Astah: Desenvolvendo Plug-ins para o software

Um dos maiores desafios para a construção de um software está relacionado ao correto entendimento das necessidades do cliente, para que se possa então prover uma solução computacional capaz de atender a estas necessidades. Para que isso seja possível, o Engenheiro de Software precisa conhecer o domínio do problema para o qual o software está sendo desenvolvido, isto é, ele deve estar ciente dos termos, jargões, relacionamentos entre conceitos, desafios e demais informações existentes no ambiente do cliente/usuário.

Em alguns casos, este domínio do problema não é conhecido pelo Engenheiro de Software. Por exemplo, seria complicado para um Engenheiro de Software que sempre trabalhou com o desenvolvimento de software para o mercado de ações conhecer os termos, jargões, entre outras informações relacionadas ao domínio de aviação civil. Em outros casos, mesmo que se conheça o domínio do problema, este possui certas complexidades que dificultam sua compreensão. Por exemplo, entender a proposta de um algoritmo para definir o melhor momento para se comprar ou vender um determinado conjunto de ações pode não uma tarefa trivial de ser entendida.

Para melhor compreensão desse domínio, pode-se criar modelos do software. Segundo Sommerville [1], modelos são representações simplificadas de alguma coisa do mundo real, considerando suas características mais importantes e descartando as irrelevantes. Modelos são utilizados em diversas áreas, como na matemática, na física, na biologia, entre outras. Por exemplo, modelos matemáticos podem ser criados para analisar os efeitos dos ventos e tremores sobres casas e prédios. Modelos arquiteturais de casas e edifícios podem auxiliar seus futuros moradores a visualizarem como será o produto final.

Na área da Engenharia de Software, pode-se também criar modelos de um software, antes mesmo de ele ser efetivamente construído. Mas por que fazer Modelagem de Software? São, pelo menos, duas as razões [1]:

1. Para compreender melhor o sistema que estamos desenvolvendo. Modelos ajudam a visualizar o sistema como ele é ou como desejamos que ele seja. Permitem especificar a estrutura ou o comportamento de um sistema, além de proporcionar um guia para a construção do software; e
2. Para dividir problemas maiores em problemas menores e mais fáceis de se entender e resolver. Há limites para a capacidade humana compreender certas complexidades. Com a ajuda da modelagem, delimitamos o problema que estamos estudando, restringido nosso foco a um único aspecto por vez. Modelos não reduzem a complexidade de um software, mas podem ajudar a controlá-la.

Em geral, para construção de modelos de software, notações gráficas são utilizadas. A linguagem de modelagem unificada (UML – Unified Modeling Language) é a notação gráfica comumente adotada na maioria dos processos de desenvolvimento. UML é uma linguagem genérica que serve para modelagem de diversos tipos de software. Ela possui 13 tipos de diagramas, apoiando a criação de diferentes modelos para diferentes perspectivas do sistema. Mais informações sobre UML podem ser obtidas no excelente guia de uso desenvolvido pelos próprios criadores desta linguagem [6].

Para auxiliar no trabalho de confecção e manutenção de modelos UML, existem diversas ferramentas proprietárias e livres, tais como Astah*, Borland Together, Magic Draw, ArgoUML, entre outras. Uma lista mais completa das ferramentas de modelagem existentes e suas respectivas licenças podem ser encontradas em [2].

Neste artigo, será abordada a ferramenta Astah*, pelos seguintes motivos: i) apesar de ser proprietária, ela possui uma versão gratuita, denominada Astah* Community; ii) a licença da versão professional pode ser obtida gratuitamente para fins acadêmicos [3]; e iii) é flexível a ponto de permitir a construção de plug-ins que podem complementar sua funcionalidade.

Além disso, o enfoque principal deste artigo não está sobre o uso da ferramenta Astah* para construção de diagramas UML, mas sim, para a extensão da mesma, por meio da construção de plug-ins. A razão para isso se baseia em dois aspectos:

