Analise e Desenho Orientado a Objetos com UML

com UML
Análise e Desenho
Orientado a Objetos
Capacitação Engenharia de Software Análise e Desenho Orientado a Objetos com UML

Rildo F Santos
rildo.santos@etecnologia.com.br
rildo.santos@companyweb.com.br

Twitter: @rildosan
Blog: http://rildosan.blogspot.com/
Todos os direitos reservados e protegidos © 2006 e 2010
Versão 27 Rildo Santos (rildo.santos@etecnologia.com.br)
Versão 27 |

Análise e Desenho Orientado a Objetos com UML

Conteúdo
Capacitação Engenharia de Software

Parte 1 - Principais Conceitos da Orientação a Objetos e introdução
UML

Parte 2 – Especificação de Requisitos de Software

Parte 3 – Analise Conceitual

Parte 4 – Desenho (design) do Modelo de Especificação de Software

Parte 5 – Arquitetura de Software

Versão 27 Rildo Santos (rildo.santos@etecnologia.com.br) 2


Principais Conceitos da
Orientação a Objetos e UML
Objetivo desta parte:
É apresentar e discutir os principais conceitos da
Orientação a Objetos e fazer uma breve introdução a UML

Todos os direitos reservados e protegidos © 2006 e 2010 3


Orientação a Objetos. Principais Conceitos:

Objetivo

Objetivo:
Apresentar os principais conceitos da orientação a objetos. Será demonstrado os seguintes
conceitos: Classes, Objetos, Atributos, Métodos, Classe Abstrata, Abstração de Dados,
Herança, Polimorfismo e Encapsulamento



Introdução. Desenvolvimento de Software Orientada a Objetos

Influência escolha da
Ferramentas

Ferramentas
Tecnologia OO
e
Artefatos

Atividades

Suporte as atividades

WorkFlows

Metodologia/Fases

Jacobson pyramid “rational enterprise philosophy”



Objetos do Mundo Real

Podemos encontrar várias definições para o termo “objeto”, entre eles:

“Objeto pode ser qualquer coisa na natureza que possua
características e comportamentos”

Veja alguns exemplos de objetos:

Pessoa Cão Partida Barco
de Futebol
Os objetos podem ser físico (aqueles que podemos pegar, exemplos: uma pessoa,
um animal, um barco, um livro, um carro, uma casa e etc) e os conceituais
(aqueles que não podemos pegar, tais como: uma partida de futebol, uma ligação
telefônica, uma conta corrente e etc...)



Objetos

O termo orientação a objetos significa organizar o mundo real
como uma coleção de objetos que incorporam estrutura de
dados (propriedades ou características) e um conjunto de
operações que manipulam estes dados.
Classes
Objetos Objeto: Pessoa Propriedades Operações
Andar
Atributos Nome
Correr
Data de Nascimento
Métodos Massa (peso)
Trabalhar
Chorar
Altura
Abstração de Dados Dançar

Herança
Objeto: Pássaro Propriedades Operações
Polimorfismo
Espécie Andar
Encapsulamento Cor das penas Correr
Tamanho Voar
Peso Pousar




Os objetos tem um identificador único (que podemos chamar de nome do objeto), tem
conjunto de propriedades (que podemos chamar de características e/ou atributos) e
comportamentos (que podemos chamar de operações).

Atributos
cor
Número chassi
Ano-fabricação
Identificador
Carro
Operações
acelerar
O que são operações ? parar
- São coisas que objeto deve
saber fazer.



Quando atribuímos valores aos objetos, ou seja, as propriedades (atributos), podemos dizer que
ele tem um estado

Atributos
cor branco
Número chassi VW1003G345
Ano-fabricação 1966
Identificador
Carro
Operações
acelerar estado
parar




Os nomes dos objetos geralmente são substantivo no singular, tais como: cliente, conta-corrente,
pessoa e etc.
Os atributos também são substantivos, exemplo: cor, tamanho, peso, idade, número e etc.
Já as operações usualmente são verbos, como: acelerar, validar, verificar, calcular e etc

Atributos
cor branco
Substantivo
Ano-fabricação 1966
Identificador
Carro
Operações
acelerar
parar
verbos




Modelagem de objeto:

Identificador Carro
Nome (identificador)

Representação na
Orientação a objetos
Carro
Atributos cor
número chassi
cor branco
ano-fabricação
Número chassi VW1003G345 Propriedades
acelerar (atributos)
Ano-fabricação 1966 parar
Operações
acelerar
parar Operações




Modelagem de objeto:

Para representar os objetos do mundo real criamos classes, E
aí partir destas classes podemos criar os “objetos”.
Podemos dizer que um objeto é uma “instance” (espécie) da
classe.
Carro As classes são “blueprint” (projeto) para os objetos. São fôrmas
cor de objetos.
número chassi
ano-fabricação O que é
acelerar uma classe ?
parar
Representação na
Orientação a objetos




Classe
Definição de Classe:
Uma classe descreve um conjunto de objetos que compartilham os
mesmos atributos, operações, métodos, relacionamentos e semântica
Classes As classes são as partes mais importantes de qualquer sistema orientado a
objetos.
Objetos Usamos as classes para capturar o vocabulário do sistema que está em
Atributos desenvolvimento. Essas classes podem incluir abstrações que são parte do domínio do
problema, assim como as classes que fazem a implementação. Podemos usar ainda as
Métodos classes para representar itens de software, de hardware e até itens que sejam somente
conceituais.
Abstração de Dados
Exemplo:
Herança A classe Pessoa deverá ter atributos e métodos comuns
Polimorfismo
Pessoa Nome da Classe
Encapsulamento
nome Atributos
idade
getNome()
getIdade()
Nota: Dicionário Aurélio Métodos
Em programação ou modelagem orientada a objetos (v. orientação a objetos), categoria descritiva setNome()
geral, que abrange o conjunto de objetos que compartilham uma ou mais características quanto a
seus itens de dados e procedimentos associados. 22. Lóg. Agrupamento de objetos que têm uma ou
setIdade()
mais características em comum.




Classe
Exemplo de Classe:
3
1 Livro
Legenda:
1 – Objeto no mundo real
Classes 2 – Classe Livro
Objetos 3 – Objeto da classe Livro

Atributos
Métodos
Herança
Polimorfismo 2 ISBN 0747551006
Encapsulamento Titulo: Harry Potter and the
Order of the Phoenix
Autor: J. K. Rowling




Classe e Objeto
Classe e Objeto. Exemplo:

ISBN 0747551006
Titulo: O Poder da inteligência
Emocional
Classes Autor: Daniel Goleman
Objetos
Atributos ISBN 0747551006
Métodos Titulo: Harry Potter and the
Order of the Phoenix
Abstração de Dados Autor: J. K. Rowling
Herança
Polimorfismo ISBN 8571643512
Titulo: AS JANELAS DO
Encapsulamento PARATII
Autor: Amir Klink

Uma coleção de livros
pode ser representada Cada livro desta coleção é
por uma classe chamada “instance” (objeto) da classe livro.
Livro.




Classe e Objeto

Identificador Carro

Classe (Modelo) Objeto (“instance”)
Carro fusca:Carro
cor cor=“branco”
Atributos número chassi número chassi=“VW1003G345
cor branco ano-fabricação ano-fabricação=1966

Acelerar()
Ano-fabricação 1966 parar()
Operações
acelerar
parar



Classe e Objeto

Classe

Classes Cliente
nome
Objetos cpf
idade
Atributos
Métodos
Herança Objetos
Polimorfismo
Encapsulamento
Cliente: clientemulher Cliente: clientehomem
nome = Marina nome = Felipe
cpf = 022.200.708-12 cpf = 039.217.908-22
idade = 16 idade = 42




Classe, Responsabilidade e Colaboração
Responsabilidades
Definição de Responsabilidades:
Um contrato ou obrigação em um tipo ou de uma classe
Ao criar uma classe você estará criando uma declaração de que todos os objetos dessa
Classes classe têm o mesmo tipo de estado e o mesmo tipo de comportamento.
Em nível mais abstrato, esses atributos e operações são apenas as características com
Objetos quais as responsabilidades das classes executadas.
Atributos
Uma classe chamada de Transação de Pagamento tem a responsabilidade de
Métodos conhecer as informações inerente a operação, tais como número da transação,
Abstração de Dados situação, valor, data, tipo de pagamento e etc.

Herança TransacaoPagamento

Polimorfismo numero
valor
Encapsulamento data
situação
TipoPagamento
Responsabilidades
Responsabilidade:
-- Saber o número da
transação, data, valor
-- Conhecer o tipo de
pagamento...




Colaboração:
Definição de Colaboração:
Ás vezes uma classe precisa colaborar com outra classe para
cumprir suas responsabilidades
Classes
A classe Transação de Pagamento tem a responsabilidade de conhecer as
Objetos informações: número da transação, situação, valor, data, tipo de pagamento e etc.
As informações sobre tipo de pagamentos estão outras classes que especifica os
Atributos dados para cada tipo de pagamento. Exemplo: CartaoCredito e BoletoBancario.
Métodos Desta forma precisamos ter uma colaboração entre as classes para atender as
responsabilidades.
Herança TransacaoPagamento CartaoCredito
Polimorfismo numero
valor
Encapsulamento data
situação
TipoPagamento Colaboração BoletoBancario
Responsabilidade:
-- Saber o número da
transação, data, valor
-- Conhecer o tipo de
pagamento...




Classes, Responsabilidades e Colaboração:

Para descrever responsabilidades utilize apenas texto em formato livre. Na prática
uma única responsabilidade pode ser escrita como expressão, ou uma oração ou
breve parágrafo.
Classes O CRC (Cartão de Responsabilidade e Colaboração) é uma técnica usada para
capturar e representar as classes, suas responsabilidade e colaborações.
Objetos Outra técnica que pode ser usada é a Análise de Caso de Uso.
Atributos
Métodos Nome da classe Cartão CRC
Herança Responsabilidades Colaborações
Polimorfismo
Encapsulamento
Aluno
-- Deve conhecer os Matricula
dados dos aluno: Pessoa
Nome Curso
Número da Matricula
Curso




Resumo: Classe e Objeto
Resumindo:
Um objeto possui:
• um estado (definido pelo conjunto de valores dos seus
atributos em determinado instante)
Classes • um comportamento (definido pelo conjunto de métodos
Objetos definido na sua interface)
Atributos • uma identificação única
Métodos
Uma classe possui:
Abstração de Dados • Atributos
Herança • Métodos
Polimorfismo • Responsabilidades (o que ela deve saber fazer)
Encapsulamento • Colaboração (interação com outras classes)




Atributo
Definindo Atributo:

• É uma característica (uma propriedade) presente no objeto.
• Os valores dos atributos é igual ao Estado do Objeto.
Classes • Somente atributos que são de relevantes ao sistema devem ser
Objetos descritos na classe.
Cliente
Atributos nome
Métodos cpf
idade
Herança
Polimorfismo
Encapsulamento

Cliente: clientemulher
nome = Marina
atributos cpf = 022.200.708-12
idade = 16




Método
Escrevendo os métodos.

Para cada atributo é recomendado escrever um par de métodos, os nomes destes
métodos devem começar com setXXXX( ) e getXXX( )

Classes
setCodigo():
Objetos Para trocar o valor do atributo
Atributos Cliente getCodigo():
Métodos codigo
Para recuperar o valor do atributo
nome Exemplo:
Abstração de Dados Valor do atributo: nome = null
getCodigo()
Herança setNome(“Duke”).
setCodigo()
Métodos Agora valor do atributo nome = “Duke”
Polimorfismo getNome()
setNome() getNome(), retornará “Duke”
Encapsulamento




Método
Definição de Método:

Definição:
Método é a implementação de uma operação.
Classes Definição de Operação:
É a implementação de um serviço que pode ser solicitado por qualquer
Objetos
objeto da classe com a finalidade de afetar um comportamento.
Atributos
Métodos Chamando os métodos
Para chamar um método de um objeto é necessário enviar uma mensagem para ele.
Abstração de Dados As mensagens identificam os métodos a serem executados no objeto receptor.
Herança Por definição todas as mensagens devem retornar pelo menos um valor.

Polimorfismo ContaCorrente
Encapsulamento conta
saldo
setDeposito()
Métodos getSaldo()
setSaque()




Mensagem
Definição de Mensagem:
Definição:
Mensagem é uma chamada de uma operação sobre um objeto,
compreendendo um nome da operação e uma lista de valores de
Classes argumentos. (Rumbaugh)
Objetos Um mensagem representa a requisição de um objeto remetente a um objeto receptor
Atributos para este último execute alguma operação definida para sua classe.
Essa mensagem deve conter informações suficientes para que a operação do objeto
Métodos receptor possa ser executada.
Herança
Polimorfismo
Encapsulamento




Resumo: Métodos
Resumindo:
Os métodos são a implementação das operações de objetos.
Os métodos são responsáveis pelo comportamento do objeto.
A mudança de estado de um objeto deve ocorrer através dos
Classes métodos.
Objetos
Atributos Desta forma podemos dizer que os métodos “encapsulam” os
Métodos atributos.
Herança
Polimorfismo
Encapsulamento




Classe Concreta e Abstrata
Temos dois tipos de classes:

Classe concreta:
São aquelas classes que podem
sofrer “instance” (criação de
objetos) e tem seus métodos
implementados por completo.

E a Classe abstrata ?
São aquelas classes que não
podem sofrer “instance” e seus
métodos não são implementados
por completo (geralmente apenas
assinado).




Exemplo:

Um a empresa de transporte possui uma frota de veículo, esta frota é composta por caminhões, peruas
e motos.
Estes veículos têm algumas características semelhantes como cor, peso, tamanho e capacidade de
carga. Entretanto, cada veículo possui outras características diferentes como número de eixos sistema
de freio, tipo de motor e etc.
A abstração de dados é utilizada neste caso para identificar todas as propriedades comuns e reuni-las
em novo conjunto, isto lembra alguns princípios da matemática como fatoração.
Desta forma estaríamos fazendo um melhor aproveitamento das informações que se repetem e também
estamos fazendo que as características diferentes sejam tratada de forma diferenciada.

O que é
abstração
de dados ?




Definição de Abstração de Dados:

Definição de abstração:
“Habilidade mental que permite aos seres humanos visualizarem os problemas
do mundo real com vários graus de detalhes, dependendo do contexto corrente
Classes do problema. (Jim Rumbaugh).
Objetos Qual é a função da abstração ?
Atributos A função da abstração é capturar as propriedades e os comportamentos essenciais,
como se fosse uma fatoração, desta forma determina-se o que é importante e o que
Métodos não é.
Abstração de Dados Exemplo
Herança
Polimorfismo Contribuinte
Encapsulamento Abstração

Contribuinte Contribuinte
Pessoa Física Pessoa Jurídica

especialização




Exemplo de Abstração de Dados:

Abstração: nos ajuda a lidar com a complexidade.
Exemplo
Classes Generalização
Objetos
MeiodeComunicação
Atributos
Métodos
Carta Telefone Jornal
Herança
Polimorfismo
Encapsulamento

Especialização
As classes Contribuinte e MeiodeComunuicação são abstratas e ambas podem
representam um domínio.




Abstração de Dados e Classe Abstrata:
Uma classe abstrata é uma classe que:
• Provê organização
• Não possui “instances”, ou seja, não possui objetos.
Classes • Possui uma ou mais operações (métodos) abstratas

Objetos public abstract class ContaBancaria extends Object {
Atributos public ContaBancaria() { }
protected int numerocontacorrente;
Métodos public abstract int getNumeroContaCorrente();

Abstração de Dados }
public abstract void setNumeroContaCorrente(int numerocontacorrente);

Herança
Polimorfismo
Encapsulamento




Abstração de Dados, exemplo:
Veja agora a classe Pessoa, que é public abstract class Pessoa {
abstrata, pois, possui um método //métodos
public abstract String getNome()
abstrato.
public void setNome(String nome){
this.nome = nome;
}
Um método abstrato não possui public abstract int calcIdade(Date
public abstract int getIdade()
implementação somente assinatura d1, Date d2);
(declaração) public void setIdade(int idade)
public void setIdade(int idade)
{ {
this.idade = idade;
this.idade = idade;
} }

}

Um método concreto possui implementação
assinatura e implementação.




Resumo: Classe Abstrata
Resumindo:
Uma classe abstrata deve ter métodos abstratos.
Uma classe abstrata não possui “instance”
Classes
Objetos
Atributos
Métodos
Abstração de Dados Como eu faço
Herança para usar uma
Polimorfismo classe abstrata ?
Encapsulamento





Comparação entre Classe Abstrata e Classe Concreta

Classe Abstrata Classe Concreta

Os métodos podem ser assinados e
Os métodos devem ser somente assinados
implementados

Não pode sofrer “instance” Poder sofrer “instance”

Relacionamento somente através de
Todos os tipos de relacionamentos
HERANÇA




Herança
Definição de Herança:
Definição:
Mecanismo baseado em objetos que permite que as classes compartilhem atributos
e operações baseadas em um relacionamento, geralmente generalização.
Classes (Rumbaugh)
Objetos Uma classe derivada herda a estrutura de atributos e métodos de sua
Atributos classe “base”, mas pode seletivamente:
• adicionar novos métodos
Métodos • estender a estrutura de dados
• redefinir a implementação de métodos já existentes
Herança Uma classe “pai” ou super classe proporciona a funcionalidade que é comum a todas as
suas classes derivadas, filhas ou sub classe, enquanto que a classe derivada
Polimorfismo proporciona a funcionalidade adicional que especializa seu comportamento.
Encapsulamento Exemplo:
Animal
classe pai

Animal Doméstico Animal Selvagem
classe filha




Herança
Exemplo de Herança:

Classes Podemos dizer que Pós-
Hierarquia de Classes Graduação é tipo de Curso
Objetos Universitário, assim como
Curso
Atributos Super classe Universitário
Curso de Especialização ou
de Extensão.
Métodos ou classe pai

Herança Graduação Pós-Graduação

Polimorfismo extends
Encapsulamento Sub classe
ou classe filha Especialização Extensão

Validação: Pode ser feita através de uma expressão que resulte um valor verdadeiro
Exemplo:
Graduação é tipo de Curso Universitário = Verdadeiro




Polimorfismo
Definição de Polimorfismo:
Definição:

“Polimorfismo” é uma operação que pode assumir múltiplas formas, a propriedade
segundo o qual uma operação pode comportar-se diferentemente em classes
Classes diferentes” (Rumbaugh)
O polimorfismo é o responsável pela extensibilidade na programação orientada a
Objetos objetos.
Atributos Promove o reúso.

Métodos Exemplo:

Billhetagem
Herança Telefone Móvel
Polimorfismo calcularConta(telefone)
Encapsulamento

Telefone Fixo




Polimorfismo
Overloading de Método
Possibilidade de reúso do nome do método para diferentes implementações, em
tempo de execução, a aplicação, escolherá o método mais adequado para cada
chamada, veja o exemplo.
Classes
Objetos
Atributos TesteSoma Soma

Métodos somar(int a, int b)
somar(float a, float b)
Abstração de Dados somar(char a, char b)
Herança somar(long a, long b))

Polimorfismo
Encapsulamento
Para cada tipo de dados existe um método, o reúso do nome do método é permitido,
entretanto, a lista de argumentos deve ser diferente, veja o exemplo acima: o método
somar é definido várias vezes, contudo, com uma lista de argumentos diferentes,
desta forma evitaremos problemas como ambigüidade.




Polimorfismo
Overridde de Método
Uma sub classe (classe filha) pode mudar o comportamento herdado da
Super classe (classe pai), ou seja, um método herdado poderá ser
modificado. Veja o exemplo abaixo:
Classes Conta Bancária
Objetos getSaldo()
Atributos
Métodos
Abstração de Dados Conta Corrente Conta Poupança Investimentos
Herança getSaldo() getSaldo() getSaldo()
Polimorfismo
Encapsulamento O método getSaldo é herdado da Superclasse (Conta Bancária), entretanto para cada tipo de
Conta o método tem uma implementação diferente. Por exemplo:
- Para apurar o saldo da Conta Corrente saldo atual = (soma dos depósitos + saldo anterior) -
saques
Para a conta poupança seria saldo atual = (soma dos depósitos + saldo anterior + juros) -
saques
Para a conta de investimentos seria saldo atual = (soma dos aplicações + saldo anterior +
juros) - resgates - ir




