Ontologia de Processo
Histórico
Esta ontologia foi construída com o apoio de
diversos especialistas em processo de
software da COPPE/UFRJ, buscando-se um consenso sobre o vocabulário e as restrições a serem consideradas para processos de
Desenvolvimento
A primeira atividade realizada foi a identificação do
propósito e a especificação inicial dos requisitos da ontologia.
Dada a complexidade do domínio, a abordagem de
ontologias em níveis foi adotada.
Assim, a ontologia de processo foi construída tendo
por base ontologias centrais do domínio, a saber ontologias de atividade, procedimento e recurso. Para cada uma dessas ontologias, o método de Engenharia de Ontologias foi recursivamente aplicado.
Na especificação de requisitos, foram
enumeradas questões de competência que serviram de base para a fase seguinte, a captura da ontologia.
Nesta fase, foram elaborados modelos
usando LINGO (Linguagem Gráfica para
descrever Ontologias) e conceitos e axiomas foram descritos utilizando linguagem natural e exemplos.
Na formalização, optou-se pela lógica de
primeira ordem, estabelecendo-se uma
linguagem formal de primeira ordem sobre processo de software.
Foram identificados as constantes e os
predicados compondo o alfabeto da
linguagem e, a partir dele, os axiomas da ontologia foram formalizados.
Objetivo
A definição de uma ontologia de processo de
software tem por objetivo apoiar a aquisição, organização, reuso e compartilhamento de conhecimento sobre processos de
desenvolvimento de software.
Para atingir este objetivo, a ontologia deve
prover um vocabulário e um conjunto de axiomas fixando a semântica dos termos neste domínio de discurso.
Ontologia de Atividade
O conceito de atividade está no cerne de
qualquer modelo de processo de software. De fato, um processo de desenvolvimento é sempre orientado a atividade e, portanto, a habilidade de representar adequadamente atividades é um aspecto fundamental para uma ontologia de processo de software.
Atividades podem ocorrer em vários níveis,
desde uma tarefa elementar até uma etapa do processo de desenvolvimento.
Utilizaremos o conceito de atividade com o
intuito de representar todo esse espectro.
Assim, uma atividade é uma primitiva de
transformação, que utiliza artefatos de entrada para gerar artefatos de saída, apoiada por recursos.
Tal ontologia deve ser capaz de responder a questões como:
1 - Qual a natureza de uma atividade?
2 - Como uma atividade pode ser decomposta? 3 - Que atividades devem anteceder uma dada
atividade?
4 - Que artefatos são consumidos por uma determinada atividade?
5 - Que artefatos são produzidos por uma determinada atividade?
6 - Qual a natureza de um artefato?
7 - Que recursos são necessários para que uma atividade possa ser realizada?
8 - Que procedimentos podem ser adotados na realização de uma atividade?
Captura e Formalização da
Ontologia
Analisando as questões de competênciaanteriormente relacionadas, identificamos alguns aspectos bastante relevantes no domínio de
atividades, que foram alvo desta ontologia:
taxonomia de atividades (questão 1)
decomposição de atividades (questão 2); encadeamento de atividades (questão 3);
atividades como primitivas de transformação
(questões 4, 5 e 6);
recursos requeridos por atividades (questão 7); e adoção de procedimentos na realização de
Taxionomia de Atividades
No contexto de processos de
desenvolvimento de software, atividades, quanto a sua natureza, podem ser
classificadas em: atividades de construção, atividades de gerência e atividades de
avaliação da qualidade. As atividades de avaliação da qualidade podem, ainda, ser divididas em atividades de certificação e atividades de teste.
Taxionomia de Atividades
Atividade
Atividade de Construção Atividade de Gerência Atividade de Avaliação da Qualidade
Atividades de Construção
As atividades de construção são aquelas
atividades diretamente relacionadas ao processo de construção do software, ao longo do seu ciclo de vida.
Exemplos de atividades de construção,
independentemente do ciclo de vida adotado, incluem: levantamento de requisitos,
modelagem, projeto e codificação, entre outras.
Atividades de Gerência
As atividades de gerência são aquelas
relacionadas ao planejamento e
acompanhamento gerencial do projeto.
Exemplo de Atividades de Gerência:
elaboração, execução, monitoramento, controle e revisão do plano de projeto.
Atividades de Avaliação da
Qualidade
As atividades de avaliação da qualidade são
aquelas relacionadas com a garantia da
qualidade do produto em desenvolvimento e do processo de software utilizado.
Exemplos de Atividades de Avaliação da
Qualidade: revisões e inspeções de produtos (intermediários ou finais) do desenvolvimento e testes.
Predicados
Para formalizar a existência de diferentes
tipos de atividades, definimos os seguintes predicados, representando cada um dos tipos identificados na taxonomia:
atividade(a), indicando que a é uma atividade;
atconstrução(a), indicando que a é uma atividade de construção; atgerência(a), indicando que a é uma atividade de gerência; e atavqualidade(a), indicando que a é uma atividade de avaliação da qualidade.
( a) (atconstrução(a) atividade(a)) ( a) (atgerência(a) atividade(a)) ( a) (atavqualidade(a) atividade(a))
Decomposição de Atividades
O conceito de atividade está sendo utilizado
para cobrir um amplo espectro de atividades, incluindo atividades macroscópicas e
atividades elementares. Contudo, é importante identificar que pequenas
atividades compõem uma atividade maior. Para tal, introduzimos os conceitos de super-atividade e sub-super-atividade.
Uma super-atividade é uma atividade que
não pode ser realizada diretamente, isto é,
ela é composta de outras atividades menores e sua realização se dá, na realidade, através da realização dessas sub-atividades. Uma
sub-atividade, por sua vez, é uma atividade
que compõe uma atividade maior, a sua super-atividade.
Atividade super-atividade sub-atividade
Predicado
O predicado subatividade(a1, a2 ) indica que
a atividade a1 é uma sub-atividade (ou é
parte) da atividade a2 , enquanto o predicado
superatividade(a2 ,a1) indica que a2 é uma
super-atividade de (ou é um todo, cuja uma das partes é) a1. Estes predicados estão relacionados segundo a seguinte sentença:
( a1 , a2 ) ( subatividade(a1 , a2 ) superatividade(a2 , a1 ))
Observação
Uma vez que a lógica de primeira ordem não é uma lógica
poli-sortida, é necessário definir axiomas de consolidação[1] que estabeleçam que tipos de objetos podem ser utilizados como argumentos em um predicado. Assim, o seguinte axioma de consolidação deve ser observado:
( a1 , a2 ) ( subatividade(a1 , a2 ) atividade(a1 ) atividade(a2 ))
[1] Axiomas de consolidação têm por objetivo verificar a coerência das informações existentes e não representam conseqüências lógicas, isto é, não derivam nova informação.
( a1 , a2 , a3) (subatividade(a1 , a2 )
subatividade(a2 , a3) subatividade(a1 , a3 ))
( a1 , a2 ) ( subatividade(a1 , a2 ) subatividade(a2 , a1 ))
Para registrarmos o fato de uma atividade
não ser mais decomponível e, portanto, ser passível de realização direta, introduzimos o conceito de atividade elementar:
uma atividade elementar é aquela que não pode ser decomposta e, portanto, é passível de
realização direta.
Seu equivalente inverso é o conceito de macro-atividade: uma macro-atividade é aquela
Os predicados atividadeelementar(a) e
macroatividade(a) indicam, respectivamente, que uma atividade a é uma atividade elementar ou uma macro-atividade. Estes predicados são definidos em termos dos conceitos de sub-atividade e
super-atividade, como mostram as sentenças abaixo: ( a) ( atividadeelementar(a) ( a1 )
(subatividade(a1 , a)))
( a) ( macroatividade(a) ( a1 ) (superatividade(a1 , a)))
Encadeamento de Atividades
Atividades são realizadas seguindo uma
ordem específica. Um aspecto primordial no contexto de um processo de
desenvolvimento é capturar o encadeamento de atividades. Para tal, introduzimos os
conceitos de pré-atividade e pós-atividade.
Atividade
dependência pré-atividade
Uma atividade a1 é dita uma pré-atividade de uma
atividade a2, se a1 precisa ser realizada para que a2 também o seja. A atividade a2, por sua vez, é
dita uma pós-atividade de a1, já que ela só pode ser realizada após a realização de a1. Assim, se a1 é uma pré-atividade de a2, então a2 é uma
pós-atividade de a1.
Estes conceitos foram formalizados através dos
predicados preatividade(a1 ,a2) e
posatividade(a2 ,a1 ), indicando que a1 é uma pré-atividade de (antecede) a2 ou, de forma inversa, que a2 é uma pós-atividade de (sucede) a1.
( a1 , a2 ) ( preatividade(a1 , a2 ) posatividade(a2 , a1 )) ( a1 , a2 , a3 )( preatividade(a1 , a2 ) preatividade(a2 , a3 ) preatividade(a1 , a3 )) ( a1 , a2 ) ( preatividade(a1 , a2 ) preatividade(a2 , a1 )) ( a1 , a2 ) ( preatividade(a1 , a2 ) atividade(a1 ) atividade(a2 ))
Atividades como Primitivas de
Transformação
Durante a realização de atividades, artefatos
de entrada - os insumos para a atividade -
são transformados em artefatos de saída - os produtos da atividade. Neste sentido, os
artefatos de entrada são “incorporados” aos artefatos de saída. Dizemos “incorporados” para denotar que o conteúdo (informações) de um artefato de entrada é, de alguma
Atividade
Artefato
produto insumo
Artefatos possuem uma importante propriedade que
define seu tipo.
Uma vez que a reutilização de software tem sido
utilizada cada vez mais no desenvolvimento de aplicações complexas, é importante distinguir
componentes de software como um tipo especial de artefato.
Componentes de software são artefatos oriundos de
uma biblioteca de componentes, tais como classes de uma biblioteca de classes, um framework de
Artefatos de código, por sua vez, são artefatos que
consistem de porções de código-fonte, passíveis de execução, tais como programas, sub-programas, rotinas, classes, procedimentos ou funções, que foram gerados no próprio desenvolvimento.
Finalmente, os demais artefatos são ditos
documentos.
Utilizamos o predicado artefato(s,t) para denotar
que s é um artefato do tipo t, onde t assume um dos seguintes valores: {Componente, Documento,
As relações insumo e produto foram formalizadas
pelos predicados insumo(s,a), denotando que o artefato s é um insumo para a atividade a, e
produto(s,a), denotando que o artefato s é um produto da atividade a.
Para garantir sua integridade, os seguintes axiomas
de consolidação devem ser observados:
( a, s) ( insumo(s, a) artefato(s,*) atividade(a))
( a, s) ( produto(s, a) artefato(s,*) atividade(a))
onde o asterisco (*) indica que não importa o valor atribuído para este argumento.
A partir dos predicados insumo e produto,
podemos elaborar uma outra definição para o conceito de pré-atividade:
Uma atividade a1 é uma pré-atividade de uma
atividade a2, se e somente se, existe pelo menos um artefato s que é um produto de a1 e um
insumo para a2.
( a1 ,a2) (preatividade(a1 ,a2) ( s) (insumo(s,a2 ) produto(s,a1))
Podemos, ainda, estabelecer relações entre
insumos e produtos de uma atividade
composta, dadas pelos seguintes axiomas:
Um artefato s é um insumo para uma atividade composta a, onde a é decomposta nas
sub-atividades {a1 , a2 ,..., an }, se s é um insumo para alguma atividade ai, mas não é um produto de nenhuma outra atividade ak, onde ai e ak {a1 , a2 ,..., an }.
( a, a1 ,..., an ,s) (subatividade(a1 ,a) ... subatividade(an ,a) insumo(s,ai ) ((
Um artefato s é um produto de uma atividade
composta a, onde a é decomposta nas sub-atividades {a1 , a2 ,..., an }, se s é um
produto de alguma atividade ai {a1 ,...,
an }, e é um insumo para alguma atividade b,
sendo que b {a1 , a2 ,..., an }.
( a, a1 ,..., an ,s) (subatividade(a1 ,a) ... subatividade(an ,a) produto(s,ai ) (( b) (insumo(s,b) b {a1 , a2 ,..., an }))
A cardinalidade (1,n) do conceito atividade
para com a relação produto, mostrada na figura 5.5, reflete o seguinte axioma: toda atividade tem de produzir pelo menos um artefato.
Artefatos
Artefatos, assim como atividades, são
elementos compostos. Um artefato pode ser composto de outros sub-artefatos.
Axiomas inerentes à relação de composição,
similares aos descritos para atividades, são igualmente válidos.
Artefato super-artefato sub-artefato
