ĠĢ ArkadaĢları ile ĠliĢkiler ve ĠĢ Tatmini ĠliĢkisi

Os axiomas desenvolvidos para a ontologia O4C são apresentados e explicados nesta seção. A lista de predicados utilizados nestes axiomas, bem como a descrição dos mesmos podem ser visualizadas no Quadro 3.1.

Quadro 3.1. Predicados utilizados nos axiomas da ontologia O4C.

Predicado Descrição

hasSubconcern(c1, c2) O interesse “c2” é subinteresse de “c1”.

hasKw(c, kw) O interesse “c” possui “kw” como uma de suas palavra-_chave.

cutAcross(c, r) O interesse “c” entrecorta o requisito “r”.

mainConcern(r, c) O requisito “r” possui “c” como seu interesse principal. dependsOn(r1, r2) O requisito “r1” depende do requisito “r2”.

isRelatedTo(rel, c1, c2)

O interesse “c1” está relacionado com o interesse “c2” por meio do relacionamento “rel”, tal que “c1” é o interesse fonte e “c2” é o interesse alvo.

isAConcernDependency(rel) O relacionamento “rel” é do tipo “Dependency”. diffConcerns(c1, c2) Os interesses “c1” e “c2” são diferentes.

hasIndication(ind, c) Há um indício “ind” de que o requisito “c” está presente _{no software em análise.}

Axioma 1: (∀ c1, c2, kw) : (hasSubConcern(c1, c2) ^ hasKw(c2, kw) → hasKw(c1, kw) )

O Axioma 1 é um axioma de derivação e especifica que, dados dois interesses “c1” e “c2”, sendo “c2” um subinteresse de “c1”, se “kw” é uma palavra-chave de “c2”, então “kw” também é uma palavra-chave de “c1”.

Axioma 2:

(∀ c1, c2, r):

(hasSubConcern(c1, c2) ^

cutAcross(c2, r) → cutAcross(c1, r) )

O Axioma 2 (de derivação) especifica que, _{se um interesse “c2” entrecorta o requisito} “r”, sendo “c2” um subinteresse de “c1”, então “c1” também entrecorta o requisito “r”.

Axioma 3:

(∀ c1, r, mc): (

cutAcross(c1, r) ^ mainConcern(r, mc) → diffConcerns(c, mc) )

O Axioma 3 é um axioma de consolidação, que especifica que um interesse “c1” só pode entrecortar um requisito “r”, caso ele não seja o seu interesse principal “mc”. A justificativa é que se “c1” é o interesse principal do requisito “r”, então ele não exerce comportamento transversal sobre o mesmo.

Axioma 4:

(∀ r1, r2, c1): (dependsOn(r1, r2) ^

cutAcross(c1, r2) → cutAcross(c1, r1) )

O Axioma 4 (de derivação) especifica que, se um requisito “r1” depende do requisito “r2” e “r2” é entrecortado por “c1”, então “r1” também é entrecortado por “c1”.

Axioma 5: (∀ r1, r2, mc1, mc2): (dependsOn(r1, r2) ^ mainConcern(r2, mc2) ^ mainConcern(r1, mc1) ^ diffConcerns(mc1, mc2) → cutAcross(mc2, r1) )

O Axioma 5 (de derivação) especifica que se um requisito “r1” depende do requisito “r2”, sendo “mc1” o interesse principal de “r1”, “mc2” o interesse principal de “r2” e “mc1” diferente de “mc2”, então “r2” é entrecortado por “mc2”. Em outras palavras, isso significa que o interesse principal de um requisito pode ser um interesse transversal de outro requisito. Por exemplo, considere os requisitos “r1: o software deve permitir a emissão da segunda via da conta do cliente, por meio do seu número de controle_{” e “r2: o custo da} emissão de uma segunda via da conta de telefone deve ser cobrado na próxima fatura do cliente”, sendo que “r1” depende de “r2”. Considerando que “Gerenciamento de Nota Fiscal” seja o interesse principal de “r1” e “Faturamento” o interesse principal de “r2”, segundo o Axioma 5, “Faturamento” entrecorta o interesse “Gerenciamento de Nota Fiscal” no requisito “r1”.

Axioma 6:

(∀ rel, c1, c2, ind1, ind2): (isRelatedTo(rel, c1, c2) ^ isAConcernDependecy(rel) ^

hasIndication(ind1, c1) → hasIndication(ind2, c2) )

O Axioma 6 (de derivação) especifica que _{se há dois interesse “c1” e “c2”, tal que} “c1” depende de “c2” e “c1” foi identificado no software, ou seja, há algum indício “ind1” de que “c1” está presente no software em análise, então deve haver algum indício “ind2” de que o interesse “c2” também está presente no software.

