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.

Transcrição

1 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 RECIFE, AGOSTO/2011

2 UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO VÍTOR TORRES BRAGA Um Processo para Projeto Arquitetural de Software Dirigido a Modelos e Orientado a Serviços ESTE TRABALHO FOI APRESENTADO À PÓS- GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO TÍTULO DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO. ORIENTADOR: AUGUSTO SAMPAIO CO-ORIENTADOR: VINICIUS CARDOSO GARCIA RECIFE, AGOSTO/2011

3 iii

4 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

5 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

6 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

7 Índice Capítulo 1 - Introdução Contexto Principais Contribuições Fora do Escopo Organização da Dissertação... 6 Capítulo 2 - Conceitos e Fundamentos Introdução MDD Model Driven Development Vantagens e Desvantagens MDA Model Driven Architecture SOA Vantagens e Limitações SoaML Simple Interfaces Service Interface Service Contract Service Architecture 25 Capítulo 3 - O Processo Introdução Especificar Modelo de Negócio Analisar Serviços Projetar Serviços Capítulo 4 - Instanciação e Execução do Processo Introdução Qualiti Internet Banking vii

8 4.3 Especificar Modelo de Negócios Analisar Serviços Projetar Serviços Capítulo 5 - Avaliação do Processo Introdução Definição Planejamento Operação Coleta e Análise dos Dados Lições Aprendidas Capítulo 6 - Conclusão Principais contribuições Trabalhos Relacionados Limitações e Trabalhos Futuros Considerações Finais Bibliografia 81 Apêndice A 87 Apêndice B 95 viii

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

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

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

12 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

13 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 Factories 1 da 1 2

