Astah Community: Verificando nomenclatura para classes

Em um artigo publicado anteriormente no website da DevMedia, foram apresentados os primeiros passos para o desenvolvimento de plug-ins para Astah* [1].

Naquela publicaç�o, comentou-se sobre algumas limitaç�es do plug-in desenvolvido como estudo de caso, s�o elas:

Como pode ser notado, o plug-in desenvolvido (Validator) neste artigo apresenta diversas limitaç�es, tais como: i) s� realiza um tipo de verificaç�o de violaç�o de convenç�es de nomenclatura; ii) a estrat�gia utilizada para exibiç�o dos erros de verificaç�o � bastante limitada, principalmente para projetos que apresentam muitas classes; iii) para efetuar a verificaç�o de um diagrama, o usu�rio precisa sempre acionar o menu Class Validator; e iv) h� strings utilizadas na classe TemplateAction que n�o adv�m do arquivo plugin.properties, violando assim, a internacionalizaç�o do plug-in [1].

Saiba tudo sobre Engenharia de Software aqui na DevMedia

Este artigo visa a minimizar tais limitaç�es, aprimorando o projeto do plug-in Validator. Para isso, aprenderemos a realizar outros tipos de verificaç�es de nomenclatura para classes, como por exemplo, se os identificadores das classes possuem espaços em branco. Al�m disso: i) veremos como utilizar mecanismos mais adequados para apresentar os problemas de nomenclatura identificados pelo plug-in, utilizando views, tabelas de dados, entre outros recursos; ii) aprenderemos a realizar a verificaç�o de um diagrama de classes automaticamente, sempre que o projeto UML sofrer alguma modificaç�o, isto �, o usu�rio n�o precisar� acionar qualquer item de menu do plug-in Validator; e iii) faremos a internacionalizaç�o completa das mensagens utilizadas na interface do plug-in.

Para que voc� consiga acompanhar este artigo adequadamente, recomendo fortemente a leitura do artigo comentado anteriormente [1]. Desta forma, estarei assumindo que voc� j� possui o conhecimento necess�rio sobre: i) os principais conceitos para desenvolvimento de plug-ins para o Astah*, como por exemplo, sobre a instalaç�o e configuraç�o do ambiente de desenvolvimento; ii) os principais scripts do Astah Plug-in SDK; iii) os principais arquivos de um projeto de plug-in, como plug-in.xml; iv) os conceitos sobre extens�es; entre outros.

Importando o projeto do plug-in Validator

A partir do artigo dispon�vel em [1] voc� poder� baixar o c�digo-fonte do projeto do plug-in Validator e import�-lo no Eclipse. Para isso, siga o procedimento abaixo:

Passo 1: descompacte o arquivo validador.zip em seu workspace Eclipse.

Passo 2: abra o Eclipse. No menu principal, escolha a opç�o File � Import, depois selecione Existing Maven Projects e clique em Next. Na pr�xima tela, clique em Browse e busque pelo projeto validator. Uma vez encontrado o projeto, clique em Finish e o mesmo ser� automaticamente importado. Pronto! Agora j� podemos realizar alguns tipos de manutenç�o no plug-in Validator, a saber, manutenç�es evolutivas e corretivas.

Planejando as manutenç�es a serem realizadas

Segundo Sommerville [10], manutenç�es evolutivas visam a incorporar novas funcionalidades ao software, com o intuito de atender �s necessidades emergentes do cliente/usu�rio. J� as manutenç�es corretivas visam a eliminar falhas no produto de software. Outro tipo de manutenç�o bastante comum � a adaptativa, que visa a efetuar modificaç�es no software para adequ�-lo a um novo ambiente operacional, por exemplo, mudança de sistema operacional, entre outros.

Manutenç�es corretivas

No caso do plug-in Validator, temos dois defeitos que podem ser tornar falhas a qualquer momento. O primeiro est� no modo como os problemas de nomenclatura s�o apresentados ao usu�rio. Isso � feito por meio de uma caixa de di�logo, conforme pode ser visto na Figura 1.

Figura 1. Exibiç�o dos problemas de nomenclatura de um diagrama de classes.

Esse tipo de visualizaç�o � inadequado, principalmente para projeto com muitas classes. Quando h� muitas classes com problemas de nomenclatura, a caixa de di�logo pode n�o comportar o nome de todas elas, omitindo alguns nomes de classes com problemas do usu�rio.

