eduardo kinder almentero dos requisitos ao código: um …julio/tese-eduardo.pdf · 2014. 4. 1. ·...

Eduardo Kinder Almentero

Dos Requisitos ao Código: Um Processo para

Desenvolvimento de Software

mais Transparente

Tese de Doutorado

Tese apresentada como requisito parcial para obtenção do grau de Doutor pelo Programa de Pós-graduação em Informática do Departamento de Informática do Centro Técnico Científico da PUC-Rio.

Orientador: Prof. Julio Cesar Sampaio do Prado Leite

Rio de Janeiro

Dezembro de 2013


Dos Requisitos ao Código: Um Processo para

Desenvolvimento de Software

mais Transparente

Tese apresentada como requisito parcial para obtenção do grau de Doutor pelo Programa de Pós-graduação em Informática do Departamento de Informática do Centro Técnico Científico da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada.

Prof. Julio Cesar Sampaio do Prado Leite Orientador

Departamento de Informática – PUC-Rio

Prof. Carlos José Pereira de Lucena Departamento de Informática – PUC-Rio

Prof. Alessandro Fabrício Garcia Departamento de Informática – PUC-Rio

Profa. Vera Maria Benjamim Werneck Universidade do Estado do Rio de Janeiro – UERJ

Prof. Elder José Reioli Cirilo Universidade Federal de São João del-Rei – UFSJ

Prof. José Eugenio Leal

Coordenador Setorial do Centro Técnico Científico – PUC-Rio

Rio de Janeiro, 12 de dezembro de 2013

Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador.


Graduou-se em Bacharelado em Informática na UERJ em 2006. Recebeu o título de Mestre em Informática na PUC-Rio em 2009.

Ficha Catalográfica

Almentero, Eduardo Kinder Dos Requisitos ao Código: Um Processo para

Desenvolvimento de Software mais Transparente / Eduardo Kinder Almentero ; orientador: Julio Cesar Sampaio do Prado Leite. - 2013.

183 f. ; 30 cm Tese (doutorado) – Pontifícia Universidade Católica

do Rio de Janeiro, Departamento de Informática, 2013. Inclui bibliografia.

1. Informática – Teses. 2. Transparência de software. 3. Desenvolvimento de software. 4. Cenários. 5. Léxico ampliado da linguagem. 6. Modularização. 7. Rastreabilidade. 8. Entendimento. I. Leite, Julio Cesar Sampaio do Prado. II. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Informática. III. Título.

CDD: 004

Aos meus pais Emilio Correa Almentero e Meire Luci Kinder Almentero.

Agradecimentos

A Deus, por tudo.

À minha amada esposa, Amanda, pelo carinho, paciência e incentivo nos

momentos mais difíceis.

À minha família, por acreditarem em mim e torcerem por minha vitória.

Ao meu orientador, Professor Julio Cesar Sampaio do Prado Leite, pela

paciência, confiança e conhecimento compartilhado.

Aos membros da banca, por aceitarem o convite e por sua colaboração com este

trabalho.

Aos integrantes do Grupo de Requisitos da PUC-Rio, pelas valiosas

contribuições e os momentos de descontração durante nossas reuniões.

Aos amigos do LES, por suas sugestões e companheirismo.

Ao corpo docente e funcionários da PUC-Rio, por toda atenção e apoio, que

foram determinantes para conclusão deste trabalho.

À agência de fomento CNPq e a PUC-Rio, pelo apoio financeiro, sem o qual este

trabalho não poderia ter sido concluído.

Resumo

Almentero, Eduardo Kinder; Leite, Julio Cesar Sampaio do Prado. Dos Requisitos ao Código: Um Processo para Construção de Software mais Transparente. Rio de Janeiro, 2013. 183p. Tese de Doutorado – Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

Transparência, no sentido de translúcido, é um conceito presente em uma

enorme variedade de âmbitos e, recentemente, tem sido explorado no contexto

de software. Um software transparente é aquele que informa sobre si mesmo,

disponibilizando informação sobre o que faz, como e porque o faz. A abordagem

da transparência no contexto de software se iniciou através da instanciação de

um catálogo de requisitos não funcionais (RNFs), que inicialmente foi

desenvolvido para transparência de processos. Durante a construção deste

catálogo, notou-se que os RNFs dependência, rastreabilidade e detalhamento,

presentes no catálogo, estão relacionados a problemas clássicos da Engenharia

de Software. Estes problemas são, respectivamente, a definição de critérios para

modularização do software, rastreabilidade entre seus artefatos e entendimento

do seu código. Neste trabalho, propomos estratégias para lidar especificamente

com estes três problemas, contribuindo também para construção de softwares

mais transparentes, uma vez que sua solução implica na satisfação de

qualidades do catálogo. Estas estratégias foram estruturadas através de um

processo de construção de software. Esse processo tem como escopo software

para Web, utilizando arquitetura MVC, desenvolvido através do paradigma de

programação procedural. A ideia central do processo é a utilização de dois

artefatos de requisitos, Léxico Ampliado da Linguagem (LAL) e cenários, durante

todo processo de construção do software. O LAL é utilizado na definição dos

módulos do software. Os cenários são refinados em diferentes níveis de

abstração, de modo que permeiam todo o processo, desde os requisitos até

serem integrados ao código fonte do software. Os rastros entre os diferentes

níveis de abstração dos cenários são mantidos. As operacionalizações propostas

no processo foram anexadas ao catálogo de transparência de software,

possibilitando futura reutilização orientada a qualidades. O processo e suas

operacionalizações foram avaliados através de estudos empíricos envolvendo

diversos sujeitos. O resultado das avaliações sugere que o processo contribui

positivamente para as qualidades de detalhamento, dependência e

rastreabilidade, presentes no catálogo de transparência.

Palavras-chave

Transparência de Software; Desenvolvimento de Software; Cenários;

Léxico Ampliado da Linguagem; Modularização; Rastreabilidade; Entendimento.

Abstract

Almentero, Eduardo Kinder; Leite, Julio Cesar Sampaio do Prado (Advisor). From Requirements to Code: A Process to Develop more Transparent Software. Rio de Janeiro, 2013. 183p. DSc Thesis – Departamento de Informática, Pontifícia Universidade Católica do Rio de Janeiro.

Transparency is a concept that permeates different disciplines, and recently

has been explored in the context of software engineering. Transparent software

aims to make information about it transparent and also aims to provide

transparency on its behavior. The study of transparency in the context of software

started by instantiating a catalog of non-functional requirements (NFRs). During

the construction of this catalog, we realized that the NFRs of traceability,

dependability and detailing are related to classical problems in software

engineering. These problems are, respectively, the definition of software

modules, traceability between its artifacts and the understanding of its source

code. In this work we propose strategies to deal specifically with these three

problems. As these problems are also related to the transparency catalog, then if

we contribute to solving these problems, we will also be contributing to software

transparency. These strategies were structured through a software construction

process that has Web software as its main target. The process uses MVC

architecture and procedural oriented programming languages. The central idea of

this process is to use two requirements artifacts, the Language Extended Lexicon

(LEL) and scenarios, throughout the construction process. The LEL is used in the

definition of the software modules. The scenarios are refined at different levels of

abstraction so that they permeate the entire development process, from

requirements documentation until their integration with the software source code.

The traces between these scenarios are maintained. The strategies proposed in

the process were attached to the software transparency catalog to allow for

quality based reuse. The process and its operationalizations were evaluated

through empirical studies involving different subjects. The results of the

evaluations suggest that the process contributes positively to the quality of

detailing, dependency and traceability, present in the transparency catalog.

Keywords

Software Transparency; Software Development; Scenarios; Language

Extended Lexicon; Modularization; Traceability; Code Understandability.

Sumário

1 Introdução 17

1.1. Motivação 17

1.2. Caracterização do Problema 21

1.3. Enfoque da Solução 22

1.4. Organização da Tese 24

2 Fundamentação Teórica 25

2.1. Léxico Ampliado da Linguagem (LAL) 25

2.2. Cenários 29

2.3. Arquitetura Model View Controller (MVC) 35

2.4. Catálogo de Transparência 37

2.5. Conclusão 46

3 Processo para Desenvolvimento de Software Mais Transparente (PDS+T) 47

3.1. O Processo PDS+T 47

3.2. Descrição das Atividades do PDS+T 50

3.2.1. Agrupar 51

3.2.2. Organizar 63

3.2.3. Operacionalizar 86

3.3. Organizando o PDS+T para Reuso Orientado a Qualidade 100

3.3.1. Atividade Agrupar 101

3.3.2. Atividades Agrupar e Organizar 102

3.3.3. Atividade Operacionalizar 104

3.3.4. PDS+T 105

3.4. Conclusão 107

4 Avaliação do Processo PDS+T 108

4.1. Estudos Empíricos 108

4.1.1. Sistemas Utilizados 109

4.1.2. Estudo Biblioteca Digital 110

4.1.3. Estudo C&L 132

4.2. Conclusão 151

5 Conclusão 152

5.1. Comparações com Trabalhos Relacionados 152

5.2. Contribuições do Trabalho 156

5.3. Limitações do Trabalho 158

5.4. Trabalhos Futuros 159

Referências 160

Anexo A. Questionários Utilizados nos Estudos 171

Lista de Figuras

Figura 1. Modelo Entidade Relacionamento do LAL, adaptado

de (Leite e Franco, 1993). 27

Figura 2. LAL do software C&L representado através de um grafo. 29

Figura 3. Modelo Entidade Relacionamento da estrutura de cenários,

