DEPARTAMENT PROGRAMA DE
MEST
: Uma
par
Transversais
NTO DE INFORMÁTICA E MATEMÁTICA A E PÓS/GRADUAÇÃO EM SISTEMAS E COM ESTRADO EM SISTEMAS E COMPUTAÇÃO
a Abordagem Baseada em
ara a Identificação de Inte
sais em Documentos de Re
Larissa de Alencar Sobral
Natal/RN
Fevereiro de 2013
APLICADA MPUTAÇÃO
em
Interesses
: Uma Abordagem Baseada em
para a Identificação de Interesses Transversais em
Documentos de Requisitos
Dissertação de Mestrado apresentada ao Programa de Pós/Graduação em Sistemas e Computação do Departamento de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Sistemas e Computação.
Engenharia de Software
Orientadora
Prof.ª Dr.ª Lyrene Fernandes da Silva
PPgSC – Programa de Pós/Graduação em Sistemas e Computação
DIMAp – Departamento de Informática e Matemática Aplicada
CCET – Centro de Ciências Exatas e da Terra
UFRN – Universidade Federal do Rio Grande do Norte
Natal/RN
Agradecimentos
Primeiramente agradeço a Deus por sempre se fazer tão presente em minha vida e por me conceder, ao longo da minha existência, todas as bênçãos que alguém poderia desejar. Se eu cheguei até aqui, é porque Deus esteve comigo em todos os momentos.
Em segundo lugar, agradeço aos meus pais por, simplesmente, serem os melhores do mundo (em tudo!). Os melhores pais, os melhores exemplos, os melhores companheiros, os melhores amigos, os melhores professores, os melhores amores que qualquer pessoa poderia ter. Nenhuma palavra seria capaz de expressar minha gratidão, meu amor e minha admiração por vocês. Obrigada pelo amor sempre incondicional e pela dedicação sem limites. Vocês são, e sempre serão, as pessoas mais importantes da minha vida.
Agradeço também a minha orientadora, Professora Lyrene, pela enorme competência, atenção e paciência que dispôs a cada etapa deste trabalho, desenvolvido ao longo dos últimos dois anos.
Agradeço ao meu irmão Rafael por ter, de seu jeito particular, me incentivado e me ajudado, me fazendo dar boas risadas até nas piores horas. A “depressiva do mestrado”, finalmente, chegou ao fim! Obrigada por ser o melhor irmão do mundo!
Agradeço ao meu namorado Renan por ter sido meu ombro amigo, meu psicólogo e meu companheiro ao longo desta jornada. Obrigada pelas milhares de horas que me ouviu falar sem parar, por ter enxugado minhas lágrimas, por ter sido extremamente paciente, por ter acreditado em mim quando nem eu mesma acreditava. Você é o melhor namorado do mundo!
As professoras Márcia Lucena e Thais Batista, pelas valiosas considerações feitas na ocasião da qualificação deste trabalho e, principalmente, pelo incentivo e ajuda que me forneceram ao longo deste Mestrado.
Aos meus amigos de toda a vida, em especial Bia, Gobyh e Moura, que me incentivaram, me apoiaram, acreditaram em mim e nunca levaram a sério meus momentos de desespero. Obrigada por serem sempre tão presentes.
Aos colegas e amigos que fiz durante o Mestrado. Em especial agradeço àqueles que participaram do Estudo Experimental realizado neste trabalho: Aline, Ana Luíza, Daniel Aguiar, Daniel Alencar, Everton, Eliezio, Maíra, Romeu e Tainá.
A CAPES pelo apoio financeiro despendido a este trabalho.
!
: Uma Abordagem Baseada em
para a Identificação de Interesses Transversais em
Documentos de Requisitos
Autora: B. Sc. Larissa de Alencar Sobral
Orientadora: Prof.ª Dr.ª Lyrene Fernandes da Silva
R
ESUMO
Quando a identificação de interesses transversais é feita desde o princípio do processo de desenvolvimento de , ainda nas atividades relacionadas à Engenharia de Requisitos, muitos são os ganhos em termos de qualidade, custo e eficiência ao longo do ciclo de vida do . Esta identificação precoce dá suporte à evolução de requisitos, detecta possíveis falhas na especificação de requisitos, melhora a rastreabilidade entre os requisitos, proporciona uma melhor modularização de e previne possíveis retrabalhos. Entretanto, apesar de todas estas vantagens, a identificação de interesses enfrenta diversas dificuldades, tais como a falta de sistematização e de ferramentas que a ofereçam um bom suporte. Além disto, é difícil, muitas vezes, justificar as razões pelas quais alguns interesses são ou não considerados transversais, uma vez que esta identificação é, na maioria das vezes, feita sem qualquer metodologia que a sistematize e a embase. Neste contexto, este trabalho propõe uma abordagem baseada nos princípios da
, chamada GT4CCI, que sistematiza e embasa o processo de identificação de interesses transversais nas etapas mais iniciais do processo de desenvolvimento de , utilizando o documento de requisitos como artefato para a identificação. é uma renomada metodologia para a análise qualitativa de dados. Através do uso da abordagem GT4CCI é possível melhor compreender, rastrear e documentar interesses, adicionando assim ganhos em termos de qualidade, confiabilidade e modularização à todo o ciclo de vida do software.
: A Grounded Theory/Based Approach for the
Identification of Crosscutting Concerns in Requirements
Documents
Author: Larissa de Alencar Sobral, B.Sc.
Supervisor: Lyrene Fernandes da Silva, D.Sc.
A
BSTRACT
When crosscutting concerns identification is performed from the beginning of development, on the activities involved in requirements engineering, there are many gains in terms of quality, cost and efficiency throughout the lifecycle of software development. This early identification supports the evolution of requirements, detects possible flaws in the requirements specification, improves traceability among requirements, provides better software modularity and prevents possible rework. However, despite these several advantages, the crosscutting concerns identification over requirements engineering faces several difficulties such as the lack of systematization and tools that support it. Furthermore, it is difficult to justify why some concerns are identified as crosscutting or not, since this identification is, most often, made without any methodology that systematizes and bases it. In this context, this paper proposes an approach based on Grounded Theory, called GT4CCI, for systematizing and basing the process of identifying crosscutting concerns in the initial stages of the software development process in the requirements document. Grounded Theory is a renowned methodology for qualitative analysis of data. Through the use of GT4CCI it is possible to better understand, track and document concerns, adding gains in terms of quality, reliability and modularity of the entire lifecycle of software.
Lista de figuras
Figura 1. Codificação Aberta Aplicada ao Trecho da Entrevista ... 20
Figura 2. Gráfico resultante da Codificação Seletiva aplicada à Entrevista ... 21
Figura 3. Tela Inicial da Versão 7.0 da Ferramenta Atlas.ti ... 22
Figura 4. Fluxograma da Abordagem GT4CCI ... 29
Figura 5. Codificação Aberta no Documento do Sistema de Tratamento de Dados Numéricos ... 30
Figura 6. Etapas da Codificação Axial aplicada entre os códigos "Func: Exibir Maior Dado" e "Persistência" ... 32
Figura 7. Gráfico gerado a partir da aplicação da codificação seletiva no código "RNF: Persistência". ... 35
Figura 8. Gráfico gerado a partir da aplicação da codificação seletiva no código "RNF: Multi/Acesso" ... 36
Figura 9. Gráfico gerado a partir da aplicação da codificação seletiva no código "Func: Exibir Maior Dado"...38
Figura 10. Gráfico gerado a partir da aplicação da codificação seletiva no código "Func: Manter Log de Uso do Sistema"...39
Figura 11. Trecho da Codificação Aberta no documento CMS ... 44
Figura 12. Gráfico referente à categoria central “Availability”... 46
Figura 13. Gráfico referente à categoria central Security"...47
Figura 14. Gráfico referente à categoria central “% & ' ”...48
Figura 15. Gráfico referente à categoria central “% ( )* ' + ” ... 49
Lista de Tabelas
Tabela 1. Conectores de Códigos adaptado de (BANDEIRA/DE/MELLO, 2006) ... 19
Tabela 2. Tabela de Resultados do Sistema de Tratamento de Dados Numéricos ... 40
Tabela 3. Trecho da Tabela de Resultados do Documento de Requisitos CMS ... 51
Tabela 4. Tabela de Divisão dos Participantes por Grupos ... 55
Tabela 5. Questões de Pesquisa ... 57
Tabela 6. Distribuição de Interesses entre Grupos e Participantes ... 60
Tabela 7. Tabela de Precisão e Recall do Grupo I# + )* ... 63
Tabela 8. Tabela de Precisão e Recall do Grupo II / Agendador de Reuniões ... 65
Tabela 9. Tabela dos Resultados Encontrados em Herrera , (2012) e Sampaio , (2007) ... 66
Tabela 10. Respostas dos Participantes para os Questionamentos 1, 2 e 3. ... 68
Tabela 11. Respostas dos Participantes para os Questionamentos 4 e 5. ... 70
Tabela 12. Respostas dos Participantes para o Questionamento 7 ... 74
Tabela 13. Respostas dos Participantes para o Questionamento 8 ... 75
Tabela 14. Respostas dos Participantes para o Questionamento 9 ... 76
Tabela 15. Respostas dos Participantes para o Questionamento 10 ... 76
Tabela 16. Respostas dos Participantes para o Questionamento 11 ... 77
Sumário
1.1 Motivação ... 14
1.2 Objetivo ... 16
1.3 Organização do Trabalho ... 17
2.1 ... 18
2.1.1 Processo de Análise de Dados ... 19
2.1.2 Ilustração do Uso de ... 20
2.1.3 Ferramenta Atlas.ti ... 22
2.2 Interesses Transversais ... 23
2.3 Identificação de Interesses Transversais ... 24
3.1 GT4CCI: 1ª Etapa / Codificação Aberta... 30
3.2 GT4CCI: 2ª Etapa / Codificação Axial ... 31
3.3 GT4CCI: 3ª Etapa /Codificação Seletiva ... 33
3.4 GT4CCI: 4ª Etapa /Análise do Gráfico ... 34
3.4.1 Análise do Gráfico: “RNF: Persistência” ... 35
3.4.2 Análise do Gráfico: “RNF: Multi/Acesso” ... 36
3.4.3 Análise do Gráfico: “Func: Exibir Maior Dado” ... 37
3.4.4 Análise do Gráfico: “Func: Manter Log de Uso do Sistema” ... 37
3.5 GT4CCI: 5ª Etapa /Criação da Tabela de Resultados ... 38
4.2 Aplicação de GT4CCI no CMS ... 43
4.2.1 Codificação Aberta no CMS... 43
4.2.2 Codificação Axial no CMS ... 45
4.2.3 Codificação Seletiva no CMS ... 45
4.2.4 Análise do Gráfico no CMS ... 45
,., ,& / / 0 ! ... 46
,., ,. / / - ! ... 47
,., ,1 / / % & ' ! ... 48
,., , / / % ( )* ' + ! ... 49
4.2.5 Criação da Tabela de Resultados no CMS ... 50
4.3 Discussão dos Resultados ... 52
& ! " & 5.1 Objetivo ... 53
5.2 Planejamento do Estudo Experimental ... 53
5.2.1 Participantes ... 53
5.2.2 Documentos de Requisitos ... 55
5.2.3 Questões de Pesquisa ... 56
5.2.4 Preparação do Ambiente e Treinamento do Estudo Experimental ... 57
5.3 Execução do Estudo Experimental ... 58
5.4 Análise dos Dados ... 61
5.5 Ameaças à Validade ... 79
5.5.1 Validade Interna ... 79
5.5.2 Validade Externa ... 80
6.1 Abordagem Theme/Doc ... 81
6.2 Identificação de # através de UML ... 83
6.3 Método DISCERN ... 85
6.4 Early/AIM (Early Aspects Identification Method) ... 87
6.5 Identificação Automatizada de # Utilizando Processamento de Linguagem Natural (CCCINPL) ... 88
6.6 Tabela Comparativa das Abordagens ... 91
* + , -7.1 Contribuições ... 94
7.2 Trabalhos Futuros ... 96
) . / -*
!/ 0 1 ! " 2
!/ 0 # ) 3 4 2
!/ 0 # ) 3 4 ) + 2*
1 Introdução
A Engenharia de Requisitos (ER) envolve diversas atividades relevantes no ciclo de vida do desenvolvimento de software, tais como elicitação, análise, especificação e validação de requisitos. O objetivo principal da ER é especificar os requisitos desejados, para que haja um melhor entendimento sobre as funcionalidades, propriedades e limitações do sistema a ser desenvolvido (Pressman, 1992). De acordo com Chung , (1995), a ER tem se tornado cada vez mais fundamental para a resolução dos problemas encontrados nas organizações com relação à definição de sistemas, uma vez que requisitos deficientes são a maior causa de falhas nos projetos de software.
No domínio da Engenharia de Requisitos, uma área relativamente nova surgiu e despertou interesse e pesquisa nos últimos anos: a Engenharia de Requisitos Orientada a Aspectos (EROA) (Rashid, 2008). Baseada nos fundamentos do desenvolvimento orientado a aspectos, a EROA trabalha os interesses transversais ainda durante a aplicação da Engenharia de Requisitos. Isto proporciona meios para a identificação, modularização, composição e análise da influência destes interesses transversais nos outros requisitos presentes em um (Ali e Kasirum,, 2008/B).
Ainda de acordo com Ali e Kasirum (2008/B), de forma bastante sucinta, pode/ se afirmar que interesses transversais são partes de um que estão espalhadas por outras partes e entrelaçadas a outras partes deste mesmo . Em termos de requisitos, estes interesses podem ser funcionais ou não/funcionais e tem características bastante variáveis. Enquanto alguns destes são óbvios e, por isto, facilmente identificáveis, outros são sutis e difíceis de serem identificados. Uma vez identificados, os interesses transversais são separados e, a partir desta separação, é possível que tais interesses sejam analisados, modelados e implementados separadamente. Em seguida, estes interesses, analisados e tratados de maneira separada são novamente integrados de forma completa e coerente, através da composição de interesses transversais.
1.1 Motivação
Identificar e documentar interesses transversais no início do ciclo de vida do software, isto é, ainda nas etapas propostas pela Engenharia de Requisitos, é essencial. Esta atitude proporciona grande melhoria na rastreabilidade entre requisitos, permite a detecção de possíveis falhas na especificação dos requisitos, facilita a avaliação do impacto de mudança no sistema, facilita as evoluções de requisitos, melhora a modularização do sistema, previne possíveis retrabalhos, entre outras vantagens. (Ali e Kasirum 2008/A)
De acordo com Rosenhainer (2004), apesar de todos estes pontos favoráveis, a identificação de interesses transversais em nível de requisitos tem sido negligenciada em grande parte dos projetos de software. Além disto, a identificação de interesses enfrenta diversas dificuldades, tais como a falta de sistematização e de ferramentas que ofereçam um bom suporte. Também é difícil, muitas vezes, justificar as razões pelas quais alguns interesses são ou não considerados transversais, uma vez que esta identificação é, na maioria das vezes, feita sem qualquer metodologia que a sistematize e a embase.
Diante destas vantagens e dificuldades, segundo Rosenhainer (2004), foi percebida a necessidade do desenvolvimento de abordagens que dessem suporte a identificação de interesses transversais ainda nas etapas mais iniciais do processo de desenvolvimento de . Estas abordagens, tais como Abordagem Theme/DOC (Baniassad e Clarke, 2004), Identificação de # através de UML (Araújo et al, 2002; Araújo e Moreira 2003; Brito, 2004), Método DISCERN (Rosenhainer, 2005), Early/AIM (Sampaio et al., 2005/A) e CCCINPL (Ali e Kasirum, 2008/B) possuem a finalidade de sistematizar, cada uma a sua maneira, a identificação destes interesses. Esta sistematização faz com que este processo, que costuma ser tedioso e, por muitas vezes, complexo, ganhe em termos de qualidade, celeridade e confiabilidade.
seja feita de forma completa, uma vez que muitas particularidades de um dado documento só podem ser detectadas através do entendimento de seu contexto.
De acordo com Sampaio . (2005) uma outra limitação identificada nas abordagens já existentes para a identificação de interesses transversais voltada à requisitos é que estas são, em sua grande maioria, ineficientes quando os documentos de requisito são complexos e/ou desestruturados. Algumas destas dependem de mecanismos específicos para sua aplicação, tais como ferramentas, que impõe uma estrutura específica para os documentos a serem analisados. Assim, para que um documento possa ser analisado pela abordagem, ele precisa estar formatado de acordo com o padrão pré/estabelecido por ela.
Outra barreira encontrada em algumas destas abordagens é a restrição nos dados a serem analisados. No caso da abordagem DISCERN (Rosenhainer, 2005), por exemplo, a análise fica inteiramente limitada aos requisitos não/funcionais pertencentes ao documento de requisitos em questão. Desta forma, todos os outros dados presentes naquele documento são ignorados, o que pode acarretar em uma séria perda de qualidade e confiabilidade na identificação destes interesses transversais.
Por fim, duas últimas limitações podem, também, ser ditas principais nas abordagens já existentes. A primeira delas é referente ao fato de que algumas das abordagens já existentes não possuem qualquer suporte ferramental que a automatizem, tornando sua aplicação totalmente manual e, desta forma, mais suscetível a falhas. A segunda delas é o fato de que estas não oferecem documentação dos resultados obtidos através da sua aplicação.
Considerando as vantagens percebidas na identificação de interesses transversais ainda nas etapas relacionadas à Engenharia de Requisitos, as dificuldades inerentes deste processo de identificação e as limitações encontradas nas abordagens já existentes, este trabalho apresenta uma nova abordagem, chamada GT4CCI. A abordagem GT4CCI, acrônimo de
, sistematiza, aprimora e dá suporte a identificação e a documentação de interesses transversais ainda nas etapas mais iniciais do ciclo de desenvolvimento de , tornando/as mais confiáveis e embasadas.
• é baseada na análise contextual de dados, o que torna a análise bastante completa e consistente, uma vez que considera o contexto no qual os interesses estão inseridos;
• baseia seus resultados estritamente nos dados contidos no documento analisado, consequentemente os resultados obtidos a partir da análise podem ser facilmente rastreados;
• não se limita à análise de documentos que foram previamente estruturados de acordo com qualquer padrão pré/definido. Isto significa que com o uso da é possível fazer a análise de qualquer documento já desenvolvido, independente da sua estruturação;
• não restringe os dados a serem analisados. Desta maneira, pode/se concluir que a análise não fica limitada a um único tipo de interesse, como, por exemplo, requisitos não/funcionais ou casos de uso, ignorando os outros interesses presentes no documento. O uso desta metodologia permite a análise de qualquer dado considerado relevante no documento de requisitos;
• Há ferramentas que dão suporte ao processo proposto pela , automatizando algumas de suas atividades.
A partir da percepção destes ganhos advindos do uso da , é possível perceber que a abordagem GT4CCI surge como uma alternativa para as abordagens já existentes, uma vez que estes ganhos sanam, ou pelo menos amenizam, diversas das limitações encontradas.
A abordagem GT4CCI utiliza o documento de requisitos gerado a partir da elicitação de requisitos de um dado como artefato de entrada para a análise e a identificação de interesses transversais. Através do uso desta abordagem é possível melhor rastrear os requisitos dentro de um dado documento, obter uma boa documentação destes requisitos e das relações existentes entre eles, detectar possíveis falhas na elaboração dos documentos, e também melhor embasar e entender as razões pelas quais um dado interesse pode, ou não, ser dito transversal. Diante disto, acredita/se que haja significativos ganhos em termos da qualidade, confiabilidade e modularização tanto do quanto do documento de requisitos em desenvolvimento.
1.2 Objetivo
Considerando as questões supramencionadas, o objetivo principal deste trabalho é especificar e avaliar uma nova abordagem, a GT4CCI, para a identificação de interesses transversais em documentos de requisitos, baseando/se nos princípios
Além de basear/se no processo proposto pela que inclui as etapas de Codificação Aberta, Codificação Axial e Codificação Seletiva, a abordagem GT4CCI inclui duas novas etapas, a Análise do Gráfico e a Criação da Tabela de Resultados, não inerentes a este processo. Estas novas etapas, próprias da abordagem GT4CCI, possuem o objetivo de tornar a identificação e a documentação de interesses transversais mais prática, embasada e mais bem documentada. Além destas novas etapas, a abordagem GT4CCI também estabelece heurísticas próprias para a identificação de interesses transversais.
GT4CCI utiliza o documento gerado a partir da elicitação de requisitos de um como base para a análise e identificação destes interesses transversais. Desta forma, visa/se sistematizar e aperfeiçoar, através desta abordagem, o processo de identificação e de documentação destes interesses. Assim, o uso da abordagem proporciona uma boa documentação de interesses e suas relações, uma determinação da transversalidade dos interesses embasada e confiável, o aumento na rastreabilidade dos requisitos dentro do documento de requisitos e a possibilidade de detectar possíveis falhas e/ou negligências na elaboração do documento de requisitos analisado. A partir disto, acredita/se que haja ganhos em termos de qualidade, confiabilidade e modularização durante o ciclo de desenvolvimento de
.
1.3 Organização do Trabalho
A presente Dissertação de Mestrado possui seis capítulos que se somam a esta introdução. O Capítulo 2 apresenta os conceitos básicos que alicerçam o assunto apresentado neste trabalho, basicamente organizados em três vertentes principais: (i) , (ii) Interesses transversais e (iii) Identificação de Interesses transversais. O Capítulo 3 trata da especificação da abordagem proposta por este trabalho, a abordagem GT4CCI, apresentando, inclusive, um exemplo genérico de sua aplicação. No Capítulo 4 é apresentado um exemplo demonstrativo utilizando o documento de requisitos elaborado para um Sistema de Gestão de Crises.
2 Conceitos Básicos
Nesse capítulo são apresentados conceitos que fundamentam o trabalho realizado. Desta forma, será feita uma pequena introdução a respeito dos principais conceitos sobre (Seção 2.1), Interesses Transversais (Seção 2.2), Identificação de Interesses Transversais (Seção 2.3), sendo estes os três pontos centrais deste trabalho.
2.1
, também chamado de Teoria Fundamentada nos Dados, é uma metodologia de pesquisa qualitativa que se utiliza de processos sistemáticos para coleta e análise de dados a fim de gerar, elaborar e validar teorias, principalmente sobre fenômenos sociais (Bandeira/de/Mello, 2006).
Ainda de acordo com Bandeira/de/Mello (2006), pode/se definir teoria, de maneira bastante simplificada, como um conjunto integrado de proposições que explicam a ocorrência de um dado fenômeno. Essencialmente,
propõe que teorias emergem de dados, ou seja, que essas são derivadas de dados sistematicamente coletados e analisados.
Esta metodologia foi desenvolvida por dois pesquisadores, Glaser e Strauss (Glaser l., 1967). Entretanto, seus criadores divergiram em alguns pontos e o método dividiu/se em duas vertentes. A primeira delas (Glaser, 1992), proposta por Glaser, dá ênfase às características emergentes da metodologia e aos processos indutivos. A segunda vertente, defendida por Strauss (Strauss, 1987), foca na sistematização dos métodos de coleta e de análise de dados. Essa última é a vertente na qual este trabalho está baseado, uma vez que essa tem seu foco totalmente voltado à coleta e análise de dados.
Ainda de acordo com a linha proposta por Strauss, é baseada na ideia de codificação, que fundamenta o processo da análise de dados. Durante a codificação são identificados conceitos, também chamado de códigos, e categorias. Um conceito tem a função de identificar um fenômeno de interesse para o pesquisador; abstrai um evento, ação, objeto ou interação que tem algum significado para o pesquisador. Já categorias são agrupamentos de conceitos unidos em um grau de abstração mais alto (Strauss ,, 1998).
e na Seção 2.1.3 é feita uma breve introdução sobre a ferramenta Atlas.ti, utilizada por este trabalho para a aplicação da abordagem GT4CCI.
2.1.1 Processo de Análise de Dados
O processo de codificação é dividido em três etapas: codificação aberta, axial e seletiva (Conte , 2009). A codificação aberta envolve a análise, a quebra, a comparação, a conceituação e a categorização dos dados. Nas fases iniciais da etapa de codificação aberta o pesquisador explora os dados examinando minuciosamente aquilo que lhe parece relevante a partir da leitura intensiva dos textos em questão. Nesta fase os dados são agrupados em códigos e as categorias, que tem a função de agregar estes códigos, são criadas (Bandeira/de/Mello, 2006).
Após a codificação aberta é aplicada a codificação axial. Nesta fase são examinadas as relações entre as categorias que formam as proposições da teoria. Nesta fase também são estabelecidas, através de conectores, as relações dos códigos entre si e as relações entre códigos e categorias. A Tabela 1, adaptada de (Bandeira/ de/Mello, 2006), exibe uma sugestão destes conectores.
Tabela 1. Conectores de Códigos adaptado de (BANDEIRA-DE-MELLO, 2006)
Símbolo Rótulo Descrição das Relações
isa Is a O código/origem é um tipo, ou forma, do código/destino.
*} Is property of O código/origem é propriedade do código/ destino
=> Is cause of O código/origem causa a ocorrência do código/destino
[ ] Is part of O código/origem é uma parte que compõe, junto com outras partes, o código/destino. É importante salientar que novos conectores podem ser criados, com o objetivo de explicitar relações não atendidas pelos conectores já existentes. Na linha proposta por Strauss (1998), todas estas relações formam o que os autores denominam de paradigma da teoria.
análise do gráfico relativo aos códigos, categorias e relações criados e estabelecidos nas etapas de codificação anteriores, a fim de fundamentar a nova teoria.
2.1.2 Ilustração do Uso de
A fim de deixar mais claro o processo que envolve a aplicação da metodologia , a mesma foi aplicada por este trabalho em um trecho de uma entrevista feita com alunos de graduação sobre o ensino da Engenharia de Software em uma dada Universidade. Através deste exemplo, desenvolvido pela própria autora deste trabalho, é possível compreender melhor cada uma das etapas de codificação envolvidas nesta metodologia.
Seguindo então o processo definido pela , inicia/se a análise com a aplicação da codificação aberta. Desta forma, o trecho da entrevista em questão foi detalhadamente analisado e cada ponto considerado relevante na entrevista em questão foi atribuído um código que o identifique. Como se pode ver na Figura 1 a seguir, o código “Pontos Positivos”, por exemplo, referencia o texto referente aos pontos positivos citados pelo entrevistado. Assim é possível perceber que a criação destes códigos facilita uma rápida e consistente compreensão dos pontos relevantes desta entrevista e de suas relações.
Figura 1. Codificação Aberta Aplicada ao Trecho da Entrevista
Os códigos e categorias, bem como as relações entre eles podem ser vistas, de forma clara através do gráfico gerado a partir da última etapa da Grounded Theory: a codificação seletiva. Nesta etapa todo o processo de análise é refinado. Durante este refinamento, a categoria central, neste caso “Avaliação do Ensino de Engenharia de Software”, foi identificada e definida e a partir daí o gráfico observado na Figura 2 é gerado.
A partir dos dados e dos gráficos resultantes de toda a análise feita utilizando a metodologia , podem/se extrair importantes conclusões sobre a questão central da análise. Neste caso, por exemplo, é possível observar que os pontos positivos e negativos apresentados pelo entrevistado são facilmente percebidos através de uma rápida análise do gráfico. As relações entre estes pontos e as sugestões de melhoria apontadas pelo entrevistado também ficaram evidentes
após a aplicação da .
Figura 2. Gráfico resultante da Codificação Seletiva aplicada à Entrevista
, obter uma documentação rica em informações. Por essas razões, essa metodologia apresenta/se como uma boa opção na coleta e análise de dados.
2.1.3 Ferramenta Atlas.ti
Atlas.ti (Atlas.ti, 2012) é uma renomada ferramenta de suporte à pesquisa e a análise qualitativa de dados. Esta ferramenta possui diversas funcionalidades que dão suporte à análise qualitativa de textos, áudio, vídeo e dados gráficos. A integração destas diversas funcionalidades provê um excelente suporte a este tipo de análise de dados, tornando a mesma mais simples e bem embasada.
Um protótipo da ferramenta Atlas.ti foi desenvolvido por Thomas Muhr,
entre os anos de 1989 e 1992, na % 4 no contexto do projeto
de pesquisa ATLAS, desenvolvido por esta universidade. A primeira versão comercial da ferramenta Atlas.ti foi lançada em 1993. Apesar de atualmente ser uma ferramenta paga, muito consumida por empresas de grande porte, como IBM e Intel, é disponibilizada uma versão em seu próprio site. Esta versão não possui limitação de tempo de uso, e sim de funcionalidades. A Figura 3 apresenta a tela inicial da mais recente versão da ferramenta Atlas.ti, a 7.0.
Figura 3. Tela Inicial da Versão 7.0 da Ferramenta Atlas.ti
ao usuário localizar, codificar e anotar resultados em documentos primários e, em seguida, avaliar a importância destes dados e determinar e visualizar as relações existentes entre eles.
A ferramenta Atlas.ti é utilizada por este trabalho por ser uma das mais renomadas e robustas ferramentas que dão suporte à aplicação da metodologia , sendo de fácil uso e compreensão e possibilitando à análise dos mais diversos tipos de documentos. Atlas.ti dá suporte semiautomático à todas as etapas do processo proposto pela metodologia .
2.2 Interesses Transversais
Sutton , (2002) define como “quaisquer pontos de interesse em um sistema de ”. Estes podem estar diretamente relacionados com o sistema em si ou com o contexto no qual estão inseridos.
De maneira bastante simplificada, pode/se afirmar que interesses transversais são partes de um sistema, identificadas como interesses, que tornam dependentes ou afetam muitas outras partes deste mesmo sistema (Kiczales ,, 1997). Ainda segundo Kiczales , (1997), interesses transversais podem ser ditos entrelaçados, ou intercalados, dentro de um sistema. Além disto, um interesse transversal é dito espalhado, ou duplicado, nas diversas partes do sistema às quais este está relacionado, resultando em uma perda de modularidade.
Desta forma, pode/se definir interesses transversais, de forma bastante resumida, como partes de um sistema que estão entrelaçadas e espalhadas por diversas outras partes deste mesmo sistema. No contexto da Engenharia de Requisitos, pode/se afirmar que cada requisito pode ser considerado um interesse de um sistema. Esses interesses podem, em determinados casos, ser considerados como transversais. Um requisito é considerado um interesse transversal quando está espalhado e entrelaçado por outro(s) requisito(s) de um mesmo sistema (Rosenhainer, 2004).
A programação orientada a aspectos (POA) visa encapsular os interesses transversais de um sistema com o objetivo de manter sua modularidade. Isto permite o isolamento e o reuso do código relativo ao interesse transversal. Ao basear todo o desenvolvimento em interesses transversais, alguns benefícios são agregados à engenharia de software, incluindo uma melhor modularização do sistema e manutenção simplificada (Li ,, 2002).
requisitos até a etapa de projeto detalhado. Diretamente ligada a esta área está a Engenharia de Requisitos Orientada a Aspectos (EROA), uma área dentro do domínio da Engenharia de Requisitos. A EROA visa atender aos interesses transversais diretamente relacionados aos requisitos, proporcionando meios para sua identificação, modularização, composição e análise de sua influência sobre outros requisitos presentes no sistema. Aplicando os fundamentos básicos sobre interesses transversais à EROA, pode/se dizer que um requisito dito transversal é aquele que está entrelaçado com outros requisitos do sistema e que está espalhado por diversas partes do sistema. As características destes requisitos são bastante variáveis, sendo algumas delas óbvias e outras bastante sutis, por isto sua identificação costuma ser considerada difícil (Ali e Kasirum, 2008/B).
Entretanto, apesar de estarem bastante relacionados à Orientação a Aspectos, os conceitos de interesses transversais, atualmente, são essenciais à modularização de em geral, podendo ou não estar associados à Orientação a Aspectos. Assim, atualmente, a identificação de interesses transversais apresenta/se cada vez mais fundamental nas fases iniciais do ciclo de vida de software, independentemente do paradigma adotado (Eaddy ,, 2007)
2.3 Identificação de Interesses Transversais
Idealmente, um documento de especificação de requisitos deve também documentar todos os requisitos identificados como interesses transversais e as relações existentes entre estes e outros requisitos deste mesmo sistema. Entretanto, na realidade, raros são os documentos que são especificados levando esse ponto em consideração (Mohamed ,, 2010).
A principal razão para isto ocorrer é que, geralmente, não há tempo suficiente durante o desenvolvimento de um projeto de software para fazer grandes melhorias no documento de especificação de requisitos. No entanto, se algumas relações entre requisitos, como o caso das relações transversais, apresentam/se de forma obscura no documento, os desenvolvedores correm um sério risco de esquecê/las durante as outras etapas do processo de desenvolvimento. Este esquecimento, em geral, acarreta retrabalho, perda de qualidade e da confiabilidade do sistema e aumento do custo final do software (Mohamed ,, 2010).
várias partes de um mesmo documento, escritos com palavras diferentes, o que dificulta ainda mais a sua identificação (Ali e Kasirum 2008/A).
Além dessas, a identificação de interesses transversais ainda nas etapas mais iniciais do ciclo de vida de enfrenta algumas outras dificuldades, tais como a ausência de uma boa sistematização e de ferramentas que a de apoio. Além disto, é considerado difícil, muitas vezes, justificar as razões pelas quais determinados interesses são ou não considerados transversais, uma vez que esta identificação é, na maioria das vezes, feita sem qualquer metodologia que a sistematize e a embase e, por isto, sem qualquer fundamento claro para a identificação e a determinação da transversalidade de um dado interesse. Mesmo quando há metodologia, muitas vezes não ficam documentadas as escolhas e definições dentro de seu processo e, por isto, também se torna difícil entender e justificar as razões pelas quais um dado interesse é, ou não, considerado transversal.
Apesar das dificuldades enfrentadas, é sabido que a identificação de interesses transversais ainda nas etapas relacionadas à Engenharia de Requisitos é importante, uma vez que adiciona ganhos consideráveis ao em desenvolvimento. Assim, para ressaltar a importância da identificação e documentação destes interesses transversais diretamente associados aos requisitos do sistema, algumas grandes vantagens podem ser citadas:
• A identificação e documentação de requisitos considerados interesses transversais e as relações entre estes torna mais fácil avaliar o impacto de mudanças;
• A identificação e documentação de requisitos ditos interesses transversais facilita o acompanhamento da evolução destes, uma vez que permitem o acompanhamento destes requisitos ao longo do ciclo de desenvolvimento;
• A identificação e a boa documentação dos interesses transversais permite a detecção de possíveis falhas nas suas especificações;
• A identificação e documentação de requisitos ditos interesses transversais proporciona uma melhor modularização do documento de requisitos e induz a modularização do como um todo e;
• Quando feito ainda na fase da aplicação da Engenharia de Requisitos, a identificação e documentação de interesses transversais possibilita que estes não sejam negligenciados nas fases seguintes do processo de desenvolvimento de software, evitando assim possíveis retrabalhos.
recomendável. É sabido que o ideal é identificar e documentar estes interesses desde o princípio do desenvolvimento, ou seja, ainda durante a elicitação e modelagem de requisitos. Entretanto, é necessário considerar que existem inúmeras especificações de requisitos que já foram elaboradas sem levar em consideração a relevância destes interesses transversais. Para os desenvolvedores que trabalham com estas especificações torna/se, muitas vezes, necessário fazer esta identificação e documentação em tais documentos. Faz/se, então, necessário utilizar alguma abordagem que permita e suporte esta identificação e documentação de interesses transversais nestes documentos de requisitos da melhor forma possível (Rosenhainer, 2004).
Diante de todas as dificuldades já citadas e das vantagens advindas da identificação precoce de interesses transversais, acredita/se ser necessário desenvolver abordagens que esquematizem e, de certa forma, facilitem o processo de identificação e documentação destes interesses transversais, especialmente quando relacionados a requisitos. As principais destas abordagens, tais como Abordagem Theme/DOC (Baniassad e Clarke, 2004), Identificação de #
através de UML (Araújo et al, 2002; Araújo e Moreira 2003; Brito, 2004), Método DISCERN (Rosenhainer, 2005), Early/AIM (Sampaio et al., 2005/A) e CCCINPL (Ali e Kasirum, 2008/B) são detalhadas no Capítulo 6 deste trabalho.
Porém, de acordo com os estudos e a revisão sistemática aplicada para a elaboração deste trabalho, as abordagens atualmente existentes para a identificação de interesses transversais diretamente relacionados a requisitos são, em parte, ineficientes em alguns pontos. Dentre estes pontos de limitação, podemos citar como principais:
• Algumas abordagens têm sua identificação de interesses transversais puramente baseada no processamento de linguagem natural (PLN) ou na análise léxica dos documentos de requisitos, negligenciando, assim, a análise do contexto no qual os dados presentes no documento estão inseridos. De acordo com Sampaio , (2005) e Appeltauer , (2010) a ausência da análise contextual no processo de identificação de interesses transversais torna esta identificação mais frágil e menos confiável;
• Diversas abordagens possibilitam a identificação de interesses transversais apenas em documentos de requisitos estruturados de acordo com padrões pré/definidos, não permitindo que a mesma seja feita em documentos elaborados em qualquer padrão que difira daquele;
funcionais, negligenciando, assim, interesses de outros tipos presente no documento de requisitos analisado;
• Algumas abordagens não possuem qualquer suporte ferramental para a sua aplicação, tendo, desta maneira, seu processo totalmente aplicado de forma manual nos documentos de requisitos;
• Diversas abordagens possuem uma fraca documentação dos resultados encontrados a partir da identificação de interesses transversais em documentos de requisitos. Na maioria das vezes as abordagens não possuem qualquer mecanismo que documente, por exemplo, as relações existentes entre os interesses analisados.
3 A Abordagem GT4CCI
Nesse capítulo é apresentada a abordagem de identificação de interesses transversais proposta por este trabalho, chamada GT4CCI, acrônimo da expressão
.
Como citado nas seções anteriores, há algumas abordagens que focam na identificação de interesses transversais. Entretanto, poucas são aquelas que tratam destes interesses ainda em nível de requisitos. Além disto, estas poucas apresentam algumas limitações. Desta forma, apresentou/se a necessidade de propor uma nova abordagem que surgisse como alternativa para sanar ou, ao menos, amenizar as limitações existentes nas abordagens até hoje já propostas. Diante disto, este trabalho apresenta uma nova abordagem, a GT4CCI, para identificação de interesses transversais nas etapas mais iniciais do desenvolvimento de software, utilizando como artefato de análise o documento de especificação de requisitos desenvolvido para um dado sistema.
A abordagem GT4CCI baseia/se na para identificar e documentar, através da codificação de dados, estes interesses ainda na fase de aplicação da Engenharia de Requisitos, utilizando/se dos documentos de especificação de requisitos, gerados a partir da elicitação de requisitos de um dado software. Apesar ser baseada no processo proposto pela incluindo as etapas de Codificação Aberta, Codificação Axial e Codificação Seletiva, a abordagem GT4CCI também inclui duas novas etapas, a Análise do Gráfico e a Criação da Tabela de Resultados, não inerentes ao processo proposto pela
. Estas novas etapas, próprias da abordagem aqui proposta, tornam a identificação e a documentação de interesses transversais mais prática, embasada e bem documentada. Além destas novas etapas, a abordagem GT4CCI também estabelece heurísticas próprias para a identificação de interesses transversais. Todas estas etapas e também as heurísticas para a identificação são apresentadas e explicadas, através da aplicação em um exemplo demonstrativo, nas subseções a seguir.
Como se pode observar na Figura 4, há cinco etapas essenciais à aplicação da abordagem GT4CCI aqui proposta: a Codificação Aberta, a Codificação Axial, a Codificação Seletiva, a Análise do Gráfico e a Criação da Tabela de Resultados. Cada uma destas possui seus respectivos artefatos de entrada e de saída, como representados, também, no fluxograma da Figura 4. Neste fluxograma é possível observar a sequência de etapas do processo e também os artefatos de entrada e de saída de cada uma dessas etapas. A sequência de etapas do processo está representada pela seta simples, sem traços pontilhados, enquanto que os artefatos de entrada e de saída estão representados pelas setas pontilhadas. É importante, mais uma vez, salientar que as três primeiras etapas do processo proposto pela abordagem GT4CCI são inerentes à . Já as duas últimas etapas são próprias da abordagem GT4CCI.
Figura 4. Fluxograma da Abordagem GT4CCI
Este documento divide/se em duas seções: “Descrição dos Requisitos Não/ Funcionais do Sistema” e “Descrição das Funcionalidades do Sistema”. Ambas são cuidadosamente analisadas seguindo o processo aqui proposto, a fim de identificar possíveis interesses transversais presentes neste Sistema. É importante destacar que todo o processo da abordagem GT4CCI foi aplicado no documento de requisitos com o auxílio da ferramenta Atlas.ti (Atlas.ti, 2011).
3.1 GT4CCI: 1ª Etapa / Codificação Aberta
De acordo com o processo estabelecido pela abordagem GT4CCI, inicia/se a aplicação da abordagem submetendo o documento de requisitos à etapa de codificação aberta. Nesta etapa, são analisados, comparados e codificados os dados relevantes presentes neste documento. Assim, todos os requisitos e demais informações relevantes, tais como descrição detalhada de requisitos e casos de uso do sistema, apontadas por este documento, são analisadas e estabelecem/se códigos para cada uma destas.
Os códigos criados tem a função de identificar e registrar, de forma sucinta e clara, todos os dados considerados relevantes presentes no documento de requisitos em análise. Estes códigos são utilizados na aplicação das próximas etapas do processo proposto pela abordagem GT4CCI.
Como ilustrado na Figura 5, no documento de requisitos utilizado como exemplo por este trabalho, foram criados códigos que identificam os requisitos não/ funcionais e também as funcionalidades apresentadas. A Figura 5 apresenta o resultado gerado a partir da aplicação da codificação aberta neste documento. É importante salientar que os códigos foram criados com o auxílio da ferramenta Atlas.ti.
Assim, pode/se observar, por exemplo, que para o requisito não/funcional ‘Desempenho’, o código ‘RNF: Desempenho’ foi criado. Outro exemplo é o código ‘Func: Manter Dados’, relativo à funcionalidade ‘Manter os Dados’, apresentada pelo documento analisado. A criação de códigos repete/se para todos os outros pontos considerados relevantes presentes neste documento, como se pode ver na Figura 5.
3.2 GT4CCI: 2ª Etapa / Codificação Axial
Após estabelecer os códigos durante a etapa de codificação aberta, demonstrados na Seção 3.1, o documento de requisitos é submetido à etapa de codificação axial. Nesta etapa são estabelecidas as relações entre os códigos criados na etapa anterior, a codificação aberta.
Estas relações são estabelecidas através de conectores. Cada conector tem a função de identificar e determinar a relação existente entre dois códigos. Na abordagem GT4CCI, dois conectores em especial são utilizados: o conector “
5’, que indica que um código está entrelaçado à outro, e o código “ ”, que indica que um código está espalhado em outro.
É válido ressaltar o fato de que a GT4CCI trata cada um dos códigos de maneira individualizada, com o objetivo de facilitar a compreensão e a visualização das relações estabelecidas entres os códigos. Desta forma, as relações são estabelecidas de acordo com a percepção do analista em relação ao código que se está analisando de forma individualizada e as relações que este código apresenta no contexto do documento de requisitos em análise.
• Nesta etapa, utilizando/se a ferramenta Atlas.ti, é selecionada a opção que permite o estabelecimento da relação entre o código ‘RNF: Persistência’ e um outro código, selecionado na etapa seguinte.
• Nesta etapa, seleciona/se o código ‘Func: Exibir Maior Dado’, que se relacionará com o código ‘RNF: Persistência’.
• Por fim, seleciona/se o conector que determinará a relação existente entre os dois códigos previamente selecionados. Neste caso, como a relação é de entrelaçamento, o conector selecionado é o ‘ ’.
A Figura 6 ilustra a aplicação dessa etapa, usando a ferramenta Atlas.ti, no documento de requisitos adotado como exemplo por esse capítulo do trabalho. Nesta figura podemos visualizar as etapas do estabelecimento de relação entre os códigos “Func: Exibir Maior Dado” e “RNF: Persistência”. Analisando de forma individualizada a funcionalidade Exibir Maior Dado, presente no documento de requisitos, foi possível identificar que a mesma apresenta uma relação clara de entrelaçamento com o requisito não/funcional Persistência. Assim, os dois códigos relativos à estes requisitos foram relacionados através do conector “ ”, que representa o entrelaçamento de um código a outro. Através do estabelecimento desta relação, fica possível, então, representar o entrelaçamento existente entre a funcionalidade Exibir Maior Dado e o requisito não/funcional Persistência.
Faz/se necessário ressaltar que, além da relação demonstrada na Figura 6, todas as relações entre os códigos que, de alguma forma, relacionavam/se com outros códigos deste mesmo documento de requisitos foram estabelecidas. Estas relações são melhores explicadas e visualizadas através do gráfico, gerado para cada um destes códigos, na etapa da codificação seletiva.
3.3 GT4CCI: 3ª Etapa /Codificação Seletiva
Após a finalização da codificação axial, é aplicada ao documento de requisitos a codificação seletiva. Nesta etapa, todo o processo de codificação pelo qual o documento em questão já foi submetido é refinado. Este refinamento constitui/se em analisar todo o documento e os códigos definidos e, a partir daí, definir a categoria central daquela análise. A categoria central é o ponto mais relevante da análise, a partir do qual o gráfico será gerado.
É importante ressaltar que a abordagem GT4CCI trata cada um dos códigos de maneira individualizada, com o objetivo de facilitar a compreensão e a visualização das relações estabelecidas entres os códigos. Isto significa que cada código previamente definido é submetido à codificação seletiva de maneira individualizada, sendo o foco central da análise e passando, desta forma, a ser considerado como categoria central. Desta forma, um gráfico, resultante da codificação seletiva, é gerado para cada um destes códigos, agora chamados categoria central. É importante salientar que todos os gráficos são gerados de maneira automática, a partir do uso da ferramenta de análise utilizada por este trabalho, a Atlas.ti (Atlas.ti, 2011).
apresentados na subseção a seguir, a fim de facilitar a visualização e a compreensão da próxima etapa deste processo.
3.4 GT4CCI: 4ª Etapa /Análise do Gráfico
Nesta etapa, totalmente concebida pela abordagem GT4CCI, os gráficos referentes às categorias centrais, gerados na etapa anterior, são cuidadosamente analisados, a fim de proceder com a identificação dos interesses considerados transversais do sistema.
A análise do gráfico é baseada nas relações estabelecidas entre os códigos presentes no gráfico em análise, com o objetivo de identificar e determinar se a categoria central em questão pode, ou não, ser considerada um interesse transversal do sistema. Para que esta identificação seja feita de forma correta, a abordagem
GT4CCI define algumas 6 7 89
: ' , apontadas a seguir:
• A identificação dos interesses transversais de um dado sistema é feita a partir da verificação do entrelaçamento do código relativo a estes com os outros presentes no documento, e do espalhamento destes códigos em outros pontos relevantes presentes no documento;
• Um dado interesse é dito espalhado quando a sua especificação está, necessariamente, espalhada por diversos outros interesses (sejam eles requisitos, casos de uso, funcionalidades, etc.) de um mesmo sistema. Este espalhamento é representado através da relação “ ”;
• Um dado interesse é dito entrelaçado quando a sua especificação está intercalada à especificação de diversos outros interesses (sejam eles requisitos, casos de uso, funcionalidades, etc.) de um mesmo sistema. Este entrelaçamento é representado através da relação “ ”;
• Desta maneira, quando um dado interesse, representado por um código nesta abordagem, é o ponto de origem de numerosas relações do tipos “ ” e é, também, o ponto de destino de diversas relações do tipo “ ” pode então ser considerado um interesse transversal;
que já foi dito, para que seja considerado um interesse transversal, um dado interesse deve originar, pelo menos, duas relações de espalhamento e ser o destino de, pelo menos, duas relações que representam o entrelaçamento, uma vez que somente assim será considerado espalhado e entrelaçado por todo o sistema.
É essencial destacar ainda que os pontos analisados não se restringem, por exemplo, a descrição dos requisitos ou casos de uso, como ocorre em muitas outras abordagens. No caso da abordagem GT4CCI, qualquer dado considerado relevante dentro do documento pode e deve ser analisado. Quanto mais dados contidos no documento forem analisados, maior será a qualidade e a confiabilidade das conclusões obtidas ao final do processo de análise. Desta forma, será apresentada a seguir a aplicação da etapa de análise do gráfico em quatro códigos definidos para o documento de requisitos utilizado como exemplo nesse capítulo.
3.4.1 Análise do Gráfico: “RNF: Persistência”
Na Figura 7 pode/se observar o gráfico gerado a partir da aplicação da codificação seletiva focando no código “RNF: Persistência”, seguindo a abordagem GT4CCI. Por ser o alvo central da análise nesta etapa, o código “RNF: Persistência” passa a ser considerado como categoria central da análise.
Figura 7. Gráfico gerado a partir da aplicação da codificação seletiva no código "RNF: Persistência".
A partir da análise detalhada deste gráfico, pode/se perceber que a categoria central “RNF: Persistência” está entrelaçada, uma vez que está associada a dois outros requisitos não/funcionais, Desempenho e Segurança, através do conector “
”. Pode/se concluir também que esta categoria está espalhada, visto que está relacionada com todas as funcionalidades apresentadas pelo documento de requisitos do Sistema de Tratamento de Dados Numéricos através do conector “
Desta forma, de acordo com as heurísticas adotadas por este trabalho, pode/se afirmar que o requisito não/funcional “Persistência” presente neste sistema é considerado um interesse transversal, uma vez que possui as característica de entrelaçamento e espalhamento.
3.4.2 Análise do Gráfico: “RNF: Multi/Acesso”
Na Figura 8 vê/se o gráfico gerado a partir da aplicação da codificação seletiva voltada diretamente ao código “RNF: Multi/Acesso”, seguindo a abordagem GT4CCI. Por ser o alvo central da análise nesta etapa, o código “RNF: Multi/Acesso” passa a ser considerado como categoria central da análise.
Analisando o gráfico gerado a partir desta etapa de codificação, pode/se perceber que a categoria central “RNF: Multi/Acesso” não pode ser dita entrelaçada, uma vez que é o ponto de destino de apenas uma relação de entrelaçamento, representada através do conector “ ”, no sistema em questão. Esta categoria também não pode ser considerada espalhada, uma vez que não está relacionada através do conector “ ” a qualquer outro interesse existente no documento de requisitos do Sistema de Tratamento de Dados Numéricos.
Figura 8. Gráfico gerado a partir da aplicação da codificação seletiva no código "RNF: Multi-Acesso"
3.4.3 Análise do Gráfico: “Func: Exibir Maior Dado”
Nessa seção é apresentada a análise do gráfico referente à categoria central “Func: Exibir Maior Dado”, que representa a funcionalidade “Exibir Maior Dado”. É válido destacar que, diferentemente das análises de gráfico feitas nas Seções 3.4.1 e 3.4.2, a análise aqui apresentada é elaborada tendo seu foco central em um código determinado para uma funcionalidade do sistema, enquanto que os outro códigos referenciavam requisitos não/funcionais.
Na Figura 9 pode/se ver o gráfico gerado na codificação seletiva focada no código “Func: Exibir Maior Dado”. Fazendo a análise do gráfico gerado a partir desta etapa de codificação, pode/se perceber que a categoria central “Func: Exibir Maior Dado” pode ser considerada entrelaçada, uma vez que esta associada a diversos outros interesses do sistema através do conector “ ”, que indica o entrelaçamento entre dois interesses. Entretanto, esta categoria central não pode ser considerada espalhada, uma vez que não apresenta qualquer relação de espalhamento com qualquer outro concern do sistema em questão. Isto pode ser constatado pela ausência de qualquer ligação do tipo “ ” neste gráfico.
Figura 9. Gráfico gerado a partir da aplicação da codificação seletiva no código "Func: Exibir Maior Dado”
Desta forma, de acordo com os conceitos adotados por este trabalho, pode/se afirmar que a funcionalidade “Exibir Maior Dado” presente neste sistema não é um interesse transversal, uma vez que possui a característica de espalhamento, mas não possui a de entrelaçamento.
3.4.4 Análise do Gráfico: “Func: Manter Log de Uso do Sistema”
aplicação da etapa de codificação seletiva, tendo como foco central o código “Func: Manter Log de Uso do Sistema”. Por ser o alvo central desta codificação, este código é definido, então, como categoria central da análise nesta etapa.
A partir da análise deste gráfico, pode/se concluir que a categoria central “Func: Manter Log de Uso do Sistema” está espalhada por diversos outros interesses do sistema, uma vez que esta é a origem de diversas relações do tipo “ ”, que indicam o espalhamento entre interesses. Além disto, esta categoria também pode ser dita entrelaçada, uma vez que é o ponto de destino de diversas relações de entrelaçamento, representadas pelo conector “ ”.
Desta maneira, de acordo com as heurísticas adotadas por este trabalho, pode/ se afirmar que a funcionalidade “Manter Log de Uso do Sistema” é um interesse transversal, uma vez que possui as características de espalhamento e entrelaçamento.
Figura 10. Gráfico gerado a partir da aplicação da codificação seletiva no código "Func: Manter Log de Uso do Sistema"
3.5 GT4CCI: 5ª Etapa /Criação da Tabela de Resultados
Após identificar, através das etapas anteriores, se cada um dos interesses identificados em um dado sistema pode, ou não, ser considerado transversal, é aplicada a última etapa proposta pela abordagem GT4CCI: a etapa da criação da Criação da Tabela de Resultados.
documento de requisitos, possibilitando assim a simples e ágil consulta destes dados sempre que necessário na verificação e validação de requisitos ou nas etapas seguintes do desenvolvimento de software.
A Tabela de Resultados é composta por quatro campos, organizados em colunas, cada um destes contendo dados referentes aos resultados obtidos a partir da aplicação da abordagem GT4CCI. Estes campos são:
13 : Este campo apresenta o interesse relacionado à categoria central da análise, ao qual todos os outros campos estão diretamente relacionados;
23 ) Este campo lista todos os outros interesses em que a categoria central é considerada espalhada;
3) ) 8 : Este campo lista todos os outros interesses com os quais a categoria central é considerada entrelaçada;
4) : Este campo indica, de maneira bastante objetiva, se o interesse em questão pode, ou não, ser dito transversal. Caso o interesse seja considerado transversal, deve/se preencher este campo com a palavra ‘Sim’, caso contrário, este campo deve ser preenchido com a palavra ‘Não’.
É importante mencionar que os nomes das colunas, constituídos de termos bastante simples e intuitivos, são assim feitos com o objetivo de facilitar a identificação e o entendimento durante as possíveis futuras consultas feitas à esta Tabela de Resultados.
A Tabela 2 apresenta a Tabela de Resultados elaborada para o Sistema de Tratamento de Dados Numéricos, utilizado como exemplo por esse capítulo. Para cada um dos interesses, tratados individualmente pela abordagem, é possível observar, de maneira simples e clara, seu entrelaçamento e seu espalhamento com os outros interesses deste mesmo Sistema, através dos campos ‘Espalhamento’ e ‘Entrelaçamento’. É possível também checar, rapidamente, através do campo ‘Transversalidade’, se o interesse em questão pode, ou não, ser considerado um interesse transversal do Sistema.
Tabela 2. Tabela de Resultados do Sistema de Tratamento de Dados Numéricos
! "( " $ "
# ! (
/ Manter os Dados / Exibir Maior Dado / Calcular e Exibir Média
de Dados / Manter Log de Uso do
Sistema / Persistência / Segurança / Disponibilidade 4 5 /
/ Manter Log de Uso do Sistema
/ Exibir Maior Dado / Manter os Dados / Calcular e Exibir Média
de Dados
/ Segurança
/ Desempenho 4
4
/ Manter os Dados / Manter Log de Uso do
Sistema
/ Desempenho / Persistência / Disponibilidade
4
# ! "
// Manter os Dados / Exibir Maior Dado / Calcular e Exibir Média
de Dados / Manter Log de Uso do
Sistema
/ Desempenho / Segurança / Multi/Acesso
4
6 " 7
— / Disponibilidade 8
6 # — / Desempenho / Persistência / Segurança / Disponibilidade 8 6 # — / Segurança / Manter Log de Uso
/ Desempenho / Disponibilidade
/ Persistência
8
" "
69 # —
/ Desempenho / Segurança / Disponibilidade 8 6 : % 4
/ Exibir Maior Dado / Calcular e Exibir Média
de Dados / Manter os Dados
/ Persistência / Segurança / Disponibilidade
/ Desempenho
Entre os interesses não/funcionais podemos observar que apenas um, o interesses “Multi/Acesso” não é considerado um interesse transversal. Isto se deve ao fato de que, em geral, requisitos não/funcionais possuem as características de espalhamento e de entrelaçamento, devido ao seu elevado grau de abstração. Já entre os interesses funcionais é possível observar que apenas um, o interesse “Manter Log de Uso do Sistema” é considerado um interesse transversal deste Sistema, uma vez que possui as características de espalhamento e entrelaçamento.
4 Exemplo Demonstrativo do Uso de GT4CCI
Nessa seção é apresentado um exemplo demonstrativo da aplicação da abordagem GT4CCI. Para elaborar este exemplo, utilizamos o documento de requisitos elaborado para o + - (Kienzle ,, 2009). Este documento foi escolhido como exemplo por ser bastante completo e bem elaborado, com requisitos e casos de uso bem definidos e tendo um domínio claro. Através da aplicação da abordagem GT4CCI neste documento espera/se obter resultados que avaliem o processo proposto pela abordagem GT4CCI, apresentado no Capítulo 3 deste trabalho.
Na Seção 4.1 é apresentado o documento referente ao Sistema
+ - , tomado como base nessa seção. Na Seção 4.2 é apresentada a aplicação da abordagem GT4CCI no CMS. Por fim, na Seção 4.3, são discutidos os resultados obtidos através da aplicação da abordagem GT4CCI neste exemplo demonstrativo.
4.1
+
-+ - (Kienzle ,, 2009) é um documento desenvolvido
com o objetivo de definir um estudo de caso padrão para as pesquisas que envolvem modelagem orientada a aspectos. Este documento foi utilizado como Estudo de Caso
padrão na publicação #; - : <
(TAOSD), publicada no ano de 2010.
+ - (CMS) tem como domínio central sistemas de gerenciamento de crise. Mais especificamente, este documento de requisitos descreve e define um sistema que ajuda a identificar, avaliar e lidar com situações de crise, permitindo a comunicação entre todas as partes envolvidas no gerenciamento da crise. Isto se dá através da atribuição e gestão dos recursos e também através do acesso a informações relevantes relacionadas com a crise, feito por usuários habilitados.
4.2 Aplicação de GT4CCI no CMS
Nas seções seguintes são apresentadas, em detalhes, cada uma das etapas da aplicação da abordagem GT4CCI no documento CMS. Na Seção 4.2.1 é apresentada a aplicação da etapa de Codificação Aberta no CMS. Na Seção 4.2.2., 4.2.3 e 4.2.4 são mostradas, respectivamente, a aplicação das etapas de Codificação Axial, Codificação Seletiva e Análise do Gráfico no CMS. Por fim, na Seção 4.2.5 é apresentada parte da Tabela de Resultados criada para este exemplo demonstrativo.
4.2.1 Codificação Aberta no CMS
Na etapa de Codificação Aberta, todos os dados relativos aos requisitos do sistema, sendo eles funcionais ou não/funcionais, presentes no documento CMS foram analisados e codificados, seguindo o processo adotado pela abordagem GT4CCI, a fim de proceder a identificação de interesses transversais. Desta maneira, uma atenção especial foi dada às seções referentes à descrição dos casos de uso e à descrição detalhada dos requisitos do sistema, uma vez que estas estão mais voltadas ao objetivo deste trabalho, contendo as informações de requisitos deste sistema.
A Figura 11 apresenta os resultados gerados a partir da aplicação da etapa de Codificação Aberta em apenas um pequeno trecho do documento CMS. Este trecho é relativo à dois requisitos não/funcionais, sendo eles “ 0 ” e “- ”, e dois
casos de uso textuais, o “% & ' ” e o % ( )* '
+ !.
No canto direito da Figura 11 é possível ver os códigos criados para cada um dos interesses identificados neste trecho do documento CMS. É possível ver nesta figura, por exemplo, o código “ 0 ”, criado para identificar o interesse
0 , referente às questões de Disponibilidade deste Sistema. É possível observar, também, o código “% & ' ”, gerado para o caso de uso %
& ' . É importante observar também a possibilidade de estabelecer mais de um código para um determinado trecho do documento.
