Pós-Graduação em Ciência da Computação

Um Processo para Projeto Arquitetural de

Software Dirigido a Modelos e Orientado a

Serviços

Por

Vítor Torres Braga

Dissertação de Mestrado

Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao

RECIFE, AGOSTO/2011
 UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

VÍTOR TORRES BRAGA

“Um Processo para Projeto Arquitetural de Software

Dirigido a Modelos e Orientado a Serviços”

ESTE TRABALHO FOI APRESENTADO À PÓS-

GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
DO CENTRO DE INFORMÁTICA DA
UNIVERSIDADE FEDERAL DE PERNAMBUCO
COMO REQUISITO PARCIAL PARA OBTENÇÃO
DO TÍTULO DE MESTRE EM CIÊNCIA DA
COMPUTAÇÃO.

ORIENTADOR: AUGUSTO SAMPAIO

CO-ORIENTADOR: VINICIUS CARDOSO GARCIA

RECIFE, AGOSTO/2011
iii
AGRADECIMENTOS

Dedico este trabalho a minha maravilhosa família que sempre me apoiou em todos
os momentos da minha vida. Em especial ao meu pai, minha mãe e minha irmã, por
serem exemplos de dignidade, honestidade e perseverança que modelaram o meu
caráter e foram os responsáveis pelo homem que me tornei. Vocês são meus únicos e
verdadeiros heróis.

A minha namorada Juliana por ter sido compreensiva, atenciosa e ter me suportado
durante esses últimos anos. Perdoe-me pelos vários compromissos desmarcados,
prometo que vou recompensar.

Ao meu orientador Augusto Sampaio por sempre ter acreditado no meu potencial e,
desde o inicio, confiado no meu trabalho. Muito obrigado pelo tempo dedicado e
paciência. Foi um privilégio ter convivido de perto durante esses anos, nossa
universidade precisa de mais professores como você.

Ao meu co-orientador Vinicius Garcia pela paciência e excelentes sugestões

apresentadas na reta final. Muito obrigado pelo tempo gasto com leitura e correções
de cada capitulo.

Aos meus parceiros da MobilIT, hoje Comment Lab, Farley, Paulo e Firma por
terem sido amigos com os quais sempre pude contar e compartilhar os sucessos,
fracassos e angustias.

iv
Resumo

Nos últimos anos, o Desenvolvimento Dirigido a Modelos (Model-Driven

Development - MDD) tem se posicionado como uma tendência na pesquisa de
engenharia de software. Embora o uso de modelos não seja novidade, o sucesso
MDD vem da possibilidade de construir sistemas de software completos a partir de
transformações automáticas de modelos. Apesar de MDD ser reconhecida como
uma abordagem útil, ainda existem lacunas importantes que precisam ser
preenchidas.
Por exemplo, SOA é um estilo de arquitetura de software que permite o
desenvolvimento de sistemas alinhado com os objetivos de Service Oriented
Computing (SOC), possibilitando o desenvolvimento de aplicações mais flexíveis,
modulares e reutilizáveis. Mas, apesar dessas vantagens, a maioria dos processos e
metodologias SOA disponível na literatura carecem de uma sistemática detalhada para
suportar o desenvolvimento.
Nesse contexto, este trabalho investiga as complementaridades e vantagens de
utilizar MDD e SOA em conjunto, e apresenta um processo de projeto arquitetural de
software dirigido a modelos e orientado a serviços, a fim de possibilitar o projeto de
arquiteturas estáveis, flexíveis e modulares. O processo foi elaborado para ser
sistemático, fácil de usar e compreender, independente de ferramentas e tecnologias,
e que pudesse resolver problemas práticos como: a integração de aplicações, o
acoplamento entre front-end e back-end dos sistemas, e o desalinhamento de
expectativas entre os stakeholders. Um estudo de casos é desenvolvido para ilustrar
as diversas etapas do processo e uma avaliação do processo é apresentada com base
em um experimento seguindo a abordagem Goal Question Metric.

Palavras-chave: Desenvolvimento Dirigido por Modelos (MDD), Arquitetura Orientada

a Serviços (SOA), Processo de Software

v
Abstract

Recently, Model-Driven Development (MDD) has positioned itself as a trend in

software engineering research. Although the use of models is not new, the success of
MDD comes from the possibility of building complete software systems from automatic
model transformations. Although MDD is recognized as a useful approach, there are
still important gaps that need to be fulfilled.
For example, SOA is a software architecture style that allows the development of
systems aligned with the objectives of service oriented computing, enabling the
development of more flexible, agile and reusable applications. Despite these
advantages, most SOA processes and methodologies available in the literature do not
have a systematic detailed approach to support the development.
In this context, this work presents a model-driven and service oriented process to
software architectural design, in order to enable the design of stable, flexible and
modular architectures. The process was designed to be systematic, easy to use and
understand, independent of tools and technologies, and that could solve practical
problems such as: integration of applications, front-end and back-end coupling,
misalignment of expectations between stakeholders.
A case study is developed to illustrate the steps of the process, and an evaluation of
the process is presented based on an experimental study following the Goal Question
Metric approach.

Keywords: Model-Driven Development (MDD), Service Oriented Architecture (SOA),

Software Process

vi
Índice

Capítulo 1 - Introdução............................................................................... 1
1.1 Contexto ............................................................................................................. 1
1.2 Principais Contribuições ................................................................................... 4
1.3 Fora do Escopo.................................................................................................. 5
1.4 Organização da Dissertação ............................................................................. 6

Capítulo 2 - Conceitos e Fundamentos ...................................................... 8

2.1 Introdução .......................................................................................................... 8
2.2 MDD – Model Driven Development ................................................................... 9
2.2.1 Vantagens e Desvantagens 10

2.3 MDA – Model Driven Architecture .................................................................. 11

2.4 SOA................................................................................................................... 15
2.4.1 Vantagens e Limitações 18

2.5 SoaML............................................................................................................... 19
2.5.1 Simple Interfaces 21
2.5.2 Service Interface 22
2.5.1 Service Contract 24
2.5.1 Service Architecture 25

Capítulo 3 - O Processo............................................................................. 27
3.1 Introdução ........................................................................................................ 27
3.2 Especificar Modelo de Negócio ...................................................................... 28
3.3 Analisar Serviços............................................................................................. 33
3.4 Projetar Serviços ............................................................................................. 42

Capítulo 4 - Instanciação e Execução do Processo ................................. 48

4.1 Introdução ........................................................................................................ 48
4.2 Qualiti Internet Banking .................................................................................. 48

vii
4.3 Especificar Modelo de Negócios .................................................................... 49
4.4 Analisar Serviços............................................................................................. 52
4.5 Projetar Serviços ............................................................................................. 56

Capítulo 5 - Avaliação do Processo.......................................................... 61

5.1 Introdução ........................................................................................................ 61
5.2 Definição .......................................................................................................... 61
5.3 Planejamento ................................................................................................... 66
5.4 Operação .......................................................................................................... 68
5.5 Coleta e Análise dos Dados ............................................................................ 69
5.6 Lições Aprendidas ........................................................................................... 73

Capítulo 6 - Conclusão .............................................................................. 75

6.1 Principais contribuições ................................................................................. 75
6.2 Trabalhos Relacionados ................................................................................. 76
6.3 Limitações e Trabalhos Futuros ..................................................................... 79
6.4 Considerações Finais ...................................................................................... 79

Bibliografia ………………………………………………………………81
Apêndice A ………………………………………………………………87
Apêndice B ………………………………………………………………95

viii
Lista de Tabelas

Tabela 5.1. Dados dos Projetos. 69

Tabela 5.2. Resultados da métrica CBCS. 70
Tabela 5.3. Resultados da métrica WOCS. 70
Tabela 5.4. Resultados da métrica IMSC. 71
Tabela 6.1. Resultados da análise. 78

ix
Lista de Figuras

Figura 1.1 – Roadmap do trabalho................................................................................ 7

Figura 2.1 – Processo MDD genérico [54]. ................................................................. 10
Figura 2.2 – Processo MDA Básico [30]...................................................................... 13
Figura 2.3 – Processo de transformação de Modelos MDA [30]. ................................ 14
Figura 2.4 – Níveis de modelagem em MDA. .............................................................. 15
Figura 2.5 – Diferentes pontos de vistas de SOA [56]. ................................................ 16
Figura 2.6 – Relacionamento entre os tipos de serviços [7]. ....................................... 17
Figura 2.7 –Serços e participantes [26]. ...................................................................... 20
Figura 2.8 –Interface Simples [26]. ............................................................................. 21
Figura 2.9 – Uso de Interface Simples como portas dos participantes [26]. ................ 21
Figura 2.10 – Definição de uma Interface de Serviço [26]. .......................................... 23
Figura 2.11 – Coreografia do Serviço [26]................................................................... 24
Figura 2.12 – Exemplo de Arquitetura de Serviço [26]. ............................................... 26
Figura 3.1 - Visão Geral do Processo. ........................................................................ 27
Figura 3.2 –Especificar Modelo de Negócio. ............................................................... 29
Figura 3.3 – Exemplo de Modelo Navegacional [30]. .................................................. 30
Figura 3.4 – Exemplo de Interface Gráfica [30]. .......................................................... 31
Figura 3.5 – Exemplo do Protótipo de Interface Gráfica [30]. ...................................... 32
Figura 3.6 – Modelos da fase Especificar Modelo de Negócio. ................................... 33
Figura 3.7– Fluxo de atividades da fase Analisar Serviços. ........................................ 34
Figura 3.8 – Construção da Arquitetura de Serviços. .................................................. 36
Figura 3.9 – Serviços de Entidade. ............................................................................. 37
Figura 3.10 –Modelo de Interação de Serviços. .......................................................... 38
Figura 3.11–Construção do Modelo de Componentes de Serviços. ............................ 40
Figura 3.12–Transformações de modelo da fase Analisar Serviços. ........................... 41
Figura 3.13–Modelos da fase Analisar Serviços. ........................................................ 42
Figura 3.14–Diagrama de artefatos de Projetar serviços ............................................ 43
Figura 3.15–Exemplo de Arquitetura do Sistema. ....................................................... 44
Figura 3.16–Transformação de modelos da fase Projetar Serviços. ........................... 46

x
Figura 3.17–Modelos da fase Projetar Serviços .......................................................... 47
Figura 4.1–Casos de Uso do QIB................................................................................ 49
Figura 4.2–Modelo de Informação de Negócio do QIB................................................ 50
Figura 4.3–Modelo de Funcionalidades do QIB. ......................................................... 51
Figura 4.4–Modelo Navegacional do QIB.................................................................... 51
Figura 4.5–Protótipo de Interface Gráfica do QIB da tela login. .................................. 52
Figura 4.6–Passo a passo para elaboração da Arquitetura de Serviços do QIB. ........ 53
Figura 4.7–Serviços de Entidade do QIB. ................................................................... 54
Figura 4.8–Modelo de Interação de Serviço do QIB. ................................................... 54
Figura 4.9–MIN Refinado do QIB. ............................................................................... 55
Figura 4.10–Modelo de Componentes dos Serviços do QIB. ...................................... 55
Figura 4.11–Arquitetura do Sistema. ........................................................................... 58
Figura 4.12–Diagrama de classes do componente ControleAcesso............................ 59
Figura 4.13–Diagrama de Seqüência de Efetuar Login. .............................................. 59
Figura 4.14–Construção da Interface Gráfica Desktop do QIB.................................... 60
Figura 4.15–Diagrama de Classe e seqüência do Desktop. ........................................ 60
Figura 5.1–Framework de medição............................................................................. 62
Figura 5.2 - Gráfico de avaliação da dificuldade do processo. .................................... 71
Figura 5.3 - Gráfico da avaliação do alinhamento entre os stakeholders. ................... 72
Figura 5.4 - Avaliação do desacoplamento entre front-end e back-end. ...................... 72

xi
Capítulo 1 - Introdução

1.1 Contexto

O relatório anual publicado pelo The Standish Group [1], chamado curiosamente de
The Chaos Report, mostra alguns números interessantes sobre o cenário da indústria
de software [2]. Aproximadamente 24% dos projetos são cancelados por atrasos e
orçamento estourados. Cerca de 40% dos projetos estouram o orçamento e/ou o
prazo. Aproximadamente 32% de todos os projetos de TI atingem seus objetivos
dentro do prazo e custo estimados.
Claramente, a taxa de insucesso em projetos de software é alta, não há
comparação com outros tipos de indústria e os motivos já foram descritos em vários
livros e artigos disponíveis na literatura [3,4,5]. Várias abordagens em engenharia de
software sugiram justamente para tentar amenizar estes números: Desenvolvimento
Baseado em Componentes, Linhas de Produtos de Software, Desenvolvimento
Orientado a Aspectos, Arquitetura Orientada a Serviço e Desenvolvimento Dirigido a
Modelos.
Atualmente, a maioria dos softwares existentes no mercado foi desenvolvida
baseada em blocos monolíticos, formados por partes relacionadas com alto grau de
acoplamento [63]. Por isso, o Desenvolvimento Baseado em Componentes (DBC)
surgiu como um novo modelo de desenvolvimento de software para transformar esses
blocos monolíticos em componentes, diminuindo a complexidade e o custo de
desenvolvimento, onde os componentes podem ser usados em outras aplicações [64].
Linhas de Produtos de Software (LPS) é um conjunto de sistemas de software que
possuem funcionalidades em comum e que atendem as necessidades de um domínio
especifico. As abordagens LPS exploram as semelhanças e variabilidades desses
produtos, guiando o desenvolvimento de artefatos fundamentais (core assets)
customizáveis e reusáveis [65]. Reutilizando esses artefatos é possível construir
sistemas em larga escala e de acordo com requisitos específicos dos clientes.

1
 O Desenvolvimento de Sistemas Orientados a Aspectos (DSOA) é uma abordagem
cujo objetivo principal é separar requisitos transversais das classes da aplicação.
Utilizando orientação a aspectos, requisitos como registro de operações, controle de
sincronização e comunicação podem ser implementados de forma simples, elegante e
favorecendo a reutilização de código [66].
Arquitetura Orientada a Serviço, do inglês Service Oriented Architecture (SOA), tem
como principal objetivo o reúso intenso de serviços, para que em médio prazo, a tarefa
do desenvolvimento de uma aplicação seja, primordialmente, a composição e
coordenação dos serviços já implementados, aumentando o reúso e diminuindo o
dispêndio de recursos. Para atingir esses objetivos, SOA segue ―boas práticas‖ e
―princípios de projeto‖ para facilitar a tarefa de definir, encontrar e gerenciar os
serviços [22]. Alguns trabalhos consideram SOA como uma evolução do
Desenvolvimento Baseado em Componentes [47].
Já o Desenvolvimento Dirigido por Modelos (Model Driven Development - MDD) [8]
utiliza modelos para especificar e implementar toda e qualquer parte dos sistemas.
Utilizando MDD, os sistemas são modelados em vários níveis de abstração e sob
diferentes perspectivas. Diferentemente das outras abordagens de desenvolvimento
de software, os modelos são os artefatos centrais para a construção das aplicações, e
não o código.
Neste sentido, analisando as abordagens de desenvolvimento apresentadas
anteriormente, a combinação de conceitos e fundamentos existentes em um processo
integrado e sistematizado pode oferecer contribuições tanto para a academia como
para a indústria [54], segundo palavras de Jim Neighbors: “organizações
acadêmicas em ciência da computação parecem preferir o trabalho em novas
teorias. Porém, alguns dos mais bem-sucedidos trabalhos acadêmicos são
uma fusão e formalização de técnicas de sucesso.”
Nos últimos anos, MDD tem se posicionado como uma tendência na prática e na
pesquisa em engenharia de software. Embora o uso de modelos não seja novidade, o
seu sucesso vem da possibilidade de construir sistemas de software completos a partir
de transformações automáticas de modelos. Propostas como Software Factories1 da

1 http://msdn.microsoft.com/en-us/library/ms954811.aspx

2
Microsoft, MDA2 (Model-Driven Architectue) da OMG e EMF3 (Eclipse Model
Framework) da IBM estão entre as abordagens de desenvolvimento orientadas a
modelos mais conhecidas na literatura. Em particular, MDA vem ganhando bastante
atenção na academia e indústria, pois sugere a separação dos modelos em vários
níveis de abstração (CIM, PIM e PSM) e incentiva a evolução dos modelos através da
definição de regras de transformação.
Apesar de MDA ser reconhecida como uma abordagem promissora, ainda existem
lacunas importantes que precisam ser preenchidas [68]. Uma delas é o papel da
Arquitetura no processo de desenvolvimento para determinar quais elementos devem
ser incluídos dentro dos modelos e quais modelos devem ser gerados em cada nível
de abstração.
Além disso, outro problema comum é vincular a arquitetura final do sistema às
transformações dos modelos [53]. Idealmente, transformações de modelo devem ser
configuráveis e fazer cumprir as decisões de arquitetura. No entanto, algumas
metodologias pesquisadas [68, 69, 70, 72, 73] não se preocupam em incorporar
decisões arquiteturais às transformações, a fim de garantir uma arquitetura flexível e
que segue as decisões e regras definidas pelos arquitetos.
Por outro lado, SOA é um estilo de arquitetura de software que permite o
desenvolvimento de sistemas alinhado com os objetivos de Service Oriented
Computing (SOC) [52]. Por isso, o desenvolvimento de software orientado a serviços
também se tornou uma tendência e vem chamando atenção tanto da indústria quanto
da academia, pois possibilita o desenvolvimento de aplicações mais flexíveis,
modulares e reutilizáveis. Mas, apesar dessas vantagens, a maioria dos processos e
metodologias SOA disponível na literatura apresentam limitações que dificultam sua
adoção na prática. Entre elas, podemos destacar [53]:

 Utilizar abordagens de desenvolvimento de propósito geral sem apoio à

