Engenharia de Software

Tema :
Engenharia de Software Orientada a Aspectos
1.Introdução
Iremos abordar sobre Engenharia de software orientada a aspectos, onde iremos
primeiro fazer uma breve contextualização do tema e descrevermos cada etapa
de implantação do mesmo e as regras que a regem, assim como também
falaremos sobre a sua implantação, também iremos falar das consequências do
seu uso e os possíveis problemas que podemos encarar na sua implantação ou
uso.
2. Engenharia de Software Orientada a Aspectos

2.1. Contextualização
Engenharia de software orientada a aspectos (AOSE, do inglês aspect-oriented
software engineering) é uma abordagem para desenvolvimento de software que
se propõe a resolver esse problema e tornar os programas mais fáceis de manter
e reusar.
3. Características
Segundo Sommerville as principais características da Engenharia de software orientada a aspectos são:

1. Ela é baseada em abstrações chamadas ‘aspectos’, que implementam funcionalidade de um

sistema que pode ser requerida em vários lugares diferentes em um programa.

2. Os aspectos encapsulam a funcionalidade que cruza e coexiste com outra funcionalidade que
existe no sistema. Eles são usados junto com outras abstrações, como objetos e métodos.

3. Pode-se especificar que o código transversal deve ser incluído antes ou depois da chamada de
um método específico ou quando um atributo é acessado. Essencialmente, o aspecto é composto
no programa para criar um novo sistema aumentado.

4. E uma característica importante de aspectos é que eles incluem uma definição sobre onde
devem ser incluídos em um programa, assim como o código que implementa o interesse
transversal.
4. Benefícios
 
Segundo Roger Presman, o principal benefício de uma abordagem orientada a
aspectos é que ela suporta a separação de interesses. Como separar interesses
em elementos diferentes em vez de incluir interesses diferentes na mesma
abstração lógica é uma boa prática de engenharia de software. Ao apresentar
interesses transversais como aspectos, esses interesses podem ser entendidos,
reusados e modificados de forma independente, sem a preocupação de onde o
código é usado no sistema central.
5.Separacao de Interesses
Segundo Roger Presman (1982) ,a separação de interesses é um princípio-chave de
projeto e implementação de software. Isso significa que deve-se organizar seu software de
tal forma que cada elemento do programa (classe, método, procedimento, entre outros.)
faça apenas uma coisa. Assim poderá concentrar-se nesse elemento sem se preocupar com
outros elementos no programa. Poderá entender cada parte do programa conhecendo seus
interesses, sem a necessidade de entender outros elementos. Quando as mudanças forem
necessárias, elas serão feitas em um número pequeno de elementos.
5.1.Tipos de Interesses
Existem vários tipos diferentes de interesses de stakeholder:
1. Interesses funcionais, relacionados com uma funcionalidade específica a ser incluída no sistema. Por exemplo, em um
sistema de controle de trens, um interesse funcional específico seria a frenagem do trem.
 
2. Interesses de qualidade de serviço, relacionados ao comportamento não funcional de um sistema. Incluem
características como desempenho, confiabilidade e disponibilidade.
 
3. Interesses de políticas, relacionados com as políticas gerais que governam o uso de um sistema. Interesses de políticas
incluem interesses de segurança e interesses relacionados com regras de negócio.
 
4. Interesses de sistemas, relacionados com atributos do sistema como um todo, tais como manutenibilidade e
configurabilidade.
 
5. Interesses organizacionais, relacionados com objetivos e prioridades organizacionais. Incluem a produção de um
sistema dentro do orçamento, fazendo uso de ativos existentes de software e mantendo a reputação da organização.
5.2.INTERESSES TRANSVERSAIS

 Interesses transversais são interesses cuja implementação atravessa uma série de

componentes do programa.

 Isso resulta em problemas quando uma mudança de interesse tem de ser feita – o código a ser
alterado não é localizada, mas é em lugares diferentes em todo o sistema.

 Interesses transversais levam ao entrelaçamento e espalhamento.

De referir que Segundo Sommeville, a implementação dos interesses centrais

nas linguagens de programação convencionais normalmente inclui código
adicional para implementar interesses transversais, funcionais, de qualidade de
serviço e de políticas. Isso gera dois fenômenos indesejáveis: entrelaçamento
(tangling) e espalhamento (scattering).
 O entrelaçamento ocorre quando um módulo do sistema inclui
código que implementa diferentes requisitos.
 Referir que o fenômeno relacionado de espalhamento ocorre quando a implementação
