UNIVERSIDADE FEDERAL DO PARÁ CENTRO DE CIÊNCIAS EXATAS E NATURAIS DEPARTAMENTO DE INFORMÁTICA LABORATÓRIO DE ENGENHARIA DE SOFTWARE - LABES Documentação de Referência do Sistema WebAPSEE.0 (beta) Belém 2006
Equipe de Desenvolvimento Coordenação Carla A. Lima Reis (Informática/UFPA) Rodrigo Quites Reis (Informática/UFPA) Arquitetura Adailton Lima (CBCC/UFPA) Heribert Schlebbe (Universität Stuttgart) Mecanismo de Execução Breno França (CBCC/UFPA) Heribert Schlebbe (Universität Stuttgart) Registro de Eventos Luciana Nascimento (PPGEE/UFPA) Carla Paxiúba (PPGEE/UFPA) Banco de Dados (Persistência de Objetos) Marcelo Almeida Silva (CBCC/UFPA) Políticas e Condições Lógicas Laudemira Farias (CBCC/UFPA) Marcelo Almeida Silva (CBCC/UFPA) Agenda Antonio Lobato (PPGCC/UFPA) Marcelo Pereira (CBCC/UFPA) Editor para Modelagem de Processos Manager Console Versão 0: Ernani Sales (CBCC/UFPA) Daniel Henriques Moreira (CBCC/UFPA) Joseane Viana (CBCC/UFPA) Versão : Adailton Lima (CBCC/UFPA) Breno França (CBCC/UFPA) Heribert Schlebbe (Universität Stuttgart) Jadielly Oliveira Marcelo Pereira (CBCC/UFPA) Instalador: Adailton Lima (CBCC/UFPA) Murilo Sales (CBCC/UFPA) Manual: Marcelo Pereira (CBCC/UFPA) Murilo Sales (CBCC/UFPA) Documentação: Adailton Lima (CBCC/UFPA) Jadielly Fernandes (PPGCC/UFPA) Vanderlene Covre (PPGEE/UFPA) 2
Sumário INTRODUÇÃO... 7. Objetivos do Projeto WebAPSEE... 7.2 Histórico... 8.3 Organização do Texto... 8 2 VISÃO GERAL DAS FUNCIONALIDADES DO WEBAPSEE... 9 2. Manager Console... 9 2.2 Task Agenda... 0 3 ARQUITETURA DO SISTEMA... 2 3. Distribuição Física dos Componentes... 3 3.2 Camada Servidora... 3 3.3 Camada Cliente... 4 3.3. Clientes Básicos... 4 3.3.2 Clientes Completos... 5 3.3.3 Arquitetura do Cliente... 6 3.4 Camada de Distribuição... 7 3.4. Serviços Disponíveis... 7 3.4.2 Facade Factory... 8 3.5 Camada de integração (Fachadas)... 9 3.5. Fachadas... 9 3.5.2 Acesso BD... 9 3.5.3 Execução... 9 3.5.4 Segurança... 9 3.5.5 Instanciação... 9 3.6 Classes de Negócio... 20 3.7 Camada de Persistência... 20 3.7. Camada de Mapeamento... 20 3.7.2 Camada de Banco de dados... 2 3.8 Mapeamento Objeto-Relacional do Modelo de Dados... 2 3.8. Mapeamento do modelo de classes (Herança)... 2 3.8.2 Exemplo de mapeamento... 22 3.8.3 Mapeamento Objeto-Relacional... 22 4 MODELO DE DADOS PRINCIPAL DO WEBAPSEE... 25 4. Descrição dos pacotes... 25 4.2 Pacote Types... 25 4.3 Pacote Log... 26 4.4 Pacote SoftwareProcesses... 28 4.4. Modelos de Processos... 28 4.4.2 Atividades de um Processo... 30 3
4.4.2. Atividades Simples Normais e Automáticas... 30 4.4.2.2 Conexões entre Atividades... 34 4.5 Pacote Organization... 37 4.5. Pacote Resources... 37 4.5.. Recursos de Uso Exclusivo (Exclusive Resources)... 40 4.5..2 Recursos Compartilháveis (Shareable Resources)... 40 4.5..2. Recursos Consumíveis (Consumable Resources)... 40 4.5..3 Pacote Agent... 4 4.5..3. Agentes... 42 4.5..3.2 Cargos... 43 4.5..3.3 Habilidades... 43 4.5..3.4 Grupos... 43 4.5.2 Pacote TaskAgenda... 43 4.6 Pacote Artifacts... 45 4.7 Pacote Tools... 45 4.8 Pacote ProcessKnowledge... 46 4.8. Métricas... 48 4.8.2 Estimativas... 49 4.9 Pacote OrganizationPolicies... 49 4.0 Pacote Policies... 50 4. Pacote StaticPolicies... 5 4.2 Pacote InstantiationPolicies... 53 4.3 Pacote Planner_Info... 57 4.4 Pacote Exceptions... 57 5 ARQUITETURA DAS APLICAÇÕES CLIENTE... 6 5. Arquitetura da Agenda do Desenvolvedor... 6 5.. Modelo de Dados da WebAPSEE Agenda (AgendaModel)... 6 5..2 Interface com o Usuário... 63 5.2 Arquitetura do Manager Console... 64 5.2. Editor Gráfico de Processos... 64 5.3 Troca de Mensagens para um Caso de Uso... 68 6 MÁQUINA DE EXECUÇÃO DE PROCESSOS DE SOFTWARE... 70 6. Gramática de Grafos... 70 6.. A Linguagem Visual de Modelagem de Processo... 70 6... O Grafo-Tipo... 7 6...2 Regras para a Execução de Processos... 72 6.2 Implementação das funcionalidades principais... 73 6.2. Enactment Engine Interface... 74 6.2.2 Dynamic Modeling Interface... 77 4
REFERÊNCIAS... 88 ANEXO (ARQUIVO DE MAPEAMENTO OBJETO-RELACIONAL)... 90 5
Lista de Figuras Figura Diagrama de Casos de Uso do Manager Console... 0 Figura 2 Extensão do Diagrama de Casos de Uso do Manager Console... 0 Figura 3 Diagrama de Casos de Uso da Agenda... Figura 4 - Camadas que compõem a Arquitetura do ambiente WebAPSEE... 2 Figura 5 Implantação física dos componentes principais... 3 Figura 6 - Visão da Arquitetura com o Fluxo de Controle... 4 Figura 7 - Arquitetura do Cliente... 7 Figura 8 - Fragmento do modelo de dados da ferramenta WebAPSEE... 22 Figura 9 - Mapeamento Objeto Relacional. (a) classes; (b) modelo relacional... 23 Figura 0 - Meta-modelo WebAPSEE (diagrama de Pacotes UML)... 25 Figura - Pacote Types - Hierarquia de tipos do WebAPSEE... 26 Figura 2 - Pacote Log... 27 Figura 3 - Pacote SoftwareProcesses... 28 Figura 4 - Pacote ProcessModels Descrição de Processos de Software... 29 Figura 5 - Pacote Activities Atividades de Processos de software... 32 Figura 6 - Pacote PlainActivities... 33 Figura 7 - Pacote SoftwareProcesses.Connections... 36 Figura 8 - Pacote Organization Aspectos da Estrutura Organizacional... 37 Figura 9 - Pacote Resources - Informações sobre os recursos da organização... 39 Figura 20 - Pacote Agent Informações Sobre Agentes... 42 Figura 2 - Pacote TaskAgenda... 44 Figura 22 - Pacote Artifacts Artefatos de Processos de Software... 45 Figura 23 - Pacote Tools... 46 Figura 24 - Pacote ProcessKnowledge...47 Figura 25 Pacote Organization.OrganizationPolicies... 50 Figura 26 Políticas da Organização... 5 Figura 27 Políticas Estáticas... 52 Figura 28 Políticas de Instanciação... 55 Figura 29 Visão em camadas da associação de políticas a processos e recursos... 57 Figura 30 Pacote Planner Info (Instanciação de Processo)... 59 Figura 3 Pacote de Exceções do WebAPSEE... 60 Figura 32 Diagrama de Pacotes para a Arquitetura da WebAPSEE Agenda... 6 Figura 33 Diagrama de Classes do Pacote Model... 62 Figura 34 Operações suportadas pela AgendaModelInterface... 63 Figura 35 Classes da Interface Gráfica com o Usuário... 64 Figura 36 Visão em camadas... 65 Figura 37 Diagrama de Classes Geral (visão simplificada sem atributos e operações)... 65 Figura 38 Diagrama de Classes da Camada de Nós... 66 Figura 39 Diagrama de Classes da Camada de Seleção... 66 Figura 40 Diagrama de Classes da Camada de Arestas... 67 Figura 4 Diagrama de Classes da Aresta... 67 Figura 42 Diagrama de seqüência para o caso de uso Inserir Atividade Normal... 68 Figura 43 - Representação gráfica para as principais construções da Linguagem de Modelagem de Processo do WebAPSEE... 7 Figura 44 - Principal regra para o início da execução de processos.... 73 Figura 45 -Módulos EnactmentEngineInterface e DynamicModelingInterface... 74 Figura 46 - Diagrama de transição de estados de uma Atividade.... 75 Figura 47. Rule G.. Adicionando uma nova atividade... 77 Figura 48 Rule G3.2. Adicionando Uma nova conexão simples... 78 6
Introdução Grande investimento vem sendo feito pela Academia e Indústria na construção de ferramentas que auxiliem o gerenciamento do processo de desenvolvimento de software, constituindo uma área de pesquisa denominada Tecnologia de Processo de Software. A Tecnologia de Processo de Software ganhou maior atenção a partir da ênfase dada ao uso de modelos como o Capability Maturity Model - usado para avaliação da qualidade de software a partir da maturidade dos processos organizacionais adotados pelos desenvolvedores. Assim, com o uso de ambientes para automação do processo de software (genericamente denominados como Process-Centered Software Engineering Environments - PSEEs), é possível coordenar atividades de equipes dispersas geograficamente, acompanhar os prazos e consumo de recursos, além de facilitar a reutilização de boas práticas gerenciais por diferentes projetos adotados. As soluções desenvolvidas nesta área devem levar em consideração elementos específicos do contexto de processos de software, tais como: o caráter criativo do processo, a grande tendência a mudanças, a impossibilidade de se reutilizar imediatamente processos executados e a falta de visibilidade do produto resultante. Atualmente, não existem PSEEs que sejam amplamente difundidos nas comunidades de desenvolvimento de software. A indústria tem fornecido apenas soluções para documentar processos (como Rational Method Composer), que pouco oferecem além das tradicionais ferramentas de diagramação, constituindo o estado da prática no setor. Este texto trata, portanto, da descrição técnica de um ambiente denominado WebAPSEE com objetivo principal de fornecer um nível maior de automação para a gestão de processos de software. As sub-seções a seguir descrevem e contextualizam os objetivos do ambiente servindo como referência técnica para subsidiar trabalhos futuros relacionados.. Objetivos do Projeto WebAPSEE Ambientes de desenvolvimento de Software Centrados em Processos (também conhecidos como PSEEs - Process-Centered Software Engineering Environments) relacionam-se com o problema de como sistemas computadorizados podem ser utilizados no desenvolvimento de software, ou seja, software para ajudar a construir software. Sua finalidade principal é atender a requisitos organizacionais para auxiliar na coordenação das atividades relacionadas com o desenvolvimento de software. A crescente exigência das organizações de desenvolvimento de software e o mercado consumidor influenciam decisivamente no gerenciamento de projetos. Assim, o desenvolvimento de PSEEs atuais requer a integração de diversas ferramentas voltadas para os seguintes domínios: auxílio à modelagem de processos segundo múltiplas perspectivas diferentes, auxílio na alocação de pessoas e recursos a processos, auxílio à monitoração da execução de processos (por exemplo, monitoração por eventos e visualização adequada do estado do processo), distribuição de informações para suporte às novas estruturas de terceirização do mercado, e também para integração do ambiente com outras ferramentas de apoio ao desenvolvimento de software. O objetivo geral do projeto é disponibilizar a funcionalidade de Gerência de Processos de Software baseados em Software Livre. Isto ocorre em resposta à demanda por soluções que integrem diferentes serviços necessários para desenvolvimento de software em 7
prol de uma Sociedade de Serviços livres, que permita sua utilização independente da linguagem de programação ou plataformas adotadas. Destaca-se ainda a necessidade de se propor uma solução escalável, isto é, que demonstre na prática a viabilidade tanto na condução de pequenos projetos quanto na coordenação de atividades envolvendo grande quantidade de profissionais dispersos geograficamente..2 Histórico O projeto do ambiente WebApsee vem de uma experiência no desenvolvimento de um PSEE de nova geração isto é, baseada em padrões da Web e em Software Livre - que adota soluções inovadoras para problemas críticos relacionados com a gerência e execução automatizada de processos de software. Assim, questões relativas à flexibilidade na alteração dinâmica em processos em execução, e apoio automatizado para seleção de desenvolvedores e reutilização de processos estão disponíveis no ambiente APSEE - desenvolvido desde 998 em cooperação entre a UFPA, UFRGS e Universität Stuttgart (Alemanha). Com o surgimento de tecnologias baseadas em Web Services houve uma evolução significativa no desenvolvimento de software baseado na Internet, ao facilitar a intercomunicação de sistemas através de um middleware aberto, multiplataforma, e baseado em padrões da Web. Havia, então, uma oportunidade de se desenvolver um novo PSEE baseado na noção de uma arquitetura flexível que acomode novos componentes, seja multiplataforma, e disponível para evolução contínua através da comunidade de Software Livre. A integração das idéias e modelos gerados com o projeto APSEE com Web Services resultou no projeto Web Process Services. O principal resultado concreto obtido pelo projeto é um produto de software funcional, mas ainda em evolução, denominado WebAPSEE. Convém ressaltar que a versão atual (versão ) do WebAPSEE está implementada tendo por base apenas o protocolo RMI (Remote Method Invocation) fornecido pela Sun na linguagem Java. Entretanto, a arquitetura do ambiente foi projetada de forma que a alteração para uso de Web Services seja trivial, podendo ser facilmente realizada pelo usuário-final..3 Organização do Texto Este texto apresenta um detalhamento sobre a construção do ambiente WebApsee. O texto foi organizado da seguinte forma: A seção 2 apresenta uma visão geral das funcionalidades do ambiente. A seção 3 apresenta a arquitetura do sistema. A seção 4 apresenta o modelo de dados principal do ambiente. A seção 5 apresenta a arquitetura interna das ferramentas que são clientes e a seção 6 apresenta o funcionamento da máquina de execução de processos. 8
2 Visão Geral das Funcionalidades do WebAPSEE Este capítulo apresenta uma visão geral das funcionalidades fornecidas pelo ambiente WebAPSEE na forma de suas duas ferramentas principais: o Manager Console (descrito na seção 2.) e a Task Agenda (seção 2.2). 2. Manager Console A modelagem de processos de desenvolvimento de software requer formalismos de alto nível para descrever aspectos de coordenação das atividades e relacionamento com a organização. Estes formalismos devem ser convenientes não somente para representação, mas também para execução. Com base nisso é proposto um formalismo de modelagem para o WebAPSEE que permite representação gráfica de processos. A linguagem de modelagem de processos de software do WebAPSEE (denominada WebAPSEE-PML 2 ) é baseada em redes de atividades que podem ser decompostas. Neste formalismo, um modelo de processo pode ser construído a partir de símbolos gráficos conectados e o detalhamento do relacionamento com os outros componentes do modelo (como por exemplo, as informações organizacionais e descrição dos artefatos, entre outros) é feito através de formulários específicos que apóiam essa tarefa. O WebAPSEE permite a integração de vários serviços de gerência de processos, incluindo modelagem, execução, visualização, instanciação e resposta a eventos da execução. Através do Manager Console o Gerente do Processo de Desenvolvimento de software pode Modelar Processos, Gerenciar Execução de Processos, Visualizar Relatórios do Processo e Gerenciar informações da Organização, como artefatos, pessoas e recursos, através de um Editor Gráfico. Na Figura é apresentado o Diagrama de Casos de Uso do Manager Console. O Caso de Uso Gerenciar informações da Organização inclui algumas funcionalidades que devem ser especificadas, para isso foi gerado um Diagrama com a extensão do Caso de Uso em questão, conforme ilustrado na Figura 2. O Manager Console oferece suporte ao cadastro e gerência de projetos, recursos, artefatos, gerência de políticas através das políticas de processos, o que for considerado exceção no modelo de processo (atrasado demasiado, não há pessoa alocada na tarefa, entre outras) pode ser modelado Adição, remoção e modificação de atividades e pessoas, gerência de métricas/estimativas de maneira sistemática (as métricas podem ser cadastradas pelo gerente). Admitindo-se como objetivo um nível maior de automação. 2 PML: Process Modelling Language (Linguagem de Modelagem de Processo). 9
Figura Diagrama de Casos de Uso do Manager Console 2.2 Task Agenda Figura 2 Extensão do Diagrama de Casos de Uso do Manager Console Através da Agenda o desenvolvedor visualiza os processos de software em execução nos quais está inserido como uma lista de tarefas a serem realizadas. Assim, o desenvolvedor interage com a agenda fornecendo feedback sobre o andamento dessas tarefas. O WebAPSEE possui um mecanismo de execução que tem como um dos principais objetivos manter a consistência entre o estado de execução do processo e o estado real da realização das tarefas. Para isso é necessário que os desenvolvedores forneçam 0
feedback sobre o estado real das tarefas e este feedback é fornecido utilizando a WebAPSEE Task Agenda. O usuário desenvolvedor visualiza o andamento de um processo de software através de uma lista de tarefas. A WebAPSEE Task Agenda fornece essa visão através do gerenciamento dos dados sobre os processos e tarefas que o usuário está inserido. O usuário escolhe um processo o qual participe e então a agenda mostra uma lista de tarefas para este usuário relacionadas a este processo. Os desenvolvedores podem delegar tarefas aos seus subordinados, e cada desenvolvedor gerencia os Artefatos das suas próprias tarefas. A Figura 3 ilustra o Diagrama de Casos de Uso das Funcionalidades fornecidas pela Agenda. Figura 3 Diagrama de Casos de Uso da Agenda
3 Arquitetura do Sistema Para prover todos os serviços necessários que um PSEE necessita fornecer aos seus usuários, como por exemplo, a visualização macro das atividades para o gerente, o envio de instruções ao desenvolvedor de como proceder em suas tarefas, entre outras [9], foi desenvolvida uma arquitetura orientada a serviços. A localização distribuída de agentes (desenvolvedores) e gerentes de processo exige uma arquitetura que provenha serviços distribuídos através de uma rede (Intranets e Internet), utilizando para tal algum protocolo de distribuição. Podem ser utilizados protocolos de distribuição tanto enquadrados nos protocolos de desenvolvimento para a WWW [8] quantos protocolos proprietários de distribuição dos dados, dependendo dos requisitos de interatividade do sistema. O sistema WebAPSEE utiliza uma abordagem voltada para padrões Web, para interoperabilidade com ferramentas externas através do uso dos web services [7] e distribuição de objetos através da linguagem Java [5], dependendo da configuração mais apropriada para o ambiente do usuário do sistema. Conforme demonstrado na Figura 4, a arquitetura do sistema WebAPSEE se divide em 3 camadas principais: A) Camada Servidora, que provê serviços de persistência, verificação de consistência para modelagem, controle e armazenamento de artefatos e execução de modelos de processos de software; B) Camada Cliente, que basicamente oferece uma infra-estrutura para acesso aos serviços da camada servidora; C) Camada de ferramentas clientes, que possui as ferramentas que interagem diretamente com GUI 3 para entrada de dados, modelagem de modelos de processos (através de sua PML - Process Modeling Language) e visualizações de informações obtidas do servidor. Figura 4 - Camadas que compõem a Arquitetura do ambiente WebAPSEE O ambiente WebAPSEE provê suporte a requisitos considerados essenciais para modelagem e execução de processos de software, podendo citar gerência de recursos, modelagem de processos, execução de modelos de processos e permitir modificações dinâmicas em processos em execução, mantendo a consistência do mesmo a partir do uso de regras ECA 4 implementadas no sistema [0]. 3 GUI - Graphical User Interface 4 Evento Condição-Ação 2
3. Distribuição Física dos Componentes Os componentes principais do WebAPSEE são: o servidor (WebAPSEE Server, o qual não é interativo), o Manager Console (software executado pelo Gerente, com interface gráfica), e a Agenda de Tarefas (executado pelo desenvolvedor). Tais componentes estão descritos nas seções a seguir. A Figura 5 apresenta a disposição física típica para os nós de hardware rotulados como Cliente (divididos em Developer Workstation e Manager Workstation), e Servidor (Server). Algumas variações podem acontecer nesta configuração: por exemplo, uma organização pode agregar as funcionalidades da Manager Workstation e WebAPSEE Server em um único nó, se o interesse for criar uma configuração de teste ou de pequena escala do sistema. Figura 5 Implantação física dos componentes principais 3.2 Camada Servidora A camada servidora provê serviços de persistência, verificação de consistência para modelagem, controle e armazenamento de artefatos e execução de modelos de processos de software. Esta pode ser dividida da seguinte maneira: A Camada de Distribuição, onde são definidas as tecnologias necessárias para os serviços que estão disponíveis; a Camada de Integração, onde são utilizadas as classes Fachadas para integrar os serviços; as Classes de Negócio; e, finalmente, a Camada de Persistência, onde é feito o mapeamento e armazenamento das informações do sistema. Na Figura 6 é mostrada uma visão da arquitetura da camada servidora com o Fluxo de Controle entre seus componentes. 3
Figura 6 - Visão da Arquitetura com o Fluxo de Controle 3.3 Camada Cliente A seguir é feita uma descrição dos componentes que formam a Camada Cliente do sistema. A descrição é feita levando-se em consideração as questões tratadas desde o início do desenvolvimento do sistema. 3.3. Clientes Básicos ) O que é? Consistem em clientes que proporcionem o acesso a funcionalidades básicas do sistema WebAPSEE. Estes clientes fornecem acesso a uma agenda simplificada para desenvolvedor e gerente, para que estes possam ter acesso básico ao sistema sem ser necessário desenvolver um cliente específico para o sistema. 4
2) Tecnologias utilizadas No desenvolvimento destes clientes básicos são utilizadas tecnologias para desenvolvimento de uma interface amigável que facilite a navegação pelo sistema. 3) Papel na arquitetura Estes clientes fornecem acesso básico ao sistema e têm papel fundamental no momento dos testes de produção que são realizados para verificar a consistência do funcionamento do sistema. 4) Relacionamentos Estes clientes se relacionam diretamente com a camada de distribuição do sistema WebAPSEE, podendo ser desenvolvidos clientes com web services, RMI, CORBA ou outro protocolo de distribuição, dependendo da implementação do Servidor. Isto decorre em função desta camada ser externa ao sistema, pois apenas são acessados os serviços que estão disponíveis em sua interface de distribuição. 5) Risco de implementação Baixo, pois utiliza tecnologias web já bastante difundidas e conhecidas para construir a sua interface. 3.3.2 Clientes Completos ) O que é? Consistem em clientes que provêem acesso completo ao sistema, com interfaces gráficas mais elaboradas e robustas, com acesso ao sistema WebAPSEE através dos protocolos de distribuição. 2) Tecnologias utilizadas Para desenvolvimento destes clientes, são utilizados recursos avançados de interfaces gráficas. O cliente poderá ter acesso a sua agenda de desenvolvimento e o gerente poderá ter acesso aos processos do sistema e modelar o processo que coordena através de recursos gráficos e visuais, assim como são providos pela agenda do sistema APSEE Manager, ferramenta do sistema APSEE em sua versão implementada na plataforma PROSOFT 5. 3) Papel na arquitetura Estes clientes formam o Front-End do sistema WebAPSEE com os clientes que têm acesso à ferramenta. O desenvolvimento destes clientes não impede que 5 PROSOFTPROSOFT é a plataforma de desenvolvimento na qual o sistema APSEE foi originalmente desenvolvido, o qual é mantido e desenvolvido no Instituto de Informática da Universidade Federal do Rio Grande do Sul (http://www.inf.ufrgs.br/~prosoft). 5
outros clientes possam ser desenvolvidos para acessar alguma funcionalidade específica do sistema WebAPSEE de alguma forma mais particular. Estes clientes desenvolvidos não impedem que extensões possam ser desenvolvidas posteriormente para acesso ao sistema, como ferramentas integradas a algum ambiente integrado de desenvolvimento de software (IDE Integrated Development Environment) ou a integração a algum outro sistema existente. 4) Relacionamentos Assim como os cientes básicos supracitados, estes clientes se relacionam diretamente com a camada de distribuição do sistema WebAPSEE, podendo ser desenvolvidos clientes para os web services, RMI, ou outro protocolo de distribuição, dependendo da implementação do Servidor. Por critério de segurança e portabilidade, recomenda-se sempre se desenvolver clientes para o acesso direto à camada de web services, pois isso permite que clientes possam desenvolvidos nas mais diversas linguagens de programação e plataformas. 5) Risco de implementação Alto, não devido ao uso da tecnologia utilizada, mas em maior risco atribuído à complexidade de se construir uma ferramenta de modelagem gráfica que atenda a todos os requisitos definidos pelo atual linguagem gráfica, implementada no ambiente PROSOFT. 3.3.3 Arquitetura do Cliente A Figura 7 apresenta uma visão geral da arquitetura dos clientes do sistema WebAPSEE, baseando-se numa visão de pacotes. A disposição dos pacotes representa as mesmas funcionalidades descritas na Figura 6 (camada inferior é composta pelo pacote mais à direita e camada superior é composta pelos pacotes mais à esquerda). Os pacotes gui, editor e reports representam o front-end do ambiente com o usuário, tendo as seguintes funcionalidades, respectivamente: disponibilizar componentes de interação e acesso aos dados internos do sistema (formulários, árvores, entre outros elementos gráficos manipulados pelo usuário); fornecer um editor visual de modelos de processos de software, com suporte para múltiplas visualizações do modelo; suporte para geração de relatórios gerenciais no sistema. 6
editor model i8n exceptions datarepository datatransform gui dataexport reports Figura 7 - Arquitetura do Cliente 3.4 Camada de Distribuição 3.4. Serviços Disponíveis ArtifactMngFacade Serviço de gerência dos artefatos do sistema. Os artefatos são armazenados e gerenciados por alguma implementação de sistema de controle de versões, para manter a consistência dos dados modificados durante a execução do modelo de processos. DataSourceFacade Serviço de gerência de objetos do sistema, que é responsável pelas operações de recuperação e persistência dos dados manipulados pelos clientes. 7
DynamicModelingFacade Serviço responsável pelas operações de manipulação de modelos de processos de software no momento de modelagem. Cada operação é validada a partir de uma série de regras que são checadas, para que se evitem ciclos e inconsistências do modelo de processos gerado. EnactFacade Serviço responsável pelas operações de execução de um modelo de processos de software. Estas operações obedecem regras definidas para a execução e o modelo de processos que foi definido em tempo de modelagem. Conforme o processo evolui na sua execução, atividades são delegadas, artefatos liberados para uso e recursos são consumidos. 3.4.2 Facade Factory ) O que é? Camada de ligação estática entre as camadas de integração e camada de distribuição. 2) Tecnologias adotadas Esta camada não utiliza nenhuma tecnologia extra, além da definição estática de classes e padrões de projetos. 3) Papel na arquitetura A definição estática serve para que os EJB, que são entidades instanciadas dinamicamente, possam ter como localizar em tempo de execução as referências para as classes fachadas da camada de integração. Os padrões de projetos utilizados são: Singleton e Abstract Factory. 4) Relacionamentos Relaciona-se com a camada de distribuição, mais diretamente com os EJB's, e com a camada de integração, ou mais especificamente com as fachadas do subsistema interno. O uso do padrão de projeto Singleton se justifica pelo fato de ser necessário manter o controle de apenas uma instancia da classe de fábrica abstrata (no padrão Abstract Factory), que será a classe que irá retornar as instâncias das fachadas correspondentes na camada de integração. Desta forma, esta camada relaciona a camada de distribuição com a camada de integração. 5) Risco de implementação Baixo, pois esta camada é apenas a implementação de padrões de projetos bem definidos e conhecidos. Sua implementação é necessária para manter uma 8
separação de papéis no momento de diferenciar as interfaces dos EJB s com as interfaces dos serviços providos pelas fachadas do sistema interno. 3.5 Camada de integração (Fachadas) 3.5. Fachadas ) O que é? É uma camada de interface composta por classes Java tradicionais, que seguem o padrão de projeto Façade. 2) Tecnologias adotadas Somente classes Java tradicionais aplicadas ao padrão de projeto Façade. 3) Papel na arquitetura As classes Fachadas têm como papel oferecer serviços bem definidos e modularizados (classificados por funcionalidade) entre duas camadas do sistema: as Classes de negócio e Facade Factory. 4) Relacionamentos Relaciona-se com as Classes de Negócio e a Facade Factory. 5) Risco de Implementação Baixo, pois se trata apenas de separar as funcionalidades do sistema que serão requisitadas pelos usuários em suas respectivas fachadas e não re-implementar algum método. 3.5.2 Acesso BD Fachada responsável por tratar transações com o Banco de Dados. Inserções, remoções, alterações e consultas realizadas diretamente pelo usuário, deverão passar por essa fachada. 3.5.3 Execução Fachada responsável por executar os processos modelados pelo gerente do processo. A classe Java que implementa essa funcionalidade é a classe EnactmentEngine que possui métodos para a execução propriamente dita. 3.5.4 Segurança Fachada responsável por tratar a segurança do sistema. O Controle de Acesso é tratado nesta fachada. 3.5.5 Instanciação Fachada responsável por instanciar processos. Atribuição de agentes e recursos a uma atividade é tratada nesta fachada. 9
3.6 Classes de Negócio ) O que é? São classes Java convencionais responsáveis pela gerência da informação e execução dos processos, ou seja, a Máquina de Execução está entre essas classes e seus métodos. 2) Tecnologias adotadas Classes Java tradicionais com tags (em forma de comentário) do framework Hibernate embutidas em seus códigos. 3) Papel na arquitetura Realização das tarefas de negócio, ou seja, gerenciam a informação e executam os processos. 4) Relacionamentos Relacionam-se com as classes Fachadas e com o framework Hibernate. 5) Risco de Implementação Alto, pois se trata das classes que possuem os métodos não convencionais (get e set) como os métodos da execução, por exemplo. 3.7 Camada de Persistência 3.7. Camada de Mapeamento ) O que é? São tags do framework Hibernate embutidos nas classes Java de negócio que devem ser persistentes, juntamente com seus arquivos de configuração e arquivos gerados para o mapeamento objeto-relacional. 2) Tecnologias adotadas Framework Hibernate para o Mapeamento Objeto-Reacional. 3) Papel na arquitetura Prover uma forma automatizada do mapeamento para armazenar os objetos (simples e compostos) em um banco de dados relacional. 4) Relacionamentos Relaciona-se com as classes Java de negócio e com o SGBD Relacional MySQL. 20
5) Risco de Implementação Médio, pois se trata de um script que lê as tags do Hibernate e gera o esquema especificado automaticamente, porém, é uma tecnologia nova. 3.7.2 Camada de Banco de dados ) O que é? É a camada que trata do armazenamento físico das classes persistentes em um SGBD relacional. 2) Tecnologias adotadas SGBD Relacional MySQL. 3) Papel na arquitetura Manter consistente as informações do Sistema. 4) Relacionamentos Relaciona-se com o framework Hibernate. 5) Risco de Implementação Baixo, pois o armazenamento é feito pelo framework Hibernate. 3.8 Mapeamento Objeto-Relacional do Modelo de Dados Os Sistemas Gerenciadores de Banco de Dados Relacionais (SGBDR) correspondem à tecnologia mais utilizada atualmente no que se refere à persistência de dados. Todavia esta tecnologia apresenta diversas limitações quando utilizada em conjunto com o paradigma de orientação a objetos [6]. Como uma tentativa de solucionar este problema, é desenvolvida a técnica de Mapeamento Objeto-Relacional (Object-Relational Mapping), que corresponde ao processo de integração entre o modelo de classe e o modelo relacional, bem como entre os sistemas que suportam essas abordagens [6]. Inserido nesse contexto, esta seção objetiva descrever de que forma o mecanismo de ORM foi utilizado no ambiente WebAPSEE [9] para mapear para o modelo relacional as classes do modelo de negócio do referido ambiente. 3.8. Mapeamento do modelo de classes (Herança) Herança representa uma importante incompatibilidade entre os paradigmas objeto e relacional. Enquanto que o modelo orientado a objetos provê suporte à modelagem tanto de relacionamentos é uma (herança) como de relacionamentos em uma (associação), o modelo relacional suporta apenas esse último tipo de relacionamento tem uma [3]. 2
Conforme [3], podemos identificar três técnicas principais para representar uma hierarquia de herança entre classes: Tabela por classe concreta: consiste em descartar o polimorfismo e as relações de herança completamente do modelo relacional; Tabela por hierarquia de classe: habilita o polimorfismo através da quebra do padrão de modelagem relacional, a informação de tipo é expressa através de uma coluna discriminadora de tipo; Tabela por subclasse: emula relacionamentos de herança a partir de relacionamentos de chave estrangeira. Foi escolhida a opção de tabela por subclasse para mapear o modelo do ambiente WebAPSEE. Essa técnica será explicada a partir de um exemplo de mapeamento de hierarquia de classes do modelo em questão. 3.8.2 Exemplo de mapeamento Todo o modelo de classes do WebAPSEE foi mapeado para o mecanismo de persistência. Porém nesse texto restringimos a apresentação do mapeamento para uma parte do modelo, considerando que o restante do mapeamento pode ser feito de forma análoga. Foi escolhido o conjunto de classes que representam as atividades que podem ser tratadas no ambiente WebAPSEE, conforme pode ser visualizado na Figura 8, mostrada a seguir: Figura 8 - Fragmento do modelo de dados da ferramenta WebAPSEE Maiores informações sobre a semântica do modelo mostrado na Figura 8 podem ser encontradas em [0]. 3.8.3 Mapeamento Objeto-Relacional Conforme citado anteriormente, dentre as opções de mapeamento possíveis, foi escolhida a opção de mapeamento de tabela por sub-classe, a qual consiste em representar os 22
relacionamentos de herança como associações de chaves estrangeiras relacionais. Dessa forma, toda subclasse (inclusive classes abstratas) que declara pelo menos uma propriedade persistente, possui sua própria tabela. A principal vantagem desta técnica é que o modelo relacional é completamente normalizado. Uma associação polimórfica para uma subclasse particular pode ser representada como uma chave estrangeira apontando para a tabela da subclasse correspondente, bem como a evolução de esquema e a definição de restrição de integridade são imediatas. Todas estas funcionalidades representam requisitos essenciais para um PSEE, conforme identificado em [6]. A seguir será descrito de que forma a estratégia supracitada foi aplicada para mapear o fragmento do modelo de dados representado na Figura 8 para o modelo relacional. Como cada classe da hierarquia é mapeada para uma tabela correspondente na base de dados, cada tabela contém somente as colunas para cada propriedade non-inherited (não herdada) da classe correspondente. Além dessas colunas, cada tabela possui ainda uma chave primária que também é uma chave estrangeira da tabela da superclasse. Esta estratégia é mostrada na Figura 9. Para auxiliar a gerência de persistência dos objetos do WebAPSEE, utilizou-se o Hibernate, um framework de mapeamento O-R (Objeto-Relacional) Livre e atualmente sendo amplamente utilizado na gerência de persistência em ambientes orientados a objetos desenvolvidos na plataforma Java. Figura 9 - Mapeamento Objeto Relacional. (a) classes; (b) modelo relacional Compreendendo um projeto de pesquisa amplamente difundido na comunidade, o Hibernate tem como proposta prover o mapeamento objeto-relacional de forma transparente ao desenvolvedor. Dessa forma esses últimos passam a se preocupar somente com a camada de negócio do software, sempre no nível do modelo de classes. Além dessa característica, ao se utilizar esse framework, a portabilidade do sistema entre SGBD s é amplamente favorecida, visto que o Hibernate pode ser configurado através de arquivos XML, não sendo necessário re-compilar o software na necessidade de migração entre SGBDs. 23
Está disponível no Anexo, o gabarito de arquivo XML referente ao mapeamento da hierarquia de classes para as tabelas correspondentes, informações relacionadas à sintaxe e semântica do arquivo podem ser encontradas em [3]. 24
4 Modelo de Dados Principal do WebAPSEE Esta seção apresenta o modelo conceitual do WebAPSEE e explica os pacotes existentes, suas classes e associações. 4. Descrição dos pacotes A Figura 0 mostra o diagrama de pacotes do meta-modelo WebAPSEE ilustrando os componentes a serem detalhados e seus relacionamentos de dependência. Alguns componentes do meta-modelo são refinados em novos pacotes. SoftwareProcesses APSEETypes Artifacts Tools Organization ProcessKnowledge Policies Figura 0 - Meta-modelo WebAPSEE (diagrama de Pacotes UML) 4.2 Pacote Types Os principais componentes da arquitetura WebAPSEE são tipados, ou seja, são classificados através de tipos predefinidos. O pacote Types contém as hierarquias de tipos para os componentes do WebAPSEE. Neste caso, são propostas as hierarquias de tipos principais, fornecidas juntamente com o modelo, mas o usuário do ambiente poderá criar novas hierarquias de tipos e instâncias para hierarquias existentes de acordo com as necessidades da organização ou do processo. 25
As hierarquias de tipos apresentadas na Figura são: recursos, cargos, grupos, habilidades, métricas, atividades, conexões, políticas, artefatos, ferramentas e eventos. O pacote Types exerce um papel importante na descrição do modelo, visto que a maioria dos componentes do meta-modelo WebAPSEE estão associados a um tipo (Type) que deve existir na hierarquia correspondente. As hierarquias de tipos relacionadas aos componentes do WebAPSEE permitem que sejam descritos processos abstratos que podem ser refinados conforme necessário para execução ou usados para reutilização e ainda apóiam a descrição de mecanismos que lidam com elementos genéricos de processos. Essa estrutura de tipos aumenta a flexibilidade do modelo facilitando o processo de extensão do mesmo. É importante observar que a hierarquia de tipos ActivityType serve para designar tanto os tipos de atividades quanto os de processos de software pois atividades podem ser decompostas em processos. +supertype 0.. Type id : String description : String userdefined : boolean +subtype Type() ArtifactType ActivityType RoleType ResourceType EventType PolicyType ArtifactType() ActivityType() RoleType() ResourceType() EventType() PolicyType() ToolType GroupType AbilityType MetricType ConnectionType ToolType() GroupType() AbilityType() MetricType() ConnectionType() Figura - Pacote Types - Hierarquia de tipos do WebAPSEE 4.3 Pacote Log O principal elemento do modelo de gerência de eventos proposto é o pacote Log, queconsiste de um conjunto de classes e regras para registro de eventos. Esta seção é responsável por apresentar a estrutura de dados principal para armazenar informações acerca de ocorrência de eventos. Como mostra a Figura 2, o pacote Log compreende todos os eventos do APSEE. Seu objetivo é armazenar informação sobre o que aconteceu (atributo What), quando aconteceu (atributo When), quem foi o responsável, neste caso pode ser o mecanismo de execução (atributo isapsee indica se o responsável é o APSEE Manager), o agente ou a atividade (atributo Who indica o responsável), e a razão da ocorrência do evento (atributo Why). O valor do atributo What está relacionado com uma instância específica do catalógo de eventos (classe EventsCatalog) ou pode armazenar a identificação da regra que foi responsável pela ocorrência. 26
Figura 2 - Pacote Log 27
Cada processo de software no ambiente APSEE tem um log (ou seja, uma instância da classe Log), que é composta por eventos (classe Event). Eventos estão relacionados aos seguintes componentes do APSEE: recursos, modelos de processos, atividades (visão global, visão do desenvolvedor e eventos de modelagem), conexões entre atividades, e o próprio processo de software. 4.4 Pacote SoftwareProcesses O pacote SoftwareProcesses (ver Figura 3) foi dividido em sub-pacotes. Seus componentes são os modelos de processos de software (ProcessModels), atividades (Activities), Atividades simples (PlainActivities) e conexões (Connections). O pacote ProcessModels, mostrado na seção a seguir, é o componente principal do pacote SoftwareProcesses e tem como objetivo descrever as características de um processo de software e seu relacionamento com os outros componentes do meta-modelo. Figura 3 - Pacote SoftwareProcesses 4.4. Modelos de Processos O pacote SoftwareProcesses.ProcessModels (Figura 4) contém o modelo para descrever processos de software em diferentes estados de modelagem e de execução. Um processo da classe Process possui um identificador, um tipo na hierarquia de tipos de atividades, um estado e um modelo de processo. O estado do processo (p_state) pode ser: Not_Started, (o processo não foi iniciado), Enacting (o processo está em execução) ou Finished (o processo foi concluído). A distinção entre processo e modelo de processo (ProcessModel) se faz necessária para determinar a situação geral do nodo raiz da rede de atividades, pois modelos de processo são definidos de forma recursiva (são compostos de atividades que podem ser decompostas em novos modelos de processo). 28
Agent (from Agent) id : String name : String email : String description : String GraphicalDescriptor oid : Integer name : String typedescription : String des criptorfile : java.s ql.blob costhour : Float ProcessModelEvent password : String (from Log) +thegraphicaldescriptor photo : java.sql.blob why : String staticok : boolean V describes ProcessModelEvent() Agent() +registers +ismanagedby +theprocessmodeldescribed ProcessModel manages <<ordered>> pmstate : String +isregistered registers requirements : String +manages +hasprocessmodel staticok : boolean Process +belongsto ProcessModel() +composes id : String enable pstate : String +policyenabled Process() <<Abstract>> Policy +theprocess (from InstantiationPolicies) +iscomposedby hastype ident : String name : String Connection (from Connections) description : text Connection() +hastype Policy() ActivityType (from APSEETypes) +policyenabled enable +hastype ActivityType() Activity +theactivity (from Activities) hastype id : String name : String staticok : boolean Activity() Figura 4 - Pacote ProcessModels Descrição de Processos de Software O modelo de processo (ProcessModel) é composto basicamente de atividades e conexões entre atividades. O estado do modelo de processo (pm_state) é determinado dinamicamente em função de seu conteúdo e pode receber os seguintes valores: Requirements: o modelo de processo não possui nenhuma atividade, apenas uma descrição textual de seus requisitos (atributo requirements), ou ainda, possui somente atividades decompostas que estão no estado requirements; Abstract: o modelo de processo possui atividades que não estão relacionadas ao contexto da organização, ou seja, são genéricas. Neste estado as atividades indicam apenas os cargos necessários, os tipos de recurso e tipos de artefato; Instantiated: neste estado o modelo de processo já possui atividades instanciadas e pode ser executado; 29
Enacting: pelo menos uma das atividades do modelo de processo está sendo executada; Finished: todas as atividades do modelo de processo foram concluídas; Failed: todas as atividades do modelo de processo falharam. Esta situação é possível através da solicitação de um gerente. As conseqüências da falha são tratadas pelo mecanismo de execução; Cancelled: o modelo de processo foi cancelado e todas as atividades estão canceladas. Também é necessária a solicitação de um gerente para que o processo assuma este estado. A diferença com relação à falha é que somente processos não iniciados podem ser cancelados; Mixed: este estado é caracterizado quando os componentes do processo estão em diferentes estados sem caracterizar nenhum dos estados anteriores. Por exemplo, um processo que possui uma atividade falhada, outra concluída e uma outra atividade decomposta no estado requirements está no estado Mixed. 4.4.2 Atividades de um Processo As atividades de um processo de software estão descritas nos pacotes Activities e PlainActivities (apresentado na próxima seção). O diagrama de classes do pacote Activities é apresentado na Figura 5. Uma atividade pode ser simples (Plain) ou decomposta (Decomposed). Se a atividade for decomposta, então é definida por um novo modelo de processo e seu conteúdo é representado pela classe ProcessModel mostrada na seção anterior. Caso contrário trata-se de uma atividade simples (ou folha) na decomposição do modelo de processo. Como característica comum a todas as atividades, temos o controle das versões da atividade (associação has_versions). 4.4.2. Atividades Simples Normais e Automáticas O diagrama de classes do pacote PlainActivities é mostrado na Figura 6 e detalha a definição de atividades simples (Plain) como normais ou automáticas. Atividades automáticas (classe Automatic) não consomem recursos nem tempo e são realizadas através de chamadas a operações de ferramentas integradas no ambiente (por exemplo, compilar código). Já as atividades normais (classe Normal) necessitam de recursos, agentes e envolvem artefatos de entrada e saída, os quais são descritos de forma abstrata (tipos) e instanciada (identificadores dos componentes). Além disso, indicam condições que devem ser avaliadas antes e depois da execução da atividade (pré e pós-condição, respectivamente). Ambos os tipos de atividade possuem uma descrição de sua execução (classe EnactionDescription) que indica o estado da atividade, suas datas de início e fim e o registro de eventos ocorridos (classe Event). A idéia de armazenar os tipos necessários na descrição da atividade serve para aumentar a flexibilidade da definição do processo. O projetista de processo pode, durante a modelagem, definir apenas o tipo de recurso necessário e decidir qual recurso vai ser efetivamente utilizado no início da execução da atividade. Além disso, a descrição do processo através dos tipos necessários permite que um modelo de processo possa ser reutilizado em outro contexto, ou mesmo em outra organização. Atividades normais possuem cronograma abstrato com duração em dias (how long), datas de início e fim planejadas (planned_begin e planned_end), o script com os objetivos da atividade; e pré e pós-condições para a sua execução. Enquanto atividades automáticas podem ser executadas a partir de um script de sistema operacional definido pelo usuário (classe 30
Script) ou uma chamada a método de uma ferramenta integrada no ambiente (classe ClassMethodCall). O projetista de processos pode indicar quais os parâmetros (classe Parameters) a serem utilizados na chamada automática e qual o artefato de saída a ser gerado ou modificado (classe Artifact). O pacote Tools, a ser apresentado na seção 4.7, apresenta com mais detalhes a definição de chamadas automáticas. O estado da atividade (state) na classe EnactionDescription é o atributo que armazena a situação de cada atividade e serve de referência para a transição de estados de todo o processo de software. Os possíveis estados de uma atividade simples são descritos a seguir: Waiting: as dependências da atividade ainda não estão satisfeitas; Ready: pronta para começar; Active: a atividade está sendo realizada pelos agentes responsáveis (pelo menos um agente está trabalhando na atividade); Paused: todos os agentes solicitaram pausa da atividade; Finished: a atividade foi concluída. Se a atividade for cooperativa, significa que todos os agentes concluíram; Cancelled: a atividade foi cancelada antes de iniciar; Failed: a atividade falhou após o início por decisão dos agentes ou do gerente. 3
hasversions +isversion Plain requirements : Text Plain() <<ordered>> +hasversions Activity id : String name : String staticok : boolean Activity() Decomposed Decomposed() <<ordered>> +registers registers +isregistered +hasactivities +defines enable 0.. definedby ModelingActivityEvent (from Log) ModelingActivityEvent() +policyenabled +belongsto +definedby <<Abstract>> Policy (from InstantiationPolicies) ident : String name : String description : text Policy() +isreferredbymodelingactivityevent enable ProcessModel (from ProcessModels) pmstate : String requirements : String staticok : boolean ProcessModel() +policyenabled who Agent id : String name : String email : String description : String costhour : Float password : String photo : java.sql.blob staticok : boolean Agent() (from Agent) +refersto Figura 5 - Pacote Activities Atividades de Processos de software 32
0.. EnactionDescription actualbegin : Date actualend : Date state : String Plain GlobalActivityEvent <<ordered>> (f rom Activ ities) (f rom Log) requirem ents : Text registers why : String execute 0.. Subroutine (f rom Tools) PrimitiveParam Autom atic Parameters description : String result ArtifactParam refersto Normal howlong : int plannedbegin : date plannedend : date s cript : Text in Artifact (f rom Artif acts) id : String description : String name : String path : String staticok : boolean Artifact() pos out InvolvedArtifacts type 0.. ArtifactType (f rom APSEETy pes) involves 0.. pre 0.. requires Condition description : Text requires requires GroupType (f rom APSEETy pes) RequiredResource amountneeded : real ResourceType (f rom APSEETy pes) requires RequiredPeople uses 0.. Resource (from Resources) id : String name : String description : String mtbftime : Real mtbfunittime : String cost : Real staticok : boolean Role (f rom Agent) requires ReqGroup ReqAgent ReqAgentRequiresAbility responsible responsible degree : integer 0.. 0.. Agent Group (f rom Agent) (f rom Agent) Ability (f rom Agent) Ability() Figura 6 - Pacote PlainActivities 33
4.4.2.2 Conexões entre Atividades As conexões servem para interligar atividades representando o fluxo de controle e de dados do processo. O modelo leva em consideração a necessidade de modelagem de processos utilizando fluxos de controle de alto nível que possam ser refinados durante a execução e que expressem vários tipos de precedência entre atividades. Portanto, são propostos os fluxos de controle de seqüência, de feedback (retorno a uma atividade anterior) e envolvendo várias atividades (branch e join). Esses fluxos de controle e de dados são representados no modelo através de conexões que são chamadas de: conexões simples, conexões múltiplas e conexões de artefato. As conexões simples podem ser de seqüência ou de feedback, enquanto que as conexões múltiplas são branch e join combinados com operadores lógicos. As conexões simples e múltiplas também possuem um tipo de dependência (end-start, start-start, end-end) que influencia diretamente na execução das atividades e pode representar diferentes dependências encontradas em processos reais. As conexões de artefato não influenciam no fluxo de controle do processo, servindo para descrever o fluxo de informações entre atividades, mas podendo ser ligadas a conexões múltiplas. O diagrama de classes do pacote Connections é mostrado na Figura 7 e seus componentes representam as conexões tendo como elemento central atividades (classe Activity). Os tipos de conexão e dependências são detalhados a seguir. Conexão Simples (SimpleCon): Define o fluxo de controle entre duas atividades (origem e destino). Este fluxo pode ser de seqüência ou de feedback. Conexão simples de seqüência: o fluxo de seqüência indica que a atividade destino depende da atividade origem. Os tipos de dependência entre atividades podem ser: o End-Start: a atividade destino somente pode iniciar quando a origem terminar; o Start-Start: a atividade destino pode iniciar somente após o início da origem; o End-End: a atividade destino somente pode terminar quando a origem terminar; Conexão simples de Feedback: O fluxo de feedback é utilizado para indicar o retorno a uma atividade já realizada desde que uma condição seja satisfeita. Nesta conexão a atividade destino (alvo) é uma atividade anterior à origem e a sintaxe define que deve haver um fluxo de execução entre a atividade destino (alvo) e a origem do feedback; Conexão Múltipla (MultipleCon): Também define o fluxo de controle, porém pode envolver várias atividades e conexões múltiplas. Existem dois tipos de conexão múltipla, ambos subdivididos pela aplicação de operadores lógicos (AND, EX-OR, In- OR) e tipos de dependência (end-start, start-start, end-end): Branch: possui uma atividade ou conexão múltipla origem e várias atividades ou conexões múltiplas destino. Um exemplo de aplicação é que a partir do término da atividade origem, todas as atividades destino podem começar (Branch AND end-start). A semântica da conexão depende do operador lógico associado (And - todas, XOR somente uma ou OR um subconjunto de), da condição lógica associada a atividade destino, quando o operador for OR ou XOR e do tipo de dependência utilizado (endstart, start-start ou end-end); 34