1. o uso de ferramentas como Astah* para construção de diagramas é bastante difundido no meio acadêmico e industrial. Sendo assim, bons tutorias e conteúdos sobre o uso dessa ferramenta para esta finalidade podem ser facilmente obtidos e entendidos, ao contrário do que ocorre com o assunto relacionado à confecção de plug-ins para ferramentas de modelagem como Astah*. A quantidade de material é bem escassa e esse assunto é pouco discutido em salas de aulas e na indústria; e
2. estou interessado no potencial científico que o conhecimento sobre a construção de plug-ins para ferramentas desse tipo possui. Digo isso, pois muitas pesquisas têm sido conduzidas em torno da avaliação da qualidade de modelos UML e a construção de plug-ins para ferramentas de modelagem pode contribuir para que as teorias propostas nestas pesquisas sejam devidamente automatizadas, caso seja possível. Isso pode ampliar a probabilidade de estas pesquisas serem realmente aplicadas em cenários reais de produção de software.

Dadas as devidas explicações, apresenta-se o objetivo deste artigo, que é apresentar a construção de um plug-in, denominado Validator, capaz de verificar uma simples convenção de nomenclatura no desenvolvimento de software Orientado a Objetos, a saber: “o identificador das classes do software deve iniciar com letra maiúscula”. Parece uma regra ingênua, mas um aspecto importante sobre a qualidade no desenvolvimento de software é seguir as boas práticas estabelecidas e preconizadas pela comunidade científica e pelos profissionais. A convenção de nomenclatura comentada anteriormente encontra-se destacada, inclusive, no guia de convenções de codificação para a linguagem Java, disponibilizado pela Oracle [4].

A motivação para desenvolvimento do Validator é que, por meio dele, pode-se identificar violações a uma convenção de nomenclatura logo nas fases iniciais do desenvolvimento do software, na qual pouco ou nenhum código existe ainda. Isso pode evitar a propagação desta violação para as fases subsequentes do desenvolvimento, como por exemplo, para a fase de implementação. Tal plug-in deverá ser capaz de varrer um projeto de modelagem criado na ferramenta Astah* a procura de classes e verificar se a primeira letra do identificador dessas classes está em maiúscula.

O material mais completo sobre esse tema, isto é, a confecção de plug-ins para a ferramenta Astah* encontra-se disponível no próprio site da empresa desenvolvedora desta ferramenta [7]. Neste artigo, pretendo seguir a mesma metodologia utilizada em [7], na qual apresenta-se inicialmente a preparação do ambiente de desenvolvimento e posteriormente a construção do plug-in de exemplo e a instalação do mesmo na ferramenta Astah*.

A Tabela 1 apresenta a lista de softwares utilizados neste artigo, bem como suas respectivas versões e link para download.

Tabela 1. Softwares necessários para acompanhamento deste artigo.

É importante salientar que todos os testes foram realizados sobre o Sistema Operacional Windows, versão 8.1. Para utilizar a versão professional do Astah*, você pode obter a licença para estudante, disponível em [3], ou adquiri-la em [5].

Instalação do Astah Plug-in SDK

A preparação do ambiente é bastante simples! Para isso, basta seguir os passos descritos a seguir:

Passo 1. Descompacte o arquivo obtido com o download do Astah Plug-in SDK em um diretório de sua preferência (no meu caso, ficou assim: C:\astah-plugin-SDK-1.2).

Passo 2. Crie duas variáveis de ambiente no seu sistema operacional, ASDK_HOME e M2_HOME, e as configure, apontando-as para o diretório onde foi descompactado o arquivo do Astah Plug-in SDK. A primeira variável é para o SDK de desenvolvimento de plug-ins da ferramenta Astah* e a segunda é para o software Maven (um software bastante conhecido para gerenciamento de projetos de software), que já vem em conjunto com o Astah Plug-in SDK (por este motivo, as duas variáveis apontam para o mesmo local). A Figura 1- A apresenta a configuração da variável ASDK_HOME (a configuração da variável M2_HOME é similar).

Passo 3. Adicione a variável de ambiente ASDK_HOME, criada anteriormente, ao classpath do seu sistema operacional. Para isso, edite a variável PATH do sistema operacional, incluindo o seguinte trecho: %ASDK_HOME%\bin (Figura 1 - B).

