5º Semestre - Projeto de Sistemas Orientados Objeto

Curso Superior de
Sistemas para Internet
Projeto de Sistemas
Orientados a Objetos
Jos Incio Serafini
Cuiab 2011
Governo Federal
Ministro de Educao
Fernando Haddad
Ifes Instituto Federal do Esprito Santo
Reitor
Dnio Rebello Arantes
Pr-Reitora de Ensino
Cristiane Tenan Schlittler dos Santos
Coordenadora do CEAD Centro de Educao a Distncia
Yvina Pavan Baldo
Coordenadoras da UAB Universidade Aberta do Brasil
Yvina Pavan Baldo
Maria das Graas Zamborlini
Curso de Tecnologia em Anlise e Desenvolvimento de Sistemas
Coordenao de Curso
Isaura Nobre
Designer Instrucional
Danielli Veiga Carneiro / Jos Mrio Costa Jnior
Professor Especialista/Autor
Jos Incio Serafini
Catalogao da fonte: Rogria Gomes Belchior - CRB 12/417

S481p Serafini, Jos Incio
Projeto de sistemas. / Jos Incio Serafini. Vitria: Ifes, 2009.
149 p. : il.

1. Projeto de sistemas. 2. UML (Computao). 3. Anlise de sistemas. I.

Instituto Federal do Esprito Santo. II. Ttulo.

CDD 005.117
DIREITOS RESERVADOS
Ifes Instituto Federal do Esprito Santo
Av. Vitria Jucutuquara Vitria ES - CEP - (27) 3331.2139
Crditos de autoria da editorao
Capa: Juliana Cristina da Silva
Projeto grfico: Juliana Cristina da Silva / Nelson Torres
Iconografia: Nelson Torres
Editorao eletrnica: Duo Translations
Reviso de texto:
Ilioni Augusta da Costa
Maria Madalena Covre da Silva
COPYRIGHT proibida a reproduo, mesmo que parcial, por qualquer meio, sem autorizao escrita dos autores
e do detentor dos direitos autorais.
Tecnologia em Anlise e Desenvolvimento de Sistemas
Ol, Aluno(a)!
um prazer t-lo conosco.
O Ifes oferece a voc, em parceria com as Prefeituras e com o Governo
Federal, o Curso Tecnologia em Anlise e Desenvolvimento de Sistemas, na modalidade a distncia. Apesar de este curso ser ofertado
a distncia, esperamos que haja proximidade entre ns pois, hoje,
graas aos recursos da tecnologia da informao (e-mails, chat, videoconferncia, etc.), podemos manter uma comunicao efetiva.
importante que voc conhea toda a equipe envolvida neste curso:
coordenadores, professores especialistas, tutores a distncia e tutores
presenciais porque, quando precisar de algum tipo de ajuda, saber a
quem recorrer.
Na EaD Educao a Distncia, voc o grande responsvel pelo
sucesso da aprendizagem. Por isso, necessrio que se organize para
os estudos e para a realizao de todas as atividades, nos prazos estabelecidos, conforme orientao dos Professores Especialistas e Tutores.
Fique atento s orientaes de estudo que se encontram no Manual
do Aluno!
A EaD, pela sua caracterstica de amplitude e pelo uso de tecnologias
modernas, representa uma nova forma de aprender, respeitando,
sempre, o seu tempo.
Desejamos-lhe sucesso!
Equipe do Ifes
Projeto de Sistemas
ICONOGRAFIA
Veja, abaixo, alguns smbolos utilizados neste material para gui-lo em seus estudos.
Fala do Professor
Conceitos importantes. Fique atento!
Atividades que devem ser elaboradas por voc,

aps a leitura dos textos.
Indicao de leituras complemtares, referentes

ao contedo estudado.
Destaque de algo importante, referente ao

contedo apresentado. Ateno!
Reflexo/questionamento sobre algo importante referente ao contedo apresentado.
Espao reservado para as anotaes que voc

julgar necessrias.
PROJETO DE SISTEMAS
Cap. 1 - Reviso de UML 13
1.1. UML 13
1.2. Diagramas de UML 13
1.3. Que diagramas devo utilizar em meus projetos? 20
1.4. Diagrama de Casos de Uso 20
1.4.1. Modelagem de Contexto
23
1.4.2. Modelagem de Requisitos 23
1.5. Diagramas de Classes 24
1.5.1. Relaes entre classes 25
1.6. Diagrama de Objetos 28
1.7. Diagrama de Componentes 29
1.8. Diagrama de Deployment 32
1.9. Diagrama de Sequncia 33
1.10. Diagrama de Colaborao 34
Cap. 2. - O PROCESSO DE PROJETO

ORIENTADO A OBJETOS 37
2.1. Do Problema Codificao 37
2.2. Identificando as Classes 37
2.3. Identificando as Funcionalidades 38
2.4. Relacionamentos entre as Classes 39
2.5. Casos de Uso 40
2.5.1. Ligar para um ramal 40
2.5.2. Deixar uma mensagem 40
2.5.3. Entrar no sistema 40
2.5.4. Recuperar mensagens 41
2.5.5. Alterar senha 41
2.5.6. Alterar saudao 42
2.6. Cartes CRC 42
2.6.1. Como a tcnica? 44
2.7. Aplicando os CRC no projeto 45
2.8. Diagrama de classe UML 51
2.9. Diagramas de Sequncia 52
2.10. Concluso 53
Cap. 3 - Fundamentos de Projeto: Padres

GRASP 55
3.1. Introduo 55
Projeto de Sistemas
3.2. Os Padres GRASP 55

3.3. GRASP 1: EXPERT 56
3.3.1. Exemplo 56
3.4. GRASP 2: CREATOR 58
3.4.1. Exemplo 59
3.5. GRASP 3: HIGH COHESION 59
3.5.1. Exemplo 60
3.6. GRASP 4: LOW COUPLING 61
3.6.1. Exemplos 63
3.6.2. Lei de Demeter 64
3.6.3. Mais alguns conselhos para reduzir o
acoplamento: 64
3.7. GRASP 5: CONTROLLER 65
Cap. 4 - FUNDAMENTOS DE PROJETO:

HERANA X COMPOSIO 67
4.1. Introduo 67
4.2. Composio 67
4.3. Herana 68
4.3.1. Exemplo 68
4.3.2. Que fazer ento? 69
4.3.3. Quando Usar Herana? 70
4.3.4. Exemplo de Uso de Composio 70
4.3.5. Outro Exemplo 73
Cap. 5 - FUNDAMENTOS DE PROJETO:

INTERFACES 77
5.1. Reviso de Interfaces 77
5.2. Por Que Usamos Interfaces? 78
5.3. Onde Aplicar Interfaces? 80
5.3.1. Para Fatorar Componentes Repetitivos 80
5.3.2. Para Fatorar os Componentes para um
Proxy (Agente) 84
5.3.3. Para Fatorar os Componentes de
Aplicativos Semelhantes 89
5.3.4. Para Fatorar para Expanso Futura 92
Cap. 6 - PADRO STRATEGY 97

6.1. Definio Oficial 97
6.2. Problema 97
6.2.1. Na Anlise: 97
6.2.2. No Projeto: 97
6.2.3. Ateno 97
6.3. Soluo 98
6.4. Diagrama UML 98
6.4.1. Participantes e Colaboradores 98
6.5. Observaes 98
6.6. Implementao 99
6.7. Exerccios 100
Cap. 7 - PADRO OBSERVER OU PUBLISH/

SUBSCRIBE 101
7.2. Problema 101
7.2.1. Na Anlise 101
7.2.2. No Projeto 101
7.2.3. Ateno: 101
7.3. Soluo 102
7.5. Observaes 102
7.6. Implementao 103
7.7. Exerccios 104
Cap. 8 - PADRO DECORATOR 105

8.2. Problema 105
8.2.1. Na Anlise: 105
8.2.3. Ateno: 105
8.3. Soluo 106
8.5. Observaes 106
8.7. Exerccios 108
Cap. 9 - PADRO FACTORY METHOD 109

9.2. Problema 109
9.2.1. Na Anlise: 109
9.3. Soluo 109
Projeto de Sistemas

9.6. Exerccios 111
Cap. 10 - PADRO SINGLETON 113

10.2. Problema 113
10.2.1. Na Anlise: 113
10.2.2. No Projeto: 113
10.3. Soluo 113
10.6. Exerccios 115
Cap. 11 - PADRO COMMAND 117

11.2. Problema 117
11.5. Exerccios 120
Cap. 12 - PADRO ADAPTER 121

12.2. Problema 121
12.2.1. Na Anlise: 121
12.2.2. No Projeto: 121
12.3. Soluo 121
12.6. Exerccios 123
Cap. 13 - PADRO FAADE 125

13.2. Problema 125
13.2.1. Na Anlise: 125
13.2.2. No Projeto: 125
13.2.3. Ateno: 125
13.3. Soluo 126

13.6. Exerccios 127
Cap. 14 - PADRO TEMPLATE METHOD 129

14.2. Problema 129
14.2.1. Na Anlise: 129
14.2.2. No Projeto: 129
14.2.3. Ateno: 129
14.3. Soluo 130
14.6. Exerccios 131
Cap. 15 - PADRO ITERATOR 133

15.2. Problema 133
15.2.1. Na Anlise: 133
15.2.2. No Projeto: 133
15.2.3. Ateno: 133
15.3. Soluo 133
15.6. Exerccios 135
Cap. 16 - PADRO COMPOSITE 137

16.2. Problema 137
16.2.1. Na Anlise: 137
16.2.2. No Projeto: 137
16.2.3. Ateno: 137
16.3. Soluo 138
16.6. Exerccios 140
Cap. 17 - PADRO STATE 141

17.2. Problema 141
Projeto de Sistemas
10
17.2.1. Na Anlise: 141

17.2.2. No Projeto: 141
17.2.3. Ateno: 141
17.3. Soluo 142
17.6. Exerccios 144
Cap. 18 - PADRO PROXY 145

18.2. Problema 145
18.2.1. Na Anlise: 145
18.2.2. No Projeto: 145
18.2.3. Ateno: 146
18.3. Soluo 146
18.6. Exerccios 148
REFERNCIAS BIBLIOGRFICAS 149
11
APRESENTAO
Ol,
Neste curso voc vai aprimorar seus conhecimentos sobre o desenvolvimento de software.
Vamos estudar com mais profundidade os aspectos da fase de projeto de sistemas.
O que vamos estudar neste curso resumidamente como estabelecer a colaborao entre os objetos de nosso sistema. Essa tarefa
que torna um sistema melhor do que outro do ponto de vista do
desempenho e da sua expanso e atualizao.
O que vamos estudar pode ser considerado como uma verdadeira
carga de experincia profissional.
Vamos examinar algumas questes prticas de projeto de sistemas que serviro como regras que voc poder aplicar em seus
futuros projetos.
Aproveite e faa todos os exerccios e participe das discusses
nos fruns.
No final deste documento voc conhecer a bibliografia recomendada para nossa disciplina.
Projeto de Sistemas
12
13
Reviso de UML
Ol,
Neste captulo vamos fazer uma reviso de alguns conceitos importantes de UML (Unified Modelling Language Linguagem
Unificada de Modelagem).
1.1. UML
UML (Unified Modelling Language Linguagem Unificada de Modelagem) uma linguagem de modelagem que utilizamos para criar modelos de sistemas.
Na maioria das vezes o diagrama de classes considerado o diagrama
mais importante, porm no devemos esquecer que ele apenas uma
representao esttica do sistema. Existem outros diagramas muito importantes que tambm demonstram a dinmica do sistema.
Uma das caractersticas mais importantes de UML que ela independente da linguagem de programao utilizada no projeto.
Outro fato importante que a UML uma linguagem padronizada pela
ISO (International Standard Organization) e capaz de modelar qualquer
tipo de problema, no s os problemas de Sistemas de Informao.
1.2. Diagramas de UML

Os diagramas de UML podem ser divididos em 2 grupos:
Estticos aqueles que representam os elementos do sistema
sem demonstrar o fluxo das informaes e as alteraes ocorridas no sistema;
Dinmicos aqueles que mostram o fluxo das informaes e
as mudanas de estado do sistema.
Projeto de Sistemas
14
Captulo 1
Veja na Figura 1 os diagramas e sua diviso:
Figura 1 Diagramas da UML
Vamos dar uma olhada nesses diagramas.

Diagramas Estticos

Diagrama de Classes
Mostra as classes, interfaces, colaborao e os seus relacionamentos.

So os diagramas mais comuns e fornecem uma viso geral e esttica
do projeto (Figura 2).
Figura 2 - Exemplo de Diagrama de Classes

Reviso de UML
Diagrama de Objetos
um diagrama de instncias das classes mostradas no diagrama de classes. Mostra as instncias e como elas se relacionam entre si. Fornece
uma viso de casos reais (Figuras 3 e 4).
Figura 3 Diagrama de Objetos
Figura 4 Diagrama de Objetos
Diagrama de Componentes
Mostra a organizao dos componentes do sistema. Um componente corresponde a uma ou a vrias classes, interfaces ou colaboraes (Figura 5).
Projeto de Sistemas
15
16
Captulo 1
Figura 5 - Exemplo de Diagrama de Componentes
Diagrama de Deployment
Mostra os ns e suas relaes. Um n um conjunto de componentes.

Esses diagramas so utilizados para reduzir a complexidade dos diagramas de classes e componentes de sistemas complexos. Serve como um
resumo e ndice destes diagramas (Figura 6).
Figura 6 - Exemplo de Diagrama de Deployment
Reviso de UML
Diagramas Dinmicos

Diagramas de sequncia e diagramas de colaborao
Mostram os diferentes objetos e suas relaes, e tambm as mensagens

que so trocadas entre eles. So diagramas com as mesmas informaes,
porm com formatos diferentes. So chamados tambm de diagramas
de interao (Figuras 7 e 8).
Figura 7 - Exemplo de Diagrama de Sequncia
Figura 8 - Exemplo de Diagrama de Colaborao
Projeto de Sistemas
17
18
Captulo 1
Diagrama de Estado
Mostra os estados, eventos, transies e atividades dos objetos. So muito teis para o projeto de sistemas que reagem a eventos e tambm no
projeto da interface grfica com o usurio (GUI), conforme Figura 9.
Figura 9 - Exemplo de Diagrama de Estados
Diagrama de Atividades
Mostra o fluxo de informaes entre objetos. til para modelar o funcionamento do sistema e o fluxo de controle entre objetos (Figura 10).
19
Reviso de UML
Figura 10 - Exemplo de Diagrama de Atividades
Veja no Quadro 1 os diagramas mais utilizados em cada fase do

projeto:
Casos
de
uso
Casos
Classes Objetos
Sequncia
Colaborao
Estado
Atividades
Compo- Deployment
nentes
de Uso
Projeto
Processos
Implementao
Deployment
Quadro 1 O uso de diagramas X fases do projeto
Projeto de Sistemas
X
X
20
Captulo 1
1.3. Que diagramas devo utilizar em meus

projetos?
Nem todos os projetos precisam dos 9 tipos de diagramas de UML.
Minha sugesto que voc utilize o quadro abaixo para

seus projetos.
Casos
de
uso
Classes Objetos
Sequncia
Colaborao
Sistemas
Simples
Sistemas
Simples
com
entradas
de dados
complexas
Cliente /
Servidor
Sistemas
Web
Sistemas
Complexos
Estado
Atividades
Compo- Deployment
nentes
1.4. Diagrama de Casos de Uso

So utilizados para visualizar o comportamento do sistema.
Geralmente um caso de uso especifica um requisito funcional.
Nos diagramas temos os seguintes smbolos:
Representado por uma elipse.

Cada Caso de Uso deve conter um nome que indique a sua
funcionalidade.
Reviso de UML
Os casos de uso podem ter relacionamentos com outros casos de uso

(Include, Extend, Generalizao):
Include: representado por uma seta:
Extend: Uma relao de caso de uso A para caso de uso B,

indica que o caso de uso B implementa a funcionalidade do
caso de uso A.
Generalizao: um tipo de herana e a notao a mesma de Extends.
Atores so representados pelo desenho de um boneco.

Eles podem se comunicar com casos de uso ou com outros atores.
Projeto de Sistemas
21
22
Captulo 1
O limite do sistema (System Boundary) representado por um quadro