adaptado de (Leite et al., 2000). 30

Figura 4. Grafo com símbolos do LAL e cenários. 34

Figura 5. Diagrama da arquitetura MVC adaptado de (Reenskaug, 1979). 35

Figura 6. Arquitetura MVC proposta. 36

Figura 7. Fragmento do SIG de Transparência representado através

do padrão Objetivo. 40

Figura 8. SIG de Transparência, adaptado de (Cappelli, 2009). 42

Figura 9. Padrão Questão de Rastreabilidade. 44

Figura 10. Padrão Questão de Dependência. 45

Figura 11. Padrão Questão de Detalhamento. 45

Figura 12. SADT do processo proposto. 49

Figura 13. Atividade AGRUPAR detalhada através do SADT. 52

Figura 14. Arquitetura de alto nível (modelo conceitual). 53

Figura 15. Atividade ORGANIZAR. 63

Figura 16. Atividade ORGANIZAR detalhada através do SADT. 64

Figura 17. Tarefa de divisão dos cenários iniciais. 65

Figura 18. Tarefa de criação de cenários de visão. 66

Figura 19. Exemplo de divisão de um cenário de visão do C&L. 67

Figura 20. Tarefa de criação de cenários de controle. 68

Figura 21. Exemplo de divisão de um cenário de visão do C&L. 69

Figura 22. Tarefa de criação de cenários de modelo. 70

Figura 23. Exemplo de divisão de um cenário de modelo do C&L. 70

Figura 24. Atividade OPERACIONALIZAR. 86

Figura 25. Atividade OPERACIONALIZAR detalhada através do SADT. 87

Figura 26. Alternativas para Dependência[Software]. 101

Figura 27. Alternativas para

Rastreabilidade[Software.Requisitos-Arquitetura]. 103

Figura 28. Alternativas para

Rastreabilidade[Software.Arquitetura-Código]. 104

Figura 29. Alternativas para Detalhamento[Software]. 106

Figura 30. Perfil dos participantes do Estudo Biblioteca Digital. 113

Figura 31. Passos para realizar a tarefa 1 do Estudo Biblioteca Digital com

artefatos do PDS+T. 114

Figura 32. Passos 1 a 5 para realizar a tarefa 3 do Estudo

Biblioteca Digital, com artefatos do PDS+T. 116





Figura 35. Grupo 1 gráfico de tarefas corretas. 124

Figura 36. Grupo 1 gráfico do tempo de execução das tarefas. 125

Figura 37. Grupo 2 gráfico de tarefas corretas. 126

Figura 38. Grupo 2 gráfico do tempo de execução das tarefas. 127

Figura 39. Gráfico de tarefas corretas Grupo 1 + Grupo 2. 128

Figura 40. Percentual de tarefas corretas executadas no Biblioteca

Digital com cenário. 128

Figura 41. Percentual de tarefas corretas executadas no Biblioteca

Digital sem cenário. 129

Figura 42. Gráfico do tempo de execução das tarefas Grupo 1 + Grupo 2. 130

Figura 43. Perfil dos participantes do Estudo C&L. 134

Figura 44. Passo 1 para realizar a tarefa 2 do Estudo B, no C&L em LUA. 136

Figura 45. Passos 2 e 3 para realizar a tarefa 2 do Estudo C&L,

no C&L em LUA. 137

Figura 46. Passo 1 para realizar a tarefa 2 do Estudo C&L,

no C&L em PHP. 138


no C&L em PHP. 139

Figura 48. Passo 1 a 3 para realizar a tarefa 4 do Estudo C&L,

no C&L em LUA. 140

Figura 49. Passo 4 a 7 para realizar a tarefa 4 do Estudo C&L,

no C&L em LUA. 141


no C&L em PHP. 142

Figura 51. Passos 2 e 3 para realizar a tarefa 4 do Estudo C&L,

no C&L em PHP. 143

Figura 52. Gráfico de tarefas corretas do Estudo C&L. 147

Figura 53. Percentual de tarefas corretas executadas no C&L PHP. 147

Figura 54. Percentual de tarefas corretas executadas no C&L Lua. 148

Figura 55. Gráfico do tempo de execução das tarefas do Estudo C&L. 149

Lista de Tabelas

Tabela 1. Exemplo de símbolo do LAL pertencente ao UdI do C&L. 27

Tabela 2. Heurísticas para descrição do LAL. 28

Tabela 3. Exemplo de cenário pertencente ao UdI do C&L. 32

Tabela 4. Cenários de requisitos do C&L. 50

Tabela 5. Número de relacionamentos dos símbolos do léxico. 54

Tabela 6. Cenário integrador do software C&L. 63

Tabela 7. Heurísticas para descrever cenários da camada de visão. 74

Tabela 8. Exemplo de cenário de visão do software C&L. 76

Tabela 9. Heurísticas para descrever cenários da camada de controle. 79

Tabela 10. Exemplo de cenário de controle do software C&L. 80

Tabela 11. Heurísticas para descrever cenários da camada de modelo. 83

Tabela 12. Exemplo de cenário de modelo do software C&L. 84

Tabela 13. Heurísticas para descrever cenários operacionais de script. 90

Tabela 14. Exemplo de cenário operacional de visão codificado. 94

Tabela 15. Exemplo de cenário operacional de controle codificado. 96

Tabela 16. Exemplo de cenário operacional de modelo codificado. 98

Tabela 17. Questionário para determinar perfil do participante. 112

Tabela 18. Resposta da tarefa 1 do Estudo Biblioteca Digital. 115

Tabela 19. Resposta da tarefa 3 do Estudo Biblioteca Digital,

com artefatos do PDS+T. 119

Tabela 20. Distribuição de tarefas entre participantes do Grupo 1. 122

Tabela 21. Distribuição de tarefas entre participantes do Grupo 2. 122

Tabela 22. Questionário para determinar perfil do participante. 133

Tabela 23. Resposta da tarefa 2 do Estudo C&L, para o C&L em LUA. 137

Tabela 24. Resposta da tarefa 2 do Estudo C&L, para o C&L em PHP. 139

Tabela 25. Resposta da tarefa 4 do Estudo C&L, para o C&L em LUA. 142

Tabela 26. Resposta da tarefa 4 do Estudo C&L, para o C&L em PHP. 143

Tabela 27. Distribuição de tarefas entre participantes Estudo C&L. 146

Lista de Abreviaturas e Siglas

ADL

CTS

Architecture Description Language

Catálogo de Transparência de Software

DAL

GQM

Data Access Library

Goal Question Metric

GQO Goal Question Operationalization

LAL Léxico Ampliado da Linguagem

LEL Lexicon Extended Language

MDD

MVC

Model Driven Development

Model View Controller

NFR Non-functional Requirements

PDS+T Processo de Desenvolvimento de Software Mais

Transparente

SIG Softgoal Interdependency Graph

UdI Universo de Informações

Introdução 17

1 Introdução

Neste trabalho, apresentamos um processo para desenvolvimento de software

mais transparentes. As contribuições deste processo foram anexadas a um catálogo, a

fim de facilitar seu reuso. Este capítulo descreve a motivação que levou a realização

deste trabalho, caracteriza o problema da construção de software transparente e como

ele se relaciona com problemas clássicos da engenharia de software, detalha o enfoque

da solução proposta e define a organização da tese.

1.1. Motivação

Transparência é um conceito difuso, que tem sido utilizado em uma grande

variedade de âmbitos, como social, econômico e político. Recentemente, este

conceito tem sido explorado também no contexto de software (Leite e Cappelli,

2010). Um software transparente é aquele que informa sobre si mesmo,

disponibilizando informação sobre o que faz, como e porque o faz. A

complexidade inerente ao termo transparência é muito grande em qualquer

contexto, e o de software não é uma exceção. Com o propósito de lidar de forma

coerente com tal complexidade, utilizou-se a abordagem proposta em (Cappelli,

2009), instanciada para o tópico software. Tal abordagem propõe a divisão da

transparência em diversos atributos de qualidade, modelados como metas

flexíveis inter-relacionadas, através do Software Interdenpendency Graph (SIG),

proposto no NFR framework (Chung et al., 2000). A partir desta modelagem,

criou-se o Catálogo de Transparência de Software (CTS) (Catálogo, 2013), cujo

objetivo é organizar as operacionalizações relacionadas às metas flexíveis

presentes no SIG. A variabilidade deste catálogo é proporcionada por

alternativas para responder as questões relacionadas às metas flexíveis.

Desenvolver sob os princípios de transparência, de forma geral, é benéfico

devido à abertura de informações. A abertura, ideia básica por trás do

movimento de Software Livre, é o pilar de sustentação da Lei de Linus1 - "given

1 Raymond, Eric S. (1999). The cathedral and the Bazaar. O'Reily Media. p.30.

ISBN 1-56592-724-9.

Introdução 18

enough eyeballs, all bugs are shallow". Não obstante, os princípios de

transparência também têm um impacto direto em outros problemas clássicos da

Engenharia de Software, como a rastreabilidade entre artefatos de um software,

o entendimento de seu código fonte e a definição de critérios para sua

organização modular. Isto significa que muitas das características elencadas no

SIG já eram desejadas para o software, porém não apareciam sob o conceito de

transparência. Esta relação ainda não foi totalmente explorada, mas sabemos,

analisando as questões do CTS, que há uma interseção entre as características

de transparência e desafios já conhecidos da Engenharia de Software. Neste

trabalho, focaremos em três conceitos que fazem parte desta interseção:

