Faculdade de Tecnologia de So Paulo

Autora: Dbora Momono Alves Kuroiwa

Reflexes sobre a Arquitetura Orientada a Servio e

o Surgimento de uma Nova Disciplina, a Engenharia
de Software de Servio.

So Paulo
2011

Faculdade de Tecnologia de So Paulo

Autora: Dbora Momono Alves Kuroiwa

Reflexes sobre a Arquitetura Orientada a Servio e

o Surgimento de uma Nova Disciplina, a Engenharia
de Software de Servio.

Monografia submetida como exigncia parcial para obteno

do Grau de Tecnlogo em Processamento de Dados

Orientador: Prof. Mrcia Ito

So Paulo
2011

Dedicatria
minha famlia.

Agradecimentos
Agradeo a Deus pelas pessoas que colocou em meu caminho para
que me guiassem. minha orientadora, Prof Marcia Ito, pela
pacincia. minha famlia, pelo carinho e apoio.

RESUMO
Com a crescente competitividade do mercado econmico, as empresas depararam-se com a
necessidade de (re-) adequao de seus processos de Negcio, visando tornarem-se mais
produtivas e lucrativas. Considerando TI como um dos pilares das empresas para produo de
respostas s demandas do mercado, as empresas passam a demandar que TI apresente um alto
grau de alinhamento Negcio-TI e flexibilidade no desenvolvimento de seus sistemas. Essas
caractersticas so observadas em um paradigma de arquitetura conhecido como Arquitetura
Orientada a Servio, porm que apresenta alto grau de complexidade em sua concepo. A
Engenharia de Software de Servio surge como uma proposta de disciplina complementar
Engenharia de Software Tradicional, apresentando princpios que visam suportar o
desenvolvimento de sistemas construdos com base na Arquitetura Orientada a Servio,
permitindo melhor aproveitamento das caractersticas oferecidas por esse paradigma de
arquitetura e, consequentemente, gerando os resultados esperados pelas empresas.

ABSTRACT
With the increasing competitiveness of the economic market, business were faced with the
need to (re-) adequacy of its business processes in order to become more productive and
profitable. Considering IT as a pillar of the companies to produce responses to market
demands, companies are demanding that IT provides a high degree of IT-Business alignment
and flexibility in developing their systems. These characteristics are observed in an
architectural paradigm known as Service Oriented Architecture, but it has a high degree of
complexity in its design. The Software Service Engineering emerges as a proposal of
complementary discipline to traditional software engineering, presenting principles that aim to
support the development of systems built on Service Oriented Architecture, enabling better
use of the features offered by this paradigm of architecture and, thus, generating the results
expected by the companies.

LISTA DE ILUSTRAES
Pg.
Figura 2.1 Resumo dos princpios SOA

19

Figura 2.2 Aplicaes em camadas lgicas, sem implementao

da Arquitetura Orientada a Servio.

23

Figura 2.3 Aplicaes baseadas na Arquitetura Orientada a Servio.

24

Figura 3.1 Processo de Engenharia de Servio

28

Figura 3.2 Construo de Servio por Composio

30

LISTA DE SIGLAS
SOA

Service-Oriented Architecture1

TI

Tecnologia da Informao

ESB

Enterprise Service Bus2

BPM

Business Process Management3

OO

Object Oriented4

CBD

Component-Based Development5

Arquitetura Orientada a Servio.

Barramento Empresarial de Servio.
3
Gerenciamento de Processo de Negcio
4
Orientao a Objeto
5
Desenvolvimento Baseado em Componente
2

SUMRIO
1. Introduo ..................................................................................................................10
1.1. Objetivo.................................................................................................................11
1.2. Justificativa ...........................................................................................................11
1.3. Mtodo de Pesquisa ..............................................................................................12
1.4. Organizao do Trabalho ......................................................................................12
2. Arquitetura Orientada a Servio .............................................................................14
2.1. Conceitos...............................................................................................................14
2.2. Benefcios .............................................................................................................17
2.3. Desafios.................................................................................................................18
2.4. Aplicao ..............................................................................................................19
3. Engenharia de Software de Servio .........................................................................22
3.1. Princpios ..............................................................................................................22
3.2. Desafios.................................................................................................................24
3.3. Engenharia de Software de Servio x Engenharia de Software Tradicional ........25
3.4. Processo de Engenharia de Servio ......................................................................26
4. Concluso ...................................................................................................................28
5. Referncias Bibliogrficas ........................................................................................29

10

1. Introduo