(A)

(B)

Figura 1. Configuração das variáveis de ambiente ASDK_HOME (A) e PATH (B).

Passo 4. Pronto, o ambiente de desenvolvimento de plug-ins Astah* já encontra-se devidamente instalado. Para testá-lo, entre no console do seu sistema operacional, digite o comando asdk e pressione enter. O resultado deve estar em conformidade com o que é apresentado na Figura 2.

Figura 2. Testando a instalação do Astah Plug-in SDK.

Construindo o projeto para desenvolvimento do plug-in

Para iniciar a construção de um plug-in, deve-se primeiramente, gerar um projeto específico para isso. Felizmente, o Astah Plug-in SDK já traz um script capaz de realizar tal tarefa. Via console, acesse o diretório onde você pretende criar o projeto do seu plug-in (no meu caso foi C:\astahplugins) e entre com o comando astah-generate-project. Serão solicitadas algumas informações sobre o projeto, as quais devem ser preenchidas como segue:

• groupID (é um identificador único para seu plug-in): com.validator.
• artifactID (é o nome do projeto para desenvolvimento do plug-in): validator.
• version (versão do plug-in): 1.0.
• package (nome do pacote onde serão criadas as classes principais do plug-in): com.validator.

A partir deste momento, um projeto com um plug-in de exemplo gerado automaticamente pelo Astah Plug-in SDK encontra-se construído e já pode ser testado. Mas antes, vamos conhecer alguns dos arquivos mais importantes deste projeto:

• pom.xml: é o arquivo de configuração para o software Maven. Ele contém informações sobre o projeto e sobre as dependências necessárias para executá-lo.
• Activator.java: é a classe, invocada automaticamente pelo Astah*, responsável pela inicialização e finalização correta do plug-in. Caso algum processamento precise ser realizado durante a inicialização ou finalização do seu plug-in, há métodos específicos para isso nesta classe.
• plugin.properties: contém as strings utilizadas como rótulos na interface gráfica do Astah*, e consequentemente, do seu plug-in.
• plugin.xml: descreve os pontos de extensão da ferramenta, isto é, os elementos que acrescentam funcionalidade ao Astah*, como grupos e itens de menu, views, entre outros. Mais detalhes sobre estes pontos de extensão são apresentados no decorrer deste artigo.

Enfim, para testar o plug-in gerado automaticamente, primeiramente, faz-se necessário construí-lo (build), isto é, empacotar todos os arquivos necessários para execução do plug-in pelo Astah*. Para isso, basta acessar o diretório de seu projeto (no meu caso, c:\astahplugins\validator) e executar o comando astah-build no console. Posteriormente, basta executar astah-launch e pronto, uma versão do Astah* com o plug-in de exemplo instalado será executada.

Pode-se verificar se o plug-in foi realmente instalado de duas formas: i) ao acessar o menu Help à Plugin List você verá uma janela com o nome do seu novo plug-in, isto é, validator (Figura 3 - A); ou ii) acessando o menu Tool, você verá um grupo de menu, a saber, “Template Group” com um item de menu, “Template Menu” (Figura 3 – B), criados automaticamente pelos Astah Plug-in SDK.

(A)

(B)

Figura 3. Verificando a instalação do plug-in de exemplo.

Este plug-in de exemplo simplesmente imprime a mensagem “Hello” em uma caixa de diálogo, caso algum projeto esteja aberto no Astah*, ou a mensagem “Project is not opened. Please open the Project or create new project”, caso contrário.

Configurando o Eclipse

Mas até agora você deve estar se perguntando, “onde o Eclipse entra na história deste artigo?”. Bom, uma vez que você tenha chegado a este ponto no artigo, já é possível fazer modificações no código fonte do plug-in de exemplo, construi-lo novamente e verificar sua execução no Astah*. Para realizar mudanças no código do plug-in, você pode utilizar seu ambiente de desenvolvimento integrado (IDE – Integrated Development Environment) favorito.