detalhamento do código fonte, modularização e rastreabilidade.

O detalhamento é uma das metas flexíveis presentes no SIG de

transparência. Aplicado ao código fonte do software, esta qualidade pode facilitar

a sua leitura por aqueles que não estiveram envolvidos diretamente em sua

escrita, expandindo o número de pessoas que o compreendem. Utilizando o

mesmo raciocínio que justifica a programação por pares na metodologia XP

(Beck e Andres, 2004), a Lei de Linus ou o uso de pontos de vista (Leite e

Freeman, 1991), podemos argumentar que a qualidade irá aumentar, pois mais

pessoas terão a capacidade de compreender o que ele faz. Esta crença também

é confirmada pelo estudo realizado por (Rahman e Devanbu, 2011), onde ficou

claro que o código escrito por vários autores apresentava menos erros que

aqueles escritos por apenas um. Uma das atividades impactada pelo

entendimento do código é a manutenção do software. Segundo (Mayrhauser e

Vans, 1995), o conhecimento do código influencia diretamente a eficácia da

manutenção e evolução do software. Além disto, a sua compreensão também

influencia a atividade de reuso. Segundo (Marshall, 1999), quando o

programador encontra o código que deseja reusar, ele pode precisar modificar

parte dele, para adaptá-lo a sua necessidade. Ainda que a modificação não seja

necessária, ele precisa importá-lo para o software em desenvolvimento. De

qualquer forma, ambas as atividades exigem que o programador entenda o

código em questão.

O conceito de modularização, embora não esteja explicitamente

representado no SIG de transparência, pode ser percebido nas metas flexíveis

dependência e divisibilidade (Catálogo, 2013). Entendemos como modularização

a disciplina de divisão do software em módulos, que são unidades básicas do

software com interface bem definida. Uma boa estrutura modular é aquela que

apresenta um alto grau de coesão e baixo grau de acoplamento (Yourdon e

Introdução 19

Constantine, 1979; Pressman, 1992; Sommerville, 2001). Acredita-se que um

software com uma boa modularização seja mais fácil de desenvolver e manter

(Pressman, 1992; Sommerville, 2001). Segundo Parnas, (Parnas, 1972) os

benefícios de uma modularização bem feita são: (i) tempo de desenvolvimento

reduzido, (ii) flexibilidade do produto e (iii) facilidade de compreensão. A primeira

vantagem se deve a possibilidade de paralelizar o desenvolvimento, uma vez

que os módulos são independentes. A segunda se deve a possibilidade de

alterar uma parte do software, sem que outras sejam afetadas. A última é

decorrente da possibilidade de compreender uma parte do software de cada vez.

Existem muitos trabalhos com o objetivo de obter uma organização modular, a

partir de software já construído (Kiarash et al., 2003; Harman et al., 2005;

Praditwong et al., 2011), porém, poucos lidam com os critérios para escolha dos

módulos no início do desenvolvimento de um novo software (Parnas, 1972).

A rastreabilidade é outra meta flexível que pertence ao SIG de

transparência. Este conceito é central na construção de software, especialmente

a ligação entre arquitetura e código e requisitos e arquitetura (De Silva e

Balasubramaniam, 2012). A arquitetura de um software é uma abstração, que

permite uma visão geral de sua estrutura. Ela oculta os detalhes de

implementação e estrutura de dados, permitindo o foco na descrição de

elementos importantes, suas propriedades visíveis externamente e o

relacionamento entre eles (Bass e Kazman, 2003). Linguagens formais para

descrição de arquitetura (ADLs) (Medvidovic e Taylor, 2000), são ferramentas

projetadas para ajudar na representação e análise destas estruturas de alto-

nível. Embora o desenvolvimento de ADLs esteja avançando, assegurar que a

arquitetura do software descreve o que foi implementado, e manter esta

arquitetura atualizada, ainda são problemas centrais no processo de

desenvolvimento de software (Aldrich et al., 2002). Como dito por Shaw (Shaw e

Clements, 2006), duas áreas promissoras no campo da arquitetura de software

são: estabelecer um vínculo entre arquitetura e código e investigar o

relacionamento entre decisões arquiteturais e atributos de qualidade. O primeiro

é importante, pois sem a presença de um elo entre arquitetura e código, ela

estará destinada a obsolescência. A segunda é crucial para determinar o

impacto dos atributos de qualidade no processo de desenvolvimento de

software, de forma que seja possível entregar o software o mais próximo

possível das necessidades do usuário. Segundo Garlan (Garlan, 2003), embora

existam trabalhos na área de geração automática de código a partir de modelos

Introdução 20

arquiteturais, assegurando a conformidade por construção, muito ainda precisa

ser feito.

Os esforços para manter a integridade entre código e arquitetura, não

devem ser limitados a apenas uma direção, isto é, apenas da arquitetura para o

código ou do código para a arquitetura. De acordo com Gurp (Gurp e Bosch,

2002) a erosão da arquitetura, isto é, a diferença do que foi modelado e o que

está realmente implementado, é uma condição inevitável, devido a evolução dos

requisitos ao longo do tempo, que é uma característica inerente da grande

maioria dos software. Portanto, os esforços devem ser concentrados em tratar o

sintoma, ao invés de tentar evitá-lo.

Podemos separar os problemas entre arquitetura e implementação em três

categorias (Ubayashi et al., 2010): (i) nível de abstração do desenho da

arquitetura, (ii) refinamento do desenho para o código e (iii) coevolução entre

desenho e código. De acordo com Ubayashi, estes problemas existem, pois não

há uma definição explícita da fronteira entre desenho e implementação. O

primeiro problema está relacionado ao nível de abstração apropriado para a

arquitetura. Um nível muito alto aumenta a diferença entre arquitetura e

implementação. Por outro lado, se o nível de abstração for muito baixo, a

diferença entre arquitetura e implementação se torna muito sutil. O segundo se

refere à correlação das decisões de desenho, com o seu respectivo impacto no

código. O último trata da integridade entre código fonte e arquitetura. Para

manter esta integridade, é necessária uma rastreabilidade bidirecional (Moriconi

et al., 1995; Aldrich, 2002; Buchgeher e Weinreich, 2009; Christensen e Hansen,

2011; Zheng e Taylor, 2011).

Observando a discussão sobre os problemas apresentados, é notória a

relevância de abordá-los durante o processo de desenvolvimento do software.

Fica claro também, o relacionamento entre algumas características desejadas

para um software transparente, e dificuldades há muito discutidas no contexto da

engenharia de software. Apesar da ampla discussão, ainda é possível contribuir

para amenizá-las, pois nenhuma solução definitiva foi apresentada. O vínculo

entre a transparência de software e estes problemas, torna a tarefa de elaborar

as soluções ainda mais recompensadora, pois desta forma também estamos

colaborando para tornar o software mais transparente.

Introdução 21

1.2. Caracterização do Problema

A transparência de software é um conceito complexo e, para ser melhor

compreendido, foi descrito através de uma rede de metas flexíveis. Para que

seja possível construir software utilizando princípios de transparência, é preciso

encontrar operacionalizações para estas metas flexíveis. A forma encontrada

para permitir a associação de operacionalizações às metas flexíveis da rede foi

a construção de um catálogo, cuja variabilidade, isto é, seu ponto de extensão,

são respostas as questões contidas em sua estrutura. Algumas questões do

Catálogo de Transparência de Software (CTS) remetem a desafios conhecidos

da engenharia de software, que ainda não foram solucionados a contento.

Dentre estes desafios, temos o de facilitar o entendimento do código, definir

critérios para modularização do software e criar/manter a rastreabilidade entre os

artefatos que compõem o software.

A melhor forma de lidar com estes desafios é incorporar ao processo de

construção do software meios de atenuá-los. É importante que estes desafios

sejam abordados durante o processo de desenvolvimento, pois sabemos que

alterações em software em produção são muito mais custosas do que aquelas

realizadas durante seu desenvolvimento (Bennett e Rajlich, 2000).

Diante do exposto acima, em relação à operacionalização de metas

flexíveis específicas da transparência de software, nos vemos diante dos

seguintes desafios:

Partindo de artefatos de requisitos em linguagem natural, como

obter a organização modular da arquitetura do software, de modo

que se mantenha a rastreabilidade entre os requisitos e a

arquitetura?

Como utilizar o mesmo artefato de requisitos, integrado com os

diferentes artefatos produzidos ao longo do desenvolvimento do

software, de modo a obter uma rastreabilidade, em ambas as

direções, dos requisitos até o código?

Como facilitar a compreensão de um software, permitindo uma

explicação detalhada de sua estrutura e código, através da

utilização de linguagem natural semi-estruturada, de forma que

sejam entendidos com esforço reduzido?

Introdução 22

Como incorporar as operacionalizações para rastreabilidade,

dependência e detalhamento no Catálogo de Transparência de

Software (CTS), a fim de permitir o seu reuso orientado a

qualidade?

1.3. Enfoque da Solução

Neste trabalho, propomos um processo de construção de software

(PDS+T) (Almentero, 2013b), que incorpora em suas etapas procedimentos

específicos para lidar com as questões enunciadas na seção anterior. Este

processo utiliza como alicerces a representação de requisitos através de

cenários (Leite et al., 1997) e a linguagem do Universo de Informação (UdI),

descrita através da técnica Léxico Ampliado da Linguagem (LAL) (Leite e

Franco, 1993). Restringimos o escopo do processo a uma categoria específica

de software, que são aqueles desenvolvidos para Web. Isto foi feito para que

