henrique prado sousa integrando modelagem intencional à ...julio/diss-henrique.pdf · modelagem de...

Henrique Prado Sousa

Integrando modelagem intencional

à modelagem de processos

Dissertação de Mestrado

Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo Programa de Pós-Graduação em Informática do Departamento de Informática da PUC-Rio.

Orientador: Prof. Julio Cesar Sampaio do Prado Leite

Rio de Janeiro

fevereiro de 2012


Integrando modelagem intencional à

modelagem de processos

Dissertação apresentada como requisito parcial para obtenção do grau de Mestre pelo Programa de Pós-Graduação em Informática do Departamento de Informática do Centro Técnico e Científico da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada.

Prof. Edward Hermann Haeusler Presidente

Departamento de Informática – PUC-Rio

Prof. Julio Cesar Sampaio do Prado Leite Orientador

Departamento de Informática – PUC-Rio

Prof.ª Cláudia Cappelli Departamento de Informática – Unirio

Prof. José Eugênio Leal Coordenador Setorial do Centro Técnico

Científico – PUC-Rio

Rio de Janeiro, 17 de fevereiro de 2012

Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador.


Graduou-se em Bacharelado em Sistemas de Informação na Universidade Federal do Estado do Rio de Janeiro (UNIRIO) em 2010. Desde 2006 participa do núcleo de pesquisa NP2Tec, da UNIRIO. Desde 2010 participa do grupo de engenharia de requisitos da PUC-Rio, coordenado pelo professor Julio Leite.

Ficha Catalográfica

Sousa, Henrique Prado Integrando modelagem intencional à modelagem de processos / Henrique Prado Sousa ; orientador: Julio Cesar Sampaio do Prado Leite. – 2012. v., 138 f,; Il. ; 30 cm

1. Dissertação (mestrado) – Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Informática, 2012.

Inclui referências bibliográfias

1. Informática – Teses. 2. Engenharia de requisitos.

3. Modelagem de processos de negócio. 4. Modelagem de objetos. 5. BPM. 6. BPMN. 7. i*. 8. Integração de processos e objetivos. 9. Alinhamento de processos e objetivos. 10. KPI. 11. Indicadores. I. Leite, Julio Cesar Sampaio do Prado. II. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. III. Título.

CDD: 004

Agradecimentos

Não há como iniciar uma página de agradecimento contida em mais um trabalho de

grande valor em minha vida, sem colocar em primeiro lugar Aquele que foi o único a me

acompanhar integralmente passo a passo durante todas as minhas vidas. Sim! És tu!

Meu Deus! Muito obrigado!

Agora, é claro, agradeço aos meus pais todos os esforços empenhados unicamente ao

meu crescimento pessoal, muito frequentemente, abdicando a si somente para doar a

mim ainda mais carinho e dedicação. Espero estar correspondendo a todas as

expectativas, de forma a recompensar justamente tudo o que me foi dado. Eternos

agradecimentos!

Em sequencia vem uma pessoa muitíssima especial para mim. Aquela que iniciou,

propiciou e alavancou juntinho de mim toda essa vida de nerd alucinado que só começou

depois de quase 20 anos de pura diversão. Ela que me motivou e ajudou em todos os

momentos de puras tribulações durante o caminho de ascensão intelectual nos últimos 8

anos. À minha noiva linda, agradeço de coração!

Agora sim, o momento mais esperado da página de agradecimentos! Fico impressionado

com as pessoas que nascem com tal dom. Ensinar é uma atividade que até pode ser

realizada por qualquer um, mas para executá-la em sua plenitude, é necessário muito

mais do que conhecimento sobre uma disciplina, tem que ter o dom que engloba

habilidades que vão desde o feeling de identificar apenas através da observação se o

aluno está entendendo, passando por paciência, paciência e paciência, até a capacidade

de ser carismático! São essas pessoas que me motivam todos os dias em minha vida, e

mal sabem que são meus verdadeiros heróis que quero ser quando crescer! Aos meus

eternos orientadores Julio Leite, Flávia Santoro e Leonardo Azevedo, MUITO

OBRIGADOOO!

O que também não poderia de forma alguma estar ausente aqui são os agradecimento

aos amigos! Não adianta... Somente aqueles que estão no mesmo barco é que, na hora

de fazer funcionar, giram a manivela com você. Seja para melhorar o seu artigo ou para

chorar a nota de PAA, eles sempre estarão lá ao seu lado, motivando, agregando e

dedicando à construção de um amigo cada vez melhor! Aos amigos André, Eduardo,

Herbet, Leandro, Marx, e todo o grupo de Engenharia de Requisitos da PUC-Rio,

broadcast de agradecimentos!!!

5

Resumo

Sousa, Henrique Prado; Leite, Julio Cesar Sampaio do Prado. Integrando modelagem intencional à modelagem de processos. Pontifícia Universidade Católica do Rio de Janeiro, 2012. 138p. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

A modelagem de processos de negócio é utilizada por empresas que

desejam documentar detalhes do fluxo de execução de seus processos,

resultando em um documento rico em detalhes sobre o negócio. Este artefato

também é utilizado pela Engenharia de Software para elicitação de requisitos de

sistema. A modelagem intencional possui foco na modelagem de objetivos -

definidos como metas e metas flexíveis - e registra as estratégias que podem ser

seguidas por um ator de forma a melhor atender suas necessidades, mapeando

tarefas e recursos necessários, além disso, também aborda as dependências

entre atores. É importante que os modelos de processos de negócio estejam

alinhados aos objetivos da organização de forma a prover fonte de informações

confiável que gere consequentemente requisitos alinhados ao negócio. Diversas

ferramentas estão disponíveis no mercado com o objetivo de apoiar a

modelagem dos processos de negócio e dos objetivos organizacionais,

entretanto, percebe-se que as soluções disponíveis ainda são incompletas

quando se fala na integração de modelos de processos com modelo de

objetivos, e em formas de verificação do alinhamento entre processos e objetivos

organizacionais a partir da modelagem. Apesar dos processos de negócio e

objetivos serem intrinsecamente interdependentes na arquitetura organizacional,

as linguagens de modelagem atuais não oferecem recursos suficientes para

tratar processos e objetivos de forma alinhada, uma vez que existem deficiências

na integração entre a camada de modelagem de objetivos e de processos.

Assim, o uso do ferramental disponível que se apoia nessas linguagens e

métodos dificulta sobremaneira a tarefa de identificar se os processos utilizados

para gerar serviços e produtos, verdadeiramente atingem os objetivos da

organização, bem como o impacto que as mudanças nos objetivos causariam

nos processos de negócio. Neste trabalho integramos uma linguagem de

6

modelagem de objetivos a uma linguagem de processos de negócio e provemos

os elementos e métodos necessários para ampliar a capacidade de análise do

alinhamento dos processos de negócio às estratégias organizacionais.

Palavras-chave

Engenharia de requisitos, Modelagem de processos de negócio,

Modelagem de objetivos, BPM, BPMN, i*, Integração de processos e objetivos,

Alinhamento de processos e objetivos, KPI, indicadores.

7

Abstract

Sousa, Henrique Prado; Leite, Julio Cesar Sampaio do Prado (Advisor). Integrating intentional modeling to business process modeling. Pontifícia Universidade Católica do Rio de Janeiro, 2012. 138p. Dissertação de Mestrado - Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

The business processes modeling is used by companies which wish to

document details of the execution flow of their processes, resulting in a document

rich in details about the business. This artifact is also used by the Software

Engineering to elicit system requirements. The intentional modeling is focused on

objectives - defined as goals and softgoals - and registers the strategies that may

be followed by an actor in order to better meet their needs and mapping tasks

and resources, furthermore, it also addresses the dependencies between actors.

It is important that business processes models are aligned to the organization’s

objectives in order to provide reliable information source that consequently

generates requirements aligned to business. Several tools are available providing

support to business processes and organizational objectives modeling, however,

it’s possible to realize that the available solutions are still incomplete when it

comes to integration of process models and goals models and ways to check the

alignment between organizational goals and processes using these models.

Despite of business processes and goals are intrinsically interdependent in the

organizational architecture, the current modeling languages generally treat

process and goals separately, since there are deficiencies in the integration

between the modeling layer of objectives and processes. Thus, the use of the

available tools that supports these languages and methods greatly complicates

the task of identify if the processes used to generate products and services truly

achieve the organizational goals, as well as the impact of the changes in the

goals would cause in business processes. In this work we integrated a goal

modeling language to a business processes modeling language and provided the

elements and methods required to expand the capacity of analysis of the

alignment between the business processes and the organizational goals.

8

Keywords

Requirements engineering, Business processes modeling, Objectives

modeling, BPM, BPMN, i*, Integration of processes and goals, alignment of

processes and goals, KPI, Indicators.

9

Sumário

1 Introdução ................................................................................................................ 13

1.1. Detalhamento do contexto ....................................................................... 16

1.2. Abordagem proposta ............................................................................... 17

1.3. Trabalhos relacionados ........................................................................... 19

1.4. Organização do documento .................................................................... 20

2 Marco Teórico .......................................................................................................... 21

2.1. Introdução ............................................................................................... 21

2.2. UML ........................................................................................................ 23

2.2.1. Extensões do diagrama de processo ................................................ 25

2.2.2. Extensões do diagrama de objetivos ................................................ 28

2.3. BPMN ...................................................................................................... 31

2.3.1. Processos privados........................................................................... 32

2.3.2. Processos públicos ........................................................................... 33

2.3.3. Processos colaborativos ................................................................... 33

2.3.4. Notação ............................................................................................ 34

2.4. Framework i* ........................................................................................... 36

2.4.1. Strategic Dependency (Modelo SD) .................................................. 37

2.4.2. Strategic Rationale (Modelo SR) ....................................................... 40

2.5. URN (UCM e GRL) .................................................................................. 45

2.5.1. GRL .................................................................................................. 46

2.5.2. UCM ................................................................................................. 48

2.5.3. Rastreabilidade entre UCM e GRL .................................................... 50

2.6. Framework ARIS ..................................................................................... 51

2.6.1. VAC – Valued Added Chain .............................................................. 52

2.6.2. EPC – Event-driven Process Chain .................................................. 53

2.6.3. FAD – Function Allocation Diagram .................................................. 54

2.6.4. Diagrama de objetivos ...................................................................... 54

10

2.7. Seleção de linguagens ............................................................................ 57

2.7.1. Domínio de processos de negócio .................................................... 57

2.7.2. Domínio de objetivos ........................................................................ 60

3 Arquitetura de Integração......................................................................................... 64

3.1. Similaridades entre as notações .............................................................. 64

3.2. Adaptações necessárias ......................................................................... 67

3.3. Diagrama Integrado ................................................................................. 70

3.4. Análise do alinhamento através de KPIs ................................................. 74

3.4.1. Introdução ......................................................................................... 74

3.4.2. Uso de indicadores no Diagrama Integrado ...................................... 77

3.4.3. Uso do Diagrama de Indicadores ...................................................... 81

4 Implementação da Integração .................................................................................. 84

4.1. Ferramenta Oryx ..................................................................................... 84

4.2. Estudo da ferramenta .............................................................................. 85

4.2.1. Aplicando a Engenharia Reversa ...................................................... 87

4.2.2. Reengenharia de software ................................................................ 99

4.3. Testes ................................................................................................... 103

5 Exemplo de aplicação ............................................................................................ 110

5.1. Modelo de processo .............................................................................. 111

5.2. Modelo SR ............................................................................................ 113

5.3. Integração dos modelos ........................................................................ 114

5.4. Modelagem dos indicadores .................................................................. 116

5.5. Análise e desenvolvimento de relatórios ............................................... 118

6 Conclusão .............................................................................................................. 123

6.1. Resumo ................................................................................................. 123

6.2. Comparação com trabalhos relacionados.............................................. 125

6.3. Contribuições para Transparência do Processo .................................... 127

6.4. Trabalhos futuros .................................................................................. 129

7 Referências bibliográficas ...................................................................................... 130

11

Lista de figuras

Tabela 1 - Elementos de um diagrama de processo de negócio em UML................... 25 Tabela 2 – Elementos de um diagrama de objetivos em UML .................................... 28 Tabela 3 – Recursos e regras compõem todos os diagramas ..................................... 31 Tabela 4 – Elementos básicos da BPMN .................................................................... 34 Tabela 5 – Elementos de um modelo SD .................................................................... 39 Tabela 6 – Elementos do modelo SR .......................................................................... 43 Tabela 7 – Elementos do modelo GRL ....................................................................... 47 Tabela 8 – Elementos do modelo UCM....................................................................... 48 Tabela 9 – Elementos de um diagrama de objetivos ................................................... 55 Tabela 10 – Conexões permitidas entre os elementos do diagrama de objetivos ....... 55 Tabela 11 – Comparação entre as linguagens de modelagem de processos ............. 63 Tabela 12 – Comparação entre as linguagens de modelagem de objetivos ................ 63 Tabela 13 – Similaridades entre elementos do i* e BPMN .......................................... 65 Tabela 14 – Novos elementos incluídos ao Diagrama Integrado ................................ 78 Tabela 15 – Elementos do Diagrama de Indicadores .................................................. 81 Tabela 16 – Projeção de macroatividades da engenharia reversa da ferramenta Oryx87 Tabela 17 – Teste gráfico ......................................................................................... 105 Tabela 18 – Teste de regras do tipo Containment Rules .......................................... 105 Tabela 19 – Teste de regras do tipo Cardinality Rules .............................................. 105 Tabela 20 - Teste de regras do tipo Connection Rules ............................................. 106 Tabela 21 - Teste gráfico para o elemento Agent (Diagrama SD) ............................. 106 Tabela 22 – Teste gráfico para o elemento meta (Diagrama SD) ............................. 107 Tabela 23 – Teste da regra Containment Rule para o elemento AgentLane (Diagrama SD) ........................................................................................................................... 107 Tabela 24 - Teste da regra Cardinality Rule para os elementos do tipo Evento inicial108 Tabela 25 - Teste da regra Connection Rule para os elementos que utilizam o relacionamento Dependency (Diagrama SD) ............................................................ 109 Tabela 26 – Detalhamento dos indicadores inseridos no Diagrama Integrado .......... 117 Tabela 27 – Resumo de associação entre principais elementos ............................... 119 Tabela 28 – Tabela de descrição de indicadores ...................................................... 120 Tabela 29 – Tabela de descrição do recurso crítico .................................................. 120 Tabela 30 – Detalhamento de recursos críticos não identificados no processo......... 121 Tabela 31 – Correlação entre recursos críticos e papéis responsáveis ..................... 121

12

Lista de tabelas

Tabela 1 - Elementos de um diagrama de processo de negócio em UML................... 25 Tabela 2 – Elementos de um diagrama de objetivos em UML .................................... 28 Tabela 3 – Recursos e regras compõem todos os diagramas ..................................... 31 Tabela 4 – Elementos básicos da BPMN .................................................................... 34 Tabela 5 – Elementos de um modelo SD .................................................................... 39 Tabela 6 – Elementos do modelo SR .......................................................................... 43 Tabela 7 – Elementos do modelo GRL ....................................................................... 47 Tabela 8 – Elementos do modelo UCM....................................................................... 48 Tabela 9 – Elementos de um diagrama de objetivos ................................................... 55 Tabela 10 – Conexões permitidas entre os elementos do diagrama de objetivos ....... 55 Tabela 11 – Comparação entre as linguagens de modelagem de processos ............. 63 Tabela 12 – Comparação entre as linguagens de modelagem de objetivos ................ 63 Tabela 13 – Similaridades entre elementos do i* e BPMN .......................................... 65 Tabela 14 – Novos elementos incluídos ao Diagrama Integrado ................................ 78 Tabela 15 – Elementos do Diagrama de Indicadores .................................................. 81 Tabela 16 – Projeção de macroatividades da engenharia reversa da ferramenta Oryx87 Tabela 17 – Teste gráfico ......................................................................................... 105 Tabela 18 – Teste de regras do tipo Containment Rules .......................................... 105 Tabela 19 – Teste de regras do tipo Cardinality Rules .............................................. 105 Tabela 20 - Teste de regras do tipo Connection Rules ............................................. 106 Tabela 21 - Teste gráfico para o elemento Agent (Diagrama SD) ............................. 106 Tabela 22 – Teste gráfico para o elemento meta (Diagrama SD) ............................. 107 Tabela 23 – Teste da regra Containment Rule para o elemento AgentLane (Diagrama SD) ........................................................................................................................... 107 Tabela 24 - Teste da regra Cardinality Rule para os elementos do tipo Evento inicial108 Tabela 25 - Teste da regra Connection Rule para os elementos que utilizam o relacionamento Dependency (Diagrama SD) ............................................................ 109 Tabela 26 – Detalhamento dos indicadores inseridos no Diagrama Integrado .......... 117 Tabela 27 – Resumo de associação entre principais elementos ............................... 119 Tabela 28 – Tabela de descrição de indicadores ...................................................... 120 Tabela 29 – Tabela de descrição do recurso crítico .................................................. 120 Tabela 30 – Detalhamento de recursos críticos não identificados no processo......... 121 Tabela 31 – Correlação entre recursos críticos e papéis responsáveis ..................... 121

13

1 Introdução

Os modelos de processos de negócio são normalmente desenvolvidos para uso

na Reengenharia de Processos de Negócio (RPN) com o objetivo de alcançar

melhorias e reduzir custos [Paim02]. Entretanto, a modelagem de processos de

negócio também possui importância na Engenharia de Software.

Uma vez que os modelos de processos de negócio registram um conjunto de

elementos que representam fluxos de consumo e produção de artefatos e

informações, atividades, requisitos, regras de negócio, sistemas de apoio e diversos

outros elementos pertinentes à execução de seus processos, é possível, por exemplo,

realizar análises e criar um mapeamento entre o modelo e uma arquitetura de software

[Villarroel06], [Marquioni05], [Soeli95] (Figura 1).

Figura 1 – Relacionamento de processos de negócio e arquitetura de componentes [Adaptação

[Junior03 apud Villarroel06]]

Outro exemplo de aplicação de modelos de processos de negócio é na

identificação de serviços (considere também serviços como requisitos de software)

[Azevedo09] [Sousa10], [Josuttis07] (Figura 2).

14

Figura 2 – Relacionamento de processos de negócios e funcionalidades de software [Diirr11]

Além disso, os modelos de processos de negócio podem servir como insumo

para estudo do domínio na fase de elicitação de requisitos, bem como um modelo

gráfico que facilita a comunicação com o cliente. A Modelagem de Processos de

Negócio auxilia tanto a equipe de desenvolvimento quanto ao cliente a descobrirem “o

que ele quer” e evidenciar o “óbvio” (minimizam surpresas) [Villarroel06].

Sob a ótica do cliente, a realização deste mapeamento permite que ele visualize

melhor a amplitude do seu negócio e consequentemente dimensione com mais

precisão quais processos podem ser informatizados (a partir da identificação de

gargalos, focos de retrabalho e outras possibilidades de melhoria). Sob a ótica da

equipe de desenvolvimento, o mapeamento permite identificar ambiguidades no

discurso do usuário durante o elicitação, evidenciar o óbvio, além de permitir relação

direta com a lista de requisitos a ser confeccionada [Villarroel06].

15

Trata-se então, de uma prática interessante de determinação de prioridades a

desenvolver, além de que, em se tratando de representação gráfica, o cliente poderá

criticar o que for omitido ainda em tempo de elicitação, e não apenas quando ele tiver

à disposição algo mais “concreto”, como uma tela já funcional. No mínimo isto irá

reduzir significativamente o retrabalho da equipe de desenvolvimento em produtos já

construídos [Villarroel06].

Os modelos de processos de negócio têm tipicamente um alcance maior em

detalhes, sendo mais inclusivos que um sistema de software, possibilitando assim, que

o engenheiro de requisitos defina claramente o que está no âmbito do sistema

proposto e o que será implementado em outra oportunidade. Também, associado ao

custo-benefício, pode prover a justificativa para construir um novo sistema baseado no

modelo atual.

Qualquer que seja a técnica utilizada para elicitação de requisitos, tão importante

quanto a elicitação em si, é realizar a sua formalização. Sistematizações diretamente

em linguagem natural (mesmo que em uma lista de requisitos) podem omitir

informações importantes que não ficam visíveis em função da ausência de

estruturação dos requisitos. Os métodos que sustentam o levantamento de processos

(por exemplo, RUP e ICONIX) constituem aliados importantes para a equipe de

desenvolvimento, pois geram mais estabilidade e visibilidade dos requisitos a serem

implementados [Marquioni05].

Portanto, ao utilizar esse artefato para derivar serviços, é possível alcançar

maior alinhamento da TI com o negócio [JOSUTTIS, 2007], uma vez que ele provê

fonte de informação consideravelmente mais segura quanto aos problemas

tradicionais de comunicação e interpretação entre o engenheiro de requisitos e o

cliente.

Entretanto, existe outro ponto de vista que deve ser considerado. Os processos

de negócio são projetados para atingir os objetivos do negócio, porém, um modelo de

processo de negócio, mesmo bem feito, pode gerar um sistema de informação

desalinhado caso o processo de negócio esteja desalinhado aos objetivos do negócio

[Cardoso11]. O sistema herda de seus requisitos, que são extraídos de um processo

de negócio, o desalinhamento existente entre os processos e os objetivos do negócio.

Isso indica que é um fator fundamental o desenvolvimento de métodos,

linguagens e ferramentas que permitam a análise do alinhamento dos processos de

negócio em relação aos seus objetivos. Diversos trabalhos são desenvolvidos nesta

linha, no entanto, é um consenso que o tema alinhamento de processos e objetivos

não é simples e gera diferentes conceitos e visões acerca de seus elementos

[Kefi&Kalika05], [Singh&Woo09], [Cardoso11].

16

A complexidade do domínio, bem como a sua importância, justifica a

continuidade de estudos na área.

1.1. Detalhamento do contexto

No contexto das organizações, a competitividade acirra-se em função de

mudanças em políticas, padrões e novas necessidades dos consumidores. Somem-se

a isso as recentes crises financeiras que obrigam às organizações responderem

rapidamente às dificuldades e oportunidades que surgem nesses momentos. Isso

demanda uma evolução dos processos empresariais porque as organizações agregam

e/ou alteram seus objetivos estratégicos para corresponder às mudanças. Esse

relacionamento direto entre objetivos e processos organizacionais é crítico, uma vez

que só a partir disto é possível medir a eficiência e eficácia do negócio. Portanto as

informações “processo x objetivo” são necessárias no ambiente organizacional e

devem ser monitoradas frequentemente para que seja possível gerir o nível de

atendimento da execução dos processos aos objetivos do negócio.

No contexto tecnológico, os sistemas computacionais devem responder em

tempo hábil às demandas dos novos requisitos que partem das alterações constantes

nos processos organizacionais. Os engenheiros de software devem estar aptos a

garantir o alinhamento da TI com o negócio e podem usufruir dos modelos de

processos e objetivos como insumo para o entendimento do problema e planejamento

correto das soluções.

Diversas ferramentas estão disponíveis no mercado com o objetivo de apoiar a

modelagem dos processos de negócio e dos objetivos organizacionais, entretanto,

percebe-se que as soluções disponíveis ainda são incompletas quando se fala na

integração de modelos de processos e modelo de objetivos [Behnam10], [Braubach

10], [Cardoso11], [Singh&Woo09]. Na arquitetura organizacional, processos de

negócio e objetivos coexistem e se relacionam, porém, as linguagens de modelagem

atuais são insuficientes em apresentar recursos que mantenham rastreabilidade e

alinhamento entre os modelos.

Por exemplo, alguns autores apontam a existência de ênfase dada à modelagem

funcional [Chung&Leite09], isto é, centrada em como fazer/executar os processos

(entre exemplos de diagrama com estas características podemos citar o workflow,

diagramas de atividade e o diagrama EPC1), sendo pouco frequente que qualidades

1 Neste trabalho a sigla EPC referencia ao diagrama Event-driven Process Chain e não à notação

proprietária que utilizada na arquitetura ARIS (Architecture of Integrated Information Systems), conforme citam alguns trabalhos.

17

do processo, em função de distintas demandas gerenciais, estejam explicitamente

modeladas. De maneira geral, os processos irão possuir atividades que implementam

características de qualidade, mas sem explicitá-las. Ocorre que ao centrar na

funcionalidade existe a possibilidade de que o modelo de processos deixe de

considerar algumas características de qualidade que deveriam estar presentes. Isso,

como já apontado na literatura por [Kueng&Kawalek97], [Soffer&Wand05],

[Cappelli10], é um problema com graves consequências.

Um dos motivos para que isso ocorra, é o maior enfoque no desenvolvimento de

soluções que representam o contexto prático dos processos, oferecendo maior

detalhamento ao nível de atividades (operacional), o que não ocorre nos modelos de

objetivos. De certa forma, os usuários das linguagens de modelagem são induzidos a

dar maior importância na modelagem de baixo nível, o que também pode ser

interpretado como herança da visão de workflow ou, ainda, de diagramas de

atividades da UML [OMG11b]. Assim, o uso do recurso de modelagem nas

ferramentas disponíveis dificulta sobremaneira a tarefa de identificar se os processos

utilizados para gerar serviços e produtos, verdadeiramente atingem os objetivos da

organização, nem o impacto que as mudanças nos objetivos causariam nos processos

de negócio [Cardoso11]. Outro efeito colateral possível é a separação da modelagem

de processos e da modelagem de objetivos em relação às equipes de levantamento

de informações e modelagem. Na atribuição da modelagem dos processos, encontra-

se uma equipe modelando os processos dos diferentes departamentos, tendo como

fontes de informação os funcionários que geralmente possuem uma visão estritamente

prática de suas atividades, enquanto na modelagem de objetivos, encontra-se o alto

escalão da organização, definindo com a visão gerencial os objetivos organizacionais.

Nesta situação o problema ocorre porque o modelo de objetivos e o modelo de

processos são feitos separadamente, e as fontes de informação do nível operacional

não compartilham a mesma visão das fontes de informação do nível gerencial. Além

disso, os processos podem ser modelados por grupos distintos, facilitando a inserção

de diferentes detalhes no produto final de modelagem por motivos de ausência de

padrão rigoroso.

1.2. Abordagem proposta

O objetivo deste trabalho é integrar uma linguagem de modelagem de objetivos

a uma linguagem de modelagem de processos de negócio e prover os elementos e

métodos necessários para oferecer maior capacidade de representação dos

relacionamentos entre processos e seus objetivos, explicitar a rastreabilidade entre os

18

elementos envolvidos e contribuir positivamente com a transparência do processo,

ampliando assim a capacidade de análise do alinhamento dos processos de negócio

às estratégias organizacionais.

Nossa proposta não considera o uso de métodos aliados a linguagens que, com

apoio de softwares, inserem novas capacidades que compõem um “produto”

ferramental (por exemplo, ferramentas que implementam BSC – Balanced Scorecard

[BSI12]), mas sim a capacidade das linguagens, notações e respectivos ambientes de

modelagem em expressar os elementos do domínio de objetivos, processos e suas

correlações. Desta forma, busca-se reduzir o distanciamento encontrado atualmente

entre modelos de objetivos e processos. Ainda propomos um método de uso de

indicadores relacionados a elementos do processo como forma de medir sua

capacidade em alcançar seus objetivos. Nossas propostas visam principalmente

contribuir na questão da análise do alinhamento entre processos e seus objetivos, o

que engloba a verificação da capacidade dos processos em satisfazer seus objetivos,

a facilitação na identificação de impactos resultantes de alterações nos objetivos

estratégicos, e a melhoria dos processos de forma a tornarem-se mais eficientes.

Neste estudo, foram avaliadas as principais linguagens para modelagem de

objetivos e processos de negócio em relação à sua capacidade de integração entre os

modelos de objetivos e modelos de processos (apenas nas linguagens que oferecem

ambos os recursos), além dos recursos gráficos disponíveis para representação dos

elementos do negócio, como forma de identificar a linguagem mais adequada para a

modelagem de processos e objetivos. Posteriormente, projetamos a integração destas

linguagens também incluindo elementos que facilitassem a análise do alinhamento

entre os modelos.

As linguagens e os recursos de integração foram implementados a partir do

reuso de código e customização da ferramenta Oryx [Daniel07], [Oryx12], [Peters07],

[Tscheschner07]. A ferramenta Oryx é um framework acadêmico Open Source para

modelagem gráfica de processos de negócio. Sua tecnologia é baseada em web,

sendo executado através de browser, o que elimina a necessidade de instalação do

software. Esta ferramenta foi desenvolvida originalmente com o objetivo de oferecer

elementos BPMN para a modelagem de processos de negócio, no entanto, sua

arquitetura foi desenvolvida separando o núcleo da aplicação e a interface, facilitando

a programação de novos elementos e linguagens ao requisitar somente a manipulação

da camada de interface.

Para integrar as linguagens, foram desenvolvidas na ferramenta Oryx novas

visões, relacionamentos e elementos para possibilitar a comunicação e alinhamento