decisões de projeto: é importante definir guias e boas práticas que orientem
no projeto dos serviços dos sistemas;

2 www.omg.og/mda
3 www.eclipse.org/emf

3
  Delegar importantes decisões arquiteturais aos programadores ou
ferramentas de automação: na prática, são os arquitetos que identificam os
principais problemas e definem a arquitetura final do sistema, isso não é algo
simples que pode ser delegado a analistas de negócios, progamadores, ou
mesmo embutido em ferramentas de automação.

Diante deste cenário, este trabalho apresentada um processo de projeto arquitetural

de software dirigido a modelos e orientado a serviços, a fim de possibilitar o projeto de
arquiteturas estáveis, flexíveis e modulares. O processo foi elaborado para ser
sistemático, fácil de usar e compreender, independente de ferramentas e tecnologias, e
que pudesse resolver problemas práticos como: a integração de aplicações, o
acoplamento entre front-end e back-end dos sistemas [13], e o desalinhamento de
expectativas entre os stakeholders [4,3].
Para atingir esses objetivos, o processo foi dividido em três conjuntos de atividades
(workflows) distintos: Especificar Modelo de Negócio, Analisar Serviços e Projetar
Serviços. Especificar Modelo de Negócio tem como principal objetivo produzir
artefatos que ajudem no alinhamento do entendimento entre os stakeholders. Analisar
Serviços tem como principal finalidade projetar a arquitetura do sistema independente
de plataforma de desenvolvimento. No Final, Projetar Serviços tem como objetivo
refinar os modelos produzidos e transformá-los em modelos menos abstratos e
projetados para executar em plataformas especificas.
Para avaliar aspectos quantitativos e qualitativos do processo aqui proposto, foi
desenvolvido um estudo de caso para ilustrar as diversas etapas do processo e
conduzido um estudo experimental utilizando a abordagem Goal Question Metric [6].

1.2 Principais Contribuições

Entre as principais contribuições deste trabalho, podemos destacar:

1. Definição de um processo sistemático para projeto arquitetural de

software dirigido a modelos e orientado a serviços, favorecendo:
o Reutilização de software: Nas primeiras fases do processo é possível
identificar oportunidades de reuso.

4
 o Modularidade: Com os artefatos gerados pelo processo é possível
projetar uma arquitetura desacoplada, tornando possível projetar os
componentes de forma independente.
2. Avaliação do processo através de um estudo experimental: Foi conduzido
um estudo experimental com 19 alunos de graduação da UFPE na disciplina de
Analise e Projeto de Sistemas para avaliar atributos qualitativos e quantitativos
do processo.
3. Alinhamento no entendimento entre os stakeholders: A prototipação do
sistema é realizada na primeira fase do processo para que todos os envolvidos
possam ter um entendimento uniforme das funcionalidades do sistema antes
que o sistema comece a ser projetado.
4. Praticidade e facilidade de uso: Foi feita uma instanciação do processo para
o contexto da disciplina na qual foi executada o experimento, mostrando assim
que o processo é flexível, fácil de usar e pode ser utilizado em outros
contextos. Para isso, o processo utiliza conceitos, fundamentos e artefatos
bastante utilizados tanto na indústria como na academia.

1.3 Fora do Escopo

Uma fez que o processo arquitetural proposto faz parte de um contexto mais amplo,
algumas questões importantes não foram abordadas nesse trabalho. Entretanto, essas
questões foram pensadas desde o início e constituem tópicos de pesquisa a serem
explorados em trabalhos futuros:

1. Transformação de modelos: O processo utiliza os conceitos de MDA e

MDD, mas não foram definidas regras formais para transformação dos
modelos (as regras e mapeamentos foram definidas textualmente).
2. Alcance do processo: O foco do processo proposto é na atividade de
projeto arquitetural. Engenharia de requisitos, controle de qualidade,
gerência de configuração, gerenciamento de atividades e codificação não
foram abordados.

5
 3. Reengenharia: O processo proposto não aborda metodologia e técnicas de
refactoring e reengenharia.
4. Ferramentas: Neste trabalho não foram desenvolvidas ferramentas
especificas para dar suporte e/ou automatizar as atividades do processo.

1.4 Organização da Dissertação

O trabalho está organizado da seguinte forma:

 Capítulo 2: Este capítulo apresenta uma breve introdução sobre SOA e MDD,
detalhando os principais conceitos, definições, métodos e práticas sobre cada
abordagem.
 Capítulo 3: Neste capítulo são mostrados em detalhes todas as fases,
atividades e artefatos gerados pelo processo proposto.
 Capítulo 4: Neste capítulo é mostrada uma instanciação do processo com um
estudo de caso para ilustrar todas as etapas e artefatos gerados pelo processo
na prática.
 Capítulo 5: Neste capítulo é apresentado o estudo experimental feito para
avaliação do processo. Todas as fases da abordagem Goal Question Metric
são mostradas em detalhes.
 Capítulo 6: Neste capítulo é apresentado um resumo de todo o trabalho,
mostrando o relacionamento com outros trabalhos disponíveis na literatura.
Por fim, são mencionadas as limitações e oportunidades a serem feitas em
trabalhos futuros.

A Figura 1.1 mostra o roadmap para orientar a leitura do trabalho.

6
 Capítulo 2
Capítulo 1
Motiva e Contextualiza Conceitos e
Introdução
Fundamentos

É usado por

Motiva e Capítulo 3 Capítulo 5

É avaliado por
apresenta o problema para O Processo Avaliação do processo

Capítulo 4 Motiva
É instanciado por
Exemplo de uso

Capítulo 6
Motiva
Conclusão

Figura 1.1 – Roadmap do trabalho.

7
Capítulo 2 - Conceitos e Fundamentos

2.1 Introdução

A maioria das organizações possui soluções que envolvem plataformas

heterogêneas, desenvolvidas usando diferentes tecnologias. Como os recursos
(pessoas, tempo, máquinas, investimentos) são escassos, as empresas não podem
simplesmente descartar as aplicações existentes. Uma das soluções para prolongar a
vida útil dessas aplicações é o paradigma de computação orientada a serviços (service
oriented computing - SOC) [7], pois através desse paradigma é possível estabelecer
uma comunicação não intrusiva com os sistemas legados, reutilizar aplicações e
prover a interoperabilidade entre diferentes tecnologias.
Arquitetura Orientada a Serviço (SOA) é, basicamente, um projeto de arquitetura de
software que favorece a eficiência, agilidade e produtividade no desenvolvimento de
aplicações e está alinhada com os objetivos de service oriented computing [7]. O
componente fundamental de SOA é o conceito de serviço que é uma função de
negócio independente, sem estado (stateless) que recebe como entrada uma ou mais
requisições e devolve uma resposta através de uma interface padronizada e bem
definida [22]. Cada serviço é completamente autônomo em relação a outros serviços.
SOA tem como principal objetivo o reuso intenso dos seus serviços para que, em
médio prazo, a tarefa do desenvolvimento de uma aplicação seja, primordialmente, a
composição e coordenação dos serviços já implementados, aumentando o reuso e
diminuindo o dispêndio de recursos. Para atingir esses objetivos, SOA segue ―boas
práticas‖ e ―princípios de projeto‖ para facilitar a tarefa de definir, encontrar e gerenciar
os serviços [22].
Por outro lado, MDD [8] utiliza modelos para especificar e implementar toda e
qualquer parte dos sistemas. Utilizando MDD os sistemas são projetados em vários
níveis de abstração e de diferentes perspectivas. Diferentemente de outras
abordagens de desenvolvimento de software, os modelos são os artefatos centrais
para a construção das aplicações, e não o código.

8
 A idéia por trás de MDD é que é possível criar modelos com alto nível de abstração
que possam ser, através de diversas transformações, traduzidos em componentes
executáveis [21]. Model Driven Architecture (MDA) é a abordagem definida pela OMG
(Object Management Group) que descreve um processo básico, padronizado e
extensível para o desenvolvimento de software dirigido a modelos.
Neste contexto, este capítulo apresenta uma introdução sobre SOA e MDE que são
a base para o desenvolvimento do processo proposto neste trabalho. A Seção 2.2
mostra uma visão geral sobre MDD e os conceitos básicos da abordagem MDA. A
Seção 2.3 mostra os conceitos básicos, objetivos e vantagens relativos a SOA.

2.2 MDD – Model Driven Development

O Desenvolvimento Dirigido a Modelos, do inglês Model-Driven Development

(MDD), é uma abordagem de desenvolvimento de software onde os modelos são os
artefatos centrais para a construção das aplicações. A idéia central de MDD é que é
possível criar modelos com alto nível de abstração que possam ser, através de
diversas transformações, traduzidos em componentes executáveis [21]. Ou seja, os
sistemas são modelados em vários níveis de abstração e de diferentes perspectivas.
O MDD também é conhecido como MDE (Model-Driven Engineering) ou MDSD
(Model-Driven Software Development). Todos esses acrônimos se referem à mesma
abordagem, cuja idéia é reconhecer a importância dos modelos no processo de
software, não apenas como um guia para tarefas de implementação e manutenção do
software [54]. A Figura 2.1 ilustra um processo genérico de Desenvolvimento Dirigido a
Modelos.

9
 Figura 2.1 – Processo MDD genérico [54].

A Figura 2.1 ilustra a ideologia por trás de MDD: “model once, run everywhere”. A
idéia é que construindo modelos de alto nível, independente de tecnologia e focados
exclusivamente no domínio do problema, mecanismos poderão transformar esses
modelos em códigos para diversas plataformas. Com isso, não será mais necessária a
implementação de código manualmente.

2.2.1 Vantagens e Desvantagens

MDD visa acelerar o desenvolvimento de software a fim de torná-lo mais eficiente.

A seguir são apresentadas algumas vantagens na utilização de MDD [23, 57, 58, 59]:

 Produtividade: Tarefas que são repetitivas podem ser implementadas nas

transformações dos modelos, diminuindo o tempo e esforço que podem ser
utilizado em outras tarefas mais importantes. Além disso, a partir dos modelos
pode-se gerar código para diversas plataformas e tecnologias.
 Portabilidade e interoperabilidade: um único modelo poderá ser
transformado em código para várias plataformas. Com isso, podem ser
construídos modelos de adaptadores e conectores independentes de
tecnologia e depois transformá-los em código para que diferentes plataformas
possam se comunicar;

10
  Comunicação: os profissionais envolvidos no projeto poderão se comunicar de
forma mais efetiva, pois os modelos são mais abstratos e fáceis de entender do
que o código, não exigindo conhecimento técnico de uma tecnologia
específica. Por isso, especialistas poderão participar ativamente e utilizar
diretamente os modelos para identificar os conceitos relativos ao problema.
 Corretude: os geradores de código não introduzem erros banais como erros
de digitação, portanto a identificação de erros conceituais acontece em um
nível de abstração mais alto, tornando-se, teoricamente, mais fáceis de
resolver.

Em resumo, as vantagens relacionadas ao uso de MDD estão diretamente

relacionadas à capacidade de evitar que os desenvolvedores executem tarefas
repetitivas que podem ser desempenhadas pelas transformações. E, diferente de
outras abordagens de desenvolvimento de software, com mecanismos de
transformações automáticas seria mais produtivo construir os sistemas em um nível de
abstração alto, pois isso possibilitaria não só o reuso de componentes de software,
mas também a reutilização de conhecimento [56].

2.3 MDA – Model Driven Architecture

Model-Driven Architecture é uma abordagem de desenvolvimento de software

orientado a modelos elaborado pelo Object Management Group (OMG), organização
internacional que define padrões abertos para aplicações orientadas a objetos. O
termo Model-Driven Architecture (MDA) foi mencionado pela primeira vez em 2000 em
um artigo publicado pela OMG [60]. Posteriormente, a OMG decidiu montar uma
equipe de arquitetos para elaborar uma definição formal de MDA que foi publicada em
2001 [61]. Esta era uma versão formal, mas incompleta que foi sendo aprimorada e,
em 2003, foi publicada uma versão mais detalhada e que foi aprovada pelo grupo. De
acordo com a OMG, MDA é um pequeno passo para transformar a arte
de desenvolvimento de software em uma disciplina de engenharia.
Resumindo, MDA define uma abordagem para:

 Especificar o sistema independentemente da plataforma que irá executar;

 Especificar plataformas de execução de sistemas;

11
  Especificar transformações de modelos.

Um modelo de um sistema é uma descrição ou especificação desse sistema e seu

ambiente para um propósito determinado. Um modelo é muitas vezes apresentado
como uma combinação de desenhos e texto. O texto pode estar em uma linguagem de
modelagem ou em uma língua natural. No contexto de MDA, um modelo é,
basicamente, uma representação de um sistema. MDA classifica o modelo em três
tipos:

 Computation Independent Model (CIM): Os requisitos do sistema podem ser

especificados com modelos independente de computação (CIM). O CIM
descreve a situação em que o sistema será utilizado. Em outras abordagens
esse modelo é chamado de modelo de domínio ou modelo de negócio. O CIM
oculta todas as informações sobre o uso do sistema e é totalmente
independente de como o sistema será implementado. O CIM pode ser
representado com diagramas UML simples.
 Platform Interdependent Model (PIM): é o modelo independente de
computação e descreve o sistema ocultando detalhes de plataforma e
tecnologias de desenvolvimento. Esses modelos apresentam o núcleo
funcional e estrutural do sistema. Diferente do CIM, o PIM projeta o sistema do
ponto de vista computacional.
 Platform Specific Model (PSM): é o modelo de plataforma específica. O PSM
é o refinamento do PIM, ou seja, ele combina as informações do PIM para uma
plataforma em particular (Java ou .Net, por exemplo).

Em princípio, o processo de desenvolvimento de software utilizando MDA começa

com a definição do Modelo de Computação Independente (CIM). O CIM pode ser
definido por analistas de sistemas em cooperação com especialistas do domínio.
Posteriormente o CIM é transformado em um modelo independente de plataforma
(PIM). O PIM acrescenta informações ao CIM, sem mostrar os detalhes da plataforma
utilizada. Por fim, o PSM é transformado em um modelo de plataforma específica
(PSM) acrescentando os detalhes da plataforma escolhida. A Figura 2.2 ilustra o
processo MDA básico descrito anteriormente.

12
 Figura 2.2 – Processo MDA Básico [30].

Conforme mostrado na Figura 2.2, MDA define um ciclo básico para o

desenvolvimento de software e divide as atividades de refinamento e transformações
de modelos em passos separados, facilitando assim a automação do processo.
Os conceitos relacionados ao processo de transformação de modelos MDA são:
Transformação e Definição de Transformação [30]. Transformação é a geração de
um modelo a partir de um modelo de origem, de acordo com uma definição de
transformação. Transformações de modelo podem ser manuais ou automáticas.
Definição de transformação é um conjunto de regras que descrevem como um
modelo, em uma linguagem de origem, será transformado em outro modelo, em uma
linguagem de destino. A Figura 2.3 ilustra o processo de transformações de modelos
utilizado em MDA.

13
 Figura 2.3 – Processo de transformação de Modelos MDA [30].

Conforme apresentado na Figura 2.3, para possibilitar transformações automáticas

através de uma ferramenta, é necessário que os modelos tenham sido escritos em
uma linguagem formal com sintaxe e semântica bem definidas. Para isso, MDA adota
o padrão MOF (Meta-Object Facility) [55] para definição das linguagens dos modelos.
MDA trabalha com os conceitos de meta-modelo e meta-linguagem. Meta-modelo é
o modelo de uma linguagem para definição de modelos. Meta-linguagem é uma
linguagem para definição de meta-modelos. Assim, MDA define quatro níveis de
modelagem que são ilustrados na Figura 2.4.

14
 Class

instace of instance of

UML Class UML Atribute

name: String name: string

instace of

Video
instance of
title: string

instace of

a:Video

title = "Casa Blanca"

Figura 2.4 – Níveis de modelagem em MDA.

O nível M0 define os modelos executáveis do sistema. O nível M1 descreve as

abstrações no domínio do sistema que são usadas no nível M0. O nível M2 descreve
os meta-modelos usados em M2 e, em M3, são definidas as metas-linguagem
utilizadas em M2.

2.4 SOA

Devido ao não esclarecimento dos termos e conceitos, SOA tem sido utilizado em
diferentes contextos e com diferentes propósitos. Por isso, dependendo do
interlocutor, arquitetura orientada a serviços pode ter diferentes interpretações,
conforme mostra a Figura 2.5:

15
 Figura 2.5 – Diferentes pontos de vistas de SOA [56].

