A Importância Dos Requisitos Não Funcionais No Desenvolvimento de Um Sistema Orientada A Aspecto

UNIVERSIDADE DO PLANALTO CATARINENSE
CURSO DE SISTEMAS DE INFORMAÇÃO

(BACHARELADO)
JOSÉ AUGUSTO ZANOTTO FRANKLIN
A IMPORTÂNCIA DOS REQUISITOS NÃO FUNCIONAIS NO

DESENVOLVIMENTO DE UM SISTEMA ORIENTADA A ASPECTO
LAGES (SC)
ANO 2015
0

Trabalho de Conclusão de Curso

submetido à Universidade do Planalto
Catarinense para obtenção dos créditos
de disciplina com nome equivalente no
curso de Sistemas de Informação -
Bacharelado.
Orientação: Prof(ª). Hugo Estevam

Longo, Esp.
LAGES (SC)
ANO 2015
1

ESTE RELATÓRIO, DO TRABALHO DE

CONCLUSÃO DE CURSO, FOI
JULGADO ADEQUADO PARA
OBTENÇÃO DOS CRÉDITOS DA
DISCIPLINA DE TRABALHO DE
CONCLUSÃO DE CURSO, DO 8º.
SEMESTRE, OBRIGATÓRIA PARA
OBTENÇÃO DO TÍTULO DE:
BACHAREL EM SISTEMAS DE
INFORMAÇÃO
Lages (SC), 23 de agosto de 2015
Prof. Hugo Estevam Longo, Esp.

Orientador
BANCA EXAMINADORA:
Prof. Madalena Pereira da Silva, Msc. Prof. Claiton Camargo de Souza.

UNIPLAC UNIPLAC
Prof. Claiton Camargo de Souza. Prof. Madalena Pereira da Silva, Msc.

Coordenador de Curso Professora de TCC
Dedico esse trabalho e todos que me
apoiaram para que sempre progredisse no
curso e todos que auxiliaram na conclusão
desse trabalho. Em especial a minha
família.
3
LISTA DE ILUSTRAÇÕES
FIGURA 1 - Ideia geral do trabalho proposto. ..........................................................14

FIGURA 2 - Abstração do encapsulamento de um caixa eletrônico .........................17
FIGURA 3 - Método sacar .........................................................................................18
FIGURA 4 - Diagrama UML de classes que (relacionamentos de herança).. ...........19
FIGURA 5 - Exemplo de polimorfismo .....................................................................20
FIGURA 6 - Exemplo de chamada de polimorfismo.................................................21
FIGURA 7 - Problemas de espalhamento e entrelaçamento causadas pela OO ........22
FIGURA 8 - Exemplo para demonstrar o entrelaçamento de código ........................23
FIGURA 9 - Manutenção transversais .......................................................................24
FIGURA 10 - Distribuição dos registros de log no Tomcat ......................................25
FIGURA 11 - Aplicação bancária com o método de transferência de valores ..........29
FIGURA 12 - Versão simplificada com novos objetivos (concerns) ........................29
FIGURA 13 - Código do negócio (sincronização de objetos concorrentes)..............31
FIGURA 14 - Combinação de um processo weaving ................................................32
FIGURA 15 - Relação entre Aspectos, components e pontos de junção ...................33
FIGURA 16 - Decomposição relacionado a separação de interesses ........................35
FIGURA 17 - Exemplo de mais de um ponto de junção para um ponto de função ..37
FIGURA 18 - Exemplo de advice do tipo around .....................................................38
FIGURA 19 - Exemplo de args .................................................................................39
FIGURA 20 - Implementação de ponto de corte .......................................................39
FIGURA 21 - Ponto de corte call ..............................................................................40
FIGURA 22 - Weaver fazendo a mesclagem dos módulos .......................................41
FIGURA 23 - Estratégia de Elicitação de Requisitos Não Funcionais ......................46
FIGURA 24 - Checklist de RNFs...............................................................................47
FIGURA 25 - Caso de Uso 03 ...................................................................................51
FIGURA 26 - Requisitos funcionais versus Casos de uso .........................................55
FIGURA 27 - RNF versus Casos de uso ....................................................................56
FIGURA 28 - Diagrama de classe .............................................................................57
FIGURA 29 - Diagrama de Atividade da Função Saque ...........................................58
FIGURA 30 - Diagrama de Sequência Função Saque ...............................................58
FIGURA 31 - Diagrama de Atividade da Função Depósito ......................................59
FIGURA 32 - Diagrama de Sequência da Função Depósito .....................................59
FIGURA 33 - Diagrama de Atividade Função Transferência ...................................60
FIGURA 34 - Diagrama de Sequência Função Transferência. ..................................60
FIGURA 35 - Diagrama de Atividade Consulta Extrato ...........................................61
FIGURA 36 - Diagrama de Sequência Consulta Extrato ..........................................61
FIGURA 37 - Interface Login ....................................................................................62
FIGURA 38 - Interface Operações ............................................................................63
4
FIGURA 39 - Interface Confirma Saque\Transferênci ..............................................63
FIGURA 40 - Interface Saque ....................................................................................64
FIGURA 41 - Interface Transferência .......................................................................64
FIGURA 42 - Interface Depósito ...............................................................................65
FIGURA 43 - Interface Extrato ..................................................................................65
FIGURA 44 - Estrutura do projeto.............................................................................69
FIGURA 45 - Classe Comuns ....................................................................................70
FIGURA 46 - Métodos classe Conta .........................................................................70
FIGURA 47 - Classe repositório ................................................................................71
FIGURA 48 - JSON e XML ......................................................................................72
FIGURA 49 - Classe Transações ...............................................................................73
FIGURA 50 - Classe static Static...............................................................................74
FIGURA 51 - Classe Traces ......................................................................................74
FIGURA 52 - Classe Program ...................................................................................74
FIGURA 53 - Método de validação de conta.............................................................75
FIGURA 54 - Método LoadAccount() (logout) .........................................................76
FIGURA 55 - Método LoadAccount() (SetDeposit) .................................................76
FIGURA 56 - Método LoadAccount() (SetTransfer) ................................................76
FIGURA 57 - 7Método LoadAccount() (GetBalance) ..............................................76
FIGURA 58 - Método LoadAccount() (SetWithdraw) ..............................................77
FIGURA 59 - Etapas de Desenvolvimento de Software Orientado a Aspectos ........78
FIGURA 60 - Estrutura de projeto com implementação de aspecto..........................79
FIGURA 61 - Biblioteca PostSharp ...........................................................................80
FIGURA 62 - Implementação aspecto de segurança .................................................81
FIGURA 63 - Aspecto Segurança ..............................................................................81
FIGURA 64 - Advice Log...........................................................................................82
FIGURA 65 - Advice Exception .................................................................................82
FIGURA 66 - Advice Security ....................................................................................83
FIGURA 67 - Exemplo de Pointcuts .........................................................................83
FIGURA 68 - Aspecto inserido no fluxo principal ....................................................84
FIGURA 69 - Tela de login do protótipo ...................................................................88
FIGURA 70 - Tela Operações Protótipo ....................................................................89
FIGURA 71 - Operação Saque Protótipo...................................................................89
FIGURA 72 - Operação Saque Protótipo...................................................................90
FIGURA 73 - Operação deposito Protótipo ...............................................................90
FIGURA 74 - Operação Transferência Protótipo ......................................................91
FIGURA 75 - Confirmação transferência Protótipo ..................................................91
FIGURA 76 - Operação extrato Protótipo .................................................................92
QUADRO 1 - Comparativo entre código espalhado e código emaranhado ..............25

QUADRO 2 - As três variações possíveis de advice after .........................................38
QUADRO 3 - Linguagens POA .................................................................................43
QUADRO 4 - Autenticação da conta .........................................................................52
QUADRO 5 - Efetuar Saque ......................................................................................52
QUADRO 6 - Efetuar Depósito .................................................................................52
5
QUADRO 7 - Efetuar Transferência ..........................................................................52
QUADRO 8 - Emitir Extrato ......................................................................................53
QUADRO 9 - Verificação de transferência ...............................................................53
QUADRO 10 - Validação de saldo para saque ..........................................................53
QUADRO 11 - Verificação de saldo para transferência ............................................54
QUADRO 12 - Validação de conta destino ...............................................................54
QUADRO 13 - Validação de valor para transferência ...............................................54
QUADRO 14 - Validação de saldo para saque ..........................................................54
QUADRO 15 - Validação de conta ............................................................................55
QUADRO 16 - Requisitos não funcionais .................................................................56
QUADRO 17 - Comparação entre a quantidade de linhas implementadas ...............86
6
LISTA DE ABREVIATURAS E SIGLAS
AJAX - Asynchronous Javascript and XML

DSOA - Desenvolvimento de Software Orientado a Aspectos
DSOO - Desenvolvimento de Software Orientado a Objetos
HTML - HyperText Markup Language
IA - Inteligência Artificial
JSON - JavaScript Object Notation
LAL - Léxico Ampliado da Linguagem
OA - Orientação a Aspecto
OO - Orientado a Objeto
POA - Programação Orientada a Aspecto
POO - Programação Orientada a Objeto
PU - Processo Unificado
RNF - Requisito Não Funcional
RUP - Rational Unified Process
SOAP - Simple Object Access Protocol
UdI - Universo de Informações
UML - Unified Modeling Language
XML - eXtensible Markup Language
XHTML - eXtensible Hypertext Markup Language
RESUMO
Durante anos, os engenheiros de softwares lutam quanto à estruturação de códigos, a

fim de maximizar sua reutilização e diminuir o risco de defeitos. Enquanto a
Programação Orientada a Objeto (POO) fornece uma estrutura sólida para a organização
de códigos, acaba apresentando dificuldades para reutilizar características transversais,
levando a duplicações desnecessárias de códigos e a um aumento de erros na fase de
produção, causando uma diminuição na qualidade e tempo de mercado. O trabalho
proposto tem por objetivo apresentar essa nova ideia de Programação Orientada a
Aspecto (POA) o qual seu objetivo se define em separar os níveis de preocupação
durante o desenvolvimento de software. A metodologia consistiu numa revisão
bibliográfica sobre o tema e a programação de um sistema com uso dos conceitos de
POO, onde constatou-se que é possível pensar separadamente nos problemas referentes
as camadas do sistema. Para facilitar o levantamento destas características transversais,
se torna viável basear-se pelos requisitos não funcionais, visto que os mesmos são de
impacto em várias camadas do sistema, pois tratam especificamente de particularidades
relacionadas ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade,
segurança, disponibilidade e manutenibilidade. A refatoração da POA é dividida em 3
fases sendo elas a decomposição, implementação e recomposição. Para demonstrar a
eficácia da POA, o trabalho consistiu no desenvolvimento de um sistema de caixa
eletrônico, o qual apresenta uma solução em POO, e sua refatoração em POA,
facilitando a identificação de pontos fortes na utilização desse novo conceito. Como
considerações destaca-se que a POA, não deve ser pensada como um novo padrão de
programação, e sim como um complemento para a POO, visto que trata de preocupações
diferentes, tendo como seu objetivo facilitar a reutilização de códigos, deixando assim
com uma estrutura de fácil manutenção, entendimento e com maior facilidade de
evolução devido sua facilidade de reutilização de códigos.
8
ABSTRACT
Over the years, software engineers struggle as the code structure in order to maximize
reuse and reduce the risk of defects. While the Object Oriented Programming (OOP)
provides a solid framework for the organization of code, just presenting difficulties to
reuse crosscutting, leading to unnecessary duplication of code and an increase of errors
in the production phase, causing a decrease in the quality and time to market. The
proposed work aims to present this new idea of Aspect Oriented Programming (AOP)
which your goal is defined in separating the levels of concern during the software
development. The methodology consisted of a literature review on the topic and
programming a system with use of the concepts of the POA. During the research, it was
found that it is possible to consider separately the problems related to the storage of data,
business modelling, security, distribution audit log records etc. To facilitate the lifting
of these crosscutting, it becomes feasible based on the non-functional requirements, as
they are impact in various system layers, as specifically deal with particulars related to
the use of the application in terms of performance, usability, reliability , security,
availability, maintainability, as well as the technologies involved. The POA is divided
into three phases and they decay, implementation and recovery. To demonstrate the
effectiveness of POA, work was the development of an ATM system, which presents a
solution in OOP, and a refactoring POA, facilitating the identification of the strengths
using this new concept. As considerations it is emphasized that the POA should not be
thought of as a new standard of programming, but as a complement to OOP, since
dealing with different concerns, having as its objective to facilitate the reuse of code,
leaving with a structure easy to maintain, and easier understanding of evolution due to
its ease of code reuse.
Keywords:
Aspecto, Programação Orientada a Aspecto, Requisitos Não Funcionais.
SUMÁRIO
1 INTRODUÇÃO ..........................................................................................................9
1.1 Apresentação .............................................................................................................9
1.2 Descrição do problema ............................................................................................10
1.3 Justificativa ..............................................................................................................11
1.4 Objetivo geral ..........................................................................................................12
1.5 Objetivos específicos ...............................................................................................12
1.6 Metodologia .............................................................................................................13
2 REVISÃO BIBLIOGRÁFICA ................................................................................14
2.1 Desenvolvimento de software. ................................................................................14
2.2 Programação Orientada a Objetos ...........................................................................15
2.2.1 Encapsulamento .............................................................................................................. 16
2.2.2 Herança ........................................................................................................................... 18
2.2.3 Polimorfismo ................................................................................................................... 19
2.3 Dificuldades encontradas na POO ...........................................................................21
2.3.1 Entrelaçamento do Código (Tangled Code).................................................................... 22
2.3.2 Espalhamento do Código (Scattering Code) ................................................................... 24
2.4 Programação Orientada a Aspectos .........................................................................26
2.4.1 Conceitos Fundamentais sobre a Programação Orientada a Aspectos.......................... 27
2.4.2 Motivação (Importância da POA) ................................................................................... 28
2.4.3 Sincronização de Objetos Concorrentes ......................................................................... 30
2.4.4 Conceitos e Terminologias .............................................................................................. 32
2.4.5 Problemas na utilização da POA .................................................................................... 41
2.4.6 Benefícios da Programação Orientada a Aspectos ......................................................... 42
2.4.7 Linguagens que implementam POA ................................................................................ 42
2.5 Requisitos do sistema ..............................................................................................43
2.5.1 Requisitos Funcionais ..................................................................................................... 44
2.5.2 Requisitos Não Funcionais .............................................................................................. 44
2.5.3 Estratégia para licitar Requisitos Não Funcionais ......................................................... 45
2.5.4 Como identificar requisitos não funcionais .................................................................... 46
2.6 Conclusões do capítulo. ...........................................................................................48
3 MODELAGEM DO SISTEMA...............................................................................49
3.1 Processo unificado: ..................................................................................................49
3.1.1 UML ................................................................................................................................. 49
3.1.2 Descrição do estudo de caso ........................................................................................... 50
3.2 Caso de uso ..............................................................................................................50
3.2.1 Diagrama de caso de uso ................................................................................................ 51
3.3 Levantamento de Requisitos....................................................................................51
3.3.1 Requisitos Funcionais ..................................................................................................... 52
3.3.2 Requisitos Não funcionais ............................................................................................... 55
3.4 Diagrama de classe ..................................................................................................56
3.5 Operações ................................................................................................................57
3.5.1 Função Saque: ................................................................................................................. 57
3.5.2 Função Depósito ............................................................................................................. 58
3.5.3 Função Transferência...................................................................................................... 59
3.5.4 Consulta Extrato .............................................................................................................. 61
3.6 Prototipação de interface .........................................................................................62
3.7 Considerações finais ................................................................................................65
4 DESENVOLVIMENTO...........................................................................................67
4.1 Tecnologias utilizadas .............................................................................................67
4.1.1 XML ................................................................................................................................. 67
4.1.2 JSON ................................................................................................................................ 68
4.1.3 PostSharp ........................................................................................................................ 68
4.2 Programação Orientada a Objetos ...........................................................................69
4.3 Programação Orientada a Aspectos .........................................................................77
4.4 Diferencial entre a programação orientada a aspecto sobre a orientada a objeto ...84
5 APRESENTAÇÃO DO SISTEMA .........................................................................88
6 CONCLUSÃO...........................................................................................................93
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................94
11
1 INTRODUÇÃO
1.1 Apresentação
A Programação Orientada a Objetos (POO) é o padrão mais utilizado entre a

comunidade científica, acadêmica e comercial. Sua estrutura é baseada na geração de
objetos, formando uma estrutura organizada que limita o uso, a inserção e a alteração
das informações contidas nesses objetos, devendo seguir suas regras de classe em que o
objeto esteja incluso.
De acordo com estudos realizados, pode-se afirmar que a POO foi o primeiro
método que permitiu a herança de atributos e objetos de classes ditas superclasses para
outras classes criadas que necessitam dessas operações, chamadas subclasses, o que
ajuda a reutilização de código. Além da herança, a POO permitiu o uso do polimorfismo
para permitir que funcionalidades sejam dinamicamente selecionadas durante a
execução dos programas.
Diante do exposto fica claro que a POO apresenta um grande papel no
processo de evolução no desenvolvimento de softwares, porém mesmo com todas as
funcionalidades exploradas, existem algumas dificuldades são existentes na formação
de uma aplicação, como o caso das características transversais, que conforme o próprio
nome diz, são métodos que atravessam toda a estrutura dos softwares, causando assim
um acúmulo de códigos duplicados, ilegibilidade, dificuldades e auto custo de
manutenção. Normalmente os interesses transversais estão associados a requisitos não
funcionais, onde estes resultam em um conjunto de aspectos (crosscutting, concerns)
relacionados às propriedades que afetam o comportamento do sistema. Com o uso da
abordagem, os requisitos não funcionais podem ser facilmente manipulados sem causar
9
impacto no código de negócio (requisitos funcionais), uma vez que estes códigos não
estão entrelaçados e espalhados em várias unidades do sistema. Desta forma, a
Programação Orientada a Aspecto (POA) possibilita o desenvolvimento de programas
utilizando tais aspectos, o que inclui isolamento, composição e reuso de códigos de
implementação dos aspectos.
A POA por ser um objeto de estudo recente, está sendo muito abordada por
engenheiros de software, pesquisadores e programadores interessados em utilizar essa
técnica que busca reduzir a complexidade e aumentar a produtividade no
desenvolvimento de software. A (OO) é um método eficaz até certo ponto, pois,
precisava de uma evolução que não foi obtida, o encapsulamento dos requisitos que
produzem efeitos em todo o sistema, não passou por revisões e adaptações profundas
nas suas descrições. Por isso, a Orientação a Aspectos (OA) ganhou força na
comunidade científica e tecnológica como a provável solução para essa brecha deixada
pela (OO), com certa eficácia na mudança de pensamento e do conhecimento na área de
desenvolvimento de sistemas. Muitas empresas têm incorporado rapidamente a OA por
não exigir nenhuma adaptação de seus equipamentos e ser de fácil compreensão aos
desenvolvedores e testadores de software.
O presente estudo contemplou os seguintes capítulos: Capítulo 1 foi
apresentado o projeto do trabalho, ou seja, definição do problema, justificativa, objetivos
e metodologia. O segundo capitulo se aprofundou no estudo de viabilidade através do
levantamento bibliográfico, abordando os temas referente aos paradigmas de
programação (OO) e (OA), e também formas de licitação de requisitos não funcionais.
No terceiro capítulo, foi apresentado a modelagem do sistema. No quarto capitulo foi
realizado o desenvolvimento de um sistema (OO), refatorando em uma solução (OA),
apresentando com tudo um comparativo com as devidas vantagens e desvantagens
existentes na (POA) sobre a (POO). O quinto capítulo tratou-se de uma apresentação do
sistema com suas formas de utilização e no capítulo final apresentou-se a conclusão
geral do trabalho.
1.2 Descrição do problema
10
Nos dias atuais existe uma grande dificuldade no controle de características
transversais o que acaba deixando um emaranhado de código espalhado por todo o
sistema, tornando cada vez mais difícil de controlar, modificar e reutilizar estas
características em comum, aumentando assim o custo de seu desenvolvimento. Neste
caso, será que com o uso da (POA) será possível resolver as dificuldades levantadas?
1.3 Justificativa
Durante anos, os engenheiros de softwares lutam quanto à estruturação de