das notações, possibilitando a união das definições e semântica específica de cada

19

linguagem. As alterações necessárias para criar uma “interface” que permita o contato

entre os elementos foram projetadas e implementadas na ferramenta, criando uma

terceira linguagem que possibilita ao usuário usufruir da capacidade das linguagens

em um único modelo.

1.3. Trabalhos relacionados

Com o objetivo de integrar o framework ARIS e a linguagem de modelagem de

objetivos Tropos, [Cardoso10] mapeia as relações semânticas entre os elementos

similares das linguagens. Neste trabalho os autores apontam o problema de

alinhamento interno de cada linguagem, que é o foco principal deste trabalho.

Enquanto o ARIS é amplamente utilizado para modelagem de processo de negócios,

apresenta uma linguagem pouco expressiva para objetivos. A linguagem Tropos, por

sua vez, compreende conceitos e técnicas que permitem a captura e análise de

objetivos, mas não aborda modelagem de processo de negócios de forma detalhada.

Os autores ainda consideram os diferentes enfoques na arquitetura organizacional, e

utilizam uma abordagem ontológica (UFO - Unified Foundational Ontology) para

mapear as duas linguagens a partir da interpretação dos seus conceitos.

Em [Cardoso11] são propostas taxonomias para modelos de objetivos de

negócio com o propósito de “harmonizar” as diferenças no domínio dos objetivos e dos

processos como forma de facilitar o alinhamento posterior dos modelos. Os autores

defendem a dificuldade de se alinhar objetivos a processos de negócio e relevam que

os objetivos são desenvolvidos em vários níveis de abstração e precisão, podendo

referenciar vários aspectos da organização e seus processos. A taxonomia proposta

equaliza o domínio de objetivos, os conceitos envolvidos em cada categoria da

taxonomia e as implicações na estrutura dos processos de negócio que apoiam esses

objetivos.

O trabalho [Shamsaei10] destaca a necessidade de garantir o alinhamento dos

processos a regras internas e externas que devem ser obrigatoriamente obedecidas e

propõe um método que permite avaliar o nível de alinhamento/discordância dos

processos de negócio em relação a essas regras. O método utiliza a extensão da

notação URN para o uso de KPIs (Key Performance Indicator) com o objetivo de medir

o alinhamento, sendo composto por quatro passos que parte da modelagem,

passando pela análise e melhoramento dos modelos e finalizando em seu

monitoramento, baseado nos KPIs. Os elementos utilizados pelo método são os

objetivos organizacionais, processos de negócio e regras, e o seu produto é o nível do

alinhamento dos processos e a identificação dos processos que necessitam de

20

melhoramento. Links de rastreamento são estabelecidos entre os modelos

organizacionais e de regulamentações, incluindo pesos de importância relativa nos

relacionamentos entre os elementos.

1.4. Organização do documento

No Capítulo 2 são revistas e resumidas as características das linguagens para

modelagem de processos e modelagem de objetivos estudadas neste trabalho. Esta

revisão visa demonstrar a pontos positivos e negativos de cada linguagem e justificar a

escolha das linguagens que foram integradas.

No Capítulo 3 é apresentada a arquitetura de integração das linguagens de

objetivo e processo, e a proposta de um método para análise do alinhamento entre os

modelos de objetivo e processo a partir do uso de indicadores.

No Capítulo 4 é detalhado como foi realizada a implementação da proposta de

integração na ferramenta Oryx.

No Capítulo 5 é apresentado um exemplo da aplicação do alinhamento dos

modelos e análise a partir dos indicadores.

No Capítulo 6 são feitas comparações com os trabalhos relacionados,

contribuições, apresentação das conclusões e trabalhos futuros.

21

2 Marco Teórico

Este capítulo apresenta análises sobre as principais linguagens de modelagem

de processos e objetivos da atualidade e demonstra as comparações e características

consideradas na seleção para posterior integração.

2.1. Introdução

Diversas linguagens estão disponíveis para a modelagem de processos de

negócio e para a modelagem de objetivos, no entanto, a maioria das linguagens é

específica dentro de seu contexto de aplicação, não apresentando meios de relacionar

seus elementos. [List&Korherr06] lista um conjunto de linguagens de modelagem de

processos de negócio e apresenta uma comparação de suas características.

Conforme demonstra a Figura 3, nenhuma das linguagens de modelagem de processo

abordada apresenta relações com a modelagem de objetivos. Essa característica

expõe uma possível tendência do mercado no desenvolvimento de soluções com

enfoque na modelagem da visão operacional, sem destaque ao relacionamento dos

processos e objetivos organizacionais, em uma visão estratégica.

Figura 3 – Avaliação da perspectiva no contexto de processos de negócio [List&Korherr06]

Ainda em uma tabela semelhante, [Pourshahid09] apresenta uma comparação

de um conjunto de notações para modelagem de processos e objetivos (Figura 4 -

apresenta três sinais representando três níveis, sendo o sinal de “visto” representando

22

“disponível”, o sinal “x” representando “indisponível”, e o sinal “+/-“ representando um

estado “intermediário, incompleto”). O trabalho demonstra a ausência de

rastreabilidade entre processos e objetivos na grande maioria das linguagens. Esse é

um forte indício da ausência do alinhamento entre os modelos nas principais

linguagens utilizadas. Além disso, a tabela corrobora com o trabalho de

[List&Korherr06] em relação a tendência de desenvolvimento de ferramentas com foco

na modelagem da visão operacional. Também expõem, partindo do ponto de vista das

linguagens de modelagem de objetivos, que existem deficiências quando analisa a

capacidade da linguagem em modelar processos.

Figura 4 – Comparação de notações e características de modelagem de processos [Pourshahid09]

Neste trabalho integramos apenas duas linguagens, sendo uma voltada para a

modelagem de processos e outra para a modelagem de objetivos. O principal objetivo

é cobrir as lacunas existentes em outras linguagens, mantendo a rastreabilidade entre

os elementos nos diversos níveis e possibilitando a análise do processo em relação

aos seus objetivos através do uso de indicadores, o que consequentemente permitirá

a avaliação do alinhamento entre os modelos.

Segundo [Pourshahid09], para apoiar o alinhamento de processos de negócio

com objetivos de negócio, a notação de modelagem deve oferecer a modelagem de

processo, modelagem de objetivo, rastreabilidade entre os modelos de objetivo e

processo, e mecanismos de avaliação do modelo de objetivos. Caso contrário, não

seria capaz de demonstrar o impacto dos processos de metas organizacionais. Além

disso, papéis coadjuvantes (ou atores / organizações), atividades (ou funções) e

eventos irão aumentar a capacidade de modelagem de processos de negócios, e

enriquecer o significado das relações entre processos de negócio e objetivos.

Em uma análise preliminar, identificamos a partir da tabela de [Pourshahid09]

(Figura 4) a ausência da modelagem de objetivos na maioria das linguagens de

modelagem de processo apresentadas, sendo ainda possível verificar que o inverso

também é verdade, ou seja, as linguagens de modelagem de objetivo não oferecem

23

recursos para modelagem de processo ou não oferecem a rastreabilidade entre os

modelos (exceto pela linguagem URN, conforme os autores apontam). No entanto, na

arquitetura organizacional, processos de negócio e objetivos são intrinsecamente

interdependentes, apesar das linguagens de modelagem atuais apresentarem

deficiências no alinhamento entre processos e objetivos.

Além do problema de alinhamento entre os modelos, observa-se grande ênfase

no desenvolvimento de linguagens que ofereçam suporte para a modelagem da visão

operacional, uma vez que são poucas as linguagens de modelagem de objetivos em

comparação com as linguagens de modelagem de processos. É possível que este fato

seja resultado da antiga visão de workflow [WMC95], aplicada de forma tradicional ao

longo dos anos, ou ainda, pelo excessivo número de ferramentas que, por muito

tempo, ofereceram (e algumas ainda oferecem) somente a modelagem de processos,

por exemplo, Arpo BPMN ++, Oryx, Bizagi, Intalio|BPMS, Signavio, Microsoft Visio,

Visual Architect e ARIS [Arpo12], [Oryx12], [Bizagi12], [Intalio12], [Signavio12],

[Visio12], [VisualArchitect12], [ARIS12]. Assim, o uso do ferramental disponível

também dificulta sobremaneira a tarefa de identificar se os processos utilizados para

gerar serviços e produtos, verdadeiramente atingem os objetivos da organização, bem

como o impacto que as mudanças nos objetivos causariam nos processos de negócio

[Cardoso10], [Cardoso11].

Para identificar as melhores características das linguagens e aplicar o reuso de

seus elementos para o desenvolvimento de uma nova linguagem integrada, as

seguintes linguagens foram analisadas: UCM e GRL (que compõem a URN), EPC e a

modelagem de objetivos do framework ARIS, UML, BPMN, i* e NFR. As próximas

subseções apresentam cada uma das linguagens e ao final a conclusão.

2.2. UML

A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é

uma linguagem visual utilizada para modelar sistemas computacionais por meio do

paradigma de Orientação a Objetos [Guedes07]. É um padrão adotado pela OMG

utilizado internacionalmente no contexto da engenharia de software e atualmente

encontra-se na versão 2.0 [OMG11a].

Esta versão é composta por 13 tipos de diagramas [Melo04] e tem como objetivo

fornecer múltiplas visões do sistema a ser modelado, permitindo a análise e a

modelagem considerando diversos aspectos, de forma a atingir a completitude da

modelagem e permitindo que cada diagrama complemente os outros. Alguns

diagramas abordam o sistema de forma mais geral, apresentando uma visão externa,

24

como é o objetivo do Diagrama de Casos de Uso, ao passo que outros oferecem uma

visão de uma camada mais profunda do software, apresentando um enfoque mais

técnico ou ainda visualizando apenas uma característica específica do sistema ou um

determinado processo [Gudes07].

No entanto, o metamodelo da UML não contempla elementos específicos para

tratar com diagramas de processos de negócio [Villarroel06], [Mili03]. Os usuários da

UML utilizam o diagrama que mais se aproxima a este propósito que é o diagrama de

atividades [Pourshahid09]. O Diagrama de Atividade se preocupa em descrever os

passos a serem percorridos para a conclusão de uma atividade específica, muitas

vezes representada por um método com certo grau de complexidade, podendo, no

entanto, modelar um processo completo [Guedes07].

Apesar disso, muitos estudiosos concordam que existe a falta de vocabulários

para expressar processos de negócio de uma forma intuitiva e natural na UML [Mili03].

Sabe-se que os diagramas de atividade oferecem a modelagem de fluxo de

sequência, papéis, atividades, eventos e hierarquias de processos, mas não oferecem

modelagem de objetivos e rastreabilidade entre os modelos de objetivos e modelos de

processos [List&Korherr06]. Além disso, certos conceitos frequentemente usados na

modelagem de processos não fazem parte do padrão UML [Eriksson&Penker00].

Para atender à demanda de modelagem de processos de negócio com uma

solução mais abrangente, os mecanismos de extensão da própria UML definidos pela

OMG foram utilizados (também conhecido como built-in extensions) [Villarroel06],

[Eriksson&Penker00].

[Eriksson&Penker00] propuseram um conjunto de extensões que, agregados ao

padrão UML, permitem a modelagem de processos de negócio. Estas extensões não

alteram o padrão UML criando uma nova linguagem, mas ampliam a sua

expressividade a partir de mecanismos naturais previstos na UML.

Entre os diversos diagramas e elementos propostos por [Eriksson&Penker00]

(Vision Statement diagram, Conceptual model, Goal model, Process diagram,

Assembly Line diagram, Use-Case diagram, Resource model, Organization model,

Information model, Statechart diagram, Interaction diagrams e System Topology

diagram), neste trabalho apenas apresentaremos os diagramas de processos (Process

diagram) e de objetivos (Goal model), e os mecanismos de interação entre eles.

Esses diagramas são apresentados a seguir, incluindo exemplos.

25

2.2.1.Extensões do diagrama de processo

O diagrama de processo proposto por [Eriksson&Penker00] é baseado no

diagrama de atividades da UML, somado a um conjunto de estereótipos que

descrevem a execução das atividades dentro de um processo, como elas interagem,

os objetos de entrada e saída, os recursos de suprimento e controle que participam no

processo, e o objetivo do processo.

O processo é representado por um objeto de atividade com estereótipo de

<<process>>, formado pelo ícone tradicional conforme descrito na Tabela 1 (além da

regra de negócio, apresentada na Tabela 3, que está disponível em todos os

diagramas). Um processo pode conter outros processos (subprocessos). A atividade é

representada por um retângulo com os lados arredondados, e também é chamada na

linguagem de “processo atômico”, ou seja, um processo que não pode ser

decomposto.

Todos os elementos que estão envolvidos com o processo são modelados ao

seu redor. O objetivo ou problema alocado ao processo é modelado acima do

diagrama de processo, relacionado através do link de dependência que contém o

estereótipo <<achieve>>, partindo do processo para o objetivo. Os outros objetos são

típicos da modelagem de processos de negócio e encontram-se detalhados na Tabela

1.

Tabela 1 - Elementos de um diagrama de processo de negócio em UML

Extensões de processo

Nome Estereótipo Símbolo Definição/Descrição

Processo Atividade

Um processo é uma descrição de um conjunto de atividades relacionadas que, quando executadas corretamente, irão satisfazer um objetivo explícito.

Atividade

(Processo atômico) Atividade

Um processo deve ser dividido em mais processos. Se estes processos são atômicos, eles são chamados de atividades.

Inicio do processo Inicio Inicia um processo

Fim do processo Fim Finaliza um processo

Objeto-para-Assembly Line

Objeto Um objeto entregue por um processo para a Assembly Line.

Objeto-vindo de-Assembly Line

Objeto Um objeto que vai da Assembly Line para um processo.

26

Fluxo de processo Fluxo de controle

Um fluxo de controle de processo com uma condição

Fluxo de recurso Fluxo de objeto

Fluxo de objeto mostra que um objeto é produzido por um processo e consumido por outro.

Fluxo de recursos não-causal

Fluxo de objeto

Fluxo de objeto não-causal mostra que um objeto pode ser produzido por um processo e consumido por outro.

Controle de processo

Fluxo de objeto Mostra que um processo é controlado por um objeto.

Conexão de objetivo

Dependência

Aloca um objetivo a um processo.

Processo de suprimento

Fluxo de objeto Mostra que um processo é suprido por um objeto.

Processo de decisão

Decisão

Ponto de decisão entre dois ou mais processos.

Processos de união e bifurcação

Bifurcação e União Bifurcação e união de processos.

Receber eventos de negócio

Recepção de sinal

Mostra um recebimento de evento de negócio.

Enviar eventos de negócio

Emissão de sinal

Mostra um envio de evento de negócio.

Assembly Line Pacote

As Assembly Lines sincronizam e suprem os processos em termos de objetos.

Objetivo

quantitativo Objetivo

Um objetivo pode ser descrito com um valor alvo em uma unidade especifica de medida (a quantidade).

Objetivo qualitativo

Objetivo

Um objetivo normalmente descreve em linguagem natural. Um objetivo qualitativo envolve julgamento humano, no processo de determinar se ele foi cumprido.

Instância de um objetivo

qualitativo


Ambos os objetivos qualitativos e quantitativos podem ser instanciados.

Recurso Classe

Recursos podem ser produzidos, consumidos, usados ou refinados por processos. Os recursos são também informação ou coisas que podem ser abstratas ou físicas.

27

Recurso abstrato Classe

Um recurso abstrato é algo intangível, por exemplo, conceitos matemáticos.

Pessoa Classe

Um recurso físico que específica um ser humano.

Recurso físico Classe

Um recurso físico que especifica documentos, máquinas (não humano).

Evento de negócio Sinal

Uma ocorrência significante no tempo ou espaço. Um evento de negócio causa algum impacto ao negócio.

A Figura 5 apresenta um exemplo de modelo de processo de negócio dividido

em raias (swimlanes), que é um elemento padrão do diagrama de atividades. Cada

raia demonstra as atividades executadas pelos respectivos responsáveis descrito no

topo. As trocas de recursos (entradas e saídas) são explicitadas entre os processos.

Figura 5 - Diagrama de processo de negócio em UML [Eriksson&Penker00]

A Figura 6 apresenta um exemplo de modelo de processo de negócio mais

simples, porém demonstra o relacionamento de um objetivo com o elemento processo.

28

Figura 6 – Exemplo de objetivo relacionado ao processo [Eriksson&Penker00]

2.2.2.Extensões do diagrama de objetivos

O diagrama de objetivos proposto por [Eriksson&Penker00] reutiliza o diagrama

de objetos da UML. Os objetivos podem ser representados em diferentes níveis, sendo

cada nível, um diagrama de objetos. Os objetivos são descritos como classes de

objetos com o estereótipo de <<goal>>. Os elementos que compõem o diagrama são:

objetivos, relacionamento de dependência, associação entre objetivos e um elemento

que representa os problemas os quais atuam negativamente sobre o objetivo (Tabela

2, além dos elementos da Tabela 3 que estão disponíveis para todos os diagramas).

Tabela 2 – Elementos de um diagrama de objetivos em UML

Extensões de objetivo


Objetivo Classe

Denota os estados de desejo, o que significa que os objetivos motivam ações para alterar estados na direção desejada.

Problema Nota

Algo que impede o alcance do objetivo. Cauda, medida e pré-requisito são outros estereótipos que são uteis quando se modela problemas. Uma causa leva aos problemas. Um problema pode ser resolvido se uma causa é removida.

29

A causa pode ser removida se uma medida é alcançada e certos pré-requisitos são validos.

Dependência

de objetivo Dependência

Objetivos são organizados em hierarquias de dependência nas quais um ou alguns objetivos são dependentes de subobjetivos.

Objetivo

contraditório Associação

Objetivos podem ser contraditórios, mas devem ser cumpridas.

Decomposição de objetivo incompleta

Dependência Objetivos são organizados em hierarquias de dependência que algumas vezes são incompletas.

Decomposição de objetivo completa

Dependência

Objetivos são organizados em hierarquias de dependência que algumas vezes são completas.

Objetivo

quantitativo Objetivo

Um objetivo pode ser descrito com um valor alvo em uma unidade especifica de medida (a quantidade).


Objetivo

Um objetivo normalmente descreve em linguagem natural. Um objetivo qualitativo envolve julgamento humano, no processo de determinar se ele foi cumprido.

Instância de um objetivo qualitativo

Objetivo

qualitativo

Ambos os objetivos qualitativos e quantitativos podem ser instanciados.

Existem duas classes de objetivos predefinidas no diagrama de objetivos:

objetivo quantitativo e objetivo qualitativo. Um objetivo quantitativo pode ser medido

através de valores específicos que são atingidos, um objetivo qualitativo depende do

julgamento de quem avalia, tornando subjetiva a sua medição. O objetivo quantitativo

é composto pelos seguintes atributos: descrição (goal description), valor esperado

(goal value), valor atual (current value) e unidade de medida (unit of measurement). O

objetivo qualitativo também possui o atributo descrição, porém seus outros atributos

“valor esperado”, “valor atual” e “unidade de medida” devem ser interpretados pelo

avaliador. Os autores definem esses atributos como “instância de um objeto

qualitativo”.

O relacionamento de dependência entre objetivos denota que um objetivo é

subobjetivo de outro, ou que um depende do outro. O relacionamento de associação

denota links entre objetivos, tais como contradições [Eriksson&Penker00].

30

Outro conceito apresentado é o de “problema”, que representa um obstáculo

para a satisfação do objetivo. Identificar problemas pode levar ao descobrimento de

novos objetivos que são satisfeitos com a eliminação desses problemas. A modelagem

de problemas pode ser hierárquica, com a subdivisão em subproblemas. Os

problemas são relacionados com os seus respectivos objetivos, mas podem ser

eliminados pela inclusão de ações de solução.

Um plano de ação pode ser projetado no modelo de objetivos como uma forma

de resolver os problemas. Os objetivos, por sua vez, são relacionados aos processos

de negócio. Os processos projetados no plano de ação devem ser posteriormente

formalizados como processos e relacionados aos seus objetivos.

A Figura 7 apresenta um exemplo de modelo de objetivo. O objetivo geral é ter

muitos consumidores, e o valor desejado é de 500.000. Este objetivo foi dividido em

três subobjetivos que também descrevem as categorias dos consumidores (visitantes

da internet desconhecidos, consumidores registrados e consumidores inscritos). Três

problemas estão relacionados a cada um dos subobjetivos. Por exemplo, o problema

relacionado ao objetivo de “atrair mais visitantes na internet” é que “os usuários podem

desconhecer o site”. Para solucionar este problema, são gerados novos subobjetivos

que almejam a “publicação do site” para o conhecimento dos usuários, por exemplo,

“Garantir que o site esteja visível nas máquinas de busca mais comuns”.

Figura 7 – Diagrama de objetivos em UML [Eriksson&Penker00]

31

A Tabela 3 apresenta o elemento regra de negócio que se apresenta em todos

os modelos. As regras são elementos especiais que definem restrições/condições ao

negócio, e por serem importantes devem sempre ser ligadas aos elementos que são

relacionados e/ou sofrem tais regras, por exemplo, objetivos e processos.

Tabela 3 – Recursos e regras compõem todos os diagramas

Extensões de regras


Regra de negócio Nota

Regras restringem, derivam e estabelecem condições de existência. As regras de negócio são usadas para especificar estados de desejo, incluindo os estados alvos permitidos ao negócio.

Esta seção apresentou a modelagem de processos de negócio e objetivos

utilizando um built-in para a linguagem UML proposta por [Eriksson&Penker00]. A

extensão apresentada utiliza modelos UML e objetos com novos estereótipos para

representação de novos conceitos, o que permite a inclusão de novos elementos com

menor esforço, a partir do reuso dos objetos e diagramas UML.

Na próxima seção é apresentada a notação BPMN.

2.3. BPMN

A BPMN (Business Process Model and Notation), versão 2.0, é um padrão

desenvolvido pela OMG (Object Management Group) com o principal objetivo de

oferecer uma notação que fosse legível e compreensível para os usuários do negócio

[OMG11a].

A notação foi desenvolvida a partir do conhecimento e experiências dos

membros da OMG que procuraram consolidar as melhores ideias para alcançar uma

única notação padrão. Muitas metodologias e notações foram revistas durante o

desenvolvimento da BPMN (por exemplo, UML Activity Diagram, UML EDOC Business

Process, IDEF, ebCML BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet,

LOVeM e Event-Process Chains (EPCs)) para que fosse desenvolvida uma

especificação que representasse a combinação das melhores práticas da comunidade

de modelagem de processos [OMG11a].

A intenção da BPMN é padronizar o modelo de processo de negócio e sua

notação em face das diversas notações de modelagem e pontos de vista distintos.

Outro fator padronizado no contexto da BPMN é a padronização de arquivos de

32

processo BPMN (extensão .bpmn), que permite a exportação e importação dos

modelos para ferramentas de diferentes fabricantes.

A BPMN suporta somente conceitos de modelagem que são aplicáveis a

processos de negócio. Isso significa que outros tipos de modelagem realizados por

organizações, mesmo com propósitos do negócio, estão fora de se escopo, por

exemplo, modelagem organizacional, modelagem de dados, modelagem de

objetivos/estratégia e modelagem de regras de negócio.

A notação oferece uma variedade de recursos para o desenvolvimento de um

modelo de processo de negócio e classifica os diagramas BPMN em três tipos básicos

baseado na perspectiva na qual o processo é modelado: Processo de negócio privado

não executável, Processo de negócio privado executável e Processo público.

Ainda existem os diagramas de Colaboração, Coreografia e Conversação, sendo

que esses dois últimos não são detalhados neste trabalho por não possuírem as

características desejadas no detalhamento dos fluxos de execução de processos.

2.3.1. Processos privados

Os Processos de negócio privados são processos internos a uma organização,

antigamente chamados de workflow ou processos BPM. Existem dois tipos de

processos privados: executável e não executável. Um processo executável é um

processo que foi modelado com propósito de ser executado, utilizando em sua

semântica processos, atividades, eventos, operadores lógicos, fluxos, loops e

manipulação de dados. Um processo não executável é um processo que foi modelado

com o propósito de documentar o comportamento do processo em um nível de detalhe

de modelagem definido. Desta forma, a informação necessária para execução, tal

como a condição formal das expressões são tipicamente excluídas em um processo

não executável.

A Figura 8 mostra um exemplo de um modelo de processo de negócio privado.

Figura 8 – Exemplo de modelo de processo de negócio privado [OMG11a].

33

2.3.2.Processos públicos

Um processo de negócio público representa as interações entre um processo de

negócio privado com outro processo ou participante (Figura 9). Somente o processo

público torna-se visível, enquanto o processo privado é representado por uma raia

vazia. Assim, o processo público mostra o lado de fora do mundo em que o fluxo de

mensagens e o comando destas mensagens de fluxo são necessários para interagir

com o processo.

Figura 9 – Exemplo de processo de negócio público [OMG11a].

2.3.3.Processos colaborativos

Uma colaboração ilustra as interações entre duas ou mais entidades do negócio.

Uma colaboração normalmente contém duas ou mais “pools”, representando os

participantes que interagem. A troca de mensagem é representada pelo fluxo que

conecta as “pools” (ou os objetos dentro das “pools”). As mensagens associadas ao

fluxo de mensagens estão descritas no corpo das setas de fluxo de mensagem. A

colaboração pode ser descrita como dois ou mais processos públicos se comunicando

(Figura 10).

Com um processo público, as atividades de colaboração dos participantes

podem ser consideradas o “ponto de toque” entre os participantes. O correspondente

interno no processo (executável) é suscetível a ter muito mais atividades e detalhes do

que é mostrado nos processos públicos. Coreografias podem ser apresentadas "entre"

as “pools” como se dividissem o fluxo de mensagem entre elas. Todas as

combinações de pools, processos, e coreografia são permitidas em uma colaboração.

34

Figura 10 – Exemplo de processo colaborativo

2.3.4. Notação

Os elementos gráficos utilizados nos diagramas BPMN foram desenvolvidos

intencionalmente para facilitar o entendimento dos modelos e ao mesmo tempo

ampliar a expressividade de complexidades inerentes aos processos de negócio. A

abordagem adotada para lidar com esses dois requisitos conflitantes foi organizar

aspectos gráficos da notação em categorias especificas, de forma que o usuário possa

facilmente reconhecer os tipos básicos de elementos e compreender o diagrama.

Dentro das categorias básicas dos elementos, podem ser adicionadas variações e

informações para suportar novas necessidades, porém sem mudar dramaticamente o

visual básico e percepção do diagrama. As cinco categorias básicas de elementos

são: Fluxo de objetos; Dados, Objetos de conexão, Swimlanes e Artefatos. Os

elementos básicos que se encaixam nesses grupos são descritos na Tabela 4. Ainda

são oferecidos outros elementos (que são variações dos elementos básicos) para

expressar casos específicos com maior nível de detalhe (não demonstrados aqui).

Tabela 4 – Elementos básicos da BPMN

Nome Símbolo Definição/Descrição

Evento

Eventos são fatos que ocorrem durante a execução do processo. Pode ser classificado em evento inicial, intermediário e final.

Atividade

Uma atividade pode ser atômica ou não atômica (composta).

Operador lógico

Um operador lógico é usado para controlar divergência e convergência nos fluxos sequenciais de um processo.

Fluxo de sequencia Um fluxo de sequencia é usado para mostrar a ordem das atividades que serão

35

executadas no processo.

Fluxo de mensagem

Um fluxo de mensagem é usado para mostrar a passagem de mensagens entre os participantes.

Associação

Uma associação é usada para ligar informação e artefatos de forma gráfica.

Pool

Representação gráfica de um participante em um modelo.

Lane

Subpartição dentro de um processo ou Pool que estende toda a extensão do processo.

Objeto de dados

Objetos de dados que proveem informação sobre o que as atividades necessitam para serem executadas ou o que elas produzem.

Mensagem

Representa uma mensagem com conteúdo de comunicação entre dois participantes.

Grupo

Agrupa elementos gráficos de uma mesma categoria.

A Figura 11 apresenta um exemplo de modelo de processo de negócio em um

diagrama BPMN. O processo é composto por quatro raias que representam os papéis

executores das atividades, alocadas nas respectivas raias. O modelo utiliza apenas

elementos simples, tais como eventos, atividades, operadores lógicos e artefatos.

36

Figura 11 – Exemplo de modelo de processo de negócio em um diagrama BPMN

Esta seção apresentou a notação BPMN. Atualmente em sua versão 2.0, é um

padrão publicado pela OMG, que foi definido a partir do esforço de diversos

pesquisadores da área para desenvolver uma notação específica para a modelagem

de processos de negócio. Portanto, a BPMN não aborda outros conceitos, como por

exemplo, a modelagem de objetivos.

Na próxima seção será apresentado o framework i*, específico para a

modelagem de metas intencionais.

2.4. Framework i*

O framework de Modelagem i* (i-estrela) [Yu95] modela contextos

organizacionais com base nos relacionamentos de dependência entre os atores

