TDRRC - Técnica para Documentação e Recuperação de Requisitos no Código-Fonte através do uso de... por Vinicius Miana Bezerra - Versão HTML

ATENÇÃO: Esta é apenas uma visualização em HTML e alguns elementos como links e números de página podem estar incorretos.
Faça o download do livro em PDF, ePub, Kindle para obter uma versão completa.

VINICIUS MIANA BEZERRA

TDRRC - TÉCNICA PARA DOCUMENTAÇÃO E

RECUPERAÇÃO DE REQUISITOS NO CÓDIGO-

FONTE ATRAVÉS DO USO DE ANOTAÇÕES

São Paulo

2011

VINICIUS MIANA BEZERRA

TDRRC - TÉCNICA PARA DOCUMENTAÇÃO E

RECUPERAÇÃO DE REQUISITOS NO CÓDIGO-

FONTE ATRAVÉS DO USO DE ANOTAÇÕES

Tese apresentada à Escola Politécnica da

Universidade de São Paulo para a obtenção do

título de Doutor em Engenharia

Área de Concentração:

Engenharia Elétrica

Orientadora:

Prof. Dr. Selma Shin Shimizu Melnikoff

São Paulo

2011

index-3_1.png

Dedico este trabalho a Natalia e ao

Felipe por me fazerem lembrar o que é

importante.

AGRADECIMENTOS

À minha orientadora, Prof. Dr. Selma Shin Shimizu Melnikoff, pela oportunidade

concedida de realizar este trabalho, orientação, apoio e incentivo.

Ao meu orientador de mestrado, Prof. Dr. Kechi Hirama, por toda sua ajuda e apoio

para a realização deste trabalho, assim como pelos valiosos comentários realizados

durante a qualificação que contribuíram para a conclusão desta tese.

Ao Prof. Dr. João José Neto pela grande contribuição oferecida no exame de

qualificação, cujos comentários foram fundamentais para a conclusão desta tese.

Aos colegas professores e à Universidade Presbiteriana Mackenzie pelo incentivo,

em especial aos professores Dr. Vilmar Pedro Votre e Dr. Arnaldo Vallim.

À minha irmã pelo apoio sem o qual não poderia realizar este trabalho.

À minha esposa pela infinita paciência.

Aos amigos do curso pelas horas de estudo e lazer em conjunto.

E a todos que direta ou indiretamente, contribuíram para a realização deste trabalho.

RESUMO

Manter os documentos de requisitos atualizados e recuperar os requisitos de um

software são desafios enfrentados por desenvolvedores no seu dia a dia durante o

desenvolvimento, a manutenção e a evolução de sistemas. Embora existam técnicas

para gestão de requisitos, muitas vezes estas técnicas não são aplicadas, os

requisitos não são atualizados e a única fonte de informação confiável sobre um

software passa a ser seu código-fonte. Esta tese apresenta a TDRRC, uma técnica

para a documentação e recuperação dos requisitos no código-fonte usando

anotações. A TDRRC possibilita a reengenharia de requisitos sem que haja uma

interrupção no desenvolvimento e permite que os requisitos sejam documentados

em ambientes de desenvolvimento ágil. A TDRRC contribui para a redução dos

problemas relacionados à atualização dos requisitos, pois o desenvolvedor

responsável pelo programa passa a ser responsável pela documentação e

atualização dos requisitos no código-fonte que ele escreve e mantém. Este trabalho

apresenta também formas de aplicar a TDRRC na reengenharia de requisitos, em

métodos ágeis e na gestão de requisitos, assim como a sua aplicação em um estudo

de caso.

ABSTRACT

Keeping requirements documents updated and recovering requirements of a

software are common chal enges faced by developers on their day to day activities.

Although there are many requirements management techniques, usual y these

techniques are not applied, requirements are not updated and the only reliable

source of information about a software becomes its source code. This thesis

presents TDRRC, a technique that can be used to document and retrieve

requirements from the source code using annotations. Applying TDRRC, it is

possible to reengineer the requirements of a software without interrupting its

development. Also requirements can be documented in a agile environment. TDRRC

also contributes to minimize requirements documents update issues as the developer

