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

Um Processo para Projeto Arquitetural de Software Dirigido a Modelos e Orientado a Serviços
Por

Vítor Torres Braga
Dissertação de Mestrado

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

RECIFE, AGOSTO/2011

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

VÍTOR TORRES BRAGA

“Um Processo para Projeto Arquitetural de Software Dirigido a Modelos e Orientado a Serviços”

ESTE TRABALHO FOI APRESENTADO À PÓSGRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO TÍTULO DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.

ORIENTADOR: AUGUSTO SAMPAIO CO-ORIENTADOR: VINICIUS CARDOSO GARCIA

RECIFE, AGOSTO/2011

iii

AGRADECIMENTOS
Dedico este trabalho a minha maravilhosa família que sempre me apoiou em todos os momentos da minha vida. Em especial ao meu pai, minha mãe e minha irmã, por serem exemplos de dignidade, honestidade e perseverança que modelaram o meu caráter e foram os responsáveis pelo homem que me tornei. Vocês são meus únicos e verdadeiros heróis. A minha namorada Juliana por ter sido compreensiva, atenciosa e ter me suportado durante esses últimos anos. Perdoe-me pelos vários compromissos desmarcados, prometo que vou recompensar. Ao meu orientador Augusto Sampaio por sempre ter acreditado no meu potencial e, desde o inicio, confiado no meu trabalho. Muito obrigado pelo tempo dedicado e paciência. Foi um privilégio ter convivido de perto durante esses anos, nossa universidade precisa de mais professores como você. Ao meu co-orientador Vinicius Garcia pela paciência e excelentes sugestões apresentadas na reta final. Muito obrigado pelo tempo gasto com leitura e correções de cada capitulo. Aos meus parceiros da MobilIT, hoje Comment Lab, Farley, Paulo e Firma por terem sido amigos com os quais sempre pude contar e compartilhar os sucessos, fracassos e angustias.

iv

Resumo
Nos últimos anos, o Desenvolvimento Dirigido a Modelos (Model-Driven Development - MDD) tem se posicionado como uma tendência na pesquisa de engenharia de software. Embora o uso de modelos não seja novidade, o sucesso MDD vem da possibilidade de construir sistemas de software completos a partir de transformações automáticas de modelos. Apesar de MDD ser reconhecida como

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

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

v

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

vi

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

Capítulo 2 - Conceitos e Fundamentos ...................................................... 8
2.1 2.2 Introdução .......................................................................................................... 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 Limitações 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

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

Capítulo 4 - Instanciação e Execução do Processo ................................. 48
4.1 4.2 Introdução ........................................................................................................ 48 Qualiti Internet Banking .................................................................................. 48

vii

4.3 4.4 4.5

Especificar Modelo de Negócios .................................................................... 49 Analisar Serviços............................................................................................. 52 Projetar Serviços ............................................................................................. 56

Capítulo 5 - Avaliação do Processo.......................................................... 61
5.1 5.2 5.3 5.4 5.5 5.6 Introdução ........................................................................................................ 61 Definição .......................................................................................................... 61 Planejamento ................................................................................................... 66 Operação .......................................................................................................... 68 Coleta e Análise dos Dados ............................................................................ 69 Lições Aprendidas ........................................................................................... 73

Capítulo 6 - Conclusão .............................................................................. 75
6.1 6.2 6.3 6.4 Principais contribuições ................................................................................. 75 Trabalhos Relacionados ................................................................................. 76 Limitações e Trabalhos Futuros ..................................................................... 79 Considerações Finais ...................................................................................... 79

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

viii

Lista de Tabelas
Tabela 5.1. Dados dos Projetos. Tabela 5.2. Resultados da métrica CBCS. Tabela 5.3. Resultados da métrica WOCS. Tabela 5.4. Resultados da métrica IMSC. Tabela 6.1. Resultados da análise. 69 70 70 71 78

ix

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

x

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

xi

Capítulo 1 - Introdução

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

1

O Desenvolvimento de Sistemas Orientados a Aspectos (DSOA) é uma abordagem cujo objetivo principal é separar requisitos transversais das classes da aplicação. Utilizando orientação a aspectos, requisitos como registro de operações, controle de sincronização e comunicação podem ser implementados de forma simples, elegante e favorecendo a reutilização de código [66]. Arquitetura Orientada a Serviço, do inglês Service Oriented Architecture (SOA), tem como principal objetivo o reúso intenso de serviços, para que em médio prazo, a tarefa do desenvolvimento de uma aplicação seja, primordialmente, a composição e coordenação dos serviços já implementados, aumentando o reúso e diminuindo o dispêndio de recursos. Para atingir esses objetivos, SOA segue ―boas práticas‖ e ―princípios de projeto‖ para facilitar a tarefa de definir, encontrar e gerenciar os serviços [22]. Alguns trabalhos consideram SOA como uma evolução do

Desenvolvimento Baseado em Componentes [47]. Já o Desenvolvimento Dirigido por Modelos (Model Driven Development - MDD) [8] utiliza modelos para especificar e implementar toda e qualquer parte dos sistemas. Utilizando MDD, os sistemas são modelados em vários níveis de abstração e sob diferentes perspectivas. Diferentemente das outras abordagens de desenvolvimento de software, os modelos são os artefatos centrais para a construção das aplicações, e não o código. Neste sentido, analisando as abordagens de desenvolvimento apresentadas anteriormente, a combinação de conceitos e fundamentos existentes em um processo integrado e sistematizado pode oferecer contribuições tanto para a academia como para a indústria [54], segundo palavras de Jim Neighbors: “organizações

acadêmicas em ciência da computação parecem preferir o trabalho em novas teorias. Porém, alguns dos mais bem-sucedidos trabalhos acadêmicos são uma fusão e formalização de técnicas de sucesso.”
Nos últimos anos, MDD tem se posicionado como uma tendência na prática e na pesquisa em engenharia de software. Embora o uso de modelos não seja novidade, o seu sucesso vem da possibilidade de construir sistemas de software completos a partir de transformações automáticas de modelos. Propostas como Software Factories1 da

1

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

2

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

2 3

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

3

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

Diante deste cenário, este trabalho apresentada um processo de projeto arquitetural de software dirigido a modelos e orientado a serviços, a fim de possibilitar o projeto de arquiteturas estáveis, flexíveis e modulares. O processo foi elaborado para ser sistemático, fácil de usar e compreender, independente de ferramentas e tecnologias, e que pudesse resolver problemas práticos como: a integração de aplicações, o acoplamento entre front-end e back-end dos sistemas [13], e o desalinhamento de expectativas entre os stakeholders [4,3]. Para atingir esses objetivos, o processo foi dividido em três conjuntos de atividades (workflows) distintos: Especificar Modelo de Negócio, Analisar Serviços e Projetar Serviços. Especificar Modelo de Negócio tem como principal objetivo produzir

artefatos que ajudem no alinhamento do entendimento entre os stakeholders. Analisar Serviços tem como principal finalidade projetar a arquitetura do sistema independente de plataforma de desenvolvimento. No Final, Projetar Serviços tem como objetivo refinar os modelos produzidos e transformá-los em modelos menos abstratos e projetados para executar em plataformas especificas. Para avaliar aspectos quantitativos e qualitativos do processo aqui proposto, foi desenvolvido um estudo de caso para ilustrar as diversas etapas do processo e conduzido um estudo experimental utilizando a abordagem Goal Question Metric [6].

1.2 Principais Contribuições
Entre as principais contribuições deste trabalho, podemos destacar: 1. Definição de um processo sistemático para projeto arquitetural de software dirigido a modelos e orientado a serviços, favorecendo: o Reutilização de software: Nas primeiras fases do processo é possível identificar oportunidades de reuso.

