Análise e Projeto OO com UML e Padrões Augusto Sampaio - acas Pedro Antonino – prga2 (Monitor) Agosto, 2013 Parte do material cedido pela Qualiti Software

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?


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

http://www.youtube.com/watch?v=dbG3FhdE-Ss

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


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

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


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


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


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


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


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


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.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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)


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


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


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


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?


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:


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)


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


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:


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:


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


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


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


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)


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


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


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


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”


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


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


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


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


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


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


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.


• 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


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


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


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


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


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


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


96

Realizações de casos de uso e projeto de subsistemas

ArquitetoMapeamento das Classes de Análise em Elementos de Projeto



Revisor


Projetista de Banco de 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.

Responsáveis e Artefatos (SOA)


97

Projeto de componentes

Arquiteto

Modelo de Interação de Serviços


Arquitetura de Serviços

Revisor



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


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


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.


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


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


101


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.



105


Revisar Projeto




Revisor de projeto


Projetar Subsistemas/componentes


Analista deSistemas

Projetar classes


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.



106


Revisar Projeto




Revisor de projeto


Projetar Subsistemascomponentes


Analista deSistemas

Projetar classes


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!


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.




Analisar Caso de Uso

Glossário Modelo de Casos de Uso

Diagrama de Classes


Diagrama de Colaboraçã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.

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


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


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



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


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


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


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


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!


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


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


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


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


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.


Descrição inicial


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.


Fluxo de eventos principal


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.


Fluxo de eventos secundários


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.


Classes de entidade


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


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


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


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.


Encontrando classes de controle


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


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.



Conta<<entity>>

Cliente<<entity>>

CartaoCredito<<entity>>

TelaPagamentoQualitiCard<<boundary>>


Mensagem<<entity>>

CodigoBarras<<entity>>

ComunicacaoOperadoraCartao<<boundary>>


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


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


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


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


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


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



Classes persistentes

CadastroPagamentosCartao<<entity collection>>

CadastroClientes<<entity collection>>

CadastroContas<<entity collection>>


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.


Dado Artefatos de requisitos do caso de uso

realizar doc Classes de entidade

Produzir Identificação das classes que deverão ser

persistentes


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


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


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


Classes de Análise Diagrama de

Colaboração

Caso de Uso


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)


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


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


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


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



: 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


: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


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



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


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


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


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



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



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.



Classes com responsabilidades

Conta

getSaldo()debitar()

<<entity>>


TelaPagamentoQualitiCard

efetuarPagamentoQualitiCard()

<<boundary>>


CadastroPagamentosCartao

inserir()


CadastroContas

consultarConta()atualizar()


ControladorPagamentoQualitiCard


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


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.


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


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


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


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


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



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.



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.



Diagrama de classes com relacionamentos e atributos

Contanumerosaldo

getSaldo()debitar()

<<entity>>

ComprovantepagamentoCartao

<<entity>>

PagamentoCartaonumeroFaturadatahoravalorcontaBancaria

<<entity>>



<<boundary>>

CadastroContas

consultarConta()atualizar()


0..n0..n


inserir()


0..n0..n

ComunicacaoOperadoraCartao

enviar()

<<boundary>>


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.


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


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


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



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


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.




Revisar Projeto




Revisor de projeto


Projetar Subsistemas


Analista deSistemas

CheckList bla bla bla blabla

Projetar classes


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


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


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.



172

Arquiteto Projetar Arquitetura



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)


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


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


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


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.


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?


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


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


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


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


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


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.



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.



184

ISubsistemaComunicacaoOperadoraCartao

enviar()

FachadaComunicacaoOperadoraCartao

PagamentoCartao

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

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


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


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


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


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


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


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


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


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


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


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


195

CadastroContas CadastroPagamentosCartao

CadastroContas

Fachada



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.

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


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


197


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!


198


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?


199

RepositorioContasBDR RepositorioContasArquivo

CadastroContas


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


200


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


201

GUI / Comunicação

NEGÓCIO

Interfaces negócio-dados

DADOS

Fachada

TelaLogin


ControladorLogin



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


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.



203

Projeto da arquitetura

Comprovante

FachadaComunicacaoOperadoraCartao

Hora

Data

PagamentoCartaonumeroFaturacontaBancariavalor

RepositorioContasCorrenteBDR


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


1

1

1

1

CadastroContasInternet

1

1

1

1

1

1

1

1


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.


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


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


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.


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


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.


Organização de pacotes


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


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


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


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.


• 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


211


Documents

Análise e Projeto OO com UML e Padrões Augusto Sampaio - acas Pedro Antonino – prga2 (Monitor) Agosto, 2013 Parte do material cedido pela Qualiti Software