O modelo de engenharia de requisitos orientado a aspectos foi proposto inicialmente por Rashid et al. (2002) e, posteriormente, foi adaptado com o uso do modelo de casos de uso e diagramas de seqüência em UML, por Araújo et al. (2002). Este modelo tem a finalidade de separar interesses transversais não-funcionais na fase de requisitos e posteriormente compô-los utilizando o modelo de casos de usos (RASHID et al., 2002). O modelo de requisitos orientado a aspectos com UML é apresentado na Figura 26.
Figura 26 – Modelo de requisitos orientados a aspectos de Araújo et al. (2002).
Com base nos requisitos do sistema de software a ser desenvolvido, os interesses não-funcionais são elicitados a partir de discussões com as partes interessadas. Paralelamente, os requisitos funcionais são especificados através de diagramas de casos de uso e diagramas de seqüência.
Os interesses não-funcionais são analisados e, caso afetem mais de um caso de uso, são especificados conforme formulário da Tabela 2.
Tabela 2 – Formulário de especificação de um interesse transversal.
Interesse Transversal <Nome>
Descrição <Descrição do interesse>
Prioridade <Prioridade pode ser Max, Méd e Min>
Lista de Requisitos <Requisitos que descrevem o interesse>
Lista de Modelos <Modelos UML influenciados pelo interesse>
A composição de um interesse não-funcional no diagrama de casos de uso é feita incluindo-se um novo caso de uso com o nome do interesse
Identificar & Descrever Interesses Não- Funcionais Identificar e Especificar Interesses Transversais Compor Interesses Transversais nos Modelos UML Identificar e Resolver Conflitos Especificar Requisitos Funcionais Requisitos Interesses Transversais Requisitos Compostos Interesses Funcionais
transversal, definido na Tabela 2, porém com um relacionamento do tipo <<sobreposição>>, <<substituição>> ou <<empacotamento>>.
O relacionamento do tipo <<sobreposição>> significa que o interesse transversal modifica o requisito funcional que ele afeta. Neste caso, o interesse transversal pode ser executado antes ou depois da execução do requisito funcional. O relacionamento de <<substituição>> especifica que o interesse transversal substitui o requisito funcional que ele atravessa. O relacionamento de <<empacotamento>> especifica que o interesse transversal encapsula o requisito funcional que ele atravessa. Neste caso, o comportamento descrito pelo requisito funcional é empacotado pelo comportamento descrito pelo interesse transversal. Um exemplo do diagrama composto pode ser visualizado na Figura 27.
Figura 27 – Exemplo de diagrama composto com o interesse transversal de tempo de resposta adaptado de Araújo et al. (2002).
A Figura 27 apresenta um exemplo de diagrama de casos de uso referente ao sistema de rodovias portuguesas de alta velocidade. Em um sistema de tarifação do tráfego rodoviário, motoristas de veículos autorizados são cobrados automaticamente assim que passam por portões de cobrança. O interesse transversal não-funcional Tempo de Resposta do Portão empacota os casos de uso entrar na rodovia, sair da rodovia e passar sinalização. Isto significa que o comportamento funcional descrito pelos casos de uso são empacotados pelo comportamento descrito no caso de uso de tempo de resposta do portão. Diagramas de seqüência devem ser construídos para representar cenários do sistema de software e a seqüência de eventos referentes à composição.
Durante a composição de interesses transversais, situações de conflito podem ocorrer. No exemplo, o interesse transversal de segurança pode conflitar com o de tempo de resposta. Desta forma, as contribuições entre
interesses devem ser avaliadas e, em geral, o interesse transversal de maior prioridade deve ser composto primeiro. Para a priorização, análises de trade-off também devem ser conduzidas entre as partes interessadas.
3.3.2 Modelo de Atributos de Qualidade Transversais para a Engenharia de Requisitos
Um modelo para atributos de qualidade transversais, utilizando UML, foi proposto em Brito, Moreira e Araújo (2002) e Moreira, Araújo e Brito (2002). Este modelo tem o objetivo de identificar e especificar atributos de qualidade com o objetivo de incluí-los na descrição funcional do sistema de software durante a fase de requisitos (MOREIRA; ARAÚJO; BRITO, 2002). Este modelo está apresentado na Figura 28.
Figura 28 – Modelo de requisitos para atributos de qualidade de Brito, Moreira e Araújo (2002). Identificar Identificar Atores e Casos de Uso Identificar Atributos de Qualidade Especificar Construir o Diagrama de Casos de Uso Especificar Casos de Uso Especificar Atributos de Qualidade usando Formulários Identificar Atributos Transversais de Qualidade Integrar Integrar atributos de qualidade transversais com
Este modelo é composto de três atividades principais: identificar, especificar e integrar requisitos.
A atividade para identificar requisitos consiste em detectar todos os requisitos do sistema de software e selecionar os atributos de qualidade relevantes para as partes interessadas.
A atividade para especificar requisitos é composta por: construir o diagrama de casos de uso, especificar de requisitos funcionais utilizando casos de uso, especificar atributos de qualidade usando formulários e identificar atributos transversais de qualidade, a fim de identificar os atributos de qualidade que afetam os requisitos funcionais. O formulário de especificação dos atributos de qualidade é apresentado na Tabela 3.
Tabela 3 – Formulário de especificação de um atributo de qualidade adaptado de Moreira, Araújo e Brito (2002).
Nome <Nome do atributo de qualidade>
Descrição <Descrição breve>
Foco <Sistema de software ou processo de desenvolvimento>
Origem <Origem da informação, por exemplo, partes interessadas, documentos, etc>
Decomposição <Decomposição de atributos de qualidade. Quando todos os sub-atributos de qualidade são necessários para atender um atributo de qualidade, deve existir um relacionamento do tipo E entre eles. Se nem todos os sub-atributos de qualidade são necessários para atender um atributo de qualidade, deve existir um relacionamento do tipo OU entre eles>
Prioridade <Importância do atributo de qualidade para as partes interessadas. Pode ser MÁXIMA, ALTA, BAIXA e MÍNIMA>
Obrigatoriedade <Opcional ou mandatória>
Onde <Lista dos modelos afetados pelo atributo de qualidade>
Requisitos <Lista dos requisitos que descrevem o atributo de qualidade>
Contribuição <Descreve como um atributo de qualidade pode ser afetado por outros atributos de qualidade. Esta contribuição pode ser positiva (+) ou negativa (-)>
A sub-atividade para identificar atributos de qualidade transversais é feita a partir da análise do campo onde da Tabela 3. Se um atributo de qualidade afetar mais de um caso de uso, este atributo será considerado transversal. Esta informação é confirmada através da análise do campo requisitos.
A atividade para integrar requisitos propõe um conjunto de modelos para representar a integração dos requisitos de qualidade transversais e requisitos funcionais. Os atributos de qualidade transversais são adicionados ao diagrama de casos de uso como novos casos de uso. Utiliza-se o relacionamento de inclusão entre os elementos. Um exemplo pode ser observado na Figura 29.
Figura 29 – Exemplo de diagrama composto com o interesse transversal de tempo de resposta de Moreira, Araújo e Brito (2002).
Na atividade integrar requisitos são utilizados os operadores de combinação (weaving), sobreposição, substituição e empacotamento. Um exemplo da utilização destes operadores na abordagem proposta em Brito, Moreira e Araújo (2002) é apresentada na Figura 30.
Figura 30 – Exemplo do uso de operadores de combinação no diagrama de casos de uso de Moreira, Araújo e Brito (2002).
Segundo os autores, neste exemplo ocorreu uma situação de sobreposição entre os atributos de qualidade de integridade e confidencialidade e a confidencialidade deve ser aplicada antes de execução da integridade. A linha tracejada mostra a condição depois e a linha cheia a condição antes.
<<depois>>
<<antes>>
Integridade