fluxo de análise e projeto 2 - visão geral do fluxo de análise e projeto

Fluxo de Análise e Projeto

2 - Visão Geral do Fluxo deAnálise e Projeto

Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados. 2


Objetivos desta parte

• Apresentar conceitos utilizados no fluxo de análise e projeto

• Dar uma visão geral das atividades, responsáveis e artefatos deste fluxo



O Fluxo de Análise e Projeto

Os objetivos do fluxo:

• Transformar os requisitos em um projeto (inicialmente abstrato) do sistema

• Desenvolver uma arquitetura robusta• Adaptar o projeto levando em consideração os requisitos

da futura implementação

Fonte: Rational



Visão geral dos artefatos

Análise eprojeto

Modelo de análise e projeto

Documento daarquitetura

Modelo de caso de uso

Modelo de dadosDocumento requisitos

Glossário

Mapeamento das classes de análise em elementos de projeto



Sobre os artefatos

• A construção do modelo de análise e projeto é o principal objetivo deste fluxo de atividades

• O modelo de análise e projeto contém as realizações de casos de uso

• O mapeamento das classes de análise em classes de projeto é um artefato temporário do desenvolvimento

• O documento da arquitetura é opcional; é usado para descrever em detalhes uma determinada arquitetura

• A elaboração do modelo de dados está fora do escopo do curso, mas pode conter, por exemplo, o mapeamento do modelo OO para o relacional



Caso de uso

Caso de uso

Diagramas de Sequência

Diagramas de Colaboração Diagramas de Classe

Realização do Caso de uso

Modelo de Casos de uso Modelo de Análise e Projeto

Fonte: Rational

Artefato Realização de caso de uso



diagramas de interação

Realização de Caso de Uso

• Descreve como o caso de uso é realizado, associando o caso de uso com classes e outros elementos de projeto

• Em UML, uma realização de caso de uso pode ser representada através de um conjunto de diagramas: – diagrama de classe– diagrama de seqüência– diagrama de colaboração




Diagramas de Sequência Diagramas deColaboração

Diagramas de Classe

Visão Lógica

Artefato Modelo de Análise e Projeto

Visão de casos de uso

+



Modelo de Análise e Projeto

• Pode ser um só artefato– evoluindo de uma visão abstrata (nas atividades de análise),

para uma visão detalhada (nas atividades de projeto)• Podem ser feitos dois artefatos

– um modelo de análise– um modelo de projeto (inicia igual à última versão do modelo

de análise e evolui independentemente)• Documentação x esforço e disciplina de manutenção



Análise X Projeto

• Análise– Foco no problema– Comportamento (caixa

preta, sem detalhes de implementação)

– Estrutura do sistema– Requisitos funcionais– Modelo simples

• Projeto– Foco em uma solução– Operações e atributos– Representação próxima

do código– Requisitos não funcionais

(exemplo: desempenho), além dos funcionais

– Modelo complexo

Fonte: Rational



Arquitetura de softwareO modelo de “4+1 Visões”

Visão de Implementação

VisãoLógica

Visão de Distribuição

Visão de Processo

Visão de Casos de Uso

ProjetistaArquiteto

EstruturaProgramadores

Integradores do sistema

Arquiteto

Performance,Escalabilidade

Topologia, implantação, comunicação

Integradores do sistema

Arquiteto

Estrutura, componentes



Fluxo de Análise e Projeto do RUP

•

•

•

•

• •

•



Fluxo de Análise e ProjetoAtividades vistas no curso

Analisar caso de

usoProjetista

Projetista de banco de

dados

Revisar projeto

Projetar caso de

uso

ArquitetoRevisor do

projeto

Projetar base de dados

Projetar arquitetura

Projetar subsistema

Projetar classes

•


Fluxo de Análise e Projeto Fonte: Rational

Responsáveis e Artefatos


3 - AtividadeAnalisar Caso de Uso



Analisar caso de usoProjetista

Projetista de banco de

dados

Revisar projeto

Projetar caso de uso

ArquitetoRevisor do

projeto

Projetar base de dados

Projetar arquitetura

Projetar subsistema

Analisar Caso de Uso



Objetivos desta atividade

• Encontrar classes de análise e distribuir comportamento dos casos de uso entre estas

• Para cada classe, descrever suas responsabilidades, atributos e associações

• Unificar classes de análise

Esta atividade é realizada para cada caso de uso!



Visão geral dos artefatos


Documento daarquitetura

