UNIVERSIDADE DE SO PAULO

INSTITUTO DE CINCIAS MATEMTICAS E DE COMPUTAO

Introduo aos Padres de Software

Rosana Teresinha Vaccare Braga Ferno Stella Rodrigues Germano Paulo Cesar Masiero Jos Carlos Maldonado

So Carlos 2001

Padres de Software
SUMRIO
1 INTRODUO .......................................................................................................................................... 1 2 CONCEITOS & TERMINOLOGIA BSICOS...................................................................................... 3 2.1 ORIENTAO A OBJETOS........................................................................................................................ 3 2.1.1 Introduo ...................................................................................................................................... 3 2.1.2 Classes e instncias ........................................................................................................................ 4 2.1.3 Atributos e Mtodos........................................................................................................................ 5 2.1.4 Generalizao, especializao e Agregao .................................................................................. 6 2.1.5 Classes Abstratas X Classes Concretas.......................................................................................... 7 2.1.6 - Herana........................................................................................................................................... 8 2.1.7 Encapsulamento e Mensagens........................................................................................................ 8 2.1.8 Polimorfismo .................................................................................................................................. 9 2.1.9 Mtodos de Anlise e Projeto OO ............................................................................................... 10 2.2 REUSO .................................................................................................................................................. 10 2.2.1 Bibliotecas de classes ................................................................................................................... 11 2.2.2 Frameworks.................................................................................................................................. 12 2.2.3 Geradores de Aplicao e Toolkits............................................................................................... 12 3. PADRES................................................................................................................................................... 13 3.1 COMPONENTES DE UM PADRO ............................................................................................................ 14 3.2 ANTI-PADRES ..................................................................................................................................... 16 3.3 COMPARAO ENTRE PADRES E OUTRAS FORMAS DE REUSO ............................................................. 16 4 CLASSIFICAO DE PADRES ........................................................................................................ 18 5 COLETNEAS DE PADRES .............................................................................................................. 19 5.1 INTRODUO........................................................................................................................................ 19 5.2 CONCEITOS & TERMINOLOGIA ............................................................................................................. 20 5.2.1 Colees de padres..................................................................................................................... 20 5.2.2 Catlogos de padres ................................................................................................................... 20 5.2.3 Sistemas de padres...................................................................................................................... 20 5.2.4 Linguagens de padres................................................................................................................. 21 5.3 SNTESE DE TRABALHOS AFINS ............................................................................................................. 22 5.4 EXEMPLOS............................................................................................................................................ 24 5.4.1 Colees de padres..................................................................................................................... 24 5.4.2 Catlogos de padres ................................................................................................................... 25 5.4.3 Sistemas de padres...................................................................................................................... 27 5.4.4 Linguagem de padres.................................................................................................................. 29 6 ESCRITA E USO DE PADRES........................................................................................................... 33 6.1 REGRAS PARA DERIVAO DE NOVOS PADRES ................................................................................... 33 6.2 DESENVOLVIMENTO DE SISTEMAS USANDO PADRES .......................................................................... 33 6.3 EXERCCIOS .......................................................................................................................................... 34 7 CONCLUSES ........................................................................................................................................ 35 REFERNCIAS: ............................................................................................................................................ 35

ANEXO: NOTAO UML (UNIFIED MODELING LANGUAGE)....................................................... 39 A1 BREVE HISTRICO ................................................................................................................................ 39 A2 NOTAO ............................................................................................................................................. 40 A2.1 Diagramas de Caso de Uso (Use Cases).................................................................................. 43 A2.2 Diagramas de Classes.................................................................................................................. 44

ndice de Figuras
Figura 1 Abordagem da Orientao a Objetos ................................................................................................ 3 Figura 2 Classe e Objetos ................................................................................................................................ 5 Figura 3 Atributos e Mtodos.......................................................................................................................... 6 Figura 4 Generalizao/Especializao ........................................................................................................... 7 Figura 5 Agregao ......................................................................................................................................... 7 Figura 6 Classes Abstratas e concretas............................................................................................................ 8 Figura 7 Relacionamento entre padres [Gamma 95] ................................................................................... 27 Figura 8 Estrutura da Linguagem de Padres apresentada graficamente ...................................................... 30 Figura 16 Exemplo de elementos genricos .................................................................................................. 42 Figura 17 Representao grfica de alguns elementos de modelagem da UML ........................................... 43 Figura 18 Exemplo de package ..................................................................................................................... 43 Figura 19 - Exemplo de Um Diagrama de Caso de Uso................................................................................... 44 Figura 20 - Representao de uma Classe. ....................................................................................................... 45 Figura 21 - Exemplo de Type (Tipo). ............................................................................................................... 46 Figura 22 - Exemplo de Associao. ................................................................................................................ 46 Figura 23 - Exemplo de Associao do tipo or. ............................................................................................ 46 Figura 24- Exemplo de relacionamentos de composio e agregao.............................................................. 46 Figura 25- Exemplo de relacionamentos de Generalizao.............................................................................. 47 Figura 26 - Exemplo de relacionamentos de Dependncia............................................................................... 47

ndice de Tabelas
Tabela 1 Coleo de Padres [Vlissides 96].................................................................................................. 24 Tabela 2 Catlogo de Padres [Gamma 95] .................................................................................................. 26 Tabela 3 Sistema de Padres [Buschmann 96].............................................................................................. 29 Tabela 4 Padres da Linguagem e propsitos ............................................................................................... 31

1 Introduo
O reuso de software um tema da engenharia de software que tem recebido destaque especial nas ltimas dcadas. O objetivo reaproveitar grande parte do software produzido e informaes associadas em projetos futuros, diminuindo o custo e aumentando a produtividade no desenvolvimento e na prpria evoluo do produto. A idia bsica de que componentes de software sejam projetados e implementados de forma que possam ser reusados em muitos sistemas diferentes. Na dcada de 60, construam-se bibliotecas de sub-rotinas cientficas que eram reusveis em aplicaes cientficas e de reengenharia, sendo portanto de um domnio de aplicao limitado. Geradores de aplicao ou geradores de programa surgiram logo depois para facilitar a criao de aplicaes a partir de sua especificao em uma linguagem de alto nvel. Apesar dos geradores de aplicao limitarem-se a poucos domnios, eles representam a preocupao com o reuso nos diferentes nveis do processo de desenvolvimento de software. Eles foram pioneiros em propiciar o reuso de anlise, mais especificamente atravs da anlise de domnios. A abordagem de desenvolvimento de software orientado a objetos traz consigo grande motivao e nfase no reuso de software. Nessa perspectiva, padres de software tm sido pesquisados na ltima dcada como uma forma promissora de reuso, no somente de cdigo mas tambm de projeto, anlise, arquitetura e processo de desenvolvimento. Por intermdio dos padres podem ser documentadas solues para diferentes tipos de problemas que ocorrem ao longo do processo de desenvolvimento de software. Essas solues, quaisquer que sejam seus nveis de abstrao, podem ser reusadas por outros desenvolvedores ao confrontarem-se com problemas similares. Diversos padres tm sido propostos, seja para solucionar problemas de programao [Coplien 92], de projeto [Gamma 95, Pree 95] e de anlise [Coad 92, Coad 95, Fowler 97], entre outros. Conferncias internacionais para apresentao e discusso de novos padres assim como linguagens de padres tm ocorrido desde 1994. Uma srie de livros rene os melhores artigos apresentados nessas conferncias [Coplien 95, Vlissides 96, Martin 98], nos quais podem ser encontrados padres das mais variadas classes. Padres de padro tm sido propostos sugerindo os componentes bsicos e opcionais que podem compor um padro [Gamma 95, Appleton 97, Buschmann 96].
1

Estas notas didticas destinam-se a dar uma viso atual sobre padres de software, discutindo em detalhes as diversas classes de padres, bem como exemplificando seu uso em casos reais. As notas didticas esto organizadas da seguinte forma. No Captulo 2 so apresentados os conceitos e terminologia necessrios para o entendimento dos demais captulos. No Captulo 3 so apresentadas as definies de padres, seus diversos componentes e feita uma comparao entre padres e outras formas de reuso. No Captulo 4 mostra-se a classificao de padres de acordo com seu nvel de abstrao. No Captulo 5 discutem-se as diversas formas de agrupamento de padres em conjuntos, que so: catlogos de padres, sistemas de padres e linguagens de padres. No Captulo 6 so fornecidas diretrizes para escrita e uso de padres. No Captulo 7 so apresentadas as concluses e sintetizados os principais questionamentos e desdobramento de pesquisas na rea. No apndice A dado um breve histrico e um resumo da notao UML, utilizada para representao dos padres no decorrer das notas didticas.

2 Conceitos & Terminologia bsicos

Neste captulo estabelecem-se conceitos importantes para o estudo de padres de software, bem como a terminologia bsica utilizada ao longo do trabalho.

2.1 Orientao a Objetos

2.1.1 Introduo O paradigma da orientao a objetos, assim como outras abordagens, surgiu na tentativa de solucionar problemas existentes no desenvolvimento de software, principalmente com relao a custos e confiabilidade. Assim, o objetivo principal da orientao a objetos diminuir o custo de desenvolvimento e manuteno e aumentar a confiabilidade dos produtos de software produzidos. Todo software representa um modelo de um problema do mundo real [Turine 98]. O mundo real possui um espao de problemas, formado por objetos que interagem. O modelo de software correspondente a esse problema representado por um espao de solues. A orientao a objetos tenta diminuir o Gap Semntico existente entre o espao de problemas e o espao de solues, por meio de um mapeamento dos objetos pertencentes ao espao de problemas para o espao de solues, de tal maneira que operaes sobre essas representaes abstratas correspondam a operaes do mundo real (Figura 1).

Mundo Real

Gap Semntico

Mundo Computacional

ESPAO DE PROBLEMAS Mapeamento

ESPAO DE SOLUES

Figura 1 Abordagem da Orientao a Objetos

