análise e projeto oo com uml e padrões augusto sampaio - acas pedro antonino – prga2 (monitor)...
Post on 07-Apr-2016
216 Views
Preview:
TRANSCRIPT
Análise e Projeto OO com UML e Padrões
Augusto Sampaio - acasPedro Antonino – prga2
(Monitor)
Agosto, 2013
• Parte do material cedido pela Qualiti Software Processes
Motivação
Análise,e Projeto OO com UML para Sistemas RT| 2
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Essência de Análise e Projeto: construção de
modelosO que é um modelo?Por que construir modelos?Quantos modelos construir para: capturar os elementos do problema Representar diferentes níveis de abstração
Em Engenharia de Software O que é Desenvolvimento Baseado em
Modelos?
Análise,e Projeto OO com UML para Sistemas RT| 3
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
- 4 -
Sistema respiratório
Outros modelos:•Muscular,•Nervoso,•Circulatório,•Digestivo,•etc.
Esqueleto
RealidadeModelos (visões parciais)Representa
Um modelo é uma visão parcial (representação) da
realidade
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Multiplas visões: controle da complexidade
Carpenter'sview
Mason'sview
Plumber'sview
Architect'sview
Landlord'sview
Renter'sview
InteriorDesigner'sview
TaxCollector'sview
Electrician'sview
ModelrepOfSystem
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Desenvolvimento baseado em modelos
A principal motivação é aumentar a produtividade: Independência de tecnologia Reutilização Automação
Aumentar o nível de abstração Foco no modelo, não no código “O modelo é o código ...”
Processos são essenciais para sistematizar o desenvolvimento
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
O grande desafio ...
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Vídeo: Modeling Through the Ages
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Objetivos do cursoProcesso de Análise e Projeto no RUPAspectos de modelagem de paradigmas recentes:
SOA (Software-Oriented Architecture) MDD (Model-Driven Development)
Técnicas de modelagem OO em UMLÊnfase em Padrões de Projeto e ArquiteturaisConsolidação dos conceitos em um exemplo construído incrementalmenteUso de ferramentas de modelagemGeração de esqueleto de código
Análise e Projeto OO com UML e Padrões| 9
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Conteúdo do cursoAnálise/projeto no RUP Disciplina de A&P Análise de caso de
uso Projetar arquitetura Projetar casos de uso
Considerando SOA e MDD Modelo de negócio Analisar serviços Projetar serviços
Análise e Projeto OO com UML e Padrões| 10
Processos de software
Análise,e Projeto OO com UML para Sistemas RT| 11
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Para ser uma atividade sistematizada, Análise e Projeto deve ser parte de um processoProcesso: O que é? Representação? Ciclo de vida? Execução? Modelos de processo
Análise e Projeto OO com UML e Padrões| 12
Processo de software
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE13/45
Análise e Projeto no modelo Cascata
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Análise e Projeto no modelo Espiral
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE15/45
Análise e Projeto no modelo iterativo do
RUP
Planejamento e Gerenciamento.....
Fluxos de Suporte
Gerência de Configuração............
Requisitos...............................Análise e Projeto......................Implementação........................Testes...................................Implantação............................
Fluxos de Processo
Iterações
FasesConcepção Elaboração Construção Transição
Inicial
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Análise e Projeto em SOA(Service Oriented Architecture)
Especificação do modelo de negócios
Analisar serviços
Implementação
TesteAvaliação
PlanejamentoInicial
Planejamento
Modelagem do Negócio
Requisitos
Projetar Serviços
Análise versus Projeto
Análise,e Projeto OO com UML para Sistemas RT| 17
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE18/45
Análise versus Projeto
Análise Foco no problema Comportamento (caixa
preta, sem detalhes de implementação)
Estrutura geral da arquitetura 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
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE19/45
Análise versus Projeto
Em MDD (Model Driven Development) da OMG (Object Management Group) ... Análise corresponde aos modelos
independentes de plataforma (PIM – Platform Independent Model)
No projeto, os modelos podem estar vinculados a uma tecnologia particular (PSM – Platform Specific Model)
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE20/45
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
Estratégias de decomposição
Análise,e Projeto OO com UML para Sistemas RT| 21
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE22/45
Estratégias de Decomposição
Funcional x DadosDecomposição Funcional Decomposição do sistema em componentes
funcionais (exemplo: casos de uso) O estado do sistema é centralizado e
compartilhado entre as funções Experiência mostrou inadequação para
estruturação de modelos de análise e projeto (as regras de negócio mudam constantemente)
Entretanto, útil para estruturar requisitos, planejar e gerenciar projetos, e realizar testes
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE23/45
Estratégias de Decomposição
Funcional x Dados Decomposição Baseada em Dados O sistema é visto como uma coleção de
entidades que interagem (ou objetos, no paradigma OO)
O estado do sistema é descentralizado Mostrou-se adequada como mecanismo de
estruturação (estabilidade de dados com relação a funções) de
• modelos de análise• projeto e • implementação
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE24/45
Estratégias de decomposição
Projeto Top-down x Bottom-up
System level
Sub-systemlevel
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE25/45
Projeto Top-down x Bottom-up
Na prática, o projeto de grandes sistemas nunca é inteiramente top-down
Os projetistas reutilizam experiência (e componentes)
No processo, ocorre brainstorm nos dois sentidos
Atributos de qualidade de modelos de análise e
projeto
Análise,e Projeto OO com UML para Sistemas RT| 26
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE27/45
Atributos de Qualidade
A qualidade é uma propriedade relativa a prioridades específicas da organizaçãoCaracterísticas de qualidade são igualmente aplicáveis a projetos orientados a objeto ou à funçãoDois atributos importantes são coesão e acoplamento
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE28/45
O Atributo Coesão Medida da proximidade das partes (elementos) de um componente do sistema Um componente deve implementar uma única entidade lógica ou função (abstração)Importância Quando uma mudança tiver que ser feita, ela
será facilmente localizada Reuso ...
Em Orientação a objetos, cada classe deve modelar uma única entidade
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE29/45
Medida da intensidade das interconexões entre componentes do sistemaImportância Baixo acoplamento implica que mudanças em
um componente tendem a não afetar outros componentes
Reuso ...
O Atributo Acoplamento
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE30/45
Acoplamento Forte
Module A Module B
Module C Module D
Shared dataarea
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE31/45
Acoplamento Fraco
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
CIn-UFPE32/45
Sistemas orientados a objeto são, potencialmente, fracamente acoplados Geralmente não compartilham estado A comunicação é feita através de passagem de
mensagensEntretanto... uma classe está acoplada a sua superclasse
(mudanças nos atributos ou operações se propagam a todas as subclasses)
Relacionamentos cíclicos (em particular, bidirecionais) também geram forte acoplamento
Acoplamento em Orientação a Objetos
Padrões, anti-padrões e frameworks
Análise,e Projeto OO com UML para Sistemas RT| 33
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
34
Padrões de Projeto e Arquiteturais
Projetistas experientes (re)utilizam soluções bem sucedidas no passadoPadrões sistematizam soluções, incluindo
• Nome• Problema• Solução• Conseqüência• Exemplo, ...
Durante as duas última décadas, surgiu uma “comunidade” voltada a padrões
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Exemplo: Padrão Fachada
35
Fachada
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
36
Anti-PadrõesSão uma maneira de documentar soluções recorrentes que não tiveram sucesso
• Podem também incluir soluções re-trabalhadas que sejam efetivas
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
37
FrameworksUsualmente baseado em padrões, mas já voltados para uma linguagem de programaçãoEspecialização/instanciação Hot spots Herança
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Análise e Projeto OO com UML e Padrões| 38
Relacionamento com outras disciplinas do processo de
softwarePlanejamento e Gerenciamento – planeja e acompanha todo o desenvolvimento Requisitos – entrada para a análise e projeto do sistemaImplementação – o modelo de análise e projeto é entrada a implementaçãoGerência de Configuração e Ambiente – oferece suporte aos artefatos gerados (incluindo modelos)
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Módulos do curso
Análise e Projeto OO com UML e Padrões| 39
4. Projetar 4. Projetar ArquiteturaArquitetura
3. Analisar 3. Analisar Caso de UsoCaso de Uso
6. SOA6. SOA
2. Disciplina 2. Disciplina de Análise e de Análise e ProjetoProjeto
5. Padrões de 5. Padrões de Projeto e Projeto e arquiteturaisarquiteturais
1. Visão geral 1. Visão geral e conceitos de e conceitos de OO com UMLOO com UML
1010. Projetar . Projetar Base de DadosBase de Dados
99. Projetar . Projetar classeclasse
88. Projetar . Projetar SubsistemaSubsistema
1111. Visão . Visão Crítica e Crítica e ReferênciasReferências
77. Projetar . Projetar Caso de UsoCaso de Uso
Análise e Projeto OO com UML e Padrões| 40
Orientação a Objetoscom UML
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Elementos básicos de OO em UML
• Objeto• Classe• Atributo• Operação• Interface• Componente• Pacote• Subsistema• Relacionamentos• Vários tipos de diagrama
Análise e Projeto OO com UML e Padrões|
42
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Objeto em UML
Análise e Projeto OO com UML e Padrões|
43
: Conta
contaSaque :Conta
contaSaqueApenas o nome daclasse
Apenas o nome doobjeto
Nome da classe e doobjeto
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Classe em UML
Análise e Projeto OO com UML e Padrões|
44
Conta
Nome da Classe Conta
Atributos Operações
numerosaldo
credito()debito()getSaldo()getNumero()
estrutura
comportamento
• O que deve ser modelado por uma classe?• O que é abstração e modularidade?
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Visibilidade
Marcações de acesso podem ser usadas para especificar o tipo de acesso permitido aos atributos e operações
+ público # protegido - privado
Análise e Projeto OO com UML e Padrões|
45
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
InterfaceInterfaces definem um tipo especificando apenas a assinatura de seus métodosInterfaces não possuem atributos e seus métodos não têm corpoClasses, subsistemas e componentes implementam interfaces provêem implementação para os métodos
especificados em uma interface
Análise e Projeto OO com UML e Padrões|
46
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Exemplo: Independência do meio de armazenamento
Isolando as coleções de negócio de mudanças na coleção de dados correspondente
Análise e Projeto OO com UML e Padrões|
47
RepositorioContasBDR RepositorioContasOO
CadastroContas
<<interface>>RepositorioContas
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Interface em UML: notação alternativa
Análise e Projeto OO com UML e Padrões|
48
RepositorioContas
Relacionamentos de realização
RepositorioContasOO
RepositorioContasXML
RepositorioContasBDR
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Classes, Interfaces e Classes Abstratas
Análise e Projeto OO com UML e Padrões|
49
Classes
• Atributos• Métodos
Classes Abstratas
• Atributos• Métodos• Assinatura de Métodos
Interfaces
• Assinaturas dos métodos
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Componente em UML
Análise e Projeto OO com UML e Padrões|
50
Interface doComponente
Arquivo fonte<<DLL>>
Componente<<EXE>>Arquivo
executável
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
PacoteMecanismo para organizar elementos em gruposFacilita entendimento do sistemaFavorece modularidade e reuso em larga escalaEssencial para estruturar sistemas complexos
Análise e Projeto OO com UML e Padrões|
51
nome do pacote
nome do pacote
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Subsistema em UML
Análise e Projeto OO com UML e Padrões|
52
Subsistema
Interface
Realização
<<subsystem>>
Nome do subsistema
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Subsistemas e Componentes
• Ambos encapsulam um comportamento modelado por interfaces
• Subsistemas representam componentes no modelo de projeto
• Componentes são a realização física dos subsistemas
Análise e Projeto OO com UML e Padrões|
53
Projeto
Implementação
Nome do componente
<<subsystem>>Nome do subsistema
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
RelacionamentosAssociação simples agregação composiçãoDependência GeneralizaçãoRealização
Análise e Projeto OO com UML e Padrões|
54
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
AssociaçãoRelação estrutural entre classes
Análise e Projeto OO com UML e Padrões|
55
Pessoa
Pessoa Empresa
Empresa
trabalha
Associação
Nome da associação
Classe
Empregado Empregador
Papéis
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Agregação• Tipo especial de associação• Relacionamento todo-parte• O todo possui um nível de abstração maior
que a parte
Análise e Projeto OO com UML e Padrões|
56
DepartamentoEmpresa
Todo Parte
Agregação
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
ComposiçãoTipo especial de agregaçãoRelação de posse mais forteO todo é responsável pela criação da parteA parte não vive sem o todoNão permite compartilhamento
Análise e Projeto OO com UML e Padrões|
57
DepartamentoEmpresa
Todo Parte
Composição
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Dependência• Relacionamento não estrutural (uso)
– mais fraco que associação• Uma dependência entre dois elementos
indica que mudança em um elemento pode causar mudanças no outro
Análise e Projeto OO com UML e Padrões|
58
CartãoLeitoraCartao
lerCartao (cartao) Relacionamentode Dependência
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
DependênciaPode existir relacionamento de dependência entre vários elementos de UML
Análise e Projeto OO com UML e Padrões|
59
Classe
Pacote
PacoteFornecedor
ComponenteFornecedorCliente
PacoteClienteDependência
Fonte: Rational
FornecedorCliente
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Multiplicidade
Multiplicidade define quantos objetos participam do relacionamento O número de instâncias de uma classe
relacionadas a uma instância de outra classe
Especificado em cada uma das pontas da associação
Análise e Projeto OO com UML e Padrões|
60
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Tipos de MultiplicidadeNão especificadaExatamente umZero ou maisMuitos (mesmo que 0..*)Um ou maisZero ou umIntervalo determinadoValores múltiplos
Análise e Projeto OO com UML e Padrões|
61
1
0..*
*
1..*
0..1
2..4
2, 4..6
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Exemplo: Multiplicidade
Análise e Projeto OO com UML e Padrões|
62
PessoaEmpresa
Multiplicidade
1..*1
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Navegação
• Especifica a direção da associação• Associações e agregações são
bidirecionais por default, mas é desejável que a navegação seja restringida a apenas uma direção
• Associações bidirecionais são mais difíceis de implementar e acoplam o modelo
Análise e Projeto OO com UML e Padrões|
63
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Exemplo: Navegação
Análise e Projeto OO com UML e Padrões|
64
PessoaEmpresa
Navegação
1..*1
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Generalização
• Relacionamento entre classes onde uma classe compartilha a estrutura (atributos e relacionamentos) e comportamento (operações) de outras classes
• Define uma hierarquia de abstrações• Relacionamento “é um tipo de” (is-a-kind-of)
–Herança comportamental (behavioural inheritance)
–Referência clássica: A behavioral notion of subtyping (Liskov & Wing)
Análise e Projeto OO com UML e Padrões|
65
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Generalização
Uma subclasse pode adicionar atributos, operações e
relacionamentos redefinir operações herdadas
Tipos de herança: simples e múltipla
Análise e Projeto OO com UML e Padrões|
66
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Herança Simples
Classes herdando de apenas uma outra classe
Análise e Projeto OO com UML e Padrões|
67
Círculoraiocentrodesenhar()
Retânguloverticesdesenhar()diagonal()
Figuracorlargura da linhadesenhar()girar(graus)selecionar()
Subclasses
Superclasse(pai)
Relacionamentode Generalização
Quadrado
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Herança Múltipla
Classes herdando de mais de uma classe
Análise e Projeto OO com UML e Padrões|
68
Mamífero AnimalVoadorHerançamúltipla
Cachorro Gato Morcego Passarinho Gaviao
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Herança Múltipla
• O que acontece quando as superclasses possuem o mesmo método (métodos com o mesmo nome?
• O que acontece quando se tenta executar um método que não está definido na subclasse? Em que hierarquia de superclasses deve-se procurar o método?
Análise e Projeto OO com UML e Padrões|
69
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Realização• Indica que um elemento serve como contrato que
o outro deve seguir
Exemplos:
Análise e Projeto OO com UML e Padrões|
70
Realização
SubsistemaClasse
Caso de uso
Componente
Realização de Caso de uso
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Exercício - ArquiteturaDefina uma arquitetura simplificada de uma aplicação bancária, com: Pelo menos 2 tipos de conta (corrente,
poupança) e um cadastro de contas Cliente e um cadastro de clientes Operações para criar, remover,
debitar, creditar, transferir, ... Adoção do padrão fachada
Análise e Projeto OO com UML para
Sistemas RT| 71
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Mecanismos adicionais de UML
EstereótiposNotasPropriedades (Tagged values)RestriçõesOCL (Object Constraint Language)
Análise e Projeto OO com UML e Padrões|
72
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Estereótipos
• Mecanismo utilizado para estender os elementos de UML
• Define um novo modelo de elemento em termos de outro já existente
• Como– criando um novo ícone– utilizando a notação <<novo_elemento>>
Análise e Projeto OO com UML e Padrões|
73
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Estereótipos - Exemplo
Classes de fronteira:
Análise e Projeto OO com UML e Padrões|
74
ClasseFronteira
<<boundary>>ClasseFronteira
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Notas• Anotação utilizada para adicionar
informação a diagramas– Pode ser afixionada a qualquer elemento de UML – Pode ser ligada a um elemento com uma linha tracejada
Exemplo:
Análise e Projeto OO com UML e Padrões|
75
LeitorCartao
Esta classe é uma abstração do dispositivo de hardware que será usado para ler efetivamente as informações do cartão magnético.
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Propriedades (Tagged Values)
• Servem para estender elementos UML, adicionando informações sobre eles
• Exemplos já definidos em UML:– Persistence– Location (ex: no cliente, no servidor)
• Você pode criar suas próprias propriedades
Análise e Projeto OO com UML e Padrões|
76
Cliente{persistence}
LeitorCartao {location=server}
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
RestriçõesUsadas para criação de novas regras sobre elementos do modeloOu modificação de regras existentes
Análise e Projeto OO com UML e Padrões|
77
Pessoa Empresa{subset}
funcionários
diretores
1..* 1
3 1
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
OCL (Object Constraint Language)
É uma linguagem usada para definir restrições sobre elementos do modelo ou modificação de restrições existentes Invariantes de classe Pré e pós-condições de operações
Análise e Projeto OO com UML e Padrões|
78
Empresacontext Empresainv diretoresNecessarios:self.diretor->size() == 3
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Diagramas UML
Diagramas de UML usados no curso (apresentados sob demanda) Casos de uso Classes Sequência Comunicação (Colaboração) Pacotes Componentes (usado em SOA)
Análise e Projeto OO com UML e Padrões|
79
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Processos e Padrões• Orientação a objetos e DBC são
paradigmas promissores, mas –Reuso–Extensibilidade –Escalabilidade ...
exigem–Processos–Técnicas–Disciplina–Experiências anteriores de sucesso (padrões)!
80
Atividades, Artefatos e Responsáveis da Disciplina
de Análise e Projeto
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
ObjetivosDar uma visão geral das atividades, responsáveis e artefatos desta disciplina no RUP Inserção de atividades e artefatos de SOA
Análise e Projeto OO com UML e Padrões|
82
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Objetivos da disciplina de análise e projeto
Transformar os requisitos em um projeto (inicialmente abstrato) do sistema Desenvolver uma arquitetura robusta para o sistemaAdaptar o projeto levando em consideração requisitos da futura implementação
Análise e Projeto OO com UML e Padrões|
83
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Relacionamento com os demais fluxos
• Planejamento e Gerenciamento – planeja o que será feito em cada iteração do sistema
• Requisitos – os casos de uso servem como entrada para o projeto da arquitetura do sistema
• Implementação – o modelo de análise e projeto é entrada para o fluxo de implementação
• Gerência de Configuração e Ambiente – oferece suporte aos artefatos gerados no fluxo de A&P
Análise e Projeto OO com UML e Padrões|
84
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Arquitetura de softwareO modelo de “4+1 Visões”
Análise e Projeto OO com UML e Padrões|
85
Visão de Implementação
VisãoLógica
Visão de Distribuição
Visão de Processos
Visão de Casos de Uso
Analista de Sistemas
Arquiteto
Estrutura
Programadores
Arquiteto Escalabilidade Topologia, implantação, comunicação
Arquiteto
Estrutura, componentes
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
O Fluxo de Análise e Projeto
Análise e Projeto OO com UML e Padrões|
86
Planejamento e Gerenciamento.....
Fluxos de SuporteGerência de Configuração............
Requisitos...............................Análise e Projeto......................Implementação........................Testes...................................Implantação............................
Fluxos de Processo
Iterações
FasesConcepção Elaboração Construção Transição
Inicial
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Visão geral dos artefatos
Análise e Projeto OO com UML e Padrões|
87
Análise e Projeto
Modelo de Casos de Uso
Projeto de Banco de Dados
Documento de Requisitos
Glossário
Documento da Arquitetura
Mapeamento das Classes de Análise em Elementos de Projeto
Modelo de Análise e Projeto
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Sobre os artefatos• A construção do modelo de análise e
projeto é o principal objetivo deste fluxo de atividades
• O projeto de banco de dados geralmente contém o mapeamento do modelo OO para o relacional, ou seja, especifica tabelas, índices, triggers, procedures, etc.
• O documento da arquitetura é opcional. Ele é usado para descrever em detalhes uma determinada arquitetura
Análise e Projeto OO com UML e Padrões|
88
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Sobre os artefatosO mapeamento das classes de análise em classes de projeto é um artefato temporário do desenvolvimentoO modelo de análise e projeto contém as realizações de casos de uso
Análise e Projeto OO com UML e Padrões|
89
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Artefato Realização de Caso de Uso
Análise e Projeto OO com UML e Padrões|
90
Modelo de Casos de Uso Modelo de Análise e Projeto
Diagrama de Classes
Diagrama de Seqüência
Diagrama de Colaboração
Realização de Caso de Uso
Caso de Uso
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
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
Análise e Projeto OO com UML e Padrões|
91
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Artefato Modelo de Análise e Projeto
Análise e Projeto OO com UML e Padrões|
92
Visão LógicaVisão de Casos de Uso Visão de Processos+
Diagramas de Classes
Diagramas de Seqüência
Diagramas de Colaboração
Diagrama de Distribuição
Modelo de Análise e Projeto
Visão de Distribuição+
Diagrama deComponentes
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Fluxo de atividades da disciplina de Análise e
Projeto
Análise e Projeto OO com UML e Padrões|
93
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Visão geral das atividades
Análise e Projeto OO com UML e Padrões|
94
Analisar Serviços
ProjetarServiços
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Arquiteto de Informação
Análise e Projeto OO com UML e Padrões| 95
Analisar Casos de Uso
Revisar Projeto
Projetar Arquitetura
Projetista deBanco de Dados
Arquiteto de Software
Revisor de projeto
Projetar Casos de Uso
Projetar Subsistemas
Projetar Base de Dados
Analista deSistemas
decisões doarquiteto
<<subsystem>>
CheckList bla bla bla blabla
Projetar classes
Prototipar Interface gráfica
Analisar Serviços
ProjetarServiços
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Responsáveis e Artefatos
Análise e Projeto OO com UML e Padrões|
96
Realizações de casos de uso e projeto de subsistemas
ArquitetoMapeamento das Classes de Análise em Elementos de Projeto
Projeto de Banco de Dados
Documento da Arquitetura
Revisor
Analista de Sistemas
Projetista de Banco de Dados
Modelo de Análise e Projeto
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Responsáveis e Artefatos (SOA)
Análise e Projeto OO com UML e Padrões|
97
Projeto de componentes
Arquiteto
Modelo de Interação de Serviços
Projeto de Banco de Dados
Arquitetura de Serviços
Revisor
Analista de Sistemas
Projetista de Banco de Dados
Modelo de Projeto
Arquitetura de Componentes
Arquitetura do Sistema
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
ArquitetoLidera e coordena as atividades técnicas e a construção dos artefatos do projetoEstabelece a estrutura das visões arquiteturais Decompõe o sistema em visões Agrupa os elementos de projeto em
subsistemas, pacotes, módulos e define suas interfaces
Identifica unidades de concorrênciaTem uma visão larga e superficial do sistema
Análise e Projeto OO com UML e Padrões|
98
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Analista de Sistema• Faz a realização dos casos de uso de
forma consistente com a arquitetura• Deve conhecer:
–A tecnologia a ser usada no desenvolvimento do sistema
–As técnicas de modelagem de casos de uso–Os requisitos do sistema–As técnicas de análise e projeto orientado a
objetos–A linguagem UML
Análise e Projeto OO com UML e Padrões|
99
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Projetista de Banco de Dados
Define a estrutura de dados da aplicação, como tabelas, índices, visões, triggers, etc.Deve possuir um conhecimento sólido em análise e projeto orientado a objetos e banco de dados
Análise e Projeto OO com UML e Padrões|
100
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
RevisorPlaneja e conduz revisões formais do modelo de análise e projetoDeve ser experiente e ter como objetivo a descoberta de problemas no modeloDeve ter um conhecimento equivalente ao de um arquiteto
Análise e Projeto OO com UML e Padrões|
101
Análise,e Projeto OO com UML para Sistemas RT| 102
Analisar Caso de Uso
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Objetivos deste móduloApresentar os passos necessários para realizar a atividade analisar casos de uso e discutir seus artefatosApresentar os diagramas de seqüência, colaboração e classes de UML
Analisar caso de uso | 104
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Arquiteto de Informação
Análise e Projeto OO com UML e Padrões|
105
Analisar Casos de Uso
Revisar Projeto
Projetar Arquitetura
Projetista deBanco de Dados
Arquiteto de Software
Revisor de projeto
Projetar Casos de Uso
Projetar Subsistemas/componentes
Projetar Base de Dados
Analista deSistemas
Projetar classes
Prototipar Interface gráfica
Analisar Serviços
ProjetarServiços
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Arquiteto de Informação
Análise e Projeto OO com UML e Padrões|
106
Analisar Casos de Uso
Revisar Projeto
Projetar Arquitetura
Projetista deBanco de Dados
Arquiteto de Software
Revisor de projeto
Projetar Casos de Uso
Projetar Subsistemascomponentes
Projetar Base de Dados
Analista deSistemas
Projetar classes
Prototipar Interface gráfica
Analisar Serviços
ProjetarServiços
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Objetivos desta atividadeEncontrar as classes iniciais do sistema (classes de análise) e distribuir comportamento dos casos de uso entre elasPara cada classe, descrever as responsabilidades, atributos e associações
Esta atividade é realizada para cada caso de uso!
Analisar caso de uso | 107
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Visão geral dos artefatos
Analisar caso de uso | 108
Analista de Sistemas
Analisar Caso de Uso
Glossário Modelo de Casos de Uso
Diagrama de Classes
Diagrama de Seqüência
Diagrama de Colaboração
Documento de Requisitos
Documento da Arquitetura
Realização de Caso de Uso
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Passos para Analisar Casos de Uso
Para cada caso de uso:1. Encontrar classes de análise2. Identificar persistência
Para cada classe:3. Distribuir comportamento entre as classes 4. Descrever responsabilidades5. Descrever atributos e associações
6. Revisar os Resultados
Analisar caso de uso | 109
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
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
Analisar caso de uso | 110
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Classes de análise: um primeiro passo em direção ao executável
Analisar caso de uso | 111
Modelo de Casos de Uso
Códigos Fonte
Executável
Classes de Análise
Elementos de Projeto
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB - Diagrama de Casos de Uso
Usaremos o QIB como exemplo
Analisar caso de uso | 112
Operadora do DOC
Desbloquear Talõesde Cheque
Efetuar Login
Alterar Senha
Consultar Saldo
Consultar Extrato
Consultar Qualiti CardRealizar Transferência
Consultar Cheques
Solicitar Talões de Cheque
Realizar DOC
ClienteAtor
Operadora Cartão de Crédito
Efetuar Pagamento do Qualiti Card
Mostrar Dados daConsulta
<<include>>
<<include>>
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Classes de Fronteira (boundary classes)
Isolam o sistema de mudanças no ambiente externoAtores devem se comunicar apenas com classes de fronteira Exemplos de classes fronteira GUI Interface com outros sistemas Interface com dispositivos
Analisar caso de uso | 113
<<boundary>>
Modelam a interação entre o sistema e seu ambiente
Notação em UML
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar LoginRegra geral para encontrar classes de fronteira: uma classe por cada par ator/caso de uso
Analisar caso de uso | 114
TelaLogin<<boundary>>
ClienteAtor Efetuar Login
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Descobrindo classes de fronteira
Analisar caso de uso | 115
TelaPagamentoQualitiCard<<boundary>>
ComunicacaoOperadoraCartao<<boundary>>
ClienteAtorEfetuar Pagamento do Qualiti Card Operadora de Cartão
de Crédito
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
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!
Analisar caso de uso | 116
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Classes de Entidade (entity classes)
Abstrações e conceitos chaves dos casos de usoFontes: Conhecimento do negócio Glossário Modelo de negócios Documento de requisitos Especificação do Caso de uso
Analisar caso de uso | 117
<<entity>>
Armazenam e controlam informação no sistema
Notação em UML
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar LoginObserve o fluxo de eventos do Efetuar Login
Analisar caso de uso | 118
Este caso de uso é responsável por autenticar um usuário do sistema.
Pré-condição: nenhumaPós-condição: um usuário válido é logado e sua sessão é registrada no sistema.
Fluxo de eventos principal1. O cliente informa login e senha.2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e senha pertencem a uma conta).3. O sistema registra o início de uma sessão de uso.
Fluxos secundários- No passo 2, se o login ou a senha forem inválidos, o sistema exibe uma mensagem e volta ao passo 1.
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
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
Analisar caso de uso | 119
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Login• Classes de entidade
• A classe Conta é uma classe que armazena o login e senha de um cliente.
• Algumas classes levantadas podem ser eliminadas e novas serão adicionadas
Analisar caso de uso | 120
Usuario<<entity>>
Conta<<entity>>
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Descrição inicial
Analisar caso de uso | 121
Este caso de uso é responsável por realizar o pagamento do Qualiti Card com a operadora de cartão de crédito. Cada cliente possui apenas um cartão como titular, estando vinculado a apenas uma operadora.
Pré-condição: O cliente deve estar conectado ao sistema (ter efetuado o login).
Pós-condição: O valor do pagamento é debitado da conta do cliente, o pagamento é enviado à operadora do cartão de crédito e a transação é registrada no sistema.
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Fluxo de eventos principal
Analisar caso de uso | 122
1. O cliente informa os dados necessários para efetuar o pagamento do cartão: - O código de barras da fatura que deseja efetuar o pagamento. - O valor que deseja pagar.
2. O sistema recupera a conta bancária do cliente logado.
3. O sistema verifica se o saldo da conta do cliente é suficiente para realizar o pagamento.
4. O sistema debita da conta do cliente.
5. O sistema envia o pagamento à operadora de cartão de crédito.
6. O sistema registra a transação de pagamento e emite um comprovante da mesma para o usuário. A transação registrada contém os dados da conta do cliente, o código de barras da fatura, data, hora e valor do pagamento.
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Fluxo de eventos secundários
Analisar caso de uso | 123
Fluxo Principal1. O cliente informa os dados necessários para efetuar o pagamento do cartão: - O código de
barras da fatura que deseja efetuar o pagamento. - O valor que deseja pagar.2. O sistema recupera a conta bancária do cliente logado 3. O sistema verifica se o saldo da conta do cliente é suficiente para realizar
o pagamento.4. O sistema debita da conta do cliente.5. O sistema envia o pagamento à operadora de cartão de crédito.
6. O sistema registra a transação de pagamento e emite um comprovante da mesma para o usuário. A transação registrada contém os dados da conta do cliente, o código de barras da fatura, data, hora e valor do pagamento.
Fluxo secundário
- No passo 3, se o saldo disponível na conta do cliente for menor que o valor do pagamento, o sistema informa que o saldo é insuficiente e retorna para o passo 1.- No passo 5, se a operadora de cartão de crédito estiver inativa, o sistema exibe uma mensagem e cancela a operação.- Em qualquer momento o usuário pode cancelar a operação.
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Classes de entidade
Analisar caso de uso | 124
Conta<<entity>>
Cliente<<entity>>
CartaoCredito<<entity>>
Comprovante<<entity>>
Mensagem<<entity>>
CodigoBarras<<entity>>
PagamentoCartao<<entity>>
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Classes de Controle (control classes)
Coordenam o comportamento (lógica de controle) do caso de usoInterface entre fronteira e entidade Dependente do caso de uso, independente do ambientePermitem separação entre o uso da entidade (específico do sistema) do comportamento inerente à entidade
Analisar caso de uso | 125
<<control>>
Coordena o comportamento do caso de uso.Uma classe controle pode ter referência a vários objetos entidade.
Notação em UML
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
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)
Analisar caso de uso | 126
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar LoginEncontrando classes de controle
Analisar caso de uso | 127
ControladorLogin<<control>>
ClienteAtor Efetuar Login
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Encontrando classes de controle
Analisar caso de uso | 128
ControladorPagamentoQualitiCard<<control>>
ClienteAtorEfetuar Pagamento do Qualiti Card Operadora de Cartão
de Crédito
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Login
Analisar caso de uso | 129
Classes de análise descobertas até o momento
Usuario<<entity>>
TelaLogin<<boundary>>
ControladorLogin<<control>>
Conta<<entity>>
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Analisar caso de uso | 130
Conta<<entity>>
Cliente<<entity>>
CartaoCredito<<entity>>
TelaPagamentoQualitiCard<<boundary>>
Comprovante<<entity>>
Mensagem<<entity>>
CodigoBarras<<entity>>
ComunicacaoOperadoraCartao<<boundary>>
PagamentoCartao<<entity>>
ControladorPagamentoQualitiCard<<control>>
Classes de análise descobertas até o momento
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Exercício – Qualiti Internet Banking
Dado: Artefatos de requisitos do Qualiti Internet
Banking, especialmente o fluxo de eventos do caso de uso RealizarDoc (ver próximos slides)
Produzir: Identificação das classes de análise, com
seus estereótipos e breve descrição
Análise e Projeto OO com UML e Padrões|
131
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Realizar DocDescrição inicial
Análise e Projeto OO com UML e Padrões|
132
Este caso de uso é responsável por realizar a transferência de valores entre uma conta deste banco para uma conta de um outro banco. A transferência pode ocorrer entre contas com mesmo CPF ou CPFs distintos.
Pré-condição: o cliente deve estar conectado ao sistema (ter efetuado o login).
Pós-condição: o valor da transferência foi debitado da conta do cliente, o DOC foi enviado à operadora de DOC e a transação foi registrada.
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Realizar DocFluxo de eventos principal
Análise e Projeto OO com UML e Padrões|
133
1. O cliente informa os dados necessários para a realização do DOC: - Banco, agência e conta destino; - CPF do favorecido; - Valor do DOC.2. O sistema recupera a conta bancária do cliente logado.3. O sistema verifica se o saldo da conta do cliente é suficiente para a realização do DOC.4. O sistema envia o DOC à operadora.5. Debita-se o valor da conta.6. O QIB registra a ocorrência desta transação (um DOC).7. Emite-se um comprovante da mesma para o usuário, contendo os dados da conta de origem e destino, assim como a data e valor do DOC.
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Realizar DocFluxo de eventos secundários
Análise e Projeto OO com UML e Padrões|
134
Fluxo Principal1. O cliente informa os dados necessários para a realização do DOC: - Banco, agência e conta destino; - CPF do favorecido; - Valor do DOC.2. O sistema recupera a conta bancária do cliente logado.3. O sistema verifica se o saldo da conta do cliente é suficiente para a
realização do DOC.4. O sistema envia o DOC à operadora.5. Debita-se o valor da conta.6. O QIB registra a ocorrência desta transação (um DOC).7. Emite-se um comprovante da mesma para o usuário, contendo os dados da conta de origem e
destino, assim como a data e valor do DOC.
Fluxo secundário• No passo 3, se o saldo disponível na conta do usuário for menor que o valor do DOC, o sistema informa que o saldo é insuficiente e retorna ao passo 1 do fluxo principal de eventos.• No passo 4, se a operadora de DOC estiver inativa ou se ocorrer algum erro de comunicação que impeça a efetivação da transação, o sistema emite uma mensagem para o cliente e aborta a transação. • Em qualquer momento o usuário pode cancelar a operação.
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Passo 2. Identificar persistência
Identificar que classes de análise deverão ser persistentesCriar, para cada classe persistente, uma classe de cadastro com estereótipo <<entity collection>>
Analisar caso de uso | 135
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Login
Analisar caso de uso | 136
Classes persistentes
Usuario<<entity>>
CadastroUsuarios<<entity collection>>
Conta<<entity>>
CadastroContas<<entity collection>>
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Analisar caso de uso | 137
Classes persistentes
CadastroPagamentosCartao<<entity collection>>
CadastroClientes<<entity collection>>
CadastroContas<<entity collection>>
PagamentoCartao<<entity>>
Cliente<<entity>>
Conta<<entity>>
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Exercício – Qualiti Internet Banking
Dado Artefatos de requisitos do caso de uso
realizar doc Classes de entidade
Produzir Identificação das classes que deverão ser
persistentes
Análise e Projeto OO com UML e Padrões|
138
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Contexto
Encontradas as classes de análise e identificadas as classes persistentes, vamos agora descrever o seu comportamento.
Lembrando que estas atividades são realizadas para cada caso de uso
Analisar caso de uso | 139
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Passo 3. Distribuir comportamento entre as
classesPara 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
Analisar caso de uso | 140
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Distribuindo comportamento entre as
classes
Analisar caso de uso | 141
Classes de Análise Diagrama de
Colaboração
Caso de Uso
Diagrama de Seqüência
Classes de Análise(com responsabilidades)
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
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 caso de uso (lógica de controle do caso de uso)
Analisar caso de uso | 142
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
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
Analisar caso de uso | 143
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
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
Analisar caso de uso | 144
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Forma Geral dos Diagramas de Seqüência
Analisar caso de uso | 145
:Cliente :Fornecedor
Objeto cliente Objeto fornecedor
Foco de controle
Numeração hierárquica para as mensagens
Mensagem reflexiva
1.1: Realize outra responsabilidade
1: Realize responsabilidade
Mensagem
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Login
Analisar caso de uso | 146
: ClienteAtor : TelaLogin : ControladorLogin : CadastroContas
efetuarLogin(login, senha)
efetuarLogin(login, senha)
existeConta(login, senha)
registraSessao(login)
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Forma Geral de Diagramas de
Colaboração
Analisar caso de uso | 147
:Cliente
:Fornecedor
Objeto cliente
Link
Objeto fornecedorMensagem
1: Realize responsabilidade
Mensagem reflexiva
1.1: Realize outra responsabilidade
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB - Efetuar Login
Analisar caso de uso | 148
: ClienteAtor
: TelaLogin
: ControladorLogin : CadastroContas
4: registraSessao(login)
1: efetuarLogin(login, senha)
2: efetuarLogin(login, senha)
3: existeConta(login, senha)
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Analisar caso de uso | 149
Exercício: diagramas de seqüência e colaboração do caso de uso Efetuar Pagamento do Qualiti Card
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Quantos diagramas de interação fazer?
• Quantos forem necessários para modelar o comportamento do caso de uso!
• Pelo menos o fluxo principal deveria ser modelado
• Não é necessário modelar todos os fluxos–Os fluxos secundários geralmente não
acrescentam muito à modelagem do principal
• O importante é exemplificar o uso de todas as responsabilidades
Analisar caso de uso | 150
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Que diagramas de interação fazer?
• Diagramas de colaboração x diagramas de seqüência
• Colaboração– Melhores para visualizar os relacionamentos e
responsabilidades de um dado objeto– Mais fáceis de desenhar - úteis em sessões de brainstorm
• Seqüência– Melhores para visualizar a seqüência do fluxo no tempo– Melhores para visualizar o fluxo completo– Mais adequados para cenários complexos
Analisar caso de uso | 151
Use o que gostar mais!!
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Contexto
Para cada caso de usoencontramos as classes de análiseidentificamos classes persistentesdescrevemos o seu comportamento através de diagramas de interação
Agora, para cada classevamos descrever suas responsabilidades
Analisar caso de uso | 152
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Passo 4. Descrever Responsabilidades
Responsabilidades identificadas nos fluxos de eventos são refletidas em diagramas de interaçãoMensagens nestes diagramas resultam em responsabilidades nas classes receptoras
Analisar caso de uso | 153
:Cliente :Fornecedor
// Realizar responsabilidade
Fornecedor
// Realizar responsabilidade
diagrama de classes
diagrama de interação
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Login
Analisar caso de uso | 154
Classes com responsabilidades
TelaLogin
efetuarLogin()
<<boundary>>
ControladorLogin
efetuarLogin()
<<control>>
CadastroContas
existeConta()
<<entity collection>>
Conta<<entity >>
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Analisar caso de uso | 155
Classes com responsabilidades
Conta
getSaldo()debitar()
<<entity>>
Comprovante<<entity>>
TelaPagamentoQualitiCard
efetuarPagamentoQualitiCard()
<<boundary>>
PagamentoCartao<<entity>>
CadastroPagamentosCartao
inserir()
<<entity collection>>
CadastroContas
consultarConta()atualizar()
<<entity collection>>
ControladorPagamentoQualitiCard
efetuarPagamentoQualitiCard()
<<control>>
ComunicacaoOperadoraCartao
enviar()
<<boundary>>
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Analisando o ModeloClasses com responsabilidades similares são candidatas a serem combinadasUma 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
Isso poderá resultar em uma alteração dos diagramas de interação
Analisar caso de uso | 156
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Exercício – Qualiti Internet Banking
Dado: Artefatos de requisitos do QIB,
especialmente o fluxo de eventos do caso de uso Realizar DOC
As classes de análise identificadas no exercício anterior
Produzir: Diagrama de interação para o caso de uso VOPC com responsabilidades
Análise e Projeto OO com UML e Padrões|
157
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Passo 5. Descrever atributos e associações
Detalhando mais as classes definir atributos estabelecer associações necessárias entre
as classes
Analisar caso de uso | 158
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Encontrando AtributosPossí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
Analisar caso de uso | 159
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
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
Analisar caso de uso | 160
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Encontrando Relacionamentos
Analisar caso de uso | 161
:Cliente :Fornecedor
Link
Fornecedor
Realizar responsabilidade
Diagramade classe
Diagrama deColaboração
Associação
Cliente Fornecedor
Um relacionamento para cada link
Cliente
1: Realizar responsabilidade
Fonte: Rational
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Login
Analisar caso de uso | 162
Diagrama de classes com relacionamentos e atributos
Contaloginsenha
<<entity>>
TelaLogin
efetuarLogin()
<<boundary>>
CadastroContas
existeConta()
<<entity col lection>>
0..n0..n
ControladorLogin
efetuarLogin()
<<control>>
1
0..n
1
0..n
1
1
1
1
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Analisar caso de uso | 163
Diagrama de classes com relacionamentos e atributos
Contanumerosaldo
getSaldo()debitar()
<<entity>>
ComprovantepagamentoCartao
<<entity>>
PagamentoCartaonumeroFaturadatahoravalorcontaBancaria
<<entity>>
TelaPagamentoQualitiCard
efetuarPagamentoQualitiCard()
<<boundary>>
CadastroContas
consultarConta()atualizar()
<<entity collection>>
0..n0..n
CadastroPagamentosCartao
inserir()
<<entity collection>>
0..n0..n
ComunicacaoOperadoraCartao
enviar()
<<boundary>>
ControladorPagamentoQualitiCard
efetuarPagamentoQualitiCard()verificarSaldo()
<<control>>1
0..n
1
0..n
1 11 1
1
1
1
1 11
11
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Exercício – Qualiti Internet Banking
Dado: Classes de análise do caso de uso Realizar
DOC com estereótipos e responsabilidades Diagramas de interação do caso de uso VOPCs desenvolvidos no exercício anterior
Produzir: VOPCs com relacionamentos e atributos.
Incluir multiplicidade e navegabilidade dos relacionamentos
Análise e Projeto OO com UML e Padrões|
164
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Passo 6. Revisar Resultados
Verificar se as classes de análise satisfazem os requisitos funcionaisUnificar as classes de análiseVerificar se todo o modelo está consistente entre si e com os requisitos
Analisar caso de uso | 165
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Revisando: Passos realizados nesta atividade
Para cada caso de uso:1. Encontrar classes de análise2. Identificar persistência
Para cada classe:3. Distribuir comportamento entre as classes
4. Descrever responsabilidades5. Descrever atributos e associações
6. Revisar os Resultados
Analisar caso de uso | 166
Projetar Arquitetura
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
ObjetivosApresentar os passos necessários para realizar a atividade projetar arquitetura e discutir seus artefatosApresentar o padrão de arquitetura em camadasApresentar e exercitar o uso de padrões de projetoApresentar o Padrão MVCConsiderações sobre concorrência e distribuição
Análise e Projeto OO com UML e Padrões|
168
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Arquiteto de Informação
Análise e Projeto OO com UML e Padrões| 169
Analisar Casos de Uso
Revisar Projeto
Projetar Arquitetura
Projetista deBanco de Dados
Arquiteto de Software
Revisor de projeto
Projetar Casos de Uso
Projetar Subsistemas
Projetar Base de Dados
Analista deSistemas
CheckList bla bla bla blabla
Projetar classes
Prototipar Interface gráfica
Analisar Serviços
ProjetarServiços
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
O que foi feito até agoraAnálise de caso de uso - para cada caso de uso: Identificação das classes de análise (fronteira, entidade e
controle) Identificação das classes persistentes Distribuição do comportamento do caso de uso entre as
classes• Elaboração do diagrama de seqüência• Geração do diagrama de colaboração
Identificação das responsabilidades das classes Identificação dos atributos e relacionamentos
Análise e Projeto OO com UML e Padrões|
170
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Objetivos desta atividadeAvaliar o conjunto das classes de análise Definir elementos de projeto (classes de projeto, cápsulas e subsistemas) e organizá-los em pacotesDefinir a estrutura da aplicação
Análise e Projeto OO com UML e Padrões|
171
No final do projeto da arquitetura tudo deve estar pronto para que os projetistas possam detalhar as realizações dos casos de uso de maneira uniforme!
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Visão geral dos artefatos
Análise e Projeto OO com UML e Padrões|
172
Arquiteto Projetar Arquitetura
Documento da Arquitetura
Documento de Requisitos
Mapeamento das Classes de Análise em Elementos de Projeto
Modelo de Análise e Projeto (classes de projeto, cápsulas e subsistemas)
Modelo de Análise e Projeto (classes de análise)
Modelo de Casos de Uso
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Passos para Projetar Arquitetura
1. Mapear classes de análise em elementos (classes, cápsulas e subsistemas) de projeto
2. Identificar oportunidades de reuso3. Definir a estrutura da aplicação
Análise e Projeto OO com UML e Padrões|
173
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Passo 1: Mapear classes de análise em elementos (classes, cápsulas e
subsistemas) de projeto
Identificar classes de projetoIdentificar subsistemasEspecificar a interface dos subsistemasFazer o mapeamento1 classe de análise pode dar origem a 0 ou mais elementos de projeto
Análise e Projeto OO com UML e Padrões|
174
Mapeamento m : n
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Identificando classes de projeto
• Uma classe de análise simples, que representa uma única abstração, é mapeada para uma única classe de projeto –Exemplo: classes de entidade
• Classes de análise muito simples podem até ser combinadas em uma única classe de projeto
• Em geral, classes de análise complexas podem ser divididas em várias classes ou transformadas em um pacote ou subsistema
Análise e Projeto OO com UML e Padrões|
175
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Identificando classes de projeto
Classe Conta Tem duas responsabilidades distintas: controle de
acesso e conta bancária Na realidade, modelam duas entidades diferentes
A separação favorece o reuso Por exemplo, ContaCorrente é utilizado para clientes
que não têm acesso à internet.
Análise e Projeto OO com UML e Padrões|
176
1
1
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Identificando subsistemasAntes, vamos revisar alguns conceitos...
Qual a diferença entre subsistemas e pacotes?
Como se descreve o comportamento de um subsistema?
Qual a grande vantagem associada aos subsistemas?
Análise e Projeto OO com UML e Padrões|
177
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Subsistemas e interfaces: notação
Análise e Projeto OO com UML e Padrões|
178
<<subsystem>>Nome subsistema
<<subsystem>>Nome subsistema
Atributos
Realização
Nome da interface
Métodos
<<interface>>Nome da interfaceAtributosMétodos
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Por que usar subsistemas?
Subsistemas permitem dividir o sistema em partes independentes (que se tornarão componentes) Cada subsistema pode ser desenvolvido,
testado e possivelmente implantado independentemente dos demais
Um subsistema pode representar uma abstração (no projeto) de produtos ou sistemas externos que serão incorporados na implementação
Análise e Projeto OO com UML e Padrões|
179
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Identificando subsistemas• Classes de análise
–Classes de fronteira (interfaces com sistemas externos e com usuários)
–Classes que fornecem serviços complexos • Componentes reusáveis
–Software de comunicação –Suporte ao acesso a BD –Estruturas de dados –Bibliotecas de utilitários–Produtos específicos da aplicação
Análise e Projeto OO com UML e Padrões|
180
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Identificando subsistemas
Análise e Projeto OO com UML e Padrões|
181
<<subsystem>>Subsistema X
Classe A
Y()Z() Y()
Z()
<<interface>>Interface A
Classe complexa
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
A classe fachada
Análise e Projeto OO com UML e Padrões|
182
Interface <<subsystem>>nomeSubsistema
FachadaSubsistemaISubSistema
Além da interface, é destacada uma classe fachada de cada subsistema
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Análise e Projeto OO com UML e Padrões|
183
Análise
Projeto
Identificando subsistemas
<<boundary>>ComunicacaoOperadoraCartao
enviar()
<<subsystem>>SubsistemaComunicacaoOperadoraCartaoISubsistemaComunicacao
OperadoraCartao
enviar()
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Pagamento do Qualiti Card
Análise e Projeto OO com UML e Padrões|
184
ISubsistemaComunicacaoOperadoraCartao
enviar()
FachadaComunicacaoOperadoraCartao
PagamentoCartao
Contexto do subsistema
ControladorPagamentoQualitiCard
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Passo 2. Identificar oportunidades de reuso
• Internas ao sistema–Similaridades entre pacotes e subsistemas
• Externas ao sistema–Componentes disponíveis no mercado–Componentes de aplicações já desenvolvidas–Componentes que podem se tornar reusáveis
para outros projetos
Análise e Projeto OO com UML e Padrões|
185
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Identificando oportunidades de reuso
A partir das interfaces de subsistemas ou componentes existentes analisar onde estes podem ser reutilizados Para um candidato a subsistema Procure interfaces similares (podendo requerer
engenharia reversa de subsistemas existentes) Tente adaptar a interface nova às existentes, ou tornar
as existentes mais gerais Substitua a interface nova por existentes
Análise e Projeto OO com UML e Padrões|
186
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Passo 3. Definir a estrutura da aplicação
Definir as camadas da aplicaçãoDeterminar o meio de armazenamento que será utilizadoAgrupar as classes, cápsulas e protocolos em pacotes e especificar a fachada da aplicação
Análise e Projeto OO com UML e Padrões|
187
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Definir as camadas da aplicação
O arquiteto pode seguir um padrão já existente para estruturar a aplicaçãoSe o arquiteto adotar uma estrutura diferente do padrão, deve descrevê-la no Documento da ArquiteturaO arquiteto também pode definir novos padrões ou atualizar orientações já existentes
Análise e Projeto OO com UML e Padrões|
188
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Estruturação em camadasSeparação do código: interface com o usuário (GUI) comunicação regras de negócio acesso a dados
Análise e Projeto OO com UML e Padrões|
189
Interface com o usuário(GUI)
Comunicação
Negócio
Dados
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Benefícios• Modularidade:
–Dividir para conquistar–Separação de conceitos–Reusabilidade–Extensibilidade
• Mudanças em uma camada não afetam as outras, desde que as interfaces sejam preservadas–plug-and-play
Análise e Projeto OO com UML e Padrões|
190
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
BenefíciosUma mesma versão de uma camada trabalhando com diferentes versões de outra camada várias GUIs para a mesma aplicação vários mecanismos de persistência
suportados pela mesma aplicação várias plataformas de distribuição para
acesso a uma mesma aplicação
Análise e Projeto OO com UML e Padrões|
191
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Camada de negóciosResponsável por implementar a lógica do negócioClasses inerentes ao domínio da aplicação: classes básicas do negócio coleções de negócio fachada do sistema
Análise e Projeto OO com UML e Padrões|
192
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Classes básicas do negócio
Representam conceitos básicos do domínio da aplicação
Análise e Projeto OO com UML e Padrões|
193
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Coleções de negócioRepresentam conjuntos de objetos das classes básicasResponsáveis pela inclusão, remoção, atualização e consultas a instâncias das classes básicasEncapsulam as verificações e validações inerentes ao negócio
Análise e Projeto OO com UML e Padrões|
194
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Fachada do sistemaSegue o padrão de projeto FacadeRepresenta os serviços oferecidos pelo sistemaCentraliza as instâncias das coleções de negócio e/ou controladoresGerencia as transações do sistema
Análise e Projeto OO com UML e Padrões|
195
CadastroContas CadastroPagamentosCartao
CadastroContas
Fachada
CadastroPagamentosCartao
ControladorPagamentoQualitiCard
Fachada
efetuarPagamentoQualitiCard()
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Camada de dadosResponsável pela manipulação da estrutura física de armazenamento dos dadosIsolam o resto do sistema do meio físico usadoClasses coleções de dados
Análise e Projeto OO com UML e Padrões|
196
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Coleções de dadosExecutam inclusões, remoções, atualizações e consultas a instâncias das classes básicas no meio de armazenamento usadoImplementadas de acordo com o meio físico usado
Análise e Projeto OO com UML e Padrões|
197
RepositorioContasBDR
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Coleções de dadosDependem do meio de armazenamento!
Análise e Projeto OO com UML e Padrões|
198
RepositorioContasBDR
RepositorioContasBDOO
RepositorioContasArquivo
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Independência do meio de armazenamento
Como isolar as coleções de negócio de mudanças na coleção de dados correspondente?
Análise e Projeto OO com UML e Padrões|
199
RepositorioContasBDR RepositorioContasArquivo
CadastroContas
<<interface>>RepositorioContas
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Interface negócio-dadosSugestão de serviços
Análise e Projeto OO com UML e Padrões|
200
<<interface>>RepositorioContas
inserir(conta: Conta): voidatualizar(conta: Conta): voidremover(conta: Conta): voidconsultarConta(login: String): Conta
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Juntando tudo - Visão geral da arquitetura
Análise e Projeto OO com UML e Padrões|
201
GUI / Comunicação
NEGÓCIO
Interfaces negócio-dados
DADOS
Fachada
TelaLogin
TelaPagamentoQualitiCard
ControladorLogin
ControladorPagamentoQualitiCard
CadastroPagamentosCartao
...ContaInternet PagamentoCart
ao
IRepositorioContasInternet IRepositorioPagamentosCartao
RepositorioPagamentosCartaoBDR
RepositorioPagamentosCartaoBDOO
RepositorioContasInternetBDR
RepositorioContasInternetArquivo
CadastroContasInternet
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Login e Efetuar Pagamento do Qualiti Card
Análise e Projeto OO com UML e Padrões|
202
Mapeamento entre análise e projetoClasses de Análise Elementos de Projeto
FachadaTelaMenuDataHora
Conta ContaInternetContaCorrente
CadastroContas
CadastroPagamentosCartao CadastroTransacoesIRepositorioTransacoesRepositorioTransacoesBDR
ComunicacaoOperadoraCartao SubsistemaComunicacaoOperadoraCartaoISubsistemaComunicacaoOperadoraCartaoFachadaComunicacaoOperadoraCartao
CadastroContasInternetIRepositorioContasInternetRepositorioContasInternetBDRCadastroContasCorrenteIRepositorioContasCorrenteRepositorioContasCorrenteBDR
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Login e Efetuar Pagamento do Qualiti Card
Análise e Projeto OO com UML e Padrões|
203
Projeto da arquitetura
Comprovante
FachadaComunicacaoOperadoraCartao
Hora
Data
PagamentoCartaonumeroFaturacontaBancariavalor
RepositorioContasCorrenteBDR
RepositorioContasInternetBDR
RepositorioPagamentosCartaoBDR
ContaCorrente
ContaInternet
1
1
1
1
IRepositorioContasCorrente
TelaLogin TelaMenu TelaPagamentoQualitiCard
IRepositorioPagamentosCartaoIRepositorio
ContasInternet
ControladorLogin
CadastroContasCorrente
1
1
1
1
Fachada 1
0..n
1
0..n
1
0..n
1
0..n 0..n
1
0..n
1
1
1
1
ISubsistemaComunicacaoOperadoraCartao
CadastroPagamentosCartao
1
1
1
1
CadastroContasInternet
1
1
1
1
1
1
1
1
ControladorPagamentoQualitiCard
1
1
1
1
1
1
1
11
1
1
1
1
1
1
1
1
1
1
1
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Exercício – Qualiti Internet Banking
Dado: As classes de análise do caso de uso Realizar Doc A tabela de mapeamento e o projeto de arquitetura de
Efetuar Login e Efetuar Pagamento do Qualiti Card Identificar para o Realizar Doc: subsistemas e suas interfaces elementos de projeto (classes e subsistemas)
Produzir: Tabela mapeando as classes de análise nos elementos
de projeto Diagrama de contexto dos subsistemas (opcional) Projeto da arquitetura com incluindo Realizar DOC
Análise e Projeto OO com UML e Padrões|
204
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Agrupar as classes em pacotesÀ medida que os elementos de projeto são identificados, a complexidade do modelo vai aumentandoPara organizá-lo, os elementos devem ser agrupados em pacotesAs camadas guiam essa organização
Análise e Projeto OO com UML e Padrões|
205
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Critérios para definição dos pacotes
• Acoplamento e Coesão–Agrupa as classes em bibliotecas–Exemplo: cliente, conta, banco, util, etc.
• Distribuição – usuário–Agrupa as classes por locais de implantação–Exemplo: clienteRecife, clienteSaoPaulo, etc.
• Segurança–Agrupa as classes por permissão de acesso–Exemplo: gerência, programadores, etc.
Análise e Projeto OO com UML e Padrões|
206
Evite dependências cíclicas
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Pacote GlobalPode ser usado por todos os outros pacotes classes utilitárias
Não é necessário explicitar as dependências
Análise e Projeto OO com UML e Padrões|
207
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Efetuar Login e Efetuar Pagamento do Qualiti Card
Organização de pacotes
Análise e Projeto OO com UML e Padrões|
208
subsistemaComunicacaoOperadoraCartao
controladores
GUIconta transacaoutil
<<global>>
protocolos
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – Pacote conta
Análise e Projeto OO com UML e Padrões|
209
IRepositorioContasCorrente
<<Interface>>
CadastroContasCorrente<<entity collection>>
1
1
1
1
RepositorioContasCorrenteBDR
ContaCorrentenumerosaldo
getSaldo()debitar()
<<entity>>
ContaInternetloginsenha
<<entity>>11 11 IRepositorioContasInternet
<<Interface>>
CadastroContasInternet<<entity collection>>
1
1
1
1
RepositorioContasInternetBDR
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
QIB – PacotesDependência entre pacotes
Análise e Projeto OO com UML e Padrões|
210
<<global>>util
controladores
GUI
conta
<<subsystem>>subsistemaComunicacaoOperadoraCartao
transacao
ISubsistemaComunicacao OperadoraCartao
protocolos
Copy
right
© 2
008
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Copy
right
© 2
006
Qual
iti. T
odos
os d
ireito
s res
erva
dos.
Exercício – Qualiti Internet Banking
• Dado:–Os elementos de projeto–A estrutura definida para a aplicação
• Definir os pacotes da aplicação e os elementos que devem estar presentes em cada pacote (incluir os elementos do caso de uso Realizar DOC)
• Elaborar um diagrama mostrando as dependências entre pacotes (opcional
Análise e Projeto OO com UML e Padrões|
211
Análise,e Projeto OO com UML para Sistemas RT| 212
top related