Para resolver esse problema, trabalharemos com o conceito de views, que s�o pain�is extras adicionados � interface do Astah*. Tais pain�is oferecem recursos mais poderosos para manipulaç�o e visualizaç�o de dados, uma vez que permitem a utilizaç�o dos componentes de interface gr�fica comuns do Java, como JLabel, JButton, entre outros.

O segundo problema est� no c�digo fonte da vers�o original do plug-in Validator (Listagem 1).

Listagem 1. Trecho de c�digo da vers�o original do plug-in Validator.


  01. public Object run(IWindow window) throws UnExpectedException {
  02.     try {
  03.       ...
  04.       if (error != null)
  05.         JOptionPane.showMessageDialog(window.getParent(), error,
  06.           "Error", JOptionPane.ERROR_MESSAGE);
  07.       else
  08.         JOptionPane.showMessageDialog(window.getParent(),
  09.           "There are not errors!", "Success", JOptionPane.INFORMATION_MESSAGE);
  10.     } 
  11.     ...
  12. }
  13. 
  14. private String validate(IModel iCurrentProject) {
  15.     ...
  16.     for (IClass cl : classList) {
  17.       String name = cl.getName();
  18.       String upperCase = name.toUpperCase();
  19.       if (name.charAt(0) != upperCase.charAt(0)) {
  20.         error.append("[ERROR] Class: " + name + "\n"); hasError = true;
  21.       }
  22.     }
  23.     ...
  24. }

Observando-se o trecho de c�digo da Listagem 1, nota-se que as linhas 6, 9 e 20 utilizam strings que representam mensagens a serem exibidas ao usu�rio na interface do Astah*. O problema � que esse tipo de implementaç�o dificulta a internacionalizaç�o do plug-in, isto �, a traduç�o do texto da interface do mesmo para outros idiomas. O Astah Plug-in SDK oferece recursos para internacionalizaç�o de plug-ins [1], contudo esse recurso � utilizado apenas no arquivo plugin.xml para internacionalizaç�o dos itens de menu do plug-in.

Da forma como o c�digo encontra-se na Listagem 1, caso o desenvolvedor traduza o arquivo de internacionalizaç�o do plug-in Validator para o portugu�s, as mensagens que aparecem nas linhas 6, 9 e 20 continuar�o aparecendo em ingl�s. A �nica forma de mudar isso seria alterar o c�digo fonte do plug-in, reconstrui-lo e redistribuir aos usu�rios, o que n�o � nada trivial. Para sanar este problema, faremos a leitura do arquivo de propriedades do plug-in, no qual est�o localizadas as strings utilizadas na interface do Astah*, utilizando um recurso da plataforma Java conhecido como ResourceBundle.

Manutenç�es evolutivas

Uma manutenç�o evolutiva desej�vel para o plug-in Validator � permitir que ele faça novos tipos de verificaç�o, antes n�o contempladas pelo mesmo. Neste artigo, iremos realizar duas verificaç�es: i) se o identificador de uma classe n�o � um acr�nimo; e ii) se h� espaços em branco no identificador de uma classe.

A primeira convenç�o de nomenclatura � citada no guia de conveç�es de codificaç�o da Oracle [8] e a justificativa � que nomes de classes devem ser simples, mas descritivos, isto �, devem passar a ideia ao desenvolvedor do que trata aquela classe. Sendo assim, este guia sugere que o desenvolvedor evite a utilizaç�o de siglas e acr�nimos para nomear classes. Para verificar essa regras, observaremos se todas os caracteres do identificador da classe est�o em mai�scula, o que pode indicar que um acr�nimo est� sendo utilizado.

A segunda convenç�o tamb�m � citada no guia da Oracle [8], por�m est� mais ligada �s caracter�sticas de nomenclatura suportadas pela linguagem Java. Como voc� deve saber, em Java, identificadores de classes/interfaces, m�todos e atributos n�o podem conter espaços em branco. Para verificar essa regra, basta procurar por espaços em branco no identificador das classes. Caso haja, um erro deve ser reportado ao usu�rio.

Realizando as modificaç�es - Internacionalizaç�o

Para resolvermos o problema de internacionalizaç�o do plug-in, utilizaremos o recurso da pr�pria linguagem Java conhecido como ResourceBundle. Foge ao escopo deste aritgo fazer uma explanaç�o mais profunda sobre esse recurso; mais detalhes sobre ele podem ser encontrados em [2].

O importante � saber que a classe java.util.ResourceBundle � utilizada para armazenar textos (strings) que s�o sens�veis ao locale, isto �, textos que s�o internacionaliz�veis, podendo variar de acordo com o idioma configurado na m�quina do usu�rio. Este � o recurso necess�rio para internacionalizar os textos utilizados nas classes do plug-in Validator.