códigos, a fim de maximizar sua reutilização e diminuir o risco de defeitos de um
sistema. Enquanto a POO fornece uma estrutura sólida para a organização de códigos,
acaba apresentando dificuldades para reutilizar características transversais, levando a
duplicações desnecessárias de códigos, e aumentando os erros na fase de produção,
causando uma diminuição na qualidade do produto, com perda de atuação no mercado.
O modelo utilizado na POO para a formação de classes acaba não se
preocupando com estas características transversais, deixando o código com uma
estrutura difícil ou até mesmo impossível de se realizar uma centralização de código em
um único lugar de forma efetiva. Esse formato de desenvolvimento resulta em
problemas associados a uma fraca separação de interesses, impactando em uma
evolução cara e difícil com baixo reuso, além de integração complicada e software muito
sensível a alterações de características por conta da rastreabilidade dos impactos.
A programação Orientada a Aspecto tem este objetivo, tentar separar os níveis

de preocupação durante o desenvolvimento de software. Logo seria possível
pensar separadamente nos problemas referentes à persistência dos dados,
modelagem de negócios, segurança, distribuição auditoria, registros de logs
etc. A proposta é poder desenvolver as partes do sistema sem se preocupar
com as demais partes. A cada iteração da integração insere-se um novo nível
de preocupação sem ser necessário alterar o que já esta pronto. (KICZALES
et al. 1997, P. 12).
Desta forma este TCC visa utilizar a POA para mostrar a separação dessas
funcionalidades ortogonais através da geração de aspectos. Será comparado a construção
de um sistema sem a valorização destes artefatos versus um sistema preocupado com as
11
características transversais, partindo da modelagem do sistema até a formação de
aspectos, tornando assim, um sistema com código mais legível e de fácil manutenção,
trazendo como benefício um aumento na produtividade em relação a reutilização de
classe, e com um processo mais eficiente para a formação de novos softwares.
Como os aspectos têm a propriedade de permitir a alteração do funcionamento

do software de maneira não invasiva, espera-se conseguir uma abordagem que
faça com que a linha de produtos de software possa crescer incrementalmente
com o tempo. Essa seria uma grande vantagem para as linhas de produtos, já
que uma das preocupações e desvantagens no seu desenvolvimento é o alto
esforço inicial de trabalho investido (PACIOS, 2006, p. 3).
A POA é um paradigma de programação relativamente novo e significativo

para a comunidade de software, o qual surgiu para complemento do paradigma da POO.
Como já dito, a POO apresenta dificuldades na separação de interesses em algumas
circunstâncias como por exemplo, os requisitos não funcionais (KICZALES et al.,
1997). A principal função da POA é identificar os interesses transversais e em que ponto
do código eles serão utilizados, normalmente os interesses transversais estão associados
a requisitos não funcionais. Tentar focar nas soluções que a POA traz para colocar na
justificativa (GROVES, 2013).
Por ser uma abordagem incremental, reduz-se a carga de trabalho necessária

no início da produção da linha de produtos. Isso é conseguido graças à
utilização de aspectos. Com isso, tem-se as vantagens de linhas de produtos
ao mesmo tempo amenizando a desvantagem do risco do alto investimento
inicial não ter o retorno esperado (PACIOS, 2006, p. VII).
1.4 Objetivo geral
Realizar um estudo para demonstrar as vantagens inerentes na (POA), levando

em consideração os requisitos não funcionais para geração dos aspectos.
1.5 Objetivos específicos
a) Realizar um estudo de conceito sobre a POA;
12
b) Estudar as abordagens utilizadas para estender a modelagem de requisitos
para tratar de interesses transversais para o desenvolvimento de aspectos;
c) Demonstrar com um exemplo a metodologia POO;
d) Refatorar o exemplo utilizando o contexto de aspectos para demonstrar
suas vantagens.
1.6 Metodologia
A primeira parte do trabalho consistiu no pré projeto, onde foi realizado um

levantamento bibliográfico através de livros e materiais disponíveis na Internet quanto
a viabilidade da utilização da (POA) para o desenvolvimento de um sistema,
identificando qual a sua importância, diferencial e sua aplicabilidade. Após foi descrito
um levantamento teórico embasado nos estudos realizados no levantamento
bibliográfico, seguindo para uma terceira parte o qual foi verificado como modelar a
aplicação e realizar a separação de interesses através da divisão dos requisitos não
funcionais, a fim de alcançar o nível de abstração de dados para formação dos aspectos.
Na quarta etapa foi desenvolvido um exemplo utilizando o paradigma (OO),
para que esse exemplo seja transformando em uma solução orientada a aspecto,
apresentando então seu diferencia, vantagens e desvantagens da (POA) sobre a (POO).
Na sequência, foi apresentado o modo de operação do sistema proposto,
finalizando com o próximo capitulo o qual expos uma conclusão do trabalho.
13
2 REVISÃO BIBLIOGRÁFICA
A Figura 1 apresenta um esboço quanto a estruturação desse trabalho, Onde

Durante o próximo capítulo será iniciado a contextualização das tecnologias abrangidas
nesta proposta, iniciando com uma retrospectiva quanto ao desenvolvimento de
softwares, sua evolução até a chegada da revolucionaria POO, seu diferencial, vantagens
e dificuldades encontradas. Explicará o surgimento da Programação Orientada a
Aspecto, vantagens, motivações, e conceitos necessários para o entendimento dessa
tecnologia complementar a POO, assim como as desvantagens em sua utilização.
FIGURA 1 - Ideia geral do trabalho proposto.
(FONTE: Próprio Autor, 2015)

Como para iniciar uma aplicação orientada a aspecto é necessário inicia-la
durante a fase de modelagem do sistema, também iremos fundamentar e trabalhar a
licitação de requisitos não funcionais ligados indiretamente com a programação
orientada a aspecto para facilitar na refatoração do sistema desenvolvido inicialmente
orientado a objeto, cessando objetivo final desse capítulo.
2.1 Desenvolvimento de software.
14
Ao longo dos últimos anos a Engenharia de Software disponibilizou vários
métodos, técnicas e ferramentas para auxiliar os desenvolvedores de software a
produzirem com maior qualidade. Outas características foram perseguidas, sendo talvez
as mais importantes para a produtividade, a reusabilidade e manutenibilidade.
(GROVES, 2013).
No desenvolvimento estruturado, a separação de interesses ocorre através das
diferentes funcionalidades oferecidas pelo software. Cada função é implementada em
um único módulo, ou procedimento. Neste paradigma de desenvolvimento, apesar dos
interesses relativos a funcionalidades ficarem separados, interesses relativos a dados
ficam distribuídos em um único módulo.
Em engenharia de software, o princípio da separação de características está
relacionado à decomposição e modularização (PARNAS, 1972). Para garantir este
princípio, durante o desenvolvimento, deve-se usar a decomposição em unidades
menores, cada uma abordando uma única característica, diminuindo a complexidade
com código modular, onde o relacionamento mútuo desses módulos formará um
sistema.
Com o desenvolvimento de aplicações complexas, cresceram as demandas por
metodologias que possam abstrair e modularizar as estruturas básicas de um programa,
surgindo assim o conceito em desenvolvimento de softwares chamado de POO.
2.2 Programação Orientada a Objetos
Com o Advento da POO houve um ganho na organização dos sistemas. O

mundo passou a ser modelado na forma de classes de objetos, e como tal, as classes de
objetos puderam ser reutilizadas com maior facilidade (GROVES, 2013).
Para trabalhar com a POO se faz necessário compreender a utilização de
objetos para melhor elaborar uma aplicação, sendo ele um elemento que representa no
domínio da solução, alguma entidade (abstrata ou concreta) do domínio de interesse do
problema sob análise. Objetos similares são agrupados em classes e, um objeto não é
muito diferente de uma variável normal (RICARTE, 2001).
15
As classes são consideradas como um identificador para que posteriormente
sejam referenciadas no momento da criação de um Objeto. Dentro destas classes, tem-
se os métodos, os quais definem funções existentes dentro das classes.
O autor (RICARTE, 2001) também descreve que os métodos definem as
funcionalidades da classe, ou seja, o que será possível fazer com os objetos dessa classe.
Cada método é especificado por uma assinatura, composta por um identificador (o nome
do método), o tipo para o valor de retorno e uma lista de argumentos, sendo cada
argumento identificado por seu tipo e nome.
A POO trouxe uma nova perspectiva de modelagem de dados, auxiliando o
desenvolvedor com métodos fáceis para garantir uma maior desenvoltura durante o
desenvolvimento de sistemas. Dentre as grandes vantagens podem ser citadas três, sendo
elas: (encapsulamento, herança e polimorfismo) que nasceram com o paradigma,
diferenciando de qualquer outra programação utilizada anteriormente.
2.2.1 Encapsulamento
O encapsulamento consiste em definir o que os outros objetos poderão acessar,

sendo implementado através do uso das palavras reservadas public, private e protected.
Existem algumas situações em que o encapsulamento se faz absolutamente
indispensável. Um exemplo, seria o caso relacionado a um caixa eletrônico. A
quantidade de pessoas que conhecem o funcionamento de um caixa eletrônico é mínima.
Isso é verdade por duas razões: primeiramente, algumas pessoas necessitam saber como
o caixa funciona para realizar manutenções, para os usuários, não há nenhuma
necessidade em saber como funciona um caixa eletrônico “por dentro” (SERSON,
2007). A Figura 2 apresenta uma abstração de um caixa eletrônica com e sem
encapsulamento.
16
FIGURA 2 - Abstração do encapsulamento de um caixa eletrônico
(FONTE: SERSON, 2007)
Na Figura 2, o caixa eletrônico encapsulado é como se fosse um cofre. Para

um usuário, não há a necessidade de saber o que há por dentro do caixa eletrônico.
O encapsulamento é o mecanismo a partir do qual os detalhes da
implementação dos métodos de uma classe são ocultados para usuários da classe. Isso é
conquistado mantendo-se atributos private e disponibilizando os dados para
visualização por meio de métodos get e permitindo que os dados sejam alterados
somente por métodos set.
Através destes métodos criados para acessar as variáveis implementadas,
obtém-se questões de segurança para acesso as classes, onde as variáveis “private” só
podem ser acessadas dentro da própria classe. É como se elas fossem invisíveis para o
escopo de outras classes. Assim, evita-se que outros métodos, classes ou até mesmo
hackers tenham acesso aos dados de determinada classe, que muitas vezes podem ser
dados privados, como é o caso de aplicações para empresas e bancos.
Ainda no exemplo do caixa eletrônico citado acima, supondo que seja
necessário criar uma aplicação para um banco, onde deve ser limitado o número de
saques de um cliente. Os valores do saldo desse cliente ficarão armazenados na variável
“saldo”. Se tiver acesso total a essa variável, o cliente poderia usar de forma
descontrolada os serviços do banco.
Porém, pode-se criar um método em que, cada vez que o cliente saque dinheiro
ele ative um contador, conforme mostra o código da Figura 3.
17
FIGURA 3 - Método sacar
No trecho do código acima, quando o usuário tenta sacar, através do menu do

caixa eletrônico, seguirá para o método “setSaque()”. Então cada vez em que o cliente
sacar, seu saldo irá diminuir em “valor” e um contador (que é uma variável de classe),
é incrementado para controle de limite de saque diário.
O método get não foi ilustrado, mas serve para obter a informação do saldo, e
esse tipo de método sempre retornará um valor, já o método set é utilizado para definição
do valore do saque.
2.2.2 Herança
O mecanismo de herança no paradigma é um dos seus grandes trunfos. Este

permite poupar tempo quando se trata de criar classes que são similares a outras. De
uma forma simples, herança é o mecanismo que faz com que uma nova classe herde da
classe mãe (ou superclasse) atributos e métodos em comum.
Cada classe existente é chamada de superclasse e a classe nova é chamada de
subclasse. Cada subclasse pode se tornar superclasse para futuras subclasses. Uma
subclasse, usualmente, adiciona seus próprios campos e métodos. Dessa forma, uma
subclasse é mais específica que sua superclasse, além de representar um grupo mais
especializado de objetos. Normalmente a subclasse exibe os comportamentos de sua
superclasse e comportamentos adicionais específicos. A superclasse direta é a
superclasse a partir da qual a subclasse herda diretamente (SERSON, 2007).
A Figura 4 demonstra os conceitos de superclasses direta e indireta. A classe
Manager é superclasse direta da classe Employee. A classe Director é superclasse direta
da classe Manager e a classe Director é superclasse indireta da classe Employee.
18
FIGURA 4 - Diagrama UML de classes que representam relacionamentos de herança.
Ainda de acordo com (SERSON, 2007), uma herança significa especialização.

Uma subclasse se especializa ao herdar todos os atributos e métodos de sua superclasse
e adicionar outros. Os atributos e métodos adicionais tornam a subclasse mais restritiva
ou, em outras palavras, mais especial.
2.2.3 Polimorfismo
Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma

mesma superclasse podem invocar métodos que têm a mesma identificação (assinatura),
mas, com comportamentos distintos, especializados para cada classe derivada, usando
para tanto uma referência a um objeto do tipo da superclasse. Esse mecanismo é
fundamental na POO, permitindo definir funcionalidades que operem genericamente
com objetos, abstraindo-se de seus detalhes particulares quando esses não forem
necessários.
19
Através deste fundamento de polimorfismo, segundo (SERSON, 2007), a
extensibilidade é promovida pelo polimorfismo a partir do momento em que ele permite
unificar o processamento de objetos relacionados por herança ou por implementação de
interfaces. Do ponto de vista arquitetural, novas classes podem ser adicionadas que o
processamento polimórfico permanecerá imutável.
Sem meios apropriados para sua separação em um sistema OO, os interesses
transversais tendem a ficar espalhados e entrelaçados com outros interesses. Um
interesse é dito espalhado quando afeta vários componentes do sistema e entrelaçado
quando se mistura com outros interesses dentro de um mesmo módulo. Estas duas
características são indesejáveis porque causam uma maior dificuldade de entendimento,
evolução e reutilização dos artefatos de software (GARCIA et Al., 2004).
Com o polimorfismo, os mesmos atributos e objetos podem ser utilizados em
objetos distintos, porém com implementações lógicas diferentes. Por exemplo, tem-se
uma classe Animal e nela sabe-se que todo animal come, sendo que Cães comem ração
e Tigres comem carne. Dentre os métodos de chamadas existentes, pode-se ter os
comportamentos citados, na Figura 5.
FIGURA 5 - Exemplo de polimorfismo
Para utilizar o método polimórfico, tem-se o exemplo, ilustrado na Figura 6.
20
FIGURA 6 - Exemplo de chamada de polimorfismo
Nota-se então, que cada chamada irá fazer algo diferente, porém como existe
herança entre as classes, todos os métodos irão funcionar, porque são do tipo mais
genérico (Animal) ou são filhos do mais genérico.
Através destas 3 fundamentações, tem-se ainda algumas dificuldades
encontradas nas implementações da POO, tais quais serão abordadas no próximo tópico.
2.3 Dificuldades encontradas na POO
Conforme apresentado nas seções anteriores, a POO trouxe algumas

contribuições importantes para o desenvolvimento de sistemas no que se refere a
facilidade de manutenção e reutilização de código. Contudo, existem alguns problemas,
tal como espalhamento e entrelaçamento de dados, que a técnica OO. Sozinha é incapaz
de lidar. Os mesmos serão abordados a seguir.
A Figura 7 (CHAVEZ, 2004) ilustra os problemas de espalhamento e
entrelaçamento causados pelas abordagens estruturadas e orientada a objetos. Sendo que
na Figura 7(a), o mesmo dado pode ser utilizado em diferentes funções (procedimentos),
e cada função trata de diferentes dados. Na Figura 7(b) o mesmo comportamento
(método) é desempenhado em diferentes componentes e cada componente desempenha
comportamentos diferentes.
21
FIGURA 7 - Problemas de espalhamento e entrelaçamento causadas pela OO
(FONTE: CHAVEZ, 2004)
Esses dois problemas expostos, evidenciam a dificuldade nos processos de

manutenção e reuso do código. E a grande evidência dos problemas na OO é o
surgimento da POA, que apresenta soluções de uma forma simplória e eficiente aos
olhos dos programadores.
Antes de aprofundar os estudos na POA, deve-se analisar então com muita
cautela alguns problemas relacionados a POO.
2.3.1 Entrelaçamento do Código (Tangled Code)
Para o DSOO (Desenvolvimento de Software Orientado a Objetos), o mundo

é representado através de objetos e classes. Para o correto funcionamento, um sistema
necessita de atributos e métodos para compor as classes que irão representar uma
entidade do mundo real. Durante o processo de integração dos componentes ao software
final, ocorre o fenômeno conhecido como entrelaçamento do código. “Quando o
trabalho de preenchimento dos métodos se inicia, faz-se necessário inserir chamadas de
responsabilidade de uma classe em outra. Estas linhas de código inseridas em outro
componente para integração são denominadas código intrusivo ou invasivo.”
(RESENDE; SILVA, 2005 p.179).
22
FIGURA 8 - Exemplo para demonstrar o entrelaçamento de código
(FONTE: RESENDE; SILVA, 2005)
Nas linhas 34 e 36 por exemplo, ocorrem duas chamadas intrusivas,

Banco.conectar() e Banco.fechar(). Isso também poderia ocorrer com tratamento de
exceções, registros de logs, persistência de dados, etc. Assim, a lógica do sistema fica
“embaralhada”, portanto, assuntos que deveriam ser tratados somente em suas classes
de origem estão sendo tratadas em outras classes.
Os autores (RESENDE; SILVA, 2005) expõem ainda mais dois possíveis
problemas gerados pelas chamadas invasivas:
 Dificuldade em saber exatamente o que ocorre com uma classe ao ler o
seu código, pois as chamadas referentes ao entrelaçamento estão fora
da mesma;
 Comportamento emergente. Alguns pesquisadores da área de IA