4

o

Modularidade: Com os artefatos gerados pelo processo é possível projetar uma arquitetura desacoplada, tornando possível projetar os componentes de forma independente.

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

1.3 Fora do Escopo
Uma fez que o processo arquitetural proposto faz parte de um contexto mais amplo, algumas questões importantes não foram abordadas nesse trabalho. Entretanto, essas questões foram pensadas desde o início e constituem tópicos de pesquisa a serem explorados em trabalhos futuros: 1. Transformação de modelos: O processo utiliza os conceitos de MDA e MDD, mas não foram definidas regras formais para transformação dos modelos (as regras e mapeamentos foram definidas textualmente). 2. Alcance do processo: O foco do processo proposto é na atividade de projeto arquitetural. Engenharia de requisitos, controle de qualidade, gerência de configuração, gerenciamento de atividades e codificação não foram abordados.

5

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

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

6

Capítulo 1 Introdução

Motiva e Contextualiza

Capítulo 2 Conceitos e Fundamentos
É usado por

Motiva e apresenta o problema para

Capítulo 3 O Processo

É avaliado por

Capítulo 5 Avaliação do processo

É instanciado por

Capítulo 4 Exemplo de uso

Motiva

Motiva

Capítulo 6 Conclusão

Figura 1.1 – Roadmap do trabalho.

7

Capítulo 2 - Conceitos e Fundamentos

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

8

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

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

9

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

2.2.1 Vantagens e Desvantagens
MDD visa acelerar o desenvolvimento de software a fim de torná-lo mais eficiente. A seguir são apresentadas algumas vantagens na utilização de MDD [23, 57, 58, 59]:  Produtividade: Tarefas que são repetitivas podem ser implementadas nas transformações dos modelos, diminuindo o tempo e esforço que podem ser utilizado em outras tarefas mais importantes. Além disso, a partir dos modelos pode-se gerar código para diversas plataformas e tecnologias.  Portabilidade e interoperabilidade: um único modelo poderá ser

transformado em código para várias plataformas. Com isso, podem ser construídos modelos de adaptadores e conectores independentes de tecnologia e depois transformá-los em código para que diferentes plataformas possam se comunicar;

10

Comunicação: os profissionais envolvidos no projeto poderão se comunicar de forma mais efetiva, pois os modelos são mais abstratos e fáceis de entender do que o código, não exigindo conhecimento técnico de uma tecnologia específica. Por isso, especialistas poderão participar ativamente e utilizar diretamente os modelos para identificar os conceitos relativos ao problema.

Corretude: os geradores de código não introduzem erros banais como erros de digitação, portanto a identificação de erros conceituais acontece em um nível de abstração mais alto, tornando-se, teoricamente, resolver. mais fáceis de

Em resumo, as vantagens relacionadas ao uso de MDD estão diretamente relacionadas à capacidade de evitar que os desenvolvedores executem tarefas repetitivas que podem ser desempenhadas pelas transformações. E, diferente de outras abordagens de desenvolvimento de software, com mecanismos de

transformações automáticas seria mais produtivo construir os sistemas em um nível de abstração alto, pois isso possibilitaria não só o reuso de componentes de software, mas também a reutilização de conhecimento [56].

2.3

MDA – Model Driven Architecture

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

de desenvolvimento de software em uma disciplina de engenharia. Resumindo, MDA define uma abordagem para:   Especificar o sistema independentemente da plataforma que irá executar; Especificar plataformas de execução de sistemas;

11

Especificar transformações de modelos.

Um modelo de um sistema é uma descrição ou especificação desse sistema e seu ambiente para um propósito determinado. Um modelo é muitas vezes apresentado como uma combinação de desenhos e texto. O texto pode estar em uma linguagem de modelagem ou em uma língua natural. No contexto de MDA, um modelo é, basicamente, uma representação de um sistema. MDA classifica o modelo em três tipos:  Computation Independent Model (CIM): Os requisitos do sistema podem ser especificados com modelos independente de computação (CIM). O CIM descreve a situação em que o sistema será utilizado. Em outras abordagens esse modelo é chamado de modelo de domínio ou modelo de negócio. O CIM oculta todas as informações sobre o uso do sistema e é totalmente independente de como o sistema será implementado. O CIM pode ser representado com diagramas UML simples.  Platform Interdependent Model (PIM): é o modelo independente de computação e descreve o sistema ocultando detalhes de plataforma e tecnologias de desenvolvimento. Esses modelos apresentam o núcleo funcional e estrutural do sistema. Diferente do CIM, o PIM projeta o sistema do ponto de vista computacional.  Platform Specific Model (PSM): é o modelo de plataforma específica. O PSM é o refinamento do PIM, ou seja, ele combina as informações do PIM para uma plataforma em particular (Java ou .Net, por exemplo). Em princípio, o processo de desenvolvimento de software utilizando MDA começa com a definição do Modelo de Computação Independente (CIM). O CIM pode ser definido por analistas de sistemas em cooperação com especialistas do domínio. Posteriormente o CIM é transformado em um modelo independente de plataforma (PIM). O PIM acrescenta informações ao CIM, sem mostrar os detalhes da plataforma utilizada. Por fim, o PSM é transformado em um modelo de plataforma específica (PSM) acrescentando os detalhes da plataforma escolhida. A Figura 2.2 ilustra o processo MDA básico descrito anteriormente.

12

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

13

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

14

Class

instace of 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 – Níveis de modelagem em MDA. O nível M0 define os modelos executáveis do sistema. O nível M1 descreve as abstrações no domínio do sistema que são usadas no nível M0. O nível M2 descreve os meta-modelos usados em M2 e, em M3, são definidas as metas-linguagem utilizadas em M2.

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

15

Figura 2.5 – Diferentes pontos de vistas de SOA [56]. Essa confusão ocorre porque o termo “service oriented architecture” é muitas vezes confundido com “service oriented computing”. Por isso, é muito importante deixar claro a distinção entre termos e conceitos relacionados a SOA. Service Oriented Computing (SOC) [7], segundo Thomas Erl, é um conceito bastante amplo que representa uma nova geração de plataforma de computação distribuída. Engloba

vários elementos como princípios de design, padrões de projeto, linguagens de programação, hardware, frameworks, processos e estratégias organizacionais. SOA é, basicamente, um modelo de arquitetura de software que beneficia a eficiência, agilidade e produtividade no desenvolvimento de aplicações e está alinhada com os objetivos de “service oriented computing”. Uma arquitetura de software é um conceito abstrato que dá margem a uma série de definições. Este trabalho utiliza a definição da IEEE: uma arquitetura de software

trata basicamente de como os componentes fundamentais de um sistema se relacionam intrinsecamente e extrinsecamente [45]. Ou seja, SOA é um modelo de
arquitetura onde as funcionalidades das aplicações são modeladas como serviços. Serviço é um componente que atende a uma função de negócio (business function) específica. Ele pode receber e responder requisições ocultando completamente os detalhes de sua implementação. Portanto, um serviço pode ser considerado um

16

conjunto de capacidades associadas a um propósito comum (ou contexto funcional). Essas capacidades estão expressas em um contrato de serviço. Baseando-se na natureza da lógica do negócio, no potencial de reutilização dessa lógica e como a lógica implementada se relaciona com o domínio da aplicação, os serviços podem ser classificados em três tipos [7]:  Serviço de Entidade (Entity Services): é um tipo de serviço que é derivado de uma ou mais entidades de negócio relacionadas e possuem alto grau de reutilização. Serviços que fazem operações CRUD (Create, Read, Update, Delete), por exemplo.  Serviço de Tareta (Task Service): serviço que corresponde a um único propósito. Um serviço de tarefa geralmente possui um baixo potencial de reuso e utiliza outros serviços para realizar a sua lógica.  Serviço de Utilidade (Utility Service): Serviço comum a vários tipos de aplicação como log, notificação, tratamento de exceção e transformação de informações. Tem um alto potencial de reuso e é desenvolvido para ser usado por outros serviços. A Figura 2.6 mostra o relacionamento entre os três tipos de serviços em uma aplicação.

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

