Extensões

Embora o núcleo forneça um conjunto de interfaces adequadas para a manipulação e controle de fluxo em Redes de Petri, trata-se apenas de uma biblioteca - um sistema de gerenciamento de Workflows empresarial certamente requer mais do que um punhado de métodos de manipulação. Isso significa que existem inúmeros requisitos funcionais importantes que não fazem parte da lógica de processos, tais como interfaces gráficas, funcionalidades de cadastro e autenticação de usuários, acesso via WEB e facilidades para ambientes distribuídos. A essas funcionalidades extra-núcleo demos o nome de extensões.

A porção das extensões residente na camada de negócios é compreendida pelos seguintes:

1. Extensões semânticas

   Muitas das abstrações fornecidas pelo núcleo possuem uma semântica incompleta ou reduzida que, embora seja suficiente para os propósitos da biblioteca, é insuficiente num caso mais específico como o do sistema de gerenciamento de workflows empresarial. Tomemos, como exemplo dessa diferença, a semântica de usuários e grupos. Embora ambos sejam tratados indiferenciadamente pelo núcleo, essas entidades diferem significativamente quando inseridas no contexto de um sistema de cadastro - papéis não possuem endereços nem telefones; já usuários podem pertencer a papéis mas não a outros usuários.

2. Extensões funcionais

   As extensões funcionais fazem-se necessárias na medida em que o núcleo torna-se incapaz de prover determinados mecanismos essenciais ao nosso sistema em particular. Note que essa deficiência do núcleo se apresenta não como uma deficiência de projeto, mas como parte da própria filosofia adotada. Isso dito, podemos identificar como extensões funcionais, por exemplo, o sistema de controle e gerenciamento de papéis e usuários (cadastro e formas de acesso diferenciadas), o sistema de troca de mensagens (fornece um canal de comunicação entre usuários do sistema), o subsistema de persistência (que não é nada mais que uma implementação opensource do JDO), entre outros.

3. Modelos da interface

   Como mencionado anteriormente, nosso sistema é baseado no modelo MVC de integração aplicação-interface (Model-View-Controller). O gerenciamento e armazenagem dos modelos (Model) fica a cargo da camada de negócios.

   Um problema que surge nesta aplicação em específico é a necessidade de se criar um grande número de interfaces dinamicamente. Essa necessidade introduz um fator de complicação a mais na estrutura do modelo, que deixa de ser estático.

   É necessário também que haja uma maneira descomplicada de especificar o modelo e o fluxo de controle - idealmente, eles devem ser gerados automaticamente a partir da especificação da interface, podendo ser modificado nos casos onde isso for necessário (seguindo a filosofia ``as coisas simples são simples de se fazer e as difíceis são possíveis'').

   Um outro problema, talvez mais sério do que os outros dois, é a necessidade de criar novos widgets dinamicamente. Note que criar um novo widget é diferente de instanciar um widget pré-existente - o trabalho de criar é feito no nível de criar uma classe, enquanto que instanciar é simplesmente obter um objeto de uma classe pré-existente.

   A estratégia adotada foi baseada num padrão de modelo adaptativo, como feito no núcleo. Essencialmente as metaclasses do núcleo sofrem uma extensão semântica e passam a contar com seqüências de telas associadas às transições, que são instanciadas também como metaobjetos em conjunto com as porções provenientes do núcleo.

   Cabe aqui uma definição um pouco mais clara a respeito do que são telas, pela perspectiva da camada de negócios. Telas são composições de modelos (ou value holders na nomenclatura Smalltalk) de widgets (tais como áreas de texto, combo boxes, ou botões de rádio) que podem ser exibidos seqüencialmente pela camada de apresentação ao iniciar de um workitem.

   Tanto as informações sobre quais widgets serão apresentados em uma tela, quanto os dados entrados no sistema pelos usuários são transferidos entre as camadas de apresentação e a de negócios encapsulados em objetos. Este padrão é conhecido como Data Transfer Object (``Objeto de Transferência de Dados''), também chamado de DTO, e permite uma comunicação eficiente entre as camadas, pois todos os dados a serem transferidos são encapsulados em um objeto, evitando a realização de diversas chamadas remotas a uma outra camada para obtenção dos mesmos.

Segue abaixo o diagrama de classe da porção mais significativa das extensões semânticas e funcionais:

Figura 14: Diagrama de classe das extensões semânticas e funcionais.

Embora o código do núcleo e interface web encontram-se praticamente prontos, ainda há o que ser implementado na parte das extensões.