(Inteligência Artificial) levantaram a hipótese de que a inserção de
chamadas a métodos em componentes que foram concebidos sem
23
pensar em tal interação poderia apresentar um novo comportamento.
Esta especulação advém da teoria de IA sobre a interação de agentes
inteligentes, que, através de sinergia da cooperação entre eles, um novo
comportamento pode surgir.
2.3.2 Espalhamento do Código (Scattering Code)
Ainda com o problema de ter classes inchadas com códigos invasivos tratando
aspectos não pertinentes a seus objetos, tem-se o problema de repetição destes códigos.
Analisando o exemplo anterior das classes Banco e Questão (Figura 8) e
supondo que aquelas mesmas chamadas intrusivas fossem feitas por outras classes, caso
fosse necessário alterar o nome do método conectar() da classe Banco para
abrirConexao(), seria necessária a alteração de todas as chamadas a esse método em todo
o sistema. Isso causaria sérios problemas de manutenibilidade e produtividade.
Por exemplo, analisando a Figura 9(a) abaixo, é possível notar que o método
conectar() se faz presente em diversas classes, podendo esses estarem espalhados em
diversas partes de um programa. A manutenção para uma alteração desse método
impactara em todas as classes que fazem uso deste. A Figura 9(b) representa a alteração
desses métodos.
FIGURA 9 - Manutenção transversais
24
Abaixo é apresentado outro exemplo o qual é possível a visualização desse
problema, a Figura 10 mostra a quantidade de registros de logs no servlet container
Tomcat. As barras verticais são as classes e as linhas horizontais representam o
espelhamento obtido pelas chamadas para registros de logs.
FIGURA 10 - Distribuição dos registros de log no Tomcat
Agora analisando o exemplo acima, imaginando que a pessoa responsável pela

manutenabilidade do sistema não se faz mais presente, e existe a necessidade de uma
alteração envolvendo uma Feature que se relaciona com duas ou mais classes, o quão
grande será o impacto dessa manutenção?
O Quadro 1 se refere a um resumo das principais características de códigos
espalhados e códigos entrelaçados, também conhecido como códigos emaranhados.
QUADRO 1 - Comparativo entre código espalhado e código emaranhado

Termo Original Tradução Descrição
Código necessário para cumprir um interesse
propagado em classes que precisam cumprir
interesses.
Scattering Code Código espalhado
O Código espalhado pode ser dividido em duas
categorias distintas: Bloco de Código Duplicado e
Bloco de Código Complementar.
Tangled Code Código emaranhado Utilização de uma única classe ou método para
implementar múltiplos interesses.
25
O código emaranhado ocorre quando um módulo é
implementado com múltiplos interesses
simultaneamente. Um desenvolvedor
frequentemente considera os interesses como
lógica do negócio, performance, sincronização,
segurança, dentre outros, durante a
implementação do módulo. Isso resulta na
implementação de vários interesses em um mesmo
módulo.
2.4 Programação Orientada a Aspectos
Pode-se dizer que a POA é um novo conceito, devido ser alvo de estudo na
esfera acadêmica e principalmente por ser de interesse dos arquitetos de softwares que
buscam diariamente metodologias ágeis e de fácil compreensão, apresentando um
retorno positivo para a equipe durante o processo de desenvolvimento.
Em 1997 Kiczales líder da empresa Xerox, coordenava uma equipe de
pesquisados, que primeiro descreveu a POA em 1997. Ele e sua equipe estavam
preocupados com o uso de repetições “clichê” que eram muitas vezes necessárias e se
tornavam “caras” pela utilização em diversos blocos de códigos orientados a objetos.
São citados como exemplos destas características, o controle de log, cache, transação,
persistência, entre outros.
O autor Kiczales (1997) e sua equipe descrevem os problemas que POO foi
incapaz de capturar e resolver de uma forma clara. Eles observaram que essas
preocupações transversais acabaram sendo espalhadas por todo o código, deixando este
com um emaranhado de código, se tornando cada vez mais difícil de desenvolver e
modificar. Eles analisaram todas as razões entre as técnicas utilizadas para identificar o
motivo de se apresentar este descontrole, resultando neste “emaranhamento”.
A POA complementa a POO, fornecendo outra maneira de pensar sobre a
estrutura do programa. A unidade fundamental da modularidade em POO é a classe,
enquanto que em POA a unidade de modularidade é o aspecto. Aspectos permitem a
modularização de preocupações, tais como gerenciamento de transações que atravessam
vários tipos e objetos.
26
O principal objetivo da POA é separar o código referente ao negócio dos
códigos transversais, uma divisão de interesses (requisitos), abrangendo o problema de
legibilidade como a questão da modularidade. Esses interesses transversais são
divididos em aspectos mantendo o código referente ao negócio como fluxo principal da
aplicação e sem qualquer alteração.
2.4.1 Conceitos Fundamentais sobre a Programação Orientada a Aspectos
Um aspecto é o elemento básico de encapsulamento dos outros elementos que

dão suporte ao uso da POA, os quais são os pontos de corte, os adendos e as declarações
inter-tipos que são os atributos, os métodos e as classes internas, que podem alterar a
estrutura estática (static crosscutting), adicionando membros a uma classe; e dinâmica,
interceptando pontos de junção e da adição de comportamento antes e depois desses
pontos de junção ou ainda por meio da obtenção de total controle sobre o ponto de
execução, de um programa, mudando a hierarquia do sistema, conforme (SOARES e
BORBA, 2002).
Seguindo com o conceito de POA, os recursos que permeiam várias classes de
um sistema, vinculando mesmo aquelas que implementam regras conceitualmente
distantes, são chamados de cross-cutting. São exemplo desses recursos; criação de logs
de operações, auditoria em alteração de dados, níveis de permissão de acesso a dados,
autorização para executar operações, tratamento de exceções, etc. Para melhorar a
solução para esses tipos de recursos foi proposta POA, onde o código que implementa
os recursos cross-cutting são retirados das classes de negócio e inseridos em métodos
próprios.
A POA depende ainda de um mecanismo que permita vincular a execução dos
códigos do aspecto à execução das regras de negócio. A solução proposta pela POA é
centrada no modelo de pontos de ligação (Join Points).
O modelo de pontos de ligação é definido por três características: o momento
em que o código poderá ser executado, chamado de Join point, uma forma de especificar
esses modelos e uma forma de especificar o código que deve ser executado em cada
momento.
27
Um ponto de ligação pode ser encarado como um evento que ocorre no código
da regra de negócio, marcado pela execução de um determinado método ou pela
alteração no valor de uma propriedade. Criar pontos de ligação significa indicar quais
desses eventos devem ser monitorados pelo aspecto, usando para isso estruturas
chamadas de pointscuts. Os pointscuts se valem de uma sintaxe especial para possibilitar
a indicação de quais métodos e propriedades dispararão a execução do código relativo a
um ponto de ligação (FABBRO, 2011).
O autor (GROVES, 2013) exemplifica uma característica transversal através
do seguinte contexto: considere um método que faz X. Se realizado um logging de
performance (C) nesse método X, caso exista outros métodos Y e Z que necessitem
desse controle de performance, será necessário colocar C em cada um desses métodos
também. Sendo assim, “C” é a preocupação transversal. Embora a preocupação
transversal seja um termo conceitual “cross-cutting” que é definido por uma ou duas
sentenças, que resulta em um código “concreto” funcional.
Enfim, a POA é uma tecnologia de programação em nítida evolução que
oferece suporte a novos mecanismos e recursos de abstração e composição com o
objetivo de permitir alcançar uma melhor separação de interesses no nível da
implementação. A POA é evolucionária porque considera atribuições reconhecidas da
separação de interesses proporcionadas por tecnologias anteriores.
2.4.2 Motivação (Importância da POA)
Conforme cita o autor (KICZALES, 1997), a POA tem como objetivo a

separação do código segundo a sua importância para a aplicação, permitindo que o
programador encapsule o código secundário em módulos separados do restante da
aplicação.
Por exemplo, considera-se que uma aplicação bancária simplesmente transfere
um valor de uma conta para outra, conforme ilustra a Figura 11.
28
FIGURA 11 - Aplicação bancária com o método de transferência de valores
(FONTE: KICZALES, 1997)
Porém, numa aplicação bancária construída para o mundo real, este método de
transferência está longe do adequado. É necessário incluir valores de segurança, que
determinam se o usuário possui autorização para realizar a operação. É preciso também
“envolver” a operação em uma transação para prevenir perda de dados. Finalmente, é
preciso fazer o log dos dados da aplicação. Uma versão simplificada que contém estes
novos objetos (concerns) está ilustrada na Figura 12.
FIGURA 12 - Versão simplificada com novos objetivos (concerns)
(FONTE: KICZALES, 1997)
Comparando com a primeira versão, o código perdeu a sua elegância e

simplicidade, depois que o código foi voltado para outros objetivos “misturado” com
29
aquele que implementa as regras do negócio.
Deve-se considerar o que ocorre quando é necessário alterar, por exemplo, a
implementação de segurança da aplicação. No exemplo mostrado, o código é espalhado
por vários métodos, e qualquer mudança significa um grande esforço de codificação.
Por fim, pode-se dizer que este código não está devidamente encapsulado nos
seus próprios módulos. Isto aumenta a complexidade do sistema e torna a manutenção
do mesmo muito difícil.
A POA então, busca resolver este problema permitindo que o programador
implemente essas questões (segurança, log, transações, e etc.) através de aspectos. Em
muitas linguagens que implementam POA, o aspecto é constituído de uma ou mais peças
de advices (fragmentos do código, como métodos) e uma lista de join points (pontos no
programa principal na qual os advices são inseridos).
2.4.3 Sincronização de Objetos Concorrentes
Um programa em que dados os globais sejam compartilhados, necessita

sincronizar suas atividades através de mecanismos que possibilitem sua execução. Um
exemplo de política de sincronização seria que todos os objetos podem realizar
operações de leitura em um determinado objeto, se ele não estiver sendo modificado,
mas, somente um deles pode realizar uma operação de escrita por vez (CAHILL &
DEMPSEY, 1997).
Logo, existem diversos benefícios em se possuir uma propriedade importante
de um sistema expressa de maneira bem localizada em uma única unidade ou seção de
código. A partir desta separação, pode-se entender com maior facilidade como esta age
no sistema como um todo, já que não é necessário procurá-la em diferentes lugares
separá-la de outras propriedades. Ainda, é possível analisá-la, modificá-la, estendê-la e
reusá-la mais facilmente (CZARNECKI & EISENECKER, 2000).
Para (GROVES, 2013) quando preocupações transversais são codificadas sem
POA, os códigos muitas vezes passam por dentro de um método sendo misturados
logicamente, perdendo toda a regra de negócio. Essa abordagem é conhecida como
tangling.
30
Quando a preocupação do código transversal é utilizada em vários métodos e
várias classes (usando o copiar e colar, por exemplo), esta abordagem é chamada de
scattering (dispersão) por que o código fica espalhado em toda a aplicação.
Na Figura 13, tem-se o código de lógica de negócio em verde, e o código de
registro em vermelho.
FIGURA 13 - Exemplo de código do negócio relacionado a sincronização de objetos

concorrentes
(FONTE: GROVES, 2013)
A preocupação do código transversal está nas mesmas classes como ocorre na

lógica de negócio. Quando é refatorado utilizando POA, todo o código em vermelho é
movido para uma nova classe, e tudo o que permanece na classe original é o código em
verde que executa a lógica de negócios. Então, é necessário informar a ferramenta de
POA para aplicar o aspecto (classe vermelho) para a classe de negócio (classe verde),
especificando um pointcut. A ferramenta de POA executa este passo de combinação
com um processo chamado de (weaving), conforme esboça a Figura 14.
Na Figura 13, o código combinado parece com o código original, misturando
verde e vermelho em uma classe. Não terá nada do código combinado em seus arquivos
de código fonte. O código terá as classes que está trabalhando, terá uma separação
31
organizada se mantendo agradável para o desenvolvimento, de maneira que as
ferramentas de POA realizarão o processo de “tecelagem” de acordo com ferramenta
utilizada.
FIGURA 14 - Combinação de um processo weaving
(FONTE: GROVES, 2013)
2.4.4 Conceitos e Terminologias
Antes de apresentar as propostas referentes à modelagem orientada a aspectos,

é conveniente fazer uma rápida revisão dos conceitos relacionados a esse tipo de
programação, principalmente do ponto de vista da linguagem AspectJ, a implementação
mais popular.
O mecanismo mais utilizado em (DSOA) Desenvolvimento de Software
Orientado a Aspectos para a implementação de aspectos é o uso de advices, trechos de
códigos que devem ser inseridos ou substituir trechos na estrutura ou execução de
componentes, e Join points, trechos identificáveis dentro da execução de um
componente, onde os advices podem ser inseridos (KICZALES, 1997). Esses
32
mecanismos podem ser utilizados de forma dynamic crosscuting, para a modificação da
execução dos componentes, executando advices antes ou depois de métodos do
componente, substituindo parâmetros, ou mesmo trocando a execução de um método do
componente por um advice do aspecto. Ou podem ser usados de forma statis
crosscuting, alterando a própria estrutura dos componentes: adicionando métodos e
propriedades, ou modificando a hierarquia de classes, conforme detalha a Figura 15.
FIGURA 15 - Relação entre Aspectos, components e pontos de junção
(FONTE: BARDOU, 1998)
Por ser uma área relativamente nova na computação, ainda não existe uma
tradução usual para muitos termos utilizados na literatura a respeito de POA sendo
assim, esse trabalho irá dar enfoque em apenas algumas terminologias, como por
exemplo: Separation of concern; Aspect; Join Point; Advices; Introduction e Weaving.
2.4.4.1 Separação de Interesses
O termo separação de interesses foi cunhado por (DIJKSTRA, 1976) para

denotar o princípio que guia a visão em partes: todo sistema de software lida com
diferentes interesses, sejam eles dados, operações, ou outros requisitos do sistema.
Segundo o autor (LADDAD, 2009), o ideal seria que a parte do programa dedicada a
33
satisfazer a um determinado interesse estivesse concentrada em uma única localidade
física, separada de outros interesses, para que o interesse possa ser estudado e
compreendido com facilidade.
Tem-se em consideração uma boa prática de desenvolvimento de sistemas,
onde a decomposição de um sistema através da divisão de interesses permite-se um
melhor nível de abstração dos dados, diminuindo assim a complexidade das
características individuais, permitindo assim que o desenvolvedor mantenha o foco
especificamente no que for de interesse aumentando o processo de evolução de
desenvolvimento.
A ideia central por trás da orientação a aspectos é que os mecanismos de
abstração e composição das tecnologias existentes não são suficientes para separar
alguns interesses especiais encontrados em sistemas mais complexos. Esses interesses
são chamados de interesses transversais (crosscutting concerns) uma vez que afetam a
modularidade de outros elementos (chamados de componentes), “atravessando” seus
limites. Sem os meios apropriados para a separação e a modularização, interesses
transversais tendem a ficar espalhados e entrelaçados com outros interesses. As
consequências naturais são uma menor compreensibilidade, uma menor evolução e uma
menor reutilização dos artefatos do código. A orientação a aspectos utiliza o aspecto
como um novo mecanismo de modularização para a separação de interesses transversais
e fornece um novo mecanismo para combinar aspectos em componentes em pontos de
combinação bem definidos (RESENDE; SILVA, 2005).
O desenvolvimento estruturado realizou a separação de interesses orientando-
se através das diferentes funcionalidades oferecidas pelo software. Cada função é
implementada em um único módulo, ou procedimento. Daí surgiram conceitos que
ajudam a manter a separação de interesses, como o baixo acoplamento e a alta coesão.
O objetivo do desenvolvimento orientado a aspectos é encapsular interesses
transversais em aspectos fisicamente separados do restante do código. Em termos
abstratos, a orientação a aspectos introduz uma terceira dimensão de decomposição,
conforme ilustra a Figura 16. Além de decompor o sistema em objetos (dados) e métodos
(funções), é então transformado cada objeto e função de acordo com o interesse sendo
34
servido e agrupados a cada interesse em um módulo distinto, ou aspecto.
FIGURA 16 - Exemplo 3D de decomposição relacionado a separação de interesses
(FONTE: NELSON, 2005)
2.4.4.2 Aspectos
Aspectos são definidos como propriedades de sistemas que afetam

componentes e, mais especificamente, como propriedades que afetam o desempenho ou
a semântica de componentes de forma sistêmica (KICZALES, 1997). Para estabelecer
uma terminologia independente de linguagem, usa-se o termo característica transversal
(crosscutting feature) a fim de denotar qualquer melhoria comportamental ou estrutural
especificada dentro do aspecto para afetar um ou mais componentes nos pontos de
combinação especificados, e o termo interface transversal (crosscutting interface) para
denotar o conjunto de pontos de combinação especificados dentro do aspecto
(LAMPING, 1999).
As interfaces transversais incorporam especificações de pontos de
combinação, ou seja, elas descrevem os tipos de pontos de combinação de interesse para
o aspecto, restritos pelo modelo de pontos de combinação adotado. As características
transversais são atributos e operações que descrevem melhorias na estrutura e no
35
comportamento de componentes. Essas melhorias podem adicionar uma nova estrutura
e comportamento para um ou mais componentes, refinar ou até mesmo redefinir o
comportamento existente.
Os aspectos podem afetar um ou mais componentes, possivelmente afetando
sua estrutura e comportamento. Além disso, amplia-se o uso do termo para denotar
também um relacionamento genérico de um aspecto para um ou mais componentes.
2.4.4.3 Pontos de Junção
São métodos bem definidos na execução do fluxo do programa que compõem

pontos de corte. Segundo (KICZALES, 2001), pontos de junção podem ser considerados
como os nós do grafo de chamada de um objeto em tempo de execução. Nesse grafo,
por exemplo, os nós incluem locais onde um objeto recebe uma chamada de método e
locais onde um atributo de um objeto é referenciado, enquanto as arestas apresentam as
relações de fluxo de controle entre os nós. Os pontos de junção são classificados em
diversos tipos, dependendo do local específico onde eles residem no programa.
Conjuntos de pontos de junção podem identificar um único ponto de junção
ou a composição de vários deles, usando operadores lógicos como “e”, “ou”, além de
operadores como a negação. Os conjuntos de junção podem ser identificados na própria
declaração dos advices ou serem identificados por um nome e, posteriormente, podem
ser referidos por esse mesmo nome na declaração dos advices.
Os pontos de junção são os elementos chaves da orientação a aspecto, pois ele
é responsável por permitir a separação dos comandos de um software para realizar a
composição entre os comandos. Inclusive acrescentando outros comandos com trechos
de códigos escritos separadamente.
É o ponto onde aplica-se um interesse transversal por meio de aspecto, como
por exemplo a chamada de métodos, construtores, tratamento de exceções e outros.
Dessa forma, pode-se ter os pontos de atuação que tem como função capturar as
chamadas aos pontos de função, com a finalidade de ter mais um ponto de junção para
um ponto de função, conforme a Figura 17.
36
FIGURA 17 - Exemplo de mais de um ponto de junção para um ponto de função
(FONTE: WINCK; GOETTEN, 2006)
Um ponto de junção é qualquer ponto identificável por aplicações durante a

execução de um programa. Aspectos podem ser associados a pontos de junção e
executados antes, depois, ou ao invés deles.
2.4.4.4 Advices
Advice é uma estrutura que denota o que um aspecto deve fazer, ou seja, qual
o comportamento do aspecto. O advice designa a semântica comportamental do aspecto.
Todo advice está associado a um pointcut, que define pontos de junção.
De acordo com o autor (NELSON, 2005), advice são construções semelhantes
aos métodos, entretanto, não podem ser chamados diretamente pela aplicação base e
nem pelo próprio aspecto, pois sua execução é feita automaticamente após o entrecorte
no ponto de junção. Outra diferença em relação aos métodos é que os advices não
possuem nome, não tem especificadores de acesso (public, private, etc) e tem acesso a
variáveis especiais das execuções dos pontos de junção, como assinatura dos métodos
entrecortados, etc. Há três tipos de advice:
 Before: é o mais simples, simplesmente executa antes do ponto de
junção. O único detalhe a se observar é que se o advice levantar uma
exceção, o ponto de junção não será mais executado.
 After: executa depois do ponto de junção. Existem três variações desse