Ao longo da histria, o mundo atravessou diversas transformaes tecnolgicas e

econmicas que promoveram constantes avanos nos processos produtivos, focando no
aumento da produtividade e lucratividade.
Em meados do sculo XVIII, inicia-se a Era Industrial, que se estendeu por dois
sculos (1750 1950), onde comearam as maiores transformaes tecnolgicas, com o
surgimento da mquina a vapor, o telgrafo e, posteriormente, a inveno do automvel, o
rdio, a televiso, entre outros.
A Era Industrial seguida pela Era da Informao, aps a Segunda Guerra Mundial,
quando surgiram tecnologias que promoveram o aumento na comunicao mundial, e onde o
mercado passou a se concentrar no mais na produo agrcola, artesanal ou industrial, mas
sim na produo da informao. (LUCCI, 2008).
Todas essas transformaes mantiveram o foco no aumento da produtividade, e para
se manterem competitivas, as empresas continuamente ampliam seu mercado focando no
apenas no bem produzido, mas tambm no servio a ele agregado, tornando, desta forma, o
mercado ainda mais desafiador. Considerando isto, a informatizao da empresa constitui um
dos pilares fundamentais para a produo de respostas da empresa ao mercado, permitindo a
inovao e sustentao em novos produtos e servios, por meio de integraes entre sistemas
de empresas parceiras, fornecedores, governo entre outros.
Tem-se ento, um grande desafio: Como a rea de TI conseguir suportar
continuamente a produo de respostas, com agilidade, ao mercado cada vez mais dinmico e
desafiador?
Diante desse contexto, tornou-se cada vez mais evidente a necessidade de sistemas
mais flexveis, aderentes e de fcil e rpida adaptao aos processos de negcio. Surge ento
um novo paradigma de arquitetura de software, baseado no conceito de Servio, e que tem
como principais caractersticas o baixo acoplamento, dinamismo e adaptabilidade, a
reutilizao de servios, interoperabilidade e a independncia de Tecnologia: Arquitetura
Orientada a Servio.
Porm, a utilizao desse novo paradigma pelas empresas ainda considerada
precoce e, em virtude das caractersticas de sistemas SOA (Service Oriented Architecture
Arquitetura Orientada a Servio) citadas acima, a utilizao de princpios e tcnicas da

11
Engenharia de Software tradicional tem-se mostrado limitadas para o seu desenvolvimento.
(HEUVEL et al., 2009).

With SOA systems operating in distributed and heterogeneous execution

environments, the engineers of such systems are confined by the limits of traditional
software engineering [...]6. (HEUVELet al., 2009, p.26)

Comea-se ento a discutir a Engenharia de Software de Servio como uma disciplina

emergente que envolve parte da Engenharia de Software Tradicional e introduz outros novos
conceitos para o desenvolvimento de sistemas baseados em SOA. (HEUVEL et al., 2009).

1.1. Objetivo

O objetivo desse trabalho discutir sobre a utilizao da Arquitetura Orientada a

Servio (SOA Service Oriented Architecture) como principal paradigma emergente de
arquitetura de software, focando na Engenharia de Software de Servio como nova rea do
conhecimento no desenvolvimento de sistemas, relacionando sua necessidade e desafios.

1.2. Justificativa

A discusso sobre o tema Engenharia de Software de Servio foi incentivada pela

repercusso a respeito da utilizao da Arquitetura Orientada Servio, que apresenta muitas
vantagens (e desafios) em sua aplicao, porm, ainda necessita de metodologia que norteie o
desenvolvimento de sistemas baseados neste paradigma de arquitetura, uma vez que a
Engenharia de Software Tradicional apresenta-se muito limitada para esse tipo de arquitetura.

Com sistemas SOA operando em ambiente de execuo distribudo e heterogneo, os engenheiros de tais
sistemas so confinados pelos limites da engenharia de software tradicional [...] Em particular, ns introduzimos
a engenharia de software de servio com uma disciplina emergente que envolve parte das disciplinas da
engenharia de software tradicional, adotando o pressuposto do mundo aberto.

12
Service Oriented Architecture (SOA) is rapidly emerging as a premier distributed
computing paradigma for developing, integrating, and maintaining enterprise
applications. Many organizations are now in their
early use of SOA, and assume that they can simply apply principles and techniques
from pre-existing software engineering paradigms [...]. SOA-enabled applications
operate in distributed, non-deterministic, unpredictable, and highly dynamic
heterogeneous execution environments; hence, SOA engineers quickly encounter the
limits of such traditional software engineering paradigms, which do not provide any
style-specific advice.