A representao de objetos em um software mais natural do que a representao de sua funcionalidade, que tende a sofrer constantes mudanas. Representar a funcionalidade do sistema a base do paradigma de orientao a procedimentos enquanto representar os objetos do sistema a base do paradigma da orientao a objetos. Uma das grandes vantagens da orientao a objetos de que nela o espao de solues est mais prximo (conceitualmente) do espao de problemas. Assim, mais fcil desenvolver a aplicao e assegurar sua compreenso, confiabilidade e manuteno. A compreenso dos conceitos e o rigor no desenvolvimento persistem como questes fundamentais nesse contexto. A programao orientada a objetos foi discutida pela primeira vez no final da dcada de 60 por aqueles que trabalhavam na linguagem Simula. Nos anos 1970 foi desenvolvida na Xerox PARC uma parte importante da linguagem Smalltalk [Coad 91], que combina a noo de classes da linguagem Simula com grande parte da essncia de abstrao funcional da linguagem LISP, embora sejam linguagens bastante diferentes [Graham 94]. A programao orientada a objetos levou alguns anos para amadurecer. O interesse cada vez maior pelo desenvolvimento de interfaces com o usurio e as pesquisas relacionando a orientao a objetos inteligncia artificial, computao concorrente e ao gerenciamento de banco de dados motivaram o aperfeioamento das linguagens orientadas a objeto. Isso levou necessidade de desenvolver mtodos para anlise e projeto orientado a objetos, que comearam a surgir no final da dcada de 80. Dentre esses mtodos, destacam-se os abordados em [Masiero 98], mais especialmente o mtodo Fusion [Coleman 94], que se props a ser uma fuso de alguns dos ento existentes e a UML [Eriksson 98], que almeja constituir uma notao unificada para todos os mtodos da orientao a objetos. 2.1.2 Classes e instncias A categorizao dos objetos em grupos e/ou classes, baseada em propriedades comuns, um dos princpios mais importantes do paradigma orientado a objetos; por exemplo, os objetos "Fiat Uno Placa: AAA-4444 Cor: Prata" e "Volkswagen Gol Placa: FFF-3333 Cor: Vinho" fazem parte da classe "Automveis" e possuem propriedades comuns, tais como marca, modelo, placa, cor etc. Nesse caso, consideramos que "Fiat Uno

Placa: AAA-4444 Cor: Prata" e "Volkswagen Gol Placa: FFF-3333 Cor: Vinho" so instncias, ou objetos, da classe "Automvel" (Figura 2).

Fiat /Uno AAA-4444 Prata

Automvel Marca/Modelo Placa Cor

Volkswagen/Gol FFF-3333 Vinho

Ford /Verona LLL-1111 Branco

Objetos
Figura 2 Classe e Objetos

Classe

2.1.3 Atributos e Mtodos Os atributos so as propriedades da classe comuns a todos seus objetos ou instncias. Em geral, os atributos so de uso exclusivo de cada classe, no podendo haver acesso a eles por objetos de outras classes; por exemplo, a classe Automvel possui atributos Marca, Modelo, Placa e Cor. Os mtodos so procedimentos que atuam sobre um objeto ou sobre uma classe de objetos. Eles descrevem uma seqncia de aes a ser executada por um objeto, podendo fazer consultas ou alteraes nos atributos desse objeto ou criar novos objetos. Atravs dos mtodos especifica-se a um objeto COMO FAZER alguma coisa. Os mtodos so intrnsecos s classes e no podem ser separados; por exemplo, a classe Automvel possui mtodos Registrar, Eliminar, AlterarPlaca, etc. (Figura 3).

Atributos

Mtodos

Automvel Marca/Modelo Placa Cor Registrar Eliminar AlterarPlaca

Figura 3 Atributos e Mtodos

2.1.4 Generalizao, especializao e Agregao Os conceitos de generalizao e especializao so decorrentes do conceito de classes: a partir de duas classes pode-se abstrair uma classe mais genrica. As subclasses satisfazem todas as propriedades das classes de que elas constituem especializaes. Deve existir pelo menos uma propriedade que diferencie duas classes especializadas; por exemplo, a partir de duas classes Automvel e Caminho pode-se criar a generalizao Veculo, que possui todos os atributos comuns entre as especializaes Automvel e Caminho (Figura 4). Nesse caso, diz-se que Veculo a superclasse (generalizao) e que Automvel e Caminho so subclasses (especializaes). A agregao ou decomposio consiste na composio de uma nova classe como um agregado de classes preexistentes. frequentemente referida por relacionamento todoparte, no qual o agregado (todo) composto de partes [Cook 94]; por exemplo, na Figura 5 a classe Diviso agregada classe Companhia, o que significa que cada diviso parte de uma nica companhia. A companhia formada por suas divises e se a companhia for destruda, assim o sero suas divises. A notao utilizada na Figura 5 a UML [Eriksson 98], resumida no apndice A.

Superclasse

Veculo
Marca/modelo Placa Cor

Subclasse Automvel
Capacidade de passageiros

GENERALIZAO
ESPECIALIZAO

Caminho
Capacidade de carga

( herana )

Figura 4 Generalizao/Especializao Companhia Diviso

Figura 5 Agregao

2.1.5 Classes Abstratas X Classes Concretas Uma classe abstrata uma classe que nunca possui instncias. Apenas suas subclasses podem possuir instncias. Em geral, a raiz de uma hierarquia de classes abstrata, enquanto as folhas so classes concretas. As classes abstratas definem seus mtodos em termos de outros mtodos indefinidos que precisam ser implementados por suas subclasses concretas; por exemplo, a classe Coleo define mtodos como Selecione, Recupere, Inclua, etc. em termos de um mtodo de iterao Faa. Suas subclasses Matriz, Conjunto e Dicionrio definem o mtodo Faa e assim podem usar os mtodos herdados de Coleo (Figura 6). Nesse caso, o mtodo Faa reescrito em cada uma das subclasses concretas, enquanto os mtodos Selecione, Recupere e Inclua so mtodos definidos apenas na classe abstrata e herdados pelas subclasses. Nada impede que uma das classes especialize um dos mtodos da classe. A classe Coleo nunca possui instncias: as instncias so sempre de umas das subclasses concretas Matriz, Conjunto ou Dicionrio.

Coleo

Classe abstrata

Selecione Recupere Inclua Faa

Classes concretas

Matriz Faa

Conjunto Faa

Dicionrio Selecione Faa

Figura 6 Classes Abstratas e concretas

2.1.6 - Herana A herana um mecanismo que permite definir uma nova classe (subclasse) a partir de uma classe j existente (superclasse). Ao se estabelecer uma Especializao (subclasse) de uma classe, a subclasse herda as caractersticas comuns da superclasse, isto , os atributos e mtodos da superclasse passam a fazer parte da especificao dos atributos e dos mtodos da subclasse. A subclasse pode adicionar novos mtodos, como tambm reescrever mtodos herdados (em ingls, override). Na Figura 6, as subclasses Matriz, Conjunto e Dicionrio herdam os mtodos Selecione, Recupere e Inclua da superclasse Coleo e reescrevem o mtodo Faa. A classe Dicionrio reescreve tambm o mtodo Selecione. 2.1.7 Encapsulamento e Mensagens Na orientao a objetos, as estruturas de dados ou atributos das classes ficam encapsuladas, ou seja, s podem ser manipuladas pelos prprios mtodos da classe. O objeto possui uma parte privada (Viso Interna) e uma parte compartilhada (Viso Externa ou Interface). O encapsulamento restringe a visibilidade do objeto mas facilita o reuso, pois

os atributos e os mtodos so empacotados sob um nome e podem ser reusados como uma especificao ou componente de programa. A passagem de mensagens o mecanismo atravs do qual os objetos se comunicam, invocando as operaes desejadas. As operaes ou mtodos que podem ser invocados por outras classes fazem parte da interface ou viso externa da classe. A interface especifica quais operaes sobre os objetos da classe podem ser realizadas, mas no como a operao ser executada. 2.1.8 Polimorfismo Ao receber uma mensagem para efetuar uma operao, o objeto quem determina como a operao deve ser efetuada, pois ele tem comportamento prprio. Como a responsabilidade do receptor e no do emissor, pode acontecer que uma mesma mensagem ative mtodos diferentes, dependendo da classe de objetos para onde enviada a mensagem. Esse mecanismo chamado de polimorfismo e possvel graas ao recurso de ligao dinmica (em ingls, dynamic binding). Por meio do polimorfismo, possvel criar vrias classes com interfaces idnticas, porm com objetos e implementaes diferentes. Assim, uma mensagem pode ser executada de acordo com as caractersticas do objeto que est recebendo o pedido de execuo do servio; por exemplo, o operador + um exemplo clssico do polimorfismo mesmo nas linguagens mais antigas: ele usado tanto com parmetros numricos quanto com parmetros do tipo caracter ou outros. Outro exemplo de polimorfismo uma lista genrica que pode conter elementos de qualquer tipo (como inteiros, strings, arrays, etc.). Na interface da lista h mtodos para manipulao de todos os seus possveis tipos de elementos. O nome dos mtodos sempre o mesmo para uma mesma operao e o polimorfismo permite que o mtodo correto seja executado de acordo com o tipo de parmetro passado.

2.1.9 Mtodos de Anlise e Projeto OO Alm da programao orientada a objetos, difundida no incio da dcada de 80 pelo surgimento de linguagens como Smalltalk e Ada, diversos mtodos de anlise e projeto orientado a objetos tm sido propostos nos ltimos anos, entre eles:

CRC (Class Responsability Collaborator, Beecke e Cunningham, 1989) OOA (Object Oriented Analysis, Coad e Yourdon, 1990) Booch (Booch, 1991) OMT (Object Modeling Technique, Rumbaugh, 1991) Objectory (Jacobson, 1992) Fusion (Coleman e outros, 1994)

O objetivo desses mtodos tornar a anlise compatvel com a codificao do software, o que no seria efetivo se mtodos baseados em outros paradigmas fossem aplicados. Em 1997 diversos autores, preocupados com a grande quantidade de notaes diferentes para representao de software orientado a objetos, propuseram uma notao universal, chamada UML (Unified Modeling Language) [Eriksson 97]. Essa notao, resumida no Apndice, ser utilizada no decorrer deste trabalho para representar os diversos diagramas relativos aos padres.

2.2 Reuso
O reuso uma atividade que se destina a identificar software reutilizvel, envolvendo tambm a correta importao, reconfigurao e adaptao desse software para uma nova aplicao. A grande motivao para o reuso a necessidade de aumento de produtividade, manutenibilidade e qualidade tanto do software quanto de seu processo de desenvolvimento. O ganho na produtividade se deve ao fato de que o reuso reduz a quantidade de cdigo a ser programada, testada e documentada, diminuindo tambm o custo do produto. A manutenibilidade melhorada pois o entendimento do sistema como um todo fica mais fcil, j que componentes projetados para reuso tambm tm funo bem
10

