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