participantes [Napolitano09]. A ideia central do i* é representar através de modelos os

atores e as dependências que eles têm uns com os outros para que metas próprias

sejam atingidas [Oliveira08c].

37

O conceito mais relevante no i* é o conceito de objetivo: “Um objetivo é uma

condição ou estado de interesse no mundo que um ator gostaria de alcançar”

[Tradução livre, [Yu95] e [13] apud [Oliveira08c]]. Dessa forma, atores dependem uns

dos outros para que seus objetivos sejam alcançados, recursos sejam fornecidos,

tarefas sejam realizadas e metas-flexíveis sejam “razoavelmente satisfeitas”

[Oliveira08c].

A proposta de modelagem do framework i* consiste em dois componentes de

modelagem chamados Strategic Dependency (SD) e Strategic Rationale (SR).

O modelo SD descreve um processo em termos dos relacionamentos de

dependência intencional entre os agentes. Os agentes dependem um do outro para

que os objetivos sejam alcançados, tarefas sejam executadas e recursos

compartilhados. O modelo SR prove uma descrição intencional do processo em

termos de seus elementos e das suas razões estratégicas internas dos atores [Yu95].

As subseções seguintes detalham os modelo SD e SR.

2.4.1. Strategic Dependency (Modelo SD)

No modelo SD, os atores possuem dependência entre si para alcançar objetivos,

executar tarefas e fornecer recursos. Ao depender de outro ator, o ator dependente

obtém vantagens das oportunidades que são disponibilizadas através dos atores que

prestam o suporte [Yu09]. Ao mesmo tempo em que o dependente é beneficiado, ele

torna-se vulnerável caso não sejam atendidas as suas expectativas. Essas

dependências são consideradas estratégicas para os atores interessados, já que eles

podem ser beneficiados ou prejudicados em seu bem-estar. Atores poderiam escolher

que dependências ter, de acordo com seu julgamento em relação a potenciais ganhos

e perdas [Yu09].

O modelo SD é um grafo onde os nós representam atores (agentes, posições,

papéis), e cada dependência representa um relacionamento de cooperação entre dois

atores, sendo que o ator chamado de depender depende de outro chamado de

dependee. O elo da dependência, chamado de dependum, é o objeto da dependência

que pode ser: um objetivo, uma meta-flexível, uma tarefa ou um recurso, definido

sempre como uma entidade física ou informacional. Conforme mencionado

anteriormente, as relações de dependência mostram as vulnerabilidades do depender,

pois o dependee pode falhar no cumprimento do acordo e, por isso, cada dependência

tem um grau de importância (“critical”, “committed” ou “open”, em ordem decrescente

de importância) para refletir sua relevância [Oliveira08c].

38

Dentro do diagrama SD, é possível expressar quatro tipos de dependências:

dependência de meta, dependência de tarefa, dependência de recurso e dependência

de meta-flexível. A Figura 12, Figura 13, Figura 14 e Figura 15 ilustram os quatro tipos

de relacionamento (nestes casos, o dependee encontra-se sempre à esquerda e o

depender sempre à direita):

Figura 12 – Exemplo de relacionamento de dependência de meta

Figura 13 - Exemplo de relacionamento de dependência de meta-flexível

Figura 14 - Exemplo de relacionamento de dependência de tarefa

Figura 15 - Exemplo de relacionamento de dependência de recurso

Os exemplos ilustram o significado de uma dependência entre dois atores: um

ator “quer” alguma coisa que outro ator “pode” suprir. A Figura 12 apresenta uma

dependência de objetivo, em que o cliente depende do caixa do banco para realizar o

saque do dinheiro. A Figura 13 apresenta uma dependência de meta-flexível, em que

o cliente depende do caixa do banco para ser atendido com rapidez ao realizar o

saque. A Figura 14 apresenta uma dependência de tarefa, em que o cliente depende

que o caixa do banco execute a tarefa de emitir o comprovante de pagamento. A

39

Figura 15 apresenta uma dependência de recurso, em que o cliente depende do caixa

do banco para obter o seu comprovante de pagamento.

Os tipos das dependências refletem o grau de liberdade existente no

relacionamento. Na dependência por objetivo, cabe ao dependee toda e qualquer

decisão para o cumprimento do objetivo. Na dependência por tarefa, o dependee

executa a tarefa da maneira como o depender deseja, portanto, é de responsabilidade

do depender decidir como a tarefa deve ser executada. Na dependência por recurso, o

grau de liberdade é nulo, ou seja, o dependee deve fornecer o recurso exatamente

como o depender deseja. Na dependência por meta-flexível, o depender tem a decisão

final de aceitar ou não a meta alcançada, porém ele usa o beneficio do “know-how”

(habilidades e conhecimentos) do dependee [Oliveira08c].

Dede que um autor seja autônomo, ele pode optar por não se tornar dependente

de outro. Ao analisar a rede de dependências, é possível concluir que algumas

dependências parecem ser mais viáveis do que outras e que uma falha dentro de uma

dependência pode propagar para uma grande cadeia de dependências [Yu09].

A Tabela 5 apresenta os elementos de um modelo SD.

Tabela 5 – Elementos de um modelo SD


Ator/Agente

Representa um ator interessado em alcançar seus objetivos.

Meta

Representa um objetivo que só pode ser completamente satisfeito ou não satisfeito.

Meta-flexível

Representa um objetivo que pode ser satisfeito em diferentes níveis, dependendo da visão do avaliador.

Tarefa

Representa uma unidade de trabalho a ser executada.

Recurso

Representa um recurso produzido, compartilhado ou consumido pelos atores para alcançar seus objetivos.

Dependência

Representa um relacionamento de dependência.

Marcação de crítico

Marca o elemento como crítico. Significa que o ator/agente acredita que não existe outra forma para suceder se a dependência não for satisfeita.

Marcação de aberto

Marca o elemento como não comprometido/independente. Significa que a rotina pode ser afetada, mas não necessariamente falhar caso a dependência não seja satisfeita.

40

A Figura 16 apresenta um exemplo de um modelo SD.

Figura 16 – Exemplo de diagrama SD [Adaptação de [Susi05]]

2.4.2. Strategic Rationale (Modelo SR)

O modelo SR oferece uma descrição intencional dos processos em termos de

seus elementos e o raciocínio aplicado em sua execução. Enquanto o modelo SD

mantém um nível de abstração por modelar somente os relacionamentos externos

entre atores, o modelo SR apresenta uma visão em baixo nível que permite maior

entendimento sobre os raciocínios estratégicos dos atores em relação aos processos.

O modelo SR descreve os relacionamentos intencionais que são internos aos atores,

tais como relacionamentos “meios-fim” que relacionam os elementos dos processos

provendo representações explícitas do “porque”, “como” e possíveis alternativas. Os

raciocínios encontram-se no nível estratégico, logo as alternativas do processo que

está sendo fundamentado também são relacionamentos estratégicos [Yu95].

Os elementos do processo usados para representar os relacionamentos

intencionais internos aos atores são: relacionamentos “meios–fim”, que possuem o

papel de explicitar as decisões que foram tomadas para que as metas do ator fossem

alcançadas; decomposição de tarefas, que detalha a elaboração e realização das

tarefas, além de mostrar como os recursos são disponibilizados e utilizados; e os

41

relacionamentos de contribuição, que exibem o tipo de contribuição (positiva ou

negativa) entre metas flexíveis [Napolitano09].

[Oliveira10] definem um metamodelo [Figura 17] contendo os elementos e

relacionamentos possíveis no i*. Cada um destes tipos de relacionamentos são

detalhados a seguir em termos de sua características de aplicação e elementos

gráficos.

Figura 17 – Metamodelo i* [Oliveira10]

No relacionamento de decomposição de tarefa é possível relacionar uma tarefa a

subelementos que devem estar disponíveis para a execução da tarefa decomposta.

Por exemplo, a decomposição de uma tarefa em uma meta implica que essa meta

deve ser satisfeita primeiramente para que a tarefa possa ser executada. Se fosse

uma decomposição de recurso, ele deveria estar disponível primeiramente para

consumo da tarefa. A Figura 18 apresenta de forma gráfica as possibilidades de

aplicação do relacionamento de decomposição.

42

Figura 18 – Ligações para o relacionamento de Decomposição

O relacionamento means-end (meios-fim) registra “como” e “o que” foi executado

(means) para que um dado “fim” (end) pudesse ser realizado. Por exemplo, para um

recurso ser produzido, alguma atividade foi realizada. Neste caso a atividade tem o

papel de “means” e o recurso, o papel de “end”. Somente tarefas possuem o papel de

“means”, porém os elementos recurso, tarefa e meta podem ter o papel de “end”.

Ainda existe o caso específico de relacionamento “means-end” para metas-

flexíveis que é explicado a seguir. A Figura 19 apresenta de forma gráfica as

possibilidades de aplicação do relacionamento “means-end”.

Figura 19 - Ligações para os relacionamentos de “meios-fim”

O relacionamento do tipo Contribuição é um sub-relacionamento do tipo Means-

end e herda as suas características [Oliveira10], entretanto, por relacionar

especificamente os elementos tarefa e meta-flexível a outro elemento do tipo meta-

flexível, recebe labels que expressam o significado de contribuição. A Figura 20

apresenta esses relacionamentos.

43

Figura 20 – Ligações para os relacionamentos de contribuição positiva e negativa

A Tabela 6 apresenta os elementos de um modelo SR e suas respectivas

descrições.

Tabela 6 – Elementos do modelo SR


Ator/Agente


Meta


Meta-flexível


Tarefa


Recurso


Dependência


Marcação de crítico

Marca o elemento como crítico. Significa que o ator/agente acredita que não existe outra forma para suceder se a dependência não for satisfeita.

Marcação de aberto

Marca o elemento como não comprometido/independente. Significa que a rotina pode ser afetada, mas não necessariamente falhar caso a dependência não seja satisfeita.

Decomposição de tarefa

Representa um relacionamento que expressa a decomposição de uma tarefa em outros elementos.

Meios-fim Representa um relacionamento que expressa a ligação entre um fim e um meio

44

de alcançá-lo.

Contribuição positiva

Representa um relacionamento que expressa contribuição positiva para um meta-flexível.

Contribuição negativa

Representa um relacionamento que expressa contribuição negativa para um meta-flexível.

Pool do ator/agente

Representa um ator/agente em forma de pool.

A Figura 21 exemplifica um modelo misto (SD + SR). O conteúdo do modelo SR

encontra-se na pool do ator central, onde é modelado o seu rationale, ou seja, a

estratégia utilizada para que ele alcance suas metas. Ao redor, apresentam-se as

modelagens das dependências de recursos, tarefas e meta com outros atores.

Figura 21 – Exemplo de modelo SR (adaptação de [Yu95])

Esta seção apresentou o framework i* que oferece uma linguagem para a

modelagem de dependências de recursos e metas entre atores, bem como a

45

modelagem das estratégias de cada ator para alcançar suas metas. Observa-se que a

modelagem de objetivos do i* ocorre em um plano de visão distinto das modelagens

tradicionais de objetivos organizacionais que são definidos em alto nível, trazendo uma

nova noção que permite análises mais apuradas dos riscos e estratégias envolvidas

na execução dos processos organizacionais.

A próxima seção apresenta a URN que é uma notação composta por uma

linguagem de modelagem de processos (UCM) e uma linguagem de modelagem de

objetivos (GRL).

2.5. URN (UCM e GRL)

A URN (User Requirement Notation) é uma notação composta por duas

sublinguagens, uma específica para modelagem de processos e outra para

modelagem de objetivos. Essa notação é um padrão nomeado como Z.151 e

recomendado pela ITU-T (International Telecommunication Union) no contexto das

Técnicas de Descrições Formais (FDT) [ITU08].

A URN foi projetada para oferecer recursos para elicitação, análise,

especificação e validação de requisitos. Entre os objetivos do desenvolvimento do

padrão URN, temos: capturar os requisitos do usuário quando apenas poucos detalhes

de projeto estão disponíveis; focalizar os estágios iniciais de projeto; avaliação

antecipada de desempenho e detecção antecipada de interações indesejadas

[Amyot&Mussbacher02].

A URN é composta por duas notações que representam conceitos de

modelagem e notações para objetivos (com foco em requisitos não funcionais e

atributos de qualidade) e cenários (com foco nos requisitos operacionais, requisitos

funcionais, desempenho e raciocínio (reasoning) arquitetural) [Sikandar03].

A notação com foco em objetivo é chamada de GRL (Goal-oriented

Requirements Language) e a notação de cenários é chamada de UCM (Use Case

Map). A partir dessa combinação, a UCM permite a captura de objetivos e raciocínios

de decisão (utilizando GRL) e a capacidade de modelar sistemas dinâmicos que

possuem comportamento variável em tempo de execução (utilizando UCM)

[Sikandar03].

As próximas subseções detalham a GRL e a UCM.

46

2.5.1.GRL

A GRL é uma extensão da linguagem i* [Yu95] que foi desenvolvida para apoiar

a modelagem orientada a metas e a representação do raciocínio (reasoning) de

atores, especialmente para tratar requisitos não funcionais. Ela fornece elementos

para expressar vários tipos de conceitos que aparecem durante o processo de

requisitos. Existem três categorias principais de conceitos: elementos intencionais,

links, e atores. Os elementos intencionais na GRL são: tarefa, objetivo, meta-flexível e

recurso. Eles são intencionais porque são usados por modelos que permitem

identificar o motivo de determinados comportamentos, o motivo de aspectos

estruturais e informacionais serem escolhidos para inclusão nos requisitos do sistema,

quais alternativas foram consideradas, quais critérios foram usados para deliberar

entre as alternativas, e quais as razões para a escolha de uma alternativa e não outra

[GRL12].

A GRL suporta o raciocínio sobre cenários, estabelecendo correspondências

entre elementos GRL intencionais e não intencionais em modelos de cenários da

URN. Modelar ambos os objetivos e cenários é complementar e pode ajudar na

identificação de objetivos e cenários adicionais importantes para os interessados,

contribuindo assim para a integralidade e exatidão dos requisitos.

Alguns dos elementos intencionais da GRL são reutilizados do i*, tais como,

ator/agente, task (tarefa), softgoal (meta-flexível) e goal (meta). Entre os

relacionamentos reutilizados encontram-se a contribuição, dependência e

decomposição. Entretanto, novos elementos são adicionados, tais como, belief

(crença), link de correlação, níveis de satisfação e tipos de contribuição. A Figura 22

apresenta os níveis de satisfação e tipos de contribuição (também presentes no i*,

provêm do NFR framework [Chung00]). A Tabela 7 apresenta os outros elementos do

modelo GRL.

Figura 22 – Níveis de satisfação (à esquerda) e tipos de contribuição (à direita) da GRL

47

Tabela 7 – Elementos do modelo GRL


Ator/Agente


Meta


Meta-flexível


Tarefa


Recurso


Crença

Raciocínio ou argumentação associada a uma contribuição ou uma relação.

Dependência


Decomposição

Define o que é necessário para uma tarefa ser executada.

Contribuição

Descreve como metas-flexíveis, tarefas, crenças, e relações contribuem entre si. Cada contribuição pode ser qualificada por um nível: equal, break, hurt, some-, some+, undetermined, help ou make (Figura 22).

Correlação

Contribuição que indica efeitos colaterais em outro elemento intencional.

A Figura 23 apresenta um exemplo de modelo em GRL utilizando grande parte

dos elementos da linguagem.

Figura 23 – Exemplo de modelo GRL [Amyot02]

48

2.5.2.UCM

A modelagem de requisitos funcionais de sistemas complexos, muitas vezes

implica em uma ênfase inicial nos aspectos comportamentais, tais como interações

entre o sistema e o seu ambiente (e usuários), de forma a definir os relacionamentos

entre suas interações e sobre as atividades intermediárias realizadas pelo sistema.

Cenários representam de maneira excelente e útil de descrever esses aspectos.

[Amyot&Mussbacher02].

Os modelos UCM são usados como uma notação visual para a descrição de

relações causais entre responsabilidades em um ou mais cenários. São mais úteis nas

fases iniciais de desenvolvimento de software e são aplicáveis para captura e

elicitação e validação de cenários, bem como design arquitetônico de alto nível e

geração de casos de teste. Também fornecem um framework comportamental para

avaliação e tomada de decisões arquiteturais em um alto nível, opcionalmente, com

base em análise de desempenho dos modelos. Além disso, fornecem aos seus

usuários a capacidade dinâmica (em tempo de execução) do refinamento de variações

de cenários e de estrutura como forma de permitir o desenvolvimento incremental e

integração de cenários complexos [Amyot&Mussbacher02].

As principais vantagens da UCM são sua capacidade de modelar refinamentos

dinâmicos para diversos comportamentos e estruturas, além de integrar componentes

estruturais e comportamentais em uma única visão, realizando assim, a ponte entre

requisitos e projeto [Amyot&Mussbacher01].

Os elementos principais da linguagem UCM são descritos a seguir (Tabela 8):

Tabela 8 – Elementos do modelo UCM


Ator/Time

Representa o responsável ou grupo de responsáveis no processo.

Ponto inicial

Captura precondições e eventos de disparo.

Ponto final

Representa eventos resultantes e pós-condições.

Responsabilidades

Locais onde, por exemplo, procedimentos, atividades e funções são necessários.

Caminhos

Conecta pontos iniciais a pontos finais e pode ligar responsabilidades em um caminho causal.

Stub estático

Representa relacionamento estático com outro diagrama.

Stub dinâmico

Representa relacionamento dinâmico com outros diagramas.

49

Cenários grandes e complexos podem ser decompostos e estruturados através

de submapas chamados plugins, usado (e reutilizados) em recipientes de mapas

chamados stubs e exibidos em formato de diamantes (Tabela 8).

A Figura 24 apresenta um exemplo de diagrama UCM. Este diagrama retrata um

cenário de alto nível (comumente chamado de Root Map), enquanto os dois outros

modelos UCM da Figura 25 e Figura 26, são plugins para o stub Authenticate.

Neste exemplo do diagrama principal, um contribuinte quer acessar o contador

eletrônico através do sistema de segurança. Após a identificação de contribuinte

(CheckId), o sistema necessita autenticar o solicitante, que pode ser aceito ou

rejeitado. Para realizar a autenticação, pode ser utilizado o plugin biométrico ou senha.

Uma vez autenticado, o contador eletrônico cria uma nova sessão, e em seguida o

sistema torna-se pronto para processar as transações.

Figura 24 – Exemplo de diagrama UCM (diagrama principal) [Amyot&Mussbacher02]

Figura 25 – Plug-in Biométrico [Amyot&Mussbacher02]

50

Figura 26 – Plugin Senha [Amyot&Mussbacher02]

Os candidatos a alternativas para a autenticação (biometria ou senha), se

incluidos no modelo GRL, podem ser operacionalizados baseado no reasoning, desta

forma é possível ter maior controle estratégico, além de possibilitar análises mais

detalhadas do contexto nos modelos.

2.5.3.Rastreabilidade entre UCM e GRL

A ferramenta jUCMNav é o principal recurso computacional para a criação de

modelos UCM e GRL. Esta ferramenta foi desenvolvida como um plugin do Eclipse e

encontra-se em constante evolução.

A integração dos modelos UCM e GRL e métodos de alinhamento ocorrem de

várias formas, por exemplo, através de relacionamentos específicos, tais como links

de realização [Behnam10] (Figura 27), responsabilidade, rastreabilidade e

complacência [Ghanavati09].

Figura 27 – Exemplo de relacionamento do tipo realização entre modelos GRL e UCM [Behnam10]

51

Diversos trabalhos são desenvolvidos para ampliar a capacidade de alinhamento

e análise dos modelos UCM e GRL, por exemplo, com o uso de indicadores

[Shamsaei10], frameworks de alinhamento [Ghanavati09] e uso de templates

[Behnam10].

Esta seção apresentou o padrão Z.151, conhecido como URN, proposto pela

ITU-T (International Telecommunication Union). Este padrão oferece a modelagem de

objetivos em alto nível utilizando a linguagem GRL, e a modelagem de cenários,

utilizando o padrão UCM. Um dos pontos positivos desse padrão é a existência de

rastreabilidade entre o modelo de objetivos e o modelo de execução. Além disso,

diversos estudos expandem a linguagem incluindo novos elementos e

relacionamentos como forma de ampliar a capacidade da linguagem no sentido de

garantir que os objetivos sejam cumpridos.

Na próxima seção será apresentado o framework ARIS, considerado um dos

mais importantes no contexto da modelagem de processos de negócio.

2.6.Framework ARIS

A Arquitetura de Sistemas de Informação Integrado (ARIS – Architecture of

Integraterd Information Systems) é um conceito (e não simplesmente uma ferramenta)

desenvolvido pelo professor August-Wilhelm Scheer, na Alemanha. Seu objetivo é

prover um framework que ofereça meios de expressar os conceitos do negócio de

forma precisa e, assim, permitir análises detalhadas e prover um ponto inicial não

ambíguo para o desenvolvimento de sistemas de informação computacionais

[Davis07].

A partir da definição do framework ARIS, foi desenvolvida a ferramenta ARIS

Toolset, lançada em 1992, sendo utilizada em larga escala para a modelagem de

processo de negócio por empresas de diversos tamanhos, sendo uma ferramenta líder

no ramo [Davis02].

No contexto da modelagem de processos de negócio, a ferramenta oferece três

níveis de abstração que são aplicados em diagramas distintos, com objetos

específicos. O primeiro nível é formado pelos processos que estão diretamente

envolvidos na criação de valores para a companhia, eles são modelados no diagrama

de Cadeia de Valor Agregado (VAC – Value-added chain) [Scheer&AG05]. O segundo

nível é basicamente formado pelo fluxo de atividades, recursos, eventos e regras, que

formam o diagrama de Cadeia de Processos e Eventos (EPC – Event-Driven Process),

considerado o diagrama central de toda a modelagem de negócio no ARIS [Davis07].

Por último, no nível mais baixo, estão modelados os elementos que representam a

52

execução das atividades, com o objetivo de oferecer informações adicionais do nível

operacional, em particular, sobre a transformação dos dados de entrada e saída

[Davis07]. Esses elementos são modelados no Diagrama de Alocação de Função

(FAD – Function Allocation Diagram).

Além desses modelos que são específicos para modelar os processos de

negócio em diferentes níveis de abstração, o ARIS também possui um modelo

designado apenas para a modelagem de objetivos, capaz de possibilitar a definição e

relacionamento dos objetivos de forma hierárquica juntamente com os processos e

Fatores Críticos de Sucesso [Seildlmeier&Storr04].

Esses diagramas são detalhados nas subseções seguintes.

2.6.1.VAC – Valued Added Chain

O diagrama VAC especifica os processos em uma organização as quais

influenciam diretamente o seu real valor agregado. Estes processos podem ser ligados

a outros sequencialmente e então formar a cadeia de valor agregado [ARIS06]. Além

disso, é possível relacioná-los aos seus respectivos objetivos e indicadores.

Um modelo VAC pode ser detalhado em outros macroprocessos do mesmo tipo

(VAC). Em um diagrama VAC, os processos podem ser dispostos em uma hierarquia

ou similar a uma árvore. A orientação do processo subordinado ou superior é sempre

ilustrada, além disso, um diagrama de cadeia de valor representa os relacionamentos

entre os processos e as unidades organizacionais e também os objetos informativos

[ARIS06].

A Figura 28 exemplifica um modelo VAC. Este modelo possui o macroprocesso

“Realizar empréstimos para pessoa física”, composto por outros três macroprocessos

que estão ligados aos seus respectivos objetivos e indicadores (KPI).

Figura 28 – Exemplo de modelo VAC [Sousa10]

Analisar pedido de créditoGerir solicitações de pedido de

crédito

Gerenciar contratos de crédito

em vigor

Realizar empréstimos para

pessoa física

Garantir acesso às

solicitações de crédito

para pessoa física

Garantir margem de

risco controlado nos

créditos concedidos

Garantir que créditos

concedidos retornarão

lucro mínimo

Garantir o pagamento

dos clientes

Minimizar perdas em

sinistros

Porcentagem de

perda em

sinistros

Quantidade de

contratos

fechados

Porcentagem de

trabalhadores da

classe C

53

A visão de macroprocesso é conhecida como uma visão gerencial devido a sua

abstração. Essa visão é moldada durante a primeira fase do ciclo de vida da

modelagem de processos de negócio com o propósito de adquirir conhecimento

necessário para calcular tempo e custo de um projeto de modelagem de processos do

negócio [Sousa10].

2.6.2.EPC – Event-driven Process Chain

O diagrama EPC é o modelo central para toda a modelagem de negócio. É um

modelo dinâmico que traz consigo os recursos estáticos do negócio (por exemplo,

sistemas, organizações e dados) e os organiza para conceber uma sequência de

tarefas ou atividades (“o processo”) que agrega valor ao negócio [Davis02].

Este modelo possui similaridades em relação ao modelo desenvolvido a partir do

uso da notação BPMN, já que ambos detalham os processos de negócio no nível de

atividades utilizando elementos semelhantes. O fluxo de trabalho detalhado em um

modelo EPC engloba informações como papéis executores e suas unidades

organizacionais, raias que organizam as atividades de acordo com seus papéis

executores, elementos de interface com outros processos, eventos que demarcam o

início e o fim do processo, eventos intermediários que sinalizam circunstâncias

importantes para a continuidade do processo (principalmente nos fluxos de decisão),

operadores lógicos para inserir regras no fluxo e as próprias atividades que serão

executadas ao longo do processo [Sousa10].

A Figura 29 ilustra um exemplo de EPC. Este modelo possui atividades

executadas pela área de “Crédito e taxas contratuais” e pelo sistema “Crédito direto”.

As atividades de responsabilidade de cada papel estão respectivamente em suas

raias. As linhas que cruzam a linha das raias representam handoffs entre os papéis

executores do processo.

Figura 29 – Exemplo de modelo EPC [Sousa10]

Organizational el... .

Ca

rrie

s o

ut &

Su

pp

ort

sC

arr

ies

ou

t &

Su

pp

ort

sC

arr

ies

ou

t &

Su

pp

ort

sC

arr

ies

ou

t &

Su

pp

ort

sC

arr

ies

ou

t &

Su

pp

ort

sC

arr

ies

ou

t &

Su

pp

ort

sC

arr

ies

ou

t &

Su

pp

ort

sC

arr

ies

ou

t &

Su

pp

ort

sC

arr

ies

ou

t &

Su

pp

ort

sC

arr

ies

ou

t &

Su

pp

ort

sO

the

r

Crédito e taxascontratuais

Receber propostade crédito

Proposta de

crédito recebida

SYS

Verificar situação

cadastral do cliente

SYS

Verificar limite decrédito do cliente

Limite aprovado

Limite não

aprovado

SYS

Cancelar proposta

Comunicar limitenão aprovado

Limite nãoaprovado

comunicado

SYS

Determinar taxa dejuros a ser

cobrada do cliente

Analisar contrato

Necessidade deajuste do

contrato nãoidentificada

Contrato derisco

identificado

Necessidade deajuste docontrato

identificada

SYS

Cancelar contratode risco

Alterar propostade crédito

Proposta decrédito alterada

Contrato derisco cancelado

Aprovar contratoContrato

efetivado

Montar contrato

SYS

Para cada tipo de imposto

Calcular alíquotade imposto

Propostacancelada

Crédito Direto

54

2.6.3.FAD – Function Allocation Diagram

O diagrama FAD é um modelo que possui informações sobre uma atividade do

ponto de vista operacional. É utilizado para apresentar uma visão mais detalhada dos

recursos disponíveis e necessários, que são relevantes para as atividades. O FAD

também é utilizado para reduzir a complexidade visual do diagrama de processo de

negócio (neste caso, considere o modelo EPC), representando elementos como, por

exemplo, funções, áreas, sistemas de apoio, entradas e saídas de dados, documentos

e riscos envolvidos nas atividades [Sousa10]. Observe que a notação BPMN não

possui modelos FAD, e que o fluxo de informações é modelado no próprio diagrama

principal.

A Figura 30 exemplifica um modelo FAD. Esta atividade é executada pelo

sistema “Crédito Direto”, caracterizando uma atividade automatizada. As informações

que a atividade consome são “Proposta de crédito”, “Créditos concedidos” e “Cadastro

de cliente”, sendo esta última extraída da base de dados “BDCliente”. O resultado da

atividade é a informação “Proposta de crédito” atualizada com um status de aprovação

que depende da regra de negócio “Verificação de limite de crédito” e que é

implementado de acordo com o requisito de negócio “Verificar limite de crédito do

cliente”.

Figura 30 – Exemplo de modelo FAD [Sousa10]

2.6.4.Diagrama de objetivos

Além da possibilidade de relacionar o objetivo ao processo na cadeia de valor,

ainda é possível detalhar os objetivos do negócio em um diagrama específico. O

diagrama de objetivos trata os objetivos como elementos centrais e permite o

relacionamento com processos, produtos/serviços, fatores críticos de sucesso (FCS) e

