Este diagrama ´e tamb´em representado com a nota¸c˜ao UML para diagramas de classes. Representa um diagrama de alto n´ıvel para o software em an´alise. Este tipo de diagramas ´e obtido pelo processo de transforma¸c˜ao de diagramas PSM,
6.3. DESCRI ¸C ˜AO DETALHADA DA APLICA ¸C ˜AO DA FERRAMENTA 103
Figura 6.6: Diagrama de classes UML (PSM) para projecto mais complexo.
j´a apresentados.
Agenda
Partindo do mesmo ecr˜a de pr´e-processamento anteriormente mostrado (na Fi- gura 6.3) ´e poss´ıvel tamb´em inferir o diagrama PIM. O utilizador apenas tem de seleccionar a op¸c˜ao PIM e o diagrama ´e apresentado ao utilizador. Foi utilizado todo o c´odigo fonte do software em quest˜ao para permitir visualizar as diferentes transforma¸c˜oes que ocorrem neste processo. Terminado o processo, mostra-se na Figura 6.7 na parte inferior o PIM resultante e na parte superior o diagrama de classes PSM original, para que se possa perceber as diferen¸cas entre os dois diagramas.
Comparando os dois modelos na figura ´e poss´ıvel perceber as v´arias trans- forma¸c˜oes que ocorreram, vendo facilmente que o PSM foi abstra´ıdo a um PIM. Podemos ver m´etodos e elementos que foram eliminados e simplificados, tal como esperado. Estas transforma¸c˜oes seguem as regras de transforma¸c˜ao de PSM em PIM descritas previamente.
´
E desta forma que se demonstra a possibilidade de implementar a funci- onalidade de abstrac¸c˜ao de diagramas, que soluciona o problema de “Permitir abstrair os diagramas PSM a PIM”. As decis˜oes previamente tomadas mostram- se suficientes para permitir a implementa¸c˜ao desta funcionalidade. Mais uma vez esta funcionalidade ´e completamente automatizada.
Figura 6.7: Diagramas PSM (em cima) e PIM (em baixo) gerados.
JHotDraw
Para projectos de maiores dimens˜oes este processo ´e efectuado da mesma forma. Tal como no caso anterior do PSM, estes diagramas s˜ao dinˆamicos o que facilita a an´alise de projectos de grandes dimens˜oes. Esta funcionalidade ´e t˜ao v´alida para projectos pequenos como para projectos de maiores dimens˜oes. Na Figura 6.8 ´e poss´ıvel ver estas mesmas transforma¸c˜oes aplicadas a classes do projecto JHotDraw.
6.3.5
Inferˆencia de padr˜oes
Esta funcionalidade soluciona o ´ultimo problema dos que a ferramenta se prop˜oe a solucionar. Esta ´e a funcionalidade de an´alise de c´odigo de mais alto n´ıvel, que corresponde `a possibilidade de inferˆencia de padr˜oes num software.
6.3. DESCRI ¸C ˜AO DETALHADA DA APLICA ¸C ˜AO DA FERRAMENTA 105
Figura 6.8: Diagrama PSM (em cima) e PIM (em baixo) gerados para um sub- conjunto das classes deJHotDraw.
Agenda
A ´ultima funcionalidade dispon´ıvel no menu de pr´e-processamento ´e a inferˆen- cia de padr˜oes na representa¸c˜ao interm´edia. Para utilizar esta funcionalidade, a partir do ecr˜a de pr´e-processamento, o utilizador tem de seleccionar a op¸c˜ao Patterns. Depois tem de seleccionar uma de duas op¸c˜oes: usar o cat´alogo embu-
tido ou especificar a localiza¸c˜ao de um cat´alogo externo, como representado na Figura 6.9.
Figura 6.9: Escolha de padr˜oes na janela de pr´e-processamento.
Caso o utilizador escolha o cat´alogo disponibilizado pela ferramenta o pro- cesso de detec¸c˜ao pode iniciar: identifica os padr˜oes caso existam e faz a sua listagem, representado na Figura 6.10. O utilizador pode seleccionar um dos padr˜oes listados e ele ser´a representado visualmente.
Figura 6.10: Listagem com um padr˜ao Composite identificado.
Quando o utilizador seleccionar um cat´alogo externo ter´a de indicar o ca- minho para um ficheiro textual que cont´em a informa¸c˜ao desse cat´alogo. Neste caso foi utilizado o cat´alogo apresentado na Figura 6.13 que cont´em o padr˜ao Composite. Nessa mesma figura ´e mostrado um mapeamento entre o padr˜ao des- crito e a sua representa¸c˜ao visual para que seja mais f´acil perceber a defini¸c˜ao
6.3. DESCRI ¸C ˜AO DETALHADA DA APLICA ¸C ˜AO DA FERRAMENTA 107 do padr˜ao. Mais `a frente ser´a descrito de que modo ´e feito o mapeamento de cada um dos elementos do padr˜ao a um elemento Prolog do cat´alogo.
JHotDraw
A dimens˜ao do software em an´alise n˜ao ´e impedimento para a utiliza¸c˜ao deste m´odulo. Para software de maiores dimens˜oes ´e normal que a quantidade de pa- dr˜oes encontrados seja maior (vis´ıvel na Figura 6.11). A listagem de padr˜oes inferidos mostra-se muito ´util neste caso por organizar convenientemente os pa- dr˜oes.
Tal como nos diagramas PSM, tamb´em nas op¸c˜oes dos padr˜oes est´a dis- pon´ıvel a funcionalidade Simplify. Neste contexto esta funcionalidade permite ter uma vis˜ao mais global sobre os padr˜oes existentes em softwares de grandes dimens˜oes, como se pode ver na Figura 6.12.
Figura 6.11: Listagem de padr˜oes inferidos em JHotDraw.
Especifica¸c˜ao de um padr˜ao
Na Figura 6.13 est´a representado o padr˜aoComposite. Aparece descrito por um lado sob a forma de factos Prolog que s˜ao no fundo uma entrada do cat´alogo (do lado esquerdo). Por outro lado ´e apresentada uma imagem representando graficamente esse padr˜ao em nota¸c˜ao UML (do lado direito). Para cada um dos mapeamentos ser´a feita de seguida uma descri¸c˜ao.
1. Esta regra define que um elemento (Component) ´e uma classe. Esta regra ´e utilizada para definir as classes que existem num sistema.
Figura 6.12: Visualiza¸c˜ao de informa¸c˜ao sobre padr˜oes em JHotDraw, de forma simplificada.
Figura 6.13: Explica¸c˜ao da defini¸c˜ao de padr˜oes.
2. 3. Esta ´e a regra que define a rela¸c˜ao de heran¸ca entre dois elementos. Temos que Composite e Leaf herdam de Component. As rela¸c˜oes de heran¸ca s˜ao especificadas desta forma.
4. Este conjunto de regras permite duas representa¸c˜oes do mesmo padr˜ao. Nesta regra permite que Component seja um interface concretizado por AbstractComponent , ao contr´ario do que acontece em 1 onde Component ´e uma classe.
5. Aqui ´e definida a regra que especifica a rela¸c˜ao de implementa¸c˜ao (em que AbstractComponent implementa o interface Component).
6. 7. Tal como em 2 e 3, esta regra define a rela¸c˜ao de heran¸ca. Neste caso Composite e Leaf herdam de AbstractComponent.
8. 9. `A semelhan¸ca de 1, esta regra define que um elemento (Composite e Leaf) ´e uma classe.
6.3. DESCRI ¸C ˜AO DETALHADA DA APLICA ¸C ˜AO DA FERRAMENTA 109 10. Esta regra define que um elemento Composite cont´em (um ou mais) Com- ponent. Esta regra define a existˆencia de uma rela¸c˜ao de agrega¸c˜ao, com- posi¸c˜ao ou associa¸c˜ao entre dois elementos.
11. Esta regra define que os elementos n˜ao podem unificar com eles mesmos, por exemplo uma classe n˜ao pode ter simultaneamente o papel de Compo- nent e Leaf. ´E importante referir estas restri¸c˜oes, ou os resultados podem n˜ao corresponder ao esperado.
Esta ´e uma regra de exemplo e apresentada o padr˜aoComposite. Demonstra a flexibilidade do formato de defini¸c˜ao de padr˜oes. As capacidades da lingua- gem Prolog fazem com que esta regra possa cobrir duas varia¸c˜oes do padr˜ao. A capacidade de representar as duas varia¸c˜oes baseia-se no operando “ou”, escrito em Prolog com ;. Neste caso ´e definido o padr˜ao Composite onde podemos ter Component como classe, ou Component como interface, e neste caso um Abs- tractComponent que implementa Component. Se Component for uma classe vai haver classes que estendem dela, como Composite e Leaf. Se por outro lado Component for um interface estas classes v˜ao estender a sua implementa¸c˜ao, AbstractComponent. Gra¸cas `a utiliza¸c˜ao do operando “ou”, vemos que facil- mente se pode fazer uma defini¸c˜ao mais gen´erica de um padr˜ao que abrange duas variantes. Esta ´e a forma que permite ter uma maior ou menor restri¸c˜ao quando definimos uma regra, determinando assim se ser˜ao identificados mais ou menos padr˜oes.
Se todas as restri¸c˜oes da regra forem satisfeitas, ent˜ao estamos perante a presen¸ca de um padr˜ao. Um cat´alogo poder´a conter mais que uma defini¸c˜ao, permitindo assim identificar assim v´arios padr˜oes diferentes.
Se uma regra for demasiada restritiva, o mesmo padr˜ao poder´a aparecer v´arias vezes. Suponhamos um padr˜ao que consiste apenas na rela¸c˜ao de im- plementa¸c˜ao, o padr˜ao implements. Este padr˜ao define-se como havendo um interface que pode ter uma ou mais implementa¸c˜oes. Contudo, a regra do pa- dr˜ao est´a definida para um interface que possui uma s´o implementa¸c˜ao:
implements(Interface,Classe) :- class(Classe), interface(Interface), implements(Class,Interface).
Como esta regra ´e demasiado restrita, no caso de termos por exemplo trˆes classes que implementam um interface, ser˜ao inferidos trˆes padr˜oes (Figura 6.14). Podemos tamb´em ver que em JHotDraw foram identificados dois padr˜oes no mesmo conjunto de subclasses na Figura 6.15.
Depois de especificado o cat´alogo de padr˜oes, ´e altura de fazer an´alise da representa¸c˜ao interm´edia de dados e mostrar ao utilizador que padr˜oes foram inferidos nessa representa¸c˜ao. No caso em quest˜ao foi pesquisado e identificado o padr˜ao Composite, apresentado na Figura 6.10. Assim que o utilizador se- lecciona o padr˜ao na lista, ´e mostrado num diagrama similar ao PSM, com os
Figura 6.14: Identifica¸c˜ao do mesmo padr˜ao v´arias vezes.
Figura 6.15: Dois padr˜oes no mesmo diagrama: Decorator (em cima) e Composite (em baixo).
elementos que fazem parte do padr˜ao real¸cados ou caso deseje, simplificado como apresentado na Figura 6.16.
6.3. DESCRI ¸C ˜AO DETALHADA DA APLICA ¸C ˜AO DA FERRAMENTA 111
Figura 6.16: Duas representa¸c˜oes do padr˜ao Composite: normal (em cima) e simplificada (em baixo).
A implementa¸c˜ao desta funcionalidade mostra que a integra¸c˜ao da funci- onalidade de inferˆencia e representa¸c˜ao de padr˜oes de concep¸c˜ao num software pode ser integrada com as funcionalidades de inferˆencia de modelos. Mostra-se tamb´em que ´e poss´ıvel integrar uma tecnologia externa no processo, neste caso Prolog, e que esta se mostra uma mais valia obtendo resultados esperados. Foi ainda apresentada uma concretiza¸c˜ao de um cat´alogo de padr˜oes que demonstra a facilidade da sua defini¸c˜ao. Na implementa¸c˜ao deste m´odulo foi reaproveitado algum do trabalho previamente feito, nomeadamente com a representa¸c˜ao inter- m´edia de dados e representa¸c˜ao visual. Esta ´e a funcionalidade que soluciona o problema de, com base numa representa¸c˜ao interm´edia de um software “Inferir padr˜oes de concep¸c˜ao nessa representa¸c˜ao”. Por fim ´e apresentado o interface que se mostra f´acil de utilizar e n˜ao exige esfor¸co por parte do utilizador para adapta¸c˜ao ao mesmo.