que envolve os casos de uso.
Veja um exemplo de Diagrama de Casos de Uso na figura 11.
Figura 11- Exemplo de Diagrama de Casos de Uso
Neste exemplo temos 3 casos de uso:

Criar Roteiro: utiliza Validar Roteiro;
Validar Roteiro;
Criar Pacote de Roteiro: uma generalizao de Criar Roteiro.
Reviso de UML
Podemos utilizar o diagrama para:

modelar o contexto do sistema e
modelar os requisitos do sistema.
1.4.1. Modelagem de Contexto

Os elementos externos e sua relao com o sistema formam o contexto
do sistema.
Utilizamos os seguintes passos para modelar o contexto de um sistema:
1. identificao dos Atores que interagem com o sistema;
2. organizao dos Atores; e
3. especificao das formas de comunicao com o sistema.
1.4.2. Modelagem de Requisitos

A principal funo do Diagrama de Casos de Uso documentar os requisitos do sistema.
Os requisitos estabelecem um contrato entre o sistema e os Atores. Definem o que se espera que o sistema realize sem definir o seu funcionamento interno.
Para modelar os requisitos recomendvel:
estabelecer o contexto para o qual tambm podemos utilizar
os diagramas de casos de uso;
identificar as necessidades dos atores;
dar um nome s necessidades e escreve-lo no formato de Casos de Uso;
identificar que Casos de Uso podem ser especializaes de
outros, ou buscar especializaes comuns para os Casos de
Uso j encontrados.
Projeto de Sistemas
23
24
Captulo 1
1.5. Diagramas de Classes

Nos Diagramas de Classes definimos as caractersticas de cada uma das
classes, interfaces, colaboraes e relaes de dependncia e generalizaes existentes no sistema.
A classe representada por um retngulo que contm 3 partes, conforme Figura 12. Na parte superior indicamos o nome da classe, na parte
do meio os atributos e na parte de baixo os mtodos.
Figura 12 - Smbolo de uma Classe em UML
Cada classe deve ter um nico nome que a diferencia das outras classes.
Um atributo representa alguma propriedade da classe que se encontra em
todas as instncias da classe. Os atributos podem ser representados por
seu nome, seu nome e tipo ou ainda por seu nome, tipo e valor default.
Um mtodo ou operao a implementao de um servio da classe que mostra um comportamento comum a todos os objetos daquela classe. Resumindo:
uma funo que indica s instncias da classe que faam alguma coisa.
Veja um exemplo de uma classe na Figura 13.
Figura 13 - Exemplo de uma classe

Reviso de UML
Neste exemplo a classe Cliente possui 3 atributos:

nome: tipo char e visibilidade public;
endereo: tipo char e visibilidade private;
status: tipo int, valor inicial 0 e visibilidade protected.
A classe Cliente tambm possui 3 mtodos:
incluir: visibilidade public;
excluir: visibilidade private;
consultar: visibilidade protected.
1.5.1. Relaes entre classes
Nas relaes temos uma classe destino e uma classe origem. Na origem
se realiza a ao de relacionar, isto , graficamente falando, de onde
parte a flecha. O destino quem recebe a flecha. Podemos modificar as
relaes com esteretipos ou com restries.
Existem 3 tipos de relaes entre classes:
Dependncia,
Generalizao e
Associao.
a) Dependncia
uma relao de uso, isto , uma classe usa a outra. representada por
uma seta tracejada que vai da classe utilizadora classe utilizada.
Com a dependncia uma alterao ocorrida na classe utilizada pode

afetar o funcionamento da classe utilizadora, porm, o contrario pode
no ser verdadeiro.
Projeto de Sistemas
25
26
Captulo 1
Os tipos de dependncias que podem ocorrer entre as classes so:

Bind: a classe utilizadora necessita de parmetros para ser utilizada.
Com bind indicamos que essa classe se instancia com os parmetros
necessrios, passando dados reais para seus parmetros.
Derive: utilizamos para indicar relaes entre dois atributos, indica
que o valor de um atributo depende diretamente do valor de outro.
Por exemplo: o atributo idade depende diretamente do atributo data
de nascimento.
Friend: especifica uma visibilidade especial sobre a classe relacionada. Isto , ela poder ver o interior da classe destino.
Instance of: indica que o objeto origem uma instncia do
destino.
Instantiate: indica que a origem cria instncias do destino.
PowerType: indica que o destino contm objetos da origem.
Refine: indica que uma chave a mesma que outra, porm, mais
refinada, isto , duas vises da mesma classe, a destino com maior
nvel de detalhes.
b) Generalizao
o relacionamento em que uma classe Filha (subclasse) tambm uma
instncia indireta da classe Pai (superclasse). similar ao conceito de Herana em Programao Orientada a Objetos. Ou seja, a classe especfica
(Filha) tem, indiretamente, as caractersticas da classe mais geral (Pai).
representada por uma linha contnua com uma seta triangular grande
da classe Filha (subclasse) para a classe Pai (superclasse).
Reviso de UML
Implementao: o filho herda a implementao do pai, sem publicar

nem suportar suas interfaces.
Restries de Generalizao:
Complete: a generalizao no permite mais filhos
Incomplete: podemos incorporar mais filhos generalizao
Disjoint: s pode ter um tipo em tempo de execuo. Uma
instncia do pai s poder ser de um tipo de filho.
Overlapping: pode mudar de tipo durante a sua vida. Uma
instncia do pai pode ir mudando de tipo entre os seus filhos.
c) Associao
Especifica que os objetos de uma classe esto relacionados aos elementos de outra classe.
representada por uma linha contnua que une as duas classes. Podemos indicar o nome da associao e sua multiplicidade nos extremos da
linha (Figura 14).
Figura 14 Associaes em um diagrama de classes com representao

da multiplicidade
Projeto de Sistemas
27
28
Captulo 1
A Figura 15 mostra um exemplo dos tipos de relaes entre classes

em UML.
Figura 15- Associaes em um diagrama de classes
No exemplo da Figura 14 temos quatro classes.

A classe principal Usurio, que possui duas classes filhas: Usurio Administrativo e Usurio Interno.
A classe Usurio mantm uma relao de associao com a classe Senha, indicada pela descrio proprietrio de uma ou mais Senha(s).
Tambm temos uma relao de dependncia com a classe Arquivo. Isso
significa que as instncias de Usurio (e seus herdeiros) iro conter um
nmero no definido de Arquivos(s).
1.6. Diagrama de Objetos

um dos diagramas estticos do sistema. Esse diagrama modela as instncias de classes do Diagrama de Classes.
Ele mostra os objetos e suas relaes, porm em um momento concreto do
sistema. Esse diagrama contm objetos e enlaces. Nos diagramas de objetos tambm podemos incorporar a classe da qual o objeto derivado.
Nesse diagrama mostramos um estado do diagrama de eventos. Para realizar o diagrama de objetos, primeiro devemos decidir qual a situao
do sistema que queremos representar. A Figura 16 mostra um exemplo
de um diagrama de objetos. Nela aparece um objeto Cliente em uma
instncia especfica, com seus respectivos pedidos, que esto com status
completo e aberto.
29
Reviso de UML
Figura 16 Exemplo de Diagrama de Objetos
1.7. Diagrama de Componentes

utilizado para a modelagem esttica do sistema.
Mostra a organizao e as dependncias entre um conjunto de componentes de software.
No necessrio que um diagrama inclua todos os componentes do sistema. Esses diagramas geralmente so construdos por partes, com cada
diagrama descrevendo uma parte do sistema.
Nos diagramas de componentes situamos as bibliotecas, arquivos, tabelas, cdigo executvel e documentos que formam o sistema.
Um dos usos principais dos Diagramas de Componentes servir para a
anlise de quais componentes podem ser compartilhados entre sistemas
ou entre diferentes partes do sistema.
Veja na Figura 17 o smbolo que utilizamos em UML para representar
um componente:
Figura 17 - Componente user32.dll mostrado

com notao UML
Nesse exemplo temos um componente do MS-Windows chamado

uswer32.dll.
No diagrama de componentes do Windows deve existir esse componente, j que sem ele o sistema no ir funcionar.
Projeto de Sistemas
30
Captulo 1
No exemplo da Figura 18, temos o mesmo componente, porm com a

indicao de que dispe de uma interface. Como ele uma DLL, a interface nos d acesso a seu contedo.
Figura 18 Componente com uma interface
A representao anterior (Figura 17) est em um nvel de detalhamento

menor, por isso ela diferente da representao da Figura 18.
Voc deve recordar que todos os objetos UML podem ser modificados
mediante esteretipos. Os esteretipos padro em UML so:
Executable;
Library;
Table;
File;
Document.
Voc pode criar seus prprios esteretipos. Por exemplo, voc pode
criar esteretipos de componentes ASP, HTML, XML, scripts, e utilizar
em seus modelos.
Na Internet possvel achar vrios esteretipos interessantes, como o

WAE (Web Applications Extensions).
Podemos modelar diferentes partes de nosso sistema e tambm modelar

diferentes entidades que no possuem nenhum relacionamento entre si,
por exemplo: Executveis e Bibliotecas e Cdigo Fonte.
O Modelo Executveis e Bibliotecas facilita a distribuio de componentes aos clientes. Ele documenta suas necessidades e dependncias.
31
Reviso de UML
Se dispusermos de um executvel que s necessita dele mesmo para a

execuo, no necessitaremos de um diagrama de componentes.
Os passos a serem seguidos para se modelar Executveis e Bibliotecas
a priori (no a posteriori!) so:
1. identificar os componentes, as parties do sistema, e especificar quais delas so factveis de serem reutilizadas. Agruplas por ns e realizar um diagrama para cada n que queremos
modelar;
2. identificar cada
correspondente;
componente
com
seu
esteretipo
3. considerar as relaes entre componentes.

Na Figura 19, temos um executvel que utiliza duas bibliotecas e essas
duas bibliotecas dispem de suas interfaces, que permitem o acesso a
seus servios. Podemos observar tambm que essas bibliotecas so componentes que podem ser reutilizados em outras partes do sistema
O modelo Cdigo Fonte utilizado para documentar as dependncias

entre os diferentes arquivos do cdigo fonte.
Um executvel ou biblioteca uma combinao desses arquivos e, ao
mostrar a dependncia entre elas, obteremos uma viso das partes necessrias para a criao do executvel ou biblioteca.
Ao documentarmos as relaes, podemos realizar mudana no cdigo
de um arquivo levando em conta onde ele utilizado e que outros arquivos podem ser afetados por sua modificao.
Projeto de Sistemas
32
Captulo 1
No exemplo mostrado na Figura 20, temos as relaes entre os diferentes arquivos de um sistema. Cada arquivo cpp utiliza seu arquivo .h
correspondente e meuServico.h utiliza NTService.h e stdio.h.
Alm desses modelos, ainda outros que no possuem entidades com

relacionamento explcito entre si podem ser desenvolvidos, tais como:
tabelas, APIs e pginas HTML.
1.8. Diagrama de Deployment

No diagrama de deployment, indicamos a disposio fsica dos componentes lgicos do sistema. Isto , alocamos o software no hardware,
indicamos o que se vai executar e onde ser executado.
Cada hardware representado por um n. Um n representado como
um cubo e onde os componentes so executados.
No exemplo da Figura 21 temos dois ns: o n Cliente e o n Servidor.
Cada um deles contm componentes. O componente do Cliente utiliza
uma interface de um dos componentes do Servidor. Observe que a relao mostrada no diagrama. Essa relao entre o Cliente e o Servidor
poderia ser associada a um esteretipo para indicar de que tipo de conexo dispomos entre eles. Poderamos mostrar tambm a cardinalidade
para indicar que um Servidor suporta diversos Clientes.
Reviso de UML
Figura 21 Diagrama de Deployment
Como um componente pode residir em mais de um n, podemos utilizar o componente de forma independente, sem que pertena a nenhum
n especfico, e relacion-lo com os ns nos quais ele pode residir.
1.9. Diagrama de Sequncia

O diagrama de sequncia faz parte da modelagem dinmica do sistema.
Nesses modelos as trocas de mensagens (ou chamadas de mtodos) entre as classes so mostradas desde um ponto concreto no sistema.
Esse diagrama extremamente til para se observar a vida dos objetos
no sistema, identificar as mensagens a serem realizaadas ou ainda descobrir erros de modelagem esttica que impossibilitem o fluxo de informaes ou de chamadas de mtodos entre componentes do sistema.
No diagrama de sequncia mostrada a ordem das chamadas de mtodos no sistema.
Utilizamos um diagrama para cada chamada que deve ser representada. impossvel representar em um nico diagrama de sequncia todas
as possveis de chamadas do sistema, para isso escolhemos um ponto
de partida e representamos apenas a seqncia dessa chamada. Em seguida, escolhemos outro ponto de partida e escrevemos sua seqncia.
Devemos repetir esse procedimento at que todas as chamadas a serem
representadas tenham sido contempladas.
O diagrama se forma com os objetos que fazem parte da sequncia e
estes se situam na parte superior do diagrama. Quem inicia a ao se
situa esquerda do diagrama. Desse objeto sai uma linha vertical traProjeto de Sistemas
33
34
Captulo 1
cejada que indica sua vida no sistema. Essa linha simples se converte
em uma linha grossa quando representa que o objeto tem o foco do
sistema, isto , quando est ativo.
No diagrama da Figura 22 temos 3 objetos e um ator, situado esquerda, que quem inicia a ao. Como se pode ver, o objeto mais
direita aparece mais embaixo que os outros existentes, pois ele ser
criado por uma mensagem de criao. Observe tambm a mensagem
para a destruio do Objeto 3.
A mensagen4() uma mensagem para o mesmo objeto, isto , uma
mensagem para um mtodo interno.
Figura 22 Exemplo de Diagrama de Sequncia
1.10. Diagrama de Colaborao

Os diagramas de colaborao contm as mesmas informaes que os
diagramas de sequncia.
A utilizao de um ou outro uma questo de preferncia pessoal.
Na Figura 23 vemos um exemplo de um Diagrama de Colaborao. Cada
objeto que possua visibilidade para outro tem uma linha ligando os dois. As
mensagens fluem por essas linhas. Dito de outra forma: se uma linha liga
dois objetos, eles podem enviar mensagens. O sentido das mensagens vai
indicar qual o tipo de visibilidade a ser utilizado na implementao.
Reviso de UML
Figura 23 Exemplo de Diagrama de Colaborao
LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao projeto orientados a objetos e ao desenvolvimento iterativo. Trad. Rosana Vaccare Braga et al. 3ed. Porto
Alegre: Bookman, 2007.
Projeto de Sistemas
35
36
Captulo 1
37
O PROCESSO DE PROJETO
ORIENTADO A OBJETOS
2.1. Do Problema Codificao

Podemos dividir o processo de desenvolvimento de software em 3 fases:
Anlise;
Projeto;
Implementao.
Na Anlise procuramos entender o problema e escrever uma especificao do sistema a ser desenvolvido.
No Projeto vamos identificar as classes e atribuir responsabilidades a
elas. Alm disso, identificamos os relacionamentos entre as classes.
Na Implementao, vamos criar o cdigo executvel da aplicao.
Vamos examinar agora este processo de projeto em um sistema de

correio de voz. Voc vai encontrar esse exemplo com o cdigo Java
correspondente no livro: Padres e Projeto Orientado a Objetos
Cray Hortsmann Cap. 2 Ed. Bookman.
2.2. Identificando as Classes

Uma descrio sucinta do sistema :
Em um sistema de correio de voz, uma pessoa disca para um nmero de
ramal e, se ningum atender, deixa uma mensagem. Cada usurio vai
possuir uma caixa postal. O destinatrio pode recuperar mensagens mais
tarde, guard-las ou elimin-las, para isso basta informar uma senha ao
entrar no sistema. As tarefas que podem ser realizadas pelo usurio so
tocadas em um menu sonoro. O usurio poder alterar sua senha e a
saudao de sua caixa postal.
Projeto de Sistemas
38
Captulo 2
A 1. regra para se identificar as classes numa descrio : encontre

os substantivos.
Assim, ao examinarmos a descrio do sistema encontramos os seguintes substantivos:
Em um sistema de correio de voz, uma pessoa disca para um numero de
De nossa anlise no texto temos as seguintes classes candidatas:
Usurio: Pessoa ou Destinatrio;
Caixa Postal;
Mensagem;
Ramal;
Senha;
Menu.
Dica: quando escolhemos as classes devemos nos precaver de detalhar demasiadamente o projeto.
Por exemplo: em um sistema para uma loja de eletrodomsticos, poderamos obter os conceitos Eletrodomsticos, Geladeira, Fogo, etc.
Mas observe que esta hierarquia pode ser considerada irrelevante para
o problema, que : vender, fazer pedidos, reservar, dar baixa nos eletrodomsticos, sem distino. Assim, o mais indicado trabalhar apenas
com o conceito Eletrodomsticos.
2.3. Identificando as Funcionalidades

