Modelagem Oo

Modelagem Orientada a ObjetoVersï¿½o 1.0.0

Sumário

I Sobre essa Apostila 2

II Informações Básicas 4

III GNU Free Documentation License 9

IV Modelagem orientada a objeto 18

1 O que é a modelagem orientada a objeto 19

2 Plano de ensino 202.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2 Público Alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3 Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.7 Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.8 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.9 Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Processos de modelagem 253.1 Introdução à modelagem orientada a objeto . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 A modelagem orientada a objeto . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.2 A abordagem deste curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.3 Otimizações apresentadas neste curso . . . . . . . . . . . . . . . . . . . . . 26

4 Etapas de uma modelagem 274.1 Análise inicial do modelo de negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.1 Modelo de negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1.2 Documentação dos requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2 Estimativa do modelo de implantação . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2.1 Modelo inicial de implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2.2 Diagrama de implantação - estimativa . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Análise de requisitos através de casos de uso . . . . . . . . . . . . . . . . . . . . . . 324.3.1 Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

1

CDTC Centro de Difusão de Tecnologia e Conhecimento Brasil/DF

4.3.2 Autenticação de usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3.3 Controle de contas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3.4 Gerenciamento de contas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3.5 Saque e depósito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3.6 Extrato e saldo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.7 Manutenção do cadastro de clientes . . . . . . . . . . . . . . . . . . . . . . . 38

4.4 Modelos de análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4.1 Os modelos de análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4.2 Interface, controle e entidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4.3 Realizações de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4.4 Autenticação de usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4.5 Exemplos: controle de informações da conta . . . . . . . . . . . . . . . . . . 454.4.6 Exemplo de diagrama de estado . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5 Modelo de projeto - alto nível . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5.1 Modelo de alto nível . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5.2 Divisão em subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5.3 Detalhamento de subsistemas . . . . . . . . . . . . . . . . . . . . . . . . . . 504.5.4 Divisão em camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.5.5 Diagramas de seqüência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.6 Modelo de projeto - detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.6.1 Modelo de projeto - detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . 554.6.2 Exemplo de detalhamento de módulo . . . . . . . . . . . . . . . . . . . . . . 554.6.3 Tabelas do banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.6.4 Diagramas de seqüência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.7 Documentação da implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.7.1 Instanciação do diagrama de implantação . . . . . . . . . . . . . . . . . . . . 61

5 Padrões de design 625.1 Introdução aos design patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.1.1 O que é um design pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.1.2 Design patterns na ciência da computação . . . . . . . . . . . . . . . . . . . 625.1.3 Categorias de design patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6 Padrões de criação 656.1 Abstract Factory e Factory Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.1.1 Abstract Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.1.2 Factory Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.2 Builder e Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.2.1 Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.2.2 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7 Padrões estruturais 827.1 Adapter e Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.1.1 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827.1.2 Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.2 Composite e Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927.2.1 Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927.2.2 Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

2


8 Padrões de comportamento 1018.1 Visitor e Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

8.1.1 Visitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018.1.2 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

8.2 Command e Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078.2.1 Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078.2.2 Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

9 Anti-Pattern, os "inimigos"de um bom design 1159.1 Anti-patterns de design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

9.1.1 Introdução aos anti-patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . 1159.1.2 Anti-patterns de design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169.1.3 Anti-pattern orientado a objeto . . . . . . . . . . . . . . . . . . . . . . . . . . 117

9.2 Outras categorias de anti-pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189.2.1 Anti-pattern de programação . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189.2.2 Anti-patterns de gerência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1209.2.3 Anti-patterns de projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219.2.4 Anti-pattern de métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1229.2.5 Anti-pattern de configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239.2.6 Anti-pattern organizacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

3

Parte I

Sobre essa Apostila

4


Conteúdo