Essa confusão ocorre porque o termo “service oriented architecture” é muitas vezes
confundido com “service oriented computing”. Por isso, é muito importante deixar claro
a distinção entre termos e conceitos relacionados a SOA. Service Oriented
Computing (SOC) [7], segundo Thomas Erl, é um conceito bastante amplo que
representa uma nova geração de plataforma de computação distribuída. Engloba
vários elementos como princípios de design, padrões de projeto, linguagens de
programação, hardware, frameworks, processos e estratégias organizacionais. SOA é,
basicamente, um modelo de arquitetura de software que beneficia a eficiência,
agilidade e produtividade no desenvolvimento de aplicações e está alinhada com os
objetivos de “service oriented computing”.
Uma arquitetura de software é um conceito abstrato que dá margem a uma série de
definições. Este trabalho utiliza a definição da IEEE: uma arquitetura de software
trata basicamente de como os componentes fundamentais de um sistema se
relacionam intrinsecamente e extrinsecamente [45]. Ou seja, SOA é um modelo de
arquitetura onde as funcionalidades das aplicações são modeladas como serviços.
Serviço é um componente que atende a uma função de negócio (business function)
específica. Ele pode receber e responder requisições ocultando completamente os
detalhes de sua implementação. Portanto, um serviço pode ser considerado um

16
conjunto de capacidades associadas a um propósito comum (ou contexto funcional).
Essas capacidades estão expressas em um contrato de serviço.
Baseando-se na natureza da lógica do negócio, no potencial de reutilização dessa
lógica e como a lógica implementada se relaciona com o domínio da aplicação, os
serviços podem ser classificados em três tipos [7]:

 Serviço de Entidade (Entity Services): é um tipo de serviço que é derivado de

uma ou mais entidades de negócio relacionadas e possuem alto grau de
reutilização. Serviços que fazem operações CRUD (Create, Read, Update,
Delete), por exemplo.
 Serviço de Tareta (Task Service): serviço que corresponde a um único
propósito. Um serviço de tarefa geralmente possui um baixo potencial de reuso
e utiliza outros serviços para realizar a sua lógica.
 Serviço de Utilidade (Utility Service): Serviço comum a vários tipos de
aplicação como log, notificação, tratamento de exceção e transformação de
informações. Tem um alto potencial de reuso e é desenvolvido para ser usado
por outros serviços.

A Figura 2.6 mostra o relacionamento entre os três tipos de serviços em uma

aplicação.

Figura 2.6 – Relacionamento entre os tipos de serviços [7].

Conforme mostrado na Figura 2.6, os serviços de tarefas ficam na primeira camada,

pois possuem um potencial de reuso baixo e normalmente utilizam outros serviços
para realizar as suas capacidades. Os serviços de entidade ficam na camada

17
intermediária. Já os serviços de utilidade ficam na camada inferior e são utilizados
frequentemente pelos serviços das camadas superiores, pois possuem um alto
potencial de reuso.

2.4.1 Vantagens e Limitações

Seguem alguns benefícios em utilizar uma arquitetura orientada a serviços [46] [47]
[7]:

 Reuso “caixa-preta”: O reuso ―caixa-preta‖ visa eliminar a necessidade de o

programador ter conhecimento da implementação de um determinado
componente de software que fará parte do processo de reuso. O reuso caixa-
preta se dá através da descrição de interfaces ou contratos bem definidos que
devem ser respeitados durante o desenvolvimento. O esforço é sempre usado
na nova implementação e não no entendimento da implementação do
componente.
 Interoperabilidade: O fenômeno da Web 2.0 apresentou uma nova realidade
para os desenvolvedores de sistemas. Por ser uma rede de escala gigantesca
existe uma infinidade de serviços que podem ser acessados através da
Internet. Usando SOA é possível acessar serviços em diferentes plataformas
de hardware, implementados em diferentes linguagens de programação,
usando protocolos bem definidos.
 Baixo acoplamento: Cada atividade (função de negócio) é implementada
como um serviço, ou seja, um componente independente que poderá ser
utilizado quantas vezes forem necessárias em diversas partes do sistema.
Assim, SOA é uma arquitetura baseada em componentes onde cada
componente preserva a sua independência.

Entretanto, apesar das vantagens apresentadas, a adoção SOA nas empresas

também requer um grande investimento inicial e o retorno sobre o investimento (ROI)
pode levar um longo tempo para acontecer. Algumas desvantagens e limitações
referentes a SOA são listadas a seguir [42] [43] [44]:

18
  Serviços com granularidade grossa: dependendo do tamanho e
complexidade das aplicações, testar e validar todas as combinações de todas
as condições de um serviço complexo pode se tornar impossível. Se um
serviço altamente genérico for utilizado por dezenas de outros, a sua
otimização pode ser uma tarefa muito difícil.
 Acoplamento fraco: é o sonho de todo arquiteto projetar um sistema
distribuído altamente desacoplado, mas adicionar novas funcionalidades com
um alto nível de complexidade pode se tornar um pesadelo.
 Integração: integração de serviços pode ser uma tarefa complexa,
especialmente quando há uma falta de pessoas qualificadas para
trabalhar com tecnologias SOA.
 Diversidade de tecnologias e fabricantes: leva-se tempo para aprender e
usar novas tecnologias. Existem muitas tecnologias e ferramentas SOA
disponíveis no mercado que são atualizadas constantemente. Portanto, custa
tempo e dinheiro treinar e manter uma equipe atualizada.

2.5 SoaML

SoaML (Service Oriented Architecture Modeling Language) é uma especificação da

OMG que descreve um profile UML e metamodelos para projetar sistemas SOA. O
principal objetivo de SoaML é dar suporte ao projeto de serviços em abordagens de
desenvolvimento de software dirigidas a modelo.
Com SoaML é possivel modelar requisitos, especificar serviços de sistemas,
especificar interface de serviços e projetar os serviços internamente. Os sistemas são
modelados na visão de provedores e consumidores de serviços. Os consumidores e
provedores de serviços podem ser pessoas, organizações e outros sistemas, em
SoaML ele são chamados de participantes.
O conceito-chave em SoaML é, naturalmente, o de serviço. Serviço é definido como
a entrega de valor para outro parte (consumidor) por meio de uma ou mais
capacidades [29]. O acesso ao serviço é feito através de um contrato que definine as
politicas e restrições que devem ser obedecidas. Um serviço é fornecido por um

19
participante que atua como o provedor para ser utilzados por outros participantes
consumidores.
Participantes oferecem serviços através de portas via o estereótipo <<Service>> e
requisitam serviços através de portas com o estereótipo <<Request>> Essas portas
representam os pontos onde os serviços são consumidos ou oferecidos. A Figura 2.7
mostra um exemplo de uso de serviços e participantes.

Figura 2.7 –Serços e participantes [26].

A Figura 2.7 mostra o participante "Productions" fornecendo o serviço "scheduling".

A porta do serviço é a interface UML "Scheduling" que tem duas operações:
"requestProductionScheduling" e "sendShippingSchedule".
A porta do serviço tem um tipo que descreve como usar esse serviço. Esse tipo
pode ser uma interface UML (para serviços muito simples – Simple Interface) ou uma
Service Interface. Em ambos os casos o tipo da porta de serviço especifica tudo que é
necessário para interagir com esse serviço, ou seja, é o contrato entre os provedores
e consumidores desse serviço. As seções a seguir mostram os principais elementos
utilizados para projetar serviços em SoaML.

20
2.5.1 Simple Interfaces

Interface Simples (Simple Interface) é utilizada para especificar interações de mão

única. O participante recebe operações e fornece os resultados diretamente para
quem fez a requisição.
Este tipo de interface pode ser usada com consumidores anônimos, ou seja, o
fornecedor não sabe nenhuma informação sobre o consumidor e como é feita a
coreografia do serviço. Interfaces simples são muitas vezes utilizadas para expor
diretamente as capacidades dos sistemas ou para definir os serviços mais simples que
não têm protocolos (troca de mensagens seguindo uma ordem predefinida).
Interface Simples é um caso especifico de Service Interface e ServiceContract,
onde o serviço é unidirecional - o consumidor chama operações do fornecedor e
recebe a resposta, pois o fornecedor não chama de volta (callback) o consumidor.

Figura 2.8 –Interface Simples [26].

A Figura 2.8 mostra um exemplo de uma Interface Simples que define o serviço
―Shipment status”. Essa interface pode ser usada como uma porta do tipo <<Service>>
ou <<Request>>.

Figura 2.9 – Uso de Interface Simples como portas dos participantes [26].

A Figura 2.9 mostra o uso da Interface Simples “Shipment Status” como portas dos
tipos <<Service>> e <<Request>>. Quando usada como << Request >> a interface é

21
consumidora. Quando usada como << Service >> a interface é provedora e deve
―entregar‖ a resposta em uma porta compatível.

2.5.2 Service Interface

Interface de Serviço (Service Interface) permite especificar serviços bidirecionais –

o fornecedor chama de volta (callback) o consumidor. A Interface de Serviço é definida
em termos do provedor do serviço e especifica a interface que o provedor oferece,
bem como a interface que, se for o caso, ela espera consumir. A Interface de Serviço
também pode especificar a coreografia do serviço – quais informações são enviadas
entre o provedor e o consumidor e em que ordem (protocolo).
Um consumidor de um serviço especifica a interface de serviço de que necessita
utilizando uma porta <<Request>>. A Interface de Serviço é do tipo <<Service>> no
provedor e do tipo <<Request>> no consumidor. As interfaces do consumidor e
fornecedor devem ser compatíveis, ou seja, o consumidor concorda em usar o serviço
conforme definido em sua Interface de Serviço, e o fornecedor se compromete em
fornecer o serviço de acordo com o que foi definido na interface (como ilustrado na
Figura 2.11). Interface de Serviço é mais usada quando as capacidades existentes são
diretamente expostas como serviços e em seguida utilizadas de várias maneiras, ou
em situações que envolvem uma ou mais entidade no protocolo.
Diferente da Interface Simples, a Interface de Serviço não é uma interface UML,
mas uma classe UML que fornece e exige uma interface do provedor. A Figura 2.10
mostra um exemplo de Interface de Serviço.

22
 Figura 2.10 – Definição de uma Interface de Serviço [26].

Conforme mostrado na Figura 2.10 a Interface de Serviço é uma classe UML

(<<ServiceInterface>> PlaceOrder Service) e define papéis específicos que cada
participante desempenha na interação de serviço. Esses papéis têm um nome e um
tipo de interface. A interface do provedor é realizada (Order Taker) pela classe Service
Interface. A interface do consumidor (Order Placer) é utilizada pela classe. A parte
inferior da Figura 2.11 mostra como o Order Placer (consumidor) e o Order Taker
(provedor) trocam mensagens para realizar o serviço, a coreografia do serviço.

23
 Figura 2.11 – Coreografia do Serviço [26].

Na coreografia do serviço, mostrada na Figura 2.11, o consumidor Order Place

chama (opcionalmente) a operação Quote Request e depois chama a operação Order.

2.5.1 Service Contract

Contrato de Serviço (Service Contract) determina como fornecedores, consumi-

dores e, potencialmente, outros papéis trabalham juntos para trocar informações. O
Contrato de Serviço define os papéis que cada participante desempenha no serviço

24
(como provedor ou consumidor) e as interfaces que implementam para desempenhar
esse papel. Essas interfaces são as portas que obrigam os participantes a
desempenhar o seu papel definido no Contrato de Serviço.
O Contrato de Serviço representa o acordo entre os participantes de como o serviço
será consumido e fornecido. Este acordo deve incluir todas as interfaces, coreografia e
quaisquer outras informações. Se provedor e consumidor suportam contratos de
serviços diferentes, deve haver um acordo ou determinação de que seus contratos de
serviço são compatíveis e coerentes com outros compromissos do mesmo
participante. Contratos de serviços podem fazer parte de uma ou mais arquiteturas de
serviços (define como um conjunto de participantes fornece e consume os serviços
para um objetivo ou processo de negócio).
Normalmente, Contratos de Serviço são inseridos "no meio" dos participantes e as
extremidades (os participantes) concordam com a sua parte no contrato ou se
adaptam a ele. Na seção a seguir será mostrado o exemplo de uso de Contratos de
Serviços na Arquitetura de Serviço.

2.5.1 Service Architecture

Um dos principais benefícios do SOA é a capacidade de permitir que comunidades,

organizações ou sistemas trabalhem em conjunto de forma mais coesa usando
serviços, sem ficar excessivamente acoplados. Isso requer uma compreensão de
como essas entidades trabalham e colaboraram. SoaML permite especificar essa
colaboração através da Arquitetura de Serviço (Service Architecture).
A Arquitetura de Serviço é uma rede de participantes, com papéis bem definidos,
fornecendo e consumindo serviços para cumprir um objetivo comum. A Arquitetura de
Serviço também pode ter um processo de negócio para definir as tarefas e
orquestração dos serviços.
A Arquitetura de Serviços pode ser projetada em dois níveis de granularidade:
arquitetura do domínio e arquitetura dos participantes. O primeiro nível, arquitetura de
serviços do domínio, corresponde a uma visão de alto nível mostrando como os
participantes de um determinado domínio trabalham em conjunto para realizar um
propósito específico. O segundo nível, arquitetura de serviços do participante, define a
arquitetura de serviços ―interna‖ de um participante. A Arquitetura de Serviços do

25
domínio é definida utilizando diagrama de comunicação UML, e Arquitetura de
Serviços de um participante pode ser modelada como um diagrama de classe ou
componentes.
A Figura 2.12 mostra um exemplo de Arquitetura de Serviço.

Figura 2.12 – Exemplo de Arquitetura de Serviço [26].

A Figura 2.11 mostra a Arquitetura de Serviço de uma comunidade composta por

um fabricante (<<Participant>> Manufacturer), um revendedor (<<Participant>>
Dealer), e uma empresa de transporte (<<Participant>> Shipper). Neste cenário, o
revendedor faz um pedido (<<Service Contract>>Order) ao fabricante, o fabricante
confirma o pedido e solicita o envio da mercadoria requisitada (<<Service
Contract>>Ship Request), que é enviada pela empresa de transporte. A qualquer
momento o revendedor pode verificar o status atual do pedido (<<Service Contract>>
Ship Status).

26
Capítulo 3 - O Processo

3.1 Introdução

O principal objetivo deste trabalho é definir um processo sistemático de projeto

arquitetural de software dirigido a modelos e orientado a serviços a fim de possibilitar o
projeto de arquiteturas estáveis, flexíveis e modulares, e que possa resolver problemas
práticos como: a integração de aplicações, o acoplamento entre front-end e back-end
dos sistemas, e o desalinhamento de expectativas entre os stakeholders.
Para atingir esse objetivo, o processo é composto por workflows distintos:
Especificar Modelo de Negócios, Analisar Serviços e Projetar Serviços. A Figura
3.1 mostra a visão geral do processo proposto.

Figura 3.1 - Visão Geral do Processo.

A Figura 3.1 mostra a visão geral do processo considerando os termos MDA e os

conceitos e princípios utilizados em SOA. No workflow Especificar Modelo de

27
Negócios são construídos os modelos independentes de computação (CIM), pois os
artefatos gerados não são modelos de software e podem ser compreendidos por
diferentes stakeholders e elaborados por especialistas de domínio. No workflow
Analisar Serviços são gerados modelos com alto grau de abstração e independentes
de plataforma e tecnologia (PIM) utilizando SoaML(um profile UML para projetar
sistemas SOA). Por fim, no workflow Projetar Serviços são gerados modelos mais
detalhados levando-se em consideração as tecnologias, plataformas e linguagens de
programação (PSM) utilizadas para a implantação, execução e codificação das
aplicações.

3.2 Especificar Modelo de Negócio

O principal objetivo deste workflow é gerar artefatos que facilitem o entendimento

do sistema que será desenvolvido e que possam ser facilmente compreendidos por
todos os stakeholders envolvidos no projeto (clientes, arquitetos, gerentes de projetos
e desenvolvedores). A Figura 3.2 mostra o fluxo de atividades e os artefatos gerados
(algumas setas foram omitidas para não prejudicar o entendimento do diagrama).

28
 Figura 3.2 –Especificar Modelo de Negócio.

Tendo em vista a grande variedade de artefatos produzidos pelos principais

processos de engenharia de software adotados na indústria nos dias de hoje, a
primeira atividade, Modelar Conceitos de Negócio (Figura 3.2), pode receber como
entrada documentos como: Requisitos do Sistema, Casos de Uso, Requisitos de
Negócio e BPM [48]. Ou seja, documentos úteis para especificar minimamente o
problema, as necessidades do cliente e as funcionalidades do sistema.
A atividade Modelar Conceito de Negócio tem como saída o Modelo de
Informação do Negócio (MIN) e o Modelo de Funcionalidades (MF). O MIN não é
um modelo de software, e sim um modelo de informação que existe no domínio do
problema. Seu principal objetivo é capturar conceitos e identificar relacionamentos
entre eles. Para a construção do MIN, devem ser usadas informações existentes nos

29
documentos de entrada. O MIN pode ser comparado com o modelo de tipos de
negócios que ajuda a identificar os conceitos de negócio que o sistema deverá
manipular. O MIN é representado como um diagrama de classes UML sem atributos e
operações contendo as ―classes conceituais‖ do sistema. Neste modelo a
especificação da multiplicidade é opcional.
O MF é, basicamente, um modelo de casos de uso, agrupados em pacotes, com as
funcionalidades (representados pelos casos de uso) e os usuários (representados
pelos atores) da aplicação. Da mesma forma que o MIN, o MF é construído a partir do
conhecimento do negócio e dos documentos de entrada. Com isso, as
funcionalidades, os usuários e os sistemas externos são representados em um modelo
de casos de uso.

A segunda atividade é Projetar Fluxo de Informação que tem como entrada o

