PONTIFICIA UNIVERSIDADE CATLICA DO RIO GRANDE DO SUL

FACULDADE DE INFORMTICA

VANESSA BARBISAN PIRES

ANLISE DE IMPACTO DE MUDANA DE SOFTWARE:

UMA METODOLOGIA BASEADA EM ONTOLOGIAS

Porto Alegre
2006

VANESSA BARBISAN PIRES

ANLISE DE IMPACTO DE MUDANA DE SOFTWARE:

UMA METODOLOGIA BASEADA EM ONTOLOGIAS

Trabalho apresentado ao Programa de Ps-Graduao em

Cincia da Computao como requisito parcial obteno
do grau de Mestre em Cincia da Computao.
Pontifcia Universidade Catlica do Rio Grande do Sul
Orientador: Prof. D. Sc. Marcelo Blois Ribeiro.

Porto Alegre, 2006

Dedico essa dissertao ao meu namorado Jos Olavo.

Aos meus amigos, alm de me e padrasto, Rose e Jaurs.
A meu pai, que torce mesmo distante. s minhas irms
Michele, Fran, Carol e Sthefane. E minha tia Jane, minha v Ruth e meu v Ruy.

AGRADECIMENTOS

Ao meu orientador, Prof. Dr. Marcelo Blois Ribeiro, pelo incentivo, pela perseverana nos
momentos difceis e pelo otimismo de que o caminho estava certo. Agradeo principalmente
por ter aceitado o desafio de orientar uma aluna que no podia dedicar integralmente seu
tempo para desenvolver a pesquisa.
Aos professores Dr. Ricardo Bastos e Dr. Toacy Oliveira, que deram suas contribuies ao
longo do desenvolvimento desse trabalho, revisando e criticando os volumes produzidos.
Aos professores Dr Mrcia Campos, minha orientadora no trabalho de concluso do curso
de graduao em Cincia da Computao, e Dr. Michael Mra, que teve pacincia de revisar
os mais diversos assuntos para a prova do POSCOMP, agradeo pelas cartas de recomendao.
Ao professor Dr. Avelino Zorzo que, na condio de coordenador do Programa de PsGraduao, me concedeu uma bolsa de estudos, possibilitando o trmino dessa pesquisa.
Ao meu chefe Eduardo Peres que, mais do que ter me incentivado sugeriu a linha de pesquisa
a ser abordada. Agradeo a compreenso e preocupao ao longo desse perodo e posso dizer que foi mais do que meu diretor, foi meu amigo. E DBServer agradeo por ter apostado
nesta minha qualificao.
Ao meu hoje amigo Arthur Sfreddo, que na condio de meu chefe na PROCERGS, soube
apoiar o meu projeto e acreditar na minha capacidade profissional, mesmo sem nunca antes
ter trabalhado comigo, flexibilizando meus horrios para que eu pudesse assistir s aulas.
Aos colegas do Grupo de Sistemas de Software Inteligentes, que contriburam com suas opinies e idias. Agradeo ao colega Rodrigo Noll pelo nosso trabalho em equipe durante o
desenvolvimento dessa pesquisa. Aos colegas Oscar e Ana Paula no apoio ao desenvolvimento da ferramenta. Tambm a todos os alunos do Programa de Ps-Graduao em Cincia da
Computao que participaram dos experimentos propostos.
A todos os meus amigos que estiveram presentes nesse momento, torcendo, me incentivando e
ajudando das mais diversas maneiras. Principalmente, ao amigo Ricardo Angrisani, que junto comigo acreditou ser possvel concluir o mestrado. Ao meu quase irmo Tasso que certamente foi a grande inspirao para eu tambm querer o ttulo de mestre! Silvana e ao Mauricio que quase diariamente me escutaram e deram fora. ngela, Carol, Tanara, Andr,
Cssio, Ed, Eduardo, Pescoo e Marcus que ouviram muitos: No posso ir. E a minha cunhada e amiga Janise que se disps a revisar esse trabalho.
minha famlia agradeo pelo apoio incondicional. Ao tio e a me por todo carinho e incentivo, segurando minha onda nos momentos difceis. Ao meu pai, pela torcida. As minhas irms, pela presena. A minha tia, que diz que algo est a minha espera aps a concluso desse trabalho. E ao orgulho que meus avs tem pela neta.
E, especialmente, ao meu amigo alm de namorado, Olavo, pela ajuda nos trabalhos, por
compreender as ausncias e pela paz e segurana que me transmitiu nos meus momentos de
dvida.

"O mais importante para o homem crer em si mesmo.

Sem esta confiana em seus recursos, em sua inteligncia,
em sua energia, ningum alcana o triunfo a que aspira"
Thomas Atkinson.

RESUMO

Quando um requisito de mudana solicitado durante um projeto de manuteno,

toda a informao referente a ele deve ser rastreada a fim de que seja possvel desenvolv-lo.
Nessa realidade est inserida a anlise de impacto de uma mudana que visa, entre outras coisas, estabelecer a probabilidade de impacto que um artefato ter. O principal objetivo desse
trabalho o desenvolvimento de uma metodologia de anlise de impacto de mudana em projetos de manuteno de software. Para que seja possvel realiz-la, preciso rastrear os artefatos que compem o sistema. O rastreamento realizado pelos conceitos da ontologia gerada
durante o processo de desenvolvimento de software a partir do modelo de domnio.
Palavras-chave: Projetos de manuteno de software, anlise de impacto, rastreabilidade, ontologia, processo de desenvolvimento de software.

ABSTRACT

When a change requirement is generated during a software project, all information

necessary for its development must be traced. In this context, the change impact analysis focus on finding the probability of an artifact impact to be modified. The main goal of this work
is to develop a change impact methodology for software maintenance projects. To analyze the
change impact it is necessary to use a traceability methodology. In our approach, the traceability is enforced by the ontology concepts that are generated from the domain model during
the software development process. The methodology validation will be made by an experiment.
Keywords: software maintenance project, impact analysis, traceability, ontology,
software development process.

LISTA DE FIGURAS

Figura 1 Exemplo de ontologia. ............................................................................................ 20

Figura 2 Fluxo para determinar anlise de impacto de mudana. ......................................... 27
Figura 3 Processo de anlise de impacto proposto por Bohner. ............................................ 27
Figura 4 Grafo com relacionamento entre objetos do ciclo de vida do software (OCV) ...... 29
Figura 5 Modelo de rastreamento entre os artefatos do sistema............................................ 31
Figura 6 Relacionamento entre mudanas, artefatos e grau de influncia entre eles. ........... 32
Figura 7 Relacionamento entre artefatos e requisitos de mudana. ...................................... 33
Figura 8 Integrao da disciplina de Engenharia Ontolgica ao RUP .................................. 39
Figura 9 Representao da rastreabilidade semntica atravs de ontologia .......................... 40
Figura 10 Exemplo de diagrama de classes. .......................................................................... 47
Figura 11 Aplicao do mtodo Fast&&Serious. .................................................................. 48
Figura 12 Requisito de mudana A, no domnio de livros. ................................................... 48
Figura 13 Exemplo de diagrama de classes aps alterao do requisito de mudana A. ...... 48
Figura 14 Nveis de influncia entre artefatos na metodologia TIAM. ................................. 49
Figura 15 - Valores de influncia normalizados entre artefatos na metodologia TIAM. ......... 50
Figura 16 - Relacionamento entre conceitos da ontologia e artefatos de software. ................. 50
Figura 17 - Influncia do conceito no artefato (Ic) do conceito Autor. .................................... 52
Figura 18 Exemplo em OWL da restrio allValuesFrom .................................................... 55
Figura 19 Sub ontologia equivalente ao domnio de livros. .................................................. 56
Figura 20 Requisito de mudana B no domnio de livros. .................................................... 56
Figura 21 Sub ontologia equivalente ao requisito de mudana no domnio de livros. .......... 56
Figura 22 Parte de um modelo de domnio de livros............................................................. 57
Figura 23 Ontologia equivalente a parte de um modelo de domnio de livros. ..................... 58
Figura 24 Ontologia equivalente ao requisito de mudana A no domnio de livros. ............ 58
Figura 25 Requisito de mudana C no domnio de livros. .................................................... 59
Figura 26 Ontologia equivalente ao requisito de mudana C no domnio de livros. ............ 59
Figura 27 Exemplo de radicalizao de palavras. ................................................................. 61
Figura 28 Sub ontologia equivalente ao domnio de livros, destacando a propriedade
objectProperty. ................................................................................................................. 62
Figura 29 Exemplo de tesauro. .............................................................................................. 63
Figura 30 Exemplo de clculo do Impacto acumulado (Ia(x)). .............................................. 65
Figura 31 Exemplo do clculo do Impacto no Artefato pelo Relacionamento (Iar(x,y)) ........ 66
Figura 32 Exemplo de clculo da Propagao do impacto (Pi). ........................................... 66
Figura 33 Passos da metodologia de anlise de impacto baseada em ontologias.................. 67
Figura 34 Desenvolvimento do modelo conceitual do requisito de mudana ....................... 68
Figura 35 Gerar ontologia do requisito de mudana a partir de um modelo conceitual........ 68
Figura 36 Interseco entre ontologias .................................................................................. 69

Figura 37 Identificao dos conceitos da ontologia do requisito de mudana na ontologia do

sistema .............................................................................................................................. 69
Figura 38 Identificao de incluso de um conceito do tipo dataTypeProperty ................... 70
Figura 39 Identificao de alterao de um conceito do tipo dataTypeProperty .................. 70
Figura 40 Identificao de um conceito do tipo dataTypeProperty que no sofre mudana 70
Figura 41 Identificao de relacionamento entre conceitos .................................................. 71
Figura 42 Rastreabilidade de relao conceito-artefato ........................................................ 72
Figura 43 Rastreabilidade de alterao de um conceito do tipo dataTypeProperty .............. 73
Figura 44 Clculos da relao dataTypeProperty-Artefato. .................................................. 73
Figura 45 Rastreabilidade de incluso de um conceito do tipo dataTypeProperty ............... 74
Figura 46 Clculos da relao estrutural class-Artefato ........................................................ 75
Figura 47 Alterao de regra de negcio associada a conceito ............................................. 75
Figura 48 Clculos da relao semntica class-Artefato ....................................................... 75
Figura 49 Identificao de um conceito do tipo dataTypeProperty que no sofre mudana 76
Figura 50 Clculos da relao class-Artefato sem alteraes. .............................................. 76
Figura 51 Rastreabilidade de relao conceito-conceito ....................................................... 77
Figura 52 Rastreabilidade de artefatos na relao conceito-conceito.................................... 77
Figura 53 Clculo do Impacto acumulado (Ia(x)) ................................................................... 78
Figura 54 Tela com os conceitos do tipo class e dataTypeProperty ..................................... 80
Figura 55 Entrada das influncias do conceito e tipo de diagrama ....................................... 81
Figura 56 Tela com os conceitos do tipo objectProperty ...................................................... 81
Figura 57 Tela para informao se houve alterao de regra de negcio.............................. 82
Figura 58 Comparao de ontologias atravs de cdigo XML ............................................. 83
Figura 59 Tela com menu de escolha para comparao da ontologias e clculo do impacto 83
Figura 60 Requisito de mudana para o sistema IsGym ........................................................ 84
Figura 61 Dicionrio de Dados IsGym .................................................................................. 85
Figura 62 Modelo de conceitual do requisito de mudana .................................................... 85
Figura 63 Ontologia do requisito de mudana representada em XML.................................. 86
Figura 64 Ontologia do requisito de mudana representada graficamente. .......................... 87
Figura 65 Representao parcial da ontologia do sistema, com conceitos do requisito de
mudana assinalados......................................................................................................... 88
Figura 66 Identificao do conceito meta. ......................................................................... 88
Figura 67 Identificao do conceito FichaBiometrica. ...................................................... 88
Figura 68 Identificao do conceito Mensalidade, com alterao estrutural. .................... 89
Figura 69 Identificao do conceito Mensalidade, com alterao de regra de negcio..... 89
Figura 70 Rastreamento dos artefatos ligados ao conceito meta. ...................................... 90
Figura 71 Clculo dos artefatos ligados ao conceito meta. ................................................ 90
Figura 72 Rastreamento dos artefatos ligados ao conceito FichaBiometrica. ................... 90
Figura 73 Clculos dos artefatos ligados ao conceito FichaBiometrica. ........................... 91
Figura 74 Rastreamento dos artefatos ligados ao conceito Mensalidade........................... 91
Figura 75 Clculos dos artefatos ligados ao conceito Mensalidade - estrutural. ............... 91
Figura 76 Clculos dos artefatos ligados ao conceito Mensalidade regra de negcio. ... 91
Figura 77 Rastreamento dos artefatos ligados ao conceito Cliente. .................................. 92
Figura 78 Clculos dos artefatos ligados ao conceito Cliente. .......................................... 93
Figura 79 Rastreamento dos artefatos ligados ao conceito Funcionrio. ........................... 94
Figura 80 Clculos dos artefatos ligados ao conceito Funcionrio. ................................... 95
Figura 81 Clculo da mdia ponderada. ................................................................................ 97
Figura 82 Variveis independentes e dependentes do estudo experimental. ....................... 104
Figura 83 Grfico de barras relativo preciso dos artefatos. ............................................ 112
Figura 84 Grfico de disperso para a varivel preciso. .................................................... 114

Figura 85 Modelo de caso de uso de negcio para o contexto Criar Ficha de

Acompanhamento de Cliente. ........................................................................................ 127
Figura 86 Modelo de atividades de negcio para o contexto Criar Ficha de
Acompanhamento de Cliente. ........................................................................................ 128
Figura 87 Modelo de interao de negcio para o contexto Criar Ficha de Acompanhamento
de Cliente. ....................................................................................................................... 128
Figura 88 Modelo de objetos de negcio para o contexto Criar Ficha de Acompanhamento
de Cliente. ....................................................................................................................... 128
Figura 89 Diagrama de casos de uso do sistema IsGym. ..................................................... 129
Figura 90 Descrio do caso de uso Criar Ficha Pessoal. ................................................... 130
Figura 91 Diagrama de atividades Criar Ficha Pessoal. ...................................................... 130
Figura 92 Modelo de classe de anlise Criar Ficha Pessoal. ............................................... 131
Figura 93 Modelo de colaborao em anlise Criar Ficha Pessoal. .................................... 131
Figura 94 Modelo de sequencia Criar Ficha Pessoal........................................................... 131
Figura 95 Diagrama de classes do sistema IsGym............................................................... 132
Figura 96 Resultado do questionrio aplicado para conhecer o perfil dos alunos. ............. 133
Figura 97 Exemplo de preenchimento do relatrio de conjunto de impacto. ...................... 134
Figura 98 Requisito de mudana 2 para sistema IsGym. ..................................................... 135
Figura 99 Requisito de mudana 3 para sistema IsGym. ..................................................... 136
Figura 100 Artefatos impactados pelo requisito de mudana 1........................................... 137
Figura 101 Artefatos impactados pelo requisito de mudana 2........................................... 137
Figura 102 Artefatos impactados pelo requisito de mudana 3........................................... 138
Figura 103 Tutorial fornecido para os participantes executarem a anlise de impacto
ontolgica. ...................................................................................................................... 139
Figura 104 Planilha para preenchimento das variveis da metodologia de anlise de impacto
ontolgica. ...................................................................................................................... 140
Figura 105 Tutorial fornecido para os participantes executarem a anlise de impacto por
requisitos......................................................................................................................... 140
Figura 106 Planilha para preenchimento das variveis da metodologia de anlise de impacto
por requisitos. ................................................................................................................. 141
Figura 107 Questionrio fornecido para os participantes. ................................................... 141

LISTA DE TABELAS

Tabela I Matriz de conectividade .......................................................................................... 29

Tabela II Atividades por fase da Engenharia Ontolgica. ..................................................... 38
Tabela III Passos do mtodo Fast&&Serious ........................................................................ 45
Tabela IV Passos dos atributos no mtodo Fast&&Serious .................................................. 45
Tabela V Guideline para classificao da Influncia do conceito no artefato (Ic) ................ 51
Tabela VI Classificao do tipo de diagrama ........................................................................ 53
Tabela VII Probabilidade de impacto dos artefatos rastreados. ............................................ 96
Tabela VIII Tabela de contingncia. ................................................................................... 106
Tabela IX Escalas das variveis. ......................................................................................... 111
Tabela X Tabulao dos valores brutos obtidos aps a execuo do experimento. ............ 112
Tabela XI Teste de normalidade Shapiro-Wilk para a varivel preciso. ........................... 114
Tabela XII Teste de Levene para igualdade das varincias sobre a varivel preciso. ....... 115
Tabela XIII Teste no paramtrico de Mann-Whitney para a varivel preciso. ................ 115
Tabela XIV Estatstica descritiva para a varivel preciso. ................................................ 116
Tabela XV Resultados da avaliao qualitativa. ................................................................. 117
Tabela XVI Mdia da satisfao das questes sobre as abordagens. .................................. 117

LISTA DE FRMULAS

Frmula 1 Artefatos que sero alterados ............................................................................... 28

Frmula 2 Clculo do nmero de Pontos por Estado ............................................................ 45
Frmula 3 Clculo da Complexidade do Mtodo .................................................................. 46
Frmula 4 Clculo dos Pontos por Comportamento ............................................................. 46
Frmula 5 Clculo dos Pontos por Classe ............................................................................. 46
Frmula 6 Clculo do peso do artefato .................................................................................. 47
Frmula 7 Normalizao dos elos na metodologia TIAM .................................................... 49
Frmula 8 Clculo do Impacto no artefato pela mudana (Iam(x,y)) ...................................... 54
Frmula 9 Clculo do Impacto acumulado (Ia(x)).................................................................. 65
Frmula 10 Clculo da Propagao do impacto (Pi)............................................................. 65
Frmula 11 Clculo do Impacto no artefato pelo relacionamento (Iar(x,y)). .......................... 66
Frmula 12 Clculo do Percentual de probabilidade de impacto do artefato (Ppi(y)). .......... 79
Frmula 13 Clculo da mdia ponderada. ............................................................................. 79
Frmula 14 Clculo da varivel Preciso. ........................................................................... 101

LISTA DE ABREVIATURAS

GQM

Goal, Question, Metric

JSP

JavaServer Pages

OO

Orientao a Objetos

OWL

Web Ontology Language

PLN

Processamento de Linguagem Natural

RUP

Rational Unified Process

SLOC

Source Line of Code

TIAM

Trace-based Impact Analysis Methodology

UML

Unified Modeling Language

XML

eXtensible Markup Language

WMSWM Workshop de Manuteno de Software Moderna

SUMRIO

1
2

INTRODUO .......................................................................................................................................... 17
REFERENCIAL TERICO ..................................................................................................................... 19
2.1 ONTOLOGIA .............................................................................................................................................. 19
2.2 ONTOLOGIA E PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ............................................................ 21
2.3 PROJETO DE MANUTENO DE SOFTWARE................................................................................................ 22
2.4 RASTREABILIDADE ................................................................................................................................... 23
2.5 ANLISE DE IMPACTO .............................................................................................................................. 25
2.5.1
Modelos de Anlise de Impacto ..................................................................................................... 26
2.5.1.1
2.5.1.2

Modelos de Bohner ...................................................................................................................................27

Metodologia baseada em rastreabilidade ...................................................................................................30

2.6 ENGENHARIA DE SOFTWARE EXPERIMENTAL............................................................................................ 34

MODELANDO A ANLISE DE IMPACTO DE MUDANA ............................................................. 37
3.1 ENGENHARIA ONTOLGICA ..................................................................................................................... 38
3.2 RASTREABILIDADE SEMNTICA ATRAVS DE ONTOLOGIA ........................................................................ 40
3.3 INFLUNCIA DA COMPLEXIDADE DE ARTEFATO........................................................................................ 41
3.3.1
Complexidade de Artefato ............................................................................................................. 42
3.3.1.1 Mtricas de produto de software................................................................................................................ 42
3.3.1.2 Mtricas para UML ...................................................................................................................................44
3.3.1.2.1
Complexidade do Diagrama de Classes .......................................................................................... 44

3.3.2
Uso da Complexidade de Artefato ................................................................................................. 46
3.4 INFLUNCIA DO CONCEITO DA ONTOLOGIA NOS ARTEFATOS.............................................................. 49
3.5 INFLUNCIA DO TIPO DE DIAGRAMA NA ANLISE DE IMPACTO ................................................................ 52
3.6 INFLUNCIA DO TIPO DE MUDANA NA ANLISE DE IMPACTO .................................................................. 53
3.6.1
Tipo de Mudana de Regras de Negcio ....................................................................................... 54
3.6.2
Tipo de Mudana Estrutural .......................................................................................................... 55
3.6.2.1 Alterao de um conceito da ontologia. ..................................................................................................... 55
3.6.2.2 Incluso de um conceito na ontologia........................................................................................................ 57
3.6.2.2.1
Incluso de conceito do tipo dataTypeProperty .............................................................................. 57
3.6.2.2.2
Incluso de conceito do tipo class ...................................................................................................59

3.7 INFLUNCIA DO RELACIONAMENTO ENTRE CONCEITOS ............................................................................ 60

3.7.1
Processamento de Linguagem Natural .......................................................................................... 60
3.7.1.1
3.7.1.2

Processamento Morfossinttico ................................................................................................................. 61

Processamento Semntico ......................................................................................................................... 62

3.7.2
Clculo da Influncia do Relacionamento entre Conceitos ........................................................... 64
METODOLOGIA PARA ANLISE DE IMPACTO DE MUDANA ................................................ 67
4.1 GERAR ONTOLOGIA DO REQUISITO DE MUDANA ................................................................................... 68
4.2 IDENTIFICAR CONCEITOS NA ONTOLOGIA DO SISTEMA ............................................................................. 69
4.3 RASTREAR ARTEFATOS ............................................................................................................................ 71
4.3.1
Relao Conceito-Artefato ............................................................................................................ 72
4.3.1.1
4.3.1.2

Relao dataTypeProperty-Artefato .......................................................................................................... 73

Relao class-Artefato............................................................................................................................... 74

4.3.2
Relao Conceito-Conceito ........................................................................................................... 76
4.4 LISTAR ARTEFATOS .................................................................................................................................. 79
4.5 FERRAMENTA........................................................................................................................................... 80
4.6 EXEMPLO DE APLICAO DA METODOLOGIA ............................................................................................ 83

4.6.1
Gerar Ontologia do Requisito de Mudana................................................................................... 84
4.6.2
Identificar Conceitos na Ontologia do Sistema ............................................................................. 87
4.6.3
Rastrear Artefatos.......................................................................................................................... 89
4.6.4
Listar e Calcular a Probabilidade dos Artefatos ........................................................................... 96
5
VALIDAO DA METODOLOGIA ...................................................................................................... 99
5.1 DEFINIO ............................................................................................................................................... 99
5.1.1
Objetivo Global ........................................................................................................................... 100
5.1.2
Objetivo do Estudo ...................................................................................................................... 100
5.1.3
Objetivo da Medio ................................................................................................................... 100
5.1.4
Questo ........................................................................................................................................ 101
5.1.5
Mtricas ....................................................................................................................................... 101
5.2 PLANEJAMENTO ..................................................................................................................................... 102
5.2.1
Seleo do Contexto .................................................................................................................... 102
5.2.2
Formulao das Hipteses .......................................................................................................... 103
5.2.3
Seleo das Variveis .................................................................................................................. 104
5.2.3.1
5.2.3.2

5.2.4
5.2.5

Seleo dos Indivduos ................................................................................................................ 105

Projeto do Experimento ............................................................................................................... 105

5.2.5.1
5.2.5.2

5.2.6
5.2.7

Varivel Independente ............................................................................................................................. 104

Varivel Dependente ............................................................................................................................... 104

Princpios Genricos de Projetos ............................................................................................................. 105

Padro para Tipo de Projeto .................................................................................................................... 106

Instrumentao ............................................................................................................................ 107

Anlise da Validade ..................................................................................................................... 107

5.2.7.1
5.2.7.2
5.2.7.3
5.2.7.4

Validade Interna ...................................................................................................................................... 108

Validade Externa ..................................................................................................................................... 108
Validade de Construo ........................................................................................................................... 108
Validade de Concluso ............................................................................................................................ 109

5.3 EXECUO ............................................................................................................................................. 110

5.3.1
Preparao .................................................................................................................................. 110
5.3.2
Execuo...................................................................................................................................... 111
5.4 ANLISE E INTERPRETAO ................................................................................................................... 111
5.4.1
Anlise Tabular e Grfica ........................................................................................................... 112
5.4.2
Estatstica Descritiva ................................................................................................................... 113
5.4.3
Hiptese: Preciso ...................................................................................................................... 113
5.5 AVALIAO QUALITATIVA ..................................................................................................................... 116
5.6 CONSIDERAES .................................................................................................................................... 117
6
CONCLUSO E TRABALHOS FUTUROS ........................................................................................ 119
REFERNCIAS ................................................................................................................................................ 123
APNDICE A RESULTADOS DO EXPERIMENTO ............................................................................... 127
APNDICE B INSTRUMENTAO DO EXPERIMENTO DE VALIDAO .................................... 139

16

17

INTRODUO

A fase inicial do ciclo de vida de um produto de software o processo de desenvolvimento, aonde ir se construir o sistema desejado pelo cliente. Quando esta finalizada,
inicia-se a manuteno do produto que, segundo a organizao do Workshop de Manuteno
de Software Moderna (WMSWM)[WMS04], a fase do ciclo de vida do software que consome mais recursos, sendo responsvel por aproximadamente 90% do custo total deste. Isso
se d por vrios motivos, dentre eles mudanas tecnolgicas, alterao de necessidades do
usurio e falhas encontradas aps sua instalao.
Para tentar manter a qualidade do produto e conseguir estimar o esforo e tempo
necessrios para realizar uma mudana no software, preciso que se tenha uma maneira otimizada para descobrir todas as partes do sistema que sero afetadas pela alterao. Essas podem ser obtidas por um modelo de anlise de impacto, que ir determinar de que forma os
artefatos so impactos e qual a probabilidade disso ocorrer. Existem diversas pesquisas nessa
rea, com propostas que visam encontrar o conjunto de artefatos impactados mais prximo da
realidade, ou seja, encontrar com preciso os elementos que sero efetivamente modificados.
Para que seja possvel obter esse conjunto, necessrio possuir um mecanismo de
rastreabilidade que suporte a anlise de impacto. Um autor que se destaca em pesquisas nesse
sentido Bohner[BOH96] com diversos artigos e livro publicados. Ele props uma metodologia de anlise de impacto, rastreando os artefatos atravs das ligaes entre eles, representadas
em um grafo de conectividade. Outro trabalho interessante foi realizado por ONeal[ONE03],
onde a probabilidade de impacto nos artefatos determinada e a rastreabilidade feita atravs
dos requisitos do sistema.
Outro mtodo utilizado para realizar o rastreamento de artefatos faz uso de mecanismos semnticos para tal, visando uma maior assertividade para encontrar o conjunto de
elementos que sero alterados. Atravs de pesquisa realizada por Noll[NOL05a], notou-se que
ontologias poderiam ser integradas ao processo de desenvolvimento de software e, atravs de
seus conceitos, realizar a rastreabilidade semntica dos artefatos. Uma das contribuies de

18
utilizar ontologia nesse contexto que esta permite integrar os elementos produzidos, desde a
modelagem de negcio, at a anlise e projeto.
Considerando-se que o uso desse tipo de rastreabilidade traria ganho para encontrar mais precisamente os artefatos modificados a partir de um requisito de mudana, foi desenvolvida uma metodologia para anlise de impacto baseada em ontologias. Essa responsvel por identificar as alteraes que ocorrem na ontologia do sistema e assim mensurar a probabilidade de impacto em cada um dos artefatos.
Para a construo dessa proposta, buscou-se compreender o que so, o que representam e como as ontologias se integram ao processo de desenvolvimento de software. Pesquisou-se saber tambm, como definida a fase de manuteno de um produto, onde diversos
requisitos de mudana so solicitados. Sendo a diferena entre rastreabilidade e anlise de
impacto bastante tnue, procurou-se estabelecer fortemente as diferenas entre elas. Ainda
como parte do referencial terico, abordado no captulo 2, estudou-se a disciplina de Engenharia de Software Experimental com a finalidade de utiliz-la como base para o experimento
de validao dessa proposta.
Com a inteno de conhecer quais os mecanismos utilizados para realizar a rastreabilidade de artefatos atravs da ontologia, foram estudadas a Engenharia Ontolgica e a rastreabilidade semntica. Com o auxilio desse estudo, presente no captulo 3, foi possvel determinar as influncias que uma mudana na ontologia do sistema exerce sobre os artefatos
relacionados aos conceitos desta.
Surgiu ento, a metodologia que ser apresentada no captulo 4 dessa proposta, estabelecendo os passos necessrios para realiz-la, cuja principal contribuio a de possibilitar maior preciso para realizar a anlise de impacto de um requisito de mudana. Para automatizar essa tarefa, foi desenvolvida uma ferramenta onde, uma vez determinada a influncia
existente entre conceitos, artefatos e tipos de mudana, possvel identificar os elementos
com maior probabilidade de serem impactados. O experimento realizado para validao da
metodologia apresentado no capitulo 5, considerando todos os passos necessrios para seu
desenvolvimento. Por fim, so feitas algumas consideraes e sugeridos alguns trabalhos futuros.

19

REFERENCIAL TERICO

Esse captulo descreve o referencial terico deste trabalho expondo os conhecimentos necessrios para entendimento do problema e para a soluo. Primeiramente preciso
saber o que as ontologias representam e qual sua integrao com o processo de desenvolvimento de software, sendo aqui utilizado o Rational Unified Process (RUP). Tambm necessrio conhecer a fase do ciclo de vida do software caracterizada por projetos de manuteno
deste, com relao rastreabilidade e ao impacto causado por uma requisio de mudana no
sistema. A Engenharia de Software Experimental descrita, j que essa tem como objetivo
validar propostas da rea de engenharia de software atravs de experimentos.

2.1

ONTOLOGIA

Um processo de construo de ontologia, no que diz respeito Cincia da Computao, representa, segundo Gruber[GRU93], a aquisio do conhecimento a partir de dados
semi-estruturados utilizando um conjunto de mtodos, tcnicas ou processos automticos ou
semi-automticos. Esse termo teve origem na computao atravs da rea de Inteligncia Artificial, que considera a representao atravs da ontologia similar a como o conhecimento humano representado. Segundo Fensel[FEN00], ontologias so desenvolvidas para facilitar o
compartilhamento e reuso de informaes.
Essa facilidade para compartilhamento de informaes foi a principal razo para
sua utilizao. Afirma-se ainda que a ontologia mais que um vocabulrio padro e mais do
que uma taxonomia, uma vez que assegura que os termos escolhidos so suficientes para especificar e definir conceitos, bem como o relacionamento entre eles, e que inclui a expresso
exata do domnio especfico do conhecimento.

20
Gruber[GRU93] definiu ontologia como sendo uma representao formal do conhecimento que baseada em uma conceituao. Ele afirma que se pode descrever uma ontologia pela definio de um conjunto representacional de termos. Essa definio compe-se de
associaes entre nomes de entidades do universo de discurso, formado pelo conjunto de objetos que podem ser representados. Esse conjunto pode ser composto por classes, relacionamentos ou funes, descritos atravs de um texto com seus significados, e com axiomas formais, responsveis pela restrio da interpretao e pela boa formao no uso das associaes.
A estrutura de dados de uma ontologia equivalente a um grafo. Cada nodo um
conceito que segundo Geller[GEL04] corresponde a palavras ou frases curtas, sendo tipicamente correspondente a substantivos. Esses conceitos so conectados uns aos outros, sendo o
relacionamento mais importante o do tipo -UM. Alguns nodos possuem outras informaes
relacionadas, podendo ser atributos, relacionamentos ou regras. A figura 1 abaixo exemplifica
uma ontologia em termos de conceitos, relacionamento e regras.
beagle
schanuzer