A forma de uso deste recurso � bastante simples. Inicialmente, precisamos obter ou criar um objeto do tipo Locale, que representa o idioma utilizado no sistema do usu�rio. Com este objeto em m�os, � poss�vel obter uma inst�ncia de ResourceBundle, que representa um arquivo de propriedades do sistema com as strings internacionalizadas. A partir deste momento, o usu�rio pode obter uma string internacionalizada invocando o m�todo getString da classe ResourceBundle. Este m�todo recebe como par�metro a chave da string que deve ser recuperada. Por exemplo, supondo que no arquivo de propriedades haja a entrada rotuloBotaoEnviar=Enviar, ao invocar o m�todo getString(�rotuloBotaoEnviar�), o usu�rio ir� receber string Enviar.

Para implementar esta funcionalidade, foram alterados os c�digos de duas classes do plug-in, a saber, Activator e TemplateAction. O trecho de c�digo alterado da classe Activator encontra-se na Listagem 2.

Listagem 2. Trecho de c�digo modificado da classe Activator.


  01. public class Activator implements BundleActivator {
  02.     
  03.  private static ResourceBundle resourceBundle;
  04. 
  05.   public void start(BundleContext context) {
  06.     initializeResourceBundle();
  07.   }
  08. 
  09.   private void initializeResourceBundle() {
  10.     Locale locale = Locale.getDefault();
  11.     resourceBundle = ResourceBundle.getBundle("plugin", locale);
  12.   }
  13. 
  14.   public static String getLabel(String key) {
  15.     return resourceBundle.getString(key);
  16.   } 
  17. }

A classe Activator possui dois m�todos pricipais, denominados start e stop. O primeiro m�todo � invocado automaticamente quando o plug-in � ativado no Astah* e o segundo, quando o mesmo � desativado.

Como os recursos de internacionalizaç�o podem ser utilizado em diversos pontos do c�digo do plug-in, optei por coloc�-lo na classe Activator. O m�todo initializeResourceBundle � respons�vel por identificar o locale padr�o do sistema do usu�rio (linha 10) e obter o arquivo plugin.properties apropriado (este � o arquivo com as string internacionaliz�veis de um plug-in Astah*). Por exemplo, se o locale for pt_BR, ent�o o m�todo getBundle da classe ResourceBundle (linha 11) tentar� obter o arquivo de propriedades plugin_pt_BR.properties. Caso n�o seja encontrado um arquivo espec�fico para o locale, o arquivo default � recuperado, isto �, plugin.properties.

Outro ponto a ser destacado na Listagem 2 � o m�todo getLabel (linhas 14 � 16). Ele recupera uma string do arquivo de propriedades do plug-in Validator a partir de uma chave passada por par�metro (linha 15). Para isso, ele utiliza o m�todo getString da classe ResourceBundle. O objeto do tipo ResourceBundle � recuperado a partir do atributo resourceBundle, da pr�pria classe Activator (linha 3). � importante ressaltar ainda que getLabel � um m�todo p�blico est�tico (m�todo de classe). Isto significa que o acesso a ele � realizado de forma direta, sem a necessidade de se ter um objeto da classe Activator instanciado para isso. Para invocar esse m�todo, basta utilizar Activator.getLabel(�chave�). Isso facilita o acesso ao mecanismo de internacionalizaç�o de qualquer ponto do projeto do plug-in.

O segundo trecho de c�digo a ser apresentado � o da classe TemplateAction, que encontra-se na Listagem 3. As linhas 6 e 9 deste c�digo fazem uso do m�todo getLabel da classe Activator para obter strings a serem apresentadas na interface do Astah* de forma internacionalizada.

Listagem 3. Trecho de c�digo modificado da classe TampleAction.


  01. public class TemplateAction implements IPluginActionDelegate {
  02.   public Object run(IWindow window) throws UnExpectedException {
  03.       ...
  04.   if (error != null) {                               
  05.         JOptionPane.showMessageDialog(window.getParent(), error,
  06.         Activator.getLabel("validationErrorsTitle"), JOptionPane.ERROR_MESSAGE);
  07.       } else {                               
 08.         JOptionPane.showMessageDialog(window.getParent(),
  09.           Activator.getLabel("successMessage"), Activator.getLabel("successTitle"),
  10.           JOptionPane.INFORMATION_MESSAGE);
  11.       }     
  12.       ...
  13.   }
  14.   ...       
  15. }