O conteúdo dessa apostila é fruto da compilação de diversos materiais livres publicados na in-ternet, disponíveis em diversos sites ou originalmente produzido no CDTC (http://www.cdtc.org.br.)

O formato original deste material bem como sua atualização está disponível dentro da licençaGNU Free Documentation License, cujo teor integral encontra-se aqui reproduzido na seção demesmo nome, tendo inclusive uma versão traduzida (não oficial).

A revisão e alteração vem sendo realizada pelo CDTC ([email protected]) desde outubrode 2006. Críticas e sugestões construtivas serão bem-vindas a qualquer hora.

Autores

A autoria deste é de responsabilidade de Shou Matsumoto ([email protected]).

O texto original faz parte do projeto Centro de Difusão de Tecnologia e Conhecimento quevêm sendo realizado pelo ITI (Instituto Nacional de Tecnologia da Informação) em conjunto comoutros parceiros institucionais, e com as universidades federais brasileiras que tem produzido eutilizado Software Livre apoiando inclusive a comunidade Free Software junto a outras entidadesno país.

Informações adicionais podem ser obtidas através do email [email protected], ou dahome page da entidade, através da URL http://www.cdtc.org.br.

Garantias

O material contido nesta apostila é isento de garantias e o seu uso é de inteira responsabi-lidade do usuário/leitor. Os autores, bem como o ITI e seus parceiros, não se responsabilizamdireta ou indiretamente por qualquer prejuízo oriundo da utilização do material aqui contido.

Licença

Copyright ©2006, Instituto Nacional de Tecnologia da Informação ([email protected]) .

Permission is granted to copy, distribute and/or modify this document under the termsof the GNU Free Documentation License, Version 1.1 or any later version published bythe Free Software Foundation; with the Invariant Chapter being SOBRE ESSA APOS-TILA. A copy of the license is included in the section entitled GNU Free DocumentationLicense.

5

Parte II

Informações Básicas

6


Sobre o CDTC

Objetivo Geral

O Projeto CDTC visa a promoção e o desenvolvimento de ações que incentivem a dissemina-ção de soluções que utilizem padrões abertos e não proprietários de tecnologia, em proveito dodesenvolvimento social, cultural, político, tecnológico e econômico da sociedade brasileira.

Objetivo Específico

Auxiliar o Governo Federal na implantação do plano nacional de software não-proprietário ede código fonte aberto, identificando e mobilizando grupos de formadores de opinião dentre osservidores públicos e agentes políticos da União Federal, estimulando e incentivando o mercadonacional a adotar novos modelos de negócio da tecnologia da informação e de novos negóciosde comunicação com base em software não-proprietário e de código fonte aberto, oferecendotreinamento específico para técnicos, profissionais de suporte e funcionários públicos usuários,criando grupos de funcionários públicos que irão treinar outros funcionários públicos e atuar comoincentivadores e defensores dos produtos de software não proprietários e código fonte aberto, ofe-recendo conteúdo técnico on-line para serviços de suporte, ferramentas para desenvolvimento deprodutos de software não proprietários e do seu código fonte livre, articulando redes de terceiros(dentro e fora do governo) fornecedoras de educação, pesquisa, desenvolvimento e teste de pro-dutos de software livre.

Guia do aluno

Neste guia, você terá reunidas uma série de informações importantes para que você comeceseu curso. São elas:

• Licenças para cópia de material disponível;

• Os 10 mandamentos do aluno de Educação a Distância;

• Como participar dos foruns e da wikipédia;

• Primeiros passos.

É muito importante que você entre em contato com TODAS estas informações, seguindo oroteiro acima.

Licença

Copyright ©2006, Instituto Nacional de Tecnologia da Informação ([email protected]).

7


É dada permissão para copiar, distribuir e/ou modificar este documento sob os termosda Licença de Documentação Livre GNU, Versão 1.1 ou qualquer versão posteriorpúblicada pela Free Software Foundation; com o Capitulo Invariante SOBRE ESSAAPOSTILA. Uma cópia da licença está inclusa na seção entitulada "Licença de Docu-mentação Livre GNU".

Os 10 mandamentos do aluno de educação online

• 1. Acesso à Internet: ter endereço eletrônico, um provedor e um equipamento adequado épré-requisito para a participação nos cursos a distância;

• 2. Habilidade e disposição para operar programas: ter conhecimentos básicos de Informá-tica é necessário para poder executar as tarefas;

• 3. Vontade para aprender colaborativamente: interagir, ser participativo no ensino a distân-cia conta muitos pontos, pois irá colaborar para o processo ensino-aprendizagem pessoal,dos colegas e dos professores;

• 4. Comportamentos compatíveis com a etiqueta: mostrar-se interessado em conhecer seuscolegas de turma respeitando-os e se fazendo ser respeitado pelos mesmos;

• 5. Organização pessoal: planejar e organizar tudo é fundamental para facilitar a sua revisãoe a sua recuperação de materiais;

• 6. Vontade para realizar as atividades no tempo correto: anotar todas as suas obrigações erealizá-las em tempo real;

• 7. Curiosidade e abertura para inovações: aceitar novas idéias e inovar sempre;

• 8. Flexibilidade e adaptação: requisitos necessário à mudança tecnológica, aprendizagense descobertas;

• 9. Objetividade em sua comunicação: comunicar-se de forma clara, breve e transparente éponto - chave na comunicação pela Internet;

• 10. Responsabilidade: ser responsável por seu próprio aprendizado. O ambiente virtual nãocontrola a sua dedicação, mas reflete os resultados do seu esforço e da sua colaboração.

Como participar dos fóruns e Wikipédia

Você tem um problema e precisa de ajuda?

Podemos te ajudar de 2 formas:

A primeira é o uso dos fóruns de notícias e de dúvidas gerais que se distinguem pelo uso:

. O fórum de notícias tem por objetivo disponibilizar um meio de acesso rápido a informaçõesque sejam pertinentes ao curso (avisos, notícias). As mensagens postadas nele são enviadas a

8


todos participantes. Assim, se o monitor ou algum outro participante tiver uma informação queinteresse ao grupo, favor postá-la aqui.Porém, se o que você deseja é resolver alguma dúvida ou discutir algum tópico específico docurso. É recomendado que você faça uso do Fórum de dúvidas gerais que lhe dá recursos maisefetivos para esta prática.

. O fórum de dúvidas gerais tem por objetivo disponibilizar um meio fácil, rápido e interativopara solucionar suas dúvidas e trocar experiências. As mensagens postadas nele são enviadasa todos participantes do curso. Assim, fica muito mais fácil obter respostas, já que todos podemajudar.Se você receber uma mensagem com algum tópico que saiba responder, não se preocupe com aformalização ou a gramática. Responda! E não se esqueça de que antes de abrir um novo tópicoé recomendável ver se a sua pergunta já foi feita por outro participante.

A segunda forma se dá pelas Wikis:

. Uma wiki é uma página web que pode ser editada colaborativamente, ou seja, qualquer par-ticipante pode inserir, editar, apagar textos. As versões antigas vão sendo arquivadas e podemser recuperadas a qualquer momento que um dos participantes o desejar. Assim, ela oferece umótimo suporte a processos de aprendizagem colaborativa. A maior wiki na web é o site "Wikipé-dia", uma experiência grandiosa de construção de uma enciclopédia de forma colaborativa, porpessoas de todas as partes do mundo. Acesse-a em português pelos links:

• Página principal da Wiki - http://pt.wikipedia.org/wiki/

Agradecemos antecipadamente a sua colaboração com a aprendizagem do grupo!

Primeiros Passos

Para uma melhor aprendizagem é recomendável que você siga os seguintes passos:

• Ler o Plano de Ensino e entender a que seu curso se dispõe a ensinar;

• Ler a Ambientação do Moodle para aprender a navegar neste ambiente e se utilizar dasferramentas básicas do mesmo;

• Entrar nas lições seguindo a seqüência descrita no Plano de Ensino;

• Qualquer dúvida, reporte ao Fórum de Dúvidas Gerais.

Perfil do Tutor

Segue-se uma descrição do tutor ideal, baseada no feedback de alunos e de tutores.

O tutor ideal é um modelo de excelência: é consistente, justo e profissional nos respectivosvalores e atitudes, incentiva mas é honesto, imparcial, amável, positivo, respeitador, aceita asidéias dos estudantes, é paciente, pessoal, tolerante, apreciativo, compreensivo e pronto a ajudar.

9


A classificação por um tutor desta natureza proporciona o melhor feedback possível, é crucial, e,para a maior parte dos alunos, constitui o ponto central do processo de aprendizagem.’ Este tutorou instrutor:

• fornece explicações claras acerca do que ele espera e do estilo de classificação que iráutilizar;

• gosta que lhe façam perguntas adicionais;

• identifica as nossas falhas, mas corrige-as amavelmente’, diz um estudante, ’e explica por-que motivo a classificação foi ou não foi atribuída’;

• tece comentários completos e construtivos, mas de forma agradável (em contraste com umreparo de um estudante: ’os comentários deixam-nos com uma sensação de crítica, deameaça e de nervossismo’)

• dá uma ajuda complementar para encorajar um estudante em dificuldade;

• esclarece pontos que não foram entendidos, ou corretamente aprendidos anteriormente;

• ajuda o estudante a alcançar os seus objetivos;

• é flexível quando necessário;

• mostra um interesse genuíno em motivar os alunos (mesmo os principiantes e, por isso,talvez numa fase menos interessante para o tutor);

• escreve todas as correções de forma legível e com um nível de pormenorização adequado;

• acima de tudo, devolve os trabalhos rapidamente;

10

Parte III

GNU Free Documentation License

11


(Traduzido pelo João S. O. Bueno através do CIPSGA em 2001)Esta é uma tradução não oficial da Licença de Documentação Livre GNU em Português Brasi-

leiro. Ela não é publicada pela Free Software Foundation, e não se aplica legalmente a distribuiçãode textos que usem a GFDL - apenas o texto original em Inglês da GNU FDL faz isso. Entretanto,nós esperamos que esta tradução ajude falantes de português a entenderem melhor a GFDL.

This is an unofficial translation of the GNU General Documentation License into Brazilian Por-tuguese. It was not published by the Free Software Foundation, and does not legally state thedistribution terms for software that uses the GFDL–only the original English text of the GFDL doesthat. However, we hope that this translation will help Portuguese speakers understand the GFDLbetter.

Licença de Documentação Livre GNU Versão 1.1, Março de 2000

Copyright (C) 2000 Free Software Foundation, Inc.59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

É permitido a qualquer um copiar e distribuir cópias exatas deste documento de licença, masnão é permitido alterá-lo.

INTRODUÇÃO

O propósito desta Licença é deixar um manual, livro-texto ou outro documento escrito "livre"nosentido de liberdade: assegurar a qualquer um a efetiva liberdade de copiá-lo ou redistribui-lo,com ou sem modificações, comercialmente ou não. Secundariamente, esta Licença mantémpara o autor e editor uma forma de ter crédito por seu trabalho, sem ser considerado responsávelpelas modificações feitas por terceiros.

Esta Licença é um tipo de "copyleft"("direitos revertidos"), o que significa que derivações dodocumento precisam ser livres no mesmo sentido. Ela complementa a GNU Licença Pública Ge-ral (GNU GPL), que é um copyleft para software livre.

Nós fizemos esta Licença para que seja usada em manuais de software livre, por que softwarelivre precisa de documentação livre: um programa livre deve ser acompanhado de manuais queprovenham as mesmas liberdades que o software possui. Mas esta Licença não está restrita amanuais de software; ela pode ser usada para qualquer trabalho em texto, independentementedo assunto ou se ele é publicado como um livro impresso. Nós recomendamos esta Licença prin-cipalmente para trabalhos cujo propósito seja de introdução ou referência.

APLICABILIDADE E DEFINIÇÕES

Esta Licença se aplica a qualquer manual ou outro texto que contenha uma nota colocada pelodetentor dos direitos autorais dizendo que ele pode ser distribuído sob os termos desta Licença.O "Documento"abaixo se refere a qualquer manual ou texto. Qualquer pessoa do público é um

12


licenciado e é referida como "você".

Uma "Versão Modificada"do Documento se refere a qualquer trabalho contendo o documentoou uma parte dele, quer copiada exatamente, quer com modificações e/ou traduzida em outralíngua.

Uma "Seção Secundária"é um apêndice ou uma seção inicial do Documento que trata ex-clusivamente da relação dos editores ou dos autores do Documento com o assunto geral doDocumento (ou assuntos relacionados) e não contém nada que poderia ser incluído diretamentenesse assunto geral (Por exemplo, se o Documento é em parte um livro texto de matemática, aSeção Secundária pode não explicar nada de matemática).

Essa relação poderia ser uma questão de ligação histórica com o assunto, ou matérias relaci-onadas, ou de posições legais, comerciais, filosóficas, éticas ou políticas relacionadas ao mesmo.

As "Seções Invariantes"são certas Seções Secundárias cujos títulos são designados, comosendo de Seções Invariantes, na nota que diz que o Documento é publicado sob esta Licença.

Os "Textos de Capa"são certos trechos curtos de texto que são listados, como Textos de CapaFrontal ou Textos da Quarta Capa, na nota que diz que o texto é publicado sob esta Licença.

Uma cópia "Transparente"do Documento significa uma cópia que pode ser lida automatica-mente, representada num formato cuja especificação esteja disponível ao público geral, cujosconteúdos possam ser vistos e editados diretamente e sem mecanismos especiais com editoresde texto genéricos ou (para imagens compostas de pixels) programas de pintura genéricos ou(para desenhos) por algum editor de desenhos grandemente difundido, e que seja passível deservir como entrada a formatadores de texto ou para tradução automática para uma variedadede formatos que sirvam de entrada para formatadores de texto. Uma cópia feita em um formatode arquivo outrossim Transparente cuja constituição tenha sido projetada para atrapalhar ou de-sencorajar modificações subsequentes pelos leitores não é Transparente. Uma cópia que não é"Transparente"é chamada de "Opaca".

Exemplos de formatos que podem ser usados para cópias Transparentes incluem ASCII sim-ples sem marcações, formato de entrada do Texinfo, formato de entrada do LaTex, SGML ou XMLusando uma DTD disponibilizada publicamente, e HTML simples, compatível com os padrões, eprojetado para ser modificado por pessoas. Formatos opacos incluem PostScript, PDF, formatosproprietários que podem ser lidos e editados apenas com processadores de texto proprietários,SGML ou XML para os quais a DTD e/ou ferramentas de processamento e edição não estejamdisponíveis para o público, e HTML gerado automaticamente por alguns editores de texto comfinalidade apenas de saída.

A "Página do Título"significa, para um livro impresso, a página do título propriamente dita,mais quaisquer páginas subsequentes quantas forem necessárias para conter, de forma legível,o material que esta Licença requer que apareça na página do título. Para trabalhos que nãotenham uma página do título, "Página do Título"significa o texto próximo da aparição mais proe-minente do título do trabalho, precedendo o início do corpo do texto.

13


FAZENDO CÓPIAS EXATAS

Você pode copiar e distribuir o Documento em qualquer meio, de forma comercial ou nãocomercial, desde que esta Licença, as notas de copyright, e a nota de licença dizendo que estaLicença se aplica ao documento estejam reproduzidas em todas as cópias, e que você não acres-cente nenhuma outra condição, quaisquer que sejam, às desta Licença.

Você não pode usar medidas técnicas para obstruir ou controlar a leitura ou confecção decópias subsequentes das cópias que você fizer ou distribuir. Entretanto, você pode aceitar com-pensação em troca de cópias. Se você distribuir uma quantidade grande o suficiente de cópias,você também precisa respeitar as condições da seção 3.

Você também pode emprestar cópias, sob as mesmas condições colocadas acima, e tambémpode exibir cópias publicamente.

FAZENDO CÓPIAS EM QUANTIDADE

Se você publicar cópias do Documento em número maior que 100, e a nota de licença doDocumento obrigar Textos de Capa, você precisará incluir as cópias em capas que tragam, clarae legivelmente, todos esses Textos de Capa: Textos de Capa da Frente na capa da frente, eTextos da Quarta Capa na capa de trás. Ambas as capas também precisam identificar clara elegivelmente você como o editor dessas cópias. A capa da frente precisa apresentar o título com-pleto com todas as palavras do título igualmente proeminentes e visíveis. Você pode adicionaroutros materiais às capas. Fazer cópias com modificações limitadas às capas, tanto quanto estaspreservem o título do documento e satisfaçam a essas condições, pode ser tratado como cópiaexata em outros aspectos.

Se os textos requeridos em qualquer das capas for muito volumoso para caber de formalegível, você deve colocar os primeiros (tantos quantos couberem de forma razoável) na capaverdadeira, e continuar os outros nas páginas adjacentes.

Se você publicar ou distribuir cópias Opacas do Documento em número maior que 100, vocêprecisa ou incluir uma cópia Transparente que possa ser lida automaticamente com cada cópiaOpaca, ou informar, em ou com, cada cópia Opaca a localização de uma cópia Transparentecompleta do Documento acessível publicamente em uma rede de computadores, à qual o públicousuário de redes tenha acesso a download gratuito e anônimo utilizando padrões públicos deprotocolos de rede. Se você utilizar o segundo método, você precisará tomar cuidados razoavel-mente prudentes, quando iniciar a distribuição de cópias Opacas em quantidade, para assegurarque esta cópia Transparente vai permanecer acessível desta forma na localização especificadapor pelo menos um ano depois da última vez em que você distribuir uma cópia Opaca (direta-mente ou através de seus agentes ou distribuidores) daquela edição para o público.

É pedido, mas não é obrigatório, que você contate os autores do Documento bem antes deredistribuir qualquer grande número de cópias, para lhes dar uma oportunidade de prover vocêcom uma versão atualizada do Documento.

14


MODIFICAÇÕES

Você pode copiar e distribuir uma Versão Modificada do Documento sob as condições das se-ções 2 e 3 acima, desde que você publique a Versão Modificada estritamente sob esta Licença,com a Versão Modificada tomando o papel do Documento, de forma a licenciar a distribuiçãoe modificação da Versão Modificada para quem quer que possua uma cópia da mesma. Alémdisso, você precisa fazer o seguinte na versão modificada:

A. Usar na Página de Título (e nas capas, se houver alguma) um título distinto daquele do Do-cumento, e daqueles de versões anteriores (que deveriam, se houvesse algum, estarem listadosna seção "Histórico do Documento"). Você pode usar o mesmo título de uma versão anterior seo editor original daquela versão lhe der permissão;

B. Listar na Página de Título, como autores, uma ou mais das pessoas ou entidades responsá-veis pela autoria das modificações na Versão Modificada, conjuntamente com pelo menos cincodos autores principais do Documento (todos os seus autores principais, se ele tiver menos quecinco);

C. Colocar na Página de Título o nome do editor da Versão Modificada, como o editor;

D. Preservar todas as notas de copyright do Documento;

E. Adicionar uma nota de copyright apropriada para suas próprias modificações adjacente àsoutras notas de copyright;

F. Incluir, imediatamente depois das notas de copyright, uma nota de licença dando ao públicoo direito de usar a Versão Modificada sob os termos desta Licença, na forma mostrada no tópicoabaixo;

G. Preservar nessa nota de licença as listas completas das Seções Invariantes e os Textos deCapa requeridos dados na nota de licença do Documento;

H. Incluir uma cópia inalterada desta Licença;

I. Preservar a seção entitulada "Histórico", e seu título, e adicionar à mesma um item dizendopelo menos o título, ano, novos autores e editor da Versão Modificada como dados na Página deTítulo. Se não houver uma sessão denominada "Histórico"no Documento, criar uma dizendo otítulo, ano, autores, e editor do Documento como dados em sua Página de Título, então adicionarum item descrevendo a Versão Modificada, tal como descrito na sentença anterior;

J. Preservar o endereço de rede, se algum, dado no Documento para acesso público a umacópia Transparente do Documento, e da mesma forma, as localizações de rede dadas no Docu-mento para as versões anteriores em que ele foi baseado. Elas podem ser colocadas na seção"Histórico". Você pode omitir uma localização na rede para um trabalho que tenha sido publicadopelo menos quatro anos antes do Documento, ou se o editor original da versão a que ela se refirader sua permissão;

K. Em qualquer seção entitulada "Agradecimentos"ou "Dedicatórias", preservar o título da

15


seção e preservar a seção em toda substância e fim de cada um dos agradecimentos de contri-buidores e/ou dedicatórias dados;

L. Preservar todas as Seções Invariantes do Documento, inalteradas em seus textos ou emseus títulos. Números de seção ou equivalentes não são considerados parte dos títulos da seção;

M. Apagar qualquer seção entitulada "Endossos". Tal sessão não pode ser incluída na VersãoModificada;

N. Não reentitular qualquer seção existente com o título "Endossos"ou com qualquer outrotítulo dado a uma Seção Invariante.

Se a Versão Modificada incluir novas seções iniciais ou apêndices que se qualifiquem comoSeções Secundárias e não contenham nenhum material copiado do Documento, você pode optarpor designar alguma ou todas aquelas seções como invariantes. Para fazer isso, adicione seustítulos à lista de Seções Invariantes na nota de licença da Versão Modificada. Esses títulos preci-sam ser diferentes de qualquer outro título de seção.

Você pode adicionar uma seção entitulada "Endossos", desde que ela não contenha qual-quer coisa além de endossos da sua Versão Modificada por várias pessoas ou entidades - porexemplo, declarações de revisores ou de que o texto foi aprovado por uma organização como adefinição oficial de um padrão.

Você pode adicionar uma passagem de até cinco palavras como um Texto de Capa da Frente, e uma passagem de até 25 palavras como um Texto de Quarta Capa, ao final da lista de Textosde Capa na Versão Modificada. Somente uma passagem de Texto da Capa da Frente e uma deTexto da Quarta Capa podem ser adicionados por (ou por acordos feitos por) qualquer entidade.Se o Documento já incluir um texto de capa para a mesma capa, adicionado previamente porvocê ou por acordo feito com alguma entidade para a qual você esteja agindo, você não podeadicionar um outro; mas você pode trocar o antigo, com permissão explícita do editor anterior queadicionou a passagem antiga.

O(s) autor(es) e editor(es) do Documento não dão permissão por esta Licença para que seusnomes sejam usados para publicidade ou para assegurar ou implicar endossamento de qualquerVersão Modificada.

COMBINANDO DOCUMENTOS

Você pode combinar o Documento com outros documentos publicados sob esta Licença, sobos termos definidos na seção 4 acima para versões modificadas, desde que você inclua na com-binação todas as Seções Invariantes de todos os documentos originais, sem modificações, e listetodas elas como Seções Invariantes de seu trabalho combinado em sua nota de licença.

O trabalho combinado precisa conter apenas uma cópia desta Licença, e Seções InvariantesIdênticas com multiplas ocorrências podem ser substituídas por apenas uma cópia. Se houvermúltiplas Seções Invariantes com o mesmo nome mas com conteúdos distintos, faça o título de

16


cada seção único adicionando ao final do mesmo, em parênteses, o nome do autor ou editororigianl daquela seção, se for conhecido, ou um número que seja único. Faça o mesmo ajustenos títulos de seção na lista de Seções Invariantes nota de licença do trabalho combinado.

Na combinação, você precisa combinar quaisquer seções entituladas "Histórico"dos diver-sos documentos originais, formando uma seção entitulada "Histórico"; da mesma forma combinequaisquer seções entituladas "Agradecimentos", ou "Dedicatórias". Você precisa apagar todas asseções entituladas como "Endosso".

COLETÂNEAS DE DOCUMENTOS

Você pode fazer uma coletânea consitindo do Documento e outros documentos publicadossob esta Licença, e substituir as cópias individuais desta Licença nos vários documentos comuma única cópia incluida na coletânea, desde que você siga as regras desta Licença para cópiaexata de cada um dos Documentos em todos os outros aspectos.

Você pode extrair um único documento de tal coletânea, e distribuí-lo individualmente sobesta Licença, desde que você insira uma cópia desta Licença no documento extraído, e siga estaLicença em todos os outros aspectos relacionados à cópia exata daquele documento.

AGREGAÇÃO COM TRABALHOS INDEPENDENTES

Uma compilação do Documento ou derivados dele com outros trabalhos ou documentos se-parados e independentes, em um volume ou mídia de distribuição, não conta como uma Ver-são Modificada do Documento, desde que nenhum copyright de compilação seja reclamado pelacompilação. Tal compilação é chamada um "agregado", e esta Licença não se aplica aos outrostrabalhos auto-contidos compilados junto com o Documento, só por conta de terem sido assimcompilados, e eles não são trabalhos derivados do Documento.

Se o requerido para o Texto de Capa na seção 3 for aplicável a essas cópias do Documento,então, se o Documento constituir menos de um quarto de todo o agregado, os Textos de Capado Documento podem ser colocados em capas adjacentes ao Documento dentro do agregado.Senão eles precisarão aparecer nas capas de todo o agregado.

TRADUÇÃO

Tradução é considerada como um tipo de modificação, então você pode distribuir traduçõesdo Documento sob os termos da seção 4. A substituição de Seções Invariantes por traduçõesrequer uma permissão especial dos detentores do copyright das mesmas, mas você pode incluirtraduções de algumas ou de todas as Seções Invariantes em adição às versões orignais dessasSeções Invariantes. Você pode incluir uma tradução desta Licença desde que você também in-clua a versão original em Inglês desta Licença. No caso de discordância entre a tradução e a

17


versão original em Inglês desta Licença, a versão original em Inglês prevalecerá.

TÉRMINO

Você não pode copiar, modificar, sublicenciar, ou distribuir o Documento exceto como expres-samente especificado sob esta Licença. Qualquer outra tentativa de copiar, modificar, sublicen-ciar, ou distribuir o Documento é nula, e resultará automaticamente no término de seus direitossob esta Licença. Entretanto, terceiros que tenham recebido cópias, ou direitos de você sob estaLicença não terão suas licenças terminadas, tanto quanto esses terceiros permaneçam em totalacordo com esta Licença.

REVISÕES FUTURAS DESTA LICENÇA

A Free Software Foundation pode publicar novas versões revisadas da Licença de Documen-tação Livre GNU de tempos em tempos. Tais novas versões serão similares em espirito à versãopresente, mas podem diferir em detalhes ao abordarem novos porblemas e preocupações. Vejahttp://www.gnu.org/copyleft/.

A cada versão da Licença é dado um número de versão distinto. Se o Documento especificarque uma versão particular desta Licença "ou qualquer versão posterior"se aplica ao mesmo, vocêtem a opção de seguir os termos e condições daquela versão específica, ou de qualquer versãoposterior que tenha sido publicada (não como rascunho) pela Free Software Foundation. Se oDocumento não especificar um número de Versão desta Licença, você pode escolher qualquerversão já publicada (não como rascunho) pela Free Software Foundation.

ADENDO: Como usar esta Licença para seus documentos

Para usar esta Licença num documento que você escreveu, inclua uma cópia desta Licençano documento e ponha as seguintes notas de copyright e licenças logo após a página de título:

Copyright (c) ANO SEU NOME.É dada permissão para copiar, distribuir e/ou modificar este documento sob os termos da Licençade Documentação Livre GNU, Versão 1.1 ou qualquer versão posterior publicada pela Free Soft-ware Foundation; com as Seções Invariantes sendo LISTE SEUS TÍTULOS, com os Textos daCapa da Frente sendo LISTE, e com os Textos da Quarta-Capa sendo LISTE. Uma cópia da li-cença está inclusa na seção entitulada "Licença de Documentação Livre GNU".

Se você não tiver nenhuma Seção Invariante, escreva "sem Seções Invariantes"ao invés dedizer quais são invariantes. Se você não tiver Textos de Capa da Frente, escreva "sem Textos deCapa da Frente"ao invés de "com os Textos de Capa da Frente sendo LISTE"; o mesmo para osTextos da Quarta Capa.

Se o seu documento contiver exemplos não triviais de código de programas, nós recomenda-mos a publicação desses exemplos em paralelo sob a sua escolha de licença de software livre,

18


tal como a GNU General Public License, para permitir o seu uso em software livre.

19

Parte IV

Modelagem orientada a objeto

20

Capítulo 1

O que é a modelagem orientada aobjeto

Em um processo de desenvolvimento de softwares; a equipe precisa, após passado por umprocesso de levantamento de requisitos básicos, modelar e projetar a estrutura e o comporta-mento do software para que este possa ser concretizado. Este processo de modelagem e projetode um software, muitas vezes, necessita de capacitação especial que não pode ser ainda imitadopor um simples computador.

Este curso mostrará alguns passos e técnicas úteis para a modelagem de sistemas em diver-sos níveis de abstração, visando como artefato final um modelo orientado a objeto. Utilizaremosa linguagem UML como linguagem de representação e documentação para as diversas etapasde modelagem estática e dinâmica do programa. Adicionalmente, alguns design-patterns serãoapresentados para melhorar a escalabilidade e qualidade do seu modelo. Os exemplos em códigofonte serão dadas em linguagem Java.

21

Capítulo 2

Plano de ensino

2.1 Objetivo

Qualificar técnicos e programadores para a modelagem e projeto de softwares adotando oparadigma orientado a objetos. Para a linguagem de modelagem, usaremos o UML.

2.2 Público Alvo

Técnicos e programadores que desejam projetar softwares orientados a objeto.

2.3 Pré-requisitos

Os usuários devem ter conhecimento razoável do paradigma orientado a objeto, conhecer obásico de UML e noções iniciais sobre engenharia de software. Conhecimento da linguagem deprogramação Java também é desejado.

2.4 Descrição

O curso de modelagem orientada a objeto será realizado na modalidade EAD e utilizará aplataforma Moodle como ferramenta de aprendizagem. O material didático estará disponível on-line de acordo com as datas pré-estabelecidas no calendário.

Todo o material está no formato de lições, e estará disponível ao longo do curso. As liçõespoderão ser acessadas quantas vezes forem necessárias. Aconselhamos a leitura de "Ambien-tação do Moodle", para que você conheça o produto de Ensino a Distância, evitando dificuldadesadvindas do "desconhecimento"sobre o mesmo.

Ao final de cada semana do curso será disponibilizada a prova referente ao módulo estudadoanteriormente que também conterá perguntas sobre os textos indicados. Utilize o material decada semana e os exemplos disponibilizados para se preparar para prova.

Os instrutores estarão a sua disposição ao longo de todo curso. Qualquer dúvida deve serdisponibilizada no fórum ou enviada por e-mail. Diariamente os monitores darão respostas eesclarecimentos.

22


2.5 Metodologia

O curso está dividido da seguinte maneira:

2.6 Cronograma

• Primeira semana:

– Introdução à modelagem orientada a objeto;

– Análise inicial do modelo de negócio;

– Estimativa do modelo de implantação;

– Análise de requisitos através de casos de uso;

– Modelo de análise;

– Modelo de projeto;

– Modelo de implementação;

– Documentação da implantação.

• Segunda semana:

– Abstract Factory e Factory Method;

– Builder e Singleton;

– Adapter e Bridge;

– Composite e Decorator;

– Visitor e Observer;

– Command e Iterator.

• Terceira semana:

– Anti-patterns de design;

– Outras categorias de anti-pattern;

– Avaliação de aprendizagem;

– Avaliação do curso.

As lições contêm o conteúdo principal. Elas poderão ser acessadas quantas vezes forem neces-sárias, desde que esteja dentro da semana programada. Ao final de uma lição, você receberáuma nota de acordo com o seu desempenho. Responda com atenção às perguntas de cada li-ção, pois elas serão consideradas na sua nota final. Caso sua nota numa determinada lição sejamenor do que 6.0, sugerimos que você faça novamente esta lição.Ao final do curso será disponibilizada a avaliação referente ao curso. Tanto as notas das liçõesquanto a da avaliação final serão consideradas para a nota final. Todos os módulos ficarão visí-veis para que possam ser consultados durante a avaliação final.Aconselhamos a leitura da "Ambientação do Moodle"para que você conheça a plataforma de En-sino a Distância, evitando dificuldades advindas do "desconhecimento"sobre a mesma.Os instrutores estarão a sua disposição ao longo de todo curso. Qualquer dúvida deverá serenviada ao fórum. Diariamente os monitores darão respostas e esclarecimentos.

23


2.7 Programa

O curso de modelagem orientada oferecerá o seguinte conteúdo:

• Semana 1:

– Processos de modelagem;

– Etapas de uma modelagem.

• Semana 2:

– Padrões de design;

– Padrões estruturais;

– Padrões de comportamento.

• Semana 3:

– Anti-Pattern, os "inimigos"de um bom design;

– Avaliações.

2.8 Avaliação

Toda a avaliação será feita on-line.Aspectos a serem considerados na avaliação:

• iniciativa e autonomia no processo de aprendizagem e de produção de conhecimento;

• capacidade de pesquisa e abordagem criativa na solução dos problemas apresentados.

Instrumentos de avaliação:

• participação ativa nas atividades programadas;

• avaliação ao final do curso;

• o participante fará várias avaliações referentes ao conteúdo do curso. Para a aprovação eobtenção do certificado o participante deverá obter nota final maior ou igual a 6.0 de acordocom a fórmula abaixo:

• Nota Final = ((ML x 7) + (AF x 3)) / 10.

• ML = Média aritmética das lições.

• AF = Avaliações.

24


2.9 Bibliografia

• Cursos CDTC, UML:

– <http://cursos.cdtc.org.br>;

– <http://comunidade.cdtc.org.br>.

• Wikipedia, anti-patterns:

– <http://en.wikipedia.org/wiki/Anti-pattern>;

– <http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%B3%E3%83%81%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3>;

– <http://es.wikipedia.org/wiki/Antipatr%C3%B3n_de_dise%C3%B1o>.

• Wikipedia, design-patterns:

– <http://en.wikipedia.org/wiki/Design_patterns>;

– <http://es.wikipedia.org/wiki/Design_Patterns>;

– <http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29>;

– <http://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_%28%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%29>.

• Lista de imagens:

– Logotipo do curso, autor: Shou Matsumoto;

– Diagramas UML de "Processos de modelagem", autor: Shou Matsumoto, ferramenta:JUDE-community;

– Diagramas UML de "Padrões de design":

* <http://pt.wikipedia.org/wiki/Imagem:Abstract_Factory.gif>

* <http://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F:Factory_Method_UML_class_diagram.svg>

* <http://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F:Builder_UML_class_diagram.svg>

* <http://pt.wikipedia.org/wiki/Imagem:Builder_%28padr%C3%A3o%29.png>

* <http://pt.wikipedia.org/wiki/Imagem:Singleton.png>

* <http://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F:Adapter_using_inheritance_UML_class_diagram.svg>

* <http://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F:Adapter_using_delegation_UML_class_diagram.svg>

* <http://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F:Bridge_UML_class_diagram.svg>

* <http://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F:Composite_UML_class_diagram.svg>

* <http://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F:Decorator_UML_class_diagram.svg>

25


* <http://zh.wikipedia.org/w/index.php?title=Image:Visitor_UML_class_diagram.svg&variant=zh-cn>

* <http://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F:Observer-pattern-uml.jpg>

26

Capítulo 3

Processos de modelagem

Nesta seção, mostraremos alguns processos de elaboração e documentação de modelos paradesenvolver seu programa.

3.1 Introdução à modelagem orientada a objeto

3.1.1 A modelagem orientada a objeto

A etapa de modelagem (algumas vezes referenciada como etapa de design e/ou de projeto) éuma etapa muito importante no processo de desenvolvimento de softwares. Na visão geral, o quedetermina a qualidade técnica do seu sistema (como portabilidade, manutenibilidade e produti-vidade) está na organização macroscópica do seu sistema; ou seja, está em como os diversoscomponentes do sistema interagem em diversos níveis de abstração.

No nosso curso, podemos entender a "modelagem"como as etapas de análise de requisitos,determinação dos requisitos técnicos do sistema, determinação dos componentes e módulosdigitais do sistema, determinação de algoritmos e parte da documentação (ou seja, seria toda aetapa de desenvolvimento de sistemas, fora a "conversa com cliente", a programação - digitação- propriamente dita e a manutenção do sistema).

3.1.2 A abordagem deste curso

Este curso mostrará uma parte da didática, dicas e métodos interessantes para melhorar aqualidade de seu modelo de software. Para isso, o processo de modelagem foi dividido nas se-guintes etapas:

• análise do domínio de negócio;

• modelagem da implantação;

• análise de requisitos;

• modelagem abstrata;

27


• modelagem concreta (ou modelo de projeto e modelo de implementação).

Note que nem todas as equipes usarão essa divisão. Este curso tem como objetivo mostrarum exemplo simples de desenvolvimento, para que algumas técnicas possam ser adaptadas parao processo utilizado pela sua equipe de desenvolvimento.

Certamente haverá métodos melhores do que os apresentados neste curso. Lembre-se queeste curso tem objetivos didáticos, não sendo então um relatório do estado de arte do processode desenvolvimento de softwares.

3.1.3 Otimizações apresentadas neste curso

Neste curso, além de exemplos de diagramas, mostraremos alguns conceitos de otimizaçãode modelo, conhecidos como design patterns.

Adicionalmente, seu conceito inverso (ou seja, técnicas para piorar seu projeto) será apresen-tado. São eles os anti-patterns e devem ser evitados.

Os design patterns estarão detalhados no segundo módulo deste curso. Os anti-patterns se-rão apresentados no terceiro módulo.

As técnicas de refatoração não serão apresentadas neste curso, uma vez que podemosentendê-las como técnicas de manutenção de sistema, e não como técnica de modelagem pro-priamente dita.

Preciso avisar aqui que não devemos exagerar na aplicação dessas técnicas no seu sistema.Não é consistente usarmos técnicas avançadas para um sistema muito simplicista. Essa mode-lagem excessiva é conhecida como over design e é uma má prática de projeto.

Afinal, o bom senso sempre deve existir. Uma modelagem de software deve sempre estarde acordo com a exigência e com o recurso atribuído à equipe. Claro, não é muito inteligenteusarmos uma bomba atômica para matar uma barata, não?

28

Capítulo 4

Etapas de uma modelagem

Nesta seção, mostraremos algumas etapas a passar em uma modelagem para facilitar o pro-cesso de desenvolvimento do software.

4.1 Análise inicial do modelo de negócio

4.1.1 Modelo de negócio

Um modelo de negócio representa a sua organização e sua atividade (é o domínio do negó-cio). É melhor mantermos documentado o domínio, os requisitos levantados para o seu sistema emais alguns documentos que permitam inferir o background que gerou a demanda pelo sistema.

Ao utilizar projetos UML (a exemplo, um arquivo .jude na ferramenta JUDE), é bom criarmosuma pasta (ou um pacote) com o nome "modelo de negócio"para mantermos textos e diagramasque identifiquem a base da sua organização. Seria interessante mantermos um organograma, alista de requisitos do sistema, os fluxogramas do processo de produção da sua organização.

Note que o modelo de negócio não é tão crucial para o desenvolvimento de sistemas, mas éuma ferramenta útil para familiarizar rapidamente novos membros de desenvolvimento ou quandoa equipe é suficientemente grande.

Neste curso, mostraremos superficialmente os conceitos sobre o modelo de negócio, umavez que ele não é a parte central do processo de modelagem. Como ilustração, os modelosmostrados neste curso representarão um sistema bancário simples.

4.1.2 Documentação dos requisitos

Dentro do pacote (de documentação), podemos criar um documento que indique os requisi-tos do sistema. Vale lembrar que devemos manter esse documento acessível a todos da equipee cada requisito deve ser verificável e consistente (não documente requisitos abstratos demaisou contraditórios). Geralmente, é da responsabilidade do projetista vetar requisitos visivelmenteerrôneos. É importante, portanto, conhecermos algumas características de bons requisitos.

29


É errado mantermos requisitos do tipo "o sistema deve ser o mais rápido possível"(abstratodemais, pois qualquer coisa é o "mais rápido possível") ou "o software deve ser licenciado porGPL"junto com o requisito "o código fonte deve ser mantido em sigilo"(contraditório, segundo re-gras da GPL). Esse tipo de requisito deve ser detido nesta etapa.

Todos os requisitos devem ser identificáveis por um nome próprio. É comum usarmos núme-ros para identificar requisitos (Ex. requisito 1, requisito 2 ...). Lembre-se sempre que a validaçãodo software está sempre de acordo com os requisitos (se o software cumpre exatamente todos osrequisitos, um por um, o software é válido). Precisamos ter cuidado em dobro para não criarmossoftwares válidos, mas inúteis.

30


31


Observe que existem projetos que levantam requisitos em dois (ou mais) níveis de abstração:abstrato e concreto. Nessa abordagem, os requisitos abstratos são geralmente resultados debrainstorming (processo de expressão livre de idéias) e os requisitos concretos são o resultadoda avaliação profissional dos abstratos.

32


4.2 Estimativa do modelo de implantação

4.2.1 Modelo inicial de implantação

Alguns requisitos repassados para a modelagem podem especificar plataformas ou organi-zação física do sistema. Nesse caso, seria melhor modelarmos inicialmente um diagrama deimplantação, indicando a estrutura física onde o sistema será executado.

Esse tipo de diagrama primordial é particularmente útil para avaliarmos requisitos secundários(aqueles deduzidos a partir dos requisitos). Por exemplo, suponha que um requisito indique quedevemos proteger o sistema (distribuído sobre uma LAN) contra ataques como ARP spoofing. Aomodelarmos a estrutura da LAN, podemos identificar quais são os pontos mais estratégicos.

Essa estruturação, nesta etapa de desenvolvimento, pode ser virtual (ou seja, não neces-sariamente precisa refletir fielmente os dispositivos físicos). Por exemplo, suponha um sistemacliente-servidor. Nesse caso, modelamos dois nós no mínimo (um representando cliente e outrorepresentando o servidor), mesmo que ambos possam, na realidade, ser atuados pelo mesmocomputador.

Na página seguinte, mostraremos um exemplo simples de um diagrama inicial de implantação,resultante dos requisitos identificados no modelo de negócio.

4.2.2 Diagrama de implantação - estimativa

Segue abaixo um exemplo simples de diagrama inicial de implantação.

É sempre bom referirmos qual(is) requisito(s) originara(m) o diagrama. Algumas ferramentaspermitem que cada elemento contenha um comentário; é bom tirarmos proveito dessa utilidade

33


para indicarmos o requisito original. Caso sua ferramenta não tenha essa utilidade, devemos do-cumentar com o elemento "anotações"(que é um quadrilátero com um canto dobrado, padrão noUML).

OBS. Esse diagrama foi gerado a partir dos requisitos 18-21 da lista de requisitos da liçãoanterior.

4.3 Análise de requisitos através de casos de uso

4.3.1 Casos de uso

Diagramas de casos de uso são úteis para uma análise mais profunda dos requisitos, na ge-ração dos requisitos detalhados e na modelagem das funcionalidades que o sistema mostrará.Nesta etapa, modelamos cada caso de uso de acordo com o requisito (ou seja, aqui tambémdevemos documentar quais requisitos geraram cada caso de uso). A rastreabilidade entre cadaetapa de modelagem é importante para mantermos formal o processo de desenvolvimento.

Nas páginas seguintes, mostraremos alguns exemplos de modelos de casos de uso. Como adocumentação do requisito que os originaram que estão incorporados no mecanismo de "comen-tários"do JUDE, eles não estão visíveis.

Note que os casos de uso não devem estar dependentes de detalhes de implementação ouimplantação. Eles devem ser uma representação extremamente abstrata das operações feitaspor agentes (geralmente usuários ou outros sistemas) sobre o seu sistema.

4.3.2 Autenticação de usuários

Esses diagramas de caso de uso são interessantes para, além de modelar uma funcionali-dade abstrata do sistema, mostrar a relação considerada entre atores e cada caso de uso (comoa definição de atores através de composição de atores, ou a definição de casos de uso atravésde outros casos de uso).

O exemplo abaixo mostra o relacionamento entre atores:

34


O exemplo abaixo esquematiza casos de uso sobre a autenticação de usuários no nosso sis-tema bancário simples.

Como podemos ver, os casos de uso são representações abstratas de funcionalidade e nãoprecisam modelar fluxo de dados. Nas páginas a seguir, mostraremos outros casos de uso donosso sistema bancário.

35


4.3.3 Controle de contas

Segue abaixo outros exemplos de casos de uso para nosso sistema bancário simples.

Segue abaixo um esquema que relaciona os casos de uso.

36


4.3.4 Gerenciamento de contas

Segue abaixo outros exemplos de casos de uso. As setas pontilhadas sem estereótipo indi-cam dependência (no caso abaixo, para criar uma conta investimento, precisamos verificar se aconta corrente existe, portanto, é dependente).

37


4.3.5 Saque e depósito

Seguem mais exemplos:

38


4.3.6 Extrato e saldo

39


4.3.7 Manutenção do cadastro de clientes

40


4.4 Modelos de análise

4.4.1 Os modelos de análise

Os modelos de análise fazem a ponte entre os casos de uso e a estruturação detalhada dosistema (as classes em Java, por exemplo). Basicamente, modelamos diagramas de classes paraa estrutura primordial do sistema. Opcionalmente, podemos modelar diagramas de colaboração(para a comunicação entre as classes) e diagramas de estados (para modelar esquemas com-plexos de mudança de estados do sistema). Ele é uma etapa muito importante da modelagem,pois identifica os módulos contidos no seu programa.

No diagrama de classes, basicamente separamos os casos de uso em três classes abstra-tas: as entidades, as controladoras e as interfaces. Adicionalmente, podemos identificar quetipo de dados serão utilizados pelo nosso sistema provisoriamente (a princípio, no nosso sistemabancário teremos dados como "conta corrente", "conta investimento", "dinheiro", "dados do usuá-rio", etc).

As entidades representam elementos de armazenamento ou elementos de representação.As controladoras são responsáveis pela coordenação entre entidades e as interfaces são oselementos diretamente acessivés pelos atores (ou usuários dos sistemas), que são na maioriados casos a tela do sistema.

Vale notar aqui que as "classes"identificadas nesta etapa não precisam ser diretamente ma-peáveis para uma linguagem de programação. Elas ainda são classes ideais (representam so-

41


mente idéias sobre um determinado elemento), portanto, seus nomes não precisam seguir asregras de nomenclatura de alguma linguagem de programação em particular.

Os diagramas de colaboração aqui servem para identificar protolocolos de comunicação en-tre objetos instanciados das "classes"anteriormente descritas. Na verdade, elas são necessáriassomente quando a troca de informação entre as classes são complexas. Se todos os modelos es-tão precisando de um diagrama de colaboração, então seu modelo está complexo demais. Podeser uma falha de algoritmo.

Um diagrama de estado pode ser usado para simplificar a visualização de um algoritmo com-plexo ou para literalmente representar um autômato de estados finitos. Se seu sistema é simples,muitas vezes este diagrama não é necessário.

Nas páginas seguintes, mostraremos alguns exemplos de diagramas gerados nesta etapa.Aviso aqui novamente que nem todos precisam seguir estritamente esta ordem. Tentem adaptá-las para a sua necessidade.

Observe que até aqui (inclusive nesta etapa), a modelagem pode ser tanto para sistemas ori-entados ou não a objetos. Somente na próxima etapa, nos modelos de projeto, é que a orientaçãoa objeto refletirá consideravelmente nos diagramas.

4.4.2 Interface, controle e entidade

Identificamos aqui nossas "classes"(ou simplesmente elementos) de interface (fronteira ou vi-são), controle (ou negócio) e entidade (ou modelo).

Esses elementos podem ser identificados gradativamente, de acordo com o progresso da mo-delagem de análise. No nosso caso, resolvemos apresentá-los primeiro.

Aviso aqui novamente que essas "classes"são representações e não seguem a estrutura declasses de alguma linguagem orientada a objeto; portanto, podem ser adaptadas para linguagensprocedurais também.

Segue abaixo:

42


Interface

43


Controle

Entidade

44


4.4.3 Realizações de casos de uso

Observem que os diagramas da etapa de modelagem de análise devem ser realizações decasos de uso, portanto, eles são basicamente um detalhamento dos casos de uso.

Nas páginas seguintes, mostraremos exemplos de diagramas de classes, diagramas de co-laboração e alguns diagramas que indicam quais os casos de uso que foram mapeados paraaqueles diagramas.

Normalmente, é comum organizamos os diagramas (e as documentações) em pastas querepresentam uma atividade ou caso de uso. Nesse caso, seria bom criarmos um diagrama quedocumente a relação lógica entre cada pasta que compõe a documentação. A exemplo:

Segue nas próximas páginas alguns diagramas exemplos.

4.4.4 Autenticação de usuários

Seguem abaixo os diagramas do modelo de análise que realizam os casos de uso de auten-ticação de usuários do banco.

45


Diagrama de classes

Diagrama de colaboração

Note que somente modelamos colaborações em caso de sucesso (não modelamos o retornode mensagem de erro).

46


Mapeamento dos casos de uso

4.4.5 Exemplos: controle de informações da conta

Segue abaixo outros exemplos de modelos de análise.

47


Mapeamento de casos de uso

48


Diagrama, cliente obtém saldo das contas

4.4.6 Exemplo de diagrama de estado

Segue abaixo um exemplo de diagrama de estado que modela a transição de um sistema dematrícula em cursos. Ele não faz parte do nosso sistema bancário simples, mas é um interessanteexemplo para modelar comportamentos.

49


4.5 Modelo de projeto - alto nível

4.5.1 Modelo de alto nível

O modelo de alto nível detalha os modelos de análise e já visa a estrutura final do sistema.Apesar de já estarmos nos níveis finais de modelagem do software, esta etapa ainda não deveconsiderar a linguagem de programação em particular (no sentido de não dever referenciar bi-bliotecas particulares, particularidades da linguagem ou construções que só uma determinadalinguagem permite).

Basicamente, temos nesta etapa os modelos de subsistema, modelos em camada (visão,controle e modelo; também conhecidos como apresentação, negócio e persistência), divisãoem módulos e diagramas de seqüência (modelam interações avançadas e a ordem que infor-mações são passadas entre módulos de softwares).

Alguns dos modelos acima não são obrigatórios para muitos sistemas, como no caso dos mo-delos de subsistema e os diagramas de seqüência. A princípio, os modelos de subsistema nãosão necessários para sistemas que não podem ser subdivididos em componentes independen-tes, e os diagramas de seqüência não são importantes quando a comunicação entre os objetosnão é tão complexa.

Observe que, como ainda não inserimos peculiaridades da linguagem de programação, estaetapa da modelagem pode ainda ser utilizada para processos de desenvolvimento não orientadoa objeto.

Nesta etapa, modelaremos algumas interfaces. Lembre que elas não são exatamente "inter-faces"do Java. Eles são interfaces ideais, podendo serem compostas por diversas "interfaces"(oudefinições de funções) ou não.

4.5.2 Divisão em subsistemas

Se forem identificados componentes completos e independentes no seu sistema, podemosdividi-lo em subsistemas. Segue abaixo alguns exemplos de diagrama.

50


Como podem ver, os subsistemas no UML são geralmente estereótipos de pacotes e contêminterfaces que fazem a ligação entre cada subsistema.

51


Adicionalmente, seria importante documentarmos a rastreabilidade com os modelos feito an-teriormente.

Note que os subsistemas devem ser componentes necessários e auto suficientes do seusistema. O exemplo acima do banco é somente para ilustrar um modelo de subsistemas, poisnão são subsistemas auto-suficientes (pois todos necessitam, em algum ponto, do subsistema depersistência).

4.5.3 Detalhamento de subsistemas

Normalmente, quando criamos subsistemas, detalhamo-os como uma composição de módu-los. Segue abaixo um exemplo:

52


Como podem ver, o subsistema é composto por módulos de softwares. O módulo pode ser in-terpretado tanto como conjunto de classes (em caso de linguagem orientado a objeto) tanto comoconjunto de funções (em linguagens procedurais), que exercem funcionalidades relacionadas aum mesmo tema e que em conjunto realizam uma atividade consistente.

4.5.4 Divisão em camadas

É uma maneira comum de dividirmos um sistema para facilitar o desenvolvimento (divida econquiste). O comum é a divisão por nível de abstração (em interface, negócio e persistência,aqueles que, respectivamente, tratam da fronteira com o usuário, com a coordenação entre enti-dades e da representação das entidades ou dados).

Observe que essa divisão nem sempre é imediata. Por exemplo, as classes orientadas a ob-jeto que representam dados devem tratar, além das estruturas de dados, as operações que sãofeitas sobre o mesmo (devendo então ter conhecimento do negócio também).

53


Segue abaixo um exemplo de divisão:

Camadas são divisões lógicas do programa, portanto, não possuem uma representantçãoem linguagens de programação (ou seja, não podemos declarar uma "camada"em um programa;devemos somente documentar que tais componentes fazem parte da mesma camada). Pararealizá-la, devemos subdividi-la em módulos (como ocorre também em subsistemas). Segueabaixo um exemplo de divisão:

54


4.5.5 Diagramas de seqüência

Alguns componentes (camadas, subsistemas ou módulos) podem conter algoritmos (ou proto-colos) complexos que sejam difíceis de se visualizar com meros diagramas estáticos de classes.Nesse caso, devemos usar diagramas dinâmicos UML, como os diagramas de seqüência.

Apesar de não ser obrigatório, seria interessante documentarmos também a origem que cau-sou o surgimento do diagrama. Veja abaixo para um exemplo de diagrama que mapeia a origem:

55


No diagrama acima, podemos ver que os diagramas de seqüência representam funcionalida-des contidas nos respectivos subsistemas.

56


4.6 Modelo de projeto - detalhado

4.6.1 Modelo de projeto - detalhado

Esta etapa consiste basicamente em detalharmos os módulos identificados no projeto de altonível. É a partir desta etapa que todas as particularidades das linguagens de programação en-tram em vigor, como as classes em orientação a objeto.

Aqui podemos identificar e documentar elementos como classes, implementações, tabelas debanco de dados, aplicações (e documentações) de design patterns, especificação de bibliotecas,algoritmos e protocolos (usando diagramas de seqüência, por exemplo), etc.

Conceitos sobre design patterns serão detalhados mais adiante. Neste momento, pense-oscomo padrões para boas práticas de modelagem.

4.6.2 Exemplo de detalhamento de módulo

Abaixo, detalhamos o módulo de autenticação da camada de apresentação. Como somenteas classes presentes na camada de apresentação estão presentes, as interfaces da camada denegócio estão isolados (sem implementações).

O diagrama deve ser o mais detalhado possível, a ponto de permitir geração automáticade templates de código fonte através de uma ferramenta computacional.

57


Ao usar design patterns, seria interessante indicar quais classes implementam quais mem-bros do design pattern. Podemos fazer isso da maneira abaixo:

58


Observe que o design pattern é representado como um estereótipo de pacotes. Em um dia-grama separado, você pode mostrar como o design pattern é estruturado (dentro do pacote quevocê usou para estereotipar o design pattern).

59


4.6.3 Tabelas do banco de dados

No modelo de projeto detalhado, podemos especificar as tabelas do banco de dado. Essadocumentação é muito importante, pois atualmente muitos aplicativos confiam em sistemas debanco de dados na sua aplicação.

60


Esse esquema será diretamente mapeado à linguagem do seu banco de dados (provavel-mente será em SQL).

4.6.4 Diagramas de seqüência

Em um projeto detalhado, não basta a modelagem estática para entendermos o correto fun-cionamento do sistema. Precisamos de um modelo estático que especificará o comportamentodinâmico das instâncias das classes. Isso é feito através de diagramas de seqüência, do UML.

61


Note que os diagramas de seqüência são muito importantes no projeto detalhado, pois elesespecificam algoritmos ou protocolos. A modelagem dinâmica, junto ao estático (diagrama declasses) permitem a visualização mais completa do sistema.

62


4.7 Documentação da implantação

4.7.1 Instanciação do diagrama de implantação

Lembram-se do diagrama de implantação que fizemos inicialmente, para a análise? Agora,especificaremos instâncias daqueles nós para indicarmos o ambiente definitivo que o sistemaentrará em execução ou ambientes usados para teste.

Na verdade, o diagrama deve conter, com o uso de anotações do UML, detalhes sobre a es-pecificação de cada nó (como sistema operacional, velocidade, softwares instalados, etc). Nocaso do nosso diagrama, isto não está visível, pois usamos o recurso de comentário do próprioJUDE para esse fim (visando manter o diagrama mais limpo).

Podemos também documentar as implantações que o sistema definitivamente suportará (jáque modelamos detalhes suficientes para sabermos sobre isso).

Note que esta etapa não é tão crucial comparado com as etapas anteriores de modelagem,mas serve de boa documentação. Na verdade, você não precisa fazer diagramas duplicados.Basta atualizar o diagrama de implantação anterior.

63

Capítulo 5

Padrões de design

Nesta semana, apresentaremos alguns padrões de modelagem conhecidos como design pat-terns. Eles melhorarão a manutenibilidade do seu programa.

5.1 Introdução aos design patterns

5.1.1 O que é um design pattern

O conceito de padrão de projeto (Design Patterns) foi criado na década de 70 pelo arquitetoChristopher Alexander em seus livros Notes on the Synthesis of Form, The Timeless Way of Buil-ding e A Pattern Language. Seu conceito pode ser definido como métodos e documentações parasoluções que foram um sucesso para determinados problemas. Eles podem ser interpretadoscomo recomendações para desviar de problemas já presenciados por outros.

Apesar de muitos design patterns não estarem diretamente ligados à "programação"propriamentedita (pois indicam boas práticas durante a etapa de projeto de software, não sua implementação),ele poderá melhorar consideravelmente o seu produto final, que é o software. Neste curso, mos-traremos alguns padrões que poderão ser usados para melhorar a qualidade de nossa modela-gem.

5.1.2 Design patterns na ciência da computação

Os padrões de projeto de software, também muito conhecido pelo termo original em inglês(Design Patterns), descrevem soluções para problemas recorrentes no desenvolvimento de siste-mas de software, geralmente orientados a objetos. Um padrão de projeto estabelece um nome edefine o problema, a solução, quando aplicar esta solução e suas conseqüências.

Os padrões de projeto visam facilitar a reutilização de soluções de design - isto é, soluçõesna fase de projeto do software, sem considerar ainda a reutilização de "código"propriamente dito.Também provê um vocabulário comum para o design, facilitando comunicação, documentação eaprendizado dos sistemas de software em nível de projeto.

64


É sugerido que o formato que a descrição de um padrão tenha cinco partes:

• nome: uma descrição essencial da solução, mais do que do problema ou do contexto;

• exemplo: uma ou mais figuras, diagramas ou descrições que ilustrem um protótipo deaplicação;

• contexto: a descrição das situações sob as quais o padrão se aplica;

• problema: uma descrição das forças e restrições envolvidos e como elas interagem;

• solução: relacionamentos estáticos e regras dinâmicas descrevendo como construir ar-tefatos de acordo com o padrão, freqüentemente citando variações e formas de ajustar asolução segundo as circunstâncias. Inclui referências a outras soluções e o relacionamentocom outros padrões de nível mais baixo ou mais alto.

E espera-se que os design patterns de software tenham as seguintes características:

• encapsulamento: um padrão encapsula um problema/solução bem definido. Ele deve serindependente, específico e formulado de maneira a ficar claro onde ele se aplica;

• generalidade: todo padrão deve permitir a construção de outras realizações a partir destepadrão;

• equilíbrio: quando um padrão é utilizado em uma aplicação, o equilíbrio dá a razão, relaci-onada com cada uma das restrições envolvidas, para cada passo do projeto. Uma análiseracional que envolva uma abstração de dados empíricos, uma observação da aplicação depadrões em artefatos tradicionais, uma série convincente de exemplos e uma análise desoluções ruins ou fracassadas pode ser a forma de encontrar este equilíbrio;

• abstração: os padrões representam abstrações da experiência empírica ou do conheci-mento cotidiano;

• abertura: um padrão deve permitir a sua extensão para níveis mais baixos de detalhe;

• combinatoriedade: os padrões são relacionados hierarquicamente. Padrões de alto nívelpodem ser compostos ou relacionados com padrões que endereçam problemas de nívelmais baixo.

5.1.3 Categorias de design patterns

Podemos organizar os design patterns em algumas categorias: de criação, estruturais ecomportamentais.

65


Os padrões de criação são relacionados à criação de objetos, os estruturais tratam das asso-ciações entre classes e objetos e os comportamentais das interações e divisões de responsabili-dades entre as classes ou objetos.

Neste curso, mostraremos alguns exemplos de design patterns que se adequam a essascategorias.

66

Capítulo 6

Padrões de criação

Nesta seção, apresentaremos alguns "creational patterns", padrões de modelagem relacio-nada a instanciação de classes.

6.1 Abstract Factory e Factory Method

6.1.1 Abstract Factory

Descrição

Este padrão permite a criação de famílias de objetos relacionados ou dependentes, atravésde uma única interface e sem que a classe concreta seja especificada.

Exemplo de uso

O padrão Abstract Factory pode ser utilizado na implementação de um toolkit que disponibilizecontroles que funcionam em diferentes interfaces gráficas, tal como Motif, GTK+ (GNOME) ou Qt(KDE).

Estas GUIs possuem diferentes padrões de controles visuais e, para facilitar a construção deaplicativos que interajam facilmente com diferentes interfaces gráficas, é interessante que se de-fina interfaces comuns para acesso aos controles, independentemente da GUI utilizada.

Este problema pode ser resolvido através de uma classe abstrata que declara uma interfacegenérica para criação dos controles visuais e de uma classe abstrata para criação de cada tipode controle. O comportamento específico, de cada um dos padrões tecnológicos contemplados,é implementado através de uma classe concreta. O aplicativo, ou "cliente", interage com o toolkitatravés das classes abstratas sem ter conhecimento da implementação das classes concretas.

67


Estrutura

Neste exemplo, a classe abstrata WidgetFactory possui duas especializações: MotifWidget-Factory para widgets Motif e QtWidgetFactory para widgets Qt. Essas especializações são clas-ses concretas capazes de "produzir"os elementos da interface gráfica. O cliente do toolkit ob-tém os elementos gráficos de que necessita através da classe (interface) WidgetFactory sem terconhecimento das classes concretas. Da mesma maneira, o cliente somente interage com asinterfaces que representam os elementos produzidos pela Abstract Factory (no exemplo, a classeJanela e a classe Botao).

Exemplo de código em Java

abstract class WidgetFactory {

public static WidgetFactory obterFactory() {

if(Configuracao.obterInterfaceGraficaAtual() == Configuracao.MotifWidget){

return new MotifWidgetFactory();

} else {

return new QtWidgetFactory();

}

}

public abstract Botao criarBotao();

68


}

class MotifWidgetFactory extends WidgetFactory {

public Botao criarBotao() {

return new BotaoMotif();

}

}

class QtWidgetFactory extends WidgetFactory {

public Botao criarBotao() {

return new BotaoQt();

}

}

abstract class Botao {

public abstract void desenhar();

}

class BotaoMotif extends Botao {

public void desenhar() {

System.out.println("Eu sou um botao Motif!");

}

}

class BotaoQt extends Botao {

public void desenhar() {

69


System.out.println("Eu sou um botao Qt!");

}

}

public class Cliente {

public static void main(String[] args) {

WidgetFactory factory = WidgetFactory.obterFactory();

Botao botao = factory.criarBotao();

botao.desenhar();

}

}

6.1.2 Factory Methods

Este design pattern fornece uma interface para criação de famílias de objetos relacionados oudependentes, sem especificar suas classes concretas, utilizando um "método de criação"de ins-tâncias e fazendo com que subclasses sejam responsáveis pela implementação desse "métodode criação".

Estrutura

70


O Factory Methods tem os seguintes componentes:

• Creator: declara o factory method (método de fabricação) que retorna o objeto da classeProduct (produto). Este elemento também pode definir uma implementação básica queretorna um objeto de uma classe ConcreteProduct (produto concreto) básica;

• ConcreteCreator: sobrescreve o factory method e retorna um objeto da classe Concrete-Product;

• Product: define uma interface para os objetos criados pelo factory method;

• ConcreteProduct: uma implementação para a interface Product.

Diferença com o Abstract Factory

Ambos são muito parecidos, entretanto, enquanto que o Factory Method foi sugerido paraacrescentar uma camada adicional de abstração na rotina de instanciação de um objeto, o Abs-tract Factory foi sugerido para ser uma classe que junta responsabilidades de criação de umconjunto de objetos relacionados. Muitas vezes, o Abstract Factory é usado em conjunto com aleitura de arquivos de configuração, enquanto que no Factory Method a Factory, o objeto respon-sável para a instanciação é mencionado pela classe que a usa.

Exemplo de uso

Podemos usar o Factory Method para, por exemplo, criar formulários:

import java.util.Map;

import java.util.HashMap;

abstract class TagFormatterFactory{

abstract TagFormatter getFormatter(String elementName);

}

abstract class TagFormatter{

private String elementName;

private Map<String,String> attributes;

TagFormatter(String elementName){

71


this.elementName = elementName;

this.attributes = new HashMap<String,String>();

}

private String getTagContents(){

StringBuilder tag = new StringBuilder();

tag.append("<").append(this.elementName);

for(Map.Entry<String,String> entry : this.attributes.entrySet()){

tag.append(" " + entry.getKey() + "=\"" + entry.getValue() + "\"");

}

return tag.toString();

}

final void addAttribute(String name, String value){

this.attributes.put(name, value);

}

final String getStartTag(){

return this.getTagContents() + ">";

}

final String getEndTag(){

return "</" + this.elementName + ">";

}

final String getEmptyTag(){

return this.getTagContents() + this.getEmptyTagSuffix();

}

abstract String getEmptyTagSuffix();

72


}

class HtmlTagFormatter extends TagFormatter{

HtmlTagFormatter(String elementName){

super(elementName);

}

String getEmptyTagSuffix(){

return ">";

}

}

class XhtmlTagFormatter extends TagFormatter{

XhtmlTagFormatter(String elementName){

super(elementName);

}

String getEmptyTagSuffix(){

return " />";

}

}

class HtmlTagFormatterFactory extends TagFormatterFactory{

TagFormatter getFormatter(String elementName) {

return new HtmlTagFormatter(elementName);

}

}

73


class XhtmlTagFormatterFactory extends TagFormatterFactory{

TagFormatter getFormatter(String elementName) {

return new XhtmlTagFormatter(elementName);

}

}

public class FactoryMethodTest {

private static String getForm(TagFormatterFactory factory){

TagFormatter form = factory.getFormatter("form");

form.addAttribute("method", "post");

form.addAttribute("action", "login");

TagFormatter dl = factory.getFormatter("dl");

TagFormatter dt = factory.getFormatter("dt");

TagFormatter dd = factory.getFormatter("dd");

TagFormatter p = factory.getFormatter("p");

TagFormatter id = factory.getFormatter("input");

id.addAttribute("type", "text");

id.addAttribute("name", "id");

TagFormatter password = factory.getFormatter("input");

password.addAttribute("type", "password");

password.addAttribute("name", "password");

TagFormatter submit = factory.getFormatter("input");

submit.addAttribute("type", "submit");

submit.addAttribute("value", "Login");

74


StringBuilder result = new StringBuilder();

result.append(form.getStartTag() + "\r\n")

.append(dl.getStartTag() + "\r\n")

.append(dt.getStartTag() + "ID" + dt.getEndTag() + "\r\n")

.append(dd.getStartTag() + id.getEmptyTag() + dd.getEndTag() + "\r\n")

.append(dt.getStartTag() + "PASSWORD" + dt.getEndTag() + "\r\n")

.append(dd.getStartTag() + password.getEmptyTag()+ dd.getEndTag() + "\r\n")

.append(dl.getEndTag() + "\r\n")

.append(p.getStartTag() + submit.getEmptyTag() + p.getEndTag() + "\r\n")

.append(form.getEndTag() + "\r\n");

return result.toString();

}


System.out.println(getForm(new HtmlTagFormatterFactory()));

System.out.println(getForm(new XhtmlTagFormatterFactory()));

}

}