raa

cachorro

-UM

animal

poodle
Figura 1 Exemplo de ontologia.

Existem duas abordagens para construo de ontologias, no ponto de vista da rea

de Engenharia de Software: uma a construo de ontologias baseadas nos requisitos do sistema e outra a construo de uma ontologia para a representao de requisitos. A primeira
vista como subproduto da atividade de Engenharia de Requisitos. Felicssimo [FEL03] defende esta questo por considerar que durante a especificao dos requisitos do sistema que se
delimita o escopo do projeto bem como se define o domnio da aplicao. Nesta fase, pode-se
construir uma ontologia nica, formada pela unio dos conceitos do problema e da soluo,
que poder ser refinada em seguida.
O papel da ontologia, quando utilizada para a representao de requisitos, de
prover a comunicao entre os requisitos atravs de uma sintaxe e semnticas bem definidas.
Como resultado, tem-se um mecanismo baseado no conhecimento para criao e manuteno
de documentos de especificao de requisitos do sistema. Para obter-se esse mecanismo, utiliza-se lgica de primeira ordem para definir os componentes da ontologia e identificam-se os
axiomas envolvidos com os objetos e a sua interao para responder questes de senso comum.

21
Tendo em vista que a comunicao entre os requisitos determinada durante o
processo de desenvolvimento de software, na prxima seo a integrao de ontologias a este
caracterizada.

2.2

ONTOLOGIA E PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Um processo de desenvolvimento de software pode ser definido, segundo Sommerville[SOM03], como um conjunto de atividades e resultados associados que geram um
produto de software. Utilizando o paradigma de orientao a objetos e os conceitos da Unified
Modeling Language (UML), foi proposta por Jacobson, Booch e Rumbaugh uma metodologia
de desenvolvimento de software unificada, o RUP.
Dentre os objetivos do RUP esto o aumento da produtividade e maior qualidade
do produto de software produzido. Para que tais metas sejam alcanadas, ele deve ser configurado para cada empresa ou projeto que desejem utiliz-lo. Isso possvel uma vez que o RUP
pode ser considerado um framework para processos de desenvolvimento de software.
O RUP dividido em quatro fases distintas, com objetivos especficos: concepo
(definio do escopo), elaborao (definio da arquitetura), construo (desenvolvimento) e
transio (implantao do produto). Tido como um processo incremental e iterativo, cada uma
dessas fases pode suportar uma ou mais iteraes. Cada uma dessas iteraes possui fluxos
especficos de trabalhos definidos pela metodologia, sendo eles: modelagem de negcios, requisitos, anlise e projeto, implementao, testes e implantao, que compem o fluxo de trabalho de engenharia, alm da gerncia de projetos, gerncia de configurao e mudanas e
configurao de ambiente, que fazem parte do fluxo de trabalho de suporte.
A integrao de ontologias no processo de desenvolvimento de software foi estudada e proposta por Noll[NOL05b]. Em seu trabalho, ontologias so relacionadas ao modelo
de domnio, que est inserido na disciplina de modelagem de negcio do RUP. Esse modelo
descreve os conceitos e relacionamentos relativos a uma rea de interesse. nesse aspecto
que ontologias e modelos de domnio assemelham-se. ento proposta a gerao da ontologia
do problema atravs do modelo de domnio. Com a ontologia integrada ao processo de desenvolvimento, tem-se uma maneira de conectar semanticamente diversos recursos, utilizando
tcnicas de inteligncia artificial, segundo Kogut[KOG02].

22
Ao final do processo de desenvolvimento de software obtm-se um produto. Aps
este ter sido implantado, dado incio a uma nova fase do ciclo de vida, que a de manuteno. Tudo aquilo que foi aprendido e produzido durante o processo de desenvolvimento,
extremamente necessrio para que se possa mant-lo. A seguir, sero abordadas as caractersticas de um de projeto de manuteno e conceitos como rastreabilidade e anlise de impacto
que esto relacionados maneira como os artefatos gerados durante o projeto podem ser acessados satisfatoriamente.

2.3

PROJETO DE MANUTENO DE SOFTWARE

A manuteno de software pode ser definida como: A alterao de um produto

de software depois de entregue para corrigir falhas, para melhorar a performance ou outros
atributos, ou adaptar o produto para um ambiente diferente, segundo IEEE[IEE98]. Os projetos de manuteno so classificados em quatro categorias por Pressman[PRE95]: preventiva,
que busca melhorar a confiabilidade ou manutenes futuras; adaptativa, que acompanha as
evolues tecnolgicas; corretiva, que visa corrigir erros no encontrados na fase de teste,
podendo esses ocorrerem na especificao, projeto ou implementao; e evolutivas que visam
continuar satisfazendo as necessidades do usurio.
O padro homologado pela IEEE para manuteno de software determina as fases
que devem ser seguidas para realizar uma alterao no sistema. Aps receber o requisito de
mudana, esse deve ser analisado, ter seu projeto desenvolvido, realizar a implementao,
fazer o teste de regresso do sistema e o teste de aceitao e por fim, a entrega ao cliente. A
existncia de um processo para manuteno de software no significa que essa ser menos
problemtica. Diversos autores, tais como Bohner[BOH96], Ajila[AJI95] e Fay[FAY85], caracterizam a manuteno de software com geralmente sendo cara, difcil e demorada.
Uma das razes para esse tipo de afirmao a dificuldade de entendimento do
negcio e de sua posterior implementao por parte de uma pessoa que no participou do projeto de desenvolvimento. Mesmo profissionais que participaram do projeto tem dificuldade de
recordar alguns detalhes deste ou de sua codificao. Essa situao agravada pela falta de
documentao ou pela sua no atualizao ao longo do processo de desenvolvimento ou
mesmo quando o software j est em manuteno. Uma outra razo est ligada quantidade
de artefatos do sistema que sero afetados por uma mudana.

23
Relacionado a esse ltimo motivo, esto as definies de rastreabilidade e de anlise de impacto de uma mudana dadas por Bohner[BOH96]. O primeiro pode ser definido
como a possibilidade de rastreamento entre os artefatos de software e seus componentes que
so gerados e modificados durante o ciclo de vida do produto. J a anlise de impacto pode
ser definida como a identificao das conseqncias de uma alterao ou estimativa do que
necessrio para realizar uma mudana. Esses aspectos sero apresentados a seguir, considerando as mudanas relativas a manutenes corretivas e evolutivas, j que essas geram requisitos de mudana funcionais, que so aqueles que representam as funcionalidades do sistema.

2.4

RASTREABILIDADE

Outras definies de rastreabilidade de requisitos foram dadas por Pearson[PEA96]: rastreamento de requisitos a habilidade de rastrear os requisitos do usurio
atravs do processo de desenvolvimento, desde o levantamento de requisitos at a entrega do
produto de software. J Gotel e Finkelstein[GOT94] defendem que o rastreamento de requisitos a habilidade de descrever e seguir a vida de um requisito, tanto para frente quanto para
trs, ou seja, desde a sua origem, passando pela especificao e desenvolvimento, at sua entrega e uso; atravs de perodos de refinamento e iteraes em qualquer uma dessas fases.
Atravs dessas definies, pode-se concordar com Palo[PAL03], que diz que uma
das importncias de se ter um mtodo para que um requisito seja rastreado que quando este
necessitar de alterao, encontre-se todos os artefatos ligados ele e que sero afetados pela
mudana. Outra caracterstica importante no rastreamento, que este pode dar toda a informao sobre as justificativas, decises importantes e suposies sobre o requisito.
Foi estudado por Castor[CAS04] fatores que justificam a utilizao do rastreamento de requisitos. Dentre os mais importantes esto:
a) Qualidade de software: uma das definies dada por Brooks[BRO87], que
diz que a qualidade a conformidade dos requisitos. Dessa forma, normas tais
como Capability Maturity Model for Software (CMM) exigem disciplinas de
rastreamento de requisitos. No CMM, esta consta no nvel dois de maturidade;
b) Anlise de impacto: no decorrer do processo de desenvolvimento de software,
muitas vezes ocorrem solicitaes de mudanas de requisitos. Com o uso do
rastreamento de requisitos possvel verificar quais artefatos sero impactados

24
pela mudana, podendo ser analisado se essa vivel ou no, uma vez que o
esforo e tempo para ser realizada podem ser estimados;
c) Manuteno de software: tendo em vista os projetos de manuteno de um
software, o rastreamento dos artefatos torna-se essencial, uma vez que custos e
esforos para efetivar a alterao podem ser determinados com maior preciso.
Sem um mtodo para rastrear os artefatos que sero afetados, so necessrios a
opinio e conhecimento de projetistas ou programadores, que muitas vezes
podem no mais fazer parte da equipe de manuteno do sistema.
Segundo Gotel e Finkelstein[GOT94], apesar do nmero de ferramentas que suportam o rastreamento de requisitos terem aumentado, a teoria necessria para que sejam utilizadas no tem sido amplamente estudadas. Com isso, a maioria dessas ferramentas descobre
e grava a maior quantidade de informao possvel sobre o processo de engenharia de requisitos e faz relacionamentos entre essas informaes para poder recuper-las. O problema, ainda
segundo Gotel e Finkelstein[GOT94], que isso pode levar a uma dificuldade de usar essa
informao, ainda mais se no existir um teste de usabilidade justificado destas, para que os
usurios tenham acesso efetivo e satisfatrio.
Alguns tipos de rastreabilidade foram estudados por Brooks[BRO87]. Um requisito pode ser rastreado pela sua direo e evoluo, entre outros:
a) Direcional: pode ocorrer pra frente (rastreamento para frente a habilidade
de rastrear um requisito para componentes de projeto ou implementao) ou
para trs (rastreamento para trs a habilidade de rastrear um requisito para
sua fonte, isto , para uma pessoa, instituio, lei, argumento). O primeiro tipo
de rastreamento utilizado quando h necessidade de saber o impacto da alterao. J o segundo, usado quando, dada uma alterao, necessita-se compreend-la desde sua origem;
b) Evolutiva: um rastreamento do tipo pr-especificao utilizado quando, ainda na fase de construo da especificao, necessrio localizar as fontes dos
requisitos ou pessoas responsveis por este. Um tipo de rastreamento psespecificao realizado depois de todos os requisitos do sistema terem sido
levantados e usado, por exemplo, para relacionar todos os planos de testes
desenvolvidos para atacar aquele requisito em especfico e ento determinar se
estes tambm precisam ser modificados.
Ao longo dos anos, foram realizadas pesquisas com o intuito de propor modelos
de rastreabilidade de requisitos. Segundo Brooks[BRO87], o rastreamento de requisitos tradi-

25
cional consiste em estabelecer relacionamentos bidirecionais entre requisitos e demais artefatos produzidos num processo de desenvolvimento de software. Podem-se citar como trabalhos
relevantes os propostos por Gotel e Finkelstein[GOT94], Ramesh e Jarke[RAM01] e Toranzo
e Castro[TOR99].
Definindo-se um modelo para rastrear os requisitos ao longo do processo de desenvolvimento de software, e tambm na fase de manuteno do produto, possvel determinar o impacto que uma mudana ter no sistema. Ou seja, possvel determinar previamente
todos os artefatos que sero alterados, qual o esforo para esse trabalho e quanto tempo ser
necessrio. Na seo seguinte ser abordada a disciplina de anlise de impacto, visando a diferenciao entre esta e a rastreabilidade.

2.5

ANLISE DE IMPACTO

A diferena entre rastreabilidade e anlise de impacto de uma mudana bastante

tnue, mas significativa. Como foi descrita anteriormente, a rastreabilidade preocupa-se em
definir a relao existente entre os artefatos do software. A anlise de impacto, por sua vez,
determina quais aes devem ser tomadas para realizar a alterao, podendo estimar quais
sero as conseqncias desta. Apesar da diferena, ambas as abordagens esto intimamente
relacionadas, uma vez que a metodologia utilizada para analisar o impacto baseada na forma
como a rastreabilidade foi construda.
Ajila[AJI95] citou as principais razes para realizar uma anlise de impacto:
a) Estimar o custo de uma mudana. Ou seja, se uma alterao ir afetar vrias
partes disjuntas do software, talvez seja melhor no realiz-la ou reexamin-la;
b) Entender a razo e o relacionamento entre o escopo da alterao e a estrutura
do sistema. Ou seja, atravs do rastreamento dos artefatos que sero afetados,
conhecer quais deles realmente sero modificados e quais tm chances de ser;
c) Gravar o histrico de uma mudana e avaliar se esta foi realizada com qualidade, no comprometendo outras funcionalidades do sistema;
d) Saber em quais partes do software dever ser realizado teste de regresso, de
forma a garantir a qualidade do sistema, principalmente nas sees crticas
deste.

26
A anlise de impacto pode ser vista atravs de dois ngulos, propostos por
ONeal[ONE03]: atravs da abordagem de anlise de dependncia e da anlise de rastreabilidade. A primeira a anlise do relacionamento entre partes do cdigo fonte, visando descobrir quais partes deste sero afetadas pela alterao. Essa abordagem permite que as relaes
sejam estabelecidas ao verificar o cdigo fonte. A segunda preocupa-se em analisar o relacionamento entre artefatos produzidos nas diversas fases do processo de desenvolvimento do
sistema, o que permite uma viso mais ampla do impacto da mudana no sistema como um
todo. Para que seja possvel o uso dessa abordagem necessrio que os artefatos tenham sido
previamente relacionados.
Diversos autores propuseram modelos para determinar a anlise de impacto de
uma mudana, que so apresentados na subseo seguinte.

2.5.1 Modelos de Anlise de Impacto

Bohner[BOH96] relatou diversos modelos de manuteno de software, a maioria

proposto na dcada de 80. Como mais relevantes podem-se citar os de Boehm, que consiste
em trs fases: entender o software, modific-lo e revalid-lo. Parikh enfatiza a identificao
dos objetivos antes de entender o software, depois modificar o cdigo e por ltimo validar a
alterao. O modelo de Osborne focado na gerncia das atividades de manuteno embora
no proponha mtricas para analisar o impacto de uma mudana. Patkow props um modelo
focado na identificao e especificao dos requisitos de mudana. Aps a mudana ser compreendida e localizada, so feitos: o projeto da alterao, implementao e posterior validao
do sistema. A principal caracterstica do modelo a preocupao com a especificao e localizao de onde a mudana deve ser feita. Lewis e Henry afirmaram a necessidade de coletar
mtricas ao longo do desenvolvimento do software para que o produto seja mais manutenvel.
De forma genrica, todos os modelos atuais pesquisados trabalham com o fluxo
mostrado na figura 2. Como entrada, tem-se todos os artefatos do ciclo de vida do software,
ou seja, todos os artefatos produzidos durante o processo de desenvolvimento mais aqueles
que foram includos ou alterados durante o projeto de manuteno. Esses objetos so analisados, de forma a determinar se ser afetado ou no pela alterao requerida. Ao final do fluxo,
tem-se a lista de todos os artefatos que devero ser modificados.

27

Figura 2 Fluxo para determinar anlise de impacto de mudana.

Este trabalho detm-se no processo de analisar quais objetos do ciclo de vida do

software sero impactados por um requisito de mudana e como esses so encontrados, atravs da rastreabilidade. Sero abordados os mtodos considerados mais relevantes para a presente proposta. So eles o de Bohner[BOH02] e o de ONeal[ONE03] que sero expostos a
seguir.

2.5.1.1 Modelos de Bohner

O mtodo de anlise de impacto de uma mudana proposto por Bohner[BOH02]

tem carter iterativo. A figura 3 apresenta o modelo.

Figura 3 Processo de anlise de impacto proposto por Bohner.

O conjunto inicial de impacto (CII) so os primeiros objetos do ciclo de vida do

software (OCV) que se supem sero afetados pela mudana. Esses normalmente so levanta-

28
dos durante a anlise do requisito de mudana. O conjunto candidato ao impacto (CCI) so os
objetos que provavelmente sero afetados pela mudana. Estes so determinados quando a
mudana rastreada entre os artefatos. O conjunto real de impacto (CRI) so os OCVs que
realmente sero alterados. Esse processo considerado iterativo, pois enquanto uma alterao
est sendo executada, podem-se encontrar outros objetos que so impactados que no foram
previstos anteriormente. Esses novos objetos impactados formam o conjunto de impactos descobertos (CID), que representa uma sub-estimativa. Em oposio a este, tem-se o conjunto
falso positivo de impacto (CFPI), representando uma super-estimativa.
De posse dessas variveis, podem-se determinar quais objetos sero alterados, ou
seja, o CRI a soma do CCI, ou os objetos candidatos a alterao, e CID, isto , os artefatos
que foram encontrados posteriormente, menos CFPI, ou seja, os artefatos que inicialmente
pensou-se que seriam afetados. A frmula 1 mostra como realizado esse clculo.
CRI = CCI + CID - CFPI
Frmula 1 Artefatos que sero alterados

O objetivo do processo encontrar o conjunto de objetos CCI, atravs de tcnicas

de rastreabilidade manuais ou automticas, que seja o mais prximo possvel do conjunto de
artefatos realmente modificados, o CRI.
Bohner distingue o impacto em dois tipos: direto e indireto. Isso porque uma mudana pode ter o efeito de uma onda, afetando objetos que no tem uma ligao direta ou bvia com a alterao solicitada. O impacto direto (ou impacto de primeiro nvel) ocorre quando
o objeto afetado relacionado a outro diretamente. Pode ser obtido a partir de um grafo de
conectividade de uma matriz de dependncia.
O impacto indireto (ou impacto em n-nveis) ocorre quando o objeto afetado est
relacionado a um conjunto de dependncias. Esse conjunto determinado pelos n-nveis de
relaes intermedirias entre os diversos artefatos e o objeto afetado. Esses objetos podem ser
obtidos por um grafo de alcance de uma matriz de dependncia.

29

OCV0
OCV9

OCV1

OCV8

OCV2

OCV7

OCV3

OCV6

OCV4
OCV5

Figura 4 Grafo com relacionamento entre objetos do ciclo de vida do software (OCV)

A figura 4 representa um grafo com relacionamento entre os objetos. A partir de

um grafo como esse, pode-se extrair uma matriz de conectividade, representando quais objetos so diretamente afetados por um artefato. Por exemplo, o objeto OCV2 tem impacto direto
dos objetos OCV1, OCV8 e OCV6, que esto representados pelas linhas tracejadas. J os objetos OCV3, OCV4 e OCV7 so dependentes dele, reapresentados pelas linhas pontilhadas. A
tabela I apresenta a matriz de conectividade para o grafo da figura. 4.
Tabela I Matriz de conectividade

OCV 0
OCV 1
OCV 2
OCV 3
OCV 4
OCV 5
OCV 6
OCV 7
OCV 8
OCV 9

OCV0 OCV1 OCV 2 OCV 3 OCV 4 OCV 5 OCV 6 OCV 7 OCV 8 OCV 9
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X

Segundo Bohner[BOH02], pode-se gerar um grafo de alcance a partir de uma matriz de conectividade, como a mostrada na tabela I, usando algoritmos de fechamento transitivo. O problema que, embora um grafo de alcance possa indicar o potencial impacto de um
artefato em outro, esse grafo tende a mostrar que todos os objetos esto conectados, direta ou
indiretamente. Por isso, necessrio outro tipo de informao estrutural, como por exemplo,
qual o nvel de relao entre os objetos. Observando o grafo da figura 4 pode-se perceber que

30
o OCV1 e OCV8 tm nvel trs de relao, ou seja, necessrio passar por outros dois objetos
(OCV4 e OCV7) e trs conectores para se relacionarem. Com essa relao, o autor afirma que
os artefatos que possuem relacionamento direto, potencialmente sero impactados e os artefatos mais distantes provavelmente no sofrero alterao.
O autor faz distino entre duas abordagens, uma baseada na estrutura e outra na
semntica. O que foi descrito at aqui faz parte da abordagem estrutural. Segundo ele, a importncia da abordagem semntica se d com a inteno de aumentar a preciso ao determinar
os objetos afetados. Tendo como base a orientao a objetos e os artefatos produzidos ao longo do processo de desenvolvimento, o autor sugere que sejam analisados os nomes de cada
um desses artefatos e de suas relaes. A tcnica proposta por ele extrai os substantivos (dos
dados dos objetos) e verbos (de funes e mensagens, por exemplo) para que se obtenha a
lista de artefatos candidatos. Um dos pontos fracos desse mtodo que quando os nomes dados aos artefatos so ambguos ou as convenes para esses so fracas, no possvel realizar
o rastreamento atravs da semntica.
Na proposta de Bohner[BOH02], no so apresentados resultados que validem o
mtodo por ele apresentado. Sem a validao, no possvel certificar-se de que realmente
todos os artefatos impactados por uma mudana so encontrados atravs desse mtodo.

2.5.1.2 Metodologia baseada em rastreabilidade

A metodologia proposta por ONeal[ONE03], est inserida no processo de desenvolvimento de software, mais especificamente na disciplina de Engenharia de Requisitos.
Quando existe a solicitao de mudana de um requisito, esse analisado de forma a estabelecer o impacto nos demais objetos do projeto a ele relacionados. A metodologia de anlise de
impacto para requisitos de mudana denominada Trace-based Impact Analysis Methodology
(TIAM), avalia um conjunto de requisitos de mudana. A finalidade prever o efeito que um
conjunto de alteraes ter em requisitos j estveis, onde provavelmente o trabalho j esteja
finalizado. Algumas premissas so assumidas:
a) Requisitos funcionais do produto so rastreveis;
b) possvel fazer a rastreabilidade para frente, ou seja, a partir do requisito
pode-se chegar a outros artefatos, at, por exemplo, ao cdigo fonte;
c) Todos os artefatos esto disponveis e esto atualizados;

31
d) A equipe do projeto ter informado qual a influncia de um artefato sobre outro, bem como a sua complexidade;
e) O processo de desenvolvimento utilizado permita a construo por mdulos,
dando preferncia para um paradigma de orientao a objetos.
O rastreamento entre os objetos representado por um conjunto denominado pelo
autor como Work product Requirements trace Model (WoRM), que composto por outros
dois conjuntos: Work product Information Model (WIM), que contm todos os artefatos produzidos ao longo do projeto e o Requirements change Information Model (RIM), composto
por todos os requisitos de mudana. Os modelos WIM e RIM relacionam-se, de forma que
toda alterao solicitada para um requisito de mudana aponta para o referido requisito. Por
sua vez, o requisito aponta para outro artefato e assim sucessivamente. A figura 5 demonstra
esses relacionamentos:

Figura 5 Modelo de rastreamento entre os artefatos do sistema

Os produtos de trabalho, referidos pelo autor, possuem alguns atributos externos,

que iro auxiliar na determinao do impacto. Os atributos usados para calcular o peso de
cada artefato so: a complexidade, que mede o grau de dificuldade para desenvolver o objeto;

32
qual o esforo para produzi-lo, medido em homens/hora e em qual fase de desenvolvimento
encontra-se o artefato, uma vez que mais difcil alter-lo nas fases finais de desenvolvimento, segundo Schach[SCH99]. Deve-se ainda, estabelecer o grau de influncia que um artefato
exerce sobre outro. Alm da influncia entre os artefatos, preciso determinar a influncia
que a mudana tem sobre o requisito a ela associado. A figura 6 mostra como os produtos de
trabalho se relacionam e qual o grau de influncia entre eles.

Figura 6 Relacionamento entre mudanas, artefatos e grau de influncia entre eles.

O conjunto de graus de influncias de mudanas e de associaes entre artefatos

pode ser configurado conforme o projeto e dados histricos da empresa. No exemplo da figura
6, tem-se que o conjunto de graus de influncia : {weak; average; strong}. A esses graus, so
associados valores, tambm configurveis. De posse desses, calculada a influncia de cada
arco. Esta deve ser normalizada quando dois artefatos se ligam a um outro, na figura 6 Design B e Design C ligam-se a Source J. A figura 7 exemplifica as influncias normalizadas entre os objetos e o peso de cada artefato do sistema.

33

Figura 7 Relacionamento entre artefatos e requisitos de mudana.

De posse dos modelos WIM e RIM, dos pesos dos artefatos e dos valores de influncia entre eles, calculam-se as mtricas de impacto para cada um dos requisitos de mudana, representando a probabilidade de impacto. As mtricas so ento agrupadas em conjuntos conforme a similaridade de impacto, a partir de um grau de similaridade. Por exemplo,
se o ponto de corte de similaridade for de 70%, todos os requisitos de mudana que obtiverem
a mtrica maior ou igual a esse ponto, formaro um conjunto. As demais sero armazenadas
em outro. Em de cada um desses conjuntos, as mtricas so ordenadas de forma decrescente.
A aplicao da metodologia TIAM caracteriza as mudanas baseadas no nvel de impacto de
cada uma delas.
A metodologia de ONeal[ONE03] interessante, pois possui mecanismos para
determinar os artefatos que so potencialmente afetados por uma mudana. Alm disso, seu
uso foi experimentado e validado com alunos de graduao de um curso de engenharia de
software da Universidade de Lousiana, Estados Unidos. O ponto fraco est na rastreabilidade
entre os artefatos, uma vez que estruturalmente realizada e no possui semntica. O autor
tambm no prope um mtodo para calcular a influncia que um artefato exerce sobre outro,
sendo esta atribuda a um especialista, sem parmetros nos quais possa se basear.

34
Na prxima seo, ser abordada a Engenharia de Software Experimental. Tem-se
como objetivo apresentar essa linha de pesquisa, que est inserida na engenharia de software,
visando sua utilizao para, atravs de um experimento, analisar qual o impacto de uma mudana rastreada atravs de conceitos de uma ontologia.

2.6

ENGENHARIA DE SOFTWARE EXPERIMENTAL

A engenharia de software experimental est inserida na discusso sobre classificar

a engenharia de software como cincia ou engenharia. Segundo Travassos, Gurov e Amaral[TRA02], essa questo est ligada ao significado que se d a software, estabelecendo-o
como produto ao considerar seu processo de criao, que possui caractersticas de produo
ou engenharia, ou que pode considerar a necessidade de melhoria contnua da qualidade do
processo e do produto, sendo ento caracterizado como cincia.
Em Basili[BAS96], o autor faz uma comparao da engenharia de software com
outras reas, tais como fsica, medicina e manufaturas. Segundo ele, as duas primeiras, diferentemente do que acontece com o produto final da engenharia de software, no podem ter a
essncia de seus produtos alterados, j na manufatura sim. E, diferente da manufatura, o software desenvolvido e no produzido, ou seja, o mesmo software no ser produzido mais de
uma vez da mesma maneira.
Ainda segundo o autor, existem caractersticas intrnsecas ao software que o diferem de qualquer outra cincia. Uma delas que mesmo aumentando o nvel de abstrao, o
desenvolvimento de software depende de pessoas, com seus aspectos individuais e criatividades nicas. Isso implica que um mesmo experimento realizado com grupos distintos de pessoas poder ter resultados diferentes.
Conforme proposto por Wohlin, Runeson, Host, Ohlsson, Regnell e Wesslen[WOH00], existem diferentes mtodos para experimentos na rea de engenharia de software: cientfico, de engenharia, experimental e analtico. O cientfico pode ser usado para tentar
entender um processo com o intuito, por exemplo, de constru-lo, extraindo do mundo algum
modelo que possa explicar o fenmeno e avali-lo. O mtodo de engenharia tem uma abordagem evolutiva, analisando algum modelo existente e modificando-o para tentar melhor-lo. O
mtodo analtico no precisa de um projeto experimental no sentido estatstico, pois possui
uma base analtica para validar a teoria formal sugerida.

35
O mtodo experimental (de maior importncia para o presente trabalho), segundo
Travassos, Gurov e Amaral[TRA02] inicia-se com o levantamento de um modelo novo, existente ou no, e estuda o efeito do processo ou produto a partir desse modelo, podendo ser analisado quantitativa ou qualitativamente.
Esse tipo de mtodo tem como base as variveis, os objetos, os participantes, o
contexto do experimento, as hipteses e o tipo de projeto do experimento. As variveis podem
ser dependentes, que se referem sada do processo, ou independentes, que se refere entrada
do processo.
O objeto usado para verificar a causa e efeito numa teoria e juntamente com o
sistema de medio, compem a instrumentao do experimento. Os participantes so as pessoas selecionadas para realizar o experimento. necessrio observar que, para um experimento ser considerado generalizado para uma populao alvo, os participantes escolhidos devem
ser representativos. O contexto do experimento refere-se as condies onde este ser aplicado,
ou seja, se ser in-vitro (laboratrio) ou in-vivo (projeto real); alunos ou profissionais; problema de sala de aula (toy example) ou problema real; especifico (contexto particular) ou geral (para toda Engenharia de Software).
Talvez o aspecto mais importante do experimento d-se pela escolha das hipteses, que so dividas entre a hiptese nula (que a principal) e as hipteses alternativas. A hiptese nula nega o relacionamento estatisticamente significante entre a causa e o efeito. Sendo
assim, o objetivo do experimento neg-la a favor de uma hiptese alternativa.
Outros aspectos centrais de um experimento correspondem medio e a validade. Atravs delas, o mapeamento entre o mundo experimental e o mundo formal ou relacional
feito. A validade diz respeito aos resultados do experimento e pode ser classificada em validade de concluso, onde se valida o relacionamento entre o tratamento (teste estatstico, escolha dos participantes, confiabilidade da medida) e o resultado do experimento; validade interna, se o resultado causal e no foi manipulado por influncia de variveis no controladas;
validade de construo, onde so avaliados os aspectos importantes do experimento e o fator
humano, no que diz respeito ao comportamento dos participantes e do experimentador; e a
validade externa, onde limitada a habilidade de generalizar os resultados de um experimento
para prtica industrial.
A seguir, sero apresentadas as fases necessrias para realizao um experimento,
propostas por Travassos, Gurov e Amaral[TRA02]:
a) Definio: o experimento expresso em termos de problemas e objetivos. Os
objetivos so separados em objetivo global, objetivo da medio e objetivo do

36
estudo. sugerido o uso da tcnica GQM (Goal, Question, Metric) para determinar os objetivos;
b) Planejamento: o projeto do experimento determinado, a instrumentao
considerada e os aspectos da validade do experimento so avaliados. preciso
realizar a seleo do contexto, formular as hipteses, selecionar as variveis,
selecionar os participantes, projetar o experimento, fazer a preparao conceitual da instrumentao e fazer a considerao da validade do experimento;
c) Execuo: os dados so coletados. Os participantes devem passar por uma
preparao antes do inicio da execuo. Tambm feita a validao preliminar dos dados;
d) Anlise e interpretao: so realizadas a anlise e interpretao dos dados e
feita concluso sobre a possibilidade de rejeio da hiptese nula. Os passos
que devem ser executados so: validao dos dados, estatstica descritiva, aplicao do teste estatstico, anlise quantitativa e qualitativa e verificao das
hipteses;
e) Apresentao e empacotamento: os resultados obtidos so apresentados e empacotados. O empacotamento importante, pois necessria a repetio do
experimento, para poder avaliar os resultados comparando-se com o experimento original. Atualmente, essa fase do experimento no possui normas internacionais aprovadas.

37

MODELANDO A ANLISE DE IMPACTO DE MUDANA

Para viabilizar a anlise de impacto de um requisito de mudana necessrio,

