If you can't read please download the document
Upload
hadat
View
216
Download
0
Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DO ESPRITO SANTO CENTRO TECNOLGICO
DEPARTAMENTO DE INFORMTICA PROGRAMA DE PS-GRADUAO EM INFORMTICA
ANA CHRISTINA DE OLIVEIRA BRINGUENTE
REENGENHARIA DE UMA ONTOLOGIA DE PROCESSO DE SOFTWARE E SEU USO
PARA A INTEGRAO DE FERRAMENTAS DE APOIO AO PLANEJAMENTO DE
PROJETOS
VITRIA 2011
ANA CHRISTINA DE OLIVEIRA BRINGUENTE
REENGENHARIA DE UMA ONTOLOGIA DE
PROCESSO DE SOFTWARE E SEU USO PARA A INTEGRAO DE FERRAMENTAS
DE APOIO AO PLANEJAMENTO DE PROJETOS
Dissertao de Mestrado apresentada ao Programa de Ps-Graduao em Informtica da Universidade Federal do Esprito Santo, como requisito parcial para obteno do Grau de Mestre em Informtica. Orientador: Prof. Dr. Ricardo de Almeida Falbo Co-orientador: Prof. Dr. Giancarlo Guizzardi
VITRIA 2011
ANA CHRISTINA DE OLIVEIRA BRINGUENTE
REENGENHARIA DE UMA ONTOLOGIA DE PROCESSO DE SOFTWARE E SEU USO
PARA A INTEGRAO DE FERRAMENTAS DE APOIO AO PLANEJAMENTO DE
PROJETOS
COMISSO EXAMINADORA
Prof. Dr. Ricardo de Almeida Falbo Departamento de Informtica - UFES Orientador
Prof. Dr. Giancarlo Guizzardi Departamento de Informtica UFES Co-orientador
Prof. Dr. Fernanda Baio Departamento de Informtica Aplicada UNIRIO
Prof. Dr. Monalessa Perini Barcellos Departamento de Informtica UFES
Vitria, 23 de agosto de 2011.
Ao Sinhozinho, Sinhazinha, Entojo e Pobre...
AGRADECIMENTOS
FAPES (Fundao de apoio Cincia e Tecnologia do Esprito Santo), pelo
apoio financeiro, viabilizado por meio da bolsa de mestrado.
RESUMO
Com o crescimento do interesse na rea de integrao entre sistemas de
software, surgiram abordagens que visam tratar este problema. De maneira geral, a
integrao de sistemas pode ocorrer em quatro nveis: de hardware, de plataforma,
sinttico e semntico. No nvel semntico, foco deste trabalho, durante o processo
de integrao, o significado dos componentes envolvidos deve ser o mais claro
possvel, ou seja, o significado pretendido dos conceitos no esquema de dados, nas
assinaturas das operaes e dos servios deve ser explicitado. Neste contexto, uma
ontologia de domnio pode ser utilizada para definir uma representao explcita
dessa conceituao compartilhada e ser usada como referncia durante a
integrao. Este trabalho aplicou a abordagem OBA-SI, uma abordagem de
integrao semntica baseada em ontologia, para integrar na camada de dados
ferramentas que apoiam o planejamento, controle e acompanhamento de projeto de
software. Durante o processo de integrao, foi utilizada uma ontologia de processo
de software, a SPO (Software Process Ontology) para adicionar semntica aos
conceitos das ferramentas envolvidas nesse processo. Para servir adequadamente
como um modelo de referncia, a SPO passou por um processo de reengenharia
baseada na UFO (Unified Foundational Ontology), uma ontologia de fundamentao.
ABSTRACT
The increasing interest in the area of integration between software systems has
promoted the emergence of approaches to address this issue. In general, systems
integration can occur at four levels, namely hardware, platform, syntactic and
semantic levels. At the semantic level, which is the focus of this work, the meaning of
the involved components must be as clear as possible during the integration process.
In other words, the intended meaning of concepts in the data schema, operations
signatures and services should be made explicit. In this context, a domain ontology
can be used to define an explicit representation of this shared conceptualization and
as reference during the integration process. This work applies the approach OBA-SI,
which is an approach of ontology-based semantic integration, to integrate the data
layer of the tools that support the software project planning, control and tracking.
During the integration process, a software process ontology (SPO) is used to add
semantics to the concepts of the tools involved in this process. In order to suitably
serve as a reference model, the SPO has gone through a reengineering process
based on UFO (Unified Foundational Ontology).
LISTA DE FIGURAS
Figura 1 Conceitos disjuntos.................................................................................................20
Figura 2 Interseo de Conceitos .........................................................................................20
Figura 3- Smbolos iguais que representam conceitos contidos ...............................................21
Figura 4 - Smbolos distintos com conceitos equivalentes ........................................................21
Figura 5 Smbolos distintos com conceitos sobrepostos .......................................................22
Figura 6 Smbolos distintos com conceitos contidos .............................................................22
Figura 7 - Relacionamentos entre modelos de OBA-SI ............................................................26
Figura 8 - Mapeamentos verticais e horizontais .......................................................................28
Figura 9 UFO-A: Individual e Universal ................................................................................38
Figura 10 UFO-A: Substantial e Moment ..............................................................................38
Figura 11 UFO-A: Sortal .......................................................................................................39
Figura 12 UFO-A: Tipos de moments ...................................................................................42
Figura 13 UFO-A: Tipos de Relaes ...................................................................................42
Figura 14 Viso geral dos conceitos da UFO-A.....................................................................44
Figura 15 - UFO-B: Evento ......................................................................................................46
Figura 16 - UFO-C: Distino entre Agente e Objeto ...............................................................47
Figura 17 UFO-C: Intentional Moment ..................................................................................48
Figura 18 - Tipos de comprometimento ...................................................................................49
Figura 19 - UFO-C: Delegao. ...............................................................................................50
Figura 20 - UFO-C: Ao. ........................................................................................................51
Figura 21 Fragmento Ontologia de Processo de Software ....................................................54
Figura 22 Reengenharia da Ontologia de Processo de Software ..........................................55
Figura 23 Definio de Processo Padro ..............................................................................58
Figura 24 Definio do Processo de Projeto. ........................................................................59
Figura 25 - Definio do Processo de Projeto baseado em um Processo Padro.....................60
Figura 26 Processo de Projeto Programado .........................................................................62
Figura 27 - Recursos definidos para as atividades ...................................................................63
Figura 28 Alocao de um recurso humano em um projeto ...................................................64
Figura 29 Alocao de Recurso Humano em uma Atividade .................................................65
Figura 30 Ocorrncia de Processo e de Atividade.................................................................66
Figura 31 Participaes de Recursos na ocorrncia de atividades. .......................................67
Figura 32 Verso atual da Ontologia de Processo de Software .............................................69
Figura 33 Modelo conceitual Def-Pro Processo Padro .....................................................74
Figura 34 - Modelo conceitual Def-Pro - Controle Processo .....................................................76
Figura 35 Modelo conceitual AlocaODE................................................................................77
Figura 36 Modelo conceitual ControlPro ...............................................................................79
Figura 37 Modelo Conceitual Endeavour ..............................................................................80
Figura 38 - Modelo de Integrao Definio de Processo Padro .........................................85
Figura 39 - Modelo de Integrao Definio de Processo de Projeto.....................................86
Figura 40 - Modelo de Integrao Alocao de Recurso .......................................................87
Figura 41 Modelo de Integrao Execuo da Atividade ....................................................88
Figura 42 - Modelo de Integrao ............................................................................................89
SUMRIO 1 INTRODUO ........................................................................................................................................... 10
1.1 OBJETIVOS ............................................................................................................................ 12
1.2 HISTRICO DO DESENVOLVIMENTO DO TRABALHO ......................................................... 13
1.3 ORGANIZAO DO TRABALHO ............................................................................................ 14
2 INTEGRAO SEMNTICA ...................................................................................................................... 15
2.1 INTEROPERABILIDADE ......................................................................................................... 16
2.1.1 Nveis de integrao................................................................................................................ 18
2.2 ABORDAGENS DE INTEGRAO SEMNTICA .................................................................... 23
2.2.1 OBA-SI: Ontology-Based Approach For Semantic Integration .................................................. 24
2.3 PLANEJAMENTO DE PROJETO E PROCESSO DE SOFTWARE ........................................... 30
2.3.1 Ferramentas de Apoio ao Planejamento de Processo de Software .......................................... 32
2.4 CONSIDERAES FINAIS ..................................................................................................... 34
3 A ONTOLOGIA DE FUNDAMENTAO UNIFICADA ................................................................................ 36
3.1 UFO-A ................................................................................................................................ 37
3.2 UFO-B ................................................................................................................................ 45
3.3 UFO-C ................................................................................................................................ 46
4 REENGENHARIA BASEADA NA UFO DA ONTOLOGIA DE PROCESSO DE SOFTWARE ....................... 52
4.1 ONTOLOGIA DE PROCESSO................................................................................................. 53
4.2 REENGENHARIA DA ONTOLOGIA DE PROCESSO .............................................................. 56
4.2.1 Definio do Processo Padro ................................................................................................ 56
4.2.2 Definio do Processo de Projeto e Agendamento .................................................................. 58
4.2.3 Tipos de Recurso .................................................................................................................... 62
4.2.4 Alocao de Recursos Humanos ............................................................................................. 63
4.2.5 Ocorrncia de Atividade .......................................................................................................... 65
4.3 CONSIDERAES FINAIS ..................................................................................................... 68
5 INTEGRANDO CONCEITUALMENTE FERRAMENTAS DE APOIO AO PLANEJAMENTO DE PROJETOS DE SOFTWARE ........................................................................................................................... 71
5.1 MODELOS CONCEITUAIS ESTRUTURAIS DAS FERRAMENTAS ......................................... 73
5.1.1 Modelo Conceitual Estrutural de Def-Pro ................................................................................. 74
5.1.2 Modelo Conceitual Estrutural de AlocaODE ............................................................................. 77
5.1.3 Modelo Conceitual Estrutural de ControlPro ............................................................................ 78
5.1.4 Modelo Conceitual Estrutural de Endeavour ............................................................................ 79
5.2 MAPEAMENTOS VERTICAIS ................................................................................................. 81
5.3 MODELO DE INTEGRAO ................................................................................................... 84
5.4 CONSIDERAES FINAIS ..................................................................................................... 90
6 CONCLUSO ............................................................................................................................................ 92
6.1 TRABALHOS FUTUROS ......................................................................................................... 94
REFERNCIAS.......................................................................................................................................... 97
10
1 INTRODUO
O gerenciamento de projetos envolve a aplicao de conhecimento,
habilidades, ferramentas e tcnicas s atividades do projeto, a fim de atender aos
seus requisitos. Um projeto um empreendimento integrado e requer que cada um
de seus processos seja alinhado e conectado de forma apropriada com os outros
processos para facilitar sua coordenao. As aes adotadas durante um processo
em geral afetam, alm do processo em si, outros processos relacionados. O
gerenciamento de projetos bem sucedido inclui gerenciar ativamente essas
interaes para cumprir os requisitos das partes interessadas (PMI, 2008).
Entre os processos de um projeto, podemos destacar os processos de
Planejamento de Projeto e Acompanhamento e Controle de Projeto. Durante o
planejamento do projeto, o processo do projeto deve ser definido, o cronograma
estabelecido, bem como um plano de recursos humanos. Baseado neste
planejamento, com o projeto em andamento, necessrio acompanhar e controlar o
projeto, verificando se o planejamento est sendo cumprido, se ele precisa ser
revisto e o que deve ser feito para corrigir eventuais desvios.
No contexto de projetos de software, durante o planejamento do projeto,
processos de software padro so utilizados como base para a definio de
processos de projeto. Uma vez que os processos de projeto esto definidos,
necessrio definir a equipe do projeto, quais os papis que um recurso humano vai
desempenhar em uma determinada atividade, quais os tipos de recursos requeridos
e assim por diante. Durante a execuo do projeto, as atividades devem ser
controladas e monitoradas, registrando seu tempo de durao e a participao de
cada recurso humano na atividade, bem como o esforo por ele despendido.
Geralmente, diferentes ferramentas so usadas para apoiar tais tarefas.
Considerando que essas tarefas so iterativas e inter-relacionadas, idealmente
essas ferramentas devem interoperar para apoiar efetivamente os processos de
gerncia de projeto.
11
De maneira geral, a integrao de sistemas pode se dar em trs camadas
diferentes (IZZA, 2009): a integrao na camada de dados lida com a troca de dados
entre os aplicativos; a integrao na camada de mensagens ou servios trata da
troca de mensagens e servios entre os sistemas; por fim, a integrao na camada
de processo responsvel por tratar o fluxo de mensagens, regras de execuo e
definir o processo de execuo global.
A integrao pode acontecer, ainda, em diferentes nveis. O nvel de hardware
envolve diferentes computadores, redes de computadores, etc. O nvel de plataforma
trata de sistemas operacionais, sistemas de bancos de dados, etc. O nvel sinttico
refere-se a como os modelos de dados e as assinaturas das operaes so escritos.
Por fim, o nvel semntico abrange o significado pretendido dos conceitos no
esquema de dados e nas assinaturas das operaes. Cada um dos nveis
construdo sobre o anterior, de modo que no faz sentido falar em integrao no
nvel sinttico se no existe integrao no nvel de plataforma (IZZA, 2009).
Para que as ferramentas trabalhem em conjunto de forma satisfatria,
necessrio que elas compartilhem uma conceituao sobre o domnio de processos
de software. Neste contexto, uma ontologia de domnio pode ser utilizada para
definir uma representao explcita dessa conceituao compartilhada.
Uma ontologia pode ser definida como uma especificao de um vocabulrio
para representao de um domnio compartilhado de discurso (GUIZZARDI, 2005).
Em outras palavras, uma ontologia um modelo de domnio, composto por um
conjunto de conceitos e relaes. Uma ontologia til para fornecer uma
compreenso clara sobre um determinado domnio.
Contudo, para servir adequadamente como um modelo de referncia, uma
ontologia de domnio deve ser construda usando uma abordagem que leve em
conta explicitamente conceitos de fundamentao. Uma ontologia de domnio de
referncia tem o propsito de representar um domnio de discurso com clareza,
veracidade e expressividade, sem considerar requisitos computacionais. O principal
objetivo desse modelo de referncia ajudar modeladores a externalizar seu
conhecimento sobre o domnio, tornando seus comprometimentos ontolgicos
explcitos, de modo a apoiar a negociao de significado e melhorar a comunicao,
12
aprendizado e resoluo de problemas no domnio. Para que atinja tais objetivos,
uma ontologia de referncia deve ser construda levando em conta uma ontologia de
fundamentao (GUIZZARDI et al., 2008).
1.1 OBJETIVOS
Levando em considerao as motivaes apresentadas, o objetivo geral deste
trabalho integrar conceitual e semanticamente ferramentas de apoio ao processo
de Gerncia de Projetos de Software na camada de dados. Para a integrao ser
utilizada, ento, uma ontologia de referncia do domnio de processos de software
que considera as distines ontolgicas feitas em uma ontologia de fundamentao,
a UFO (Unified Foundational Ontology) (GUIZZARDI, 2005) (GUIZZARDI et al.,
2008).
Esse objetivo geral pode ser detalhado nos seguintes objetivos especficos:
Fazer a reengenharia da Ontologia de Processo de Software baseado na
UFO:
Uma vez que j existe uma ontologia de processos de software desenvolvida
(BERTOLLO, 2006) e parcialmente alinhada aos conceitos da UFO
(GUIZZARDI et al., 2008), um objetivo especfico desta dissertao avanar
na reengenharia dessa ontologia. Essa reengenharia tem o intuito de
explicitar os compromissos ontolgicos da ontologia de processos de
software.
Aplicar uma abordagem de integrao semntica para integrar
conceitualmente as ferramentas escolhidas.
Neste trabalho, tem-se como ponto de partida um conjunto inicial de
ferramentas a serem integradas: as ferramentas de apoio ao processo de
Gerncia de Projetos do ambiente ODE (Ontology-based software
Development Environment) (FALBO et al., 2005). Assim, necessrio
selecionar uma ferramenta de Gerncia de Projeto que atenda a requisitos
tidos como necessrios para que o processo de Gerncia de Projetos de
13
Software seja atendido aps a integrao. Para a integrao, foi aplicada
OBA-SI (CALHAU; FALBO, 2010), uma abordagem de integrao semntica
de sistemas de informao.
1.2 HISTRICO DO DESENVOLVIMENTO DO TRABALHO
Para alcanar os objetivos listados na seo anterior, foram realizadas as
atividades descritas a seguir.
Inicialmente, foi feito um levantamento bibliogrfico relacionado ao tema
Interoperabilidade Semntica. O intuito deste estudo foi levantar como o problema
de interoperabilidade est sendo tratado pela comunidade cientfica. Durante este
estudo notou-se que, apesar de existir um consenso sobre a importncia do uso de
ontologias para a integrao semntica, pouco se relata sobre a qualidade dessas
ontologias e como elas, de fato, devem ser usadas. Sendo assim, optou-se por, no
apenas utilizar uma ontologia no processo de integrao, mas utilizar uma ontologia
de domnio que fosse elaborada com base em uma ontologia de fundamentao.
Uma vez que este trabalho visa discutir a integrao no nvel conceitual, foi de
extrema importncia utilizar uma abordagem de integrao semntica que enfoque
os aspectos no computacionais da integrao.
Como as ferramentas a serem integradas so ferramentas que apoiam a
gerncia de projetos de software, foi feito um estudo sobre este domnio. O estudo
possibilitou reconhecer dentro do ambiente ODE quais eram os pontos que no
eram devidamente apoiados pelas ferramentas e, consequentemente, quais os
requisitos que a ferramenta externa deveria atender.
Uma vez que as ferramentas seriam integradas no nvel conceitual, a
ontologia utilizada como interlngua entre os modelos conceituais das ferramentas
deveria ser construda de maneira a maximizar a expressividade na captura de
aspetos fundamentais do domnio subjacente e tornar explcitos os compromissos
ontolgicos. Para tal, a ontologia de processo de software passou por um processo
de reengenharia baseado na UFO para atender a tais requisitos.
14
Com a ontologia de referncia e as ferramentas a serem integradas definidas,
deu-se incio ao processo de integrao semntica de acordo com a abordagem
OBA-SI.
Parte dos resultados obtidos neste trabalho foram descritos em um artigo
cientfico, o qual foi apresentado no XXVI Simpsio Brasileiro de Banco de Dados
(SBBD 2011) e publicado no Journal of Information and Data Management JIDM.
1.3 ORGANIZAO DO TRABALHO
Esta dissertao est organizada em seis captulos. Alm deste captulo, que
apresenta a Introduo, h mais cinco captulos com o seguinte contedo:
Captulo 2 Integrao Semntica: apresenta uma reviso da literatura
sobre Interoperabilidade Semntica e sobre o domnio de estudo desta
dissertao: a Gerncia de Projetos de Software.
Captulo 3 A Ontologia de Fundamentao Unificada: apresenta a
ontologia de fundamentao UFO, fazendo uma breve explicao dos
conceitos necessrios para este trabalho.
Captulo 4 Reengenharia Baseada na UFO da Ontologia de Processo
de Software: apresenta a reengenharia da ontologia de processo de
Software baseada na UFO.
Captulo 5 Integrando Conceitualmente Ferramentas de Apoio ao
Planejamento de Projetos de Software: apresenta a iniciativa de
integrao semntica no nvel conceitual, utilizando OBA-SI, realizada
visando integrar as ferramentas do ambiente ODE com a ferramenta
Endeavour.
Captulo 6 Consideraes Finais: apresenta as concluses do
trabalho, as contribuies, dificuldades e propostas de trabalhos futuros.
15
2 INTEGRAO SEMNTICA
Atualmente, cresce a necessidade dos sistemas de informao interoperarem
de forma a apoiarem os objetivos das organizaes. Podemos citar como uma das
causas o crescente nmero de fuses entre empresas. Quando isso ocorre,
sistemas que antes trabalhavam de forma independente passam a ter que trabalhar
integrados para apoiar os processos de negcio satisfatoriamente. Podemos citar,
ainda, ferramentas que executam tarefas complementares dentro de um processo
como, por exemplo, ferramentas que apoiam diferentes fases do processo de
desenvolvimento de software. Durante esse processo comum que artefatos
produzidos em uma fase sejam consumidos por outra e, portanto, ideal que essas
ferramentas sejam capazes de se comunicar entre si, sem a necessidade de
interveno manual.
Na busca por solues para o problema apresentado acima, tem-se
despendido muito tempo e dinheiro. Em 2002, estimava-se que as grandes
organizaes gastavam cerca de 40% do seu oramento destinado tecnologia com
este problema e que isto aumentaria com o passar dos anos (SERAIN, 2002). Isto
implicou no crescimento do interesse na rea de interoperabilidade e,
consequentemente, surgiram abordagens que visam solucionar este problema. As
abordagens diferenciam-se entre si, entre outros fatores, pelo nvel de
interoperabilidade que se deseja entre os componentes de software.
Este captulo aborda o problema de Interoperabilidade Semntica, bem como
as possveis abordagens para a sua soluo. Ele est estruturado da seguinte
forma: a Seo 2.1 apresenta o problema da falta de interoperabilidade; a Seo 2.2
apresenta a abordagem de integrao semntica adotada neste trabalho; a Seo
2.3 apresenta um cenrio de necessidade de integrao de ferramentas para apoiar
o planejamento de projetos de software; e a Seo 2.4, por fim, apresenta as
consideraes finais do captulo.
16
2.1 INTEROPERABILIDADE
Interoperabilidade em um contexto amplo pode ser definida como a habilidade
de operar em conjunto ou, mais especificamente no contexto de sistemas
computacionais, como a capacidade de trocar dados e servios entre aplicativos ou
componentes de aplicativos (VERNADAT 1996, WEGNER, 1996). Esses aplicativos,
por sua vez, podem ser classificados de acordo com a heterogeneidade existente
entre eles (IZZA et al. 2005). Heterogneo significa que cada aplicao implementa
seu prprio modelo de dados e de processo. Quanto maior a diferena entre esses
modelos, sejam por conflitos sintticos ou semnticos, mais difcil e complexo
torn-los interoperveis (IZZA, 2009).
H diversas dimenses de integrao que ajudam a caracterizar a noo de
integrao e que podem ser usadas para classificar as abordagens de integrao.
Izza (2009) prope quatro dimenses:
Escopo da integrao: A integrao pode se dar dentro da organizao,
envolvendo apenas aplicaes da mesma, ou entre organizaes,
conectando aplicaes de diferentes parceiros.
Pontos de vista da integrao: A integrao pode focar o ponto de vista do
usurio, do projetista ou do programador. O ponto de vista do usurio
preocupa-se as diferentes vises que especialistas de domnio e usurios
de negcio tm. O ponto de vista do projetista enfoca os diferentes
modelos usados durante o projeto de sistemas de informao (viso
conceitual). Finalmente, o ponto de vista do programador refere-se
implementao dos sistemas.
Camadas de integrao: A integrao de aplicativos pode ocorrer em trs
camadas: camada de dados, camada de mensagem ou servio e camada
de processo. A camada de dados lida com a troca de dados entre vrios
repositrios. Neste ponto, uma aplicao manipula os dados de outra
aplicao diretamente no banco de dados, atravs de sua interface nativa,
ignorando a lgica da aplicao. A integrao na camada de mensagens
17
ou servios ocorre quando duas ou mais aplicaes trocam mensagens
entre si. Por fim, a ltima camada, a camada de processo constitui a
integrao mais complexa, pois ela enxerga uma organizao como uma
srie de processos relacionados e os sistemas responsveis pela
execuo desse processo no podem ser vistos como ilhas de
informaes. Dessa forma a integrao nessa camada responsvel por
tratar o fluxo de mensagens, regras de execuo e definir o processo de
execuo global.
Nveis de integrao: Como dito anteriormente, a integrao pode
acontecer em diferentes nveis, a saber: nvel de hardware, de plataforma,
sinttico e semntico. O nvel de hardware envolve a integrao de
diferentes computadores, redes de computadores etc. Neste nvel
utilizado, por exemplo, protocolos de redes para que duas ou mais redes
possam se comunicar. O nvel de plataforma trata de sistemas
operacionais, sistemas de bancos de dados etc. O nvel sinttico refere-se
ao modo como modelos de dados e assinaturas de operaes so
escritos. Por fim, o nvel semntico abrange o significado pretendido dos
conceitos no esquema de dados e nas assinaturas das operaes. Cada
um dos nveis construdo sobre o anterior. Dessa forma, no faz sentido
falar em integrao no nvel sinttico se no existe integrao no nvel de
plataforma .
Nesta dissertao, trabalha-se a integrao segundo o ponto de vista do
projetista, na camada de dados e no nvel semntico. Interesse especial est nesta
ltima dimenso, a qual discutida com mais detalhes a seguir.
18
2.1.1 Nveis de integrao
Conforme discutido anteriormente, a integrao pode acontecer em diferentes
nveis, a saber: nvel de hardware, plataforma, sinttico e semntico. Os de maior
interesse para este trabalho so os nveis sinttico e semntico, os quais so
discutidos mais detalhadamente nesta seo.
2.1.1.1 Integrao Sinttica
A sintaxe define uma lista de palavras vlidas em uma determinada linguagem
e as regras que governam como essas palavras sero combinadas para que formem
sentenas vlidas (POKRAEV, 2009). Dois ou mais sistemas esto integrados
sintaticamente quando eles so capazes de trocar dados e servios. Para tal,
essencial a especificao de protocolos de comunicao que descrevam como esta
troca vai ocorrer. Podemos citar XML ou SQL como padres que proveem
interoperabilidade sinttica.
Quando dois sistemas esto integrados sintaticamente, possvel detectar
erros sintticos como, por exemplo, chamar um servio passando um parmetro de
tipo incompatvel com o esperado. Contudo, abordagens sintticas no preveem
erros semnticos, onde a sintaxe est correta, contudo, a semntica no. Estudos
apontavam em 2005 que 70% das tentativas de integrao que se limitavam a este
nvel no eram bem sucedidas (HALLER et al, 2005).
Lidar com o problema de integrao sinttica foge do escopo desta
dissertao. Por esta razo ns focaremos no problema de interoperabilidade
semntica
19
2.1.1.2 Integrao Semntica
Semntica refere-se ao significado dos construtores sintticos em uma
determinada linguagem. Para exemplificar o que semntica no contexto de
sistemas computacionais, podemos pensar em um mtodo escrito em Java com a
seguinte assinatura:
public Double CalculaComprimentoCirculo (Double x);
Este mtodo recebe como parmetro o raio de um crculo e calcula o
comprimento do mesmo. Suponha um programador que utilizar este mtodo e que
conhea a linguagem. Ele ser capaz de deduzir, apenas olhando, que o mtodo
calcula o comprimento de um crculo. Contudo, uma vez que a semntica do
parmetro x no est explcita, caber ao programador atribuir significado a esse
parmetro. Tal situao pode trazer consequncias indesejadas, pois o programador
pode entender que x representa o dimetro do crculo e usar incorretamente o
mtodo. Desta forma, mesmo conhecendo a sintaxe da linguagem, ocorreria um
erro, pois a semntica do parmetro no est explcita.
Neste contexto, podemos definir semntica como sendo o mapeamento de
um objeto de um sistema de informao para o objeto no mundo real que ele
representa (POKRAEV, 2009). Desta forma, interoperabilidade semntica a
capacidade de dois ou mais sistemas heterogneos e distribudos trabalharem em
conjunto, compartilhando as informaes entre eles com entendimento comum de
seu significado (BURANARACH, 2001).
De acordo com Pokraev (2009), ao integrar dois sistemas, podemos ter os
seguintes problemas de interoperabilidade semntica:
i. Diferentes sistemas usam o mesmo smbolo para representar
conceitos disjuntos.
Por exemplo, um sistema usa o smbolo Amazonas para
representar o conceito estado venezuelano, enquanto outro sistema
20
usa o mesmo smbolo para representar o conceito estado brasileiro
(Figura 1).
Sistema 1 Sistema 2
Amazonas Amazonas
estado venezuelano
estado
brasileiro
Figura 1 Conceitos disjuntos
ii. Diferentes sistemas usam o mesmo smbolo para representar
conceitos que se sobrepe.
Por exemplo, um sistema usa o smbolo animal para representar
o conceito animal mamfero, enquanto outro sistema usa o mesmo
smbolo para representar o conceito animal carnvoro. Uma vez que
nem todos mamferos so carnvoros e vice-versa, em alguns casos, o
smbolo animal pode se referir a entidades diferentes no mundo real
(Figura 2).
Sistema 1 Sistema 2
animal animal
animal
carnvoro
animal
mamfero
Figura 2 Interseo de Conceitos
iii. Sistemas diferentes usam o mesmo smbolo para representar
conceitos com significados mais gerais (ou especficos).
21
Por exemplo, um sistema usa o smbolo Floresta Amaznica
para representar a Amaznia Legal, enquanto outro sistema usa o
mesmo smbolo para representar o conceito Floresta Amaznica (a
floresta est presente em nove naes) (Figura 3).
Sistema 1 Sistema 2
Floresta
Amaznica
Floresta
Amaznica
Floresta Amaznica
Amaznia Legal
Figura 3- Smbolos iguais que representam conceitos contidos
iv. Sistemas diferentes usam smbolos diferentes para representar o
mesmo conceito.
Por exemplo, um sistema usa o smbolo comprador para
representar o conceito algum que adquire bens ou servios
enquanto outro sistema utiliza o smbolo cliente para representar o
mesmo conceito (Figura 4).
Sistema 1 Sistema 2
comprador cliente
Algum que adquire
bens ou servios
Figura 4 - Smbolos distintos com conceitos equivalentes
v. Diferentes sistemas usam smbolos diferentes para representar
conceitos com sobreposio de significados.
22
Por exemplo, um sistema usa o smbolo empregado para
representar o conceito algum que trabalha na empresa, enquanto
outro sistema usa o smbolo cliente para representar o conceito
algum que adquire um produto da empresa (Figura 5).
Sistema 1 Sistema 2
empregado cliente
algum que adquire
um produto
da empresa
algum que trabalha
na empresa
Figura 5 Smbolos distintos com conceitos sobrepostos
vi. Diferentes sistemas usam smbolos diferentes para representar
conceitos com significados mais gerais ou especficos.
Por exemplo, um sistema pode usar o smbolo esprito-santense
para representar o conceito pessoa que nasceu no Esprito Santo,
enquanto outro sistema pode utilizar o smbolo brasileiro para
representar o conceito pessoa que nasceu no Brasil (Figura 6).
Sistema 1 Sistema 2
esprito-
santensebrasileiro
Cidado brasileiro
Cidado
esprito-santense
Figura 6 Smbolos distintos com conceitos contidos
As incompatibilidades semnticas foram apresentadas para pontuar quais os
tipos de problemas semnticos que podem surgir quando dois sistemas
23
computacionais esto sendo integrados. importante salientar que esses problemas
acontecem no apenas com os conceitos, mas tambm com os relacionamentos que
existem entre os conceitos.
2.2 ABORDAGENS DE INTEGRAO SEMNTICA
Para cada um dos nveis de interoperabilidade citados anteriormente, existem
diferentes abordagens utilizadas para que ela seja alcanada. Para o nvel de
integrao semntica, que o foco desta dissertao, as abordagens baseiam-se na
representao e explorao da semntica dos sistemas de informao durante o
processo de integrao. Algumas delas apoiam tanto a integrao na camada de
dados quanto de servios e processos (IZZA; VINCENT; BURLAT, 2005; BOURAS
et al. 2006; POKRAEV et al. 2006). Outras abordagens cobrem apenas
determinadas camadas (TEKTONIDIS et al., 2005, JIN; CORDY, 2006). Existem
abordagens que usam servios web (web services) e outras que focam no uso de
uma linguagem de ontologia.
Entretanto, essas abordagens, em sua maioria, focam nos aspectos
tecnolgicos da soluo de integrao. Calhau e Falbo (2010), por sua vez,
defendem que a integrao semntica deve ser independente de como a integrao
ser implementada. Assim como no processo de desenvolvimento de software, o
processo de integrao deve iniciar no nvel conceitual. Apenas depois de
considerar os requisitos de integrao e construir um modelo conceitual da
integrao, os aspectos tecnolgicos devem ser considerados.
Este trabalho usa a viso proposta em OBA-SI (CALHAU; FALBO, 2010), ou
seja, focar nas questes conceituais da integrao semntica. A seguir
detalharemos a abordagem OBA-SI, com foco na integrao semntica na camada
de dados.
24
2.2.1 OBA-SI: Ontology-Based Approach For Semantic Integration
A Abordagem baseada em Ontologias para a Integrao Semntica (Ontology-
Based Approach for Semantic Integration OBA-SI), analogamente ao processo de
desenvolvimento de software, defende o uso de um processo composto das
seguintes atividades: anlise, projeto, implementao e testes. OBA-SI, no entanto,
est centrada na primeira fase, a anlise da integrao, dando apenas algumas
orientaes para a fase de projeto. De acordo com OBA-SI, a semntica deve ser
definida no incio do processo de integrao, na fase de anlise. Isto porque as
ferramentas devem concordar semanticamente antes da concepo e
implementao de uma soluo especfica. Desta forma, OBA-SI procura ser
independente da tecnologia e de uma soluo de integrao especfica. Durante a
fase de anlise, mapeamentos semnticos so feitos entre os modelos conceituais
das ferramentas que esto sendo integradas, usando ontologias para atribuir
significado.
Na fase de anlise, trs artefatos so muito importantes: (i) uma ontologia de
domnio de referncia que descreve o domnio de integrao, (ii) os modelos
conceituais dos aplicativos que esto sendo integrados (modelos estruturais e
comportamentais) e (iii) o modelo de processo de negcio que est sendo apoiado
pelas ferramentas. A ontologia de referncia, como dito anteriormente, uma
especificao independente da soluo utilizada para descrever de forma clara e
precisa as entidades do domnio. Ela usada como um modelo de referncia para
atribuir semntica durante a anlise da integrao. Os modelos conceituais dos
aplicativos que esto sendo integrados podem ser conhecidos a priori (por exemplo,
as aplicaes foram desenvolvidas pela organizao e os modelos conceituais esto
disponveis), ou devem ser escavados por meio de tcnicas de engenharia
reversa. O modelo de processo de negcios, por sua vez, deve descrever os
processos da organizao envolvidos no cenrio de integrao, indicando, dentre
outros, as atividades, os recursos humanos, as ferramentas de apoio e as entradas e
sadas de cada fase do processo.
25
Esses modelos se concentram em diferentes aspectos da integrao. A
ontologia de domnio de referncia, juntamente com os modelos conceituais das
ferramentas, so utilizados para estabelecer a semntica das camadas de dados e
de servios. O modelo do processo de negcios usado principalmente para tratar
da integrao de processos, embora tambm seja til na integrao dos servios.
Como resultado da fase de anlise, um modelo de integrao produzido,
capturando a imagem global do cenrio de integrao. O modelo de integrao
especifica: (i) os conceitos a serem representados, (ii) como o conjunto de
ferramentas integradas vai se comportar como um todo e (iii) quais as atividades do
processo que sero atendidas pelas ferramentas integradas. O modelo de
integrao construdo com base nos requisitos de integrao e os trs artefatos
mencionados anteriormente. De fato, o objetivo principal do modelo de integrao
estabelecer mapeamentos entre os modelos das ferramentas que esto sendo
integradas. Esses mapeamentos so discutidos a seguir.
a) Mapeamentos entre modelos
O objetivo de um mapeamento relacionar os elementos de modelos distintos
que so conceitualmente equivalentes. Mapeamentos ocorrem principalmente em
dois nveis: vertical e horizontal.
Mapeamentos verticais (MVs) so responsveis pela atribuio de significado
para os elementos do modelo com base na ontologia de referncia. Eles so
independentes da soluo de integrao. Seu objetivo atribuir significado para as
entidades das ferramentas, relacionando-as com as entidades na ontologia de
referncia. Uma vez que os MVs relacionam os elementos do modelo com os
conceitos da ontologia, eles so independentes do cenrio de integrao e podem
ser usados em vrias iniciativas de integrao.
26
Mapeamento Vertical
Mapeamento Horizontal
Modelo
Conceitual A
Modelo
Conceitual B
Modelo de
Integrao
Ontologia de
Referncia
Modelo
Conceitual C
Figura 7 - Relacionamentos entre modelos de OBA-SI
Mapeamentos horizontais (MHs), por outro lado, ocorrem entre os elementos
dos modelos, focando no cenrio de integrao. Ao estabelecer os MHs, os
elementos dos modelos das ferramentas so mapeados para elementos do modelo
de integrao, como ilustrado na Figura 7. Os MHs definem como as ferramentas
sero vistas pelo mediador de integrao e como a interao entre eles ocorrer.
Idealmente, MHs devem basear-se nos MVs. No entanto, uma vez que MHs focam
em um cenrio de integrao especfico, eles nem sempre se baseiam no MVs.
b) A Fase de Anlise da Integrao
A fase de anlise de OBA-SI abrange as seguintes atividades: (i) especificao
de requisitos de integrao, (ii) recuperao de modelos conceituais; (iii) atribuio
semntica aos modelos conceituais estruturais das ferramentas e (iv) a modelagem
da integrao.
Durante a atividade de especificao de requisitos da integrao, os requisitos
e os objetivos da integrao devem ser definidos. Inicialmente, os objetivos da
integrao devem ser estabelecidos. Com base neles, os requisitos podem ser
levantados. O escopo da integrao deve ser definido, apontando quais atividades
do processo de negcio sero apoiadas e quais aplicaes devem ser integradas
para tal. As atividades do processo de negcio e as aplicaes a serem integradas
27
compem o cenrio de integrao. Caso os modelos de processo de negcio no
estejam disponveis, devero ser desenvolvidos como parte do projeto de
integrao.
Uma vez definido o cenrio de integrao, devem-se obter os modelos
conceituais estruturais e comportamentais das ferramentas. Precisamos tambm
selecionar uma ontologia de referncia sobre o domnio do cenrio de integrao
que, caso no esteja disponvel, deve ser desenvolvida.
O prximo passo atribuir semntica aos modelos conceituais, definindo os
mapeamentos verticais entre seus conceitos e relaes e os conceitos e relaes da
ontologia de referncia. Esses mapeamentos devem ser validados por um
especialista de domnio.
Uma vez que os modelos estruturais esto semanticamente anotados, a
modelagem da integrao pode comear. O propsito do modelo de integrao
modelar os aspectos estruturais e comportamentais da integrao no nvel
conceitual, considerando os requisitos especificados anteriormente. bastante
semelhante a um modelo conceitual em qualquer processo de desenvolvimento. A
principal diferena que o modelo de integrao construdo baseado na ontologia
e nos modelos das ferramentas. Desta forma, a diferena semntica entre o modelo
de integrao e os modelos das ferramentas ser menor.
O modelo de integrao a sada principal da fase de anlise de OBA-SI. Ele
construdo intercalando as abordagens top-down e bottom-up. Inicialmente, um
modelo preliminar construdo com base nos requisitos, no modelo de processo de
negcio e na ontologia de referncia, em uma abordagem top-down. Em seguida,
este modelo refinado, considerando os modelos conceituais das ferramentas a
serem integradas, em uma abordagem bottom-up. Com uma verso mais refinada
do modelo de integrao, os MHs devem ser estabelecidos, ou seja, feito um
mapeamento entre os conceitos dos modelos que esto sendo integrados.
A Figura 8 ilustra um cenrio de integrao, onde dois modelos conceituais
estruturais devem ser mapeados para o modelo de integrao luz de uma
28
ontologia de domnio. Os MVs mapeiam os conceitos das ferramentas e do modelo
de integrao com a ontologia, como os mapeamentos (b2, o2) e (a2, o2). Os MHs
so, ento, estabelecidos com base nos MVs, como o caso dos mapeamentos (a2,
i2) e (b2, i2). No entanto, pode haver MHs, tais como (a3, i3) e (b3, i3), que no so
baseadas em um MV. Isso pode ocorrer porque a ontologia a referncia pode no
abranger todos os elementos do modelo considerado pelos aplicativos.
No mapeamento estrutural (camada de dados), inicialmente mapeiam-se os
conceitos. Uma vez estabelecido os mapeamentos entre os conceitos, devem-se
definir os mapeamentos entre as relaes. O procedimento para as relaes
anlogo, ou seja, MVs e MHs so estabelecidos e as relaes correspondentes so
incorporadas ao modelo estrutural de integrao. No entanto, como um conceito
tambm definido em termos de suas relaes, mapeamentos entre as relaes
podem influenciar os mapeamentos entre conceitos e, por isso, este um processo
iterativo.
a3
a2
a1
b2
b3
b1
b4
o1
o3
o2
i1
i3
i2
Ontologia de Domnio
Modelo Conceitual A
Modelo Conceitual B
Modelo de Integrao
Mapeamento Vertical
Mapeamento Horizontal
Figura 8 - Mapeamentos verticais e horizontais
29
c) As Fases de Design e de Implementao
Uma soluo de integrao pode ser concebida e implementada de vrias
maneiras. OBA-SI no se compromete com uma soluo de integrao
especfica. No entanto, fornece algumas diretrizes a fim de manter a consistncia
semntica durante o processo de integrao. Primeiro de tudo, o projeto deve ser
baseado na semntica estabelecida durante a fase de anlise. Assim, os principais
insumos para a fase de projeto so os modelos conceituais das ferramentas e o
modelo de integrao. Esses artefatos so independentes dos aspectos
computacionais relacionados soluo de integrao. No entanto, natural que o
modelo de integrao seja alterado para incorporar as decises relativas soluo
de integrao.
A integrao de ferramentas pode acontecer sem que as mesmas sejam
alteradas. Uma forma de integr-las construindo mediadores para intermediarem a
comunicao entre as ferramentas. Um mediador deve ter uma viso global dos
sistemas a serem integrados. Ele responsvel pelo intercmbio de dados e
funcionalidades entre as ferramentas. O modelo de integrao fornece as
informaes para projet-lo, onde o modelo estrutural capta os conceitos e as
relaes que sero manipuladas pelo mediador. O modelo comportamental, por sua
vez, mostra as atividades do processo de negcio e os servios das aplicaes que
sero integrados. Alm disso, a orquestrao de invocaes dos servios das
ferramentas feita atravs do mediador, considerando o modelo comportamental da
integrao. Assim, importante que o mediador implemente o modelo de integrao,
a fim de ligar as ferramentas. Finalmente, os mapeamentos horizontais (estruturais e
comportamentais) podem ser usados para projetar a comunicao entre as
ferramentas e o mediador. A implementao desta comunicao pode ocorrer dentro
do mediador ou fora dele, por meio de adaptadores que se conectam as ferramentas
para o mediador.
30
2.3 PLANEJAMENTO DE PROJETO E PROCESSO DE SOFTWARE
De acordo com a ISO 10006:2003, a Gerncia de Projetos, em geral, inclui as
atividades de planejamento, organizao, superviso e controle de todos os
aspectos do projeto, em um processo contnuo para atingir seus objetivos. Esses
objetivos so alcanados de forma mais eficiente quando as atividades do projeto e
seus recursos so gerenciados como um processo (ISO, 2003). Os Processos de
Gerncia de Projetos so usados para estabelecer e desenvolver planos de projeto,
para avaliar o progresso do projeto em relao aos planos e controlar a execuo do
projeto at a sua finalizao (ISO/IEC, 2008).
Processos so decompostos em partes menores. No contexto da engenharia
de software, um processo pode ser decomposto em outros processos
(subprocessos) ou em atividades. Um subprocesso descrito como uma
decomposio do processo que satisfaz os critrios para ser um processo, ou seja,
tem um propsito, coeso e colocado sob a responsabilidade de uma
organizao, ou de uma parte dela, no ciclo de vida do software. Uma atividade
utilizada quando a unidade decomposta do processo no pode ser qualificada como
um processo. Uma atividade pode ser considerada simplesmente como um conjunto
de tarefas (ISO/IEC, 2008).
Os processos de projeto devem ser identificados e documentados, e as
atividades devem ser realizadas e controladas de acordo com o plano do projeto
(ISO, 2003). Processos de projeto de software devem ser definidos considerando as
atividades a serem executadas, os recursos necessrios, os artefatos de entrada e
sada, os procedimentos adotados (mtodos, tcnicas, modelos de documento, entre
outros) e o modelo de ciclo de vida que ser usado (FALBO; BERTOLLO, 2009).
A definio do processo que ser seguido no decorrer do projeto pode ser feita
atravs da identificao das entradas, sadas e dos objetivos, alm da atribuio de
autoridade e responsabilidades para os processos, entre outros (ISO/IEC, 2008).,
sendo que a organizao deve considerar a experincia adquirida no
desenvolvimento e uso de seus processos em projetos anteriores.
31
Embora diferentes projetos requeiram processos com caractersticas
especficas, possvel estabelecer um conjunto de ativos de processo de software
que devem estar presentes em todos os processos de projeto de uma organizao.
Esse conjunto de ativos de processos chamado de processo de software padro
organizacional. O processo padro da organizao adaptado para definir um
processo cada projeto.
Outros ativos de processos organizacionais so utilizados para apoiar a
adaptao e implementao de processos definidos. Um processo padro
composto por outros processos (ou seja, subprocessos) ou elementos de processo
que descrevem as atividades e tarefas para executar o trabalho de forma consistente
(SEI, 2010). O uso de processos padro defendido por quase todos os modelos e
normas de qualidade de processo de software, incluindo a ISO/IEC 12207 (ISO/IEC,
2008), o CMMI (SEI, 2010) e o MPS-BR (SOFTEX, 2011). Todos eles sugerem a
utilizao de um processo padro como ponto de partida a partir do qual os
processos de projeto devem ser definidos.
O principal objetivo do planejamento do projeto definir um escopo para o
projeto, refinar os objetivos e desenvolver as aes necessrias para alcan-los
(PMI, 2008). Assim, o processo de planejamento do projeto deve, dentre outros (SEI,
2010): (i) determinar o escopo do projeto e atividades tcnicas, (ii) identificar as
sadas dos processos, tarefas e as entregas do projeto, e (iii) estabelecer um
cronograma para a execuo das tarefas do projeto, incluindo os critrios de
realizao e os recursos necessrios para realizar as tarefas do projeto. Isso
envolve, entre outros, estimar o esforo requerido, definir as atividades e tarefas a
serem realizadas e os recursos necessrios para execut-las, estabelecer o
cronograma para a realizao das tarefas e alocar tarefas e atribuir
responsabilidades.
No contexto da gerncia de projetos, processos relacionados a recursos visam
planej-los e control-los, incluindo equipamentos, instalaes, materiais, software,
servios, pessoal e espao (PMI, 2008).
As pessoas que participam do projeto devem ter a autoridade e as
responsabilidades bem definidas em relao sua participao no projeto. A
32
autoridade delegada aos participantes do projeto deve corresponder s suas
responsabilidades. A qualidade e o sucesso de um projeto depender do pessoal
que participa desse projeto. Portanto, deve ser dada ateno especial s atividades
dos processos relacionadas com o pessoal, tal como a alocao de pessoas. Ao
atribuir os membros para as equipes de projeto, seus interesses, pontos fortes e
fracos devem ser considerados. O trabalho ou papel a ser desempenhado deve ser
compreendido e aceito pela pessoa designada (ISO, 2003).
Processos relacionados com o tempo do projeto visam determinar as
dependncias e a durao das atividades, e visam assegurar a concluso do projeto
no tempo adequado. Esses processos incluem o planejamento das dependncias
das atividades, da estimativa de durao e do desenvolvimento e controle do
cronograma. A definio do cronograma pode impactar nos recursos do projeto. Na
verdade, processos relacionados com o tempo e processos relacionados com
recursos (incluindo processos relacionados a pessoas) so extremamente
interligados. Decises ou aes tomadas no contexto de um deles devem ser
analisadas com cautela, considerando as implicaes em outros processos (ISO,
2003).
2.3.1 Ferramentas de Apoio ao Planejamento de Processo de Software
O ambiente ODE (Ontology-based software Development Environment)
(FALBO et al., 2003) um ambiente de desenvolvimento de software (ADS)
centrado em processos (ARBAOUI et al., 2002) (GRUHN, 2002) e baseado em
ontologias (FALBO et al., 2004).
O ambiente constitudo de vrias ferramentas. No contexto deste trabalho,
nos interessam as ferramentas ligadas ao planejamento do processo de software,
tais como Def-Pro, a ferramenta de apoio definio de processos (BERTOLLO et
al., 2006) (SEGRINI et al., 2006), ControlPro, a ferramenta de apoio ao
acompanhamento de projetos (DAL MORO, 2005) e AlocaODE, a ferramenta de
apoio alocao de recursos (COELHO, 2007).
33
2.3.1.1 Def-Pro
Def-Pro (SEGRINI, 2009) a ferramenta de definio de processo de software
de ODE. Ela oferece apoio definio de processos em nveis baseada em
componentes. Ela permite que processos de software sejam definidos em dois nveis
de abstrao, a saber: nvel de processo padro e nvel de processo de projeto.
Em ambos os nveis de abstrao, a definio segue os seguintes passos:
Para um componente de processo complexo, define-se quais sero os subprocessos
que o compe, os componentes de processo simples. Para cada componente de
processo simples, possvel definir as suas macroatividades. Para cada atividade,
sendo ela uma macroatividade ou subatividade, possvel definir subatividades, pr-
atividades, artefatos produzidos e requeridos, recursos necessrios e procedimentos
a serem adotados. Esse conjunto de caractersticas so os ativos de uma atividade.
importante ressaltar ainda que no nvel de abstrao de processo padro a
definio de componentes de processo pode acontecer nos trs nveis.
2.3.1.2 ControlPro
ControlPro (DAL MORO, 2005) a ferramenta de acompanhamento de
projetos de ODE. Ela permite o acompanhamento do progresso do projeto e a
alterao do processo em tempo de execuo. H uma forte integrao entre
ControlPro e Def-Pro, conseguida pelo compartilhamento dos mesmos modelos de
classes.
Usando ControlPro, um gerente de projeto pode editar os ativos de processo
definidos para as atividades do projeto, definir datas de incio e fim para elas,
realocar recursos e controlar o andamento das atividades. Alm disso, o gerente de
projeto pode controlar o estado do projeto, incluindo aes para iniciar, finalizar,
cancelar ou reativar um projeto .
34
Desenvolvedores tambm podem usar ControlPro para acompanhar as
atividades a eles alocadas, registrar esforo despendido nelas ou criar sub-
atividades para melhor organizar o seu trabalho.
2.3.1.3 AlocaODE
AlocaODE (COELHO, 2007) (PIANISSOLA, 2007) a ferramenta de alocao
de recurso do ambiente ODE. Ela permite que para cada atividade sejam alocados
pessoas, ferramentas de software, hardware e sistemas de apoio.
Para ter um maior controle sobre as alocaes de recursos humanos a
atividades dentro do ambiente, um recurso humano alocado para desempenhar
um papel especfico, possvel registrar a dedicao em termos de tempo dirio do
recurso humano alocado realizao da atividade, o esforo total previsto para a
alocao, as datas de incio e fim previstas e efetivas da alocao, alm do estado
da mesma.
2.4 CONSIDERAES FINAIS
Este captulo apresentou alguns conceitos importantes sobre Interoperabilidade
Semntica, tema foco desta dissertao, com o intuito de oferecer ao leitor uma
viso geral acerca do tema, para que este possa dar prosseguimento leitura dos
prximos captulos.
Foram discutidos os tipos de problemas semnticos que podem ocorrer durante
a integrao de ferramentas e foi apresentada uma abordagem, OBA-SI, baseada
em ontologia para prover interoperabilidade semntica.
O trabalho apresentado na sequncia desta dissertao abrange a integrao
de sistemas de apoio ao planejamento de projetos, segundo o ponto de vista do
35
projetista, na camada de dados e no nvel semntico, seguindo parcialmente o
processo proposto por OBA-SI. A integrao realizada apenas no nvel conceitual
e, portanto, apenas a fase de anlise de OBA-SI foi realizada.
Para a realizao do trabalho, foi feita a reengenharia da Ontologia de
Processo de Software proposta em (BERTOLLO, 2006). Essa reengenharia foi feita
com base na Ontologia de Fundamentao Unificada (Unified Foundational Ontology
UFO) (GUIZZARDI, 2005) (GUIZZARDI et al., 2008), a qual apresentada no
prximo captulo. O Captulo 4 apresenta a nova verso da Ontologia de Processo
de Software, a qual usada como base para o projeto de integrao semntica,
discutido no Captulo 5.
36
3 A ONTOLOGIA DE FUNDAMENTAO UNIFICADA
Uma ontologia pode ser definida como uma especificao de um vocabulrio
para representao de um domnio compartilhado de discurso (GUIZZARDI apud
GUIZZARDI, R.S.S, 2006). Em outras palavras, uma ontologia um modelo de
domnio, composto por um conjunto de conceitos e relaes. Uma ontologia til
para fornecer uma compreenso clara sobre um determinado domnio.
O processo de reengenharia apresentado neste trabalho (ver Captulo 4)
baseado na UFO (Unified Foundational Ontology) (GUIZZARDI, 2005), uma
ontologia de fundamentao. Segundo Guizzardi e Wagner (2005), uma ontologia de
fundamentao "define um conjunto de categorias ontolgicas independente de
domnio que formam uma base geral para ontologias especficas de domnio"
(GUIZZARDI; WAGNER, 2005).
UFO tem sido desenvolvida baseada em um nmero de teorias das reas de
Ontologias Formais, Lgica Filosfica, Filosofia da Linguagem, Lingstica e
Psicologia Cognitiva. Ela dividida em trs camadas incrementais, a saber: i) a
UFO-A define o ncleo do UFO, apresentada em detalhes e formalizada em
(GUIZZARDI, 2005). Ela inclui os conceitos relacionados a endurants; ii) a UFO-B
define, com base na UFO-A, os conceitos relacionados a perdurants e, por fim, iii) a
UFO-C define, sob a UFO-A e a UFO-B, conceitos relacionados s esferas de coisas
intencionais e sociais.
As sees seguintes apresentam, respectivamente, os conceitos de UFO-A,
UFO-B e UFO-C que so importantes para a compreenso completa deste trabalho.
O contedo apresentado nessas sees foi elaborado com base nos seguintes
trabalhos (GUIZZARDI, 2005; GUIZZARDI, R.S.S, 2006; GUIZZARDI et al., 2008;
ZAMBORLINI, 2011).
Por questes de legibilidade, nos diagramas apresentados neste trabalho,
apenas tero destaque os conceitos que no foram previamente apresentados (os
demais conceitos ficaro em um tom mais claro de cinza).
37
3.1 UFO-A
A UFO-A trata particularmente de entidades chamadas endurantes (endurants).
A diferena entre endurantes e perdurantes (perdurants), este ltimo tratado na
UFO-B, pode ser intuitivamente compreendida em termos da distino entre objetos
e processos, respectivamente. A UFO-A proposta por Guizzardi (2005). Devido
dificuldade de se traduzir alguns termos, eles so mantidos em lngua inglesa nos
diagramas e no texto, porm alguns so traduzidos no texto quando convm, tanto
nessas sees quanto nas demais.
Uma distino fundamental nessa ontologia ocorre entre a categoria Individual
e a categoria Universal. Universal a categoria ou tipo geral que representa os
padres de caractersticas presentes em diferentes indivduos. Por exemplo, este
tipo se aplica aos conceitos ou categorias de indivduos Pessoa, Adulto e Cachorro,
que so padres de caractersticas comuns presentes em certos indivduos. Por
outro lado, Individual a categoria ou tipo geral que se aplica aos indivduos, que
so entidades que existem na realidade e possuem uma identidade nica. Por
exemplo, este tipo se aplica aos indivduos Eugnio e Rex. Alm disso, cada
indivduo num domnio deve ser instncia de pelo menos um universal. Por exemplo,
Eugnio um indivduo do domnio que instancia os universais Pessoa e Adulto,
enquanto Rex instancia o universal Cachorro.
Classifica-se, ainda, Universal como Monadic Universal ou Relation
Universal. O tipo Monadic Universal a categoria que se aplica aos conceitos que
so padres aplicados a indivduos singulares, enquanto o tipo Relation Universal
se aplica s relaes, que so padres aplicados a grupos de dois ou mais
indivduos. A Figura 9 apresenta esses conceitos.
38
Individual
Thing
Universal* 1..*
instanceOf4
Monadic Universal Relation Universal
Figura 9 UFO-A: Individual e Universal 1
A principal distino de tipos de universais mondicos e tipos de indivduos em
UFO a distino entre substantials e moments. Substantial representa as
entidades do mundo real que persistem no tempo, mantendo as suas identidades.
So exemplos de Substantials entidades fsicas e sociais do dia-a-dia, como uma
pessoa, uma bola, um co, oceano atlntico e o presidente da repblica. Indivduos
podem ainda ser especializados ainda em Situations (situaes). Situaes so
entidades complexas constitudas possivelmente por vrios objetos (incluindo outras
situaes), sendo tratadas aqui como um sinnimo para o que chamado na
literatura de estado de coisas (state of affairs), ou seja, uma poro da realidade que
pode ser compreendida como um todo. So exemplos de situaes: Joo Paulo
estar gripado e com febre, e Patricia estar casada com Joo Paulo que trabalha
para a UFES.
Individual Universal
* 1..*
instanceOf4
Monadic UniversalMoment
Moment UniversalSubstantial Universal
SubstantialSituation
Figura 10 UFO-A: Substantial e Moment
i. Substantials
A entidade Substantial (GUIZZARDI 2005) especializada em Sortal e
Mixin, conforme apresentado no diagrama da Figura 11. Os universais do tipo
1 As entidades do tipo Universal sero representados no diagramas com uma forma
arredondada para favorecer a compreenso dos diagramas.
39
Sortal so tais que agregam indivduos com o mesmo princpio de identidade.
Por exemplo, supondo que a impresso digital defina a identidade de uma
pessoa, so universais do tipo Sortal os conceitos Pessoa, Cliente Pessoa
Fsica e Adulto, uma vez que todos agregam indivduos que possuem o mesmo
princpio de identidade, como Joo, Maria e Jos. Em contraste, universais do
tipo Mixin so tais que agregam indivduos com princpios de identidade
diferentes. Seguindo o mesmo exemplo, supondo tambm que o CNPJ defina a
identidade de uma empresa, ento o conceito Item Assegurvel, que agrega
pessoas e empresas, um universal do tipo Mixin.
Na sequncia do diagrama, os universais do tipo Sortal podem ainda ser
classificados como Rigid Sortal ou Anti Rigid Sortal. Universais do tipo Rigid
Sortal so conceitos rgidos como Pessoa e Empresa, cujos indivduos devem
instanci-los enquanto existirem, por exemplo, Joo Paulo necessariamente
instncia de Pessoa enquanto existir. Por outro lado, universais do tipo Anti
Rigid Sortal so conceitos anti-rgidos como Cliente e Professor, cujos
indivduos podem eventualmente instanci-los ou no enquanto existirem. Por
exemplo, Joo Paulo pode ser instncia do conceito professor em um
determinado instante e deixar de ser professor em outro.
Substantial Universal
Sortal Universal Mixin Universal
RigidSortal AntiRigidSortal
UltimateSortal Subkind
Kind
Phase Role
Figura 11 UFO-A: Sortal
Os universais do tipo Rigid Sortal so ainda classificados como Ultimate Sortal
quando proveem o princpio de identidade aos seus indivduos, ou como
Subkind quando apenas herdam este princpio. Por exemplo, considerando-se
a impresso digital como o princpio de identidade provido a toda instncia do
40
conceito Pessoa, este do tipo Ultimate Sortal, enquanto os conceitos Homem
e Mulher so do tipo Subkind pois, alm de serem rgidos, especializam o
conceito Pessoa e, portanto, herdam dele o princpio de identidade. O tipo
Ultimate Sortal, especializa-se em Espcie (Kind) que categoriza conceitos
cujas instncias so complexos funcionais.
Os universais do tipo Anti-Rigid Sortal, por sua vez, como mostra a Figura 11,
so classificados como Phase ou Role. Conceitos do tipo Phase (Fase) so
tais que sua instanciao determinada por uma propriedade intrnseca do
indivduo. Por exemplo, Joo instancia a fase Adulto se sua idade (propriedade
intrnseca) maior que 18 anos. J os conceitos do tipo Role (Papel), como
Cliente Pessoa Fsica ou Esposo, so relacionalmente dependentes, ou seja,
sua instanciao determinada por uma propriedade relacional do indivduo.
Por exemplo, Joo instancia o papel de Esposo se est casado com
(propriedade relacional) Maria.
ii. Moments
Moment, por sua vez, denota o que chamado de objetificao (instanciao)
de uma propriedade (e no tem nenhuma relao com o sentido de instante
temporal como o termo comumente utilizado). Exemplos de Moments so: a
cor de uma cadeira, uma carga eltrica e um sintoma de um determinado
paciente (GUIZZARDI, 2005) (GUIZZARDI et al., 2008). Uma caracterstica
comum aos Moments que todos estes so dependentes de Substantials,
somente podendo existir em outros Substantials, como, por exemplo, uma
carga eltrica somente pode existir em algum condutor eltrico, ou uma ligao
covalente somente pode existir se os tomos conectados existirem. Os
Moments so existencialmente dependentes de outros Substantials.
dito que um indivduo x dependente existencialmente (ed) de um outro
indivduo y se, e somente se, por questo de necessidade, y existir sempre que
x existir. A dependncia existencial uma relao modalmente constante, isto
41
, se x for dependente de y esta relao existe entre estes dois indivduos
especficos em todos os mundos possveis em que x existe.
Dependncia existencial pode tambm ser usada para diferenciar Relational
Moments (propriedades relacionais) de Intrinsic Moments (propriedades
intrnsecas). Os Intrinsic Moments dependem de apenas um Substantial para
existirem e so intrnsecas a ele. So exemplos de Intrinsic Moments a cor de
um objeto, a dor de cabea de uma pessoa e a temperatura de um ser. Se
essa propriedade no mensurvel, ela chamada de Mode, por exemplo, a
dor de cabea de Joo. Diferentemente dos Intrinsic Moments, os Relational
Moments, tambm chamados de Relators, dependem de um conjunto de
Indivduos para existirem como, por exemplo, o Relator tratamento mdico
depende para existir dos Indivduos Paciente e Mdico.
A relao de dependncia existencial que existe entre um Moment x e um
Individual y na qual x depende de y a relao de Inherence (inerncia).
Assim, para que um Individual x seja um Moment de um outro Individual y, a
relao i(x,y), ou seja, x inerente a y, deve existir entre os dois. Por exemplo,
a inerncia prende a existncia de um sorriso a um rosto, ou a carga em um
condutor especfico ao prprio condutor. Nessa ontologia, admite-se que
Moments podem ser inerentes a outros Moments. Um exemplo de um Moment
que inerente a um outro moment a gravidade de um sintoma. A partir dessa
relao, pode-se dizer que os Individuals que no so inerentes a outros
Individuals so denominados de Substantials.
42
Individual
Moment Substantial
Relator
2..*
*
mediates4
Intrisic Moment
1
1..*
existential dependent4
Mode
Figura 12 UFO-A: Tipos de moments
iii. Relations
Retomando a distino inicial dos tipos de universais (mondicos e de relao),
o tipo Relation Universal a categoria geral que se aplica aos universais de
relao. Esta categoria subdividida em Formal e Material (GUIZZARDI;
WAGNER, 2008), como pode ser visualizado na Figura 13.
Relation Universal
Formal Relation Material Relation
Domain Internal Relation
Mediation
Basic Internal Relation
Figura 13 UFO-A: Tipos de Relaes
O tipo Material Relation se aplica s relaes que dependem de algum
interventor para valer, a saber, um indivduo do tipo Relator. Por exemplo, a
material relation casado existente entre Manuel e Anna vale enquanto existir o
relator Casamento de Manuel e Anna. Contrariamente, as relaes do tipo
Formal Relation valem pela simples existncia dos indivduos relacionados.
Por exemplo, a relao todo-parte entre Manuel e seu Crebro vale sempre
que ambos existirem.
43
As relaes do tipo Formal podem ser ainda classificadas como Basic Internal
Relation (Relao Bsica Interna) ou Domain Formal Relation (Relao
Formal de Domnio). O tipo Basic Internal Relation aplica-se a relaes
formais internas ditas de dependncia existencial que tm representao entre
as categorias de indivduos da UFO. Este tipo pode ser especializado em
Mediation (Mediao), que se aplica relao mediates (de mediao) que
define os indivduos do tipo Relator. Por sua vez, o tipo Domain Formal
Relation se aplica s relaes formais que so especficas de domnio e que,
por isso, no so representadas entre os tipos de indivduos da UFO, mas
entre os conceitos especficos de domnio, assim como as do tipo Material
Relation.
A Figura 14 apresenta um panorama geral dos conceitos apresentados da UFO-A.
Entretanto, importante ressaltar que esta no a verso completa da mesma.
44
Thing
Individual Universal* 1..*
instanceOf4
Monadic Universal Relation Universal
disjoint
Formal Relation Material RelationSubstantial Universal
Intrinsic Moment Universal
Moment Universal
Relational Moment (Relator Universal)
SubstantialMoment
Relator Intrisic Moment
1
1..*
existential dependent4
Externally Dependent Moment
1..*
*
externally dependent moment
Mode Universal
Sortal Universal
RigidSortal
Role
AntiRigidSortal
PhaseSubkind
Kind
Domain Internal Relation
Mediation
2..*
*
mediates4
Basic Internal Relation
UltimateSortal
Figura 14 Viso geral dos conceitos da UFO-A
45
3.2 UFO-B
UFO-B trata de Perdurants ou, mais intuitivamente, de Eventos (Event).
Eventos (ou ocorrncias) so indivduos compostos de partes temporais. Eles
acontecem no tempo no sentido de se estenderem no tempo acumulando partes
temporais. So exemplos de eventos: uma conversa, uma partida de futebol, a
execuo de uma sinfonia e um processo de negcio. Em qualquer momento em
que um evento est presente, apenas algumas de suas partes temporais estaro
presentes. Como uma consequncia, eventos no podem sofrer mudanas no tempo
no sentido genuno, uma vez que nenhuma de suas partes temporais mantm sua
identidade ao longo do tempo.
Eventos so possveis transformaes de uma situao para outra na
realidade, i.e., eles podem alterar o estado de coisas da realidade de um pr-estado
(pre-state) para outro (post-state) em um intervalo temporal. Eventos so entidades
ontologicamente dependentes no sentido de, para existirem, dependerem
existencialmente de seus participantes. Seja o evento e: o ataque de Brutus a Csar.
Nesse evento, h a participao de Csar, Brutus e da faca usada no ataque. Neste
caso, e composto da participao individual de cada uma dessas entidades. Cada
uma dessas participaes por si prpria um evento que pode ser complexo ou
atmico, mas que existencialmente depende de um nico substancial. Em UFO-B,
ser atmico e ser instantneo so noes ortogonais, i.e., participaes atmicas
podem se estender no tempo, bem como eventos instantneos podem ser
compostos de mltiplas participaes (instantneas). Em suma, o modelo da Figura
15 mostra essas duas perspectivas sob as quais eventos podem ser analisados, a
saber: como entidades que se estendem no tempo com certas estruturas
mereolgicas (i.e., eventos simples ou complexos), e como entidades
ontologicamente dependentes que podem envolver um nmero de participaes
individuais.
46
UFO-A::Situation Event
1
*
1
*
Atomic Event Complex Event
*
2..*
UFO-A::Formal Relation
Time Interval RelationTime Interval
1
*
1 *framed by4
- pre-state
- pos-state
- source
- target
Temporal Structure
UFO-A::Quality Structure
Participation
Figura 15 - UFO-B: Evento
3.3 UFO-C
A terceira camada da UFO uma ontologia de entidades sociais (tanto
endurants quanto perdurants), construda sobre UFO-A e UFO-B. Conforme mostra
a Figura 16, uma das principais distines feitas na UFO-C entre agentes (Agent)
e objetos no-agentivos (Object). Um agente um substancial que cria aes
(Action), percebe eventos (Event) e que pode possuir tipos especiais de modos,
chamados de intentional modes. Os agentes podem ser fsicos (Physical Agent)
(por exemplo, uma pessoa) ou sociais (Social Agent) (por exemplo, uma
organizao). Um objeto, por outro lado, um substancial incapaz de perceber
eventos ou ter intencional modes. Objetos tambm podem ser divididos em objetos
fsicos (Physical Object) (por exemplo, um livro, um carro) e objetos sociais (Social
Object) (por exemplo, dinheiro, lngua). A descrio normativa (Normative
Description) um tipo de objeto social, que define uma ou mais regras/normas
reconhecidas por, pelo menos, um agente social e que pode definir entidades sociais
como universais (p.ex., tipos de comprometimentos sociais) e papis sociais, tais
como presidente, ou pedestre. Uma descrio plano (Plan Description) um tipo
especial de descries normativas que descreve planos complexos (Complex
Action Universal).
47
UFO-A::Substantial
Agent Object
Physical Agent Physical ObjectSocial Agent Social Object
Organization Normative Description
1..*
*
3 reconized by
Plan Description
Social Role0..1
*
defines4
UFO-A::Role
Action Universal
Complex Action Universal
1..*
0..1
3 describes
*
2..*
UFO-B::Event
*
*
3 perceives
Action
*
*
instance of4
*
*
3 creates
Figura 16 - UFO-C: Distino entre Agente e Objeto
Como dito anteriormente, agentes so substanciais que podem possuir tipos
especiais de modos, chamados de intentional moments. Intencionalidade deve ser
entendida em um contexto mais amplo do que a noo de alguma coisa que se
intenciona, mas como a capacidade de certas propriedades de certos indivduos de
se referir a possveis situaes (Situation) na realidade (SEARLE apud GUIZZARDI,
FALBO, GUIZZARDI, 2008). Todo modo intencional tem um tipo, a saber: crena
(belief), desejo (desire), inteno (intention ou internal commitment) e um
contedo proposicional que um objetivo (goal), sendo este ltimo uma
representao abstrata de uma classe de situaes referenciadas por esse modo
intencional. Assim, alguma coisa que se intenciona um tipo especfico de
intencionalidade denominada inteno (intention).
48
UFO-A::Intrisic Moment
Agent
1..*
1
inheres in4
Social Moment Mental Moment
Proposition Intentional Moment1
*
proposition content of4
Goal
UFO-A::Externally Dependent Moment
Social Commitment
*
1..*
external dependence4
Commitment
Intention
1 1..*
proposition content of4
DesireBelieve
{disjoint, complete}
UFO-A::Situation
sastifies4
Claim
Figura 17 UFO-C: Intentional Moment
Alm de comprometimentos internos (intenes), existem tambm
comprometimentos sociais (social commitment). Um comprometimento social o
comprometimento de um agente A com outro agente B. Como um momento
externamente dependente (externally dependent moment), o comprometimento
social inerente ao agente A e externamente dependente de B. O
comprometimento social do agente A com o agente B necessariamente causa a
criao de um comprometimento interno em A e a reivindicao social (claim) de B
com A. Comprometimentos internos, ou intenes (intentions), por sua vez, fazem
com que o agente realize aes.
Comprometimentos podem ser atmicos (atomic commitment) ou complexos
(complex commitment). Um comprometimento complexo composto de dois ou
mais comprometimentos. Um tipo especial de comprometimento um compromisso
(appointment). Um compromisso um comprometimento cujo objetivo (contedo
proposicional) refere-se explicitamente a um intervalo de tempo (time interval). A
Figura 18 sumariza os tipos de comprometimentos.
49
Commitment
Complex Commitment
Atomic Commitment
Intention Social Commitment Appointment
Closed CommitmentOpen Commitment
Goal1..** 3 proposition content of
Appointment Goal1..*
13 proposition content of
Time Interval
*
1..*
3 refers to
*
2..*
Figura 18 - Tipos de comprometimento
Por fim, comprometimentos podem ser abertos (open commitments) ou
fechados (closed commitments), sendo a diferena que, no caso do ltimo, o
agente deve cumprir o comprometimento pela execuo de uma ao especfica.
Diz-se, ento, que um comprometimento C baseado em um plano P tal que C
cumprido pelo agente A se, e somente se, A ativamente provocar uma situao S
que satisfaz o contedo proposicional de C e por meio de uma ao p que uma
instncia de P. Por exemplo, quando o professor Joo compromete-se com o
departamento de avaliar os alunos matriculados em sua turma, este
comprometimento um comprometimento aberto, pois no existe um plano a ser
seguido para que esse comprometimento seja cumprido. Em contrapartida, caso o
professor Joo comprometa-se a avaliar os alunos atravs da aplicao de duas
provas, este um comprometimento fechado, pois, para alcan-lo, ele dever,
necessariamente, aplicar duas provas. Comprometimentos abertos e fechados
podem explicar as noes de delegao aberta e fechada, respectivamente.
Delegao (Delegation) um tipo especial de relao material (material
relation) derivada de um social relator delegatum. Quando um agente A
(delegator) delega um objetivo a um agente B (delegatee), B se compromete
(comprometimento social) com o agente A. O agente A, por sua vez, passa a ter o
direito de reivindicar (claim) de B o cumprimento do que foi delegado. O par de
comprometimento / reivindicao compe o delegatum a partir do qual a delegao
derivada, como mostrado na Figura 19.
50
Compromissos e reivindicaes sempre formam um par que se refere ao
mesmo contedo proposicional, e um relator social um exemplo de um relator
composto por dois ou mais pares de compromissos associados / reclamao.
Social Relator
UFO-A::Material Relation
Delegation
* 1
derived from4
UFO-A::Externally Dependent Moment
UFO-A::Intrisic Moment
UFO-A::Moment
UFO-A::Relator
Sociall Moment
2..*
*
1
derived from4
Physical Agent
*
-delegator
1
-delegatee
1
* Social CommitmentClaim1
1..*
1
1..*
Delegatum
Figura 19 - UFO-C: Delegao.
Finalmente, as aes (action) so eventos intencionais, ou seja, eles tm a
finalidade especfica de satisfazer alguma inteno (por exemplo, um processo de
negcio). Como eventos, aes podem ser atmicas (atomic action) ou complexas
(complex action). J uma ao complexa composta de duas ou mais
participaes (Participation). Essas participaes, por sua vez, podem ser
intencionais (sendo, portanto, elas prprias aes) ou eventos no intencionais. Por
exemplo, o ataque de Brutus a Csar inclui a participao intencional de Brutus e a
participao no intencional da faca. Em outras palavras, nem toda participao de
um agente considerada uma ao, mas somente as participaes intencionais,
aqui denominadas contribuies de ao (action contributions). Apenas agentes
(entidades capazes de possuir modos intencionais) podem realizar aes. A Figura
20 apresenta esses conceitos.
51
Action UniversalAction1*
Atomic ActionComplex Action
Participation
UFO-B::Event
1*
UFO-A::Event Universal
*
2..*
Action ContributionResource Participation
Agent
1
*
Object
*
*
UFO-A::Substantial
Intention*
1
caused by4
Figura 20 - UFO-C: Ao.
52
4 REENGENHARIA BASEADA NA UFO DA ONTOLOGIA DE
PROCESSO DE SOFTWARE
Este trabalho integra conceitualmente duas ferramentas que apoiam o
planejamento do processo de software (Seo 2.3). De acordo com OBA-SI (ver
Seo 2.2.1) uma ontologia de domnio deve ser utilizada para atribuir significado
aos modelos conceituais das ferramentas que esto sendo integradas para que,
posteriormente, eles possam ser mapeados semanticamente.
Uma Ontologia de Processo de Software (Software Process Ontology - SPO)
usada como a ontologia de referncia no processo de integrao dessas
ferramentas. Essa ontologia foi originalmente desenvolvida em (BERTOLLO, 2006)
com o objetivo de estabelecer uma conceituao comum para que as organizaes
de software pudessem falar a respeito de processo de software. Em (GUIZZARDI et
al. 2008) essa ontologia foi objeto de uma reengenharia parcial, onde alguns
conceitos da SPO foram mapeados para conceitos da UFO com o objetivo de tornar
explcitos os compromissos ontolgicos subjacentes. Entretanto, essa reengenharia
no cobriu todos os conceitos necessrios para discutir o domnio de planejamento
de projetos de software, alm de apresentar alguns problemas, como discutido mais
adiante.
Este captulo apresenta um passo frente na reengenharia da SPO com base
na UFO, com o intuito de cobrir os conceitos necessrios para discutir o domnio de
planejamento de projetos de software. Ele est estruturado da seguinte forma: a
Seo 4.1 apresenta a verso original da ontologia de processo de software e a
verso produzida em sua primeira reengenharia; a Seo 4.2 apresenta a nova
verso, resultante da reengenharia realizada neste trabalho; e a Seo 4.3, por fim,
apresenta as consideraes finais do captulo.
53
4.1 ONTOLOGIA DE PROCESSO
Como discutido na Seo 2.3, durante o planejamento de projetos,
necessrio definir o processo do projeto, agendar as atividades e alocar os recursos
humanos que iro execut-las. Para controlar e monitorar o projeto de forma
eficiente, necessrio acompanhar o cumprimento dessas atividades e o tempo
gasto em sua execuo.
Durante a definio do processo de software para um projeto, o gerente de
projeto deve identificar as atividades que devero ser re