durante o processo, pudéssemos adotar heurísticas específicas aos paradigmas

(Web), como, por exemplo, interface construída através da linguagem de

marcação HTML, envolvidos na construção do software.

Propomos um processo inteiramente novo para construção de software,

pois vislumbramos a oportunidade de aproveitar características específicas das

técnicas de requisitos LAL e cenários, a fim de agregar características de

transparência ao software, durante seu desenvolvimento. Não encontramos

nenhuma outra estratégia que utiliza estas técnicas com este fim. As

características que nos interessaram são: (i) o princípio da circularidade do LAL,

que permite identificar o relacionamento entre os símbolos do domínio, atributo

interessante para abordar a qualidade de dependência, (ii) o modelo semi-

estruturado dos cenários, que já foi utilizado com sucesso na descrição de

artefatos do software (Silva et al., 2003; Almentero, 2009) e demonstrou ser uma

característica interessante para qualidade de detalhamento e (iii) a existência de

relacionamentos entre cenários, que nos permite a criação de uma rede de

relacionamentos entre artefatos descritos com esta técnica, uma característica

muito interessante para qualidade de rastreabilidade.

Na primeira etapa do processo, o objetivo é a organização dos cenários

de requisitos em módulos. Esta organização é obtida através de heurísticas de

clusterização aplicadas ao LAL do UdI. Estas heurísticas irão identificar os

Introdução 23

conceitos mais importantes dentro do LAL, que representarão os módulos do

software. A estreita relação entre os cenários e o LAL será utilizada a fim de

dispor os cenários de acordo com os módulos identificados. Através desta etapa,

propomos a modularização a partir dos requisitos do software (LAL e cenários).

A originalidade desta etapa reside no fato de que estas heurísticas se alicerçam

em técnicas de requisitos em linguagem natural, que fornecem a base para

encontrar os relacionamentos entre seus artefatos. O mesmo não acontece em

(Al-Otaiby et al., 2005), onde estes relacionamentos tem que ser inferidos.

A segunda etapa do processo consiste na derivação da arquitetura,

segundo o padrão MVC, com base nos cenários de requisitos. Para esta tarefa,

foram propostas heurísticas, através das quais cenários específicos de cada

camada do MVC são criados a partir dos cenários de requisitos. Esta tarefa é

executada de forma que é mantido um rastro bidirecional entre os cenários

iniciais e os de camada originados a partir deles. Com isto, obtemos a

arquitetura do software, que é explicada através dos cenários de camadas, e

pode ser rastreada até os requisitos. Nesta etapa, a contribuição em relação a

trabalhos existentes reside no fato de que um rastro bi-direcional é mantido entre

os requisitos e a arquitetura. Além disto, a arquitetura é explicada através dos

cenários criados, que são escritos em linguagem natural. Isto não acontece em

(Aldrich et al., 2000), onde o rastro entre a arquitetura e os requisitos é mantido

em apenas uma direção, dos requisitos para a arquitetura, e não é fornecida

uma explicação em linguagem natural para arquitetura do software.

Durante a última etapa do processo, o código do software é produzido.

Antes de escrever o código propriamente dito, os cenários das camadas são

refinados e cenários mais detalhados são produzidos (chamados de cenários

operacionais), de forma que se mantém um rastro entre eles e os das camadas.

Os cenários operacionais são então codificados. Ao final desta etapa, obtemos

um único documento, que contém o código fonte do software integrado com os

cenários operacionais. Os cenários operacionais deste documento podem ser

rastreados até os de camada (arquitetura), que por sua vez, podem ser

rastreados até os iniciais (requisitos). O caminho inverso também pode ser

percorrido. Esta última etapa se assemelha a proposta Model Driven

Development (MDD) (Sheng e Benatallhah, 2005; Hastbacka e Vepsalainen,

2011; Agner et al., 2012), porém, a diferença é que nossa abordagem não é

restrita a um domínio específico. Além disto, o código não é gerado a partir de

modelos semelhantes à arquitetura, e sim de modelos em linguagem natural. Por

fim, nossa abordagem tem como resultado uma rastreabilidade bi-direcional

Introdução 24

entre arquitetura e código, enquanto a maioria das técnicas MDD apresenta

apenas a rastreabilidade da arquitetura para o código.

Resumidamente, o processo proposto é composto de etapas encadeadas,

de forma que o produto de cada uma é verificado antes de ser utilizado na

seguinte, procurando com isso atenuar problemas com a qualidade. Nestas

etapas, critérios e heurísticas são estabelecidas, com o intuito de padronizar a

estrutura do software produzido e criar uma sequência lógica de passos, onde

qualidades de transparência (detalhamento, dependência e rastreabilidade) são

atendidas através de operacionalizações integradas com as atividades

tradicionais do desenvolvimento de software.

1.4. Organização da Tese

No capítulo 2, apresentamos os conceitos e abordagens, que inspiraram

e foram utilizados como alicerce de nossa pesquisa. O capítulo 3 apresenta o

processo que foi proposto para lidar com as dificuldades enunciadas neste

trabalho. Tal processo foi distribuído em etapas, com entradas e saídas bem

definidas, com o intuído de aclarar seus procedimentos. No capítulo 3, expomos

como as contribuições obtidas através do processo foram anexadas ao CTS. No

capítulo 4, descrevemos as avaliações realizadas, através de estudos empíricos,

com o intuito de determinar se os objetivos esperados foram alcançados.

Finalmente, no capítulo 5, apresentamos o relacionamento da pesquisa com

trabalhos anteriores, nossas conclusões, limitações do trabalho e os trabalhos

futuros.

Fundamentação Teórica 25

2 Fundamentação Teórica

Neste capítulo são apresentados os conceitos e abordagens utilizadas, que

servem como base para o trabalho realizado. Dentre estes conceitos estão duas técnicas

da engenharia de requisitos (LAL e cenários) e o Catálogo de Transparência de

Software, que é peça fundamental neste estudo. Apresentamos também, neste capítulo,

a instanciação dos conceitos do padrão arquitetural MVC, conceito fundamental para o

entendimento do trabalho. Por fim, detalhamos a motivação para criação do Catálogo de

Transparência de Software, descrevemos o catálogo em si e apontamos sua relação

com o trabalho realizado.

2.1. Léxico Ampliado da Linguagem (LAL)

A técnica LAL (Leite e Franco, 1993) está fundamentada na existência de

uma linguagem específica em cada Universo de Informação (UdI). Esta

linguagem é composta de símbolos, que possuem um significado particular

quando utilizados pelos atores do UdI. Portanto, para compreender o UdI é

preciso primeiro entender tal linguagem. O LAL foi criado especificamente para

guiar a elicitação e permitir a modelagem desta linguagem. O foco da técnica é

especificamente a linguagem, o problema em si não é abordado neste momento

da engenharia de requisitos. Leite (Leite et al., 1997), argumenta que o

conhecimento desta linguagem deve ser o primeiro passo na fase de elicitação

de requisitos.

O processo proposto para construção do LEL é composto de quatro

passos: (i) identificar as principais fontes de informação do UdI, (ii) identificar

símbolos relevantes no UdI, (iii) elicitar o significado dos símbolos e (iv) validar o

LAL resultante. Abaixo detalhamos as atividades compreendidas em cada um

destes passos.

Identificar fontes de informação. As fontes de maior importância

do UdI são os atores e os documentos. A identificação dos atores

corretos, que possam indicar os documentos e outras fontes de

informação relevantes, é essencial nesta etapa.


Identificar símbolos relevantes. Nesta etapa é produzida a

primeira lista de símbolos. São propostas duas abordagens para

construção desta lista: ler documentos e escutar os atores. Em

ambos os casos, a principal heurística envolve anotar frases e

termos que parecem ter um significado especial. O foco deve ser

em listar os símbolos e não em entender como o software irá

funcionar. Nesta etapa, os atores podem ser ouvidos através de

observação ou entrevistas não estruturadas.

Elicitar o significado dos símbolos. Assim como na etapa

anterior, o foco não deve ser a descrição de funcionalidades, e sim

a definição da semântica de cada símbolo. A técnica de elicitação

indicada para esta etapa é a entrevista estruturada. A lista de

símbolos previamente criada deve servir como guia na entrevista, e

perguntas diretamente relacionadas ao significado dos símbolos

devem ser incluídas no roteiro.

Validar o LAL. Duas técnicas complementares são utilizadas para

validação. Uma baseia-se na checagem informal, onde o LAL é

validado com a ajuda dos atores do UdI. A outra envolve uma

análise das entradas do LAL a fim de detectar símbolos

esquecidos.

Como resultado do processo, cada símbolo elicitado será identificado por

um nome e descrito através de noções (denotação) e impacto (conotação). Na

noção, frases curtas descreverão o significado literal do símbolo no UdI. No

impacto, serão descritos os efeitos do uso e ocorrência do símbolo no UdI.

Adicionalmente, os símbolos podem possuir sinônimos e devem ser

classificados, gramaticalmente, como sujeito, estado, objeto ou verbo, como

mostra o modelo ER apresentado na Figura 1. Para exemplificar, na Tabela 1

apresentamos a descrição de um símbolo do LAL pertencente ao UdI da

ferramenta C&L (C&L, 2013a).


Figura 1. Modelo Entidade Relacionamento do LAL, adaptado de (Leite e Franco,

1993).

Nome Projeto

Classificação Objeto

Noção

- Conceito utilizado para representar um UdI

específico dentro do software.

- Símbolos e cenários podem ser criados no projeto.