definida e os programadores encontram-se mais familiarizados com os blocos reutilizados. A qualidade de um software projetado para reuso em geral maior do que a de um software desenvolvido normalmente, pois em geral h um investimento maior no projeto, documentao e testes. Componentes reusveis devem ser catalogados para que possam ser facilmente consultados, padronizados para facilitar a aplicao e validados para que sua integrao seja fcil [Pressman 95]. O processo de identificao do componente a ser reutilizado chamado de recuperao de informao. A falta de componentes reusveis, a dificuldade para encontrar um componente e modific-lo so os grandes entraves ao reuso. Alm disso, o custo para construo desses componentes maior, pois necessrio investir mais no planejamento, documentao e testes. Outro problema que desmotiva o reuso a ineficincia dos componentes, que ocorre quando tenta-se fazer componentes mais genricos para servir a uma gama maior de reutilizadores. Nesses casos, muitos desenvolvedores preferem desenvolver seu prprio componente, para que o desempenho seja mximo. O sucesso da implantao do reuso depende de trs fatores bsicos: atitude, ferramentas e tcnicas [Johnson 88]. A atitude que deve ser tomada envolve a conscientizao da equipe da necessidade de reuso. Muitas vezes, por comodidade ou por receio de utilizar programas alheios, prefere-se desenvolver um componente novamente. Essa uma atitude que deveria ser ponderada nas empresas. Ferramentas de auxlio ao reuso so fundamentais: elas auxiliam na busca, armazenagem e recuperao dos componentes. Tcnicas para reuso tambm so necessrias para seu sucesso: regras para projeto e codificao de componentes reusveis aumentam a facilidade de entendimento e conseqentemente o reuso de um componente. 2.2.1 Bibliotecas de classes Com a efetivao do paradigma da orientao a objetos o reuso passou a ser no somente de cdigo mas passou a abranger as estruturas de dados. Bibliotecas de classes passaram a ser criadas para resolver problemas das mais diversas reas: sistemas operacionais, computao grfica, interfaces, banco de dados, etc. A modularidade e ocultamento de informao oferecidos pelas classes facilitam extremamente o reuso. Alm
11

disso, a herana faz com que a classe possa ser reusada criando-se as especializaes desejadas e o polimorfismo faz com que os mtodos funcionem para uma variedade maior de argumentos. A disponibilizao de bibliotecas de classes aos desenvolvedores permite que eles usem a herana a fim de particularizar as classes abstratas de acordo com o caso especfico. Por exemplo, em Smalltalk existe uma biblioteca de classes para tratar de colees, que permitem a manipulao de colees de objetos tais como matrizes, dicionrios, conjuntos, etc. Cada componente dessa biblioteca pode ser usado como parte da soluo para um problema maior [Johnson 88]. 2.2.2 Frameworks Aps a popularizao da linguagem Smalltalk, no incio da dcada de 80, paralelamente s bibliotecas de classes, comearam a ser construdos frameworks de aplicao, que acrescentam s bibliotecas de classes os relacionamentos e interao entre as diversas classes que compem o framework. Com os frameworks, reutilizam-se no somente as linhas de cdigo, como tambm o projeto abstrato envolvendo o domnio de aplicao. Framework definido por Coad como um esqueleto de classes, objetos e relacionamentos agrupados para construir aplicaes especficas [Coad 92] e por Johnson como um conjunto de classes abstratas e concretas que prov uma infra-estrutura genrica de solues para um conjunto de problemas [Johnson 88]. Essas classes podem fazer parte de uma biblioteca de classes ou podem ser especficas da aplicao. Frameworks possibilitam reutilizar no s componentes isolados, como tambm toda a arquitetura de um domnio especfico. O Captulo 15 explica em detalhes os conceitos associados a frameworks, exemplificando diversos deles. 2.2.3 Geradores de Aplicao e Toolkits Geradores de aplicao so ferramentas de apoio por computador ao desenvolvimento de software. Alm de reduzir os custos e aumentar a produtividade, eles ajudam a melhorar a qualidade dos sistemas produzidos. Essencialmente, um gerador de aplicao um utilitrio que, a partir de uma especificao de alto nvel de um problema
12

implementvel, transforma automaticamente essa especificao na implementao do problema [Meira 91, Masiero 93]. No contexto de orientao a objetos e frameworks, toolkits so ambientes de construo de aplicaes orientadas a objetos, sendo constitudos por ferramentas de alto nvel que permitem aos usurios interagirem com um framework de aplicao para configurar e construir novas aplicaes [Johnson 88].

3. Padres
A origem dos padres de projeto deu-se com o trabalho feito pelo arquiteto Christopher Alexander no final dos anos 70. Ele escreveu dois livros: A Pattern Language [Alexander 77] e A Timeless Way of Building [Alexander 79] que, alm de exemplificarem, descrevem seu mtodo para documentao de padres. O trabalho de Alexander, apesar de ser voltado para a arquitetura, possui uma fundamentao bsica que pode ser abstrada para a rea de software. Os padres permaneceram esquecidos por um tempo, at que ressurgiram na conferncia sobre programao orientada a objetos (OOPSLA) de 1987, mais especificamente, no Workshop sobre Especificao e Projeto para Programao Orientada a Objetos [Beck 87]. Nesse trabalho, Beck e Cunningham falam sobre uma linguagem de padres para projetar janelas em Smalltalk. A partir de ento, muitos artigos, revistas e livros tm aparecido abordando padres de software, que descrevem solues para problemas que ocorrem freqentemente no desenvolvimento de software e que podem ser reusadas por outros desenvolvedores. Um dos primeiros trabalhos estabelecendo padres foi o de Coad [Coad 92], no qual so descritos sete padres de anlise. Nesse mesmo ano Coplien publicou um livro definindo inmeros idiomas, que so padres de programao especficos para a linguagem C++. Em 1993, Gamma e outros introduzem os primeiros de seus vinte e trs padres de projeto [Gamma 93], que seriam publicados em 1995 [Gamma 95]. Esses foram os trabalhos pioneiros na rea de padres, seguidos por muitos outros nos anos seguintes. Um padro descreve uma soluo para um problema que ocorre com freqncia durante o desenvolvimento de software, podendo ser considerado como um par problema/soluo [Buschmann 96]. Projetistas familiarizados com certos padres podem
13

aplic-los imediatamente a problemas de projeto, sem ter que redescobri-los [Gamma 95]. Um padro um conjunto de informaes instrutivas que possui um nome e que capta a estrutura essencial e o raciocnio de uma famlia de solues comprovadamente bem sucedidas para um problema repetido que ocorre sob um determinado contexto e um conjunto de repercusses [Appleton 97]. Padres de software podem se referir a diferentes nveis de abstrao no desenvolvimento de sistemas orientados a objetos. Assim, existem padres arquiteturais, em que o nvel de abstrao bastante alto, padres de anlise, padres de projeto, padres de cdigo, entre outros. As diversas categorias de padres so discutidas no Captulo 3. O uso de padres proporciona um vocabulrio comum para a comunicao entre projetistas, criando abstraes num nvel superior ao de classes e garantindo uniformidade na estrutura do software [Gall 96]. Alm disto, eles atuam como blocos construtivos a partir dos quais projetos mais complexos podem ser construdos [Gamma 95].

3.1 Componentes de um padro

Apesar de existirem diversos padres de padro, que so detalhados no Captulo 11, padres tm sido descritos em diferentes formatos. Porm, existem componentes essenciais que devem ser claramente identificveis ao se ler um padro [Appleton 97]:

Name: Todo padro deve ter um nome significativo. Pode ser uma nica palavra
ou frase curta que se refira ao padro e ao conhecimento ou estrutura descritos por ele. Se o padro possuir mais do que um nome comumente usado ou reconhecvel na literatura, subsees Aliases ou Also know as devem ser criadas.

Problem: Estabelece o problema a ser resolvido pelo padro, descreve a

inteno e objetivos do padro perante o contexto e foras especficas.

Context: Pr-condies dentro das quais o problema e sua soluo costumam

ocorrer e para as quais a soluo desejvel, o que reflete a aplicabilidade do padro. Pode tambm ser considerado como a configurao inicial do sistema antes da aplicao do padro.

14

Forces: Descrio dos impactos, influncias e restries relevantes para o

problema e de como eles interagem ou so conflitantes entre si e com os objetivos a alcanar. Um cenrio concreto que serve como motivao para o padro.

Solution: Relacionamentos estticos e regras dinmicas descrevendo como

obter o resultado desejado. Equivale a dar instrues que descrevem como o problema resolvido, podendo para isso utilizar texto, diagramas e figuras. So possveis as seguintes subsees: Structure, revelando a forma e organizao esttica do padro; Participants, descrevendo cada um desses componentes; Dynamics, exibindo o comportamento dinmico do padro. Implementation, mostrando detalhes de implementao do padro; e Variants, discutindo possveis variaes e especializaes da soluo.

Examples: Uma ou mais aplicaes do padro que ilustram, num contexto

inicial especfico, como o padro aplicado e transforma aquele contexto em um contexto final.

Resulting context: O estado ou configurao do sistema aps a aplicao do

padro, podendo ter uma subseo Conseqncias (tanto boas quanto ruins). Descreve as ps-condies e efeitos colaterais do padro.

Rationale: Uma explicao das regras ou passos do padro que explicam como
e porque ele trata suas influncias contrrias, definidas em 'Forces', para alcanar os objetivos, princpios e filosofia propostos. Isso nos diz realmente como o padro funciona, porque funciona e porque ele bom.

Related Patterns: Os relacionamentos estticos e dinmicos desse padro com

outros dentro da mesma linguagem ou sistema de padres. Padres relacionados geralmente compartilham as mesmas influncias. So possveis os seguintes tipos de padres relacionados: padres predecessores, cuja aplicao conduza a esse padro; padres sucessores, que devem ser aplicados aps esse; padres alternativos, que descrevem uma soluo diferente para o mesmo problema mas diante de influncias e restries diferentes; e
15

padres

codependentes,

que

podem

(ou

devem)

ser

aplicados

simultaneamente com esse padro.

Known Uses: Descreve ocorrncias conhecidas do padro e sua aplicao em

sistemas existentes. Isso ajuda a validar o padro, verificando se ele realmente uma soluo provada para um problema recorrente.

