Projeto de Sistemas

Alexandre Monteiro
 Agenda

1.
1. Revisão
Revisão

2.
2. Análise
Análise

3.
3. Projeto
Projeto

4.
4. Exercícios
Exercícios
REVISÃO
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

CadastrarProduto
Ator
<<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
 Análise

 Visão estático 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>> <<entity>>
EntidadeAtor 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
CadastrarProduto
Ator
<<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>> <<entity>> <<entity>> <<entity collection>>
ColecaoAtor EntidadeAtor EntidadeProduto ColecaoProdutos


[UC 02]: Efetuar Login
<<entity>> <<entity collection>>
EntidadeAtor ColecaoAtor
 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>>

[UC 02]
FronteiraLogin FronteiraCadastrarProduto

<<control>>
<<control>>
ControladorLogin ControladorCadastrarProduto

<<entity collection>> <<entity>>

<<entity>> <<entity collection>>
EntidadeAtor ColeçãoAtor ColeçãoProduto EntidadeProduto

•Faltam os métodos e os atributos!!!

Projeto
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