Engenharia de Software e Sistemas
Allan Araujo e César Delmas
Agenda
1. Introdução/Motivação
2. Diagrama de Casos de Uso
3. Diagrama de Classes (Análise)
4. Diagrama de Sequência
5. Exercícios
Introdução – The Chaos
Report
Introdução – Imaturidade
Motivação
 Desenvolver sistemas de alta qualidade,
respeitando as restrições de tempo e
custo, e atendendo aos requisitos
implícitos e explícitos do Cliente.
 Utilizar as melhores práticas de
desenvolvimento de sistemas,
aumentando as chances de Sucesso.
 Executar processos que colaborem entre
si para a conclusão do Projeto.
Processo em ESS
 Modelo de Ciclo de Vida em Cascata
Concepção
Requisitos
UML
Análise
Projeto
Implementação
Testes
REQUISITOS
Diagrama de Casos de
Uso
 Diagrama de Casos de Uso



Descreve a interação com atores como uma
seqüência de mensagens;
Representa uma das possíveis visões
dinâmicas do sistema;
Elementos
 Atores;
 Casos de Uso;
 Relacionamentos.
Diagrama de Casos de
Uso
Diagrama de Casos de
Uso - Relacionamentos
Aluno
Matricular
Diagrama de Casos de
Uso - Exemplo
 [UC 01]: Cadastrar Produto
Ator
CadastrarProduto
<<include>>
EfetuarLogin
Diagrama de Casos de Uso Exemplo
 [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.
Diagrama de Casos de Uso Exemplo
 [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
Diagrama de Classes Análise
 A atividade de análise procura descrever o
problema sob o ponto de vista 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 Análise
 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 Análise
 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.
Diagrama de Classes –
Análise – Exemplo
 Fronteira: Modelam uma interação entre o
sistema e um agente interno (atores,
componentes, etc.)
CadastrarProduto
Ator
<<include>>
<<boundary>>
FronteiraCadastrarProduto
EfetuarLogin
[UC 01]
<<boundary>>
FronteiraLogin
[UC 02]
Diagrama de Classes –
Análise – Exemplo
 Entidades: Representam abstrações e
conceitos chave dos casos de uso.
 Identificando Entidades: Utilizar os fluxos
e:




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.
Diagrama de Classes –
Análise – Exemplo
 Entidades:

[UC 01]: Cadastrar Produto
<<entity>>
EntidadeAtor

<<entity>>
EntidadeProduto
[UC 02]: Efetuar Login
<<entity>>
EntidadeAtor
Diagrama de Classes –
Análise – Exemplo
 Controle:


Coordenam o comportamento (lógica de
controle) do caso de uso. Sendo, dependente
do caso de uso, independente do ambiente;
Interface entre fronteira e entidade.
<<control>>
ControladorLogin
Ator
CadastrarProduto
<<include>>
<<control>>
ControladorCadastrarProduto
EfetuarLogin
Diagrama de Classes –
Análise – Exemplo
 Persistência: Identificar as classes de
análise que devem ser persistentes,
criado << 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 –
Análise – Exemplo
 Montando os relacionamentos e atributos:
[UC 01]
[UC 02]
<<boundary>>
<<boundary>>
FronteiraLogin
FronteiraCadastrarProduto
<<control>>
ControladorLogin
<<entity>>
<<entity collection>>
EntidadeAtor
ColeçãoAtor

<<control>>
ControladorCadastrarProduto
<<entity collection>>
<<entity>>
ColeçãoProduto
EntidadeProduto
Evidentemente, faltam mostrar os métodos (mensagens) e
atributos que ajudam a formar os relacionamentos e trocas de
mensagens entre os objetos!
Diagrama de Classes –
Análise – Exemplo
 Finalmente:

Resta apenas conferir e revisar se o modelo acima descreve a
realização de todos os casos de uso solicitados neste exemplo.
E Agora?
 Temos um modelo de análise, que nos permitiu
entender o problema em termos de orientação a
objetos;
 Descobrimos erros prematuramente (o custo por
erro descoberto cresce exponencialmente ao
longo do projeto);
 Temos um artefato escrito numa linguagem
padrão e comum, que todos podem entender;
 Caminhamos a passos largos para obter o
modelo de implementação (o diagrama de
classes final), após a fase de projeto, onde
definimos a arquitetura do sistema.
Perguntas