engenharia de software e sistemas danilo veras e rebeka gomes

Engenharia de Software e Sistemas

Danilo Veras e Rebeka Gomes

Agenda

2. Análise2. Análise

3. Projeto 3. Projeto

1. Revisão1. Revisão

4. Exercícios4. Exercícios

REVISÃOREVISÃ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

Ator CadastrarProduto

EfetuarLogin

<<include>>

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áliseAnálise

Análise

Visão estática 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

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

Fronteira

Modelam uma interação entre o sistema e um ator.

Esteriótipo <<boundary>>

FronteiraCadastrarProduto<<boundary>>

[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

[UC 02]: Efetuar Login

EntidadeAtor<<entity>>


EntidadeProduto<<entity>>

Controle

Coordenam o comportamento (lógica de controle) do caso de uso;

Interface entre fronteira e entidade. Esteriótipo <<control>>


EfetuarLogin

<<include>>

ControladorLogin<<control>>

ControladorCadastrarProduto<<control>>

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

[UC 02]: Efetuar Login


ColecaoAtor<<entity collection>>



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


[UC 01: Cadastrar Produto]


[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


FronteiraLogin<<boundary>>

Relacionamentos

Associação



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




ColeçãoAtor<<entity collection>>

ColeçãoProduto<<entity collection>>

ControladorCadastrarProduto<<control>>


FronteiraCadastrarProduto<<boundary>>[UC 01] [UC 02]

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

ProjetoProjeto

•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

Modelo de Projeto

• 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

Refinamento

• Dividir o sistema em camadas

• A mais comum:

Arquitetura

Apresentação

Negócio

Dados

Comunicação

•Utilizar pacotes para organizar as classes em grupo

Diagrama de Classes – Modelo de Projeto

Perguntas

engenharia de software e sistemas danilo veras e rebeka gomes

Documents