3.2 Anti-padres
Anti-padres representam uma lio aprendida, ao contrrio dos padres, que representam a melhor prtica [Appleton 97]. Os anti-padres podem ser de dois tipos: Aqueles que descrevem uma soluo ruim para um problema que resultou em uma situao ruim Aqueles que descrevem como escapar de uma situao ruim e como proceder para, a partir dela, atingir uma boa soluo. Os anti-padres so necessrios porque to importante ver e entender solues ruims como solues boas. Se por um lado til mostrar a presena de certos padres em sistemas mal sucedidos, por outro lado til mostrar a ausncia dos anti-padres em sistemas bem sucedidos. Segundo uma outra definio [CMG 98] um anti-padro : um padro que diz como ir de um problema para uma soluo ruim ou um padro que diz como ir de uma soluo ruim para um soluo boa.

A primeira parece intil, exceto se considerarmos o padro como uma mensagem No faa isso. O segundo definitivamente um padro positivo, no qual o problema a soluo ruim.

3.3 Comparao entre padres e outras formas de reuso

Fazendo uma comparao entre padres e frameworks, Johnson [Johnson 97] diz que padres so mais abstratos do que frameworks, porque um framework um software executvel, enquanto um padro representa conhecimento e experincia sobre software
16

(pode-se dizer que frameworks tm natureza fsica enquanto que padres tm natureza lgica). Os padres so menores do que frameworks. Em geral padres so compostos por 2 ou 3 classes, enquanto os frameworks envolvem um nmero bem maior de classes, podendo englobar diversos padres. Os padres so menos especializados do que frameworks, j que os frameworks geralmente so desenvolvidos para um domnio de aplicao especfico e os padres (ou muitos deles) podem ser usados em diversos tipos de aplicao. Apesar de haver padres mais especializados, eles no so capazes de ditar a arquitetura de uma aplicao, ao contrrio dos frameworks.

17

4 Classificao de Padres
Conforme mencionado no Captulo 1, padres de software abrangem diferentes nveis de abstrao, podendo portanto ser classificados em diversas categorias de modo a facilitar sua recuperao e uso. Porm, essa classificao no rigorosa, podendo haver padres que se encaixem em mais do que uma categoria. A seguir resumem-se algumas categorias importantes de padres, que so detalhadas posteriormente nos Captulos 4 a 13. Outras categorias de padres so discutidas em [Coplien 95, Vlissides 96, Martin98].

Padres de processo: definem solues para os problemas encontrados nos

processos envolvidos na engenharia de software: desenvolvimento, controle de configurao, testes, etc.

Padres arquiteturais: expressam o esquema ou organizao estrutural

fundamental de sistemas de software ou hardware.

Padres de padro (em ingls, patterns on patterns): so padres descrevendo

como um padro deve ser escrito, ou seja, que padronizam a forma com que os padres so apresentados aos seus usurios.

Padres de anlise: descrevem solues para problemas de anlise de sistemas,

embutindo conhecimento sobre o domnio de aplicao especfico.

Padres de projeto: definem solues para problemas de projeto de software. Padres de interface: definem solues para problemas comuns no projeto da
interface de sistemas. um caso particular dos padres de projeto.

Padres de programao: descrevem solues de programao particulares de

uma determinada linguagem ou regras gerais de estilo de programao.

Padres de Persistncia: descrevem solues para problemas de armazenamento de informaes em arquivos ou bancos de dados.

Padres para Hipertexto: descrevem solues para problemas encontrados no

projeto de hipertextos.

Padres para Hipermdia: descrevem solues para problemas encontrados no

desenvolvimento de aplicaes hipermdia.

18

5 Coletneas de padres
5.1 Introduo
Conforme j mencionado no Captulo 1, diversos autores tm proposto centenas de padres nas mais diversas reas de aplicao. Esses padres so descobertos aps a abstrao de fatores comuns em diversos pares problema-soluo, podendo-se situar em vrias faixas de escala e abstrao. Existem padres de domnio especfico, como por exemplo para sistemas multimdia educativos (ver captulo 10) e tambm padres independentes de domnio, como por exemplo padres para projeto de interface. H padres que ajudam a estruturar um sistema de software em subsistemas e outros que ajudam a implementar aspectos de projeto particulares. Olhando mais de perto para muitos padres, percebe-se que um padro resolve um problema, mas sua aplicao pode gerar outros problemas, que podem ser resolvidos por outros padres. Em geral no existem padres isolados: um padro pode depender de outro no qual esteja contido, ou das partes que ele contm, ou ser uma variao de outro, ou ser uma combinao de outros. De maneira geral, um padro e seus variantes descrevem solues para problemas muito similares, que variam em algumas das influncias envolvidas. Portanto, deve-se pensar em formas de agrupar os padres existentes segundo algum critrio, de forma a facilitar sua recuperao e reuso. Isso pode ser feito por meio de colees de padres, catlogos de padres, sistemas de padres ou linguagem de padres. Este captulo tm por objetivo fornecer os conceitos relacionados a esses quatro tipos de agrupamento de padres, bem como exemplific-los, deixando clara a diferena entre eles e a utilidade de cada um deles em particular.

19

5.2 Conceitos & Terminologia

5.2.1 Colees de padres Uma coleo de padres uma coletnea qualquer de padres que no possuem nenhum vnculo entre si e, em geral, nenhuma padronizao no formato de apresentao. Os padres podem estar reunidos por terem sido apresentados em um mesmo congresso, por terem sido propostos pelo mesmo autor, ou por se referirem a um mesmo domnio, mas no possuem um relacionamento semntico significativo. 5.2.2 Catlogos de padres Um catlogo de padres uma colenea de padres relacionados (talvez relacionados apenas fracamente ou informalmente). Em geral subdivide os padres em um pequeno nmero de categorias abrangentes e pode incluir algumas referncias cruzadas entre os padres [Appleton 97]. Um catlogo de padres pode oferecer um esquema de classificao e recuperao de seus padres, j que eles esto subdivididos em categorias. Um catlogo de padres adiciona uma certa quantidade de estrutura e organizao a uma coleo de padres, mas usualmente no vai alm de mostrar apenas as estruturas e relaes mais superficiais (se que o faz) [Appleton 97]. 5.2.3 Sistemas de padres Um sistema de padres um conjunto coeso de padres co-relacionados que trabalham juntos para apoiar a construo e evoluo de arquiteturas completas. Alm de ser organizado em grupos e subgrupos relacionados em mltiplos nveis de granularidade, um sistema de padres descreve as diversas inter-relaes entre os padres e seus grupamentos e como eles podem ser combinados e compostos para resolver problemas mais complexos. Os padres num sistema de padres devem ser descritos num estilo consistente e uniforme e precisam cobrir uma base de problemas e solues suficientemente abrangente para permitir a construo de parcelas significativas de arquiteturas completas [Appleton 97].
20

Um sistema de padres interliga padres individuais, descreve como os padres que o constituem so conectados com outros padres no sistema, como esses padres podem ser implementados e como o desenvolvimento de software com padres apoiado. Um sistema de padres um veculo poderoso para expressar e construir arquiteturas de software [Buschmann 96]. Alm da estrutura e organizao oferecidas por um catlogo de padres, num sistema de padres adicionada uma maior profundidade estrutura, maior riqueza interao dos padres e maior uniformidade ao catlogo de padres [Appleton 97].

5.2.4 Linguagens de padres Uma linguagem de padres uma coleo estruturada de padres que se apoiam uns nos outros para transformar requisitos e restries numa arquitetura [Coplien 98]. Os padres que constituem uma linguagem de padres cobrem todos os aspectos importantes em um dado domnio. Pelo menos um padro deve estar disponvel para cada aspecto da construo e implementao de um sistema de software: no pode haver vazios ou brancos. Uma linguagem de padres uma forma de subdividir um problema geral e sua soluo complexa em um nmero de problemas relacionados e suas respectivas solues. Cada padro da linguagem resolve um problema especfico no contexto comum compartilhado pela linguagem. importante notar que cada padro pode ser usado separadamente ou com um certo nmero de padres da linguagem. Isso significa que um padro sozinho considerado til mesmo se a linguagem no for ser usada em sua plenitude. Meszaros e Doble [1998] propem uma linguagem de padres para auxiliar na escrita de padres. Ela possui uma sub-seo dedicada a padres a serem seguidos por linguagens de padres, dentre os quais padres especificando que uma linguagem de padres deve: dar ao leitor uma viso geral da linguagem de padres, fornecer uma tabela resumindo todos os padres, deixar claro quando houver formas alternativas para resolver o mesmo problema, deixar clara a estruturao da linguagem, utilizar um mesmo exemplo em

21

toda a linguagem para ilustrar cada padro e oferecer um glossrio de termos como parte da linguagem.

5.3 Sntese de trabalhos afins

Buschmann e outros [Buschmann 96] distinguem sistemas de padres de linguagens de padres, salientando que uma linguagem de padres tem a obrigao de ser completa em um certo domnio restrito, isto , tem que ter pelo menos um padro disponvel para cada aspecto da construo e implementao de sistemas de software. No pode haver falhas ou omisses. J um sistema de padres pode abranger um domnio mais amplo, sem ter essa obrigao de ser completo. Sua definio de um sistema de padres para arquitetura de software : uma coleo de padres para arquitetura de software, juntamente com diretrizes para sua implementao, combinao e uso prtico no desenvolvimento de software. Tal sistema deve dar apoio ao desenvolvimento de sistemas de alta qualidade, que satisfaam tanto a requisitos funcionais quanto no-funcionais. Os requisitos desejveis para um sistema de padres so os seguintes: Deve abranger uma base suficiente de padres: deve haver padres para especificao da arquitetura bsica do sistema, padres que ajudem ao refinamento dessa arquitetura bsica e padres que ajudem a implementar essa arquitetura de software em uma linguagem de programao especfica Deve descrever todos os padres de maneira uniforme: a forma de descrio deve captar tanto a essncia do padro quanto a definio precisa de seus detalhes e deve permitir a comparao do padro com outros Deve expor os vrios relacionamentos entre padres, tais como: refinamentos, combinaes, etc. Deve organizar os padres que o constituem: o usurio deve poder encontrar rapidamente um padro que resolva seu problema de projeto concreto e deve ser possvel que o usurio explore solues alternativas endereadas por padres diferentes Deve apoiar a construo de sistemas de software: deve haver diretrizes de como aplicar e implementar seus padres constituintes
22

Deve apoiar sua prpria evoluo: assim como a evoluo tecnolgica, um sistema de padres deve evoluir tambm. Assim, deve ser permitida a modificao de padres existentes, a melhoria de sua descrio, a adio de novos padres e a retirada de padres no mais utilizados