primeiramente, conhecer o que foi produzido durante o processo de desenvolvimento do software e, principalmente, identificar o tipo de rastreabilidade utilizada. O conhecimento dos
artefatos necessrio tendo em vista que cada um deles ter uma influncia diferente no impacto que ser estabelecido. Uma das premissas bsicas para realizar a anlise de impacto,
ter a possibilidade de rastrear os artefatos, uma vez que esta ir determinar, a partir do requisito de mudana, as implicaes da alterao.
A proposta de uma metodologia de anlise de impacto de mudana, utilizando a
rastreabilidade semntica proporcionada pelo uso de ontologias, foi construda com base no
estudo de outras propostas na rea de anlise de impacto. A metodologia de anlise de impacto baseada em rastreabilidade, desenvolvida por ONeal[ONE03], foi considerada a mais interessante, pois utiliza para relacionar os artefatos a estrutura de um grafo, que tambm utilizado para representar uma ontologia.
O modelo de anlise de impacto proposto nesse trabalho tem como base um processo de desenvolvimento que utilize a Engenharia Ontolgica e construa a rastreabilidade
semntica atravs da ontologia do sistema. Ainda como premissa para determinar o impacto
de um requisito de mudana deve-se estabelecer a influncia de um tipo de mudana na ontologia, a influncia dos relacionamentos entre os conceitos da ontologia, a influncia que um
conceito da ontologia exerce sobre um artefato relacionado a ele e a influncia do tipo do artefato, no que se refere a diagramas da UML. Estas influncias sero detalhadas nesse captulo.
O experimento, descrito no Apndice A, foi aplicado para conhecer de que forma
alteraes nos artefatos do sistema se refletem na ontologia. Assim, foi possvel perceber dois
tipos de influncia na ontologia: a influncia por tipo de mudana, que est relacionada a alteraes diretamente nos conceitos, e a influncia do relacionamento entre os conceitos, que
retrata a propagao de uma mudana. Essas duas influncias sero amplamente abordadas a

38
seguir, demonstrando o clculo do impacto para cada uma e analisando as variveis que se
relacionam a elas. Alm dessas, sero tambm discutidas algumas variveis utilizadas por
ONeal em sua metodologia, estabelecendo sua ligao com a presente proposta.

3.1

ENGENHARIA ONTOLGICA

A proposta de Noll[NOL05b] estende o RUP para que este passe a integrar em suas disciplinas a Engenharia Ontolgica. Esta nova disciplina responsvel por construir a
ontologia e atualiz-la ao longo do processo de desenvolvimento, visando manter a integridade das informaes produzidas durante o projeto.
Baseado em propostas da rea de Engenharia Ontolgica, o autor prope atividades que sero realizadas em cada fase da disciplina, a saber Projeto, Manuteno e Validao
da ontologia. Essas atividades so executadas por um ator que tambm responsvel pelos
artefatos produzidos e por organizar as iteraes. A tabela II mostra como as atividades so
distribudas nas fases.
Tabela II Atividades por fase da Engenharia Ontolgica.
Atividade
Definio do escopo da ontologia.
Projeto
Aquisio e explicao dos conceitos do domnio
Formalizao dos conceitos
Integrao s ontologias existentes (se preciso)
Manuteno
Definio de axiomas
Validao
Validao
Fase

Na fase de Projeto, a ontologia preliminar gerada. Utiliza-se para isso o Modelo

de Domnio, produzido durante a disciplina de Modelagem de Negcio do RUP. Neste modelo, os conceitos relevantes a uma rea de interesse e seus relacionamentos so descritos.
A fase de Manuteno caracterizada pelo refinamento da ontologia, onde se definem estruturas lgicas para esclarecer o modelo e podem-se integrar ontologias previamente
existentes, caso seja identificada essa necessidade. Os conceitos da ontologia so refinados a
medida que artefatos como Especificao de Requisitos, Modelos de Anlise e Modelos de
Projetos so desenvolvidos.

39
A fase de Validao deve ser realizada a cada iterao do ciclo de desenvolvimento com a finalidade de avaliar a integridade, a completude e a corretude da ontologia em relao ao modelo lgico do projeto.
A integrao da Engenharia Ontolgica com o RUP dada pela figura 8 onde
Noll[NOL05b] insere a nova disciplina entre as existentes originalmente. Segundo ele, o incio dessa disciplina ocorre logo aps o comeo da disciplina de Modelagem de Negcio, pois
nela que se estabelece, em nvel conceitual, o universo de discurso. Alm disso, a maior
parte das atividades dessa nova disciplina est concentrada entre as fases de iniciao e de
elaborao uma vez que nesse momento que os conceitos do domnio so definidos.

Figura 8 Integrao da disciplina de Engenharia Ontolgica ao RUP

Para realizar a anlise de impacto baseada na rastreabilidade por ontologias imprescindvel que a Engenharia Ontolgica faa parte do processo de desenvolvimento. Com a
ontologia sendo gerada, mantida e validada ao longo do ciclo de vida do projeto, possvel
estabelecer elos de rastreabilidade entre os conceitos da ontologia e artefatos produzidos no
decorrer do uso do RUP. A seo a seguir descreve como estruturada a rastreabilidade com
o uso de ontologia.

40
3.2

RASTREABILIDADE SEMNTICA ATRAVS DE ONTOLOGIA

Para que seja possvel realizar a rastreabilidade ontolgica, a proposta de

Noll[NOL05b] utiliza a ferramenta ONTrace. Esta permite, atravs de mecanismos prprios,
o rastreamento dos artefatos a partir da ontologia gerada para representar o domnio do problema.
Existem dois conceitos associados aos recursos do ONTrace: model, onde esto
definidos todos os tipos previstos na UML; e artifact, que um dos elementos produzidos no
processo de desenvolvimento de software. Esse ltimo possui duas propriedades associadas:
ontraceRecover, onde so relacionados todos os conceitos da ontologia aos quais o artefato
est relacionado e ontraceArtifactsTypedBy, que representa o tipo do artefato, definido pelo
conceito model. Na figura 9 est a representao da rastreabilidade semntica, considerando
os diversos tipos de artefatos produzidos ao longo do processo de desenvolvimento do software.

Figura 9 Representao da rastreabilidade semntica atravs de ontologia

Atravs da ferramenta desenvolvida por Noll[NOL05b] possvel associar os

conceitos da ontologia gerada aos elementos do modelo. Concludo esse processo de associa-

41
o entre conceitos e artefatos, pode-se buscar o conjunto de elementos que esto relacionados a um mesmo conceito, possibilitando o conhecimento de todos os artefatos que sero impactados por uma alterao.
Utilizando o exemplo dado pelo autor, o caso de uso Registrar compra, pode estar associado a conceitos como cliente, compra, produto. Outro caso de uso, Cadastrar
cliente, relaciona-se com o conceito cliente. Tem-se ento um relacionamento entre os
casos de uso indexados pelo conceito cliente.
O rastreamento de artefatos pode ocorrer em outros nveis, alm do relacionamento direto apresentado no exemplo anterior. Se conceitos da ontologia possurem, por exemplo,
relacionamentos no taxonmicos, os artefatos associados a esses conceitos podem se relacionar. Supondo que o caso de uso Cadastrar funcionrio esteja associado ao conceito funcionrio, e o caso de uso Cadastrar cliente esteja associado ao conceito cliente, se os conceitos funcionrio e cliente estiverem relacionados por uma propriedade, talvez um caso
de uso seja afetado por uma mudana no outro.
Nas sees seguintes, sero estabelecidas as influncias que elementos da ontologia possuem, dependendo do tipo de mudana, relacionamento e artefatos associados.

3.3

INFLUNCIA DA COMPLEXIDADE DE ARTEFATO

Na metodologia TIAM de anlise de impacto, a complexidade uma das variveis

utilizadas para determinar o peso de um artefato. Um dos objetivos de mensur-la associar
ao clculo da probabilidade de impacto a dificuldade de manter o artefato, em termos, por
exemplo, de estimativas de tempo, custo e esforo para realizar o requisito de mudana.
As sees seguintes expem como a complexidade de artefatos pode ser estabelecida e so citadas outras formas de determin-la, alm dos modelos de custos propostos por
Boehm[BOE01], cujo uso sugerido por ONeal. A inteno demonstrar como essa varivel
empregada em cada uma das propostas, na metodologia TIAM e na anlise de impacto baseada em ontologias, e distinguir o seu uso em cada uma delas.

42
3.3.1 Complexidade de Artefato

A complexidade de artefatos definida ou estimada pelo uso de mtricas. Existem

diversas propostas de mtricas na bibliografia e o uso de cada uma delas est ligado a qual foi
o processo de desenvolvimento usado no projeto, o paradigma de programao e a arquitetura
do software utilizada, dentre outros fatores. Alm disso, h a diferenciao entre mtricas de
processo e de produto.
No contexto dessa pesquisa interessante verificar quais so as mtricas utilizadas
para produto de software, estabelecendo prioritariamente mtricas para o paradigma de orientao a objetos relacionados a diagramas da UML. Ao final dessa subseo, ser analisado o
uso da complexidade de artefatos na proposta de anlise de impacto baseada em ontologias.

3.3.1.1 Mtricas de produto de software

Nesses mais de trinta anos de pesquisa na rea de mtricas, a importncia do desenvolvimento de projetos de software teve um crescimento bastante acentuado. O aumento
dessa importncia faz com que haja mais requisitos intrnsecos ao projeto. Desta forma, necessrio que exista um controle mais preciso tanto no processo de desenvolvimento quanto no
produto a ser entregue. Isso se faz necessrio, pois a maioria dos projetos atrasa, estouram o
oramento ou no possuem a qualidade desejada pelo cliente. Uma forma de evitar ou reduzir
esse tipo de problema conseguir estimar corretamente as variveis envolvidas, tais como
custo, esforo e prazo necessrios para o desenvolvimento do projeto.
O processo de medio de software traz benefcios como modelar e entender o
processo de desenvolvimento e o produto gerado, ajudar na gerncia do projeto de software e
melhor-lo. Dentro desta realidade, a rea de mtricas de software, que a medida quantitativa de atributos especficos do desenvolvimento de software, tem sugerido meios capazes de
atingir os objetivos desejados.
Scotto [SCO04] classificou os tipos de mtricas em mtricas de processo, de produto e de recursos. O foco das mtricas de produto est nas caractersticas do software em
relao qualidade de entrega. Segundo Sommerville [SOM03], medidas como tamanho e
complexidade ciclomtica no so facilmente relacionadas com atributos de qualidade, tais

43
como a facilidade de compreenso e manuteno, isto porque esto intimamente relacionadas
com o processo de desenvolvimento e com a tecnologia aplicada. Uma forma de relacionar
tais medidas e atributos realidade do projeto que est sendo desenvolvido coletar essas
mtricas e comparar os dados histricos dentro, por exemplo, de uma fbrica de software,
procurando uma relao entre elas.
Sommerville [SOM03] props a classificao das mtricas de produto em dinmicas e estticas. A primeira relacionada diretamente qualidade e so coletadas por medies
realizadas por um programa em execuo. Esse tipo de mtrica pretende avaliar a eficincia e
a confiabilidade de um programa. J as mtricas estticas so medidas por representaes do
sistema, ou seja, pelo projeto, programa ou documentao, tendo uma relao indireta com
atributos de qualidade. Essas mtricas ajudam a medir atributos como a complexidade, a facilidade de compreenso e manuteno do software.
Outra proposta de classificao de mtricas de produto foi dada por Mills
[MIL99], que as separou em mtricas de produto por tamanho, complexidade e qualidade. A
medida por tamanho est diretamente relacionada ao produto e processo por meio do qual este
foi desenvolvido; a medida por complexidade tem relao com o gerenciamento do processo
de desenvolvimento; e a medida por qualidade que mensura caractersticas como a corretividade, confiabilidade e manutenibilidade, sendo essas as mais estudadas dentro de um tpico
onde no existe consenso em uma nica mtrica para todos os itens de qualidade.
Alm das classificaes apresentadas, pode-se ainda classificar as mtricas de
produto em mtricas orientadas a objetos. Pesquisas nesse sentido iniciaram na dcada de 90,
sendo que algumas foram derivadas das mtricas mais antigas, baseadas em programao estruturada, embora outras sejam exclusivas do paradigma de orientao a objetos. Dentro dessas pesquisas, os mtodos propostos por Lorenz em 1993 e por Chidamber e Kemerer em
1994, so bastante referenciados. A primeira proposta composta de um conjunto de onze
mtricas orientadas a objetos (OO). A segunda, tambm conhecida como mtricas CK, possui
um conjunto de seis mtricas, voltadas para o projeto e complexidade. Essa proposta, dentre
outras, serviu como base para as atuais mtricas orientadas a objetos que utilizam diagramas
da UML, segundo Kim[KIM02]. As mtricas para esses diagramas sero apresentadas na seo seguinte.

44
3.3.1.2 Mtricas para UML

Desde a sua criao, a UML vem sendo largamente utilizada no processo de desenvolvimento de softwares orientados a objetos. Segundo Kim[KIM02], uma vez que o nmero de artefatos produzidos utilizando a UML aumentou, existe a necessidade de mensurar
as caractersticas desses objetos. Com isso, possvel obter uma noo exata, por exemplo, da
complexidade do projeto j nas primeiras fases deste, que o momento onde se comea a criao dos modelos UML. Uma das vantagens apontadas por McQuillan[MQU06], de que,
com o uso dessas mtricas, a qualidade do software pode ser estimada ainda nas fases iniciais
do ciclo de vida, onde o custo de se fazer uma mudana ainda no alto.
Durante a pesquisa de trabalhos nesta rea, no foi encontrado um modelo nico
de mtricas para artefatos da UML. Cada proposta utiliza as mtricas dentro do seu prprio
modelo, com o objetivo de propor resultados mais precisos. Outra caracterstica, segundo Genero[GEN03], que a maioria das propostas trabalha com os diagramas estruturais, principalmente com o diagrama de classes. Tendo em vista essa realidade, ser apresentada a seguir
uma mtrica de complexidade para esse diagrama.

3.3.1.2.1 Complexidade do Diagrama de Classes

Dentro do estudo de mtricas orientadas a objetos, a complexidade dos diagramas

estruturais so os que possuem mais pesquisa, segundo Genero[GEN03]. Trabalhos propostos
por Chidamberer e Kemerer [CHI94], as mtricas CK, por Lorenz [LOR94], por Marchesi
[MAR98] e por Fenton [FET00], dentre outros, esto relacionados a esse diagrama.
A proposta de Carbone [CAR02], denominada Fast&&Serious, prope mtricas
para determinar a complexidade do diagrama de classes, ou somente de uma classe, j que
considera esse artefato o mais importante da modelagem orientada a objetos. O mtodo
composto por seis passos, sendo alguns opcionais, como mostra a tabela III.

45

Tabela III Passos do mtodo Fast&&Serious

Passo
1
2
3*
4*
5*
6

Descrio
Determinar o tipo do mtodo, se i ou Serious.
Calcular a complexidade de cada classe (CP) pertencente ao diagrama de classes que est sendo analisado.
Avaliar o CPs para o diagrama de casos de uso.
Avaliar o CPs para os diagramas de seqncia e de colaborao.
Avaliar o CPs para o diagrama de estados.
Somar os CPs encontrados nos passos 2, 3, 4 e 5, obtendo o nmero de SLOC de todo o sistema.

Os passos que esto sinalizados na tabela III com (*) no so obrigatrios. O primeiro passo determina qual mtodo ser utilizado, atravs da mdia da mtrica do percentual
de mtodos com assinatura (PMS). Se o PMS for maior do que 70% usado o mtodo Fast,
seno usado o mtodo Serious. A seguir, ser apresentado apenas o mtodo Fast, descrevendo o segundo passo da tabela III, pois a finalidade conhecer como se determina a complexidade das classes de um diagrama de classes.
Os atributos de cada classe so classificados em trs categorias, conforme a tabela
IV. Aps, calculado o nmero de Pontos por Estado (SP), que dado pela frmula 2, onde
ListAtrib classificado pelo par {atributo; tipo} e numAtrib o nmero de atributos da classe.

Tabela IV Passos dos atributos no mtodo Fast&&Serious

Complexidade
Leve
Pesado
Importado

Definio
Atributos simples, como inteiro, string, etc.
Atributos complexos desenvolvidos e testados, como atributos em pacotes pr-definidos.
Atributos complexos de uma classe no desenvolvida e no testada.

Peso
1
3
5

numAtrib( c )

SP( c )

Peso( ListAtrib)
i 1

Frmula 2 Clculo do nmero de Pontos por Estado

Aps o clculo de SP, os mtodos so classificados em Triviais, que so mtodos

que possuem ao menos 80% de atributos do tipo leve e no tem atributos do tipo importado na
sua assinatura, ou em Substanciais, que so os mtodos que no foram classificados como
triviais. No mtodo Fast, que o nico que est sendo abordado nesse trabalho, todos os mtodos so classificados como substanciais com um atributo do tipo importado. Caso o mtodo
Serious fosse aplicado, cada mtodo da classe deveria ser classificado conforme os critrios
apresentados. A complexidade do mtodo dada pela frmula 3, onde numLA, numHA e nu-

46
mIA so os nmeros de atributos leves, pesados ou importados na assinatura do mtodo, respectivamente. A varivel T significa que o mtodo trivial (T=1; S=0) e S, que substancial
(T=0; S=1).
CM ( m )

TS

1 2 3
1 3 5

numLA
numHA
numIA

Frmula 3 Clculo da Complexidade do Mtodo

Em seguida, o Ponto por Comportamento (BP) calculado para a classe, conforme a frmula 4, onde numAss o nmero de associaes da classe e numMet o nmero de
mtodos da classe.
numMet ( c )

BP( c )

1 numAss( c )

CM ( mi )
i 1

Frmula 4 Clculo dos Pontos por Comportamento

Por fim, calculado, para cada classe, o Ponto por Classe (CP), que a estimativa
da complexidade desta, apresentada na frmula 5.

CP(c )

2 SP(c )

3 BP(c )

Frmula 5 Clculo dos Pontos por Classe

Com esta estimativa possvel prever quando uma classe mais complexa do que
outra, caracterizando, possivelmente, uma maior dificuldade de manuteno das classes mais
complexas. Um exemplo de aplicao desse mtodo ser dado na seo seguinte.

3.3.2 Uso da Complexidade de Artefato

Para utilizar a metodologia TIAM, o peso do artefato uma das informaes utilizadas para conhecer a mtrica de impacto do requisito de mudana. Essa mtrica possibilita
que sejam determinadas outras estimativas com a finalidade de prever o que necessrio para
efetuar cada alterao solicitada.
O peso do artefato ento dado pela frmula 6, que alm da complexidade do artefato (c(n)), relaciona o esforo (e(n)), que mensura o tempo necessrio para produzir o artefa-

47
to, e a fase (p(n)) na qual este est inserido, considerando que quanto mais adiantada for a fase,
maior o esforo para alterao.

w( n )

c( n ) e( n )

p( n )

Frmula 6 Clculo do peso do artefato

Os nveis e valores relacionados s variveis de complexidade, fase e esforo so

determinados pelos desenvolvedores durante o processo de desenvolvimento. A varivel e(n)
determinada pelo esforo em horas necessrias para desenvolver um artefato e mensurada
em homem-hora. A complexidade e a fase devem ser classificadas em diferentes nveis. Para
determinar a varivel c(n), pode ser estabelecido o conjunto de nveis de complexidade {alta;
mdia; baixa} com valores correspondentes a {1;0,6;0,3}. A varivel p(n) pode ser representada por {Requisitos; Anlise; Projeto; Implementao; Teste} e ter valores associados como
{1;2;3;4;5}, respectivamente. A figura 10 apresenta o diagrama de classes, que servir de
exemplo para o clculo do peso de um artefato.

Figura 10 Exemplo de diagrama de classes.

Usando os conjuntos de complexidade e fases acima propostos, pode-se determinar que o peso do artefato Autor de w(n)=0,45, considerando que o artefato tem complexidade baixa (c(a)=0,3), que o esforo de desenvolvimento de 30 min (e(a)=0,5) e que est
presente na fase de projeto (p(a)=3). Para o artefato Livro, o peso correspondente de
w(n)=0,9, pois o seu tempo de desenvolvimento, incluindo implementao do mtodo, de
2h (e(l)=2), com complexidade baixa (c(l)=0,3) e tambm pertencente fase de projeto
(p(l)=3). Posteriormente, esses valores sero usados juntamente com a influncia da relao
entre os artefatos para determinar a mtrica de impacto.
No mbito da presente pesquisa, interessa descobrir quais artefatos sero afetados
usando a probabilidade de impacto em cada um deles. Nesta realidade, a varivel fase no
utilizada, uma vez que esta se refere as fases do processo de desenvolvimento e no a um projeto de manuteno. As variveis de complexidade e esforo de cada artefato no determinam
uma maior ou menor probabilidade de impacto, como o objetivo, j que elas esto relacionadas dificuldade de mant-lo.

48
Utilizando o mesmo diagrama de classes da figura 10, com o uso do mtodo
Fast&&Serious [CAR02], pode-se determinar a complexidade das classes. A figura 11 mostra
a aplicao do mtodo para calcular a complexidade destas. Tem-se ento que a complexidade
da classe Autor de CP(a)=13 e da classe Livro de CP(l)=17, sendo esta ltima mais
complexa do que a primeira.

Classe
Autor
Livro

Ponto por Estado (SP)

numLA
numHA numIA
0
0
5
0
0
4

Classe
Livro

numAss

SP

Complexidade do Mtodo (CM)

Mtodo Triv/Sub numIA
Relatrio
Sub
1

Classe
Autor
Livro

Pontos por Classe (CP)

SP
BP
1
5
3
4

CM
3

CP
13
17

Figura 11 Aplicao do mtodo Fast&&Serious.

Um exemplo de um requisito de mudana para o domnio desse problema poderia

ser o apresentado na figura 12. O resultado dessa alterao no diagrama de classes do projeto
possivelmente seria o representado na figura 13. Percebe-se ento que, embora a classe Livro seja efetivamente mais complexa que a classe Autor, esse no foi um fator determinante para considerar o impacto do requisito de mudana.

Requisito de Mudana A:Deseja-se conhecer o grau de formao de cada autor. Tendo ele
nvel superior, informar qual a instituio de ensino onde obteve o grau.
Figura 12 Requisito de mudana A, no domnio de livros.

Figura 13 Exemplo de diagrama de classes aps alterao do requisito de mudana A.

49
3.4

INFLUNCIA DO CONCEITO DA ONTOLOGIA NOS ARTEFATOS

A metodologia TIAM utiliza fatores de influncia nos elos que inter-relacionam o

requisito de mudana e os diversos artefatos produzidos durante o projeto. Quem classifica a
influncia o desenvolvedor, durante o processo de desenvolvimento. Os nveis de influncia
e seus respectivos valores podem ser escolhidos conforme a caracterstica de cada projeto e
pelo histrico de projetos da empresa. Uma vez escolhidos os nveis e valores atribudos aos
arcos entre os artefatos, o grau de influncia deve ser normalizado, a fim de que, se vrios
artefatos estiverem relacionados a um nico outro, a soma das influncias de cada elo seja
igual a 1, ou 100%. A figura 14 apresenta um exemplo do uso dessas influncias.

mdio
fraco
Mudana

mdio
Requisito

Artefato de
Implementao
1

Artefato do
Projeto
forte

Artefato de
Implementao
2

Figura 14 Nveis de influncia entre artefatos na metodologia TIAM.

O conjunto de nveis de influncia da figura 14 composto por {fraco; mdio;

forte}. Os valores associados a eles, sugeridos pelo autor, so {0,3; 0,6; 1}. Esses valores devem ser usados na frmula 7, onde i({a,b}) a influncia entre dois artefatos, i({a,b}) o
resultado da normalizao e T o conjunto de elos entre os artefatos. Na figura 15, mostrado
o resultado da influncia normalizada de cada relacionamento.

i' ({a, b})

i({a, b})
i({c, b})
T

Frmula 7 Normalizao dos elos na metodologia TIAM

50

1
Mudana

1
Requisito

0,375
dio

Artefato de
Implementao
1

Artefato do
Projeto
0,625

Artefato de
Implementao
2

Figura 15 - Valores de influncia normalizados entre artefatos na metodologia TIAM.

A metodologia TIAM proposta por ONeal serve como base para a proposta da
anlise de impacto atravs da rastreabilidade por ontologias. Isso porque, considerando que
uma ontologia tem representao equivalente a um grafo e que a rastreabilidade semntica
nela relaciona conceitos a artefatos, pode-se assumir que existe uma influncia especfica do
arco que liga o conceito ao artefato. A figura 16 representa graficamente essa relao, usando
como exemplo os artefatos do grafo de relacionamento da figura 15.

Artefato de
Implementao
2

Requisito

Artefato do
Projeto
Artefato de
Implementao
1

Figura 16 - Relacionamento entre conceitos da ontologia e artefatos de software.

O grau de influncia de cada relacionamento depende do tipo de artefato ao qual o

conceito est ligado. Embora o conjunto de nveis de influncia e seus valores possam ser
determinados por um desenvolvedor do projeto, baseado no histrico de dados deste, a metodologia aqui proposta sugere um conjunto inicial de nveis e de valores, obtidos de forma emprica. Estes so compostos por duas escalas {fraco, forte}, cujos valores associados so respectivamente {0,3; 1}.

51
Cada um dos conceitos, que estiver relacionado a um artefato, deve ter a varivel
Influncia do conceito no artefato (Ic) informada, dentro da escala sugerida. A tabela V apresenta um guideline para ajudar nessa classificao, que baseado em caractersticas do tipo
do artefato.
Os diagramas da UML presentes na tabela V e que so referenciados nesse trabalho foram escolhidos, pois so suportados pela ferramenta ArgoUML, na qual o aplicativo
ONTrace foi desenvolvido como um plug-in. Atualmente, s os objetos do ciclo de vida do
software que foram modelados nesse sistema tm a possibilidade de serem rastreados.
Trs dos diagramas que podem ser modelados e rastreados pela ferramenta de
modelagem citada e que no esto presentes no guideline proposto so: o Diagrama de Casos
de Uso, o Diagrama de Classes e o Diagrama de Implantao. O primeiro diagrama no consta na classificao da influncia do conceito no artefato, pois se preferiu trabalhar somente
com a descrio do caso de uso ao invs do relacionamento entre eles, uma vez que no detalhamento deste que se encontram as informaes comportamentais do sistema. De forma anloga, foram consideradas apenas as classes , pois assim possvel ter conhecimento exato de
quais delas sero impactadas por um requisito de mudana, considerando que o Diagrama de
Classes muito abrangente, pois vrios conceitos poder ser relacionados a ele. J o ltimo
diagrama relatado no est abordado no guideline por dar a viso organizacional do hardware
do sistema, que est fora do escopo dessa pesquisa.

Tabela V Guideline para classificao da Influncia do conceito no artefato (Ic)

Tipo do Artefato
Descrio de Caso de Uso (UC)

Classe (C)
Diagrama de Seqncia (DS)
Diagrama de Estados (DE)
Diagrama de Atividades (DA)
Diagrama de Colaborao (DC)

Influncia do conceito no artefato (Ic)

Fraco
Forte
O conceito referenciado na pr ou psO conceito referenciado no
condies e/ou fluxos alternativo e de
fluxo principal
exceo
Classe associativa quando uma das
Possui o mesmo nome do conclasses ligadas a ela tem o mesmo nome
ceito
do conceito
Est presente nas mensagens entre os
O conceito um objeto
objetos
O conceito est presente nos estados dos
O conceito est presente nos
fluxos alternativos e de excees
estados do fluxo bsico
O conceito est presente nas atividades
O conceito est presente nas
dos fluxos alternativos e de excees
atividades do fluxo bsico
Est presente nas mensagens entre os
O conceito um objeto
objetos

Os critrios de influncia dos artefatos utilizados para construo do guideline foram determinados segundo estudo de cada um dos diagramas da UML. Por exemplo, quando

52
se descreve um Caso de Uso (UC), o fluxo principal deste obrigatrio, sendo opcionais o
fluxo alternativo e pr ou ps-condies. Assim, infere-se que quando o conceito estiver presente no fluxo principal, a Influncia do concenito no artefato (Ic) forte, caso esteja apenas
no fluxo alternativo ou na pr ou ps-condies fraco. Futuramente, este guideline pode ser
revisto atravs de experimentos, podendo, inclusive, abranger todos os diagramas da UML.
Considerando o conceito Autor associado classe Autor da figura 17, a influncia que o primeiro exerce sobre o seguindo de Ic = Forte, utilizando o critrio presente na
tabela V. J o diagrama de atividades relacionado ao mesmo conceito possui Ic = Fraco.

Ic = forte
Autor
Usurio

Ic = fraco

Selecionar opo de
cadastrar autor

Informar dados
do autor

Sistema

Apresenta
formulrio

Validar dados
do autor
[ dados invlidos ]
[ dados vlidos ]
Cadastrar
autor

Figura 17 - Influncia do conceito no artefato (Ic) do conceito Autor.

A influncia do conceito no artefato no deve ser normalizada quando dois conceitos diferentes estiverem relacionados ao mesmo artefato. Isso no necessrio, pois a influncia mxima para cada par conceito-artefato individualmente e no se considerado o
conjunto de todos os conceitos que se ligam ao mesmo artefato.

3.5

INFLUNCIA DO TIPO DE DIAGRAMA NA ANLISE DE IMPACTO

Diagramas da UML podem ser classificados em modelos estticos, dinmicos e

funcionais. Os modelos estticos mostram a estrutura do sistema e as suas funcionalidades. Os
modelos dinmicos mostram as interaes que o sistema suporta. Esses detalham a interao
entre os diagramas estruturais, fornecendo uma representao mais clara do comportamento
do sistema. Os modelos funcionais mostram a organizao em seu sistema dos componentes
executveis. Esses distinguem a localizao fsica de execuo entre os componentes e os ns
de armazenamento com os que eles podem interagir. Eles so produzidos no incio da fase de

53
desenvolvimento do sistema e so atualizados durante o projeto para indicar a arquitetura fsica pretendida.
importante diferenciar o tipo de diagrama, pois, dependendo do tipo de mudana, os artefatos so influenciados de forma diferente, com relao sua classificao. Quando
h alterao de regras de negcio, os diagramas dinmicos so os mais afetados. Quando a
mudana referente estrutura dos artefatos, os diagramas estticos tm maior probabilidade
de impacto. No experimento que foi realizado e que serviu para identificao das hipteses,
no foi possvel detectar a influncia nos diagramas funcionais, pois esses no fizeram parte
do estudo. Sendo assim, a influncia referente a esse tipo de diagrama ser determinada como
irrelevante, para qualquer tipo de mudana, sendo proposto seu estudo como trabalho futuro.
A Influncia do tipo de diagrama (Id) dada pelo conjunto das classificaes dos
diagramas UML {esttico; dinmico; funcional}. O peso para cada um desses elementos
dado conforme o tipo de mudana e ser determinado na seo seguinte. Para cada artefato
associado a um conceito, deve-se classificar o tipo de diagrama a que pertence, conforme a
tabela VI.

Tabela VI Classificao do tipo de diagrama

Tipo do Artefato
Diagrama de Caso de Uso (DUC)
Descrio de Caso de Uso (UC)
Diagrama de Classes (DC)
Classe (C)
Diagrama de Seqncia (DS)
Diagrama de Estados (DE)
Diagrama de Atividades (DA)
Diagrama de Colaborao (DCo)
Diagrama de Implantao (DI)

3.6

Influncia do tipo de diagrama (Id)

Esttico
Dinmico
Funcional
X
X
X
X
X
X
X
X
X

INFLUNCIA DO TIPO DE MUDANA NA ANLISE DE IMPACTO

Um requisito de mudana pode afetar de diferentes formas o produto ao qual relacionado durante o projeto de manuteno deste. Considerando-se que durante o processo de
desenvolvimento foi includa a disciplina de Engenharia Ontolgica, as alteraes requisitadas
podem ser identificadas na ontologia. Atravs do experimento, detalhado no Apndice A, percebeu-se ser de grande influncia as mudanas de regra de negcio, que esto relacionadas ao

