um processo para projeto arquitetural de software dirigido a modelos e orientado a serviços

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

[email protected]

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

iv

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.

v

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

vi

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

vii

Í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

viii

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

ix

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

x

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

xi

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

1

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.

2

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

3

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

4

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.

5

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.

6

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.

7

Capítulo 1 Introdução

Capítulo 2 Conceitos e

Fundamentos

Capítulo 3 O Processo

Motiva e Contextualiza

É usado por

Motiva e apresenta o problema para

Capítulo 5 Avaliação do processo

É avaliado por

Capítulo 6Conclusão

Motiva

Motiva

Capítulo 4 Exemplo de uso

É instanciado por

Figura 1.1 – Roadmap do trabalho.

8

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.

9

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.

10

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;

11

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;

http://pt.wikipedia.org/wiki/Aplica%C3%A7%C3%A3o

http://pt.wikipedia.org/wiki/Orienta%C3%A7%C3%A3o_a_objeto

12

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.

13

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.

14

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.

15

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:

Class

UML Class

name: String

Video

title: string

a:Video

title = "Casa Blanca"

instace of

instace of

instace of

UML Atribute

name: string

instance of

instance of

16

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

17

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

18

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]:

19

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

20

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.

21

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 é

22

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.

23

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.

24

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

25

(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

26

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

27

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

28

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

29

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

30

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

31

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

32

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.

33

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.

MOF

UML2 MM GuiProfile UML MM

MIN MN PIGMF

conforms To

conforms Toconforms To

extends

instance Of

instance Ofinstance Of

instance Of

34

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

35

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.

36

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

Ator 1Ator 2

Pacote 1

Pacote 2

UC 1

UC2

UC3

UC 4

UC 5

Pacote1<<Service Contract>>


UC5<<Service Contract>>

UC5-Ator2<<Service Contract>>

Ator1<<Participant>> Ator2

<<Participant>>Sistema

<<Participant>>

consume

consume

consume

provide

provide

provide

consume provide

37

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.

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);

E1<<entity service>>

E 2<<entity service>>

E3

Serviço E1<<service contract>>

Serviço E2<<service contract>>

MIN marcado

38

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.

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:

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

operacao1() operacao1()

retornooperacao1()

retornoretorno

operacao2()

retorno

39

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.

40

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



UC5<<Service Contract>>

UC5-Ator2<<Service Contract>>

Ator1<<Participant>>

Ator2<<Participant>>

Sistema<<Participant>>

consume

consume

consume

provide

provide

provide

consume provide

Service E1<<Service Contract>>

Compoente A

Componente 1

Componente 3

IService1

IServicec2

IServicec4 IService3

IServiceE1

ComponenteE1

Componente 2

Componente 4

Arquitetura de Serviços

Serviço de Entidade

41

<<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 Informação do Negócio

Modelo de Funcionalidades


Modelo de Interação de

Serviços (Template)

Modelo de Interação de

Serviços (completo)

TransformaçãoCIM-PIM

Transformação PIM-PIM

TransformaçãoPIM-PIM

TransformaçãoPIM-PIM

Modelo de Componenes de

Serviços

Modelo Informação do Negócio

Refinado

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.

42

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.

MOF

UML2 MM SoaMLProfile MM

MINMF

conforms To

conforms To

conforms To

extends

instance Of

instance Of

AS MIS MCS

instance Ofinstance Of

instance Of

43

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?

44

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.

Figura 3.15–Exemplo de Arquitetura do Sistema.

Componente 1 Componente 3

IServiceContrac1

IServiceContrac2

IServiceContrac4

IServiceContrac3Componente 2Componente 4

Communication

Desktop<<Front-end>>

ICommunication

Mobile<<Front-end>>

45

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.

46

Transformação PIM-PIM

Arquitetura Sistema

Padrões de Arquitetura

Restrições

Diagramas Back-end

Diagramas Front-end

Tranformação PIM-PIM

Padrões de ProjetosGuias

Transformação (PIM -PSM)

Transformação(PIM-PSM)

Modelos Front-end PSM

Modelos Back-end PSM

Protótipo Interface Gráfica

Modelo de Plataforma

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.

47

Figura 3.17–Modelos da fase Projetar Serviços

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

MOF

UML2 MM

conforms To

conforms To

Modelos Front-end Modelos Back-end Arquitetura do Sistema

instace Of

48

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

49

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.

ClienteAtor

Realizar Transferência

Operadora de Cartão

Alterar Senha

Efetuar Login

Consultar Extrato

Consultar Saldo

Efetuar Pagamento Cartão

Consultar Cartão

50

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

51

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

ClienteAtor

Realizar Transferência


Alterar Senha

Efetuar Login

Consultar Extrato

Consultar Saldo

Efetuar Pagamento Cartão

Consultar Cartão

ClienteAtorControle de Acesso

Controle ContaControle Qualit Card


Casos de Uso


52

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.

53

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 é

ClienteAtorControle de Acesso