advice, que dependem de como a execução do ponto de junção é
finalizada, ou seja, se terminou normalmente, com uma exceção, ou de
37
qualquer forma. O Quadro 3 sintetiza as variações do after().
QUADRO 2 - As três variações possíveis de advice after

after() ponto_de_corte() Executa depois do ponto de junção, independente de como ele retornou
after() returning: ponto_de_corte() Executa depois do ponto de junção se ele tiver terminado novamente
(sem exceção)
after() throwing: ponto_de_corte() Executa depois do ponto de junção somente se este tiver saído com
uma exceção
 Around: o corpo de um advice around é executado substituindo o ponto

de junção. No entanto, o ponto de junção pode ser executado dentro do
corpo do advice usando-se o método proceed().
Todo advice around deve declarar um tipo a ser retornado. Este tipo
deve ser o mesmo tipo dos pontos de junção associados a ele. Por
exemplo, se o advice está associado à chamada de um método que
retorna inteiro, ele deve retornar um inteiro. Todos os pontos de junção
de um advice around devem retornar um tipo compatível com o tipo
retornado pelo advice, conforme ilustra a Figura 18.
FIGURA 18 - Exemplo de advice do tipo around
O aspecto pode usar informações do ponto de junção capturado. Essa

informação traz parte do contexto do ponto de junção. É dever do ponto de corte
(pointcut) expor o contexto desejado para que o advice possa usá-lo.
2.4.4.5 Passagem de Contexto
De acordo com o autor (LADDAD, 2009), aspectos frequentemente precisam
38
de informações sobre o ponto de junção que será afetado em determinado instante.
Sendo assim, através das cláusulas nos pontos de corte, existem 3 tipos de informação:
 Args(): a cláusula args(var1, var2, ... varn) pode ser usada para
capturar argumentos passados para um método. No exemplo da Figura
19, o método interceptado adicionalIngrediente() recebe como
parâmetro um objeto da classe Ingrediente. O ponto de corte captura o
objeto passado através da cláusula args. O args recebe como parâmetro
uma variável que pode ser usada no advice. A variável é declarada na
definição do pointcut, como se fosse um parâmetro do pointcut. No
advice, uma nova variável é declarada na declaração do advice, e
passada para o ponto de corte.
FIGURA 19 - Exemplo de args
 This: a cláusula this(obj) captura o objeto onde está o ponto de junção,

conforme pode ser visualizado no trecho de programa na Figura 20.
FIGURA 20 - Implementação de ponto de corte
Vai capturar na variável var o objeto da classe A que estiver executando

quando for feita a chamada a b.g(). Por exemplo, se executarmos o main() da classe A,
o objeto capturado pelo this() acima será o objeto a declarado em main().
 Target: esta cláusula é semelhante ao this(), porém ao invés de capturar
o objeto que contém o ponto de junção, capturará o objeto que é o alvo
39
de uma chamada ou atribuição. No entanto, target() fará sentido quando
associar aos pontos de corte call() ou set(), conforme a Figura 21.
FIGURA 21 - Ponto de corte call
O ponto de corte irá capturar o objeto da classe B sobre o qual está sendo executado o
método g(). O resultado do ponto de corte, nesse caso, é a execução de B.g() está na
classe B e não na classe A. Assim, o target(var) vai retornar um objeto da classe B
2.4.4.6 Weaving
É o processo onde é feita a mesclagem dos módulos do sistema de acordo com

os aspectos encontrados. O weaving é como uma outra etapa de compilação. Weaving
rules são as regras que devem ser aplicadas durante essa fase da compilação. Através de
um compilador especial é possível montar o sistema final combinando os módulos
principais e os secundários pelo método weaving (tecelagem), então tem-se o nome de
weaver ao compilador.
O weaver tem a capacidade de interceptar as chamadas de métodos em tempo
de compilação ou execução, conforme seu propósito, podendo desviar o fluxo de
execução e até mesmo abortar a execução do método (SILVEIRA et al., 2004).
O resultado que a POA modulariza as funcionalidades secundárias,
possibilitando a criação de um sistema que é mais fácil de implementar e manter,
conforme a Figura 22.
40
FIGURA 22 - Weaver fazendo a mesclagem dos módulos
(FONTE: GARCIA, 2015)
2.4.5 Problemas na utilização da POA
Conforme (KICZALES, 1997), a depuração é um dos maiores problemas.

Enquanto no nível sintático o código POA aparece em separado, ele está junto do
restante do código em tempo de execução. A inserção de advices pode se tornar
imprevisível se não ficar definido que aspecto deve dominar. Os designers de software
devem considerar meios alternativos para conseguir a separação do código. Porém, estas
abordagens não tem um mecanismo de quantificação que permite que o programador
chegue a diversos Join points com apenas uma declaração.
Outro problema com a POA é a captura não intencional de Join points através
de wilcards. Por exemplo, supõem-se que seja especificado um determinado pointcut a
um advice associado, e um wilcard para todos os métodos que tenham certo padrão de
nomenclatura. Um programador desatento pode criar um método cujo nome seja
compatível com esse wilcard, sem que seja essa a sua intenção, levando a execução
inadvertida do advice. Da mesma forma, ao renomear um método, pode-se alterar
41
completamente a sua semântica.
2.4.6 Benefícios da Programação Orientada a Aspectos
Conforme apresentado nas seções anteriores, a POA trouxe algumas

contribuições importantes para o desenvolvimento de sistemas no que se refere a
facilidade de manutenção e reutilização de código. Dentre as diversas vantagens e
benefícios que a POA dispõe, podem-se citar algumas delas, conforme o autor
(GARCIA, 2015):
 Responsabilidades mais transparentes de cada módulo: cada módulo é
responsável apenas pelas tarefas destinadas ao próprio módulo. Os
módulos são mais independentes.
 Modularização mais alta: as responsabilidades são melhor definidas em
cada módulo, os módulos têm baixo acoplamento entre si.
 Evolução do sistema mais facilitada: o baixo acoplamento possibilita
que alterações no sistema sejam feitas sem alteração do núcleo.
 Decisões de design podem ser tomadas com mais atraso: devido ao
baixo acoplamento não é necessário pensar em todos os problemas no
início do desenvolvimento do sistema.
 Mais reusabilidade do código: os módulos podem ser mais
reaproveitados devido à alta coesão e baixo acoplamento.
 Sistemas mais fáceis de desenvolver e manter: os aspectos tornam a
integração das partes do sistema um módulo separado, o que traz mais
facilidade no desenvolvimento.
 Custos reduzidos de introdução de novas funcionalidades: novas
funcionalidades podem ser introduzidas criando aspectos, não sendo
necessário alterar o núcleo para adicionar tais funcionalidades.
2.4.7 Linguagens que implementam POA
A linguagem de programação nada mais é do que comandos dos quais ao
42
serem executados realizar alguma função para atender alguma necessidade.
O quadro 3 apresenta as linguagens que possibilitam a POA.
QUADRO 3 - Linguagens POA

Linguagem Framework - (Referencia)
C# PostSharp, Spring.Net, aspect# - (ARCHER, 2001).
VB.NET DotSpect - (GROVES, 2013) e (PODILA, 2005).
Ada Ada - (BARNES, 2012).
AutoHotkey AutoHotkey - (HOOKS, 2009).
C AspectC - (COADY; FEELEY; SOMOLYN; KICZALES, 2001).
C++ AspectC++ - (AspectC++, 2015).
COBOL Cobble - (ADAMS, SCHUTTER e ZAIDMAN, 2005).
The Cocoa Objective-C AspectCocoa - (COCOADEV, 2015).
ColdFusion ColdSprint - (BATEMAN, CORFIELD, ROSS, SCOTT e WIERSMA, 2015).
Common Lisp AspectL - (COSTANZA, 2005).
Delphi Dsharp - (HODGES, 2014).
Delphi Prism Cirrus - (Avram, 2010).
ActionScript As3-commons-bytecode - (WARD, 2011).
Emacs Lisp GNU Emacs - (GNU, 2015)
Groovy Groovy - (Groovy, 2015)
Haskell AspectH - (ANDREADE; BORBA; SANTOS, 2004).
Java AspectJ - (LADDAD, 2001).
JavaScript AspectJS - (ASPECTSCHEME, 2015).
Squeak Smalltalk AspectS - (HIRSCHFELD, 2003).
Lua AspectLua - (ASPECTLUA, 2006).
Make Makao - (MCIS, 2014).
Matlab AspectMatlab - (ASLAM, BODZAY, 2015).
ML AspectML - (LIGATTI, ZDANCEWIC e WALKER, 2006).
Perl PearlAspect - (KENNEDY, 2013).
PHP PHPAspect - (PHPASPECT, 2015).
Prolog Whirl - (AUCLAIR, 2005).
Python SpringPython - (SPRINGPYTON, 2015).
Racket AspectScheme - (ASPECTSCHEME, 2015).
Ruby AspectR - (BRYANT, FELDT, 2002).
(FONTE: Próprio Autor)
2.5 Requisitos do sistema
Requisitos de um sistema são descrições dos serviços que devem ser

fornecidos por esse sistema e as suas restrições operacionais (SOMMERVILLE, 2007).
43
Um requisito de um sistema é uma característica do sistema ou a descrição de
algo que o sistema é capaz de realizar para atingir seus objetivos (PFLEEGER, 2004).
Com base nessas definições, pode-se dizer que os requisitos de um sistema
incluem especificações dos serviços que o sistema deve prover, restrições sob as quais
ele deve operar, propriedades gerais do sistema e restrições que devem ser satisfeitas no
seu processo de desenvolvimento.
As definições acima apresentadas apontam para a existência de diferentes
tipos de requisitos. Uma classificação amplamente aceita quanto ao tipo de informação
documentada por um requisito faz a distinção entre requisitos funcionais e requisitos
não funcionais.
2.5.1 Requisitos Funcionais
São declarações de serviços que o sistema deve prover, descrevendo o que o

sistema deve fazer (SOMMERVILLE, 2007). Um requisito funcional descreve uma
interação entre o sistema e o seu ambiente (PFLEEGER, 2004), podendo descrever,
ainda, como o sistema deve reagir a entradas específicas, como o sistema deve se
comportar em situações específicas e o que o sistema não deve fazer (SOMMERVILLE,
2007).
2.5.2 Requisitos Não Funcionais
Descrevem restrições sobre os serviços ou funções oferecidas pelo sistema

(SOMMERVILLE, 2007), as quais limitam as opções para criar uma solução para o
problema (PFLEEGER, 2004). Nesse sentido, os requisitos não funcionais são
importantes para a fase do projeto (design), servindo como base para a tomada de
decisões nessa fase.
Os requisitos não funcionais têm origem nas necessidades dos usuários, em
restrições de orçamento, em políticas organizacionais, em necessidades de
interoperabilidade com outros sistemas de software ou hardware ou em fatores externos
como regulamentos e legislações (SOMMERVILLE, 2007). Assim, os requisitos não
44
funcionais podem ser classificados quanto à sua origem. Existem diversas classificações
de requisitos não funcionais. O autor (SOMMERVILLE, 2007), por exemplo, classifica-
os em:
 Requisitos de produto: especificam o comportamento do produto
(sistema). Referem-se a atributos de qualidade que o sistema deve
apresentar, tais como confiabilidade, usabilidade, eficiência,
portabilidade, manutenibilidade e segurança.
 Requisitos organizacionais: são derivados de metas, políticas e
procedimentos das organizações do cliente e do desenvolvedor,
Incluem requisitos de processo (padrões de processo e modelos de
documentos que devem ser usados), requisitos de implementação (tal
como a linguagem de programação a ser adotada), restrições de entrega
(tempo para chegar ao mercado, restrições de cronograma, etc),
restrições orçamentárias (custo, custo-benefício), etc.
 Requisitos externos: referem-se a todos os requisitos derivados de
fatores externos ao sistema e seu processo de desenvolvimento. Podem
incluir requisitos de interoperabilidade com sistemas de outras
organizações, requisitos legais (tais como requisitos de privacidade) e
requisitos éticos.
2.5.3 Estratégia para licitar Requisitos Não Funcionais
Conforme cita o autor (LEITE, 1995), utiliza-se a ideia de que requisitos, de

uma maneira geral, não são estáticos e, portanto, sofrem mudanças durante o ciclo de
vida do software. Isso significa que os requisitos identificados, durante a fase de
elicitação de requisitos, continuam evoluindo por todo o ciclo de vida do software,
devendo o engenheiro de software ficar atento para estas possíveis evoluções e
representá-las devidamente.
A Figura 23 ilustra, a estratégia de elicitação de requisitos não funcionais.
45
FIGURA 23 - Estratégia de Elicitação de Requisitos Não Funcionais
(FONTE: LEITE, 1995)
2.5.4 Como identificar requisitos não funcionais
A elicitação de requisitos não funcionais deve ser feita separadamente dos

requisitos funcionais, de forma a manter o engenheiro de software centrado no problema
que ele está investigando. Isso significa que, mesmo se durante a elicitação de requisitos
funcionais, caso o engenheiro de software identifique algum requisito não funcional, ele
não deverá se aprofundar nesse requisito não funcional, e sim anotá-lo à parte para
posterior investigação.
Essa regra, é claro, vale também para o caso inverso que seria a identificação
de um requisito funcional ainda não identificado durante a elicitação dos requisitos não
funcionais.
Nessa etapa, o engenheiro de software deverá utilizar uma ou mais técnicas de
elicitação para identificar os requisitos não funcionais inerentes ao UdI. Assim, utiliza-
se o Léxico Ampliado da Linguagem (LAL), conforme cita o autor (FRANCO, 1992),
que tem por objetivo conhecer o vocabulário usado no UdI.
O LAL é baseado em um sistema de códigos composto por símbolos, noções
e impactos. Este é construído utilizando-se um conjunto de descrições, com o objetivo
de se obter a semântica dos símbolos encontrados. Essa descrição utiliza um sistema de
representação onde cada símbolo é descrito por noções e impactos. Cada símbolo é uma
46
entrada e as noções e impactos são itens dessa entrada, nos quais toda referência a outras
entradas deve ser sublinhada (princípio da circularidade).
A busca de requisitos não funcionais deverá ter como auxílio os requisitos
funcionais encontrados, o que significa dizer que o engenheiro de software, de posse do
documento que define os requisitos funcionais do sistema, deverá fazer uma busca em
cada requisito funcional descrito no documento, procurando identificar eventuais RNFs
a eles associados. Entretanto, alguns desses requisitos não funcionais, como por
exemplo segurança de acesso a dados do sistema, podem ser globais ao sistema não
estando relacionado a um determinado requisito funcional, e sim, presente em diversas
partes do sistema, ou mesmo no sistema como um todo.
Um instrumento importante no auxílio a identificação de RNFs pode ser o uso
de um checklist de RNFs como guia. A Figura 24 mostra um checklist que poderá ser
usado como ponto de partida. Essa lista não pretende ser completa e sim um apanhado
dos RNFs mais comuns, sendo portanto aconselhável que a medida que se identifique
um RNF não constante da lista que esta seja atualizada.
FIGURA 24 - Checklist de RNFs
(FONTE: FRANCO, 1992)
47
É importante que não sejam identificados apenas os RNFs de forma genérica,
como por exemplo, especificar desempenho como um RNF existente e nada mais. É
necessário que o requisito não funcional genérico seja instanciado (detalhado) até a
identificação do que o sistema precisa possuir ou fazer para que esse RNF seja satisfeito.
2.6 Conclusões do capítulo.
Seguindo o que foi apresentado no capítulo anterior, a POA, não é uma nova
metodologia de programação, e sim um suplemento para a POO, a qual não é substituída
pela POA, e sim complementada por esta. Essa evolução de tecnologia diz respeito a
melhorias e facilidades para novas implementações e manutenibilidade no que diz
respeito a um sistema, onde os interesses globais são fatorados em módulos separados
do código principal, aumentando assim a compreensão do sistema.
Esta separação de interesse dividida em módulos apresenta um melhor nível
de abstração dos dados, interesse esse considerado como aspecto, conceito principal
utilizado pela programação. Os aspectos são separados em classes individuais para que
com o auxílio de Pointcut, Joinpoint, Advices e o compilador Weaving as classes de
aspectos sejam executadas junto ao fluxo principal do sistema.
Para compreender o que considerar como um aspecto, se faz necessário que
sua identificação seja realizada ainda na fase de modelagem, e para se ter auxílio, pode
se levar em consideração a licitação de requisitos, como principal os não funcionais, os
quais expressam condições de comportamento e restrições que devem prevalecer.
Os Requisitos não Funcionais, estão normalmente relacionados a Requisitos
Funcionais, porém nem todo RNF necessita virar um aspecto. Pode se levar em
consideração e também auxiliar em sua escolha, como por exemplo, o impacto desse
requisito no sistema, sua abrangência em mais de uma classe e sua necessidade de
evolução. Realizando a separação desses aspectos, e possível evoluir no
desenvolvimento do sistema orientado a aspecto.
48
3 MODELAGEM DO SISTEMA
Neste capítulo, serão apresentados conceitos e informações sobre UML e o

Processo Unificado, seguido do levantamento de requisitos, casos de uso, expansão de
casos de uso, diagrama de classes, diagrama de atividade e prototipação de interface do
sistema proposto.
3.1 Processo unificado:
De acordo com Falbo, (2000), o Processo Unificado proposto pela Rational

(Rational Unified Process – RUP), foi criado para apoiar o desenvolvimento orientado
a objetos, fornecendo uma forma sistemática para se obter reais vantagens no uso da
Linguagem de Modelagem Unificada (Unified Modeling Language – UML). De fato,
ele não é exatamente um processo: é uma infraestrutura genérica de processo que pode
ser especializada para uma ampla classe de sistemas de software, para diferentes áreas
de aplicação, tipos de organização, níveis de competência e tamanhos de projetos.
O Processo Unificado e formado por algumas das melhores práticas de

desenvolvimento de software de forma que pode ser adaptada a uma vasta
variedade de projetos e empresas. Porém, o Processo Unificado não pode ser
considerado como apenas uma junção das melhores e principais características
das metodologias mais popular, ele também possui características especificas,
como ser orientado por casos de uso, ser centrado na arquitetura, ser iterativo
e incremental. Estas são as características principais do Processo Unificado, o
que o torna único (SEABRA, 2001).
3.1.1 UML
Segundo a empresa OMG, (2003) a linguagem de Modelagem Unificada é

uma linguagem visual para especificar, construir e documentar os artefatos de um
sistema.
49
A UML serve de interesse a qualquer pessoa que participe na produção,
desenvolvimento ou manutenção de um software. Pois prevê situações ainda não
identificadas na fase de desenvolvimento, facilitando assim para que se chegue ao final
de um software com maior aproveitamento do projeto.
“A UML, é uma linguagem gráfica para visualização, especificação,

construção e documentação de artefatos de sistemas complexos de softwares,
onde a UML proporciona uma forma-padrão para preparação de planos de
arquiteturas de projetos de sistemas, incluindo aspectos conceituais como
processos de negócios e funções do sistema, além de itens concretos como as
classes escritas em determinada linguagem de programação, esquemas de
bancos de dados e componentes de softwares reutilizáveis”. (BOOCH et al
2005, p. XIV)
3.1.2 Descrição do estudo de caso
Desenvolver uma aplicação Windows Forms, o qual simule três tipos de