A função main do programa acima emitirá a seguinte saída:

<form action="login" method="post">

<dl>

<dt>ID</dt>

<dd><input name="id" type="text"></dd>

75


<dt>PASSWORD</dt>

<dd><input name="password" type="password"></dd>

</dl>

<p><input type="submit" value="Login"></p>

</form>

<form action="login" method="post">

<dl>

<dt>ID</dt>

<dd><input name="id" type="text" /></dd>

<dt>PASSWORD</dt>

<dd><input name="password" type="password" /></dd>

</dl>

<p><input type="submit" value="Login" /></p>

</form>

6.2 Builder e Singleton

6.2.1 Builder

Este padrão permite a separação da construção de um objeto complexo da sua representação,de forma que o mesmo processo de construção possa criar diferentes representações.

76


Estruturação

O Builder contém os seguintes elementos:

• director: constrói um objeto utilizando a interface do builder;

• builder: especifica uma interface para um construtor de partes do objeto product;

• concrete builder: define uma implementação da interface builder;

• product: o objeto complexo em construção.

Exemplo de utilização

O padrão Builder pode ser utilizado, por exemplo, em uma aplicação que converte o formatoRTF para uma série de outros formatos e que permite a inclusão de suporte para conversão paraoutros formatos, sem a alteração do código fonte do leitor de RTF.