MIN. Esta atividade gera como saída o Modelo Navegacional (MN). O MN pode ser
um diagrama de classes que utiliza GuiProfile profile [30], um profile UML para a
modelagem de interfaces gráficas, para organizar o fluxo de telas (ou páginas, no caso
de aplicações web) do sistema. A Figura 3.3 mostra um exemplo de modelo
navegacional de um editor UML simples.

Figura 3.3 – Exemplo de Modelo Navegacional [30].

O modelo navegacional, mostrado na Figura 3.3, foi projetado como um diagrama

de classes com estereótipos para representar as janelas principais (<<
primaryWindow>>), caixa de mensagens (<<messageBox>>), janela de escolha de

30
arquivo (<<fileChooser>>), frames (<<frameSets>> e <<frame>>) e a navegabilidade
entre as telas (<<links>>).
O MN também pode ser projetado como um site map [27] (bastante usado em
aplicações web) ou User interface flow [61] (bastante usado em metodologias ágeis).
A última atividade do workflow Especificar Modelo de Negócios é Elaborar
Protótipo de Interface. Esta atividade tem como entrada os artefatos gerados
anteriormente e gera como saída o Protótipo da Interface Gráfica (PIG). O PIG é,
basicamente, um layout completo do sistema que contem todas as funcionalidades,
telas, conteúdo e mensagens do sistema. A Figura 3.5 mostra o PIG correspondente à
tela apresentada na Figura 3.4.

Figura 3.4 – Exemplo de Interface Gráfica [30].

31
 Figura 3.5 – Exemplo do Protótipo de Interface Gráfica [30].

A imagem, os textos, a caixa de texto, os seletores e o botão foram modelados

com os estereótipos PresentationImage, Text, InputTextBox, RadioButton, CheckBox e
Button, respectivamente. A proporção de alguns elementos foi alterada para facilitar a
visualização de seus nomes.

O PIG também pode ser projetado como um wireframe [27] completo do sistema
que contém todas as funcionalidades, telas, conteúdo e mensagens. Wireframes são
muito utilizados na indústria para validar funcionalidades e aplicar testes de
usabilidades antes que o sistema comece a ser codificado. O PIG é um artefato muito
útil para entender, visualizar e avaliar claramente o que será desenvolvido antes que o
sistema comece a ser projetado.

A Figura 3.6 mostra os modelos, meta-modelos e meta-linguagens envolvidos em

Especificar Modelo de Negócios.

32
 conforms To

MOF

conforms To
conforms To

UML2 MM GuiProfile UML MM

extends

instance Of
instance Of
instance Of instance Of

MF MIN MN PIG

Figura 3.6 – Modelos da fase Especificar Modelo de Negócio.

Conforme ilustrado na Figura 3.6, o Modelo de Informação de Negócios (MIN) e o

Modelo de Funcionalidades é um modelo UML 2.0. O Modelo Navegacional (MN) e
o Protótipo de Interface Gráfica (PIG) são instâncias do GuiProfile. O GuiProfile é
uma extensão de UML 2.0 em conformidade com seus respectivos meta-modelos
(GuiProfile UML MM). E todos os meta-modelos de UML 2.0 e GuiProfile foram
definidos em conformidade com o MOF.

3.3 Analisar Serviços

O principal objetivo de Analisar Serviços é construir os primeiros modelos

arquiteturais do sistema. Isto é feito utilizando uma sistemática para identificação dos
primeiros serviços e componentes. Para a criação dos modelos é utilizado SOAML
[29], um profile UML para projetar sistemas SOA. A Figura 3.7 mostra o fluxo de
atividades de Analisar Serviços.

33
 Figura 3.7– Fluxo de atividades da fase Analisar Serviços.

A primeira atividade é Identificar Serviços, que recebe como entrada o Modelo de

Funcionalidades e o Modelo de Informação do Negócio, e gera como saída a
Arquitetura de Serviços (AS).
A Arquitetura de Serviço descreve como os participantes (participants) [29]
trabalham em conjunto para fornecer e utilizar os serviços descritos nos contratos de
serviço (service contracts) [29]. Os participantes representam entidades que fornecem
e consomem serviços. Os participantes podem ser pessoas, organizações ou outros
sistemas, por exemplo. Um contrato de serviço é a especificação de um acordo entre

34
provedores e consumidores de serviços quanto às informações que serão trocadas
entre eles.
A partir do Modelo de Funcionalidades pode se gerar a Arquitetura de Serviço
automaticamente utilizando as seguintes regras:

 Contratos de serviços: os pacotes de casos de uso do modelo de

funcionalidades são mapeados em contratos de serviços. Casos de usos que
não pertencem a nenhum pacote são mapeados em contratos de serviços
independentes. Os relacionamentos entre caso de uso  ator também são
mapeados como contratos independentes.
 Participantes: os atores são diretamente mapeados como participantes. O
―sistema‖ dá origem a um participante independente que irá consumir e
fornecer serviços para os outros participantes.
O próprio ―sistema” dá origem a um participante independente.

Para facilitar a compreensão, a Figura 3.8 mostra visualmente o processo de

transformação.

35
 Pacote 2
UC 5
UC3

UC 4

Pacote 1

UC 1 Ator 2
Ator 1

UC2

<<Service Contract>>
<<Service Contract>> UC5-Ator2
Pacote1

provide consume
consume provide

<<Participant>> <<Participant>>
<<Participant>> consume <<Service Contract>> Sistema Ator2
Ator1 Pacote2
provide

consume
provide
<<Service Contract>>
UC5

Figura 3.8 – Construção da Arquitetura de Serviços.