de um único interesse (um requisito lógico ou conjunto de requisitos) está espalhada por
vários componentes em um programa. É mais provável que isso ocorra quando os requisitos
relacionados com os interesses funcionais secundários ou interesses de políticas são
implementados.
ASPECTOS, PONTOS DE JUNÇÃO E PONTOS DE CORTE

 Um aspecto é uma abstração que implementa um interesse. Ele inclui informações as quais devem ser
incluídas em um programa.

 Um ponto de junção é um lugar em um programa onde um aspecto pode ser incluído (composto).

 Um ponto de corte define onde (nos pontos de junção) o aspecto será incluído no programa.
De referir que a capacidade de especificar, com pontos de corte, onde o código deve ser executado, é a
característica que diferencia os aspectos. No entanto, para entender o que significa ponto de corte,
precisamos entender outro conceito— o ponto de junção. Um ponto de junção é um evento que ocorre
durante a execução de um programa.

Segundo Sommeville existem vários tipos possíveis de eventos que podem ocorrer durante a execução de
um programa. Um modelo de ponto de junção define o conjunto de eventos que podem ser referenciados
em um programa orientado a aspectos. Modelos de pontos de junção não são padronizados, e cada
linguagem de programação orientada a aspectos possui seu próprio modelo de pontos de junção. Por
exemplo, em AspectJ, os eventos que fazem parte do modelo de pontos de junção incluem:

1. Eventos de chamada — chama um método ou um construtor;

2. Eventos de execução — a execução de um método ou de um construtor;
3. Eventos de iniciação — iniciação de classe ou objeto;
4. Eventos de dados — acesso ou atualização de um campo;
5. Eventos de exceção — tratamento de uma exceção.
PONTOS DE CORTE-Adendo

Identifica os eventos específicos com os quais cada adendo deve ser associado.
Exemplos de contextos em que o adendo pode ser composto em um programa:

o Antes da execução de um método específico.

o Após o retorno normal ou excepcional de um método

o Quando um campo em um objeto é modificado

COMPOSIÇÃO DE ASPECTOS
Compositores de aspectos processam o código fonte e compõem os aspectos no programa nos
pontos de junção especificados.
Três abordagens para composição de aspectos:

Pré-processamento de código-fonte.
Composição em tempo de ligação.
Composição dinâmica em tempo de execução.

EX: ilustracao de uma composicao hospitalar.

ENGENHARIA DE SOFTWARE COM ASPECTOS
 Aspectos foram introduzidos como uma construção de linguagem de programação,
mas, como a noção de interesses vem dos requisitos, uma abordagem orientada a
aspectos pode ser adotada em todas as fases no processo de desenvolvimento de
software.

 A arquitetura de um sistema orientada a aspectos é baseada em torno de um

sistema central mais extensões.

 O sistema central implementa os principais interesses.

 As extensões implementam interesses secundários e transversais.

 SISTEMA CENTRAL COM EXTENSÕES
Os aspectos são uma maneira para implementar essas extensões e podem ser compostos com a
funcionalidade do sistema central usando recursos de composição do ambiente de programação orientado a
aspectos.
TIPOS DE EXTENSÃO
 Extensões funcionais secundárias
Adicionar ao sistema central novas capacidades funcionais.

 Extensões de políticas
Adicionar capacidades funcionais para apoiar uma política organizacional,
tais como proteção.

 Extensões de qualidade de serviço (QoS – Quality of Service)

Adicionar capacidades funcionais para ajudar a atingir requisitos de
qualidade de serviço.

 Extensões de infraestrutura
Adicionar capacidades funcionais para apoiar a implementação do sistema
em algumas plataformas específicas.
PONTOS IMPORTANTES QUE NÃO PODEMOS IGNORAR :

 Abordagens de desenvolvimento de software orientadas a aspectos, suportam a separação de interesses.

 Por meio da representação dos interesses transversais como aspectos, os interesses individuais podem ser
compreendidos, reusados e modificados sem alterar outras partes do programa.

 O entrelaçamento ocorre quando um módulo em um sistema inclui códigos que implementa requisitos de
sistemas diferentes.
 O espalhamento ocorre quando a implementação de um interesse está espalhada por vários componentes.

 Os aspectos incluem um ponto de corte que define onde o aspecto será composto no programa, e um adendo o
código para implementar o interesse transversal.
 Pontos de junção são eventos que podem ser referenciados em um ponto de corte.

 Para garantir a separação de interesses, os sistemas podem ser concebidos como um sistema central que