Em seguida vamos examinar as funcionalidades necessrias.
A 2. regra para se identificar as funcionalidades na descrio acima :
encontre os verbos.
O Processo de Projeto Orientado a Objetos
Examinamos a descrio do sistema e encontramos:

Em um sistema de correio de voz, uma pessoa disca para um numero de
Da anlise do texto, encontramos as seguintes funcionalidades:
Ligar para um ramal;
Deixar uma mensagem;
Recuperar mensagens;
Entrar no sistema;
Alterar senha;
Alterar saudao.
comum usarmos o termo Responsabilidade como sinnimo de funcionalidade durante essa anlise.
Dica: Cada responsabilidade (ou funcionalidade) est relacionada

a somente uma classe.
2.4. Relacionamentos entre as Classes

Os relacionamentos que detectamos em nosso exemplo so:
o sistema de correio possui caixas postais;
uma caixa postal possui duas filas de mensagens;
uma fila de mensagens possui mensagens;
uma conexo possui uma caixa postal corrente.
Projeto de Sistemas
39
40
Captulo 2
2.5. Casos de Uso

Com as funcionalidades podemos escrever os seguintes casos de uso:
2.5.1. Ligar para um ramal
1. Usurio disca o nmero principal do sistema de correio de voz.
2. O sistema responde: Entre com o nmero da caixa postal,
seguido de #.
3. O usurio digita o nmero do ramal e #.
4. O sistema responde: Voc se conectou caixa postal XXXX.
Por favor, deixe sua mensagem.
2.5.2. Deixar uma mensagem
1. Usurio executa Ligar para um ramal.
2. Usurio grava a mensagem.
3. Usurio desliga.
4. O sistema armazena a mensagem gravada na caixa postal.
2.5.3. Entrar no sistema
1. O dono da caixa postal executa Ligar para um ramal.
2. O dono da caixa postal digita a senha seguida da tecla #.
(Senha default = nmero da caixa postal. Para alterar a senha
veja Trocar de senha)
3. O sistema toca o menu:
Entre 1 para recuperar suas mensagens.
Entre 2 para trocar a sua senha.
Entre 3 para trocar a saudao.
2.5.4. Recuperar mensagens

1. O dono da caixa postal executa Entrar no sistema (Log in)
2. O dono da caixa postal seleciona a opo de menu recuperar
suas mensagens

Pressione 1 para escutar a mensagem corrente.

Pressione 2 para salvar a mensagem corrente.
Pressione 3 para eliminar a mensagem corrente.
Pressione 4 para retornar ao menu da caixa postal.
4. O dono da caixa postal seleciona a opo escutar mensagem

corrente.
5. O sistema toca a mensagem corrente nova, ou, se no existirem novas mensagens, a mensagem corrente antiga.
Nota: A mensagem tocada, e no removida da fila.
6. O sistema toca o menu de mensagens.
7. O usurio seleciona eliminar mensagem corrente. A mensagem removida de forma permanente.
8. Continua no passo 3.
a) Variao #1
1.1. Inicie no passo 6
1.2. Usurio seleciona salvar a mensagem corrente.
A mensagem removida da fila e acrescentada na fila de
mensagens velhas.
1.3. Continua no passo 3.
2.5.5. Alterar senha
1. O dono da caixa postal executa Entrar no sistema (Log in).
2. O dono da caixa postal seleciona a opo alterar senha.
3. O dono da caixa postal digita a nova senha.
4. O dono da caixa postal pressiona a tecla #.
5. Sistema armazena a nova senha.
Projeto de Sistemas
41
42
Captulo 2
a) Variao #1: Desligar antes da confirmao

1.1. Inicie no passo 3.
1.2. O dono da caixa postal desliga o telefone.
1.3. Sistema mantm a senha antiga.
2.5.6. Alterar saudao

1. O dono da caixa postal executa Entrar no sistema (Log in).
2. O dono da caixa postal seleciona a opo alterar saudao.
3. O dono da caixa postal grava a nova saudao.
4. O dono da caixa postal pressiona a tecla #.
5. Sistema ativa a nova saudao.
a) Variao #1: Desligar antes da confirmao

1.1. Inicie no passo 3.
1.2. O dono da caixa postal desliga o telefone.
1.3. Sistema mantm a saudao antiga.
2.6. Cartes CRC

Os cartes CRC so uma ferramenta simples e eficiente para nossos
projetos.
CRC a abreviatura de Class-Responsibility-Collaborator ou em portugus: Classe-Responsabilidade-Colaborador.
Foram criados por Kent Beck e Ward Cunningham em 1989 e apresentados em um artigo intitulado A Laboratory for Teaching ObjectOriented Thinking.
O artigo A Laboratory for Teaching Object-Oriented Thinking facilmente encontrado em vrios links na Internet. Vale a pena conhec-lo!
Um carto CRC dividido em3 partes:

Classe
Responsabilidades
Colaboradores
A Classe uma coleo de objetos.

Responsabilidade qualquer coisa que a classe conhece ou realiza. Por exemplo: a classe Aluno possui a responsabilidade de conhecer o nome do aluno e
seu curso.
Colaborador representa outra classe que utilizada para obter informaes
necessrias a uma responsabilidade da classe.
Para realizar uma sesso CRC envolvemos trs elementos importantes:
Clientes: que conhecem o domnio do negcio;

Desenvolvedores: que conhecem a tcnica de modelagem CRC;
Facilitador: para garantir a realizao da reunio de forma
produtiva.
Observaes:
Para grupos de at 5 pessoas o facilitador opcional;
Sempre que possvel inclua uma pessoa dedicada a anotar as
discusses do grupo, chamamos essa pessoa de Escriba (nome
dado queles que sabiam escrever nos tempos antigos e eram
responsveis pelos registros do povo);
Pode ser interessante incluir no grupo Observadores para
aprenderem a tcnica. Esses observadores devem permanecer
em silncio durante todo o processo.
Projeto de Sistemas
43
44
Captulo 2
O nmero de participantes deve ser:

Cliente: 3 a 6 pessoas;
Desenvolvedor: 1 a 3 pessoas;
Facilitador: 1 pessoa.
A reunio deve ser realizada em uma sala de reunies ou numa sala
qualquer com uma mesa grande em que todos possam fazer contato
visual com os demais componentes do grupo.
ainda necessrio:
cartes de 8x13 ou 13x18 (ou Post-It do mesmo tamanho);
canetas coloridas;
quadro branco;
papel para anotaes;
e demais itens que garantam o conforto dos participantes para
executarem o trabalho.
2.6.1. Como a tcnica?
Inicialmente o Facilitador deve explicar o objetivo da sesso CRC para os participantes que no a conhecem.
Em seguida selecionamos os cenrios que sero tratados na sesso. Pode ser
feito um brainstorm para a escolha dos cenrios a serem utilizados na sesso e
sua ordem de tratamento.
Para facilitar o incio do trabalho, procure iniciar a sesso com os

cenrios mais simples.
Selecionado o cenrio, criamos um carto CRC para cada classe do cenrio e colocamos estes cartes CRC no centro da mesa de reunies.
Em seguida, percorremos os passos do cenrio procurando responder a
pergunta: de quem a responsabilidade deste passo?
Anotamos a resposta na coluna Responsabilidade da classe responsvel.

A prxima pergunta ser: Quem pode ajudar essa classe a realizar a tarefa?
Anotamos a resposta na coluna Colaborador da classe.
Observaes:
Podemos descobrir novas classes durante esse processo.
As classes do tipo Interface podem ser ignoradas.
2.7. Aplicando os CRC no projeto

Utilizamos os Cartes CRC fazendo um walkthroughs nos casos de
uso e atribuindo s classes as responsabilidades e colaboraes.
Iniciamos criando os cartes CRC para as classes encontradas:
Caixa Postal;
Mensagem;
Sistema de Correio.
A principal tarefa da Caixa Postal ser armazenar mensagens, indicando
quais mensagens so novas e quais mensagens esto salvas. Ela vai permitir que o Usurio possa recuperar, salvar e eliminar as suas mensagens.
Para realizar essa tarefa, vamos utilizar uma fila para armazenar as mensagens. Na realidade vamos utilizar duas filas para armazenar as mensagens:
uma para as mensagens novas e outra para as mensagens armazenadas.
Assim precisaremos de uma classe para representar essa Fila: Fila de Mensagens, que ir implementar uma fila do tipo FIFO (first in, first out).
A classe Sistema de Correio quem vai gerenciar as caixas postais.
Assim podemos escrever nossos cartes CRC:
Caixa Postal
Gerenciar as mensagens novas e Fila de Mensagens
armazenadas
Projeto de Sistemas
45
46
Captulo 2
Mensagem
Sistema de Correio
Gerenciar caixas postais
Fila de Mensagens
Gerenciar mensagens por meio de
uma fila FIFO
Podemos ento realizar a tcnica para nossos casos de uso.

Em seguida vamos examinar como processamos as entradas e sadas
do sistema. Vamos criar uma classe Telefone para representar o telefone real. Essa classe ter duas responsabilidades: capturar as entradas do
usurio e tocar as mensagens gravadas.
Telefone
Capturar as entradas do usurio
Tocar as mensagens gravadas
Outra observao importante que Telefone est conectado ao Sistema

de Correio. Criamos uma classe Conexo para essa representao. Assim, podemos ter vrias conexes ativas no sistema simultaneamente.
As responsabilidades da Conexo so: receber as entradas do Telefone,
tratar os comandos e manter o estado da conexo. A classe Conexo
colabora com Telefone e Sistema de Correio.
47
Conexo
Receber as entradas de telefone
Tratar os comandos
Manter o estado da conexo
Vamos agora examinar o Caso de Uso Deixar uma Mensagem

1. Usurio disca o nmero principal do sistema de correio de voz.

A classe Telefone envia o nmero do ramal para a

classe Conexo.
Acrescentar Conexo como colaboradora de Telefone.
Colocar os cartes CRC Telefone e Conexo prximos.
2. O sistema responde: Entre o nmero da caixa postal,

seguido de #.
3. O usurio digita o nmero do ramal e #.

A classe Conexo solicita a Sistema de Correio o objeto

Caixa Postal correspondente ao ramal.
Colocar os cartes CRC Sistema de Correio, Caixa Postal

prximos de Conexo.
Essa ao esta includa na responsabilidade gerenciar

caixa postal.
4. O sistema responde: Voc conectou a caixa postal XXXX. Por

favor deixe sua mensagem.

A classe Conexo solicita a Sistema de Correio a saudao.
Acrescentar a responsabilidade de gerenciar saudao a

Caixa Postal.
Caixa Postal ser colaborador de Conexo.
A classe Conexo solicita a Telefone que toque a saudao.
Projeto de Sistemas
48
Captulo 2
5. Usurio grava a mensagem.

A classe Telefone solicita que a classe Conexo

grave a mensagem.
Conexo recebe a responsabilidade de gravar a mensagem.
6. Usurio desliga.
Telefone notifica Conexo.

A classe Conexo cria um objeto Mensagem que contm

a mensagem gravada.
Mensagem colaborador de Conexo.
Mensagem tem a responsabilidade de gerenciar contedo

da Mensagem.
7. Sistema armazena a mensagem gravada na caixa postal.

Conexo adiciona o objeto Mensagem a Caixa Postal.
Aps a anlise desse caso de uso, os cartes CRC ficam assim:
Telefone
Capturar as entradas do usurio
Conexo
Tocar as mensagens gravadas
Conexo
Receber as entradas de telefone
Telefone
Tratar os comandos
Sistema de Correio
Manter o estado da conexo
Caixa Postal
Gravar entrada de voz
Mensagem
Caixa Postal
Gerenciar as mensagens novas e Fila de mensagens

armazenadas
Gerenciar saudao
Mensagem
Gerenciar contedo de mensagens
Vamos ento examinar o Caso de Uso: Recuperar Mensagens
1. Dono da caixa postal executa Ligar para um ramal.
2. O dono da caixa postal digita a senha seguida da tecla #.

Telefone notifica Conexo.
Conexo solicita a Caixa Postal que verifique a senha.

Acrescentamos Gerenciar Senha como responsabilidade
da classe Caixa Postal.
Assumindo que a senha esteja correta, a classe Conexo

seleciona a Caixa Postal correspondente e solicita que
Telefone toque o menu da caixa postal.
3. Sistema toca o menu:

Entre 1 para recuperar suas mensagens.
Entre 2 para trocar a sua senha.
Entre 3 para trocar a saudao.
4. O dono da caixa postal seleciona a opo de menu Recuperar

suas mensagens.

A classe Telefone repassa a opo selecionada para a

classe Conexo.
Projeto de Sistemas
49
50
Captulo 2

Pressione 1 para escutar a mensagem corrente.
Pressione 2 para salvar a mensagem corrente.
Pressione 3 para eliminar a mensagem corrente.
Pressione 4 para retornar ao menu da caixa postal.
6. O dono da caixa postal seleciona a opo de menu Escutar a

Mensagem Corrente

A classe Telefone repassa a opo selecionada para a

classe Conexo.
7. O sistema toca a mensagem corrente ou, se no existirem

novas mensagens, o sistema toca a mensagem mais recente.
Uma mensagem, quando tocada, no removida da fila de
mensagens.

A classe Conexo obtm a primeira mensagem da Caixa

Postal e envia a Mensagem para Telefone.
Acrescentamos Recuperar Mensagens s responsabilidades

da Caixa Postal.
8. O sistema toca o menu de mensagens.
9. O usurio seleciona Salvar a mensagem corrente.

A classe Telefone passa a opo para Conexo.
Conexo avisa Caixa Postal para salvar a mensagem corrente.
Caixa Postal deve ter a responsabilidade de recuperar, salvar

e eliminar mensagens.
10. Sistema toca o menu de mensagens.

Conexo solicita a Telefone que toque o menu de mensagens.
11. ...
Aps a anlise desse caso de uso, vemos que o carto CRC Caixa Postal
sofreu algumas alteraes:
Caixa Postal
Gerenciar as mensagens novas e Fila de Mensagens
armazenadas
Gerenciar saudao
Gerenciar senha
Recuperar, salvar e eliminar
mensagens
Assim terminamos nossa anlise de dois casos de uso com a tcnica de CRC.
Obtivemos uma boa distribuio das responsabilidades.
2.8. Diagrama de classe UML

Dos cartes CRC temos as seguintes colaboraes:
Caixa Postal depende de Fila de Mensagem.
Sistema de Correio depende de Caixa Postal.
Conexo depende de Telefone, Sistema de Correio, Mensagem
e Caixa Postal.
Telefone depende de Conexo.
Os relacionamentos que detectamos em nosso exemplo so:
O sistema de correio possui Caixas Postais.
Uma Caixa Postal possui duas Filas de Mensagens.
Uma Fila de Mensagem possui Mensagens.
Uma Conexo possui uma Caixa Postal corrente.
Projeto de Sistemas
51
52
Captulo 2
Assim podemos construir nosso diagrama de classes como mostrado na

Figura 24:
Figura 24 Diagrama de Classes
2.9. Diagramas de Sequncia

Vamos agora construir o diagrama de Sequncia para os Casos de Uso Deixar
uma Mensagem e Recuperar uma Mensagem (Figuras 25 e 26).
Diagrama de Sequncia para o Caso de Uso Deixar uma Mensagem
Figura 25 Diagrama de Sequncia para o Caso de Uso Deixar uma Mensagem
Diagrama de Sequncia para o Caso de Uso Recuperar uma Mensagem:
Diagrama 26 - Diagrama de Sequncia para o Caso de Uso Recuperar uma Mensagem:
2.10. Concluso
Neste captulo examinamos um processo de desenvolvimento de software muito simples e eficaz.
Com os diagramas de Classes e de Sequncia fica fcil e seguro partir
para a implementao em uma linguagem de programao.
LARMAN, Craig. Utilizando UML e padres: uma introduo