Para testar as alteraç�es que fizemos, criamos um arquivo plugin_pt_BR.properties (Listagem 4) e o adicionamos ao projeto do plug-in (na pasta main/resources). Posteriormente, traduzimos as strings existentes neste arquivo para portugu�s do Brasil e inicializamos nosso plug-in com as alteraç�es realizadas. Conforme explicado em [1], voc� pode inicializar o Astah* com seu plug-in carregado da seguinte forma:

..., basta mover-se ao diret�rio onde se encontra o projeto com o plug-in e digitar o comando astah-launch no console.

Listagem 4. Arquivo plugin_pt_BR.properties.


  pluginName = Validador de Diagramas de Classes
  providerName = by Paulo Afonso
   
  lb_group_validator=&Validador
  lb_item_classValidator=&Classes
  tooltip_item_classValidator=Valida a nomenclatura das classes existentes em seu projeto.
   
  validationErrorsTitle=Erros de Validaç�o
  successTitle=Sucesso
  successMessage=N�o h� erros neste projeto!
  projectNoOpened=N�o h� projetos abertos. Por favor, abra um projeto existente ou crie um novo.
  projectNoOpenedTitle=Atenç�o
  unexpectedError=Ocorreu um erro inesperado!
  unexpectedErrorTitle=Atenç�o
   
  validationErrorMessage=[ERRO] Classe:

Com isso, as modificaç�es s�o vis�veis na interface do Astah* (Figura 2), isto �, as strings utilizadas na interface do plug-in est�o todas em portugu�s, uma vez que meu locale est� configurado como portugu�s do Brasil. � importante notar que as strings dos outros itens de menus do Astah* continuam em ingl�s. Isso ocorre, pois eu n�o possuo o pacote de internacionalizaç�o da interface do Astah* para portugu�s. Mais detalhes de como obter e instalar este pacote podem ser encontrados em [9].

Figura 2. Interface do plug-in Validator internacionaliada.

Adicionando novos tipos de verificaç�o de nomenclatura

Adicionar novos tipos de verificaç�o � relativamente simples. Neste caso, vamos alterar o m�todo validate da classe TemplateAction, com o intuito de permitir que ele realize as verificaç�es desejadas. Conforme j� discutido anteriormente, os novos tipos de verificaç�o de nomenclatura s�o: i) verificar se o identificador de uma classe n�o � um acr�nimo; e ii) verificar se h� espaços em branco no identificador de uma classe.

Antes de apresentar o c�digo da classe TemplateAction, cabe ressaltar que o arquivo plugin.properties precisou ser modificado. Isso ocorreu, pois agora mais de um tipo de problema pode ser detecado pelo plug-in Validator e mensagens diferentes para cada tipo de problema devem ser apresentadas. Sendo assim, foram criadas strings espec�ficas para cada tipo de problema de nomenclatura, conforme pode ser visto ena Listagem 5.

Listagem 5. Arquivo plugin_pt_BR.properties modificado.


  ...
  validationErrorMessageFirstLetter=[ERRO] A primeira letra do nome de uma classe deve ser mai�scula:  
  validationErrorMessageAcronym=[ERRO] O nome de uma classe n�o deve ser um acr�nimo/sigla: 
  validationErrorMessageBlankSpace=[ERRO] O nome de uma classe n�o pode conter espaços em branco:

Ap�s alterar o c�digo do m�todo validate, o resultado � equivalente ao apresentado na Listagem 6. As linhas 4 � 8 j� existiam e serviam para verificar se o nome da classe inicia com letra mai�scula. A �nica mudança ocorreu na linha 7, na chamada do m�todo getLabel, para a qual foi passado como par�metro uma outra chave.

Listagem 6. Trecho de c�digo da classe TemplateAction modificado.


  01. private String validate(IModel iCurrentProject) {
  02.   ...
  03.   for (IClass cl : classList) {
  04.     String name = cl.getName();
  05.     String upperCase = name.toUpperCase();
  06.     if (name.charAt(0) != upperCase.charAt(0)) {
  07.       error.append(Activator.getLabel("validationErrorMessageFirstLetter") + name + "\n");
  08.       hasError = true;
  09.     } else if (upperCase.equals(name)) {
  10.       error.append(Activator.getLabel("validationErrorMessageAcronym") + name + "\n");
  11.       hasError = true;                             
  12.     } else if (name.contains(" ")) {
  13.       error.append(Activator.getLabel("validationErrorMessageBlankSpace") + name + "\n");
  14.       hasError = true;
  15.     }
  16.   }
  17.   ...
  18. }