(HEUVEL; ZIMMERMANN; LEYMANN; PATRICIA

LAGO; SCHIEFERDECKER; ZDUN; AVGERIOU, 2009, p.26)

1.3. Mtodo de Pesquisa

O trabalho apresentado foi desenvolvido por meio de levantamentos bibliogrficos e

artigos cientficos.

1.4. Organizao do Trabalho

No Captulo 1 apresentada uma introduo contendo o contexto histrico e atual que

fomentou o surgimento da Arquitetura Orientada a Servio. Apresenta tambm o objetivo do
trabalho, sua justificativa e o resultado que se espera atingir.
O Captulo 2 apresenta os conceitos da Arquitetura Orientada a Servio, vantagens e
desafios deste novo paradigma de arquitetura.

Arquitetura Orientada a Servio (AOS) est rapidamente emergindo como principal paradigma de
computao distribuda para o desenvolvimento, integrao e manuteno de aplicaes corporativas. Muitas
organizaes esto agora em seu uso precoce de SOA, e assumem que eles podem simplesmente aplicar
princpios e tcnicas dos paradigmas pr-existentes da engenharia de software [...]. Apliaes habilitadas
SOA operam em ambientes de execuo heterogneos, distribudos, no-deterministas, imprevisveis
e altamente dinmicos, portanto, engenheiros SOA rapidamente encontram os limites de tais paradigmas da
engenharia de software tradicional, que no fornecem qualquer conselho de estilo especfico.

13
O Captulo 3 introduz o conceito de Engenharia de Software de Servio, uma breve
comparao com a Engenharia de Software Tradicional e tambm sua aplicao no
desenvolvimento de sistemas baseados em SOA8.
No Captulo 4 apresentada a Concluso do trabalho.

Software Oriented Architecture Arquitetura Orientada a Servio

14

2. Arquitetura Orientada a Servio

A Arquitetura Orientada a Servio desponta como uma aposta de arquitetura para

utilizao, principalmente empresarial, no desenvolvimento de softwares, pois com o
crescimento do mercado e o aumento da competitividade, os processos de negcios tm-se
tornado cada vez mais dinmicos, desta forma demandando que o desenvolvimento e
manuteno de sistemas de software empresariais respondam com a mesma velocidade.
Os paradigmas de arquitetura adotados at ento, se apresentaram pouco flexveis ao
dinamismo exigido pelos negcios.
Os sistemas tradicionais cliente servidor sempre focaram a interao com o usurio,
e os dados de forma centralizada o que tornava difcil qualquer mudana estrutural
pelo fato de exigir um grande esforo, at mesmo nas novas aplicaes clientes.
(COSTA; CARVALHO NETO, 2007, p.02).

Pela dificuldade de adapt-las ou reorganiz-las, vemos que as aplicaes acabam

sendo um empecilho no caminho das mudanas ou movimentos estratgicos das
corporaes. (TAURION, 2009, p.06).

SOA passa, ento, a ser fortemente adotada por sua principal caracterstica de
promover o alinhamento entre Negcio e TI9 (BIEBERSTEIN et al., 2008).

2.1. Conceitos

Diversas definies para SOA so encontradas em livros acadmicos e sites: j a

definiram como uma nova tecnologia, framework, metodologia, outros como um produto,
soluo de negcio, e assim por diante.
Neste trabalho, a definio adotada a que apresenta SOA como um estilo de
arquitetura: SOA um paradigma de arquitetura, baseada no conceito de Servio, que
promove o alinhamento entre TI e Negcio. Esse paradigma de arquitetura visa possibilitar

Tecnologia da Informao

15
maior agilidade para atender s demandas empresariais, flexibilidade para responder s
mudanas, trazendo reduo de custos empresa e possibilitando a reutilizao e (re-)
combinao dos servios. (SANTOS, 2009).
Segundo Santos (2009), Servio pode ser definido como um componente que atende a
uma funo de negcio.

Servio um componente que atende a uma funo de negcio (business function).

Ele pode receber e responder requisies ocultando os detalhes de sua
implementao. (SANTOS, 2009, p.25).

Os servios em SOA apresentam as seguintes caractersticas:

I.

Contrato de Servio padronizado:

O contrato especifica o que o servio faz e qual o procedimento para utiliz-lo.

(Exemplo. O contrato dos webservices so os WSDLs, onde esto declarados os mtodos e

a forma como o servio deve ser invocado);