A implementação da solução para esse problema pode ser realizada através de uma classede leitura (director) associada a uma classe capaz de converter o formato RTF para outra re-presentação (builder). O objeto da classe de leitura lê cada token do texto e executa o métodoapropriado no objeto de conversão, de acordo com tipo do token. A classe de conversão possuium método para cada tipo de token, incluindo os caracteres comuns, parágrafos, fontes e etc.Para cada formato de texto suportado é criada uma classe de conversão especializada (concretebuilder). Um conversor para formato ASCII, por exemplo, poderia ignorar qualquer requisiçãopara converter tokens que não fossem caracteres comuns. Um conversor para o formato PDF,por outro lado, iria processar qualquer requisição para poder converter o estilo, além do texto.

Comparação com a Abstract Factory

O padrão Builder é muitas vezes comparado com o padrão Abstract Factory pois ambos po-dem ser utilizados para a construção de objetos complexos. A principal diferença entre eles éque o Builder constrói objetos complexos passo a passo (seguindo pelo director e pelo builder ) eo Abstract Factory constrói famílias de objetos, simples ou complexos, de uma só vez (o Factoryjá pode o criar diretamente).

77


Exemplo em linguagem Java

abstract class ConversorTexto {

public void converterCaractere(char c) {

// vazio

}

public void converterParagrafo() {

// vazio

}

public void converterFonte(Fonte f) {

// vazio

}

}

