Apoo Jacques Ufcg

Anlise e Projeto de Sistemas Orientados a Objeto
Page 1 of 1
Anlise e Projeto de Sistemas Orientados a Objeto Objetivos Gerais

Aprender a analisar, projetar e implementar sistemas usando a orientao a objeto (OO). Ao terminar a disciplina, o aluno ter desenvolvido um projeto prtico completo utilizando os conceitos gerais apresentados.
Objetivos Especficos
Introduzir os conceitos bsicos relacionados com a orientao a objeto, incluindo sua aplicabilidade a Anlise Orientada a Objeto (OOA), o Projeto Orientado a Objeto (OOD) e a Programao Orientada a Objeto (OOP) Apresentar a linguagem de modelagem padro de mercado Unified Modeling Language (UML) largamente utilizada para a Anlise e Projeto de sistemas de software de grande escala Apresentar um processo completo de desenvolvimento de software utilizvel com a linguagem UML Exemplificar OOA, OOD, OOP, UML e o processo de desenvolvimento atravs de um estudo de caso completo Apresentar tcnicas bsicas de Projeto Orientado a Objeto. O enfoque mostrar em que consiste um bom projeto. Apresentar Padres de Projeto, chaves para o bom projeto de software. Apresentar rapidamente assuntos mais "quentes" relacionados com a tecnologia OO. Permitir que o aluno aprofunde seu conhecimento dos conceitos apresentados atravs da elaborao de um sistema completo
apoo-1 programa prxima
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\apoo1.htm
04/02/2012
Anlise e Projeto de Sistemas Orientados a Objeto: Programa
Page 1 of 2
Anlise e Projeto de Sistemas Orientados a Objeto Programa

1. Introduo Anlise e Projeto de Sistemas Orientados a Objeto 1.1 Anlise e projeto orientados a objeto (Captulo 1 do livro de Larman) 1.2 Introduo a um processo de desenvolvimento (Captulo 2) 1.3 Modelos e artefatos (Captulo 3) 2. Fase de Planejamento e Elaborao 2.1 2.2 2.3 2.4 Estudo de caso: Terminal Ponto de Venda (PDV) (Captulo 4) Entendendo requisitos (Captulo 5) Use cases: descrio de processos (Captulo 6) Priorizao de use cases (Captulo 7)
3. Fase de Anlise 1 3.1 3.2 3.3 3.4 3.5 3.6 Elaborao de um modelo conceitual (Captulo 9) Modelo conceitual: adio de associaes (Captulo 10) Modelo conceitual: adio de atributos (Captulo 11) Construo do glossrio (Captulo 12) Comportamento dinmico: diagramas de sequncia (Captulo 13) Comportamento dinmico: contratos (Captulo 14)
4. Fase de Projeto 1 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Da anlise ao projeto (Captulo 15) Projeto arquitetural (Captulo 22) Descrio de use cases reais (Captulo 16) Diagramas de colaborao (Captulo 17) Padres para atribuir responsabilidades (Captulo 18) Projeto de solues com objetos e padres (Captulo 19) Visibilidade (Captulo 20) Diagramas de classe para a fase de projeto (Captulo 21) Esquema de banco de dados e mapeamento OO-Relacional (Captulo 38)
5. Fase de Implementao 5.1 5.2 5.3 5.4 Mapeamento do projeto para cdigo (Captulo 23) Programa exemplo em Java (Captulo 24) Testes de unidade Adicionando uma interface com o usurio
6. Fase de Anlise 2 6.1 6.2 6.3 6.4 6.5 6.6 6.7 Escolha de requisitos da segunda iterao (Captulo 25) Relacionando mltiplos use cases (Captulo 26) Extenso do modelo conceitual (Captulo 27) Generalizao (Captulo 28) Organizando o modelo conceitual com packages (Captulo 29) Refinamento do modelo conceitual (Captulo 30) Modelo conceitual no estudo de caso (Captulo 31)
04/02/2012
Anlise e Projeto de Sistemas Orientados a Objeto: Programa
Page 2 of 2
6.8 Comportamento do sistema: Diagramas de sequncia e contratos na Segunda Iterao (Captulo 32) 6.9 Comportamento do sistema: Diagramas de estado (Captulo 33) 7. Fase de projeto 2 7.1 7.2 7.3 7.4 Polimorfismo Interfaces Composio versus herana Padres de Projeto (Design Patterns) 7.4.1 O que so Design Patterns? 7.4.2 Elementos essenciais de um Design Pattern 7.4.3 Design Pattern: Factory Method 7.4.4 Design Pattern: Iterator 7.4.5 Design Pattern: Composite 7.4.6 Design Pattern: Strategy 7.4.7 Design Pattern: Decorator 7.4.8 Design Pattern: Template Method 7.4.9 Design Pattern: Observer 7.4.10 Comentrios finais sobre Design Patterns 8. Tpicos avanados 8.1 8.2 8.3 8.4
apoo-2 home
Refactoring Extreme Programming Frameworks Componentes
04/02/2012
1. Introduo Anlise e Projeto de Sistemas Orientados a Objeto
Page 1 of 1
1. Introduo Anlise e Projeto de Sistemas Orientados a Objeto

Anlise e projeto orientados a objeto Introduo a um processo de desenvolvimento Modelos e artefatos
intro programa
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\intro\index.htm
04/02/2012
Anlise e Projeto Orientados a Objeto
Page 1 of 4

Objetivos

Comparar e contrastar Anlise e Projeto Definir Anlise e Projeto Orientados a Objeto
O que vamos fazer na disciplina?
Saber uma linguagem de programao orientada a objeto (OO) no suficiente para criar sistemas OO

Tem que saber Anlise e Projeto OO (APOO) Isto , Anlise e Projeto usando uma perspectiva de objetos
Usaremos um estudo de caso para concretizar a discusso Usaremos a linguagem UML (Unified Modeling Language) para criar modelos (de anlise e de projeto)
Um modelo uma representao abstrata dos aspectos essenciais de um sistema O que "essencial" depende do momento da modelagem A UML usa uma representao principalmente grfica para representar os modelos UML muito popular hoje em dia para modelar sistemas
Usaremos Design Patterns (padres de projeto) para mostrar solues abstratas para problemas que surgem frequentemente durante o projeto de sistemas OO
Os patterns trataro principalmente de:
Como atribuir responsabilidades a objetos (uma das atividades mais difcil no desenvolvimento de sistemas OO) Como separar o que muda do que constante numa determinada situao, com o objetivo de ganhar flexibilidade
Para evitar "o efeito gelatina"
Explicaremos e seguiremos um processo de desenvolvimento que mostra claramente quais so as etapas a seguir para produzir software de qualidade
Veremos tambm quais artefatos devem ser produzidos na vrias fases e etapas do processo
O que Anlise e Projeto?
Diferenas entre anlise e projeto: tem mais do que uma definio empregada
Primeira alternativa:
A anlise modela o problema e consiste das atividades necessrias para entender o domnio do problema (o que deve ser feito). uma atividade de investigao. O projeto modela a soluo e consiste das atividades de criao (como pode ser feito)
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\intro\intro1.htm
04/02/2012
Page 2 of 4
Segunda alternativa:
A anlise consiste de todas as atividades feitas com ou para o conhecimento do cliente. A informao produzida aquela que o cliente deve discutir e aprovar O projeto inclui as atividades que resultam em informao que interessa apenas ao programador Com essa definio, a anlise invade um pouco o "lado da soluo", pois o cliente deve discutir alguns tipos de interaes que ocorrero na interface do usurio, etc.
Observe portanto que no definio binria que isole "anlise" de "projeto" Nesta disciplina, adotaremos a segunda alternativa, pois queremos associar as palavras "anlise" e "projeto" aos artefatos (deliverables) entregues nos final de cada fase
Um modelo de anlise deve ser aprovado pelo cliente e pode incluir alguma (pequena) discusso da soluo, principalmente no que diz respeito interface com usurio, etc.
Apesar do nome da disciplina, vamos ver tambm as fases de requisitos, implementao e testes
A obteno de requisitos frequentemente includa na fase de anlise ("anlise de requisitos")
04/02/2012
Page 3 of 4
O que Anlise e Projeto Orientados a Objeto (APOO)?
A perspectiva empregada de objetos (coisas, conceitos ou entidades) Durante a Anlise OO, a nfase est em achar e descrever objetos (ou conceitos) no domnio do problema
Por exemplo, num sistema de informao para uma biblioteca, alguns dos conceitos so Livro, Biblioteca, Usurio. Tais objetos podem ter atributos e responsabilidades
Durante o projeto orientado a objeto, a nfase est em achar objetos lgicos de software que podero ser eventualmente implementados usando uma linguagem de programao OO
Tais objetos pode ter atributos e mtodos
Durante a construo (programao OO), os objetos do projeto so implementados e testados
APOO versus AP Orientados a Funes (APOF)
Com ambas as tcnicas, usa-se decomposio (chamado modularizao em APOF) para lidar com a complexidade A APOF (tambm chamados de Anlise e Projeto Estruturados), a decomposio por funo ou processo
04/02/2012
Page 4 of 4
Por que queremos Orientao a Objeto? Quais so as vantagens?
As abstraes podem corresponder s coisas do domnio do problema

O nvel mais natural mais fcil comunicar-se com o usurio ou domain expert na linguagem dele
Os mesmos objetos existem em todas as fases e uma notao nica (objetos) facilita portanto a integrao entre fases de desenvolvimento (passar de uma fase para a outra)
Fases posteriores adicionam novos objetos mas os objetos do domnio do problema permanecem: so estveis Isso ajuda o rastreamento de decises de projeto e implementao
mais fcil entender o domnio do problema quando esta quebrado em pedaos: gerenciamento da complexidade atravs da modularizao O mesmo pode ser dito no domnio do computador (projetando e programando com objetos) A abstrao controla a complexidade (escondendo algo atravs da separao da interface e da implementao) A encapsulao facilita as mudanas (atravs do isolamento) A hierarquia (grafo de herana) permite uma melhor reutilizao Hierarquia promove a flexibilidade de fazer mudanas de forma localizada
Exemplo: novos trechos de programas podem usar uma sub-classe nova e cdigo antigo continua usando a superclasse e no toma conhecimento das mudanas Porm, h problemas de acoplamento com herana que veremos em outro captulo
A reutilizao de pedaos mais difcil usando paradigmas anteriores (modularizao via funes) porque no posso usar coisas pr-existentes to facilmente

Com objetos, posso dizer: "me d dois daqueles" porque objetos tm estado No posso fazer isso com funes porque elas no encapsulam estado
intro-1 programa prxima
04/02/2012
Modelos e Artefatos
Page 1 of 1
Modelos e Artefatos
Objetivos
Definir os modelos e artefatos a serem produzidos durante o proceso de desenvolvimento de software
Os modelos e outros artefatos (deliverables)
Artefatos da fase de elaborao

Documento de business case (investigao preliminar) Documento de oramento e cronograma Documento de especificao de requisitos

Requisitos funcionais (Modelo de use case) Requisitos no funcionais
Modelo conceitual inicial Glossrio Projeto arquitetural (poder incluir un Modelo de componentes) Refinamento dos requisitos funcionais (Modelo de use case) Refinamento do modelo conceitual (Modelo conceitual)
Fase de construo

Inclui vrios tipos de diagramas UML
Refinamento do projeto arquitetural (poder incluir un Modelo de componentes) Refinamento do glossrio Projeto de baixo nvel (Modelo de projeto)

Inclui vrios tipos de diagramas UML Esquema de banco de dados
Planos de testes Planos de publicao Planos de testes alfa, beta Planos de treinamento
Fase de implantao

intro-3 programa anterior
04/02/2012
2. Fase de Planejamento e Elaborao
Page 1 of 1
2. Fase de Planejamento e Elaborao

Estudo de caso: Terminal Ponto de Venda (PDV) Entendendo requisitos Use cases: descrio de processos Priorizao de use cases
plan programa
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\plan\index.htm
04/02/2012
Estudo de caso: Terminal Ponto de Venda (PDV)
Page 1 of 2

Objetivos
Introduzir o estudo de caso utilizado na disciplina
O Terminal de Ponto de Venda (PDV)
Nosso estudo de caso envolve um Terminal PDV

Um sistema computadorizado que registra vendas e trata de pagamentos Tipicamente usado numa loja de varejo Tipicamente est acoplado a um leitor de cdigo de barra
Trataremos do desenvolvimento do software que controla o terminal usando um processo de desenvolvimento iterativo-incremental

Falaremos de requisitos, anlise, projeto e implementao Este sistema envolve um sistema de informao tpico e nos far cruzar com muitas situaes tpicas
Arquitetura em camadas e nfase do estudo
Um sistema de informao tpico organizado usando as camadas apresentadas abaixo
As camadas arquiteturais apresentadas so:

04/02/2012
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\plan\plan1.htm
Page 2 of 2
Apresentao
Interface grfica, janelas Objetos representando conceitos do domnio (business objects) Contm o que se chama tambm business logic Objetos que no pertencem ao domnio do problema mas oferecem servios tais como interfaceamento para um banco de dados, etc. Mecanismos de armazenamento persistente (SGBDOO, SGBDR, SGBDOR)
Lgica de aplicao - Objetos do domnio de problema

Lgica de aplicao - Objetos de servio
Armazenamento
Usam-se Anlise e Projeto OO principalmente nas camadas de lgica de aplicao Falaremos em mais detalhes sobre arquiteturas em camadas na seo 4.2 (Projeto arquitetural) Boa parte da disciplina tratar do business logic A seo 4.9 tratar de objetos para servios de persistncia
plan-1 programa prxima
04/02/2012
Fase de Planejamento e Elaborao
Page 1 of 3
Entendendo Requisitos
Objetivos

Descrever os artefatos do processo de desenvolvimento relacionados aos requisitos Identificar e categorizar requisitos funcionais do sistema Identificar e categorizar requisitos no-funcionais do sistema (atributos do sistema)
Requisitos

Requisitos so uma descrio de necessidades ou desejos para um produto. Motivo da fase de levantamento de requisitos: saber que sistema deve ser construido Se houver sucesso no levantamento de requisitos, no haver surpresas desagradveis para o usurio na entrega do sistema Artefatos tpicos a serem criados

Breve descrio do sistema Descrio dos clientes alvo
Pode incluir como eles operam hoje e quais problemas eles enfrentam
Descrio das metas do sistema Descrio dos requisitos funcionais do sistema Descrio dos requisitos no funcionais do sistema
Usaremos o estudo de caso (Terminal PDV) para exemplificar a obteno de requisitos
Breve descrio do sistema
O objetivo do projeto de criar um sistema para um Terminal Ponto de Venda (TPDV) a ser usado no comrcio varejista.
Descrio dos clientes alvo
O cliente Xpto, Ltda., que vende TPDVs a lojas varejistas.
Descrio das metas do sistema
A meta bsica de melhorar a automao do balco de vendas, incluindo:

Checkout mais rpido para o cliente Anlise rpida e precisa das vendas Automatizar o controle de estoque
Observe que, no Brasil, haveria outras consideraes de ordem legal, incluindo o recolhimento
04/02/2012
Page 2 of 3
de impostos
Descrio dos requisitos funcionais do sistema

Requisitos funcionais descrevem o que o sistema deve fazer As categorias de requisitos funcionais so:
Categoria de funcionalidade Significado Usurio est ciente de que a funo est sendo feita Embora a funo seja feita, ela invisvel ao usurio. Tal funcionalidade frequentemente esquecida ao levantar requisitos Funcionalidade opcional; sua adio no afeta outras funes ou o custo significativamente
Evidente Escondida Friso
Funcionalidade bsica
A lista abaixo no exaustiva mas servir de exemplo para explicar as atividades do processo de desenvolvimento Observe que o levantamento dos requisitos funcionais deve ser completado usando use cases (discutidos no prximo captulo)

Use cases descrevem os processos do domnio do problema A lista abaixo pode servir para nortear o levantamento de use cases Alguns desenvolvedores usam apenas use cases para levantar os requisitos funcionais De toda forma, a tabela abaixo exemplifica o que se entende por requisito funcional
Funcionalidade Registrar a vanda corrente (os itens comprados) Calcular o total de venda, incluindo impostos e descontos aplicveis Evidente Evidente Categoria
Referncia R1.1 R1.2
R1.3
Capturar a informao do item sendo comprado atravs de um leitor de cdigo de barra, ou manualmente usando Evidente um cdigo de produto tal como o Universal Product Code (UPC) Dar baixa no inventrio ao terminar uma venda Manter um log de vendas feitas O caixa deve fazer login com uma identificao e uma senha antes de usar o sistema Deve prover um mecanismo persistente de armazenamento Prover integrao com outros sistemas Exibir a descrio e o preo do item sob considerao Escondida Escondida Evidente Escondida Escondida Evidente
R1.4 R1.5 R1.6 R1.7 R1.8 R1.9
Funcionalidade associada ao pagamento

Referncia Funcionalidade Tratar de pagamentos vista com dinheiro, capturando o valor entregue e calculando o troco Tratar de pagamentos por carto de crdito, capturando a informao do carto atravs de um leitor de cartes ou por digitao manual e autorizando o pagamento usando o servio de autorizao de crdito da loja (um sistema externo) usando uma conexo via modem Tratar de pagamentos por cheque, capturando a informao de identidade/CPF por digitao manual e autorizando o pagamento usando o servio de verificao de cheques da loja (um sistema externo) usando uma conexo via modem Evidente Categoria
R2.1
R2.2
Evidente
R2.3
Evidente
R2.4
Lanar os pagamentos via carto de crdito no sistema de contas a receber, j que o servio de carto de crdito Escondida deve dinheiro loja
Descrio dos requisitos no funcionais do sistema
Requisitos no funcionais incluem requisitos das seguintes categorias

Facilidade de uso necessria Tipo de interface desejada Quem utilizar o produto Volume de utilizao (nmero de usurios, nmero de transaes, ...) Hardware e software alvo para o produto Qualidade/robustez
04/02/2012

Page 3 of 3
Tolerncia a falha Desempenho Segurana Compatibilidade com outros produtos/verses e necessidades de migrao Necessidades de internacionalizao do produto Necessidades de customizao do produto pelo cliente Suporte Preo da soluo Documentao necessria Uso de padres Aspectos legais Integrao com outros produtos Packaging Requisitos de instalao Riscos aceitveis
Os requisitos no funcionais tambm so chamados de atributos do sistema Alguns exemplos seguem

Atributo Detalhes ou condio limite (Condio limite) Ao registrar um item sendo vendido, a descrio e preo devem aparecer em 2 segundos (Detalhe) Usar formulrios para entrada de dados e dialog boxes
Tempo de resposta
Tipo de interface (Detalhe) Maximizar a facilidade de uso via teclado e no via mouse Tolerncia a falhas Plataformas operacionais
plan-2 programa anterior prxima
(Condio limite) Deve fazer log dos pagamentos autorizados via carto de crdito em 24 horas, mesmo com falhas de energia ou de dispositivo (Detalhe) Microsoft Windows 95, Windows, 98, Windows NT e Windows 2000
04/02/2012
Page 1 of 4
Use Cases: Descrio de Processos

Objetivos

Identificar e escrever use cases Diagramar use cases Constrastar use cases de alto nvel e expandidos Contrastar use cases essenciais e reais
Introduo

Use cases so usados para descrever os processos do domnio de problema So uma excelente forma de explorar e documentar os requisitos funcionais Antes de elaborar use cases, pode valer a pena elaborar uma tabela de funes bsicas como vimos na seo anterior
Use cases
Um use case um documento narrativo que descreve uma sequncia de eventos feitos por um ator no uso de um sistema para completar um processo de interesse deste ator.

Use cases so "estrias" ou "casos" no uso de um sistema As estrias acabam revelando as funcionalidade desejada do sistema
Em UML, um use case representado assim:
Exemplo de um Use Case de alto nvel: Comprar item
Segue uma breve descrio do processo de comprar um item numa loja quando um TPDV utilizado
Use case: Comprar item Atores: Cliente, Caixa Tipo: primrio (a ser explicado Descrio: Um cliente chega ao caixa O caixa registra os itens No fim, o cliente sai com

logo) com itens a comprar. comprados e recebe pagamento. os itens comprados.
UML no fora o formato exato de um Use Case. A clareza na descrio o essencial. Iniciamos acima com um Use Case de alto nvel, fornecendo poucos detalhes
til para entender rapidamente os processos principais envolvidos
Exemplo de um Use Case expandido: Comprar item com dinheiro vivo
Ignoramos a questo de dar baixa no inventrio aqui
Use case: Comprar item com dinheiro Atores: Cliente (iniciador), Caixa Propsito: Capturar uma venda e seu pagamento em dinheiro Resumo: Um cliente chega ao caixa com itens a comprar. O caixa registra os itens comprados e recebe pagamento. No fim, o cliente sai com os itens comprados. Tipo: primrio e essencial Referncia cruzada: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1 (pode fazer referncia a outros use Cases) Sequncia tpica de eventos
Ao do ator 1. O Use Case inicia quando um cliente chega a um caixa munido de TPDV com itens a comprar 3. Determina o preo do item e adiciona a informao ao total da transao de venda Resposta do sistema
2.
O caixa registra a identificao de cada item
04/02/2012

Se houver mais itens, o caixa pode informar a quantidade tambm 4. 6. 7. Ao completar a entrada dos itens, o caixa indica este fato ao TPDV O caixa informa o total da venda ao cliente O cliente efetua o pagamento com dinheiro, possivelmente maior que o total da venda 9. 8. O caixa registra a quantidade de dinheiro recebida Mostra o valor do troco ao cliente Gera um recibo impresso 5. A descrio e preo do item corrente so exibidos Calcula e apresenta o total da venda
Page 2 of 4
10.
O caixa deposita o dineiro recebido e extrai o troco a devolver O caixa entrega o troco e o recibo impresso ao cliente
11.
Faz log da venda completada
12.
O cliente sai da loja com os itens comprados
Sequncias alternativas: Linha 2: Entrada de um identificador invlido. Indica erro. Linha 7: Cliente no tinha dinheiro suficiente. Cancela transao de venda. Atores
Um ator uma entidade externa ao sistema que, de alguma forma, participa das estrias relatadas no Use Case Um ator tipicamente estimula o sistema com eventos de entrada ou recebe algo so sistema Atores so representados pelo papel que desempenham (e no por nome de pessoa, etc.) Em UML, o cone que representa um ator o seguinte:
Para cada Use Case, um dos atores o iniciador e outros atores podem ser participantes Atores correspondem frequentemente a papeis de seres humanos mas, s vezes, outros sistemas ou dispositivos eltricos ou mecnicos podem ser atores
O motivo de usar Use Cases

Para decidir e descrever a funcionalidade de comum acordo com o cliente Servem de documento bsico de referncia durante todo o processo sobre o que foi prometido Serve como base para elaborar os testes funcionais do sistema final Para poder rastrear requisitos funcionais dentro dos modelos de anlise, projeto e implementao
Sabemos que requisitos causaram o aparecimento de determinadas solues
Um erro frequente ao criar Use Cases
Iniciantes costumam representar cada etapa, operao ou transao como Use Case separado (exemplo: login como Use Case) Um Use Case deve representar uma iterao completa e til para os atores Use Cases so geralmente processos inteiros, cabo-a-rabo e normalmente envolvem muitas etapas ou transaes
Eles modelam os Business Processes do negcio
Etapas comuns a vrios Use Cases podem ser agrupados em Use Cases Abstratos, no sentido de minimizar a duplicao de informao
Falaremos mais sobre isso em outro captulo Sacar dinheiro num caixa eletrnico Fazer pedido de um produto Cadastrar-se num curso numa escola Verificar a grafia de um documento num processador de texto Atender uma chamada telefnica
Exemplos de processo:

Identificao de Use Cases

De forma geral, deve-se verificar a lista de requisitos levantados e usar tcnicas de brainstorming Duas formas comuns:
04/02/2012
Page 3 of 4
Foco nos atores

Identificar os atores relacionados com o sistema Para cada ator, identificar os processos que eles iniciam ou dos quais participam Para identificar atores, faa as seguintes perguntas sobre o sistema:

Quem vai usar a funcionalidade principal do sistema (atores principais)? Quem vai precisar do suporte do sistema para desempenhar suas tarefas do dia-a-dia? Quem dever manter e administrar o sistema (atores secundrios)? Que dispositivos de hardware o sistema precisa manusear? Com que outros sistemas este interage? Quem ou o que tem interesse nos resultados (valores produzidos) do sistema?
Foco nos eventos

Identificar os eventos externos aos quais um sistema deve responder Relacione os eventos aos atores e Use Cases
Diagramas de Use Case
Em UML, um diagrama de Use Case tem o formato seguinte:
O diagrama identifica e relaciona os Use Cases e os relaciona com os atores Observe que o diagrama de Use Case determina com preciso o que o "sistema"
Use Cases Primrios, Secundrios e Opcionais

Use Cases primrios: representam processos importantes e/ou comuns (comprar itens) Use Cases secundrios: representam processos menos importantes ou raros (Pedido de reposio de estoque) Use Cases opcionais: representam processos que talvez no sejam considerados
Use Cases Essenciais versus Reais
Use Cases essenciais: possui uma descrio breve, muito abstrata, sem detalhes, sem mencionar tecnologias empregadas (poderia incluir uma frase: "cliente se identifica" sem maiores detalhes porque a forma de identificao pode mudar com tempo e com a disponibilidade de tecnologia) Use Cases reais: muito mais concretos, mencionando tecnologias correntemente usadas ("cliente se identifica passando seu Smart Card no leitor")
Use Cases essenciais so usados mais cedo no processo (antes do design) e Use Cases podem ser transformados em Use Cases reais durante o design Durante o levantamento de requisitos

Durante o processo de desenvolvimento:
Crie Use Cases em formato de alto nvel Crie um diagrama de Use Cases, indicando os relacionamentos Selecione os Use Cases mais crticos, que devero influenciar o sistema mais ou que envolvam mais risco e escreva uma verso Expandida Essencial Priorize os Use Cases (prximo captulo) Escreva uma verso Expandida Essencial dos Use Cases sendo atacados na iterao corrente (se j no estiver pronta) Escreva uma verso Expandida Real dos Use Cases sendo atacados na iterao corrente
Durante a fase de anlise
Durante a fase de projeto
Estudo de Caso: O sistema TPDV

Identificar o sistema, atores e Use Cases
O sistema ser a combinao de hardware (o terminal) e software executando nele

04/02/2012
Page 4 of 4
Os atores relevantes e alguns processos que eles iniciam so:

Fecha caixa Compra itens Devolve itens Start Up Shut Down
Caixa Cliente Gerente
Administrador do sistema Adiciona novos usurios
Escrever Use Cases em formato de alto nvel
Use case: Comprar item Atores: Cliente (iniciador), Tipo: primrio Descrio: Um cliente chega ao caixa O caixa registra os itens No fim, o cliente sai com
Caixa com itens a comprar. comprados e recebe pagamento. os itens comprados.
Use case: Start Up Atores: Gerente Tipo: primrio Descrio: Um gerente liga um TPDV para o preparar para uso pelos Caixas. O gerente verifica que a data e horas esto corretas. O sistema est pronto para uso pelos Caixas
Elaborar um diagrama de Use Cases
Escrever alguns Use Cases no formato Expandido Essencial
Favor ver livro, seo 6.16.5
Priorizar os Use Cases
Ver prximo captulo
plan-3 programa anterior prxima
04/02/2012
Priorizao de Use Cases
Page 1 of 2

Objetivos

Priorizar Use Cases Quando necessrio, criar verses simplificadas de Use Cases Alocar os Use Cases s iteraes de desenvolvimento
Introduo

De forma geral, cada iterao da fase de construo vai tratar de um ou mais Use Cases identificados s vezes, um Use Case pode ser tratado em duas ou mais iteraes, com verses simplificadas tratadas primeiro
Normalmente, quem prioriza os Use Cases o cliente (ou Domain Expert)

Os tcnicos podem ajud-lo fornecendo estimativas de esforo de desenvolvimento para os vrios Use Cases Mas lembre que o cliente que sabe o Business Value de cada Use Case Afetam muito a arquitetura

Alguns parmetros que podem aumentar a prioridade de um Use Case
O primeiro incremento deveria ser um teste arquitetural (uma validao da viabilidade da arquitetura) O processo de desenvolvimento deve ser "architecture-centric"
Pouco esforo dando muito insight sobre o projeto do sistema Use Cases que envolvem muito risco, so crticos no tempo
O processo de desenvolvimento deve ser "risk-confronting" Deixe o cliente falar! Deixe o cliente falar!
Envolvem business processes fundamentais
Podem aumentar significativamente o lucro ou diminuir as despesas/custos
O estudo de caso
Uma possibilidade de priorizao

Prioridade Use Case Comprar itens Adicionar novos usurios Login Devolver itens Fechamento de caixa Start Up Shut Down Afeta a segurana Afeta a segurana Processo importante; afeta a contabilidade Efeito mnimo na arquitetura Definio depende de outros Use Cases Efeito mnimo na arquitetura Justificativa Satisfaz quase todos os critrios de aumento de prioridade
Alta Mdia
Baixa
O Use Case Start Up poderia ser feito numa verso mnima se ele for necessrio ao funcionamento do resto Escalonamento final dos Use Cases no estudo de caso

Teremos que atacar Comprar Itens na primeira iterao alm de uma verso reduzida de Start Up Como Comprar Itens complexo, pode-se quebr-lo em vrias verses incrementais:
Comprar Itens verso 1:

Pagamento em dinheiro apenas Sem atualizao de estoque Loja stand-alone, sem integrao a uma organizao maior Entrada manual de UPC, sem leitor de cdigo de barras Sem clculo de impostos
04/02/2012

Page 2 of 2
Sem descontos especiais Sem log in Sem manuteno de perfil de usurio (preferncias, ...) Sem controle contbil do valor em caixa Recibo no contm informao completa (sem ID do Caixa, ID do TPDV)
Comprar Itens verso 2: (todas as formas de pagamentos) Comprar Itens verso 3: (verso completa)
As trs verses (alm dos outros Use Cases) so distribudas ao longo dos incrementos
plan-4 programa anterior
04/02/2012
3. Fase de Anlise 1
Page 1 of 1
3. Fase de Anlise 1

Elaborao de um modelo conceitual Modelo conceitual: adio de associaes Modelo conceitual: adio de atributos Construo do glossrio Comportamento dinmico: diagramas de sequncia Comportamento dinmico: contratos
anal1 programa
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\anal1\index.htm
04/02/2012
Incio de uma Iterao de Construo
Page 1 of 6

Para iniciar uma iterao, lembre que certos refinamentos so feitos antes de iniciar a anlise detalhada da funcionalidade desejada na iterao O captulo que inicia agora trata de anlise, ou da elaborao de um modelo conceitual
Elaborao de um Modelo Conceitual

Objetivos

Criar um modelo conceitual inicial Distinguir entre atributos corretos e incorretos Adicionar conceitos de descrio, quando apropriado Comparar e contrastar os termos conceito, tipo, interface e classe
Introduo

O modelo conceitual o artefato mais importante criado durante a anlise O modelo conceitual ilustra os conceitos importantes do domnio do problema, suas associaes e atributos Falaremos de associaes e atributos nos prximos captulos Levantar um conjunto rico e expressivo de conceitos (objetos) durante a anlise ajuda muito a conduzir as fases de projeto e implementao importante lembrar que os conceitos levantados aqui so do domnio do problema e no conceitos associados a software
Modelos conceituais
Ao fazer anlise OO, a decomposio do domnio do problema utiliza objetos e no funes ou processos como na anlise estruturada Exemplo de um modelo conceitual (com conceitos, associaes e atributos)

Apenas a parte diagramtica est sendo mostrada UML permite associar descries mais detalhadas dos conceitos, atributos, etc.
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\anal1\anal1.htm
04/02/2012
Page 2 of 6
Criar o modelo conceitual ajuda a elaborar o glossrio, definindo os termos importantes do domnio do problema
Muito importante para a comunicao entre os envolvidos (clientes e desenvolvedores)
Modelos conceituais no representam entidades de software mas conceitos do domnio do negcio
Exemplo correto
Exemplos errados
Cuidado! Alguns profissionais acham correto introduzir responsabilidades (ou operaes) no modelo conceitual
Embora ningum ache certo introduzir mtodos (que implementam operaes) no modelo conceitual
Estratgias para identificar conceitos (objetos)
Regra fundamental: melhor ter conceitos demais (muitos conceitos de granularidade pequena) do que conceitos de menos no modelo conceitual Novos conceitos podem ser descobertos com tempo (quando se est identificando associaes ou atributos, por exemplo) e a elaborao de um modelo conceitual portanto uma atividade iterativa Na modelagem de dados para bancos de dados, h um critrio de modelagem que diz que algo sobre o qual no precisamos lembrar nada no precisa entrar no modelo conceitual
04/02/2012
Page 3 of 6
Com o ponto de visto de persistncia, a regra faz sentido Mas na modelagem OO, objetos com apenas comportamento (sem atributos) tambm so importantes (embora raros) e no devem ser excludos do modelo
Usando a lista de categoria de conceitos
Conceitos so comumente descobertos nas categorias da tabela seguinte
Os exemplos so referentes aos domnios de uma loja e reserva de passagem area

Categoria de Conceito Exemplos Terminal Ponto De Venda (TPDV) Aeronave Especificao de produto Descrio de um vo Loja Aeroporto Venda, Pagamento Reserva Item de detalhe de uma venda Caixa Piloto Loja, Prateleira Aeronave Item Passageiro Sistema de autorizao de carto de crdito Sistema de controle de trfego areo Fome Acrofbia (medo de altura) Departamento de vendas Voamos Baixo, Ltda. Venda, Roubo, Reunio Vo, Desastre, Aterrissagem
Objetos fsicos ou tangveis
Especificaes, projetos ou descries de coisas
Lugares
Transaes (um momento notvel) Detalhes de transao (Line item) Papeis de pessoas
Colees de outras coisas (containers)
Coisas dentro das colees
Outros sistemas externos a nosso sistema
Conceitos abstratos
Organizaes
Eventos
Processos (frequentemente no representado como conceito, Fazer a venda de um produto Fazer uma reserva de lugar num vo mas pode ocorrer) Regras e polticas Poltica de devoluo Poltica de cancelamento Catlogo de produtos Catlogo de peas Recibo, Plano de contas, Contrato de emprego Log de manuteno Linha de crdito Estoque Manual do empregado Manual de reparos
Catlogos Registros de assuntos financeiros, de trabalho, de contratos, legais Instrumentos e servios financeiros
Manuais, livros
Achando conceitos atravs de substantivos
Uma tcnica simples para a identificao de conceitos de isolar os substantivos nas descries textuais dos Use Cases
Muitos dos substantivos sero conceitos ou atributos

04/02/2012
Page 4 of 6
Exemplo: Use Case expandida "Comprar Item com Dinheiro Vivo"