No meu caso, escolhi o Eclipse por dois motivos: i) trata-se de um IDE robusto e bem conhecido no mercado; e ii) o Astah Plug-in SDK oferece um script específico, capaz de preparar o projeto gerado anteriormente para ser importado no Eclipse. Neste sentido, aqui entra o Eclipse! Além deste IDE, o pessoal do Astah* preparou também um script para o IDE IntelliJ IDEA. Você pode conferir como importar seu projeto nesta ferramenta em [7].

No caso do Eclipse, os passos para realizar a importação do projeto com o plug-in de exemplo são bem simples.

Passo 1. Inicialmente, via console, acesse o diretório onde está localizado o projeto do seu plug-in e execute o comando astah-mvn eclipse:eclipse. Isso irá preparar o projeto para ser importado no Eclipse.

Passo 2. Agora, é necessário configurar o Eclipse para trabalhar com o Maven, software utilizado para gerenciar o projeto do plug-in. Para isso, abra o Eclipse e selecione o menu Window à Preference. Na janela que aparecer, escolha a opção Maven (lado esquerdo da tela) e depois Installations. Posteriormente, clique no botão Add (lado direito da tela) e informe o local de instalação do Astah Plug-in SDK no campo Installation home, conforme exibido na Figura 4 – A. Por fim, clique em Finish, o resultado final pode ser visualizado na Figura 4 – B.

(A)

(B)

Figura 4. Configuração do Eclipse.

Passo 3. Pronto! Agora é possível importar o projeto criado anteriormente no Eclipse. Para isso, no menu principal do Eclipse 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.

Neste momento, é possível que em seu ambiente de trabalho, o projeto apareça com seis erros. A causa principal disso é uma configuração incorreta no arquivo pom.xml do plug-in de exemplo. Para corrigi-la, abra o arquivo pom.xml e na linha onde se encontra o trecho ${astahPath}/astah-api.jar, substitua ${astahPath} pelo caminho absoluto do diretório de instalação do Astah* (Atenção: é o diretório onde encontra-se instalado o Astah*/Professional, não o Astah Plug-in SDK). Em geral, esse caminho é algo parecido com “C:\Program Files\astah-professional”. A nova configuração deve ficar assim:

<systemPath>C:/Program Files/astah-professional/astah-api.jar</systemPath>

Implementação do plug-in

Como foi visto, o plug-in de exemplo já traz um grupo de menu (Template Group) com um item de menu acoplado a ele (Template menu). O código responsável por esta alteração na interface do Astah* está no arquivo plugin.xml, arquivo este que concentra todas as configurações de extensões feitas no plug-in. Portanto, é importante dar uma olhada no código deste arquivo, apresentado na Listagem 1.

Listagem 1. Código do arquivo plugin.xml.

  01. <?xml version="1.0" encoding="UTF-8"?>
  02. <plugin>
  03.    <extension point="com.change_vision.astah.ui.actionSets">
  04.       <actionSet>
  05.          <menu
  06.                id="validador"
  07.                label="%menu_group"
  08.                path="tool/">
  09.          </menu>
  10.          <action
  11.                label="%menu_label"
  12.                class="com.validaclasse.TemplateAction"
  13.                tooltip="%menu_tooltip"
  14.                menubarPath="tool/validador/"
  15.                id="validaclasse">
  16.          </action>
  17.      </actionSet>
  18.    </extension>
  19. </plugin>

São dois os tipos de extensões permitidos pelo Astah*: actionSets e view. Uma extensão do tipo actionSet permite ao desenvolvedor adicionar grupos e itens de menus à interface do Astah*, juntamente com a ação a ser realizada quando um item de menu for acionado. A extensão view permite adicionar tipos de visões extras à ferramenta. Neste artigo, será apresentado apenas o tipo de extensão actionSet.

O tipo de extensão desejado pelo desenvolvedor deve ser especificado, informando seu id como valor para propriedade point da tag extension do arquivo plugin.xml (linha 3 da Listagem 1). No exemplo dessa listagem está sendo utilizada uma extensão do tipo actionSets, cujo id é com.change_vision.astah.ui.actionSets. Informações sobre o id dos tipos de visão podem ser encontrados em [7].

