Sub-Processo 5: Elaborar o Modelo Composto

Este sub-processo tem o objetivo de incorporar o resultado da decomposição dos RNFs, através dos SIGs, ao modelo de casos de uso. Sua representação é apresentada na Figura 49.

Figura 49 – Sub-processo elaborar modelo composto (5).

A atividade para identificar metas operacionais e restrições de projeto (5.1) tem a finalidade de classificar as metas identificadas nos SIGs em metas operacionais ou restrições de projeto.

As metas operacionais são novas funções que devem ser incorporadas ao sistema de software. As restrições de projeto são impactam nas atividades do desenvolvimento e contribuem para que uma meta operacional possa ser satisfeita; são exemplos de restrições de projeto a infra-estrutura de hardware, restrições de implementação, documentação ou gerenciamento de projeto.

As metas operacionais devem ser incorporadas ao modelo de casos de uso do sistema de software através de novos casos de uso. A identificação de restrições de projeto deve sugerir restrições a serem impostas ao sistema de

software. Estas informações devem ser atualizadas na tabela de RNF com metas operacionais e restrições de projeto.

Nesta tabela deve ser identificado:

• Número seqüencial atribuído ao SIG que originou a meta;

• Texto da meta;

• Classificação da meta em: meta operacional ou restrição de projeto;

• Origem da meta, que pode ser: NFR (proveniente do NFR Framework), tática (proveniente da proposta de Bass, Clements e Kazman (2003)) ou definida pelo engenheiro de requisitos (caso não existam catálogos disponíveis relacionados ao tipo de RNF a ser detalhado);

• Nome do caso de uso a ser incluído no modelo de casos de uso, quando se tratar de meta operacional ou a descrição da restrição de projeto a ser imposta ao sistema de software, quando se tratar de restrição de projeto.

Recomenda-se que cada meta operacional seja definida em apenas um caso de uso pois, se mais de uma meta operacional for definida em um único caso de uso são necessários controles adicionais para identificá-las.

A atividade para definir pontos de composição (5.2) utiliza regras para a composição através dos operadores de sobreposição, substituição e empacotamento, definidos no modelo de engenharia de requisitos orientado a aspectos com UML (ARAÚJO et al., 2002), apresentado na seção 3.3.1.

A definição da tabela de RNF com composição foi baseada na proposta da abordagem direcionada a casos de uso para o desenvolvimento de software orientado a aspectos (SOUSA, 2004), descrita na seção 3.3.5.

Esta tabela possui:

• Identificação do caso de uso que recebe a composição;

• Passo do seu fluxo básico ou alternativo do caso de uso em que a composição é feita;

• Regra de composição a ser aplicada;

• Condição da composição, quando se tratar de substituição ou empacotamento. No caso da substituição, deve ser definida a ação que substitui o fluxo básico ou alternativo do caso de uso que recebe a

composição. No caso do empacotamento, deve ser definida a situação em que a inclusão deve ocorrer.

Somente metas operacionais devem ser compostas no modelo de casos de uso, por representarem funções a serem adicionadas no sistema de software. Restrições de projeto somente terão sua descrição definida na tabela de RNF com meta operacional ou restrição de projeto.

A partir do momento em que os pontos de composição estão definidos e a tabela de RNF com composição está preenchida, novas propagações, que antes não foram detectados podem ser identificadas. Uma confirmação das propagações deve ser feita na atividade confirmar propagação (5.3), e caso exista necessidade de atualização das propagações, esta atividade deve ser remetida para o sub-processo de identificação de aspectos, onde a tabela de RNF com propagações e o SIG, devem ser atualizados e o processo reiniciado a partir deste ponto, como mostra o link B na Figura 49. A atividade 5.3 pode não ser executada caso não exista necessidade de revisão das propagações.

A atividade para resolver de conflitos (5.4) deve ser iniciada a partir da tabela de RNF com composição. A análise de conflitos tem a finalidade de identificar pontos de composição que coincidam no mesmo passo de um cenário de um caso de uso, com a mesma regra de composição. Estes conflitos são identificados e a tabela de RNF com prioridades é preenchida.

Esta tabela possui a definição da prioridade de composição e, o menor valor da atribuído na coluna de prioridade da composição representa a prioridade mais alta.

A atividade para atualizar o modelo do sistema de software (5.5) com as informações da composição encerra este sub-processo. Novos casos de uso são adicionados no diagrama de casos de uso através do relacionamento de inclusão. Esta definição é baseada na proposta do modelo de atributos de qualidade transversais para a engenharia de requisitos, descrita na seção 3.3.2 deste trabalho.

Um estereótipo <<aspecto>> deve ser incluído no novo caso de uso, caso o requisito não-funcional representado seja um aspecto.

É importante salientar que requisitos não-funcionais que não são identificados como aspectos são também tratados por este sub-processo. Os

operadores de composição, bem como a inclusão de novos casos de uso são também contemplados. Neste caso estereótipos não são utilizados.

Caso ocorra o inter-relacionamento entre requisitos não-funcionais, isto é, caso exista necessidade de relacionar os novos casos de uso entre si, a definição das especificações dos novos casos de uso deve ser concluída para que a tabela de RNF com composição seja preenchida. Esta situação é apresentada na atividade 5.5, como mostra o link C da Figura 49.

A saída deste sub-processo consiste do modelo de casos de uso atualizado, a tabela de RNF com prioridades e o diagrama integrado. O modelo de casos de uso recebido como dado de entrada no PARNAFOA não é alterado. A informação sobre o passo do fluxo básico ou alternativo em que ocorre a composição dos novos casos de uso fica disponível somente na planilha de RNF com prioridades.

4.8 Considerações Finais

A definição inicial do PARNAFOA foi revisada até chegar nesta versão que foi apresentada. Informações para que a revisão pudesse ser realizada foram coletadas à medida que o processo foi aplicado e avaliado em cinco sistemas de software com características diversas. Foi percebida também a evolução na integração dos métodos e adequação dos detalhamentos dos métodos originais, utilizados no PARNAFOA.

A definição do PARNAFOA considerou abordagens e processos propostos na literatura, bem como a integração e detalhamento de métodos relacionados aos RNFs e aspectos. As abordagens e processos integrados ao PARNAFOA e o detalhamento dos métodos utilizados neste processo foram contribuições deste trabalho.