Ps-Graduao em Cincia da Computao

Um Processo para Projeto Arquitetural de Software Dirigido a Modelos e Orientado a Servios

Por

Vtor Torres Braga

Dissertao de Mestrado

Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao

RECIFE, AGOSTO/2011

UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMTICA PS-GRADUAO EM CINCIA DA COMPUTAO

VTOR TORRES BRAGA

Um Processo para Projeto Arquitetural de Software Dirigido a Modelos e Orientado a Servios

ESTE TRABALHO FOI APRESENTADO PSGRADUAO EM CINCIA DA COMPUTAO DO CENTRO DE INFORMTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENO DO TTULO DE MESTRE EM CINCIA DA COMPUTAO.

ORIENTADOR: AUGUSTO SAMPAIO CO-ORIENTADOR: VINICIUS CARDOSO GARCIA

RECIFE, AGOSTO/2011

iii

AGRADECIMENTOS
Dedico este trabalho a minha maravilhosa famlia que sempre me apoiou em todos os momentos da minha vida. Em especial ao meu pai, minha me e minha irm, por serem exemplos de dignidade, honestidade e perseverana que modelaram o meu carter e foram os responsveis pelo homem que me tornei. Vocs so meus nicos e verdadeiros heris. A minha namorada Juliana por ter sido compreensiva, atenciosa e ter me suportado durante esses ltimos anos. Perdoe-me pelos vrios 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 pacincia. Foi um privilgio ter convivido de perto durante esses anos, nossa universidade precisa de mais professores como voc. Ao meu co-orientador Vinicius Garcia pela pacincia e excelentes sugestes apresentadas na reta final. Muito obrigado pelo tempo gasto com leitura e correes de cada capitulo. Aos meus parceiros da MobilIT, hoje Comment Lab, Farley, Paulo e Firma por terem sido amigos com os quais sempre pude contar e compartilhar os sucessos, fracassos e angustias.

iv

Resumo
Nos ltimos anos, o Desenvolvimento Dirigido a Modelos (Model-Driven Development - MDD) tem se posicionado como uma tendncia na pesquisa de engenharia de software. Embora o uso de modelos no seja novidade, o sucesso MDD vem da possibilidade de construir sistemas de software completos a partir de transformaes automticas 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 aplicaes mais flexveis, modulares e reutilizveis. Mas, apesar dessas vantagens, a maioria dos processos e metodologias SOA disponvel na literatura carecem de uma sistemtica 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 servios, a fim de possibilitar o projeto de arquiteturas estveis, flexveis e modulares. O processo foi elaborado para ser sistemtico, fcil de usar e compreender, independente de ferramentas e tecnologias, e que pudesse resolver problemas prticos como: a integrao de aplicaes, 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 avaliao do processo apresentada com base em um experimento seguindo a abordagem Goal Question Metric.

Palavras-chave: Desenvolvimento Dirigido por Modelos (MDD), Arquitetura Orientada a Servios (SOA), Processo de Software

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

vi

ndice
Captulo 1 - Introduo............................................................................... 1
1.1 1.2 1.3 1.4 Contexto ............................................................................................................. 1 Principais Contribuies ................................................................................... 4 Fora do Escopo.................................................................................................. 5 Organizao da Dissertao ............................................................................. 6

Captulo 2 - Conceitos e Fundamentos ...................................................... 8

2.1 2.2 Introduo .......................................................................................................... 8 MDD Model Driven Development ................................................................... 9 Vantagens e Desvantagens 10

2.2.1 2.3 2.4

MDA Model Driven Architecture .................................................................. 11 SOA................................................................................................................... 15 Vantagens e Limitaes 18

2.4.1 2.5

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

2.5.1 2.5.2 2.5.1 2.5.1

Captulo 3 - O Processo............................................................................. 27
3.1 3.2 3.3 3.4 Introduo ........................................................................................................ 27 Especificar Modelo de Negcio ...................................................................... 28 Analisar Servios............................................................................................. 33 Projetar Servios ............................................................................................. 42

Captulo 4 - Instanciao e Execuo do Processo ................................. 48

4.1 4.2 Introduo ........................................................................................................ 48 Qualiti Internet Banking .................................................................................. 48

vii

4.3 4.4 4.5

Especificar Modelo de Negcios .................................................................... 49 Analisar Servios............................................................................................. 52 Projetar Servios ............................................................................................. 56

Captulo 5 - Avaliao do Processo.......................................................... 61

5.1 5.2 5.3 5.4 5.5 5.6 Introduo ........................................................................................................ 61 Definio .......................................................................................................... 61 Planejamento ................................................................................................... 66 Operao .......................................................................................................... 68 Coleta e Anlise dos Dados ............................................................................ 69 Lies Aprendidas ........................................................................................... 73

Captulo 6 - Concluso .............................................................................. 75

6.1 6.2 6.3 6.4 Principais contribuies ................................................................................. 75 Trabalhos Relacionados ................................................................................. 76 Limitaes e Trabalhos Futuros ..................................................................... 79 Consideraes Finais ...................................................................................... 79

Bibliografia 81 Apndice A 87 Apndice B 95

viii

Lista de Tabelas
Tabela 5.1. Dados dos Projetos. Tabela 5.2. Resultados da mtrica CBCS. Tabela 5.3. Resultados da mtrica WOCS. Tabela 5.4. Resultados da mtrica IMSC. Tabela 6.1. Resultados da anlise. 69 70 70 71 78

ix

Lista de Figuras
Figura 1.1 Roadmap do trabalho................................................................................ 7 Figura 2.1 Processo MDD genrico [54]. ................................................................. 10 Figura 2.2 Processo MDA Bsico [30]...................................................................... 13 Figura 2.3 Processo de transformao de Modelos MDA [30]. ................................ 14 Figura 2.4 Nveis de modelagem em MDA. .............................................................. 15 Figura 2.5 Diferentes pontos de vistas de SOA [56]. ................................................ 16 Figura 2.6 Relacionamento entre os tipos de servios [7]. ....................................... 17 Figura 2.7 Seros 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 Definio de uma Interface de Servio [26]. .......................................... 23 Figura 2.11 Coreografia do Servio [26]................................................................... 24 Figura 2.12 Exemplo de Arquitetura de Servio [26]. ............................................... 26 Figura 3.1 - Viso Geral do Processo. ........................................................................ 27 Figura 3.2 Especificar Modelo de Negcio. ............................................................... 29 Figura 3.3 Exemplo de Modelo Navegacional [30]. .................................................. 30 Figura 3.4 Exemplo de Interface Grfica [30]. .......................................................... 31 Figura 3.5 Exemplo do Prottipo de Interface Grfica [30]. ...................................... 32 Figura 3.6 Modelos da fase Especificar Modelo de Negcio. ................................... 33 Figura 3.7 Fluxo de atividades da fase Analisar Servios. ........................................ 34 Figura 3.8 Construo da Arquitetura de Servios. .................................................. 36 Figura 3.9 Servios de Entidade. ............................................................................. 37 Figura 3.10 Modelo de Interao de Servios. .......................................................... 38 Figura 3.11Construo do Modelo de Componentes de Servios. ............................ 40 Figura 3.12Transformaes de modelo da fase Analisar Servios. ........................... 41 Figura 3.13Modelos da fase Analisar Servios. ........................................................ 42 Figura 3.14Diagrama de artefatos de Projetar servios ............................................ 43 Figura 3.15Exemplo de Arquitetura do Sistema. ....................................................... 44 Figura 3.16Transformao de modelos da fase Projetar Servios. ........................... 46

Figura 3.17Modelos da fase Projetar Servios .......................................................... 47 Figura 4.1Casos de Uso do QIB................................................................................ 49 Figura 4.2Modelo de Informao de Negcio do QIB................................................ 50 Figura 4.3Modelo de Funcionalidades do QIB. ......................................................... 51 Figura 4.4Modelo Navegacional do QIB.................................................................... 51 Figura 4.5Prottipo de Interface Grfica do QIB da tela login. .................................. 52 Figura 4.6Passo a passo para elaborao da Arquitetura de Servios do QIB. ........ 53 Figura 4.7Servios de Entidade do QIB. ................................................................... 54 Figura 4.8Modelo de Interao de Servio do QIB. ................................................... 54 Figura 4.9MIN Refinado do QIB. ............................................................................... 55 Figura 4.10Modelo de Componentes dos Servios do QIB. ...................................... 55 Figura 4.11Arquitetura do Sistema. ........................................................................... 58 Figura 4.12Diagrama de classes do componente ControleAcesso............................ 59 Figura 4.13Diagrama de Seqncia de Efetuar Login. .............................................. 59 Figura 4.14Construo da Interface Grfica Desktop do QIB.................................... 60 Figura 4.15Diagrama de Classe e seqncia do Desktop. ........................................ 60 Figura 5.1Framework de medio............................................................................. 62 Figura 5.2 - Grfico de avaliao da dificuldade do processo. .................................... 71 Figura 5.3 - Grfico da avaliao do alinhamento entre os stakeholders. ................... 72 Figura 5.4 - Avaliao do desacoplamento entre front-end e back-end. ...................... 72

xi

Captulo 1 - Introduo