Modelo de caso de uso

Documento de requisitos

Glossário

Analisarcaso de uso

Realização de caso de uso(desenvolvimento)

Classes de análise

Fonte: Rational



Passos para Analisar Caso de Uso

Para cada caso de uso:1. Encontrar classes de análise

2. Distribuir comportamento entre as classes Para cada classe:

3. Descrever responsabilidades4. Descrever atributos e associações5. Identificar persistência

6. Revisar os Resultados



Sistema exemplo: Auto AtendimentoDescrição do Problema

O auto atendimento é uma característica essencial das agências bancárias atuais. A idéia é que operações simples como saques, depósitos, transferências entre contas e consultas a saldos e extratos sejam realizadas diretamente pelo cliente, sem necessidade da intervenção de funcionários do banco. Esta estratégia de atendimento diminui custos operacionais das agências e agrada ao cliente, que pode efetuar operações corriqueiras mais agilmente.



Sistema exemplo: Auto AtendimentoDescrição do Problema

O sistema em questão deve automatizar essas operações em um caixa automático, que será distribuído em vários locais, permitindo ao cliente realizar transações remotas com o seu banco.

O uso do caixa automático deve ser controlado através de cartão magnético e senha, que serão fornecidos a cada cliente pelo banco. O caixa deve ler o cartão para validar o login do cliente e comunicar-se com o sistema central do banco para executar as operações. Toda operação realizada pelo cliente no caixa automático deve ser registra em um log de transações.



Sistema exemplo: Auto AtendimentoDiagrama de casos de uso

Cliente Sistema do banco

Solicitar extrato

Consultar saldo

Sacar dinheiro

Realizar depósito

Registrar transacao

<<include>>

<<include>><<include>>

<<include>>

Transferir entre contas

<<include>>



Passo 1. Encontrar classes de análise

• O comportamento do caso de uso é distribuído em classes de análise dos seguintes tipos (estereótipos)– fronteira– controle– entidade

• Estes estereótipos são uma conveniência de análise que desaparecem no projeto



Classes de análise: um primeiro passo em direção ao executável

Casosde uso

Classes deanálise

Elementosde projeto

Códigofonte

Executável

Use-Case Analysis

Fonte: Rational



Classes de Fronteira (boundary classes)

• Isolam o sistema de mudanças no ambiente externo

• Atores devem se comunicar apenas com classes de fronteira

• Exemplos de classes fronteira– GUI– Interface com outros sistemas– Interface com dispositivos

<<boundary>>



O Papel de uma Classe de Fronteira

<<boundary>>

<<entity>>

<<control>>

<<boundary>>

<<boundary>>

<<entity>>

Modela interação entre o sistema e seu ambiente

Usuário

Fonte: Rational



Regra geral para encontrar Classes de Fronteira

• Uma classe por cada par ator/caso de uso • Exemplo: Caso de uso Sacar Dinheiro

ClienteSacar dinheiro

Sistema do banco

FormularioSaque SistemaBanco



Descrevendo Classes de Fronteira

• GUI– Concentre-se nas informações que serão

apresentadas, não em um projeto gráfico • Interface com outros sistemas ou

dispositivos– Concentre-se em quais protocolos devem ser

definidos, não como serão implementados

• Concentre-se nas responsabilidades, não nos detalhes!



Classes de Entidade (entity classes)

• Abstrações e conceitos chaves dos casos de uso

<<entity>>Glossário

Descrição doCaso de uso

<<entity>>

<<entity>>

Fonte: Rational



O Papel de uma Classe de Entidade

<<boundary>>

<<entity>>

<<control>>

<<boundary>>

<<boundary>>

<<entity>>

Customer

Fonte: Rational

Armazenam e gerenciam informação no sistema



Orientações para encontrarClasses de Entidade

• Usando a descrição do caso de uso, use a abordagem tradicional de filtrar substantivos– identifique substantivos no fluxo de eventos– remova candidatos redundantes e vagos– remova atores que apenas interagem com o

sistema mas não fazem parte da modelagem– remova atributos (serão usados mais tarde) e

operações



Exemplo: Classes de entidade dos casos de uso Sacar Dinheiro e Registrar Transação

Transação



Classes de Controle (control classes)• Coordenam o comportamento

(lógica de controle) do caso de uso• Interface entre fronteira e entidade • Dependente do caso de uso,

independente do ambiente• Permitem separação entre o uso

da entidade (específico do sistema) do comportamento inerente à entidade

