cobertas, mas desej´aveis de serem incorporadas ao framework e `a linguagem de padr˜oes. Para n˜ao poluir o diagrama da Figura 8.1, optou-se por n˜ao acrescentar as setas de retorno para representar a iteratividade do processo.
3.3
O Processo de Construc¸ ˜ao da Linguagem de Padr ˜oes
O primeiro passo do processo proposto consiste em um sub-processo para construc¸˜ao de uma lin- guagem de padr˜oes para um dom´ınio espec´ıfico. Deve-se ressaltar que tal linguagem de padr˜oes ´e composta de padr˜oes de an´alise, cada qual contendo um ou mais diagramas de classe que ilus- trem a(s) soluc¸˜ao(˜oes) para o problema em quest˜ao. ´E tamb´em desej´avel que sejam fornecidos os relacionamentos entre os padr˜oes que comp˜oem a linguagem de padr˜oes resultante, podendo ser denotados por um grafo ou, mais informalmente, por uma sec¸˜ao “Pr´oximos padr˜oes” adicionada em cada um dos padr˜oes.
A Figura 8.2 mostra os sub-passos necess´arios para construc¸˜ao de uma linguagem de padr˜oes, apresentados nas sec¸˜oes seguintes. A vers˜ao aqui exposta foi obtida ap´os o refinamento de uma vers˜ao preliminar, proposta durante um trabalho de mestrado (R´e e Masiero, 2002). O passo 1.1 da Figura 8.2 encontra-se mais detalhado no trabalho de mestrado mencionado, que teve seu enfoque principal na fase de engenharia reversa para obtenc¸˜ao do modelo do dom´ınio. Aqui, essa atividade ´e apresentada de maneira mais geral, podendo ser feita por meio de engenharia reversa ou por an´alise de dom´ınio. Foram feitas algumas melhorias nos passos 1.2 a 1.5 da Figura 8.2 desde a publicac¸˜ao da dissertac¸˜ao de mestrado, acrescentando mais sugest˜oes para tornar esses passos mais f´aceis de serem seguidos por desenvolvedores de linguagens de padr˜oes.
Conhecimento sobre linguagens de padrões Linguagem de Padrões Conhecimento sobre linguagens de padrões Experiência com outras linguagens de padrões Padrões de análise existentes Conhecimento sobre padrões Conhecimento sobre o domínio Experiência em um domínio específico Sistemas Específicos Modelo de Análise do Domínio Análise de Domínio ou Engenharia Reversa Determinação dos Padrões Passo 1.1 Passo 1.2 Passo 1.3 Grafo de fluxo de Aplicação Padrões da Linguagem Escrita dos padrões Conhecimento
sobre o domínio Passo 1.4
Validação da linguagem de padrões Linguagem de Padrões Passo 1.5 Modelo de análise de sistemas específicos Especificação de requisitos de sistemas do domínio Criação de um grafo de fluxo de aplicação dos padrões
3.3 O Processo de Construc¸˜ao da Linguagem de Padr˜oes 39
3.3.1
An ´alise de Dom´ınio ou Engenharia Reversa
Conforme visto na sec¸˜ao 2.2.1, padr˜oes s˜ao documentados a partir de experiˆencia no desenvol- vimento de software. Portanto, para construir uma linguagem de padr˜oes que abranja aplicac¸˜oes em um dado dom´ınio, ´e necess´ario observar as soluc¸˜oes comumente empregadas para resolver problemas recorrentes desse dom´ınio.
Assim, o ponto de partida para criac¸˜ao de uma linguagem de padr˜oes ´e obter um modelo que represente o dom´ınio alvo, ou seja, capte a funcionalidade presente na grande maioria das aplicac¸˜oes do dom´ınio. Isso pode ser conseguido de diversas maneiras: pode ser conduzida a an´alise do dom´ınio, utilizando t´ecnicas como a descrita por Gomaa (Gomaa, 1996) ou aquelas se- lecionadas por Prieto-Diaz (Prieto-Diaz e Arango, 1991); pode ser realizada a engenharia reversa de aplicac¸˜oes do dom´ınio, similarmente ao que foi feito para o dom´ınio de leil˜oes virtuais por R´e et. al. (R´e et al., 2001); ou pode ser utilizada a pr´opria experiˆencia pr´atica de desenvolvimento de aplicac¸˜oes no dom´ınio, o que pode ser considerado uma combinac¸˜ao das duas alternativas anteri- ores, pois as informac¸˜oes que o engenheiro de software possui sobre aplicac¸˜oes j´a desenvolvidas s˜ao similares ao resultado que se obteria via engenharia reversa, e tais informac¸˜oes devem ser utilizadas na construc¸˜ao de um modelo de an´alise do dom´ınio.
Uma das maneiras de conseguir reunir informac¸˜oes sobre as funcionalidades b´asicas do dom´ı- nio ´e por meio da engenharia reversa de alguns sistemas j´a existentes. Para tal, ´e necess´ario que a engenharia reversa produza modelos intermedi´arios representando cada um desses sistemas, para depois avanc¸ar para um processo de generalizac¸˜ao dos modelos que culminar´a com o modelo de an´alise do dom´ınio (R´e et al., 2001).
Independentemente da forma utilizada para conseguir as informac¸˜oes sobre o dom´ınio, o resul- tado desse passo ´e o modelo de an´alise do dom´ınio, que para a proposta desta tese, ´e constitu´ıdo de um modelo est´atico e de um modelo dinˆamico. O modelo est´atico pode ser expresso usando uma notac¸˜ao orientada a objetos, como por exemplo o modelo de classes da UML (do inglˆes Unified Modeling Language) (Rational, 2000). Nele, cada classe possui como atributos e m´etodos somente
aqueles que forem comuns ao dom´ınio, com nomes gen´ericos que devem ser explicados em um gloss´ario do dom´ınio. O relacionamento entre as classes tamb´em pode possuir nomes gen´ericos que reflitam a semˆantica inerente ao dom´ınio. O modelo dinˆamico pode ser expresso, por exemplo, pelo diagrama de seq¨uˆencia da UML, que mostra como funciona a comunicac¸˜ao entre os objetos para implementar as operac¸˜oes do sistema, sendo tamb´em definido com nomes gen´ericos.
3.3.2
Determinac¸ ˜ao dos Padr ˜oes
O modelo de an´alise do dom´ınio, resultante do passo anterior, ´e utilizado para definir os padr˜oes da linguagem de padr˜oes (passo 1.2). Essa atividade depende bastante do conhecimento e experiˆencia
3.3 O Processo de Construc¸˜ao da Linguagem de Padr˜oes 40 sobre padr˜oes do desenvolvedor da linguagem de padr˜oes. Entretanto, algumas recomendac¸˜oes devem ser seguidas para que os padr˜oes sejam definidos de forma uniforme e com maior possibi- lidade de reuso:
1. Padr˜oes de an´alise existentes na literatura devem ser analisados. ´E prov´avel que alguns deles estejam presentes no modelo de an´alise do dom´ınio tratado. No caso de serem en- contrados esses padr˜oes, o problema resolvido por eles deve ser especializado para o caso de tal dom´ınio e o padr˜ao deve receber um novo nome que reflita o problema espec´ıfico do dom´ınio.
2. Outras linguagens de padr˜oes de an´alise, para dom´ınios similares, devem ser estudadas, observando quais s˜ao seus padr˜oes constituintes, como est˜ao documentados e como se rela- cionam entre si. Isso contribui para o conhecimento sobre padr˜oes e aumenta as chances do desenvolvedor da linguagem de padr˜oes definir os padr˜oes de forma correta e mais f´acil de reusar por outros usu´arios da linguagem de padr˜oes. Nesse momento, pode-se optar por um formato para os padr˜oes, ou pelo menos identificar dois ou trˆes formatos mais apropriados. 3. A determinac¸˜ao dos padr˜oes deve iniciar pela an´alise das classes b´asicas do modelo de
dom´ınio obtido no passo anterior. Classes b´asicas s˜ao aquelas que est˜ao envolvidas nas func¸˜oes b´asicas ou principais representadas no modelo do dom´ınio, ou seja, aquelas que est˜ao presentes em todos os sistemas desse dom´ınio.
4. As classes b´asicas devem ser estudadas em busca de grupos de duas ou mais classes que se- jam respons´aveis por func¸˜oes importantes no sistema. Isso pode ser feito no pr´oprio modelo de classes do dom´ınio, por exemplo destacando-as com uma cor diferente, ou criando-se modelos menores referentes a cada func¸˜ao. Esses grupos de classes b´asicas representar˜ao os principais padr˜oes da linguagem, j´a que cada padr˜ao deve referir-se a uma func¸˜ao espec´ıfica realizada no dom´ınio. Isso facilita o reuso, pois conduz a padr˜oes com problemas/soluc¸˜oes sucintos e objetivos.
5. As classes complementares, diferentemente das classes b´asicas, adicionam melhorias em relac¸˜ao a um padr˜ao, ou adicionam uma func¸˜ao diferente em relac¸˜ao `as func¸˜oes b´asicas do modelo do dom´ınio. As classes complementares geralmente representam funcionalidades que s˜ao opcionais para o funcionamento de sistemas do dom´ınio estudado. Assim, classes complementares tˆem maior possibilidade de serem padr˜oes opcionais, ou de se juntarem a padr˜oes j´a existentes na linguagem, formando variantes dos padr˜oes principais e se tornando elementos opcionais dos padr˜oes principais. Novamente, fica a cargo do analista a decis˜ao de como estabelecer quais classes fazem parte de um padr˜ao. A existˆencia de padr˜oes op-
3.3 O Processo de Construc¸˜ao da Linguagem de Padr˜oes 41 cionais permite que eles sejam ignorados durante o uso da linguagem de padr˜oes, caso a funcionalidade por eles coberta n˜ao for necess´aria na aplicac¸˜ao espec´ıfica.
6. Cada padr˜ao deve receber um nome que deve abstrair o conte´udo do padr˜ao, facilitando sua identificac¸˜ao e utilizac¸˜ao por outros analistas. Uma forma de facilitar a nomeac¸˜ao do padr˜ao ´e por meio da observac¸˜ao de suas func¸˜oes. O nome escolhido deve ser significativo o suficiente para que sua simples citac¸˜ao traga consigo o valor semˆantico envolvido no pro- blema que o padr˜ao resolve. Podem ser utilizadas met´aforas ou express˜oes, desde que sejam conhecidas no dom´ınio coberto pela linguagem de padr˜oes.
7. Ap´os identificar e nomear os padr˜oes, uma tabela pode ser elaborada contendo apenas o nome do padr˜ao, o problema resolvido e uma s´ıntese da soluc¸˜ao proposta. Essa tabela ajuda o desenvolvedor da linguagem de padr˜oes a manter-se fiel aos seus objetivos para cada um dos padr˜oes e ser´a utilizada tanto na criac¸˜ao do grafo da linguagem de padr˜oes quanto durante a fase de escrita dos padr˜oes.
3.3.3
Criac¸ ˜ao de um grafo de fluxo de aplicac¸ ˜ao dos padr ˜oes
O terceiro passo para a construc¸˜ao da linguagem de padr˜oes ´e a an´alise da interac¸˜ao entre os diversos padr˜oes que a comp˜oem. Deve-se estabelecer a ordem na qual os padr˜oes devem ser aplicados, de forma a facilitar a modelagem de sistemas usando a linguagem de padr˜oes. Al´em disso, deve-se mostrar quais s˜ao os padr˜oes principais e opcionais da linguagem, informac¸˜oes que s˜ao obtidas por interm´edio da descric¸˜ao geral do padr˜ao. ´E importante salientar que o grafo deve indicar a interac¸˜ao entre os padr˜oes, mas n˜ao tem a intenc¸˜ao de mostrar como ´e a ordem de funcionamento do sistema resultante.
Uma das estrat´egias para criar o grafo ´e iniciar pelos padr˜oes que representam as funciona- lidades mais b´asicas do dom´ınio, e acrescentar, de forma gradual, os padr˜oes que correspondem `as funcionalidades mais espec´ıficas, terminando com os padr˜oes que s˜ao opcionais, ou seja, os padr˜oes que representam problemas nem sempre encontrados em aplicac¸˜oes do dom´ınio. En- tretanto, deve-se avaliar com cuidado o melhor local para posicionar os padr˜oes opcionais, pois muitas vezes eles dependem da aplicac¸˜ao de algum padr˜ao obrigat´orio e devem ser aplicados logo na seq¨uencia desses.
Al´em de elaborar um diagrama ou grafo para ilustrar a interac¸˜ao entre os padr˜oes, ´e desej´avel repetir essa informac¸˜ao sobre a interac¸˜ao por meio de uma sec¸˜ao em cada padr˜ao, denominada “Pr´oximos Padr˜oes”. O intuito principal ´e guiar o usu´ario da linguagem de padr˜oes a respeito dos pr´oximos padr˜oes que ele deve considerar ap´os ter aplicado ou n˜ao determinado padr˜ao.
O fluxo de aplicac¸˜ao dos padr˜oes, al´em de ser influenciado pelos padr˜oes opcionais, tamb´em pode ser influenciado por outros elementos dos padr˜oes, como por exemplo, os variantes, as clas-
3.3 O Processo de Construc¸˜ao da Linguagem de Padr˜oes 42 ses e os elementos opcionais. Podem ocorrer casos em que a aplicac¸˜ao de um determinado padr˜ao implica na adic¸˜ao de elementos em outros padr˜oes, outros casos em que a aplicac¸˜ao de um padr˜ao exige a aplicac¸˜ao de outro padr˜ao ou, ainda, casos em que um padr˜ao pode ser aplicado somente se outro padr˜ao for aplicado tamb´em. Dependendo da notac¸˜ao utilizada para representar o grafo, tal- vez essas situac¸˜oes n˜ao consigam ser mostradas diretamente no grafo, sendo ent˜ao documentadas apenas na sec¸˜ao “Pr´oximos Padr˜oes” de cada padr˜ao.
3.3.4
Escrita dos Padr ˜oes
No passo 1.4 s˜ao escritos os padr˜oes da linguagem de padr˜oes. O analista deve estabelecer um padr˜ao para descrever os padr˜oes da linguagem, como por exemplo, “nome”, “contexto”, “pro- blema”, “estrutura”, “participantes”, “padr˜oes relacionados” e “pr´oximos padr˜oes”, entre outros. Existem v´arias propostas de formatos de padr˜oes, dentre elas as sugeridas por Alexander et al. (1977), Appleton (1997) e Meszaros e Doble (1998). Independentemente do formato adotado, os componentes b´asicos de um padr˜ao devem estar presentes, que s˜ao:
• nome: deve ser relacionado com a intenc¸˜ao do padr˜ao;
• contexto: deve descrever como e quando o padr˜ao pode ser aplicado;
• problema: deve descrever, de maneira direta, o problema que o padr˜ao se prop˜oe a resolver, frente ao contexto anteriormente especificado;
• forc¸as: deve mostrar quais s˜ao os fatores que, frente ao contexto especificado e ao problema estabelecido, influenciam a soluc¸˜ao proposta e como ela ´e implementada. Tamb´em pode apresentar limitac¸˜oes e restric¸˜oes da soluc¸˜ao, desvantagens em utilizar o padr˜ao ou o porquˆe da soluc¸˜ao n˜ao utilizar outras estrat´egias;
• soluc¸˜ao: pode ser escrito de v´arias formas, desde que apresente de maneira clara a soluc¸˜ao proposta pelo padr˜ao. Podem ser criadas ilustrac¸˜oes da soluc¸˜ao, com sub-sec¸˜oes para des- crever os participantes da soluc¸˜ao bem como a colaborac¸˜ao entre eles.
Escolhido o formato do padr˜ao, sua escrita deve basear-se na descric¸˜ao geral dos padr˜oes e nas classes que comp˜oem os padr˜oes, obtidas no passo 1.2. ´E importante notar que um padr˜ao ´e muito mais que uma estrutura de classes e uma descric¸˜ao sobre elas, ele apresenta basicamente todas as informac¸˜oes do contexto no qual pode ser aplicado, o problema que resolve, bem como as forc¸as que atuam para formar a soluc¸˜ao (Fowler, 1997).
Com o objetivo de melhorar os padr˜oes da linguagem, o analista pode pesquisar outros padr˜oes do mesmo dom´ınio ou de um dom´ınio pr´oximo. Durante essa pesquisa, o analista pode descobrir
3.4 Processo de Uso de uma Linguagem de Padr˜oes 43