wil be clearly responsible for documenting and updating the requirements in the

source code he is programming. This thesis also presents how to apply the technique

in a requirement reengineering project, in a agile development environment and in a

requirements management process. Final y a case study is presented.

LISTA DE ILUSTRAÇÕES

FIGURA 1 – METODOLOGIA UTILIZADA................................................................10

FIGURA 2 – EXEMPLO DE CASO DE USO..............................................................23

FIGURA 3 – ESTILOS DAS LINGUAGENS FORMAIS (HARRY, 1997)..................26

FIGURA 4 – META-MODELO DOS CASOS DE USO (RUI, 2007)...........................28

FIGURA 5 – MODELO CONCEITUAL DA ENGENHARIA REVERSA (CANFORA

ET AL., 2008)..............................................................................................................43

FIGURA 6 – MODELO DE GESTÃO DE MUDANÇAS (FAHMI ET AL., 2007)........46

FIGURA 7 – SINTAXE DOS TIPOS ANOTAÇÃO.....................................................55

FIGURA 8 – EXEMPLO DE DECLARAÇÃO DE UM TIPO ANOTAÇÃO.................56

FIGURA 9 – EXEMPLO DE DECLARAÇÃO DE TIPO DE ALVO............................57

FIGURA 10 – EXEMPLO DE DECLARAÇÃO DE TEMPO DE RETENÇÃO............57

FIGURA 11 – SINTAXE DA ANOTAÇÕES................................................................58

FIGURA 12 – EXEMPLO DE UMA ANOTAÇÃO.......................................................58

FIGURA 13 – CARDINALIDADE DE UMA ANOTAÇÃO..........................................59

FIGURA 14 – EXEMPLO DE UMA ANOTAÇÃO EM ELEMENTOS DE UM

PROGRAMA...............................................................................................................60

FIGURA 15 – EXEMPLO DE UMA ANOTAÇÃO EM UM PACOTE.........................61

FIGURA 16 – EXEMPLO DE PROCESSADOR DE ANOTAÇÕES..........................63

FIGURA 17 – VISÃO GERAL DA TDRRC.................................................................68

FIGURA 18 – EXEMPLO DE META-MODELO DE REQUISITOS............................72

FIGURA 19 – EXEMPLO DE TIPO ANOTAÇÃO DO META-MODELO....................73

FIGURA 20 – EXEMPLO DE PROCESSADOR DE ANOTAÇÕES..........................74

FIGURA 21 – EXEMPLO DE CÓDIGO-FONTE ANOTADO.....................................76

FIGURA 22 – META-MODELO DE CASOS DE USO APÓS REMOÇÃO DO NÍVEL

DE EVENTOS.............................................................................................................85

FIGURA 23 – META-MODELO DE CASOS DE USO APÓS REMOÇÃO DE ATOR,

OBJETIVO, TAREFA E USUÁRIO.............................................................................86

FIGURA 24 – META-MODELO DE CASOS DE USO ADAPTADO PARA A TDRRC

.....................................................................................................................................87

FIGURA 25 – EXEMPLO DE META-MODELO COM ASSOCIAÇÃO......................90

FIGURA 26 – TIPO ANOTAÇÃO MANTENDO ASSOCIAÇÃO DO META-MODELO

.....................................................................................................................................90

FIGURA 27 – ANOTAÇÕES COM REDUNDÂNCIA.................................................90

FIGURA 28 – TIPO ANOTAÇÃO SEM ASSOCIAÇÃO.............................................91

FIGURA 29 – ANOTAÇÕES SEM REDUNDÂNCIA..................................................91

FIGURA 30 – TIPO ANOTAÇÃO SERVIÇO..............................................................92

FIGURA 31 – TIPOS ANOTAÇÃO CONDIÇÃO E CONTEXTO...............................93

FIGURA 32 – TIPO ANOTAÇÃO EPISÓDIO.............................................................93

FIGURA 33 – PSEUDO CÓDIGO DA RECUPERAÇÃO DO MODELO DE

REQUISITOS..............................................................................................................96

FIGURA 34 – MODELO DE FAHMI ET AL. (2007) ADAPTADO PARA A TDRRC