class ConversorPDF extends ConversorTexto {


78


System.out.print("Caractere PDF");

}


System.out.print("Parágrafo PDF");

}


System.out.print("Fonte PDF");

}

}

class ConversorTeX extends ConversorTexto {


System.out.print("Caractere Tex");

}


System.out.print("Paragrafo Tex");

}


System.out.print("Fonte Tex");

}

}

class ConversorASCII extends ConversorTexto {


System.out.print("Caractere ASCII");

79


}

}

class LeitorRTF {

private ConversorTexto conversor;

LeitorRTF(ConversorTexto c) {

this.conversor = c;

}

public void lerRTF() {

List<Token> tokens = obterTokensDoTexto();

for (Token t : tokens) {

if (t.getTipo() == Token.Tipo.CARACTERE) {

conversor.converterCaractere(t.getCaractere());

}

if (t.getTipo() == Token.Tipo.PARAGRAFO) {

conversor.converterParagrafo();

}

if (t.getTipo() == Token.Tipo.FONTE) {

conversor.converterFonte(t.getFonte());

}

}

}

}

public class Cliente {

80



ConversorTexto conversor;

if (args[0].equals("pdf")) {

conversor = new ConversorPDF();

} else if (args[0].equals("tex")) {

conversor = new ConversorTeX();

} else {

conversor = new ConversorASCII();

}

LeitorRTF leitor = new LeitorRTF(conversor);

leitor.lerRTF();

}

}

6.2.2 Singleton

Singleton é um padrão de projeto de software que visa garantir a existência de apenas umainstância de uma classe, mantendo um ponto global de acesso ao seu objeto. Em alguns casos,é sugerido como uma alternativa aos objetos static.

Nota: O termo vem do inglês que é um estado quando se resta apenas uma carta nas mãos,num jogo de baralho.

Estrutura

Como podem ver, o design do padrão singleton é bem simples.

81


Exemplos de Uso

Muitos projetos necessitam que algumas classes tenham apenas uma instância. Por exemplo,em uma aplicação que precisa de uma infraestrutura de log de dados, pode-se implementar umaclasse no padrão singleton. Desta forma, existe apenas um objeto responsável pelo log em todaa aplicação, que é acessível unicamente através da classe singleton.

Código em Java

public class SingletonLog {

// Construtor privado. Suprime o construtor publico padrao.

private SingletonLog() {

// Leitura da configuração de log. Normalmente descrita em um arquivo.

}

// Faz o log de eventos da aplicacao

public void doLog(String eventDescription) {

// Faca algo aqui

}

//Retorna a instancia unica da classe SingletonLog

public static SingletonLog getInstance() {

return SingletonLogHolder.instance;

}

//Classe auxiliar para criacao da instancia.// Este esquema evita problemas de sincronizacao de threads// em instanciacao sob demanda.

private static class SingletonLogHolder {

private static SingletonLog instance = new SingletonLog();

}

82


}

Por que não simplesmente usamos um "if"para verificar se o objeto é "null"quando nuncafoi instanciada e diferente de "null"caso contrário? Esse tipo de esquema de "verificação pordemanda", quando usado em ambientes concorrentes, traz um risco de dois ou mais threads fa-zerem esse teste no mesmo momento e todos concluírem a mesma resposta. O código mostradoacima é uma forma também "por demanda", mas evita esses problemas com múltiplas threads.

O esquema abaixo é a tradicional forma "sem demanda"para evitar o problema de múltiplasthreads.

public class Singleton {

private final static Singleton INSTANCE = new Singleton();

// Construtor privado. Suprime o construtor publico padrao.

private Singleton() {}

public static Singleton getInstance() {

return INSTANCE;

}

}

O esquema acima é mais simples, mas INSTANCE estará presente no programa desde seuinício, sendo ou não utilizado (é por isso que alguns preferem mais o esquema "sob demanda").

Apesar de sugerirmos o padrão singleton no lugar dos objetos static, muitos consideram aprópria necessidade dessas estruturas como um indício de mal design, logo, sugerindo que sejamevitados. Talvez seja realmente melhor utilizarmos o singleton somente quando temos certeza deque isso fará grande impacto na performance e que a classe em padrão singleton não passe aser estendida futuramente.

83

Capítulo 7

Padrões estruturais

Nesta seção, mostraremos alguns padrões de herança, composição e relacionamento de clas-ses e objetos.

7.1 Adapter e Bridge

7.1.1 Adapter

Este padrão é utilizado quando uma classe que queremos usar implementa a interface A, masesperávamos que esta tivesse implementado uma interface B. O padrão Adapter permite esta"adaptação"de interface de uma classe sem precisar alterar o código fonte dela, permitindo assimque classes com interfaces incompatíveis sejam "compatibilizadas".

Suponha que nós precisamos usar uma classe chamada "Product", que tem um método cha-mada "getCost", entretanto, já temos uma interface ProductPrice que declara um método cha-mado "getPrice". Como o "getCost"faz virtualmente o que o "getPrice"faz, queremos fazer comque a classe "Product"seja uma implementação da interface "ProductPrice". Se eu não possoalterar o código fonte de "Product", o que eu posso fazer?

O problema acima pode ser resolvido usando-se o Adapter. Podemos usar este padrão deduas maneiras: adapter por herança e adapter por agregação.

84


Adapter por herança

Exemplo de código em Java para adapter por herança

interface ProductPrice{

public int getPrice();

}

class Product{

private int cost;

public int getCost(){

return cost;

}

}

class ProductAdapter extends Product implements ProductPrice{

public int getPrice(){

return this.getCost();

}

85


}

Adapter por agregação

Exemplo de código em Java para adapter por agregação

interface ProductPrice{

public int getPrice();

}

class Product{

private int cost;

public int getCost(){

return cost;

}

}

class ProductAdapter implements ProductPrice{

private Product product = new Product();

public int getPrice(){

86


return product.getCost();

}

}

7.1.2 Bridge

O padrão Bridge (ponte) é utilizado quando é desejável que uma interface (abstração) possavariar independentemente das suas implementações; ou seja, que a "idéia"seja desacoplada daimplementação. Este padrão permite que se diminua o tamanho da árvore hierárquica (diagramade classes que mostra a árvore de subclasses para uma determinada superclasse) quando deve-se existir diversas subclasses implementando funções semelhantes que exigem implementaçãodiferente (por exemplo, quando modelamos interfaces gráficas para diversos sistemas operacio-nais).

Estrutura

Como podem ver, a classe Abstraction que representa a abstração (estrutura, ou "idéia"nodesign do software) está separada da classe Implementor que literalmente implementa uma de-terminada atividade.

Alguns exemplos não-técnicos

Imagine um sistema gráfico de janelas que deve ser portável para diversas plataformas. Nestesistema são encontrados diversos tipos de janelas, como ícones, diálogos, etc. Estas janelas for-mam uma hierarquia que contém uma abstração das janelas (classe base). Normalmente, aportabilidade seria obtida criando-se especializações dos tipos de janelas para cada uma das

87