Encapsulada pela tag extension, há a tag denominada actionSet. Ela é responsável por agrupar a declaração de grupos e itens de menu. A tag menu encapsula um grupo de menu, isto é, um menu que contém itens de menu, como é o caso do Template group, que possui o item Template menu. Os principais atributos da tag menu são apresentados e explicados na Tabela 2.

No caso do atributo path, deve-se informar o caminho do grupo ou item de menu, sob o qual o novo grupo de menu será inserido. No exemplo da Listagem 1, informou-se tool/ como caminho para o grupo de menu, o que significa que o novo grupo de menu será inserido sob o menu Tool, já existente na ferramenta Astah*. Caso o desenvolvedor queira criar um novo menu na interface do Astah*, basta informar apenas o símbolo / e o grupo de menu será criado entre os itens de menu Window e Help. É importante ressaltar que tool é o id para o grupo de menu Tool, do Astah*; uma lista completa com o id de todos os grupos de menu da ferramenta pode ser encontrada em [7].

Tabela 2. Atributos da tag menu.

Quanto ao atributo label, percebe-se que a string informada na Listagem 1, %menu_group, não corresponde exatamente ao rótulo do grupo de menu, isto é, Template group. Na verdade, o valor informado corresponde a uma entrada no arquivo plugin.properties (Listagem 2).

Listagem 2. Código do arquivo plugin.properties.

  pluginName=plugin validaclasse
  providerName=Change Vision, Inc.
   
  menu_group=Template group
  menu_label=&Template menu
  menu_tooltip=plugin template

Cada linha do arquivo plugin.properties possui um par de strings separado por um sinal de =. A string localizada antes do = corresponde a uma chave que será utilizada para identificar a string que aparece do lado direito do sinal de =. Por exemplo, a string %menu_group, utilizada no arquivo plugin.xml identifica a string Template group, que corresponde ao rótulo do grupo de menu. Esse é um recurso interessante do Astah Plug-in SDK, permitindo a fácil internacionalização da interface dos plug-ins.

Por fim, a tag action encapsula um item de menu, para o qual deverá ser executada uma ação quando o usuário clicar sobre ele. Alguns atributos desta tag são idênticos aos da tag menu e não serão comentados novamente. Sendo assim, apenas os atributos distintos são apresentados e explicados na Tabela 3.

Tabela 3. Atributos da tag action.

Antes de explicar como configurar a ação do menu, faz-se necessário realizar algumas alterações no arquivo plugin.xml para que o mesmo fique adequado ao nosso objetivo, que é construir um validador de diagramas de classes da UML.

Primeiramente, são alterados os rótulos no arquivo plugin.properties, conforme apresentado na Listagem 3.

Listagem 3. Código do arquivo plugin.properties modificado.

  pluginName = Class Diagram Validator
  providerName = by Paulo Afonso
   
  lb_group_validator=&Validator
  lb_item_classValidator=&Class Validator
  tooltip_item_classValidator=Validate the existing classes diagrams in the project.

Agora, deve-se alterar o arquivo plugin.xml, invocando os rótulos corretamente, conforme apresentado na Listagem 4.

Listagem 4. Código do arquivo plugin.xml modificado.

  <?xml version="1.0" encoding="UTF-8"?>
  <plugin>
     <extension point="com.change_vision.astah.ui.actionSets">
        <actionSet>
           <menu
                 id="validator"
                 label="%lb_group_validator"
                 path="tool/">
           </menu>
           <action
                             id="classValidator"
                             label="%lb_item_classValidator"
                 class="com.validaclasse.TemplateAction"
                 tooltip="%tooltip_item_classValidator"
                 menubarPath="tool/validator/">
           </action>
       </actionSet>
     </extension>
  </plugin>

Ao executar novamente o Astah* com plug-in modificado (como já comentado, basta mover-se ao diretório onde se encontra o projeto com o plug-in e digitar o comando astah-launch no console), o resultado deve ser similar ao apresentado na Figura 5.

Figura 5. Nova interface do plug-in Validator.

