Etik ve Ahlak Kavramları

Rashid et al. (2003) e Rashid et al. (2002) propuseram uma abordagem para EROA baseada em pontos de vista (viewpoints). Nesta abordagem, são utilizados arquivos XML para especificação dos pontos de vista, dos interesses não funcionais e das regras de composição entre pontos de vista e interesses do software. Além disso, a ferramenta ARCADE, comentada na Seção 2.2.3, também é utilizada por essa abordagem para automatizar a tarefa de representação dos conceitos descritos anteriormente.

Identificação, Classificação e Representação de Interesses. A identificação

dos pontos de vista e interesses não funcionais é realizada por meio da análise dos requisitos do software pelo engenheiro de software. Uma vez identificados, eles são especificados em arquivos XML, semelhantes àqueles apresentados na abordagem

MDSoC (Seção 2.2.1). Após a identificação dos pontos de vista e dos interesses não

funcionais do software, define-se quais desses interesses são candidatos a interesses transversais. Para isso cria-se uma matriz de relacionamentos, na qual os interesses do software são colocados em suas linhas e os pontos de vista, em suas colunas (Quadro 2.2).

Cada célula dessa matriz, quando marcada, representa que um determinado interesse exerce influência sobre os requisitos do ponto de vista da coluna correspondente àquela célula. Sendo assim, é possível observar quais pontos de vista são entrecortados pelos interesses do software. Segundo os autores, quando um interesse entrecorta os requisitos de vários pontos de vista, isso pode indicar que se trata de um interesse transversal. No exemplo do Quadro 2.2, apresentado por Rashid

et al. (2003), o interesse “Disponibilidade” está entrelaçado com requisitos dos interesses “Pagamento” e “Cadastramento”, enquanto que o interesse “Tempo de Resposta” está entrelaçado apenas com “Pagamento”.

Quadro 2.2. Trecho de uma matriz de relacionamentos (adaptada de Rashid et al., 2003).

Interesses não funcionais/

Pontos de Vista Pagamento Cadastramento ...

Tempo de resposta X ...

Disponibilidade X X ...

... ... ... ...

Composição de Interesses e Detecção e Análise de Conflitos. Após a

identificação dos candidatos a interesses transversais e dos pontos de vista do software ter ocorrido, os mesmos devem ser compostos por meio de regras de composição. Posteriormente, a detecção e análise de conflitos deve ser realizada. A definição das regras de composição e da atividade de detecção e resolução de conflitos segue a mesma ideia da abordagem MDSoC (Moreira et al., 2005) e por esse motivo não será comentada novamente.

Pontos fortes e fracos. O principal ponto positivo desta abordagem é a

apresentação de um novo tipo de recurso para identificação de interesses transversais, a saber, a matriz de relacionamento.

Como pontos negativos, têm-se: (i) embora haja o apoio computacional ARCADE, muitas atividades onerosas continuam sem automatização, como por exemplo, a identificação de interesses a partir dos requisitos do software; (ii) além da baixa automatização, algumas das atividades desta abordagem são altamente dependentes da experiência do engenheiro de software com relação aos conceitos de interesses transversais, como por exemplo, identificação de interesses e definição da influência desses interesses sobre outros; e (iii) a matriz de relacionamentos proposta não contempla a situação em que um interesse funcional (tratado como ponto de vista) seja transversal.

2.2.6 Considerações finais sobre as abordagens para EROA

Algumas das limitações das abordagens apresentadas nesta seção podem ser as fontes para as causas da baixa efetividade proporcionada por essas abordagens quanto à identificação e classificação de interesses em requisitos de software, conforme foi comentado no Capítulo 1 desta tese. Nesta seção, a discussão sobre essas causas é retomada à luz dos trabalhos analisados neste capítulo, bem como daqueles obtidos a partir do MS sobre EROA conduzido neste doutorado (Parreira Júnior e Penteado, 2014; Parreira Júnior e Penteado, 2015d).

Causa 1: falta de compreensão a respeito do domínio dos interesses de software. Na maioria das abordagens para EROA existentes na literatura, em especial

naquelas que lidam com a identificação e classificação de interesses, o conhecimento sobre o domínio dos interesses de software é documentado em arquivos XML (templates) específicos, desenvolvidos pelos autores dessas abordagens. Tais arquivos geralmente não são acompanhados do meta-modelo que deu origem aos mesmos, nem compartilham entre si os principais conceitos e relacionamentos existentes no domínio dos interesses de software. Por exemplo, o arquivo proposto por Moreira et al. (2005) não contempla como informação de um interesse, a fonte que deu origem a ele, tais como um stakeholder, um documento de negócio, entre outros. Contudo, essa informação pode ser encontrada em templates de outras abordagens para EROA (Agostinho et al., 2008; Whittle e Araújo, 2004; Brito e Moreira, 2003). Em alguns casos, há divergências entre os termos utilizados para representar um mesmo conceito. Por exemplo, no conjunto de ferramentas proposto para a abordagem EA-Miner (Chitchyan

et al., 2006; Sampaio et al., 2005), em alguns casos ITs são tratados como “Early-

Aspects” e em outros casos, como aspectos (“Aspects”).

Causa 2: escassez de recursos apropriados para apoiar engenheiros de software durante a identificação e classificação dos interesses do software. Muitas

abordagens para EROA, tais como Theme/Doc (Clarke e Baniassad, 2005; Baniassad e Clarke, 2004), baseiam-se apenas na experiência dos engenheiros de software para a correta identificação e classificação dos interesses do software, o que pode levar à diminuição da precisão e da cobertura dessas abordagens. Em outras abordagens, esta atividade é apoiada por meio do uso de catálogos de requisitos não funcionais (Chernak, 2012; Zheng et al., 2010; Alencar et al., 2010; Mussbacher et al., 2010; Agostinho et al., 2008; Chitchyan et al., 2006; Soeiro et al., 2006; Moreira et al., 2005; Whittle e Araújo, 2004; Brito e Moreira, 2003), tais como os propostos por Cysneiro (2015), Chung e Leite (2000) e Boehm e In (1996). Entretanto, essa estratégia não é

adequada para o contexto da EROA, pois esses catálogos: (i) não são preparados para o domínio dos interesses de software, deixando de considerar algumas propriedades inerentes a esse domínio; e (ii) são descritos por meio de notações específicas para