anlise e ao projeto orientados a objetos e ao desenvolvimento
iterativo. Trad. Rosana Vaccare Braga et al. 3ed. Porto Alegre:
Bookman, 2207.
Projeto de Sistemas
53
54
Captulo 2
Mtodos e Estratgias de Estudo
FUNDAMENTOS DE PROJETO:
PADRES GRASP
Neste captulo, vamos revisar alguns princpios estudados na disciplina de Anlise e Projeto de Sistemas I que devemos seguir para
realizarmos um bom projeto.
3.1. Introduo
Neste captulo vamos examinar os Padres de Atribuio de Responsabilidades, propostos por Larman em seu livro Utilizando UML e Padres e alguns outros princpios de projeto importantes.
Nas prximas sees veremos alguns conselhos de Larman que podem
parecer bastante bvios e triviais; porm, a violao dessas regras simples que causa a maioria dos problemas nos projetos OO.
3.2. Os Padres GRASP

Os padres de projeto GRASP propostos por Craig Larman podem melhorar bastante nossos projetos.
O que Larman fez foi adaptar os critrios fundamentais de projeto ao
formato dos padres de projeto e foi muito feliz com essa abordagem.
GRASP significa General Responsibility Assigment Software Patterns,
ou seja, Padres de Software Genricos de Atribuio de Responsabilidades. Esses padres podem nos ajudar a alocar responsabilidades (ou
comportamentos) s classes de uma forma muita prtica.
Os Padres GRASP so:
Expert;
Creator;
High Cohesion;
Projeto de Sistemas
55
56
Captulo 3
Low Coupling;
Controller.
3.3. GRASP 1: EXPERT

Este um padro muito simples e um dos mais desobedecidos! Ele deve
estar sempre em sua mente quando estiver construindo os diagramas de
colaborao e diagramas de classes. A palavra expert, na lngua portuguesa, quer dizer especialista.
O Padro Expert responde a questo:
Dado um comportamento, a que classe deve ser atribudo esse

comportamento?
A resposta simplesmente: a quem tem a informao necessria
para realizar o comportamento.
A resposta a essa pergunta leva alocao inteligente dos comportamentos, o que por sua vez resulta em sistemas mais robustos e fceis de
entender, expandir e reutilizar.
3.3.1. Exemplo
Temos trs classes: uma representando Pedidos, outra LinhaPedido e
outra CatalogoDeProduto. Um trecho do modelo conceitual :
Fundamentos de Projeto: Padres GRASP
Agora suponha que estamos construindo a colaborao para um dos

casos de uso e esse caso de uso necessita que o total de um Pedido seja
apresentado ao usurio.
A que classe deve ser alocado o comportamento calcularTotal()?
O Padro Expert diz que a nica classe que deve ter permisso para lidar
com o Custo Total de um Pedido a classe Pedido, isso porque ela deve
ser especialista em todas as coisas relativas a Pedidos.
Ento alocamos o mtodo calcularTotal() classe Pedidos.
Mas para calcular o total do Pedido, o Pedido precisa saber o total de
cada linha de Pedido.
A opo de deixar que Pedido acessasse as informaes de LinhaPedido
e realizasse a soma tornaria mais pobre nosso projeto.
Mais uma vez aplicamos o padro Expert, e temos que a nica classe
que deveria calcular o total de Linha de Pedido LinhaPedido, que deve
ser o expert sobre todas as coisas de Linha de Pedido, assim criamos um
mtodo calcularSubTotal() e alocamos em LinhaPedido.
Por sua vez, calcularSubTotal() precisa obter o preo unitrio do produto e multiplicar por quantidade do produto, ento novamente o Expert
sugere que aloquemos o mtodo obterPreco() a CatalogoProduto, pois
ele deve ser o Expert sobre todas as informaes sobre Produto.
Nesse exemplo aplicamos o padro Expert trs vezes e assim teremos o
seguinte diagrama de classes:
Projeto de Sistemas
57
58
Captulo 3
E nosso diagrama de colaborao fica:
3.4. GRASP 2: CREATOR

O Padro Creator uma especializao do padro Expert. A palavra
creator, na lngua portuguesa, quer dizer criador.
Ele responde a questo:
Quem deve ser responsvel pela criao de instncias de uma classe

particular?
A resposta que a classe A deve ser responsvel pela criao dos
objetos da classe B se:
A contm objetos B;
A utiliza objetos B;
A contm os dados de inicializao que devem ser passados
classe B.
3.4.1. Exemplo
No nosso exemplo anterior, quando um novo Pedido criado, quem

deve ser responsvel pela criao dos objetos LinhaPedido?
A soluo apontada pelo padro Creator que, como Pedido contm

LinhaPedido, ento a classe Pedido (e somente ela) deve ser responsvel
pela criao de Linhas de Pedidos.
O diagrama de colaborao fica:
3.5. GRASP 3: HIGH COHESION

extremamente importante garantir que as responsabilidades de cada
classe sejam focalizadas. Em um bom projeto OO, cada classe no deve
realizar trabalho excessivo. Um sinal de um bom projeto OO que cada
classe possua um pequeno nmero de mtodos. Chamamos essa caracterstica de High Cohesion, ou seja, Alta Coeso.
Projeto de Sistemas
59
60
Captulo 3
3.5.1. Exemplo
No projeto de um sistema de controle de elevadores, a seguinte classe
foi projetada:
Esse um bom projeto?

Bem, a classe obviamente realiza um bocado de trabalho: liga alarmes,
inicia, desativa, move o elevador, etc.
Podemos perceber que esse no um bom projeto porque a classe
no coesiva. Ela deve ser difcil de manter, e no est claro o que
ela deve fazer.
Quando criamos uma classe, devemos seguir a regra:
Cada classe deve representar uma nica coisa (ou abstrao) do

mundo real, isto Coeso.
Nosso sistema de controle de elevador est tentando modelar no mnimo umas trs abstraes com uma nica classe: um Alarme, a Porta do
elevador e o registro de falhas.
Separando essas abstraes, teramos um projeto que podemos considerar melhor para o sistema de controle de elevadores:
3.6. GRASP 4: LOW COUPLING

Low Coupling ou Baixo Acoplamento uma caracterstica muito importante para nossos projetos.
Acoplamento uma medida de identifica quo dependente uma

classe de outra.
Quanto mais baixo o acoplamento entre as classes, melhor
ser o projeto.
O Alto Acoplamento leva a um projeto de difcil manuteno e modificao, isto porque uma simples mudana em uma classe pode ocasionar mudanas em vrias outras classes, visto que elas so muito
dependentes entre si.
O diagrama de colaborao fornece um excelente meio de verificar o
nvel de acoplamento do projeto. O diagrama de classes tambm d uma
idia do nvel de acoplamento.
Projeto de Sistemas
61
62
Captulo 3
Veja o diagrama abaixo:
Todas as associaes so necessrias? O projetista desse sistema deve

questionar seriamente alguns detalhes de projeto. Por exemplo:
Por que a classe C esta associada classe A, se existe uma
associao indireta atravs da classe B? Essa associao pode
ter sido criada por motivo de performance, o que razovel,
ou pode ter sido criada por desleixo.
Por que a classe B possui tantas associaes? Essa classe provavelmente est realizando muito trabalho.
Seguir o modelo conceitual uma forma excelente de reduzir o acoplamento. Somente envie mensagem de uma classe a outra se a associao foi identificada durante a fase de modelagem conceitual. Agindo assim, voc estar
se restringindo a introduzir acoplamentos que existem no mundo real.
Se, durante o projeto de uma colaborao, voc perceber que precisa enviar uma mensagem de uma classe para outra a que no est associada
no modelo conceitual, ento se pergunte seriamente sobre a existncia
ou no de acoplamento no mundo real. Conversar com o usurio do
sistema pode ajudar a identificar se a associao foi esquecida durante
a construo do modelo conceitual.
A regra :
Mantenha o acoplamento o menor possvel.
O modelo conceitual uma excelente fonte de informaes sobre o que devemos considerar o mnimo. tolervel aumentar o nvel de acoplamento de
um projeto, depois de uma sria e profunda anlise sobre as consequncias.
3.6.1. Exemplos
Em um sistema de Pedidos, identificamos no modelo conceitual que
Clientes possuem Pedidos.
No caso de uso Criar Pedidos que classe deve ser responsvel por criar
um novo Pedido?
O padro Creator sugere que a classe Cliente deve ser responsvel:
Com esde critrio acoplamos Cliente a Pedidos. Nesse caso, est OK,
pois, como voc pode ver (no modelo conceitual), eles so acoplados
no mundo real.
Em seguida, uma vez que Pedido foi criado, o caso de uso precisa adicionar Linha de Pedidos a Pedidos. Quem deve ser responsvel por adicionar as linhas de pedidos?
Uma soluo seria Cliente adicionar as linhas (afinal ele possui as informaes de inicializao necessrias: quantas linhas, que produtos, que
quantidades, etc).
Essa soluo aumentou o acoplamento artificialmente; temos agora todas as trs classes dependentes umas das outras.
Se fizermos Pedido responsvel pela criao das linhas de pedidos, faremos com que Cliente no tenha nenhum acoplamento com
LinhaPedidos.
Projeto de Sistemas
63
64
Captulo 3
Se a implementao da classe LinhaPedido sofrer alguma mudana, a

nica classe afetada vai ser a classe Pedido.
Todo acoplamento que existe neste projeto foi identificado no modelo

conceitual:
Clientes possuem Pedidos;
Pedidos possuem LinhaPedidos.
3.6.2. Lei de Demeter
Esta lei, tambm conhecida como No fale com estranhos um mtodo efetivo de combater o acoplamento.
Esta lei estabelece que:
Qualquer mtodo de um objeto somente pode chamar mtodos

pertencentes a:
Ele mesmo.
Qualquer parmetro que foi passado ao mtodo.
Qualquer objeto que ele criou.
Qualquer objeto que ele contm.
Aplicando essa lei fazemos nossos objetos tmidos e o acoplamento

ser reduzido.
3.6.3. Mais alguns conselhos para reduzir o acoplamento:
Nunca faa um atributo de uma classe pblico: um atributo
pblico abre a classe para abusos. Uma exceo so as constantes de uma classe.
Somente fornea mtodos set/get onde for estritamente

necessrio.
Fornea a menor interface pblica possvel (isto , somente faa
um mtodo pblico se ele tem que ser acessado fora da classe).
Minimize a passagem de dados como parmetros, isto , minimize o fluxo de dados no sistema.
No considere o acoplamento sozinho, lembre-se de alta coeso e do padro Expert.
Um sistema completamente desacoplado vai ter classes fazendo muitas coisas. Isso frequentemente se manifesta como um
sistema com poucos objetos ativos que no se comunicam.
3.7. GRASP 5: CONTROLLER

O ltimo padro GRASP proposto por Larman o Padro Controller,
que quer dizer controlador.
Vamos examinar um Sistema de Apostas e o caso de uso Fazer Apostas.
Esse sistema deve permitir que seus usurios faam apostas sobre o resultado de uma partida e consultem os resultados das partidas.
Como o usurio vai entrar com as apostas e como os resultados sero
mostrados?
Precisamos mostrar os resultados de uma partida para o usurio. Que
classe deve ser responsvel por satisfazer esse requisito?
A aplicao do padro Expert sugere que, como os detalhes pertencem a Partidas, ento a classe Partida deve ser a Expert em mostrar
os detalhes relevantes.
Essa soluo pode parecer boa, mas na realidade ela viola o padro Expert!
Projeto de Sistemas
65
66
Captulo 3
Vamos ver o porqu!

A classe Partida deve ser especialista em todas as informaes sobre
as Partidas, e no sobre Interface Grfica para mostrar os resultados
de uma partida!
Geralmente, a incluso de informaes sobre a GUI, Bases de Dados
(ou qualquer outro objeto fsico) em nossas classes resultar em um
projeto pobre.
Imagine se tivssemos 500 classes em nosso sistema, e muitas dessas
classes devessem ler e escrever na tela do computador. O que aconteceria se os requisitos do sistema mudassem e fosse necessrio alterar toda
a interface com o usurio? Teramos que alterar cada classe envolvida
com a interface com o usurio!
Fica muito melhor manter todas as classes do modelo conceitual puras
chamamos essas classes de Classes de Negcio ou Business Classes.
No Padro Controller criamos uma nova classe que vai ficar entre
o usurio e as classes de negcio.
O padro Controller uma soluo possvel.
Uma sugesto para o nome desta classe :
<nomeDoCasoDeUSo>Handler.
Ento, em nosso projeto, precisamos criar uma classe
FazerApostasHandler
No caso de termos de alterar a interface com o usurio, a nica classe

que precisamos modificar a classe controladora.
LARMAN, Craig. Utilizando UML e padres: uma introduo

anlise e ao projeto orientados a objetos e ao desenvolvimento
iterativo. Trad. Rosana Vaccare Braga et al. 3ed. Porto Alegre:
Bookman, 2207.
67
HERANA X COMPOSIO
Neste captulo vamos examinar uma questo muito importante

para o projeto de sistemas: quando usar herana e quando usar
composio?
Que critrios devemos utilizar?
4.1. Introduo
Neste captulo vamos examinar como devemos utilizar os mecanismos
de herana e composio em nossos projetos de forma eficiente e eficaz.
Para estender um objeto temos dois mecanismos bsicos:
Herana
Composio
Os desenvolvedores iniciantes acreditam erradamente que o mecanismo de herana mais importante e costumam deixar de lado a composio em seus projetos.
Para projetos bem sucedidos, siga a seguinte regra:
use Composio para estender responsabilidades de um objeto delegando trabalho para outros objetos; e
use Herana para estender atributos e mtodos.
4.2. Composio
Neste exemplo um objeto Passageiro uma composio de algum nmero de objetos Reserva.
Uma composio ocorre sempre que voc encontrar uma restrio de
conexo de objetos que seja diferente de 1:1.
Projeto de Sistemas
68
Captulo 4
4.3. Herana
O mecanismo de herana estende a implementao de um mtodo, no
apenas a sua interface.
Os problemas ocasionados pelo uso indiscriminado do mecanismo de

Herana so:
A herana implica encapsulamento forte com outras classes, mas
encapsulamento fraco entre a superclasse e suas subclasses;
Se mudarmos a implementao de uma classe que uma superclasse, ento mudamos efetivamente a implementao de
todas as suas subclasses.
A soluo para esses problemas : Projetar uma hierarquia de classes coesa
e garantir que a subclasse seja realmente um tipo especial de superclasse
4.3.1. Exemplo
Vamos ver um exemplo de (mal) uso de herana:
Um sistema possui uma classe Pessoa e uma classe Passageiro:
Criamos uma superclasse Pessoa e especializamos a classe Pessoa em

uma classe Passageiro.
Fundamentos de Projeto: Herana x Composio
Em seguida, precisamos criar uma classe chamada Agente, para os agentes de viagens.
Criamos ento a classe Agente como uma subclasse de Pessoa, j que

uma especializao de Pessoa.
Mas o Agente de Viagens tambm ocasionalmente um Passageiro, assim criamos uma subclasse Agente-Passageiro que herda as caractersticas de Passageiro e de Agente.
O problema que esse tipo de herana chamado Herana Mltipla

no suportado por algumas linguagens de programao como Java.
4.3.2. Que fazer ento?
Soluo:
Use composio de papis para evitar o risco de uma mudana nos papis dos objetos.
A composio se ajusta muito melhor mudana contnua.
Projeto de Sistemas
69
70
Captulo 4
4.3.3. Quando Usar Herana?

A herana deve ser utilizada para estender atributos e mtodos, mas o
encapsulamento fraco dentro de uma hierarquia de classes, portanto o
uso desse mecanismo limitado.
O uso de herana indicado quando se puder satisfazer os seguintes critrios:
um tipo especial de, e no um papel desempenhado por.
Nunca precisa transmutar para ser um objeto em alguma outra classe.
Estende uma superclasse em vez de sobrep-la ou anul-la.
No divide em subclasse o que simplesmente uma classe utilitria.
Dentro do domnio do problema, expressa tipos especiais de papis, de transaes ou de dispositivos.
Resumindo: usamos Herana de trs maneiras principais:

Papel: especializando em tipos especiais de papis de participante ou misso.
Transao: especializando em tipos especiais de transaes.
Dispositivos: especializando em tipos especiais de dispositivos.
4.3.4. Exemplo de Uso de Composio

Vamos retomar o exemplo anterior de Pessoa e seus papis de Agente e
Passageiro.
Criar uma classe Agente-Passageiro que herda de Agente e de Passageiro levaria soluo:
Essa soluo no possvel em Java, pois essa linguagem no admite