Agora será explicado o funcionamento do tratamento das ações para um plug-in Astah*. Para invocar uma ação quando um item de menu é selecionado pelo usuário, você deverá criar uma classe que implemente a interface IPluginActionDelegate e, consequentemente, o seu método run. Este método será automaticamente invocado quando o usuário clicar sobre o item de menu correspondente a esta ação. Para vincular um item de menu a uma ação, basta informar o nome da classe criada por você no atributo class da tag action correspondente a este item de menu. Por exemplo, na Listagem 4, a classe responsável por tratar os eventos de clique sobre o item de menu Class Validator é com.validaclasse.TemplateAction.

Um trecho do código da classe TemplateAction, que foi criada automaticamente para este plug-in de exemplo é apresentada na Listagem 5.

Listagem 5. Trecho de código da classe TemplateAction.

  01. public class TemplateAction implements IPluginActionDelegate {
  02.   public Object run(IWindow window) throws UnExpectedException {
  03.     try {
  04.       AstahAPI api = AstahAPI.getAstahAPI();
  05.       ProjectAccessor projectAccessor = api.getProjectAccessor();
  06.       projectAccessor.getProject();
  07.       JOptionPane.showMessageDialog(window.getParent(),"Hello");
  08.     } catch (ProjectNotFoundException e) {
  09.       String message = "Project is not opened.Please open the project or create new 
 10.         project.";
  11.       JOptionPane.showMessageDialog(window.getParent(), message, "Warning", 
 12.         JOptionPane.WARNING_MESSAGE); 
  13.     } catch (Exception e) {
  14.       JOptionPane.showMessageDialog(window.getParent(), "Unexpected error has occurred.", 
 15.         "Alert", JOptionPane.ERROR_MESSAGE); 
  16.       throw new UnExpectedException();
  17.     }
  18.     return null;
  19.   }
  20. }

As linhas 4, 5 e 6 utilizam a API do Astah Plug-in SDK para obter o projeto corrente. Caso o mesmo não exista, uma exceção do tipo ProjectNotFoundException é lançada automaticamente. Neste exemplo, caso isso ocorra, uma mensagem de alerta será exibida ao usuário, como já comentado neste artigo. Caso haja um projeto aberto, a mensagem Hello é exibida na tela (linha 7).

As modificações que foram realizadas na classe TemplateAction para contemplar no objetivo definido neste artigo são apresentadas na Listagem 6.

Os métodos mais importantes da nova versão da classe TemplateAction são getAllClasses e validate. O primeiro método encontra-se disponível no material disponibilizado pela empresa desenvolvedora do Astah* [7] e seu objetivo é vasculhar um projeto UML a procura de classes. Quando uma classe é encontrada, a mesma é adicionada em uma lista denominada classList. Este método é recursivo e é capaz de encontrar classes localizadas dentro de pacotes.

O segundo método, validate, foi desenvolvido para o propósito deste artigo; ele recebe a lista de classes identificada pelo método getAllClasses, obtém o identificador de cada classe e verifica se o mesmo se inicia com letra maiúscula. Caso não, uma string com o formato [ERRO] Class: nome_da_classe, onde nome_da_classe representa o identificador da classe que violou a convenção de nomenclatura, é concatenado à variável do tipo string, denominada error. Ao final, caso tenha ocorrido problemas com o identificador de alguma classe, a string com os erros é retornada, caso contrário, retorna-se null.

O método run, que é executado toda vez que o usuário clica no item de menu Class Validator, é responsável por obter o projeto atual aberto pelo usuário e submetê-lo à validação, por meio do método validate. Caso haja algum erro de validação, o mesmo é exibido em uma caixa de diálogo, caso contrário a mensagem There are no errors é exibida na tela. Classes como IModel, INamedElement, entre outras, fazem parte da API para manipulação de modelos Astah*. Mais informações sobre a mesma podem ser obtidas em [8].