Impactos

- O usuário pode criar um projeto.

- O usuário pode editar um projeto.

- O usuário pode adicionar símbolos e adicionar

cenários a um projeto.

- O usuário pode exportar um projeto.

- O usuário pode gerar o grafo do projeto.

Tabela 1. Exemplo de símbolo do LAL pertencente ao UdI do C&L.

Outra característica do LAL é utilização de dois princípios básicos, que

guiam a descrição de seus símbolos. O princípio da circularidade estabelece

que, na descrição da noção e impacto de um símbolo, deve-se utilizar ao

máximo outros símbolos pertencentes ao LAL. Por exemplo, na descrição do

símbolo projeto, apresentada na Tabela 1, o símbolo usuário é utilizado em

todas as sentenças que descrevem o impacto de projeto. De forma

complementar, o vocabulário mínimo estabelece que, ao descrever a noção e o


impacto de um símbolo, deve-se minimizar o uso de termos externos ao LAL.

Caso seja necessário o uso de termos externos, deve-se optar por aqueles mais

simples, com significado claro. Na descrição do impacto do símbolo projeto

(Tabela 1), por exemplo, o único termo externo utilizado foi a palavra "pode".

Heurísticas foram criadas para ajudar a descrição da noção e impacto dos

símbolos de acordo com sua classificação gramatical. Tais heurísticas foram

descritas através de perguntas, como mostra a Tabela 2. Um de seus propósitos

é enfatizar o uso do princípio da circularidade. De acordo com a heurística para

descrição da noção de um objeto, por exemplo, devemos identificar com quais

outros objetos ele se relaciona. Desta forma, estamos criando relacionamentos

entre símbolos do tipo objeto. De forma semelhante, quando o impacto de um

símbolo do tipo sujeito é descrito, devemos enumerar as ações que ele pode

executar. Neste caso, estamos estabelecendo relacionamento entre sujeitos e

verbos.

Classificação Noção Impacto

Sujeito - Quem é o sujeito? - Quais ações pode

executar?

Verbo

- Quem executa a ação?

- Quando ela acontece?

- Quais atividades são

executadas?

- Quais os reflexas desta

ação no ambiente?

- Quais estados são

alcançados a partir da

ação?

Objeto

- Como o objeto pode ser

definido?

- Com quais outros objetos

se relaciona?

- Quais ações podem ser

aplicadas ao objeto?

Estado

- O que o estado significa?

- Quais ações levaram a

este estado?

- Quais outros estados e

ações podem ocorrer a

partir deste?

Tabela 2. Heurísticas para descrição do LAL.

Como consequência da utilização do princípio da circularidade, obtemos

um conjunto de símbolos ligados através de uma rede complexa de


relacionamentos. Esta rede pode ser interpretada como um grafo, onde cada

símbolo é representado através de um vértice. Os relacionamentos entre dois

símbolos são representados através de arestas ligando dois vértices. A Figura 2

apresenta o grafo de um subconjunto dos termos do LAL referente ao UdI do

software C&L.

Figura 2. LAL do software C&L representado através de um grafo.

2.2. Cenários

A fim de definir os requisitos, os engenheiros devem compreender e

modelar UdI do software. Uma vez modelado o conhecimento, os usuários

interagem com engenheiros para verificar se o entendimento foi correto e validar

os modelos construídos. Portanto, é essencial que a comunicação entre usuário

e engenheiros seja facilitada, de modo que o processo de definição de requisitos

seja realizado adequadamente. Esta motivação levou a pesquisa de métodos

que ajudassem na interação entre os envolvidos durante o processo de definição

dos requisitos. Uma das técnicas criadas através destas pesquisas foi a

descrição através de cenários.

Segundo Leite (Leite, 1997), no contexto da engenharia de requisitos, os

cenários são entendidos como uma técnica que é focada tanto na descrição do

processo quanto centrada no usuário. Está técnica é muito utilizada na

engenharia de requisitos, pois ajuda os engenheiros a entender melhor o

software e sua interface com o ambiente. A interação com os envolvidos é

facilitada pelo uso da linguagem natural na descrição dos cenários. Isto permite

que os envolvidos compreendam melhor os modelos produzidos, fazendo com

que se sintam mais confortáveis ao interagir com os engenheiros.


No âmbito da engenharia de requisitos, vários modelos de cenários foram

propostos, desde os mais formais (Hsia et al., 1994), que utilizam linguagem

formal e permitem a geração e validação automáticas, até os informais (Carroll

et al., 1994; Rosson e Carroll, 2002), que são descritos sem uma estrutura

definida. O modelo adotado em nossa pesquisa pode ser classificado como

intermediário, pois visa à descrição de uma situação específica do software,

através de linguagem natural semi-estruturada (Leite et al. 1997). Este modelo

foi escolhido, pois sua estrutura conduz a um detalhamento mais preciso e maior

das situações que são descritas, facilitando o entendimento. Além disto, o

modelo propõe a utilização de relacionamentos, a fim de interligar os diversos

cenários produzidos, o que também facilita o entendimento, e permite uma

análise da interdependência dos cenários. A estrutura estabelecida para este

modelo é composta dos seguintes elementos: título, objetivo, contexto, recursos,

atores, episódios, exceções e restrições, como mostra a Figura 3.

Figura 3. Modelo Entidade Relacionamento da estrutura de cenários, adaptado de

(Leite et al., 2000).

O título serve como identificador do cenário dentro do UdI, portanto deve

ser único. A finalidade do cenário é descrita, de forma sucinta, através de seu

objetivo, que também deve conter breve informação de como a ela é alcançada.

O contexto do cenário é descrito através da localização geográfica, localização

temporal ou precondições. Pelo menos um dos itens citados anteriormente deve

estar presente na descrição. A localização geográfica indica se o cenário requer

uma posição geográfica específica para que possa ser executado. A localização

temporal pode ser utilizada para delimitar um intervalo de tempo ou informar a

periodicidade com que o cenário ocorre. E, por fim, temos as precondições, que

servem para estabelecer os requisitos necessários para execução do cenário.


Os atores são as entidades ativas do cenário, que utilizam os recursos,

entidades passivas, para realizar as ações necessárias a fim de satisfazer o

objetivo. Para serem válidos, os atores e recursos devem aparecer em pelo

menos um dos episódios do cenário.

Os episódios descrevem ações executadas pelos atores com o uso dos

recursos. São apresentados de forma sequencial e podem ser de três tipos

distintos: simples, condicionais ou opcionais. Os simples são aqueles

indispensáveis para que o objetivo do cenário seja alcançado. Os condicionais

dependem da ocorrência de uma condição específica para serem executados.

As condições internas de um cenário podem ocorrer devido a precondições,

alternativas, restrições de atores ou recursos e episódios anteriores. Por fim,

temos os opcionais, que podem ocorrer ou não, dependendo de condições que

não podem ser explicitamente detalhadas.

Título Criar projeto no C&L

Objetivo

Permitir a representação de um UdI específico dentro do

software C&L, com a finalidade de agrupar símbolos do

léxico e cenários através da ação de inserir projeto.

Contexto - Usuário deve possuir conta no software.

- Executar cenário AUTENTICAR USUÁRIO.

Recursos

Nome do projeto, descrição, formulário para cadastro

de projeto, menu principal. Restrição: O formulário

para cadastro deve ser simples.

Atores Usuário e software.

Episódios

1. Usuário solicita a inclusão de um novo projeto no

software através de comando no menu principal.

Restrição: o comando para criar projeto deve ser

intuitivo.

2. Software exibe formulário com os campos nome e

descrição do projeto.

3. Usuário informa nome e descrição do projeto.

Restrição: os dados devem estar completos.

4. Usuário solicita criação do projeto.

5. Software analisa os dados informados pelo usuário.

6. Software cria novo projeto e exibe mensagem para o

usuário, informando que o projeto foi criado com


sucesso. Restrição: mensagem exibida dever ser

informativa.

Exceção

- Se o usuário informar um nome para o projeto que já

exista na base de projetos, então o software informa

que o nome escolhido já existe e um nome diferente

precisa ser informado.

- Se o usuário deixar algum dos campos do formulário

em branco, o software não cria o projeto e emite uma

mensagem informando ao usuário que os dados são

obrigatórios.

Tabela 3. Exemplo de cenário pertencente ao UdI do C&L.

O atributo restrição pode estar relacionado ao contexto, recursos ou

episódios de um cenário. Este atributo é utilizado para descrever aspectos não

funcionais que podem interferir na qualidade com que o objetivo de um cenário é

alcançado. É importante ressaltar que este atributo não impede a satisfação do

objetivo do cenário. No cenário apresentado na Tabela 3, por exemplo, há a

restrição "os dados devem estar completos" associada ao episódio três. Neste

caso, mesmo que o usuário informe parcialmente os dados, o objetivo do cenário

será alcançado, isto é, o projeto será criado. Porém, a qualidade da

representação do UdI será menor se os dados informados forem muito

superficiais.

Uma exceção pode interromper o fluxo normal de execução dos episódios

de um cenário. Cada exceção deve ser descrita através de uma sentença

simples que deve identificar a causa da interrupção e como tratá-la. O

tratamento da interrupção não precisa necessariamente fazer com que o objetivo

do cenário seja alcançado.

Uma característica importante dos cenários é a existência de

relacionamentos entre eles. Segundo Breitman (Breitman, 2000), cenários estão

ligados a outros cenários através de elos, formando uma complexa rede de

relacionamentos. Estes elos podem ser de quatro tipos distintos: subcenário,

