Des pratiques modales corrélées au rapport au temps
I. C.2 Un rythme de vie qui varie en fonction de la position dans le cycle de vie
Visando facilitar a visualização da comparação feita entre todas as abordagens aqui apresentadas, além da abordagem proposta por este trabalho, gerou/se a Tabela 18. Nesta tabela cinco critérios principais de comparação foram estabelecidos. Estes critérios são:
1) D 89 : Indica qual técnica é utilizada pela abordagem para fazer a identificação dos interesses transversais;
2) : Indica em quais artefatos são identificados interesses transversais;
3) : : Indica qual(is) o(s) tipo(s) de dado(s) que é(são) analisado(s) pela abordagem como base para a identificação de interesses transversais;
4) : 89 : Indica qual documentação é gerada ao final da aplicação do processo proposto pela abordagem. Esta documentação tem como objetivo gerar dados de saída que indiquem os resultados encontrados pela aplicação da abordagem;
5) 89 B : Indica qual o grau de automação que a
abordagem possui, ou seja, informa se esta é automatizada, semi/ automatizada ou manual. Além disto, caso possua, indica quais ferramentas dão suporte à aplicação do processo proposto pela abordagem. É importante destacar que as abordagens classificadas como semi/automatizadas são aquelas que possuem ferramentas que apoiam a aplicação do processo de identificação que a mesma propõe;
A Tabela 18 resume as principais características de cada uma das abordagens estudadas por este trabalho, apontando as principais similaridades e diferenças existentes entre cada uma destas. Desta forma, fica mais clara a percepção das principais limitações de cada uma das abordagens e os pontos em que estas se distinguem e se assemelham.
A partir da análise desta tabela é possível observar alguns pontos que merecem ser destacados. O primeiro deles, referente à técnica de identificação utilizada por cada uma das abordagens, aponta que a maioria das abordagens baseia/se na análise contextual do documento de requisitos analisado. Entretanto, é
possível perceber que a abordagem Early/AIM não faz este tipo de análise, ignorando o contexto no qual os interesses estão inseridos dentro do documento.
Tabela 18. Tabela Comparativa das Abordagens Apresentadas
9 9 . . " # " # , Análise contextual do documento Qualquer documento de requisitos Análise de todos os dados relevantes Gráficos e Tabela de Resultados que permitem a identificação dos ITs Semi/ automatizada. Auxiliada pela ferramenta Atlas.it ( @# Análise sintática e contextual do documento Documentos de requisitos estruturados de acordo com padrão pré/ definido Requisitos não/ funcionais ou funcionais textuais Modelo que permite a identificação dos ITs (+ < 3 Semi/ automatizada. Auxiliada pela ferramenta Theme/Doc Tool . $9 %6: Análise contextual do documento Qualquer documento de requisitos Apenas requisitos não/ funcionais textuais Modelo de Caso de Uso que integra os ITs identificados
Manual. Não cita qualquer ferramenta de apoio # 4 )8 Análise contextual do documento Qualquer documento de requisitos Apenas requisitos não/ funcionais textuais Modelo de Casos de Uso que integra os ITs identificados Manual. Entretanto, um protótipo de ferramenta de apoio é proposto ";7 6 Processamento de linguagem natural Qualquer documento de requisitos Requisitos não/ funcionais e funcionais textuais Modelo que exibe os ITs do sistema Semi/ automatizada. Auxiliada pela ferramenta EA/ MINER 85: Processamento de linguagem natural e Análise Contextual Qualquer documento de requisitos Requisitos não/ funcionais e funcionais textuais Mapeamento de relacionamento entre ITs e outros
requisitos do sistema Automatizada. Totalmente suportada pela ferramenta C3I
Outro ponto que merece ser mencionado são os artefatos analisados por cada uma das abordagens. A abordagem Theme/Doc, por exemplo, faz a análise apenas de documentos de requisitos previamente estruturados de acordo com um padrão pré/definido pela própria abordagem. Desta maneira, torna seu uso inviável em documentos de requisitos desenvolvidos sem considerar este padrão.
Os dados analisados por cada uma das abordagens são também um ponto relevante desta comparação. É possível notar, através da análise da Tabela 4, que duas das abordagens estudadas limitam sua análise à apenas um tipo de requisito: os requisitos não/funcionais de um dado sistema, limitando assim a análise. Além disto, um fato que merece ser enaltecido é a possibilidade de analisar qualquer dado
relevante, proporcionada pelo uso da abordagem GT4CCI. Isto significa que esta abordagem não apenas analisa requisitos textuais do documento, mas também permite a análise de elementos gráficos, como diagramas de caso de uso, por exemplo.
Mais um ponto de destaque na análise desta Tabela Comparativa é a documentação gerada por cada uma das abordagens. Cada uma destas abordagens gera artefatos que documentam os resultados gerados a partir de sua aplicação em um dado documento. O que vale ser destacado é o fato de que algumas destas abordagens documentam apenas os interesses transversais em si, ignorando a documentação das relações existentes entre os interesses do sistema.
Por fim, outro ponto que merece especial atenção é o nível de automação de cada uma dessas abordagens. Duas destas abordagens, a Identificação Através da UML e o método DISCERN, não possuem qualquer automação ou ferramentas que deem suporte à aplicação do processo por elas proposto. Isto faz, em geral, com que a identificação de interesses transversais torne/se mais lenta e menos confiável. Contrastando com esta realidade há, dentre as abordagens estudadas, uma totalmente automatizada, a abordagem CCCINPL. A total automatização do processo de identificação de interesses transversais adiciona, certamente, ganhos em termos de celeridade. Entretanto, o analista não pode acompanhar o processo de identificação e, desta maneira, torna/se inviável a detecção de possíveis falhas neste processo e no próprio documento analisado, uma vez que esta abordagem retorna apenas o resultado final da análise.
Diante de todos estes pontos destacados, é possível ver que cada uma das abordagens possui características próprias, que as diferem umas das outras. Desta forma, é possível perceber similaridades e diferenças entre estas abordagens e vislumbrar limitações existentes em cada uma delas.
7 Considerações Finais
Este trabalho especificou e apresentou, de maneira detalhada, a abordagem GT4CCI. Essa abordagem, baseada na renomada metodologia de análise de dados , sistematiza e embasa a identificação de interesses transversais nos estágios mais iniciais do desenvolvimento de , utilizando documentos de requisitos como artefatos para a análise.
Para demonstrar e tornar mais clara a abordagem GT4CCI foram apresentados, neste trabalho, dois exemplos da aplicação da abordagem em documentos de requisitos. O primeiro exemplo, bastante simplificado, foi apresentado no Capítulo 3 deste trabalho e demonstrou em detalhes cada uma das etapas da abordagem. O segundo exemplo, mais robusto, utilizou o documento de requisitos do Sistema + - e foi apresentado no Capítulo 4 deste trabalho. Para avaliar a abordagem GT4CCI um estudo experimental foi realizado e seus resultados foram apresentados no Capítulo 5 deste trabalho.
Na Seção 7.1 são apresentadas as principais contribuições deste trabalho e na Seção 7.2 apresentamos as propostas de trabalhos futuros, objetivando dar continuidade a essa pesquisa.
7.1 Contribuições
A mais relevante contribuição deste trabalho é, sem dúvidas, a especificação da abordagem GT4CCI, uma nova abordagem para a identificação de interesses transversais utilizando documentos de requisitos. Diversas são as contribuições desta abordagem. Como principais, podemos citar:
• A abordagem GT4CCI sistematiza todo o processo de identificação de interesses transversais em documentos de requisitos, o que torna esta identificação mais simples e confiável;
• A abordagem GT4CCI possibilita a análise qualitativa de dados, baseada no contexto no qual estes interesses estão inseridos no documento de requisitos;
• A abordagem GT4CCI possibilita a identificação de interesses transversais em qualquer documento de requisitos já desenvolvido, sem que estejam, necessariamente, estruturados em qualquer padrão pré/definido;
• A abordagem GT4CCI permite a obtenção de resultados fortemente embasados nos dados, de fato, contidos no documento de requisitos
analisado, o que permite que estes resultados sejam facilmente rastreados e justificados;
• A abordagem GT4CCI possibilita uma melhor visualização do documento de requisitos analisado, destacando possíveis problemas existentes no mesmo e pontos que necessitam ser mais bem entendidos e analisados, proporcionando, assim, a possibilidade de obter um documento de requisitos com maior qualidade;
• A abordagem GT4CCI gera uma documentação bem detalhada e embasada, incluindo gráficos e tabelas de resultados, possibilitando um fácil acompanhamento e rastreamentos dos interesses ao longo do processo de desenvolvimento de ;
• A abordagem GT4CCI permite uma embasada e confiável identificação dos interesses, o que permite justificar as razões pelas quais alguns interesses são ou não considerados transversais;
• A abordagem GT4CCI conta com suporte ferramental, possibilitando a automatização de algumas de suas etapas;
• A abordagem GT4CCI inclui em seu processo duas novas etapas, não inerentes ao processo proposto pela Grounded Theory, que tornam a identificação e a documentação de interesses transversais mais prática, embasada e, principalmente, documentada;
• A abordagem GT4CCI estabelece, também, algumas heurísticas próprias para a identificação de interesses transversais em documentos de requisitos.
Além das contribuições já citadas, diretamente relacionadas à abordagem GT4CCI, outras importantes contribuições deste trabalho também devem ser mencionadas:
• O mapeamento das principais abordagens de identificação de interesses transversais em documento de requisitos já existentes e a identificação de suas limitações;
• A definição do planejamento do Estudo Experimental;
• A realização do Estudo Experimental que avaliou a abordagem GT4CCI;
• A comparação entre as principais abordagens de identificação de interesses transversais em documento de requisitos já existentes e a abordagem GT4CCI.
7.2 Trabalhos Futuros
Com o objetivo de dar continuidade à pesquisa desenvolvida por esse trabalho, algumas sugestões de trabalhos futuros podem ser citadas. Primeiramente, sugerimos a adaptação para a aplicação da abordagem GT4CCI à outras etapas do processo de desenvolvimento de . Desta maneira, sugere/se adaptar esta abordagem para identificar interesses transversais na etapa de codificação, por exemplo. Assim, será possível utilizar a abordagem GT4CCI durante uma maior parte do processo de desenvolvimento de .
Sugerimos também, como trabalho futuro, o desenvolvimento de uma ferramenta própria para a abordagem GT4CCI. Apesar da ferramenta Atlas.ti ser bastante completa e robusta, foi possível perceber, através do estudo experimental realizado neste trabalho, que há necessidade do desenvolvimento de uma ferramenta que dê suporte à todas as etapas do processo proposto pela abordagem GT4CCI. Diante disto, sugere/se a criação de uma ferramenta simples, de fácil uso e aprendizado, que suporte e automatize todas as etapas do processo proposto por esta abordagem.
A partir da realização do estudo experimental apresentado neste trabalho foi possível perceber, ainda, que alguns participantes observaram alguma dificuldade na utilização dos conectores. Essa dificuldade foi atribuída ao fato da nomenclatura utilizada pelos dois conectores definidos pela abordagem GT4CCI, “ ” e “
”, não ser suficientemente intuitiva e clara, o que gerou certa dificuldade na sua utilização. Desta maneira sugerimos também, como trabalho futuro, analisar a nomenclatura destes conectores e, se necessário, alterá/las para nomenclaturas mais intuitivas.
Por fim, como trabalho futuro, recomendamos também a execução de outros estudos experimentais que comparem a abordagem GT4CCI à outras renomadas abordagens de identificação de interesses transversais em documentos de requisitos, tais como Early/AIM e Theme/Doc. Através destes estudos experimentais será possível, então, aferir com precisão as principais similaridades e diferenças existentes entre as abordagens já propostas e a abordagem GT4CCI e também identificar possíveis melhorias a serem feitas abordagem proposta por esse trabalho.
Referências
Alencar, F.; Castro, J.; Moreira, A.; Araujo, J.; Silva, C.; Ramos, R.; Mylopoulos, J. (2008). Integration of Aspects with i* Models. Agent/Oriented Information Systems IV. Springer/Verlag. Hakodate, Japan.
Ali, B. S.; Kasirum, Z. M. (2008/A). A Review on Approaches for Identifying #
. : Advanced Computer Theory and Engineering, ICACTE '08.
" L p.p. 855 – 859.
Ali, B. S.; Kasirum, Z. M. (2008/B). Crosscutting concern identification at requirement level. : Malaysian Journal of Computer Science, vol. 21(2), pp.78/87.
Anacleto, A. C. S. (2009). Aplicação de Técnicas de Data Mining em Extracção de Elementos de Documentos Comerciais. Tese de Mestrado. Universidade do Porto. Porto, Portugal
Appeltauer, M.; Hirschfeld, R.; Masuhara, H.; Haupt, M.; Kawauchi, K. (2010). Event/ specic software composition in context/oriented programming. In: Benoît Baudry and Eric Wohlstadter (eds), Software Composition, volume 6144 of Lecture Notes in Computer Science, p.p. 50/65. Heidelberg: Springer Berlin.
Araújo, J.; Baniassad, E.; Clements, P.; Moreira, A.; Rashid, A.; Tekinerdoğan , E. (2005). Early Aspects: The Current Landscape. Technical Notes, CMU/SEI and Lancaster University.
Araújo, J.; Moreira, A. (2003). An Aspectual Use Case Driven Approach. : VIII Jornadas de Ingeniería de Software y Bases de Datos (JISBD 2003). Alicante, Spain. Araujo, J.; Moreira, A.; Brito, I.; Rashid, A. (2002). Aspect/Oriented Requirements
with UML. Workshop #; + %+ ,
Araújo, J.; Moreira, A.; Brito, I.; Rashid, A. (2002). Aspect/Oriented Requirements with UML. : Workshop on Aspect/Oriented Modelling with UML (UML 2002). Dresden, Germany.
Atlas.ti. (2011). Versão 6.2. Disponível em: <http://www.atlasti.com>. Acesso em: 28 oct. 2011.
Atlas.ti. (2012). Versão 7.0. Disponível em: <http://www.atlasti.com>. Acesso em: 17 sep. 2012.
Bandeira/de/Mello, R. (2006). Softwares em Pesquisa Qualitativa. : Godoi, C. K.; Bandeira/de/Mello, R.; Silva, A. B. d. (eds), Pesquisa Qualitativa em Estudos Organizacionais: Paradigmas, Estratégias e Métodos, São Paulo: Saraiva, Chapter 15. Baniassad, E.; Clarke, S. (2004). Finding Aspects in Requirements with Theme/Doc.
: Proceedings of Early Aspects 2004 (AOSD 2004). Lancaster, United Kingdom. Brito, I. (2004). Aspects Oriented Requirements Engineering. : 7th International Conference on Unified Modelling Language (UML 2004). Lisbon, Portugal.
Cappelli, C., Leite, J.C.S.P., Batista, T., Silva, L. An aspect/oriented approach to business process modeling. Proceedings of the 15th workshop on Early aspects, EA '09. ACM. New York, NY, USA, 2009.
Chitchyan, R; Sampaio, A; Rashid, A. (2006). A Tool Suit for Aspect/Oriented Requirements Engineering. : Workshop on Early Aspects (held at ICSE 2006). Shanghai, China.
Chung, L.; Nixon B.A.; Yu, E. (1995). Using Non/Functional Requirements to Systematically Select Among Alternatives in Architectural Design. : Proceedings of ICSE17 Workshop on Architectures for Software Systems, pp. 31/43.
Conte, T.; Cabral, R.; Travassos, G. H. (2009). Aplicando Grounded Theory na Análise Qualitativa de um Estudo de Observação em Engenharia de Software: Um Relato de Experiência. : V Workshop Um Olhar Sociotécnico sobre a Engenharia de Software (WOSES 2009). Ouro Preto, Minas Gerais.
Eaddy, M.; Aho, A.; Murphy, G. C. (2007). Identifying, Assigning, and Quantifying Crosscutting Concerns. : Workshop on Assessment of Contemporary Modularization Techniques (ACoM 2007).
Glaser, B. (1992). Basics of grounded theory analysis. Mill Valley, California: The Sociology Press.
Glaser, B.; Strauss, A. (1967). The discovery of grounded theory: Strategies for Qualitative Research. New York: Aldine Transaction.
Herrera, J.; Macia, I.; Salas, P.; Pinho, R.; Vargas, R.; Garcia, A.; Araujo, J.; Breitman, K. (2012). Revealing Crosscutting Concerns in Textual Requirements Documents: An Exploratory Study with Industry Systems. 26th Brazilian Symposium on Software Engineering. Natal, Brazil.
Jacobson, I.; Ng, P. (2005). Aspect/Oriented Software Development with Use Cases. Addison/Wesley.
Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda (1997). Aspect/Oriented Programming. : ECOOP 1997 / Proceedings of the 11th European Conference on Object/Oriented Programming, p.p. 220–242. Finland.
Kienzle, J.; Guelfi, N.; Mustafiz, S. (2009). + -
# / Technical Report. McGill Univ.
Li, H.; Krishnamurthi, S.; Fisler, K. (2002). Verifying Cross/Cutting Features as Open Systems. : ACM SIGSOFT Software Engineering Notes 27, p.p. 89–98.
Mohamed, A. Y. A.; Hegazy, A. E. F.; Dawood, A. R. (2010). Aspect Oriented Requirements Engineering. : Computer and Information Science. Volume 3, p.p. 135/154.
Pressman, R. (1992). Software Engeneering: a Practioner's Approach. 3 ed. McGraw Hill International Editions.
Rashid, A. (2008). Aspect/Oriented Requirements Engineering: An Introduction. 16th IEEE International Requirements Engineering (RE '08). Catalunya, Spain.
Rosenhainer, L. (2004). Identifying # in Requirements
Specifications. : Proceedings of OOPSLA Early Aspects 2004: Aspect/Oriented Requirements Engineering and Architecture Design. Vancouver, Canada.
Rosenhainer, L. (2005). The DISCERN Method: Dealing Separately with Crosscutting Concerns. : Proceedings of OOPSLA Early Aspects 2005. San Diego, USA.
S. M. Sutton Jr.; I. Rouvellou. (2002). Modeling of Software Concerns in Cosmos. Proceedings of the 1st International Conference on Aspect/Oriented Software
Development, p.p. 127–133. ACM Press.
Sampaio, A.; Chitchyan, R.; Rashid, A.; Rayson, P. (2005/B). EA/Miner: A Tool for Automating Aspect/Oriented Requirements Identification. International Conference on Automated Software Engineering (ASE'05). Long Beach, California, USA.
Sampaio, A.; Rashid, A.; Chitchyan, R.; Rayson, P. (2007). EA/Miner: Towards Automation in Aspect/Oriented Requirements Engineering. : Transactions on Aspect Oriented Software Development: Special Issue on Early Aspects.
Sampaio, A.; Rashid, A.; Rayson, P. (2005/A). ) # +: An Approach for Identifying Aspects in Requirements. Poster Paper. : Requirements Engineering Conference. Paris, France.
Sawyer, P.; Rayson, P.; Garside, R. (2000). REVERE: support for requirements synthesis from documents. Information Systems Frontiers Journal. Volume 4, issue 3, pp. 343 – 353. Kluwer, Netherlands.
Strauss, A. (1987). Qualitative analysis for social scientists. New York: Cambridge University Press.
Strauss, A.; Corbin, J. (1998). Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory. 2 ed. London: SAGE Publications. Travassos, G. H.; Gurov, D.; Amaral, E. A. G. (2002). Introdução à Engenharia de Software Experimental. Relatório Técnico. Rio de Janeiro, Brazil.
Yu, Y.; d. P. Leite, J.C.S.; Mylopoulos, J. (2004). From goals to aspects: Discovering aspects from requirements goal models. Proceedings of the 12th IEEE International Requirements Engineering Conference. Kyoto, Japan.
van Lamsweerde, K., Darimont, R., Massonet, P. (1993). The Meeting Scheduler System – Preliminary Definition. Internal Report. Université Catholique de Louvain. Silva Júnior, C.R., Perrelli, H., Mesquita, S. (2001). Documento de Requisitos do
Sistema Methodology Explorer. Disponível em:
!/
0 1
!
"
Questionário I – Conhecimento PrévioNome: ________________________________________________________________________
1. De acordo com sua experiência na elaboração, análise e uso de DOCUMENTOS DE REQUISITOS, classifique de acordo com os critérios acima:
( ) Já elaborei documentos de requisitos; ( ) Costumo elaborar documentos de requisitos;
( ) Ao elaborar documentos de requisitos, uso um template bem definido; ( ) Já fiz análise em documentos de requisitos;
( ) Costumo fazer análises em documentos de requisitos;
( ) Sou capaz de diferenciar requisitos funcionais e não-funcionais em documentos de requisitos; ( ) Sou capaz de reconhecer um requisito em um documento, ainda que ele não esteja explícito e bem definido.
2. De acordo com sua experiência na IDENTIFICAÇÃO DE INTERESSES TRANSVERSAIS, classifique de acordo com os critérios acima:
( ) Sei definir o que é um interesse transversal;
( ) Já fiz alguma identificação de interesses transversais; ( ) Costumo fazer identificação de interesses transversais;
( ) Já fiz a identificação de interesses transversais em documentos de requisitos;
( ) Costumo fazer a identificação de interesses transversais em documentos de requisitos;
( ) Conheço alguma(as) abordagem(ns) para a identificação de interesses transversais em documentos de requisitos;
( ) Já fiz uso de alguma(as) abordagem(ns) para a identificação de interesses transversais em documentos de requisitos.
Caso conheça ou já tenha utilizado alguma abordagem para a identificação de interesses transversais em documentos de requisitos, cite qual(is):
________________________________________________________________________ 0 – Discordo Totalmente
1 – Discordo Parcialmente 2 – Nem Concordo Nem Discordo
3 – Concordo Parcialmente 4 – Concordo Totalmente
!/
0 #
) 3
4
Documento de Requisitos – Sistema Methodology Explorer
DESCRIÇÃO DO SISTEMAO sistema Methodology Explorer é uma ferramenta para o processo de desenvolvimento de software. Fornece uma maneira intuitiva e eficiente para definir componentes adequados a uma empresa/projeto. Um componente é uma unidade da metodologia que pode ser manipulada isoladamente, por exemplo artefato, atividade etc.
Utilizando a ferramenta, o usuário - em geral, engenheiro de processos ou projetista de metodologias - poderá cadastrar novos componentes ou criar componentes a partir de outros já existentes. Além disso, poderá alterar, remover e consultar componentes já criados. Tais componentes podem ser exportados da ferramenta, gerando um documento texto, páginas HTML ou um arquivo PDF que podem ser visualizados sem utilizar a ferramenta.
A ferramenta conterá também testes de validação sobre os componentes criados. Estes são baseados no Rational Unified Process [2] (metodologia proposta pela empresa Rational Software Corporation [5]) e servem de ajuda aos usuários, evitando que este cometa pequenos erros.
Diante da facilidade de se definir metodologias, o Methodology Explorer contribui de modo decisivo para melhorar a qualidade do processo de desenvolvimento dos projetos de software de uma empresa.
Requisitos funcionais (casos de uso)
Cadastro
[RF001] Criar componente
Descrição do caso de uso: Este caso de uso permite que o usuário crie e armazene um novo componente no sistema.
Prioridade: Essencial Importante Desejável Entradas e pré-condições: não tem.
Saídas e pós-condição: um componente é cadastrado no sistema
[RF002] Excluir componente
Descrição do caso de uso: Este caso de uso permite que o usuário exclua um componente do cadastro de componentes do sistema. Um componente pode ser excluído de qualquer instanciação de metodologia (árvore).
Prioridade: Essencial Importante Desejável Entradas e pré-condições: recebe como entrada o componente que se deseja excluir
Saídas e pós-condição: o usuário consegue excluir o componente que deseja
[RF003] Alterar componente
Descrição do caso de uso: Este caso de uso permite que o usuário altere os dados de um componente.
Prioridade: Essencial Importante Desejável Entradas e pré-condições: recebe como entrada o componente que se deseja alterar. Saídas e pós-condição: um componente é alterado no sistema.
Interface
[RF001] Visualizar Componente
Descrição do caso de uso: Este caso de uso permite que o usuário visualize os dados de um determinado componente (todos os seus atributos, exceto aqueles que são considerados suas propriedades).
Prioridade: Essencial Importante Desejável Entradas e pré-condições: deve receber como entrada o componente que se deseja visualizar. Saídas e pós-condição: o usuário visualiza o componente desejado
[RF002] Copiar componente
Descrição do caso de uso: Este caso de uso permite que o usuário copie um componente do cadastro de componentes do sistema. Ou seja, copia o componente de onde ele estava e manda a cópia para