14 Microsoft, MDA 2 (Model-Driven Architectue) da OMG e EMF 3 (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;

15 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

16 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

17 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

18 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

19 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

20 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

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

22 Comunicação: os profissionais envolvidos no projeto poderão se comunicar de forma mais efetiva, pois os modelos são mais abstratos e fáceis de entender do que o código, não exigindo conhecimento técnico de uma tecnologia específica. Por isso, especialistas poderão participar ativamente e utilizar diretamente os modelos para identificar os conceitos relativos ao problema. Corretude: os geradores de código não introduzem erros banais como erros de digitação, portanto a identificação de erros conceituais acontece em um nível de abstração mais alto, tornando-se, teoricamente, mais fáceis de resolver. Em resumo, as vantagens relacionadas ao uso de MDD estão diretamente relacionadas à capacidade de evitar que os desenvolvedores executem tarefas repetitivas que podem ser desempenhadas pelas transformações. E, diferente de outras abordagens de desenvolvimento de software, com mecanismos de transformações automáticas seria mais produtivo construir os sistemas em um nível de abstração alto, pois isso possibilitaria não só o reuso de componentes de software, mas também a reutilização de conhecimento [56]. 2.3 MDA Model Driven Architecture Model-Driven Architecture é uma abordagem de desenvolvimento de software orientado a modelos elaborado pelo Object Management Group (OMG), organização internacional que define padrões abertos para aplicações orientadas a objetos. O termo Model-Driven Architecture (MDA) foi mencionado pela primeira vez em 2000 em um artigo publicado pela OMG [60]. Posteriormente, a OMG decidiu montar uma equipe de arquitetos para elaborar uma definição formal de MDA que foi publicada em 2001 [61]. Esta era uma versão formal, mas incompleta que foi sendo aprimorada e, em 2003, foi publicada uma versão mais detalhada e que foi aprovada pelo grupo. De acordo com a OMG, MDA é um pequeno passo para transformar a arte de desenvolvimento de software em uma disciplina de engenharia. Resumindo, MDA define uma abordagem para: Especificar o sistema independentemente da plataforma que irá executar; Especificar plataformas de execução de sistemas; 11

23 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

24 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

25 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

26 Class instace of instance of UML Class name: String UML Atribute name: string instace of Video title: string instance of a:video instace of title = "Casa Blanca" Figura 2.4 Níveis de modelagem em MDA. O nível M0 define os modelos executáveis do sistema. O nível M1 descreve as abstrações no domínio do sistema que são usadas no nível M0. O nível M2 descreve os meta-modelos usados em M2 e, em M3, são definidas as metas-linguagem utilizadas em M 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

27 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

28 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

29 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 Vantagens e Limitações [7]: Seguem alguns benefícios em utilizar uma arquitetura orientada a serviços [46] [47] 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

30 Serviços com granularidade grossa: dependendo do tamanho e complexidade das aplicações, testar e validar todas as combinações de todas as condições de um serviço complexo pode se tornar impossível. Se um serviço altamente genérico for utilizado por dezenas de outros, a sua otimização pode ser uma tarefa muito difícil. Acoplamento fraco: é o sonho de todo arquiteto projetar um sistema distribuído altamente desacoplado, mas adicionar novas funcionalidades com um alto nível de complexidade pode se tornar um pesadelo. Integração: integração de serviços pode ser uma tarefa complexa, especialmente quando há uma falta de pessoas qualificadas para trabalhar com tecnologias SOA. Diversidade de tecnologias e fabricantes: leva-se tempo para aprender e usar novas tecnologias. Existem muitas tecnologias e ferramentas SOA disponíveis no mercado que são atualizadas constantemente. Portanto, custa tempo e dinheiro treinar e manter uma equipe atualizada. 2.5 SoaML SoaML (Service Oriented Architecture Modeling Language) é uma especificação da OMG que descreve um profile UML e metamodelos para projetar sistemas SOA. O principal objetivo de SoaML é dar suporte ao projeto de serviços em abordagens de desenvolvimento de software dirigidas a modelo. Com SoaML é possivel modelar requisitos, especificar serviços de sistemas, especificar interface de serviços e projetar os serviços internamente. Os sistemas são modelados na visão de provedores e consumidores de serviços. Os consumidores e provedores de serviços podem ser pessoas, organizações e outros sistemas, em SoaML ele são chamados de participantes. O conceito-chave em SoaML é, naturalmente, o de serviço. Serviço é definido como a entrega de valor para outro parte (consumidor) por meio de uma ou mais capacidades [29]. O acesso ao serviço é feito através de um contrato que definine as politicas e restrições que devem ser obedecidas. Um serviço é fornecido por um 19

31 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

32 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

33 consumidora. Quando usada como << Service >> a interface é provedora e deve entregar a resposta em uma porta compatível 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

34 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

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

36 (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 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

37 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

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

39 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

40 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

41 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

42 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

43 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

44 conforms To MOF conforms To conforms To UML2 MM extends GuiProfile UML MM 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

45 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

46 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

47 Pacote 2 UC3 UC 5 UC 4 Pacote 1 UC 1 Ator 1 Ator 2 UC2 <<Service Contract>> Pacote1 <<Service Contract>> UC5-Ator2 consume provide consume provide <<Participant>> Ator1 consume <<Service Contract>> Pacote2 provide <<Participant>> Sistema <<Participant>> Ator2 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

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

49 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

50 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

51 <<Service Contract>> Pacote1 <<Service Contract>> UC5-Ator2 consume provide consume provide <<Participant>> Ator1 consume <<Service Contract>> Pacote2 provide <<Participant>> Sistema <<Participant>> Ator2 consume provide <<Service Contract>> UC5 Arquitetura de Serviços <<Service Contract>> Service E1 Serviço de Entidade Componente 1 ComponenteE1 IService1 IServiceE1 Compoente A Componente 2 IServicec2 Componente 4 Componente 3 IServicec4 IService3 Figura 3.11 Construção do Modelo de Componentes de Serviços. Conforme ilustrado na Figura 3.11, participante Ator1 foi mapeado no Componente A e os contratos de serviços: <<Service Contract>> Pacote 1 deu origem ao IService1 e Componente1 <<Service Contract>> Pacote 2 deu origem ao IService2 e Componente1 <<Service Contract>> UC5 deu origem ao IService4 e Componente4 40

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

53 conforms To MOF conforms To conforms To UML2 MM SoaMLProfile MM extends instance Of instance Of 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

54 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

55 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 Componente 4 IServiceContrac2 Componente 2 IServiceContrac1 Componente 1 Componente 3 IServiceContrac3 Figura 3.15 Exemplo de Arquitetura do Sistema. 44

56 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

57 Padrões de Arquitetura Transformação PIM- PIM 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

58 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

59 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

60 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

61 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

62 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 Modelo de Funcionalidades ClienteAtor Operadora de Cartão 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

63 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

64 Controle Conta Controle Qualit Card Controle de Acesso Modelo de Funcionalidades ClienteAtor Operadora de Cartão <<Service Contract>> ControleAcesso <<Service Contract>> OperadoraCartao consumer provider consumer provider <<participant>> Cliente Front-end consumer <<Service Contractt>> ControleConta provider <<participant>> Sistema back-end <<participant>> Operadora Cartão consumer <<Service Contract>> ControleQualitiCard consumer 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

65 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) sessão ContaInternet alterar(login,antiga, nova) existe(login,senha) ContaInternet atualizar(containternet) sessão Conta Internet Figura 4.8 Modelo de Interação de Serviço do QIB. Conforme as regras descritas no capítulo anterior, o MIS relacionado ao contrato de serviço ControleAcesso, mostrado na Figura 4.8, contém as interfaces IControleAcesso, IContaInternet e o consumidor Client Front-end. As mensagens entre os elementos foram adicionadas de acordo com a descrição dos casos de uso relacionados ao contrato de serviço Controle Acesso (Efetuar Login e Alterar Senha descritos no Apêndice B). 54

66 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 IControleQualitCard Controle de Acesso Controle Conta Controle QualitCard IContaInternet ContaInternet IContaBancaria ContaBancaria ITransação Transação IOperadoraCartã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

67 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 Draw 4 com o plugin Cameo SOA+ 5 ou o Rational Software Archtect 6, 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 community 7 (antigo JUDE Community) ou o StarUML 8 (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?

68 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

69 Front-end Web Front-end Iphone Front-end Desktop IFachadaWebSercice WebService IControleAcesso IControleConta IControleQualitCard Controle de Acesso Controle Conta Controle QualitCard IContaInternet IContaBancaria ITransação IOperadoraCartão ContaInternet ContaBancaria Transação OperadoraCartão 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

70 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) ContaintInternet +login +senha IControleAcesso +logar(login, senha) +alterarsenha(login, senhaatual, SenhaNova) IContaInternet +inserir(containternet) +remover(containternet) +atualizar(containternet) +existe(login, senha) Figura 4.12 Diagrama de classes do componente ControleAcesso. : FachadaWebservice : IControleAcesso : IContaInternet 1 : logar() 2 : existe() 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

71 interface gráfica do sistema. Os diagramas de classe e sequência, simplificado, do front-end desktop do QIB são mostrados na Figura Figura 4.14 Construção da Interface Gráfica Desktop do QIB. TelaLogin +logintext: TextField +senhatext: TextField +logarbutton: JButton +efeturarloginr() IComunicacaoWebService ComunicacaoWebService +logar() +chamarwebservice() : TelaLogin : ComunicacaoWebService : ClienteAtor 1 : efeturarlogin() 2 : logar() 3 : chamarwebservice() Figura 4.15 Diagrama de Classe e seqüência do Desktop. 60