As linhas 9 � 14 s�o respons�veis por verificar se o nome da classe � um acr�nimo (linhas 9 � 11) e se h� espaços em branco no nome da classe (linha 12 � 14).

Para testar a nova vers�o do plug-in Validator, foi criado o diagrama de classes fict�cio da Figura 3. Como pode ser observado, apenas a classe Class2 est� correta; as classes Class 1, class3 e CLASS4 apresentam problemas, conforme segue:

Class 1: apenas a primeira letra do nome da classe � mais�cula, por�m ele possui um espaço em branco entre �Class� e �1�;
class3: o nome da classe n�o possui espaços em branco, por�m n�o começa com letra mai�scula; e
CLASS4: o nome da classe n�o possui espaços em branco, por�m todas as letras do nome da classe s�o mai�scula, o que pode indicar que se trata de uma sigla ou acr�nimo.

Figura 3. Diagrama de classes fict�cio.

Ao executar o plug-in Validator sobre o diagrama de classes da Figura 3, por�m, ocorreu uma surpresa! Conforme pode ser visto na Figura 4, al�m dos erros j� comentados, apareceu um erro a mais, referindo-se a uma classe denominada UUID, acusando que o nome desta classe n�o pode ser um acr�nimo. Por�m, n�o criamos uma classe denominada UUID, o que ocorreu ent�o?

O que aconteceu � que quando criamos um projeto no Astah*, ele carrega automaticamente um conjunto de classes e interfaces comuns da plataforma Java, tais como String, Math, List, entre outras. Uma dessas classes � justamente a UUID que, segundo a documentaç�o da plataforma Java [3], representa um identificador �nico imut�vel de 128 bits. Este tipo de classe � muito utilizada para serializaç�o de objetos que precisam ser transportados via rede. Em suma, o plug-in Validator descobriu uma classe da API Java que vai de encontro a (contra) uma convenç�o da pr�pria Oracle, interessante n�o!?

Figura 4. Resultado da execuç�o da nova vers�o do plug-in Validator.

� importante notar que a maneira como implementamos esta nova funcionalidade n�o � a mais adequada em termos de flexibilidade. Veja que precisamos adicionar novos comandos if-else no c�digo da classe TamplateAction e, se seguirmos sempre esta estrat�gia, todas as vezes que um novo tipo de verificaç�o for incorporado, mais comandos if-else precisar�o ser adicionados ao c�digo, o que diminiu bastante sua flexibilidade. Uma maneira mais interessante de realizar verificaç�es de forma din�mica e flex�vel � por meio da implementaç�o do padr�o de projeto Chain of Responsability [4]. Tente fazer isso como exerc�o, utilize os coment�rios no final deste artigo para esclarecer d�vidas e trocar experi�ncias.

Trabalhando com views

No artigo �Desenvolvendo Plug-ins para o software Astah*� [1], foi apresentado um recurso de extens�o do Astah*, a saber, o actionSet, que permitia a confecç�o de novos itens de menu para a ferramenta.

Neste artigo, ser� visto outro mecanismo de extens�o conhecido como views. Eles s�o bem mais poderosos, uma vez que permitem ao desenvolvedor criar pain�is extras para a ferramenta Astah* e incluir nesses pain�is elementos de interface gr�fica bem conhecidos por quem trabalha com Java, tais como JLabel, JButton, JTable, entre outros.

Nossa ideia � criar um painel que permita uma apresentaç�o mais adequada dos problemas de nomenclatura identificados pelo plug-in Validator. A Figura 5 apresenta um prot�tipo da interface do que pretende-se implementar neste painel.

Figura 5. Prot�tipo do painel para visualizaç�o de problemas de nomenclatura.

Ser� criada uma tabela de dados, na qual: i) a primeira coluna apresenta o nome da classe com problemas de nomenclarura; e ii) a segunda e �ltima coluna apresenta o tipo de erro identificado pelo plug-in.

Para criar uma extens�o desse tipo, precisamos criar um ponto de extens�o por meio da tag extension, no arquivo plugin.xml. Esse ponto de extens�o deve conter o valor com.change_vision.astah.ui.view atribu�do ao atributo point da tag extension. Esse id � definido pelo pr�prio Astah Plug-in SDK; mais detalhes sobre os ids utilizados pelo SDK podem ser encontrados em [5].