II.

Autonomia e Baixo Acoplamento:

Servios devem ser autnomos e com baixo acoplamento, ou seja, no devem ter

dependncias funcionais e/ou tcnicas.

For services to carry out their capabilities consistently and reliably, their underlying
solution logic needs to have a significant degree of control over its environment and
resources.10 (ERL, 2011)

Segundo Evdemon (2005), servios devem ser projetados e implantados sem

dependncias de outros servios, e se comunicam por meio de mensagens controladas
(especificadas) por contrato.
O baixo acoplamento visa reduzir impactos nos servios quando necessria a
manuteno corretiva ou evolutiva de um determinado servio (JOSUTTIS, 2007).

10

Para que servios realizem suas capacidades consistente e confiavelmente, sua soluo lgica precisa ter um
grau significativo de controle sobre seu ambiente e recursos.

16
III.

Abstrao:
Servios devem ocultar detalhes de sua implementao, praticando o conceito de

caixa-preta, que prega que para uso e reuso de um servio no necessrio conhecer
detalhes alm do que especificado no contrato de servio. (MACHADO, 2004)
On a fundamental level, this principle emphasizes the need to hide as much of the
underlying details of a service as possible.11 (ERL, 2011)

IV.

Granularidade e Reutilizao:
A granularidade do servio pode ser definida como grossa ou fina, dependendo do

nvel de detalhe do servio. Quanto maior o nvel de detalhe, mais fina a granularidade do
servio (SANTOS, 2009).
Conforme definido anteriormente, Servio representa um componente que atende a
uma funo de negcio e, considerando esta definio, os servios devem apresentar a
granularidade de uma funo de negcio, porm implementando granularidade grossa, que
proporcionar assim, a reutilizao desse servio em n processos do negcio (FURTADO et
al., 2009).

V.

Componibilidade:
Segundo Thomas Erl (2011), servios devem ser capazes de participar como membros

efetivos na composio.

VI.

Estado:
Servios apenas mantm-se stateful12 quando necessrio, visando no comprometer

sua disponibilidade e seu potencial de escalabilidade (ERL, 2011).

VII.

Descoberta:
Servios devem ser facilmente identificados e interpretados medida que as

oportunidades de reuso se apresentam (ERL, 2011).

11

Em um nvel fundamental, este princpio enfatiza a necessidade de esconder os detalhes subjacentes do servio
o tanto quanto possvel.
12
Stateful Capacidade de manter estado, ou seja, de armazenar informaes na sesso entre chamadas.

17
VIII.

Interoperabilidade:
A interoperabilidade considerada por Thomas Erl (2011) como fundamental para

cada um dos princpios listados, medida que cada um dos princpios contribui de alguma
maneira para a interoperabilidade.
Este princpio trata da necessidade de integrar diferentes sistemas por meio dos
servios, independente dos ambientes em que tais sistemas operam ou linguagens de
programao utilizadas na sua construo.
A seguir, ilustrao que resume os princpios de SOA:

Figura 2.1 Resumo dos princpios SOA

Fonte: Adaptado de http://www.slideshare.net/Ridlo/soa-fundamentos

2.2. Benefcios

Como dito anteriormente, a adoo desse paradigma de arquitetura visa proporcionar

maior alinhamento entre Negcio e TI trazendo benefcios considerveis s empresas.

18
Sistemas baseados na Arquitetura Orientada a Servio possuem procedimentos mais
geis de evoluo e manuteno, pois implementam Servios e suas caractersticas que
proporcionam flexibilidade, como a componibilidade e a reutilizao, possibilitando que TI
responda s mudanas do negcio na velocidade desejada. Alm disso, proporcionam:

I.

Integrao ente sistemas:

Devida s caractersticas de Interoperabilidade, Baixo Acoplamento e Contratos

padronizados, sistemas construdos em diferentes linguagens e que executam em diferentes

ambientes de execuo conseguem se comunicar, ou seja, tais caractersticas promovem a
integrao entre sistemas, desta forma tornam geis os processos de negcios entre os
diversos departamentos da empresa, entre fornecedores, parceiros e governo.

II.

Reduo de custos:
Pelas caractersticas de Reutilizao, Autonomia, Baixo Acoplamento, Abstrao e

Estado, a Arquitetura Orientada a Servio pode proporcionar a reduo de custos da empresa