...................................................................................................................................105

FIGURA 35 – VISÃO GERAL DOS MÓDULOS DO SGVD.....................................115

FIGURA 36 – PROCESSO DE DESENVOLVIMENTO COM APLICAÇÃO DA

TDRRC......................................................................................................................122

FIGURA 37 – DEMANDA DE REGISTRO DE EVENTOS PARA RENOVAÇÃO DE

DOMÍNIOS................................................................................................................125

FIGURA 38 – CASO DE USO REGISTRO DE DOMÍNIOS GERADO PELAS

ANOTAÇÕES............................................................................................................126

FIGURA 39 – CASOS DE USO DE COMPRA DE DOMÍNIOS GERADO PELAS

ANOTAÇÕES............................................................................................................127

FIGURA 40 – CASOS DE USO DE RENOVAÇÃO DE DOMÍNIOS GERADO PELAS

ANOTAÇÕES............................................................................................................127

FIGURA 41 – PRIMEIRAS LINHAS DO MÉTODO DE CONGELAMENTO DE

DOMÍNIO ANTES DA REFATORAÇÃO..................................................................130

FIGURA 42 – MÉTODO DE CONGELAMENTO DE DOMÍNIO APÓS

REFATORAÇÃO E UM EPISÓDIO ANOTADO.......................................................131

FIGURA 43 – DEMANDA DA PROMOÇÃO NOVOS DOMÍNIOS...........................134

FIGURA 44 – PRÉ-CONDIÇÕES DO CASO DE USO COMPRA DE DOMÍNIOS..134

FIGURA 45 – CASOS DE USO DE COMPRA DE DOMÍNIOS COM INFORMAÇÃO

DE RASTREABILIDADE..........................................................................................136

LISTA DE TABELAS

TABELA 1 - MATRIZ DE RASTREABILIDADE........................................................39

TABELA 2 - MODELO DE REQUISITOS DA CALCULADORA...............................77

TABELA 3 - OPERAÇÕES PARA AJUSTE NO META-MODELO...........................81

TABELA 4 - PONTOS DE SCRUM ENTREGUES NOS SPRINTS.........................137

LISTA DE ABREVIATURAS E SIGLAS

API – Application Programming Interface

APT - Annotation Processing Tool

BNF - Backus Normal Form ou Backus–Naur Form

CCS - Calculus of Communicating Systems

CRM – Customer Relationship Management

CSP - Communicating Sequential Processes

DNS - Domain Name Server

E-BNF – BNF Extendida

EJB - Enterprise Java Beans

ERP – Enterprise Resource Planner

IEEE – Institute of Electrical and Electronics Engineers

JEE - Java Enterprise Edition

JMS - Java Messaging Service

JSP - Java Server Pages

LSI – Latent Semantic Indexing

NA – Não se aplica

NC – Não Conhecido

OMG – Object Management Group

RMI - Remote Method Invocation

SOA – Service Oriented Architecture

TDRRC - Técnica para Documentação e Recuperação de Requisitos no Código-fonte

UML – Unified Modeling Language

VDM - Vienna Development Method

SUMÁRIO

Pág.

1

INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .1

1

.1 MOTIVAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

1

.2 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

1

.3 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

1

.4 METODOLOGIA DE TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

0

1

.5 ESTRUTURA DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

2

2

REPRESENTAÇÃO DE REQUISITOS FUNCIONAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . .1

4

2

.1 PRINCIPAIS REPRESENTAÇÕES DE REQUISITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

4

2

.2 CASOS DE USO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

1

2

.3 MÉTODOS FORMAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

4

2

.4 UM META-MODELO DE CASOS DE USO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

7

2

.5 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

1

3

GESTÃO DE REQUISITOS DE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .3

4

3

.1 GESTÃO DE REQUISITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

4

3

.2 RASTREABILIDADE DE REQUISITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

9

3

.3 REENGENHARIA DE REQUISITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

1

3

.4 GESTÃO DE REQUISITOS INTEGRADA À ENGENHARIA REVERSA . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .4

6

3

.5 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

9

4

MECANISMO DE ANOTAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .5

1