Encapsulamento
Principais Conceitos
Definição de Encapsulamento:

É uma proteção adicional dos dados do objeto de possíveis modificações
impróprias, forçando o acesso a um nível mais baixo para tratamento do dados.

Classes
Objetos Public
Operações/métodos/interface
Atributos
Métodos
Herança
Polimorfismo
Private
Encapsulamento Dados/Atributos/propriedades

Exemplo:
Quanto temos a edição de um arquivo protegida por senha, podemos dizer que ele
está protegido, pois, apenas aquele que tem a senha poderá editá-lo. Os demais
somente estão aptos a le-lo.




Encapsulamento
Benefícios do Encapsulamento:

Benefícios
- Segurança:
Protege os atributos dos objetos de terem seus valores corrompidos por
Classes outros objetos.
- Independência:
Objetos “Escondendo” seus atributos, um objeto protege outros objetos de
Atributos complicações de dependência de sua estrutura interna

Métodos
Pessoa
Herança nome
Polimorfismo idade setNome() nome getNome()
Encapsulamento setNome()
getNome()
setIdade() setIdade() idade getIdade()
getIdade()

encapsulamento



UML. Linguagem de Modelagem Unificada

A versão da UML abordada é versão 1.5




Introdução
Por que modelar sistemas ?

Construímos modelos para compreender melhor o sistema que estamos desenvolvendo.
Com a modelagem, podemos alcançar alguns objetivos:
1 - Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja;
2 - Os modelos permitem especificar a estrutura ou o comportamento de um sistema;
3 - Os modelos proporcionam um guia para a construção do sistema;
4 - Os modelos ajudam na documentação do sistema.
O Que é Modelagem Visual?

“A Modelagem captura as partes essenciais do sistema.” (Rumbaugh)



Introdução
O Que é Modelagem Visual?
Modelagem visual significa modelar com a utilização de uma notação padrão.
Precisamos adotar uma notação padrão (linguagem) e uma ferramenta.
UML (Linguagem de Modelagem Unificada) é a linguagem de modelagem visual
considerada padrão de mercado.

A UML (Linguagem de Modelagem Unificado)
é mantida pelo OMG (www.omg.org/uml).




Introdução
A UML (Linguagem de Modelagem Unificada) é uma linguagem-padrão para elaboração
da estrutura de projetos de software. A UML poderá ser usada para:
• Visualização
• Especificação
• Construção de modelos e diagramas
• Parte da documentação.

A UML é adequada para a modelagem de sistemas, cuja a abrangência poderá incluir
sistemas de informação corporativos a serem distribuídos a aplicação baseadas em Web
e até sistemas complexos embutidos de tempo real.

A UML é apenas uma linguagem e, portanto, é somente uma parte de um método para
desenvolvimento de software. Ela é independente do processo, apesar de ser
perfeitamente utilizada em processo orientado a casos de usos, centrado na arquitetura,
iterativo e incremental.




Principais Digramas:

ESTÁTICOS

. Diagrama de Classes
. Diagrama de Objetos Estrutura do sistema
. Diagrama de Componentes
. Diagrama de Distribuição

DINÂMICOS

. Diagrama de Casos de Uso
. Diagramas de Interação Comportamento do sistema
- Diagrama de Seqüência
- Diagrama de Colaboração
. Diagrama de Atividade
. Diagrama de Estados




Processo de Desenvolvimento:
Processo de Desenvolvimento

Modelo Casos Modelo Objetos
Modelo de Classes
Uso de Negócio de Negócio

Realização Análise Desenho
Necessidades dos Visão Modelo de dos Casos de Uso Classes Classes
Stakeholders Casos de Uso

Casos de Teste
Componentes

Defeitos Script de Testes




A Linguagem:
• Linguagem = Sintaxe + semântica
– syntax = rules by which language elements (e.g., words) are assembled
into expressions (e.g., phrases, clauses)
– semantics = rules by which syntactic expressions are assigned
meanings
• Notação = (UML Notation Guide) – define uma sintaxe gráfica UML
• Semântica = (UML Semantics) – define uma semântica UML




Elementos:
• Elementos estruturais:
– classe, interface, colaboração, caso de uso, classe ativa, componente
e nó
• Elementos comportamentais:
– Interação e máquina de estados
• Elementos de agrupamento:
– Pacote e subsistema




Visão: 4 + 1

Visão de Visão da
Projeto Implementação
Codificação
Funcionalidade Montagem
Vocabulário
Visão de
Caso de Uso
Visão do Visão da
Processo Implantação
Desempenho Topologia do Sistema
Escalabilidade Distribuição
Throughput Instalação

Conceitual Físico



Visões:
Visão de Caso
de Uso
• A visão do caso de uso abrange os casos de usos que descrevem o comportamento do sistema
conforme é visto pelos seus usuários finais, analistas e pessoal de teste. Essa visão não
especifica realmente a organização do sistema de software. Porém , ela existe para especificar as
forças que determinam a forma da arquitetura do Sistema. Com a UML, os aspectos estáticos
dessa visão são representados em diagramas de caso de uso, enquanto os aspectos dinâmicos
são representados em diagrama de interação, diagrama de estados e diagrama de atividades

Visão de Projeto

• A visão de projeto de um sistema abrange as classes e colaborações que formam o vocabulário do
problema e da solução. Essa perspectiva proporciona principalmente um suporte para os requisitos
funcionais do sistema, ou seja, os serviços que o sistema deverá fornecer a seus usuários finais.
Com a UML, os aspectos estáticos dessa visão são capturados em diagramas de classes e de
objetos; os aspectos dinâmicos são capturados em diagramas de interações, de estados e de
atividades.



Visões:
Visão de Processo

• A visão do processo abrange os “threads” e os processos que formam os mecanismos de
concorrência e de sincronização do sistema. Essa visão tem com objetivo principal tratar questões
de desempenho, crescimento “escalar” e ao “throughput” do sistema. Com a UML, os aspectos
estáticos e dinâmicos dessa visão são capturados nos mesmos tipos de diagrama da visão do
projeto, mas o foco voltado para as classes ativas que representam essas threads e processos.
Threads = Linhas de execução em paralelos, também conhecido como processo, estas linhas podem ser
programas ou parte.

Visão de Implementação

• A visão de implementação de um sistema abrange os componentes e os arquivos utilizados
para a montagem e fornecimento do sistema físico. Essa visão envolve principalmente o
gerenciamento de configuração das versões do sistema, compostas por componentes e
arquivos de alguma maneira independentes, que podem ser reunidos de diferentes formas para
a produção de um sistema executável.




Visões:
Visão de Implantação

• A visão de implantação de um sistema abrange os “nodes” que formam a topologia de hardware
em que o sistema é executado. Essa visão direciona principalmente a distribuição, o fornecimento e
a instalação das partes que constituem o sistema físico. Com a UML, os aspectos estáticos dessa
visão são representados em diagramas de implantação; os aspectos dinâmicos são capturados em
diagramas de interações, de gráfico de estados e diagramas de atividades.

Cada uma dessas visões pode ser considerada isoladamente, permitindo que diferentes
participantes orientem seu foco para os aspectos da arquitetura do sistema que mais lhes
interessem. Essas cincos visões também interagem entre si, por exemplo:
Os “nodes” na visão de implantação contêm componentes da visão de implementação que, por sua vez,
representa a realização física de classes, interfaces, colaborações e classes ativas provenientes das visões
de projeto e de processo.




Exemplo: de Projeto Software Orientado a Objetos:

Use case view Formulários

unidades Diagrama de Seqüência e/ou
Diagrama de Colaboração
Casos de Uso
Diagrama de Estado
Logical view Diagrama de Atividades
Diagrama de Pacotes

Diagrama de Estado
Diagrama de Classes Diagrama de Atividades
Diagrama de Pacotes
Component view

Diagrama de Componentes
Deployment view

Diagrama de Deployment




Big Picture. Requisitos e Análise
Caso de Negócio Coleta de Requisitos Análise Conceitual
Modelo Conceitual
Documento
de Visão

Engenharia de Requisitos
4

Análise de Requisitos Especificação de Requisitos
(Visão de Caso de Uso)
Requisitos Funcionais
Glossário de
conceitos

Casos de Uso

Requisitos Não
Funcionais Arquitetura Inicial




Introdução. Artefatos:
Produtos dos Workflows de Requisitos e de Análise:
Documento de Visão

Documento de Requisitos
Requisitos
Especificação de Requisitos (Casos de Uso)

Modelo Conceitual ou Modelo de Domínio

Análise Vocabulário do Sistema

Modelo de Arquitetura Inicial




Big Picture. Análise & Projeto
Análise Projeto (Visão Lógica)
Modelo Conceitual Diagrama de Classes

4

Receber Pedido

4

Preencher Pedido Enviar Fatura

Entrega

[pedido urgente] [senão]

Receber Pagamento

Entrega durante Entrega Regular

Especificação de Requisitos a noite

: FormBusca : Categoria : Produto : Catalogo
: visitante

getDescricao( )

exibirCategoria( )

selecionarCategoria
getDescricao( ) getQuantidade( )

exibirProduto( )
Encerrar Pedido

selecionarProduto( )




Projeto
Principais Produtos (Artefatos):

Diagrama de Seqüência / Colaboração

Diagrama de Atividades

Diagrama de Estados

Diagrama de Classes




Big Picture. Projeto &Arquitetura
Projeto (Visão Lógica) Arquitetura
Diagramas Projeto (Visão de Componentes e
Visão de Deployment)

4

Receber Pedido

: visitante

getDescricao( )

Entrega
exibirCategoria( )

selecionarCategoria [pedido urgente] [senão]
Receber Pagamento

exibirProduto( )

a noite

Encerrar Pedido




Arquitetura
Principais Produtos (Artefatos):


Diagrama de Distribuição(Deployment)

Modelo de Arquitetura



Especificação de Requisitos
de Software
É apresentar uma revisão da Especificação de Requisitos
de Software.
Para ver todo o conteúdo da parte 2, veja o Anexo B.


Introdução Análise e Desenho Orientado a Objetos com UML
Análise de Requisitos: Introdução
Um entendimento completo dos requisitos de software é essencial para um o sucesso do

desenvolvimento do software. Não importa quão bem projetado ou quão bem codificado
seja, um programa mal analisado e especificado frustrará o usuário.
Análise de requisitos é um processo de descoberta, refinamento, modelagem e
especificação.

O escopo do software, inicialmente estabelecido pelo Analista de Sistemas e refinado
durante o planejamento do projeto de software, é aperfeiçoado em detalhes.
Modelos, diagramas, fluxos são criados para melhor compreensão do problema.
O analista e o usuário desempenham um papel ativo na análise e especificação de
requisitos.

O cliente (usuário) tenta reformular um conceito de função e desempenho de software, às
vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e
solucionador de problemas.
Entretanto, a análise e especificação de requisitos pode parecer uma tarefa relativamente
simples, mas as aparências enganam. O grau comunicação é elevado. Daí, surgem as
oportunidades de interpretações errôneas e informações falsas. A ambigüidade é provável.

O dilema com o qual se depara um analista pode ser mais bem entendido, repetindo-se a
declaração de um cliente anônimo:
“Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo
que percebeu que aquilo que ouviu não é o que eu pretendia dizer...”


Ferramenta de Desenvolvimento de Software

Big Picture. Requisitos
Caso de Negócio Coleta de Requisitos Análise Conceitual
Modelo Conceitual
Documento
de Visão

4

Glossário de
conceitos

Casos de Uso

Requisitos Não



Workflow Requisitos

Requisitos
Workflow Artefatos Papéis
Arquitetura Documento de Visão

Analista de Sistema
Analista de Requisitos
(Requisitos Funcionais e
Requisitos Não Funcionais)

(Casos de Uso)



Da perspectiva da engenharia de software, a “elicitação” de requisitos é talvez a mais parte mais critica
do processo de desenvolvimento de software.
Estudos indicam que os requisitos, só detectados depois do software implementado ou erros na análise
de requisitos, são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.



Requisitos

Definições de requisito (segundo IEEE)
1) Uma condição ou uma capacidade de que o usuário necessita para solucionar um
problema ou alcançar um objetivo.

2) Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema
ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação
ou outros documentos impostos formalmente.

3) Uma representação documentada de uma condição ou capacidade, conforme os itens
(1) e (2).



Requisitos

Requisitos. Road Map

Fazer identificação e elicitação
Regras de
negócio
de requisitos

Documento de Visão

Fazer Análise de Requisitos
Usuários e
Clientes
Documento de
Requisitos
Fazer Especificação de Requisitos

Documentos Fazer Validação de Requisitos

Documento de
Especificação
de Requisitos


Requisitos

Identificação e elicitação de Requisitos:
Por que o “elicitação” é importante:
O sucesso no desenvolvimento de um projeto de software depende basicamente da elicitação de
requisitos, pois, é a base que permitirá ao Analista tirar conclusões sobre as situações, problemas ou
fenômenos e, assim, sugerir propostas que possam contribuir para a solução do problema.
Entretanto, esta atividade, nem sempre está presente no processo de desenvolvimento, raramente ela é
elaborada de forma metodológica, geralmente tem uma abordagem intuitiva.
Principais características de uma “boa elicitação de requisitos”:

• Definir as técnicas de coleta de requisitos baseadas em fatores operacionais, táticos e financeiros;
• Criar um planejamento com objetivo de alcançar as metas estabelecidas, tais como: Prazos, Custos e
Qualidade;
• Promover a integração e o comprometimento de todos os envolvidos no processo, por exemplo:
Clientes, Fornecedores, Usuários e o Patrocinador.
• Identificar os documentos e procedimentos que definem as políticas de negócios da empresa.
Uma Simples Comparação:
Elicitação Boa Elicitação Ruim
Bom Diagnóstico Diagnóstico ineficiente

Soluções eficientes Soluções medíocres
Satisfação dos usuários Insatisfação dos usuários
Melhoria dos processos e redução de custo Problemas operacionais e financeiros



Requisitos

Documento (Artefato) desta etapa: “Documento de Visão”

Participantes:
Analistas e
documentos Objetivo:
Especialista reuniões
em Negócios Descrever
a visão inicial
Participantes: identificação/
do software
Usuário, elicitação de
Clientes, Requisitos
Fornecedores e Documento
Patrocinadores de visão
entrevistas



Requisitos

As fases da Identificação/Elicitação de Requisitos:

Um projeto de elicitação de requisitos têm as seguintes fases:

Identificar Fontes
Como deve ser feito ? Planejamento Técnicas

Elicitação de Identificar Funcionalidades
O que devo coletar ?
Requisitos Identificar Restrições e Riscos

Como devo documentar ? Documentação

Documento de Visão



Requisitos

As informações podem ser identificadas ou encontradas em diversas fontes:
- Usuários;
- Documentos;
- Especificações;
- Clientes;
- Patrocinadores;
- Analista de Negócios (“Domain Experts” - Especialista em uma ou mais área de negócio)
Quais são as técnicas ?

Existem várias técnicas, todas elas possuem seus
próprios conceitos, vantagens e desvantagens,
que podem ser usada nesta atividade entre elas estão:
- Reuniões;
- Entrevistas;
- Questionários;
- Workshop;
- Brainstorming;
- JAD (Join Application Development)
- Fast;
- Documentos;
- Sistemas Legados.


Análise de Requisitos

Identificação dos Requisitos: Tipos de Requisitos
Os Requisitos de Software podem ser divididos em duas categorias:

Requisitos

Requisitos Requisitos
Funcionais Não-Funcionais
Os requisitos funcionais descrevem o quê o Os requisitos não funcionais dizem respeito as
sistema deve fazer, isto é, as funções características que descrevem qualidade do serviço
(funcionalidades) necessárias para atender os (QoS).
objetivos. Exemplos: Buscar cliente, Registrar A omissão ou esquecimento desses requisitos constitui
pedido uma das principais razões de uma eventual
Calcular conta de consumo, Calcular tributos e insatisfação dos usuários com relação a um software.
etc. Os Requisitos Não Funcionais (RNF) também são
chamamos de “Requisito Suplementares.”
Exemplos: performance, disponibiliade, confiabilidade,
segurança, usabilidade e etc.



Requisitos

Identificação dos Requisitos:
Os requisitos de software podem ser identificados no texto da “declaração do
problema” (geralmente são verbos que identificam algumas ações).

Este documento possibilita a identificação, extração e
classificação dos requisitos
- Requisitos funcionais e

- Requisitos não funcionais.

Texto da Declaração do Problema



Requisitos

Documento de Visão: Exemplo: Documento de Visão:
Data: ________ | Autor: ________ | Revisão: ____
Objetivo: Índice:
Fazer uma descrição da visão da solução 1.0 - Introdução
1.1 Objetivo do documento
Este documento tem as seguintes seções: 1.2 Escopo
-Entendimento do Problema; 1.3 Abreviaturas, Siglas e etc.
- Lista dos Stakeholders 2.0 Entendimento do Problema (Contexto)
- Lista dos Requisitos 2.1 Declaração do Problema
- Lista dos Riscos 2.2 Diagrama de Contexto
- Lista das Restrições 3.0 Lista de Stakeholders
3.0 Usuários
3.1 Entidades
4.0 Lista dos Requisitos
4.1 Requisitos funcionais
4.2 Requisitos não funcionais
5.0 Lista dos Riscos
6.0 Lista das Restrições
6.1 Software
6.2 Hardware
6.3 Ambiente e Tecnologia


Requisitos


Regras de
negócio
de requisitos

Documento de Visão

Usuários e
Clientes
Documento de
Requisitos


Documento de
Especificação
de Requisitos


Requisitos

Análise de Requisitos: Introdução
A análise de requisitos procura sistematizar o processo de definição de requisitos.
Essa sistematização é necessária porque a complexidade dos sistemas exige que se preste mais
atenção ao correto entendimento do problema antes do comprometimento de uma solução. Uma
definição para requisitos é apresentada a seguir.
O Documento de Visão é um artefato importante na Análise de Requisitos, destacamos algumas
razões:
- Da perspectiva da engenharia de software, a elicitação de requisitos é talvez a mais parte mais critica
do processo de desenvolvimento de software.
A Análise de Requisitos deve ser:

Correta: Quando cada requisito expresso nela for encontrado no software;

Não Ambígua: Cada requisito deve ter somente uma interpretação (definição);

Completa: Quando incluir todos os requisitos significativos relacionados as funcionalidades e requisitos
relacionados a qualidade do serviço (também conhecidos como requisitos não funcionais)

Consistente: Quando não existir conflito entre os requisitos;

Verificável: Quando for possível verificar/validar cada requisito;

Modificável: Quando os requisitos podem ser facilmente alterados.


Requisitos

Análise de Requisitos
Atividades da Análise de Requisitos
A análise de requisitos possibilita que o Analista de Sistemas especifique as funcionalidades,
classificando e detalhando os requisitos encontrados na coleta.
Os requisitos funcionais serão descritos em detalhes. E os requisitos não funcionais serão classificados.

Detalhar os

Classificar os
Requisitos não Funcionais

Descrever os Usuários
e Entidades Externas

Fazer Plano de Redução
de Risco



Requisitos

Análise de Requisitos. Detalhar
Requisitos Funcionais:
Os requisitos funcionais devem ser detalhados. Devemos usar um formato padrão para
esta atividade. Veja o exemplo:

Lista de Requisitos funcionais

Autor: Revisão: Data Atualização:

Nome Código Descrição
Fazer Reserva RF01E Esta funcionalidade deverá permitir o usuário (funcionário)
a fazer reserva de apartamentos, as ações que estarão
disponíveis são: criar, remover, alterar e consultar reservas.
Cada reserva deverá ter um cliente e um apartamento e
respectiva período)