com a manuteno de sistemas e at mesmo em novos desenvolvimentos.
Por exemplo, com servios implementando as caractersticas de baixo acoplamento,
autonomia e abstrao, a manuteno de determinado servio no dever gerar impactos
aos consumidores de tais servios, reduzindo desta forma os custos para manutenes em
cadeia. No caso da caracterstica estado, traz reduo nos recursos de hardware, medida
que reduz o consumo de memria.
Alm disso, segundo Gouveia e Gouveia (2011), gera reduo de custos medida que
otimiza a comunicao entre tcnicos e utilizadores de negcio, o time-to-market e o retorno
sobre o investimento dos projetos.

2.3. Desafios

A implantao da SOA, porm, tem encontrado em suas prprias caractersticas seus

maiores desafios, o desenvolvimento de Servios se torna muito complexo.
Os seguintes desafios so listados por Gouveia e Gouveia (2011):

19
I.

Segurana
Devida caracterstica da Interoperabilidade, os sistemas ficam mais vulnerveis a

ameaas externas.

II.

Rastreabilidade
Pela capacidade de composio dos servios, aumenta a necessidade de

monitoramento e rastreabilidade.

III.

Disponibilidade da Informao em Tempo Real

Devido ao baixo acoplamento, SOA melhor adequa-se a sistemas que no demandam

respostas em tempo real.

IV.

Competncias e experincia na Implementao SOA

Processos e padres de implementao SOA ainda encontram-se em nvel baixo de

maturidade e experincia.

V.

Custo Alto investimento inicial

A implantao da SOA nas empresas gera um alto investimento inicial, considerando

o lento processo de reengenharia das arquiteturas existentes, que requer recursos humanos e
financeiros.

2.4. Aplicao

Aplicaes desenvolvidas em SOA so baseadas em princpios como local, protocolo

e independncia de plataforma tecnolgica. Tambm so baseadas em padres como contrato
de servio, composio de servio, ESB13 e registro de Servio (HEUVEL et al., 2009):

I.

13

Protocolo: Utilizao de protocolos de comunicao.

ESB Enterprise Service Bus: Barramento de Servio Empresarial

20
II.

Enterprise Service Bus (ESB): Camada de integrao que permite a troca de

mensagens entre os consumidores e os provedores de servios (HEUVEL et al., 2009).

III.

Registro de Servio: Diretrio de provedores de servios disponveis (HEUVEL et al.,

2009).

A seguir, ilustraes de aplicaes que no se baseiam em SOA (Figura 2) em

comparao a aplicaes baseadas em SOA (Figura 3):

Figura 2.2 Aplicaes em camadas lgicas, sem implementao da Arquitetura

Orientada a Servio.
Fonte: http://www.slideshare.net/Ridlo/soa-fundamentos

Cada aplicao acima, independente da rea de negcio, implementa o seu acesso e

integrao aos sistemas da empresa e bases de dados. Com isso, para uma mesma
necessidade, existem diversas aplicaes desenvolvidas, o que gera redundncia, aumenta o
risco, a complexidade e o custo na manuteno das aplicaes.

21

Figura 2.3 Aplicaes baseadas na Arquitetura Orientada a Servio.

Fonte: http://www.slideshare.net/Ridlo/soa-fundamentos

Nessa viso acima, as aplicaes se comunicam com os diversos sistemas da empresa

por meio do ESB (Enterprise Service Bus) como camada de integrao, tambm responsvel
por coordenar os processos e servios.
A gesto dos processos de Negcio (Business Process Management) deve ser realizada
entre Negcio e TI, a fim de realizar a identificao e definio dos servios bem como a
composio dos fluxos de negcio, promovendo a implementao de SOA de forma adequada
s reais necessidades da empresa.
SOA, ento uma evoluo dos paradigmas de arquitetura existentes at o momento.
SOA combina elementos de vrias disciplinas, tais como modelagem e gesto de
processos de Negcio (BPM), Arquitetura de Software, CBD14, OO15, EAI16, computao
distribuda e gesto de sistemas. (HEUVEL et al., 2009)

14

Component-Based Development Desenvolvimento Baseado em Componente

Object Oriented Orientao a Objeto Paradigma de desenvolvimento baseado no conceito de Objeto.
16
Enterprise Application Integration Integrao de Aplicao Empresariais
15

22

3. Engenharia de Software de Servio

Diante de tantas vantagens proporcionadas pela Arquitetura Orientada a Servio, surge