4

.1 INTRODUÇÃO AO MECANISMO DE ANOTAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

1

4

.2 TIPOS ANOTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

4

4

.3 ANOTAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

8

4

.4 PROCESSAMENTO DE ANOTAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

1

4

.5 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

4

5 TDRRC - TÉCNICA PARA DOCUMENTAÇÃO E RECUPERAÇÃO DE

R

EQUISITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

7

5

.1 VISÃO GERAL DA TDRRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

7

5

.2 ARTEFATOS DA TDRRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

0

5

.3 ATIVIDADES DA TDRRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

7

5

.4 APLICAÇÃO DA TDRRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

00

5

.5 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

09

6

ESTUDO DE CASO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .1

11

6

.1 DESCRIÇÃO DO CONTEXTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

11

6

.2 APLICAÇÃO DA TDRRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

20

6

.3 SITUAÇÕES TÍPICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

23

6

.4 ANÁLISE DOS RESULTADOS OBTIDOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

37

6

.5 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

41

7

CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . .1

43

7

.1 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

43

7

.2 CONTRIBUIÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

47

7

.3 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

49

APÊNDICE I – GRAMÁTICA DAS ANOTAÇÕES EM JAVA . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .1

59

Introdução

1

1 INTRODUÇÃO

Este capítulo apresenta a motivação, o objetivo, a justificativa, a metodologia do

desenvolvimento deste trabalho e a sua estrutura.

1.1 MOTIVAÇÃO

Em geral, no contexto de desenvolvimento e manutenção de software, podem-se

destacar as seguintes situações:

Um processo de desenvolvimento ágil, em que a documentação dos

requisitos é vista como um processo lento e de pouco valor e que a

documentação formal tira agilidade do desenvolvimento (CAO; RAMESH,

2008);

Manutenção de software, em que a documentação de requisitos não existe ou

está desatualizada, fato que ocorre na maioria dos projetos de

desenvolvimento de software depois de um certo tempo de uso (FAHMI et

al., 2007);

Manutenção de software, em que técnicas de gestão de requisitos foram

aplicadas e um repositório de requisitos foi criado.

Ao desenvolver um sistema usando um processo ágil, os desenvolvedores

concentram-se em entender as necessidades do usuário , representá-las de forma

informal e descartável e implementá-las (PAETSCH et al., 2003). A constante

reengenharia faz parte de um ambiente de desenvolvimento ágil, onde a refatoração

é a principal técnica empregada. Seguindo estes processos, os desenvolvedores

deveriam passar 50% do seu tempo programando novas funções e 50% refatorando

código (SNEED, 2008; LAM; SHANKARARAMAN, 2002). Em função da constatação

de que, com a exceção do código-fonte, todos os outros artefatos acabam ficando

desatualizados e só servem para tornar o desenvolvimento mais lento, os métodos

Introdução

2

ágeis não pregam a documentação formal dos requisitos (CAO; RAMESH, 2008;

SNEED, 2008). Esta forma de trabalho permite que os requisitos sejam

implementados mais rapidamente, porém perde-se o modelo de requisitos. Entre as

vantagens trazidas pelos processos ágeis estão: menor tempo de desenvolvimento,

maior contato entre o stakeholder1 e a equipe de desenvolvimento e refatoração

constante do software que, segundo seus criadores, permitiria impedir a degradação

da arquitetura do software (CAO; RAMESH, 2008). Na prática, tudo funciona muito

bem, quando se tem bons desenvolvedores com sólida experiência no

desenvolvimento de software e sistemas de pequeno e médio porte. Ao utilizá-la em

sistemas de grande porte com equipes heterogêneas, a arquitetura acaba se

degradando de forma mais rápida que em um desenvolvimento tradicional, pois nos

métodos ágeis os desenvolvedores têm um papel mais importante na definição da

arquitetura do sistema. Além disso, devido à informalidade na captura de requisitos,

tem-se o agravante de se possuir pouca informação sobre os requisitos do software

(CAO; RAMESH, 2008).

Nos processos de desenvolvimento tradicionais, os requisitos são capturados e

documentados com mais detalhes e, após uma sequência de atividades de análise e