herana mltipla.
Vamos aplicar nossos critrios para a utilizao de herana para
esse problema:
Um Passageiro no um tipo especial de pessoa, um papel
que uma pessoa desempenha. O mesmo acontece com Agente. Um passageiro e um agente so tipos especiais de papeis
desempenhados por pessoas.
Um objeto Passageiro pode ficar para sempre como um objeto
Passageiro, no necessrio transmutar para um objeto em qualquer outra classe; o mesmo verdadeiro para o Agente. Isto , ele
NO precisa transmutar para ser um objeto de outra classe.
Ambas as classes estendem as responsabilidades definidas na
superclasse.
No divide em subclasse o que simplesmente uma classe
utilitria.
Dentro do domnio do problema NO expressa tipos especiais de papis, de transaes ou de dispositivos.
Assim, Herana no se aplica nesse caso, pois viola 3 condies para seu
uso (sentenas marcadas em amarelo)!
Podemos ver que Passageiros e Agentes so tipos especiais de papis
desempenhados por uma Pessoa. Assim, uma soluo melhor utilizar composio:
Vamos examinar outro exemplo.

Um sistema possui uma classe para representar as Transaes de
uma empresa.
As transaes podem ser do tipo Reserva e Compra.
Podemos dizer que as transaes de Reserva e Compra herdam de Transao?
Projeto de Sistemas
71
72
Captulo 4
Se utilizarmos herana neste exemplo, obtemos a seguinte soluo:
Se utilizarmos composio, teremos a seguinte soluo:
Vamos aplicar os nossos critrios de utilizao de herana nesse problema:

Uma Reserva um tipo especial de transao. Uma Compra tambm.
Um objeto Reserva permanece como um objeto Reserva, mesmo se criarmos um objeto Compra correspondente mais tarde. Um objeto Reserva poderia precisar conhecer seu objeto
Compra correspondente (isso significa composio entre dois
objetos nas subclasses).
A Reserva estende a definio de Transao e Compra estende
a definio de Transao.
No divide em subclasses o que uma classe utilitria.
Dentro do domnio do problema, expressa tipos especiais de
papeis, de transaes ou dispositivos.
Observe que alguns objetos Reserva tero um objeto Compra correspondente.
Nesse exemplo, podemos utilizar herana, mas uma soluo melhor seria utilizamos tanto herana quanto composio. Veja a soluo abaixo:
A implementao em Java ficaria assim:

public class Transacao
{
...
}
public class Reserva extends Transacao
{
...
private Compra compra;
...
}
public class Compra extends Transacao
{
...
private Reserva reserva;
...
}
4.3.5. Outro Exemplo
Temos um sistema que utiliza uma classe Sensor que coleta de dados.
Temos tambm uma classe Temporizador que, em intervalos, solicita
informaes classe Sensor.
Queremos ento incluir uma classe Sensor Remoto, que deve ser solicitada para que fornea uma leitura de seus dados. Esse tipo de sensor no
pode ser ativado e monitorado pelo Temporizador.
Projeto de Sistemas
73
74
Captulo 4
A primeira soluo apresentada a seguir:
Vamos ento aplicar nossos critrios de herana a esse problema:

O sensor remoto um tipo especial de sensor (e no um
papel que o sensor desempenha).
Um sensor remoto permanece um sensor remoto que no
est sob nosso controle direto.
A classe sensor remoto anula, e no tem uso para uma conexo para temporizador ou trs mtodos (ativar, monitorar, avaliar).
No divide em subclasse o que simplesmente uma
classe utilitria.
Dentro do domnio do problema, expressa tipos especiais
de papeis, de transaes ou de dispositivos, um tipo especial de dispositivo.
Observe que os critrios de herana se aplicam a esse problema.
Mas uma soluo melhor ser obtida se observarmos que:
Podemos dividir os sensores em dois grupos:
Sensores Ativveis (ou Locais)
Sensores Remotos
Criamos ento uma classe geral chamada Sensor, e estendemos com
duas classes: Sensor Local e Sensor Remoto.
E a classe Temporizador ser acoplada somente classe Sensor Local.
[1]
Projeto de Sistemas
75
76
Captulo 4
77
INTERFACES
Neste captulo vamos estudar quais as vantagens do uso de interfaces e como aplic-las em nossos projetos.
5.1. Reviso de Interfaces

Uma Interface um conjunto de assinaturas de mtodos que
definimos para usar em diversos lugares em uma aplicao.
Ela contm somente uma listagem de assinaturas de mtodos e descreve

um protocolo padro de acesso a um objeto. Uma interface descreve
uma maneira padronizada de interagir com objetos de classes que implementam a interface.
Para utilizar uma interface precisamos:
especificar a interface e
especificar quais classes implementam essa interface.
Um exemplo de interface:
Ao criar uma Interface, utilize a seguinte regra para o nome da interface: inicie o nome com o prefixo I, seguido por:
um substantivo, quando for uma interface de acesso;
um verbo, quando for uma interface de clculo;
um substantivo com um verbo, quando for uma combinao de interfaces.
Projeto de Sistemas
78
Captulo 5
Em Java uma interface criada com:

public interface IAluno
{
String obterNome();
void atribuirNome(String umNome);
}
Uma classe que implementa a interface se compromete a implementar
tambm os mtodos dessa interface.
Em Java:
public class Aluno implements IAluno
{
...
String obterNome()
{
// implementao de obterNome
}
...
void atribuirNome(String umNome)
{
// implementao de obterNome
}
...
}
A classe Aluno obrigada a definir os mtodos obterNome() e

atribuirNome(), pois implementa a interface IAluno.
5.2. Por Que Usamos Interfaces?

Em nossos projetos observamos que os objetos interagem com outros
objetos. O que ocorre frequentemente que quase sempre teremos alteraes no projeto que demandaro adies e remoes de classes.
Fundamentos de Projeto: Interfaces
A interao entre dois objetos acopla esses dois objetos, tornando difcil
ou trabalhosa a alterao dos sistemas.
O uso de interfaces permite tornar mais flexvel, mais fcil de estender e
mais fcil a conexo entre os objetos de nosso sistema.
Quando precisamos de flexibilidade, podemos especificar as conexes
do objeto e o envio de mensagens para objetos em todas as classes que
implementam uma interface.
As interfaces tambm tornam mais fraco o acoplamento.
Podemos usar Interfaces para expressar a generalizao-especializao de
assinaturas de mtodos isto , comportamentos. Podemos usar um mecanismo de herana para expressar as relaes de generalizao-especializao de interfaces implementadas. As interfaces fornecem uma maneira de
separar assinaturas de mtodos das implementaes dos mtodos.
Enfim, as interfaces nos proporcionam uma maneira de estabelecer conexes entre objetos e o envio de mensagens a objetos em qualquer classe
que implemente uma interface necessria, sem conectar fisicamente os
objetos ou os envios de mensagens a uma classe especfica de objetos.
Estratgia 1
Questione cada conexo de objetos.
Essa conexo est conectada fisicamente apenas aos objetos nessa classe (mais simples), ou essa uma conexo a algum objeto
que implementa uma determinada interface (mais flexvel, extensvel ou plugvel)?
Estratgia 2
Questione cada envio de mensagem.
Esse envio de mensagem est conectado fisicamente apenas aos
objetos nessa classe (mais simples), ou um envio de mensagem
para qualquer objeto que implementa uma determinada interface
(mais flexvel, extensvel ou plugvel)?
Projeto de Sistemas
79
80
Captulo 5
5.3. Onde Aplicar Interfaces?

Devemos utilizar as interfaces para separar os componentes das assinaturas de mtodos em quatro situaes principais:
Para fatorar componentes repetitivos;
Para fatorar os componentes para um Proxy;
Para fatorar os componentes de aplicativos anlogos;
Para fatorar para expanso futura.
Vamos examinar cada uma dessas situaes a seguir.
5.3.1. Para Fatorar Componentes Repetitivos
A estratgia que utilizamos :
Fatore os elementos das assinaturas de mtodos que se repetem dentro do seu modelo de objetos;
Transforme os sinnimos em uma nica assinatura;
Generalize nomes muito especficos em uma nica assinatura
Razes para uso: capturar explicitamente o comportamento
comum, reutilizvel e trazer um nvel mais alto de abstrao
para o modelo.
a) Exemplo
Se temos em uma classe A um mtodo calculaTotal() e em uma classe B um mtodo calculaTotal, criamos uma interface ITotal com um
mtodo calculaTotal() e fazemos com que a classe A e a classe B
implementem ITotal.
Se temos em uma classe A um mtodo calculaTotal() e em uma classe C um mtodo determinaTotal() e ambas possuem o mesmo comportamento, ento separamos os componentes dessa assinatura de
mtodos para uma interface ITotal e fazemos com que as classes A
e C implementem ITotal.
Se temos uma classe A com um mtodo calculaTotal(), uma classe D
com um mtodo calculaSubTotal() e uma classe E com um mtodo
calculaTotalGeral(), escolhemos um sinnimo comum: calculaTotal. Separamos os componentes dessa assinatura de mtodo para a
interface ITotal. Fazemos com que as classes A, D e E implementem
a interface ITotal
b) Outro Exemplo
Veja o diagrama de classes a seguir.
Vamos aplicar a estratgia: fatorar elementos repetitivos.

Separamos os componentes de calcularTotal();
Os mtodos calcularTotal() e quantos() poderiam ser sinnimos, mas no
so, pois um soma unidades monetrias e o outro quantidades de itens.
Os mtodos calcularTotal() e quanto() so sinnimos e os tipos de retorno correspondem. Escolhemos calcularTotal().
TotalGeral() um nome especializado para calcularTotal(). Usamos
calcularTotal().
quantos() : ocorre duas vezes.
calcularImpostos() : ocorre duas vezes.
calcularTotal() e quanto() : ocorre quatro vezes.
Vamos criar trs interfaces:
IQuantos: quantos();
IImpostos: calcularImpostos();
ITotal: calcularTotal().
Como estamos utilizando duas interfaces comuns, IImpostos e ITotal
sempre juntas, ento podemos combinar essas duas interfaces em uma
nica interface chamada IVenda.
Projeto de Sistemas
81
82
Captulo 5
Fazendo as modificaes no diagrama anterior, temos:
A implementao em Java ficaria assim:

public interface IQuantos
{
int quantos();
}
public interface ITotal
{
float calculaTotal();
}
public interface IImpostos
{
float calculaImpostos();
}
public interface IVenda extends ITotal, IImpostos
{
}
public Cliente extends Object implements ITotal
{
public float calculaTotal()

{
}
public Venda extends Object implements IVenda
{

{
}
public float calculaImpostos()
{
}
public Loja extends Object implements ITotal, IQuantos
{

{
}
public int quantos()
{
}
public Item extends Object implements IQuantos
{
public int quantos()

{
}
}
Projeto de Sistemas
83
84
Captulo 5
5.3.2. Para Fatorar os Componentes para um Proxy

(Agente)
Fatore os componentes das assinaturas de mtodos para um agente (ou
Proxy), um objeto com uma nica conexo a algum outro objeto.
Razes para uso: simplificar o agente dentro de um modelo de

objeto e suas visualizaes de cenrio.
Sempre que um objeto tem uma e somente uma conexo com outro
objeto, ento esse objeto pode atuar como um agente para o outro.
Passageiro tem uma e somente uma conexo com o objeto Pessoa, ento Passageiro pode atuar como um agente (Proxy) para Pessoa.
Um agente faz perguntas em nome de um outro e proporciona uma
interface conveniente.
Exemplo
Veja o diagrama abaixo: o objeto Reserva solicita ao objeto Passageiro um
passageiro e em seguida solicita ao objeto Pessoa o endereo do Passageiro:
No seria melhor poder perguntar diretamente a Passageiro seu endereo?

Ento fazemos uma mudana nas classes Pessoa e Passageiro, incluindo
mtodos para acesso a nome e endereo.
Nosso diagrama de classes parcial mostrar as seguintes classes Pessoa e Passageiro:
A implementao em Java de Passageiro fica assim:

public class Passageiro extends Object
{
...
public String obterNome()
{
return this.pessoa.obterNome();
}
public void atribuirNome(String umNome)
{
this.pessoa.atribuirNome(umNome);
}
public String obterEndereco()
{
return this.pessoa.obterEndereco();
}
public void atribuirEndereco(String umEndereco)
{
this.pessoa.atribuirEndereco(umEndereco);
}
}
Com essa soluo podemos perguntar a Passageiro o seu endereo diretamente, em vez de perguntar ao objeto Pessoa.
uma soluo, mas no muito boa!
Projeto de Sistemas
85
86
Captulo 5
Vamos ver agora uma soluo utilizando um Proxy.

Em primeiro lugar, fatoramos os componentes e obtemos:
Podemos combinar as interfaces INome e IEndereco em uma nica interface IDadosPessoais.

Nosso diagrama fica assim:
Depois, inserimos um Proxy para responder por Passageiro. Chamamos

esse Proxy de PapelPessoa.
A implementao em Java fica assim:

public class Pessoa extends Object implements IDadosPessoais
{
...
}
public abstract class PapelPessoa extends Object implements
IDadosPessoais
{
...
}
public class Passageiro extends PapelPessoa
{
...
}
Observe como as interfaces mudam a natureza de uma conexo de objetos, isto , como um objeto pode conhecer outro.
A viso muda de eu guardo um conjunto de objetos Pessoa para eu
guardo um conjunto de objetos IDadosPessoais que podem ser quaisquer objetos que implementem IDadosPessoais!
Veja como fica fcil estender o projeto.
Vamos incluir uma classe Agente ao nosso diagrama. Como temos um
Proxy para PapelPessoa e Agente um papel de uma pessoa no sistema,
fazemos simplesmente:
Projeto de Sistemas
87
88
Captulo 5
A implementao em Java fica assim:

public class Pessoa extends Object implements IDadosPessoais
{
...
}
public abstract class PapelPessoa extends Object implements
IDadosPessoais
{
...
}
public class Passageiro extends PapelPessoa
{
...
}
public class Agente extend PapelPessoa
{
Outra possibilidade muito interessante a criao de uma interface IUDadosPessoais, que um objeto de interface com o usurio, e contm
objetos de interface com o usurio (IU) menores, tais como botes, caixas de texto, etc. Essa interface tambm conhece alguns dos objetos nas
classes que implementam IDadosPessoais.
Como IDadosPessoais no est fisicamente conectada a objetos de apenas uma classe, ela trabalha com objetos de todas as classes que implementem a interface IDadosPessoais.
Assim a IUDadosPessoais ter acesso aos atributos de quaisquer objetos

que implementem a interface IDadosPessoais.
Por exemplo, quando inserimos a classe Agente, todo o cdigo est preparado para funcionar com essa classe!
Para o objeto receptor no importa em que posio a classe est na hierarquia de classes, e tambm no importa mais se sua classe possui uma
implementao diferente.
O projetista pode pensar mais sobre o comportamento de que precisa
em vez de sobre quem deve implementar esse comportamento.
Os principais impactos da utilizao dessa tcnica so:
Melhor reutilizao de objetos dentro da aplicao atual;
Maior probabilidade de reutilizao de objetos em aplicativos futuros;
Modelos mais simples;
Modelos mais flexveis, extensveis e que suportam
plugabilidade.
Enfim, utilizando interfaces, melhoramos a abstrao e simplificamos o projeto.
5.3.3. Para Fatorar os Componentes de Aplicativos
Semelhantes
A estratgia que usamos :
Fatore os componentes das assinaturas de mtodos que podero ser utilizveis em aplicativos anlogos.
Razes para uso: aumentar a probabilidade de utilizao e reutilizao de classes de prateleira.
Por meio das interfaces ns podemos categorizar os objetos (isto , criar

hierarquias de classes) de mltiplas maneiras. Obtemos ento dimenses em nosso projeto.
Projeto de Sistemas
89
90
Captulo 5
a) Exemplo
Nosso projeto realiza a venda ou o aluguel de um produto.
Podemos criar uma interface IVenda e outra IAluguel para nosso objeto Coisa.
Assim o objeto Coisa poder ser utilizado em aplicativos de Venda e

tambm de Aluguel, bastando utilizar a interface adequada.
b) Outro exemplo
Em um sistema de uma empresa area temos uma classe chamada Descrio de Vo, que possui os mtodos disponvel(), reservar() e cancelar().
Criamos uma IUDescrioVoo para acessar as informaes de voo.
Veja o diagrama parcial a seguir:
O diagrama de sequncia mostrado a seguir:
Utilizando nossa estratgia criamos uma interface IReservaData
A implementao em Java fica:

public interface IReservaData
{
boolean disponivel (Date umaData);...
Object reservar (Date umaData, Object reservador);
boolean cancelar (Date umaData, Object reservador);
}
Os mtodos disponvel() e cancelar() retornam resultados booleanos.
O mtodo reservar() retorna um objeto, mantendo a interface flexvel
(no estamos limitando a interface a objetos de uma determinada classe
ou suas subclasses). O objeto que contm esse objeto retornado deve
conter o tipo do resultado para qualquer tipo de objeto que ele espera
receber de volta.
Criamos uma interface que permite que objetos que sabem como interagir com essa interface se pluguem e a utilizem.
Nosso diagrama de classes parcial fica:
Observe que qualquer aplicao pode interagir com um objeto em qualquer classe que implemente IReservaData.
Projeto de Sistemas
91
92
Captulo 5
Por exemplo: poderamos utilizar IUReservaData e IReservaData para aplicaes que requeiram fazer reservas (bibliotecas, locadoras, hotis, etc).
5.3.4. Para Fatorar para Expanso Futura
Fatore as assinaturas de mtodos de forma que objetos de classes diferentes possam ser facilmente aceitos no futuro.
Razes para uso: permitir a flexibilidade de mudanas.
Uma dvida permanente a todo projeto : Com que outros objetos teremos que lidar no futuro?
Uma soluo para essa dvida adicionar interfaces a fim de se melhorar a compreenso do modelo e de se permitir a flexibilidade de mudanas no futuro.
Exemplo
Um sistema possui Sensores em Zonas diferentes.
Um diagrama de classes parcial mostrado a seguir:
Aplicando nossa estratgia, criamos uma interface chamada IAtivar com

as assinaturas dos mtodos das classes Zona e Sensor. Nosso diagrama
de classes parcial fica assim:
Observe que Zona mantm um conjunto de objetos IAtivar, neste caso

IAtivar poderia conter outros objetos IAtivar.
Como IAtivar uma interface, ela no tem atributos e nem conexes de objetos.
Em uma verso futura do software, poderamos querer ativar ou desativar um grupo de sensores de uma nica vez, isto , querermos tratar um
grupo de sensores como se fosse um nico sensor!
Veja como fica fcil a soluo:
1. Criamos uma interface IAtivarGrupo;
2. Adicionamos um mtodo adicionarAtivar, para adicionar um
sensor ao grupo;
3. Adicionamos um mtodo removerAtivar para remover um sensor do grupo.
public interface IAtivar

{
void ativar();
void desativar();
}
public interface IAtivarGrupo extends IAtivar
{
void adicionarAtivar(IAtivar umaIAtivar);
void removerAtivar(IAtivar umaIAtivar);
}
public class Sensor extends Object implements IAtivar
{
public void ativar()

Projeto de Sistemas
93
94
Captulo 5
}
public void desativar()
{
}
}
public class Zona extends Object implements IAtivarGrupo
{
private Vector ativados = new Vector();
public adcionaIAtivar(IAtivar umaIAtivar)

{
this.ativados.addElement(umaIAtivar);
}
public removerAtivar(IAtivar umaIAtivar)
{
this.ativados.removeElement(umaIAtivar);
}
public void ativar()
{
// iterar atravs do vetor de ativados
// e solicitar a cada IAtivar para se ativar
Enumeration listaAtivados = this.ativados.elements();
while (listaAtivados.hasMoreElements())
{
// converte o tipo do elemento para IAtivar
IAtivar umaAtivar = (IAtivar)listaAtivados;
umaAtivar.ativar();
}
}
public void desativar()
{
// iterar atravs do vetor de ativados
// e solicitar a cada IAtivar para se desativar
Enumeration listaAtivados = this.ativados.elements();
while (listaAtivados.hasMoreElements())
{
// converte o tipo do elemento para IAtivar

IAtivar umaAtivar = (IAtivar)listaAtivados;
umaAtivar.desativar();
}
}
Com essa estratgia podemos combinar os Sensores e Zonas de maneiras novas. Por exemplo: uma zona ser um conjunto de outras zonas que,
por sua vez, podem ser um conjunto de sensores e um sensor ser um
conjunto de outros sensores.
[1]
Projeto de Sistemas
95
96
Captulo 5
97
PADRO STRATEGY
Neste captulo vamos definir uma famlia de algoritmos, encapsular

cada um deles e faz-los intercambiveis.
6.1. Definio Oficial

Definir uma famlia de algoritmos, encapsular cada uma delas, e fazlas intercambiveis. O padro Strategy permite que algoritmo mude independentemente dos clientes que o utilizam [GAMMA et al., 2000].
6.2. Problema
Como permitir que a seleo de um algoritmo possa variar por objeto e
durante a execuo?
6.2.1. Na Anlise:
Quando existem diferentes implementaes de uma regra de negcio.
6.2.2. No Projeto:
Quando uma regra de negcio ou algoritmo muda de acordo com
um contexto.
6.2.3. Ateno
Quando uma estrutura de seleo mltipla (switch) determina que regra de negcio utilizar.
Quando existe uma hierarquia de classes e a diferena entre elas somente um mtodo que sobrescrito.
Projeto de Sistemas
98
Captulo 6
6.3. Soluo
Faa com que a classe que contm o algoritmo contenha uma classe
abstrata que tem um mtodo abstrato especificando como chamar o algoritmo. Cada classe derivada implementa o algoritmo desejado.
6.4. Diagrama UML
6.4.1. Participantes e Colaboradores

Cliente: essa classe delega uma operao para uma classe abstrata ou interface, a Estratgia. Ela no sabe qual objeto ir
executar a operao.
Estratgia: classe abstrata ou interface que abstrai as operaes fornecidas por todas as suas subclasses, as Estratgias.
Estratgia1 at a EstratgiaN: so as classes que fornecem
as diferentes implementaes das operaes especificadas
em Estratgia.
6.5. Observaes
Podemos utilizar o Strategy:
Quando classes relacionadas forem diferentes apenas no seu
comportamento;
Quando precisamos de diferentes variaes de um mesmo algoritmo;
Quando um algoritmo deve utilizar dados que um cliente no
deve conhecer;
Quando uma classe define muitos comportamentos que aparecem com mltiplas declaraes condicionais em suas operaes.
Padro Strategy
6.6. Implementao
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
interface SocketPool
{ Socket allocate( String host, int port )
void release ( Socket s )
}
class SimplePool implements SocketPool
{ public Socket allocate(String host,int port)
{ return new Socket(host, port);
}
public void release(Socket s)
{ s.close();
}
};
class KeepalivePool implements SocketPool
{ private Map connections = new HashMap();
public Socket allocate(String host,int port)
{ Socket connection =
(Socket)connections.get(host+:+port);
if(connection == null)
connection = new Socket(host,port);
return connection;
}
{ String host = s.getInetAddress().getHostName();
connections.put( host+:+s.getPort(),s );
}
//...
}
class ProtocolHandler
{ SocketPool pool = new SimplePool();
public void process( String host, int port )
{ Socket in = pool.allocate(host,port);
//...
pool.release(in);
}
public void setPoolingStrategy( SocketPool p)
{ pool = p;
}
}
Projeto de Sistemas
99
100
Captulo 6
6.7. Exerccios
1. O que acontece quando um sistema tem uma exploso de objetos
Strategy? Existe alguma forma melhor de gerenciar estas estratgias?
2. Existem duas formas de implementao do padro Strategy. Uma
forma descreve como um objeto estratgia pode ser passado como
uma referncia ao objeto contexto, permitindo o acesso aos dados
do contexto. Mas possvel que o dado requerido pelo Strategy no
esteja disponvel na interface de contexto? Como podemos remediar este problema potencial?
[1]
GAMMA, Erich; HELM, Richard; JOHSON, Ralph;
VLISSIDES, John. Padres de projeto: solues reutilizveis de
software orientado a objetos. Trad. Luiz A. Meirelles Salgado. Porto Alegre: Bookman, 2000. p. 292
[2]
METSKER, Steven John. Padres de projetos em Java.
Porto Alegre: Bookman, 2004. p. 217
Funes
PADRO OBSERVER OU
PUBLISH/SUBSCRIBE
Neste captulo vamos definir uma dependncia um-para-muitos

entre objetos para que, quando um objeto mudar de estado, os seus
dependentes sejam notificados e atualizados automaticamente.

Definir uma dependncia um-para-muitos entre objetos para que,
quando um objeto mudar de estado, todos os seus dependentes sejam
notificados e atualizados automaticamente [GAMMA et al., 2000].
7.2. Problema
Como estabelecer uma dependncia entre objetos de modo que, quando um objeto mudar seu estado interno, seus objetos dependentes sejam informados?
7.2.1. Na Anlise
Quando diferentes objetos precisam saber quando um evento ocorre.
E o nmero destes objetos pode variar com o tempo ou com o caso.
7.2.2. No Projeto
Quando diferentes objetos precisam saber quando um evento ocorre.
E o nmero destes objetos pode variar com o tempo ou com o caso.
7.2.3. Ateno:
Quando um novo objeto precisa ser notificado de um evento e o programador precisa modificar o cdigo do objeto que detecta o evento.
Projeto de Sistemas
101
102
Captulo 7
7.3. Soluo
Temos objetos (observadores) que querem saber quando um evento
ocorre, conectamos a outro objeto (observado), que est na realidade
esperando por sua ocorrncia. Quando um evento ocorre, o observado
informa aos observadores que ele ocorreu. O padro Adapter algumas
vezes necessrio para ser capaz de implementar a interface de Observer para todos os tipos de objetos.
7.4. Diagrama UML
7.4.1 Participantes e Colaboradores

Observador: Existem tanto uma interface quanto uma ou
mais classe de implementao. A interface possui um mtodo chamado update, que chamado pelos objetos Observados
quando seu estado mudado.
Observado: Existem tanto uma interface quanto uma ou mais
classes de implementao. A interface possui mtodos para
adicionar ou remover objetos Observadores, cujo mtodo
update chamado a cada mudana de estado.
7.5. Observaes
Vantagens:
Tanto os observadores quando os observados podem ser reutilizados e ter a sua interface e implementao alteradas sem
afetar o sistema.
Padro Observer ou Publish/Subscribe
O acoplamento forte implicado pelo relacionamento bidirecional reduzido com o uso de interfaces e classes abstratas.
Desvantagens:
O abuso pode causar srio impacto na performance. Sistemas em que todos notificam todos a cada mudana ficam
inundados de requisies, esse efeito chamado de tempestade de eventos.
7.6. Implementao
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
public final class NotifyingCollection

implements Collection
{ private final Collection c;
public NotifyingCollection(Collection wrap)
{ c = wrap; }
private final Collection subscribers
= new LinkedList();
public interface Subscriber
{ void addedItem ( Object item );
void removedItem ( Object item );
}
synchronized public void addSubscriber(
Subscriber subscriber)
{ subscribers.add( subscriber ); }
synchronized public void removeSubscriber(
Subscriber subscriber)
{ subscribers.remove( subscriber );
}
private void notify(boolean add, Object o)
{ Object[] copy;
synchronized(this)
{ copy = subscribers.toArray();
}
for( int i = 0; i < copy.length; ++i )
{ if( add )
((Subscriber)copy[i]]).addItem(o);
else
((Subscriber)copy[i]).removeItem(o);
Projeto de Sistemas
103
104
Captulo 7
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
}
}
public boolean add(Object o)
{ notify(true,o); return c.add(o); }
public boolean remove(Object o)
{ notify(false,o); return c.remove(o); }
public boolean addAll(Collection items)
{ Iterator i = items.iterator()
while( i.hasNext() )
notify( true, i.next() );
return c.addAll(items);
}
// pass-through implementations of other
// Collection methods go here...
}
7.7. Exerccios
1. Quais so as propriedades de um sistema que usa o padro Observer extensivamente? Como podemos abordar a tarefa de depurao de um sistema desse tipo?
2. Est claro para voc como tratar problemas de concorrncia com esse padro? Considere uma mensagem Unregister()
sendo enviada a um Observado, justamente antes que o observado envie uma mensagem Notify() para o MudaGerenciador
(ou Controller).
[1]
software orientado a objetos. Trad. Luiz A. Meirelles Salgado. Porto Alegre: Bookman, 2000. p. 274
[2]
Funes
PADRO DECORATOR
Neste captulo vamos definir uma dependncia um-para-muitos

entre objetos para que, quando um objeto mudar de estado, os seus
dependentes sejam notificados e atualizados automaticamente.

Anexar responsabilidades adicionais a um objeto dinamicamente. O
padro Decorator oferece uma alternativa flexvel ao uso de herana
para estender uma funcionalidade [GAMMA et al., 2000].
8.2. Problema
Como estender as funcionalidades de uma nica instncia de uma classe, sem afetar as outras instncias?
8.2.1. Na Anlise:
Quando existe alguma ao que sempre deve ser realizada e algumas
outras aes que podem ser realizadas.
8.2.2. No Projeto:
Quando existe um conjunto de aes e essas aes podem ser adicionadas em qualquer combinao a um mtodo existente. No desejamos
alterar o cdigo que utiliza a funo decorada.
8.2.3. Ateno:
Quando uma estrutura de seleo mltipla (switch) determina se alguma
funo opcional deve ser chamada antes de alguma funo existente.
Projeto de Sistemas
105
106
Captulo 8
8.3. Soluo
Configure uma classe abstrata que representa tanto a classe original
quanto as novas funes a serem adicionadas. Faa cada uma conter
um tratador para um objeto deste tipo (na realidade, um tipo derivado).
Em nossos decoradores, execute a funo adicional e ento chame o
mtodo operao() do objeto contido. Opcionalmente chame o mtodo
operao() do objeto contido primeiro e ento execute as suas prprias
funes especiais.
8.4. Diagrama UML

Servico: Existe tanto uma interface quanto uma ou mais classes concretas. Os objetos dessas classes fornecem um servio.
Wrapper: Existe tanto uma interface quanto uma ou mais
classes concretas. Os objetos dessas classes delegam as operaes para Servio.
8.5. Observaes
Padro Decorator
8.6. Implementao
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
import java.util.*;
/* I would prefer for this class to be a LinkedList,
* but LinkedList is not an interface, and
* useful methods like addFirst() and removeFirst()
* are not defined in an interface.
*/
public class BlockingList implements List
{ private final List component;
public BlockingList( List component )
{ this.component = component;
}
private boolean noLongerEmpty()
{ try
{ while( component.size() == 0 )
wait();
return true;
}
catch( InterruptedException e )
{ return false;
}
}
synchronized public boolean add(Object o)
{ boolean toReturn = component.add(o);
notifyAll();
return toReturn;
}
synchronized public boolean remove(Object o)
{ if( noLongerEmpty() )
return component.remove(o);
return false;
}
public int size()
{ return component.size();
}
/* Syncrhonized versions of all other methods of

* the List interface are implemented here ...
*/
Projeto de Sistemas
107
108
Captulo 8
8.7. Exerccios
1. Na implementao do padro Decorator, a interface de um objeto decorator deve ser idntica interface do componente que ele
decora. Considere um objeto A, que decorado com um objeto B.
Como B decora o objeto A, o objeto B compartilha uma interface
com o objeto A. Se a algum cliente ento passada uma instncia
desse objeto decorado, e esse mtodo tenta chamar um mtodo
em B que no faz parte da interface de A, isso significa que o objeto no mais um Decorator, no senso estrito do padro? Alm
disso, por que importante que a interface de um objeto decorador seja idntica interface do componente que ele decora?
[1]
software orientado a objetos. Trad. Luiz A. Meirelles Salgado. Porto Alegre: Bookman, 2000. p. 170.
[2]
Porto Alegre: Bookman, 2004. p. 259.
Funes
PADRO FACTORY METHOD
Neste captulo vamos definir uma interface para criar famlias

de objetos relacionados ou dependentes sem especificar suas
classes concretas.

Definir uma interface para criar um objeto, mas deixar que subclasses
decidam que classe instanciar. O padro Factory Method permite que
uma classe delegue a responsabilidade de instanciamento s subclasses
[GAMMA et al., 2000].
9.2. Problema
Como permitir que subclasses decidam que classe instanciar?
9.2.1. Na Anlise:
Quando existem objetos semelhantes cujas implementaes so coordenadas entre elas.
9.2.2. No Projeto:
Uma classe precisa instanciar uma derivao de outra classe, mas no
sabe qual.
FactoryMethod permite que uma classe derivada tome essa deciso.
9.3. Soluo
Tenha um mtodo na classe abstrata que abstrato (virtual puro). O
cdigo da classe abstrata ir referenciar esse mtodo quando precisar
instanciar um objeto contido. Observe, entretanto, que o cdigo no
Projeto de Sistemas
109
110
Captulo 9
sabe qual dos mtodos ele precisa. Isso ocorre porque todas as classes
derivadas dessa devem implementar esse mtodo com comandos new
apropriados para instanciar o objeto correto.
9.4. Diagrama UML

Produto: Interface de objetos que o Factory Method cria.
ProdutoConcreto: Implementa Produto para um produto especifico.
IFabrica: Interface que declara o mtodo Fbrica que retorna
um Produto.
Fbrica: classe especfica da aplicao com mtodos para criar
ProdutoConcreto e que implementa IFabrica.
9.5. Implementao
130
131
132
133
134
135
136
137
138
139
140
141
public class BusinessObject

{ public void doSomething()
{ Element e = createDefaultElement();
//...
}
protected Element createDefaultElement()
{ return new Element();
}
}
public class Element
{ public void f(){/*...*/}
}
Padro Factory Method
142
143
144
145
146
147
148
149
150
151
public class SpecializedBusinessObject

{
protected Element createDefaultElement()
{ return new SpecializedElement();
}
private class SpecializedElement extends Element
{ public void f(){ /*...*/ }
}
}
9.6. Exerccios
1. Explique como o Factory Method promove o baixo acoplamento.
[1]
GAMMA, Erich; HELM, Richard; JOHSON, Ralph; VLISSIDES, John. Padres de projeto: solues reutilizveis de software orientado a objetos. Trad. Luiz A. Meirelles Salgado. Porto
Alegre: Bookman, 2000. p. 112.
[2]
Projeto de Sistemas
111
112
Captulo 9
Funes
PADRO SINGLETON
Neste captulo vamos garantir que uma classe s tenha uma nica instncia, e vamos prover um ponto de acesso global a ela.

Garantir que uma classe s tenha uma nica instncia, e prover um
ponto de acesso global a ela [GAMMA et al., 2000].
10.2. Problema
Como garantir que somente uma nica instncia de uma classe vai ser
criada?
10.2.1. Na Anlise:
Quando existe uma nica instncia de algum objeto no domnio do
problema que utilizada em lugares diferentes.
10.2.2. No Projeto:
Quando vrios objetos clientes precisam referenciar o mesmo objeto
servidor e queremos ter certeza de que no teremos mais de uma instncia do objeto servidor.
Quando queremos uma nica instncia de um objeto, mas no existe
nenhum objeto superior controlando a instanciao dele.
10.3. Soluo
Adicione um membro esttico classe que referencia a primeira instanciao desse objeto (inicialmente ele nulo). Ento, adicione um mtodo esttico que instancia essa classe se esse membro nulo (e atribua
Projeto de Sistemas
113
114
Captulo 10
o valor do membro a ele) e ento retorne o valor desse membro. Finalmente, faa o construtor protegido ou privado, de modo que ningum
possa instanciar diretamente essa classe e pular esse mecanismo.
10.4. Diagrama UML

Singleton: uma classe que existe ao menos em uma
instncia.
10.5. Implementao
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
Class Singleton1
{ private static Singleton instance;
private Singleton1()
{ Runtime.getRuntime().addShutdownHook
( new Thread()
{ public void run()
{ /* clean-up code here */
}
}
);
}
public static synchronized Singleton instance()
{ if( instance == null )
instance = new Singleton();
return instance;
}
}
class Singleton2
{ private static final Singleton instance =
new Singleton2();
Padro Singleton
172
173
174
175
176
177
178
179
180
181
182
183
184
public static Singleton instance()

{ return instance;
}
//...
//Other than creating object in static
//initializer, is identical to Singleton1
}
class Singleton3
{ static Type allFields;
static Type allOperations();
// No instance() method, just use the
// class name to the left of the dot.
}
10.6. Exerccios
1. O padro Singleton frequentemente utilizado com o padro
Abstract Factory. Que outro padro (criacional ou no) podemos
usar com o padro Singleton?
[1]
[2]
Projeto de Sistemas
115
116
Captulo 10
Funes
PADRO COMMAND
Este captulo ensina a encapsular uma requisio como objeto

para que clientes possam parametrizar diferentes requisies,
filas e suportar operaes reversveis.

Encapsular uma requisio como um objeto, permitindo que clientes
possam parametrizar diferentes requisies, filas ou requisies de log,
e suportar operaes reversveis [GAMMA et al., 2000].
11.2. Problema
Como permitir operaes sobre comandos, tais como sequenciamento e desfazer?
11.3. Diagrama UML

ComandoAbstrato: Interface para a execuo de um comando. Possui mtodos abstratos fazer() e desfazer().
ComandoConcreto: Implementa um comando especfico. O
Construtor deve possuir os parmetros necessrios. Especializa os mtodos fazer() e desfazer();
Projeto de Sistemas
117
118
Captulo 11
Chamador: chama os comandos para execuo. Pode criar

o comando.
Gerenciador de Comandos: gerencia o conjunto de comandos para suportar um histrico de comandos.
11.4. Implementao
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
abstract class Cursor extends Cloneable

{ public Object clone();
public char characterAt();
public void deleteCharacterAt();
public void insertCharacterAt(
char newCharacter);
public void moveTo(Cursor newPosition);
public void moveRight();
//...
}
class TextEditor
{ private Cursor current = new Cursor();
private LinkedList undoStack =
new LinkedList();
private LinkedList redoStack =
new LinkedList();
public void insertCharacter(char c)
{ process( new Inserter(c) );
}
public void deleteCharacter()
{ process( new Deleter() );
}
private void process( Action command )
{ command.doIt();
undoStack.addFirst(command);
}
public void undo()
{ Action action =
(Action) undoStack.removeFirst();
action.undoIt();
redoStack.addFirst( action );
}
public void redo()
Padro Command
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
{ Action action =
(Action) redoStack.removeFirst();
action.doIt();
undoStack.addFirst( action );
}
private interface Action
{ void doIt ();
void undoIt();
}
private class InsertAction implements Action
{ Cursor where = (Cursor) current.clone();
char inserted;
public InsertAction(char newCharacter)
{ inserted = newCharacter;
}
public void doIt()
{ current.moveTo( where );
current.
insertCharacterAt(inserted);
current.moveRight();
}
public void undoIt()
current.deleteCharacterAt();
}
}
private class DeleteAction implements Action
{ Cursor where = (Cursor) current.clone();
char deleted;
public void doIt()
deleted = current.characterAt();
current.deleteCharacterAt();
}
public void undoIt()
current.insertCharacterAt( deleted);
current.moveRight();
}
}
//...
}
Projeto de Sistemas
119
120
Captulo 11
11.5. Exerccios
1. Uma utilizao muito comum do padro Command em Menus. Uma aplicao possui um menu, que por sua vez possui Itens
de menu, que executam comandos quando so clicados. O que
acontece se o comando precisa de alguma informao sobre a
aplicao para executar a sua tarefa? Como deve o comando ter
acesso a essa informao de modo que novos comandos possam
ser facilmente escritos e que possuam acesso informao de que
eles necessitam?
[1]
[2]
Funes
PADRO ADAPTER
A funo do padro Adapter converter a interface de uma