1.1 Contexto
O relatrio anual publicado pelo The Standish Group [1], chamado curiosamente de The Chaos Report, mostra alguns nmeros interessantes sobre o cenrio da indstria de software [2]. Aproximadamente 24% dos projetos so cancelados por atrasos e oramento estourados. Cerca de 40% dos projetos estouram o oramento 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, no h comparao com outros tipos de indstria e os motivos j foram descritos em vrios livros e artigos disponveis na literatura [3,4,5]. Vrias abordagens em engenharia de software sugiram justamente para tentar amenizar estes nmeros: Desenvolvimento Baseado em Componentes, Linhas de Produtos de Software, Desenvolvimento Orientado a Aspectos, Arquitetura Orientada a Servio e Desenvolvimento Dirigido a Modelos. Atualmente, a maioria dos softwares existentes no mercado foi desenvolvida baseada em blocos monolticos, 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 monolticos em componentes, diminuindo a complexidade e o custo de desenvolvimento, onde os componentes podem ser usados em outras aplicaes [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 domnio especifico. As abordagens LPS exploram as semelhanas e variabilidades desses produtos, guiando o desenvolvimento de artefatos fundamentais (core assets) customizveis e reusveis [65]. Reutilizando esses artefatos possvel construir sistemas em larga escala e de acordo com requisitos especficos dos clientes.

O Desenvolvimento de Sistemas Orientados a Aspectos (DSOA) uma abordagem cujo objetivo principal separar requisitos transversais das classes da aplicao. Utilizando orientao a aspectos, requisitos como registro de operaes, controle de sincronizao e comunicao podem ser implementados de forma simples, elegante e favorecendo a reutilizao de cdigo [66]. Arquitetura Orientada a Servio, do ingls Service Oriented Architecture (SOA), tem como principal objetivo o reso intenso de servios, para que em mdio prazo, a tarefa do desenvolvimento de uma aplicao seja, primordialmente, a composio e coordenao dos servios j implementados, aumentando o reso e diminuindo o dispndio de recursos. Para atingir esses objetivos, SOA segue boas prticas e princpios de projeto para facilitar a tarefa de definir, encontrar e gerenciar os servios [22]. Alguns trabalhos consideram SOA como uma evoluo 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 so modelados em vrios nveis de abstrao e sob diferentes perspectivas. Diferentemente das outras abordagens de desenvolvimento de software, os modelos so os artefatos centrais para a construo das aplicaes, e no o cdigo. Neste sentido, analisando as abordagens de desenvolvimento apresentadas anteriormente, a combinao de conceitos e fundamentos existentes em um processo integrado e sistematizado pode oferecer contribuies tanto para a academia como para a indstria [54], segundo palavras de Jim Neighbors: organizaes

acadmicas em cincia da computao parecem preferir o trabalho em novas teorias. Porm, alguns dos mais bem-sucedidos trabalhos acadmicos so uma fuso e formalizao de tcnicas de sucesso.
Nos ltimos anos, MDD tem se posicionado como uma tendncia na prtica e na pesquisa em engenharia de software. Embora o uso de modelos no seja novidade, o seu sucesso vem da possibilidade de construir sistemas de software completos a partir de transformaes automticas de modelos. Propostas como Software Factories1 da

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

Microsoft, MDA2 (Model-Driven Architectue) da OMG e EMF3 (Eclipse Model Framework) da IBM esto entre as abordagens de desenvolvimento orientadas a modelos mais conhecidas na literatura. Em particular, MDA vem ganhando bastante ateno na academia e indstria, pois sugere a separao dos modelos em vrios nveis de abstrao (CIM, PIM e PSM) e incentiva a evoluo dos modelos atravs da definio de regras de transformao. 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 includos dentro dos modelos e quais modelos devem ser gerados em cada nvel de abstrao. Alm disso, outro problema comum vincular a arquitetura final do sistema s transformaes dos modelos [53]. Idealmente, transformaes de modelo devem ser configurveis e fazer cumprir as decises de arquitetura. No entanto, algumas metodologias pesquisadas [68, 69, 70, 72, 73] no se preocupam em incorporar decises arquiteturais s transformaes, a fim de garantir uma arquitetura flexvel e que segue as decises 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 servios tambm se tornou uma tendncia e vem chamando ateno tanto da indstria quanto da academia, pois possibilita o desenvolvimento de aplicaes mais flexveis, modulares e reutilizveis. Mas, apesar dessas vantagens, a maioria dos processos e metodologias SOA disponvel na literatura apresentam limitaes que dificultam sua adoo na prtica. Entre elas, podemos destacar [53]: Utilizar abordagens de desenvolvimento de propsito geral sem apoio decises de projeto: importante definir guias e boas prticas que orientem no projeto dos servios dos sistemas;

2 3

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

Delegar importantes decises arquiteturais aos programadores ou ferramentas de automao: na prtica, so os arquitetos que identificam os principais problemas e definem a arquitetura final do sistema, isso no algo simples que pode ser delegado a analistas de negcios, progamadores, ou mesmo embutido em ferramentas de automao.

Diante deste cenrio, este trabalho apresentada um processo de projeto arquitetural de software dirigido a modelos e orientado a servios, a fim de possibilitar o projeto de arquiteturas estveis, flexveis e modulares. O processo foi elaborado para ser sistemtico, fcil de usar e compreender, independente de ferramentas e tecnologias, e que pudesse resolver problemas prticos como: a integrao de aplicaes, 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 trs conjuntos de atividades (workflows) distintos: Especificar Modelo de Negcio, Analisar Servios e Projetar Servios. Especificar Modelo de Negcio tem como principal objetivo produzir

artefatos que ajudem no alinhamento do entendimento entre os stakeholders. Analisar Servios tem como principal finalidade projetar a arquitetura do sistema independente de plataforma de desenvolvimento. No Final, Projetar Servios 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 Contribuies

Entre as principais contribuies deste trabalho, podemos destacar: 1. Definio de um processo sistemtico para projeto arquitetural de software dirigido a modelos e orientado a servios, favorecendo: o Reutilizao de software: Nas primeiras fases do processo possvel identificar oportunidades de reuso.

Modularidade: Com os artefatos gerados pelo processo possvel projetar uma arquitetura desacoplada, tornando possvel projetar os componentes de forma independente.

2. Avaliao do processo atravs de um estudo experimental: Foi conduzido um estudo experimental com 19 alunos de graduao 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 prototipao 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 instanciao do processo para o contexto da disciplina na qual foi executada o experimento, mostrando assim que o processo flexvel, fcil de usar e pode ser utilizado em outros contextos. Para isso, o processo utiliza conceitos, fundamentos e artefatos bastante utilizados tanto na indstria como na academia.

1.3 Fora do Escopo

Uma fez que o processo arquitetural proposto faz parte de um contexto mais amplo, algumas questes importantes no foram abordadas nesse trabalho. Entretanto, essas questes foram pensadas desde o incio e constituem tpicos de pesquisa a serem explorados em trabalhos futuros: 1. Transformao de modelos: O processo utiliza os conceitos de MDA e MDD, mas no foram definidas regras formais para transformao 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, gerncia de configurao, gerenciamento de atividades e codificao no foram abordados.

3. Reengenharia: O processo proposto no aborda metodologia e tcnicas de refactoring e reengenharia. 4. Ferramentas: Neste trabalho no foram desenvolvidas ferramentas especificas para dar suporte e/ou automatizar as atividades do processo.

1.4 Organizao da Dissertao

O trabalho est organizado da seguinte forma: Captulo 2: Este captulo apresenta uma breve introduo sobre SOA e MDD, detalhando os principais conceitos, definies, mtodos e prticas sobre cada abordagem. Captulo 3: Neste captulo so mostrados em detalhes todas as fases, atividades e artefatos gerados pelo processo proposto. Captulo 4: Neste captulo mostrada uma instanciao do processo com um estudo de caso para ilustrar todas as etapas e artefatos gerados pelo processo na prtica. Captulo 5: Neste captulo apresentado o estudo experimental feito para avaliao do processo. Todas as fases da abordagem Goal Question Metric so mostradas em detalhes. Captulo 6: Neste captulo apresentado um resumo de todo o trabalho, mostrando o relacionamento com outros trabalhos disponveis na literatura. Por fim, so mencionadas as limitaes e oportunidades a serem feitas em trabalhos futuros. A Figura 1.1 mostra o roadmap para orientar a leitura do trabalho.

Captulo 1 Introduo

Motiva e Contextualiza

Captulo 2 Conceitos e Fundamentos

usado por

Motiva e apresenta o problema para

Captulo 3 O Processo

avaliado por

Captulo 5 Avaliao do processo

instanciado por

Captulo 4 Exemplo de uso

Motiva

Motiva

Captulo 6 Concluso

Figura 1.1 Roadmap do trabalho.

Captulo 2 - Conceitos e Fundamentos

2.1 Introduo
A maioria das organizaes possui solues que envolvem plataformas heterogneas, desenvolvidas usando diferentes tecnologias. Como os recursos (pessoas, tempo, mquinas, investimentos) so escassos, as empresas no podem simplesmente descartar as aplicaes existentes. Uma das solues para prolongar a vida til dessas aplicaes o paradigma de computao orientada a servios (service oriented computing - SOC) [7], pois atravs desse paradigma possvel estabelecer uma comunicao no intrusiva com os sistemas legados, reutilizar aplicaes e prover a interoperabilidade entre diferentes tecnologias. Arquitetura Orientada a Servio (SOA) , basicamente, um projeto de arquitetura de software que favorece a eficincia, agilidade e produtividade no desenvolvimento de aplicaes e est alinhada com os objetivos de service oriented computing [7]. O componente fundamental de SOA o conceito de servio que uma funo de negcio independente, sem estado (stateless) que recebe como entrada uma ou mais requisies e devolve uma resposta atravs de uma interface padronizada e bem definida [22]. Cada servio completamente autnomo em relao a outros servios. SOA tem como principal objetivo o reuso intenso dos seus servios para que, em mdio prazo, a tarefa do desenvolvimento de uma aplicao seja, primordialmente, a composio e coordenao dos servios j implementados, aumentando o reuso e diminuindo o dispndio de recursos. Para atingir esses objetivos, SOA segue boas prticas e princpios de projeto para facilitar a tarefa de definir, encontrar e gerenciar os servios [22]. Por outro lado, MDD [8] utiliza modelos para especificar e implementar toda e qualquer parte dos sistemas. Utilizando MDD os sistemas so projetados em vrios nveis de abstrao e de diferentes perspectivas. Diferentemente de outras abordagens de desenvolvimento de software, os modelos so os artefatos centrais para a construo das aplicaes, e no o cdigo.

A idia por trs de MDD que possvel criar modelos com alto nvel de abstrao que possam ser, atravs de diversas transformaes, traduzidos em componentes executveis [21]. Model Driven Architecture (MDA) a abordagem definida pela OMG (Object Management Group) que descreve um processo bsico, padronizado e extensvel para o desenvolvimento de software dirigido a modelos. Neste contexto, este captulo apresenta uma introduo sobre SOA e MDE que so a base para o desenvolvimento do processo proposto neste trabalho. A Seo 2.2 mostra uma viso geral sobre MDD e os conceitos bsicos da abordagem MDA. A Seo 2.3 mostra os conceitos bsicos, objetivos e vantagens relativos a SOA.

2.2 MDD Model Driven Development

O Desenvolvimento Dirigido a Modelos, do ingls Model-Driven Development (MDD), uma abordagem de desenvolvimento de software onde os modelos so os artefatos centrais para a construo das aplicaes. A idia central de MDD que possvel criar modelos com alto nvel de abstrao que possam ser, atravs de diversas transformaes, traduzidos em componentes executveis [21]. Ou seja, os sistemas so modelados em vrios nveis de abstrao e de diferentes perspectivas. O MDD tambm conhecido como MDE (Model-Driven Engineering) ou MDSD (Model-Driven Software Development). Todos esses acrnimos se referem mesma abordagem, cuja idia reconhecer a importncia dos modelos no processo de software, no apenas como um guia para tarefas de implementao e manuteno do software [54]. A Figura 2.1 ilustra um processo genrico de Desenvolvimento Dirigido a Modelos.

Figura 2.1 Processo MDD genrico [54]. A Figura 2.1 ilustra a ideologia por trs de MDD: model once, run everywhere. A idia que construindo modelos de alto nvel, independente de tecnologia e focados exclusivamente no domnio do problema, mecanismos podero transformar esses modelos em cdigos para diversas plataformas. Com isso, no ser mais necessria a implementao de cdigo manualmente.

2.2.1 Vantagens e Desvantagens

MDD visa acelerar o desenvolvimento de software a fim de torn-lo mais eficiente. A seguir so apresentadas algumas vantagens na utilizao de MDD [23, 57, 58, 59]: Produtividade: Tarefas que so repetitivas podem ser implementadas nas transformaes dos modelos, diminuindo o tempo e esforo que podem ser utilizado em outras tarefas mais importantes. Alm disso, a partir dos modelos pode-se gerar cdigo para diversas plataformas e tecnologias. Portabilidade e interoperabilidade: um nico modelo poder ser

transformado em cdigo para vrias plataformas. Com isso, podem ser construdos modelos de adaptadores e conectores independentes de tecnologia e depois transform-los em cdigo para que diferentes plataformas possam se comunicar;

10

Comunicao: os profissionais envolvidos no projeto podero se comunicar de forma mais efetiva, pois os modelos so mais abstratos e fceis de entender do que o cdigo, no exigindo conhecimento tcnico de uma tecnologia especfica. Por isso, especialistas podero participar ativamente e utilizar diretamente os modelos para identificar os conceitos relativos ao problema.

Corretude: os geradores de cdigo no introduzem erros banais como erros de digitao, portanto a identificao de erros conceituais acontece em um nvel de abstrao mais alto, tornando-se, teoricamente, resolver. mais fceis de

Em resumo, as vantagens relacionadas ao uso de MDD esto diretamente relacionadas capacidade de evitar que os desenvolvedores executem tarefas repetitivas que podem ser desempenhadas pelas transformaes. E, diferente de outras abordagens de desenvolvimento de software, com mecanismos de

transformaes automticas seria mais produtivo construir os sistemas em um nvel de abstrao alto, pois isso possibilitaria no s o reuso de componentes de software, mas tambm a reutilizao 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), organizao internacional que define padres abertos para aplicaes 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 definio formal de MDA que foi publicada em 2001 [61]. Esta era uma verso formal, mas incompleta que foi sendo aprimorada e, em 2003, foi publicada uma verso 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 execuo de sistemas;

11

Especificar transformaes de modelos.

Um modelo de um sistema uma descrio ou especificao desse sistema e seu ambiente para um propsito determinado. Um modelo muitas vezes apresentado como uma combinao de desenhos e texto. O texto pode estar em uma linguagem de modelagem ou em uma lngua natural. No contexto de MDA, um modelo , basicamente, uma representao de um sistema. MDA classifica o modelo em trs tipos: Computation Independent Model (CIM): Os requisitos do sistema podem ser especificados com modelos independente de computao (CIM). O CIM descreve a situao em que o sistema ser utilizado. Em outras abordagens esse modelo chamado de modelo de domnio ou modelo de negcio. O CIM oculta todas as informaes 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 computao e descreve o sistema ocultando detalhes de plataforma e tecnologias de desenvolvimento. Esses modelos apresentam o ncleo 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 especfica. O PSM o refinamento do PIM, ou seja, ele combina as informaes do PIM para uma plataforma em particular (Java ou .Net, por exemplo). Em princpio, o processo de desenvolvimento de software utilizando MDA comea com a definio do Modelo de Computao Independente (CIM). O CIM pode ser definido por analistas de sistemas em cooperao com especialistas do domnio. Posteriormente o CIM transformado em um modelo independente de plataforma (PIM). O PIM acrescenta informaes ao CIM, sem mostrar os detalhes da plataforma utilizada. Por fim, o PSM transformado em um modelo de plataforma especfica (PSM) acrescentando os detalhes da plataforma escolhida. A Figura 2.2 ilustra o processo MDA bsico descrito anteriormente.

12

Figura 2.2 Processo MDA Bsico [30]. Conforme mostrado na Figura 2.2, MDA define um ciclo bsico para o desenvolvimento de software e divide as atividades de refinamento e transformaes de modelos em passos separados, facilitando assim a automao do processo. Os conceitos relacionados ao processo de transformao de modelos MDA so: Transformao e Definio de Transformao [30]. Transformao a gerao de um modelo a partir de um modelo de origem, de acordo com uma definio de transformao. Transformaes de modelo podem ser manuais ou automticas. Definio de transformao 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 transformaes de modelos utilizado em MDA.

13

Figura 2.3 Processo de transformao de Modelos MDA [30]. Conforme apresentado na Figura 2.3, para possibilitar transformaes automticas atravs de uma ferramenta, necessrio que os modelos tenham sido escritos em uma linguagem formal com sintaxe e semntica bem definidas. Para isso, MDA adota o padro MOF (Meta-Object Facility) [55] para definio das linguagens dos modelos. MDA trabalha com os conceitos de meta-modelo e meta-linguagem. Meta-modelo o modelo de uma linguagem para definio de modelos. Meta-linguagem uma linguagem para definio de meta-modelos. Assim, MDA define quatro nveis de modelagem que so ilustrados na Figura 2.4.

14

Class

instace of UML Class name: String instace of Video title: string instace of a:Video title = "Casa Blanca"

instance of

UML Atribute name: string

instance of

Figura 2.4 Nveis de modelagem em MDA. O nvel M0 define os modelos executveis do sistema. O nvel M1 descreve as abstraes no domnio do sistema que so usadas no nvel M0. O nvel M2 descreve os meta-modelos usados em M2 e, em M3, so definidas as metas-linguagem utilizadas em M2.

2.4 SOA
Devido ao no esclarecimento dos termos e conceitos, SOA tem sido utilizado em diferentes contextos e com diferentes propsitos. Por isso, dependendo do interlocutor, arquitetura orientada a servios pode ter diferentes interpretaes, conforme mostra a Figura 2.5:

15

Figura 2.5 Diferentes pontos de vistas de SOA [56]. Essa confuso ocorre porque o termo service oriented architecture muitas vezes confundido com service oriented computing. Por isso, muito importante deixar claro a distino entre termos e conceitos relacionados a SOA. Service Oriented Computing (SOC) [7], segundo Thomas Erl, um conceito bastante amplo que representa uma nova gerao de plataforma de computao distribuda. Engloba