Requisitos

Análise de Requisitos. Requisitos Funcionais
Descrição das Regras de Negócio
Nome do Projeto Serviço de Reserva de Apartamento
Objetivo
Descrever todas as regras de negócio para o serviço de reserva de apartamentos.

id Nome da Regra Descrição da Regra de Negócio

Um cliente poderá fazer reserva de apartamento.
RN01 Registrar Reserva de
Apartamento Restrição:
Cliente Vip devem ter preferência na escolha de data e tipo de apartamento

Para que agilizar o atendimento manter a satisfação dos clientes as consultas de reserva
devem ser feitas em no máximo 20 segundos.

Data Nome / Equipe Versão Status
Os código permitem a rastreabilidade 01/01/08 RFS 2.1 Vigente

Requisitos Funcional
RN: RN01 Nome: Reserva Descrição: Serviço de Atendimento e Reserva de Apartamento

ID Nome Descrição

Esta funcionalidade deverá permitir ao cliente fazer reserva de apartamentos, as ações que
RFC01 Registrar Reserva estarão disponíveis são: criar reserva, cancelar reserva, alterar reserva e consultar
de Apartamento disponiblidade de apartamentos
Cliente Vip terão preferência na escolha de data e tipo de apartamento



Requisitos

Análise de Requisitos. Classificar
Requisitos Não Funcionais:
Agora vamos descrever os Requisitos Não Funcionais. Entretanto, precisamos
categorizar estes requisitos, as mais frequente são:
- Performance:
Tempo de resposta
- Segurança:
Uso de senhas, certificados digitais e etc..
- Usabilidade:
Identidade Visual e Interfaces amigáveis
- Disponibilidade:
O software deve estar disponível para usuário 24x7. Exemplo: Tolerância a falha
- Flexibilidade:
Capacidade de adaptação quando um requisito muda
- Portabilidade:
Capacidade de se adaptar a outros ambientes (sistemas operacionais)
- Escalabilidade:
Capacidade de responder aumento de carga (novos usuários)

Outras categorias como Integração, Processamento, Manutenível e etc.



Requisitos

Análise de Requisitos. Classificar e Detalhar
Bem vamos descrever os requisitos não funcionais. Como na descrição dos Requisitos
funcionais, precisamos ter um padrão

Lista de Requisitos Não funcionais

Categoria: Performance

Req. Funcional
Código Descrição

Fazer As consultas que serão realizadas pelo cliente não poderão
RNFP1
Consulta exceder ao tempo de resposta de 15 segundos

Por que preciso de um código ?
Este código tem como objetivo facilitar a “rastreabilidade”.
Ele pode ser usado no Formulário de Caso de Uso, por exemplo, desta
forma conseguiremos identificar qual é o caso de uso que realiza este
RNF, no caso de mudanças.



Requisitos

Análise de Requisitos. Requisitos Não Funcionais
Descrição das Regras de Negócio
Nome do Projeto Serviço de Reserva de Apartamento
Objetivo
Descrever todas as regras de negócio para o serviço de reserva de apartamentos.

id Nome da Regra Descrição da Regra de Negócio

Um cliente poderá fazer reserva de apartamento.
RN01 Registrar Reserva de
Apartamento Restrição:
Cliente Vip devem ter preferência na escolha de data e tipo de apartamento

Para que agilizar o atendimento manter a satisfação dos clientes as consultas de reserva
devem ser feitas em no máximo 20 segundos.

Data Nome / Equipe Versão Status
Os código permitem a rastreabilidade 01/01/08 RFS 2.1 Vigente

Requisitos Não Funcional
RN: RN01 Nome: Reserva Descrição: Serviço de Reserva de Apartamento

ID Nome Descrição

RNFC01 Registrar Reserva
Performance: Consulta de disponibilidade de apartamento deve ser feitas 20 segundos.
de Apartamento



Requisitos

Análise de Requisitos. Classificar e Detalhar
Continuação:

Lista de Requisitos Não funcionais

Categoria: Usabilidade
RF /
Código Descrição
Aplicação
As cores, as fontes e logotipos devem seguir o Manual de
Aplicação RNFU1
Identidade Visual da empresa.

As interfaces com usuário devem seguir padrão de interfaces
Aplicação RNFU2
estabelecido pelo Manual de Sistema



Requisitos

Lista de Stakeholders:
Precisamos descrever todos as pessoas e/ou organização que influenciam a tomada de
decisão ou participam direta ou indiretamente do processo de construção do software.
Mais uma vez criaremos um formato padrão. Veja o exemplo:

Lista de Stakeholders


Nome Descrição

Cliente São todas as pessoas físicas ou jurídicas que fazem reservas

É qualquer pessoa que presta algum tipo serviço para
Colaborador
empresa



Requisitos

Lista de Stakeholders:
Continuação:

Lista de Entidades Externas


Nome Descrição

Administradora de Entidade que faz validação de um cartão de crédito presente
Cartão de Crédito em transação de pagamento.

Plano de Redução de Riscos:
Precisamos elaborar um Plano de Redução de Risco, para os risco que já foram
identificados. Este plano deve detalhar como mitigar os riscos identificados.



Requisitos

Análise de Requisitos. Artefato
Documento de Requisitos: Exemplo:Documento de Requisitos:
Data: ________ | Autor: ________ | Revisão: ____
Objetivo:
Classificar, descrever os requisitos de
Índice:
software, usuários e entidade externas e
1.0 - Introdução
elaboração do plano de redução de risco.
1.1 Objetivo do documento
1.2 Escopo
Este documento tem as seguintes
2.0 Requisitos Funcionais
seções:
- Requisitos Funcionais
3.0 Requisitos Não Funcionais
- Requisitos Não Funcionais 4.0 Lista Stakeholders
- Lista dos Stakeholders 4.1 Usuários
- Plano de Redução de Risco 4.2 Entidades
5.0 Plano de Redução de Riscos



Requisitos


Regras de
negócio
de requisitos

Documento de Visão

Usuários e
Clientes
Documento de
Fazer Especificação de Requisitos Requisitos
(Casos de Uso)


Documento de
Especificação
de Requisitos


Requisitos

Especificação de Requisitos:
O produto que devemos ter após Análise de Requisitos é a “A especificação de Requisitos” é feita
através de Casos de Uso, conforme definido pela UML. Um conjunto de casos de uso é importante
para se compreender o que o usuário quer. Um caso de uso descreve uma funcionalidade (“requisito”)
a ser oferecida pelo sistema, ou seja, um serviço.

Requisitos Não
Documento

Funcionais
Requisitos

Funcionais
de Visão

Documento de
Requisitos
Modelo de
Comportamento externo Casos de Uso Arquitetura
do Software
Comportamento interno Seqüência Colaboração

Estrutura Classes

Implementação Distribuição


Requisitos

Análise de Casos de Uso:
•Casos de uso expressam o diálogo entre os usuários e o sistema
•Casos de uso expressam “o quê” o sistema deverá fazer. E não “como” fazer.
•Casos de uso formam a base para testes e documentação do sistema
•O modelo de casos de uso expressam todos os casos de uso do sistema e os seus
relacionamentos.
•As técnicas para criar e expressar casos de uso em uma aplicação Web são as
mesmas para construir outros sistemas de software.

Objetivos:

• Identificar os atores;
• Identificar os casos de uso;
• Desenhar os casos de uso e
• Escrever cenários.



Requisitos

Transformar os Requisitos
Funcionais em Casos de Uso:

Calcular Total

Fazer Cadastro
Cliente
Funcionário
Fazer Pedido

Emitir NF


Requisitos

Atividades e Passos:

Fazer Diagrama de
Casos de Uso

Identificar Atores /
Casos de Uso

Escrever cenários
Rational Rose

Escrever Formulário

Fazer Diagrama de
Caso de Uso



Requisitos

Casos de Uso
Introdução:

Caso de Uso é uma representação gráfica e semântica da interação do usuário e o sistema.

Os diagramas de caso de uso são usados para capturar os requisitos funcionais do sistema. Ajuda o
entendimento do contexto dos requerimentos do sistema.

Os casos de uso podem ser agrupados em pacotes, desta forma temos uma organização funcional.

O que são Caso de Uso?
São diagramas de que permitem visualizar, especificar e documentar o comportamento de um
elemento. Esses diagramas fazem com que sistema, subsistemas e classes fiquem acessíveis e
compreensíveis, por apresentarem uma visão externa sobre como esses elementos interagem
com sistema.

Definição:
Caso de Uso é uma descrição de um conjunto de seqüências de ações, inclusive variantes, que um
sistema pode produzir um resultado de valor observável por um ator. A representação gráfica é uma
elipse.

Caso de Uso Os nomes de casos de uso
Gerenciar são breves expressões verbais
Reserva ativas.
Usuário
Ator
Nome


Requisitos

Casos de Uso
Casos de Uso e Cenários:

Os casos de uso exibem a funcionalidade na perspectiva do usuário. Entretanto, podemos ter vários
caminhos para completar esta função. Um cenários é como uma “instance” do Caso de uso, isto é, um
caminho lógico com início e fim.
Principais características:
- Cenários não contém declarações condicionais;
- Pode ter mesmo começo, mas, com final diferente;
- Um cenário é narrativa de uma situação e
- Os cenários devem descrever os bons caminhos e maus também.

Exemplo: Autorização de acesso.
O usuário executa a aplicação, o sistema exibe a janela de identificação que pede a identificação
do usuário, ou seja, seu nome e sua senha, O usuário informa seu nome e sua senha, o sistema
valida as informações e dá a autorização de acesso ao Sistema.
Se senha for invalida ou nome neste caso teremos um novo cenário.



Requisitos

Casos de Uso
Casos de Uso e Fluxo de Eventos:
Uso caso de uso descreve “o quê” um sistema (ou subsistema, classe, ou interface) faz,
ele não especifica “como” isso é feito. Ao fazer uma modelagem, importante manter clara a separação
de questões entre a visão interna e externa.

Podemos especificar o comportamento de um caso de uso pela descrição do fluxo de eventos no texto
de maneira suficientemente clara para que qualquer pessoa possa entende-lo facilmente. Ao
escrevermos o fluxo de eventos devemos incluir como e quando o caso de uso inicia e termina, como e
quando o caso de uso interage com os atores e o fluxo básico e fluxo alternativo do comportamento.
Tipos de fluxos:
• Fluxo de eventos principal e
• Fluxo alternativo de eventos.

Tipicamente descrevemos um fluxo de eventos para um caso de
uso. Os fluxos de eventos ajudam a compreensão dos requisitos do
sistema, entretanto, você desejará utilizar os diagramas de
interação para especificar esses fluxos graficamente. Além disso,
você também utilizará um diagrama de seqüência para especificar
o fluxo principal de um caso de uso e variação deste diagrama para
especificar os fluxos excepcionais.



Requisitos

Casos de Uso
Casos de Uso e Formulário:
Os formulários devem ter as seguinte informações:
- Ponto de ativação (momento que caso de uso começa)
- Nome do caso de uso
- Objetivo
- Atores que participam do caso de uso
- Pré-condição
- Fluxo Normal
- Fluxo Alternativo
- Pós-condição.

Opcionalmente podemos acrescentar outros itens ao Formulário de Caso Uso.
Exemplos:
- Nome ou código dos Requisitos (RN e RNF) que estão associados a este caso de uso



Requisitos

Casos de Uso
Exemplos de Casos de Uso:

Manter informações dos
Manter informação de cursos
aluno

Gerente
Gerar catalogo
Manter informação de
professor

Pedir lista dos
matriculados
Sistema de
cobrança
Matrícula nos
Cursos
Professor

Aluno
Selecionar curso
para ensinar



Requisitos

Casos de Uso
Casos de Uso e Formulário
Nome: Fazer Busca Produto
Exemplo: Ponto de ativação: Este caso de uso começa quando entra na página de
Busca e seleciona um item da caixa de seleção
Ator: Visitante e Cliente
Objetivo: Fazer busca de produto por categoria
Pré-condição: Aplicação Disponível
Fluxo Normal:
1 - O visitante seleciona a página de busca
2 - O visitante seleciona a categoria para busca
3 - O visitante informar o produto
4 - O visitante pressiona o botão buscar
5 - O sistema processa a busca
6 - Retorna as informações sobre o produto
Fluxo Alternativo:
1 - O Visitante seleciona a página de busca
2 - O visitante seleciona a categoria para busca
3 - O visitante informar o produto
4 - O visitante pressiona o botão buscar
5 - O sistema processa a busca
6 - Retorna as uma mensagem “produto não encontrado”
Pós-condição: Busca realizada
Requisito Funcional: RF002 -Fazer Busca do Produto
Requisito Não Funcional: ---



Requisitos

Casos de Uso
Elementos dos Caso de Uso:
Ator:
Um ator representa um conjunto coerente de papéis que os usuários de casos de
uso desempenham quanto interagem com esses casos de uso. Geralmente um
ator representa um papel, que pode ser de pessoa, de um sistema ou de um
dispositivo e etc...

Cenários:
É narrativa de determinado fato ou de uma situação.
“O caso de uso deve ser descrito através de cenários. Devem ser construídos tantos
cenários quantos forem necessários para se entender completamente todo o
sistema. Podem ser considerados como teste informais para validação dos requisitos do
sistema.”

Formulário:
É a representação estruturada de um ou mais cenários



Requisitos

Casos de Uso. Relacionamentos
Organização dos Casos de Uso:
Os casos de uso também podem ser organizados pela especificação de relacionamento de
generalização, inclusão e extensão, existentes entre eles. Esses podem ser aplicados com a finalidade
de fatorar o comportamento comum (obtendo esse comportamento a partir de outros casos de uso que
ele inclui) e fatorar variantes (obtendo esse comportamento em outros casos de uso que o estendem)

Generalização:
Entre os casos de uso é parecida à generalização existente entre as classes.
No caso de uso a generalização significa que o caso de uso filho herda o
comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou sobrescrever o
comportamento de seu pai; poderá ser substituído em qualquer local qual o pai apareça.
Include:
Quando você estiver se repetindo em dois ou mais caso de uso separados
devemos evitar a repetição
Extends:
Quando estivermos descrevendo uma variação em comportamento normal, entretanto, querendo
fazer uma descrição mais controlada, explicando os pontos de extensão no caso de uso.
Realizes:
Especifica a colaboração entre os casos de uso

* Use (obsoleto): Especifica que a semântica do elemento de origem depende da
semântica da parte pública do destino. Substituído pelo include.


Requisitos

Generalização:
Podemos usar a generalização entre casos de A generalização também pode ser aplicado aos
uso, pelo mesmo motivo que utilizamos atores e seus respectivos papéis. Veja o exemplo:
nas classes, para compartilhar comportamento:

Receber Pagamento

generalização
Funcionário

Pagto Cartão de Crédito Pagto Cartão de Débito

Gerente de
Recepcionista
Reservas



Requisitos

Extends:
Podemos usa-lo para “Demonstrar Variação de Comportamento”:
Cada uma das extensões descreve as diferentes maneiras com que um passo do
caso de uso pode ser executado. Variação de Comportamento. Exemplo:

Locadora de Automóveis Sala de Conferência

Devolver Veículo Fazer Ligação

Usuário
<<extend>>
<<include>> <<extend>>
<<include>>

Alterar status do carro Consulta Cliente Calcular Multa Fazer Ligação
(Conference call)



Requisitos

Explicando o estereotipo “include”
Um relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora
explicitamente o comportamento de outro caso de uso em uma localização especificada na base.

O caso de uso incluído nunca permanece isolado, mas é apenas uma “instance” como parte de alguma
base maior que o inclui. Você pode pensar na inclusão como o caso de uso base que o obtém o
comportamento a partir do fornecedor do caso de uso. Você utiliza um relacionamento de inclusão para
evitar descrever o mesmo fluxo de eventos várias vezes, incluindo o comportamento comum em um caso
de uso próprio. O relacionamento de inclusão é essencialmente um exemplo de delegação, você coleta
um conjunto de responsabilidades do sistema e o captura um único local (o caso de uso incluído); depois,
permite que outras partes do sistema (outros casos de uso) incluam a nova agregação de
responsabilidade sempre que precisamos utilizar essa funcionalidade.
Exemplos:
Fazer Pedido Fazer Check IN Fazer Check OUT

<<include>> Validar Usuário

Gerenciar Receber
Acompanhar Pedido Pagamento
Reserva <<include>>
<<include>>
<<include>>



Requisitos

Casos de Uso
Casos de Uso - Identificação de Atores

Os atores não fazem parte do sistema - eles representam qualquer um e qualquer coisa
que faça interação com sistema. Podendo ser uma pessoa, software, hardware e etc.

Uma ator pode:
- Apenas fornecer informações ao sistema
- Apenas receber informações do sistema
- Fornecer e receber informações ao sistema

Tipicamente os atores são identificados nas Declarações de Problemas (Documento
de Visão) ou através de entrevistas com os usuários e outros envolvidos no processo,
como, Gerente, Especialista em Negócio, Analista de Sistema e Analista de Negócio,
por exemplo.
As seguintes questões podem ser usadas para identificar o atores:
- Onde o sistema será usado ?
- Quais áreas serão usuárias do sistema ?
- O sistema usará recurso externo ?
- Quem será o responsável pelo sistema ?
- Quem serão os usuários do sistema ?


Requisitos

Casos de Uso.Dicas
Um engano comum na identificação de casos de uso é representar como Caso de uso
passos individuais, operações ou transações.

Exemplo:
No domínio de ponto de venda, alguém pode definir um caso de uso chamado
“Imprimindo o Recibo”, quando de fato, a operação de impressão é meramente um passo
no processo muito mais abrangente do caso de uso Comprar Itens

Lembre-se:

Um caso de uso é uma descrição completa de processo,
que inclui outros passos ou transações.



Requisitos

Especificação de Requisitos. Exemplo:
O hotel contém um número de apartamentos disponíveis para ser alugado aos hospedes. Cada apartamento tem as
seguintes propriedades:
- Número, preços base, capacidade de pessoas
- Tipo (Single, double, triplo ou suite)
O preço de cada apartamento está relacionado com seu tipo e sazonalidades (períodos especiais, tais como: férias, natal,
carnaval...)
Um hospede pode fazer reserva de mais de um apartamentos através do telefone, Internet ou pessoalmente no balcão de
reserva do Hotel .

1 Requisitos Funcionais
2
• Gerenciar Reserva
 •...
Refinado pelo 


Documento de
Visão
„

Documento
de Requisitos



Requisitos


3
Formulário

Cenários

Gerenciar Reserva
Usuário
Caso de Uso
Ator
Associação

Caso de Uso: Gerenciar Reserva



Requisitos

Escrevendo os Cenários:
Cenário 1: Gerenciamento de Reserva:
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos
para data.
O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a reserva.

Cenários O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para
data.
O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento
ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa que não tem
disponibilidade de apartamento para o período informado pelo cliente e oferece um outro tipo de
apartamento.
O cliente aceita o apartamento e então o funcionário confirma a reserva.
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos
para data.
O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa que não tem
disponibilidade de apartamento para o período informado pelo cliente e oferece um outro tipo de
apartamento.
O cliente não aceita a proposta do funcionário e a reserva não é confirmada.



Requisitos

Escrevendo o Formulário:
Compilar os Cenários em Formulário:

Cenários Formulário

Identificando a pré-condição e pós-condição:
Cenário
Gerenciamento de Reserva:

O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva
de apartamentos para data.
Pré- condição ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a
reserva.

Pós- condição


Requisitos

Escrevendo o Formulário:
Compilar os Cenários em Formulário:

Primeiras linhas do cenário
Nome: Gerenciar Reserva
Ponto de ativação: Este caso de uso começa quando o
funcionário do setor de reserva recebe uma solicitação de
reserva
Ator: Funcionário
Objetivo: Fazer reservar de apartamentos
Gerenciar Reserva Pré-condição: Solicitação de reserva
“caminho feliz” Fluxo Normal:

Gerenciar Reserva Fluxo Alternativo:
“caminho alternativo”

Pós-condição: Reserva confirmada

Última linha do cenário



Requisitos

Escrevendo o Formulário de Descrição de Caso de Uso:

Ponto de ativação: Este caso de uso começa quando o funcionário do setor de
reserva recebe uma solicitação de reserva

Ator: Funcionário


Pré-condição: Solicitação de reserva
Fluxo Normal:
O cliente informa o tipo de apartamento
O cliente o período (data de chegada e partida)
O funcionário do Hotel verifica a disponibilidade do apartamento
O funcionário confirma a reserva
Fluxo Alternativo:
...
O funcionário faz proposta de outro apartamento para cliente
O cliente aceita e então o funcionário confirma a reserva




Requisitos


3
Formulário

Cenários

Gerenciar Reserva
Funcionário
Caso de Uso
Ator
Associação

Caso de Uso: Gerenciar Reserva



Requisitos

Mitos e Lendas
• Requisitos não são Casos de Uso;

• Um Caso de Uso pode relacionar mais de um requisito, veja o exemplo:
Caso de Uso Fazer Busca, está associado a dois requisitos:
• (RF) Fazer Buscar
• (RNF) O tempo de resposta para transação deve ser 10 segundos
(Desempenho)



Requisitos

Especificação de Requisitos. Exercício:
Especificação de Requisitos, como fazer:

1 - Identifique quais os REQUISITOS e relacione com os CASOS DE USO;
2 - Identifique também os ATORES e seus respectivos PAPÉIS;
3 - Dê um nome para o CASO DE USO, lembre-se que este nome deve ser único
no modelo;
4 - Escreva os CENÁRIOS para o CASO DE USO;
5 - Compile os CENÁRIOS em único FORMULÁRIO e
6 - Faça o Diagrama de Caso de Uso.



Requisitos

Especificação de Requisitos. Template:
Template do “Formulário”:
Data: ______ | Autor: ________ | Revisão: ____

Nome: <nome do caso de uso>

Ponto de ativação: <informar o ponto de ativação>

Ator: <informar os atores>

Objetivo: <descrever o objetivo>

Pré-condição: <descrever a pré-condição>
Fluxo Normal:
<descrever o fluxo normal>
Fluxo Alternativo:
<descrever o fluxo alternativo>

Pós-condição: <descrever a pós-condição>

RF: <informar os código ou nomes dos RFs>
Rastreabilidade
RNF: <informar os código ou nomes dos RNFs>



Requisitos


Regras de
negócio
de requisitos

Documento de Visão

Usuários e
Clientes
Documento de
Requisitos


Documento de
Especificação
de Requisitos


Requisitos

Validação de Requisitos
Deve preocupa-se em mostrar que os requisitos definem o sistema que o cliente/usuário
deseja.
Validação é importante uma vez que o custo para remover um erro de requisitos é
grande.

Pequeno Check List de Requisitos:

Validade. O sistema fornece as funções que melhor atende as necessidades do usuário?

Consistência. Existem conflitos de requisitos?

Completeza. Todas as funções necessárias para o cliente estão incluídas?

Realismo. Os requisitos podem ser implementados com a tecnologia e orçamento
disponíveis?

Facilidade de verificação. Os requisitos podem ser checados?


Requisitos

Técnicas de validação de requisitos

Revisão de requisitos:
- Análise manual sistemática dos requisitos
Prototipação:
- Uso de um modelo executável do sistema para checar os requisitos.
Geração de casos de teste:
- Desenvolver testes para os requisitos a fim de verificar a “testabilidade”.
Análise automatizada da consistência:
- Uso de ferramenta para verificar a consistência do modelo.



Requisitos

Técnicas de validação de requisitos

Revisão de requisitos:
- Revisões regulares devem ocorrer durante a formulação da definição dos requisitos
- Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revisões
- As revisões podem ser formais (com documentos completos) ou informais. Uma boa
comunicação entre os desenvolvedores, clientes e usuários pode resolver problemas em
estágios iniciais

Verificação de revisões:
- “Verificabilidade”. O requisito é realisticamente testável?
- Compreensibilidade. O requisito é propriamente entendido?
- Rastreabilidade. A origem do requisito é claramente estabelecida?
- Adaptabilidade. O requisito pode ser modificado sem grande impacto sobre outros
requisitos?



Requisitos

Formato do documento de especificação de requisitos sugerido pela IEEE/ANSI 830-1993:

Estrutura do Documento:
1.0 Introdução
1.1 propósito do documento de requisitos
1.2 escopo do produto
1.3 definições, acrônimos e abreviações
1.4 referências
1.5 visão geral do restante do documento
2.0 Descrição geral
2.1 perspectiva do produto
2.2 funções do produto
2.3 características do usuário
2.4 restrições gerais
2.5 suposições e dependências
3. Requisitos (Específicos)
os requisitos podem documentar interfaces externas, descrever funcionalidade e desempenho do
sistema, especificar requisitos lógicos de banco de dados,restrições de projeto, características de
qualidade.
4. Apêndices
5. índice



Análise Conceitual

É apresentar e discutir a Análise Conceitual suas técnicas,
conceitos e modelos.



Workflow de Análise

Objetivo:
Apresentar e discutir como elaborar o Modelo Conceitual (também chamado de modelo de
domínio) e o Vocabulário de Conceitos. Para isto apresentaremos um algumas técnicas
para identificação dos candidatos a classes.

Os objetivos desta etapa são:
1 - Apresentar técnicas para identificação dos candidatos a classes, atributos e
associações;
2 - Elaborar o Modelo Conceitual ou modelo de domínio;
3 - Elaborar o Vocabulário de Conceitos.



Big Picture. Requisitos e Análise
Caso de Negócio Coleta de Requisitos Foco Análise Conceitual
Modelo Conceitual
Documento
de Visão

4

Glossário de
conceitos

Casos de Uso

Requisitos Não



Workflow Analise

Analise
Arquitetura Modelo Conceitual ou Modelo
de Domínio
Analista de Sistema
Analista de Requisitos
Arquiteto de Software
Vocabulário do Sistema

Modelo de Arquitetura Inicial




Introdução:
Modelo de Casos de Uso de software é elaborado para dar a Visão de Caso de Uso.
Esta visão fornece uma perspectiva do software a partir de um ponto de vista externo.
Os aspectos dinâmicos descrevem a troca de mensagens entre os objetos e a sua
reação a eventos que ocorrem no software. O aspecto dinâmico será apresentado na
terceira parte, no workflow de Projetos.

Visão da
Visão de
Implementação
Funcionalidade Projeto Codificação
Vocabulário Montagem
Visão de Caso de
Uso
Gerenciar Reserva Visão do Visão da Implantação
Funcionário Desempenho Processo Topologia do Sistema

O aspecto estrutural estático permite entender como uma software está estruturado
internamente para atender os requisitos (visão externa).
Esse aspecto é chamado de estático porque não apresenta informações sobre como os
objetos se comportam no ciclo de vida de software e também porque representa a estrutura
das classes de objetos e os relacionamentos entre elas.




Atividades.Road Map

Fazer Análise Conceitual
Caso de Uso
Modelo Conceitual

Fazer Vocabulário
Documento de
Visão Vocabulário

Definir o modelo de
Arquitetura





Análise Conceitual. Introdução:
“Modelo Conceitual. É o artefato mais importante da Análise Orientada a Objetos”

O modelo representa conceitos relevantes (do ponto de vista do modelador) do domínio
do negócio. Estes conceitos também são chamados de Chaves da Abstração.
“A chave da abstração é uma classe ou objeto que faz parte do vocabulário do
domínio do problema” (Booch).

Na UML, esta fase é representada com os diagramas de estruturas estáticas:
- Caso de Uso
- Digrama de Classes (na verdade o Modelo Conceitual).

Os objetivos são:

1 - Apresentar técnicas para identificação dos candidatos a classe classes, atributos e
associações e
2 - Elaborar o Modelo Conceitual ou Modelo de Domínio.




Atividade: Fazer Análise Conceitual

Caso de Uso
Modelo Conceitual

Documento de
Visão




Análise Conceitual. Modelos:
O modelo de classe têm pelo três níveis de abstração:

- Modelo Conceitual de Classes: Representa as classes no domínio do
desenvolvimento do software, este modelo pertence a Workflow de Análise. Por
definição, um modelo de classes de domínio não leva em consideração restrições
referente à tecnologia a ser utilizada na solução do problema. Este modelo também
conhecido como “Modelo de Classes de Domínio”.

- Modelo de Classes de Especificação: É derivado do Modelo Conceitual. Com
acréscimos de detalhes, tais como, tipo de dado, operações (métodos),
implementação de associações, generalização, agregação e composição e
incremento de novas classes para que se fazem necessária para dar uma solução ao
problema.
Exemplo:
Classes associativas. Este modelo é desenvolvido no Workflow de Projeto.




Análise Conceitual. Modelos
- Modelo de Classes de Implementação: É derivado do modelo de especificação e
corresponde a implementação das classes em alguma linguagem de programação,
como Java, C#, C++ por exemplo. O modelo de implementação é construído na Fase
de Design (Desenho)
Workflow de Análise Workflow de Design

Pessoa
Pessoa
-nome
nome -idade
idade
<<refines>> +setNome()
+getNome()
+getIdade()
+getIdade()

Modelo Conceitual ou Modelo de Classes de
Modelo de Domínio Implementação ou
Modelo de Especificação




Análise Conceitual. Atividades e Passos:


Identificar os candidatos
a classe

Selecionar uma técnica

Fazer a Lista de
Candidatos

Desenhar o Modelo
Conceitual

4

Definir a Arquitetura
Inicial




Análise Conceitual. Identificação das Classes:
Um software orientado a objetos é composto de uma coleção de objetos que colaboram
para realizar seus requisitos. Entretanto, sabemos que os objetos são “instances” das
classes.
Para identificar as classes, podemos usar um método simples. O primeiro passo é fazer
uma lista de todas classes que encontramos, esta lista pode ser chamada de “Lista de
Classes Candidatas”.
E depois usando algum critério, eliminamos as classes irrelevantes e aí teremos uma lista
definitiva. Existem dois métodos principais para realizar a identificação das classes de
domínio de um software:
- Método dirigido a dados:
Neste método, a ênfase está na identificação da estrutura dos conceitos
relevantes para o domínio do negócio, resultando em Modelo Conceitual.
Exemplo: Inspeção Gramatical
- Método dirigido a responsabilidades:
Neste método, a ênfase está na identificação de classes a partir de seus
comportamentos relevante ao sistema. Este método também resulta em
Modelo Conceitual.
Exemplo: CRC




UML. Introdução
A UML deve ser utilizada para criar o Modelo Conceitual. Os modelos visuais ajudam
a compreender melhor o sistema que estamos construindo.

A seguir será apresentado os “nodes, elementos e adornos usados para construir o
modelo.




Diagrama de Classes. Introdução
O Diagrama de Classes nasce no Workflow de Análise com Modelo Conceitual (modelo de
domínio), mais tarde no Workflow de Design (Desenho) este o modelo será refinado
ganhando adornos, novos tipos de relacionamentos, operações (métodos) e até novas
classes.

Agora faremos apenas o Modelo Conceitual que podemos considerar como o primeiro
“esboço” do que mais tarde se tornará o Diagrama de Classes.




UML. Elementos:
Elementos estruturais:
Classe, Interface, Colaboração, Caso de Uso, Classe Ativa, Nó e Componente
Elementos de agrupamento:
Pacote e Subsistema




UML. Elementos:
• Dependência
• Associação
– Associação
– Composição
– Agregação
• Generalização
Mecanismos de Extensibilidade:
• Estereótipo
• “Tagged value”
• Restrição (Constraint)




Diagrama de Classes

O diagrama de classes deve
capturar o Vocabulário* do
sistema




Associação
Definição de Associação:
Um relacionamento estrutural que descreve um conjunto de vínculos, em que o vínculo
é uma conexão entre objetos; relacionamento semântico entre dois ou mais
classificadores que envolve as conexões entre seus objetos.
Associação classe
classe
Usuario Senha

Nome de Associação:
Uma associação pode ter um nome, que pode usado para descrever a natureza do relacionamento.
Podemos ainda acrescentar um triângulo para demonstrar a direção do nome, ou seja, a direção que
nome deve ser lido.
Nome da associação
Direção do nome

faz
Cliente Pedido

Observação:
Apesar da possibilidade de a associação ter um nome, não é necessário incluí-lo. Recomendamos o uso do nome quando o modelo possui muitas associações e você tem a
necessidade de fazer referência às associações ou de destacá-las.




Associação (Navegação e Role Name)
Navegação:
Indica qual é a direção da associação. A direção da associação pode ser unidirecional (onde somente uma
das pontas da linha de associação tenha a seta) ou bidirecional (não existem setas em nenhum dos lados)

Associação
Navegação

Cliente Pedido

Definição de Role Name:
É um identificador (nome) do papel da associação, podendo cada ponta ter um nome especifico.