Riehle e Zllighoven [Riehle 95] apresentam uma linguagem de padres chamada A Pattern Language for Tool Construction and Integration Based on the Tools and Materials Metaphor. Essa linguagem foi desenvolvida para ajudar no aprendizado da metfora de ferramentas e materiais, segundo a qual o trabalho possui uma perspectiva especfica: as pessoas tem competncia e talento necessrio para seu trabalho; no h necessidade de definir um fluxo de trabalho fixo, porque as pessoas saber o que querem e podem arcar com mudanas na situao de forma adequada e as pessoas devem poder decidir sozinhas como organizar seu trabalho e seu ambiente (inclusive o software que utilizam), de acordo com suas tarefas. A idia principal dessa metfora que a maioria dos objetos de um domnio de aplicao devem pertencer ou a uma ferramenta ou a um material. Ferramentas so a forma de operar em materiais, onde materiais so resultado do trabalho em um domnio. Aarsten e outros [Aarsten 95] apresentam a G++, uma linguagem de padres para manufatura integrada ao computador. O problema abordado por essa linguagem o projeto de sistemas de informaes concorrentes e provavelmente distribudos, com aplicaes na manufatura integrada ao computador. O objetivo do trabalho aumentar o reuso de projeto orientado a objetos desde o nvel de componentes at o nvel arquitetural, oferecendo um modelo conceitual para arquiteturas concorrentes e distribudas. Cunningham [Cunningham 95] apresenta uma linguagem de padres chamada The CHECKS Pattern Language of Information Integrity, que diz como fazer checagem nas entradas de dados para separar dados invlidos dos vlidos e assegurar que o menor nmero possvel de dados invlidos seja registrado. O objetivo fazer essa checagem sem complicar os programas e comprometer a flexibilidade futura.. Em [Cunningham 96] ele apresenta a linguagem de padres chamada EPISODES: A Pattern Language of Competitive Development, que descreve uma forma de desenvolvimento de software apropriada para organizaes entreprenurial. Assume-se que os desenvolvedores dessa organizao trabalham em equipes pequenas de pessoas brilhantes e altamente motivadas e
23

que o tempo de mercado altamente valorizado pela organizao. Essa organizao tambm espera liberar outras verses em um tempo razovel, isto , ela espera ter sucesso e explorar esse sucesso pelo tempo que os clientes desejarem. Kerth [Kerth 95] apresenta uma linguagem de padres chamada Caterpillar's Fate: A Pattern Language for Transformation from Analysis to Design. Ela usada para apoiar a transformao dos documentos de anlise em um projeto inicial de software. O nome da linguagem (destino da lagarta) vem da analogia que feita entre a transio da anlise para o projeto com a lagarta que magicamente se transforma em uma borboleta. A linguagem tenta captar a sabedoria adquirida durante o desenvolvimento de solues de projeto a partir de modelos de anlise, documentando o que deve ser feito durante a transio. Braga e outros [Braga 99] apresentam uma linguagem de padres chamada A Pattern Language for Business Resource Management, que composta de padres para guiar o desenvolvimento de sistemas para gerenciamento de recursos de negcios tais como: produtos, carros, servios, etc. A linguagem composta de quinze padres

5.4 Exemplos
5.4.1 Colees de padres [Vlissides 96] uma coleo de padres, no caso dos padres apresentados no PLOP95. A Tabela 1 mostra alguns deles. Estudando esses padres de forma detalhada, observa-se que eles abrangem domnios e nveis de abstrao variados, e no possuem relacionamento explcito. So padres escritos por diversos autores diferentes e de maneira independente, isto , um autor no tinha conhecimento do que os demais autores estavam escrevendo. O editor do livro agrupou os padres que pertencem ao mesmo domnio ou fase do processo de desenvolvimento em captulos, mas isso no suficiente para que essa coleo de padres possa ser considerada um catlogo de padres.
Tabela 1 Coleo de Padres [Vlissides 96]

Captulo

Padro
Command Processor

Autor
Peter Sommerlad 24

2- Padres de propsitos gerais 32- Padres de propsitos especficos gerais

Command Processor

Peter Sommerlad

A Structural Pattern for Designing Transparent Jim Doble e Roy Campbell Shopper Aamod Sane Layered Services Patterns for Processing Satellite Telemetry with Stephen Berczuk Distributed Teams A Pattern Language for Object-RDBMS Kyle Brown e Bruce Integration Transactions and Accounts Patterns for Classroom Education Software Demonstrations A Pattern Language for na Essay-Based Web Robert Orenstein Site Whitenack Ralph Johnson Dana Anthony

A Pattern Language for the Preparation of Todd Coram

5.4.2 Catlogos de padres [Gamma 95] um catlogo de padres de projeto, pois possui mais estrutura e organizao, exibindo tambm relaes entre os padres. A Tabela 2 exibe os padres desse catlogo. Deve-se lembrar que os critrios para classificao dos padres so dois: escopo e propsito. No critrio escopo decide-se se o padro atua sobre uma classe ou sobre objetos da classe. Padres da classe lidam com os relacionamentos entre classes e suas subclasses, por meio do uso de herana, sendo portanto estabelecidos de forma esttica (em tempo de compilao). Padres do objeto lidam com relacionamentos entre objetos, que podem ser modificados durante a execuo e so mais dinmicos. A maioria dos padres utiliza herana de alguma forma. Portanto os nicos padres classificados na categoria classe so os que se concentram em relacionamentos de classes. No critrio propsito existem padres de criao, padres estruturais e padres comportamentais. Padres de criao concentram-se no processo de criao de objetos. Padres estruturais lidam com a composio de classes ou objetos. Padres comportamentais caracterizam as formas pelas quais classes ou objetos interagem e distribuem responsabilidades.
25

Tabela 2 Catlogo de Padres [Gamma 95]

Propsito
De Criao Classe Factory Method Objeto Abstract Factory Builder Prototype Singleton Estrutural Adapter Adapter Bridge Composite Decorator Facade Flyweygth Proxy Comportamental Interpreter Template Method Chain of Responsability Command Iterator Mediator Memento Observer State Strategy Visitor

Escopo

Gamma e outros propem tambm uma outra forma de organizar seus padres de projeto, mostrada na Figura 7. Nessa figura os padres esto relacionados de acordo com a maneira com que cada um referencia os outros na seo Related Patterns.

26

Figura 7 Relacionamento entre padres [Gamma 95]

5.4.3 Sistemas de padres [Buschmann 96] um exemplo de um sistema de padres, j que d maior destaque estrutura e interao entre os padres e os apresenta com maior uniformidade. A Tabela 3 mostra os padres desse sistema, no qual so usados dois critrios para classificao:

27

categorias de padres e categorias de problemas. As categorias de padres propostas por Buschmann e outros so:

padres arquiteturais, que podem ser usados no incio do projeto de alto nvel,
quando se faz a especificao da estrutura fundamental de uma aplicao;

padres de projeto, que so aplicados no final do projeto, quando se refina e se

estende a arquitetura fundamental de um sistema de software e

idiomas, que so usados na fase de implementao para transformar a

arquitetura de software em um programa escrito numa linguagem especfica

Abstraindo os problemas especficos que ocorrem durante o desenvolvimento de um software podem ser definidas categorias de problemas, cada uma das quais envolvendo diversos problemas relacionados. Essas categorias de problemas correspondem diretamente a situaes concretas de projeto. As categorias de problemas propostas por Buschamnn e outros para agrupar os padres que fazem parte do seu sistema de padres so:

Da lama para a estrutura (em ingls, From Mud to Structure): padres que
apoiam a decomposio adequada de uma tarefa do sistema em sub-tarefas que cooperam entre si;

Sistemas Distribudos (em ingls, Distributed Systems): padres que

fornecem infra-estrutura para sistemas que possuem componentes localizados em processadores diferentes ou em diversos sub-sistemas e componentes;

Sistemas Interativos (em ingls, Interactive Systems): padres que ajudam a

estruturar sistemas com interface homem-mquina;

Sistemas Adaptveis (em ingls, Adaptable Systems): padres que fornecem

infra-estruturas para a extenso e adaptao de aplicaes em resposta a requisitos de evoluo e mudana funcional;

Decomposio Estrutural (em ingls Structural Decomposition): padres

que apoiam a decomposio adequada de sub-sistemas e componentes complexos em partes cooperativas;

Organizao do Trabalho (em ingls, Organization of Work): padres que

definem como componentes colaboram para oferecer um servio complexo;

Controle de Acesso (em ingls, Access Control): padres que guardam e

controlam o acesso a servios e componentes;
28

Gerenciamento (em ingls, Management): padres para lidar com colees

homogneas de objetos, servios e componentes como um todo;

Comunicao (em ingls, Communication): padres que ajudam a organizar

a comunicao entre componentes e

Manuseio de Recursos (em ingls, Resource Handling): padres que ajudam

a gerenciar componentes e objetos compartilhados

Tabela 3 Sistema de Padres [Buschmann 96]

Padres arquiteturais Da lama para a estrutura Sistemas Distribudos Sistemas Interativos Sistemas adaptveis Decomposio da estrutura Organizao do trabalho Controle de Acesso Gerenciamento Comunicao Manuseio de Recursos Layers Pipes and Filters Blackboard Brokers Pipes and Filters Microkernel MVC PAC Microkernel Reflection

Padres de projeto

Idiomas

Whole-Part Master-Slave Proxy Command Processor View Handler Publisher-Subscriber Forwarder-Receiver Cliente-Dispatcher-Server Counted Pointer

5.4.4 Linguagem de padres [Meszaros 96] uma linguagem de padres para melhorar a capacidade e confiabilidade de sistemas reativos. Esses padres so geralmente encontrados em sistemas de telecomunicaes, embora possam tambm ser aplicados a quaisquer sistemas reativos com caractersticas de pico de capacidade. Por sistemas reativos entende-se aqueles sistemas cuja funo principal a de responder a requisies de usurios de fora do
29

sistema. Esses usurios podem ser pessoas ou mquinas. Exemplos de sistemas reativos so: sistemas computacionais de tempo compartilhado, centrais telefnicas de comutao, servidores, processamento de transaes on-line (como redes bancrias ATM, etc.). Todos esses sistemas precisam de alta capacidade a um custo razovel e alta confiabilidade quando frente de cargas extremas que podem levar sobrecarga do sistema. Essa linguagem de padres prope padres para lidar com a necessidade de sistemas de alta capacidade e sobrevivncia diante de condies de sobrecarga do sistema. A Figura 8 ilustra, de forma grfica, os padres que constituem a linguagem e seus relacionamentos, enquanto a Tabela 4 lista os padres e seus respectivos propsitos.
Capacity Bottleneck

Memory Capacity

Processing Capacity

