Multi-Tenancy is a critical component of any Software as a Service (SaaS) application, which enables one application instance to serve multiple organizations, or tenants. This presentation by Scott Crespo covers the basics of multi-tenant architectures, and how to implement multi-tenancy using Python, Django, and the open-source project known as Django Tenant Schemas.
Multi-Tenancy is a critical component of any Software as a Service (SaaS) application, which enables one application instance to serve multiple organizations, or tenants. This presentation by Scott Crespo covers the basics of multi-tenant architectures, and how to implement multi-tenancy using Python, Django, and the open-source project known as Django Tenant Schemas.
A aplicação de boas práticas de governança de ti no gerenciamento de ativos d...Marcelo Ariatti
Trabalho de Conclusão de Curso apresentado como requisito parcial para a obtenção do título de Bacharel em Sistemas de Informação da Escola Superior de Criciúma, ESUCRI.
Requisitos
Funcionais
Não-funcionais
Problemas
Possíveis Soluções
UML
Diagrama de Casos de Uso
Diagrama de Atividades
Diagramas de Caso de Uso no Rose
Diagramas de Atividades no Rose
“Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.” Martin Fowler
> Gerenciamento de Tempo
- Definição da Atividade
- Sequenciamento de Atividades
- Estimativa de Recursos e Duração da Atividade
- Desenvolvimento e Controle do Cronograma
> Gerenciamento de Riscos
- Planejamento do Gerenciamento de Riscos
- Identificação de Riscos
- Análise Qualitativa e Quantitativa de Riscos
- Planejamento de Respostas a Riscos
- Monitoramento e Controle de Riscos
> Gerenciamento de Comunicações
- Distribuição das Informações
- Relatório de Desempenho
- Gerenciamento das Partes Interessadas
> Gerenciamento de Recursos Humanos
- Planejamento de Recursos Humanos
- Mobilização e Desenvolvimento da Equipe do Projeto
A aplicação de boas práticas de governança de ti no gerenciamento de ativos d...Marcelo Ariatti
Trabalho de Conclusão de Curso apresentado como requisito parcial para a obtenção do título de Bacharel em Sistemas de Informação da Escola Superior de Criciúma, ESUCRI.
Requisitos
Funcionais
Não-funcionais
Problemas
Possíveis Soluções
UML
Diagrama de Casos de Uso
Diagrama de Atividades
Diagramas de Caso de Uso no Rose
Diagramas de Atividades no Rose
“Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.” Martin Fowler
> Gerenciamento de Tempo
- Definição da Atividade
- Sequenciamento de Atividades
- Estimativa de Recursos e Duração da Atividade
- Desenvolvimento e Controle do Cronograma
> Gerenciamento de Riscos
- Planejamento do Gerenciamento de Riscos
- Identificação de Riscos
- Análise Qualitativa e Quantitativa de Riscos
- Planejamento de Respostas a Riscos
- Monitoramento e Controle de Riscos
> Gerenciamento de Comunicações
- Distribuição das Informações
- Relatório de Desempenho
- Gerenciamento das Partes Interessadas
> Gerenciamento de Recursos Humanos
- Planejamento de Recursos Humanos
- Mobilização e Desenvolvimento da Equipe do Projeto
> Gerenciamento de Custos
- Estimativa de Custos
- Orçamentação
- Controle de Custos
> Gerenciamento de Aquisições
- Planejamento das Compras e Aquisições
> Gerenciamento da Integração
- Plano de Gerenciamento do Projeto
- Controle Integrado de Mudanças
- Monitoramento e Controle do Trabalho do Projeto
- Encerramento do Projeto
Este material descreve o processo de desenvolvimento de software desde o Workflow de Requisitos até o Workflow Arquitetura.
Os modelos são elaborados com a UML seguindo a Orientação a Objetos.
> Introdução
- Motivação
- Evolução da gerência de projetos
- Definição de projeto e gerenciamento de projetos
- PMI e estrutura do GUIA PMBOK®
- O ciclo de vida do projeto
- Processos de gerenciamento x Processos de desenvolvimento
> Gerenciamento de Escopo
- Planejamento do Escopo
- Verificação e Controle do Escopo
> Gerenciamento da Qualidade
- Planejamento da Qualidade
- Garantia e Controle da Qualidade
Exercicio de UML - Documentacao RestauranteJuliana Cindra
Exercício da disciplina de Especificação e Manutenção de Sistemas de Informação, do curso de pós-graduação em Análise, Projeto e Gerência de Sistemas de Informação.
UML, Linguagem de Modelagem Unificada, é um padrão para modelagem visual de software.
Neste tutorial abordamos como utilizar a UML para fazer especificação de software através de conjunto de modelos e diagramas.
A modelagem visual facilita o entendimento e a comunicação do 'o quê' precisa ser feito e 'como' deverá ser feito o software;
Apresentação sobre UML com foco nos Diagramas de Caso de Uso e Diagrama de Classes; apresentada na SESTINFO2009 (Semana de Estudos em Tecnologia da Informação) realizada na Universidade Metodista de São Paulo.
Quantas vezes você precisou lidar com achar e corrigir bugs mesmo meses depois do desenvolvimento?
Quantas vezes o seu budget estourou pois nem todos os cenários foram cobertos pelos desenvolvedores nos seus testes?
Nesta palestra vamos ver como uma pessoa ou time dedicada ao controle de qualidade pode trabalhar com o gerente do projeto e/ou líder técnico/arquiteto para garantir uma melhor cobertura de casos de usos e testes em múltiplos projetos, e como isso impactará a entrega final.
Isso não é um ataque aos desenvolvedores. Eu também sou um desenvolvedor!
Mas já passou o momento de levarmos QA mais a sério durante o desenvolvimento.
COMPARANDO FRAMEWORKS DE ARQUITETURA CORPORATIVA PARA APLICAÇÃO EM E-COMMERCEFernando S. de Paulo
Monografia apresentada ao PECE – Programa de Educação Continuada em Engenharia da Escola Politécnica da Universidade de São Paulo como parte dos requisitos para a conclusão do curso de MBA em Tecnologia de Software.
Área de Concentração: Tecnologia de Software
Orientador: Prof. Dra. Maria Alice Grigas Varella Ferreira
Este documento demonstra os cuidados que devemos ter ao desenvolver projetos ETL com o Oracle Data Integrator. Neste documento são demonstradas algumas das melhores práticas.
Slides utilizados na apresentação da RubyConf 2017 onde compartilhamos um pouco da nossa experiência na reconstrução de um sistema antigo utilizando Rails API e Vue.js
Apostila Linguagens Formais e Autômatos (LFA)Ricardo Terra
1 Revisão
- Conjuntos, relações e funções
- Definições Recursivas
- Indução Matemática -
- Linguagens Formais e Autômatos (LFA)
- Lemas, Teoremas, Corolários, etc.
2 Introdução
- Hierarquia de Chomsky
- Conceitos Básicos
3 Linguagens Regulares
- Conjuntos Regulares
- Expressões Regulares
- Gramáticas Regulares
- Autômatos Finitos
- Autômatos Finitos Determinísticos
- Autômatos Finitos Não-Determinísticos
- Autômatos Finitos Não-Determinísticos com Transições-λ
- Autômatos com Saída
- Máquina de Moore
- Máquinas de Mealy
- Algoritmos de Transformação
- Algoritmos
- Transformação AFND-λ para AFD
- Minimização de AFD
- Transformação de ER para AFND-λ
- Propriedades
- Lema do Bombeamento
4 Linguagens Livres de Contexto
- Gramática Livre de Contexto
- Recursividade
- Árvore de Derivação
- Ambiguidade
- Backus-Nahur Form (BNF)
- Formas Normais
- Transformações de Gramática
- Remoção de recursividade no símbolo inicial
- Eliminação de regras λ
- Eliminação de regras de cadeia
- Remoção de símbolos inúteis (TERM e REACH)
- Forma Normal de Chomsky
- Remoção de recursividade à esquerda
- Forma Normal de Greibach
- Autômatos com Pilha
- Variantes
- Critérios de Aceitação
- Algoritmos de Reconhecimento
- Autômato com Pilha como Reconhecedor
- Autômato com Pilha Descendente
- Algoritmo de Cocke-Younger-Kasami (CYK)
- Algoritmo de Early
- Algoritmos
- Transformação de GLCs para APs
- Transformação de APs para GLCs
- Propriedades
5 Linguagens Sensíveis ao Contexto
- Gramática Sensível ao Contexto
- Autômato Linearmente Limitado
- Teoremas
6 Linguagens Irrestritas
- Gramática Irrestrita
- Teoremas
- Máquinas de Turing
- Variantes
- Teoremas
7 Considerações Finais
- Hierarquia de Chomsky
- Tese de Church-Turing
Slides Lição 10, Central Gospel, A Batalha Do Armagedom, 1Tr24.pptxLuizHenriquedeAlmeid6
Slideshare Lição 10, Central Gospel, A Batalha Do Armagedom, 1Tr24, Pr Henrique, EBD NA TV, Revista ano 11, nº 1, Revista Estudo Bíblico Jovens E Adultos, Central Gospel, 2º Trimestre de 2024, Professor, Tema, Os Grandes Temas Do Fim, Comentarista, Pr. Joá Caitano, estudantes, professores, Ervália, MG, Imperatriz, MA, Cajamar, SP, estudos bíblicos, gospel, DEUS, ESPÍRITO SANTO, JESUS CRISTO, Com. Extra Pr. Luiz Henrique, 99-99152-0454, Canal YouTube, Henriquelhas, @PrHenrique
livro para professor da educação de jovens e adultos analisarem- do 4º ao 5º ano.
Livro integrado para professores da eja analisarem, como sugestão para ser adotado nas escolas que oferecem a educação de jovens e adultos.
Slides Lição 9, Betel, Ordenança para uma vida de santificação, 2Tr24.pptxLuizHenriquedeAlmeid6
Slideshare Lição 10, Betel, Ordenança para buscar a paz e fazer o bem, 2Tr24, Pr Henrique, EBD NA TV, 2° TRIMESTRE DE 2024, ADULTOS, EDITORA BETEL, TEMA, ORDENANÇAS BÍBLICAS, Doutrina Fundamentais Imperativas aos Cristãos para uma vida bem-sucedida e de Comunhão com DEUS, estudantes, professores, Ervália, MG, Imperatriz, MA, Cajamar, SP, estudos bíblicos, gospel, DEUS, ESPÍRITO SANTO, JESUS CRISTO, Comentários, Bispo Abner Ferreira, Com. Extra Pr. Luiz Henrique, 99-99152-0454, Canal YouTube, Henriquelhas, @PrHenrique
LIVRO MPARADIDATICO SOBRE BULLYING PARA TRABALHAR COM ALUNOS EM SALA DE AULA OU LEITURA EXTRA CLASSE, COM FOCO NUM PROBLEMA CRUCIAL E QUE ESTÁ TÃO PRESENTE NAS ESCOLAS BRASILEIRAS. OS ALUNOS PODEM LER EM SALA DE AULA. MATERIAL EXCELENTE PARA SER ADOTADO NAS ESCOLAS
Slides Lição 11, CPAD, A Realidade Bíblica do Inferno, 2Tr24.pptxLuizHenriquedeAlmeid6
Slideshare Lição 11, CPAD, A Realidade Bíblica do Inferno, 2Tr24, Pr Henrique, EBD NA TV, Lições Bíblicas, 2º Trimestre de 2024, adultos, Tema, A CARREIRA QUE NOS ESTÁ PROPOSTA, O CAMINHO DA SALVAÇÃO, SANTIDADE E PERSEVERANÇA PARA CHEGAR AO CÉU, Coment Osiel Gomes, estudantes, professores, Ervália, MG, Imperatriz, MA, Cajamar, SP, estudos bíblicos, gospel, DEUS, ESPÍRITO SANTO, JESUS CRISTO, Com. Extra Pr. Luiz Henrique, de Almeida Silva, tel-What, 99-99152-0454, Canal YouTube, Henriquelhas, @PrHenrique, https://ebdnatv.blogspot.com/
3. 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
4. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
5. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
6. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
7. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
8. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
9. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
10. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
11. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
12. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
Código do Apache Tomcat
§ Requisito não-transversal
§ Parsing de documento HTML
12
13. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
§ Requisito transversal (exemplo tradicional)
§ Logging
Código do Apache Tomcat
Código espalhado (scattered) e entrelaçado (tangled)
13
14. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
OOP vs AOP?
⇒
Implementação OOP de
logging
Implementação AOP de
logging
§ Boa pergunta a ser realizada:
§ Qual das implementações acima está mais fácil de ser
desenvolvida e de ser mantida?
14
15. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
§ 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
§ Boa pergunta a ser realizada:
§ 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
16. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
17. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
18. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
19. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
20. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
21. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
22. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
§ Observe as classes abaixo:
§ Boa pergunta a ser realizada:
§ 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) {..}
public Point getP2() {..}
public void setP2(Point p2) {..}
public void draw(Graphics g){..}
public void refresh(){
this.draw(Canvas.getGraphics(this));
}
}
Prática 01
22
23. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
§ Métodos comuns
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) {..}
public Point getP2() {..}
public void setP2(Point p2) {..}
public void draw(Graphics g){..}
public void refresh(){
this.draw(Canvas.getGraphics(this));
}
}
Prática 01
23
24. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
public class Point extends Figure {
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 class Line extends Figure {
private Point p1,p2;
public Point getP1() {..}
public void setP1(Point p1) {..}
public Point getP2() {..}
public void setP2(Point p2) {..}
public void draw(Graphics g){..}
}
public abstract class Figure {
public abstract void draw(Graphics g);
public void refresh(){
this.draw(Canvas.getGraphics(this));
}
}
Prática 01
§ Solução: uso de herança como mecanismo de reuso
24
25. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
§ Observe as classes abaixo:
§ Boa pergunta a ser realizada:
§ O que há de errado com o código acima?
public class Point extends Figure {
...
public void setX(int x) {
this.x = x;
this.refresh();
}
public void setY(int y) {
this.y = y;
this.refresh();
}
...
}
public class Line extends Figure {
...
public void setP1(Point p1) {
this.p1=p1;
this.refresh();
}
public void setP2(Point p2) {
this.p2=p2;
this.refresh();
}
...
}
Prática 01
25
26. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
§ Chamada a um mesmo método no final de todos setters
public class Point extends Figure {
...
public void setX(int x) {
this.x = x;
this.refresh();
}
public void setY(int y) {
this.y = y;
this.refresh();
}
...
}
public class Line extends Figure {
...
public void setP1(Point p1) {
this.p1=p1;
this.refresh();
}
public void setP2(Point p2) {
this.p2=p2;
this.refresh();
}
...
}
Prática 01
26
27. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
public aspect RefreshingAspect {
pointcut setterMethods():
execution(public void Figure+.set*(..));
after(Figure f): setterMethods() && this(f) {
f.refresh();
}
}
public class Point extends Figure {
...
public void setX(int x) {
this.x = x;
}
public void setY(int y) {
this.y = y;
}
...
}
public class Line extends Figure {
...
public void setP1(Point p1) {
this.p1=p1;
}
public void setP2(Point p2) {
this.p2=p2;
}
...
}
Prática 01
§ Solução: uso de aspecto
27
28. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
§ Observe a classe abaixo:
§ Boa pergunta a ser realizada:
§ O que há de errado com o código acima?
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
29. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
§ Implementação OOP de um requisito transversal
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
29
31. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
public class Concerns {
public void doSomething(int value){
...
}
public void doAnotherThing(char a, double b){
...
}
}
Prática 02
§ Assim, o desenvolvedor não precisa dar atenção a requisito de
logging
31
32. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
Prática 02
§ Demostração da criação de todo um projeto orientado a
aspectos
32
33. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
§ Observe uma das classes de persistência do sistema:
§ Boa pergunta a ser realizada:
§ O que há de errado com o código acima?
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
34. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
§ Observe uma das classes de persistência do sistema:
§ Boa pergunta a ser realizada:
§ O que há de errado com o código acima?
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
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
34
35. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
§ Observe uma das classes de persistência do sistema:
§ Boa pergunta a ser realizada:
§ O que há de errado com o código acima?
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
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
35
36. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
§ Implementação OOP de controle transacional
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
36
37. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
38. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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){
if (dao._connection!=null){
dao._connection.rollback();
}
throw e;
}finally{
if (dao._connection!=null){
dao._connection.close();
}
}
return operationResult;
}
} // Fim do Aspecto
Prática 03
§ Solução: uso de aspecto
38
39. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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);
if (dao._connection!=null){
dao._connection.commit();
}
}catch(SQLException e){
if (dao._connection!=null){
dao._connection.rollback();
}
throw e;
}finally{
if (dao._connection!=null){
dao._connection.close();
}
}
return operationResult;
}
} // Fim do Aspecto
39
40. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
public class UsuarioDAO implements IDataAccessObject{
public void add(Usuario usuario) throws SQLException{
PreparedStatement st =
_connection.prepareStatement("insert into USUARIO values (?,?,?)");
st.setString(1, usuario.getLogin());
st.setString(2, usuario.getSenha());
st.setString(3, usuario.getNome());
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
41. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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
42. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
Dúvidas?
???
42
43. Ricardo Terra (rterrabh [at] gmail.com) Outubro, 2013Programação Orientada a Aspectos
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