operações possíveis de serem realizadas em um caixa eletrônico, permitindo que o
usuário acesse sua conta e realize operações de saque, transferência e depósito, bem
como, visualização de saldo ou extrato. Após finalizada a primeira parte do
desenvolvimento utilizando orientação a objeto, serão identificados os possíveis pontos
de aspectos, baseados nos requisitos levantados na modelagem para refatoração da
aplicação, utilizando o conceito de orientação a aspecto.
3.2 Caso de uso
Para Seabra (2015), um caso de uso representa um conjunto de ações realizadas

pelo sistema que geram resultados observáveis por um ator, ou seja, um caso de uso é
utilizado para estruturar o comportamento de um sistema sem ser necessário especificar
sua implementação, além de envolver a interação de atores, que podem ser tanto
humanos como sistemas automatizados.
“O diagrama de caso de uso por meio de uma linguagem simples, demonstra

o comportamento externo do sistema, procurando apresentar o sistema através
de uma perspectiva do usuário, demonstrando as funções e serviços oferecidos
e quais usuários poderão utilizar cada serviço. Este diagrama é, dentre todos
50
os diagramas de UML, o mais abstrato, flexível e informal, sendo utilizado
principalmente no início da modelagem do sistema, embora venha a ser
consultado e possivelmente modificado durante todo o processo de engenharia
e sirva de base para a modelagem de outros diagramas”. (GUEDES, 2005).
3.2.1 Diagrama de caso de uso
A figura 25 representa o diagrama de caso de uso de parte de um sistema de caixa

eletrônico.
FIGURA 25 - Caso de Uso 03
3.3 Levantamento de Requisitos
Para (Wazlavick, 2013) a eliciação de requisitos referência a extração de

informações sobre as funções que o sistema realiza, e também suas restrições. No
entanto, durante a eliciação de requisitos, o analista pode encontrar regras de negócio
ou restrições sobre como as funções devem ser realizadas pelo sistema, esse tipo de regra
é um requisito não funcional.
Sommerville, (2007), reforça que outra forma de registrar requisitos através do
uso de um documento que consiste em uma lista de requisitos funcionais, possivelmente
acompanhada de uma lista de restrições.
51
3.3.1 Requisitos Funcionais
As informações que definem as funcionalidades do protótipo proposto serão

descritas através, dos quadros 4 a 15:
QUADRO 4 - Autenticação da conta

RF1. Autenticação da conta
Descrição:
Para iniciar o sistema, deve-se informar os dados de agência e conta para
validação de cadastro, confirmando ou negando o acesso ao sistema.
Restrições lógicas: Digitar agência e conta
QUADRO 5 - Efetuar Saque

RF1. Efetuar Saque
Descrição:
O sistema deve permitir a opção de saque, limitado ao valor diário de no máximo
R$ 1.000,00. Antes de realizar essa operação a agência e conta do cliente devem
ser informadas. A efetivação da operação depende da confirmação da senha do
cliente.
Restrições lógicas: Usuário precisa confirmar a senha da conta.
QUADRO 6 - Efetuar Depósito

RF2. Efetuar depósito
Descrição:
O sistema deve permitir a opção de depósito. Antes de realizar essa operação a
agência e a conta do cliente devem ser informadas. A efetivação da operação
depende da confirmação da senha do cliente.
Restrições lógicas: N/A
QUADRO 7 - Efetuar Transferência

RF3. Efetuar transferência
52
Descrição:
O sistema deve permitir a realização de transferências entre contas. Antes de
realizar essa operação a agência e a conta do cliente devem ser informadas. A
efetivação da operação depende da confirmação da senha do cliente.
QUADRO 8 - Emitir Extrato

RF5. Emitir extrato
Descrição:
O sistema deve permitir a geração de extrato da conta, apresentando o histórico
de movimentação dos últimos 15 (quinze) dias. Antes de realizar essa operação a
agência e a conta do cliente devem ser informadas. A efetivação da operação
depende da confirmação da senha do cliente.
QUADRO 9 - Verificação de transferência

RF6. O sistema não deve permitir transferência para um mesmo número de
conta
Descrição:
O sistema deve verificar se os dados da conta de destino não são os mesmos da
conta de origem, para permitir a transferência.
QUADRO 10 - Validação de saldo para saque

RF8. O valor de saque deve ser maior que zero
Descrição:
O sistema deve verificar se o valor desejado para saque é maior que R$ 0,00, caso
contrário, apresentar mensagem de alerta.
53
QUADRO 11 - Verificação de saldo para transferência
RF8. O saldo da conta para realizar a transferência deve ser maior do que o
valor transferido
Descrição:
O sistema deve verificar se o saldo da conta de origem é maior do que o valor de
transferência da conta de destino, caso contrário, apresentar mensagem de alerta.
QUADRO 12 - Validação de conta destino

RF8. O sistema deve verificar a existência da conta de destino para realizar a
transferência
Descrição:
O sistema deve verificar os dados da conta de destino para que possibilite realizar
a transferência de valores, em caso de inexistência da conta, apresentar mensagem
de alerta.
QUADRO 13 - Validação de valor para transferência

RF8. O valor da transferência deve ser maior que zero
Descrição:
O sistema deve verificar se o valor para transferência é maior que R$ 0,00, caso
contrário, apresentar mensagem de alerta.
QUADRO 14 - Validação de saldo para saque

RF8. O saldo da conta deve ser maior do que o valor de saque
Descrição:
O sistema deve verificar se o saldo da conta é maior do que o valor solicitado para
o saque, caso contrário, apresentar mensagem de alerta.
54
QUADRO 15 - Validação de conta
RF8. O sistema deve validar os dados da conta de acesso através de uma senha
Descrição:
Para garantir a segurança do acesso, o sistema deve solicitar uma senha de
confirmação de conta, para assim garantir que a operação a ser realizada é válida.
3.3.1.1 Relacionamento entre requisitos funcionais versus casos de uso
A Figura 26 demonstra o relacionamento de dependência entre os casos de uso

e os requisitos funcionais.
FIGURA 26 - Requisitos funcionais versus Casos de uso
3.3.2 Requisitos Não funcionais
55
O quadro 16 apresenta a lista de requisitos não funcionais do sistema.
QUADRO 16 - Requisitos não funcionais

RNF.01 O sistema deve verificar se a conta informada é íntegra.
RNF.02 O sistema deve verificar se o tempo de acesso não expirou.
RNF.03 O sistema deve manter um controle de auditoria nas operações.
RNF.04 O sistema deve tratar todas as ocorrências de erro em uma tela informativa.
RNF.05 O sistema deve manter um tempo de resposta inferior a 1000ms em todas as chamadas.
RNF.06 O sistema deve consultar/salvar os dados da conta do usuário em arquivo, através do
padrão de repositórios.
3.3.2.1 Relacionamento entre requisitos não funcionais versus casos de uso
Os requisitos não funcionais apresentam grande impacto no sistema, pois

normalmente suas características estão relacionadas a todas as camadas. Após os
requisitos levantados é possível identificar os possíveis aspectos, onde para facilitar a
visualização destes, foi montada uma tabela comparativa entre requisitos não funcionais
e os casos de uso, representado pela Figura 27.
FIGURA 27 - RNF versus Casos de uso
3.4 Diagrama de classe
No diagrama de classes é possível modelar as classes e seus relacionamentos,

assim como, definir seus atributos e operações.
A Figura 28 apresenta o diagrama de classe do estudo de caso proposto.
56
FIGURA 28 - Diagrama de classe

Para melhorar a compreensão do diagrama, as classes propostas na Figura 29
serão explicadas durante a fase de desenvolvimento.
3.5 Operações
A seguir será descrito as principais funções da classe transação pertencente ao

estudo de caso proposto.
3.5.1 Função Saque:
O sistema deve permitir que o usuário realize saque. Na Figura 29 será

apresentado o Diagrama de Atividade.
57
FIGURA 29 - Diagrama de Atividade da Função Saque
Na Figura 30 será apresentado o diagrama de sequência.
FIGURA 30 - Diagrama de Sequência Função Saque
3.5.2 Função Depósito
58
O sistema deve permitir que o usuário realize Depósito. Na Figura 31 será
apresentado o Diagrama de Atividade dessa funcionalidade.
FIGURA 31 - Diagrama de Atividade da Função Depósito

FIGURA 32 - Diagrama de Sequência da Função Depósito
3.5.3 Função Transferência
59
O sistema deve permitir que o usuário realize Transferência. Na Figura 33 será
apresentado o Diagrama de Atividade.
FIGURA 33 - Diagrama de Atividade Função Transferência
Na figura 34 será apresentado o diagrama de sequência.
FIGURA 34 - Diagrama de Sequência Função Transferência.
60
3.5.4 Consulta Extrato
O sistema deve permitir que o usuário visualize seu extrato. Na Figura 35 será
apresentado o Diagrama de Atividade
FIGURA 35 - Diagrama de Atividade Consulta Extrato
FIGURA 36 - Diagrama de Sequência Consulta Extrato
61
3.6 Prototipação de interface
Segundo Sommerville (2003, p.159), “a prototipação é parte essencial do

processo de projeto de interface. Devido à natureza dinâmica das interfaces com o
usuário, as descrições textuais e os diagramas não são suficientemente bons para
exprimir os requisitos da interface com usuário”.
A seguir serão apresentados, da Figura 37 até a Figura 43, os protótipos de
interface das telas do sistema proposto.
A Figura 37 apresenta o protótipo da tela inicial do sistema.
FIGURA 37 - Interface Login
A Figura acima representa a tela de acesso à conta do usuário, onde devem ser
inseridos os dados da agência e conta disponibilizadas pela operadora do cartão
cadastrado. Após isso, basta acessar o botão confirmar para prosseguir.
A Figura 38, representa as opções de saque, depósito, transferência e extrato,
disponíveis para utilização do usuário, bastando clicar na opção desejada.
62
FIGURA 38 - Interface Operações
Para a opção de saque e transferência, será necessário uma confirmação de conta

através de uma senha conforme demonstra a Figura 39. Essa senha é fornecida no
momento da abertura da conta.
FIGURA 39 - Interface Confirma Saque\Transferência
Confirmando a senha, será apresentado a opção para informar o valor desejado

para o saque. A Figura 40 representa a interface para informar o valor do saque.
63
FIGURA 40 - Interface Saque
Na Figura 41 será apresentada a operação de transferência.
FIGURA 41 - Interface Transferência
Na Figura 42 é apresentado a opção de depósito.
64
FIGURA 42 - Interface Depósito
Na Figura 43 apresenta uma opção de Extrato para consulta das últimas operações
realizadas.
FIGURA 43 - Interface Extrato
3.7 Considerações finais
Nesse capítulo foi apresentado o processo de modelagem do sistema em questão,

onde optou-se pelo processo unificado o qual permitiu realizar o levantamento das
necessidades essenciais do sistema, e também realizar definições quanto ao formato de
65
sua estrutura e particularidades para seu funcionamento. Com isso, foi possível
apresentar as principais classes necessárias para o desenvolvimento, assim como o fluxo
de funcionamento para cada opção que estará disponível, assim como as possíveis
classes para utilização de aspectos. Também foi realizada toda prototipação de interface,
apresentando assim uma documentação inicial do sistema.
66
4 DESENVOLVIMENTO
Para elaboração do desenvolvimento foram utilizadas as ferramentas de

programação Microsoft Visual Studio 2012, juntamente com a linguagem C#. O trabalho
será apresentado em duas fases, iniciando com o desenvolvimento do sistema proposto
em POO e sua transformação para POA, enfatizando seus princípios, e demonstrando
suas vantagens e desvantagens.
4.1 Tecnologias utilizadas
Para a implementação do sistema foi necessário o uso de algumas tecnologias e

ferramentas. Abaixo são descritos breves conceitos destas tecnologias.
4.1.1 XML
Segundo PEREIRA (2006), o XML traz uma sintaxe básica que pode ser utilizada
para compartilhar informações entre diferentes computadores e aplicações. Quando
combinado com outros padrões, torna possível definir o conteúdo de um documento
separadamente de seu formato, tornando simples para reutilizar o código em outras
aplicações para diferentes propósitos. Uma das suas principais características é a
portabilidade, pois, por exemplo, um banco de dados pode escrever um arquivo XML
para que outro banco consiga lê-lo.
“XML significa Extensible Markup Language (Linguagem de Marcação

Extensível). Linguagens de marcação compreendem todas aquelas que
possibilitam a formatação de elementos por meio de tags e atributos como o
HTML e XHTML. Por ser extensível, o XML possibilita a criação de
elementos, ou seja, você mesmo pode inventar as suas tags.” (DÉCIO, 2000).
67
Alguns dos propósitos do XML consiste em auxiliar os sistemas de informação
no compartilhamento de dados (especialmente via internet), codificar documentos e
inserir seriais nos dados comparando o texto com o de outras linguagens baseadas em
serialização (PEREIRA, 2006).
4.1.2 JSON
Segundo AUGUSTO (2009), o JSON pode substituir o XML, e faz isso muito
bem na hora de trabalhar com respostas em AJAX. A estrutura de dados fica mais
simples de trabalhar e o tempo de execução de um script lendo dados em JSON é dezenas
de vezes mais rápido do que ler um conteúdo XML.
O JSON é um formato de troca de dados que também serve para serializar objetos.
Um objeto na memória pode ser transformado em um formato independente da
linguagem e ser transportado por qualquer meio até o seu destino, de maneira
semelhante ao SOAP (SAMPAIO, 2007).
4.1.3 PostSharp
PostSharp Aspect Framework é uma implementação pragmática de conceitos

POA. Todas as implementações ready-made de padrões construídos usando PostSharp
Aspect Framework. Você pode usar a mesma tecnologia para automatizar a
implementação de seus próprios padrões. (Postsharp.net, 2015).
“Uma vez o PostSharp estando instalado, você pode encapsular a

funcionalidade transversal desejada em um método de aspecto e, em seguida,
aplicar esse aspecto individualmente para as classes ou métodos desejados
dentro do aplicativo de maneira declarativa e de maneira declarativa também
usar seus atributos.” (KUNK, 2012).
PostSharp é uma extensão 100% compatível para o C# ou VB, linguagens que

adicionam suporte para padrões de projetos e segurança de segmentos. As equipes que
usam PostSharp são capazes de fornecer recursos com menos linhas de código e menos
defeitos. (Postsharp.net, 2015).
68
4.2 Programação Orientada a Objetos
Neste capítulo será realizado o detalhamento da implementação de um sistema

de caixa eletrônico, baseado em todo o levantamento realizado na fase de modelagem.
4.2.1.1 Estrutura do projeto
Para a estruturação do projeto proposto as classes foram divididas em três

camadas (dados, interfaces e negócio), conforme demonstrado na Figura 44:
FIGURA 44 - Estrutura do projeto
(Fonte: Próprio Autor)
A camada de dados é composta pelas classe Conta e as classes de Repositório. A

classe Conta conforme demonstrada pela Figura 45 apresenta toda a estrutura do objeto
Conta e algumas validações específicas deste objeto, suas declarações e seus tipos de
transações possíveis, e também os atributos de um extrato.
69
FIGURA 45 - Classe Comuns
Ainda dentro da classe Conta, também são apresentados os métodos

específicos deste objeto, relacionados a controles. A Figura 46 apresenta informações
dos métodos disponíveis.
FIGURA 46 - Métodos classe Conta
Abaixo serão apresentados detalhes sobre os métodos da classe Conta

 Authorized é utilizado para validação da conta. Nesse método é
verificado se a conta não expirou, gravando a data da consulta em um
arquivo.
 FilePath apresenta o local em que estão sendo salvas as contas criadas
e seus históricos de transações.
 LoadAccount serve para verificar se os dados da conta existem nos
70
arquivos salvos, carregando assim suas informações em uma lista de
objetos do tipo Conta.
 ValidPassword verifica se a senha da conta logada confere com a
digitada pelo usuário.
 AddValue adiciona o valor na conta, gera um extrato e grava em
arquivo.
 RemoveValue remove o valor da conta, gera um extrato e grava em
arquivo.
A Classe Repositório é uma classe polimórfica “pai”, a qual “seta” um padrão
para que se possa salvar em arquivo formatado com estilo XML ou JSON.
A Figura 47 apresenta a implementação da classe repositório.
FIGURA 47 - Classe repositório
Os métodos apresentados nas linhas 33 e 34, LoadAccount() e SaveAccount()

possuem a assinatura da classe de repositório, e são implementadas nas classes de nome
RepositórioXML.cs e RepositorioJson.cs. A Figura 48 apresenta esta implementação.
71
FIGURA 48 - JSON e XML
É possível notar que cada uma das classes utilizou os dois métodos override, o
qual são de assinatura da classe de Repositório. Sendo assim, os dois invocam os
mesmos métodos, cada um utilizando implementações específicas.
A camada Interface apresenta todas as classes WindowsForms, o qual constitui-
se de telas do sistema.
A camada de Negócio possui a classe Itransactions e a classe Transações que é
responsável pela implementação de todos os métodos da classe de interface
Itransactions, sendo responsável pelas principais operações do sistema.
A Figura 49 serão detalhados os principais métodos de operação do sistema.
72
FIGURA 49 - Classe Transações
Abaixo serão detalhados os principais métodos utilizados pelo sistema:

 Login, é utilizado para verificar os dados da conta do usuário, validando
se a mesma existe, e também para carregar todas as informações do
usuário, como por exemplo, sua senha, seu saldo e suas últimas
transações.
 Logout verifica se a conta expirou seu tempo de atividade, ficando
assim inativa e não liberando as operações.
 SetDepósit é utilizado para inserir o dinheiro na conta do usuário, como
por exemplo na função depósito e na função transferência.
 SetTransfer é utilizado para a função transferência, utilizando mais dois
métodos para a operação sendo eles o SetWithdraw e SetDeposit.
 GetBalance serve para obter o saldo atual da conta do usuário.
 SetWithdraw, é utilizado junto ao método de saque e transferência,
sendo o responsável por remover o dinheiro da conta de origem.
A classe Static existe para deixar o objeto Conta “visível” para todo o projeto,
podendo ser chamado a qualquer instante. A Figura 50 traz a implementação dessa
classe.
73
FIGURA 50 - Classe static Static

A classe Trace serve para definir o diretório utilizado para salvar os arquivos
de trace da aplicação. A Figura 51 apresenta o método Write da classe trace.
FIGURA 51 - Classe Traces
E por último tem-se a classe Program, responsável pelo start inicial do

sistema.
Na Figura 52 é possível visualizar seus métodos de inicialização.
FIGURA 52 - Classe Program
74
Os métodos utilizados nas linhas 14 e 16, preparam os estilos que serão
utilizados nas classes WindowsForm, e na linha 19 inicia a tela de login: Formlogin() o
qual irá conhecer todos os métodos apresentados pela classe Transações, instanciada
através da linha 18.
4.2.1.2 Entrelaçamento de Código (Tangled Code)
Conforme verificado nos relacionamentos entre casos de uso e requisitos não

funcionais, estas funcionalidades “não funcionais”, são passíveis de virarem uma classe
de aspecto. Neste tópico serão apresentados alguns dos aspectos que serão
implementados na fase de desenvolvimento.
Na Figura 53, linha 63 é apresentada a função de validação de conta do
usuário. Conforme requisito “RNF.02, O sistema deve verificar se o tempo de acesso não
expirou.”. Essa validação é replicada em vários métodos da mesma classe, Realizar o
Login, Logout, Transferência, Depósito e atualizar o Saldo ou Extrato. Gerando um
excesso de informação, perdendo assim o foco na regra de negócio.
FIGURA 53 - Método de validação de conta
O método (!conta.Autorized) é responsável por verificar se o usuário logado