A c�digo que deve ser incorporado ao arquivo plugin.xml encontra-se na Listagem 7. O atributo id refere-se a um identificador �nico para a sua view. O atributo type identifica o tipo de view a ser criado. Atualmente, o Astah Plug-in SDK permite apenas a criaç�o de views extras, que s�o apresentadas quando o usu�rio acessa o menu View � Show/Hide Extra View do Astah*. Para criar uma view extra, utilize o valor extraTab para o atributo type. O atributo class especifica a classe respons�vel pela criaç�o da view (dos componentes visuais) e do tratamento dos eventos que poder�o atualizar a interface desta view.

Listagem 7. Trecho de c�digo a ser incorporado no arquivo plugin.xml


  01. <extension point="com.change_vision.astah.ui.view">
  02.         <view
  03.             id="validatorView"
  04.             type="extraTab"
  05.             class="com.validator.ValidatorView" />
  06. </extension>

A Listagem 8 apresenta os trechos de c�digo mais importantes da classe ValidatorView, melhor detalhados a seguir. Os dois primeiros fatos que precisam ser observados � que esta classe deve herda da classe JPanel e implementa as interfaces IPluginExtraTabView, ProjectEventListener. Ela extende a classe JPanel, por se tratar de um painel que ser� apresentado pelo Astah* em uma aba extra de sua interface. O fato de implementar a interface IPluginExtraTabView obrigada o desenvolvedor a prover implementaç�o para alguns m�todos necess�rios para o Astah* poder tratar a view corretamente. Alguns desses m�todos s�o:

getTitle: permite ao Astah* conhecer o t�tulo que deve ser atribu�do � aba da view.
getComponent: permite ao Astah* capturar o painel que deve ser apresentado na tela da ferramenta.

O m�todo getTitle do nosso exemplo busca o t�tulo da view no arquivo de propriedades plugin.properties, de forma internacionalizada (linha 31). J� o m�todo getComponent retorna a pr�pria inst�ncia da classe ValidatorView, criada automaticamente pelo Astah* no momento da execuç�o do plug-in. O painel a ser exibido � constru�do por meio do m�todo initComponents.

Quanto � interface ProjectEventListener, ela serve para informar ao Astah* que sua view estar� observando as mudanças ocorridas no projeto UML, como a abertura e fechamento do projeto, as modificaç�es feitas em alguns elementos, entre outros. Assim como a interface IPluginExtraTabView, ProjectEventListener tamb�m obriga o desenvolvedor a implementar alguns m�todos, tais como:

projectChanged: notifica a vis�o de que o projeto UML do usu�rio foi modificaç�o;
deactivated: notifica a vis�o de que o projeto atual foi fechado pelo usu�rio; e
activated: notifica a vis�o de que um projeto foi aberto pelo usu�rio.

Listagem 8. Trecho de c�digo da classe ValidatorView.


  01. public class ValidatorView extends JPanel implements IPluginExtraTabView,
  02.   ProjectEventListener {
  03. 
  04.   public ValidatorView() {
  05.     initComponents();
  06.   }
  07. 
  08.   private void initComponents() {
  09.     setLayout(new BorderLayout());
  10.     add(createLabelPane(), BorderLayout.CENTER);
  11.     addProjectEventListener();
  12.   }
  13. 
  14.   private Container createLabelPane() {
  15.     JLabel label = new JLabel("hello world");
  16.     JScrollPane pane = new JScrollPane(label);
  17.     return pane;
  18.   }
  19. 
  20.   private void addProjectEventListener() {
  21.     try {
  22.       AstahAPI api = AstahAPI.getAstahAPI();
  23.       ProjectAccessor projectAccessor = api.getProjectAccessor();
  24.       projectAccessor.addProjectEventListener(this);
  25.     } catch (ClassNotFoundException e) {
  26.       System.err.println(Activator.getLabel("unexpectedError"));
  27.     }
  28.   }
  29.   @Override
  30.   public String getTitle() {
  31.     return Activator.getLabel("viewTitle");
  32.   }
  33.   @Override
  34.   public Component getComponent() {
  35.     return this;
  36.   }
  37.   @Override
  38.   public void projectChanged(ProjectEvent arg0) {
  39.     // TODO Auto-generated method stub
  40.   }
  41.  
  42.   @Override
  43.   public void activated() {  }
  44. 
  45.   @Override
  46.   public void deactivated() {  }  
  47.   ...
  48. }