implementa os interesses primários dos stakeholders, e um conjunto de extensões que implementam os interesses
secundários.
ENGENHARIA DE REQUISITOS ORIENTADA A INTERESSES
 Uma abordagem de engenharia de requisitos que incide sobre os interesses dos
clientes é consistente com o desenvolvimento de software orientado a aspectos.

 Pontos de vista são uma maneira de separar as interesses dos diferentes

stakeholders.

 Pontos de vista representam os requisitos dos grupos de stakeholders

relacionados.

 Interesses transversais são interesses que são identificados por todos os pontos
de vista.
PONTOS DE VISTA E INTERESSES
Portanto, podemos perceber que os
requisitos funcionais secundários
identificados a partir de qualquer
ponto de vista não necessariamente
cruzam os requisitos dos outros pontos
de vista. Por exemplo, apenas o ponto
de vista de equipamentos está
interessado em completar os registros
de equipamentos. Esses requisitos
refletem a necessidade desse ponto de
vista e esses interesses podem não ser
compartilhados com outros pontos de
vista. No entanto, além dos requisitos
funcionais secundários, existem
interesses transversais que geram
requisitos importantes para alguns ou
todos os pontos de vista.
PROJETO E PROGRAMAÇÃO ORIENTADOS A ASPECTOS

Projeto orientado a aspectos

O processo de projetar um sistema que faz uso de aspectos para implementar os interesses transversais e
extensões que são identificados durante o processo de engenharia de requisitos.

Programação orientada a aspectos

A implementação de um projeto orientado a aspectos usando uma linguagem de programação orientada a
aspectos, como a AspectJ.
Mas também devemos compreender como esses aspectos serão compostos com outros componentes
de sistema e garantir que não apareçam ambiguidades de composição.
Como mostra exemplos de três casos de uso abaixo que poderiam ser parte de um sistema de
gerenciamento de inventário. Eles refletem os interesses de adicionar um equipamento a um
inventário e solicitar equipamento. Solicitar equipamento e adicionar equipamento a um depósito são
interesses relacionados. Uma vez que os itens solicitados são entregues, eles devem ser adicionados
ao inventário e entregues a um depósito de equipamentos.
 CASOS DE USO DE EXTENSÃO
-Caso de uso de extencao evitar conflito ,voltando a ilustracao passada.
 Desenvolver um processo efetivo para projeto orientado a aspectos é essencial se o projeto
orientado a aspectos for aceito e usado. Segundo Sommeville ele sugire que um processo de
projeto orientado a aspectos deve incluir as atividades. E Essas atividades são:
1.Projeto de sistema central – Onde se projeta a arquitetura do sistema para suportar a funcionalidade central
do sistema.

2.Identificação e projeto de aspectos – Começando com as extensões identificadas nos requisitos de sistema,
é necessário analisá-las para ver se são aspectos em si ou se devem ser divididos em vários aspectos.

3.Projeto de composição – Nessa fase, você analisa o sistema central e projeta o aspecto para descobrir onde
os aspectos devem ser compostos com o núcleo do sistema.

4.Análise resolução de conflitos. Um problema com aspectos é que eles podem interferir uns com
os outros quando são compostos com o sistema central. Conflitos ocorrem quando há um choque de
ponto de corte com aspectos diferentes especificando que devem ser compostos no mesmo ponto do
programa.
UM PROCESSO GENÉRICO DE PROJETO ORIENTADO A ASPECTOS

5.Projeto de nomenclatura. Essa é uma atividade importante de projeto que define os

padrões para a nomenclatura de entidades no programa. Isso é essencial para evitar
problemas de pontos de corte acidentais, os quais ocorrem quando, em algum ponto
de junção do programa, o nome acidentalmente combina com o padrão de um ponto
de corte.
EXTENSÕES DA UML
Expressar um projeto orientado a aspectos na UML requer:

 Uma forma de modelar os aspectos usando estereótipos da UML.

 Um meio de especificar os pontos de junção onde os adendos do

aspecto devem ser compostos com o
sistema central.
UM MODELO DE PROJETO ORIENTADO A ASPECTOS

Portanto falamos tanto de projecto e seus 5 ponto ,abaixo temos um exemplo:

VERIFICAÇÃO E VALIDAÇÃO

 O processo de mostrar que um programa atende a sua especificação (verificação) e

atende às reais necessidades dos seus stakeholders (validação).

 Como quaisquer outros sistemas, os sistemas orientados a aspectos podem ser testados