No exemplo mostrado na Figura 3.8, os pacotes de casos de uso (Pacote 1 e

Pacote 2 ) foram mapeados nos contratos de serviços com os mesmos nomes
(<<Service Contract>> Pacote 1 e (<<Service Contract>> Pacote 2). O caso de uso
UC5 (quadrado tracejado na Figura 3.8) foi mapeado em um novo serviço (<<Service
Contract>> UC5). Os atores 1 e 2 foram mapeados em participantes com os mesmos
nomes (<<Participant>> Ator 1 e <<Participant>> Ator 2 ). O relacionamento UC5-Ator
2 deu origem ao contrato de <<Service Contract>> UC5-Ator2, conforme ilustrado pela
seta pontilhada na Figura 3.8. O participante ―Sistema‖ surgiu para prover serviços ao
participante ―Ator 1‖ e consumir de ―Ator 2‖.

36
 A segunda atividade de Analisar Serviços é Refinar Serviços, que recebe como
entrada a AS, o MIN e tem como saída o Modelo de Interação dos Serviços (MIS) e
o MIN refinado. Esta atividade tem como principal objetivo identificar as capacidades
dos serviços (services capabilities) [7]. As capacidades dos serviços representam
funções específicas através das quais os serviços podem ser invocados. Elas são as
―operações‖ das interfaces dos serviços.
Para construir o MIS é necessário identificar os serviços de entidades [7], um tipo
de serviço que é derivado de uma ou mais entidades de negócio relacionadas e
possuem alto grau de reutilização: serviços que fazem operações CRUD (Create,
Read, Update, Delete), por exemplo. Pode-se obter os contratos de serviços de
entidades marcando as entidades do MIN com o estereótipo <<Entity Service>>. A
Figura 2.8 ilustra esse processo.

<<entity service>> <<entity service>>

E1 E2 E3

MIN marcado

<<service contract>> <<service contract>>

Serviço E1 Serviço E2

Figura 3.9 – Serviços de Entidade.

Com a identificação dos serviços de entidade e a Arquitetura de Serviços é

possível criar automaticamente os templates dos Modelos de Interação dos
Serviços da seguinte forma:

1. Criam-se interfaces com os nomes dos participantes consumidores

(representando a porta <<Resquest >> dos participantes consumidores de
SoaML);
2. Criam-se interfaces com os nomes dos contratos de serviços e serviços de
entidade (representando a porta <<Service>> dos participantes
consumidores de SoaML);

37
 3. Para cada contrato de serviço é criado automaticamente um MIS
contendo:
a. a interface com o nome do participante consumidor do contrato de
serviço;
b. a interface com o nome do contrato de serviço e
c. as interfaces dos serviços de entidade.

Com o template do MIS construído, pode-se identificar manualmente as operações

e mensagens de cada interface (baseado nos artefatos de entrada para o processo).A
Figura 3.10 mostra um exemplo da construção de um MIS completo.

: Participantes 1 : Servico1 : Serviço E1 : Servico 2

operacao1() operacao1()

retorno
operacao1()

retorno
retorno
operacao2()

retorno

Figura 3.10 –Modelo de Interação de Serviços.

O MIS pode ser construído como um diagrama de sequência ou de comunicação. É

importante notar que o MIS não deve conter mensagens reflexivas e não precisa exibir
a seqüência numérica, pois o objetivo é identificar apenas as operações das interfaces
e não como estas operações são realizadas. Ao final, as interfaces de serviços de
entidades não utilizadas são removidas.

Com a elaboração dos Modelos de Interação dos Serviços podem surgir novas
entidades que não foram identificadas previamente e identificar entidades não
utilizadas ou modeladas incorretamente, portanto, o MIN deverá ser atualizado. Após a
construção dos Modelos de Interação dos Serviços a Arquitetura de Serviço é
revisada levando-se em consideração as seguintes questões:

38
  Empacotamento das funcionalidades foi feito de forma correta?
 As funcionalidades ―isoladas‖ poderiam fazer parte de algum contrato de
serviço existente?
 Todas as funcionalidades foram contempladas?

A última atividade de Analisar Serviços é Identificar Componentes. Essa

atividade tem como objetivo construir o Modelo de Componentes dos Serviços
(MCS). O MCS é a primeira arquitetura ―componentizada‖ do sistema. O MCS também
pode ser construído a partir da transformação da AS e dos MIS através das seguintes
regras:

 os participantes exclusivamente consumidores são mapeados em

componentes;
 os contratos de serviços são mapeados em componentes e suas respectivas
interfaces (interfaces com o mesmo nome do contrato de serviço geradas na
atividade anterior);
 As operações das interfaces são obtidas diretamente das operações
identificadas no MIS.

A Figura 3.10 mostra visualmente as regras para construir o Modelo de

Componentes dos Serviços a partir da Arquitetura de Serviços.

39
 <<Service Contract>>
Pacote1 <<Service Contract>>
UC5-Ator2

consume provide provide

consume
<<Participant>>
<<Participant>> Ator2
<<Participant>> consume <<Service Contract>> Sistema
Ator1 Pacote2
provide

consume
provide
<<Service Contract>>
UC5
Arquitetura de Serviços

<<Service Contract>>
Service E1

Serviço de Entidade

Componente 1 ComponenteE1

IServiceE1
IService1

Compoente A Componente 2

IServicec2

Componente 4 Componente 3

IServicec4 IService3

Figura 3.11–Construção do Modelo de Componentes de Serviços.

Conforme ilustrado na Figura 3.11, participante ―Ator1‖ foi mapeado no

―Componente A‖ e os contratos de serviços:

 <<Service Contract>> Pacote 1 deu origem ao IService1 e Componente1

 <<Service Contract>> Pacote 2 deu origem ao IService2 e Componente1
 <<Service Contract>> UC5 deu origem ao IService4 e Componente4

40
  <<Service Contract>> UC5-Ator2 deu origem ao IService3 e Componente3

Conforme mostrado anteriormente, os modelos gerados em Analisar Serviços

podem ser construídos sistematicamente e/ou gerados por meio de transformações
(apenas o MIS completo deve ser criado manualmente pelo arquiteto). A Figura 3.12
mostra o fluxo completo das transformações de modelos envolvidos em Analisar
Serviços.
Modelo de
Funcionalidades

Modelo Informação
Transformação do Negócio
CIM-PIM

Modelo de
Arquitetura de
Transformação Interação de
Serviços
PIM-PIM Serviços (Template)

Modelo Informação
do Negócio
Refinado Transformação
PIM-PIM

Modelo de
Transformação Interação de
PIM-PIM Serviços (completo)

Modelo de
Componenes de
Serviços

Figura 3.12–Transformações de modelo da fase Analisar Serviços.

A Figura 3.13 mostra os modelos, meta-modelos e meta-linguagens utilizados em

Analisar Serviços.

41
 conforms To

MOF

conforms To
conforms To

UML2 MM SoaMLProfile MM
extends

instance Of
instance Of instance Of
instance Of instance Of

MF AS MIS MCS
MIN

Figura 3.13–Modelos da fase Analisar Serviços.

O Modelo Funcional (MF) e o Modelo de Informação do Negócio (MIN) são

modelos UML. A Arquitetura de Serviços (AS), Modelo de Interação de Serviços
(MIS) e Modelo de Componentes dos Serviços (MCS) são modelos SOAML. O
profile SoaML foi modelado conforme seu meta-modelo SoaML MM que foram
definidos com o MOF.

3.4 Projetar Serviços

Projetar serviços é o último workflow do processo e define como o sistema será

realizado, tendo como objetivos:
1. Desenvolver uma arquitetura detalhada e identificar novas oportunidades de
reuso para o sistema.
2. Evoluir o projeto arquitetural para cumprir com o que foi definido na
documentação.
3. Elaborar modelos que mostrem como os objetos colaboram para desempenhar
as operações das interfaces dos componentes.
4. Projetar o sistema para que ele execute em uma plataforma específica.

42
A Figura 3.14 apresenta o fluxo de atividades desta fase.

Figura 3.14–Diagrama de artefatos de Projetar serviços

Na primeira atividade, Definir Arquitetura do Sistema, é feita a revisão e o

refinamento dos modelos gerados na fase anterior. Baseado na documentação do
sistema e no conhecimento do negócio é uma boa prática revisar o Modelo de
Interação dos Serviços e Modelo de Componentes dos Serviços, gerados no
workflow anterior, levando-se em consideração as seguintes questões:

 Todos os componentes de front-end foram identificados?

43
  Podemos agrupar contratos de serviços semelhantes?
 Como será a integração entre o front-end e back-end? Como será feita a
comunicação com sistemas externos?
 É possível reutilizar, adaptar ou comprar componentes existentes?
Com isso, a atividade Definir Arquitetura do Sistema tem como saída a
Arquitetura do Sistema que é, basicamente, uma evolução da Arquitetura de
Componentes de Serviços com todos os elementos necessários para modelar os
componentes internamente e os componentes de front-end marcados com o
estereótipo <<Front-end>>. Com os modelos devidamente refinados, são definidos os
padrões, tecnologias e frameworks que serão utilizados no projeto do sistema.
Portanto, devem-se levar em consideração os seguintes aspectos:

 Plataformas de desenvolvimento e frameworks: quais serão as plataformas,

tecnologias e frameworks utilizados para o desenvolvimento do sistema?
 Integração front-end e back-end: como será a comunicação entre o font-end
e o back-end do sistema?
 Padrões de arquitetura: quais padrões de arquitetura serão utilizados no
desenvolvimento do sistema?
 Padrões de projetos: quais padrões de projetos serão utilizados na
modelagem de cada componente?

A Figura 3.15 mostra o exemplo de uma Arquitetura do Sistema.

<<Front-end>> <<Front-end>>
Desktop Mobile

ICommunication

Communication

IServiceContrac4 IServiceContrac1
IServiceContrac2

Componente 4 Componente 2 Componente 1 Componente 3

IServiceContrac3

Figura 3.15–Exemplo de Arquitetura do Sistema.

44
 Com a Arquitetura do Sistema definida, as atividades Projetar Front-end e
Projetar Fack-end podem ser feitas em paralelo. É importante destacar que o
processo induz, de forma sistemática, como ilustrado, à definição de uma interface
entre o front-end e o back-end (conforme ilustrado na Figura 3.15).
Para a atividade Projetar Back-end, deve-se seguir o seguinte fluxo de trabalho:

1. Projetar componentes: seguindo os padrões e regras definidas

anteriormente, para cada componente é construído seu diagrama de classes
e os diagramas de sequência de todas as operações da sua interface.
Portanto, é necessário detalhar a estrutura interna (atributo e operações) e
relacionamentos das classes projetadas, além de garantir que elas fornecem o
comportamento necessário para realizar as operações da interface do
componente.
2. Atualizar modelo de informação: com todos os componentes modelados
internamente, é necessário atualizar o modelo de informação do sistema.
3. Projetar banco de dados: com o modelo de informação refinado do sistema e
todos os componentes projetados, caso seja necessário, é feito o projeto de
banco de dados do sistema levando-se em consideração a tecnologia
utilizada.

Na atividade Projetar Front-end são construídos os diagramas de sequência e de

classe baseando-se no Protótipo da Interface Gráfica, a integração entre o front-end
e back-end, os guias e padrões definidos para cada componente front-end do sistema.
Da mesma forma que a fase Analisar Serviços, os modelos gerados na fase
Projetar Serviços podem ser construídos sistematicamente e/ou gerados por meio de
transformações. A Figura 3.16 mostra as transformações de modelos envolvidos na
fase Projetar Serviços.

45
 Padrões de
Transformação PIM- Restrições
Arquitetura
PIM

Guias Arquitetura Sistema Padrões de Projetos

Protótipo Interface
Gráfica

Tranformação
PIM-PIM

Diagramas Back- Diagramas Front-

end end

Modelo de
Transformação Transformação
Plataforma
(PIM -PSM) (PIM-PSM)

Modelos Front-end Modelos Back-end

PSM PSM

Figura 3.16–Transformação de modelos da fase Projetar Serviços.

Com todos os modelos do sistema devidamente refinados e atualizados é feita a

transformação dos modelos produzidos (PIM) até o momento para modelos
específicos para as plataformas utilizadas (PSM).
A Figura 3.17 mostra os modelos, meta-modelos e meta-metamodelos da fase
Projetar Serviços caso a plataforma escolhida para implementar todo o sistema fosse
Java.

46
 conforms To

MOF

conforms To

UML2 MM

instace Of

Modelos Front-end Modelos Back-end Arquitetura do Sistema

Figura 3.17–Modelos da fase Projetar Serviços

Em Projetar Serviços todos os modelos produzidos são modelos UML 2.0.

47
Capítulo 4 - Instanciação e Execução do

Processo

4.1 Introdução

Para apresentar em detalhes todas as atividades e artefatos apresentados no

capítulo anterior, será mostrada uma instanciação do processo com o objetivo de
permitir um uso prático e auxiliar os participantes no contexto do experimento.
Também foram definidas guias e ferramentas para facilitar a construção dos artefatos
e configurar um ambiente completo para execução do processo. A seção a seguir
mostra o sistema que será usado como exemplo.

4.2 Qualiti Internet Banking

O exemplo utilizado neste capitulo é o sistema Qualiti Internet Banking (QIB). Este
exemplo foi o mesmo utilizado no treinamento dos participantes do experimento que
será mostrado no próximo capitulo. O QIB é, basicamente, um sistema de internet
banking com os casos de uso mostrados na Figura 4.1. Mais detalhes sobre o sistema
podem ser encontrados em [30].

48
 Consultar Saldo

Realizar Transferência
Consultar Extrato

Consultar Cartão

Alterar Senha
Efetuar Pagamento Cartão

ClienteAtor
Efetuar Login

Operadora de Cartão

Figura 4.1–Casos de Uso do QIB.

No sistema é possível realizar transferências entre contas correntes, consultar

saldo e extrato, gerenciar a conta do usuário (login e senha), consultar e efetuar
pagamento do cartão de crédito (Qualiti Card). Para simplificar o sistema e ajudar na
construção dos artefatos, um cliente possui apenas uma conta corrente e um cartão de
crédito. As descrições dos casos de uso são mostradas no Apêndice B.

4.3 Especificar Modelo de Negócios

Conforme mostrado no capítulo anterior, o primeiro workflow do processo é

Especificar Modelo de Negócios e seu principal objetivo é gerar artefatos a fim de
garantir o alinhamento entre os stakeholder. Para isso, são gerados os artefatos:
Modelo de Informação do Negócio, Modelo de Funcionalidades, Modelo
Navegacional e Protótipo de Interface Gráfica.
A partir da análise da descrição de cada caso de uso é possível gerar o MIN com os
principais ―termos‖ (substantivos) mencionados; ao final, eles são unificados em um
modelo único, eliminando as duplicidades e redundâncias (termos com nomes
diferentes na descrição, mas que representam o mesmo conceito). No QIB foram
identificados quatro conceitos que o sistema deve manipular (Conta, Cliente,
PagamentoCartão e Comprovante), conforme ilustrado na Figura 4.2.

49
 Figura 4.2–Modelo de Informação de Negócio do QIB.

Conforme mencionado no Capítulo 3, o MF é, basicamente, um modelo de casos

de uso, agrupados em pacotes, com as funcionalidades (representados pelos casos
de uso) e os usuários (representados pelos atores) da aplicação.
Como ilustrado na Figura 4.3, a partir da descrição dos casos de uso do QIB
(Anexo I) os casos de uso foram agrupados em três pacotes distintos: Controle de
Acesso (funcionalidades relacionadas ao acesso dos usuários ao sistema), Controle
de Conta (relacionado a manipulação da conta bancária dos clientes) e Controle
QualitCard (funcionalidades relacionadas ao Qualit Card).

50
 Consultar Saldo

Realizar Transferência
Consultar Extrato

Consultar Cartão

Alterar Senha
Efetuar Pagamento Cartão

ClienteAtor
Efetuar Login

Casos de Uso
Operadora de Cartão

Controle Qualit Card

Controle Conta

Controle de Acesso ClienteAtor

Operadora de Cartão

Modelo de Funcionalidades

Figura 4.3–Modelo de Funcionalidades do QIB.

O QIB é um sistema simples e possui apenas quatro páginas principais (home,

minha página, ajuda e contato. Em ―minha página‖ ele poderá acessar as opções de
gerenciamento de conta corrente e cartão. Para elaborar o Modelo Navegacional foi
escolhido o sitemap, mais indicado para aplicações web, conforme mostrado na Figura
4.4.

Figura 4.4–Modelo Navegacional do QIB

51
 Para construção do MN em aplicações web recomenda-se o uso da ferramenta
Axure RP [28]. Em aplicações para dispositivos móveis recomenda-se o uso da
ferramenta Netbeans (versão completa com o Visual Mobile Designer) [50]. Se a
aplicação for simples até mesmo o PowerPoint ou o Visio pode ser utilizado para fazer
o MN.

Com o MN e MIN é possível construir o PIG que é o primeiro protótipo do sistema e

pode ser utilizado para validar as funcionalidades e avaliar a usabilidade do sistema. A
Figura 4.5 mostra o wireframe da tela inicial do sistema.

Figura 4.5–Protótipo de Interface Gráfica do QIB da tela login.

Para construção do PIG aconselhasse fortemente o uso de ferramentas de

prototipação como o Axure RP [28].

4.4 Analisar Serviços

O próximo workflow do processo é Analisar Serviços que tem como objetivo gerar
a primeira arquitetura do sistema. Para isso, são construídos os artefatos: Arquitetura
de Serviços, Modelo de Interação de Serviços, Modelo de Componentes dos
Serviços e o Modelo de Informação Refinado.
Para construir a Arquitetura de Serviço é necessário empacotar os casos de uso.
No exemplo do QIB, mostrado na Figura 4.6, os casos de uso Efetuar Login e Alterar
Senha foram agrupados no pacote Controle Acesso, Consultar Cartão e Efetuar
Pagamento Cartão no pacote Controle QualitCard, e os demais em Controle Conta.

52
 Controle Qualit Card
Controle Conta

Controle de Acesso ClienteAtor

Operadora de Cartão

Modelo de Funcionalidades

<<Service Contract>> <<Service Contract>>

ControleAcesso OperadoraCartao

provider consumer
consumer provider

<<Service Contractt>> <<participant>>

ControleConta <<participant>>
<<participant>> Sistema back-end Operadora Cartão
Cliente Front-end provider
consumer
consumer
consumer
<<Service Contract>>
ControleQualitiCard

Arquitetura de Serviços

Figura 4.6–Passo a passo para elaboração da Arquitetura de Serviços do QIB.

Depois, o ator cliente foi mapeado no participante ―Cliente Front-end‖ e o ator

Operadora de Cartão no participante ―Operadora Cartão‖. O relacionamento com o
ator Operadora de Cartão foi mapeado no contrato de serviço ―OperadoraCartão‖,
conforme indicado pela seta continua na Figura 4.6.
Os pacotes de casos de uso foram mapeados nos contratos de serviços
―ControleAcesso‖, ―ControleConta‖ e ―ControleQualitiCard‖. O participante ―Sistema
Back-End‖ surge para prover serviços ao ―Cliente Font-end‖ e consumir de ―Operadora
Cartão‖.
O segundo artefato a ser gerado em Analisar Serviços é o Modelo de Interação
dos Serviços (MIS). Conforme mencionado anteriormente, para construir o MIS é

53
necessário identificar os serviços de entidades, um tipo de serviço que é derivado de
uma ou mais entidades de negócio relacionadas e possuem alto grau de reutilização:
serviços que fazem operações CRUD (Create, Read, Update, Delete), por exemplo. As
Figuras 4.7 e 4.8 mostram os serviços de entidades e um dos MIS do QIB.

<<Service Contract>> <<Service Contract>> <<Service Contract>>

ContaInternet ContaBancaria Transação

Figura 4.7–Serviços de Entidade do QIB.

: Cliente Front-end : IControleAcesso : IContaInternet

logar(login,senha)
existe(login, senha)

sessão ContaInternet

alterar(login,antiga, nova)

existe(login,senha)

ContaInternet

atualizar(ContaInternet)
sessão Conta Internet

Figura 4.8–Modelo de Interação de Serviço do QIB.

Conforme as regras descritas no capítulo anterior, o MIS relacionado ao contrato de

serviço ―ControleAcesso‖, mostrado na Figura 4.8, contém as interfaces
IControleAcesso, IContaInternet e o consumidor Client Front-end. As mensagens entre
os elementos foram adicionadas de acordo com a descrição dos casos de uso
relacionados ao contrato de serviço ―Controle Acesso‖ (Efetuar Login e Alterar Senha
descritos no Apêndice B).

54
 Após a construção dos modelos de interação dos serviços foi verificado que a
entidade PagamentoCartão era na verdade uma Transação e surgiram os atributos
das entidades, por isso, o MIN foi atualizado. A Figura 4.9 mostra o MIN atualizado.

Transacao
ContaBancaria ContaintInternet
+numero da fatura
+numero +login +data
+saldo +senha +valor
+numero da conta

Figura 4.9–MIN Refinado do QIB.

O último artefato a ser gerado é o Modelo de Componentes dos Serviços (MCS).

A Figura 4.10 mostra o MCS do QIB.

<<Front-end>>
Cliente Front-end

IControleAcesso IControleConta IControleQualitCard

Controle de Acesso Controle Conta Controle QualitCard

IOperadoraCartão
IContaInternet ITransação
IContaBancaria
OperadoraCartão
ContaInternet ContaBancaria Transação

Figura 4.10–Modelo de Componentes dos Serviços do QIB.

Como se pode observar na Figura 4.10, o MCS foi construído sistematicamente

seguindo as regras mostradas no capítulo anterior:
1. o participante consumidor (Clitente Front-end na parte inferior da Figura 4.6)
foi mapeado no componente ―Cliente Front-end‖ (Figura 4.10)
2. os contratos de serviços da AS do sistema (―ControleAcesso‖,
―ControleConta‖, ―ControleQualitiCard‖ e ―OperadoraCartão‖ - Figura 4.6)
foram transformados em componentes (―ControleAcesso‖, ―ControleConta‖ e

55
 ―ControleQualitiCard‖ - Figura 4.6) e suas interfaces (IControleAcesso,
IControleConta e IControleQualitiCard – e Figura 4.10).
3. os serviços de entidades (ContaInternet, ContaBancaria, Transação na
Figura 4.7) foram transformados em componentes (―ContaInternet’,
―ContaBancaria‖ e ―Transação‖ – Figura 4.10) e suas interfaces (IContaInternet,
IContaBancaria e ITransacao – Figura 4.10).

4. O participante ―OperadotaCartão‖ (Figura 4.6) foi transformado no componente

―OperadoraCartão‖ (Figura 4.10) e sua interface ―IOperadoraCartão‖ (Figura
4.10) foi gerada a partir do contratado de serviço ―OperadoraCartão‖ (Figura
4.6).
Como ferramenta de modelagem para esse workflow, aconselhasse o uso das
ferramentas Magic Draw4 com o plugin Cameo SOA+5 ou o Rational Software
Archtect6, pois elas possuem o profile SoaML completo. Mas como os modelos SoaML
utilizados pelo processo podem ser facilmente representados com estereótipos,
também podem ser usadas outras ferramentas de modelagens UML 2.0 como astah
community7 (antigo JUDE Community) ou o StarUML8 (ferramenta utilizada neste
trabalho).

4.5 Projetar Serviços

No começo da fase Projetar Serviços é feita a revisão e o refinamento dos

modelos gerados na fase anterior e depois é elaborada a Arquitetura do Sistema.
Para isso é recomendado responder as seguintes questões:
 Empacotamento das funcionalidades foi feito de forma correta? As
funcionalidades ―isoladas” poderiam fazer parte de algum contrato de serviço
existente?

4 https://www.magicdraw.com/
5 https://www.magicdraw.com/cameo_soa
6 http://www.ibm.com/developerworks/rational/products/rsa/
7 http://astah.net/editions/community
8 http://staruml.sourceforge.net/en/

56
 Resposta: Todos os casos de uso foram empacotados seguindo critérios de
coesão e acoplamento e, pelo sistema ser simples, nenhuma funcionalidade
ficou isolada.
 Todos os componentes de front-end foram identificados?
Resposta: Não. Por isso, foram identificados três novos componentes que
representam as aplicações Front-end do sistema (mobile, web e desktop).
 Podemos agrupar contratos de serviços semelhantes?
Resposta: Não. Todos os serviços identificados possuem granularidade fina.
 Todas as funcionalidades foram contempladas?
Resposta: Sim. Todos os casos de uso foram realizados.
 Como será a integração entre o front-end e back-end? Como será feita a
comunicação com sistemas externos?
Resposta: A integração será feita utilizando web services.
 É possível reutilizar ou comprar componentes existentes?
Resposta: Não. Todos os componentes serão implementados devido a
restrição do cliente.
Portanto, a Figura 4.11 mostra a Arquitetura do Sistema do QIB levando-se
em consideração as questões acima.

57
 Front-end Iphone
Front-end Web Front-end Desktop

IFachadaWebSercice

WebService

IControleAcesso IControleConta IControleQualitCard

Controle de Acesso Controle Conta Controle QualitCard

IContaInternet ITransação IOperadoraCartão

IContaBancaria

Transação OperadoraCartão
ContaInternet ContaBancaria

Figura 4.11–Arquitetura do Sistema.

Para construir a arquitetura foram levadas em consideração as seguintes

definições:

 Plataformas de desenvolvimento e frameworks: o back-end será

implementado em .Net utilizando NHibernate [31], o front-end desktop em Java
utilizando o JPA [32] e o front-end para dispositivos móveis em iPhone.
 Integração front-end e back-end: a comunicação será implementada
utilizando web services [7].
 Padrões de arquitetura: O sistema back-end seguirá o padrão N-Tier [33] e o
font-end iPhone e desktop o padrão MVC [34].
 Padrões de projetos: O componente OperadoraCartão utilizará o padrão
Observer para chamadas assíncronas ao sistema de cartão de crédito. Além
disso, todos os componentes deverão utilizar o padrão singleton e facade.

58
 Após a construção da Arquitetura do Sistema e a descrição dos padrões a serem
utilizados, são elaborados os diagramas de classes e sequência de cada componente
do sistema. A Figura 4.12 mostra o diagrama de classe do componente
ControleAcesso. Na Figura 4.13 é mostrado o diagrama de sequência para a operação
EfetuarLogin.

ControladorControleAcesso ContaintInternet

+logar(login, senha) +login

+alterarSenha(login, senhaAtual, SenhaNova) +senha

IControleAcesso

+logar(login, senha)
+alterarSenha(login, senhaAtual, SenhaNova)

IContaInternet

+inserir(ContaInternet)
+remover(ContaInternet)
+atualizar(ContaInternet)
+existe(login, senha)

Figura 4.12–Diagrama de classes do componente ControleAcesso.

: FachadaWebservice : IControleAcesso : IContaInternet

1 : logar() 2 : existe()

3 : true
4 : session

Figura 4.13–Diagrama de Seqüência de Efetuar Login.

Por fim, são construídos os diagramas de seqüência e de classe baseando-se no

Protótipo da Interface Gráfica. A Figura 4.14 ilustra a construção das classes da

59
interface gráfica do sistema. Os diagramas de classe e sequência, simplificado, do
front-end desktop do QIB são mostrados na Figura 4.15.

Figura 4.14–Construção da Interface Gráfica Desktop do QIB.

ComunicacaoWebService
TelaLogin

+loginText: TextField +logar()

+senhatext: TextField +chamarWebService()
+logarButton: JButton IComunicacaoWebService

+efeturarLoginr()

: TelaLogin : ComunicacaoWebService

: ClienteAtor
1 : efeturarLogin()
2 : logar()
3 : chamarWebService()

Figura 4.15–Diagrama de Classe e seqüência do Desktop.

60
Capítulo 5 - Avaliação do Processo

5.1 Introdução

No Capítulo 3 foi apresentado um processo de projeto arquitetural de software

orientado a modelo e baseado em SOA, portanto, uma análise deve ser feita para
compreender e avaliar se o processo proposto atinge seus objetivos. Neste contexto,
este capítulo apresentada um experimento para avaliar o novo processo proposto
levando-se em consideração alguns critérios de desenvolvimentos de software como:
modularidade, complexidade, estabilidade, facilidade de utilização e entendimento.
Esta seção apresenta em detalhes o estudo experimental feito para avaliar o
processo. O experimento foi definido usando a abordagem Goal Question Metric (GQM)
[6]. O GQM é composto por quatro fases (definição, planejamento, coleta de dados e
interpretação) que orientam o experimento, estabelecendo o objetivo do estudo, as
perguntas a serem respondidas, e as métricas utilizadas para interpretar as respostas.
Informações mais detalhadas sobre experimentação na área de engenharia de
software pode ser encontrada em [37].

5.2 Definição

Na fase de definição são definidos os objetivos do experimento, as

questões a serem respondidas e as métricas relacionadas que devem ser
colhidas para ajudar a responder as questões. Além disso, é preciso definir o objeto
de estudo, o foco, o ponto de vista e o contexto.
O objetivo do experimento é analisar o processo de desenvolvimento para
avaliar a sua eficiência e dificuldade de uso, do ponto de vista do arquiteto de
software e no contexto de projeto de sistemas de software.
Para atingir o objetivo do experimento é preciso definir questões qualitativas e
métricas. As métricas são mais eficazes quando associadas a alguma estrutura de
medição, facilitando a compreensão do relacionamento entre as questões, métricas e

61
a interpretação dos dados que serão coletados [38]. Por isso, este trabalho utilizou um
framework de medição baseado nas métricas definidas e refinadas em [22]. A Figura
5.1 mostra o framework de medição utilizado.

Framework de Medição
Variável de
resposta

Qualidade de
Projeto
Qualidades

Reusabilidade Manutenibilidade
Fatores

Complexidade Compreensibilidade Modularidade Estabilidade

Atributos

Tamanho Acoplamento Instabilidade

Métricas

WOCS CBCS IMSC

Figura 5.1–Framework de medição.

As questões e as métricas utilizadas são apresentadas a seguir:

62
 Questão 1: O processo de desenvolvimento gera serviços e componentes de baixa
complexidade?
Dependências estruturais entre os serviços e componentes
(relações cliente-consumidor) têm influência considerável sobre a complexidade dos
sistemas. Por isso, a métrica a seguir foi utilizada para ajudar a responder a questão 1:

 Métrica 1 (M1): Weighted Operations per Component or Service (WOCS).

Métrica utilizada para medir a complexidade de componentes e serviços
utilizada em [22]. A quantidade e complexidades das operações de um
componente ou serviço são diretamente relacionadas ao tempo e esforço
necessários para desenvolvê-los e mantê-los. Assim, as WOCS medem a
complexidade do serviço ou componente, em termos de suas
operações (métodos) que serão utilizados por outros serviços ou componentes.
Considere um componente (ou serviço) C com operações O1,...,On. Onde c1,...,
cn são as complexidades das operações. Então:

Esta métrica indica que operações com muitos parâmetros formais são mais
complexas do que operações que exigem menos parâmetros. Neste sentido, a
complexidade da operação On pode ser definida da seguinte forma: cn = α + 1,
onde α denota o número de parâmetros formais de On. De acordo com [39],
valores até 10 são considerados aceitáveis para aplicação simples.

Questão 2. O processo de desenvolvimento gera serviços e componentes

estáveis?
Uma única mudança pode encadear mudanças em cascata nos componentes e
serviços de uma aplicação. Tornando a arquitetura frágil, dificultando o
desenvolvimento e o reuso. Por isso, a métrica a seguir foi utilizada para ajudar a
responder a questão 2:

63
  Métrica 2 (M2): Instability Metric for Service or Component (IMSC). O IMSC é
uma métrica para medir a instabilidade dos componentes ou serviços de uma
aplicação baseada no fan.in e fan.out.
O fan.in de uma função A é o número de funções que chamam a função A. O
fan.out de uma função A é o número de funções que a função A chama. Ou
seja, as funções com um fan.out alto são mais difíceis de manter. E funções
com fan.in grande são bastante utilizadas. O fan-in e fan.out são métricas
utilizadas para estimar a complexidade de manutenção de softwares [40].
Baseado nestas métricas, Perepletchikov definiu uma nova métrica para
medir a interação entre um serviço ou componente por meio do envio e
recebimento de mensagens [41]. Ele definiu que o fan.in de um serviço S é o
número de mensagens que S recebe. E fan.out é o número de mensagens que
ele envia. Com isso, ele propos a seguinte formula:

De acordo com [41] quanto mais próximo de 0, mais estável é o serviço. Se o

IMSC = 1, o serviço é muito instável e difícil de manter.

Questão 3: O processo de desenvolvimento gera serviços e componentes com

baixo grau de acoplamento?
O baixo grau de acoplamento entre os componentes e serviços de uma aplicação
indica uma arquitetura modular. Aplicações modulares potencializam benefícios em
vários aspectos: velocidade no desenvolvimento, redução de custo no
desenvolvimento, flexibilidade e reusabilidade. Por isso, a métrica 3 foi utilizada para
ajudar a responder a questão acima:

 Métrica 3 (M3): Coupling Between Components or Services (CBCS).

Esta métrica é calculada baseando-se no número de relacionamentos dos
componentes ou serviços:

64
 Seja n o número de serviços da aplicação, então se o serviço não
está conectado ao serviço , caso contrário . Para um serviço A
quanto maior o CBCS, maior o acoplamento com outros serviços. Está métrica
foi utilizada em [22]. Valores maiores que seis indicam alto grau de
acoplamento [41].

Questão 4: Os participantes tiveram dificuldade em entender e aplicar o processo?

A fim de compreender as dificuldades que os participantes irão enfrentar durante a
adoção do novo processo, eles serão solicitados a informar as dificuldades
enfrentadas ao final da fase de execução. Para ajudar a responder a esta questão, a
métrica a seguir foi definida:

 Métrica 4 (M4): Dificuldade em utilizar o processo: Porcentagem dos

participantes que acharam o processo difícil. Métrica que mede a dificuldade de
aplicação e entendimento do processo. Esta métrica foi baseada na avaliação
do processo proposto no trabalho [9].

Questão 5: O processo ajuda a alinhar o entendimento entre os stakeholders?

Com o intuito de avaliar se o processo ajuda no alinhamento do entendido entre os
envolvidos no projeto foi criada a métrica 5:

 Métrica 5 (M5). Alinhamento entre os stakeholders: Porcentagem dos

participantes que concordaram que o processo ajuda no alinhamento de
entendimento entre os stakeholders.

Questão 6: O processo desacopla o front-end e back-end?

A fim de avaliar se o processo proposto contribui para o desacoplamento entre o
front-end e back-end das aplicações foi criada a métrica 6:

65
  M6. Desacoplamento entre front-end e back-end: Porcentagem dos
participantes que concordaram que o processo ajuda no desacoplamento entre
front-end e back-end.

As métricas M1, M2 e M3 também fazem parte do framework de métricas utilizado

em [22]. A M4 foi baseada em [9]. M5 e M6 foram baseadas em experiência prática,
senso comum e definidas especificamente para avaliação deste trabalho.

5.3 Planejamento

O experimento foi conduzido na disciplina Análise e Projeto de Sistemas do Centro

de Informática da UFPE9 no segundo semestre de 2010 (agosto até dezembro). Foi
um experimento off-line (não foi aplicado na indústria) e todos os participantes eram
graduandos dos cursos de Ciência da Computação e Engenharia da Computação a
partir do sexto período.

Para coletar as métricas quantitativas (M1, M2 e M3) foram utilizados as seguintes

ferramentas de modelagem: StarUML10, Rational Software Architect11 e JUDE12. Para
coletar as métricas qualitativas (M4, M5 e M6) foi utilizado o questionário de perguntas
e resposta mostrado no Apêndice A. A avaliação do experimento foi feita baseando-se
nas seguintes hipóteses:
Hipóteses nulas. As hipóteses nulas (H0) são as que o experimento quer rejeitar
fortemente:
H0a: μ WOCS ≥ 10
H0b: μ CBCS ≥ 6
H0c: μ IMSC ≥ 0,5
H0d: μ Dificuldade em utilizar o processo >=30 %
H0e: μ Alinhamento entre os stakeholders <=70 %

9 Página da disciplina: www.cin.ufpe.br/~if678

10 Ferramenta StarUML: http://staruml.sourceforge.net/
11 RSA: http://www.ibm.com/developerworks/rational/products/rsa/
12 JUDE: http://jude.change-vision.com/jude-web/product/community.html

66
 H0f: μ Desacoplamento entre front-end e back-end <=70 %

Hipóteses alternativas. As hipóteses alternativas (H1) são as hipóteses contrárias

às hipóteses nulas e que o experimento espera aceitar:
H1a: μ WOCS < 10
H1b: μ CBCS <6
H1c: μ IMSC <0,5
H1d: μ Dificuldade em utilizar o processo <30 %
H1e: μ Alinhamento entre os stakeholders >70 %
H1f: μ Desacoplamento entre front-end e back-end >70 %

As hipóteses referentes às métricas WOCS, CBCS e IMSC foram as mesmas

definidas e utilizadas em [22], a dificuldade em utilizar o processo foi baseada em [9],
as demais foram definidas e utilizadas pela primeira vez neste trabalho. A seguir será
mostrada a validade do experimento:

 Validade Interna: a validade interna é definida como a capacidade de um novo

experimento de repetir o comportamento do atual, com os mesmos temas
e objetos com os quais ele foi executado. Neste caso, a validade interna deste
experimento depende da quantidade de participantes, pois deve ter no mínimo
um grupo com três integrantes.
 Validade externa: a validade externa define as condições que limitam a
habilidade de generalizar o experimento. A quantidade e diversidade de
projetos desenvolvidos se mostraram suficientes para que o experimento possa
ser aplicado em diferentes domínios.
 Validade de conclusão: a validade de conclusão é relacionada à habilidade
do experimento em chegar a uma conclusão. Neste caso, o experimento feito é
válido, pois pode se chegar às conclusões desejadas através de uma análise
matemática simples que será mostrado na próxima seção.

Por fim, as seguintes ameaças à validade do experimento foram identificadas e

tratadas:

67
  Motivação dos participantes. Os participantes poderiam escolher os seus
grupos e, em se tratando de alunos de graduação, poderia ser o caso de nem
todos participarem efetivamente do projeto. Para tratar essa ameaça, todos os
alunos tinham que apresentar e participar ativamente na apresentação dos
projetos sob pena de perder pontos na nota final da disciplina.
 Experiência dos participantes. Os resultados podem ser influenciados pela
falta de conhecimento e experiência prática dos participantes, pois todos eram
alunos de graduação e a maioria não tinha experiência profissional no
desenvolvimento de software. Para contornar essa ameaça foram ministradas
aulas práticas para auxiliar e treinar os participantes no desenvolvimento dos
projetos.
 Complexidade e formato dos projetos. Os projetos foram propostos pelos
participantes e não chegaram a ser implementados. Isso pode influenciar
negativamente as métricas M1,M2 e M3. Para mitigar essa ameaça foram
definidos requisitos mínimos (número de casos de uso, interação com sistemas
externos, por exemplo) para a elaboração dos projetos.

5.4 Operação

Os alunos tiveram aulas introdutórias sobre o RUP (processo normalmente

ensinado na disciplina) e o processo apresentado neste trabalho. Depois das aulas
introdutórias, os alunos se dividiram em grupos com até quatro integrantes e tiveram a
opção de desenvolver seus projetos utilizando o RUP ou o processo SOA/MDE aqui
proposto. Os projetos foram sugeridos pelos próprios alunos e foram avaliados para
verificar se tinham um grau de complexidade mínimo requerido para disciplina.
Cinco grupos13 escolheram utilizar o processo SOA/MDE, totalizando 19 alunos
participantes do experimento. A Tabela 5.1 mostra as informações de cada grupo.

13 Grupos e Projetos: www.cin.ufpe.br/~if718/proj2010-2.html

68
 Projetos Componentes analisados Participantes

Projeto 1 11 4
Projeto 2 14 4
Projeto 3 10 4
Projeto 4 6 4
Projeto 5 10 3
Total 51 19
Tabela 5.1. Dados dos Projetos.

Após a divisão das equipes foram ministradas 24 horas de aulas práticas e teóricas14
(8 horas para cada fase do processo), para mostrar todas as atividades e artefatos
produzidos pelo processo.
No final da disciplina, os grupos apresentaram os artefatos gerados pelo processo e
disponibilizaram todos os modelos construídos (arquivos de ferramentas CASE) no
projeto. No final da disciplina foi aplicado um formulário de avaliação sobre o
processo15.

5.5 Coleta e Análise dos Dados

Com os modelos gerados pelas equipes foi possível coletar e calcular

manualmente, através das ferramentas CASE utilizadas, as métricas WOCS, CBCS e
ISMC. Com as respostas do questionário foi possível coletar as demais métricas. A
Tabela 5.2 mostra os resultados obtidos, levando-se em consideração a modularidade
(CBCS) dos projetos.

14 Cronograma das aulas: www.cin.ufpe.br/~if718/proj2010-2.html

15 Questionário: http://www.cin.ufpe.br/~vtb/experimento/Formulario.docx

69
 Projetos CBCS

média min max

Projeto 1 2,46 1 5
Projeto 2 2,57 1 9
Projeto 3 3,3 1 6
Projeto 4 2,83 2 4
Projeto 5 2,3 1 4
Total 2,69 1 9
Resultado: H0: CBCS > 6 (rejeitada)
Tabela 5.2. Resultados da métrica CBCS.

A análise estatística dos dados mostra que a média CBCS (2,69) rejeitou
fortemente a hipótese nula. Isto indica que o processo colabora para o
desenvolvimento de componentes e serviços com baixo acoplamento, pois valores
abaixo de 6 são considerados aceitáveis para aplicações simples [22]. Outro ponto
importante é que nenhum projeto apresentou média CBCS próxima de 6 (máxima foi
3,3). A Tabela 5.3 mostra os resultados obtidos para a métrica de complexidade
(WOCS).

Projetos WOCS

média min max

Projeto 1 6,73 2 28
Projeto 2 10,57 3 44
Projeto 3 8,9 1 14
Projeto 4 9,17 3 22
Projeto 5 10,2 3 16
Total 9,12 1 44
Resultado: H0: WOCS >= 10 (rejeitada)
Tabela 5.3. Resultados da métrica WOCS.

Como podemos observar na Tabela 5.3, a média WOCS foi de 9,12 (valores até 10
são aceitáveis para aplicações simples [22]) e rejeitou a hipótese nula, mostrando que

70
o processo contribui significantemente para a redução da complexidade dos
componentes e serviços desenvolvidos.
A Tabela 5.4 mostra os resultados obtidos, levando-se em consideração a
instabilidade dos componentes e serviços projetados.
Projetos IMSC
média min max
Projeto 1 0,25 0 0,8
Projeto 2 0,38 0 0,66
Projeto 3 0,37 0 0,8
Projeto 4 0,44 0 0,66
Projeto 5 0,25 0 0,57
Total 0,34 0 0,8
Resultado: H0: IMSC >= 0,5 (rejeitada)
Tabela 5.4. Resultados da métrica IMSC.

A análise dos dados da Tabela 5.4 mostra que a média IMSC foi 0,34 e rejeitou
fortemente a hipótese nula. Isto é um forte indício que o processo colabora para o
desenvolvimento de componentes e serviços estáveis, pois valores mais próximos de
zero indicam estabilidade alta. Outro ponto importante é que nenhum projeto
apresentou média IMSC próxima de 1 (máxima foi 0,44).
Os gráficos das Figuras 5.2, 5.3 e 5.4 mostram os resultados obtidos com o
questionário de avaliação do processo.

Figura 5.2 - Gráfico de avaliação da dificuldade do processo.

71
 Os dados da Figura 5.2 apontam que o processo de desenvolvimento não é difícil,
apenas 14% acharam o processo difícil, rejeitando a hipótese nula H0d (μ Dificuldade
em utilizar o processo >=30 %).

Figura 5.3 - Gráfico da avaliação do alinhamento entre os stakeholders.

O gráfico da Figura 5.3 mostra que 100% dos participantes concordaram que o
processo ajuda no alinhamento entre os stakeholders, rejeitando fortemente a hipótese
nula H0e (μAlinhamento entre os stakeholders <=70 %).

Figura 5.4 - Avaliação do desacoplamento entre front-end e back-end.

A análise do gráfico da Figura 5.4 mostra que 100% dos participantes responderam
que concordam que o processo contribui para o desacoplamento entre o front-end e
back-end, rejeitando fortemente a hipótese nula H0f (μ Desacoplamento entre front-
end e back-end <= 70%).

72
 Portanto, os dados obtidos no experimento indicam que o processo cumpre com
seus principais objetivos, além de colaborar para o desenvolvimento de uma
arquitetura com serviços e componentes estáveis, com baixo grau de acoplamento e
complexidade.
Apesar da maioria dos participantes não ter experiência em projetos reais (90%
nunca tinham participado de projetos envolvendo clientes reais) todos os projetos
apresentaram serviços com granularidade fina e sem problemas graves na arquitetura.
Um fato interessante é que apesar das limitações de tempo e escopo da disciplina
em que foi aplicado o experimento, os participantes se mostraram motivados e com
vontade de aprender novos paradigmas de desenvolvimento de software e faziam
perguntas relevantes contribuindo ativamente para a melhoria do processo. Como
prova disso, 84% marcaram no questionário que tinham interesse em aprender mais
sobre o processo em outra disciplina.
Outro fato interessante é que com a resposta dos questionários os participantes
sugeriram mais detalhes e guias para as atividades do workflow Projetar Serviços.
Com essas respostas foi possível identificar as deficiências e melhorar os detalhes das
atividades do processo.

5.6 Lições Aprendidas

Como lições aprendidas no experimento pode-se destacar:

 Simplicidade e facilidade de uso do Processo: A maioria dos participantes

concordou que, no geral, o processo é fácil (27%) ou razoável (59%) e apenas
14% considerou o processo difícil e nenhum muito difícil de aplicar.
 Avaliação da produtividade e qualidade das aplicações: No estudo
experimental, os participantes não chegaram a codificar os projetos propostos,
apenas produziram os modelos. Com isso, não foi possível avaliar a
produtividade e métricas de qualidade como Lack of Cohesion over Operations
(LCOO), Cyclomatic Complexity (CC) e Concern Diffusion over Components or
Services (CDCS) [22]. Além disso, a média de WOCS foi alta (9,12), indicando
uma complexidade considerável para os componentes modelados.

73
 Dificuldades na fase Projetar Serviços: 32% dos participantes do
experimento acharam a fase Projetar Serviço difícil e 36% tiveram dificuldade
em produzir os artefatos. Estes dados indicam que a fase pode estar complexa
e ou o material de treinamento não foi adequado.
 Comparação com outras abordagens: Para melhorar a avaliação do
processo, os participantes poderiam ter sido expostos aos dois processos e ao
final poderia ter sido feita uma análise mais completa com a comparação dos
resultados. Também poderiam ter sido expostos a outros processos SOA/MDD
e não o RUP. Isso não foi feito devido às restrições de tempo e escopo da
disciplina.
 Avaliação da métrica M5: Para avaliar o alinhamento de entendimento entre
os stakeholders, os participantes das outras equipes foram incentivados a fazer
perguntas e questionamento aos outros grupos, para de fato compreender
como iria funcionar os projetos das outras equipes. Contornando assim o fato
de todos os participantes estarem na mesma ―ponta‖ do alinhamento.
 Validade do questionário e das métricas M4: A métrica M4 é altamente
dependente da experiência dos participantes do experimento e do tamanho do
projeto das equipes, por isso os resultados obtidos possuem pouco valor para
se tecer análises que o generalizem.

74
Capítulo 6 - Conclusão

O trabalho investigou as complementaridades e vantagens de utilizar MDD e

SOA em conjunto, e apresentou um processo de projeto arquitetural de software
dirigido a modelos e orientado a serviços a fim de possibilitar o projeto de arquiteturas
estáveis, flexíveis e modulares.
Para isso, o processo foi dividido em três conjuntos de atividades distintos:
Especificar Modelo de Negócio, Analisar Serviços e Projetar Serviços. Em
Especificar Modelo de Negócio são gerados artefatos que ajudam no alinhamento
das expectativas entre os stakeholders. Analisar Serviços define atividades para
projetar a arquitetura do sistema independente de plataforma de desenvolvimento. Em
Projetar Serviços são definidas atividades para refinar os modelos produzidos nas
atividades anteriores e transformá-los em modelos menos abstratos e projetados para
executar em plataformas específicas.
Para avaliar aspectos quantitativos e qualitativos do processo, foram apresentadas
em detalhes as fases do estudo experimental executado em uma disciplina de
graduação do Centro de Informática da UFPE.

6.1 Principais contribuições

O processo é sistemático, fácil de usar e compreender, independente de

ferramentas e tecnologias, e foi capaz de resolver problemas práticos como: a
integração de aplicações, o acoplamento entre front-end e back-end dos sistemas, e o
desalinhamento de expectativas entre os stakeholders. Como principais contribuições
deste trabalho, podemos destacar:

1. Definição de um processo sistemático para projeto arquitetural de

software dirigido a modelos e orientado a serviços, proporcionando:

75
 o Aumento na reutilização de software: Nas primeiras fases do
processo é possível identificar oportunidades de reuso. Como forte
indício para comprovar o aumento no reuso, em todos os projetos do
experimento foram identificados um ou mais serviços com alto grau de
reutilização (serviços utilitários).
o Projeto de arquiteturas modulares e estáveis: Seguindo as
atividades do projeto é possível projetar uma arquitetura modular e com
componentes desacoplados. Como forte indício para comprovar isso, a
média CBCS nos projetos foi 2,69 (indica baixo grau de acoplamento
entre os componentes) e a média IMSC foi 0,34 (indica estabilidade).
o Alinhamento no entendimento entre os stakeholders. Os dados
obtidos no estudo experimental indicam que o processo ajuda a alinhar
as expectativas entre os envolvidos no projeto, pois 100% dos
participantes responderam um questionário concordando que o
processo contribui para o alinhamento do entendimento entre todos os
stakeholders.
o Praticidade e facilidade de uso: A maioria dos participantes
concordou que, no geral, o processo é fácil (27%) ou razoável (59%) e
apenas 14% considerou o processo difícil. Além disso, o processo
utiliza conceitos, fundamentos, artefatos e modelos bastante utilizados
tanto na indústria como na academia.
o Avaliação através de um estudo experimental. O processo foi
avaliado em um estudo experimental envolvendo 19 alunos de
graduação da UFPE e executado em cinco projetos distintos.

6.2 Trabalhos Relacionados

Devido a grandes esforços na pesquisa e aplicação de MDD e SOA nos últimos

anos, alguns trabalhos também tem investigado suas complementaridades e
vantagens de uso em conjunto. Por exemplo, Castro et al.[69] apresentou SOD-M,
uma abordagem de desenvolvimento orientada a serviço para a construção de
sistemas de informações. Na abordagem apresentada, os modelos de composição de

76
web services são construídos a partir de modelos de negócios de alto
nível, facilitando o alinhamento dos processos comerciais de alto nível com as
tecnologias disponíveis, seguindo o paradigma SOC (Service Oriented Computing).
Marzullo et al. [68] apresentou uma metodologia para construção de protótipos de
arquitetura com o objetivo de acelerar o processo de desenvolvimento de software. A
arquitetura é construída utilizando MDA e SOA. O trabalho mostra que a abordagem
utilizada pode promover um ambiente de desenvolvimento mais eficiente, e que a
arquitetura pode se adaptar continuamente às mudanças no ambiente de negócios. O
estudo de caso apresentado foi baseado em um projeto real reaizado no NALIM
(Núcleo de Apoio Logístico Integrado da Marinha).
Em [70] é apresentado uma abordagem de desenvolvimento orientada a modelos
para construção de serviços de telecomunicações para dispositivos móveis. Nesse
trabalho foi desenvolvido um profile UML para construção das aplicações portáveis
para diversas plataformas.
Em [71] é mostrado o MINERVA, um framework dirigido a modelos e orientado a
serviços para melhoria continua de processos de negócio. O framework foi definido em
três dimensões: conceitual, metodológica e suporte ferramental. O trabalho mostra que
utilizando o framework é possível obter automaticamente os modelos de serviços
(modelos SoaML) a partir de modelos de negócios (modelos BPMN).
Em [67] é apresentada uma abordagem orientada a modelos para aplicar estilos
arquiteturais em modelos SOA. A abordagem define templates arquiteturais que
servem de entradas para as transformações dos modelos dos serviços. Em [73] é
apresentado o SOSA, uma abordagem orientada a modelos para projetar arquitetura
de software orientada a serviços independente de plataforma (no nível do PIM). A
abordagem faz parte da metodologia MIDAS [24], um framework para o
desenvolvimento de sistemas de informação baseado em MDA.
A fim de obter uma melhor compreensão quanto às vantagens e limitações
expostas neste trabalho, foi realizada uma análise comparativa do processo proposto
e dos trabalhos relacionados mencionados anteriormente. A Tabela 6.1 mostra o
resultado dessa análise.

77
 Precisão Cobertura do Arquitetura Independente Suporte a
Domínio
do ciclo de vida vinculada às de ferramentas decicões
restrito
Processo genérico transformações e tecnologias arquiteturais

A Study Case on Domain-Driven

Development, Using MDA, SOA and baixa não não sim não não
Web Services [68]
SOD-M [69] alta sim sim não sim sim
Realizing an MDA and SOA Marriage
for the Development of Mobile médio não não sim não não
Services [70]
Minerva [71] baixa não sim sim não sim
A Model-Driven Approach to Weave
Architectural Styles into Service- médio não sim sim não não
Oriented Architectures [67]
SOSA [73] alta sim não sim não não
O processo proposto no trabalho alta não não não sim sim
Tabela 6.1. Resultados da análise.

A análise mostrada na Tabela 6.1 foi feita de acordo com os critérios apresentados
em [74], adicionando as limitações e deficiências encontradas em algumas
metodologias mostradas na introdução:

 Precisão do processo: se o processo é detalho o suficiente para ser

efetivamente seguido pelas pessoas envolvidas no projeto.
 Cobertura do ciclo de vida genérico: a metodologia abrange as fases e
atividades do clico genérico de desenvolvimento de software.
 Domínio restrito: o escopo dos projetos e domínios para os quais a
metodologia é aplicável. Algumas metodologias propostas não são de uso
geral o suficiente ou não foram avaliada em vários domínios (é o caso do
processo proposto).
 Arquitetura vinculada às transformações: se a arquitetura final do sistema é
atrelada às transformações automáticas dos modelos.
 Independente de tecnologias ou ferramentas: se o processo depende de
ferramentas para ser executado completamente ou se é vinculado a uma
tecnologia de desenvolvimento específica (web services, por exemplo).
 Suporte a decisões arquiteturais: se o processo fornece suporte a
importantes decisões arquiteturais ou delega essas decisões aos
programadores ou ferramentas de automação.

78
6.3 Limitações e Trabalhos Futuros

O processo foi concebido para ser sistemático e significativamente automatizado,

mas não foi possível avaliar essas características. Estes pontos serão abordados em
trabalhos futuros. A idéia é definir regras formais de transformações de modelos e
programar essas regras em ferramenta CASE ou plugins para ferramentas existentes,
a fim de facilitar, automatizar e gerenciar a criação e atualização dos modelos gerados
pelo processo.
Como outro trabalho futuro pretende-se utilizar métodos formais para descrever as
interfaces dos componentes e os contratos de serviços, servindo de base para garantir
a consistência e preservação de seus comportamentos. Outro trabalho que se
pretende fazer é implementar o processo no Eclipse Process Framework (EPM) [75] e
integrar as atividades do processo a outros processos como o OpenUp [49], por
exemplo.
Para uma avaliação mais efetiva do processo, seria necessário um estudo
experimental mais abrangente executado em um projeto na indústria com clientes
reais. Com isso, seria possível validar corretamente as métricas qualitativas (facilidade
de uso e alinhamento entre os stakeholders) e avaliar atributos de produtividade
(esforço, custo e velocidade de execução).

6.4 Considerações Finais

Embora existam esforços na pesquisa e aplicação de MDD e SOA, ter

investigado os problemas, suas complementaridades e vantagens do uso em
conjunto das duas abordagens na prática foi muito interessante. Além disso, a
utilização das duas abordagens em conjunto se mostrou adequada, pois com MDD foi
possível começar a projetar os sistemas em um alto nível de abstração. Com SOA foi
possível guiar o projeto em um nível menos abstrato e independente de tecnologia,
incentivando e favorecendo o reuso
A operação do estudo experimental em uma disciplina da graduação do Centro de
Informática da UFPE foi um grande e trabalhoso desafio, mas no final se mostrou
essencial, pois foi possível aperfeiçoar todas as atividades do processo, melhorar a

79
descrição das regras de transformação e detalhar os artefatos gerados nas atividades.
Além disso, o processo foi testado em cinco projetos diferentes.

80
Bibliografia

1. The Standish Group. Disponível em http://www.standishgroup.com/, março

2011.
2. CHAOS Summary 2009. Disponível em
http://www.standishgroup.com/newsroom/ chaos_2009.php , maio 2009.
3. George Stepanek. Software Project Secrets: Why Software Projects Fail.
Apress, 2005
4. From Stakeholders to Models: It Is All a Matter of Viewpoints. Disponível em
http://msdn.microsoft.com/pt-br/library/bb447667(en-us).aspx, março 2011.
5. Proof-of-Concept Design. Disponível em http://msdn.microsoft.com/en-
us/library/cc168618.aspx, março 2011.
6. Basili, V. R., Caldiera, G., and Rombach, H. D. (1994). The goal question
metric approach. In Encyclopedia of Software Engineering. Wiley.
7. Thomas, E. SOA Principles of Service Design, Prentice Hall, 2007.
8. Kent, S. Model Driven Engineering. IFM 2002: 286-298, 2002
9. Almeida, E. S. d. (2007). RiDE: The RiSE Process for Domain Engineering.
Ph.D. thesis, Federal University of Pernambuco, Informatics Center, Recife,
Pernambuco, Brazil.
10. France, R. and Rumpe, B. Model-driven Development of Complex
Software: A Research Roadmap. International Conference on Software
Engineering, 2007.
11. Papazoglou, M. P.; van den Heuvel, W. J.: Service oriented architectures:
approaches, technologies and research issues. VLDB Journal, 2007.
12. Xiaochun, W. and Yuanchun S. UMDD: User Model Driven Software
Development. IEEE/IFIP International Conference on Embedded and
Ubiquitous Computing, 2008.
13. Front-end and back-end. Disponível em http://en.wikipedia.org/wiki/Front-
end_e_back-end, maio de 2009.
14. CIRILLO, C. E., PRADO, A. F., ZAINA, L. A. M., SOUZA, W. L. Model
Driven RichUbi - A Model Driven Process for Building Rich Interfaces of
Context-Sensitive Ubiquitous Applications. In: 28th ACM International
Conference on Design of Communication, 2010, São Carlos, São Paulo.

81
15. L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice,
second ed. Addison-Wesley, 2003.
16. B. Hailpern and P. Tarr, ―Model-Driven Development: The Good, the Bad,
and the Ugly,‖ IBM Systems J., vol. 45, pp. 451-461, 2006.
17. P. Baker, L. Shiou, and F. Weil, Model-Driven Engineering in a Large
Industrial Context—Motorola Case Study,‖ Proc. Eighth Int’l Conf. Model
Driven Eng. Languages and Systems, pp. 476-491, 2005.
18. Staron, M. Adopting Model Driven Software Development in Industry—A
Case Study at Two Companies. Ninth Int’l Conf. Model Driven Eng.
Languages and Systems, pp. 57-72, 2006.
19. Pfadenhauer, K. Dustdar, S. Kittl, B. Challenges and Solutions for Model
Driven Web Service Composition. 4th IEEE International Workshops on
Enabling Technologies: Infrastructure for Collaborative Enterprise, 2005.
20. Castro, v. Mesa J. M. V. Herrmann, E. Marcos, E. A Model Driven Approach
for the Alignment of Business and Information Systems Models. Mexican
International Conference on Computer Science, 2008.
21. Stephen J. Mellor, Anthony N. Clark, Takao Futagami, "Guest Editors'
Introduction: Model-Driven Development," IEEE Software, vol. 20, no. 5, pp.
14-18, September/October, 2003.
22. RIBEIRO, Heberth Braga Gonçalves; ALVES, V.; Garcia, C. Vinicius; Álvaro,
Alexandre ; Lucrédio, Daniel; Almeida, S. Eduardo; Meira, L. R. Silvio. An
Assessment on Technologies for Implementing Core Assets in Service-
Oriented Product Lines. In: IV Simpósio Brasileiro de Componentes,
Arquiteturas e Reutilização de Software (SBCARS), 2010, Salvador.
23. Anneke Kleppe, Jos Warmer, Wim Bast, ―MDA Explained, The Model Driven
Architecture:Practise and Promise‖, 2003, Addison-Wesley
24. Päivi Parviainen, Juha Takalo, Susanna Teppola & Maarit Tihinen. Model-
Driven Development Process and Practices. VTT Technical Research
Centre of Finland, 2009.
25. USUF, L.; CHESSELL, M.; GARDNER, D. T. Implement model-driven
development to increase the business value of your IT system. v. 2008.
Disponível em: http://www.ibm.com/developerworks/library/ar-mdd1/ .
26. Nora Koch, Hubert Baumeister, Rolf Hennicker, and Luis Mandel. Extending
UML for Modeling Navigation and Presentation in Web Applications. In Geri
Winters and Jason Winters, editors, In Modeling Web Applications in the
UML Workshop, UML´2000, York, England, October 2000.
27. Wireframe. Disponível em http://en.wikipedia.org/wiki/Website_wireframe,
março 2011.

82
28. Axure- Sample Projects. Disponível em
http://www.axure.com/sampleProjects.aspx, março 2011.
29. Service oriented architecture Modeling Language (SoaML). Disponível
http://www.omg.org/spec/SoaML/1.0/Beta2/PDF, março 2011.
30. Luiz Francisco Lacerda Jr.. Um profile UML 2 e um processo de modelagem
para engenharia de interfaces gráficas dirigida a modelos e baseada em
componentes. 2005. Dissertação de Mestrado Universidade Federal de
Pernambuco.
31. NHibernate for .NeT. Disponivel em
http://community.jboss.org/wiki/NHibernateforNET, março 2011.
32. Java Persistebce API. Disponivel em
http://pt.wikipedia.org/wiki/Java_Persistence_API, março 2011.
33. Building an N-Tier Application in .NET. Disponivel em
http://msdn.microsoft.com/en-us/library/ms973279.aspx, março 2011.
34. MVC. Disponivel em http://pt.wikipedia.org/wiki/MVC, março 2011.
35. Model Driven SOA. Disponivel em
http://searchsoa.techtarget.com/tip/Model-driven-SOA, março 2011.
36. Wireframe completo do QIB. Disponível em
http://www.cin.ufpe.br/~vtb/qib/pig, maio 2011.
37. Basili, V. R., ―The Role of Experimentation in Software Engineering: Past,
Present, Future‖, Proceedings of the 18th International Conference on
Software Engineering, 1(2), PP. 133-164, 1996.
38. Sant’anna, C., Garcia, A., Chavez, C., Lucena, C., and von Staa, A. v.
(2003). On the reuse and maintenance of aspect-oriented software: An
assessment framework. In Proceedings of the 7th Brazilian Symposium on
Software Engineering.
39. Chidamber, S. R. and Kemerer, C. F. (1994). A metrics suite for object
oriented design. IEEE Transactions on Software Engineering, 20(6), 476–
493.
40. CDAC (2009). Metric advisor. http://www.cdac.in/html/ssdgblr/metric.asp.
Last access on November/2009.
41. Perepletchikov, M., Ryan, C., Frampton, K., and Tari, Z. (2007). Coupling
metrics for predicting maintainability in service-oriented designs. In
Proceedings of the 2007 Australian Software Engineering Conference
(ASWEC ’07), pages 329–340, Washington, DC, USA. IEEE Computer
Society Press.
42. Mahmood, Z. The Promise and Limitations of Service Oriented Architecture.
INTERNATIONAL JOURNAL OF COMPUTERS, Issue 3, Volume 1, 2007.

83
43. D. Overall, ―Have we been there before?‖, Opinions, Computer Weekly, UK,
11 April 2006.
44. M. Fowler, ―Patterns of enterprise application architecture‖, Addison Wesley,
2002.
45. Recommended Practice for Architectural Description of Software-Intensive
Systems; ANSI/IEEE Std 1471-2000.
46. Thomas, E. Service-Oriented Architecture: Concepts, Technology, and
Design, Prentice Hall, 2005.
47. Machado, João. Um estudo sobre o desenvolvimento orientado a serviços.
Rio de Janeiro, 2004. 89p. Dissertação de Mestrado - Departamento de
Informática, Pontifícia Universidade Católica do Rio de Janeiro.
48. Derek Miers, Stephen A. White. BPMN Modeling and Reference Guide.
Future Strategies Inc., Agosto 2008
49. OpenUp. Disponível em http://epf.eclipse.org/wikis/openup/, julho 2011.
50. Netbeans. Disponivel em http://netbeans.org/index.html, jullho 2011.
51. O'Reilly, T. 2005. What is Web 2.0: design patterns and business models for
the next generation of software. Disponível em:
http://oreilly.com/web2/archive/what-is-web-20.html, julho: 2009.
52. Qing Gu , Patricia Lago, A stakeholder-driven service life cycle model for
SOA, 2nd international workshop on Service oriented software engineering:
in conjunction with the 6th ESEC/FSE joint meeting, September 03-03,
2007, Dubrovnik, Croatia.
53. Rafael Capilla and Muhammad Ali Babar, On the Role of Architectural
Design Decisions in Software Product Line Engineering, Second European
Conference, ECSA 2008 Paphos, Cyprus, September -October, 2008
Proceedings.
54. Lucrédio, Daniel. Uma abordagem orientada a modelos para reutilização de
software, Tese de Doutorado, Universidade de São Paulo, USP, Brasil,
2009.
55. MOF.The Meta-Object Facility. Disponível em http://www.omg.org/mof/,
julho 2011.
56. Arquitetura Orientada a Serviços – SOA Infraestrutura para a Inovação.
Disponível em http://www.scribd.com/doc/46068179/Introducao-Ao-SOA-
31574, julho 2011.
57. DEURSEN, A. van; KLINT, P. Little languages: little maintenance. Journal of
Software Maintenance, John Wiley & Sons, Inc., New York, NY, USA, v. 10,
n. 2, p. 75–92, 1998. ISSN 1040-550X.
58. MERNIK, M.; HEERING, J.; SLOANE, A. M. When and how to develop
domain-specific languages. ACM Computing Surveys, v. 37, n. 4, p. 316–
344, dez. 2005. ISSN 0360-0300.
59. BAHNOT, V. et al. Using domain-specific modeling to develop software
defined radio components and applications. In: The 5th OOPSLA Workshop
on Domain-Specific Modeling, San Diego USA. [S.l.: s.n.], 2005. p. 33–42.

84
60. Soley, R. (2000, 11 27). Model Driven Architecture. Retrieved from Object
Management Group: http://www.omg.org/mda
61. ORMSC, A. B. (2001, 07 09). Model Driven Architecture - A Technical
Perspective. Retrieved from Object Management Group:
http://www.omg.org/mda
62. Agile Modeling: User Interface Flow. Disponível em
http://www.agilemodeling.com/artifacts/uiFlowDiagram.htm, julho 2011.
63. Alvaro, Alexandre. Software component certification: a component quality
model. Recife, 2005. 124p. Dissertação de Mestrado – Centro de
Informática, Universidade Federal de Pernambuco.
64. J. Sametinger, Software Engineering with Reusable Components, Springer-
Verlag, USA,1997.
65. Clements, P. and Northrop, L. Software Product Lines: Practices and
Patterns, volume 0201703327. Addison-Wesley Longman Publishing,
Boston, MA, USA. 2001
66. Fabio Tirelo; Roberto da Silva Bigonha; Mariza Andrade da Silva Bigonha;
Marco Tulio de Oliveira Valente. Desenvolvimento de Software Orientado
por Aspectos. Mini-curso apresentado na XXIII Jornada de Atualização em
Informática (JAI), 2004
67. López-Sanz, M.; Vara, J.; Cuesta, C.: A Model-Driven Approach to Weave
Architectural Styles into Service-Oriented Architectures Proceeding of the
first international workshop on Model driven service engineering and data
quality and security, 2009
68. Fabio Perez Marzullo, Jano Moreira de Souza, José Roberto Blaschek: A
Study Case on Domain-Driven Development, Using MDA, SOA and Web
Services. SERVICES I 2008:93-94
69. Valeria de Castro, Esperanza Marcos, Roel Wieringa: Towards a Service-
Oriented MDA-Based Approach to the Alignment of Business Processes
with IT Systems: from the Business Model to a Web Service Composition
Model. Int. J. Cooperative Inf. Syst. (IJCIS) 18(2):225-260 (2009)
70. Mariano Belaunde, Paolo Falcarin: Realizing an MDA and SOA Marriage for
the Development of Mobile Services. ECMDA-FA 2008:393-405
71. Delgado, A.; Ruiz, F., García-Rodríguez de Guzmán, I.; Piattini, M.:
―MINERVA: Model drIveN and service oriented framework for the continuous
business processes improvement & related tools‖,5th Int. Workshop on
Engineering SO Applications (WESOA’09),Nov. 2009
72. Haeng-Kon Kim, Roger Y. Lee: MS2Web: Applying MDA and SOA to Web
Services. Software Engineering, Artificial Intelligence, Networking and
Parallel/Distributed Computing 2008:163-180
73. López-Sanz, M.; Acuña, C,J..; Cuesta, C.;Marcos, E.: Defining Service-
Oriented Software Architecture Models for a MDA-based Development
Process at the PIM level Proceeding WICSA '08 Proceedings of the Seventh
Working IEEE/IFIP Conference on Software Architecture (WICSA 2008).

85
74. Chitforoush, F; Yazdandoost, M; Ramsin, R; Methodology Support for the
Model Driven Architecture. 14th Asia-Pacific Software Engineering
Conference (APSEC 2007).
75. Eclipse Process Framework. Disponível em http://www.eclipse.org/epf/,
julho 2011.

86
Apêndice A

PARTE 1 – SOBRE OS PARTICIPANTES (10 MINUTOS)

Data:__/__/____
Período atual:___
Login: _____

Curso:

( ) Ciência da Computação
( ) Engenharia da Computação
( ) Sistemas de Informação
( ) Outros _________________

Em quantos projetos profissionais (envolvendo clientes reais) você já participou

de acordo com as seguintes categorias (preencher com números):

___ projetos de baixa complexidade (menos de seis meses).

___ projetos de média complexidade (entre seis meses e um ano).
___ projetos de alta complexidade (mais de um ano).

Em quantos projetos acadêmicos você já participou de acordo com as seguintes

categorias:

___ projetos de baixa complexidade (menos de seis meses).

___ projetos de média complexidade (entre seis meses e um ano).
___ projetos de alta complexidade (mais de um ano).

87
Em quantos projetos você já atuou como líder técnico (responsável pela
arquitetura)?

___ Projetos acadêmicos

___ Projetos profissionais

Em quantos projetos orientados a serviços você já participou

___ Projetos Acadêmicos

___ Projetos profissionais

Antes de começar o curso, como você definiria a sua experiência em engenharia

de software?

( ) Nenhuma
( ) Baixa
( ) Média
( ) Alta

Antes de começar o curso, como você definiria a sua experiência em SOA?

( ) Nenhuma
( ) Baixa
( ) Média
( ) Alta

Quantos documentos de requisitos e casos de uso você já escreveu ou

participou de revisões?

Profissional: ( ) Nenhum ( ) entre 1 e 4 ( ) mais de 4

Acadêmico: ( ) Nenhum ( ) entre 1 e 4 ( ) mais de 4

88
PARTE 2 – SOBRE O PROCESSO (30 MINUTOS)

No geral, como você classificaria o processo?

( ) muito fácil
( ) fácil
( ) razoável
( ) difícil
( ) muito difícil

Qual etapa do processo você teve mais dificuldade em entender?

( ) Nenhuma
( ) Especificação do modelo de negocio
( ) Projetar Serviços
( ) Analisar serviços
( ) Todas

Como você classificaria a fase de Especificação do Modelo de Negócio?

( ) muito fácil
( ) fácil
( ) razoável
( ) difícil
( ) muito difícil

89
Na fase de Especificação do Modelo de Negócio, teve dificuldade em entender as
atividades e os artefatos gerados?

( ) Não
( ) Sim. Por favor, indique os artefatos e justifique?
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
____________________________________________________________________

Na fase de Especificação do Modelo de Negócio, teve dificuldade em produzir os

artefatos?

( ) Não
( ) Sim. Por favor, indique os artefatos e justifique?
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
____________________________________________________________________

Na fase de Especificação do Modelo de Negócio, achou os artefatos gerados

úteis?

( ) Sim
( ) Não. Por favor, indique os artefatos e justifique?
_____________________________________________________________________
_____________________________________________________________________
____________________________________________________________________

90
Como você classificaria a fase de Analisar Serviço?

( ) muito fácil
( ) fácil
( ) razoável
( ) difícil
( ) muito difícil

Na fase de Analisar Serviço, teve dificuldade em entender as atividades?

( ) Não
( ) Sim. Por favor, indique os artefatos e justifique?
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
____________________________________________________________________

Na fase de Analisar Serviço, teve dificuldade em produzir os artefatos?

( ) Não
( ) Sim. Por favor, indique os artefatos e justifique?
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
____________________________________________________________________

Na fase de Analisar Serviço, achou os artefatos gerados úteis?

( ) Sim
( ) Não. Por favor, indique os artefatos e justifique?
_____________________________________________________________________
_____________________________________________________________________

91
_____________________________________________________________________
_____________________________________________________________________
____________________________________________________________________

Em geral, como você classificaria a fase de Projetar Serviços:

( ) muito fácil
( ) fácil
( ) razoável
( ) difícil
( ) muito difícil

Na fase de Projetar Serviço, teve dificuldade em entender as atividades?

( ) Não
( ) Sim. Por favor, indique os artefatos e justifique?
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
____________________________________________________________________

Na fase de Projetar Serviço teve dificuldade em produzir os artefatos gerados?

( ) Não
( ) Sim. Por favor, indique os artefatos e justifique?
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

92
Na fase de Projetar Serviço, achou os artefatos gerados úteis?

( ) Sim
( ) Não. Por favor, indique os artefatos e justifique?
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
____________________________________________________________________

Você concorda que o processo ajuda no alinhamento do entendimento entre

todos os participantes envolvidos no projeto (gerentes, analistas,
programadores, arquitetos, designer, clientes)?

( ) Discordo totalmente
( ) Discordo
( ) Não sei responder
( ) Concordo
( ) Concordo totalmente

Você concorda que o processo é útil para construção de uma arquitetura

desacoplada entre front-end e o back-end?

( ) Discordo totalmente
( ) Discordo
( ) Não sei responder
( ) Concordo
( ) Concordo totalmente

Como você classificaria as aulas sobre o processo:

( ) Muito ruim

93
( ) Ruim
( ) Satisfatória
( ) Bom
( ) Muito Bom

Você gostaria de cursar a disciplina de Tópicos Avançados em Análise e Projeto

de sistemas com seminários mais detalhados sobre SOA e MDE e projetos de
sistemas até a codificação?

( ) Sim
( ) Não

Você tem alguma sugestão de melhoria no processo? Quais?

_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
____________________________________________________________________

94
Apêndice B

Descrição dos Casos Uso do Qualiti Internet Banking.

Caso de uso: Efetuar Login

Descrição: Este caso de uso é responsável por autenticar um usuário do sistema.

Pré-condição: nenhuma

Pós-condição: um usuário válido é logado e sua sessão é registrada no sistema.

Fluxo principal

1. O cliente informa login e senha.

2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e

senha pertencem a uma conta).

3. O sistema registra o início de uma sessão de uso.

Fluxos secundários

- No passo 2, se o login e a senha forem inválidos, o sistema exibe uma

mensagem e volta ao passo 1.

95
Caso de Uso: Alterar Senha

Descrição: Este caso de uso é responsável por alterar a senha de um usuário do

sistema.

Pré-condição: O cliente da conta deve ter efetuado login.

Pós-condição: senha do usuário alterada

Fluxo principal:

1. O cliente informa login, senha antiga e a nova senha.

2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e

senha pertencem a uma conta).