Controle ContaControle Qualit Card


Cliente Front-end<<participant>> Sistema back-end

<<participant>>

Operadora Cartão<<participant>>

ControleAcesso<<Service Contract>>

consumerprovider

ControleConta<<Service Contractt>>

consumerprovider

ControleQualitiCard<<Service Contract>>

consumerconsumer

OperadoraCartao<<Service Contract>>

consumer provider



54

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.

Figura 4.7–Serviços de Entidade do QIB.

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

ContaInternet<<Service Contract>>

Transação<<Service Contract>>

ContaBancaria<<Service Contract>>

: Cliente Front-end : IControleAcesso : IContaInternet

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

ContaInternetsessão

alterar(login,antiga, nova)

existe(login,senha)

ContaInternet

atualizar(ContaInternet)

Conta Internetsessão

55

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.

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.

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

ContaintInternet

+login+senha

ContaBancaria

+numero+saldo

Transacao

+numero da fatura+data+valor+numero da conta

Cliente Front-end<<Front-end>>

Controle ContaControle de Acesso Controle QualitCard

IControleAcesso IControleConta IControleQualitCard

Transação

ITransaçãoIContaInternet

ContaInternet ContaBancaria

IContaBancaria

IOperadoraCartão

OperadoraCartão

56

―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/

57

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.

58

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.

Controle ContaControle de Acesso Controle QualitCard

IControleAcesso IControleConta IControleQualitCard

Transação

ITransaçãoIContaInternet

ContaInternet ContaBancaria

IContaBancaria

IFachadaWebSercice

WebService

Front-end WebFront-end Iphone

Front-end Desktop

IOperadoraCartão

OperadoraCartão

59

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.

Figura 4.12–Diagrama de classes do componente ControleAcesso.

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

ControladorControleAcesso

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

IContaInternet

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

ContaintInternet

+login+senha

IControleAcesso

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

: FachadaWebservice : IControleAcesso : IContaInternet

1 : logar() 2 : existe()

3 : true4 : session

60

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.

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

TelaLogin

+loginText: TextField+senhatext: TextField+logarButton: JButton

+efeturarLoginr()

IComunicacaoWebService

ComunicacaoWebService

+logar()+chamarWebService()

: TelaLogin : ComunicacaoWebService

: ClienteAtor

1 : efeturarLogin()2 : logar()

3 : chamarWebService()

61

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

62

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

Qu

alid

ades

Var

iáve

l de

resp

ost

aFa

tore

sA

trib

uto

sM

étri

cas

Qualidade de Projeto

Reusabilidade Manutenibilidade

Complexidade Compreensibilidade EstabilidadeModularidade

Tamanho InstabilidadeAcoplamento

WOCS CBCS IMSC

Figura 5.1–Framework de medição.

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

63

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:

64

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:

65

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:

66

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

67

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:

68

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

69

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

70

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

71

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.

72

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%).

73

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.

74

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.

75

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:

76

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

77

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.

78

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.

Precisão

do

Processo

Cobertura do

ciclo de vida

genérico

Domínio

restrito

Arquitetura

vinculada às

transformações

Independente

de ferramentas

e tecnologias

Suporte a

decicões

arquiteturais

A Study Case on Domain-Driven

Development, Using MDA, SOA and

Web Services [68]

baixa não não sim não não

SOD-M [69] alta sim sim não sim sim

Realizing an MDA and SOA Marriage

for the Development of Mobile

Services [70]

médio não não sim não não

Minerva [71] baixa não sim sim não sim

A Model-Driven Approach to Weave

Architectural Styles into Service-

Oriented Architectures [67]

médio não sim sim não não

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

79

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

80

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.

81

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.

82

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.

http://www.pst.informatik.uni-muenchen.de/~kochn/ExtendingUML.pdf

http://www.pst.informatik.uni-muenchen.de/~kochn/ExtendingUML.pdf

83

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.

http://www.omg.org/spec/SoaML/1.0/Beta2/PDF

http://pt.wikipedia.org/wiki/Java_Persistence_API

84

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.

85

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

http://www.omg.org/mda

86

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.

87

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

88

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

89

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

90

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


_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

____________________________________________________________________

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?

_____________________________________________________________________

_____________________________________________________________________

____________________________________________________________________

91

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


_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

____________________________________________________________________

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

( ) Não


_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

____________________________________________________________________

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

( ) Sim


_____________________________________________________________________

_____________________________________________________________________

92

_____________________________________________________________________

_____________________________________________________________________

____________________________________________________________________

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


_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

____________________________________________________________________

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

( ) Não


_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

93

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

( ) Sim


_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

____________________________________________________________________

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

94

( ) 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?

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

____________________________________________________________________

95

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.

96

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.

97

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.

98

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:

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

99

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.

100

Caso de uso: Consultar Cheques

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

cliente.



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.

101

Caso de uso: Consultar Extrato

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

bancária do cliente.



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.

um processo para projeto arquitetural de software dirigido a modelos e orientado a serviços

Documents