Engenharia de Software e Sistemas
Danilo Veras e Rebeka Gomes
Agenda
1. Revisão
2. Análise
3. Projeto
4. Exercícios
REVISÃO
Revisão
 O que temos até agora:




Fluxo principal de eventos;
Modelo de Casos de Uso;
Pre-condições;
Pos-condições;
Exemplos
 [UC 01]: Cadastrar Produto
Ator
CadastrarProduto
<<include>>
EfetuarLogin
Exemplos
 [UC 01]: Cadastrar Produto

Fluxo Principal
 <<include>> [UC 02: Efetuar Login]
 O ator preenche todas informações necessárias
ao novo produto e confirma a operação;
 O sistema verifica se o produto não existe. Caso
não, o produto é adicionado ao sistema;
 O ator é informado do sucesso da informação.

Fluxo Alternativo: Produto Existente
 [Passo 3 do FP]: Se acusar que o produto já
existe, o ator é informado, e dessa forma, não
pode ser adicionado novamente.
Exemplos
 [UC 02]: Efetuar Login

Fluxo Principal
 O ator preenche as informações necessárias
(login/senha, por exemplo) e confirma a transação;
 O sistema verifica a existência de um usuário com
aquele respectivo conjunto de informações. Caso
exista, o ator tem acesso à tela principal do
sistema.

Fluxo Alternativo: Usuário Inexistente
 [Passo 2 do FP]: Se não existir um usuário com
tais informações, o ator é informado do erro e da
impossibilidade de obter acesso ao sistema.
Análise
Análise
 Visão estática do sistema
 Cada caso de uso deve ser analisado
isoladamente
 Encontrar as classes iniciais do sistema e
distribuir o comportamento dos casos de
uso entre elas
 Cada classe tem suas responsabilidades,
atributos e associações
Diagrama de Classes
 Para cada caso de uso:


Encontrar classes de análise
Identificar persistências
 Para cada classe:



Distribuir comportamento entre elas
Descrever responsabilidades
Descrever atributos e associações
 Revisar resultados.
Diagrama de Classes
 O comportamento do caso de uso é
distribuído em classes de análise dos
seguintes tipos (estereótipos):



Fronteira
Controle
Entidade
 Utilizado apenas como convenções,
devem sumir na fase de projeto.
Fronteira
 Modelam uma interação entre o sistema e
um ator.
 Esteriótipo <<boundary>>
CadastrarProduto
Ator
<<boundary>>
FronteiraCadastrarProduto
[UC 01]
Entidade
 Representam abstrações e conceitos
chave dos casos de uso.
 Identificando Entidades:




Identificar substantivos no fluxo de eventos;
Remover candidatos redundantes e vagos;
Remover atores que apenas interagem com o
sistema mas não fazem parte da modelagem;
Remover atributos (serão usados mais tarde)
e operações.
 Esteriótipo <<entity>>
Entidade

[UC 01]: Cadastrar Produto
<<entity>>
EntidadeAtor

<<entity>>
EntidadeProduto
[UC 02]: Efetuar Login
<<entity>>
EntidadeAtor
Controle



Coordenam o comportamento (lógica de
controle) do caso de uso;
Interface entre fronteira e entidade.
Esteriótipo <<control>>
<<control>>
ControladorLogin
Ator
CadastrarProduto
<<include>>
<<control>>
ControladorCadastrarProduto
EfetuarLogin
Persistência
 Identificar as classes de entidade que
devem ser persistentes,e para cada uma
criar uma nova classe
 Esteriótipo << Entity Collection >>

[UC 01]: Cadastrar Produto
<<entity collection>>
ColecaoAtor

<<entity>>
EntidadeAtor
<<entity>>
EntidadeProduto
[UC 02]: Efetuar Login
<<entity>>
EntidadeAtor
<<entity collection>>
ColecaoAtor
<<entity collection>>
ColecaoProdutos
Diagrama de Seqüências
 É utilizado para representar aspectos
dinâmicos do sistema através da troca de
mensagens entre objetos.
 É construído para cada caso de uso,
utilizando seu respectivo fluxo de evento e
classes de análise.
 Os objetos trocam mensagens entre si
para assim, realizar o caso de uso.
Diagrama de Seqüências
 [UC 01: Cadastrar Produto]
Diagrama de Seqüências
 [UC 02: Efetuar Login]
Poderia reportar um erro também!
Diagrama de Classes
 Já podemos identificar os relacionamentos, os
métodos e os atributos das classes:

Cada iteração no diagrama de seqüência
corresponde a um relacionamento no diagrama de
classe
<<boundary>>
FronteiraLogin
<<control>>
ControladorLogin
Relacionamentos
 Associação
<<boundary>>
FronteiraLogin
<<control>>
ControladorLogin
 Agregação X Composição
 Dependência
Diagrama de Classes


Os métodos são identificados através do diagrama de
seqüência;
Podemos identificar os atributos mais ainda não
podemos identificar o tipo deles
Diagrama de Classes
[UC 01]
<<boundary>>
<<boundary>>
FronteiraLogin
FronteiraCadastrarProduto
<<control>>
ControladorLogin
<<entity>>
<<entity collection>>
EntidadeAtor
ColeçãoAtor
[UC 02]
<<control>>
ControladorCadastrarProduto
<<entity collection>>
<<entity>>
ColeçãoProduto
EntidadeProduto
•Faltam os métodos e os atributos!!!
Projeto
Modelo de Projeto
•Mais concreto do que o modelo de análise
•Depende da tecnologia de implementação
•Unificação em um único modelo
•Definição da arquitetura do sistema
•Proposição de padrões de projeto
•Projetar arquitetura
•Projetar Banco de Dados
Refinamento
• Agrupar todas as classes de análise em um único
diagrama
• Identificar redundância
• Criar ou remover classes
• Identificar interfaces entre os grupos maiores
Refinamento
•Adicionar modificadores de visibilidade aos métodos
e atributos
• Definir os tipos dos atributos
• Definir o tipo do retorno e dos parâmetro dos
métodos
• Identificar padrões de projeto
Arquitetura
• Dividir o sistema em camadas
• A mais comum:
Apresentação
Comunicação
Negócio
Dados
•Utilizar pacotes para organizar as classes em grupo
Diagrama de Classes –
Modelo de Projeto
Perguntas