Messaging Capacity

Faster Processor

Optimize HighRunner Cases

Shed Load

Share the Load

Finish Work in Progress

Fresh Work Before Stale

Match Progress Work with New

Shed Work at Periphery

Different Strokes for Different Folks

Hash Access Port

Leaky Bucket of Credits

Figura 8 Estrutura da Linguagem de Padres apresentada graficamente

Para ilustrar a similaridade de um padro de uma linguagem em relao a um padro convencional, como os vistos nos Captulos 4 a 10, descreve-se a seguir o padro Finish Work in Progress. Deve-se observar que, conforme foi dito na seo 13.2.4, como no existe um formato padro para escrever os padres de uma linguagem, os autores tm usado o formato que acreditam ser mais apropriado para documentar os padres que ele tem em mos. No caso desse exemplo, Meszaros utilizou o formato Nome/ Alias/ Problem/
30

Context/ Forces/ Solution/ Related Patterns.

Observe na descrio do padro

que

referncias a outros padres da linguagem so colocadas em sublinhado. Isso garante que o usurio da linguagem fique consciente do inter-relacionamento entre seus diversos padres.

Tabela 4 Padres da Linguagem e propsitos

Padro
Capacity Bottleneck Memory Capacity Processing Capacity Messaging Capacity Faster Processor Optimize High-Runner Cases Shed Load Share the Load Finish Work in Progress Fresh Work before Stale Match Progress work with new Shed Work at Periphery Different Strokes for Different Folks Hash Access Port Leaky Bucket of Credits

Propsito
Quando h um gargalo na capacidade do sistema, como proceder. Quando a causa do gargalo na capacidade do sistema a capacidade de memria, como proceder. Quando a causa do gargalo na capacidade do sistema a capacidade de processamento, como proceder. Quando a causa do gargalo na capacidade do sistema a dificuldade de enviar mensagens entre processadores a tempo, como proceder. Quando um processador mais rpido necessrio para aumentar a capacidade de processamento do sistema, como proceder. Quando a otimizao dos casos de maior demanda necessria para aumentar a capacidade de processamento do sistema, como proceder. Quando o descarte de parte da demanda necessrio para evitar sobrecarga da capacidade de processamento do sistema, como proceder. Quando o atendimento da demanda deve ser compartilhado por mais de um processador para aumentar a capacidade de processamento do sistema, como proceder. Quando o trmino do atendimento de trabalho em curso necessrio para evitar sobrecarga da capacidade de processamento do sistema,, como proceder. Quando o atendimento prioritrio de certos clientes necessrio para evitar sobrecarga da capacidade de processamento do sistema, como proceder. Quando necessrio evitar o desperdcio dos recursos j empregados no atendimento de certos clientes, causado por sua desistncia de obter atendimento, como proceder. Quando necessrio o descarte da demanda que est alm da capacidade de processamento do sistema, como proceder para detectar o quanto antes o que dever ser descartado. Quando necessrio o estabelecimento de prioridades para o atendimento de certos clientes, como proceder para garantir que esse atendimento seja de boa qualidade. Quando o estabelecimento de funes Hash na porta de entrada de atendimento prioritrio necessrio para estabelecer as prioridades, como proceder. Quando reservatrios com vazamento so necessrios para armazenar os crditos enviados aos processadores perifricos por processadores sobrecarregados que todavia ainda possuem capacidade de processamento disponvel, como proceder

31

Padro 5 Finish Work in Progress (Termine o Trabalho em Andamento) Tambm conhecido como: Termine o que voc comeou Problema: Quais requisies devem ser aceitas e quais devem ser rejeitadas de
forma a melhorar o throughput do sistema?

Contexto: Voc est trabalhando com um sistema reativo ou orientado a transaes,

no qual as requisies do usurio dependem de certa forma umas das outras. Uma requisio pode se apoiar em uma requisio prvia, fornecer informao adicional em resposta (ou em antecipao) a outra requisio, ou cancelar ou desfazer uma requisio prvia.

Influncias: Entender as interdependncias entre requisies crucial para separar

trabalho de forma produtiva. Rejeitar o trabalho errado pode negar investimento prvio considervel, ou pior ainda, resultar em deadlock por pendurar algumas transaes juntamente com todos os recursos que elas estejam usando. Falhar na identificao do trabalho que pode ser rejeitado inibe a melhoria da capacidade do sistema pela aplicao do padro Shed Load.

Soluo: Requisies que so continuaes de trabalho em andamento devem ser

reconhecidas como tal e devem ser priorizadas em relao requisies totalmente novas. Claramente categorize todas as requisies em categorias Novo e Em Andamento, e assegure que todas as requisies do tipo Em Andamento sejam processadas antes das do tipo Novo. A nica exceo a essa regra quando o tempo decorrido entre as requisies iniciais e as seguintes fixo e previsvel (por exemplo, t segundos). Nessa situao, bloquear completamente todas as requisies novas resultar em uma queda de carga t segundos depois que o sistema comear a separar o trabalho novo. Isso cria uma oscilao entre uma condio de sobrecarga e subcarga; o resultado uma capacidade mdia reduzida. Isso pode ser contornado admitindo uma pequena quantidade de trabalho novo durante o perodo de sobrecarga para reduzir a profundidade da queda.

Padres Relacionados: Esse padro apoia a aplicao do padro Shed Load.

32

6 Escrita e Uso de Padres

6.1 Regras para derivao de novos padres
Algumas regras para derivao de novos padres (Pattern mining) so sugeridas por Buschmann e outros [Buschmann 96]. So elas: 1. Encontre pelo menos trs exemplos nos quais um problema resolvido efetivamente usando a mesma soluo. ..... 2. Extraia a soluo, o problema e as influncias 3. Declare a soluo como candidata a padro 4. Execute um writers workshop para melhorar a descrio do candidato e compartilh-lo com outros 5. Aplique o candidato a padro em um outro projeto de desenvolvimento de software 6. Declare o candidato a padro como padro se sua aplicao for bem sucedida. Caso contrrio tente procurar uma soluo melhor.

6.2 Desenvolvimento de sistemas usando padres

Segundo Buschmann e outros [Buschmann 96], padres no definem um novo mtodo para desenvolvimento de software que substitua os j existentes. Eles apenas complementam os mtodos de anlise e projeto gerais e independentes do problema, p.ex, Booch, OMT, Shlaer/Mellor, etc., com diretrizes para resolver problemas especficos e concretos. Em [Buschmann 96] sugerem-se os seguintes passos para desenvolver um sistema usando padres de software: 1. Utilize seu mtodo preferido para o processo de desenvolvimento de software em cada fase do desenvolvimento. 2. Utilize um sistema de padres adequado para guiar o projeto e implementao de solues para problemas especficos, isto , sempre que encontrar um padro que resolva um problema de projeto presente no sistema, utilize os passos de

33

implementao associados a esse padro. Se esses se referirem a outros padres, aplique-os recursivamente. 3. Se o sistema de padres no incluir um padro para seu problema de projeto, tente encontrar um padro em outras fontes conhecidas. 4. Se nenhum padro estiver disponvel, aplique as diretrizes de anlise e projeto do mtodo que voc est usando. Essas diretrizes fornecem pelo menos algum apoio til para resolver o problema de projeto em mos. Segundo Buschmann, essa abordagem simples evita que se criem outros mtodos de projeto. Ela combina a experincia de desenvolvimento de software captada pelos mtodos de anlise e projeto com as solues especficas para problemas de projeto descritas pelos padres. Os autores destas notas didticas discordam quanto a essa afirmao, por acharem que est claro que a abordagem proposta cria um novo mtodo de desenvolvimento de sistemas, diferente dos j existentes.

6.3 Exerccios
1) Discuta a evoluo de uma coleo de padres para se tornar um catlogo, um sistema e uma linguagem de padres. 2) Quais as dificuldades de recuperao de um padro nas diversas formas de agrupamento dos mesmos? 3) Apresente mais um critrio de classificao que poderia ser til na recuperao de padres. 4) Em que voc concorda/discorda em relao proposta para derivao de novos padres? Por que?

34

7 Concluses
Padres documentam uma parte repetida de um projeto orientado a objetos, permitindo seu entendimento e aplicao em um contexto particular. Eles fornecem ao projeto um vocabulrio comum aos desenvolvedores, facilitando a comunicao entre projetistas. Alm disso, eles constituem uma base de experincia para construo de software reutilizvel. Pode-se pensar em padres como blocos construtivos a partir dos quais projetos mais complexos podem ser construdos Padres expem conhecimento sobre a construo de software que foi ganho por especialistas em muitos anos. Portanto, todo trabalho sobre padres deveria esforar-se para colocar esse recurso precioso amplamente disponvel [Buschmann 96]: Todo desenvolvedor de software deveria ser capaz de usar padres de forma efetiva. Quando isso for conseguido, seremos capazes de comemorar a inteligncia humana que os padres refletem, tanto em cada padro individual quanto em todos os padres na sua plenitude. Tanto padres quanto frameworks so valiosos instrumentos de reuso. Alm disso, os padres so preciosos para a documentao dos frameworks.

Referncias:
[Alexander 77] [Alexander 79] [Appeton 97] [Beck 87] [Bosch 97] [Boyd 98] [Braga 98a] Christopher Alexander et. al., A Pattern Language, Oxford University Press, New York, 1977. Christopher Alexander, The Timeless Way of Building, Oxford University Press, New York, 1979. Appleton, Brad. Patterns and Software: Essential Concepts and Terminology, disponvel na WWW na URL: http://www.enteract.com/~bradappdocpatterns-intro.html. Beck, Kent; Cunningham, Ward. Using Pattern Languages for ObjectOriented Programs, Technical Report n CR-87-43, 1987, disponvel na WWW na URL: http://c2.com/doc/oopsla87.html Bosch, Jan. Design Patterns as Language Constructs, disponvel na WWW na URL: http://st-www.cs.uiuc.edu/users/patterns/papers, 1997. Boyd, L. Business Patterns of Association Objects. In: Martin, R.C.; Riehle, D.; Buschmann, F. Pattern Languages of Program Design 3. Reading, MA, Addison-Wesley, 1998, p. 395-408. Braga, Rosana T. V.; Germano, Ferno S.R.; Masiero, Paulo C. A Family of Patterns for Business Resource Management. In Proceedings of the 5th
35