Ao do ator Resposta do sistema
1.
O Use Case inicia quando um cliente chega a um caixa munido de TPDV com itens a comprar O caixa registra a identificao de cada item Se houver mais itens, o caixa pode informar a quantidade tambm 3. Determina o preo do item e adiciona a informao ao total da transao de venda A descrio e preo do item corrente so exibidos
2.
4.
Ao completar a entrada dos itens, o caixa indica este fato ao TPDV O caixa informa o total da venda ao cliente O cliente efetua o pagamento com dinheiro, possivelmente maior que o total da venda
5.
Calcula e apresenta o total da venda
6. 7.
8.
O caixa registra a quantidade de dinheiro recebida
9.
Mostra o valor do troco ao cliente Gera um recibo impresso
10.
O caixa deposita o dinheiro recebido e extrai o troco a devolver O caixa entrega o troco e o recibo impresso ao cliente
11.
Faz log da venda completada
12.
O cliente sai da loja com os itens comprados
Alguns desses substantivos so conceitos (objetos), outros so atributos de conceitos

Falaremos mais sobre as diferenas em outro captulo Uma regra til: Se pensarmos sobre um conceito X como nmero ou texto no mundo real, ele pode ser um atributo; caso contrrio, sempre ser um conceito

Na dvida, crie um conceito separado Exemplo: Destino um atributo de um vo ou um conceito separado?
um conceito separado (pensamos no destino como sendo um aeroporto)
Conceitos candidatos para o domnio do TPDV
Usando as tcnicas acima, temos a seguinte relao de candidatos:

Especificao de produto Item de detalhe de uma venda Caixa Cliente Gerente
TPDV Item Loja Venda Pagamento Catlogo de produtos
Relatrios so objetos?

Um recibo um relatrio Deveria ser um conceito (objeto) A favor de excluir:

Um recibo apenas um relatrio de uma venda Inclu-lo no modelo conceitual no seria til porque toda sua informao derivada de outros objetos Um recibo tem um papel importante nas regras de negcio porque permite que o cliente devolva itens comprados
04/02/2012
A favor de incluir
Page 5 of 6
Na primeira iterao de desenvolvimento, os Use Cases no consideram a devoluo do produto e no incluiremos o objeto Recibo
Em outra iterao, poder ser includo
Modelagem do mundo no real

Em certos domnios de problema, os conceitos so muito abstratos Exemplo: domnio de redes de computadores ou telecomunicaes
Conceitos possveis so: Mensagem, Conexo, Dilogo, Protocolo, etc.
Modelando descries
No se deve incluir como atributos descries de conceitos a instncias desses conceitos por dois motivos

Repetio de informao A descrio some se no houver instncia melhor criar um novo conceito DescrioDeProduto que descreve instncias de Produtos
Exemplo: No est correto incluir a descrio de um produto no conceito Produto
Outro exemplo: O conceito Vo deveria incluir toda a descrio do vo?
No! Se nenhum vo RG321 ocorrer, a descrio do vo RG321 deve continuar em algum lugar: um conceito parte
Termos empregados na UML

UML no emprega a palavra "conceito" As alternativas so tipo e classe

04/02/2012
Page 6 of 6
A diferena entre tipo e classe que um tipo abstrato (sem implementao) enquanto a classe sempre inclui alguma implementao Portanto, o tipo uma especificao e a classe uma implementao (de um tipo) A diferena entre as duas coisas se torna mais importante durante a fase de Projeto
Por enquanto, basta dizer que usaremos "conceito" para falar do domnio do problema e "classe" para falar de entidades de software
anal1-1 programa prxima
04/02/2012
Comportamento Dinmico: Diagramas de Sequncia
Page 1 of 3
Ainda estamos em Anlise
Objetivos

Identificar eventos e operaes do sistema Criar diagramas de sequncia do sistema para Use Cases
Introduo

O modelo conceitual visto no captulo anterior um modelo esttico Agora, vamos considerar um modelo do comportamento dinmico do sistema Um diagrama de sequncia do sistema ilustra eventos partindo de atores e estimulando o sistema Como ainda estamos investigando o que o sistema faz (e no como), tais diagramas fazem parte do modelo de anlise Cuidado! Embora o autor do livro texto (Larman) indique que diagramas de sequncia do sistema so utilizados apenas na anlise, eles podem ser utilizados no projeto tambm Os diagramas de sequncia do sistema so altamente dependentes dos Use Cases, pois a partir deles que criamos os diagramas Trataremos o sistema como "caixa preta", isto , investigando o que ele faz, mas no como
Diagramas de sequncia do sistema

Os Use Cases sugerem como atores interagem com o sistema Os atores geram eventos para o sistema, pedindo que alguma operao
seja feita
Exemplo: quando o caixa entrega o UPC do item sendo comprado ao sistema, o caixa pede que o sistema registre a compra deste item
Queremos entender o sistema melhor examinando as operaes que um ator requisita do sistema Um diagrama de sequncia do sistema mostra, para um cenrio particular de um Use Case, os eventos gerados pelos atores externos, sua ordem, alm de eventos envolvendo outros sistemas Todos os sistemas so tratados como caixas preta
Portanto, os eventos cruzam fronteiras de sistemas

04/02/2012
Page 2 of 3
Diagramas de sequncia do sistema so elaborados para os Use Cases mais importantes e as alternativas mais cruciais dos Use Cases
Cuidado! No gere diagramas de sequncia do sistema para situaes bvias ou de fcil entendimento
Exemplo de um diagrama de sequncia

No diagram abaixo, o tempo flui para baixo Eventos podem incluir parmetros
Operaes do sistema

Para cada evento, h uma operao correspondente que o sistema desempenha Podemos enxergar o sistema como possuindo operaes, necessrias para descrever um comportamento dinmico
No modelo conceitual, isso no era necessrio pois estvamos descrevendo um modelo esttico
Exemplo:
Mostrando o texto dos Use Cases nos diagramas de sequncia

til para mostrar a relao entre as operaes e a descrio dos Use Cases Exemplo:
04/02/2012
Page 3 of 3
Cuidado! S utilize diagramas de sequncia para esclarecer iteraes mais complexas entre os atores e o sistema
O exemplo mostrado aqui simples demais e no merece um diagrama de sequncia
anal1-5 programa anterior prxima
04/02/2012
Modelo Conceitual: Adio de Associaes
Page 1 of 6
Objetivos

Identificar associaes num modelo conceitual Diferenciar associaes de conhecimento e associaes de entendimento de modelo
Introduo
Queremos associar conceitos de forma a:

Satisfazer as necessidades de acesso a informao dos conceitos Deixar o modelo conceitual mais fcil de entender
Associaes
Uma associao um relacionamento estrutural entre conceitos que indica uma conexo interessante e til
Critrio de associaes teis
Associaes "de conhecimento" (need-to-know) representam a conhecimento de um relacionamento que deve ser preservado por algum tempo

Entre quais objetos precisamos ter memria de um relacionamento? Exemplo: Um "Item de detalhe de uma venda" tem uma associao com uma instncia de uma Venda
Caso contrrio, no poderamos calcular o total da venda, emitir o recibo, etc.
Vo implicar em algum tipo de navegao no projeto e na implementao

04/02/2012
Page 2 of 6
Outras associaes que podem ser teis so aquelas que melhoram o entendimento do modelo conceitual
Notao UML para associaes
Associaes so sempre bi-direcionais

No h informao de navegabilidade num modelo conceitual Conceitualmente, a navegabilidade existe nos dois sentidos Escolher o verbo para representar uma direo ou outra arbitrrio

Prefere-se manter a voz ativa no verbo melhor "Registra-a-atual" do que "-registrada-por"
No h implicao sobre a existncia de ponteiros, chaves estrangeiras, etc. A seta no possui informao semntica
A seta de direo de leitura opcional e indica como ler o nome da associao
Pode haver informao de multiplicidade nas extremidades das associaes
Como achar associaes: a lista de associaes comuns
Os exemplos so dos domnios de uma Loja e da reserva de passagem area

Categoria de Associao Gaveta-TPDV Asa-Aeronave Item de detalhe de vanda-Venda Trecho de vo-Rota de vo TPDV-Loja, Item-Prateleira Passageiro-Aeronave Descrio de item-Catlogo Vo-Schedule de vo Exemplos
A uma parte fsica de B
A uma parte lgica de B
A fisicamente contido em B
A logicamente contido em B
04/02/2012
Page 3 of 6
A uma descrio de B
Descrio de item-Item Descrio de vo-Vo Item de detalhe de vanda-Venda Tarefa de manuteno-Log de manuteno
A uma linha de detalhe de uma transao ou relatrio B
A conhecido/logado/registrado/reportado/capturado por ou Venda-TPDV em B Reserva-Lista de passageiros A um membro de B Caixa-Loja Piloto-Viao area Departamento-Loja manuteno-Viao area Caixa-TPDV Piloto-Aeronave Cliente-Caixa Agente de reserva-Passageiro Cliente-Pagamento Passageiro-Ticket Pagamento-Venda Reserva-Cancelamento TPDV-TPDV Cidade-Cidade TPDV-Loja Aeronave-Viao area
A uma subunidade organizacional de B
A usa ou gerencia B
A se comunica com B
A est relacionado com uma transao B
A uma transao relacionada com outra transao B
A vizinho de B
A pertence a B
Algumas categorias de associaes sempre so teis num modelo conceitual

A uma parte fsica ou lgica de B A est fisicamente ou logicamente contido em B A registrado em B
Nvel de detalhamento das associaes

No inclua associaes demais no modelo muito mais importante achar conceitos do que associaes
Nomes de associaes
Use uma frase com verbo que facilite a leitura quando juntada com os conceitos em cada extremidade
Exemplo: Loja Estoca Item
Associaes so normalmente lidas da esquerda para a direita e de cima para baixo
04/02/2012
Page 4 of 6
Associaes mltiplas entre dois tipos
Exemplo segue
Associaes e implementao
Durante a anlise associaes no implicam em fluxos de dados ou informao de navegabilidade A implementao de uma associao ser frequentemente uma referncia entre dois objetos Porm, algumas associaes da anlise no sero implementadas Novas associaes que forem implementadas (na fase de implementao) devem ser adicionadas ao modelo conceitual (foram esquecidas durante a modelagem conceitual)
Associaes no Domnio do TPDV
Usam-se as duas tcnicas mostradas acima para identificar associaes

Associaes de conhecimento (que implicam que um objeto deve conhecer o outro) Usando a lista de associaes comuns
Associaes de conhecimento na loja
As seguintes associaes so do tipo "conhecimento"

Associao Por que implica em conhecimento Para poder conhecer a venda corrente, calcular o total e imprimir um recibo Para poder saber se a venda foi paga, comparar o valor recebido do cliente com o total e imprimir um recibo Para poder obter uma especificao de item, dado um cdigo UPC
TPDV Captura Venda Venda Paga-com Pagamento CatlogoDeProduto Registra EspecificaoDeItem
Usando a lista de associaes comuns

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\anal1\anal2.htm 04/02/2012
Page 5 of 6
Examinemos a aplicabilidade de cada categoria

Categoria de Associao Sistema TPDV no se aplica Item de detalhe de venda-Venda TPDV-Loja Item-Loja Especificao de produto-Catlogo de produtos Catlogo de produto-Loja Especificao de produto-Item Item de detalhe de venda-Venda
A uma parte fsica de B A uma parte lgica de B A fisicamente contido em B
A logicamente contido em B A uma descrio de B A uma linha de detalhe de uma transao ou relatrio B
A conhecido/logado/registrado/reportado/capturado por ou Venda (completada)-Loja ( logada por) em B Venda (atual)-TPDV ( capturada por) A um membro de B A uma subunidade organizacional de B Caixa-Loja no aplicvel Caixa-TPDV Gerente-TPDV Gerente-Caixa (mas provavelmente no aplicvel no sistema) Cliente-Caixa Cliente-Pagamento Caixa-Pagamento Reserva-Cancelamento Pagamento-Venda TPDV-TPDV (mas provavelmente no aplicvel no sistema) TPDV-Loja
A usa ou gerencia B
A se comunica com B
A est relacionado com uma transao B
A uma transao relacionada com outra transao B A vizinho de B A pertence a B
O modelo conceitual para o domnio TPDV
Ver modelo conceitual parcial (sem atributos) abaixo
04/02/2012
Page 6 of 6
Pode-se debater cada associao para verificar a utilidade de ser includa no modelo

Uma associao que implica conhecimento normalmente fica As demais ficam se esclarecerem o modelo
No h modelo nico "correto" Podemos argumentar que algumas associaes do modelo poderiam sumir
Exemplos
Nenhuma das associaes seguintes implica em conhecimento
Venda Entrada-por Caixa
Isso mudaria se precisssemos da identificao do caixa no recibo
TPDV Iniciado-por Gerente Venda Iniciada-por Cliente Loja Estoca Item LinhaDetalheVenda Registra-Venda-de Item
04/02/2012
Modelo Conceitual: Adio de Atributos
Page 1 of 3
Objetivos

Identificar atributos num modelo conceitual Distinguir entre atributos corretos e incorretos
Introduo
Precisamos identificar os atributos que serviro para satisfazer as necessidades de informao dos Use Cases sob considerao na iterao corrente Lembre que os atributos so do domnio do problema
Atributos

Um atributo um valor de dado lgico de um objeto (ou instncia de conceito) Os atributos so identificados primariamente localizando a necessidade de lembrar informao
Exemplo: Uma Venda tem atributos data e hora
Notao UML para atributos
Os tipos podem ser opcionalmente mostrados
Atributos vlidos
Manter os atributos de tipos simples
Atributos so normalmente de tipos bsicos
Boolean, Date, Number, String (ou Text), Time

04/02/2012
Page 2 of 3
Podem ser de outros tipos comuns tais como
Endereo, Cor, Geomtricos (Point, Rectangle, ...), Fone, CPF, UPC (Universal Product Code), SKU (Stock Keeping Unit), CEP
No se deve representar associaes como atributos
Repetio de um exemplo anterior em que um destino de vo no um atributo
Valores puros de dados
Um valor puro quando no possuem identidade
No precisamos distinguir entre instncias de mesmo valor Instncias Instncias Instncias Instncias separadas separadas separadas separadas do do de de Number 5 String "mame" Fone contendo o mesmo nmero de telefone Endereo contendo o mesmo endereo
Exemplos: no precisamos distinguir entre

Por outro lado, duas Pessoas chamadas "Sicrano da Silva" devem ser distinguida (tm identidade diferente), apesar do nome igual Resultado: apenas um valor puro de dado pode ser representado como atributo
No usar chaves estrangeiras como atributos
Na construo de esquemas lgicos de bancos de dados, comum usar chaves estrangeiras como atributos
Isso no deve ser feito num modelo conceitual (OO ou no)
Exemplo
04/02/2012
Page 3 of 3
Uso de tipos no primitivos
Pode-se escolher entre usar tipos no primitivos que representem valores puros como associao ou como atributo, conforme o desejo do analista ou a situao particular
O importante que a comunicao das idias sobre o modelo esteja clara
Exemplo
Modelagem de quantidades e unidades
Cuidado! Certos atributos parecem "nmeros" mas podem ter algo mais associado

Valores financeiros podem ter uma moeda, alm do valor Uma quantidade pode ter uma unidade (velocidade em km/s), alm do valor
Atributos para o sistema TPDV

S estamos considerando os Use Cases da primeira iterao Para achar os atributos, lem-se os requisitos, Use Cases da iterao, outros documentos explicativos Muitos atributos podero no ser descobertos na anlise e sero identificados apenas no projeto ou na implementao Podemos ver o modelo conceitual final com os atributos abaixo
04/02/2012
Comportamento Dinmico: Contratos
Page 1 of 3
Objetivos
Criar contratos para as operaes do sistema
Introduo

Estamos continuando a investigar o comportamento dinmico do sistema Contratos descrevem os efeitos que as operaes tm no sistema Em UML, contratos so especificados usando pr-condies e ps-condies Contratos so estabelecidos depois temos o modelo conceitual, que fizemos os diagramas de sequncia e que identificamos as operaes no sistema Continuamos com uma viso de caixa preta para o sistema (queremos caracterizar o que o sistema faz e no como o faz)
Contratos
O diagrama de sequncia no menciona a funcionalidade das operaes
Isto , o comportamento do sistema
Um contrato um documento que descreve o que uma operao promete cumprir As pr- e ps-condies descrevem as mudanas de estado do sistema Contratos podem ser associados a operaes do sistema como um todo ou a mtodos individuais (na fase de projeto)
Consideraremos apenas contratos de operaes de sistema
Exemplo de um contrato
04/02/2012
Page 2 of 3
Segue um contrato possvel para a operao entrarItem

Nome Responsabilidades entrarItem(upc:nmero, quantidade:integer) Registrar a venda de um item a adicionar seu valor ao total da venda. Exibir a descrio do item e seu preo Sistema Funes do sistema: R1.1, R1.3, R1.9
Tipo Referncias cruzadas Anotaes Excees
Se o UPC no for vlido, indicar erro Faz log da venda completada
Sada
Pr-condies
UPC conhecido pelo sistema
Ps-condies
Se for uma nova venda, uma Venda foi criada (criao de instncia) Se for uma nova venda, a nova Venda foi associada ao TPDV (formao de associao) Uma LinhaDetalheVenda foi criada (criao de instncia) A LinhaDetalheVenda foi associada Venda (formao de associao) LinhaDetalheVenda.quantidade recebeu o valor quantidade (mudana de atributo) A LinhaDetalheVenda foi associada com uma EspecificaoProduto, baseado no casamento de UPC (formao de associao)
Alguns comentrios
O tipo pode ser Sistema, Classe de software ou Interface, dependendo do tipo de contrato que se est elaborando As anotaes podem indicar dicar para a fase de projeto, algoritmos especiais desejados, etc. A sada indica informao que sai do sistema (mensagens, registros, ...), sem incluir a interface com o usurio As pr-condies mencionam as suposies sobre o estado do sistema antes da execuo da operao
Muitas dessas coisas podero ser testadas durante a implementao (programao defensiva)
As ps-condies mencionam as alteraes ao estado do sistema como resultado da execuo da operao (isto, depois que a operao terminou)
As ps-condies podem ser descobertas nas seguintes categorias:

Criao e destruio de instncias Modificao de atributos Associaes formadas e quebradas
No mencione aes que so feitas na operao mas mudanas que ocorreram no estado do sistema
Tire uma foto do sistema antes e depois da operao e descreva a diferena entre as duas fotos Descrevemos o que ocorreu e no como ocorreu
Outros contratos podem ser vistos no livro de Larman
Relao com outros artefatos
04/02/2012
Page 3 of 3
anal1-6 programa anterior
04/02/2012
Construo do Glossrio
Page 1 of 1
Construo do Glossrio
Objetivos
Expressar termos num glossrio
Introduo

Um glossrio um documento simples que descreve termos A definio de termos do domnio do problema importantssimo para manter limpa a comunicao entre desenvolvedores e clientes

Para reduzir o risco de falahas de entendimento Para ajudar a introduzir novos membros na equipe no meio do projeto
O glossrio elaborado em paralelo com outras fases e elaborado ao longo da vida do projeto Pode incluir definies de tipos, business rules, Use Cases, atributos, etc.

Eu particularmente no gosto de repetir informao aqui que esteja em outro lugar Exemplo: descrio de atributos que podero estar em outro documento
Serve como dicionrio particular do projeto
Exemplo de glossrio (incompleto) para o domnio TPDV

Termo Comprar Itens EspecificaoProduto.descrio Item Pagamento LinhaDetalheVenda.quantidade Venda LinhaDetalheVenda Loja Venda.total EspecificaoProduto.UPC
Categoria Use Case atributo tipo tipo atributo tipo tipo tipo atributo atributo
Comentrio Descrio do processo que envolve a compra de itens por um cliente numa loja Uma descrio curta de um item de venda Um item venda numa Loja Um pagamento em dinheiro vivo A quantidade de um tipo de item comprado Uma transao de venda O detalhamento da venda de um item particular numa Venda O lugar onde vendas de itens ocorrem O valor total de uma Venda O Universal Product Code do item
04/02/2012
4. Fase de Projeto 1
Page 1 of 1

Da anlise ao projeto Projeto arquitetural Descrio de use cases reais Diagramas de colaborao Padres para atribuir responsabilidades Projeto de solues com objetos e padres Visibilidade Diagramas de classe para a fase de projeto Esquema de banco de dados e mapeamento OO-Relacional
proj1 programa
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\proj1\index.htm
04/02/2012
Da Anlise ao Projeto
Page 1 of 1
Da Anlise ao Projeto
A anlise se concentra na questo "O qu?"
Entendimento dos requisitos, conceitos e operaes relacionados a um sistema
A prxima fase a de Projeto, onde a questo "Como?" abordada O projeto de um sistema dividido em duas partes

Projeto arquitetural (ou Projeto de Alto Nvel) Projeto detalhado (ou Projeto de Baixo Nvel)
O projeto arquitetural lida com questes "macro" O projeto detalhado lida com objetos individuais e suas interaes

Procura-se resolver o problema de atribuir responsabilidades s classes Tambm trata de resolver as questes de persistncia de objetos Padres de Projeto (Design Patterns) so extremamente teis durante o Projeto detalhado
proj1-1 programa prxima
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\proj1\proj1.htm
04/02/2012
Projeto Arquitetural
Page 1 of 13
Resumo da seo

Projeto de uma arquitetura Decomposio do sistema: parties e camadas Arquiteturas em n camadas Uso de UML para modelar a arquitetura Estruturas de controle Opes de persistncia Reutilizao: Frameworks e componentizao Resumo: Perguntas a fazer ao elaborar um projeto arquitetural
Projeto de uma arquitetura
O que um projeto arquitetural?

Decises estratgicas que tero consequncias profundas As decises so tomadas num alto nvel Modularizao do projeto em subsistemas Escolha de uma estrutura de comunicao e controle entre os subsistemas Escolha da diviso de trabalho entre membros de uma equipe ou entre equipes de desenvolvimento Definio das interfaces entre subsistemas para possibilitar o trabalho paralelo de desenvolvimento Escolha de uma estratgia de persistncia Escolha do paradigma de DBMS a usar Determinao de oportunidades para o reuso de software Atendimento a requisitos especiais de desempenho Atendimento a outros requisitos (custo, mobilidade, uso de padres, etc.) Exposio das interfaces para facilitar a futura integrao de aplicaes (Enterprise Application Integration - EAI) etc.
Exemplos de decises

Observe que sempre deve-se ter um olho na satisfao dos requisitos levantados Veremos vrios aspectos do projeto arquitetural
A discusso direcionada mais a sistemas de informao

04/02/2012
Page 2 of 13
Decomposio do sistema: parties e camadas
Uma estrutura elegante pode frequentemente ser elaborada usando camadas e parties
Uma camada um subsistema que adiciona valor a subsistemas de menor nvel de abstrao Uma partio um subsistema "paralelo" a outros subsistemas
Lembre que subsistemas devem ser coesos (trata de responsabilidades fortemente relacionadas)

Tem forte acoplamento dentro de um subsistema Tem fraco acoplamento entre subsistemas
Para minimizar o acoplamento, camadas frequentemente se comunicam apenas com as camadas "vizinhas" A decomposio pode terminar quando voc atingir subsistemas com temas claros que sejam simples de entender Alguns sistemas muito pequenos no necessitam de camadas e parties
Arquiteturas em n camadas
Para sistemas de informao que incluam uma interface com o usurio e persistncia (isto , quase todos!), usa-se frequentemente uma arquitetura em 3 camadas (3-tier architecture)
As camadas verticais so:
Apresentao: janelas, relatrios, etc.
Tambm chamada de Camada de Interface com o Usurio, Camada de Servios do Usurio

04/02/2012
Page 3 of 13
Lgica da Aplicao: tarefas e regras que governam o processo
Tambm chamada de Camada de Aplicao, Ccamada de Servios de Aplicao Tambm chamada de Camada de Gerncia de Dados, Camada de Servios de Dados, Camada de Armazenamento
Dados: mecanismo de armazenamento persistente
O que vai em cada camada pode mudar ligeiramente
Exemplo: possvel (e pode ser desejvel) ter alguma lgica de aplicao na camada de dados usando Stored Procedures Exemplo: possvel (mas em geral indesejvel) ter alguma lgica de aplicao na camada de apresentao usando linguagens de scripts
Em que mquina cada camada roda pode variar, mas hoje em dia, a distribuio fsica completa comum Por que uma arquitetura em 3 camadas?
Sistemas em camadas surgiram para aproveitar os PCs da empresa e oferecer sistemas com interface grficas amigveis e integradas ao desktop Os primeiros sistemas cliente-servidor eram de duas camadas (juntando as camadas de apresentao e de aplicao) mas sofriam de vrios problemas:

Falta de escalabilidade (conexes a bancos de dados) Enormes problemas de suporte (mudanas lgica de aplicao forava instalaes) Nenhum suporte a Thin Clients (PDA, celulares, smart cards, quiosques, ...) Dificuldade de acessar fontes heterogneas (legado CICS, 3270, ...) Dificuldade de criar software reutilizvel para rodar em clientes Usar o browser como cliente universal, levando ao conceito de Intranet Evitar instalao em computadores de clientes, parceiros, fornecedores, etc. Implementar servios automticos de persistncia, tolerncia a falhas com failover, gerncia de transaes, balanceamento de carga, resource pooling, etc.
Alm do mais, a arquitetura em 3 camadas permite:

Enterprise JavaBeans, COM+
Arquitetura em n camadas
Podemos dividir a camada de aplicao em mais de uma camada
Frequentemente feito separando as aspectos relacionados ao domnio do problema e os aspectos de servios
Podemos tambm dividir a camada de dados em mais camadas (usando um datawarehouse, por exemplo)
Uso de UML para modelar a arquitetura

UML prov o conceito de package para agrupar elementos Este mecanismo pode ser utilizado para evidenciar os subsistemas e suas dependncias Um package em UML:
04/02/2012
Page 4 of 13
A arquitetura em camadas pode ser representada em UML:
A arquitetura detalhada e as dependncias (acoplamento) entre packages podem ser representadas em UML:
Estruturas de controle
O paradigma de controle externo da aplicao deve ser escolhido
O paradigma diz como uma aplicao controlada "de fora" e como interage com seus usurios e outras aplicaes O controle interno dos objetos da aplicao no visvel fora da aplicao
04/02/2012
Page 5 of 13
H vrios paradigmas de controle externo
Controle orientado a procedimento

Tem um nico thread no programa Mtodos executam chamadas para obter dados de entrada e esperam os dados O estado do programa pode ser guardado em variveis locais aos procedimentos (na pilha de execuo) Vantagem: fcil de implementar com linguagens convencionais Desvantagem: qualquer paralelismo inherente aos objetos deve ser mapeado a um fluxo de controle sequencial Frequentemente usado em aplicaes que possuem uma interface no grfica Um dispatcher provido pela linguagem, SGBD, linguagem ou sistema operacional Mtodos da aplicao so amarrados a eventos
Controle orientado a evento
Quando o evento ocorre, o mtodo correspondente chamado
Todos os mtodos retornam o controle para o dispatcher em vez de esperar que os dados de entrada cheguem O estado do programa deve ser guardado em variveis globais j que os mtodos retornam o controle (e no ficam com ele) Vantagem: ajuda a separar a lgica da aplicao da interface com o usurio Frequentemente usado com SGBD munido de linguagem de quarta gerao Muito usado com bancos de dados Quase sempre usado para controlar uma interface grfica O controle fica com vrios objetos autnomos, cada um respondendo a eventos A concorrncia provida pelo sistema operacional
Controle concorrente

Usando paralelismo em hardware ou no
Observe que estamos nos referindo a controle concorrente dentro da aplicao e no entre aplicaes
Este ltimo muito comum (sesses paralelas de acesso a BD, por exemplo)
Infrequentemente usado, embora seu uso tenda a crescer com o CORBA (framework de objetos distribudos) O programa usa um fluxo de controle implcito beaseado em statements declarativos Usado em sistemas especialistas baseados em regras
Controle declarativo
Dois padres de controle frequentemente utilizados na arquitetura so:

Observer Pattern (ou Publish-Subscribe) para acoplar objetos ou subsistemas Model-View-Controller (MVC) para separar os objetos de domnio dos objetos de interface Sero descritos em outro captulo (sobre Design Patterns)
Opes de persistncia
Tratamos aqui apenas dos aspectos arquiteturais da persistncia
Um captulo frente trata mais detalhadamente do mapeamento de projetos OO para esquemas de BD relacionais Escolha da forma bsica de persistncia (na memria, em arquivos, usando um SGBD) Escolha do paradigma de SGBD (se usar um SGBD) Determinao da estratgia de interao entre a aplicao e os dados
Trs grandes pontos devem ser tratados com respeito persistncia de objetos:
04/02/2012
Page 6 of 13
Escolha da forma bsica de persistncia
As alternativas bsicas so:

Dados na memria Dados em arquivos Dados sob controle de um BD
Muitas aplicaes requerem necessariamente os servios de um BD, mas algumas podem funcionar bem com uma alternativa mais simples Os seguintes pontos devem ser avaliados para tomar a deciso sobre a forma de persistncia:
Persistncia de dados

Arquivos e SGBDs so fortes Ficar com os dados na mamria requer um suporte especial de memria e fontes de alimentao para prevenir a perda de informao Um SGBD pode ser muito caro
Custo de aquisio
Se houver um site license j em uso, o custo incremental pode ser pequeno
O hardware para manter dados na memria pode ser caro Arquivos nada custam pois so inherentemente suportados pelo sistema operacional Custos incluem a aquisio, treinamento, desenvolvimento, implantao, operao e manuteno Qualquer uma das 3 alternativas pode ganhar aqui
Custo total de posse (Total Cost of Ownership)
Exemplo: SGBD pode reduzir custos de desenvolvimento mas aumenta custos de operao (incluindo recursos humanos) Exemplo: arquivos no tm custo de aquisio mas tm um alto custo de manuteno
Quantidade de dados

SGBDs podem armazenar gigantescas quantidades de informao Recursos de hardware limitam a quantidade de dados que pode ser armazenada na memria Arquivos so limitados em tamanho pelo sistema operacional
Cuidado com sistemas que limitam arquivos a 32 bits (4 GBytes)
Desempenho

xdados na memria so acessados mais rapidamente SGBDs tm algoritmos e estruturas de dados especiais para lidar com grandes quantidades de dados Arquivos podem ser rpidos se couberem na memria ou se forem eficientemente acessados sequencial ou randomicamente SGBDs oferecem independncia de dados de forma que o desenvolvedor pode se concentrar nos aspectos lgicos dos dados, sem preocupao imediata com detalhes de implementao fsica A granularidade de travamento pode afetar o desempenho Tipicamente, arquivos so travados por completo
Extensibilidade
Acesso concorrente

Travamento de registros de arquivos requer muita programao
A granularidade melhor com dados na memria SGBDs podem ter boa granularidade (record locking) ou menos boa (page locking)
Alm do mais, SGBDs podem escalonar travamentos e resolver conflitos

04/02/2012
Page 7 of 13
automaticamente sem programao adicional
Recuperao de crash

Arquivos: Arquivos de backup so necessrios SGBDs: tm lgica sofisticada para recuperao de crash Memria: requer o uso de shadow memory Apenas SGBDs oferecem o suporte a regras de integridade (definidas pelo programador) Apenas SGBDs oferecem suporte a transaes Apenas (alguns) SGBDs oferecem suporte distribuio de dados e vrios sites SGBDs oferecem linguagens de consulta para facilitar o manuseio de dados Alguns produtos do mercado oferecem linguagens de consulta simples para dados em arquivos Arquivos podem ser protegidos pelo sistema operacional (mas sem sofisticao) SGBDs podem implementar segurana com passwords, views, etc. SGBDs permitem a manipulao da estrutura dos dados (metadados) em tempo de execuo
Dados na memria Arquivos Bom suporte No h Varivel Limitado pelo sostema operacional; A memria limita files em cache Rpido para acesso sequencial, certos acessos randmicos e para arquivos em cache Limitada Locking de arquivos Arquivos de backup No h No h No h Parcial Proteo simples do sistema operacional No h Bom suporte Pode ser caro Varivel Essencialmente sem limite SGBDs
Integridade
Suporte a transaes
Distribuio
Linguagem de consulta

Segurana

Metadados
Um sumrio segue:
Requer hardware especial Custo do hardware especial Varivel Limitado pelo hardware
Persistncia de dados Custo de aquisio Custo total de posse Quantidade de dados
Desempenho Estensibilidade Acesso concorrente Recuperao de crash Integridade Suporte a transaes Distribuio Linguagem de consulta Segurana Metadados
Muito rpido Limitada Locking de objetos Shadow memory No h No h No h No h No h No h
Rpido Excelente Locking de objetos ou de registros; Alguns SGBDs s tm locking de pginas Bom suporte Projetista pode especificar regras Transaes curtas s vezes Poderosa Pode ser simples ou sofisticado Sim
Em suma, algumas aplicaes naturalmente se beneficiam de cada alternativa de persistncia:
Dados na memria

Dados Dados Dados de um
para dispositivos eletrnicos (celulares, PDAs, ...) para smart cards, cartuchos de jogos para aplicaes que no podem tolerar o custo ou falta de confiabilidade disco
Arquivos
04/02/2012
Page 8 of 13
Dados de grande volume, com pouca densidade de informao (archival files, registros histricos detalhados, logs, ...) Dados crus que devem ser sumarizados num BD (exe.: aquisio de dados, telemetria, ...) Quantidades modestas de dados com estrutura simples (quando no tem SGBD ou este seria complexo demais para a empresa manter) Dados acessados sequencialmente Dados que so lidos por inteiro na memria Dados que requerem atualizao com nveis finos de granularidade por mltiplos usurios Dados que devem ser acessados por vrias aplicaes Grandes quantidades de dados que devem ser eficientemente manipulados Dados de longa durao e muito valiosos a uma organizao Dados que devem ser acessados com sofisticado controle de segurana Dados sujeitos a anlise sofisticada para o apoio deciso
SGBDs
Finalmente, observe que comum utilizar mais do que uma nica alternativa para dados diferentes
Escolha do paradigma de SGBD
Se usar um SGBD, ainda deve-se escolher entre SGBDs relacionais, objeto-relacionais e orientados a objeto Os detalhes fogem do escopo desta disciplina Resumindo:
SGBDRs so maduros mas sofrem de um problema srio: impedance mismatch entre objetos e relaes
As grandes desvantagens so:

Navegao lenta (usando joins de tabelas) Protocolos de travamento inflexveis (por serem automticos) Poucos tipos de dados Tudo tem que ser uma tabela
Mostraremos como mapear um projeto OO para um esquema relacional num captulo frente
SGBDOOs no so to maduros mas no sofrem de impedance mismatch e apresentam recursos avanados (evoluo de esquema, controle de verses, long transactions, notificaes de mudanas, ...)
Oferecem navegao rpida mas ainda carecem at de uma teoria completa!
H ainda a alternativa de SGBDs Objeto-Relacionais que mantm o paradigma relacional mas resolvem algumas questes (tais como melhor suporte a tipos de dados)
Determinao da estratgia de interao entre a aplicao e os dados

Quais so as estratgias para conectar sua aplicao a um SGBD? Pr-processador e ps-processador batch