precondição, exceção e restrição.

Um cenário é considerado subcenário de outro quando aparece em pelo

menos um de seus episódios. Este relacionamento é útil quando:


Um comportamento comum é detectado em vários cenários do mesmo

UdI. Neste caso, o comportamento é isolado em um novo cenário e este

passa a ser referenciado pelos outros que possuíam o comportamento.

Desta forma é possível reduzir a redundância de informações e,

consequentemente, todos os problemas decorrentes dela.

Há um curso de ação, que pode ser alternativo ou condicional, dentro de

uma situação do UdI. Quando isto ocorre, podemos separar este

comportamento em um novo cenário, o que possibilita um melhor

detalhamento e, consequentemente, facilita sua compreensão.

É preciso melhorar a descrição de uma situação que possui um objetivo

importante e bem definido dentro de sua descrição. Diante disto, é

possível destacar este objetivo e criar um novo cenário para detalhá-lo,

facilitando desta forma tanto sua descrição quanto entendimento.

A precondição é um relacionamento definido dentro do componente

contexto de um cenário, isto é, um cenário que atua como precondição para

outro deve aparecer dentro de seu contexto. Este relacionamento nos permite

estabelecer de forma objetiva uma ordem entre os cenários, possibilitando a

especificação de estágios que devem ser completados antes da execução de

outros. Um exemplo deste relacionamento pode ser visto no cenário descrito na

Tabela 3, onde o cenário "autenticar usuário" é precondição para "criar projeto

no C&L". Para destacar o relacionamento, o título do cenário que é referenciado

é escrito com letras maiúsculas.

Relações de exceção acontecem quando um cenário aparece no

componente exceção de outro. Este relacionamento nos permite detalhar melhor

tratamentos de exceção complexos através de outro cenário. Desta forma,

contamos com toda a estrutura de um cenário para detalhar o tratamento, ao

invés de resumi-lo em uma sentença simples.

O relacionamento de restrição é estabelecido quando utilizamos um novo

cenário com o objetivo de detalhar aspectos não funcionais que restringem o

funcionamento correto de outro cenário. Este relacionamento ocorre no atributo

restrição, que pode estar associado a recursos, contexto e episódios.


Figura 4. Grafo com símbolos do LAL e cenários.

O processo de construção de cenários para descrever situações do UdI

está intimamente relacionado ao LAL, técnica descrita na seção 2.1. Esta

relação existe, pois, ao descrever os cenários, é natural que os envolvidos

utilizem a linguagem do UdI, que é justamente o alvo da técnica LAL. Desta

forma, além de elos entre cenários, temos também elos entre cenários e

símbolos do LAL, facilitando ainda mais a compreensão dos cenários. Os

símbolos do LAL utilizados na descrição do cenário da Tabela 3 estão

sublinhados. Desta forma, por exemplo, se quiséssemos compreender melhor o

significado do termo "software" no UdI do C&L, bastaria olhar a definição destes

símbolos no LAL.

Extrapolando a ideia exposta na seção 2.1, de desenhar um grafo

utilizando os símbolos como vértices e os relacionamentos como arestas,

podemos desenhar um grafo contendo cenários e símbolos do LAL. A Figura 4

representa o grafo da Figura 2 com a adição de dois cenários, que estão

destacados juntamente com seus relacionamentos. O relacionamento entre dois

cenários também é representado através de uma aresta, que neste caso possui

o nome do relacionamento, como podemos ver no caso dos cenários "autenticar

usuário" e "criar projeto no C&L", onde o primeiro é precondição para o segundo.


2.3. Arquitetura Model View Controller (MVC)

O padrão arquitetural MVC foi proposto por Reenskaug (Reenskaug,

1979). Sua principal característica é uma organização, que promove a separação

da interface, lógica e dados do software. Reenskaug propôs a camada de

Controle (Controller) como um elo entre o usuário e o software. Este elo permite

o envio de informações do usuário para o software através de comandos e

dados. Também permite o fluxo inverso, isto é, a saída de informações através

da apresentação das interfaces apropriadas. A camada de Modelo (Model), por

sua vez, é utilizada para representar a base de conhecimento do software e

armazenar o seu estado corrente. Por fim, a camada de Visão (View) abarca

toda a representação visual da camada de modelo. Componentes desta camada

podem filtrar os dados obtidos da camada de Modelo, escondendo alguns

atributos e destacando outros. Os dados apresentados são obtidos diretamente

da camada de Modelo. Componentes da Visão também podem atualizar a

camada de Modelo, caso seja necessário. A arquitetura descrita anteriormente

está representada na Figura 5.

Figura 5. Diagrama da arquitetura MVC adaptado de (Reenskaug, 1979).

Uma das primeiras linguagens a explorar este padrão arquitetural foi

smalltalk-80 (Krasner e Pope, 1988). Segundo Krasner, esta divisão implica na

separação (i) das partes que representam o modelo do domínio do software (ii)

da forma com que ele é apresentado paro o usuário e (iii) do modo com que o

usuário interage com o software (Krasner e Pope, 1988). Esta organização é

interessante, pois, segundo o próprio autor, a separação destes conceitos facilita


o entendimento e a modificação de um componente, sem que seja necessário

conhecer o restante do software.

O padrão arquitetural MVC empregado neste trabalho é diferente do

explicado anteriormente, porém, a motivação para sua utilização é a mesma.

Como o contexto desta pesquisa é restrito a software Web, adotamos uma

variante do MVC que implementa a arquitetura em três camadas, comum neste

domínio. A principal diferença para a arquitetura proposta originalmente é a

adoção do conceito de camadas. Assim, cada camada da arquitetura só pode se

comunicar com aquelas adjacentes, como mostra a Figura 6. Além disto, esta

proposta também engloba o acesso ao banco de dados do software.

Normalmente, a camada que contempla os serviços relacionados a acesso ao

banco de dados é utilizada na forma de uma biblioteca, como representado

através da caixa DAL (Data Access Library) na Figura 6.

Figura 6. Arquitetura MVC proposta.

Devido às mudanças propostas, foi necessário mudar a definição de cada

camada, a fim de adaptá-las a nova abordagem. A seguir, descrevemos o

propósito de cada camada dentro desta nova abordagem.

Visão. Camada com a qual o usuário irá interagir diretamente. Os

dados ou comandos recebidos do usuário são repassados pela

camada de visão ao controle através de requisições HTTP. As

repostas recebidas através destas requisições são exibidas para o

usuário através de arquivos HTML, código Java Script e folhas de

estilo (CSS).


Controle. Recebe as requisições da camada de Visão. Contém a

lógica do software e, de acordo com a lógica, pode requisitar ou

atualizar dados da camada de Modelo. A comunicação entre

Controle e Modelo é realizada através de chamadas/retorno de

função.

Modelo. Encapsula o modelo conceitual do domínio. É a camada

responsável por manter o estado do software. Estabelece

comunicação com a base de dados através da biblioteca de acesso

a dados (DAL). A comunicação entre Modelo e DAL é realizada

através de chamada/retorno de função.

DAL (Data Access Library). Contempla todos os serviços para

acesso ao banco de dados do software. Comunica-se com o banco

de dados através de API específica para linguagem de

programação utilizada no desenvolvimento.

2.4. Catálogo de Transparência

É sabido que construir software é uma atividade complexa devido a muitos

fatores, como, por exemplo, o envolvimento de um grande número de pessoas

com conhecimentos variados. Outro motivo para tal complexidade é que, além

de estar de acordo com os requisitos funcionais, o software precisa satisfazer

metas de qualidade, que são, normalmente, modeladas como requisitos não

funcionais (RNF). A dificuldade em lidar com tais metas está em sua natureza

subjetiva e no fato de que possuem um impacto amplo no software.

Com o objetivo de lidar com esta complexidade, muitas técnicas foram

propostas para auxiliar no processo de desenvolvimento de software. Estas

técnicas abrangem tanto requisitos funcionais quanto os não funcionais

(Jackson, 2001; Chung et al., 2000; Bresciani e Perini, 2004; Lamsweerde,

2009). As abordagens orientadas a metas (Yu, 1996; Lamsweerde, 2009)

propõem modelar o software através de suas metas e seus relacionamentos.

Elas dão suporte à tomada de decisão e permitem a avaliação do impacto destas

decisões. Estas técnicas promovem as metas de qualidade a entidades de

primeira classe, estimulando os desenvolvedores a perseguir sua satisfação


durante o desenvolvimento do software. Normalmente, estes modelos são

produzidos exclusivamente para um software, sem que haja a preocupação de

reutilizar o conhecimento que foi adquirido. Entretanto, engenheiros de software

se beneficiariam de um conjunto de soluções premontadas para lidar com metas

de qualidade. Um caminho importante a ser seguido neste caso é o

desenvolvimento de catálogos, que listem as possíveis operacionalizações para

estas metas de qualidade.

O framework para RNF (NFR framework), proposto por Chung (Chung et

al., 2000) endossa as abordagens orientadas a metas. Em seu trabalho, Chung

modela RNFs como metas flexíveis (softgoals) que podem entrar em conflito

uma com as outras. Portanto, estas devem ser detalhadas e discutidas durante

os estágios iniciais do desenvolvimento de software, com o objetivo de se chegar

a soluções aceitáveis, que atendam as expectativas dos envolvidos. O principal

modelo do NRF framework é o Softgoal Interdependency Graph (SIG), que é

composto de vértices e elos, utilizados para representar as metas flexíveis e

