Um Componente de Gerenciamento de Execução de Workflow Segundo a Abordagem de Linha de Produto de Software

Transcrição

1 Um Componente de Gerenciamento de Execução de Workflow Segundo a Abordagem de Linha de Produto de Software Itana M. S. Gimenes 1 itana@din.uem.br Radames J. Halmeman 1 radames@cm.cefetpr.br Fabrício R. Lazilha 2 fabricio@cesumar.br Edson A. O. Junior 1 edson.junior@pop.com.br 1 Universidade Estadual de Maringá Departamento de Informática Maringá-PR, Centro Universitário de Maringá Departamento de Informática Maringá-PR, Resumo - A abordagem de linha de produto é aplicável a sistemas que compartilham um conjunto gerenciado de características, que satisfazem necessidades específicas de um segmento ou missão e que são desenvolvidos a partir de um núcleo de artefatos seguindo um plano previamente definido. Deste modo, percebe-se que o domínio dos Sistemas Gerenciadores de Workflow é propício à aplicação desta abordagem. Este artigo apresenta o projeto de um componente de Gerenciamento de Execução de Workflow segundo a abordagem de linha de produto de software. Este componente se caracteriza por executar um workflow previamente instanciado através do gerenciamento de suas tarefas. Tal componente foi projetado para permitir diferentes variantes de algorítmos de escalonamento possibilitando a instanciação de produtos com características diferentes. A validação deste componente é realizada através da implementação de um protótipo. Palavras chave: Desenvolvimento Baseado em Componentes, Linha de Produto, Sistemas de Gerenciamento de Workflow, Arquitetura de Software, Variabilidade. Tema: Linha de Produto de Software 1. Introdução Segundo Clements [1] uma linha de produto de software é uma coleção de sistemas que compartilham um mesmo conjunto gerenciado de características que satisfazem as necessidades específicas de um segmento ou missão e que são desenvolvidos a partir de um núcleo de artefatos seguindo um plano previamente definido. A abordagem de linha de produto de software tem por objetivos a redução de custos de desenvolvimento e o incremento da qualidade dos produtos. Estes objetivos são atingidos principalmente por meio da reutilização dos artefatos de software produzidos durante o processo. Segundo Gimenes [2] um artefato de software é um item reutilizável de software utilizado como bloco de construção de uma linha de produto. Para a realização dos workflows são utilizados os Sistemas de Gerenciamento de Workflow (WfMS), que definem, criam e gerenciam a execução de workflows através do uso de produtos de software, executando uma ou mais máquinas de workflow, os quais estão aptos a interpretar a definição de um processo, interagir com os participantes do workflow e, quando necessário, invocar o uso de ferramentas da tecnologia da informação ou aplicativos[3]. Este artigo apresenta o projeto do componente Gerenciador de Execução de Workflow (WorkflowExecutionMgr) segundo a abordagem de linha de produto de software. O propósito do desenvolvimento deste componente está em incrementar um núcleo de artefatos para linha de produto WfMS, identificar os pontos de variabilidade deste componente e revisar a arquitetura de linha de produto de software para WfMS proposta por Lazilha [4], na qual o componente está inserido. Esta arquitetura foi concebida de acordo com a abordagem de Desenvolvimento Baseado em Componentes (DBC) e teve como método de apoio o Catalysis[5]. A Figura 1 apresenta a arquitetura de componentes proposta por Lazilha.

2 Figura 1: Arquitetura de Componentes para WfMS [4]. Continuando o trabalho desenvolvido por Lazilha, cada um dos componentes deve ser projetado e implementado. Deste modo, foi escolhido o componente WorkflowExecutionMgr e foi realizado seu projeto. O projeto do componente segue os estágios do Catalysis, acompanhando o método já utilizado no desenvolvimento da arquitetura. A validação do componente foi realizada através da implementação de um protótipo que permite a avaliação do componente, de suas funcionalidades e interfaces. Este artigo está organizado da seguinte maneira. A Seção 2 apresenta o projeto do componente Gerenciador de Execução de Workflow segundo o método Catalysis. A Seção 3 apresenta o protótipo desenvolvido para o componente proposto, e a Seção 4 apresenta as conclusões e contribuições acerca deste trabalho. 2. Projeto do Componente O projeto do componente seguiu o método Catalysis e seus estágios: especificação de requisitos, especificação do sistema, projeto da arquitetura e projeto interno dos componentes. A seguir são apresentadas as etapas do projeto do componente WorkflowExecutionMgr segundo o Catalysis. 2.1 Especificação de Requisitos Para a especificação de requisitos foram elaborados diagramas de caso de uso da Unified Modeling Language (UML) onde são apresentados estereótipos do tipo <<extend>> conforme proposto por Jacobson [6] para representar aspectos de variação. O caso de uso estendido recebe uma marca, representada por um círculo preenchido, para indicar a variabilidade. A Figura 2 apresenta o diagrama de casos de uso para o componente proposto, permitindo visualizar as principais ações e os pontos de variação identificados. Nos casos de uso WorkflowExecutionMgr e WorkflowMgr, a variabilidade esta representada conforme proposto por Bachmann [7], estabelecendo que quando acontecer uma variação na relação entre dois artefatos, esta deverá ser representada em ambos os artefatos.

