UMA ABORDAGEM DE DESENVOLVIMENTO BASEADA EM MODELOS DE ARQUITETURA ORGANIZACIONAL DE TI: DA SEMÂNTICA AO DESENVOLVIMENTO DE SISTEMAS

Transcrição

1 UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO DEPARTAMENTO DE INFORMÁTICA MESTRADO EM INFORMÁTICA PAULO SÉRGIO DOS SANTOS JÚNIOR UMA ABORDAGEM DE DESENVOLVIMENTO BASEADA EM MODELOS DE ARQUITETURA ORGANIZACIONAL DE TI: DA SEMÂNTICA AO DESENVOLVIMENTO DE SISTEMAS VITÓRIA, DEZEMBRO 2009

2 PAULO SÉRGIO DOS SANTOS JÚNIOR UMA ABORDAGEM DE DESENVOLVIMENTO BASEADA EM MODELOS DE ARQUITETURA ORGANIZACIONAL DE TI: DA SEMÂNTICA AO DESENVOLVIMENTO DE SISTEMAS Dissertação submetida ao Programa de Pós-Graduação em Informática da Universidade Federal do Espírito Santo como requisito parcial para a obtenção do grau de Mestre em Informática. VITÓRIA, DEZEMBRO 2009

3 PAULO SÉRGIO DOS SANTOS JÚNIOR UMA ABORDAGEM DE DESENVOLVIMENTO BASEADA EM MODELOS DE ARQUITETURA ORGANIZACIONAL DE TI: DA SEMÂNTICA AO DESENVOLVIMENTO DE SISTEMAS Dissertação submetida ao Programa de Pós-Graduação em Informática da Universidade Federal do Espírito Santo como requisito parcial para a obtenção do grau de Mestre em Informática. Aprovada em 16 de dezembro de COMISSÃO EXAMINADORA Prof. Dr. João Paulo Andrade Almeida Universidade Federal do Espírito Santo (UFES) (Orientador) Prof. Dr. Giancarlo Guizzardi Universidade Federal do Espírito Santo (UFES) (Co-orientador) Prof. Dr. Ricardo de Almeida Falbo Universidade Federal do Espírito Santo (UFES) Profa. Dra. Lucinéia Heloísa Thom Universidade Federal da Universidade do Rio Grande do Sul (UFRGS) VITÓRIA, DEZEMBRO 2009

4 DEDICATÓRIA Dedico esta dissertação a meus pais, Paulo e Rosileni e a todos que me ajudaram nessa jornada.

5 AGRADECIMENTOS Primeiramente, gostaria de agradecer a Deus, pela vida e pela força. Em seguida gostaria de agradecer aos meus pais e a minha irmã (magrela), pelo exemplo, pela oportunidade, pela companhia, pela paciência e por todo o apoio. A Débora (lindinha) pelo amor e pela paciência por todo o caminho do mestrado. Foi longo né linda? Agradeço também a galera da UFES pelo companheirismo e por me animarem sempre. Sempre tinha um barzinho (com a galera do mestrado e/ou da graduação), uma costelada na casa de Caribe (acreditem esse é o nome dele!), um churrasco na casa de Vello que ajudaram a esquecer um pouco do mestrado ou até mesmo, melhorar um pouco as idéias do mestrado com discussões filosóficas (claro, isso depois de algumas cervejas!). Também não posso deixar de agradecer a galera dos bichos (Berna (PM), André (barriguinhaaaa), Carol, Mary e Clarinha), amigos desde a época do cursinho, pelo companherismo ao longo da graduação e mestrado. Também agradeço a galera do NEMO (Thiago (Macarrão - Destruidor de lares), Evelin (Evelini), Ariane (Branca), Rodrigo (Calhau), Lucas (Lucão), Felipe, Aline, Ana, Veruska e todos os outros amigos) e a galera da PETRO (Helder, Faco (Destruidoooor de Lares), Pedro (Muqui)) pela amizade, apoio de vocês e por rirem das minhas piadas sem graças. Dentre os diversos professores do mestrado, venho agradecer especialmente a Prof. João Paulo A. Almeida (JP), Prof. Giancarlo Guizzardi (Gian) e Profa. Renata S. S.Guizzardi (Renatinha). Ao JP agradeço por ser meu orientador, pela amizade e por toda ajuda, motivação e apoio recebido durante o mestrado (Valeu JP! ). Ao Gian agradeço por ser meu co-orientador, pela amizade e pela ajuda nos momento de dificuldade. Agradeço também a Renatinha pela amizade e pelas conversas motivadoras que ocorreram durante o mestrado.

6 RESUMO O gerenciamento das organizações é uma tarefa que envolve um nível de complexidade significante, uma vez que agrega diversos domínios de conhecimento (incluindo processos de negócios, tecnologias da informação e infraestrutura). Para que seja possível analisar como esses fatores estão interconectados entre si e como a priorização de um deles pode ocasionar a postergação de outro, a utilização de uma Arquitetura Organizacional de TI (Enterprise Architecture) torna-se necessária. Através de uma Arquitetura Organizacional de TI é possível: (i) capturar a essência e as evoluções do negócio e dos sistemas de informação presentes na organização; e (ii) realizar de maneira mais eficaz e menos onerosa o alinhamento entre tecnologia da informação e os processos de negócios executados a uma ou mais organizações. Diversas abordagens de Desenvolvimento Orientado a Modelos utilizam os modelos que representam as Arquiteturas Organizacionais de TI para o desenvolvimento de sistemas computacionais. Porém, a grande maioria das abordagens não permite que o projetista do sistema (i) explore a riqueza semântica dos diferentes modelos da Arquitetura Organizacional de TI (além dos modelos de processos de negócio), (ii) parametrize transformações pré-definidas nessas abordagens para adequar as transformações ao sistema sendo desenvolvido; e (iii) divida o processo de desenvolvimento em etapas independente e dependente de plataforma. Este trabalho propõe uma nova abordagem de Desenvolvimento Orientado a Modelos que visa mitigar estas limitações do estado-da-arte, através de transformações parametrizadas que exploram a riqueza semântica dos modelos das Arquiteturas Organizacionais de TI. Adicionalmente, a abordagem propõe uma divisão clara das etapas independente e dependente de plataforma. Palavras-chave: Arquitetura Organizacional de TI, Análise Semântica, Desenvolvimento Orientado a Modelos.

7 ABSTRACT The management of organizations is a highly complex activity, since it requires the use of knowledge from several knowledge domains (including business process, information technology and infrastructure). In order to analyze how these domains are interrelated an Enterprise Architecture is essential. The main benefits of using Enterprise Architecture are: (i) to capture the essence and evolution of a business and its information systems; and (ii) to manage the alignment between the business and information systems in a cost-effective manner, possibly by revealing how business processes and information systems are interrelated. To address the alignment between business processes and information systems, several Model-Driven Development approaches enable designers to derive process-oriented systems directly from the business process models through automatic transformation. However, most of these approaches do not enable designers to explore the semantic richness of many Enterprise Architectural models (using only the control flow of business process models), and further define rather inflexible transformations. Moreover, many of these approaches to not clearly separate the development process into platform-independent and platform-specific steps, polluting business process models with platform concerns. This work proposes a novel Model-Driven Development approach to address the aforementioned issues. This approach enable the designers to (i) profit from the semantics of Enterprise Architecture models throughout the system development process; (ii) to apply parameterization in pre-defined transformations and; (iii) to clearly divide the development process into platform-independent and platform-specific steps. Keywords: Enterprise Architecture, Semantic Analysis, Model-Driven Development.

8 i INDÍCE DE FÍGURA Figura 2.1 Tipos de Ontologias de acordo com o nível de generalização (GUARINO, 1998) Figura 2.2 Fragmento da UFO-A Figura 2.3 Fragmento da UFO-A com foco nos Universais Figura 2.4 Fragmento da UFO-B Figura Exemplificando os Allen s Relations: relações temporais entre intervalos de tempo Figura Fragmento da UFO-C Figura 2.7 Fragmento da UFO-C contendo a relação entre Social Agent e Normative Description Figura 2.8 Fragmento da UFO-C com foco na entidade Action Figura 2.9 Fragmento da UFO-C contendo outros conceitos sociais Figura 2.10 Redução do espaço de soluções para um projeto com diferente níveis de abstração (ALMEIDA et al., 2006a) Figura 2.11 Relação entre conformidade e transformações (ALMEIDA et al., 2006). 39 Figura 2.12 Conformidade e transformação (ALMEIDA et al., 2006a) Figura 2.13 Gerenciador de fluxo de trabalho como link entre Pessoas e Sistemas computacionais (DUMAS et al., 2007) Figura Fragmento do metamodelo organizacional contendo Organizational Unit, Organizational Unit Type e seus relacionamentos Figura 3.2 Símbolos do elemento Organizational Unit Figura 3.3- Símbolos do elemento Organizational Unit Type Figura 3.4 Símbolo do elemento Position Figura Fragmento do Metamodelo Organizacional contendo os elemento Position, Position Type Organizacional Unit, Organizational Unit Type e seus relacionamentos Figura 3.6 Símbolo dos elementos notacionais do elemento Person Figura 3.7 Fragmento do Metamodelo Organizacional com foco no elemento Person Figura 3.8 Símbolo do elemento Person Type Figura Fragmento do metamodelo organizacional com foco no elemento Person Type e seus relacionamentos Figura 3.10 Símbolo do elemento Location Figura 3.11 Fragmento do metamodelo organizacional com foco no elemento Location e em seus relacionamentos Figura 3.12 Símbolo do elemento Group Figura 3.13 Fragmento do metamodelo organizacional com foco no elemento Group e em seus relacionamentos Figura 3.14 Fragmento do metamodelo organizacional com foco nos elementos System Organizational Unit e System Organizational Unit Type Figura 3.15 Exemplo de Modelo Organizacional Construído Utilizando as Metaclasses do Metamodelo Organizacional Figura Fragmento do metamodelo de processo com foco no elemento Function e seus relacionamentos com o elemento Participant e com o elemento Application Figura Símbolo do elemento Function

9 Figura 3.18 Símbolo do elemento Process Interface Figura 3.19 Símbolo do elemento System function (actual) Figura 3.20 Símbolo do elemento Application System Figura 3.21 Símbolo do elemento Application System Type Figura Símbolo do elemento Application System Class Figura 3.23 Símbolo do elemento Event Figura 3.24 Fragmento do metamodelo de processo contendo os relacionamentos entre Function, Event e Rule Figura 3.25 Exemplo o relacionamento is evaluated by entre Event e Rule Figura 3.26 Exemplo do relacionamento activates Figura 3.27 Exemplo do relacionamento links Figura 3.28 Exemplo do relacionamento leads to Figura 3.29 Mapeamento entre as entidades Participant e Function do metamodelo de processo de negócio e em suas instancias em um modelo de processo de negócio Figura Mapeamento entre as entidades Rule e Event do metamodelo de processo de negócio e suas instâncias em um modelo de processo de negócio Figura Fragmento do Metamodelo de Detalhamento de Atividade contendo Function, Cluster e Technical Term e seus relacionamentos Figura Fragmento do Metamodelo de Detalhamento de Atividade contendo Cluster, Participant, User e seus relacionamentos Figura 3.33 Símbolo do elemento Cluster Figura 3.34 Símbolo do elemento Technical Term Figura 3.35 Símbolo do elemento Information Carrier Figura 3.36 Fragmento do metamodelo de detalhamento de atividade com foco no elemento Information Carrier Figura 3.37 Fragmento do metamodelo de detalhamento de atividades com foco nos elementos Application System, Application System Type e Application System Class Figura 3.38 Símbolo do elemento Business Rule Figura 3.39 Fragmento do metamodelo de detalhamento de atividades apresentado o relacionamento do elemento Business rule Figura Mapeamento entre as entidades do metamodelo de Detalhamento de Atividades e suas instâncias em um modelo de detalhamento de atividades Figura 3.41 Fragmento do elemento ARIS Object e o Elemento Assignments Figura 3.42 Fragmento do Metamodelo Organizacional Figura 4.1 Abordagem da avaliação ontológica Figura Interpretação dos elementos Organizational Unit Type, Organizational Unit e Position seguindo os conceitos do ARIS Method Figura Fragmento do metamodelo organizacional com os elementos Position e Person Figura Fragmento da UFO-C contendo Institutional Agent, Human Agent e Artificial Agent (GUIZZARDI et al., 2007) Figura Nova interpretação do elemento Position Figura Fragmento do Metamodelo Organizacional contendo somente Position Type, Organizational Unit Type e Position Figura Interpretação do elemento Position Type como um Social Role Mixin Figura Interpretação do Position Type como um High Order Universal Figura Fragmento do metamodelo organizacional contendo alguns relacionamentos do elemento Person, Position, Organizational Unit e Organizational Unit Type Figura Exemplo do relacionamento is composed of ii

10 Figura Exemplo de utilização do relacionamento belongs to Figura Exemplo do relacionamento is organization manager for Figura 4.13 Fragmento do metamodelo contendo os relacionamentos do elemento Person Type Figura 4.14 Exemplo de relacionamento performs Figura 4.15 Exemplo de relacionamento belongs to entre Person Type e Organizational Unit Figura 4.16 Interpretação do elemento Person Type e dos relacionamentos performs e belongs to Figura 4.17 Fragmento do Metamodelo Organizacional com elemento Person Type e Position Description Figura Interpretação do elemento Position Description Figura Interpretação do elemento Group Figura Interpretação do Location e dos relacionamentos at location, is located at e encompasses Figura 4.21 Fragmento de um modelo organizacional apresentado em (SCHEER, 1999, p. 187) Figura 4.22 Fragmento do dialeto da linguagem organizacional do ARIS Method Figura 4.23 Fragmento do Metamodelo de Processo de Negócio com os relacionamento entre Particpant e Function Figura Interpretação ontológica do elemento Function Figura 4.25 Interpretação do elemento Event Figura 4.26 Interpretação dos elementos Application System e Application System Type Figura 4.27 Interpretação do elemento Application System Class Figura Fragmento do dialeto da linguagem de processos de negócio do ARIS Method Figura 4.29 Interpretação dos elementos Cluster, Technical Term e Information Carrier Figura 4.30 Interpretação do elemento Business Rule Figura 5.1 Abordagem de Desenvolvimento Orientado a Modelos utilizando artefatos de Arquitetura Organizacional de TI Figura 5.2 Modelo representando as relações dos metamodelos do sistema orientado a processo de negócio Figura Diferença entre a abordagem atuais e a abordagem proposta Figura 5.4 Exemplo de Componente Figura 5.5 Exemplo de utilização das transformações no nível comportamental Figura 5.6 Exemplo de aplicação da Transformação de abstração Figura Exemplo da transformação de abstração Figura 5.8 Processo de utilizado para exemplificar abstração de padrões de processo Figura 5.9 Criando componente a partir de padrões de processo Figura 5.10 Processo de negócio após a abstração dos padrões Excluise Choice e Simple Merge Figura 5.11 Caso extremo da transformação de abstração em padrões de processo. 152 Figura 5.12 Transformação de abstração em atividades de responsáveis distintos Figura 5.13 Indicando um papel para nova atividade abstraída Figura Exemplo de escolha dos elementos organizacionais pertencente a um papel (Person Type) do processo de negócio Figura Indicando um grupo para nova atividade abstraída iii

11 iv Figura 5.16 Grupo contendo os participantes das atividades abstraídas Figura 5.17 Exemplo de aplicação da transformação refinamento Figura 5.18 Aplicando a transformação refinamento e criando um componente formado por mais de um padrão de processo Figura 5.19 Transformação no nível de componente Figura 5.20 Selecionando os elementos dos modelos de detalhamento de componente Figura 5.21 Modelo de Detalhamento de uma atividade utilizando a primeira e segunda regra Figura 5.22 Transformação de automatização: Atividade totalmente automatizada Figura 5.23 Transformação de automatização: automatização de atividades para responsáveis com mais de uma atividade Figura Transformação de automatização nível: Acompanhada/gerenciada Figura 5.25 Transformação de automatização nível: Totalmente manual Figura Desvio do fluxo de informação Figura Exemplo de utilização da transformação organizacional com papel social Figura Exemplo de definição de papéis do sistema Figura 6.1 Implementação da Abordagem de Desenvolvimento Orientado a Modelos Figura 6.2 Conjunto de transformações para criar os modelos de domínio organizacional, processo de negócio e detalhamento de atividades do ARIS Method. 174 Figura 6.3 Metamodelo de Seleção e Parametrização de Transformações Independentes de Plataforma Figura 6.4 Metamodelo da metaclasse SourceComponent Figura 6.5 Metamodelo da metaclasse NewComponent Figura 6.6 Plugin para desenvolvimento de modelos de seleção e parametrização de transformações independentes de plataforma Figura 6.7 Transformação de Abstração modelado no plugin Figura 6.8 Definindo o Source Component Figura Modelo SourceComponent.eepc construído no plugin Figura 6.10 Transformação de Refinamento modelado no plugin Figura 6.11 Definindo o Source Task Figura 6.12 Modelo listando os elemento necessários para a atividade ABC Figura 6.13 Definindo o Modelo FAD na Transformação de Detalhamento de Atividade Figura 6.14 Definindo a primeira transformação a ser executada Figura 6.15 Definindo a transformação sucessora Figura 6.16 Transformações no nível dependente de plataforma deste trabalho Figura 6.17 Arquitetura de Automatização das Transformações Figura 6.18 Fragmento do metamodelo da linguagem jpdl Figura 6.19 Triar pacientes para admissão no setor (Parte 1) Figura Triar pacientes para admissão no setor (Parte 2) Figura Modelo de estrutural do sistema de workflow (Parte 1) Figura Modelo de estrutural do sistema de workflow (Parte 2) Figura Modelo Detalhado da atividade Analisar resultados dos exames parametrizado Figura FAD criado para o componente Solicitar exames laboratoriais Figura 6.33 FAD criado para o componente Encaminhar paciente para ambulatório

12 Figura 6.34 Parametrização do modelo organizacional Recepcionista Figura Parametrização do modelo organizacional Médico Figura 6.36 Paramtrização do modelo organizacional Grupo do ambulatório de reabilitação Figura 6.37 Interpretação do responsáveis pelas atividades no jdpl Figura 6.38 Interpretação do elemento Start Event no jpdl Figura 6.39 Interpretação do elemento End Event no jpdl Figura Interpretação do elementos Function, System Function (Actual), Process Interfaces no jpdl Figura Interpretação do elementos Function e System Function Actual no jpdl Figura Interpretação do elemento XOR do ARIS Method no jpdl Figura 6.43 Criando as inter-relações entre os elementos do processo de negócio Figura Fragmento do modelo em jpdl do processo de negócio Triar pacientes para admissão no setor Figura 6.45 Modificação da atividade Encaminhar paciente para ambulatório Figura Notificações da atividade Encaminhar paciente para ambulatório Figura Transformação organizacional Figura 6.48 Adicionando a entidade organizacional no elemento notificação Figura 6.49 Tela da atividade Buscar ficha do paciente Figura 6.50 Tela da atividade Examinar o paciente Figura 6.51 Tela da atividade Verificar realização previa de exames laboratoriais Figura 6.52 Log de execução da atividade Solicitar exames laboratoriais Figura Fragmento do processo de negócio v

13 vi INDÍCE DE TABELA Tabela Regras básicas do ARIS Tabela 3.2 Outras regras do ARIS Tabela 3.3 Elementos notacionais do Information Carrier Tabela 4.1 Elementos presente no dialeto organizacional Tabela 4.2 Relacionamentos eleminados da linguagem organizacional Tabela 4.3 Elementos presente no dialeto organizacional Tabela 4.4 Relacionamentos eleminados da linguagem de processo de negócio Tabela 4.5 Elementos presentes somente no Dialeto de Detalhamento de Atividades Tabela 5.1 Abstrações das atividades do Participante A Tabela 6.1 Transformações de Abstração Tabela 6.2 Interpretação das regras de processo no jpdl Tabela Atividades Utilizadas na Demonstração

14 vii Sumário CAPÍTULO 1 INTRODUÇÃO Introdução Motivação Objetivo Metodologia e Histórico do Desenvolvimento do Trabalho Principais contribuições Organização CAPÍTULO 2 REFERENCIAL TEÓRICO Introdução Arquiteturas Organizacionais da Tecnologia da Informação Ontologias Desenvolvimento Orientado a Modelos Sistemas de Informação Orientados a Processos de Negócio Conclusão CAPÍTULO 3 METAMODELOS DAS LINGUAGENS DO ARIS METHOD Introdução Metamodelo da Linguagem Organizacional Metamodelo da Linguagem de Processo de Negócio Metamodelo da Linguagem de Detalhamento de Atividades ARIS Object Discussão sobre Elementos Notacionais no ARIS Method Discussão sobre os Metamodelos de Domínio do ARIS Method Conclusão CAPÍTULO 4 ANÁLISE ONTOLÓGICADAS LINGUAGENS DO ARIS METHOD Introdução... 84

15 viii 4.2 Abordagem de Análise Ontológica Análise Ontológica do Metamodelo Organizacional Dialeto da Linguagem Organizacional do ARIS Method Análise Ontológica do Metamodelo da Linguagem de Processo de Negócio Dialeto da Linguagem de Processo de Negócio do ARIS Method Análise Ontológica do Metamodelo de Detalhamento de Atividades Dialeto da Linguagem de Detalhamento de Atividade do ARIS Method Discussão Sobre Análise Ontológica e Trabalhos Correlatos Conclusão CAPÍTULO 5 UMA ABORDAGEM DE DESENVOLVIMENTO ORIENTADO A MODELOS UTILIZANDO ARTEFATOS DE ARQUITETURA ORGANIZACIONAL DE TECNOLOGIA DA INFORMAÇÃO Introdução Componente de Padrão de Processo Transformações no Nível Comportamental Transformação no Nível de Atividade Parametrizações das Transformações Conclusão CAPÍTULO 6 PROVA DE CONCEITOS Introdução Implementação da Abordagem Proposta de Desenvolvimento Orientado a Modelos Implementação das Transformações Aplicação das Transformações No Nível Independente de Plataforma Aplicação das Transformações no Nível Dependente De Plataforma Etapas Manuais para o Desenvolvimento do Sistema de Workflow Workflow do Processo Triar Pacientes para Admissão no Setor Conclusão

16 ix CAPÍTULO 7 CONCLUSÕES E TRABALHOS FUTUROS Conclusões Trabalhos Futuros CAPÍTULO 8 REFERÊNCIAS APÊNDICE A DETALHAMENTO DAS TRANSFORMAÇÕES COMPORTAMENTAIS A.1 Introdução A.2 Transformações Comportamentais

17 1 CAPÍTULO 1 INTRODUÇÃO 1.1 INTRODUÇÃO O gerenciamento das organizações é uma tarefa que envolve um nível de complexidade significante, uma vez que agrega diversos domínios de conhecimento (incluindo processo de negócios, tecnologias da informação e infraestrutura) (DODAF, 2007). Tais domínios, por sua vez, fornecem critérios de qualidade potencialmente conflitantes (desempenho, regras de negócio e outros), e envolvem fatores diversos que influenciam o desempenho de uma organização. Segundo Jonkers et al. (2004), isso é um problema importante, porque uma mudança na estratégia e nos objetivos da organização traz grandes modificações em todas as áreas de domínio de conhecimento da organização. Para que seja possível analisar como os domínios de conhecimento estão interconectados entre si e como a priorização de um deles pode ocasionar a postergação de outro, a utilização de uma Arquitetura Organizacional de Tecnologia da Informação (TI) torna-se necessária. Arquitetura Organizacional de TI (Enterprise Architecture) é uma arquitetura que captura a estrutura de uma organização, suas características e funcionalidades, bem como a interação dinâmica entre os seus diversos componentes (DODAF, 2007). Uma completa e consistente Arquitetura Organizacional de TI é a chave para a diminuição dos riscos e para o gerenciamento dos diversos domínios do conhecimento presentes na organização. Isso se justifica pelo fato de que a Arquitetura Organizacional de TI possibilita a avaliação de novos investimentos (novas tecnologias de informação, mudanças na infraestrutura, novos processos negócios, entre outros) e a avaliação dos impactos dos novos investimentos no(s) objetivo(s) da organização e nos domínios de conhecimento (DODAF, 2007). Através de uma Arquitetura Organizacional de TI é possível capturar a essência e as evoluções do negócio e dos sistemas de informação presentes na organização, tornando

18 2 assim a organização mais flexível, adaptativa às evoluções, e consequentemente, tendo melhores chances para alcançar o sucesso nos negócios. Através da utilização das Arquiteturas Organizacionais de TI é possuível realizar de maneira mais eficaz e menos onerosa o alinhamento entre tecnologia da informação e os processos de negócios pertencentes a uma ou mais organizações. Isso ocorre, pois as Arquiteturas Organizacionais possibilitam visualizar de maneira clara como os diferentes domínios de conhecimento estão conectados. Este alinhamento é reconhecido como uma boa prática e de grande eficiência (LANKHORST e VAN DRUNEN, 2007) (JONKERS et al., 2004). A eficiência organizacional é obtida pela boa orquestração das relações entre os componentes organizacionais e não pela especificação detalhada de cada componente individualmente (LANKHORST e VAN DRUNEN, 2007) (JONKERS et al., 2004). Por fim, o conceito de Arquitetura Organizacional de TI é de tal importância acadêmica e governamental que diversos trabalhos têm abordado esse conceito na literatura. Os principais trabalhos concentram-se no desenvolvimento de frameworks que ajudam na construção e na modelagem da Arquitetura Organizacional de TI de uma organização (LANKHORST, 2005). A seção 2.2 apresenta maiores detalhes sobre os frameworks de Arquiteturas Organizacionais TI. 1.2 MOTIVAÇÃO As Arquiteturas Organizacionais de TI são uma fonte rica de informação para o desenvolvimento de sistemas computacionais que tem por objetivo interagir com um ou mais componentes organizacionais. Afinal, através dos modelos de Arquiteturas Organizacionais de TI é possível conhecer, dentre outros: i. a estrutura da organização (obtendo informações que descrevem como as entidades organizacionais interagem para o funcionamento e comportamento da organização) (SCHEER, 1999) (MINTZBERG, 1995); ii. as atividades necessárias em um processo de negócio; e

19 3 iii. como os membros da organização e os recursos (software e equipamentos) interagem com o processo de negócio. Dentre as diversas abordagens de desenvolvimento de sistemas computacionais, a que mais se destaca por proporcionar um meio de utilizar modelos no curso do entendimento, projeto, construção, implantação, operação, manutenção e modificação de sistemas computacionais é o Desenvolvimento Orientado a Modelos (do inglês, Model-Driven Development) (OMG, 2003). Através do Desenvolvimento Orientado a Modelos é possível construir transformações que permitam agilizar o desenvolvimento de um sistema computacional. A seção 2.4 apresenta detalhes sobre o Desenvolvimento Orientado a Modelos. Existem diversas abordagens de Desenvolvimento Orientado a Modelos que utilizam os modelos das Arquiteturas Organizacionais de TI para o desenvolvimento de sistemas computacionais, como (MENDLING e NÜTTGEN, 2004) (MENDLING e NÜTTGEN, 2004), (OUYANG et al., 2008), (ZIEMANN e MENDLING, 2005), (MENDLING e ZIEMANN, 2005), dentre outras. Assim como essas abordagens, este trabalho concentra-se em Sistemas de Informação Orientados a Processo. A seção 2.5 caracteriza esse tipo de sistema. A utilização dos modelos das Arquiteturas Organizacionais de TI é motivada pelo fato de que tais modelos contêm informações úteis para o desenvolvimento de sistemas computacionais. Por exemplo, os modelos de processos de negócio representam o fluxo de controle da execução de um conjunto de atividades organizacionais que visam alcançar um objetivo da organização (OUYANG et al., 2008). O detalhamento de uma atividade pode incluir a descrição das informações necessárias para a sua execução e produzidas pela atividade, os responsáveis pela execução da atividade dentre outras informações que tornam os modelos de processos de negócio de grande importância para as abordagens de Desenvolvimento Orientado a Modelos. Infelizmente, a maioria das abordagens atuais de Desenvolvimento Orientado a Modelos limita-se ao uso dos modelos de processos de negócios, e, dessa forma, não tira proveito das informações contidas nos outros modelos usados para descrever Arquiteturas Organizacionais de TI. Por exemplo, a maioria das abordagens não utiliza

20 4 os modelos de estrutura organizacional e os modelos de detalhamento de atividades como fonte de informação para o desenvolvimento de sistemas computacionais. Os modelos de estrutura organizacional (organogramas, por exemplo) muitas vezes possuem informações que são de grande valor para o sistema computacional que será desenvolvido, como os papéis ou posto de trabalhos da organização que desempenham alguma atividade no processo de negócio. Esses papéis e os postos de trabalhos no nível do negócio podem ser usados como base para a definição de papéis e atores no nível de sistema. Além disso, o modelo organizacional pode fornecer informações que serão utilizados para definir padrões de atividades no sistema computacional (THOM et al., 2009). Os modelos de detalhamento de cada atividade, por sua vez, tipicamente descrevem as informações que são consumidas e produzidas em cada atividade de um processo, assim como regras de negócio que se aplicam em cada atividade e os sistemas que dão suporte à execução da atividade. Em uma abordagem orientada a modelos, as informações contidas nos modelos detalhados podem ser utilizadas para descrever os dados necessários e produzidos para uma determinada funcionalidade do sistema em realização e, até mesmo, regras de execução que influenciem diretamente em diversas funcionalidades do sistema computacional em realização. Apesar do potencial de uso dos modelos de detalhamento de atividade, grande parte das abordagens atuais de Desenvolvimento Orientado a Modelos consideram a atividade de um processo de negócio como uma caixa preta (menor unidade de decomposição). Em outras palavras, grande parte das abordagens de Desenvolvimento Orientado a Modelos não se interessam pelo detalhamento da atividade como: (i) informações que são necessárias e produzidas pela atividade; (ii) sistemas computacionais que auxiliam a atividade; (iii) regras de negócio da atividade e dentre outros. Logo, é necessário que o responsável pelo desenvolvimento do sistema computacional acrescente as informações contidas nos modelos de detalhamento de atividade manualmente, tornando, assim, o desenvolvimento mais demorado e mais suscetível a erros. Com a utilização de diversos modelos da Arquitetura Organizacional de TI no desenvolvimento de sistemas computacionais torna-se possível que um projetista tenha

21 5 uma visão abrangente dos aspectos organizacionais do ambiente no qual o sistema computacional está inserido. Assim, é possível também considerar os impactos do sistema computacional na organização e vice-versa. Segundo CARDOSO et al. (2008), a partir de um processo de negócio é possível definir diferentes sistemas computacionais levando em consideração as diferentes decisões de projeto e os requisitos para os mesmos. No entanto, grande parte das abordagens de Desenvolvimento Orientado a Modelos que utiliza os modelos das Arquiteturas Organizacionais de TI para o desenvolvimento de sistemas computacionais possui transformações pré-estabelecidas e não parametrizáveis, desta forma, impossibilitando que o projetista aplique decisões nas transformações. Por exemplo, as atuais abordagens Desenvolvimento Orientado a Modelos são apenas traduções entre espaços tecnológicos (no inglês, technological spaces) (KURTEV et al., 2002), como em (MENDLING e ZIEMANN, 2005) que propõe a transformação direta de BPEL (Business Process Execution Language) (OASIS, 2006) em EPC (SCHEER, 1999). Com este tipo de abordagem de transformação direta não há parametrização para permitir ao projetista indicar decisões de projeto relevantes para o sistema computacional. Um exemplo deste tipo de decisão é a definição de como uma determinada atividade do modelo BPEL deve ser transformada para o modelo EPC (Event-Driven Process Chain). Por fim, a maioria das abordagens atuais de Desenvolvimento Orientado a Modelos não explora a riqueza da semântica das linguagens de modelagem das Arquiteturas Organizacionais de TI. Desta forma, as transformações propostas por essas abordagens não realizam um mapeamento adequado entre os elementos do domínio organizacional e os elementos do domínio da solução computacional. Por exemplo, a transformação proposta por (MENDLING e NÜTTGEN, 2004) (MENDLING e NÜTTGEN, 2004) não diferencia atividades que são executas por seres humanos e por sistemas do modelo EPC (SCHEER, 1999) para o desenvolvimento do modelo em EPML (MENDLING, 2009).

22 6 1.3 OBJETIVO O objetivo deste trabalho é apresentar uma nova abordagem de Desenvolvimento Orientado a Modelos que utiliza os modelos de Arquiteturas Organizacionais de TI para o desenvolvimento de sistemas computacionais. A abordagem de Desenvolvimento Orientado a Modelos proposta possibilita a inclusão de diversos e diferentes modelos de domínio das Arquiteturas Organizacionais de TI no desenvolvimento de sistemas computacionais, não se limitando aos modelos de processos de negócio. Por exemplo, a abordagem proposta permite que o projetista utilize os modelos organizacionais e de detalhamento de atividades no processo de desenvolvimento do sistema computacional. A inclusão de outros modelos objetiva-se auxiliar o projetista no entendimento do contexto no qual o sistema computacional está incluído e, também, possibilitar a utilização das informações contidas nesses modelos em transformações semiautomáticas para o desenvolvimento do sistema computacional. As abordagens atuais de Desenvolvimento Orientado a Modelos assumem que os modelos das Arquiteturas Organizacionais de TI podem ser automatizados sem modificações. Esta premissa leva à definição de modelos de processos de negócio que misturam interesses de negócio e interesses de sistema. Diferentemente dessas abordagens, a abordagem proposta neste trabalho assume que os modelos das Arquiteturas Organizacionais de TI foram construídos para representar uma realidade organizacional e não para automatização. Desta forma, são definidos mecanismos para que o projetista possa adequar os modelos das Arquiteturas Organizacionais de TI para atender às necessidades do sistema computacional em desenvolvimento, mantendo ainda o alinhamento com a realidade organizacional capturada nos modelos originais. Por fim, a abordagem de Desenvolvimento Orientada a Modelos proposta permite que o projetista explore a riqueza da semântica das linguagens de modelagem da Arquitetura Organizacional de TI em todas as etapas do desenvolvimento do sistema computacional.

23 7 1.4 METODOLOGIA E HISTÓRICO DO DESENVOLVIMENTO DO TRABALHO Inicialmente foi realizado um estudo das principais abordagens de Desenvolvimento Orientado a Modelos que utilizam modelos de Arquiteturas Organizacionais de TI para o desenvolvimento de sistemas computacionais. Nesse estudo buscou-se entender como tais abordagens utilizam as informações contidas nos modelos e como as decisões de projeto são incorporadas no desenvolvimento de sistemas computacionais. Constatou-se que a maioria das abordagens de Desenvolvimento Orientado a Modelos baseadas em modelos de Arquiteturas Organizacionais de TI não explora de forma abrangente as informações contidas nos modelos e não permite que o projetista aplique as decisões de projeto nas transformações. Adicionalmente, foi realizado um levantamento bibliográfico sobre os principais frameworks de modelagem de Arquiteturas Organizacionais de TI que podem ser utilizados para o desenvolvimento de sistemas computacionais. Dentre os diversos frameworks (como DODAF (DODAF, 2007), TOGAF (TOGAF, 2007), ArchiMate (ARCHIMATE CONSORTIUM, 2009)), o ARIS (Architecture of Integrated Information Systems) (SCHEER, 1999) foi adotado neste trabalho. A escolha pelo ARIS foi motivada por este fornecer um conjunto de linguagens de modelagem bem difundido, que permite modelar os diversos aspectos da organização como, por exemplo, aspectos organizacionais e de processo de negócio. Outro ponto importante na escolha do ARIS é a existência de diversas ferramentas que utilizam os modelos do ARIS como, por exemplo, Microsoft s Visio, BOC s ADONIS, SAP R/3, ARIS Toolset e outras da IDS Scheer (KERN e KÜHNE, 2007). Devido ao valor econômico do ARIS, diversos trabalhos acadêmicos têm sido realizados utilizando seus modelos como, por exemplo, trabalhos na área de análise ontológica (GREEN et al., 2004), na área de transformações entre linguagens utilizando técnicas de desenvolvimento orientado a modelos (MENDLING e NÜTTGEN, 2004) (MENDLING e NÜTTGEN, 2004) (KERN e KÜHNE, 2007), dentre outros. Com a escolha do framework de modelagem, foi necessário considerar os aspectos sintáticos e semânticos das linguagens de modelagem para incorporação dos modelos

24 8 produzidos por essas linguagens na abordagem de Desenvolvimento Orientado a Modelos proposta. Logo, foi realizada uma busca bibliográfica sobre os metamodelos das linguagens de domínio do ARIS que são implementadas nas ferramentas de modelagem. O objetivo dessa busca foi entender de forma profunda os conceitos dos domínios representados por tais linguagens. Os metamodelos das linguagens de domínio disponíveis na literatura e apresentados em (SCHEER, 1999) e (DAVIS, 2001) não descrevem as atuais implementações nas ferramentas de modelagem. Desta forma, foi necessário desenvolver no escopo deste trabalho uma abordagem de escavação para definir os metamodelos das linguagens de modelagem de domínio. A fim de uma melhor definição e compreensão dos conceitos de cada elemento presente nos metamodelos de domínio escavado em termos de entidades do mundo real, foi necessário realizar uma análise ontológica com ontologias de fundamentação. A ontologia de fundamentação escolhida neste trabalho foi a UFO (Unified Foundational Ontology ) (GUIZZARDI, 2005a) (GUIZZARDI et al., 2008). A UFO tem sido aplicada com sucesso na avaliação, (re) projeto e integração de modelos de linguagens de modelagem conceitual, assim como, na definição semântica de entidades do mundo real para os elementos de tais modelos (GUIZZARDI et al., 2008). A análise ontológica possibilitou identificar e eliminar problemas nos metamodelos das linguagens de domínio do ARIS, além de realizar distinções conceituais relevantes entre os elementos do metamodelo. Através da análise ontológica foi possível definir um conjunto mínimo de elementos e relacionamentos que permite expressar de forma exata e sem ambiguidade as conceituações presentes em cada domínio organizacional que as linguagens do ARIS visam representar. Com uma base sintática e semântica para representação e interpretação dos modelos de Arquitetura Organizacional de TI e com um estudo aprofundado das abordagens atuais de Desenvolvimento Orientado a Modelos, foi proposta uma abordagem de Desenvolvimento Orientado a Modelos que visa: (i) melhor aproveitar a semântica dos elementos de modelagem contidos nos modelos das Arquiteturas Organizacionais de TI e (ii) permitir ao projetista aplicar as decisões de projeto nas transformações pré-

25 9 definidas; e (iii) dividir o processo de desenvolvimento do sistema computacional em etapas independente e dependente de plataforma. Por fim, foi realizada uma prova de conceitos da abordagem de desenvolvimento orientado a modelos proposta neste trabalho com a implementação dos metamodelos e transformações. Esses metamodelos e transformações foram aplicados no desenvolvimento de um sistema de workflow. 1.5 PRINCIPAIS CONTRIBUIÇÕES As principais contribuições deste trabalho são: i. A escavação, análise e melhoria do metamodelo AML do ARIS Method. A abordagem utilizada para escavar e melhorar o metamodelo AML é apresentado em (SANTOS JR. et al., 2008); ii. A escavação do metamodelo Organizacional, do metamodelo de Processo de Negócio e do metamodelo de Detalhamento de Atividade do ARIS Method, implementado no ARIS Toolset. Os metamodelos e a abordagem utilizada para escavá-los são apresentados em (SANTOS JR. e ALMEIDA, 2008) (SANTOS JR. et al., 2009); iii. Análise Ontologica dos metamodelos Organizacional, Processo de Negócio e Detalhamento de Atividade. Essa análise permitiu desenvolver um dialeto bemformado dessas linguagens. Em (SANTOS JR. et al., 2010) é apresentado a análise ontológico do metamodelo de processos de negócio. iv. Desenvolvimento de uma abordagem de desenvolvimento orientado a modelos que permite separar o desenvolvimento de sistemas baseado em processos em duas etapas bem distintas: Independentende e dependente de plataforma.

26 ORGANIZAÇÃO Este trabalho é estruturado em sete capítulos e um apêndice. O conteúdo de cada um desses é descrito resumidamente abaixo: Capítulo 2 Referencial Teórico: apresenta o referencial teórico a respeito de Arquiteturas Organizacionais de TI, Desenvolvimento Orientado a Modelos, Ontologias de fundamentação e Sistemas orientados a processos de negócio (PAIS Process-Aware Information System) (THOM et al., 2009). Capítulo 3 Metamodelos das Linguagens do ARIS Method: apresenta os metamodelos das linguagens de modelagem organizacional, processo de negócio e detalhamento de atividades presente no ARIS Method. Capitulo 4 Análise Ontológica dos Metamodelos dos Domínios de Modelagem Organizacional e de Modelagem de Processo de Negócio: apresenta a análise ontológica dos elementos e relacionamentos presentes nos metamodelos dos domínios de modelagem organizacional e de modelagem de processo de negócio. Através da análise ontológica é possível interpretar cada elemento presente nos metamodelos em entidades do mundo real e, também, identificar problemas estruturais nas linguagens de modelagem. Capítulo 5 Uma Abordagem de Desenvolvimento Orientado a Modelos Utilizando Artefatos de Arquitetura Organizacional de TI: descreve em detalhes os conceitos e as transformações da abordagem de desenvolvimento orientado a modelos proposta neste trabalho. O capítulo discute também as diferenças entre a abordagem proposta neste trabalho e a maioria das abordagens atuais de Desenvolvimento Orientado a Modelos com base em modelos de Arquiteturas Organizacionais de TI. Capítulo 6 Prova de conceitos: apresenta a viabilidade da abordagem de Desenvolvimento Orientado a Modelos proposta neste trabalho, através da construção de um sistema orientado a processos de negócio.

27 11 Capítulo 7 - Considerações Finais e Trabalhos Futuros: apresenta as conclusões do trabalho, as contribuições, dificuldades e propostas de trabalhos futuros que podem ser desenvolvidos com base neste trabalho. Apêncide A Detalhamento das Transformações Comportamentais: apresenta as decisões de projeto que foram aplicadas sobre o modelo comportamental, com a finalidade de demonstrar a utilização da abordagem proposta neste trabalho.

28 12 CAPÍTULO 2 REFERENCIAL TEÓRICO 2.1 INTRODUÇÃO Este capítulo apresenta o referencial teórico necessário para o entendimento deste trabalho como um todo. O capítulo é organizado da seguinte forma: a seção 2.2 apresenta uma breve discussão sobre as Arquiteturas Organizacionais de TI e depois apresenta as características do framework ARIS; a seção 2.3 apresenta conceitos sobre ontologias, mais especificamente sobre a Ontologia de Fundamentação UFO; a seção 2.4 descreve os conceitos e práticas do Desenvolvimento Orientado a Modelos e, finalmente; a seção 2.5 descreve os conceitos dos sistemas computacionais que utilizam os processos de negócio como base para o seu funcionamento e desenvolvimento. 2.2 ARQUITETURAS ORGANIZACIONAIS DA TECNOLOGIA DA INFORMAÇÃO Uma definição ampla de Arquitetura Organizacional de TI é apresentada por LANKHORST (2005): Arquitetura Organizacional de TI consiste em um conjunto completo e coerente de princípios, métodos e modelos que são utilizados no projeto e implementação de uma estrutura organizacional, processos de negócios, sistemas de informação e infraestrutura. O conceito de Arquitetura Organizacional de TI é de tal importância acadêmica e governamental que diversos trabalhos acadêmicos e governamentais estão presentes na literatura. Grande parte desses trabalhos se concentra no desenvolvimento de frameworks para modelagem e estruturação de Arquitetura Organizacional de TI. Os frameworks que se destacam são:

29 13 i. ArchiMate (ARCHIMATE CONSORTIUM, 2009), desenvolvido por um consórcio composto dos seguintes membros: Telematica Institut, Ordina, Radboud University Nijmegen, o Leiden Institute for Advanced Computer Science (LIACS) e o Centre for Mathematics and Computer Science (CWI). ii. DoDAF (Department of Defense Architecture Framework), desenvolvido pelo Departamento de Defesa Norte-Americano (DODAF, 2007); iii. RM-ODP, padronizado pela ISO (RM-ODP-ISO-ISO/ITU-T, 1995) e especializado na arquitetura de sistemas distribuídos; iv. TOGAF (The Open Group Architecture Framework) (TOGAF, 2007), desenvolvido pelo The Open Group (THEOPENGROUP, 2009); v. O framework de Zachman (ZACHMAN, 1987), desenvolvido por John Zachman em 1987; e vi. ARIS (Architecture of Integrated Information Systems) (SCHEER, 1999), desenvolvido pelas pesquisas acadêmicas do professor A.W.Scheer; Com a utilização desses frameworks, é possível documentar os conceitos do negócio, das aplicações, de infraestrutura e outros conceitos relacionados aos mesmos que sejam relevantes, além de perspectivas e aspectos desejáveis para atender o(s) stakeholder(s) no desenvolvimento de um projeto de software (LANKHORST, 2005). A utilização de um framework de Arquitetura Organizacional de TI possibilita não somente a estruturação do conhecimento do domínio organizacional de forma sistemática, mas também provê ferramentas para análise de desempenho organizacional, análise de impactos e também provê um meio de realizar o alinhamento entre estrutura organizacional e arquitetura de TI. Os frameworks de Arquiteturas Organizacionais de TI são particularmente úteis no desenvolvimento de sistemas computacionais em dois aspectos: (i) favorecem a rastreabilidade de informações entre a arquitetura organizacional (capturada no formato

30 14 de um artefato denominado modelo) e os sistemas/infraestrutura que suportam essa arquitetura (concebidos a partir dos modelos gerados previamente) (LANKHORST, 2005) e (ii) permitem a geração automática de código, uma vez que os modelos são artefatos passíveis de sofrer transformações, para derivarem código para sistemas computacionais (LANKHORST, 2005). Este trabalho está interessado nos frameworks de Arquitetura Organizacional de TI que fornecem um conjunto de linguagens de modelagem, que permita modelar os diversos aspectos da organização como, por exemplo, aspectos organizacionais e de processo de negócio. Dentre os frameworks supracitados, os que possuem tal característica são o ARIS e o ArchiMate. Devido ao foco deste trabalho, será explicado apenas o framework ARIS na seção ARIS O ARIS (ARchitecture for integrated Information Systems) foi desenvolvido na universidade de Saarbrucken, Alemanha, em 1992 com o objetivo principal de permitir a descrição e desenvolvimento de sistemas de informação que estivessem integrados à estrutura da organização através de seus processos de negócio (SCHEER, 1999). Através do ARIS é possível: (i) documentar os processos de negócios existentes na organização; (ii) obter uma visão geral da organização para análise e projeto dos processos de negócios; e (iii) apoiar o projeto de sistemas de informação (LANKHORST, 2005). O ARIS propõe uma arquitetura de modelagem de organizações chamada de ARIS Method, estruturada em cinco diferentes visões (organizacional, dados, controle, função e saída) e três diferentes camadas de abstração (requisitos, projeto e implementação) (SCHEER, 1999). Dado o escopo dos modelos suportados pelo ARIS Method, esta abordagem pode ser considerada uma técnica abrangente de modelagem de organizações e de arquiteturas de TI (LANKHORST, 2005). Cada uma das visões do ARIS Method possui uma linguagem própria.

31 15 A visão organizacional descreve a hierarquia organizacional, isto é, descreve a comunicação e o relacionamento entre as unidades organizacionais de uma organização, revelando também os papéis dos indivíduos na organização (SCHEER, 1999). A visão de dados descreve as informações que são manipuladas na organização. Nesta visão é possível expressar como o conhecimento organizacional está organizado e armazenado (DAVIS, 2001). A visão de função é utilizada para descrever as tarefas realizadas pela organização. Através dessa visão é possível expressar os objetivos organizacionais de cada tarefa realizada na organização e quais sistemas computacionais auxiliam em cada tarefa organizacional. Também é possível descrever a hierarquia das tarefas organizacionais. A visão de controle descreve os processos de transformação da informação por meio de uma função ou um conjunto de funções. Como as funções representam atividades organizacionais potencialmente complexas, esta visão é usada para modelar processos de negócio na abordagem ARIS (SCHEER, 1999). Através dessa visão é possível mostra o relacionamento entre os processos de negócio da organização e as demais entidades da organização (entidades organizacionais, recursos, informações e entre outros aspectos). Em relação aos níveis de abstração propostos pelo ARIS, o Nível de Requisitos é destinado a atividades de modelagem do domínio do problema, ou seja, na elicitação de conceitos e detalhes referentes ao negócio e à organização, assim como o fechamento do escopo da modelagem abarcada pelos modelos e os objetivos pelos quais se justifica a modelagem. Assim, nesse momento, a perspectiva analisada deve ser inteiramente orientada à percepção que o usuário possui do negócio, bem como sua documentação e padrões (CARDOSO, 2007). Estão presentes neste primeiro nível os modelos de cadeia de eventos orientados a processos (EPCs), diagrama de objetivos, dentre outros modelos que ajudam na modelagem do domínio do problema (CARDOSO, 2007). O segundo nível de abstração, o nível de Especificação de Projeto, tem por objetivo construir modelos que retratem os conceitos de TI, ou seja, construir modelos que descrevam o projeto conceitual de arquitetura, requisitos funcionais de uma aplicação e

32 16 infraestrutura de um sistema, sem se ater, no entanto, a detalhes específicos a uma tecnologia (CARDOSO, 2007). Portanto, como esse nível implementa certas características do nível de Nível de Requisitos, é possível alterar-se alguns detalhes de especificação de projeto que implementem os mesmos conceitos do negócio, sem que, no entanto, seja necessário retornar ao Nível de Requisitos para atualizá-lo, o que garante flexibilidade no processo (CARDOSO, 2007). O último nível de abstração, o Nível de Descrição de Implementação, tem por objetivo traduzir a arquitetura descrita no Nível de Especificação de Projeto para modelos que descrevam detalhes tecnológicos dos componentes que irão implementá-la (CARDOSO, 2007). O Nível de Descrição de Implementação está intimamente ligado à tecnologia da informação e sua especificação pode ser apoiada pelos detalhes levantados no Nível de Especificação de Projeto (CARDOSO, 2007). Tendo como base o ARIS Method, diversas ferramentas foram desenvolvidas, como por exemplo, ARIS SOA Architect, ARIS Business Architect e ARIS Toolset. Estas ferramentas proveem um ambiente para modelagem, gerenciamento dos modelos produzidos e outros serviços de gerenciamento de processos (KERN e KÜHNE, 2007). 2.3 ONTOLOGIAS O Dicionário Webster (2004 apud GUIZZARDI 2005, GUIZZARDI 2007) define ontologia como: (i) um ramo da metafísica preocupado com a natureza e os relacionamentos dos seres; (ii) uma teoria particular sobre a natureza do ser; (iii) uma teoria preocupada com os tipos de entidades e, especialmente, com os tipos abstratos de entidades que são admitidos em um sistema de linguagem. Segundo GRUBER (1993) uma ontologia é uma especificação formal e explícita de uma conceituação compartilhada. Uma conceituação é uma abstração, uma visão simplificada de uma parte do mundo que se deseja representar para algum propósito. Outra definição bastante utilizada sobre ontologias é apresentada em (GUARINO e GIARETTA, 1995): Uma ontologia é uma especificação explícita e parcial de uma conceitualização

33 17 Na Filosofia, a palavra ontologia 1 é utilizada para representar um sistema particular de categorias que descreve uma visão do mundo (GUARINO, 1998) (GUIZZARDI, 2005a). Aristóteles foi primeiro filósofo ocidental que utilizou a ontologia para o estudo das características da realidade e dos objetos reais. De acordo com Guizzardi (2007), na Ciência da Computação, o primeiro relato da utilização de ontologias ocorreu em um trabalho sobre fundamentos de modelagem de dados em 1967, no qual foi utilizado o conceito filosófico de ontologias. De uma maneira independente, pesquisadores na área de Inteligência Artificial começaram a fazer uso daquilo que veio a ser conhecido como Ontologias de Domínio (GUIZZARDI, 2007) e, desde então, diversas ontologias de domínio têm sido criadas em diversas áreas da Ciência da Computação. As Ontologias de Domínio descrevem um vocabulário relativo a um domínio genérico (por exemplo, de Engenharia de Software e Processos de Negócio) (GUARINO, 1998). Um ponto importante que deve ser enfatizado é que o termo ontologia é utilizado com diferentes sentidos nas diversas áreas da Ciência da Computação (GUIZZARDI, 2007) (GUIZZARDI et al., 2008). Na área de Sistema de Informação, o termo ontologia tem sido utilizado de acordo com as definições da Filosofia, isto é, como um sistema de categorias formais independente de domínio e filosoficamente bem fundamentado que pode ser usado para enunciar modelos da realidade específica de domínio (GUIZZARDI et al., 2008). Em outras áreas da Ciência da Computação o termo ontologia é, em geral, utilizado: (i) como um artefato concreto de engenharia projetado para um propósito específico sem dar muita atenção para questões de fundamentação (GUIZZARDI, 2007) (GUIZZARDI et al., 2008); e (ii) como uma representação de um domínio particular (por exemplo, Engenharia de Software, Processo de negócio, Medicina e entre outros domínios do conhecimento) (GUIZZARDI et al., 2008). Guarino (1998) define quatro tipos de ontologias de acordo com o seu nível de generalidade: (i) Ontologias de Fundamentação, (ii) Ontologias de Domínio, (iii) Ontologias de Tarefa e (iv) Ontologias de Aplicação. A Figura 2.1 apresenta a relação entre os tipos de ontologias. As setas na Figura 2.1 representam uma relação de 1 A palavra ontologia, em grego, significa o estudo do ser e da existência (GUIZZARDI, 2005a) (GUIZZARDI, 2007).

34 18 dependência conceitual entre os tipos de ontologias, ou seja, uma ontologia de fundamentação fornece os conceitos necessários para a construção das ontologias de domínio e de tarefa, enquanto as ontologias de domínio e tarefa fornecem os conceitos necessários para a construção de ontologias de aplicação. Figura 2.1 Tipos de Ontologias de acordo com o nível de generalização (GUARINO, 1998) As Ontologias de Fundamentação descrevem conceitos como espaço, tempo, objeto, eventos, ações e outros conceitos que são independentes de um problema ou domínio em particular (GUARINO, 1998). As Ontologias de Domínio e Ontologias de Tarefa descrevem, respectivamente, o vocabulário relativo a um domínio genérico (por exemplo, de Engenharia de Software, processos de negócio) e o vocabulário relativo a uma tarefa ou atividade genérica (por exemplo, venda ou compra) através de especializações de termos apresentados nas Ontologias de Fundamentação (GUARINO, 1998). As Ontologias de Aplicação descrevem conceitos que dependem de um domínio e uma tarefa em particular, que frequentemente são especializações das Ontologias de Domínio e de Tarefa. Esses conceitos frequentemente correspondem a papéis que são desempenhados pelas entidades do domínio na execução de certa tarefa ou atividade (GUARINO, 1998). Em particular, neste trabalho estamos interessados nas Ontologias de Fundamentação e no uso destas para a melhoria da qualidade das linguagens de modelagem, conforme apresentado em (GUIZZARDI e WAGNER, 2005b). Dentre as diversas Ontologias de Fundamentação presentes na literatura, como DOLCE (BOTTAZI e FERRARIO, 2006), GFO (HERRE et al., 2006), SUMO (NILES e PEASE, 2001), adota-se neste

35 19 trabalho a Ontologia de Fundamentação UFO (Unified Foundational Ontology), por ser uma ontologia que visa unificar as ontologias de fundamentação supracitadas, capturando as suas características positivas e sanando suas limitações (GUIZZARDI e WAGNER, 2005b). A UFO será utilizada como base semântica para a análise ontológica dos metamodelos da linguagem Organizacional, de Processo de Negócio e de Detalhamento de Atividades do ARIS Method a serem apresentados no Capítulo 3. Através da análise ontológica será possível: i. definir precisamente o significado dos elementos dessas linguagens em termos de entidades do mundo real (utilizando os conceitos da UFO); ii. identificar elementos inadequados das linguagens de modelagem utilizando o framework de avaliação de linguagens apresentado em (GUIZZARDI et al., 2005a); e iii. indicar recomendações de melhoria nas linguagens, caso sejam identificados problemas na interpretação ontológica dos elementos das linguagens. O resto desta subseção é dedicado a uma descrição da UFO, uma vez que seus conceitos serão relevantes para a análise ontológica conduzida no Capítulo UFO A UFO tem sido desenvolvida com base em um número de teorias das áreas de Ontologias Formais, Lógica Filosófica, Filosofia da Linguagem, Linguística e Psicologia Cognitiva (GUIZZARDI et al., 2008). Essa ontologia de fundamentação tem sido aplicada com sucesso na avaliação, (re) projeto e na integração de modelos das linguagens de modelagem, assim como na definição semântica de entidades do mundo real para os elementos de tais modelos (GUIZZARDI et al., 2008) (ALMEIDA et al., 2009) (SANTOS JR. et al., 2010).

36 20 A UFO é dividida em três camadas que se complementam: (i) UFO-A é o núcleo da UFO, excluindo conceitos relacionados com eventos; (ii) UFO-B concentra-se nos conceitos ligados a eventos; e (iii) UFO-C fundamenta-se em UFO-A e UFO-B para sistematizar conceitos sociais, tais como planos, agentes, objetivos, ações, intencionalidade e compromisso (GUIZZARDI et al., 2008). As seções seguintes apresentam, respectivamente, a UFO-A, UFO-B e UFO-C. O conteúdo apresentado nessas seções foi elaborado com base nos seguintes trabalhos: (GUIZZARDI, 2005a), (GUIZZARDI et al., 2005a), (GUIZZARDI e WAGNER, 2005b), (GUIZZARDI et al., 2007a) e (GUIZZARDI et al., 2008) UFO-A Uma distinção fundamental nessa ontologia ocorre entre a categoria Particular e a categoria Universal. Particulars são entidades que existem na realidade, possuindo uma identidade única. Universal, de modo contrário, são modelos independentes de espaço e tempo, que podem ser instanciados em diferentes Particulars, ou até mesmo em outros Universals. Em outras palavras, um Particular é uma instância de um Universal que define, em linguagem informal, tipos de entidades. A Figura 2.2 apresenta um fragmento da UFO-A com a distinção entre Particular e Universal. A entidade Substantial representa as entidades do mundo real que persistem no tempo, mantendo as suas identidades. São exemplos de Substantials entidades físicas e sociais do dia-a-dia, como uma pessoa individual, uma bola, um cão, oceano atlântico e o presidente da república. A entidade Moment denota o que é chamado de objetificação (instanciação) de uma propriedade (e não tem nenhuma relação com o sentido de instante temporal como o termo é comumente utilizado). Exemplos de Moments são: a cor de uma cadeira, uma carga elétrica e um sintoma de um determinado paciente (GUIZZARDI, 2005) (GUIZZARDI et al., 2008). Uma característica comum aos Moments é que todos estes são dependentes de Substantials, somente podendo existir em outros Substantials, como, por exemplo, uma carga elétrica somente pode existir em algum condutor

37 21 elétrico, ou uma ligação covalente somente pode existir se os átomos conectados existirem. Os Moments são existencialmente dependentes de outros Substantials. É dito que um particular x é dependente existencialmente (ed) de um outro particular y se e somente se, por questão de necessidade, y existir sempre que x existir. A dependência existencial é uma relação modalmente constante, isto é, se x for dependente de y esta relação existe entre estes dois indivíduos específicos em todos os mundos possíveis em que x existe. Dependência existencial pode também ser usada para diferenciar Relational Moments (Propriedade Relacional) de Intrinsic Moments (Propriedade Intrínseca). Os Intrinsic Moments dependem de apenas um Substantial para existirem. São exemplos de Intrinsic Moments a cor de um objeto, a dor de cabeça de uma pessoa e a temperatura de um ser. Diferentemente dos Intrinsic Moments, os Relational Moments, também chamados de Relators, dependem de um conjunto de Particulars para existirem como, por exemplo, o Relator tratamento médico depende para existir dos Particulars Paciente e Médico. Figura 2.2 Fragmento da UFO-A.

38 22 A relação de dependência existencial que existe entre um Moment x e um Particular y na qual x depende de y é a relação de Inherence (inerência- i). Assim, para que um Particular x seja um Moment de um outro Particular y, a relação i(x,y), ou seja, x é inerente a y, deve existir entre os dois. Por exemplo, a inerência prende a existência de um sorriso a um rosto, ou a carga em um condutor específico ao próprio condutor. Nessa ontologia, admite-se que Moments podem ser inerentes a outros Moments. Um exemplo de um Moment que é inerente a um outro moment é a gravidade de um sintoma. A partir dessa relação, pode-se dizer que os Particulars que não são inerentes a outros Particulars são denominados de Substantials. As categorias Substantial Universal e Moment Universal, ambas especializações de Monadic Univerval, são uma interpretação ontológica para as estruturas estáticas de um domínio. Exemplos de Substantial Universals são Maçã, Planeta e Pessoa. Todos esses são tipos e não Particulars como uma pessoa específica. Da mesma maneira, exemplos de Moment Universal são a Cor, a Carga Elétrica, o Sabor e a Dor de Cabeça, que são intrínsecos a alguns Substantial Universals. Uma tentativa de modelar a relação entre propriedades intrínsecas e suas representações na estrutura cognitiva humana, ou seja, na forma em que o ser humano vê o mundo, é representada na Teoria dos Espaços Conceituais, introduzida em (GÄRDENFORS, 2000). Essa teoria é baseada na noção de Quality Structures. A idéia é que, para diversos tipos de propriedades, existe uma Quality Structure relacionada na cognição humana. Por exemplo, a Altura e a Massa estão associadas com as estruturas unidimensionais isomórficas à semi-reta dos números positivos. Outros tipos de propriedades, como a Cor e o Sabor, são representadas por estruturas multidimensionais. Em (GÄRDENFORS, 2000), a percepção, ou concepção, de uma propriedade intrínseca pode ser representada como um ponto em uma Quality Structure e este ponto é chamado de Quale. Quality structures e Qualia o plural de Quale são, juntos com conjuntos, números e proposições lógicas (Propositions), exemplos de Abstract Particulars, como mostrado na Figura 2.2. Assim, resume-se que, se um

39 23 Moment Universal é associado a uma Quality Structure e é inerente a um Substantial Universal, então uma instância (um Substantial) desse Substantial Universal deve possuir uma propriedade cuja concepção é um ponto na Quality Structure citada. Por exemplo, quando dizemos que Antônio possui 1,80 m de altura estamos nos referindo a uma instância do Substantial Universal Pessoa, sua altura (Quality) e um ponto (Quale) na Quality Structure de estruturas unidimensionais isomórficas à semi-reta dos números racionais. A entidade Quality representa uma qualidade de um indivíduo. O Quality está associado a uma estrutura de qualidade (Quality Structure). Por exemplo, a cor (Quality) da maçã está associada à estrutura de qualidade (Quality Structure) RGB. Relations são entidades que conectam ( colam ) outras entidades. Na literatura filosófica, duas amplas categorias de relações são tipicamente consideradas, a saber, as Material Relations (relações materiais) e Formal Relations (relações formais) (HELLER e HERRE, 2004a). As Formal Relations relacionam duas ou mais entidades diretamente, sem nenhum indivíduo de intervenção adicional. A princípio, a categoria de Formal Relations inclui aquelas relações que dão forma a uma superestrutura matemática que garante formalmente a estrutura da ontologia UFO, incluindo as relações de dependência existencial (existential dependence - ed), inerência (inherence - i), parte-de (part-of - <), subconjunto-de (subset-of), instanciação (instantiation), caracterização (characterization), exemplificação (exemplification), dentre outras não discutidas aqui (ver (GUIZZARDI, 2005a)). As Material Relations, ao contrário, têm uma estrutura material em si próprias e incluem exemplos tais como trabalhar em, estar registrado em, e ser conectado a. Enquanto uma Formal Relation como aquela entre Paulo e seu conhecimento x da língua inglesa reside diretamente e sempre em todas as situações em que Paulo e x existirem, uma relação material de sendo tratado por entre José e uma unidade médica UM1 existe se uma outra entidade mediadora existir e que ela relacione José a UM1. Essas entidades são chamadas de Relators. Relators são particulars com a

40 24 capacidade (poder) de conectar outras entidades. Por exemplo, um tratamento médico conecta um paciente com uma unidade médica, um registro conecta um estudante com uma instituição educacional e uma ligação covalente conecta dois átomos. Um importante conceito para a caracterização de Relators é a noção de Foundation. Foundation pode ser vista como um tipo de dependência histórica, de maneira que, por exemplo, uma instância de ser beijado é fundamentada em um beijo individual, ou uma instância de ser conectado entre aos aeroportos é fundamentada em uma conexão de um vôo em particular. Suponha que Gian está casado com Renata. Neste caso, podese assumir que há um Particular Relator (Relational Moment) m1 do tipo casamento que faz o intermédio entre Gian e Renata. A Foundation deste Relator pode ser, por exemplo, um evento de casamento ou de assinatura de um contrato social entre as partes envolvidas, que dá veracidade à proposição Gian é casado com Renata. A existência do relator depende historicamente deste evento. Há muitos Moments que Gian adquire pela virtude de ser casado com Renata. Por exemplo, considere todas as responsabilidades legais que Gian tem no contexto desta relação. Estas propriedades recentemente adquiridas são Intrinsic Moments de Gian que, consequentemente, são inerentes e existencialmente dependentes dele. Entretanto, estes Moments dependem também da existência de Renata. Este tipo de Moment é denominado na ontologia UFO como Externally Dependent Moments, isto é, Intrinsic Moments que são inerentes a um indivíduo único, mas que são existencialmente dependentes de outros indivíduos: um Moment x é externamente dependente (Externally Dependent) se e somente se é existencialmente dependente de um Particular que seja independente (no sentido técnico discutido anteriormente) do portador do Moment. No exemplo de um Externally Dependent Moment x há sempre um Particular externo a seu portador (isto é, que não é uma de suas partes ou seus Intrinsic Moments), que é a Foundation de x. Mais uma vez, no exemplo dado, pode-se pensar em um determinado evento e1 (evento do casamento ou assinatura do contrato social) em que Gian e Renata participam e em que fundamenta a existência destes Externally Dependent Moments inerentes a Gian.

41 25 Situations (situações) são tipos especiais de Endurants. São entidades complexas que são constituídas possivelmente por muitos Endurants (incluindo outras Situations). Situations são assumidas aqui como sinônimos do que é denominado na literatura de state of affairs, isto é, uma parcela da realidade que possa ser compreendida como um todo. Os exemplos de situações incluem José estar com gripe e febre, José está no mesmo local que Gian enquanto Bernardo estiver no mesmo local que André, José estar mais velho do que a idade mínima de aposentadoria enquanto Lula for presidente do Brasil, Renata está casada com Gian que trabalha para a UFES. A UFO define uma relação de estar presente em (being present at) entre Endurants e as Situations que eles constituem. Por exemplo, pode-se assumir que José (Substancial) e os seus Intrinsic Moments m1 (febre de José) e o m2 (gripe de José) estão presentes na Situation s1: José estar com gripe e febre. Espécie (Kind), Subespécie (Subkind), Coleção (Collection), Fase (Phase) e Papel (Role) são especializações de Sortal. Kind é um tipo que provê o Princípio de Identidade às suas instâncias, que são chamadas de complexos funcionais, ou seja, entidades cujas partes exercem diferentes papéis. Por exemplo, Pessoa é uma Espécie composta de várias partes, cada qual desempenha um papel distinto. Subkind é uma especialização de Espécie que herda desta entidade o Princípio de Identidade. Por exemplo, sendo Pessoa uma Espécie, pode-se definir Homem e Mulher como suas Subespécies. Um grupo de pessoas, porém, é uma instância do tipo Collection. Este tipo, assim como Espécie, provê o Princípio de Identidade a suas instâncias, que são, porém, conjuntos de objetos que exercem o mesmo papel. Pode-se dizer ainda que um indivíduo (ou coleção) que é instância de uma Espécie/Subespécie (ou Coleção), é necessariamente instância deste (em todos os mundos possíveis). Já o tipo Phase é um Sortal instanciado em determinado mundo ou período de tempo, mas não necessariamente em todos. Por exemplo, Criança, Adolescente e Adulto são fases da Espécie Pessoa. Também Role é um tipo de Sortal instanciado eventualmente, mais precisamente na Participação em um Evento ou numa determinada Relação. Por exemplo, Mãe é um Papel para a Subespécie Mulher mediante a existência da relação de

42 26 maternidade com uma instância do Papel Filho da Espécie Pessoa (GUIZZARDI, 2005a). Figura 2.3 Fragmento da UFO-A com foco nos Universais. Por fim, Category (Categoria) é um tipo de Mixin, que classifica as entidades que pertencem a Kinds diferentes, mas que compartilham uma propriedade comum essencial (ou seja, uma propriedade que eles não podem perder). Por exemplo, uma Categoria Entidade Racional pode ser especializada pelas Espécies Pessoa e Agente Artificial (GUIZZARDI, 2005a). Mixin é o tipo de entidade que representa Dispersive Universal (Universais Dispersivos), ou seja, cobrem conceitos com diferentes princípios de Identidade (GUIZZARDI, 2005a) UFO-B A UFO-B faz a distinção entre indivíduos Endurants e Perdurants. Tal distinção pode ser captada a partir do entendimento de seus comportamentos em relação ao tempo. Endurants são ditos como sendo totalmente presentes em qualquer momento em que existam, ou seja, os Endurants existem no tempo, no sentido de que se é dito

43 27 que, em uma circunstância c1, um Endurant e1 tem uma propriedade P1, e, em uma circunstância c2, a propriedade P2 (podendo ser incompatíveis entre si), é o mesmo Endurant e que está sendo referenciado em cada uma das situações. Por exemplo, pode-se dizer que o Particular Paulo pesa 80 Kg em c1, mas 68 Kg em c2. Nessas duas situações, é sempre o mesmo Particular Paulo que está sendo referenciado. Exemplos de Endurants são casas, pessoas, a Lua, um buraco e um punhado de areia. Perdurants, ou eventos, são indivíduos compostos de partes temporais. Os Perdurants acontecem no tempo, no sentido de que eles se estendem no tempo acumulando partes temporais. Exemplos de Perdurants são uma conversa, um jogo de futebol, uma sinfonia, uma festa de aniversário, a análise de um projeto de software, a Segunda Guerra Mundial e um processo de negócio. Sempre que um Perdurant está presente, não é o caso que todas as suas partes temporais estão presentes. Por exemplo, se for considerado o evento ocorrência de conversas em uma sala de bate-papo em diferentes partes do tempo em que ele está ocorrendo, em cada um desses instantes de tempo, somente algumas partes temporais estarão presentes, como a participação de uma pessoa X em um determinado período, mas a ausência dela em outro. Como consequência, perdurants não podem exibir mudança no tempo visto que nenhuma de suas partes temporais retêm sua identidade ao longo do tempo. A principal categoria dessa ontologia é Event (Evento) também podendo ser chamada de Perdurant ou Occurrent. Eventos podem ser atômicos (Atomic Event) ou complexos (Complex Event), dependendo de suas estruturas merológicas, ou seja, enquanto eventos atômicos não possuem subpartes, os eventos complexos são agregações de pelo menos dois outros eventos que por sua vez podem ser atômicos ou complexos. Eventos possibilitam transformações de uma porção da realidade para outra, ou seja, os eventos podem mudar a realidade mudando o estado de uma (pre-state) situation para uma (post-state) situation. A Figura 2.4 apresenta um fragmento da UFO-B.

44 28 Figura 2.4 Fragmento da UFO-B. Os Eventos são entidades ontologicamente dependentes, no sentido que dependem existencialmente de seus participantes (Participants) para existir. Tome, por exemplo, o evento e: a defesa de Gordon Banks (na cabeçada de Pelé na Copa de 70). Nesse evento, há a participação de Pelé (cabeceando a bola), de Gordon Banks (defendendo a cabeçada) e da bola. Neste caso, e é composto da participação individual de cada uma destas entidades. Cada uma destas participações é por si própria um evento, que pode ser atômico ou complexo, mas existencialmente dependente de um Particular. É importante enfatizar que ser atômico e ser instantâneo são noções ortogonais nesta estrutura, isto é, as participações atômicas podem ser estendidas ao longo do tempo assim como um evento instantâneo pode ser composto de múltiplas participações (instantâneas). Em (MASOLO et al., 2008), as propriedades especiais dos eventos são definidas em termos das propriedades espaciais de seus participantes. Ao contrário, as propriedades temporais dos Substantials são definidas em termos dos eventos nos quais participam. Analogamente ao que foi discutido com Endurants, as propriedades temporais dos eventos têm seus valores obtidos (seu Qualia) projetando estas propriedades em uma estrutura de qualidade (Quality Structure).

45 29 Aqui, define-se o espaço conceitual de tempo como sendo uma estrutura composta de Time Intervals (intervalos de tempo). Um intervalo de tempo, por sua vez, é composto de Time Points (pontos no tempo). Tais pontos no tempo podem ser representados como números reais e os intervalos de tempo como sendo um conjunto de números reais. Entretanto, podem também ser interpretados como entidades Sui Generis, como os Chronoids e os Times Boundaries da GFO (HELLER e HERRE, 2004b). Por fim, adicionalmente, é admitida a existência de: (i) intervalos limitados por um ponto de início e por um de fim, ou podendo ter intervalos abertos; (ii) intervalos contínuos e não-contínuos; e (iii) intervalos com e sem duração instantania. Particularmente, esse modelo permite uma diversidade de estruturas temporais, como as de tempo linear, de ramificação, paralelo e circular. No caso de estruturas ordenadas, são utilizados as chamadas Relações de Allen (ALLEN, 1983), as relações temporais entre os intervalos, de onde se deriva as relações correspondentes entre eventos. Essas relações são mostradas na Figura 2.5. Figura Exemplificando os Allen s Relations: relações temporais entre intervalos de tempo UFO-C A UFO-C é uma ontologia de entidades sociais (incluindo tanto Endurants quanto Perdurants). A UFO-C é baseada nos conceitos de Substantial e Moment Individual definidos na UFO-A e no conceito de evento especificado na UFO-B. A

46 30 ontologia começa a ser entendida pela distinção de Substantials em agentes (Agents) e objetos (Objects). A Figura 2.6 apresenta um fragmento da UFO-C. Figura Fragmento da UFO-C. Os agentes (Agent) podem ser Sociais (Social Agent) como, por exemplo, uma organização ou uma sociedade; e não sociais como um software. Deve ser ressaltada a diferença entre um agente humano (Human Agent) ou biológico (Biological Agent), um agente artificial (Artificial Agent) e um agente institucional (Institutional Agent), que são, respectivamente, agentes representados por seres humanos, entidades computacionais (em geral, software) e agentes que representam organizações ou subunidades da organização (tais como departamentos, áreas e divisões). Os agentes institucionais são compostos de diversos (outros) agentes, que podem ser eles mesmos seres humanos, artificiais ou institucionais (GUIZZARDI et al., 2007a) (ALMEIDA et al., 2009). um Institutional Agent exemplifica o que é chamado de Functional Complex (GUIZZARDI, 2005a), isto é, uma entidade mereológica complexa, cujas partes desempenham diferentes papéis em relação ao todo. O relacionamento entre o Institutional Agent e suas partes é um tipo de relacionamento todo-parte especial chamado Component-Functional Complex. Este relacionamento é utilizado para representar que as partes possuem um link

47 31 funcional com o todo, e desta forma, as partes contribuem para o funcionamento (e/ou comportamento) do todo (GUIZZARDI, 2005a). A estrutura funcional de composição de um Institutional Agent é definida da seguinte maneira (ALMEIDA et al., 2009): Vamos considerar que X é um Institutional Agent (ou um Institutional Agent Universal) e N é uma Normative Description associada a X. N define para X um conjunto de funções (functions) que devem ser instanciadas para que X exista, perdure e apresente as propriedades essenciais (incluindo comportamento) associada a X (ou uma instância de X). Essas funções são designadas para um conjunto de Social Roles prescritos para existirem em X. Finalmente, um agente z é dito ser uma parte funcional de X (ou instância de X) se, e somente se, z instancia um dos Social Roles definidos na Normative Description N associada a X. No caso dos Social Function Complexes (como as Institutional Agents, por exemplo), a definição do universal instanciado por um Agent é feito via Normative Description. A Figura 2.7 apresenta os relacionamentos entre Agent e Normative Description.

48 32 Figura 2.7 Fragmento da UFO-C contendo a relação entre Social Agent e Normative Description. Agentes são Substantials que podem possuir tipos especiais de propriedades chamados Intentional Moments (Propriedades Intencionais). Como defendido em (SEARLE, 2000), intencionalidade deve ser entendida em um contexto mais amplo que a noção de ter a intenção de algo deve ser entendida como a capacidade de algumas propriedades de certos indivíduos referenciar certas situações da realidade. Todo Intentional Moment tem um tipo (e.g., Belief (Crença), Desire (Desejo), Intention (Intenção)), e um conteúdo proposicional (Proposition). O conteúdo proposicional é entendido como sendo uma representação abstrata de uma classe de situações referenciadas por um Intentional Moment. (Dessa maneira, ter a intenção de algo (Intending Something) é um tipo específico de intencionalidade chamada Intention). O conteúdo proposicional de uma intenção é um Goal (Objetivo). Uma descrição precisa da relação entre um Intentional Moment e uma Situation (da UFO-A) é a seguinte: situações da realidade podem satisfazer o conteúdo proposicional de uma intenção, ou seja, satisfazer no sentido da lógica a proposição representada pelo conteúdo proposicional. Crenças podem ser justificadas por situações da realidade. Como exemplos, inclui-se a crença de que Roma é a capital da Itália e a de que a Lua orbita a Terra. Desejos e intenções podem ser satisfeitos (atingidos) ou frustrados. Enquanto um desejo expressa uma vontade de um agente que um estado do mundo torne-se real (e.g., o desejo de que

49 33 o Brasil ganhe a próxima Copa do Mundo), intenções são estados do mundo desejados os quais o agente busca atingir Internal Commitments (compromissos internos, ou compromissos pessoais), como a intenção de passar de ano (CONTE e CASTELFRANCHI, 1995) (SEARLE, 2000). Por essa razão, intenções, ou compromissos internos, fazem com que os agentes executem ações. Os objetos (Object) podem também ser categorizados em objetos sociais (Social Object) e não-sociais. Os objetos não-sociais incluem um livro, uma árvore ou um carro. Objetos sociais incluem dinheiro, linguagem e Descrições Normativas (Normative Description). Uma Normative Description define uma ou mais regras, ou normas, reconhecidas por pelo menos um agente social (Social Agent), permitindo-se, dessa maneira, a definição de universais nominais, como tipos de propriedades sociais (e.g., tipos de compromissos sociais), objetos sociais (a coroa do rei da Espanha) e papéis sociais (Social Roles), como presidente, primeiro ministro e pedestre. Exemplos de Normative Description incluem a constituição Italiana e a regulamentação do programa de Mestrado em Informática da Universidade Federal do Espírito Santo, e também um conjunto de diretivas em como realizar certas ações dentro de uma organização uma descrição de um plano (BOTTAZI e FERRARIO, 2006). Actions (ações) são eventos intencionais, ou seja, eventos que instanciam um plano (Plan), ou tipo de ação (Action Universal), com o propósito específico de satisfazer (o conteúdo proposicional de) algum compromisso interno. Exemplos de ações são escrever um artigo, um processo de negócio e um ato de comunicação. Como os eventos, as ações podem ser atômicas (Atomic Action) ou complexas (Complex Action). Uma ação complexa é composta de duas ou mais participações (Participation). As participações podem ser eventos intencionais (i.e., serem elas mesmas ações) ou eventos não-intencionais. Por exemplo, a punhalada de Brutus em Cesar inclui a participação intencional de Brutus e a não-intencional do punhal. Em outras palavras, seguindo a teoria filosófica de ações, tem-se que não é o caso que qualquer participação de um agente é considerada uma ação, mas somente aquelas participações intencionais chamadas aqui de Action Contributions. Somente

50 34 agentes entidades capazes de ter Intentional Moments podem executar ações. Quando um objeto participa de uma ação é dito que existe uma Object Participation de um Object (Non-Agentive). A Figura 2.8 apresenta um fragmento da UFO-C com foco na entidade Action. Figura 2.8 Fragmento da UFO-C com foco na entidade Action. Uma ação complexa, composta de Action Contributions de diferentes agentes, é chamada de Interaction (interação). Dois artistas colaborando para criar uma escultura é um exemplo de uma interação, assim como um diálogo entre dois agentes. Nesse caso citado, a escultura, bem como as ferramentas e as matérias-primas usadas para criá-la, são exemplos de Object (Non-agentive). Objetos podem participar de ações de diferentes maneiras. Há quatro diferentes modos de participação de Object (Nonagentive) (Resource Participation): criação (Creation), finalização (Termination), mudança (Change) e uso (Usage), que podem ser caracterizados do seguinte modo: seja r um recurso, a uma ação e s1, s2 duas situações que são, respectivamente, pre-state e post-state da ação a. Então, define-se: i. Creation: a participação do Object (Non-agentive)r em a é uma criação se, e somente se, (r não está presente em s1) e (r está presente em s2) e (existe pelo menos uma Action Contribution ac que também é parte de a e que s2 satisfaz o conteúdo proposicional (objetivo) de ac);

51 35 ii. Termination: a participação do Object (Non-agentive)r em a é uma destruição se, e somente se, (r está presente em s1) e (r não está presente em s2) e (existe pelo menos um Action Contribution ac que também é parte de a de tal modo que s2 satisfaz o conteúdo proposicional de ac); iii. Change: a participação de um Object (Non-agentive)r em a é uma mudança se, e somente se, existe pelo menos uma propriedade m tal que ((m é inerente a r em s1 e não é inerente a r em s2) ou (m não é inerente a r em s1 e m é inerente a r em s2)) e (existe pelo menos um Action Contribution ac que também faz parte de a e que s2 satisfaz o conteúdo proposicional de ac); iv. Usage: a participação de um Object (Non-agentive)que não é nenhum dos três tipos de participação anteriormente mencionados é uma participação de recurso do tipo Usage. Como discutido em (GUIZZARDI et al., 2007a) uma participação de recurso pode ser a causa de uma dependência de recurso (Resource Dependence) e o resultado de uma delegação de recurso (Resource Delegation) entre agentes. Em uma delegação de recurso, o agente A dá uma permissão de recurso r ao agente B. Para que isso aconteça, A deve ter o direito de conceder a permissão ao agente B e, além disso, a possibilidade de conceder o modo correto de permissão (por exemplo, permissão de usar ou modificar). Communicative Acts (Atos de comunicação) podem ser usados para criar Social Moments. Nesta visão, uma linguagem representa não somente a realidade, mas cria também uma parte da realidade (SEARLE, 2000). Assim, Social Moments são tipos de Intentional Moments que são criados pela troca de Communicative Acts e pelas consequências dessas trocas (por exemplo, adoção de um objetivo ou uma delegação (GUIZZARDI et al., 2007a). Por exemplo, suponha o aluguel de um carro em um serviço de aluguéis de carros; ao assinar um acordo de negócio, um agente executa um Communicative act (neste caso uma promessa). Esse ato cria um compromisso social (Social Commitment) para essa organização: um compromisso de retornar o carro em boas condições de uso, etc (o conteúdo proposicional). Além disso, cria também uma reivindicação social (Social Claim) dessa organização para o agente.

52 36 Uma relação social (Social Relator) é um exemplo de um relator composto de dois ou mais pares de compromissos/reivindicações associados (Social Moments). Finalmente, um compromisso (Commitment) (interno ou social) é cumprido (Fulfilled) por um agente a se este agente executar uma ação x tal que o pós-estado dessa ação seja uma situação que satisfaça ao conteúdo proposicional desse compromisso. A Figura 2.9 mostras um fragmento da UFO-C contendo os conceitos discutidos nesse parágrafo. Figura 2.9 Fragmento da UFO-C contendo outros conceitos sociais. 2.4 DESENVOLVIMENTO ORIENTADO A MODELOS Atualmente existe uma grande distância entre a etapa de elicitação de requisitos e o desenvolvimento (codificação) de sistemas computacional (ALMEIDA et al., 2006a) (ALMEIDA, 2006), tornando, assim, o desenvolvimento de um aplicativo computacional demorado e custoso. O Desenvolvimento Orientado a Modelos é uma das possíveis soluções para aumentar a velocidade e diminuir o custo do desenvolvimento de um aplicativo computacional. O Desenvolvimento Orientado a Modelos é uma abordagem de desenvolvimento de sistemas computacionais, que aumenta o poder da utilização de modelos para esta finalidade (OMG, 2003). Tal abordagem proporciona um meio de utilizar modelos no curso do entendimento, projeto, construção, implantação, operação, manutenção e modificação de sistemas computacionais (OMG, 2003). Os modelos são expressos em linguagens de modelagem que possuem sua sintaxe abstrata descritas em modelos conhecidos como metamodelos (ALMEIDA et al., 2006b).

53 Processo de Desenvolvimento Orientado a Modelos O Processo de Desenvolvimento Orientado a Modelos é caracterizado como uma sequência de etapas de projeto que possuem como finalidade o desenvolvimento de um sistema computacional. Para cada etapa de projeto, atividades de projeto são executadas. Cada atividade de projeto contém uma atividade de transformação (do inglês, transformation activity) e uma atividade de avaliação (do inglês, assessment activities) (ALMEIDA et al., 2006a). Uma atividade de transformação é uma atividade de projeto genérica que é responsável por produzir um modelo destino (do inglês, target model) tendo com base um modelo origem (do inglês, source design) e um ou mais requisito que devem ser satisfeitos. Uma atividade de avaliação é uma atividade de projeto genérica que possui como compromisso avaliar o modelo destino produzido pela atividade de transformação. A noção de modelo origem e destino depende da etapa do projeto (ALMEIDA et al., 2006b). Em princípio, as atividades de avaliação devem incluir a avaliação de conformidade (do inglês, conformance assessment) para avaliar se o modelo destino está em conformidade com o modelo origem (ALMEIDA, 2006). A teoria sobre o relacionamento entre conformidade e transformações é apresentada na seção Durante o processo de desenvolvimento do sistema computacional, as atividades de transformação incorporam diversas decisões de projetos que adicionam características que eventualmente estarão associadas ao sistema em realização. Diferentes decisões de projeto guiam para diferentes alternativas de realização. A redução do espaço de realização imposta pelas sucessivas decisões de projeto é apresentada na Figura As decisões de projeto aplicadas em cada etapa do projeto devem reunir dois requisitos para que o processo de construção do sistema computacional tenha sucesso: i. as decisões devem contribuir para satisfazer requisitos do sistema que ainda não foram cumpridos, e

54 38 ii. as decisões de projeto devem preservar as características que estão presentes no modelo origem, isto é, o modelo destino deve estar em conformidade com o modelo origem (ALMEIDA et al., 2006a). As decisões de projeto devem eventualmente guiar o projeto de desenvolvimento do sistema computacional, a fim de definir todas as características que são necessárias para o sistema em realização. A plataforma em que o sistema computacional irá ser desenvolvido, particularmente, define como as decisões de projeto podem ser realizadas. De forma similar, as decisões de projeto definem as possíveis plataformas em que o projeto pode ser realizado (ALMEIDA et al., 2006a). Figura 2.10 Redução do espaço de soluções para um projeto com diferente níveis de abstração (ALMEIDA et al., 2006a) Plataformas de Realização e Modelos Independentes de Plataforma Uma plataforma de realização provê ao projetista um conjunto de construtores reusáveis. Esses construtores permitem ao projetista desenvolver um sistema computacional sem que o mesmo tenha a necessidade de se preocupar com a implementação dos construtores (ALMEIDA et al., 2006a). Por prover um conjunto de construtores reusáveis, a plataforma de realização impõe um conjunto de regras no

55 39 projeto do sistema computacional. Essas regras impostas pela plataforma de realização devem ser incorporadas nas etapas de projeto do sistema computacional em realização (ALMEIDA et al., 2006a). Quando os sistemas computacionais são descritos de forma a evitar depedências dos construtores de uma plataforma específica, os modelos utilizados são chamados de modelos independentes de plataforma (do inglês, platform-independent models PIMs) (OMG, 2003). A independência de plataforma evita poluir modelos independentes de plataforma com interesses relacionados a restrições de uma plataforma específica, facilitando o reúso dos mesmos modelos para a construção de um sistema em diferentes plataformas (ALMEIDA et al., 2006a) Relacionamento entre Conformidade e Transformações As regras de conformidade determinam o mínimo que deve ser preservado na etapa de projeto, ou seja, determinam o máximo de liberdade para a criação do modelo destino sem perder as decisões de projeto presentes no modelo origem. As especificações de transformação determinam o máximo que pode ser escrito na etapa de projeto, ou seja, determinam o resultado em um específico modelo destino (mínimo de liberdade) (ALMEIDA et al., 2006a). Isto é apresentado na Figura Figura 2.11 Relação entre conformidade e transformações (ALMEIDA et al., 2006).

56 40 As regras de conformidade determinam implicitamente o conjunto de modelos destino que estão em conformidade com um modelo origem. Essas regras são faróis e um modelo origem ilumina uma área alvo no nível do modelo destino. Em contraste, uma especificação de transformação (não-parametrizada ou determinística) é descrita como uma seta do modelo origem para o modelo destino (ALMEIDA et al., 2006a). A avaliação da conformidade pode ser realizada como mostra a Figura A Figura 2.12 ilustra o que é feito durante a construção de um modelo destino Dt a partir de um modelo origem Ds, com a inserção de características c (consequência das decisões de projeto que foram tomadas). Para considerar a conformidade de um modelo destino com relação a um modelo origem, devemos abstrair as características do modelo destino, resultando, assim, em uma abstração modelo destino Dt`. Então, devemos checar se o modelo destino sem as características (Dt`) é equivalente (~) ao modelo origem (ALMEIDA et al., 2006a). Para abstrair as características c que foram inseridas, é necessário conhecer as decisões de projeto que foram tomadas no passo de projeto que levou Ds a Dt. Se, por exemplo, durante a construção do modelo destino, uma interação foi inserida, nós devemos saber que a interação deve ser abstraída durante o processo de validação da conformidade (ALMEIDA et al., 2006a). Figura 2.12 Conformidade e transformação (ALMEIDA et al., 2006a). Uma transformação do modelo origem Ds para o modelo destino Dt é um caso especial de construção de um modelo destino. Neste caso, o modelo destino e as características inseridas são completamente determinados pelas regras de transformação e pelo modelo origem Ds. Consequentemente, as características c que devem ser abstraidas durante a avaliação de conformidade podem ser automaticamente determinadas por uma função ftransform aplicada sobre o modelo origem Ds. Essa função deve ser definida como um complemento da transformação. Se tal função existe, é possível validar automaticamente a conformidade do modelo destino em relação ao modelo origem. A Figura 2.12 (ii) ilustra este caso.

57 41 A Figura 2.12 (iii) ilustra o caso das transformações parametrizadas. Para as transformações parametrizadas, as decisões de projeto que foram tomadas nas etapas de projeto são determinadas pelas regras de transformação, o modelo origem e os valores dos parâmetros. Consequentemente, c pode ser determinada por uma função ftranform no modelo origem Ds e valores dos parâmetros p (ALMEIDA et al., 2006a). Uma abordagem de Desenvolvimento Orientado a Modelos que preserva conformidade em suas transformações sempre produz modelos de destino que estão em conformidade com os modelos de origem. O benefício deste tipo de abordagem é que as atividades de validação de conformidade não tem que ser executadas manualmente para cada aplicação de transformação. Isto é particularmente beneficial para as abordagens de projeto iterativas em que as transformações são re-aplicadas com frequência para lidar com as mudanças nos modelos de origem (ALMEIDA et al., 2006a). A fim de demonstrar que uma transformação de modelos garante a conformidade, é necessário demonstrar que, para cada modelo origem Ds: abstract(transform(ds), ftransform(ds)) ~ Ds. Para as transformações parametrizadas, é necessário demonstrar que, para cada modelo origem Ds e cada valor admissível do parâmetro de Ds: abstract(transform(ds), ftransform(ds, p)) ~ Ds. 2.5 SISTEMAS DE INFORMAÇÃO ORIENTADOS A PROCESSOS DE NEGÓCIO Um dos principais desafios enfrentados pelas organizações, atualmente, é transformar os conceitos e as ideias em produtos e serviços de maneira rápida e com menor custo e impacto possível em seus ambientes organizacionais (DUMAS et al., 2007). Para suprir estas necessidades organizacionais, diversos tipos de Sistemas de Informação (ALTER, 1999) têm surgido.

58 42 Nas décadas de 70 e 80, o desenvolvimento de sistemas de informação foi dominado pelas abordagens orientadas a dados (do inglês, data-driven approach). O foco da tecnologia da informação (TI) era o armazenamento, recuperação e apresentação das informações (primeiramente vista como dados) (DUMAS et al., 2007). De certa forma, a modelagem de dados foi o ponto de partida para o desenvolvimento de sistemas de informação nesta época. Porém, devido ao foco nos dados, os modelos de processos foram negligenciados. Como resultado, a lógica dos processos de negócio foi espalhada em diversos sistemas computacionais e processos manuais (DUMAS et al., 2007). Além disso, os processos de negócio foram estruturados para se adaptarem às limitações dos sistemas computacionais, introduzindo assim a ineficiências ao processo de negócio como, por exemplo, alocação de recursos humanos desnecessários e uma separação pobre de responsabilidade para a execução das atividades organizacionais (DUMAS et al., 2007). A partir da década de 90 houve uma tendência voltada para o gerenciamento dos processos de negócio, desta forma, trazendo uma grande ênfase para os processos de negócio. Como resultado, os responsáveis pelo desenvolvimento de sistemas computacionais recorreram às abordagens orientadas a processos (do inglês, processes driven approach). Através das abordagens orientadas a processos, estabelecer o cenário para o surgimento dos sistemas de informação sensível a processo (do inglês, process-aware information systems - PAISs) (DUMAS et al., 2007). DUMAS et al. (2007) definem um sistema de informação sensível a processos como: um sistema computacional que gerencia e executa processos operacionais envolvendo pessoas, aplicativos computacionais e/ou fontes de informações tendo como base um modelo de processo. Dada essa definição, pode ser visto que um editor de texto e um cliente de não são aplicações sensíveis ao processo, à medida em que estes são utilizados para facilitar a execução de uma ou mais tarefas específicas, sem tomar conhecimento do processo

59 43 que a tarefa faz parte. Neste tipo de sistemas os usuários executam tarefas em uma ordem pré-estabelecida (DUMAS et al., 2007). Os sistemas de informação sensíveis a processos são construídos sobre uma infraestrutura tecnológica que permite separar os sistemas computacionais e o processo organizacional. Exemplos dessas infraestruturas são sistemas de gerenciamento de fluxo de trabalho (do inglês, workflow management systems), process-aware groupware e algumas plataformas de integração de aplicações computacionais (do inglês, Enterprise Application Integration Plataforms - EAI). Nos sistemas de informação tradicionais, o processo suportado por estes não é avaliado como um todo ou é codificado diretamente em um programa ( hard-coded ). A manutenção dos sistemas de informação tradicionais em que o código da aplicação é misturado com a lógica do processo é cara e propensa a erros. Durante o seu ciclo de vida, os processos requerem adaptações devido às mudanças organizacionais. As mudanças no processo em um sistema de informação tradicional requerem modificações no código fonte. Cada modificação no código fonte pode guiar a erros de programação ou a resultados inesperados. Por outro lado, o princípio central do gerenciamento de fluxo de trabalho é a separação da lógica do processo e das aplicações. As mudanças no processo podem ser feitas usando ferramentas de fluxo de trabalho sem ter a necessidade de reescrever o código fonte do sistema (DUMAS et al., 2007). Desta forma, basta apenas modificar os modelos de processo para evoluir o sistema de informação (VAN DER AALST e JABLONSKI, 2000). O mesmo princípio da remoção de funções genéricas dos aplicativos computacionais tem sido aplicado com sucesso na área Sistemas de gerenciamento de base de dados (do inglês, Data-Base Management System), em que a funcionalidade de gerenciar os dados (tais como processamento de pesquisas, controle de integração ou controle de concorrência) é levado para fora dos sistemas computacionais (DUMAS et al., 2007). A infraestrutura dos sistemas de informação sensíveis a processos pode ser usada para evitar a codificação da lógica do processo nas aplicações computacionais, deixando tais regras nos modelos de mais alto nível e facilitando, assim, o (re) projeto dos sistemas de informação. Mais do que isso, os sistemas de informação sensíveis a processo permitem o gerenciamento dos recursos das organizações de forma mais eficiente. Por exemplo,

60 44 os sistema de gerenciamento de fluxo de trabalho e as plataformas de EAI permitem aos projetistas e desenvolvedores implementarem as mudanças do processo através de modelos de processo de negócio (uma prática consistente com a MDA). Mais ainda, o isolamento do gerenciamento de processo em um componente separado é consistente com o recente desenvolvimento de aplicações de integração do domínio intra e inter-organizacional (por exemplo, Web Services e Arquiteturas Orientadas a Serviços) (DUMAS et al., 2007). Por fim, a construção de sistemas de informação utilizando modelos de processos permite ao projetista uma visão global de todas as operações suportadas pelos sistemas de informação, permitindo a redução de informações redundantes dentro das tarefas e provendo oportunidades para interconectar transações separadas (VAN DER AALST e VAN HEE, 2002) (JABLONSKI e BUSSLER, 1996.) (LEYMANN e ROLLER, 1999) Sistemas de Gerenciamento de Fluxo de Trabalho Um sistema de informação sensível ao processo associa usuários e outros recursos (por exemplo, sistemas computacionais) às tarefas do sistema ou, de outro ponto de vista, tarefas e sistemas computacionais são alocadas para os usuários. Além disso, é necessário um controlador das tarefas do sistema de informação. Esta funcionalidade pode ser provida por um sistema de gerenciamento de fluxo de trabalho (do inglês, workflow management systems) integrado ou trabalhando em parceria com um sistema de informação (DUMAS et al., 2007). O gerenciador de fluxo de trabalho visa apoiar a execução do fluxo de atividades de um processo de negócio de uma organização, de tal forma que as atividades sejam feitas no momento certo, pela pessoa certa e com o sistema computacional adequado. O foco do gerenciador de fluxo de trabalho é na estrutura do processo de trabalho e não no conteúdo individual de cada tarefa. As tarefas são suportadas por sistemas computacionais específicos. O gerenciador de fluxo de trabalho associa as pessoas aos seus sistemas computacionais para que as atividades sejam realizadas pelas mesmas, como apresentado na Figura 2.13 (DUMAS et al., 2007).

61 45 Figura 2.13 Gerenciador de fluxo de trabalho como link entre Pessoas e Sistemas computacionais (DUMAS et al., 2007). Um sistema de fluxo de trabalho é um sistema de informação baseado em um sistema de gerenciamento de fluxo de trabalho, que suporta um conjunto específico de processos de negócio através da execução de uma especificação de um processo de negócio (DUMAS et al., 2007). Segundo DUMAS et al., 2007, uma especificação de processo de negócio descreve um tipo de processo de negócio que pode ser interpretado como um modelo para a execução concreta das instâncias do workflow. Mudanças estruturais nos tipos de processos podem ser feitas utilizando ferramentas de modelagem de workflow sem a necessidade de reescrever os sistemas computacionais. Para finalizar, o uso de Gerenciadores de Fluxo de Trabalho simplifica o desenvolvimento de sistemas computacionais, pois permitem o reúso de componentes computacionais e funcionalidades de processos, que são comuns a muitas aplicações computacionais, é provido pela arquitetura do sistema de gerenciamento de fluxo de trabalho (DUMAS et al., 2007). No escopo deste trabalho, um Gerenciador de Fluxo de Trabalho específico (como por exemplo, JBOSS jbpm, SAP Workflow e Oracle BPM Studio) é considerado como uma plataforma específica. Desta forma, uma especificação de processo de negócio que pode ser executado por um Gerenciador de Fluxo de Trabalho é um modelo de processo dependente de plataforma e será o alvo das transformações a serem descritas na abordagem proposta. 2.6 CONCLUSÃO Este capítulo apresentou um referencial teórico para embasar a abordagem de Desenvolvimento Orientado a Modelos proposta neste trabalho.

62 46 Primeiramente, foram discutidas as características que uma Arquitetura Organizacional de TI deve possuir para viabilizar a abordagem proposta. Dentre essas características, destaca-se o uso de uma linguagem de modelagem arquitetural que permita modelar diversos aspectos da organização (como, por exemplo, os processos de negócio e as interações entre as entidades organizacionais). Dentre os diversos frameworks de Arquitetura Organizacional de TI foi destacado o ARIS (ARchitecture for integrated Information Systems), devido ao seu grande uso no meio acadêmico e organizacional. Os conceitos do ARIS Method apresentados na seção serão de grande importância para a definição dos metamodelos apresentados no Capítulo 3. Uma das características da abordagem de Desenvolvimento Orientado a Modelos proposta neste trabalho é o uso adequado da semântica dos elementos das linguagens de modelagem das Arquiteturas Organizacionais em todas as etapas da abordagem. A seção 2.3 apresentou os conceitos da ontologia de fundamentação UFO que será a base conceitual da análise ontológica apresentada no Capítulo 4. Em relação ao Desenvolvimento Orientado a Modelos, o capítulo apresentou a definição formal desse processo de desenvolvimento de sistemas computacionais e também de outros conceitos como: transformação, parametrização e conformidade entre modelos. Tais conceitos são necessários para o entendimento por completo da abordagem de Desenvolvimento Orientado a Modelos apresentada no Capítulo 5. Por fim, a seção 2.5 apresentou os conceitos sobre os sistemas de informação orientados a processo de negócio. Tais conceitos são fundamentais para o entendimento do tipo de sistemas computacionais que a abordagem de Desenvolvimento Orientado a Modelos proposta neste trabalho visa construir, como será ilustrado no uso da plataforma JBOSS jbpm (CUMBERLIDGE, 2007) no Capítulo 6.

63 47 CAPÍTULO 3 METHOD METAMODELOS DAS LINGUAGENS DO ARIS 3.1 INTRODUÇÃO Conforme apresentado na seção 1.3, uma das características da abordagem de Desenvolvimento Orientado a Modelos proposta neste trabalho é possibilitar que o Projetista utilize a riqueza da semântica dos elementos de modelagem empregados para representar uma Arquitetura Organizacional de TI. Para isto, é necessário um estudo aprofundado das linguagens de modelagem de Arquiteturas Organizacionais de TI. Este capítulo apresenta o primeiro passo deste estudo, considerando as linguagens de modelagem dos domínios de Estrutura Organizacional, Processo de Negócio e Detalhamento de Atividades do framework ARIS. A escolha por essas linguagens deve-se ao grande uso destas na modelagem de Arquiteturas Organizacionais de TI e devido à relevância dos modelos criados nessas linguagens para o desenvolvimento de sistemas orientados a processos. Inicialmente, consideramos como fonte para a definição do ARIS Method o livro original do criador do método, Prof. Scheer (SCHEER, 1999). Apesar de Scheer (1999) apresentar a linguagem para representar cada uma das visões da metodologia ARIS, a implementação dessas linguagens no ARIS Toolset não condiz com o apresentado por Scheer. Em outras palavras, há elementos de uma determinada linguagem de domínio que estão presentes na ferramenta de modelagem e não estão presentes nos modelos ou nas descrições textuais em (SCHEER, 1999) e vice-versa. Por exemplo, o metamodelo organizacional apresentado em (SCHEER, 1999) inclui os elementos Organizational Object e Profile que não ocorrem no ARIS Toolset. Ao mesmo tempo, ARIS Toolset inclui o elemento System Organizational Unit que não ocorre no metamodelo organizacional apresentado em (SCHEER, 1999).

64 48 Essa deficiência na definição da linguagem cria empecilhos para o estudo e análise das linguagens do ARIS Method. Desta forma, as fontes definitivas para estudo dos elementos sintáticos e semânticos das linguagens de domínio do ARIS são as ferramentas ARIS (ARIS Toolset, ARIS Architecture, dentre outras), uma vez que estas são de fato empregadas em larga escala no desenvolvimento dos modelos. Como as ferramentas computacionais revelam diretamente apenas os elementos sintáticos concretos, a representação abstrata da linguagem suportada pela ferramenta deve ser escavada na ausência de documentação definitiva para essa representação. Essa representação da linguagem é chamada de sintaxe abstrata (HAREL e RUMPE, 2000) que pode ser parcialmente definida através de um metamodelo (OMG, 2003). Para obter a sintaxe abstrata das linguagens adotas pelo ARIS Toolset, definimos uma abordagem que permite a escavação e a construção dos metamodelos das linguagens do ARIS Method. Os detalhes das etapas dessa abordagem são apresentados em (SANTOS JR. e ALMEIDA, 2008). O resultado da aplicação da abordagem são os metamodelos apresentados neste capítulo. Os metamodelos foram modelados na linguagem ECORE (ECLIPSE, 2008). Este capítulo discute, ainda, a semântica dos elementos e relacionamentos presentes nesses metamodelos. Na ausência de especificação rigorosa da linguagem, a semântica das metaclasses de cada metamodelo de domínio foi inferida a partir da documentação on-line da ferramenta ARIS Toolset, de conhecimentos de modelagem adquiridos através da utilização do ARIS Toolset e das seguintes referências bibliográficas (DAVIS, 2001) (SCHEER, 1999). Diferentemente das metaclasses, os metarelacionamentos não possuem semântica definida na literatura e nem na documentação on-line da ferramenta. Desta forma, a semântica inferida para os relacionamentos foi derivada a partir da semântica dos elementos relacionados, do conhecimento de modelagem adquirido através da utilização do ARIS Toolset e de exemplos de uso desses relacionamentos na literatura como em (DAVIS, 2001) (SCHEER, 1999).

65 49 Este capítulo é organizado da seguinte forma: as seções 3.2, 3.3 e 3.4 apresentam informalmente a semântica dos elementos e relacionamentos dos metamodelos das linguagens organizacional, de processo de negócio e de detalhamento de atividades, respectivamente; a seção 3.5 apresenta o conceito denominado ARIS Object que é comum a todas as metaclasses dos metamodelos de domínio; a seção 3.6 apresenta uma discussão sobre elementos notacionais nos metamodelos de domínio; a seção 3.7 apresenta uma discussão sobre os metamodelos apresentados neste capítulo e a seção 3.8 as conclusões do capítulo. 3.2 METAMODELO DA LINGUAGEM ORGANIZACIONAL As principais metaclasses do metamodelo da linguagem organizacional são: Organizational Unit Type, Organizational Unit, Position, System Organizational Unit Type, System Organizational Unit, Location, Person, Person Type e Group. A Figura 3.1 apresenta um fragmento do metamodelo organizacional com os elementos Organizational Unit, Organizational Unit Type, Cost Center e seus relacionamentos. Os elementos em cinza na figura são elementos notacionais no ARIS, ou seja, são apenas especializações simples de metaclasses. A seção 3.6 apresenta uma discussão sobre elementos notacionais no ARIS Method

66 50 Figura Fragmento do metamodelo organizacional contendo Organizational Unit, Organizational Unit Type e seus relacionamentos. O elemento Organizational Unit representa uma entidade responsável pela execução de atividades que materializem os objetivos da organização. A Figura 3.2 apresenta os símbolos do elemento Organizational Unit. O elemento Organizational Unit possui o elemento notacional Cost Center. Organizational unit Organizational unit Figura 3.2 Símbolos do elemento Organizational Unit. As unidades organizacionais (Organizational Unit) podem ser categorizadas levando em consideração características em comum como, por exemplo, as responsabilidades e deveres que um possui conjunto de unidades organizacionais. Desta forma, o ARIS Method permite que sejam criados tipos de unidade organizacionais que são representados pelo elemento Organizationalal Unit Type. O elemento Organizational

67 51 Unit Type possui o elemento notacional Position Type. A Figura 3.3 apresenta os símbolos do elemento Organizational Unit Type. Organizational unit type Organizational unit type Figura 3.3- Símbolos do elemento Organizational Unit Type. O relacionamento is of type é utilizado para representar que uma determinada entidade é do tipo de outra entidade. Por exemplo, esse relacionamento é utilizado para expressar que uma Organizational Unit é do tipo Organizational Unit Type. A documentação on-line, assim como (DAVIS, 2001) e (SCHEER, 1999) definem que a menor unidade organizacional é representada por uma posição (Position) que um indivíduo (Person) possui dentro da organização. As posições podem ser alocadas de acordo com o tamanho das unidades, levando em consideração as regras do negócio ou a estrutura da empresa (SCHEER, 1999). Várias posições podem ser associadas a uma unidade organizacional. As responsabilidades e deveres de uma posição (Position) são definidos no Position Description (vide Figura 3.9). A Figura 3.4 apresenta o símbolo do elemento Position e a Figura 3.5 apresenta um fragmento do metamodelo organizacional contendo Position, Position Type, Organizational Unit Type e Organizational Unit e seus relacionamentos. Position Figura 3.4 Símbolo do elemento Position. O relacionamento is composed of entre Organizational Unit e Position representa que uma unidade organizacional é composta por uma ou mais posições. Por exemplo, esta relação pode ser usada para representar que o Departamento de Vendas é composto pelas posições Vendedor e Gerente de Vendas.

68 52 Figura Fragmento do Metamodelo Organizacional contendo os elemento Position, Position Type Organizacional Unit, Organizational Unit Type e seus relacionamentos. O autorrelacionamento is component of do elemento Organizational Unit representa que uma unidade organizacional é componente (é parte) de uma ou mais unidades organizacionais. Através desse relacionamento é possível modelar que o Departamento de TI e o Departamento de RH são componentes da uma empresa. O autorrelacionamento is responsible for do elemento Organizational Unit representa que uma unidade organizacional é a responsável legal por uma ou mais unidades organizacionais. Assim, é possível expressar, por exemplo, que o Departamento de TI de uma empresa é responsável pelo Departamento de Processo de Negócio da mesma. Os autorrelacionamentos can be disciplinary superior e can be technical superior do elemento Organizational Unit Type especificam quais as unidades organizacionais poderão ser consideradas superiores disciplinar e tecnicamente. O autorrelacionamento can be constituent do elemento Organizational Unit Type especifica quais os tipos de unidades organizacionais podem compor um outro tipo de unidade organizacional. Por exemplo, através desse relacionamento é possível expressar que o tipo de unidade organizacional Y pode ser composto pelos tipos de unidades organizacionais X e K. Os relacionamentos e autorrelacionamentos is disciplinary superior to, is technical superior to e is superior to, representam, respectivamente, que uma determinada

69 53 entidade (por exemplo, posição ou unidade organizacional) é superior disciplinarmente a outra entidade; que uma determinada entidade é superior tecnicamente a outra entidade e que uma entidade é superior hierarquicamente que a outra entidade. A associação de uma pessoa (Person) a uma unidade organizacional expressa que essa pessoa é um empregado da mesma e a associação de uma pessoa (Person) a uma posição (Position) define qual o status dela na organização, as funções e as responsabilidades dentro da organização. O elemento Person não possui símbolo, porém, os seus elementos notacionais External Person e Internal Person possuem. A Figura 3.6 apresenta o símbolo do elemento notacional External Person e o símbolo do elemento notacional Internal Person. External person Internal person Figura 3.6 Símbolo dos elementos notacionais do elemento Person. A Figura 3.7 apresenta um fragmento do Metamodelo Organizacional com foco no elemento Person. O relacionamento occupies entre Person e Position indica que uma pessoa ocupa uma determinada posição na organização, por exemplo, Paulo ocupa a posição de Gerente no Departamento de TI.

70 54 Figura 3.7 Fragmento do Metamodelo Organizacional com foco no elemento Person. O relacionamento belongs to entre Organizational Unit e Person (Organizational Unit belongs to Person) representa que uma unidade organizacional pertence a uma pessoa, expressando a idéia de posse ou que uma pessoa é o responsável legal pela unidade organizacional. Por exemplo, José da Silva é o responsável legal pela empresa X. O relacionamento belongs to entre Person e Organizational Unit (Person belongs to Organizational Unit) representa que uma pessoa (Person) faz parte de uma ou mais unidades organizacionais. É possível expressar através desse relacionamento que o empregado X trabalha na unidade organizacional Y. Os relacionamentos is Organizational manager for que ocorrem entre Positon e Person, Person e Organizational Unit, Person e Organizational Unit Type, Position e Organizational Unit e Position e Organizational Unit Type representam que uma entidade é gerenciada por outra entidade. Por exemplo, que o Gerente de RH gerencia o Departamento de RH ou que o empregado E é gerenciado pela position P. Os relacionamentos substitutes for que ocorrem entre Position e Person representam que uma entidade pode ser substituída por uma ou mais entidades. O elemento Person

71 55 possui um autorrelacionamento com o mesmo nome. Assim, é possível expressar que o empregado X foi substituído pelo empregado Y na organização. Da mesma forma que as unidades organizacionais (Organizational Unit), as pessoas (Person) também podem ser classificadas levando em consideração uma característica em comum como, por exemplo, as responsabilidades e deveres de um conjunto de empregados. Desta forma, o ARIS Method permite que sejam criados tipos de pessoas (Person Type) como, por exemplo, gerente de departamento, líder de grupos ou gerente de projeto. A Figura 3.8 apresenta o símbolo do elemento Person Type e a Figura 3.9 apresenta um fragmento do metamodelo organizacional com foco no elemento Person Type e seus relacionamentos. Person type Figura 3.8 Símbolo do elemento Person Type. Segundo a documentação on-line, o beneficio de utilizar os tipos (como, por exemplo, Organizational Unit Type e Person Type) é possibilidade de representar regras de negócios genéricas que são impostas a unidades organizacionais reais ou a pessoas da organização. Um exemplo disso é a possibilidade de especificar que somente um certo tipo de pessoa (Person Type) poderá desempenhar uma certa função ou ter acesso a uma determinada informação da organização. O elemento Person Type possui o elemento notacional Position Description O relacionamento performs ocorre entre Person Type e todos os demais elementos do metamodelos (com exceção dos elementos System Organizational Unit e System Organizational Unit Type) e representa que uma determinada entidade desempenha (instância) um Person Type. Por exemplo, através desse relacionamento é possível expressar que uma pessoa desempenha um Person Type chamado Gerente de projetos em uma unidade organizacional. O relacionamento belongs to representa que um Person Type pertence a uma unidade organizacional (Organizational Unit) ou a um grupo (Group), ou seja, esse relacionamento é utilizado para expressar, por exemplo, o Person Type Gerente de Projeto pertence ao Departamento de TI.

72 56 Figura Fragmento do metamodelo organizacional com foco no elemento Person Type e seus relacionamentos. O relacionamento can belongs to entre Person Type e Organizational Unit Type representa uma especificação de quais Person Types podem pertencer a um tipo de unidade organizacional. Por exemplo, é possível modelar que o Person Type Gerente de TI pode pertencer um tipo de unidade organizacional de TI. O relacionamento belongs to entre os elementos Group (Grupo) e Person Type representa que um ou mais Person Types pertencem a um grupo, ou seja, fazem parte de um grupo. Assim, através desse relacionamento é possível descrever que o Person Type Y pertence ao grupo K. O autorrelacionamento is generalization of e o autorrelacionamento is composed of representam, respectivamente, que um Person Type é uma generalização de outro Person Type e que um Person Type é composto de outros Person Types. Logo, através desses relacionamentos é possível expressar, respectivamente, que um Person Type Y é uma generalização de outros dois Person Types K e Z; e que o Person Type J é composto por outros dois Person Types.

73 57 O autorrelacionamento is in conflict with representa que um determinado Person Type está em conflito com outro Person Type. (Não há semântica detalhada para este relacionamento na literatura.) O elemento Location representa a posição geográfica de uma unidade organizacional (Organizational Unit), de uma pessoa (Person), de uma posição (Position) ou de um recurso da organização. Uma localização (Location) pode representar uma região, uma cidade, uma planta de chão de fábrica, um prédio, uma sala ou uma estação de trabalho.o elemento Location possui o elemento notacional Workstation. A Figura 3.10 apresenta o símbolo do elemento Location e a Figura 3.11 apresenta um fragmento do metamodelo de processo organizacional com foco no elemento Location e seus relacionamentos. Os relacionamentos at location e located at representam que uma determinada entidade está localizada em uma posição geográfica. Por exemplo, esses relacionamentos podem ser utilizados para representar que a posição Modelador de Processos de negócio está localizada na unidade organizacional Departamento de TI. Location Figura 3.10 Símbolo do elemento Location. O autorrelacionamento encompasses é utilizado para representar que uma determinada região geográfica pode englobar outras regiões geográficas permitindo, por exemplo: representar a localização Brasil como o conjunto de todas as posições geográficas dos estados brasileiros.

74 58 Figura 3.11 Fragmento do metamodelo organizacional com foco no elemento Location e em seus relacionamentos. Um grupo (Group) representa um grupo de empregados (Person) - com ou sem posições na organização - ou unidades organizacionais que estão trabalhando em conjunto por um período de tempo específico para um determinado objetivo. A Figura 3.13 apresenta um fragmento do metamodelo organizacional com foco no elemento Group e em seus relacionamentos e a Figura 3.12 apresenta o símbolo do elemento Group. Group Figura 3.12 Símbolo do elemento Group. Os relacionamentos is position of e is composed of representam que uma ou mais posições (Position) fazem parte de um grupo. Através desses relacionamentos é possível descrever, por exemplo, que o Position Analista de processo de negócio e o position Analista de demandas compõem o grupo chamado de Grupo de validação de demandas.

75 59 Figura 3.13 Fragmento do metamodelo organizacional com foco no elemento Group e em seus relacionamentos. O relacionamento has member representa que uma pessoa é membro de um grupo. Assim, é possível expressar que Paulo faz parte do grupo de pesquisa NEMO. O relacionamento is assigned to representa que um grupo está associado a uma ou mais unidades organizacionais, ou seja, esse relacionamento descreve que, de alguma forma, o grupo está ligado à organização. Esse relacionamento também pode ser utilizado para expressar que o grupo é reconhecido pela organização. Por exemplo, através desse relacionamento é possível expressar que uma determinada ONG é reconhecida pelo Brasil ou que o grupo de pesquisa NEMO está associado ao Departamento de Informática da UFES. O relacionamento is managed by que ocorre entre os elementos Group e Person representa que um ou mais grupos são gerenciados por uma ou mais pessoas. Por exemplo, através desse relacionamento é possível expressar que o grupo de pesquisa NEMO é gerenciado por João Paulo, Giancarlo e Ricardo Falbo.

76 60 O relacionamento cooperates with representa que dois ou mais grupos trabalham juntos para que um ou mais objetivos sejam alcançados. Esse objetivo pode ser comum a todos os grupos ou pertencente a apenas um dos grupos. Por exemplo, é possível expressar que o grupo X trabalha com o grupo Y para realizar uma determinada tarefa no processo de negócio da empresa. Infelizmente a documentação on-line do ARIS Toolset não fornece de forma clara a semântica dos elementos System Organizational Unit e System Organizational, assim, não conseguimos extrair a semântica desses elementos. A Figura 3.14 apresenta um fragmento do metamodelo organizacional com foco nos elementos System Organizational Unit e System Organizational Unit Type. Figura 3.14 Fragmento do metamodelo organizacional com foco nos elementos System Organizational Unit e System Organizational Unit Type. Por fim, a Figura 3.15 apresenta um exemplo de modelo organizacional construído utilizando as metaclasses do metamodelo organizacional do ARIS Method. Como pode ser observado na Figura 3.15, o elemento Vendas é uma instância da metaclasse Organizational Unit, os elementos Gerente e Vendedor são instâncias da metaclasse Position e as conexões entres os elementos do modelo são instâncias do metarelacionamento is composed of.

77 61 Figura 3.15 Exemplo de Modelo Organizacional Construído Utilizando as Metaclasses do Metamodelo Organizacional. 3.3 METAMODELO DA LINGUAGEM DE PROCESSO DE NEGÓCIO O metamodelo da linguagem de processo de negócio é formado pelas seguintes metaclasses Participant, Event, Rule, Function, Application System, Application System Type, Application System Class e Employee Variable. A metaclasse Participant é uma classe abstrata que representa os elementos organizacionais Organizational Unit Type, Organizational Unit, Position, Person Type, Person, Group. A metaclasse Application é uma classe abstrata que representa os elementos Application System, Application System Type, Application System Class. De acordo com o help do ARIS Toolset, uma Function é uma atividade técnica ou atividade realizada sobre um determinado objeto, que possui como finalidade apoiar um ou vários objetivos de negócios da organização. Uma atividade pode ser realizada por uma pessoa ou por um sistema de computador. A Figura 3.16 apresenta um fragmento do metamodelo de processo de negócio com o foco nos relacionamentos do elemento Function com o elemento Participant.

78 62 Figura Fragmento do metamodelo de processo com foco no elemento Function e seus relacionamentos com o elemento Participant e com o elemento Application. As atividades possuem inputs (informações ou matéria-prima) e criam outputs (informações diferentes ou produtos) e podem consumir recursos (DAVIS, 2001). As atividades de um processo de negócio têm o propósito de atingir um ou mais objetivos (SCHEER, 1999). A Figura 3.17 apresenta o símbolo do elemento Function. Function Figura Símbolo do elemento Function. O elemento notacional Process Interface, apresentado na Figura 3.18, do elemento function é utilizado para representar o ponto de finalização de um processo e início de outro subsequente processo de negócio (DAVIS, 2001) (MENDLING et al., 2005a) (MENDLING et al., 2005b). De maneira simplória, esse elemento notacional realiza um link entre dois processos de negócio. Process interface Figura 3.18 Símbolo do elemento Process Interface.

79 63 De acordo com (MENDLING et al., 2005b), existe uma especialização do elemento function chamada hierarchical function. Essa especialização é utilizada para representar que uma atividade do processo de negócio principal é refinada em um subprocesso de negócio do mesmo. O ARIS Method utiliza o símbolo padrão do elemento function para representar hierarchical function, ou seja, não há elemento notacional para representar que uma atividade do processo de negócio é refinada em um subprocesso de negócio. O relacionamento entre uma ou mais instâncias do elemento Function e um ou mais modelos de processo (sub-processos ou macro-processo) é realizado pelo conceito denominado Assignment. Esse conceito é apresentado detalhes na seção 3.5. O elemento notacional System Function (actual) representa as atividades que são suportadas por aplicativos computacionais ou por computadores. A Figura 3.19 apresenta o símbolo do elemento System Function (actual) (DAVIS, 2001). Figura 3.19 Símbolo do elemento System function (actual). O relacionamento carries out representa que um ou mais participantes do processo de negócio são os responsáveis legais pela execução da atividade, ou seja, que um ou mais participantes possuem o compromisso que a atividade seja realizada. É importante ressaltar que um ou mais participantes responsáveis legais pela realização da atividade podem ou não ser os executores da mesma. Assim é possível representar que o participante Analista de processo de negócio é o responsável pela conclusão da atividade Modelar processo de negócio. System function (actual) SYS SYS O relacionamento contributes to representa que um Participant contribui para que a atividade seja realizada (concluída), sem nenhuma responsabilidade legal sobre a conclusão da atividade. Os relacionamentos must be informed about, must be informed on cancellation e must be informed about result of representam, respectivamente, que um ou mais participantes devem ser informados sobre a execução da atividade que um ou mais

80 64 participantes devem ser informados quando uma atividade for cancelada e que um ou mais participantes devem ser informados sobre o resultado da atividade. Infelizmente não foi possível definir uma semântica clara para os seguintes relacionamentos entre Function e Participant: is technically responsible for, is IT responsible for, decides on, accepts e has consulting role in. Apenas podemos obter uma notação intuitiva devido ao nome desses relacionamentos. O elemento Employee Variable representa um espaço reservado para uma pessoa que será especificada posteriormente e cujo envolvimento no processo já pode ser identificado. O elemento Application System representa um software de computador que é utilizado para dar suporte à execução de atividades (Function) de um ou mais processos de negócios (DAVIS, 2001). A Figura 3.20 apresenta o símbolo do elemento Application System. Application system Figura 3.20 Símbolo do elemento Application System. O elemento Application System Type representa a tipificação do elemento Application System, ou seja, ele representa um tipo de aplicações que possuem exatamente as mesmas propriedades tecnológicas. A Figura 3.21 apresenta o símbolo do elemento Application System Type. Application system type Figura 3.21 Símbolo do elemento Application System Type. Conforme apresentado na documentação on-line da ferramenta de modelagem, o elemento Application System Class representa uma classificação feita aos tipos de aplicações (Application System Type) baseada em diversos critérios de classificação. Assim, um Application System Type pode estar em diversas classes de aplicações de

81 65 sistemas (Application System Class). A Figura 3.22 apesenta o símbolo do elemento Application System Class. Application system class Figura Símbolo do elemento Application System Class. O relacionamento supports entre Application e Function representa que uma atividade é apoiada por uma aplicação computacional, por um tipo de aplicação computacional ou por uma classe de aplicações computacionais. Um evento (Event) representa um estado que é relevante para o gerenciamento do processo e que influencia ou controla o fluxo de execução de um ou mais processos de negócio. Mudanças no estado são refletidas na troca do status das informações relevantes do processo. A Figura 3.23 apresenta o símbolo do elemento Event. Event Figura 3.23 Símbolo do elemento Event. Eventos disparam atividades (Function) e são resultados de atividades ou são criados por atores externos ao processo (SCHEER, 1999). Um evento tem um aspecto temporal e ocorre em um instante de tempo. A Figura 3.24 apresenta um fragmento do metamodelo de processo de negócio contendo os relacionamentos entre Function, Event e Rule. Segundo (DAVIS, 2001) os eventos representam as pré-condições e pós-condições para cada etapa do processo. As pré-condições representam estados da realidade que ativam uma ou mais atividades. As pós-condições representam estados da realidade após a execução da atividade. Os eventos podem ocorrer como um resultado de algo que uma pessoa realizou ou como resultado de uma operação de algum software (DAVIS, 2001). Por fim, de acordo com (DAVIS, 2001), um evento final em um processo pode ativar um ou mais processos da organização, desta forma, criando uma ligação entre dois ou mais processos.

82 66 Figura 3.24 Fragmento do metamodelo de processo contendo os relacionamentos entre Function, Event e Rule. De acordo com (DAVIS, 2001), as atividades são ativadas por um ou mais eventos (Events). Na metodologia ARIS um evento ativa uma atividade e uma atividade sempre cria um ou mais novos eventos. Os relacionamentos activates e creates entre Function e Event representam, respectivamente, que uma atividade é ativada por zero ou mais eventos e que um ou mais funções podem criar zero ou mais eventos. O relacionamento is predecessor of representa que uma atividade é predecessor de outra atividade do processo de negócio. Assim, é possível expressar que uma atividade A acontece antes de uma atividade B. O elemento Rule representa os operadores lógicos que permitem especificar um relacionamento lógico entre eventos (Event) e atividade (Function) em um processo de negócio. As Rules são utilizadas para controlar o fluxo do modelo de processo, ou seja, as regras definem o caminho que fluxo do processo deve seguir, tomando como base as informações processadas nas atividades que a precedem (DAVIS, 2001). As três regras básicas são: OR, XOR e AND. Qualquer regra pode estar ligada, antes ou depois, a atividades de decisão. A Tabela 3.1 apresenta as regras básicas do ARIS.

83 67 Tabela Regras básicas do ARIS. Operador Símbolo Antes de uma função Após uma função OR XOR AND Qualquer evento, ou combinação de eventos, ativa uma atividade Um, e somente um, evento ativa uma atividade Somente após a execução de todos os eventos a atividade será ativada Um ou mais caminhos serão habilitados com o resultado da atividade Um, e somente um, caminho será habilitado com o resultado da atividade Divide o processo em dois ou mais caminhos em paralelo. O ARIS Toolset apresenta outros elementos notacionais para o elemento Rule, conforme apresentado na Tabela 3.2, no entanto, não é apresentada a semântica para os mesmos. Segundo (DAVIS, 2001), os elementos presentes na tabela abaixo não possuem semântica definida e em muitos casos tais elementos possuem semânticas ambíguas. Assim, os elementos notacionais presentes na Tabela 3.2 não serão considerados neste trabalho. Tabela 3.2 Outras regras do ARIS. Elemento Elemento notacional Rule Gateway AND/XOR Rule XOR/AND Rule OR/AND Rule XOR/OR Rule OR/XOR Rule Rule As atividades (Function) são responsáveis por tomar as decisões e as regras (Rules) que determinam qual a lógica do fluxo que o processo irá tomar. O relacionamento is evaluated by é utilizado para especificar, em alguns casos até mesmo compor, o Event que é necessário para que uma determinada etapa do processo de negócio seja realizada. O conector direcionado na Figura 3.25 representa o relacionamento is evaluated by.

84 68 Event 1 Event 1 Event 1 Event 2 Event 2 Event 2 Figura 3.25 Exemplo o relacionamento is evaluated by entre Event e Rule. O relacionamento activates é utilizado para especificar que uma ou mais atividades do processo de negócio serão ativadas após o seu pré-estado ser selecionado ou composto, através do relacionamento is evaluated by, por algum elemento Rule. A Figura 3.26 apresenta um exemplo do relacionamento activates. Event 1 Event 1 activates Function activates Function Event 2 Event 2 (A) (B) Figura 3.26 Exemplo do relacionamento activates. Conforme apresentado no exemplo acima, o elemento RULE-AND (Figura 3.26 (A)) é responsável por criar um evento (Event) que ativa, através do relacionamento activates, uma atividade (Function). Na Figura 3.26 (B) o elemento RULE-XOR é responsável selecionar um evento (Event) que irá ativar uma atividade. O autorrelacionamento links do elemento Rule é utilizado para especificar regras comportais mais complexas no processo de negócio. A Figura 3.27 apresenta um exemplo desse relacionamento.

85 69 Event 1 links Event 2 Event 3 Figura 3.27 Exemplo do relacionamento links. No exemplo acima, o relacionamento link é utilizado para especificar uma regra de comportamento que tem como consequência a construção de um novo evento que será composto pelo Event 1, Event 2 e Event 3 ou apenas pelo Event 1 e Event 2 ou apenas Event 3. O relacionamento leads to representa a relação entre a atividade que antecede a regra (Rule) e os eventos (Event) que são criados pela atividade. A Figura 3.28 apresenta um exemplo da relação leads to entre uma atividade e um Rule-XOR. Event 1 Function leads to Event 2 Figura 3.28 Exemplo do relacionamento leads to. Por fim, a Figura 3.29 e a Figura 3.30 apresentam um exemplo de modelo de processo de negócio construído utilizando as metaclasses do metamodelo de processo de negócio do ARIS Method. Como pode ser observado na Figura 3.29, os elementos Cliente e Vendedor são, respectivamente, instâncias das metaclasses Position e Person Type, enquanto os elementos Solicitar Compra, Analisar Solicitação de Compra, Finalizar Comprar e Informar Cliente são instâncias da metaclasse Function. A Figura 3.30 mostrar que o elemento XOR é uma instância da metaclasse Rule e os elementos Necessidade de compra identificada, Pedido aprovado, Pedido não aprovado, Compra finalizada e Cliente informado são instâncias da metaclasse Event.

86 70 Figura 3.29 Mapeamento entre as entidades Participant e Function do metamodelo de processo de negócio e em suas instancias em um modelo de processo de negócio. Figura Mapeamento entre as entidades Rule e Event do metamodelo de processo de negócio e suas instâncias em um modelo de processo de negócio.

87 METAMODELO DA LINGUAGEM DE DETALHAMENTO DE ATIVIDADES O metamodelo da linguagem de detalhamento de atividades é composto pelas seguintes metaclasses: Participation, Employee Variable, Function, Information Carrier, Cluster, Technical Term, Application e Business Rule. No metamodelo de detalhamento de atividade os elementos Participant e Function possuem os mesmos relacionamentos apresentado na seção anterior. A Figura 3.31 e a Figura 3.32 apresentam fragmentos do metamodelo da linguagem de detalhamento de atividades do ARIS Method contendo os elementos Function, Technical Term e Cluster e seus relacionamentos. Todas as classes em cinza na Figura 3.31 são classes abstratas. A classe abstrata Information é utilizada apenas para estruturar o metamodelo e capturar as características gerais dos elementos generalizados.

88 72 Figura Fragmento do Metamodelo de Detalhamento de Atividade contendo Function, Cluster e Technical Term e seus relacionamentos. Figura Fragmento do Metamodelo de Detalhamento de Atividade contendo Cluster, Participant, User e seus relacionamentos

89 73 O ARIS Method possui uma linguagem de modelagem conceitual de dados chamada de eerm (Extended Entity-Relationship Model). Um dos principais elementos dessa linguagem é o Entity Type, que segundo (DAVIS, 2001), representa as entidades do mundo real (por exemplo: consumidores, empregados e pessoas). Na linguagem de detalhamento de atividades, o elemento Cluster é utilizado para representar uma coleção de Entity Types como, por exemplo, pessoas e os seus compromissos (DAVIS, 2001). A Figura 3.33 apresenta o símbolo do elemento Cluster. Cluster Figura 3.33 Símbolo do elemento Cluster. O elemento Technical Term representa conceitos que existem na organização e tem por objetivo descrever objetos de informação do negócio da organização. Segundo (DAVIS, 2001), esse elemento é usado para modelar informações do ponto de vista da perspectiva dos negócios e o elemento Cluster é utilizado para a modelagem das informações do ponto de vista de dados. A Figura 3.34 apresenta o símbolo do elemento Technical Term. Technical term Figura 3.34 Símbolo do elemento Technical Term. Os relacionamentos entre o elemento Function e o elemento Information, apresentados na Figura 3.31, possuem as seguintes semânticas: i. has output of: uma atividade tem zero ou mais informações com saída; ii. reads: uma atividade lê zero ou mais informações; iii. archives: uma atividade guarda (arquiva) zero ou mais informações; iv. creates: uma atividade gera zero ou mais informações; v. distributes: uma atividade distribui zero ou mais informações;

90 74 vi. deletes: uma atividade exclui zero ou mais informações; vii. changes: uma atividade modifica zero ou mais informações; viii. is input for: uma informação é entrada para zero ou mais atividades; ix. is checked by: uma informação é verificada por zero ou mais atividades; x. is approved by: uma informação é aprovada zero ou mais atividades; Os relacionamentos is owner of e accesses entre os elementos Organizational Unit, Organizational Unit Type, Position, Person, Group, Location e Person Type com o elemento Information representam, respectivamente, que os elementos organizacionais são donos da informação e que os elementos organizacionais acessam as informações. O relacionamento is specimen owner of entre Organizational Unit e Cluster representa que uma ou mais unidades organizacionais são os proprietários de um Cluster. O elemento Information Carrier representa um meio de armazenamento de informação. De acordo com (DAVIS, 2001), dados e informações estão sempre armazenados em algum lugar. Por exemplo, as informações da organização estão armazenadas em um arquivo de computador, formulários, arquivos, relatório de negócios ou em outros meios que possam armazenar informação. A Figura 3.35 apresenta o símbolo do elemento Information Carrier. Information carrier Figura 3.35 Símbolo do elemento Information Carrier.

91 75 A Tabela 3.3 apresenta alguns elementos notacionais do elemento Information Carrier. Tabela 3.3 Elementos notacionais do Information Carrier. Elemento notacional Símbolo Document Document Eletronic Document Electronic document File File Os relacionamentos provides e is used by que ocorrem entre os elementos Person Type, Position, Group e Organizational Unit com os elementos Cluster e Information Carrier representam, respectivamente, que tais elementos organizacionais fornecem o cluster e os meios de armazenamento; e que os clusters e os meios de armazenamento são usados por tais elementos organizacionais. A Figura 3.36 apresenta um Fragmento do metamodelo de detalhamento de atividade com foco no elemento Information Carrier. Na Figura 3.36 somente as classes User, Information e Application são classes abstratas, os demais elementos são elementos notacionais.

92 76 Figura 3.36 Fragmento do metamodelo de detalhamento de atividade com foco no elemento Information Carrier. O relacionamento lies on que ocorre entre Information e Information Carrier representa que as informações estão armazenadas em um portador de informação. O relacionamento provides input for entre Information Carrier e Function representa que um ou mais portadores de informação proveem informações para uma ou mais atividades. O relacionamento reads entre Information Carrier e Function representa que uma ou mais atividades leem informações que estão contidas em um ou mais portadores de informação. O relacionamento creates output to entre Information Carrier e Function representa que uma ou mais atividades criam informações para serem armazenadas em um ou mais elementos portadores de informação. A Figura 3.37 apresenta um Fragmento do metamodelo de detalhamento de atividades com foco nos elementos Application System, Application System Type e Application System Class.As classes em cinza na Figura 3.37 são abstratas.

93 77 Figura 3.37 Fragmento do metamodelo de detalhamento de atividades com foco nos elementos Application System, Application System Type e Application System Class. Os elementos Organizational Unit Type e Person Type possuem o relacionamento chamado can be user com o elemento Application System. Esse relacionamento indica que esses elementos organizacionais podem ser usuários de sistemas computacionais. Os elementos Person, Position, Organizational Unit e Group possuem o relacionamento is user com o elemento Application System. Esse relacionamento monstra que este subconjunto do metamodelo organizacional é usuário de sistemas computacionais. Os elementos Organizational Unit Type, Person Type, Person, Position, Organizational Unit e Group possuem os seguintes relacionamentos com os elementos Application System, Application System Type e Application Class: i. is responsible for development of: os elementos do metamodelo organizacional listados acima são responsáveis pelo desenvolvimento de um ou mais Application System, Application System Type ou Application Class; ii. is technically responsible for: os elementos do metamodelo organizacional listados acima são tecnicamente responsáveis por um ou mais Application System, Application System Type ou Application Class;

94 78 O relacionamento provides input for entre o elemento Information Carrier e os elementos Application System, Application System Type e Application Class representa que um ou mais portadores de informação proveem informações para um ou mais elementos do conjunto de sistema de informação. O relacionamento creates output to entre o elemento Information Carrier e os elementos Application System, Application System Type e Application Class representa que um ou mais sistemas de informação produzem informações que são armazenadas em um ou mais portadores de informação. O relacionamento uses entre Application System, Application System Type e Application Class e Information representa que os sistemas computacionais utilizam as informações contidas nos Cluster e nos Technical Terms para algum processamento. O relacionamento can use entre Application System Type e Information é utilizado para especificar quais tipos de informação que um tipo de sistema computacional pode utilizar para o processamento. Infelizmente a documentação on-line da ferramenta, (SCHEER, 1999) e (DAVIS, 2001) não apresentam a semântica para o elemento Business Rule. Business rule Figura 3.38 Símbolo do elemento Business Rule. A Figura 3.39 apresenta um fragmento do metamodelo de detalhamento de atividades com foco no elemento Business Rule e Function. Figura 3.39 Fragmento do metamodelo de detalhamento de atividades apresentado o relacionamento do elemento Business rule.

95 79 O relacionamento describes entre Business Rule e Function representa que uma ou mais atividades são descritas por uma ou mais regras de negócio da organização. Por fim, a Figura 3.40 apresenta uma instância do Diagrama de Detalhamento de atividades construído com os elementos Position (Vendedor), Function (Analisar solicitação de compra), Application System (Sistema de cadastro de cliente), Cluster (Informação da solicitação de compra, Pedido aprovado e Pedido não aprovado) e Information Carrier (Solicitação de compra). Figura Mapeamento entre as entidades do metamodelo de Detalhamento de Atividades e suas instâncias em um modelo de detalhamento de atividades. 3.5 ARIS OBJECT Todas as metaclasses de cada metamodelo de linguagem de domínio do ARIS Method apresentadas neste capítulo são extensões da metaclasse abstrata ARISObject. A Figura 3.41 apresenta um fragmento do elemento ARISObject contendo apenas os atributos Name (representando o nome do objeto) e Description (representando a descrição do objeto) (PIUMBINI, 2009).

96 80 Figura 3.41 Fragmento do elemento ARIS Object e o Elemento Assignments. O ARIS permite que um elemento de modelagem esteja relacionado a um ou mais modelos. Por exemplo, é possível associar a um mesmo elemento Function um modelo de processo de negócio (EPC) e um modelo de detalhamento de atividades (FAD). Desta forma, o ARIS Method permite descrever os diversos níveis de abstração e refinamento entre os modelos de processo. Para representar o relacionamento entre um elemento de modelagem e um modelo foi criada a metaclasse Assigment (Figura 3.41). O atributo linkedmodels dessa metaclasse representa o identificador do modelo associado dentro do ARIS Toolset (PIUMBINI, 2009). 3.6 DISCUSSÃO SOBRE ELEMENTOS NOTACIONAIS NO ARIS METHOD No ARIS Method os elementos notacionais são utilizados como uma forma de adaptar um elemento de modelagem mudando apenas a sua aparência (sintaxe concreta). Por exemplo, o ARIS Method permite ao modelador mudar a aparência de um elemento do tipo Organizational Unit Type para Position Type. O mecanismo é usado de forma extensa até mesmo em filtros pré-definidos na ferramenta ARIS Toolset. O principal problema da abordagem é que o mecanismo é usado, introduzindo modificações significativas na semântica dos elementos originais. Como ilustrado na Figura 3.42, o elemento Position Type é considerado um elemento notacional do elemento Organizational Unit Type.

97 81 Figura 3.42 Fragmento do Metamodelo Organizacional. De forma sucinta, os elementos notacionais no ARIS Method são uma forma que os projetistas das linguagens encontraram de adicionar elementos semânticos nas linguagens sem precisar modificar os metamodelos dessts. No entanto, isso pode acarretar problemas na linguagem como no caso do Position Type e Organizational Unit Type onde o modelador pode usar entidades com semânticas diferentes em um mesmo objeto. Para solucionar o problema supracitado é necessário fazer um reengenharia dos metamodelos das linguagens de modelagem de domínio. Tal reengenharia transformará os elementos notacionais que causam problemas na linguagem em elementos semânticos do metamodelo. Em termos de sintaxe abstrata, consideramos aqui um elemento notacional do ARIS como uma especialização de metaclasses existentes, sem introduzir novos atributos e relacionamentos. 3.7 DISCUSSÃO SOBRE OS METAMODELOS DE DOMÍNIO DO ARIS METHOD Os metamodelos apresentados neste capítulo retratam a real implementação das linguagens de modelagem utilizadas no ARIS Toolset. É importante ressaltar que foi realizada apenas uma refatoração nos metamodelos para torná-los mais legíveis, sem acrescentar elementos na sintaxe abstrata como suportada pela ferramenta. Adicionalmente, neste ponto do trabalho, não foram propostas modificações para possíveis inconsistências e/ou irregularidades na sintaxe abstrata. Um exemplo desse tipo de inconsistência pode ser observado no metamodelo da linguagem organizacional que considera o elemento Position Type como uma

98 82 especialização de Organizational Unit Type, porém não considera o elemento Position como uma especialização de Organizational Unit, conforme mostrado na Figura 3.5. Além disso, foram preservados elementos com semântica indefinida para uma posterior análise. Por exemplo, foi preservado o relacionamento performs entre os elementos Location e Person Type, o que daria uma impressão que uma localização pode executar um papel organizacional (vide Figura 3.11). Podemos ainda observar que os metamodelos apresentados neste capítulo são pouco restritivos sobre os elementos de modelagem, permitindo a construção de modelos com semântica indefinida. Por exemplo, o relacionamento assigments permite relacionar qualquer elemento com outro elemento ou modelo. No entanto, esse elemento de modelagem não possui semântica definida. Esta característica do metamodelo foi preservada para refletir adequadamente as linguagens do ARIS Method como suportadas pelas ferramentas. Um dos princípios básicos da abordagem de Desenvolvimento Orientada a Modelos proposta neste trabalho é o conhecimento completo das linguagens de modelagem utilizadas. Logo, será necessário analisar e resolver as inconsistências das linguagens de modelagem do ARIS Method para a construção de um dialeto que permita expressar descrições arquiteturais sem ambiguidade ou inconsistências. Para atingir este objetivo, o Capítulo 4 apresenta uma análise ontológica de cada elemento do metamodelo, identificando de forma sistemática as inconsistências das linguagens de modelagem e propondo soluções para os problemas identificados. 3.8 CONCLUSÃO Os metamodelos apresentados neste capítulo descrevem as metaclasses e os elementos notacionais das linguagens organizacional, de processo de negócio e de detalhamento de atividades do ARIS Method. Através dos metamodelos apresentados neste capítulo torna-se viável a construção de ferramentas de modelagem, simulação e análise de modelos de processos de negócio usando técnicas de desenvolvimento orientado a modelos (do inglês, Model-Driven Design).

99 83 Torna-se também viável a construção de ferramentas que implementem transformações entre linguagens distintas sem a necessidade de realizar transformações em nível de documento, como é o caso da transformação XSLT apresentada em (MENDLING e NÜTTGEN, 2004) (MENDLING e NÜTTGEN, 2004) para a conversão de EPCs do ARIS para EPML (EPC Markup Language) (MENDLING e NÜTTGEN, 2004) (MENDLING e NÜTTGEN, 2004). Com o uso de metamodelos, a manipulação de modelos é feita em um nível mais alto de abstração, sem recorrer ao nível de documento. Apesar dos metamodelos de domínio do ARIS Method serem acompanhados de texto para apresentar informalmente a semântica das linguagens, será necessária uma avaliação rigorosa dessas semântica. A avaliação também deve ser capaz de identificar elementos inadequados nas linguagens de modelagem de domínio e propor melhorias na linguagem. Esta avaliação será realizada no Capítulo 4 e será conduzida com base em ontologias de fundamentação. A avaliação ontológica das linguagens permitirá ainda melhorar o conhecimento dos elementos das linguagens de domínio organizacional e de processo de negócio, facilitando assim a criação de transformações de Desenvolvimento Orientado a Modelos corretas e completas.

100 84 CAPÍTULO 4 ARIS METHOD ANÁLISE ONTOLÓGICADAS LINGUAGENS DO 4.1 INTRODUÇÃO Este capítulo apresenta a análise ontológica dos metamodelos das linguagens organizacional, de processo de negócio e de detalhamento de atividades do ARIS Method que foram apresentados no Capítulo 3. Através da análise ontológica será possível definir, de forma, rigorosa a semântica dos elementos dos metamodelos do ARIS Method em termos de entidades do mundo real. Para isto serão utilizados as ontologias de fundamentação UFO-A, UFO-B e UFO-C ( seção 2.3). Além disto, a análise ontológica permitirá identificar elementos de modelagem inadequados de cada domínio. Esta identificação será feita através de uma série de critérios sistemáticos de avaliação revelando a clareza, expressividade, completude, parcimônia, lucidez, correção e consistência das linguagens de modelagem (GUIZZARDI et al., 2005a), levando à definição de recomendações de melhoria bem fundamentadas. Para realizar e organizar a análise ontológica das linguagens de domínio organizacional, de processos de negócio e de detalhamento de atividades do ARIS Method, foi necessário o desenvolvimento de uma abordagem sistemática, descrita na seção 4.2. Essa seção apresenta os passos utilizados para a análise ontológica e os conceitos utilizados para a mesma. Ao fim de cada análise ontológica, é apresenta um dialeto bem formado da respectiva linguagem analisada. Em outras palavras, ao fim da análise ontológica será apresentando um conjunto mínimo de construtores de cada linguagem, que permita expressar de forma adequada e sem ambiguidade uma determinada conceituação. Os dialetos desenvolvidos nesse capítulo serão utilizado como base para a produção dos modelos arquiteturais deste trabalho. Além disso, a abodagem de Desenvolvimento

101 85 Orientado a Modelos apresentado no Capítulo 5 utiliza os dialetos produzidos neste capítulo como linguagens bem-formadas, ou seja, linguagem sem problemas ontológicos. As seções 4.3, 4.5 e 4.7 apresentam, respectivamente, as análises ontológicas dos metamodelos da linguagem organizacional, de processos de negócios e de detalhamento de atividade e as seções 4.4, 4.6 e 4.8 apresetam os dialetos da linguagem organizacional, de processo de negócio e de detalhamenro de atividade, respectivamente. Por fim, a seção 4.8 apresenta as conclusões do capítulo. 4.2 ABORDAGEM DE ANÁLISE ONTOLÓGICA A abordagem de análise ontológica proposta neste trabalho tem por objetivo: (i) interpretar os elementos das linguagens de modelagem em termos de entidades da uma ontologia de fundamentação; (ii) identificar possíveis problemas nas linguagem de modelagem; e (iii) propor soluções para os problemas das linguagens de modelagem. A abordagem é aplicada para cada metaclasse e metarelacionamento presente nos metamodelos de domínio organizacional, de processo de negócio e de detalhamento de atividades do ARIS Method. A Figura 4.1 apresenta a estrutura da abordagem proposta. Figura 4.1 Abordagem da avaliação ontológica. A abordagem é composta das seguintes etapas:

102 86 i. Analisar a semântica do elemento e seus relacionamentos: nesta etapa é realizada uma busca na literatura com o objetivo de encontrar a semântica dos elementos e relacionamentos contidos nos metamodelos. ii. Buscar interpretação ontológica: nesta etapa busca-se uma interpretação ontológica para os conceitos representados pelo elemento do metamodelo selecionado e seus relacionamentos. A interpretação ontológica será feita utilizando a semântica das entidades presentes na UFO-A, UFO-B ou UFO-C. iii. Verificar problemas ontológicos no elemento: nesta etapa, verifica-se se o elemento do metamodelo selecionado possui algum problema ontológico que possa afetar a clareza, a expressividade, a completude, a parcimônia ou a lucidez da linguagem. Para essa etapa, será necessário utilizar um framework de avaliação de linguagens de modelagem como apresentado em (GUIZZARDI et al., 2005a). O framework de avaliação de linguagens irá utilizar as informações da interpretação ontológica (realizada pela segunda etapa) e as informações da semântica do elemento fornecida pelo ARIS (realizada pela primeira etapa) para verificar se há problemas ontológicos no elemento selecionado que afetam a linguagem. iv. Corrigir problemas ontológicos no elemento: caso a terceira etapa encontre algum problema ontológico no elemento selecionado, a quarta etapa busca sugerir modificações na linguagem que corrijam os problemas encontrados. Ao fim da abordagem o elemento avaliado possui uma interpretação ontológica e, caso exista um problema na linguagem que envolva o elemento analisado, são apresentados os problemas da linguagem e as possíveis soluções para os mesmos.

103 ANÁLISE ONTOLÓGICA DO METAMODELO ORGANIZACIONAL Para realizar a análise ontológica dos elementos do metamodelo organizacional será utilizada a semântica das metaclasses e dos metarelacionamentos apresentados na seção 3.2 e outros os conceitos da socias discutidos na seção Conceitos Sociais complemantares a UFO-C Essa seção apresenta outros conceitos sociais que auxiliarão na análise ontológica do modelo organizacional do ARIS. Esse conceitos complementam os conceitos apresentados na UFO-C. Como apresentado na seção , uma Normative Description pode criar normas que são reconhecidas por uma ou mais entidades sociais. Essas normas podem ser utilizadas para criar novas entidades sociais, controlar o comportamento de entidades sociais e até mesmo para descrever como uma determinada atividade organizacional deve ser desempenhada. De acordo com (BOTTAZI e FERRARIO, 2006), as normas são dividas nos seguintes tipos: i. Constitutive Norm: norma responsável por criar novos conceitos, papéis e indivíduos sociais na organização. Este tipo de norma também pode descrever, por exemplo, quais são os requisitos para que uma pessoa assuma um papel social ou quais os requisitos que definem qual o papel é superior a outro; ii. Deontic Norm: norma responsável por regular o comportamento social das entidades, ou seja, este tipo de norma define as permissões, obrigações, direitos e regras de comportamento social dos agentes quando assumem um papel social reconhecido pela organização; iii. Technical Norms: norma responsável por descrever qual o procedimento correto para que alguma atividade organizacional seja realizada. As Technical Norms têm o propósito de sugerir o comportamento social de certos papéis sociais da organização ao desempenharem alguma atividade na organização

104 88 De acordo com (BOTTAZI e FERRARIO, 2006), todos os conceitos e papéis sociais criados por uma norma do tipo Constitutive Norm são ditos válidos ou reconhecidos (recognized by) no contexto da organização. Segundo (BOTTAZI e FERRARIO, 2006), um conceito ou um papel social só é reconhecido pela organização quando a norma responsável por criar estes elementos é reconhecida pela organização, ou seja, o papel é reconhecido (is institutionalized by) pela organização. Segundo (BOTTAZI e FERRARIO, 2006), além dos papéis sociais e normas as Normative Descriptions também definem Social Relator Universals. Os papéis são sempre definidos em um contexto ou dentro do escopo de uma relação. Assim, para que Paulo (Particular) instancie um papel social (por exemplo, estudante), ele precisa ser mediado por um Particular Relator (por exemplo, a inscrição na universidade de ensino). O Relator Universal Inscrição, neste caso, define as propriedades que todas as instâncias de estudante possuem no contexto deste relacionamento (ou, equivalentemente, quando instancia o papel). Do mesmo modo, para que um Particular z assuma um papel social (Social Role) na estrutura de um Institutional Agent x, o Particular z deve ser mediado por uma instância de um Social Relator Universal definido em uma Normative Description N associada a X. Um exemplo de Normative Description responsável por definir Social Role e Social Relator é o Social Contract (Contrato Social) (DIGNUM, 2004). De acordo com (DIGNUM, 2004), um contrato social descreve atividades, regras e obrigações específicas que estão associadas a um papel social da organização como: (i) limite de tempo que um determinado membro pode assumir um papel, (ii) acordos específicos entre a organização e o membro que assume um papel na organização; (iii) condições de governança, ou seja, como a organização pode governar o agente que está querendo assumir um papel social e vice-versa; (iv) além de definir sanções ao agente quando as normas são violadas. Logo, o Social Contract é utilizado para explicitar a expectativa de comportamento de um ou mais agentes (Human Agent, por exemplo) ao assumirem um papel social dentro de uma organização (DIGNUM, 2004).

105 89 O Social Contract é constituído de Norms. Através destas normas a organização especifica e limita o comportamento social de um agente ao assumir um papel social dentro do contexto organizacional. Os membros da organização podem possuir mais de um contrato social e mais de um papel social dentro da organização (DIGNUM, 2004). O Social Contract prove um relacionamento (Social Relator) entre os agentes e os papéis sociais presentes na organização. O ato de assinar um Social Contract é um declarative speech act que serve como foundation para a criação de um Social Relator que liga as partes envolvidas. Quando o agente assina um Social Contract está declarando de forma explícita que aceita todos as condições organizacionais contidas no contrato social. Um agente é admitido em uma organização através de um processo de socialização (DIGNUM, 2004). Neste processo as partes negociam os termos e condições da participação do agente na organização utilizando Social Contracts. Cada agente irá negociar a sua participação na organização e acordar a duração de sua participação, recursos e como será comunicação entre este agente e os demais agentes já pertencentes a organização, por exemplo. Segundo (DIGNUM, 2004), existe um relacionamento chamdo affiliate entre o agente e a organização indicando que ambos aceitaram as condições descritas no Social Contract, e assim, assumiu um papel social reconhecido pela organização e tornou-se parte da organização. Vale ressaltar, que não são apenas agentes humanos (Human Agents) e outras organizações (Institutional Agent) que podem tornar-se membros de uma organização através do processo de socialização Análise Ontológica dos Elementos Position, Organizational Unit, Organizational Unit Type Antes da análise ontológica dos elementos Position, Organizational Unit e Organizational Unit Type, será necessário interpretar o relacionamento is of type, que ocorre entre esses elementos, como mostrado nas Figura 3.1e Figura 3.5. O relacionamento is of type (tradução: é do tipo) é interpretado como o relacionamento chamado instanciação (instantiation) da UFO-A. O relacionamento de instanciação é

106 90 um relacionamento formal (Relation Formal) que ocorre entre um Universal e um Particular e possui a seguinte semântica: quando dizemos que p é uma instância de U, estamos querendo representar que p tem a propriedade de ser um U (GUIZZARDI, 2005a). Logo, o relacionamento is of type é utilizado para expressar que um determinado elemento do metamodelo assume as propriedades de outro elemento do metamodelo. Por exemplo, as instâncias de Position e Organizational Unit irão assumir propriedades de um determinado Organizational Unit Type. Analisando a semântica do elemento Organizational Unit, pode-se interpretá-lo como a entidade ontológica Institutional Agent presente na UFO-C (seções ), pois ambos representam o conceito social de organização (instituição). Levando em consideração a interpretação do relacionamento is of type entre Organizational Unit e Organizational Unit Type (vide Figura 3.1) e a interpretação do elemento Organizational Unit, pode-se interpretar o elemento Organizational Unit Type como um Institutional Agent Universal. O elemento Position é definido como a menor unidade organizacional. Caso esse conceito seja interpretado literalmente e seja utilizada a interpretação do relacionamento is of type entre esse elemento e Organizational Unit Type, seria possível interpretar o elemento Position como um Institutional Agent. A Figura 4.2 apresenta as interpretações dos elementos Organizational Unit, Organizational Unit Type e Position e a interpretação do relacionamento is of type em relação a entidades e relacionamentos presentes na UFO-A e UFO-C. O relacionamento pontilhado com o estereótipo <<represents>> indica que um determinado elemento ou relacionamento do ARIS Method foi interpretado (representa) como uma entidade ou relacionamento da UFO-A, UFO-B ou UFO-C. Vale ressaltar que na parte superior do diagrama temos elementos conceituais da ontologia de fundamentação UFO e que na parte inferior temos elementos linguísticos do ARIS Method.

107 91 Figura Interpretação dos elementos Organizational Unit Type, Organizational Unit e Position seguindo os conceitos do ARIS Method Problemas Ontológicos na Interpretação do Elemento Position Segundo o ARIS o elemento position é a menor unidade organizacional dentro de uma organização, ou seja, este não pode ser decomposto em outras partes menores. Outra característica desse elemento é que somente o tipo Person pode instanciá-lo este elemento. Esta última afirmação pode ser comprovada através do relacionamento occupies entre Position e Person, apresentado na Figura 4.3. Figura Fragmento do metamodelo organizacional com os elementos Position e Person. O relacionamento occupies possui a mesma interpretação do relacionamento is of type, ou seja, o relacionamento occupies é interpretado como um relacionamento de instanciação. Sendo o elemento Position indivisível, pode-se considerá-lo como o todo que é composto por somente uma parte. Em outras palavras, o elemento Position representa uma unidade organizacional (Institutional Agent) que é composta por somente uma pessoa, caracterizando assim uma quebra do princípio de suplementação fraca (do

108 92 inglês, weak supplementation) (GUIZZARDI, 2005a) e também um problema na interpretação ontológica, afinal um agente institucional é formado por partes. O princípio de suplementação fraca expressa que o todo não pode ser constituído de apenas uma parte, porque, neste caso, a parte é todo. O todo deve ser constituído de pelo menos duas partes disjuntas. Este conceito está fortemente atrelado ao conceito de agente institucional, como pode ser observado na Figura 4.4, onde é demonstrado que um Institutional Agent é composto de pelo menos dois agentes. Figura Fragmento da UFO-C contendo Institutional Agent, Human Agent e Artificial Agent (GUIZZARDI et al., 2007). Devido aos problemas ontológicos na interpretação do elemento Position é necessária uma nova interpretação para esse elemento, com o objetivo de corrigir tais problemas Nova Interpretação para o Elemento Position Propomos que o elemento Position seja interpretado com um papel social (Social Role) desempenhado, somente, por uma pessoa (Agente Humano (Human Agent)). Em outras palavras, o elemento Position é um Social Role que possui um relacionamento de instanciação (instantiation) somente com agentes do tipo Agente Humano (como sugerido pelo metamodelo organizacional do ARIS Method através do relacionamento occupies entre Person e Position apresentado na Figura 4.3). A Figura 4.5 apresenta a nova interpretação para o elemento Position.

109 93 A semântica do relacionamento occupies é que uma pessoa pode ocupar (ser associada) a uma ou mais posições em uma organização. Em outras palavras, o relacionamento occupies representa que quando uma instância de Person assume (ocupa) uma Position, uma pessoa assume todos os comportamentos sociais que estão associados ao Position. Desta forma, o relacionamento occupies é interpretado como um instantiation presente na UFO-A. Figura Nova interpretação do elemento Position. Com a nova interpretação do elemento Position, o problema de suplementação fraca foi eliminado, pois um Position não é mais interpretado como uma entidade ontológica formada por partes funcionais. Através da nova interpretação (Social Role) o elemento Position adquire propriedades que não existiam na interpretação antiga (Institutional Agent) como: (i) Social Moments, que regulam o comportamento social da pessoa que instanciar o Position; e (ii) existe um contrato social (Social Contract) que estabelece um relacionamento social (Social Relator) entre a instância de Person que assume o Position (Social Role) com a organização na qual o Social Role pertence; entre outras característica associadas ao Social Role. Neste trabalho é assumido que o elemento Position é um papel social (Social Role) e não uma unidade organizacional (Organization Unit).

110 Análise Ontológica do Position Type Como pode ser observado na Figura 4.6, o elemento Position Type é um elemento notacional e assim, não possui semântica definida pelo ARIS Method. Para formular a semântica do elemento Position Type foram consideradas as semânticas do elemento Organizational Unit Type e do elemento Position. Assim, pode-se concluir que o elemento Position Type é uma tipificação das menores unidades organizacionais (Position) que possuem características em comum. Figura Fragmento do Metamodelo Organizacional contendo somente Position Type, Organizational Unit Type e Position Assumindo o conceito apresentado acima para o elemento Position Type, a nova interpretação do elemento Position e a interpretação do relacionamento is of type, podese interpretar o elemento Position Type como um dos seguintes elementos ontológicos: (i) Social Role, (ii) Social Role Mixin ou (iii) High Order Universal (HOU). Ao interpretar o Position Type como um Social Role, determinaríamos que o elemento Position Type possui a mesma interpretação que o elemento Position, ou seja, o elemento Position Type é um papel social que é instanciado apenas por agentes humanos. Desta forma, é identificado um problema de construção em excesso na linguagem, pois teremos dois elementos distintos com a mesma interpretação ontológica. Para resolver tal problema de acordo com essa interpretação, seria necessário retirar o elemento Position Type do metamodelo organizacional. A segunda interpretação considera o elemento Position Type como um Social Role Mixin. Com essa interpretação, o elemento Position é uma especialização do elemento

111 95 Position Type, e assim, o elemento Position herdaria os Social Moments do Position Type. O relacionamento de especialização seria feito pelo relacionamento is of type. Para exemplificar, imagine o Position Type Cliente e os Positions Pessoa Física e Pessoa Jurídica. Ambos os Positions são especializações de Position Type. Cada um dos Positions possui os Social Moments do Position Type. A Figura 4.7 apresenta a interpretação do elemento Position Type como um Social Role Mixin. Figura Interpretação do elemento Position Type como um Social Role Mixin. A terceira, e última, interpretação do elemento Position Type considera este elemento como um HOU, ou seja, todas as instâncias desse elemento são Universais, o que torna essa interpretação bastante plausível, pois as instâncias do elemento Position Type seriam Position que também são universais (Social Role). A instanciação será feita pelo relacionamento is of type que ocorre de forma indireta no fragmento do metamodelo apresentado na Figura 4.6. A Figura 4.8 apresenta a interpretação do elemento Position Type com um HOU. Figura Interpretação do Position Type como um High Order Universal. Para exemplificar a terceira interpretação, vamos considerar o HOU Tipo de Docente. Este elemento pode ter uma instância chamada Docente de ensino superior (Social Role) e, este último pode ser instanciado em Docente do Departamento de Informática da UFES pelo João Paulo (Person), por exemplo.

112 96 Este trabalho utiliza a primeira interpretação do elemento Position Type, ou seja, considera que o elemento Position Type é um Social Role e, desta forma, não é necessário para a linguagem organizacional do ARIS Method Interpretação de Person Segundo a documentação on-line da ferramenta de modelagem, o elemento Person representa uma pessoa que está associada a uma unidade organizacional. Esta associação expressa que a pessoa é um membro da organização e que assume um posição dentro dela, reconhecida por ambos. A associação de uma pessoa a uma posição (Position) define qual o status dela na organização, as funções e as responsabilidades dentro da organização. Os conceitos apresentados acima são capturados pelo relacionamento belongs to entre Person e Organizational Unit e pelo relacionamento occupies entre Person e Position, no fragmento do metamodelo organizacional apresentado pela Figura 4.9. Figura Fragmento do metamodelo organizacional contendo alguns relacionamentos do elemento Person, Position, Organizational Unit e Organizational Unit Type. O relacionamento belongs to entre Person e Organizational Unit representa que uma pessoa pertence a uma unidade organizacional, ou seja, que uma pessoa faz parte de uma unidade organizacional. Dessa forma, este relacionamento pode ser interpretado

113 97 como um relacionamento semelhante ao relacionamento affiliate que ocorre entre as entidades Agentes e Agentes Institucionais, como discutido na seção É dito que uma pessoa faz parte de uma organização quando ela assina um contrato social (Social Contract) com uma organização e assume (occupies) um papel social (Position no caso do ARIS e Social Role na UFO-C) dentro de uma unidade organizacional. Por fim, analisando a semântica do elemento Person e as interpretações dos elementos Position, Organizational Unit e Organizational Unit Type é possível interpretar o elemento Person como um Agente Humano (Human Agent). A Figura 4.5 apresenta a interpretação do elemento Person e dos relacionamentos occupies e belongs to. A interpretação que o elemento Person é um Human Agent é o assumido nesse trabalho. O relacionamento occupies que ocorre entre Person e Position foi definido e interpretado na seção Com a nova interpretação do elemento Position, o relacionamento is of type que ocorre entre esse elemento e o elemento Organizational Unit Type torna-se desnecessário. Logo, tal relacionamento não está presente no dialeto da linguagem organizacional proposto neste trabalho. O relacionamento is composed of entre Organizational Unit e Position representa uma composição funcional entre uma unidade organizacional e uma ou mais Positions, ou seja, através deste relacionamento o ARIS representa quais os papéis sociais que são as partes funcionais e essenciais de uma unidade organizacional. Desta forma, este relacionamento será interpretado com o relacionamento todo-parte chamado Component-Functional Complex. A Figura 4.10 apresenta um exemplo do relacionamento is composed of.

114 98 Tipo de Departamento is of type Departamento de Informática da UFES is composed of Docente occupies João Paulo Giancarlo Ricardo Falbo Figura Exemplo do relacionamento is composed of. Na Figura 4.10 o relacionamento is composed of é o responsável por estabelecer relação funcional entre uma unidade organizacional (Departamento de Informática da UFES), seus papéis sociais (Docentes) e um relacionamento entre a unidade organizacional e as pessoas (João Paulo, Giancarlo e Ricardo Falbo) que instanciam os papéis sociais reconhecidos pela organização. Os relacionamentos e autorrelacionamentos is disciplinary superior to, is technical superior to e is superior to representam, respectivamente, que uma determinada entidade é superior disciplinarmente a outra entidade; que uma determinada entidade é superior tecnicamente a outra entidade e; que uma entidade é superior hierarquicamente que a outra entidade. Infelizmente não é possível definir o significado da expressão a entidade X é superior tecnicamente ou disciplinarmente do que a entidade Y, mas é possível definir o que é superioridade hierárquica pela seguinte definição (DIGNUM, 2004): Um relacionamento de superioridade hierárquica é um relacionamento de coordenação, onde o elemento denominado superior hierarquicamente pode delegar tarefas, obrigações ou objetivos para um elemento denominado inferior hierárquico (em relação ao elemento

115 99 que delegou a tarefa, obrigação ou objetivo) e este executa o que foi lhe pedido. Pela definição de (DIGNUM, 2004) pode-se assumir que uma ou mais unidade organizacionais podem ser superiores hierarquicamente a um ou mais Positions e viceversa. Não será feita a distinção entre os relacionamentos is disciplinary superior to, is technical superior to e superior to. Ambos, serão considerados relacionamentos de hierarquia definidos em (DIGNUM, 2004). Os relacionamentos is disciplinary superior to e is technical superior to e o autorrelacionamento is superior to são interpretados como uma relação material (Material Relation) da UFO-A, ou seja, existe um relator (Social Relator) que une as entidades envolvidas nesse relacionamento e esse relator também descreve quais as propriedades sociais (Social Moments) adquiridas pelas entidades ao realizar o relacionamento. Para exemplificar os relacionamentos de superioridade hierárquica, no contexto organizacional pode existir um objeto social (Social Object) que descreve que a unidade de Recursos Humanos é superior à unidade de Produção ou que a posição de Gerente de Recursos Humanos (instância de Position) é superior à unidade de Recursos Humanos. O relacionamento belongs to entre Organizational Unit e Person (Organizational Unit belongs to Person) representa que uma organização pertence a uma pessoa, expressando a idéia de posse ou que uma pessoa é o responsável legal pela organização. Em outras palavras, através desse relacionamento o ARIS representa que uma pessoa (Person) assume um papel social (Social Role), que é reconhecido no contexto interno e externo à organização, que lhe dá responsabilidades, direitos, deveres, obrigações e outras propriedades (Social Moments) perante o ambiente interno e externo da unidade organizacional. Desta forma, esse relacionamento pode ser interpretado como um relacionamento material (Material Relation), pois é necessário um relator (um contrato social) para associar a unidade organizacional e a pessoa.

116 100 Através do relacionamento belongs to entre Organizational Unit e Person é possível expressar, por exemplo, que Paulo é o responsável legal da empresa X, ou que o Presidente Luiz Inácio Lula da Silva é o responsável legal pela República Federativa do Brasil perante o povo brasileiro e as entidades internacionais, conforme apresentado na Figura Presidente País occupies is of type Luiz Inácio Lula da Silva belongs to Brasil Figura Exemplo de utilização do relacionamento belongs to. Como pode ser observado na Figura 4.11, quando o Luiz Inácio assume o papel social de Presidente da Republica, ele assume todas as propriedades socais deste papel, sendo que uma delas é ser o responsável legal pela República Federativa do Brasil. O relacionamento belongs to entre Person e Organizational Unit (Person belongs to Organizational Unit) representa que uma pessoa (Person) faz parte de uma ou mais unidades organizacionais. Através desse relacionamento, o ARIS Method tenta expressar que uma pessoa assinou um contrato social com a organização e assumiu uma posição (Position) dentro de uma ou mais unidades organizacionais. Desta forma, esse relacionamento é interpretado com uma Relação Material (Material Relation), ou seja, existe um contrato social para unir as partes envolvidas e descrever as propriedades sociais que ambas receberam nesse relacionamento. Através do relacionamento belongs to é possível expressar que existe uma ligação entre uma pessoa e uma unidade organizacional através do papel que a pessoa assume nessa unidade organizacional. O relacionamento is organization manager for representa que uma entidade é gerenciada por outra entidade. Da mesma forma que os outros relacionamentos, a escavação não conseguiu encontrar o significado desse relacionamento. Desta forma, não há interpretação formal para o relacionamento acima. Para permitir a análise,

117 101 assumimos a definição de coordenação definida em (DIGNUM, 2004), apresentada anteriormente, que foi utilizada para definir os relacionamentos is disciplinary superior to, is technical superior to e superior to. Logo, o relacionamento is organization manager for é interpretado como um relacionamento material, pois é necessário um relator para unir as entidades envolvidas e definir as propriedades de gerenciamento das entidades envolvidas. Através do relacionamento is organization manager for é possível expressar, por exemplo, que situações como Paulo é gerenciado pelo João Paulo, Os Analista de Processo (Position) são gerenciados pelo Escritório de Processo (Organizational Unit) e O gerente coordena Pedro, Evellin e Ariane. A Figura 4.12apresenta a interpretação do relacionamento is organization manager. Gerente is organization manager for Analista de Processo occupies occupies João Paulo Ariane Evellin Pedro Figura Exemplo do relacionamento is organization manager for. Como apresentado na Figura 4.12, através do relacionamento is organization manager for que ocorre, neste caso, entre papéis sociais que um relacionamento de superioridade hierárquica. Em outras palavras, existe um Social Moment descrito em uma Normative Description que define que o papel social Gerente é superior hierarquicamente ao papel social Analista de Processo. Sendo assim, todas as pessoas que instanciarem esses papéis irão assumir esse Social Moment. O relacionamento substitutes for representa que uma entidade pode ser substituída por uma ou mais entidades, ou seja, através desse relacionamento é possível expressar que Paulo, que assume o papel social (Position) de Analista de Sistema, foi substituído por João, por exemplo. Desta forma, o relacionamento substitutes for é uma relação formal. O autorrelacionamento is component of do elemento Organizational Unit representa uma composição funcional entre unidades organizacionais, ou seja, através desse relacionamento o ARIS representa quais as unidades organizacionais que são as partes

118 102 funcionais e essenciais de outra unidade organizacional. Desta forma, esse relacionamento é interpretado como o relacionamento todo-parte chamado Component-Functional Complex. Assim, esse relacionamento permite expressar, por exemplo, que os estados brasileiros compõem a República Federativa do Brasil. O autorrelacionamento is responsible for do elemento Organizational Unit representa que uma unidade organizacional é a responsável legal por uma ou mais unidades organizacionais. Em outras palavras, esse relacionamento expressa de forma implícita que uma unidade organizacional assume um papel social de ser responsável por uma ou mais unidades organizacionais da organização. Logo, o relacionamento is responsible for é interpretado com um relacionamento material. Através desse relacionamento é possível expressar, por exemplo, que o Centro Tecnologico da UFES é o responsável pelo Departamento de Informática da UFES e pelo Departamento de Engenharia Elétrica da UFES. Os relacionamentos can be disciplinary superior e can be technical superior do elemento Organizational Unit Type especificam quais as unidades organizacionais poderão ser consideradas superiores disciplinarmente e superiores tecnicamente. Esses relacionamentos receberam a mesma interpretação dos relacionamentos is disciplinary superior e is technical superior. Vale ressaltar que os relacionamentos can be disciplinary superior e can be technical superior (Figura 3.1) estão no nível de tipo e não no nível de instância como os relacionamentos is disciplinary superior e is technical superior (Figura 3.5). Por fim, o autorrelacionamento can be constituent do elemento Organizational Unit Type, especifica quais os tipos de unidades organizacionais que podem compor um outro tipo de unidade organizacional. Assim, esse relacionamento é interpretado como um Component-Functional Complex no nível de tipo Análise Ontológica do Elemento Person Type O elemento Person Type é uma tipificação de um conjunto de pessoas que possuem as mesmas características: responsabilidades, direitos, obrigações entre outras. A relação is

119 103 of type entre Person e Person Type no metamodelo tende a reforçar esta definição, como mostrado na Figura A seção 3.2 apresenta detalhes sobre os elementos Person e Person Type. Tendo como base que o elemento Person foi interpretado como um Human Agent e a existência do relacionamento is of type entre este elemento e o elemento Person Type é possível interpretar, que este último, como um Human Agent Universal. Se estendermos a análise ontológica para os demais relacionamentos do Person Type (por exemplo, peforms e belongs to) é possível identificar o problema de sobrecarga semântica 2 nesse elemento, afetando, desta forma, a interpretação que o Person Type representa um Human Agent Universal e até mesmo a interpretação do elemento Person. Para mostrar o problema de sobrecarga de semântica do elemento Person Type é necessário realizar a análise ontológica dos relacionamentos peforms e belongs to que ocorrem entre o elemento Person Type e alguns elementos do Metamodelo Organizacional. Figura 4.13 Fragmento do metamodelo contendo os relacionamentos do elemento Person Type. O relacionamento performs representa que uma determinada entidade executa um Person Type. Desta forma, esse relacionamento é interpretado como um relacionamento 2 A sobrecarga semântica ocorre quando uma simples construção da gramática da linguagem é utilizada para representar duas ou mais entidades ontológicas (GUIZZARDI, 2005a).

120 104 de instanciação (instantiation) presente na UFO-A. A Figura 4.14 apresenta um exemplo de modelo organizacional com o relacionamento perfoms. Através do relacionamento performs, o elemento Position está assumindo todas as propriedades do elemento Person Type. Person type performs Position Figura 4.14 Exemplo de relacionamento performs. O relacionamento belongs to representa que um Person Type pertence a uma unidade organizacional (Organizational Unit) ou a um grupo (Group). Desta forma, este relacionamento é interpretado como o relacionamento is institutionalized by/ recognized by (BOTTAZI, 2006) que ocorre entre unidades organizacionais e papéis sociais (Social Role). A Figura 4.15 apresenta um exemplo de relacionamento belongs to entre um Person Type X e uma unidade organizacional Y, representando que o Person Type X é reconhecido pela unidade organizacional Y e pertence à mesma. Organizational unit Y belongs to Person type X Figura 4.15 Exemplo de relacionamento belongs to entre Person Type e Organizational Unit. Assumindo somente as interpretações dos relacionamentos belongs to e perfoms, é possível interpretar o elemento Person Type com um Social Role Mixin, pois o elemento Person Type possui características de Social Role da UFO-C; e através do relacionamento performs, o elemento Person Type pode ser instanciado por diversos elementos distintos do metamodelo organizacional (Organizational Unit, Organizational

121 105 Unit Type, Position, Location, Person e Group), desta forma caracterizando a sua propriedade de Mixin. O problema de sobrecarga semântica do elemento Person Type pode ser comprovado, pois esse possui duas interpretações ontológicas: Human Agent Universal (através do relacionamento is of type com o elemento Person) e Social Role Mixin (através do relacionamento perfoms e belongs to). Infelizmente, o problema de sobrecarga de construtor do elemento Person Type não é o único encontrado nesse elemento. Ao analisar o autorrelacionamento is composed of deste elemento, foi encontrado um problema de construtor em excesso. O problema de construtor em excesso ocorre, porque não foi encontrado nenhuma interpretação para esse relacionamento na UFO-A, na UFO-B, na UFO-C e em outros trabalhos (BOTTAZI e FERRARIO, 2006) (DIGNUM, 2004) que descreva que um Human Agent Universal ou um Social Role Mixin possam ser compostos de outros elementos do mesmo tipo. Desta forma, esse relacionamento explicita um problema de construtor em excesso no elemento Person Type. Para sanar os problemas de sobrecarga semântica e construtor em excesso do elemento Person Type são propostas as seguintes soluções: (i) interpretar o elemento Person Type com um Social Role Mixin; (ii) criar um novo elemento no ARIS Method para simbolizar o Human Agent Universal (chamado Person Universal, por exemplo), e assim, transferir o relacionamento is of type que ocorre entre Person Type e Person para este novo elemento, ou seja, existiria um relacionamento Person is of type Person Universal; e (iii) retirar o relacionamento is composed of do elemento Person Type. As soluções (i) e (ii) têm por objetivo sanar o problema de sobrecarga semântica e a solução (iii) visa resolver o problema de construtor em excesso do elemento Person Type. A Figura 4.16 apresenta a interpretação do elemento Person Type como um Social Role Mixin. Com a definição que o elemento Person Type representa um Social Role Mixin, é possível realizar a interpretação ontológica dos demais relacionamentos desse elemento.

122 106 Este trabalho assume que o elemento Person Type representa um Social Role Mixin. Assim, o relacionamento is of type entre Person Type e Person não é necessário no dialeto da linguagem organizacional. O relacionamento can belongs to entre Person Type e Organizational Unit Type representa uma especificação de quais tipos de papéis sociais podem pertencer a um tipo de unidade organizacional. Desta forma, esse relacionamento é interpretado com um Component-Functional Complex no nível de tipo. A interpretação do relacionamento is organization manager for foi apresentada na seção O relacionamento belongs to entre os elementos Group e Person Type (Figura 4.13) representa que um ou mais papéis sociais são reconhecidos pela organização como os responsáveis legais por um ou mais grupos. Desta forma, esse relacionamento é interpretado como um relacionamento material, pois é necessário um relator (um contrato social) para colar Group a um papel social. Para exemplificar, esse relacionamento possibilita expressar, que o papel social Coordenador de TI é responsável pelo grupo que realiza as auditorias internas na empresa X. Figura 4.16 Interpretação do elemento Person Type e dos relacionamentos performs e belongs to.

123 107 O relacionamento occupies entre Person Type e Position recebe a mesma interpretação do relacionamento de mesmo nome apresentado na seção No caso de Person Type, o relacionamento occupies é utilizado para representar que um determinado Person Type pode instanciar um determinado Position na organização. O autorrelacionamento is generalization of representa que um determinado papel social possui um conjunto de Social Moments que está presente em um ou mais papéis sociais (Person Type), ou seja, esse relacionamento indica que um determinado papel social é generalização de outro papel social. Desta forma, o relacionamento is generalization of é interpretado como um relacionamento de generalização presente na UFO-A. Através do autorrelacionamento is generalization of é possível expressar que o papel social Analista financeiro possui propriedades que são herdados pelo papel social Contador financeiro. Assim, o papel social Analista financeiro é a generalização do papel Contador financeiro. Em outras palavras, todas as instâncias do papel social Contador financeiro serão instâncias do papel social Analista financeiro e, portanto, as instâncias de Contador financeiro exibem as características do papel social Analista financeiro. O autorrelacionamento is composed of representa que um papel social é omposto de um ou mais papéis sociais. Ou seja, através desse relacionamento o ARIS Method tenta expressar que um determinado papel social pode ser composto de Social Moments que pertencem a outros papéis sociais da organização. A UFO não apresenta uma relação (ou até mesmo conceitos) que descreva que um papel social é composto de social moments presentes em outros. Porém, é valido descrever que um papel social é composto de social moments de outros papéis social como, por exemplo, o papel social Analista de Processo possui características (social moments) que pertencem ao papel social Analista de Domínio e Modelador de Processo, por exemplo. Isto é, o papel social Analista de processo é composto de social moments que pertencem aos papéis sociais Analista de Domínio e Modelador de Processo. De forma, singular é possível interpretar o relacionamento is composed of como um relacionamento formal (Formal Relator).

124 108 Para finalizar, o relacionamento is in conflict with descreve que um papel social pode estar em conflito com outro papel social da organização, ou seja, que os objetivos de um papel social estão em conflito com os objetivos de outros papéis sociais da organização. Assim, uma mesma entidade (pessoa ou unidade organizacional, por exemplo) não pode desempenhar os dois papéis sociais, com objetivos conflitantes, simultaneamente. O relacionamento is in conflict with é um relacionamento formal Análise Ontológica do Position Description Segundo a documentação on-line da ferramenta ARIS Toolset, o elemento notacional Position Description é utilizado para descrever as responsabilidades e deveres de um Position dentro de uma organização. Caso seja utilizada apenas a semântica apresentada acima (sem analisar do Metamodelo Organizacional), o elemento Position Description é interpretado como uma Deontic Norm (BOTTAZI e FERRARIO, 2006). Em outras palavras, o elemento Position Description representa um documento organizacional utilizado para descrever o comportamento social de um Position. Utilizando a semântica proposta pela documentação on-line, a interpretação do elemento Person Type e o fragmento do metamodelo organizacional apresentado na Figura 4.17, é possível concluir que a interpretação que o elemento Position Description representa a entidade ontológica Deontic Norm é incorreta. Tal conclusão é possível, porque teríamos no nível ontológico um Social Object (Position Description) sendo a especialização de um Social Role Mixin (Person Type) e isso não é válido na UFO. Figura 4.17 Fragmento do Metamodelo Organizacional com elemento Person Type e Position Description Como o elemento Person Type foi interpretado como um Social Role Mixin, pode-se concluir que o elemento Position Description representa, pelo menos, um Social Role ou um Social Role Mixin. Ao analisar novamente a semântica do elemento Position

125 109 Description e levando em consideração a hipótese que este elemento é um Role, conclui que o elemento Position Description é utilizado para representar papéis sociais (Social Role) que são instanciados por pessoas (Person). Assim, quando uma pessoa (Person) instanciar o elemento Position Description, a mesma assume todas as responsabilidades e deveres associados ao papel instanciado. A instanciação é feita através do relacionamento performs, herdado do elemento Person Type. A Figura 4.18 apresenta a interpretação do elemento Position Description. Um exemplo do conceito apresentado no parágrafo anterior é que podem existir no nível de processo os papéis sociais Cliente Juridico e Cliente Físico representados, respectivamente, pelos elementos Person Type e Position Description. O Cliente pode ser instanciado por uma pessoa (Person) ou uma unidade organização (Organizational Unit), enquanto o Cliente Físico somente pode ser instanciado por uma pessoa (Person). Figura Interpretação do elemento Position Description. Não há diferenças ontológicas entre os elementos Position e Position Description. Ambos representam papéis sociais (Social Role) instanciados por pessoas (Human Agent). A diferença entre esses elemento é no uso. De acordo com Scheer (ARIS, 1999, p. 57), existem papéis sociais que estão associados diretamente ao nível organizacional, outros papéis sociais que estão associados ao nível de processo de negócio. Desta forma, o elemento Position Description está ligado somente ao nível de Processo de negócio e não está associado à estrutura organizacional. A seção

126 110 apresenta uma discussão mais detalhada sobre esse conceito. Logo, ele pode ser removido da organização e, consequentemente, do processo de negócio sem grandes impactos na estrutura organizacional. Por fim, este trabalho assume que o elemento Position Description representa um papel social (Social Role) Análise Ontológica do Elemento Group O elemento Group representa um conjunto de empregados (Person) que estão trabalhando juntos por um período de tempo específico. No entanto, somente a semântica do elemento Group não é suficiente para realizar a análise ontológica desse elemento. Portanto, é necessário utilizar a semântica dos relacionamentos do elemento Group com os demais elementos do Metamodelo Organizacional para realizar a análise ontológica do elemento. A Figura 3.13 apresenta um fragmento do metamodelo organizacional com foco no elemento Group e seus relacionamentos. A primeira interpretação do relacionamento is position of é que este é utilizado para indicar que uma ou mais posições (Position) fazem parte de um grupo. Essas posições são papéis sociais (Social Role) que são reconhecidos pela organização (ou organizações) de que o grupo faz parte ou somente pelo grupo. Esse relacionamento é utilizado no nível de instância. Através deste relacionamento é possível expressar, por exemplo, que o papel social Pesquisador do NEMO é um position do grupo NEMO. O relacionamento is composed of pode representar que um ou mais grupos são compostos de posições (Position). Da mesma forma que o relacionamento is position of, todas as posições associadas ao grupo são reconhecidas pela organização (ou organizações) que o grupo faz parte (consequentemente, pelo grupo) ou somente pelo grupo. Porém, esse relacionamento é utilizado no nível de tipos, ou seja, é utilizado para especificar quais os tipos de posições compõem um grupo (Group). O relacionamento is composed of permite expressar que o universal Grupo de Pesquisa é composto de papéis sociais do tipo Pesquisadores

127 111 Logo, os relacionamentos is position of, e is composed são interpretados como o relacionamento Component-Functional Complex. Sendo o primeiro utilizado no nível de instância (Particular) e o último no nível de tipo (Universal). Outra interpretação possível para os relacionamentos is position of, e is composed é que ambos sejam utilizados para representar que uma determinada posição que é parte de um grupo, sem realizar a distinção entre nível de tipo e nível de instância. Caso essa interpretação seja levada em consideração, é caracterizado um problema de construção em excesso 3 na linguagem. Caso contrário, é caracterizado um problema de sobrecarga semântica, pois o elemento Group está representando ao mesmo tempo um Universal e um Particular. O relacionamento has member representa que uma pessoa é membro de um grupo. Uma pessoa torna-se membro de um grupo através da posição que ela ocupa dentro do grupo. Através deste relacionamento é possível expressar, por exemplo, que Paulo Sérgio é membro do grupo de Pesquisa NEMO através do papel social Pesquisador que é reconhecido pelo grupo. Outra interpretação para o relacionamento has member é que este seja utilizado para expressar quais os tipos de pessoas que podem assumir os papéis sociais reconhecidos pelo grupo. Assim, o relacionamento has member é um relacionamento utilizado no nível de instância e no nível de tipo, caracterizando, novamente, um problema de sobrecarga semântica no elemento Group. Em ambas as interpretações o relacionamento has member é interpretado como um Material Relation, pois é necessário um Relator para unir as duas partes. O relacionamento perfoms representa que um grupo instancia um determinado papel na organização, ou seja, o grupo como um todo instancia um determinado papel social em algum processo da organização. Por exemplo, um grupo chamado de Grupo de validação (composto de diversos agentes e papéis sociais) pode desempenhar o papel 3 O problema de construtor em excesso ocorre quando existe uma construção gramatical que não pode ser interpretada como nenhuma construção ontológica.

128 112 social de Validador de alguma etapa do processo de negócio da empresa. O relacionamento perfoms é interpretado como uma instantiation da UFO-A. O relacionamento is assigned to representa que um grupo está associado a uma ou mais unidades organizacionais, ou seja, esse relacionamento descreve que, de alguma forma, o grupo está associado à organização. Este relacionamento também pode ser utilizado para expressar que o grupo é reconhecido pela organização. Por exemplo, através desse relacionamento é possível expressar que uma determinada ONG é reconhecida pelo Brasil ou que o grupo de pesquisa NEMO está associado ao Departamento de Informática da UFES. O reconhecimento do grupo pela organização é feito através de uma Normative Description. Desta forma, interpretamos que este relacionamento é interpretado com um Material Relation. O relacionamento is managed by que ocorre entre os elementos Group e Person representa que um ou mais grupos são gerenciados por uma ou mais pessoas. Por exemplo, através desse relacionamento é possível expressar que o grupo de pesquisa NEMO é gerenciado por João Paulo, Giancarlo e Ricardo Falbo. Vale lembrar que este relacionamento representa de forma indireta que o elemento Person está associado a um Position e este último possui Social Moments que o permite gerenciar o grupo (Group). Desta forma, concluímos que o relacionamento is managed by é interpretado como um Material Relation, pois existe um Social Relator que une o Group, Position e Person. O relacionamento belongs to que ocorre entre os elementos Group e Person Type representa que um ou mais papéis sociais são os responsáveis pelo grupo. Assim este relacionamento possui a interpretação semelhante do relacionamento belongs to que ocorre entre Person e Organizational Unit. O autorrelacionamento cooperates with representa que dois ou mais grupos trabalham juntos para que um ou mais objetivos sejam alcançados. Esse objetivo pode ser comum a todos os grupos ou pertencente a apenas um dos grupos. Em ambos os casos, os grupos trabalham juntos porque sozinhos não conseguiriam alcançar os objetivos. Desta forma, existe um social relator (criado por uma Normative Description) que define as propriedades desse relacionamento e como os objetivos serão alcançados. Logo, esse

129 113 relacionamento é interpretado como uma relação material. Através do relacionamento cooperates with, é possível expressar que o grupo de pesquisa NEMO trabalha em cooperação com outro grupo chamado LPRM, por exemplo. Utilizando as interpretações dos relacionamentos interpretados acima, a semântica apresentada para o elemento Group pelo ARIS Method e a definição de grupo dado por (DIGNUM, 2004), o elemento Group pode ser interpretado como um Collective Social Agent ou como um Institucional Agent. A diferença de interpretação dependerá do uso do elemento Group. A Figura 4.19 apresenta a interpretação do elemento Group do ARIS Method em relação aos elementos da UFO-C. A interpretação do elemento Group como um Collective Social Agent ocorre quando a instância do elemento Group é utilizado para representar uma coleção (Collection) de Social Agent do mesmo tipo como, por exemplo, um grupo formado apenas por Human Agent ou um grupo formado por apenas pessoas que assumem o papel de gerente da organização. Figura Interpretação do elemento Group. A interpretação do elemento Group como um Institutional Agent ocorre quando a instância do elemento Group possui características de Function Complex, ou seja, quando as partes possuem um relacionamento funcional com o grupo. Em outras

130 114 palavras, todos os integrantes do grupo contribuem para o funcionamento e comportamento do grupo. Quando o elemento Group se comporta como um Institutional Agent assume todas as propriedades desse tipo de agente como, por exemplo, o elemento Group pode possuir uma Normative Description, pode ser sub-divida em unidade menores (chamado de sub-grupos) e entre outras características inerentes ao agentes institucionais 4. Por fim, para solucionar o problema de sobrecarga semântica do elemento Group, é necessário criar um novo elemento na linguagem que represente o Group no nível de tipos (Universal) ou criar um elemento na linguagem que Group no nível de instância (Particular). Ambos as semânticas do elemento Group serão asumidas no dialeto da linguagem organizacional Análise Ontológica do Elemento Location O elemento Location representa uma localização geográfica de uma unidade organizacional, de um papel social (Position e Person Type), etc. Porém, somente essa informação não é suficiente para a análise ontológica do elemento Location, é necessário analisar os relacionamentos que esse elemento possui com os demais elementos. A Figura 3.11 apresenta um fragmento do metamodelo organizacional com foco no elemento Location e em seus relacionamentos. Os relacionamentos is located at e at location são utilizados para representar em qual região geográfica o elemento organizacional está localizado. Pode-se dizer que é através desse relacionamento que as entidades organizacionais recebem o valor da sua localização geográfica. O autorrelacionamento encompasses é utilizado para representar que uma determinada região geográfica pode englobar outras regiões geográficas, por exemplo: podemos 4 O ARIS não permite expressar que um grupo é constituído de sub-grupos.

131 115 representar a localização Brasil como o conjunto de todas as posições geográficas dos estados brasileiros. A partir do conceito apresentado pelo ARIS Method para o elemento Location e a semântica dos relacionamentos supracitados é possível interpretar o elemento Location como um Quale de um Quality Domain de localizações. Essa é a interpretação assumida neste trabalho. Sendo o elemento Location um Quale, o relacionamento encompasses é interpretado como o relacionamento member of entre as entidades ontológicas Quale e Quale Structure na UFO-A. Através do relacionamento encompasses, o ARIS Method cria uma Quality Structure utilizando os Qualia (elemento Location) que pertencem a um Quality Domain de Localizações. O relacionamento at location e o relacionamento is location at são interpretados como sendo o relacionamento quale of que ocorre entre as entidades Quality e Quale. A Figura 4.20 apresenta a interpretação do elemento Location e dos relacionamentos is located at, at location e encompasses.

132 116 Figura Interpretação do Location e dos relacionamentos at location, is located at e encompasses. Como apresentado na Figura 3.11, o elemento Location apresenta um relacionamento chamado de performs com o elemento Person Type e o relacionamento is organization manager for com os elementos Person e Position que podem induzir que o elemento Location seja interpretado (erroneamente) como um Institutional Agent. Logo, existe um problema de sobrecarga semântica, ou seja, que o elemento Location está sendo utilizado para mais de uma construção ontológica. O relacionamento performs indica que o Location instancia um Person Type, neste caso, o elemento Location não representa uma coordenada geográfica e sim uma unidade organizacional como, por exemplo, uma planta de fábrica pode assumir o papel de responsável da produção de um determinado produto da organização. Desta forma, pode-se concluir o elemento Location pode ser interpretado como um Institutional Agent. Como descrito na seção 4.3, o elemento Organizational Unit foi interpretado como um Institutional Agent sendo desnecessário que o Location também seja interpretado

133 117 como essa entidade da UFO-C, porque, caso os dois elementos do ARIS sejam interpretados para a mesma entidade da UFO-C, teríamos um problema de construtor em excesso. Sendo assim, propomos a retirada do relacionamento performs entre Location e Person Type para evitar o problema de construtor em excesso e a não interpretação do elemento Location como um Institutional Agent para resolver o problema de sobrecarga semântica. Por fim, o relacionamento is organization manager for indica que uma pessoa (Person) e uma posição (Position) podem ser gerenciados por uma determinada localização. Porém, esta interpretação indica que o elemento Location novamente está sendo interpretado como uma unidade organizacional, por exemplo, Paulo is organization manager for Vitória, onde Vitória é uma unidade organizacional. Tomando como base esta interpretação, o elemento Location novamente é interpretado como um Institutional Agent quando for necessário realizar este relacionamento. Desta forma, encontramos o mesmo problema de sobrecarga de construtor que ocorreu no relacionamento performs entre Location e Person Type. Sendo assim, propomos a retirada do relacionamento is organization manager for entre Person e Position com o elemento Location para evitar o problema de sobrecarga de construtor. Esses relacionamentos não serão considerados no dialeto organizacional. Neste trabalho não assumidmos que o elemento Location representa uma unidade organizacional. Desta forma, os seguintes relacionamentos não serão considerados no dialeto organizacional: (i) is organization manager for entre Person e Location; (ii) performs com o elemento Person Type; e (iii) o relacionamento is organization manager for com os elementos Person e Position Discussão sobre as diferenças entre papéis no nível organizacional e no nível de processo de negócio. A análise ontológica do Metamodelo Organizacional identificou que os elementos Position, Person Type e Position Description são utilizados para representar papéis sociais (Social Role) que são reconhecidos na organização. Do ponto de vista ontológico, retirando as particularidades, tais elementos do ARIS Method são idênticos, ou seja, ambos são interpretados como Social Roles que são instanciados por agentes.

134 118 De acordo com Scheer (1999, p. 57), alguns papéis sociais estão associados, somente, no nível de processo de negócio. Alguns papéis sociais, entretanto, são raramente associados ao nível de processo de negócio, pois caso esses papéis deixem de existir, será necessário atualizar o processo de negócio. Este trabalho acredita que o elemento Position é utilizado para representar papéis sociais que estão ligados diretamente no nível organizacional e que são raramente alocados no nível de processo. O elemento Position é utilizado para representar postos de trabalhos que as pessoas assumem ao entrar em uma organização. Por outro lado, os elementos Person Type e Position Description são papéis sociais que estão associados diretamente ao nível de Processo de Negócio. A eliminação de algum papel social que seja representando por um desses dois elementos não acarreta em impactos graves na estrutura organizacional (SCHEER, 1999). Sample Co. Inc Organization Unit Sales Billing Position Secretary Sales Sales manager Sales Clerk Billing Clerk 1 Billing Clerk 2 Person Pegi Stevies Troy Bennedit Tammy Carvielli Mike Beakley Tom Cummins Person Type/ Position Description Secretary Sales Clerk Billing Clerk Figura 4.21 Fragmento de um modelo organizacional apresentado em (SCHEER, 1999, p. 187). A Figura 4.21 apresenta um fragmento do modelo organizacional retirado de (ARIS, 1999). Nesse modelo, é possível observar que o elemento Position (Secretary Sales, Sales Manager, Sales Clerk, Billing Clerk 1 e Billing Clerk 2) é utilizado para representar os papéis sociais que estão associados diretamente à estrutura organizacional, enquanto os elementos Person Type e Position Description (Billing Clerk) estão associados ao nível de processo de negócio.

135 119 Pode-se concluir que o elemento Position refere-se aos cargos assumidos quando uma pessoa (Person) entra na organização (através do processo de socialização) e o elemento Person Type são os papéis sociais que a pessoa assume na execução de uma ou mais atividades organizacionais que estão presente nos diversos processos de negócio da organização. 4.4 DIALETO DA LINGUAGEM ORGANIZACIONAL DO ARIS METHOD A seção 4.3 apresentou a análise ontológica dos elementos e relacionamentos presente no metamodelo organizacional da linguagem ARIS Method apresentado no Capítulo 3. A seção 4.3, também, apresentou a semântica para cada elemento e relacionamento que está presente no dialeto organizacional. A Figura 4.22 apresenta um fragmento do dialeto da linguagem organizacional do ARIS Method. Figura 4.22 Fragmento do dialeto da linguagem organizacional do ARIS Method. A Tabela 4.1 apresenta os elementos presentes no dialeto da linguagem organizacional do ARIS Method. Somente o elemento Position Type não está presente no dialeto da linguagem organizacional do ARIS Method. Tabela 4.1 Elementos presente no dialeto organizacional. Elemento do ARIS Method Elemento da UFO Descrição Organization Unit Institutional Agent Unidade Organizacional

136 120 Organization Unit Type Position Institutional Agent Universal Social Role Tipo de Unidade Organizacional Papel Social instanciados por elementos do tipo Person Person Human Agent Agentes do tipo humano Person Type Social Role Mixin Papel Social que pode ser instanciado pelos seguintes elementos: Organizational Unit, Organizational Unit Type, Position, Person e Group Papel social que uma determinada Position Social Role posição (Position) assume no Description processo de negócio. Location Quale Localização geográfica. Grupo funcional que é composto por Institutional Agent Group diversas papeis sociais. Collective Social Agent Coleção de papéis sociais. A Tabela 4.2 apresenta os relacionamentos que não estão presenta no dialeto organizacional. Tabela 4.2 Relacionamentos eleminados da linguagem organizacional. Relacionamento Elemento de Origem Elemento de Destino Is of type Position Person Organization Unit Type Person Type Performs Location Person Type Organization Manager for Location Person Position 4.5 ANÁLISE ONTOLÓGICA DO METAMODELO DA LINGUAGEM DE PROCESSO DE NEGÓCIO De acordo com (SHARP e MCDERMOTT, 2000) e (OUYANG et al., 2008) um processo de negócio pode ser definido como uma ordem parcial de tarefas de trabalho inter-relacionadas, iniciadas em resposta a um ou vários eventos, que visa alcançar algum objetivo organizacional. Um processo de negócio pode ser interpretado como uma Complex Action Universal da UFO-C, ou seja, uma especificação de um conjunto de atividades relacionadas, que estão sob a responsabilidade de um ou mais agentes.

137 121 Para realizar a análise ontológica dos elementos do metamodelo de processo de negócio, a etapa Analisar semântica do elemento e seus relacionamentos tomou como base a semântica desses elementos na seção 3.3. Também foi utilizada a interpretação ontológica dos elementos organizacionais, apresentada na seção Análise ontológica do Elemento Function O elemento Function é responsável por descrever atividades que são desempenhadas na organização por um ou mais participantes (pessoas ou aplicativos computacionais), com a finalidade de atingir um ou mais objetivos organizacionais. Isso pode ser comprovado na Figura 4.23 através do relacionamento carries out entre Participant e Function. Outra característica importante do elemento Function é que ele possui vários níveis de abstração e refinamento, ou seja, o elemento Function pode representar uma atividade de alto nível de abstração que é refinada em outras atividades de menor nível de granularidade (SCHEER, 1999). Através da semântica do elemento Function é possível interpretá-lo como uma (i) Atomic Action Universal, (ii) Complex Action Universal ou (iii) Interaction Universal. Figura 4.23 Fragmento do Metamodelo de Processo de Negócio com os relacionamento entre Particpant e Function.

138 122 A interpretação do elemento Function como um Atomic Action Universal ocorre quando o elemento Function representa uma ação atômica (não possui refinamentos) e é executada por somente um agente (Participant). A interpretação do elemento Function como um Complex Action Universal ocorre quando o elemento Function representa uma ação não-atômica, composta de dois ou mais Actions Universal, e é executada por somente um agente (Participant). A interpretação do elemento Function como Interaction Universal ocorre quando o elemento Function representa uma Complex Action que é executada por dois ou mais agentes. A Figura 4.24 apresenta a interpretação ontológica do elemento Function. Figura Interpretação ontológica do elemento Function. Devido às diferentes interpretações ontológicas do elemento Function, é possível identificar um problema de incompletude 5 na linguagem, i.e., existem entidades na ontologia de referência que não são representadas na linguagem. Desta forma, há uma sobrecarga semântica no elemento Function, gerando, assim, o problema de não-lucidez na linguagem de modelagem. Uma possível solução para esse problema é a criação de novos elementos notacionais que representem as diferenças ontológicas do elemento Function. A existência de um relacionamento carries out entre um Participant p e uma Function f indica que um agente participará intencionalmente da atividade organizacional representada por f. Em outras palavras, existe um compromisso social (Social 5 Uma linguagem é dita incompleta quando falta expressividade, ou seja, que existem fenômenos do domínio da linguagem, que não podem ser expressos pela linguagem (GUIZZARDI, 2005a).

139 123 Commitment) por parte do agente com a organização, no qual, o agente se compromete em ser responsável pela execução e conclusão da atividade organizacional. Esse agente contribuirá para a atividade organizacional representada por f intencionalmente através de uma Action Contribution. O relacionamento contributes to entre um Participant p e uma Function f indica que um agente a contribui intencionalmente para a conclusão de uma atividade organizacional representada por f. Ou seja, o agente a possui um compromisso social (Social Commitment) de auxiliar na execução e conclusão da atividade organizacional f, porém não possui nenhuma responsabilidade social com a organização para a conclusão da atividade organizacional f. Dependendo da metaclasse que especializa p nos relacionamentos carries out e contributes to, o agente será uma instância do universal representado por p (nos casos de Position, Person Type, Position Description, Organizational Unit Type) ou será o próprio agente (Person, Organizational Unit, Group). Os relacionamentos must be informed about, must be informed on cancellation e must be informed about result of são interpretados como Interações (Interaction) que são realizadas entre dois agentes. Neste caso, objetos são sistemas computacionais que não possuem características de agentes artificiais (Artificial Agent). O autorrelacionamento is predecessor of do elemento Function representa um relacionamento temporal entre duas ou mais atividades do processo de negócio, ou seja, esse relacionamento define que, para que uma ou mais atividades sejam executadas, é necessário que a atividade antecessora a essas tenha sido concluída. Esse relacionamento também descreve que uma atividade produz um pré-estado (Situation) de uma atividade sucessora a essa. O relacionamento is predecessor of é interpretado como uma Time Relation da UFO-B, mais especificamente, uma relação before relation ou uma relação meets relation. Conforme apresentado na análise ontológica do metamodelo organizacional do ARIS Method (seção 4.3), o elemento Location representa uma localização geográfica, sendo assim, não pode ser responsável pela conclusão de uma atividade de processo de

140 124 negócio. Logo, o relacionamento is carried out entre Location e Function não é valido e, portanto, não será interpretado. Esse relacionamento não está presente no dialeto da linguagem de processo de negócio. Infelizmente não foi possível definir uma semântica clara dos demais relacionamentos entre Function e Participant. Desta forma, esses relacionamentos não form interpretados à luz da UFO e, assim, não estão no dialeto da linguagem de processo de negócio. De maneira geral, é possível interpretar o elemento Function como uma Action da UFO Interpretação do Elemento Event O elemento Event é utilizado de duas formas distintas em EPC: para representar uma situação de interesse (informalmente, um estado de interesse) ou para representar uma ação arbitrária que influencia a execução do processo (informalmente um evento ). No primeiro caso, o elemento Event do ARIS Method deve ser interpretado como um Situation Universal. Durante a execução do processo, instâncias desse Universal serão os pré-estados (situações) que habilitam atividades organizacionais ou pós-estados (situações) que resultam destas. Como eventos no ARIS podem envolver uma descrição textual arbitrária, não há regras sobre que tipos de entidades podem estar presentes (present in) na situação. Um evento inicial é denotado pela ausência de atividades do processo que a antecedam (ou seja, não há Function relacionada através de creates com um evento inicial). Os eventos iniciais denotam, portanto, as situações que habilitam o processo como um todo. Atividades que habilitem essa situação não fazem parte do processo. Similarmente, um evento final é denotado pela ausência de atividades do processo que o sucedam. No segundo caso, o elemento Event do ARIS Method é utilizado para representar ocorrências eventos (intencionais ou não intencionais) que dependem de um Substantials. Por exemplo, o clicar de mouse ou mudança de temperatura. Desta forma, o elemento Event do ARIS Method é interpretado como um Event Universal da UFO. Como eventos no ARIS podem envolver uma descrição textual arbitrária, não há regras sobre que tipos de entidades podem participar do Event (ou seja, que tipos de

141 125 Participations são permitidas). A Figura 4.25 apresenta a interpretação do elemento Event do ARIS Method como Situation Universal e Event Universal. Figura 4.25 Interpretação do elemento Event. Para o uso do elemento Event do ARIS Method como um Situation Universal, o relacionamento activates representa que um ou mais eventos são pré-estados (prestate Situation) necessários para uma ou mais atividades. Em outras palavras, para que a atividade inicie sua execução, é necessário que a situação exista. O relacionamento creates entre Function e Event representa que uma ou mais atividades geram situações (pos-state da Function) que podem ser pré-estados para outras atividades do processo de negócio. Caso seja considerada a interpretação que o elemento Event do ARIS Method é um Event Universal, o relacionamento activates representa um relacionamento temporal, mais especificamente uma relação Before ou Meets entre os Events representados por Event e Function. Ou seja, este relacionamento define que, para que uma ou mais atividades sejam executadas, é necessário que os eventos antecessores a essas atividades tenham ocorrido. O relacionamento creates representa o inverso de activates (também uma relação entre Events). Devido às diferentes interpretações ontológicas, o elemento Event do ARIS Method apresenta o problema de sobrecarga semântica. Uma possível solução desse problema é a criação de novos elementos notacionais que representem as diferenças ontológicas do elemento Event. Outra recomendação possível é o uso exclusivo de Events para

142 126 representar estados (como sugerido por (DAVIS, 2001)). Desta forma, não há sobrecarga semântica. Este trabalho assume que o elemento Event do ARIS Method seja interpretado como um Event da UFO Análise Ontológica do Elemento Rule O conjunto de Rules presente em um processo de negócio especifica quais atividades devem ser executadas, tomando como base o estado das coisas (do inglês, state of affairs). O estado das coisas para o processo de negócio são os eventos internos (produzidos pelas atividades) e os eventos externos (produzidos por outros processos ou por outras entidades) ao processo de negócio. Através do elemento Rule é possível compor eventos complexos a partir da união de eventos internos do processo de negócio e/ou eventos externos ao processo de negócio. Esses eventos complexos podem ser pré-requisitos para que uma determinada atividade do processo ocorra. Por exemplo, o elemento notacional AND é utilizado para compor um evento complexo a partir de dois ou mais eventos do processo de negócio, que pode ser o pré-estado de uma ou mais atividade do processo de negócio. O autorrelacionamento Links do elemento Rule também pode ser utilizado para criar eventos complexos através de combinações de Rules. Diferentemente dos demais elementos do metamodelo de processo de negócio do ARIS Method, o elemento Rule não apresenta um interpretação direta para uma entidade ontológica da UFO. Isto ocorre, porque os Rule descrevem relações entre universais que restringem possíveis relações entre instâncias. Por exemplo, assumindo que o elemento Event represente uma Situation, temos as seguintes interpretações: (i) X, Y AND Z: significa que existe um Situation Universal W, tal que toda instância de Z tem como pré-situação uma instância w de W e toda instância de w é a soma mereológica de uma instância de X e uma instância de Y (ambas situações); (ii) X,Y OR Z: significa que toda instância de Z tem como pré-situação uma instância w tal que w é uma instância de X ou de Y ou a soma mereológica de ambas instâncias; e (iii) X,Y XOR Z é igual a (ii) com o requisito adicional de que X e Y sejam Situation Universals que são disjuntos.

143 Análise Ontológica do Application System, Application System Type e Application System Class O elemento Application System (Figura 3.16) representa um sistema computacional que auxiliam na execução do processo de negócio, por exemplo, o editor de texto instalado na máquina de um empregado da organização. Desta forma, o elemento Application System pode ser interpretado na UFO-C como duas entidades: (i) Object Particular ou (ii) um Agent Artificial Particular. A diferença de interpretação do elemento Application System é devido ao uso do elemento. A Figura 4.26 apresenta a interpretação do elemento Application System. Figura 4.26 Interpretação dos elementos Application System e Application System Type. A primeira interpretação ocorre quando o sistema computacional não possui características de agentes (desejos, crenças e intenções) como, por exemplo, o editor de texto instalado na máquina de um empregado da organização. Essa é a interpretação assumida neste trabalho e que é utilizada no dialeto da linguagem de processsos de negócio. A segunda interpretação ocorre quando o sistema computacional possui características de agentes como, por exemplo, um sistema orientado a agentes A que está em operação em um computador Z.

144 128 O elemento Application System Type representa uma tipificação de um sistema computacional (Application System). Em outras palavras, esse elemento representa o Universal que foi instanciado para criar um determinado Application System. Desta forma o elemento Application System Type é interpretado como um Object Universal ou como um Agent Artificial Universal. A Figura 4.26 apresenta a interpretação do elemento Application System Type. Este trabalho assume que o elemento Application System Type é um Object Universal. Como pode ser observado nessa figura, os elementos Application System e Application System Type possuem duas interpretações ontológicas, desta forma caracterizando um problema de sobrecarga semântica. Para corrigir este problema, é necessário criar mais um elemento no metamodelo que seja utilizado para indicar que um sistema é um objetivo ou um agente. Os elementos Application System e Application System Type também podem ser interpretados, respectivamente, como Resource Particular e Resource Universal da UFO-C quando representam objetos (Object Particular e Object Universal) que são utilizados pelas entidades organizacionais na execução de uma atividade (Function). Isso pode ser comprovado pela semântica dos relacionamentos can be user e is user entre os elementos organizacionais e o Application System e Application System Type. Esses relacionamentos nesse contexto são interpretados como Resource participation, mais especificamente, Usage e Usage Universal. O elemento Application System Class representa uma classificação realizada ao tipo de aplicações computacionais (Application System Type). Sendo que um mesmo tipo de aplicação computacional pode pertencer a mais de uma classificação de aplicações. Assim, o elemento Application System Class é interpretado como a entidade Category da UFO-A. Uma Category é um tipo de Mixin, que classifica as entidades que pertencem a tipos diferentes, mas que compartilham uma propriedade comum essencial (ou seja, uma propriedade que eles não podem perder) (GUIZZARDI, 2005a). A Figura 4.27 apresenta a interpretação do elemento Application System Class.

145 129 Figura 4.27 Interpretação do elemento Application System Class. O relacionamento supports entre Application System e Application System Type e o elemento Function é interpretado ontologicamente de duas maneiras distintas. Caso os elementos Application System e Application System Type sejam interpretados, respectivamente, como Object Particular e Object Universal, o relacionamento supports é interpretado como um Resource Participation, mais especificamente, Usage e Usage Universal. A segunda interpretação do relacionamento supports leva em consideração que os elementos Application System e Application System Type são interpretados como Artificial Agent e Artificial Agent Universal. Desta forma, tal relacionamento é interpretado como Action Contribution. O elemento Application System Class também possui o relacionamento supports com o elemento Function. Não há conceitos na UFO-A, UFO-B e UFO-C que descreva que uma Category possa executar um atividade ou ser usada em uma atividade. Porém, é possível expressar situações do tipo A categoria de aplicação X auxilia na execução de tais tipos de atividades ou A categoria de aplicação Y é responsável por executar tais tipos de atividades. Desta forma, não há um problema ontológico nesse relacionamento.

146 130 Os demais relacionamentos (is technically responsible for, is resposible for development of) não possuem uma interpretação ontológica de devido à falta de documentação desses relacionamentos Problemas Ontológicos com a Semântica do Elemento Function Utilizando o Elemento Application System. Segundo o conceito de Function apresentado na seção 3.3, uma atividade do processo de negócio pode ser desempenhada por um sistema computacional, ou seja, uma atividade pode ser de responsabilidade e/ou executada por uma aplicação computacional. Porém, não existe um relacionamento entre uma aplicação computacional (Application System, Application System Type e Application System Class) e uma Function que descreva tal situação. Desta forma, é identificado um problema de não-solidez 6 na linguagem de processos de negócio do ARIS Method, ou seja, existe uma conceituação do domínio de Processos de Negócio que não pode ser expresso pela linguagem. Para resolver tal problema, é necessário adicionar um novo relacionamento com a mesma semântica do carries out entre os elementos que representam sistemas computacionais (Application System, Application System Type e Application System Class) e o elemento Function. 4.6 DIALETO DA LINGUAGEM DE PROCESSO DE NEGÓCIO DO ARIS METHOD A seção 4.5 apresentou a análise ontológica dos elementos e relacionamentos presente no metamodelo de Processo de Negócio da linguagem ARIS Method apresentado no Capítulo 3. A seção 4.5, também, apresentou a semântica para cada elemento e relacionamento que está presente no dialeto da linguagem de processo de negócio. A 6 Uma linguagem é considerada não-lucida quando há uma construção não-lucida na linguagem, ou seja, quando existe um elemento de modelagem que representa duas ou mais entidades ontológicas. A não lucidez no nível de linguagem é considerada um caso especial de sobrecarga no construtor (GUIZZARDI, 2005a).

147 131 Figura 4.28 apresenta um fragmento do dialeto da linguagem de Processo de Negócio do ARIS Method. Figura Fragmento do dialeto da linguagem de processos de negócio do ARIS Method. A Tabela 4.1 apresenta somente os elementos exclusivos da linguagem de processo de negócio do ARIS Method. Somente o elemento Location, presente no dialeto organizacional, não está presente no dialeto da linguagem de processo de negócio do ARIS Method. Tabela 4.3 Elementos presente no dialeto organizacional. Elemento do ARIS Method Elemento da UFO Descrição Function Action Uma tarefa organizacional realizada por um agente. Event Event Um evento ocasionado por alguma tarefa externa ou interna ao processo de negócio. Rule Sem interpretação ontológica Regras de controle do fluxo do processo de negócio. Application Sistemas computacionais que auxiliam Object System na conclusão de uma atividade. Application Tipo de sistema computacional que Object Universal System Type auxilia na conclusão de uma atividade. Uma categoria de sistemas Application Category computacionais que auxiliam na System Class conclusão de uma atividade.

148 132 A Tabela 4.4 apresenta os relacionamentos que não estão presenta no dialeto da linguagem de processo de negócio. Tabela 4.4 Relacionamentos eleminados da linguagem de processo de negócio. Relacionamento Elemento de Origem Elemento de Destino is techinically responsible for is IT responsible for decides on has consulting role in Accepts is carried out Participant Location Function 4.7 ANÁLISE ONTOLÓGICA DO METAMODELO DE DETALHAMENTO DE ATIVIDADES Para realizar a análise ontológica dos elementos do Metamodelo de Detalhamento de Atividades tomou-se como base a semântica apresentada na seção Também será utilizada as interpretações ontológicas dos elementos Organizacionais e de Processo de Negócio apresentadas, respectivamente, nas seções 4.3 e Análise Ontológica do Cluster, Technical Term e Information Carrier Os elementos Cluster e Technical Term representam informações e o elemento Information Carrier representa veículos de armazenamento de informações. Levando em consideração apenas esses conceitos, os elementos Cluster, Technical Term e Information Carrier são interpretados como Object Universals. A Figura 4.29 apresenta a interpretação dos elementos Cluster, Technical Term e Information Carrier.

149 133 Figura 4.29 Interpretação dos elementos Cluster, Technical Term e Information Carrier. No entanto, no contexto do processo de negócio, mais especificamente no contexto da execução de uma atividade, os elementos Cluster, Technical Term e Information Carrier representam recursos que são criados, utilizados, modificados e destruídos em uma ou mais atividades de um processo de negócio. Isto pode ser comprovado ao analisar a semântica dos relacionamentos creates, deletes, change e read que os elementos Cluster e Technical Term possuem com o elemento Function e ao analisar a semântica dos relacionamentos create output to, reads, provides input for e is used by que ocorre entre o elemento Information Carrier e os elementos organizacionais e Function. Logo, os elementos Cluster, Technical Term e Information Carrier, no contexto de processo de negócio, também podem ser interpretados como Resource Universal. Os relacionamentos creates, deletes, change e read que ocorrem entre os elementos Cluster e Technical Term com o elemento Function representam, respectivamente, as seguintes Resource Participation Universal: Creation Universal, Termination Universal, Change Universal e Usage Universal. O relacionamento lies on entre Information (Cluster e Technical Term) e Information Carrier é interpretado como um relacionamento formal, utilizado para descrever o relacionamento entre a informação e o meio de armazenamento. O relacionamento use entre Cluster e Application System representa que uma informação é utilizada por um sistema computacional e é interpretado como um Usage.

150 134 O relacionamento can use entre Cluster e Application System Type representa que uma informação é utilizada por um tipo de sistema computacional é interpretado como um Usage Universal. O relacionamento is owner of entre Participant e Information representa que uma ou mais entidades organizacionais são os responsáveis legais pelas informações. Desta forma, esse relacionamento é interpretado com um social moment que uma ou mais entidades organizacionais assumem ao criarem uma ou mais informações dentro da organização. O relacionamento is specimen owner of entre Organizational Unit e Cluster possui a mesma interpretação que o relacionamento is owner of entre Participant e Information. O relacionamento reads entre Function e Information Carrier representa que a atividade lê as informações contidas em um veículo de armazenamento. Desta forma, pode-se interpretar esse relacionamento com um Usage Universal (Resouce Participation) indireto, pois o recurso que está sendo utilizado é a informação contida no veículo de armazenamento. Por fim, é importante destacar que o elemento Information Carrier não possui nenhum relacionamento com os demais elementos do metamodelo que descreva os Resource Participation: Create, Terminate e Change. Desta forma, não é possível expressar situações de criação, exclusão ou modificação do meio de armazenamento. Assim, propomos que seja adicionado no metamodelo de detalhamento de atividade relacionamentos que possibilitem expressar as situações citadas Análise Ontológica do Elemento Business Rule Infelizmente a documentação on-line da ferramenta, (SCHEER, 1999) e (DAVIS, 2001) não apresentaram a semântica para o elemento Business Rule. Desta forma, foi necessário analisar o metamodelo de detalhamento de atividades na tentativa de encontrar a semântica desse elemento e, assim, realizar a análise ontológica.

151 135 No metamodelo de detalhamento de atividade o elemento Business Rule possui um relacionamento com o elemento Function chamado describes. Assim, é possível concluir que o elemento Business Rule é utilizado para descrever as regras que ditam o comportamento de uma ou mais atividades do processo de negócio ou até mesmo de um processo de negócio. De acordo com Guide Business Rule (2008 apud AZEVEDO et al., 2009), as regras de negócio são declarações de políticas ou condições que devem ser satisfeitas pelos processos da organização. As regras de negócio também definem ou restringem alguns aspectos da organização e são utilizadas para explicitar a dependência entre as atividades organizacionais, definindo o fluxo do processo de negócio. Além disto, as regras de negócio definem regras específicas de uma atividade do processo de negócio. Tendo como base o conceito apresentado no parágrafo acima, o elemento Business Rule é interpretado como um Technical Norms. A Figura 4.30 apresenta a interpretação do elemento Business Rule. Figura 4.30 Interpretação do elemento Business Rule. 4.8 DIALETO DA LINGUAGEM DE DETALHAMENTO DE ATIVIDADE DO ARIS METHOD A seção 4.7 apresentou a análise ontológica dos elementos e relacionamentos presente no metamodelo de Detalhamento de Atividade do ARIS Method apresentado no

152 136 Capítulo 3. A seção 4.7, também, apresentou a semântica para cada elemento e relacionamento que está presente no dialeto da linguagem de detalhamento de atividades. O dialeto de Detalhamento de Atividade é composto por elementos presentes no dialeto da linguagem organizacional e no dialeto da linguagem de processos de negócio. A Tabela 4.5 apresenta somentes os elementos que são excluivos do dialeto de Detalhamento de atividades do ARIS Method. Tabela 4.5 Elementos presentes somente no Dialeto de Detalhamento de Atividades. Elemento do ARIS Method Elemento da UFO Descrição Cluster Technical Term Information Carrier Bussines Rule Object Universal Technical Norms Representa Informação Representa Informação Veiculo que armazena a informação. São regras que ditam o comportamento de uma ou mais atividades do processo de negócio ou até mesmo de um processo de negócio. 4.9 DISCUSSÃO SOBRE ANÁLISE ONTOLÓGICA E TRABALHOS CORRELATOS Um dos trabalhos que mais se assemelham a este é o apresentado por Green e Rosemann em (GREEN et al., 2004) (GREEN et al., 2004b) (GREEN e ROSEMANN, 2005). Green e Rosemann discutem a avaliação ontológica das linguagens presentes no ARIS Method com base na ontologia BWW (WEBER, 1997). A análise ontológica proposta neste trabalho difere do trabalho de Green e Rosemann em três aspectos principais. Primeiramente, utilizamos como ponto de partida para a nossa avaliação fragmentos dos metamodelos que representam fielmente as linguagens de modelagem que estão implementadas na ferramenta ARIS Toolset. Desta forma, a avaliação se aplica aos modelos produzidos nessa ferramenta. Em sua vez, Green e Rosemann consideraram o metamodelo apresentado por Scheer (SCHEER, 1999) que já não retrata a linguagem como adotada nas organizações que utilizam a ferramenta ARIS Toolset.

153 137 Adicionalmente, Green e Rosemann interpretaram apenas os elementos da linguagem isoladamente. Neste trabalho, avaliamos também a interpretação dos relacionamentos entre os elementos da linguagem (meta-associações no metamodelo). Por fim, este trabalho utilizou uma ontologia de fundamentação diferente na análise ontológica. Isto nos permitiu chegar a diferentes conclusões com relação à interpretação de alguns elementos de modelagem. Por exemplo, nossa interpretação de Function difere significativamente daquela apresentada em (GREEN et al., 2004). Naquele trabalho, uma Function é interpretada como um mapeamento formal entre dois valores em um espaço conceitual de estados. Desta forma, Green e Rosemann não fornecem uma explicação ontológica, por exemplo, para: (i) participação de agentes em atividades organizacionais; (ii) noção de tempo associada à execução de uma atividade organizacional; (iii) definição de funções complexas através de relações mereológicas entre funções e sub-funções; dentre outras relações que envolvem funções, eventos, agentes e compromissos. Outros autores, usando o termo Semantic Business Process Management (THOMAS e FELLMANN, 2006), propõem realizar anotações nos elementos dos modelos de processo de negócio para adicionar informações ( anotação semântica ) nesses modelos. Tais anotações, normalmente estão se referindo a entidades de uma ontologia do domínio de negócio com o objetivo de definir objetivos, pré-condições e efeitos das atividades no modelo de processo de negócio. Este trabalho reconhece que a análise ontológica proposta neste trabalho é um pré-requisito para fundamentar as anotações semânticas, quando os elementos do modelo anotado e os elementos da anotação são interpretados em termos de entidades de uma ontologia de fundamentação. A abordagem inicialmente esboçada em (THOMAS e FELLMANN, 2006) foi desenvolvida em (THOMAS e FELLMANN, 2007), onde os autores propõem uma abordagem de anotação semântica em EPC baseada em uma ontologia que espelha um pequeno fragmento do metamodelo EPC. Infelizmente, tal abordagem proposta não clarifica a semântica dos elementos de modelagem do EPC. O projeto SUPER tem investigado a semântica do EPC (sepc) (FILIPOWSKA et al., 2009a) (FILIPOWSKA et al., 2009b). Essa abordagem é baseada na transformação do

154 138 sepcs na Ontologia de Modelagem de Processo de Negócio (Business Process Modeling Ontology BPMO) (SUPER, 2008) (SUPER, 2009). O BPMO, por sua vez, especializa conceitos de uma ontologia chamada UPO. A UPO é inspirada no DOLCE (BOTTAZI e FERRARIO, 2006). A relação entre sepcs e a sua fundamentação semântica não é direta, e consequentemente este projeto não apresenta a interpretação semântica do EPC. Por fim, outros trabalhos na literatura visam especificamente a análise de propriedades formais do metamodelo de processo de negócio do ARIS utilizando Redes de Petris (KINDLER, 2006) (ROSEMANN e VAN DER AALST, 2007) (VAN DER AALST, 1998) (VAN DONGEN et al., 2005). Esses trabalhos são complementares ao descrito aqui, pois definem semânticas de execução para EPCs CONCLUSÃO A abordagem de análise ontológica apresentada neste capítulo possibilitou um melhor entendimento dos conceitos presentes nas linguagens de domínio do ARIS Method com base em uma ontologia de fundamentação. Um benefício direto da análise ontológica dos metamodelos do ARIS Method está relacionado ao desenvolvimento de modelos organizacionais (organizacional, processo de negócio e detalhamento de atividades) com semântica bem definida. Afinal, não haverá elementos nas linguagens de domínio com semântica duvidosa e elementos em excesso (elementos sem nenhuma relação semântica com o domínio da linguagem). Com as linguagens de modelagem sem problemas ontológicos as técnicas de desenvolvimento de aplicativo computacionais poderão tirar um maior proveito da semântica dos elementos destas linguagens. A avaliação ontológica permitiu também revelar problemas de uso (por exemplo, caso do uso do elemento Event). A análise permitiu identificar de forma sistemática, um problema já identificado informalmente na literatura (DAVIS, 2001, p. 111).

155 139 CAPÍTULO 5 UMA ABORDAGEM DE DESENVOLVIMENTO ORIENTADO A MODELOS UTILIZANDO ARTEFATOS DE ARQUITETURA ORGANIZACIONAL DE TECNOLOGIA DA INFORMAÇÃO 5.1 INTRODUÇÃO Os modelos produzidos pelas Arquiteturas Organizacionais de TI são artefatos ricos em informação que podem ser utilizados no desenvolvimento de sistemas computacionais através de técnicas de Desenvolvimento Orientado a Modelos. Desta forma, diversos autores propuseram técnicas de Desenvolvimento Orientado a Modelos que utilizam os modelos das Arquiteturas Organizacionais de TI no desenvolvimento de sistemas computacionais, dentre eles: i. Lubke et al. (2008) propõem uma abordagem que permite utilizar os modelos de processos de negócio, modelados em EPC, para o desenvolvimento de sistemas orientados a serviços para empresas de pequeno e médio porte; ii. Specht et al. (2005) apresentam uma abordagem que permite utilizar os modelos de processos, modelados em EPC, e os modelos de detalhamento de atividade, modelados em FADs, para o desenvolvimento de um sistema orientado a serviços; iii. Ouyang et al. (2008) propõem uma abordagem de automatização de modelos BPMN (BPMN, 2009). Tal automatização é feita através de uma transformação que traduz o modelo BPMN em um modelo BPEL (OASIS, 2006) pronto para execução em uma BPEL engine; iv. Ziemann e Mendling (2005) apresentam uma abordagem de transformação de modelos de processos de negócio modelados na linguagem EPC para modelos em BPEL.

156 140 Apesar das abordagens supracitadas utilizarem modelos de processo de negócio para o desenvolvimento de sistemas computacionais orientados a processos, tais abordagens descartam quase que completamente os outros modelos que estão presentes nas Arquiteturas de TI. Por exemplo, grande parte das abordagens supracitas utiliza apenas o modelo EPC para a construção dos sistemas computacionais. Desta forma, tais abordagens não garantem sistematicamente o alinhamento dos diferentes aspectos da organização (organizacional, detalhamento de atividades de processos de negócio, entre outros) com os sistemas computacionais desenvolvidos. Logo, a tarefa de alinhamento entre os diversos aspectos deve ser conduzida manualmente, aumentando o esforço necessário durante o processo de desenvolvimento e perdendo-se oportunidades de automação. Adicionalmente, grande parte das abordagens apresentadas anteriormente não permite que o projetista manipule por completo as informações contidas nos modelos das Arquiteturas Organizacionais de TI. Em outras palavras, as abordagens atuais não permitem ao projetista utilizar a semântica dos elementos presentes nos modelos das Arquiteturas Organizacionais de TI no desenvolvimento do sistema computacional. Por exemplo, a abordagem proposta por Lubke et al. (2008) não diferencia atividades executadas por humanos e atividades executadas por aplicativos computacionais. As abordagens supracitadas também não permitem que o projetista introduza decisões de projeto nas transformações que manipulam os modelos, com a finalidade de alcançar o sistema computacional desejado. Isso ocorre, pois grande parte dessas abordagens consiste em traduções diretas entre espaços tecnológicos (um termo definido em (KURTEV et al., 2002)), ou seja, transformam os modelos de processo de negócio diretamente em um modelo de realização (linguagem de programação, XML, entre outros). Desta forma, os modelos produzidos nas Arquiteturas Organizacionais de TI são considerados artefatos finais, ou seja, assume-se que os modelos das Arquiteturas Organizacionais de TI estão prontos para serem automatizados. Esta abordagem funde o nível de modelagem organizacional (conceitual) e o nível detalhado de projeto, o que é inadequado, uma vez que, na maioria dos casos os modelos das Arquiteturas Organizacionais de TI foram criados para representar uma realidade organizacional e não para produção de sistemas computacionais. Logo, é necessário analisar os modelos das Arquiteturas de TI para identificar como os mesmos podem ser automatizados ou

157 141 como as informações contidas nos modelos podem ser úteis para construir sistemas computacionais que automatizem, por completo ou parcialmente, certos aspectos da organização (AZEVEDO et al., 2009) (GONZÁLEZ e DÍAZ, 2007) (KOHLBORN et al., 2009). Como discutido em (CARDOSO et al., 2008), a união das decisões de projeto com as informações contidas nos modelos das Arquiteturas Organizacionais de TI pode proporcionar a construção de diversos sistemas computacionais, a partir do mesmo modelo de Arquitetura Organizacional de TI. A maioria das abordagens de Desenvolvimento Orientado a Modelos com base em modelos de Arquiteturas Organizacionais de TI ou modelos de processos de ignora esta possibilidade. Desta forma, tais abordagens se baseiam na representação direta de soluções tecnológicas nos Modelos de Arquiteturas Organizacionais de TI, perdendo as vantagens da separação entre interesses (do inglês, concerns) organizacionais e tecnológicos. Para suprir as deficiências apresentadas acima, é proposta uma nova abordagem de Desenvolvimento Orientado a Modelos para o desenvolvimento de sistemas computacionais orientados a processo. Tal abordagem permite que o projetista utilize as informações contidas nos diversos modelos das Arquiteturas Organizacionais de TI e aplique as decisões de projeto nas transformações, com a finalidade de desenvolver um sistema computacional mais adequado às suas necessidades. A Figura 5.1 apresenta a abordagem de Desenvolvimento Orientado a Modelos proposta. A abordagem é composta de três transformações parametrizadas: (i) Transformação de Abstração (TA), (ii) Transformação de Refinamento (TR) e (iii) Transformação de Detalhamento de Atividade (TDA). Cada uma dessas transformações gera resultados que estão de acordo (em conformidade) com as informações contidas nos modelos das Arquiteturas Organizacionais de TI e não modificam decisões de projeto já tomadas em outras transformações. (De acordo com a teoria sobre conformidade e transformações apresentada na seção ) Uma característica importante da abordagem de Desenvolvimento Orientado a Modelos proposta é a sua independência de plataforma (veja a seção 2.4.2), ou seja, as transformações TA (Transformação de Abstração), TR (Transformação de

158 142 Refinamento) e TDA (Transformação de Detalhamento de Atividade) não estão relacionadas com nenhuma tecnologia ou plataforma tecnológica. Desta forma, os modelos de sistemas computacionais gerados podem ser utilizados para gerar sistemas computacionais em diferentes tecnologias e plataformas tecnológicas (BPEL, JBOSS jbpm entre outras). Figura 5.1 Abordagem de Desenvolvimento Orientado a Modelos utilizando artefatos de Arquitetura Organizacional de TI. As Transformações de Abstração (TA) e de Refinamento (TR) são responsáveis por alterar seletivamente a granularidade de um modelo de processos para construir um novo modelo que será utilizado para ditar as regras do comportamento do sistema computacional. Em outras palavras, essas transformações permitem que o projetista

159 143 aplique decisões de projeto sobre o modelo de processo (modelo conceitual), transformando este em um modelo comportamental (modelo de projeto) adequado para o sistema computacional em desenvolvimento. As Transformações de Abstração e Refinamento, neste trabalho, são chamadas de Transformações no nível comportamental. Tanto a transformação de Abstração (TA), quanto a transformação de Refinamento (TR) utilizam o conceito chamado de Componente como base para as suas etapas. De forma simplória, um componente é a maneira de representar um conjunto de atividade de menor nível de abstração em uma atividade de maior nível de abstração. (A teoria sobre componentes de processo de negócio é apresentada na seção 5.2.) A Transformação de Detalhamento da Atividade (TDA) permite ao projetista informar (selecionar) quais elementos do diagrama de detalhamento de atividades são necessários, baseado em uma ou mais decisões de projeto, para o desenvolvimento do sistema de computacional. Como apresentado na seção 3.4, os modelos de detalhamento de atividade são utilizados para descrever os detalhes e, assim, possuem grandes informações (por exemplo, informações necessárias e produzidas na atividade) que podem ser úteis para o desenvolvimento de atividade que será automatizada. O resultado da TDA é um modelo de detalhamento de atividade que contem apenas os elementos necessários para o desenvolvimento do sistema computacional. A abordagem de Desenvolvimento Orientado a Modelos proposta é composta de dois tipos de parametrizações que guiam as transformações supracitadas: Parametrização de Automatização (PA) e Parametrização Organizacional (PO). Como demonstrado na Figura 5.1, a parametrização PA é utilizada exclusivamente nas Transformações de Abstração e Refinamento e a parametrização PO é utilizada em todas as transformações. A Parametrização de Automatização (PA) permite ao projetista decidir o grau de automatização de cada atividade do modelo comportamental do sistema computacional em realização. A seção apresenta maiores detalhes sobre essa parametrização. A Parametrização Organizacional (PO) possibilita ao projetista manipular as entidades organizacionais presentes nos modelos organizacionais para a identificação dos atores

160 144 do sistema computacional em realização. Por exemplo, através dessa parametrização, é possível ao projetista informar quais entidades organizacionais irão executar um determinado papel no sistema computacional em desenvolvimento. No final da execução das transformações do nível independente de plataforma é gerado um conjunto de modelos do sistema orientado a modelos. Esse conjunto é composto por modelos que descrevem a estrutura comportamental, detalhes de cada componente de processo de negócio integrante da estrutura comportamental e as entidades organizacionais que fazem parte do sistema computacional em realização, como mostrado na Figura 5.2. Figura 5.2 Modelo representando as relações dos metamodelos do sistema orientado a processo de negócio A descrição do sistema orientado a processos é realizada através de instâncias dos seguintes metamodelos: i. Metamodelo Comportamental do Sistema Orientado a Processos: utilizado para criar modelos comportamentais que descrevam o comportamento funcional do sistema computacional em realização e, assim, descrever quais componentes serão executados e quais entidades organizacionais serão responsáveis pelos mesmos no escopo do sistema

161 145 ii. Metamodelo de Detalhamento de Atividade do Sistema Orientado a Processo: utilizado para criar modelos que descrevam os detalhes de cada atividade de processo de negócio que estão presentes no modelo comportamental; e iii. Metamodelo Organizacional do Sistema Orientado a Processo: utilizado para criar modelos que descrevam as entidades organizacionais que estão no modelo comportamental e nos modelos de detalhamento. A última etapa da abordagem proposta ocorre no nível dependente de plataforma. Nesse nível, o projetista utiliza os modelos criados no nível independente de plataforma para a concretização do sistema computacional através das Transformações Dependentes de Plataforma (TDP). As Transformações Dependentes de Plataforma são responsáveis por aplicar as decisões de projeto no nível tecnológico, gerando o sistema computacional em uma determinada tecnologia ou plataforma tecnológica escolhida pelo projetista. Figura Diferença entre a abordagem atuais e a abordagem proposta. A Figura 5.3 apresenta a comparação entre as abordagens de Desenvolvimento Orientado a Modelos atuais e a abordagem proposta neste trabalho. Como pode ser observado, a abordagem proposta permite ao projetista produzir diversas soluções tecnológicas enquanto as abordagens atuais permitem a produção de um tipo de solução tendo com base os modelos das Arquiteturas Organizacionais de TI.

162 146 Para comprovar que a abordagem proposta neste trabalho permite gerar diversos sistemas a partir de um conjunto de modelos de uma Arquitetura Organizacional de TI, imagine o seguinte exemplo: um modelo de processo com três atividades e cada atividade com apenas um responsável. Utilizando apenas as três possibilidades de automatização da Parametrização de Automatização (totalmente automatizada, gerenciada e manual) (apresentadas na seção 5.5.1) é possível gerar vinte e seis sistemas computacionais diferentes a partir desse modelo de processo de negócio. Caso sejam consideradas as Transformações de Abstração, Refinamento e Detalhamento de Atividade, o número de possibilidades de sistemas gerados a partir de um processo de três atividades será ainda maior. Desta forma, é mostrado que a abordagem proposta permite o desenvolvimento de diversos sistemas computacionais tendo como base as decisões de projeto e os modelos das Arquiteturas Organizacionais de TI. O capítulo está organizado da seguinte forma: a seção 5.2 apresenta o conceito de componentes: a seção 5.3 apresenta as transformações do nível comportamental; a seção 5.4 apresenta a transformação do nível de atividade; a seção 5.5 apresenta as parametrizações utilizadas nas transformações, por fim, a seção 5.6 apresenta as conclusões deste capítulo. 5.2 COMPONENTE DE PADRÃO DE PROCESSO Um componente de padrão de processo é uma atividade de maior nível de abstração que engloba um ou mais padrões de processo 7 de um determinado processo (OUYANG et al., 2008). Em outras palavras, o componente é uma forma de representar que um conjunto de atividades (que possuem o mesmo objetivo) pode ser agrupado em uma nova atividade de maior nível de abstração. De acordo com Ouyang et al (2008), um componente é uma atividade que possui somente uma entrada e uma saída. A entrada do componente (do inglês, source place) é responsável por receber as informações a serem manipuladas pelo componente e a saída 7 Um padrão de processo (do inglês, workflow pattern) é uma abstração de uma forma concreta que ocorre repetidamente em contextos específicos do processo de negócio (AZEVEDO et al., 2009).

163 147 da componente (no inglês, sink place) é a responsável por enviar as informações manipuladas para o próximo componente (caso exista). Os pontos de entrada e saída do componente são os responsáveis pelas fronteiras de controle de fluxo (comportamento) e da informação do componente (OUYANG et al., 2008). Segundo Ouyang (et al., 2008), o componente possui as seguintes características: i. um componente é composto por pelo menos um objeto elementar do BPMN (BPMN, 2009) como, por exemplo, o elemento fork. (OUYANG et al., 2008); ii. um componente possui um, e somente um, ponto de entrada responsável por receber a informação a ser manipulado pelo componente; iii. um componente possui um, e somente um, ponto de saída responsável por enviar para fora do componente a informação manipulada pelo componente; iv. um componente é o caminho entre dois pontos do modelo de processo de negócio que estão entre os eventos: inicial e final; e v. um componente possui apenas eventos intermediários em sua definição. Propomos uma extensão do conceito de componente com as seguintes modificações: i. um componente é composto por pelo menos um padrão de processo (ao invés de componentes de BPMN) e; ii. um componente pode ser composto de outros componentes. A Figura 5.4 apresenta um exemplo de componente que combina os padrões de processo Parallel Split (RUSSELL e HOFSTEDE, 2008) e Multi-Merge (RUSSELL e HOFSTEDE, 2008).

164 148 Figura 5.4 Exemplo de Componente. Como pode ser observado na Figura 5.4, o componente foi criado porque a combinação dos dois padrões de projeto formou um componente com apenas uma entrada e uma saída. Para finalizar, diferente de como o conceito de componente é utilizado em (OUYANG et al., 2008) e em (VANHATALO et al., 2007) 8, neste trabalho o conceito de componente é utilizado para definir as fronteiras, no modelo de processo, onde as transformações serão aplicadas. O conceito de componente também é utilizado para definir a fronteira do resultado das transformações. Por exemplo, é possível definir que um componente é composto de dois padrões de processo contidos em um processo de negócio e uma determinada transformação será aplicada sobre esse componente; ou que através de uma transformação uma determinada atividade será substituída por dois padrões de processo. 5.3 TRANSFORMAÇÕES NO NÍVEL COMPORTAMENTAL As transformações no nível comportamental abrangem a Transformação de Abstração e a Transformação de Refinamento. Essas transformações são aplicadas seletivamente pelo projetista para transformar os modelos de processo de negócio (modelo conceitual) em modelos comportamentais (modelo de projeto) que descrevam a sequência de atividades que o sistema computacional deve realizar. A Figura 5.5 apresenta uma exemplificação da aplicação da transformação de abstração e refinamento sobre um modelo de processo de negócio. 8 Em (VANHATALO et al., 2007) o conceito de componente é chamado de Single Entry Single Exit (SESE)

165 149 Como discutido anteriormente, os modelos de processo de negócio são utilizados para representar uma realidade organizacional e não para o desenvolvimento de sistemas computacionais. Devido a esse fato, é necessário que o projetista modifique o modelo de processo de negócio gerando um modelo comportamental do sistema computacional que atenda as decisões de projeto. Por exemplo, na Figura 5.5 as atividades A, B e C foram abstraídas para o componente (atividade) ABC através da transformação de abstração (TA) tomando como base uma ou mais decisões de projeto, enquanto a atividade D foi refinada em um componente, que contém as atividades D1 e D2, através da transformação de refinamento (TR) tomando como base uma decisão de projeto. Figura 5.5 Exemplo de utilização das transformações no nível comportamental Transformação de Abstração Uma Transformação de Abstração (TA) permite que o projetista una duas ou mais atividades, dois ou mais componentes ou dois ou mais padrões de processo em um único componente de mais alto nível de abstração. Em outras palavras, pode-se dizer que a Transformação de Abstração constrói um componente de maior nível de abstração a partir de dois ou mais componentes de menor nível de abstração. Através dessa transformação, o projetista pode unir atividades do processo de negócio que têm um mesmo objetivo a ser alcançado em uma única atividade no modelo

166 150 comportamental do sistema computacional em desenvolvimento, desta forma, diminuindo a complexidade do sistema computacional. A Figura 5.6 apresenta o modelo de processo de negócio que será utilizado para ilustrar a Transformação de Abstração. Start event A1 A2 A3 End event Figura 5.6 Exemplo de aplicação da Transformação de abstração. A Tabela 5.1 apresenta as possíveis abstrações que podem ser realizadas com as atividades A1, A2 e A3 da figura acima. Tabela 5.1 Abstrações das atividades do Participante A. Número Combinação Resultado 1 A1 e A2 A1A2 2 A2 e A3 A2A3 3 A1, A2 e A3 A1A2A3 Como apresentado na Tabela 5.1, foi possível desenvolver três possíveis componentes utilizando a combinação das atividades e o padrão de processo sequence. A Figura 5.7 apresenta um exemplo de processo de negócio após a aplicação da transformação de abstração de atividades utilizando a terceira opção da Tabela 5.1. Figura Exemplo da transformação de abstração. A Transformação de Abstração substituiu as atividades A1, A2 e A3 e em um novo componente chamado A1A2A3 de maior nível de abstração. Vale notar que a Tabela 5.1 omite a combinação do elemento A1 com o elemento A3; a abstração de A1 e A3 é inválida, pois o novo modelo comportamental não estaria em conformidade com o modelo de processo original, uma vez que a atividade A2 seria eliminada sem ser

167 151 incorporada à sua antecessora ou sucessora em um novo componente de um nível mais alto de abstração. Quando a transformação de abstração é aplicada sobre um conjunto de padrões de processo, a transformação leva à abstração de todo o conjunto de padrões de processo em um novo componente. É importante ressaltar que o projetista somente pode abstrair um ou mais padrões de processo que obedeçam as regras que definem um componente, apresentadas na seção 5.2. O processo de negócio ilustrado na Figura 5.8 será utilizado para exemplificar a Transformação de Abstração com um ou mais padrões de processo. Event B B Event B' Start event A D End event Event C C Event C' Figura 5.8 Processo de utilizado para exemplificar abstração de padrões de processo. Usando o conceito de componente, o projetista pode abstrair os padrões de processo Exclusive Choice (RUSSELL e HOFSTEDE, 2008) e Simple Merge (RUSSELL e HOFSTEDE, 2008), apresentados na Figura 5.9 (i), e transformá-los no componente Exclusive Choice/Simple Merge que contempla esses dois padrões de processo, conforme é ilustrado na Figura 5.9 (ii). Figura 5.9 Criando componente a partir de padrões de processo. É importante observar na Figura 5.9 que somente foi possível abstrair os padrões de processo Exclusive Choice e Simple Merge e criar o componente Exclusive Choice/Simple Merge porque a combinação dos padrões de processo obedecem às regras para criar um componente, a saber: (i) possui apenas um ponto de entrada e um ponto de saída e (ii) somente existem eventos intermediários dentro do componente. O

168 152 componente Exclusive Choice/Simple Merge foi nomeado como BC no modelo, como mostra a Figura Start event A BC D End event Figura 5.10 Processo de negócio após a abstração dos padrões Excluise Choice e Simple Merge. O caso extremo da utilização da transformação de abstração em padrões de processo ocorre quando todo o modelo de processo de negócio é abstraído em apenas um componente, ou seja, todo o modelo de processo de negócio é transformado em um componente de mais alto nível de abstração no modelo comportamental do sistema em realização. A Figura 5.11 apresenta o caso extremo. Start event ABCD End event Figura 5.11 Caso extremo da transformação de abstração em padrões de processo. O componente ABCD é composto das atividades A e D e do componente BC do modelo apresentado na Figura Desta forma, foi possível criar um modelo comportamental para o sistema computacional de mais alto nível de abstração que o modelo de processo apresentado na Figura Impactos da Transformação de Abstração sobre a Estrutura Organizacional As regras da Transformação de Abstração (TA) apresentadas até o momento podem ser aplicadas para atividades que estão sob a responsabilidade de um mesmo participante ou que estão sob a responsabilidade de participantes distintos (cada atividade possui somente um participante responsável) do modelo do processo de negócio utilizado para o desenvolvimento do sistema computacional. Sempre que a Transformação de Abstração (TA) é aplicada em atividades que estão sob a responsabilidade de participantes distintos é necessário definir uma entidade

169 153 organizacional (participante) que será responsável pela nova atividade criada pela transformação. Desta forma, é estabelecido um relacionamento carries out entre a entidade organizacional e a nova atividade, ou seja, a entidade organizacional escolhida é a responsável legal pela execução da atividade. Isso não implica que a entidade organizacional irá executar a nova atividade, mas que é de sua responsabilidade a conclusão da mesma. É importante ressaltar que a nova atividade concentra as responsabilidades de cada um dos participantes das atividades envolvidas e devido a isso, ao definir um responsável para essa nova atividade, este irá assumir as responsabilidades de todos os participantes das atividades abstraídas. Desta forma, a escolha de um responsável para a nova atividade trás um grande impacto sobre a conformidade entre o modelo de processo e modelo organizacional da Arquitetura Organizacional de TI com os modelos de comportamento e organizacional do sistema orientado a processo. Afinal, é muito provável que nenhuma das entidades organizacionais das entidades abstraídas tenha Social Moments para ser responsável pela nova atividade abstraída. Para solucionar o problema da conformidade, é necessário que o responsável pela nova atividade seja (i) uma das entidades organizacionais que eram responsáveis pelas atividades que foram abstraídos; ou (ii) uma nova entidade organizacional formada pelas entidades organizacionais das atividades abstraídas (porque tais entidades tinham um relacionamento de carries out com as atividades abstraídas.) No caso do projetista escolher a opção (i), é importante enfatizar que a entidade organizacional escolhida pode não possuir todos os Social Moments necessários para que a atividade seja concluída com sucesso. Desta forma, é necessário que as outras entidades organizacionais que não foram escolhidas auxiliem a entidade organizacional escolhida para que a nova atividade seja realizada com sucesso. Por exemplo, na Figura 5.12, o projetista escolheu que o responsável pela atividade A3BC (abstração das atividades A3, B e C) será o Participante B, mas o Participante A e o Grupo C contribuíram para a conclusão da atividade.

170 154 Figura 5.12 Transformação de abstração em atividades de responsáveis distintos. Outra característica da Transformação de Abstração quando envolve atividade com responsáveis distintos é a eliminação dos responsáveis sem atividades no modelo comportamental. Isso ocorre quando o responsável não possui nenhum relacionamento carries out com alguma atividade do modelo de processo. Por exemplo, ao abstrair a atividade B, do Participante B, e a atividade C, do Grupo C, esse último ficou sem nenhuma atividade sob a sua responsabilidade e, assim, o mesmo foi eliminado do modelo comportamental. Caso o projetista descida pela a opção (ii) é necessário criar nova entidade organizacional que será composta ou instanciada pelas entidades organizacionais responsáveis pelas atividades abstraídas. Essa nova entidade organizacional deve ter os Social Moments necessários para se responsabilizar pela atividade. No caso do ARIS, a Transformação de Abstração permite que o projetista crie uma das seguintes entidades organizacionais que será responsável pela nova atividade: i. um novo papel social (Person Type ou Position Description): somente poderá ser instanciado por um ou mais participantes responsáveis pelas atividades abstraídas; ou ii. ou um novo grupo (Group): somente pode ser composto por um ou mais participantes que eram responsáveis pelas atividades abstraídas.

171 155 Caso o Projetista decida criar um novo papel social (Person Type ou Position Description) para o novo componente, é necessário informar o nome do novo papel e quais entidades organizacionais irão instanciar esse papel. Como apresentado no Capítulo 4, o relacionamento de instanciação entre as entidades organizacionais e o elemento Person Type é realizada pelo relacionamento performs. A Figura 5.13(A) apresenta o modelo comportamental com o Papel X. Figura 5.13 Indicando um papel para nova atividade abstraída. A Figura 5.13(B) apresenta que os elementos organizacionais Participante A, Participante B e Grupo C podem instanciar o Papel X e, desta forma, todos estes elementos podem ser responsáveis pelo componente A3BC. Devido a uma limitação da linguagem organizacional do ARIS Method não é possível existir relacionamento peforms entre dois Person Types, assim, o projetista não pode informar que o novo papel (Person Type) é instanciado por um outro papel (Person Type) existente. Para resolver tal problema, no caso do ARIS Method, será necessário transferir para o novo papel (Person Type) todos os elementos (ou somente aqueles que o projetista deseja) que possuem o relacionamento performs com o elemento Person Type da atividade que participa da transformação abstração. A Figura 5.14 apresenta um exemplo de como o projetista pode escolher os elementos organizacionais de um papel (Person Type) que serão transferidos. O tipo de problema que ocorre com o relacionamento performs é o que torna importante ao projetista da transformação ter o conhecimento profundo das linguagens de

172 156 modelagem de uma Arquitetura Organizacional de TI, pois sem tal conhecimento erros dessa natureza passam despercebidos, implicando em problemas nas transformações que visam automatizar modelos das Arquiteturas Organizacionais de TI. Figura Exemplo de escolha dos elementos organizacionais pertencente a um papel (Person Type) do processo de negócio. Por fim, caso o Projetista decida criar um novo grupo (Group) para a nova atividade, é necessário informar quais entidades organizacionais irão compor esse grupo. A Figura 5.15 apresenta o novo modelo comportamental contendo o novo grupo que será responsável pela atividade A3BC e a Figura 5.16 apresenta a estrutura do novo elemento organizacional..... Participante A Grupo X Start event A1 A2 A3BC End event Figura Indicando um grupo para nova atividade abstraída.

173 157 Grupo X Participante A Participante B cooperates with Grupo C Figura 5.16 Grupo contendo os participantes das atividades abstraídas Transformação de Refinamento (TR) A Transformação de Refinamento permite ao projetista transformar uma atividade do processo de negócio em um componente de processo de negócio. O componente criado pela Transformação de Refinamento é composto de um ou mais padrões de processo. A Figura 5.17 apresenta um exemplo da aplicação da transformação de refinamento sobre uma atividade do processo de negócio. Figura 5.17 Exemplo de aplicação da transformação refinamento. A atividade B (dentro do retângulo pontilhado) do processo de negócio, apresentado na Figura 5.17, foi refinada no padrão de processo sequence (detalhes em (RUSSELL e HOFSTEDE, 2008)) composto por dois componentes de processo chamados de B1 e B2 (dentro do retângulo contínuo). Observe que o padrão sequence obedece as regras que define um componente.

174 158 Um outro exemplo de aplicação da transformação de refinamento é apresentado na Figura Nessa figura a atividade B (dentro do retângulo pontilhado) é refinada em um componente de processo (dentro do retângulo contínuo) que é composto por dois padrões de processo: Exclusive Choice (RUSSELL e HOFSTEDE, 2008) e Simple Merge (RUSSELL e HOFSTEDE, 2008). Figura 5.18 Aplicando a transformação refinamento e criando um componente formado por mais de um padrão de processo. Observe que o componente de processo formado pela união dos padrões de processo Exclusive Choice e Simple Merge obedece às regras de um componente Impacto das Entidades Organizacionais na Transformação de Refinamento Ao aplicar a Transformação de Refinamento em uma atividade do processo de negócio é necessário que o projetista verifique qual tipo da entidade organizacional é responsável por tal atividade. Como discutido no Capítulo 4, existem entidade organizacionais compostas de outras entidades organizacionais (por exemplo, unidades organizacionais e grupos) e entidades organizacionais que não são compostas de outras entidades organizacionais (papéis sociais e agentes que não são Function Complex). Para fins didáticos, neste trabalho, as entidades organizacionais compostas de outras entidades organizacionais serão chamadas de Entidades Organizacionais Complexas (EOC) e as demais de Entidades Organizacionais não-complexas (EONC).

175 159 Caso a Transformação de Refinamento seja aplicada sobre uma atividade que é da responsabilidade de uma EOC, o projetista necessitará analisar a relação entre as entidades que compõem a EOC com a atividade a ser refinada. Isso é necessário, pois em muitos casos as entidades que compõem a EOC executam tarefas contidas na atividade a ser refinada. Portanto, ao aplicar a Transformação de Refinamento em uma atividade que é da responsabilidade de uma EOC será necessário relacionar as entidades da EOC com as novas atividades contidas no componente gerado pela Transformação de Refinamento e assim adicionando raias no modelo comportamental do sistema computacional. Isso trará um grande impacto para o sistema computacional em desenvolvimento, visto que cada entidade organizacional dentro de uma raia é considerada um ator no sistema computacional. Para exemplificar essa afirmação acima, imagine que uma determinada atividade A do processo de negócio X seja da responsabilidade de um grupo G (Group). O grupo G é formado por três papéis sociais e cada uma desses papéis sociais executa uma ou mais tarefas da atividade A. Caso seja aplicada a Transformação de Refinamento na atividade A, o projetista terá que executar os seguintes passos: (i) refinar o grupo G e definir raias para cada um dos integrantes; (ii) criar atividades no processo de negócio que representem as tarefas executadas por cada integrante do grupo; e (iii) associar os integrantes do grupo com as atividades criadas por meio do relacionamento carries out. Caso a Transformação de Refinamento seja aplicada sobre uma atividade de responsabilidade de uma EONC, a transformação torna-se mais simples, pois cada atividade criada pela transformação pertencerá à EONC. Um exemplo de Transformação de Refinamento que envolva uma entidade do tipo EONC é apresentado na Figura Por fim, para simplificar a aplicação da Transformação de Refinamento, neste trabalho foi definido que a transformação não tratará a complexidade da entidade organizacional responsável pela atividade, ou seja, a Transformação de Refinamento não irá refinar a entidade organizacional. Portanto, caso um grupo ou unidade organizacional seja

176 160 responsável por uma atividade, esses tipos de entidade serão responsáveis por todas as novas atividades criadas pela Transformação de Refinamento. 5.4 TRANSFORMAÇÃO NO NÍVEL DE ATIVIDADE (TDA) Os modelos de detalhamento de atividades de processo de negócio das Arquiteturas Organizacionais de TI possuem informações importantes que podem ser utilizadas no desenvolvimento de sistemas computacionais. Por exemplo, tais modelos possuem informações que descrevem: (i) as informações necessárias para a execução de uma atividade; (ii) as informações produzidas pela atividade; (iii) as regras de negócios da atividades; e (iv) as entidades organizacionais que devem ser notificadas sobre a execução da atividade, dentre outras informações. A Transformação de Detalhamento de Atividade permite que o projetista utilize as informações contidas nos modelos de detalhamento das Arquiteturas Organizacionais de TI para construir modelos de detalhamento de componentes do sistema em realização, conforme apresentado na Figura Desta forma, o projetista consegue descrever os detalhes ( informações necessárias e produzidas pelo componente, sistemas de suporte entre outras informações) para cada componente do sistema computacional em desenvolvimento.

177 161 Figura 5.19 Transformação no nível de componente. Os retângulos descrevem a escolha feita pelo projetista através da Transformação de Detalhamento de Atividade, i.e, o projetista definiu que a atividade C do sistema computacional necessita como informação de entrada a Informação X (Cluster) do documento X (Eletronic Document) e produz como produto a Informação D (Cluster) e o documento Documento D (Eletronic Document). Além disto, o projetista também definiu que o papel Q (Person Type) irá contribuir para a conclusão da atividade C e que o sistema computacional deve utilizar as regras de negócio contidas no elemento Regra de Negócio W (Business Rule) Regras para Construção do Modelo de Detalhamento de Atividade do Sistema Computacional A Transformação de Detalhamento de Atividade (TDA) possui um conjunto de regras para a construção do Modelo de Detalhamento de Atividade do Sistema Computacional. Tais regras garantem que conformidade entre os modelos de Detalhamento de Atividade

178 162 da Arquitetura Organizacional de TI seja alcançada e, também, garantem que as decisões de projeto sejam aplicadas sobre tais modelos. A primeira regra de Transformação de Detalhamento de Atividade (TDA) permite que o projetista adicione novos elementos no modelo de Detalhamento de Atividade do Sistema Computacional que não estejam presentes no Modelo de Detalhamento de Atividades, satisfazendo, assim, um ou mais decisões de projeto. Afinal, como em outros modelos da Arquitetura Organizacional de TI, os modelos de detalhamento não foram criados com a finalidade de desenvolver sistemas computacionais em particular. A segunda regra refere-se à construção dos modelos de Detalhamento de Atividades do Sistema Computacional para as atividades que foram criadas pelas Transformações de Refinamento e de Abstração. Tais atividades não possuem modelos de detalhamento nas Arquiteturas Organizacionais de TI. Portanto, é necessário que o projetista construa os modelos de detalhamento dessas atividades a partir das informações contidas nos modelos de Detalhamento de Atividade das atividades que foram abstraídas ou refinadas. Para fins didáticos, os novos modelos de Detalhamento de Atividades do Sistema Computacional criados a partir da Transformação de Abstração e da Transformação de Refinamento serão, respectivamente, chamados de modelos abstratos e modelos refinados. A Figura 5.20 apresenta como as informações contidas em outros modelos de detalhamento de atividades da Arquitetura Organizacional de TI podem ser utilizadas para a construção de um modelo detalhado de atividade, para uma atividade criada pela Transformação de Abstração. Figura 5.20 Selecionando os elementos dos modelos de detalhamento de componente

179 163 Os retângulos na Figura 5.20 representam as seleções dos elementos que o projetista considerou necessários para a construção do modelo de detalhamento do componente A1A2A3, apresentado na Figura O retângulo na Figura 5.21 representa o elemento adicionado no modelo de Detalhamento de Atividade aplicando-se a primeira regra. O Sistema X auxilia a execução da atividade A1A2A3. Figura 5.21 Modelo de Detalhamento de uma atividade utilizando a primeira e segunda regra. Os passos realizados para a construção do modelo detalhado do componente abstrato são os mesmos para a construção do modelo detalhado do componente refinado. Para garantir a conformidade entre os modelos criados através da primeira e de segunda regra, é necessário que os elementos adicionais e os elementos escolhidos não interfiram nas decisões de projeto tomadas em outras transformações de Detalhamento de Atividade de outras atividades e nas Transformações de Abstração e Refinamento aplicadas sobre o processo de negócio no qual a atividade pertence. Por exemplo, não é permitido que o projetista: (i) adicione um elemento de informação H (Cluster) como entrada para uma atividade X se a sua antecessora não produz tal informação e não há nenhum sistema computacional associado à atividade X que produza a informação H e; (ii) selecione uma entidade organizacional como responsável pela atividade X sendo que tal entidade foi eliminada na Transformação de Abstração. Por fim, vale ressaltar, que a Transformação de Detalhamento de Atividade é aplicada somente nas atividades que compõem o modelo comportamental do sistema computacional. Logo, as atividades que foram consideradas totalmente manuais na parametrização de automatização não serão considerados na Transformação de

180 164 Detalhamento de Atividade. Os detalhes sobre a parametrização de automatização são apresentados na seção Parametrizações das Transformações Esta seção apresenta as parametrizações utilizadas nas transformações propostas na abordagem de desenvolvimento orientado a modelos. A seção apresenta as parametrizações chamadas de Parametrização de Automatização, pois permitem ao projetista definir o grau de automatização de uma determinada atividade do modelo comportamental. A seção apresenta a parametrização chamada de Parametrização Organizacional. Tais parametrizações permitem ao projetista definir quais elementos organizacionais serão utilizados no sistema orientado a processos de negócio Parametrização de Automatização A Parametrização de Automatização (PA) permite ao projetista definir se uma atividade é totalmente automatizada, gerenciada ou totalmente manual. O projetista define uma atividade como totalmente automatizada quando não há a necessidade da intervenção humana para a execução da atividade, ou seja, a atividade é executado de forma automática pelo sistema computacional. Ao fim da execução da atividade, o fluxo do processo é encaminhado para a próxima atividade. Desta forma, por exemplo, o projetista pode definir que a atividade será executado por um serviço ou por um sistema de workflow. A Figura 5.22 apresenta um exemplo de definição de uma atividade como sendo totalmente automatizada.

181 165 Figura 5.22 Transformação de automatização: Atividade totalmente automatizada. Quando uma atividade é totalmente automatizada é necessário que o projetista defina o sistema computacional 9 que será o novo responsável pela conclusão da atividade automatizada. Após essa etapa, será criada uma raia no Modelo Comportamental do Sistema Computacional para representar que o sistema computacional escolhido é o responsável pela atividade automatizada, como mostra a Figura Caso o projetista escolha automatizar a atividade de um responsável que não possua nenhuma outra atividade, a não ser a que está sendo automatizada, a transformação exclui a raia do responsável no modelo Comportamental do Sistema Computacional. Como ilustrado na Figura 5.23, o Position Participante B foi excluído do modelo Comportamental do Sistema Computacional e foi criada a raia para o Application System Sistema de Workflow X como responsável pela atividade automatizada B. 9 Em relação ao ARIS Method, o projetista poderia definir que a atividade ou componente é de responsabilidade de um tipo de sistema computacional (Application System Type) ou de uma classe de aplicações (Application System Class).

182 166 Figura 5.23 Transformação de automatização: automatização de atividades para responsáveis com mais de uma atividade. O projetista define uma atividade como gerenciada quando há a necessidade de uma ação humana para informar que a atividade foi executada e, assim, o fluxo do processo é encaminhado para o próximo componente do modelo comportamental. A Figura 5.24 apresenta um exemplo da definição do nível acompanhada/gerenciada para uma atividade do processo de negócio. A atividade B da Figura 5.24 foi definida como gerenciada pelo projetista através da parametrização de automatização. Desta forma, o projetista definiu que a atividade (atividade C) será executada quando o Participante B confirmar no sistema que a atividade B foi concluída. A atividade dentro do retângulo continuo é considerada como gerenciada. Figura Transformação de automatização nível: Acompanhada/gerenciada.

183 167 O projetista define uma atividade como totalmente manual quando essa não pertencerá ao sistema computacional em desenvolvimento, ou seja, não é necessário nem mesmo que a sua execução seja registrada no sistema em desenvolvimento. A Figura 5.25 apresenta um exemplo da definição do nível totalmente manual para uma atividade do processo de negócio. Uma atividade em branco é considerada como totalmente manual. Figura 5.25 Transformação de automatização nível: Totalmente manual. Quando uma atividade é definida como totalmente manual o projetista tem que ter em mente que o fluxo das informações do sistema computacional não irá passar por esta atividade e, sim, para a próxima atividade que não seja totalmente manual. A Figura 5.26 demonstra o desvio do fluxo de informação devido à atividade B ser uma totalmente manual. Figura Desvio do fluxo de informação. Ao definir que uma atividade será totalmente manual, o projetista deve garantir que as informações produzidas nessa atividade estarão no sistema computacional em desenvolvimento, caso tais informações sejam úteis.

184 Parametrização Organizacional A Parametrização Organizacional possibilita ao projetista manipular as entidades organizacionais presentes nos modelos organizacionais e assim identificar os atores que estarão presentes no sistema computacional em realização. Cada entidade organizacional manipulada pela parametrização organizacional está associada a uma ou mais atividades do modelo comportamental do sistema em realização. Os modelos organizacionais são utilizados para descrever as entidades organizacionais e seus relacionamentos. Da mesma forma que os demais modelos das Arquiteturas Organizacionais de TI, os modelos organizacionais, na sua maioria, não são criados para serem utilizados em desenvolvimento de software. Desta forma, é necessário que o projetista aplique decisões de projetos sobre tais modelos, para adequá-los ao sistema computacional em desenvolvimento. Os elementos organizacionais são divididos em duas classes: Papéis Sociais (Social Agent) e Agentes (Human Agent, Social Agent e Artificial Agent). Em relação ao ARIS os papéis sociais são representados pelos elementos Position, Person Type e Position Description e os Agentes são representados por Organizational Unit, Group, External Person e Internal Person. Para exemplificar a utilização da Parametrização Organizacional, imagine que exista um modelo de processo de negócio no qual o papel social Cliente (representado pelo elemento Person Type) é um de seus participantes. Conforme apresentado na Figura 5.27, o Cliente é instanciado pela unidade organizacional Recursos Humanos (Organizational Unit) e pelo Gerente (Position) da unidade organizacional Produção (Organizational Unit). Figura Exemplo de utilização da transformação organizacional com papel social

185 169 Através da Transformação Organizacional o projetista pode definir: (i) que todos os elementos organizacionais que possuem o relacionamento de performs como papel social Cliente no modelo serão atores no sistema, conforme apresentado Figura 5.27 (i); (ii) que apenas o Gerente da unidade organizacional de Produção terá permissão de instanciar o papel de Cliente no sistema, conforme apresentado na Figura 5.27 (ii); ou (iii) apenas a unidade organizacional de Recursos Humanos irá instanciar o papel de Cliente no sistema, conforme apresentado na Figura 5.27 (iii). Continuando com a exemplificação, caso o projetista escolha a opção (iii) da Figura 5.27, a parametrização organizacional permite ao projetista definir quais entidades organizacionais da unidade organizacional Recursos Humanos irão instanciar o papel Cliente no sistema computacional. Por exemplo, o projetista pode definir que apenas o Analista de Recursos Humanos dessa unidade organizacional poderá instanciar o papel Cliente no sistema computacional, como apresentado na Figura CONCLUSÃO Figura Exemplo de definição de papéis do sistema. Este capítulo apresentou a nova abordagem de Desenvolvimento Orientada a Modelos que utiliza modelos das Arquiteturas Organizacionais de TI para desenvolvimento de sistemas computacionais orientados a processos de negócio. A primeira característica da abordagem proposta que difere da grande parte das abordagens atuais de Desenvolvimento Orientado a Modelos é a utilização adequada da semântica dos modelos utilizados, afinal parte das abordagens atuais considera apenas os aspectos comportamentais de controle de fluxo em EPCs.

186 170 Outra característica fundamental da abordagem apresentada neste capítulo é que todas as transformações pré-definidas na abordagem são parametrizadas. Essa é uma forma de permitir que o projetista aplique as decisões de projeto sobre os modelos utilizados no desenvolvimento do sistema computacional. A terceira, e última, característica particular desta abordagem é a divisão clara do processo de desenvolvimento em etapas independente e dependente de plataforma. Essa divisão no processo de desenvolvimento possibilita ao projetista separar a decisões de projeto no nível independente e dependente de plataforma, evitando a contaminação dos modelos de processos de negócio com interesses de plataformas de realização. No nível independente de plataforma o projetista pode produzir um conjunto de modelos que visa retratar diversos aspectos que o sistema computacional deve possuir. No nível dependente de plataforma o projetista utiliza os modelos produzidos no nível independente de plataforma e aplica as transformações para realizar os sistemas computacionais na plataforma tecnológica escolhida.

187 171 CAPÍTULO 6 PROVA DE CONCEITOS 6.1 INTRODUÇÃO Este capítulo apresenta a prova de conceitos da abordagem de Desenvolvimento Orientado a Modelos proposta no Capítulo 5. Para a prova de conceitos foi desenvolvido parte de um sistema de workflow utilizando a abordagem proposta neste trabalho. O sistema de workflow visa automatiza o processo denominado Triar pacientes para admissão no setor, que ocorre em um determinado hospital público da região da Grande Vitória (Vitória, Espírito Santo) (CARDOSO, 2009). De forma sucinta, esse processo busca selecionar pacientes com doenças reumatológicas para que os mesmos ingressem no setor de reumatologia do hospital de maneira a receber tratamento adequado para sua enfermidade. Os detalhes sobre esse processo estão apresentados em (CARDOSO, 2009). Obedecendo aos princípios da abordagem proposta de Desenvolvimento Orientado a Modelos, o sistema de workflow foi dividido em etapas do nível independente e dependente de plataforma. No nível independente de plataforma, foi realizada uma série de transformações que adéqua os modelos produzidos, para descrever o processo de negócio Triar pacientes para admissão no setor, às decisões de projeto tomadas pelo projetista do sistema computacional. Para a seleção e parametrização das transformações desse nível, foi desenvolvido um metamodelo que permite ao projetista construir modelos que descrevam as transformações e suas parametrizações; e selecionar em quais modelos as transformações serão aplicadas. A seção apresenta o metamodelo de seleção e parametrização de transformações do nível independente de plataforma. No nível dependente de plataforma, as transformações transformarão os modelos gerados no nível independente de plataforma em artefatos tecnológicos. Neste trabalho, tais transformações produziram um modelo jpdl. Um modelo jpdl é uma

188 172 especificação de um processo para a execução no framework JBOSS jbpm (CUMBERLIDGE, 2007). O JBOSS jbpm é um sistema de gerenciado de fluxo de trabalho (workflow). O modelo jpdl é um documento XML que permite expressar tarefas, eventos e outros elementos de um processo de negócio executável. O capítulo está organizado da seguinte forma: a seção 6.2 apresenta a implementação da abordagem de Desenvolvimento Orientado a Modelos proposta neste trabalho, a seção 6.3 apresenta a implementação das transformações, a seção 6.4 apresenta a aplicação das transformações no nível independente de plataforma, enquanto a seção 6.5 apresenta a aplicação das transformações no nível dependente de plataforma. A seção 6.6 apresenta uma discussão sobre as etapas manuais que serão necessárias para finalizar o sistema computacional e a seção 6.7 apresenta o sistema computacional criado a partir da abordagem. Por fim, a seção 6.8 apresenta as conclusões do capítulo. 6.2 IMPLEMENTAÇÃO DA ABORDAGEM PROPOSTA DE DESENVOLVIMENTO ORIENTADO A MODELOS A implementação da abordagem proposta é composta de transformações que estão no nível independente de plataforma (em cinza na Figura 6.1) e no nível dependente de plataforma (em branco na Figura 6.1).

189 173 Figura 6.1 Implementação da Abordagem de Desenvolvimento Orientado a Modelos. A abordagem inicia com a Transformação de Construção de Modelos de Domínio (TCMD). Essa transformação é responsável por construir os modelos do domínio Organizacional, de Processo de Negócio e de Detalhe de atividade a partir de um documento AML (ARIS Markup Language). Um documento AML é um documento XML utilizado para serializar os modelos desenvolvidos dentro da ferramenta de modelagem ARIS Toolset e exportado para que seja utilizado em ferramentas externas. Detalhes sobre o formato AML são apresentado em (SANTOS JR. et al., 2008). A seção apresenta os detalhes da Transformação de Construção de Modelos de Domínio (TCMD).

190 174 Após a construção dos modelos de domínio, o próximo passo é aplicar as decisões de projeto através das Transformações de Abstração, Refinamento e Detalhamento de Atividade apresentadas no Capítulo 5. Desta forma, após a aplicação dessas transformações é gerado o conjunto de modelos que serão usados nas transformações dependentes de plataforma. Por fim, após a construção dos modelos independentes de plataforma, são executadas as transformações do nível dependente de plataforma sobre tais modelos. No caso deste trabalho, as transformação do nível dependente de plataforma geram um modelo jpdl a partir das informações contidas nos modelos independentes de plataforma. A seção apresenta as transformações dependentes de plataforma Transformação de Construção de Modelos de Domínio A Transformação de Construção de Modelos de Domínio é composta das seguintes transformações: Construir AML Refatorado, Construir Modelo Organizacional, Construir Modelo de Processo de Negócio e Construir Modelo de Detalhamento de Atividades. A Figura 6.2 apresenta o conjunto de transformações que são parte da Transformação de Construção de Modelos de Domínio. Figura 6.2 Conjunto de transformações para criar os modelos de domínio organizacional, processo de negócio e detalhamento de atividades do ARIS Method.

191 175 A transformação Construir AML Refatorado é responsável por criar uma instância do metamodelo AML Refatorado 10 a partir de informações de um documento AML exportado da ferramenta ARIS Toolset. A transformação Construir AML Refatorado é uma transformação entre espaços tecnológicos, porque transforma um documento XML em um modelo ECORE preservando o isomorfismo entre documento de origem e modelo de destino (SANTOS JR. et al., 2008). Apesar do modelo AML Refatorado conter informações sobre os modelos desenvolvidos na ferramenta ARIS Toolset, a manipulação dessas informações é onerosa, pois não permite uma distinção clara das entidades contidas nos modelos de domínios do ARIS Method. A distinção entre as entidades de domínio é realizada através de codificações dos valores do atributo de cada classe presente no AML Refatorado. Por exemplo, para identificar se um determinado modelo é do tipo organizacional, é necessário verificar se o valor do atributo Type da classe Model é MT_ORG_CHT. Para que a manipulação das informações seja menos onerosa, é necessário que tal procedimento seja feito no nível de modelo, ou seja, é necessária a construção dos modelos de domínio de processo de negócio, organizacional e detalhamento de atividade a partir das informações contidas no documento AML. As transformações Construir Modelo Organizacional, Construir Modelo de Processo de Negócio e Construir Modelo de Detalhamento de Atividades têm por objetivo, respectivamente, criar instâncias de modelos organizacionais, de processo de negócio e detalhamento de atividades através de informações contidas no modelo AML Refatorado. A partir dos modelos gerados por essas transformações, é possível a manipulação das informações dos modelos utilizando conceitos do domínio de maneira mais direta do que realizar a mesma operação sobre um documento AML. Em (PIUMBINI, 2009) é apresentado em detalhes a implementação do conjunto de transformações que forma a Transformação de Construção de Modelos de Domínio (TCMD). 10 O Metamodelo AML Refatorado é um metamodelo que descreve as entidades e os relacionamentos que estão presentes em um documento AML (SANTOS JR. et al., 2008)..

192 Metamodelo de Seleção e Parametrização das Transformações Independentes de Plataforma O Metamodelo das Transformações Parametrizadas Independentes de Plataforma permite que o projetista crie modelos para representar as transformações de abstração, refinamento e detalhamento de componentes apresentadas no Capítulo 5. A Figura 6.3 apresenta o Metamodelo das Transformações Parametrizadas Independentes de Plataforma. A metaclasse TransformationModel é utilizada para representar um container, ou seja, essa metaclasse é utilizada para conter as metaclasses que representam as transformações. A metaclasse abstrata Transformation representa uma transformação parametrizada que será utilizada para aplicar as decisões de projeto sobre algum modelo de domínio da Arquitetura Organizacional de TI. O meta-atributo name e o meta-atributo modeldomain são utilizados para especificar um nome para a transformação e o nome do modelo sobre o qual a transformação será aplicada. Por exemplo, o projetista pode nomear a transformação de transformação de Abstração em X atribuindo um valor ao parâmetro name e informar que a transformação será aplicada sobre o modelo X atribuindo um valor no atributo modeldomain.

193 Figura 6.3 Metamodelo de Seleção e Parametrização de Transformações Independentes de Plataforma. 177

194 178 O metarelacionamento firsttransformation que ocorre entre Transformation Model e Transformation é utilizada para representar qual a primeira transformação será executada de um conjunto de transformações. O metaautorrelacionamento is predecessor of é utilizado para representar a sequência de transformações que serão executadas durante o processo de construção dos modelos independentes de plataforma. As metaclasses AbstractionTransformation, RefinementTransformation e FunctionTransformation representam as Transformações de Abstração, Refinamento e Detalhamento de Atividade, respectivamente. Com relação a metaclasse AbstractionTransformation, o metarelacionamento definenewtask é utilizado para representar a nova atividade de alto nível (NewTask) que será criada após aplicar a transformação de abstração sobre um componente de processo (SourceComponent). A metaclasse NewParticipant, apresentada na. A Figura 6.3, representa o novo participante que pode ser criado pela transformação de abstração e a metaclasse Participant é utilizada para representar um participante do processo de negócio que será o responsável pela nova atividade abstrata. Figura 6.4 Metamodelo da metaclasse SourceComponent.

195 179 A metaclasses abstrata AutomationLevelTransformation é utilizada para representar os tipos de transformações de automatização. O metarelacionamento definefunction especifica a atividade (instância de Function) que será sujeita a um nível de automação específico através desta transformação. As especializações FullyAutomated, Managed e Manual desta metaclasse representam, respectivamente, os seguintes níveis de automatização: Totalmente Automatizada, Gerenciada e Totalmente Manual. A metaclasse SourceTask, associada à metaclasse RefinementTransformation pelo relacionamento definesourcetask, representa a atividade do processo de negócio que será refinada. A metaclasse NewComponent, apresentada na Figura 6.5, representa o componente que será criado pela transformação de refinamento. Figura 6.5 Metamodelo da metaclasse NewComponent. As metaclasses OrganizationModel e FADModel representam subconjuntos do metamodelo Organizacional e do metamodelo de Detalhamento de Atividade do ARIS Method apresentados nas seções 3.2 e 3.4, respectivamente. Esses subconjuntos são formados por apenas elementos e relacionamentos que tiveram a sua semântica definida na análise ontológica do Capítulo 4. Por exemplo, no caso do metamodelo Organizacional, o relacionamento performs entre Person Type e Location não está presente no subconjunto representado pela metaclasse OrganizationModel.

196 Construtor de Modelos de Seleção e Parametrização de Transformações Independentes de Plataforma O protótipo inclui um plugin na plataforma Eclipse (ECLIPSE, 2008b) que permite ao projetista desenvolver modelos que selecionem e parametrizem as transformações independentes de plataforma. O plugin permite desenvolver os seguintes modelos: processo de negócio, organizacional e detalhamento de atividades do ARIS Method e os modelos de seleção e parametrização de transformações. Para o desenvolvimento do plugin, foi necessário utilizar os metamodelos das linguagens de domínio do ARIS Method (apresentados no Capítulo 3) e os metamodelos de seleção e parametrização de transformações independentes de plataforma (apresentados na seção 6.2.2). Não foram considerados no desenvolvimento do plugin os relacionamentos das linguagens de domínio do ARIS Method que foram considerados desnecessários na análise ontológica, realizada no Capítulo 4. A Figura 6.8 apresenta um exemplo de modelo de seleção e parametrização construído através do plugin. Figura 6.6 Plugin para desenvolvimento de modelos de seleção e parametrização de transformações independentes de plataforma. Como mostra a Figura 6.6, o projetista selecionou e parametrizou três transformações: (i) uma Transformação de Abstração, (ii) uma Transformação de Refinamento e (iii) uma Transformação de Detalhamento de Atividades. A Transformação de Abstração, chamada de Abstração X, cria uma nova atividade (NewTask) chamada de Task X e totalmente automatizada (FullyAutomated). O

197 181 responsável por essa atividade é o Sistema X. A Figura 6.7 apresenta a Transformação de Abstração Abstração X e a parametrização de automatização. Figura 6.7 Transformação de Abstração modelado no plugin. Para indicar sobre qual componente a transformação será aplicada, é necessário que o projetista informe o modelo que representa o SourceComponent no campo Define Source Component, conforme mostrado na Figura 6.8. Figura 6.8 Definindo o Source Component. No caso do exemplo deste trabalho, o modelo que representa o Source Component é chamado de SourceComponent.eepc. Esse modelo contém duas atividades do processo de negócio: Atividade A e Atividade B. A Figura 6.9 apresenta o modelo do Source Component. Figura Modelo SourceComponent.eepc construído no plugin. A segunda transformação modelada pelo projetista é uma Transformação de Refinamento chamada de Refinamento. Como mostrado na Figura 6.10, a Transformação de Refinamento modelada irá construir duas atividades automatizadas (atividade Y e atividade Z) e uma gerenciada (atividade W). As atividades Y e Z serão

198 182 da responsabilidade dos sistemas computacionais Sistema Y e Sistema Z, respectivamente. Figura 6.10 Transformação de Refinamento modelado no plugin. Para indicar sobre qual atividade a Transformação de Refinamento será aplicada, é necessário que o projetista informe o nome da atividade no campo Define Source Task. Como mostrado na Figura 6.11, a Transformação de Refinamento será aplicada sobre a Atividade X do modelo de processo de negócio. Figura 6.11 Definindo o Source Task. Como apresentado na Figura 6.6, a terceira transformação modelada pelo projetista é uma Transformação de Detalhamento de Atividade chamada de Detalhamento da Atividade ABC. Para indicar quais elementos são necessários para uma atividade, é necessário que o projetista crie um modelo de FAD com os tais. Na Figura 6.12 o projetista informou que, para o sistema computacional, somente são necessários os seguintes elementos: Notificação X ( - Information Carrier) e Informação H (Cluster).

199 183 Figura 6.12 Modelo listando os elemento necessários para a atividade ABC. O campo Define FAD Model da Transformação de Detalhamento de Atividade associa o modelo FAD com a transformação, conforme mostrado na Figura Figura 6.13 Definindo o Modelo FAD na Transformação de Detalhamento de Atividade. O plugin permite que o projetista defina a ordem na qual as transformações serão executadas. Primeiro é necessário definir a primeira transformação através do campo First Transformation do elemento Transformation Model. Como mostrado na Figura 6.14, o projetista definiu que a primeira transformação a ser executada será a Abstração X Figura 6.14 Definindo a primeira transformação a ser executada. Por fim, o segundo, e último passo, é a definição em cada uma das transformações sobre qual será a sua sucessora. Para isso, o projetista informa no campo Is Predecessor Of qual transformação será a sucessora da transformação atual. Por exemplo, como mostrado na Figura 6.15, a sucessora da transformação Abstração X será a transformação Refinamento.

200 184 Figura 6.15 Definindo a transformação sucessora Transformações Dependentes de Plataforma Neste trabalho as transformações dependentes de plataforma são responsáveis por construir o modelo jpdl do sistema de workflow. Essa construção será feita através de transformações que utilizam as informações contidas nos modelos gerados pelas transformações do nível independente de plataforma. A Figura 6.16 apresenta as transformações utilizadas para o desenvolvimento do modelo jpdl. Figura 6.16 Transformações no nível dependente de plataforma deste trabalho. A Transformação Comportamental (TC) é responsável por definir no modelo jpdl as atividades (Task ou Java), as relações (Transition) entre as atividades e os principais atores (Swimlanes) do processo de negócio. Isso é feito através da análise das informações contidas no modelo EPC gerado pelas transformações do nível independente de plataforma. Por exemplo, através da identificação do elemento Function (e seus elementos notacionais) no modelo comportamental, gerado no níve

201 185 independente de plataforma, é possível identificar uma atividade (Task ou Java) que estará presente no modelo jpdl, como demonstrado na seção A Transformação de Atividade (TA) utiliza as informações contidas nos modelos de detalhamento de atividade para complementar o modelo jpdl construído pela Transformação Comportamental (TC). Por exemplo, essa transformação pode utilizar o relacionamento must be informed about para criar atividade de envio de no jpdl, conforme mostrado na seção Por fim, a Transformação Organizacional (TO) utiliza as informações contidas nos modelos organizacionais gerados pelas transformações do nível independente de plataforma para complementar o modelo jpdl. Por exemplo, através dos modelos organizacionais criados no nível independente de plataforma, a transformação pode: (i) criar atividades de notificação para usuários do sistema no modelo jpdl, ao identificar o relacionamento must be informed about; ou (ii) adicionar os atores no swimlanes ao identificar o relacionamento performs. 6.3 IMPLEMENTAÇÃO DAS TRANSFORMAÇÕES Para automatizar a abordagem proposta na Figura 6.1 foi desenvolvida uma aplicação em Java que permite que o projetista produza um modelo jpdl a partir de um documento AML e de um conjunto de modelos de seleção e parametrização de transformações. A Figura 6.17 apresenta a arquitetura dessa. Figura 6.17 Arquitetura de Automatização das Transformações.

202 186 A aplicação desenvolvida é composta por três funcionalidades principais: i. Construtor de Modelos de Domínio ARIS: é o responsável por transformar o documento AML, exportado da ferramenta de modelagem ARIS Toolset, em modelos de domínio do ARIS Method. Para o desenvolvimento dessa API foi utilizada a abordagem apresentada na seção ii. Modulo de Transformações Independentes de Plataforma: é o responsável por aplicar as transformações descritas nos Modelos de Transformação sobre os modelos de domínio do ARIS Method. Após aplicar todas as transformações descritas nos Modelos de Transformações, a Implementação das Transformações Independente de Plataforma gera um conjunto de modelos transformados. Para o modelo de transformações independentes de plataforma foram utilizados os metamodelos de domínio do ARIS Method apresentados no Capítulo 3 e o metamodelo de transformações apresentado na seção iii. Modulo de Transformações Dependentes de Plataforma: é o responsável por transformar o conjunto de modelos transformados, produzido pelas transformações independentes de plataforma, em um documento jpdl. Para isso, foram implementadas as transformações comportamental, organizacional e de atividades descritas na seção Para facilitar o desenvolvimento do documento jpdl, foi construído um metamodelo da linguagem jpdl, cujas principais metaclasses são apresentadas na Figura No metamodelo apresentado na Figura 6.18 a metaclasse Process representa o processo de negócio que será construído no modelo jpdl. As metaclasse End e Start representam, respectivamente, os eventos iniciais e finais do modelo de processo implementado no jpdl. A metaclasse Java representa atividades realizadas automaticamente e a metaclasse Task representa uma atividade realizada por um ator do sistema. A metaclasse State representa um estado do processo de negócio. As metaclasses Fork, Join e Exclusive são utilizadas para representar, respectivamente, uma divisão do fluxo em dois ou mais caminhos que devem executar as atividades em paralelo, uma união de dois ou caminhos do fluxo em apenas um caminho e uma escolha exclusiva entre dois ou mais caminhos do processo de negócio.

203 187 Figura 6.18 Fragmento do metamodelo da linguagem jpdl. Por fim, é importante ressaltar que o aplicativo que concretiza a arquitetura apresentada na Figura 6.17 foi desenvolvido utilizando objetos que representavam as entidades do ARIS Method, Metamodelo de Transformações e do metamodelo do jpdl. Em outras palavras, com exceção da transformação do documento AML para modelo AML e da transformação modelo jpdl para documento jpdl, a aplicação foi desenvolvida seguindo uma abordagem orientada a modelos. Isso possibilitou maior agilidade no desenvolvimento da aplicação, pois houve manipulação de informações no nível de modelos e não no nível de documento. 6.4 APLICAÇÃO DAS TRANSFORMAÇÕES NO NÍVEL INDEPENDENTE DE PLATAFORMA Esta seção apresenta o conjunto de decisões de projeto e as transformações no nível independente de plataforma aplicadas sobre os modelos do processo Triar pacientes para admissão no setor. A Figura 6.19 e a Figura 6.20 apresentam o processo de negócio Triar pacientes para admissão no setor.

204 188 Médico Paciente Recepcionista Orientar pacientes com fibromialgia Realizar procedimentos Encaminhamento de médico externo realizado Encaminhamento de médico interno de outra especialidade realizado Exames laboratoriais realizados Necessidade de retorno para a triagem Necessidade de retorno para a triagem Fornecer cartão de consulta ao recepcionista Elaborar ficha do paciente Anexar ficha do paciente ao prontuário médico Investigar histórico clínico do paciente Relatar sintomas Investigar histórico pessoal do paciente Investigar histórico familiar do paciente Realizar exame físico Decidir necessidade de exames para confirmar hipótese de diagnóstico Necessidade de exames laboratoriais não detectada Necessidade de exames laboratoriais detectada Verificar realização prévia de exames laboratoriais Exames laboratoriais realizados previamente Exames laboratoriais não realizados previamente Solicitar exames laboratoriais Registrar folha de faturamento no sistema Registrar no sistema data do agendamento de retorno Analisar resultados dos exames Folha de faturamento registrada no sistema Resultados dos exames analisados Figura 6.19 Triar pacientes para admissão no setor (Parte 1).

205 189 Elaborar hipótese de diagnóstico Verificar fechamento do diagnóstico Diagnóstico fechado Diagnóstico não fechado Verificar existência de doença reumatológica Encaminhar paciente ao diagnóstico Agendar ambulatório de diagnósticos para paciente Existência de patologia reumatológica identificada Verificar complexidade da doença reumatológica Ausencia de patologia reumatológica Fornecer recomendações complementares ao paciente Conceder alta ao paciente Registrar folha de faturamento no sistema Registrar no sistema data do agendamento de retorno Diagnosticar quadro de saúde Existência de patologia reumatológica de baixa complexidade Realizar intervenção terapêutica através de encaminhamento a ambulatório Existência de patologia reumatológica de alta complexidade Expor ao paciente a hipótese de diagnóstico Registrar folha de faturamento no sistema Necessidade de encaminhamento ao grupo de orientação de fibromialgia Encaminhar paciente para grupo de orientação de fibromialgia Necessidade de realização de procedimento identificada em ambulatório Encaminhar paciente para realização de procedimentos Necessidade de encaminhamento ao ambulatório de reabilitação Encaminhar paciente para ambulatório de reabilitação Iniciar elaboração de terapêutica Decidir ambulatório de seguimento mais adequado no momento Folha de faturamento registrada no sistema Agendar ambulatório de procedimentos para paciente Ambulatório de procedimentos agendado Agendar ambulatório de reabilitação para paciente Ambulatório de reabilitação agendado Necessidade de Necessidade de Necessidade de encaminhamento encaminhamento encaminhamento ao ambulatório de ao ambulatório de ao ambulatório de colagenosas fibromialgia osteometabólicas Reencaminhar paciente Reencaminhar paciente Reencaminhar paciente para ambulatório para ambulatório para ambulatório de colagenosas de fibromialgia de osteometabólicas Necessidade de Necessidade de encaminhamento encaminhamento ao ambulatório de ao ambulatório de artrites reumatologia infantil Reencaminhar paciente Reencaminhar paciente para ambulatório para ambulatório de reumatologia de artrites infantil Agendar ambulatório Agendar ambulatório de colagenosas de fibromialgia para paciente para paciente Agendar ambulatório de osteometabólicas para paciente Agendar ambulatório de artrites para paciente Agendar ambulatório de reumatologia infantil para paciente Registrar folha de faturamento no sistema Registrar no sistema data do agendamento de retorno Realizar ambulatório de colagenoses Realizar ambulatório de osteometabólicas Realizar ambulatório de fibromialgia Realizar ambulatório de artrites Realizar ambulatório de reumatologia infantil Registrar folha de faturamento no sistema Pacientes com fibromialgia orientados Procedimentos realizados Figura Triar pacientes para admissão no setor (Parte 2). Orientar pacientes com fibromialgia Realizar procedimentos Transformações Comportamentais Esta seção apresenta as decisões de projeto e as transformações que permitiram definir quais atividades do processo de negócio Triar pacientes para admissão no setor serão incluídas no sistema de workflow. A Tabela 6.1 apresenta os detalhes das transformações comportamentais que construíram o modelo comportamental apresentado na Figura 6.21 e Figura A coluna Atividades Abstraidas apresenta as atividades do processo de negócio que serão abstraídas na transformação comportamental, a coluna Responsável apresenta o responsável por cada atividade do processo de negócio que será abstraída, a coluna

206 190 Nova Atividade apresenta a nova atividade criada pela transformação comportamental, a coluna Responsável da Nova Atividade apresenta o responsável pela nova atividade criada e a coluna Nível de Automatização descreve o quanto a atividade será automatizada.o detalhamento sobre as decisões de projeto para cada transformação é apresentada no Capítulo 8APÊNDICE A. Tabela 6.1 Transformações de Abstração. Atividades Abstraidas Responsável Nova Atividade Responsável da Nova Atividade Fornecer cartão de consulta ao Paciente recepcionista Buscar ficha do Elaborar ficha do paciente Recepcionista paciente Anexar ficha do paciente ao Recepcionista prontuário médico Relatar Sintomas Paciente Investigar histórico clínico do paciente Investigar histórico pessoal do paciente Examinar o Investigar histórico familiar do Médico paciente paciente Médico Realizar exame físico Decidir necessidade de exames para confirmar hipótese de diagnóstico Solicitar exames laboratoriais Médico Registrar folha de faturamento no Solicitar exames Sistema de Solicitação sistema Recepcionista laboratoriais de exames Registrar no sistema data do agendamento de retorno Elaborar hipótese de diagnóstico Elaborar Verificar fechamento do Médico diagnóstico Méidco diagnóstico preliminar Encaminhar paciente ao Encaminhar diagnóstico Médico paciente e Agendar ambulatório de Médico agendar diagnóstico para paciente ambutório Registrar folha de faturamento no Recepcionista Nível de Automatização Gerenciada Gerenciada Totalmente Automatizada Gerenciada Gerenciada

207 191 sistema Registrar no sistema data do agendamento de retorno Fornecer recomendações complementares ao paciente Conceder alta ao paciente Registrar folha de faturamento no sistema Realizar intervenção terapêutica através de encaminhamento a ambulatório Encaminhar paciente para grupo de orientação fibromialgia Encaminhar paciente para realização de procedimentos Agendar ambulatório de procedimentos para pacientes Encaminhar paciente para ambulatório de reabilitação Agendar ambulatório de reabilitação para paciente Registrar folha de faturamento no sistema Médico Recepcionista Médico Recepcionista Conceder alta Médico Gerenciada Encaminhar paciente para Médico Gerenciada ambulatório

208 O Médico Sistema de solicitação de exames Recepcionista Orientar pacientes com fibromialgia Realizar procedimentos Encaminhamento de médico externo realizado Encaminhamento de médico interno de outra especialidade realizado Exames laboratoriais realizados Necessidade de retorno para a triagem Necessidade de retorno para a triagem Examinar o paciente Buscar ficha do paciente Necessidade de exames laboratoriais não detectada Necessidade de exames laboratoriais detectada Verificar realização prévia de exames laboratoriais Exames laboratoriais realizados previamente Exames laboratoriais não realizados previamente Analisar resultados dos exames Solicitar exames laboratoriais SYS SYS Folha de faturamento registrada no sistema Resultados dos exames analisados Elaborar diagnóstivo preliminar Figura Modelo de estrutural do sistema de workflow (Parte 1).

209 193 Elaborar diagnóstivo preliminar Diagnóstico fechado Diagnóstico não fechado Verificar existência de doença reumatológica Encaminhar paciente e agendar ambulatório Existência de patologia reumatológica identificada Ausencia de patologia reumatológica Paciente encaminhado e ambulatório agendado Diagnosticar quadro de saúde Verificar complexidade da doença reumatológica Conceder alta Folha de faturamento registrada no sistema Existência de patologia reumatológica de baixa complexidade Existência de patologia reumatológica de alta complexidade Encaminhar paciente para ambulatório Explicitar o diagnóstivo ao paciente Pacientes com fibromialgia orientados Procedimentos realizados Encaminhar para ambulatóio de colagenoses Encaminhar para ambulatório de osteometabólicas Encaminhar para ambulatório de fibromualgia Encaminhar para ambulatório de atrites Encaminhar para o ambulatório de reumatologia infantil Orientar pacientes com fibromialgia Realizar procedimentos Realizar ambulatório de colagenoses Realizar ambulatório de osteometabólicas Realizar ambulatório de fibromialgia Realizar ambulatório de artrites Realizar ambulatório de reumatologia infantil Figura Modelo de estrutural do sistema de workflow (Parte 2).

210 Transformações de Atividades Nesta etapa do projeto, o projetista deve definir quais elementos são necessários para cada atividade do processo de negócio já existente ou para cada nova atividade do processo de negócio criado pelas Transformações de Abstração e de Refinamento. Em outras palavras, neste momento o projetista deve aplicar decisões de projeto que definem quais informações são necessárias e quais informações são produzidas por cada atividade, quais notificações que devem ser feitas pela atividade, quais regras de negócio devem ser consideradas e assim por diante. Para que seja possível a definição dos detalhes de cada atividade, o projetista: (i) construir uma transformação de detalhamento de componente para os componentes que não foram construídos pelas transformações de Abstração e Refinamento e; (ii) construir modelos de detalhamento para os componentes que foram criados pelas transformações de Abstração e Refinamento. Para exemplificar o primeiro caso, será utilizado o FAD da atividade Analisar resultados dos exames. Nesta atividade, o projetista definiu que o documento Exame do paciente e suas informações (o cluster Informações do exame ) são necessários para a execução da atividade e que a atividade deve gerar a informação Resultado da análise do exame. Por fim, a decisão de projeto define que o Sistema do laboratório irá auxiliar na execução da atividade no sistema computacional em desenvolvimento. Os retângulos pretos na Figura 6.23 demonstram a decisão de projeto sobre o FAD da atividade Analisar resultados dos exames. Médico Paciente Sistema do laboratório must be informed about Informações do exame Analisar resultados dos exames Resultado da análise do exame Exame do paciente Figura Modelo Detalhado da atividade Analisar resultados dos exames parametrizado.

211 195 Para exemplificar o segundo caso, no qual é necessário criar os modelos de detalhamento de atividades, serão utilizadas como exemplos as novas atividades: Solicitar exames laboratoriais e Encaminhar paciente para ambulatório. Ao criar os modelos de detalhamento das atividades criadas pelas transformações de Abstração e Refinamento, o projetista não pode infringir quaisquer decisões de projeto que já foram aplicadas. Por exemplo, no caso da atividade Solicitar exames laboratoriais o projetista deve modelar o Sistema de solicitação de exames como o responsável pela atividade, pois isso foi definido nas transformações comportamentais, como discutido na seção 5.3. No caso da atividade Solicitar exames laboratoriais é importante observar que a transformação que a criou, definiu que tal atividade é totalmente automatizado e, assim, o responsável por tal atividade é um sistema computacional (Sistema solicitação de exames, conforme mostrado na Figura 6.24). Logo, tal decisão de projeto deve estar presente no modelo de detalhamento desta atividade. O projetista definiu que a atividade Solicitar exames laboratoriais terá como entrada as informações do prontuário médico do paciente (representado pelo cluster Informações do prontuário médico), provido pelo Sistema de controle de paciente, e produzirá como saída a Solicitação do exame laboratorial e Notificação sobre o atendimento do paciente. Estes elementos não estão presentes em nenhum dos FADs das atividades abstraídas que originaram a nova atividade Solicitar exames laboratoriais, mas foram incluídos pela necessidade identificada.

212 196 Sistema de solicitação de exames must be informed about Paciente Sistema de controle de pacientes Sistema do laboratório Prontuário médico Informações do prontuário médico Solicitar exames laboratoriais SYS SYS Informações da solicitação do exame laboratorial Solicitação do exame laboratórial Regras da solicitação Informações sobre o atendimento do paciente Informações sobre o agendamento do paciente Notificação sobre o atendimento do paciente Figura FAD criado para o componente Solicitar exames laboratoriais. Observe que foi usado um objeto do tipo Business Rule denominado Regras de solicitação. Esse objeto foi incluído no modelo para definir as regras de negócio necessárias nesta atividade como, por exemplo, quando o Paciente deve ser notificado sobre a Solicitação do exame laboratorial. Os demais elementos presentes no modelo acima, foram retirados das atividades abstraídas que originaram o componente. A Figura 6.25 apresenta o modelo FAD construído para a nova atividade Encaminhar paciente para ambulatório. Como pode ser observado, o projetista definiu que: i. as informações contidas no prontuário médico do paciente são necessárias para a execução da atividade abstraída ; ii. a atividade deve enviar uma ou mais notificações para os grupos de ambulatórios; iii. os sistemas Sistema de agendamento de ambulatório e Sistema de controle de paciente auxiliam na execução do componente; e iv. a atividade possui uma regra de negócio que descreve o seu comportamento.

213 197 Médico Grupo de orientação fibromialgia Grupo do ambulatório procedimentos Grupo do ambulatório de reabilitação Sistema de agendamento de ambulatório Sistema de controle de pacientes must be informed about must be informed about must be informed about Informações do prontuário médico Encaminhar paciente para ambulatório Informação do agendamento do ambulatório fibromialgia Prontuário médico Notificação de encaminhamento para o grupo de fibromialgia Regras para encaminhar paciente Informação do agendamento do ambulatório de procedimentos Notificação de encaminhamento para o ambulatório de procedimentos Informação do agendamento do ambulatório de reabilitação Notificação de encaminhamento para o ambulatório de reabilitação Informações sobre o atendimento do paciente Notificação sobre o atendimento do paciente Figura 6.25 FAD criado para o componente Encaminhar paciente para ambulatório Transformações Organizacionais As transformações organizacionais permitem que o projetista aplique as decisões de projeto nos modelos organizacionais com o objetivo de definir quais entidades organizacionais serão transformadas em atores no sistema de workflow em desenvolvimento. Essas transformações também definem o relacionamento entre os atores do sistema computacional. As Transformações Organizacionais são transformações que possuem a Parametrização Organizacional. A primeira transformação organizacional define quais entidades organizacionais poderão executar o papel de Recepcionista no sistema computacional em desenvolvimento. Conforme mostrado na Figura 6.26, somente as pessoas que executam a posição Auxiliar Administrativo podem executar o papel de Recepcionista no sistema computacional em desenvolvimento.

214 198 Figura 6.26 Parametrização do modelo organizacional Recepcionista. O projetista definiu que, dentre todas as especializações de médicos presentes no hospital, somente os médicos que executam a posição Reumatologista podem instanciar o papel Médico no sistema de workflow que está sendo desenvolvido. A Figura 6.27 mostra a decisão de projeto aplicada sobre o modelo organizacional do Position Description Médico. Figura Parametrização do modelo organizacional Médico.

215 199 Por fim, o projetista decidiu que somente as pessoas que desempenharem o papel de Enfermeira chefe no Grupo do ambulatório de reabilitação receberão a notificação do agendamento de um paciente feito pelo Médico na atividade Encaminhar paciente para ambulatório. A Figura 6.28 demonstra a decisão de projeto sobre o modelo organizacional Grupo do ambulatório de reabilitação. Figura 6.28 Paramtrização do modelo organizacional Grupo do ambulatório de reabilitação. Por fim, observe na figura acima, que a decisão de projeto aplicada sobre o modelo organizacional também inclui a seguinte condição: Somente as pessoas que desempenham a posição Enfermeira na organização podem desempenhar o papel Enfermeira chefe no grupo do ambulatório de reabilitação. Isso é uma restrição imposta pela organização e que deve estar presente no sistema computacional em desenvolvimento. Tais regras da decisão de projeto devem estar presentes na transformação organizacional que auxilia no desenvolvimento do sistema computacional. 6.5 APLICAÇÃO DAS TRANSFORMAÇÕES NO NÍVEL DEPENDENTE DE PLATAFORMA As transformações do nível dependente de plataforma possuem o mesmo princípio das transformações do nível independente de plataforma, ou seja, a partir de um modelo de origem e das decisões de projeto é construído o modelo de destino. No caso das

216 200 transformações do nível de plataforma de realização, os modelos de origem são os modelos produzidos nas transformações do nível independente de plataforma e o modelo de destino é um modelo jpdl do JBOSS jbpm. Apesar das transformações do nível de dependência de plataforma, neste trabalho, serem transformações tecnológicas, o conhecimento da semântica dos elementos contidos nos modelos do domínio de origem e do domínio de destino é necessário. Afinal, através do conhecimento preciso dos conceitos presentes em cada domínio é possível a construção de transformações que utilizem de maneira mais adequada as informações contidas no modelo de origem e, assim, gerar modelos no domínio de destino que sejam compatíveis com os conceitos presentes no domínio de origem. Para uma melhor utilização dos conceitos presentes nos modelos de origem, as transformações do nível dependente de plataforma foram divididas em 3 tipos: (i) Transformações comportamentais; (ii) Transformações de atividade; e (iii) Transformações organizacionais. As transformações comportamentais utilizam as informações contidas no modelo comportamental, construído na seção 6.4.1, para produzir o modelo do processo em jpdl. Esse modelo é o que define a sequência de atividades e os responsáveis pelas mesmas. As transformações de atividade utilizam as informações contidas nos modelos de detalhamento de atividade para complementar o modelo jpdl desenvolvido na transformação comportamental. As transformações organizacionais utilizam as informações contidas nos modelos organizacionais produzidos na seção 6.5.3, com a finalidade de informar as entidades organizacionais que serão atores no sistema. Após a execução das transformações do nível dependente de plataforma, o projetista possui um modelo jpdl que retrata todas as decisões de projeto que foram tomadas sobre os modelos da Arquitetura Organizacional de TI. Desta forma, o modelo

217 201 produzido está de acordo com diversos aspectos organizacionais e com as decisões de projeto. Por fim, o desenvolvedor deve complementar as lacunas deixadas pelas transformações. Por exemplo, a implementação das atividades totalmente automatizadas e das telas utilizadas para realizar a interface entre o usuário e o sistema computacional Transformação Comportamental A transformação comportamental do nível de dependência de plataforma é composta de seis etapas especializadas. Cada uma dessas etapas trabalha em conjunto para o desenvolvimento do modelo jpdl do processo Triar pacientes para admissão no setor. A primeira etapa da transformação comportamental é utilizada para criar as raias das entidades organizacionais no jpdl. Para isso, é necessário identificar as entidades organizacionais que são responsáveis por componentes de processo com nível gerenciado. A identificação dos responsáveis é feita verificando a existência do relacionamento carries out entre uma entidade organizacional com um componente do processo (representado pela entidade Function). Para cada entidade organizacional identificada na primeira etapa, é criado o elemento <swimlane> no jpdl. Esse elemento representa quais usuários ou conjunto de usuários são responsáveis por executar um ou mais atividades no JBPM. A Figura 6.29 apresenta o resultado do primeiro passo. <swimlane name="medico"/> <swimlane name="recepcionista"/> Figura 6.29 Interpretação do responsáveis pelas atividades no jdpl. O jpdl não permite a criação de <swimlane> para entidades computacionais responsáveis por atividades automatizadas no processo de negócio. Todas as atividades que são da responsabilidade de uma entidade computacional serão executadas automaticamente pelo JBOSS jbpm.

218 202 A segunda etapa é responsável por criar os elementos que representam o evento inicial (<start>) e final (<end>) no modelo jpdl, através da identificação das entidades Start Event e End Event no modelo de processo. A linguagem jpdl possui uma restrição sob os eventos iniciais: não pode existir mais de um evento inicial no modelo. Não existem restrições desse tipo para os eventos finais. Para se adequar à restrição do evento inicial, a transformação cria um evento inicial (start) seguindo de um decision. Para cada evento inicial contido no processo será criado um state. Desta forma, o modelo jpdl contem os seguintes states: Encaminhamento de médico externo realizado, Encaminhamento de médico interno de outra especialidade realizado, Exames laboratoriais realizados e Necessidade de retorno para a triagem. A Figura 6.30 apresenta como os eventos iniciais do processo de negócio são representados no jpdl. Como pode ser observado na Figura 6.30, para cada evento inicial do modelo de processo foi criado um state e uma transition na decision chamada decisionstartevent. Cada transition da decisionstartevent possui uma expressão (expr) que irá definir para qual estado (evento inicial) o processo irá seguir. Por exemplo, caso o valor da expressão seja encaminhamentomer, isso indicará que foi o evento inicial Encaminhamento do médico externo realizado que iniciou o processo de negócio.

219 203 <start name="inicio"> <transition to= decisionstartevent /> </start> <decision name= decisionstartevent > <transition to= Encaminhamento do medico externo realizado > <condition expr= #{conten==encaminhamentomer} > </transition> <transition to= Encaminhamento do medico interno de outra especialidade realizado > <condition expr= #{conten==encaminhamentomier} > </transition> <transition to= Exames laboratoriais realizados > <condition expr= #{conten==exameslr} > </transition> <transition to= Necessidade de retorno para a triagem > <condition expr= #{conten==necessidadert} > </transition> </decision> <state name = Encaminhamento do medico externo realizado /> <state name = Encaminhamento do medico interno de outra especialidade realizado /> <state name = Exames laboratoriais realizados /> <state name = Necessidade de retorno para a triagem /> Figura 6.30 Interpretação do elemento Start Event no jpdl. Em relação aos eventos finais, a segunda etapa cria um elemento <end> no modelo jpdl para cada evento final do modelo de processo de negócio. Conforme mostrado na Figura 6.31 foram criados elementos <end> para os seguintes eventos finais: Procedimentos realizados, Pacientes com fibromialgia orientados, Folha de faturamento registrada no sistema. <end name="procedimentos realizados"/> <end name="pacientes com fibromialgia"/> <end name="folha de faturamento registrada no sistema"/> Figura 6.31 Interpretação do elemento End Event no jpdl. A terceira etapa é responsável por criar as entidades no jpdl que representam uma Function, System Function Actual e Process Interface do ARIS Method no modelo em

220 204 desenvolvimento. O elemento Function do ARIS é interpretado como um elemento Task do jpdl e os elementos System Function (Actual) e Process Interfaces são interpretados com o elemento Java do jpdl 11. Levando em consideração a semântica do elemento notacional Process Interface, apresentada na seção 3.3, sempre que este for interpretado como um elemento Java será necessário adicionar um elemento end para representar o fim da instância atual do processo. Para exemplificar a terceira etapa da transformação será utilizada a Function Examinar o paciente, a System Function (Actual) Solicitar exames laboratoriais e a Process Interface Diagnosticar quadro de saúde. A Figura 6.32 apresenta o resultado da terceira etapa. //Tarefa executada por humanos <task name="examinar paciente"/> //Tarefa executada automaticamente por sistemas computacionais <java name="solicitar exames laboratoriais class= TODO method="todo var="todo /> //Process Interface <java name="diagnosticar quadro de saúde class= TODO method="todo var="todo > <trasition name= toenddiagosticar to= ENDDiagnosticar /> </java> <end name="enddiagnosticar" /> Figura Interpretação do elementos Function, System Function (Actual), Process Interfaces no jpdl. Como pode ser observado na figura acima, o elemento Java possui um conjunto de parâmetros que necessitam ser preenchidos. Por causa disto, foi atribuído aos mesmos o valor TODO. O valor TODO descreve que deve ser preenchido pelo desenvolvedor após a conclusão das transformações. Para representar que após a execução de um Process Interface é o fim do processo de negócio, foi adicionado o elemento transition e o elemento end no modelo jpdl.o 11 No jpdl o elemento Task representa uma atividade que é desempenhada por humanos e o elemento Java representa uma tarefa automatizada.

221 205 elemento transition define um possível caminho que o fluxo do processo poderá seguir. A quarta etapa é responsável por relacionar as entidades organizacionais, identificadas na primeira etapa, com as atividades realizadas por humanos, identificadas na terceira etapa, no modelo jpdl em construção. O relacionamento entre essas duas entidades é feito através do relacionamento carries out. A Figura 6.33 apresenta o resultado da aplicação da quarta etapa na atividade Examinar Paciente (desempenhada pelo Médico). //Tarefa executada por humanos <task name="examinar paciente" swimlane= Médico /> Figura Interpretação do elementos Function e System Function Actual no jpdl. A quinta etapa é responsável por interpretar as regras de processo, representadas pelo elemento Rule do ARIS Method, em termos das entidades do jpdl. A Tabela 6.2 apresenta a interpretação para cada Rule que existe no ARIS Method na linguagem jpdl. Tabela 6.2 Interpretação das regras de processo no jpdl. Elemento notacional do ARIS Method Elemento no jpdl OR Split OR-Join XOR-Split XOR-Join AND-Split AND-Join Decision Decision Decision Decision Fork Join Para exemplificar a quinta etapa, esta é aplicada sobre o elemento XOR que ocorre após a atividade Examinar paciente. A Figura 6.34 apresenta a representação deste elemento Rule no jpdl.

222 206 <decision name="decision_examinar paciente" expr= #{content} > <transition name="necessidadede exames laboratoriais Não detectada" to= DECISION_Analisar_resultados_dos_exames /> <transition name="necessidade de exames laboratoriais detectada" to= Verificar realização prévia de exames laboratoriais /> </decision> Figura Interpretação do elemento XOR do ARIS Method no jpdl. Para o nome do elemento decision foi definida a seguinte regra: DECISION + nome do elemento Function anterior ao elemento Rule. Caso exista um conjunto de elementos Rule interligados através do relacionamento link, a regra é modificada para: DECISION + nome do elemento Function anterior ao elemento Rule mais um identificador. O parâmetro expr do elemento decision descreve qual expressão ou variável define a regra de escolha de um ou mais caminhos que o fluxo do processo poderá seguir. Como dito anteriormente, cada elemento transition define um possível caminho que o fluxo do processo poderá seguir. Para indicar qual caminho o fluxo de processo irá seguir, o resultado da expr deve ser igual ao valor associado ao parâmetro name do elemento transition. O parâmetro to do elemento transition define o componente que será ativado. Para a construção dos transitions que estão presente no elemento decision é necessário que a quinta etapa analise no modelo de processo os relacionamentos leads to (ocorrem entre os elementos Rule e Event), activates (ocorre entre os elementos Event e Function) e is evaluted by (ocorre entre os elementos Event e Rule). A análise desses relacionamentos permite identificar quais são os possíveis caminhos que o processo poderá seguir. Como pode ser observado na Figura 6.34, o valor do atributo name do transition é o nome do Event que está associado ao elemento Rule, pelo relacionamento leads to. O parâmetro to é utilizado para definir o elemento que será ativado pela transação. O valor do parâmetro to é o nome do elemento que pode ser alcançado pelos relacionamentos activates e is evaluted by.

223 207 A identificação de um AND-Split pela quinta etapa é realizada através da análise dos seguintes casos: i. identificação do relacionamento leads to entre o elemento Function e o elemento notacional AND Rule; ii. identificação de um ou mais relacionamentos do tipo link saindo do elemento notacional AND Rule; ou iii. identificação do relacionamento is evaluated by entre um Event e o elemento notacional AND Rule. A identificação de um AND-Join pela quinta etapa é realizada quando: i. existem dois ou mais relacionamentos is evaluated by entre dois ou mais elementos Event e o elemento notacional AND Rule; ii. existe um ou mais relacionamentos do tipo link chegando em um elemento notacional AND Rule; ou iii. existe um relacionamento do tipo activates entre o elemento AND Rule e um elemento Function. A sexta, e última, etapa é responsável por relacionar os elementos construídos nas outras etapas das transformações no modelo jpdl em desenvolvimento, através do elemento transition do jpdl. Para isto, é necessário identificar os seguintes relacionamentos no modelo: (i) is predecessor of, (ii) activates, e (iii) leads to. O primeiro relacionamento ocorre entre os elementos do tipo Function, o segundo relacionamento ocorre entre o conjunto de elementos formado por Event e Rule e o elemento Function, enquanto o último relacionamento ocorre entre o elemento Function e o elemento Rule. Para exemplificar a sexta etapa, esta foi aplicada no componente de processo Examinar paciente com o objetivo de relacioná-lo com o elemento XOR-Rule (ocorre após essa atividade). A figura abaixo mostra o resultado desta etapa.

224 208 <task name="examinar paciente" swimlane= Médico > <transition name= Paciente Examinado to= DECISION_Examinar paciente > </task> Figura 6.35 Criando as inter-relações entre os elementos do processo de negócio. A Figura 6.36 apresenta um fragmento do modelo jpdl produzido pela transformação comportamental. <?xml version="1.0" encoding="utf-8"?> <process name="jpdl4" xmlns=" <!-- Raias do processo --> <swimlane name="medico"/> <swimlane name="recepcionista"/> <!-- Evento inicial do processo --> <start name="start"> <transition name="tobuscar_ficha" to="buscar ficha"/> </start> <!-- Atividades do processo --> <task name="buscar ficha " swimlane="recepcionista"> <transition name="toexaminar_o_paciente" to="examinar o paciente"/> </task> <task name="examinar o paciente" swimlane="medico"> <transition name="todecision_examinar_o_paciente" to="decision_examinar_o_paciente"/> </task> <task name="verificar realizacao previa de exames laboratoriais" swimlane="medico"> <transition name="todecisionverificar_realizacao_previa_de_exames_laboratoriais" to="decision_verificar_realizacao_previa_de_exames_laboratoriais"/> </task> <decision name="decision_examinar_o_paciente"> <transition name="necessidade de exames laboratoriais detectada" to="verificar realizacao previa de exames laboratoriais"/> <transition name="necessidade de exames laboratoriais nao detectada" to="decision_examinar_o_paciente_1"/> </decision> Figura Fragmento do modelo em jpdl do processo de negócio Triar pacientes para admissão no setor.

225 Transformação de Atividade Nesta etapa do desenvolvimento do sistema de workflow os modelos de Detalhamento de Atividade ajudaram a obter informações sobre cada atividade do processo presente no sistema. Para exemplificar a utilização das informações contidas em tais modelos é apresentada uma transformação que é utilizada para complementar o modelo jpdl desenvolvido na seção O complemento é a adição do componente de envio de no jpdl denominado mail. A transformação é composta de cinco etapas. É utilizado o modelo de detalhamento da atividade Encaminhar paciente para ambulatório (Figura 6.25) para exemplificar as etapas. A primeira etapa da transformação é a identificação dos elementos organizacionais que devem ser notificados ao fim da atividade. Essa identificação é realizada através da análise do relacionamento must be informed about entre os elementos Function e Participant. O resultado dessa etapa sobre o componente de processo selecionado foi: Grupo de Orientação de fibromialgia, Grupo do ambulatório de procedimentos e Grupo do ambulatório de reabilitação. A segunda etapa identifica as notificações que cada uma das entidades organizacionais receberá. A identificação das notificações é feita através do relacionamento lies on entre os elementos Cluster e Eletronic Document. Para capturar o nome de cada Eletronic Document, é lido o valor do campo name desse elemento. É importante ressaltar que somente os Clusters que possuem o relacionamento has output of com o elemento Function são analisados. Através da segunda etapa foi possível identificar os seguintes documentos: Notificação de encaminhamento para o grupo de fibromialgia, Notificação de encaminhamento para o ambulatório de procedimentos e Notificação de encaminhamento para o ambulatório de reabilitação.

226 210 A terceira etapa é a responsável por construir e adicionar o elemento mail no modelo jpdl utilizando as informações contidas nas duas etapas anteriores. Desta forma, foram adicionados três componentes mail no modelo jpdl. A quarta etapa é responsável por modificar a tarefas Encaminhar paciente para ambulatório, para que se adéque às modificações feitas pela terceira etapa. A modificação se resume em: (i) remover o transition existente e (ii) adicionar os transitions que levam o fluxo do processo para cada uma das notificações. A Figura 6.37 apresenta o resultado da quarta etapa. <task name="encaminhar paciente para o ambulatório" swimlane= Médico > <transition name= tonotificação_de_encaminhamento_para_o_grupo_de fibromialgia to= Notificação de encaminhamento para o grupo de fibromialgia > <transition name= tonotificação_de_encaminhamento_para_o_ambulatório de procedimentos to= Notificação de encaminhamento para o ambulatório de procedimentos > <transition name= tonotificação_de_encaminhamento_para_o_ambulatório_de_reabilitaç ão to= Notificação de encaminhamento para o ambulatório de reabilitação > </task> Figura 6.37 Modificação da atividade Encaminhar paciente para ambulatório. A quinta, e última, etapa é a responsável por adicionar um transition em cada uma das notificações. O valor do parâmetro to do transition é o mesmo do transition que foi removido na quarta etapa. Essa etapa é importante para manter a conformidade entre as transformações. A Figura 6.38 apresenta o resultado da terceira etapa e quintaetapa.

227 211 //Notificação para o grupo de fibromialgia <mail name="notificação de encaminhamento para o grupo de fibromialgia"> <to addresses=#{grupo de orientação fibromialgia} /> <subject> Notificação de encaminhamento para o grupo de fibromialgia </subject> <text>todo</text> <transition to=" DECISIONEncaminhar_paciente_para_ambulatorio"/> </mail> // Notificaçao para o grupo do ambulatório de procedimentos <mail name="notificação de encaminhamento para o ambulatório de procedimentos"> <to addresses=#{grupo do ambulatório procedimentos} /> <subject> Notificação de encaminhamento para o ambulatório de procedimentos </subject> <text>todo</text> <transition to=" DECISIONEncaminhar_paciente_para_ambulatorio"/> </mail> //Notificação de encaminhamento para o ambulatório de reabilitação <mail name="notificação de encaminhamento para o ambulatório de reabilitação"> <to addresses=#{grupo do ambulatório de reabilitação}/> <subject>notificação de encaminhamento para o ambulatório de reabilitação </subject> <text>todo</text> <transition to=" DECISIONEncaminhar_paciente_para_ambulatorio"/> </mail> Figura Notificações da atividade Encaminhar paciente para ambulatório Transformação Organizacional As transformações organizacionais têm por objetivo complementar o modelo jpdl construído nas seções e 6.5.2, utilizando as informações contidas nos modelos organizacionais do sistema computacional construído pelas transformações independentes de plataforma.

228 212 Para exemplificar o uso das transformações organizacionais do nível dependente de plataforma, são apresentadas duas transformações. A primeira transformação complementa o modelo jpdl descrevendo quais entidades organizacionais que irão instanciar os papéis definidos no processo de negócio. A segunda transformação complementa o modelo jpdl adicionando atividades de notificação. Para exemplificar a utilização da primeira transformação organizacional, essa será aplicada sobre os modelos organizacionais de sistema computacional do Médico (Figura 6.27) e da Recepcionista (Figura 6.26). No caso desses dois modelos, a transformação organizacional identifica qual entidade irá assumir o papel de Médico e o papel de Recepcionista no sistema computacional através dos relacionamentos performs ou occupies. Como explicado na seção 4.3, esses relacionamentos devem existir entre o elemento Person Type (e suas especializações) e as entidades organizacionais que irão instanciá-lo. Porém, em outros modelos talvez seja necessário analisar outros relacionamentos. Como mostrado nas Figura 6.26 e Figura 6.27, somente, o Reumatologista poderá assumir o papel de Médico e somente o Auxiliar de Administrativo poderão assumir o papel de Recepcionista no processo. Desta forma, a Transformação Organizacional irá r associar a posição Reumatologista ao papel médico e a posição Auxiliar Administrativo ao papel Recepcionista. A Figura 6.39 apresenta o resultado da primeira transformação <swimlane name= Medico assignee= reumatologista /> <swimlane name="recepcionista" assignee= auxiliar Administrativo /> Figura Transformação organizacional Para exemplificar a utilização da segunda transformação organizacional, esta é aplicada sobre o modelo organizacional de sistema computacional mostrado na Figura No caso da Figura 6.28 o projetista definiu que apenas a Enfermeira chefe deve receber a notificação que será encaminhada para o Grupo do ambulatório de reabilitação. Desta forma, a segunda transformação atualiza o modelo jpdl com as informações do modelo, conforme apresentado na Figura 6.40.

229 213 //Notificação de encaminhamento para o ambulatório de reabilitação <mail name="notificação de encaminhamento para o ambulatório de reabilitação"> <to addresses=enfermeira chefe/> <subject>notificação de encaminhamento para o ambulatório de reabilitação </subject> <text>todo</text> <transition to=" DECISIONEncaminhar_paciente_para_ambulatorio"/></mail> Figura 6.40 Adicionando a entidade organizacional no elemento notificação. 6.6 ETAPAS MANUAIS PARA O DESENVOLVIMENTO DO SISTEMA DE WORKFLOW As implementações das transformações dependentes de plataforma apresentadas neste capitulo produziram o documento jpdl necessário para descrever o processo que será automatizado. No entanto, isso não é suficiente para a conclusão do desenvolvimento do sistema de workflow. Afinal ainda é necessário: (i) desenvolver as telas que serão utilizadas pelos usuários, (ii) criar a base de dados e (iii) implementar as regras de negócio no sistema computacional em desenvolvimento. Desta forma, a equipe, responsável por desenvolver o sistema computacional terá que implementar manualmente os itens (i), (ii) e (iii) citados anteriormente. Para complementar o restante do sistema computacional que visa automatizar o processo de negócio Triar Paciente para Admissão no Setor foi necessário criar todas as telas das atividades que serão gerenciadas por usuários, criar a base de dados, desenvolver as classes em Java que representam as atividades automatizadas e atualizar o documento jpdl com informações diversas (caminho da classe que representa as atividades automatizadas, caminhos das páginas que representam as telas dos usuários, entre outras). É importante ressaltar que as implementações das transformações dependentes de plataforma apresentadas neste trabalho apenas exemplificaram o uso da semântica contida nos modelos arquiteturais e como elas podem ser usadas para o desenvolvimento de sistemas computacionais. É possível o desenvolvimento de diversas outras transformações que explorem de forma diferente as informações contidas nos modelos arquiteturais.

230 214 Por exemplo, é possível o desenvolver uma transformação no nível dependente de plataforma que produza códigos que descrevam uma ou mais regras de negócio, que devem estar contidos na aplicação, tendo como fonte as informações contidas dentro dos elementos Business Rule associados às atividades (Function) do processo de negócio. 6.7 WORKFLOW DO PROCESSO TRIAR PACIENTES PARA ADMISSÃO NO SETOR Esta seção é dedicada à demonstração da utilização do sistema de workflow desenvolvido através das transformações independentes, dependentes de plataforma e com o complemento manual do desenvolvedor. A Tabela 6.2 apresenta as atividades utilizadas na demonstração. Tabela Atividades Utilizadas na Demonstração. Atividade Responsável Buscar Ficha do Paciente Recepcionista Examinar o Paciente Médico Verificar realização prévia de exames Médico laboratoriais Sistema de Solicitar exames solicitação de laboratoriais exames O sistema de workflow inicia quando o Recepcionista informa o identificador do paciente, conforme ilustrado na Figura Após o Recepcionista clicar no botão Enviar Prontuário, o sistema automaticamente busca o prontuário médico do paciente na base de dados e envia para o médico que irá atender o paciente. Esses passos são realizados na atividade Buscar Ficha do Paciente. Figura 6.41 Tela da atividade Buscar ficha do paciente.

231 215 Na atividade Examinar o paciente", o sistema apresenta ao Médico todo o histórico do paciente que está sendo examinado. Nessa atividade o Médico cadastra no sistema os novos sintomas do paciente e informa se existe a necessidade de realizar exames laboratoriais por parte do paciente. A Figura 6.42 apresenta a tela da atividade Examinar paciente. Figura 6.42 Tela da atividade Examinar o paciente. Caso o Médico verifique a necessidade da realização de exames laboratoriais, o sistema de workflow encaminha o Médico para a atividade Verificar realização prévia de exames laboratoriais. Nessa atividade o Médico visualiza se o paciente já realizou algum exame laboratorial previamente. A Figura 6.43 apresenta a tela da atividade Verificar realização prévia de exames laboratoriais. Caso o Médico queira que o Paciente realize algum exame que não foi realizado previamente, ele informa o nome do exame no campo Novo Exame, seleciona a opção Exames laboratoriais não realizados previamente e clica no botão Ok. Por fim, o sistema de workflow executa a atividade automatizada Solicitar exames laboratoriais que solicita automaticamente o exame no laboratório para o paciente, através do Sistema de Exames Laboratoriais e registra a consulta no Sistema de Controle de Paciente. A Figura 6.44 apresenta log da execução da atividade Solicitar exames laboratoriais.

232 216 Figura 6.43 Tela da atividade Verificar realização previa de exames laboratoriais. Figura 6.44 Log de execução da atividade Solicitar exames laboratoriais. Após a execução da atividade Solicitar exames laboratoriais, a instância do processo Triar pacientes para admissão no setor é finalizada. A Figura 6.45 apresenta o fluxo de execução para essa instância do processo. As setas pretas indicam as atividades que foram executadas ao longo do sistema de workflow.

233 O Médico Sistema de solicitação de exames Recepcionista Orientar pacientes com fibromialgia Realizar procedimentos Encaminhamento de médico externo realizado Encaminhamento de médico interno de outra especialidade realizado Exames laboratoriais realizados Necessidade de retorno para a triagem Necessidade de retorno para a triagem Examinar o paciente Buscar ficha do paciente Necessidade de exames laboratoriais não detectada Necessidade de exames laboratoriais detectada Verificar realização prévia de exames laboratoriais Exames laboratoriais realizados previamente Exames laboratoriais não realizados previamente Analisar resultados dos exames Solicitar exames laboratoriais SYS SYS Folha de faturamento registrada no sistema Resultados dos exames analisados Figura Fragmento do processo de negócio.

234 CONCLUSÃO Este capítulo apresentou como a abordagem de Desenvolvimento Orientado a Modelos proposta (Capítulo 5) pode ser utilizada para o desenvolvimento de sistemas computacionais orientados a processo de negócio. Para a demonstração da abordagem proposta, as transformações (independentes e dependentes de plataforma) foram implementadas e aplicadas sobre os modelos de Processo de Negócio, Organizacional e Detalhamento de Processo de Atividade que descrevem o processo Triar pacientes para admissão no setor, com o objetivo de desenvolver um sistema computacional que automatize tal processo de negócio. Desta forma, é mostrada a viabilidade da abordagem e mostrado como os diferentes modelos podem ser utilizados nas etapas de desenvolvimento de um sistema computacional. Ao implementar as transformações também foi mostrado como o entendimento da semântica dos elementos de modelagem pode ser útil na construção e no resultado esperado destas. Também foi mostrado no capítulo como as decisões de projeto são aplicadas nas transformações através das parametrizações gerando, assim, o sistema computacional conforme requerido.

235 219 CAPÍTULO 7 CONCLUSÕES E TRABALHOS FUTUROS 7.1 CONCLUSÕES Este trabalho apresentou uma abordagem de Desenvolvimento Orientado a Modelos que utiliza modelos de Arquiteturas Organizacionais de TI para desenvolvimento de sistemas computacionais orientados a processo. Diferentemente da maioria das abordagens atuais de Desenvolvimento Orientado a Modelos, a abordagem proposta neste trabalho permite ao projetista: (i) utilizar a semântica dos vários modelos que representam uma Arquitetura Organizacional de TI; (ii) aplicar as decisões de projeto sobre os modelos utilizados, através da definição de parametrizações nas transformações pré-definidas; e (iii) dividir o processo de desenvolvimento do sistema computacional em etapas independente e dependente de plataforma. A utilização da semântica (bem definida) dos elementos das linguagens de modelagem possibilitou um melhor uso das informações contidas nos modelos. Através dessas transformações o projetista pode explorar a riqueza das informações contidas nos modelos e aplicar decisões de projeto sobre tais informações. Por exemplo, foram utilizadas informações relativas ao comportamento de processos, à estrutura organizacional e ao detalhamento de atividades (que podem incluir a descrição das informações necessárias e produzidas pela atividade e os responsáveis pela execução da atividade). As decisões de projeto são aplicadas sobre os modelos através das parametrizações das transformações pré-definidas. Desta forma, a abordagem proposta permite ao projetista uma maior flexibilidade nas transformações. Para que o desenvolvimento do sistema computacional seja inteiramente orientado a modelos, foi desenvolvimento um metamodelo (seção 6.2.2) que permite ao projetista desenvolver modelos que selecionam e parametrizam as transformações definidas na abordagem.

236 220 A divisão do processo de Desenvolvimento Orientado a Modelos nos níveis independente e dependente de plataforma possibilita ao projetista introduzir decisões de projeto em perspectivas diferentes. No nível independente de plataforma, o projetista utiliza as decisões de projeto com a finalidade de construir um conjunto de modelos que descreva o comportamento, os atores e os detalhes de cada atividade do sistema computacional, sem levar em consideração as tecnologias e a infraestrutura envolvida no desenvolvimento do sistema. Desta forma, a partir dos modelos gerados, é possível descrever as partes essenciais de um sistema computacional orientado a processo e, assim, possibilitar o desenvolvimento de diversos sistemas computacionais baseado nesses modelos. No nível dependente de plataforma, o projetista utiliza as decisões de projeto para transformar os modelos gerados no nível independente de plataforma em modelos que concretizem o sistema computacional orientado a modelos. Por exemplo, neste trabalho as transformações no nível dependente de plataforma possibilitaram a construção de um modelo jpdl a partir dos modelos gerados no nível independente de plataforma, conforme mostrado no Capítulo 6. A construção de modelos e transformações durante o processo de desenvolvimento orientado a modelos proposto neste trabalho somente foi possível devido ao estudo aprofundado da semântica dos elementos e relacionamentos presentes nos modelos utilizados no processo de desenvolvimento. Como discutido no Capítulo 4, o estudo aprofundado da semântica dos modelos do ARIS possibilitou a identificação de problemas na linguagem que poderiam interferir em uma transformação automatizada. O estudo aprofundado da semântica dos elementos de modelagem também teve impacto na área de modelagem organizacional, afinal, com a semântica dos elementos bem definida tornou-se possível a construção de modelos corretos, ou seja, que representam as diversas situações do mundo real de forma correta e sem ambiguidade. O estudo semântico realizado neste trabalho é complementar aos estudos quem concentram na semântica formal (de execução) de EPCs (como apresentado em (VAN DER AALST, 1998) (KINDLER, 2006)). Por fim, de forma sucinta, podem-se listar as seguintes contribuições deste trabalho:

237 221 i. Entendimento dos conceitos dos domínios Organizacional, de Processo de Negócio e de Detalhamento de Atividades presentes no ARIS: Através dos metamodelos das linguagens dos domínios organizacionais, de processo de negócio e de detalhamento de atividades, que estão implementadas nas ferramentas ARIS, foi possível uma melhor compreensão dos conceitos de cada um desses domínios proposto pelo ARIS Method. Também vale ressaltar, que os metamodelos de domínio propostos neste trabalho são os mais atuais publicamente conhecidos; e esses modelos também podem ser utilizados para desenvolvimento de aplicações que manipulem as informações dos modelos de domínio organizacional, processo de negócio e detalhamento de atividades, como apresentado em (PIUMBINI, 2009). ii. Análise Ontológica das linguagens dos domínios de Processo de Negócio, Organizacional e Detalhamento de Atividades: Através da análise ontológica dos elementos dos metamodelos, das linguagens de domínio escavadas, foi possível estabelecer uma relação entre esses elementos e as entidades do mundo real com base em uma ontologia de fundamentação. A análise ontológica também possibilitou identificar erros de semântica nas linguagens de domínio do ARIS Method. iii. Abordagem de Desenvolvimento Orientado a Modelos utilizando modelos das Arquiteturas Organizacionais de TI: Apresentamos uma abordagem de Desenvolvimento Orientado a Modelos que difere das demais abordagens atuais por permitir ao projetista aplicar as decisões de projeto, dividir o processo de desenvolvimento em duas etapas bem definidas (independente e dependente de plataforma) e utilizar a semântica dos modelos arquiteturais de forma mais adequada no processo de construção de um sistema computacional. 7.2 TRABALHOS FUTUROS Os trabalhos futuros se concentrarão principalmente: (i) na aplicação e no aperfeiçoamento da abordagem de Desenvolvimento Orientada a Modelos proposta neste trabalho; (ii) no desenvolvimento de um ambiente computacional que implemente completamente a abordagem proposta e; (iii) no desenvolvimento de técnicas que

238 222 permitam evoluir o sistema computacional tendo como base as mudanças nos processos de negócio e/ou Arquitetura Organizacional de TI da organização. O ambiente computacional permitiria ao projetista: i. aplicar as transformações da abordagem de forma automática, aumentando a produtividade no desenvolvimento de sistemas computacionais; ii. visualizar todo o processo de desenvolvimento do sistema computacional e, desta forma, prever o resultado das transformações e suas consequências no sistema computacional em desenvolvimento; iii. permitir que o projetista desenvolva o sistema computacional em diversas plataformas de realização, apenas tendo como base os modelos gerados pelas transformações no nível independente de plataforma. Por exemplo, a partir de um mesmo conjunto de modelos, gerar diversos sistemas computacionais em BPEL (OASIS, 2006), Java e jbpm. Em relação ao aperfeiçoamento da abordagem de Desenvolvimento Orientado a Modelos, proposta neste trabalho, vislumbramos o desenvolvimento de: i. Transformações que utilizem outros modelos das Arquiteturas Organizacionais de TI como, por exemplo, diagramas da UML, diagramas de banco de dados, modelos de interface com usuário, modelos de segurança de informação e outros modelos que sejam passíveis de transformação automática e venham a contribuir para o desenvolvimento de sistemas computacionais; ii. Estudos de transformações (e regras para transformações) que permitam ao projetista: a. aplicar conceitos de abstração e refinamento nas entidades organizacionais que estão presente nos modelos de processos de negócio e vislumbrar quais serão as modificações nos modelos comportamentais do sistema computacional;

239 223 b. construir um modelo comportamental do sistema computacional a partir de dois ou mais processos de negócios; c. aplicar conceitos nos modelos comportamentais que não estejam presentes nas linguagens de processo de negócio nativas das Arquiteturas Organizacionais de TI. Por exemplo, aplicar o conceito de multi-instância que está presente em BPMN (BPMN, 2009) nos modelos EPC (SCHEER, 1999); e d. verificar os impactos de mudanças no processo de negócio, de requisitos e/ou decisões de projeto sobre um sistema computacional desenvolvido ou em desenvolvimento.

240 224 CAPÍTULO 8 REFERÊNCIAS ALLEN, J. F. Maintaining knowledge About Temporal Intervals. Communications of the AcM, 26, ALLEN, J. F. Maintaining Knowledge About Temporal Intervals. Communications of the ACM, Vol.26, n. 11, ALMEIDA, J. P. A. Model-Driven Design of Distributed Applications, Ph.D. Thesis in Computer Science. Enschede: Telematica Instituut Fundamental Research Series, ISBN ALMEIDA, J. P. A. et al. Model Driven Design, Refinement and Transformation of Abstract Interactions. International Journal of Cooperative Information Systems (IJCIS), 15, n. 4, 2006b ALMEIDA, J. P. A.; GUIZZARDI, G.; SANTOS JR., P. S. Applying and Extending a Semantic Foundation for Role-Related Concepts in Enterprise Modelling. Enterprise information systems, 3, pp ALMEIDA, J. P. A.; VAN ECK, P.; IACOB, M. E. Requirements Traceability and Transformation Conformance in Model-Driven Development. Tenth IEEE International EDOC Conference (EDOC 2006), 2006a ALTER, S. Information Systems: A Management Perspective. [S.l.]: Addison-Wesley, ARCHIMATE CONSORTIUM. Archimate Resource Tree, Disponível em: < Acesso em: 20 janeiro AZEVEDO, L. G. et al. Identificação de Serviços a partir da Modelagem de Processos de Negócio. V Simpósio Brasileiro de Sistema de Informação (SBSI), 2009.

241 225 BALDINGER, K. Semantic Theory: Towards a Modern Semantics. [S.l.]: Palgrave Macmillan, BOTTAZI, E.; FERRARIO, R. Preliminaries to a DOLCE Ontology of Organizations. J. Business Process Integration and Management, Vol.1, pp BPMN. BPMN - Business Process Modeling Notation, Disponível em: < Acesso em: 2009 Janeiro 8. CARDOSO, E. C. S. Uma Comparação entre Requisitos de Sistemas Gerados por Técnicas de Modelagem de Processos com Requisitos de Sistemas Gerados por Técnicas Convencionais de Engenharia de Requisitos, Monografia de Conclusão de Curso, Universidade Federal do Espírito Santo. CARDOSO, E. C. S. Towards the Alignment of Enterprise Architecture Models and Goal Models. Vitória: [s.n.], Dissertação de Mestrado. Universidade Federal do Espírito Santo. CARDOSO, E. C. S.; ALMEIDA, J. P. A.; GUIZZARDI, G. A Requirements Engineering Experiment based on Process Models (Uma Experiência com Engenharia de Requisitos baseada em Modelos de Processos in portuguese). XI Iberoamerican Workshop on Requirements Engineering and Software Environments (IDEAS 2008), Recife, CONTE, R.; CASTELFRANCHI, C. Cognitive and Social Action. Londres: UCL Press, CUMBERLIDGE, M. Business Process Management with JBoss jbpm: A Practical Guide for Business Analysts. Olton,Birmingham,UK: Packt Publishing, DAVIS, R. Business Process Modeling with ARIS - A Pratical Guide. [S.l.]: Springer, DIGNUM, V. A Model for Organization Interaction: Based on Agents, Founded in Logic. The Netherland: [s.n.], Ph.D. Thesis.

242 226 DOCKHORN COSTA, P.; GUIZZARDI, G.; ALMEIDA, J. P. A. Situations in Conceptual Modeling of Context. Proceedings of the IEEE EDOC 2nd International.Ontologies and Rules for The Enterprise (VORTE 06), Hong Kong, China., Outubro DODAF. DODAF - DoD Architecture Framework Version 1.5. [S.l.]: [s.n.], v. II: Product Descriptions, DUMAS, M.; VAN DER AASLT, W. M. P.; TER HOFSTEDE, A. H. M. Process- Aware Information Systems: Bridging people and software through process technology. Book Reviews. ed. [S.l.]: [s.n.], DOI= ECLIPSE, F. Eclipse. Eclipse Modeling - EMF - Home, Disponível em: < ECLIPSE, F. Generating an EMF Model using XML Schema (XSD), 2008b. Disponível em: < Acesso em: 15 maio FELHBERG, G. Interoperabilidade Semântica de Aplicações Comercialmente Disponíveis Usando Ontologias de Domínio. [S.l.]: Monografia de Conclusão de Curso. Universidade Federal do Espírito Santo, FERDINAND, M.; ZIRPINS, C.; TRASTOUR, D. Lifting XML Schema to OWL, Web Engineering. 4th International Conference, ICWE 2004, LNCS 3140, pp FILIPOWSKA, A. et al. Organisational Ontology Framework for Semantic Business Process Management. Proceedings of the 12th International Business Information Systems Conference (BIS 2009), Poznan, Poland, 2009a. pp

243 227 FILIPOWSKA, A. et al. Organizational Ontologies to Support Semantic Business Process Management. SBPM, 2009b. GÄRDENFORS, P. Conceptual Spaces: the Geometry of Thought. USA: MIT Press, GONZÁLEZ, J.; DÍAZ, J. Business process-driven requirements engineering: a goalbased approach. In Proc. of 8th Workshop on Business Process Modelling.Development and Support (BPMDS'07), GREEN, P. F.; ROSEMANN, M. Ontological Analysis of Business Systems Analysis Techniques: Experiences and Proposals for and Enhanced Methodology. Business Systems Analysis with Ontologies, GREEN, P.; DAVIES, I. G.; ROSEMANN, M. Exploring proposed ontological issues of ARIS with different categories of modellers. Proceedings of the Australasian Conference on Information Systems, Hobart, Australia, GREEN, P.; INDULSKA, M.; AND ROSEMANN, M. A Reference Methodology for Conducting Ontological Analyses. A Reference Methodology for Conducting Ontological Analyses. In Proceedings of the 23rd International Conference on Conceptual Modelling,ER 2004, Shanghai, China, 2004b. GRUBER, T. R. A translation approach to portable ontology specifications. In: Knowledge Acquisition. [S.l.]: [s.n.], v. 5, p GUARINO, N. Formal Ontology and Information Systems. Formal Ontologyin Information Systems, Proceedings of the International Conference on Formal Ontology and Information Systems (FOIS), Trento, Italia, 6-8 junho pag GUARINO, N.; GIARETTA, P. Ontologies and Knowledge Bases: Towards a Terminological Clarification. Amsterdam: IOS Press, p. GUIDE BUSINESS RULE. Business Rules Group, Disponível em: <

244 228 GUIZZARDI, G. Ontological Foundations for Structural Conceptual Models. The Netherlands: [s.n.], 2005a. Ph.D. Thesis, University of Twente. GUIZZARDI, G. On Ontology, ontologies, Conceptualizations, Modeling Languages, and (Meta)Models. Frontiers in Artificial Intelligence and Applications, Databases and Information Systems IV, Amsterdam, GUIZZARDI, G.; FALBO, R. A.; GUIZZARDI, R. S. S. The Importance of Foundational Ontologies for Domain Engineering: The case of the Software Process Domain (A importância de Ontologias de Fundamentação para a Engenharia de Ontologias de Domínio:o caso do domínio de Processos de Software in portuguese). IEEE Transactions Latin America, GUIZZARDI, G.; FERREIRA PIRES, L.; VAN SINDEREN, M. An Ontology-Based Approach for Evaluating the Domain Appropriateness and Comprehensibility Appropriateness of Modeling Languages. ACM/IEEE 8th International Conference on Model Driven Engineering Languages and Systems, vol. 3713, 2005a. GUIZZARDI, G.; WAGNER, G. Towards Ontological Foundations for Agent Modeling Concepts using UFO. Agent-Oriented Information Systems II, Lecture Notes on Artificial Intelligence (LNAI), 3508, 2005b. GUIZZARDI, R. S. S. et al. Towards an Ontological Account of Agent Oriented Goals,Software Engineering for Multi-Agent Systems, Berlin, v. Vol. V, 2007a. HAREL, D.; RUMPE, B. Modeling Languages: Syntax, Semantics and All That Stuff, Part1: The Basic Stuff. The Weizmann Institute of Science, Israel, HELLER, B.; HERRE, H. Ontological categories in gol: Axiomathes. [S.l.]: Kluwer Academic Publishers, 2004a. pp p. HELLER, B.; HERRE, H. General ontological language GOL: A formal framework for building and representing ontologies., Leipzig, Germany, 2004b.

245 229 HERRE, H. et al. General Formal Ontology (GFO): a foundational ontology integrating objects and processes, Part 1: Basic Principals. Onto-Med Report 8, University of Leipzig, version HSI, I. Analyzing the Conceptual Integrity of Computing Applications Through Ontological: Excavation and Analysis. Georgia Institute of Technology: [s.n.], Dissertação de Doutorado. IBM. XML Import tool from ARIS to IBM WebSphere Business Modeler, Disponível em: < Acesso em: 23 Julho JABLONSKI, S.; BUSSLER, C. Workflow Management: Modeling Concepts, Architecture, and Implementation. Londres, UK: International Thomson Computer Press, ISBN / JONKERS, H. et al. Concepts for modeling enterprise architectures. In special issue on Architecture in IT of the International Journal of Cooperative Information Systems, setembro KERN, H.; KÜHNE, S. Model Interchange between ARIS and Eclipse EMF. The 7th OOPSLA Workshop Domain-Specific Modeling, KINDLER, E. On the Semantics of EPCs: A Framework for Resolving the Vicious Circle. Technical Report. Computer Science Department, University of Paderborn, Alemanha, KOHLBORN, T. et al. Identification and Analysis of Business and Software Services A Consolidated Approach. IEEE Transactions on Services Computing, vol. 2, pp doi: /tsc KURTEV, I.; BÉZIVIN, J.; AKSIT, M. Technological spaces: An initial appraisal. CoopIS, DOA'2002 Federated Conferences, Industrial track, Irvine, USA, 2002.

246 230 LANKHORST, M. Enterprise Architecture at Work - Modelling, Communication and Analysis. [S.l.]: Springer, LANKHORST, M.; VAN DRUNEN, H. Enterprise Architetcture Development and Modelling. Via-nova-architectura, Março Disponível em: < Acesso em: 2008 ago. 20. LENAT, D.; GUHA, R. V. Building Large Knowledge based Systems: Representation and Inference in the CYC Project. Massachusetts: Addison Wesley, LEYMANN, F.; ROLLER, D. Production Workflow: Concepts and Techniques. NJ: Prentice- Hall PTR, Upper Saddle River, LUBKE, D. et al. Using event-driven process chains for model-driven development of business application. International Journal of Business Process Integration and Management, v. vol. 3, n. n. 2, p. pp , MASOLO, C. et al. Ontology Library. WonderWeb Deliverable D18, MENDLING. EPML, Disponível em: < Acesso em: 12 setembro MENDLING, J.; NEUMANN, G.; NÜTTGENS, M. Towards Workflow Pattern Support of Event-Driven Process Chains (EPC). Proceedings of the 2nd GIWorkshop XML4BPM at the 11th GI Conference BTW, 2005a. MENDLING, J.; NEUMANN, G.; NÜTTGENS, M. Yet Another Event-Driven Process Chain (Extended Version): Technical Report. Enterprise Modelling and Information Systems Architectures - International Journal (EMISA Journal), Outubro 2005b. pp MENDLING, J.; NÜTTGEN, M. Transformation of ARIS Markup Language to EPML. Proc. of the 3rd GI Workshop on Event-Driven Process Chains, outrubro 2004.

247 231 MENDLING, J.; ZIEMANN, J. Transformation of BPEL Processes to EPCs. Proc. of the 4th GI Workshop on Event-Driven Process Chains, Hamburg, 167, Dezembro MINTZBERG, H. Structure in Fives: Designing Effective Organizations., São Paulo: Atlas, MORRIS, C. W. Foundations of a theory of signs. International Encyclopedia of Unified, Chicago, NILES, I.; PEASE, A. Towards a standard upper ontology. Proceedings of the international Conference on Formal ontology in information Systems(FOIS '01), Ogunquit, Maine, USA, OASIS. Web Services Business Process Execution Language, Disponível em: < Acesso em: 21 agosto OMG. MDA Guide Version 1.0.1, junho Disponível em: < Acesso em: 10 maio OMG. Object Constraint Language, Disponível em: < Acesso em: 10 abril OUYANG, C. et al. From Business Process Models to Process-oriented Software Systems: The BPMN to BPEL Way. ACM Transactions on Software Engineering and Methodology, PIUMBINI, M. T. Acesso a Modelos do ARIS Toolset: Uma abordagem Orientada a Modelos para Arquiteturas Organizacionais de TI. Espírito Santo: Monografia. Universidade Federal do Espírito Santos, RM-ODP-ISO-ISO/ITU-T. Open Distributed Processing - Reference Model. In: 10746, I. S. I. Open Distributed Processing - Reference Model. [S.l.]: [s.n.], 1995.

248 232 ROSEMANN, M.; VAN DER AALST, W. M. P. A Configurable reference modelling language. Inf. Syst., Março pp DOI= RUSSELL, N.; HOFSTEDE, A. H. M. WORKFLOW CONTROL-FLOW PATTERNS A Revised View. Workflow Patterns, Disponível em: < Acesso em: 10 outubro RUSSELL, N.; HOFSTEDE, A. H. M. WORKFLOW CONTROL-FLOW PATTERNS: A Revised View. Workflow Patterns, Disponível em: < Acesso em: 10 outubro SANTOS JR., P. S.; ALMEIDA, J. P. A. Escavando as Linguagens de Modelagem Organizacional e Modelagem de Processos de Negócio do ARIS Method. Workshop em Gerência de Processos de Negócio (WBPM).WebMedia 2008 XIV Simpósio Brasileiro de Sistemas Multimídia e Web, Anais Artigos Resumidos e Artigos de Workshops., Vila Velha, ES, v.2, SANTOS JR., P. S.; ALMEIDA, J. P. A.; GUIZZARDI, G. An Ontology-Based Semantic Foundation for ARIS EPCs. 7 Enterprise Engineering, ACM SAC, Sierre, Suiça, março SANTOS JR., P. S.; ALMEIDA, J. P. A.; PIANISSOLLA, T. L. Escavação, Refatoração e Análise de um Metamodelo para o ARIS Method. 3rd Workshop on Ontologies and Metamodels in Software and Data Engineering, Campinas, São Paulo, SANTOS JR., P. S.; ALMEIDA, J. P. A.; PIANISSOLLA, T. L. Uncovering the Organizational Modelling and Business Process Modelling Languages in the ARIS Method. International Journal of Business Process Integration and Management (IJBPIM), SCHEER, A. W. ARIS Business Process Modeling. Terceira Edição. ed. [S.l.]: Springer, 1999.

249 233 SCHEER, I. ARIS Platform: XML Export and Import,White Paper. [S.l.]: [s.n.], 2006b. SEARLE, J. Language and Society. [S.l.]: Basic Books, SHARP, A.; MCDERMOTT, P. Workflow modeling: Tools for Process Improvement and Application Development. [S.l.]: [s.n.], ISBN SPECHT, T. et al. Modeling cooperative business processes and transformation to a service oriented architecture. E-Commerce Technology, CEC 2005.Seventh IEEE International Conference, pp SUN. Sun Microsystems. Java.com, Disponível em: < Acesso em: 10 abril SUPER. sbpmn and sepc to BPMO Translation. Version 1.0. ed. [S.l.]: [s.n.], SUPER. Process Ontology Stack: Evolved Version. [S.l.]: [s.n.], THOM, L. H.; REICHERT, M.; IOCHPE, C. Activity Patterns in Process-aware Information systems: Basic Concepts and Empirical Evidence. IJBPIM - International Journal of Business Process and Information Management., THOMAS, O.; FELLMANN, M. Semantic Event-Driven Process Chains. Workshop SBPM, Budva, Montenegro, THOMAS, O.; FELLMANN, M. Semantic Event-Driven Process Chains, SBPM (Budva, Montenegro, 2006). ESWC 2006., THOMAS, O.; FELLMANN, M. Semantic EPC: Enhancing Process Modeling Using Ontology Languages. Proceedings of the Workshop on Semantic Business Process and Product Lifecycle Management, Innsbruck, Austria, 7 Junho 2007.

250 234 TOGAF, T. O. G. The Open Group Architectural Framework (TOGAF The Book ) ed. [S.l.]: Van Haren Publishing, UML. Unified Modeling Language (UML), Version 2. OMG, Disponível em: < Acesso em: 20 agosto VAN DER AALST, W. M. P. Formalization and Verification of Event-driven Process Chains. Computing Science Reports 98/01, Eindhoven University of Technology,Eindhoven, VAN DER AALST, W. M. P.; JABLONSKI, S. Dealing with Workflow Change: Identification of Issues and Solutions. International Journal of Computer Systems, Science, and Engineering, p , VAN DER AALST, W. M. P.; VAN HEE, K. M. Workflow Management: Models, Methods, and Systems. [S.l.]: The MIT Press, ISBN / VAN DONGEN, B. F.; VAN DER AALST, W. M. P.; VERBEEK, H. M. W. Verification of EPCs: Using Reduction Rules and Petri Nets. Proceedings of the 17th Conference on Advanced Information Systems Engineering (CAiSE'05).Lecture Notes in Computer Science, Berllin, vol. 3529, pp VANHATALO, J.; VÖLZER, H.; LEYMANN, F. Faster and More Focused Control- Flow Analysis for Business Process Models Through SESE Decomposition. Proceedings of the 5th international Conference on Service-Oriented Computing, Vienna, Austria, Setembro VOLZ, R. et al. OntoLiFT Prototype - WonderWeb: Ontology Infrastructure for the Semantic Web, W3SCHOOLS. DTD Tutorial, Disponível em: < Acesso em: 2008 abril 10.

251 235 W3SCHOOLS. Introduction to XML Schema. W3Schools, 2008b. Disponível em: < WEBER, R. Ontological Foundations of Information System. Coopers & Lybrand and the Accounting Association of Australia and New Zealand, Melboune, Australia, WEBER, R. Ontological Foundations of Information Systems. Coopers & Lybrand, Melbourne,Australia, WEBSTER. Merriam-Webster Dictionary, Disponível em: < ZACHMAN, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26, ZIEMANN, J.; MENDLING, J. EPC-Based Modelling of BPEL Processes: a Pragmatic Transformation Approach. Proceedings of the 7th International Conference "Modern Information Technology in the Innovation Processes of the Industrial Enterprises" (MITIP 2005), Genova,Italia, Setembro 2005.

252 236 APÊNDICE A DETALHAMENTO DAS TRANSFORMAÇÕES COMPORTAMENTAIS A.1 INTRODUÇÃO Este apêndice descreve as decisões de projeto tomadas para as transformações comportamentais apresentas na seção A.2 TRANSFORMAÇÕES COMPORTAMENTAIS A primeira decisão de projeto define que é necessário criar uma nova atividade de mais alto nível de abstração chamada Buscar ficha do paciente, que abstrai a atividade Fornecer cartão de consulta ao recepcionista, de responsabilidade do Paciente, e as atividades Elaborar ficha do paciente e Anexar ficha do paciente ao prontuário médico, de responsabilidade do Recepcionista. A decisão de projeto também define que o responsável pela nova atividade é o Recepcionista. Para aplicar essa decisão de projeto foi construída uma Transformação de Abstração que possui uma Parametrização de Automatização que define a atividade como gerenciada. A Figura A.1 apresenta o resultado da decisão de projeto após a transformação de abstração. Como a Transformação de Abstração, apresentada na Figura 6.2, envolveu atividade de responsáveis distintos (raias diferentes) foi necessária a escolha de um dos responsáveis para a nova atividade, respeitando as regras da Transformação de Abstração apresentadas na seção

253 Figura A.1 - Criando o componente Buscar ficha do paciente. 237

254 238 A segunda decisão de projeto define que é necessário abstrair a atividade Relatar sintomas, da responsabilidade do Paciente, e o conjunto de atividades Investigar histórico clínico do paciente, Investigar histórico pessoal do paciente, Investigar histórico familiar do paciente, Realizar exame físico e Decidir necessidade de exames para confirmar hipótese de diagnóstico, da responsabilidade do Médico, para criar uma nova atividade de mais alto nível. Essa nova atividade é chamada de Examinar o paciente que será da responsabilidade do Médico. Para aplicar essa decisão de projeto foi construída uma Transformação de Abstração que possui uma Parametrização de Automatização que define que atividade será gerenciada. A Figura A.2 mostra o resultado da segunda decisão de projeto após aplicar a transformação de abstração. Na atividade Examinar o paciente o médico também informa se há necessidade de novos exames laboratoriais e, caso sejam necessários, quais exames devem ser realizados pelo paciente. Figura A.2 - Criando o componente Examinar o paciente. A próxima decisão de projeto define que a atividade Solicitar exames laboratoriais, da responsabilidade do Médico, e as atividades Registrar folha de faturamento no sistema e Registrar no sistema data do agendamento de retorno, de responsabilidade da Recepcionista, serão abstraídas em uma nova atividade de mais alto nível chamado de Solicitar exames laboratoriais. A decisão de projeto também definiu que essa

255 239 atividade será totalmente automatizada e que será desempenhada pelo sistema computacional chamado Sistema de solicitação de exames. Desta forma, para aplicar tal decisão de projeto foi selecionada uma Transformação de Abstração que transforma as atividades selecionadas em uma atividade de mais alto nível e que será desempenhada por um sistema. Em outras palavras, foi criada uma transformação de abstração com uma Parametrização de Automatização para transformar a atividade em totalmente automatizada. A Figura A.3 apresenta a transformação da terceira decisão de projeto. Figura A.3 - Criando o componente totalmente automatizado Solicitar exames laboratoriais. Ao analisar o modelo do processo de negócio, o projetista definiu que as atividades as atividades Elaborar hipótese de diagnóstico e Verificar fechamento do diagnóstico, ambas de responsabilidade do Médico, podem ser abstraídas em apenas uma atividade de mais alto nível de abstração chamada Elaborar diagnóstico preliminar. A nova atividade é de responsabilidade do Médico. Logo, foi criada uma transformação de abstração que abstrai as atividades citadas e cria a atividade de mais alto nível chamada Elaborar diagnóstico preliminar como gerenciada pelo Médico. A Figura A.4 apresenta transformação de abstração utilizada para construir a nova atividade Elaborar diagnóstico preliminar.

256 240 Figura A.4 - Quinta transformação no nível de independente de plataforma. Durante a análise do processo foi identificado no modelo de processo de negócio que as atividades Encaminhar paciente ao diagnóstico, Agendar ambulatório de diagnóstico para paciente, de responsabilidade do Médico, e as atividades Registrar folha de faturamento no sistema e Registrar no sistema data do agendamento de retorno, de responsabilidade do Recepcionista, podem ser abstraídas, gerando uma nova atividade de mais alto nível. Desta forma, o projetista definiu que é necessário criar uma transformação de Abstração que una tais atividades e crie uma nova atividade de maior nível de abstração denominado Encaminhar paciente e agendar ambulatório que será da responsabilidade do Médico. A Figure A.5 apresenta o resultado dessa decisão de projeto após a transformação.

257 241. Figure A.5 - Criando o componente Encaminhar paciente e agendar ambulatório. Dando continuidade à transformação do modelo de processo em um modelo estrutural do workflow, o projetista identificou que as atividades Fornecer recomendações complementares ao paciente e Conceder alta ao paciente, de responsabilidade do Médico, e a atividade Registrar folha de faturamento no sistema, de responsabilidade do Recepcionista, podem ser abstraídas em uma atividade de mais alto nível. O projetista definiu que a nova atividade será chamada de Conceder alta e será da responsabilidade do Médico. A Figura A.6 apresenta a decisão de projeto que originou o componente Conceder alta.

258 242 Figura A.6 - Criando o componente Conceder alta. Para aplicar a decisão de projeto acima, foi necessário criar uma transformação de abstração que abstraiu as atividades do Médico e Recepcionista e cria a nova atividade Conceder alta como gerenciada pelo médico. A análise do processo de negócio identificou que o conjunto de atividade presentes no retângulo pontilhado presente na Figura A.7 pode ser abstraída em uma atividade do processo de maior nível de abstração. O projetista também definiu que a nova atividade será da responsabilidade do Médico. Para satisfazer essa decisão de projeto, foi criada uma transformação de abstração que abstrai as atividades contidas dentro do retângulo pontilhado e cria uma nova atividade de mais alto nível chamado de Encaminhar paciente para ambulatório. A Figura A.7 apresenta a decisão de projeto que originou o componente Encaminhar paciente para ambulatório.

259 243 Figura A.7 - Criando o componente Encaminhar paciente para ambulatório. A transformação que criou a atividade Encaminhar paciente para ambulatório (Figura A.7) é uma demonstração de como a Transformação de Abstração pode ser aplicada em um ou mais padrões de processo. Neste caso, a transformação foi aplicada sobre os padrões de processo Sequence, XOR-Split e XOR-Join que, em conjunto, formam um componente, desta forma, permitindo, desta forma, que a Transformação de abstração crie uma atividade de mais alto nível. A próxima decisão de projeto aplicada ao modelo de processo visa abstrair todo o conjunto de atividades presente no retângulo pontilhado da Figure A.8 e construir uma atividade de maior nível de abstração, denominada Explicar o diagnóstico ao

260 244 paciente. O projetista também definiu que a nova atividade será da responsabilidade do Médico. Para aplicar a decisão de projeto apresentado na Figure A.8, foi necessária a construção de uma Transformação Abstração que abstrai todo o conjunto de atividades presente no retângulo e, assim, criar a nova atividade Explicar o diagnóstico ao paciente. O nível de automatização deste novo componente é gerenciada. Para as atividades Verificar realização prévia de exames laboratoriais, Analisar resultados dos exames, Verificar existência de doença reumatológica e Verificar complexidade da doença reumatológica a decisão de projeto foi simplesmente definilas como atividades que serão gerenciadas por seus responsáveis. Neste caso, por coincidência, todas as atividades são da responsabilidade do Médico. Assim, para aplicar tal decisão de projeto no modelo de processo, foi criada uma transformação para cada atividade do processo citada acima que descreve que o nível de automatização delas é gerenciada.

261 Figure A.8 - Criando o componente Explicitar o diagnóstico ao paciente 245