Neste caso, estamos preocupados com a implementaç�o dos m�todos activated e projectChanged, uma vez que precisaremos verificar o projeto todas as vezes em que o mesmo for aberto ou que alguma modificaç�o for realizada sobre ele. Contudo, para que a vis�o seja notificada � necess�rio cadastr�-la como um observador do projeto (esta estrat�gia de implementaç�o utilizada pelo Astah* trata-se do conhecido padr�o de projeto Observer [6]). Isso � feito no m�todo addProjectEventListener, linha 24, por meio m�todo addProjectEventListener da classe ProjectAccessor, que representa o projeto atual aberto pelo usu�rio. Da forma como est� o c�digo da Listagem 8, a view criada apenas apresentar� um texto �hello world�, conforme pode ser visto na Figura 6. Para criar nossa tabela de dados, conforme o prot�tipo da Figura 5, precisamos alterar o c�digo da classe ValidatorView, conforme exibido na Listagem 9.

Figura 6. Apresentaç�o da view at� o momento.

Listagem 9. Trecho de c�digo da classe ValidatorView modificado.


  01. public class ValidatorView extends JPanel implements IPluginExtraTabView, ProjectEventListener {
  02.   private DefaultTableModel model = new DefaultTableModel(); 
  03.   private  JTable table = new JTable(model);
  04.   private IModel currentProject;
  05. 
  06.   private void initComponents() {
  07.     setLayout(new BorderLayout());
  08.     add(createDataTable(), BorderLayout.CENTER);
  09.     addProjectEventListener();
  10.   }
  11.   private Container createDataTable() {
  12.     model.addColumn(Activator.getLabel("colClass")); 
  13.     model.addColumn(Activator.getLabel("colError")); 
  14.     JScrollPane pane = new JScrollPane(table);
  15.     return pane;
  16.   }
  17.   private void updateTable() {
  18.     model.getDataVector().clear();
  19.     List<IClass> classList = new ArrayList<IClass>();
  20.     getAllClasses(currentProject, classList);
  21.     for (IClass cl : classList) {
  22.       String name = cl.getName();
  23.       String upperCase = name.toUpperCase();
  24.       if (name.charAt(0) != upperCase.charAt(0)) {
  25.         model.addRow(new Object[]{name, 
  26.           Activator.getLabel("validationErrorMessageFirstLetter")});
  27.       } else if (upperCase.equals(name)) {
  28.         model.addRow(new Object[]{name, 
  29.           Activator.getLabel("validationErrorMessageAcronym")});
  30.       } else if (name.contains(" ")) {
  31.         model.addRow(new Object[]{name, 
  32.           Activator.getLabel("validationErrorMessageBlankSpace")});
  33.       }
  34.     }
  35.   }  
  36.   private void getAllClasses(INamedElement element, List<IClass> classList) {
  37.     if (element instanceof IPackage) {
  38.       for (INamedElement ownedNamedElement : ((IPackage) element).getOwnedElements()) {
  39.        getAllClasses(ownedNamedElement, classList);
  40.       }
  41.     } else if (element instanceof IClass) {
  42.       classList.add((IClass) element);
  43.     }
  44.   }
  45.   private void addProjectEventListener() {
  46.     try {      
  47.       ...
  48.      currentProject = projectAccessor.getProject();
  49.       ...
  50.     } catch (ProjectNotFoundException e) {
  51.       System.out.println(Activator.getLabel("projectNoOpenedTitle"));
  52.     } catch (ClassNotFoundException e) {
  53.       System.out.println(Activator.getLabel("unexpectedError"));
  54.     }
  55.   }
  56.   public void activated() {
  57.     updateTable();
  58.   }
  59.   public void projectChanged(ProjectEvent arg0) {
  60.     updateTable();
  61.   }
  62. }

O m�todo getAllClasses � o mesmo apresentado em [1] e � respons�vel por vasculhar um projeto a procura de classes, colocando-as em uma lista denominada classList. O m�todo createDataTable constr�i a estrutura de uma tabela de dados em Java e a coloca sobre um componente do tipo ScrollPane, respons�vel por atribuir barras de rolagem � tabela sempre que for necess�rio. Conforme planejado em nosso prot�tipo, esta tabela deve conter duas colunas, uma para o nome da classe e outro para o problema de nomenclatura encontrado na classe em quest�o.

O m�todo updateTable � respons�vel por limpar os dados da tabela e preench�-la novamente com as informaç�es corretas, isto �, o nome das classes e seus respectivos problemas de nomenclatura. Este m�todo � invocado em dois momentos distintos: i) quando o projeto � aberto pelo usu�rio (linha 57); e ii) quando alguma modificaç�o � feita no projeto, como a criaç�o de um novo elemento, a mudança do nome de uma classe, entre outros (linha 60). Assim, o usu�rio n�o precisar� mais clicar em qualquer menu para realizar a verificaç�o de seu diagrama de classes UML, pois isso � feito automaticamente. Mais detalhes sobre a construç�o e atualizaç�o de tabelas de dados em Java podem ser encontrados em [6].