3 User (from BusinessActors) WorkflowMgr (from bbusinessusecasemodel) WorkflowManager (from BusinessActors) <<extend>> WorkflowExecutionMgr (from bbusinessusecasemodel) <<extend>> ExecuteWorkflowWithPriorityControl TaskScheduler (from TaskScheduler) ExecuteWorkflowSerial PreConditionManager TransitionManager TimerManager Figura 2: Diagrama de Casos de Uso: WorkflowExecutionMgr. Para o relacionamento entre o ator TaskScheduler e o caso de uso WorkflowManager foi necessária a criação de um estereótipo para um ator que apresenta uma variação. Neste caso, a indicação de variação é feita através de uma marca V junto ao estereótipo do ator. 2.2 Especificação do Sistema Este estágio apresenta a solução de software identificada a partir dos diagramas de caso de uso. As ações identificadas pelos casos de uso e o modelo de objetos do negócio permitem a identificação das classes de software e respectivas interações entre os objetos. Neste estágio a variação é representada através do estereótipo <<V>> junto ao tipo onde esta acontece. A Figura 3 apresenta o diagrama estático de tipos do componente proposto, que incrementa o diagrama de tipos para a arquitetura de linha de produto para WfMS. Neste artigo, por questões de espaço, não será mostrado o diagrama estático de tipos a arquitetura. <<V>> WorkflowMgr (from aworkflowmgr) Workflow User 0 n <<V>> ExecuteWorkflowMgr 0..* Task 1..n TaskTransition 1..n TimerMgr 1..n PreConditionMgr Figura 3: Modelo Estático de Tipos do Componente WorkflowExecutionMgr. Com base nos diagramas de caso de uso e no modelo estático de tipos foi elaborado um diagrama de seqüência que apresenta a ordem em que os eventos devem ocorrer permitindo a identificação dos parâmetros dos métodos necessários.

4 : Us er : Task Sc heduler : Work flowmgr : WorkflowExecutionMgr TaskTransitionManager : PreConditionManager : : TimerMgr TaskTransition PreConditionMgr requestconnection(logical View::java::lang::String, Logical View::java::lang::String) [se conexao = OK] selectusertask(int) choosetask(task) executetask(task) executetask(task) [if don t have precondition] getprecondition(tas k) gettransition( ) settimer(typetimer) changetaskstatus(task) concludetask(task) executetask(task) getprecondition(tas k) [if don t have precondition] gettransition( ) changetaskstatus(task) concludetask(task) [time finis hed] Figura 4: Diagrama de Seqüência do Componente WorkflowExecutionMgr. 2.3 Projeto da Arquitetura A partir do diagrama estático de tipos e do diagrama de seqüência foi elaborado um diagrama de classes de classes da UML, onde estão presentes os métodos, os atributos e as interfaces necessárias à implementação da solução de software. A Figura 5 apresenta o diagrama de classes, e omite alguns métodos por questões de espaço.