classe em outra interface esperada pelos clientes.

Converter a interface de uma classe em outra interface esperada pelos
clientes. O padro Adapter permite a comunicao entre classes que
no poderiam trabalhar juntas devido incompatibilidade de suas interfaces [GAMMA et al., 2000].
12.2. Problema
O que fazer quando um objeto Cliente deseja um servio de outro objeto Servidor por meio de uma interface, mas o objeto Servidor no
implementa a interface?
12.2.1. Na Anlise:
Normalmente no nos preocupamos com interfaces na Anlise. Entretanto, se voc sabe que vai utilizar algum cdigo pr-existente em seu
projeto, pode ser necessrio utilizar um Adapter para esse cdigo.
12.2.2. No Projeto:
Quando algum objeto tem mtodos adequados, mas uma interface inadequada.
usado quando temos que realizar alguma operao em um objeto cuja
interface no pode ou no deve ser alterada.
12.3. Soluo
Contm a classe existente em outra classe. Fazer com que a classe
contida possua a mesma interface e chame os mtodos contidos na
classe adaptada.
Projeto de Sistemas
121
122
Captulo 12
12.4. Diagrama UML

Cliente: classe que precisa do servio por meio de interface IAlvo.
IAlvo: interface esperada por cliente para obter um servio.
Adaptador: Classe que implementa IAlvo e fornece servios
usando Adaptado.
Adaptado: classe que fornece o servio.
12.5. Implementao
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class ObjectIterator extends ObjectInputStream

implements Iterator
{ private boolean atEndOfFile = false;
public ObjectIterator(InputStream src)
throws IOException
{ super(src);
}
public boolean hasNext()
{ return atEndOfFile == false;
}
public Object next()
{ try
{ return readObject();
}
catch( Exception e )
{ atEndOfFile = true;
return null;
Padro Adapter
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
}
}
public void remove()
{ throw new UnsupportedOperationException();
}
}
class WrappedObjectIterator implements Iterator
{ private boolean atEndOfFile = false;
private final ObjectInputStream in;
public
WrappedObjectIterator(ObjectInputStream in)
{ this.in = in;
}
{ return atEndOfFile == false;
}
{ try
{ return in.readObject();
}
catch(Exception e){/* as above */}
}
public void remove()
{ throw new UnsupportedOperationException();
}
}
12.6. Exerccios
1. Faz sentido criar um Adapter que possui a mesma interface que
o objeto que ele adapta? Seu Adapter no seria um Proxy?
[1]
[2]
Projeto de Sistemas
123
124
Captulo 12
Funes
PADRO FAADE
O padro Faade oferece uma interface nica de nvel mais elevado para um conjunto de interfaces de um subsistema.

Oferecer uma interface nica para um conjunto de interfaces de um
subsistema. O padro Faade define uma interface de nvel mais elevado que torna o subsistema mais fcil de usar [GAMMA et al., 2000].
13.2. Problema
Como acessar um conjunto de objetos por meio de uma nica interface ou objeto?
13.2.1. Na Anlise:
Quando somente algumas funes de um sistema complexo vo
ser utilizadas.
13.2.2. No Projeto:
Quando a referncia a um sistema j existente feita de forma semelhante.
Ento, vemos combinaes de chamadas ao sistema sendo repetidas
vrias vezes.
13.2.3. Ateno:
Quando os desenvolvedores precisam estudar a interface de um
novo sistema, porm cada um deles s vai utilizar uma pequena
parte da interface.
Projeto de Sistemas
125
126
Captulo 13
13.3. Soluo
Defina uma nova classe (ou classes) que possui (em) a interface desejada. Faa com que essa(s) classe(s) utilize(m) o sistema existente.
13.4. Diagrama UML