17

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

2.4.1 Vantagens e Limitações
Seguem alguns benefícios em utilizar uma arquitetura orientada a serviços [46] [47] [7]:

Reuso “caixa-preta”: O reuso ―caixa-preta‖ visa eliminar a necessidade de o programador ter conhecimento da implementação de um determinado componente de software que fará parte do processo de reuso. O reuso caixapreta se dá através da descrição de interfaces ou contratos bem definidos que devem ser respeitados durante o desenvolvimento. O esforço é sempre usado na nova implementação e não no entendimento da implementação do componente.

Interoperabilidade: O fenômeno da Web 2.0 apresentou uma nova realidade para os desenvolvedores de sistemas. Por ser uma rede de escala gigantesca existe uma infinidade de serviços que podem ser acessados através da Internet. Usando SOA é possível acessar serviços em diferentes plataformas de hardware, implementados em diferentes linguagens de programação, usando protocolos bem definidos.

Baixo acoplamento: Cada atividade (função de negócio) é implementada como um serviço, ou seja, um componente independente que poderá ser utilizado quantas vezes forem necessárias em diversas partes do sistema. Assim, SOA é uma arquitetura baseada em componentes onde cada componente preserva a sua independência.

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

18

Serviços

com

granularidade

grossa:

dependendo

do

tamanho

e

complexidade das aplicações, testar e validar todas as combinações de todas as condições de um serviço complexo pode se tornar impossível. Se um serviço altamente genérico for utilizado por dezenas de outros, a sua otimização pode ser uma tarefa muito difícil.  Acoplamento fraco: é o sonho de todo arquiteto projetar um sistema distribuído altamente desacoplado, mas adicionar novas funcionalidades com um alto nível de complexidade pode se tornar um pesadelo.  Integração: especialmente  integração de serviços 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

disponíveis no mercado que são atualizadas constantemente. Portanto, custa tempo e dinheiro treinar e manter uma equipe atualizada.

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

19

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

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

20

2.5.1

Simple Interfaces

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

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

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

21

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

2.5.2

Service Interface

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

22

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

23

Figura 2.11 – Coreografia do Serviço [26]. Na coreografia do serviço, mostrada na Figura 2.11, o consumidor Order Place chama (opcionalmente) a operação Quote Request e depois chama a operação Order.

2.5.1

Service Contract

Contrato de Serviço (Service Contract) determina como fornecedores, consumidores e, potencialmente, outros papéis trabalham juntos para trocar informações. O Contrato de Serviço define os papéis que cada participante desempenha no serviço

24

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

2.5.1

Service Architecture

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

25

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

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

26

Capítulo 3 - O Processo

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

Figura 3.1 - Visão Geral do Processo. A Figura 3.1 mostra a visão geral do processo considerando os termos MDA e os conceitos e princípios utilizados em SOA. No workflow Especificar Modelo de

27

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

3.2 Especificar Modelo de Negócio
O principal objetivo deste workflow é gerar artefatos que facilitem o entendimento do sistema que será desenvolvido e que possam ser facilmente compreendidos por todos os stakeholders envolvidos no projeto (clientes, arquitetos, gerentes de projetos e desenvolvedores). A Figura 3.2 mostra o fluxo de atividades e os artefatos gerados (algumas setas foram omitidas para não prejudicar o entendimento do diagrama).

28

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

29

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

funcionalidades, os usuários e os sistemas externos são representados em um modelo de casos de uso. A segunda atividade é Projetar Fluxo de Informação que tem como entrada o MIN. Esta atividade gera como saída o Modelo Navegacional (MN). O MN pode ser um diagrama de classes que utiliza GuiProfile profile [30], um profile UML para a modelagem de interfaces gráficas, para organizar o fluxo de telas (ou páginas, no caso de aplicações web) do sistema. A Figura 3.3 mostra um exemplo de modelo navegacional de um editor UML simples.