54
significado dos conceitos da ontologia, e as mudanas no relacionamento dos conceitos, que
engloba a incluso ou alterao destes, alterando estruturalmente a ontologia.
A varivel Influncia da mudana (Im) deve ser determinada para, juntamente
com a Influncia do conceito no artefato (Ic) e a Influncia do tipo de diagrama (Id), medir o
Impacto no artefato pela mudana (Iam(x,y)), que calculado atravs da frmula 8, onde x o
conceito do tipo class e y o artefato.
Iam(x,y) = Im x Ic x Id
Frmula 8 Clculo do Impacto no artefato pela mudana (Iam(x,y))

A varivel Influncia da mudana (Im) formada pelo conjunto {baixa;alta}, com

valores correspondentes a {0,1;0,9}, respectivamente. Os tipos de mudana detalhados a seguir possuem Im = alta. Ter Im = baixa qualquer outro tipo de mudana no citada. Uma
vez que a influncia do tipo de diagrama depende do tipo de mudana ocorrida, os valores dos
elementos do conjunto {esttico; dinmico; funcional} sero determinados em cada uma delas.

3.6.1 Tipo de Mudana de Regras de Negcio

Quando uma regra de negcio j existente alterada ou quando uma nova regra
associada a um conceito, o significado deste pode ser alterado. Isso significa que poder haver
mais restries nas propriedades da ontologia ou que o domnio do conceito poder ser alterado, por exemplo.
No cdigo Web Ontology Language (OWL) presente na figura 18, tem-se a restrio allValuesFrom, que restringe os valores da propriedade da classe a que est associada. Ou
seja, todos os membros da classe que possurem a propriedade devem pertencer ao tipo de
recurso indicado na clusula. No exemplo significa que toda instncia da classe Casal, se
tiver filhos, estes devem pertencer a classe filhoNatural. Um requisito de mudana poderia
alterar a obrigatoriedade de que os filhos do casal pertenam a classe de filhoNatural, podendo ser filhosAdotivos.

55

<owl:Class rdf:ID="Casal">
<owl:Restriction>
<owl:onProperty rdf:resource="#temFilhos"/>
<owl:allValuesFrom rdf:resource="&filhoNatural"/>
</owl:Restriction>
</owl:Class>
Figura 18 Exemplo em OWL da restrio allValuesFrom

A influncia dada por uma mudana de regra de negcio afeta diretamente os artefatos do tipo dinmico, uma vez que esses detalham o comportamento do sistema. Sendo assim, os valores referentes para o conjunto Id = {esttico; dinmico; funcional} so, respectivamente, {0,5; 1; 0,1}.

3.6.2 Tipo de Mudana Estrutural

Quando conceitos so includos ou alterados numa ontologia, o relacionamento

entre eles pode ser afetado. Numa incluso, provavelmente um novo elo de ligao entre conceitos ser necessrio. Numa alterao, a prpria ligao entre eles pode ser modificada. Nessas situaes se est alterando estruturalmente o relacionamento entre os conceitos. Assim, o
modelo de artefatos que sofre mais influncia desse tipo de mudana so os diagramas estticos, pois esses representam a estrutura do sistema. Desta forma, o conjunto dos valores referentes para o conjunto Id = {esttico; dinmico; funcional} so, respectivamente, {1; 0,5;
0,1}. As possibilidades de alterao na ontologia sero descritas abaixo.

3.6.2.1 Alterao de um conceito da ontologia.

Quando um conceito alterado, est se modificando a propriedade do tipo range

de um conceito do tipo dataTypeProperty. Essa mudana tem grande influncia sobre artefatos relacionados diretamente a esse conceito. A figura 19 mostra uma sub ontologia para o
domnio de livros, destacando o relacionamento do conceito ISBN com o seu tipo de dado.

56

class
type

Livro

domain

domain

ttulo

ISBN
domain

range

int

domain

ano

editora

type

type

type

type

dataTypeProperty

Property
Figura 19 Sub ontologia equivalente ao domnio de livros.

Na solicitao de mudana presente na figura 20, o range do conceito ISBN deve passar a ser String, como mostra a figura 21, referente ontologia de mudana. Nesse
contexto, so considerados os artefatos que esto ligados diretamente ao conceito do tipo dataTypeProperty, no exemplo, os artefatos ligados ao conceito ISBN.
Requisito de Mudana B: Atravs de um decreto do Ministrio da Cultura, os livros editados no Brasil passaro a receber a sigla do pas (BR) na identificao ISBN.
Figura 20 Requisito de mudana B no domnio de livros.
class
type

Livro

domain

domain

ttulo

ISBN
domain

ano

range

String

domain

editora

type

type

type

type

dataTypeProperty

Property
Figura 21 Sub ontologia equivalente ao requisito de mudana no domnio de livros.

57
3.6.2.2 Incluso de um conceito na ontologia

A incluso de um conceito pode ser de dois tipos: a associao de um novo conceito do tipo dataTypeProperty a um j existente do tipo class, e a incluso de um conceito do
tipo class, com seus dataTypeProperty associados e objectProperty relacionados. A seguir,
cada uma dessas incluses ser detalhada.

3.6.2.2.1 Incluso de conceito do tipo dataTypeProperty

A incluso de um conceito do tipo dataTypeProperty ir acrescentar uma nova

propriedade ao conceito do tipo class ao qual se relacionar. Essa situao pode ser verificada
analisando o exemplo da figura 22 que a representao de parte do modelo de domnio de
livros, apresentado anteriormente na figura 10. A ontologia equivalente a esse modelo mostrada na figura 23.

Figura 22 Parte de um modelo de domnio de livros.

58

class
object
Property

type

type

type
range

Livro

Autor

domain

nome

onProperty

ehEscrito

domain

domain

domain

domain

ttulo

nascimento

codinome

domain

type

ISBN

domain

ano

editora

type
type

type
type
type

dataType
Property

type

Figura 23 Ontologia equivalente a parte de um modelo de domnio de livros.

Considerando o requisito de mudana da figura 12, a ontologia equivalente mudana mostrada da figura 24. Nota-se que um novo conceito formao do tipo dataTypeProperty foi associado ao conceito Autor, que do tipo class.
class
object
Property

type

type

type
range
domain

onProperty

ehEscrito

Livro

Autor

domain

domain
domain

nome
domain

formao

domain

ttulo

nascimento

domain

type

codinome

ano

editora

type
type

type

type
type

ISBN

domain

type

dataType
Property

type

Figura 24 Ontologia equivalente ao requisito de mudana A no domnio de livros.

A influncia desse tipo de mudana foi percebida durante o experimento relatado

no Apndice A. A incluso de um novo conceito do tipo dataTypeProperty caracterizou-se

59
por afetar fortemente os artefatos ligados ao conceito do tipo class ao qual o primeiro se relaciona.

3.6.2.2.2 Incluso de conceito do tipo class

Durante o experimento, no houve nenhum requisito de mudana que propiciasse

a incluso de um novo conceito do tipo class. Estudando a estrutura ontolgica percebe-se que
quando conceitos desse tipo so includos, h uma nova associao com outros conceitos da
ontologia. Essa associao possibilitada pelo uso de conceitos do tipo objectProperty. Nesse
caso, o impacto calculado para os artefatos que esto relacionados ao conceito ao qual o
novo conceito se liga.
Para exemplificar essa situao, o requisito de mudana da figura 25 aplicado ao
modelo de domnio de livros, representado na figura 22. A alterao na ontologia est representada na figura 26, onde esto destacados os novos conceitos includos.

Requisito de Mudana C: necessrio conhecer em quais livrarias o livro est disponvel

para venda. As informaes necessrias sobre esta so: onde est localizada, qual o volume
de vendas por ms, contato e ramo de atividade.
Figura 25 Requisito de mudana C no domnio de livros.
class
type

type
type

object
Property

type

range

ehVendido

range

onProperty

onProperty

ehEscrito
Livraria

Livro

Autor
domain

type

domain

domain
domain

nome

ttulo
domain

ISBN
domain

nascimento

domain

domain

endereo

codinome

ano

editora

domain

domain

type
type

ramoAtividade

type
type

type
type

type

dataType
Property

type
type

type

Figura 26 Ontologia equivalente ao requisito de mudana C no domnio de livros.

volumeVendas

60
No exemplo, o novo conceito do tipo class Livraria ligado ao conceito do tipo
class Livro, anteriormente existente, atravs do novo conceito do tipo objectProperty ehVendido. Como na ontologia original do domnio de livros no existe o conceito Livraria,
conseqentemente no h artefatos rastreados para esse conceito. Assim, a anlise de impacto
dessa mudana deve ser feita rastreando-se os artefatos que esto associados ao conceito Livro, atravs da influncia do relacionamento entre conceitos, apresentado a seguir.

3.7

INFLUNCIA DO RELACIONAMENTO ENTRE CONCEITOS

Sendo a ontologia equivalente a um grafo, possvel percorrer seus nodos, ou

conceitos, a partir de critrios pr-estabelecidos. No contexto da rastreabilidade semntica,
essa caracterstica til, pois permite encontrar os artefatos indiretamente afetados, a partir do
relacionamento entre conceitos.
A metodologia aqui proposta sugere o uso de algoritmos de radicalizao (ou de
stemming) para lngua portuguesa, como forma de identificar a relao sinttica existente entre os conceitos que se relacionam. Este utilizado para determinar o peso relativo ao conceito do tipo objectProperty que liga outros dois conceitos do tipo class. Na seo seguinte, ser
abordada a rea na qual esse mtodo est inserido, bem como a forma de utiliz-lo.

3.7.1 Processamento de Linguagem Natural

O Processamento de Linguagem Natural (PLN) usado, segundo Dias [DIA04],

para descrever a funo de softwares ou de componentes de hardware em um sistema computacional que analisam ou sintetizam linguagem falada ou escrita. Segundo Gonzalez
[GON03], aspectos da comunicao humana como sons, palavras, sentenas e discursos, considerando formatos e referncias, estruturas e significados, contextos e usos so tratados computacionalmente. O autor estabelece nveis de entendimento para esses aspectos:
a) Fontico e fonolgico: que trabalham o relacionamento das palavras com os
seus sons;

61
b) Morfolgico: abrange a construo das palavras a partir das unidades de significado primitivas e sua classificao em categorias morfolgicas;
c) Sinttico: aborda o relacionamento das palavras entre si e como as frases podem ser partes de outras, construindo sentenas;
d) Semntico: estuda o relacionamento das palavras com seus significados e como eles so combinados para formar os significados das sentenas;
e) Pragmtico: abrange o uso de frases e sentenas em diferentes contextos, afetando o significado.
No contexto da presente proposta, cabe analisar os nveis morfossinttico e semntico. Ambos sero brevemente detalhados a seguir, citando as tcnicas utilizadas para
extrair informaes de cada um desses processamentos.

3.7.1.1 Processamento Morfossinttico

Segundo Dias [DIA04], fazem parte do processamento morfossinttico, a anlise

morfolgica e a anlise sinttica. Ambas preocupam-se com a constituio das palavras e de
seus grupos, que o que forma os elementos de expresso de um lngua. A morfologia est
ligada a estrutura da palavra e a classificao dessas. Por outro lado, a anlise sinttica preocupa-se com o agrupamento de palavras, verificando a formao de frases.
Inserido na anlise morfolgica encontra-se a conflao, que o ato de fuso ou
combinao para igualar variantes morfolgicas de palavras. Segundo Gonzalez [GON03] os
principais mtodos de conflao so o de radicalizao e o de lematizao.
O mtodo de radicalizao relevante, dentro da proposta de anlise de impacto,
pois combina as formas diferentes de uma palavra em uma representao comum, o radical.
Esse mtodo pode ser utilizado para determinar a similaridade entre os conceitos da ontologia,
atravs de algoritmos de radicalizao. Esses algoritmos permitem comparar palavras que so
basicamente iguais, mas que sem a radicalizao so palavras distintas. Na figura 27, mostrado um exemplo de aplicao dessa tcnica. As palavras Livro e Livraria so reduzidas
a um mesmo radical, identificando que h uma relao entre elas.
Livro
Livraria
Radical: livrFigura 27 Exemplo de radicalizao de palavras.

62
Na metodologia de anlise de impacto, se for possvel reduzir os conceitos ao
mesmo radical, ento a influncia do relacionamento entre esses dois conceitos alto, caso
contrrio baixo. Os nveis de Influncia do relacionamento (Ir) podem ento ser classificados em: {baixo; alto}, tendo como valores correspondentes {0,5; 0,9}.
A ligao entre os conceitos Livro e Livraria dada pelo conceito ehVendido, como visto na figura 28, onde esto destacados os conceitos do tipo objectProperty. Nesse caso, a Influncia do relacionamento seria: Ir = alto. Isso significa que um requisito de
mudana que afete os artefatos ligados a um desses conceitos tem grande probabilidade de
impactar os artefatos do outro. J o conceito ehEscrito tem influncia Ir = baixo, pois os
conceitos relacionados a Autor e Livro no podem ser reduzidos ao mesmo radical.
class
type

type
type

Autor

Livro

Livraria
onProperty

onProperty
range

range

ehEscrito
Ir(ehEscrito) = baixo

ehVendido
type
type

Ir(ehVendido) = alto

object
Property

Figura 28 Sub ontologia equivalente ao domnio de livros, destacando a propriedade objectProperty.

Embora a extrao de um radical comum entre dois termos seja capaz de estabelecer um relacionamento entre eles, este est restrito morfologia das palavras. Uma maneira
mais precisa determinar a influncia de um relacionamento seria usar estruturas semnticas
para tal. Na seo seguinte ser brevemente detalhada a estrutura de tesauro.

3.7.1.2 Processamento Semntico

A semntica tem relao com o significado das palavras ou do conjunto delas. Segundo Dias [DIA04], o processamento semntico considerado um dos grandes desafios do

63
PLN, pois se vincula a morfologia e a estrutura sinttica juntamente com informaes pragmticas.
O significado de conjuntos de palavras pode ser obtido utilizando estruturas como
um tesauro, cuja definio dada por Corra [COR03] de um agrupamento de palavras, ou
radicais de palavras em certas categorias de assunto chamadas de classes conceituais. Uma
das vantagens de us-lo a possibilidade de se ter um vocabulrio controlado para pesquisa.
Os objetivos elencados por Salton [SAL68] para a criao de um tesauro so:
a) A padronizao das palavras-chave que foram encontradas, ou seja, fornecer
um vocabulrio padro para indexao e pesquisa;
b) Ajudar os usurios na localizao de termos para a formulao de consultas e;
c) Fornecer hierarquias de classes que permitem ampliar e limitar as consultas de
acordo com as necessidades do usurio.
A forma mais simples de estruturar um tesauro ter uma lista de palavras (conceitos) importantes para um domnio de conhecimento e, para cada palavra dessa lista, um conjunto de palavras relacionadas. As palavras relacionadas so variaes derivadas de um relacionamento sinnimo.
A representao, segundo Corra [COR03], pode ser feita atravs de um grafo,
onde cada nodo representa um termo que est ligado a outros termos e aos arcos so atribudos pesos. Os pesos so importantes para poder determinar a similaridade entre termos de um
documento. A figura 29 representa um tesauro.

Moradia

Apartamento

Casa

Figura 29 Exemplo de tesauro.

Em um tesauro palavras sintaticamente distintas, mas com semntica equivalente

podem ser relacionadas. No exemplo da figura 29, os termos casa e apartamento tm significados iguais, no contexto de moradia, mas so sintaticamente diferentes.
No contexto de anlise de impacto, uma melhoria na proposta aqui descrita seria
usar estrutura de tesauro, ao invs de algoritmos de radicalizao, para determinar a influncia
do relacionamento entre conceitos da ontologia. Assim, termos relacionados a um mesmo

64
domnio poderiam ser identificados, mesmo que tenham formao morfolgica distintas. Dessa forma, a preciso da influncia entre os conceitos seria maior, possibilitando determinar
mais precisamente a probabilidade de impacto de uma mudana em diversos nveis de caminhamento na ontologia.
A seguir, ser apresentado o clculo da influncia do relacionamento entre conceitos, utilizando o processo de radicalizao de palavras, como visto anteriormente. O uso de
uma estrutura como tesauro dever ser verificada em trabalhos futuros.

3.7.2 Clculo da Influncia do Relacionamento entre Conceitos

Na ontologia, a propriedade objectProperty tem o papel de relacionar conceitos do

tipo class. A figura 28 destaca essa propriedade. Assim, podemos perceber que, se uma alterao for realizada no conceito Autor, os artefatos ligados ao conceito Livro podem ser
rastreados, uma vez que os dois esto relacionados atravs do conceito ehEscrito. Se ocorrer
uma mudana em Livro, essa pode afetar os artefatos relacionados ao conceito Livraria,
j que esses esto ligados pelo conceito ehVendido. Assim, a rastreabilidade pode ser realizada em nveis. Na metodologia de anlise de impacto aqui proposta, o rastreamento de conceitos realizado somente na ontologia do sistema aps os conceitos do requisito de mudana
serem identificados nela. No capitulo 4, esse assunto ser amplamente abordado.
Associado a cada conceito do tipo objectProperty tem-se a influncia que este exerce sob os conceitos aos quais se relaciona. Esta influncia importante uma vez que ir
auxiliar na determinao de em quantos nveis interessante percorrer a ontologia. Se no
houver um critrio para determinar o nvel mximo de rastreabilidade, provvel que todos os
artefatos do projeto sejam encontrados, uma vez que todos os conceitos esto relacionados de
alguma forma. Para iniciar o caminhamento na ontologia, sugere-se rastrear a partir do conceito que teve maior nmero de mudanas, seja estrutural ou semntica.
Deve-se encontrar o conceito onde se iniciar o percurso de busca, somando todos
os valores de Impacto no artefato pela mudana (Iam(x,y)) que foram encontrados para cada
um dos artefatos relacionados aos conceito. Aquele conceito que possuir o maior Impacto
acumulado (Ia(x)), ser o ponto inicial de caminhamento no grafo, apresentado na frmula 9
onde x o conceito, n o nmero de artefatos ligados ao conceito e y o artefato.

65
n

Ia ( x )

Iam( x , y )
x 1

Frmula 9 Clculo do Impacto acumulado (Ia(x))

A figura 30 mostra a aplicao da frmula 9, supondo valores para artefatos ligados aos conceitos Livraria, Livro e Autor. Com o resultado, o conceito a partir do qual
se iniciar o caminhamento o conceito Livraria.
Iam(x,y) = Im x Ic x Id
Iam(Autor, C-Autor) = 0,9 x 1 x 0,5 = 0,45
Iam(Autor, UC-ManterAutor) = 0,9 x 1 x x = 0,9
Ia(Autor) = 1,35
Iam(Livro, C-Livro) = 0,9 x 1 x 0,5 = 0,45
Iam(Livro, DA-ManterLivro) = 0,9 x 1 x 1 = 0,9
Ia(Livro) = 1,35
Iam(Livraria, UC-ManterLivraria) = 0,9 x 1 x 1 = 0,9
Iam(Livraria, DA-ClassificarLivraria) = 0,9 x 1 x 1 = 0,9
Ia(Livraria) = 1,8
Figura 30 Exemplo de clculo do Impacto acumulado (Ia(x)).

Para estabelecer a Propagao do impacto (Pi), os diversos fatores de Influncia

do relacionamento (Ir(z)) devem ser multiplicados, como mostra a frmula 10, onde z representa o conceito do tipo objectProperty, conforme os conceitos so percorridos. A sugesto
dessa a metodologia que o nvel de impacto para parada do percurso seja fixado em 70%.
Sendo menor do que esse valor no mais recomendvel continuar a rastreabilidade, pois a
tendncia que os artefatos no sejam afetados pela alterao do requisito de mudana.

Pi

Irz1 Irz 2 ... Irzn

Frmula 10 Clculo da Propagao do impacto (Pi)

Todos os conceitos do tipo objectProperty que estiverem relacionados ao conceito

com maior Ia(x) devem ser analisados para que o Impacto no artefato pelo relacionamento
(Iar(x,y)) seja calculado. Essa varivel ir determinar a probabilidade de alterao no artefato,
atravs da frmula 11, onde x o conceito do tipo class e y o artefato. Nela, Pi representa a
propagao de influncia que o conceito recebeu at o momento no caminho percorrido no
grafo. Os valores que devem ser atribudos aos elementos da varivel Id so os mesmos utilizados para mudanas de regras de negcio, isso porque supostamente as alteraes desse tipo
tm maior propagao do que mudanas estruturais.

66

Iar( x, y )

Pi Ic Id

Frmula 11 Clculo do Impacto no artefato pelo relacionamento (Iar(x,y)).

Usando os elementos da figura 28, tem-se que o conceito do tipo class Livraria
est ligado ao conceito do tipo objectProperty ehVendido que por sua vez est ligado ao
conceito do tipo class Livro. Considerando que os artefatos do conceito Livraria foram os
que mais sofreram alteraes, os artefatos do conceito Livro tm probabilidade de serem
impactados. O calculo dessa probabilidade mostrada na figura 31. Nota-se que Pi igual a
Ir(ehVendido), isso porque os conceitos esto diretamente ligados.
Iar(x,y) = Pi x Ic x Id
Iar(Livro, C-Livro) = Pi x Ic x Id = 0,9 x 1x 0,5 = 0,45
Iar(Livro, DA-ManterLivro) = 0,9 x 0,9 x 1 = 0,9
Figura 31 Exemplo do clculo do Impacto no Artefato pelo Relacionamento (Iar(x,y))

Uma vez que o conceito Livro tem probabilidade de ser impactado e este se relaciona com o conceito do tipo class Autor atravs do conceito do tipo objectProperty
ehEscrito, os artefatos relacionados ao conceito Autor podem ser tambm impactados
pela mudana. Calcula-se ento a Propagao do impacto (Pi) e as probabilidades correspondentes para cada artefato, como mostra a figura 32. Dessa forma, estamos percorrendo a ontologia em trs nveis.
Pi = Ir(ehEscrito) x Ir(ehVendido)
Pi = baixo x alto
Pi = 0,5 x 0,9 = 0,45
Iar(x,y) = Pi x Ic x Id
Iar(Autor, C-Autor) = 0,45 x 0,9 x 0,5 = 0,20
Iar(Autor, UC-ManterAutor) = 0,45 x 0,9 x 1 = 0,40
Figura 32 Exemplo de clculo da Propagao do impacto (Pi).

No exemplo, utilizou-se um critrio de parada de 40% com o nico objetivo de

demonstrar o clculo em nveis, mesmo sabendo que no esse o fator recomendado pela
metodologia aqui apresentada. Nesse caso especfico, quando Pi < 0,4, o caminhamento no
grafo deve ser descontinuado. Por exemplo, se o conceito Autor estivesse ligado a um outro
conceito e o Ir entre eles fosse baixo, o valor de Pi passaria a ser de 0,225, tornando assim
no interessante o rastreamentos dos artefatos ligados a esse ltimo conceito.
Aps o detalhamento de todas as influncias e variveis necessrias para que a
metodologia seja aplicada, o prximo captulo apresentar os passos que devem ser realizados
para que a anlise de impacto de um requisito de mudana seja estabelecida.

67

METODOLOGIA PARA ANLISE DE IMPACTO DE MUDANA

A metodologia de anlise de impacto baseada na rastreabilidade por ontologias

avalia cada requisito de mudana de software separadamente. Esses requisitos so analisados
no contexto de projetos de manuteno de um produto, sendo que devem ser referentes a alteraes funcionais no software. Pela aplicao da metodologia, os artefatos com maior probabilidade de serem afetados pela mudana so identificados.
A metodologia de anlise de impacto de mudanas baseada na rastreabilidade por
ontologias composta por quatro passos: gerar a ontologia do requisito de mudana, identificar os conceitos da ontologia de mudana na ontologia do sistema, rastrear os artefatos impactados e listar, ordenados decrescentemente, os artefatos impactados. A figura 33 mostra graficamente como esses passos so encadeados.

1 - Gerar

Requisito
de mudana

2 - Identificar

Ontologia do
requisito de
mudana

4 - Listar

3 - Rastrear

Ontologia
do sistema

Artefatos
rastreados

Figura 33 Passos da metodologia de anlise de impacto baseada em ontologias

Listagem ordenada das probabilidades de

impacto

68
4.1

GERAR ONTOLOGIA DO REQUISITO DE MUDANA

O primeiro passo para gerar a ontologia do requisito de mudana , a partir de um

requisito de mudana, construir o modelo conceitual deste. Essa construo deve ser feita utilizando o dicionrio de dados do sistema, que definido como um depsito central que descreve e define o significado de toda a informao usada na construo de um sistema, dado
por Oliveira [OLI01]. Este artefato tem como objetivo, uniformizar a nomenclatura dos termos que sero usados na modelagem do requisito de mudana. Por exemplo, se no sistema
usado o termo docente, no deve ser usado na modelagem do requisito de mudana o termo
professor. A figura 34 mostra esse processo.

Dicionrio de
Dados do sistema
Requisito de
mudana

Modelo conceitual do
requisito de mudana

Figura 34 Desenvolvimento do modelo conceitual do requisito de mudana

Aps o modelo conceitual ter sido criado, pode-se gerar a ontologia referente a ele. Sugere-se o uso da ferramenta ONTrace da mesma forma como a ontologia do sistema
construda. A figura 35 apresenta esse passo.

Modelo conceitual do
requisito de mudana

Ontologia do requisito
de mudana

Figura 35 Gerar ontologia do requisito de mudana a partir de um modelo conceitual

A ontologia do requisito de mudana contm os conceitos existentes na ontologia

do sistema, sendo um sub-conjunto deste. A interseco entre as ontologias formada pelos
conceitos que so comuns as duas e que sero analisados para identificar o impacto da mudana. No possvel realizar a anlise de impacto se os conjuntos forem disjuntos, pois nesse

69
caso, no havendo nenhum conceito em comum, no h como realizar a rastreabilidade dos
artefatos, o que impede a medio do impacto.

Ontologia
do sistema

Ontologia do
requisito de
mudana

Conceitos que
sero analisados
pela metodologia
Figura 36 Interseco entre ontologias

A prxima fase da metodologia responsvel por identificar os conceitos da ontologia do requisito de mudana na ontologia do sistema, que formam o conjunto comum s
duas, representado na figura 36.

4.2

IDENTIFICAR CONCEITOS NA ONTOLOGIA DO SISTEMA

A segunda fase da metodologia identificar, na ontologia do sistema, os conceitos

que foram modelados no requisito de mudana. Esse passo necessrio uma vez que a rastreabilidade entre conceito e artefato foi realizada na ontologia do sistema. A figura 37 apresenta
esse passo.

Ontologia do requisito
de mudana

Ontologia do
sistema

Figura 37 Identificao dos conceitos da ontologia do requisito de mudana na ontologia do sistema

O processo de identificao deve ser realizado de forma a encontrar o tipo de mudana que est ocorrendo, explicitada na seo 3.6. Eventualmente, alguns conceitos da ontologia do requisito de mudana no sero encontrados na ontologia do sistema, o que caracteri-

70
za uma incluso. Em outros casos, podem-se encontrar conceitos que esto sendo alterados, e,
tambm, conceitos que foram apenas modelados sem sofrer nenhum tipo de alterao.
Na figura 38, tem-se a representao de um conceito do tipo dataTypeProperty
sendo includo, que taxaGordura. Os conceitos dataAvaliao e FichaBiomtrica, que
esto destacados, foram identificados na ontologia do sistema.
class
type

domain

dataAvaliao

type

dataType
Property

Ficha
Biomtrica
type

taxaGordura

domain

Figura 38 Identificao de incluso de um conceito do tipo dataTypeProperty

A figura 39 apresenta um conceito que est sendo alterado. Na ontologia referente

ao requisito de mudana, o range do conceito Meta, em destaque, int. Na ontologia do
sistema, esse mesmo conceito tem range string.
dataType
Property

type

dataType
Property

type

Meta

Meta
range

int

range

Ontologia do requisito
de mudana

string

Ontologia do
sistema

Figura 39 Identificao de alterao de um conceito do tipo dataTypeProperty

Os conceitos que so identificados na ontologia do sistema, mas que no sofrem

alteraes estruturais, tais como incluso ou alterao de conceitos, podem ter alteraes semnticas, ou seja, uma regra de negcio associada ao conceito pode ser alterada ou includa.
Nesse caso, o responsvel por fazer a anlise da mudana deve indicar que o conceito afetado dessa forma. Na figura 40, o conceito Cliente foi identificado na ontologia do sistema, e
este pode ser afetado ou no por uma regra de negcio constante no requisito de mudana.
class

type

Cliente

domain

nome

type

dataType
Property

Figura 40 Identificao de um conceito do tipo dataTypeProperty que no sofre mudana

A no existncia de um conceito na ontologia do requisito de mudana, do tipo

class ou dataTypeProperty, no caracteriza que esse conceito est sendo excludo da ontolo-

71
gia do sistema. Essa situao dever ser tratada em trabalhos futuros por apresentar complexidade superior incluso ou alterao de conceitos.
Outra identificao que pode ser feita quanto aos relacionamentos existentes entre conceitos. Esses relacionamentos permitem encontrar artefatos em n-nveis. O conceito da
ontologia do sistema que mais sofreu mudanas, seja de incluso de conceitos ou de alterao
destes, ser o ponto inicial de pesquisa, como visto no captulo anterior. A partir desse ponto,
o conceito do tipo objectProperty relacionado a ele encontrado e inicia-se ento o percurso
pelo encadeamento de conceitos. Um conceito do tipo objectProperty responsvel por relacionar outros dois conceitos do tipo class. A figura 41 apresenta esse tipo de relacionamento,
onde se pode determinar, como exemplo, que o conceito de partida seja o conceito Mensalidade, pois foi o mais afetado por mudanas.
object
Property

type

Possuem
Geradas
domain

onProperty

domain
range

Cliente

Mensalidade
type

type

class
Figura 41 Identificao de relacionamento entre conceitos

4.3

RASTREAR ARTEFATOS

Aps a identificao dos conceitos na ontologia do sistema, os artefatos relacionados a este podem ser rastreados. Os artefatos so rastreados conforme a relao e o tipo de
mudana, e a esta atribuda uma Influncia da mudana (Im).

72
4.3.1 Relao Conceito-Artefato

Esse tipo de relacionamento usado para rastrear os artefatos em apenas um nvel,

ou seja, que esto ligados diretamente aos conceitos. O clculo do impacto deve ser realizado
para cada um dos artefatos e determinado pela frmula 8.
A figura 42 abaixo mostra, genericamente, como dada a relao entre um conceito extrado da ontologia do sistema e artefatos rastreados a partir dele. No exemplo, o conceito Mensalidade foi identificado como existente na ontologia do sistema. A esse conceito,
foram ligados os artefatos do tipo caso de uso UC-GerarMensalidade e do tipo classe CMensalidade.

Mensalidade

GerarMensalidade

Conceito
Ontologia do
sistema

Mensalidade

Artefatos
Rastreados
Figura 42 Rastreabilidade de relao conceito-artefato

Para realizar a rastreabilidade nesse tipo de relao, importante distinguir se a

alterao referente a regras de negcio ou a relacionamentos, o que muda estruturalmente a
ontologia. Esses tipos de mudana tm influncia alta, mas so diferenciados na maneira como o artefato impactado, dependendo do tipo de diagrama da UML a que pertencem. Alm
disso, as alteraes estruturais podem ser identificadas automaticamente, pois h a incluso de
um novo conceito ou a alterao de algum j existente.
Independe se o requisito de mudana afeta estruturalmente ou semanticamente a
ontologia, os tipos de conceitos que se relacionam diretamente a artefatos so os do tipo dataTypeProperty e do tipo class. Pode-se estabelecer ento, a relao dataTypePropertyArtefato e class-Artefato. Ambas sero detalhadas a seguir.

