Programação Orientada a Aspectos

Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013
Programação Orientada a
Aspectos
Ricardo Terra
rterrabh [at] gmail.com
Programação Orientada a Aspectos 1

Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013
CV
Nome: Ricardo Terra
Email: rterrabh [at] gmail.com
www: ricardoterra.com.br
Twitter: rterrabh
Lattes: lattes.cnpq.br/ 0162081093970868
Ph.D. (UFMG/UWaterloo),
Post-Ph.D. (INRIA/Université Lille 1)
Background
Acadêmico: UFLA (desde 2014), UFSJ (1 ano), FUMEC (3 anos), UNIPAC (1 ano), FAMINAS (3 anos)
Profissional: DBA Eng. (1 ano), Synos (2 anos), Stefanini (1 ano)
Programação Orientada a Aspectos 2

Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
Nomenclaturas
§  Quaisquer das nomenclaturas abaixo é valida:
§  AOP à Aspect-Oriented Programming
§  POA à Programação Orientada a Aspectos (tradução)
§  AOSD à Aspect-Oriented Software Development
§  Já familiarizados com a variedade de termos para AOP, vamos
simplesmente falar AOP
3

Introdução
§  Paradigmas de Programação:
§  Programação Estruturada
§  Programação Orientada a Objetos (OOP)
§  Programação Orientada a Aspectos (AOP)
§  Boas perguntas a serem realizadas:
§  A OOP substitui a programação estruturada?
§  Então a AOP veio para substituir a OOP?
4

OOP vs AOP?
§  OOP
§  Paradigma dominante de programação
§  Unidade básica de modularização: classes
§  Desenvolvimento orientado a objetos:
§  Decomposição dos sistemas em classes
§  Classes implementam interesses (concerns) do sistema
5

OOP vs AOP?
ECOOP - European Conference on Object-Oriented Programming
§  Na ECOOP 1997, Gregor Kiczaler, propôs a AOP no artigo
Aspect-Oriented Programming
§  "We have found many programming problems for which
neither procedural nor object-oriented programming
techniques are sufficient to clearly capture some of the
important design decisions the program must implement. This
forces the implementation of those design decisions to be
scattered throughout the code, resulting in tangled code that
is excessively difficult to develop and maintain."
§  Principal objetivo da AOP:
§  Separation of Concerns
(separação de interesses, requisitos, funcionalidades…)
6

OOP vs AOP?
§  “O paradigma de orientação a objetos tem se consolidado como o
principal paradigma para o desenvolvimento de sistemas de
software. Entretanto, as abstrações e os mecanismos de
composição desse paradigma possuem limitações para separar e
compor alguns interesses relevantes em um sistema de software.”
§  “Assim, muitas propriedades importantes espalham-se por vários
módulos e misturam-se com outras propriedades de um sistema de
maneira intrusiva, dificultando a reutilização e manutenção de seus
componentes.”
§  “A POA propõe um novo tipo de abstração – denominado aspecto
– e novos mecanismos de composição que permitem a descrição
modular e a composição de interesses que geralmente se
encontram espalhados e misturados (crosscutting concerns) em
vários pontos de um sistema de software tradicional.”
7

OOP e AOP!
§  Respondendo a pergunta:
§  AOP não veio para substituir OOP
§  AOP trabalha em conjunto com a OOP
§  Uma linguagem orientada por aspectos permite confinar
interesses transversais (crosscutting concerns) em módulos
§  Em AOP, tais módulos são chamados de aspectos
§  Boa pergunta a ser realizada:
§  O que são interesses transversais (crosscutting concerns)?
8

Interesses transversais
§  São requisitos que não são facilmente implementados em uma
ou em poucas classes do sistema
§  Pode-se dizer que estes requisitos "pertencem" a todo o sistema
§  Exemplos:
§  Logging
§  Autenticação
§  Controle de acesso
§  Controle de transações
§  Persistência
§  Não é comum, mas requisitos funcionais também podem
apresentar um comportamento transversal
9