projeto, são implementados (ROYCE, 1998). É comum durante a execução destas

atividades que estes requisitos implementados sejam distintos dos que foram

documentados (LAMSWEERDE, 2008). Isto ocorre devido à falha na captura inicial

dos requisitos, falha no processo de desenvolvimento e mudanças nos requisitos

(KOTONYA; SOMMERVILLE, 1998). Com o passar do tempo, novos requisitos vão

surgindo e as mudanças nos requisitos precisam ser gerenciadas para evitar que o

problema se agrave (LAMSWEERDE, 2008). Na prática, ao usar processos de

desenvolvimento tradicionais, muitas vezes, os documentos de requisitos não são

atualizados, embora isso seja necessário. Quando o software já foi desenvolvido e

os novos requisitos vem de uma evolução do software, o problema se torna ainda

mais grave, pois muitas vezes os documentos iniciais já estão completamente

1 O stakeholder é qualquer parte interessada no resultado do desenvolvimento, manutenção ou

evolução do software. Pode ser, por exemplo, o cliente, usuário ou investidor.

Introdução

3

desatualizados ou perdidos (LAMSWEERDE, 2008). Com o passar do tempo, ocorre

a degradação da arquitetura, o custo de manutenção vai aumentando e o

desenvolvimento de um novo software para substituir o antigo vai se tornando mais

atrativo; porém devido à falta da documentação dos requisitos, o software passa a

ser a única fonte das regras de negócio que foram implementadas ao longo dos

anos (LIU, 2005).

Algumas organizações, porém, conseguem implantar, com sucesso, o

gerenciamento de requisitos, tornando possível evoluir um software e manter seus

documentos de requisitos atualizados e coerentes. O gerenciamento de requisitos é

um processo contínuo durante o desenvolvimento e evolução de um software e

engloba a documentação, análise, priorização, validação, controle de mudanças dos

requisitos (KOTONYA; SOMMERVILLE, 1998). Visando aumentar a produtividade

neste processo e facilitar a identificação de impactos das mudanças, foram criados

mecanismos de rastreabilidade que permitem ligar um código-fonte ao requisito que

o originou. O aumento de produtividade no gerenciamento de requisitos devido à

aplicação dos mecanismos de rastreabilidade é mais visível em sistemas de grande

porte e, por este motivo, a rastreabilidade é considerada fundamental para o

sucesso de um processo de gerenciamento de requisitos deste tipo de sistema

(WEBER et al., 2005; SCHWARZ et al., 2008; LAMSWEERDE, 2008). No entanto,

apesar de trazer grandes avanços para a produtividade, é trabalhoso acessar as

informações básicas dos documentos de requisitos, pois existe a necessidade de

procurar e abrir documentos que estão em um repositório, o que poderia ser evitado

durante a programação de uma alteração de um requisito se os mesmos estivessem

registrados no código-fonte.

Como se pode perceber nestas três situações, enfrentam-se os seguintes desafios:

Como manter os documentos de requisitos atualizados sem burocratizar o

processo ágil, mantendo-o centrado no desenvolvedor;

Como recuperar requisitos na manutenção de sistemas, quando os

documentos de requisitos não existem ou estão desatualizados;

Introdução

4

Como permitir ao desenvolvedor atualizar e consultar o modelo de requisitos

de forma mais ágil na manutenção de sistemas, quando as técnicas de

gestão de requisitos foram aplicadas.

Pensando nestes desafios, estabeleceu-se o objetivo deste trabalho.

1.2 OBJETIVO

O objetivo desta tese é desenvolver uma técnica para representação dos requisitos

funcionais diretamente no código-fonte, que foi denominada TDRRC (Técnica para

Documentação e Recuperação de Requisitos no Código-fonte). Desta forma, esta

técnica permite minimizar a desatualização dos requisitos e recuperar os

documentos de requisitos a partir do código-fonte. Com o uso da TDRRC é

possível, por meio da análise do código-fonte, determinar os requisitos que estão

implementados em um dado software e os trechos de código que os implementam.

Para o desenvolvimento da TDRRC, foi utilizado o mecanismo de anotações que é