o relacionamento entre objetivos de forma hierárquica. A Tabela 9 e

Verificar limite de

crédito do cliente

Crédito DiretoProposta de

crédito

Cadastro do

cliente

Créditosconcedidos

BDClienteProposta de

crédito

Verificação de limite de

crédito

Verificar limite

de crédito decliente

55

Tabela 10 apresentam respectivamente os elementos do diagrama de objetivos

e os tipos de relacionamentos disponíveis entre os elementos. Observe que os

relacionamentos são limitados e não podem ser customizados (apenas é possível

substituir o nome de representação, mas não o tipo).

Tabela 9 – Elementos de um diagrama de objetivos


Objetivo

O objetivo pode ser decomposto em subobjetivos e deve estar relacionado direta ou indiretamente a um processo.

Processo

Um processo deve ter um ou mais objetivos relacionados.

Fator crítico de sucesso

(FCS)

O fator crítico de sucesso é relacionado ao objetivo e representa algo que deve ser tratado para que o objetivo seja alcançado.

Produto/Serviço

Um Produto/Serviço é consumido ou produzido por um processo.

Tabela 10 – Conexões permitidas entre os elementos do diagrama de objetivos

Conexão x Objeto

Objetivo Processo Fator crítico Produto/ Serviço

Objetivo Belongs to Supports N/A N/A

Processo Supports N/A N/A Has output of

Fator crítico Is critical fator for N/A N/A N/A

Produto/ Serviço Supports is input for N/A N/A

A Figura 31 apresenta um exemplo de modelo de objetivos. O objetivo

“Aumentar eficiência” é composto pelos objetivos “Reduzir custos” e “Aumentar lucro”.

Este último encontra-se relacionado ao fator crítico de sucesso “Lucro”. Os processos

“Executar campanha publicitária” e “Verificar estratégias de preço”, estão relacionados

ao objetivo “Aumentar Market Share”.

Objective

Process

Critical factor

Product/Service

56

Figura 31 – Modelo de objetivos

Esta subseção apresentou a modelagem de processos de negócio e objetivos

utilizando a ferramenta ARIS, que implementa o framework ARIS. A ferramenta

oferece três níveis de modelagem de processos de negócio (VAC, EPC e FAD) além

de um diagrama específico para a modelagem de objetivos.

Por ser uma ferramenta comercial, a customização de elementos no ARIS é

bastante limitada, de forma a garantir sempre as regras de seu framework original.

Portanto, existem dificuldades para representar modelos mais detalhados no contexto

da semântica dos relacionamentos entre os elementos, por exemplo, relacionamentos

de medidas qualitativas/quantitativas, que não existem na linguagem. Essas

limitações na definição de novos elementos dificultam a configuração de alterações

que ampliam a expressividade dos diagramas auxiliando as análises de alinhamento

entre os processos e objetivos. Por exemplo, não é possível identificar as atividades

chave de um processo sem a rastreabilidade entre as necessidades de um objetivo e

as atividades executadas. Também não é possível utilizando-se apenas a notação

disponível, verificar através dos modelos se o processo é capaz de satisfazer um

objetivo, ou ainda, medir de forma quantitativa o seu impacto na camada estratégica

do negócio.

Particularmente, cabe observar que apesar da plataforma ARIS possibilitar uma

hierarquização dos objetivos por intermédio do diagrama de objetivos, o consequente

alinhamento a diferentes processos é de difícil execução principalmente pela ausência

de relacionamentos que possuam semântica para criar a rastreabilidade entre os

objetivos e atividades que visam satisfazê-los.

57

A próxima seção apresenta uma rápida análise das linguagens vistas e

justificativas para a seleção das linguagens utilizadas na integração.

2.7. Seleção de linguagens

O objetivo desta seção é ponderar sobre cada linguagem analisada nas

subseções anteriores para realizar uma breve análise sobre seus pontos positivos e

negativos e então justificar a escolha das linguagens para o trabalho de integração.

O que se busca neste momento é uma linguagem de modelagem de objetivos e

outra de modelagem de processos de negócio para, posteriormente, inserirmos a

rastreabilidade entre as linguagens, adicionando os elementos necessários, além de

propor um método de verificação do alinhamento no nível de modelagem.

Um dos objetivos da seleção das linguagens é o reuso de seus elementos e

definições de interface, uma vez que seria um retrabalho projetar novos elementos

representativos, considerando que muitas das definições utilizadas atualmente nos

modelos já possuem certa padronização em seus elementos gráficos, mesmo entre

diferentes ferramentas e notações. Por outro lado, não vamos nos ater às regras de

cada linguagem, mas realizar as adaptações que forem necessárias para alinhar

melhor os modelos. O conjunto de alterações expressivas na união das linguagens

resultará em uma nova solução, porém derivada das linguagens escolhidas.

Nesta avaliação, não somente a capacidade da linguagem será importante, mas

todo o contexto de aceitabilidade do mercado e a importância da linguagem dentro de

seu domínio. Iniciaremos as análises no domínio dos processos de negócio e

posteriormente, no domínio dos objetivos.

2.7.1.Domínio de processos de negócio

Seguindo de acordo com a sequência de apresentações das linguagens de

modelagem de processos de negócio neste capítulo, temos a seguinte lista: UML,

BPMN, UCM e EPC.

A modelagem de processos de negócio na UML inicialmente era desenvolvida

utilizando o diagrama de atividades padrão que não possui recursos suficientes para

modelar a complexidade de um processo de negócio. No entanto, com a proposta de

extensão de [Eriksson&Penker00], foram incluídos novos conceitos, aumentando a

capacidade de representação da linguagem.

A UML é uma linguagem fortemente consolidada no contexto do

desenvolvimento de software e seu diagrama de atividades já é utilizado há anos pelos

58

profissionais da áera, entretanto, o fato da extensão de processos de negócio não ser

um elemento nativo da UML é um ponto negativo. O diagrama de atividades em si

permite apenas o desenho simples do fluxo de atividades, não permitindo, por

exemplo, o registro de insumos e produtos das atividades, tais como informações e

artefatos. Outro fator agravante é que, apesar desta proposta surgir em 2000, a OMG

lançou em 2001 a BPMN, alcançando rapidamente um grande número de usuários.

A BPMN é um padrão atualmente desenvolvido pela OMG, que é um consórcio

aberto, de nível internacional, que foi fundado em 1989 com o objetivo de criar

padrões através do apoio dos diversos membros participantes ao redor do mundo

[OMG12]. Entre as grandes empresas que participaram do desenvolvimento da BPMN

2.0, podemos citar: Oracle, SAP AG, Unisys, Accenture, IDS Scheer, Red Hat, TIBCO

e Hewlett-Packard.

Com o auxilio de diversos usuários, é possível desenvolver os padrões unindo a

experiência de vários grupos, além de facilitar a aceitabilidade e uso dos conteúdos

gerados. Com isso, a BPMN é atualmente a notação mais utilizada para a modelagem

de processos de negócio [OMG11a].

Isso também se justifica pelo grande número de ferramentas comerciais e

principalmente gratuitas (incluindo ferramentas de código aberto) disponíveis no

mercado. Como exemplo de ferramentas gratuitas (algumas livres) que oferecem a

BPMN podemos citar ARIS Express, Barium Live, BizAgi Process Modeler, BonitaSoft,

Eclipse BPMN Modeler, Intalio BPMS, Interfacing Free Vision BPMN Modeler, ITP

Commerce BPMN Visio plug-in, Oryx, Processmaker Open Source BPM and Workflow,

Questetra BPM Suite, TIBCO Business Studio, Visio BPMN Modeler e ainda um vasto

número de ferramentas que podem ser encontradas em [Louw12]. Isso demonstra a

grande aceitação da notação e a maturidade de difusão, já que temos ferramentas

desenvolvidas por empresas de diversos países.

Na capacidade da notação em representar elementos de processos de negócio,

é a linguagem que mais oferece recursos gráficos. Identifica-se grande número de

componentes, muitas vezes de um mesmo tipo, mas com elemento gráfico levemente

distinto para representar situações específicas. Um exemplo são os eventos, que

podem ocorrer temporalmente em diversas circunstâncias, entretanto, dentro de um

processo de negócio, é comum certos eventos possuírem maior número de

ocorrências, por exemplo, a emissão de uma mensagem. Esses elementos são

chamados de triggers (Figura 32).

http://www.ariscommunity.com/aris-express/

http://www.bizagi.com/?lang=en

http://www.intalio.com/

http://www.interfacing.com/free-visio-bpmn-modeler

http://www.itp-commerce.com/

http://www.itp-commerce.com/

http://bpt.hpi.uni-potsdam.de/Oryx

http://www.processmaker.com/

http://store.questetra.com/en/

http://developer.tibco.com/business_studio/default.jsp

http://www.interfacing.com/free-visio-bpmn-modeler

59

Figura 32 – Tipos de eventos da BPMN

A BPMN não oferece recursos para a modelagem de objetivos, no entanto, isso

não é considerado um problema neste trabalho. Porém, isso talvez justifique a

ausência de regras de negócio na notação, que é um conceito importante já que

podem atuar diretamente no contexto dos objetivos da organização.

Outro ponto importante é que a BPMN, em relação à extensão da UML para

processos de negócio, é de autoria da OMG, o que garante maior possibilidade de

evolução contínua da notação de acordo com as necessidades reais do mercado e

maior garantia de longevidade. No contexto da extensibilidade, ambos permitem a

inserção de novas definições.

Outra linguagem analisada foi a UCM, que integra a URN, juntamente com a

GRL. A UCM é uma linguagem para modelagem de cenários que são usados para

descrever processos de negócios ou fluxos de trabalho.

Apesar da sua importância dentro da URN ao representar os processos

(descritos como cenários) relacionados aos objetivos, no contexto específico da

modelagem de processos de negócio ela torna-se menos adequada, seja pela

ausência de representação de elementos do negócio como pelo seu padrão gráfico de

modelagem.

60

Portanto entende-se que a UCM é importante no contexto da URN quando trata

de rastreabilidade e alinhamento entre objetivos e processos, mas para representar

modelos de negócio de forma abrangente, ela não é a melhor opção. Outros autores

corroboram com esse pensamento como [Pourshahid09] e [Sikandar03].

Como última linguagem analisada, temos o EPC que foi desenvolvido em 1992

pelo grupo do professor Scheer, na Universidade de Saarland. Assim como a BPMN, o

EPC possui vasta capacidade de representação de elementos de processos de

negócio e considerável aceitação do mercado. Um exemplo de importância da

linguagem é que os sistemas ERP da SAP utilizam os diagramas EPC para

documentar os processos do sistema SAP R/3.

O EPC é integrante de um dos frameworks mais avançados no contexto da

modelagem de processo: o framework ARIS. Esse framework inspirou o

desenvolvimento da ferramenta conhecida como ARIS (Architecture of Integrated

Information Systems), da empresa Software AG. Obviamente a ferramenta ARIS

também oferece o modelo EPC, porém muitas outras soluções foram desenvolvidas

contendo o diagrama, por exemplo, ARIS Express, ADONIS, Mavim Rules, Business

Process Visual ARCHITECT, Microsoft Visio, Semtalk, Bonapart e Oryx.

Apesar de ser uma linguagem sólida e reconhecida, não se tornou um padrão

internacional como a BPMN, principalmente por ter sido desenvolvido em um contexto

proprietário e ser o principal modelo de uma das soluções mais complexas e de alto

custo do mercado, não atingindo as empresas de pequeno porte e usuários simples.

Baseado nestas considerações, escolhemos a BPMN como notação para a

modelagem de processos de negócio, uma vez que consideramos sua capacidade de

modelagem de processos de negócio satisfatória e com elementos gráficos amigáveis,

além de ser um padrão reconhecido e adotado por um grupo internacional com

constantes atualizações e estar consolidado entre os usuários e desenvolvedores de

ferramentas.

2.7.2.Domínio de objetivos

No domínio de objetivos, de acordo com a sequência de linguagens

apresentadas neste capítulo, iniciaremos a análise com a extensão da linguagem

UML, prosseguindo com o framework i*, a GRL e o modelo de objetivos do framework

ARIS.

Assim como os elementos de modelagem de processos de negócio são

propostos através da extensão da UML por [Eriksson&Penker00], o mesmo trabalho

inclui a extensão de elementos para a modelagem de objetivos. Essa linguagem

http://en.wikipedia.org/wiki/ARIS_Express

61

oferece uma abordagem parecida com a do framework ARIS que permite o

relacionamento dos objetivos com os processos e a decomposição de objetivos em um

diagrama específico, entretanto, é a única linguagem (entre as analisadas) que

oferece o conceito de “problema”.

O framework i* é o precursor da modelagem intencional distribuída e no registro

do raciocínio (reasoning) para o alcance dos objetivos. A modelagem intencional é

voltada para objetivos, definidos como metas e metas-flexíveis. A modelagem

tradicional de processos utiliza objetivos, mas de uma maneira pouco profunda o que

acarreta uma série de problemas.

O i* permite uma análise aprofundada sobre os objetivos organizacionais e como

os objetivos provocam impactos uns nos outros e nas tarefas executadas pela

organização, uma vez que o i* lida com a intencionalidade de forma mais completa,

através da dependência estratégica entre os atores [Oliveira08c], evidenciando maior

nível de informações e detalhamento, o que contribui positivamente para a

transparência do negócio.

Além disso, é um dos frameworks mais referenciados e discutidos da atualidade,

servindo de inspiração para novos métodos, tais como GRL (Goal-Oriented

Requirements Engineering) e TROPOS [Bresciani04], [Castro02], ERi*c [Oliveira08c],

e extensões, tais como, Diagrama de IP [Oliveira08a], SD Situation [Oliveira08a], SR

Construct [Oliveira08b] e Diagnósticos i* [Oliveira08b]. Isso demonstra a importância

acadêmica do i*, principalmente como precursor da abordagem intencional.

Conforme visto, a GRL compõe a URN, que é um padrão internacional aprovado

pela União Internacional de Telecomunicação (ITU) e é composta pelos elementos

disponíveis no i*, incluindo extensões que ampliam a capacidade da linguagem tanto

para a modelagem de agentes (em sistemas multiagentes) como maior capacidade

semântica de relacionamentos, já que a GRL aborda especialmente requisitos não

funcionais.

Apresentando uma visão distinta da modelagem de objetivos baseada em i*,

encontra-se o modelo de objetivos do framework ARIS. Consideramos este modelo

como o mais simples, principalmente no que tange a capacidade semântica dos

relacionamentos. Além de não diferenciar meta de meta-flexível e de não possuir

relacionamentos de contribuição, oferece apenas um tipo de relacionamento entre

objetivos (belongs to) e outro entre objetivos e processos (supports). Além disso, não

permite a extensão da linguagem (ou seja, do framework ARIS) para inclusão de

novos elementos. Entretanto, é a única linguagem a explorar o conceito de FCS (Fator

Crítico de Sucesso) [Rockart78], [Grunert&Ellegard92].

62

Duas linguagens se destacam entre as linguagens analisadas pela capacidade

representativa dos elementos e semântica dos relacionamentos: i* e GRL. Na escolha

entre as duas linguagens, optamos pelo i*, uma vez que a capacidade da GRL é

justificada pelo uso do i* e, além disso, acreditamos que o i* possui maior enfoque

acadêmico.

Sabemos que existem muitas outras linguagens além das analisadas neste

trabalho, por exemplo, somente entre as linguagens discutidas por trabalhos que

utilizamos como referências [Pourshahid09], [List&Korherr06], temos: IDEF, Petri Nets,

YAWL e EEML, entretanto, descartamos estas linguagens porque entendemos serem

menos expressivas no contexto da modelagem de processos do que as outras. Além

disso, os trabalhos de [List&Korherr06] e [Pourshahid09] já demonstram que estas

linguagens não oferecem mais benefícios do que as linguagens abordadas.

Esta subseção apresentou uma avaliação das linguagens de modelagem de

processos e objetivos abordados neste capítulo e justificou a escolha da BPMN e do

framework i* para o trabalho de integração das linguagens. Cabe salientar que ao

reutilizar os conceitos dessas linguagens, a capacidade e restrições referentes à

modelagem de processos de negócio e objetivos são basicamente as mesmas das

linguagens BPMN e i*, e apenas mudanças convenientes à integração foram

aplicadas. Neste trabalho não atentamos a possíveis imperfeições das linguagens,

mas apenas focamos na comparação de suas qualidades nos quesitos que

consideramos importantes.

A Tabela 11 e Tabela 12 sintetizam de forma comparativa, com notas de 0 a 4,

sendo o menor valor representando ausência da capacidade descrita, e o maior valor

representando a máxima pontuação de satisfação. Os valores foram definidos

baseados na experiência prévia e conhecimento adquirido durante o estudo.

O quesito Interface refere-se à capacidade representativa dos elementos

gráficos; Representação refere-se à capacidade de englobar as diversas definições

dos elementos envolvidos no respectivo domínio; Popularidade refere-se às frentes de

pesquisa existentes, artigos, citações, porém, principalmente à percepção de volume

de usuários utilizando a linguagem; Integração refere-se à presença de elementos que

relacionam objetivos e processos de negócio; Padronização refere-se à forma como a

linguagem foi projetada, propósito, autores e uso como linguagem padrão dentro de

seu domínio; Ferramentas referem-se ao número de softwares disponíveis que

oferecem a modelagem da respectiva linguagem; Evolução refere-se à projeção de

atualização e continuidade da linguagem.

63

Tabela 11 – Comparação entre as linguagens de modelagem de processos

Diagrama de

processos (UML) BPMN UCM (URN) EPC (ARIS)

Interface 2 4 1 4

Representação 2 3 1 4

Popularidade 1 4 2 3

Integração 2 0 3 0

Padronização 1 4 4 4

Ferramentas 1 4 1 2

Evolução 2 4 3 4

Tabela 12 – Comparação entre as linguagens de modelagem de objetivos

Diagrama de

objetivos (UML) I* GRL (URN)

Diagrama de

objetivos (ARIS) NFR

Interface 3 4 4 3 4

Representação 2 4 4 2 3

Popularidade 2 3 3 2 3

Integração 2 0 3 0 0

Padronização 1 1 2 2 2

Ferramentas 1 2 1 1 2

Evolução 2 4 3 2 4

O próximo capítulo apresenta a integração das duas linguagens, os novos

elementos, relacionamentos e visões propostas.

64

3 Arquitetura de Integração

O objetivo da integração é permitir a modelagem de objetivos e a modelagem de

processos em um mesmo diagrama de forma a explicitar o “porque” e o “como” ao

mesmo tempo, evidenciando o alinhamento ou desalinhamento entre processos e

objetivos e aumentando a transparência dos modelos.

As duas notações (i* e BPMN) possuem elementos e regras próprias que não

necessariamente serão reutilizadas aqui. O framework i* oferece a modelagem de

objetivos a partir do ponto de vista dos atores, entretanto, em nossa proposta seus

elementos são reutilizados na modelagem de objetivos de processos de negócio e,

consequentemente, sofre alterações para se adequar à integração. A BPMN serve de

base para a modelagem de processos de negócio – sendo que este já é o seu papel

principal - mas também é adequada para a integração.

O resultado do trabalho é uma nova forma de representação e uso de elementos

do i* e da BPMN, o que consideramos uma nova linguagem que reutiliza elementos de

interesse para a integração. Essa nova linguagem oferece notação mais completa,

principalmente no que tange os relacionamentos entre objetivos de negócio, objetivos

dos atores (objetivos de mais baixo nível) e suas atividades, que visam satisfazer os

respectivos objetivos. Outras contribuições são discutidas posteriormente.

3.1.Similaridades entre as notações

[Cardoso10] apresenta um estudo que propõem a integração semântica entre os

elementos do framework ARIS e a linguagem TROPOS, correlacionando seus

elementos similares. Nesta seção apresentaremos as similaridades que identificamos

entre a BPMN e o framework i*.

A Tabela 13 apresenta os elementos que possuem a mesma semântica nas

duas linguagens. A pool do agente tem o mesmo objetivo que a pool do papel executor

que é a imposição de limites no modelo para a inserção dos elementos que são de

responsabilidade do ator/agente. Ator e agente também possuem a mesma semântica.

65

Tabela 13 – Similaridades entre elementos do i* e BPMN

Framework i* BPMN

Nome Símbolo Nome Símbolo

Pool do ator + agente

Pool

Tarefa

Atividade

Recurso

Objeto de dados

A tarefa é similar a atividade representando ações que são executadas pelos

atores/agentes. Entretanto, a tarefa também pode representar um processo mais

abstrato, que em BPMN é representado por um elemento igual a atividade, mas com

uma marcação de subprocesso (Figura 37).

Os relacionamentos de decomposição e meios-fim (means-end) podem ser

interpretados em relação aos relacionamentos da BPMN, entretanto esses são mais

complexos, já que dependem dos elementos que se relacionam.

No caso do relacionamento entre tarefa e meta através da decomposição, não é

especificado como o objetivo deve ser atingido porque isso não é interesse do ator

[iStarWiki12], portanto podem existir alternativas a serem executadas, entretanto, isso

é de interesse do alinhamento entre processos e objetivos, e deve ser expressado

claramente. Esse objetivo será alcançado por uma ou mais tarefas interligadas pelo

relacionamento meios-fim, que insere a ideia de XOR (ou exclusivo). Para estas

tarefas, o objetivo é algo a ser alcançado. Traduzindo para BPMN, temos um

macroprocesso que pode ser executado por um dos dois processos/tarefas que visam

alcançar o objetivo (Figura 33). Em outras palavras, no i* as tarefas marcadas com o

sinal ‘’?’’ implementam o objetivo que decompõem a tarefa mais abstrata. Em BPMN

essas tarefas correspondem a atividades que almejam alcançar o objetivo. A tarefa

mais abstrata corresponde a um processo macro.

66

Figura 33 – Relacionamento Decomposição entre tarefa e objetivo no contexto BPMN

No relacionamento entre tarefas através do link de Decomposição, a tarefa

macro é restringida à execução das subtarefas [iStarWiki12]. Todas as tarefas que

decompõem devem ser executadas em prol da tarefa macro, porém sem restrição de

ordem de execução, portanto, em BPMN esse é um relacionamento de inclusão (AND)

(Figura 34).

Figura 34 – Relacionamento de Decomposição entre tarefas no contexto da BPMN

No relacionamento entre tarefa e recurso através do link de Decomposição, o

recurso deve estar disponível, sendo que o ator da tarefa não é o responsável pelo

recurso [iStarWiki12]. Portanto, na BPMN esse recurso é repassado por terceiros para

o responsável da tarefa que a utiliza como insumo. Pode também ser um produto de

um processo que serve de insumo para outro.

No relacionamento entre tarefa e meta-flexível através do link de Decomposição,

a meta-flexível representa um atributo de qualidade que deve ser seguido na execução

da tarefa e guiará na escolha de alternativas entre as demais decomposições que

estão abaixo dela [iStarWiki12]. Em BPMN, a meta-flexível poderá representar uma

regra de negócio ou novas atividades de decisão que seguem em um dado fluxo a

partir de algum parâmetro.

67

O relacionamento de meios-fim apresenta uma tarefa “meio” que representa a

ação ou conjunto de ações realizadas que levaram ao produto “fim”. O produto fim

pode ser um recurso, outra tarefa ou um meta/meta-flexível. No caso do “fim” como um

recurso, podemos representar em BPMN o produto de uma atividade ou processo.

Caso o “fim” seja uma tarefa, representa um processo decomposto em outra tarefa, no

entanto, para mais de uma tarefa, há uma relação de XOR (ou exclusivo), já que a

execução de uma das tarefas é suficiente (Figura 35).

Figura 35 – Relacionamento de meios-fim entre tarefas no contexto BPMN

No caso dos relacionamentos de dependência, eles tornam-se implícitos na troca

de recursos entre raias e processos na BPMN.

3.2. Adaptações necessárias

O i* é uma linguagem para a modelagem de objetivos (meta e meta-flexível) e de

estratégias que visam satisfazer os objetivos de forma intencional, considerando o

ponto de vista de um agente. Ela parte da modelagem do alto nível com os objetivos e

pode descer até a representação de atividades e recursos de tarefas.

Nosso ponto de interesse no reuso do i* segue até o nível em que as tasks

(tarefas) iniciam a representação de elementos dos processos de negócio ou mesmo o

próprio processo. É neste momento em que fica a cargo do reuso de recursos da

BPMN a introdução de maiores detalhes de como as atividades/processos são

executadas. Portanto é possível perceber que o “reasoning” típico dos atores/agentes

será compartilhado com a BPMN que também possui elementos para representá-lo,

tais como operadores lógicos e eventos. O i* será responsável primordialmente pelas

representações de alto nível, contendo objetivos e processos abstratos, e a BPMN,

pelos elementos de baixo nível, representando o fluxo de recursos e as tarefas.

A Figura 36 demonstra basicamente os limites das linguagens e seus pontos de

encontro.

68

Figura 36 – Integração BPMN e i*

Um ponto importante a salientar é que apesar de propormos o diagrama que

integra as linguagens e a sua semântica de uso, não limitamos o uso dos recursos das

duas linguagens caso o usuário deseje inserir mais elementos representativos. Por

69

exemplo, a BPMN já representa a dependência de recursos entre os handoffs

(passagem de fluxo de um ator para outro) naturalmente no diagrama, porém se o

usuário desejar também representar isso no alto nível, utilizando i*, não haverá

restrições.

No diagrama da Figura 36 é possível identificar duas adaptações importantes na

integração. Uma é referente ao elemento gráfico que representa tarefas. Como no i*

não existe uma diferenciação gráfica entre tarefas que representam atividades simples

e tarefas que representam um conjunto de atividades (na linguagem i* considera-se as

tarefas folhas como tarefas atômicas), acrescentamos ao elemento representativo o

mesmo sinal que a BPMN utiliza para representar o processo que possui

subprocessos (Figura 37 e Figura 38). O sinal de “+” representa uma atribuição

(assignment), ou seja, um relacionamento com o modelo de subprocesso. Essa

atribuição é necessária para a integração das linguagens, uma vez que não será

possível representar todos os processos em BPMN em um mesmo modelo caso o

nível de objetivos (pertinente aos elementos do i*) possua muitas tarefas deste tipo.

Figura 37 – Processo que contém subprocesso

Figura 38 – Tarefa que contém subprocesso

Outra adaptação foi a ampliação dos elementos nos quais o relacionamento de

meios-fim e decomposição de tarefa podem conectar. Os processos em BPMN

sempre serão relacionados com os outros elementos a partir destes conectores

mantendo a mesma semântica.

O elemento “Regra de negócio” (Figura 39) também foi incluído entre os

elementos da BPMN.

Figura 39 – Elemento Regra de Negócio

70

Alguns objetivos podem ser expressos como regras de negócio, portanto esse

elemento foi incluído. Nestes casos consideramos que é melhor expressar os objetivos

como regras locais dentro de um processo do que como objetivos do processo, uma

vez que são mais difíceis de serem medidos porque não necessariamente essas

regras irão gerar produtos, mas apenas controlar a forma como os processos devem

ser executados. Entretanto as regras de negócio tornam claras as respectivas

decisões no fluxo dos processos e as formas de proceder em atividades, o que a

classifica como uma informação importante.

As próximas subseções descrevem os diagramas (visões) principais da nova

linguagem. As definições de outros elementos que serão incluídos na linguagem

aparecerão conforme a apresentação dos modelos.

3.3. Diagrama Integrado

O objetivo do Diagrama Integrado é permitir, em um único modelo, a

visualização dos elementos do escopo da modelagem de objetivos e da modelagem

de processos, ou seja, ele inter-relaciona elementos de processos da BPMN e

elementos de objetivos do i*, formando uma única visão.

Conforme dito na subseção anterior, o encontro entre BPMN e i* situa-se no

nível de processo, conforme apresenta a Figura 36. Uma vez que toda a parte “macro”

foi modelada partindo do nível mais abstrato, o detalhamento de seus elementos

resulta na descrição de um segundo nível, onde se encontram os processos.

No primeiro nível de detalhamento, é possível fazer a ligação com modelos

BPMN diretamente a partir do relacionamento de “Atribuição” (Figura 40), ou a partir

de um relacionamento meios-fim (Figura 41). No relacionamento de atribuição o

processo BPMN fica relacionado através de um link “+” que consta no elemento

gráfico.

Figura 40 – Relacionamento de Atribuição levando ao modelo de processos

71

Também é possível explicitar o modelo de processo através do relacionamento

“meios-fim”, conforme mostra a Figura 41.

Figura 41 – Relacionamento meios-fim

Cada processo é executado por um conjunto de atores, esses atores executam

atividades do processo de acordo com o seu “reasoning” (ou seja, os caminhos de

atividades percorridos estrategicamente baseado nos diferentes estados possíveis),

bem como o que aqui definimos como “objetivos locais”, que são os objetivos que

partem do ponto de vista do ator, ou seja, objetivos de baixo nível que representam a

intencionalidade do ator em contemplar suas responsabilidades dentro do processo.