Annual Conference on Pattern Languages of Programs (PLOP98), Monticello, Illinois, Technical Report #WUCS-98-25, Washington University in St. Louis, Missouri, EUA, agosto de 1998, disponvel na WWW na URL: http://jerry.cs.uiuc.edu/plop/plopd4-submissions/ plopd4-submissions.html. [Braga 98b] Braga, Rosana T.V.; Germano, Ferno S.R.; Masiero, Paulo C. Experimentos para implementao do padro Type-Object em linguagem Delphi. So Carlos, USP, 1998. (Documento de Trabalho, ICMSC-USP, So Carlos, SP) [Budinsky 96] Budinsky, F.J, et al. Automatic code generation from design patterns. IBM Systems Journal, V. 35, n 2, p. 151-171, 1996. [Buschmann 96] Buschmann, F. et at. A System of Patterns, Wiley, 1996. [Chikofsky 90] Chikofsky, E.J.; Cross, J.H. Reverse Engineering and Design Recovery: A Taxonomy. IEEE Trans. Software, pp. 13-17, Janeiro 1990. [CMG 98] Component Management Group (CMG). Anti-patterns, disponvel na WWW na URL: http://160.79.202.73/Resource/AntiPatterns/index.html. [Coad 91] Coad, Peter/ Yourdon, Edward. Object-Oriented Analysis, 2 edio, Yourdon Press, 1991. [Coad 92] Coad, Peter. Object-Oriented Patterns. Communications of the ACM, V. 35, n9, p. 152-159, setembro 1992. [Coad 95] Coad, P.; North, D.; Mayfield, M. Object Models: Strategies, Patterns and Applications, Yourdon Press, 1995. [Cook 94] Cook, Steve; Daniel, John. Designing Object Systems. Prentice Hall, 1994. [Coleman 94] Coleman, D. et al. Object Oriented Development - the Fusion Method. Prentice Hall, 1994. [CMG 98] Component Management Group (CMG). Anti-patterns, disponvel na WWW na URL: http://160.79.202.73/Resource/AntiPatterns/index.html. [Coplien 92] Coplien, J.O. Advanced C++ Programming Styles and Idioms. ReadingMA, Addison-Wesley, 1992. [Coplien 95] Coplien, J.; Schmidt, D. (eds.) Pattern Languages of Program Design, Reading-MA, Addison-Wesley, 1995. [Coplien 98] James O. Coplien. Software Design Patterns: Common Questions and Answers. In Linda Rising, editor, The Patterns Handbook: Techniques, Strategies, and Applications, p. 311-320. Cambridge University Press, New York, January 1998. [Cunningham 95] Cunningham,Ward. The CHECKS Pattern Language of Information Integrity. In Coplien, J.; Schmidt, D. (eds.) Pattern Languages of Program Design, Reading-MA, Addison-Wesley, 1995, p. 145-155. [Cunningham 96] Cunningham,Ward. EPISODES: A Pattern Language of Competitive Development. In: Vlissides, J.; Coplien, J.; Kerth, N (eds.). Pattern Languages of Program Design 2. Reading-MA; Addison-Wesley, 1996, p. 371-388. [Eriksson 98] Eriksson, H.; Penker, M. UML Toolkit. New York, Wiley Computer Publishing, 1998. [Fayad 97] Fayad, M.E.; Schmidt, D.C. (eds) Object-Oriented Application Frameworks. Communications of the ACM, V. 40, n 10, p. 32-38, 1997.
36

[Fowler 97] [Gall 96]

[Gamma 93] [Gamma 95] [Graham 94] [Johnson 88] [Johnson 91] [Johnson 97] [Johnson 97a] [Johnson 98] [Kerth 97] [Kramer 96]

[Krasner 88] [Martin 98] [Masiero 93] [Masiero 98]

Fowler, M. Analysis Patterns. Menlo-Park-CA, Addison-Wesley, 1997. Gall, Harald C., Klsh, Ren R.; Mittermeir, Roland T. Application Patterns in Re-Engineering: Identifying and Using Reusable Concepts. Proceedings of the 6th International Conference on Information Processing and Management of Uncertainty in Knowledge-Based Systems, Julho 1996, p. 1099-1106. Gamma, E.; Helm, R.; Johnson,R.; Vlissides, J. Design Patterns Abstraction and Reuse of Object-Oriented Design. LNCS, n 707, p. 406431, julho de 1993. Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. Design Patterns Elements of Reusable Object-Oriented Software. Reading-MA, AddisonWesley, 1995. Graham, Ian. Object Oriented Methods, 2 edio, Addison-Wesley, 1994. Johnson, Ralph E.; Foote B. Designing Reusable Classes. Journal of Object Oriented Programming JOOP, 1(2):22-35, Junho/Julho 1988. Johnson, Ralph E.; Russo, Vincent. Reusing Object-Oriented Designs. Relatrio Tcnico da Universidade de Illinois, UIUCDCS 91-1696, 1991. Johnson, Ralph E. CS497 Lectures Lecture 12, 13, 14 e 17, disponvel na WWW na URL: http://st-www.cs.uiuc.edu/users/johnson/cs497 /notes98/online-course.html Johnson, Ralph. E. Frameworks = (Components + Patterns). Communications of the ACM, V. 40, n 10, p. 39-42, 1997. Johnson, Ralph E.; Woolf, B. Type Object. In: Martin, R.C.; Riehle, D.; Buschmann, F. Pattern Languages of Program Design 3. Reading-MA, Addison-Wesley, 1998, p. 47-65. Kerth, Norman L.; Cunningham, Ward. Using Patterns to Improve Our Architectural Vision, IEEE Software, pp. 53-59, janeiro, 1997. Krmer, Christian; Prechelt, Lutz. Design Recovery by Automated Search for Structural Design Patterns in Object-Oriented Software. Proceeding of the 3rd Working Conference on Reverse Engineering (WCRE), Monterey-CA, EUA, 1996, p. 208-215. Krasner, E. K.; Pope, S.T. A Cookbook for using the Model-ViewController User Interface Paradigm in Smalltalk-80. Journal of Object Oriented Programming, p. 26-49, Agosto-Setembro 1988. Martin, R.C.; Riehle, D.; Buschmann, F. (eds.) Pattern Languages of Program Design 3, Reading-MA, Addison-Wesley, 1998. Masiero, P.C.; Meira, C.A. A. Development and Instantiation of a Generic Application Generator. Journal of Systems and Software, Vol. 23, pp. 27-37, 1993. Masiero, P.C.; Germano, F.S; Maldonado, J.C. Object and System Life Cycles Revisited: Their Use in Object-Oriented Analysis and Design Methods. Proceedings of the 3rd CaiSE/IFIP8.1 (International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design), Pisa, Italy, pp. O1-O12, Junho 1998.

37

[Meira 91] [Meszaros 95] [Pree 95] [Pressman 95] [Riehle 95]

[Roberts 98]

[Schmidt 96] [Schmid 97] [Taligent 93] [Taligent 94] [Turine 98]

[Vlissides 95]

[Vlissides 96] [Yoder 98]

MEIRA, C.A.A. Sobre Geradores de Aplicao, Dissertao de Mestrado apresentada ao Instituto de Cincias Matemticas de So Carlos, USP, setembro de 1991. Meszaros, Gerard. A Pattern Language for Improving the Capacity of Reactive Systems. In: Coplien, J.; Schmidt, D. (eds.) Pattern Languages of Program Design, Reading-MA, Addison-Wesley, 1995, p. 575-591. Pree, Wolfgang. Design Patterns for Object-Oriented Software Development. Reading-MA, Addison-Wesley, 1995. Pressman, Roger S. Engenharia de Software, Makron Books, 1995. Riehle, Dirk; Zllighoven, Heinz. A Pattern Language for Tool Construction and Integration Based on the Tools and Materials Metaphor. In: Coplien, J.; Schmidt, D. (eds.) Pattern Languages of Program Design, Reading-MA, Addison-Wesley, 1995, p. 9-42. Roberts, Don; Johnson, Ralph E. Evolving Frameworks: A Pattern Language for Developing Object-Oriented Frameworks, In Martin, R. C.; Riehle, D. and Buschmann, F. Pattern Languages of Program Design 3, Addison-Wesley, pp. 471-486, 1998, disponvel na WWW na URL: http://st-www.cs.uiuc.edu/users/droberts/evolve.html Schmidt, Douglas C.; Fayad, Mohamed; Johnson, Ralph E. (guest editors). Software Patterns. Communications of the ACM, V. 39, n10, pp. 36-39, outubro 1996. Schmid, H. A. Systematic Framework Design by generalization. Communications of the ACM, V. 40, n 10, p. 48-51, 1997. Taligent Inc. Leveraging Object-Oriented Frameworks. A Taligent White Paper, 1993, disponvel na WWW na URL: http://www.ibm.com/java/education/ooleveraging. Taligent Inc. Building Object-Oriented Frameworks. A Taligent White Paper, 1994, disponvel na WWW na URL: http://www.ibm.com/java/education/oobuilding/index.html. Turine, Marcelo A. S. Fundamentos, Conceitos e Aplicaes do Paradigma de Orientao a Objetos. Apresentao didtica, agosto de 1998, disponvel na WWW na URL: http://nt-labes.icmsc.sc.usp.br/cursos/sce220/02_98/aulas.html Vlissides, John. Reverse Architecture, Position Paper for Software Architectures Seminar, Schloss Daghstuhl, Germany, agosto 1995, disponvel na WWW na URL: http://st-www.cs.uiuc.edu/users/patterns/papers/,. Vlissides, J.; Coplien, J.; Kerth, N (eds.). Pattern Languages of Program Design 2. Reading-MA; Addison-Wesley, 1996. Yoder, J.W.; Johnson, R.E.; Wilson, Q.D. Connecting Business Objects to Relational Databases. Proceedings of the 5th Conference on the Pattern Languages of Programs, Monticello-IL, EUA, agosto de 1998. (Relatrio Tcnico n WUCS-98-25 da Universidade de Washington), disponvel na WWW na URL: http://jerry.cs.uiuc.edu/~plop/plop98/final_submissions/

38

ANEXO: NOTAO UML (Unified Modeling Language)