Em alguns casos, melhor que a aplicao no acesse o BD Aplicaes batch existentes podem fazer uso de um BD de forma indireta Pode ser til em algos (raros?) casos em que se usa software legado ou sem cdigo fonte dentro de uma aplicao (como subsistema)
04/02/2012
Page 9 of 13
Arquivos de script
Para certas aplicaes simples, basta executar um ou mais arquivos contendo comandos de uma linguagem de consulta (SQL, OQL, ...) Bom para certas situaes tais como criar esquemas, popular um BD, prorotipagem Neste caso, a aplicao acessa o BD diretamente Parece natural devido ao casamento entre a linguagem hospedeira (digamos Java) e um SGBDOO Cuidado! Ao proceder assim, o acoplamento com o SGBDOO fica muito forte e pode ser difcil mudar de SGBD posteriormente
Comandos embutidos da linguagem de manipulao de dados de um SGBDOO

Use o padro ODMG para melhorar a portabilidade
Comandos SQL estticos embutidos

Cdigo SQl esttico conhecido em tempo de compilao relativamente simples de usar, mas:

Sem muitos cuidados (batching, etc.), pode resultar numa execuo lenta Acopla muito o cdigo da aplicao ao esquema do BD Resulta em cdigo difcil de se ler
Em suma, tenta-se desta forma resolver o impedance mismatch com cdigo esttico Os acessos ao BD so encapsulados em poucos mtodos da aplicao Ajuda a manter a consistncia dos dados Ajuda a manter o escopo de transaes Ajuda a no contaminar a aplicao com um monte de cdigo de acesso ao BD Tcnica muito usada Stored procedures Boa forma de reuso para vrias aplicaes Certos cuidados ao usar Stored Procedures sero tratados num captulo posterior sobre persistncia Cuidado! Stored Procedures no so implementados de forma portvel pelos vrios SGBDs do mercado
Implementar uma API customizada de acesso aos dados

Mtodos armazenados no BD

O padro SQL no obedecido pelos fabricantes
Linguagem de quarta gerao

SGBDRs normalmente vm com uma linguagem 4GL Podem reduzir o esforo de desenvolvimento, mas no so portveis
04/02/2012
Page 10 of 13
Camada Genrica Orientada a Objeto

Uma camada OO escrita para completamente esconder o BD Ela pode ser genrica (para qualquer objeto, qualquer aplicao) com bastante esforo Geralmente sofre com desempenho A camada de acesso ao BD acessa o metamodelo e constroi a consulta dinamicamente A consulta resultante acessa o BD Soluo frequentemente usada com frameworks Cuidado! Essa tcnica requer muito esforo!
Interao baseada em Metamodelo
melhor usar uma soluo pronta, tal como Toplink
Uso de Middleware
Os servios de persistncia podem ser obtidos automaticamente usando Middleware

Enterprise JavaBeans COM+ Gerncia de transaes distribudas Directory/Naming Segurana Tolerncia a falha com Failover Balanceamento de carga Resource pooling Monitoring, logging, ...
Vantagem: muitos servios so obtidos alm da persistncia:

Reutilizao: Frameworks e componentizao
Devido sua importncia, dedicamos um captulo frente sobre o tema de reutilizao
Frameworks
Criao de uma aplicao quase pronta que permite rapidamente criar vrias aplicaes de um mesmo domnio de problema Pedaos de software que permitem a composio visual de aplicaes em tempo
04/02/2012
Componentes
Page 11 of 13
de design
Resumo: Perguntas a fazer ao elaborar um projeto arquitetural

Sobre entidades externas ao sistema

Quais sistemas externos devem ser acessados? Como sero acessados? H integrao com o legado a ser feita? Como?
Determinao de oportunidades para o reuso de software

H interesse/convenincia/tempo em aproveitar tais oportunidades? Como isso pode ser feito?

Com componentes? Construindo um framework?
Sobre a organizao geral do sistema

O sistema centralizado ou distribudo? Como modularizar em subsistemas? Como minimizar acoplamento entre os pedaos? Lembrando que um sistema pode ser visto como sendo composto de trs grandes camadas lgicas ... Tais camadas sero lgicas ou tero existncia fsica separada? Onde colocar o business logic (como dividir entre as camadas)? Qual o nvel de acoplamento, frequncia de interaes, volumes de dados trocados entre as camadas? Qual seria a estrutura de comunicao e controle entre os subsistemas (como ligar as camadas)?

Usando o Observer Pattern? Usando o Model-View-Controller Pattern? Qual o formato das mensagens (xml, ...)? Como feita a comunicao remota? CORBA? RPC? RMI? Message Queue?
Quais so as interfaces importantes entre os pedaos?

A programao ser feita com qual paradigma? OO? Que linguagens e ferramentas sero usadas?
Sobre a camada de interface
O sistema ser acessado usando que tipos de clientes?

Browser? Uso de applet? Uso de script cliente? Com que ferramentas? Com que componentes visuais?
Como fazer a interface grfica?

Sero desenvolvidos? comprados?
Javascript ou outra linguagem de script do lado cliente ser usada? Activex? Javabeans? Servlets? JSP? ASP?
04/02/2012
Que modelo de componentes visuais ser usado?

Se a interface usar um browser, como ser feita a gerao de HTML dinmico?


Page 12 of 13
Que ferramentas usar para a formatao de relatrios? H packages a desenvolver que poderiam ser comuns a vrias partes da interface?
Sobre a camada de lgica da aplicao
Escolha de middleware: qual modelo de componentes de servidor ser usado?

COM+? EJB?
Quais so os componentes principais a fazer? Sero componentes persistentes? Sero componentes com ou sem estado? De que forma atender aos requisitos para uso multiusurio?
Solues para resolver a concorrncia Dados persistentes? Servio de mail? Servio de nomes?
Que APIs sero usadas para acesso a:

H packages a desenvolver que poderiam ser comuns a vrias partes da lgica da aplicao? Qual a organizao interna dos modulos executveis?
Determinar sub-camadas e parties
Quais so as interfaces importantes entre os pedaos? Onde verificar os business rules?

No SGBD? No middleware?
Como implementar aspectos de segurana? Como implementar os requisitos de auditoria?
Sobre a camada de dados persistentes

Quais so as fontes de dados? externas? internas? existentes? novas? Como acessa-las? Que estratgia de persistncia ser usada:

Na memria (com recursos especiais como pilha)? Em arquivos? Usando um SGBD? Relacional? O-R? O-O?
Qual paradigma de SGBD usar?

Onde usar stored procedures para implementar os business rules ou garantir a integridade dos dados? Qual ser a estratgia de interao entre a aplicao e os dados? De que forma atender aos requisitos para uso multiusurio (concorrncia)? Como resolver o impedance mismatch entre a camada de lgica de aplicao e o esquema de persistncia? Para grandes escalas, como oferecer connection pooling? Como implementar a segurana no SGBD? Como ser feita a populao dos bancos de dados?
Sobre requisitos de desempenho
H necessidade de bolar formas especiais de atender aos requisitos de desempenho?

Como prover escala? Como prover failover?
04/02/2012
Page 13 of 13
O que deve ser produzido?
Quais so os mdulos executveis a produzir?
Executveis, DLLs, ...
Quais so os arquivos importantes (de configurao, etc.) e seu formato (xml, ...)? Como ser resolvida a instalao do produto? O que ser comprado, feito, modificado? O que ser gerado automaticamente com uma ferramenta especial?
Exemplo: gerao de esquema atravs de ferramentas CASE, ...
Sobre a integrao futura
Que interfaces devem ser expostas para facilitar a futura integrao de aplicaes (Enterprise Application Integration - EAI)?
Pode-se usar uma camada de API para expor a camada de business logic, colocar uma camada de script acima disso e ainda camada(s) de interface para ativar a business logic atravs de scripts. Vantagens:

Fcil criao de macros e outras formas de automao Fcil criao de testes de regresso Clara separao de business logic da interface para o usurio
Como ser feita a exposio?

Com XML? Atravs de uma API?
Perguntas adicionais

Que ferramentas de desenvovimento sero geradas? Como ser o atendimento a outros requisitos (custo, mobilidade, uso de padres, etc.) H consideraes especiais de administrao a levar em conta?

Como ser a troca de verses? Como ser a distribuio do software?

Via Internet/Intranet? Via mdia?
Pergunta final
Voc j verificou que a arquitetura bolada pode atender a todos os requisitos levantados?
proj1-2 programa anterior prxima
04/02/2012
Descrio de Use Cases Reais
Page 1 of 2
Use Cases reais so uma redefinio de Use cases essenciais mostrando o projeto do Use case em termos de tecnologias especficas de entrada e sada Exemplo: se uma GUI usada, as telas com todos seus campos podem ser usadas para detalhar o Use Case, mostrando as interaes de baixo nvel Use Cases reais normalmente no so criados, s sendo necessrios quando o cliente exige uma alto grau de detalhamento da interface com o usurio
Normalmente, basta ter um esboo das telas com os detalhes sendo aprontados durante a implementao
Comprar item - verso 1 (pagamento vista) Cliente (iniciador), Caixa Capturar uma venda e seu pagamento vista Um Cliente chega ao caixa de sada com itens sendo comprados. O Caixa registra os itens comprados e recebe pagamento em espcie. No final, o Cliente sai com os itens. Primrio e real Funes: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1
Exemplo
Use Case: Atores: Objetivo: Resumo: Tipo: Referncias cruzadas:
Sequncia Tpica de Eventos Ao do ator 1. O Use Case inicia quando um Cliente chega ao TPDV com itens sendo comprados 3. Adiciona o preo do item ao valor total da compra. Resposta do Sistema
2.
Para cada item, o Cliente digita o Cdigo Universal de Produto (UPC) no campo A acima. Se houver mais de um item, a
04/02/2012

quantidade digitada no campo E. H pressionado aps a entrada de cada item 4. Ao completar a entrada dos itens, o Cliente indica o fato pressionando I ... 5.
Page 2 of 2
A descrio e preo do item corrente so exibidos nos campos B e F Calcula e exibe o total da venda em C
6.
04/02/2012
Diagramas de Colaborao
Page 1 of 7
Introduo
Dois tipos de diagramas podem ser usados para mostrar as interaes (mensagens) entre objetos

Diagramas de Sequncia Diagramas de Colaborao
Os dois tipos de diagramas so chamados diagramas de interao O objetivo de mostrar como as ps-condies dos contratos sero realizadas O diagrama de sequncia mais simples de usar quando se deseja mostrar apenas as sequncias de interaes O diagrama de colaborao mais adequado quando se deseja expressar mais detalhes da colaborao entre objetos Exemplo de um diagrama de sequncia:
Exemplo de um diagrama de colaborao
04/02/2012
Page 2 of 7
No exemplo acima:

A mensagem faaPagamento enviada a uma instncia de uma TPDV O TPDV envia a mensagem faaPagamento a uma instncia de Venda O objeto da classe Venda cria uma instncia de um Pagamento
Sobre a importncia de diagramas de interao
Uma das coisas mais difceis de fazer no projeto de um sistema a atribuio de responsabilidades a objetos e a consequente colaborao entre objetos Os diagramas de interao ajudam muito a construir o sistema e uma boa parcela do tempo deve ser dedicado sua construo principalmente aqui que bons princpios de projeto sero usados Esta seo discute apenas a notao empregada em diagramas de colaborao Sees subsequentes trataro da distribuio de responsabilidades entre objetos e apresentar padres de projeto
Como criar diagramas de colaborao

1. Criar um diagrama separado para cada operao do sistema sendo desenvolvida na iterao corrente. Para cada mensagem de operao do sistema, um diagrama consttudo com essa mensagem inicial 2. Se o diagrama ficar complexo (no cabe numa nica pgina), quebre-o em diagramas menores 3. Usando o contrato das operaes (principalmente as ps-condies) e os Use Cases como ponto de partida, projete um sistema de objetos interagindo entre si para realizar as tarefas. Aplique padres de projeto para desenvolver um bom projeto
Relao entre diagramas de colaborao e outros artefatos
04/02/2012
Page 3 of 7
O Use Cases sugerem os eventos do sistema, os quais so mostrados explicitamente nos diagramas de sequncia do sistema Uma primeira aproximao do efeito das operaes do sistema descrita nos contratos As operaes do sistema so mensagens que iniciam um diagrama de interao, o qual ilustra como os objetos realizam a tarefa
Notao bsica para diagramas de colaborao

Classe e instncias
Links
Um link uma conexo entre dois objetos
uma instncia de uma associao
Indica alguma forma de navegabilidade e visibilidade
Mensagens
Observe o nmero de sequncia das mensagens
Parmetros
O tipo do parmetro opcional

04/02/2012
Page 4 of 7
Valor de retorno
Sintaxe de mensagem
Pode-se usar a sintaxe UML (como acima) ou de outra linguagem (Java, por exemplo)
Mensagens a "this"
Iterao
A iterao mostrada com um nmero de sequncia e um *
A mensagem enviada repetidamente
Valores de recorrncia podem ser includos
Mais de uma mensagem pode ser enviada na iterao
04/02/2012
Page 5 of 7
Criao de instncias

A mensagem de criao independente de linguagem "create" O esteretipo new pode ser usado
Sequenciamento de mensagens
A primeira mensagem no numerada
Tem vrias alternativas para numerar as demais mensagens, incluindo um esuqema hierrquico
04/02/2012
Page 6 of 7
Mensagens condicionais
A mensagem s enviada se o teste resultar em TRUE
Caminhos condicionais mutuamente exclusivos
Colees
Um conjunto de instncias (multiobjeto)
Mensagens para colees
Na UML 1.1, uma mensagem enviada para uma coleo vai para o objeto-coleo e no para todos os objetos da coleo
Na UML 1.0, a mensagem ia para todos os objetos

04/02/2012
Page 7 of 7
Outros exemplos de mensagens para objetos e colees
Mensagens para a classe (mtodos estticos)
Classe no est sublinhada
04/02/2012
Padres Para Atribuir Responsabilidades
Page 1 of 13
Introduo
Um sistema OO composto de objetos que enviam mensagens uns para os outros
Uma mensagem um mtodo executado no contexto de um objeto Uma m distribuio leva a sistemas e componentes frgeis e difceis de entender, manter, reusar e estender Padres GRASP (General Responsibility Assignment Software Patterns) So padres de Larman
Escolher como distribuir as responsabilidades entre objetos (ou classes) crucial para um bom projeto
Mostraremos alguns padres de distribuio de responsabilidades

Ao mostrar padres, apresentaremos princpios de um bom projeto OO Veremos mais padres de projeto em outros captulos Os padres so utilizados enquanto se cria diagramas de interao
Responsabilidades

Responsabilidades so obrigaes de um tipo ou de uma classe Obrigaes de fazer algo

Fazer algo a si mesmo Iniciar aes em outros objetos Controlar ou coordenar atividades em outros objetos Conhecer dados encapsulados Conhecer objetos relacionados Conhecer coisas que ele pode calcular Uma Venda tem a responsabilidade de criar linha de detalhe (fazer algo) Uma Venda tem a responsabilidade de saber sua data (conhecer algo) Uma responsabilidade pode envolver um nico mtodo (ou poucos)
Obrigaes de conhecer algo

Exemplos

Granularidade
Exemplo: Criar uma linha de detalhe Exemplo: Responsabilidade de fornecer acesso a um BD Mas mtodos so usados para implementar responsabilidades
Uma reponsabilidade pode envolver dezenas de classes e mtodos
Uma responsabilidade no igual a um mtodo
Diagramas de interao evidenciam responsabilidades
O diagrama indica que objetos da classe Venda tm responsabilidade de criar linhas de detalhe de venda Eles devem colaborar com objetos da classe LinhaDetalheVenda
04/02/2012
Page 2 of 13
Padres
Uma definio informal:
"Cada padro descreve um problema que ocorre frequentemente e ento descreve o cerne da soluo ao problema de forma a poder reusar a soluo milhes de vezes em situaes diferentes" Reuso de idias, no cdigo Consistem de micro-arquiteturas de classes, objetos, suas responsabilidades e suas colaboraes
Observe que o que reutilizado so as classes e suas colaboraes

Contm o somatrio da experincia dos melhores projetistas O-O! Esto revolucionando o projeto de software desde 1995 quando o famoso livro da "Gang of Four" (GoF) apareceu com o primeiro catlogo de 23 padres

Ver bibliografia Tem muito mais padres aparecendo sempre OOPSLA uma grande fonte de padres
Ficar mais claro com alguns exemplos Design Patterns iniciaram a febre de padres

Analysis Patterns Testing Patterns Business Patterns Pedagogical Patterns e mais ...
Os padres GRASP so de Larman e so do tipo Design Patterns Veremos padres GRASP e GoF (em outro captulo)
Elementos essenciais de um Design Pattern

Um Nome

Descreve o problema de projeto, suas solues e consequncias em poucas palavras Permite projetar num nvel mais alto de abstrao Permite falar com outros sobre solues e documentar cdigo, j que os nomes de padres esto ficando padronizados

"Todo mundo" conhece os 23 padres da GoF equivalente a padronizar "lista encadeada", "pilha", etc. no mundo das estruturas de dados Cuidado! Nem todo mundo conhece os padres de Larman
O Problema

Descreve quando aplicar o padro Descreve o problema e o contexto Pode descrever problemas especficos de projeto
Exemplo: como representar algoritmos como objetos?
Pode descrever estruturas de objetos ou de classes que so sintomas de um projeto inflexvel s vezes, o padro lista condies que devem se aplicar para usar o padro
A Soluo

Descreve os elementos constituintes do projeto, seus relacionamentos, responsabilidades e colaboraes A soluo no descreve um projeto ou implementao concretos porque um padro um gabarito de soluo para vrias situaes
As Consequncias

Os resultados e trade-offs da aplicao do padro Diz respeito a trade-offs de espao, tempo, flexibilidade, extensibilidade, portabilidade
Os padres GRASP deste captulo

Expert Creator Low Coupling High Coesion Controller
Expert
Problema
Qual o princpio mais fundamental para atribuir responsabilidades?
Soluo
Atribuir uma responsabilidade ao expert de informao - a classe que possui a informao necessria para preencher a responsabilidade
Exemplo

No estudo de caso, alguma classe precisa saber o total de uma venda Podemos dizer isso sobre a forma de uma responsabilidade:
04/02/2012
Page 3 of 13
Quem deveria ser reponsvel pelo conhecimento do total de uma venda?
Pelo padro Expert, escolhemos a classe que possui a informao necessria para determinar o total Considere uma parte do modelo conceitual:
Qual a informao necessria?

Precisamos conhecer (ter acesso a) todos os LinhaDetalheVenda Qual information expert? a classe Venda
Podemos agora fazer parte do diagrama de colaborao e do diagrama de classes
Ainda no terminamos. Qual informao necessria para determinar o subtotal para um item (uma linha de detalhe)?

Precisamos de LinhaDeVenda.quantidade e de EspecificaoDeProduto.preo Quem o information expert? a classe LinhaDeVenda
Chegamos aos seguintes diagramas:
Qual o information expert para saber o preo de um produto?
EspecificaoDeProduto
Chegamos aos seguintes diagramas:
Discusso

o padro mais usado de todos para atribuir responsabilidades A informao necessria frequentemente est espalhada em vrios objetos

Portanto, tem muitos experts parciais Exemplo: determinar o total de uma venda requer a colaborao de 3 objetos, em 3 classes diferentes
Mensagens so usadas para estabelecer as colaboraes O resultado final diferente do mundo real

No mundo real, uma venda no calcula seu prprio total Isso seria feito por uma pessoa (se no houvesse software) Mas no mundo de software, no queremos atribuir essa responsabilidade ao Caixa ou ao TPDV!
04/02/2012
Page 4 of 13
No mundo de software, coisas inertas (ou at conceitos como uma venda) podem ter responsabilidades: Tudo est vivo!
Consequncias
A encapsulao mantida, j que objetos usam sua prpria informao para cumprir suas responsabilidades
Leva a fraco acoplamento entre objetos e sistemas mais robustos e fceis de manter
Leva a alta coeso, j que os objetos fazem tudo que relacionado sua prpria informao
Tambm conhecido como

"Colocar as responsabilidades com os dados" "Quem sabe, faz" "Animao" "Eu mesmo fao" "Colocar os servios junto aos atributos que eles manipulam"
Creator
Problema
Quem deve criar novas instncias de uma classe?
Soluo
Atribuir classe B a responsabilidade de criar instncia da classe A se uma das seguintes condies se aplicar:

B B B B B
agrega objetos da classe A contm objetos da classe A registra instncias da classe A usa muito objetos da classe A possui os dados usados para inicializar A
B um criador (creator) de objetos da classe A Se mais de uma opo se aplica, escolha o B que agregue ou contenha objetos da classe A
Exemplo

No estudo de caso, quem deveria criar uma instncia de LinhaDetalheVenda? Pelo padro Creator, precisamos achar algum que agrega, contm, ... instncias de LinhaDetalheVenda Considere o modelo conceitual parcial abaixo:
Venda agrega instncias de LinhaDetalheVenda e portanto um bom candidato para criar as instncias Chegamos aos seguintes diagramas:
Discusso

Escolhemos um criador que deve estar conectado ao objeto criado, de qualquer forma, depois da criao Isso leva a fraco acoplamento Exemplo de criador que possui os valores de inicializao

Uma instncia de Pagamento deve ser criada A instncia deve receber o total da venda Quem tem essa informao? Venda Venda um bom candidato para criar objetos da classe Pagamento
Consequncias
Fraco acoplamento, j que o objeto criado deve normalmente ser visvel ao criador, depois da criao
Low Coupling
Problema
Como minimizar dependncias e maximizar o reuso?
04/02/2012
Page 5 of 13
O acoplamento uma medida de quo fortemente uma classe est conectada, possui conhecimento ou depende de outra classe Com fraco acoplamento, uma classe no dependente de muitas outras classes Com uma classe possuindo forte acoplamento, temos os seguintes problemas:

Mudanas a uma classe relacionada fora mudanas locais classe A classe mais difcil de entender isoladamente A classe mais difcil de ser reusada, j que depende da presena de outras classes
Soluo
Atribuir responsabilidades de forma a minimizar o acoplamento
Exemplo
Considere o seguinte diagrama parcial de classes no estudo de caso
Suponha que temos que criar um Pagamento e associ-lo a uma Venda Que classe deveria ter essa responsabilidade? Alternativa 1: No mundo real, um TPDV "registra" um pagamento e o padro Creator sugere que TPDV poderia criar Pagamento

TPDV deve ento passar o pagamento para a Venda Veja o resultado abaixo
Alternativa 2: Criar o Pagamento com Venda e associ-lo Venda
Veja o resultado abaixo
Supondo que a Venda deva ter conhecimento do pagamento (depois da criao) de qualquer jeito, a alternativa 2 tem menos acoplamento (TPDV no est acoplado a Pagamento)

Dois padres (Creator e Low Coupling) sugeriram diferentes solues Minimizar acoplamento ganha
Discusso

Minimizar acoplamento um dos princpios de ouro do projeto OO Acoplamento de manifesta de vrias formas:

X tem um atributo que referencia uma instncia de Y X tem um mtodo que referencia uma instncia de Y
Pode ser parmetro, varivel local, objeto retornado pelo mtodo
X uma subclasse direta ou indireta de Y X implementa a interface Y Uma seo futura esmiua o assunto Exemplo: todo o comportamento numa classe e outras classes usadas como depsitos passivos de informao Acoplamento Acoplamento Acoplamento Acoplamento Situaes

A herana um tipo de acoplamento particularmente forte
No se deve minimizar acoplamento criando alguns poucos objetos monstruosos (God classes)
Tipos de acoplamentos (do menos ruim at o pior)

de de de de
dados controle dados globais dados internos
Acoplamento de dados
Sada de um objeto entrada de outro Uso de parmetros para passar itens entre mtodos Objeto a passa objeto x para objeto b Objeto x e b esto acoplados
Ocorrncia comum:

Uma mudana na interface de x pode implicar em mudanas a b
04/02/2012
Page 6 of 13
Exemplo:
class Servidor { public void mensagem(MeuTipo x) { // cdigo aqui x.faaAlgo(Object dados); // dados e x esto acoplados // (se interface de dados mudar x ter que mudar) // mais cdigo } }
Exemplo pior:

Objeto a passa objeto x para objeto b x um objeto composto ou agregado (contm outro(s) objeto(s)) Objeto b deve extrair objeto y de dentro de x H acoplamento entre b, x, representao interna de x, y Exemplo: ordenao de registros de alunos por matrcula e nome
class Aluno { String nome; long matrcula; public String getNome() { return nome; } public long getMatrcula() { return matrcula; } // etc. } ListaOrdenada listaDeAlunos = new ListaOrdenada(); Aluno novoAluno = new Aluno(...); //etc. listaDeAlunos.add(novoAluno);
Agora, vamos ver os problemas
class ListaOrdenada { Object[] elementosOrdenados = new Object[tamanhoAdequado]; public void add(Aluno x) { // cdigo no mostrado long matrcula1 = x.getMatrcula(); long matrcula2 = elementosOrdenados[k].getMatrcula(); if(matrcula1 < matrcula2) { // faa algo } else { // faa outra coisa } }
O problema da soluo anterior que h forte acoplamento
ListaOrdenada sabe muita coisa de Aluno

O fato de que a comparao de alunos feito com a matrcula O fato de que a matrcula obtida com getMatrcula() O fato de que matrculas so long (representao de dados) Como comparar matrculas (com <)
O que ocorre se mudarmos qualquer uma dessas coisas?
Soluo 2: mande uma mensagem para o prprio objeto se comparar com outro
class ListaOrdenada { Object[] elementosOrdenados = new Object[tamanhoAdequado]; public void add(Aluno x) { // cdigo no mostrado if(x.lessThan(elementosOrdenados[K])) { // faa algo } else { // faa outra coisa } }
Reduzimos o acoplamento escondendo informao atrs de um mtodo Problema: ListaOrdenada s funciona com Aluno Soluo 3: use interfaces para desacoplar mais ainda
Interface Comparable { public boolean lessThan(Object outro);
04/02/2012

public boolean greaterThan(Object outro); public boolean equal(Object outro); } class Aluno implements Comparable { public boolean lessThan(Object outro) { // compare registro de aluno com outro } } class ListaOrdenada { Object[] elementosOrdenados = new Object[tamanhoAdequado]; public void add(Comparable x) { // cdigo no mostrado if(x.lessThan(elementosOrdenados[K])) { // faa algo } else { // faa outra coisa } }
Page 7 of 13
Em C++, teria outras solues

Apontador de funo Apontador de funo com tipos genricos (templates)
Acoplamento de controle
Passar flags de controle entre objetos de forma que um objeto controle as etapas de processamento de outro objeto Ocorrncia comum:

Objeto a manda uma mensagem para objeto b b usa um parmetro da mensagem para decidir o que fazer
class Lampada { public static final ON = 0; public void setLampada(int valor) { if(valor == ON) { // liga lampada } else if(valor == 1) { // desliga lampada } else if(valor == 2) { // pisca } } } Lampada lampapa = new Lampada(); lampada.setLampada(Lampada.ON); lampada.setLampada(2);
Soluo: decompor a operao em mltiplas operaes primitivas
class Lampada { public void on() { // liga lampada } public void off() { // desliga lampada } public void pisca() { // pisca } } Lampada lampada = new Lampada(); lampada.on(); lampada.pisca();
Ocorrncia comum:

Objeto a manda mensagem para objeto b b retorna informao de controle para a Exemplo: retorno de cdigo de erro
class Teste { public int printFile(File toPrint) { if(toPrint est corrompido ) { return CORRUPTFLAG; } // etc. etc. } } Teste umTeste = new Teste(); int resultado = umTese.printFile(miniTeste); if(resultado == CORRUPTFLAG) { // oh! oh! } else if(resultado == -243) { // etc. etc.
Soluo: use excees
class Teste { public int printFile(File toPrint) throws PrintExeception { if(toPrint est corrompido ) {
04/02/2012

throw new PrintExeception(); } // etc. etc. } } try { Teste umTeste = new Teste(); umTeste.printFile(miniTeste); } catch(PrintException printError) { // faa algo }
Page 8 of 13
Acoplamento de dados globais

Dois ou mais objetos compartilham estruturas de dados globais um acoplamento muito ruim pois est escondido
Uma chamada de mtodo pode mudar um valor global e o cdigo no deixa isso aparente
Um tipo de acoplamento muito ruim Um objeto altera os dados locais de um outro objeto Ocorrncia comum:

Acoplamento de dados internos

Friends em C++ Dados protected ou pblicos de java
Use com cuidado!
Consequncias

Uma classefracamente acoplada no afetada (ou pouco afetada) por mudanas em outras classes Simples de entender isoladamente Reuso mais fcil
High Coesion
Problema

Como gerenciar a complexidade? A coeso mede quo relacionados ou focados esto as responsabilidades da classe
Tambm chamado coeso funcional (ver frente) Difcil de entender Difcil de reusar Difcil de manter "Delicada": constantemente sendo afetada por outras mudanas
Uma classe com baixa coeso faz muitas coisas no relacionadas e leva aos seguintes problemas:

Uma classe com baixa coeso assumiu responsabilidades que pertencem a outras classes e deveriam ser delagadas
Soluo
Atribuir responsabilidades que mantenham alta coeso
Exemplo

Mesmo exemplo usado para Low Coupling Na primeira alternativa, TPDV assumiu uma responsabilidade de efetuar um pagamento (mtodo faaPagamento())
At agora, no h problema Mas suponha que o mesmo ocorra com vrias outras operaes de sistema

TPDV vai acumular um monte de mtodos no muito focados Resultado: baixa coeso Mantm maior coeso em TPDV
A segunda alternativa delega faaPagamento() para a classe Venda
Discusso
Alta coeso outro princpio de ouro que deve ser sempre mantido em mente durante o projeto
04/02/2012
Page 9 of 13
Tipos de coeso entre mdulos

Coincidental (pior) Lgico Temporal Procedural De comunicao Sequencial Funcional (melhor) H nenhuma (ou pouca) relao construtiva entre os elementos de um mdulo No linguajar OO:

Coeso coincidental

Um objeto no representa nenhum conceito OO Uma coleo de cdigo comumente usado e herdado atravs de herana (provavelmente mltipla)
class Angu public // } public // } public // } } class Xpto ... }
{ static int acharPadro(String texto, String padro) { ... static int mdia(Vector nmeros) { ... static outputStream abreArquivo(string nomeArquivo) { ...
extends Angu { // quer aproveitar cdigo de Angu
Coeso lgica
Mdulo faz um conjunto de funes relacionadas, uma das quais escolhida atravs de um parmetro ao chamar o mdulo Semelhante a acoplamento de controle Cura: quebrar em mtodos diferentes
public void faa(int flag) { switch(flag) { case ON: // coisas para tratar break; case OFF: // coisas para tratar break; case FECHAR: // coisas para tratar break; case COR: // coisas para tratar break; } }
de ON
de OFF
de FECHAR
de COR
Coeso temporal

Elementos esto agrupados no mesmo mdulo porque so processados no mesmo intervalo de tempo Exemplos comuns:

Mtodo de inicializao que prov valores defaults para um monte de coisas diferentes Mtodo de finalizao que limpa as coisas antes de terminar
procedure inicializaDados() { font = "times"; windowSize = "200,400"; xpto.nome = "desligado"; xpto.tamanho = 12; xpto.localizao = "/usr/local/lib/java"; }
Cura: depender de construtores e destrutores
04/02/2012
Page 10 of 13
class Xpto { public Xpto() { this.nome = "desligado"; this.tamanho = 12; this.localizao = "/usr/local/lib/java"; } }
Outro exemplo: arquivo de configurao tpico
[Macintosh] EquationWindow=146,171,406,661 SpacingWindow=0,0,0,0 [Spacing] LineSpacing=150% MatrixRowSpacing=150% MatrixColSpacing=100% SuperscriptHeight=45% SubscriptDepth=25% LimHeight=25% LimDepth=100% LimLineSpacing=100% NumerHeight=35% DenomDepth=100% FractBarOver=1pt FractBarThick=0.5pt SubFractBarThick=0.25pt FenceOver=1pt SpacingFactor=100% MinGap=8% RadicalGap=2pt EmbellGap=1.5pt PrimeHeight=45% [General] Zoom=200 CustomZoom=150 ShowAll=0 Version=2.01 OptimalPrinter=1 MinRect=0 ForceOpen=0 ToolbarDocked=1 ToolbarShown=1 ToolbarDockPos=1 [Fonts] Text=Times Function=Times Variable=Times,I LCGreek=Symbol,I UCGreek=Symbol Symbol=Symbol Vector=Times,B Number=Times [Sizes] Full=12pt Script=7pt ScriptScript=5pt Symbol=18pt SubSymbol=12pt
04/02/2012
Page 11 of 13
Coeso procedural

Associa elementos de acordo com seus relacionamentos procedurais ou algortmicos Um mdulo procedural depende muito da aplicao sendo tratada

Junto com a aplicao, o mdulo parece razovel Sem este contexto, o mdulo parece estranho e muito difcil de entender
"O que est acontecendo aqui!!!????!!"
No pode entender o mdulo sem entender o programa e as condies que existem quando o mdulo chamado Cura: reprojete o sistema Todas as operaes de um mdulo operam no mesmo conjunto de dados e/ou produzem o mesmo tipo de dado de sada Cura: isole cada elemento num mdulo separado "No deveria" ocorrer em sistemas OO usando polimorfismo (classes diferentes para fazer tratamentos diferentes nos dados) A sada de um elemento de um mdulo serve de entrada para o prximo elemento Cura: decompor em mdulos menores Um mdulo tem coeso funcional se as operaes do mdulo puderem ser descritas numa nica frase de forma coerente Num sistema OO:

Coeso de comunicao
Coeso sequencial

Coeso funcional (a melhor)
Cada operao na interface pblica do objeto deve ser funcionalmente coesa Cada objeto deve representar um nico conceito coeso
Exemplo: um objeto que esconde algum conceito ou estrutura de dados ou recurso e onde todos os mtodos so relacionados por um conceito ou estrutura de dados ou recurso
Meyer chama isso de "information-strength module"
Consequncias

Melhor claridade e facilidade de compreenso do projeto Simplificao da manuteno Frequentemente vai mo na mo com acoplamento fraco Com granularidade baixa e funcionalidade bem focada, aumenta o reuso
Controller
Problema

Quem deveria receber a responsabilidade de tratar eventos do sistema? Um evento do sistema um evento de alto nvel gerado por um ator externo Esto associados a operaes do sistema que j vimos nos Diagramas de Sequncia do Sistema Exemplo do estudo de caso: Caixa pressiona "Fim de venda"
Soluo
Use um controlador

Um controlador um objeto que no de interface GUI responsvel pelo tratamento de eventos do sistema Um controlador define mtodos para as operaes do sistema
Atribuir a responsabilidade pelo tratamento de eventos do sistema a uma classe de acordo com uma das alternativas abaixo:

Representa o "sistema" como um todo (facade controller) Representa o negcio ou organizao como um todo (facade controller) Representa algo no mundo real que ativo (por exemplo, o papel de uma pessoa) que poderia estar envolvido na tarefa (role controller) Representa um handler artificial de todos os eventos do sistema para um Use Case particular, normalmente chamado "<NomeDoUseCase>Handler" (use case controller)
Exemplo
No estudo de caso, h vrias operaes de sistema:
Quem deveria ser o controlador para os eventos do sistema?
04/02/2012
Page 12 of 13
Pelo padro Controller, temos as seguintes alternativas:

Representa Representa Representa Representa
o "sistema": TPDV o negcio ou organizao: Loja algo no mundo real ...: Caixa um handler artificial ...: CompraItemHandler
A escolha particular depende de fatores discutidos na seo Discusso
Por exemplo, se fosse TPDV, teramos:
Discusso
De forma geral, o mesmo controlador deve ser usado para todas as operaes de um mesmo Use Case de forma a manter a informao de estado do Use Case
A informao de estado pode ser til para detectar sequncias erradas de eventos de sistema
Exemplo: faaPagamento() antes de fimDeVenda()
No coloque toda a inteligncia no controlador
Delegue para outros objetos,para manter coeso Quando est surgindo um "God class" Usado em sistemas mais complexos Tais classes podem receber o evento e deleg-lo ao controlador No se deve colocar business logic num objeto de interface com o usurio Um design correto seria:
Use um Handler artificial quando as outras alternativas exibem acoplamento alto ou coeso baixa

Observe que classes "Window", "Applet", "Application", "View", "Document" no devem ser controladores

Um design incorreto seria:
04/02/2012
Page 13 of 13
O Role Controller pode levar a um mau projeto
O fato de algo ser feito por uma pessoa no mundo real no necessariamente significa que isso uma boa alternativa em software mais comum "dar vida aos objetos" (no animados)
Consequncias
Maior possibilidade de reuso, j que o business logic no est nos objetos de interface
Exemplo: embutir o business logic num objeto de interface no permitiria fazer EAI (Enterprise Application Integration)
Ajuda a verificar o sequenciamento das operaes do sistema, atravs do estado do controlador
Responsabilidades, Role Playing e Cartes CRC
Embora no faa parte de UML, uma tcnica chamada Cartes CRC muito usada para atribuir responsabilidades durante o projeto CRC = Class-Responsibility-Collaborations CRC cards inventadas por Ward Cunningham e Kent Beck (Tektronix) Carto CRC um carto pequeno (para s escrever o essencial) para cada classe Escreve-se o nome da classe, suas responsabilidades e colaboraes
S pense nas responsabilidades de alto nvel
So desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes Mais detalhes aqui:
Designing Object-Oriented Software, Wirfs-Brock, Wilkerson e Wiener; Prentice Hall, 1990.
Algumas pessoas acham que melhor usar ferramentas grficas em vez de CRC
04/02/2012
Projeto de Solues com Objetos e Padres
Page 1 of 4
Introduo
O aluno responsvel por estudar o captulo 19 do livro-texto (Larman)
Trazer dvidas para a aula
O captulo utiliza padres para atribuir responsabilidades e construir diagramas de colaborao para os seguintes Use Cases do estudo de Caso
Comprar Itens, com os seguintes eventos de sistema:

entraItem fimDeVenda faaPagamento startUp
Start Up, com o seguinte evento de sistema:
Os diagramas de colaborao so resumidos abaixo
entraItem
04/02/2012
Page 2 of 4
fimDeVenda
totalDeVenda
No operao de sistema, mas necessrio para o cumprir o contrato
faaPagamento
Incluindo log da venda
04/02/2012
Page 3 of 4
troco
No operao de sistema, mas necessrio para o cumprir o contrato
startUp
Criao do objeto inicial de domnio e demais objetos
Conexo entre camadas de apresentao e de domnio
04/02/2012
Page 4 of 4
04/02/2012
Visibilidade
Page 1 of 3
Visibilidade
Introduo

Mensagens entre objetos s podem ocorrer se o receptor for visvel ao remetente H quatro formas bsicas de visibilidade

Visibilidade Visibilidade Visibilidade Visibilidade
de atributos de parmetros declarada localmente global
Visibilidade de atributos
No estudo de caso, para que TPDV possa enviar uma mensagem a CatlogoDeProdutos, usa-se um atributo em TPDV
public class TPDV { private CatlogoDeProdutos catlogo; ... } Visibilidade de parmetros

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\proj1\proj7.htm 04/02/2012
Visibilidade
Page 2 of 3
Um objeto tem visibilidade para outro se este for recebido como parmetro No estudo de caso, para criar uma linha de detalhe de venda, TPDV chama criaLinhaDetalhe de Venda, passando a especificao do produto
Assim, Venda tem visibilidade para a especificao de produto
A visibilidade de parmetro frequentemente convertida para visibilidade de atributo Exemplo: LinhaDetalheVenda recebe a especificao de produto como parmetro no construtor e a especificao armazenada como atributo de LinhaDetalheVenda
Visibilidade declarada localmente
Um objeto visvel a partir de uma varivel local de um mtodo
Pode inicializar a varivel local com um novo objeto, receber como valor de retorno de alguma chamada, etc.
Exemplo do estudo de caso:
04/02/2012
Visibilidade
Page 3 of 3
Visibilidade global

Um objeto global visvel a todos No uma boa forma de ter visibilidade Se for obrigado a ter objetos globais, melhor usar o padro de projeto Singleton (GoF)
Visibilidade em UML

Uso de Stereotypes No usado em diagramas, normalmente
Visibilidade em Java
public para definir acesso a mtodos pblicos

Que fazem parte da interface ao objeto para quem vai cham-lo No usa para atributos
private para acesso estritamente privado ao objeto (na realidade classe) protected para definir acesso a mtodos ou atributos que devem ficar disponveis para quem estende a classe (acessvel a subclasses) "package" (sem modificador) para acesso quase pblico a todas as classes do package

Semelhante a friend de C++ usar com cuidado
04/02/2012
Diagramas de Classe para a Fase de Projeto
Page 1 of 6
Introduo

Ao completar os diagramas de interao, pode-se completar o diagrama de classes Na realidade, o diagrama de classes criado em paralelo com os diagramas de interao
No final, falta incluir alguns detalhes finais
Exemplo de um Diagrama de Classes
Diagrama de classes na fase de projeto
Deve especificar as classes de software e as interfaces da aplicao
No somente das entidades conceituais Classes, associaes e atributos Interfaces, incluindo mtodos e constantes Mtodos Informao de tipo de atributos Navegabilidade Dependncias
04/02/2012
Informao tipicamente includa:

Page 2 of 6
Como construir um diagrama de classes

1. Identificar todas as classes que participam da soluo em software
Isso feito pela anlise dos diagramas de interao
2. Inclui-las num diagrama de classes 3. Duplicar os atributos, a partir das entidades associadas no modelo conceitual 4. Adicionar nomes de mtodos descobertos nos diagramas de interao 5. Adicoonar informao de tipo aos atributos e mtodos 6. Adicionar as associaes necessrias para a visibilidade de atributos 7. Adicionar setas s associaes para indicar a dirao da visibilidade de atributos 8. Adicionar linhas de relaes de dependncia para indicar a visibilidade que no seja de atributo
Modelo conceitual versus diagrama de classes da fase de projeto

Para ambos, UML usa o diagrama de classes No modelo conceitual, uma entidade no representa uma classe de software mas um conceito do domnio do problema No diagrama de classes da fase de projeto, as classes so de software
Criao dos diagramas de classe do estudo de caso

Identificar as classes de software

Verificar todos os diagramas de interao para identificar classes Adicion-las ao diagrama de classes, junto com os atributos No precisa incluir classes que no participam da iterao atual
04/02/2012
Page 3 of 6
Adicionar nomes de mtodos

Analisar os diagramas de interao para descobrir os mtodos de cada classe Alguns detalhes sobre mtodos
O mtodo create() de UML no aparece em muitas linguagens, pois uma chamada a um construtor Muitas vezes, no se incluem os mtodos acessores (getAtributo() e setAtributo()) Se classes de bibliotecas (ex. Vector em Java) so mostrados no diagrama, no se precisa mencionar seus mtodos
Pode-se usar a sintaxe da linguagem de programao final, se desejado
Diagrama at agora:
Adio de informao de tipo
Este passo opcional

04/02/2012
Page 4 of 6
Se o diagrama de classes est sendo criado numa ferramenta CASE (ex. Rational Rose), e a ferramenta ser usada para gerar cdigo, todos os detalhes de tipos devem ser dados Se o diagrama for preparado apenas para leitura por desenvolvedores, o nvel de detalhamento pode ser menor
O seguinte diagrama contm toda a informao de tipo
Adicionar Associaes e Navegabilidade
A navegabilidade implica visibilidade da fonte para o destino
Normalmente navegabilidade de atributo, includa na implementao Isso diferente das associaes no modelo conceitual, as quais podem ser includas para melhorar o entendimento
As associaes devem ser apenas aquelas necessrias para a visibilidade de objetos
Os diagramas de interao so usados para descobrir a visibilidade, associaes e navegabilidade Situaes comuns que levam a associaes:

A envia uma mensagem a B A cria uma instncia de B A deve manter conhecimento de B
Exemplo:
04/02/2012
Page 5 of 6
Diagrama de classes at agora:
Adio de relaes de dependncia
Quando uma classe conhece outra (tem visibilidade), mas a visibilidade no de atributo, usa-se uma linha tracejada Exemplo: TPDV recebe um objeto da classe EspecificaoDeProduto como retorno do mtodo especificao da classe TPDV Diagrama de classes com dependncias:
Incluindo detalhes de membros de classes
UML possui sintaxe para especificar:

Visibilidade Valores iniciais

04/02/2012
Page 6 of 6
etc.
Exemplo:
04/02/2012
Esquema de banco de dados e mapeamento OO-Relacional
Page 1 of 12
Referncias
H uma discusso detalhada de como tratar persistncia de objetos de vrias formas nos livros:

Object-Oriented Modeling and Design for Database Applications, Blaha e Premerlani, Prentice Hall, 1998. Database Design for Smarties, Muller, Morgan Kaufmann Publishers, 1999.
Este livro tambm cobre o mapeamento para SGBDs Objeto-Relacionais
Nossa discusso um breve resumo do material desses dois livros
Um tratamento completo no pode ser dado nesta disciplina devido a restries de tempo Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design, Larman, PrenticeHall, 1998.
Tambm tem uma breve discusso de como montar um framework de persistncia no livro:
Frameworks profissionais de persistncia podem ser vistos nos produtos TopLink e CocoBase Falaremos especialmente do mapeamento de um modelo OO para um esquema relacional
No h tempo para tratar do mapeamento para SGBDs Objeto-Relacionais
Supe-se uma certa familiaridade com o modelo relacional
Resumo da seo

Implementao da identidade de objetos Implementao de domains Implementao de classes Implementao de operaes Implementao de associaes simples Implementao de associaes avanadas Implementao de herana simples Implementao de herana mltipla Resumo dos passos para o mapeamento OO-Relacional
Implementao da identidade de objetos

Em SGBDOOs, objetos possuem identidade baseada na existncia, mas isso no automtico num SGBDR Com um SGBDR (ou quando usam-se arquivos para a persistncia), pode-se usar uma de duas alternativas:
Identidade baseada na existncia
O SGBDR gera um identificador nico (OID) para cada registro
O OID armazenado numa coluna adicional e a chave primria da tabela
Identidade baseada em valor
Uma combinao de atributos identifica cada registro
As duas alternativas podem ser misturadas num mesmo esquema Vantagens da identidade baseada na existncia

A chave primria um atributo nico, pequeno e uniforme em tamanho Algumas tabelas no possuem uma combinao de atributos que possa ser chave primria
04/02/2012
Page 2 of 12
Desvantagens da identidade baseada na existncia

Alguns SGBDs podero no oferecer a gerao de identificadores nicos A gerao de identificadores nicos pode necessitar de acesso a dados globais, interferindo assim com o controle de concorrncia e deixando a aplicao potencialmente mais lenta Pode complicar a depurao das aplicaes
J que os OIDs no possuem semntica em nvel de aplicao
Vantagens da identidade baseada em valor
As chaves primrias possuem semntica clara em nvel de aplicao, facilitando a depurao e manuteno do BD A distribuio do BD pode ser mais fcil

Porque no h gerao centralizada de identidade Mas manter a unicidade das chaves pode no ser simples
Desvantagens da identidade baseada em valor
Chaves primrias podem ser mais difceis de alterar
Devido propagao causada por chaves estrangeiras usadas em associaes e herana
A propagao poder no ser suportada automaticamente pelo SGBD
Recomendaes
Usar identidade baseada na existncia para esquemas maiores (com mais de 30 classes)
No precisa incluir o OID como atributo no modelo UML
Caso contrrio, para aplicaes pequenas, considere utilizar a identidade baseada em valor, ou uma combinao das duas tcnicas
No modelo UML, acrescente o tag {OID} para os atributos que participam da chave primria
H quem recomende usar identidade baseada na existncia sempre
Implementao de domains

Precisamos agora pensar sobre o tipo de dados que armazenaremos no BD Que tipos sero usados nas declaraes de colunas? Domains so usados para lidar com a questo
Um domain um subconjunto nomeado dos valores possveis para um atributo Promovem um projeto mais consistente do que com o uso direto dos vrios tipos de dados Facilitam as mudanas Ajudam a validar consultas
Domains:

O padro ANSI SQL-92 suporta o conceito de domain. Exemplo:
CREATE DOMAIN Boolean AS CHAR(1) NOT NULL DEFAULT 'T' CONSTRAINT Bool_Constraint CHECK (Boolean IN ('T', 'F'));

Pode-se assim criar domains para os tipos de dados que sero armazenados no BD Infelizmente, a maioria dos SGBDs no d suporte a domains!
Portanto, domains so geralmente implementados:

Usando clusulas CHECK do SQL na definio dos atributos Ou usando cdigo de aplicao
Infelizmente, esse cdigo de verificao de domains deve ser inserido sempre que se define um atributo, j que no h suporte a domains ANSI Use o tipo de dado apropriado e especifique um tamanho

Para domains simples tais como nomes, Strings e valores financeiros:
Use tipos ANSI (CHARACTER, CHARACTER VARYING, ...) Ou use tipos do SGBD (Oracle: VARCHAR2, NUMBER, ...)
Para domains de enumerao, h 4 solues
String de enumerao: armazene o atributo de enumerao como string

Use CHECK ou cdigo de aplicao para verificar valores Soluo simples mas no pode ser estendida a muitos valores Exemplo:
CREATE TABLE Pessoa ( EstadoCivil CHARACTER(1) NULL CHECK (EstadoCivil IN ('S', 'C', 'D', 'V')) ...
Page 3 of 12
Codificao da enumerao: como acima, mas usando inteiros em vez de strings

Uma tabela pode fornecer o mapeamento entre inteiros e strings correspondentes Vantagens:

Mais fcil lidar com mltiplas lnguas Usam menos espao em disco Complica a depurao e manuteno (devido ao uso de "nmeros mgicos" sem semntica prpria)
Desvantagem (sria)
Um flag por valor de enumerao: use um atributo booleano para cada valor de enumerao
Funciona bem apenas quando mltiplos valores podem ser aplicveis (atributos no mutuamente exclusivos) Exemplo:
CREATE TABLE xxx ( Vermelho CHARACTER(1) NULL Azul CHARACTER(1) NULL Amarelo CHARACTER(1) NULL ... )
Uma tabela de enumerao: os valores possveis para a enumerao so armazenados numa tabela parte

Pode haver uma tabela por enumerao ou uma tabela para todas as enumeraes O cdigo de aplicao verifica que o valor do atributo pertence tabela Boa soluo quando h muitos valores Vantagem de ter os valores possveis no prprio BD em vez de t-los no cdigo Novos valores podem ser inseridos facilmente, sem modificar o cdigo Mas tabelas adicionais complicam o esquema e o cdigo genrico de manipulao
Para pequenas enumeraes, mais fcil usar strings e um constraint em SQL
Use quando h muitos valores ou valores desconhecidos durante o desenvolvimento Exemplo:
CREATE TABLE TipoEstadoCivil ( Valor CHAR(1) PRIMARY KEY, DisplayString VARCHAR2(50) NOT NULL, Descricao VARCHAR2(2000)); INSERT INTO TipoEstadoCivil (Valor, DisplayString) VALUES ('S', 'Solteiro'); INSERT INTO TipoEstadoCivil (Valor, DisplayString) VALUES ('C', 'Casado'); INSERT INTO TipoEstadoCivil (Valor, DisplayString) VALUES ('D', 'Divorciado'); INSERT INTO TipoEstadoCivil (Valor, DisplayString) VALUES ('V', 'Viuvo'); ) CREATE TABLE Pessoa ( EstadoCivil CHARACTER(1) NOT NULL DEFAULT 'U' REFERENCES TipoEstadoCivil(Valor), ... )
Para domains estruturados, h trs alternativas, todas vlidas em certas situaes
Concatenao: jogue fora a estrutura e armazene o atributo como string
Exemplo

Uma Pessoa tem um Endereo O Endereo um domain estruturado (possui vrios atributos)
04/02/2012
Page 4 of 12
Armazene o endereo inteiro como string
Mltiplas colunas
O Endereo seria armazenado na tabela Pessoa em colunas diferentes Pessoa referencia um registro da tabela Endereo
Tabela separada
Para domains multivalorados, use as tcnicas de domains estruturados
No h suporte especial do modelo relacional, porque domains multivalorados no obedecem a primeira forma normal
Implementao de classes
No modelo de projeto, algumas classes so persistentes e outras no
As classes persistentes tm o esteretipo UML persistent As demais definem um comportamento transiente que deve ser tratado no cdigo da aplicao Discutiremos o que fazer com as operaes na prxima subseo
Tratamos aqui apenas das classes persistentes
Uma classe contm atributos e operaes
De forma geral, cada classe persistente se transforma numa tabela e cada atributo se transforma numa coluna da tabela Para cada tabela, trata-se a questo de identidade vista acima Para cada atributo, trata-se a questo de domains vista acima O modelo relacional no trata a visibilidade dos atributos
Todos os atributos so pblicos
Para atributos que tm tag UML {OID}, use um constraint PRIMARY KEY Para atributos que tm tag UML {alternate OID} (alternate key), use um constraint UNIQUE Para atributos que tm tag UML {nullable}, no use o constraint NOT NULL, caso contrrio, use NOT NULL
Alguns SGBDs permitem que voc use o constraint NULL que no faz parte do padro ANSI na definio de colunas
Implementao de operaes

Um SGBD Relacional no permite encapsular operaes (mtodos) com classes Por outro lado, stored procedures so possveis, o que permite colocar alguma funcionalidade dos mtodos dos objetos da aplicao no SGBD
Alguns SGBDs oferecem tambm stored functions que retornam valor No final das contas, podemos particionar o cdigo entre o servidor de BD e as outras camadas (middle tier, cliente) O que melhor colocar no SGBD e o que melhor deixar fora? No se pode colocar operaes que lidam com aspectos transientes no SGBD
A questo bsica : "Que tipo de funcionalidade pode ser adequadamente colocada em stored procedures?"
Algumas regras sobre o que evitar seguem:
O cdigo de stored procedures no pode acessar os objetos que esto em memria nas outras camadas Um SGBDR acessa dados naturalmente por registro, no por atributo individual O acesso ao BD atributo por atributo resultaria numa aplicao muito lenta
No se deve usar stored procedures para acessar dados atributo por atributo

Evite stored procedures que tenham que deixar "estado transiente" armazenado no BD para fazer outras operaes subsequentes (no armazenar estado comportamental usado entre chamadas)
Embora alguns SGBDs (Oracle, por exemplo) permitam que isso seja feito, melhor que cada chamada a um stored procedure seja reentrante e no dependa de estado O sistema resultante muito mais simples e fcil de manter e depurar Tal tipo de estado deve ser mantido na camada do meio (aplicao)
Evite fazer grandes quantidades de verificao de erro, com condies de aborto, etc. no SGBD. Mantenha isso em outra camada (aplicao ou cliente) Algumas operaes de alto desempenho podero ser mais rpidas quando executadas numa linguagem compilada (em outra camada), em vez de uma linguagem interpretada para executar stored procedures (como PL/SQL do Oracle, Transact/SQL do SQLServer) Evite fazer aes transacionais (COMMIT, ROLLBACK) em stored procedures

Faa isso em outra camada A semntica de transao expressa melhor na aplicao em si
Seria ruim um programador chamar um stored procedure e, depois, ao verificar um erro e tentar
04/02/2012
Page 5 of 12
fazer um ROLLBACK, descobrir que a transao j sofreu COMMIT
O que pode ser colocado no SGBD como stored procedures?

Fazer uma consulta dando um result set (um conjunto de registros) Insert/update/delete, mas apenas de registros inteiros, no atributo por atributo Verificao de regras de consistncia e outros business rules

Talvez este seja o motivo principal do uso de Stored Procedures Triggers podem ser valiosos aqui tambm
Operaes que chamam outros stored procedures (para acessar o dicionrio, por exemplo) Verificao de erros (mas apenas erros relacionados com a estrutura do BD) Ao usar um SGBDR, no h suporte a polimorfismo
Como tratar polimorfismo?
Mesmo SGBDORs tm suporte fraco ou inexistente a polimorfismo Pode usar em classes transientes
Evite-o portanto, nas classes persistentes
Se o polimorfismo for usado na modelagem de classes persistentes, ele tem que ser transformado em ifthen-else e chamadas as stored procedures diferentes
Todas essas restries explicam porque se fala do impedance mismatch!
Implementao de associaes simples
Associaes simples so:

1-para-1 0..1-para-1 1-para-muitos muitos-para-muitos Sempre considere primeiro o mapeamento recomendado Mapeamentos alternativos podem ser usados por uma questo de desempenho, extensibilidade, ou estilo
Descrevemos mapeamentos recomendados, alternativos e desencorajados para cada tipo

Associaes 1-para-1
Recomendado

Embutir a chave estrangeira em qualquer uma das classes A chave estrangeira poder ser nula se houver uma cardinalidade mnima de 0 no alvo A associao pode ser implementada numa tabela parte A chave primria da tabela de associao pode ser qualquer uma das duas chaves estrangeiras Vantagem: o esquema mais extensvel
Alternativo

Se houver mudana na cardinalidade da associao, basta mudar o constraint, no a estrutura de tabelas
Desvantagens: fragmentao do esquema e maior overhead de navegao (com joins) Combinao: no junte duas classes e sua associao numa nica tabela
Desencorajado
O esquema mais fcil de entender se seguir o modelo de objetos
Associaes bi-direcionais: no coloque duas chaves estrangeiras, uma em cada tabela referenciando a outra
Os SGBDs no vo manter a consistncia das associaes redundantes
Associaes 0..1-para-1
Recomendado

Embutir a chave estrangeira na classe com a cardinalidade 0..1 A chave estrangeira NOT NULL
Associaes 1-para-muitos
Recomendado

Embutir a chave estrangeira na classe com cardinalidade "muitos" Se a cardinalidade 1 (do alvo) puder ser 0-1, a chave estrangeira pode se nula Exemplo:
04/02/2012
Page 6 of 12
Alternativo

A associao pode ser implementada numa tabela parte A chave estrangeira para a classe "muitos" a chave primria da tabela de associao Mesmas vantagens e desvantagens do mapeamento 1-para-1 Exemplo:
Associaes muitos-para-muitos
Recomendado

A associao mapeada para uma tabela distinta A chave primria da tabela de associao uma combinao das chaves estrangeiras Exemplo:
Implementao de associaes avanadas
Associaes avanadas so:

Associao qualificada Classe de associao Associao ordenada Associao ternria
Associao qualificada
Lembre que uma associao qualificada uma associao "para-muitos" onde os objetos envolvidos do lado "muitos" so total ou parcialmente especificados usando um atributo chamado o qualificador Tais associaes aumentam a preciso do modelo Um qualificador seleciona um ou mais dentre vrios objetos-alvo, com o efeito de reduzir a cardinalidade, s vezes at 1 Quando a cardinalidade final 1, a associao qualificada especifica uma forma precisa de selecionar o objeto alvo a partir do objeto fonte Exemplo:

Uma descrio de vo se aplica a muitos vos A combinao de uma descrio de vo mais uma data de partida especifica um vo
04/02/2012
Page 7 of 12
Recomendado

O mapeamento tal qual para a associao sem qualificador No exemplo acima, uma chave estrangeira seria includa na classe Vo
Classe de associao

uma associao com uma classe que a descreve A classe de associao pode participar de outras associaes Recomendado

Implemente a associao com uma tabela distinta A chave primria da classe de associao uma combinao das chaves primrias das classes envolvidas na associao Exemplo:
Associao ordenada

Ocorre quando as ligaes entre objetos possuem uma ordem Exemplo: janelas podem estar ordenadas numa tela (indicando qual est na frente das outras) O tag UML {ordered} usado na associao ( ou {ordered by ...}) Recomendado
Introduzir um nmero de sequncia como atributo
Associao ternria
Exemplo:
04/02/2012
Page 8 of 12
Recomendado
Uma tabela distinta deve ser usada para representar a associao ternria
Agregaes
Recomendado
Agregaes so associaes e so implementadas como tal
Implementao de herana simples (generalizao)
Recomendado

Normalmente, a herana implementada com tabelas separadas para a superclasse e cada subclasse Idealmente, um objeto tem a mesma chave primria na hierarquia inteira A superclasse inclui um discriminador que indica qual subclasse se aplica
Isso no mostrado no modelo de objetos
A integridade referencial pode ser usada para garantir que um registro da superclasse exista para cada registro de uma subclasse
Entretanto, se a superclasse for abstrata e exigir que haja um objeto de uma subclasse, a integridade referencial no pode solucionar o problema O cdigo da aplicao deve implementar a restrio
Exemplo:
Pode-se usar uma View para cada subclasse, no sentido de consolidar os dados herdados e facilitar o acesso ao objeto Exemplo:
04/02/2012
Page 9 of 12
CREATE VIEW view_PagamentoCC AS SELECT pagamentoID, valor, tipoCC, numeroCC FROM Pagamento AS P JOIN PagamentoCC as CC ON P.pagamentoID = CC.pagamentoCCID
Alternativo
Eliminao
Como otimizao, subclasses que no contm atributos, fora a chave estrangeira, podem ser eliminadas Desvantagens

O cdigo de navegao tem que saber se h uma tabela ou no para implementar a subclasse Falta de extensibilidade: se houver uma adio subclasse, a tabela vai ter que voltar
Exemplo:
Empurrar atributos da superclasse para baixo

Elimine a superclasse e duplique seus atributos para cada subclasse Uma nica tabela contm todos os dados de um objeto (no h necessidade de join para reconstituir um objeto) Desvantagens

Introduz redundncia no esquema Poder ser necessrio pesquisar vrias tabelas para achar um objeto Se vrios nveis de hierarquia estiverem envolvidos, a estrutura da generalizao (herana) perdida
Exemplo:
04/02/2012
Page 10 of 12
Empurrar atributos da subclasse para cima
Neste caso, as subclasses so eliminadas e todos seus atributos migram para a tabela da superclasse Atributo desnecessrios para certos objetos so nulos Essa alternativa viola a segunda forma normal porque alguns atributos no dependem completamente da chave primria Exemplo:
Abordagem hbrida
Empurrar os atributos da superclasse para baixo mas manter a tabela da superclasse para navegar nas subclasses Exemplo:
04/02/2012
Page 11 of 12
Tabela de generalizao
Semelhante ao mapeamento recomendado (tabelas para superclasse e subclasses) mas adicionando uma tabela de generalizao que amarra a chave primria da superclasse chave primria da subclasse
A chave primria das subclasses a chave "natural" da tabela e no mais a mesma da superclasse como no mapeamento recomendo inicial
Implementao de herana mltipla
Recomendado
Usar o mapeamento recomendado acima (tabelas distintas para superclasse e subclasses)
Resumo dos passos para o mapeamento OO-Relacional

1. Cada classe UML mapeada para uma tabela 2. Cada atributo da clase uma coluna da tabela 3. O tipo do atributo mapeado para um tipo da coluna, de acordo com regras de transformao de tipos 4. Se o atributo tem o tag UML {nullable}, a coluna tem constraint NULL; caso contrrio, tem constraint NOT NULL 5. Se o atributo UML tem um inicializador, adicionar a clusula DEFAULT coluna 6. Para cada classe sem generalizao ( raiz de hierarquia ou no participa de hierarquia) e com identidade baseada na existncia, criar uma chave primria inteira; com identidade baseada em valor, adicionar as colunas com tag UML {OID} ao constraint PRIMARY KEY 7. Para subclasses com uma nica superclasse com chave primria de uma coluna, adicionar a chave da superclasse ao constraint PRIMARY KEY e adicionar uma clusula REFERENCES para relacionar a coluna (chave estrangeira) chave primria da superclasse 8. Para subclasses com uma nica superclasse com chave primria de vrias colunas, use constraints de tabela PRIMARY KEY e FOREIGN KEY em vez do constraint de coluna do item anterior 9. Para herana mltipla, adicione uma coluna na subclasse para cada chave primria de cada superclasse; adicione um constraint de tabela FOREIGN KEY com todas essas colunas (que referenciam chaves primrias das superclasses) 0. Para classes de associao, adicione uma coluna para a chave primria de cada classe participando da
Page 12 of 12
associao; use um constraint FOREIGN KEY 1. Para tags UML {alternate OID}, adicione as colunas envolvidas ao constraint UNIQUE 2. Adicione CHECK para cada constraint explcito 3. Crie tabelas para as associaes que no usam chaves estrangeiras embutidas (muitos-para-muitos, ternrias, ...), e use constraint de tabela FOREIGN KEY 4. Para agregaes, use a opo ON DELETE CASCADE, ON UPDATE CASCADE na tabela agregadora
proj1-9 programa anterior
04/02/2012
5. Fase de Implementao
Page 1 of 1
5. Fase de Implementao

Mapeamento do projeto para cdigo Programa exemplo em Java Testes de unidade Adicionando uma interface com o usurio
impl programa
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\impl\index.htm
04/02/2012
Mapeamento do Projeto para Cdigo
Page 1 of 2
Com os artefatos j produzidos, estamos prontos para implementar (codificar e testar) A codificao feita a partir dos artefatos de projeto
Diagramas de colaborao e diagrama de classes Porque explorar alternativas mais barato em fases anteriores
Deve-se codificar depois de um esforo suficiente de anlise e projeto
No entanto, alguma atividade de prototipagem pode ser feita em fases anteriores Em termos de maturidade de processo de desenvolvimento, codificar cedo demais no leva a um processo que possa ser repetido
Os riscos so muito maiores
A atividade de codificao em si uma traduo bastante mecnica dos modelos produzidos
A criatividade no ocorre durante a codificao mas antes dela Portanto, depois da codificao, os artefatos j produzidos devem ser sincronizados com o cdigo Uma ferramenta CASE que faz Engenharia Reversa pode ajudar aqui
Porm, a codificao frequentemente leva a modificaes em decises anteriores
Ela l o cdigo e produz diagramas de modelos
Mapeamento do projeto para cdigo
Deve-se escrever:

Cdigo para interfaces e classes Cdigo para os mtodos
Criao de definies de interfaces e classes

Feita a partir de diagramas de classes Os passos so simples, lembrando que tipos suportados pela linguagem devem ser escolhidos A navegabilidade indica que atributos referenciando outros objetos devem ser includos na classe
desejvel chamar o atributo pelo papel assumido pelo destino da associao

04/02/2012
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\impl\impl1.htm
Page 2 of 2
Criao de mtodos
Feita a partir dos diagramas de colaborao, examinando as mensagens enviadas entre os objetos
Atualizao das definies de classes
Aps a codificao (e testes), as definies de classes so alteradas para incluir novos mtodos introduzidos, etc.
Tratamento de erros
Embora tenhamos nos concentrado na atribuio de responsabilidades, a atividade de projeto deve tambm considerar como ser feito o tratamento de erros Normalmente usa o mecanismo de excees Uma parte significativa do cdigo diz respeito ao tratamento de erros
Ordem de implementao
Classes individuais devem ser codificadas e sujeitas a testes de unidade na ordem da menos acoplada mais acoplada
Para minimizar scaffolding
Uma ordem sugerida no estudo de caso seria como mostrado abaixo
impl-1 programa prxima
04/02/2012
Fase de Implementao
Page 1 of 10
Programa Exemplo em Java
O cdigo abaixo no inclui sincronizao devido a acessos concorrentes, nem tratamento de persistncia O cdigo abaixo diferente do cdigo do livro
Usa interfaces para desacoplar classes
Apenas as interfaces externas foram definidas de forma a produzir a documentao externa de quem usa as classes (ver documentao externa) Outras interfaces (internas) poderiam ser definidas para ter mais polimorfismo dentro do pacote
Inclui comentrios javadoc para produzir documentao automaticamente Alguns modificadores de acesso (public, ...) foram alterados Usa Factory Methods (ver Design Patterns, em outro captulo) Alguns mtodos faltam no livro
Exemplo: Loja tem que ter um getCatlogoDeProdutos(), seno a camada de interface com o usurio no consegue obter a descrio de um produto com dado UPC para exibir ao cliente Acentuao usada em atributos e mtodos mas no em nomes de classes e interfaces porque, neste ltimo caso, o nome do arquivo igual classe/interface e quero evitar acentuao em nomes de arquivos (portabilidade) Falta tratar mais um ou dois erros possveis que estou deixando para o aluno descobrir (e tratar!)
Est em portugus
Tem tratamento de erro completo com 3 tipos de excees
O resultado um cdigo mais profissional

Porm, as coisas sempre podem ser melhoradas Por exemplo: o uso de float para representar valores monetrios no foi uma boa deciso do autor Larman

Por qu? Como voc faria?
Documentao
A documentao externa est aqui

Observe que nesta documentao, h apenas a informao que pode ser usada "de fora", isto , pelas classes da interface do usurio O nico objeto que pode ser criado uma Loja A partir da Loja, pode-se obter um TPDV, ou um catlogo de produtos para fazer as outras operaes associada interface com o usurio til para os desenvolvedores do pacote
A documentao interna est aqui
Interface IPagamento package tpdv; /** * Interface para qualquer tipo de pagamento. * * @author Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ interface IPagamento { /** * Retorna o valor entregue pelo cliente para pagar a venda. * @return O valor entregue pelo cliente para pagar a venda. */ float getValor(); } Classe Pagamento package tpdv; /** * Classe que representa um pagamento feito para uma venda.
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\impl\impl2.htm 04/02/2012
Fase de Implementao
Page 2 of 10
* * @author Craig Larman, Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ class Pagamento implements IPagamento { /** * O valor do pagamento de uma venda. */ private float valor; /** * Cria um pagamento. * @param valorEntregue O valor entregue para pagar a venda. */ public Pagamento(float valorEntregue) { this.valor = valorEntregue; } /** * Cria um pagamento. * @param valorEntregue O valor entregue para pagar a venda. */ public Pagamento(double valorEntregue) { this.valor = (float)valorEntregue; } /** * Retorna o valor entregue para pagar a venda. * @return O valor entregue para pagar a venda. */ public float getValor() { return valor; } } Interface IEspecProduto package tpdv; /** * Interface para qualquer tipo de especificao de produto. * * @author Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ public interface IEspecProduto { /** * Obtem o Universal Product Code (UPC) do produto. * @return O Universal Product Code (UPC) do produto. */ int getUPC(); /** * Obtem o preo do produto. * @return O preo do produto. */ float getPreo(); /** * Obtem a descrio do produto. * @return A descrio do produto. */ String getDescrio(); } Classe EspecificacaoDeProduto package tpdv; /** * Classe que representa uma especificao de um produto do catlogo de produtos. * * @author Craig Larman, Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ class EspecificacaoDeProduto implements IEspecProduto { /** * O Universal Product Code (UPC) do produto.
Fase de Implementao
Page 3 of 10
*/ private int upc; /** * O preo do produto. */ private float preo; /** * A descrio do produto. */ private String descrio; /** * Cria uma especificao de produto. * @param upc O Universal Product Code do produto. * @param preo O preo do produto. * @param descrio A descrio do produto. */ public EspecificacaoDeProduto(int upc, float preo, String descrio) { this.upc = upc; this.preo = preo; this.descrio = descrio; } /** * Cria uma especificao de produto. * @param upc O Universal Product Code do produto. * @param preo O preo do produto. * @param descrio A descrio do produto. */ public EspecificacaoDeProduto(int upc, double preo, String descrio) { this(upc, (float)preo, descrio); } /** * Obtem o Universal Product Code do produto. * @return O Universal Product Code do produto. */ public int getUPC() { return upc; } /** * Obtem o preo do produto. * @return O preo do produto. */ public float getPreo() { return preo; } /** * Obtem a descrio do produto. * @return A descrio do produto. */ public String getDescrio() { return descrio; } } Interface ICatalogoDeProdutos package tpdv; /** * Interface para qualquer tipo de Catlogo de Produtos * * @author Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ public interface ICatalogoDeProdutos { /** * Obtem a especificao de produto, dado o Universal Product Code (UPC) * @param upc O Universal Product Code (UPC) do produto desejado * @return A especificao de produto, dado o Universal Product Code (UPC) */ public IEspecProduto getEspecificao(int upc) throws ProdutoInexistenteException; } Classe CatalogoDeProdutos package tpdv; import java.util.*;
Fase de Implementao
Page 4 of 10
/** * Classe que representa um catlogo de produtos. * Um catlogo contm vrias especificaes de produtos. * * @author Craig Larman, Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ class CatalogoDeProdutos implements ICatalogoDeProdutos { /** * O catlogo de produtos guardado aqui. */ private Map especsProdutos = new HashMap(); /** * Cria um catlogo de produtos. Esta verso no trata de persistncia. * O catlogo fixo e criado no construtor. */ public CatalogoDeProdutos() { int upc1 = 100; especsProdutos.put(new Integer(upc1), makeEspecProduto(upc1, (float)1.99, "produto 1")); int upc2 = 200; especsProdutos.put(new Integer(upc2), makeEspecProduto(upc2, (float)3.49, "produto 2")); } /** * Obtm a especificao de um produto. * @param upc o Universal Product Code do produto cuja especificao se deseja. * @return A especificao do produto desejado. */ public IEspecProduto getEspecificao(int upc) throws ProdutoInexistenteException { IEspecProduto espec = (IEspecProduto)especsProdutos.get(new Integer(upc)); if(espec == null) { throw new ProdutoInexistenteException("Produto inexistente, UPC: " + upc); } return espec; } // factory method protected IEspecProduto makeEspecProduto(int upc, float preo, String descrio) { return new EspecificacaoDeProduto(upc, preo, descrio); } } Classe ProdutoInexistenteException package tpdv; /** * Exceo indicando produto inexistente no catlogo de produtos. * * @author Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ public class ProdutoInexistenteException extends TPDVException { /** * Cria uma exceo de produto inexistente * @param mensagem Mensagem de erro imprimvel */ public ProdutoInexistenteException(String mensagem) { super(mensagem); } } Interface ILinhaDetalhe package tpdv; /** * Interface para qualquer tipo de linha de detalhe de uma venda. * * @author Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */
Fase de Implementao
Page 5 of 10
interface ILinhaDetalhe { /** * Retorna o subtotal da venda para os itens correspondendo a esta linha de detalhe. * @return O subtotal da venda para os itens correspondendo a esta linha de detalhe. */ float subTotal(); } Classe LinhaDetalheVenda package tpdv; /** * Classe que representa uma linha de detalhe de uma venda. * * @author Craig Larman, Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ class LinhaDetalheVenda implements ILinhaDetalhe { /** * A quantidade de itens (do mesmo produto) neste detalhe de venda. */ private int quantidade; /** * A especificao do produto sendo comprado. */ private IEspecProduto espec; /** * Cria uma linha de detalhe de uma venda. * @param espec A especificao do produto sendo comprado. * @param quantidade A quantidade de itens (do mesmo produto) sendo comprados */ public LinhaDetalheVenda(IEspecProduto espec, int quantidade) { this.espec = espec; this.quantidade = quantidade; } /** * Informa o subtotal da venda correspondendo a esta linha de detalhe. * @return O subtotal da venda correspondendo a esta linha de detalhe. */ public float subTotal() { return quantidade * espec.getPreo(); } } Interface IVenda package tpdv; /** * Interface externa para qualquer tipo de venda. * * @author Craig Larman, Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ public interface IVenda { /** * Retorna o troco da venda, aps fazer um pagamento de uma venda. * @return o troco da venda, aps fazer um pagamento de uma venda. */ float getTroco(); /** * Retorna o valor total da venda, at agora. * @return o valor total da venda, at agora. */ float total(); } Classe Venda package tpdv;
04/02/2012
Fase de Implementao
Page 6 of 10
import java.util.*; /** * Classe que representa uma venda de produtos feita atravs de um TPDV. * Uma venda composta de vrias linhas de detalhe. * Enquanto a venda no terminou, tais linhas de detalhe podem ser criadas. * Um pagamento pode ser feita para pagar a venda. * Pode-se calcular o troco a ser entregue ao cliente. * * @author Craig Larman, Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ class Venda implements IVenda { /** * As linhas de detalhe da venda. */ private List linhasDetalhe = new Vector(); /** * A data da venda. */ private Date data = new Date(); // hoje /** * Indica se a venda terminou. */ private boolean isTerminada = false; /** * O pagamento efetuado para a venda. */ private IPagamento pagamento; /** * Calcula o valor total da venda. * @return O valor total da venda. */ public float total() { float total = (float)0.0; Iterator it = linhasDetalhe.iterator(); while(it.hasNext()) { total += ((ILinhaDetalhe)it.next()).subTotal(); } return total; } /** * Calcule o troco para a venda, aps um pagamento. * @return O troco para a venda. */ public float getTroco() { return pagamento.getValor() - total(); } /** * Chamado para indicar que a venda terminou. */ void terminou() { isTerminada = true; } /** * Obtm o status da venda. * @return true se a venda terminou; false caso contrrio. */ boolean isTerminada() { return isTerminada; } /** * Cria uma linha de detalhe para a venda. * @param espec A especificao do produto sendo comprado. * @param quantidade A quantidade de itens (do mesmo produto) sendo comprados. */ void criaLinhaDetalhe(IEspecProduto espec, int quantidade) { linhasDetalhe.add(makeLinhaDetalhe(espec, quantidade)); } /**
Fase de Implementao
Page 7 of 10
* Faz um pagamento para a venda. * @param valorEntregue O valor entregue pelo cliente para pagar a venda. */ void faaPagamento(float valorEntregue) throws PagamentoInsuficienteException { if(valorEntregue < total()) { throw new PagamentoInsuficienteException("Pagamento insuficiente"); } pagamento = makePagamento(valorEntregue); } // factory methods protected ILinhaDetalhe makeLinhaDetalhe(IEspecProduto espec, int quantidade) { return new LinhaDetalheVenda(espec, quantidade); } protected IPagamento makePagamento(float valorEntregue) { return new Pagamento(valorEntregue); } } Classe NaoHaVendaException package tpdv; /** * Exceo indicando operao necessitando de venda sem venda ativa * * @author Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ public class NaoHaVendaException extends TPDVException { /** * Cria uma exceo de operao necessitando de venda sem venda ativa * @param mensagem Mensagem de erro imprimvel */ public NaoHaVendaException(String mensagem) { super(mensagem); } } Classe PagamentoInsuficienteException package tpdv; /** * Exceo indicando pagamento insuficiente para uma venda. * * @author Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ public class PagamentoInsuficienteException extends TPDVException { /** * Cria uma exceo de pagamento insuficiente * @param mensagem Mensagem de erro imprimvel */ public PagamentoInsuficienteException(String mensagem) { super(mensagem); } } Interface ITPDV package tpdv; /** * Interface para qualquer tipo de Terminal Ponto De Venda (TPDV). * Um TPDV usado para fazer uma venda (uma nica venda de cada vez). * Itens podem ser comprados at o final da venda. * Um pagamento pode ser feito para a venda corrente. * * @author Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ public interface ITPDV { /**
Fase de Implementao
Page 8 of 10
* Obtm a venda corrente sendo realizada pelo TPDV. * @return A venda corrente sendo realizada pelo TPDV. */ IVenda getVenda(); /** * Chamado para indicar que a venda terminou. */ void fimDeVenda() throws NaoHaVendaException; /** * Chamado para adicionar venda corrente um nmero de itens sendo comprados. * @param upc O Universal Product Code do item sendo comprado. * @param quantidade O nmero de itens sendo comprados. */ void entraItem(int upc, int quantidade) throws ProdutoInexistenteException; /** * Realiza um pagamento para uma venda. * @param valorEntregue O valor entregue pelo cliente para pagar a venda. */ void faaPagamento(float valorEntregue) throws PagamentoInsuficienteException; } Classe TPDV package tpdv; /** * Classe que implementa um Terminal Ponto De Venda (TPDV). * Um TPDV usado para fazer uma venda (uma nica venda de cada vez). * Itens podem ser comprados at o final da venda. * Um pagamento pode ser feito para a venda corrente. * * @author Craig Larman, Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ class TPDV implements ITPDV { /** * O catlogo de produtos que podem ser vendidos neste TPDV. */ private ICatalogoDeProdutos catlogo; /** * A venda corrente sendo realizada no TPDV. */ private IVenda venda; /** * Cria um TPDV. * @param catlogo Um catlogo de produtos que podem ser adquiridos neste TPDV. */ public TPDV(ICatalogoDeProdutos catlogo) { this.catlogo = catlogo; venda = null; } /** * Obtm a venda corrente sendo realizada no TPDV. * @return A venda corrente sendo realizada no TPDV. */ public IVenda getVenda() { return venda; } /** * Quando chamado, indica que a venda corrente sendo realizada no TPDV terminou. */ public void fimDeVenda() throws NaoHaVendaException { if(venda == null) { throw new NaoHaVendaException("Nao ha venda iniciada"); } venda.terminou(); } /** * Informa um produto e a quantidade de itens deste produto sendo comprados na venda corrente.
Fase de Implementao
Page 9 of 10
* Caso a venda anterior j tenha terminado, uma nova Venda criada. * @param upc O Universal Product Code (UPC) do produto sendo comprado. * @param quantidade A quantidade de itens sendo comprados. */ public void entraItem(int upc, int quantidade) throws ProdutoInexistenteException { if(isNovaVenda()) { venda = makeVenda(); } venda.criaLinhaDetalhe(catlogo.getEspecificao(upc), quantidade); } /** * Realiza um pagamento para a venda corrente do TPDV. * @param valorEntregue O valor entregue pelo cliente para pagar a venda. */ public void faaPagamento(float valorEntregue) throws PagamentoInsuficienteException { venda.faaPagamento(valorEntregue); } // visibilidade de package para poder testar boolean isNovaVenda() { return venda == null || venda.isTerminada(); } // factory method protected IVenda makeVenda() { return new Venda(); } } Classe Loja package tpdv; /** * Classe que implementa uma Loja. Cada loja tem um catlogo de produtos e um nico TPDV. * * @author Craig Larman, Jacques Philippe Sauv, jacques@dsc.ufpb.br * @version 1.0 */ public class Loja { /** * O catlogo de produtos da loja. */ private ICatalogoDeProdutos catlogo; /** * O terminal ponto de venda (TPDV) da loja. * Uma loja s tem um nico TPDV. */ private ITPDV tpdv; /** * Cria uma loja. O catlogo de produtos e o TPDV so automaticamente criados. * @param valorEntregue O valor entregue para pagar a venda. */ public Loja() { catlogo = makeCatlogo(); tpdv = makeTPDV(catlogo); } /** * Obtem o TPDV da loja. * @return O TPDV da loja. */ public ITPDV getTPDV() { return tpdv; } /** * Obtem o TPDV da loja. * @return O TPDV da loja. */ public ICatalogoDeProdutos getCatlogoDeProdutos() { return catlogo; } // factory methods protected ICatalogoDeProdutos makeCatlogo() { return new CatalogoDeProdutos(); } protected ITPDV makeTPDV(ICatalogoDeProdutos catlogo) {
Fase de Implementao
Page 10 of 10
return new TPDV(catlogo); } }

impl-2 programa anterior prxima
04/02/2012
Testes de Unidade
Page 1 of 3
Testes de Unidade
Justificativa

Reduzir defeitos (bugs) apresentados pelo produto Cobrir uma gama maior de equipamentos e ambientes operacionais do que aqueles disponveis na empresa atravs de testes em clientes Assegurar a qualidade final do produto para o cliente, incluindo avaliao de embalagem, manuais, usabilidade, etc.
Estgios de testes

Testes so feitos em vrios estgios Fazer testes monolticos do produto inteiro aumentaria o tempo necessrio depurao total do software melhor (mais rpido) testar partes menores para depois testar a integrao dessas partes Determinados testes devem ser feitos por pessoas fora da equipe de desenvolvimento no sentido de manter a maior objetividade possvel nessas fases de testes e no sentido de envolver tambm os usurios finais fora da empresa
Automatizao de testes
Os testes devem ser automatizados
Pelo menos nas fases em que isso possvel
Scripts de testes desenvolvidos ao longo do tempo aumentam o patrimnio da empresa e garantiro uma qualidade cada vez maior
Tipos de testes
Testes de unidade

Para testar classes individuais Feito pelo prprio programador da classe Testa toda a interface da classe Para testar os Use Cases Feito pelo time de desenvolvimento Uso de Total System Environment
Testes funcionais

Testes de sistema
Incluindo outros produtos de software, todas as plataformas, todas as configuraes, etc.
Feito por uma equipe independente de testes Antes de por o sistema na rua, mesmo que tenha havido apenas uma recompilao Normalmente um subconjunto dos testes de sistema Teste de produto (com embalagem manual, etc.) num "cliente" dentro da empresa Como teste alfa mas incluindo clientes fora da empresa
04/02/2012
Testes de regresso

Teste alfa
Teste beta
Testes de Unidade
Page 2 of 3
Testes de Unidade
Necessidade de automao

Clica um boto a qualquer momento para testar tudo! Pelo menos um teste por dia (frequentemente vrios testes por hora)
Uso de um framework de testes Desenvolvimento e testes em paralelo Absolutamente necessrio ter testes de unidade, principalmente se fizer refactoring de cdigo Testar as classes da menos acoplada para a mais acoplada

Na realidade, segue a ordem de desenvolvimento Desenvolvimento e testes de unidade feitos em paralelo! Neste pacote, leia o artigo "Test Infected: Programmers Love Writing Tests" Escrito por Beck (CRC, Extreme Programming) e Gamma (GoF) Todos os testes esto aqui para o cdigo do captulo anterior
Exemplo com o framework JUnit (teste da classe Venda)

package tpdv; import junit.framework.*; import tpdv.*; /** * Testes da classe Venda. * */ public class TestaVenda extends TestCase { protected IVenda venda1; protected IEspecProduto ep1; protected IEspecProduto ep2; protected IEspecProduto ep3; public TestaVenda(String name) { super(name); } public static void main(String[] args) { junit.textui.TestRunner.run(suite()); } protected void setUp() { venda1 = new Venda(); ep1 = new EspecificacaoDeProduto(100, 1.99, "prod1"); ep2 = new EspecificacaoDeProduto(200, 2.99, "prod2"); ep3 = new EspecificacaoDeProduto(300, 3.99, "prod3"); } public static Test suite() { return new TestSuite(TestaVenda.class); } public void testConstrutor() { assert("1", !venda1.equals(null)); assertEquals("2", 0.0, venda1.total(), 0.0); assert("3", !venda1.isTerminada()); } public void testManipulacao() { venda1.criaLinhaDetalhe(ep1, 1); assertEquals("1", 1.99, venda1.total(), 0.001); venda1.criaLinhaDetalhe(ep2, 2); assertEquals("2", 1.99+(2*2.99), venda1.total(), 0.001); venda1.criaLinhaDetalhe(ep3, 2); assertEquals("3", 1.99+(2*2.99)+(2*3.99), venda1.total(), 0.001); try { venda1.faaPagamento((float)5.0); fail("facaPagamento(5.0) deveria gerar exception"); } catch(PagamentoInsuficienteException e) {
Testes de Unidade
Page 3 of 3
} try { venda1.faaPagamento((float)20.0); } catch(PagamentoInsuficienteException e) { fail("facaPagamento(20.0) nao deveria gerar exception"); } assertEquals("4", 20-1.99-(2*2.99)-(2*3.99), venda1.getTroco(), 0.001); assert("3", !venda1.isTerminada()); venda1.terminou(); assert("3", venda1.isTerminada()); } } Algumas palavras de Beck e Gamma
Sometimes you just won't feel like writing tests, especially at first. Don't. However, pay attention to how much more trouble you get into, how much more time you spend debugging, and how much more stress you feel when you don't have tests. We have been amazed at how much more fun programming is and how much more aggressive we are willing to be and how much less stress we feel when we are supported by tests. The difference is dramatic enough to keep us writing tests even when we don't feel like it.
impl-3 programa anterior prxima
04/02/2012
Adicionando uma Interface com o Usurio
Page 1 of 3
Interface com o usurio

O business logic estando pronto e testado, podemos fazer uma interface com o usurio Pode-se fazer uma interface em 1 camada, 2 camadas, com applets, 3 camadas com servlets ou JSP, 4 camadas com RMI, etc. Observe que o business logic no muda para qualquer tipo de interface Ao ver o cdigo da interface com o usurio, observe que a lgica s de apresentao e de verificao de dados de entrada Uma interface Swing em 1 camada pode ser vista aqui

Est no package tpdvui Foi feita com JBuilder 3.0
A interface parece a seguinte:
A interface no muito funcional e merece ser repensada
Alguns trechos de cdigo

A classe principal
public class Tpdv { public Tpdv() { TpdvFrame frame = new TpdvFrame(); // ... um monte de coisinhas frame.setVisible(true); } public static void main(String[] args) { try { UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); } catch(Exception e) { } new Tpdv(); } }
A classe TpdvFrame
04/02/2012
Page 2 of 3
public class TpdvFrame extends JFrame { Loja loja = new Loja(); ITPDV tpdv = loja.getTPDV(); // ... }
Atendimento ao clique do boto Entra Item

Tem umas 8 linhas de interesse e mais de 20 linhas de verificao e captura de erros Isso perfeitamente normal!
public class TpdvFrame extends JFrame { // ... void entraItem_actionPerformed(ActionEvent e) { if(upc.getText().equals("")) { JOptionPane.showMessageDialog(this, "UPC deve ser informado"); return; } if(quantidade.getText().equals("")) { JOptionPane.showMessageDialog(this, "Quantidade deve ser informada"); return; } int upcInt = 0; int quant = 0; try { upcInt = Integer.parseInt(upc.getText()); } catch(NumberFormatException ex) { JOptionPane.showMessageDialog(this, "Produto " + upc.getText() + " inexistente"); } try { quant = Integer.parseInt(quantidade.getText()); } catch(NumberFormatException ex) { JOptionPane.showMessageDialog(this, "Quantidade deve ser numrica"); } try { tpdv.entraItem(upcInt, quant); } catch(ProdutoInexistenteException ex) { JOptionPane.showMessageDialog(this, ex.getMessage()); return; } upc.setText(""); quantidade.setText(""); total.setText(""); valorEntregue.setText(""); troco.setText(""); } // ... }
Atendimento ao clique do boto Fim Venda
2 linhas de interesse e 5 linhas de verificao e captura de erros
public class TpdvFrame extends JFrame { // ... void fimVenda_actionPerformed(ActionEvent e) { try { tpdv.fimDeVenda(); } catch(NaoHaVendaException ex) { JOptionPane.showMessageDialog(this, ex.getMessage()); return; } total.setText(String.valueOf(tpdv.getVenda().total())); } }
Atendimento ao clique do boto Faa Pagamento
2 linhas de interesse e 9 linhas de verificao e captura de erros
04/02/2012
Page 3 of 3
public class TpdvFrame extends JFrame { // ... void faaPagamento_actionPerformed(ActionEvent e) { if(valorEntregue.getText().equals("")) { JOptionPane.showMessageDialog(this, "Qual o valor entregue?"); return; } try { tpdv.faaPagamento((float)Double.parseDouble(valorEntregue.getText())); } catch(PagamentoInsuficienteException ex) { JOptionPane.showMessageDialog(this, ex.getMessage()); return; } troco.setText(String.valueOf(tpdv.getVenda().getTroco())); } }
impl-4 programa anterior
04/02/2012
6. Fase de Anlise 2
Page 1 of 1
6. Fase de Anlise 2

Escolha de requisitos da segunda iterao Relacionando mltiplos use cases Extenso do modelo conceitual Generalizao Organizando o modelo conceitual com packages Refinamento do modelo conceitual Modelo conceitual no estudo de caso Comportamento do sistema: Diagramas de sequncia e contratos na Segunda Iterao Comportamento do sistema: Diagramas de estado
anal2 programa
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\anal2\index.htm
04/02/2012
Escolha de Requisitos da Segunda Iterao
Page 1 of 1
Escolha de Requisitos da Segunda Iterao
Escolheremos o que fazer na segunda iterao visando apresentar novos conceitos na disciplina
No mundo real, os requisitos da segunda iterao poderiam ser diferentes
Manteremos os mesmos Use Cases da primeira iterao, mas o Use Case de Compra de Itens incluir pagamentos em dinheiro, com cheque e com carto de crdito Temos a seguinte funcionalidade adicional

Pagamento pode ser em dinheiro, com cheque e com carto de crdito Apenas um pagamento feito e de um tipo nico Pagamentos em cheque e com CC devem ser autorizados Um servio diferente de autorizao de crdito usado para cada carto de crdito (Visa, Mastercard, ...) Um nico servio de autorizao de cheques usado para todos os cheques O terminal PDV responsvel pela comunicao com o servio de autorizao de crdito
O leitor de CC apenas l o nmero do CC e o disponibiliza para o terminal PDV Deve-se discar um nmero de telefone a cada venda
A comunicao com um servio externo feito com um modem
anal2-1 programa prxima
04/02/2012
Organizando o Modelo Conceitual com Packages
Page 1 of 3
Introduo
Quando o modelo conceitual fica grande demais, pode ser quebrado em modelos menores J falamos de camadas e parties em outro contexto (Projeto arquitetural), mas a situao se aplica tambm no modelo conceitual
Packages em UML
Para referencia um conceito de um outro package, usa-se a notao NomeDoPackage::NomeDoConceito
Pode-se incluir dependncias entre packages
Organizando um modelo conceitual em packages
Regras para juntar elementos num mesmo package:
Os elementos partencem mesma rea conceitual

04/02/2012

Page 2 of 3
Os elementos participam de uma mesma hierarquia de tipos Os elementos participam dos mesmos Use Cases Os elementos Esto fortemente associados
Packages no estudo de caso
Os packages mostrados abaixo so:

Conceitos De Domnio Elementos Bsicos Vendas Produtos Pagamentos Transaes De Autorizao
04/02/2012
Page 3 of 3
04/02/2012
Relacionando Mltiplos Use Cases
Page 1 of 3
Introduo
UML tem uma notao especial para Use Cases em dois casos:

Use Cases grandes podem ser quebrados em vrios Use Cases menores mas relacionados A duplicao de certos passos de Use Cases diferentes pode se fatorada em um Use Case separado Pagar com dinheiro Pagar com carto de crdito (CC) Pagar com cheque
Veremos como fazer isso para os Use Cases seguintes do estudo de caso:

Relacionamentos "Uses" em UML
Se um Use Case inicia outro Use Case (isto , inclui o comportamento de outro Use Case), o relacionamento entre os dois do tipo "Uses" Exemplo: O Use Case Comprar Itens pode iniciar um dos Use Cases seguintes:

Pagar com dinheiro Pagar com carto de crdito (CC) Pagar com cheque
Ver o diagrama UML abaixo
Na descrio do Use Case, a palavra "initiate" (iniciar) usada para identificar que um Use Case usa outro
O Use Case Comprar Itens
Use case: Comprar itens Atores: Cliente (iniciador), Descrio: Um cliente chega ao caixa O caixa registra os itens No fim, o cliente sai com
Caixa com itens a comprar. comprados e recebe pagamento. os itens comprados.
Sequncia tpica de eventos

Ao do ator Resposta do sistema
1.
O Use Case inicia quando um cliente chega a um caixa munido de TPDV com itens a comprar
2.
O caixa registra a identificao de cada item
3.
Determina o preo do item e adiciona a informao ao total da transao de venda
04/02/2012

Se houver mais itens, o caixa pode informar a quantidade tambm 4. 6. 7. Ao completar a entrada dos itens, o caixa indica este fato ao TPDV O caixa informa o total da venda ao cliente O cliente escolhe o mtodo de pagamento: a. Se for dinheiro, iniciar Pagar Com Dinheiro b. Se for CC, iniciar Pagar Com CC a. Se for cheque, iniciar Pagar Com Cheque 8. 9. 10. 11. O caixa entrega o recibo impresso ao cliente O cliente sai da loja com os itens comprados Faz log da venda completada Gera um recibo impresso 5. A descrio e preo do item corrente so exibidos Calcula e apresenta o total da venda
Page 2 of 3
Sequncias Alternativas: Seo 2: Identificador invlido de item informado: Exibit erro. Seo 7: Cliente no pode pagar: Cancelar transao de venda Use Usa Usa Usa Cases Pagar Pagar Pagar Relacionados: com dinheiro com CC com Cheque
O Use Case Pagar com Dinheiro
Use case: Pagar com Dinheiro Atores: Cliente (iniciador), Caixa Descrio: Um cliente paga uma venda com dinheiro num terminal ponto-de-venda Sequncia tpica de eventos
Ao do ator
Resposta do sistema
1.
O Use Case inicia quando um cliente decide pagar uma venda com dinheiro, aps descobrir o valor total da venda
2.
O cliente entrega o pagamento em dinheiro (o "valor entregue", possivelmente maior que o total da venda
3.
O Caixa registra o valor entregue
4.
Exibe o troco devido ao Cliente
5.
O Caixa deposita o dinheiro recebido e devolve o troco devido
Sequncias Alternativas: Seo 2: O Cliente no tem dinheiro suficiente. Pode cancelar a venda ou iniciar um novo mtodo de pagamento Seo 3: A gaveta no tem dinheiro para pagar o troco. Caixa pede dinheiro ao supervisor ou pede ao Cliente para escolher outro mtodo de pagamento
O Use Case Pagar com Carto de Crdito
Use case: Pagar com Carto de Crdito Atores: Cliente (iniciador), Caixa, Servio de Autorizao de Crdito, Contas A Receber Descrio: Um cliente paga uma venda com carto de crdito num terminal ponto-de-venda. O pagamento validado num servio externo de autorizao de crdito e lanado num sistema de contas a receber.
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\anal2\anal2.htm 04/02/2012
Page 3 of 3
Sequncia tpica de eventos
Ao do ator
Resposta do sistema
1.
O Use Case inicia quando um cliente decide pagar uma venda com CC, aps descobrir o valor total da venda
2.
O cliente entrega a informao de crdito para o pagamento
3.
Gera um pedido de pagamento com CC e o envia a um Servio de Autorizao de Crdito
4.
O Servio de Autorizao de Crdito autoriza o pagamento
5.
Recebe uma aprovao de crdito do Servio de Autorizao de Crdito
6.
Lana o pagamento com crdito e informao de autorizao no sistema de Contas a Receber
7.
Exibe uma messagem de sucesso de autorizao
Sequncias Alternativas: Seo 4: A autorizao negada pelo Servio de Autorizao de Crdito. O Caixa sugere um outro mtodo de pagamento.
O Use Case Pagar com Cheque
Use case: Pagar com Cheque Atores: Cliente (iniciador), Caixa, Servio de Autorizao de Cheque Descrio: Um cliente paga uma venda com cheque num terminal ponto-de-venda. O pagamento validado num servio externo de autorizao de cheque. Sequncia tpica de eventos
Ao do ator
Resposta do sistema
1.
O Use Case inicia quando um cliente decide pagar uma venda com cheque, aps descobrir o valor total da venda
2.
O cliente escreve o cheque e se identifica
3.
O Caixa registra a informao de identificao e pede a autorizao de pagamento com cheque
4.
Gera um pedido de pagamento com cheque e o envia a um Servio de Autorizao de Cheque
5.
O Servio de Autorizao de Cheque autoriza o pagamento
6.
Recebe uma aprovao de crdito do Servio de Autorizao de Cheque
7.
Exibe uma messagem de sucesso de autorizao
Sequncias Alternativas: Seo 5: A autorizao negada pelo Servio de Autorizao de Cheque. O Caixa sugere um outro mtodo de pagamento.
04/02/2012
Extenso do Modelo Conceitual
Page 1 of 2
Novos conceitos no estudo de caso
Examinando a lista de categorias de conceitos, preenchemos a tabela abaixo

Categoria de Conceito Exemplos Carto de crdito, Cheque
Objetos fsicos ou tangveis Especificaes, projetos ou descries de coisas Lugares Transaes (um momento notvel) Detalhes de transao (Line item) Papeis de pessoas Colees de outras coisas (containers) Coisas dentro das colees Outros sistemas externos a nosso sistema Conceitos abstratos Organizaes Eventos Processos (frequentemente no representado como conceito, mas pode ocorrer) Regras e polticas Catlogos
PagamentoComDinheiro, PagamentoComCC, PagamentoComCheque,
SistemaAutorizaoCC, SistemaAutorizaoCheque
SistemaAutorizaoCC, SistemaAutorizaoCheque
04/02/2012
Page 2 of 2
Registros de assuntos financeiros, de trabalho, de contratos, legais Instrumentos e servios financeiros Manuais, livros
ContasAReceber
Pode-se tambm identificar conceitos novos atravs dos substantivos nos Use Cases
Identificamos assim:

PedidoAutorizaoCC RespostaAutorizaoCC PedidoAutorizaoCheque RespostaAutorizaoCheque
Modelo conceitual inicial resultante
04/02/2012
Refinando o Modelo Conceitual
Page 1 of 3
Introduo
Apresentam-se idias adicionais associadas modelagem conceitual
Tipos Associativos
Quando uma Loja usa um Servio de Autorizao, a comunicao envolve uma Identificao de Lojista Onde seria armazenado o atributo?

No pode ficar na Loja, pois a identificao diferente para cada Servio No pode ficar no Servio, pois a identificao diferente para cada Loja (Lojista)
Podemos modelar isso com um tipo associativo (ou Tipo de Associao)
Regras: quando usar um tipo associativo?

Um atributo est relacionado com uma associao Instncias do tipo associativo tm tempo de vida dependentes da associao H uma associao muitos-para-muitos entre dois conceitos e h informao associada associao em si H uma nica instncia do tipo associativo para uma associao envolvendo dois conceitos
Exemplo fcil para os alunos: Modele o domnio de problema envolvendo Aluno,

04/02/2012
Page 2 of 3
DescrioDeDisciplina, DisciplinaCursada, etc. Onde vai o conceito recebido numa disciplina cursada?
Agregao e composio
A agregao uma associao que modela um relacionamento todo-parte

O "todo" chamado composite As partes no tm nome padronizado (parte, componente, elemento, ...)
Exemplo: todo = mo, partes = dedos Agregao na UML
Agregao composta

A cardinalidade do lado composite 1 O losango cheio (preto) Significa que o composite possui as partes sozinho, sem compartilhamento A cardinalidade do lado composite pode ser maior que 1 Significa que uma parte pode estar em mais de um composite Exemplo no domnio de desenho grfico
Agregao compartilhada

Regras para identificar agregao

O tempo de vida das partes est incluso no tempo de vida do composite Tem uma relao bvia de todo-parte ou montagem lgica Algumas propriedades do composite se propagam para as partes
Exemplo: localizao Exemplos: movimento, destruio, ...
Operaes aplicadas ao composite propagam paraa as partes
Usa ou no usar agregao nos diagramas

No muito importante e pode ser excludo ao construir um modelo conceitual As vantagens so mais importantes durante a fase de projeto Durante o projeto, a agregao

Identifica mais claramente dependncias de tempo de vida Ajuda a identificar o criador das partes (padro Creator) Alerta para a possvel propagao de operaes
Exemplo: clone, ou Deep Copy
Agregao no estudo de caso
04/02/2012
Page 3 of 3
Nomes de papeis na associaes
O uso de nomes de papeis, de cada lado de uma associao possvel mas no obrigatrio
Associaes qualificadas
Numa associao, um qualificador ajuda a determinar um ou mais objetos do lado destino de uma associao Exemplo: UPC usado (conceitualmente) para identificar Especificaes de Produtos dentro de um Catlogo de Produtos
Observe que a cardinalidade foi afetada
Cuidado! J que estamos na anlise, uma associao qualificada apenas pode ajudar a entender o modelo melhor
Nada significa sobre a escolha de chaves de recuperao no projeto
04/02/2012
Page 1 of 5
Generalizao
Generalizao
Os conceitos PagamentoDinheiro, PagamentoCC e PagamentoCheque so semelhantes de podem ser organizados num hierarquia de tipos chamada GeneralizaoEspecializao Temos um supertipo (Pagamento) que representa um conceito mais genrico e subtipos mais especializados
A generalizao til pois:

Permite identificar conceitos em termos mais gerais e abstratos Permite evitar a repetio de informao No momento de implementar, a herana ser usada e ela permite polimorfismo, o que leva a cdigo mais extensvel
Duas formas de representar generalizao em UML
Definio de Supertipos e Subtipos

Uma definio de supertipo mais geral do que uma definio de subtipo Exemplo:
04/02/2012
Page 2 of 5
Um Pagamento (genrico) envolve um valor transferido entre partes Um PagamentoCC um Pagamento que deve ser autorizado Portanto, Pagamento mais geral e PagamentoCC mais especfico Todos os membros de um conjunto de subtipo pertence ao conjunto do supertipo
Em termos de teoria dos conjuntos:
Duas regras teis para verificar se subtipos so de fato subtipos de um supertipo
Regra 100%: 100% da definio do supertipo deve ser aplicveis ao subtipo, incluindo atributos e associaes
Exemplo: Os subtipos de Pagamento devem:

Ter um atributo "valor" Ter uma associao com Venda (Pagamento Paga-uma Venda)
Isso verdade para os subtipos acima
Regra -um: Todos os membros de um conjunto de subtipo pertence ao conjunto do supertipo
Em linguagem natural, pode-se dizer Subtipo -um Supertipo
Quando definir um subtipo
O particionamento nem sempre til
Exemplo: Supertipo Cliente e subtipos ClienteMasculino e ClienteFeminino pode no ser til O subtipo tem atributos adicionais O subtipo tem associaes adicionais O conceito subtipo manipulado, recebe operaes, reage, ou leva a reaes diferentemente do supertipo ou outros subtipos O conceito subtipo representa uma coisa animada (animal, rob, ...) que se comporta de forma diferente comparado ao subtipo ou outros subtipos
Para criar um subtipo, uma das 4 regras abaixo deve se aplicar:

Pelas regras, os subtipos ClienteMasculino e ClienteFeminino no parecem teis (mas podem ser em algumas aplicaes estranhas) Exemplos concretos seguem:
Motivao para ter um subtipo Pagamentos - no aplicvel Exemplos
O subtipo tem atributos adicionais Biblioteca - Livro, subtipo de RecursoEmprestvel tem um ISBN Pagamentos - PagamentoCC, subtipo de Pagamento, est associado a um CC O subtipo tem associaes adicionais Biblioteca - Vdeo, subtipo de RecursoEmprestvel, est associado a um Diretor O conceito subtipo manipulado, recebe operaes, reage, ou leva a reaes diferentemente do supertipo ou outros subtipos Pagamentos - PagamentoCC, subtipo de Pagamento, manipulado de forma diferente no que diz respeito a autorizao Biblioteca - Software, subtipo de RecursoEmprestvel, requer um depsito antes de ser emprestado Pagamentos - no aplicvel O conceito subtipo representa uma coisa animada (animal, rob, ...) Biblioteca - no aplicvel
04/02/2012

que se comporta de forma diferente comparado ao subtipo ou outros subtipos
Page 3 of 5
Pesquisa de mercado - PessoaMasculina, subtipo de Pessoa, tem um comportamento diferente de PessoaFeminina com respeito a hbitos de compras
Quando definir um supertipo
A generalizao de tipos existentes motivada pela identificao de fatores comuns entre subtipos potenciais Algumas regras:

Os subtipos potenciais representam variaes de um conceito similar Os subtipos obedecero as regras 100% e -um Todos os subtipos possuem um determinado atributo que pode ser fatorado e colocado no supertipo Todos os subtipos possuem uma determinada associao que pode ser fatorada e colocada no supertipo
Estudo de caso: Terminal ponto-de-venda

Tipos de Pagamentos
Ver a motivao da criao da hierarquia na figura abaixo
Tipos de Servios de Autorizao
Ver a motivao da criao da hierarquia na figura abaixo
04/02/2012
Page 4 of 5
Tipos de Transaes de Autorizao
Transaes com o mundo externo devem ser mostradas no modelo conceitual porque os processos utilizam esses conceitos Vrios tipos de hierarquias podem ser montadas usando esses conceitos Usar uma hierarquia muito profunda pode ser complexo demais Optamos pela estrutura abaixo que exibe as relaes enquanto mantm uma certa simplicidade
Tipos abstratos
Se um conceito no pode existir como instncia concreta, estamos definindo um tipo abstrato Exemplo: um Pagamento no pode existir, sem que seja um dos subtipos Em UML, um tipo abstrato recebe um nome em itlico
Na implementao, um tipo abstrato pode ser implementado como classe abstrata ou como interface (em Java, por exemplo)
Mutao de tipos

No modele mudanas de estado de objetos como mudanas de tipos (mutaes) Exemplo: um Pagamento pode ser no autorizado (no incio) e passar a ser autorizado
No modele isso como mudana de um tipo PagamentoNoAutorizado para outro tipo PagamentoAutorizado
Falaremos mais sobre mutaes quando elaborarmos sobre herana num captulo futuro
Generalizao e herana
No falamos de herana aqui porque estamos no mundo conceitual e no estamos falando de classes de software Em linguagens OO, uma subclasse de uma superclasse herda atributos e mtodos
A herana portanto uma forma de implementar a regra 100%

04/02/2012
Page 5 of 5
Ao passar para a fase de projeto, poderemos ou no usar herana para as hierarquias de tipo
Exemplo, em C++, poderamos usar uma nica classe com templates em vez de uma hierarquia de classes
04/02/2012
Modelo Conceitual no Estudo de Caso
Page 1 of 3
O Package Conceitos De Domnio
O Package Elementos Bsicos
O Package Pagamentos
04/02/2012
Page 2 of 3
O Package Produtos
O Package Vendas
04/02/2012
Page 3 of 3
O Package Transaes De Autorizao
04/02/2012
Comportamento do Sistema: Diagramas de Sequncia e Contratos na Segunda Iterao
Page 1 of 2
Diagramas de Sequncia do Sistema
Para esta iterao, os diagramas de sequncia do sistema devem representar o processo de escolher e tratar o mtodo de pagamento
O incio comum para o Use Case Comprar Itens
O incio no depende do mtodo de pagamento
Pagamento com carto de crdito
Aps o incio comum, a seguinte sequncia usada:
04/02/2012
Page 2 of 2
Pagamento com cheque
Aps o incio comum, a seguinte sequncia usada:
Contratos
Os contratos podem ser elaborados para cada evento do sistema
Os detalhes podem ser vistos no livro texto (Larman)
04/02/2012
Comportamento do Sistema: Diagramas de Estado
Page 1 of 1
Comportamento do Sistema: Diagramas de Estado
Eventos, estados e transies
Um evento uma "ocorrncia interessante"
Exemplo: os eventos do sistema discutidos anteriormente (entraItem, ...) Exemplo: no estudo de caso, o sistema est no estado "Entrando itens" enquanto itens esto sendo informados
Um estado a condio de um objeto entre dois eventos
Diagramas de estado
Diagramas de estado podem ser usados para Use Cases complexos
Quando a ordem legal de eventos do sistema no bvia
No Use Case complexo no estudo de caso, mas podemos mostrar um diagrama de estado nesse contexto (Use Case Comprar Itens)
anal2-9 programa anterior
04/02/2012
Page 1 of 1

Padres adicionais para atribuir responsabilidades Interfaces Composio versus herana Padres de Projeto (Design Patterns)

O que so Design Patterns? Elementos essenciais de um Design Pattern Design Pattern: Factory Method Design Pattern: Iterator Design Pattern: Composite Design Pattern: Strategy Design Pattern: Decorator Design Pattern: Template Method Design Pattern: Observer
proj2 programa
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\proj2\index.htm
04/02/2012
Padres Adicionais para Atribuir Responsablidades
Page 1 of 1
Polimorfismo
O padro de projeto Polimorfismo
Problema
Como tratar alternativas baseadas no tipo de objeto?
Se usar if-then-else ou switch-case, temos que mudar o cdigo sempre que uma nova alternativa surge
A modificao tem que ser feita em todo lugar onde a alternativa deve ser tratada O resultado um cdigo pouco extensvel
Como criar componentes plugveis?

Como trocar um componente por outro sem afetar os clientes do componente? H uma discusso mais detalhada de componentes em outro captulo
Soluo

Usar operaes polimrficas ao comportamento que varia entre os tipos Resultado: no se testa o tipo do objeto, chama-se a operao polimrfica, simplesmente
Exemplo
No estudo de caso, quem deveria ser responsvel pela autorizao de diferentes tipos de pagamentos? Como a forma de obter autorizao depende do tipo de pagamento (dinheiro, CC ou cheque), podemos usar uma operao polimrfica autorize()
A implementao da operao ser diferente em cada subtipo
Discusso

A idia semelhante ao padro Expert ("eu mesmo fao") Polimorfismo um dos padres mais importantes no projeto de software Extenses so simples
Exemplo: como adicionar um mtodo de pagamento com dbito direto em conta corrente?
Consequncias
Adies futuras e no antecipadas tm pouco efeito no cdigo existente
04/02/2012
Interfaces
Page 1 of 3
Interfaces
Herana de classe versus herana de interface
H uma diferena grande entre uma classe e seu tipo

A classe define uma implementao O tipo define apenas a interface oferecida para acessar objetos da classe Um objeto pode ter muitos tipos Classes diferentes podem ter o mesmo tipo A sub-classe herda a implementao da super-classe um mecanismo para compartilhar cdigo e representao
Herana de classe significa herana de implementao

Herana de interface (ou sub-tipos) descreve quando um objeto pode ser usado em vez de outro Ao fazer herana de classe, automaticamente faz tambm herana de interface Algumas linguagens no permitem definir tipos separadamente de classes
Mas, neste caso, a classe puramente abstrata serve
"Program to an interface, not an implementation"
O fato de que a herana de implementao permite facilmente reusar a funcionalidade de uma classe interessante mas no o aspecto mais importante a ser considerado Herana oferece a habilidade de definir famlias de objetos com interfaces idnticas Isso extremamente importante pois permite desacoplar um objeto de seus clientes atravs do polimorfismo A herana de interface corretamente usada (sem eliminar partes da interface nas sub-classes) acaba criando sub-tipos, permitindo o polimorfismo Programar em funo de uma interface e no em funo de uma implementao (uma classe particular) permite o polimorfismo e fornece as seguintes vantagens:
Clientes permanecem sem conhecimento do tipo de objetos que eles usam, desde que os objetos obedeam a interface Clientes permanecem sem conhecimento das classes que implementam tais objetos A flexibilidade vem da possibilidade de mudar a implementao da interface, at em tempo de execuo, j que o polimorfismo implementado com "late binding" feito em tempo de execuo Isso permite ter mais polimorfismo mesmo sem que as classes pertenam a uma mesma hierarquia
A interface o que h de comum
Em java, uma classe pode implementar vrias interfaces
Exemplo no uso de interfaces
Temos vrios tipos de composites (colees) que no pertencem a uma mesma hierarquia

ColeoDeAlunos ColeoDeProfessores ColeoDeDisciplinas Digamos um selecionador de objetos usado numa interface grfica para abrir uma list box para selecionar objetos com um determinado nome Exemplo:

Temos um cliente comum dessas colees
Quero listar todos os alunos com nome "Joo" e exib-los numa list box para escolha pelo usurio Idem para listar professores com nome "Alfredo" Idem para listar disciplinas com nome "Programao"
Queremos fazer um nico cliente para qualquer uma das colees O exemplo abaixo tem polimorfismo em dois lugares
interface SelecionvelPorNome { Iterator getIteradorPorNome(String nome); } interface Nomevel { String getNome(); } classe ColeoDeAlunos implements SelecionvelPorNome { // ... Iterator getIteradorPorNome(String nome) { // ... } } classe Aluno implements Nomevel { // ...
Interfaces
Page 2 of 3
String getNome() { ... } } classe ColeoDeProfessores implements SelecionvelPorNome { // ... Iterator getIteradorPorNome(String nome) { // ... } } classe Professor implements Nomevel { // ... String getNome() { ... } } classe ColeoDeDisciplinas implements SelecionvelPorNome { // ... Iterator getIteradorPorNome(String nome) { // ... } } classe Disciplina implements Nomevel { // ... String getNome() { ... } } classe ComponenteDeSeleo { Iterator it; // observe o tipo do parmetro (uma interface) public ComponenteDeSeleo(SelecionvelPorNome coleo, String nome) { it = coleo.getIteradorPorNome(nome); // chamada polimrfica } // ... void geraListBox() { response.out.println("<select name=\"nome\" size=\"1\">"); while(it.hasNext()) { int i = 1; // observe o tipo do objeto Nomevel obj = (Nomevel)it.next(); response.out.println("<option value=\"escolha" + i + "\">" + obj.getNome() + // chamada polimrfica "</option>"); } response.out.println("</select>"); } } // Como usar o cdigo acima num servlet: // supe que as colees usam o padro Singleton ComponenteDeSeleo cds = new ComponenteDeSeleo(ColeoDeAlunos.getInstance(), "Joo"); cds.geraListBox(); cds = new ComponenteDeSeleo(ColeoDeDisciplinas.getInstance(), "Programao"); cds.geraListBox(); Como achar interfaces
Procure assinaturas repetidas
Exemplo: vrias classes que representam coisas que podem ser vendidas indicam o uso de uma interface VendvelIF
Onde h delegao, um objeto se esconde atrs de outro: deve haver uma interface comum Procure mtodos que poderiam ser usadas em aplicaes semelhantes e use interfaces para que a reusabilidade das classes clientes seja maior
Exemplo: muitas coisas poderiam ser reservveis, no s passagens de avio
04/02/2012
Interfaces

Page 3 of 3
Exemplo: muitas coisas pode ser alugadas, no s fitas de vdeo Exemplo: muitos objetos so clonveis
Procure mudanas futuras (novos objetos que poderiam aparecer) e coloque as semelhanas sob controle de interfaces H, entretanto, pessoas que no concordam em "pensar muito na frente"
Vide "Extreme Programming" adiante ...
04/02/2012
Composio versus Herana
Page 1 of 5

Composio e Herana

Composio e herana so dois mecanismos para reutilizar funcionalidade Alguns anos atrs (e na cabea de alguns programadores ainda!), a herana era considerada a ferramenta bsica de extenso e reutilizao de funcionalidade A composio estende uma classe pela delegao de trabalho para outro objeto a herana estende atributos e mtodos de uma classe Hoje, considera-se que a composio muito superior herana na maioria dos casos
A herana deve ser utilizada em alguns (relativamente poucos) contextos
Um exemplo de composio
Use composio para estender as responsabilidades pela delegao de trabalho a outros objetos Um exemplo no domnio de endereos

Uma empresa tem um endereo (digamos s um) Uma empresa "tem" um endereo Podemos deixar o objeto empresa responsvel pelo objeto endereo e temos agregao composta (composio)
Um exemplo de herana
Atributos, conexes a objetos e mtodos comuns vo na superclasse (classe de generalizao) Adicionamos mais dessas coisas nas subclasses (classes de especializao) Trs situaes comuns para a herana (figura abaixo)
Uma transao um momento notvel ou intervalo de tempo
Exemplo no domnio de reserva e compra de passagens de avio
04/02/2012
Page 2 of 5
Benefcios da herana

Captura o que comum e o isola daquilo que diferente A herana vista diretamente no cdigo
Problemas da herana
O encapsulamento entre classes e subclasses fraco (acoplamento forte)

Mudar uma superclasse pode afetar todas as subclasses Isso viola um dos princpios bsicos de projeto O-O (fraco acoplamento) Com herana, a estrutura est parafusada no cdigo e no pode sofrer alteraes facilmente em tempo de execuo A herana um relacionamento esttico que no muda com tempo Cenrio: pessoas envolvidas na aviao (fugira abaixo)
s vezes um objeto precisa ser de uma classe diferente em momentos diferentes
04/02/2012
Page 3 of 5
Problema: uma pessoa pode mudar de papel a assumir combinaes de papeis Fazer papeis mltiplos requer 7 combinaes (subclasses)
Solucionando o problema com composio: uma pessoa e vrios papeis possveis
Observe que tambm podemos inverter a composio (uma pessoa tem um ou mais papeis)
Pense na implicao par a interface de "pessoa"
Aqui, estamos usando delegao: dois objetos esto envolvidos em atender um pedido (digamos setNome)
O objeto tripulao (digamos) delega setNome para o objeto pessoa que ele tem por composio Tcnica tambm chamada de forwarding semelhante a uma subclasse delegar uma operao para a superclasse (herdando a operao)
Delegao sempre pode ser usada para substituir a herana
Se usssemos herana, o objeto tripulao poderia referenciar a pessoa com this Com o uso de delegao, tripulao pode passar this para pessoa e o objeto pessoa pode referenciar o objeto original se quiser Em vez de tripulao ser uma pessoa, ele tem uma pessoa A grande vantagem da delegao que o comportamento pode ser escolhido em tempo de execuo e vez de estar amarrado em tempo de compilao A grande desvantagem que um software muito dinmico e parametrizado mais difcil de entender do que software mais esttico
O resultado de usar composio
Em vez de codificar um comportamento estaticamente, definimos pequenos comportamentos padro e usamos composio para definir comportamentos mais complexos
5 regras para o uso de herana (Coad)

Page 4 of 5
O objeto " um tipo especial de" e no "um papel assumido por" O objeto nunca tem que mudar para outra classe A subclasse estende a superclasse mas no faz override ou anulao de variveis e/ou mtodos No uma subclasse de uma classe "utilitria"
No uma boa idia fazer isso porque herdar de, digamos, HashMap deixa a classe vulnervel a mudanas futuras classe HashMap O objeto original no "" uma HashMap (mas pode us-la) No uma boa idia porque enfraquece a encapsulao
Clientes podero supor que a classe uma subclasse da classe utilitria e no funcionaro se a classe eventualmente mudar sua superclasse Exemplo: x usa y que subclasse de vector

x usa y sabendo que um Vector Amanh, y acaba sendo mudada para ser subclasse de HashMap x se lasca!
Para classes do domnio do problema, a subclasse expressa tipos especiais de papeis, transaes ou dispositivos
Exemplo da aplicao das regras
Considere Agente, Tripulao e Passageiro como subclasses de Pessoa
Regra 1 (tipo especial): no passa. Um Passageiro no um tipo especial de Pessoa: um papel assumido por uma Pessoa Regra 2 (mutao): no passa. Um Agente pode se transformar em Passageiro com tempo Regra 3 (s estende): ok. Regra 4: ok. Regra 5: no passa. Passageiro est sendo modelado como tipo especial de Pessoa e no como tipo especial de papel
Outro exemplo: transaes
Reserva e Compra podem herdar de Transao?
Regra 1 (tipo especial): ok. Uma Reserva um tipo especial de Transao e no um papel assumido por uma Transao
04/02/2012
Page 5 of 5
Regra 2 (mutao): ok. Uma reserva sempre ser uma Reserva, e nunca se transforma em Compra (se houver uma compra da passagem, ser outra transao). Idem para Compra: sempre ser uma Compra Regra 3 (s estende): ok. Ambas as subclasses estendem Transao com novas variveis e mtodos e no fazem override ou anulam coisas de Transao Regra 4 (no estende classe utilitria): ok. Regra 5 (tipo especial de papel/transao/dispositivo): ok. So tipos especiais de Transao
proj2-3 programa
04/02/2012
O que so Design Patterns?
Page 1 of 1
Design Patterns O que so Design Patterns?
Uma definio informal:
"Cada padro descreve um problema que ocorre frequentemente e ento descreve o cerne da soluo ao problema de forma a poder reusar a soluo milhes de vezes em situaes diferentes" Reuso de idias, no cdigo Consistem de micro-arquiteturas de classes, objetos, seus papeis e suas colaboraes
Observe que o que reutilizado so as classes e suas colaboraes

Contm o somatrio da experincia dos melhores projetistas O-O! Esto revolucionando o projeto de software desde 1995 quando o famoso livro da "Gang of Four" (GoF) apareceu com o primeiro catlogo de 23 padres

Ver bibliografia Tem muito mais padres aparecendo sempre OOPSLA uma grande fonte de padres
Ficar mais claro com alguns exemplos Design Patterns iniciaram a febre de padres

Analysis Patterns Testing Patterns Business Patterns Pedagogical Patterns e mais ...
H um meta-padro envolvido: Entre vrias situaes, isolar o que muda do que igual. Uma sinopse dos Design Patterns da GoF est aqui.
pat-1 programa prxima
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\oque.htm
04/02/2012
Page 1 of 1

Um Nome
Descreve o problema de projeto, suas solues e consequncias em poucas palavras Permite projetar num nvel mais alto de abstrao Permite falar com outros sobre solues e documentar cdigo, j que os nomes de padres esto ficando padronizados

"Todo mundo" conhece os 23 padres da GoF equivalente a padronizar "lista encadeada", "pilha", etc. no mundo das estruturas de dados
O Problema

Descreve quando aplicar o padro Descreve o problema e o contexto Pode descrever problemas especficos de projeto
Exemplo: como representar algoritmos como objetos?
Pode descrever estruturas de objetos ou de classes que so sintomas de um projeto inflexvel s vezes, o padro lista condies que devem se aplicar para usar o padro
A Soluo
Descreve os elementos constituintes do projeto, seus relacionamentos, responsabilidades e colaboraes A soluo no descreve um projeto ou implementao concretos porque um padro um gabarito de soluo para vrias situaes
As Consequncias

Os resultados e trade-offs da aplicao do padro Diz respeito a trade-offs de espao, tempo, flexibilidade, extensibilidade, portabilidade
pat-2 programa anterior prxima
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\elem.htm
04/02/2012
Factory Method
Page 1 of 10
Factory Method
Introduo aos Padres de Criao: Construindo Labirintos

GoF classifica os padres em Padres de Criao, Estruturais e de Comportamento Padres de criao abstraem o processo de instanciao de objetos Usaremos a construo de labirintos para um jogo via computador para mostrar alguns padres de criao
Ignoraremos muitos detalhes do labirinto (o que pode estar no labirinto, os jogadores, etc.) Foco na criao dos labirintos Uma sala conhece seus quatro vizinhos Vizinhos podem ser outra sala, uma parede ou uma porta para outra sala S trataremos as partes das classes que interessam para a criao do labirinto Se precisar de um resumo de UML, ver aqui
Um labirinto um conjunto de salas

As classes importantes so Sala, Porta e Parede
O diagrama de classes segue abaixo (em UML)
Um diagrama de objetos segue para um pequeno labirinto
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\factory.htm
04/02/2012
Factory Method
Page 2 of 10
Cada sala tem quatro vizinhos
Usamos norte, sul, leste, oeste para referenci-los
A interface ElementoDeLabirinto implementada por todos os componentes de um labirinto
Tem um mtodo entra() cujo significado depende onde se est entrando

Se for uma sala, a localizao do jogador muda Se for uma porta aberta, voc vai para outra sala, caso contrrio se machuca Se for uma parede, voc se machuca
public interface ElementoDeLabirinto { public void entra(); }
Exemplo: se voc estiver numa sala e quiser implementar a operao "v para o leste", o jogo determina qual ElementoDeLabirinto est do lado leste e chama entra () deste objeto

O mtodo entra() da subclasse especfica determina o que ocorre Num jogo real, entra() poderia aceitar o objeto jogador como parmetro
Sala a classe que implementa ElementoDeLabirinto e define as relaes-chave entre objetos

Mantm referncias para 4 outros ElementoDeLabirinto Armazena um nmero de sala para indentificar as salas do labirinto
class Sala implements ElementoDeLabirinto { private ElementoDeLabirinto[] vizinhos =

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\factory.htm 04/02/2012
Factory Method
Page 3 of 10
new ElementoDeLabirinto[4]; private int nmeroDaSala; public Sala(int nmeroDaSala) { ... } public void entra() { ... } public ElementoDeLabirinto getVizinho(int direo) { ... } public void setVizinho(int direo, ElementoDeLabirinto vizinho) { ... } } class Parede implements ElementoDeLabirinto { public Parede() { ... } public void entra() { ... } } class Porta implements ElementoDeLabirinto { private Sala sala1, sala2; private boolean estAberta; public Porta(ElementoDeLabirinto sala1, ElementoDeLabirinto sala2) { ... } public void entra() { ... } public Sala salaDoOutroLado(Sala sala) { ... } }
Tambm precisamos de uma classe Labirinto para representar uma coleo de salas
A classe Labirinto pode localizar uma sala dado seu nmero com o mtodo getSala()
class Labirinto { private Vector salas = new Vector(); public Labirinto() { ... } public void adicionaSala(Sala sala) { ... } public sala getSala(int nmeroDaSala) { ... } }
Tambm definimos uma classe Jogo que cria o labirinto
Uma forma simples de criar um labirinto de criar os componentes, adicionlos ao labirinto e interconect-los Exemplo da criao de um labirinto com 2 salas e uma porta entre elas
04/02/2012
Factory Method
Page 4 of 10
class Jogo { ... public Labirinto criaLabirinto() { Labirinto umLabirinto = new Labirinto(); Sala sala1 = new Sala(1); Sala sala2 = new Sala(2); Porta aporta = new Porta(sala1,sala2); umLabirinto.adicionaSala(sala1); umLabirinto.adicionaSala(sala2); sala1.setVizinho(norte, new Parede()); sala1.setVizinho(leste, aporta); sala1.setVizinho(sul, new Parede()); sala1.setVizinho(oeste, new Parede()); sala2.setVizinho(norte, new Parede()); sala2.setVizinho(leste, new Parede()); sala2.setVizinho(sul, new Parede()); sala2.setVizinho(oeste, aporta); return umLabirinto; } ... }
O problema desta soluo sua inflexibilidade

O mtodo criaLabirinto() no reutilizvel em outras situaes Motivo: criaLabirinto() mistura a questo da estrutura do labirinto com a questo dos tipos exatos de elementos que compem o labirinto
New cria um forte acoplamento entre a classe Jogo e as classes dos objetos criados porque implica num compromisso (amarrao) com uma determinada implementao
Veremos agora como mudar o projeto para criar diferentes tipos de labirintos
Labirintos encantados

Com portas travadas que precisam de um encantamento para abrir Salas contendo encantamentos que podem ser apanhados
04/02/2012
Factory Method
Page 5 of 10
Labirintos perigosos
Salas com bombas que podem ser explodidas para danificar as paredes (e talvez o jogador!)
Como mudar criaLabirinto() para facilmente criar estes novos tipos de labirintos?
O maior problema que a soluo atual nos fora a colocar em cdigo as classes concretas que sero instanciadas
Usaremos padres de criao para tornar o projeto mais flexvel (mais reusvel)
O padro Factory Method

Objetivo
Definir uma interface para criar objetos de forma a deixar subclasses decidirem qual classe instanciar Factory Method deixa que subclasses faam a instanciao
Construtor Virtual
Resumo
A idia simples: em vez de um cliente que precisa de um objeto chamar new e assim especificar a classe concreta que ele instancia, o cliente chama um mtodo abstrato (Factory Method) especificado em alguma classe abstrata (ou interface) e a subclasse concreta vai decidir que tipo exato de objeto criar e retornar
Mudar a subclasse concreta que cria o objeto permite mudar a classe do objeto criado sem que cliente saiba Permite estender a funcionalidade atravs da construo de subclasses sem afetar os clientes "Crie objetos numa operao separada de forma que subclasses possam fazer override da forma de criao"
Resumindo:
Quando usar o padro Factory Method?
Quando uma classe (o criador) no pode antecipar a classe dos objetos que deve criar Quando uma classe quer que suas subclasses especifiquem os objetos criados Quando classes delegam responsabilidade para uma entre vrias subclasses de apoio e queremos localizar num ponto nico a conhecimento de qual subclasse est sendo usada
Estrutura genrica
04/02/2012
Factory Method
Page 6 of 10
Participantes

Produto: define a interface dos objetos criados pelo Factory Method ProdutoConcreto: implementa a interface Produto Criador: declara o Factory Method que retorna um objeto do tipo Produto
s vezes, o Criador no apenas uma interface mas pode envolver uma classe concretaque tenha tem uma implementao default para o Factory Method para retornar um objeto com algum tipo ProdutoConcreto default Pode chamar o Factory Method para criar um produto do tipo Produto
CriadorConcreto: faz override do Factory Method para retornar uma instncia de ProdutoConcreto
Colaboraes
Criador depende de suas subclasses para definir o Factory Method para que ele retorne uma instncia do ProdutoConcreto apropriado
Consequncias do uso do padro Factory Method
Factory Methods eliminam a necessidade de colocar classes especficas da aplicao no cdigo

O cdigo s lida com a interface Produto O cdigo pode portanto funcionar com qualquer classe ProdutoConcreto Criar objetos dentro de uma classe com um Factory Method sempre mais flexvel do que criar objetos diretamente O Factory Method prov um gancho para que subclasses forneam uma verso estendida de um objeto Exemplo num editor de documentos
Prov ganchos para subclasses
Uma classe Documento poderia ter um Factory Method criaFileDialog para criar um objeto file dialog default para abrir um documento existente Uma subclasse de Documento poderia criar um file dialog especial atravs do override do Factory Method default Neste caso, o Factory Method no abstrato mas fornece um default razovel
Exerccio: como estruturar o cdigo de uma aplicao bancria para que voc no fique maluco quando seu gerente pedir que todas as novas contas de poupana criadas a partir de segunda-feira tenham algo novo implementado nelas mas sem afetar cdigo antigo que trata das contas antigas?
Consideraes de implementao
boa prtica usar uma conveno de nomes para alertar para o fato de que est
04/02/2012
Factory Method
Page 7 of 10
usando Factory Methods

Exemplo: makeAbc(), makeXyz() Exemplo: criaAbc(), criaXyz()
Exemplo de cdigo: criao de labirintos
A criao de labirintos j vista no ficou flexvel pois criamos (com new) os objetos especificando as classes concretas na funo criaLabirinto() Usaremos Factory Methods para deixar que subclasses escolham que objetos criar Usaremos o seguinte projeto

Produto: Sala, Parede, Porta ProdutoConcreto: Sala, SalaEncantada, SalaPerigosa, Parede, ParedeComBomba, Porta, PortaComChave Ccriador: Jogo

Seu mtodo criaLabirinto cria o labirinto chamando Factory Methods Ele tambm um CriadorConcreto pois oferece uma implementao default para os Factory Methods (para criar um labirinto simples)
CriadorConcreto: Jogo, JogoEncantado, JogoPerigoso que sero subclasses de jogo
Iniciamos com o criador Jogo que contm os Factory Methods
class Jogo { // Factory Methods com default public Labirinto criaLabirinto() { return new Labirinto(); } public Sala criaSala(int nmeroDaSala) { return new Sala(nmeroDaSala); } public Parede criaParede() { return new Parede(); } public Porta criaPorta(Sala sala1, Sala sala2) { return new Porta(sala1, sala2); } // Observe que essa funo no tem new: // ela usa Factory Methods // Esta a *nica* diferena com relao // verso original // Observe como o mtodo s trata da estrutura do labirinto // e no do tipo de elemento que o compe public Labirinto criaLabirinto() { Labirinto umLabirinto = criaLabirinto(); Sala sala1 = criaSala(1); Sala sala2 = criaSala(2); Porta aPorta = criaPorta(sala1, sala2); umLabirinto.adicionaSala(sala1); umLabirinto.adicionaSala(sala2); sala1.setVizinho(norte, criaParede()); sala1.setVizinho(leste, aporta); sala1.setVizinho(sul, criaParede()); sala1.setVizinho(oeste, criaParede()); sala2.setVizinho(norte, criaParede()); sala2.setVizinho(leste, criaParede()); sala2.setVizinho(sul, criaParede()); sala2.setVizinho(oeste, aporta); return umLabirinto; }
Factory Method
Page 8 of 10
Para criar um jogo perigoso, criamos uma subclasse de Jogo e redefinimos alguns Factory Methods
// um novo CriadorConcreto class JogoPerigoso extends Jogo { public Parede criaParede() { return new ParedeDestrutvel(); } public Sala criaSala(int nmeroDaSala) { return new SalaComBomba(nmeroDaSala); } }
Comparando o diagrama de objetos com a verso inicial, no h objeto adicional
S h uma mudana do objeto umJogo para um umJogoPerigoso
Para criar um jogo encantado, procedemos de forma anloga
// um novo CriadorConcreto class JogoEncantado extends Jogo { public sala criaSala(int nmeroDaSala) { return new salaEncantada(nmeroDaSala, jogaEncantamento()); } public Porta criaPorta(Sala sala1, Sala sala2) { return new portaPrecisandoDeEncantamento(sala1, sala2); } protected Encantamento jogaEncantamento() { ... }
Factory Method
Page 9 of 10
O acoplamento depois do Factory Method
Discusso geral de padres de criao
Ajudam a deixar o sistema independente de como seus objetos so criados, compostos e representados So dois tipos:
Padres de criao via classes

Usam herana para variar a classe que instanciada Exemplo: Factory Method Delegam a instanciao para outro objeto Exemplo: Abstract Factory
Padres de criao via objetos

Composio usada mais que herana para estender funcionalidade e padres de criao ajudam a lidar com a complexidade de criar comportamentos
Em vez de codificar um comportamento estaticamente, definimos pequenos comportamentos padro e usamos composio para definir comportamentos mais complexos Isso significa que instanciar um objeto com um comportamento particular requer mais do que simplesmente instanciar uma classe. Eles escondem como instncias das classes concretas so criadas e juntadas para gerar "comportamentos" (que podem envolver vrios objetos compostos) Os padres mostrados aqui mostram como encapsular as coisas de forma a simplificar o problema de instanciao.
Os padres de criao discutem temas recorrentes:
Eles encapsulam o conhecimento das classes concretas que so instanciadas
Lembre que preferimos nos "amarrar" a interfaces (via interface ou classes abstratas) do que a classes concretas Isso promove a flexibilidade de mudana (das classes concretas que so instanciadas)
04/02/2012
Factory Method
Page 10 of 10
Pergunta final para discusso
De que forma a Factory Method ajuda a produzir cdigo fracamente acoplado?
04/02/2012
Iterator
Page 1 of 4
Iterator
Objetivo
Prover uma forma de sequencialmente acessar os elementos de um objeto agragado sem expor sua representao interna
Cursor
Motivao
Queremos isolar o uso de uma estrutura de dados de sua representao interna de forma a poder mudar a estrutura sem afetar quem a usa Para determinadas estruturas, pode haver formas diferentes de caminhamento ("traversal") e queremos encapsular a forma exata de caminhamento
Exemplo: rvore pode ser varrida "em ordem", "em ps-ordem", em "prordem" Exemplo: podemos ter um "iterador com filtro" que s retorna certos elementos da coleo
Exemplo: num editor de documentos, poderamos ter os elementos do documento organizados em rvores (documento consiste de pginas qe consistem de pargrafos, ...) e ter um iterador especial para elementos no grficos (que podem ter sua grafia verificada, por exemplo)
A idia do iterador de retirar da coleo a responsabilidade de acessar e caminhar na estrutura e colocar a responsabilidade num novo objeto separado chamado um iterador A interface Iterador:
Define uma interface para acessar os elementos da coleo Implementa a interface Iterador Mantm qualquer informao de estado necessria para saber at onde a iterao (caminhamento) j foi No podemos usar new de uma classe concreta diretamente pois o iterador a ser criado depende da coleo a ser varrids Soluo: a coleo tem um factory method para criar um iterador
A classe Iterador

Como criar um iterador?
Exemplo em java: Vector.iterator()
Aplicabilidade: use o padro iterador

Para acessar o contedo de uma coleo sem expor suas representao interna Para suportar mltiplas formas de caminhamento Para prover uma interface nica para varrer estruturas agregadas diferentes
Isto , para suportar iterao polimrfica
Estrutura
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\iterator.htm
04/02/2012
Iterator
Page 2 of 4
Exemplo de uso: um impressor genrico em Java

class Printer { static void printAll(Iterator it) { while(it.hasNext()) { System.out.println(it.next().toString()); } } } class LabirintoDeRatos { public static void main(String[] args) { Vector ratos = new Vector(); for(int i = 0; i < 3; i++ ) { ratos.add(new Rato(i)); } // iterador criado aqui Printer.printAll(ratos.iterator()); } }
Participantes
Iterador (Enumeration no Java original)
Define a interface para acessar e caminhar nos elementos Implemementa a interface Iterator Mantm estado para saber o elemento corrente na coleo Define uma interface para criar um objeto iterador Implementa a interface de criao do iterador e retorna uma instncia do IteradorConcreto
IteradorConcreto (elements() no Java original, iterator() no Java recente)

Coleo (no tem isso no Java antigo; no Java recente, chama-se Collection)
ColeoConcreta (Vector, ArrayList, LinkedList, ... em Java)
Consequncias
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\iterator.htm 04/02/2012
Iterator
Page 3 of 4
A mera substituio de um iterador permite caminhar numa coleo de vrias formas Juntar a interface de caminhamento num iterador permite retirar esta interface da coleo, simplificando assim a interface desta coleo Vrias iteraes podem estar ocorrendo ao mesmo tempo, j que o estado de uma iterao mantido no iterador e no na coleo
Detalhes de implementao
Iteradores internos versus iteradores externos
Com iterador interno, o cliente passa uma operao a ser desempenhada pelo iterador e este o aplica a cada elemento Com iterador externo (mais flexveis), o cliente usa a interface do iterador para caminhar mas ele mesmo (o cliente) processa os elementos da coleo Um iterador interno s usado quando um iterador externo seria difcil de implementar
Exemplo: para colees complexas, manter o estado da iterao pode ser difcil (teria que armazenar o caminho inteiro dentro de uma coleo recursiva multi-nvel). Neste caso, usar um iterador interno recursivo e armazenar o estado na propria pilha de execuo pode ser mais simples.
Tratamento de concorrncia
O que ocorre se houver mudanas coleo (novos objetos ou objetos removidos) durante uma iterao (devido a um thread)? Um "iterador fail-fast" indica imediatamente que est havendo acesso concorrente (via exceo) Alguns iteradores podem clonar a coleo para caminhar, mas isto caro em geral Um "iterador robusto" permite fazer iteraes e mudar a coleo sem se perder Pode permitir ou no andar para trs, pular posies, etc. Um iterador nulo sempre diz que a iterao acabou Eexemplo: se todo objeto de um Composite (ver frente) tiver um iterador, uma folha poderia ter um iterador nulo
Operadores do iterador
Iteradores nulos so interessantes para prover condies limites

Exemplo de cdigo
O iterador do Vector em Java seria semelhante ao que segue abaixo
public Iterator iterator() { return new Iterator() { // classe interna annima int cursor = 0; public boolean hasNext() { return cursor < size(); } public Object next() { try { Object next = get(cursor); cursor++; return next; } catch(IndexOutOfBoundsException e) { throw new NoSuchElementException(); } } };
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\iterator.htm 04/02/2012
Iterator
Page 4 of 4
Considere uma coleo (objeto composto) que contenha objetos representando emprstimos. A interface do objeto Emprstimo contm um mtodo chamado ValorDoEmprstimo() que retorna o valor corrente do emprstimo. Dado um requisito para extrair todos os emprstimos da coleo com valor menor que um limite (ou maior que um limite ou entre dois limites), voc usaria ou escreveria um iterador para resolver o problema?
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\iterator.htm
04/02/2012
Composite
Page 1 of 11
Composite
Um problema a resolver: editor de documentos
Para introduzir este padro (e alguns outros), usaremos o exemplo do projeto de um editor de documentos WYSIWYG (What You See Is What You Get)

Semelhante a Word, por exemplo Outros exemplos do padro Composite no Swing de Java
O editor pode misturar texto e grficos usando vrias opes de formatao A redor da rea de edio esto os menus, scroll bars, barras de ferramentas, etc. O primeiro problema de design que queremos atacar como representar a estrutura do documento
Essa estrutura afeta o resto da aplicao j que a edio, formatao, anlise textual, etc. devero acessar a representao do documento Caracteres, linhas, polgonos e outras figuras
Um documento um arranjo de elementos grficos bsicos
O usurio normalmente no pensa em termos desses elementos grficos mas em termos de estruturas fsicas

Linhas, colunas, figuras, tabelas e outras sub-estruturas As sub-estruturas podem ser compostas de outras sub-estruturas, etc. No vamos considerar isso aqui mas a soluo que usaremos se aplica a esta situao tambm
O usurio tambm pode pensar na estrutura lgica (frase, pargrafos, sees, etc.)
A interface do usurio (UI) do editor deve permitir que o usurio manipule tais subestruturas diretamente
Por exemplo, o usurio pode tratar um diagrama como uma unidade em vez de uma coleo de elementos grficos primitivos O usurio deve manipular uma tabela como uma unidade e no como um amontoado de texto e grficos
Para permitir tal manipulao, usaremos uma representao interna que case com a estrutura fsica do documento Portanto, a representao interna deve suportar:
A manuteno da estrutura fsica do documento (o arranjo de texto e grficos em linhas, colunas, tabelas, ...) A gerao e apresentao visual do documento Mapear posies da tela para elementos da representao interna. O editor vai saber para o que o usurio est apontando Texto e grficos devem ser tratados uniformemente

Tem algumas outras restries no projeto
A interface deve permitir embutir texto em grficos e vice versa Um grfico no deve ser tratado como caso especial de texto, nem texto como caso especial de grfico, seno teremos mecanismos redundantes de manipulao, formatao, etc.
A implementao no deve ter que diferenciar entre elementos nicos e grupos de elementos na representao interna
O editor deve tratar elementos simples e complexos de forma uniforme permitindo assim documentos arbitrariamente complexos O dcimo elemento da linha 5, coluna 2 pode ser um caractere nico ou um diagrama complexo com muitos elementos
04/02/2012
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\composite.htm
Composite
Page 2 of 11
Basta que o elemento saiba se desenhar, possa dar suas dimenses: ele pode ter qualquer complexidade
Por outro lado, queremos analisar o texto para verificar a grafia, hifenizar, etc. e no podemos verificar a grafia de grficos ou hifeniz-las
Composio recursiva
Uma forma comum de representar informao estruturada hierarquicamente atravs da Composio Recursiva
Permite construir elementos complexos a partir de elementos simples
Aqui, a composio recursiva vai permitir compor um documento a partir de elementos grficos simples
Comeamos formando linhas a partir de elementos grficos simples (caracteres e grficos) Mltiplas linhas formam colunas Mltiplas colunas formam pginas Mltiplas pginas formam documentos etc.
Podemos representar essa estrutura fsica usando um objeto para cada elemento

Isso inclui elementos visveis e elementos estruturais (linhas, colunas) A estrutura de objetos seria como abaixo
04/02/2012
Composite
Page 3 of 11
Na prtica, talvez um objeto no fosse usado para cada caractere por razes de eficincia
Podemos agora tratar texto e grficos de forma uniforme Podemos ainda tratar elementos simples e compostos de forma uniforme Teremos que ter uma classe para cada tipo de objeto e essas classes tero que ter a mesma interface (para ter uniformidade de tratamento)
Uma forma de ter interfaces compatveis de usar herana
Definimos uma interface "ElementoDeDocumentoIF" e uma classe abstrata "ElementoDeDocumento" para todos os elementos que aparecem na estrutura de objetos
Suas subclasses definem elementos grficos primitivos (caracteres e grficos) e elementos estruturais (linhas, colunas, frames, pginas, documentos, ...) Parte da hierarquia de classes segue abaixo
04/02/2012
Composite
Page 4 of 11
Elementos de documentos tm trs responsabilidades

Sabem se desenhar (draw) Sabem o espao que ocupam (limites) Conhecem seus filhos e pai
Subclasses de ElementoDeDocumento devem redefinir certas operaes tais como draw() Um ElementoDeDocumentoIF pai deve freqentemente saber quanto espao seus filhos ocupam para posicion-los de forma a no haver sobreposio
Isso feito com o mtodo limites() que retorna o retngulo que contm o elemento Usado quando o usurio clica com o mouse
A operao intersecta() serve para saber se um ponto intersecta o elemento
A classe abstrata ElementoCompostoDeDocumento implementa certos mtodos comuns atravs da aplicao sucessiva do mtodo aos filhos
o caso de intersecta()
04/02/2012
Composite
Page 5 of 11
Todos os elementos tm uma mesma interface para gerenciar os filhos (inserir, remover, etc.) Este padro de projeto chama-se Composite e ser discutido mais detalhadamente agora
O Padro Composite
Objetivo

Compor objetos em estruturas em rvore para representar hierrquias Parte-Todo Composite permite que clientes tratem objetos individuais e composies uniformemente
Participantes

Os nomes genricos dados s classes abstratas so Component e Composite Os nomes genricos dados s classes concretas so Leaf e ConcreteComposite
04/02/2012
Composite
Page 6 of 11
Consequncias do uso de Composite
Objetos complexos podem ser compostos de objetos mais simples recursivamente
O cliente pode tratar objetos simples ou compostos da mesma forma: simplifica o cliente
Facilita a adio de novos componentes: o cliente no tem que mudar com a adio de novos objetos (simples ou compostos) Do lado negativo, o projeto fica geral demais

mais difcil restringir os componentes de um objeto composto Por exemplo, acima, podemos compor linhas com linhas ou com documentos, etc. o que no faz sentido O sistema de tipagem da linguagem no ajuda a detectar composies erradas
04/02/2012
Composite
Page 7 of 11
A soluo verificar em tempo de execuo
Adicionar referncia ao pai de um objeto pode simplificar o caminhamento na estrutura
Onde adicionar a referncia ao pai? Normalmente colocada na classe abstrata Component
Exerccio: colocar esta referncia na figura acima
As subclasses herdam a referncia e os mtodos que a gerenciam til para reduzir as necessidades de espao Por exemplo, caracteres iguais poderiam compartilhar objetos Fazer isso complica se os componentes s puderem ter um nico pai O padro "flyweight" mostra como resolver a questo Exerccio para casa: certos livros colocam os mtodos de gerenciamento de filhos apenas na classe Composite porque uma folha no tem filhos! Voc concorda ou discorda com a maximizao da interface de Component? Por qu? Em outras palavras, melhor ter uma interface idntica para folhas e Composite (transparncia para o cliente) ou interfaces diferentes (segurana de no fazer besteiras como adicionar um filho a uma folha, o que seria capturado pelo compilador)? Se mantivermos as interfaces de Component e Composite diferentes, como o cliente pode testar se um objeto folha ou composto? Ns os colocamos em Composite mas eles poderiam ser colocados em Component A desvantagem a perda de espao para essa referncia para folhas Usar um iterator uma boa idia As classes Composite podem manter em cache informao sobre seus filhos de forma a eliminar (curto-circuitar) o caminhamento ou pesquisa nos filhos Um exemplo: um Composite poderia manter em cache os limites do conjunto de filhos de forma a no ter que recalcular isso sempre

Compartilhamento de componentes

Maximizao da interface de Component
Onde so armazenados os filhos?
Quando os filhos devem ter um ordem especial, deve-se cuidar deste aspecto
Cache de informao
Quando um filho muda, a cache deve ser invalidada Neste caso, os filhos devem conhecer o pai para avisar da mudana
Como armazenar os filhos?
Vector, LinkedList, HashMap (qualquer coleo razovel)
Uso do padro na API Java: O pacote java.awt.swing
Usa o padro Composite com a classe abstrata "Component" e o Composite sendo a classe "Container" Folhas podem ser Label, TextField, Button Composites concretos so Panel, Frame, Dialog
Exemplo de cdigo: um editor de documentos

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\composite.htm 04/02/2012
Composite
Page 8 of 11
O diagrama de classes segue
interface ElementoDeDocumentoIF { ElementoDeDocumentoIF getPai(); /** * Retorna o font associado a este objeto. * Se no houver font, retorna o font do pai. * Se no houver pai, retorna null. */ Font getFont(); /** * Associa um font a este objeto. */ void setFont(Font font); /** * Retorna o nmero de glyphs que este objeto contm. */
Composite
Page 9 of 11
int getNumGlyph(); /** * Retorna o filho deste objeto na posio dada. */ ElementoDeDocumentoIF getFilho(int ndice) throws FolhaException; /** * Faa o ElementoDeDocumentoIF dado um filho deste objeto. */ void insereFilho(ElementoDeDocumentoIF filho) throws FolhaException; /** * remove o ElementoDeDocumentoIF dado * da lista de filhos deste objeto. */ void removeFilho(ElementoDeDocumentoIF filho) throws FolhaException; } // interface ElementoDeDocumentoIF abstract Class ElementoDeDocumento implements ElementoDeDocumentoIF { // Este o font associado ao objeto // Se for nulo, o font herdado do pai private Font font; // o container deste objeto ElementoDeDocumentoIF pai; ... public ElementoDeDocumentoIF getPai() { return pai; } public Font getFont() { if(font != null) { return font; } else if(pai != null) { return pai.getFont(); } else { return null; } } // getFont() public void setFont(Font font) { this.font = font; } // setFont() public abstract int getNumGlyph(); public ElementoDeDocumentoIF getFilho(int ndice) throws FolhaException { throw new FolhaException("Folha no tem filhos"); } /** * Faa o ElementoDeDocumentoIF dado * um filho deste objeto. */ public void insereFilho(ElementoDeDocumentoIF filho) throws FolhaException { throw new FolhaException("Folha no tem filhos"); } /** * Remove o ElementoDeDocumentoIF dado * da lista de filhos deste objeto. */ public void removeFilho(ElementoDeDocumentoIF filho) {
Composite
Page 10 of 11
throws FolhaException { throw new FolhaException("Folha no tem filhos"); } } // class ElementoDeDocumento abstract class ElementoCompostoDeDocumento extends ElementoDeDocumento implements ElementoDeDocumentoIF { // Os filhos deste objeto private Collection filhos = new Vector(); // Valor em cache de getNumGlyph private int cacheNumGlyph; // Validade de cacheNumGlyph private boolean cacheValida = false; /** * Retorna o filho deste objeto na posio dada. */ public ElementoDeDocumentoIF getFilho(int ndice) { return (ElementoDeDocumentoIF)filhos.get(ndice); } // getFilho() /** * Faa o ElementoDeDocumentoIF dado * um filho deste objeto. */ public synchronized void insereFilho(ElementoDeDocumentoIF filho) { synchronized(filho) { filhos.add(filho); filho.pai = this; avisoDeMudana(); } // synchronized } // insereFilho() /** * Remove o ElementoDeDocumentoIF dado * da lista de filhos deste objeto. */ public synchronized void removefilho(ElementoDeDocumentoIF filho) { synchronized(filho) { if(this == filho.pai) { filho.pai = null; } filhos.remove(filho); avisoDeMudana(); } // synchronized } // removeFilho() ... /** * Uma chamada a esta funo significa que um filho mudou, * o que invalida a cache de informao que o objeto mantm * sobre seus filhos. */ public void avisoDeMudana() { cacheValida = false; if(pai != null) { pai.avisoDeMudana(); } } // avisoDeMudana() /** * Retorna o nmero de glyphs que este objeto contm. */ public int getNumGlyph() { if(cacheValida) { return cacheNumGlyph; } cacheNumGlyph = 0; for(int i = 0; i < filhos.size(); i++) {
Composite
Page 11 of 11
ElementoDeDocumentoIF filho; filho = (ElementoDeDocumentoIF)filhos.get(i); cacheNumGlyph += filho.getNumGlyph(); } // for cacheValida = true; return cacheNumGlyph; } // getNumGlyph() } // class ElementoCompostoDeDocumento class Caractere extends ElementoDeDocumento implements ElementoDeDocumentoIF { ... /** * Retorna o nmero de glyphs que este objeto contm. */ public int getNumGlyph() { return 1; } // getNumGlyph() } // class Caractere class Imagem extends ElementoDeDocumento implements ElementoDeDocumentoIF { ... /** * Retorna o nmero de glyphs que este objeto contm. */ public int getNumGlyph() { return 1; } // getNumGlyph() } // class Imagem class Pgina extends ElementoCompostoDeDocumento { implements ElementoDeDocumentoIF { ... } // Pgina
Alguns comentrios

getFont() usa a informao de seu pai Um objeto composto usa uma cache para saber quantos glyphs compem o objeto synchronized usado ao mexer com dados que podem ser compartilhados para possibilitar uma implementao multi-threaded
Perguntas finais para discusso
De que forma o padro Composite ajuda a consolidar lgica condicional espalhada no sistema (system-wide conditional logic)? Voc usaria o padro Composite se no tivesse uma hierarquia parte-todo? Em outras palavras, se apenas alguns objetos tm filhos e quase todos os outros objetos de uma coleo so folhas (uma folha no tem filho), voc ainda usaria o padro Composite para modelar tais objetos?
04/02/2012
Strategy
Page 1 of 6
Strategy
Introduo

Vamos considerar o problema de formatao no editor de documentos WYSIWYG J sabemos como a representao da informao Mas ainda no sabemos como gerar um estrutura particular de linhas, colunas e objetos simples para um documento particular
Isso resultado da formatao do documento O resto da formatao pode ser tratado de forma anloga H um trade-off entre velocidade de formatao e a qualidade resultante Muitas coisas devem ser consideradas tais como a "cor" de um documento (o espalhamento uniforme de espaos em branco) Muitos algoritmos tm sido propostos e podem ser usados no editor
Para simplificar, formatao significa apenas quebra em linhas
Automatizar a formatao no simples

O algoritmo pode at mudar em tempo de execuo
Considere a formatao em word com "layout normal" (simples) e "layout da pgina" (mais demorado mas mais WYSIWYG)
Ponto importante: queremos manter o algoritmo de formatao isolado da estrutura do documento

Podemos adicionar elementos grficos sem afetar o algoritmo de formatao Podemos mudar o algoritmo de formatao sem afetar o tratamento de elementos de documento
Isolaremos o algoritmo de formatao atravs de sua encapsulao num objeto Usaremos uma hierarquia de classes para objetos que encapsulam algoritmos de formatao
A raiz da hierarquia ser uma classe com interface suficientemente genrica para suportar uma larga gama de algoritmos Cada subclasse implementa a interface para um algoritmo particular
As classes Formatador e ElementosAFormatar
A classe Formatador usada para objetos que encapsulam um algoritmo de formatao As subclasses de Formatador implementam algoritmos de formatao especficos Os elementos a formatar so filhos de uma subclasse especial de ElementoDeDocumento (ElementosAFormatar)

Tem um nico objeto da classe ElementosAFormatar ElementosAFormatar existe por dois motivos:

Para ser pai dos elementos bsicos quando no tem formatao feita ainda Para manter referncia ao formatador
Quando um objeto ElementosAFormatar criado, ele cria uma instncia de uma subclasse de Formatador, especializada em formatar de alguma forma O objeto ElementosAFormatar pede ao formatador para formatar seus elementos quando necessrio
Por exemplo, quando h uma mudana ao documento
Ver a estrutura de classes abaixo
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\strategy.htm
04/02/2012
Strategy
Page 2 of 6
Um objeto ElementosAFormatar no formatado contm apenas os elementos bsicos visveis (sem Composites linha, coluna, etc.) Quando os ElementosAFormatar precisam de formatao, o objeto chama o formatador
O formatador varre os filhos de ElementosAFormatar e insere os elementos linha, coluna, etc. de acordo com o algoritmo de formatao Ver resultado dos objetos abaixo
04/02/2012
Strategy
Page 3 of 6
Formatadores diferentes implementam algoritmos diferentes
FormatadorSimples o mais simples e rpido (no trata de "cor") e trata apenas uma linha de cada vez FormatadorTeX mais complexo pois considera o pargrafo inteiro para distribuir os espaos em branco FormatadorArray coloca um nmero igual de elementos em cada linha (para alinhar imagens, por exemplo)
Resultado: a separao Formatador-ElementosAFormatar assegura uma separao forte entre o cdigo que suporta a estrutura do documento e o cdigo de formatao
Podemos adicionar novos formatadores sem tocar nas classes de elementos e vice-versa Podemos at mudar de formatador em tempo de execuo com uma funo setFormatador na classe ElementosAFormatar
O padro que usamos chama-se Strategy
O padro Strategy
Objetivo

Definir uma famlia de algoritmos, encapsular cada um, e torn-los intercambiveis Strategy permite mudar os algoritmos independentemente dos clientes que os usam
Policy
Quando usar o padro Strategy?

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\strategy.htm 04/02/2012
Strategy
Page 4 of 6
Vrias classes relacionadas tm apenas comportamento diferente Voc precisa de variantes de um algoritmo
Exemplo: com trade-offs diferentes de espao-tempo
Para esconder dos clientes os dados complexos que um algoritmo usa Uma classe tem vrios comportamentos escolhidos com muitas decises
Em vez de usar decises, mova os trechos apropriados para sua prpria classe Strategy
Estrutura genrica
Participantes
EstratgiaIF (exemplo: FormatadorIF)

Declara a interface comum a todos os algoritmos O contexto usa essa interface para chamar o algoritmo definido em EstratgiaConcreta Possvel classe abstrata para fatorar cdigo comum entre os algoritmos Implementa o algoritmo usando a interface EstratgiaIF configurado com um objeto EstratgiaConcreta Mantm uma referncia para um objeto EstratgiaIF Pode definir uma interface para que a estratgia acesse seus dados
Estratgia (exemplo: Formatador)
EstratgiaConcreta (exemplo: FormatadorSimples)
Contexto (exemplo: ElementosAFormatar)

Colaboraes entre objetos

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\strategy.htm 04/02/2012
Strategy
Page 5 of 6
O Contexto pode chamar a Estratgia passando a si mesmo para que a estratgia acesse os dados O Contexto encaminha pedidos dos seus clientes para a Estratgia Clientes normalmente criam uma EstratgiaConcreta e a passam para o contexto
A partir da, os clientes interagem apenas com o Contexto
Consequncias do uso do padro Strategy
Uma alternativa herana
Poder-se-ia usar herana (subclasses de Contexto) para fazer a mesma coisa
Teramos uma hierarquia de ElementosAFormatar, cada um com um mtodo formatar() diferente Em tempo de execuo, faramos um new de alguma subclasse de ElementoAFormatar
Qual subclasse dependeria do algoritmo especfico de formatao que se quer Teria que fazer "mutao" do objeto ElementoAFormatar1 para um novo tipo ElementoAFormatar2 Mas a "mutao de tipo" sinal de que o cdigo fede!
O problema: como mudar o algoritmo formatar() em tempo de execuo??
As linguagens no do suporte para isso
Soluo melhor: retirar o mtodo formatar e criar um objeto a parte s para ele Acopla o Contexto com os algoritmos (parafusa o comportamento no Contexto) Deixa o Contexto mais difcil de entender, manter e estender O algoritmo no poderia variar dinamicamente
Portanto, isso seria um mau exemplo do uso de herana
Exemplo clssico de herana versus composio Quando vrios comportamentos esto agrupados na mesma classe Cdigo que tem muitas condies assim candidato para o padro Strategy Depois que o contexto criado, os clientes enxergam apenas um objeto (o contexto) e no dois (contexto e estratgia) Porm, no momento da criao do contexto, alguma estratgia deve ser escolhida

Estratgias eliminam statements condicionais

Ponto negativo: transparncia incompleta dos 2 objetos
Os clientes devem portanto conhecer as estratgias antes de escolher uma Isso expe os clientes a consideraes de implementao S usa Strategy quando a diferena de comportamento for relevante aos clientes
Ponto negativo: mais objetos no projeto
O padro flyweight mostra como lidar com isso
Exemplo na API Java
Os Layout Managers de AWT so exemplos de classes que representam uma estratgia de layout para containers A EstratgiaIF LayoutManager
04/02/2012
Strategy
Page 6 of 6
tambm tem LayoutManager2 que uma extenso de LayoutManager
No tem classe abstrata Estratgia Tem muitas classes concretas (GridLayout, FlowLayout, BorderLayout, ...) O Contexto pode ser qualquer Container (Panel, ScrollPane, Window, ...)
O que ocorre quando um sistema tem uma exploso de objetos de estratgia? Tem uma forma melhor de gerenciar essas estratgias? Em Gamma, os autores descrevem duas formas pelas quais um objeto de estratgia pode obter a informao de que precisa para fazer seu trabalho. Uma forma descreve como um objeto de estratgia poderia receber uma referncia a um objeto de contexto, permitindo assim o acesso aos dados de contexto. Mas no poderia ocorrer que os dados necessrios estratgia no estivessem disponveis atravs da interface do objeto de contexto? Como remediar este possvel problema?
04/02/2012
Decorator
Page 1 of 8
Decorator
Introduo
No editor de documentos WYSIWYG, vamos embelezar a interface do usurio (UI)

Vamos adicionar uma borda rea de edio Vamos adicionar barras de rolagem (scroll bars) No poderamos mudar o embelezamento em tempo de execuo Para n tipos de embelezamento, precisaramos de 2n-1 subclasses para ter todas as combinaes
No vamos usar herana para adicionar este embelezamento

Teremos mais flexibilidade se outros objetos da UI no souberem que est havendo embelezamento!
Incluso transparente
Usaremos composio em vez de herana evita os problemas mencionados, mas quais objetos devem participar da composio? O embelezamento em si ser um objeto (digamos uma instncia da classe Borda) Isso nos d dois objetos para fazer a composio: ElementoDeDocumento e Borda Devemos decidir agora quem vai compor quem A Borda pode conter o ElementoDeDocumento
Faz sentido j que a Borda engloba o ElementoDeDocumento na tela Isso implica em mudar a classe ElementoDeDocumento para que ela conhea a Borda
O ElementoDeDocumento pode conter a Borda
Usaremos a primeira escolha de forma a manter o cdigo que trata bordas inteiramente na classe Borda sem mexer nas outras classes Como construir a classe Borda?
O fato da borda ter uma aparncia na tela sugere que ela deveria ser uma subclasse de ElementoDeDocumento Tem um outro motivo mais forte ainda de fazer isso: clientes tratam objetos ElementoDeDocumento e no deveriam saber se um ElementoDeDocumento tem uma Borda ou no!

Clientes devem tratar ElementoDeDocumento uniformemente Se um cliente manda um ElementoDeDocumento sem Borda se desenhar no vai aparecer borda, caso contrrio, vai aparecer borda, mas o cliente no sabe
Isso implica que a Borda tem a mesma interface que ElementoDeDocumento
Fazemos Borda uma subclasse de ElementoDeDocumento para garantir este relacionamento Composio com um nico filho; e Interfaces compatveis
Este conceito chama-se "Incluso Transparente"

Clientes no sabem se esto tratando do objeto original (ElementoDeDocumento) ou do seu incluidor (Borda) O incluidor delega as operaes para o objeto includo, mas aumenta o comportamento fazendo seu trabalho antes ou depois da delegao da operao
A classe MonoElementoDeDocumento
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\decorator.htm 04/02/2012
Decorator
Page 2 of 8
Definimos uma subclasse de ElementoDeDocumento chamada MonoElementoDeDocumento MonoElementoDeDocumento uma classe abstrata para todos os ElementoDeDocumento de embelezamento
MonoElementoDeDocumento armazena uma referncia a um nico ElementoDeDocumento (da "mono") e encaminha todos os pedidos para ele
Isso chamado Forwarding ou Delegao
Isso faz com que MonoElementoDeDocumento seja completamente transparente aos clientes A classe MonoElementoDeDocumento vai reimplementar pelo menos um dos mtodos de ElementoDeDocumento para fazer seu trabalho Exemplo: Borda redefine o mtodo draw():
public class Borda extends MonoElementoDeDocumento { ... public void draw(Component c) { super.draw(c); drawBorda(c); } ...
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\decorator.htm
04/02/2012
Decorator
Page 3 of 8
Observe que Borda estende o mtodo do pai para desenhar a borda
J que chama o mtodo do pai antes de fazer seu trabalho Ela desenha seu Componente em posies diferentes dependendo de duas barras de rolagem Ela adiciona as barras de rolagem como embelezamento Ao desenhar seu Componente, Rolador pede ao sistema grfico para fazer "clipping" do Componente nos limites apropriados
A classe Rolador tambm um embelezamento
As partes fora dos limites no aparecero
Agora, como adicionar uma Borda e um Rolador?
Compomos os ElementosAFormatar dentro de um Rolador e este dentro de uma Borda
Se compusssemos a Borda dentro do Rolador, a borda seria rolada tambm
Se isso for o comportamento desejado, essa ordem deve ser usada
A estrutura de objetos aparece abaixo
04/02/2012
Decorator
Page 4 of 8
Observe que os embelezadores compem um nico Componente Se tentssemos embelezar mais de uma coisa de cada vez, teramos que misturar vrios tipos de ElementoDeDocumento com embelezadores

Teramos embelezamento de linha, embelezamento de coluna, etc. O jeito que fizemos parece melhor Embelezamento usando incluso transparente Observe que o embelezamento pode, na realidade, ser qualquer adio de responsabilidades e no um "embelezamento visual"

Este padro chama-se Decorator

Ex. embeleza uma rvore de sintaxe com aes semnticas Ex. embeleza uma mquina de estados finitos com novas transies
O padro Decorator
Objetivo

Adicionar responsabilidades dinamicamente a um objeto Decoradores provem uma alternativa flexvel herana para estender funcionalidade
04/02/2012
Decorator
Page 5 of 8
Permitem adicionar responsabilidades a um objeto e no a uma classe inteira
Tambm chamado de
Wrapper
Quando usar o padro Decorator?
Para adicionar responsabilidades dinamicamente a objetos individuais e transparentemente (sem afetar outros objetos) Quando h responsabilidades que podem ser retiradas Quando herana geraria uma exploso de subclasses Quando a herana seria uma boa alternativa mas a definio da classe est escondida ou no disponvel para herana
Estrutura genrica
Participantes
ComponenteIF (ex. ElementoDeDocumentoIF)

04/02/2012
Decorator
Page 6 of 8
Define a interface de objetos que podem ter responsabilidades adicionadas dinamicamente Possvel classe abstrata para fatorar o cdigo comum dos ComponenteConcreto Define um objeto ao qual se pode adicionar responsabilidades adicionais Mantm uma referncia a um objeto ComponenteIF e define uma interface igual do Componente Adiciona responsabilidades ao Componente
Componente (ex. ElementoDeDocumento)
ComponenteConcreto (ex. ElementosAFormatar)
Decorador (ex. MonoElementoDeDocumento)
DecoradorConcreto (ex. Borda, Rolador)
Colaboraes entre objetos

O Decorador encaminha pedidos ao Componente Pode opcionalmente adicionar operaes antes ou depois deste encaminhamento
Consequncias do uso do padro Decorator
Mais flexvel do que herana esttica

Pode adicionar responsabilidades dinamicamente Pode at adicionar responsabilidades duas vezes! (ex. borda dupla) Em vez de tentar prever todos os features numa classe complexa e customizvel, permite definir classes simples e adicionar funcionalidade de forma incremental com objetos decoradores Desta forma, as aplicaes no tm que pagar pelos features que no usam Portanto, cuidado com a identidade de objetos: um Decorador adiconado a um objeto vai mudar o objeto com o qual o cliente lida (em termos de identidade) Fcil de customizar por programadores que entendem o projeto mas pode ser difcil entender e depurar
Evita classes com features demais no topo da hierarquia
Ponto negativo: o Decorador e o objeto incluso no tm a mesma identidade
Ponto negativo: muitos pequenos objetos

A interface do decorador deve ser igual interface do objeto sendo decorado Se tiver que adicionar uma nica responsabilidade, pode remover o decorador abstrato
Neste caso, o decorador concreto pode tratar do forwarding para o Componente incluso A classe Componente deve ser mantida enxuta e os dados ser definidos nos Componentes concretos Caso contrrio, os decoradores (que herdam de Componente) ficam "pesados"
Mantendo Componentes enxutos
Decorator versus Strategy

Decorator
Page 7 of 8
Decorator muda a "pele" de um objeto enquanto Strategy muda as "entranhas" Strategy melhor quando a classe Componente pesada

Neste caso, o decorador seria pesado demais Com Strategy, parte do comportamento de Componente repassado para outro objeto (que implementa um algoritmo) O Componente "sabe" da existncia do(s) objeto(s) de estratgia mas no sabe da existncia de decoradores O Componente pode mandar um objeto Borda (que ele conhece) desenhar a borda O Componente pode manter uma lista de objetos de estratgia para fazer vrias coisas, o que equivalente a ter decoradores recursivos Neste caso, o objeto Borda encapsula a estratgia de desenhar uma borda
Exemplo: bordas com Strategy
Ver a figura abaixo
Exemplo de cdigo na API Java

Uso de scroll bars ScrollPane() um decorador que contm um Component e adiciona barras de rolagem
No usei Swing para poder mostrar o resultado num applet e vrios browsers ainda no suportam Swing Para Swing, a classe um JScrollPane.
Exemplo de cdigo segue:
import java.awt.*; import java.applet.*; public class Scroll extends Applet { public void init() { ScrollPane spane = new ScrollPane(); Button botaoGrande1 = new Button("Eu adoro Metodos Avanados de Programao!"); botaoGrande1.setFont(new Font("Serif", Font.ITALIC, 80)); Button botaoGrande2 = new Button("Eu adoro Metodos Avanados de Programao!"); botaoGrande2.setFont(new Font("Serif", Font.ITALIC, 80)); spane.add(botaoGrande1); add(botaoGrande2); // sem scroll bars add(spane); // com scroll bars }
Decorator
Page 8 of 8
Applet roda aqui
Na seo de implementao do Decorator Pattern, os autores (Gamma et al.) escrevem: A interface de um objeto decorador deve estar de acordo com a interface do Componente que ele decora. Agora, considere um objeto A decorado pelo objeto B. Haja vista que o objeto B decora o objeto A, o objeto B compartilha uma interface com o objeto A. Se algum cliente recebe uma instncia do objeto decorado (B) e tenta chamar um mtodo em B que no faa parte da interface de A, isto significa que o objeto B no mais um decorador, no sentido estrito do padro? Alm do mais, porque importante que a interface de um objeto decorador esteja de acordo com a interface do objeto que ele decora?
04/02/2012
Template Method
Page 1 of 4
Template Method
Um problema a resolver: login
Sua tarefa de escrever uma classe para controlar o login de usurios numa aplicao Tem dois caminhos bsicos para resolver o problema:

Escrever uma classe estanque para a aplicao sob considerao Escrever uma soluo genrica para qualquer aplicao
Para promover o reuso
A soluo genrica seria um framework de login

Um esqueleto de login que seja comum a qualquer tarefa de login Ganchos para permitir que cada aplicao customize o processo de login Prompt para o usurio fornecer sua identificao (ID) e senha Autenticao da ID e senha

Quais so os passos genricos de login?

O resultado da autenticao deve ser um objeto Este objeto pode encapsular qualquer informao que possa ser usada adiante pela aplicao para comprovar a autenticao
Aviso visual de progresso indicando que a autenticao est sendo realizada Um aviso de sucesso ao resto da aplicao que o login foi realizado e para disponibilizar o objeto produzido pela autenticao
A lgica das etapas 1 e 3 no muda A lgica das etapas 2 e 4 pode variar muito entre aplicaes
Cada aplicao dever prover seu prprio cdigo Criar uma classe abstrata Login contendo:
Soluo
Um mtodo principal (chamado Template Method) que capture a lgica comum de login Mtodos abstratos para representar as etapas do algoritmo que devem ser fornecidas pela aplicao particular
Estender a classe Login para prover implementaes dos mtodos abstratos para uma aplicao particular (digamos para uma aplicao de DecisionSupportSystem)
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\template.htm
04/02/2012
Template Method
Page 2 of 4
Chama-se o mtodo login() de Template Method
O padro Template Method

Objetivo
Define o esqueleto de um algoritmo numa operao, deixando que subclasses completem algumas das etapas. O padro Template Method permite que subclasses redefinem determinadas etapas de um algoritmo sem alterar a estrutura do algoritmo.
Resumo

Um Template Method define um algoritmo usando operaes abstratas Subclasses fazem override das operaes para prover um comportamento concreto Este padro a base para a construo de frameworks
Quando usar o padro Template Method?
Para implementar partes invariantes de um algoritmo uma nica vez e deixar subclasses implementarem o comportamento varivel Quando comportamento comum entre subclasses deveria ser fatorado e localizado numa classe comum para evitar duplicao
um passo frequente de "refactoring" de cdigo

Primeiro identifique as diferenas Coloque as diferenas em novos mtodos Substitua o cdigo das diferenas por uma chamada a um dos novos mtodos
Para controlar extenses de subclasses
Voc pode definir um Template Method que chame operaes-gancho (hook) e pontos especficos, permitindo extenses apenas nestes pontos
Faa com que apenas os mtodos-gancho possam sofrer override, usando adjetivos de visibilidade
04/02/2012
Template Method
Page 3 of 4
"public final" para o Template Method "protected" para mtodos que devem/podem sofrer override
Estrutura genrica
Participantes
ClasseAbstrata (Login)
Define operaes abstratas que subclasses concretas definem para implementar certas etapas do algoritmo Implementa um Template Method definindo o esqueleto de um algoritmo
O Template Method chama vrias operaes, entre as quais as operaes abstratas da classe
ClasseConcreta (LoginDecisionSupportSystem)
Implementa as operaes abstratas para desempenhar as etapas do algoritmo que tenham comportamento especfico a esta subclasse
Colaboraes
ClasseConcreta depende de ClasseAbstrata para implementar as partes invariantes do algoritmo
Consequncias do padro Template Method
Template Methods constituem uma das tcnicas bsicas de reuso de cdigo
So particularmente importantes em frameworks e bibliotecas de classes para o fatoramento de comportamento comum O cdigo particular de uma aplicao chamado pelo resto do cdigo Normalmente, escrevemos o cdigo "de cima" e chamamos partes comuns "em baixo"
Template Methods levam a uma inverso de controle

Aqui, o contrrio
04/02/2012
Template Method
Page 4 of 4
Tambm chamado de "Hollywood Principle"
"Don't call us, we'll call you"
O Template Method pode chamar vrios tipos de operaes

Operaes concretas (da ClasseConcreta ou de outras classes) Operaes concretas de ClasseAbstrata (operaes comuns teis s subclasses) Operaes abstratas (onde o comportamento varia)
Devem sofrer override
Factory Methods Operaes-gancho

Podem sofrer override Uma operao-gancho tem implementao nula (fazendo nada) na ClasseAbstrata A subclasse pode fazer override para inserir algo neste ponto (da, "gancho") uma forma limpa de estender o comportamento de uma classe de forma controlada
Isto , apenas nos pontos onde h ganchos
importante minimizar o nmero de operaes abstratas que devem sofrer override para completar o algoritmo
Motivo: simplificao para no chatear o programador Mtodos abstratos que devem sofrer override deveriam ter algo de comum no nome
Convenes de nome
Exemplo: doXpto() // comea com "do"
Mtodos-gancho que podem sofrer override deveriam ter algo de comum no nome
Exemplo: logHook() // termina com "Hook"
O Template Method funciona com herana. Seria possvel obter a mesma funcionalidade da Template Method usando composio de objetos? Quais seriam alguns dos tradeoffs? Suponha que um framework tenha uma classe X contendo um ou mais template methods. Os criadores de objetos da classe X so objetos da classe C. O framework completado com subclasses de X, digamos X'. De que forma seria possvel que objetos da classe X' fossem criados pelo framework, sem que o programador tenha o cdigo fonte do framework (isto , sem o cdigo fonte da classe C)?
04/02/2012
Observer
Page 1 of 8
Observer
No vamos seguir a apresentao do livro GoF aqui, pois h crticas sobre a soluo dada
Falaremos das crticas frente
Seguiremos a apresentao dada por Bill Venners em http://www.javaworld.com/topicalindex/jw-ti-techniques.html (The 'event generator' idiom) Em particular, apresentaremos como este padro implementado em Java
Portanto, alm de um Design Pattern (que no depende de linguagem), apresentaremos um "Idioma Java" que mostra como implementar um Design Pattern numa linguagem particular
Objetivo
O padro Observer permite que objetos interessados sejam avisados da mudana de estado ou outros eventos ocorrendo num outro objeto
O objeto sendo observado chamado de:

"Subject" (GoF) "Observable" (java.util) "Source" ou "Event Source" (java.swing e java.beans) Provedor de informao (Bill Venners) Gerador de eventos (Bill Venners) Observer (GoF e java.util) Listener (java.swing)

O objeto que observa chamado de

Java usa este padro em 2 lugares mas de formas diferentes! A forma java.util no boa (ver crticas adiante)
Usaremos as palavras Source e Listener
Tambm chamado de
Event Generator, Dependents, Publisher-Subscriber
Exemplo
Como projetar um sistema que modele um telefone e todos os objetos que poderiam estar interessados quando ele toca? Os objetos interessados poderiam ser:

Pessoas que estejam perto (na mesma sala) Uma secretria eletrnica Um FAX At um dispositivo de escuta clandestina :-) Pessoas entram e saem da sala onde o telefone est Secretrias eletrnicas, FAX, etc. podem ser adicionados ou removidos durante a execuo do programa Novos dispositivos podero ser inventados e adicionados em verses futuras do programa Faa do telefone um Event Source
04/02/2012
Os objetos interessados podem mudar dinamicamente

Qual a soluo bsica de projeto?
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\observer.htm
Observer
Page 2 of 8
O problema
Em Java, um objeto (o Source) envia informao para outro objeto (o Listener) pela chamada de um mtodo do Listener Mas, para que isso seja possvel:

O Source deve ter uma referncia ao Listener O tipo desta referncia deve ser uma classe ou interface que declare ou herde o mtodo a chamar
Fazer com que o tipo da referncia seja a classe (concreta) do Listener no funciona bem, porque:

O nmero e tipos dos Listeners no conhecido em tempo de compilao Os vrios listeners podero no fazer parte de uma mesma hierarquia de objetos No queremos criar um acoplamento forte entre Source e Listeners Alis, este um excelente exemplo do poder de interfaces para prover polimorfismo envolvendo classes no relacionadas por herana (de implementao)
A soluo vai se basear primordialmente em interfaces para resolver o problema
A soluo idiomtica em Java

Etapa 1: Definir classes de categorias de eventos
Defina uma classe separada de evento para cada categoria principal de eventos que podero ser gerados pelo Source Faa com que cada classe de eventos estenda java.util.EventObject Faa com que cada classe encapsule a informao a ser propagada para os Listeners Use nomes de classe que terminem em Event (exemplo: TelefoneEvent)
Etapa 2: Define interfaces de Listener
Para cada categoria de eventos, defina uma interface que estenda java.util.EventListener e que contenha um mtodo para cada evento (da categoria) que vai gatilhar a propagao de informao do Source para os Listeners Chame a interface como chamou a classe de eventos, substituindo Event por Listener
Exemplo: Para a classe TelefoneEvent, a interface de Listener seria TelefoneListener
D nomes aos mtodos da interface para descrever a situao que causou o evento. Use um verbo no pretrito
Exemplo: mtodo TelefoneTocou
Cada mtodo deve retornar void e aceitar um parmetro, uma referncia a uma instncia da classe de eventos apropriada
Exemplo de uma assinatura completa:
void telefoneTocou(TelefoneEvent e);
Etapa 3: Define classes de adaptao (opcional)
Observao:
muito comum querer uma classe que implemente uma interface fazendo nada para a maioria dos mtodos e fazendo algo til apenas para alguns poucos mtodos
04/02/2012
Observer
Page 3 of 8
Para ajudar o programador, comum, em Java, criar uma classe "adapter" que implemente todos os mtodos de uma interface com mtodos que nada fazem
As classes que devem implementar a interface podem herdar do adapter e fazer override de alguns poucos mtodos
Para cada interface de Listener que contenha mais do que um mtodo, defina uma classe adapter que implemente a interface por inteiro com mtodos que nada fazem D um nome classe substituindo Listener com Adapter
Exemplo, para a interface TelefoneListener, a classe seria TelefoneAdapter
Etapa 4: Defina a classe observvel Source
Para cada categoria de eventos que sero propagados a partir de instncias desta classe, define um par de mtodos para adicionar/remover Listeners
Chame os mtodos add<nome-da-interface-listener> e remove<nome-dainterface-listener>
Exemplo: addTelefoneListener() e removeTelefoneListener()
Para cada mtodo em cada interface de Listener, define um mtodo privado de propagao de eventos. O mtodo no aceita parmetros e retorna void. Este mtodo propaga o evento para os Listeners
Chame o mtodo dispara<nome-do-mtodo-listener>
Exemplo: disparaTelefoneTocou()
Chamadas ao mtodo de disparo de eventos devem ser adicionas em lugares apropriados da classe Source
Nos lugares onde h mudana de estado ou ocorrncia de outros eventos interessantes
Etapa 5: Defina objetos Listener
Para ser um Listener de uma certa categoria de eventos, basta implementar a interface de Listener da categoria de eventos
Isso normalmente feito estendendo a classe Adapter
Estrutura
04/02/2012
Observer
Page 4 of 8
Exemplo de cdigo
No arquivo TelefoneEvent.java:
public class TelefoneEvent extends java.util.EventObject { public TelefoneEvent(Telefone source) { super(source); } }
Observe que source passado como parmetro e armazenado no objeto (super (source) faz isso)
Isso permite que quem recebe o evento faa java.util.EventObject.getSource() para saber qual objeto gerou o evento Permite que um mesmo objeto seja Listener de vrios objetos Source Tambm permite que, com esta referncia ao Source, o Listener acione outros mtodos do objeto para obter informao

Chama-se este modelo de "Pull model" No "Push model", toda a informao necessria est presente dentro do evento
Por simplicidade, no se est encapsulando dados no evento aqui mas seria possvel incluir:

O nmero de telefone que est chamando A data e as horas
No arquivo TelefoneListener.java (interface de Listener):

04/02/2012
Observer
Page 5 of 8
public interface TelefoneListener extends java.util.EventListener { void telefoneTocou(TelefoneEvent e); void telefoneAtendido(TelefoneEvent e); }
No arquivo TelefoneAdapter.java (classe Adapter):
public class TelefoneAdapter implements TelefoneListener { void telefoneTocou(TelefoneEvent e) { } void telefoneAtendido(TelefoneEvent e) { } }
A definio do source fica no arquivo Telefone.java:
import java.util.*; public class Telefone { private Collection telefoneListeners = new Vector(); public void tocaFone() { disparaTelefoneTocou(); } public void atendeFone() { disparaTelefoneAtendido(); } public synchronized void addTelefoneListener( TelefoneListener l) { if (telefoneListeners.contains(l)) { return; } telefoneListeners.add(l); } public synchronized void removeTelefoneListener(TelefoneListener l) { telefoneListeners.remove(l); } private void disparaTelefoneTocou() { Collection tl; synchronized (this) { // A interface Collection no tem clone() // mas a classe AbstractCollection tem. // Clonar para evitar problemas de sincronizao // durante a propagao tl = ((AbstractCollection)telefoneListeners).clone(); } Iterator it = tl.iterator(); if(!it.hasNext()) { return; } TelefoneEvent evento = new TelefoneEvent(this); while(it.hasNext()) { ((TelefoneListener)(it.next())).telefoneTocou(evento); } }
04/02/2012
Observer
Page 6 of 8
// disparaTelefoneAtendido() semelhante a disparaTelefoneTocou() // Exerccio: Que design pattern poderia ser usado para fatorar // o cdigo comum? private void disparaTelefoneAtendido() { Collection tl; synchronized (this) { tl = ((AbstractCollection)telefoneListeners).clone(); } Iterator it = tl.iterator(); if(!it.hasNext()) { return; } TelefoneEvent evento = new TelefoneEvent(this); while(it.hasNext()) { ((TelefoneListener)(it.next())).telefoneAtendido(evento); } } }

Tambm seria possvel usar o Infobus de Java para propagar os eventos Agora, precisamos de classes para usar o esquema acima Primeiro, os Listeners No arquivo SecretariaEletronica.java, temos:
public class SecretariaEletronica implements TelefoneListener { public void telefoneTocou(TelefoneEvent e) { System.out.println("Secretaria escuta o telefone tocando."); } public void telefoneAtendido(TelefoneEvent e) { System.out.println("Secretaria sabe que o telefone foi atendido."); } }
No arquivo Pessoa.java
public class Pessoa { public void escutaTelefone(Telefone t) { t.addTelefoneListener( new TelefoneAdapter() { public void telefoneTocou(TelefoneEvent e) { System.out.println("Eu pego!"); ((Telefone)(e.getSource())).atendeFone(); } } ); } }
Observe que a SecretariaEletronica implementa a interface TelefoneListener diretamente, sem usar TelefoneAdapter Por outro lado, o objeto Pessoa instancia uma "inner class" annima que estende TelefoneAdapter e faz override apenas do mtodo que interessa (TelefoneTocou())
Quisemos apenas mostrar formas diferentes de implementar a interface TelefoneListener
Finalmente, precisamos de uma aplicao (arquivo ExemploFone.java)
public class ExemploFone { public static void main(String[] args) { Telefone fone = new Telefone(); Pessoa fulano = new Pessoa(); SecretariaEletronica se = new SecretariaEletronica();
04/02/2012
Observer
Page 7 of 8
fone.addTelefoneListener(se); fulano.escutaTelefone(fone); fone.tocaFone(); // comea a brincadeira } }
A execuo de ExemploFone imprime:
Secretaria escuta o telefone tocando. Eu pego! Secretaria sabe que o telefone foi atendido.
Quando usar o padro Observer?
Quando uma abstrao tem dois aspectos, um dependente do outro. Encapsular tais aspectos em objetos separados permite que variem e sejam reusados separadamente Quando uma mudana a um objeto requer mudanas a outros e voc no sabe quantos outros objetos devem mudar Quando um objeto deve ser capaz de avisar outros sem fazer suposies sobre quem so os objetos. Em outras palavras, sem criar um acoplamento forte entre os objetos
Consequncias do uso do padro
Permite que se varie objetos Source e Listeners independentemente

Pode-se reusar objetos Source sem reusar seus Listeners e vice-versa Pode-se adicionar Listeners sem modificar o Source ou os outros Listeners Basta que os Listeners implementem uma interface simples Os objetos involvidos poderiam at pertencer a camadas diferentes de software O Source faz broadcast do aviso. Os Listeners podem fazer o que quiserem com o aviso, incluindo ignor-lo
O acoplamento entre Source e Listeners mnimo

Suporte para comunicao em broadcast
Do lado negativo: o custo de uma mudana ao estado de um Source pode ser grande se houver muitos Listeners
Um Listener pode estar cadastrado junto a vrios objetos Source
Ele pode descobrir quem o esta notificando se o objeto evento contiver uma referncia ao source (como temos no idioma Java) Se cada mtodo que muda o estado do Source disparar um evento, pode haver eventos demais se houver mudanas de estado demais Neste caso, pode-se deixar um mtodo pblico do Source que clientes ativam para disparar um evento depois que todas as mudanas ao estado forem feitas
Quem dispara o evento original?
O problema que o cliente pode "esquecer" de chamar este mtodo
Assegurar a consistncia do estado do objeto antes de disparar o evento
Particularmente perigoso se um mtodo do Source fizer:
super(novoValor); // Pai dispara o evento

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\observer.htm 04/02/2012
Observer
Page 8 of 8
var = novoValor;
// atualiza estado do objeto ( tarde!)
Diferenas entre modelos Push e Pull
O modelo Pull acopla os objetos menos pois o modelo Push supe que o Source sabe das necessidades de informao dos Listeners O modelo Push pode ser mais eficiente pois o Source pode indicar o que mudou dentro do evento, facilitando a vida para que os listeners saibam o que mudou
Usar eventos diferentes para cada situao pode resolver o problema
Cadastro de interesses
Pode-se mudar o protocolo de cadastro (Subscribe) para que o Listener indique as coisas que o interessam
Crticas sobre outras solues do mesmo padro
Gamma apresenta este padro de uma forma um pouco diferente e menos interessante
Esta forma (fraca) do padro Observer tambm usada nas classes Observer/Observable de java.util
Esses dois exemplos so mais fracos do que o apresentado aqui (baseado no Java Swing) pelos seguintes motivos:
Observable uma classe da qual voc deve herdar para fazer seu objeto um Source

Java no tem herana mltipla e isso queima o (nico) cartucho de herana Usar interfaces (herana de tipo) em vez de herana de implementao melhor
Para implementar um Observer (equivalente a Listener), voc tem que implementar a interface Observer que tem um nico mtodo update (Observable, Object)
A soluo acima muito melhor pois podemos ter vrios eventos, e vrios mtodos associados, o que torna o cdigo mais claro
Voc prefere entrar no cdigo do mtodo para descobrir que ele tratar de um telefone que est tocando ou melhor chamar o mtodo telefoneTocou() como fizemos??
A soluo acima permite descobrir mais facilmente o que mudou no estado do Source pois podemos usar vrios eventos.
De forma geral, o Observer/Observable do Java no bem visto hoje
O design clssico Model-View-Controller explicado na nota de implementao #8: Encapsulamento de semntica complexa de de atualizao. Poderia fazer sentido s vezes um Observer (ou View) falar diretamente com o Subject (ou Model)? Quais so as propriedades de um sistema que usa o padro Observer muito? Como fazer para depurar cdigo em tal sistema? Como tratar o problema de concorrncia com este padro? Considere, por exemplo, uma mensagem Unregister() sendo enviada para um objeto antes que este envie uma mensagem Notify() para o Gerente de Mudana (ou Controlador). Examine a tecnologia Infobus do Java e relacione-a com o padro Observer.
04/02/2012
Comentrios finais sobre Design Patterns
Page 1 of 3
Comentrios finais sobre Design Patterns Como selecionar um Design Pattern?

Considerando como Design Patterns resolvem Problemas de Design

Vimos aqui uma lista de situaes que foram um redesign Listamos novamente os problemas juntamente com os Design Patterns que ajudam a resolv-los Criar um objeto especificando sua classe explicitamente
Abstract Factory, Factory Method, Prototype Chain of Responsibility, Command Abstract Factory, Bridge Abstract Factory, Bridge, Memento, Proxy Builder, Iterator, Strategy, Template Method, Visitor Abstract Factory, Bridge, Chain of Responsibility, Command, Faade, Mediator, Observer Bridge, Chain of Responsibility, Composite, Decorator, Observer, Strategy Adapter, Decorator, Visitor
Dependncia de operaes especficas
Dependncia de plataformas de hardware ou software especficas
Dependncia da representao ou implementao de objetos
Dependncias algortmicas
Acoplamento forte
Extenso de funcionalidade atravs da herana
Dificuldade de alterar classes convenientemente
Examinando os Objetivos de cada Pattern
Veja a lista de todos os objetivos aqui
Estudando o relacionamento entre Design Patterns
Ver figura abaixo
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\pat\comentarios.htm
04/02/2012
Page 2 of 3
Examinando no livro da GoF as semelhanas e diferenas entre padres

Ver o final da apresentao de cada padro Ver a introduo aos 3 captulos do catlogo
H uma discusso das semelhanas
Considerando o que deve ser varivel do Design
Em vez de verificar as causas de redesign, podemos fazer o contrrio e verificar o que gostaramos que fosse modificvel sem redesign O importante aqui Encapsular o conceito que varia
04/02/2012
Page 3 of 3
Ver tabela abaixo

Aspecto(s) que varia(m) Propsito Design Pattern (O que pode mudar sem redesign) Abstract Factory Builder Famlias de objetos-produto Como um objeto composto criado Subclasse do objeto que instanciado A classe do objeto que instanciado A nica instncia de uma classe A interface para acessar um objeto A implementao de um objeto A estrutura e composio de um objeto As responsabilidades de um objeto (sem uso de herana) A interface de um subsistema O custo de armazenamento de objetos Como um objeto acessado; sua localizao O objeto que pode atender a um pedido Quando e como um pedido atendido Gramtica e interpretao de uma linguagem Como os elementos de uma coleo so acessados, varridos Como e quais objetos interagem uns com os outros Qual informao privada armazenada fora de um objeto, e quando O nmero de objetos que dependem de um outro objeto; como os objetos dependentes ficam atualizados Os estados de um objeto Um algoritmo Certas etapas de um algoritmo Operaes que podem ser aplicadas a objetos sem mudar suas classes
Criao
Factory Method Prototype Singleton Adapter Bridge Composite
Estrutura
Decorator Faade Flyweight Proxy Chain of Responsibility Command Interpreter Iterator Mediator Memento
Comportamento Observer State Strategy Template Method Visitor
Finalmente ... O que esperar de Design Patterns
Um vocabulrio comum de Design
"Vamos usar um Observer aqui ..." Desde que se especifique os Design Patterns usados
Ajuda no entendimento de software existente
Patterns faro de voc um projetista melhor Um alvo para Refactoring

Mais sobre isso aqui Consiste na reorganizao de software existente para melhorar sua qualidade
pat-11 programa anterior
04/02/2012
8. Tpicos Avanados
Page 1 of 1
8. Tpicos Avanados

Refactoring Extreme Programming Frameworks Componentes
etc programa
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\etc\index.htm
04/02/2012
Refactoring
Page 1 of 2
Refactoring
Introduo
Entropia de software
Programas comeam num estado bonito, bem projetados mas, com tempo, as sucessivas adies e mudanas fazem o programa perder sua estrutura Resultado final: espaguete Programa muda em formas no previstas Programa no perfeitamente entendido (mesmo sendo nosso!) e o enxerto menos perfeito do que poderia ser Presses de tempo Seria melhor reprojetar o sistema para limp-lo, mas preferimos empurrar com a barriga
Motivos

Tem um excelente livro de Fowler sobre Refactoring
Refactoring
Refactoring um termo usado para descrever tcnicas que diminuem a dor de reprojetar
Mudanas feitas a um programa que alteram apenas sua organizao, no sua funcionalidade Transformaes que preservam o comportamento
Por que refactoring importante?

A nica defesa contra a entropia de software Para consertar "bugs" de reusabilidade Permite adicionar padres de projeto aps escrever o programa Permite transformar um programa num framework Deixa voc pensar na generalidade amanh!

Hoje: basta deixar funcionando Parece algo estranho a dizer, mas veremos que a turma do extreme programming acredita nisso piamente!
Necessrio para software bonito
Problemas que refactoring pode resolver
Cdigo duplicado
Elimina duplicao com novos mtodos, novos objetos, movendo coisas comuns numa superclasse Mtodos Mtodos Mtodos Mtodos devem devem devem devem ser coesos (ser longo dica de que no est coeso) caber numa tela ser do mesmo nvel de abstrao estar na classe correta
Mtodos longos

Acoplamento forte demais Longas listas de parmetros

Encapsula num objeto Muda o mtodo para acessar o objeto

04/02/2012
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\etc\refactoring.htm
Refactoring
Page 2 of 2
V o que mais deveria estar no objeto Mudar para polimorfismo
switch e variveis "tipo-de-objeto"
Introduzir interfaces e aumentar o polimorfismo
Como fazer refactoring?

No faa refactoring e adio de funcionalidade ao mesmo tempo Tenha testes automticos prontos antes de fazer refactoring Faa mudanas muito pequenas de cada vez e teste, teste, teste
Quando fazer refactoring?

Quando parece difcil de enxertar nova funcionalidade Se uma nova funcionalidade adicionou cdigo feio Quando voc no aguenta olhar para seu prprio cdigo!
etc-1 programa prxima
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\etc\refactoring.htm
04/02/2012
Extreme Programming
Page 1 of 3
Extreme Programming (XP)

Introduo
Alguns super-programadores (e irreverentes!) de smalltalk decidiram criar um processo simples de desenvolvimento de software

Talvez achando que os outros processos eram complexos?!? Ward Cunningham, Ron Jeffries, Martin Fowler, Kent Beck
Cunningham e Beck so a turma do carto CRC
Cuidado! XP foi testado para times pequenos e talvez requeira excelentes programadores. No se sabe a aplicabilidade geral da tcnica
No para qualquer um, mas pode ter resultado impressionantes
Muita informao aqui sobre isso. Vale a pena conferir. Tambm tem um excelente livro de Beck
Extreme Programming
Alegao bsica: software difcil demais para gastar tempo com coisas que no so importantes Ento, o que importante?
Codificar: se, no final do dia, o programa no funciona e no ajuda o cliente a ganhar dinheiro, voc no fez nada Testar: voc tem que saber quando terminou. Os testes dizem isso. Se voc for inteligente, vai escrev-los primeiro para saber instantaneamente quando voc terminou Escutar: tem que saber qual o problema a resolver. Escute clientes, gerentes e pessoas do negcio Refatorar: voc tem que escutar o que o programa est dizendo para voc sobre sua prpria estrutura e colocar este conhecimento de volta no programa Se algum falar para voc que fazer software outra coisa (alm de codificar, testar, escutar, refatorar), ele est tentando lhe vender algo
No falei que eram irreverentes?!
Por isso, inventaram uma disciplina de desenvolvimento de software (xp) baseada nos seguintes valores:

Simplicidade Comunicao Feedback Agressividade
As prticas de XP foram definidas para balancear as foras agindo no projeto
Resumo do processo (com links para o wiki)
Planejamento feito com o PlanningGame
Autoridade delegada para os clientes definirem os requisitos usando UserStories (parecem Use Cases) Autoridade delegada para os clientes estabelecerem as prioridades de desenvolvimento das estrias
Desta forma, o cliente pode maximizar o business value (BusinessValueFirst)
Autoridade delegada para os desenvolvedores estimarem quanto tempo cada estria levar para ser desenvolvida
04/02/2012
file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\etc\xp.htm
Extreme Programming
Page 2 of 3
Esta delegao de autoridade (que rara!) prov um ambiente de desenvolvimento livre de estresse
Os clientes possuem boa informao sobre quanto tempo as coisas levam e podem portanto maximizar o custo-benefcio das estrias que so desenvolvidas primeiro Os desenvolvedores pouco se importam com as funcionalidades pedidas (o que tambm raro!), porque eles estimam quanto tempo as coisas levam J que delegar as prioridades para o cliente pode ser perigoso em alguns casos (pedir algo fundamental mas difcil no fim do projeto perigoso!), h uma regra que balanceia as coisas: as piores coisas so atacadas primeiro (WorstThingsFirst)
Semelhante ao processo unificado "risk-confronting"
O trabalho acompanhado atravs de um cronograma (CommitmentSchedule) revisado a cada poucas iteraes
Para avaliar novos riscos e oportunidades
As iteraes so planejadas (IterationPlanning) entre desenvolvedores e clientes Nada feito que no seja imediatamente til e necessrio para no impactar os prazos de desenvolvimento (YouArentGonnaNeedIt)
Eles no acreditam em pensar muito no futuro para se preparar para o que vem depois Faa funcionar o UserStory de hoje!
A simplicidade sempre reina: s se usa a soluo mais simples que satisfaa os requisitos do problema (DoTheSimplestThingThatCouldPossiblyWork) As duas regras acima (YouArentGonnaNeedIt e DoTheSimplestThingThatCouldPossiblyWork) acabam gerando cdigo que precisa ser alterado s vezes. Para simplificar a manuteno/evoluo, o cdigo tem que estar sempre limpo e no duplicado. A regra refatorar impiedosamente (RefactorMercilessly).
Prticas de XP
Para terminar esta introduo, eis a lista de prticas de XP (leia cada uma dessas prticas no wiki e resuma cada uma em uma frase nas suas prprias palavras) DoTheSimplestThingThatCouldPossiblyWork encoraja no sobre-projetar (nem subprojetar) AskTheCode porque ele sabe (... dizer que precisa ser refatorado, ... dizer onde est o bug, ...) UnitTests: essa turma testa, testa, testa ... para no quebrar o cdigo um do outro. Unit testes so escritos para cada classe e testados usando o TestingFramework. Testes de unidade pertencem ao desenvolvedor. FunctionalTests para testar as estrias e saber se as necessidades do usurio esto sendo atingidas. Os usurios forneceram os dados usados nestes testes. Testes funcionais pertencem ao cliente. ContinuousIntegration gerando um processo iterativo para evitar IntegrationHell. A integrao de uma nova verso de algo (mesmo pequeno) quase instantnea, logo depois dos testes. ContinuousIntegrationRelentlessTesting (como acima, mas lembrando que tem que testar, testar e testar) RefactorMercilessly para manter o cdigo limpo e o progresso rpido (ver tambm WikiPagesAboutRefactoring). S funciona bem se tiver muitos testes para se assegurar de que no quebrou nada.

Recomenda-se chegar ExtremeNormalForm "Your classes are small and your methods are small; you've said everything OnceAndOnlyOnce and you've removed the last piece of unnecessary code. Somewhere far away an aikido master stands in a quiet room. he is centered.. aware.. ready for anything.
04/02/2012
Extreme Programming
Page 3 of 3
Outside a sprinter shakes out her legs and settles into the block, waiting for the crack of the gun while a cool wind arches across the track. Ssoftly, a bell sounds.. all of your tests have passed. Your code is in ExtremeNormalForm... tuned to today and poised to strike at tomorrow."
ProgrammingInPairs prov qualidade mais alta, treinamento mtuo e velocidade mais alta. Use uma pessoa menos experiente no teclado e uma mais experiente junto. SpikeSolution solues exploratrias rpidas para certos problemas ModelFirst mais SpartanUserInterface ajudam a manter o foco nas necessidades do usurio. SpartanUserInterface significa fazer uma interface simples e deixar o usurio usar, melhorar o que atrapalha, jogar fora o que no usado at que o resultado satisfaa. ExtremePlanning bolar um mapa rpido da soluo global com refinamentos incrementais PlanningGame para formalizar os papeis e responsabilidades no planejamento CountDownToRelease discute como usar ExtremePlanning quando a data de release final se aproxima. As regras:

Deixa o cliente decidir o que falta at soltar o produto Reunio semanal para tratar de IterationPlan StandupMeeting dirio rpido
ExtremeReuse adotando software de terceiros e adequando-o a XP pela construo de testes TossIt para fazer e manter projetos magros, jogue o que no parece til pela janela. No precisa ser mantido, documentado, etc. SystemMetaphor formas de comunicar o sistema para outros e os prprios desenvolvedores. Outras palavras para arquitetura
Pouca coisa: algumas classes, alguns padres, ... Soluo: o time (pequeno) inteiro usando CRC Para requisitos: UserStories e FunctionalTests (Sim! testes funcionais so requisitos que devem ser satisfeitos! Pense sobre isso ...) Para anlise e design: nenhum documento, s cartes CRC Para codificao: um comentrio por classe, se necessrio Se o usurio quiser um documento, manual, etc. s fazer um UserStory pedindo! Regra 1: parea calmo (no precisa s-lo, s parecer) Regra 2: escreva cada problema num carto Regra 3: atribua um fator de urgncia a cada carto Regra 4: trate de um carto de cada vez. faa o primeiro. faa o segundo, ... at que a crise v embora.
XpDesign quem projeta em XP e quando?
ExtremeDocuments documentao faz parte, embora ela seja diferente s vezes
SupportCrisis o que fazer quando a m..... bate no ventilador?

etc-2 programa anterior prxima
04/02/2012

Apoo Jacques Ufcg

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Apoo Jacques Ufcg

Transféré par

Droits d'auteur :

Formats disponibles

Anlise e Projeto de Sistemas Orientados a Objeto

Anlise e Projeto de Sistemas Orientados a Objeto Objetivos Gerais

apoo-1 programa prxima

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\apoo1.htm

Anlise e Projeto de Sistemas Orientados a Objeto: Programa

Anlise e Projeto de Sistemas Orientados a Objeto Programa

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\apoo2.htm

Anlise e Projeto de Sistemas Orientados a Objeto: Programa

Refactoring Extreme Programming Frameworks Componentes

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\apoo2.htm

1. Introduo Anlise e Projeto de Sistemas Orientados a Objeto

1. Introduo Anlise e Projeto de Sistemas Orientados a Objeto

Anlise e projeto orientados a objeto Introduo a um processo de desenvolvimento Modelos e artefatos

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\intro\index.htm

Anlise e Projeto Orientados a Objeto

Anlise e Projeto Orientados a Objeto

Comparar e contrastar Anlise e Projeto Definir Anlise e Projeto Orientados a Objeto

O que vamos fazer na disciplina?

Os patterns trataro principalmente de:

Para evitar "o efeito gelatina"

O que Anlise e Projeto?

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\intro\intro1.htm

Anlise e Projeto Orientados a Objeto

A obteno de requisitos frequentemente includa na fase de anlise ("anlise de requisitos")

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\intro\intro1.htm

Anlise e Projeto Orientados a Objeto

O que Anlise e Projeto Orientados a Objeto (APOO)?

Tais objetos pode ter atributos e mtodos

Durante a construo (programao OO), os objetos do projeto so implementados e testados

APOO versus AP Orientados a Funes (APOF)

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\intro\intro1.htm

Anlise e Projeto Orientados a Objeto

Por que queremos Orientao a Objeto? Quais so as vantagens?

As abstraes podem corresponder s coisas do domnio do problema

intro-1 programa prxima

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\intro\intro1.htm

Definir os modelos e artefatos a serem produzidos durante o proceso de desenvolvimento de software

Os modelos e outros artefatos (deliverables)

Artefatos da fase de elaborao

Requisitos funcionais (Modelo de use case) Requisitos no funcionais

Inclui vrios tipos de diagramas UML

Inclui vrios tipos de diagramas UML Esquema de banco de dados

intro-3 programa anterior

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\intro\intro3.htm

2. Fase de Planejamento e Elaborao

2. Fase de Planejamento e Elaborao

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\plan\index.htm

Estudo de caso: Terminal Ponto de Venda (PDV)

Estudo de caso: Terminal Ponto de Venda (PDV)

Introduzir o estudo de caso utilizado na disciplina

O Terminal de Ponto de Venda (PDV)

Nosso estudo de caso envolve um Terminal PDV

Arquitetura em camadas e nfase do estudo

Um sistema de informao tpico organizado usando as camadas apresentadas abaixo

As camadas arquiteturais apresentadas so:

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\plan\plan1.htm

Estudo de caso: Terminal Ponto de Venda (PDV)

Lgica de aplicao - Objetos do domnio de problema

Lgica de aplicao - Objetos de servio

plan-1 programa prxima

file://C:\_SYNC\_DISCIPLINAS\APOO\APOO Jacques UFCG\plan\plan1.htm

Fase de Planejamento e Elaborao

Breve descrio do sistema Descrio dos clientes alvo

Usaremos o estudo de caso (Terminal PDV) para exemplificar a obteno de requisitos