73
4.3.1.1 Relao dataTypeProperty-Artefato

Nesse caso, os artefatos so relacionados diretamente ao conceito do tipo dataTypeProperty. Podem ser rastreadas as alteraes semnticas e estruturais. Essa ltima ocorre
quando h mudana do tipo de range do conceito.
A figura 43 mostra essa rastreabilidade. Nela, a Influncia da mudana (Im) est
classificada como alta conforme explicao constante na seo 3.6. O artefato CFichaBiomtrica ligado ao conceito Meta, teve a Influncia do conceito no artefato (Ic)
determinada como sendo forte. Uma vez que uma classe pertence ao diagrama de classes e, a
Influncia do tipo de diagrama (Id) foi dada como esttica.
string
range

dataType
Property

type

Meta

Ic = Forte
Id = esttico

FichaBiometrica

Im = Alta
Figura 43 Rastreabilidade de alterao de um conceito do tipo dataTypeProperty

Seguindo o exemplo, o Impacto no artefato pela mudana (Iam(x,y)) no artefato

pode ser calculado como mostra a figura 44. Os valores dos elementos do conjunto representacional de Id so dados conforme o tipo de mudana, se de regra de negcio ou de relacionamentos na ontologia, sendo, nesse exemplo, o segundo.

Im = {baixa;alta} = {0,1;0,9}
Ic = {fraco; forte} = {0,3; 1}
Id = {esttico; dinmico; funcional} = {1;0,5;0,1}
Iam(x, y )= Im x Ic x Id
Iam(Meta, C-FichaBiometrica)= alta x forte x esttico
Iam(Meta,C-FichaBiometrica) = 0,9 x 1 x 1 = 0,9
Figura 44 Clculos da relao dataTypeProperty-Artefato.

74
4.3.1.2 Relao class-Artefato

Os artefatos so diretamente ligados a um conceito do tipo class. Assim como ocorre na relao dataTypeProperty-Artefato, mudanas semnticas ou estruturais podem ser
identificadas. Essa ltima ocorre quando um novo conceito do tipo dataTypeProperty associado a um conceito do tipo class.
necessrio diferenciar os conceitos que esto sendo afetados pelo requisito de
mudana, estruturalmente ou semanticamente, dos conceitos que foram identificados na ontologia do sistema, mas que no sofrem nenhuma alterao. No primeiro caso, a influncia pelo
tipo de mudana alta e no segundo baixa. Mesmo que Influncia da mudana (Im) seja
baixa, interessante rastrear os artefatos relacionados a este conceito, uma vez que ele apareceu no requisito de mudana. Atravs da anlise da varivel Iam(x,y), ser possvel determinar
a probabilidade de impacto no artefato.
A figura 45 representa a incluso de um conceito, classificada como alterao estrutural, cuja Influncia da mudana (Im) tida como alta. Os conceitos que esto destacados
so os conceitos que foram identificados no passo anterior, de identificao de conceitos. No
exemplo, o conceito dataAvaliao est sendo associado ao conceito FichaBiomtrica.
Esse ltimo, por sua vez, est associado a artefatos, com sua Influncia do conceito no artefato (Ic) sendo determinada para cada um deles. tambm identificado individualmente o tipo
de diagrama a que o artefato pertence, utilizando a tabela VI, e estabelecendo a Influncia do
tipo de diagrama (Id).
FichaBiometrica

class
type
type

dataAvaliao

domain

Ficha
Biomtrica

dataType
Property

Property

type

taxaGordura

domain

Im = Alta

Ic = Forte
Id = esttico
Ic = Fraco
Id = dinmico

AcessarFicha

Ic = Forte
Id = dinmico
Ic = Fraco
Id = dinmico

Figura 45 Rastreabilidade de incluso de um conceito do tipo dataTypeProperty

ManterFicha
Cliente

Sistema

AtividadeA

AtividadeB

AtividadeD

AtividadeC

75
O impacto calculado para cada artefato que for rastreado. A figura 46 mostra o
clculo da varivel impacto para o artefato UC-ManterFicha. Os valores dos elementos dos
conjuntos Im e Ic so os mesmos da figura 44.

Im = {baixa;alta} = {0,1;0,9}
Ic = {fraco; forte} = {0,3; 1}
Id = {esttico; dinmico; funcional} = {1;0,5;0,1}
Iam(x, y) =Im x Ic x Id
Iam(FichaBiometrica, UC-ManterFicha)= alta x forte x dinmico
Iam(FichaBiometrica, UC-ManterFicha)= 0,9 x 1 x 0,5 = 0,45
Figura 46 Clculos da relao estrutural class-Artefato

Quando existir alterao semntica, essa deve ser indicada. A partir de ento, os
artefatos relacionados ao conceito podem ser analisados quanto ao impacto da mudana. A
figura 47 mostra um exemplo quando o conceito Mensalidade est relacionado a alteraes
em regras de negcio.
Ic:= Forte
Id = esttico
type

class

Mensalidade
Im = Alta

Mensalidade

Ic = Forte
Id = dinmico
GerarMensalidade

Figura 47 Alterao de regra de negcio associada a conceito

Para realizar o clculo desse tipo de mudana, os conjuntos de valores de Im e Ic

so iguais aos apresentados na figura 44. Especificamente nesse caso, os valores dos elementos do conjunto do tipo de diagrama so diferentes. A figura 48 mostra o clculo do artefato
do tipo caso de uso UC-GerarMensalidade.

Im = {baixa;alta} = {0,1;0,9}
Ic = {fraco; forte} = {0,3; 1}
Id = {esttico; dinmico; funcional} = {0,5; 1; 0,1}
Iam(x, y) =Im x Ic x Id
Iam(Mensalidade, UC-GerarMensalidade) = alta x forte x dinmico
Iam(Mensalidade, UC-GerarMensalidade) = 0,9 x 1 x 1 = 0,9
Figura 48 Clculos da relao semntica class-Artefato

A figura 49 destaca um conceito presente na ontologia de requisito de mudana e

que foi identificado na ontologia do sistema, mas que no sofre alteraes estruturais ou se-

76
mnticas. Apesar disso, o impacto nos artefatos pode ser avaliado, embora se considere que
existe uma baixa probabilidade de serem afetados.
Ic = Forte
Id = esttico

class

type

Cliente

Cliente

Ic = Forte
Id = dinmico
ManterFichaCliente

Im = Baixa
Ic = Fraco
Id = dinmico
GerarMensalidade

Figura 49 Identificao de um conceito do tipo dataTypeProperty que no sofre mudana

O clculo das probabilidades de impacto nos artefatos ligados no conceito Cliente demonstrado na figura 50, referente ao artefato C-Cliente. Consideram-se os valores
dos elementos do conjunto de influncia do tipo de diagrama como se a alterao fosse de
regra de negcio. Isso porque se infere que, se a mudana fosse estrutural, essa seria identificada ao comparar a ontologia do requisito de mudana e a ontologia do sistema. Os valores
dos elementos dos conjuntos Im, Ic e Id so os mesmos da figura 48.
Im = {baixa;alta} = {0,1;0,9}
Ic = {fraco; forte} = {0,3; 1}
Id = {esttico; dinmico; funcional} = {0,5; 1; 0,1}
Iam(x, y) =Im x Ic x Id
Iam(Cliente, C-Cliente) = baixa x forte x esttico
Iam(Cliente, C-Cliente) = 0,1 x 1 x 0,5 = 0,05
Figura 50 Clculos da relao class-Artefato sem alteraes.

4.3.2 Relao Conceito-Conceito

Associado ao conceito do tipo objectProperty, tem-se a Influncia do relacionamento (Ir), determinada por um algoritmo de stemming, conforme apresentado na seo
3.7.1.1. No necessrio utilizar a influncia do tipo de mudana, pois no se trata, nesse
caso, de rastrear as mudanas semnticas ou estruturais a que o conceito foi submetido e sim a
propagao do impacto nos conceitos. A figura 51 apresenta os artefatos que so encontrados
num rastreamento de dois nveis e a relao entre os conceitos.

77

Cliente

Cliente
ManterFichaCliente
domain

onProperty

Possuem
GerarMensalidade

onProperty

Ontologia do
sistema

Mensalidade

range

Mensalidade
Artefatos
Rastreados

Conceitos

Figura 51 Rastreabilidade de relao conceito-conceito

Considerando-se que no ensimo nvel de busca na ontologia todos os artefatos do

sistema sero rastreados, pois isso implica num percurso completo no grafo da ontologia, deve-se estabelecer um nvel mximo de busca de conceitos nesta. A frmula 9 calcula a Propagao do impacto (Pi). A partir do resultado dessa propagao, devem ser rastreados todos os
artefatos que esto relacionados a conceitos do tipo class e que estiverem relacionados por
conceitos do tipo objectProperty, respeitando o critrio de parada. A figura 52 apresenta uma
relao conceito-conceito.
Ic = Forte
Id = esttico

onProperty

Ic = Forte
Id = dinmico
ManterFichaCliente
Ic: Fraco
Id = dinmico

Cliente
type
domain

object
Property

type

Possuem
Geradas

Ir(possuemGeradas) = baixo
domain

Cliente

class
GerarMensalidade
range

Mensalidade

type

Ic = Forte
Id = dinmico
Mensalidade

Ic = Forte
Id = esttico

Figura 52 Rastreabilidade de artefatos na relao conceito-conceito

78
O primeiro passo para analisar o impacto que se propaga entre os conceitos determinar qual deles foi afetado com maior nmero de mudanas, ou seja, Impacto Acumulado
(Ia(x)), dado pela frmula 10. Os conceitos que sero analisados para ter essa varivel calculada sero todos aqueles que foram identificados na ontologia do sistema a partir da ontologia
do requisito de mudana. A figura 53 estabelece os valores do Impacto no artefato pela mudana (Iam(x,y)), para os conceitos e calcula o Ia(x), considerando as alteraes analisadas anteriormente nas figuras 47 e 49.

Im = {baixa;alta} = {0,1;0,9}
Ic = {fraco; forte} = {0,3; 1}
Id = {esttico; dinmico; funcional} = {0,5; 1; 0,1}
Iam(x,y) = Im x Ic x Id
Iam(Cliente, C-Cliente) = 0,05
Iam(Cliente, UC-ManterFichaCliente) = 0,1
Iam(Cliente, UC-GerarMensalidade) = 0,06
Ia(Cliente) = 0,22
Iam(Mensalidade, UC-GerarMensalidade) = 0,45
Iam(Mensalidade, C-Mensalidade) = 0,9
Ia(Mensalidade) = 1,35
Figura 53 Clculo do Impacto acumulado (Ia(x))

O prximo passo iniciar o caminhamento no grafo da ontologia a partir do conceito Mensalidade que teve maior Impacto acumulado (Ia(x)). No exemplo da figura 52,
onde mostrada parcialmente uma ontologia, o nico conceito que pode ser relacionado
Cliente. Conforme determinado pelo algoritmo de radicalizao, a Influncia do relacionamento (Ir) entre os dois conceitos baixa.
Nesse exemplo, a Propagao do impacto (Pi) igual a Ir, pois s existe um conceito do tipo objectProperty capaz de estabelecer relacionamentos entre dois outros conceitos.
Como a metodologia sugere que o critrio de parada seja maior do que 70%, nesse caso no
indicado que se rastreie os artefatos do conceito Cliente, j que Pi = 0,5, ou seja, tem probabilidade de impacto de 50%, sendo menor do que o critrio estabelecido.

79
4.4

LISTAR ARTEFATOS

O ltimo passo da metodologia fornecer a lista de artefatos que tem mais probabilidade de impacto. Aps ter sido calculado o impacto do artefato, seja pelo tipo de mudana
ou pelo relacionamento entre conceitos, um valor atribudo a cada um deles.
Como mostrado na figura 51, um mesmo artefato pode estar relacionado a mais de
um conceito, no exemplo, o caso de uso UC-GerarMensalidade.Isso significa que durante o
rastreamento, um mesmo artefato pode ter sido encontrado mais de uma vez e, conseqentemente, ter o impacto calculado cada uma delas. Os impactos calculados para um mesmo artefato devem ser somados.
Aps a soma dos valores de impacto dos artefatos que se repetiram, armazenada
na varivel Probabilidade acumulada (Pa(y)), onde y o artefato, calculado o Percentual de
probabilidade de impacto (Ppi(y)) para cada um deles. O clculo dado pela frmula 12, onde
a porcentagem dos demais artefatos normalizada a partir do maior Pa(y). Ao final, fornecido o conjunto ordenado de forma decrescente de Ppi(y) dos artefatos rastreados.

Pa ( y ) 100

Ppi( y )

max( Pa ( y ) )

Frmula 12 Clculo do Percentual de probabilidade de impacto do artefato (Ppi(y)).

Para determinar os artefatos com a maior probabilidade de impacto, calculada a

mdia ponderada em relao a todos aqueles que foram rastreados. Todos os artefatos que
tiverem sua Probabilidade acumulada (Pa(y)) maior do que a mdia ponderada, iro formar o
conjunto dos elementos que mais provavelmente sero alterados. A frmula 13 mostra como
se calcula essa mdia, onde x o nmero de artefatos que obtiveram a mesma Pa(y).
n

Pa y1 .x1

Pa y 2 .x 2

Pa y1

Pa y 2

Pa y 3 .x3
Pa y 3

... Pa yn .x n

( Pa yi

xi )

i 1

... Pa yn

Pa yi
i 1

Frmula 13 Clculo da mdia ponderada.

Para auxiliar na aplicao da metodologia, foi proposta e desenvolvida uma ferramenta chamada ONTImpact. Essa ser descrita a seguir.

80
4.5

FERRAMENTA

Com o objetivo de calcular automaticamente o impacto que os artefatos sofrem ao

serem alterados por um requisito de mudana, uma ferramenta foi desenvolvida usando a tecnologia Java[JAV06]. A esse aplicativo foi dado o nome de ONTImpact, que armazena as
influncias dos artefatos e conceitos, compara as ontologias do requisito de mudana e do
sistema e calcula o impacto nos objetos rastreados.
Para armazenar as influncias que o conceito exerce sobre o artefato e o tipo de
diagrama ao qual este pertence, a ontologia do sistema gerada pela ferramenta ONTrace
carregada no ONTImpact. Para que seja possvel carregar os conceitos por tipos que os representam, feita uma consulta no Jena[JEN06]. A figura 54 mostra um exemplo dessa seleo.

Figura 54 Tela com os conceitos do tipo class e dataTypeProperty

Em uma janela, so apresentados os conceitos do tipo class e dataTypeProperty

bem como os artefatos que foram ligados a eles. A esses objetos, possvel associar a Influ-

81
ncia do conceito no artefato (Ic) e a Influncia do tipo de diagrama (Id). A primeira pode ser
classificada em: fraca, moderada e forte e armazenada ao conceito artifact da ontologia,
utilizando a propriedade ontImpactConceptInfluence. A segunda escolhida entre esttico,
dinmico e funcional, tambm relacionada ao conceito artifact e utilizando a propriedade
ontImpactDiagramInfluence. A figura 55 mostra essa interface.

Figura 55 Entrada das influncias do conceito e tipo de diagrama

Numa segunda janela, so apresentados os conceitos do tipo objectProperty, juntamente com os conceitos do tipo class aos quais se relaciona A esses conceitos, atribuda a
Influncia do relacionamento (Ir), calculada a partir de um algoritmo de radicalizao que
compara os conceitos ligados a ele com as propriedades range e domain. Essa influncia
ento classificada em baixa ou alta e armazenada no conceito artifact na propriedade ontImpactRelationshipInfluence. A figura 56 apresenta essa tela.

Figura 56 Tela com os conceitos do tipo objectProperty

82
Aps todas as influncias terem sido atribudas, faz-se necessrio tambm, que o
usurio do sistema informe se o conceito est tendo alguma regra de negcio associada a ele
alterada. A figura 57 mostra esse procedimento. Somente os conceitos presentes na rvore de
Tipo de Mudana podem ter essa varivel setada. Essa informao armazenada em uma
varivel que ser utilizada no ltimo passo da metodologia e essencial para que a anlise de
impacto seja realizada com preciso.

Figura 57 Tela para informao se houve alterao de regra de negcio

Para que se faa a comparao das ontologias, o cdigo eXtensible Markup Language (XML) da ontologia do requisito de mudana carregado na ferramenta e comparado
com o cdigo XML da ontologia do sistema. So ento identificados os conceitos que so
comuns as duas ontologias bem como os conceitos que esto sendo inseridos ou alterados. A
figura 58 mostra a comparao entre dois cdigos XML e mostra os elementos comuns identificados. No exemplo, pode-se notar que o conceito possuemGeradas, do tipo objectProperty, e os conceitos do tipo class Mensalidade e Cliente so comum as duas ontologias.

83

<owl:ObjectProperty rdf:about="possuemGeradas">
<rdfs:domain>
<rdf:Description rdf:about="Clientes">
<owl:onProperty rdf:resource="possuemGeradas"/>
<owl:onProperty>
<owl:ObjectProperty rdf:about="mantemCadastro"/>
</owl:onProperty>
</rdf:Description>
</rdfs:domain>
<rdfs:range>
<rdf:Description rdf:about="Mensalidade">
<owl:onProperty rdf:resource="possueGeradas"/>
</rdf:Description>
</rdfs:range>
</owl:ObjectProperty>

Ontologia do Sistema

<owl:ObjectProperty rdf:about="possuemmGeradas">
<rdfs:domain rdf:resource="Cliente"/>
<rdfs:range>
<rdf:Description rdf:about="Mensalidade">
<owl:onProperty rdf:resource="possuemGeradas"/>
<rdf:type rdf:resource="Class"/>
</rdf:Description>
</rdfs:range>
</owl:ObjectProperty>

Ontologia do Requisito de Mudana

Figura 58 Comparao de ontologias atravs de cdigo XML

A ltima tarefa da ferramenta realizar a anlise de impacto, calculando a probabilidade de cada um dos artefatos relacionados aos conceitos serem impactados. Para isso, o
usurio deve escolher entre analisar o impacto verificando as mudanas estruturais ou semnticas identificadas na ontologia ou percorrendo ela pelo relacionamento entre os conceitos. A
figura 59 mostra o atalho para esse procedimento.

Figura 59 Tela com menu de escolha para comparao da ontologias e clculo do impacto

Com base nos valores dos elementos dos conjuntos de influncia, so calculados o
Impacto no artefato pela mudana (Iam(x,y)) ou o Impacto do Artefato pelo Relacionamento
(Iar(x,y)), dependendo do tipo de anlise de impacto escolhida. Ao final, apresentada uma
tabela com todos os artefatos rastreados e a probabilidade de impacto para cada um deles.

4.6

EXEMPLO DE APLICAO DA METODOLOGIA

O exemplo de aplicao da metodologia ser apresentado utilizando o projeto

IsGym, de controle de uma academia de ginstica, desenvolvido em uma disciplina do curso
de graduao em Sistemas de Informao da Faculdade de Informtica da Pontifcia Universidade Catlica do Rio Grande do Sul. Esse mesmo projeto foi aplicado em um experimento

84
inicial dessa metodologia, que est descrito no Apndice A, e serviu como insumo das hipteses identificadas.
O sistema IsGym foi escolhido pois possui algumas premissas bsicas necessrias
para o desenvolvimento desse trabalho. Dentre elas est o fato de seus autores no estarem
relacionados a esse estudo, ou seja, o projeto foi construdo sem que seus dados fossem direcionados a resultados especficos para serem utilizados na rastreabilidade e anlise de impacto. Alm disso, ele foi completamente modelado seguindo o processo unificado, facilitando a
abordagem aqui proposta, e teve uma implementao consistente.

4.6.1 Gerar Ontologia do Requisito de Mudana

O sistema IsGym foi desenvolvido com a finalidade de integrar todas as funcionalidades administrativas de uma academia em um nico sistema de informao. Ele mantm
cadastros de clientes, funcionrios, fornecedores, recursos e utilizao destes, assim como as
fichas de acompanhamento das avaliaes (biometria) e atividades dos alunos. Foi utilizada a
tecnologia JavaServer Pages (JSP) com conexo ao banco de dados MS-Access para desenvolv-lo e a modelagem de requisitos e funcionalidades foi feita no Rational Rose.
Abaixo esto relacionados o dicionrio de dados do sistema, o modelo conceitual
construdo baseado no requisito de mudana e a ontologia gerada a partir deste. O requisito de
mudana, presente na figura 60, foi escolhido por incluir novos conceitos na ontologia original do sistema e alterar uma regra de negcio associada a um conceito previamente existente.
Nele esto destacados os conceitos que so relevantes para analisar o problema.
Com o intuito de aumentar o nmero de freqentadores da academia, a GymJoe decidiu dar desconto para os
alunos que atingirem suas metas de treinamento. feita uma avaliao inicial do aluno. Aps o resultado
dessa, o aluno informa qual o percentual de taxa de gordura que deseja atingir nos prximos 6 meses, sendo
essa a sua meta. Ao final desse perodo, uma nova avaliao realizada e o instrutor verifica se o aluno
atingiu seu objetivo. Os descontos so dados seguindo os critrios:
25% de desconto da mensalidade se o resultado atingido for maior que a meta;
15% se atingiu a meta ou ficou 20% abaixo desta;
5% se ficou entre 21% e 60% abaixo da meta

Figura 60 Requisito de mudana para o sistema IsGym

85
Os conceitos presentes no requisito de mudana devem ser verificados no dicionrio de dados do sistema para garantir a uniformidade entre as nomenclaturas. Na figura 61
esto reproduzidos os trechos importantes para esse exemplo.
Nome: Cliente;
Tipo: classe;
Descrio: descreve os dados cadastrais do cliente da academia;
Pseudnimos: aluno;
Especificao:
Comentrios: a classe est presente no modelo de domnio e no diagrama de classes.
Nome: FichaBiometrica;
Tipo: classe;
Descrio: descreve os dados da avaliao do cliente;
Pseudnimos: avaliao;
Especificao:
Comentrios: a classe est presente no modelo de domnio e no diagrama de classes.
Nome: Mensalidade;
Tipo: classe;
Descrio: possui atributos necessrios para gerar a mensalidade;
Pseudnimos: fatura, boleto bancrio;
Especificao:
Comentrios: a classe est presente no modelo de domnio e no diagrama de classes.
Nome: Funcionrio;
Tipo: classe;
Descrio: descreve os dados cadastrais dos funcionrios;
Pseudnimos: professor, instrutor;
Especificao:
Comentrios: a classe est presente no modelo de domnio e no diagrama de classes.
Nome: Meta;
Tipo: atributo da classe FichaBiometrica;
Descrio: descreve o objetivo do cliente freqentar a academia;
Pseudnimos: objetivo;
Especificao: atributo do tipo String;
Comentrios: a classe FichaBiometrica est presente no modelo de domnio e no diagrama de classes.
Nome: TaxaDeGordura;
Tipo: atributo da classe FichaBiometrica;
Descrio: o percentual de gordura do cliente quando avaliado;
Pseudnimos: ndice de gordura;
Especificao: atributo do tipo float
Comentrios: a classe FichaBiometrica est presente no modelo de domnio e no diagrama de classes.

Figura 61 Dicionrio de Dados IsGym

Aps a verificao dos termos, o modelo conceitual do requisito de mudana pode

ser construdo. Na figura 62 est o modelo conceitual que representa o requisito de mudana.

Figura 62 Modelo de conceitual do requisito de mudana

86
De posse do modelo conceitual, possvel gerar a ontologia do requisito de mudana atravs da ferramenta ONTrace. Esta gera um cdigo em XML, apresentado na figura
63, que importante para identificao dos conceitos pela ferramenta que realiza a anlise de
impacto. A ontologia graficamente representada pela figura 64.
<?xml version="1.0"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#" >
<owl:Ontology rdf:about="isGymAlteracao1.owl"/>
<owl:Class rdf:about="Funcionario">
<owl:onProperty>
<owl:ObjectProperty rdf:about="ehResponsavel"/>
</owl:onProperty>
</owl:Class>
<owl:Class rdf:about="FichaBiometrica">
<owl:onProperty>
<owl:ObjectProperty rdf:about="possuemCadastrada"/>
</owl:onProperty>
</owl:Class>
<owl:Class rdf:about="Cliente">
<owl:onProperty>
<owl:ObjectProperty rdf:about="possuemGeradas"/>
</owl:onProperty>
</owl:Class>
<owl:ObjectProperty rdf:about="ehResponsavel">
<rdfs:domain rdf:resource="Funcionario"/>
<rdfs:range rdf:resource="FichaBiometrica"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="possuemGeradas">
<rdfs:domain rdf:resource="Cliente"/>
<rdfs:range>
<rdf:Description rdf:about="Mensalidade">
<owl:onProperty rdf:resource="possuemGeradas"/>
<rdf:type rdf:resource="Class"/>
</rdf:Description>
</rdfs:range>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="possuemCadastrada">
<rdfs:range rdf:resource="FichaBiometrica"/>
<rdfs:domain rdf:resource="Cliente"/>
</owl:ObjectProperty>
<owl:DatatypeProperty rdf:about="FichaBiometrica_dataAvaliacao">
<rdfs:domain rdf:resource="FichaBiometrica"/>
<rdfs:range rdf:resource="date"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:about="FichaBiometrica_taxaGordura">
<rdfs:domain rdf:resource="FichaBiometrica"/>
<rdfs:range rdf:resource="long"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:about="FichaBiometrica_meta">
<rdfs:domain rdf:resource="FichaBiometrica"/>
<rdfs:range rdf:resource="int"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:about="Mensalidade_desconto">
<rdfs:domain rdf:resource="Mensalidade"/>
<rdfs:range rdf:resource="int"/>
</owl:DatatypeProperty>
</rdf:RDF>

Figura 63 Ontologia do requisito de mudana representada em XML.

87

type

class

type

Mensalidade
Funcionario

type

domain
desconto

type
onProperty

domain

range

onProperty
onProperty

ehResponsavel

range

Cliente
Ficha
Biomtrica

domain

onProperty

domain

range

domain

possuem
Cadastradas
type

meta
range

int

possuem
Geradas

domain

domain
dataAvaliao

range

taxaGordura
range

date
range

type

int

long
type

type

objectProperty

type

type
dataType
Property

Figura 64 Ontologia do requisito de mudana representada graficamente.

Com a ontologia gerada, pode-se passar para o prximo passo, que de identificao dos conceitos na ontologia do sistema.

4.6.2 Identificar Conceitos na Ontologia do Sistema

A comparao entre as ontologias do sistema feita automaticamente a partir das

representaes XML da ontologia do requisito de mudana e da ontologia do sistema. A figura 65 representa graficamente os conceitos que so identificados na ontologia do sistema. Esta
est representada parcialmente, apenas os conceitos do tipo class so identificados e os demais conceitos associados a este esto sendo mostrados.

88

range

dataReferencia
class

type

Mensalidade
Funcionario

type

date

domain

type

domain

valor

range

int

type
onProperty

domain

range

onProperty

Possuem
Geradas

onProperty

ehResponsavel

range

Cliente
Ficha
Biomtrica

onProperty

altura

range
long

range
long

range

int

domain

domain
domain
domain
domain meta
taxaGordura
peso

domain
multa

range

range

domain
Possuem
Cadastradas
type

range
type

string

long

type

type

type

type
type

type

dataType
Property

type

objectProperty

type

type

type
type

Figura 65 Representao parcial da ontologia do sistema, com conceitos do requisito de mudana assinalados.

Foram identificadas trs solicitaes de alterao estrutural. Uma de alterao de

um dataTypeProperty e duas de incluso de dataTypeProperty. A primeira a alterao do
tipo do conceito meta ligado ao conceito FichaBiomtrica. A figura 66 mostra essa alterao. A segunda a incluso do conceito dataAvaliao relacionado ao conceito FichaBiometrica e do conceito desconto ligado ao conceito Mensalidade. As figuras 67 e 68,
respectivamente, apresentam essas mudanas.

range

type

dataType
Property

Meta

string

Figura 66 Identificao do conceito meta.

type

class

Ficha
Biomtrica

domain

type

dataAvaliao

Figura 67 Identificao do conceito FichaBiometrica.

dataType
Property

89

type

domain

Mensalidade

class

type

desconto

dataType
Property

Figura 68 Identificao do conceito Mensalidade, com alterao estrutural.

Houve tambm uma alterao de regra de negcio associada ao conceito Mensalidade, pois a forma de calcular a mensalidade foi alterada. Nesse caso, deve ser atribuda ao
conceito a informao de que existe essa alterao, uma vez que no h como identific-la
pela comparao das ontologias. A figura 69 mostra a identificao dessa alterao.
Mensalidade

Regra de negcio
alterada

Figura 69 Identificao do conceito Mensalidade, com alterao de regra de negcio.

4.6.3 Rastrear Artefatos

Os artefatos que foram rastreados para cada um dos conceitos identificados foram
baseados na rastreabilidade feita por um especialista na ferramenta ONTrace. Primeiramente,
sero rastreados e tero o impacto analisado os artefatos ligados a conceitos que sofreram
alteraes estruturais. Em seguida o mesmo ocorrer para os que tiveram alterao de regra de
negcio. Esses conceitos foram descritos na seo anterior. Por ltimo, os conceitos que foram identificados, mas que no esto relacionados a nenhum desses dois tipos de mudana,
sero analisados.
Ser considerado, para esse projeto, que o conjunto utilizado para classificar os
nveis de influncia que o conceito exerce sob o artefato de: {fraco, forte}, sendo os valores:
{0,3; 1}, respectivamente. A influncia do tipo de mudana dada pelo conjunto {baixa; alta}, tendo valores respectivos a {0,1; 0,9}. A influncia do tipo de diagrama dada pelo conjunto {esttico; dinmico; funcional} sendo que os valores dos elementos so diferentes dependendo do tipo de mudana. Se for estrutural, de {1; 0,5; 0,1} seno de {0,5; 1; 0,1}.

90
Os artefatos rastreados para o tipo de mudana de alterao do conceito do tipo
dataTypeProperty dado pela figura 70. Na figura 71 calculado o impacto do artefato, atravs da frmula 8.
string
range
dataType
Property

Ic = Forte
Id = esttico

type

Meta
Im = Alta

Figura 70 Rastreamento dos artefatos ligados ao conceito meta.

Iam(meta,C-FichaBiometrica) = Im x Ic x Id = 0,9 x 1 x 1 = 0,9
Figura 71 Clculo dos artefatos ligados ao conceito meta.

Os artefatos rastreados para o tipo de mudana de incluso do conceito do tipo dataTypeProperty para o conceito FichaBiomtrica dado pela figura 72. Na figura 73 calculado o impacto do artefato, atravs da frmula 8.

Ic = Forte
Id = esttico

class
type

dataType
Property

type

domain

dataAvaliao

Ficha
Biomtrica

Im = Alta
Ic = Fraco
Id = dinmico
: Usurio

Sistema

Ic = Forte
AlterarUltimaFichaBiometria
Id = dinmico
Ic = Forte
Id = dinmico
CriarFichaBiometria

Ic = Fraco
Ic = ForteId = dinmico
Id = dinmico
AcessarFichaBiometria

Ic = Forte
Id = dinmico
: Funcionario

: Funcionario

Sistema

Sistema

Selecionar opo Criar

ficha de biometria
Selecionar opo Acessar ficha
de acompanhamento de cliente

[ no existe ficha pessoal cadastrada ]

Selecionar opo Alterar
ltima ficha de biometria

[ usuario = cliente ]

[ existe ]
[ usurio = funcionario ]

Apresentar formulrio para

seleo do cliente

[ no existe ficha pessoal

cadastrada OU no existe ficha
de biometria cadastrada ]

Apresentar formulrio para

criao da ficha de biometria

[ existe ]
Retornar dados da ltima
ficha de biometria
Selecionar cliente
desejado

Apresentar opes que compem a