Figura 3.3 – Exemplo de Modelo Navegacional [30]. O modelo navegacional, mostrado na Figura 3.3, foi projetado como um diagrama de classes com estereótipos para representar as janelas principais (<<

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

30

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

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

31

Figura 3.5 – Exemplo do Protótipo de Interface Gráfica [30]. A imagem, os textos, a caixa de texto, os seletores e o botão foram modelados com os estereótipos PresentationImage, Text, InputTextBox, RadioButton, CheckBox e Button, respectivamente. A proporção de alguns elementos foi alterada para facilitar a visualização de seus nomes. O PIG também pode ser projetado como um wireframe [27] completo do sistema que contém todas as funcionalidades, telas, conteúdo e mensagens. Wireframes são muito utilizados na indústria para validar funcionalidades e aplicar testes de usabilidades antes que o sistema comece a ser codificado. O PIG é um artefato muito útil para entender, visualizar e avaliar claramente o que será desenvolvido antes que o sistema comece a ser projetado. A Figura 3.6 mostra os modelos, meta-modelos e meta-linguagens envolvidos em Especificar Modelo de Negócios.

32

conforms To MOF

conforms To 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 Negócio. Conforme ilustrado na Figura 3.6, o Modelo de Informação de Negócios (MIN) e o Modelo de Funcionalidades é um modelo UML 2.0. O Modelo Navegacional (MN) e o Protótipo de Interface Gráfica (PIG) são instâncias do GuiProfile. O GuiProfile é uma extensão de UML 2.0 em conformidade com seus respectivos meta-modelos (GuiProfile UML MM). E todos os meta-modelos de UML 2.0 e GuiProfile foram definidos em conformidade com o MOF.

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

33

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

34

provedores e consumidores de serviços quanto às informações que serão trocadas entre eles. A partir do Modelo de Funcionalidades pode se gerar a Arquitetura de Serviço automaticamente utilizando as seguintes regras:  Contratos de serviços: os pacotes de casos de uso do modelo de funcionalidades são mapeados em contratos de serviços. Casos de usos que não pertencem a nenhum pacote são mapeados em contratos de serviços independentes. Os relacionamentos entre caso de uso  ator também são mapeados como contratos independentes.  Participantes: os atores são diretamente mapeados como participantes. O ―sistema‖ dá origem a um participante independente que irá consumir e fornecer serviços para os outros participantes. O próprio ―sistema” dá origem a um participante independente. Para facilitar a compreensão, a Figura 3.8 mostra visualmente o processo de transformação.

35

Pacote 2 UC 5 UC3 UC 4

Pacote 1 UC 1 Ator 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 – Construção da Arquitetura de Serviços. No exemplo mostrado na Figura 3.8, os pacotes de casos de uso (Pacote 1 e Pacote 2 ) foram mapeados nos contratos de serviços com os mesmos nomes (<<Service Contract>> Pacote 1 e (<<Service Contract>> Pacote 2). O caso de uso UC5 (quadrado tracejado na Figura 3.8) foi mapeado em um novo serviço (<<Service Contract>> UC5). Os atores 1 e 2 foram mapeados em participantes com os mesmos nomes (<<Participant>> Ator 1 e <<Participant>> Ator 2 ). O relacionamento UC5-Ator 2 deu origem ao contrato de <<Service Contract>> UC5-Ator2, conforme ilustrado pela seta pontilhada na Figura 3.8. O participante ―Sistema‖ surgiu para prover serviços ao participante ―Ator 1‖ e consumir de ―Ator 2‖.

36

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

funções específicas através das quais os serviços podem ser invocados. Elas são as

<<entity service>> E1

<<entity service>> E2

E3

MIN marcado

<<service contract>> Serviço E1

<<service contract>> Serviço E2

Figura 3.9 – Serviços de Entidade. Com a identificação dos serviços de entidade e a Arquitetura de Serviços é possível criar automaticamente os templates dos Modelos de Interação dos Serviços da seguinte forma: 1. Criam-se interfaces com os nomes dos participantes consumidores (representando a porta <<Resquest >> dos participantes consumidores de SoaML); 2. Criam-se interfaces com os nomes dos contratos de serviços e serviços de entidade (representando a porta <<Service>> dos participantes

consumidores de SoaML);

37

3. Para cada contrato de serviço é criado automaticamente um MIS contendo: a. a interface com o nome do participante consumidor do contrato de serviço; b. a interface com o nome do contrato de serviço e c. as interfaces dos serviços de entidade. Com o template do MIS construído, pode-se identificar manualmente as operações e mensagens de cada interface (baseado nos artefatos de entrada para o processo).A Figura 3.10 mostra um exemplo da construção de um MIS completo.
: Participantes 1 : Servico1

: Serviço E1

: Servico 2

operacao1()

operacao1() retorno

operacao1()

retorno operacao2() retorno

retorno

Figura 3.10 –Modelo de Interação de Serviços. O MIS pode ser construído como um diagrama de sequência ou de comunicação. É importante notar que o MIS não deve conter mensagens reflexivas e não precisa exibir a seqüência numérica, pois o objetivo é identificar apenas as operações das interfaces e não como estas operações são realizadas. Ao final, as interfaces de serviços de entidades não utilizadas são removidas. Com a elaboração dos Modelos de Interação dos Serviços podem surgir novas entidades que não foram identificadas previamente e identificar entidades não utilizadas ou modeladas incorretamente, portanto, o MIN deverá ser atualizado. Após a construção dos Modelos de Interação dos Serviços a Arquitetura de Serviço é revisada levando-se em consideração as seguintes questões:

38

  

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

A última atividade de Analisar Serviços é Identificar Componentes. Essa atividade tem como objetivo construir o Modelo de Componentes dos Serviços (MCS). O MCS é a primeira arquitetura ―componentizada‖ do sistema. O MCS também pode ser construído a partir da transformação da AS e dos MIS através das seguintes regras:   os participantes exclusivamente consumidores são mapeados em

componentes; os contratos de serviços são mapeados em componentes e suas respectivas interfaces (interfaces com o mesmo nome do contrato de serviço geradas na atividade anterior);  As operações das interfaces são obtidas diretamente das operações identificadas no MIS. A Figura 3.10 mostra visualmente as regras para construir o Modelo de Componentes dos Serviços a partir da Arquitetura de Serviços.

39

<<Service Contract>> Pacote1

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

consume

<<Participant>> Ator1

consume

<<Service Contract>> Pacote2

consume provide <<Service Contract>> UC5

Arquitetura de Serviços
<<Service Contract>> Service E1

Serviço de Entidade

Componente 1 IServiceE1

ComponenteE1

IService1

Compoente A IServicec2

Componente 2

Componente 4 IServicec4 IService3

Componente 3

Figura 3.11–Construção do Modelo de Componentes de Serviços. Conforme ilustrado na Figura 3.11, participante ―Ator1‖ foi mapeado no ―Componente A‖ e os contratos de serviços:    <<Service Contract>> Pacote 1 deu origem ao IService1 e Componente1 <<Service Contract>> Pacote 2 deu origem ao IService2 e Componente1 <<Service Contract>> UC5 deu origem ao IService4 e Componente4

40

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

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

Transformação CIM-PIM

Modelo Informação do Negócio

Arquitetura de Serviços

Transformação PIM-PIM

Modelo de Interação de Serviços (Template)

Modelo Informação do Negócio Refinado

Transformação PIM-PIM

Transformação PIM-PIM

Modelo de Interação de Serviços (completo)

Modelo de Componenes de Serviços

Figura 3.12–Transformações de modelo da fase Analisar Serviços. A Figura 3.13 mostra os modelos, meta-modelos e meta-linguagens utilizados em Analisar Serviços.

41

conforms To

MOF

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

instance Of

instance Of

instance Of

MF

MIN

AS

MIS

MCS

Figura 3.13–Modelos da fase Analisar Serviços. O Modelo Funcional (MF) e o Modelo de Informação do Negócio (MIN) são modelos UML. A Arquitetura de Serviços (AS), Modelo de Interação de Serviços (MIS) e Modelo de Componentes dos Serviços (MCS) são modelos SOAML. O profile SoaML foi modelado conforme seu meta-modelo SoaML MM que foram definidos com o MOF.

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

42

A Figura 3.14 apresenta o fluxo de atividades desta fase.

Figura 3.14–Diagrama de artefatos de Projetar serviços Na primeira atividade, Definir Arquitetura do Sistema, é feita a revisão e o refinamento dos modelos gerados na fase anterior. Baseado na documentação do sistema e no conhecimento do negócio é uma boa prática revisar o Modelo de Interação dos Serviços e Modelo de Componentes dos Serviços, gerados no workflow anterior, levando-se em consideração as seguintes questões:  Todos os componentes de front-end foram identificados?

43

  

Podemos agrupar contratos de serviços semelhantes? Como será a integração entre o front-end e back-end? Como será feita a comunicação com sistemas externos? É possível reutilizar, adaptar ou comprar componentes existentes?

Com isso, a atividade Definir Arquitetura do Sistema tem como saída a Arquitetura do Sistema que é, basicamente, uma evolução da Arquitetura de Componentes de Serviços com todos os elementos necessários para modelar os componentes internamente e os componentes de front-end marcados com o estereótipo <<Front-end>>. Com os modelos devidamente refinados, são definidos os padrões, tecnologias e frameworks que serão utilizados no projeto do sistema. Portanto, devem-se levar em consideração os seguintes aspectos:     Plataformas de desenvolvimento e frameworks: quais serão as plataformas, tecnologias e frameworks utilizados para o desenvolvimento do sistema? Integração front-end e back-end: como será a comunicação entre o font-end e o back-end do sistema? Padrões de arquitetura: quais padrões de arquitetura serão utilizados no desenvolvimento do sistema? Padrões de projetos: quais padrões de projetos serão utilizados na modelagem de cada componente? A Figura 3.15 mostra o exemplo de uma Arquitetura do Sistema.
<<Front-end>> Desktop <<Front-end>> Mobile

ICommunication Communication

IServiceContrac4 IServiceContrac2 Componente 4 Componente 2

IServiceContrac1

Componente 1

Componente 3 IServiceContrac3

Figura 3.15–Exemplo de Arquitetura do Sistema.

44

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

anteriormente, para cada componente é construído seu diagrama de classes e os diagramas de sequência de todas as operações da sua interface. Portanto, é necessário detalhar a estrutura interna (atributo e operações) e relacionamentos das classes projetadas, além de garantir que elas fornecem o comportamento necessário para realizar as operações da interface do componente. 2. Atualizar modelo de informação: com todos os componentes modelados internamente, é necessário atualizar o modelo de informação do sistema. 3. Projetar banco de dados: com o modelo de informação refinado do sistema e todos os componentes projetados, caso seja necessário, é feito o projeto de banco de dados do sistema levando-se em consideração a tecnologia utilizada. Na atividade Projetar Front-end são construídos os diagramas de sequência e de classe baseando-se no Protótipo da Interface Gráfica, a integração entre o front-end e back-end, os guias e padrões definidos para cada componente front-end do sistema. Da mesma forma que a fase Analisar Serviços, os modelos gerados na fase Projetar Serviços podem ser construídos sistematicamente e/ou gerados por meio de transformações. A Figura 3.16 mostra as transformações de modelos envolvidos na fase Projetar Serviços.

45

Padrões de Arquitetura

Transformação PIMPIM

Restrições

Guias

Arquitetura Sistema

Padrões de Projetos

Protótipo Interface Gráfica Tranformação PIM-PIM

Diagramas Backend

Diagramas Frontend

Transformação (PIM -PSM)

Modelo de Plataforma

Transformação (PIM-PSM)

Modelos Front-end PSM

Modelos Back-end PSM

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

46

conforms To

MOF

conforms To UML2 MM

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

Figura 3.17–Modelos da fase Projetar Serviços Em Projetar Serviços todos os modelos produzidos são modelos UML 2.0.

47

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

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

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

48

Consultar Saldo Consultar Extrato Realizar Transferência

Consultar Cartão Alterar Senha Efetuar Pagamento Cartão Efetuar Login ClienteAtor

Operadora de Cartão

Figura 4.1–Casos de Uso do QIB. No sistema é possível realizar transferências entre contas correntes, consultar saldo e extrato, gerenciar a conta do usuário (login e senha), consultar e efetuar pagamento do cartão de crédito (Qualiti Card). Para simplificar o sistema e ajudar na construção dos artefatos, um cliente possui apenas uma conta corrente e um cartão de crédito. As descrições dos casos de uso são mostradas no Apêndice B.

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

49

Figura 4.2–Modelo de Informação de Negócio do QIB. Conforme mencionado no Capítulo 3, o MF é, basicamente, um modelo de casos de uso, agrupados em pacotes, com as funcionalidades (representados pelos casos de uso) e os usuários (representados pelos atores) da aplicação. Como ilustrado na Figura 4.3, a partir da descrição dos casos de uso do QIB (Anexo I) os casos de uso foram agrupados em três pacotes distintos: Controle de Acesso (funcionalidades relacionadas ao acesso dos usuários ao sistema), Controle de Conta (relacionado a manipulação da conta bancária dos clientes) e Controle QualitCard (funcionalidades relacionadas ao Qualit Card).

50

Consultar Saldo Consultar Extrato Realizar Transferência

Consultar Cartão Alterar Senha Efetuar Pagamento Cartão Efetuar Login ClienteAtor

Casos de Uso
Operadora de Cartão

Controle Conta

Controle Qualit Card

Controle de Acesso

ClienteAtor

Operadora de Cartão

Modelo de Funcionalidades Figura 4.3–Modelo de Funcionalidades do QIB. O QIB é um sistema simples e possui apenas quatro páginas principais (home, minha página, ajuda e contato. Em ―minha página‖ ele poderá acessar as opções de gerenciamento de conta corrente e cartão. Para elaborar o Modelo Navegacional foi escolhido o sitemap, mais indicado para aplicações web, conforme mostrado na Figura 4.4.

Figura 4.4–Modelo Navegacional do QIB

51

Para construção do MN em aplicações web recomenda-se o uso da ferramenta Axure RP [28]. Em aplicações para dispositivos móveis recomenda-se o uso da ferramenta Netbeans (versão completa com o Visual Mobile Designer) [50]. Se a aplicação for simples até mesmo o PowerPoint ou o Visio pode ser utilizado para fazer o MN. Com o MN e MIN é possível construir o PIG que é o primeiro protótipo do sistema e pode ser utilizado para validar as funcionalidades e avaliar a usabilidade do sistema. A Figura 4.5 mostra o wireframe da tela inicial do sistema.

Figura 4.5–Protótipo de Interface Gráfica do QIB da tela login. Para construção do PIG aconselhasse fortemente o uso de ferramentas de prototipação como o Axure RP [28].

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

52

Controle Conta

Controle Qualit Card

Controle de Acesso

ClienteAtor

Operadora de Cartão

Modelo de Funcionalidades

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

<<Service Contract>> OperadoraCartao provider <<participant>> Operadora Cartão

provider

<<participant>> Sistema back-end

consumer

consumer <<Service Contract>> ControleQualitiCard

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

53

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

Figura 4.7–Serviços de Entidade do QIB.

: Cliente Front-end

: IControleAcesso

: IContaInternet

logar(login,senha)

existe(login, senha) ContaInternet

sessão alterar(login,antiga, nova)

existe(login,senha) ContaInternet atualizar(ContaInternet) sessão Conta Internet

Figura 4.8–Modelo de Interação de Serviço do QIB. Conforme as regras descritas no capítulo anterior, o MIS relacionado ao contrato de serviço ―ControleAcesso‖, mostrado na Figura 4.8, contém as interfaces

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

54

Após a construção dos modelos de interação dos serviços foi verificado que a entidade PagamentoCartão era na verdade uma Transação e surgiram os atributos das entidades, por isso, o MIN foi atualizado. A Figura 4.9 mostra o MIN atualizado.
ContaBancaria +numero +saldo ContaintInternet +login +senha Transacao +numero da fatura +data +valor +numero da conta

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

IControleAcesso

IControleConta Controle Conta

IControleQualitCard Controle QualitCard

Controle de Acesso

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

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

55

―ControleQualitiCard‖ - Figura 4.6) e suas interfaces (IControleAcesso, IControleConta e IControleQualitiCard – e Figura 4.10). 3. os serviços de entidades (ContaInternet, ContaBancaria, Transação na Figura 4.7) foram transformados em componentes (―ContaInternet’, ―ContaBancaria‖ e ―Transação‖ – Figura 4.10) e suas interfaces (IContaInternet, IContaBancaria e ITransacao – Figura 4.10). 4. O participante ―OperadotaCartão‖ (Figura 4.6) foi transformado no componente ―OperadoraCartão‖ (Figura 4.10) e sua interface ―IOperadoraCartão‖ (Figura 4.10) foi gerada a partir do contratado de serviço ―OperadoraCartão‖ (Figura 4.6). Como ferramenta de modelagem para esse workflow, aconselhasse o uso das ferramentas Magic Draw4 com o plugin Cameo SOA+5 ou o Rational Software Archtect6, pois elas possuem o profile SoaML completo. Mas como os modelos SoaML utilizados pelo processo podem ser facilmente representados com estereótipos, também podem ser usadas outras ferramentas de modelagens UML 2.0 como astah community7 (antigo JUDE Community) ou o StarUML8 (ferramenta utilizada neste trabalho).

4.5 Projetar Serviços
No começo da fase Projetar Serviços é feita a revisão e o refinamento dos modelos gerados na fase anterior e depois é elaborada a Arquitetura do Sistema. Para isso é recomendado responder as seguintes questões:  Empacotamento das funcionalidades foi feito de forma correta? As funcionalidades ―isoladas” poderiam fazer parte de algum contrato de serviço existente?

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

57

Front-end Web

Front-end Iphone

Front-end Desktop

IFachadaWebSercice WebService

IControleAcesso

IControleConta Controle Conta

IControleQualitCard Controle QualitCard

Controle de Acesso

IContaInternet

IContaBancaria ContaBancaria

ITransação Transação

IOperadoraCartão OperadoraCartão

ContaInternet

Figura 4.11–Arquitetura do Sistema. Para construir a arquitetura foram levadas em consideração as seguintes definições:  Plataformas de desenvolvimento e frameworks: o back-end será

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

58

Após a construção da Arquitetura do Sistema e a descrição dos padrões a serem utilizados, são elaborados os diagramas de classes e sequência de cada componente do sistema. A Figura 4.12 mostra o diagrama de classe do componente ControleAcesso. Na Figura 4.13 é mostrado o diagrama de sequência para a operação EfetuarLogin.
ControladorControleAcesso +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.12–Diagrama de classes do componente ControleAcesso.

: FachadaWebservice

: IControleAcesso

: IContaInternet

1 : logar()

2 : existe()

4 : session

3 : true

Figura 4.13–Diagrama de Seqüência de Efetuar Login. Por fim, são construídos os diagramas de seqüência e de classe baseando-se no Protótipo da Interface Gráfica. A Figura 4.14 ilustra a construção das classes da

59

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

Figura 4.14–Construção da Interface Gráfica Desktop do QIB.
ComunicacaoWebService +logar() +chamarWebService()

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

IComunicacaoWebService

: TelaLogin : ClienteAtor 1 : efeturarLogin()

: ComunicacaoWebService

2 : logar() 3 : chamarWebService()

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

60

Capítulo 5 - Avaliação do Processo

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

5.2 Definição
Na fase de definição são definidos os objetivos do experimento, as questões a serem respondidas e as métricas relacionadas que devem ser

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

61

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

Framework de Medição

Variável de resposta

Qualidade de Projeto

Qualidades

Reusabilidade

Manutenibilidade

Fatores

Complexidade

Compreensibilidade

Modularidade

Estabilidade

Atributos

Tamanho

Acoplamento

Instabilidade

Métricas

WOCS

CBCS

IMSC

Figura 5.1–Framework de medição. As questões e as métricas utilizadas são apresentadas a seguir:

62

Questão 1: O processo de desenvolvimento gera serviços e componentes de baixa complexidade? Dependências estruturais entre os serviços e componentes

(relações cliente-consumidor) têm influência considerável sobre a complexidade dos sistemas. Por isso, a métrica a seguir foi utilizada para ajudar a responder a questão 1:  Métrica 1 (M1): Weighted Operations per Component or Service (WOCS). Métrica utilizada para medir a complexidade de componentes e serviços utilizada em [22]. A quantidade e complexidades das operações de um componente ou serviço são diretamente relacionadas ao tempo e esforço necessários para desenvolvê-los e mantê-los. Assim, as WOCS medem a complexidade do serviço ou componente, em termos de suas

operações (métodos) que serão utilizados por outros serviços ou componentes. Considere um componente (ou serviço) C com operações O1,...,On. Onde c1,..., cn são as complexidades das operações. Então:

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

Questão 2. O processo de desenvolvimento gera serviços e componentes estáveis? Uma única mudança pode encadear mudanças em cascata nos componentes e serviços de uma aplicação. Tornando a arquitetura frágil, dificultando o

desenvolvimento e o reuso. Por isso, a métrica a seguir foi utilizada para ajudar a responder a questão 2:

63

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

De acordo com [41] quanto mais próximo de 0, mais estável é o serviço. Se o IMSC = 1, o serviço é muito instável e difícil de manter.

Questão 3: O processo de desenvolvimento gera serviços e componentes com baixo grau de acoplamento? O baixo grau de acoplamento entre os componentes e serviços de uma aplicação indica uma arquitetura modular. Aplicações modulares potencializam benefícios em vários aspectos: velocidade no desenvolvimento, redução de custo no

desenvolvimento, flexibilidade e reusabilidade. Por isso, a métrica 3 foi utilizada para ajudar a responder a questão acima:  Métrica 3 (M3): Coupling Between Components or Services (CBCS). Esta métrica é calculada baseando-se no número de relacionamentos dos componentes ou serviços:

64

Seja n o número de serviços da aplicação, então está conectado ao serviço , caso contrário

se o serviço . Para um serviço A

não

quanto maior o CBCS, maior o acoplamento com outros serviços. Está métrica foi utilizada em [22]. Valores maiores que seis indicam alto grau de acoplamento [41]. Questão 4: Os participantes tiveram dificuldade em entender e aplicar o processo? A fim de compreender as dificuldades que os participantes irão enfrentar durante a adoção do novo processo, eles serão solicitados a informar as dificuldades enfrentadas ao final da fase de execução. Para ajudar a responder a esta questão, a métrica a seguir foi definida:  Métrica 4 (M4): Dificuldade em utilizar o processo: Porcentagem dos participantes que acharam o processo difícil. Métrica que mede a dificuldade de aplicação e entendimento do processo. Esta métrica foi baseada na avaliação do processo proposto no trabalho [9].

Questão 5: O processo ajuda a alinhar o entendimento entre os stakeholders? Com o intuito de avaliar se o processo ajuda no alinhamento do entendido entre os envolvidos no projeto foi criada a métrica 5:  Métrica 5 (M5). Alinhamento entre os stakeholders: Porcentagem dos participantes que concordaram que o processo ajuda no alinhamento de entendimento entre os stakeholders.

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

65

M6.

Desacoplamento

entre

front-end

e

back-end:

Porcentagem

dos

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

As métricas M1, M2 e M3 também fazem parte do framework de métricas utilizado em [22]. A M4 foi baseada em [9]. M5 e M6 foram baseadas em experiência prática, senso comum e definidas especificamente para avaliação deste trabalho.

5.3 Planejamento
O experimento foi conduzido na disciplina Análise e Projeto de Sistemas do Centro de Informática da UFPE9 no segundo semestre de 2010 (agosto até dezembro). Foi um experimento off-line (não foi aplicado na indústria) e todos os participantes eram graduandos dos cursos de Ciência da Computação e Engenharia da Computação a partir do sexto período. Para coletar as métricas quantitativas (M1, M2 e M3) foram utilizados as seguintes ferramentas de modelagem: StarUML10, Rational Software Architect11 e JUDE12. Para coletar as métricas qualitativas (M4, M5 e M6) foi utilizado o questionário de perguntas e resposta mostrado no Apêndice A. A avaliação do experimento foi feita baseando-se nas seguintes hipóteses: Hipóteses nulas. As hipóteses nulas (H0) são as que o experimento quer rejeitar fortemente: H0a: μ WOCS ≥ 10 H0b: μ CBCS ≥ 6 H0c: μ IMSC ≥ 0,5 H0d: μ Dificuldade em utilizar o processo >=30 % H0e: μ Alinhamento entre os stakeholders <=70 %
9

Página da disciplina: www.cin.ufpe.br/~if678 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 %

Hipóteses alternativas. As hipóteses alternativas (H1) são as hipóteses contrárias às hipóteses nulas e que o experimento espera aceitar: H1a: μ WOCS < 10 H1b: μ CBCS <6 H1c: μ IMSC <0,5 H1d: μ Dificuldade em utilizar o processo <30 % H1e: μ Alinhamento entre os stakeholders >70 % H1f: μ Desacoplamento entre front-end e back-end >70 %

As hipóteses referentes às métricas WOCS, CBCS e IMSC foram as mesmas definidas e utilizadas em [22], a dificuldade em utilizar o processo foi baseada em [9], as demais foram definidas e utilizadas pela primeira vez neste trabalho. A seguir será mostrada a validade do experimento:  Validade Interna: a validade interna é definida como a capacidade de um novo experimento de repetir o comportamento do atual, com os mesmos temas e objetos com os quais ele foi executado. Neste caso, a validade interna deste experimento depende da quantidade de participantes, pois deve ter no mínimo um grupo com três integrantes.  Validade externa: a validade externa define as condições que limitam a habilidade de generalizar o experimento. A quantidade e diversidade de projetos desenvolvidos se mostraram suficientes para que o experimento possa ser aplicado em diferentes domínios.  Validade de conclusão: a validade de conclusão é relacionada à habilidade do experimento em chegar a uma conclusão. Neste caso, o experimento feito é válido, pois pode se chegar às conclusões desejadas através de uma análise matemática simples que será mostrado na próxima seção. Por fim, as seguintes ameaças à validade do experimento foram identificadas e tratadas:

67

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

Experiência dos participantes. Os resultados podem ser influenciados pela falta de conhecimento e experiência prática dos participantes, pois todos eram alunos de graduação e a maioria não tinha experiência profissional no desenvolvimento de software. Para contornar essa ameaça foram ministradas aulas práticas para auxiliar e treinar os participantes no desenvolvimento dos projetos.

Complexidade e formato dos projetos. Os projetos foram propostos pelos participantes e não chegaram a ser implementados. Isso pode influenciar negativamente as métricas M1,M2 e M3. Para mitigar essa ameaça foram definidos requisitos mínimos (número de casos de uso, interação com sistemas externos, por exemplo) para a elaboração dos projetos.

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

13

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

68

Projetos 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

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

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

14 15

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

69

Projetos média 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 métrica CBCS.

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

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

70

o processo contribui significantemente para a redução da complexidade dos componentes e serviços desenvolvidos. A Tabela 5.4 mostra os resultados obtidos, levando-se em consideração a instabilidade dos componentes e serviços projetados. Projetos média 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 métrica IMSC.

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

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

71

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

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

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

72

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

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

73

Dificuldades na fase Projetar Serviços: 32% dos participantes do experimento acharam a fase Projetar Serviço difícil e 36% tiveram dificuldade em produzir os artefatos. Estes dados indicam que a fase pode estar complexa e ou o material de treinamento não foi adequado.

Comparação com outras abordagens: Para melhorar a avaliação do processo, os participantes poderiam ter sido expostos aos dois processos e ao final poderia ter sido feita uma análise mais completa com a comparação dos resultados. Também poderiam ter sido expostos a outros processos SOA/MDD e não o RUP. Isso não foi feito devido às restrições de tempo e escopo da disciplina.

Avaliação da métrica M5: Para avaliar o alinhamento de entendimento entre os stakeholders, os participantes das outras equipes foram incentivados a fazer perguntas e questionamento aos outros grupos, para de fato compreender como iria funcionar os projetos das outras equipes. Contornando assim o fato de todos os participantes estarem na mesma ―ponta‖ do alinhamento.

Validade do questionário e das métricas M4: A métrica M4 é altamente dependente da experiência dos participantes do experimento e do tamanho do projeto das equipes, por isso os resultados obtidos possuem pouco valor para se tecer análises que o generalizem.

74

Capítulo 6 - Conclusão

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

6.1 Principais contribuições
O processo é sistemático, fácil de usar e compreender, independente de ferramentas e tecnologias, e foi capaz de resolver problemas práticos como: a integração de aplicações, o acoplamento entre front-end e back-end dos sistemas, e o desalinhamento de expectativas entre os stakeholders. Como principais contribuições deste trabalho, podemos destacar: 1. Definição de um processo sistemático para projeto arquitetural de software dirigido a modelos e orientado a serviços, proporcionando:

75

o

Aumento na reutilização de software: Nas primeiras fases do processo é possível identificar oportunidades de reuso. Como forte indício para comprovar o aumento no reuso, em todos os projetos do experimento foram identificados um ou mais serviços com alto grau de reutilização (serviços utilitários).

o

Projeto de arquiteturas modulares e estáveis: Seguindo as atividades do projeto é possível projetar uma arquitetura modular e com componentes desacoplados. Como forte indício para comprovar isso, a média CBCS nos projetos foi 2,69 (indica baixo grau de acoplamento entre os componentes) e a média IMSC foi 0,34 (indica estabilidade).

o

Alinhamento no entendimento entre os stakeholders. Os dados obtidos no estudo experimental indicam que o processo ajuda a alinhar as expectativas entre os envolvidos no projeto, pois 100% dos participantes responderam um questionário concordando que o processo contribui para o alinhamento do entendimento entre todos os stakeholders.

o

Praticidade e facilidade de uso: A maioria dos participantes concordou que, no geral, o processo é fácil (27%) ou razoável (59%) e apenas 14% considerou o processo difícil. Além disso, o processo

utiliza conceitos, fundamentos, artefatos e modelos bastante utilizados tanto na indústria como na academia. o Avaliação através de um estudo experimental. O processo foi avaliado em um estudo experimental envolvendo 19 alunos de graduação da UFPE e executado em cinco projetos distintos.

6.2 Trabalhos Relacionados
Devido a grandes esforços na pesquisa e aplicação de MDD e SOA nos últimos anos, alguns trabalhos também tem investigado suas complementaridades e vantagens de uso em conjunto. Por exemplo, Castro et al.[69] apresentou SOD-M, uma abordagem de desenvolvimento orientada a serviço para a construção de sistemas de informações. Na abordagem apresentada, os modelos de composição de

76

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

desenvolvimento de sistemas de informação baseado em MDA. A fim de obter uma melhor compreensão quanto às vantagens e limitações expostas neste trabalho, foi realizada uma análise comparativa do processo proposto e dos trabalhos relacionados mencionados anteriormente. A Tabela 6.1 mostra o resultado dessa análise.

77

Precisão 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 genérico

Domínio restrito

Arquitetura Independente Suporte a vinculada às de ferramentas decicões transformações e tecnologias arquiteturais

baixa alta médio baixa médio alta alta

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

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

sim não sim sim sim sim não

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

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

Tabela 6.1. Resultados da análise.

A análise mostrada na Tabela 6.1 foi feita de acordo com os critérios apresentados em [74], adicionando as limitações e deficiências encontradas em algumas metodologias mostradas na introdução:    Precisão do processo: se o processo é detalho o suficiente para ser efetivamente seguido pelas pessoas envolvidas no projeto. Cobertura do ciclo de vida genérico: a metodologia abrange as fases e atividades do clico genérico de desenvolvimento de software. Domínio restrito: o escopo dos projetos e domínios para os quais a metodologia é aplicável. Algumas metodologias propostas não são de uso geral o suficiente ou não foram avaliada em vários domínios (é o caso do processo proposto).   Arquitetura vinculada às transformações: se a arquitetura final do sistema é atrelada às transformações automáticas dos modelos. Independente de tecnologias ou ferramentas: se o processo depende de ferramentas para ser executado completamente ou se é vinculado a uma tecnologia de desenvolvimento específica (web services, por exemplo).  Suporte a decisões arquiteturais: se o processo fornece suporte a importantes decisões arquiteturais ou delega essas decisões aos

programadores ou ferramentas de automação.

78

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

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

79

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

80

Bibliografia

1. The Standish Group. Disponível em http://www.standishgroup.com/, março 2011. 2. CHAOS Summary 2009. Disponível em http://www.standishgroup.com/newsroom/ chaos_2009.php , maio 2009. 3. George Stepanek. Software Project Secrets: Why Software Projects Fail. Apress, 2005 4. From Stakeholders to Models: It Is All a Matter of Viewpoints. Disponível em http://msdn.microsoft.com/pt-br/library/bb447667(en-us).aspx, março 2011. 5. Proof-of-Concept Design. Disponível em us/library/cc168618.aspx, março 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. Disponível 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, São Carlos, São Paulo.

81

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

82

28. AxureSample Projects. Disponível http://www.axure.com/sampleProjects.aspx, março 2011.

em

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

83

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

84

60. Soley, R. (2000, 11 27). Model Driven Architecture. Retrieved from Object Management Group: http://www.omg.org/mda 61. ORMSC, A. B. (2001, 07 09). Model Driven Architecture - A Technical Perspective. Retrieved from Object Management Group: http://www.omg.org/mda 62. Agile Modeling: User Interface Flow. Disponível em http://www.agilemodeling.com/artifacts/uiFlowDiagram.htm, julho 2011. 63. Alvaro, Alexandre. Software component certification: a component quality model. Recife, 2005. 124p. Dissertação de Mestrado – Centro de Informática, Universidade Federal de Pernambuco. 64. J. Sametinger, Software Engineering with Reusable Components, 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 Atualização em Informática (JAI), 2004 67. López-Sanz, M.; Vara, J.; Cuesta, C.: A Model-Driven Approach to Weave Architectural Styles into Service-Oriented Architectures Proceeding of the first international workshop on Model driven service engineering and data quality and security, 2009 68. Fabio Perez Marzullo, Jano Moreira de Souza, José Roberto Blaschek: A Study Case on Domain-Driven Development, Using MDA, SOA and Web Services. SERVICES I 2008:93-94 69. Valeria de Castro, Esperanza Marcos, Roel Wieringa: Towards a 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., García-Rodríguez de Guzmán, I.; Piattini, M.: ―MINERVA: Model drIveN and service oriented framework for the continuous business processes improvement & related tools‖,5th Int. Workshop on Engineering SO Applications (WESOA’09),Nov. 2009 72. Haeng-Kon Kim, Roger Y. Lee: MS2Web: Applying MDA and SOA to Web Services. Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing 2008:163-180 73. López-Sanz, M.; Acuña, C,J..; Cuesta, C.;Marcos, E.: Defining 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. Disponível em http://www.eclipse.org/epf/, julho 2011.

86

Apêndice A

PARTE 1

SOBRE OS PARTICIPANTES (10 MINUTOS)

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

Curso:

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

Em quantos projetos profissionais (envolvendo clientes reais) você já participou de acordo com as seguintes categorias (preencher com números):

___ projetos de baixa complexidade (menos de seis meses). ___ projetos de média complexidade (entre seis meses e um ano). ___ projetos de alta complexidade (mais de um ano). Em quantos projetos acadêmicos você já participou de acordo com as seguintes categorias:

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

87

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

___ Projetos acadêmicos ___ Projetos profissionais Em quantos projetos orientados a serviços você já participou

___ Projetos Acadêmicos ___ Projetos profissionais

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

( ) Nenhuma ( ) Baixa ( ) Média ( ) Alta Antes de começar o curso, como você definiria a sua experiência em SOA?

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

Quantos documentos de requisitos e casos de uso você já escreveu ou participou de revisões?

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

88

PARTE 2

SOBRE O PROCESSO (30 MINUTOS)

No geral, como você classificaria o processo?

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

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

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

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

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

89

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

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

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________

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

( (

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

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________ Na fase de Especificação do Modelo de Negócio, achou os artefatos gerados úteis?

( (

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

_____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________

90

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

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

Na fase de Analisar Serviço, teve dificuldade em entender as atividades? ( ( ) Não ) Sim. Por favor, indique os artefatos e justifique?

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________

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

( (

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

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ ____________________________________________________________________

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

( (

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

_____________________________________________________________________ _____________________________________________________________________

91

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

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

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

( (

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

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

( (

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

_____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________

92

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

( (

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

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

programadores, arquitetos, designer, clientes)?

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

Você concorda que o processo é útil para construção de uma arquitetura desacoplada entre front-end e o back-end?

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

Como você classificaria as aulas sobre o processo:

( ) Muito ruim

93

( ) Ruim ( ) Satisfatória ( ) Bom ( ) Muito Bom Você gostaria de cursar a disciplina de Tópicos Avançados em Análise e Projeto de sistemas com seminários mais detalhados sobre SOA e MDE e projetos de sistemas até a codificação?

( ) Sim ( ) Não

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

94

Apêndice B

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

Caso de uso: Efetuar Login

Descrição: Este caso de uso é responsável por autenticar um usuário do sistema. Pré-condição: nenhuma Pós-condição: um usuário válido é logado e sua sessão é registrada no sistema. Fluxo principal 1. O cliente informa login e senha. 2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e senha pertencem a uma conta). 3. O sistema registra o início de uma sessão de uso. Fluxos secundários - No passo 2, se o login e a senha forem inválidos, o sistema exibe uma mensagem e volta ao passo 1.

95

Caso de Uso: Alterar Senha

Descrição: Este caso de uso é responsável por alterar a senha de um usuário do sistema. Pré-condição: O cliente da conta deve ter efetuado login. Pós-condição: senha do usuário alterada Fluxo principal: 1. O cliente informa login, senha antiga e a nova senha. 2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e senha pertencem a uma conta). 3. O sistema altera a senha do usuário com a nova senha Fluxos secundários - No passo 2, se o login e a senha forem inválidos, o sistema exibe uma mensagem e volta ao passo 1.

96

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

Pré-condição: O cliente depositante deve ter efetuado login. Pós-condição: O saldo atual do cliente é debitado deste valor , o qual é creditado na conta informada como destinatária. Fluxo principal:

1.O cliente escolhe a opção de transferência e informa o valor a ser transferido e a conta para depósito. 2.O sistema recupera a conta bancária do cliente (que já efetuou o login anteriormente) e a conta para depósito. 3.O sistema debita o valor da conta do cliente e credita na conta destinatária.

Fluxos secundários - No passo 2, se a conta bancária do cliente não tiver saldo suficiente, sistema exibe uma mensagem de aviso e volta ao passo 1.

97

Caso de Uso: Efetuar Pagamento Qualiti Card

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

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

Pós-condição: O valor do pagamento é debitado da conta do cliente, o pagamento é enviado à operadora do cartão de crédito e a transação é registrada no sistema. Fluxo Principal:

1. O cliente informa os dados necessários para efetuar o pagamento do cartão: - O código de barras da fatura que deseja efetuar o pagamento. - O valor que deseja pagar.

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

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

4. O sistema debita da conta do cliente.

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

6. O sistema registra a transação de pagamento e emite um comprovante da mesma para o usuário. A transação registrada contém os dados da conta do cliente, o código de barras da fatura, data, hora e valor do pagamento. Fluxos Secundários:

98

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

Caso de uso: Consultar Saldo

Descrição: Este caso de uso é responsável por consultar o saldo da conta bancária do cliente. Pré-condição: O cliente deve ter efetuado login. Pós-condição: nenhuma. Fluxo principal 1. O cliente seleciona a opção de consulta de saldo 2. O sistema recupera o saldo atual da conta bancária do cliente 3. O sistema exibe o valor do saldo e a data atual Fluxos secundários - Não tem.

99

Caso de uso: Consultar Cheques

Descrição: Este caso de uso é responsável por consultar os cheques emitidos pelo cliente. Pré-condição: O cliente deve ter efetuado login. Pós-condição: nenhuma. Fluxo principal 1. O cliente seleciona o período referente a consulta (data inicial e data final) 2. O sistema recupera todos os cheques compensados na conta do cliente 3. O sistema exibe uma lista com a data, hora e o valor de cada cheque compensado Fluxos secundários - No passo 1, se o cliente informar uma período inválido, sistema exibe uma mensagem de avise e volta ao passo 1.

100

Caso de uso: Consultar Extrato

Descrição: Este caso de uso é responsável por consultar o extrato da conta bancária do cliente. Pré-condição: O cliente deve ter efetuado login. Pós-condição: nenhuma. Fluxo principal 1. O cliente seleciona o período referente ao extrato (data inicial e data final) 2. O sistema recupera todas as transações realizadas na conta do cliente 3. O sistema exibe uma lista com a data, hora e o valor de cada transação Fluxos secundários - No passo 1, se o cliente informar uma período inválido, sistema exibe uma mensagem de avise e volta ao passo 1.

101