Um Componente de Gerenciamento de Execução de

Um Componente de Gerenciamento de Execução de Workflow
Segundo a Abordagem de Linha de Produto de Software
Itana M. S. Gimenes1
Radames J. Halmeman1
Fabrício R. Lazilha2
Edson A. O. Junior1
[email protected]
[email protected]
[email protected]
[email protected]
1
Universidade Estadual de Maringá
Departamento de Informática
Maringá-PR, 87020-900
2
Centro Universitário de Maringá
Departamento de Informática
Maringá-PR, 87050-390
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.
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.
User
WorkflowMgr
WorkflowManager
(from BusinessActors)
(from bBusinessUseCaseModel)
(from BusinessActors)
<<include>>
<<extend>>
WorkflowExecutionMgr
(from bBusinessUseCaseModel)
<<extend>>
ExecuteWorkflowWithPriorityControl
TaskScheduler
(from TaskScheduler)
(from Use Cases)
<<include>>
ExecuteWorkflowSerial
(from Use Cases)
<<include>>
<<include>>
TimerManager
(from Use Cases)
TransitionManager
PreConditionManager
(from Use Cases)
(from Use Cases)
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
<<V>>
ExecuteWorkflowMgr
(from aWorkflowMgr)
(from bExecuteWorkflowMgr)
0..n
TaskTransition
(from bExecuteWorkflowMgr)
1..n
1..n
0..n
Workflow
PreConditionMgr
1..n
0..*
Task
User
0
(from bExecuteWorkflowMgr)
TimerMgr
(from bExecuteWorkflowMgr)
n
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.
: U s er
: Wor k flowMgr
: Tas k Sc heduler
: Wor k flowEx ec utionMgr
Tas k Tr ans itionManager :
Tas k Tr ans ition
Pr eC onditionManager :
Pr eC onditionMgr
: Timer Mgr
r eques tC onnec tion( Logic al View ::jav a::lang::Str ing, Logic al View ::jav a::lang::Str ing)
[s e c onex ao = OK]
s elec tU s er Tas k ( int)
c hoos eTas k ( Tas k )
ex ec uteTas k ( Tas k )
ex ec uteTas k ( Tas k )
[if don´ t hav e pr ec ondition]
getPr eC ondition( Tas k )
getTr ans ition( )
s etTimer (ty peTimer )
c hangeTas k Status ( Tas k )
c onc ludeTas k ( Tas k )
ex ec uteTas k ( Tas k )
getPr eC ondition( Tas k )
[if don´ t hav e pr ec ondition]
getTr ans ition( )
c hangeTas k Status ( Tas k )
c onc ludeTas k ( Tas k )
[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.
Task
User
IExecuteTask
Mgt
(from aStaticModel)
(from aStaticModel)
userId : int
userName : Logical View::java::lang::String
userPassword : Logical View::java::lang::String
_id : int
(from aWorkflowM...
executeTask()
cancelTask()
interruptTask()
restartTask()
finalizeTask()
visualizeTask()
selectUserTask()
User()
getId()
getUserName()
getUserPassword()
setUserId()
setUserName()
...
<<V>>
WorkflowExecutionMgr
0..n
setTaskTimer()
getTaskTimer()
getNextTransition()
selectTaskTransition()
getPreCondition()
chooseTask()
executeTask()
cancelTask()
interruptTask()
restartTask()
finalizeTask()
visualizeTask()
postponeTask()
ExecuteWorkflow()
...
TimerMgr
workflowId : int
userId : int
taskId : int
startAt : Logical View::java::lang::String
finishAt : Logical View::java::lang::String
_id : int
TimerMgr()
getId()
setId()
getWorkflowId()
setWorkflowId()
getUserId()
setUserId()
getTaskId()
setTaskId()
getStartAt()
setStartAt()
getFinishAt()
...
0..*
taskId : int
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
workflowId : int
userId : int
_id : int
getId()
setId()
getDuraction()
setDuraction()
getUserId()
getWorkflowId()
Task()
getImplementation()
setImplementation()
getDescription()
setDescription()
getCharacteristic()
setCharacteristic()
getInstantiation()
setInstantiation()
getStartMode()
setStartMode()
getFinishMode()
setFinishMode()
getPreCondition()
setPreCondition()
...
0..n
0..n
0..n
TaskTransition
workflowId : int
userId : int
taskId : int
transitionId : int
transitionFrom : int
transitionTo : int
transitionDescription : Logical View::java::lang::String
transitionDuraction : int
_id : int
TaskTransition()
getId()
setId()
getWorkflowId()
setWorkflowId()
getUserId()
setUserId()
getTaskId()
setTaskId()
getTransitionId()
setTransitionId()
getTransitionFrom()
setTransitionFrom()
getTransitionTo()
setTransitionTo()
getTransitionDescription()
setTransitionDescription()
...
PreConditionMgr
workflowId : int
userId : int
taskId : int
_id : int
Requirements()
getId()
setId()
getWorkflowId()
setWorkflowId()
getUserId()
setUserId()
getTaskId()
...
0..n
Workflow
(from aStaticModel)
workflowId : int
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
_id : int
Workflow()
getId()
setId()
getWorkflowId()
setWorkflowId()
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.
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, 2001.
[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. 3046.
[3] Workflow Management Coalition. Workflow Reference Model. Document number TC00-1003,
January, 1995.
[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 2002.
[5] D. F. D’Souza, A. C. Wills, Objects, Components and Frameworks with UML – The Catalysis
Approach. Addison Wesley Publishing Company, 1999.
[6] I. Jacobson, M. Griss, P. Jonsson, Software Reuse – Architecture Process and Organization for
Business Success, New York: Addison-Wesley, 1997.
[7] F. Bachmann, L. Bass, “Managing Variability in Software Architectures”, in 2001 Sysmposium on
Software Reusability, Toronto, Canada.
[8] SUN, Java, Available: http://java.sun.com/, June 2003.
[9] MySQL, Available: http://www.mysql.com/, June 2003.
[10] Jakarta Project, ObJectRelationBridge, Available: http://jakarta.apache.org/ojb, June de 2003.