ficha de acompanhamento

Informar dados da ficha de

biometria do cliente

Validar dados da
ficha de biometria

Alterar dados da ltima ficha

de biometria do cliente

[ dados invlidos ]

Selecionar opo
Ficha de biometria

Selecionar uma das

biometrias apresentadas

Apresentar todas as biometrias

cadastradas deste cliente

Validar dados da
ficha de biometria

[ dados vlidos ]
Cadastrar ficha
de biometria

[ existem ]

[ dados invlidos ]
[ no existem biometrias cadastradas para este cliente ]

[ dados vlidos ]

Mostrar dados da
ficha de biometria

Acessar
FichaBiometria

Alterar ltima ficha

de biometria

Criar
AlterarUltima FichaBiometria
FichaBiometria

Figura 72 Rastreamento dos artefatos ligados ao conceito FichaBiometrica.

91

Iam(FichaBiometrica,C-FichaBiometrica) = 0,9 x 1 x 1 = 0,9;

Iam(FichaBiometrica,UC-CriarFichaBiometrica) = 0,9 x 1 x 0,5 = 0,45;
Iam(FichaBiometrica,UC-AlterarUltimaFichaBiometria) = 0,9 x 1 x 0,5 = 0,45;
Iam(FichaBiometrica,UC-AcessarFichaBiometria) = 0,9 x 1 x 0,5 = 0,45;
Iam(FichaBiometrica,DA-CriarFichaBiometria) = 0,9 x 1 x 0,5 = 0,45;
Iam(FichaBiometrica,DA-AlterarUltimaFichaBiometria) = 0,9 x 1 x 0,5 = 0,45;
Iam(FichaBiometrica,DA-AcessarFichaBiometria) = 0,9 x 1 x 0,5 = 0,45;
Figura 73 Clculos dos artefatos ligados ao conceito FichaBiometrica.

Os artefatos rastreado para o tipo de mudana de incluso do conceito do tipo dataTypeProperty para o conceito Mensalidade dado pela figura 74. Na figura 75 calculado o impacto do artefato, atravs da frmula 8.

class
type

dataType
Property

type

desconto

domain

Mensalidade
Im = Alta

Ic = Forte
Id = esttico
Ic = Forte
Id = dinmico
Ic = Forte
Id = esttico

GerarMensalidade
Funcionario

Sistema

Seleciona a opo de
Gerar Mensalidade

Apresentar formulrio para

seleo de cliente

Selecionar cliente
desejado

Informa multa

Validar dados
da multa

[ dados invlidos ]
[ dados vlidos ]
Calcula mensalidade
do cliente

GerarMensalidade

Figura 74 Rastreamento dos artefatos ligados ao conceito Mensalidade.

Iam(Mensalidade,C-Mensalidade) = 0,9 x 1 x 1 = 0,9;
Iam(Mensalidade,UC-GerarMensalidade) = 0,9 x 1 x 0,5 = 0,45;
Iam(Mensalidade,DA-GerarMensalidade) = 0,9 x 1 x 0,5 = 0,45;
Figura 75 Clculos dos artefatos ligados ao conceito Mensalidade - estrutural.

Para esse mesmo conceito, existem mudanas na regra de negcio associada a ele.
Os artefatos rastreados so os mesmos da figura 74, embora o clculo do impacto seja diferente, pois os valores da varivel Id mudam em decorrncia do tipo de mudana. Na figura 76
calculado o impacto do artefato, atravs da frmula 8.
Iam(Mensalidade,C-Mensalidade) = 0,9 x 1 x 0,5 = 0,45;
Iam(Mensalidade,UC-GerarMensalidade) = 0,9 x 1 x 1 = 0,9;
Iam(Mensalidade,DA-GerarMensalidade) = 0,9 x 1 x 1 = 0,9;
Figura 76 Clculos dos artefatos ligados ao conceito Mensalidade regra de negcio.

92
Os artefatos que foram identificados na ontologia do sistema a partir da ontologia
do requisito de mudana, mas que no sofrem nenhum tipo de alterao, seja estrutural ou
semntica, tambm so calculados. A finalidade identificar a probabilidade de impacto,
mesmo que pequena, dos artefatos que esto relacionados a esses conceitos. Outra motivao
que um artefato pode ser encontrado novamente e ento ter seus impactos somados.
A figura 77 mostra os artefatos relacionados ao conceito Cliente. Na figura 78
calculado o impacto do artefato, atravs da frmula 8.

CriarAtividadeTreinamento

CriarFichaPessoal

GerarGraficoCargaPorAtividade

: Usurio

Sistema

Sistema

Seleciona a opo de
Gerar Mensalidade

Cliente

Apresentar formulrio para

seleo de cliente

: Usurio

Sistema

Apresentar tela solicitando

identificao do tipo de usurio

Sistema

Sistema

Selecionar
cliente

Apresentar formulrio de
autenticao

Apresentar formulrio para

criao da ficha pessoal

[ usuario = cliente ]

Apresentar formulrio para

seleo do cliente

Selecionar cliente
desejado

Informa multa

Selecionar cliente
desejado

: Funcionario

Selecionar opo
Criar ficha pessoal

[ usuario = funcionario ]

[ usurio = funcionario ]

Cliente
Im = Baixa

CriarAtividadeTreinamento

Selecionar opo Gerar

grficos de desempenho

Acessar sistema da Academia

Desportiva Gym-Joe

[ usuario = cliente ]

type
class

AcessarAtividadeTreinamento

GerarGraficoPeso AlterarUltimaAtividadeTreinamento

Funcionario

Selecionar opo Acessar ficha

de acompanhamento de cliente

CriarFichaBiometria

AcessarFichaBiometria

GerarGraficoTaxaGordura

AcessarFichaPessoal

AlterarFichaPessoal

AutenticarCliente

GerarMensalidade

Informar cdigo e
senha

Apresentar opes que compem a

ficha de acompanhamento

Apresentar formulrio para

seleo do cliente

Selecionar cliente
desejado

Validar dados
da multa

Apresentar opes de
grficos existentes

Validar dados da
ficha pessoal

Informar dados da ficha

pessoal do novo cliente

Validar dados da
autenticao

[ dados invlidos ]
[ no existem biometrias cadastradas para este cliente ]

[ dados invlidos ]

Selecionar opo Grfico

de evoluo de peso

[ dados invlidos ]

[ dados vlidos ]

[ dados vlidos ]
[ existe ]

Selecionar opo
Ficha pessoal

[ dados vlidos ]

Calcula mensalidade
do cliente

Mostrar dados da ficha

pessoal do cliente

Liberar acesso
ao cliente

: Funcionario

Sistema

: Funcionario

Selecionar opo Alterar ltima

atividade de treinamento

Sistema

Selecionar opo
Alterar ficha pessoal

Cadastrar ficha
pessoal

Mostrar grfico

: Funcionario

Sistema

: Funcionario

Sistema

Selecionar opo Criar

ficha de biometria

Selecionar opo Criar

atividade de treinamento

[ no existe ficha pessoal cadastrada ]

[ no existe ficha pessoal cadastrada

OU no existe ficha de biometria
cadastrada OU no existe atividade
de treinamento cadastrada ]

[ no existe ficha pessoal

cadastrada OU no existe ficha
de biometria cadastrada ]

[ no existe ficha pessoal cadastrada ]

[ existe ]

Apresentar formulrio para

criao da ficha de biometria

[ existe ]
Retornar dados da
ficha pessoal

[ existe ]

[ existe ]

Apresentar formulrio para criao da

atividade de treinamento

Retornar dados da ltima

atividade de treinamento

Informar dados da ficha de

biometria do cliente

Alterar dados da ficha

pessoal do cliente

Alterar dados da ltima atividade

de treinamento do cliente

Validar dados da
ficha pessoal

Validar dados da
ficha de biometria

[ dados invlidos ]

Validar dados da atividade

de treinamento

Informar dados da atividade de

treinamento do cliente

[ dados vlidos ]

[ dados invlidos ]

Validar dados da
atividade de treinamento

Cadastrar ficha
de biometria

[ dados vlidos ]

[ dados invlidos ]
[ dados invlidos ]

Cadastrar atividade de
treinamento

[ dados vlidos ]
[ dados vlidos ]

Alterar ficha
pessoal

Alterar ltima atividade de

treinamento

: Usurio

Sistema

: Funcionario

Sistema

: Usurio

Sistema

: Usurio

Sistema

Selecionar opo Acessar ficha

de acompanhamento de cliente

Selecionar opo Gerar

grficos de desempenho

Selecionar opo Alterar

ltima ficha de biometria

[ usuario = cliente ]

[ usuario = cliente ]

[ no existe ficha pessoal

cadastrada OU no existe ficha
de biometria cadastrada ]

[ usuario = funcionario ]

[ usuario = cliente ]

Apresentar formulrio para

seleo do cliente

[ usuario = funcionario ]

[ existe ]
Retornar dados da ltima
ficha de biometria

Selecionar cliente
desejado

Sistema

[ usurio = funcionario ]

Selecionar cliente
desejado

Alterar dados da ltima ficha

de biometria do cliente

Selecionar cliente
desejado

Apresentar formulrio para

seleo do cliente

Apresentar opes que compem a

ficha de acompanhamento

Apresentar opes de
grficos existentes

Selecionar opo
Ficha de biometria

Validar dados da
ficha de biometria

Selecionar opo Grfico de

evoluo de carga por atividade

[ usuario = cliente ]

[ usurio = funcionario ]

Apresentar formulrio para

seleo do cliente

Apresentar formulrio para

seleo do cliente

Apresentar opes de
grficos existentes

[ no existem atividades de treinamento cadastradas para este cliente ]

: Usurio

Selecionar opo Acessar ficha

de acompanhamento de cliente

Selecionar opo Gerar

grficos de desempenho

Apresentar todas as biometrias

cadastradas deste cliente

Selecionar cliente
desejado

Selecionar opo
atividades de treinamento

Apresentar opes que compem a

ficha de acompanhamento

Apresentar todas as atividades de

treinamento cadastradas deste cliente

[ no existem biometrias cadastradas para este cliente ]

[ existe ]

Selecionar opo Grfico de

evoluo da taxa de gordura

[ dados invlidos ]

Selecionar uma das

biometrias apresentadas

[ existem ]

[ no existem biometrias cadastradas para este cliente ]

Mostrar
grfico(s)

[ existe ]
[ dados vlidos ]
Alterar ltima ficha
de biometria

Selecionar uma das atividades

de treinamento apresentadas

[ existe ]

[ no existem atividades de treinamento cadastradas para este cliente ]

Mostrar grfico

Mostrar dados da
ficha de biometria

Mostrar dados da
atividade de treinamento

Figura 77 Rastreamento dos artefatos ligados ao conceito Cliente.

93

Iam(Cliente,C-Cliente) = 0,1 x 1 x 0,5 = 0,05;

Iam (Cliente,UC-CriarFichaPessoal) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,UC-AlterarFichaPessoal) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,UC-AcessarFichaPessoal) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,UC-CriarFichaBiometria) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,UC-AlterarUltimaFichaBiometria) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,UC-AcessarFichaBiometria) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,UC-CriarAtividadeTreinamento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,UC-AlterarUltimaAtividadeTreinamento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,UC-AcessarAtividadeTreinamento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,UC-GerarGrficoPeso) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,UC-GerarGrficoTaxaGordura) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,UC-GerarGrficoCargaAtividade) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,UC-AutenticarCliente) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,UC-GerarMensalidade) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,DA-CriarFichaPessoal) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,DA-CriarFichaPessoal) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,DA-AcessarFichaPessoal) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,DA-CriarFichaBiometria) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,DA-AlterarUltimaFichaBiometria) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,DA-AcessarFichaBiometria) = 0,1 x 1 x 1 = 0,1;
Iam (Cliente,DA-CriarAtividadeTreinamento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,DA-AlterarUltimaAtividadeTreinamento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,DA-AcessarAtividadeTreinamento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,DA-GerarGrficoPeso) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,DA-GerarGrficoTaxaGordura) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,DA-GerarGrficoCarga) = 0,1 x 0,3 x 1 = 0,03;
Iam (Cliente,DA-AutenticarCliente) = 0,1 x 0,3 x 1 = 0,03;
Iam(Cliente,DA-GerarMensalidade) = 0,1 x 0,3 x 1 = 0,03;
Figura 78 Clculos dos artefatos ligados ao conceito Cliente.

94
A figura 79 mostra os artefatos relacionados ao conceito Funcionrio. Na figura
80 calculado o impacto do artefato, atravs da frmula 8.

AlterarFornecedor

CriarAtividadeTreinamento

CriarFichaPessoal

CriarFornecedor GerarGraficoCargaPorAtividade

AutenticarCliente

GerarMensalidade

CriarFichaBiometria CriarFuncionario

AcessarFichaBiometria AcessarAtividadeTreinamento AlterarFuncionario

GerarGraficoTaxaGordura

AutenticarFuncionrio AlterarFichaPessoal AcessarFichaPessoal GerarGraficoPeso AlterarUltimaAtividadeTreinamento

ClassificarFornecedor AlterarUltimoOramento CadastrarOramento

: Usurio

Sistema

Funcionario

Selecionar opo Acessar ficha

de acompanhamento de cliente

Sistema

Seleciona a opo de
Gerar Mensalidade

EmitirPedidoCompra

Cliente

Apresentar formulrio para

seleo de cliente

type

Sistema

Apresentar tela solicitando

identificao do tipo de usurio

[ usuario = funcionario ]

Apresentar formulrio para

seleo do cliente

Selecionar cliente
desejado

Informa multa

Selecionar cliente
desejado

Sistema

Apresentar formulrio para

criao da ficha pessoal

Selecionar opo
Criar ficha pessoal
[ usuario = cliente ]

[ usurio = funcionario ]

Funcionrio
Im = Baixa

: Funcionario

Selecionar opo Gerar

grficos de desempenho

Acessar sistema da Academia

Desportiva Gym-Joe

[ usuario = cliente ]

class

CancelarCompra

EfetuarCompra

: Usurio

Sistema

CriarAtividadeTreinamento

Selecionar
cliente

Apresentar formulrio de
autenticao

Informar cdigo e
senha

Validar dados da
autenticao

Apresentar formulrio para

seleo do cliente

Selecionar cliente
desejado

Validar dados
da multa

Apresentar opes que compem a

ficha de acompanhamento

Validar dados da
ficha pessoal

Informar dados da ficha

pessoal do novo cliente

Apresentar opes de
grficos existentes

[ dados invlidos ]
[ no existem biometrias cadastradas para este cliente ]

[ dados invlidos ]

Selecionar opo Grfico

de evoluo de peso

[ dados invlidos ]

[ dados vlidos ]

[ dados vlidos ]
[ existe ]

Selecionar opo
Ficha pessoal

Calcula mensalidade
do cliente

Mostrar dados da ficha

pessoal do cliente

Liberar acesso
ao cliente

: Funcionario

: Funcionario

[ dados vlidos ]

Sistema

: Funcionario

Sistema

Cadastrar ficha
pessoal

Mostrar grfico

: Funcionario

Sistema

: Funcionario

Sistema

Sistema
Selecionar opo Alterar ltima
atividade de treinamento

Selecionar opo
Alterar ficha pessoal

Selecionar opo Criar

ficha de biometria

Selecionar opo Criar

atividade de treinamento

[ no existe ficha pessoal cadastrada ]

[ no existe ficha pessoal cadastrada

OU no existe ficha de biometria
cadastrada OU no existe atividade
de treinamento cadastrada ]

[ no existe ficha pessoal

cadastrada OU no existe ficha
de biometria cadastrada ]

[ no existe ficha pessoal cadastrada ]

[ existe ]

Apresentar formulrio para

criao da ficha de biometria

[ existe ]

Alterar status do
pedido de compra

Selecionar opo
Cancelar compra

Retornar dados da
ficha pessoal

[ existe ]

[ existe ]

Apresentar formulrio para criao da

atividade de treinamento

Retornar dados da ltima

atividade de treinamento

Informar dados da ficha de

biometria do cliente

Alterar dados da ficha

pessoal do cliente

Alterar dados da ltima atividade

de treinamento do cliente

Cancelar
compra

Validar dados da
ficha pessoal

Validar dados da
ficha de biometria

[ dados invlidos ]

Validar dados da atividade

de treinamento

Informar dados da atividade de

treinamento do cliente

[ dados vlidos ]

[ dados invlidos ]

Validar dados da
atividade de treinamento

Cadastrar ficha
de biometria

[ dados vlidos ]

[ dados invlidos ]
[ dados invlidos ]

Cadastrar atividade de
treinamento

[ dados vlidos ]
[ dados vlidos ]

Alterar ficha
pessoal

Alterar ltima atividade de

treinamento

: Usurio

Sistema

: Funcionario

Sistema

: Usurio

: Usurio

Sistema

Sistema

Selecionar opo Acessar ficha

de acompanhamento de cliente

Selecionar opo Gerar

grficos de desempenho

Selecionar opo Alterar

ltima ficha de biometria

: Usurio

Sistema

Selecionar opo Acessar ficha

de acompanhamento de cliente

Selecionar opo Gerar

grficos de desempenho
[ usuario = cliente ]

[ usuario = cliente ]

[ no existe ficha pessoal

cadastrada OU no existe ficha
de biometria cadastrada ]

[ usuario = funcionario ]

[ usuario = cliente ]

Apresentar formulrio para

seleo do cliente

[ usurio = funcionario ]

[ usuario = funcionario ]

[ existe ]
Retornar dados da ltima
ficha de biometria

Selecionar cliente
desejado

Selecionar cliente
desejado

Alterar dados da ltima ficha

de biometria do cliente

Selecionar cliente
desejado

Apresentar opes que compem a

ficha de acompanhamento

Apresentar opes de
grficos existentes

Selecionar opo
Ficha de biometria

Validar dados da
ficha de biometria

[ no existem atividades de treinamento cadastradas para este cliente ]

Selecionar opo Grfico de
evoluo de carga por atividade

[ usuario = cliente ]

Apresentar formulrio para

seleo do cliente

[ usurio = funcionario ]

Apresentar formulrio para

seleo do cliente

Apresentar formulrio para

seleo do cliente

Apresentar opes de
grficos existentes

Apresentar todas as biometrias

cadastradas deste cliente

Selecionar cliente
desejado

Selecionar opo
atividades de treinamento

Apresentar opes que compem a

ficha de acompanhamento

Apresentar todas as atividades de

treinamento cadastradas deste cliente

[ no existem biometrias cadastradas para este cliente ]

[ existe ]

Selecionar opo Grfico de

evoluo da taxa de gordura

[ dados invlidos ]

Selecionar uma das

biometrias apresentadas

[ existem ]

[ no existem biometrias cadastradas para este cliente ]

Mostrar
grfico(s)

[ existe ]

Selecionar uma das atividades

de treinamento apresentadas

[ dados vlidos ]

[ existe ]

[ no existem atividades de treinamento cadastradas para este cliente ]

Alterar ltima ficha

de biometria

Mostrar dados da
ficha de biometria

Mostrar grfico

Mostrar dados da
atividade de treinamento

: Funcionario

: Funcionario

Sistema

Selecionar opo
Alterar fornecedor

Sistema

Selecionar opo
Criar fornecedor

Apresentar formulrio para

criao do fornecedor

: Funcionario

Sistema

Selecionar opo
Alterar funcionrio

Retornar dados do
funcionrio

: Funcionario

: Funcionario

Sistema

Selecionar opo
Criar novo funcionrio

Apresentar formulrio para

criao do novo funcionrio

Informar dados do
novo funcionrio

Validar dados
do funcionrio

Sistema

Acessar sistema da Academia

Desportiva Gym-Joe

Apresentar tela solicitando

identificao do tipo de usurio

[ no existe fornecedor cadastrado ]

[ existe ]
Retorna dados
do fornecedor

Informar dados
do fornecedor

Validar dados
do fornecedor

Selecionar
funcionrio

Alterar dados
do funcionrio

[ dados invlidos ]
Alterar dados
do fornecedor

Validar dados
do funcionrio

Apresentar formulrio de
autenticao

[ dados invlidos ]
Validar dados da
autenticao

Informar cdigo e
senha

Validar dados
do fornecedor

[ dados vlidos ]

[ dados invlidos ]

[ dados vlidos ]

[ dados invlidos ]

Cadastrar
fornecedor

[ dados invlidos ]

Alterar
funcionrio

[ dados vlidos ]
[ dados vlidos ]

[ dados vlidos ]

Cadastrar
funcionrio

Alterar
fornecedor

: Funcionario

Sistema

: Funcionario

Sistema

Selecionar opo
Efetuar compra

: Funcionario

Sistema

Selecionar opo
Cadastrar oramento

Selecionar opo Alterar

ltimo oramento

Recuperar
fornecedores

: Funcionario

Sistema

Selecionar opo Emitir

pedido de compra

Apresentar formulrio para

insero do pedido de compra

[ no existe oramento cadastrado ]

Retornar
oramentos

Funcionario

[ no existe fornecedor cadastrado ]

Informar dados do
pedido de compra

[ existe ]
Retornar dados do ltimo
oramento

Informar dados
do oramento

Validar dados do
pedido de compra

Validar dados
do oramento

Escolher
oramento

[ dados vlidos ]

[ existe fornecedor ]

[ dados invlidos ]

[ dados invlidos ]
Alterar atributo escolhido do
oramento

Alterar status do
pedido de compra

Efetuar compra

Alterar dados do
ltimo oramento

Recuperar
fornecedores

Validar dados
do oramento

[ dados vlidos ]

Sistema

Selecionar opo
Classificar fornecedor

Apresentar formulrio para

cadastro de oramento

[ no existe oramento cadastrado ]

[ existe ]

Liberar aceso
ao funcionrio

Retorna dados
do fornecedor

Cadastrar pedido de
compra

Cadastrar
oramento

[ dados invlidos ]

[ dados vlidos ]
Alterar ltimo
oramento

Figura 79 Rastreamento dos artefatos ligados ao conceito Funcionrio.

Classificar
fornecedor

Calcular
classificao

95

Iam(Funcionrio,C- Funcionrio) = 0,1 x 1 x 0,5 = 0,05;

Iam (Funcionrio,UC-CriarFuncionrio) = 0,1 x 1 x 1 = 0,1;
Iam (Funcionrio,UC-AlterarFuncionrio) = 0,1 x 1 x 1 = 0,1;
Iam (Funcionrio,UC-CriarFornecedor) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-AlterarFornecedor) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-ClassificarFornecedor) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-CadastrarOramento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-AlterarUltimoOramento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-CancelarCompra) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-EfetuarCompra) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-EmitirPedidoCompra) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-CriarFichaPessoal) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-AlterarFichaPessoal) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-AcessarFichaPessoal) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-CriarFichaBiometria) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-AlterarUltimaFichaBiometria) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-AcessarFichaBiometria) = = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-CriarAtividadeTreinamento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-AlterarUltimaAtividadeTreinamento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-AcessarAtividadeTreinamento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-GerarGrficoPeso) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-GerarGrficoTaxaGordura) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-GerarGrficoCargaAtividade) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,UC-AutenticarFuncionrio) = 0,1 x 1 x 1 = 0,1;
Iam (Funcionrio,UC-GerarMensalidade) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-CriarFuncionrio) = 0,1 x 1 x 1 = 0,1;
Iam (Funcionrio,DA-AlterarFuncionrio) = 0,1 x 1 x 1 = 0,1;
Iam (Funcionrio,DA-CriarFornecedor) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-AlterarFornecedor) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-ClassificarFornecedor) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-CadastrarOramento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-AlterarUltimoOramento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-CancelarCompra) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-EfetuarCompra) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-EmitirPedidoCompra) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-CriarFichaPessoal) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-AlterarFichaPessoal) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-AcessarFichaPessoal) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-CriarFichaBiometria) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-AlterarUltimaFichaBiometria) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-AcessarFichaBiometria) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-CriarAtividadeTreinamento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-AlterarUltimaAtividadeTreinamento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-AcessarAtividadeTreinamento) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-GerarGrficoPeso) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-GerarGrficoTaxaGordura) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-GerarGrficoCargaAtividade) = 0,1 x 0,3 x 1 = 0,03;
Iam (Funcionrio,DA-AutenticarFuncionrio) = 0,1 x 1 x 1 = 0,1;
Iam (Funcionrio,DA-GerarMensalidade) = 0,1 x 0,3 x 1 = 0,03;
Figura 80 Clculos dos artefatos ligados ao conceito Funcionrio.

96
4.6.4 Listar e Calcular a Probabilidade dos Artefatos

O ltimo passo somar os valores obtidos ao calcular o impacto de cada artefato

rastreado list-los em ordem decrescente. A tabela VII mostra a probabilidade de impacto.
Tabela VII Probabilidade de impacto dos artefatos rastreados.

Artefato

Probabilidade
acumulada (Pa(y))

C-FichaBiomtrica
UC-GerarMensalidade
DA-GerarMensalidade
C-Mensalidade
UC-CriarFichaBiometria
UC-AlterarUltimaFichaBiometria
DA-CriarFichaBiometria
DA-AlterarUltimaFichaBiometria
UC-AcessarFichaBiometria
DA-AcessarFichaBiometria
UC-CriarFichaPessoal
UC-AlterarFichaPessoal
UC-AcessarFichaPessoal
UC-AutenticarCliente
DA-CriarFichaPessoal
DA-AlterarFichaPessoal
DA-AcessarFichaPessoal
DA-AutenticarCliente
UC-CriarFuncionrio
UC-AlterarFuncionrio
UC-AutenticarFuncionrio
DA-AutenticarFuncionrio
UC-CriarAtividadeTreinamento
UC-AlterarUltimaAtividadeTreinamento
UC-AcessarAtividadeTreinamento
UC-GerarGrficoPeso
UC-GerarGrficoTaxaGordura
UC-GerarGrficoCargaAtividade
DA-CriarAtividadeTreinamento
DA-AlterarUltimaAtividadeTreinamento
DA-AcessarAtividadeTreinamento
C-Cliente
C-Funcionrio
UC-CriarFornecedor
UC-AlterarFornecedor
UC-ClassificarFornecedor
UC-CadastrarOramento
UC-AlterarUltimoOramento
UC-CancelarCompra
UC-EfetuarCompra
UC-EmitirPedidoCompra
DA-CriarFuncionrio
DA-AlterarFuncionrio
DA-CriarFornecedor
DA-AlterarFornecedor
DA-ClassificarFornecedor
DA-CadastrarOramento
DA-AlterarUltimoOramento
DA-CancelarCompra
DA-EfetuarCompra
DA-EmitirPedidoCompra

1,80
1,41
1,41
1,35
0,58
0,58
0,58
0,58
0,58
0,58
0,13
0,13
0,13
0,13
0,13
0,13
0,13
0,10
0,10
0,10
0,10
0,10
0,06
0,06
0,06
0,06
0,06
0,06
0,06
0,06
0,06
0,05
0,05
0,03
0,03
0,03
0,03
0,03
0,03
0,03
0,03
0,03
0,03
0,03
0,03
0,03
0,03
0,03
0,03
0,03
0,03

Percentual de probabilidade de impacto (Ppi(y)) %

100,00
78,34
78,34
75,00
32,22
32,22
32,22
32,22
32,33
32,22
7,22
7,22
7,22
7,22
7,22
7,22
7,22
5,56
5,56
5,56
5,56
5,56
3,33
3,33
3,33
3,33
3,33
3,33
3,33
3,33
3,33
2,78
2,78
1,67
1,67
1,67
1,67
1,67
1,67
1,67
1,67
1,67
1,67
1,67
1,67
1,67
1,67
1,67
1,67
1,67
1,67

97
Na tabela VII foram destacados os artefatos que tem maior probabilidade de impacto. Esse conjunto de artefatos com maior probabilidade de impacto formado por aqueles
que tiverem a Probabilidade acumulada (Pa(y)) maior do que a mdia ponderada calculada
para todos os elementos rastreados. A figura 81 apresenta sua aplicao nesse exemplo.

1 1,8 2 1,41 1 1,35 6 0,58 7 0,13 5 0,1 9 0,06 2 0,05 18 0,03

1 2 1 6 7 5 9 2 18

0,23

Figura 81 Clculo da mdia ponderada.

Nota-se que a classe FichaBiomtrica, que atingiu o maior impacto acumulado

foi considerada como o artefato que com certeza seria impactado, isto , probabilidade de
100%. A probabilidade dos demais artefatos foi calculada dentro dessa escala. Os resultados
aqui apresentados podem ser verificados no experimento constante no Apndice A, onde se
comprova que os objetos mais atingidos esto entre os identificados pela metodologia de anlise de impacto baseada em ontologia.
Para o sistema IsGym, no possvel aplicar a influncia do relacionamento entre
conceitos, pois com o uso do algoritmo de radicalizao, todos os relacionamentos entre conceitos so baixos. Nesse quesito, o sistema deveria ter sido desenvolvido com maior preocupao na denominao dos conceitos.

98

99

VALIDAO DA METODOLOGIA

Esse captulo apresenta a validao da proposta de metodologia de anlise de impacto baseada na rastreabilidade ontolgica. Para realiz-la, foi utilizada a Engenharia de
Software Experimental.
Igualmente ao primeiro experimento realizado, que auxiliou na definio dessa
proposta, o sistema de software utilizado no experimento de validao da metodologia o
IsGym. Este amplamente apresentado no Apndice A. Foram utilizados tambm os mesmos
requisitos de mudana usados no primeiro experimento, mostrados nas figuras 98 e 99. Isso
foi possvel, pois os participantes de um e outro experimento so diferentes.
importante destacar que esse experimento, no que diz respeito ao sistema de
software utilizado, bem como alguns pontos do planejamento e seleo de participantes foi
feito em conjunto ao experimento de validao da proposta de rastreabilidade ontolgica
[NOL05b]. Sendo assim, algumas caractersticas de ambos os experimentos sero as mesmas
ou semelhantes. A seguir, sero apresentados os passos necessrios para se construir e validar
um experimento, como consta no referencial terico desse trabalho.

5.1

DEFINIO

Para estabelecer os objetivos desse estudo, foi utilizada a tcnica GQM proposta
por Basili [BAS94]. Nessa etapa, necessrio apresentar as questes que sero avaliadas e as
mtricas que sero utilizadas para medi-las.

100
5.1.1 Objetivo Global

Avaliar a preciso da anlise de impacto baseada na rastreabilidade indexada por

conceitos da ontologia com relao proposta de anlise de impacto baseada na rastreabilidade indexada por requisitos [ONE03].

5.1.2 Objetivo do Estudo

Comparar a metodologia de anlise de impacto baseada em rastreabilidade indexada por conceitos e por requisitos,
Com o propsito de caracterizar, com base em um requisito de mudana, a de
probabilidade de alterao de artefatos e o conjunto de artefatos realmente modificados,
Com foco na preciso,
Sob o ponto de vista do analista de software,
No contexto de manuteno de um sistema de informao no domnio de academia desportiva, desenvolvido por estudantes durante uma disciplina da Faculdade de Informtica da PUCRS.

5.1.3 Objetivo da Medio

Qual a preciso, indicada pela interseco entre o conjunto de artefatos previstos

para alterao e os realmente alterados, das abordagens de anlise de impacto baseada em
ontologias e baseada em requisitos.

101
5.1.4 Questo

A preciso do conjunto dos artefatos com maior probabilidade de impacto encontrada atravs da anlise de impacto baseada na rastreabilidade atravs de requisitos igual a
preciso do conjunto dos artefatos com maior probabilidade de impacto encontrada atravs da
anlise de impacto baseada na rastreabilidade ontolgica?

5.1.5 Mtricas

A mtrica utilizada para responder a questo estabelecida corresponde preciso

