2 - Visão Geral do Fluxo de
Análise e Projeto
Fluxo de Análise e Projeto
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
2
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
3
Visão geral dos artefatos
Modelo de análise
e projeto
Modelo de caso
de uso
Glossário
Análise e
projeto
Documento
requisitos
Documento da
arquitetura
Modelo de dados
Mapeamento das
classes de análise
em elementos de
projeto
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
4
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
5
Artefato Realização de caso de uso
Modelo de Casos de uso
Caso de uso
Modelo de Análise e Projeto
Realização do Caso de uso
Diagramas de Sequência
Caso de uso
Diagramas de Colaboração
Diagramas de Classe
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
6
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
diagramas de interação
– diagrama de colaboração
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
7
Artefato Modelo de Análise e Projeto
Diagramas de Sequência
Diagramas deColaboração
Modelo de análise e projeto
Visão de casos de uso
+
Diagramas de Classe
Visão Lógica
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
8
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
9
Análise X Projeto
• Análise
• Projeto
– Foco no problema
– Comportamento (caixa
preta, sem detalhes de
implementação)
– Estrutura do sistema
– Requisitos funcionais
– Modelo simples
– 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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
10
Arquitetura de software
O modelo de “4+1 Visões”
Estrutura
Estrutura,
componentes
Projetista
Arquiteto
Integradores
do sistema
Arquiteto
Programadores
Visão
Lógica
Visão de
Implementação
Visão de Casos
de Uso
Visão de
Processo
Integradores
do sistema
Visão de
Distribuição
Performance,
Escalabilidade
Arquiteto
Topologia,
implantação,
comunicação
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
11
Fluxo de Análise e Projeto do RUP
•
•
•
•
•
•
•
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
12
Fluxo de Análise e Projeto
Atividades vistas no curso
Projetar
arquitetura
Arquiteto
Revisor do
projeto
Projetar
subsistema
Projetista
Analisar
caso de
uso
Projetar
caso de
uso
Projetar
classes
Revisar
projeto
•
Projetista de
banco de
dados
Projetar
base de
dados
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
13
Responsáveis e Artefatos
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
14
3 - Atividade
Analisar Caso de Uso
Fluxo de Análise e Projeto
Analisar Caso de Uso
Projetar
arquitetura
Arquiteto
Revisor do
projeto
Projetar
subsistema
Projetista
Analisar
caso de uso
Projetar
caso de uso
Projetista de
banco de
dados
Revisar
projeto
Projetar
base de
dados
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
16
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!
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
17
Visão geral dos artefatos
Glossário
Documento da
arquitetura
Classes de análise
Analisar
caso de uso
Documento de
requisitos
Modelo de caso de uso
Realização de caso de uso
(desenvolvimento)
Modelo de análise e projeto
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
18
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 responsabilidades
4. Descrever atributos e associações
5. Identificar persistência
6. Revisar os Resultados
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
19
Sistema exemplo: Auto Atendimento
Descriçã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.
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
20
Sistema exemplo: Auto Atendimento
Descriçã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.
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
21
Sistema exemplo: Auto Atendimento
Diagrama de casos de uso
<<include>>
<<include>>
Solicitar extrato
Registrar transacao
<<include>>
<<include>>
Consultar saldo
Cliente
<<include>>
Sacar dinheiro
Sistema do
banco
Realizar depósito
Transferir entre contas
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
22
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
23
Classes de análise: um primeiro passo em
direção ao executável
Casos
de uso
Classes de
análise
Elementos
de projeto
Código
fonte
Executável
Use-Case Analysis
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
24
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
<<boundary>>
– GUI
– Interface com outros sistemas
– Interface com dispositivos
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
25
O Papel de uma Classe de Fronteira
Modela interação
entre o sistema e seu
ambiente
<<boundary>>
<<control>>
<<boundary>>
Usuário
<<boundary>>
<<entity>>
<<entity>>
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
26
Regra geral para encontrar
Classes de Fronteira
• Uma classe por cada par ator/caso de
uso
• Exemplo: Caso de uso Sacar Dinheiro
Sacar dinheiro
Cliente
FormularioSaque
Sistema do banco
SistemaBanco
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
27
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!
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
28
Classes de Entidade (entity classes)
• Abstrações e conceitos chaves dos
casos de uso
<<entity>>
Glossário
<<entity>>
<<entity>>
Descrição do
Caso de uso
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
29
O Papel de uma Classe de Entidade
Armazenam e
gerenciam informação
no sistema
<<boundary>>
<<control>>
<<boundary>>
Customer
<<boundary>>
<<entity>>
<<entity>>
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
30
Orientações para encontrar
Classes 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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
31
Exemplo: Classes de entidade dos casos de
uso Sacar Dinheiro e Registrar Transação
Transação
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
32
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>>
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
33
O Papel de uma Classe de Controle
Coordenam o comportamento do caso de uso
Uma classe controle pode ter referência a vários objetos entidade
Finalidade semelhante a classes fachada (Arquitetura de Camadas)
<<boundary>>
<<control>>
<<boundary>>
Customer
<<boundary>>
<<entity>>
<<entity>>
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
34
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)
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
35
Exemplo de Classe de Controle
Caso de uso Sacar Dinheiro
Cliente
Sacar dinheiro
Sistema do banco
ControladorSaque
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
36
Exemplo: Classes de Análise resultantes do caso de uso
Sacar Dinheiro
<<boundary>>
FormularioSaque
<<control>>
ControladorSaque
<<boundary>>
SistemaBanco
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
37
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
38
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
39
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
40
Distribuindo comportamento entre as classes
Classes de análise
Diagrama de seqüência
Caso de uso
Diagrama de colaboração
Classes de análise com
responsabilidades
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
41
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
42
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
43
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
44
Forma Geral dos Diagramas de Seqüência
Supplier Object
Client Object
:Client
:Supplier
Object Lifeline
Reflexive Message
1: Perform Responsibility
1.1: Perform Another
Responsibility
Message
Hierarchical Message
Numbering
Focus of control
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
45
Exemplo de um Diagrama de Seqüência:
Caso de uso Registrar Transação
cliente do log
: ControladorLogTransacoes
: Transacao
registrar transacao (dados da transacao)
criar transacao (dados da transacao)
gravar transacao()
Fluxo de Análise e Projeto
:
LogTransacoes
Exemplo de um Diagrama de Seqüência:
Caso de uso Sacar Dinheiro
Distribuir diagrama
para os alunos
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
47
Forma Geral de Diagramas de Colaboração
Client Object
Link
Supplier Object
:Client
1: PerformResponsibility
:Supplier
Message
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
48
Exemplo de um Diagrama de Colaboração
Caso de uso Registrar Transação
1: registrar transacao (dados da transacao)
cliente
do log
: ControladorLogTransacoes
3: gravar transacao()
2: criar transacao (dados da transacao)
:
LogTransacoes
: Transacao
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
49
Vários diagramas podem ser necessários
Pelo menos o fluxo principal deve ser modelado
Mas não é necessário modelar todos os fluxos
O importante é exemplificar o uso de todas as responsabilidades
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
50
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
51
Contexto
Para cada caso de uso
encontramos as classes de análise
descrevemos o seu comportamento através
de diagramas de interação
Agora, para cada classe
vamos descrever suas responsabilidades
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
52
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
diagrama de
interação
:Client
:Supplier
// PerformResponsibility
diagrama de
classe
Supplier
// PerformResponsibility
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
53
Exemplo de VOPC (View of Participating Classes) com
Responsabilidades: Caso de uso Sacar Dinheiro
LeitoraCartao
ler cartao()
entregar dinheiro(valor)
FormularioSaque
selecionar conta(numero, senha)
ControladorSaque
informar senha(senha)
informar valor saque(valor)
iniciar sessao(numero)
SistemaBanco
ContadoraDinheiro
iniciar sessao(cartao, senha)
finalizar sessao()
debitar(identificador conta, valor)
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
54
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
55
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
56
Passo 4. Descrever atributos e associações
• Detalhando mais as classes
– definir atributos
– estabelecer associações necessárias entre as
classes
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
57
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
58
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
59
Encontrando Relacionamentos
1: PerformResponsibility
Diagrama de
Colaboração
:Client
:Supplier
Link
Client
Diagrama
de classe
Supplier
Client
0..*
Supplier
0..*
Prime suppliers
PerformResponsibility()
Association
Um relacionamento para cada link
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
Fonte: Rational
60
Exemplo de VOPC com Relacionamentos
Caso de uso Registrar Transação
ControladorExtrato
ControladorTransferencia
1
1
ControladorSaldo
1
1
ControladorDeposito
1
1
1
1
ControladorSaque
ControladorLogTransacoes
1
1
1
*
Transacao
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
61
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
62
Passo 5. Identificar persistência
• Identificar quais classes de análise
deverão ser persistentes
• Identificar características de persistência
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
63
Algumas características de persistência
• Granularidade
• Volume: até 200
• Freqüência de acesso
– Leitura
– Atualização
– ...
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
64
Exemplo: Classes persistentes
Caso de uso Registrar Transação
Transação
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
65
Exercício: Projeto
• Dado
– Artefatos de requisitos
• Produzir
– Identificar as classes que deverão ser persistentes
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
66
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
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
67
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 responsabilidades
4. Descrever atributos e associações
5. Identificar persistência
6. Revisar os Resultados
Fluxo de Análise e Projeto
Maio, 2000Copyright CESAR-Qualiti, Maio 2000. Todos os direitos reservados.
68