Listagem 6. Trecho de código da classe TemplateAction modificada.

  public class TemplateAction implements IPluginActionDelegate {
    public Object run(IWindow window) throws UnExpectedException {
      try {
        ...
        IModel iCurrentProject = projectAccessor.getProject();
        String error = validate(iCurrentProject);
        if (error != null)
          JOptionPane.showMessageDialog(window.getParent(), error,
            "Error", JOptionPane.ERROR_MESSAGE);
        else
          JOptionPane.showMessageDialog(window.getParent(),
            "There are not errors!", "Success", JOptionPane.INFORMATION_MESSAGE);
      } 
      ...
    }
    
    private String validate(IModel iCurrentProject) {
      List<IClass> classList = new ArrayList<IClass>();
      getAllClasses(iCurrentProject, classList);
      StringBuffer error = new StringBuffer();
      boolean hasError = false;
      for (IClass cl : classList) {
        String name = cl.getName();
        String upperCase = name.toUpperCase();
        if (name.charAt(0) != upperCase.charAt(0)) {
          error.append("[ERROR] Class: " + name + "\n"); hasError = true;
        }
      }
      if (hasError) return error.toString();
      else return null;
    }
   
    private void getAllClasses(INamedElement element, List<IClass> classList) {
      if (element instanceof IPackage) {
        for (INamedElement ownedNamedElement : ((IPackage) element).getOwnedElements()) {
          getAllClasses(ownedNamedElement, classList);
        }
      } else if (element instanceof IClass) {
        classList.add((IClass) element);
      }
    }
  }

Para testar o plug-in Validator, inicialize-o por meio do comando astah-launch, crie um novo projeto no Astah*, clicando em File à New. Posteriormente, crie um diagrama de classes, clicando em Diagram à Class Diagram. Com o diagrama de classes criado, adicione três classes, conforme apresentado na Figura 6.

Observe que apenas a classe ItemDeVenda possui um identificador cuja primeira letra é maiúscula. Sendo assim, ao executar o item Validator à Class Validator do plug-in Validator, o resultado será uma mensagem de erro, conforme exibido na Figura 7.

Figura 6. Diagrama de classes com problemas de nomenclatura.

Figura 7. Erros de validação.

Uma vez corrigido o problema, ou seja, colocando os nomes das classes Venda e Produto com a primeira letra maiúscula (Figura 8), o resultado será a mensagem exibida na Figura 9.

Figura 8. Diagrama de classes com problemas de nomenclatura.

Figura 9. Erros de validação.

Instalação do plug-in

A instalação de um plug-in em uma versão pré-existente do Astah* é extremamente simples. Inicialmente, você deve construir um aquivo .jar a partir do seu projeto. Para isso, abra o console do seu sistema operacional, vá até a pasta onde se encontra o projeto do seu plug-in e execute o comando astah-build. Isso fará com que o arquivo validator-1.0.jar seja gerado na pasta target do seu projeto.

Pronto! Agora basta copiar este arquivo para a pasta plugins do diretório de instalação do Astah* e executá-lo. Para conferir se o plug-in está instalado, basta acessar Help à Plugin list.

Este artigo serviu como uma introdução ao desenvolvimento de plug-ins com o Astah Plug-in SDK. Foram vistas as principais motivações para o desenvolvimento de plug-ins para uma ferramenta de modelagem como o Astah*, bem como o procedimento de preparação do ambiente e o desenvolvimento de um primeiro plug-in simples para o Astah*.

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.

Estas limitações podem ser minimizadas por meio da utilização de outros recursos do Astah Plug-in SDK, tais como as views, que não foram alvos de enfoque neste artigo. Mais sobre estes mecanismos podem ser encontrados em [7].

Referências

[1] Sommerville, Ian. Engenharia de Software. 9ª. edição. Pearson Prentice Hall, 529 p., 2011.

[2] Lista de ferramentas de modelagem e suas respectivas licenças. Disponível em: http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools

[3] http://astah.net/student-license-request

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

[5] Preços para aquisição da licença do Astah*/Professional. Disponível em http://astah.net/pricing

[6] Booch, Grady; Jacobson, Ivar; Rumbaugh, James. Uml - Guia do Usuário. 2ªF edição. Campus, 500 p., 2006.

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

[8] Documentação da API do Astah*.
Disponível em: http://members.change-vision.com/javadoc/astah-api/6_8_0/api/en/doc/index.html