no sistema não excedeu seu tempo de utilização, expirando assim seu login no sistema.
75
Note que esta função é espalhada em vários métodos, conforme apresentado nas Figuras
54 a 58.
FIGURA 54 - Método LoadAccount() (logout)
FIGURA 55 - Método LoadAccount() (SetDeposit)
FIGURA 56 - Método LoadAccount() (SetTransfer)
FIGURA 57 - 7Método LoadAccount() (GetBalance)
76
FIGURA 58 - Método LoadAccount() (SetWithdraw)
O mesmo ocorre para as chamadas de registro de logs de operação. A chamada

Traces.Write é repetida por todo o código, chamando a classe de trace e adicionando o
status atual do sistema junto ao método Write.
O controle de exceção realizado pelo comando throw new exception também
é controlado em cada método do sistema, onde se repete em todos os métodos para que
em caso de uma ação inesperada o sistema apresente o motivo desta exceção.
Sendo assim, estes apresentam características semelhantes durante a operação
de um sistema, pois todos estão espalhados por todo o sistema, ocasionando pela falta
de um controle centralizado.
4.3 Programação Orientada a Aspectos
Nesta seção será transformado o desenvolvimento apresentado no tópico

anterior, baseado nos conceitos estudados anteriormente.
A ideia principal deste desenvolvimento será focada na utilização de 3 (três)
aspectos já apresentados no tópico anterior, para que seja possível apresentar uma
solução compacta onde demonstre a eficácia da solução, junto aos seus pontos de
funcionamento.
O principal diferencial da POA é a facilidade de modularização dos interesses
transversais, complementando a POO, e para o seu funcionamento, são necessárias três
etapas distintas para a fase de desenvolvimento. Na Figura 59 são apresentadas as etapas
de desenvolvimento de software orientado a aspectos, extraída de LADDAD (2003).
77
FIGURA 59 - Etapas de Desenvolvimento de Software Orientado a Aspectos
(FONTE: LADDAD, 2003)
• Decomposição dos interesses (aspectual decomposition): identificar e

separar os interesses transversais dos interesses do negócio;
• Implementar os interesses (concern implementation): implementar cada um
dos interesses identificados separadamente;
• Recompor os aspectos (aspectual recomposition): nesta etapa, tem-se o
integrador de aspectos que especifica regras de recomposição para criação de unidades
de modularização. A esse processo de junção da codificação dos componentes e dos
aspectos é dado o nome de combinação (weaving).
4.3.1.1 Estrutura do projeto orientado a aspecto
A estrutura do projeto ficou similar ao já apresentado com a solução orientada

a objeto. Sendo assim, as classes foram separadas nas camadas (dados, interfaces,
negócio e aspectos). A Figura 60 apresenta esta estrutura.
78
FIGURA 60 - Estrutura de projeto com implementação de aspecto
Como a estrutura acima já foi apresentada anteriormente, o próximo passo

consiste na apresentação dos conceitos levantados na revisão bibliográfica.
4.3.1.1.1 Classes de aspecto
Para a criação dos aspectos foi utilizado o Framework do Postsharp,

disponibilizado em sua biblioteca uma estrutura de aspectos prontos para utilização.
Para realizar a instalação basta acessar o site: https://www.postsharp.net/,
navegar até a aba de download e baixar a versão 4.1.23. Após a instalação deve ser
verificado se o Postsharp ficou referenciado no projeto, conforme demonstra a Figura
61.
79
FIGURA 61 - Biblioteca PostSharp
Também é possível realizar a instalação do Postsharp via Gerenciador

“Nuget” de pacotes. Feito isto, basta criar uma nova classe de aspectos adicionando a
Tag [Serializable], responsável por deixar a classe visível para que o compilador utilize-
a em tempo de execução.
Para definição do tipo de execução de um aspecto, o Postsharp disponibiliza
algumas interfaces prontas para sua implementação, como por exemplo, o
OnMethodBoundaryAspect, o qual já disponibiliza a estrutura de métodos para serem
utilizados quando esta classe for executada. Os métodos podem ser utilizados antes ou
depois da execução do método que invocou o aspecto através dos métodos OnEntry e
OnExit. Também é possível utilizar alguns métodos prontos que o postsharp oferece,
como é o caso do OnException, que trata exceções no formato de aspecto identificando
que deve ser invocado após o acionamento de uma exceção no fluxo principal do
programa.
A Figura 62 representa a nova classe Aspecto_Security, responsável por
validar se não expirou a sessão da conta do usuário que está acessando o sistema.
80
FIGURA 62 - Implementação aspecto de segurança
As linhas 10 e 11 apresentam a estrutura da classe de aspecto. A linha 13

apresenta o momento que será executado o método apresentado nas linhas 15 à 19. Ou
seja, nesse caso a clausula OnEntry representa que o método será executado antes do
método que o aspecto será inserido no fluxo principal.
Para utilizar a classe de aspecto demonstrada acima, basta evidenciar sua
necessidade através da marcação [Aspecto_Security]. A Figura 63 apresenta a utilização
deste aspecto no fluxo principal, através da classe Transação.
FIGURA 63 - Aspecto Segurança
A linha 79 apresenta a marcação informando ao compilador que ao executar o

método SetWithdraw, deverá antes acessar a classe Aspecto_security, para interceptar
qual deve ser o momento da execução deste aspecto, sendo para este caso no início do
método, ou seja, antes de executar a validação realizada na linha 82.
81
Toda essa implementação de aspecto é tratada dentro dos conceitos utilizados
pela POA. No próximo tópico serão detalhados tais conceitos com exemplos utilizados
na implementação.
4.3.1.2 Classificação de conceitos
Nesta seção são apresentados na pratica os principais conceitos da POA,

demonstrando suas funções junto ao código implementado do sistema proposto.
4.3.1.2.1 Advice
O Advice nada mais é do que o “aspecto” que está sendo centralizado em uma
nova classe. Sendo assim, é o código que será executado em um determinado momento
da interrupção do fluxo principal para execução de um código secundário. As Figuras
64, 66 e 66 representam exemplos de advices.
FIGURA 64 - Advice Log
FIGURA 65 - Advice Exception
82
FIGURA 66 - Advice Security
4.3.1.2.2 Pointcut
O Pointcut é um ponto bem definido no fluxo principal do sistema o qual

informa o momento de uma interrupção para que seja realizada a execução de um
Advice. A Figura 67 representa um exemplo de Pointcuts.
FIGURA 67 - Exemplo de Pointcuts
A marcação [Aspecto_Exception] trata de um pointcut o qual deve interromper

o método SetDeposit para tratar a execução, conforme descrito por um Advice, assim
como o pointcut [aspecto_log].
4.3.1.2.3 Joinpoint
O Joinpoint é definido por um conjunto de pontos bem definidos no fluxo

principal do sistema, o qual une os advices aos Pointcuts. A Figura 68 representa a
estrutura de um conjunto dos Joinpoints da classe Transação.
83
FIGURA 68 - Aspecto inserido no fluxo principal
Quaisquer classes com um conjunto de aspectos implementados formam uma

estrutura chamada de joinpoints, onde sua responsabilidade é ligar esses com as classes
de aspecto e seus devidos métodos.
4.4 Diferencial entre a programação orientada a aspecto sobre a orientada a

objeto
A POA surgiu com o objetivo de melhorar a modularização dos interesses

transversais, envolvendo os requisitos não-funcionais, que tem influência em todo o
programa, por meio de abstrações que possibilitam a separação e composição destes
interesses para construção de um sistema de software aspectual. Desde então são
realizadas pesquisas sobre o assunto para se determinar se a POA é ou não um
84
mecanismo eficaz para o desenvolvimento de software, com o seu foco voltado à
separação de interesses.
Abaixo serão apresentadas as principais vantagens e desvantagens em utilizar
a POA
4.4.1.1 Vantagens:
Foi possível identificar diversos benefícios que foram supridos pelo

surgimento da POA em relação à POO. Dentre eles pode-se destacar:
4.4.1.1.1 Melhor modularização
Foram definidos alguns módulos, os quais foram separados fisicamente em

classes de aspectos com características específicas tais como: segurança, tratamentos de
exceções e auditoria. Isso possibilitou o tratamento de assuntos transversais em classes
individuais tornando o código mais conciso e fácil de manter.
4.4.1.1.2 Menos responsabilidades em cada parte
Foi possível constatar que utilizando aspectos para tratar questões relativas à
segurança, log do sistema e tratamento de exceções elimina-se os códigos replicados.
Assim, a repetição de trechos de código como blocos “Trace.write” ou
"if(!conta.Authorized)" são evitados, centralizando estes códigos em classes específicas.
4.4.1.1.3 Facilidade para manutenção
Como as classes em aspectos tem-se menos responsabilidades no contexto

geral do sistema, tornando o código mais “enxuto”, as classes de regras de negócio
apresentam uma menor complexidade lógica, mantendo em seus métodos apenas o que
se propõe a fazer, gerando uma facilidade em se realizar uma manutenção pela
centralização de códigos específicos nos aspectos e de fácil identificação no sistema.
4.4.1.1.4 Facilidade de evolução
Com a centralização das classes de aspecto, o desenvolvedor pode se focar nas
85
regras de negócio, sem se preocupar com o código transversal, sendo assim, para cada
nova implementação serão recuperados os códigos já criados de maneira simples e
objetiva, aumentado assim a produtividade e facilitando a evolução.
4.4.1.1.5 Menor tempo e custo de desenvolvimento
Com a utilização da separação de interesses, os desenvolvedores podem ser

melhor distribuídos em um projeto, cada um com foco no que é de seu conhecimento e
realmente necessário, como por exemplo, uma equipe poderá cuidar da implementação
dos aspectos de log, persistência, exceção, segurança, e outra equipe focará com a
implementação das regras focadas no que realmente o sistema se propõe a fazer sem se
preocupar com características paralelas as quais poderão ser aproveitadas em qualquer
parte do sistema.
O fator (facilidade de manutenção) também apresenta grandes benefícios para
que o desenvolvedor identifique uma falha e possa corrigi-la com a perda de um menor
tempo de procura e manutenção.
4.4.1.1.6 Menor quantidade de linhas programadas
Foi feita uma contagem do número de linhas de código gerada por cada versão
do aplicativo, onde se obtiveram os seguintes resultados apresentado no Quatro 17.
QUADRO 17 - Comparação entre a quantidade de linhas implementadas

Tecnologia Classe1 Linhas de código Classe 2 Linha de código
POO Transações 173 Aspectos 32
POA Transações 93 Aspectos 50
Analisando os dados obtidos, observou-se uma pequena redução no número

de linhas do aplicativo feito em POA. Essa redução é proporcional à quantidade de
aspectos que forem implementados: quanto mais aspectos, menos código replicado e
consequentemente menos linhas de código geradas. É importante frisar que não foram
analisados todos os possíveis casos onde a POA poderia ser aplicada nesse software,
86
apenas os casos principais. Portanto, a redução de código poderia ser ainda maior.
4.4.1.2 Desvantagens:
Apesar de todos os benefícios gerados pelo uso da POA em relação ao uso da

POO, é importante destacar alguns pontos negativos que devem ser analisados antes de
se adotar esse novo paradigma de programação. Dentre eles se destacam os descritos a
seguir.
4.4.1.2.1 Pouco material de pesquisa disponível
Por se tratar de um paradigma de programação mais recente, uma das maiores

dificuldades encontradas para o desenvolvimento desse trabalho foi a limitação de fontes
didáticas disponíveis para a busca de conhecimento sobre esse assunto. Apesar da
existência de alguns bons livros, a POO leva bastante vantagem sobre a POA nesse
quesito, pois é um paradigma já consolidado e amplamente difundido.
4.4.1.2.2 Compilação mais lenta (Performance)
Foi possível observar, durante o desenvolvimento desse projeto, que o

processo de compilação em POA é mais lento que em POO. Muito provavelmente isso
se deve ao fato de antes da compilação ocorrer, um processo é realizado pelo
Combinador Aspectual (Weaver). Como dito anteriormente, ele combina as classes
escritas em linguagem de componentes, com as classes escritas em linguagens de
aspectos. A criação desse código intermediário, que precede a compilação, gera atrasos.
4.4.1.2.3 Refatoração de software orientado a objeto
Existe uma dificuldade para refatorar um software já finalizado orientado a

objeto, pois a geração de aspectos está ligada a fase de modelagem, e muitos sistemas
passaram por incrementações e evoluções não documentadas, sendo necessário um novo
projeto de modelagem de forma a identificar todos os aspectos para implementação.
87
5 APRESENTAÇÃO DO SISTEMA
Mesmo com o foco do trabalho voltado para esse novo conceito do paradigma
orientado a aspecto e não para o produto, para mostrar a aplicabilidade da POA foi
desenvolvido um protótipo referente a operações básicas de um caixa eletrônico, com
intuito de demonstrar um comparativo da POO versus a POA. O sistema desenvolvido
permite operações como por exemplo a realização de um saque, depósito, transferência
e extrato.
O protótipo ficou dividido em 8 telas, sendo a primeira: Tela de Login prevista
na modelagem, onde permite acessar as demais opções do sistema descrita na Figura 69.
FIGURA 69 - Tela de login do protótipo
Para acessar o sistema basta digitar os dados da Agência e Conta, clicando

após em Confirma. Caso não possua estes dados, para facilitar a criação de uma nova
Agência e Conta, basta realizar a tentativa de Login utilizando uma conta ainda não
cadastrada que o sistema se encarregará de criá-la, trazendo a senha padrão “123”. Na
segunda tentativa com esta mesma Agência e Conta, o sistema liberará a sessão de
88
acesso com este novo usuário criado.
A segunda tela contém as Opções de Operações, apresentando todas as opções
disponíveis para utilização, bastando selecionar a desejada. Figura 70.
FIGURA 70 - Tela Operações Protótipo
Iniciando pela função saque, a próxima tela é a de seleção de valores. Nesta

tela deve ser informado o valor que se deseja realizar o saque, confirmando a operação
clicando em Confirma. Figura 71.
FIGURA 71 - Operação Saque Protótipo

Na sequência aparecerá uma nova tela para confirmação da conta através de
uma senha. Figura 72.
89
FIGURA 72 - Operação Saque Protótipo
A segunda opção é a de depósito, bastando digitar o valor que se deseja

depositar que será automaticamente debitado na conta logada no sistema. Figura 73.
FIGURA 73 - Operação deposito Protótipo
A terceira opção é a transferência, nessa tela deve ser informado os dados da

agência e da conta em que se deseja realizar a operação. Também deve ser digitado o
valor que se deseja transferir. Figura 74.
90
FIGURA 74 - Operação Transferência Protótipo
Para continuar a operação basta clicar em Confirma, que o sistema irá validar
os dados da agência e conta digitada, e caso exista, será apresentada uma nova tela para
que se confirme a operação através de uma senha. Figura 75.
FIGURA 75 - Confirmação transferência Protótipo
Nessa tela, basta digitar a senha e clicar em Confirma, que após a validação
da senha a operação será realizada.
91
A última função disponível é o extrato. Selecionando essa opção, serão
apresentadas todas as transações realizadas e salvas no histórico. Figura 76.
FIGURA 76 - Operação extrato Protótipo
92
6 CONCLUSÃO
Conforme apresentado no levantamento bibliográfico, as empresas de

softwares investem cada vez mais em melhorias relacionadas a modularização dos seus
projetos, tendo assim um retorno positivo quanto ao tempo de desenvolvimento,
evolução, correção de falhas e manutenções. Devido a POA permitir uma melhor
distribuição de um mesmo projeto, está em grande evolução no estudo entre os
arquitetos de softwares. A evolução deste conceito também se dá devido a ampla
quantidade de Frameworks disponíveis no mercado para diversas linguagens, dentre
elas as mais conhecidas como C, C# e Java. Porém, a falta de documentações claras
quanto suas utilizações desfavorecem sua evolução.
Analisando o paradigma do ponto de vista da solução implementada, é notório
que as vantagens apresentadas trazem grandes benefícios para as empresas de softwares,
sendo que o foco na fase de modelagem traz uma outra perspectiva no ponto de vista do
desenvolvimento da solução proposta.
A utilização dos requisitos não funcionais para eliciação dos aspectos, facilita
a identificação das características transversais, podendo assim verificar o impacto para
o sistema, avaliando a possibilidade de implementação dos requisitos separado do “fluxo
principal”.
Sendo assim a POA se mostrou de grande eficácia pelo que se propõe a fazer,
pois mesmo com poucos aspectos implementados, ficou visível que as classes ficaram
mais coesas, apresentando maior modularização, sendo elas mais legíveis, não
necessitando que o desenvolvedor implemente a todo momento a mesma função,
aumentando a produtividade e o foco no que é de interesse, gerando assim um código
com menos linhas implementadas.
93
REFERÊNCIAS BIBLIOGRÁFICAS
ADAMS, Bram; SCHUTTER, Kris; ZAIDMAN Andy, AOP for Legacy

Environments, a Case Study Disponível em: < http://soft.vub.ac.be/events/
eiwas2005/Papers/EIWAS2005-Bram%20Adams.pdf > acessado em: 13 Jun. 2015.
ANDRADE, Carlos; BORBA, Paulo H; SANTOS, André. Uma extensão Orientada

a Aspectos de Hasekel. Disponível em: < http://seer.ufrgs.br/rita/article/
view/rita_v11_n2_p21-32 > acessado em: 05 de Ago. 2015.
ARCHER, Tom, Inside C# (Microsoft Programming) Second Edition. Washington:

Paperback, 2001.
ASLAM, Toheed; BODZAY, Andrew. A FRAMEWORK FOR DYNAMIC

SCIENTIFIC LANGUAGES. Disponível em: < http://www.sable.mcgill.ca/
mclab/aspectmatlab/index.html > acessado em: 06 de Ago. 2015.
ASPECTC++, AspectC++ Documentation. Disponível em: <

http://www.aspectc.org/Documentation.php > acessado em: 10 de Jun. 2015.
ASPECTLUA. Aspect-Oriented programming in Lua. Disponível em: <

http://aspectlua.luaforge.net/> Acessado em: 08 de Jun. 2015.
ASPECTSCHEME. AspectScheme. Disponível em: < http://planet.racket-

lang.org/display.ss?package=aspectscheme.plt&owner=dutchyn > acessado em: 05 de
Ago. 2015.
AUCLAIR, Douglas. Aspect-Oriented Programming in Prolog. Disponível em: <

https://bigzaphod.github.io/Whirl/dma/docs/aspects/aspects-man.html > acessado em:
01 de Ago. 2015.
AUGUSTO, Danilo. O que é JSON, como e quando utilizar?. Disponível em

<http://www.tidbits.com.br/o-que-e-json-como-e-quando-utilizar>. Acessado em 13 de
Set. 2015.
AVRAM, Abel. Delphi Prism 2010 Oferece um Melhor Desenvolvimento .NET.

Disponível em: < http://www.infoq.com/br/news/2009/10/Delphi-Prism-2010 >
Acessado em: 17 de Jun. 2015.
BARDOU, D. Roles, Subjects and Aspects: how do they relate? In: WORKSHOP
ON OBJECT-ORIENTED TECHNOLOGY, ECOOP 98, 12, 1998, Brussels. Berlin:
Springer-Verlag, 1998. p. 418- 419 (Lecture Notes In Computer Science; v. 1543).
94
BARNES Jhon, Rationale for Ada 2012: Introduction. 2012 Reino Unido.
BATEMAN, CORFIELD, ROSS, SCOTT e WIERSMA, 2015).
BOOCH Grady; IVAR, Jacobson; RUMBAUGH, James. UML Guia do Usuário. Rio
de Janeiro: Elsevier, 2005.
BRAYANT, Avi; FELDT, Robrt. AspectR - Simple aspect-oriented programming