vrios elementos como princpios de design, padres de projeto, linguagens de programao, hardware, frameworks, processos e estratgias organizacionais. SOA , basicamente, um modelo de arquitetura de software que beneficia a eficincia, agilidade e produtividade no desenvolvimento de aplicaes e est alinhada com os objetivos de service oriented computing. Uma arquitetura de software um conceito abstrato que d margem a uma srie de definies. Este trabalho utiliza a definio 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 aplicaes so modeladas como servios. Servio um componente que atende a uma funo de negcio (business function) especfica. Ele pode receber e responder requisies ocultando completamente os detalhes de sua implementao. Portanto, um servio pode ser considerado um

16

conjunto de capacidades associadas a um propsito comum (ou contexto funcional). Essas capacidades esto expressas em um contrato de servio. Baseando-se na natureza da lgica do negcio, no potencial de reutilizao dessa lgica e como a lgica implementada se relaciona com o domnio da aplicao, os servios podem ser classificados em trs tipos [7]: Servio de Entidade (Entity Services): um tipo de servio que derivado de uma ou mais entidades de negcio relacionadas e possuem alto grau de reutilizao. Servios que fazem operaes CRUD (Create, Read, Update, Delete), por exemplo. Servio de Tareta (Task Service): servio que corresponde a um nico propsito. Um servio de tarefa geralmente possui um baixo potencial de reuso e utiliza outros servios para realizar a sua lgica. Servio de Utilidade (Utility Service): Servio comum a vrios tipos de aplicao como log, notificao, tratamento de exceo e transformao de informaes. Tem um alto potencial de reuso e desenvolvido para ser usado por outros servios. A Figura 2.6 mostra o relacionamento entre os trs tipos de servios em uma aplicao.

Figura 2.6 Relacionamento entre os tipos de servios [7]. Conforme mostrado na Figura 2.6, os servios de tarefas ficam na primeira camada, pois possuem um potencial de reuso baixo e normalmente utilizam outros servios para realizar as suas capacidades. Os servios de entidade ficam na camada

17

intermediria. J os servios de utilidade ficam na camada inferior e so utilizados frequentemente pelos servios das camadas superiores, pois possuem um alto potencial de reuso.

2.4.1 Vantagens e Limitaes

Seguem alguns benefcios em utilizar uma arquitetura orientada a servios [46] [47] [7]:

Reuso caixa-preta: O reuso caixa-preta visa eliminar a necessidade de o programador ter conhecimento da implementao de um determinado componente de software que far parte do processo de reuso. O reuso caixapreta se d atravs da descrio de interfaces ou contratos bem definidos que devem ser respeitados durante o desenvolvimento. O esforo sempre usado na nova implementao e no no entendimento da implementao do componente.

Interoperabilidade: O fenmeno da Web 2.0 apresentou uma nova realidade para os desenvolvedores de sistemas. Por ser uma rede de escala gigantesca existe uma infinidade de servios que podem ser acessados atravs da Internet. Usando SOA possvel acessar servios em diferentes plataformas de hardware, implementados em diferentes linguagens de programao, usando protocolos bem definidos.

Baixo acoplamento: Cada atividade (funo de negcio) implementada como um servio, ou seja, um componente independente que poder ser utilizado quantas vezes forem necessrias em diversas partes do sistema. Assim, SOA uma arquitetura baseada em componentes onde cada componente preserva a sua independncia.

Entretanto, apesar das vantagens apresentadas, a adoo SOA nas empresas tambm requer um grande investimento inicial e o retorno sobre o investimento (ROI) pode levar um longo tempo para acontecer. Algumas desvantagens e limitaes referentes a SOA so listadas a seguir [42] [43] [44]:

18

Servios

com

granularidade

grossa:

dependendo

do

tamanho

complexidade das aplicaes, testar e validar todas as combinaes de todas as condies de um servio complexo pode se tornar impossvel. Se um servio altamente genrico for utilizado por dezenas de outros, a sua otimizao pode ser uma tarefa muito difcil. Acoplamento fraco: o sonho de todo arquiteto projetar um sistema distribudo altamente desacoplado, mas adicionar novas funcionalidades com um alto nvel de complexidade pode se tornar um pesadelo. Integrao: especialmente integrao de servios uma pode ser uma tarefa complexa,

quando h

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

disponveis no mercado que so atualizadas constantemente. Portanto, custa tempo e dinheiro treinar e manter uma equipe atualizada.

2.5 SoaML
SoaML (Service Oriented Architecture Modeling Language) uma especificao da OMG que descreve um profile UML e metamodelos para projetar sistemas SOA. O principal objetivo de SoaML dar suporte ao projeto de servios em abordagens de desenvolvimento de software dirigidas a modelo. Com SoaML possivel modelar requisitos, especificar servios de sistemas, especificar interface de servios e projetar os servios internamente. Os sistemas so modelados na viso de provedores e consumidores de servios. Os consumidores e provedores de servios podem ser pessoas, organizaes e outros sistemas, em SoaML ele so chamados de participantes. O conceito-chave em SoaML , naturalmente, o de servio. Servio definido como a entrega de valor para outro parte (consumidor) por meio de uma ou mais capacidades [29]. O acesso ao servio feito atravs de um contrato que definine as politicas e restries que devem ser obedecidas. Um servio fornecido por um

19

participante que atua como o provedor para ser utilzados por outros participantes consumidores. Participantes oferecem servios atravs de portas via o esteretipo <<Service>> e requisitam servios atravs de portas com o esteretipo <<Request>> Essas portas representam os pontos onde os servios so consumidos ou oferecidos. A Figura 2.7 mostra um exemplo de uso de servios e participantes.

Figura 2.7 Seros e participantes [26]. A Figura 2.7 mostra o participante "Productions" fornecendo o servio "scheduling". A porta do servio a interface UML "Scheduling" que tem duas operaes: "requestProductionScheduling" e "sendShippingSchedule". A porta do servio tem um tipo que descreve como usar esse servio. Esse tipo pode ser uma interface UML (para servios muito simples Simple Interface) ou uma Service Interface. Em ambos os casos o tipo da porta de servio especifica tudo que necessrio para interagir com esse servio, ou seja, o contrato entre os provedores e consumidores desse servio. As sees a seguir mostram os principais elementos utilizados para projetar servios em SoaML.

20

2.5.1

Simple Interfaces

Interface Simples (Simple Interface) utilizada para especificar interaes de mo nica. O participante recebe operaes e fornece os resultados diretamente para quem fez a requisio. Este tipo de interface pode ser usada com consumidores annimos, ou seja, o fornecedor no sabe nenhuma informao sobre o consumidor e como feita a coreografia do servio. Interfaces simples so muitas vezes utilizadas para expor diretamente as capacidades dos sistemas ou para definir os servios mais simples que no tm protocolos (troca de mensagens seguindo uma ordem predefinida). Interface Simples um caso especifico de Service Interface e ServiceContract, onde o servio unidirecional - o consumidor chama operaes do fornecedor e recebe a resposta, pois o fornecedor no 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 servio Shipment status. Essa interface pode ser usada como uma porta do tipo <<Service>> ou <<Request>>.

Figura 2.9 Uso de Interface Simples como portas dos participantes [26]. A Figura 2.9 mostra o uso da Interface Simples Shipment Status como portas dos tipos <<Service>> e <<Request>>. Quando usada como << Request >> a interface

21

consumidora. Quando usada como << Service >> a interface provedora e deve entregar a resposta em uma porta compatvel.

2.5.2

Service Interface

Interface de Servio (Service Interface) permite especificar servios bidirecionais o fornecedor chama de volta (callback) o consumidor. A Interface de Servio definida em termos do provedor do servio e especifica a interface que o provedor oferece, bem como a interface que, se for o caso, ela espera consumir. A Interface de Servio tambm pode especificar a coreografia do servio quais informaes so enviadas entre o provedor e o consumidor e em que ordem (protocolo). Um consumidor de um servio especifica a interface de servio de que necessita utilizando uma porta <<Request>>. A Interface de Servio do tipo <<Service>> no provedor e do tipo <<Request>> no consumidor. As interfaces do consumidor e fornecedor devem ser compatveis, ou seja, o consumidor concorda em usar o servio conforme definido em sua Interface de Servio, e o fornecedor se compromete em fornecer o servio de acordo com o que foi definido na interface (como ilustrado na Figura 2.11). Interface de Servio mais usada quando as capacidades existentes so diretamente expostas como servios e em seguida utilizadas de vrias maneiras, ou em situaes que envolvem uma ou mais entidade no protocolo. Diferente da Interface Simples, a Interface de Servio no 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 Servio.

22

Figura 2.10 Definio de uma Interface de Servio [26]. Conforme mostrado na Figura 2.10 a Interface de Servio uma classe UML (<<ServiceInterface>> PlaceOrder Service) e define papis especficos que cada participante desempenha na interao de servio. Esses papis tm 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 servio, a coreografia do servio.

23

Figura 2.11 Coreografia do Servio [26]. Na coreografia do servio, mostrada na Figura 2.11, o consumidor Order Place chama (opcionalmente) a operao Quote Request e depois chama a operao Order.

2.5.1

Service Contract

Contrato de Servio (Service Contract) determina como fornecedores, consumidores e, potencialmente, outros papis trabalham juntos para trocar informaes. O Contrato de Servio define os papis que cada participante desempenha no servio

24

(como provedor ou consumidor) e as interfaces que implementam para desempenhar esse papel. Essas interfaces so as portas que obrigam os participantes a desempenhar o seu papel definido no Contrato de Servio. O Contrato de Servio representa o acordo entre os participantes de como o servio ser consumido e fornecido. Este acordo deve incluir todas as interfaces, coreografia e quaisquer outras informaes. Se provedor e consumidor suportam contratos de servios diferentes, deve haver um acordo ou determinao de que seus contratos de servio so compatveis e coerentes com outros compromissos do mesmo participante. Contratos de servios podem fazer parte de uma ou mais arquiteturas de servios (define como um conjunto de participantes fornece e consume os servios para um objetivo ou processo de negcio). Normalmente, Contratos de Servio so inseridos "no meio" dos participantes e as extremidades (os participantes) concordam com a sua parte no contrato ou se adaptam a ele. Na seo a seguir ser mostrado o exemplo de uso de Contratos de Servios na Arquitetura de Servio.

2.5.1

Service Architecture

Um dos principais benefcios do SOA a capacidade de permitir que comunidades, organizaes ou sistemas trabalhem em conjunto de forma mais coesa usando servios, sem ficar excessivamente acoplados. Isso requer uma compreenso de como essas entidades trabalham e colaboraram. SoaML permite especificar essa colaborao atravs da Arquitetura de Servio (Service Architecture). A Arquitetura de Servio uma rede de participantes, com papis bem definidos, fornecendo e consumindo servios para cumprir um objetivo comum. A Arquitetura de Servio tambm pode ter um processo de negcio para definir as tarefas e orquestrao dos servios. A Arquitetura de Servios pode ser projetada em dois nveis de granularidade: arquitetura do domnio e arquitetura dos participantes. O primeiro nvel, arquitetura de servios do domnio, corresponde a uma viso de alto nvel mostrando como os participantes de um determinado domnio trabalham em conjunto para realizar um propsito especfico. O segundo nvel, arquitetura de servios do participante, define a arquitetura de servios interna de um participante. A Arquitetura de Servios do

25

domnio definida utilizando diagrama de comunicao UML, e Arquitetura de Servios de um participante pode ser modelada como um diagrama de classe ou componentes. A Figura 2.12 mostra um exemplo de Arquitetura de Servio.

Figura 2.12 Exemplo de Arquitetura de Servio [26]. A Figura 2.11 mostra a Arquitetura de Servio de uma comunidade composta por um fabricante (<<Participant>> Manufacturer), um revendedor (<<Participant>> Dealer), e uma empresa de transporte (<<Participant>> Shipper). Neste cenrio, o revendedor faz um pedido (<<Service Contract>>Order) ao fabricante, o fabricante confirma o pedido e solicita o envio da mercadoria requisitada (<<Service Contract>>Ship Request), que enviada pela empresa de transporte. A qualquer momento o revendedor pode verificar o status atual do pedido (<<Service Contract>> Ship Status).

26

Captulo 3 - O Processo

3.1 Introduo
O principal objetivo deste trabalho definir um processo sistemtico de projeto arquitetural de software dirigido a modelos e orientado a servios a fim de possibilitar o projeto de arquiteturas estveis, flexveis e modulares, e que possa resolver problemas prticos como: a integrao de aplicaes, 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 Negcios, Analisar Servios e Projetar Servios. A Figura 3.1 mostra a viso geral do processo proposto.

Figura 3.1 - Viso Geral do Processo. A Figura 3.1 mostra a viso geral do processo considerando os termos MDA e os conceitos e princpios utilizados em SOA. No workflow Especificar Modelo de

27

Negcios so construdos os modelos independentes de computao (CIM), pois os artefatos gerados no so modelos de software e podem ser compreendidos por diferentes stakeholders e elaborados por especialistas de domnio. No workflow Analisar Servios so gerados modelos com alto grau de abstrao e independentes de plataforma e tecnologia (PIM) utilizando SoaML(um profile UML para projetar sistemas SOA). Por fim, no workflow Projetar Servios so gerados modelos mais detalhados levando-se em considerao as tecnologias, plataformas e linguagens de programao (PSM) utilizadas para a implantao, execuo e codificao das aplicaes.

3.2 Especificar Modelo de Negcio

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 no prejudicar o entendimento do diagrama).

28