Ao detalhar um processo pelo ponto de vista intencional dos atores, estaremos

implementando o segundo nível de detalhamento do Diagrama Integrado.

A Figura 42 apresenta o detalhamento de objetivos do “Papel 1” e “Papel 2”,

relacionando com suas raias no processo, demonstrando as atividades executadas

para atingir seu objetivo (considere neste processo a possibilidade de representar os

elementos da BPMN e no modelo de objetivos, o uso de outros elementos, por

exemplo, a representação de dependência entre os papéis).

A Figura 43 detalha ainda mais os relacionamentos entre objetivos e suas

atividades. Seus objetivos no processo são relacionados ao trecho de atividades que

são específicas para satisfazer os “objetivos locais”. Este modelo permite a

rastreabilidade entre o “porque” e o “como” na camada mais próxima ao nível

operacional. As atividades são agrupadas através do elemento “agrupamento” da

BPMN e relacionadas aos respectivos objetivos através do relacionamento de “meios-

fim”.

72

Cabe salientar que os “objetivos locais” são detalhamento dos objetivos de

processo, ou seja, são subobjetivos, porém expressados no nível de abstração dos

atores. Essa relação possibilita a rastreabilidade entre os objetivos de alto nível, os

atores responsáveis e suas atividades, o que torna mais fácil e preciso, por exemplo, a

identificação de responsabilidades e propagação de impactos causados por problemas

ou mudanças, apenas percorrendo o modelo.

Figura 42 – Detalhamento no diagrama integrado ao nível de papéis executores

73

Figura 43 – Relacionamento de “objetivos locais” dos papéis e rastreabilidade no processo

Essencialmente, fazem parte do Diagrama Integrado todos os elementos do i* e

da BPMN selecionados para uso neste trabalho. Além dos elementos demonstrados

até o momento, também inserimos o conceito de indicadores e propusemos uma

forma de utilizá-lo dentro da nova linguagem.

Um indicador, mais precisamente um “Key Performance Indicator (KPI)” ou

“Indicador Chave de Performance (ICP)”, é um termo da indústria para medição ou

métrica que avalia a performance relativa a algum objetivo. Indicadores são usados

rotineiramente por organizações para medir tanto sucesso quando qualidade na

satisfação de objetivos estratégicos, aprovando processos ou entregando

serviços/produtos. Por exemplo, o indicador “Aumento da porcentagem da base de

clientes” pode ser apropriado para o objetivo “Aumentar Market share”, enquanto

“Duração média” pode servir como um indicador para a atividade “Pedido de

empréstimo” [Daniele11].

Indicadores constituem um elemento importante da modelagem de negócio já

que oferecem critérios para determinar se uma organização está alcançando seus

objetivos, sejam eles objetivos estratégicos, requisitos de qualidade, ou objetivos de

74

produção [Daniele11]. Na Engenharia de Requisitos, indicadores estão sendo usados

para avaliar o nível de satisfação de objetivos [Lamsweerde09 apud Daniele11].

A próxima seção apresenta como utilizar os KPIs como auxílio na análise de

alinhamento dos processos e seus objetivos.

3.4. Análise do alinhamento através de KPIs

Este subseção apresenta uma proposta que consiste em uma abordagem

baseada em indicadores com o objetivo de verificar a possibilidade de um processo

alcançar seus objetivos.

3.4.1.Introdução

Durante a modelagem dos processos de negócio, diversas informações são

levantadas e mapeadas em diferentes modelos, em seus respectivos níveis de

abstração. No nível mais abstrato, são representados os processos de negócio que

representam a cadeia de valor da organização, formada por processos de alto nível

que podem ser decompostos por outros processos em níveis inferiores, mas ainda

assim abstratos o suficiente para serem denominados “processos”. Cada processo

existe e se justifica quando ele é projetado de forma a atingir algum objetivo dentro da

organização. Da mesma forma que uma organização possui um objetivo geral que

justifica a sua existência (por exemplo, produzir um produto), cada processo e

subprocesso desta organização também possui seus objetivos (de nível mais baixo)

que ao serem satisfeitos, contribuem com os macros objetivos organizacionais.

Entretanto, cada processo poderá levar a diferentes níveis de satisfação de seus

objetivos: por exemplo, um processo, quando realizado a contento, pode satisfazer por

completo um objetivo; ou essa satisfação pode ser parcial (alguns chamam esta última

de contribuição). Nesse último caso, o objetivo então será cumprido caso mais de um

processo seja realizado com sucesso. Também é relevante mencionar que alguns

objetivos são cumpridos a cada execução de um processo enquanto outros dependem

de várias execuções de um mesmo processo para serem atingidos. De uma forma

geral, serão necessários diversos processos ocorrendo em paralelo para que a

organização obtenha sucesso em seu nicho de atuação.

Cada objetivo existente em uma organização (independente do nível de

abstração) impõe que um conjunto de condições seja satisfeito para que o objetivo

possa ser considerado alcançado. O termo “condições” refere-se, por exemplo, ao

desenvolvimento de um produto, um estado do processo, a produção de alguma

75

informação, o disparo de um evento específico ou qualquer coisa que possa ser

alcançada a partir da execução de um processo. Essas condições (ou conjunto de

condições) esperadas em um objetivo são definidas por elementos nomeados como

“Indicadores”. Os indicadores, quando interligados a objetivos, representam as

condições que devem ser alcançadas para que o objetivo possa ser satisfeito. Quando

interligados a processos, representam condições que são esperadas que sejam

produzidas ao instanciar o processo.

Abaixo do nível de modelagem dos processos de negócio, está mapeado o

conjunto de atividades que devem ser executadas para que o processo seja

considerado finalizado. A finalização do processo está inteiramente relacionada à

produção das condições necessárias para satisfação de seus objetivos. Ou seja, o

processo é responsável por produzir todas as condições esperadas a fim de alcançar

os objetivos relacionados ao dado processo.

A produção dessas condições está intimamente ligada aos diferentes estados e

transformações dos produtos e informações que são processados durante a execução

das atividades. As informações são manipuladas através das atividades, gerando

diferentes produtos e disparando diferentes eventos.

Como a execução natural do processo gera as diferentes condições necessárias

para alcançar os objetivos do processo, entende-se que os indicadores devem ser

definidos em função da produção destes elementos durante sua execução. Os

elementos produzidos pelo processo são vestígios que indicam se o processo de fato

produziu o esperado, que é definido através dos indicadores.

Portanto os indicadores podem ser definidos através dos elementos que são

desenvolvidos ao longo da execução do processo. Supondo-se que o processo produz

as informações necessárias para que os indicadores sejam calculados, podemos

inferir que:

1. Os indicadores podem ser calculados.

2. Se os indicadores forem satisfatórios (alcançarem suas metas), podemos supor que o

processo é eficaz.

Entenda como “satisfatório” o desempenho do processo necessário de forma

que os valores resultantes dos indicadores estejam dentro dos limites dos valores

esperados pela organização (metas).

Caso o processo não produza as informações necessárias, inferimos que:

76

1. Os indicadores não podem ser calculados.

2. Não é possível saber se o objetivo está sendo alcançado nos casos em que são

necessários insumos para gerar cálculos.

3. O objetivo (meta) não será alcançado caso dependa de produtos do processo.

4. A meta-flexível pode não ter contribuições suficientes para se tornar satisfatória.

5. Os processos encontram-se desalinhados com seus objetivos.

A diferença entre o item 2 e 3 é que existem objetivos que dependem apenas de

cálculos para serem verificados. Por exemplo, para a meta “O número de carros

produzidos mensalmente seja maior do que o número de carros vendidos no mês”,

seu indicador depende apenas de informações sobre números que o processo em

algum momento deve produzir para que o objetivo seja medido. No entanto, para a

meta “Um carro seja produzido por hora”, dado que em algum momento do processo

de fabricação de componentes houver falha na produção de um item e ele deixar de

ser produzido (por exemplo, um parafuso), então entende-se que na ausência do

produto, a meta fatalmente não será alcançada.

O fluxo de produtos que percorrem um processo pode estar modelado em um

diagrama de nível mais baixo, onde as atividades são detalhadas com informações

operacionais (como no framework ARIS), mas na BPMN, encontram-se registrados no

mesmo nível das atividades, no modelo de processo de negócio. A modelagem do

nível operacional consiste em registrar os elementos que participam da execução de

uma atividade, por exemplo, dados de entrada e saída, sistemas de apoio,

ferramentas utilizadas, regras de negócio e requisitos de negócio. A BPMN somente

oferece um nível de modelagem, que é o nível de processo, logo esses elementos

devem estar relacionados neste nível (conforme dito anteriormente, a BPMN não

oferece modelagem de regras de negócio, e também não possui os elementos que

representem requisitos de negócio. Porém cabe salientar que a BPMN deixa em

aberto a possibilidade de inclusão de novas definições de negócio no modelo

[OMG12], bem como oferece elementos de “anotações” que podem conter as

informações textuais. Neste trabalho incluímos o elemento “Regras de Negócio”

devido a sua importância para o mapeamento de objetivos e processos, entretanto,

não abordamos os impactos de sua aplicação).

Os elementos que são necessários para calcular um indicador são produzidos

pelas atividades e naturalmente modelados ao registrar os elementos de saída das

atividades. Nem todos os elementos produzidos pelas atividades são produtos chave

para um indicador, podendo tratar-se apenas de informações que perpassam os

processos como elementos intermediários que podem, em sequência, se transformar

ou não em novos produtos de maior valor para o negócio.

77

Portanto, uma das primeiras ações que realizamos foi de desenvolver um novo

elemento representativo, levemente distinto, de forma a proporcionar a identificação

simples dos elementos que são utilizados como insumos para os indicadores (os quais

chamamos de “críticos”) em relação aos elementos que participam apenas do fluxo do

processo. A Figura 44 e Figura 45 apresentam a diferença entre esses elementos. A

única diferença foi a cor do elemento que tornou-se vermelha como forma de chamar

mais atenção ao elemento crítico que o processo deve produzir.

Figura 44 – Cluster representando informações/artefatos que fluem através do processo

Figura 45 – Cluster representando informações/artefatos necessárias ao indicador

3.4.2.Uso de indicadores no Diagrama Integrado

O Diagrama Integrado é composto por elementos do i*, da BPMN, além de

elementos que auxiliam na integração. Para aplicarmos a abordagem da análise de

alinhamento utilizando indicadores, foram incluídos ao diagrama novos elementos para

apoiar a representação dos recursos críticos (apresentado na subseção anterior),

indicadores e novos relacionamentos.

A Tabela 14 apresenta o conjunto de elementos que foram adicionados ao

Diagrama Integrado. Dois relacionamentos foram incluídos para ligar o recurso crítico

ao indicador (com a semântica de “Recurso crítico é insumo para o Indicador”), e para

ligar o indicador à meta/meta-flexível (com a semântica de “Indicador mede o

objetivo”).

78

Tabela 14 – Novos elementos incluídos ao Diagrama Integrado


Recurso crítico

(Informação/Artefato)

Representa um artefato/informação que é utilizado como insumo para cálculo dos indicadores.

Indicador

Representa o elemento indicador.

Associação (Insumo) Relaciona um Recurso Crítico como insumo de um Indicador.

Associação (Medição)

Relaciona um KPI como um elemento que mede satisfação de uma meta/meta-flexível.

Para exemplificar a aplicação do uso dos indicadores, foi desenvolvida a Figura

46. O Diagrama Integrado apresenta a modelagem de um processo que visa atender

um cliente. Na parte que define os objetivos, temos que o Atendente geral possui dois

objetivos, A meta-flexível “Clientes sejam atendimentos rapidamente” e a meta

“Clientes sejam atendidos de forma satisfatória”.

Para verificar o atendimento satisfatório da meta-flexível, foi criado o indicador

“Tempo médio de atendimento” que calcula a média de tempo dos atendimentos. Caso

a média seja menor ou igual ao tempo estabelecido pelo gestor como “rápido”, o

objetivo será considerado satisfatório. Esse objetivo caracteriza-se como meta-flexível

porque “tempo rápido” é discutível e pode mudar seus critérios de satisfação baseado

em pontos de vista distintos. Entretanto o indicador existe e calcula a média do tempo,

ficando a cargo de um possível gestor definir o que é “tempo rápido” baseado em

métricas que ele utilizar como apoio [Kaiya02], [Cysneiros&Leite]. Para que o indicador

possa ser calculado, ele necessita de um insumo, que é o tempo dos atendimentos.

Neste caso, a solução foi fazer a média a partir do tempo de gravação dos

atendimentos. Portanto, para que o indicador seja calculado, é necessário este recurso

crítico.

Para verificar a satisfação da meta “Atendimento mal sucedido seja menor que

10%” foi criado o indicador “Porcentagem de atendimentos mal sucedidos”. O objetivo

consiste em verificar se o número de atendimentos que não foram solucionados é

menor ou igual a 10% de todos os atendimentos. O indicador então calcula a

porcentagem baseando-se no número de todos os atendimentos e o número de

atendimentos mal sucedidos. O número de todos os atendimentos é calculado com o

79

somatório de gravações de atendimentos. O número de atendimentos mal sucedidos é

obtido a partir do registro de atendimentos que tenham sido mal sucedidos.

Para atender a esses objetivos, a Atendente geral deve realizar a tarefa “Atender

cliente”. Essa tarefa pode ser executada de duas maneiras: ao executar o processo

“Realizar atendimento presencial para clientes externos” ou “Realizar atendimento

telefônico para clientes externos”. Observe que neste caso o cliente em foco é um

cliente externo, entretanto, nada impede que esses objetivos sejam usados no

contexto dos clientes internos.

Na integração dos modelos, ficou expressado o processo “Realizar atendimento

telefônico para clientes externos”. Observa-se sem dificuldades que este processo

produz o recurso crítico “Gravação do atendimento”, necessário para calcular o

“Indicador tempo médio de atendimento” e também parte dos insumos necessários

para o cálculo do indicador “Porcentagem de atendimentos mal sucedidos”. Entretanto,

não é possível identificar o recurso crítico “Atendimento mal sucedido”. Com isso, é

possível concluir que o processo não é capaz de oferecer recursos para saber se o

objetivo “Atendimentos mal sucedidos seja menor do que 10%” está sendo alcançado

ou não, o que demonstra o desalinhamento entre os modelos, o processo e seu

objetivo.

É claro que o objetivo pode estar sendo alcançado, uma vez que, como dito

anteriormente, este é um objetivo que depende de cálculo e não de produto. Porém,

no nível de modelagem identifica-se o problema e para solucioná-lo, ou elimina-se o

objetivo ou o processo deve ser alterado de forma a permitir que a medição do objetivo

seja possível.

80

Figura 46 – Uso dos indicadores no Diagrama Integrado

Uma visão mais simplificada pode ser expressa como na Figura 47, onde o

detalhamento do processo é escondido em um relacionamento de “Atribuição” e a

produção do recurso crítico é explicita através de relacionamento.

Figura 47 - Uso dos indicadores de forma simplificada no Diagrama Integrado

81

Nos exemplos citados, o indicador mais complexo é que necessita de dois

elementos como insumo para realizar o cálculo. Entretanto podem existir muitos

objetivos relacionados a muitos indicadores que, por sua vez, necessitam de muitos

recursos para o seu cálculo. Isso pode tornar o Diagrama Integrado inviável em

número de elementos presentes, uma vez que ele já possui naturalmente a

modelagem de processos e objetivos no mesmo modelo. Para solucionar este

problema, desenvolvemos o Diagrama de Indicadores que “modulariza” o

relacionamento entre objetivos, indicadores e recursos críticos permitindo a extração

desses elementos do Diagrama Integrado e garantindo a possibilidade de análise dos

indicadores.

3.4.3.Uso do Diagrama de Indicadores

Esta seção apresenta a aplicação do Diagrama de Indicadores que tem como

objetivo permitir o relacionamento dos indicadores com os objetivos e dos indicadores

com os elementos necessários para medi-los que, neste caso, são as informações

e/ou artefatos críticos. Com este diagrama, viabiliza-se a proposta apresentada na

seção anterior sem a necessidade de representar no Diagrama Integrado todos os

elementos críticos, reduzindo assim a complexidade do modelo, principalmente em

casos em que diversos elementos devem ser modelados.

A Tabela 15 apresenta os elementos que compõem o Diagrama de Indicadores:

Tabela 15 – Elementos do Diagrama de Indicadores


Meta

Representa um objetivo que somente pode ser completamente satisfeito ou não satisfeito.

Meta-flexível

Representa um objetivo que pode ser satisfeito de acordo com pontos de vista, ou então parcialmente satisfeito.

Recurso crítico

(Informação/Artefato)

Representa um recurso considerado crítico em um processo, uma vez que ele é usado na medição dos objetivos do processo.

Indicador

Representa um indicador que pode medir um objetivo.

Processo

Representa um processo relacionado através de atribuição.

82

Associação (Insumo) Relaciona um Recurso Crítico como insumo de um Indicador.

Associação (Medição)

Relaciona um KPI como um elemento que mede satisfação de um meta/meta-flexível.

Associação (Produto)

Relaciona um Recurso Crítico que é produzido por um Processo.

Associação (Dever) Relaciona um Processo a uma meta/meta-flexível que deve ser satisfeito.

No Diagrama de Indicadores, o principal objetivo é relacionar o indicador aos

elementos críticos necessários para que ele seja calculado e relacionar o indicador ao

objetivo o qual ele mede. Esses relacionamentos são necessários porque ao retornar

no Diagrama Integrado, o Diagrama de Indicadores fará a ponte para a verificação dos

elementos críticos presentes nos processos com os elementos críticos presentes no(s)

indicador(es), além do relacionamento entre o objetivo e o indicador demonstrar se

aquele modelo se refere ao objetivo do processo avaliado.

Opcionalmente, é possível relacionar o elemento “processo” tanto ao objetivo

através do relacionamento de Associação de Satisfação (que tem a semântica que

implica que o processo deve satisfazer aos seus objetivos) quanto ao Recurso Crítico,

com o relacionamento de Associação de Produto (que tem a semântica que implica

que o processo produz o recurso crítico). A inclusão desses elementos adiciona ao

modelo a informação de qual processo que gera o recurso critico bem como o

processo responsável por atingir o objetivo. A inclusão desses elementos é opcional,

entretanto, torna mais transparente o contexto em que se encontram os

relacionamentos dos recursos críticos x indicadores x objetivos.

A Figura 48 apresenta um exemplo de um modelo no Diagrama de Indicadores:

Figura 48 – Exemplo de modelo no Diagrama de Indicadores

83

Este diagrama demonstra os relacionamentos básicos entre os elementos meta-

flexível, indicador e recurso crítico. A meta-flexível “Cliente seja atendido rapidamente”

implica no cálculo do tempo médio dos atendimentos aos clientes que é medido pelo

indicador “Tempo médio de atendimento”. Para realizar esse cálculo, o indicador utiliza

como insumo o recurso crítico “Gravações dos atendimentos”, extraindo a informação

de tempo e realizando a média. O objetivo será satisfeito se o valor do tempo médio

das gravações estiver dentro de um intervalo definido como rápido pelos gestores do

negócio (essas informações extras relacionadas aos elementos ficam registradas nos

campos “propriedades” dos elementos, oferecidos pela ferramenta).

No contexto da análise aqui proposta, para que a meta-flexível seja medida é

necessário que o processo relacionado a este objetivo obrigatoriamente produza o

recurso crítico “Gravações dos atendimentos”. Uma vez produzido, a satisfação da

meta-flexível (que é o valor do tempo médio) dependerá exclusivamente da instância

do processo (e para o caso de metas-flexíveis, também dependerá da interpretação do

possível avaliador ou ainda do valor resultante das diferentes contribuições que a

meta-flexível recebe. Em [Chung00] encontra-se mais explicações sobre a diferença

entre os conceitos de satisfação de metas e metas-flexíveis). Portanto, conforme dito

anteriormente, uma verificação de alinhamento possível de aplicar no nível de

modelagem é a identificação da produção dos recursos necessários para o cálculo dos

indicadores.

Esta seção apresentou a aplicação da proposta utilizando os elementos de

indicadores como um meio para relacionar objetivos, processos e

informações/artefatos. Com essa proposta é possível avaliar se o processo produz as

informações necessárias para que os indicadores ligados aos objetivos sejam

calculados. O simples cálculo dos indicadores não é suficiente para que se afirme algo

em relação aos objetivos do processo, ainda é necessário que a instância do processo

seja capaz de gerar informações que produzam indicadores satisfatórios. Desta forma,

se todos os indicadores relacionados a um objetivo estiverem satisfatórios, sugere-se

que o objetivo foi alcançado, entretanto, é possível identificar se o processo, conforme

está, possui capacidade de alcançar seus objetivos se for executado de forma a

produzir os resultados satisfatórios.

O próximo capítulo apresenta como foi realizada a implementação de todos os

elementos e modelos que foram desenvolvidos para possibilitar a integração das

linguagens.

84

4 Implementação da Integração

Este capítulo descreve como foram implementadas as linguagens e os

elementos de integração na ferramenta-protótipo que reutilizou o núcleo e estrutura da

ferramenta de código aberto Oryx.

4.1. Ferramenta Oryx

A ferramenta Oryx é um framework acadêmico de código aberto inicialmente

desenvolvido para oferecer a modelagem gráfica de processos de negócio (BPMo).

Sua tecnologia é baseada em web, sendo executado através de browser, o que

elimina a necessidade de instalação do software. Atualmente a ferramenta oferece

várias linguagens para modelagem, tais como BPMN (Business Process Model and

Notation) e EPC (Event-driven Process Chain), além disso, é extensível a novas

funções através da adição de plugins [Oryx12].

Sua arquitetura é bem definida e já foi reutilizada para o desenvolvimento de

soluções comerciais como, por exemplo, a ferramenta Signavio [Kunze&Weske10].

Além disso, a ferramenta Oryx encontra-se em uso por grandes empresas, por

exemplo, a organização Serpro [Serpro11], que realiza customizações para adequá-la

às suas necessidades.

A Figura 49 apresenta alguns diagramas disponíveis para uso através da

ferramenta Oryx. Atualmente a ferramenta encontra-se na versão Beta e pode ser

acessada pelo site oficial do Oryx: “http://bpt.hpi.uni-potsdam.de/Oryx/Research”.

85

Figura 49 - Painel com diversos exemplos de tipos de modelos que podem ser modelados na

ferramenta

4.2. Estudo da ferramenta

Apesar de possuir o código aberto, pouca documentação existe sobre a

infraestrutura da ferramenta, além disso, a documentação disponível encontra-se em

línguas estrangeiras como o inglês e alemão. Portanto, para adquirir o conhecimento

necessário para customizar a ferramenta de acordo com as nossas necessidades,

foram demandados esforços de pesquisa nas bibliografias existentes e principalmente

no código fonte, utilizando o método de tentativa e erro.

Como forma de projetar um caminho estratégico para alcançar o conhecimento

necessário sobre a ferramenta e posteriormente customizá-la, definiu-se o uso das

seguintes técnicas da engenharia de software: engenharia reversa e reengenharia de

software.

A engenharia de software utiliza-se dos princípios da engenharia reversa como

uma coleção de teorias, metodologias e técnicas capazes de suportar a extração e

abstração de informações de um software existente, produzindo documentos

consistentes, quer seja a partir do código fonte, ou através da adição de conhecimento

86

e experiência, que não poderiam ser automaticamente reconstruídos a partir do código

[Benedusi92].

A engenharia reversa atua no caminho contrário da engenharia progressiva, que

se define como àquela que segue a sequencia de desenvolvimento estabelecida por

uma metodologia, visando à obtenção do sistema implementado. Na engenharia

reversa o sistema geralmente é o ponto inicial do processo [Chikofsky&Cross90].

Portanto utiliza-se a técnica de engenharia reversa, quando o produto existe

juntamente com a necessidade realizar alterações de qualquer natureza, porém, não

existem insumos suficientes que documentem a sua infraestrutura de forma a

possibilitar o entendimento necessário para realizar as alterações.

Duas categorias dentro da engenharia reversa são apontadas por

[Chikofsky&Cross90]: redocumentação e recuperação do projeto.

A redocumentação visa criar diferentes visões do sistema, em diferentes níveis

de abstração através da análise do código fonte, para possibilitar maior compreensão

do sistema. O desenvolvimento dessas visões pode gerar nova documentação

(diferente da documentação preexistente), agregando mais conhecimento sobre o

sistema.

A recuperação do projeto visa obter as informações necessárias para melhorar

o entendimento sobre os objetivos do sistema, quais suas atividades e como ele as

executa.

Por sua vez, a reengenharia de software também chamada de recuperação ou

renovação, recupera informações de projeto de um software existente e usa essas

informações para alterar ou reconstituir o sistema, preservando as funções existentes,

ao mesmo tempo em que adiciona novas funções ao software, num esforço para

melhorar sua qualidade global [Piekarski&Quinaia95].

Essa definição demonstra uma ligação direta entre a reengenharia de software e

a engenharia reversa, uma vez que a reengenharia utiliza o conhecimento gerado a

partir da aplicação da engenharia reversa para possibilitar as alterações no software

durante a execução da reengenharia. Portanto existe distinção clara entre as duas

técnicas, conforme destaca [Piekarski&Quinaia95]: “O objetivo da reengenharia é

produzir um sistema novo com maior facilidade de manutenção e a engenharia reversa

é usada como parte do processo de reengenharia, pois fornece o entendimento do

sistema a ser reconstruído”.

Durante o trabalho no Oryx, foi recuperado o desenho da ferramenta a partir das

descobertas possibilitadas pela engenharia reversa e concluída a reengenharia ao

implementar um conjunto de plugins que possuem os elementos propostos neste

trabalho. As próximas subseções detalham as atividades realizadas.

87

4.2.1. Aplicando a Engenharia Reversa

Como início da execução da engenharia reversa, foi definido um plano composto

por três fases que, por sua vez, são compostas por um conjunto de atividades

conforme descrito na Tabela 16:

Tabela 16 – Projeção de macroatividades da engenharia reversa da ferramenta Oryx

Fase 1 Fase 2 Fase 3

Identificar como obter o código fonte

Identificar documentação da ferramenta

Estudar o código fonte

Identificar os procedimentos para a instalação da base de codificação

Estudar a arquitetura da ferramenta

Identificar os conceitos arquiteturais na codificação

Configurar o ambiente de desenvolvimento

Identificar os procedimentos para desenvolvimento de plugins

Avaliar outras necessidades

Execução da Fase 1

A primeira fase do processo de engenharia reversa foi iniciada com uma

pesquisa na internet para obter informações gerais sobre como proceder com a

instalação do ambiente de desenvolvimento Oryx. Durante as buscas foram

identificados muitos sites com o assunto “Oryx”, porém o site oficial do projeto Oryx

