Vegetasjonsfordeling og topografi i et GIS-perspektiv

Gabaritos de Negócios Padrões de Projeto Modelo da Tecnologia Modelo de Negócios Modelo da Aplicação Modelo de Implementação OMT UML C++ Java Analisar Projetar Gerar Entregar

Figura 2.4: Estrutura do OmniBuilder (OMNISPHERE, 2002)

controlar mudanc¸as causadas em categorias de objetos ao longo do tempo, o que pode ser repre- sentado utilizando contas e transac¸˜oes. Algumas caracter´ısticas importantes em sistemas cont´abeis e providas pelo frameworkAccounts s˜ao: prover um meio de acesso `as transac¸˜oes de acordo com

sua data, criar grupos de contas de acordo com uma hierarquia e armazenar os dados em um banco de dados.

2.5

Trabalhos relevantes que relacionam padr ˜oes a fra-

meworks

2.5.1

HotDraw

Os primeiros frameworks comec¸aram a surgir a partir de 1986, praticamente na mesma ´epoca das linguagens de padr˜oes. Quem primeiro notou o relacionamento entre linguagens de padr˜oes e

2.5 Trabalhos relevantes que relacionam padr˜oes a frameworks 27 frameworks foi Johnson (1992), em um artigo no qual sugere a utilizac¸˜ao de padr˜oes para docu- mentar frameworks e, desta forma, facilitar seu reuso. Ele apresenta um conjunto de dez padr˜oes para documentar o framework HotDraw, que ´e um framework para editores gr´aficos semˆanticos

desenvolvido originalmente na empresa “Tektronix”, por Kent Beck e Ward Cunningham, e reim- plementado diversas vezes desde ent˜ao18_.

O padr˜oes que documentam oHotDraw foram criados ap´os o framework, portanto n˜ao foram

utilizados no seu desenvolvimento. Seu prop´osito ´e de ensinar a utilizar o framework e n˜ao de mostrar como ele funciona, embora muitas vezes os padr˜oes contenham informac¸˜oes sobre a teoria envolvida no projeto do framework, ´util para melhor entendˆe-lo.

Johnson sugere que o primeiro padr˜ao do conjunto de padr˜oes descreva o prop´osito do fra- mework e que os padr˜oes sejam tratados como um grafo dirigido, no qual as informac¸˜oes sobre o projeto do framework fiquem o mais longe poss´ıvel do primeiro padr˜ao. Cada padr˜ao deve conter indicac¸˜oes dos pr´oximos padr˜oes a aplicar. Al´em disso, Johnson ressalta a necessidade de colocar exemplos ilustrativos em cada padr˜ao, que tornam o framework mais concreto, do ponto de vista dos usu´arios, e fazem com que seu fluxo de controle seja melhor entendido.

Johnson optou pelo uso do termo “padr˜oes” ao inv´es de “linguagens de padr˜oes”, devido `a forte conotac¸˜ao matem´atica envolvida no termo “linguagem”, que implica formalismos (como linguagens livres de contexto, por exemplo). Posteriormente, o termo “linguagem de padr˜oes” foi melhor definido pela comunidade de padr˜oes e outros trabalhos usando essa denominac¸˜ao foram publicados a partir da primeira conferˆencia sobre padr˜oes, em 1994, nos Estados Unidos.

Outro trabalho que trata do relacionamento entre o frameworkHotDraw e padr˜oes ´e o artigo

de Beck e Johnson (1994), no qual s˜ao mostrados os padr˜oes de projeto contidos no HotDraw e

que, portanto, servem para gerar sua arquitetura. O objetivo desses padr˜oes ´e documentar o projeto do framework para facilitar sua compreens˜ao, seja para fins de manutenc¸˜ao ou para permitir sua instanciac¸˜ao para aplicac¸˜oes espec´ıficas.

2.5.2

G++

O framework G++ (Brugali et al., 2000), constru´ıdo com base na linguagem de padr˜oes de mesmo nome (Aarsten et al., 2000), foi o ´unico caso encontrado na literatura, at´e o momento da escrita desta tese, de um framework constru´ıdo com base em uma linguagem de padr˜oes.

O G++ ´e um framework para desenvolvimento de sistemas integrados de fabricac¸˜ao, forne- cendo classes que implementam blocos construtivos a serem usados no desenvolvimento de novas aplicac¸˜oes. Foi constru´ıdo com base na linguagem de padr˜oes G++, que possui onze padr˜oes estruturados por meio de uma ´arvore, conforme mostra a Figura 2.5.

18

mais informac¸˜oes sobre oHotDraw podem ser obtidas na URL: http://st-www.cs.uiuc.edu/users/

2.5 Trabalhos relevantes que relacionam padr˜oes a frameworks 28

1 Hierarquia de

Camadas de Controle

2 Visibilidade de

Comunicação entre

Módulos de Controle 3 Objetos e

Concorrência 4 Ações Disparadas por Eventos 5 Serviços esperando por uma condição 6 Cliente/Servidor /Serviço 7 Implementação _{de Módulos de} Controle

8 Interface para _{Módulos de}

Controle

9 Protótipo e

Realidade

10 Distribuição dos _{Módulos de}

Controle

11 Controle

Remoto

Figura 2.5: Linguagem de Padr˜oes G++ (Aarsten et al., 2000)

Os padr˜oes da G++ situam-se em diversos n´ıveis de abstrac¸˜ao: os dois primeiros padr˜oes da Figura 2.5 referem-se `a an´alise e projeto de alto n´ıvel da aplicac¸˜ao desenvolvida; os padr˜oes de trˆes a seis tratam do projeto l´ogico; os padr˜oes de sete a nove cuidam da transic¸˜ao do prot´otipo da aplicac¸˜ao para sua implementac¸˜ao final; e os padr˜oes dez e onze apresentam dois casos de distribuic¸˜ao f´ısica.

O framework G++ fornece mecanismos, classes abstratas e blocos construtivos para a maioria das soluc¸˜oes propostas pela linguagem de padr˜oes G++ (Brugali et al., 1997). Os componen- tes do framework s˜ao classificados em trˆes tipos: elementares, projeto b´asico e dependentes do dom´ınio. Esses tipos refletem diferentes necessidades do dom´ınio da aplicac¸˜ao e tamb´em os di- ferentes est´agios, dentro do ciclo de desenvolvimento do framework, nos quais o componente foi introduzido. Os componentes elementares, tais como mecanismo para comunicac¸˜ao e concorrˆencia l´ogica, determinam os elementos da arquitetura nos quais deve-se escrever toda a aplicac¸˜ao. Os elementos de projeto b´asico s˜ao classes intermedi´arias e praticamente independentes da aplicac¸˜ao, embora sejam concebidos com um dom´ınio espec´ıfico em mente. Os demais componentes s˜ao dependentes do dom´ınio e, em geral, s˜ao especializac¸˜oes dos componentes b´asicos.

2.6 Abordagens para Construc¸˜ao de frameworks 29