plataformas suportadas. O problema com essa solução reside na complexidade da hierarquiagerada e na dependência de plataforma que existirá nos clientes do sistema.

Através do padrão Bridge, a hierarquia que define os tipos de janelas é separada da hierarquiaque contém a implementação. Desta forma todas as operações de Janela são abstratas e suasimplementações são escondidas dos clientes.

Outros exemplos (em Java)

Imagine que classes "Entity"e "Controller "tenham um método chamado "getDescription()",que retorna um texto descrevendo o que a instância faz. Dependendo do que a interface com ousuário pede, desejamos que este método retorne a descrição em texto puro ou em HTML.

Claro, podemos fazer isso usando heranças sem problema (podemos criar as subclasses"PlaneEntity", "HTMLEntity", "PlaneController "e "HTMLController "que sobreescrevam o método"getDescription").

Isto resolveria o problema, mas o que faremos caso precisemos estender estas classes paraque suportem agora linguagens como o XML, OWL, DAML, OIL, XHTML? Seria pior se fossenecessário agora criar as classes "WorldEntity"e "WorldController", que estendam aquelas duasclasses originais, pois precisaríamos criar todas as subclasses que suportem todas aquelas lin-guagens de descrição também... Isso geraria um caos na árvore hierárquica.

Podemos usar o padrão Bridge para melhorar isso. Usaremos as classes "Entity"e "Control-ler"para representarem a abstração e as classes "PlaneDescriptor"e "HTMLDescriptor"para seencarregarem da geração do texto de descrição. O código em Java se encontra abaixo:

Código em Java

Veja abaixo um exemplo em Java que trata o Bridge. Tente comparar com a estrutura (dia-grama) geral mostrada acima.

// Classes Abstraction

class Entity { // Este seria a classe Abstraction

private Descriptor descriptor = null; // Este seria o impl

88


// construtor padrao

Entity() {

this.descriptor = new PlaneDescriptor();

}

// construtor que inicializa o descritor

Entity(Descriptor desc) {

this.descriptor = desc;

}

// os getters/setters abaixo sao para acessar descriptor, private

Descriptor getDescriptor() {

return this.descriptor;

}

void setDescriptor(Descriptor desc) {


}

// este seria um exemplo de function()

String getDescription() {

return this.descriptor.describe(this);

}

89


}

class Controller { // Este seria a tambem uma classe Abstraction

private Descriptor descriptor = null; // Este seria o impl

// construtor padrao

Controller() {

this.descriptor = new PlaneDescriptor();

}

// construtor que inicializa o descritor

Controller(Descriptor desc) {


}

// os getters/setters abaixo sao para acessar descriptor, private

Descriptor getDescriptor() {

return this.descriptor;

}

void setDescriptor(Descriptor desc) {


}

90


// este seria um exemplo de function()

String getDescription() {

return this.descriptor.describe(this);

}

}

// Classes RefinedAbstraction, estendem Abstraction

class WorldEntity extends Entity { // Este seria a classe RefinedAbstraction

WorldEntity (Descriptor desc) {

super(desc);}// Estenda alguma funcionalidade aqui

}

class WorldController extends Controller {// Este seria a tambem uma classe RefinedAbstraction

WorldController (Descriptor desc) {

super(desc);}// Estenda alguma funcionalidade aqui

}

// Interface Implementor

interface Descriptor { // este seria o Implementor

public String describe(Object obj);// este seria uma adaptacao de implementation()

}

// Classes ConcreteImplementor

91


class PlaneDescriptor implements Descriptor {// este seria um ConcreteImplementor default

// este seria o implementation()

public String describe(Object obj) {

return "Descricao de " + obj.getClass().getSimpleName() + " em texto puro";

}

}

class HTMLDescriptor implements Descriptor{ // este seria tambem um ConcreteImplementor

// este seria o implementation()

public String describe(Object obj) {

return "<html><head /> <body>"

+ "<p>Descricao de " + obj.getClass().getSimpleName() + " em HTML<p>"

+ "</body></html>";

}

}

// Classe de execucao

public class BridgeExampleTest {


Entity planeEntity = new Entity(new PlaneDescriptor());

Entity htmlEntity = new Entity(new HTMLDescriptor());

Controller planeController = new Controller(new PlaneDescriptor());

Controller htmlController = new Controller(new HTMLDescriptor());

WorldEntity worldPlaneEntity = new WorldEntity(new PlaneDescriptor());

92


WorldEntity worldHtmlEntity = new WorldEntity(new HTMLDescriptor());

WorldController worldPlaneController =new WorldController(new PlaneDescriptor());

WorldController worldHtmlController =new WorldController(new HTMLDescriptor());

System.out.println(planeEntity.getDescription());

System.out.println(htmlEntity.getDescription());

System.out.println();

System.out.println(planeController.getDescription());

System.out.println(htmlController.getDescription());


System.out.println(worldPlaneEntity.getDescription());

System.out.println(worldHtmlEntity.getDescription());


System.out.println(worldPlaneController.getDescription());

System.out.println(worldHtmlController.getDescription());

}

}

O código acima gera a saída abaixo:

Descricao de Entity em texto puro

<html><head /> <body><p>Descricao de Entity em HTML<p></body></html>

Descricao de Controller em texto puro

93


<html><head /> <body><p>Descricao de Controller em HTML<p></body></html>

Descricao de WorldEntity em texto puro

<html><head /> <body><p>Descricao de WorldEntity em HTML<p></body></html>

Descricao de WorldController em texto puro

<html><head /> <body><p>Descricao de WorldController em HTML<p></body></html>

Note que declaramos 6 classes para representar 8 diferentes categorias. Se não usássemoso padrão Bridge, teríamos de declarar, a princípio, 8 classes diferentes. Essa diferença torna-semaior quanto mais combinações precisamos criar.

7.2 Composite e Decorator

7.2.1 Composite

Composite é um padrão de projeto de software utilizado para representar um objeto que éconstituído pela composição de objetos similares a ele. Neste padrão, o objeto composto possuium conjunto de outros objetos que estão na mesma hierarquia de classes a que ele pertence.

O padrão composite é utilizado para representar listas recorrentes - ou recursivas - de ele-mentos (uma árvore, por exemplo). Além disso, esta forma de representar elementos compostosem uma hierarquia de classes permite que os elementos contidos em um objeto composto sejamtratados como se fossem um único objeto. Desta forma, todos os métodos comuns às classesque representam objetos atômicos (folhas) da hierarquia poderão ser aplicáveis também ao con-junto de objetos agrupados no objeto composto.

94


Estrutura

Onde "Leaf"são os elementos atômicos da estrutura e "Composite"está agregado ou com uma"Composite"ou com alguma "Leaf".

Aplicação

Pode ser utilizado, por exemplo, em interfaces gráficas cujo um elemento gráfico pode serconstituído pela composição de vários outros elementos gráficos. Uma janela pode conter um oumais ícones, uma caixa de texto e vários outros elementos gráficos - até mesmo outra janela.

Outro exemplo clássico é o de gramáticas utilizadas para definir linguagens de programação.Se utilizarmos uma hierarquia de classes para representar os comandos da linguagem, supondoque a super-classe seria Comando, teríamos uma classe para o comando de atribuição, outropara, digamos, o comando While, outra para o comando composto - comando que é constituídopor uma lista de outros comandos normalmente delimitados por indicadores como { e } ou pala-vras reservadas como begin e end - e assim por diante. Pois bem, comandos que podem conteroutros comandos - como o comando composto ou o comando While do exemplo - normalmenteserão representados utilizando-se o padrão composite.

Note que este padrão pode ser usado para qualquer tipo de estrutura hierárquica. Um outroexemplo, que detalharemos mais adiante, é da estrutura de diretórios e arquivos.

95


É importante observar que será responsabilidade do objeto composto, para cada método aser aplicável à lista de objetos que possui, implementá-lo de maneira repetitiva. Por exemplo, nodiagrama de classes acima, se o método "operation()"da classe "Composite"for executado, todosos componentes agregados a ele (que podem ser tanto "Composite"quanto "Leaf") devem serexecutadas recursivamente.

Também devemos tomar cuidado para que o Composite seja somente utilizado em estruturashierárquicas (acíclicas), pois se houver um ciclo, certamente introduzirá um loop infinito.

Exemplo em Java

import java.util.ArrayList;

import java.util.List;

interface FileInterface { // Este seria o Component

public void defaultMethod(int depth);

public List<FileInterface> getChildren();

public boolean addComponent(FileInterface c);

public boolean removeComponent(FileInterface c);

}

class File implements FileInterface { // Este seria o Leaf

private String name;

public File(String name) {

this.name = name;

}

public void defaultMethod(int depth) {

for (int i = 0; i < depth; i++) System.out.print(" ");

System.out.println("file:" + this.name);

96


}

public List<FileInterface> getChildren() { return null; }

public boolean addComponent(FileInterface c) { return false; }

public boolean removeComponent(FileInterface c) { return false; }

}

class Folder implements FileInterface { // Este seria o Composite


private List<FileInterface> fileList = new ArrayList<FileInterface>();

public Folder(String name) { this.name = name; }

public void defaultMethod(int depth) {

for (int i = 0; i < depth; i++)

System.out.print(" ");

System.out.println("folder:" + name);

for (FileInterface file : fileList) {

file.defaultMethod(depth + 1);

}

}

public List<FileInterface> getChildren() { return this.fileList; }

public boolean addComponent(FileInterface c) { return this.fileList.add(c); }

public boolean removeComponent(FileInterface c){ return this.fileList.remove(c); }

}

97


public class DirectoryUser { // Teste

public static void main(String [] args){

FileInterface root = new Folder("root");

FileInterface usr = new Folder("usr");

FileInterface var = new Folder("var");

FileInterface home = new Folder("home");

FileInterface user1 = new Folder("user1");

FileInterface file1 = new File("file1");

root.addComponent(usr);

root.addComponent(var);

root.addComponent(home);

home.addComponent(user1);

user1.addComponent(file1);

root.defaultMethod(0);

}

}

Saída

folder:root

folder:usr

folder:var

folder:home

98


folder:user1

file:file1

7.2.2 Decorator

Este padrão consiste em encapsular uma classe existente usando uma nova classe Decora-tor. Ele permite a adição de funcionalidades em tempo de execução, sem usar herança. Devidoa esse comportamento, este padrão é freqüentemente referenciado como uma alternativa à he-rança.

Isso é particularmente interessante quando uma linguagem de programação não permiteherança em tempo de execução (como o Java). Como nesses tipos de linguagem fica difíciladicionar funcionalidades enquanto o programa ainda estiver rodando, utilizamos o Decorator.Isso é feito criando-se uma subclasse do Decorator e, durante sua instanciação, passar o objetooriginal para a nova Decorator.

Geralmente esses tipos de encapsulamento (que "quebra"a execução seqüencial do pro-grama) traz um ligeiro decréscimo de performance, mas isso é compensado com a grande flexi-bilidade introduzida com a possibilidade de extensão de funcionalidades em tempo de execução.

Estrutura

Note que ConcreteDecorator é a classe que "estende"o ConcreteComponent. No Concrete-Decorator, devemos ter um construtor que passa como argumento algum objeto que implementaComponent.

99


Exemplo em Java

Imagine que temos uma classe que representa preços, mas queremos estender algumas fun-cionalidades dele para que tenha uma classe que represente o dobro de seu preço e outro querepresente o preço do produto mais um lucro adicional de venda (isso pode não ser útil, mas épara ilustrarmos um uso de Decorator). Veja o código abaixo:

// Interface que representa o preco

interface Price{ // Este seria o Component

int getValue();

}

// Representa o preco primario

class PrimePrice implements Price{ // Este seria o ConcreteComponent

private int value;

PrimePrice(int value){

this.value = value;

}

public int getValue(){

return this.value;

}

}

// Classe que comporta algumas margens adicionais do preco

abstract class MarginPrice implements Price{ // Este seria o Decorator

protected Price originalPrice;

MarginPrice(Price price){

this.originalPrice = price;

100


}

}

// Representa preco com custo adicional de venda

class WholesalePrice extends MarginPrice{ // Este seria um ConcreteDecorator

private int advantage;

WholesalePrice(Price price, int advantage){

super(price);

this.advantage = advantage;

}


return this.originalPrice.getValue() + advantage;

}

}

// Representa o dobro do preco original

class DoublePrice extends MarginPrice{ // Este tambem seria um ConcreteDecorator

DoublePrice(Price price){

super(price);

}


return this.originalPrice.getValue() * 2;

}

}

// Teste

101


public class DecoratorTest{

public static void main(String[] argv){

System.out.println(

new WholesalePrice(

new DoublePrice(

new WholesalePrice(

new DoublePrice(

new PrimePrice(120)

) // fim de new DoublePrice(PrimePrice)

,80

) // fim de new WholesalePrice(DoublePrice,80)

) // fim de DoublePrice(WholesalePrice)

,200

) // fim de new WholesalePrice(DoublePrice,200)

.getValue() // WholesalePrice.getValue()

); // fim de println

}

}

Observe que conseguimos criar um objeto (que é uma instância de WholesalePrice) adicio-nando uma cadeia de funcionalidades e no PrimePrice (que é a classe concreta original).

102

Capítulo 8

Padrões de comportamento

Esta seção apresentará alguns padrões que tratam sobre comunicação entre objetos.

8.1 Visitor e Observer

8.1.1 Visitor

Este padrão é uma forma de separarmos a implementação de um algoritmo da maneira emque a classe é representada em uma estrutura (similar ao objetivo da Bridge pattern).

Sua diferença com o padrão Bridge é que o Bridge concentra-se mais na estrutura em que asclasses são organizadas para permitir uma combinação de classes para estender uma funciona-lidade, enquanto que o Visitor se concentra mais em como um objeto Visitor deve se comportarpara que uma determinada estrutura tenha comportamentos diferentes durante uma execução.

Enquanto que o Bridge se preocupa em diminuir a variedade de subclasses para estenderuma funcionalidade, o Visitor se preocupa na mudança de comportamento de uma classe graçasà diferentes instâncias de Visitor em uma porção do programa.

103


Estrutura

As classes que implementam "Element"são as classes estruturais do programa, enquanto queas classes que implementam o "Visitor"são as classes que implementam algum algoritmo em par-ticular.

Basicamente, o Visitor possui um método "visit()"e os elementos possuem um método "ac-cept()", que executa o "visit()"do Visitor. Alterando o comportamento de visit() e accept(), po-demos criar diversas combinações de funcionalidades (de forma semelhante ao que o padrãoBridge faz).

Exemplo

Abaixo, mostraremos um exemplo de uso do padrão Visitor usado para "checar"um carro esuas partes. As adaptações de "Element"definirão a estrutura do carro, seus componentes e aordem em que essa checagem deve ser feita, enquanto que as adaptações de "Visitor"definirãoo que especificamente o check deve fazer (no caso abaixo, imprimir a parte do carro que foi che-cada).

interface Visitor { // Esse seria a interface Visitor

void visit(Wheel wheel);

void visit(Engine engine);

void visit(Body body);

void visit(Car car);

104


}

interface Visitable { // Esse seria o Element

public void accept(Visitor visitor);

}

class Wheel implements Visitable { // Esse seria um ConcreteElement


Wheel(String name) {

this.name = name;

}

String getName() {

return this.name;

}

public void accept(Visitor visitor) {

visitor.visit(this);

}

}

class Engine implements Visitable{ // Esse tambem seria um ConcreteElement



}

}

class Body implements Visitable{ // Esse seria tambem um ConcreteElement

105




}

}

class Car implements Visitable{ // Esse seria um ConcreteElement que integra as outras

private Engine engine = new Engine();

private Body body = new Body();

private Wheel[] wheels = {

new Wheel("front left"), new Wheel("front right"),

new Wheel("back left") , new Wheel("back right") };

public Engine getEngine() {

return this.engine;

}

public Body getBody() {

return this.body;

}

public Wheel[] getWheels() {

return this.wheels;

}



106


engine.accept(visitor);

body.accept(visitor);

for(Wheel wheel : wheels) {

wheel.accept(visitor);

}

}

}

class PrintVisitor implements Visitor { // Este seria um concrete visitor

public void visit(Wheel wheel) {

System.out.println("Visiting "+ wheel.getName() + " wheel");

}

public void visit(Engine engine) {

System.out.println("Visiting engine");

}

public void visit(Body body) {

System.out.println("Visiting body");

}

public void visit(Car car) {

System.out.println("Visiting car");

}

}