de cada uma das abordagens, com relao completude e corretude das previses de alterao
de artefatos em relao aos artefatos que foram realmente modificados. Por preciso, nesse
experimento, considera-se a razo entre o conjunto de artefatos previstos e modificados e o
conjunto total de artefatos previstos e modificados. O conjunto de artefatos previstos e modificados composto pelo conjunto dos artefatos com maior probabilidade de impacto, estabelecidos atravs da aplicao de cada uma das metodologias de anlise de impacto, interseccionados com o conjunto dos artefatos realmente modificados. O conjunto total de artefatos
previstos ou modificados composto por de todos os artefatos que tiveram previso de impacto, e por todos os artefatos que foram realmente modificados. O clculo da preciso est representado na frmula 14.
P

qtdArtefatos Pb
qtdArtefatos Pb

M
M

Frmula 14 Clculo da varivel Preciso.

Onde:
M: Conjunto de artefatos modificados;
Pb: Conjunto de artefatos previstos por determinada metodologia de anlise de
impacto;
qtdArtefatos(): funo que recupera a quantidade de artefatos do conjunto.

102
5.2

PLANEJAMENTO

O projeto do experimento determinado, a instrumentao considerada e os aspectos da validade do experimento so avaliados. Realiza-se a seleo do contexto, formulamse as hipteses, selecionam-se as variveis e os participantes, projeta-se o experimento, realiza-se a preparao conceitual da instrumentao e considera-se a validade do experimento.

5.2.1 Seleo do Contexto

Para a conduo do experimento de anlise de impacto, foi escolhido o contexto

de uma universidade e no de um ambiente realista, pois esse mais arriscado e envolve custos no previstos nesse experimento. Tambm fazem parte do contexto:
a) Processo: ser utilizada abordagem In-vitro, na qual o conjunto de participantes executar o experimento em um ambiente controlado. Este experimento
no se dar durante o desenvolvimento de software industrial, isto , ele ser
off-line;
b) Participantes: o experimento ser conduzido por alunos de graduao e psgraduao da Faculdade de Informtica da PUCRS;
c) Realidade: o problema estudado ser de sala de aula (toy example) e corresponde a um sistema modelado e desenvolvido por alunos da graduao, durante uma disciplina da Faculdade de Informtica da PUCRS, no domnio de uma
academia desportiva. O objetivo desta escolha a utilizao de um sistema
que se aproxime do real e que foi desenvolvido sem a interveno do pesquisador;
d) Generalidade: o experimento especfico e com validade apenas no escopo do
presente estudo.

103
5.2.2 Formulao das Hipteses

Para o experimento, foi definida informalmente a hiptese:

Sugere-se que a anlise de impacto baseada na rastreabilidade por requisitos
prev o mesmo conjunto de artefatos que a anlise de impacto baseada por
conceitos de uma ontologia, com relao ao conjunto realmente modificado.
A formalizao das hipteses e a definio de suas medidas se do por:
Hiptese Nula, H0: A preciso na previso de artefatos impactados por uma
mudana obtidos pela anlise de impacto baseada na rastreabilidade por requisitos igual a anlise de impacto baseada na rastreabilidade por conceitos da
ontologia.
a. Medidas: A preciso ser avaliada pela relao entre o conjunto de
artefatos modificados e que tinham sido previstos e o conjunto de
unio dos artefatos que foram previstos ou modificados, onde:
i. Pair: Preciso associada anlise de impacto baseada na rastreabilidade por requisitos;
ii. Paic: Preciso associada anlise de impacto baseada na rastreabilidade por conceitos da ontologia;
b. H0: Pair = Paic
c. Hiptese Alternativa, H1: A preciso na previso dos artefatos obtidos pela anlise de impacto baseada na rastreabilidade por requisitos maior do que a da anlise de impacto baseada na rastreabilidade por conceitos da ontologia.
H1: Pair >Paic
d. Hiptese Alternativa, H2: A preciso na previso dos artefatos obtidos pela anlise de impacto baseada na rastreabilidade por conceitos da ontologia maior do que a da anlise de impacto baseada na
rastreabilidade por requisitos.
H2: Paic > Pair

104
5.2.3 Seleo das Variveis

As variveis independentes servem como entrada para o experimento, enquanto as

dependentes se referem sada.

5.2.3.1 Varivel Independente

Assumiram-se como variveis independentes:

a) Experincia do time de manuteno;
b) Metodologia de anlise de impacto.

5.2.3.2 Varivel Dependente

Assume-se como varivel dependente:

a) Preciso atravs da relao entre os conjuntos de artefatos previstos e modificados e do total de artefatos previstos ou modificados.

Experincia do time de manuteno

Metodologia de anlise de impacto

Variveis Independentes

Processo

Preciso

Variveis Dependentes

Figura 82 Variveis independentes e dependentes do estudo experimental.

105
5.2.4 Seleo dos Indivduos

A populao definida para o experimento formada por alunos do curso de graduao e ps-graduao da Faculdade de Informtica da PUCRS, totalizando doze alunos.
No ser utilizada uma amostragem probabilstica para seleo dos indivduos,
mas sim uma amostragem no probabilstica:
a) Amostragem por convenincia: sero escolhidas as pessoas mais convenientes
para o experimento.

5.2.5 Projeto do Experimento

Caracteriza a forma de conduo do experimento, decidindo, por exemplo, a alocao dos participantes.

5.2.5.1 Princpios Genricos de Projetos

Dentre os princpios genricos para o projeto do experimento, caracteriza-se:

a) Aleatoriedade: a aleatoriedade ser utilizada para definir quais participantes
iro executar cada metodologia de anlise de impacto (baseada na rastreabilidade atravs de requisito ou conceito);
b) Obstruo: durante a experimentao, muitos dos participantes no possuem o
mesmo nvel de experincia acadmica e profissional. Para minimizar o efeito
da experincia sobre o experimento, os indivduos foram selecionados utilizando o critrio de quota e convenincia;
c) Balanceamento: este princpio ser utilizado no experimento para que cada
proposta de anlise de impacto seja executada pela mesma quantidade de participantes.

106
5.2.5.2 Padro para Tipo de Projeto

Para a hiptese que ser validada, sero utilizadas as seguintes notaes:

air

Anlise de impacto baseada na rastreabilidade por requisitos;

aic

Anlise de impacto baseada na rastreabilidade por conceitos.

Esse experimento investiga se a preciso de air igual a preciso de aic. A abordagem conhecida como um fator com dois tratamentos. Nesse caso, o fator refere-se ao time
de manuteno, ou seja, aos participantes do experimento e os tratamentos so as metodologias de anlise de impacto que esto sendo comparadas, a baseada em rastreabilidade por requisitos e por conceitos.
Optou-se por conduzir o projeto do experimento, no que diz respeito a execuo
desse, utilizando uma abordagem completamente aleatria para escolha de quais participantes
iriam executar uma ou outra metodologia. Essa deciso foi tomada, pois se cada participante
fizesse uso das duas metodologias, os resultados quando a segunda metodologia fosse utilizada seriam prejudicados, uma vez que a pessoa j teria um conhecimento prvio do sistema e
do requisito de mudana que estaria sendo proposto. A tabela VIII, chamada de tabela de contingncia, mostra com os fatores (participantes) foram divididos para executar os dois tratamentos (metodologias).
Tabela VIII Tabela de contingncia.
#Participante aic air
1
X
2
X
3
X
4
X
5
X
6
X
7
X
8
X
9
X
10
X
11
X
12
X
11
X
12
X

Para verificar a hiptese, alguns testes de significncia so sugeridos na literatura.

O Teste T usado para realizar um teste paramtrico com duas amostras independentes. J o

107
teste Mann-Whitney usado caso o teste seja no-paramtrico. Dependendo da normalidade e
varincia dos dados obtidos na execuo, ser escolhido um ou outro teste.

5.2.6 Instrumentao

Para realizar o experimento, ser utilizado:

a) Objetos: a descrio do sistema de informao IsGym, sua modelagem UML
do diagrama de classes de projeto, a descrio dos casos de uso e o Modelo de
Domnio, alm de dois requisitos de mudana. Para auxiliar na anlise de impacto, ser fornecida para cada abordagem uma planilha onde devero se determinadas as variveis usadas para calcular o conjunto de artefatos com maior
probabilidade de impacto para cada metodologia, e serem informados os artefatos que foram modificados;
b) Guias: ser fornecido um treinamento para os participantes, apresentando as
duas metodologias de anlise de impacto, o contexto do experimento e a motivao da equipe. Tambm ser fornecido um tutorial sobre como proceder durante o experimento;
c) Mtricas: Os dados sero recuperados atravs da planilha preenchida pelos
participantes e das alteraes feitas diretamente no diagrama de classes do sistema, utilizando para isso a ferramenta ArgoUML.

5.2.7 Anlise da Validade

Os resultados devem ser vlidos para a populao a qual os participantes fazem

parte. So definidas as validades interna, externa, construo e concluso.

108
5.2.7.1 Validade Interna

Sero avaliados alguns critrios, tais como:

a) Histrico: a data de aplicao do experimento ser criteriosamente definida,
evitando perodos nos quais os participantes possam sofrer influncias externas;
b) Maturao: durante o treinamento, sero utilizadas tcnicas de motivao para
incentivar positivamente os participantes;
c) Seleo dos grupos: ser utilizada uma abordagem para nivelar o conhecimento dos participantes atravs de um treinamento sobre as metodologias. A execuo das atividades ser individual;
d) Difuso: durante o treinamento, ser desenvolvida uma motivao que no incentive interao entre os participantes. Adicionalmente, haver um policiamento durante a experimentao para evitar este tipo de interao.

5.2.7.2 Validade Externa

Para esta avaliao, ser adotada a interao da seleo, ou seja, os participantes

que foram selecionados possuem um perfil apto aos tratamentos do experimento, apresentando, em sua maioria, conhecimento prvio sobre processo de desenvolvimento de software e
modelagem de sistemas, alm de experincia em indstria.

5.2.7.3 Validade de Construo

Durante o experimento, sero avaliados:

a) Inadequada explicao pr-operacional: consiste na explicao operacional
do experimento, visando mostrar como a metodologia aplicada;
b) Adivinhao de hipteses: devido ao fato dos participantes serem humanos,
possvel sua interao com o experimento, sugerindo novas hipteses e exercitando a criatividade. importante manter o foco no estudo planejado;

109
c) Expectativas do condutor do experimento: ao se conduzir um experimento, o
responsvel pode exercer influncias sobre as variveis envolvidas e sobre o
material elaborado. Durante a presente proposta, todo o material utilizado ser
previamente avaliado por outro responsvel.

5.2.7.4 Validade de Concluso

A validade de concluso segue as perspectivas:

a) Manipulao dos dados: como os dados resultantes do experimento sero manipulados pelo pesquisador, possvel que os mesmos sofram algumas variaes, tal como o coeficiente de significncia para validao dos resultados;
b) Confiabilidade das medidas: sugere que medidas subjetivas possam ser influenciadas pelo pesquisador. Essa perspectiva ser minimizada j que as medidas foram definidas sem dependncia do critrio humano;
c) Confiabilidade na implementao dos tratamentos: consiste no risco em que
diferentes participantes possam implementar de forma distinta os processos estabelecidos pelo experimento. Este risco no ser evitado, uma vez que a determinao das variveis das metodologias de anlise de impacto comparadas
subjetiva e dependente da interpretao de cada participante no experimento,
assim como a modelagem de cada requisito de mudana propostos. Com isso,
os participantes podero prever e modificar artefatos diferentes;
d) Configuraes do ambiente do experimento: consiste nas interferncias externas do ambiente que podem influenciar os resultados durante a execuo do
experimento. O experimento ser executado em um laboratrio isolado, onde
ser proibida a interao externa como celulares, sadas, etc.;
e) Heterogeneidade aleatria dos participantes: a escolha de diferentes participantes com diferentes experincias pode exercer um risco na variao dos resultados.

110
5.3

EXECUO

Os dados so coletados e feita a validao preliminar destes.

5.3.1 Preparao

Foram analisadas algumas caractersticas intrnsecas execuo:

a) Consenso com o experimento: se os participantes no concordam com os objetivos da pesquisa ou no tem conhecimento sobre o experimento, corre-se o
risco de que sua participao no ocorra em encontro aos objetivos. Durante a
experimentao, a preparao dos participantes dever fornecer o embasamento necessrio sobre o experimento, clarificando quais os objetivos e metas almejadas;
b) Resultados sensitivos: possvel que o resultado obtido pelo experimento se
influencie por questes pessoais, como a sensibilidade dos participantes por
estarem sendo avaliados. Ser adotada uma postura de anonimato dos participantes em toda a descrio da experimentao.
O primeiro passo para execuo do experimento foi a apresentao de um treinamento especfico para cada grupo, demonstrando cada uma das metodologias de anlise de
impacto. Nesse mesmo momento, foram explanados os objetivos, a tcnica, a motivao e o
procedimento tcnico para conduo do experimento. Aps, os participantes receberam a instrumentao prevista, fazendo parte dessa um tutorial contendo o passo-a-passo para a execuo das atividades. Os participantes do experimento foram responsveis pela coleta dos dados,
preenchendo a planilha que foi disponibilizada. Todo esse material est presente no Apndice
B.

111
5.3.2 Execuo

A execuo do experimento para cada metodologia foi feita em turnos diferentes,

sem tempo determinado para o trmino das atividades. O pesquisador esteve presente durante
toda a durao do experimento a fim de para conduzi-lo, ficando a disposio para esclarecimento de eventuais dvidas, embora sem interferncia nos dados que estavam sendo coletados.
Em ambas as metodologias, a base a rastreabilidade dos artefatos, seja atravs de
casos de uso ou de conceitos da ontologia. Dessa forma, para cada uma delas foi fornecido o
gabarito da rastreabilidade, ou seja, para a metodologia de anlise de impacto baseada na rastreabilidade por requisitos, foram disponibilizadas todas as classes que se associam a um caso
de uso. Para a metodologia de anlise de impacto baseada na rastreabilidade por conceitos,
foram fornecidas as classes indexadas por conceitos. A partir dessas informaes e, aps o
entendimento do requisito de mudana proposto, os participantes foram capazes de identificar
a qual caso de uso ou conceito o requisito de mudana se referia. Aps foi possvel determinar
os valores das variveis necessrias para cada metodologia, obtendo assim o conjunto de artefatos com maior probabilidade de impacto. O ltimo passo era realizar efetivamente a manuteno no diagrama de classes.

5.4

ANLISE E INTERPRETAO

Primeiramente devem ser analisadas as escalas das variveis, a fim de determinar

a as operaes que podem ser realizas em cada uma delas. A tabela IX apresenta essas escalas.
Tabela IX Escalas das variveis.
Variveis
Nome
Escala
Dependentes Preciso
Razo
Independentes Metodologia de Anlise de Impacto Nominal

112
5.4.1 Anlise Tabular e Grfica

O experimento obteve como resultado os dados apresentados na tabela X, onde os

participantes que realizaram a metodologia de anlise de impacto baseada em ontologia foram
representados por C0x e o que utilizaram a metodologia baseada em requisitos foram classificados por R0x. Para cada requisito de mudana proposto e alterado pelo participante foi
calculada a Preciso, atravs da frmula 14. O valor apresentado na tabela X corresponde a
mdia da Preciso obtida por cada participante, em relao aos requisitos de mudanas propostos.
Tabela X Tabulao dos valores brutos obtidos aps a execuo do experimento.
Abordagem
Participante Preciso
Anlise de Impacto por Conceitos
C01
1,00
Anlise de Impacto por Conceitos
C02
1,00
Anlise de Impacto por Conceitos
C03
1,00
Anlise de Impacto por Conceitos
C04
0,75
Anlise de Impacto por Conceitos
C05
0,25
Anlise de Impacto por Conceitos
C06
0,50
Anlise de Impacto por Requisitos
R01
0,13
Anlise de Impacto por Requisitos
R02
0,35
Anlise de Impacto por Requisitos
R03
0,32
Anlise de Impacto por Requisitos
R04
0,42
Anlise de Impacto por Requisitos
R05
0,25
Anlise de Impacto por Requisitos
R06
0,23

A figura 83 representa o grfico de barras com a preciso dos artefatos que tiveram a anlise de impacto determinada e que foram modificados pelos participantes.
1,20

Preciso

1,00
0,80
0,60
0,40
0,20
0,00
R01 R02 R03 R04 R05 R06 C01 C02 C03 C04 C05 C06
Participante

Figura 83 Grfico de barras relativo preciso dos artefatos.

113
5.4.2 Estatstica Descritiva

A varivel preciso est caracterizada na escala razo. Isso permite o clculo da

normalidade e homocedasticidade, necessria para definir o tipo de teste das hipteses (paramtrico ou no-paramtrico). Conforme definido no projeto do experimento, o padro para
tipo de teste previsto o Teste T para duas amostras independentes, caso o teste empregado
seja paramtrico, ou Mann-Whitney, caso seja no paramtrico.
Para avaliar a preciso, os dados tabulados durante o experimento sero caracterizados com o objetivo de visualizar tendncias centrais e disperses. Os dados que forem determinados como anormais ou incertos devem ser eliminados atravs da reduo do intervalo
de dados, pois esses distorcem a integridade da concluso do experimento. Por ltimo, ser
realizado o teste das hipteses que compreende a avaliao estatstica dos dados at certo nvel de significncia. O nvel de significncia adotado (p-value) para todos os testes de 5%.
O p-value compreende o menor nvel de significncia com que se pode rejeitar a hiptese nula.

5.4.3 Hiptese: Preciso

Para iniciar a validao da hiptese, verificada a distribuio dos dados coletados. Para isso, gerado o grfico de disperso boxplot para a identificao dos outliers. A
figura 84 apresenta o grfico.

114

1,00

0,80

Precisao

0,60

0,40

0,20

0,00

Conc

Req

Abordagem

Figura 84 Grfico de disperso para a varivel preciso.

Como verificado na figura 84, a varivel preciso possui outliers moderados, sendo assim, nenhum participante ser extrado da amostra, j que no h risco de haver distoro. Pode-se notar no grfico, previamente, que a disperso maior quando utilizada a anlise
de impacto baseada na rastreabilidade por conceitos, embora a mediana da varivel preciso
esteja perto de 100%. Os resultados para a anlise de impacto baseada na rastreabilidade por
requisitos so mais uniformes, mas menos precisos.
A prxima etapa consiste em identificar se os dados seguem uma distribuio
normal. Para se avaliar a normalidade, definida uma hiptese nula e uma hiptese alternativa, conforme:
a) H0: a distribuio normal;
b) H1: a distribuio no normal.
Existem duas formas para se avaliar a distribuio normal dos dados, que compreendem o Teste de Kolmogorov-Smirnov e o Teste de Shapiro-Wilk. O primeiro utilizado para
identificar a normalidade em variveis com pelo menos 30 valores e o segundo em variveis
com menos de 50 valores. A tabela XI apresenta os testes de normalidades para a amostra
utilizando o Teste de Shapiro-Wilk.
Tabela XI Teste de normalidade Shapiro-Wilk para a varivel preciso.
Varivel

Abordagem
Estatstica Grau de Liberdade Significncia
0,831
6
0,110
Anlise de Impacto por Conceitos
Preciso
0,984
6
0,970
Anlise de Impacto por Requisitos

115
Com base na tabela XI, observa-se que a significncia dos dados do Teste de Shapiro-Wilk superior, em ambas as amostras (anlise de impacto baseada na rastreabilidade
por conceito e anlise de impacto baseada na rastreabilidade por conceito), ao nvel de significncia definido (0,05 ou 5%). Com esta informao, no h indcios para rejeitar a hiptese
nula sobre a distribuio da normalidade, conseguindo assim o primeiro requisito para utilizao de teste paramtrico para duas amostras independentes.
O segundo requisito requer a anlise da homocedasticidade, tornando necessrio
analisar a varincia das duas amostras. Com este objetivo, definem-se duas hipteses:
a) H0: As varincias so iguais;
b) H1: As varincias no so iguais.
O teste da hiptese acima realizado com a significncia obtida diretamente atravs do Teste de Levene. Este usado para testar se k amostras tm a mesma varincia. A tabela XII apresenta os resultados obtidos para este teste.
Tabela XII Teste de Levene para igualdade das varincias sobre a varivel preciso.
Significncia
Assumindo varincias iguais
Preciso
No assumindo varincias iguais

0,032

Com base na tabela XII, verifica-se que o nvel de significncia para varincias
iguais (0,032) inferior ao nvel de significncia definido (0,05 ou 5%). Com esta informao, pode-se rejeitar a hiptese nula para varincias, no sendo mais possvel utilizar o teste
paramtrico. O prximo passo utilizar o Teste de Mann-Whitney, para duas amostras independentes, por se tratar de uma alternativa no-paramtrica para o Teste T.
O Teste de Mann-Whitney para duas amostras independentes utilizado para
comprovar se as diferenas entre as mdias observadas nos dois grupos independentes so
estatisticamente significativas. Com base na declarao das hipteses, sugere-se:
a) H0: No h diferena entre as mdias (air = aic);
b) H1: H diferena entre as mdias (air aic).
Os resultados da aplicao do teste esto na tabela XIII.
Tabela XIII Teste no paramtrico de Mann-Whitney para a varivel preciso.
Z
Sig. Assimpt. (bilateral) Sig. Exata [2*(Sig.Unilateral)]
U de Mann-Withney W de Wilcoxon
0,019
Preciso
3,500
24,500
-2,342
0,015a
(a) No corrigidos para os empates

116
Como o grau de significao associado (Sig. Assimpt.) 0,019 e menor que a
significncia assumida de 0,05, deve-se rejeitar H0. Com a rejeio desta, comprova-se a hiptese H1, que afirma que h diferena entre as mdias, ou seja, existe diferena de mdia entre
a anlise de impacto baseada na rastreabilidade por conceitos e na anlise de impacto baseada
na rastreabilidade por requisitos.
Pela anlise estatstica dos dados, consegue-se recuperar duas informaes:
a) A distribuio da preciso no normal, o que implica na execuo de testes
no paramtricos;
b) Utilizando o Teste de Mann-Whitney, conseguiu-se verificar que existem diferenas entre as mdias das duas amostras air e aic.
Utilizando o Teste de Mann-Whitney, conseguiu-se apenas rejeitar a hiptese nula,
porm no foi possvel validar as hipteses alternativas, pois no possvel extrair relaes de
maior do que com o teste aplicado. Porm, sugere-se comparar a anlise descritiva das mdias da amostra, conforme a tabela XIV.
Tabela XIV Estatstica descritiva para a varivel preciso.
Abordagem
Mdia
Anlise de Impacto por Requisitos 0,281
Anlise de Impacto por Conceitos 0,750

Observando as mdias da varivel preciso para cada uma das metodologias, pode-se verificar que, em mdia, a preciso da anlise de impacto por conceitos maior do que a
preciso da anlise de impacto por requisitos.

5.5

AVALIAO QUALITATIVA

Atravs do experimento foi possvel avaliar quantitativamente as metodologias de

anlise de impacto. Para realizar a anlise qualitativa, os participantes responderam um questionrio ao trmino de suas atividades, conforme apresentado ao final desse apndice. Como
critrio de resposta, foi utilizada a escala Likert que possui cinco pontos para o grau de satisfao, O objetivo de usar essa pesquisa de opinio era conhecer a percepo dos participantes
quanto a usabilidade, utilidade e esforo para usar as diferentes metodologias.

117
As cinco questes propostas podem ser verificadas no Apndice B. Os dados brutos obtidos como resultados esto apresentados na tabela XV, onde o participante identificado
como R0x referente a abordagem de anlise de impacto baseada na rastreabilidade por
requisitos e o participante C0x referente a abordagem ontolgica.
Tabela XV Resultados da avaliao qualitativa.
Participante Q1 Q2 Q3 Q4 Q5
R01
3 3 2 3 2
R02
3 3 4 2 3
R03
3 3 2 2 2
R04
2 3 2 4 2
R05
3 3 4 3 3
R06
4 3 4 4 3
C01
4 5 4 3 4
C02
4 5 4 4 4
C03
4 4 3 4 5
C04
3 4 2 3 3
C05
5 5 4 4 5
C06
4 4 3 4 4

A mdia aritmtica para cada uma das questes apresentada na tabela XVI.
Tabela XVI Mdia da satisfao das questes sobre as abordagens.
Abordagem
Q1 Q2 Q3 Q4 Q5
Anlise de Impacto por Requisitos 3,0 3,0 3,0 3,0 2,5
Anlise de Impacto por Conceitos 4,0 4,5 3,3 3,7 4,2

Comparando-se as mdias obtidas para cada uma das abordagens, pode-se perceber que as mdias obtidas pela metodologia de anlise de impacto baseada na rastreabilidade
por conceitos foi maior para todas as questes. Verifica-se ento que qualitativamente essa
metodologia melhor do que a metodologia de anlise de impacto por requisitos, para esse
conjunto de participantes.

5.6

CONSIDERAES

Neste captulo foram apresentadas as avaliaes quantitativas, atravs do uso da

Engenharia de Software Experimental, e qualitativa, atravs de uma pesquisa de opinio. A
inteno era comparar as metodologias de anlise de impacto baseada por conceitos e por
requisitos, sendo esta ltima proposta por ONeal [ONE03].

118
O experimento fez uso da rastreabilidade ontolgica, que est inserida dentro de
um processo de desenvolvimento especfico, o que no possibilita que essa experimentao
seja generalizvel a outros processos. Quanto ao contexto, foi analisado o impacto dos requisitos de mudana somente nas classes de projetos e as modificaes foram solicitadas apenas
no diagrama de classes. Decidiu-se restringir o experimento por questes de tempo para execuo e escolheu-se esse artefato por representar as alteraes estruturais no sistema.
Com os dados fornecidos pelos participantes, foi possvel avaliar a varivel preciso, a partir da qual seria feita a comparao das metodologias. Com a anlise inicial da varivel, percebeu-se que essa no apresentou uma distribuio normal das suas mdias. Por esse
motivo, usou-se o teste Mann-Whitney para avaliar as hipteses. Esse teste comprova se as
diferenas entre as mdias observadas em dois grupos independentes so estatisticamente significativas, mas no estabelece se um grupo superior ao outro. Uma vez que a aplicao do
teste comprovou que as mdias eram diferentes, foi necessrio utilizar a anlise descritiva das
mdias de cada metodologia e compar-las. Assim, verificou-se que a metodologia de anlise
de impacto baseada na rastreabilidade por conceitos tem uma preciso maior na determinao
do conjunto de artefatos que sero impactados.
A ltima fase da experimentao a Apresentao e Empacotamento do que foi
realizado no experimento para que esse possa ser repetido. Sendo assim, interessante a repetio deste para outros artefatos de software, tais como a descrio dos casos de uso, diagramas de atividades, de seqncia, ou quaisquer outros que se considerar relevante. A varivel
de preciso poder ser analisada em outros contextos, possibilitando um maior conhecimento
de como a metodologia de anlise de impacto baseada na rastreabilidade por conceitos se
comporta em universos distintos de projetos de manuteno e de participantes.

119

CONCLUSO E TRABALHOS FUTUROS

O objetivo dessa pesquisa era desenvolver uma metodologia de anlise de impacto

que fosse capaz de determinar com maior preciso os artefatos impactados por um requisito
de mudana. Para tanto, buscou-se utilizar um tipo de rastreabilidade de artefatos que fizesse
uso de semntica para tal. Isso porque se inferiu que a assertividade dos elementos rastreados
que seriam afetados por uma alterao fosse maior. Encontrou-se ento, na pesquisa que vinha
sendo realizada por Noll[NOL05b], a integrao de ontologias ao processo de desenvolvimento de software, onde uma das principais vantagens a possibilidade de rastreamento dos artefatos.
Com essa realidade, decidiu-se propor uma metodologia de anlise de impacto baseada na rastreabilidade atravs de ontologias. Para isso foi preciso conhecer como uma ontologia estruturada, quais so seus elementos e como estes se relacionam. Igualmente foi necessrio buscar na literatura outras propostas de anlise de impacto, com a finalidade de encontrar os pontos fortes e fracos dessas, procurando determinar exatamente onde o uso da
rastreabilidade semntica seria vantajoso.
Aps o estudo desses e outros assuntos, iniciou-se o trabalho em direo a construo e estruturao da metodologia. Observou-se que no existiam na literatura trabalhos
correlacionados que relacionassem modificaes nos conceitos da ontologia a alteraes sofridas por artefatos produzidos ao longo do desenvolvimento de software. Assim, foi necessrio realizar um experimento exploratrio para que se conhecesse como alteraes na ontologia
se refletiriam nos artefatos relacionados aos seus conceitos.
Ao analisar os resultados do experimento, foi possvel determinar algumas influncias, referentes a tipos de mudana e de relacionamento entre conceitos da ontologia. Percebeu-se que a mudana pode ser estrutural ou relacionada a regras de negcio e que cada
uma delas afeta diferentemente os artefatos que so rastreados, dependendo da classificao
do tipo de diagrama. Alm disso, pode-se notar que artefatos que no estavam diretamente
relacionados a um conceito poderiam ser afetados, uma vez que os conceitos da ontologia se

120
relacionam e uma alterao em um deles pode comprometer, de alguma forma, os outros aos
quais est ligado. Para que o clculo das probabilidades de impacto nos artefatos pudesse ser
determinado, tem-se como premissa que essas variveis sejam informadas na ontologia do
sistema.
A primeira fase da metodologia analisar o requisito de mudana e, aps este ser
modelado conceitualmente, gerar uma ontologia referente a esse requisito. Dessa forma, as
duas ontologias, a do requisito de mudana e a do sistema, podem ser comparadas a fim de
identificar os conceitos comuns as duas e saber, estruturalmente, quais esto sendo afetados e
de que maneira. Com essas duas fases concludas, podem-se rastrear os artefatos que esto
relacionados aos conceitos que foram identificados. O ltimo passo calcular o impacto para
todos os artefatos que foram encontrados, determinando assim, o conjunto dos artefatos com
maior probabilidade de impacto.
Alm do uso de ontologias para determinar o impacto de um requisito de mudana, outra contribuio dessa proposta foi o desenvolvimento da ferramenta ONTImpact. Com
ela possvel informar as influncias aos conceitos da ontologia, compar-las e realizar automaticamente os clculos necessrios, informando ao final os artefatos com maior probabilidade de serem modificados.
Alguns trabalhos futuros podem ser propostos para solucionar certas limitaes
dessa metodologia. Um deles pesquisar a possibilidade de se identificar, tambm automaticamente, as alteraes de regras de negcio, uma vez que hoje o usurio deve inform-la. Outro item que pode ser melhorado inserir o uso de tesauros, realizando uma anlise semntica
dos conceitos e no morfossinttica como feita atravs de algoritmos de radicalizao de
palavras. Visando a evoluo da metodologia, futuramente pode ser estudada uma forma de,
utilizando as disciplinas de anlise de impacto e rastreabilidade, garantir que a ontologia original do sistema em manuteno seja atualizada aps a execuo do requisito de mudana
solicitado. Seria interessante tambm que essa metodologia, e sua ferramenta, fossem aplicadas em uma empresa, com um sistema efetivamente em manuteno. Desta forma, poderia-se
estabelecer o uso real e prtico do que foi proposto neste trabalho.
No que se refere as mudanas na estrutura da ontologia, deveriam ser analisadas
as excluses de conceitos e relacionamentos. Provavelmente, essas mudanas tambm exerceriam influncia em artefatos relacionados a esses conceitos ou em outros a eles relacionados.
Quanto a ferramenta, suas funcionalidades poderiam ser adicionadas ao aplicativo
ONTrace, proposto por Noll[NOL05b], j que as pesquisas de rastreabilidade ontolgica, feita
por ele, e a de anlise de impacto, constante nesse trabalho, esto integradas. Dessa forma, o

121
usurio que queira calcular o impacto de uma mudana poderia realizar todas suas atividades
em um s sistema.

122

123

REFERNCIAS