5 IExecuteTask Mgt (from aworkflowm executetask() canceltask() interrupttask() restartt ask() finalizetask() visualizetask() sel ectusert ask() <<V>> WorkflowExecutionMgr User (from astaticmodel) username : Logical View::java::lang::String userpassword : Logical View::java::lang::String User() getusername() getuserpassword() setusername() Task (from astaticmodel) taskdescription : Logical View::java::lang::String taskstatus : Logical View::java::lang::String taskimplementation : Logical View::java::lang::String taskcharacteristic : Logical View::java::lang::String taskinstantiation : Logical View::java::lang::String taskstartmode : Logical View::java::lang::String taskfinishmode : Logical View::java::lang::String taskduraction : int taskprecondition : Logical View::java::lang::String taskpostcondition : Logical View::java::lang::String settaskt i mer() gettasktimer() getnexttransition() selectt asktransiti on() getprecondition() choosetask() executetask() canceltask() interrupttask() restartt ask() finalizetask() visualizetask() postponetask() ExecuteWorkflow() TimerMgr startat : Logical View::java::lang::String finishat : Logical View::java::lang::String TimerMgr() gettaskid() settaskid() getstartat() setstartat() getfinishat() TaskTransition transitionid : int transitionfrom : int transitionto : int transitiondescription : Logical View::java::lang::String transitionduraction : int TaskTransition() gettaskid() settaskid() gettransitionid() settransitionid() gettransitionfrom() settransitionfrom() gettransitionto() settransitionto() gettransitiondescription() settransitiondescription() PreConditionMgr Requirements() gettaskid() 0..* getduraction() setduraction() Task() getimplementation() setimplementation() getdescription() setdescri pti on() getcharacteristic() setcharacteristic() getinstantiation() setinstantiation() getstartmode() setstartmode() getfinishmode() setfinishmode() getprecondition() setprecondition() Workflow (from astaticmodel) workflowversion : Logical View::java::lang::String workflowvendor : Logical View::java::lang::String workflowcreated : Logical View::java::lang::String workflowdescription : Logical View::java::lang::String workflowduraction : int Workflow() getworkflowversion() setworkflowversion() getworkflowvendor() setworkflowvendor() getworkflowcreated() setworkflowcreated() getdescription() Figura 5: Diagrama de Classes do Componente WorkflowExecutionMgr. 3. Protótipo do Componente Para validar o componente proposto foi desenvolvido um protótipo deste componente que aciona os componentes relacionados através das interfaces externas e promove a execução de um workflow previamente instanciado. A principal interface com o usuário está diretamente relacionada ao componente TaskScheduler e mostra as tarefas que estão disponíveis, a Figura 6 mostra esta interface. Figura 6: Interface do Usuário - TaskScheduler.

6 A instanciação das variabilidades é feita através de um arquivo de configuração, no qual é informado um parâmetro que indica qual o algoritmo de escalonamento deve ser utilizado. 3.1 Mecanismos Utilizados na Implementação do Protótipo Para a implementação do protótipo foi escolhido: a plataforma Linux, a linguagem de programação Java[8], o sistema gerenciador de banco de dados MySQL[9] e o framework que faz o mapeamento dos objetos para uma base de dados relacional ObJectBridge [10]. 4. Conclusões Este artigo apresentou o projeto de um componente de Gerenciamento de Execução de Workflow segundo a abordagem de linha de produto de software e o método de DBC Catalysis. A principal contribuição deste trabalho está no projeto do componente WorkflowExecutionMgr o que incrementa o núcleo de artefatos para a arquitetura de linha de produto para WfMS. Consequentemente foram repensadas as funcionalidades dos componentes da arquitetura relacionados a ele o que proporcionou um melhor entendimento e separação das funcionalidades dos componentes. Notou-se que o mapeamento das variabilidades se torna extremamente difícil devido ao fato deste ser o primeiro componente da arquitetura a ser implementado de acordo com a abordagem de linha de produto de software. Percebe-se que as variações existentes neste componente influenciarão os demais componentes da arquitetura. No entanto o mapeamento dessas variabilidades depende de um projeto mais detalhado dos demais componentes. A implementação do protótipo contribuiu para o refinamento do projeto, validando tipos e estruturas utilizadas no projeto e permitindo que o projeto fosse complementado com detalhes relacionados à fase de implementação. Referente a trabalhos futuros estão em desenvolvimento outros dois trabalhos relacionados a arquitetura de linha de produto para WfMS. O primeiro refere-se à Geração de Produtos numa abordagem de linha de produto e o segundo é o projeto do componente Gerenciador de Interfaces Gráficas. Referências [1] P. Clements, Software Product Line Fundamentals, Addison-Wesley, [2] I. M. S. Gimenes, G. Weiss, E. H. M. Huzita, Um Padrão para Definição de um Gerenciador de Processos de Software, in 1999 Proc. II Workshop Ibero Americano de Engenharia de Requisitos Y Ambientes de Software, San José, Costa Rica, Ideas 1999 Memorias, 1999, pp [3] Workflow Management Coalition. Workflow Reference Model. Document number TC , January, [4] F. R. Lazilha, Uma Proposta de Arquitetura de Linha de Produtos para Workflow Management Systems. Universidade Federal do Rio Grande do Sul. Instituto de Informática. Porto Alegre. Janeiro de [5] D. F. D Souza, A. C. Wills, Objects, Components and Frameworks with UML The Catalysis Approach. Addison Wesley Publishing Company, [6] I. Jacobson, M. Griss, P. Jonsson, Software Reuse Architecture Process and Organization for Business Success, New York: Addison-Wesley, [7] F. Bachmann, L. Bass, Managing Variability in Software Architectures, in 2001 Sysmposium on Software Reusability, Toronto, Canada. [8] SUN, Java, Available: June [9] MySQL, Available: June [10] Jakarta Project, ObJectRelationBridge, Available: June de 2003.