Interesses transversais
§  Principais problemas com requisitos transversais:
§  Código espalhado (code spreading/scattered)
§  Interesse transversal espalhado em diversas classes
§  Código entrelaçado (code tangling)
§  Interesse transversal entrelaçado com código de negócio
10

Código do Apache Tomcat
§  Para explicar na prática o que vem a ser um requisito transversal
ou não-transversal, vamos fazer análise sobre o código fonte do
Apache Tomcat
11

§  Requisito não-transversal
§  Parsing de documento HTML
12

§  Requisito transversal (exemplo tradicional)
§  Logging
Código espalhado (scattered) e entrelaçado (tangled)
13

OOP vs AOP?
⇒
Implementação OOP de
logging
Implementação AOP de
logging
§  Qual das implementações acima está mais fácil de ser
desenvolvida e de ser mantida?
14

§  Identificar e caracterizar os requisitos
§  Implementar requisitos não-transversais utilizando CLASSES
§  Implementar requisitos transversais utilizando ASPECTOS
§  Aspecto é uma unidade de modularização
§  Aspectos são desenvolvidos de forma isolada
§  Os módulos influenciados não necessitam de modificações
§  São combinados com os outros módulos usando
mecanismos declarativos ou programáticos
§  Vamos supor que eu implemente alguns aspectos. Como é
feita a sua combinação com os outros módulos de minha
aplicação?
Utilizando AOP
15

Interseção
§  Processo de interseção, conhecido como WEAVING
§  Ele é o responsável por “injetar” os aspectos, ou melhor, é a
ferramenta que combina código OO e código OA para a
geração do sistema final
§  É um processo relativamente lento
16

Conceitos básicos
§  Joinpoints (pontos de junção)
§  São pontos da execução do programa:
§  chamadas e execuções de métodos ou construtores
§  retorno de métodos ou construtores
§  lançamento ou tratamento de exceções
§  alteração de campos de classe
§  Pointcuts (coleção de pontos de junção)
§  Exemplos:
§  Todas as execuções de métodos públicos
§  Toda criação de objetos da classe Point
§  Toda chamada do método Point.setX ou Point.setY
§  Toda alteração do campo x da classe Point
17

Conceitos básicos
§  Advices
§  Código que deve executar no momento de qualquer joinpoint
de um pointcut
§  Exemplos:
§  chamar um método de log antes de toda chamada a
método público do programa
§  abrir conexão antes de executar métodos de persistência
§  fechar conexão depois de executar métodos de
persistência
§  chamar um método de atualização depois que qualquer
atributo de uma figura geométrica for alterado
§  executar um outro método ao invés de executar o método
§  Aspectos
§  Coleção de pointcuts e advices
18

Prática
§  Linguagens que permitem implementação AOP:
§  Java
§  AspectJ (a que será abordada)
§  HyperJ
§  Spring AOP
§  C e C++
§  AspectC e AspectC++, respectivamente
§  Aplicações de destaque que utiliza AOP:
§  FreeBSD (reestruturação do kernel)
§  JBoss AOP
§  Implementação de sistemas distribuídos
19

Prática
§  AspectJ
§  Extensão orientada a aspectos para Java
§  Declarações de aspectos são similares a declarações de
classes (como veremos nos exemplos a frente)
§  Em um aspecto podem ser declarados:
§  Pointcuts (conjuntos de junção)
§  Advices
20

Prática
§  Com a teoria já absorvida podemos ir um pouco além e mostrar
alguns exemplos
§  Os exemplos a seguir foram feitos utilizando:
§  Eclipse (Kepler)
§  http://www.eclipse.org
§  AJDT: AspectJ Development Tools 2.2.3
§  http://www.eclipse.org/ajdt
21

§  Observe as classes abaixo:
§  O que há de errado com o código acima?
public class Point {
private int x, y;
public int getX() {..}
public void setX(int x) {..}
public int getY() {..}
public void setY(int y) {..}
public void draw(Graphics g){..}
public void refresh(){
this.draw(Canvas.getGraphics(this));
}
}
public class Line {
private Point p1, p2;
public Point getP1() {..}
public void setP1(Point p1) {..}
}
}
Prática 01
22