public class VisitorTest { // Uma classe para verificar funcionamento de visitor.

107


static public void main(String[] args){

Car car = new Car();

Visitor visitor = new PrintVisitor();

car.accept(visitor);

}

}

Vantagens sobre sobrecarga/sobreposição de métodos

Como os Visitors são aproximadamente um método representado como classe, eles podemter atributos (ou seja, podemos definir um estado para um método). Isso permite que esse método(implementado com padrão visitor) tenha comportamento diferente de acordo com sua invocação.

Se não usássemos o padrão Visitor e quiséssemos definir métodos com comportamento di-ferente ao longo de sua invocação, teríamos que definir atributos na própria classe de estrutura(mesmo que somente aquele método a use). Isso deixaria a classe desnecessariamente com-plexa.

8.1.2 Observer

É também conhecido como Publisher-Subscriber,Event Generator, Dependents ou Listeners.O padrão Observer permite que objetos interessados sejam avisados da mudança de estado ououtros eventos ocorrendo num outro objeto. Ele define uma dependência um-para-muitos, demodo que quando um objeto muda o estado, todos seus dependentes (geralmente armazenadosem forma de lista) sejam notificados e atualizados automaticamente.

Agora, como garantir que objetos dependentes percebam das mudanças de um objeto? Usa-remos um laço de repetição que testa alguma mudança o tempo todo? Seria muito mais fácil oobjeto avisar todos seus dependentes que houve uma mudança, e é isso que o padrão Observerfaz.

108


Estrutura

Note que:

• Os observadores (Observer) devem conhecer o objeto que quer receber a mensagem (ouseja, o observer deve saber quem ele deve avisar quando o "Subject"pedir a emissão denotificações). Por isso, no Java costumamos declarar uma classe Observer como classeinterna (inner class) à classe que deve ser avisada;

• O objeto de interesse (Subject) deve notificar todos os observadores quando for atualizado;

• O método notify() nas classes Observer devem implementar as ações que respondem aoevento notificado. Por exemplo, se Subject representa um mouse e a notificação é feita aoclicar, o notify() pode conter rotinas que traz o foco no componente clicado.

Exemplos

As bibliotecas gráficas (como o SWING no Java) costumam usar intensivamente esse padrão(são os famosos Action Listeners ou Event Listeners). Não faltam exemplos em programas cominterface gráfica, portanto, omitiremos exemplos de código aqui.

Quem já trabalhou com o Action Script do Adobe/Macromedia flash, pode estar familiarizadocom os métodos "onKeyDown()"ou "onRelease()". Eles correspondem aos métodos "notify()"dopadrão Observer, onde inserimos código adicional para reagir a eventos de teclado ou mouse.

8.2 Command e Iterator

8.2.1 Command

É também conhecido como Action ou Transaction. É uma classe que, sozinha, representauma operação. Com isso, uma seqüência de operações pode ser representada como uma listade objetos, ao invés de uma seqüência de comandos em uma linguagem de programação.

O padrão Command permite encapsular uma solicitação como um objeto, desta forma, per-mitindo parametrizar clientes com diferentes solicitações, enfileirar ou fazer o registro (log) desolicitações e suportar operações que podem ser desfeitas.

109


É um padrão bastante útil quando precisamos emitir solicitações para objetos, mas nada sa-bendo sobre detalhes de operação que está sendo solicitada ou sobre o receptor da mesma (seja,o responsável pela solicitação não precisa estar ciente do que está sendo solicitado. Quem sepreocupa com isso seria a classe que implementa a Command).

Utilize quando você precisar:

1. Parametrizar objetos por uma ação a ser executada. Você pode expressar tal parametriza-ção numa linguagem procedural através de uma função callback, ou seja, uma função que éregistrada em algum lugar para ser chamada em um momento mais adiante. Os Commandssão uma substituição orientada a objetos para callbacks;

2. Especificar, enfileirar e executar solicitações em tempos diferentes. Um objeto Commandpode ter um tempo de vida independente da solicitação original. Se o receptor de umasolicitação pode ser representado de uma maneira independente do espaço de endereça-mento, então você pode transferir um objeto Command para a solicitação para um processodiferente e lá atender a solicitação;

3. Suportar desfazer operações. A operação "execute()", de Command, pode armazenar es-tados para reverter seus efeitos no próprio comando. A interface do Command deve teracrescentada uma operação Unexecute, que o reverte.efeitos de uma chamada anterior deExecute. Os comandos executados são armazenados em uma lista histórica. O nível ilimi-tado de desfazer e refazer operações é obtido percorrendo esta lista para trás e para frente,chamando operações Unexecute e Execute, respectivamente.

Estrutura

A estrutura acima é só uma simplificação do padrão Command. Basicamente, há uma inter-face (que serão as referenciadas pelos responsáveis pela transação) que possui um método deexecução do comando (o command()). Podem haver diversos outros métodos, mas pelo menoso método execute() deve existir.

110


O ConcreteCommand opcionalmente precisará de atributos para parametrizar a operação feitapelo Command. Por exemplo, se o Command representa uma transação bancária, o Concrete-Command pode haver um atributo que represente a quantia. O gerador da transação alteraráesse atributo de maneira conveniente até executar o comando.

Adicionalmente, o Command pode conter o método "undo()"ou "rollback()"para desfazer suaação, caso você queira que esse comando possa ser desfeito.

Aplicações

• Operações com a opção "desfazer"em diversos níveis: quando as operações são arma-zenadas como pilhas de objetos Command, podemos usar métodos "undo()"para desfazê-los;

• Armazenamento de Macros: se todas as operações do usuário são implementados comCommand, armazenar os objetos permite armazenamento de seqüência de operações fei-tas pelo usuário, permitindo definição de macros;

• Operação remota: podemos enviar instâncias de Command pela rede, representando pe-didos remotos de operação. Isso pode ser usado para ações em jogos on-line;

• Barra de progresso: se cada Command possuir um método "getEstimatedTime()"que ob-tém o tempo estimado de duração para aquela operação, podemos estimar o tempo total deexecução de um conjunto de operações.

Exemplo em Java

import java.util.Collection;

import java.util.ArrayList;

import java.util.Stack;

interface Command { // Uma interface Command

public abstract void execute();

public abstract void rollback();

}

111


// classe que insere um elemento em uma colecao

class InsertionCommand implements Command { // Este seria o ConcreteCommand

private Object obj = null;

private Collection<Object> collection = null;

// Na inicializacao, ja adiciona os parametros necessarios para execucao.

InsertionCommand(Object obj, Collection<Object> collection) {

this.obj = obj;

this.collection = collection;

}

// Insere um elemento

public void execute() {

System.out.println("Adicionando " + this.obj.toString());

this.collection.add(this.obj);

}

// Desfaz insersao

public void rollback(){

System.out.println("Desfazendo a adicao de " + this.obj.toString());

this.collection.remove(this.obj);

}

}

// Classe para exercitar o padrao Command

public class CommandTest {


112


Stack<Command> commands = new Stack<Command>();

Collection<Object> collection = new ArrayList<Object>();

commands.push(new InsertionCommand("insertion",collection));

commands.push(new InsertionCommand("insertion2",collection));

// Executa todas as Commands cadastradas em commands

for (Command element : commands) {

element.execute();

}

// Desfaz toda execucao de Command

while (!commands.isEmpty()) {

commands.pop().rollback();

}

}

}

A saída do programa acima é:

Adicionando insertion

Adicionando insertion2

Desfazendo a adicao de insertion2

Desfazendo a adicao de insertion

8.2.2 Iterator

Um iterator, em programação de computadores, permite um modo de acesso seqüencial aelementos individuais contidos em um agregado de objetos, dentro de um laço de repetição, maisexposição de estruturas internas.

113


Comparado ao acesso por índices (usado em vetores), o Iterator fornece as seguintes vanta-gens:

• o laço contável (acesso através de um numeral) não pode ser feito em qualquer tipo deestrutura de dados, ou pode ser muito lento o acesso direto. As estruturas arbóreas seenquadram nesta categoria (o acesso indexado é lento ou impossível);

• o Iterator provê uma maneira consistente de iterar sobre estruturas de dados de qualquertipo, melhorando a legibilidade e tornando-a menos sensível à mudança de estruturaçãodos dados;

• o Iterator pode adicionar restrições de acesso a alguns dados. Por exemplo, podemosforçar que elementos não possam ser "pulados"ou garantir que um elemento não pode seracessado duas vezes;

• o acesso dos dados através de Iterator permite que a estrutura de dados possa ser alte-rada sem grandes impactos. Por exemplo, podemos adicionar elementos que vêm antes do"ponteiro"do Iterator e mantê-las consistente, enquanto que no acesso indexado a inserçãode elemento modificaria todos os índices dos elementos posteriores.

Estrutura

Como pode ver, sua estrutura em si é super simples. É recomendado que qualquer estruturaavançada de dados em que o acesso seqüencial e necessáro implemente o padrão Iterator.

Exemplo de uso em Java

Vejamos um trecho do código do padrão Command, apresentado anteriormente:


Stack<Command> commands = new Stack<Command>();

Collection<Object> collection = new ArrayList<Object>();

commands.push(new InsertionCommand("insertion",collection));

114


commands.push(new InsertionCommand("insertion2",collection));

// Executa todas as Commands cadastradas em commands

for ( Command element : commands) {element.execute();

}

// Desfaz toda execucao de Command

while (!commands.isEmpty()) {

commands.pop().rollback();

}

}

O código sublinhado em negrito é um exemplo de acesso implícito de Iterator. Ele equivale a:

Iterator it = commands.iterator(); // extrai uma Iterator a partir de uma Collection

while (it.hasNext()) { // Enquanto o "ponteiro" nao aponta para o final...

Command element = (Command)it.next(); // next() seria o getNext() do diagrama acima

element.execute();

}

Aplicações

Atualmente, qualquer coleção de dados no Java (Collection) pode ser convertida temporaria-mente para um Iterator para um acesso seqüencial. Adicionalmente, a sintaxe da própria lingua-gem é bastante simplificada para o uso de Iterators. Logo, qualquer tipo de programa que usauma estrutura "Collection"já pode se aderir ao padrão Iterator.

115


Por exemplo, temos no Java a construção "for (Object o : Iterator)"(esse tipo de construçãoé chamada de Iterator implícito) para percorrer todos os elementos iteráveis (que implementama interface Iterable). Logo, é um padrão que já está sendo incorporado à sintaxe da linguagem(isso indica que já está começando a deixar de ser um padrão, e se tornando uma "regra").

116

Capítulo 9

Anti-Pattern, os "inimigos"de um bomdesign

Já que vimos os padrões de projeto (design patterns) na semana passada, veremos agorao seu oposto; seja, padrões de modelagem que pioram a qualidade de seu programa. Essastécnicas, também conhecidas como anti-patterns, são práticas que DEVEM SER EVITADAS. Co-nheça nesta semana o seu pior inimigo...

Adicionalmente, a avaliação de aprendizagem e uma pequena pesquisa de opinião serão ofe-recidas aqui.

9.1 Anti-patterns de design

9.1.1 Introdução aos anti-patterns

Os anti-patterns, também conhecidos como "pitfalls", são re-invenções horríveis ou soluçõesterríveis que ocorrem freqüentemente em sistemas de difícil manutenção ou em sistemas que li-teralmente não funcionam. O estudo deles é MUITO importante para identificarmos erros comunsno passado e evitá-los no futuro.

Muitas vezes, o estudo de anti-patterns nos lidera ao estudo aprofundado dos design-patterns,uma vez que o estudo do contrário facilita a identificação de pontos cruciais para o reparo. Umadescrição dos erros repetitivos é tão útil quanto a descrição das soluções comuns.

Desenvolvedores de sistemas devem evitar os anti-patterns sempre que possível. Isso requerum diagnóstico antecipado durante cada etapa do ciclo de vida de um software; portanto, anti-patterns são um importante componente na engenharia de softwares.

117


9.1.2 Anti-patterns de design

Abaixo, listamos alguns anti-patterns gerais que focam na etapa de design de um software.

• Abstraction inversion (inversão de abstração): ocorre quando um módulo de software (ouuma classe) não expõe aos usuários algumas funcionalidades já implementadas, forçandoque os usuários tenham de implementá-las novamente em um módulo superior;

• Ambiguous viewpoint (ponto de vista ambígua): ocorre geralmente em modelos orientadosa objetos, quando apresentamos um modelo de organização dos módulos do sistema semdocumentar se ele é uma interface, ou se ele implementa alguma funcionalidade em particu-lar, ou se ele é um módulo de interface com usuário, se é módulo de controle ou de entidade.Com isso, torna-se ambíguo identificar qual visão do software o módulo implementa;

• Big ball of mud (grande bola de lama): ocorre quando um programa não possui uma estru-tura consistente verificável;

• Blob (massa sem forma): ocorre quando uma porção do código possui excessiva funciona-lidade. Geralmente é verificado quando existe módulos (classes ou funções) "faz-tudo";

• Banco de dados como uma IPC (Inter Process Communication): ocorre quando usamosum banco de dados para manter comunicações entre processos, enquanto que simplesmecanismos IPC diretos são suficientes e apropriados;

• Gas factory (fábrica de gás): nome atribuído a um design extremamente complexo (como oencanamento no refinamento de gás);

• Input kludge: é a falha na especificação e implementação de tratamento de possíveis en-tradas inválidas. Kludge é um jargão com sentido semelhante ao "quebra-galho"ou "gambi-arra";

• Interface bloat (interface inflamada): quando criamos uma interface (não necessariamentecom o usuário) que seja tão poderosa que dificulta extremamente a sua implementação;

• Magic pushbutton (botão mágico): ocorre quando codificamos a implementação lógica di-retamente em um código de interface, sem usar abstração. Ocorre muito quando criamosbotões visuais que acionam funcionalidades, mas a mesma porção do código que imple-menta a visualização do botão realiza também sua lógica;

• Race hazard (desastre de corrida): ocorre quando não tomamos cuiado com as conseqüên-cias de diferentes ordens de acontecimento de eventos;

• Re-coupling (reacoplação): ocorre quando introduzimos dependências entre objetos (aco-plação) de forma desnecessária;

• Stovepipe system (sistema de tubos do fogão): nome atribuído a um sistema montado deforma nada manutenível, com componentes relacionados de forma doentia.

118


9.1.3 Anti-pattern orientado a objeto

Nesta lição, mostraremos os anti-patterns de design, mas particulares à orientação a objeto.

• Anemic Domain Model (modelo de domínio com anemia): ocorre quando falta a implemen-tação de algumas lógicas em classes de domínio (classes que representam entidades), ouseja, quando criamos classes que na verdade são só "tipos"de dados. Isso não deve serfeito em orientação a objeto, pois classes devem dispor métodos de manipulação dos "ti-pos"que ele representa The use of domain model without any business logic which is notOOP because each object should have both attributes and behaviors;

• BaseBean (Bean - componente - de base): ocorre quando usamos herança sobre umaclasse de utilidade (ex. os contidos no pacote java.util) para simplesmente usarmos suafuncionalidade. Ao invés disso, devemos usar a classe original com repasse de controle.Por exemplo, quando queremos usar uma lista, podemos usar a classe java.util.ArrayList aoinvés de estendê-lo;

• Call super (chamada ao superior): quando o design requer que uma subclase chame ummétodo da superclasse, que geralmente já foi sobrecarregado ou sobreposto;

• Circle-ellipse problem (problema do círculo-elipse): criar subclasses de acodo com seusvalores internos pode ser um problema. No caso do círculo-elipse, um círculo é uma elipsecom raio constante e de único eixo. Quando representamos um círculo como uma subclassede uma elipse, isso indicará que no programa existirão elipses com distância zero entre oseixos, mas não sendo da classe dos círculos (sendo que uma elipse com eixos de distânciazero é sempre um círculo). Adicionalmente, se a classe da elipse implementa um métodopara esticar a figura, a classe círculo deve tomar muito cuidado para que esse métodoherdado não crie uma instância "não-círcular". Esse problema é grave, pois a maioria daslinguagens orientadas a objeto (como o Java) não permite que uma instância (não suareferência, mas sim o próprio objeto) mude de classe durante a execução, ou seja, umamesma instância não pode ser da classe de elipses ou da classe de círculos dependendodo seu raio ser constante ou não;

• Empty subclass failure (falha em subclasses vazias): ocorre quando criamos classes quefalham no teste da "subclasse vazia"; ou seja, quando a classe se comporta de forma dife-rente ao criarmos subclasses sem alteração de conteúdo;