um recurso de meta-modelagem presente em diversas linguagens de programação

modernas. Por meta-modelagem, entende-se como a capacidade de criar modelos

de modelos que, no caso específico da técnica, corresponde ao modelo de um

modelo de requisitos (meta-modelo de requisitos) (BARGMEYER et al., 2000). Este

recurso permite ao desenvolvedor, definir o modelo de requisitos que segue um

meta-modelo de requisitos previamente definido.

Para especificar a TDRRC, foi utilizada a linguagem Java que possui o mecanismo

de anotações desde a versão 5.0; esta linguagem foi escolhida por ser bastante

utilizada e possuir um dos mecanismo de anotações mais completos e maduros

(BLOCH, 2008). No entanto, a TDRRC pode ser aplicada em qualquer linguagem

que tenha suporte ao mecanismo de meta-modelagem, sendo necessário fazer

apenas os ajustes de sintaxe, pois os outros aspectos são tratados e ajustados

durante a aplicação da TDRRC.

Com uso da TDRRC, cria-se um meta-modelo de requisitos e uma forma de modelar

os requisitos usando este meta-modelo e o mecanismo de anotações. O

Introdução

5

desenvolvedor passa a documentar os requisitos funcionais diretamente no código-

fonte através de anotações. Uma vez que as anotações estejam feitas no código-

fonte, um processador de anotações, pode extrair o modelo de requisitos e gerar

documentos de requisitos. É possível também, através de um processador de

anotações, sincronizar os requisitos com outros requisitos já existentes e

armazenados em um repositório. Ao representar os requisitos diretamente no

código-fonte, espera-se evitar problemas relacionados a requisitos desatualizados

em relação ao que foi implementado e minimizar a necessidade de mecanismos de

rastreabilidade. A TDRRC permite que os desenvolvedores documentem os

requisitos de maneira gradual, com o conhecimento adquirido durante o processo de

manutenção. Por esta característica, a TDRRC permite a recuperação gradual dos

requisitos sem que haja a necessidade de um esforço concentrado de reengenharia

de requisitos.

A TDRRC torna-se particularmente interessante nos processos ágeis, pois permite

ao desenvolvedor, após sua reunião informal de captura de requisitos, documentar o

que foi especificado no próprio código-fonte que vai ser implementado. O uso da

TDRRC nesta situação permite que os documentos de requisitos passem a existir e

se mantenham atualizados sem um grande aumento da burocracia evitada pelos

processos ágeis.

1.3 JUSTIFICATIVA

Este trabalho se posiciona dentro de duas importantes áreas da Engenharia de

Software:

A Engenharia de Requisitos, que visa o estudo e a criação de métodos,

técnicas e processos para lidar com os requisitos, englobando as atividades

envolvidas na descoberta, elicitação, avaliação, especificação, documentação

e evolução dos objetivos, funcionalidades, qualidade e restrições de um

software (LAMSWEERDE, 2008; LAUESEN, 2002; ZAVE, 1997; KOTONYA;

SOMMERVILLE, 1998).

Introdução

6

A Evolução de S oftware, que compreende as atividades realizadas após a

implantação do software, visando a alteração do mesmo. Engloba várias

atividades de modificação do código-fonte, onde a leitura e compreensão

deste são necessárias para a realização de atividades como: aplicar

atualizações de segurança, adicionar novas funcionalidades, corrigir erros e

melhorar o desempenho (BENNETT; RAJLICH, 2000; CHAPIN et al., 2001;

IEEE CCSE, 2004).

Na intersecção entre estas áreas, encontram-se a área de estudo deste trabalho.

Nesta intersecção, encontram-se a Evolução de Requisitos, que é estudada pela

Evolução de Software, e a Gestão de Requisitos, que é estudada pela Engenharia

de Requisitos. Enquanto, na Gestão de Requisitos, o enfoque está em administrar a

mudança; na Evolução de Requisitos está em determinar o que muda, como muda e

por que muda. A TDRRC contribui com a Gestão de Requisitos; ao propor uma

forma de documentar, armazenar e recuperar os requisitos; e serve de apoio à

Evolução de Requisitos, pois com o registro dos requisitos no código-fonte e o seu