como caixas-pretas usando a especificação para derivar os testes.

 No entanto, as inspeções de programa e os testes "caixabranca“ que contam com o

código fonte do programa são problemáticos.

 Os aspectos também introduzem testes adicionais dos problemas.

PROBLEMAS DE INSPEÇÃO DE PROGRAMA
Para inspecionar um programa (em uma linguagem convencional) de forma
eficaz, devemos ser capazes de ler da direita para a esquerda e de cima para
baixo.

 Os aspectos tornam isso impossível pois o programa é um documento web e

não um documento sequencial.

 A partir do código-fonte, não podemos dizer onde um aspecto será composto

e executado.

O achatamento de um programa orientado a aspectos para leitura é

praticamente impossível.
TESTE DE CAIXA BRANCA

 O objetivo do teste de caixa branca é usar o conhecimento do código-fonte para projetar

testes que ofereçam algum nível de cobertura do programa, por exemplo cada ramo lógico
em um programa deve ser executado pelo menos uma vez.
Portanto no teste podemos encontrar os seguintes problemas ,

Problemas de aspectos:
1. Como o conhecimento sobre o código-fonte pode ser usado para derivar sistematicamente testes do
programa?
2. O que significa exatamente cobertura de teste?
3. Como a interferência do aspecto pode ser testada? Conforme vimos, a interferência do aspecto ocorre
quando dois ou mais aspectos usam a mesma especificação de ponto de corte.
4. Como os testes podem ser projetados para que todos os pontos de junção do programa sejam executados e
testes de aspectos adequados sejam aplicados?
Derivar um fluxograma de programa de um programa com aspectos é impossível.
Portanto, é difícil projetar sistematicamente testes que assegurem que todas as
combinações de códigos bases e aspectos sejam executadas.

 Basicamente, esses problemas com testes ocorrem porque os aspectos são

fortemente interligados com o código-base de um sistema. Por isso, são difíceis
de serem testados isoladamente. Como eles podem ser compostos no programa
em vários lugares diferentes, não podemos ter certeza de que um aspecto que
funciona corretamente em um ponto de junção funcionará corretamente em todos
os pontos de junção. Todos esses continuam sendo problemas a serem
pesquisados no desenvolvimento de software orientado a aspectos.
Resumo de Todo Processo
Exemplo de um AspectJ de um Sistema Bancario
Solucao para Aspectos
 Vantagens e Desvantagens
 
a)Vantagens
 
 Separação de Interesses transversais;
 Fácil reuso;
 Menor Complexidade dos componentes;
 As classes não conhecem os aspectos;
 Os interesses podem ser anexados em paralelo;
 Configuração (Plugabilidade).
 
 
b)Desvantagens
 Novo paradigma;
 Requer muito aprendizado e treinamento na nova forma de pensar;
 Fragmentação dos Códigos (muitos componentes pequenos);
 Ausência de suporte Ferramental e poucos recursos;
 Linguagens ainda pouco maduras.
Conclusão
Através deste trabalho de pesquisa conclui-se que na maioria dos sistemas de grande porte, os relacionamentos
entre requisitos e componentes de programa são complexos. Um único requisito pode ser implementado por uma
série de componentes, e cada componente pode incluir elementos de vários requisitos. Na prática, isso significa que
mudar requisitos pode envolver o entendimento e a alteração de vários componentes. Como alternativa, um
componente pode prover alguma funcionalidade central, mas também incluir o código que implementa vários
requisitos de sistema. Mesmo quando parece haver reúso significativo em potencial, pode ficar caro reusar tais
componentes. O reúso pode envolver sua alteração para remover um código extra
que não esteja associado com a funcionalidade central do componente, e que isso tudo acaba tornando difícil de
efetuar os testes e gera um problema no uso da Engenharia de software orientada a aspectos, mesmo na analise do
código fonte, pois num sistema com enumeras componentes ligadas a um requisito teríamos várias dificuldades de
analise e testagem.
Não só, também desenvolvimento de software orientado por aspectos e uma técnica nova cujo objetivo e permitir a
definição separada de requisitos transversais as classes de um sistema orientado por objetos. Por atravessarem todo
o código, tais requisitos são, em geral, de difícil modularização em linguagens orientadas por objetos puras. Com a
orientação por aspectos, requisitos transversais, tais como geração de registros de operações, controle
sincronização e comunicação, podem ser implementados de maneira elegante, eficiente e modular, aumentando o
nível de reutilização de código em sistemas.
FIM
OBRIGADO