UNIVERSIDADE NOVE DE JULHODisciplina: Processo de Desenvolvimento de Software

Programação Orientada a Serviço e Aspectos

UNINOVESÃO PAULO – 2013-1

UNIVERSIDADE NOVE DE JULHODisciplina: Processo de Desenvolvimento de Software

Programação Orientada a Serviço e Aspectos

Trabalho apresentado à Universidade Nove de Julho, UNINOVE, em cumprimento parcial às exigências da

disciplina de Processo de Desenvolvimento de Software, sob orientação do Profº. Moises

UNINOVESÃO PAULO – 2013-1

UNIVERSIDADE NOVE DE JULHO

Nomes R.A.

Armando Lopes da Silva 311203263

Deivid Moreira Macimo 311205030

Francisco dos Santos Martins 311205036

3

SUMÁRIO

1. RESUMO..............................................................................................................................................52. PROGRAMAÇÃO ORIENTADA A SERVIÇO (SOA).............................................................................................6

2.1. DEFINIÇÃO......................................................................................................................................62.2. SOA COMO SERVIÇOS ENCAPSULAM A LÓGICA.............................................................................72.3. SOA PRÁTICAS ESSENCIAIS.........................................................................................................10

3. PROGRAMAÇÃO ORIENTADA A ASPECTOS (POA).........................................................................................113.1. ORIENTAÇÃO A ASPECTOS...........................................................................................................123.2. ELEMENTOS DA ORIENTAÇÃO A ASPECTOS.................................................................................143.3. ASPECTOS.....................................................................................................................................153.4. AS VANTAGENS DA ORIENTAÇÃO ASPECTO................................................................................16

4. CONCLUSÃO..........................................................................................................................................17

4

1. RESUMO

Objetivo desta atividade é descrever os conceitos sobre (SOA) programação orientada a

serviço e (POA) programação orienta a aspectos

SOA é um estilo de arquitetura de software cujo princípio fundamental prega que as

funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de

serviço são conectados através de um "barramento de serviços" (enterprise service bus, em

inglês) que disponibiliza interfaces, ou contratos, acessíveis através de web services ou outra

forma de comunicação entre aplicações. A arquitetura SOA é baseada nos princípios da

computação distribuída e utiliza o paradigma request/reply para estabelecer a comunicação

entre os sistemas clientes e os sistemas que implementam os serviços.

5

2. Programação Orientada a Serviço (SOA)

2.1.Definição

Programação orientada a serviço (SOA) é um conceito de arquitetura corporativo, que nos

permite criar, padronizar, documentar serviços genéricos, únicos e interoperáveis, que possam

de maneira fácil, ser reutilizados por diversas aplicações diferentes, sem a necessidade de ser

desenvolvido novamente, tornando o processo de desenvolvimento mais ágil.

O SOA coloca a prestação de serviço como eixo de todo o negócio, dando destaque à gestão

de serviços e ao cliente.

Serviço – É uma É uma função independente, sem estado (stateless) que aceita uma ou mais

requisições e devolve uma ou mais respostas através de uma interface padronizada e bem

definida. Serviços podem também realizar partes discretas de um processo tal como editar ou

processar uma transação. Serviços não devem depender do estado de outras funções ou

processos. A tecnologia utilizada para prover o serviço, tal como uma linguagem de

programação, não pode fazer parte da definição do serviço.

Orquestração - Processo de sequenciar serviços e prover uma lógica adicional para processar

dados. Não inclui uma representação de dados.

Stateless - Não depende de nenhuma condição pré-existente. Os serviços não devem

depender de condições de outros serviços. Eles recebem todas as informações necessárias

para prover uma resposta consistente. O objetivo de buscar a característica de stateless dos

serviços é possibilitar que o consumidor do serviço possa sequenciá-lo, ou seja, orquestrá-los

em vários fluxos (algumas vezes chamados de pipelines) para executar a lógica de uma

aplicação.

Provedor – O recurso que executa o serviço em resposta a uma requisição de um consumidor.

Consumidor – É quem consome ou pede o resultado de um serviço fornecido por um

provedor.

Descoberta – SOA se baseia na capacidade de identificar serviços e suas características.

Consequentemente, esta arquitetura depende de um diretório que descreva quais os serviços

disponíveis dentro de um domínio.

Binding – A relação entre os serviços do provedor e do consumidor deve ser idealmente

dinâmica, ela é estabelecida em tempo de execução através de um mecanismo de binding.

6

2.2.SOA Como serviços encapsulam a lógica

Pode ser em contextos distintos. Estes contextos podem ser específicos para uma tarefa de

negócio, entidades de negócio e outros agrupamentos de negócio.

Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Na figura, quando construímos uma solução consistente de serviço, cada serviço pode

encapsular a tarefa realizada por um passo individual ou um sub-processo composto de um

conjunto de passos. Um serviço pode encapsular toda a lógica do processo. O último caso

