Engenharia de Software e Sistemas Allan Araujo e César Delmas.

29
Engenharia de Software e Sistemas Allan Araujo e César Delmas

Transcript of Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Page 1: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Engenharia de Software e SistemasAllan Araujo e César Delmas

Page 2: Engenharia de Software e Sistemas Allan 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

Page 3: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Introdução – The Chaos Report

Page 4: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Introdução – Imaturidade

Page 5: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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.

Page 6: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Processo em ESS

Modelo de Ciclo de Vida em Cascata

ConcepçãoConcepção

RequisitosRequisitos

AnáliseAnálise

ProjetoProjeto

ImplementaçãoImplementação

TestesTestes

UML

Page 7: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

REQUISITOS

Page 8: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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.

Page 9: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Diagrama de Casos de Uso

Page 10: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Diagrama de Casos de Uso - Relacionamentos

MatricularAluno

Page 11: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Diagrama de Casos de Uso - Exemplo

[UC 01]: Cadastrar Produto

Ator CadastrarProduto

EfetuarLogin

<<include>>

Page 12: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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.

Page 13: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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.

Page 14: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Análise

Page 15: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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.

Page 16: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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

Page 17: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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

Page 18: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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]

Page 19: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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.

Page 20: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Diagrama de Classes – Análise – Exemplo

Entidades: [UC 01]: Cadastrar Produto

[UC 02]: Efetuar Login

EntidadeAtor<<entity>>

EntidadeAtor<<entity>>

EntidadeProduto<<entity>>

Page 21: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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>>

Page 22: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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>>

Page 23: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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.

Page 24: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Diagrama de Seqüências

[UC 01: Cadastrar Produto]

Page 25: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Diagrama de Seqüências

[UC 02: Efetuar Login]

Poderia reportar um erro também!

Page 26: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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]

Page 27: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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.

Page 28: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

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.

Page 29: Engenharia de Software e Sistemas Allan Araujo e César Delmas.

Perguntas