Orientação a aspectos - Revista Engenharia de Software Magazine 54

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (2)  (2)

Este artigo apresenta através de um estudo de caso como podemos proceder para lidar com interesses transversais em requisitos de software.

Artigo do tipo Estudo de Caso
Recursos especiais neste artigo:
Conteúdo sobre Engenharia.
Autores: Orestes Santos e Rodrigo Spinola
Orientação a aspectos
Este artigo aborda o tema orientação a aspectos sob a perspectiva do mapeamento de requisitos transversais. Para isso, inicialmente apresentamos a abordagem de mapeamento de requisitos transversais que será utilizada nesse artigo (INFR), detalhando sua estrutura e funcionamento. Em seguida descreveremos o processo de aplicação do INFR a um estudo de caso podendo assim aplicar na prática os conceitos propostos pela abordagem. Por fim, analisaremos a viabilidade da aplicação do INFR em uma situação real.


Em que situação o tema é útil

Um processo de desenvolvimento de software rastreável e modular é de vital importância para sua manutenção e evolução. Neste sentido, o conteúdo apresentado neste artigo é útil para apoiar estas questões quando lidamos com requisitos não funcionais.

Sistemas orientados a aspectos têm a identificação dos interesses transversais feitos na fase de desenvolvimento. Esse foco tardio leva à inexistência do mapeamento dos requisitos ortogonais que são subsídio para obter uma visualização do impacto das decisões tomadas durante o desenvolvimento. Por exemplo, qual será o impacto no sistema se ocorrer determinada mudança em um requisito específico? Por impacto entenda quais as mudanças decorrentes daquela ação. Requisitos ortogonais não mapeados levarão a problemas de rastreabilidade e modularização no processo de desenvolvimento de software.

Um processo de desenvolvimento de software rastreável e modular é de vital importância para sua manutenção e evolução. Tratar o mapeamento de interesses transversais em um estágio prematuro do processo de software irá evitar especificação e código emaranhados. A relação entre os requisitos funcionais e os não funcionais merece atenção porque em um sistema pouco rastreável não há como se identificar em quais pontos um requisito complementa o outro.

Requisitos não funcionais são propriedades que afetam o sistema como um todo. Medidas existentes para lidar com este tipo de requisito são limitadas devido à natureza diversa desses atributos. A maioria destas abordagens, no caso mecanismos de documentação, trata dos requisitos não funcionais separadamente dos funcionais. Isso mostra que a integração é difícil e que geralmente só é alcançada em estágios avançados do processo de desenvolvimento do software.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?