3.4 Considerações Finais

Neste capítulo apresentou-se a ontologia para interesses de software no contexto da EROA, denominada O4C. Tal ontologia foi utilizada como base para a construção da abordagem para identificação e classificação de interesses de software ObasCId e da ferramenta ObasCId-Tool, apresentadas nos Capítulos 4 e 5 desta tese, respectivamente.

A ontologia O4C foi simbolicamente dividida em duas partes A e B, sendo que a parte A apresenta conceitos independentes de contexto, isto é, que podem ser instanciados para formar uma base de conhecimento comum sobre interesses de software. Ao instanciar a parte A da ontologia O4C, o pesquisador estará elaborando catálogos para tipos específicos de interesses de software, descrevendo com quais palavras-chave esses interesses se relacionam, como eles dependem de outros interesses, entre outras coisas.

Assim, com a O4C, os pesquisadores poderão construir um arcabouço de catálogos de interesses que poderão ser (re)utilizados como apoio para facilitar a identificação de interesses transversais. No Capítulo 4 desta tese, são apresentados alguns exemplos de catálogos de interesses elaborados a partir de fontes diversas, como catálogos de requisitos não funcionais e projetos anteriores, bem como um conjunto de passos para utilização destes catálogos durante a identificação e classificação de interesses a partir de requisitos de software.

A parte B da ontologia O4C descreve conceitos que dependem do projeto de software sobre o qual as instâncias dos conceitos da parte A da ontologia estão sendo aplicadas. Esses conceitos incluem os requisitos do software e seus relacionamentos, dentre outras informações. Apesar de esses conceitos serem específicos para cada projeto, eles podem ser úteis para atualização das instâncias de conceitos da parte A da ontologia. Por exemplo, durante a identificação de interesses em um determinado software, pode-se notar a necessidade de atualizar o conjunto de palavras-chave de um interesse para aprimorar sua cobertura no software.

No Quadro 3.2 estão resumidos os principais conceitos e relacionamentos definidos na O4C, destacando-se os trabalhos relacionados à EROA que propõem alguma forma de representação dos mesmos. O símbolo “-”, quando utilizado, representa que o conceito/relacionamento não foi explorado por um determinado trabalho relacionado.

Como pode ser visto no Quadro 3.2, muitas das abordagens contemplam apenas os conceitos “Concern”, “NonFunctionalConcern”, “NonFunctionalConcern” e “NonFunctionalCCC”. Sendo assim, há carência de abordagens que propõem formas de representação para conceitos referentes aos tipos de requisitos de um software (“FunctionalRequirement” e “NonFunctionalRequirement”), aos tipos de relacionamentos

existentes entre interesses (_{tais como “Composition”), aos interesses e suas palavras-chave} (“Keyword”), entre requisitos (“RequirementDependency”) e aos interesses e requisitos (“Indication”, “MainConcernIndication”, “FunctionalCCCIndication” e “NonFunctionalCCCIndication”).

Destaca-se ainda que não há abordagens que contemplam todos os conceitos descritos na ontologia O4C. As duas abordagens que apresentam maior quantidade de conceitos em comum com a ontologia O4C (oito conceitos) são MDSoC (Moreira et al., 2005) e EROA/XML (Soeiro et al., 2006).

Quadro 3.2. Trabalhos relacionados aos conceitos da ontologia O4C. Conceito da O4C/ Trabalhos relacionados 1 2 3 4 5 6 7 8 9 10 11 12 13 Concern X X X X X X X X X X X X X NonFunctionalConcern X X X X X X X X X X X X X FunctionalConcern X X X X X X X X X X X X X Keyword - - - - Source X X X - - - - Composition - - - - Dependency - - - - X - - - - Contribution - - - X X - - - - Priority - - - X X - - - - Requirement - - - X X X X X X - - - - FunctionalRequirement, - - - - NonFunctionalRequirement - - - - RequirementsDependency - - - - NonFunctionalCCC X X X X X X X X X X X X X FunctionalCCC - - - X - - - - Indication - - - - FunctionalCCCIndication - - - - NonFunctionalCCCIndication - - - - MainConcernIndication - - - -

Legenda: 1. Agostinho et al., 2008; 2. Whittle e Araújo, 2004; 3. Brito e Moreira, 2003; 4. Moreira et al., 2005; 5. Soeiro et al., 2006; 6. Chitchyan et al., 2006; 7. Sampaio et al., 2005; 8. Clarke e

Baniassad, 2005; 9. Baniassad e Clarke, 2004; 10. Chernak, 2012; 11. Zheng et al., 2010; 12. Alencar