<<control>>



O Papel de uma Classe de Controle

<<boundary>>

<<entity>>

<<control>>

<<boundary>>

<<boundary>>

<<entity>>

Customer

Coordenam o comportamento do caso de usoUma classe controle pode ter referência a vários objetos entidadeFinalidade semelhante a classes fachada (Arquitetura de Camadas)

Fonte: Rational



Orientações para encontrar Classes de Controle

• Usualmente, uma classe de controle por caso de uso

• Eventualmente mais de uma (comportamento complexo) ou nenhuma (manipulação simples de informações armazenadas)



Exemplo de Classe de ControleCaso de uso Sacar Dinheiro

ClienteSacar dinhei ro

Sistema do banco

ControladorSaque



Exemplo: Classes de Análise resultantes do caso de uso Sacar Dinheiro

<<control>>ControladorSaque

<<boundary>>FormularioSaque

<<boundary>>SistemaBanco



Exercício: Projeto

• Dado:– O documento de requisitos, especificamente o

fluxo de eventos de um dos principais casos de uso do seu projeto

• Produzir:– Identificação das classes de análise, com seus

estereótipos e breve descrição



Contexto

• Encontradas as classes de análise, vamos agora descrever o seu comportamento.

• Lembrando que estas atividades são realizadas para cada caso de uso



Passo 2. Distribuir comportamento entre as classes

• Para cada fluxo de eventos– alocar responsabilidades do caso de uso às

classes de análise– modelar interações entre as classes através

dos diagramas de interação



Distribuindo comportamento entre as classes

Caso de uso

Diagrama de seqüência Diagrama de colaboração

Classes de análise

Classes de análise com responsabilidades



Alocando responsabilidades

• Use estereótipos de análise como guia– Classes de fronteira

• Comportamento que envolve comunicação com um ator

– Classes de entidade• Comportamento que envolve informação encapsulada

na abstração – Classes de controle

• Comportamento específico ao (lógica de controle do) caso de uso



Alocando responsabilidades

• Identificar que classe tem a informação necessária para realizar a responsabilidade– isso pode envolver apenas uma classe, pode ser

preciso criar nova classe ou relacionamento entre classes



Modelando interações

• Diagramas de interação (colaboração e seqüência) modelam interações do sistema com seus atores

• A interação é iniciada por um ator e envolve instâncias (objetos) das classes

• Diagramas de interação capturam a semântica do fluxo de eventos do caso de uso– Auxiliam a identificar classes, responsabilidades e

relacionamentos– Mecanismo de validação da arquitetura



Forma Geral dos Diagramas de Seqüência

:Client :Supplier

Client Object Supplier Object

Focus of control

Hierarchical MessageNumbering

Reflexive MessageObject Lifeline

1.1: Perform AnotherResponsibility

1: Perform Responsibility

Message


cliente do log : ControladorLogTransacoes : Transacao : LogTransacoes

registrar transacao (dados da transacao)

criar transacao (dados da transacao)

gravar transacao()

Exemplo de um Diagrama de Seqüência:Caso de uso Registrar Transação



Exemplo de um Diagrama de Seqüência:Caso de uso Sacar Dinheiro

Distribuir diagramapara os alunos



Forma Geral de Diagramas de Colaboração

:Client

:Supplier

Client Object

Link

Supplier Object

Message

1: PerformResponsibility



: LogTransacoes

cliente do log

: ControladorLogTransacoes

: Transacao

1: registrar transacao (dados da transacao)

2: criar transacao (dados da transacao)

3: gravar transacao()

Exemplo de um Diagrama de Colaboração Caso de uso Registrar Transação



Vários diagramas podem ser necessários

Pelo menos o fluxo principal deve ser modeladoMas não é necessário modelar todos os fluxos

O importante é exemplificar o uso de todas as responsabilidades

Fonte: Rational



Diagramas de Colaboração e Seqüência

• Colaboração– Apresenta relacionamentos

além das interações– Adequado para visualizar

padrões de colaboração– Adequado para visualizar

efeitos em um dado objeto– Útil em sessões de

brainstorm

• Seqüência– Apresenta seqüência

explícita de mensagens– Adequado para

visualizar o fluxo completo

– Adequado para especificações de tempo real e para cenários complexos

Fonte: Rational



Contexto

Para cada caso de usoencontramos as classes de análisedescrevemos o seu comportamento através de diagramas de interação