representado pelo serviço pode englobar a lógica encapsulada de outros serviços.

Como serviços são relacionados

Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

7

Dentro do SOA serviços podem ser usados por outros serviços ou por outros programas.

Independentemente, o relacionamento por trás do serviço é baseado no entendimento que os

serviços possam interagir. Eles devem estar atentos ao outro. Esta consciência é obtida

através do uso da descrição do serviço.

Como serviços se comunicam

Quando as mensagens são enviadas eles perdem o controle do que acontece depois. Essas

mensagens podem ser equipadas com inteligência suficiente para auto-governar as partes

lógicas do processamento.

Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Esta arquitetura é similar ao passado da arquitetura distribuída que suporta mensagens e

separação de interface de processamento lógico. O que distingue é como esses três

componentes fundamentais (serviço, descrição e mensagem) são projetados. Onde entra a

orientação de serviços.

Como serviços são projetados

8

Serviços podem encapsular a lógica de outros serviços "find-bind-execute"

Acoplamento: busca-se um fraco acoplamento. Contrato de serviço: meio de acesso a esse

serviço. Autonomia: serviços têm controle sobre a lógica que a encapsulam. Abstração: além

do que é descrito no contrato de serviço, serviços escondem a lógica do mundo exterior.

Reusabilidade: a lógica é dividida no serviço com a intenção de reuso. Agregabilidade:

coleções de serviços podem ser coordenados e montados em forma de serviços compostos.

Statelessness: serviços minimizam a retenção da informação em determinada atividade.

Descoberta: serviços são projetados para ser exteriormente descrito, para que possam ser

encontrados e avaliados através de mecanismos de descobertas disponíveis.

Como serviços são construídos A obtenção do SOA não exige serviço web, mas SOA pode

e deve ser realizada através do uso da plataforma de tecnologia de serviço web

9

2.3.SOA Práticas Essenciais

Primeiro: use para minimizar o futuro custo de mudanças em um ou duas áreas críticas.

Segundo: crie um pequeno grupo, um “Centro de Excelência SOA” para liderar esses projetos,

desenvolvendo os conhecimentos necessários e educar todos os envolvidos.

Terceiro: faça com que esse centro colabore com as áreas de negócio para aprender quais são os

problemas mais adequados para resolver.

10

3. Programação Orientada a Aspectos (POA)

O conceito foi criado por Gregor Kiczales e a sua equipe na Xerox PARC, a divisão de

pesquisa da Xerox. Eles desenvolveram o AspectJ, a primeira e mais popular linguagem POA.

Os paradigmas de programação mais antigos, como a programação procedural e

programação orientada a objeto, implementam a separação do código, através de entidades

únicas. Por exemplo, a funcionalidade de log de dados, numa linguagem orientada a objetos, é

implementada em uma única classe, que é referenciada em todos os pontos onde é necessário

fazer log de dados. Como praticamente todo método necessita que alguns dados sejam

registrados em log, as chamadas a essa classe são espalhadas por toda a aplicação.

Tipicamente uma implementação da POA busca encapsular essas chamadas através de uma

nova construção chamada de "aspecto". Um aspecto pode alterar o comportamento de um

código (a parte do programa não orientada a aspectos) pela aplicação de um comportamento

adicional, advice, sobre um "ponto de execução", ou join point. A descrição lógica de um

conjunto de join points é chamada de pointcut.

3.1. Orientação a Aspectos

11

 Todas as aplicações possuem diversas funcionalidades, algumas fazem parte do núcleo

(primárias) e outras dão suporte as funcionalidades presentes no núcleo e geralmente se

repetem em diversos módulos (secundárias). Em uma aplicação comercial as funcionalidades

do núcleo são as regras de negócios e as secundárias são, por exemplo, logging e autorização.

A programação orientada a objetos é a metodologia de programação mais utilizado para

implementar funcionalidades primárias, mas ela não é suficiente para cobrir as funcionalidades

secundárias, especialmente em aplicações complexas. Essas funcionalidades secundárias são

definidas pelo termo crosscuting concerns. A orientação a objetos cria um acoplamento entre

funcionalidades principais e os crosscuting concerns que não é desejado, uma vez que a

adição ou modificação dessas funcionalidades secundárias implicam em mudanças no núcleo

da aplicação.

O acoplamento da regra de negócios com as funcionalidades secundárias, implica em

mudanças no núcleo caso ocorra alguma alteração nas funcionalidades secundárias

AOP é uma nova metodologia que provê a separação dos crosscuting concerns introduzindo

uma nova unidade de modularização, o aspecto. Com AOP você implementa os crosscuting

concerns em aspectos ao invés de mesclá-los nos módulos principais. Os módulos principais e

os secundários são implementados separadamente. Um compilador especial monta o sistema

final combinando os módulos principais e os secundários num processo chamado weaving