• God object (objeto Deus): nome atribuído às classes que concentram muitas funções, muitoalém do necessário;

• Object cesspool (esgoto de objetos): ocorre quando temos um depósito de objetos paraserem reusados, mas seus estados não estão de acordo com os requisitos mínimo de reuso(ex. quando não há remoção de campos com informações sigilosas, etc);

• Poltergeists: são os objetos que têm como seu único objetivo a passagem de informação(ou execução) para outros objetos, e logo então são apagados. Têm esse nome pois elessurgem temporariamente para trafegarem informação e depois somem repentinamente;

• Sequential Coupling (acoplamento de seqüência): é uma classe que requer que seus mé-todos sejam chamados em uma determinada ordem;

119


• Singletonity : é o uso abusivo do padrão singleton;

• Yet Another Layer (mais uma camada, para variar...): ocorre quando adicionamos camadasdesnecessárias de abstração. Isso é muito comum em iniciantes que ainda não estão tãoacostumados na aplicação de design estruturado;

• Yo-yo problem (problema do yo-yo): é uma estruturação de classes (de herança, agregação,composição ou dependência) que está altamente fragmentada e difícil de entender. É co-mum quando referências ou dependências sobem e descem entre camadas de abstração,sem muito controle.

9.2 Outras categorias de anti-pattern

9.2.1 Anti-pattern de programação

Nesta página, apresentamos alguns anti-patterns ligados à programação.

• Accidental complexity (complexidade acidental): ocorre quando a implementação deum algoritmo insere, sem necessidade, muita complexidade;

• Action at a distance (ação à distância): ocorre quando partes extremamente separadasdo sistema interagem de forma inesperada;

• Accumulate and fire (acumule e dispare): ocorre quando um conjunto de variáveis globaissão usadas como argumentos de subrotinas. Esses "parâmetros"são calibrados um por um(acúmulo) e no final a subrotina é executada (disparo);

• Blind faith (fé às cegas): é a falha na verificação da corretude de um reparo de bugsou sobre resultados de subrotinas. É quando acreditamos, sem razão alguma, que umasubrotina (geralmente criada pelo próprio programador) retorna valores sempre corretos ouquando não verificamos se um bug, reportado como removido, foi realmente consertado;

• Boat anchor (âncora de barcos): ocorre quando mantemos presente uma parte do sis-tema que não é mais usado;

• Busy spin (giro ocupado): é uma maneira de se esperar por um evento, mas consumindoCPU durante essa espera. Isso é implementado através de uma checagem iterativa aoinvés do uso de um mecanismo próprio de troca de mensagens;

• Caching failure (falha de cache): ocorre quando esquecemos de voltar valores de indica-dores (flags) quando esse evento já foi tratado. Ocorre muito em flags de erros.

• Cargo cult programming (programação por culto de carga): muitas vezes referenciadascomo programação voodoo, é uma prática de programação que utiliza padrões e procedi-mentos sem conhecer o porquê. O nome vem de um culto que se estabeleceu entre osséculos XIX e XX, no sul do pacífico;

120


• Checagem de tipos, ao invés de interfaces: ocorre quando há uma verificação muitoespecífica de tipos, quando somente uma restrição mais geral é necessária. Por exemplo,seja Moeda uma interface e Realuma classe que a implementa. Para testar se um determi-nado objeto pode ser usado em um "pagamento", não é necessário testar se aquele objetoé exatamente da classe, mas basta testar se é subclasse (ou especificações) da interfaceMoeda;

• Code momentum (momento de código): é quando uma determinada porção do códigoé altamente dependente de porções diferentes do código. Ele se assemelha ao "mo-mento"físico. Quanto mais dependência é inserida para um "sentido"(de dependência),maior é a probabilidade dele se manter naquele "sentido"(de dependência) e mais difícil éde "parar"(remover a dependência);

• Codificação por exceções: consiste na adição de novos códigos para tratar cada caso deexceção encontrada. Alguns chamam este anti-pattern de "programação orientada a erros".

• Error hiding (ocultação de erros): ocorre quando um erro é capturado antes de chegarao usuário e não é tratado nem corretamente repassado (nenhuma mensagem é emitida ouuma mensagem sem sentido é mostrada);

• Exception handling (processamento por exceção): ocorre quando usamos o mecanismode manuseio de erros da própria linguagem de programação para implementar algumaslógicas. Erros ou exceções devem ser tratadas como execução irregular do código e nãodeve ser incorporado à lógica do programa;

• Full monty (Monty completo): acredita-se que a origem desse termo seja o nome de umsistema que possuía uma interface extremamente complexa (com centenas de botões), masque realizava operações triviais de acesso a arquivos ou pastas. Desde então, este nome étratado como um anti-pattern que indica extrema complexidade desnecessária gerada poruma combinação infeliz de múltiplas anti-pattens;

• Hard code (código rígido): ocorre quando embutimos códigos específicos de hardwares(aqueles que supõem que estamos usando um determinado sistema em particular pararodar o programa) em partes da implementação;

• Lava flow (fluxo de lava): ocorre quando um código redundante ou de baixa qualidadeé criada rapidamente durante o processo de desenvolvimento e acaba sendo mantido atédepois da publicação do sistema, devido ao custo de reparo desse código. O código debaixa qualidade se assemelha à lava que sai rapidamente dos vulcões, resfria-se e torna-serígido, transformando-se em um produto arqueológico naquele sistema;

• Loop-switch: ocorre quando codificamos uma lógica seqüencial usando uma estrutura ite-rativa (um laço/loop de repetição) e um switch-case (ou, em caso pior, controle de fluxo comif aninhado);

• Magic numbers (número mágico): ocorre quando incluímos números em algoritmos, massem nenhuma explicação. Isso pode ser amenizado usando-se constantes no lugar denumerais;

• Magic strings (string mágico): ocorre quando inserimos textos literais nas porções docódigo, geralmente em comparações, tipos de eventos, etc;

121


• Packratting (também conhecido como leak ou vazamento de memória): ocorre quandoum programa ocupa mais espaço na memória por manter vivo os objetos dinamicamentealocados por mais tempo do que o necessário. No caso do Java, como o gerenciamento dememória é feita pelo coletor de lixo, todos os pacotes contribuem um pouco no packratting;

• Ravioli code (código ravioli): são os sistemas cheios de objetos fracamente conectadosentre si;

• Spaghetti code (código espaguete): sistemas com estrutura extremamente difícil de secompreender, especialmente por causa da má aplicação dos principais mecanismos deestruturação do programa (isso inclui separação de blocos de código, funções/métodos,classes, controle estruturado de fluxo, indentação, etc);

• Superboolean logic (lógica super-booleana): ocorre quando usamos desnecessaria-mente as comparações ou abstrações de álgebra booleana;

• Useless exception handling (tratamento inútil de exceções): ocorre quando testamosalgumas condições para prevenir exceções em tempo de execução, mas lançamos manu-almente essas exceções quando a condição falha (ex. if (a != null) process(a) else thrownew NullPointerException() ). No caso do Java, é muito mais eficiente e seguro usarmos opróprio mecanismo de exceção de execução da máquina virtual.

9.2.2 Anti-patterns de gerência

Nesta seção, aprenderemos alguns anti-patterns de gerência de projetos ou de administraçãode equipes. Eles são importantes para um processo de desenvolvimento, pois atualmente é maisraro um projeto de software ser desenvolvido sem uma equipe (e uma equipe geralmente precisade um gerente ou administrador).

• Absentee Manager (gerente ausente): é qualquer situação em que o gerente se tornainvisível (ou inacessível) pela equipe por um período considerável de tempo;

• All You Have Is A Hammer (tudo que você tem é um martelo): ocorre quando a adminis-tração/gerência é unidirecional e sempre a mesma técnica é forçada a todos os subordina-dos;

• Cage Match Negotiator (negociador de lutas em jaula): ocorre quando um gerente usa aabordagem "vitória a qualquer custo", desconsiderando muitos das prioridades secundárias;

• Doppelganger : é um gerente (ou colega de trabalho) que é "amigável"em um momento,mas "maléfico"ou "vicioso"em outro;

• Fruitless Hoops (aro sem fruto): ocorre quando um gerente requer, de forma interminável(e muitas vezes sem sentido), dados para realizar uma decisão;

• Golden Child (criança de ouro): ocorre quando responsabilidades especiais, oportuni-dades, reconhecimento ou retribuições são dadas aos membros do time; baseadas emrelações pessoais ou de forma inconsistente ao trabalho do membro;

122


• Headless Chicken (frango sem cabeça): é o gerente sempre em "pânico", com o "pé nofogo", extremamente agitado;

• Leader Not Manager (líder, mas não gerente): infelizmente um ótimo líder não necessa-riamente é um ótimo gerente;

• Managerial Cloning (clonagem gerencial): é o ato de contratar ou treinar gerentes paraque todos eles ajam de mesma maneira no trabalho, de forma idêntica aos chefes;

• Manager Not Leader (gerente, mas não líder): é o gerente que é proficiente nos seusdeveres administrativos e gerenciais, mas falha na habilidade como líder;

• Metric Abuse (abuso de métrica): é o uso malicioso ou incompetente de métricas para amedição de resultados ou para tomadas de decisão;

• Mr. Nice Guy (o Sr. Bonzinho): é o gerente que luta para ser o "amigão"de todos;

• Proletariat Hero (herói proletariado): é o trabalhador considerado como ideal, mas naverdade é só uma figura conseqüente do crescimento de demandas e a ampliação de alvode produção;

• Rising Upstart (presunçoso ascendente): as potenciais estrelas que não conseguemesperar pela sua hora apropriada e preferem privar-se do tempo requisitado para exercitar oaprendizado, maturidade e para reconhecer a sua posição na própria equipe ou em outrasequipes;

• Spineless Executive (executivo covarde): é o gerente sem a coragem para confrontarsituações desfavoráveis, perde-se perante uma falha ou hesita na hora de proteger seusempregados;

• Three-Headed Knight (cavaleiro de três cabeças): é o gerente sempre indeciso;

• Ultimate Weapon (a arma final): são os fenômenos ou entidades que são excessivamenteconfiados, a ponto de se tornar a conduta de tudo na equipe ou na organização;

• Warm Bodies (corpos quentes): são os trabalhadores que mal cumprem os requisitosmínimos esperados pela natureza do trabalho e, portanto, é desviado de time a time ou deprojeto a projeto indefinidamente.

9.2.3 Anti-patterns de projeto

Nesta seção, mostraremos alguns anti-patterns para gerentes de projetos e publicidade.

• Smoke and mirrors (fumaça e espelhos): é o ato de apresentar funcionalidades no sis-tema que não estão implementadas ainda;

• Software bloat (inflamação de software): ocorre quando sucessivas atualizações de ver-são demandam cada vez mais recursos computacionais;

123


• Bad Management (má gerência): é o ato de gerenciar um projeto sem ter uma noção su-ficiente do domínio tratado.

9.2.4 Anti-pattern de métodos

Abaixo, apresentamos alguns anti-patterns relacionados aos processos de produção ou me-todologias.

• Low hanging fruit (fruta em galho baixo): ocorre quando lidamos sempre com as tarefasmais simples, ignorando fatores mais importantes e complexas;

• Copy and paste programming (programação por cópia/cola): ocorre quando nos con-tentamos com simples cópia (e modificação) de códigos, quando podemos criar soluçõesmais genéricas (como bibliotecas);

• De-factoring ("defatoração"): é o processo de remoção de funcionalidade e sua substitui-ção por documentações;

• Golden hammer (o martelo de ouro): é o ato de assumir que a solução favorita é univer-salmente aplicável;

• Improbability factor (fator de improbabilidade): é quando assumimos que um erro co-nhecido é improvável de acontecer;

• Premature optimization (otimização prematura): é a otimização baseada em informa-ções insuficientes;

• Programming by permutation (programação por permutação): é a tentativa de se apro-ximar à solução através de mudanças sucessivas do código para "ver se funciona";

• Reinventing the wheel (reinventando a roda): quando não adotamos uma solução ade-quada e já existente;

• Reinventing the square wheel (reinventando a roda quadrada): quando criamos umasolução precária, quando uma melhor solução já existe;

• Silver bullet (bala de prata): é quando assumimos que a solução técnica favorita poderesolver um problema maior. Afinal, uma bala de prata só serve para lobisomens, não paraqualquer monstro;

• Tester Driven Development (desenvolvimento orientado a depuradores): é o projeto desoftware cujo novos requisitos são especificados através de relatórios de bugs.

124


9.2.5 Anti-pattern de configuração

Nesta seção, mostraremos um exemplo de design-pattern de configuração (de implantação)de softwares, focando-nos em componentes que completam um sistema.

• Dependency hell (inferno de dependência): são os problemas ocorridos com versões deprodutos requeridos pelo seu produto. Pode se subdividir nas categorias abaixo;

– DLL hell (inferno de DLL): problemas com versões, disponibilidade ou redundân-cia/multiplicidade de bibliotecas de links dinâmicos, especificamente no Microsoft Win-dows;

– JAR hell (inferno de JAR): problemas que ocorrem com diferentes versões ou locali-zações de pacotes JAR em programas Java. Isso ocorre freqüentemente por causa dafalta de entendimento do modelo de carregamento de classes;

– Extension conflict (conflito de extensões): problemas que ocorrem em diferentesextensões, tipicamente do Mac OS, na tentativa de estender partes semelhantes dosistema operacional.

9.2.6 Anti-pattern organizacional

Nesta página, mostraremos alguns anti-patterns observáveis em nível de organização.

• Analysis paralysis (paralisação por análise): ocorre quando alocamos esforço despro-porcional na fase de análise de um projeto;

• Cash cow (a vaca do dinheiro): é um termo vulgar que representa uma forte dependênciaa uma fonte particular de lucro. O anti-pattern ocorre quando exageramos na dependênciaa um produto (ou serviço) e ignoramos outros importantes;

• Continuous obsolescence (obsolescência contínua): é a grande preocupação em man-ter um esforço desapropriado só para portar um sistema a um novo ambiente;

• Cost migration (migração de custo): é a transferência de gasto do projeto a um departa-mento vulnerável ou para um simples parceiro de negócio;

• Design by committee (projeto por comitê): é o resultado da existência de múltiplos con-tribuintes para o projeto inicial (design), sem uma unificação prévia de visão;

• Escalation of commitment (intensificação do compromisso): ocorre quando não revo-gamos uma decisão quando este foi provado ser errado.

• Creeping featurism (crescimento de características): é o ato de adicionar novas carac-terísticas em um sistema, em detrimento da qualidade geral;

• Hero-Mode (modo herói): é a política de confiar continuamente em esforços heróicos dealgumas equipes para cumprir prazos apertados, ignorando o custo a longo prazo em qua-lidade do produto ou serviço;

125


• I told you so (eu te avisei): é quando um aviso de um perito é inicialmente ignorado e,quando justificado, esse aviso torna-se o foco central da atenção (quando deveríamos focarna solução);

• Management by numbers (gerência por números): ocorre quando pagamos excessivaatenção aos critérios quantitativos de gerência, ou quando esses critérios não são essenci-ais e são custosos;

• Management by perkele (gerência por Perkele): Perkele é um Deus na mitologia daFinlândia. O termo foi originado de um ditado popular na Suécia sobre uma administraçãoem curtíssimo prazo, em detrimento da visão global. Atualmente, é usado no sentido dagerência ao estilo militar: controle através do medo, disciplina, obrigação e incerteza;

• Moral hazard (risco moral): é quando separamos um responsável (pelas decisões) daconseqüência de sua própria decisão;

• Mushroom management (administração de cogumelos): ocorre quando mantemos osfuncionários mal-informados e abusados (cultivando-os no escuro e alimentados com adubo).

• Scope creep (crescimento de escopo): é quando permitimos que o escopo de um projetocresça sem controle;

• Stovepipe (chaminé): é a estrutura organizacional que suporta um fluxo vertical (no orga-nograma) das informações, mas inibe comunicação inter-organizacional;

• Vendor lock-in (preso ao vendedor): ocorre quando criamos um sistema excessivamentedependente de um componente suprido por uma entidade externa;

• Violin string organization (organização de corda de violino): é uma organização alta-mente amparado, decorado e afinado, mas sem flexibilidade.

126

Modelagem Oo

Documents

Transcript of Modelagem Oo