§  Métodos comuns
public class Point {
private int x, y;
}
}
public class Line {
private Point p1, p2;
}
}
Prática 01
23

public class Point extends Figure {
private int x,y;
}
public class Line extends Figure {
private Point p1,p2;
}
public abstract class Figure {
public abstract void draw(Graphics g);
}
}
Prática 01
§  Solução: uso de herança como mecanismo de reuso
24

§  Observe as classes abaixo:
...
public void setX(int x) {
this.x = x;
this.refresh();
}
public void setY(int y) {
this.y = y;
this.refresh();
}
...
}
...
public void setP1(Point p1) {
this.p1=p1;
this.refresh();
}
this.p2=p2;
this.refresh();
}
...
}
Prática 01
25

§  Chamada a um mesmo método no final de todos setters
...
this.x = x;
this.refresh();
}
this.y = y;
this.refresh();
}
...
}
...
this.p1=p1;
this.refresh();
}
this.p2=p2;
this.refresh();
}
...
}
Prática 01
26

public aspect RefreshingAspect {
pointcut setterMethods():
execution(public void Figure+.set*(..));
after(Figure f): setterMethods() && this(f) {
f.refresh();
}
}
...
this.x = x;
}
this.y = y;
}
...
}
...
this.p1=p1;
}
this.p2=p2;
}
...
}
Prática 01
§  Solução: uso de aspecto
27

§  Observe a classe abaixo:
public class Concerns {
public void doSomething(int value){
Logger.logEntry("doSomething(" + value + ")");
...
Logger.logExit("doSomething");
}
public void doAnotherThing(char a, double b){
Logger.logEntry("doAnotherThing(" + a + "," + b + ")");
...
Logger.logExit("doAnotherThing");
}
}
Prática 02
28

§  Implementação OOP de um requisito transversal
Logger.logEntry("doSomething(" + value + ")");
...
Logger.logExit("doSomething");
}
Logger.logEntry("doAnotherThing(" + a + "," + b + ")");
...
Logger.logExit("doAnotherThing");
}
}
Prática 02
29

public aspect LoggingAspect {
pointcut publicMethods() : execution(public * *(..));
pointcut logObjectMethods() : execution(* Logger.*(..));
pointcut loggableCalls(): publicMethods() && !logObjectMethods();
before() : loggableCalls() {
Logger.logEntry(thisJoinPoint.getSignature().toString());
}
after() : loggableCalls() {
Logger.logExit(thisJoinPoint.getSignature().toString());
}
}
Prática 02
30

...
}
...
}
}
Prática 02
§  Assim, o desenvolvedor não precisa dar atenção a requisito de
logging
31

Prática 02
§  Demostração da criação de todo um projeto orientado a
aspectos
32

§  Observe uma das classes de persistência do sistema:
public class UsuarioDAO implements IDataAccessObject{
...
public void add(Usuario usuario) throws SQLException{
Connection conn = null;
try {
conn = ConnectionLocator.getConnection(); //Abre a conexão
PreparedStatement st =
conn.prepareStatement("insert into USUARIO values (?,?,?)");
st.setString(1, usuario.getLogin());
st.setString(2, usuario.getSenha());
st.setString(3, usuario.getNome());
st.execute();
st.close();
conn.commit(); //Realiza commit
} catch (SQLException e) {
if (conn!=null){
conn.rollback(); //Realiza rollback
}
throw e;
}finally{
if (conn!=null){
conn.close(); //Fecha a conexão
}
}
}
...
}//Fim da Classe
Prática 03
33

...
try {
st.execute();
st.close();
if (conn!=null){
}
throw e;
}finally{
if (conn!=null){
}
}
}
...
}//Fim da Classe
Prática 03
...
try {
st.execute();
st.close();
if (conn!=null){
}
throw e;
}finally{
if (conn!=null){
}
}
}
...
}//Fim da Classe
34