(tecelagem), daí dá-se o nome de weaver (tecelão) ao compilador. O resultado é que a AOP

modulariza as funcionalidades secundárias, possibilitando a criação de um sistema que é mais

fácil de implementar e manter.

12

Diferença na construção dos módulos entre Orientação a Objetos e Orientação a Aspectos

A separação dos módulos ainda possibilita a reutilização dos módulos secundários em vários

módulos principais. Os módulos secundários são escritos apenas uma vez, e mesclado

quantas vezes for necessário nos módulos principais. Isso sem nenhuma alteração no núcleo

da aplicação.

Existem várias implementações de AOP para várias linguagens de programação, inclusive em

Java. AspectJ é a implementação AOP para Java mais utilizada e que tem mais suporte, por

isso utilizaremos ela nesse trabalho, além disso a sintaxe estendida do AspectJ o torna uma

das implementações AOP mais poderosas que existe.

13

3.2.Elementos da Orientação a Aspectos.

Assim como na Orientação a objetos, a Orientação a Aspectos possui os seus próprios

conceitos.

Crosscuting concern - é o termo que define partes do sistema que são aplicaveis em vários

locais. Autenticação é uma funcionalidade que aparece em vários módulos do sistema, logo,

autenticação é um crosscuting concern. Crosscuting também é o termo dado ao processo de

adicionar código extra a um determinado módulo.

Weaving - Processo onde é feita a mesclagem dos módulos do sistema de acordo com os

aspectos encontrados. O weaving é como uma outra etapa da compilação. Weaving rules são

as regras que devem ser aplicadas durante essa fase da compilação.

Join point - Um join point (ponto de mesclagem) é um ponto identificável do fluxo de um

programa. Pode ser uma chamada de método ou a configuração do valor de uma variável.

Variadas implementações da orientação a aspectos suportam variados tipos de join point.

Pointcut - Um pointcut é uma construção que seleciona join points. Depois de capturar um join

point é possível especificar as regras de weaving nesses join points, como executar

determinada ação antes ou depois da execução desse join point. Um pointcut pode selecionar

um join point que é uma chamada para um método por exemplo. Pointcuts especificam as

regras de mesclagem (onde devem ser feitas as mesclagens), e join points são as situações

que satisfazem essas regras. Podemos criar um pointcut para todos os métodos chamados

checar, o pointcut definiu a regra: métodos chamados checar. Cada método chamado checar

será um join point desse pointcut.

14

3.3. Aspectos

O aspect (aspecto) é o ponto central da Orientação a Aspectos, assim como uma classe é o

ponto central em orientação a objetos. Nele são declarados e implementados os códigos que

expressam as regras de mesclagem das funcionalidades. Pointcuts, advices, introductions e

declarações são combinadas em aspectos. Além dos elementos da Orientação a Aspecto, um

aspecto também pode conter métodos e variáveis membros assim como nas classes Java.

Existem outras implementações de Orientação a Aspectos para Java que podem não ter a

sintaxe extendida do AspectJ e por isso utiliza classes e métodos normais para criação dos

aspectos, mas ainda assim os conceitos são válidos.

15

3.4.As Vantagens da Orientação Aspecto

A Orientação a Aspectos traz novas dificuldades a programação, mesmo porque é uma nova

metodologia, e tudo que é novo requer um tempo de aprendizado. Mas a Orientação a

Aspectos oferece vantagens que cobrem esse tipo de problema:

Responsabilidades mais transparentes de cada módulo: cada módulo é responsável

apenas pelas tarefas destinadas ao próprio módulo. Os módulo são mais

independentes.

Modularização mais alta: As responsabilidades são melhor definidas em cada módulo,

os módulos tem 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 a

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 modulo 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.

16

4. Conclusão

A Orientação a Aspectos é uma nova metodologia de programação. A Orientação a Aspectos

não é um substituto a orientação a objetos e sim um complemento. Um novo nível de

modularização é alcançado, a diminuição do acoplamento dos módulos possibilita mais

facilidade de manutenção, maior reaproveitamento do código e maior organização do sistema.

Apesar de ser uma nova metodologia a orientação a aspectos já é está madura o suficiente

para ser utilizada na produção de sistemas, já tem documentação e suporte de ferramentas

suficiente. Assim como hoje a orientação a objetos é a maneira mais aceita para

desenvolvimento dos módulos do sistema, a orientação a aspectos será o padrão de integração

desses módulos.

17

5. Bibliografia

Uso de Programação Orientada a Aspecto no Desenvolvimento de Aplicações que utilizam conceitos de Tecnologia Adaptativa

http://lta.poli.usp.br/lta/wta/wta-2012/trabalhos/papers/wta_submission_13

Enciclopedias Wikipédia, a enciclopédia livre.

Programação orientada a seriviço

http://pt.wikipedia.org/wiki/Service-oriented_architecture

Programação orientada aspecto

http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_orientada_a_aspecto

18