a necessidade de revisitar os mtodos e ferramentas utilizadas para o desenvolvimento de
sistemas baseados em servios, uma vez que a Engenharia de Software Tradicional no
consegue atender s peculiaridades de tais sistemas: passa-se ento a discutir respeito da
Engenharia de Software de Servios.
A Engenharia de Software de Servio tem seus primeiros relatos em meados de 2009
em um seminrio, e definida a seguir:
Software service engineering is the science and application of concepts, models,
methods, and tools to design, develop (source), deploy, test, provision, and maintain
business-aligned and SOA-based software systems in a disciplined, reproducible,
and repeatable manner. 17
(HEUVEL;

ZIMMERMANN;

LEYMANN;

PATRICIA

LAGO;

SCHIEFERDECKER; ZDUN; AVGERIOU, 2009, p.32)

3.1. Princpios

A Engenharia de Software de Servio procura aplicar o Pressuposto do Mundo

Aberto18, e inicialmente apresenta sete princpios, listados a seguir:

I.

Federao Tcnica:
As vantagens proporcionadas pela Arquitetura Orientada a Servio trazem consigo um
aumento na complexidade tcnica no desenvolvimento de sistemas. Com isso, o princpio da
Federao Tcnica prega que a Engenharia de Software de Servio deve fornecer aos

17

Engenharia de Software de Servio a cincia e aplicao de conceitos, modelos, mtodos e ferramentas para
projetar, desenvolver (fonte), implantar, testar, fornecer e manter sistemas de software alinhados ao negcio e
baseados em SOA de forma disciplinada, reprodutvel e repetveis.
18
Pressuposto do Mundo Aberto Tudo verdadeiro (possvel), a menos que seja provado como falso. No caso
da Engenharia de Software de Servio, o Pressuposto do Mundo Aberto implica que essa nova disciplina no
est fechada, desta forma, no possvel afirmar como no verdadeiro qualquer outro princpio que venha a ser
levantado.

23
arquitetos e engenheiros de servio, conceitos, linguagens, mtodos e ferramentas que os
ajudem a gerenciar o aumento de tal complexidade tcnica. (HEUVEL et al., 2009)

II.

Dinamismo (Virtualizao):
O Dinamismo um dos princpios fundamentais da SSE19 com relao aos servios
que so agregados na composio de servio em tempo de execuo, bem como o contexto
altamente voltil em que os servios operam. Desta maneira, o princpio dinamismo implica
que os mtodos, tcnicas e ferramentas devem lidar com propriedades emergentes e
comportamento complexo. (HEUVEL et al., 2009)

III.

Federao Organizacional:
A Engenharia de Software de Servio deve considerar que o desenvolvimento e
manuteno de sistemas so, muitas vezes, realizados em unidades organizacionais
distribudas, envolvendo diversas linhas de negcio, outras empresas e instituies
governamentais. Considerando isso, o princpio de Federao Organizacional demanda
mecanismos slidos de Governana Distribuda, a fim de gerenciar por exemplo, dificuldade
de controle de versionamento de servios compartilhados por vrios consumidores em
diferentes domnios organizacionais. (HEUVEL et al., 2009)

IV.

Limites Explcitos (Contratos):

Servios devem possuir limites claros por meio de seu contrato. Quanto mais ricas so
as interfaces com cenrios e comportamentos, mais robusta e estvel ser a composio de
servios. (HEUVEL et al., 2009)

V.

Heterogeneidade:
As tcnicas, mtodos e ferramentas da Engenharia de Software de Servio devem
abranger o princpio da heterogeneidade dos servios, uma vez que deve considerar a
infraestrutura e o contexto em que sistemas baseados em SOA operam. A heterogeneidade
deve ser considerada em todas as fases do ciclo de vida do desenvolvimento dos servios, pois
pode levantar restries sobre como os servios devem ser concebidos e construdos, uma vez
que se comunicaro com servios desenvolvidos em diferentes paradigmas e que operam em
diferentes plataformas. (HEUVEL et al., 2009)
19

Software Service Engeneering Engenharia de Software de Servio

24
VI.

Alinhamento entre Negcio-TI:

Considerando as caractersticas de componibilidade e reutilizao apresentada pelos
sistemas baseados em SOA, que visam permitir o alinhamento Negcio-TI, a Engenharia de
Software de Servio deve estar unificada com o Business Process Management20 a fim de
garantir no s a Qualidade do Servio, em nvel de sistema, como tambm a conformidade s
especificaes do Negcio. (HEUVEL et al., 2009)

VII.

