Engenharia de Software e Sistemas Allan Araujo e César Delmas.
-
Upload
natalia-van-der-vinne-faria -
Category
Documents
-
view
218 -
download
3
Transcript of Engenharia de Software e Sistemas Allan Araujo e César Delmas.
Engenharia de Software e SistemasAllan Araujo e César Delmas
Agenda
2. Diagrama de Casos de Uso
3. Diagrama de Classes (Análise)
4. Diagrama de Sequência
1. Introdução/Motivação
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çãoConcepção
RequisitosRequisitos
AnáliseAnálise
ProjetoProjeto
ImplementaçãoImplementação
TestesTestes
UML
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
MatricularAluno
Diagrama de Casos de Uso - Exemplo
[UC 01]: Cadastrar Produto
Ator CadastrarProduto
EfetuarLogin
<<include>>
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.
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
Diagrama de Classes – Análise – Exemplo
Ator CadastrarProduto
EfetuarLogin
<<include>>
Fronteira: Modelam uma interação entre o sistema e um agente interno (atores, componentes, etc.)
FronteiraCadastrarProduto<<boundary>>
FronteiraLogin<<boundary>>
[UC 01]
[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
[UC 02]: Efetuar Login
EntidadeAtor<<entity>>
EntidadeAtor<<entity>>
EntidadeProduto<<entity>>
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.
Ator CadastrarProduto
EfetuarLogin
<<include>>
ControladorLogin<<control>>
ControladorCadastrarProduto<<control>>
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
[UC 02]: Efetuar Login
EntidadeAtor<<entity>>
EntidadeAtor<<entity>>
EntidadeProduto<<entity>>
ColecaoProdutos<<entity collection>>
ColecaoAtor<<entity collection>>
ColecaoAtor<<entity collection>>
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:
Evidentemente, faltam mostrar os métodos (mensagens) e atributos que ajudam a formar os relacionamentos e trocas de mensagens entre os objetos!
ControladorLogin<<control>>
FronteiraLogin<<boundary>>
EntidadeAtor<<entity>>
ColeçãoAtor<<entity collection>>
ColeçãoProduto<<entity collection>>
ControladorCadastrarProduto<<control>>
EntidadeProduto<<entity>>
FronteiraCadastrarProduto<<boundary>>
[UC 01] [UC 02]
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