UNIVERSIDADE NOVE DE JULHO

Disciplina: Processo de Desenvolvimento de Software

Programao Orientada a Servio e Aspectos

UNINOVE SO PAULO 2013-1

UNIVERSIDADE NOVE DE JULHO

Disciplina: Processo de Desenvolvimento de Software

Programao Orientada a Servio e Aspectos

Trabalho apresentado Universidade Nove de Julho, UNINOVE, em cumprimento parcial s exigncias da disciplina de Processo de Desenvolvimento de Software, sob orientao do Prof. Moises

UNINOVE SO PAULO 2013-1

2

UNIVERSIDADE NOVE DE JULHO

Nomes Armando Lopes da Silva Deivid Moreira Macimo Francisco dos Santos Martins

R.A. 311203263 311205030 311205036

SUMRIO
1. 2. RESUMO ............................................................................................................................................... 5 PROGRAMAO ORIENTADA A SERVIO (SOA) ................................................................................... 6 2.1. DEFINIO .................................................................................................................................... 6 2.2. SOA COMO SERVIOS ENCAPSULAM A LGICA ............................................................................. 7 2.3. SOA PRTICAS ESSENCIAIS ........................................................................................................ 10 3. PROGRAMAO ORIENTADA A ASPECTOS (POA) .............................................................................. 11 3.1. ORIENTAO A ASPECTOS .......................................................................................................... 12 3.2. ELEMENTOS DA ORIENTAO A ASPECTOS. ................................................................................ 14 3.3. ASPECTOS ................................................................................................................................... 15 3.4. AS VANTAGENS DA ORIENTAO ASPECTO ................................................................................ 16 4. CONCLUSO ....................................................................................................................................... 17

1.

RESUMO

Objetivo desta atividade descrever os conceitos sobre (SOA) programao orientada a servio e (POA) programao orienta a aspectos SOA um estilo de arquitetura de software cujo princpio fundamental prega que as funcionalidades implementadas pelas aplicaes devem ser disponibilizadas na forma de servio so conectados atravs de um "barramento de servios" (enterprise service bus, em ingls) que disponibiliza interfaces, ou contratos, acessveis atravs de web services ou outra forma de comunicao entre aplicaes. A arquitetura SOA baseada nos princpios da computao distribuda e utiliza o paradigma request/reply para estabelecer a comunicao entre os sistemas clientes e os sistemas que implementam os servios.

2.

Programao Orientada a Servio (SOA)

2.1. Definio
Programao orientada a servio (SOA) um conceito de arquitetura corporativo, que nos permite criar, padronizar, documentar servios genricos, nicos e interoperveis, que possam de maneira fcil, ser reutilizados por diversas aplicaes diferentes, sem a necessidade de ser desenvolvido novamente, tornando o processo de desenvolvimento mais gil. O SOA coloca a prestao de servio como eixo de todo o negcio, dando destaque gesto de servios e ao cliente. Servio uma uma funo independente, sem estado (stateless) que aceita uma ou mais requisies e devolve uma ou mais respostas atravs de uma interface padronizada e bem definida. Servios podem tambm realizar partes discretas de um processo tal como editar ou processar uma transao. Servios no devem depender do estado de outras funes ou processos. A tecnologia utilizada para prover o servio, tal como uma linguagem de programao, no pode fazer parte da definio do servio. Orquestrao - Processo de sequenciar servios e prover uma lgica adicional para processar dados. No inclui uma representao de dados. Stateless - No depende de nenhuma condio pr-existente. Os servios no devem depender de condies de outros servios. Eles recebem todas as informaes necessrias para prover uma resposta consistente. O objetivo de buscar a caracterstica de stateless dos servios possibilitar que o consumidor do servio possa sequenci-lo, ou seja, orquestr-los em vrios fluxos (algumas vezes chamados de pipelines) para executar a lgica de uma aplicao. Provedor O recurso que executa o servio em resposta a uma requisio de um consumidor. Consumidor quem consome ou pede o resultado de um servio fornecido por um provedor. Descoberta SOA se baseia na capacidade de identificar servios e suas caractersticas. Consequentemente, esta arquitetura depende de um diretrio que descreva quais os servios disponveis dentro de um domnio. Binding A relao entre os servios do provedor e do consumidor deve ser idealmente dinmica, ela estabelecida em tempo de execuo atravs de um mecanismo de binding.

2.2. SOA Como servios encapsulam a lgica

Pode ser em contextos distintos. Estes contextos podem ser especficos para uma tarefa de negcio, entidades de negcio e outros agrupamentos de negcio.

Servios podem encapsular a lgica de outros servios "find-bind-execute" Na figura, quando construmos uma soluo consistente de servio, cada servio pode encapsular a tarefa realizada por um passo individual ou um sub-processo composto de um conjunto de passos. Um servio pode encapsular toda a lgica do processo. O ltimo caso representado pelo servio pode englobar a lgica encapsulada de outros servios. Como servios so relacionados

Servios podem encapsular a lgica de outros servios "find-bind-execute" 7