armazenamento em sistemas de controle de versão fica mais fácil estudar e

relacionar mudanças nos requisitos com mudanças no software. Ambas as áreas

são bastante críticas para a evolução de software, pois para aplicar uma mudança

ao software é necessário saber o que o software faz hoje e o que deveria fazer

(LAMSWEERDE, 2008). A definição do que um software deveria fazer é um

problema clássico de definição dos requisitos; no entanto, depois de algum tempo,

descrever o que um software faz nem sempre é uma tarefa trivial, pois muitas vezes

os documentos de requisitos não são atualizados depois que o software é

implementado (FAHMI et al., 2007). Dentre as abordagens para resolver o problema

de determinar o que o software faz hoje encontram-se a rastreabilidade e a

engenharia reversa (FAHMI et al., 2007; CANFORA; PENTA, 2007; SCHWARZ et

al., 2008; JERMAKOVICS et al., 2008).

Nas pesquisas da literatura sobre o tema, encontrou-se um grande número de

publicações sobre propostas para a melhoria de mecanismos de rastreabilidade de

requisitos. A rastreabilidade é a capacidade de associar um artefato do software a

Introdução

7

outros artefatos correlatos, especialmente aqueles relacionados a requisitos. Através

de ligações de rastreabilidade pode-se correlacionar um trecho de código ao

requisito que demandou que este código fosse escrito e vice-versa (EGYED et al.,

2009). A rastreabilidade é um fator importante para diminuição do risco na evolução

de software, porém a grande maioria dos software não foi desenvolvida para prever

rastreabilidade. Diversos estudos foram feitos para obter a rastreabilidade entre

código e requisitos após o desenvolvimento ter sido concluído. Muitos deles utilizam

uma técnica chamada Latent Semantic Indexing (LSI) que busca determinar o

significado do texto de descrição dos requisitos e encontrar estes trechos no código-

fonte; dentre estes destacam-se os trabalhos de Marcus e Maletic (2003),

Jermakovics et al. (2008), De Lucia et al. (2008), Lormans e Deursen (2009) e

Oliveto et al. (2010). Os trabalhos pesquisados que utilizam rastreabilidade de

requisitos têm, como limitação, partir do pressuposto de que os documentos de

requisitos existem e estão atualizados.

Os trabalhos em engenharia reversa permitem que se recuperem modelos de

projeto, diagramas de classes, atividades, a partir do código-fonte de maneira

automática e sem intervenção humana (FAHMI et al., 2007; CANFORA et al., 2008).

A engenharia reversa não consegue, porém, recuperar de maneira automática

artefatos de nível de abstração mais alto, entre eles, os requisitos de um sistema

(YU et al., 2005; FAHMI et al., 2007). Por não poder ser recuperada de forma

automática e por depender de intervenção humana, a extração dos requisitos a partir

do código-fonte através da engenharia reversa é extremamente custosa e falha

(FAHMI et al., 2007; CANFORA et al., 2008). Existem poucos trabalhos publicados

tratando especificamente da engenharia reversa de requisitos. Na pesquisa

bibliográfica realizada no presente trabalho, não foram encontrados artigos tratando

do assunto mais recentes do que o artigo de Canfora et al. (2008). Canfora et al.

(2008) apresenta o estado da arte da engenharia reversa e tem o trabalho de Yu et

al. (2005) como única referência para engenharia reversa de requisitos. Yu et al.

(2005) apresentam um workshop sobre o assunto realizado na décima-segunda

conferência de engenharia reversa do IEEE (12th Working Conference on Reverse

Engineering) e não trata o assunto com muita profundidade.

Introdução

8

Na pesquisa realizada no presente trabalho, foram encontrados os seguintes

trabalhos tratando da engenharia reversa de requisitos:

Liu (2005): apresenta uma técnica semiótica para engenharia de requisitos

que se baseia fortemente na utilização do software e entrevistas com

usuários. Esta técnica, muitas vezes é a única opção, pois pode ser utilizada

mesmo sem a existência do código-fonte, porém tem como limitação ser

intensamente manual e sujeita a erros;