(http://code.google.com/p/Oryx-editor/) publicado no “Google Codes” ofereceu o

conjunto de informações necessárias para realizar as atividades da primeira fase. Os

procedimentos de instalação da ferramenta, acesso à codificação e configuração do

ambiente de desenvolvimento são descritos em [Sousa&Leite12].

Após as execuções destas atividades, a Fase 1 da engenharia reversa do

software Oryx foi finalizada. A próxima subseção descreve a execução da segunda

fase.


A segunda fase da engenharia reversa foi iniciada com a busca de documentos

que descrevessem a arquitetura da ferramenta Oryx. Alguns documentos [Daniel07],

[Peters07], [Tscheschner07], foram encontrados no site oficial Oryx-editor, no Google

Codes. Estes documentos são monografias desenvolvidas por alunos que estão

envolvidos no grupo de pesquisa da ferramenta Oryx. Os trabalhos possuem um

conteúdo extenso sobre a infraestrutura da ferramenta e o desenvolvimento de

plugins, no entanto, todas as documentações estão em língua estrangeira como o

inglês e o alemão.

http://code.google.com/p/oryx-editor/

88

Para solucionar parcialmente a dificuldade de leitura em alemão, os arquivos em

PDF deveriam ser traduzidos. Então foi feita uma pesquisa para identificar ferramentas

que realizassem esse trabalho. A maioria das ferramentas encontradas não traduziam

arquivos com extensão PDF, e as que traduziam eram caras, além disso, as traduções

em softwares gratuitos e demonstrativos eram limitadas em poucas linhas.

Outra busca foi realizada para verificar softwares de tradução de arquivos do tipo

DOC, e diversos aplicativos foram encontrados. A partir disso foi iniciada outra busca

por programas capazes de transformar arquivos PDF para arquivos DOC. Vários

aplicativos foram encontrados e a conversão foi feita, no entanto, o produto desta

conversão não foi satisfatório, já que foram inseridos no documento muitos caracteres

aleatórios, deformando sua formatação e afetando sua estrutura, o que impossibilitou

uma tradução minimamente satisfatória.

Novamente iniciou-se a busca por tradutores de PDF, e desta vez foi identificada

uma ferramenta de tradução online baseada no tradutor do Google (Google Translate -

http://translate.google.com.br/), disponível em

http://www.onlinedoctranslator.com/translator.html. Este ferramenta traduziu o

documento integralmente, mas também inseriu muitos erros, no entanto, foi a única

solução descoberta que produziu uma tradução aceitável.

Com a leitura destes documentos traduzidos foi possível obter o conjunto de

informações necessárias sobre a arquitetura da ferramenta (Figura 50), compreender

no nível teórico como é a organização de arquivos do Oryx e identificar os arquivos

chaves para a construção de plugins. Essas informações descobertas a partir do

estudo dos documentos identificados na pesquisa serão descritas a seguir, de forma

resumida.

http://translate.google.com.br/

http://www.onlinedoctranslator.com/translator.html

89

Figura 50 – Arquitetura da ferramenta Oryx [Daniel07]

A ferramenta tem um projeto típico “Cliente-Servidor” onde mantém a codificação

principal sendo processada no lado do servidor, enquanto parte da codificação

permanece no lado cliente. A codificação desenvolvida para o lado servidor não foi

estudada neste trabalho, já que não é necessária para o desenvolvimento de plugins.

A estrutura da ferramenta foi desenvolvida para ser capaz de interpretar arquivos que

são compostos pela definição de elementos de modelagem e suas regras de

interação. O desenvolvimento destes arquivos independe da complexidade do núcleo

da ferramenta Oryx, o que demonstra a modularidade dos componentes “núcleo de

sistema e plugin”.

O foco do trabalho será na parte do cliente, mais especificamente no

desenvolvimento dos “Stencils”. Um stencil é a descrição de um objeto gráfico e suas

regras, que definem como esse objeto irá se relacionar com os outros no diagrama.

Um conjunto de stencils pode ser carregado no editor Oryx para construir modelos

[Peters07]. No entanto os stencils não serão carregados em separado, eles serão

agrupados em um mesmo arquivo formando um stencil set.

Uma importante característica do stencil é que ele não define a representação

gráfica dos elementos, mas somente as propriedades referentes ao comportamento do

objeto no diagrama. O desenvolvimento da parte gráfica dos componentes será

abordado mais a frente.

90

Os stencils set são armazenados em arquivos do tipo JSON (JavaScript Object

Notation - http://JSON.org/). O arquivo JSON que define um plugin para o Oryx é

composto por um cabeçalho, conjunto de stencils e conjunto de regras.

A Figura 51 exemplifica o código de um stencil set. Esse fragmento é composto

por um título, que nomeia o stencil set, um namespace que é um identificador único,

uma descrição, e o conjunto de stencils e regras.

Figura 51 – Fragmento de um stencil set

No interior da tag de stencils são inseridas as definições dos elementos de

modelagem. Não há restrição de numero de stencils a serem inseridos no conjunto. A

Figura 52 exemplifica o código de um stencil, presente dentro da tag “Stencils”: [ ], ele

inicia e termina entre as chaves ({ }).

O stencil é formado pelos atributos: type, que define qual é o tipo de elemento do

stencil, por exemplo, um nó ou relacionamento; id, que é um identificador único para o

elemento; title, que nomeia o objeto no diagrama; description, que define uma

descrição do elemento que será mostrada no gráfico; view, que é o path para o

arquivo gráfico que será desenhado no diagrama; icon, que é o path para o arquivo

gráfico que possuirá o pequeno ícone que representará o elemento; roles, que

especificam regras definidas que podem ser aplicadas a elementos específicos;

properties, que oferecem ao usuário informações e campos para serem preenchidos

referentes a propriedades do elemento. Não existe restrição ao numero de

propriedades inseridas no stencil.

91

Figura 52 – Fragmento de um stencil

As propriedades de um stencil podem conter diversos parâmetros. Cada

propriedade descrita irá gerar um campo no gráfico seja para permitir a inserção de

texto, seleção de opção ou conteúdo pré-definido. A Figura 53 exemplifica o código

das properties contendo apenas uma propriedade e seus parâmetros, limitados pelos

“{ }”.

Figura 53 – Fragmento das propriedades de um stencil

Por fim, as rules definem um conjunto de regras referente a relacionamentos

entre os elementos no diagrama. A Figura 54 mostra um fragmento de código

contendo três tipos de regras: connectionRules, cardinalityRules e containmentRules.

Ainda existem outros tipos de regras, porém somente essas três serão detalhadas já

que os stencils set produzidos neste trabalho as utilizam predominantemente.

92

Figura 54 – Fragmento de código das regras de um stencil set

O tipo de regra “connectionRules” consiste em definir quais elementos podem

ser interligados a partir de um relacionamento, ou seja, mais especificamente é a

configuração de um determinado objeto do tipo relacionamento, onde define-se os

elementos em que ele pode interligar.

A Figura 55 apresenta um fragmento de código que define regras para

relacionamento entre elementos. Neste exemplo, o elemento de relacionamento

“controlflow” está configurado com duas regras de conexão. A primeira define que

pode existir uma conexão saindo do elemento “activitySource” em direção ao elemento

“conditionTarget”. A segunda regra define a conexão saindo do elemento

“conditionSource” para o elemento “activityTarget”.

Figura 55 – Fragmento de código das regras de conexão

O tipo de regra “cardinalityRules” define o número de conexões de entrada/saída

que um elemento pode possuir. A Figura 56 exemplifica um fragmento contendo duas

regras de cardinalidade. Essa regra não está definida para um elemento específico

como descrito nas regras de conexão, exemplificada anteriormente, mas define um

papel (role) que deve ser configurado no stencil para adquirir a regra. No exemplo,

dois papéis são definidos: inputcondition e outputcondition. O papel inputcondition

define que o objeto o qual está configurado para obedecer esta regra deverá

obrigatoriamente ter um elemento de relacionamento “entrando”. O papel

outputcondition também especifica que é obrigatório um relacionamento de saída do

elemento.

93

Figura 56 – Fragmento de código de regras de cardinalidade

O tipo de regra “containmentRules” define quais elementos podem estar contidos

dentro do elemento configurado. Esta regra é mais adequada às raias (pools) onde os

elementos são inseridos. A Figura 57 exemplifica um fragmento de código contendo

regras de conteúdo. Esta regra cria uma role “diagram” que contém os elementos que

possuem o id “activity”, “condition” e as regras definidas de conexão definidas

anteriormente “inputcondition” e “outputcondition”.

Figura 57 – Fragmento de código de regras de conteúdo

Uma vez definido o stencil set, todas as informações e regras sobre os

elementos estarão disponíveis para interpretação do Oryx. O próximo passo é definir

os elementos gráficos que representarão os stencils definidos no stencil set. Dois

elementos gráficos são necessários para representação no modelo: o ícone e o objeto

gráfico.

O ícone é uma versão reduzida do objeto gráfico que a ferramenta disponibiliza

em um painel na interface da ferramenta, para que o usuário selecione entre as

opções, e o respectivo elemento seja incluído no diagrama. Os ícones devem estar no

formato de arquivo PNG com dimensões de 16 x 16 pixels. Essas figuras podem ser

facilmente desenvolvidas utilizando o MsPaint, no Windows.

O elemento gráfico que representa o objeto que será desenhado no diagrama é

definido a partir do formato SVG (Scalable Vetor Graphics).

94

Neste formato os desenhos são criados a partir de códigos do padrão SVG.

Existem vários comandos que podem ser utilizados para gerar diversos tipos de

grafos. Esses comandos podem ser estudados no site do W3C

(http://www.w3.org/Graphics/SVG/). Alguns tipos de arquivo SVG são oferecidos, por

exemplo, é possível criar um arquivo SVG relacionado a figuras existentes, como se

fosse uma ancora para o outro arquivo gráfico, no entanto, este tipo de arquivo SVG

não funciona corretamente no Oryx, sendo recomendado apenas o uso dos arquivos

SVG descritivos, em que as imagens são geradas a partir da especificação de código

na linguagem oferecida pelo padrão.

Além da codificação do padrão SVG, devem ser inseridos no arquivo outras tags

que serão interpretadas especificamente pelo Oryx. Por exemplo, devem ser definidos

no arquivo SVG a localização do campo de texto, cor, tamanho da fonte, entre outros

elementos, como os Oryx Magnets, que definem pontos no desenho onde os

relacionamentos podem se ligar ao objeto.

A Figura 58 demonstra um exemplo de codificação de arquivo SVG contendo

tags do Oryx. Neste exemplo, nota-se que o cabeçalho possui a definição do

namespace do Oryx, necessário para reconhecer as tags:

“xmlns:Oryx="http://www.b3mn.org/Oryx".

A tag <Oryx:magnets> demarca o inicio da configuração dos pontos que estarão

disponíveis no objeto para a ligação de relacionamentos. Cada ponto é definido pela

sua coordenada x e y.

Entre as tags <g> </g> estão configurados os elementos que definirão o visual

gráfico do elemento. A tag <radialGradient> </radialGradient> define um fundo para

ser utilizado no objeto.

Esta imagem é composta por uma reta <rect> que está ancorada ao elemento

(Oryx:anchors) pelo topo, esquerda e direita, o que significa que ao ampliar o objeto no

diagrama, a reta crescerá para estas direções, exceto para baixo. O mesmo ocorre

para o círculo <circle> que também compõem a imagem. Na tag <text> é definido o

campo para inserção de texto no elemento, incluindo o tamanho da fonte, sua

coordenada x, y e seu alinhamento (align) em relação ao objeto. O texto é encaixado

na reta que é desenhada no gráfico (fittoelem).

http://www.w3.org/Graphics/SVG/

95

Figura 58 – Exemplo de código de imagem SVG

Em suma, para desenvolver o plugin desejado, é necessário definir o stencil set

contendo todos os elementos que se deseja modelar, suas regras, seus ícones e

arquivos SVG referentes a cada um dos elementos. Esse conhecimento é suficiente

para finalizar a Fase 2 (Tabela 16) do processo de engenharia reversa.

Na próxima subseção, são descritos os procedimentos realizados na terceira

fase do processo de engenharia reversa onde foram estudados os conceitos

descobertos na segunda fase diretamente na codificação da ferramenta.


Na terceira fase do processo de engenharia reversa, o alvo de estudo é a

codificação e o ambiente de programação do Oryx. Grande parte do código já foi

estudada nos documentos, na segunda fase, porém neste momento todos os

conceitos serão revistos de forma prática nos arquivos do projeto do Oryx.

96

Entre o conjunto de pastas e arquivos do projeto do Oryx, estão codificações

referentes ao lado servidor e cliente da aplicação. Como dito antes, o estudo realizado

tem foco no lado do cliente. Os arquivos dos stencils, os quais serão de fato editados,

estão presentes no seguinte path: “Oryx/editor/data/stencilsets” (Figura 59).

Figura 59 – Infraestrutura de pastas do ambiente de desenvolvimento do Oryx

Abrindo a pasta stencilset (Figura 60) é possível encontrar um grande conjunto

de stencils presentes nas subpastas e também o arquivo “stencilsets.json”. Neste

arquivo são registrados todos os stencils sets presentes na pasta stencilsets. Portanto

é necessário registrar o novo stencil neste arquivo. A Figura 61 exemplifica o registro

de um stencil set no arquivo stencilsets.json. As informações que compõem o registro

são título do stencil (title), namespace, descrição (description), path onde está o

arquivo JSON do stencilset que se deseja registrar (uri), path do ícone para

representar o stencil set (icon_url) e a opção que torna o stencil set visível na

ferramenta ou não (visible).

97

Figura 60 – Detalhamento da pasta stencilsets

Figura 61 – Exemplo de registro de stencil set

Ao entrar em uma pasta de um stencil set, identifica-se uma estrutura comum a

todos as pastas dos stencils set que é composta por uma subpasta dedicada aos

ícones dos elementos (icons), uma subpasta dedicada aos arquivos SVG que

representam os elementos no modelo (view) (Figura 62), o arquivo JSON que contem

todas as configurações dos stencils, suas regras, e opcionalmente um arquivo do tipo

PNG contendo o ícone que representa o stencil set.

98

Figura 62 – Estrutura de pastas do stencil set “petrinets”

É justamente essa estrutura que foi implementada neste projeto a criação dos

novos stencils set. Todo o conhecimento sobre a infraestrutura da ferramenta Oryx

necessário para a continuação do projeto foi identificado, finalizando a atividade de

engenharia reversa.

A partir do conhecimento extraído com a aplicação da engenharia reversa, foi

possível modelar um diagrama conceitual, representado na Figura 63. Neste diagrama

estão contidos os elementos básicos de um stencil set, conforme apresentado nos

capítulos anteriores. O stencil set pode conter zero ou mais stencils e rules. Um stencil

contém zero ou mais properties e roles. Uma rule pode ser de três tipos:

ConnectionRules, CardinalityRules e ContainmentRules. Cada rule define uma role

que pode ser referenciada pelo stencil que passa a respeitar a regra.

Figura 63 – Diagrama conceitual contendo elementos básicos de um stencil set

Com esse conhecimento adquirido, é possível descrever uma lista de requisitos

mais detalhada, por exemplo, para poder implementar na ferramenta a linguagem do

framework i*, o check list de requisitos poderia ser:

99

Criar plugin contendo i*

o Criar elementos SVG com formato gráfico compatível ao i*

o Criar ícones para cada elemento SVG

o Implementar o arquivo stencil set

Criar stencil para cada elemento do i*

Criar regras de acordo com as regras do i*

Aplicar as regras aos elementos de acordo com as regras do i*

Utilizando os novos conhecimentos que possibilitaram visualizar as atividades

necessárias para implementar as novas demandas na ferramenta Oryx (i* alinhado à

BPMN), é possível aplicar a reengenharia reversa para customizar a ferramenta,

inserindo novo código, alterando e reutilizando a codificação existente. A próxima

seção descreve como foram implementados os novos requisitos e quais as novas

alterações incluídas após gerar a versão 1.0 da ferramenta.

4.2.2. Reengenharia de software

Esta seção apresenta como foi executado o processo de reengenharia da

ferramenta Oryx. A estrutura de pastas da ferramenta é detalhada, mostrando onde se

encontram as codificações no ambiente de desenvolvimento, além disso, são

apresentados diagramas que demonstram as diferentes definições do Oryx e como os

seus arquivos se relacionam.

Este capítulo possui um enfoque na apresentação dos conceitos e infraestrutura

do ambiente e seus arquivos. Na fase de reengenharia, o objetivo era desenvolver os

plugins do i* e da BPMN de forma a permitir a modelagem conjunta de seus

elementos. No entanto, o código do Oryx disponibilizado para download já possui uma

implementação do BPMN 2.0, permitindo o seu reuso.

Retornando ao assunto da codificação, conforme dito nos estudos anteriores é

possível definir as atividades necessárias para alcançar os objetivos desta fase. O

reuso do stencil set BPMN foi muito útil, eliminando completamente o trabalho de

definição dos elementos dessa notação. Então foi apenas necessário incluir os novos

stencils do i* e suas regras, além de definir os elementos gráficos e realizar as

alterações necessárias para adaptar o i* ao stencil set do BPMN.

O stencil set BPMN + i* foi projetado conforme o esquema apresentado na

Figura 64. A maior dificuldade encontrada na implementação foi a ausência de

ferramenta de debug, já que não há como acompanhar a execução do código de um

100

stencil set, e um pequeno erro de uma virgula ausente já faz com que a ferramenta

não funcione corretamente.

Figura 64 – Esquema de formação do Stencil set BPMN + i*

Diversas vezes foi necessário apagar grande parte da codificação desenvolvida

e reinserir novamente por partes e realizando testes de execução em paralelo para

garantir que nada estivesse faltando. Neste tipo de programação, onde se trabalha

com um arquivo simples de tags e sem um sistema de debug, não é seguro aplicar um

grande número de modificações e posteriormente realizar testes, já que um erro

inserido em algum ponto do código (mesmo que sem querer) demandará esforços

maiores para ser rastreado e identificado.

Os sintomas que ocorrem por problemas de codificação são os mesmos para

qualquer problema inserido no stencil set. O sistema não apresenta os elementos do

stencil set no ambiente Oryx ou a ferramenta simplesmente não carrega integralmente,

independente de carregar os elementos do stencil set.

Após a finalização do código, os stencils sofreram novas alterações para

oferecer ao usuário a possibilidade de trabalhar com as notações separadamente, por

exemplo, modelar um diagrama SD, SR ou utilizar unicamente a BPMN, ou ainda, na

parte de integração das linguagens, incluir as visões geradas a partir da união da

BPMN com SD ou da BPMN com SR.

Para implementar esses alterações, foram extraídos todos os elementos do

stencil set implementado até o momento. Cada diagrama (i* SD, i* SR e BPMN) foi

Stencil set

+titulo+namespace+description

Stencils BPMN

+properties+roles

Regras BPMN

+connectionRules+cardinalityRules+containmentRules

Regras i*


Stencils i*

+properties+roles

101

transformado em um único stencil set e foram criadas “perspectivas” na ferramenta

para que o usuário possa selecionar e facilmente trocar entre os diferentes plugins.

A separação dos novos stencil sets não trazem nenhuma novidade ao trabalho,

a não ser pela mudança do esquema de implementação (Figura 64), no entanto, a

criação de perspectivas demandou alterações em um arquivo que define as

perspectivas na ferramenta e na estrutura de pastas.

O Oryx possui um arquivo chamado extension.json (Figura 65), onde são

configurados stencil sets que estendem a capacidade de outros stencil set

considerados como principais. Estas extensões são aplicadas ao modelo quando o

usuário solicita a inclusão do plugin manualmente ou quando seleciona a perspectiva

predefinida que contém plugins de extensão.

Figura 65 – Pasta “extensions” contendo o arquivo “extensions.json”

Esta estrutura de extensões foi utilizada como estratégia para a implementação

das visões. Um stencil set genérico foi desenvolvido contendo o stencil básico do

diagrama e o conjunto de regras genéricas que são usadas pelos stencils set que irão

estendê-lo. Esse stencil set principal é iniciado na ferramenta, e as perspectivas

definem os elementos que vão ser apresentados neste stencil set principal. Portanto

cada stencil set implementado a partir da separação mencionada anteriormente (i* SD,

i* SR e BPMN) foi configurado como uma extensão. A Figura 66 ilustra o esquema de

formação do stencil set principal i*BPMN e seu relacionamento com suas extensões.

102

Figura 66 – Esquema de formação do stencil set i*BPMN a partir de extensões

O arquivo extension.json é formado pelo registro do conjunto de stencils set que

são utilizados como extensão e o registro das perspectivas. O registro de um stencil

set é formado por titulo, namespace, descrição, definição (path para o stencil set da

extensão) e o campo de extensão, onde se define o path em que se encontra o stencil

set a ser estendido. O registro de uma perspectiva é composto por titulo, namespace,

descrição, stencil set que vai ser estendido, o campo onde se registra quais stencils

set serão incluídos na perspectiva e outro campo onde se registra quais stencils set

serão removidos da perspectiva (Figura 67).

i* SD Stencil set

+title+namespace+description

i* SR Stencil set


i* SR Rules


BPMN Stencil set


i* SD Stencils

+properties+rules

i* SD Rules


Stencil set i*BPMN

+title+namespace+description+connectionRules+cardinalityRules+containmentRules

BPMN Rules


i* SR Stencils

+properties+rules

BPMN Stencils

+properties+rules

extends

extends

extends

103

Figura 67 – Exemplo do arquivo extension.json

Com essas alterações também se finaliza a fase de implementação dos plugins

realizada através da reengenharia de software. Uma vez que a codificação foi

desenvolvida, é natural que a próxima etapa seja referente aos testes e correções. A

próxima seção apresenta como foram feitos os testes partindo de um roteiro

predefinido e apresenta alguns exemplos do que foi realizado.

4.3.Testes

A codificação desenvolvida neste trabalho é um conjunto de especificações que

são interpretadas pelo núcleo da ferramenta Oryx e geram um resultado gráfico em

seu ambiente de modelagem. Para testar a codificação desenvolvida, foi escolhido o

método de testes assistido, baseado em um roteiro onde são pré-registrados os

resultados esperados por cada funcionalidade a ser testada. Uma vez que os

resultados esperados são atingidos através do uso da funcionalidade, a função é

considerada satisfatória. Caso contrário, é identificado o defeito que deve ser

consertado e novamente testado ou simplesmente registrada a existência do

problema, caso seja avaliado e justificado que o código não deve ser alterado neste

caso.

Os testes foram projetados a partir de roteiros onde se definem especificações

que devem ser integralmente cumpridas ao utilizar a função na ferramenta. Os

elementos alvo dos testes foram cada objeto e cada regra (de objetos) que compõem

a notação definida neste trabalho (exceto os elementos BPMN reutilizados). Aqui

104

descreveremos apenas o roteiro de testes aplicados e alguns exemplos de testes, os

resultados mais detalhados encontram-se em [Sousa&Leite12].

Como um plugin é formado por stencils e regras, basicamente foram estes os

elementos testados. A especificação dos elementos é repassada para a codificação e

o resultado esperado é o elemento gráfico e regras de acordo com o esperado.

Para cada stencil foram testados:

No caso de ser um nó, o elemento gráfico esperado, localização do texto no

objeto, efeito de ampliação do objeto, regras específicas.

No caso de ser um relacionamento, o elemento gráfico esperado,

localização do texto no objeto, efeito de ampliação do objeto, regras

específicas e regras de conexão.

Nem todos os testes são aplicáveis a todos os stencils e regras, sendo neste

caso, marcado como não aplicável. A sintaxe geral do programa é automaticamente

verificada pelo Oryx, que somente abre o stencil set para modelagem se todas as

regras de sintaxe estiverem corretas.

Os testes foram divididos em dois tipos, chamados de Teste gráfico e Teste de

regras, sendo que este último ainda possui variações, já que as regras foram testadas

separadamente para cada situação esperada por um objeto em relação aos outros

elementos que fazem parte do domínio da regra.

O objetivo do teste gráfico (Tabela 17) é verificar se o elemento está de acordo

com as especificações esperadas. A verificação de aceite do teste é visual e

comparativa. A especificação padrão dos elementos é composta dos seguintes

campos: Elemento – nome do elemento na ferramenta; Formato – formato gráfico do

elemento; Cor – cor do corpo do elemento; Texto – Configuração do texto em relação

ao objeto; O campo Resultado, mostra a figura que é resultante do código que foi

implementado. Esta figura deverá ser comparada com a especificação para verificar se

o objeto obedece a todas as especificações, o que caracteriza um teste com sucesso.

Uma vez que o elemento passou no teste, o campo “Teste” é preenchido com “OK”.

105

Tabela 17 – Teste gráfico

Teste gráfico

Especificação Resultado

Elemento:

Formato:

Cor:

Texto:

Teste:

O teste de regras do tipo Containment Rules (Tabela 18) possuem os seguintes

parâmetros: elemento – nome do elemento o qual a regra está atribuída; conteúdo –

os elementos que podem encontrar-se modelados no corpo do elemento que deve

obedecer a regra.

Tabela 18 – Teste de regras do tipo Containment Rules

Teste de regras (Containment Rules)


Elemento:

Conteúdo:

Teste:

O Teste de regras do tipo Cardinality Rules (Tabela 19) possuem os seguintes

parâmetros: elemento – nome do elemento o qual a regra está atribuída; elemento de

entrada – nome do relacionamento que chega ao elemento; Card. Entrada –

Cardinalidade do elemento de entrada; Elemento de saída – nome do relacionamento

que sai do elemento; Card. Saída – Cardinalidade do elemento de saída.

Tabela 19 – Teste de regras do tipo Cardinality Rules

Teste de regras (Cardinality Rules)


Elemento:

Elemento de entrada

Card. Entrada:

Elemento de saída:

Card. Saída:

Teste:

106

O teste de regras do tipo Connection Rules (Tabela 20) possui os seguintes

parâmetros: Elemento – nome do relacionamento que será avaliado; Elem. Inicial –

nome do elemento que deve estar na ponta inicial do relacionamento; Elem. Final –

nome do elemento que deve estar na ponta final do relacionamento.

Tabela 20 - Teste de regras do tipo Connection Rules

Teste de regras (Connection Rules)


Elemento:

Elem. Inicial:

Elem. Final:

Teste:

Testes de “negação” das regras não serão aplicados já que o Oryx

automaticamente impede a execução de regras que não estão explicitas. Por exemplo,

se definir somente uma regra que relaciona o objeto A ao objeto B nesta direção, a

partir do relacionamento X, não é necessário testar a conexão para a direção inversa

porque ela não acontecerá, já que não está definida.

A Tabela 21 e Tabela 22 apresentam dois exemplos de teste gráfico, neste caso,

para elementos do i*. A tabela é dividida em duas partes, na esquerda, encontram-se

as especificações do elemento, do lado direito, o elemento modelado. O teste consiste

em uma avaliação visual do elemento que, uma vez modelado, apenas deve

corresponder às especificações. Caso corresponda, o teste é concluído de forma

positiva.

Tabela 21 - Teste gráfico para o elemento Agent (Diagrama SD)

Teste gráfico


Elemento: Agent

Formato: circular

Cor: cinza

Texto: centralizado

Teste: OK

107

Tabela 22 – Teste gráfico para o elemento meta (Diagrama SD)

Teste gráfico


Elemento: Meta

Formato: oval

Cor: verde

Texto: centralizado

Teste: OK

A Tabela 23 apresenta o teste para a regra Containment Rule. A configuração

desta regra permite que elementos sejam modelados dentro de outros elementos, o

qual se torna seu limite de mobilidade. Por exemplo, podemos citar o próprio diagrama

principal que recebe os elementos de modelagem. O diagrama deve estar configurado

nesta regra para todos os elementos de linguagem. No teste apresentado, foi testado

o elemento AgentLane, que é uma Lane que representa um papel/agente. De acordo

com a especificação da tabela, os elementos que devem ser modelados dentro da

lane estão descritos no campo “Conteúdo”. Os elementos são: Agent, Meta, Meta-

flexível, Task, Resource, Critical Mark, Open Mark, Dependency. O teste consiste em

inserir estes elementos na lane. Uma vez que a ferramenta permite o desenho dos

elementos esperados, o teste foi realizado com sucesso.

Observando o resultado do teste, verifica-se que todos os elementos esperados

foram modelados corretamente no interior da lane, validando o resultado.

Tabela 23 – Teste da regra Containment Rule para o elemento AgentLane (Diagrama SD)

Teste de regras (Containment Rules)


Elemento: AgentLane

Conteúdo: Agent, Meta, Meta-flexível, Task, Resource, Critical Mark, Open Mark, Dependency.

Teste: OK

108

A Tabela 24 apresenta o teste para a regra Cardinality Rule. Esta regra define

quantos relacionamentos de um dado tipo um elemento pode ter como entrada/saída.

No exemplo, o relacionamento de fluxo de sequência foi testado para os eventos do

tipo inicial. A cardinalidade de um evento inicial é zero, uma vez que só o processo

inicia-se com ele. Portanto, para este teste, tenta-se ligar um relacionamento em

direção ao evento inicial, e espera-se que a ferramenta recuse a ligação, conforme

mostra o resultado do teste. A ferramenta apresenta sinais em vermelho

demonstrando que a ligação não é permitida. Isso demonstra que a restrição da regra

está funcionando conforme o esperado.

Tabela 24 - Teste da regra Cardinality Rule para os elementos do tipo Evento inicial

Teste de regras (Cardinality Rules)


Elemento: Regra genérica (Eventos iniciais)

Elemento de entrada: SequenceFlow

Card. Entrada: 0

Elemento de saída: N/A

Card. Saída: N/A

Teste: OK

A Tabela 25 apresenta o teste para a regra Connection Rule. Esta regra define

quais objetos podem se relacionar. No exemplo, o teste é para o relacionamento de

dependência em um diagrama SD. A especificação apresenta o elemento inicial e o

elemento final, ou seja, também define a direção do relacionamento. O resultado deve

apresentar os elementos relacionados, seguindo a direção correta no relacionamento.

109

Tabela 25 - Teste da regra Connection Rule para os elementos que utilizam o relacionamento

Dependency (Diagrama SD)

Teste de regras (Connection Rules)


Elemento: Dependecy

Elem. Inicial: Agent

Elem. Final: Meta


Elem. Final: Meta-flexível


Elem. Final: Task


Elem. Final: Resource

Elem. Inicial: Meta

Elem. Final: Agent

Elem. Inicial: Meta-flexível

Elem. Final: Agent

Elem. Inicial: Task

Elem. Final: Agent

Elem. Inicial: Resource

Elem. Final: Agent

Teste: OK

Esta seção apresentou o roteiro de testes que foram aplicados na ferramenta e

exemplificou cada tipo de teste aplicado para as diferentes regras que os elementos

podem receber. Os testes completos, incluindo a listagem de erros presentes na

ferramenta (e não nos plugins desenvolvidos), as dificuldades encontradas e o manual

da ferramenta podem ser vistos em [Sousa&Leite12]. Os resultados dos testes foram

satisfatórios resultando na possibilidade de uso integral das linguagens como extensão

da ferramenta Oryx. A próxima seção apresenta o estudo de caso aplicado à proposta

deste trabalho.

110

5 Exemplo de aplicação

Este capítulo apresenta um exemplo de uso da linguagem proposta como forma

de validação. Através da implementação da linguagem utilizando o potencial de

extensão da ferramenta Oryx é possível demonstrar o desenvolvimento dos modelos e

a integração das linguagens.

Para realizar este teste, utilizamos um modelo de processo de negócio em

BPMN e um modelo SR, ambos desenvolvidos por terceiros. Apesar da notação

proposta neste trabalho não reutilizar integralmente todos os recursos do i* e da

BPMN, principalmente no que tange a regras e relacionamentos, queremos

demonstrar que partindo desses modelos, podemos introduzir as

alterações/adaptações necessárias para construir um terceiro modelo que integra os

dois primeiros, introduzindo relacionamentos que permitem a rastreabilidade com

semântica de causa (why) e efeito (how) referenciando respectivamente a modelagem

de objetivos e processes.

O modelo de processo utilizado foi extraído de [Diirr10] e encontra-se modelado

utilizando a notação do framework ARIS, portanto, foi necessário o trabalho de

tradução do modelo de processos para a notação BPMN. Com o processo modelado

em BPMN, solicitamos a um aluno de doutorado da PUC-Rio que projetasse o modelo

SR do processo, tendo como fonte de informação o modelo em BPMN e uma

descrição do processo. Uma vez que o modelo foi finalizado, apresentamos a

linguagem de integração e solicitamos que a utilizasse, criando um Diagrama

Integrado. Ao concluir o Diagrama Integrado, apresentamos nosso método de uso de

indicadores e solicitamos que também fossem projetados indicadores para os

objetivos que haviam sido incluídos no modelo SR, o que possibilita a verificação de

alinhamento entre os modelos. Posteriormente realizamos análises no Diagrama

Integrado e extraímos informações de interesse.

Durante a validação, nosso papel foi apenas de instruir no uso da linguagem, da

ferramenta e em dúvidas pontuais nas atividades solicitadas. As subseções seguintes

detalham cada procedimento realizado nesta validação.

111

5.1.Modelo de processo

O modelo de processo extraído de [Diirr10] foi modelado utilizando diagramas

EPC e FAD. Primeiramente desenvolvemos em BPMN o fluxo de atividades, eventos e

operadores lógicos contidos no diagrama EPC e, posteriormente, completamos o

modelo com os elementos de detalhamento do fluxo de informações presentes nos

modelos FAD.

A descrição de alto nível do processo também foi extraída de [Diirr10], conforme

transcrito a seguir:

“Neste processo são analisadas propostas de crédito, as quais podem ser

aprovadas ou rejeitadas. Quando uma proposta de crédito é recebida, o cadastro do

cliente é checado e o sistema verifica se o limite de crédito do cliente é suficiente para

a concessão do crédito proposto. Se o limite for aprovado, então o sistema calcula as

taxas do contrato para gerar uma proposta de contrato. Esta proposta de contrato é

encaminhada a um analista de crédito que identifica necessidades de ajustes e o nível

do risco inerente ao empréstimo. Se o contrato for aceitável, o cliente é contatado para

avaliar o contrato. Uma vez que o contrato é aprovado, ele será ratificado. Se o

contrato não for aprovado, ele será cancelado.”

O modelo resultante da tradução para a notação BPMN pode ser visto na Figura

68.

112

Figura 68 – Processo “Analisar Pedido de Crédito” [adaptação de [Diirr10]]

113

5.2.Modelo SR

O modelo SR foi desenvolvido por um aluno de doutorado da PUC-Rio a partir

da leitura do modelo BPMN e sua descrição (considere uma abordagem botton-up).

Nenhuma informação sobre a integração posterior dos modelos foi repassada na

atividade da construção do modelo SR, logo, ficou sob a responsabilidade do aluno

toda a interpretação do modelo de processo de negócio e o desenvolvimento do

modelo SR. O modelo resultante é apresentado na Figura 69.

Observe que existe a naturalidade de interpretar durante a tradução do modelo

BPMN para o modelo SR, os papéis executores como atores, raias como pools de

agentes e a dependência de artefatos/informações que são repassadas (handoff) de

uma raia para outra no modelo BPMN.

Figura 69 – Modelo SR desenvolvido a partir do processo “Analisar Pedido de Crédito”

114

Cabe salientar que não temos o objetivo de criticar o modelo SR em relação à

sua completude porque não necessitamos de um modelo plenamente detalhado.

Nossos objetivos se restringem a integrar os modelos e identificar os fluxos/atividades

na camada de processos que correspondem às tarefas/objetivos da camada de

objetivos, visando tornar explícita a rastreabilidade entre os modelos.

5.3.Integração dos modelos

Neste momento apresentamos noções gerais referentes à integração das

linguagens, o método e a notação de modelagem do Diagrama Integrado. Solicitamos

ao aluno que modelasse o Diagrama Integrado partindo do modelo BPMN e de seu

modelo i*.

Como uma forma de minimizar o esforço do aluno, solicitamos que

desconsiderasse o fluxo de informações/artefatos do modelo BPMN para simplificar o

modelo e facilitar a visualização e modelagem dos agrupamentos de atividades

porventura necessários. Os eventos também não foram descritos, para reduzir o

tamanho do modelo.

A Figura 70 apresenta o Diagrama Integrado com o desenho modificado para

raias horizontais descritas à esquerda, e os elementos de modelagem de objetivos à

direita.

Figura 70 – Resultado da integração

Ao integrar os modelos alguns elementos que faziam parte do modelo i* foram

eliminados. Estes elementos não deixaram de ser representados, na verdade eles

foram ainda mais detalhados no modelo BPMN. Um dos elementos que foram

excluídos são as decomposições das tarefas. No alto nível, estes elementos poderiam

115

representar processos complexos, mas partindo do ponto de vista dos papéis e suas

responsabilidades, os elementos folha que decompõem uma tarefa tendem a serem

atividades atômicas e possuirão elementos correspondentes no diagrama BPMN.

Algumas tarefas poderão ser mais abstratas, sendo detalhadas por um pequeno fluxo

dentro do processo (agrupamento).

Um dos maiores ganhos nesta representação é a definição da temporalidade na

execução das tarefas decompostas. Além disso, outros detalhamentos serão

possíveis, tais como a representação de insumos necessários para a execução das

atividades e os seus produtos, descrições textuais mais elaboradas, representação de

outros conceitos do negócio e regras de execução dos processos, definidas por

operadores lógicos e eventos.

Alguns relacionamentos meios-fim de objetivos (meta e meta-flexível) com

tarefas também foram eliminados, e substituídos por relacionamentos meios-fim com

agrupamentos de atividades que são executados para satisfazê-los. O agrupamento

demonstra o esforço realizado no processo para satisfazer os objetivos locais.

Outro elemento que pode ser eliminado são os recursos, automaticamente

representados na troca de informações/artefatos entre os atores e na entrada e saída

de atividades.

Partindo do ponto de vista do ator Atendente, seus objetivos são “Resultado da

proposta seja comunicado” e “Condições do contrato sejam satisfeitas”. Para

satisfazer o objetivo “Resultado da proposta seja comunicado” é necessário que a

tarefa “Enviar resultado da proposta” seja satisfeita. O processo já possui atividade

semelhante com o nome de “Comunicar proposta não aprovada” que substituiu a

tarefa sendo relacionada diretamente com o objetivo (observe que a possível tarefa de

“Comunicar proposta aprovada” não faz parte do escopo deste processo). O objetivo

“Condições do contrato sejam satisfeitas” é satisfeito através da tarefa “Verificar

aceitação do contrato”, que corresponde no processo a um agrupamento que promove

a atividade de avaliar com o cliente o contrato, podendo resultar na provação ou

reprovação. Para atingir esse objetivo o Atendente depende do Cliente. O Cliente, por

sua vez, depende do Atendente para receber a comunicação de não aprovação de sua

proposta. Observe que o relacionamento de dependência pode ser aplicado tanto no

modelo de objetivos como no modelo de processo.

Partindo do ponto de vista do ator Crédito Direto (trata-se de um sistema), o seu

objetivo principal “Proposta de contrato seja gerada” é satisfeito através da tarefa

“Gerar proposta de contrato” que, por sua vez, é decomposta no objetivo “Dados do

cliente sejam mantidos” e tarefas “Comprometer limite de crédito”, “Calcular taxas do

contrato” e “Gerar proposta”. O objetivo “Dados do cliente sejam mantidos” pode ser

116

alcançado ao executar a tarefa “Atualizar dados do cliente” ou “Cadastrar dados do

cliente”. As tarefas que decompõem a tarefa “Gerar proposta de contrato” encontram-

se em mais detalhes no modelo de processos que possui um fluxo específico

agrupado que gera a proposta de contrato. O mesmo ocorre com as tarefas “meio” do

objetivo “Dados do cliente sejam mantidos”. A execução de uma ou outra atividade

respectiva às tarefas no modelo i* fica definida através do operador lógico e eventos

no modelo de processos, demonstrando o ganho de detalhamento a partir da

modelagem do fluxo. A ordem de satisfação dos objetivos (primeiro “Dados do cliente

sejam mantidos” e depois “Proposta de contrato seja gerada”) imposta no modelo i*

através do relacionamento de decomposição da tarefa “Gerar proposta de contrato”

também é expressa no processo conforme demonstra a ligação entre os

agrupamentos.

Partindo do ponto de vista do ator Analista de crédito, a tarefa “Analisar

contrato”, ao ser executada de forma satisfatória, atinge o objetivo “Contrato seja

analisado”. Essa tarefa é decomposta pelas tarefas “Verificar se contrato é de risco”,

“Verificar necessidade de ajuste do contrato” e “Notificar resultado da análise”. A tarefa

“Verificar se contrato é de risco” contribui positivamente para o objetivo “Menor risco

de crédito”. Ao alinhar os modelos ambos os objetivos observou-se que o

agrupamento de atividades de sua raia correspondia a ambos os objetivos do ator.

Após essas alterações foi finalizada a integração, sendo posteriormente aplicada

a proposta do uso de indicadores.

5.4.Modelagem dos indicadores

Neste momento apresentamos nossa proposta de uso de indicadores como um

recurso que permite verificar a capacidade dos modelos em atingir os seus objetivos.

Como primeiro passo, solicitamos ao aluno que projetasse indicadores para os

objetivos que ele definiu anteriormente. Essa atividade de projetar uma forma de medir

os objetivos (que inclui a definição dos elementos que são necessários para aplicar

possíveis cálculos ou gerar indícios suficientes para comprovar que o “esperado” pelo

objetivo pode ser “produzido” pelo processo) auxiliou o aluno a conhecer mais

detalhadamente os objetivos que ele estabeleceu. Após a definição dos indicadores,

atualizamos o Diagrama Integrado (Figura 71).

Os indicadores, seus respectivos objetivos e descrição encontram-se na Tabela

26.

117

Tabela 26 – Detalhamento dos indicadores inseridos no Diagrama Integrado

Objetivo Indicador Descrição

Condições do contrato sejam

verificadas

Produção de documento de verificação do

contrato

Mede o percentual de documentos de verificação de contrato produzidos em relação ao numero de contratos analisados sem restrição. O valor esperado é de 100%. O calculo é: numero de documentos de verificação do contrato/numero de contratos analisados sem restrição.

Resultado da proposta seja comunicado

Emissão de comunicação de

resultado das propostas

Mede o percentual de comunicados emitidos em relação ao numero de propostas canceladas. O valor esperado é de 100%. O calculo é: numero de comunicações emitidas / numero de cancelamentos de proposta.

Proposta de contrato seja

gerada

Produção de propostas de

contratos

Verifica se foi gerada a proposta de contrato respectivo ao cliente que teve o crédito comprometido, de forma a evidenciar que a proposta de contrato foi produzida para o cliente que possui crédito.

Dados do cliente sejam

mantidos

Razão de acessos a cadastros do

cliente

Verifica se houve o acesso ao cadastro do cliente para cada proposta recebida de forma a evidenciar que o cadastro foi analisado. Deve haver um acesso registrado no log do sistema respectivo a cada proposta recebida.

Menor risco de crédito

Coeficiente de risco de crédito

Calcula o coeficiente de risco de crédito baseado em heurísticas que utiliza o checklist como insumo.

Contrato seja analisado

Percentual de contratos

analisados

Mede o percentual de contratos analisados em relação ao número de propostas de contrato geradas. O valor esperado é de 100%. O calculo é: numero de contratos analisados / número de propostas geradas.

Figura 71 – Inclusão de indicadores no diagrama integrado

118

Após a atualização do modelo com os indicadores, foi solicitado ao aluno que

identificasse no processo onde ocorre a produção dos elementos necessários para

medir os indicadores, e então atualizasse novamente o Diagrama Integrado inserindo

os respectivos recursos críticos (Figura 72).

Figura 72 – Diagrama Integrado contemplando indicadores e recursos críticos

Após modificar o diagrama inserindo os recursos críticos, consideramos o teste

de integração finalizado. A próxima subseção apresenta como extrair informações

importantes através da análise do Diagrama Integrado.

5.5. Análise e desenvolvimento de relatórios

Uma vez que os modelos encontram-se prontos, torna-se possível a análise e a

extração de informações sobre os elementos envolvidos. Inicialmente temos o

relacionamento explicito entre os objetivos e seus processos, dos indicadores e seus

elementos necessários, e das atividades com os recursos críticos. A partir disso é

possível identificar, por exemplo, quais objetivos podem ser medidos pelo processo e

quais não podem; os papéis e atividades envolvidos na produção dos recursos

críticos; correlação entre papéis e recursos críticos; e verificação dos processos que

produzem os recursos críticos desejados.

As tabelas Tabela 27, Tabela 28, Tabela 29, Tabela 30 e Tabela 31 consolidam

informações contidas no diagrama. A Tabela 27 contém o resumo dos principais

elementos que se relacionam no processo que são: o próprio processo, seus objetivos,

as atividades que são executadas como esforço para atingir os objetivos, os

indicadores associados aos objetivos e os recursos críticos necessários para gerar os

indicadores.

119

Tabela 27 – Resumo de associação entre principais elementos

Elemento Descrição

Processo Analisar pedido de crédito

Objetivo associado Condições do contrato sejam verificadas

Atividades associadas Verificar condições de contrato com o cliente; Aprovar contrato; Cancelar contrato;

Indicadores associados Produção de documento de verificação do contrato;

Recursos críticos associados Documento de verificação do contrato; Proposta de contrato analisada (sem

restrição);

Objetivo associado Resultado da proposta seja comunicado

Atividades associadas Comunicar proposta não aprovada;

Indicadores associados Emissão de comunicação de resultados das propostas

Recursos críticos associados Proposta de crédito (cancelada); Comunicado de proposta não aprovada;

Objetivo associado Proposta de contrato seja gerada

Atividades associadas

Verificar cadastro do cliente; Atualizar cadastro do cliente; Cadastrar cliente;

Verificar limite de crédito do cliente; Cancelar proposta de crédito; Comprometer

limite de crédito; Calcular taxas do contrato; Determinar taxas de juros a ser

cobrada; Gerar proposta de contrato;

Indicadores associados Produção de propostas de contrato;

Recursos críticos associados Proposta de contrato;

Objetivo associado Dados do cliente sejam mantidos

Atividades associadas Verificar cadastro do cliente; Atualizar cadastro do cliente; Cadastrar cliente;

Indicadores associados Percentual de acessos a cadastros de cliente

Recursos críticos associados Logs de acesso ao cadastro do cliente; Proposta de crédito (recebida);

Objetivo associado Menor risco de crédito

Atividades associadas Analisar contrato; Alterar proposta de crédito; Cancelar contrato de risco;

Comunicar não aprovação de contrato de risco;

Indicadores associados Coeficiente de risco de crédito;

Recursos críticos associados Checklist de análise de contrato;

Objetivo associado Contrato seja analisado

Atividades associadas Analisar contrato; Alterar proposta de crédito; Cancelar contrato de risco;

Comunicar não aprovação de contrato de risco;

Indicadores associados Percentual de contratos analisados;

Recursos críticos associados Proposta de contrato; Proposta de contrato (analisada);

A Tabela 28 apresenta como pode ser realizada a descrição detalhada dos

indicadores. Essas informações podem ser preenchidas na própria ferramenta que

oferece os respectivos campos como atributo dos indicadores. A tabela é composta

por nome e descrição do indicador, objetivo associado, o valor alvo que o indicador

deve apresentar que é esperado pelo objetivo, o responsável por gerir o indicador, os

recursos críticos necessários como fonte de informação, as atividades que geram

120

esses recursos, a unidade de medida do valor produzido pelo indicador, a

periodicidade em que ele é calculado e a fórmula de cálculo.

Tabela 28 – Tabela de descrição de indicadores

Indicador Descrição

Nome Produção de documento de verificação do contrato

Descrição Mede o percentual de documentos de verificação de contrato produzidos em

relação ao numero de contratos analisados sem restrição.

Objetivo Condições do contrato sejam verificadas

Valor alvo O valor esperado é de 100%.

Responsável Atendente

Recursos críticos Documento de verificação do contrato; Proposta de contrato analisada (sem

restrição);

Atividades de origem Verificar condições de contrato com o cliente; Analisar contrato;

Unidade de medida %

Peridiocidade A cada instância do processo em que for gerado um contrato sem restrição.

Fórmula de cálculo O calculo é: numero de documentos de verificação do contrato/numero de

contratos analisados sem restrição.

A Tabela 29 apresenta detalhes sobre os recursos críticos. Além do nome e da

descrição, as informações mais importantes são quais processo e atividades geram

esses recursos, uma vez que essas merecem acompanhamento especial porque

possuem relacionamento direto com a satisfação de objetivos.

Tabela 29 – Tabela de descrição do recurso crítico

Recurso crítico Descrição

Nome Proposta de contrato

Descrição

Representa a proposta de contrato, contendo: código da proposta de crédito; nome

do cliente; CPF; endereço do cliente; telefone do cliente; lista de peças; valor a ser

financiado; número de parcelas; taxa de juros; valor das taxas do contrato; para

cada parcela; data a ser realizado o pagamento; valor a ser pago; juros

correspondentes à multa por atraso; situação.

Processos que geram o

recurso crítico Analisar pedido de crédito

Atividades que geram o

recurso crítico Gerar proposta de contrato

A Tabela 30 lista todos os recursos críticos que não foram identificados nos

processos (baseado na necessidade dos indicadores). Os campos “Processo que

geram o recurso crítico” e “Atividades que geram o recurso crítico” evidenciam a

produção desses elementos em locais distintos ao processo avaliado.

121

No caso do processo utilizado nos nossos testes, verifica-se de acordo com a

Tabela 30 a ausência de três recursos críticos (Documento de verificação do contrato,

Logs de acesso ao cadastro do cliente, Checklist de análise de contrato). Como não

estudamos todo o domínio referente ao negócio que o processo “Analisar pedido de

crédito” compõe, não podemos afirmar se existem outros processos e atividades que

possuem esses recursos críticos.

Neste caso, esses recursos críticos podem ser implementados posteriormente

em uma versão “to-be” deste processo. O impacto da ausência desses elementos é

explicado no capítulo 3.4.

Tabela 30 – Detalhamento de recursos críticos não identificados no processo

Recurso crítico não identificado

Descrição

Nome Documento de verificação do contrato

Processos que geram o recurso crítico -

Atividades que geram o recurso crítico -

Nome Logs de acesso ao cadastro do cliente



Nome Checklist de análise de contrato



A Tabela 31 evidencia a responsabilidade dos papéis em relação à produção

dos recursos críticos ao correlacioná-los. Os atores envolvidos na produção destes

recursos possuem relação mais forte com os objetivos do processo (até mesmo se

esses recursos críticos forem utilizados em outros processos). Essa tabela também

evidencia os recursos que não são produzidos por nenhum ator listado.

Tabela 31 – Correlação entre recursos críticos e papéis responsáveis

Recurso crítico Ator

Nome Atendente Crédito direto Analista de crédito

Documento de verificação do contrato - - -

Proposta de contrato analisada (sem

restrição) - - x

Proposta de crédito (cancelada) - x -

Comunicado de proposta não aprovada x - -

Proposta de contrato - x -

122

Logs de acesso ao cadastro do cliente - - -

Proposta de crédito (recebida) - x -

Checklist de análise de contrato - - -

Proposta de contrato - x -

Proposta de contrato (analisada) - - x

123

6 Conclusão

Este capítulo apresenta a conclusão do trabalho que é composta por um resumo

geral, comparação com trabalhos relacionados e trabalhos futuros.

6.1.Resumo

A modelagem de processos de negócio é um recurso importante para as

organizações porque registra informações desde a camada estratégica até as tarefas

no nível operacional, facilitando o estudo do negócio e posteriores modificações de

melhoria. Ao mesmo tempo, a engenharia de requisitos pode utilizar este artefato

como insumo para estudo do domínio e elicitação de requisitos.

Entretanto, é possível que exista o desalinhamento entre os processos de

negócio e os objetivos organizacionais, o que poderia conduzir à modelagem de um

artefato correto, porém representando um processo que contém deficiências em sua

projeção operacional, proposta como solução às necessidades da organização. O uso

deste artefato como insumo para elicitação de requisitos provavelmente resultará no

desenvolvimento de software também desalinhado aos objetivos organizacionais.

As ferramentas de suporte, linguagens e notações de modelagem de processos

e objetivos deixam lacunas quanto à necessidade de verificar se os processos

condizem com os objetivos, e a maioria não permite registrar a rastreabilidade entre os

modelos, além de existir maior direcionamento das ferramentas em registrar o fluxo de

atividades da visão operacional em relação ao nível estratégico do negócio.

Baseado nisso, propomos a integração de uma linguagem de modelagem de

processos a uma linguagem de modelagem de objetivos. Para isso avaliamos um

conjunto de linguagens de modelagem de processos e objetivos, sendo o resultado

desta seleção a BPMN e o framework i*.

Através do reuso de seus elementos, projetamos uma arquitetura de negócio

integrando os recursos do framework i* na camada de objetivos e os recursos da

BPMN na camada de processos. A integração gerou uma nova linguagem adicionada

de novos elementos e modelos capazes de representar a rastreabilidade entre

objetivos de diferentes níveis de abstração (elementos i*) com as respectivas

atividades (elementos BPMN) que representam o esforço dentro dos processos para

satisfazer os objetivos.

124

Com a introdução da modelagem da intencionalidade dentro do contexto de

processos de negócio, foi adicionada à linguagem a capacidade de representar metas

e metas-flexíveis no nível operacional, unindo em um mesmo modelo (Diagrama

Integrado) informações sobre as questões “o que?”, representada pelos objetivos, e o

“como?”, representada pelas atividades de processo. O relacionamento direto através

de links meios-fim entre a intencionalidade dos atores dentro do processo e como eles

são executados, permitem verificar não somente o fluxo de atividades de forma

temporal, mas também o raciocínio utilizado pelo ator através dos operadores lógicos,

eventos e regras de negócio, para atingir seus objetivos. Isso só foi possível com a

inclusão do relacionamento entre os modelos, que além de garantir a rastreabilidade,

inclui o potencial da BPMN na modelagem de processos e também os elementos

extras que incluímos nesta nova linguagem.

Outra proposta deste trabalho foi o uso de indicadores como forma de verificar a

capacidade dos modelos em satisfazer seus objetivos. A proposta consiste em

relacionar aos objetivos o conjunto de indicadores necessários para medi-lo e, ao

mesmo tempo, relacionar aos indicadores os elementos de negócio necessários para

que eles possam ser calculados. Esses elementos de negócio (os quais chamamos de

recursos críticos) são rastreados nos processos e, uma vez que não se encontram

disponíveis, consideramos que foi identificado o desalinhamento entre a camada de

objetivos e a camada de processos. Isso ocorre porque na camada de objetivos um

conjunto de recursos críticos são esperados como produtos dos processos que

evidenciam a satisfação de seus objetivos. Entretanto, considerando a ausência desse

elemento na camada de processos, não é possível garantir o cálculo dos indicadores

que medem os objetivos através da modelagem (pode ser que a instância do processo

atinja os objetivos, porém não poderíamos saber sem calcular os indicadores).

A rastreabilidade inserida entre a camada de objetivos organizacionais e a

camada de objetivos de baixo nível referente aos atores, tornou possível identificar

mais facilmente possíveis impactos, desvios e suas motivações, isso porque os

objetivos de baixo nível nada mais são do que a decomposição dos objetivos de alto

nível, porém, esses objetivos são modelados a partir da visão dos atores. Esses

objetivos de baixo nível possuem relações com as atividades do processo que são

executadas para satisfazer os objetivos do ator, o que consequentemente, contribuirá

para os objetivos do negócio.

Um protótipo que permite o uso da linguagem proposta foi desenvolvido a partir

do reuso da codificação (código aberto) da ferramenta Oryx. Este protótipo permitiu a

validação da linguagem de forma gráfica e lógica.

125

6.2.Comparação com trabalhos relacionados

Em [Cardoso10] são mapeadas as relações semânticas dos elementos do

framework ARIS e da linguagem de modelagem de objetivos Tropos como uma

proposta de integração. Eles utilizam a Ontologia de Fundamentação Unificada (UFO)

para se apoiar na interpretação dos conceitos. Nosso trabalho vai além do

mapeamento semântico porque não somente correlacionamos os elementos de

conceitos semelhantes entre as linguagens, mas reutilizamos seus elementos para

gerar uma nova arquitetura e método de modelagem. Além disso, utilizamos outras

linguagens: o framework i* (a qual Tropos também se baseia) e a BPMN (que é um

padrão internacional aberto desenvolvido pela OMG). Não consideramos necessária a

utilização de uma abordagem ontológica porque no nosso caso as semelhanças entre

as definições dos elementos do framework i* e BPMN são diretas. Nosso objetivo

também não era apenas apontar semelhanças entre os conceitos das linguagens, mas

reutilizar, descartar e criar qualquer elemento necessário para representar a nossa

visão de arquitetura.

Em [Cardoso11] são propostas taxonomias para modelos de objetivos de

negócio com o propósito de “harmonizar” as divergências existentes entre o domínio

dos objetivos e o domínio dos processos que determinam o desalinhamento entre

eles. Após a atividade de harmonização, espera-se que seja possível projetar o

alinhamento dos modelos com maior facilidade, uma vez que as

alterações/adaptações necessárias para alinhar ambos os domínios (processos e

objetivos) foram realizadas. A taxonomia qualifica diversos tipos de objetivos e

categorias e suas implicações na estrutura dos processos de negócio que apoiam

esses objetivos.

Nossa proposta difere primeiramente porque consideramos objetivos

qualificados somente como metas e metas-flexíveis uma vez que todos os objetivos

podem ser enquadrados dentro desta perspectiva que é mais simples e tradicional.

Outra diferença é que nossa proposta de alinhamento entre objetivos e

processos não está restrita a qualificação de objetivos porque ela se baseia no

conjunto de relações “indicadores com objetivos” e “recursos críticos com indicadores”,

para representar os elementos que o processo deve produzir, de modo a evidenciar

que o objetivo está sendo alcançado e garantir que os indicadores possam ser

calculados.

Além disso, o relacionamento entre objetivos e atividades no Diagrama Integrado

é possibilitado pelas relações entre os objetivos do negócio e objetivos dos atores. Os

objetivos do negócio estão em nível mais abstrato, e de fato, podem ser decompostos

126

em objetivos mais específicos que direcionam as tarefas dos atores ao longo do

processo. Esses objetivos são identificados mais facilmente ao considerar a visão do

ator/agente, partindo de seu entendimento sobre os papéis e responsabilidades que

desempenha no contexto organizacional. Desvios de entendimento podem ser

identificados ao modelar esses objetivos enquanto são obtidas as informações do

próprio papel executor, durante a modelagem dos processos.

Portanto, o relacionamento entre os elementos citados anteriormente mostra-se

de certa forma com naturalidade - desde que objetivos e processos estejam alinhados

- facilitando análises mais aprofundadas quando se deseja relacionar elementos no

baixo nível (atores, atividades, informações) com elementos do alto nível (objetivos

organizacionais e indicadores). A partir destas relações, não identificamos a

necessidade de uma fase de harmonização entre processos e objetivos como requisito

facilitador para realização de atividades de alinhamento, uma vez que, se os atores

não podem alcançar seus “objetivos locais” (por não poder realizá-lo, e não por

insatisfação de possíveis métricas) e não produzem os elementos previstos nos

indicadores, simplesmente consideramos o processo incapaz de atingir tais objetivos,

tonando-se necessária a sua revisão.

O trabalho de [Shamsaei10] apresenta propostas na linha de indicadores com o

objetivo de garantir o alinhamento dos processos de negócio com regras internas

(definidas pela organização) e externas (por exemplo, normas e leis), além disso,

propõe um método que permite avaliar o nível de alinhamento/discordância dos

processos de negócio em relação a essas regras. A proposta utiliza a extensão da

notação URN que oferece o recurso de indicadores, os quais possibilitam a medição

do alinhamento. O produto da aplicação do método é o nível do alinhamento entre

processos e regras, bem como a identificação dos processos que necessitam de

melhoramento. Nossa proposta também aplica o uso de indicadores, porém de uma

forma diferente. Nosso objetivo é oferecer um recurso que permita em tempo de

modelagem (ou no nível de modelagem) identificar objetivos que não poderão ser

medidos e/ou satisfeitos pela ausência de componentes “chave” nos processos. Não

nos limitamos a análises de regras, mas de objetivos de qualquer natureza que

possam ser medidos através dos indicadores.

Nosso método também permite identificar onde se encontram os elementos

utilizados como insumo pelos indicadores nas atividades do processo e seus

respectivos responsáveis através do rastreamento pelo uso de objetos especiais

(recursos críticos). Com isso, torna-se mais fácil identificar deficiências, como também

o impacto de possíveis mudanças nos objetivos estratégicos.

127

6.3.Contribuições para Transparência do Processo

[Cappelli08], [Leal10] realizam estudos aplicando o conceito de Transparência

(definido por [GupoERPuc12]), no domínio de processos. Neste trabalho, definimos

uma linguagem de modelagem que favorece a análise do alinhamento dos processos

e seus objetivos, sendo que esta facilitação é possibilitada por efeitos da

Transparência no modelo de processo de negócio. Esta seção apresenta análises

sobre as contribuições deste trabalho para a Transparência do Processo.

Segundo [GupoERPuc12], Transparência pode ser qualificada como uma meta-

flexível que possui relações de contribuição com outras metas-flexíveis. O seguinte

grafo SIG (Softgoal Interdependency Graph) [Chung00] foi definido demonstrando

essas relações (Figura 73):

Figura 73 - Gráfico de interdependência de metas de transparência - Softgoal Interdependency

Graph (SIG) [GupoERPuc12].

O relacionamento entre as metas-flexíveis é de "help" e indica que caso essa

meta-flexível sofra contribuições positivas, todos os níveis superiores que estão

ligados pelo link "help" também serão promovidos positivamente (o contrário também é

verdadeiro). As atividades que ao serem executadas contribuem positivamente para

os determinados atributos são chamadas “Operacionalização”. Estas atividades

implementam o requisito não funcional, ou seja, são o meio operacional de satisfazê-lo

[GupoERPuc12].

Em [Leal10], observa-se ao operacionalizar certas metas-flexíveis em processos

de negócio que, dependendo dos resultados gerados pela solução aplicada, é possível

surgir "efeitos colaterais" capazes de gerar relacionamentos implícitos entre as metas-

flexíveis com contribuições tanto positivas quanto negativas. Em outras palavras, ao

operacionalizar uma meta-flexível, é possível que o resultado produzido contribua

positivamente para a meta-flexível visada inicialmente, porém, essa mesma

operacionalização poderá impactar outras meta-flexíveis, tanto de forma positiva

quanto de forma negativa, o que consequentemente será refletido para a

Transparência. Portanto o Grafo de Transparência apesar de relacionar todos os seus

128

elementos do ponto de vista da contribuição positiva, pode sofrer mutações e gerar

diversos relacionamentos implícitos (desejáveis ou não) baseado nas diferentes

operacionalizações. Neste trabalho analisamos apenas as contribuições positivas

explícitas.

Analisamos as contribuições da linguagem para alguns dos nós da árvore que

consideramos mais pertinentes ao contexto, são eles: Informatividade, Entendimento e

Auditabilidade.

Em “Informatividade”, consideramos que contribuímos positivamente para o

atributo Completeza (definido como “Capacidade de não faltar nada do que pode ou

deve ter”) através do Diagrama Integrado, uma vez que ele permite o registro de todos

os elementos da linguagem, desde os níveis abstratos até o nível operacional,

expondo também os relacionamentos entre a camada de objetivos e a camada e

processos. Neste modelo, preferencialmente todos os elementos envolvidos devem

ser modelados e os objetivos devem ter suas relações registradas com as respectivas

atividades que foram projetadas para satisfazê-los.

Com isso, também contribuímos para “Entendimento” ao afetar seus atributos

”Compositividade” (definido como “Capacidade de construir ou formar a partir de

diferentes partes”) e “Dependência” (definido como “Capacidade de identificar a

relação entre as partes com um todo”). Ao inserir informações particulares e de

composição/decomposição, por exemplo, “relacionamento de objetivos locais com as

respectivas atividades que o satisfazem” e “relacionamento entre objetivos

estratégicos e objetivos locais”, contribuímos com o atributo “Detalhamento”, definido

como “Capacidade de descrever em minúcias”. Os atributos “Concisão” (definido como

“Capacidade de ser resumido”) e “Divisibilidade” (definido como “Capacidade de ser

particionado”) podem ser explorados pelo usuário da ferramenta de acordo com suas

necessidades, por exemplo, ao seccionar a modelagem utilizando o Diagrama de

Indicadores ou somente BPMN e i* como forma de resumir e/ou separar as

informações em modelos diferentes.

No contexto da “Auditabilidade”, o atributo “Validável” (definido como

“Capacidade de ser testado por experimento ou observação para identificar se o que

está sendo feito é correto”) torna-se algo intrínseco ao modelo de processo de

negócio, já que ele pode ser instanciado como teste, e também acompanhado e

avaliado pelos indicadores. O mesmo ocorre para o atributo “Controlabilidade”

(definido como “Capacidade de domínio”) caso os processos sejam geridos a parir dos

modelos. Com a aplicação do Diagrama Integrado, maior nível de informações e

relacionamentos entre os elementos são descritos, ampliando a capacidade de

129

controle, principalmente pela relação entre objetivos e atividades que é mais visível

neste diagrama.

O atributo “Verificabilidade” (definido como “Capacidade de identificar se o que

está sendo feito é o que deve ser feito”) recebe contribuição do uso de indicadores

que, em nossa proposta, consiste em identificar se o processo é capaz de produzir o

que é esperado pelos objetivos. O atributo “Rastreabilidade” (definido como

“Capacidade de seguir o desenvolvimento de um processo ou a construção de uma

informação, suas mudanças e justificativas”) recebe contribuição naturalmente pelo

registro das atividades dos processos e das transformações de produtos/informações

que ocorrem durante sua execução. Porém, através dos relacionamentos entre as

camadas de objetivos e processos, é possível rastrear ao mesmo tempo com maior

amplitude e precisão as justificativas das projeções das atividades e objetivos de

negócio, ou seja, as questões do “por que” e “como” encontram-se relacionadas no

Diagrama Integrado, o que também beneficia o atributo “Explicável” (definido como

“Capacidade de informar razão de algo”).

Conforme visto em nossas ponderações sobre as contribuições dos modelos

propostos neste trabalho no contexto da Transparência, o seu uso amplia o nível de

aderência a alguns (porque não analisamos todos os casos) dos requisitos não

funcionais presentes no gráfico de interdependência de metas de Transparência,

atuando como uma opção de operacionalização para cada um dos atributos

apresentados.

6.4. Trabalhos futuros

Nosso trabalho envolveu a definição de uma linguagem para modelagem e o

desenvolvimento de um protótipo. Os trabalhos futuros envolvem melhorias nestes

dois elementos.

No contexto da ferramenta, um dos trabalhos futuros é a evolução da interface

gráfica como forma de melhorar a representação dos elementos, facilitando a

diferenciação dos tipos de relacionamentos e representação de definições. Também

devemos corrigir defeitos na ferramenta Oryx e transformá-la em uma versão final, se

possível, disponibilizando a funcionalidade de oferecer relatórios automatizados.

No contexto da linguagem, devemos explorar mais o uso do conceito de regras

de negócio e seu relacionamento com os objetivos, além do refinamento no uso de

indicadores.

No contexto geral, esforços devem ser orientados para o uso da proposta em

casos mais complexos, possibilitando a busca por pontos de melhoria tanto na

ferramenta como na linguagem.

130

7 Referências bibliográficas

[Amyot02] Amyot, D.; “Using the User Requirements Notation”, ITU-T Workshop on

the "Use of Description Techniques", novembro de 2002.

[Amyot&Mussbacher01] Amyot, D., Mussbacher, G.; “Bridging the

Requirements/Design Gap in Dynamic Systems with Use Case Maps (UCMs)”. In

Proceeding ICSE '01 Proceedings of the 23rd International Conference on Software

Engineering, IEEE Computer Society Washington,DC,USA, 2001, ISBN:0-7695-1050-7

[Amyot&Mussbacher02] Amyot, D., Mussbacher, G.; “URN: Towards a New

Standard for the Visual Description of Requirements”. In Proceedings of

SAM'2002. pp.21~37.

[ARIS06] ARIS; “Help Documentation”, ARIS Business Architect 7.0 v. 7.0.2.234414,

IDS Scheer AG, 2006.

[ARIS12] Site oficial da ferramenta;

http://www.softwareag.com/corporate/products/aris_platform/aris_design/business_arc

hitect/overview/default.asp, acessado em 25/01/2012.

[ARPO12] Site oficial da ferramenta; http://www.klugsolutions.com/, acessado em

25/01/2012.

[Azevedo09] Azevedo, L.G., Sousa, H.P., Souza, Santoro, F.M., Baião, F.;

“Identificação automática de serviços candidatos a partir de modelos de

processos de negócio”, Conferência IADIS Ibero-Americana WWW/Internet 2009,

2009.

[Behnam10] Behnam, S.A., Amyot, D., Mussbacher, G.; “Towards a Pattern-Based

Framework for Goal-Driven Business Process Modeling”, 2010 Eighth ACIS

International Conference on Software Engineering Research, Management and

Applications, 2010.

http://www.softwareag.com/corporate/products/aris_platform/aris_design/business_architect/overview/default.asp

http://www.softwareag.com/corporate/products/aris_platform/aris_design/business_architect/overview/default.asp

http://www.klugsolutions.com/

131

[Benedusi92] Benedusi, P., Cimitile, A., Carlini, U.; “Reverse Engineering

Processes, Design Document Production, and Structure Charts”, Journal Systems

and Software, v. 19, p. 225-245, 1992.

[BSI12] Balanced Scorecard Institue; site oficial BSC,

http://www.balancedscorecard.org/, acessado em 10/02/2012.

[Braubach 10] Braubach, L., Pokahr, A., Jander, K., Lamersdorf, W., Burmeister, B.;

“Go4Flex: Goal-oriented Process Modelling”, Proc. 4th International Symposium on

Intelligent Distributed Computing (IDC-2010).

[Bizagi12] Site oficial da ferramenta; www.bizagi.com, acessado em 25/01/2012.

[Cappelli&Leite08] Cappelli, C., Leite, J. C. S. P.; “Transparência de Processos

Organizacionais”, Universidade Federal Fluminense, LATEC. II Simpósio

Internacional de Transparência nos Negócios. 2008.

[Cappelli09] Cappelli, C.; “Uma Abordagem para Transparência em Processos

Organizacionais Utilizando Aspectos”, Rio de Janeiro, 2009. 328 p. Tese de

Doutorado – Departamento de Informática, Pontifícia Universidade Católica do Rio de

Janeiro.

[Cappelli10] Cappelli, C., Santoro F.M., Leite, J.C.S.P., Batista, T., Medeiros, A.L.,

Romeiro, C.S.C.; “Reflections on the modularity of business process models: The

case for introducing the aspect-oriented paradigm”, Business Process

Management Journal 16(4): Emerald 662-687, 2010.

[Cardoso10] Cardoso, E.C.S., Junior, P.S.S., Almeida J.P.A.; Guizzardi, R.S.S.,

“Semantic Integration of Goal and Business Process Modeling”, Anais da

International Conference on Research and Practical Issues of Enterprise Information

Systems (CONFENIS 2010), Natal/RN, Brasil, 2010.

[Cardoso11] Cardoso, E.C.S., Guizzardi, R.S.S., Almeida, J.P.A.; “Aligning Goal

Analysis and Business Process Modelling: A Case Study in Health Care”,

International Journal of Business Process Integration and Management 2011, 2011.

http://www.bizagi.com/

http://www-di.inf.puc-rio.br/~julio/Bpm-aop.pdf

http://www-di.inf.puc-rio.br/~julio/Bpm-aop.pdf

132

[Chikofsky&Cross90] Chikofsky, E. J., Cross II, J. H.; “Reverse Engineering and

Design Recovery: A Taxonomy”. IEEE Software, v. 7, n. 1, p. 13-17, 1990.

[Chung00] Chung, L., Nixon, B., Yu, E., Mylopoulos, J.; “Non-Functional

Requirements in Software Engineering” – Kluwer Academic Publishers –

Massachusetts, USA, 2000.

[Chung&Leite09] Chung, L., Leite, J.C.S.P.; “On non-functional requirements in

software engineering”, in Borgida, A., Chaudhri, V., Giorgini, P. and Yu, E. (Eds),

Conceptual Modeling: Foundations and Applications, 1st ed., Vol. 5600, Springer,

Berlin, pp. 363-79, 2009.

[Cysneiros&Leite] Cysneiros, L.M.; Leite, J.C.S.P.; “Nonfunctional requirements:

From elicitation to conceptual models”, Software Engineering, IEEE Transactions,

páginas 328 – 350, ISSN: 0098-5589, 04 Maio 2004.

[Daniel07] Daniel, P., Weske, M., Overdick, H., Decker, G.; “Oryx BPMN Stencil Set

Implementation”, Bachelor Thesis, Hasso Plattner Institut, 30/06/2007, disponível em

“http://Oryx-project.org/research”.

[Decker08] Decker, G., Overdick, H., Weske, M.; “Oryx - An Open Modeling

Platform for the BPM Community”, In Marlon Dumas, Manfred Reichert, and Ming-

Chien Shan, editors, BPM, volume 5240 of Lecture Notes in Computer Science, pages

382–385. Springer, 2008.

[Daniele11] Daniele, B.; Jiang, L.; Amyot, D.; Mylopoulos, J.; “Reasoning with Key

Performance Indicators”, 4th IFIP WG 8.1 Working Conference, PoEM 2011 Oslo,

Norway, November 2-3, 2011 Proceedings, pp 82-96, DOI: 10.1007/978-3-642-24849-

8_7, ISBN: 978-3-642-24848-1, ISSN: 1865-1348.

[Davis02] Davis, R.; “Business Process Modeling with ARIS – A Practical Guide”,

London: Springer, 2002, 531 p. Bibliografia: ISBN, 1-85233-434-7.

[Davis07] Davis, R., Brabander, E.; “ARIS design platform: getting started with

BPM”, Springer, 2007, Bibliografia: ISBN-10: 1846286123 | ISBN-13: 978-1846286124.

http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=32

http://books.google.com/books?id=yZbExAf6jU0C&printsec=frontcover&dq=ARIS&hl=pt-BR&ei=hMHATbicIabu0gGb_aS3Cg&sa=X&oi=book_result&ct=result&resnum=2&ved=0CDsQ6AEwAQ

http://books.google.com/books?id=yZbExAf6jU0C&printsec=frontcover&dq=ARIS&hl=pt-BR&ei=hMHATbicIabu0gGb_aS3Cg&sa=X&oi=book_result&ct=result&resnum=2&ved=0CDsQ6AEwAQ

133

[Diirr10] Diirr, T., Souza, A, Azevedo, L. G., Santoro, F.; “Analyze Credit Request

Model”. (2010). Relatórios técnicos do Departamento de Informática Aplicada –

Universidade Federal do Estado do Rio de Janeiro (UNIRIO).

[Diirr11] Diirr, T., Souza, A., Santoro, F.M., Azevedo, L.G.; “Identificação e análise

de serviços: Um estudo de caso”, NP2Tec – Núcleo de Pesquisa e Prática em

Tecnologia, Departamento de Informática Aplicada, Universidade Federal do Estado

do Rio de Janeiro (UNIRIO).

[Eriksson&Penker00] Eriksson, H-E.; Penker, M.; “Business Modeling with UML –

Business Patterns at Work”, John Wiley & Sons, (459 pages), ISBN: 0471295515,

2000.

[Fiorini95] Fiorini, S.T.; “Processos de Negocio e Hipertextos: uma proposta para

elicitacao de requisitos”, Dissertação de mestrado, PUC-Rio, 1995.

[Ghanavati09] Ghanavati S., Amyot D., Peyton, L.; “Compliance Analysis Based on

a Goal-oriented Requirement Language Evaluation Methodology”, IEEE

International Conference on Requirements Engineering, 2009.

[Guedes07] Guedes, G.T.A.; “UML2 Guia prático”, ISBN:978-85-7522-145-7

Páginas:176 Ano: 2007.

[GRL12] GRL; Site oficial, http://www.cs.toronto.edu/km/GRL/, acessado em 2/2/2012.

[Grunert&Ellegard92] Grunert, K. G.; Ellegard, C.; “The concept of key success

factors: theory and method”. MAPP Working Paper, n. 4, Oct. 1992. Disponível em

“http://130.226.203.239/pub/mapp/wp/wp04.pdf”.

[GupoERPuc12] Grupo de Engenharia de Requisitos – PUC-Rio, “Transparência”,

disponível em “http://www.er.les.inf.puc-rio.br/~wiki/index.php/Transpar%C3%AAncia”,

acessado em 25/01/2012.

[Intalio12] Site oficial da fermenta; www.intalio.com/bpm, acessado em 25/01/2012.

[iStarWiki12] Wiki oficial do i*; http://istar.rwth-aachen.de/tiki-

index.php?page=iStarQuickGuide#Purpose, acessado em 8/2/2012.

http://www.cs.toronto.edu/km/GRL/

http://130.226.203.239/pub/mapp/wp/wp04.pdf

http://www.intalio.com/bpm

134

[ITU08] International Telecommunication Union; “User requirements notation (URN)

– Language Definition”, Padrão recomendado Z.151, 11/2008.

[Josuttis07] Josuttis, N.; “SOA in practice: The Art of Distributed System Design”.

O’Reilly, 2007.

[Kaiya02] Kaiya, H.; Horai, H.; Saeki, M.; “AGORA: Attributed Goal-Oriented

Requirements Analysis Method”, Requirements Engineering, 2002. Proceedings.

IEEE Joint International Conference, page 13 – 22, ISSN: 1090-705X , 10 Dezembro

2002.

[Kefi&Kalika05] Kefi H, Kalika M.; “Survey of strategic alignment impacts on

organizational performance”, in international European companies. In: Hawaii

International Conference on System Sciences 25, 2005.

[Kueng&Kawalek97] Kueng, P., Kawalek, P.; “Goal-based business process

models: creation and evaluation”, Business Process Management Journal, Vol. 3

No. 1, pp. 17-38.

[Kunze&Weske10] Kunze, M., Weske, M.; “Signavio-Oryx Academic Initiative”,

Demo Session of the 8th International Conference on Business Process Management

(BPM 2010). Hoboken, NJ, September 2010.

[Lamsweerde09] Lamsweerde, A. V.; “Conceptual modeling: Foundations and

applications”. Chapter Reasoning About Alternative Requirements Options. Springer-

Verlag, 2009.

[Leal10] Leal, A.L.C., Sousa, H.P., Leite, J.C.S.P., Braga, J.L., “Transparência

aplicada a modelos de negócio”, Worshop de Engenharia de Software, 2010.

[List&Korherr06] List, B., Korherr, B.; “An evaluation of conceptual business

process modelling languages”, In 21st ACM symposium on applied computing

(SAC’06) (pp. 1532–1539), Dijon, France, (2006).

[Louw12] Louw, L.; “Business Process Management (BPM) – InSights”, blog que

aborda assuntos relativos à BPM, http://bpmfundamentals.wordpress.com/, acessado

em 4/2/2012.

135

[Marquioni05] Marquioni, C. E.; “A modelagem de processos de negócio como

subsídio fundamental para a identificação dos requisitos”. Disponível em:

<http://www.choose.com.br/infochoose/artigos/39art03.htm>. Acesso em 1/02/2012.

[Melo04] Melo, A. C.; “Desenvolvendo aplicações com UML 2.0”, Rio de Janeiro:

Brasport, 2004. ISBN8574521752, Número Edição: 2, Número Volume:0, Quantidade

de Páginas:304, Acabamento:Brochura, Editora: BRASPORT.

[Mili03] Mili, H., Jaodue, G.B., Lefebvre, E., Tremlay, G., Petrenko, A.; “Business

process modeling languages: Sorting through the alphabet soup” (TR LATECE).

UQAM, 55 pages, November 2003.

[Napolitano09] Napolitano, F. M.; “Uma Estratégia Baseada em Simulação para

Validação de Modelos em i*”. Dissertação de Mestrado, PUC–Rio, Março de 2009.

[Oliveira08a] Oliveira, A.; Padua A.; Leite, J. C. S. P; Cysneiros, L. M.; “AGFL –

Agent Goals from Lexicon – Eliciting Multi-Agent Systems Intentionality”, iStar’08

The third internation i* workshop; Recife, Brazil, Fevereiro de 2008, CEUR Workshop

Proceedings 322, pg. 29-32, ISBN: 1613-0073.

[Oliveira08b] Oliveira, A.; Padua A.; Leite, J. C. S. P; Cysneiros, L. M.; Lucena, C.J.;

“Diagnoses: a quality process for building i* models”, Proceedings of the Forum at

the CAiSE’08, Montpellier, France, June 2008, CEUR Workshop Proceedings 344

CEUR-WS.org, pg. 9-12, 2008.

[Oliveira08c] Oliveira, A.; Padua A.; Leite, J. C. S. P; Cysneiros, L. M.; “Engenharia

de requisitos intencional: um método de elicitação, modelagem e análise de

requisitos”, tese de doutorado, PUC-RIO, 03/2008.

[Oliveira10] Oliveira, A.; Padua A.; Leite, J. C. S. P; Cysneiros, L. M.; “Using i* Meta

Modeling for Verifying i* Models”, Proceedings of the 4th International i* Workshop -

iStar10, 76-80, Hammamet, Tunisia, 2010.

[Oryx12] Oryx; Site oficial Oryx, disponível em “http://Oryx-project.org/research”,

acessado em “15/01/2012”.

136

[Paim02] Santos, R.P.C., Cameira, R.F., Clemente, A.A., Clemente, R.G.;

“Engenharia de Processos de Negócios: Aplicações e Metodologias”, Engenharia

de Processos de Negocios - XXII ENEGEP – 2002.

[Peters07] Peters, N., Weske, M., Overdick, H., Decker, G.; “Oryx Stencil Set

Specification”, Final Bachelor’s Page, Hasso Plattner Institut, 30/06/2007, disponível

em “http://Oryx-project.org/research”.

[Piekarski&Quinaia95] Piekarski, A.E.T., Quinaia, M.A.; “Reengenharia de

software: o que, por quê e como”, PRESSMAN, R. S. Engenharia de Software. São

Paulo: Makron Books, 1995.

[Pourshahid09] Pourshahid, A., Amyot, D., Peyton, L., Ghanavati, S., Chen, P.,

Weiss, M., Forster, A.J.; “Business process management with the user

requirements notation”, 2009.

[Rockart78] Rockart, J.; “A New Approach to Defining the Chief Executive's

Information Needs”. Working Paper no. 37. Center for Information Systems Research,

Sloan School of Management. Massachusetts Institute of Technology. May 1978.

Disponível em “http://dspace.mit.edu/bitstream/handle/1721.1/1942/SWP-1008-

04219611-CISR-037.pdf?sequence=1”.

[Salm03] Salm, J. F.; “Extensões da UML para descrever processos de negócio”.

Dissertação (Pós-graduação em Engenharia da Produção) – Universidade Federal de

Santa Catarina, Florianópolis, 2003.

[Scheer00] Scheer, A.W.; “ARIS – Business Process Modeling”, Berlin; Heidelberg;

New York; Barcelona; Hong Kong; London; Milan; Paris; Singapore; Tokyo: Springer,

2000, 218 p. 3. ed., Bibliografia: ISBN, 3-540-65835-1.

[Scheer&AG05] IDS Scheer AG; “Methods ARIS 7.0”, 2005, Disponível em

http://www.rmdservice.com/quality_policy/JobAid_ARIS_Method_Manual.pdf.

[Seidlmeier&Storr04] Seidlmeier, H., Storr, D.; “Process Modeling with ARIS: A

Piratical Introduction”, Vieweg, 2004.

[Serpro11] Serpro; “Revista tema”, n 208, setembro/outubro, 2011. ISSN: 0100-5227.

http://dspace.mit.edu/bitstream/handle/1721.1/1942/SWP-1008-04219611-CISR-037.pdf?sequence=1

http://dspace.mit.edu/bitstream/handle/1721.1/1942/SWP-1008-04219611-CISR-037.pdf?sequence=1

http://www.rmdservice.com/quality_policy/JobAid_ARIS_Method_Manual.pdf

137

[Shamsaei10] Shamsaei, A.; Pourshahid, A.; Amyot, D.; “Business Process

Compliance Tracking Using Key Performance Indicators”, 6th International

Workshop on Business Process Design (BPD’10), 2010.

[Signavio12] Site oficial da ferramenta; http://www.signavio.com/en.html, acessado

em 25/01/2012.

[Sikandar03] Sikandar-gani, S. B.; “User Requirement Notation (URN)”, Graduate

Student, Department of Electrical and Computer Engineering, Mississippi State

University, MS, USA, 2003.

[Singh&Woo09] Singh, S.N., Woo C.; “Investigating business-IT alignment through

multi-disciplinary goal concepts”, Revista Springer-Verlag New York, Inc., 2009.

[Soffer&Wand05] Soffer, P., Wand, Y.; “On the notion of soft goals in business

process modeling”, Journal of Business Process Management, Vol. 11 No. 6, pp.

663-79, 2005.

[Sousa10] Sousa, H. P.; “Identificação Automática de Serviços em Uma

Abordagem SOA”. Relatórios Técnicos. Universidade Federal do Estado do Rio De

Janeiro, Escola de Informática Aplicada. Projeto Final de Graduação. 2010.

[Sousa&Leite12] Sousa, H. P., Leite, J.C.S.P.; “Aplicação da Engenharia Reversa e

Reengenharia de Software no Desenvolvimento de plugins para a Ferramenta

Oryx”. Monografias, PUC-Rio. 2012 (a publicar).

[Susi05] Susi, A., Perini, A., Mylopoulos, J; Giorgini, P.; “The Tropos Metamodel and

its Use”, Informatical Journal, 5/2005.

[Tscheschner07] Tscheschner, W., Weske, M., Overdick, H., Decker, G.; “Oryx

Dokumentation”, Bachelorabeit, Hasso Plattner Institut, 30/06/2007, disponível em

“http://Oryx-project.org/research”.

[Villarroel06] Villarroel Dávalos, R.; “Modelagem de processos”, livro didático /

Ricardo Villarroel Dávalos; design instrucional Dênia Falcão de Bittencourt, Viviane

http://www.signavio.com/en.html

138

Bastos. - 2. ed. rev. e atual. - Palhoça: UnisulVirtual, 2006. 176 p.: il.; 28 cm. Inclui

bibliografia. ISBN 85-60694-89-7; ISBN 978-85-60694-89-1.

[Visio12] Site oficial da ferramenta; http://office.microsoft.com/pt-br/visio/, acessado

em 25/01/2012.

[VisualArchitect12] Site oficial da ferramenta; http://www.visual-

paradigm.com/product/bpva/, acessado em 25/01/2012.

[Weiss&Amyot05] Weiss, M., Amyot, D.; “Business process Modeling with URN”,

International Journal of E-Business Research, Vol. 1, No. 3, 2005.

[WMC95] Workflow Management Coalition; “The Workflow Reference Model”,

Bruxelas, Jan. 1995. 53p, Disponível por http://www.wfmc.org.

[Yu95] Yu, E.; “Modelling Strategic Relationships for Process Reengineering”.

Phd Thesis, Graduate Department of Computer Science, University of Toronto,

Toronto, Canada, 1995, pp.124.

[Yu01] Yu, E.; “Agent-Oriented Modelling: Software versus the world in agent-

oriented software engineering”, AOSE-2001, Workshop Proceedings, Montreal,

Canada, 29/03/2001, LNCS 2222.

[Yu09] Yu, E.; “Social Modeling and i*”, In: Borgida, A. T., V. Chaudhri, P. Giorgini,

E. S. Yu (eds.): Conceptual Modeling: Foundations and Applications - Essays in Honor

of John Mylopoulos. LNCS volume 5600, 2009. Springer. ISBN 978-3-642-02462-7.

http://office.microsoft.com/pt-br/visio/

http://www.visual-paradigm.com/product/bpva/

http://www.visual-paradigm.com/product/bpva/

http://www.wfmc.org/

http://www.cs.toronto.edu/pub/eric/JMfest09-EY.pdf

http://dx.doi.org/10.1007/978-3-642-02463-4

http://dx.doi.org/10.1007/978-3-642-02463-4

http://en.wikipedia.org/wiki/Special:BookSources/9783642024627

henrique prado sousa integrando modelagem intencional à ...julio/diss-henrique.pdf · modelagem de...

Documents