A1 Breve Histrico
Entre os anos de 1989 e 1994 houve um grande aumento do nmero de linguagens de modelagem. Diversos mtodos para anlise, modelagem e projeto orientado a objetos surgiram, causando uma espcie de guerra dos mtodos. Apesar dos diversos mtodos e do paradigma da orientao a objetos j estarem bem estabelecidos, uma das principais dificuldades encontradas na modelagem e projeto orientado a objetos era a falta de padronizao. A partir de meados da dcada de 90, comeou-se a reconhecer que havia pontos fortes e fracos em cada um dos mtodos para modelagem e projeto orientado a objetos. A Unified Modeling Language (UML) uma linguagem para modelagem, anlise, projeto e documentao orientados a objetos de sistemas que possuem requisitos complexos. Ela resultado da fuso de conceitos oriundos das metodologias Booch [Booch 93], OMT (Object Modeling Technique) [Rumabugh 93] e OOSE (Object-Oriented Software Engineering) [Jacobson 92]. A UML um linguagem para modelagem orientada a objetos adotada como padro pelo OMG (Object Management Group)1 . A maioria dos mtodos consiste, pelo menos a princpio, de uma linguagem (grfica ou no) e de um processo. A linguagem de modelagem consiste da notao que o mtodo utiliza para expressar o modelo e o projeto, enquanto o processo apresenta os passos que devem ser tomados para desenvolver o modelo e o projeto. O desenvolvimento da UML teve incio em outubro de 1994, quando Booch e Rumbaugh comearam um esforo para unificar seus mtodos. Uma primeira verso, chamada Unified Method 0.8, foi divulgada em outubro de 1995. Jacobson juntou-se ento ao grupo, agregando caractersticas do seu mtodo. O esforo dos trs resultou na liberao da UML verso 0.9 e 0.91 em junho e outubro de 1996, respectivamente. Em

http://www.omg.org. 39

janeiro de 1997 foi liberada a verso 1.0 da UML, tendo sido recomendada como padro pela OMG em final de 1997. Foi formado um consrcio para o desenvolvimento da UML. Este consrcio composto de diversas empresas, entre as quais a Digital Equipment Corporation, HP, Intellicorp, i-Logic, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Rational Software, TI e Unisys. J existem algumas ferramentas para auxiliar o projeto e a modelagem de sistemas, utilizando a UML. Por exemplo, a Rational Software Corporation e at mesmo a Microsoft j lanaram produtos para auxiliar a modelagem e projeto de sistemas, gerar cdigo a partir da modelagem e projeto e realizar engenharia reversa, ou seja, obter o modelo em UML a partir do cdigo. A Famlia Rational Rose98i Interprise a ferramenta mais completa e entre outras caractersticas, gera cdigo para SMALLTALK, PowerBuilder, C++, J++ e Visual Basic.

A2 Notao
A UML apenas uma linguagem de modelagem e no um mtodo, portanto fornece uma notao para modelagem e projeto orientado a objetos, sendo composta de 9 diagramas principais: Diagrama de casos de uso (em ingls, Use-Case Diagram), Diagrama de classe, Diagrama de objeto, Diagrama de estado, Diagrama de atividade, Diagrama de seqncia, Diagrama de colaborao, Diagrama de componente e Diagrama de disponibilidade. Os dois primeiros diagramas preocupam-se com a modelagem da parte esttica do sistema. Os diagramas de casos de uso so similares aos do mtodo OOSE. Os diagramas de classes so uma fuso dos diagramas de classe do OMT, Booch e da maioria dos mtodos OO, com alguns novos elementos de modelagem. Os diagramas de objetos so uma variao do diagrama de classes e utilizam uma notao praticamente igual. A diferena entre os dois que um diagrama de objetos mostra um certo nmero de objetos ou instncias das classes, ao invs das classes em si. Os diagramas de estado so uma simplificao dos statecharts, sendo utilizados para complementar a descrio de uma classe. Eles mostram todos os possveis estados que um objeto da classe pode ter e quais eventos causam mudanas de estado. Os diagramas de
40

atividades mostram um fluxo seqencial de atividades e usado para descrever as

atividades executadas em uma operao ou outros fluxos de atividade como casos de uso ou interao. Os diagramas de seqncia mostram a colaborao dinmica entre um certo nmero de objetos, por meio de uma seqncia de mensagens enviadas entre os objetos. Os diagramas de colaborao mostram a colaborao dinmica, da mesma forma que os diagramas de seqncia, mas adicionando ao diagrama os objetos e seus relacionamentos (diz-se o contexto). Os diagramas de componente mostra a estrutura fsica do cdigo em termos de componentes de cdigo. Um componente pode ser um componente de cdigo, um componente binrio ou um componente executvel. Os diagramas de disponibilidade mostram a arquitetura fsica do sistema de hardware e software. Nele podem ser mostrados os dispositivos e computadores (ns), juntamente com suas interconexes e o tipo de conexo. No contexto destas notas didticas, sero detalhados apenas os diagramas de classes e diagramas de casos de uso, por serem utilizados para representao de padres, quando pertinente. Na UML existem alguns elementos genricos (isto , aparecem em qualquer um dos diagramas) So eles: Note: um comentrio inserido no diagrama. Constrain: uma relao semntica entre elementos do modelo. Especifica condies ou proposies que devem ser mantidas verdadeiras. Uma restrio mostrada como uma cadeia entre chaves {}. Name: uma cadeia usada para identificar um elemento do modelo dentro de algum escopo Path name: usado para encontrar um elemento do modelo a partir da raiz do sistema, por exemplo: MathPak::Matrices::BandedMatrix.dimension Property string: uma cadeia usada para mostrar propriedades de certos elementos do sistema Tagged value: cada tag representa um tipo particular de propriedade aplicvel a um ou vrios elementos do modelo. um mecanismo de extenso que permite que informaes arbitrrias sejam conectadas aos modelos

41

Packages: agrupa elementos de modelagem; podendo conter classes, relacionamentos, classes abstratas, Packages, tipos, etc. A Figura 11 a seguir apresenta um exemplo de um diagrama de classes apenas com packages.

Esteretipo (Stereotype):

um mecanismo de extenso introduzido pela

UML, que permite que o usurio estenda o meta-modelo para suprir necessidades no encontradas entre os meta-elementos disponveis, desde que a definio semntica da prpria linguagem no seja ferida. Um esteretipo pode ser aplicado a classes, relacionamentos de dependncia, atributos, operaes, etc. Exemplos de esteretipos: <<abstract>> e <<metclass>> O diagrama da Figura 9, apresenta exemplos de constrain. As classes so representadas pelos retngulos e as constraints esto entre {}. A Figura 10 apresenta um diagrama com a representao grfica de alguns dos elementos da UML.
membro de *
1 {subset } Chefe de

Pessoa

Comit
*
*

{pessoa.chefe de comit = pessoa.membro de comit}

trabalha para +empregado

Pessoas
* +boss 0..1

+worker

+empregador Empresa

Figura 9 Exemplo de elementos genricos

42

Class Attributes Operations

Object Attributes Operations Interface Node Component State

User Case

Package

Note

Figura 10 Representao grfica de alguns elementos de modelagem da UML

Acadmico

Graduao (from Acadmico)

PosGraduao (from Acadmico)

Figura 11 Exemplo de package

A2.1 Diagramas de Caso de Uso (Use Cases)

Um diagrama de caso de uso mostra o relacionamento entre os atores e os casos de uso dentro de um sistema. Um caso de uso uma descrio de uma funcionalidade (um uso especfico do sistema) oferecida pelo sistema. Um caso de uso representado por uma elipse contendo o nome do caso de uso. Um ator algum ou alguma coisa que interage com o sistema, podendo ser representado no diagrama como um retngulo de classe com o esteretipo "ator" ou pelo cone de um boneco. A Figura 12 mostra um diagrama de casos de uso para um sistema de biblioteca.

43

Sistema de Biblioteca

Leitor
Reservar Adiciona ttulo

Cancelar reserva

<<uses>>

Remover /atualizar ttulo

<<uses>> <<uses>>
Manuteno

Bibliotecrio

Emprestar

Adiciona item

<<uses>> <<uses>>

Bibliotecrio

Devolver

Adiciona leitor

Figura 12 - Exemplo de Um Diagrama de Caso de Uso.

A2.2 Diagramas de Classes

Um diagrama de classes uma coleo de elementos estticos do modelo, tais como: classes, tipos, e seus relacionamentos, conectados uns aos outros e aos seus contedos como um grafo. Alguns dos principais elementos de um diagrama de classes so:

Classe: um conjunto de objetos semelhantes. Uma vez instanciadas originam objetos.

Metaclasse: so elementos que uma vez instanciados originam as classes. Classes abstratas: so classes que no possuem instncias. Classes concretas: so classes que possuem instncias diretas. Tipo (Type): um descritor para objetos com estado abstrato, especificao de

operaes externas concretas, e nenhuma implementao das operaes. Um tipo estabelece uma especificao comportamental para classes. Uma classe que suporta as operaes definidas por um tipo dita "implementar" o tipo e pode ser representada como um smbolo de uma classe com o esteretipo << tipo >>. Alm disso, um tipo pode conter listas de atributos abstratos e de operaes.

44

Para diferenciar uma classe de uma instncia, o nome e o tipo aparecem sublinhados.
Utility: so esteretipos de classe, que servem para agregar atributos e/ou mtodos

genricos do sistema.
Templates: permitem a criao de famlia de classes Association Class: Designa uma associao que tem propriedades como uma classe, tais

como atributos, operaes e outras associaes. A UML fornece cinco tipos diferentes de relacionamento:
Associao: a forma de relacionamento mais genrica que pode haver entre duas classes Agregao: uma classe formada agregando-se outras classes Composio: uma classe formada compondo-se outras classes Generalizao: uma classe formada a partir da especializao de outra classe Dependncia: uma classe (dependente) depende de outra classe (independente). Uma

mudana na classe independente afeta a classe dependente. A UML permite tambm a representao de classificao dinmica e mltipla herana. A Figura 13 apresenta a notao para representao de uma classe.

Figura 13 - Representao de uma Classe.

Um atributo e um mtodo possuem trs tipos de visibilidade; pblica, privada e protegida. A seguir so apresentados exemplos de representao de alguns dos elementos de modelagem da UML que aparecem no diagrama de classes. A Figura 19 ilustra um relacionamento de dependncia. Neste caso uma alterao na classe Email dever implicar em uma alterao na classe DiscussionGroup.

45

< < Ty p e > > P ric e P ric e L is t

Figura 14 - Exemplo de Type (Tipo).

Person

Owns Owned by

0..*

Car

Figura 15 - Exemplo de Associao.

Figura 16 - Exemplo de Associao do tipo or.

Polygon

contains

3..*

Point

{ordered} GraphicsBundle color texture 1 density

Figura 17- Exemplo de relacionamentos de composio e agregao.

46

Figura 18- Exemplo de relacionamentos de Generalizao.

Figura 19 - Exemplo de relacionamentos de Dependncia

47