seus relacionamentos. Os vértices podem representar três tipos de elementos:

metas flexíveis, operacionalizações e afirmações. O primeiro é utilizado para

representar os RNFs. O segundo para representar possíveis operacionalizações

que satisfazem a contento um RNF. O último é utilizado para justificar as

decisões tomadas com base no SIG.

No NFR framework as metas flexíveis são descritas por seu tipo e tópico.

Seu tipo indica a qualidade que está sendo representada e o tópico o contexto

em que é aplicada. No contexto de desenvolvimento de software, por exemplo,

poderíamos ter um NFR softgoal com tipo Rastreabilidade e o tópico Processo

de Desenvolvimento de Software. Os relacionamentos de interdependência

dentro do NFR framework podem ser explícitos ou implícitos. O primeiro

representa refinamentos ou contribuições, dependendo da direção do

relacionamento. Aqueles direcionados para baixo representam uma relação de

refinamento, onde uma meta flexível é detalhada por duas ou mais metas

flexíveis descendentes. As contribuições são representadas por relacionamentos

direcionados para cima e identificam o grau - que pode ser totalmente ou

parcialmente e positivo ou negativo - com que o descendente pode contribuir

para a satisfação a contento da meta flexível pai.

Uma das principais características do NFR framework são os catálogos. O

framework disponibiliza uma estrutura que permite organizar o conhecimento,

fazendo com que os desenvolvedores possam reutilizar o que foi aprendido em

experiências anteriores. Inicialmente, o NFR framework define três tipos distintos


de catálogo: Tipo, Método e Correlação. Um catálogo Tipo permite a

representação estruturada de conhecimento sobre uma meta flexível específica,

sem que um tópico seja definido. No SIG de Transparência (Figura 8), por

exemplo, a meta flexível transparência é decomposta em Acessibilidade,

Usabilidade, Entendimento, Auditabilidade e Informativo. A meta flexível

acessibilidade, por sua vez, é decomposta em Portabilidade, Disponibilidade e

Publicidade.

O catálogo Método permite a organização de catálogos contendo técnicas

de desenvolvimento, obtidas através da decomposição de metas flexíveis,

instanciação de operacionalizações e identificação de afirmações. Em seu

trabalho, Chung (Chung et al., 2000) exemplifica o uso do catálogo Método

através do refinamento "and" da meta flexível acurácia aplicada ao tópico conta

de banco (Acurácia [Conta]) em Acurácia [ContaRegular], Acurácia [ContaGold]

e Acurácia [ContaPremier]. Por fim, o catálogo Correlação permite a construção

de catálogos para inferir as possíveis interações entre metas flexíveis, tanto as

positivas quanto as negativas. No SIG de Transparência (Figura 8), por exemplo,

fica claro que a meta flexível Concisão contribui negativamente para a meta

flexível Detalhamento. Um SIG é composto de informações dos três tipos de

catálogo descritos. A Figura 8 mostra o SIG de transparência adaptado de

(Cappelli, 2009), onde é possível observar a estrutura proposta pelo NFR

framework para organizar as informações.

O conhecimento a cerca de metas flexíveis compreende, entre outros, o

seu refinamento e operacionalização, contribuições entre metas flexíveis,

questões que ajudam sua operacionalização e pontos de vista e organização de

questões em categorias. Como dito, apenas o SIG não é o suficiente para

representar este vasto e complexo conhecimento. Portanto, é necessária a

complementação do SIG com outros artefatos de requisitos. Porém, a

representação de informações em diferentes artefatos a tornaria mais difícil de

utilizar, manter e evoluir. Para lidar com este problema e instanciar o SIG para o

tópico [Software], criando desta forma o Catálogo de Transparência de Software

(Catálogo de Transparência de Software, 2013) o GrupoER (GrupoER, 2013)

propôs organizar o catálogo SIG como uma coleção de padrões RNF.

Os padrões RNF foram propostos por Supakkul (Supakkul et al., 2010),

com o propósito de reusar o conhecimento sobre RNFs. Em seu trabalho,

Supakkul define três padrões: Objetivo, Problema, Alternativa e Seleção. O

padrão Objetivo é utilizado para capturar a definição de RNFs em termos de

metas flexíveis. Os problemas e obstáculos para satisfazer a contento as metas


flexíveis são representados através do padrão Problema. Os diferentes meios de

satisfazer a contento as metas flexíveis e seus efeitos colaterais são descritos

pelo padrão Alternativa. Finalmente, temos o padrão Seleção, que dá suporte à

escolha de alternativas, utilizando analises qualitativas ou quantitativas. Nos

padrões RNF todo o conhecimento é representado através de uma estrutura

composta de três partes: Inicial, Resultado e Regras de Refinamento. A parte

Inicial captura os conceitos chaves, fornecendo o contexto necessário para o

reuso. O Resultado representa o conhecimento disponível sobre o RNF em

questão. As Regras de Refinamento capturam os refinamentos de modelos que

são feitos manualmente durante uma típica sessão de engenharia de requisitos,

onde novos elementos são adicionados ao modelo e relacionados com os já

existentes. Além dos padrões e regras, propostos por Supakkul, O GrupoER

propôs a criação de um novo padrão, chamado Questão. Duas novas Regras de

Refinamento também foram adicionadas àquelas propostas por Supakkul:

GroupIdentification e QuestionIdentification.

Figura 7. Fragmento do SIG de Transparência representado através do padrão

Objetivo.

No Catálogo de Transparência de Software, o SIG foi representado através

do padrão Objetivo. A seção Inicial do padrão define o tópico, que neste caso é

Transparência

Início Resultado

Regras de Refinamento

Transparência de Software Padrão Objetivo

R1: NFRIdentification(Software: Transparência [Software])

R2: NFRHelpDecomposition(Transparência , {Acessibilidade, Informativo, Usabilidade,

Entendimento, Auditabilidade})

Software Software

Acessibilidade

Usabilidade

Informativo

Entendimento

Auditabilidade

Controlabilidade Verificabilidade

Rastreabilidade

Help

Help

Hel

p

Help

Help

Help

HelpH

elp

R1

R2

R3

R3: NFRHelpDecomposition(Auditabilidade, {Controlabilidade, Verificabilidade,

Rastreabilidade})


[Software]. A seção Resultado, por sua vez, identifica a meta flexível principal e

sua decomposição. O modelo apresentado nesta seção é alcançado através das

Regras de Refinamento: NFRIdentification e NFRDecomposition. Na Figura 7, o

padrão Objetivo identifica a Transparência no contexto de software (Regra de

Refinamento R1) e então a meta flexível Transparência é decomposta em

Acessibilidade, Informativo, Usabilidade, Entendimento e Auditabilidade (Regra

de Refinamento R2). Por último, a meta flexível Auditabilidade é refinada em

Controlabilidade, Verificabilidade e Rastreabilidade (Regra de Refinamento R3).

Deste modo, fica claro que utilizando as regras NFRIdentification e

NFRDecomposition, é possível descrever todo o SIG de Transparência através

do padrão Objetivo.


Figura 8. SIG de Transparência, adaptado de (Cappelli, 2009).

Tra

nsp

arê

ncia

ace

ssib

ilid

ad

e

usa

bili

da

de

info

rma

tivo

en

ten

dim

en

to

au

dita

bili

da

de

Help

Help

Help

Help

po

rta

bili

da

de

dis

po

nib

ilid

ad

e

pu

blic

ida

de

Help

Help

un

ifo

rmid

ad

e

am

iga

bili

da

de

ad

ap

tab

ilid

ad

e

de

se

mp

en

ho

intu

itiv

ida

de

op

era

bili

da

de

sim

plic

ida

de

Help

Help Hel

p Hel

p

cla

reza

acu

rácia

inte

grid

ad

e

co

nsis

tên

cia

co

mp

ara

bili

da

de

atu

alid

ad

e

co

rre

tud

e

co

mp

lete

zaH

elp Hel

p

Help

Help

Help

Help

Help

Help

Help

Hel

p

Help

co

ncis

ão

co

ntr

ola

bili

da

de

va

lida

de

de

pe

nd

ên

cia

de

talh

am

en

to

div

isib

ilid

ad

e

co

mp

ositiv

ida

de

Help

Help

Help

Help

Help

exp

lica

çã

o

rastr

ea

bili

da

de

ve

rifica

bili

da

de

Help

Help

Help

Hel

p

Help

Help

Help


É necessário um cuidado especial quando refinamos uma meta flexível

através de elos de contribuição do tipo Help. Este tipo de elo significa que

satisfazer a contento uma meta flexível descendente, implica em uma

contribuição positiva a meta flexível pai. Todavia, não satisfazê-la a contento não

impede, necessariamente, a satisfação a contento da meta flexível pai. Porém,

há alguns casos especiais em que isso não é verdade. Analisando o primeiro

nível de metas flexíveis do SIG de Transparência, podemos perceber que a meta

flexível Acessibilidade é um destes casos especiais. A Transparência de

Software não pode ser alcançada sem que o software esteja acessível. Portanto,

neste caso, a impossibilidade de satisfazer a contento a meta flexível

Acessibilidade (descendente) deve levar ao impedimento da Transparência de

Software (pai). Para descrever este tipo de situação, o padrão Problema foi

utilizado. Este padrão foi originalmente criado por Supakkul (Supakkul et al.,

2010) para capturar o conhecimento sobre problemas especiais, que poderiam

obstruir a satisfação a contento de uma meta flexível ou de uma de suas

operacionalizações.

O Catálogo de Transparência de Software (CTS) também inclui uma lista