Modificadores:
(+) public | (-) private | (#) protected




Multiplicidade
Definição:
A especificação de uma faixa de números cardinais, que um conjunto pode assumir.

Eqüivale a muitos

Multiplicidade Faixa Válida:
0....1 | 0..* | * | 1 | 1..*

O que é uma multiplicidade ?
Uma associação representa um relacionamento entre dois objetos. Em algumas situações de
modelagem, é importante especificar a quantidade de objetos que podem ser conectados pela
“instance” de uma associação.
Essa “quantidade” é chamada de multiplicidade do papel de uma associação e é escrita como uma
expressão equivalente a um intervalo de valores ou de uma valor explícito.




Role Name e Multiplicidade
Exemplo:

Multiplicidade
Para cada objeto (instance) da classe Pessoa a classe
Empresa poder ter uma ou muitos objetos.




Análise Conceitual. Técnicas:

Abbot Kent Beck UML

Inspeção Análise de
CRC
Gramatical Caso de Uso
Scott Ambler
Graig Larman
Peter Coad

Outras
Técnicas



Modelo Conceitual. Técnica: Inspeção Gramatical
Introdução:

A primeira etapa na construção do Modelo Conceitual é identificar os conceitos (idéias ou
coisas). Podemos achar os candidatos a classe com a identificação de substantivos
(Inspeção Gramatical).

É uma técnica útil, por causa da simplicidade, proposta por Abbot. Consiste em identificar
os substantivos no texto da Declaração de Problema/Declaração de Visão e considerá-los
como candidatos a classe ou conceitos.




Técnica: Inspeção Gramatical
Lista de Candidatos:

Conhecimento do Negócio Interações

Declaração de
Visão 1º Lista Lista Final

Identificação dos Fazer revisão da lista:
candidatos a classe, Eliminar conceitos os repetidos,
associações e atributos ambíguo, irrelevantes e etc..



Artefatos:

Modelo Conceitual
Lista de Candidatos

4

Vocabulário de Conceitos





Nome da associação
Classe

Reserva Cliente
1..* feita por 1
numero id
data-entrada hospede nome
data-saida documento
Atributo 0..*

Multiplicidade
Apartamento
1..*
numero
tipo
situacao
Associação




Modelo Conceitual. Técnica: Inspeção Gramatical - Exemplo
Declaração do Problema:

O cliente solicitou o desenvolvimento de software para apoiar uma rede bancária
computadorizada incluindo caixas humanos e máquinas de auto atendimento (ATM) a ser
compartilhada por um consórcio de bancos. Cada banco provê seu próprio computador
para manter suas contas e processar transações sobre elas. Os caixa automáticos são
propriedade dos bancos e se comunicam diretamente com os computadores de seus
bancos proprietários. Os caixas humanos introduzem dados sobre as contas e
transações. Os caixas eletrônicos comunicam-se com um computador central que liquida
as transações com os bancos adequados. Um caixa automático receber cartão
magnéticos, interage com o usuário, comunica-se com o sistema central para executar
transações, entrega de dinheiro e impressão de extratos.
O sistema exige um adequado arquivamento de registros e reservas de segurança. O
sistema deve manipular corretamente acessos concorrente à mesma conta. Os bancos
devem prover seu próprio software para seus próprios computadores; devemos projetar o
software para as ATM e para a rede. O custo do sistema compartilhado deve ser
distribuído pelos bancos de acordo com número transações realizadas.




Identificando do Domínio:
(Técnica usada: extração dos substantivos do enunciado do problema)

Fazer transações eletrônica através de caixa de
Auto atendimento e caixas




Identificando os conceitos:
Software Rede Bancária Caixa

ATM Consórcio Banco

Computador do Banco Conta Transação

Terminal do caixa Dados de contas Dados de transações

Computador Central Cartão Magnético Usuário

Dinheiro Extrato Sistema

Manutenção do Reserva de segurança Acesso
arquivo de Registro

Preço Cliente

Classes da ATM originadas do conhecimento do domínio do problema
Linha de Comunicação Registro de transação




Identificando os conceitos:
Após a revisão identificamos o seguinte:

Conceitos vagos:
Sistema, Reserva de Segurança, Manutenção do arquivo de Registro e Rede Bancária

Atributos:
Dados de contas, extrato, dinheiro e dados de transações

Conceito redundante:
Usuário

Conceito Irrelevante:
Preço

Conceito de implementação:
Registro de Transação, Acesso, Software e Linha de Comunicação
Eliminado às classes apontadas, ficamos com as seguintes conceitos válidos:
Conta, ATM, Banco, Computador do Banco, Cartão Magnético, Caixa Terminal do Caixa, Computador
Central, Consórcio, Cliente e Transação




Identificando as Associações:

Qualquer dependência entre duas ou mais conceitos é uma associação. Uma referência
de uma classe a outra é uma associação.
As associações muitas vezes correspondem a verbos estáticos ou a locuções verbais.
Isso inclui localização física:
- junto a, parte de, contido em e etc
Ações indiretas:
- direciona, comunica-se (fala a), propriedade (tem, parte de), ou satisfação de alguma
condição (trabalha para, casado com, gerencia).
Tente identificar as associações, lembre-se que nem todas, estão explicitas, pode haver
muitas transações implícitas e algumas associação dependem do conhecimento do
mundo real, ou seja, do negócio.
Extraia todas as candidatas do enunciado do problema e as escreva em uma lista, e
depois refine-as.





Lista (Frases verbais):
Rede de bancária inclui caixas e ATM
Consórcio compartilha ATM
Banco provê computador do banco
Computador do banco mantém contas
Computador do banco processa transações contra a conta
Banco possui terminal de caixa
Terminal de caixa comunica-se com o computador do banco
Caixa introduz transação para a conta
ATM comunica-se com computador central sobre transação
Computador central liquida transação com banco
ATM aceita cartão magnético
ATM interage com usuário





Lista (Frases verbais):
ATM entrega o dinheiro
ATM imprime extrato
Sistema manipula acesso concorrente
Bancos fornecem software
Custo repartido pelos bancos

Frases Verbais implícitas:
Consórcio compõem-se de bancos
Banco mantém conta
Consórcio possui computador central
Sistema provê arquivamento de registros
Sistema provê segurança
Clientes possuem cartões magnéticos

Conhecimento do domínio do problema:
Cartão magnético permite acesso a contas
Banco emprega caixas




Identificação dos conceitos dos atributos:

Os atributos são propriedades de objetos individuais, como nome, peso, altura,
velocidade, cor e etc.
Os atributos não devem ser objetos; utilize uma associação para demonstrar qualquer
relacionamento entre dois objetos.
Os atributos geralmente correspondem a substantivos seguidos por frases possessivas,
por exemplo: “a cor do carro” ou “o número da conta”.
Os adjetivos muitas vezes representam valores de atributos específicos e enumerados,
como vermelho sobre ou expirado. Diretamente das classes e associações, os atributos
têm menos probabilidade de serem integralmente descritos no enunciado do problema.
Devemos valer-se de nosso conhecimento do domínio da aplicação e do mundo real
para encontrá-los. Lembre-se que os atributos raramente afetam a estrutura básica do
problema.




Identificação dos conceitos dos atributos:

Os atributos derivados devem ser omitidos ou claramente rotulados, como: idade é
derivado de data de nascimento e data atual (que é uma propriedade do ambiente). Os
atributos derivados como os objetos e associação derivadas podem ser úteis na
abstração de propriedade significativas de uma aplicação, mas devem ser distinguidos
nitidamente dos atributos básicos, que definem o estado do objeto. Os atributos
derivados não devem ser expressos como operações, como obter-idade, embora
possam eventualmente ser implementados como tais.
Os atributos de ligação também devem ser identificados. Um atributo de ligação é uma
propriedade da ligação entre dois objetos e não a propriedade de um objeto
isoladamente. Por exemplo: a associação muitos-para-muitos entre Acionistas e
Empresa tem o atributo de ligação número de ações. Os atributos de ligação às vezes
são tomadas erradamente por atributos de objetos.




Modelo Conceitual vs Modelo de Especificação

Workflow de Análise Workflow de Design

Transacao Transacao

Datahora Datahora:Timestamp
+getTransacao()
+setDataHora()
+getDataHora()

Conceito de Classes
classes e atributos




Modelo Conceitual:




Técnica: CRC (Cartão de Responsabilidade e Colaboração)
Método dirigido a responsabilidades:
Neste método, a ênfase está na identificação das classes a partir de seus comportamentos
relevante ao sistema.
Técnica Cartão (CRC):
O CRC foi apresentado por Kent Beck e Ward Cunningham em artigo chamado:
"A Laboratory for Teaching Object-Oriented Thinking" no OOPLSA '89.

Conceito e Aplicação:

CRC (Cartão Responsabilidade e Colaboração) é um cartão índice que é usado para
representar as responsabilidades das classes e suas interações com outras classes.
O cartão CRC é uma abordagem informal do modelo de orientação a objetos.
Os cartões são criados através de cenários, baseado nos Requisitos, que modela o
comportamento do sistema.

Observação:
O CRC não faz parte da UML. Mas é uma técnica recomendada, pela sua simplicidade,
principalmente para quem tem pouca experiência com orientação a objetos.




Técnica CRC. Responsabilidades e Colaborações:
Em sistema orientado a objetos, os objetos encapsulam os dados e os comportamentos.
O comportamento de um objeto é definido de tal forma que ele possa cumprir com as
responsabilidades. Uma responsabilidade é uma obrigação que um objeto tem para como
sistema no qual ele estará inserido.
Através das responsabilidades, um objeto colabora com outros objetos para que os
objetivos sejam alcançados.
Podemos considerar que uma responsabilidade é alguma coisa que objeto deve conhecer
ou que ele deve saber fazer.
Em alguns casos, um objeto tem uma responsabilidade com qual ele não pode cumprir
sozinho. Nesses casos, o objeto deve requisitar uma colaboração com outros objetos do
software para cumprir com sua responsabilidade.

Objeto

Colaborações:
Responsabilidades:
(o que objeto conhece e o que faz) + (outras classes que são associadas,
para a interação entre os objetos)




CRC. Elementos:
O nome do cartão é o mesmo nome da classe, as responsabilidades são as coisas que a
classe dever saber fazer e/ou coisas que ela deve conhecer.

As colaborações as informações que a classe precisa e que está alocada em outra classe,
desta forma temos que fazer o relacionamento entre classes, para que ela
cumpra com sua responsabilidade.
Modelo:

Nome da Classe
Responsabilidades: Colaborações:

Lista das responsabilidades Lista de colaborações

Melhores Práticas:
Os candidatos a classe cujo a responsabilidade não foi encontrada, logo este candidato
deve ser descartado. Pois, não podemos ter classe sem nenhuma responsabilidade.



CRC. Exemplos:

Classe: Reserva
Conhecer o período da reserva
Apartamento
(datas)
Cliente
Saber o nome do cliente
Saber o número do apartamento

Classe: Cliente

Saber o nome do cliente Reserva
Saber a Reserva do Cliente




Técnicas: Inspeção Gramatical & CRC
1 2 3
Inspeção Gramatical CRC UML

Lista de Candidatos Classe: Cliente


Classe: Cliente Reserva

Reserva
Classe: Cliente


Reserva

Identificação dos candidatos Identificação das Responsabilidade Modelo Conceitual




Técnica: Análise de Caso de Uso:
Análise começa com verificação do Modelo de Caso de Uso, Diagrama, Cenários e
Formulários e a Lista de Requisitos Funcionais. Nesta análise é identificado os candidatos
a classe.

Formulário

Cenários

Usuário
Gerenciar Reserva
Caso de Uso Listas de Candidatos
Ator Associação




Análise de Caso de Uso. Big Picture
Documento de Visão 4 Lista de
1 Candidatos


3 (Visão de Caso de Uso)
Lista de Requisitos
Funcionais Formulário

2

Cenários

Casos de Uso
Lista de Requisitos
Não Funcionais
Usuário Gerenciar Reservas
Ator Associação



Análise de Caso de Uso: Identificando os candidatos a classe
Como fazer. Diagrama:
1 - Verifique os nome dos Casos de Uso, eles geralmente contêm bons candidatos.

Usuário
Gerenciar Reserva Reserva é provável candidato a classe

<<include>>

Atualizar Reserva Buscar Apartamento

Funcionário <<include>>
Criar Reserva Cadastrar Cliente prováveis candidatos a classe

Remover Reserva




Análise de Caso de Uso: Identificando os candidatos a classe
Como fazer. Cenários:
2 - Os cenários devem usados para identificação dos candidatos. Ache os substantivos,
exemplo:
Cenários:
Gerenciar de Reserva:

O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva
de apartamentos para data.
ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa
Cenários que não tem disponibilidade de apartamento para o período informado pelo cliente e
oferece um outro tipo de apartamento.
O cliente não aceita a proposta do funcionário e a reserva não é confirmada.

Prováveis candidatos a classe




Análise de Caso de Uso: Atividades
Como fazer. Formulário:
3 - Os Formulários também devem usados para identificação dos candidatos. Ache os
substantivos, exemplo:
Ponto de ativação: Este caso de uso começa quando o funcionário do setor de
reserva recebe uma solicitação de reserva
Ator: Funcionário
Formulários
Pré-condição: Solicitação de reserva
Fluxo Normal:
O cliente informa o tipo de apartamento
O cliente o período (data de chegada e partida)
O funcionário confirma a reserva
Fluxo Alternativo:
...
O funcionário faz proposta de outro apartamento para cliente
O cliente aceita e então o funcionário confirma a reserva


Prováveis candidatos a classe



Técnicas: Análise de Caso de Uso e CRC
1 2 3
Análise de Caso de Uso CRC UML

Lista de Candidatos Classe: Cliente

Classe: Cliente Reserva

Reserva
Classe: Cliente

Reserva

Identificação dos candidatos Identificação das Responsabilidade Modelo Conceitual




Dicas: Scott Ambler
Para encontrar as classes, vejamos algumas dicas:

1 - Considere que as classes são lugares, eventos, conceitos, pessoas e etc.
2 - Atores são classes em potencial;
3 - Identifique os clientes;
4 - Siga o dinheiro, podemos identificar produtos, serviços, eventos como venda,
compra e etc;
5 - Conceitos são classes em potencial;
6 - Eventos são classes em potencial e
7 - Entende o negócio.

Use a técnica CRC para atribuir ou descobrir as responsabilidades e colaborações
das classes encontradas




Dicas: Graig Larman
Larman sugere a que a identificação dos substantivos, que são os candidatos a classe ou
conceitos seja feito através dos Casos de Uso “expandidos”, pois, eles fornecem uma
excelente descrição a serem usadas como fontes para este tipo de análise.
Exemplo:

Exemplo de Caso de Uso expandido:

Seqüência típica de eventos:
1 - Este caso de uso começa quando um Cliente chega a um ponto de venda e deseja
comprar alguns itens.
2 - O Caixa registra o código do produto de cada item
...

Entretanto, esta técnica exige uma ou mais revisão nos conceitos encontrados, pois,
diferentes substantivos podem representar o mesmo conceito.




Dica: Graig Larman
Larman também sugere usar uma abordagem de Categoria de Conceitos, que nada mais
é que uma lista de categorias. Após determinar lista use-a para identificar os conceitos.
Exemplo de lista:

Categoria Exemplos
Objeto físico ou tangível Terminal de ponto-de-venda
Avião

Especificação, projeto, ou descrição de coisas Especificação de produto
Descrição de vôo

Lugares Loja
Aeroporto

Transações Venda, Pagamento
Reserva

Itens de transação Itens de venda
Parcelas de pagamento

Papéis de pessoas Operador
Piloto




Dica: Graig Larman
Identificação dos Conceitos:
Abaixo um exemplo de identificação dos conceitos a partir dos Formulários dos Casos
de Uso:

Ação do Ator Resposta do Sistema
1. Este caso de uso começa quando
um Cliente chega no caixa com itens
para comprar. 3. Determina o preço do item e
2. O Operador registra o identi-ficador adiciona informação sobre o item à
de cada item. transação de venda em anda-mento.
Se há mais de um do mesmo item, o Mostra a descrição e o preço do item
Operador também pode informar a corrente.
quantidade.




Dica: Peter Coad
A Proposta de Coad & Yourdon:
O método Análise Orientada a Objetos, proposto por Peter Coad e Yourdon e denominado
OOA (Object Oriented Analysis), consiste basicamente em cinco passos:

1 - Localização de classes-&-objetos: entende-se por objetos como a abstração de alguma
coisa, em um domínio de problema, cujas informações devam ser manipuladas pelo
sistema. Uma classe corresponde ao conjunto de objetos semelhantes.
2 - Identificação de estruturas: que podem ser classificadas em:
Generalização-especialização: quando uma classe é um tipo de uma outra classe.
Exemplo: a classe carro é uma especialização da classe veículos;
Todo-parte: quando uma classe é formada por outras classes. Exemplo: as classes
motor e chassis fazem parte da classe carro.
3 - Definição de assuntos: onde cada qual se relaciona a diferentes partes do modelo,
permitindo minimizar a complexidade de projetos extensos.




Dicas: Peter Coad
A Proposta de Coad & Yourdon

4 - Definição de atributos: um atributo é definido como uma propriedade, uma qualidade
ou uma característica de um determinado objeto. Um atributo consiste em alguns dados
(informações de estado) através dos quais cada objeto em uma classe tem seu próprio
valor. Atributos comuns a todas as subclasses (especializações) de uma classe são
apenas listados na classe e, automaticamente, estendidos para as suas subclasses.
Uma conexão de ocorrência representa relacionamentos entre objetos.
5 - Definição de Serviços: um serviço é um comportamento específico que um objeto
deve exibir. Um serviço altera o estado de um objeto. Serviços pertencentes a todas
subclasses são definidos apenas na classe. Os serviços implícitos, tais como incluir,
remover, alterar e selecionar instâncias, não são apresentados no diagrama. Uma
conexão de mensagem representa a comunicação entre objetos, onde um “emissor”'
envia uma mensagem para um “`receptor'', para a realização de algum processamento.




Vocabulário.Road Map:

Caso de Uso
Modelo Conceitual

Fazer Vocabulário
Documento de
Visão Vocabulário




Vocabulário:

Fazer Vocabulário

Descrever os conceitos
Fazer Vocabulário:
Devemos fazer um Vocabulário de todas as classes presente no Modelo Conceitual.
O vocabulário consiste em simples descrição do conceito.

Transacao

Datahora
Transação – Uma única solicitação integral para operações nas
contas de um único cliente. Especificamente somente que as ATM
podem entregar dinheiro, mas não podemos eliminar a
possibilidade da impressão de cheques ou de receber dinheiro ou
cheques. Também queremos prover a flexibilidade de operar as
contas de diferente clientes, embora isso não seja exigido. As
diferentes operações devem fechar apropriadamente.




Modelo Conceitual.




Vocabulário. Exemplo:
Vocabulário:

ATM – Uma estação que permite os clientes fazerem suas próprias transações utilizando
cartões magnéticos como identificação. A ATM interage com o cliente para obter
informações sobre transações, envia as informações sobre transações para o
computador central para validação, processamento e entrega de dinheiro ao usuário no
caso de uma transação de saque. Presumimos que uma ATM não necessita operar
independente de rede.

Banco – Uma instituição financeira que mantém contas de clientes e emite cartões
magnéticos autorizando o acesso às contas através da ATM.

Caixa – Um empregado do banco autorizado a fazer transações nos terminais de caixa e
a receber, entregar dinheiro e cheques aos clientes. As transações, o dinheiro e os
cheques manipulados por cada caixa devem ser registrados e devidamente
contabilizados.




Vocabulário:

Cartão Magnético – Cartão vinculado a um cliente do banco que autoriza o acesso às
contas utilizando uma máquina ATM. Cada cartão contém um código de banco e um
número de cartão, codificados de acordo com os padrões definidos pelo Banco Central
sobre cartões de créditos e cartões magnéticos.
O código do banco identifica inequivocamente o banco dentro do consórcio.
O número do cartão determina as contas a que cartão pode ter acesso. Um cartão não
necessariamente dá acesso a todas as contas do cliente.
Cada cartão pertence a um usuário cliente, mas podem existir múltiplas cópias dele, de
modo que a utilização simultânea do mesmo cartão em diferentes máquinas deve ser
considerada.

Cliente – Possuidor de uma ou mais contas em um banco. Um cliente pode ser uma ou
mais pessoas ou corporações; a correspondência não é relevante para este problema. Se
uma pessoa possui conta em um diferente banco é considerada cliente diferente.




Vocabulário:

Computador Central - Computador operado pelo consórcio que despacha transações entre as ATM e
os computadores dos bancos. O computador central valida códigos de bancos mas não processam
transações diretamente.

Consórcio – Organização de bancos que comissiona e opera a rede ATM. A rede só manipula
transações do consórcio.

Conta – Única conta no banco contra a qual as transações podem ser aplicadas. As contas podem ser
de vários tipos (conta corrente ou conta de poupança). Um cliente pode manter mais de uma conta.

Terminal de caixa – Terminal no qual os caixas fazem transações para os clientes. Os caixas
entregam a recebem dinheiro e cheques; a impressora do terminal imprime extratos. O terminal do
caixa comunica-se com o computador central do banco para validar e processar transações.

Transações – Uma única solicitação integral para operações nas contas de um único cliente.
Especificamente somente que as ATM podem entregar dinheiro, mas não podemos eliminar a
possibilidade da impressão de cheques ou de receber dinheiro ou cheques.




Diagrama de Objetos
Introdução:
Bem o última coisa a fazer neste Workflow é a validação do Diagrama de Classes (Modelo Conceitual).
Podemos fazer esta validação utilizando o Diagrama de Objetos e os Casos de Uso. Desta forma
estaremos garantindo que o Diagrama de Classes feito atende os requisitos.

Diagrama de Objetos, é um diagrama estrutural, que demonstra um conjunto de objetos e seus
relacionamentos em determinado instante (tempo).
Sua principal aplicação é demonstrar as estruturas de dados, registros estáticos das “instances” dos itens
encontrados no diagrama de classe.
O diagrama de objetos direcionam a visão estática do projeto ou de processo de um sistema.
O Diagrama de Objetos também podem conter pacotes ou subsistemas, notas e restrições.
Exemplo da notação:

:Nome do Objeto

Atributo: Valor do atributo
objeto

Nome do Objeto
vínculo
Atributo: Valor do atributo




Diagrama de Objetos
Recomendamos o uso do Diagrama de Objetos para validar o Diagrama de Classes.
Exemplo:

Diagrama de Classe Diagrama de Objetos
Aluno :Aluno
Nome da -Nome: String Nome: “Fulano de Tal”
associação -Data: Date Data: 23-02-2001
Nome do
“Instance” objeto
objeto

Matricula 201-23-02-01:Matricula
-Matricula: int Matricula: 201-23-02-01 vinculo
-Curso: String Curso: Adm Empresas

Atributo Valor do atributo




Diagrama de Objetos
Conteúdo do Diagrama de Objetos:
Objetos e Vinculo

Diagrama de Objetos
objeto :Aluno
Nome: “Fulano de Tal”
Data: 23-02-2001

201-23-02-01:Matricula
Matricula: 201-23-02-01 vínculo
Curso: Adm Empresas Um vínculo é uma conexão semântica
existente entre os objetos.
Em geral, um vínculo é uma “instance”
de uma associação.
Desta forma um objeto pode enviar uma
mensagem para outro.




Diagrama de Objetos
Como fazer a modelagem de um estrutura de objetos:
Como posso
• Identifique o mecanismo cuja modelagem você deseja fazer. Um mecanismo
validar o
representa algum requisito ou comportamento da parte do sistema cuja a
diagrama de
modelagem você está fazendo e que é resultante da interação de um conjunto
classes?
de classes, interfaces e outros itens.
• Para cada mecanismo, identifique todos os itens (classes, interfaces e outros
elementos) que participam nessa colaboração e seus relacionamentos.
• Leve em consideração somente um cenário capaz de percorrer esse
mecanismo. Congele o cenário em determinado momento e represente cada
objeto que participa do mecanismo.
• Exponha o estado e os valores dos atributos de cada um desses objetos,
conforme seja necessário, para compreensão do cenário.
• De maneira semelhante, exponha os vínculos existentes entre esses objetos,
representando as “instance” de associação entre eles.




Arquitetura Inicial.Road Map

Caso de Uso
Modelo Conceitual

Fazer Vocabulário
Documento de
Visão
Vocabulário

Definir o modelo de
Arquitetura

(Requisitos não funcionais) Modelo de Arquitetura




Modelo de Inicial de Arquitetura
Definir o Modelo de
Arquitetura Definir o Modelo de
Arquitetura Inicial

Podemos criar um Modelo de Arquitetura Inicial para aplicação. O objetivo deste modelo é apresentar
uma visão macro da arquitetura. Os modelos de Caso de Uso, Modelo Conceitual e os Requisitos
Não Funcionais são utilizados para desenhar este o modelo.

Uma visão inicial da arquitetura pode ter muita formas, podemos utilizar a UML para representar este
modelo ou qualquer outra notação. Este modelo será refinado no workflow de projeto na Atividade
“Fazer o Modelo de Arquitetura”.

Camada de Camada
Camada Banco de
serviço regra de
apresentação Dados
4

(controle) negócio




Desenho (design) do Modelo de
Especificação de Software
É apresentar e discutir o desenho (modelo de especificação)
seus conceitos, técnicas e modelo.



Workflow de Design (Desenho)

Objetivo:
Apresentar e discutir o Workflow de Design (Desenho), também conhecida como “Fase de
Especificação”, agora faremos uso da intenso da UML para fazer os modelos (diagramas)
e a documentação.

As principais atividades são:
- Construção do Modelo de Especificação (Projeto)
- Construção do Modelo de Arquitetura
- Fazer validação do modelo.




UML Visões: 4 + 1

Visão de Visão da
Codificação
Vocabulário
Visão de
Caso de Uso
Visão do Visão da

Conceitual Físico



Introdução. Aspectos: Estáticos e Dinâmicos
O Workflow de Análise é determinado pelo “aspecto estrutural estático”, que permite
entender como uma software está estruturado internamente para atender os requisitos.

Esse aspecto é chamado de estático porque não apresenta informações sobre como os
objetos se comportam no ciclo de vida de software e também porque representa a estrutura
das classes de objetos e os relacionamentos entre elas.

No Workflow de Design, faremos a modelagem dos aspectos dinâmicos do sistema, estes
aspectos são capturados em digramas (diagrama de interação, diagrama de estados e
diagrama de atividades).
E assim podemos representar os comportamentos internos e desta forma teremos novas
visões do software e aí conseguiremos compreender melhor o software.




Introdução. Aspectos: Estáticos e Dinâmicos
UML. Principais Diagramas:

Modela a estrutura do sistema Modela o comportamento do sistema

ESTÁTICOS DINÂMICOS
. Diagrama de Classes . Diagrama de Casos de Uso
. Diagrama de Objetos . Diagramas de Interação
. Diagrama de Componentes - Diagrama de Seqüência
. Diagrama de Distribuição - Diagrama de Colaboração
. Diagrama de Atividade
. Diagrama de Estados

Workflow de Análise Workflow de Projeto




Introdução
A Workflow de Projeto depende da Workflow de
Análise:

Workflow de Análise Análise

dependência

Workflow de Projeto Projeto




Introdução
A Workflow de Design refina a Workflow de
Análise:
Workflow de Análise Workflow de Projeto
modelo conceitual Diagrama de Classes
Atributos:
Cliente Cliente Tipo de dados

codigo -codigo: int
<<refine>>
nome -nome: String
+getCodigo()
+setCodigo()
Atributos: +getNome()
Visibilidade
+setNome()
métodos




Big Picture. Projeto
Análise Design (Visão Lógica)

Modelo Conceitual Diagrama de Classes

4

Receber Pedido

4


Entrega


Receber Pagamento


Especificação de Requisitos a noite

: visitante

getDescricao( )

exibirCategoria( )

selecionarCategoria

exibirProduto( )
Encerrar Pedido





Arquitetura
Arquitetura Diagrama de Seqüência /
Colaboração
Analista de Sistema
Projetista de Software
Arquiteto de Software

Diagrama de Estados

Diagrama de Classes





Atividades.Road Map

Fazer Modelo de Especificação
Caso de Uso
Modelo de Especificação

Fazer Modelo de Arquitetura
Modelo
conceitual
Modelo de Arquietura




Projeto. Atividades e Passos:

Fazer Modelo Especificação

Identificar as classes de
Especificação
Fazer Diagrama de
Interação

Fazer a Diagrama de
Atividades / Estados*

Refinar o Modelo
de Classes

Modelo de
Especificação




Casos de Uso. Revisão
Uso caso de uso descreve “o quê” um sistema faz, ele não especifica “como” isso é feito.
Ao fazer uma modelagem, importante manter clara a separação de questões entre a visão
interna e externa. “O como” é modelado pelo Diagrama de Interação (Diagrama de
Sequência).

“O quê” <<include>>
selecionar categoria

buscar produtos Diagrama de Sequência
“O como”
visitante

Diagrama de Estado : visitante

getDescricao( )

exibirCategoria( )

selecionarCategoria

exibirProduto( )

Formulário




Diagrama de Interação. Introdução
Diagrama de Interação são modelos que descrevem como grupos de objetos colaboram
para atender comportamento.
Tipicamente, um diagrama de interação captura o comportamento de um único caso de
uso. O diagrama deve mostrar os vários objetos e as mensagens que são passadas entre
estes objetos.

Existem dois tipos de diagramas:

• Diagrama de Seqüência:
O foco deste diagrama é maneira que as mensagens são enviadas ao longo do tempo.

• Diagrama de Colaboração:
Aqui o foco é o relacionamentos estrutural entre os objetos de uma interação e então
considerar como as mensagens são passadas no contexto dessa estrutura.




Diagrama de Interação
O que é Diagrama de Seqüência?
É um diagrama que exibe a colaboração dinâmica entre objetos de um sistema. O
principal aspecto deste diagrama é que a partir dele percebe-se a seqüência de
mensagens enviadas entre os objetos. Ele mostra a interação entre os objetos e os
eventos que acontecem em um ponto específico da execução do sistema.

Notação:
Diagrama de Seqüência

:Objeto 1 :Objeto 2

Ator: 1: mensagem 1

2: mensagem 2

3: mensagem 3




Diagrama de Seqüência: Exemplo 1




Diagrama de Seqüência: Exemplo 2

formulários de formulário de cursos
registro matrícula disponíveis

entrar com senha de
acesso
validar acesso

Aluno:
entrar com o
semestre

criar nova matrícula
apresentar em tela

obter cursos




Diagrama de Seqüência. Elementos:
Instance das classes
ator

: Cliente : Veiculo : Locacao
: Atendente

getDadosCliente( )

[* se cliente cadastrado
verificar divida ]
getDivida( )

getDisponibilidade( )
setSaida( )
[* se veículo
disponível ]

Autodelegação

As interações entre os Restrição ou
Linha do tempo objetos condição




Diagrama de Seqüência. Numerando as seqüências das mensagens.

: visitante

1: getDescricao( )

2: exibirCategoria( )

3: selecionarCategoria
4: getDescricao( ) 5: getQuantidade( )

6: exibirProduto( )

7: selecionarProduto( )

Este diagrama descreve em ordem cronológica as mensagens entre os objetos.




O que é Diagrama de Colaboração?
É um diagrama que mostra a colaboração dinâmica entre os objetos, semelhante ao
diagrama de seqüência.
No diagrama de colaboração, além de mostrar a troca de mensagens entre os objetos,
percebe-se também as colaborações dos objetos.
A interação de mensagens é mostrada em ambos os diagramas.
Diagrama de Colaboração tem a maioria de suas características semelhantes ao
Diagrama de Seqüência.

Quando usar o diagrama de Colaboração ?
Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o
diagrama de seqüência, mas se a ênfase for relacionamentos estrutural
entre os objetos de uma interação, é melhor dar prioridade ao diagrama
de colaboração. Podemos também escolher ambos.
Diagrama de Seqüência é mais usual.




O que é Diagrama de Colaboração ?
O diagrama de colaboração é desenhado como um diagrama de objeto, onde os diversos
objetos são mostrados juntamente com seus relacionamentos. As setas de mensagens
são desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As
mensagens são nomeadas, que entre outras coisas mostram a ordem em que as
mensagens são enviadas. Também podem mostrar condições, interações, valores de
resposta, e etc. O diagrama de colaboração também pode conter objetos ativos, que
executam paralelamente com outros.
Exemplo:
Diagrama de Colaboração 2: validar acesso
1:entrar com chave 3:entrar com o
de acesso semestre

formulários de registro
4:criar nova matrícula
Ator (José)
5:apresentar
em tela

cursos disponíveis formulário de matrícula
6:obter cursos




Projeto. Atividades e Passos:

Fazer Modelo Especificação

Identificar as classes de
Especificação
Fazer Diagrama de
Interação

Fazer a Diagrama de
Atividades / Estados*

Refinar o Modelo
de Classes

Modelo de
Especificação




Diagrama de Estado
O que é Diagrama de Estado?
É um diagrama que tipicamente complementa a descrição das classes. Pois, este
diagrama exibe todos os estados possíveis que objetos de uma certa classe podem se
encontrar. Mostra também quais as variações de comportamento provocam tais
mudanças.
Não necessário escrever o diagrama de estado para todas as classes de um sistema,
mas, apenas para aquelas que possuem um número definido de estados conhecidos e
onde o comportamento das classes é afetado e modificado pelos diferentes estados.
Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas.

Aplicação:
Um diagrama de estado pode ser aplicado a diversos elementos da UML, tais como:
- Classes e Casos de Uso




Diagrama de Estado
Elementos:

O diagrama de estado são compostos de transições e estados. As transições são
associadas com ações e são consideradas como processo de curta duração e não
podem ser interrompidos. Os estados são associados com as atividades e podem levar
mais tempo. Uma atividade pode ser interrompida por algum evento.

Verificando

Estado Transição

Início do fluxo Final do fluxo




Diagrama de Estado
Exemplo 1:

início

transição

fora do gancho

ocioso Ativo

no gancho

Estado




Diagrama de Estado
Exemplo 2:

on
Inicializa o
Objeto Lamp
On
Espera por
Evento on/print(”on”)
Trata
Evento
off
off
Lamp
Off
Finaliza
Objeto
stop




Diagrama de Estado
Exemplo 3: (Completo)
[Nem todos os itens verificados]/pegar
próximo item
início

[Todos os itens verificados e
Verificando
os todos itens disponíveis] Expedindo

[itens ecebidos
[Todos os itens [alguns itens não
verificados e estão disponíveis]
alguns itens não Item recebido
estão disponíveis] [os todos itens
disponíveis]
Aguardando cancelamento

cancelado

Cancelamento Entregue

final




Diagrama de Estado
Exemplo: Caso de Uso e Diagrama de Estado

Cliente

Autenticar Diagrama de Estado
Senha

Consultar Verificando Status [Pedido não entregue] Mudando Status
Pedido

Gerenciar <<extends>> Cancelando Pedido
Pedido
Cancelar
Pedido
<<include>>

UpdateStatus Logistica
Funcionário Confirmar Pedido
Pedido




O que é Diagrama de Atividade?

É um diagrama que exibe o fluxo seqüencial das atividades, é geralmente utilizado para
demonstrar as atividades executadas por uma operação específica do sistema, como por
exemplo seleção de um item do menu principal.
Consistem em estados de ação, que contém a especificação de uma atividade a ser
desempenhada por uma operação do sistema. Decisões e condições, como execução
paralela, também podem ser representados no diagrama de atividade.
O diagrama também pode conter especificações de mensagens enviadas e recebidas
como partes de ações executadas.
Diagrama de Atividade capturam ações e seus resultados. Eles focam o trabalho
executado na implementação de uma operação (método), e suas atividades numa
“instance” de um objeto. O diagrama de atividade é uma variação do diagrama de estado
e possui um propósito um pouco diferente do diagrama de estado, que é o de capturar
ações (trabalho e atividades que serão executados) e seus resultados em termos das
mudanças de estados dos objetos.




Elementos e Exemplo comentado:

responsabilidades

Cliente Vendas Estoque
Atividade

atividade
Fazer Pedido atividade

transição Processar Pedido

separação Separar Produtos

Enviar Pedido

decisão

Receber Pedido Cobrar Cliente

Pagar Fatura
Barras de
sincronização Fechar Pedido

junção
Elementos
raias



Os estados no diagrama de atividade mudam para um próximo estágio quando uma ação é
executada (sem a necessidade de especificar nenhum evento).
Outra diferença entre o diagrama de atividade e o de estado é que podem ser colocadas como
swimlanes (raias). Uma swimlane agrupa atividades, com respeito a quem é responsável e onde
estas atividades residem na organização, e é representada por retângulos que englobam todos os
objetos que estão ligados a ela (swimlane).
Um diagrama de atividade é podemaneira alternativa de se mostrar interações, com a possibilidade
Um diagrama de atividade uma ser usado com diferentes propósitos inclusive:
de expressar como as ações são executadas, o que elas fazem (mudanças dos estados dos objetos),
 Para capturar os trabalhos (seqüência das ações), e onde elas acontecem (swimlanes).
quando elas são executadas que serão executados quando uma operação é disparada (ações). Este
é o uso mais comum para o diagrama de atividade.
 Para capturar o trabalho interno em um objeto.
• Para mostrar como um grupo de ações relacionadas podem ser executadas, e como elas vão afetar
os objetos em torno delas.
• Para mostrar como uma “instance” pode ser executada em termos de ações e objetos.
 Para mostrar como um negócio funciona em termos de trabalhadores (atores), fluxos de trabalho,
organização, e objetos (fatores físicos e intelectuais usados no negócio).
Diagrama de Atividades não é orientado a objetos, na verdade ele é muito semelhante a um
fluxograma.




Exemplo 1:
Receber Pedido


Entrega
Receber Pagamento

a noite

Encerrar Pedido




- Quando utilizar Diagrama de Atividade:

Como a maioria das técnicas de modelagem comportamental, os diagramas de
atividades têm qualidades e deficiências, a melhor forma de usá-lo é a combinado com
outras técnicas.
A maior qualidade dos diagramas de atividades está no fato que eles suportam e
encorajam comportamento paralelo.
Isso faz que ele possa ser utilizado como uma ferramenta para modelagem de “workflow”,
e, em princípio, para programação concorrente.
A desvantagem destes diagramas é que eles não deixam muito claro as ligações entre as
ações e objetos.
Você pode definir uma ligação para um projeto rotulando uma atividade com um nome
de objeto ou usando raias que dividem uma diagrama de atividades em base em
responsabilidades, mas, isso não tem a clareza simples de diagramas de interação.




Quando utilizar Diagramas de Atividades:

Podemos utilizar diagrama de atividade nas seguintes situações:
- Analisando um caso de uso: Neste estágio, não estamos interessados em alocar ações aos
objetos; precisamos simplesmente compreender que ações precisam acontecer e quais são
as dependências comportamentais.
- Compreendo workflow: Os diagramas de atividades são muito úteis para compreensão de
um processo de negócio.
- Descrevendo um algoritmo sequencial complicado: Neste caso, um diagrama de
atividades é simples “flowcharts” em notação UML.
- Modelando processamento paralelo: Podemos usar o diagrama de atividades para modelar
aplicações de processamento paralelo.

Quando não é indicado:
- Tentando ver como os objetos colaboram: O diagrama de interação é mais indicado.
- Tentando ver o comportamento de objeto durante se ciclo de vida: Neste caso o
diagrama de estado é o mais indicado.




Diagrama de Classes. Introdução
Apresentaremos e discutiremos o Diagrama de Classes, ele é considerado o artefato mais
importante e é que também exige mais esforço para ser construído.
O Diagrama de Classes é derivado do Modelo Conceitual (Workflow de Análise)
Agora no Workflow de Design o modelo é refinado ganhando adornos, novos tipos de
relacionamentos, métodos e até novas classes.

Esta atividade tem a seguinte divisão, a qual chamamos de refinamento, são quatro
passos. A cada passo faremos alguns refinamentos no modelo. Também será definido
alguns conceito durante estes passos.




Diagrama de Classe. Revisão:
• O diagrama de classe é um elemento estrutural




Diagrama de Classe. Exemplo:




Diagrama de Classe. Revisão:
Refinamentos:
1 - Refinamento: 2 - Refinamento:
Atributos: Acrescentar tipos de dados e visibilidade Acrescentar: outros tipos de relacionamento entre as classes
exemplo: codigo exemplo: agregação, composição, herança
Acrescentar outros elementos como: Seta de navegação, Role
-codigo: int (private int codigo)
Name (papéis) e multiplicidade

Pessoa
nome
Fase de Análise Fase de Projeto
modelo Diagrama de
Atributos:
conceitual Classes
Tipo de dados e
Cliente Cliente Visibilidade Pedido Cliente
Data Relacionamento
codigo -codigo: int cpf Herança
<<refine>> Status
nome -nome: String codigo
Numero
1
+getCodigo()
1..n item
+setCodigo()
+getNome() ItemPedito
+setNome()
Quantidade
métodos




Diagrama de Classes. Refinamento
1 - Refinamento:
Exemplo: Atributos e Métodos:

modelo conceitual Diagrama de Classes Atributos:
Tipo de dados e
Cliente Cliente Visibilidade
codigo -codigo: int
<<refine>>
nome -nome: String
+getCodigo()
+setCodigo()
+getNome()
+setNome()
+getCliente() métodos




1 - Refinamento:
Atributos: Acrescentar tipos de dados e visibilidade e métodos.
exemplo: codigo
-codigo: int (private int codigo)
Método: Definir os Métodos
Cliente
Cliente -codigo: int
codigo <<refine>> -nome: String
nome +getCodigo()
+setCodigo()
Atributos:
Tipo de dados e Visibilidade +getNome()
métodos




2 - Refinamento:
Acrescentar: outros tipos de relacionamento entre as classes
exemplo: agregação, composição, herança
Acrescentar: Navegação, Role Name (papéis) e Multiplicidade
Pessoa Pessoa Relacionamento
Herança
nome <<refine>> cpf
nome

cliente
PessoaFisica PessoaFisica
codigo codigo Role name
cpf




Herança, Agregação, Composição, Associação
Herança: É mecanismo baseado em objetos
que permite que as classes compartilhem
atributos e operações baseados em um
relacionamento, geralmente generalização Herança
Podemos dizer que Pós-
Graduação é tipo de Curso
Curso
Uma classe derivada herda a estrutura de Universitário
Universitário, assim como
Curso de Especialização ou
atributos e métodos de sua de Extensão.
extends
classe “base”, mas pode seletivamente:
• adicionar novos métodos
Graduação Pós-Graduação
• estender a estrutura de dados
• redefinir a implementação de métodos já extends
existentes
Especialização Extensão
Uma classe “pai” proporciona a funcionalidade
que é comum a todas as suas classes
derivadas, filhas, enquanto que uma classe
derivada proporciona a funcionalidade
adicional que especializa seu comportamento.




EspecialidadeMédica generalização

Tipo de Tipo de
especialização
Ortopedia Pediatria

ContaBancaria

Tipo de Tipo de
ContaCorrente ContaPoupança




Herança:
Quais associações são inválidas:

Figura Cartao TipoPagamento

Tipo de Tipo de
CartaoCredito CartaoDebito
Retangulo Circulo
Tipo de

Tipo de

Ponto




Diagrama de Classes Avançado. Refinamento
Refinamentos:
3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador), 4 - Refinamento:
Acrescentar: Classes Associativas, Interfaces e Dependência
associações reflexivas e Constraint (restrições)
CPF <Interface>
-cpf Pessoa
getCPF() -nome: String
setCPF() +getNome()
+setNome()
{ idade > 18}

Sociio
CPF Cliente -codigo: int
-cpf Livro
-codigo: int * -idade: int
getCPF() -isbn *
setCPF() { idade > 18} -nome: String -titulo +getCodigo()
-idade: int +setCodigo()
getISBN()
+getCodigo() setISBN() +getIdade()
+setCodigo() setTitulo() +setIdade()
Emprestimo
+getNome() getTitulo()
+setNome() -data
+getIdade() -status
+setIdade() getData()
setDAta()
setStatus()
getStatus()




3 - Refinamento:
Acrescentar: Associação Qualificada (qualificador),
Associação Qualificada
É um equivalente da UML de um conceito de programação conhecido como vetores,
árvores binárias, maps ou dicionários.
Qualificador é um atributo da associação cujo os valores particionam o conjunto de
objetos relacionados a um objeto da associação.
Aplicação:
Redução de semântica da associação. Também pode ser usado como índice para hash
ou vetor, isto quando, precisamos ter recurso de pesquisa em uma das extremidades da
associação.
Nome da
Classe associação
0..1
Classe
qualificador
atributos papel papel atributos




3 - Refinamento:
Associação Qualificada

0..1
ItemPedido
Pedido Produto
Linha de item quantidade: int

Qualificador

O exemplo, demonstra uma associação qualificada, entre as classe Produto,
ItemPedido. O qualificador diz que em associação com Pedido poder haver um item
de pedido cada ocorrência de produto. Conceitualmente, esse exemplo indica que não
é possível existir dois itens de pedido com pedido para o mesmo produto. Para fazer
acesso a um item de pedido em especifico, é necessário identificar o produto como
argumento.



3 - Refinamento:
Associações Reflexivas e Constraint (restrições)
Associação Reflexiva
Uma associação reflexiva (também conhecida como auto-associação) liga objetos da
mesma classe. Cada objeto tem um papel distinto nesta associação.

papel Nome da associação
1
Classe
*

papéis
Em uma associação o uso dos papéis é importante para evitar ambigüidade na
interpretação da associação. Uma associação reflexiva não indica que um objeto
se associa a si próprio (um empregado não é gerente dele mesmo; uma condição
não é pré-requisito dela mesma). Associação reflexiva indica que um objeto se
associa com outros objetos da mesma classe.



3 - Refinamento:
Associação Reflexiva:
Exemplo
Supervisão

Supervisor 1
Empregado
*

Supervisionado

Neste exemplo existe uma associação reflexiva objetos de Empregado. Nesta
associação, há objetos que assumem o papel de supervisor e outros objetos que
assumem o papel de supervisionado. O nome da associação pode ser omitido, uma vez
que os papéis foram definidos.



3 - Refinamento:
Constraint (restrições):
Uma restrição é um relacionamento semântica entre elementos de modelo que
especifica condições que devem ser satisfeitas.
Classe { restrição } 0..1
Classe
atributos papel papel atributos

Duas opções para representar restrições em UML:
• Informal, a UML permite usar qualquer notação para representar as restrições,
entretanto , as estas devem ser especificadas dentro de chaves “{ }”, podemos usar a
linguagem formal, por exemplo.
• Formal, UML fornece linguagem formal de restrições de objetos. (OCL - Object
Constraint Language).
Veja mais: http://www.omg.org/technology/documents/formal/ocl.htm



3 - Refinamento:
Constraint (restrições):
Por ser um mecanismo de extensão da UML, certos tipos de restrições já estão
definidos, tais como: complete, destroyd, disjoint, implicit, incomplete, new, or
overlapping e transient.
Veja o exemplo: da restrição Contrato
“ou”.
atributos

{ ou }

0..1 0..1
Pessoafisica PessoaJuridica
atributos atributos




4 - Refinamento:
Classe Associativa
Em associação entre duas classes, a própria associação poderá ter propriedades.
Essas propriedades são originadas a partir da associação de classes com a
multiplicidade de: muitos:muitos, para expor a representação destas propriedades é
implementado uma nova classe que é resultante da associação, assim como seus
atributos e métodos.
Classe * *
Classe
atributos atributos

Nome da Associação Classe de Associação
atributos




4 - Refinamento:
Classe Associativa
Exemplo

Associação de muitos:muitos
Produto * * Fornecedor
atributos atributos

ProdutoFornecido Classe de associação

atributos




4 - Refinamento:
Interface:
O que é interface ?
(Representa a forma mais pura de abstração de dados - Linguagem Java)
Interface é um contrato entre o cliente, onde o cliente pode ser classe concreta ou
abstrata. Este contrato é garantia que o métodos assinados na interface serão
implementados na classe cliente.
O relacionamento entre uma interface e uma classe é chamada de realização.

<<interface>> Estereotipo e
nome da interface
Nome Interface
Métodos (assinatura)
Assinatura do
métodos

Nota: Na interface também podemos declarar constantes (public static final).



4 - Refinamento:
Interface:
Exemplo
Interface, realização e classes
<<interface>>
PessoaJuridica
getCNPJ()
setCNPJ() Realização
setContrato()
getContrato()

Fornecedor PrestadorServico
atributos atributos




4 - Refinamento:
Dependência:
Uma dependência é um relacionamento de utilização, determinando as modificações
na especificação de um item, mas não necessariamente o inverso.
Utilizamos o relacionamento de dependência no contexto das classes para mostrar que
uma classe usa outra como argumento na assinatura de uma operação.

FilmClip
play(c: Channel)
Channel
start()
stop()
pause()

dependência



Workflow de Projeo (Desenho)
Design

Diagrama de Classes. Outros conceitos: Granularidade
Granularidade:

Geralmente para cada atributo criamos um par de métodos getter e setter, estes
métodos garantem o encapsulamento dos dados. Entretanto, quando estamos em um
ambiente distribuído (de rede), fazer a manipulação de vários e métodos e atributos,
um a um, pode causar um péssimo desempenho, temos que considerar latência de
rede, tempo de IO (input/output) e etc.

Para evitar esta situação podemos criar um método chamado getCliente(), que
contempla todos os dados do cliente, desta forma estaríamos fazendo um única
requisição.

Desta forma temos a seguinte estrutura granular:

Granularidade Grossa: Manipulação através de único método que encapsula todos os
atributos da classe.

Granularidade Fina: Cada atributo é manipulado por um par de método especifico.




Diagrama de Classes. Granularidade
Granularidade: Exemplo

Cliente
-codigo: int
Granularidade Fina
-descricao: String
+getCodigo()
+setCodigo()
Granularidade Grossa +getDescricao()
+setDescricao()
+getCliente()




Diagrama de Classes. Construtores:
O que são construtores?
Construtores são um tipo especial de método usado para inicializar uma “instance” da classe.
Toda a classe deve ter um Construtor. Quando não declaramos o “Construtor default”, que é
inicializado automaticamente pelo Java. Mas existem casos que se faz necessário a declaração explícita
dos construtores.
Cliente Tipo
- codigo: int -descricao: String
- nome: String
- tipo: Tipo +getDescricao(): String
<<construtores>> +setDescricao(d: String)
+Cliente(codigo: int, nome: String) dependência
+Cliente(codigo: int, nome: String, tipo: Tipo)

<<métodos>>
+ getCodigo(): int
+ getNome(): String
+ setCodigo(int codigo)
+ setNome(String nome)
+ getTipo(): Tipo
+ setTipo(tipo Tipo)
+ getCliente(): String




Restrição:
O Construtor não pode ser herdado. Para chamá-lo a partir de uma subclasse usamos a referência
super.

Para escrever um construtor, devemos seguir algumas regras:
1ª O nome do construtor precisa ser igual ao nome da classe;
2ª Não deve ter tipo de retorno;
3ª Podemos escrever vários construtores para mesma classe.

public class Mamifero {
private int idade;

public Mamifero(int idade)
{
this.idade = idade; construtor
}

//Métodos
}




Quantos construtores pode ter uma classe ?
Uma classe pode ter vários construtores, entretanto, eles devem seguir a regra de
overloading;

Posso ter construtores com mesmo nome, mas com a lista de argumentos diferente
(quantidade de argumentos, tipos de dados, ordem e etc)

public class Mamifero {
private int idade;

public Mamifero(int idade)
{
this.idade = idade;
} construtores
public Mamifero()
{
}
//Métodos
}




Diagrama de Classes. Propriedades:
Propriedades dos Atributos:
Existem três propriedades definidas que poderão ser utilizada como os atributos:

- Changeable: Não há restrições para se modificar o valor do atributo.

- addOnly: No caso de atributos com multiplicidade maior do que um, valores adicionais
poderão ser incluídos, mas uma vez criado, o valor não poderá ser removido ou alterado.

- Frozen: O valor do atributo não pode poderá ser modificado depois que o objeto for
iniciado

TaxaJuro
- valor: double {frozen}

<<métodos>>
+ getValor(): double Propriedade
+ setValor(double valor)




Diagrama de Classes. Delegação:
Definição de Delegação:
A habilidade de um objeto enviar uma mensagem a outro objeto como resposta a uma
mensagem.
O reúso de propriedades de uma classe pode ser realizado não só através do mecanismo
generalização entre as classes, mas também através do mecanismo de delegação.
O reúso por generalização se baseia na estrutura de superclasse e subclasse, onde a
subclasse herda todos os métodos e atributos da classe “pai” (superclasse).
Recomendamos usar o mecanismo de delegação em algumas situações:
• Para não violar regra de encapsulamento;
• Para não sobrecarregar de responsabilidade uma classe;
• Para atender a semântica da classe e
• Favorecer o mecanismo de reúso.

A seguir veremos um exemplo completo, onde a aplicação do mecanismo de delegação
é melhor solução para obedecermos as regras da orientação a objetos.




No Modelo Conceitual devemos identificar os candidatos a classe e seus respectivos
conceitos. Entretanto, devemos antes lembrar da definição da classe.

Classe
A descrição de conjunto de objetos que compartilham os mesmos atributos, operações,
relacionamento e semântica.

Temos a primeira sugestão do modelo, a classe Cliente fazendo uma associação a Senha.

Cliente Senha
possui
codigo senha
nome




Em segunda sugestão de modelo, a classe Cliente tem como atributo senha, desta forma
a classe Senha não seria necessário.

Cliente
codigo Quais são as implicações
nome que o atributo “senha” pode
senha causar ao modelo ?




Ao modelarmos devemos ter os seguintes cuidados:

1 - Identificar todas classes que fazem uso ou que tem um determinado atributo,
neste caso, Cliente e Funcionário tem o atributo “senha”. Isto deverá estar explícito
no documento “Domínio do Problema”. Veja o exemplo:

Conceito diferente

Cliente Funcionario
codigo codigo-funcional
nome nome
senha senha

O mesmo conceito




Ao modelarmos devemos ter os seguintes cuidados: (continuação)

- Uma sugestão para solução do problema:

Pedido Cliente Funcionario
codigo codigo-funcional
nome nome

HistoricoCliente possui Senha possui
senha





2 - Uma vez que senha é um atributo de cliente como podemos implementar regras de
negócio a senha, se implementarmos dentro da classe Cliente, teríamos um erro de
conceito (semântica). Veja o exemplo:

Cliente
codigo
nome
senha Este atributo somente é regra
qde_dias_expiracao_senha que se aplica somente a senha e
não a cliente.




3 - Reúso:
- O atributo senha poderá ser utilizado por outra aplicação, que nem sempre deverá
ver os outros atributos de cliente.

Cliente
codigo
nome
senha

Podemos concluir, que no exemplo apresentado duas regras da orientação a
objetos foram violadas:
- Semântica e
- Baixo reúso




Mitos e Lendas
O que é dito:
- Modelo de entidade e relacionamento (MER), deve ser feito antes do diagrama de
classes.

Entretanto, a realidade é outra...

Quando estamos a metodologia de orientação a objetos os dados são
encapsulados. Assim o “MER” deve ser derivado do modelo de
classes.



Arquitetura de Software

É apresentar e discutir Arquitetura de Software, conceitos
modelos e técnicas



Workflow Arquitetura

Objetivo:
Apresentar e discutir a Arquitetura de Software. Arquitetura é parte do Workflow de Design
(Desenho), nesta fase criamos os componentes, modelos físicos e como serão distribuídos.
Os principais diagramas UML são:
- Diagrama de Deployment e
- Diagrama de Componentes.

Também nesta fase refinamos o Modelo de Arquitetura. Objetivo primário da arquitetura é
atender os requisitos não funcionais. O artefato deste passo é:
- Modelo de Arquitetura.




Big Picture. Arquitetura
Design (Visão Lógica)
Diagramas Arquitetura
Projeto (Visão de Componentes e
Visão de Deployment)

4

Receber Pedido

: visitante

getDescricao( )

Entrega
exibirCategoria( )

selecionarCategoria [pedido urgente] [senão]
Receber Pagamento

exibirProduto( )

a noite

Encerrar Pedido




Arquitetura
Arquitetura
Digrama de Componentes

Analista de Sistema
Projetista de Software
Diagrama de Deployment Arquiteto de Software





Introdução. UML, Visões:

Visão de Visão da
Codificação
Vocabulário
Visão de
Caso de Uso
Visão do Visão da

Conceitual Físico



Modelo de Inicial de Arquitetura
Na Análise fizemos um o Modelo de Arquitetura Inicial para aplicação. O objetivo deste
modelo é apresentar uma visão macro da arquitetura.
Os modelos de Caso de Uso e Modelo Conceitual são utilizados para desenhar este o
Modelo de Arquitetura.
Uma visão inicial da arquitetura pode ter muita formas, podemos utilizar a UML para
representar este modelo ou qualquer outra notação.
Este modelo será refinado no Workflow de arquitetura na Atividade “Refinar o Modelo
de Arquitetura”.
Passos:
1 - Selecionar o Modelo de Arquitetura
2 – Refinar o Modelo de Arquitetura Inicial.




Decomposição e Camadas
Decomposição:

A decomposição refere-se à fragmentação de uma aplicação ou sistema em partes
menores e lógicas facilitando gerenciamento da complexidade. Os módulos, os
subsistemas e componentes são bom exemplo de decomposição.
A decomposição ajuda a definir e a esclarecer as interfaces entre as diferentes partes de
um sistema. Também pode ser útil nas situações em que você tem de integrar com o
sistemas legados e ou aplicações de terceiros (externas).
A decomposição pode também auxiliar na distribuição do software em diversos
processadores.
A decomposição ajuda na distribuição de responsabilidades e papéis na equipe de
desenvolvimento.

As desvantagens:
As decomposições inadequadas ou excesso pode levar facilmente a uma grave
degradação do desempenho devido ao “overhead” de comunicação.

Na UML a decomposição pode ser representada através do diagrama de pacotes e
subsistemas.



Workflow de Arquitetura

UML. Diagrama de Pacotes
Como podemos definir o diagrama de pacotes?
A definição de Pacote é uma generalização, ou seja, um agrupamento, com o propósito de
organizar as Classes de Objetos em grupos. Esta abordagem facilita a análise a medida
que o número de Classes de Objetos cresce num do cenário. O tipo de relacionamento é
linha pontilhada com uma seta que indica dependência. Os diagramas de pacote podem
ser usados para fazer decomposição funcional.
A notação usada pela UML para representar pacotes é:

Nome do Nome do
Pacote Pacote

Nome do Pacote

Nome do
Pacote
Dependência
(import)



UML. Diagrama de Pacotes
Decomposição. “Dividir para conquistar...”
Algumas aplicações podem ser enormes ou ter um grau muito alto de complexidade ou
ambas as coisas. Para facilitar é necessário fazer uma decomposição.
A idéia da decomposição é simples. É fazer uma divisão para simplificar o entendimento, a
modelagem ou processo de desenvolvimento de um software.
Veja o exemplo abaixo:

Contas a Fluxo de
Pagar Caixa

Nome do Pacote
Subsistema

Contas a
Receber
Dependência




Separação em camadas
Camada:
Uma aplicação de grande escala pode ser complexo e difícil de desenvolver e gerenciar.
A camada é um padrão para a decomposição. A decomposição leva uma fragmentação
lógica do sistema em subsistemas e módulos, e as camadas agrupam e separam esses
subsistemas, assim limitando quem pode usar os subsistemas, componentes e módulos.
O Rational Unified Process (RUP) ou simplesmente UP identifica duas abordagens para a
camada:
- Camada baseada em responsabilidade e
- Camada baseada em reúso.
Camada baseada em responsabilidade:
Estas as camadas são bem definidas, significando que cumprem um papel específico no
esquema geral das coisas. Tais camadas também são conhecidas como níveis.

Níveis:
Os níveis podem ser mapeados para as camadas baseada em responsabilidades, neste
caso um nível torna-se sinônimo de cumprir um papel específico no sistema, como a
apresentação, a lógica de negócio e etc.
Uma arquitetura baseada em níveis facilitam a manutenção, disponibilidade e separação
de funcionalidades e de papéis de uma aplicação



Separação em camadas
Níveis:
A forma de se conseguir a distribuição em arquitetura com n níveis é alinhar as camadas
específicas com cada nível, exemplo:
- O nível de cliente, lida com a interação com usuário
- O nível de apresentação, lida com apresentação dos dados
- O nível de negócio, contém as regras de negócios e as entidades
- O nível de dados, fornece a interface para armazenamento de dados

<<tier>> <<tier>> <<tier>> <<tier>>
Cliente Apresentação Negócios Dados




Pattern. Model View Controller
Aplicação do MVC (Model, View e Controller)

O padrão MVC originou da linguagem Smalltalk e foi usada para projetar interfaces com
usuário. Esta interface é divida em três partes: model, view e controller.
Onde:
Model: Representa o dado ou objeto. Ele é que manipula e objetos, exemplo: JavaBeans
e EJB (Linguagem Java).
View: É visão de como os dados serão apresentados, exemplo: páginas JSP e ASP
Controller: Recebe as requisições, faz validação e define o model que manipulará os
dados.
Algumas vantagens do MVC:
- Decomposição;
- Reúso;
- Possibilita o desenvolvimento em paralelo;
- Separação de responsabilidades e papéis;
- Isolamento e separação das camadas e
- Baixo acoplamento.
MVC podem ser implementado de duas maneiras o modelo 1 e modelo 2, como
veremos a seguir.




Model View Controller. Model 1
Model 1: O cliente faz uma requisição para uma página dinâmica (JSP ou ASP) que pode
chamar um model (componente) ou outra página dinâmica que faz algum processamento
e devolve para cliente a resposta

View View View

Web Server Model




Model View Controller. Model 2
Model 2: O cliente faz uma requisição para a camada controller que redireciona para
camada model que executa algum processamento e retorna para controller que gera uma
página dinâmica (JSP ou ASP) que é devolvida como a resposta ao cliente

View View View

Controller
Web
Componentes (Model) Server



Model View Controller
Aplicação do MVC em ambiente de três camadas (Web)

View:
Visão representa a apresentação (interface com usuário) de uma aplicação. O componentes
da View obtém os valores do estado do Model.

Separação do View e do Model habilita a construção independente interfaces com
diferentes “Look and Feel” (aparências - skins). Diferentes Views podem interagir
com mesmo model. JSP é escolha natural para implementação do View

Controller:
O Controller fornece a ligação da arquitetura MVC. Ela é responsável por receber as
requisições e determinar qual o Model apropriado para atende-la. Ele também poder
tratar a resposta.




Model View Controller
Aplicação do MVC (Model, View e Controller)

Model:
O modelo representa as regras de negócios de uma aplicação. Encapsulando as regras
dentro de um componente facilita os testes, melhora a qualidade e promove o reúso de
componentes.
Estado do componentes (model):
O estado define um conjunto de valores do Model e inclui métodos para mudar estes
valores. Estes métodos são regras de negócios e outros métodos.

O “estado” de componente são geralmente um protocolo independente. Na
tecnologia Java os JavaBeans e os EJBs são uma boa escolha para implementar
estes componentes.
Na tecnologia .Net (Microsoft) podemos usar os componentes COM+




Introdução:
O papel do Arquiteto:
Os softwares podem ter arquitetura e ambiente simples, ou seja, “rodar” um único servidor
e em diversas estações clientes em ambiente de rede local.
Atualmente, os softwares podem ter uma arquitetura mais complexa, ou seja, eles podem
ser distribuídos, ou seja, rodar em uma rede distribuída, com diversos servidores, quando
alocamos algum recurso remotamente (componentes, por exemplo), temos que garantir o
funcionamento (desempenho) deste software é missão mais difícil e até critica.

O papel do “Arquiteto de Software” é garantir o funcionamento do software e atendimento
pleno dos Requisitos Não Funcionais (Desempenho, “Escalabilidade”, Confiabilidade,
Segurança e etc) e das Restrições, como uso de determinada tecnologia (protocolos,
linguagens de programação, banco de dados e etc)
As responsabilidades do Arquiteto de Software:
- Selecionar uma tecnologia adequada e projetar um modelo robusto, flexível e eficiente.
- Propor um plano de redução de risco.Um ambiente complexo tem um risco maior, cabe ao
Arquiteto desenvolver um plano para redução de risco.
- O Arquiteto também deve sugerir o uso de Patterns de Arquitetura que são as boas
práticas para a construção do Modelo.




Princípios:
Existem diversos princípios que podemos aplicar a arquitetura de software, entretanto
existem dois que se destacam:
- Separação de Camadas e
- Princípio da Dependência Inversa.




Arquitetura.Road Map

Modelo de Digrama de
Especificação Deployment
Documentos Fazer Diagramas
de Requisitos Digrama de
Componentes

View Controller Model Resources

Modelo de
Fazer Modelo de Arquitetura
Arquitetura Inicial Banco de
JSP/HTML Servlet EJB
Dados

Caso de Uso




Arquitetura. Atividades e Passos:

Fazer Modelo Arquitetura
Selecionar uma
Arquitetura

Fazer Diagrama de Digrama de
Modelo de Deployment
Arquitetura Inicial Deployment

Fazer Diagrama de Digrama de
Componentes Componentes

Refinar Modelo de
Arquitetura (RNFs)

Refinar o Modelo
de Especificação



O que é Diagrama de Deployment?
Variações tradução:
• Diagrama de Deployment <=> Diagrama de Implantação
• Diagrama de Deployment <=> Diagrama de Distribuição

É um diagrama que exibe a arquitetura física do hardware e do software no sistema.
Pode apresentar os computadores e periféricos, juntamente com as conexões que eles
estabelecem entre si. Podemos mostrar também os tipos de conexões entre esses
computadores.
Especifica-se os componentes executáveis e objetos que são alocados para exibir quais
unidades de software são executados e quais computadores.
O diagrama de deployment demonstra a arquitetura “runtime” de processadores,
dispositivos físicos e de software que executam no ambiente onde o sistema
desenvolvido será utilizado. É o último diagrama da topologia do sistema, descrevendo
a estrutura de hardware e software que executam em cada unidade.




Elementos:

Processor (Processador): É qualquer máquina que possua a capacidade de
processamento. Os servidores, estações de trabalho por exemplo.

Servidor

processador

Device (Dispositivo): É qualquer máquina com finalidade ou finalidade limita. Os
dispositivos são os itens como impressoras, roteadores, raids, storages, scanners,
leitoras de código de barra e etc.
Impressora

Dispositivo



Elementos:
Connection (conexão): A conexão é o vinculo entre processadores e dispositivos.
Geralmente representam as conexões de rede físicas (rede local ou distribuída).

estereotipo

Servidor
Cliente <<TCP/IP>>

<<RS 232>>

Processador
Impressora (Nó)
conexão

Dispositivo
(Nó)




Elementos:
Os processadores e os dispositivos podem ser chamados de nó. Um nó é um elemento
físico que existe em tempo de execução e representa um recurso computacional.

<<WebServer>>
<<Cliente>> Apache
WebBrowser <<HTTP>>

<<RS 232>>

Impressora

Nós
<<Application Server>> <<Banco de Dados>>
JBoss Oracle

<<RMI>>

<<Client-Server>>
Cliente




O diagrama de Deployment pode ser substituído por outro diagrama que exibam com
maiores detalhes e/ou com ícones mais apropriados. Apesar de não ser uma boa
recomendação, pois, estaríamos deixando de lado a UML, mas em algumas vezes se
faça necessário.

WebServer Banco de Dados
Apache

Oracle
Application Server
JBoss




Diagrama de Deployment & Diagrama de Componentes
Adicionando ao Diagrama de Deployment o “Diagrama de Componentes”, podemos ter uma
visão mais “clara” da arquitetura baseada na UML




Diagrama de Componentes. Introdução:
Os componentes são utilizados para a modelagem de coisas físicas que podem residir em
nó, como executáveis, bibliotecas, tabelas, arquivos e documentos.
Um componente tipicamente representa o pacote físico de elementos lógicos, como
classes, interfaces, colaborações.

Bons componentes definem abstrações com interfaces bem-definidas, desta forma é
possível atualização de componentes, ou seja, trocar os componentes mais velhos por
outros componentes mais novos ou por novas versões.

Dependência Componente
A

Componente
genérico

Componente Nome do
B componente




O que é um Diagrama de Componentes?
É um diagrama que exibe o sistema por um lado funcional, expondo as relações entre
seus componentes e a organização de seus módulos durante sua execução.
O diagrama de componente descreve os componentes de software e suas dependências
entre si, representando a estrutura do código gerado. Eles são tipicamente os arquivos
implementados no ambiente de desenvolvimento.
Diagrama de componente representa uma visão física, é um pedaço de software de
sistema e seus relacionamentos.
Quando um componente colabora com outro componente, está colaboração é ilustrada
com uma dependência entre o componente cliente e o componente de serviço.

ReservaService
ReservaUI

Dependência Reserva
Service_ Interface
stub
Room Component




Diagrama de Componentes. Definições:
Componente:
Um componente é a parte física e substituível de um sistema ao qual se adapta e fornece a
realização de um conjunto de interfaces.

Interfaces:
Uma interface é coleção de operações utilizadas para especificar um serviço de uma classe
ou de um componente. O relacionamento entre componente e interface é muito importe.
As tecnologias mais populares usam interfaces na implementação de componentes, tais
como:
- Enterprise Java Beans;
- Corba (CCM) e
- Microsoft COM+.




Diagrama de Componentes. Exemplo:

CatalogHome
CatalogHome

Catalog Catalog
Home EJB
Catalog.jsp Stub Home

Catalog
Business
Delegate
Catalog
CatalogRemote
CatalogRemote Bean

Catalog
Catalog
EJB
Remote
Object CatalogRemote
Stub




Tipos de Componentes:
Existem três tipos de componentes:
- Componentes de Implantação: São os componentes necessários para montar um
sistema executável, como as DLLs e os arquivos EXEs. A definição da UML para
componentes é abrangente, inclui componentes mais populares (COM+, CCM e EJB),
além de modelos alternativos como páginas web, tabelas de banco de dados e etc...

CheckIT.exe Video.dll
{versão 1.}

Disk.dll

Floppy.dll




Tipos de Componentes: (continuação)
- Componentes do Produto do Trabalho: Esses componentes são essencialmente o é
parte do processo de desenvolvimento, formados por arquivos de código fontes, arquivos
de dados, ícones. Esses componentes não fazem parte (diretamente) em sistema
executável, mas são os produtos de desenvolvimento, usados para criação do sistema
executável. Cliente.class

Conta.class Conta.jar
{versão 1}
Historico.class

Conta.java

- Componentes de Execução: Esses componentes são criados como uma
conseqüência de um sistema em execução, como um componente COM+, que é sofre
“instance” a partir de uma DLL.




Diagrama de Componentes. Elementos:
Elementos:
A UML define cinco estereótipos-padrão que se aplica aos componentes:
1 - Executável:
Especifica um componente que poderá ser executado em um nó
2 - Biblioteca:
Especifica uma biblioteca de objetos estática ou dinâmica
3 - Tabela:
Especifica um componente que representa uma tabela de banco de dados
5 - Arquivo:
Especifica um componente que representa um documento contendo código-fonte ou
dados
6 - Documento:
Especifica um componente que representa um documento.




- Componente: O ícone de componente representa um módulo (pedaço) de software
com uma interface bem definida. Na especificação de componente definimos o
estereótipo como: ActiveX, Applet, Application, DLL e EXE.
Componente
Nome do genérico
Componente

- Especificação e corpo do subprograma: Estes ícones representam a especificação
visível de um subprograma e o seu corpo de implementação. Um subprograma costuma
ser uma coleção de sub-rotinas. Os subprogramas não contém definições de classe.

NewSubprogSpec NewSubprogBody




- Programa Principal: Este ícone representam o programa principal. Um programa
principal que contém a raiz de um programa. Na linguagem Java seria o programa que
tem o método “main”. MainProgram

Programa princial
(método main)

- Especificação e corpo do pacote: Um pacote é a implementação de uma classe. Uma
especificação de pacote constitui-se em um arquivo de cabeçalho, o qual contém as
informações referentes ao protótipo de função para a classe.
Package Specification Package Body
Um corpo de pacote pode
apresentar o código para as
Na linguagem C++, as
operações da classe. Em C++,
especificações de pacote são os
os corpos de pacotes são os
arquivos .h (header). Em Java
arquivos
usamos o ícone de especificação
.cpp
de pacote para representar os
arquivos .java



- Especificação e corpo da tarefa: Estes ícones representam os pacotes que possuem
linhas independentes de controle. Uma arquivo executável é geralmente representado
como uma especificação de tarefa com uma extensão .exe

NewTaskSpec NewTaskBody

Além de modelar o componente propriamente dito, podemos modelar o relacionamento
entre o componente e sua interface. Veja o exemplo abaixo:

Componente
genérico
Interface




Arquitetura.Diagrama de Componentes. Exemplo:
Neste exemplo criaremos um diagrama de componentes para a funcionalidade
“cesta de compra”. Neste momento identificaremos as classes que são necessárias
para realizar o caso de uso “adicionar item na cesta de compra”. Como alguns
casos de usos são embutidos, novos componentes serão adicionados ao
diagrama. A tecnologia deste exemplo é Java.
Component view

Boundary

Services

Entities

Visão principal do Diagrama de Componentes



Todos os componentes do pacote Entities. Esses são os componentes que conterão as
classes de entidades.
Component view
Cesta

Entities

Cesta Item Produto

As classes Entidades




Todos os componentes do pacote Services. Esses são os componentes que conterão as
classes de serviços ou de controle.
Component view
CestaService

Services
ProdutoService

As classes de Serviços ou Controle




Todos os componentes do pacote Boundaries. Esses são os componentes que conterão
as classes de Boundaries (ou de interface com usuário).
Component view

CestaInterface

Boundary

As classes de Interfaces




Uma visão dos componentes e relacionamentos
MainProgram
CestaInterface

CestaService

ProdutoService

Cesta

Produto
Cesta Item




Um novo exemplo, o cenário fazer Reserva de apartamento.
Menu Principal
ReservaUI
View

Controller ReservaService

ClienteService
ApartamentoService

Model Cliente Reserva Apartamento




Diagrama de Componentes. Identificação de Componentes:
Componentes:

Componentes são grupos de classes que representam uma funcionalidade
dentro de sistema.

Como faço Componentes são identificados usando coesão e acoplamento. Grupos de
o diagrama de
classes que exigem alta coesão e baixo acoplamento formam um
componentes ?
componente.

Como identificar os componentes ?
Componentes
Na fase de Projeto os componentes são desenhados da
seguinte forma:
• O Diagrama de Classe são revisados e grupos de
classes são identificados usando coesão e
acoplamento.
• Este grupos representaram os componentes.




Conceitos: Acoplamento e Coesão
Independência Funcional

Conceito que está diretamente relacionado a modularidade,
abstração e encapsulamento de informação.
Principais características:
– função de propósito único.
– Interfaces simples quando visto de outras partes da
Independência estrutura do programa.
Funcional: – É medida usando-se dois critérios qualitativos: coesão e
•Coesão e acoplamento.
•Acoplamento

Coesão e Acoplamento ajudaram na divisão de classe dentro
de componente.




Coesão (High Cohesion)

É uma medida de força funcional relativa de um módulo.
Uma classe coesiva executa uma única tarefa, exigindo pouca
interação com outras classes ou objetos. Alta coesão é o desejável.

Como manter a alta coesão ?

Independência - Solução: Atribuir uma responsabilidade de forma que a coesão
Funcional: permaneça alta.
•Coesão e
Como manter a complexidade sob controle ?
•Acoplamento
Em termos de projeto orientado a objetos, a coesão (ou mais
especificamente, coesão funcional) é uma medida de quão
fortemente relacionadas e focalizadas são as responsabilidades
de uma classe.
Uma classe com responsabilidade altamente relacionadas e que
não executa um formidável volume de trabalho tem coesão alta.




Coesão: (continuação)

Uma classe com coesão baixa faz muitas coisas não-relacionadas, ou
executa demasiado trabalho. Tais classes são indesejáveis, elas sofrem
dos seguintes problemas:
- São difíceis de compreender;
- São difíceis de reusar;
- São difíceis de manter;
Independência - São muito sensíveis a mudança;
Funcional:
Classes de coesão baixa representam, geralmente, uma abstração de
•Coesão e
“grande granularidade” ou atribuíram responsabilidades que deveriam ter
•Acoplamento sido delgadas a outras classes ou objetos





Exemplo:

Neste exemplo é NotaFiscal Cliente
- número - codigo
demonstrado a baixa - nome
- data emissão
coesão, uma vez que a - tipo +getCodigo()
classe Nota Fiscal +calcularImposto() +setCodigo()
+getNumero +getNome()
Independência assume a
+setNumero
Funcional: responsabilidade de ....
fazer o cálculo dos
•Coesão e
imposto
•Acoplamento
Tributo NotaFiscalItem Produto
- item[ ] - codigo
- codigo
- quantidade - descrição
- nome
+getQuantidade()
+setCodigo()
+setQuantidade()
+getCodigo()
...




Tributo
Coesão: (continuação) - codigo
- nome
Exemplo:

Solução é delegar a NotaFiscal
responsabilidade de - número
cálculo de imposto para - data emissão
- tipo
uma classe especializada CalculoImposto
+getNumero
neste assunto (usamos
Independência +setNumero
aqui o mecanismo de .... +calcularImposto()
Funcional: delegação). Desta forma
•Coesão e teremos uma alta coesão.
•Acoplamento
Produto NotaFiscalItem Cliente
- codigo - codigo
- quantidade
- descrição - nome
+setCodigo() +getQuantidade() +getCodigo()
+getCodigo() +setQuantidade() +setCodigo()
+gerProduto ... +getNome()
+get/cliente()




Tipos de coesão funcional:

• Coesão Muito Baixa:
– Uma classe é a única responsável por muitas coisas em áreas funcionais
muito diferentes
• Coesão Baixa:
– Uma classe é a única com a responsabilidade de uma tarefa complexa em
Independência área funcional
Funcional: • Coesão Alta:
–
•Coesão e Uma classe tem a responsabilidade moderadas em uma área funcional e
colabora com outras classes para levar a termo as tarefas
•Acoplamento • Coesão Moderada:
– Uma classe tem peso leve e responsabilidade exclusivas em umas poucas
áreas diferentes que estão logicamente relacionadas ao conceito da classe,
mas não entre si.





Benefícios:

• Clareza e a facilidade de compreensão do projeto aumentam;
• A manutenção e as melhorias são simplificadas;
• Freqüentemente, o baixo acoplamento é favorecido;
• A granularidade fina de funcionalidades altamente relacionadas suporta
Independência o aumento do potencial de reúso, porque uma classe altamente coesiva
pode ser usada para finalidade muito específica..
Funcional:
•Coesão e
•Acoplamento




Acoplamento (Low Coupling)

É uma medida da interdependência relativa entre as classes.
Depende da complexidade de interface entre as classes.
Baixo acoplamento é o desejável

Como manter o baixo acoplamento ?

Independência - Solução: Atribuir uma responsabilidade de forma que o
Funcional: acoplamento permaneça fraco
•Coesão e
•Acoplamento Como suportar uma dependência baixa e aumentar o
reúso?
O acoplamento é uma medida de quão fortemente uma classe
está ligada a uma ou mais classes, tem conhecimento das
mesmas ou depende delas.
Uma classe com acoplamento baixo (fraco) não é dependente
de muitas classes.




Acoplamento (continuação)

Uma classe com acoplamento alto (forte) depende de muitas outras
classes. Tais classes são indesejáveis; elas sofrem dos seguinte
problemas:
• Mudança em classes relacionadas forçam mudanças locais
• Mais difícil de compreender isoladamente
• Mais difícil de reusar porque o seu uso requer a presença adicional
Independência das classes que ela depende.

Funcional:
Benefícios:
•Coesão e
•Acoplamento • Não afeta por mudanças em outros componentes
• simples de entender
• conveniente para o reúso.




Acoplamento. Tipos:

Abaixo os possíveis tipos de acoplamento:
Acoplamento Abstrata:
<<Interface>>
Cliente Service Cliente Service
{abstract}

Independência
Service Service Service Service
Funcional:
•Coesão e Sem acoplamento Forte acoplamento
•Acoplamento

Com acoplamento
Cliente Service

Versão 27 tight
Rildo Santos (rildo.santos@etecnologia.com.br)


Workflow de Projeto, Arquitetura

Acoplamento

Princípio da Dependência Inversa:

“Abstração não deve depender classe concreta. Uma classe
concreta deve depender de uma abstração”
Exemplo:

Moeda MaskMoeda
Independência
- valor
Funcional:
+getValor
•Coesão e +setValor
+maskFormat()

•Acoplamento
dependência

Este modelo tem alguns problemas:
1 - Herança. Todos que herdarem a classe Moeda são obrigados
a herdar também a classe MaskMoeda e as vezes somente
precisamos da classe Moeda.



Acoplamento

Princípio da Dependência Inversa (continuação):

Moeda MaskMoeda
- valor
+getValor
+maskMoeda()
+setValor

Independência
Funcional: dependência

•Coesão e 2 - O relacionamento de dependência inibe a extensibilidade da
•Acoplamento classe Moeda.
Vamos analisar o seguinte cenário:
Em uma aplicação financeira que lida com mercado
internacional, precisamos ter uma classe Moeda com as
seguintes responsabilidades de saber o valor, formatação de
acordo padrão monetário e exibir o respectivo símbolo da
moeda (cifrão).



Acoplamento

Princípio da Dependência Inversa (continuação):
Aplicando a DIP, podemos resolver a situação, veja os modelos:

DIP com Classe Abstrata: DIP com Interface:
<<Interface>>
{abstract}
Independência
Funcional:
•Coesão e Service Service Service Service

•Acoplamento Solução para a classe Moeda:
Moeda MoedaMask
{abstract}

Real Dolar




Acoplamento
Relacionamento de Realização

Problema:

A classe Cliente realiza a interface iPessoa (isto quer dizes que todos os
métodos assinados na interface deve ser implementado na classe) Uma
vez que se declare uma nova assinatura de método na interface iPessoa
será necessário implementar este novo método na classe Cliente.
Independência
Funcional:
•Coesão e <<interface>>
Realização
•Acoplamento iPessoa

Cliente




Acoplamento
Relacionamento de Realização

Solução:
Criação de nova classe PessoaAdapter esta classe se relacionará com a
interface iPessoa, desta forma todas as modificações ou novos
implementações serão feitas nesta classe.
Desta forma reduziremos o acoplamento entre a interface e a classe
Cliente
Independência
Funcional: <<interface>>
•Coesão e iPessoa

•Acoplamento Realização

PessoaAdapter

Cliente




Exemplo:
A partir do diagrama de classe, tentamos agrupar classes usando
técnicas de coesão e acoplamento.

Exemplo:
Acoplamento
Coesão
e Componentes




Exemplo:

Temos o seguinte resultado:

Exemplo:
Acoplamento
Coesão
e Componentes




Exemplo 2:
Diagrama de Classes:




UML. Diagrama de Componentes
Exemplo 2:
A partir do diagrama de classe,
agrupar classes usando os
conceitos de coesão
e acoplamento.

Pedido

Cesta de Compra

Produto

FormaPagto

317


Workflow de Projeto, Arquitetura

Exemplo 2:

Produto

Pedido

Cesta de Compra
Cesta

Produto

FormaPagto
Pedido FormaPagto




Projetando um Modelo de Arquitetura
Web
Camada de Camada de Camada de Camada de
Camada Cliente Apresentação Negócio Integração dados

<< componente 1>>
Browser
Controller
Form
HTTP
<< componente 2>
ator Banco de
Dados
<< componente n> DriveDB

Browser Página Dinâmicas Componentes SQL


Quer Mais
Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema e novas versões deste material...

Envie um e-mail para com subject: “Quero entrar na comunidade” para rildo.santos@etecnologia.com.br que te
enviaremos um convite para participar da nossa comunidade

http://etecnologia.ning.com/
Versão 27 Rildo Santos (rildo.santos@etecnologia.com.br) 320

Sobre o Análise eRildo F. Orientado a Objetos com UML
autor: Desenho Santos
Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.

A Gestão Ágil ajuda as empresas a responder mais rápido as demandas de negócio e mudanças. A Gestão 2.0, abrange Planejamento
Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, Tecnologia da Informação (Métodos Ágeis), Inovação e Liderança.

Minha Experiência:
Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de Software. Formado
em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia de Software pela Universidade
Mackenzie.

Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM.

Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), RUP/UP -
Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.

Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA.

Possuo fortes conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e GRC -
Governance, Risk and Compliance), SOX, Basel II e PCI;
E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais frameworks e
padrões: ITIL, Cobit, ISO 27001 e ISO 15999;

Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software, Projetista de
Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Segurança Pública,
Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.

Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, ITIL
Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;

Sou membro do IIBA-International Institute of Business Analysis (Canada)

Onde estou:
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/


Marcas Registradas:

Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de responsabilidade de
seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor apresentado neste
material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o
autor informa que o uso é apenas ilustrativo e/ou educativo, não visando ao lucro, favorecimento ou
desmerecimento do produto/fabricante.

Melhoria e Revisão:

Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie
um e-mail nós.

Criticas e Sugestões:

Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-
mail para nós.

Imagens:
Google, Flickr e Banco de Imagem.

Rildo F dos Santos (rildo.santos@etecnologia.com.br)

Licença:


Analise e Desenho Orientado a Objetos com UML

Mais conteúdo relacionado

Mais procurados (20)

Destaque (20)

Semelhante a Analise e Desenho Orientado a Objetos com UML (20)

Mais de Rildo (@rildosan) Santos (20)

Último (20)

Analise e Desenho Orientado a Objetos com UML