ads:
FRANCISCO VIRGINIO MARACCI
RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
MARING
´
A
2010
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
ads:
FRANCISCO VIRGINIO MARACCI
RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
Disserta¸c˜ao apresentada ao Programa de
P´os-Gradua¸c˜ao em Ciˆencia da Computa¸c˜ao
da Universidade Estadual de Maring´a, como
requisito para obten¸c˜ao do grau de Mestre
em Ciˆencia da Computa¸c˜ao.
Orientadora: Profa. Dra. ITANA MARIA
DE SOUZA GIMENES
MARING
´
A
2010
M257r Maracci, Francisco Virginio
RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio.
/ Francisco Virginio Maracci. Maring´a, PR: UEM, 2010.
115f. : il.
Orientador: Itana Maria de Souza Gimenes
Disserta¸c˜ao (Mestrado) - Universidade Estadual de Maring´a.
Programa de P´os-Gradua¸c˜ao em Ciˆencia da Computa¸c˜ao.
1. Processo de Neg´ocio. 2. Servi¸cos Web. 3. Reutiliza¸c˜ao
4. Linha de Produto de Software. 5. Arquitetura Orientada
a Servi¸cos. 6. Tecnologia de Servi¸cos Web. I. Gimenes, Itana
Maria de Souza. II. Universidade Estadual de Maring´a. Pro-
grama de P´os-Gradua¸c˜ao em Ciˆencia de Computa¸c˜ao.
CDD: 001.6
Agradecimentos
Primeiramente e mais importante, agrade¸co a Deus por permitir entrar no mestrado
e termin´a-lo. Agrade¸co, tamb´em, por ter concedido a oportunidade de conhecer pessoas
inesquec´ıveis durante este per´ıodo. Apesar das dificuldades encontradas, estou realizando
um dos meus maiores sonhos.
Sei que este sonho n˜ao seria poss´ıvel sem a dedica¸c˜ao, esfor¸co, apoio e compreens˜ao das
duas pessoas mais importantes da minha vida. Portanto, agrade¸co os meus pais Oswaldo
Luzeni Maracci e Valdelici Virginio Maracci, que me deram o dom da vida.
N˜ao posso deixar de agradecer especialmente a minha orientadora Dr. Itana Maria
de Souza Gimenes pelo esfor¸co, dedica¸c˜ao e compreens˜ao ao me orientar. Obrigado
professora por tudo, e saiba que tenho a senhora como um exemplo a ser seguido.
Agrade¸co, ainda, aos professores Thelma Elita Colanzi Lopes, Andreia Padovan
Jubileu e Marcelo Vin´ıcius Creres Rosa pela amizade que consolidou-se durante
as orienta¸c˜oes. N˜ao esquecendo dos excelentes professores e profissionais que lecionaram
durante a minha gradua¸c˜ao e mestrado. Vocˆes com certeza foram a motiva¸c˜ao para o
desejo de realizar o mestrado e lecionar.
Ainda, n˜ao poderia deixar de agradecer a Inˆes secret´aria do mestrado que sempre
atende os mestrandos com muita dedica¸c˜ao, carinho e respeito. Ao Robson que substituiu
a Inˆes durante um per´ıodo realizando um excelente trabalho. Obrigado pela amizade e
compreens˜ao.
Aos meus amigos do mestrado e do grupo de pesquisa Ana Paula, Daiane, Tiago,
Rodrigo, Roberto, Camila, Maur´ılio, K´essia, Bruno, Marcelo, Carlos, Vanderson, Andr´e
e Edson pelo companheirismo, amizade e apoio nestes anos.
Aos meus amigos e colegas de profiss˜ao da Uniesp pelo apoio, amizade e, principal-
mente, pela troca de experiˆencias. Especialmente aos coordenadores pela compreens˜ao
neste tempo.
Um agradecimento especial aos meus amigos e treinadores da academia do Sesc-Maring´a
companheiros dos poucos momentos de lazer durante este percurso a ser vencido.
A todos meus familiares e amigos, de Presidente Prudente e Maring´a, pelo
apoio nos momentos de alegrias, tristezas, fraquezas e ausˆencias. Desculpem-me pelas
falhas cometidas e falta de tempo para lhes disponibilizar a devida aten¸c˜ao que vocˆes
merecem.
Um agradecimento muito especial para Christiane Barros e Daniele Gregorio Costa
pela grande ajuda concedida ao auxiliarem-me na corre¸c˜ao deste trabalho.
Deixo, ainda, a todos uma frase para reflex˜ao ’When you reach the end of what you
should know, you will be at the beginning of what you should sense’.
i
Finalmente, obrigado a todos que diretamente ou indiretamente ajudaram-me neste
ciclo de vida que se completa com a finaliza¸c˜ao desta disserta¸c˜ao de mestrado.
Muito obrigado!
ii
Resumo
Processos de neg´ocio (PN) e servi¸cos Web (SW) contemplam solu¸c˜oes para uma
comunica¸c˜ao inter-organizacional organizada e apoiada pelo estabelecimento de um
acordo m´utuo (contrato eletrˆonico). O estabelecimento dos contratos eletrˆonicos
para os processos de neg´ocio em um determinado dom´ınio envolvem um conjunto
de pontos comum e divergentes (variabilidades). Portanto, a presente disserta¸c˜ao
prop˜oe uma abordagem para reutiliza¸c˜ao de processos de neg´ocio por interm´edio do
estabelecimento de uma estrutura de linha de produto com representa¸c˜ao de vari-
abilidades pelo diagrama de atividades da UML. A abordagem proposta ´e aplicada
no momento da contrata¸c˜ao dos PN e SW, n˜ao no momento do desenvolvimento
dos mesmos. O objetivo da abordagem e da representa¸c˜ao ´e o desenvolvimento de
estruturas de linha de produto para processos de neg´ocio com o intuito de melhorar
a estrutura¸c˜ao dos processos de neg´ocio e servi¸cos Web e, consequentemente, per-
mitir a reutiliza¸c˜ao dos mesmos. A abordagem proposta ´e dividida em dois ciclos de
vida. O ciclo de vida denominado engenharia de dom´ınio de processos de neg´ocio ´e
respons´avel por definir o dom´ınio do PN e o desenvolvimento e publica¸c˜ao dos PN
e SW. A engenharia de PN ´e respons´avel pela configura¸c˜ao e desenvolvimento dos
produtos. A finaliza¸c˜ao do trabalho deu-se atrav´es da aplica¸c˜ao da abordagem no
dom´ınio de operadoras de telecomunica¸c˜oes com o intuito de avaliar a aplicabilidade
da mesma. A abordagem ´e ´util para a estrutura¸c˜ao dos processos de neg´ocio,
servi¸cos Web e termos de QoS possibilitando, assim, o reuso dos mesmos.
iii
iv
Abstract
Business processes (BP) and Web Services (SW) are solutions to an inter-organiza-
tional communication organized and supported by the establishment of a mutual
agreement (electronic contract). The establishment of contracts for electronic
business processes in a given area involves a set of common points and differences
(variability). Therefore, this thesis proposes an approach to reuse of business
processes through the establishment of an effective product line with representation
of variability by the UML activity diagram. The proposed approach is applied at
the time of hire the BP and SW, not the time of their development. The objective
of the approach and the representation is the development of a product line in-
frastructure for business processes in order to improve the structuring of business
processes and Web services and thus enable their reuse. The proposed approach
is divided into two life cycles. The life cycle called business processes domain
engineering is responsible for defining the domain of BP and the development
and publication of the BP and SW. BP Engineering is responsible for setting and
product development. The completion of the work took place by applying the
approach in the field of telecommunications carriers in order to demonstrate the
applicability of the same. The approach demonstrated the advantage of being
useful for the structuring of business processes, web services and terms of QoS,
thus allowing for the reuse of them.
v
vi
Sum´ario
Lista de Figuras ix
1 Introdu¸c˜ao 1
1.1 Contexto e Motiva¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Organiza¸c˜ao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Processo de Neg´ocio, Servi¸cos Web e Contrato Eletrˆonico 5
2.1 Considera¸c˜oes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Arquitetura Orientada a Servi¸cos . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Tecnologia de Servi¸cos Web . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Processo de Neg´ocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Contratos Eletrˆonicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.1 Uma abordagem baseada em caracter´ısticas para o estabele- ci-
mento de contratos eletrˆonicos para servi¸cos Web . . . . . . . . . . 14
2.6 Projeto InfraPro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7 Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3 Linha de Produto de Software e Reutiliza¸c˜ao 21
3.1 Considera¸c˜oes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Reutiliza¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Linha de Produto de Software . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 Um processo de gerenciamento de variabilidades para linha de pro-
duto de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio 33
4.1 Considera¸c˜oes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio . . . . . . . 35
4.2.1 Ciclos de vida e suas atividades . . . . . . . . . . . . . . . . . . . . 36
4.2.2 Artefatos produzidos na RofPN . . . . . . . . . . . . . . . . . . . . 38
4.3 Representa¸c˜ao de Variabilidades em Diagrama de Atividades . . . . . . . . 49
4.4 Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
vii
5 Exemplo de aplica¸c˜ao 55
5.1 Considera¸c˜oes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Dom´ınio da aplica¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3 Engenharia de dom´ınio de processos de neg´ocio . . . . . . . . . . . . . . . 57
5.3.1 Modelo de dom´ınio . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.2 Molde de contrato eletrˆonico . . . . . . . . . . . . . . . . . . . . . . 62
5.3.3 Reposit´orio de servi¸cos Web e processos de neg´ocio . . . . . . . . . 75
5.4 Engenharia de processo de neg´ocio . . . . . . . . . . . . . . . . . . . . . . 75
5.4.1 Modelo de caracter´ıstica configurado . . . . . . . . . . . . . . . . . 75
5.4.2 Diagrama de atividades configurado . . . . . . . . . . . . . . . . . . 79
5.4.3 Contrato eletrˆonico final . . . . . . . . . . . . . . . . . . . . . . . . 79
5.5 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.6 Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6 Conclus˜ao 89
Referˆencias Bibliogr´aficas 93
viii
Lista de Figuras
2.1 Estrutura da tecnologia de servi¸cos Web. (Garcia, 2007) . . . . . . . . . . 7
2.2 Modelo de servi¸cos Web b´asico. (Garcia, 2007) . . . . . . . . . . . . . . . . 8
2.3 Ciclo de vida de gerencia de processo de neg´ocio. (Garcia, 2007) . . . . . . 12
2.4 Processo de estabelecimento de contrato eletrˆonico com base em carac-
ter´ısticas (Fantinato, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Relacionamento entre os artefatos produzidos pelo processo (Fantinato, 2007). 16
2.6 Estrtura do modelo de caracter´ısticas para servi¸cos eletrˆonicos (Fantinato,
2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7 Arquitetura do conjunto de ferramentas FeatureContract (Fantinato, 2007). 18
3.1 reutiliza¸c˜ao-Based workflow Type Development (Kradolfer, 2000). . . . . . 22
3.2 Atividades essenciais de Linha de Produto de Software (Adaptado). (Northrop
e Clements, 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Desenvolvimento do n´ucleo de artefatos. (Northrop e Clements, 2007) . . . 25
3.4 Desenvolvimento do produto. (Northrop e Clements, 2007) . . . . . . . . . 26
3.5 Exemplo de Modelo de caracter´ısticas (Antkiewicz e Czarnecki, 2004) . . . 27
3.6 Exemplo de Modelo de Caracter´ıstica no FeaturePlugin (Fantinato, 2007) . 28
3.7 UML Profile para representa¸c˜ao de variabilidades em diagrama de classes
(Korherr e List, 2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.8 Mapeamento de variabilidades em diagrama de atividades (Korherr e List,
2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.9 Processo de desenvolvimento de LP existente com gerenciamento de vari-
abilidade (Oliveira Junior, 2005). . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Abordagem para reutiliza¸c˜ao de PN . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Etapas da sele¸c˜ao e reutiliza¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Modelo de caracter´ıstica para o processo de neg´ocio da agˆencia de viagens . 39
4.4 Modelo de caracter´ıstica para agˆencia de hot´eis . . . . . . . . . . . . . . . 40
4.5 Modelo de caracter´ıstica para a agˆencia de linhas a´ereas . . . . . . . . . . . 40
4.6 Modelo de caracter´ıstica para a locadora de ve´ıculos . . . . . . . . . . . . . 41
4.7 Descri¸c˜ao dos SW para agˆencia de hot´eis - se¸c˜ao: wsdl:Definitions . . . . . 42
4.8 Descri¸c˜ao do PN para agˆencia de hot´eis - se¸c˜ao: bpel:Process . . . . . . . . 43
4.9 Descri¸c˜ao dos Termos de QoS para agˆencia de hot´eis - se¸c˜ao: wsag:Terms . 43
4.10 Modelo de caracter´ıstica configurado para rede hoteleria . . . . . . . . . . 44
4.11 Modelo de caracter´ıstica configurado para o processo de neg´ocio da agˆencia
de viagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
ix
4.12 Modelo de caracter´ıstica configurado para a agˆencia de linhas a´ereas . . . . 46
4.13 Modelo de caracter´ıstica configurado para a locadora de ve´ıculos . . . . . . 46
4.14 SW contratados da agˆencia de hot´eis - se¸c˜ao: wsdl:Definitions . . . . . . . 47
4.15 PN contratados da agˆencia de hot´eis - se¸c˜ao: bpel:Process . . . . . . . . . 48
4.16 Termos de QoS contratados da agˆencia de hot´eis - se¸c˜ao: wsag:Terms . . . 48
4.17 Representa¸c˜ao de uma atividade, servi¸co Web e/ou sub-processo obrigat´orio 49
4.18 Representa¸c˜ao de uma atividade, servi¸co Web e/ou sub-processo com ex-
ecu¸c˜ao opcional (a) com decision node (b) com fork e join nodes . . . . . . 49
4.19 Representa¸c˜ao de atividades, servi¸co Web e/ou sub-processos executados
em paralelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.20 Representa¸c˜ao de atividades, servi¸cos Web e/ou sub-processos executados
com op¸c˜ao de escolha m´ultipla . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.21 Representa¸c˜ao de atividades, servi¸cos Web e/ou sub-processos executados
com op¸c˜ao de escolha m´ultipla exclusiva . . . . . . . . . . . . . . . . . . . 51
4.22 Representa¸c˜ao de estrutura de repeti¸c˜ao. . . . . . . . . . . . . . . . . . . . 51
4.23 Exemplo de diagramas de atividades mostrando o processo de neg´ocio da
agˆencia de viagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.24 Exemplo de diagramas de atividades mostrando o processo de neg´ocio da
agˆencia de viagens conFigurado . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1 Modelo de caracter´ısticas para servi¸cos eletrˆonicos do sistema COB (car-
acter´ısticas relacionadas aos servi¸cos eletrˆonicos) (Fantinato, 2007). . . . . 58
5.2 Modelo de caracter´ısticas para servi¸cos eletrˆonicos do sistema COB (car-
acter´ısticas relacionadas aos servi¸cos eletrˆonicos) (Fantinato, 2007). . . . . 59
5.3 Modelo de caracter´ısticas para servi¸cos eletrˆonicos do sistema CRM (car-
acter´ısticas relacionadas aos servi¸cos eletrˆonicos) (Fantinato, 2007). . . . . 61
5.4 Modelo de caracter´ısticas para servi¸cos eletrˆonicos do sistema CRM (car-
acter´ısticas relacionadas aos servi¸cos eletrˆonicos) (Fantinato, 2007). . . . . 62
5.5 Molde de Contrato eletrˆonico - se¸c˜ao: wsdl:Definitions (Sistema COB)
(Fantinato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.6 Molde de Contrato eletrˆonico - se¸c˜ao: wsdl:Definitions (Sistema CRM)
(Fantinato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.7 Molde de contrato eletrˆonico - se¸c˜ao: wsdl:Definitions, elementos partner-
LinkType (Sistema COB) (Fantinato, 2007). . . . . . . . . . . . . . . . . . 67
5.8 Diagrama de atividades com as representa¸c˜oes para o processo de neg´ocio
da operadora de telecomunica¸c˜oes. . . . . . . . . . . . . . . . . . . . . . . . 69
5.9 Molde de contrato- se¸c˜ao: bpel:Process (Fantinato, 2007). . . . . . . . . . . 70
5.10 Molde de contrato- se¸c˜ao: bpel:Process, elementos partnerLink e variable
(Fantinato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.11 Molde de contrato eletrˆonico - se¸c˜ao: wsag:Terms, Parte I (Sistema COB)
(Fantinato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.12 Molde de contrato eletrˆonico - se¸c˜ao: wsag:Terms, Parte II (Sistema COB)
(Fantinato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.13 Configura¸c˜ao do modelo de caracter´ısticas para servi¸cos eletrˆonicos do
sistema COB (Fantinato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . 76
x
5.14 Configura¸c˜ao do modelo de caracter´ısticas para os atributos de QoS do
sistema COB (Fantinato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . 77
5.15 Configura¸c˜ao do modelo de caracter´ısticas para servi¸cos eletrˆonicos do
sistema CRM (Fantinato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . 78
5.16 Diagrama de atividades para o contrato eletrˆonico vigente. . . . . . . . . . 79
5.17 Contrato eletrˆonico - se¸c˜ao: wsdl:Definitions para o sistema COB (Fanti-
nato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.18 Contrato eletrˆonico - se¸c˜ao: wsdl:Definitions para o sistema CRM (Fanti-
nato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.19 Contrato eletrˆonico - se¸c˜ao: wsdl:Definitions elementos partnerLinkType
para o sistema COB (Fantinato, 2007). . . . . . . . . . . . . . . . . . . . . 81
5.20 Contrato eletrˆonico - se¸c˜ao: wsag:Terms para o sistema COB, Parte I
(Fantinato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.21 Contrato eletrˆonico - se¸c˜ao: wsag:Terms para o sistema COB, Parte II
(Fantinato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.22 Contrato eletrˆonico - se¸c˜ao: bpel:Process (Fantinato, 2007). . . . . . . . . . 84
5.23 Contrato eletrˆonico - se¸c˜ao: BPEL:Process elementos partnerLink e vari-
able (Fantinato, 2007). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.24 Compara¸c˜ao entre a RofPN e a abordagem de Fantinato (2007). . . . . . . 87
xi
xii
Lista de Siglas
BP: Business Process
BPM: Business Process Management
BPMN: Business Process Modeling Notation
BPMS: Business Process Management System
LPS: Linha de Produto de Software
1
PN: Processo de Neg´ocio
2
SOA: Arquitetura Orientada a Servi¸cos
3
SOAP: Protocolo da arquitetura orientada a servi¸cos
4
SW: Servi¸cos Web
5 6
UDDI: Universal Description, Discovery, and Integration
WS-BPEL: Business Process Execution Language for Web Services
WSDL: Web Service Definition
1
Do Inglˆes Software Product Line(SPL)
2
Do Inglˆes Business Process(BP)
3
Do Inglˆes Service Oriented Architecture
4
Do Inglˆes Service Oriented Architecture Protocol
5
Do Inglˆes Web Service
6
Tamb´em denominado de servi¸cos eletrˆonicos em algumas bibliografias
xiii
xiv
Cap
´
ıtulo
1
Introdu¸c˜ao
1.1 Contexto e Motiva¸c˜ao
Com o crescente aumento da complexidade dos neg´ocios, os sistemas de informa¸c˜ao neces-
sitam responder `as novas especifica¸c˜oes requeridas pelas organiza¸c˜oes. Uma das exigˆencias
das organiza¸c˜oes ´e a troca de informa¸c˜oes inter-organizacionais e a utiliza¸c˜ao de servi¸cos.
Portanto, as aplica¸c˜oes corporativas necessitam comunicar-se trocando um grande volume
de informa¸c˜oes, apoiadas pelo estabelecimento de um acordo m´utuo (Weske, 2007). O
estabelecimento do acordo m´utuo ´e realizado por interm´edio de contratos eletrˆonicos
que descrevem os servi¸cos contratados e as responsabilidades e direitos de cada uma das
organiza¸c˜oes parceiras (Fantinato, 2007). A comunica¸c˜ao inter-organizacional atrav´es
dos sistemas de informa¸c˜ao encontra dificuldades quando a tecnologia utilizada torna-se
heterogˆenea. Por´em, atualmente, com o advento da Arquitetura Orientada a Servi¸cos
(SOA) esta comunica¸c˜ao tornou-se poss´ıvel (Alonso, 2004).
SOA ´e um modo de projetar sistemas de software por interm´edio da publica¸c˜ao e iden-
tifica¸c˜ao de interfaces (Alonso, 2004). SOA ´e uma arquitetura utilizada para disponibilizar
servi¸cos baseada na troca de mensagens que objetiva um melhor reaproveitamento dos
servi¸cos garantindo agilidade na composi¸c˜ao de servi¸cos, menor custo e maior facilidade
de manuten¸c˜ao.
Servi¸cos Web s˜ao definidos como componentes de software auto-descritivos que auxi-
liam na composi¸c˜ao de aplica¸c˜oes. Servi¸cos Web s˜ao vistos como aplica¸c˜oes acess´ıveis
por outras aplica¸c˜oes por meio da Web e que podem ser combinadas para desempenhar
1
2 1. Introdu¸c˜ao
um processo de neg´ocio (Alonso, 2004; Leymann et al., 2002). A associa¸c˜ao de SOA com
servi¸cos Web resulta na tecnologia de servi¸cos web. Esta tecnologia consiste de protocolos
de mensagens e padr˜oes para descri¸c˜ao e descoberta de servi¸cos, tornando a interliga¸c˜ao
de componentes de servi¸co gerenci´avel (Ort, 2005).
Um processo de neg´ocio ´e um conjunto de procedimentos ou atividades realizadas
coordenadamente em uma organiza¸c˜ao para atingir o objetivo do neg´ocio. Cada processo
de neg´ocio ´e realizado por uma ´unica organiza¸c˜ao, mas ele pode interagir com processos
de neg´ocio realizados por outras organiza¸c˜oes (Leymann e Altenhuber, 1994; Sadtler e
Kovari, 2004; Weske, 2007). A combina¸c˜ao de processos de neg´ocio com servi¸cos Web
permite a cria¸c˜ao de processos de neg´ocio que s˜ao compostos por servi¸cos Web (Garcia,
2007). A composi¸c˜ao destacada permite o pensamento do reuso de processos de neg´ocio
e dos servi¸cos que os comp˜oem, principalmente, porque SOA foi criado pensando-se em
reuso (Leymann e Altenhuber, 1994).
Por interm´edio de pesquisas sobre reuso de processos de neg´ocio foi encontrado em
reuso de workflow o conceito de linha de produto de software como uma op¸c˜ao para inserir
o reuso em processos de neg´ocio (Kang et al., 1998).
Linha de Produto de Software (LP) pode ser definida como um conjunto de sistemas
que compartilham aspectos comuns e vari´aveis. Estes aspectos s˜ao denominados variabi-
lidades e s˜ao gerenci´aveis de modo a satisfazer as necessidades de um dom´ınio espec´ıfico
(Gimenes e Travassos, 2002). O resultado final de uma LP s˜ao os produtos finais -
softwares constru´ıdos utilizando os recursos dispon´ıveis na LP. Este conjunto de produtos
desenvolvidos comp˜oem a fam´ılia de produtos de uma LP (Sugumaran et al., 2006).
A pesquisa realizada ´e parte do projeto denominado InfraPro que objetiva a cria¸c˜ao de
uma infra-estrutura de apoio a modelagem e execu¸c˜ao de processo de neg´ocio baseado nos
preceitos de reutiliza¸c˜ao (Gimenes, 2006). Portanto, os resultados obtidos com a pesquisa
ser˜ao integrados ao projeto.
A proposta foi desenvolvida utilizando-se como base dois trabalhos:
• Um processo de gerenciamento de variabilidades para linha de produto
de software Oliveira Junior (2005): aborda os conceitos de LP propondo a uti-
liza¸c˜ao de um processo de gerenciamento de variabilidades que utiliza os diagramas
de classes e casos de uso da UML na sua modelagem e o modelo de caracter´ısticas.
• Uma abordagem baseada em caracter´ısticas para o estabelecimento de
contratos eletrˆonicos para servi¸cos Web Fantinato (2007): prop˜oe uma
estrutura¸c˜ao de linha de produto para contratos eletrˆonicos utilizando o modelo
1.2 Objetivos 3
de caracter´ısticas para a modelagem de servi¸cos Web e termos de qualidade de
software e as variabilidades encontradas nos mesmos.
1.2 Objetivos
As vantagens de LP, principalmente, quanto ao reuso motivaram a investiga¸c˜ao de sua
aplica¸c˜ao em PN compostos por servi¸cos Web. Portanto, este trabalho tem como objetivo
aplicar os conceitos e diretrizes de LP para gerenciar os aspectos comuns e as variabilidades
encontradas em processos de neg´ocio e seus servi¸cos Web, possibilitando uma maior
reutiliza¸c˜ao dos processos de neg´ocio e dos servi¸cos que os comp˜oem.
A abordagem proposta possui como base os processos propostos por Oliveira Junior
(2005) e Fantinato (2007). Contudo, o problema de reuso de processos de neg´ocio n˜ao
foi abordado nestes trabalhos. No presente trabalho ´e proposto uma abordagem para
reutiliza¸c˜ao de PN aplicando os conceitos de LP para o gerenciamento de variabilidades
visando permitir o reuso de processos de neg´ocio e SW.
´
E proposta, tamb´em, uma
representa¸c˜ao de variabilidades em diagrama de atividades para modelar os processos
de neg´ocio. A abordagem proposta ´e utilizada no momento da contrata¸c˜ao dos processos
de neg´ocio e SW e n˜ao no momento do desenvolvimento.
Em s´ıntese, os elementos que compor˜ao a abordagem proposta s˜ao:
• A defini¸c˜ao de um conjunto de passos a serem seguidos para garantir uma estrutura
de linha de produto que permita a reutiliza¸c˜ao de processos de neg´ocio;
• A representa¸c˜ao de variabilidades de processos de neg´ocio utilizando-se do diagrama
de atividades da UML;
1.3 Organiza¸c˜ao do Trabalho
O segundo cap´ıtulo apresenta a fundamenta¸c˜ao te´orica sobre processos de neg´ocio, servi¸cos
Web e contratos eletrˆonicos. No terceiro cap´ıtulo ´e apresentado a fundamenta¸c˜ao te´orica
sobre reutiliza¸c˜ao e linha de produtos de software. Os assuntos abordados nos dois
cap´ıtulos de fundamenta¸c˜ao te´orica formam a base para o desenvolvimento da abordagem
proposta.
A abordagem para reutiliza¸c˜ao de PN e representa¸c˜ao de variabilidades de PN em
diagramas de atividades ´e proposta no cap´ıtulo 4. No cap´ıtulo 5 ´e apresentado um exemplo
de aplica¸c˜ao da abordagem proposta para verificar a validade por interm´edio da aplica¸c˜ao
da mesma no dom´ınio do processo de neg´ocio de operadoras de telecomunica¸c˜oes. O sexto
4 1. Introdu¸c˜ao
cap´ıtulo apresenta conclus˜oes e resultados obtidos com o desenvolvimento do trabalho de
pesquisa e as perspectivas futuras quanto ao assunto. Finalmente, o cap´ıtulo 7 apresenta
as referˆencias bibliogr´aficas utilizadas no trabalho de pesquisa.
Cap
´
ıtulo
2
Processo de Neg´ocio, Servi¸cos Web e
Contrato Eletrˆonico
2.1 Considera¸c˜oes Iniciais
O cap´ıtulo apresenta os conceitos necess´arios para o posterior entendimento da abordagem
proposta nesta disserta¸c˜ao. O cap´ıtulo est´a dividido em se¸c˜oes que abordam os assuntos
pesquisados, referentes a processo de neg´ocio e as tecnologias envolvidadas, durante o
desenvolvimento da pesquisa do mestrado. A primeira se¸c˜ao apresenta a arquitetura
SOA
1
. Na segunda se¸c˜ao, s˜ao apresentados a tecnologia de servi¸cos web e os padr˜oes que
comp˜oem as camadas desta tecnologia. A terceira se¸c˜ao aborda o conte´udo de processos
de neg´ocio. Na ´ultima se¸c˜ao ´e apresentado as considera¸c˜oes finais deste cap´ıtulo.
2.2 Arquitetura Orientada a Servi¸cos
SOA ´e uma arquitetura cuja fun¸c˜ao ´e coordenar o relacionamento entre as principais car-
acter´ısticas de servi¸cos de modo a oferecer apoio dinˆamico `a busca e ao uso automatizado
dos servi¸cos (Abinader e Lins, 2006). Esses servi¸cos podem estar dispon´ıveis em uma rede
local ou na Web (Ort, 2005).
As caracter´ısticas principais de SOA compreendem (Abinader e Lins, 2006): a local-
iza¸c˜ao, a organiza¸c˜ao e a especifica¸c˜ao dos servi¸cos. A localiza¸c˜ao dos servi¸cos possibilita
1
Do Inglˆes Service-oriented architecture
5
6 2. Processo de Neg´ocio, Servi¸cos Web e Contrato Eletrˆonico
a busca para atender a crit´erios de neg´ocios necess´arios. A organiza¸c˜ao de servi¸cos busca
disponibilizar informa¸c˜oes a fim de que o requisitante do servi¸co consiga identificar o
que realmente o servi¸co oferece. Por fim, a especifica¸c˜ao dos servi¸cos inclui os formatos,
protocolos e quest˜oes t´ecnicas, para que os servi¸cos sejam obtidos corretamente. As
arquiteturas SOA s˜ao baseadas em trˆes componentes: o cliente (service requester ), o
provedor (service provider) e o registro (service registry).
O uso de SOA acelera o processo de desenvolvimento de aplica¸c˜oes e faz com que as
aplica¸c˜oes se adaptem `as mudan¸cas de software. As mudan¸cas e adapta¸c˜oes s˜ao permitidas
atrav´es das caracter´ısticas da organiza¸c˜ao da arquitetura que permite (Ort, 2005):
• Reutiliza¸c˜ao: a reutiliza¸c˜ao de servi¸cos feitos para outras aplica¸c˜oes diminui o
custo e o tempo de desenvolvimento. Por´em, alguns obst´aculos s˜ao considerados
tais como: as singularidades de cada aplica¸c˜ao, c´odigo em diferentes linguagens,
diferentes ambientes de execu¸c˜ao, diferentes interfaces e protocolos. Contudo, SOA
permite a reutiliza¸c˜ao por interm´edio do reuso do tipo caixa preta. O reuso caixa
preta visa eliminar a necessidade do conhecimento da implementa¸c˜ao do servi¸co,
pois o reuso d´a-se atrav´es da utiliza¸c˜ao de interfaces de comunica¸c˜ao com o servi¸co
que padroniza a comunica¸c˜ao.
• Interoperabilidade: consiste na comunica¸c˜ao entre clientes e servi¸cos, n˜ao impor-
tando a plataforma que estes est˜ao executando. Os padr˜oes de Servi¸cos Web s˜ao
respons´aveis para que a comunica¸c˜ao seja interoper´avel.
• Escalabilidade: SOA permite que os sistemas sejam escal´aveis, sendo assim, o
crescimento ´e organizado e n˜ao afeta o funcionamento dos elementos pr´e-existentes.
• Adapta¸c˜ao a mudan¸cas: a facilidade de integrar e remover novos servi¸cos por
interm´edio da utiliza¸c˜ao de interfaces de comunica¸c˜ao permite que os sistemas
consigam adaptar-se a mudan¸cas com maior facilidade. A utiliza¸c˜ao de um servi¸co
ocorre como descrito nos itens abaixo.
1. O cliente acessa o registro de servi¸cos requisitando os dados de identifica¸c˜ao
do servidor e da interface de comunica¸c˜ao com o servi¸co.
2. O registro responde dando uma identifica¸c˜ao para o servidor que implementa
a interface do servi¸co
3. O cliente acessa o servi¸co utilizando a interface
2.3 Tecnologia de Servi¸cos Web 7
2.3 Tecnologia de Servi¸cos Web
Segundo Clement (2004), Servi¸cos Web s˜ao caracterizados como aplica¸c˜oes auto-suficientes,
modulares, orientadas `a internet e com interfaces padronizadas. O objetivo principal
dos servi¸cos Web ´e estruturar a intera¸c˜ao entre servi¸cos de maneira que computadores
gerenciem esta intera¸c˜ao atrav´es dos conceitos de COS (Computa¸c˜ao Orientada a Servi¸cos)
e implementados sobre a arquitetura orientada a servi¸cos apresentada na se¸c˜ao ??. A as-
socia¸c˜ao de SOA com servi¸cos Web resulta na tecnologia de servi¸cos web. Esta tecnologia
consiste de protocolos de mensagens e padr˜oes para descri¸c˜ao e descoberta de servi¸cos
Web (Alonso, 2004). Esses protocolos e padr˜oes s˜ao baseados na linguagem XML
2
. A
Figura 2.1 ilustra a estrutura da tecnologia de servi¸cos Web.
Figura 2.1: Estrutura da tecnologia de servi¸cos Web. (Garcia, 2007)
A tecnologia de servi¸cos Web ´e dividida em camadas conforme segue:
• Camada de Comunica¸c˜oes ou transporte: representa os formatos e os protocolos que
permitem a conex˜ao com o servi¸co.
• Camada de Descri¸c˜oes: linguagem padr˜ao para a descri¸c˜ao de servi¸cos Web. A
camada descreve o contrato de servi¸co que cont´em informa¸c˜oes como as opera¸c˜oes
e os parˆametros que o servi¸co necessita para se comunicar.
• Camada de busca: implementa o mecanismo respons´avel por encontrar um servi¸co
nos reposit´orios e sua descri¸c˜ao.
A Figura 2.2 ilustra o modelo de servi¸cos web b´asico onde os provedores de servi¸co
publicam seus servi¸cos no reposit´orio de servi¸cos por interm´edio da camada de descri¸c˜oes
e transporte (passo 1). Os clientes procuram os servi¸cos nos reposit´orios utilizando a
2
Do Inglˆes Extensible Markup Language
8 2. Processo de Neg´ocio, Servi¸cos Web e Contrato Eletrˆonico
camada de busca e descri¸c˜oes para contrat´a-los(passo 2). Ap´os a contrata¸c˜ao do servi¸cos o
mesmo ´e invocado para utiliza¸c˜ao realizando o passo 3 utilizando a camada de transporte.
Figura 2.2: Modelo de servi¸cos Web b´asico. (Garcia, 2007)
As se¸c˜oes subsequentes apresentam os principais protocolos e padr˜oes das camadas da
tecnologia de servi¸cos Web. S˜ao eles: WSDL, UDDI e SOAP
2.3.1 WSDL
Segundo Abinader e Lins (2006), WSDL ´e uma linguagem utilizada para descrever servi¸cos
Web de modo a informar ao consumidor: o que o servi¸co executa, como invocar o
servi¸co e como diferenciar o servi¸co dos similares dispon´ıveis. As descri¸c˜oes WSDL tˆem
como principal fun¸c˜ao permitir que o consumidor conhe¸ca, primeiramente, os servi¸cos
dispon´ıveis para depois selecion´a-los e utiliz´a-los de forma autom´atica, sem que seja
necess´aria a interven¸c˜ao ou contato com o autor do servi¸co. A descri¸c˜ao de um servi¸co
Web busca explicitar detalhes da interface, os m´etodos dispon´ıveis, as assinaturas dos
m´etodos, a localiza¸c˜ao, o protocolo de invoca¸c˜ao e os valores retornados.
Em um documento WSDL, dois tipos de descri¸c˜ao devem ser considerados: a abstrata
e a concreta. A abstrata refere-se `a descri¸c˜ao de servi¸cos em n´ıvel de aplica¸c˜ao, e a
concreta s˜ao informa¸c˜oes direcionadas aos consumidores para o acesso ao servi¸co.
A descri¸c˜ao em n´ıvel de aplica¸c˜ao ´e constitu´ıda dos elementos (Abinader e Lins, 2006):
• portType: se¸c˜ao de mensagens para descrever as fun¸c˜oes de assinatura, como nome
da opera¸c˜ao, parˆametros de entrada e sa´ıda;
• operations: representa a intera¸c˜ao particular com o servi¸co e descreve as mensagens
de entrada e sa´ıda;
• message: representa os dados trocados em uma transmiss˜ao de mensagem;
• types: cont´em tipos de defini¸c˜oes independentes da linguagem e da plataforma;
2.3 Tecnologia de Servi¸cos Web 9
A descri¸c˜ao em n´ıvel concreto cont´em a especifica¸c˜ao de implementa¸c˜ao para o servi¸co
Web. Para esta descri¸c˜ao, dois elementos XML s˜ao importantes: Bindings e Service.
Bindings define como o servi¸co ser´a acessado na rede e, tamb´em, qual o protocolo uti-
lizado. Service adiciona informa¸c˜ao espec´ıfica ao documento indicando onde o servi¸co
est´a localizado para acesso, isto ´e, o endere¸co do servi¸co na rede.
2.3.2 UDDI
Ap´os os servi¸cos serem definidos e descritos em WSDL ´e necess´ario public´a-los para que as
organiza¸c˜oes possam utiliz´a-los. O padr˜ao UDDI ´e, portanto, empregado para publicar e
encontrar servi¸cos Web em um reposit´orio de descri¸c˜oes (Leymann et al., 2002). O UDDI ´e
um framework que define um modelo de dados em XML e SOAP para que API s registrem
e descubram informa¸c˜oes de servi¸cos Web (NewComer, 2002). UDDI ´e baseado em XML e
provˆe uma infra-estrutura para integrar informa¸c˜oes em ambientes de servi¸cos Web tanto
para servi¸cos dispon´ıveis publicamente quanto para servi¸cos expostos internamente em
organiza¸c˜oes. O diret´orio ou reposit´orio de descri¸c˜oes oferece uma infra-estrutura para
integrar e compartilhar informa¸c˜oes sobre a localiza¸c˜ao e uso de servi¸cos por meio de
registros respons´aveis por fornecer informa¸c˜oes sobre o servi¸co (Alonso, 2004). UDDI
oferece aos consumidores de Servi¸cos Web a infra-estrutura para localizar provedores, os
servi¸cos disponibilizados por eles e as interfaces que devem ser utilizadas para interagir
com os servi¸cos.
O padr˜ao UDDI permite os seguintes tipos de reposit´orios (Leymann et al., 2002):
• P´ublico: provˆe acesso aberto aos servi¸cos registrados;
• Privado: utilizado por organiza¸c˜oes de modo fechado, por um firewall, para apoiar
a integra¸c˜ao de suas pr´oprias aplica¸c˜oes internas.
• Compartilhado: utilizado por um grupo limitado de organiza¸c˜oes (parceiros de
neg´ocio) para apoiar a integra¸c˜ao de aplica¸c˜oes entre os parceiros.
Um registro UDDI, fornece informa¸c˜oes tais como: nome do servi¸co, breve descri¸c˜ao
do que ele faz e a descri¸c˜ao da interface para acessar o servi¸co (Ort, 2005). Segundo
Chen et al. (2006), um registro UDDI ´e constitu´ıdo por trˆes grandes partes ou divis˜oes:
as p´aginas brancas, as p´aginas amarelas e as p´aginas verdes. Nas p´aginas brancas, os
consumidores encontram informa¸c˜oes das organiza¸c˜oes que oferecem os servi¸cos como
telefone, e-mail e at´e mesmo endere¸co. Usando estas p´aginas brancas como cat´alogos,
os clientes podem encontrar servi¸cos Web oferecidos por um certo neg´ocio. As p´aginas
10 2. Processo de Neg´ocio, Servi¸cos Web e Contrato Eletrˆonico
amarelas incluem informa¸c˜ao de classifica¸c˜ao baseada na taxonomia padr˜ao da ind´ustria
ou segmento da qual a empresa e os servi¸cos por ela oferecidos fazem parte. Nas p´aginas
verdes, encontra-se uma lista completa dos servi¸cos oferecidos descritos por extenso.
2.3.3 SOAP
SOAP (Simple Object Access Protocol ) ´e um protocolo b´asico de comunica¸c˜ao entre o
cliente e os servi¸cos, possibilitando a comunica¸c˜ao entre servi¸cos Web. SOAP utiliza
a linguagem XML para permitir a troca de informa¸c˜oes em um ambiente distribu´ıdo
e descentralizado oferecendo um formato de mensagem comum para a troca de dados.
O formato do procolo SOAP define caracter´ısticas como: formato da mensagem para
comunica¸c˜ao, forma de intera¸c˜ao entre as partes (invoca¸c˜ao e resposta).
´
E importante
relatar que SOAP n˜ao define um novo protocolo de comunica¸c˜ao, mas trabalha sobre os
protocolos existentes como o HTTP para o transporte de dados na internet (Leymann et
al., 2002)(Abinader e Lins, 2006).
A mensagem SOAP ´e, basicamente, um envelope cuja fun¸c˜ao ´e indicar ao receptor
onde come¸ca e onde termina a mensagem. Uma mensagem SOAP possui os seguintes
componentes (Ort, 2005):
• Um elemento obrigat´orio para a identifica¸c˜ao de mensagens SOAP;
• Um cabe¸calho (header ) opcional que cont´em informa¸c˜oes que podem ser processadas
por n´os intermedi´arios;
• Um corpo (Body) obrigat´orio que possui a mensagem sendo transmitida.
A mensagem SOAP pode possuir dois tipos de intera¸c˜ao (Abinader e Lins, 2006)(Ort,
2005):
• Documento (document-style): mensagens SOAP s˜ao utilizadas para transportar os
documentos entre as partes ap´os o estabelecimento de um acordo entre as partes
sobre a estrutura dos documentos a serem trocados;
• Chamada de procedimento remoto (RPC-style): uma mensagem SOAP encapsula
uma requisi¸c˜ao enquanto outra encapsula a resposta para a requisi¸c˜ao. A men-
sagem de requisi¸c˜ao possui a chamada do procedimento, especificando o nome e os
parˆametros de entrada. A mensagem de resposta inclui os resultados e os parˆametros
de sa´ıda.
2.4 Processo de Neg´ocio 11
O comportamento de um n´o, ao enviar, receber ou ambos, com rela¸c˜ao `a mensagem
SOAP, ´e denominado modelo de processamento SOAP (Abinader e Lins, 2006). Al´em
do emissor e do receptor, existe o papel do n´o intermedi´ario, sendo assim, SOAP possui
trˆes categorias de n´os. Em resumo, uma mensagem SOAP sai do remetente e a cada
n´o que ela chega, identifica-se e ´e processada. As entradas do Header da mensagem
permitem verificar se a mensagem ´e destinada ao n´o atual; caso n˜ao seja destinada a ele
(n´o intermedi´ario), a mensagem ´e enviada adiante; caso seja o destino, deve-se processar
o conte´udo do elemento Body.
2.4 Processo de Neg´ocio
A representa¸c˜ao do conhecimento sobre uma organiza¸c˜ao ´e uma atividade que requer a
representa¸c˜ao de v´arios aspectos de maneira coerente e integrada (Caetano et al., 2007).
Organiza¸c˜oes, tipicamente, descrevem como os processos de neg´ocio devem ser realizados,
principalmente, os que representam uma rotina complexa de trabalho envolvendo muitas
pessoas e que s˜ao frequentemente realizados (Leymann e Altenhuber, 1994). Processos
de neg´ocio s˜ao definidos como um conjunto de atividades invocadas e executadas em
uma sequˆencia espec´ıfica e coordenada para atingir as metas do neg´ocio em um ambiente
t´ecnico e organizacional (Weske, 2007). Um processo de neg´ocio deve definir a sequˆencia
do fluxo de dados, os requisitos de intera¸c˜ao humana, como os eventos externos s˜ao
controlados e como realizar o processamento (Sadtler e Kovari, 2004). Um processo ´e
definido por meio da descri¸c˜ao de regras, atividades e recursos, e executado por interm´edio
da invoca¸c˜ao de servi¸cos de neg´ocio existentes (Garcia, 2007). Cada processo de neg´ocio
´e realizado por uma organiza¸c˜ao, mas ele pode interagir com processos realizados por
outras organiza¸c˜oes (Weske, 2007).
Com o objetivo de garantir vantagens competitivas, as organiza¸c˜oes est˜ao formando
organiza¸c˜oes virtuais onde os processos de neg´ocio s˜ao compostos de processos inter
organizacionais gerenciados pelas organiza¸c˜oes envolvidas (Garcia, 2007). A qualidade
de um processo de neg´ocio passa, ent˜ao, a influenciar no desempenho da empresa necessi-
tando assim de um gerenciamento. A atividade de gerenciamento de processo de neg´ocio
torna-se, portanto, uma atividade importante nestas organiza¸c˜oes (Leymann e Altenhu-
ber, 1994). O gerenciamento de processo de neg´ocio (BPM) ´e definido como um apoio para
o processo de neg´ocio utilizando m´etodos, t´ecnicas e softwares para projetar, administrar,
realizar e analisar os processos operacionais envolvendo humanos, organiza¸c˜oes, aplica¸c˜oes,
documentos e outros recursos de informa¸c˜ao (Leymann e Altenhuber, 1994; Weske, 2007).
O gerenciamento de processos de neg´ocio ´e realizado por um sistema de gerenciamento
12 2. Processo de Neg´ocio, Servi¸cos Web e Contrato Eletrˆonico
de processos de neg´ocio (BPMS). O BPMS ´e um sistema de software gen´erico que deve
realizar as atividades de defini¸c˜ao, execu¸c˜ao, manuten¸c˜ao, monitoramento e an´alise para
melhorias no processo de neg´ocio (Aalst et al., 2003).
Segundo Garcia (2007), a gerencia de processos de neg´ocio cumpre o ciclo de vida
representado na figura 2.3. O ciclo de vida inicia-se realizando a defini¸c˜ao do processo de
automatiza¸c˜ao (projeto). Em seguida a defini¸c˜ao ´e registrada em um sistema de geren-
ciamento de processos de neg´ocio (configura¸c˜ao) para ent˜ao ser executado. A execu¸c˜ao
inicia-se a com cria¸c˜ao de uma instˆancia. Ap´os a execu¸c˜ao s˜ao apresentados diagn´osticos
baseados nos resultados da execu¸c˜ao com a finalidade de aprimorar o processo de neg´ocio.
Figura 2.3: Ciclo de vida de gerencia de processo de neg´ocio. (Garcia, 2007)
Com o intuito de tornar os processos de neg´ocio inter-organizacionais, surge a abor-
dagem de processos de neg´ocio compostos por servi¸cos Web. Nesta abordagem, os pro-
cessos de neg´ocio s˜ao compostos por servi¸cos oferecidos por parceiros de neg´ocio que s˜ao
contratados para serem utilizados ap´os dispon´ıveis em um reposit´orio de processos de
neg´ocio e servi¸cos Web (Garcia, 2007).
OS PN s˜ao modelados pela linguagem WS-BPEL para descrever e compor o com-
portamento dos processos de neg´ocio. Esta linguagem, por ser padronizada, garante a
portabilidade e interoperabilidade dos processos de neg´ocio. Um processo especificado
em WS-BPEL mostra a intera¸c˜ao entre os parceiros que podem interagir de maneira
ass´ıncrona e s´ıncrona por meio da troca de mensagens. Tal processo ´e composto pelos
seguintes elementos: PartnerLinks (parceiros), vari´aveis, FaultHandlers (cabe¸calho de
falhas) e Activities (atividades) (Fantinato, 2007).
• parceiros: define os parceiros que interagem com o processo de neg´ocio durante
toda a execu¸c˜ao identificando a funcionalidade que deve ser oferecida por cada
parceiro do servi¸co;
2.5 Contratos Eletrˆonicos 13
• vari´aveis: define as vari´aveis de dados usadas pelo processo de neg´ocio;
• cabe¸calho de falhas: cont´em os tratadores de falhas que definem as atividades a
serem executadas em resposta as falhas resultantes da invoca¸c˜ao de servi¸cos;
• atividades: cont´em a descri¸c˜ao do comportamento normal para a execu¸c˜ao do
processo de neg´ocio.
2.5 Contratos Eletrˆonicos
A necessidade de realiza¸c˜ao de processos organizacionais de modo ´agil e a evolu¸c˜ao da
internet permitiram que aplica¸c˜oes pudessem ser disponibilizadas em formato de servi¸cos
para serem utilizadas por v´arias organiza¸c˜oes. Contudo, a realiza¸c˜ao destes servi¸cos
por outras organiza¸c˜oes inclui a necessidade de um estabelecimento de regras para o
fornecimento e o consumo destes servi¸cos (Garcia, 2007).
Contratos eletrˆonicos s˜ao documentos modelados, especificados, executados, controla-
dos e monitorados por sistemas de software para para descrever detalhes e/ou regras sobre
o fornecimento e consumo de servi¸cos eletrˆonicos pelas partes interessadas. As obriga¸c˜oes
das partes envolvidas nos contratos devem ser deixadas claras durante o estabelecimento
do contrato. Os contratos poder˜ao incluir, tamb´em, os atributos de qualidade dos servi¸cos
a serem contratados (QoS). Os contratos eletrˆonicos possuem elementos que descrevem
as partes, responsabilidades e atividades a serem contratadas que devem ser realizadas
durante o ciclo de vida do contrato. (Fantinato, 2007).
O ciclo de vida de contratos eletrˆonicos inicia-se com o desenvolvimento dos servi¸cos
a serem contratados. Logo ap´os o desenvolvimento, os servi¸cos s˜ao disponibilizados para
que sejam buscados e descobertos pelas organiza¸c˜oes interessadas em utiliz´a-los. Ap´os
a descoberta ´e realizado a negocia¸c˜ao para o estabelecimento do contrato eletrˆonico que
regulamentar´a a utiliza¸c˜ao dos servi¸cos contratados. Por fim, o ciclo de vida termina
com a realiza¸c˜ao do processo de neg´ocio que executa os servi¸cos eletrˆonicos cumprindo os
termos estabelecidos no contrato (Fantinato, 2007).
Segundo Fantinato (2007), os elementos mais comuns dos contratos eletrˆonicos s˜ao:
1. partes: apresentam os parceiros envolvidos no contrato eletrˆonico e os pap´eis
exercidos por eles;
2. atividades: descrevem os servi¸cos a serem executados por meio da realiza¸c˜ao do
contrato eletrˆonico;
14 2. Processo de Neg´ocio, Servi¸cos Web e Contrato Eletrˆonico
3. cl´ausulas contratuais: descrevem as responsabilidades (restri¸c˜oes) a serem cumpri-
das pelas partes durante a execu¸c˜ao das atividades contratadas.
2.5.1 Uma abordagem baseada em caracter´ısticas para o estabele-
cimento de contratos eletrˆonicos para servi¸cos Web
Nesta subse¸c˜ao ´e apresentado a abordagem baseada em caracter´ısticas para o estab-
elecimento de contratos eletrˆonicos para servi¸cos Web prospota por Fantinato (2007) e
utilizada como base para o desenvolvimento da proposta a ser apresentada nesta dis-
serta¸c˜ao de mestrado. O objetivo da abordagem ´e reduzir a complexidade durante
o estabelecimento de contratos eletrˆonicos para servi¸cos Web, melhorar a estrutura e
aumentar a reutiliza¸c˜ao dos servi¸cos Web e informa¸c˜oes dos contratos eletrˆonicos.
A abordagem utiliza-se de modelo de caracter´ısticas para representar os servi¸cos
eletrˆonicos e seus n´ıveis de QoS de forma gen´erica. Os modelos de caracter´ısticas orienta
atrav´es de suas configura¸c˜oes o processo de estabelecimento de contratos eletrˆonicos entre
as partes envolvidas. Cada configura¸c˜ao do modelo de caracter´ıstica apresenta o conjunto
de servi¸cos, n´ıveis de QoS conhecidos pelas partes envolvidas e que ser˜ao contratados
para utiliza¸c˜ao. Os servi¸cos gen´ericos ap´os contratados para utiliza¸c˜ao s˜ao mapeados
para servi¸cos Web espec´ıficos com o intuito de serem executados. A abordagem baseia-se
nos conceitos de linha de produto de software e ´e derivada do m´etodo FORM, sendo
dividida em dois ciclos de vida que possuem 5 est´agios (Fantinato, 2007; Kang et al.,
1998).
O primeiro ciclo de vida, denominado desenvolvimento do molde, ´e respons´avel por
desenvolver o molde do contrato eletrˆonico e o desenvolvimento e publica¸c˜ao dos servi¸cos
Web por interm´edio do desenvolvimento do modelo de caracter´ısticas, molde de contrato
eletrˆonico e servi¸cos Web. este ciclo de vida e suas atividades s˜ao realizados uma ´unica
vez para um dom´ınio de contrato eletrˆonico envolvendo o mesmo par de organiza¸c˜oes (?).
O desenvolvimento do contrato (segundo ciclo de vida) ´e respons´avel por realizar as
configura¸c˜oes do modelo de caracter´ısticas para compor o contrato eletrˆonico final que
utilizar´a os servi¸cos e termos de QoS selecionados na configura¸c˜ao. O ciclo de vida
do desenvolvimento do contrato e suas atividades ´e realizado a cada nova instˆancia
do contrato para um mesmo dom´ınio. A Figura 2.4 ilustra o processo proposto, seus
ciclos e vida e as atividades pertencentes aos ciclos. A Figura 2.5 ilustra os artefatos
desenvolvidos durante a abordagem (posteriormente descritos) e os relacionamentos entre
eles (Fantinato, 2007).
2.5 Contratos Eletrˆonicos 15
Figura 2.4: Processo de estabelecimento de contrato eletrˆonico com base em carac-
ter´ısticas (Fantinato, 2007)
As atividades pertencentes ao processo e os ciclos de vida s˜ao (Fantinato, 2007):
• Desenvolvimento do molde
1. elabora¸c˜ao dos modelos de caracter´ısticas para servi¸cos eletrˆonicos: desen-
volvimento de modelos de caracter´ısticas para a representa¸c˜ao dos servi¸cos
eletrˆonicos e os atributos de QoS a serem contratados pelas organiza¸c˜oes;
2. cria¸c˜ao do molde de contrato eletrˆonico para seri¸cos Web: molde de contrato
com informa¸c˜oes que poder˜ao ser utilziadas em qualquer contrato eletrˆonico;
16 2. Processo de Neg´ocio, Servi¸cos Web e Contrato Eletrˆonico
3. desenvolvimento e publica¸c˜ao de servi¸cos Web: os servi¸cos eletrˆonicos repre-
sentados nos modelos de caracter´ısticas s˜ao desenvolvidos nesta atividade e
publicados para ficarem dispon´ıveis para contrata¸c˜ao e realiza¸c˜ao do processo
de neg´ocio contido no contrato;
• Desenvolvimento do contrato
1. configura¸c˜ao dos modelos de caracter´ısticas para servi¸cos eletrˆonicos: nesta
atividade os modelos de caracter´ısticas s˜ao configurados para representar os
servi¸cos e os n´ıveis de QoS que ser˜ao utilizados para a gera¸c˜ao de um con-
tato eletrˆonico em espec´ıfico para um processo de neg´ocio entre um par de
organiza¸c˜oes;
2. cria¸c˜ao da instˆancia de contrato eletrˆonico para servi¸cos Web: ap´os configu-
rado o modelo de caracter´ıstica o molde de contrato eletrˆonico ´e agora refinado
para estabelecer as defini¸c˜oes e gera¸c˜ao do contrato eletrˆonico final.
Figura 2.5: Relacionamento entre os artefatos produzidos pelo processo (Fantinato,
2007).
Os artefatos produzidos durante a abordagem s˜ao (Fantinato, 2007):
• modelo de caracter´ıstica para servi¸cos eletrˆonicos: representa atrav´es do
modelo de caracter´ıstica os servi¸cos Web e os atributos de QoS que encontra-se
dispon´ıvel para contrata¸c˜ao. O modelo de caracter´ıstica segundo (Fantinato, 2007)
deve seguir a estrutura mostrada na Figura 2.6. Onde o modelo possui os servi¸cos
eletrˆonicos e atributos de QoS que possuem as suas respectivas catacter´ısticas.
2.5 Contratos Eletrˆonicos 17
Figura 2.6: Estrtura do modelo de caracter´ısticas para servi¸cos eletrˆonicos (Fantinato,
2007).
• molde de contrato eletrˆonico para servi¸cos Web: o molde de contrato eletrˆonico
descreve os servi¸cos Web, termos de QoS e o processos de neg´ocio utilizando:
– servi¸cos Web: linguagem WSDL;
– atributos de QoS: WS-Agreement;
– processos de neg´ocio: WS-BPEL;
• servi¸cos Web: reposit´orio de servi¸cos Web j´a desenvolvidos e publicados;
• modelo de caracter´ıstica para servi¸cos eletrˆonicos configurado: configura¸c˜ao
do modelo de caracter´ıstica para representa¸c˜ao de um determinado contrato eletrˆonico
e os servi¸cos e termos de QoS selecionados para este contrato em espec´ıfico;
• contrato eletrˆonico final: contrato eletrˆonico desenvolvido por interm´edio da con-
figura¸c˜ao do modelo de caracter´ıstica e a deriva¸c˜ao do molde de contrato eletrˆonico.
Fantinato (2007) prop˜oe em seu trabalho um conjunto de ferramentas denominada
de FeatureContrat para utiliza¸c˜ao com o seus processo. A Figura 2.7 ilustra o conjunto
de ferramentas que ´e composto por seis ferramentas integradas e que oferecem apoios a
diferentes est´agio durante o desenvolvimento do processo.
18 2. Processo de Neg´ocio, Servi¸cos Web e Contrato Eletrˆonico
Figura 2.7: Arquitetura do conjunto de ferramentas FeatureContract (Fantinato, 2007).
O processo proposto por Fantinato (2007) ´e validado no trabalho por interm´edio da
aplica¸c˜ao do mesmo em um estudo de caso e ao final ´e resultado os resultados obtidos
pelo trabalho. Apresenta-se as vantagens obtidas com a realiza¸c˜ao do processo proposto.
S˜ao elas: representa¸c˜ao adequada de servi¸cos eletrˆonicos por modelos de caracter´ısticas,
melhor estrutura¸c˜ao e reuso de informa¸c˜oes envolvidas. Como desvantagens e limita¸c˜oes
destacam-se a necessidade de conhecimento de modelagem de caracter´ısticas, a hetero-
geneidade das ferramentas propostas para utiliza¸c˜ao com o processo
2.6 Projeto InfraPro
O projeto InfraPro tem como objetivo o desenvolvimento de uma infra-estrutura de apoio
a modelagem e execu¸c˜ao de processos de neg´ocio baseado nos preceitos de reutiliza¸c˜ao,
no paradigma de orienta¸c˜ao a aspectos, e na tecnologia de servi¸cos Web (Gimenes, 2006).
O projeto possui como principais objetivos:
1. A investiga¸c˜ao para aplicar os conceitos do paradigma de orienta¸c˜ao a aspectos aos
processos de neg´ocio;
2. Investigar modelos e metodologias para reutiliza¸c˜ao de processos de neg´ocio e servi¸cos
Web.
2.7 Considera¸c˜oes Finais 19
O presente trabalho de mestrado encontra-se inserido no contexto do projeto InfraPro
com o intuito de estabelecer uma abordagem que permita o reuso de processos de neg´ocio
e servi¸cos Web. Foi encontrado em reuso de workflow o conceito de linha de produto de
software como um bom candidato para aplicar em processos de neg´ocio com o intuito de
garantir o reuso. Portanto, a pr´oxima se¸c˜ao deste cap´ıtulo aborda os conceitos de LP,
suas problem´aticas e aplica¸c˜oes encontradas. A abordagem que ser´a proposta no cap´ıtulo
4 ´e desenvolvida aplicando os conceitos de LP para propor o desenvolvimento de uma
estrutura de LP para reuso de processos de neg´ocio.
2.7 Considera¸c˜oes Finais
O presente cap´ıtulo apresentou os conceitos pertinentes aos assuntos necess´arios para o
entendimento da proposta desta disserta¸c˜ao. Foi apresentado os conceitos de SW e suas
tecnologias, processos de neg´ocio, projeto InfraPro e contratos eletrˆonicos para servi¸cos
Web. Os conceitos e tecnologias apresentados s˜ao elementos base para a comunica¸c˜ao entre
servi¸cos eletrˆonicos, estabelecimento de contratos eletrˆonicos para os servi¸cos e realiza¸c˜ao
de processos de neg´ocio inter-organizacionais.
Um processo de neg´ocio ´e um conjunto de atividades realizadas em uma determinada
ordem para atingir o objetivo do neg´ocio. Os processo de neg´ocio compostos de servi¸cos
Web e regulamentado por um contrato eletrˆonico para o estabelecimento de regras que
norteiem o acordo de interesse entre os parceiros de neg´ocio. O estabelecimento de
contrato eletrˆonico ´e tido como o elemento dificultador neste acordo inter-organizacional.
O processo de Fantinato (2007) diminui a complexidade do estabelecimento de contratos
eletrˆonicos.
´
E utilizado como base (background) para as propostas a serem desenvolvidas e
apresentadas na presente disserta¸c˜ao de mestrado. Apesar das vantagens j´a mencionadas
do processo proposto por Fantinato (2007), o mesmo n˜ao desenvolve atividades que
enfatize a reutiliza¸c˜ao dos processos de neg´ocio envolvidos nos contratos eletrˆonicos.
A reutiliza¸c˜ao neste trabalho ocorre quanto aos servi¸cos eletrˆonicos, termos de QoS e
informa¸c˜oes gen´ericas do contrato. Portanto, a proposta desta disserta¸c˜ao tem o intuito
de estender a abordagem proposta por Fantinato (2007) com o objetivo de incluir uma
enfase maior na reutiliza¸c˜ao e representa¸c˜ao dos processos de neg´ocio.
O pr´oximo cap´ıtulo apresentar´a a fundamenta¸c˜ao te´orica sobre os assunto pertinentes
a linha de produto de software com o intuito de nortear o leitor quando aos conceitos
utilizados como base para a gera¸c˜ao da proposta de reutiliza¸c˜ao de processos de neg´ocio
utilizando conceitos de LP. A abordagem a ser desenvolvida ser´a inserida no contexto do
projeto InfraPro j´a descrito neste cap´ıtulo.
20 2. Processo de Neg´ocio, Servi¸cos Web e Contrato Eletrˆonico
Cap
´
ıtulo
3
Linha de Produto de Software e
Reutiliza¸c˜ao
3.1 Considera¸c˜oes Iniciais
Este cap´ıtulo apresenta os conceitos de linha de produto de software que norteiam o
desenvolvimento da abordagem proposta nesta disserta¸c˜ao de mestrado.
´
E abordado,
tamb´em, neste cap´ıtulo dois trabalhos utilizados como base para o desenvolvimento da
abordagem.
Os conceitos de linha de produto de software foi encontrado como um assunto promis-
sor para reutiliza¸c˜ao de processo de neg´ocio por interm´edio de pesquisas sobre o assunto de
reutiliza¸c˜ao de processos e reutiliza¸c˜ao de workflow. Portanto, a primeira se¸c˜ao apresenta
os conceitos b´asico e essenciais sobre reutiliza¸c˜ao incluindo uma tese de mestrado que
trata sobre reutiliza¸c˜ao de tipos de workflow utilizada como um dos trabalhos base. A
segunda se¸c˜ao apresenta os conceitos de linha de produto de software e o ´ultimo trabalho
utilizado como base para a proposta. A ´ultima se¸c˜ao apresenta as considera¸c˜oes finais
deste cap´ıtulo.
3.2 Reutiliza¸c˜ao
reutiliza¸c˜ao ou reutiliza¸c˜ao ´e definido por Kradolfer (2000) em sua tese de doutorado como
um processo de incorporar a um novo produto um produto j´a existente ou partes deste.
21
22 3. Linha de Produto de Software e Reutiliza¸c˜ao
Em seu trabalho Kradolfer (2000) aborda um metamodelo para reutiliza¸c˜ao de tipos de
Workflow em um modelo evolutivo seguindo as atividades do processo ilustrado na Figura
3.1 e descrito posteriormente.
Figura 3.1: reutiliza¸c˜ao-Based workflow Type Development (Kradolfer, 2000).
A reutiliza¸c˜ao ´e permitida por interm´edio da entrada no processo dos requisitos e
modelo de processo de neg´ocio para uma atividade no processo que localiza os tipos de
workflows que tem potencialidade de serem reutiliz´aveis. Ap´os esta sele¸c˜ao estes workflows
s˜ao analisados verificando sua completa aplicabilidade na resolu¸c˜ao do novo problema.
Caso seja completamente aplic´avel o mesmo ´e reutilizado. Caso contr´ario, duas frentes
podem ser consideradas. Na primeira o tipo de woorkflow ´e adaptado para adequar-se as
novas exigˆencias gerando, assim, uma nova vers˜ao do mesmo ou modificando o original
e integrando aos tipos workflows j´a existentes. Na segunda frente n˜ao ´e encontrado um
tipo de workflow que possa ser modificado ou reutilizado e neste caso ´e necess´ario criar
um tipo novo e integr´a-lo aos tipos j´a existentes Kradolfer (2000).
3.3 Linha de Produto de Software 23
3.3 Linha de Produto de Software
As iniciativas de componentiza¸c˜ao de software e o desenvolvimento orientado a objetos
tornaram a reutiliza¸c˜ao de software vi´avel. Com a evolu¸c˜ao destas ideias surge o modelo
de LP apresentando um deslocamento no paradigma tradicional de desenvolvimento de
software (Gimenes e Travassos, 2002).
O termo LP ´e uma referˆencia `a linha de produ¸c˜ao das ind´ustrias de manufatura
que introduziram uma revolu¸c˜ao no processo produtivo, sugerindo o desenvolvimento
sequencial de produtos por interm´edio de tarefas repetidas e executadas pelas mesmas
pessoas e com as mesmas mat´erias-primas e ferramentas de trabalho. Portanto, LP ´e
uma abordagem que usa a constru¸c˜ao sistem´atica de software baseada em uma fam´ılia
de produtos por interm´edio da reutiliza¸c˜ao de artefatos. Uma fam´ılia de produtos de
software ´e o conjunto de produtos de software com propriedades suficientemente similares
para permitir a defini¸c˜ao de uma infra-estrutura comum dos ´ıtens que os comp˜oem e a
parametriza¸c˜ao das diferen¸cas entre eles. Os membros da fam´ılia s˜ao produtos espec´ıficos
desenvolvidos de maneira sistem´atica a partir de um conjunto comum de artefatos da LP
(Gimenes, 2006).
A ideia chave de LP ´e que a maioria das aplica¸c˜oes de software desenvolvidas ´e pare-
cida, apresentando muitas igualdades ao inv´es de diferen¸cas (Sugumaran et al., 2006). Por-
tando, o objetivo das abordagens de LP ´e identificar os aspectos comuns e as variabilidades
existentes entre os artefatos de software durante o desenvolvimento objetivando a gera¸c˜ao
de produtos espec´ıficos por interm´edio da reutiliza¸c˜ao de componentes pr´e-existentes.
Variabilidades s˜ao diferen¸cas tang´ıveis, entre os produtos, que s˜ao encontradas em qual-
quer etapa do desenvolvimento de uma LP (Fantinato, 2007).
Os benef´ıcios conseguidos com a ado¸c˜ao de uma Linha de Produto podem ser classifi-
cados em (Oliveira Junior, 2005):
• Organizacionais: melhor compreens˜ao do dom´ınio por analisar v´arios produtos
pertencentes a um mesmo dom´ınio tornando o dom´ınio amplamente conhecido e
aumento da qualidade dos produtos e da confian¸ca do cliente, pois novos produtos
s˜ao criados utilizando-se de artefatos j´a testados por outro(s) produto(s) j´a em
opera¸c˜ao;
• Engenharia de software: melhor an´alise, aumento da reutiliza¸c˜ao dos artefatos,
melhor controle da qualidade dos produtos;
• Neg´ocio: redu¸c˜ao dos gastos com teste e manuten¸c˜ao.
24 3. Linha de Produto de Software e Reutiliza¸c˜ao
Segundo Sugumaran et al. (2006), implantar uma LP e estrat´egias de reutiliza¸c˜ao
em uma organiza¸c˜ao requer decis˜ao sobre investimentos, portanto o processo de ado¸c˜ao
torna-se um aspecto a ser considerado. Existem trˆes modelos de processo de ado¸c˜ao que
s˜ao frequentemente utilizados para a ado¸c˜ao de reutiliza¸c˜ao: proativo, reativo e extrativo.
Com o modelo proativo a organiza¸c˜ao faz investimentos para desenvolver componentes
para a LP e produtos s˜ao desenvolvidos utilizando esses componentes. No modelo reativo
componentes s˜ao desenvolvidos quando surge a necessidade e oportunidade n˜ao requerendo
um grande investimento. O modelo extrativo fica entre os dois modelos apresentados.
Nele os componentes podem ser desenvolvidos antecipadamente e quando necess´ario. A
abordagem extrativa ´e efetiva para organiza¸c˜oes que possuem experiˆencias acumuladas
de desenvolvimento e artefatos acumulados em um dom´ınio, por´em requer uma r´apida
mudan¸ca do modelo tradicional para o de LP.
Para mudar a maneira como as organiza¸c˜oes produzem software, segundo Clements
et al. (2006) e Clements e Northrop (2001), ´e necess´ario realizar mudan¸cas de neg´ocio,
t´ecnicas, financeiras e pessoais. Portanto, tra¸car diretrizes para adotar LP torna-se
necess´ario, pois facilita a ado¸c˜ao ao definir as metas e pr´aticas a serem alcan¸cadas de
modo cont´ınuo. As diretrizes cont´em as metas a serem alcan¸cadas dividindo-as em metas
de produto, processo e organiza¸c˜ao. As metas est˜ao ainda subdivididas para mostrar o
n´ıvel de ado¸c˜ao da organiza¸c˜ao: estabelecer contexto, estabelecer capacidade de produ¸c˜ao
e operar a LP.
O SEI
1
(Software Engineering Institute) estabelece as atividades essenciais que as
abordagens de LP devem possuir como ilustrada na Figura 3.2 (Northrop e Clements,
2007). As atividades s˜ao: o desenvolvimento do n´ucleo de artefatos, o desenvolvimento do
produto e o gerenciamento. Os trˆes c´ırculos da Figura 3.2, que representam as atividades,
est˜ao conectados para indicar que as atividades s˜ao altamente interligadas e interativas,
sendo assim, uma atividade pode influenciar nas demais (inclus˜ao de novos requisitos ou
rean´alise de algum existente).
1
www.sei.cmu.edu
3.3 Linha de Produto de Software 25
Figura 3.2: Atividades essenciais de Linha de Produto de Software (Adaptado).
(Northrop e Clements, 2007)
O Desenvolvimento do n´ucleo de artefatos, representado na figura 3.3, tem como
entrada as restri¸c˜oes do produto, restri¸c˜oes de produ¸c˜ao, estrat´egia de produ¸c˜ao, frame-
works, padr˜oes e o reposit´orio dos artefatos pr´e-existentes. Com estas informa¸c˜oes s˜ao
estabelecidos o contexto da linha de produto, o n´ucleo de artefatos e o plano de produ¸c˜ao.
O contexto da linha de produto descreve o que ela ´e capaz de produzir apresentando as
variabilidades e semelhan¸cas entre os produtos. O n´ucleo de artefatos ´e uma estrutura
que viabiliza a reutiliza¸c˜ao da arquitetura da LP e de seus componentes j´a dispon´ıveis.
Figura 3.3: Desenvolvimento do n´ucleo de artefatos. (Northrop e Clements, 2007)
26 3. Linha de Produto de Software e Reutiliza¸c˜ao
O Desenvolvimento do produto representado na figura 3.4, tem como objetivo a
partir do contexto da LP, do n´ucleo de artefatos e do plano de produ¸c˜ao, a gera¸c˜ao
de produtos de uma LP. Nesta fase ´e poss´ıvel que sejam encontrados requisitos que n˜ao
foram anteriormente especificados e, consequentemente, ser´a necess´ario atualizar o n´ucleo
de artefatos da LP, bem como o contexto da LP.
Figura 3.4: Desenvolvimento do produto. (Northrop e Clements, 2007)
O Gerenciamento da LP tem como objetivo garantir que todas as atividades t´ecnicas
sejam realizadas de acordo com um planejamento coordenado. Uma das tarefas mais
importantes ´e a cria¸c˜ao de um plano de ado¸c˜ao que descreva o estado desejado da
organiza¸c˜ao e uma estrat´egia para alcan¸car tal estado.
As atividades possuem como objetivo principal gerenciar as variabilidades existentes
em uma fam´ılia de produtos para gerar produtos espec´ıficos por interm´edio da reutiliza¸c˜ao
de artefatos pr´e-existentes. Portanto, um dos aspectos principais a serem observados ´e a
representa¸c˜ao das variabilidades e o gerenciamento das mesmas (Oliveira Junior, 2005).
Na literatura ´e poss´ıvel encontrar diversas formas de representar variabilidades den-
tre elas podemos citar: diagramas de casos de uso, diagramas de classes, diagrama
de atividades e modelos de caracter´ısticas. Modelos de caracter´ısticas s˜ao usados em
engenharia de software para capturar e gerenciar pontos em comum, e variabilidades em
fam´ılias de produto de software. Abordaremos aqui a representa¸c˜ao utilizando o modelo
de caracter´ıstica e, tamb´em, abordagens para a representa¸c˜ao utilizando o diagrama de
atividades da UML Fantinato (2007); Oliveira Junior (2005).
Modelos de carater´ısticas s˜ao normalmente organizados em diagramas hier´arquicos,
na forma de ´arvore, onde cada n´o representa uma caracter´ıstica e cada caracter´ıstica
3.3 Linha de Produto de Software 27
pode ser descrita por um conjunto de sub-caracter´ısticas Fantinato (2007). A Figura
3.5 apresenta um modelo de caracter´ısticas desenvolvido para representar os servi¸cos
disponibilizados por uma loja eletrˆonica na nota¸c˜ao proposta por Antkiewicz e Czarnecki
(2004). Os servi¸cos disponibilizados s˜ao: pagamento e entrega. As variabilidades no
servi¸cos de pagamento s˜ao apresentadas nos tipos de pagamentos dispon´ıveis (cart˜ao de
cr´edito, cart˜ao de d´ebito, boleto banc´ario) e as variabilidades no servi¸co de entrega s˜ao
os meios de entrega (mar, terra, ar).
Figura 3.5: Exemplo de Modelo de caracter´ısticas (Antkiewicz e Czarnecki, 2004)
Czarnecki et al. (2005) desenvolveram uma ferramenta para a automatiza¸c˜ao de mode-
los de caracter´ısticas denominada FeaturePlugin. A ferramenta oferece apoio `a elabora¸c˜ao
de modelos de caracter´ısticas e suas configura¸c˜oes por interm´edio de uma interface gr´afica
com o usu´ario. FeaturePlugin oferece tamb´em a op¸c˜ao de exporta¸c˜ao dos modelos de
caracter´ısticas e suas configura¸c˜oes para documentos XML. A figura 3.6 apresenta o
modelo de caracter´ısticas da figura 3.5 elaborado na ferramenta FeaturePlugin, assim
como, os significados dos s´ımbolos usados na representa¸c˜ao.
A representa¸c˜ao atrav´es do diagramas de atividades ´e estabelecida pensando-se que um
processo de neg´ocio consiste, essencialmente, de atividades que representam os servi¸cos
e os sub-processos que comp˜oem. O diagrama de atividades faz parte do conjunto de
diagramas comportamental da UML e sua principal utiliza¸c˜ao ´e representar e modelar
o fluxo de controle de atividades em software. Uma das modifica¸c˜oes da UML 2.0 foi
a compatibiliza¸c˜ao do diagrama de atividades com as linguagens de representa¸c˜ao de
processos de neg´ocio (Rumbaugh et al., 2005; Selic, 2005). At´e o presente momento
a maioria dos trabalhos sobre representa¸c˜ao de variabilidades em UML utilizam-se dos
diagramas de classes e casos de uso. Contudo, estes diagramas representam a vis˜ao
estrutural dos processos de neg´ocio e n˜ao uma vis˜ao comportamental. A vis˜ao comporta-
28 3. Linha de Produto de Software e Reutiliza¸c˜ao
Figura 3.6: Exemplo de Modelo de Caracter´ıstica no FeaturePlugin (Fantinato, 2007)
3.3 Linha de Produto de Software 29
mental permite ver o comportamento do processo de neg´ocio durante a execu¸c˜ao de seus
servi¸cos, atividades, e/ou processos (Gomaa, 2005; Oliveira Junior, 2005; Rumbaugh et
al., 2005; Selic, 2005). Com este intuito Korherr e List (2006, 2007) prop˜oem Profiles
para representa¸c˜ao de variabilidades em diagrama de atividades.
Um ponto de varia¸c˜ao, segundo Korherr e List (2006, 2007), pode ser multi-valorado
e as op¸c˜oes podem ser mutualmente exclusivas e/ou combinadas. Com o intuito de repre-
sentar este tipo de variabilidades Korherr e List (2006, 2007) criaram uma representa¸c˜ao
de variabilidades em diagramas de classes representado na Figura 3.7.
Figura 3.7: UML Profile para representa¸c˜ao de variabilidades em diagrama de classes
(Korherr e List, 2006)
Korherr e List (2006, 2007), representam variabilidades em diagramas de atividades
da UML por interm´edio dos recursos j´a dispon´ıveis no diagrama de atividades. A repre-
senta¸c˜ao das multiplicidades d´a-se por interm´edio do uso das estruturas de decis˜ao (merge,
join, fork e decision) presentes no diagrama de atividades como pode ser observado na
Figura 3.8.
30 3. Linha de Produto de Software e Reutiliza¸c˜ao
Figura 3.8: Mapeamento de variabilidades em diagrama de atividades (Korherr e List,
2006)
3.3.1 Um processo de gerenciamento de variabilidades para linha de
produto de software
Segundo Oliveira Junior (2005) a correta captura e representa¸c˜ao de variabilidades per-
mite ampliar o n´umero de produtos desenvolvido a partir de uma LP. V´arias solu¸c˜oes
para o gerenciamento de variabilidades s˜ao encontradas na literatura, por´em o que se
percebe ´e a falta de um processo que possibilite identificar, representar, delimitar, es-
colher mecanismos de implementa¸c˜ao, monitorar e rastrear as variabilidades de uma LP.
Portanto, Oliveira Junior (2005) prop˜oe em seu trabalho um processo de gerenciamento
de variabilidade para linha de produto de software.
O processo de gerenciamento de variabilidades encontra-se inserido no contexto do
processo de desenvolvimento de uma linha de produto de forma a gerenciar a linha de
produto e suas variabilidades consumindo informa¸c˜oes da LP criada e gerarando novas
informa¸c˜oes que ser˜ao utilizadas para a realiza¸c˜ao de melhorias na LP e dos produtos
a serem gerados. A Figura 3.9 permite ver o relacionamento entre o o processo de
desenvolvimento de linha de produto e os seus trˆes componentes internos, sendo um deles
o gerenciamento de variabilidades.
O processo proposto utiliza-se do diagrama de casos de uso da UML e do modelo de
caracter´ısticas como principais artefatos para identificar, delimitar e representar grafica-
mente as variabilidades. Com a identifica¸c˜ao, representa¸c˜ao e delimita¸c˜ao ´e poss´ıvel fazer
o controle e rastreamento das variabilidades para a an´alise de configura¸c˜oes de produtos
espec´ıficos. Portanto, o processo possui atividades que, em conjunto, apoiam a constru¸c˜ao
3.4 Considera¸c˜oes Finais 31
Figura 3.9: Processo de desenvolvimento de LP existente com gerenciamento de vari-
abilidade (Oliveira Junior, 2005).
de uma LP e a gerencia de suas variabilidades. Dando suporte `a gera¸c˜ao de produtos
espec´ıficos al´em de fornecerem uma vis˜ao gerencial de uma LP.
O processo proposto foi validado realizando um estudo de caso que concluiu que
o processo permite identificar e gerenciar variabilidades em LP de forma efetiva. Foi
conclu´ıdo, tamb´em, que o modelo de caracter´ıstica permitiu uma maior facilidade para a
representa¸c˜ao, identifica¸c˜ao, entendimento e gerenciamento de variabilidades.
3.4 Considera¸c˜oes Finais
Este cap´ıtulo apresentou os conceitos necess´arios para o entendimento da proposta desta
disserta¸c˜ao. Foi apresentado os conceitos de reutiliza¸c˜ao, linha de produto de software e
representa¸c˜ao de variabilidades.
As abordagens de LP, gerenciamento de variabilidades e de estabelecimento de contrato
eletrˆonicos apresentadas durante este cap´ıtulo e o cap´ıtulo de processo de neg´ocio resolvem
os seguintes problemas relacionados as necessidades observadas em processos de neg´ocio,
servi¸cos web e linha de produto a serem consideradas para o projeto InfraPro:
• gerenciamento de variabilidades em LP;
32 3. Linha de Produto de Software e Reutiliza¸c˜ao
• representa¸c˜ao de servi¸cos Web;
• gera¸c˜ao de contratos eletrˆonicos para servi¸cos Web.
Contudo, a pesquisa desenvolvida durante este trabalho observou que encontra-se em
aberto solu¸c˜oes para definir uma representa¸c˜ao de variabilidades em processos de neg´ocio
compostos por SW e, principalmente, uma solu¸c˜ao que crie uma estrutura de LP que
permita o reutiliza¸c˜ao dos processos de neg´ocio e servi¸cos Web.
O pr´oximo cap´ıtulo apresentar´a a abordagem proposta para reutiliza¸c˜ao de processos
de neg´ocio, aplicando os conceitos de linha de produto, reutiliza¸c˜ao e gerenciamento de
variabilidades com o intuito de melhorar a reutiliza¸c˜ao de processos de neg´ocio. Aplica-se
estes conceitos para fazer uma extens˜ao do processo originalmente proposto por Fantinato
(2007).
´
E apresentado ainda, a proposta de uma representa¸c˜ao de variabilidades em
processos de neg´ocio, utilizando-se do diagrama de atividades da UML, o objetivo ´e
resolver o problema da representa¸c˜ao de variabilidades em processos de neg´ocio e o
reutiliza¸c˜ao dos processos de neg´ocio.
Cap
´
ıtulo
4
RofPN - Abordagem para reutiliza¸c˜ao
de processos de neg´ocio
4.1 Considera¸c˜oes Iniciais
Com intuito de resolver os problemas apresentados nos cap´ıtulos anteriores sobre o re-
utiliza¸c˜ao de processos de neg´ocio e a representa¸c˜ao de variabilidades em diagrama de
atividades. Encontrou-se em reutiliza¸c˜ao de workflow, linha de produto de software como
principal candidato para reutiliza¸c˜ao de processo de neg´ocio. Na se¸c˜ao 4.2 ´e apresentada
uma abordagem para reutiliza¸c˜ao de processos de neg´ocio aplicando os conceitos de linha
de produto, reutiliza¸c˜ao e gerenciamento e representa¸c˜ao de variabilidades.
A abordagem apresentada juntamente com a representa¸c˜ao de variabilidades em di-
agramas de atividades (4.3), procura melhorar o Reutiliza¸c˜ao de processos de neg´ocio e
servi¸cos Web e representar a intera¸c˜ao entre os mesmos. A abordagem proposta estende a
abordagem originalmente proposta por Fantinato (2007) inserindo artefatos e atividades
que permita o Reutiliza¸c˜ao de processos de neg´ocio. A utiliza¸c˜ao da abordagem d´a-se
no momento da sele¸c˜ao e contrata¸c˜ao dos processos e dos servi¸cos e o estabelecimento
do contrato eletrˆonico que rege os compromissos das partes e n˜ao no momento do de-
senvolvimento dos mesmos. Portanto, os artefatos aqui apresentados possuem um n´ıvel
de representa¸c˜ao considerado alto para desenvolvimento, por´em ´util para entendimento,
sele¸c˜ao e contrata¸c˜ao. O intuito da abordagem ´e permitir trˆes n´ıveis de granularidade de
Reutiliza¸c˜ao que s˜ao encontrados em processos de neg´ocio e servi¸cos Web.
33
34 4. RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
O primeiro n´ıvel ´e o Reutiliza¸c˜ao integral dos processos de neg´ocio observado quando
o processo ´e reusado sem alterar as especifica¸c˜oes. A altera¸c˜ao das variabilidades, servi¸cos
contratados e/ou termos de QoS implica na instancia¸c˜ao de um novo produto na LP, n˜ao
caracterizando assim, um Reutiliza¸c˜ao integral do processo. Quando ocorre as altera¸c˜oes
d´a-se o Reutiliza¸c˜ao de partes do processo denominado Reutiliza¸c˜ao de sub-processos.
O Reutiliza¸c˜ao de sub-processos, segundo n´ıvel, acontece quando partes de processos
s˜ao reutilizadas. Por exemplo, uma empresa W que detˆem um site para vendas on-line
possui um processo que realiza a venda, cobran¸ca e recebimento fazendo chamada aos
servi¸cos das financeiras (boletos, cart˜oes de cr´edito e d´ebito). A organiza¸c˜ao Z necessita
realizar, tamb´em, as cobran¸cas dos seus servi¸cos e/ou produtos oferecidos aos clientes e
decide por contratar o sub-processo de cobran¸ca e recebimento j´a existente e dispon´ıvel
de W. Contudo, Z conFigura as variabilidades do processo de neg´ocio de W contratando
somente partes do processo que lhe interessa para integrar no seu processo de neg´ocio
realizando o Reutiliza¸c˜ao de parte do processo de W (Reutiliza¸c˜ao de sub-processo).
O terceiro n´ıvel ´e o Reutiliza¸c˜ao de servi¸cos que ocorre quando apenas um servi¸co ´e
contratado. Por exemplo, a empresa W possui em seu processo de neg´ocio servi¸cos que
realizam cobran¸ca e recebimento, vendas, compras, cadastros e consultas. Esta cole¸c˜ao
de servi¸cos define o processo de neg´ocio da organiza¸c˜ao. Um sub-processo seria a venda
e os servi¸cos que a comp˜oem. O Reutiliza¸c˜ao de apenas um servi¸co desta organiza¸c˜ao
conFiguraria a utiliza¸c˜ao apenas de um servi¸co de cobran¸ca em espec´ıfico (exemplo:
cobran¸ca por boleto banc´ario) n˜ao utilizando os demais servi¸cos de cobran¸ca dispon´ıveis.
Portanto, a se¸c˜ao 4.2 deste cap´ıtulo apresenta a abordagem para Reutiliza¸c˜ao de
processos de neg´ocio e, tamb´em, uma abordagem desenvolvida para a representa¸c˜ao de
variabilidades em diagramas de atividades, com o intuito de representar n˜ao apenas as
variabilidades, mas tamb´em a intera¸c˜ao entre os processos de neg´ocio.
A abordagem apresentada neste cap´ıtulo utiliza-se dos trabalhos j´a mencionados como
base. O trabalho de Fantinato (2007) ´e estendido para melhor´a-lo quanto a reutiliza¸c˜ao e
representa¸c˜ao de processos de neg´ocio. O trabalho de Oliveira Junior (2005) foi utilizado
com o intuito de inserir artefatos que melhorem o gerenciamento de variabilidade em
processo de neg´ocio, servi¸cos Web e contrato eletrˆonicos. A tese de Kradolfer (2000)
´e utilizada para detalhar a descri¸c˜ao da atividade que permite a realiza¸c˜ao efetiva da
reutiliza¸c˜ao na abordagem proposta. Os trabalhos de Korherr e List (2006); ? s˜ao
utilizados para a proposta de utiliza¸c˜ao de diagrama de atividades para representa¸c˜ao
de variabilidades em processo de neg´ocio.
A abordagem proposta foi desenvolvida para ser utilizada, principalmente, no mo-
mento da contrata¸c˜ao de processos de neg´ocio e servi¸cos Web pelas empresas e n˜ao no
4.2 RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio 35
momento da cria¸c˜ao e publica¸c˜ao do mesmo. Portanto, os artefatos considerados na
mesma s˜ao de alto n´ıvel de representa¸c˜ao e n˜ao de baixo n´ıvel para ser utilizado para
implementa¸c˜ao.
4.2 RofPN - Abordagem para reutiliza¸c˜ao de processos
de neg´ocio
A abordagem desenvolvida estende a abordagem proposta originalmente por Fantinato
(2007) para o estabelecimento de contratos eletrˆonicos para servi¸cos Web. A abordagem
´e composta por dois modelos de ciclo de vida acompanhando a proposta de Fantinato
(2007) e FORM (Kang et al., 1998). A Figura 4.1 ilustra a abordagem proposta e os
artefatos produzidos durante a mesma. A abordagem aplica os conceitos de LP para
definir os passos a serem seguidos a fim de criar uma estrutura¸c˜ao para os processos de
neg´ocio em um determinado dom´ınio, permitindo a reutiliza¸c˜ao dos mesmos.
As atividades que comp˜oem a engenharia de dom´ınio tem como principal objetivo
desenvolver o n´ucleo de artefatos para um dom´ınio do processo de neg´ocio. A engenharia
de processo de neg´ocio possui como objetivo o desenvolvimento dos produtos finais, por
interm´edio da conFigura¸c˜ao dos artefatos desenvolvidos no ciclo de vida anterior.
A RofPN inicia-se com o desenvolvimento da an´alise de dom´ınio,que ser´a realizada
apenas uma vez para um dom´ınio de neg´ocio, envolvendo o mesmo par de organiza¸c˜oes.
Nestas atividades s˜ao criados o modelo de contrato eletrˆonico e o desenvolvimento e
publica¸c˜ao dos SW e PN.
O segundo ciclo de vida e suas atividades s˜ao executados inteiramente para cada
novo produto da LP. Durante a realiza¸c˜ao deste ciclo de vida pode ser necess´ario realizar
altera¸c˜oes ou inclus˜oes de novas informa¸c˜oes (variabilidades, servi¸cos, processos e n´ıveis
de qualidade de servi¸cos) no primeiro ciclo de vida.
Os produtos da LP s˜ao criados atrav´es da conFigura¸c˜ao do(s) modelo de carac-
ter´ısticas, conFigura¸c˜ao do processo de neg´ocio e a instancia¸c˜ao do contrato eletrˆonico
final. As se¸c˜oes subsequentes descrevem as atividades dos modelos de ciclo de vida da
RofPN.
36 4. RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
Figura 4.1: Abordagem para reutiliza¸c˜ao de PN
4.2.1 Ciclos de vida e suas atividades
Engenharia de dom´ınio de processo de neg´ocio
• An´alise de dom´ınio: a an´alise de dom´ınio do processo de neg´ocio tem como
principal objetivo entender e documentar o dom´ınio e os requisitos necess´arios
para a concretiza¸c˜ao do processo de neg´ocio. O entendimento do dom´ınio permite
desenvolver o artefato denominado, modelo de dom´ınio composto pelo modelo de
caracter´ısticas e o modelo de decis˜ao. Esta composi¸c˜ao e o modelo de decis˜ao n˜ao
existiam na abordagem original proposta por Fantinato (2007).
• Cria¸c˜ao do molde de contrato eletrˆonico para servi¸cos Web: baseando-se
no modelo de dom´ınio ´e criado o molde de contrato eletrˆonico com as informa¸c˜oes
necess´arias, que ser˜ao usadas em qualquer contrato eletrˆonico estabelecido a partir
do modelo de dom´ınio. No molde s˜ao descritos os processos de neg´ocio, servi¸cos Web
4.2 RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio 37
e termos de QoS. A composi¸c˜ao e descri¸c˜ao dos processos de neg´ocio por interm´edio
do diagrama de atividades ´e proposto neste trabalho com o intuito de melhorar a
reutiliza¸c˜ao dos processos de neg´ocio.
• Desenvolvimento e publica¸c˜ao de processos de neg´ocio e servi¸cos Web:
nesta atividade s˜ao desenvolvidos e publicados, em seus respectivos reposit´orios,
os servi¸cos Web e os processos de neg´ocio para que sejam utilizados/reusados na
instancia¸c˜ao do(s) produto(s) da LP.
Engenharia de processo de neg´ocio
• An´alise de dom´ınio baseada no modelo de dom´ınio: esta atividade analisa o
modelo de dom´ınio, estabelecendo as conFigura¸c˜oes para o processo de neg´ocio e o
contrato eletrˆonico a serem desenvolvidos com as variabilidades, pertencentes a cada
produto em espec´ıfico. Nesta fase s˜ao selecionados os processos de neg´ocio e servi¸cos
Web a serem utilizados. Nesta atividade realiza¸c˜ao o Reutiliza¸c˜ao ´e realizado atrav´es
do entendimento e sele¸c˜ao dos servi¸cos Web e processos de neg´ocio a serem utilizados
para compor um produto da LP. Nesta fase, pode ocorrer de um servi¸co ou processo
n˜ao existir ou n˜ao ser adequado ao produto, sendo assim, torna-se necess´ario sua
adapta¸c˜ao ou cria¸c˜ao do novo servi¸co. Ap´os as fases de sele¸c˜ao, adapta¸c˜ao e cria¸c˜ao ´e
necess´ario realizar a integra¸c˜ao dos componentes desenvolvidos a LP. As ideias aqui
expostas partem do trabalho de doutorado de Kradolfer (2000) para o Reutiliza¸c˜ao
de workflow. Com o intuito de ilustrar e detalhar os passos internos pertencentes
a esta atividade, a Figura 4.2 foi desenvolvida derivando a originalmente proposta
por Kradolfer (2000).
Figura 4.2: Etapas da sele¸c˜ao e reutiliza¸c˜ao
38 4. RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
• ConFigura¸c˜ao do processo de neg´ocio: esta atividade objetiva conFigurar
o processo de neg´ocio a ser contratado, baseando-se no modelo de caracter´ıstica
conFigurado. O processo de neg´ocio conFigurado ´e ilustrado por interm´edio do
diagrama de atividades conFigurado. Esta atividade ´e proposta neste trabalho e
n˜ao pertence `a abordagem original proposta por Fantinato (2007)
• Instancia¸c˜ao do contrato eletrˆonico: esta atividade objetiva a cria¸c˜ao do(s)
produto(s) da LP por interm´edio do(s) modelo(s) de caracter´ıstica conFigurado(s)
e diagrama de atividades conFigurado, que estabelecem os servi¸cos web, termos de
QoS e processos de neg´ocio a serem utilizados pelo produto da LP.
4.2.2 Artefatos produzidos na RofPN
Com a finalidade de proporcionar um melhor entendimento a respeito dos artefatos
produzidos durante a realiza¸c˜ao das atividades da RofPN ´e utilizado como exemplo, o
processo de neg´ocio de uma agˆencia de viagens. O dom´ınio de um processo de neg´ocio
para uma agˆencia de viagens consiste no gerenciamento de vendas e reserva de passagens,
hot´eis e ve´ıculos. Neste contexto o processo de neg´ocio da agˆencia de viagens realiza
chamadas aos servi¸cos eletrˆonicos contratados de trˆes organiza¸c˜oes, s˜ao elas: agˆencia de
hot´eis, locadora de ve´ıculos e agˆencia de linhas a´ereas. No cap´ıtulo 5 ´e apresentado um
exemplo mais completo dos artefatos produzidos num dom´ınio de processo de neg´ocio
diferente. Os artefatos est˜ao separados de acordo com o ciclo de vida a qual pertencem.
Engenharia de dom´ınio de processo de neg´ocio
• Modelo de dom´ınio: documenta as variabilidades do dom´ınio do processo de
neg´ocio, os servi¸cos Web e os termos e QoS; documentando os requisitos necess´arios
para a concretiza¸c˜ao do processo de neg´ocio. O modelo de dom´ınio ´e composto de
dois artefatos: modelo de decis˜ao e modelo de caracter´ısticas.
– Modelo de caracter´ıstica: representa os servi¸cos Web e os atributos de QoS
como proposto no trabalho de (Fantinato, 2007). As Figuras 4.3, 4.4, 4.5,
4.6 representam os modelos de caracter´ısticas para o processo de neg´ocio da
agˆencia de viagens, com os servi¸cos e termos de QoS dispon´ıveis.
4.2 RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio 39
Figura 4.3: Modelo de caracter´ıstica para o processo de neg´ocio da agˆencia de viagens
40 4. RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
Figura 4.4: Modelo de caracter´ıstica para agˆencia de hot´eis
Figura 4.5: Modelo de caracter´ıstica para a agˆencia de linhas a´ereas
4.2 RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio 41
Figura 4.6: Modelo de caracter´ıstica para a locadora de ve´ıculos
– Modelo de decis˜ao: documenta os requisitos, restri¸c˜oes e outras informa¸c˜oes
relevantes a respeito da LP de processo de neg´ocio para o dom´ınio em quest˜ao,
objetivando apoiar as decis˜oes futuras no momento da instancia¸c˜ao de um novo
produto. O modelo de decis˜ao complementa o modelo de caracter´ısticas, no
sentido de descrever melhor as op¸c˜oes de conFigura¸c˜ao e as consequˆencias de
suas escolhas. Por motivo de foco no trabalho este modelo ´e postergado como
trabalho futuro definindo a padroniza¸c˜ao do modelo. Este artefato ´e proposto
neste trabalho e n˜ao pertence a abordagem proposta por Fantinato (2007).
• Molde de contrato eletrˆonico: descreve todos os servi¸cos Web, processos de
neg´ocio e termos de QoS poss´ıveis de serem utilizados para a gera¸c˜ao dos produtos
da LP. As caracter´ısticas obrigat´orias do molde de contrato eletrˆonico s˜ao direta-
mente incorporadas no contrato eletrˆonico final descrevendo os servi¸cos, processos
de neg´ocio e termos de QoS que devem ser obrigatoriamente contratados. As
caracter´ısticas alternativas ou opcionais s˜ao adiadas at´e o momento da negocia¸c˜ao
dos servi¸cos Web e QoS a serem contratados. O molde de contrato eletrˆonico ´e
apresentado em trˆes partes, s˜ao elas:
42 4. RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
– Descri¸c˜ao dos SW: a descri¸c˜ao dos servi¸cos Web ´e realizada por interm´edio
dos arquivos relativos a se¸c˜ao: wsdl:Definitions. A Figura 4.7 apresenta a
descri¸c˜ao dos SW para o processo de neg´ocio contratado da agˆencia de hot´eis,
pela agˆencia de viagens como exemplo deste artefato.
Figura 4.7: Descri¸c˜ao dos SW para agˆencia de hot´eis - se¸c˜ao: wsdl:Definitions
– Descri¸c˜ao dos PN: os processos de neg´ocio s˜ao descritos por interm´edio do
diagrama de atividades, para mostrar as variabilidades nos processos de neg´ocio
e a intera¸c˜ao entre os mesmos. A descri¸c˜ao ´e realizada, tamb´em, por meio da
se¸c˜ao: bpel:Process. O diagrama de atividades ´e apresentado na se¸c˜ao 4.3 deste
mesmo cap´ıtulo, pois nela ´e proposta uma representa¸c˜ao de variabilidades de
processos de neg´ocio em diagrama de atividades. A Figura 4.8 apresenta a se¸c˜ao
bpel:Process para o processo de neg´ocio da agˆencia de hot´eis. A descri¸c˜ao por
diagrama de atividades ´e proposta neste trabalho n˜ao constando na abordagem
original proposta por Fantinato (2007).
4.2 RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio 43
Figura 4.8: Descri¸c˜ao do PN para agˆencia de hot´eis - se¸c˜ao: bpel:Process
– Termos de QoS: a descri¸c˜ao dos atributos de qualidade de servi¸co (QoS) s˜ao
realizadas atrav´es da se¸c˜ao: wsag:Terms. A Figura 4.9 ilustra partes de uma
se¸c˜ao wsag:Terms para o processo de neg´ocio da agˆencia de hot´eis.
Figura 4.9: Descri¸c˜ao dos Termos de QoS para agˆencia de hot´eis - se¸c˜ao: wsag:Terms
• Reposit´orio de SW: mant´em os servi¸cos Web j´a dispon´ıveis de forma organizada
para que sejam utilizados. O reposit´orio ´e proposto nesta abordagem todavia n˜ao
consta na original proposta por Fantinato (2007). Contudo, quando utiliza-se de
44 4. RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
SOA ´e previs´ıvel a existˆencia de um reposit´orio para os servi¸cos a serem disponibi-
lizados.
• Reposit´orio de PN: mant´em os processos de neg´ocio j´a dispon´ıveis de forma
organizada para que sejam utilizados. O reposit´orio ´e proposto nesta abordagem
todavia n˜ao consta na original proposta por Fantinato (2007).
Engenharia de processo de neg´ocio
• Modelo de carater´ıstica conFigurado: ´e o modelo de caracter´ıstica com os
atributos j´a selecionados. Representando, assim, os servi¸cos Web e os n´ıveis de QoS
contratados para um determinado produto da LP. As Figuras 4.11, 4.10, 4.12 e 4.13,
apresentam os modelos conFigurados para a agˆencia de viagens.
Figura 4.10: Modelo de caracter´ıstica configurado para rede hoteleria
4.2 RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio 45
Figura 4.11: Modelo de caracter´ıstica configurado para o processo de neg´ocio da agˆencia
de viagens
46 4. RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
Figura 4.12: Modelo de caracter´ıstica configurado para a agˆencia de linhas a´ereas
Figura 4.13: Modelo de caracter´ıstica configurado para a locadora de ve´ıculos
4.2 RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio 47
• Diagrama de atividades conFigurado: ´e o diagrama que representa o processo
de neg´ocio com os SW e n´ıveis de QoS contratados para um determinado produto
da LP. Assim como na descri¸c˜ao dos processos de neg´ocio, o diagrama de atividades
conFigurado ´e apresentado somente na se¸c˜ao 4.3 deste mesmo cap´ıtulo onde ´e
proposto uma representa¸c˜ao de variabilidades de processos de neg´ocio em diagrama
de atividades. Artefato tamb´em n˜ao proposto por Fantinato (2007).
• Contrato eletrˆonico final: o(s) contrato(s) eletrˆonico final reflete a instancia¸c˜ao
de um produto da LP com seus devidos processos de neg´ocio, servi¸cos Web e termos
de QoS. S˜ao criados utilizando-se do modelo de caracter´ıstica conFigurado e o
diagrama de atividades conFigurado. O contrato eletrˆonico final ´e composto por:
– Servi¸cos Web contratados: os servi¸cos Web contratados no contrato eletrˆonico
vigente e dispon´ıveis no reposit´orio de servi¸cos Web. Os servi¸cos Web s˜ao
descritos por meio da se¸c˜ao: wsdl:Definitions. A Figura 4.14 apresenta a se¸c˜ao
wsdl:Definitions conFigurada descrevendo, assim, os servi¸cos Web contratados
da agˆencia de hot´eis.
Figura 4.14: SW contratados da agˆencia de hot´eis - se¸c˜ao: wsdl:Definitions
– Processo de neg´ocio contratados: os processos de neg´ocio contratados no con-
trato eletrˆonico vigente e dispon´ıveis no reposit´orio de processos de neg´ocio.
Os processos de neg´ocio s˜ao descritos pela se¸c˜ao: bpel:Process. A Figura 4.15
apresenta a se¸c˜ao bpel:Process para os processos contratados da agˆencia de
hot´eis.
– Termos de QoS contratados: os termos de QoS contratados no contrato eletrˆonico
vigente. Os termos de QoS s˜ao descritos por interm´edio da se¸c˜ao: wsag:Terms.
48 4. RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
Figura 4.15: PN contratados da agˆencia de hot´eis - se¸c˜ao: bpel:Process
A Figura 4.16 apresenta parte da se¸c˜ao wsag:Terms contratada da agˆencia de
hot´eis.
Figura 4.16: Termos de QoS contratados da agˆencia de hot´eis - se¸c˜ao: wsag:Terms
4.3 Representa¸c˜ao de Variabilidades em Diagrama de Atividades 49
4.3 Representa¸c˜ao de Variabilidades em Diagrama de Ativi-
dades
Ao analisar as propostas j´a existentes, para representa¸c˜ao de variabilidades em diagramas
de atividades, verificou-se a necessidade de realizar modifica¸c˜oes no profile encontrado
para tornar adapt´avel para modelagem de variabilidades em processos de neg´ocio e per-
mitir o mapeamento entre o modelo de caracter´ısticas e o diagrama de atividades rep-
resentando as multiplicidades encontradas nos pontos de varia¸c˜ao Korherr e List (2006,
2007). Deste modo, foi feito uma extens˜ao do Profile existente para melhor adequar-se `a
representa¸c˜ao desejada de variabilidades em processos de neg´ocio.
Ao pensar em modelagem de variabilidade de processos de neg´ocio, compostos de
servi¸cos Web, utilizando-se de diagramas de atividades surgem v´arios tipos de multiplici-
dades a serem mapeadas. Uma das ocorrˆencias especiais ´e o caminho nulo que representa
a escolha de nenhuma das alternativas dispon´ıveis em um ponto de varia¸c˜ao representada
no diagrama de atividades por um fluxo que n˜ao executa atividade(s). A seguir s˜ao
apresentadas e explicadas as representa¸c˜oes desenvolvidas para a extens˜ao proposta neste
trabalho:
• Obrigat´orio: neste tipo de multiplicidade `a atividade, sub-processo e/ou servi¸co ´e
obrigatoriamente executada. A representa¸c˜ao d´a-se atrav´es de um fluxo normal de
uma atividade `a pr´oxima, como na Figura 4.17;
Figura 4.17: Representa¸c˜ao de uma atividade, servi¸co Web e/ou sub-processo obri-
gat´orio
• Opcional: ´e poss´ıvel a escolha de zero (caminho nulo) ou uma entre as op¸c˜oes
dispon´ıveis de acordo a condi¸c˜ao satisfeita. Representa-se utilizando o fork e join
nodes ou com o decision node, como na Figura 4.18;
Figura 4.18: Representa¸c˜ao de uma atividade, servi¸co Web e/ou sub-processo com
execu¸c˜ao opcional (a) com decision node (b) com fork e join nodes
50 4. RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
• Paralelas: as atividades, servi¸cos Web e/ou sub-processos s˜ao executados par-
alelamente, n˜ao havendo a op¸c˜ao de escolha e sim uma execu¸c˜ao em paralelo.
´
E
representada pelo fork e join nodes, como na Figura 4.19;
Figura 4.19: Representa¸c˜ao de atividades, servi¸co Web e/ou sub-processos executados
em paralelo
• M´ultipla-Alternativa: ´e poss´ıvel dentre as op¸c˜oes de atividades, servi¸cos e/ou
sub-processos escolher zero, uma ou v´arias das dispon´ıveis. A representa¸c˜ao d´a-se
atrav´es dos fork e join nodes, como na Figura 4.20. Neste caso tamb´em ´e poss´ıvel
a utiliza¸c˜ao de condi¸c˜oes representada atrav´es de colchetes;
Figura 4.20: Representa¸c˜ao de atividades, servi¸cos Web e/ou sub-processos executados
com op¸c˜ao de escolha m´ultipla
• M´ultipla-Alternativa exclusiva: na m´ultipla-alternativa exclusiva ´e escolhido
um caminho no processo de neg´ocio e este caminho deve ser ´unico apesar de existir
v´arias alternativas. O caminho ´e escolhido de acordo com a condi¸c˜ao que for satis-
feita. A representa¸c˜ao d´a-se atrav´es do uso dos fork e join nodes, como na Figura
4.21. A diferen¸ca entre a m´ultipla-alternativa e a m´ultipla-alternativa exclusiva
´e que nesta ´ultima apenas um caminho pode ser escolhido e na anterior existe a
possibilidade de escolher mais de uma alternativa.
4.3 Representa¸c˜ao de Variabilidades em Diagrama de Atividades 51
Figura 4.21: Representa¸c˜ao de atividades, servi¸cos Web e/ou sub-processos executados
com op¸c˜ao de escolha m´ultipla exclusiva
A representa¸c˜ao de estrutura de repeti¸c˜ao na abordagem proposta para representa¸c˜ao
de variabilidades em processos de neg´ocio por interm´edio do diagrama de atividades ´e
realizada utilizando o decision node e um fluxo de retorno para o ponto em que deseja-se
realizar a repeti¸c˜ao. A Figura 4.22, demonstra a utiliza¸c˜ao de um la¸co de repeti¸c˜ao para
repetir uma parte de processo de neg´ocio que apresenta atividades realizadas paralela-
mente. A restri¸c˜ao que define a execu¸c˜ao ou termino do la¸co ´e representada no fluxo de
retorno dentro de colchetes.
Figura 4.22: Representa¸c˜ao de estrutura de repeti¸c˜ao.
Com o intuito de utilizar a representa¸c˜ao proposta, para modelagem de variabilidades
em processo de neg´ocio, a Figura 4.23 ilustra a modelagem do processo de neg´ocio para
a agˆencia de viagens representando o comportamento do processo de neg´ocio da agˆencia
de viagens quanto `a chamada dos seus servi¸cos e dos servi¸cos dispon´ıveis das outras
organiza¸c˜oes. As swimlanes do diagrama de atividades ´e utilizada nesta representa¸c˜ao
para diferenciar cada organiza¸c˜ao envolvida no processo de neg´ocio e as chamadas aos seus
servi¸cos. A Figura 4.24 apresenta o diagrama de atividades conFigurado para o mesmo
processo de neg´ocio, portanto, apresenta apenas os servi¸cos, termos de QoS e processos
contratados. Por exemplo, os servi¸cos de remo¸c˜ao de passagem, remo¸c˜ao de quartos e
remo¸c˜ao de ve´ıculos n˜ao aparecem no diagrama conFigurado, pois n˜ao ser˜ao contratados
para compor o processo de neg´ocio que est´a sendo conFigurado.
52 4. RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
Figura 4.23: Exemplo de diagramas de atividades mostrando o processo de neg´ocio da
agˆencia de viagens
Figura 4.24: Exemplo de diagramas de atividades mostrando o processo de neg´ocio da
agˆencia de viagens conFigurado
4.4 Considera¸c˜oes Finais 53
4.4 Considera¸c˜oes Finais
Este cap´ıtulo apresentou a abordagem desenvolvida para reutiliza¸c˜ao de processos de
neg´ocio por interm´edio do estabelecimento de uma estrutura de LP para processos de
neg´ocio compostos por servi¸cos Web. O intuito da abordagem ´e melhorar a reutiliza¸c˜ao
dos processos de neg´ocio em seus diferentes n´ıveis. A abordagem constou ainda com a
proposta de uma representa¸c˜ao de variabilidades em processos de neg´ocio utilizando-se
do diagrama de atividades da UML.
Os conte´udos apresentados foram ilustrados por interm´edio da modelagem do processo
de neg´ocio para uma agˆencia de viagens.
O pr´oximo cap´ıtulo, 5, apresenta um exemplo de aplica¸c˜ao da abordagem proposta
em um outro dom´ınio de processo de neg´ocio e as conclus˜oes obtidas por interm´edio da
utiliza¸c˜ao da abordagem.
54 4. RofPN - Abordagem para reutiliza¸c˜ao de processos de neg´ocio
Cap
´
ıtulo
5
Exemplo de aplica¸c˜ao
5.1 Considera¸c˜oes Iniciais
Este cap´ıtulo apresenta um exemplo de aplica¸c˜ao da RofPN em um dom´ınio de processo de
neg´ocio, diferente do abordado no cap´ıtulo 4, com o intuito de exemplificar a abordagem
proposta e analisar as vantagens e desvantagens de sua utiliza¸c˜ao. O dom´ınio do processo
de neg´ocio abordado ´e uma continua¸c˜ao do estudo de caso apresentado no trabalho de
(Fantinato, 2007). Portanto, v´arios artefatos produzidos para o dom´ınio s˜ao derivados do
trabalho de (Fantinato, 2007). A escolha deste dom´ınio deu-se pelo fato do dom´ınio j´a ter
sido modelado anteriormente e ter produzido resultados no trabalho de (Fantinato, 2007).
Portanto, espera-se que com a aplica¸c˜ao da RofPN neste dom´ınio os resultados obtidos
anteriormente repitam-se, visto que a RofPN ´e uma extens˜ao da proposta anterior, e que
os novos resultados sejam alcan¸cados.
A se¸c˜ao (5.2) apresenta o dom´ınio da aplica¸c˜ao utilizada como exemplo. Em seguida
s˜ao apresentados os artefatos produzidos durante os ciclos de vida da abordagem para o
dom´ınio modelado. Na se¸c˜ao 5.3 ´e apresentado o ciclo de vida de engenharia de dom´ınio
do processo de neg´ocio e os artefatos produzidos neste ciclo.
A se¸c˜ao 5.4 apresenta o segundo ciclo de vida, denominado de engenharia de processo
de neg´ocio, onde s˜ao instanciados os produtos da linha de produto, desenvolvido no ciclo
de vida anterior, por interm´edio da configura¸c˜ao do molde de contrato eletrˆonico que
seleciona os servi¸cos web, processos de neg´ocio e termos de QoS a serem contratados.
Cria-se, assim, um processo de neg´ocio a ser utilizado pela organiza¸c˜ao.
55
56 5. Exemplo de aplica¸c˜ao
A se¸c˜ao 5.5 apresenta os trabalhos relacionados evidenciando as extens˜oes proposta
durante o trabalho. Por fim, a se¸c˜ao 5.6 apresenta as conclus˜oes e resultados obtidos com
a aplica¸c˜ao da metodologia para o dom´ınio escolhido.
5.2 Dom´ınio da aplica¸c˜ao
O dom´ınio de processo de neg´ocio apresentado ´e derivado do estudo de caso apresentado
por Fantinato (2007) em sua tese e possui como objeto de estudo a integra¸c˜ao entre dois
sistemas de apoio a neg´ocios e opera¸c˜oes, conhecidos como sistemas BOSS (Business and
Operation Support Systems), no contexto de operadoras de telecomunica¸c˜oes. Contudo,
o objetivo do estudo de caso ´e mostrar os artefatos produzidos no desenvolvimento de
uma linha de produto para o processo de neg´ocio do dom´ınio das operadoras de teleco-
munica¸c˜oes que sub-contrata servi¸cos eletrˆonicos de outras organiza¸c˜oes demonstrando,
assim, os artefatos produzidos para a linha de produto e o reuso de servi¸cos web e processos
de neg´ocio contratados (Fantinato, 2007).
No dom´ınio apresentado, a empresa operadora de telecomunica¸c˜oes, para diminui¸c˜ao
de custos ou por n˜ao ter dom´ınio de conhecimento do neg´ocio, sub-contrata os servi¸cos
oferecidos por outras empresas (processo de neg´ocio inter-organizacionais). Neste exem-
plo, abordaremos dois sistemas dentro do dom´ınio de telecomunica¸c˜oes. O primeiro
realiza o gerenciamento entre os clientes e a empresa de telecomunica¸c˜oes (processo
desenvolvido pela operadora de telecomunica¸c˜oes), e o segundo apresenta o sistema de
cobran¸ca que oferece um apoio computacional para a cobran¸ca de d´ebitos de clientes da
empresa de telecomunica¸c˜oes. O sistema de cobran¸ca (processo de neg´ocio) ´e um sistema
sub-contratado de outra organiza¸c˜ao pela empresa de telecomunica¸c˜ao, sendo assim, ´e
criado um processo de neg´ocio inter-organizacional. Os sistemas neste processo de neg´ocio
oferecem um conjunto de servi¸cos eletrˆonicos ao outro implementados e disponibilizados
como servi¸cos Web e contratados por interm´edio de contratos eletrˆonicos. Os sistemas
s˜ao (Fantinato, 2007):
• Sistema de atendimento a Clientes (CRM - Customer Relationship mana-
gement): este sistema gerencia o relacionamento entre a empresa de telecomu-
nica¸c˜oes e seus clientes oferecendo um conjunto de servi¸cos eletrˆonico para venda
de produtos, contrata¸c˜ao e cancelamento de servi¸cos, consulta de servi¸cos, cria¸c˜ao e
atualiza¸c˜ao de cadastro de clientes, e cria¸c˜ao de contratos entre empresa e clientes.
A execu¸c˜ao deste sistema requer a integra¸c˜ao com outros sistemas BOSS para
gerenciamento das demais ´areas dentro do dom´ınio de telecomunica¸c˜oes. Como
5.3 Engenharia de dom´ınio de processos de neg´ocio 57
exemplos: gerˆencia de recursos, gerencia de recursos humanos, tarifa¸c˜ao de servi¸cos,
faturamento de servi¸cos, arrecada¸c˜ao, cobran¸ca e contabiliza¸c˜ao.
• Sistema de Cobran¸ca (COB): oferece apoio computacional `a cobran¸ca de d´ebitos
de clientes da empresa de telecomunica¸c˜oes oferecendo um conjunto de servi¸cos
eletrˆonicos que realizam as a¸c˜oes de inclus˜ao e exclus˜ao de registro de cheques irreg-
ulares, cadastramento de d´ebitos, atualiza¸c˜ao de d´ebitos, parcelamento de d´ebitos,
cancelamento de d´ebitos, cancelamentos de encargos (multas e juros), concess˜ao
de descontos, notifica¸c˜ao de d´ebitos (correspondˆencia, e-mail, telefone), suspens˜ao
do fornecimento de servi¸cos contratados (parcial ou total) e a¸c˜oes legais contra os
clientes em d´ebito.
Neste processo de neg´ocio os sistemas citados necessitam disponibilizar os servi¸cos um
para o outro para que as tarefas possam ser executadas. Pode ser necess´ario a execu¸c˜ao
de servi¸cos pelo sistema CRM para que o sistema COB possa terminar a execu¸c˜ao de um
determinado servi¸co.
5.3 Engenharia de dom´ınio de processos de neg´ocio
Nesta se¸c˜ao ´e apresentado o ciclo de vida intitulado de engenharia de dom´ınio de processos
de neg´ocio que inicia-se com o desenvolvimento do modelo de dom´ınio, molde de contrato
eletrˆonico e reposit´orios de SW e PN.
5.3.1 Modelo de dom´ınio
Modelo de caracter´ısticas
Os modelos de caracter´ısticas para o dom´ınio do processo de neg´ocio em estudo repre-
sentar´a os servi¸cos Web e termos de QoS para o processo de neg´ocio das operadoras de
telecomunica¸c˜oes. Os modelos foram desenvolvidos com o apoio da ferramenta Feature-
Plugin.
Os modelos de caracter´ısticas apresentados possuem um conjunto de sub-caracter´ısticas
que representam de forma estruturada os servi¸cos Web dispon´ıveis e os atributos de QoS
disponibilizados por eles. As caracter´ısticas raiz pr´e-nomeadas de servi¸cos eletrˆonicos
e atributos de QoS representam, respectivamente, os processos de neg´ocio a serem
contratados com os seus servi¸cos e os atributos de qualidade dispon´ıveis para contrata¸c˜ao
dos mesmos (Fantinato, 2007).
58 5. Exemplo de aplica¸c˜ao
As Figuras 5.1 e 5.2 apresentam os modelos de caracter´ısticas para os termos de QoS
e servi¸cos disponibilizados pelo sistema COB para o sistema CRM. O sistema COB ´e o
sistema contratado pela operadora de comunica¸c˜oes de outra organiza¸c˜ao. Os modelos
de caracter´ısticas aqui apresentados seguem as mesmas regras definidas no trabalho de
Fantinato (2007).
Figura 5.1: Modelo de caracter´ısticas para servi¸cos eletrˆonicos do sistema COB (carac-
ter´ısticas relacionadas aos servi¸cos eletrˆonicos) (Fantinato, 2007).
A caracter´ıstica raiz servi¸cos eletrˆonicos ´e expandida e possui as sub-caracter´ısticas
que representam agrupamentos estruturados de servi¸cos eletrˆonicos oferecidos pelo sistema
COB, exemplos: cheques irregulares, encargos e descontos, cadastro de clientes,
dividas e outros.
5.3 Engenharia de dom´ınio de processos de neg´ocio 59
Opcionalmente, os servi¸cos eletrˆonicos podem conter sub-caracter´ısticas que represen-
tam detalhes funcionais associados ao respectivo servi¸co. Por exemplo, a caracter´ıstica
consulta de estado de acoes e revers˜oes de a¸c˜ao de cobran¸ca cont´em as seguintes
sub-caracter´ısticas que representam detalhes funcionais relacionados `a aplica¸c˜ao de a¸c˜oes
de cobran¸ca consulta estado de a¸c˜ao de cobran¸ca e consulta estado de revers˜ao
de a¸c˜ao de cobran¸ca.
Figura 5.2: Modelo de caracter´ısticas para servi¸cos eletrˆonicos do sistema COB (carac-
ter´ısticas relacionadas aos servi¸cos eletrˆonicos) (Fantinato, 2007).
60 5. Exemplo de aplica¸c˜ao
No modelo de caracter´ıstica apresentado s˜ao definidas caracter´ısticas obrigat´orias e
opcionais. As caracter´ısticas obrigat´orias s˜ao consideradas de extrema importˆancia para
o funcionamento do sistema COB e sem elas o mesmo n˜ao opera, portanto, s˜ao servi¸cos
(caracter´ısticas) que devem ser obrigatoriamente contratados pela empresa operadora de
telecomunica¸c˜oes, exemplo: acoes e revers˜oes de a¸c˜ao de cobran¸ca, consultas a
acoes e revers˜oes de a¸c˜ao de cobran¸ca, e outros. As caracter´ısticas opcionais podem
ser contratadas pela empresa caso sejam consideradas necess´arias, exemplos: cheques
irregulares, dividas, encargos e descontos, e outras.
Os atributos de QoS tamb´em apresenta a caracter´ıstica raiz e suas sub-caracter´ısticas
que podem ser associados a servi¸cos eletrˆonicos representando os n´ıveis de qualidade
desejados para os servi¸cos, exemplos deste tipo de caracter´ısticas: disponibilidade,
tempo de resposta, acessos simultˆaneos e seguran¸ca. As sub-caracter´ısticas de
QoS possuem tamb´em suas sub-caracter´ısticas apresentando os tipos de op¸c˜ao de atributo
de QoS, como: sem controle e n´ıveis de QoS. As sub-caracter´ısticas do tipo n´ıveis
de QoS apresentam, ainda, sub-caracter´ısticas representando os n´ıveis de QoS que est˜ao
dispon´ıveis para escolha para os servi¸cos eletrˆonicos a serem contratados, exemplo: 5, 15,
30 e outros para a caracter´ıstica tempo de resposta.
At´e o momento, apresentamos o modelo de caracter´ıstica para o sistema COB con-
tratado pela operadora de telecomunica¸c˜oes. As figuras 5.3 e 5.4 apresentam os modelos
de caracter´ısticas dos servi¸cos e atributos de QoS, respectivamente, para o sistema CRM
respons´avel pelo gerenciamento de atendimento aos clientes. O modelo de caracter´ıstica
para o sistema CRM apresenta a mesma estrutura do modelo de caracter´ıstica do sistema
COB, com as caracter´ısticas raiz e suas sub-caracter´ısticas, assim, como os tipos de
caracter´ısticas obrigat´orias e opcionais.
5.3 Engenharia de dom´ınio de processos de neg´ocio 61
Figura 5.3: Modelo de caracter´ısticas para servi¸cos eletrˆonicos do sistema CRM (carac-
ter´ısticas relacionadas aos servi¸cos eletrˆonicos) (Fantinato, 2007).
62 5. Exemplo de aplica¸c˜ao
Figura 5.4: Modelo de caracter´ısticas para servi¸cos eletrˆonicos do sistema CRM (carac-
ter´ısticas relacionadas aos servi¸cos eletrˆonicos) (Fantinato, 2007).
Modelo de decis˜ao
O modelo de decis˜ao deve descrever os requisitos, restri¸c˜oes e outras caracter´ısticas
necess´arias ao processo de neg´ocio que est´a sendo modelado objetivando proporcionar
aos interessados uma clareza maior na escolha dos servi¸cos, processos e suas variabili-
dades. O modelo deve, ainda, descrever as implica¸c˜oes que cada escolha realizada ter´a na
configura¸c˜ao do produto final da LP. Neste trabalho n˜ao ´e proposto uma padroniza¸c˜ao
para este modelo postergando o desenvolvimento do mesmo, por motivo de foco, como
trabalho futuro de pesquisa.
5.3.2 Molde de contrato eletrˆonico
Nesta se¸c˜ao s˜ao apresentados os artefatos produzidos na segunda atividade realizada
durante a engenharia de dom´ınio de processo de neg´ocio. Estes artefatos comp˜oem o molde
5.3 Engenharia de dom´ınio de processos de neg´ocio 63
de contrato eletrˆonico para servi¸cos Web pertencentes a linha de produto de operadora de
telecomunica¸c˜oes e s˜ao apresentados em sua forma gr´afica pelas ferramentas que comp˜oem
o conjunto FeatureContract (Fantinato, 2007).
Parte do molde de contratos eletrˆonico apresentado foi desenvolvido no trabalho pro-
posto por Fantinato (2007), contudo, neste trabalho os artefatos produzidos para o molde
de contrato eletrˆonico foram divididos em trˆes categorias para representar separadamente
os servi¸cos Web, processos de neg´ocio e termos de QoS.
A RofPN apresenta tamb´em a utiliza¸c˜ao do diagrama de caracter´ısticas para repre-
sentar o processo de neg´ocio, juntamente, com a documenta¸c˜ao WS-BPEL. A primeira
subse¸c˜ao apresenta os artefatos utilizados para descrever os servi¸cos Web, a segunda
apresenta os artefatos utilizados para descrever os processos de neg´ocio e a ultima se¸c˜ao
apresenta os artefatos utilizado para descrever os termos de QoS.
Descri¸c˜ao dos servi¸cos Web
A descri¸c˜ao dos servi¸cos Web ´e apresentada utilizando-se dos arquivos relativos `as se¸c˜oes
wsdl:Definitions gerados com o apoio da ferramenta XSLTransformer. Os elementos
b´asicos da se¸c˜ao wsdl:Definitions s˜ao gerados de forma autom´atica a partir dos respectivos
elementos nos modelos de caracter´ısticas. As figuras dos modelos de caracter´ısticas apre-
sentadas na se¸c˜ao anterior foram utilizadas para gerar a se¸c˜ao wsdl:Definitions (Fantinato,
2007).
As figuras 5.5 e 5.6 apresentam as se¸c˜oes wsdl:Definitions para os sistemas COB e
CRM, respectivamente. S˜ao apresentados os elementos b´asicos da linguagem WSDL
utilizados para descrever os servi¸cos Web para o processo de neg´ocio da operadora de
telecomunica¸c˜oes. As caracter´ısticas utilizadas para a gera¸c˜ao da descri¸c˜ao dos servi¸cos
Web est˜ao localizadas abaixo da sub-´arvore servi¸cos eletrˆonicos.
Os principais elementos da se¸c˜ao wsdl:Definitions s˜ao os tipos de porta (portType),
criados a partir das caracter´ısticas do tipo grupo de servi¸cos. Como exemplo, o tipo
de porta acoes-de-cobrancaPT ´e gerado a partir da caracter´ıstica acoes-de-cobranca. Os
portType s˜ao compostos por um conjunto de opera¸c˜oes (operation), criadas a partir das
sub-caracter´ısticas do tipo servi¸co eletrˆonico, exemplo: aplicacao-de-acao-de-cobrancaOP
(Fantinato, 2007).
Um conjunto de pelo menos dois tipos de mensagens s˜ao associadas a cada opera¸c˜ao,
uma de entrada e uma de sa´ıda, que s˜ao utilizadas como vari´aveis pelas opera¸c˜oes. Al´em
desses dois tipos, algumas opera¸c˜oes podem possuir mensagens adicionais criadas a partir
64 5. Exemplo de aplica¸c˜ao
de sub-caracter´ısticas do tipo propriedade de servi¸cos existente a partir da hierarquia de
caracter´ısticas (Fantinato, 2007).
Outro tipo de elemento da se¸c˜ao wsdl:Definitions ´e o tipo de liga¸c˜ao entre parceiros
(partnerLinkType. Este elemento, por´em, n˜ao faz parte do conjunto padr˜ao de elementos
de uma especifica¸c˜ao WSDL apesar de ser necess´ario para o entendimento dos servi¸cos
Web. A ferramenta utilizada para visualizar graficamente oferece apenas apoio aos
elementos padr˜oes, portanto, o elemento partnerLinkType ´e apresentado na Figura 5.7
no formato textual para o sistema COB.
5.3 Engenharia de dom´ınio de processos de neg´ocio 65
Figura 5.5: Molde de Contrato eletrˆonico - se¸c˜ao: wsdl:Definitions (Sistema COB)
(Fantinato, 2007).
66 5. Exemplo de aplica¸c˜ao
Figura 5.6: Molde de Contrato eletrˆonico - se¸c˜ao: wsdl:Definitions (Sistema CRM)
(Fantinato, 2007).
5.3 Engenharia de dom´ınio de processos de neg´ocio 67
Figura 5.7: Molde de contrato eletrˆonico - se¸c˜ao: wsdl:Definitions, elementos partner-
LinkType (Sistema COB) (Fantinato, 2007).
Descri¸c˜ao dos processos de neg´ocio
Os processos de neg´ocio s˜ao descritos por interm´edio da representa¸c˜ao das variabilidades
em diagramas de atividades, que modelam as variabilidades do processo de neg´ocio e,
tamb´em, as intera¸c˜oes ocorridas entre os sistemas que comp˜oem o processo de neg´ocio da
operadora de telecomunica¸c˜ao. A representa¸c˜ao por diagrama de atividades foi proposta
neste trabalho com o intuito de melhor entender e visualizar as variabilidades do processo
de neg´ocio para que seja poss´ıvel a reutiliza¸c˜ao dos mesmos ao configurar o diagrama
no momento de criar um produto da LP. Portanto, esta representa¸c˜ao n˜ao pertence a
abordagem original proposta por Fantinato (2007).
O diagrama de atividades, apresentado na Figura 5.8, descreve o processo de neg´ocio
em quest˜ao apresentando, ambos, os sistemas CRM e COB suas variabilidades e as in-
tera¸c˜oes presentes entre os mesmos. Neste diagrama ´e apresentado diversas possibilidades
de acordo de neg´ocio entre as organiza¸c˜oes, contudo, apenas uma delas ou um conjunto
delas ´e utilizado em cada instˆancia de contrato a ser criada em uma etapa futura. O
processo ´e especificado tendo o sistema CRM como ator principal na coopera¸c˜ao entre
os dois sistemas. As variabilidade e suas multiplicidades s˜ao representadas e visualizadas
no diagrama utilizando-se de colchetes com a multiplicidade inseridos nos elementos de
escolha pertencentes ao diagrama de atividades da UML (join, merge e decision).
68 5. Exemplo de aplica¸c˜ao
A Figura 5.9 apresenta parte da se¸c˜ao bpel:Process para o processo de neg´ocio que
envolve os sistemas COB e CRM. O processo descrito em linguagem WS-BPEL ´e apresen-
tado graficamente por meio da ferramenta ActiveBPEL Designer, tamb´em integrante do
conjunto de ferramentes FeatureContract. Assim como no diagrama de atividades, a se¸c˜ao
bpel:Process apresenta diversas possibilidades de acordo de neg´ocio entre as organiza¸c˜oes.
A se¸c˜ao aqui apresentada n˜ao representa por completo todos os servi¸cos Web que foram
criados na se¸c˜ao wsdl:Definitions e sim parte do processo de neg´ocio relativo aos servi¸cos
Web de aplica¸c˜ao de a¸c˜oes de cobran¸ca e a revers˜ao de aplica¸c˜ao de a¸c˜oes de cobran¸ca por
parte do sistema COB; e a gerˆencia de ordens de servi¸cos para apoiar tais aplica¸c˜oes e
revers˜oes pelo sistema CRM. O processo ´e composto por uma s´erie de sequˆencia de fluxos
paralelos de servi¸cos Web sendo invocados entre os sistemas. O processo ´e especificado,
assim como no diagrama de atividades, tendo o sistema CRM como ator principal na
coopera¸c˜ao entre os dois sistemas. Portanto, a comunica¸c˜ao entre os sistemas para o uso
de servi¸cos Web ´e realizado de duas formas (Fantinato, 2007):
1. Sistema CRM invoca servi¸cos Web oferecidos pelo Sistema COB: esse tipo
de opera¸c˜ao ´e representado por apenas um elemento gr´afico no processo (invoke).
O recebimento da invoca¸c˜ao do servi¸co Web por parte do sistema COB e a sua
resposta ao sistema CRM n˜ao s˜ao apresentados, por estarem no escopo de opera¸c˜ao
do sistema COB.
2. Sistema CRM recebe uma invoca¸c˜ao do sistema COB/Sistema CRM
responde `a invoca¸c˜ao realizada pelo sistema COB: estas opera¸c˜oes s˜ao apre-
sentadas por dois elementos gr´aficos no processo (receive e reply). Ao contr´ario
do caso anterior, a invoca¸c˜ao do servi¸co Web por parte do sistema COB n˜ao ´e
apresentada por estar no escopo de opera¸c˜ao do sistema COB.
5.3 Engenharia de dom´ınio de processos de neg´ocio 69
Figura 5.8: Diagrama de atividades com as representa¸c˜oes para o processo de neg´ocio
da operadora de telecomunica¸c˜oes.
70 5. Exemplo de aplica¸c˜ao
Figura 5.9: Molde de contrato- se¸c˜ao: bpel:Process (Fantinato, 2007).
Al´em dos elementos apresentados na Figura 5.9, existem outros tipo de elementos da
se¸c˜ao bpel:Process que n˜ao s˜ao representados graficamente pela ferramenta ActiveBPEL
5.3 Engenharia de dom´ınio de processos de neg´ocio 71
Designer. S˜ao eles: partnerLink que representa a liga¸c˜ao entre os parceiros e variable que
representa as vari´aveis do processo. Portanto, estes elementos s˜ao apresentados de forma
textual na Figura 5.10 (Fantinato, 2007).
Figura 5.10: Molde de contrato- se¸c˜ao: bpel:Process, elementos partnerLink e variable
(Fantinato, 2007).
Termos de QoS
Na se¸c˜ao wasg:Terms tamb´em s˜ao geradas com o apoio da ferramenta XSLTransformer
utilizando o modelo de caracter´ısticas que descrevem os termos que QoS. Os atributos de
QoS descritos na linguagem WS-Agreement s˜ao apresentados graficamente por meio da
ferramenta XML Editor tamb´em integrante do conjunto de ferramentas FeatureContract.
As Figuras 5.11 e 5.12 apresentam partes da se¸c˜ao wsag:Terms para o sistema COB
gerados em fun¸c˜ao do modelo de caracter´ısticas para os termos de QoS, e seus respectivos
n´ıveis, relacionados com os servi¸cos Web envolvidos. As caracter´ısticas utilizadas para
72 5. Exemplo de aplica¸c˜ao
gerar esta se¸c˜ao do molde de contrato s˜ao todas as existentes abaixo da sub-´arvore
atributos de QoS (Fantinato, 2007).
As se¸c˜oes wsag:Terms apresentam as propriedades de servi¸co wsag:ServiceProperties
criados para cada opera¸c˜ao de servi¸co Web na se¸c˜ao wsdl:Definitions. Um conjunto de
vari´aveis de garantia wsag:Variable s˜ao geradas a partir de todas as caracter´ısticas do tipo
atributo de QoS para cada propriedade de servi¸co. O exemplo de propriedade de servi¸co
apresentado na figura ´e aplica¸c˜ao de a¸c˜ao de cobran¸caSP, associada `a opera¸c˜ao aplica¸c˜ao
de a¸c˜ao de cobran¸caOP. Um exemplo de vari´aveis de garantia ´e tempo de respostaVAR,
gerada para a caracter´ıstica tempo de resposta (Fantinato, 2007).
A parte da se¸c˜ao que descreve os termos de garantia wsag:GuaranteeTerm ´e criada
para opera¸c˜ao de servi¸co Web; um para cada vari´avel de garantia wsag:Variable de uma
determinada propriedade de servi¸co. Cada termo de garantia possui um objetivo de n´ıvel
de servi¸co wsag:ServiceLevelObjective associado `a respectiva vari´avel de garantia. O
objetivo do n´ıvel de servi¸co ´e criado a partir de: caracter´ısticas agrupadas para a op¸c˜ao
de atributo sem-controle; e sub-caracter´ısticas do tipo n´ıvel das caracter´ısticas agrupadas
para a op¸c˜ao de atributo n´ıveis de QoS (Fantinato, 2007).
5.3 Engenharia de dom´ınio de processos de neg´ocio 73
Figura 5.11: Molde de contrato eletrˆonico - se¸c˜ao: wsag:Terms, Parte I (Sistema COB)
(Fantinato, 2007).
74 5. Exemplo de aplica¸c˜ao
Figura 5.12: Molde de contrato eletrˆonico - se¸c˜ao: wsag:Terms, Parte II (Sistema COB)
(Fantinato, 2007).
5.4 Engenharia de processo de neg´ocio 75
5.3.3 Reposit´orio de servi¸cos Web e processos de neg´ocio
O reposit´orio de servi¸cos Web ´e respons´avel por manter os servi¸cos Web j´a implementados
e dispon´ıveis para a utiliza¸c˜ao na linha de produto de software, assim como, suas vers˜oes.
´
E importante que neste reposit´orio seja realizado alguma organiza¸c˜ao para que os servi¸cos
Web sejam facilmente encontrados e que seja tamb´em poss´ıvel identificar qual ´e a vers˜ao
de cada servi¸co Web para facilitar o uso e reuso dos mesmos. O reposit´orio de SW s˜ao
tamb´em definidos neste trabalho para melhor organizar os SW a serem disponibilizados.
Estes reposit´orios s˜ao servidores onde encontrar˜ao os servi¸cos dispon´ıveis para utiliza¸c˜ao
por interm´edio da arquitetura de servi¸cos Web.
5.4 Engenharia de processo de neg´ocio
Nesta se¸c˜ao s˜ao apresentados os documentos gerados no ciclo de vida intitulado de en-
genharia de processos de neg´ocio com o intuito de gerar os produtos para o dom´ınio
da operadora de telecomunica¸c˜oes atrav´es da configura¸c˜ao do modelo de caracter´ısticas
e gera¸c˜ao do contrato eletrˆonico final composto pelos servi¸cos Web, termos de QoS e
processos de neg´ocio contratados.
5.4.1 Modelo de caracter´ıstica configurado
Nesta se¸c˜ao ´e apresentado o modelo de caracter´ıstica configurado para a instancia¸c˜ao de
um produto da linha de produto para o dom´ınio das operadoras de telecomunica¸c˜oes.
Os modelos de caracter´ısticas aqui configurados s˜ao derivados dos modelos apresentados
na se¸c˜ao 5.3.1 que apresenta o molde de contrato eletrˆonico desta LP. A configura¸c˜ao
apresenta um processo de neg´ocio poss´ıvel de ser gerado para esta LP, contudo, existe a
possibilidade de configurar de varias formas o modelo de caracter´ısticas gerando, assim,
produtos (processos de neg´ocio) diferentes para esta mesma LP.
As Figuras 5.13 e 5.14 apresentam a configura¸c˜ao do sistema COB contratado pela
operadora de telecomunica¸c˜oes onde os servi¸cos obrigat´orios j´a aparecem pr´e-selecionados,
como a¸c˜oes de cobran¸ca e alguns de suas sub-caracter´ısticas. As caracter´ısticas op-
cionais/alternativas s˜ao selecionados de acordo com a necessidade - como por exemplo
revers˜oes de a¸c˜ao de cobran¸ca que n˜ao foi selecionada e nem suas sub-caracter´ısticas.
Neste caso a operadora de telecomunica¸c˜ao em quest˜ao n˜ao deseja contratar estes servi¸cos.
76 5. Exemplo de aplica¸c˜ao
Figura 5.13: Configura¸c˜ao do modelo de caracter´ısticas para servi¸cos eletrˆonicos do
sistema COB (Fantinato, 2007).
5.4 Engenharia de processo de neg´ocio 77
Figura 5.14: Configura¸c˜ao do modelo de caracter´ısticas para os atributos de QoS do
sistema COB (Fantinato, 2007).
78 5. Exemplo de aplica¸c˜ao
Os modelos de caracter´ısticas, tamb´em, s˜ao configurados quanto aos atributos de QoS
selecionando os n´ıveis de qualidade desej´avel para os processos de neg´ocio e seus servi¸cos
contratados. A Figura 5.15 apresenta a configura¸c˜ao do modelo de caracter´ıstica, que
descreve o processo de neg´ocio e servi¸cos Web, para o sistema CRM. Como no sistema
COB a caracter´ıstica de revers˜ao de a¸c˜ao de cobran¸ca n˜ao foi selecionada, o sistema CRM
n˜ao deve, portanto, apresentar em sua configura¸c˜ao este servi¸co.
Figura 5.15: Configura¸c˜ao do modelo de caracter´ısticas para servi¸cos eletrˆonicos do
sistema CRM (Fantinato, 2007).
5.4 Engenharia de processo de neg´ocio 79
5.4.2 Diagrama de atividades configurado
O diagrama de atividades configurado deve refletir o processo de neg´ocio da operadora
de telecomunica¸c˜oes configurado para o produto da LP que esta sendo configurado neste
exemplo durante a engenharia do processo de neg´ocio. O diagrama de atividade ´e con-
figurado baseando-se no modelo de caracter´ıstica configurado para o processo de neg´ocio.
A Figura 5.16 apresenta o diagrama de atividades configurado para o produto da LP
utilizado como exemplo. O presente artefato ´e proposto neste trabalho n˜ao constando no
trabalho de Fantinato (2007).
Figura 5.16: Diagrama de atividades para o contrato eletrˆonico vigente.
5.4.3 Contrato eletrˆonico final
O contrato eletrˆonico final ´e composto pelos servi¸cos Web, processos de neg´ocio e termos
de n´ıveis de QoS contratados. Portanto, esta se¸c˜ao descreve os servi¸cos Web contratados
atrav´es das defini¸c˜oes WSDL e seus elementos (partnerLinkType), os termos de n´ıveis
de QoS por interm´edio da se¸c˜ao WSAG, e o processo de neg´ocio pela se¸c˜ao WS-BPEL
e seus elementos (partnerLink, variable). O contrato eletrˆonico ´e realizado baseando-se
no modelo de caracter´ıstica configurado apresentado na se¸c˜ao 5.4.1. A configura¸c˜ao e
realiza¸c˜ao do contrato eletrˆonico final estabelece uma instˆancia da linha de produto para
o dom´ınio das operadoras de telecomunica¸c˜oes.
O contrato eletrˆonico ´e produzido pela ferramentas FeatureContract. As Figuras 5.17,
5.18 e 5.19 apresentam os servi¸cos eletrˆonicos que foram contratados para o contrato
vigente de ambos os sistemas (COB, CRM). Portanto, apresentam apenas um subconjunto
80 5. Exemplo de aplica¸c˜ao
dos servi¸cos dispon´ıveis para o dom´ınio de processo de neg´ocio em quest˜ao, pois somente
deve apresentar os servi¸cos selecionados.
Figura 5.17: Contrato eletrˆonico - se¸c˜ao: wsdl:Definitions para o sistema COB (Fanti-
nato, 2007).
5.4 Engenharia de processo de neg´ocio 81
Figura 5.18: Contrato eletrˆonico - se¸c˜ao: wsdl:Definitions para o sistema CRM (Fanti-
nato, 2007).
Figura 5.19: Contrato eletrˆonico - se¸c˜ao: wsdl:Definitions elementos partnerLinkType
para o sistema COB (Fantinato, 2007).
Outra parte do contrato eletrˆonico de grande importˆancia s˜ao os termos de n´ıveis de
qualidade (QoS). Portanto, as Figuras 5.20 e 5.21 ilustram os n´ıveis de QoS contratados
para os sistemas COB.
Nas Figuras 5.22 e 5.23 s˜ao apresentadas a se¸c˜ao BPEL e seus elementos (partnerLink e
variable) para o mesmo processo de neg´ocio. As trˆes figuras mencionadas, juntas, definem
82 5. Exemplo de aplica¸c˜ao
o produto que foi instanciado para a linha de produto apresentada para o dom´ınio das
operadoras de telecomunica¸c˜oes.
Figura 5.20: Contrato eletrˆonico - se¸c˜ao: wsag:Terms para o sistema COB, Parte I
(Fantinato, 2007).
5.4 Engenharia de processo de neg´ocio 83
Figura 5.21: Contrato eletrˆonico - se¸c˜ao: wsag:Terms para o sistema COB, Parte II
(Fantinato, 2007).
84 5. Exemplo de aplica¸c˜ao
Figura 5.22: Contrato eletrˆonico - se¸c˜ao: bpel:Process (Fantinato, 2007).
5.5 Trabalhos relacionados 85
Figura 5.23: Contrato eletrˆonico - se¸c˜ao: BPEL:Process elementos partnerLink e
variable (Fantinato, 2007).
5.5 Trabalhos relacionados
Esta se¸c˜ao descreve os trabalhos relacionados enfatizando a utiliza¸c˜ao dos mesmos para
compor a proposta desenvolvida neste trabalho. O primeiro trabalho a ser abordado ´e
a tese de doutorado de Kradolfer (2000) que prop˜oe uma processo a ser seguido para
atingir a reutiliza¸c˜ao. Neste trabalho a processo foi modificado propondo uma estrutura
de sub-atividades a serem seguidas durante a atividade denominado an´alise de dom´ınio
baseado no modelo de dom´ınio para permitir a reutiliza¸c˜ao.
O segundo trabalho abordado foi o trabalho de Oliveira Junior (2005) utilizado durante
as pesquisas para pesquisar a representa¸c˜ao de variabilidades utilizando-se dos diagramas
da UML e o gerenciamento das mesmas. Durante a leitura do trabalho foi observado que
o diagrama da UML que melhor mostraria variabilidades em processos de neg´ocio seria
o diagrama de atividades visto que o mesmo consegue apresentar o comportamento de
um processo de neg´ocio. Portanto, o trabalho contribuiu juntamente com os trabalhos
86 5. Exemplo de aplica¸c˜ao
de Korherr e List (2006, 2007) para a proposta de representa¸c˜ao de variabilidades de
processos de neg´ocio em diagrama de atividades.
O terceiro trabalho, e o mais relevante para o desenvolvimento da proposta, ´e o
trabalho de Fantinato (2007) que foi durante a proposta estendido para incluir atividades
de gerenciamento, publica¸c˜ao e configura¸c˜ao de processos de neg´ocio. Inserindo, assim,
no trabalho uma estrutura n˜ao apenas para servi¸cos eletrˆonicos e termos de qualidade,
mas, tamb´em, uma estrutura que permite a representa¸c˜ao e configura¸c˜ao do processo de
neg´ocio a ser contrato pelos contrato eletrˆonicos.
A Figura 5.24 apresenta uma compara¸c˜ao entre as duas abordagens, mostrando os
ciclos de vida, atividades e artefatos pertencentes. O nome dos ciclos de vida foram
alterados para melhor adequar-se ao conceito de reutiliza¸c˜ao de processos de neg´ocio. A
atividades denominada de configura¸c˜ao de processos de neg´ocio e os artefatos diagrama
de atividades e diagrama de atividades configurado foram adicionados para permitir a
representa¸c˜ao e configura¸c˜ao dos processos de neg´ocio e, portanto, a reutiliza¸c˜ao dos
mesmos. O artefato modelo de dom´ınio foi adicionado juntamente com os artefatos que
o comp˜oem para permitir uma melhor representa¸c˜ao do dom´ınio do neg´ocio. O molde de
contrato eletrˆonico e o contrato eletrˆonico final foi alterado inserindo uma composi¸c˜ao de
artefatos que representa os servi¸cos Web, processos de neg´ocio e termos de QoS a serem
configurados e contratados.
5.6 Considera¸c˜oes Finais
Este cap´ıtulo apresentou uma aplica¸c˜ao da RofPN no dom´ınio de processos de neg´ocio das
operadoras de telecomunica¸c˜oes com o intuito de analisar sua aplica¸c˜ao em um dom´ınio
de processo de neg´ocio para levantar suas vantagens e desvantagens. Neste cap´ıtulo
foram apresentados, ainda, exemplos dos artefatos desenvolvidos durante a aplica¸c˜ao da
abordagem para o desenvolvimento da engenharia de dom´ınio do processo de neg´ocio,
tamb´em, durante a instancia¸c˜ao (configura¸c˜ao) de um processo de neg´ocio (produto) e
seu contrato eletrˆonico. A aplica¸c˜ao da abordagem obteve como principal resultado a
demonstra¸c˜ao de que a utiliza¸c˜ao da abordagem ´e realmente poss´ıvel.
A abordagem contribuiu estendendo o trabalho de Fantinato (2007) por interm´edio
da inclus˜ao de representa¸c˜ao e configura¸c˜ao dos processos de neg´ocio e suas variabilidades
utilizando-se do diagrama de atividades. As altera¸c˜oes realizadas na abordagem original
permite uma melhor representa¸c˜ao dos processos de neg´ocio e, portanto, um melhor reuso
dos mesmos. Contudo, algumas observa¸c˜oes devem ser feitas a respeito da abordagem
considerando suas vantagens e desvantagens. As vantagens encontradas foram:
5.6 Considera¸c˜oes Finais 87
Figura 5.24: Compara¸c˜ao entre a RofPN e a abordagem de Fantinato (2007).
• Representa¸c˜ao adequada dos servi¸cos Web por modelos de caracter´ısticas:
o modelo de caracter´ısticas ´e considerado adequado para a representa¸c˜ao de servi¸cos
Web e termos de QoS. A representa¸c˜ao estruturada dos servi¸cos Web pelo modelo
de caracter´ısticas facilita o entendimento do mesmo e permite uma representa¸c˜ao
efetiva das caracter´ısticas obrigat´orias, opcionais e/ou alternativas. Este ponto forte
da abordagem proposta neste trabalho foi obtido tamb´em na abordagem proposta
por Fantinato (2007) da qual a RofPN baseia-se.
• Representa¸c˜ao adequada dos processos de neg´ocio e variabilidades pelo
diagrama de atividades: o diagrama de atividades demonstrou-se ser de grande
88 5. Exemplo de aplica¸c˜ao
valia para a representa¸c˜ao das variabilidades e intera¸c˜ao dos processos de neg´ocio.
A melhora no entendimento do processo de neg´ocio atrav´es do uso do diagrama de
atividades permite uma facilidade maior no momento da configura¸c˜ao dos processos
neg´ocio e servi¸cos Web para compor o produto final. O diagrama de atividades para
a representa¸c˜ao dos processos de neg´ocio e suas variabilidades ´e um resultado obtido
com a proposta desta abordagem.
• Melhor estrutura¸c˜ao e reuso de informa¸c˜oes envolvidas: a abordagem pro-
posta re-estrutuou a abordagem originalmente proposta por Fantinato (2007), com
o intuito de incluir a representa¸c˜ao de processos de neg´ocio por diagrama de ativi-
dades, para facilitar a reutiliza¸c˜ao dos mesmos aplicando em conjunto os conceitos de
linha de produto. Portanto, a abordagem demonstrou uma melhoria na estrutura¸c˜ao
para o reuso dos processos de neg´ocio e servi¸cos Web.
A abordagem apresenta, tamb´em, pontos fracos que foram observados durante o
desenvolvimento da aplica¸c˜ao demonstrada neste cap´ıtulo, s˜ao eles:
• Necessidade de conhecimento a respeito do modelo de caracter´ısticas: ´e
necess´ario o conhecimento a respeito de modelagem de caracter´ısticas por interm´edio
do modelo de caracter´ısticas. Contudo, Fantinato (2007) n˜ao considera esta t´ecnica
complexa.
• Heterogeneidade das ferramentas que englobam o conjunto FeatureCon-
tract: este ponto fraco deriva-se da abordagem proposta por Fantinato (2007).
Contudo, a problem´atica esta sendo solucionada atrav´es do desenvolvimento de
trabalhos de pesquisa para propor ferramentas que permitam uma homogeneidade
maior. As ferramentas ser˜ao integradas ao projeto InfraPro (Gimenes, 2006).
O pr´oximo cap´ıtulo, 6, apresenta as conclus˜oes gerais desta disserta¸c˜ao, bem como, os
poss´ıveis trabalho futuros.
Cap
´
ıtulo
6
Conclus˜ao
Com o objetivo de facilitar a realiza¸c˜ao e reuso de processos de neg´ocio inter-organizacionais,
esta disserta¸c˜ao apresenta uma abordagem para reutiliza¸c˜ao de processos de neg´ocio.
O reuso de processos de neg´ocio e servi¸cos Web ´e extremamente interessante para as
organiza¸c˜oes por agilizar o desenvolvimento de novos processos de neg´ocio que possuam
as mesmas caracter´ısticas. Portanto, ´e necess´ario existir uma metodologia que apoie o
desenvolvimento e o reuso dos processos.
A RofPN possui dois ciclos de vida. O primeiro ciclo de vida ´e respons´avel por criar
e estabelecer o dom´ınio do processo de neg´ocio, suas variabilidades, servi¸cos e termos
de QoS que s˜ao desenvolvidos e publicados. Ao completar o primeiro ciclo de vida uma
estrutura para a LP e seus componentes ficam dispon´ıveis sendo, portanto, poss´ıvel a
cria¸c˜ao dos produtos da LP reutilizando a estrutura desenvolvida. O segundo ciclo de
vida permite a configura¸c˜ao do dom´ınio especificado anteriormente para a cria¸c˜ao dos
produtos finais. A configura¸c˜ao ´e realizada sobre o modelo de caracter´ıstica, pertencente
ao molde de contrato eletrˆonico, e o diagrama de atividades. Ao final do segundo ciclo de
vida o resultado ´e um processo de neg´ocio configurado com os servi¸cos e termos de QoS
contratados e o desenvolvimento de um contrato eletrˆonico.
A abordagem proposta estendeu a abordagem originalmente proposta por Fantinato
(2007) incluindo a representa¸c˜ao e configura¸c˜ao de processos de neg´ocio e suas variabili-
dades, al´em de, propor a utiliza¸c˜ao do diagrama de atividades para esta representa¸c˜ao.
A modelagem do dom´ınio das operadoras de telecomunica¸c˜oes e agˆencia de viagens
possibilitou analisar a abordagem proposta verificando seus pontos fortes e fracos. A
89
90 6. Conclus˜ao
abordagem permite uma modelagem das variabilidade de processos de neg´ocio considerada
de f´acil entendimento que possibilita uma maior facilidade no momento da configura¸c˜ao
dos produtos finais. A facilidade de configura¸c˜ao de produtos diferentes para um mesmo
dom´ınio de processo de neg´ocio demonstra que a abordagem consegue estruturar os pro-
cessos de neg´ocio e servi¸cos Web de modo que permita uma melhoria quanto `a reutiliza¸c˜ao
dos mesmos.
A representa¸c˜ao dos processos de neg´ocio e suas variabilidade pelo diagrama de ativi-
dades permite `as organiza¸c˜oes usufru´ırem dos benef´ıcios do reuso de seus processos de
neg´ocio e servi¸cos compondo com facilidade os produtos finais e, consequentemente, uma
redu¸c˜ao de custo e tempo de desenvolvimento. O reuso permite, ainda, que a qualidade
dos produtos desenvolvidos sejam confi´aveis partindo do preceito de que as partes que o
comp˜oem j´a foram testadas e est˜ao em utiliza¸c˜ao por outros produtos sem apresentarem
problemas.
Observa-se, ainda, que a representa¸c˜ao das variabilidades de processos de neg´ocio
utilizando o diagrama de atividades da UML permite um entendimento mais claro do
processo de neg´ocio modelado e suas variabilidades por conseguir mostrar n˜ao apenas as
variabilidades, mas, tamb´em, o comportamento dos sistemas envolvidos em um determi-
nado produto da LP. Esta facilidade de entendimento ´e importante no momento da sele¸c˜ao
de variabilidades para a cria¸c˜ao de novos produtos da mesma fam´ılia. O entendimento
e sele¸c˜ao das variabilidades, servi¸cos e termos de QoS que comp˜oem os produtos da
fam´ılia ´e realizado, tamb´em, por interm´edio dos modelos de caracter´ısticas que permitem
a configura¸c˜ao dos mesmos atrav´es das sele¸c˜oes das caracter´ısticas desejadas.
A an´alise dos resultados obtidos permitiu observar que a abordagem proposta possui
como vantagens a representa¸c˜ao adequada por interm´edio dos modelos de caracter´ısticas
dos SW e termos de QoS. Uma representa¸c˜ao adequada por meio do diagrama de ativi-
dades dos processos de neg´ocio e suas variabilidades. Melhor estrutura¸c˜ao e reuso dos
PN, SW e termos de QoS atrav´es da estrutura de LP.
Quanto as desvantagens observou-se a necessidade de conhecimento sobre modelo de
caracter´ısticas. Necessidade de entendimento sobre estrutura de LP para aplica¸c˜ao da
abordagem, desenvolvimento e gerenciamento da estrutura proposta na abordagem para
reutiliza¸c˜ao de processos de neg´ocio.
Como trabalhos futuros ´e observado a necessidade de aplicar e analisar a abordagem
proposta em outros dom´ınios de processos de neg´ocio dentro de organiza¸c˜oes objetivando
um melhoramento na abordagem proposta. Outra necessidade futura ´e o desenvolvimento
do modelo de decis˜ao para melhorar o apoio no momento da sele¸c˜ao das caracter´ısticas
para compor os produtos. O melhoramento das ferramentas j´a propostas para o projeto
91
InfraPro de modo a resolver o problema da heterogeneidade das mesmas. Quanto `a
problem´atica das ferramentas trabalhos de pesquisa est˜ao em desenvolvimento.
92 6. Conclus˜ao
Referˆencias Bibliogr´aficas
Aalst, W. M. P. van der and Hofstede, A. H. M. ter and Weske, M. Business process
managment: A survey. In: Business Process Managment, v. 2678, Springer Berlin /
Heidelberg, p. 1019, lectures Notes in Computer Science, 2003.
Abinader, J. A and Lins, R. D. Web service em java. 1st ed. Brasport, 2006.
Alonso, G et al Web services: Concepts, architectures and applications. 1st ed. Springer,
2004.
Antkiewicz, M. and Czarnecki, K. Featureplugin: Feature modeling plug-in for eclipse.
In: Proceedings of the 2004 OOPSLA workshop on eclipse technology eXchange, 2004,
p. 67–72.
Caetano, A. and Zacarias, M. and Souza, P. and Silva, A. R. and Tribolet, J. A. A
framework for businesss process modeling and alignment. In: IRMA 2007 Business
Process Management Track, 2007, p. 264.
Chen, L. and Wassermann, B. and Emmerich, W. and Foster, H. Web service orches-
tration with bpel. International Conference on Software Engineering, p. 1071–1072,
2006.
Clement, L. Uddi consortium. [On-line], http://www.uddi.org/pubs/uddiv3.htm.
Clements, P. and Northrop, L. Software product lines: Practices and patterns.
Addison-Wesley, 2001.
Clements, P. C. and Jones, L. G. and Mcgregor, J. D. and Northrop L. M. Getting
there from here: A roadmap for software product line adoption mapping the technical
and business activities and steps required for successful organizational adoption.
Communications of the ACM, v. 49, n. 12, 2006.
93
94 REFER
ˆ
ENCIAS BIBLIOGR
´
AFICAS
Czarnecki, K. and Helsen, S. and Eisenecker, U. Staged configuration through
specialization and multi-level configuration of feature models. Software Process:
Improvement and Practive, v. 10, n. 2, p. 143–169, 2005.
Fantinato, M. Uma abordagem baseada em caracter´ısticas para o estabelecimento de
contratos eletrˆonicos para servi¸cos web. Tese de Doutoramento, IC - Instituto de
Computa¸c˜ao, Unicamp - Universidade Estadual de Campinas, Campinas - S˜ao Paulo,
2007.
Garcia, D. Z. G. Incorpora¸c˜ao de qualidade de servi¸co no modelo de servi¸co web.
Disserta¸c˜ao de Mestrado, IC - Instituto de Computa¸c˜ao, Unicamp - Universidade
Estadual de Campinas, Campinas - S˜ao Paulo, 2007.
Gimenes, I. M. S. Infra-estrutura de apoio a processos de neg´ocio baseado em reutiliza¸c˜ao
e aspectos. 2006.
Gimenes, I. M. S. and Travassos, G. H. O enfoque de linha de produto para
desenvolvimento de software. In: JAI - Jornada de Atualiza¸c˜ao em Inform´atica da
SBC, 2002, p. 1–32.
Gomaa, H. Designing software product lines with uml: From uses cases to pattern-based
software architecture. 1st ed. Addison Wesley, 2005.
Kang, K. and kim, S. and Lee, J. and Shin, E. and Huh, M. Form: A feature-oriented
reuse method with domain-specific reference architectures. Annals of Software
Engineering, v. 1, n. 2, p. 143–168, 1998.
Korherr, B. and List, B. Extending the uml 2.0 activity diagrama with business process
goals and performance measures and the mapping to bpel. v. 4231, p. 7–18, 2006.
Korherr, Birgit and List, Beate A uml 2 profile for variability models and their
dependency to business processes, p. 829–834. 2007.
Kradolfer, M. A workflow metamodel supporting dynamic, reuse-based model evolution.
Tese de Doutoramento, Wirtschaftswissenschaftljchen Fakult¨at, Universit¨at Zurich,
Zurich - Germany, 2000.
Leymann, F. and Altenhuber, W. Managing business process as an information resource.
IBM System Journal, v. 33, n. 2, p. 326–348, 1994.
REFER
ˆ
ENCIAS BIBLIOGR
´
AFICAS 95
Leymann, F. and Roller, D. and Schmidt, M. Web services and business process
managment. IBM System Journal, v. 41, n. 2, p. 198–211, 2002.
NewComer, E. Understanding web services - xml, wsdl, soap e uddi. 1st ed. Pearson,
2002.
Northrop, L. and Clements, P. C. A framework for software product line practice, version
5.0. [On-line], http://www.sei.cmu.edu/plp/framework.html.
Oliveira Junior, E. Um processo de gerenciamento de variabilidade para linha de produto
de software. Disserta¸c˜ao de Mestrado, DIN - Departamento de Inform´atica, UEM -
Universidade Estadual de M´aringa, Maring´a - Paran´a, 2005.
Ort, Ed. Service-oriented architecture and web services: Concepts, technologies, and
tools. 1st ed. Sun Microsystems Inc., 2005.
Rumbaugh, J. and Jacobson, I. and Booch, G. The unified modeling language reference
manual. 2nd ed. Addison-Wesley, 2005.
Sadtler, C. and Kovari, P. Websphere business integration server foundation architecture
and overview. IBM Redbooks paper, 2004.
Selic, B. What is new in uml 2.0? IBM Distinguished Engineer, 2005.
Sugumaran, V. and Park, S. and Kang, K. C. Software product line engineering.
Communications of the ACM, v. 49, n. 12, 2006.
Weske, M. Business process management: concepts, languages, architectures. 1st ed.
Springer, 2007.
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