Outra mudança que fizemos em nosso projeto foi apagar o trecho de c�digo respons�vel pela criaç�o do menu do plug-in Validator, uma vez que precisamos mais dele, al�m de excluir a classe TamplateAction, que era respons�vel por tratar o evento de clique sobre o item de menu do plug-in. Novas atualizaç�es tamb�m foram realizadas no arquivo com as strings utilizadas na interface do plug-in, conforme pode ser visto na Listagem 10.

Listagem 10. �ltima vers�o do arquivo plugin.properties.


  ...
  validationErrorMessageFirstLetter=A primeira letra do nome de uma classe deve ser mai�scula.  
  validationErrorMessageAcronym=O nome de uma classe n�o deve ser um acr�nimo/sigla. 
  validationErrorMessageBlankSpace=O nome de uma classe n�o pode conter espaços em branco.  
   
  viewTitle=Erros de Nomenclatura
   
  colClass=Classe
  colError=Erro

Pronto! Agora, basta executar a vers�o final do plug-in. O resultado � similar ao apresentado na Figura 7.

Figura 7. Interface gr�fica da vers�o final plug-in Validator.

Neste artigo foram apresentadas estrat�gias para minimizar as limitaç�es existentes no plug-in desenvolvido no artigo [1]. Neste sentido, viu-se: i) como utilizar o mecanismo de extens�o view, do Astah Plug-in SDK; ii) como identificar novos tipos de problemas de nomenclatura em diagramas de classes UML; e iii) como internacionalizar por completo um plug-in Astah*.

Ainda assim, esta nova vers�o do plug-in Validator apresenta algumas limitaç�es, tais como: i) s� realiza verificaç�es sobre os nomes das classes, n�o levando em consideraç�o, m�todos, atributos, pacotes, associaç�es, entre outros elementos importantes de um diagrama de classes; ii) a tabela de dados s� apresenta o nome das classes. Neste sentido, se houver duas classes com o mesmo nome, por�m em pacotes diferentes, o que � poss�vel de ocorrer, o usu�rio ficar� confuso ao tentar localizar a classe com problema; iii) todos os tipos de verificaç�o s�o sempre inspecionados. O desenvolvedor pode desejar desabilitar algum tipo de verificaç�o por algum tempo para se concentrar em um problema espec�fico de cada vez; e iv) a tabela de dados n�o permite que usu�rio filtre os resultados por nome de classes ou por tipo de erro.

Acredita-se que com as informaç�es apresentadas neste artigo e no artigo anterior [1], juntamente com seu conhecimento sobre a linguagem Java, voc� conseguir� aprimorar este plug-in a ponto de mitigar as limitaç�es comentadas anteriormente.

Refer�ncias

[1] Desenvolvendo Plug-ins para o software Astah*. Dispon�vel em: https://www.devmedia.com.br/astah-desenvolvendo-plug-ins-para-o-software/31127

[2] Tutorial sobre utilizaç�o do ResourceBundle. Dispon�vel em: http://tutorials.jenkov.com/java-internationalization/resourcebundle.html

[3] Documentaç�o Java sobre a classe UUID. Dispon�vel em: http://docs.oracle.com/javase/7/docs/api/java/util/UUID.html

[4] Padr�o de projeto Chain of Responsability. Dispon�vel em: http://pt.wikipedia.org/wiki/Chain_of_Responsibility

[5] Tutorial para desenvolvimento de plug-ins no Astah*. Dispon�vel em: http://astah.net/tutorials/plug-ins/plugin_tutorial_en/html/index.html.

[6] Padr�o de projeto Observer. Dispon�vel em: http://en.wikipedia.org/wiki/Observer_pattern

[7] Documentaç�o JTable. Dispon�vel em: http://docs.oracle.com/javase/7/docs/api/javax/swing/JTable.html

[8] Oracle Code Convention. Dispon�vel em: http://www.oracle.com/technetwork/java/codeconvtoc-136057.html

[9] Recurso de internacionalizaç�o do Astah*. Dispon�vel em: http://astah.net/features/gui-localization

[10] Sommerville, Ian. Engenharia de Software. 9�. ediç�o. Pearson Prentice Hall, 529 p., 2011.