Abordagem Holstica:
A Engenharia de Software de Servio possui uma caracterstica de natureza holstica21,
sendo assim, demanda uma abordagem interdisciplinar para a anlise e racionalizao dos
Processos de Negcio, concepo de servios de suporte, implantao, monitoramento e
evoluo. Isto significa que mtodos, modelos e conceitos devem ser integrados e que as
ferramentas SSE devem ser interoperveis. (HEUVEL et al., 2009)

3.2. Desafios

Os principais desafios listados por Heuvel et al. (2011) para a evoluo da Engenharia
de Software de Servio so:
I.
II.

Alinhamento Negcio-TI, adaptabilidade;

Novos modelos e abstraes para representar e lidar com a dinmica SOA;

III.

Como lidar com a heterogeneidade;

IV.

O mapeamento de requisitos;

V.
VI.

20
21

Componibilidade;
Testes.

Business Process Management Gerenciamento de Processos de Negcio.

Holstica relativo ao holismo. Que busca tudo abranger.

25

3.3. Engenharia de Software de Servio x Engenharia de Software

Tradicional

A Engenharia de Software definida por Fritz Bauer como: O estabelecimento e uso

de slidos princpios de engenharia para que se possa obter economicamente um software que
seja confivel e que funcione eficientemente em mquinas reais.
Segundo Pressman (1995), a Engenharia de Software abrange:
Mtodos: proporcionam os detalhes de como fazer. Tarefas que incluem:
planejamento, estimativa, anlise de requisitos, projeto da estrutura,
arquitetura, algoritmo, codificao, teste e manuteno;
Ferramentas: As ferramentas proporcionam apoio automatizado ou semiautomatizado aos mtodos.
Procedimentos: Constituem o elo de ligao que mantem juntos os mtodos e
as ferramentas [...] Os procedimentos definem a sequncia em que os mtodos
sero aplicados
Os princpios da Engenharia de Software a serem destacados, citados por Rezende
(2005), so:

I.

Formalidade:
Evitar a dependncia de pessoas ou processos em especfico.

II.

Abstrao:
Identificar aspectos importantes de determinado fenmeno.

III.

Decomposio:
Subdividir problemas complexos.

IV.

Generalizao:
Disseminar solues semelhantes e reutilizar resultados.

V.

Flexibilizao:
Facilitar eventuais mudanas modulares.

26

A Engenharia de Software de Servio busca a definio de mtodos, ferramentas e

procedimentos que se baseiem no apenas nos princpios da Engenharia de Software
Tradicional, mas tambm nos princpios identificados que visam proporcionar a melhor
utilizao da Arquitetura Orientada a Servio.
Percebe-se ento que no existem princpios que se contradizem, e sim uma
complementao da Engenharia de Software Tradicional com os princpios apresentados pela
proposta de Engenharia de Software de Servio.

3.4. Processo de Engenharia de Servio

A figura abaixo ilustra o processo de engenharia de servio:

Figura 3.1 Processo de Engenharia de Servio.

Fonte: http://www.i2p.com.br/ricardo/eng-orientada-a-servicos.pdf

I.

Identificao do Servio Candidato:

Servios podem ser classificados em Servios de utilidade, Servios de Negcio

ou Servios de coordenao ou de processo.

Servios de utilidade implementam funcionalidades gerais.
Servios de negcio implementam uma funo especfica do negcio.
Servios de coordenao ou de processo apoiam os processos de negcio.
Nessa fase devem ser aplicadas as caractersticas de Granularidade e Autonomia de
Servio, bem como podem ser observados os princpios de Alinhamento Negcio-TI e

27
Heterogeneidade da Engenharia de Software de Servio, uma vez que tais princpios devem
ser observados desde o incio do processo pela possibilidade de gerarem restries ao servio
a ser construdo.

II.

Projeto de Servio:
Durante o projeto de servio realizada a especificao de interface do servio,

aplicando ento o princpio Limites Explcitos da Engenharia de Software de Servio, para

proporcionar caractersticas de Servio como Contrato de Servio Padronizado e Abstrao.

III.

Implementao e Implantao do Servio:

Nessa etapa, o servio projetado anteriormente construdo e implantado.
A partir desse momento, o servio estar disponvel para consumo e/ou reutilizao

para construo de fluxos de negcio ou de outros servios, por meio da Composio de

servios, ilustrada na figura a seguir:

Figura 3.2 Construo de Servio por Composio.

Fonte: Adaptado de http://www.i2p.com.br/ricardo/eng-orientada-a-servicos.pdf

28

4. Concluso

A Arquitetura Orientada a Servio, no que tange ao seu aspecto tcnico, j est