in Ruby. Disponível em: < http://aspectr.sourceforge.net/ > acessado em: 07 de Ago.
2015.
CAHILL, Vinn, DEMPSEY, John, y. Aspects of System Support for Distributed

Computing. Proceedings of the Aspect-Oriented Programming Workshop at
ECOOP´97, Finlândia: Springer-Verlag LNCS, 1997.
CHAVEZ, C. A Model-Driven approach to aspect-oriented design. 2004, 305 p.

Tese de Doutorado – Pontifícia Universidade Católica do Rio de Janeiro,
Departamento de Informática, Rio de Janeiro, Março de 2004.
Coady, Yvonne; Feeley, Mike; Smolyn, Greg; Kiczales, Gregor. Using AspectC to
Improve the Modularity of Path-Specific Customization in Operating System
Code. Columbia, 2001.
COCOADEV. Aspect Oriented Programming Framework for Cocoa and

Objective-C. Disponível em: < http://cocoadev.com/AspectCocoa > acessado em: 14
de Jun. 2015.
COSTANZA, Pascal. AspectL - Release Notes. Disponível em: < https://common-

lisp.net/project/aspectl/release-notes.html > acessado em: 15 de Jun. 2015.
CZARNECKI Krzysztof, EISENECKER, Ulrich. Generative Programming:

Methods, Tools, and Applications. Addison-Wesley, 2000.
DÉCIO, Otávio C. Guia de consulta rápida: XML. São Paulo: Novatec, 2000.
DIJKSTRA, E., A Discipline of Programming. Pretice-Hall, Upper Sadlle River,

1976, NK, USA.
ELRAD, T.; Aksit, M.; Kiczales, G.; Lieberherr, K.; Ossher, H. Discussing Aspects of
AOP. Communications of the ACM, October 2001.
FABBRO, Luís Gustavo. Artigo: O que é Programação Orientada a Aspectos

(POA)? Disponível em: <http://www.profissionaisti.com.br/2011/09/o-que-e-
programacao-orientada-a-aspectos-poa/> acessado em: 27 de Fev. 2015.
FALBO, R. De Almeida. Artigo: A Experiência na Definição de um Processo

Padrão Baseado Disponível em:
<http://inf.ufes.br/~falbo/download/pub/Simpros2000.pdf>. Acessado em: 26 de Jul.
de 2015.
95
FRANCO, Ana Paula M., Métodos e representações de suporte à aquisição de
linguagens da aplicação. Dissertação de Mestrado da PUC-Rio, Abril 1992.
GARCIA, A. et al. Aspects @ PUC-Rio: Poster Session. In: BRAZILIAN

WORKSHOP ON ASPECT-ORIENTED SOFTWARE DEVELOPMENT, Brasília,
Brazil, 2004.
GROVES, Matthew D. AOP in .NET; practical aspect-oriented programming.

Canada: Manning Publications, 2013.
GROOVY – Objects implements. Disponível em < http://www.groovy-

lang.org/objectorientation.html > acessado em: 02 de Ago. 2015.
GUEDES, Gilleanes T.A. UML 2 – Guia de Consulta Rápida – Segunda Edição. São
Paulo: Novatec Editora Ltda, Novembro de 2005.
GNU, Appendix D X Options and Resources Disponível em:

<http://www.gnu.org/software/emacs/manual/html_node/emacs/X-Resources.html 2015>
Acessado em: 03 de Ago. 2015.
HIRRSCHFELD, Robert. AspectS – Aspect-Oriented Programming with Squeak.

Disposnível em: < https://www.hpi.uni-
potsdam.de/hirschfeld/publications/media/Hirschfeld_2003_AspectSAspectOrientedPr
ogrammingWithSqueak_Lncs2591.pdf > acessado em: 06 de Ago. 2015.
HOOKS, Function. Advice is best for end user programming, 2009.
HODGES, Nick. Developer Skill Sprints - Aspect Oriented Programming using

DSharp with Nick Hodges. Disponível em: < http://community.embarcadero.com/
index.php/article/technical-articles/1016-developer-skill-sprints-aspect-oriented-
programming-with-nick-hodges > acessado em: 13 de Jun. 2015.
KENNEDY, Adam. Aspect - Aspect-Oriented Programming (AOP) for Perl.

Disponível em: < https://metacpan.org/pod/Aspect > acessado em: 01 de Ago. 2015.
KICZALES, G. et al. Aspect-Oriented Programming. In: European Conference on

Object-Oriented Programming, 1997. London.
KUNK, Joe. Aspect-Oriented Programming with PostSharp. Disponível em:

<https://visualstudiomagazine.com/articles/2012/09/01/aop-with-postsharp.aspx>.
Acessado em: 14 de Set. 2015.
LADDAD, Ramnivas. AspectJ in Action, Second Edition. Enterprise AOP with

Spring Applications. Greenwich, London, 2009.
LAMPING, J. (1999). The Role of Base in Aspect-oriented Programming. In: Int´l

Workshop on Aspect-Oriented Programming At Ecoop´99.
96
LEITE, J.C.S.P., Oliveira, A.P.A, A Client Oriented Requirements Baseline. In
Proceedings of the Second IEEE International Symposium on Requirements
Engineering, York, UK, IEEE Computer Society Press, 1995 pp 108-115.
LIGATTI, Jay; ZDANCEWIC, Steve; WALKER, David. AspectML - Aspect-

oriented Functional Programming Language Research. Disponível em: <
http://sip.cs.princeton.edu/projects/aspectml/ > acessado em: 02 de Ago. 2015.
MCIS. MCIS LAB MAINTENANCE CONSTRUCTION AND INTELLIGENCE

OF SOFTWARE. Disponível em: < http://mcis.polymtl.ca/makao.html > acessado
em: 01 de Ago. 2015.
NELSON, Torsten. Aspectos, Treinamento e Consultoria em Engenharia de

Software. Belo Horizonte, 01 de novembro de 2005.
OMG. UML 2 Infrastructure Final Adopted Specifcation. Whitepaper, Object

Management Group, September 2003.
PACIOS, S. F. Uma abordagem orientada a aspecto para desenvolvimento de

linhas de produtos de software. 2006.
PARNAS, D. On the Criteria To Be Used in Decomposing Systems into Modules

Communications of the ACM, Vol. 15, No. 12, 1972. P.1053-1058.
PEREIRA, Gisele Floriano. Desenvolvimento do Sistema Web do Observatório

Astronômico da UFSC. 2006. 124 f. Graduação (Bacharel) - Curso de Sistemas
deInformação, Universidade Federal De Santa Catarina, Florianópolis, 2006. Cap. 3.
Disponível em:
<http://projetos.inf.ufsc.br/arquivos_projetos/projeto_513/monografia_gfp.pdf>.
Acessado em 11 de Maio de 2013>. Acessado em> 10 de Set. 2015.
PFLEEGER, S.L., Engenharia de Software: Teoria e Prática, São Paulo: Prentice

Hall, 2ª Edição, 2004.
PODILA, Pavan. Dotspect Project Home. 2009. Disponível em: <

http://dotspect.tigris.org/ > acessado em: 04 de Jun. 2015.
POSTSHARP.NET. What is postsharp. Disponível em: <

http://doc.postsharp.net/what-is-postsharp >. Acessado em: 13 de Set. 2015.
RESENDE, Antônio M. Pereira; SILVA, Claudiney Calixto. Programação

Orientada a Aspectos em Java: Desenvolvimento de Software Orientado a Aspectos.
Rio de Janeiro – Brasport, 2005.
PHPASPECT, PHPAspect Programing if aspect. Disponível em: <

http://www.phpaspect.org/ > acessado em: 15 de Ago. 2015.
RICARTE, Ivan Luiz Marques. Programação Orientada a Objetos: Uma
97
Abordagem com Java. UNICAMP, 2001.
SAMPAIO, Cleuton. Web 2.0 e mashups: Reinventando a Internet. Brasport, 2007.
SEABRA, Rodolfo Moacir Jr. Análise e projeto orientado a objetos usando UML e
o Processo Unificado. Disponível em: < http://www.ufpa.br/cdesouza/teaching/
es/Exemplo-RUP-Rodolfo-Seabra.pdf>. Acessado em: 01 de Ago. 2015.
SERSON, Roberto Rubinstein. Programação Orientada a Objetos com Java –

Curso Universitário. Rio de Janeiro: Brassport, 2007.
SILVEIRA, Fábio F. et al. Uma abordagem sobre atualização dinâmica em

componentes de sistemas orientados a objetos. São Paulo, 2004.
SOARES, Sergio; BORBA, Paulo. Implementing distribution and persistence

aspects with AspectJ. ACM Sigplan Notices 174-190, Pernambuco, 2002.
SOMMERVILLE, I. Engenharia de Software. 6ª Ed. São Paulo: Addison Wesley,

2003.
SOMMERVILLE, I. Engenharia de Software. 8ª Edição. São Paulo: Pearson –

Addison Wesley, 2007.
WARD, James. Introducing Mixing Loom – Runtime ActionScript Bytecode

Modification. Disponível em: < http://www.jamesward.com/2011/04/26/introducing-
mixing-loom-runtime-actionscript-bytecode-modification/ > Acessado em: 17 de Jun.
2015.
WAZLAWICK, R. Sidinei. Engenharia de software: conceitos e práticas. Rio de

Janeiro: Elsevier, 2013.
WINCK, D. V.; GOETTEN JUNIOR, V. AspectJ: programação orientada a

aspectos com Java. São Paulo: Novatec. 2006.
APÊNDICE
98
APÊNDICE A – ARTIGO…................................................................................... 100
99
APÊNDICE A - ARTIGO
A importância dos requisitos não funcionais no

desenvolvimento de um sistema orientada a aspecto
José Augusto Z. Franklin, Hugo Estevam R. Longo
Sistemas de Informação – Universidade do Planalto Catarinense (UNIPLAC)

88500-000 – Lages – SC – Brasil
Departamento de Tecnologia da Informação - Universidade do Planalto Catarinense

guto2908@live.com, hugoestevamrl@hotmail.com
Abstract. The article proposes an analogy to the object-oriented programming
format, noting the difficulties in controlling cross characteristics, emergence a new
concept of aspect-oriented programming. In this section will appear for function
format, key concepts and their idea of separation of crosscutting concerns, focusing
on system modelling phase which will demonstrate the importance of non-functional
requirements for identification of aspects. And lastly present a way to create a look
with real examples of use.
Resumo. O artigo propõe uma analogia ao formato de programação orientado a
objeto, observando suas dificuldades no controle de características transversais,
surgimento um novo conceito de programação orientada a aspecto. Nesta seção será
apresentado quanto ao seu formato de funcionamento, principais conceitos e sua
ideia de separação de interesses transversais, tendo como foco a fase de modelagem
do sistema o qual demonstrará a importância dos requisitos não funcionais para
identificação dos aspectos. E por último apresentará uma maneira de criação de um
aspecto, com exemplos reais de utilização.
1. Introdução
Durante anos, os engenheiros de softwares lutam quanto à estruturação de códigos, a fim de
maximizar sua reutilização e diminuir o risco de defeitos de um sistema. Enquanto a (POO)
Programação Orientada a Objeto fornece uma estrutura sólida para a organização de códigos,
acaba apresentando dificuldades para reutilizar características transversais, apresentando
problemas de entrelaçamento e espalhamento de código.
O autor Kiczales (1997) e sua equipe descrevem os problemas que (POO) Programação
Orientada a Objeto foi incapaz de capturar e resolver de uma forma clara. Eles observaram que
essas preocupações transversais acabaram sendo espalhadas por todo o código, deixando este
100
com um emaranhado de código, se tornando cada vez mais difícil de desenvolver e modificar.
Eles analisaram todas as razões entre as técnicas utilizadas para identificar o motivo de se
apresentar este descontrole, resultando neste “emaranhamento”, possibilitando o surgimento de
um novo conceito de programação orientada a aspecto.
2. Dificuldades encontradas na Programação Orientada a Objetos

Mesmo com a programação orientada a objeto sendo o padrão mais utilizado nos dias atuais
nas comunidades cientifica, comercial e acadêmica, neste conceito algumas dificuldades são
apresentadas referente ao controle de características transversais, apresentando um descontrole
nos códigos que ficam espalhado por todo o sistema trazendo maior deficiência no
desenvolvimento de um sistema. A Figura 1 representa esta dinâmica de entrelaçamento de
código.
Figura 1. Características transversais em camadas

Observando a Figura 1, fica visível a representação de três classes (conta, pedido e
estoque), onde possuem métodos específicos para cada operação, porém junto a estes métodos
existirão códigos redundantes e paralelos, misturando conceitos da classe de negócio com os
códigos de Segurança, Visualização e Persistência. Sendo assim, estes códigos atravessarão
todas as camadas do sistema, ficando a implementação destes códigos paralelos deficitário para
se manter e evoluir durante a fase de desenvolvimento.
Esse código intrusivo também pode ser observado através da Figura 2(a), o qual
analisando as linhas 34 e 42 e 50 os códigos acabam deixando lógica do sistema “embaralhada”,
portanto, assuntos que deveriam ser tratados somente em suas classes de origem estão sendo
tratadas em outras classes.
101
Figura 2. Código com características transversais
Neste caso é possível notar que o método “conectar()” se faz presente em diversas
classes, podendo também ser espalhados em diversas partes de um programa. A manutenção
para uma alteração desse método impactara em todas as classes que fazem uso deste. Por
exemplo, a Figura 2(b) representa a alteração desse método, note que neste formato o
desenvolvedor deve procurar em todo sistema o método “conectar()”, e realizar sua alteração
de forma descentralizada, necessitando de uma maior quantidade de tempo para esta atividade.
Sento assim, este código redundante distribuído pelo sistema representa o problema de
entrelaçamento, com consequência no espalhamento de código em várias classes. Esta situação
geralmente está associada a alguns problemas conhecidos, sendo eles:
 Baixa produtividade – A implementação simultânea de múltiplos interesses muda o foco
do desenvolvedor do interesse principal para interesses periféricos, gerando uma baixa
produtividade.
 Menor reuso de código – Devido as circunstâncias, um módulo implementa interesses
múltiplos. Outros sistemas requerendo funcionalidades similares podem não conseguir
utilizar o módulo prontamente, reduzindo ainda mais a produtividade.
 Qualidade de código baixa – O Entrelaçamento produz código com problemas ocultos.
Além disso, por atender a diversos interesses de uma só vez, um ou mais desses
interesses podem não receber atenção suficiente.
 Dificuldade de compressão – Fica difícil de saber exatamente o que ocorre com uma
classe ao ler o seu código, pois as chamadas referentes ao entrelaçamento estão fora da
mesma.
 Problemas de manutenção – Como não se tem um código centralizado a necessidade de
alteração de uma nomenclatura irá impactar em diversos métodos do sistema, tendo que
o desenvolvedor percorrer diversas linhas de códigos até certificar que todas sejam
atualizadas.
102
 Dificuldade de evolução – Atender requisitos futuros pode obrigar a um retrabalho na
implementação. Como a implementação não é modularizada corretamente, isso implica
em modificar muitos módulos.
Devido a todas as situações indesejadas expostas, em 1997 Kiczales, líder da Xerox,
coordenou uma equipe de pesquisadores dos quais preocupados com estes problemas,
estudaram os motivos destes códigos transversais, sendo os primeiros a descrever o conceito de
Programação Orientada a Aspecto.
3. Fundamentos da Programação Orientada a Aspectos

Segundo Hecht (2007), várias propostas surgiram nos últimos anos para permitir que interesses
transversais sejam solucionados isoladamente, entre elas a Separação Multidimensional de
Interesses (Multi-Dimensional Separation of Concerns), a Programação Orientada a Assuntos
(Subject-Iriented Programming). No entanto, a técnica que mais se popularizou, gerando não
só a maior quantidade de pesquisas, mas também as ferramentas mais avançadas foi a POA, ou
(AOP, do inglês Aspect-Oriented Programming).
A programação orientada a aspectos introduz novos conceitos à área da computação.
Dentre eles, o principal é o aspecto, que, é a unidade de encapsulamento de uma funcionalidade
ortogonal.
3.1 Importância da POA

A POA complementa a POO, fornecendo outra maneira de pensar sobre a estrutura do
programa. A unidade fundamental da modularidade em POO é a classe, enquanto que em POA
a unidade de modularidade é o aspecto. Aspectos permitem a modularização de preocupações,
tais como gerenciamento de transações que atravessam vários tipos e objetos.
O principal objetivo da POA é separar o código referente ao negócio dos códigos
transversais, uma divisão de interesses (requisitos), abrangendo o problema de legibilidade
como a questão da modularidade Por exemplo, considera-se que uma aplicação bancária
simplesmente transfere um valor de uma conta para outra, conforme ilustra a Figura 3.
Figura 3. Operação transferência.

Porém, numa aplicação bancária construída para o mundo real, este método de
transferência está longe do adequado. É necessário incluir valores de segurança, que
determinam se o usuário possui autorização para realizar a operação. É preciso também
“envolver” a operação em uma transação para prevenir perda de dados. Finalmente, é preciso
fazer o log dos dados da aplicação. Uma versão simplificada que contém estes novos objetos
(concerns) está ilustrada na Figura 4.
103
Figura 4. Códigos invasivos
Comparando com a primeira versão, o código perdeu a sua elegância e simplicidade,
depois que o código foi voltado para outros objetivos “misturado” com aquele que implementa
as regras do negócio.
Deve-se considerar o que ocorre quando é necessário alterar, por exemplo, a
implementação de segurança da aplicação. No exemplo mostrado, o código é espalhado por
vários métodos, e qualquer mudança significa um grande esforço de codificação.
Por fim, pode-se dizer que este código não está devidamente encapsulado nos seus
próprios módulos. Isto aumenta a complexidade do sistema e torna a manutenção do mesmo
muito difícil.
A POA então, busca resolver este problema permitindo que o programador implemente
essas questões (segurança, log, transações, e etc.) através de aspectos. Em muitas linguagens
que implementam POA, o aspecto é constituído de uma ou mais peças de advices (fragmentos
do código, como métodos) e uma lista de joinpoints (pontos no programa principal na qual os
advices são inseridos).
3.2 Conceitos e Terminologias

Para compreender o funcionamento da AOP se faz necessário o conhecimento de alguns
conceitos que formam a essência do paradigma. Abaixo será apresentado os principais
conceitos:
 Aspectos: Um aspecto é o elemento básico para o encapsulamento de elementos que
dão suporte ao uso da POA, sendo a implementação de um interesse transversal
realizada de maneira independente da implementação dos requisitos centrais. Aspectos
são definidos como propriedades de sistemas que afetam componentes e, mais
especificamente, como propriedades que afetam o desempenho ou a semântica de
104
componentes de forma sistêmica (KICZALES, 1997). Os aspectos podem afetar um ou
mais componentes, possivelmente afetando sua estrutura e comportamento. Além disso,
amplia-se o uso do termo para denotar também um relacionamento genérico de um
aspecto para um ou mais componentes
 JoinPoint. São métodos bem definidos na execução do fluxo do programa que compõem
