adlaniger - aplicação de padrões de projeto no desenvolvimento de frameworks
DESCRIPTION
Dissertação sobre o assunto.TRANSCRIPT
-
ODLANIGER LOURENO DAMACENO MONTEIRO
APLICAO DE PADRES DE PROJETO NO
DESENVOLVIMENTO DE FRAMEWORKS - UM
ESTUDO DE CASO
Florianpolis - SC
2002
-
UNIVERSIDADE FEDERAL DE SANTA CATARINA
PROGRAMA DE PS-GRADUAO EM CINCIA DA
COMPUTAO
Odlaniger Loureno Damaceno Monteiro
APLICAO DE PADRES DE PROJETO NO
DESENVOLVIMENTO DE FRAMEWORKS - UM
ESTUDO DE CASO
Dissertao submetida Universidade Federal de Santa Catarina como parte dos
requisitos para a obteno do grau de Mestre em Cincia da Computao
Orientador:
Prof. Rosvelter Joo Coelho da Costa
Florianpolis, 08 de agosto de 2002.
-
ii
APLICAO DE PADRES DE PROJETO NO
DESENVOLVIMENTO DE FRAMEWORKS - UM
ESTUDO DE CASO
Odlaniger Loureno Damaceno Monteiro
Esta Dissertao foi julgada adequada para a obteno do ttulo de Mestre
em Cincia da Computao com rea de concentrao em Sistemas de Computao e
aprovada em sua forma final pelo Programa de Ps-Graduao em Cincia da
Computao.
Prof. Dr. Fernando lvaro Ostuni Gauthier Coordenador do Curso de Ps-Graduao em Cincia da Computao da Universidade Federal de Santa Catarina
Banca Examinadora:
Prof. Dr. Rosvelter Joo Coelho da Costa Orientador e Presidente da Banca
UFSC
Prof. Dr. Joo Bosco Mangueira Sobral UFSC
Prof. Dr. Vitrio Bruno Mazzola UFSC
-
iii
Agradecimentos Agradeo ao Programa de Ps-Graduao em Cincia da Computao da
Universidade Federal de Santa Catarina pela oportunidade de ter me recebido como
aluno.
Agradeo ao Centro Universitrio do Par pela oportunidade que me foi
dada de aderir, seguir a carreira acadmica e viabilizar a minha participao no
programa de Ps-Graduao em Cincia da Computao em parceria com a
Universidade Federal de Santa Catarina.
Agradeo ao meu orientador Prof. Rosvelter Joo Coelho da Costa, pelo
direcionamento e grande apoio na elaborao deste trabalho, bem como pela pacincia e
dedicao oferecida.
Agradeo aos meus colegas professores, dos quais muitos participaram do
mesmo programa de Ps-Graduao, pela amizade e troca de colaboraes durante o
perodo de curso.
Agradeo ao professor Gustavo Campos, responsvel pela coordenao
local (Belm) do programa de Ps-Graduao pela amizade e suporte durante o
transcorrer do curso.
Agradeo especialmente professora Conceio Rangel Fiuza de Melo, pelo
incentivo dirio e apoio irrestrito para a elaborao desta pesquisa e concluso do curso.
Agradeo minha famlia, meus irmos Filipe e Davi e meus pais
Reginaldo e Iara Monteiro, por formarem a estrutura abenoada que me foi dado o
privilgio de integrar.
Agradeo minha famlia, minha esposa Luclia e meu filho Leandro, pelo
incentivo, amor e carinho e por nortearem minhas principais atitudes, tanto pessoais
quanto profissionais.
Agradeo a Deus por sempre me conduzir por bons caminhos.
-
iv
Sumrio
Resumo ...................................................................................................................... vii
Abstract .................................................................................................................... viii
Introduo ................................................................................................................... 1
A Modelagem de Sistemas Orientados a Objetos .................................................... 4
1 - Complexidade de software .................................................................................. 4
2 - Modelagem.......................................................................................................... 5
2.1 - Importncia da modelagem .......................................................................... 6
2.2 - Princpios da modelagem ............................................................................. 7
3 - Modelos de software ........................................................................................... 7
3.1 - Foco em algoritmos...................................................................................... 7
3.2 - Foco em objetos ........................................................................................... 8
3.3 - Abordagem orientada a objetos.................................................................... 9
3.4 - Desenvolvimento de sistemas orientados a objetos ................................... 13
4 - Linguagem de Modelagem Unificada - UML ................................................... 15
4.1 - Itens ............................................................................................................ 15
4.2 - Relacionamentos ........................................................................................ 18
4.3 - Diagramas .................................................................................................. 19
5 - Consideraes sobre a modelagem usando objetos.......................................... 21
Padres de Projeto.................................................................................................... 22
1 - Introduo ......................................................................................................... 22
2 - Padres ............................................................................................................. 22
3 - Frameworks....................................................................................................... 24
4 - Um exemplo: a arquitetura MVC...................................................................... 24
-
v
5 - Descrevendo padres de projeto....................................................................... 27
6 - O catlogo GoF................................................................................................. 30
7 - Utilizando padres ............................................................................................ 34
7.1 - O padro Estado ......................................................................................... 34
7.2 - Exemplo: a calculadora .............................................................................. 36
7.3 - Soluo sem o padro Estado .................................................................... 38
7.4 - Soluo com o padro Estado .................................................................... 40
8 - Concluso.......................................................................................................... 42
Aplicando Padres de Projeto no Desenvolvimento de Frameworks .................. 43
1 - Introduo ......................................................................................................... 43
2 - A problemtica .................................................................................................. 44
3 - Solucionando o problema da representao de expresses verso 0.1......... 47
4 - Tratando o problema da avaliao de expresses verso 1.0 ....................... 52
5 - Revendo o problema da representao concreta de expresses verso 1.1 .. 55
6 - Ainda sobre o problema da representao concreta de expresses verso 1.2
58
7 - Concluso.......................................................................................................... 61
Concluso .................................................................................................................. 62
Referncias ................................................................................................................ 64
-
vi
Lista de figuras Figura 2.1 Exemplo de classe e suas instncias (objetos). ............................................. 12
Figura 2.2 Representao grfica de interface em UML................................................ 16
Figura 2.3 Representao grfica de classe em UML. ................................................... 16
Figura 2.4 Representao grfica de um componente em UML. ................................... 17
Figura 2.5 Representao grfica de um n em UML.................................................... 17
Figura 2.6 Representao grfica de um pacote. ............................................................ 18
Figura 2.7 Representao grfica do item anotacional................................................... 18
Figura 2.8 Diagrama de classes. ..................................................................................... 20
Figura 3.1 Exemplo de aplicao da arquitetura MVC [GAM2000]. ............................ 26
Figura 3.2 Viso geral do padro Estado e seus elementos............................................ 35
Figura 3.3 Janela do aplicativo calculadora.................................................................... 36
Figura 3.4 Diagrama de estados do aplicativo calculadora. ........................................... 37
Figura 3.5 Representao da classe GUI. ....................................................................... 38
Figura 3.6 Estrutura da primeira soluo. ...................................................................... 39
Figura 3.7 Representao da classe na primeira soluo................................................ 40
Figura 3.8 Estrutura da segunda soluo. ....................................................................... 41
Figura 3.9 Representao da classe Calculadora e interface Estado. ............................. 42
Figura 4.1 Sintaxe abstrata. ............................................................................................ 45
Figura 4.2 O modelo arquivo-diretrio .......................................................................... 47
Figura 4.3 Modelo de composio de expresses .......................................................... 48
Figura 4.4 Diagrama de classes da verso 0.1................................................................ 50
Figura 4.5 Cdigo da interface Exp na verso 1.0.......................................................... 53
Figura 4.6 Cdigo da interface EvalVisitante na verso 1.0. ......................................... 53
Figura 4.7 Diagrama de classes da verso 1.0................................................................ 54
Figura 4.8 Cdigo da interface Precedencia na verso 1.1............................................. 56
Figura 4.9 Cdigo da interface Exp na verso 1.1.......................................................... 56
Figura 4.10 Diagrama de classes da soluo 1.1. ........................................................... 57
Figura 4.11 Cdigo da interface Exp na verso 1.2........................................................ 58
Figura 4.12 Cdigo da interface PrecedenciaAbsFab na verso 1.2. ............................. 59
Figura 4.13 Diagrama de classes da soluo 1.2. ........................................................... 60
-
vii
Resumo
Este trabalho aborda o projeto de sistemas orientados a objetos auxiliado por
padres de projeto. Fornece uma viso geral sobre os principais aspectos da modelagem
de sistemas orientados a objetos, conceitos, notaes, padres de projeto e frameworks,
e suas aplicaes no processo de desenvolvimento de software.
O principal foco desta dissertao o uso de padres de projeto na definio
de arquiteturas de software oferecendo alto grau de reusabilidade. apresentado o
desenvolvimento de um sistema avaliador de expresses matemticas estudo de caso
onde os padres de projetos foram utilizados para a soluo de diferentes problemas de
projeto.
Um prottipo totalmente funcional desse sistema foi desenvolvido
utilizando a plataforma Java disponibilizada pela SUN Microsystems.
Palavras-chave: padres de projeto; programao orientada a objetos; frameworks.
-
viii
Abstract
This work is concerned with object-oriented software development based on
design patterns. It will be shown an overview about the most important aspects of
object-oriented software modeling, concepts, notation, design patterns, frameworks and
their application on software developing process.
The main point of this work is the use of design patterns in software
architecture definition with high level of reusability. It is presented a mathematics
expression evaluator framework, where design patterns were used to solve different
kind of reusability problems.
A totally functional prototype of this solution was developed using SUN
Microsystems Java platform.
Key-words: design patterns; object-oriented programing; frameworks.
-
Captulo 1
Introduo
Projetar software orientado a objetos uma tarefa difcil, mas projetar
software reutilizvel orientado a objetos ainda mais difcil. necessrio modelar
objetos pertinentes, fator-los em classes no nvel correto de granularidade, definir as
interfaces das classes e as hierarquias de herana e estabelecer as relaes entre eles. O
projeto deve ser especfico para resolver o problema, mas tambm genrico o suficiente
para atender futuros problemas e requisitos [GAM2000].
A modelagem de uma arquitetura de sistema que tenha mltiplos requisitos
e posteriores adaptaes com modificaes desses requisitos um dos maiores desafios
do arquiteto de sistemas. Ao mesmo tempo em que o software deve ser especfico o
suficiente para resolver um problema especfico, ele deve tambm se adaptar a solues
um pouco mais genricas.
Um professor de disciplina de programao de sistemas orientados a objetos
pode perceber que apresentao a um aluno de graduao em computao de um
conjunto de regras e padres, previamente testados e aprovados, associado com
conceitos de componentizao, pode melhorar o tempo que um aluno leva para
desenvolver uma boa soluo de programa, com caractersticas de reusabilidade e
adaptabilidade.
O principal problema que motivou a elaborao deste texto a dificuldade
de se desenvolver software, mesmo para principiantes em programao, com
caractersticas de reusabilidade.
O tema principal tratado nesta pesquisa a explorao dos elementos
inerentes ao desenvolvimento de software reutilizvel com solues baseadas em
padres de projeto.
Para tal entendimento torna-se necessrio elaborar um estudo sobre
modelagem e desenvolvimento de software; padres de projeto e suas aplicaes.
-
2
A partir dessas idias surgem dois questionamentos que norteiam este
trabalho:
Como os padres de projeto podem nos ser teis no processo de criao de sistemas orientados a objetos?
O que possvel obter de vantagens ao optarmos por usar padres de projeto no desenvolvimento de uma arquitetura de software?
O objetivo principal deste texto estudar e mostrar a aplicao de padres
de projeto na realizao de software reutilizvel orientado a objetos.
Os objetivos especficos deste estudo so:
Apresentar as caractersticas mais importantes da modelagem de software orientado a objetos, como complexidade e modelos de software;
Visualizar os itens necessrios para representar modelos de software orientado a objetos em uma linguagem de modelagem unificada UML;
Conhecer os conceitos e aplicaes dos principais padres de projeto catalogados;
Apresentar um exemplo de aplicao dos padres de projeto na criao de um framework para solucionar um problema.
Para atender os objetivos propostos, esse trabalho est estruturado com o
Captulo 1 apresentando as motivaes e a justificativa para o desenvolvimento desse
trabalho, seus objetivos e estrutura.
O Captulo 2 mostra as principais caractersticas da modelagem baseada em
orientao a objetos, desde os princpios de complexidade de software, a importncia do
processo de modelagem, os modelos de software e discorre sobre os conceitos mais
relevantes de uma linguagem de modelagem unificada, a UML.
O Captulo 3 caracteriza os padres de projeto e frameworks, conceitos e
aplicaes dos principais padres catalogados e mostra um exemplo simples de
aplicao do padro Estado no projeto de uma calculadora.
-
3
O Captulo 4 apresenta quatro verses de um sistema avaliador de
expresses, onde em cada verso aplicado um padro diferente. So feitas anlises da
aplicao dos padres suas conseqncias e benefcios.
No Captulo 5 so feitas as consideraes finais e propostas de continuao
deste trabalho.
-
Captulo 2
A Modelagem de Sistemas Orientados a Objetos
A elaborao de programas abrange um conjunto de regras e passos que
devem ser seguidos para que o resultado satisfaa os objetivos esperados. Alm disso,
especifidades como o ambiente, os usurios, o grau de preciso das respostas do
programa, etc., devem sempre ser respeitados.
A programao orientada a objetos vem de encontro com essas necessidades
provendo inmeros elementos relacionados tanto na anlise como ao projeto de sistemas
de software. Este captulo abrange de forma sucinta o problema da modelagem de
sistemas de software envolvendo o paradigma da programao orientada a objetos.
1 - Complexidade de software
A complexidade dos sistemas de software advm de inmeros fatores e
geralmente comparvel a complexidade encontrada em sistemas de engenharia. So
quatro os principais fatores [BOO1994]:
1) A complexidade do domnio do problema
Os problemas a serem resolvidos por um software envolvem elementos de
grande complexidade, com requisitos difceis de compreender e, por vezes,
contraditrios. Alm disso, existem os requisitos no funcionais que nem sempre
aparecem explicitamente, mas que so importantes como: usabilidade, desempenho,
custo, tempo de vida til e reutilizao. Boa parte da dificuldade em compreender os
requisitos do software advm dos problemas de comunicao e compreenso entre os
usurios do programa e seus analistas. Por ltimo, os requisitos de um sistema podem e
geralmente mudam no decorrer do tempo, em funo de mudanas nas regras e
necessidades do ambiente. Como a elaborao de software resulta em um investimento
de capital, o seu desenvolvimento geralmente envolve uma prorrogao, chamada
inconvenientemente de manuteno.
-
5
2) A dificuldade de gerenciamento do processo de desenvolvimento
Uma equipe de desenvolvimento de software precisa ser bem gerenciada,
pois alm de ter como tarefa fundamental manter o usurio protegido da complexidade
do programa, a equipe vai utilizar durante todo o processo de criao uma variada
quantidade de artifcios, tornando necessrio uma boa sintonia, comunicao, unidade e
integridade entre seus membros.
3) A flexibilidade possvel atravs do software
necessrio, possvel e perigoso o uso da abstrao no processo de
elaborao, pois ao mesmo tempo em que se precisa atender as especificaes do
problema, existem alguns padres de desenvolvimento na indstria de software que
ainda no so bem interpretados e utilizados pelas empresas.
4) A problemtica da caracterizao do comportamento de sistemas
discretos
Os sistemas discretos, diferentemente dos sistemas contnuos, possuem a
dificuldade natural de serem modelados, pois devem ser representados por valores
discretos e devem ser elaborados de tal forma que procurem atender da maneira mais
completa possvel todos os estados de um sistema. Um sistema computacional, montado
em um ambiente digital, um sistema discreto que possui variveis para representar o
estado de seus valores. Como difcil prever todos os possveis estados de um sistema
contnuo, necessrio trabalhar com nveis aceitveis de aproximao e erro.
Ao projetar software de qualidade deve-se levar em considerao que a
complexidade um fator presente e contnuo em todo o processo. Obtm-se um melhor
aproveitamento, atravs do uso de tcnicas de abstrao e criao de software, entre
elas, algumas que sero apresentadas no decorrer deste captulo.
2 - Modelagem
Pode-se afirmar que a meta de um bom produto de software atender as
necessidades dos usurios com qualidade e seu desenvolvimento deve ser feito de
maneira previsvel e com utilizao eficiente de recursos.
ScheufeleHighlight
-
6
Dentro dessa perspectiva, a modelagem aparece como parte central e
fundamental de todas as atividades de desenvolvimento de software, pois a construo
de modelos permite que a estrutura e o comportamento desejados do sistema possam ser
divulgados e comunicados.
2.1 - Importncia da modelagem
Um programa de computador simples e pequeno talvez no exija uma
modelagem completa, pois a sua complexidade pode no ser to grande a ponto de
impedir o entendimento e a construo da soluo. Entretanto, um software com maior
grau de complexidade exige cuidados tais como levantamento de requisitos,
planejamento, desenvolvimento e validao, pontos para os quais uma modelagem bem
elaborada fundamental.
A modelagem uma tcnica de engenharia aprovada e bem-aceita. A sua
aplicao na engenharia de sistemas tambm aconselhvel, pois modelos so
simplificaes da realidade e ns os utilizamos para compreender melhor o sistema que
estamos desenvolvendo. Ainda em cima de seus princpios, citamos quatro objetivos da
modelagem [BOO2000]:
Os modelos ajudam a visualizar o sistema como ele ou como desejamos que seja;
Os modelos permitem especificar a estrutura ou o comportamento de um sistema;
Os modelos proporcionam um guia para a construo do sistema; Os modelos documentam as decises tomadas.
Quanto maior a complexidade do software, maior ser a necessidade da
utilizao da modelagem, pois construmos modelos de sistemas complexos para
compreend-los em sua totalidade.
A modelagem pode ser feita at mesmo de maneira informal, atravs de
rascunhos ou resumos de modelos, porm a utilizao de mtodos formais permite uma
padronizao do modelo e a garantia de que algumas regras de desenvolvimento pr-
estabelecidas sejam obedecidas.
-
7
2.2 - Princpios da modelagem
Baseado no estudo do uso da modelagem possvel afirmar quatro
princpios norteadores [BOO2000]:
A escolha dos modelos a serem criados tem profunda influncia sobre a
maneira como um determinado problema atacado e como uma soluo definida.
Cada modelo poder ser expresso em diferentes nveis de preciso.
Os melhores modelos esto relacionados realidade.
Nenhum modelo nico suficiente. Qualquer sistema no-trivial ser
melhor investigado por meio de um pequeno conjunto de modelos quase independentes.
3 - Modelos de software
Desde que o homem passou a usar mquinas de computao, surgiu a
necessidade de repassar as instrues e os dados para a obteno da soluo esperada.
Simultaneamente, de acordo com a evoluo tecnolgica, aumentou tambm o grau de
dificuldade dos problemas propostos. Veremos a seguir um pouco do histrico da
evoluo das metodologias de desenvolvimento de sistemas e alguns dos conceitos
bsicos de uma tcnica que vem sendo amplamente utilizada: a orientao a objetos.
3.1 - Foco em algoritmos
Durante muitos anos os computadores foram utilizados somente por grandes
empresas. At que no princpio da dcada de 70 houve uma queda no preo dos
equipamentos de informtica e algumas empresas de mdio e pequeno porte puderam se
aventurar em transferir para os sistemas informatizados algumas funes de carter
operacional.
Todo o conhecimento que se tinha at ento de tcnicas de desenvolvimento
de software no era suficiente para contornar os problemas de desenvolvimento de
sistemas, principalmente se produzidos em grande escala, como passou a se exigir com
a demanda de um pblico consumidor de programas.
-
8
E desta necessidade surgiu uma tcnica com o foco no desenvolvimento do
algoritmo, que at hoje bastante utilizada e difundida chamada de programao
estruturada, seguida pelo conceito de desenvolvimento estruturado de sistemas. Como
uma alternativa para sanar as dificuldades de um desenvolvimento em grande escala, a
metodologia estruturada pregava alguns princpios [OLI1996]:
Abstrao
A soluo de um problema pode ser encontrada mais facilmente se o mesmo
for analisado de forma a separar os demais aspectos que possam atrapalhar numa etapa
(relevar os detalhes no necessariamente importantes);
Formalidade
Deve ser seguido um caminho rigoroso e metdico para solucionar um
problema;
Dividir para conquistar
Dividir o problema em partes menores, independentes e com possibilidade
de serem mais simples de entender e solucionar;
Hierarquizao
Os componentes da soluo devem ficar dispostos em uma estrutura
hierrquica. O sistema deve ser entendido e construdo nvel a nvel, onde cada novo
nvel acrescenta mais detalhes.
Como esses princpios facilitavam a vida dos programadores, a abordagem
estruturada obteve grande sucesso e ainda hoje amplamente utilizada.
3.2 - Foco em objetos
A revoluo ocorrida na dcada de 70 voltou a ocorrer no final da dcada de
90, onde os preos dos equipamentos voltaram a cair. Um bom nmero de empresas, de
diversos portes, j possuam parte de seus sistemas com um considervel nvel de
informatizao, foi amplamente divulgado o uso da Internet como meio de comunicao
e busca macia de informao e finalmente o computador passou a ser um
-
9
eletrodomstico dos indivduos de classe mdia e uma ferramenta de trabalho dirio
para uma grande quantidade de pessoas.
Surge ento a necessidade de se produzir softwares mais atraentes,
dinmicos e com alto poder de troca de informaes [OLI1996]. Tais aplicaes se
caracterizam por:
Interao intensiva com o usurio; Uso de interfaces grficas (GUI-Graphics User Interface); Necessidade permanente de alterao e expanso, dada a velocidade de
mudanas na tecnologia do hardware;
Interao com outros sistemas, possibilitando a troca de dados; Portabilidade para diversas plataformas e sistemas operacionais; As tcnicas oferecidas pela metodologia estruturada no foram suficientes
para atender com a satisfao desejada a elaborao deste tipo de aplicao. Era
necessrio partir para outro tipo de metodologia, que permitisse o desenvolvimento de
sistemas com essas novas caractersticas. Comeou a ser adotada por parte dos
profissionais da rea de desenvolvimento de sistemas a abordagem orientada a objetos.
3.3 - Abordagem orientada a objetos
Apesar de no ser um conceito totalmente novo no meio acadmico,
somente na dcada de 90, esta abordagem fora tambm no mercado de software. Basta
citar que as grandes empresas da rea de desenvolvimento de sistemas oferecem
ferramentas baseadas no conceito de objetos.
A abordagem orientada a objetos fundamentada no que coletivamente
chamamos de modelo de objetos, que engloba os princpios da abstrao,
hierarquizao, encapsulamento, classificao, modularizao, relacionamento,
simultaneidade e persistncia. Embora no sejam individualmente novos, importante
ressaltar que no modelo de objetos esses elementos so agora agrupados de forma
sinrgica.
-
10
Como a abstrao e a hierarquizao j foram detalhados na parte da
abordagem estruturada, vamos analisar os outros princpios:
Encapsulamento
Mecanismo pelo qual podemos ocultar detalhes de uma estrutura complexa,
que poderiam interferir durante o processo de anlise. Por exemplo, todos ns sabemos
que um carro composto de motor, lataria, bancos, etc. O motor por sua vez composto
por uma grande quantidade de peas e elementos de ligaes. Mas na hora de preencher
um cadastro financeiro para solicitao de um emprstimo pessoal, nos campos para
colocar os detalhes do carro, no ser necessrio dizer quais so as peas que formam o
motor do carro, apesar de sabermos que sem estas, o valor do carro cai bastante. Estes
detalhes sero encapsulados pelas caractersticas gerais do carro.
Classificao
o ato de associar um objeto analisado a uma determinada categoria. Ao
classificarmos um objeto, estamos afirmando que este pertence a uma determinada
classe. Esta associao feita comparando as caractersticas e funes do objeto em
questo com as caractersticas e funes dos objetos que pertencem quela categoria.
Quando vemos um gato, por exemplo, podemos afirmar que ele pertence classe dos
mamferos, porque conhecendo as caractersticas e funes dos mamferos e dos gatos,
fica fcil chegar a esta concluso.
Modularizao
Em um sistema previamente dividido, podemos juntar partes com algumas
semelhanas. Note que a idia de modularizar facilita bastante a aplicao dos outros
princpios.
Relacionamento
Para o funcionamento do todo, necessrio que as partes funcionem
separadamente, mas cooperativamente.
Paralelismo
Mesmo em um sistema simples, pode haver diversas aes a serem
executadas concorrentemente. necessrio um correto gerenciamento dos recursos
-
11
computacionais para haver uma correta distribuio do tempo entre as tarefas a serem
executadas.
Persistncia
Um objeto em um programa utiliza algum espao para armazenamento e
manipulao e existe por um perodo de tempo em particular. Muitas vezes o tempo de
vida de um objeto supera o tempo de vida do sistema que o manipula. Este princpio
prega que deve haver uma ateno especial nesta manipulao.
3.3.1 - Objetos e classes
Usamos o termo objeto para representar um determinado elemento do
mundo real. Mas somente analisaremos os objetos que tm relevncia para a soluo de
um determinado problema. Portanto, o objeto uma entidade do mundo real que merece
representao para o ambiente estudado.
Como exemplos de objetos, podemos citar os objetos fsicos (um livro, uma
mercadoria), funes de pessoas para os sistemas (cliente, vendedor), eventos (uma
compra, um telefonema), interaes entre outros objetos (um item de uma nota fiscal
uma interao entre uma compra e um produto do estoque) e lugares (loja matriz,
revenda norte).
Um objeto pode ser simples ou composto de demais objetos. Em geral a
maioria dos objetos so compostos, pois sempre podemos divid-los em partes menores
at chegar a elementos indivisveis. Um sistema um grande objeto composto de outros
objetos, formando um mecanismo.
Um objeto composto de atributos e mtodos e tem a capacidade de trocar
mensagens com outros objetos.
Os atributos, ou propriedades, representam as caractersticas dos objetos e
podem ser fixos ou variveis. Por exemplo, o objeto computador tem como
caractersticas a marca, o modelo, a quantidade de memria RAM, o tamanho do disco
rgido, se tem ou no CD-ROM, etc.
O estado de um objeto o conjunto de valores de seus atributos em um
determinado instante. Os servios ou mtodos so as funes que operam sobre o
-
12
mesmo. O comportamento de um objeto como ele age e reage em termos de suas
mudanas de estado e troca de mensagens com outros objetos. A identidade a
caracterstica que um objeto deve ter de ser distinguido dos demais.
Uma classe representa uma coleo de objetos que possuem caractersticas e
comportamentos comuns e de agora em diante, diremos que um objeto uma instncia
de uma determinada classe. Para estabelecer que criaremos nossos objetos baseados nas
caractersticas definidas em suas classes. A nfase da abordagem orientada a objetos
dada na descrio das classes, e no dos objetos, como se poderia pensar pelo nome. A
Fig. 2.1 mostra um exemplo de classe e algumas de suas respectivas instncias
(objetos).
+receberDados()+processarDados()+enviarDados()
-marca-modelo-quantidadeMemoriaPrincipal-quantidadeMemoriaSecundaria-possuiCdRom
Computador
iMac
Classe
Objetos
Figura 2.1 Exemplo de classe e suas instncias (objetos).
Todo objeto pertence a uma determinada classe durante sua existncia, no
podendo modificar sua classificao.
-
13
3.3.2 - Relacionamento entre classes
As classes devem poder se relacionar para que o sistema possa funcionar.
As principais formas de relacionamento so as seguintes:
Associao
Um exemplo tpico de associao a feita entre as classes Aluno e
Responsvel de um sistema de controle acadmico. Um objeto da classe Aluno est
associado a um nico responsvel, mas uma mesma pessoa pode ser responsvel por
mais de um aluno. Podem haver relacionamentos de cardinalidades um-para-um, um-
para-muitos e muitos-para-muitos.
Especializao
Dada uma determinada classe, criamos uma outra com acrscimos ou
modificaes de novos atributos ou servios que a tornam mais especfica a um
determinado comportamento.
Herana
o mecanismo pelo qual uma classe obtm as caractersticas e mtodos de
outra para expand-la ou especializ-la de alguma forma.
Agregao
o ato de agregar, juntar duas ou mais classes para formar uma nova classe.
Alm desses conceitos, se analisarmos as obras dos diversos autores que se
propem a estudar os detalhes da abordagem orientada a objetos, veremos uma
quantidade muito grande de variaes, conceitos, especificaes e documentaes.
3.4 - Desenvolvimento de sistemas orientados a objetos
perfeitamente possvel modelar uma soluo utilizando totalmente a
abordagem orientada a objetos desde a fase de anlise, passando pelo projeto do
software e chegando ao cdigo atravs de uma linguagem de programao orientada a
objetos.
-
14
Uma grande vantagem de se pensar totalmente orientado a objeto o fato de
que um mesmo objeto, concebido na fase de anlise, passa com as mesmas
caractersticas desde o usurio at o programador que ser responsvel pela codificao
final.
A abordagem orientada a objetos teve diversas contribuies ao longo dos
ltimos anos. Entre elas os conceitos que Coad, Yourdon, Pressman e tantos outros
abordaram, discutiram e definiram em suas publicaes. Figurando entre os principais,
temos:
A orientao a objetos uma abordagem para a produo de modelos que especifiquem o domnio do problema de um sistema.
Quando construdos corretamente, sistemas orientados a objetos so flexveis a mudanas, possuem estruturas bem conhecidas e provm a oportunidade de
criar e realizar componentes totalmente reutilizveis.
Modelos orientados a objetos so realizados convenientemente utilizando uma linguagem de programao orientada a objetos. A engenharia de
software orientada a objetos muito mais que utilizar mecanismos de sua
linguagem de programao, saber utilizar da melhor forma possvel todas
as tcnicas da modelagem orientada a objetos.
A abordagem orientada a objetos no s teoria, mas uma tecnologia de
comprovada eficincia e qualidade usada em inmeros projetos para construo de
diferentes tipos de sistemas.
A abordagem orientada a objetos requer um mtodo que integre o processo
de desenvolvimento e a linguagem de modelagem com a construo de tcnicas e
ferramentas adequadas.
Um dos problemas de se tentar estudar a abordagem orientada a objetos o
fato de que alguns autores montam suas prprias concepes sobre esta teoria, surgindo
assim vrias escolas. A Linguagem de Modelagem Unificada UML (Unified
Modeling Language) surgiu como uma tentativa de soluo a este problema e tenta
concentrar os principais conceitos da modelagem orientada a objetos em um nico
mtodo.
-
15
4 - Linguagem de Modelagem Unificada - UML
Para utilizarmos qualquer mtodo no desenvolvimento de software,
precisamos ter um conjunto de termos, nomenclaturas e ferramentas padronizadas
formando uma linguagem ou notao que os tcnicos entendam e efetivamente utilizem.
A UML vem justamente de encontro a estes objetivos.
A UML foi desenvolvida por Grady Booch, James Rumbaugh, e Ivar
Jacobson que so trs conhecidos autores de metodologias de desenvolvimento de
software seguindo a abordagem orientada a objetos. A UML nasceu da juno do que
havia de melhor nas suas respectivas metodologias.
A seguinte definio aparece em [MAT2002]:
A UML uma composio das boas caractersticas de outras notaes de
ferramentas direcionadas orientao a objetos, tornando-se assim a ferramenta ideal
para conceber, compreender, testar, validar, arquitetar lgica e fisicamente e ainda
identificar todos os possveis comportamentos do sistema.
Para o exerccio de sua funo, a UML possui trs grandes blocos para
modelar um sistema: itens, relacionamentos e diagramas. Itens so as abstraes
identificadas como elementos de primeira classe em um modelo, os relacionamentos
renem esses itens e os diagramas agrupam colees interessantes de itens [BOO2000].
4.1 - Itens
Os itens constituem os blocos de construo bsicos da UML e sero usados
para escrever modelos bem-formados.
4.1.1 - Itens estruturais
So os itens estticos do modelo, representando elementos conceituais ou
fsicos. Foram definidos sete elementos como pertencentes ao grupo de itens estruturais:
interface, classe, colaborao, caso de uso, classe ativa, componente e n.
Uma interface um conjunto de operaes que especificam servios de uma
classe ou componente, descrevendo o comportamento externamente visvel desse
-
16
elemento. A interface define o conjunto de operaes (assinaturas), mas no suas
realizaes.
+Object aceita(in EvalVisitante V)+String infix(in PrecedenciaAbsFab f)+Precedencia mkPrecedencia(in PrecedenciaAbsFab f)
interfaceExp
Figura 2.2 Representao grfica de interface em UML.
A classe a descrio de um conjunto de objetos que compartilham os
mesmos atributos, operaes, relacionamentos e semntica. Uma classe realiza uma ou
mais interfaces. representada graficamente como um retngulo com seu nome,
atributos e operaes conforme mostra a Fig. 2.3.
+Racional(in int a, in int b)+Object eval()+String infix()+boolean prec(in Soma E)+boolean prec(in Produto E)+String toString()+int n()+int d()
-int n-int d
Racional
Figura 2.3 Representao grfica de classe em UML.
As colaboraes definem interaes e so sociedades de papis e outros
elementos que funcionam em conjunto para proporcionar um comportamento
cooperativo superior soma de todos os elementos.
Um caso de uso a descrio de um conjunto de seqncia de aes
realizadas pelo sistema que proporciona resultados observveis importantes para um
determinado elemento participante do processo, normalmente chamado de ator.
As classes ativas so classes cujos objetos tem um ou mais processos ou
threads e, portanto, podem iniciar a atividade de controle.
-
17
Os componentes so partes fsicas e substituveis de um sistema, que
proporcionam a realizao de um conjunto de interfaces. Normalmente os componentes
representam o pacote fsico de elementos lgicos diferentes, como classes, interfaces e
colaboraes. Graficamente um componente representado por um retngulo com abas,
incluindo somente seu nome, conforme mostra a Fig.2.4.
Componente
Figura 2.4 Representao grfica de um componente em UML.
Um n um elemento fsico existente em tempo de execuo que representa
um recurso computacional, geralmente com alguma memria e, freqentemente,
capacidade de processamento (cf. Fig 2.5). Um conjunto de componentes poder estar
contido em um n e tambm poder migrar de um n para outro.
N
Figura 2.5 Representao grfica de um n em UML.
4.1.2 - Itens comportamentais
Representam as partes dinmicas de um modelo em UML e seus
comportamentos no tempo e no espao. Geralmente so dois: interao e mquina de
estado.
Uma interao um comportamento que abrange um conjunto de
mensagens trocadas entre um conjunto de objetos de um determinado contexto para a
realizao de propsitos especficos.
Uma mquina de estado um comportamento que especifica as seqncias
de estados pelas quais objetos ou interaes passam durante sua existncia em resposta
a eventos, bem como suas respostas a esses eventos.
-
18
4.1.3 - Itens de agrupamento
So as partes organizacionais dos modelos de UML. So os blocos em que
os modelos podem ser decompostos.
O pacote o principal item de agrupamento e um mecanismo de propsito
geral para a organizao de elementos em grupos (cf. Fig. 2.6). Ele puramente
conceitual e s existe em tempo de desenvolvimento. Uma variao do pacote o
framework, que ser visto com mais detalhes no captulo 3.
Pacote
Figura 2.6 Representao grfica de um pacote.
4.1.4 - Itens anotacionais
So as partes explicativas do modelo, sendo comentrios para descrever,
esclarecer ou fazer alguma observao sobre qualquer elemento. Seu representante a
nota (cf. Fig. 2.7), que funciona como um smbolo grfico para agrupar os comentrios.
Nota
Figura 2.7 Representao grfica do item anotacional.
4.2 - Relacionamentos
So os blocos relacionais bsicos de construo da UML, e de suma
importncia para a construo de modelos bem-estruturados. Podem ser divididos em
quatro tipos: dependncia, associao, generalizao e realizao.
A dependncia cria um relacionamento semntico entre dois itens, nos quais
a alterao de um pode afetar a semntica do outro.
-
19
A associao um relacionamento estrutural que descreve um conjunto de
ligaes, que so conexes entre objetos. A agregao um tipo especial de associao,
que representa um relacionamento estrutural entre um membro e seu grupo.
A generalizao um relacionamento de especializao/generalizao, nos
quais os objetos dos elementos generalizados so substituveis por objetos do elemento
especializado. Dessa maneira os objetos filhos (especializados) compartilham a
estrutura e o comportamento dos pais (generalizados).
A realizao um relacionamento semntico entre classificadores, em que
um classificador especifica um contrato que outro classificador garante executar.
Normalmente so encontrados entre a interface e as classes ou componentes que a
realizam e entre casos de uso e as colaboraes que os realizam.
4.3 - Diagramas
Os diagramas so apresentaes grficas em forma de grafos que
representam os elementos de um modelo sob uma determinada viso parcial. No total
existem nove diagramas, mas a utilizao de cada um depende da necessidade do
modelo. Os tipos de diagramas so: classes, objetos, casos de uso, seqncias,
colaboraes, estados, atividades, componentes e implantao.
O diagrama de classes exibe um conjunto de classes, interfaces e
colaboraes, bem como seus relacionamentos. Um exemplo de diagrama de classes
utilizado como exemplo no Captulo 4 apresentado na Fig. 2.8.
-
20
interfaceExp
Num Soma ProdutoRacional
2
int
2
Figura 2.8 Diagrama de classes.
O diagrama de objetos exibe um conjunto de objetos e seus
relacionamentos. So retratos estticos de instncias de itens encontrados em diagramas
de classes.
O diagrama de caso de uso exibe um conjunto de casos de uso, atores e seus
relacionamentos. So importantes para uma viso da organizao e modelagem do
comportamento do sistema.
O diagrama de seqncias um diagrama de interao cuja nfase est na
ordenao temporal das mensagens e o diagrama de colaborao um diagrama de
interao cuja nfase est na organizao estrutural dos objetos que enviam e recebem
mensagens.
-
21
O diagrama de estados exibe uma mquina de estados, formada por estados,
transies, eventos e atividades e abrange uma viso dinmica de um sistema.
O diagrama de atividade um tipo especial de estado, exibindo o fluxo de
uma atividade para outra no sistema.
O diagrama de componente exibe as organizaes e as dependncias
existentes em um conjunto de componentes, abrangendo a viso esttica da realizao
de um sistema. Tipicamente os componentes so mapeados para uma ou mais classes,
interfaces ou colaboraes.
O diagrama de implantao mostra a configurao dos ns de
processamento em tempo de execuo e os componentes neles existentes.
5 - Consideraes sobre a modelagem usando objetos
Existem vrias maneiras de se definir um modelo, mas no caso de um
software, as duas abordagens mais comuns so: foco em algoritmos e foco em objetos.
Historicamente, o foco em algoritmos foi muito utilizado, mas vem sendo
gradativamente substitudo pelo foco em objetos nos sistemas em todos os tipos de
domnio de problemas, abrangendo todos os graus de tamanho e complexidade.
A utilizao da abordagem orientada a objetos inevitvel para quem pensa
em comear a desenvolver sistemas adequados ao nosso tempo. A adoo de uma
linguagem padronizada para representar os resultados das anlises dos modelos
imprescindvel e a UML vem atender justamente essa necessidade.
Hoje existem ferramentas grficas que facilitam bastante a vida do
programador, mas no fazem o principal: montar a soluo com a escolha correta das
classes e suas estruturas de cooperao. O grande trabalho continua sendo o do mentor
que est por trs de todas as solues dos problemas deste mundo: o crebro humano.
-
Captulo 3
Padres de Projeto
1 - Introduo
O processo de elaborao de software pode ter momentos em que a soluo
desejada j foi vista, analisada, projetada e desenvolvida por algum em situao
parecida. Isso nos leva a pensar se no existe uma maneira de compartilhar um conjunto
de solues de problemas previamente resolvidos, acessveis e em um formato de fcil
assimilao. Os padres de projeto nasceram justamente para suprir esta necessidade.
O uso de padres1 pode fazer a diferena na qualidade do processo de
desenvolvimento de software. O projetista de software pode e deve usar padres para
agilizar o tempo de desenvolvimento, sem a necessidade de redescobrir solues j
experimentadas com sucesso o tal chamado reinvento da roda. Maximizando as
possibilidades de sucesso do produto final.
Este captulo consacra-se ao estudo de padres, conceitos e perspectivas de
utilizao.
2 - Padres
O conceito bsico de um padro tambm pode ser visto como o conceito
bsico de um sistema: adicionar uma camada de abstrao entre o problema e a soluo
[ECK2002]. Em [BOO2000] vemos uma outra definio de padro: Um padro uma
soluo comum para um problema bsico em um determinado contexto. Christopher
Alexander descreve padres da seguinte maneira:
1 Freqentemente neste texto, utiliza-se a palavra padres com o significado restrito a padres de
projeto.
-
23
Cada padro descreve um problema no nosso ambiente e o ncleo da sua
soluo, de tal forma que voc possa usar esta soluo mais de um milho de vezes, sem
nunca faz-lo da mesma maneira [GAM2000].
Partindo dessas idias, podemos visualizar um padro como um elemento
auxiliar na realizao de software que nos oferece uma interface entre um problema e
uma soluo anteriormente pensada, projetada, resolvida e testada.
Esses conceitos so verdadeiramente aplicados em muitas reas de
conhecimento. Em engenharia de software so importantes, pelos seguintes motivos:
O uso de padres facilita a reutilizao de projetos e arquiteturas bem sucedidas. Expressar tcnicas testadas e aprovadas as torna mais acessveis
para os projetistas de novos sistemas.
Os padres de projeto ajudam a escolher opes de projeto que tornam um sistema reutilizvel e a evitar alternativas que comprometam a reutilizao.
Os padres de projeto podem melhorar a documentao e a manuteno de sistemas ao fornecer uma especificao clara das interaes entre classes e
objetos e o seu objetivo subjacente.
Em suma, ajudam um projetista a obter um projeto correto e rpido
[GAM2000].
Em todos os sistemas bem-estruturados, podemos encontrar uma grande
variedade de padres em diversos nveis de abstrao. Padres especificam a estrutura e
o comportamento de uma sociedade de classes; os padres de arquitetura especificam a
estrutura e o comportamento de todo um sistema. Criando padres explicitamente em
um sistema, o tornamos mais compreensvel e fcil de desenvolver e manter.
Os padres nos ajudam a visualizar, especificar, construir e documentar os
artefatos de um sistema complexo de software. Podemos usar a engenharia de produo
para um sistema, selecionando um conjunto de padres apropriados e aplicando-os s
abstraes especficas do seu domnio. Ao finalizar um sistema, podemos especificar os
padres nele existentes para que, mais tarde, quando outra pessoa quiser reutiliz-lo ou
adapt-lo o faa com mais clareza e objetivo [BOO2000].
-
24
3 - Frameworks
Um mecanismo um padro de projeto aplicado a uma sociedade de classes
e um framework um padro de arquitetura que fornece um modelo extensvel a
qualquer aplicao dentro de um domnio especfico. Os padres so utilizados para
especificar os mecanismos e frameworks que compem a arquitetura do sistema.
[BOO2000].
Podemos pensar em um framework como um tipo de arquitetura bsica
abrangendo um conjunto de mecanismos que trabalham juntos para resolver uma classe
especfica de problemas. Ao especificar um framework, especificamos o esqueleto da
sua arquitetura, juntamente com os conectores, guias, botes e indicadores que expomos
aos usurios que desejam adapt-lo ao seu prprio contexto.
Um framework captura as decises de projeto que so comuns ao seu
domnio de aplicao. Assim, frameworks enfatizam reutilizao de projetos em relao
reutilizao de cdigo, embora um framework, geralmente, inclua subclasses
concretas que podemos utilizar imediatamente.
Um framework montado atravs do uso de padres tem muito maior
possibilidade de atingir altos nveis de reusabilidade de projeto e cdigo, comparado
com um que no usa padres. Frameworks maduros comumente incorporam vrios
padres de projeto. Os padres ajudam a tornar a arquitetura do framework adequada a
muitas aplicaes diferentes, sem necessidade de reformulao [GAM2000].
Ser visto no Captulo 4 um exemplo de framework para a avaliao de
expresses matemticas.
4 - Um exemplo: a arquitetura MVC
A arquitetura MVC (Modelo / Visual / Controlador Model / View /
Controler) tem sua origem no SmallTalk, onde foi aplicada para mapear as tradicionais
tarefas de entrada, processamento e sada para interfaces grficas do usurio. Em
seguida, a arquitetura MVC foi adaptada para mapear os mesmos conceitos em domnio
de aplicaes multi-camadas.
-
25
A arquitetura MVC, de fato um padro, composto por trs tipos de
objetos. O modelo o objeto de aplicao, o visual a apresentao na tela e o
controlador define a maneira pela qual a interface grfica reage s entradas do usurio.
Antes do padro MVC, os projetos de interface grfica tendiam a agrupar esses objetos.
O padro MVC os separa para aumentar a flexibilidade e a reutilizao [GAM2000].
O modelo representa os dados da aplicao e as regras de negcios que
norteiam o acesso e atualizao dos dados. Geralmente o modelo serve como uma
aproximao do software para o processo do mundo real, logo, quando definimos o
modelo, aplicamos as tcnicas de modelagem do mundo real.
O visual o responsvel por mostrar o contedo do modelo. Acessa os
dados da aplicao atravs do modelo e especifica como esses dados devem ser
apresentados. sua responsabilidade manter a consistncia da apresentao quando
existe alguma mudana no modelo.
O controlador traduz as interaes do visual para aes a serem executadas
pelo modelo. As aes exercidas pelo modelo incluem ativaes de processos de
negcios ou mudanas no estado do modelo. Baseado nas interaes do usurio e nos
resultados das aes do modelo, o controlador responde selecionando o visual
apropriado.
A arquitetura MVC traz os seguintes benefcios [SUN2002]:
Mltiplas vises usando um mesmo modelo:
A separao entre modelo e visual permite que mltiplos visuais possam ser
usados em um mesmo modelo. Conseqentemente, o modelo de componentes de um
aplicao fica mais fcil de realizar, testar e manter, desde que todos os acessos ao
modelo sejam efetuados pelos componentes.
Suporte facilitado para novos tipos de clientes:
Para dar suporte a mais um cliente, basta desenvolver um visual e um
controlador e encaix-los no modelo existente.
-
26
Um exemplo de aplicao da arquitetura MVC visto em [GAM2000]. Um
modelo contendo alguns valores de dados e trs visuais, contendo uma planilha, um
histograma e um grfico de pizza, apresentam os dados de vrias maneiras conforme
Fig. 3.1.
Tabela
a b cx 60 30 10y 50 30 20z 80 10 10
Histograma
a b c
Grfico em forma de pizza
a
b
c
visuais
a = 50%b = 30%c = 20%
modelo
Figura 3.1 Exemplo de aplicao da arquitetura MVC [GAM2000].
Um modelo relaciona-se com seus visuais quando seus valores se
modificam, e os visuais se comunicam com o modelo para acessar os valores que
mostraro, os controladores foram omitidos por simplificao.
-
27
5 - Descrevendo padres de projeto
Normalmente um padro de projeto possui quatro elementos essenciais
[GAM2000]:
1. Nome do padro
uma referncia que podemos usar para descrever um problema de projeto,
suas solues e conseqncias em uma ou duas palavras. Dar nome a um padro
aumenta imediatamente o nosso vocabulrio de projeto. Isso nos permite projetar em
um nvel mais alto de abstrao. Ter um vocabulrio para padres permite-nos
conversar sobre eles com nossos colegas e referenci-los em nossa documentao. O
nome torna mais fcil o pensar sobre projetos e a comunic-los, bem como os custos e
benefcios envolvidos, a outras pessoas.
2. Problema
Descreve quando aplicar o padro. Ele explica o problema e o seu contexto.
Pode descrever problemas de projeto especficos, tais como representar algoritmos
como objetos. Pode descrever a estrutura de classes ou objetos sintomticos de um
projeto. Algumas vezes, o problema incluir uma lista de condies que devem ser
satisfeitas para que faa sentido aplicar o padro.
3. Soluo
Descreve os elementos que compem o projeto, seus relacionamentos, suas
responsabilidades e colaboraes. A soluo no descreve um projeto concreto ou uma
realizao em particular porque um padro como um gabarito que pode ser aplicado
em muitas situaes diferentes. Em vez disso, o padro fornece uma descrio abstrata
de um problema de projeto e de como um arranjo geral de elementos (classes e objetos,
no nosso caso) resolve o mesmo.
4. Conseqncias
Fornece o resultado e anlise das vantagens e desvantagens da aplicao do
padro. Embora as conseqncias sejam raramente mencionadas quando descrevemos
decises de projeto, elas so crticas para a avaliao de alternativas de projetos e para a
compreenso dos custos e benefcios da aplicao do padro. As conseqncias para o
-
28
software freqentemente envolvem compromissos de espao e tempo. Elas tambm
podem abordar aspectos sobre linguagens e realizao. Uma vez que a reutilizao
freqentemente um fator no projeto orientado a objetos, as conseqncias de um padro
incluem o seu impacto sobre a flexibilidade, a extensibilidade ou a portabilidade de um
sistema. Relacionar estas conseqncias explicitamente ajuda a compreend-las e
avali-las.
A descrio de um padro de projeto envolve os elementos que o compem,
suas funes e documentaes. Alm dos quatro elementos essenciais vistos a pouco,
podemos tambm utilizar outras formas de descrio de um padro. A forma
apresentada a seguir conhecida pelo nome de formato GoF [GAM2000]:
Nome e classificao do padro
O nome do padro expressa a sua prpria essncia de forma sucinta. Um
bom nome vital, porque ele se tornar parte do seu vocabulrio de projeto. A
classificao do padro descreve a que categoria, por escopo ou finalidade, ele pertence.
Inteno e objetivo
uma curta declarao que explica o que faz o padro de projeto, quais os
seus princpios e sua inteno e que tpico ou problema particular de projeto ele trata e
se prope a ajudar resolver.
Tambm conhecido como
Outros nomes bem conhecidos para o padro, caso existam.
Motivao
Um cenrio que ilustra um problema de projeto e como as estruturas de
classes e objetos no padro solucionam o problema.
Aplicabilidade
Mostra quais as situaes nas quais o padro de projeto pode ser aplicado,
que exemplos de maus projetos ele pode tratar e como podemos reconhecer essas
situaes.
Estrutura
-
29
Uma representao grfica das classes do padro.
Participantes
As classes e/ou objetos que participam do padro de projeto e suas
responsabilidades.
Colaboraes
Como os participantes colaboram para executar suas responsabilidades.
Conseqncias
Mostra como o padro suporta a realizao de seus objetivos, quais so os
seus custos e benefcios, os resultados da sua utilizao e que aspecto da estrutura do
sistema ele permite variaes.
Realizao
Mostra que armadilhas, sugestes ou tcnicas voc precisa conhecer quando
da realizao do padro e se existem consideraes especficas de linguagem.
Exemplo de cdigo
Fragmentos ou blocos de cdigo que ilustram como podemos programar o
padro em uma linguagem de programao adequada, por exemplo, Java, C++ ou
SmallTalk.
Usos conhecidos
Exemplos do padro encontrados em sistemas conhecidos.
Padres relacionados
Mostra quais padres de projeto esto intimamente relacionados com este,
quais so as diferenas importantes e com quais outros padres este deveria ser usado.
-
30
O formato GoF2 o mais utilizado e contempla os elementos essenciais de
um padro. Pode-se, claro, se necessrio, envolver outras caractersticas de um
determinado padro quando da sua descrio ou divulgao.
6 - O catlogo GoF
Os principais padres para projeto de software foram catalogados em
[GAM2000]. Contm a descrio de vinte e trs padres, so eles:
Adaptador (Adapter)
Converte a interface de uma classe em outra interface mais adequada s
classes clientes. O padro adaptador permite que certas classes trabalhem em conjunto,
pois de outra forma seria impossvel por causa de suas interfaces incompatveis. Isso
permite que classes possuindo interfaces incompatveis entre si adaptem-se umas as
outras para um trabalho cooperativo.
Aproximador (Proxy)
Fornece um objeto representante, ou um marcador de outro objeto, para
controlar o acesso ao mesmo.
Cadeia de Responsabilidade (Chain of Responsibility)
Evita o acoplamento do remetente de uma solicitao ao seu destinatrio,
dando a mais de um objeto a chance de tratar uma determinada solicitao. Encadeia os
objetos receptores e passa a solicitao ao longo da cadeia at que um objeto possa
trat-la.
Comando (Command)
Encapsula uma solicitao como um objeto, desta forma permitindo a
parametrizao de clientes com diferentes solicitaes, enfileire ou registre solicitaes
e suporte operaes que possam ser desfeitas.
2 GoF vem do ingls Gang of Four e usado como referncia ao grupo composto por Erich Gamma,
Richard Helm, Ralph Johnson e John Vlissides.
-
31
Composto (Composite)
Compe objetos em estrutura de rvore para representar hierarquias do tipo
parte-todo. O padro composto permite que os clientes tratem objetos individuais e
composies de objetos de maneira uniforme.
Conjunto Unitrio (Singleton)
Garante que uma classe tenha somente uma instncia e fornece uma
referncia global de acesso.
Construtor (Builder)
Separa a construo de um objeto complexo da sua representao, de modo
que o mesmo processo de construo possa criar diferentes representaes.
Decorador (Decorator):
Atribui responsabilidades adicionais a um objeto dinamicamente. O padro
Decorador fornece uma alternativa flexvel a subclasses para extenso da
funcionalidade.
Estado (State)
Permite que um objeto altere seu comportamento quando seu estado interno
alterado. O objeto parecer ter alterado sua classe.
Estratgia (Strategy)
Define uma famlia de algoritmos, encapsula cada um deles e os faz
intercambiveis. O padro Estratgia permite que o algoritmo varie independentemente
dos clientes que o utilizam.
Fbrica Abstrata (Abstract Factory)
Fornece uma interface para a criao de famlias de objetos relacionados ou
dependentes sem especificar suas classes concretas.
Fachada (Faade)
Fornece uma interface unificada para um conjunto de interfaces em um
subsistema. O padro Fachada define uma interface de nvel mais alto que torna o
subsistema mais fcil de usar.
-
32
Interpretador (Interpreter)
Dada uma linguagem, define uma representao para sua gramtica
juntamente com um interpretador que usa a representao para interpretar sentenas
nesta linguagem.
Iterador (Iterator)
Fornece uma maneira de acessar seqencialmente os elementos de um
objeto agregado sem expor sua representao interna.
Lembrete (Memento)
Sem violar a encapsulao, captura e externaliza um estado interno de um
objeto, de modo que o mesmo possa posteriormente ser restaurado.
Mediador (Mediator)
Define um objeto que encapsula como um conjunto de objetos faz suas
interaes. O padro mediador promove o acoplamento fraco entre classes ao evitar que
os objetos refiram-se explicitamente uns aos outros, permitindo que suas interaes
variem independentemente.
Mtodo de Fbrica (Factory Method)
Define uma interface para criar um objeto, mas deixa a cargo das subclasses
a deciso da instanciao. O padro mtodo de fbrica permite a uma classe postergar a
instanciao s subclasses.
Mtodo de Molde (Template Method)
Define o esqueleto de um algoritmo associado a uma operao, postergando
a definio de alguns passos para subclasses. Permite que as subclasses redefinam
certos passos de um algoritmo sem modificar, no entanto, sua estrutura.
Observador (Observer)
Define uma dependncia um-para-muitos entre objetos, de modo que,
quando um objeto modifica o seu estado, todos os seus dependentes so
automaticamente notificados e atualizados.
Peso Leve (Flyweight)
-
33
Usa compartilhamento para suportar grandes quantidades de objetos, de
granularidade fina, de maneira eficiente.
Ponte (Bridge)
Separa uma abstrao da sua realizao, de modo que as duas possam variar
independentemente.
Prottipo (Prototype)
Especifica os tipos de objetos a serem criados usando uma instncia
particular como prottipo. A criao de novos objetos dar-se- pela cpia do prottipo.
Visitante (Visitor)
Representa uma operao a ser executada sobre os elementos da estrutura de
um objeto. O padro visitante permite que possamos definir uma nova operao sem
modificar as classes dos elementos sobre os quais opera.
Todos esses padres podem ser agrupados por famlias de padres
relacionados, de acordo com o seu propsito e escopo.
Na viso de seu propsito, a finalidade levada em considerao: criao,
estrutural e comportamental. Um padro classificado como de criao preocupa-se com
o processo de criao dos objetos. Um padro estrutural lida com a composio de
classes ou de objetos. Um padro comportamental caracteriza a maneira pela qual
classes ou objetos interagem e distribuem responsabilidades.
Na viso de seu escopo, verificado se o padro se aplica primariamente a
classes ou objetos. Os padres para classes lidam com relacionamentos entre classes e
suas subclasses. Esses relacionamentos so estabelecidos atravs do mecanismo de
herana, assim eles so estticos e fixados em tempo de compilao. Os padres para
objetos lidam com relacionamentos entre objetos que podem ser modificados em tempo
de execuo e so dinmicos. Quase todos utilizam a herana em certa medida. A
maioria dos padres est no escopo de Objeto.
-
34
A Tab. 3.1 mostra a classificao dos padres em relao ao propsito e ao
escopo.
Propsito
Criao Estrutural Comportamental
Classe Mtodo de Fbrica Adaptador Interpretador
Mtodo de Molde
Escopo
Objeto Conjunto Unitrio
Construtor
Fbrica Abstrata
Prottipo
Adaptador
Aproximador
Composto
Decorador
Fachada
Peso Leve
Ponte
Cadeia de Responsabilidade
Comando
Estado
Estratgia
Iterador
Lembrete
Mediador
Observador
Visitante Tabela 3.1 Classificao dos padres GoF [GAM2000].
7 - Utilizando padres
7.1 - O padro Estado
O padro Estado classificado como comportamental de objeto e permite a
um objeto alterar seu comportamento quando o seu estado interno se modifica, fazendo
com que parea que o objeto modificou sua prpria classe [GAM2000].
Pode ser usado quando o comportamento do objeto modifica-se em tempo
de execuo ou em situaes em que o comportamento de um objeto tenha vrias
alternativas ou obedea a vrias condies. Nesse caso, o padro Estado coloca cada
trecho do comando adicional em uma classe separada. Em ambas as situaes os estados
dos objetos so tratados como objetos propriamente ditos.
Seus participantes so:
Contexto: define a interface de interesse para os clientes e mantm uma
instncia de uma subclasse EstadoConcreto que define o estado atual.
-
35
Estado: define uma interface para encapsulamento associado a um
determinado estado do Contexto.
Subclasse EstadoConcreto: cada subclasse realiza um comportamento
associado a um estado do Contexto.
+Requisita()
Contexto
estado --> Monitora()
+Monitora()
interfaceEstado
estado
+Monitora()
EstadoConcretoA
+Monitora()
EstadoConcretoB
Figura 3.2 Viso geral do padro Estado e seus elementos
A Fig. 3.2 ilustra os elementos acima citados e seus relacionamentos.
O Contexto delega solicitaes especficas de estados para o objeto atual
EstadoConcreto. Um contexto pode passar a si prprio como argumento para o objeto
Estado que trata a solicitao. Isso permite ao objeto Estado acessar o Contexto, se
necessrio.
O Contexto define uma interface primria para os clientes. Os clientes
podem configurar um contexto com objetos Estado. Uma vez que o contexto est
configurado, seus clientes no tm que lidar com os objetos Estado diretamente.
Tanto o Contexto quanto as subclasses de EstadoConcreto podem decidir a
mudana de estado e sob quais circunstncias.
O uso do padro estado pode gerar as seguintes conseqncias [GAM2000]:
1) Confinar o comportamento especfico de estados e particionar o
comportamento para estados diferentes. O padro coloca todo o comportamento
-
36
associado a um estado particular em um objeto. Novos estados e transies de estado
podem facilmente ser adicionados pela definio de novas subclasses.
2) Tornar explcitas as transies de estado.
3) Objetos Estado podem ser compartilhados.
O padro Estado focaliza sobre como lidar com um objeto cujo
comportamento depende de seu estado. Seu uso facilita a realizao de problemas
dependentes de estado, com nfase nos seus estados e suas transies de estado.
7.2 - Exemplo: a calculadora
Para ilustrar a aplicao dos benefcios do uso dos padres, mostra-se como
a utilizao do padro Estado pode significativamente melhorar o projeto de uma
calculadora contemplando as operaes de soma, subtrao, multiplicao e diviso (cf.
Fig. 3.3).
Figura 3.3 Janela do aplicativo calculadora.
O diagrama de estados apresentado na Fig. 3.4 explicita as trs principais
atividades da calculadora e suas transies.
-
37
exe() = {acc = acc op val;}
ini() ={acc =0.0; val = 0.0; op = +;}
CalculandoResultado
EscolhendoOperao
DigitandoNmero
?= &{val = digs; exe();}
?s=+|-|*|/&
{val=digs; exe(); op=s;}
?x=0|..|9|,&
{digs=x;}
?= & {exe();}
?s=+|-|*|/&
{val=acc; op=s;}
?x=0|..|9|,&
{digs+=x;}
?s=+|-|*|/&
{op=s;}
acc = 0.0;val = 0.0;op = +;
?= & {exe();}
?x=0|..|9|, & {ini(); digs=x;}
Figura 3.4 Diagrama de estados do aplicativo calculadora.
Resumidamente a calculadora pode estar recebendo, atravs de botes,
comandos para representar dgitos numricos ([0..9]), o ponto (.) para representar a
parte decimal de um nmero, o smbolo de igualdade (=) ou operadores algbricos
(+, -, *, /). Os principais valores controlados pelo programa so: acc
(acumulador), op (operador) e val (ltimo valor digitado).
A calculadora pode assumir trs estados: digitando nmero, escolhendo
operao ou calculando resultado. Quando a calculadora estiver no estado digitando
nmero, ela deve acumular os valores at receber um dgito de operao, causando uma
mudana do seu estado para escolhendo operao. Se novamente a entrada for de
dgitos numricos, ela volta ao estado digitando nmero e espera a prxima entrada. No
-
38
momento em que for pressionado o boto de igualdade, ela passa para o estado
calculando resultado e mostra o resultado obtido da operao escolhida.
Podemos perceber que a partir de cada estado, a calculadora pode
permanecer no mesmo ou mudar para qualquer um dos outros.
Sero apresentadas duas verses da calculadora: com e sem o uso do padro
Estado.
Para todas as duas verses, foi utilizada uma mesma interface com o usurio
chamada GUI (Fig. 3.5) que fornece os componentes e botes para representar
graficamente a calculadora, receber as entradas e mostrar as sadas.
+GUI()
+Msg_Inicial+Separador_Decimal+visor
GUI
Figura 3.5 Representao da classe GUI.
7.3 - Soluo sem o padro Estado
Em uma primeira verso ser mostrada uma soluo sem a aplicao do
padro Estado, baseado em uma arquitetura (cf. Fig. 3.6) onde a mudana de estado
controlada dentro da classe principal.
No momento em que pressionado o boto de igualdade, o programa
executa a operao acc = acc op val, achando o novo valor de acc e mostrando no visor da calculadora o resultado obtido.
-
39
acc = acc op val
Calculadora
valacc op
Controle
Figura 3.6 Estrutura da primeira soluo.
A representao da classe calculadora (Fig. 3.7) mostra que as mudanas de
estado so controladas internamente e so representadas por um atributo da classe que
tem seu valor modificado quando h uma mudana no estado da calculadora.
-
40
actionPerformed(ActionEvent)eval()eval(char)eval(OpBin)
...eval();......eval();...
Calculadoraatual: intacc,val: doubleop: OpBin
ActionListenerGUI
Calculando Resultado = 0Digitando Nmero = 1Escolhendo Operao = 2
Figura 3.7 Representao da classe na primeira soluo.
O grande inconveniente desta representao que o comportamento da
calculadora descrito pelos mtodos eval(), eval(char) e eval(OpBin) no importando o estado em que a calculadora encontra-se. Portanto, h a necessidade de
refazer o cdigo no caso de alguma alterao no projeto.
7.4 - Soluo com o padro Estado
O padro Estado permite uma viso arquitetural da calculadora
significativamente melhor que a soluo anterior. As atividades no estaro mais
dissimuladas no cdigo, mas assumindo um papel explcito na estrutura comportamental
da calculadora da forma como ilustrada na Fig. 3.8.
O padro Estado fornece uma interface chamada de estado que tem a
responsabilidade de instanciar os trs estados possveis para a calculadora (cf. Fig. 3.9).
-
41
acc = acc op val
Calculadora
valacc op
DigitandoNmero
CalculandoResultado
EscolhendoOperao
acc = acc op val
Calculadora
valacc op
DigitandoNmero
CalculandoResultado
EscolhendoOperao
Figura 3.8 Estrutura da segunda soluo.
Nessa nova arquitetura o objeto da classe Calculadora passa a alterar seu
comportamento quando o seu estado interno se modifica. Suas aes dependem agora
do estado atual. Pode-se notar que com este novo projeto, o comportamento da cada
estado de funcionamento da calculadora, fornecido pelos objetos Estado, dissociado
do comportamento da classe Calculadora.
Note que como os estados so classes que realizam a interface Estado, suas
instncias so objetos separados da instncia da classe Calculadora.
-
42
actionPerformed(ActionEvent)
CalculandoResultado
EscolhendoOperacao
DigitandoNumero
Estado
eval()eval(char)eval(OpBin)
...estado[atual].eval();...
Calculadoraestado: Estado[]atual: intacc,val: doubleop: OpBin
ActionListenerGUI
ActionListenerGUI
Figura 3.9 Representao da classe Calculadora e interface Estado.
A modificao do projeto para que a calculadora exiba uma nova
funcionalidade, por exemplo, memorizao, pode ser facilmente estabelecida pelo
acrscimo de um novo tipo de objeto Estado, sem precisar modificar o comportamento
associado aos outros tipos de objetos Estado. Isso melhora o grau de reusabilidade do
projeto, tornando-o mais flexvel e adaptvel a novas funcionalidades.
8 - Concluso
Existem padres de fcil identificao e visualizao que podem ter
imediata aplicao e existem padres que exigem uma maior experincia do projetista.
Um grande nmero de padres est descrito e disponvel para uso de acordo
com a necessidade, a partir de um modelo de problema a ser resolvido e de sua soluo.
Como um exemplo de aplicao de padro, este captulo apresentou o
projeto de uma calculadora simples. Vimos como o padro Estado foi positivamente
aplicado a este caso, capturando o essencial da sua estrutura comportamental.
No prximo captulo, aprofundaremos ainda mais este estudo sobre padres
apresentando um projeto de um sistema que incorpora na sua ntegra o principal intuito
da aplicao de padres que a reusabilidade.
-
Captulo 4
Aplicando Padres de Projeto no Desenvolvimento de Frameworks
1 - Introduo
Este captulo aborda o tema principal dessa dissertao que a utilizao de
padres no desenvolvimento de software orientado a objetos. apresentado um estudo
de caso voltado a construo e a avaliao de expresses matemticas. A aplicao em
si no muito importante neste estudo, mas a utilizao de padres na soluo de
problemas de projeto relacionado diretamente aplicao que, por sua vez, reflete uma
problemtica bastante recorrente em software.
Muito do que se conhece sobre a abordagem orientada a componentes no
desenvolvimento de software refere-se geralmente a modelos arquiteturais de software
j bem definidos. caso, por exemplo, de software para o desenvolvimento de
aplicaes web (servlets e EJB da Sun Microsystems, DCOM da Microsoft, etc.) que
mascaram grande parte das especificidades de suas arquiteturas. O foco do estudo
apresentado neste captulo a utilizao de padres no desenvolvimento de um modelo
de utilizao de componentes ao software. Por isso, nem todos os conceitos associados a
componentes sero verdadeiramente considerados.
O estudo parte com a definio da problemtica na Seo 2; prope uma
primeira soluo utilizando o padro Composto na Seo 3; na Seo 4 apresentado
uma segunda soluo com uso do padro Visitante; a terceira verso da soluo, na
Seo 5, apresenta o padro Mtodo de Fbrica e finalmente a quarta verso, Seo 6,
prope o uso do padro Fbrica Abstrata. A concluso para este captulo encontra-se na
seo 7.
-
44
2 - A problemtica
A avaliao de expresses matemticas exige primeiramente uma
representao adequada das expresses em termos de objetos de software. Para
entendermos este problema, consideraremos inicialmente um conjunto simples de
expresses compreendendo duas operaes, adio e multiplicao, e apenas dois tipos
de nmeros, inteiros e racionais. Mais adiante discutiremos como estender este conjunto
com um nmero maior de operaes e nmeros.
Expresses desse tipo podem ser concretamente escritas na tela de um
computador da seguinte maneira:
5 (E1)
2/3 (E2)
5 * 3 + 4 (E3)
2 + 4/3 (E4)
A expresses E1 e E2 representam apenas valores, embora E2 seja na
realidade uma composio de dois valores inteiros. Na avaliao de uma expresso
matemtica, valores representam expresses terminais, possuem significado prprio,
mas que podem, entretanto ser representado de mais de uma maneira 2/3, 4/6, 8/12, ...,
representam o mesmo nmero racional. Nmeros racionais com numerador maior que o
denominador so habitualmente representados na forma de nmero misto k n/d, onde k
n/d = k + n/d = (k*d + n)/d . Por exemplo, 5/3 pode ser representado como 1 2/3, pois
1*3+2 = 5. Para o nosso caso, a forma de representao no de fato importante.
Entretanto, devemos ter em mente que a proposta que seguiremos neste captulo, o
racional 1/3 diferente de 0,333 ... 33. No importa o grau de preciso que estejamos
trabalhando.
A expresses E3 e E4 por outro lado so composies de operaes sobre
valores e outras expresses e, por isso, precisam ser avaliadas. Representam expresses
no terminais. A avaliao de uma expresso no necessariamente deve fornecer o
mesmo tipo de valor. Por exemplo, a avaliao da expresso E4 = 2 + 4/3 pode resultar
em um inteiro 3, avaliao inteira, em um racional 10/3, avaliao racional, ou em um
-
45
decimal 3,33, avaliao decimal. O primeiro e o terceiro resultado so aproximados,
pois o valor correto da expresso o racional 10/3.
Um outro fato importante sobre a representao de expresses so as
simplificaes sintticas a partir da aplicao de prioridades diferentes s operaes. Por
exemplo, a expresso E3 de fato uma representao ambgua, pois podemos ter duas
interpretaes: (5 * 3) + 4 ou 5 * (3 + 4). considerando que a multiplicao tem
prioridade sobre a soma que podemos resolver essa ambigidade: 5 * 3 + 4 = (5 * 3) + 4
= 19.
Um dos principais problemas a ser resolvido pelo projeto a representao
de expresses em objetos de software. Uma maneira de fazer isso converter as
expresses na sua forma concreta sintaxe concreta na forma de uma rvore sintaxe
abstrata. A representao em rvore de uma expresso considera dois tipos de
elementos: ns e folhas. Ns so elementos compostos de uma ou mais expresses, as
ramificaes do n. o caso, por exemplo, da adio e multiplicao. As folhas so
simplesmente ns sem ramificaes, portanto, representam valores. Assim, a expresso
E3 acima pode ser abstratamente representada como mostra a Fig. 4.1.a. Podemos notar
que a expresso 5 * (3 + 4) possui como esperado uma representao em rvore, Fig.
4.1.b, diferente da expresso E3.
+
35
4*
43
+5
*
(a) 5 * 3 + 4 (b) 5 * (3 + 4)
Figura 4.1 Sintaxe abstrata.
-
46
O processo da avaliao de expresses opera exclusivamente com
expresses representadas na sua forma abstrata. Entretanto, h casos onde o resultado da
avaliao de uma expresso uma outra expresso. Por exemplo, a avaliao da
expresso
d (x^2 + 3 * x + 5) / dx
descrevendo a derivada de x^2 + 3 * x + 5 com relao a x, tem como resultado a
expresso 2*x + 3. Para externar adequadamente o resultado para o usurio, a
problemtica deve tambm envolver o problema da representao concreta de
expresses.
O projeto do software que ser desenvolvido dever prover solues para os
seguintes problemas relacionado representao e avaliao de expresses:
1. Editar expresses;
2. Representar expresses em sintaxe abstrata objetos de software;
3. Fornecer diferentes formas de avaliao de expresses;
4. Representar expresses em sintaxe concreta.
5. Prover um ambiente de interao com o usurio.
O projeto apresentado neste captulo fornece solues apenas para os
problemas 2, 3 e 4. A edio de expresses e a proviso de um ambiente usurio,
considerados problemas ortogonais aos outros trs, so colocados aqui como propostas
de continuao do trabalho de dissertao.
O projeto apresentado na prxima seo contempla principalmente o
problema da representao abstrata das expresses e prope uma arquitetura centrada no
padro Composto. O problema 3 propriamente tratado no projeto apresentado na
Seo 4 utilizando o padro Visitante. A soluo adotada fornece uma estrutura
orientada a componentes para a avaliao de expresses. O problema da representao
de expresses em sintaxe concreta abordado na Seo 6 utilizando o padro Fbrica
Abstrata.
-
47
3 - Solucionando o problema da representao de expresses verso 0.1
Esta seo apresenta uma primeira verso do projeto do avaliador que
basicamente fornece uma soluo ao problema da representao de expresses
utilizando o padro Composto j mencionado no Captulo 3. Para os outros problemas,
esta verso oferece apenas solues temporrias.
O padro Composto colocado como uma soluo geral aos problemas de
composio de objetos hierarquias parte/todo que podem ser estruturados na forma
de uma rvore. Ele permite que clientes possam tratar colees de objetos como objetos
individuais [GAM2000]. Esse tipo de estrutura de composio muito comum em
software. Um exemplo tpico o modelo arquivo-diretrio utilizado pelos sistemas
operacionais (cf. Fig. 4.2).
Arquivo
Arquivo texto(*.txt)
Arquivo documento(*.doc) Diretrio
*
Figura 4.2 O modelo arquivo-diretrio
Neste modelo, a estrutura mais simples o arquivo genrico, que pode ter
novas reclassificaes, a medida em que precisamos de arquivos especializados. Um
arquivo pode ser do tipo texto simples, pode ser um documento ou pode ainda ser um
tipo especial de arquivo, chamado diretrio, que por sua vez uma composio de
arquivos.
-
48
Esse exemplo caracteriza a natureza recursiva da estrutura de rvore. E
justamente essa caracterstica que o padro Composto explora.
Essa a estrutura de composio exibida pelas expresses. Uma expresso
compe-se de outras expresses que, por sua vez, tambm compem-se de outras
expresses e assim por diante. A Fig. 4.3 apresenta um esboo dessa arquitetura de
composio aplicada ao caso das expresses.
interfaceExp
Num Soma ProdutoRacional
2
int
2
Figura 4.3 Modelo de composio de expresses
A interface Exp utilizada para generalizar a composio recursiva dos elementos envolvidos na expresso. Assim, nmeros inteiros (Num), nmeros racionais (Racional), adies (Soma) ou multiplicao (Produto) so modeladas como simples realizaes da interface Exp. Notemos que objetos Soma e Produto possuem dois atributos para objetos Exp quaisquer. Por exemplo, a expresso 5 * 3 + 4 representada pelo seguinte objeto Exp:
Exp e1 = new Soma(
-
49
new Produto( new Num(5), new Num(3) ), new Num(4) )
O cliente, elemento que manipula os objetos na composio atravs da
interface Exp, usa a interface da classe para interagir com os objetos na estrutura composta. Se o receptor um objeto Num ou Racional, ento a solicitao tratada diretamente. Se o receptor um objeto Soma ou Produto, ento parte da computao envolvida delegada aos seus componentes-filhos.
Como conseqncia do uso deste padro percebemos a definio das
hierarquias de classe que consistem de objetos primitivos e de objetos compostos. Os
objetos primitivos podem compor objetos mais complexos, os quais, por sua vez,
tambm podem compor outros objetos, e assim por diante, recursivamente. O cdigo do
cliente pode aceitar um objeto primitivo ou um objeto composto.
O comportamento do cliente torna-se simples mesmo em face de estruturas
composicionais complexas. Isso simplifica o cdigo da classe cliente e evita o uso de
comandos case que utilizam os rtulos das classes que definem a composio
[GAM2000].
Essa arquitetura torna mais fcil o acrscimo de novos tipo de componentes
s expresses que o avaliador pode tratar. Os clientes no precisam ser modificados para
tratar novas classes do tipo Exp.
-
50
+Object eval()+String infix()+boolean prec(in Soma E)+boolean prec(in Produto E)
interfaceExp
+Num(in int n)+Objetct eval()+String infix()+boolean prec(in Soma E)+boolean prec(in Produto E)+int val()+String toString()
-int valNum
+Soma(in Exp E1, in Exp E2)+Object eval()+String infix()+boolean prec(in Soma E)+boolean prec(in Produto E)+String toString()+Exp exp1()+Exp exp2()