3. O sistema altera a senha do usuário com a nova senha

Fluxos secundários

- No passo 2, se o login e a senha forem inválidos, o sistema exibe uma

mensagem e volta ao passo 1.

96
Caso de Uso: Realizar Transferência

Descrição: Este caso de uso é responsável por realizar transferência entre duas
contas bancárias.

Pré-condição: O cliente depositante deve ter efetuado login.

Pós-condição: O saldo atual do cliente é debitado deste valor , o qual é creditado

na conta informada como destinatária.

Fluxo principal:

1.O cliente escolhe a opção de transferência e informa o valor a ser

transferido e a conta para depósito.

2.O sistema recupera a conta bancária do cliente (que já efetuou o login

anteriormente) e a conta para depósito.

3.O sistema debita o valor da conta do cliente e credita na conta destinatária.

Fluxos secundários

- No passo 2, se a conta bancária do cliente não tiver saldo suficiente,

sistema exibe uma mensagem de aviso e volta ao passo 1.

97
Caso de Uso: Efetuar Pagamento Qualiti Card

Descrição Este caso de uso é responsável por realizar o pagamento do Qualiti Card
com a operadora de cartão de crédito. Cada cliente possui apenas um cartão como
titular, estando vinculado a apenas uma operadora.

Pré-condição: O cliente deve estar conectado ao sistema (ter efetuado o login).