Yang et al. (2006): apresenta um framework para engenharia reversa de

requisitos não funcionais do software. Esta técnica foi capaz de recuperar

esta informação de maneira automática, porém se limita à recuperação de

requisitos não funcionais;

Fahmi et al. (2007): apresenta um modelo de um ambiente onde a engenharia

reversa de requisitos faz parte do processo de desenvolvimento de um

software em evolução. Ele reforça a ausência de publicações com uma

solução automática para o problema e a importância da resolução deste

problema para evolução de software.

Ao invés de tentar recuperar um artefato de nível de abstração mais alto (requisitos)

a partir de um artefato derivado e de nível de abstração mais baixo (código-fonte)

como propõem as técnicas de engenharia reversa, este trabalho propõe que se

inclua junto com o código-fonte de um software, as informações de requisitos. Com

esta abordagem, o trabalho da engenharia reversa se torna mais fácil ou

desnecessário, pois se o código-fonte passa a conter informações de nível de

abstração mais alto, fica mais fácil recompor ou recuperar esta informação. Com

isto, este trabalho contribui com a solução do problema da falta de documentos de

requisitos dos sistemas citado por Canfora e Penta (2007), Schwarz et al. (2008),

Fahmi et al. (2007), Yu et al. (2005) entre outros.

Introdução

9

Este trabalho contribui também com uma proposta que simplifica ou elimina a

necessidade de criar e manter as ligações de rastreabilidade ( trace-links), pois

informações que precisam ser conectadas passam a estar no próprio código-fonte.

Resumindo, este trabalho se justifica por propor uma abordagem que contribui para

solução dos seguintes problemas citados por pesquisadores nas áreas de

Engenharia Reversa de Requisitos, Evolução de Requisitos e Rastreabilidade de

Requisitos:

Ausência de documentos de requisitos atualizada (CANFORA; PENTA, 2007;

FAHMI et al., 2007; YU et al., 2005);

Dificuldade em encontrar o trecho de código que implementa um dado

requisito (SCHWARZ et al., 2008);

Dificuldade em determinar qual requisito está sendo implementado por um

certo trecho de código (SCHWARZ et al., 2008);

Dificuldade em determinar quais mudanças deverão ser feitas em um sistema

para que ele atenda um certo requisito (CIRACI et al., 2007);

Ausência de formas de verificar se um requisito foi implementado ou não

(FAHMI et al., 2007);

Dificuldade em verificar se houve mudanças em um requisito (FAHMI et al.,

2007).

index-24_1.png

Introdução

10

1.4 METODOLOGIA DE TRABALHO

A metodologia de desenvolvimento deste trabalho está representada na figura 1.

Figura 1 – Metodologia Utilizada

O trabalho teve como ponto de partida uma Pesquisa Bibliográfica, na qual as

destacam-se as seguintes referências:

Canfora e Penta (2007), Canfora et al. (2008) que apresentam as técnicas,

um modelo conceitual e o estado da arte da Engenharia Reversa;

Cao e Ramesh (2008) e Paetsch et al. (2003) que discutem a aplicação da

Engenharia de Requisitos em métodos ágeis;

Chung e Leite (2009) que apresenta requisitos não funcionais;

De Lucia et al. (2008), Marcus e Maletic (2003), Lormans e Deursen (2009) e

Oliveto et al. (2010) que apresentam técnicas para recuperação automática

da rastreabilidade de requisitos;

Introdução

11

Fahmi et al. (2007) que propõe um processo de desenvolvimento iterativo

baseado na Gestão de Requisitos;

Gotel e Finkelstein (2002) e Ramesh (1998; 2005) que discutem a

rastreabilidade de requisitos;

Lam e Shankararaman (2002), Robertson e Roberston (2006) e Leffingwell

(2006) que discutem a Gestão de Requisitos;

Lamsweerde (2008), e Zave (1997) que colocam a Engenharia de Requisitos

dentro de um contexto histórico e apresentam o estado da arte;

Lauesen (2002), Kotonya e Sommerville (1998) que apresentam a Engenharia

de Requisitos em geral e as formas de representar requisitos;

Liu (2005) que define um processo e técnicas para a reengenharia de