pontos de corte. Segundo (KICZALES, 2001), pontos de junção podem ser
considerados como os nós do grafo de chamada de um objeto em tempo de execução.
Nesse grafo, por exemplo, os nós incluem locais onde um objeto recebe uma chamada
de método e locais onde um atributo de um objeto é referenciado, enquanto as arestas
apresentam as relações de fluxo de controle entre os nós. Os pontos de junção são
classificados em diversos tipos, dependendo do local específico onde eles residem no
programa.
 PointCut: Pode ser entendido como uma variável. Esta variável armazena uma lista
contendo as assinaturas de métodos que se tem interesse em interceptar. Esta
interceptação é feita com o objetivo de alterar o fluxo original do programa e inserir
novas chamadas, advices (RESENDE; SILVA, 2005).
 Advice: é uma estrutura que denota o que um aspecto deve fazer, ou seja, qual o
comportamento do aspecto. O advice designa a semântica comportamental do aspecto.
Todo advice está associado a um pointcut, que define pontos de junção.
De acordo com o autor (NELSON, 2005), advice são construções semelhantes aos
métodos, entretanto, não podem ser chamados diretamente pela aplicação base e nem pelo
próprio aspecto, pois sua execução é feita automaticamente após o entrecorte no ponto de
junção.
 Weaving - É o processo onde é feita a “mesclagem” dos módulos do sistema de acordo
com os aspectos encontrados. O weaving é como uma outra etapa de compilação.
Através de um compilador especial é possível montar o sistema final combinando os
módulos principais e os secundários pelo método weaving (tecelagem), então tem-se o
nome de weaver ao compilador. O weaver tem a capacidade de interceptar as chamadas
de métodos em tempo de compilação ou execução, conforme seu propósito, podendo
desviar o fluxo de execução e até mesmo abortar a execução do método (SILVEIRA et
al., 2004).
A linguagem de aspectos deve suportar a implementação das propriedades desejadas de
forma clara e concisa, fornecendo construções necessárias para que o programador crie
estruturas que descrevam o comportamento dos aspectos e definam em que situações eles
ocorrem, para isso vale observar algumas situações que devem ser avaliadas antes de escolher
o paradigma.
3.3 Problemas na utilização da POA

Existem alguns pontos importantes que devem ser destacados antes de começar a utilização
deste conceito orientação a aspecto, sendo o primeiro a depuração é um dos maiores problemas.
Enquanto no nível sintático o código POA aparece em separado, ele está junto do restante do
código em tempo de execução. (KICKZALES, 1997).
105
Outro problema com a POA é a captura não intencional de Join points através de
wilcards. Por exemplo, supõem-se que seja especificado um determinado pointcut a um advice
associado, e um wilcard para todos os métodos que tenham certo padrão de nomenclatura. Um
programador desatento pode criar um método cujo nome seja compatível com esse wilcard,
sem que seja essa a sua intenção, levando a execução inadvertida do advice. Da mesma forma,
ao renomear um método, pode-se alterar completamente a sua semântica.
3.4 Benefícios da Programação Orientada a Aspectos

Conforme apresentado nas seções anteriores, a POA trouxe algumas contribuições importantes
para o desenvolvimento de sistemas no que se refere a facilidade de manutenção e reutilização
de código. Dentre as diversas vantagens e benefícios que a POA dispõe, podem-se citar algumas
delas na Tabela 1, conforme descreve o autor (GARCIA, 2006).
Tabela 1. Vantagens e Benefícios disponível pelo paradigma orientado a aspecto.
Características Benefícios
“Responsabilidades mais Cada módulo é responsável apenas pelas tarefas

transparentes de cada módulo” destinadas ao próprio módulo. Os módulos são mais
independentes.
“Modularização mais alta” As responsabilidades são melhor definidas em cada

módulo pois estes possuem baixo acoplamento entre
si.
“Evolução do sistema mais O baixo acoplamento possibilita que alterações no

facilitada” sistema sejam feitas sem alteração do núcleo.
“Decisões de design podem ser Devido ao baixo acoplamento não é necessário

tomadas com mais atraso” pensar em todos os problemas no início do
desenvolvimento do sistema.
“Mais reusabilidade do código” Os módulos podem ser mais reaproveitados devido à

alta coesão e baixo acoplamento.
“Sistemas mais fáceis de desenvolver Os aspectos tornam a integração das partes do sistema
e manter” um módulo separado, o que traz mais facilidade no
desenvolvimento.
“Custos reduzidos de introdução de Novas funcionalidades podem ser introduzidas

novas funcionalidades” criando aspectos, não sendo necessário alterar o
núcleo para adicionar tais funcionalidades.
Os benefícios da POA tais como modularização, evolutibilidade e a remoção das

características negativas da presença dos interesses ortogonais do sistema, junto com a
robusteza das linguagens orientadas a aspectos, faz com que o trabalho de reengenharia de
sistemas OO seja muito recompensador. Em aspetos, uma das grandes dificuldades do processo
de refatoramento é a determinação de pointcuts efetivos para interceptar a execução do
106
programa e redirecioná-lo para seu devido advice. Tal processo precisa ser realizado de tal
forma que preserve o comportamento original (SILVA, 2011).
3.5 O Uso de POA em requisitos não funcionais

A POA surgiu com o objetivo de melhorar a modularização dos interesses transversais, para
isso a fase de separação de interesses é de extrema importância, visto que esta identificação
servirá de moldura para os aspectos desenvolvidos.
Os requisitos não funcionais apresentam características e especificações dos quais
expressam detalhes de como as funcionalidades do sistema devem se comportar para
alcançarem um determinado objetivo. Sendo assim, normalmente os requisitos não funcionais
entrecortam várias classes do sistema, por estarem geralmente associados a camadas de
(disponibilidade, segurança, log, persistência, design).
Para facilitar a identificação dos aspectos, os requisitos não funcionais servem de pilar
para iniciar a abstração destes. Após levantar todos os requisitos não funcionais, é possível
classificar alguns requisitos passíveis a virarem aspectos, Para facilitar esta concepção, pode-
se realizar o cruzamento de dados entre RNF versus casos de usos, como por exemplo o modelo
criado para esta representação disponibilizado através da Figura 5.
Figura 5. Requisitos versus Casos de uso

Essa intersecção marcada por um múltiplo relacionamento é passível de ser
implementada como um aspecto, de preferência que seja escolhido as intersecções que mais
casos de usos afetarem.
4. Programação Orientado a Aspecto em Requisitos não-Funcionais

O principal diferencial da POA é a facilidade de modularização dos interesses transversais,
complementando a POO, e para o seu funcionamento, são necessárias três etapas distintas para
a fase de desenvolvimento.
 Decomposição dos interesses (aspectual decomposition): identificar e separar os
interesses transversais dos interesses do negócio;
 Implementar os interesses (concern implementation): implementar cada um dos
interesses identificados separadamente;
107
 Recompor os aspectos (aspectual recomposition): nesta etapa, tem-se o integrador de
aspectos que especifica regras de recomposição para criação de unidades de
modularização. A esse processo de junção da codificação dos componentes e dos
aspectos é dado o nome de combinação (weaving).
Na Figura 6 é apresentado as etapas de desenvolvimento de software orientado a
aspectos, extraída de LADDAD (2003).
Figura 6. Etapas de desenvolvimento Orientado a aspecto

A estrutura de um sistema orientado a aspecto inicia pela licitação dos requisitos
transversais, dos quais conforme visto na seção anterior muitas vezes estão associados aos
requisitos não funcionais. A fase de implementação é similar ao código que seria criado no
fluxo principal no sistema. Finalizando com a recomposição realizada através do processo
weaving responsável por juntar todas as camadas em um só Fluxo. Na próxima seção será
apresentado uma forma de implementação dos aspectos utilizando a linguagem C#
4.1 Criando um Aspecto

Atualmente muitos frameworks já estão disponíveis no mercado para implementação deste
novo paradigma, como por exemplo, para a linguagem C# a biblioteca Postsharp, é um plug-
in para a ferramenta de programação Visual Studio. Sua instalação pode ser realizada via
gerenciador “Nuget” de pacotes e em sua biblioteca tem-se disponível uma estrutura de aspectos
prontos para serem utilizados, bastando criar uma nova classe incluindo em sua estrutura a Tag
[Serializable], responsável por deixar está visível para que o compilador utilize a classe em
tempo de execução.
4.2 Implementações de um aspecto

Para criar um Advice (aspecto), o framework disponibiliza algumas interfaces prontas para
implementação, como é o caso da interface OnMethodBoundaryAspect, o qual já disponibiliza
em sua estrutura alguns métodos para serem implementados e utilizados quando a classe de
aspecto for invocada. Um exemplo são os métodos OnEntry e OnExit, que servem para realizar
uma instrução no início e (ou) no final do método principal que invocou a classe de aspecto.
Para melhorar a abstração deste cenário e também exemplificando, imaginamos um
sistema de frente de caixa eletrônico, o qual devemos implementar dois interesses transversais,
sendo eles (manter um registro de log e realizar o tratamento de exceções). Para implementar
uma estrutura de registro (log), pode ser utilizado o método OnEntry com o comando
Console.Write("Entrando no método: " + args.Method); servindo para registro do momento da
entrada do método executado e também o método OnExit com o código Console.Write("Saindo
108
do método: " + args.Method); para registro da saída do método executado. A Figura 7
representa está implementação.
Figura 7. Códigos invasivos

A cláusula “args”, serve de auxílio para passagem de contextos, esta opção já vem
disponível na biblioteca utilizada. Para o exemplo representativo da Figura 7, a cláusula
args.Method retornará o nome do método em execução. No entanto, com esta estrutura pronta,
para todo método criado o qual seria necessário reescrever todas as cláusulas de trace em cada
método, agora pode ser inserido apenas um novo ponto de corte no método desejado através da
marcação [“nome_classe_AspectoImplementado”] antes de se iniciar a estrutura do método que
se deseje utilizar o aspecto. A Figura 8 representa a representação da implementação do aspecto
citado a nesse exemplo.
Figura 8. Fluxo de funcionamento de um aspecto

Para a implementação da tratativa de exceções, o Postsharp também disponibiliza a
interface OnExceptionAspect juntamente com o método OnException possibilitando a
implementação de uma estrutura para tratamento de exceção, conforme apresentado pela Figura
9. A sua utilização funciona do mesmo formato descrito para o tratamento de log, sendo que
deverá ser inserido um novo pointcut no fluxo principal do programa onde se queira introduzir
este método.
109
Figura 8. Aspecto de exceção
A centralização deste código em uma classe de aspecto apresenta diversos benefícios a
fase de desenvolvimento, dentre eles a principal, relacionado a melhorar a modularização, com
isso tem-se uma maior facilidade de manutenção, evolução e implementação, sendo que o
desenvolvedor poderá se focar no que é de interesse, podendo utilizar os códigos transversais,
sem se preocupar em reescrevê-los.
5. Considerações Finais
Com a utilização da POA foi possível identificar diversas vantagens apresentadas, dentre elas
podemos citar uma melhor modularização, deixando as características em comum separadas
fisicamente através de classes de aspectos, como por exemplo, classe de segurança, tratamento
de exceções e auditoria. Através dessa separação é apresentado uma menor responsabilidade
em cada parte do sistema devido a eliminação dos códigos replicados em várias classes o que
possibilita o tratamento de assuntos transversais em classes individuais.
Como as classes em aspectos passam a ter menos responsabilidades no contexto geral
do sistema o código fica mais “enxuto”, as classes de regras de negócio apresentam uma menor
complexidade lógica, mantendo em seus métodos apenas o que se propõe a fazer, ficando o
código centralizado com fácil identificação dos aspectos gerando uma facilidade em se realizar
uma manutenção. Com isso, os desenvolvedores podem ser melhor distribuídos em um projeto,
cada um focando com o que é necessário, como por exemplo, uma equipe poderá cuidar da
implementação dos aspectos de log, persistência, exceção, segurança, e outra equipe focará com
a implementação das regras de negócio. Focadas no que um método realmente se propõe a fazer
sem se preocupar com características paralelas as quais poderão ser aproveitadas em qualquer
parte do sistema. Sendo assim, para cada nova implementação serão recuperados os códigos já
criados de maneira simples e objetiva, aumentado assim a produtividade e facilitando a
evolução do sistema
A redução do número de linhas implementadas também ficou visível com a POA. Nos
testes realizados com três aspectos implementados se teve uma redução de 17% código. Sendo
essa redução proporcional à quantidade de aspectos que foram implementados pois quanto
maior a quantidade de aspectos, menos código replicado e consequentemente menos linhas de
código gerado.
Mesmo com todos os benefícios identificados é importante frisar alguns pontos
negativos que devem ser analisados antes de se adotar esse novo paradigma de programação.
Como por exemplo o fato de apresentar uma compilação mais lenta, devido ao fato de que
durante a compilação, um processo de combinação é realizado (Weaver). O qual junta as classes
110
escritas em linguagem de componentes, com as classes escritas em linguagens de aspectos. A
criação desse código intermediário, que precede a compilação, gera atrasos. Também existe
uma dificuldade para refatorar um software já produzido orientado a objeto, pois a geração de
aspectos está interligada com a fase de modelagem, e muitos sistemas passaram por
implementações e evoluções não documentadas, sendo necessário um novo projeto de
modelagem de forma a identificar todos os aspectos para implementação.
Também deve-se destacar a limitação nos materiais de pesquisa. Apesar da existência
de alguns bons livros, a POO leva bastante vantagem sobre a POA nesse quesito, pois é um
paradigma já consolidado e amplamente difundido.
References
GARCIA, Rogel. O que é Programação Orientada a Aspectos? Disponível em: <
http://www.javaframework.org/portal/2010/04/14/o-que-programao-orientada-a-aspectos/
> acessado em: 04 de Fev. 2015.
HECHT, Marcelo Victora. Análise Automática de código para Programação Orientada a
Aspectos. Disponível em: <https://www.lume.ufrgs.br/bitstream/handle/10183/31118/
000779425.pdf> acessado em: 10 de Out. 2015.
KICZALES, G. et al. Aspect-Oriented Programming. In: European Conference on Object-
Oriented Programming, 1997. London.
KICZALES, G. et al. An overview of AspectJ. In: European Conference on Object Oriented
Programming, 2001. London.
LADDAD, Ramnivas. AspectJ in Action, Second Edition. Enterprise AOP with Spring
Applications. Greenwich, London, 2009.
NELSON, Torsten. Aspectos, Treinamento e Consultoria em Engenharia de Software. Belo
Horizonte, 01 de novembro de 2005.
RESENDE, Antônio M. Pereira; SILVA, Claudiney Calixto. Programação Orientada a
Aspectos em Java: Desenvolvimento de Software Orientado a Aspectos. Rio de Janeiro –
Brasport, 2005.
SILVA, Antônio Carlos Júnior. REFATORAÇÃO DE SISTEMAS ORIENTADOS A
OBJETOS PARA AUXILIAR A CONSTRUÇÃO DE UM TESTBED PARA
MANUTENÇÃO DE SOFTWARE ORIENTADO A ASPECTOS Disponível em
<http://www.cin.ufpe.br/~tg/2011-2/acsj.pdf> acessado em: 10 de Nov. 2015.
SILVEIRA, Fábio F. et al. Uma abordagem sobre atualização dinâmica em componentes de
sistemas orientados a objetos. São Paulo, 2004.
111

A Importância Dos Requisitos Não Funcionais No Desenvolvimento de Um Sistema Orientada A Aspecto

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

A Importância Dos Requisitos Não Funcionais No Desenvolvimento de Um Sistema Orientada A Aspecto

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE DO PLANALTO CATARINENSE

CURSO DE SISTEMAS DE INFORMAÇÃO

JOSÉ AUGUSTO ZANOTTO FRANKLIN

A IMPORTÂNCIA DOS REQUISITOS NÃO FUNCIONAIS NO

A IMPORTÂNCIA DOS REQUISITOS NÃO FUNCIONAIS NO

Trabalho de Conclusão de Curso

Orientação: Prof(ª). Hugo Estevam

A IMPORTÂNCIA DOS REQUISITOS NÃO FUNCIONAIS NO

ESTE RELATÓRIO, DO TRABALHO DE

Lages (SC), 23 de agosto de 2015

Prof. Hugo Estevam Longo, Esp.

Prof. Madalena Pereira da Silva, Msc. Prof. Claiton Camargo de Souza.

Prof. Claiton Camargo de Souza. Prof. Madalena Pereira da Silva, Msc.

FIGURA 1 - Ideia geral do trabalho proposto. ..........................................................14

QUADRO 1 - Comparativo entre código espalhado e código emaranhado ..............25

AJAX - Asynchronous Javascript and XML

Durante anos, os engenheiros de softwares lutam quanto à estruturação de códigos, a

A Programação Orientada a Objetos (POO) é o padrão mais utilizado entre a

1.2 Descrição do problema

Durante anos, os engenheiros de softwares lutam quanto à estruturação de

A programação Orientada a Aspecto tem este objetivo, tentar separar os níveis

Como os aspectos têm a propriedade de permitir a alteração do funcionamento

A POA é um paradigma de programação relativamente novo e significativo

Por ser uma abordagem incremental, reduz-se a carga de trabalho necessária

1.4 Objetivo geral

Realizar um estudo para demonstrar as vantagens inerentes na (POA), levando

1.5 Objetivos específicos

a) Realizar um estudo de conceito sobre a POA;

A primeira parte do trabalho consistiu no pré projeto, onde foi realizado um

A Figura 1 apresenta um esboço quanto a estruturação desse trabalho, Onde

(FONTE: Próprio Autor, 2015)

2.1 Desenvolvimento de software.

2.2 Programação Orientada a Objetos

Com o Advento da POO houve um ganho na organização dos sistemas. O

O encapsulamento consiste em definir o que os outros objetos poderão acessar,

(FONTE: SERSON, 2007)

Na Figura 2, o caixa eletrônico encapsulado é como se fosse um cofre. Para

(FONTE: SERSON, 2007)

No trecho do código acima, quando o usuário tenta sacar, através do menu do

O mecanismo de herança no paradigma é um dos seus grandes trunfos. Este

(FONTE: SERSON, 2007)

Ainda de acordo com (SERSON, 2007), uma herança significa especialização.

Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma

FIGURA 5 - Exemplo de polimorfismo

(FONTE: SERSON, 2007)

Para utilizar o método polimórfico, tem-se o exemplo, ilustrado na Figura 6.

(FONTE: SERSON, 2007)

2.3 Dificuldades encontradas na POO

Conforme apresentado nas seções anteriores, a POO trouxe algumas

(FONTE: CHAVEZ, 2004)

Esses dois problemas expostos, evidenciam a dificuldade nos processos de

2.3.1 Entrelaçamento do Código (Tangled Code)

Para o DSOO (Desenvolvimento de Software Orientado a Objetos), o mundo

(FONTE: RESENDE; SILVA, 2005)

Nas linhas 34 e 36 por exemplo, ocorrem duas chamadas intrusivas,

2.3.2 Espalhamento do Código (Scattering Code)

(FONTE: RESENDE; SILVA, 2005)

FIGURA 10 - Distribuição dos registros de log no Tomcat

(FONTE: RESENDE; SILVA, 2005)

Agora analisando o exemplo acima, imaginando que a pessoa responsável pela

QUADRO 1 - Comparativo entre código espalhado e código emaranhado

2.4 Programação Orientada a Aspectos

2.4.1 Conceitos Fundamentais sobre a Programação Orientada a Aspectos