Dentro do SOA servios podem ser usados por outros servios ou por outros programas. Independentemente, o relacionamento por trs do servio baseado no entendimento que os servios possam interagir. Eles devem estar atentos ao outro. Esta conscincia obtida atravs do uso da descrio do servio. Como servios se comunicam Quando as mensagens so enviadas eles perdem o controle do que acontece depois. Essas mensagens podem ser equipadas com inteligncia suficiente para auto-governar as partes lgicas do processamento.

Servios podem encapsular a lgica de outros servios "find-bind-execute" Esta arquitetura similar ao passado da arquitetura distribuda que suporta mensagens e separao de interface de processamento lgico. O que distingue como esses trs componentes fundamentais (servio, descrio e mensagem) so projetados. Onde entra a orientao de servios. Como servios so projetados

Servios podem encapsular a lgica de outros servios "find-bind-execute" Acoplamento: busca-se um fraco acoplamento. Contrato de servio: meio de acesso a esse servio. Autonomia: servios tm controle sobre a lgica que a encapsulam. Abstrao: alm do que descrito no contrato de servio, servios escondem a lgica do mundo exterior. Reusabilidade: a lgica dividida no servio com a inteno de reuso. Agregabilidade: colees de servios podem ser coordenados e montados em forma de servios compostos. Statelessness: servios minimizam a reteno da informao em determinada atividade. Descoberta: servios so projetados para ser exteriormente descrito, para que possam ser encontrados e avaliados atravs de mecanismos de descobertas disponveis. Como servios so construdos A obteno do SOA no exige servio web, mas SOA pode e deve ser realizada atravs do uso da plataforma de tecnologia de servio web

2.3. SOA Prticas Essenciais

Primeiro: use para minimizar o futuro custo de mudanas em um ou duas reas crticas. Segundo: crie um pequeno grupo, um Centro de Excelncia SOA para liderar esses projetos, desenvolvendo os conhecimentos necessrios e educar todos os envolvidos. Terceiro: faa com que esse centro colabore com as reas de negcio para aprender quais so os problemas mais adequados para resolver.

10

3. Programao Orientada a Aspectos (POA)

O conceito foi criado por pesquisa da POA. Os paradigmas de programao mais antigos, como a

Gregor Kiczales e a sua equipe na Xerox PARC, a diviso de

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

programao procedural e

programao orientada a objeto, implementam a separao do cdigo, atravs 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 necessrio fazer log de dados. Como praticamente todo mtodo necessita que alguns dados sejam registrados em log, as chamadas a essa classe so espalhadas por toda a aplicao. Tipicamente uma implementao da POA busca encapsular essas chamadas atravs de uma nova construo chamada de "aspecto". Um aspecto pode alterar o comportamento de um cdigo (a parte do programa no orientada a aspectos) pela aplicao de um comportamento adicional, advice, sobre um "ponto de execuo", ou join point. A descrio lgica de um conjunto de join points chamada de pointcut.

11

3.1. Orientao a Aspectos

Todas as aplicaes possuem diversas funcionalidades, algumas fazem parte do ncleo (primrias) e outras do suporte as funcionalidades presentes no ncleo e geralmente se repetem em diversos mdulos (secundrias). Em uma aplicao comercial as funcionalidades do ncleo so as regras de negcios e as secundrias so, por exemplo, logging e autorizao. A programao orientada a objetos a metodologia de programao mais utilizado para implementar funcionalidades primrias, mas ela no suficiente para cobrir as funcionalidades secundrias, especialmente em aplicaes complexas. Essas funcionalidades secundrias so definidas pelo termo crosscuting concerns. A orientao a objetos cria um acoplamento entre funcionalidades principais e os crosscuting concerns que no desejado, uma vez que a adio ou modificao dessas funcionalidades secundrias implicam em mudanas no ncleo da aplicao.

O acoplamento da regra de negcios com as funcionalidades secundrias, implica em mudanas no ncleo caso ocorra alguma alterao nas funcionalidades secundrias AOP uma nova metodologia que prov a separao dos crosscuting concerns introduzindo uma nova unidade de modularizao, o aspecto. Com AOP voc implementa os crosscuting concerns em aspectos ao invs de mescl-los nos mdulos principais. Os mdulos principais e os secundrios so implementados separadamente. Um compilador especial monta o sistema final combinando os mdulos principais e os secundrios num processo chamado weaving (tecelagem), da d-se o nome de weaver (tecelo) ao compilador. O resultado que a AOP modulariza as funcionalidades secundrias, possibilitando a criao de um sistema que mais fcil de implementar e manter.

12

Diferena na construo dos mdulos entre Orientao a Objetos e Orientao a Aspectos

A separao dos mdulos ainda possibilita a reutilizao dos mdulos secundrios em vrios mdulos principais. Os mdulos secundrios so escritos apenas uma vez, e mesclado quantas vezes for necessrio nos mdulos principais. Isso sem nenhuma alterao no ncleo da aplicao. Existem vrias implementaes de AOP para vrias linguagens de programao, inclusive em Java. AspectJ a implementao AOP para Java mais utilizada e que tem mais suporte, por isso utilizaremos ela nesse trabalho, alm disso a sintaxe estendida do AspectJ o torna uma das implementaes AOP mais poderosas que existe.