amplamente difundida, no entanto, considerando as fases que antecedem implementao de
sua unidade bsica, o servio, observa-se grandes desafios, pois suas caractersticas produzem
alto grau de complexidade, tanto na identificao de sua granularidade quanto no prprio
alinhamento com o Negcio, a fim de proporcionar flexibilidade, reutilizao,
componibilidade e promover produtividade e reduo de custos s empresas nos
investimentos em TI.
Percebe-se ento, a carncia de mtodos, ferramentas e procedimentos especficos para
esse paradigma de desenvolvimento, uma vez que a Engenharia de Software Tradicional no
supre determinadas exigncias da Arquitetura Orientada a Servio.
A Engenharia de Software de Servio, ento, baseada em princpios que enfatizam a
necessidade de se adotar mtodos e ferramentas especficas para o desenvolvimento de
sistemas baseados em servio, e que complementam os princpios apresentados pela
Engenharia de Software Tradicional, a fim de constru-los abrangendo todas as caractersticas
inerentes Arquitetura Orientada Servio, e contribuir, desta forma, para os resultados das
empresas que a adotam.

[...] software service engineering as an emerging discipline that entails a departure

from traditional software engineering disciplines [...] (HEUVELet al., 2009, p.26)

29

5. Referncias Bibliogrficas

LUCCI, Elian Alabi. A Era Ps-Industrial, a sociedade do Conhecimento e a Educao

para o Pensar. Disponvel em: <http://www.mendeley.com/research/era-psindustrialsociedade-conhecimento-ea-educao-para-o-pensar/> Acesso em: 08 nov. 2011.
KRAFZIG, D., BANKE, K., SLAMA, D. Enterprise SOA: Service-Oriented Architecture Best
Pratices. 2004.

HEUVEL, Willem-jan Van Den et al. Software Service Engineering: Tenets and
Challenges. Disponvel em: <http://www.cs.rug.nl/~paris/papers/PESOS09.pdf>. Acesso em:
09 nov. 2011.

BIEBERSTEIN, Norbert et al. Executing SOA: A Practical Guide for the Service-Oriented
Architect. Pearson Education, 2008.
TAURION, Cezar. SOA Arquitetura Orientada a Servios. Disponvel
<http://www.smashwords.com/books/view/4104>. Acesso em: 20 nov. 2011.

em:

COSTA, Ivanir; CARVALHO NETO, Antonio Rodrigues. Tendncias Sobre a Arquitetura

Orientada
a
Servios
SOA. Disponvel
em:
<http://www.abepro.org.br/biblioteca/enegep2007_tr670485_9968.pdf>. Acesso em: 20 nov.
2011.

SANTOS JUNIOR, Alfredo Luiz Dos. Integrao de Sistemas com Java. Rio de Janeiro:
Brasport, 2007.

EVDEMON, John. Princpios do design de servio: padres e antipadres de

servio. Disponvel em: <http://msdn.microsoft.com/pt-br/library/ms954638.aspx>. Acesso
em: 26 nov. 2011.

ERL,
Thomas. Service-Orietation
Design
Principles. Disponvel
<http://www.soaprinciples.com/>. Acesso em: 27 nov. 2011.

JOSUTTIS, N. M. SOA in practice: The Art of Distributed System Design.

OReilly, 2007.

em:

30
FURTADO, Camille et al. Arquitetura Orientada a Servio - Conceituao. Disponvel
em: <http://np2tec.uniriotec.br:9093/np2tec/publicacoes>. Acesso em: 27 nov. 2011.

MACHADO, Joo Coutinho. Um estudo sobre o desenvolvimento orientado a servios.

Disponvel
em:
<
http://www2.dbd.pucrio.br/pergamum/tesesabertas/0210486_04_cap_02.pdf/>. Acesso em: 28 nov. 2011.

GOUVEIA, Miguel; GOUVEIA, Vitorino. Service Oriented Architecture (SOA), Desafios

para o Processo de Desenvolvimento de Software. Disponvel em: <http://isg.inesc-id.pt/>.
Acesso em: 28 nov. 2011.

PRESSMAN, Roger S.. Engenharia de Software. So Paulo: Makron Books, 1995.

REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informao. Rio de

Janeiro: Brasport, 2005.

LIMA, Ricardo Roberto de. Engenharia de Software Orientada a servios. Disponvel em:
<http://www.i2p.com.br/ricardo/eng-orientada-a-servicos.pdf>. Acesso em: 04 dez. 2011.