de operacionalizações para metas flexíveis folha (aquelas que não têm

descendentes) e mapeia o seu impacto em outras metas flexíveis. A principal

contribuição de se representar operacionalizações no SIG é o reuso, já que

ajudam a construção e avaliação de novos software. Com o objetivo de definir

quais operacionalizações eram importantes para a meta flexível principal, o

método Goal-Question-Metric (GQM) (Basili, 1992) foi adaptado para o Goal-

Question-Operationalization (GQO) pelo GrupoER (GrupoER, 2013). O método

GQM se inicia com metas para o software (ou desenvolvimento do software),

define questões para assegurar a satisfação destas metas e cria métricas para

permitir que as questões sejam respondidas de forma quantitativa. Em sua

adaptação, as métricas foram trocadas por operacionalizações. O GQO segue

uma abordagem de boas práticas, onde questões são agrupadas por categoria,

usando como base a proximidade de conceitos. Estas questões são respondidas

através da identificação de boas práticas da engenharia de software, que

operacionalizam as metas flexíveis folha. As questões e operacionalizações

fornecem pontos de variabilidade e extensão para o catálogo.

Como visto anteriormente, nosso foco neste trabalho será três metas

flexíveis específicas do catálogo, que são: Rastreabilidade, Dependência e

Detalhamento. Através de uma análise das questões relacionadas a estas metas

flexíveis, presente no CTS foi possível estabelecer sua relação com os


problemas de rastreabilidade entre artefatos de um software, definição de sua

organização modular e entendimento do software como um todo. Para uma

melhor identificação, destacamos estas metas flexíveis na Figura 8. Através da

Figura 9, apresentamos o padrão Questão aplicado a Rastreabilidade. Como É

possível observar, foram criadas três categorias para organizar as questões

relacionadas à meta flexível: pré-rastreabilidade, rastreabilidade em tempo de

desenho e rastreabilidade em tempo de execução.

Figura 9. Padrão Questão de Rastreabilidade.

Na Figura 10, apresentamos as categorias e questões referentes à meta

flexível Dependência, que foi detalhada através de três categorias: informação,

acoplamento e coesão. Por fim, na Figura 11, exibimos as questões relacionadas

à meta flexível Detalhamento. Estas questões foram agrupadas através de três

categorias: usar estruturação de dados (variáveis) / funções (comandos), usar

nomes adequados e explicar o software. As questões e categorias associadas a

todas as outras metas flexíveis podem ser consultadas em (Catálogo de

Transparência de Software, 2013).

Rastreabilidade

Inicial Resultado


Padrão Questão Rastreabilidade

R1: GroupIdentification(Rastreabilidade, {Pré-rastreabilidade,

Pré-rastreabilidade, Rastreabilidade em

tempo de execução})

R2:

QuestionIdentification(Prerastreabilidade,

{As fontes de informação podem ser

rastreadas?, Os recursos utilizados ou que

serão necessários podem ser rastreados?,

As questões sociais, como eventos e redes

sociais, podem ser rastreadas?, As

principais metas e preocupações dos

envolvidos podem ser rastreadas? })

segue

R1

R2

Rastreabilidade

Pré-rastreabilidade Rastreabilidade em tempo de desenho

Rastreabilidade em

tempo de execução

As fontes de informação podem

ser rastreadas?

Os recursos utilizados ou que

serão necessários podem ser

rastreados?

As questões sociais, como

eventos e redes sociais, podem

ser rastreadas?

As principais metas e

preocupações dos envolvidos

podem ser rastreadas?

Os rastros entre diferentes

documentos da Engenharia de

Software são mantidos?

Os rastros entre diferentes

versões do mesmo documento

são mantidos?

O raciocínio por trás das

tomadas de decisão são

rastreados?

As questões sociais em tempo

de desenho são rastreadas?

As fontes dos dados

são anotadas?

As modificações/

atualizações dos

dados são

rastreadas?

São mantidos os

rastros dos processos

executados/

aplicados?

R3:

QuestionIdentification(Rastreabilidade

em tempo de desenho, {Os rastros entre

diferentes documentos da Engenharia

de Software são mantidos?, Os rastros

entre diferentes versões do mesmo

documento são mantidos?, O raciocínio

por trás das tomadas de decisão são

rastreados?, As questões sociais em

tempo de desenho são rastreadas?})

segue

R4:

QuestionIdentification(Rastreabilidad

e em tempo de execução, As fontes

dos dados são anotadas?, As

modificações/atualizações dos

dados são rastreadas?, São

mantidos os rastros dos processos

executados/aplicados?})

segue

R3 R4

Transparência

He

lpH

elp

Auditabilidade


Figura 10. Padrão Questão de Dependência.

Figura 11. Padrão Questão de Detalhamento.

Dependência

Início Resultado


Padrão Questão Dependência

R1: IdentificaçãodeGrupos(Dependência, {Informação, Acoplamento, Coesão})

R2:

IdentificaçãodeQuestões(Infor

mação, {Existe diagrama de

pacote?, Existe arquivo de

gerência de configuração(i.e.

local onde os arquivos do

código sejam descritos)?,

Existe sistema de controle de

versão/configuração?})

segue

R1

R2

Transparência

Informação Acoplamento Coesão

Existe diagrama de

pacote?

Existe arquivo de

gerência de

configuração(i.e. local

onde os arquivos do

código sejam descritos)?

Existe sistema de

controle de versão/

configuração?

As dependências internas de cada

parte foram identificadas? (ex:

utilização de subpartes)

As dependências externas de cada


utilização de bibliotecas)

As dependências externas ao todo

foram identificadas? (ex: utilização

de serviços)

A interdenpendência entre as

partes é consistente? (ex: verificar

se todas as dependências entre as

partes foram identificadas)

O significado das

variáveis de cada parte

é identificado?

O local de criação das

variáveis é

identificado?

O local onde as

variáveis são usadas é

identificado?

R3:

IdentificaçãodeQuestões(Acoplamento

, {As dependências internas de cada


utilização de subpartes), As

dependências externas de cada parte

foram identificadas? (ex: utilização de

bibliotecas), As dependências externas

ao todo foram identificadas? (ex:

utilização de serviços), A

interdenpendência entre as partes é

consistente? (ex: verificar se todas as

dependências entre as partes foram

identificadas)})

segue

R4:

IdentificaçãodeQuestões(C

oesão, {O significado das

variáveis de cada parte é

identificado?, O local de

criação das variáveis é

identificado?, O local onde

as variáveis são usadas é

identificado?})

segue

R3 R4Dependência

Help

Entendimento

He

lp

Detalhamento

Início Resultado


Padrão Questão Detalhamento

R1: GroupIdentification(Detalhamento, {Usar estruturação de dados(variáveis) / funções (comandos) , Usar nomes adequados,

Explicar o software})

R2: QuestionIdentification(Usar

estruturação de dados(variáveis) /

funções (comandos) , {A taxonomia

(uso de classes) está explicada?, A

mereologia (uso de relações todo

parte) está explicada?, Os axiomas

(relacionamentos restritivos) estão

explicados?})

segue

R1

R2

Transparência

Usar estruturação de dados(variáveis) /

funções (comandos)

Usar nomes adequados Explicar o software

A taxonomia (uso de classes)

está explicada?

A mereologia (uso de

relações todo parte) está

explicada?

Os axiomas (relacionamentos

restritivos) estão explicados?

Os nomes são inteligíveis?

Os nomes seguem um padrão?

Os tamanhos dos nomes são

adequados(não muito longos)?

O nome é adequado para o

significado?

O código está explicado?

A arquitetura está explicada?

Os requisitos funcionais

estão explicados?

Os requisitos não funcionais

estão explicados?

R3: QuestionIdentification(Usar

nomes adequados, {Os nomes são

inteligíveis?, Os nomes seguem um

padrão?, Os tamanhos dos nomes

são adequados(não muito longos)?,

O nome é adequado para o

significado?})

segue

R4: QuestionIdentification(Explicar

o software, {O código está

explicado?, A arquitetura está

explicada?, Os requisitos funcionais

estão explicados?, Os requisitos

não funcionais estão explicados?})

segue

R3 R4

Detalhamento

Help

Entendimento

Help


2.5. Conclusão

Neste capítulo, foram apresentados os conceitos que serviram como base

para a construção do processo PDS+T, que é apresentado a seguir. O Léxico

Ampliado da Linguagem e os cenários são duas técnicas da engenharia de

requisitos que possuem propósitos distintos. A primeira, foca na descrição da

linguagem utilizada pelos atores do UdI, sem se preocupar em descrever o

problema em si. A segunda tem como objetivo o detalhamento do problema,

através da descrição das situações do UdI. Esta descrição é realizada através de

uma estrutura bem definida, que permite a identificação dos recursos e atores da

situação e seu detalhamento passo a passo. Estas abordagens foram utilizadas

em conjunto, pois têm uma ligação muito estreita, já que os cenários são

descritos através do uso dos termos identificados no LAL. Também foi

apresentado o padrão arquitetural MVC, no qual nos baseamos para criar a

arquitetura dos software construídos a partir do processo PDS+T. Este padrão

sugere a organização do software em três camadas, isolando a interface para

interação com o usuário do modelo conceitual e regras de negócio

implementadas pelo software. Por fim, descrevemos como surgiu o Catálogo de

Transparência de Software (Catálogo de Transpa

eduardo kinder almentero dos requisitos ao código: um …julio/tese-eduardo.pdf · 2014. 4. 1. ·...

Documents