...
try {
st.execute();
st.close();
if (conn!=null){
}
throw e;
}finally{
if (conn!=null){
}
}
}
...
}//Fim da Classe
Prática 03
...
try {
st.execute();
st.close();
if (conn!=null){
}
throw e;
}finally{
if (conn!=null){
}
}
}
...
}//Fim da Classe
35

§  Implementação OOP de controle transacional
...
try {
st.execute();
st.close();
if (conn!=null){
}
throw e;
}finally{
if (conn!=null){
}
}
}
...
}//Fim da Classe
Prática 03
36

Prática 03
§  Esta implementação faz com o código do controle transacional
esteja espalhado e entrelaçado em todos os métodos dos
DAOs
§  O ideal seria que, na chamada de qualquer método transacional,
fosse automaticamente feito:
§  Abertura de conexão
§  Realização do commit da transação
§  Encerramento da conexão
§  Tratamento de eventuais exceções que possam vir a ocorrer
37

public aspect PersistenceAspect percflow(topLevelTransactedMethods()) {
public Connection com.terra.dao.IDataAccessObject._connection;
pointcut transactedMethods() : execution(* com.terra.dao.IDataAccessObject+.*(..));
pointcut topLevelTransactedMethods(): transactedMethods() &&
!cflowbelow(transactedMethods());
Object around(IDataAccessObject dao) throws SQLException :
topLevelTransactedMethods() && target(dao){
Object operationResult = null;
try{
dao._connection = ConnectionLocator.getConnection();
operationResult = proceed(dao);
if (dao._connection!=null){
dao._connection.commit();
}
}catch(SQLException e){
dao._connection.rollback();
}
throw e;
}finally{
dao._connection.close();
}
}
return operationResult;
}
} // Fim do Aspecto
Prática 03
38

Prática 03
public aspect PersistenceAspect percflow(topLevelTransactedMethods()) {
public Connection com.terra.dao.IDataAccessObject._connection;
pointcut transactedMethods() : execution(* com.terra.dao.IDataAccessObject+.*(..));
pointcut topLevelTransactedMethods(): transactedMethods() &&
!cflowbelow(transactedMethods());
Object around(IDataAccessObject dao) throws SQLException :
topLevelTransactedMethods() && target(dao){
Object operationResult = null;
try{
dao._connection = ConnectionLocator.getConnection();
operationResult = proceed(dao);
dao._connection.commit();
}
}catch(SQLException e){
dao._connection.rollback();
}
throw e;
}finally{
dao._connection.close();
}
}
return operationResult;
}
} // Fim do Aspecto
39

_connection.prepareStatement("insert into USUARIO values (?,?,?)");
st.execute();
st.close();
}
}//Fim da Classe
Prática 03
§  Assim, o desenvolvedor não precisa dar atenção ao controle
transacional nos métodos de persistência
40

Considerações finais
§  Desenvolver uma solução utilizando aspecto é um pouco
trabalhoso, mas é realizada apenas uma única vez
§  AOP é poderoso, entretanto pode ser perigoso
§  AOP quebra o raciocínio modular
§  Nada impede, mas o AOP não deve ser usado para qualquer
interesse, mas apenas, para os interesses transversais
§  Melhora o nível de modularização do sistema, com baixo
acoplamento e alta coesão
§  O processo de weaver demora
§  A sintaxe do AspectJ não é trivial
§  Desenvolver utilizando AOP é “massa”!
41

Dúvidas?
???
42

Ricardo Terra
rterrabh [at] gmail.com
Apresentação e vídeo disponíveis em:
www.ricardoterra.com.br/palestras
Principais referências bibliográficas:
KICZALES, Gregor et al. Aspect-Oriented Programming. ECOOP, 1997.
TIRELO, Fábio et al. Desenvolvimento de Software Orientado por
Aspectos. XXIII JAI, 2004.
VALENTE, M. T. Programação Orientada por Aspectos. Programa de
Pós-graduação em Informática PUC Minas, 2006.
Obrigado!
43

Programação Orientada a Aspectos

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Programação Orientada a Aspectos

Mais de Ricardo Terra

Último

Programação Orientada a Aspectos