Pós-condição: O valor do pagamento é debitado da conta do cliente, o pagamento

é enviado à operadora do cartão de crédito e a transação é registrada no sistema.

Fluxo Principal:

1. O cliente informa os dados necessários para efetuar o pagamento do

cartão:
- O código de barras da fatura que deseja efetuar o pagamento.
- O valor que deseja pagar.

2. O sistema recupera a conta bancária do cliente logado.

3. O sistema verifica se o saldo da conta do cliente é suficiente para realizar

o pagamento.

4. O sistema debita da conta do cliente.

5. O sistema envia o pagamento à operadora de cartão de crédito.

6. O sistema registra a transação de pagamento e emite um comprovante da

mesma para o usuário. A transação registrada contém os dados da conta do
cliente, o código de barras da fatura, data, hora e valor do pagamento.

Fluxos Secundários: 98

- No passo 3, se o saldo disponível na conta do cliente for menor que o valor do

pagamento, o sistema informa que o saldo é insuficiente e retorna para o passo 1.
Caso de uso: Consultar Saldo

Descrição: Este caso de uso é responsável por consultar o saldo da conta bancária
do cliente.

Pré-condição: O cliente deve ter efetuado login.

Pós-condição: nenhuma.

Fluxo principal

1. O cliente seleciona a opção de consulta de saldo