13

3.2. Elementos da Orientao a Aspectos.

Assim como na Orientao a objetos, a Orientao a Aspectos possui os seus prprios conceitos. Crosscuting concern - o termo que define partes do sistema que so aplicaveis em vrios locais. Autenticao uma funcionalidade que aparece em vrios mdulos do sistema, logo, autenticao um crosscuting concern. Crosscuting tambm o termo dado ao processo de adicionar cdigo extra a um determinado mdulo. Weaving - Processo onde feita a mesclagem dos mdulos do sistema de acordo com os aspectos encontrados. O weaving como uma outra etapa da compilao. Weaving rules so as regras que devem ser aplicadas durante essa fase da compilao. Join point - Um join point (ponto de mesclagem) um ponto identificvel do fluxo de um programa. Pode ser uma chamada de mtodo ou a configurao do valor de uma varivel. Variadas implementaes da orientao a aspectos suportam variados tipos de join point. Pointcut - Um pointcut uma construo que seleciona join points. Depois de capturar um join point possvel especificar as regras de weaving nesses join points, como executar determinada ao antes ou depois da execuo desse join point. Um pointcut pode selecionar um join point que uma chamada para um mtodo por exemplo. Pointcuts especificam as regras de mesclagem (onde devem ser feitas as mesclagens), e join points so as situaes que satisfazem essas regras. Podemos criar um pointcut para todos os mtodos chamados checar, o pointcut definiu a regra: mtodos chamados checar. Cada mtodo chamado checar ser um join point desse pointcut.

14

3.3. Aspectos
O aspect (aspecto) o ponto central da Orientao a Aspectos, assim como uma classe o ponto central em orientao a objetos. Nele so declarados e implementados os cdigos que expressam as regras de mesclagem das funcionalidades. Pointcuts, advices, introductions e declaraes so combinadas em aspectos. Alm dos elementos da Orientao a Aspecto, um aspecto tambm pode conter mtodos e variveis membros assim como nas classes Java. Existem outras implementaes de Orientao a Aspectos para Java que podem no ter a sintaxe extendida do AspectJ e por isso utiliza classes e mtodos normais para criao dos aspectos, mas ainda assim os conceitos so vlidos.

15

3.4. As Vantagens da Orientao Aspecto

A Orientao a Aspectos traz novas dificuldades a programao, mesmo porque uma nova metodologia, e tudo que novo requer um tempo de aprendizado. Mas a Orientao a Aspectos oferece vantagens que cobrem esse tipo de problema: Responsabilidades mais transparentes de cada mdulo: cada mdulo responsvel apenas pelas tarefas destinadas ao prprio mdulo. Os mdulo so mais independentes. Modularizao mais alta: As responsabilidades so melhor definidas em cada mdulo, os mdulos tem baixo acoplamento entre si. Evoluo do sistema mais facilitada: O baixo acoplamento possibilita que alteraes no sistema sejam feitas sem alterao do ncleo. Decises de design podem ser tomadas com mais atraso: Devido ao baixo acoplamento no necessrio pensar em todos os problemas no incio do desenvolvimento do sistema. Mais reusabilidade do cdigo: Os mdulos podem ser mais reaproveitados devido a alta coeso e baixo acoplamento. Sistemas mais fceis de desenvolver e manter: Os aspectos tornam a integrao das partes do sistema um modulo separado, o que traz mais facilidade no desenvolvimento. Custos reduzidos de introduo de novas funcionalidades: Novas funcionalidades podem ser introduzidas criando aspectos, no sendo necessrio alterar o ncleo para adicionar tais funcionalidades.

16

4. Concluso

A Orientao a Aspectos uma nova metodologia de programao. A Orientao a Aspectos no um substituto a orientao a objetos e sim um complemento. Um novo nvel de modularizao alcanado, a diminuio do acoplamento dos mdulos possibilita mais facilidade de manuteno, maior reaproveitamento do cdigo e maior organizao do sistema. Apesar de ser uma nova metodologia a orientao a aspectos j est madura o suficiente para ser utilizada na produo de sistemas, j tem documentao e suporte de ferramentas suficiente. Assim como hoje a orientao a objetos a maneira mais aceita para desenvolvimento dos mdulos do sistema, a orientao a aspectos ser o padro de integrao desses mdulos.

17

5. Bibliografia

Uso de Programao Orientada a Aspecto no Desenvolvimento de Aplicaes que utilizam conceitos de Tecnologia Adaptativa http://lta.poli.usp.br/lta/wta/wta-2012/trabalhos/papers/wta_submission_13 Enciclopedias Wikipdia, a enciclopdia livre. Programao orientada a serivio http://pt.wikipedia.org/wiki/Service-oriented_architecture Programao orientada aspecto http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_orientada_a_aspecto

18