Figura 3.2 Especificar Modelo de Negcio. Tendo em vista a grande variedade de artefatos produzidos pelos principais processos de engenharia de software adotados na indstria nos dias de hoje, a primeira atividade, Modelar Conceitos de Negcio (Figura 3.2), pode receber como entrada documentos como: Requisitos do Sistema, Casos de Uso, Requisitos de Negcio 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 Negcio tem como sada o Modelo de Informao do Negcio (MIN) e o Modelo de Funcionalidades (MF). O MIN no um modelo de software, e sim um modelo de informao que existe no domnio do problema. Seu principal objetivo capturar conceitos e identificar relacionamentos entre eles. Para a construo do MIN, devem ser usadas informaes existentes nos

29

documentos de entrada. O MIN pode ser comparado com o modelo de tipos de negcios que ajuda a identificar os conceitos de negcio que o sistema dever manipular. O MIN representado como um diagrama de classes UML sem atributos e operaes contendo as classes conceituais do sistema. Neste modelo a especificao 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 usurios (representados pelos atores) da aplicao. Da mesma forma que o MIN, o MF construdo a partir do conhecimento do negcio e dos documentos de entrada. Com isso, as

funcionalidades, os usurios e os sistemas externos so representados em um modelo de casos de uso. A segunda atividade Projetar Fluxo de Informao que tem como entrada o MIN. Esta atividade gera como sada 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 grficas, para organizar o fluxo de telas (ou pginas, no caso de aplicaes 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 esteretipos para representar as janelas principais (<<

primaryWindow>>), caixa de mensagens (<<messageBox>>), janela de escolha de

30

arquivo (<<fileChooser>>), frames (<<frameSets>> e <<frame>>) e a navegabilidade entre as telas (<<links>>). O MN tambm pode ser projetado como um site map [27] (bastante usado em aplicaes web) ou User interface flow [61] (bastante usado em metodologias geis). A ltima atividade do workflow Especificar Modelo de Negcios Elaborar Prottipo de Interface. Esta atividade tem como entrada os artefatos gerados anteriormente e gera como sada o Prottipo da Interface Grfica (PIG). O PIG , basicamente, um layout completo do sistema que contem todas as funcionalidades, telas, contedo e mensagens do sistema. A Figura 3.5 mostra o PIG correspondente tela apresentada na Figura 3.4.

Figura 3.4 Exemplo de Interface Grfica [30].

31

Figura 3.5 Exemplo do Prottipo de Interface Grfica [30]. A imagem, os textos, a caixa de texto, os seletores e o boto foram modelados com os esteretipos PresentationImage, Text, InputTextBox, RadioButton, CheckBox e Button, respectivamente. A proporo de alguns elementos foi alterada para facilitar a visualizao de seus nomes. O PIG tambm pode ser projetado como um wireframe [27] completo do sistema que contm todas as funcionalidades, telas, contedo e mensagens. Wireframes so muito utilizados na indstria 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 Negcios.

32

conforms To MOF

conforms To UML2 MM

conforms To

GuiProfile UML MM extends

instance Of instance Of

instance Of

instance Of

MF

MIN

MN

PIG

Figura 3.6 Modelos da fase Especificar Modelo de Negcio. Conforme ilustrado na Figura 3.6, o Modelo de Informao de Negcios (MIN) e o Modelo de Funcionalidades um modelo UML 2.0. O Modelo Navegacional (MN) e o Prottipo de Interface Grfica (PIG) so instncias do GuiProfile. O GuiProfile uma extenso 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 Servios

O principal objetivo de Analisar Servios construir os primeiros modelos arquiteturais do sistema. Isto feito utilizando uma sistemtica para identificao dos primeiros servios e componentes. Para a criao dos modelos utilizado SOAML [29], um profile UML para projetar sistemas SOA. A Figura 3.7 mostra o fluxo de atividades de Analisar Servios.

33

Figura 3.7 Fluxo de atividades da fase Analisar Servios. A primeira atividade Identificar Servios, que recebe como entrada o Modelo de Funcionalidades e o Modelo de Informao do Negcio, e gera como sada a Arquitetura de Servios (AS). A Arquitetura de Servio descreve como os participantes (participants) [29] trabalham em conjunto para fornecer e utilizar os servios descritos nos contratos de servio (service contracts) [29]. Os participantes representam entidades que fornecem e consomem servios. Os participantes podem ser pessoas, organizaes ou outros sistemas, por exemplo. Um contrato de servio a especificao de um acordo entre

34

provedores e consumidores de servios quanto s informaes que sero trocadas entre eles. A partir do Modelo de Funcionalidades pode se gerar a Arquitetura de Servio automaticamente utilizando as seguintes regras: Contratos de servios: os pacotes de casos de uso do modelo de funcionalidades so mapeados em contratos de servios. Casos de usos que no pertencem a nenhum pacote so mapeados em contratos de servios independentes. Os relacionamentos entre caso de uso ator tambm so mapeados como contratos independentes. Participantes: os atores so diretamente mapeados como participantes. O sistema d origem a um participante independente que ir consumir e fornecer servios para os outros participantes. O prprio sistema d origem a um participante independente. Para facilitar a compreenso, a Figura 3.8 mostra visualmente o processo de transformao.

35

Pacote 2 UC 5 UC3 UC 4

Pacote 1 UC 1 Ator 1 Ator 2

UC2

<<Service Contract>> Pacote1 provide consume

<<Service Contract>> UC5-Ator2

consume

provide <<Participant>> Ator2

<<Participant>> Ator1

consume

<<Service Contract>> Pacote2

<<Participant>> Sistema provide

consume provide <<Service Contract>> UC5

Figura 3.8 Construo da Arquitetura de Servios. No exemplo mostrado na Figura 3.8, os pacotes de casos de uso (Pacote 1 e Pacote 2 ) foram mapeados nos contratos de servios 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 servio (<<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 servios ao participante Ator 1 e consumir de Ator 2.

36

A segunda atividade de Analisar Servios Refinar Servios, que recebe como entrada a AS, o MIN e tem como sada o Modelo de Interao dos Servios (MIS) e o MIN refinado. Esta atividade tem como principal objetivo identificar as capacidades dos servios (services capabilities) [7]. operaes das interfaces dos servios. Para construir o MIS necessrio identificar os servios de entidades [7], um tipo de servio que derivado de uma ou mais entidades de negcio relacionadas e possuem alto grau de reutilizao: servios que fazem operaes CRUD (Create, Read, Update, Delete), por exemplo. Pode-se obter os contratos de servios de entidades marcando as entidades do MIN com o esteretipo <<Entity Service>>. A Figura 2.8 ilustra esse processo. As capacidades dos servios representam

funes especficas atravs das quais os servios podem ser invocados. Elas so as

<<entity service>> E1

<<entity service>> E2

E3

MIN marcado

<<service contract>> Servio E1

<<service contract>> Servio E2

Figura 3.9 Servios de Entidade. Com a identificao dos servios de entidade e a Arquitetura de Servios possvel criar automaticamente os templates dos Modelos de Interao dos Servios 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 servios e servios de entidade (representando a porta <<Service>> dos participantes

consumidores de SoaML);

37

3. Para cada contrato de servio criado automaticamente um MIS contendo: a. a interface com o nome do participante consumidor do contrato de servio; b. a interface com o nome do contrato de servio e c. as interfaces dos servios de entidade. Com o template do MIS construdo, pode-se identificar manualmente as operaes e mensagens de cada interface (baseado nos artefatos de entrada para o processo).A Figura 3.10 mostra um exemplo da construo de um MIS completo.
: Participantes 1 : Servico1

: Servio E1

: Servico 2

operacao1()

operacao1() retorno

operacao1()

retorno operacao2() retorno

retorno

Figura 3.10 Modelo de Interao de Servios. O MIS pode ser construdo como um diagrama de sequncia ou de comunicao. importante notar que o MIS no deve conter mensagens reflexivas e no precisa exibir a seqncia numrica, pois o objetivo identificar apenas as operaes das interfaces e no como estas operaes so realizadas. Ao final, as interfaces de servios de entidades no utilizadas so removidas. Com a elaborao dos Modelos de Interao dos Servios podem surgir novas entidades que no foram identificadas previamente e identificar entidades no utilizadas ou modeladas incorretamente, portanto, o MIN dever ser atualizado. Aps a construo dos Modelos de Interao dos Servios a Arquitetura de Servio revisada levando-se em considerao as seguintes questes:

38

Empacotamento das funcionalidades foi feito de forma correta? As funcionalidades isoladas poderiam fazer parte de algum contrato de servio existente? Todas as funcionalidades foram contempladas?

A ltima atividade de Analisar Servios Identificar Componentes. Essa atividade tem como objetivo construir o Modelo de Componentes dos Servios (MCS). O MCS a primeira arquitetura componentizada do sistema. O MCS tambm pode ser construdo a partir da transformao da AS e dos MIS atravs das seguintes regras: os participantes exclusivamente consumidores so mapeados em

componentes; os contratos de servios so mapeados em componentes e suas respectivas interfaces (interfaces com o mesmo nome do contrato de servio geradas na atividade anterior); As operaes das interfaces so obtidas diretamente das operaes identificadas no MIS. A Figura 3.10 mostra visualmente as regras para construir o Modelo de Componentes dos Servios a partir da Arquitetura de Servios.

39

<<Service Contract>> Pacote1

<<Service Contract>> UC5-Ator2 provide consume <<Participant>> Sistema provide provide <<Participant>> Ator2

consume

<<Participant>> Ator1

consume

<<Service Contract>> Pacote2

consume provide <<Service Contract>> UC5

Arquitetura de Servios
<<Service Contract>> Service E1

Servio de Entidade

Componente 1 IServiceE1

ComponenteE1

IService1

Compoente A IServicec2

Componente 2

Componente 4 IServicec4 IService3

Componente 3

Figura 3.11Construo do Modelo de Componentes de Servios. Conforme ilustrado na Figura 3.11, participante Ator1 foi mapeado no Componente A e os contratos de servios: <<Service Contract>> Pacote 1 deu origem ao IService1 e Componente1 <<Service Contract>> Pacote 2 deu origem ao IService2 e Componente1 <<Service Contract>> UC5 deu origem ao IService4 e Componente4

40

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

Conforme mostrado anteriormente, os modelos gerados em Analisar Servios podem ser construdos sistematicamente e/ou gerados por meio de transformaes (apenas o MIS completo deve ser criado manualmente pelo arquiteto). A Figura 3.12 mostra o fluxo completo das transformaes de modelos envolvidos em Analisar Servios.
Modelo de Funcionalidades

Transformao CIM-PIM

Modelo Informao do Negcio

Arquitetura de Servios

Transformao PIM-PIM

Modelo de Interao de Servios (Template)

Modelo Informao do Negcio Refinado

Transformao PIM-PIM

Transformao PIM-PIM

Modelo de Interao de Servios (completo)

Modelo de Componenes de Servios

Figura 3.12Transformaes de modelo da fase Analisar Servios. A Figura 3.13 mostra os modelos, meta-modelos e meta-linguagens utilizados em Analisar Servios.

41

conforms To

MOF

conforms To conforms To UML2 MM extends instance Of instance Of SoaMLProfile MM

instance Of

instance Of

instance Of

MF

MIN

AS

MIS

MCS

Figura 3.13Modelos da fase Analisar Servios. O Modelo Funcional (MF) e o Modelo de Informao do Negcio (MIN) so modelos UML. A Arquitetura de Servios (AS), Modelo de Interao de Servios (MIS) e Modelo de Componentes dos Servios (MCS) so modelos SOAML. O profile SoaML foi modelado conforme seu meta-modelo SoaML MM que foram definidos com o MOF.

3.4 Projetar Servios

Projetar servios 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 documentao. 3. Elaborar modelos que mostrem como os objetos colaboram para desempenhar as operaes das interfaces dos componentes. 4. Projetar o sistema para que ele execute em uma plataforma especfica.

42

A Figura 3.14 apresenta o fluxo de atividades desta fase.

Figura 3.14Diagrama de artefatos de Projetar servios Na primeira atividade, Definir Arquitetura do Sistema, feita a reviso e o refinamento dos modelos gerados na fase anterior. Baseado na documentao do sistema e no conhecimento do negcio uma boa prtica revisar o Modelo de Interao dos Servios e Modelo de Componentes dos Servios, gerados no workflow anterior, levando-se em considerao as seguintes questes: Todos os componentes de front-end foram identificados?

43

Podemos agrupar contratos de servios semelhantes? Como ser a integrao entre o front-end e back-end? Como ser feita a comunicao com sistemas externos? possvel reutilizar, adaptar ou comprar componentes existentes?

Com isso, a atividade Definir Arquitetura do Sistema tem como sada a Arquitetura do Sistema que , basicamente, uma evoluo da Arquitetura de Componentes de Servios com todos os elementos necessrios para modelar os componentes internamente e os componentes de front-end marcados com o esteretipo <<Front-end>>. Com os modelos devidamente refinados, so definidos os padres, tecnologias e frameworks que sero utilizados no projeto do sistema. Portanto, devem-se levar em considerao os seguintes aspectos: Plataformas de desenvolvimento e frameworks: quais sero as plataformas, tecnologias e frameworks utilizados para o desenvolvimento do sistema? Integrao front-end e back-end: como ser a comunicao entre o font-end e o back-end do sistema? Padres de arquitetura: quais padres de arquitetura sero utilizados no desenvolvimento do sistema? Padres de projetos: quais padres de projetos sero utilizados na modelagem de cada componente? A Figura 3.15 mostra o exemplo de uma Arquitetura do Sistema.
<<Front-end>> Desktop <<Front-end>> Mobile

ICommunication Communication

IServiceContrac4 IServiceContrac2 Componente 4 Componente 2

IServiceContrac1

Componente 1

Componente 3 IServiceContrac3

Figura 3.15Exemplo de Arquitetura do Sistema.

44

Com a Arquitetura do Sistema definida, as atividades Projetar Front-end e Projetar Fack-end podem ser feitas em paralelo. importante destacar que o processo induz, de forma sistemtica, como ilustrado, definio 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 padres e regras definidas

anteriormente, para cada componente construdo seu diagrama de classes e os diagramas de sequncia de todas as operaes da sua interface. Portanto, necessrio detalhar a estrutura interna (atributo e operaes) e relacionamentos das classes projetadas, alm de garantir que elas fornecem o comportamento necessrio para realizar as operaes da interface do componente. 2. Atualizar modelo de informao: com todos os componentes modelados internamente, necessrio atualizar o modelo de informao do sistema. 3. Projetar banco de dados: com o modelo de informao refinado do sistema e todos os componentes projetados, caso seja necessrio, feito o projeto de banco de dados do sistema levando-se em considerao a tecnologia utilizada. Na atividade Projetar Front-end so construdos os diagramas de sequncia e de classe baseando-se no Prottipo da Interface Grfica, a integrao entre o front-end e back-end, os guias e padres definidos para cada componente front-end do sistema. Da mesma forma que a fase Analisar Servios, os modelos gerados na fase Projetar Servios podem ser construdos sistematicamente e/ou gerados por meio de transformaes. A Figura 3.16 mostra as transformaes de modelos envolvidos na fase Projetar Servios.

45

Padres de Arquitetura

Transformao PIMPIM

Restries

Guias

Arquitetura Sistema

Padres de Projetos

Prottipo Interface Grfica Tranformao PIM-PIM

Diagramas Backend

Diagramas Frontend

Transformao (PIM -PSM)

Modelo de Plataforma

Transformao (PIM-PSM)

Modelos Front-end PSM

Modelos Back-end PSM

Figura 3.16Transformao de modelos da fase Projetar Servios. Com todos os modelos do sistema devidamente refinados e atualizados feita a transformao dos modelos produzidos (PIM) at o momento para modelos especficos para as plataformas utilizadas (PSM). A Figura 3.17 mostra os modelos, meta-modelos e meta-metamodelos da fase Projetar Servios caso a plataforma escolhida para implementar todo o sistema fosse Java.

46

conforms To

MOF

conforms To UML2 MM

instace Of Modelos Front-end Modelos Back-end Arquitetura do Sistema

Figura 3.17Modelos da fase Projetar Servios Em Projetar Servios todos os modelos produzidos so modelos UML 2.0.

47

Captulo 4 - Instanciao e Execuo do Processo

4.1 Introduo
Para apresentar em detalhes todas as atividades e artefatos apresentados no captulo anterior, ser mostrada uma instanciao do processo com o objetivo de permitir um uso prtico e auxiliar os participantes no contexto do experimento. Tambm foram definidas guias e ferramentas para facilitar a construo dos artefatos e configurar um ambiente completo para execuo do processo. A seo 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 prximo capitulo. O QIB , basicamente, um sistema de internet banking com os casos de uso mostrados na Figura 4.1. Mais detalhes sobre o sistema podem ser encontrados em [30].

48

Consultar Saldo Consultar Extrato Realizar Transferncia

Consultar Carto Alterar Senha Efetuar Pagamento Carto Efetuar Login ClienteAtor

Operadora de Carto

Figura 4.1Casos de Uso do QIB. No sistema possvel realizar transferncias entre contas correntes, consultar saldo e extrato, gerenciar a conta do usurio (login e senha), consultar e efetuar pagamento do carto de crdito (Qualiti Card). Para simplificar o sistema e ajudar na construo dos artefatos, um cliente possui apenas uma conta corrente e um carto de crdito. As descries dos casos de uso so mostradas no Apndice B.

4.3 Especificar Modelo de Negcios

Conforme mostrado no captulo anterior, o primeiro workflow do processo Especificar Modelo de Negcios e seu principal objetivo gerar artefatos a fim de garantir o alinhamento entre os stakeholder. Para isso, so gerados os artefatos: Modelo de Informao do Negcio, Modelo de Funcionalidades, Modelo Navegacional e Prottipo de Interface Grfica. A partir da anlise da descrio de cada caso de uso possvel gerar o MIN com os principais termos (substantivos) mencionados; ao final, eles so unificados em um modelo nico, eliminando as duplicidades e redundncias (termos com nomes diferentes na descrio, mas que representam o mesmo conceito). No QIB foram identificados quatro conceitos que o sistema deve manipular (Conta, Cliente, PagamentoCarto e Comprovante), conforme ilustrado na Figura 4.2.

49

Figura 4.2Modelo de Informao de Negcio do QIB. Conforme mencionado no Captulo 3, o MF , basicamente, um modelo de casos de uso, agrupados em pacotes, com as funcionalidades (representados pelos casos de uso) e os usurios (representados pelos atores) da aplicao. Como ilustrado na Figura 4.3, a partir da descrio dos casos de uso do QIB (Anexo I) os casos de uso foram agrupados em trs pacotes distintos: Controle de Acesso (funcionalidades relacionadas ao acesso dos usurios ao sistema), Controle de Conta (relacionado a manipulao da conta bancria dos clientes) e Controle QualitCard (funcionalidades relacionadas ao Qualit Card).

50

Consultar Saldo Consultar Extrato Realizar Transferncia

Consultar Carto Alterar Senha Efetuar Pagamento Carto Efetuar Login ClienteAtor

Casos de Uso
Operadora de Carto

Controle Conta

Controle Qualit Card

Controle de Acesso

ClienteAtor

Operadora de Carto

Modelo de Funcionalidades Figura 4.3Modelo de Funcionalidades do QIB. O QIB um sistema simples e possui apenas quatro pginas principais (home, minha pgina, ajuda e contato. Em minha pgina ele poder acessar as opes de gerenciamento de conta corrente e carto. Para elaborar o Modelo Navegacional foi escolhido o sitemap, mais indicado para aplicaes web, conforme mostrado na Figura 4.4.

Figura 4.4Modelo Navegacional do QIB

51

Para construo do MN em aplicaes web recomenda-se o uso da ferramenta Axure RP [28]. Em aplicaes para dispositivos mveis recomenda-se o uso da ferramenta Netbeans (verso completa com o Visual Mobile Designer) [50]. Se a aplicao for simples at mesmo o PowerPoint ou o Visio pode ser utilizado para fazer o MN. Com o MN e MIN possvel construir o PIG que o primeiro prottipo 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.5Prottipo de Interface Grfica do QIB da tela login. Para construo do PIG aconselhasse fortemente o uso de ferramentas de prototipao como o Axure RP [28].

4.4 Analisar Servios

O prximo workflow do processo Analisar Servios que tem como objetivo gerar a primeira arquitetura do sistema. Para isso, so construdos os artefatos: Arquitetura de Servios, Modelo de Interao de Servios, Modelo de Componentes dos Servios e o Modelo de Informao Refinado. Para construir a Arquitetura de Servio necessrio 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 Carto e Efetuar Pagamento Carto no pacote Controle QualitCard, e os demais em Controle Conta.

52

Controle Conta

Controle Qualit Card

Controle de Acesso

ClienteAtor

Operadora de Carto

Modelo de Funcionalidades

<<Service Contract>> ControleAcesso consumer <<participant>> Cliente Front-end <<Service Contractt>> ControleConta consumer provider consumer

<<Service Contract>> OperadoraCartao provider <<participant>> Operadora Carto

provider

<<participant>> Sistema back-end

consumer

consumer <<Service Contract>> ControleQualitiCard

Arquitetura de Servios Figura 4.6Passo a passo para elaborao da Arquitetura de Servios do QIB. Depois, o ator cliente foi mapeado no participante Cliente Front-end e o ator Operadora de Carto no participante Operadora Carto. O relacionamento com o ator Operadora de Carto foi mapeado no contrato de servio OperadoraCarto, conforme indicado pela seta continua na Figura 4.6. Os pacotes de casos de uso foram mapeados nos contratos de servios ControleAcesso, ControleConta e ControleQualitiCard. O participante Sistema Back-End surge para prover servios ao Cliente Font-end e consumir de Operadora Carto. O segundo artefato a ser gerado em Analisar Servios o Modelo de Interao dos Servios (MIS). Conforme mencionado anteriormente, para construir o MIS

53

necessrio identificar os servios de entidades, um tipo de servio que derivado de uma ou mais entidades de negcio relacionadas e possuem alto grau de reutilizao: servios que fazem operaes CRUD (Create, Read, Update, Delete), por exemplo. As Figuras 4.7 e 4.8 mostram os servios de entidades e um dos MIS do QIB.
<<Service Contract>> ContaInternet <<Service Contract>> ContaBancaria <<Service Contract>> Transao

Figura 4.7Servios de Entidade do QIB.

: Cliente Front-end

: IControleAcesso

: IContaInternet

logar(login,senha)

existe(login, senha) ContaInternet

sesso alterar(login,antiga, nova)

existe(login,senha) ContaInternet atualizar(ContaInternet) sesso Conta Internet

Figura 4.8Modelo de Interao de Servio do QIB. Conforme as regras descritas no captulo anterior, o MIS relacionado ao contrato de servio ControleAcesso, mostrado na Figura 4.8, contm as interfaces

IControleAcesso, IContaInternet e o consumidor Client Front-end. As mensagens entre os elementos foram adicionadas de acordo com a descrio dos casos de uso relacionados ao contrato de servio Controle Acesso (Efetuar Login e Alterar Senha descritos no Apndice B).

54

Aps a construo dos modelos de interao dos servios foi verificado que a entidade PagamentoCarto era na verdade uma Transao e surgiram os atributos das entidades, por isso, o MIN foi atualizado. A Figura 4.9 mostra o MIN atualizado.
ContaBancaria +numero +saldo ContaintInternet +login +senha Transacao +numero da fatura +data +valor +numero da conta

Figura 4.9MIN Refinado do QIB. O ltimo artefato a ser gerado o Modelo de Componentes dos Servios (MCS). A Figura 4.10 mostra o MCS do QIB.
<<Front-end>> Cliente Front-end

IControleAcesso

IControleConta Controle Conta

IControleQualitCard Controle QualitCard

Controle de Acesso

IOperadoraCarto IContaInternet ContaInternet IContaBancaria ContaBancaria ITransao Transao OperadoraCarto

Figura 4.10Modelo de Componentes dos Servios do QIB. Como se pode observar na Figura 4.10, o MCS foi construdo sistematicamente seguindo as regras mostradas no captulo 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 servios da AS do sistema (ControleAcesso, ControleConta, ControleQualitiCard e OperadoraCarto - Figura 4.6) foram transformados em componentes (ControleAcesso, ControleConta e

55

ControleQualitiCard - Figura 4.6) e suas interfaces (IControleAcesso, IControleConta e IControleQualitiCard e Figura 4.10). 3. os servios de entidades (ContaInternet, ContaBancaria, Transao na Figura 4.7) foram transformados em componentes (ContaInternet, ContaBancaria e Transao Figura 4.10) e suas interfaces (IContaInternet, IContaBancaria e ITransacao Figura 4.10). 4. O participante OperadotaCarto (Figura 4.6) foi transformado no componente OperadoraCarto (Figura 4.10) e sua interface IOperadoraCarto (Figura 4.10) foi gerada a partir do contratado de servio OperadoraCarto (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 esteretipos, tambm 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 Servios

No comeo da fase Projetar Servios feita a reviso e o refinamento dos modelos gerados na fase anterior e depois elaborada a Arquitetura do Sistema. Para isso recomendado responder as seguintes questes: Empacotamento das funcionalidades foi feito de forma correta? As funcionalidades isoladas poderiam fazer parte de algum contrato de servio existente?

4 5 6 7 8

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

56

Resposta: Todos os casos de uso foram empacotados seguindo critrios de coeso e acoplamento e, pelo sistema ser simples, nenhuma funcionalidade ficou isolada. Todos os componentes de front-end foram identificados? Resposta: No. Por isso, foram identificados trs novos componentes que representam as aplicaes Front-end do sistema (mobile, web e desktop). Podemos agrupar contratos de servios semelhantes? Resposta: No. Todos os servios identificados possuem granularidade fina. Todas as funcionalidades foram contempladas? Resposta: Sim. Todos os casos de uso foram realizados. Como ser a integrao entre o front-end e back-end? Como ser feita a comunicao com sistemas externos? Resposta: A integrao ser feita utilizando web services. possvel reutilizar ou comprar componentes existentes? Resposta: No. Todos os componentes sero implementados devido a restrio do cliente. Portanto, a Figura 4.11 mostra a Arquitetura do Sistema do QIB levando-se em considerao as questes acima.

57

Front-end Web

Front-end Iphone

Front-end Desktop

IFachadaWebSercice WebService

IControleAcesso

IControleConta Controle Conta

IControleQualitCard Controle QualitCard

Controle de Acesso

IContaInternet

IContaBancaria ContaBancaria

ITransao Transao

IOperadoraCarto OperadoraCarto

ContaInternet

Figura 4.11Arquitetura do Sistema. Para construir a arquitetura foram levadas em considerao as seguintes definies: 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 mveis em iPhone. Integrao front-end e back-end: a comunicao ser implementada utilizando web services [7]. Padres de arquitetura: O sistema back-end seguir o padro N-Tier [33] e o font-end iPhone e desktop o padro MVC [34]. Padres de projetos: O componente OperadoraCarto utilizar o padro Observer para chamadas assncronas ao sistema de carto de crdito. Alm disso, todos os componentes devero utilizar o padro singleton e facade.

58

Aps a construo da Arquitetura do Sistema e a descrio dos padres a serem utilizados, so elaborados os diagramas de classes e sequncia 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 sequncia para a operao EfetuarLogin.
ControladorControleAcesso +logar(login, senha) +alterarSenha(login, senhaAtual, SenhaNova) IControleAcesso +logar(login, senha) +alterarSenha(login, senhaAtual, SenhaNova) ContaintInternet +login +senha

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

Figura 4.12Diagrama de classes do componente ControleAcesso.

: FachadaWebservice

: IControleAcesso

: IContaInternet

1 : logar()

2 : existe()

4 : session

3 : true

Figura 4.13Diagrama de Seqncia de Efetuar Login. Por fim, so construdos os diagramas de seqncia e de classe baseando-se no Prottipo da Interface Grfica. A Figura 4.14 ilustra a construo das classes da

59

interface grfica do sistema. Os diagramas de classe e sequncia, simplificado, do front-end desktop do QIB so mostrados na Figura 4.15.

Figura 4.14Construo da Interface Grfica Desktop do QIB.

ComunicacaoWebService +logar() +chamarWebService()

TelaLogin +loginText: TextField +senhatext: TextField +logarButton: JButton +efeturarLoginr()

IComunicacaoWebService

: TelaLogin : ClienteAtor 1 : efeturarLogin()

: ComunicacaoWebService

2 : logar() 3 : chamarWebService()

Figura 4.15Diagrama de Classe e seqncia do Desktop.

60

Captulo 5 - Avaliao do Processo

5.1 Introduo
No Captulo 3 foi apresentado um processo de projeto arquitetural de software orientado a modelo e baseado em SOA, portanto, uma anlise deve ser feita para compreender e avaliar se o processo proposto atinge seus objetivos. Neste contexto, este captulo apresentada um experimento para avaliar o novo processo proposto levando-se em considerao alguns critrios de desenvolvimentos de software como: modularidade, complexidade, estabilidade, facilidade de utilizao e entendimento. Esta seo 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 (definio, planejamento, coleta de dados e interpretao) que orientam o experimento, estabelecendo o objetivo do estudo, as perguntas a serem respondidas, e as mtricas utilizadas para interpretar as respostas. Informaes mais detalhadas sobre experimentao na rea de engenharia de software pode ser encontrada em [37].

5.2 Definio
Na fase de definio so definidos os objetivos do experimento, as questes a serem respondidas e as mtricas relacionadas que devem ser

colhidas para ajudar a responder as questes. Alm 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 eficincia 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 questes qualitativas e mtricas. As mtricas so mais eficazes quando associadas a alguma estrutura de medio, facilitando a compreenso do relacionamento entre as questes, mtricas e

61

a interpretao dos dados que sero coletados [38]. Por isso, este trabalho utilizou um framework de medio baseado nas mtricas definidas e refinadas em [22]. A Figura 5.1 mostra o framework de medio utilizado.

Framework de Medio

Varivel de resposta

Qualidade de Projeto

Qualidades

Reusabilidade

Manutenibilidade

Fatores

Complexidade

Compreensibilidade

Modularidade

Estabilidade

Atributos

Tamanho

Acoplamento

Instabilidade

Mtricas

WOCS

CBCS

IMSC

Figura 5.1Framework de medio. As questes e as mtricas utilizadas so apresentadas a seguir:

62

Questo 1: O processo de desenvolvimento gera servios e componentes de baixa complexidade? Dependncias estruturais entre os servios e componentes

(relaes cliente-consumidor) tm influncia considervel sobre a complexidade dos sistemas. Por isso, a mtrica a seguir foi utilizada para ajudar a responder a questo 1: Mtrica 1 (M1): Weighted Operations per Component or Service (WOCS). Mtrica utilizada para medir a complexidade de componentes e servios utilizada em [22]. A quantidade e complexidades das operaes de um componente ou servio so diretamente relacionadas ao tempo e esforo necessrios para desenvolv-los e mant-los. Assim, as WOCS medem a complexidade do servio ou componente, em termos de suas

operaes (mtodos) que sero utilizados por outros servios ou componentes. Considere um componente (ou servio) C com operaes O1,...,On. Onde c1,..., cn so as complexidades das operaes. Ento:

Esta mtrica indica que operaes com muitos parmetros formais so mais complexas do que operaes que exigem menos parmetros. Neste sentido, a complexidade da operao On pode ser definida da seguinte forma: cn = + 1, onde denota o nmero de parmetros formais de On. De acordo com [39], valores at 10 so considerados aceitveis para aplicao simples.

Questo 2. O processo de desenvolvimento gera servios e componentes estveis? Uma nica mudana pode encadear mudanas em cascata nos componentes e servios de uma aplicao. Tornando a arquitetura frgil, dificultando o

desenvolvimento e o reuso. Por isso, a mtrica a seguir foi utilizada para ajudar a responder a questo 2:

63

Mtrica 2 (M2): Instability Metric for Service or Component (IMSC). O IMSC uma mtrica para medir a instabilidade dos componentes ou servios de uma aplicao baseada no fan.in e fan.out. O fan.in de uma funo A o nmero de funes que chamam a funo A. O fan.out de uma funo A o nmero de funes que a funo A chama. Ou seja, as funes com um fan.out alto so mais difceis de manter. E funes com fan.in grande so bastante utilizadas. O fan-in e fan.out so mtricas utilizadas para estimar a complexidade de manuteno de softwares [40]. Baseado nestas mtricas, Perepletchikov definiu uma nova mtrica para medir a interao entre um servio ou componente por meio do envio e recebimento de mensagens [41]. Ele definiu que o fan.in de um servio S o nmero de mensagens que S recebe. E fan.out o nmero de mensagens que ele envia. Com isso, ele propos a seguinte formula:

De acordo com [41] quanto mais prximo de 0, mais estvel o servio. Se o IMSC = 1, o servio muito instvel e difcil de manter.

Questo 3: O processo de desenvolvimento gera servios e componentes com baixo grau de acoplamento? O baixo grau de acoplamento entre os componentes e servios de uma aplicao indica uma arquitetura modular. Aplicaes modulares potencializam benefcios em vrios aspectos: velocidade no desenvolvimento, reduo de custo no

desenvolvimento, flexibilidade e reusabilidade. Por isso, a mtrica 3 foi utilizada para ajudar a responder a questo acima: Mtrica 3 (M3): Coupling Between Components or Services (CBCS). Esta mtrica calculada baseando-se no nmero de relacionamentos dos componentes ou servios:

64

Seja n o nmero de servios da aplicao, ento est conectado ao servio , caso contrrio

se o servio . Para um servio A

no

quanto maior o CBCS, maior o acoplamento com outros servios. Est mtrica foi utilizada em [22]. Valores maiores que seis indicam alto grau de acoplamento [41]. Questo 4: Os participantes tiveram dificuldade em entender e aplicar o processo? A fim de compreender as dificuldades que os participantes iro enfrentar durante a adoo do novo processo, eles sero solicitados a informar as dificuldades enfrentadas ao final da fase de execuo. Para ajudar a responder a esta questo, a mtrica a seguir foi definida: Mtrica 4 (M4): Dificuldade em utilizar o processo: Porcentagem dos participantes que acharam o processo difcil. Mtrica que mede a dificuldade de aplicao e entendimento do processo. Esta mtrica foi baseada na avaliao do processo proposto no trabalho [9].

Questo 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 mtrica 5: Mtrica 5 (M5). Alinhamento entre os stakeholders: Porcentagem dos participantes que concordaram que o processo ajuda no alinhamento de entendimento entre os stakeholders.

Questo 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 aplicaes foi criada a mtrica 6:

65

M6.

Desacoplamento

entre

front-end

back-end:

Porcentagem

dos

participantes que concordaram que o processo ajuda no desacoplamento entre front-end e back-end.

As mtricas M1, M2 e M3 tambm fazem parte do framework de mtricas utilizado em [22]. A M4 foi baseada em [9]. M5 e M6 foram baseadas em experincia prtica, senso comum e definidas especificamente para avaliao deste trabalho.

5.3 Planejamento
O experimento foi conduzido na disciplina Anlise e Projeto de Sistemas do Centro de Informtica da UFPE9 no segundo semestre de 2010 (agosto at dezembro). Foi um experimento off-line (no foi aplicado na indstria) e todos os participantes eram graduandos dos cursos de Cincia da Computao e Engenharia da Computao a partir do sexto perodo. Para coletar as mtricas quantitativas (M1, M2 e M3) foram utilizados as seguintes ferramentas de modelagem: StarUML10, Rational Software Architect11 e JUDE12. Para coletar as mtricas qualitativas (M4, M5 e M6) foi utilizado o questionrio de perguntas e resposta mostrado no Apndice A. A avaliao do experimento foi feita baseando-se nas seguintes hipteses: Hipteses nulas. As hipteses nulas (H0) so 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

Pgina da disciplina: www.cin.ufpe.br/~if678 Ferramenta StarUML: http://staruml.sourceforge.net/ RSA: http://www.ibm.com/developerworks/rational/products/rsa/ JUDE: http://jude.change-vision.com/jude-web/product/community.html

10 11 12

66

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

Hipteses alternativas. As hipteses alternativas (H1) so as hipteses contrrias s hipteses 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 hipteses referentes s mtricas 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 mnimo um grupo com trs integrantes. Validade externa: a validade externa define as condies 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 domnios. Validade de concluso: a validade de concluso relacionada habilidade do experimento em chegar a uma concluso. Neste caso, o experimento feito vlido, pois pode se chegar s concluses desejadas atravs de uma anlise matemtica simples que ser mostrado na prxima seo. Por fim, as seguintes ameaas validade do experimento foram identificadas e tratadas:

67

Motivao dos participantes. Os participantes poderiam escolher os seus grupos e, em se tratando de alunos de graduao, poderia ser o caso de nem todos participarem efetivamente do projeto. Para tratar essa ameaa, todos os alunos tinham que apresentar e participar ativamente na apresentao dos projetos sob pena de perder pontos na nota final da disciplina.

Experincia dos participantes. Os resultados podem ser influenciados pela falta de conhecimento e experincia prtica dos participantes, pois todos eram alunos de graduao e a maioria no tinha experincia profissional no desenvolvimento de software. Para contornar essa ameaa foram ministradas aulas prticas para auxiliar e treinar os participantes no desenvolvimento dos projetos.

Complexidade e formato dos projetos. Os projetos foram propostos pelos participantes e no chegaram a ser implementados. Isso pode influenciar negativamente as mtricas M1,M2 e M3. Para mitigar essa ameaa foram definidos requisitos mnimos (nmero de casos de uso, interao com sistemas externos, por exemplo) para a elaborao dos projetos.

5.4 Operao
Os alunos tiveram aulas introdutrias sobre o RUP (processo normalmente ensinado na disciplina) e o processo apresentado neste trabalho. Depois das aulas introdutrias, os alunos se dividiram em grupos com at quatro integrantes e tiveram a opo de desenvolver seus projetos utilizando o RUP ou o processo SOA/MDE aqui proposto. Os projetos foram sugeridos pelos prprios alunos e foram avaliados para verificar se tinham um grau de complexidade mnimo requerido para disciplina. Cinco grupos13 escolheram utilizar o processo SOA/MDE, totalizando 19 alunos participantes do experimento. A Tabela 5.1 mostra as informaes de cada grupo.

13

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

68

Projetos Projeto 1 Projeto 2 Projeto 3 Projeto 4 Projeto 5 Total

Componentes analisados 11 14 10 6 10 51
Tabela 5.1. Dados dos Projetos.

Participantes 4 4 4 4 3 19

Aps a diviso das equipes foram ministradas 24 horas de aulas prticas e tericas14 (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 construdos (arquivos de ferramentas CASE) no projeto. No final da disciplina foi aplicado um formulrio de avaliao sobre o processo15.

5.5 Coleta e Anlise dos Dados

Com os modelos gerados pelas equipes foi possvel coletar e calcular manualmente, atravs das ferramentas CASE utilizadas, as mtricas WOCS, CBCS e ISMC. Com as respostas do questionrio foi possvel coletar as demais mtricas. A Tabela 5.2 mostra os resultados obtidos, levando-se em considerao a modularidade (CBCS) dos projetos.

14 15

Cronograma das aulas: www.cin.ufpe.br/~if718/proj2010-2.html Questionrio: http://www.cin.ufpe.br/~vtb/experimento/Formulario.docx

69

Projetos mdia Projeto 1 Projeto 2 Projeto 3 Projeto 4 Projeto 5 Total Resultado: 2,46 2,57 3,3 2,83 2,3 2,69

CBCS min 1 1 1 2 1 1 max 5 9 6 4 4 9 (rejeitada)

H0: CBCS > 6

Tabela 5.2. Resultados da mtrica CBCS.

A anlise estatstica dos dados mostra que a mdia CBCS (2,69) rejeitou fortemente a hiptese nula. Isto indica que o processo colabora para o desenvolvimento de componentes e servios com baixo acoplamento, pois valores abaixo de 6 so considerados aceitveis para aplicaes simples [22]. Outro ponto importante que nenhum projeto apresentou mdia CBCS prxima de 6 (mxima foi 3,3). A Tabela 5.3 mostra os resultados obtidos para a mtrica de complexidade (WOCS). Projetos mdia Projeto 1 Projeto 2 Projeto 3 Projeto 4 Projeto 5 Total 6,73 10,57 8,9 9,17 10,2 9,12 WOCS min 2 3 1 3 3 1 max 28 44 14 22 16 44

Resultado: H0: WOCS >= 10 (rejeitada)

Tabela 5.3. Resultados da mtrica WOCS.

Como podemos observar na Tabela 5.3, a mdia WOCS foi de 9,12 (valores at 10 so aceitveis para aplicaes simples [22]) e rejeitou a hiptese nula, mostrando que

70

o processo contribui significantemente para a reduo da complexidade dos componentes e servios desenvolvidos. A Tabela 5.4 mostra os resultados obtidos, levando-se em considerao a instabilidade dos componentes e servios projetados. Projetos mdia Projeto 1 Projeto 2 Projeto 3 Projeto 4 Projeto 5 Total 0,25 0,38 0,37 0,44 0,25 0,34 IMSC min 0 0 0 0 0 0 max 0,8 0,66 0,8 0,66 0,57 0,8

Resultado: H0: IMSC >= 0,5 (rejeitada)

Tabela 5.4. Resultados da mtrica IMSC.

A anlise dos dados da Tabela 5.4 mostra que a mdia IMSC foi 0,34 e rejeitou fortemente a hiptese nula. Isto um forte indcio que o processo colabora para o desenvolvimento de componentes e servios estveis, pois valores mais prximos de zero indicam estabilidade alta. Outro ponto importante que nenhum projeto apresentou mdia IMSC prxima de 1 (mxima foi 0,44). Os grficos das Figuras 5.2, 5.3 e 5.4 mostram os resultados obtidos com o questionrio de avaliao do processo.

Figura 5.2 - Grfico de avaliao da dificuldade do processo.

71

Os dados da Figura 5.2 apontam que o processo de desenvolvimento no difcil, apenas 14% acharam o processo difcil, rejeitando a hiptese nula H0d ( Dificuldade em utilizar o processo >=30 %).

Figura 5.3 - Grfico da avaliao do alinhamento entre os stakeholders. O grfico da Figura 5.3 mostra que 100% dos participantes concordaram que o processo ajuda no alinhamento entre os stakeholders, rejeitando fortemente a hiptese nula H0e (Alinhamento entre os stakeholders <=70 %).

Figura 5.4 - Avaliao do desacoplamento entre front-end e back-end. A anlise do grfico 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 hiptese nula H0f ( Desacoplamento entre frontend e back-end <= 70%).

72

Portanto, os dados obtidos no experimento indicam que o processo cumpre com seus principais objetivos, alm de colaborar para o desenvolvimento de uma arquitetura com servios e componentes estveis, com baixo grau de acoplamento e complexidade. Apesar da maioria dos participantes no ter experincia em projetos reais (90% nunca tinham participado de projetos envolvendo clientes reais) todos os projetos apresentaram servios com granularidade fina e sem problemas graves na arquitetura. Um fato interessante que apesar das limitaes 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 questionrio que tinham interesse em aprender mais sobre o processo em outra disciplina. Outro fato interessante que com a resposta dos questionrios os participantes sugeriram mais detalhes e guias para as atividades do workflow Projetar Servios. Com essas respostas foi possvel identificar as deficincias e melhorar os detalhes das atividades do processo.

5.6 Lies Aprendidas

Como lies aprendidas no experimento pode-se destacar: Simplicidade e facilidade de uso do Processo: A maioria dos participantes concordou que, no geral, o processo fcil (27%) ou razovel (59%) e apenas 14% considerou o processo difcil e nenhum muito difcil de aplicar. Avaliao da produtividade e qualidade das aplicaes: No estudo experimental, os participantes no chegaram a codificar os projetos propostos, apenas produziram os modelos. Com isso, no foi possvel avaliar a produtividade e mtricas de qualidade como Lack of Cohesion over Operations (LCOO), Cyclomatic Complexity (CC) e Concern Diffusion over Components or Services (CDCS) [22]. Alm disso, a mdia de WOCS foi alta (9,12), indicando uma complexidade considervel para os componentes modelados.

73

Dificuldades na fase Projetar Servios: 32% dos participantes do experimento acharam a fase Projetar Servio difcil e 36% tiveram dificuldade em produzir os artefatos. Estes dados indicam que a fase pode estar complexa e ou o material de treinamento no foi adequado.

Comparao com outras abordagens: Para melhorar a avaliao do processo, os participantes poderiam ter sido expostos aos dois processos e ao final poderia ter sido feita uma anlise mais completa com a comparao dos resultados. Tambm poderiam ter sido expostos a outros processos SOA/MDD e no o RUP. Isso no foi feito devido s restries de tempo e escopo da disciplina.

Avaliao da mtrica 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 questionrio e das mtricas M4: A mtrica M4 altamente dependente da experincia dos participantes do experimento e do tamanho do projeto das equipes, por isso os resultados obtidos possuem pouco valor para se tecer anlises que o generalizem.

74

Captulo 6 - Concluso

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 servios a fim de possibilitar o projeto de arquiteturas estveis, flexveis e modulares. Para isso, o processo foi dividido em trs conjuntos de atividades distintos: Especificar Modelo de Negcio, Analisar Servios e Projetar Servios. Em Especificar Modelo de Negcio so gerados artefatos que ajudam no alinhamento das expectativas entre os stakeholders. Analisar Servios define atividades para projetar a arquitetura do sistema independente de plataforma de desenvolvimento. Em Projetar Servios so definidas atividades para refinar os modelos produzidos nas atividades anteriores e transform-los em modelos menos abstratos e projetados para executar em plataformas especficas. Para avaliar aspectos quantitativos e qualitativos do processo, foram apresentadas em detalhes as fases do estudo experimental executado em uma disciplina de graduao do Centro de Informtica da UFPE.

6.1 Principais contribuies

O processo sistemtico, fcil de usar e compreender, independente de ferramentas e tecnologias, e foi capaz de resolver problemas prticos como: a integrao de aplicaes, o acoplamento entre front-end e back-end dos sistemas, e o desalinhamento de expectativas entre os stakeholders. Como principais contribuies deste trabalho, podemos destacar: 1. Definio de um processo sistemtico para projeto arquitetural de software dirigido a modelos e orientado a servios, proporcionando:

75

Aumento na reutilizao de software: Nas primeiras fases do processo possvel identificar oportunidades de reuso. Como forte indcio para comprovar o aumento no reuso, em todos os projetos do experimento foram identificados um ou mais servios com alto grau de reutilizao (servios utilitrios).

Projeto de arquiteturas modulares e estveis: Seguindo as atividades do projeto possvel projetar uma arquitetura modular e com componentes desacoplados. Como forte indcio para comprovar isso, a mdia CBCS nos projetos foi 2,69 (indica baixo grau de acoplamento entre os componentes) e a mdia IMSC foi 0,34 (indica estabilidade).

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 questionrio concordando que o processo contribui para o alinhamento do entendimento entre todos os stakeholders.

Praticidade e facilidade de uso: A maioria dos participantes concordou que, no geral, o processo fcil (27%) ou razovel (59%) e apenas 14% considerou o processo difcil. Alm disso, o processo

utiliza conceitos, fundamentos, artefatos e modelos bastante utilizados tanto na indstria como na academia. o Avaliao atravs de um estudo experimental. O processo foi avaliado em um estudo experimental envolvendo 19 alunos de graduao da UFPE e executado em cinco projetos distintos.

6.2 Trabalhos Relacionados

Devido a grandes esforos na pesquisa e aplicao de MDD e SOA nos ltimos anos, alguns trabalhos tambm 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 servio para a construo de sistemas de informaes. Na abordagem apresentada, os modelos de composio de

76

web services so construdos a partir de modelos de negcios de alto nvel, facilitando o alinhamento dos processos comerciais de alto nvel com as tecnologias disponveis, seguindo o paradigma SOC (Service Oriented Computing). Marzullo et al. [68] apresentou uma metodologia para construo de prottipos de arquitetura com o objetivo de acelerar o processo de desenvolvimento de software. A arquitetura construda 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 mudanas no ambiente de negcios. O estudo de caso apresentado foi baseado em um projeto real reaizado no NALIM (Ncleo de Apoio Logstico Integrado da Marinha). Em [70] apresentado uma abordagem de desenvolvimento orientada a modelos para construo de servios de telecomunicaes para dispositivos mveis. Nesse trabalho foi desenvolvido um profile UML para construo das aplicaes portveis para diversas plataformas. Em [71] mostrado o MINERVA, um framework dirigido a modelos e orientado a servios para melhoria continua de processos de negcio. O framework foi definido em trs dimenses: conceitual, metodolgica e suporte ferramental. O trabalho mostra que utilizando o framework possvel obter automaticamente os modelos de servios (modelos SoaML) a partir de modelos de negcios (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 transformaes dos modelos dos servios. Em [73] apresentado o SOSA, uma abordagem orientada a modelos para projetar arquitetura de software orientada a servios independente de plataforma (no nvel do PIM). A abordagem faz parte da metodologia MIDAS [24], um framework para o

desenvolvimento de sistemas de informao baseado em MDA. A fim de obter uma melhor compreenso quanto s vantagens e limitaes expostas neste trabalho, foi realizada uma anlise comparativa do processo proposto e dos trabalhos relacionados mencionados anteriormente. A Tabela 6.1 mostra o resultado dessa anlise.

77

Preciso do Processo A Study Case on Domain-Driven Development, Using MDA, SOA and Web Services [68] SOD-M [69] Realizing an MDA and SOA Marriage for the Development of Mobile Services [70] Minerva [71] A Model-Driven Approach to Weave Architectural Styles into ServiceOriented Architectures [67] SOSA [73] O processo proposto no trabalho

Cobertura do ciclo de vida genrico

Domnio restrito

Arquitetura Independente Suporte a vinculada s de ferramentas decices transformaes e tecnologias arquiteturais

baixa alta mdio baixa mdio alta alta

no sim no no no sim no

no sim no sim sim no no

sim no sim sim sim sim no

no sim no no no no sim

no sim no sim no no sim

Tabela 6.1. Resultados da anlise.

A anlise mostrada na Tabela 6.1 foi feita de acordo com os critrios apresentados em [74], adicionando as limitaes e deficincias encontradas em algumas metodologias mostradas na introduo: Preciso do processo: se o processo detalho o suficiente para ser efetivamente seguido pelas pessoas envolvidas no projeto. Cobertura do ciclo de vida genrico: a metodologia abrange as fases e atividades do clico genrico de desenvolvimento de software. Domnio restrito: o escopo dos projetos e domnios para os quais a metodologia aplicvel. Algumas metodologias propostas no so de uso geral o suficiente ou no foram avaliada em vrios domnios ( o caso do processo proposto). Arquitetura vinculada s transformaes: se a arquitetura final do sistema atrelada s transformaes automticas 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 especfica (web services, por exemplo). Suporte a decises arquiteturais: se o processo fornece suporte a importantes decises arquiteturais ou delega essas decises aos

programadores ou ferramentas de automao.

78

6.3 Limitaes e Trabalhos Futuros

O processo foi concebido para ser sistemtico e significativamente automatizado, mas no foi possvel avaliar essas caractersticas. Estes pontos sero abordados em trabalhos futuros. A idia definir regras formais de transformaes de modelos e programar essas regras em ferramenta CASE ou plugins para ferramentas existentes, a fim de facilitar, automatizar e gerenciar a criao e atualizao dos modelos gerados pelo processo. Como outro trabalho futuro pretende-se utilizar mtodos formais para descrever as interfaces dos componentes e os contratos de servios, servindo de base para garantir a consistncia e preservao 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 avaliao mais efetiva do processo, seria necessrio um estudo experimental mais abrangente executado em um projeto na indstria com clientes reais. Com isso, seria possvel validar corretamente as mtricas qualitativas (facilidade de uso e alinhamento entre os stakeholders) e avaliar atributos de produtividade (esforo, custo e velocidade de execuo).

6.4 Consideraes Finais

Embora existam esforos na pesquisa e aplicao de MDD e SOA, ter investigado os problemas, suas complementaridades e vantagens do uso em conjunto das duas abordagens na prtica foi muito interessante. Alm disso, a
utilizao das duas abordagens em conjunto se mostrou adequada, pois com MDD foi possvel comear a projetar os sistemas em um alto nvel de abstrao. Com SOA foi possvel guiar o projeto em um nvel menos abstrato e independente de tecnologia, incentivando e favorecendo o reuso A operao do estudo experimental em uma disciplina da graduao do Centro de Informtica da UFPE foi um grande e trabalhoso desafio, mas no final se mostrou essencial, pois foi possvel aperfeioar todas as atividades do processo, melhorar a

79

descrio das regras de transformao e detalhar os artefatos gerados nas atividades. Alm disso, o processo foi testado em cinco projetos diferentes.

80

Bibliografia

1. The Standish Group. Disponvel em http://www.standishgroup.com/, maro 2011. 2. CHAOS Summary 2009. Disponvel 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. Disponvel em http://msdn.microsoft.com/pt-br/library/bb447667(en-us).aspx, maro 2011. 5. Proof-of-Concept Design. Disponvel em us/library/cc168618.aspx, maro 2011. http://msdn.microsoft.com/en-

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. Disponvel em http://en.wikipedia.org/wiki/Frontend_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, So Carlos, So Paulo.

81

15. L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, second ed. Addison-Wesley, 2003. 16. B. Hailpern and P. Tarr, Model-Driven Development: The Good, the Bad, and the Ugly, IBM Systems J., vol. 45, pp. 451-461, 2006. 17. P. Baker, L. Shiou, and F. Weil, Model-Driven Engineering in a Large Industrial ContextMotorola Case Study, Proc. Eighth Intl Conf. Model Driven Eng. Languages and Systems, pp. 476-491, 2005. 18. Staron, M. Adopting Model Driven Software Development in IndustryA Case Study at Two Companies. Ninth Intl 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 Gonalves; ALVES, V.; Garcia, C. Vinicius; lvaro, Alexandre ; Lucrdio, Daniel; Almeida, S. Eduardo; Meira, L. R. Silvio. An Assessment on Technologies for Implementing Core Assets in ServiceOriented Product Lines. In: IV Simpsio Brasileiro de Componentes, Arquiteturas e Reutilizao 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. Pivi Parviainen, Juha Takalo, Susanna Teppola & Maarit Tihinen. ModelDriven 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. Disponvel 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, UML2000, York, England, October 2000. 27. Wireframe. Disponvel em http://en.wikipedia.org/wiki/Website_wireframe, maro 2011.

82

28. AxureSample Projects. Disponvel http://www.axure.com/sampleProjects.aspx, maro 2011.

em

29. Service oriented architecture Modeling Language (SoaML). Disponvel http://www.omg.org/spec/SoaML/1.0/Beta2/PDF, maro 2011. 30. Luiz Francisco Lacerda Jr.. Um profile UML 2 e um processo de modelagem para engenharia de interfaces grficas dirigida a modelos e baseada em componentes. 2005. Dissertao de Mestrado Universidade Federal de Pernambuco. 31. NHibernate for .NeT. Disponivel http://community.jboss.org/wiki/NHibernateforNET, maro 2011. 32. Java Persistebce API. Disponivel http://pt.wikipedia.org/wiki/Java_Persistence_API, maro 2011. 33. Building an N-Tier Application in .NET. Disponivel http://msdn.microsoft.com/en-us/library/ms973279.aspx, maro 2011. 34. MVC. Disponivel em http://pt.wikipedia.org/wiki/MVC, maro 2011. 35. Model Driven SOA. Disponivel http://searchsoa.techtarget.com/tip/Model-driven-SOA, maro 2011. 36. Wireframe completo do QIB. http://www.cin.ufpe.br/~vtb/qib/pig, maio 2011. Disponvel em em em em em

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. Santanna, 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 329340, Washington, DC, USA. IEEE Computer Society Press. 42. Mahmood, Z. The Promise and Limitations of Service Oriented Architecture. INTERNATIONAL JOURNAL OF COMPUTERS, Issue 3, Volume 1, 2007.

83

43. D. Overall, Have we been there before?, Opinions, Computer Weekly, UK, 11 April 2006. 44. M. Fowler, Patterns of enterprise application architecture, Addison Wesley, 2002. 45. Recommended Practice for Architectural Description of Software-Intensive Systems; ANSI/IEEE Std 1471-2000. 46. Thomas, E. Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall, 2005. 47. Machado, Joo. Um estudo sobre o desenvolvimento orientado a servios. Rio de Janeiro, 2004. 89p. Dissertao de Mestrado - Departamento de Informtica, Pontifcia Universidade Catlica do Rio de Janeiro. 48. Derek Miers, Stephen A. White. BPMN Modeling and Reference Guide. Future Strategies Inc., Agosto 2008 49. OpenUp. Disponvel 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. Disponvel 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. Lucrdio, Daniel. Uma abordagem orientada a modelos para reutilizao de software, Tese de Doutorado, Universidade de So Paulo, USP, Brasil, 2009. 55. MOF.The Meta-Object Facility. Disponvel em http://www.omg.org/mof/, julho 2011. 56. Arquitetura Orientada a Servios SOA Infraestrutura para a Inovao. Disponvel em http://www.scribd.com/doc/46068179/Introducao-Ao-SOA31574, 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. 7592, 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. 3342.

84

60. Soley, R. (2000, 11 27). Model Driven Architecture. Retrieved from Object Management Group: http://www.omg.org/mda 61. ORMSC, A. B. (2001, 07 09). Model Driven Architecture - A Technical Perspective. Retrieved from Object Management Group: http://www.omg.org/mda 62. Agile Modeling: User Interface Flow. Disponvel em http://www.agilemodeling.com/artifacts/uiFlowDiagram.htm, julho 2011. 63. Alvaro, Alexandre. Software component certification: a component quality model. Recife, 2005. 124p. Dissertao de Mestrado Centro de Informtica, Universidade Federal de Pernambuco. 64. J. Sametinger, Software Engineering with Reusable Components, SpringerVerlag, 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 Atualizao em Informtica (JAI), 2004 67. Lpez-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 ServiceOriented 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., Garca-Rodrguez de Guzmn, 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 (WESOA09),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. Lpez-Sanz, M.; Acua, C,J..; Cuesta, C.;Marcos, E.: Defining ServiceOriented Software Architecture Models for a MDA-based Development Process at the PIM level Proceeding WICSA '08 Proceedings of the Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008).

85

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

86

Apndice A

PARTE 1

SOBRE OS PARTICIPANTES (10 MINUTOS)

Data:__/__/____ Perodo atual:___ Login: _____

Curso:

( ) Cincia da Computao ( ) Engenharia da Computao ( ) Sistemas de Informao ( ) Outros _________________

Em quantos projetos profissionais (envolvendo clientes reais) voc j participou de acordo com as seguintes categorias (preencher com nmeros):

___ projetos de baixa complexidade (menos de seis meses). ___ projetos de mdia complexidade (entre seis meses e um ano). ___ projetos de alta complexidade (mais de um ano). Em quantos projetos acadmicos voc j participou de acordo com as seguintes categorias:

___ projetos de baixa complexidade (menos de seis meses). ___ projetos de mdia complexidade (entre seis meses e um ano). ___ projetos de alta complexidade (mais de um ano).

87

Em quantos projetos voc j atuou como lder tcnico (responsvel pela arquitetura)?

___ Projetos acadmicos ___ Projetos profissionais Em quantos projetos orientados a servios voc j participou

___ Projetos Acadmicos ___ Projetos profissionais

Antes de comear o curso, como voc definiria a sua experincia em engenharia de software?

( ) Nenhuma ( ) Baixa ( ) Mdia ( ) Alta Antes de comear o curso, como voc definiria a sua experincia em SOA?

( ) Nenhuma ( ) Baixa ( ) Mdia ( ) Alta

Quantos documentos de requisitos e casos de uso voc j escreveu ou participou de revises?

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

88

PARTE 2

SOBRE O PROCESSO (30 MINUTOS)

No geral, como voc classificaria o processo?

( ) muito fcil ( ) fcil ( ) razovel ( ) difcil ( ) muito difcil

Qual etapa do processo voc teve mais dificuldade em entender?

( ) Nenhuma ( ) Especificao do modelo de negocio ( ) Projetar Servios ( ) Analisar servios ( ) Todas

Como voc classificaria a fase de Especificao do Modelo de Negcio?

( ) muito fcil ( ) fcil ( ) razovel ( ) difcil ( ) muito difcil

89

Na fase de Especificao do Modelo de Negcio, teve dificuldade em entender as atividades e os artefatos gerados?

( ) No ( ) Sim. Por favor, indique os artefatos e justifique?

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________

Na fase de Especificao do Modelo de Negcio, teve dificuldade em produzir os artefatos?

( (

) No ) Sim. Por favor, indique os artefatos e justifique?

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________ Na fase de Especificao do Modelo de Negcio, achou os artefatos gerados teis?

( (

) Sim ) No. Por favor, indique os artefatos e justifique?

_____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________

90

Como voc classificaria a fase de Analisar Servio?

( ) muito fcil ( ) fcil ( ) razovel ( ) difcil ( ) muito difcil

Na fase de Analisar Servio, teve dificuldade em entender as atividades? ( ( ) No ) Sim. Por favor, indique os artefatos e justifique?

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________

Na fase de Analisar Servio, teve dificuldade em produzir os artefatos?

( (

) No ) Sim. Por favor, indique os artefatos e justifique?

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________

Na fase de Analisar Servio, achou os artefatos gerados teis?

( (

) Sim ) No. Por favor, indique os artefatos e justifique?

_____________________________________________________________________ _____________________________________________________________________

91

_____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________ Em geral, como voc classificaria a fase de Projetar Servios:

( ) muito fcil ( ) fcil ( ) razovel ( ) difcil ( ) muito difcil

Na fase de Projetar Servio, teve dificuldade em entender as atividades?

( (

) No ) Sim. Por favor, indique os artefatos e justifique?

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________ Na fase de Projetar Servio teve dificuldade em produzir os artefatos gerados?

( (

) No ) Sim. Por favor, indique os artefatos e justifique?

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________

92

Na fase de Projetar Servio, achou os artefatos gerados teis?

( (

) Sim ) No. Por favor, indique os artefatos e justifique?

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________ Voc concorda que o processo ajuda no alinhamento do entendimento entre todos os participantes envolvidos no projeto (gerentes, analistas,

programadores, arquitetos, designer, clientes)?

( ) Discordo totalmente ( ) Discordo ( ) No sei responder ( ) Concordo ( ) Concordo totalmente

Voc concorda que o processo til para construo de uma arquitetura desacoplada entre front-end e o back-end?

( ) Discordo totalmente ( ) Discordo ( ) No sei responder ( ) Concordo ( ) Concordo totalmente

Como voc classificaria as aulas sobre o processo:

( ) Muito ruim

93

( ) Ruim ( ) Satisfatria ( ) Bom ( ) Muito Bom Voc gostaria de cursar a disciplina de Tpicos Avanados em Anlise e Projeto de sistemas com seminrios mais detalhados sobre SOA e MDE e projetos de sistemas at a codificao?

( ) Sim ( ) No

Voc tem alguma sugesto de melhoria no processo? Quais? _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________

94

Apndice B

Descrio dos Casos Uso do Qualiti Internet Banking.

Caso de uso: Efetuar Login

Descrio: Este caso de uso responsvel por autenticar um usurio do sistema. Pr-condio: nenhuma Ps-condio: um usurio vlido logado e sua sesso registrada no sistema. Fluxo principal 1. O cliente informa login e senha. 2. O sistema verifica se o login e a senha so vlidos (verifica-se se o login e senha pertencem a uma conta). 3. O sistema registra o incio de uma sesso de uso. Fluxos secundrios - No passo 2, se o login e a senha forem invlidos, o sistema exibe uma mensagem e volta ao passo 1.

95

Caso de Uso: Alterar Senha

Descrio: Este caso de uso responsvel por alterar a senha de um usurio do sistema. Pr-condio: O cliente da conta deve ter efetuado login. Ps-condio: senha do usurio alterada Fluxo principal: 1. O cliente informa login, senha antiga e a nova senha. 2. O sistema verifica se o login e a senha so vlidos (verifica-se se o login e senha pertencem a uma conta). 3. O sistema altera a senha do usurio com a nova senha Fluxos secundrios - No passo 2, se o login e a senha forem invlidos, o sistema exibe uma mensagem e volta ao passo 1.

96

Caso de Uso: Realizar Transferncia

Descrio: Este caso de uso responsvel por realizar transferncia entre duas contas bancrias.

Pr-condio: O cliente depositante deve ter efetuado login. Ps-condio: O saldo atual do cliente debitado deste valor , o qual creditado na conta informada como destinatria. Fluxo principal:

1.O cliente escolhe a opo de transferncia e informa o valor a ser transferido e a conta para depsito. 2.O sistema recupera a conta bancria do cliente (que j efetuou o login anteriormente) e a conta para depsito. 3.O sistema debita o valor da conta do cliente e credita na conta destinatria.

Fluxos secundrios - No passo 2, se a conta bancria do cliente no tiver saldo suficiente, sistema exibe uma mensagem de aviso e volta ao passo 1.

97

Caso de Uso: Efetuar Pagamento Qualiti Card

Descrio Este caso de uso responsvel por realizar o pagamento do Qualiti Card com a operadora de carto de crdito. Cada cliente possui apenas um carto como titular, estando vinculado a apenas uma operadora.

Pr-condio: O cliente deve estar conectado ao sistema (ter efetuado o login).

Ps-condio: O valor do pagamento debitado da conta do cliente, o pagamento enviado operadora do carto de crdito e a transao registrada no sistema. Fluxo Principal:

1. O cliente informa os dados necessrios para efetuar o pagamento do carto: - O cdigo de barras da fatura que deseja efetuar o pagamento. - O valor que deseja pagar.

2. O sistema recupera a conta bancria 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 carto de crdito.

6. O sistema registra a transao de pagamento e emite um comprovante da mesma para o usurio. A transao registrada contm os dados da conta do cliente, o cdigo de barras da fatura, data, hora e valor do pagamento. Fluxos Secundrios:

98

- No passo 3, se o saldo disponvel na conta do cliente for menor que o valor do pagamento, o sistema informa que o saldo insuficiente e retorna para o passo 1.

Caso de uso: Consultar Saldo

Descrio: Este caso de uso responsvel por consultar o saldo da conta bancria do cliente. Pr-condio: O cliente deve ter efetuado login. Ps-condio: nenhuma. Fluxo principal 1. O cliente seleciona a opo de consulta de saldo 2. O sistema recupera o saldo atual da conta bancria do cliente 3. O sistema exibe o valor do saldo e a data atual Fluxos secundrios - No tem.

99

Caso de uso: Consultar Cheques

Descrio: Este caso de uso responsvel por consultar os cheques emitidos pelo cliente. Pr-condio: O cliente deve ter efetuado login. Ps-condio: nenhuma. Fluxo principal 1. O cliente seleciona o perodo 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 secundrios - No passo 1, se o cliente informar uma perodo invlido, sistema exibe uma mensagem de avise e volta ao passo 1.

100

Caso de uso: Consultar Extrato

Descrio: Este caso de uso responsvel por consultar o extrato da conta bancria do cliente. Pr-condio: O cliente deve ter efetuado login. Ps-condio: nenhuma. Fluxo principal 1. O cliente seleciona o perodo referente ao extrato (data inicial e data final) 2. O sistema recupera todas as transaes realizadas na conta do cliente 3. O sistema exibe uma lista com a data, hora e o valor de cada transao Fluxos secundrios - No passo 1, se o cliente informar uma perodo invlido, sistema exibe uma mensagem de avise e volta ao passo 1.

101