2. O sistema recupera o saldo atual da conta bancária do cliente

3. O sistema exibe o valor do saldo e a data atual

Fluxos secundários

- Não tem.

99
Caso de uso: Consultar Cheques

Descrição: Este caso de uso é responsável por consultar os cheques emitidos pelo
cliente.

Pré-condição: O cliente deve ter efetuado login.

Pós-condição: nenhuma.

Fluxo principal

1. O cliente seleciona o período referente a consulta (data inicial e data final)

2. O sistema recupera todos os cheques compensados na conta do cliente

3. O sistema exibe uma lista com a data, hora e o valor de cada cheque
compensado

Fluxos secundários

- No passo 1, se o cliente informar uma período inválido, sistema exibe uma

mensagem de avise e volta ao passo 1.

100
Caso de uso: Consultar Extrato

Descrição: Este caso de uso é responsável por consultar o extrato da conta

bancária do cliente.

Pré-condição: O cliente deve ter efetuado login.

Pós-condição: nenhuma.

Fluxo principal

1. O cliente seleciona o período referente ao extrato (data inicial e data final)

2. O sistema recupera todas as transações realizadas na conta do cliente

3. O sistema exibe uma lista com a data, hora e o valor de cada transação

Fluxos secundários

- No passo 1, se o cliente informar uma período inválido, sistema exibe uma

mensagem de avise e volta ao passo 1.

101