Cliente: classe que acessa Faade para obter os servios.
Faade: classe que acessa Sistema.
Sistema: grupo de objetos que fornecem um servio.
13.5. Implementao
1
2
3
4
5
6
7
8
9
10
class XMLStorage
{ public store(URL out, Object toStore)
{ /* Code goes here that uses the
* introspection APIs in the System
* class to get the class name and the
* values of all the public fields in
* the class. The name and the values of
* those fields are then used to build a
* JDOM tree, which is passed to an
* outputter to send an XML
Padro Faade
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
* representation of the tree to the

* OutputStream.
*/
}
public Object load(URL in);

{ /* Code goes here that creates a
* JDOM SaxBuilder for the InputStream,
* uses it to build a JDOM, instantiates
* a class named in the XML file,
* then initializes that class using
* one of the constructors or a series
* of get/set methods.
*/
}
13.6. Exerccios
1. Quo complexo deve ser um sistema que justifique o uso do
padro Faade?
2. Que outras formas de utilizar o padro Faade podemos imaginar com relao a um grupo de desenvolvedores e projetistas
com diferentes habilidades e conhecimento? Quais as ramificaes polticas?
[1]
Alegre: Bookman, 2000. p. 179
[2]
Projeto de Sistemas
127
128
Captulo 13
Funes
PADRO TEMPLATE METHOD
Neste captulo vamos definir o esqueleto de um algoritmo dentro de uma operao, deixando alguns passos a serem preenchidos pelas subclasses.

Definir o esqueleto de um algoritmo dentro de uma operao, deixando
alguns passos a serem preenchidos pelas subclasses. O padro Template
Method permite que suas subclasses redefinam certos passos de um algoritmo sem mudar a sua estrutura [GAMMA et al., 2000].
14.2. Problema
Como permitir que subclasses de uma classe variem partes ou passos de
um algoritmo geral?
14.2.1. Na Anlise:
Quando existem diferentes procedimentos que devem ser seguidos e
que so essencialmente o mesmo, exceto em detalhes em que cada passo
faz coisas diferenciadas.
14.2.2. No Projeto:
Voc tem um conjunto de passos consistentes a seguir, mas alguns passos individuais podem ter implementaes diferentes.
14.2.3. Ateno:
Quando classes diferentes implementam essencialmente o mesmo
fluxo de processo.
Projeto de Sistemas
129
130
Captulo 14
14.3. Soluo
Crie uma classe abstrata que implementa um procedimento usando mtodos abstratos. Esses mtodos devem ser implementados nas classes
derivadas, para executar cada passo do procedimento. Se os passos variam independentemente, cada passo pode ser implementado com um
padro Strategy.
14.4. Diagrama UML

TemplateAbstrato: esta classe define um mtodo o templateMethod, que implementa a lgica geral de um algoritmo. O
templateMethod chama outros mtodos que so sobrescritos
pela classe TemplateConcreto.
TemplateConcreto: esta classe deve sobrescrever os mtodos
que so chamados pelo Template Method.
14.5. Implementao
27
28
29
30
31
32
class ProtocolHhandler2
{ protected Socket allocate(String host,int port)
{ return new Socket(host, port);
}
protected void release(Socket s)
{ s.close();
Padro Template Method
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
}
public void process( String host, int port )
{ Socket in =
socketPool.allocate(host,port);
//...
socketPool.release(in);
}
}
class KeepaliveProtocolHandler
{
private Map connections = new HashMap();
public Socket allocate(String host,int port)
{ Socket connection =
(Socket)connections.get(host+:+port);
if(connection == null)
connection = new Socket(host,port);
return connection;
}
{ String host=
s.getInetAddress().getHostName();
connections.put( host+:+s.getPort(),s);
}
}
14.6. Exerccios
1. O Template Method utiliza herana. Seria possvel obter a mesma funcionalidade de um Template Method, utilizando a composio? Quais seriam as desvantagens?
Projeto de Sistemas
131
132
Captulo 14
[1]
[2]
Funes
PADRO ITERATOR
Este padro promove uma maneira de acessar elementos de um objeto agregado sequencialmente, sem expor sua representao interna.

Prover uma maneira de acessar os elementos de um objeto agregado sequencialmente, sem expor sua representao interna [GAMMA et al., 2000].
15.2. Problema
Como acessar sequencialmente todos os objetos de uma coleo, sem
expor a interface ou a forma de representao da coleo.
15.2.1. Na Anlise:
Quando temos uma coleo de objetos, mas no est claro qual o tipo
certo de coleo de objetos que devemos utilizar.
15.2.2. No Projeto:
Quando desejamos esconder a estrutura interna de uma coleo e precisamos de uma forma de percorrer uma coleo independente de sua
armazenagem interna.
15.2.3. Ateno:
Quando uma mudana na estrutura de interna de uma coleo implica
a mudana da forma de como a coleo iterada.
15.3. Soluo
Defina uma classe abstrata para ambas as colees e iteradores. Faa
cada coleo derivada incluir um mtodo que instancia o iterador ade
Projeto de Sistemas
133
134
Captulo 15
quado. O iterador deve ser capaz de solicitar a informao requerida da

coleo, de modo que possa atravess-la apropriadamente.
15.4. Diagrama UML

Coleo: Classe que encapsula uma coleo de objetos.
IColeo: interface comum para Coleo. Ela fornece mtodos para criar Iterador.
Iterador: implementao de Iterator.
IIterator: Interface que define os mtodos para acessar seqencialmente os objetos de uma coleo.
15.5. Implementao
1
2
3
4
5
6
7
8
9
10
11
12
13
class Tree implements Collection

{ private Node root = null;
private static class Node
{ public Node left, right;
public Object item;
public Node( Object item )
{ this.item = item; }
}
Iterator iterator()
{ return new Iterator()
{ private Node current = root;
private LinkedList stack =
new LinkedList();
Padro Iterator
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

{ while( current != null )
{ stack.addFirst( current );
current = current.left;
}
if( stack.size() != 0 )
{ current = (Node)
( stack.removeFirst() );
Object toReturn=current.item;
current = current.right;
return toReturn;
}
throw new NoSuchElementException();
}
{ return !(current==null
&& stack.size()==0);
}
public void remove(){ /*...*/ }
};
}
public interface Examiner
{ public void examine( Object o ); }
void traverse( Examiner client )
{ traverseInorder( root, client );
}
private void traverseInorder(Node current,
Examiner client )
{ if( current == null )
return;
traverseInorder(current.left, client);
client.examine (current.item );
traverseInorder(current.right, client);
} // ...
}
15.6. Exerccios
1. Considere um Composite que contm objetos Emprstimo. A
interface do objeto Emprstimo contm um mtodo chamado
Projeto de Sistemas
135
136
Captulo 15
quantiaEmprestimo(), que retorna o valor atual de mercado de

um emprstimo. Dado um requisito de extrair todos os emprstimos acima, abaixo e entre certa quantia, voc deve escrever ou
usar um Iterator para fazer isso?
[1]
[2]
Funes
PADRO COMPOSITE
Neste captulo, vamos aprender como se permite um tratamento de

objetos individuais e composies desses objetos de maneira uniforme.

Compor objetos em estruturas de rvores para representar hierarquias
todo-parte. O padro Composite permite que clientes tratem objetos
individuais e composies de objetos de maneira uniforme [GAMMA
et al., 2000].
16.2. Problema
Como criar um objeto estruturado definido recursivamente em termos
de outros objetos?
16.2.1. Na Anlise:
Quando existem objetos simples e grupos de objetos que precisam ser
tratados da mesma maneira.
O grupo de objetos composto de outros grupos e objetos simples, isto
, eles so hierarquicamente relacionados.
16.2.2. No Projeto:
Alguns objetos so compostos de colees de outros objetos, e queremos tratar esses objetos de uma forma unificada.
16.2.3. Ateno:
Quando o tratamento entre um objeto e sua coleo feito por cdigos diferentes.
Projeto de Sistemas
137
138
Captulo 16
16.3. Soluo
Crie uma classe abstrata que representa todos os elementos na hierarquia. Defina no mnimo uma classe derivada que representa as componentes individuais. Ainda defina no mnimo uma outra classe que representa os elementos compostos (isto , aqueles elementos que contm
componentes mltiplos). Na classe abstrata, defina mtodos abstratos
que os objetos clientes usaro. Finalmente, implemente esses mtodos
para cada uma das classes derivadas.
16.4. Diagrama UML

ComponenteAbstrato: Superclasse da famlia inteira de objetos na estrutura Composite.
ComponenteConcreto: Implementao do ComponenteAbstrato (as folhas da estrutura em rvore).
CompositeAbstrato: superclasse dos objetos composite da estrutura.
CompositeConcreto: implementao de CompositeAbstrato
(os ramos da estrutura em rvore).
Padro Composite
16.5. Implementao
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
abstract class Element

{ private Rectangle position;
public Element(Rectangle position)
{ this.position = position;
}
protected void prepare(Graphics surface)
{ // modify the surfaces coordinate
// system so that (0,0) is at the
// current Elements position.
}
public abstract void renderTo(Graphics surface);
}
89
class Form extends Element

{ private Collection subelements
= new ArrayList();
public Form( Rectangle position )
{ super(position);
}
public void add(Element subelement)
{ subelements.add( subelement );
}
public void renderTo(Graphics surface)
{ prepare(surface);
Iterator i = subelements.iterator();
while( i.hasNext() )
((Element)i.next()).render(surface);
}
}
class StaticText extends Element
{ private String text;
public StaticText(Rectangle position,
String text)
{ super(position);
this.text = text;
}
public void renderTo(Graphics surface)
{ prepare(surface);
surface.drawText(text);
}
Projeto de Sistemas
139
140
Captulo 16
16.6. Exerccios
1. Como o padro Composite ajuda a consolidar uma lgica condicional no sistema como um todo?
2. Podemos usar o padro Composite mesmo no tendo uma hierarquia parte-todo? Em outras palavras, se somente uns poucos
objetos possuem filhos e quase todos os outros elementos de sua
coleo so folhas (uma folha no pode ter filhos!), ainda assim
devemos usar o padro Composite para modelar esses objetos?
[1]
software orientado a objetos. Trad. Luiz A. Meirelles Salgado. Porto Alegre: Bookman, 2000. p.160.
[2]
Funes
PADRO STATE
A Neste captulo aprenderemos como o padro State permite a

um objeto alterar o seu comportamento quando o seu estado
interno mudar

Permitir a um objeto alterar o seu comportamento quando o seu estado interno mudar. O objeto ir aparentar mudar de classe [GAMMA et al., 2000]
17.2. Problema
Como permitir que um objeto dinamicamente mude um conjunto de
atributos?
Como mudar a natureza (ao invs dos valores) de um estado do
objeto?
17.2.1 Na Anlise:
Quando temos comportamentos que mudam dependendo do estado
em que est o objeto.
17.2.2. No Projeto:
Quando temos comportamentos que mudam dependendo do estado
em que est o objeto.
17.2.3. Ateno:
Quando o cdigo tem que lembrar do estado do sistema.
Cada vez que um evento tratado, um comando de seleo mltipla
(switch) determina que cdigo deve ser executado.
Projeto de Sistemas
141
142
Captulo 17
17.3. Soluo
Defina uma classe abstrata para representar o estado de uma aplicao.
Derive uma classe para cada estado possvel. Cada uma dessas classes
pode agora operar independentemente de outra. As transies de estado podem ser tratadas tanto na classe contextual quanto nos prprios
estados. As informaes que so persistentes entre os estados devem
ser armazenadas no contexto. Os estados devem precisar acessar essas
informaes por meio de mtodos get.
17.4. Diagrama UML

Contexto: classe cuja instncia exibe um comportamento.
Ele mantm uma referncia a objetos EstadoConcreto que
implementa a funcionalidade de estado. cliente do Padro Estado.
EstadoContexto: superclasse de todas as classes usadas por
Contexto para representar um Estado. Ela fornece os mtodos
para inicializao e mudana de estado.
EstadoConcreto: subclasse concreta de EstadoContexto. referenciada por Contexto.
17.5. Implementao
1
2
3
4
5
public final class LockedCollection

implements Collection
{ private final Collection c;
private int activeIterators = 0;
Padro State
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
private Unsafe active = new IsActive();

private Unsafe locked = new IsLocked();
private Unsafe state = active;
public LockedCollection(Collection c)
{ this.c = c;
}
public Iterator iterator()
{ final Iterator wrapped = c.iterator();
++activeIterators;
state = locked;
return new Iterator()
{ private boolean valid = true;
//...
{ return wrapped.hasNext();
}
{ Object next = wrapped.next();
if( !hasNext() )
{ if( --activeIterators == 0 )
state = active;
valid = false;
}
return next;
}
};
}
public int size()
{ return c.size(); }
public boolean isEmpty()
{ return c.isEmpty(); }
// ...
// Collection methods that dont
// change behavior are defined here.
public boolean add(Object o)
{return state.add(o);}
{return state.remove(o);}
Projeto de Sistemas
143
144
Captulo 17
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
private interface Unsafe

{ public boolean add(Object o);
public boolean remove(Object o);
//...
}
private final class IsActive
implements Unsafe
{ public boolean add(Object o)
{return c.add(o);}
{return c.remove(o);}
//...
}
private final class IsLocked
implements Unsafe
{ public boolean add(Object o)
{ throw new Exception(locked); }
{ throw new Exception(locked); }
//...
}
}
17.6. Exerccios
1. Se um objeto possui somente dois ou trs estados, vale a pena
usar o padro State?
[1]
[2]
Funes
PADRO PROXY
Este captulo apresenta o padro Proxy, que prov um substituto ou

ponto atravs do qual um objeto possa controlar o acesso a outro.

Prover um substituto ou ponto atravs do qual um objeto possa controlar o acesso a outro [GAMMA et al., 2000].
18.2. Problema
Como acessar um servio de modo transparente, permitindo acesso fcil a objetos complexos ou que no esto instanciados durante a execuo da chamada?
18.2.1. Na Anlise:
1. Problemas de Performance (velocidade ou memria) podem
ocorrer devido ao custo em manter um objeto na memria antes
de ele ser utilizado.
2. Precisamos que alguma ao ocorra antes que um objeto j
existente seja chamado.
3. Um objeto precisa acessar um objeto remoto, e no queremos
nos preocupar com a conexo.
18.2.2. No Projeto:
1. Problemas de Performance (velocidade ou memria) podem
ocorrer devido ao custo em manter um objeto na memria antes
de ele ser utilizado.
2. Precisamos que alguma ao ocorra antes que um objeto j
existente seja chamado.
3. Um objeto precisa acessar um objeto remoto, e no queremos
nos preocupar com a conexo.
Projeto de Sistemas
145
146
Captulo 18
18.2.3. Ateno:
Quando objetos so instanciados antes de serem utilizados e causam
problemas de performance.
Quando precedemos uma funo com o mesmo cdigo cada vez que
utilizada, ou quando adicionamos uma estutura de seleo mltipla
(switch) a um objeto de modo que em algumas vezes ele faa um prprocessamento e em outras no.
Quando o uso de um objeto e de seu acesso encontrado em vrios
lugares do cdigo.
18.3. Soluo
Proxy Virtual: O cliente referencia o objeto proxy em vez do objeto original. O objeto proxy armazena as informaes necessrias para instanciar a classe original, porm adia a sua instanciao. Quando o objeto
da classe original realmente necessrio, o proxy o instancia e faz as
operaes necessrias.
18.4. Diagrama UML

ClasseServidora: classe que fornece servios.
Proxy: classe pela qual ClasseServidora acessada.
IServio: interface comum entre ClasseServidora e Proxy
Padro Proxy
18.5. Implementao
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
class Employee
{ private long id;
private Money wage; // hourly wage
private Timesheet hoursWorked;
public Employee(long id)
{ this.id = id;
hoursWorked = Timesheet.create(id);
wage
= Database.getHourlyWage(id);
}
void printPaycheck()
{ Money weeklyWage =
hoursWorked.computeSalary(wage);
//...
}
}
abstract class Timesheet
{ //...
public static Timesheet create(long id)
{ return ( dataAlreadyInMemory )
? new Real(id)
: new Proxy(id);
}
public abstract Money computeSalary(Money wage);
//---------------------------------------private static class Proxy extends Timesheet
{ Timesheet realTimesheet = null;
long id;
Proxy(long id){this.id = id;}
public Money computeSalary(Money wage)
{ if( realTimesheet == null )
realTimesheet = new Real(id);
return realTimesheet.
computeSalary(wage);
}
}
//---------------------------------------private static class Real extends Timesheet
{ Real(long employeeId)
Projeto de Sistemas
147
148
Captulo 18
108
109
110
111
112
113
114
115
{ // load data from the database.

}
public Money computeSalary(Money wage)
{ // Compute weekly salary.
return null;
}
}
18.6. Exerccios
1. Se um Proxy utilizado para instanciar um objeto somente quando ele
absolutamente necessrio, o Proxy simplifica o cdigo?
[1] GAMMA, Erich; HELM, Richard; JOHSON, Ralph; VLISSIDES, John. Padres de projeto: solues reutilizveis de software
orientado a objetos. Trad. Luiz A. Meirelles Salgado. Porto Alegre:
Bookman, 2000. p. 198.
[2] [METSKER, Steven John. Padres de projetos em Java. Porto
Funes
LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao projeto orientados a objetos e ao desenvolvimento iterativo.
Trad. Rosana Vaccare Braga et al. 3ed. Porto Alegre: Bookman, 2207.
GAMMA, Erich et alii.. Padres de projeto: solues reutilizveis de
software orientado a objetos. Trad. Luiz A. Meirelles Salgado. Porto Alegre: Bookman, 2000.
McCONNEL, Steve. Code complete: guia prtico para a construo de
software. 2ed. Porto Alegre: Bookman, 2005.
METSKER, Steven John. Padres de projetos em Java. Porto Alegre:
Bookman, 2004.
http://www.cix.co.uk/~smallmemory/almanac/
Projeto de Sistemas
149

5º Semestre - Projeto de Sistemas Orientados Objeto

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

5º Semestre - Projeto de Sistemas Orientados Objeto

Enviado por

Direitos autorais:

Formatos disponíveis

Curso Superior de

Sistemas para Internet

Catalogao da fonte: Rogria Gomes Belchior - CRB 12/417

Conceitos importantes. Fique atento!

Atividades que devem ser elaboradas por voc,

Indicao de leituras complemtares, referentes

Destaque de algo importante, referente ao

Reflexo/questionamento sobre algo importante referente ao contedo apresentado.

Espao reservado para as anotaes que voc

Tecnologia em Anlise e Desenvolvimento de Sistemas

Cap. 2. - O PROCESSO DE PROJETO

Cap. 3 - Fundamentos de Projeto: Padres

3.2. Os Padres GRASP 55

Cap. 4 - FUNDAMENTOS DE PROJETO:

Cap. 5 - FUNDAMENTOS DE PROJETO:

Cap. 6 - PADRO STRATEGY 97

Cap. 7 - PADRO OBSERVER OU PUBLISH/

Cap. 8 - PADRO DECORATOR 105

Cap. 9 - PADRO FACTORY METHOD 109

9.4.1. Participantes e Colaboradores 110

Cap. 10 - PADRO SINGLETON 113

Cap. 11 - PADRO COMMAND 117

Cap. 12 - PADRO ADAPTER 121

Cap. 13 - PADRO FAADE 125

13.5. Implementao 126

Cap. 14 - PADRO TEMPLATE METHOD 129

Cap. 15 - PADRO ITERATOR 133

Cap. 16 - PADRO COMPOSITE 137

Cap. 17 - PADRO STATE 141

17.2.1. Na Anlise: 141

Cap. 18 - PADRO PROXY 145

REFERNCIAS BIBLIOGRFICAS 149

Tecnologia em Anlise e Desenvolvimento de Sistemas

Tecnologia em Anlise e Desenvolvimento de Sistemas

1.2. Diagramas de UML

Veja na Figura 1 os diagramas e sua diviso:

Figura 1 Diagramas da UML

Vamos dar uma olhada nesses diagramas.

Mostra as classes, interfaces, colaborao e os seus relacionamentos.

Figura 2 - Exemplo de Diagrama de Classes

Figura 3 Diagrama de Objetos

Figura 4 Diagrama de Objetos

Figura 5 - Exemplo de Diagrama de Componentes

Mostra os ns e suas relaes. Um n um conjunto de componentes.

Figura 6 - Exemplo de Diagrama de Deployment

Tecnologia em Anlise e Desenvolvimento de Sistemas

Diagramas de sequncia e diagramas de colaborao

Mostram os diferentes objetos e suas relaes, e tambm as mensagens

Figura 7 - Exemplo de Diagrama de Sequncia

Figura 8 - Exemplo de Diagrama de Colaborao

Figura 9 - Exemplo de Diagrama de Estados

Tecnologia em Anlise e Desenvolvimento de Sistemas

Figura 10 - Exemplo de Diagrama de Atividades

Veja no Quadro 1 os diagramas mais utilizados em cada fase do

Quadro 1 O uso de diagramas X fases do projeto

1.3. Que diagramas devo utilizar em meus

Minha sugesto que voc utilize o quadro abaixo para

1.4. Diagrama de Casos de Uso

Representado por uma elipse.

Os casos de uso podem ter relacionamentos com outros casos de uso

Extend: Uma relao de caso de uso A para caso de uso B,

Generalizao: um tipo de herana e a notao a mesma de Extends.

Atores so representados pelo desenho de um boneco.

O limite do sistema (System Boundary) representado por um quadro