[AJI95] AJILA, S. Software maintenance: an approach to impact analysis of objects

change. Software: practice and experience, v. 25, n.10, p. 1155-1181, Oct. 1995.
[BAS94] BASILI, V. R, CALDIERA, G., ROMBACH, D. H. The Goal Question Metric
Approach. Encyclopedia of Software Engineering - 2 Volume Set, pp 528-532, Copyright by
John Wiley & Sons, Inc., 1994.
[BAS96] BASILI, V. R. The role of experimentation in software engineering: past, current and future. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, ICSE, 18.,1996, Berlin. Proceedings... Berlin: Springer-Verlag, c1996.
[BOE01] BOEHM, B. et al. The Cocomo 2.0 software cost estimation model. Estados Unidos, 2001. Disponvel em: <http://www.softwareengineer.org/>. Acesso em: 15/04/2005
[BOH96] BOHNER, S.; ARNOLD, R. Software change impact analysis. Los Alamitos,
Calif.: IEEE Computer Society, c1996. 376 p.
[BRO87] BROOKS, F. P. No silver bullet: essence and accidents of software engineering.
Computer, v. 20, n. 4, p. 10-19, Apr. 1987.
[CAS04] CASTOR, A. P. Rastreamento de requisitos no processo de desenvolvimento de
software orientado a agentes. 2004. 128 f. Dissertao (Mestrado em Cincia da Computao) - Centro de Informtica, Universidade Federal de Pernambuco, Recife, 2004.
[CAR02] CARBONE, M; SANTUCCI, G. Fast&&Serious: a UML based metric for effort
estimation. 2002. Trabalho apresentado na 16 European Conference on Object-Oriented
Programming - ECOOP, Mlaga, 2002.
[CAN05] CARNEIRO, R. E; BRITO, P. F. Definio de uma ontologia em OWL para representao de contedos educacionais. Trabalho apresentado no 7 Encontro de Estudantes
de Informtica do Tocantins - ECOINFO, Palmas, 2005.
[CHI94] CHIDAMBER, S; KEMERER, C. A metrics suite for object oriented design.
IEEE Transactions on Software Engineering, v. 20, n. 6, p. 476-493, June 1994.
[COR03] CORRA, A. C. G. Recuperao de documentos baseada em informao semntica no ambiente AMMO. 2003. 93 f. Dissertao (Mestrado em Cincia da Computao) - Centro de Cincias Exatas e de Tecnologia, Universidade Federal de So Carlos, So
Carlos, 2003.

124
[DIA04] DIAS, M. A. L. Extrao automtica de palavras-chave na lngua portuguesa
aplicada a dissertaes e teses da rea das engenharias. 2004. 138 f. Dissertao (Mestrado em Engenharia Eltrica) - Faculdade de Engenharia Eltrica e de Computao, Universidade Estadual de Campinas, Campinas, 2004.
[FAY85] FAY, D. S.; HOLME, G. D. Help! I have to update an undocumented program.
In: CONFERENCE ON SOFTWARE MAINTENANCE, Proceedings... Washington, D.C.:
IEEE Computer Society Press, c1985. p. 194-202.
[FEL03] FELICSSIMO, C. H. et al. Gerao de ontologias subsidiada pela engenharia de
requisitos. In: INTERNATIONAL WORKSHOP ON REQUIREMENTS ENGINEERING WER, 6., 2003, Piracicaba. Proceedings... Piracicaba: [s.n.], 2003.
[FEN00] FENSEL, D. Ontologies: a silver bullet for knowledge management and electronic commerce. Berlin: Springer, 2001. 138 p.
[FET00] FENTON, N; NEIL, M. Software metrics: roadmap. In: CONFERENCE ON THE
FUTURE OF SOFTWARE ENGINEERING - ICSE, 2000, Limerick, Ireland. Proceedings...
New York: ACM Press, 2000. p. 357-370.
[GEL04] GELLER, J.; PERL, Y.; LEE, J. Ontology challenges: a thumbnail historical
perspective. Knowledge and Information Systems, v. 6, n. 4, p. 375-379, July 2004.
[GEN03] GENERO, M., MIRANDA, D.; PIATTINI, M. Defining metrics for UML statechart diagrams in a methodological way. In: CONCEPTUAL modeling for novel application domains. Berlin: Springer, c2003. p. 118-128. (Lecture Notes in Computer Science,
2814).
[GOM01] GOMES, P.; BENTO, C. A case similarity metric for software reuse and design.
AI EDAM, v. 15, n. 1, p. 21-35, Jan. 2001.
[GON03] GONZALEZ, M.; LIMA, V. L. S. Recuperao de informao e processamento
da linguagem natural. In: JORNADA DE MINI-CURSOS DE INTELIGNCIA ARTIFICIAL, 3., 2003, Campinas. Campinas: SBC, 2003. v. 3, p. 347-395. Realizada no 23 Congresso da Sociedade Brasileira de Computao.
[GOT94] GOTEL, O.C.Z.; FINKELSTEIN, C.W. An analysis of the requirements traceability problem. In: INTERNATIONAL CONFERENCE ON REQUIREMENTS ENGINEERING, 1., 1994. Proceedings.... Los Alamitos, Calif.: IEEE Computer Society Press,
1994. p. 94-101.
[GRU93] GRUBER, T. R. A translation approach to portable ontology specifications.
Knowledge Acquisition, v. 5, n. 2, p. 199-220, 1993.
[IEE98] INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS. Standard for
software maintenance: IEEE std 1219. New York, 1998. 52 p.
[JAV06] JAVA. Java Technology. Estados
<http://java.sun.com/>. Acesso em: 14/10/2006

Unidos,

2006.

Disponvel

em:

[JEN06] JENA. A Semantic Web Framework for Java. Estados Unidos, 2006. Disponvel
em: <http://jena.sourceforge.net/>. Acesso em: 22/10/2006

125
[KOG02] KOGUT, P. et al. UML for ontology development. The Knowledge Engineering
Review, v. 17, n. 1, p. 61-64, 2002.
[KIM02] KIM, H.; BOLDYREFF, C. Developing software metrics applicable to UML
models, 2002. Trabalho apresentado na 16 European Conference on Object-Oriented Programming - ECOOP, Mlaga, 2002.
[LOR94] LORENZ, M.; KIDD, J. Object-oriented software metrics: a practical guide. Englewood Cliffs, N.J.: Prentice Hall, 1994.
[MAR98] MARCHESI, M. OOA metrics for the unified modeling language. In: EUROMICRO CONFERENCE ON SOFTWARE MAINTENANCE AND REENGINEERING, 2.,
1998, Florence. Proceedings...,1998. p. 67-73.
[MIL99] MILLS, E. E. Metrics in the software engineering curriculum. Annals of Software
Engineering, v. 6 n. 1-4, p. 181-200, 1998.
[MQU06] McQUILLAN, J. A.; POWER, J. F. Some observations on the application of software metrics to UML models. In: ACM/IEEE INTERNATIONAL CONFERENCE ON
MODEL DRIVEN ENGINEERING LANGUAGES AND SYSTEMS - MoDELS, 9., 2006,
Genova. Proceedings...
[NOL05a] NOLL, R. Ontologias no processo de desenvolvimento de software. Trabalho
individual I, Instituto de Informtica, Pontifcia Universidade Catlica do Rio Grande do Sul,
Porto Alegre, 2005.
[NOL05b] NOLL, R. Integrao de ontologias no processo de desenvolvimento de software. Projeto de estudo e pesquisa. Instituto de Informtica, Pontifcia Universidade Catlica
do Rio Grande do Sul, Porto Alegre, 2005.
[NOL05c] NOLL, R. Integrao de ontologias no processo de desenvolvimento de software. Trabalho individual II, Instituto de Informtica, Pontifcia Universidade Catlica do Rio
Grande do Sul, Porto Alegre, 2005.
[ONE03] ONEAL, J. S. Analyzing the impact of changing software requirements: a traceability-based methodology. 2003. Tese de Doutorado - Faculty of the Louisiana State University, 2003.
[OLI01] OLIVEIRA, D. V. JDBC Java Database Connectivity. Videira: Universidade do
Oeste de Santa Catarina, 2001. p.1-6.
[PAL03] PALO, M. Requirements traceability. Helsinki: University of Helsinki, Department of Computer Science, 2003. 10p. Seminar report.
[PEA96] PEARSON, J. K. Requirements, traceability and formal software development
or a further analysis of requirement traceability. 1996.
[PRE95] PRESSMAN, R. S. Engenharia de software. So Paulo: Makron Books, 1995.
1056 p.

126
[PIN02] PINTO, M. B.; SACCOL, D. B. Uso de ontologias na definio de esquemas para
banco de dados semi-estruturados. Trabalho apresentado na 3 Jornada de Iniciao Cientfica do CEULP, 2002.
[RAM01] RAMESH, B.; JARKE, M. Toward reference models for requirements traceability.
IEEE Transactions on Software Engineering, v. 27, n. 1, p. 58-93, Jan. 2001.
[SCH99] SCHACH, S. R. Object-oriented and classical software engineering. WCB,
McGraw Hill, 1999.
[SAL68] SALTON, G. Automatic information organization and retrieval. New York:
McGraw-Hill, c1968. 514 p. (Computer Science Series).
[SCO04] SCOTTO, M. et al. A relational approach to software metrics. In: ACM SYMPOSIUM ON APPLIED COMPUTING, 2004, Nicosia, Cyprus. Proceedings... New York:
ACM Press, 2004. p. 1536-1540.
[SOM03] SOMMERVILLE, I. Software engineering. Addison-Wesley, 2003.
[TOR99] TORANZO, M.; CASTRO, J. A. Comprehensive traceability model to support
the design of interactive systems. In: WISDOM99 - INTERNATIONAL WORKSHOP ON
INTERACTIVE SYSTEM DEVELOPMENT AND OBJECT MODELS, 1999, Lisboa. Proceedings... 1999. p. 1-20.
[TRA02] TRAVASSOS, G. H.; GUROV, D.; AMARAL, E. A. G. do. Introduo engenharia de software experimental. Rio de Janeiro: COPPE/UFRJ, 2002. 52 p. (RT-ES590/02).
[WMS04] WORKSHOP DE MANUTENO DE SOFTWARE MODERNA - WMSWM,
1., 2004, Braslia. Anais eletrnicos... Disponvel em: <http://www.ucb.br/ucbtic/wmswm04/>. Acesso em: 17 jul. 2006.
[WOH00] Wohlin, C. et al. Experimentation in software engineering: an introduction. Boston: Kluwer Academic, 2000. 204 p.

127

APNDICE A RESULTADOS DO EXPERIMENTO

Neste apndice apresentado o experimento realizado com o objetivo de mapear

as alteraes ocorridas na ontologia do sistema, a partir de alguns requisitos de mudana para
este. Para realiz-lo, foi usado um projeto pr-existente, desenvolvido por alunos do curso de
Sistemas de Informao da Faculdade de Informtica da PUCRS, para se obter os resultados.
Esse projeto denominado IsGym e tem como objetivo integrar todas as funcionalidades administrativas de uma academia de ginstica em um nico sistema de informao. Nele, so
executadas funes como manter cadastro de clientes, funcionrios, fornecedores, recursos e
utilizao destes, assim como as fichas de acompanhamento das avaliaes (biometria) e atividades dos alunos.
Esse projeto foi escolhido por duas caractersticas principais. A primeira possuir
uma rica documentao sobre a modelagem do sistema, seguindo a metodologia RUP e utilizando os principais diagramas indicados por esta. A segunda por ter sido desenvolvido sem
a inteno de ser aplicado nesse experimento, o que garante que seus dados no foram manipulados para algum resultado especfico.
O negcio do sistema foi amplamente estudado, usando para esse fim modelos
como Casos de Uso de Negcio, Atividades de Negcio, Interao de Negcio e Objetos de
Negcio. A modelagem do ambiente foi feita para os contextos Efetuar Compra, Criar Ficha
de Acompanhamento de Cliente e Gerar Grfico de Desempenho. Como exemplo, as figuras
85, 86, 87 e 88 mostram, respectivamente, os modelos citados, para o segundo contexto.

Recepcao

Criar conta

Figura 85 Modelo de caso de uso de negcio para o contexto Criar Ficha de Acompanhamento de Cliente.

128

: Recepcao

: Fisioterapeuta

: Instrutor

Coleta dados pessoais

do aluno

Solicita exame
biomtrico

Realiza biometria no
aluno

Solicita avaliao do
exame biomtrico

Avalia exame
biomtrico

[ no apto ]

[ apto a realizar atividades ]

Presta informaes
ao aluno

Gera atividade
de treinamento

Figura 86 Modelo de atividades de negcio para o contexto Criar Ficha de Acompanhamento de Cliente.

: Recepcao

: Fisioterapeuta

: Instrutor

Solicita exame biomtrico

Exame biomtrico completo

Solicita avaliao do exame biomtrico

Avalia exame e gera atividade de treinamento do aluno

Figura 87 Modelo de interao de negcio para o contexto Criar Ficha de Acompanhamento de Cliente.

EntidadeBiometria

EntidadeCliente

EntidadeTreinamento

Fisioterapeuta

Recepcao

Instrutor

Figura 88 Modelo de objetos de negcio para o contexto Criar Ficha de Acompanhamento de Cliente.

129
Aps anlise detalhada do problema, foi modelado o diagrama de casos de uso,
que mostrado na figura 89. Com ele, podem-se verificar quais so as funes do sistema. De
acordo com esse diagrama, foram criadas as descries detalhadas dos casos de uso, dos diagramas de atividades, de modelo de classe de anlise e de colaborao em anlise pra cada um
deles. Como exemplo, as figuras 90, 91, 92 e 93 mostram esses diagramas para o caso de uso
CriarFichaPessoal. Com relao a fase de projeto, os diagramas construdos foram os de seqncia e de classes, apresentados nas figuras 94 e 95, respectivamente. Finalizando a modelagem do projeto, os diagramas de componentes e de implantao foram definidos. A ferramenta Rational Rose foi utilizada para modelar os diagramas e os modelos presentes na documentao do projeto. Aps a modelagem, o sistema foi desenvolvido utilizando a tecnologia JSP e usando banco de dados MS-Access.

AcessarAtividadeTreinamento

EmitirPedidoCom pra
AcompanharDesem penho
AcessarFi chaBiometri a

AcessarFi chaPessoal

GerarMensal idade

GerarGraficoTaxaGordura

AcessarFi chaDeAcompanhamento de
Cli ente

AlterarFuncionario

AutenticarUsuari o

ManterFuncionario
Usuari o
Cri arFuncionario
GerarGraficoCargaPorAti vi dadeGerarGraficoPeso
GerarGraficosDesempenho
AlterarFornecedor
Cli ente
Funcionario

Cri arFichaPessoal

AlterarUltimaFichaBiometria

ManterFornecedor

Cri arFornecedor

ManterFichaAcompanhamentoCl iente
EfetuarCompra

AlterarUltimaAtividadeTreinam ento Cri arFichaBiometria

AlterarFichaPessoal

Cri arAtividadeTrei namento

CancelarCompra

CadastrarOramento

AlterarUltimoOramento

Figura 89 Diagrama de casos de uso do sistema IsGym.

130
Identificao
UC3.
Caso de Uso
Manter ficha de acompanhamento de cliente.
Ator
Funcionrio.
Pr-Condio
Funcionrio estar autenticado no sistema.
Ps-Condio
Ficha pessoal criada.
Cenrio
Criar ficha pessoal
3.3.1. Criar ficha pessoal
Seqncia tpica de eventos
Ao do ator
Resposta do sistema
1
Este caso de uso comea
quando o Funcionrio seleciona
a opo Criar ficha pessoal na
seo Manter ficha de
acompanhamento de cliente do
sistema.
2
Sistema apresenta formulrio
para criao da ficha pessoal.
3
Funcionrio informa nome, CPF,
endereo, telefone, cidade,
estado (uf) e cdigo de acesso e
senha de acesso do novo cliente.
4
Sistema verifica se nome, CPF,
endereo, cidade, estado (uf),
cdigo de acesso e senha de
acesso so nulos, se CPF so
numricos no negativo e se
CPF e cdigo de acesso j
existem no cadastro de fichas
pessoais do sistema.
5
Sistema cadastra ficha pessoal
com status ativa e confirma
criao da ficha pessoal do
cliente.
Seqncia alternativa de eventos
4a Se nome, CPF, endereo, cidade, estado (uf), cdigo de acesso ou senha
de acesso so nulos, ou se CPF no numrico, ou se CPF um
numrico negativo, ou se CPF ou cdigo de acesso j existem no cadastro
de fichas pessoais do sistema: volta para 3.

Figura 90 Descrio do caso de uso Criar Ficha Pessoal.

: Funcionario

Sistema

Selecionar opo
Criar ficha pessoal

Apresentar formulrio para

criao da ficha pessoal

Informar dados da ficha

pessoal do novo cliente

Validar dados da
ficha pessoal

[ dados invlidos ]

[ dados vlidos ]
Cadastrar ficha
pessoal

Figura 91 Diagrama de atividades Criar Ficha Pessoal.

131

InterfaceSistema

Funcionario

ControleCriarFichaPessoal

EntidadeCliente

Figura 92 Modelo de classe de anlise Criar Ficha Pessoal.

6: validarDados(nome,CPF,endereco,cidade,uf,codigo,senha)

1: selecionar(criarFichaPessoal)
4: informarDados(nome,CPF,endereco,telefone,cidade,uf,codigo,senha)

2: apresentar(formulario)
5: cadastrar(nome,CPF,endereco,telefone,cidade,uf,codigo,senha)

3: apresentar formulrio
: InterfaceSistema

: Funcionario

: ControleCriarFichaPessoal

7: existe(CPF,codigo)
9: cadastrar(nome,CPF,endereco,telefone,cidade,uf,codigo,senha,status="ativa")

8: retorna existncia de CPF e cdigo

: EntidadeCliente

Figura 93 Modelo de colaborao em anlise Criar Ficha Pessoal.

: InterfaceSistema

:
ControleCriarFichaPessoal

: Funcionario

: EntidadeCliente

selecionar(criarFichaPessoal)
apresentar(formulario)
apresentar formulrio

informarDados(nome,CPF,endereco,telefone,cidade,uf,codigo,senha)
cadastrar(nome,CPF,endereco,telefone,cidade,uf,codigo,senha)

validarDados(nome,CPF,endereco,cidade,uf,codigo,senha)

existe(CPF,codigo)

retorna existncia de CPF e cdigo

cadastrar(nome,CPF,endereco,telefone,cidade,uf,codigo,senha,status="ativa")

Figura 94 Modelo de sequencia Criar Ficha Pessoal.

132

Figura 95 Diagrama de classes do sistema IsGym.

Para aplicao do experimento foi escolhida a turma de Desenvolvimento de Sistemas Inteligentes do Programa de Ps-Graduao em Cincia da Computao da PUCRS. A
execuo do experimento foi planejada em duas fases. Na primeira, as reas de anlise de
impacto e rastreabilidade semntica foram abordadas, numa aula explanatria sobre os assuntos. Nesse mesmo momento, a turma foi dividida em nove duplas e cada aluno respondeu um
questionrio para traar o perfil dos participantes, que pode ser verificado na figura 96. Tambm foi explicado como o experimento seria conduzido, mostrando o que seria disponibiliza-

133
do e o que se exigiria como entrega. Para realizao das tarefas, foi dado um prazo de duas
semanas.

Figura 96 Resultado do questionrio aplicado para conhecer o perfil dos alunos.

Com a anlise dos dados dos alunos que responderam ao questionrio, verifica-se
que a maioria tem experincia acadmica, sendo que a taxa de quem no tem experincia em
modelagem, implementao e projetos de manuteno semelhante a taxa daqueles que tem
bastante experincia, sendo que muito poucos conheciam o assunto de rastreabilidade. Era
interessante ter conhecimento dessas informaes para ter-se uma noo da dificuldade, ou
no, de realizar uma mudana na aplicao. Alem dessas informaes, foi solicitado que os
alunos classificassem seus conhecimentos nas metodologias e ferramentas usadas no experimento. Quanto ontologias, a turma ainda no possua nenhum conhecimento nesse assunto,
mas isso no foi impeditivo para a realizao do experimento, no que diz respeito a anlise de
impacto da mudana, pois esta estava sendo usada somente para realizar a rastreabilidade dos
artefatos com o uso da ferramenta ONTrace, fazendo parte da pesquisa e experimentao de
Noll[NOL05c].
Para atingir a finalidade do experimento, alguns materiais foram fornecidos para
os alunos. Dentre eles estavam a documentao completa do sistema, contendo os diagramas
j citados e a descrio detalhada do negcio; o arquivo com a modelagem reproduzida no
ArgoUML, uma vez que nessa ferramenta que o ONTrace est integrado e neste software
que a ontologia do sistema pode ser gerada; o cdigo fonte e a base de dados, alm dos requisitos de mudana. Os documentos de entrega do experimento esperados eram um relatrio das

134
alteraes feitas, representando o conjunto de artefatos impactados, reproduzido na figura 97,
o arquivo com a modelagem modificada, o cdigo fonte e banco de dados alterados.

Figura 97 Exemplo de preenchimento do relatrio de conjunto de impacto.

O relatrio de conjunto de impacto presente na figura 94 est preenchido com dados fictcios para demonstrar seu preenchimento. A finalidade era conhecer que tipo de raciocnio foi utilizado para encontrar os artefatos impactados, j que no foi sugerido o uso de
uma metodologia para tal. Os artefatos que foram selecionados para serem analisados so os
listados abaixo:
a) Modelo de Domnio: era interessante analisar alguma alterao nesse diagrama, j que a ontologia gerada a partir dele;
b) Diagrama de Caso de Uso: foi selecionado pois a alterao poderia ser realizada modelando um novo caso de uso;
c) Descrio de Caso de Uso: uma vez que foram propostas alteraes nas regras
de negcio, essas deveriam ser informadas na descrio do caso de uso;
d) Diagrama de Atividades: com a alterao de regras de negcio, provavelmente
novas atividades seriam necessrias na modelagem anteriormente existente;
e) Diagrama de Classes: analisado para verificar se houve mudana de tipo de atributo, incluso de novo atributo ou classe;
f) Banco de Dados: embora as alteraes no banco de dados no possam ser rastreadas pela ferramenta ONTrace, era interessantes saber como as alteraes
se refletiam nele;
g) Cdigo Fonte: tambm no possvel rastrear o trecho do cdigo onde deve
ser feita a alterao, mas era necessrio saber se as alteraes feitas na modelagem seriam refletidas neste. Alm disso, quando no se utiliza uma metodo-

135
logia de rastreabilidade, artefatos que precisam ser alterados podem ser descobertos somente quando o cdigo alterado.
Outras duas informaes constantes no relatrio so: o tipo de mudana que estava sendo feita e a classificao do artefato. A primeira refere-se incluso, excluso ou alterao de elementos dos diagramas ou do cdigo. A segunda informao foi baseada na proposta de Bohner[BOH02], que separa os artefatos em conjuntos diferentes a medida que esses
so encontrados. No caso, tentou-se perceber quais artefatos foram rastreados primeiramente e
desses, quais realmente foram impactados (Im:Impactado), quais no foram impactados
(NI:No Impactado) e os que foram encontrados depois (N:Novo), possivelmente quando o
cdigo fonte estava sendo alterado.
Com finalidades distintas, foram criados trs requisitos de mudana. O primeiro
deles foi citado no capitulo 4 e j foi amplamente abordado. O segundo requisito de mudana
visava modificar a semntica e o range de conceitos da ontologia. O terceiro requisito alterava
uma regra de negcio. As figuras 98 e 99 apresentam, respectivamente, essas solicitaes.
Visando ter uma carta de fornecedores confiveis, a GymJoe decidiu classificar seus fornecedores
pela qualidade do item vendido ao invs de classificar pelo prazo de entrega. Esta deciso foi tomada, pois
mesmo havendo atraso de alguns fornecedores, seus itens so superiores aos da concorrncia. Quando os itens
forem entregues, o funcionrio deve classific-los em: bom e ruim, no havendo mais nenhum outro critrio
vlido para classificao de fornecedores.
Figura 98 Requisito de mudana 2 para sistema IsGym.

136

Foi identificado um problema na promoo de descontos da mensalidade, j que a adeso foi muito
grande. Os clientes estavam determinando objetivos fceis de serem atingidos. Consequentemente, o nmero
de clientes com desconto mximo cresceu consideravelmente. Para que isso no ocorra, o sistema deve calcular, a partir do peso, altura, sexo e idade do cliente, a taxa de gordura ideal que deve ser atingida. Se o objetivo for atingido, ser concedido um desconto de 10%. Os critrios so:
Se o cliente est na faixa Excesso de gordura, o objetivo deve ser passar para faixa Moderado.
Se o cliente est na faixa Moderado, o objetivo deve ser passar para Ideal.
Se o cliente est na faixa Ideal, o objetivo deve ser permanecer nessa faixa.
Se o cliente est na faixa Baixo, o objetivo deve passar ser para faixa Ideal.
Se o cliente est na faixa Excepcionalmente baixo, o objetivo deve ser passar para faixa
Baixo.
Clculo da Taxa de Gordura:
Sexo = 1(homem); 0(mulher)
Imc = peso/((altura_m * 100 + altura_cm)/100)
igc = (1.2 * imc) + (0.23 * idade) - (10.8 * sexo) - 5.4;
Classificao
excepcionalmente baixo
baixo
ideal
moderado
excesso de gordura

Homens

Mulheres

6% a 10%
11% a 14%
15% a 18%
19% a 24%
maior que 25%

10% a 15%
16% a 19%
20% a 25%
26% a 29%
maior que 30%

Figura 99 Requisito de mudana 3 para sistema IsGym.

Com a anlise dos documentos entregues, percebeu-se que houve dificuldade em

usar a classificao de impacto do artefato proposta. Possivelmente um dos motivos para isso
ter ocorrido que o experimento no foi realizado presencialmente, o que impediu o esclarecimento de dvidas. Da mesma forma, a qualidade da informao do tipo de mudana que
estava sendo realizada no foi positiva, no permitindo uma anlise nesse sentido.
Sobre o raciocnio utilizado para encontrar os artefatos impactados, a tcnica mais
utilizada foi analisar os documentos de especificao do IsGym que foram entregue, verificando os diversos diagramas e modelos. Alguns grupos iniciaram a anlise diretamente pelo
cdigo fonte, procurando nele por palavras-chave retiradas do requisito de mudana e aps
mantendo a integridade na especificao.
Os artefatos impactados pelo requisito de mudana 1, esto na figura 100, os impactados pelo requisito de mudana 2 esto presentes na figura 101, e pelo requisito de mudana 3, na figura 103. Pode-se perceber que as alteraes no formam uniformes, pois sem o
uso de uma metodologia de anlise de impacto, que ir indicar os artefatos com maior probabilidade de serem afetados, as alteraes so bastante dependentes da interpretao de quem a
est desenvolvendo e do entendimento que se tem do negcio e da estrutura do sistema.

137

Figura 100 Artefatos impactados pelo requisito de mudana 1.

Figura 101 Artefatos impactados pelo requisito de mudana 2.

138

Figura 102 Artefatos impactados pelo requisito de mudana 3.

O experimento foi bastante til para identificar de que forma as alteraes se refletiriam na ontologia e a probabilidade de impacto que cada uma delas teria. Assim, foi possvel verificar que, quando se inclui um conceito ou esse alterado, a influncia da mudana
alta e que ela se nota estruturalmente na ontologia. Essa situao foi mais nitidamente verificada no requisito de mudana 2. Da mesma forma, quando regras de negcio so acrescentadas ou alteradas, casos dos requisitos de mudana 1 e 3, a influncia dessas sero igualmente
altas, mas mais fortemente nos diagramas dinmicos. Alm disso, foi possvel notar a influncia existente entre os relacionamentos dos conceitos, ou seja, quando artefatos so afetados,
mas de forma indireta.
Esse experimento teve carter exploratrio, no sendo utilizado para validar a metodologia. Os resultados obtidos a partir dele, serviram apenas de insumo para que essa fosse
estruturada.

139

APNDICE B INSTRUMENTAO DO EXPERIMENTO DE VALIDAO

Nesse apndice apresentado todo o material necessrio para conduo do experimento para validao da proposta. Primeiramente apresentado o material necessrio para
realizar o experimento na abordagem da anlise de impacto baseada na rastreabilidade ontolgica. Aps, o material para a anlise de impacto baseada na rastreabilidade por requisitos.
Por ltimo apresentado o questionrio, que comum s duas metodologias.

Anlise de Impacto baseada na rastreabilidade atravs de requisitos

Atividade #01: Criao dos modelos conceituais e realizar a anlise de impacto

1. Ler os requisitos de mudana propostos para o sistema IsGym (RequisitosMudanaIsGym.doc)
2. Fazer o modelo conceitual para cada requisito de mudana, no ArgoUML.
3. Comparar os modelos conceituais com o modelo de domnio do sistema (isGym.zargo)
4. Abrir a planilha (AIO.xls).
5. Para cada classe comum aos modelos conceitual e de domnio, informar qual o tipo de
alterao est sendo solicitado: estrutural (e suas subdivises) ou de regra de negcio.
6. Informar a influncia que o conceito exerce sobre o artefato.
7. Informar o valor da influncia do tipo de diagrama, dependendo do tipo de mudana.

Atividade #02: Realizar a alterao no diagrama de classes

1. Abrir o modelo isGym.zargo no ArgoUML.
2. Modelar as alteraes solicitadas nas classes necessrias.
3. Entregar a planilha AIO.xls e o modelo isGym.zargo.

Atividade #03: Responder ao questionrio

Figura 103 Tutorial fornecido para os participantes executarem a anlise de impacto ontolgica.

140

Figura 104 Planilha para preenchimento das variveis da metodologia de anlise de impacto ontolgica.

Anlise de Impacto baseada na rastreabilidade atravs de requisitos

Atividade #01: Definio das variveis que fazem parte da metodologia

8. Ler os requsitos de mudana propostos para o sistema IsGym (RequisitosMudanaIsGym.doc)
9. Identificar a quais requisitos (ou casos de uso) os requisitos de mudana se referem.
10. Abrir a planilha IAR.xls
11. Para cada artefato (classe) rastreado para o requisito, informar a influncia que o requisito exerce sobre ele.
12. Para cada artefato (classe), informar a complexidade, esforo e a fase na qual este se
encontra.

Atividade #02: Realizar a alterao no diagrama de classes

4. Abrir o modelo isGym.zargo no ArgoUML.
5. Modelar as alteraes solicitadas nas classes necessrias.
6. Entregar a planilha IAR.xls e o modelo isGym.zargo.

Atividade #03: Responder ao questionrio

Figura 105 Tutorial fornecido para os participantes executarem a anlise de impacto por requisitos.

141

Figura 106 Planilha para preenchimento das variveis da metodologia de anlise de impacto por requisitos.

Questionrio
Avaliao Qualitativa da Proposta de Anlise de Impacto

(1) Muito Ruim

Q1
Q2

(2) Ruim
(3) Regular
(4) Boa
(5) Muito Boa
Como voc considera a usabilidade desta tcnica de anlise de impacto?
Como voc considera a utilidade desta tcnica de anlise de impacto?

(1) Muito traba(2) Pouco traba(3) Regular

(4) Cmodo
(5) Muito Cmodo
lhoso
lhoso
Como voc considera o esforo para aprendizagem da tcnica?
Q3
Como voc considera o esforo para a definio das variveis necessrias para determinar o
Q4
impacto do artefato nessa metodologia?
(1) Discordo Plenamente
Q5

(3) No discordo nem

(5) Concordo
(4) Concordo
concordo
Plenamente
Voc usaria na prtica novamente esta metodologia de anlise de impacto?
(2) Discordo

Figura 107 Questionrio fornecido para os participantes.