Agora, para cada classevamos descrever suas responsabilidades



Passo 3. Descrever Responsabilidades• Responsabilidades identificadas nos fluxos de

eventos são refletidas em diagramas de interação

• Mensagens nestes diagramas resultam em responsabilidades nas classes receptoras

:Client :Supplier

// PerformResponsibility

Supplier

// PerformResponsibility

diagrama de classe

diagrama de interação



Exemplo de VOPC (View of Participating Classes) com Responsabilidades: Caso de uso Sacar Dinheiro

LeitoraCartao

ler cartao()

ContadoraDinheiro

entregar dinheiro(valor)

FormularioSaque

informar senha(senha)informar valor saque(valor)iniciar sessao(numero)

ControladorSaque

iniciar sessao(cartao, senha)finalizar sessao()debitar(identificador conta, valor)

SistemaBanco

selecionar conta(numero, senha)



Analisando o Modelo

• Classes com responsabilidades similares são candidatas a serem combinadas

• Uma classe com responsabilidades disjuntas é candidata a ser dividida

• Classes sem (ou com apenas uma responsabilidade) e classes que interagem com muitas classes são candidatas a serem reexaminadas

Poderá resultar em uma alteração dos diagramas de interação



Exercício: Projeto

• Dado:– O documento de requisitos, especificamente o fluxo

de eventos de um dos principais casos de uso do seu projeto

– As classes de análise identificadas no exercíco anterior

• Produzir:– Diagrama de interação para o caso de uso– VOPC com responsabilidades



Passo 4. Descrever atributos e associações

• Detalhando mais as classes– definir atributos– estabelecer associações necessárias entre as

classes



Encontrando Atributos

• Possíveis fontes: conhecimento do negócio, requisitos, glossário, modelo do negócio, etc.

• São propriedades/características das classes identificadas– informação cujo valor é o aspecto crucial– informação de propriedade exclusiva do objeto – informação que pode ser lida ou escrita por operações, mas

sem outro comportamento a não ser fornecer um valor

• Se a informação tem comportamento complexo ou é compartilhada, deve gerar uma classe



Encontrando Relacionamentos

• Links entre objetos em diagramas de colaboração indicam a necessidade de relacionamento entre as respectivas classes

• Links reflexivos só geram relacionamentos reflexivos quando dois objetos da classe precisam se comunicar (mas não quando um objeto envia mensagens para si próprio)

• A navegabilidade do relacionamento deve estar de acordo com a direção da mensagem

• Inclua também o papel (role) e a multiplicidade dos relacionamentos



Encontrando Relacionamentos

:Client :Supplier

Link

Supplier

PerformResponsibility()

Diagramade classe

Diagrama deColaboração

Association

Client Supplier

Um relacionamento para cada link

Client

1: PerformResponsibility

Prime suppliers

0..* 0..*

Fonte: Rational



Exemplo de VOPC com RelacionamentosCaso de uso Registrar Transação

ControladorSaque

ControladorSaldo

ControladorExtrato

ControladorDeposito

ControladorTransferencia

Transacao

ControladorLogTransacoes1 1

11 1

1

11

1

1

*

1

1

1 1

1

11

1111

*

1



Exercício: Projeto

• Dado: – Classes de análise dos casos de uso com

estereótipos e responsabilidades – Diagramas de colaboração para estes casos

de uso– VOPCs desenvolvidos no exercício anterior

• Produzir:– VOPCs com relacionamentos e atributos



Passo 5. Identificar persistência

• Identificar quais classes de análise deverão ser persistentes

• Identificar características de persistência



Algumas características de persistência

• Granularidade• Volume: até 200• Freqüência de acesso

– Leitura– Atualização– ...



Exemplo: Classes persistentes Caso de uso Registrar Transação

Transação



Exercício: Projeto

• Dado – Artefatos de requisitos

• Produzir – Identificar as classes que deverão ser persistentes



Passo 6. Revisar Resultados

• Verificar se as classes de análise satisfazem os requisitos funcionais

• Unificar as classes de análise• Verificar se todo o modelo está

consistente entre si e com os requisitos



Revisando: Passos realizados nesta atividade

Para cada caso de uso:1. Encontrar classes de análise

2. Distribuir comportamento entre as classes Para cada classe:

3. Descrever responsabilidades4. Descrever atributos e associações5. Identificar persistência

6. Revisar os Resultados

fluxo de análise e projeto 2 - visão geral do fluxo de análise e projeto

Documents