Arquitetura de Referência Para Aplicações Corporativas Web Utilizando Linguagem de Programação Java

Transcrição

1 ORGANIZAÇÃO SETE DE SETEMBRO DE CULTURA E ENSINO LTDA FACULDADE SETE DE SETEMBRO FASETE CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO EDSON ALVES DA SILVA Arquitetura de Referência Para Aplicações Corporativas Web Utilizando Linguagem de Programação Java Paulo Afonso-BA Junho 2010

2 I EDSON ALVES DA SILVA Arquitetura de Referência Para Aplicações Corporativas Web Utilizando Linguagem de Programação Java Monografia apresentada ao curso de Bacharelado em Sistemas de Informação da Faculdade Sete de Setembro FASETE. Sob a orientação do professor Msc. Igor Medeiros Vanderlei. Paulo Afonso-BA Junho de 2010

3 II FACULDADE SETE DE SETEMBRO FASETE. CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO Arquitetura de Referência Para Aplicações Corporativas Web Utilizando Linguagem de Programação Java BANCA EXAMINADORA Monografia apresentada ao curso de Bacharelado em Sistemas de Informação da Faculdade Sete de Setembro FASETE. Sob a orientação da professora Msc. Igor Medeiros Vanderlei. Prof. Igor Medeiros Vanderlei (Orientador) Membro convidado 1 Membro convidado 2 Paulo Afonso/ BA Junho 2010

4 III DEDICATORIA Dedico esse trabalho a todos que de alguma forma participaram para que ele fosse possível.

5 IV AGRADECIMENTOS Considerando esta monografia como resultado de uma caminhada que não começou na Fasete, agradecer pode não ser tarefa fácil, nem justa. Para não correr o risco da injustiça, agradeço de antemão a todos que de alguma forma passaram pela minha vida e contribuíram para a construção de quem sou hoje. Agradeço principalmente a meus pais, Maria e José, que sempre me orientaram e se esforçaram o máximo para que eu tivesse uma boa educação. A minha namorada Caline, pelo seu amor, compreensão, cumplicidade e paciência. E agradeço, particularmente, a algumas pessoas pela contribuição direta na construção deste trabalho: Ao meu professor, orientador e amigo Igor Medeiros por ser um guia na minha jornada do mundo acadêmico, servindo como referência por seu profissionalismo, conhecimentos e competência. Aos professores Ricardo e Juliana por suas competências e ensinamentos, fundamentais para minha formação. Aos meus colegas de graduação que estiveram comigo tanto nas atividades acadêmicas quanto nas farras, em especial Jhoni, Filipe, Juliana, Cássio, Jaime e Jadiael. Aos meus amigos de profissão, que dividem do meu entusiasmo pela tecnologia de informação, Igor Oliveira e Thiago Varjão. A Fasete Faculdade Sete de Setembro pela bolsa e oportunidade de trabalho concebida. Ao programa ProUni do governo, por arcar com todas as despesas da minha graduação. E por fim, para aqueles que direta ou indiretamente me ajudaram a desenvolver esse trabalho.

6 V Mata o tempo e matas a tua carreira" (Bryan Forbes).

7 VI SILVA, Edson Alves. Arquitetura de referência para Aplicações Corporativas Web utilizando Linguagem de Programação Java p. Monografia. (Bacharelado em Sistemas de Informação), FASETE Faculdade Sete de Setembro, Paulo Afonso-BA. RESUMO Há muito tempo a atividade de desenvolvimento de aplicações é estudada pela disciplina Engenharia de Software que propõe técnicas de abstração com objetivo de diminuir a complexidade envolvida neste processo. No entanto, para lidar com sistemas grandes e complexos, que exigem mais confiabilidade, desempenho e economia, é proposta uma disciplina específica denominada Arquitetura de Software. A disciplina atua na definição e documentação da arquitetura de uma aplicação, considerada uma atividade complexa, pode ser simplificada através da utilização de uma arquitetura de referência. Frente à demanda por sistemas corporativos, evolução tecnológica da plataforma web e quantidade de desenvolvedores para linguagem Java, o objetivo desta monografia é prover uma arquitetura de referência como solução para as dificuldades encontradas na definição da arquitetura de sistemas que atendam esta delimitação. A proposta da pesquisa está em inicialmente testar frameworks, escolhendo um conjunto conciso e integrável para compor a solução, em seguida descrever a arquitetura de referência utilizando o modelo de visões 4+1 views da RUP, estendendo aos padrões de projeto e frameworks escolhidos, e por fim validar a arquitetura de referência descrevendo a prática de seu uso em um projeto exemplo e a participação da solução no processo de desenvolvimento de software. Palavras Chave Arquitetura de Software, Arquitetura de Referência, Web, Java.

8 VII SILVA, Edson Alves. Arquitetura de referência para Aplicações Corporativas Web utilizando Linguagem de Programação Java p. Monografia. (Bacharelado em Sistemas de Informação), FASETE Faculdade Sete de Setembro, Paulo Afonso-BA. ABSTRACT Long ago the activity of application development is studied by the Software Engineering discipline that proposes abstraction techniques aiming to reduce the complexity involved in this process. However, to handle large, complex systems, which require higher reliability, performance and economy, we propose a specific discipline called Software Architecture. The course acts in the definition and documentation of the architecture of an application, considered a complex activity, can be simplified by using reference architecture. Faced with the demand for enterprise systems, technological platform and quantity of web developers to Java, the goal of this monograph is to provide reference architecture as a solution to the difficulties in defining the architecture of systems that meet this definition. The research proposal is to initially test frameworks, choosing a concise set integrable and to compose the solution, then describe the reference architecture using the model of visions of RUP 4 +1 views, extending the design patterns and frameworks chosen, and finally validate the reference architecture describing the practice of its use in a sample project and participation in the solution process of software development. Keywords - Software Architecture, Reference Architecture, Web, Java.

9 VIII LISTA DE ILUSTRAÇÃO Figura Arquitetura de Referência Figura Relacionamento entre Modelo de Referência, Estilo de Arquitetura e Arquitetura de Referência Figura Modelo de Visões 4+1 views Figura Relação entre os elementos de uma aplicação corporativa Figura Evolução da plataforma JEE Figura estilo Interativo de Arquitetura - MVC Tabela Comparação entre zk, GWT, Flex, Echo2 e OpenLaszlo Figura Definição das Camadas da Arquitetura de Referência Figura Visão Lógica - Camada de Apresentação Figura Visão Lógica do Zk Framework Figura Visão Lógica - Implementação da Camada de Apresentação Figura Visão Lógica Camada de Negócio Figura Visão Lógica - Implementação da Camada de Negócio Figura Visão Lógica - Implementação da Camada de Integração Figura Visão Lógica - Implementação da Camada de Persistência Figura Visão Lógica Camada de Segurança Figura Implementação das Camadas da Arquitetura de Referência Figura Diagrama de Classe Sistema de Controle de CD Figura SCC Sistema de Controle de CD Figura Mapeamento da classe Departamento utilizando HIbernate Figura Configuração do Spring - SpringContext.xml Figura Implementação da Classe DepartamentoDaoImp Figura Implementação da Classe AlteraSenhaController Figura Formulário em zk para Altera Senha Figura Configuração Spring Security ApplicationContext-Security.xml Figura Configuração Spring Security Formulário de Autenticação Figura Ambiente de desenvolvimento de relatório com BirtReport Figura Classe Java AdicionarNumeroImp Figura Configuração do Servlet do Web Service Adicionar Numero Figura Configuração do EndPoint do Web Service Adicionar Numero Figura Fases do processo unificado... 67

10 IX SUMÁRIO RESUMO... VI ABSTRACT... VII CAPÍTULO I CONSIDERAÇÕES INICIAIS CONTEXTUALIZAÇÃO JUSTIFICATIVA PROBLEMAS DE PESQUISA OBJETIVOS Geral Específico METODOLOGIA ORGANIZAÇÃO DO TRABALHO CAPÍTULO II CONCEITOS BÁSICOS ARQUITETURA DE SOFTWARE ARQUITETURA DE UMA APLICAÇÃO Modelo de Referência Estilo de Arquitetura Arquitetura de Referência Linha de Produtos Relação entre Modelo de Referência, Arquitetura de Referência e Estilo de Arquitetura Visões de Arquitetura APLICAÇÕES CORPORATIVAS Aplicações Corporativas na Plataforma Web Java para Web Model View Control (MVC) CAPÍTULO III ARQUITETURA DE REFERÊNCIA INTRODUÇÃO METODOLOGIA DO DESENVOLVIMENTO DA ARQUITETURA DESCRIÇÃO DA ARQUITETURA DE REFERÊNCIA Visão Lógica Camada de Apresentação Camada de Negócio Camada de integração Camada de Persistência... 49

11 X Camada de Segurança Implementação das Camadas Visão de Implementação Visão de Processos Visão de Implantação CAPÍTULO IV EXMPLO DE USO DA ARQUITETURA DE REFERÊNCIA INTRODUÇÃO FERRAMENTAS DEFININDO O SISTEMA A SER DESENVOLVIDO DETALHES DE IMPLEMENTAÇÃO Cadastro Permissão e Autenticação Relatórios Integração PARTICIPAÇÃO NO PROCESSO DE DESENVOLVIMENTO Fase de Concepção Fase de Elaboração e Construção Fase de Transição RESULTADOS CAPÍTULO V CONSIDERAÇÕES FINAIS TRABALHOS FUTUROS 72 REFERÊNCIAS... 73

12 CAPÍTULO I CONSIDERAÇÕES INICIAIS

13 C A P Í T U L O I C O N S I D E R A Ç Õ E S I N I C I A I S 12 1 CONSIDERAÇÕES INICIAIS Este capítulo apresenta a importância da arquitetura de referência para aplicações corporativas web utilizando linguagem de programação Java iniciando a partir da contextualização, seguido com a justificativa para a escolha do tema apresentado. Por fim, serão apresentados a definição do problema, metodologia utilizada, o objetivo geral e os específicos e a estrutura da monografia. 1.1 CONTEXTUALIZAÇÃO O desenvolvimento de software pode ser classificado como uma atividade complexa, pois diferente de projetos que geram bens materiais, os produtos gerados são puramente ideias. À medida que a complexidade do sistema aumenta, a tarefa de construir o software fica mais difícil. Por razão desta complexidade, segundo estudos da Stadish Group (2010), uma grande parte dos projetos de software apresenta algum tipo de problema durante o seu desenvolvimento. Empresas que desenvolvem software enfrentam dificuldades em estimar orçamento, manter o cronograma especificado e entregar um produto que atenda às necessidades do cliente com um número mínimo ou controlável de defeitos. Como forma de contornar esta situação, desde 1968, época da crise do software 1, a Engenharia de Software propõe aplicar técnicas da engenharia objetivando melhorar significativamente o desenvolvimento de software nas atividades de especificação, projeto e implementação. Segundo Sommerville (2003), sem esse conhecimento as áreas de transportes e telecomunicações não estariam no nível tecnológico atual. Contudo, o crescimento contínuo do tamanho dos sistemas tem requerido em conjunto sempre mais confiabilidade, economia e desempenho por parte dos 1 Época em que surgiram os computadores de terceira geração, o custo do hardware caiu e do software aumentou (DIJKSTRA, 1972).

14 C A P Í T U L O I C O N S I D E R A Ç Õ E S I N I C I A I S 13 desenvolvedores, que para obter os resultados desejados, que se resumem a baixo custo e maior qualidade, utilizam a disciplina Arquitetura de Software como forma de lidar com sistemas grandes e complexos. Segundo Flower (2006, pág. 24) a Arquitetura de Software é uma compreensão subjetiva de um projeto, compartilhada pelos desenvolvedores experientes. Esta compreensão compartilhada frequentemente se apresenta na forma dos componentes mais importantes do sistema e na interação entre eles. Frente ao que foi apresentado, a Arquitetura de Software tem o objetivo de auxiliar no processo de definição e documentação da arquitetura do sistema. Esta definição normalmente é uma atividade que exige muita pesquisa e teste, demandando custos e tempo. No entanto, visando facilitar a definição da arquitetura de um sistema, pode ser utilizada como ponto de partida uma arquitetura de referência. De acordo com Sommerville (2003, pág. 198): Uma arquitetura de referência representa uma arquitetura idealizada que inclui boa parte das características que o sistema pode incorporar, como um conjunto das melhores práticas arquiteturais e componentes que podem ser adotadas. Toda arquitetura de referência possui sua delimitação, pois existem diferentes tipos de software, cada qual com seus próprios desafios e complexidades. Portanto, os padrões de projeto e tecnologias da referência são definidos de acordo com o cenário que será utilizado a solução. A arquitetura de referência proposta neste trabalho foi direcionada ao desenvolvimento de software corporativos, que possuem características como: uso de banco de dados, quantidade elevada de dados, interação com vários usuários ao mesmo tempo e capacidade de comunicação com outros sistemas. Em seguida, esta arquitetura de referência será validada através do desenvolvimento de uma aplicação baseada na mesma, mostrando de maneira prática o desenvolvimento de software com os padrões e frameworks escolhidos para compor a solução.

15 C A P Í T U L O I C O N S I D E R A Ç Õ E S I N I C I A I S 14 Não há a intenção de criar uma arquitetura de referência mais recomendada, preferível ou adequada para algum tipo de projeto. Cabe ao desenvolvedor avaliar se esta referência está de acordo com os seus objetivos e sua forma de trabalho, podendo modificá-la livremente para torná-la compatível com os seus objetivos. 1.2 JUSTIFICATIVA A atividade de definição da arquitetura de um projeto demanda recursos. Nesta atividade é necessário testar a solução proposta, analisando se os requisitos não funcionais 2 foram atendidos. De acordo com Germoglio (2009) essas decisões são de vital importância para que os objetivos do projeto sejam alcançados. É essencial que tanto os atributos de qualidade, quanto técnicas e padrões de projeto arquitetural sejam devidamente decididos. Segundo Mendes (2004), o uso de uma arquitetura de referência para um projeto aumenta a produtividade, a qualidade e diminui os custos. Para escolha dessa referência se deve buscar um equilíbrio entre o atendimento de requisitos atuais e futuros. A definição de estruturas e mecanismos genéricos demais produz sistemas ineficientes e fora do prazo, enquanto a definição de estruturas e mecanismos específicos demais produz sistemas de manutenção e extensão difíceis. Por esse motivo, diante do crescente aumento do uso e desenvolvimento de sistema para plataforma web, a arquitetura de referência proposta neste trabalho será para aplicações corporativa web na linguagem Java, delimitando seu uso, evitando ser genérica ou específica demais. A delimitação da linguagem de programação para Java se baseia na sua grande utilização em projetos comerciais e quantidade de utilizadores, visto que, de acordo com o TIOBE (2010), o Java está há vários anos seguidos como linguagem de programação mais utilizada. Outro fator para escolha é a grande quantidade de 2 São os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas. Em geral, requisitos não funcionais podem constituir restrições aos requisitos funcionais. (L. Chung, B. A. Nixon, E. Yu and J. Mylopoulos, 1999)

16 C A P Í T U L O I C O N S I D E R A Ç Õ E S I N I C I A I S 15 frameworks 3 disponíveis para a linguagem, este possui o lado positivo de acelerar a evolução da tecnologia por motivo da concorrência e o lado negativo de dificultar a escolha de qual a ferramenta mais indicada para ser utilizada em cada projeto. 1.3 PROBLEMAS DE PESQUISA Diante das dificuldades encontradas no desenvolvimento de uma arquitetura de referência, surgiram alguns problemas como: Como validar uma arquitetura de referência para sistemas corporativo web? Como definir os elementos que farão parte da arquitetura de referência? Como organizar a ordem dos elementos da arquitetura de referência e as suas interações? Quais critérios a serem considerados ao escolher os frameworks e padrões de projetos que irão formar a arquitetura de referência? 1.4 OBJETIVOS Geral Apresentar uma proposta de uma arquitetura de referência para aplicações corporativas web utilizando linguagem de programação Java Específico Estudar conceitos da disciplina Arquitetura de Software; Pesquisar e testar frameworks, com a finalidade de definir quais serão utilizados na arquitetura de referência; Documentar a arquitetura de referência, estendendo aos frameworks e padrões de projeto escolhidos; 3 No contexto apresentado, se refere às ferramentas que auxiliam o desenvolvimento de software, provendo soluções para problemas semelhantes.

17 C A P Í T U L O I C O N S I D E R A Ç Õ E S I N I C I A I S 16 Desenvolver um sistema que exemplifique o uso prático da arquitetura de referência. 1.5 METODOLOGIA A monografia foi elaborada através de pesquisas bibliográficas e trabalhos publicados que serviram de embasamento teórico para o tema. Este material foi utilizado como forma de conhecer os diferentes pontos de vista sobre o mesmo assunto, bem como adquirir uma consistente base teórica sobre o tema. A pesquisa bibliográfica visou oferecer embasamento teórico sobre o tema abordado. Para maior embasamento da monografia foram utilizadas informações secundárias, como livros, revistas e sites especializados no tema com objetivo de mostrar a importância da pesquisa. Sendo assim, o aprofundamento sobre o tema foi obtido através destas informações sobre o assunto. Para recolher e reter os dados necessários para o desenvolvimento da solução, os frameworks estudados foram submetidos à prática de caixa cinza em laboratório, realizando testes a nível estrutural e de entrada e saída de dados. Ao final dos testes, os que proverem melhor suporte para a delimitação serão escolhidos como base da solução. 1.6 ORGANIZAÇÃO DO TRABALHO A presente monografia está organizada de maneira que proporcione ao leitor um fácil entendimento do trabalho como um todo e um conhecimento adequado do tema proposto. Os capítulos estão organizados como se segue: Capítulo 01 CONSIDERAÇÕES INICIAIS: Apresenta a introdução ao tema escolhido Arquitetura de Referência para Aplicações Corporativas Web Utilizando Linguagem de Programação Java, seguido da justificativa para a escolha do tema

18 C A P Í T U L O I C O N S I D E R A Ç Õ E S I N I C I A I S 17 apresentado. Em seguida, a definição do problema, metodologia utilizada e o objetivo geral e os específicos. Capítulo 02 CONCEITOS BÁSICOS: Este capítulo tem como objetivo apresentar de forma geral conceitos importantes para compreender o objetivo da pesquisa, este capítulo auxiliará na distinção dos conceitos: Arquitetura de Software, modelo de referência, estilos de arquitetura, arquitetura de referência e linha de produtos. Capítulo 03 ARQUITETURA DE REFERÊNCIA: Contém a descrição da solução, neste capítulo são apresentados os resultados da pesquisa, como quais frameworks e padrões foram utilizados para compor a arquitetura de referência logicamente. Capítulo 04 EXEMPLO DE USO: Neste capitulo é mostrada a solução de forma prática através de um sistema que usa a arquitetura de referência como base para sua arquitetura. Capítulo 05 - CONSIDERAÇÕES FINAIS: Este capítulo apresenta as conclusões obtidas durante o desenvolvimento deste trabalho e está organizado da seguinte forma: Introdução, Considerações Finais sobre o Trabalho Realizado e Trabalhos Futuros. Nas Referências consta o material pesquisado ao longo da realização deste trabalho.

19 CAPÍTULO II CONCEITOS BÁSICOS

20 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 19 2 CONCEITOS BÁSICOS Nas próximas seções serão abordados conceitos importantes para compreensão do tema, em especial arquitetura de referência, pois é comum o uso incorreto deste conceito, quase sempre confundido com os conceitos de modelo de referência ou linhas de produto. 2.1 ARQUITETURA DE SOFTWARE O objetivo da Engenharia de Software de acordo com Mendes (2004) é de empregar princípios de engenharia a fim de obter, a baixo custo, software que funcionem corretamente. Com a evolução da tecnologia de software, diversos paradigmas da engenharia e programação surgiram, normalmente utilizando técnicas de abstrações para reconhecer padrões, analisar e especificar sistemas. Contudo, paralelamente ao crescimento em escala dos sistemas de software, aumenta a preocupação com requisitos não funcionais, como desempenho, qualidade, confiabilidade, manutenção e disponibilidade. Estes requisitos estão associados à organização global dos sistemas de software, explanados na disciplina Arquitetura de Software, que será abordado ao longo desse texto. Até o momento deste trabalho não existe uma definição única sobre o que é Arquitetura de Software, essa discordância pode ser acompanhada no Software Engineering Institute s 4, onde são disponibilizadas várias definições do termo, estas são enviadas por pesquisadores da área. De acordo com Germoglio (2009) a importância de procurar definir de maneira clara e objetiva o que é Arquitetura de Software é relevante em três aspectos: 4 Site especialista na área de Arquitetura de Software.

21 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 20 Por eles serem explícitos em quando devemos aplicar conhecimentos de Arquitetura de Software. Por serem claros na separação de tarefas, algoritmos e estruturas de dados ou os elementos e organização do sistema como um todo, sendo em relação à estrutura do sistema, controle, comunicação, ou implantação. Por fim, por eles citarem que o processo de projeto da arquitetura precisa se preocupar com atributos de qualidade do sistema. Os aspectos acima apresentados, quando em conjunto, formam uma boa definição de Arquitetura de software. No entanto, estes aspectos não foram concebidos ao mesmo tempo, ao longo do tempo apenas um ou outro era considerado na definição proposta para a disciplina. Como forma de retratar a evolução desta definição, no texto a seguir será apresentado de forma linear definições da disciplina por diversos autores. Segundo Perry e Wolf (1992) a Arquitetura de Software pode ser representada pela fórmula Arquitetura de Software = elemento, organização, relações, onde específica que a Arquitetura de Software é um conjunto de elementos arquiteturais que possuem alguma organização. Os elementos e suas relações são definidos por decisões tomadas para satisfazer objetivos e restrições. A relação entre os elementos arquiteturais possuem propriedades e restringem como os elementos devem interagir de forma a satisfazer os objetivos do sistema. Adicionalmente, essas relações devem ser ponderadas de modo a indicar sua importância no processo de seleção de alternativas. A definição acima considera que a Arquitetura de Software é, de maneira sucinta, somente os elementos que compõe o sistema, não mencionando que a Arquitetura de Software também se refere às relações com o ambiente externo ou seus relacionamentos com outros sistemas. Passado alguns anos, Garlan e Shaw (1994) publicaram uma definição mais completa sobre o termo, onde é explicito que a Arquitetura de Software se torna

22 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 21 necessária quando o tamanho e a complexidade dos sistemas de software crescem. A definição menciona que o problema de se construir sistemas vai além da escolha dos algoritmos e estruturas de dados certos. Esse problema envolverá também decisões sobre as estruturas que formarão o sistema, qual estrutura global de controle será usada, protocolos de comunicação, sincronização e acesso a dados, atribuição de funcionalidade a elementos do sistema, ou ainda sobre distribuição física dos elementos do sistema. Além disso, o problema envolverá decisões que impactarão no comportamento do sistema em termos de escala e desempenho, entre outros atributos de qualidade. Nota-se que na definição acima, a Arquitetura de Software passou a ser mais importante na concepção do sistema, tendo participação ativa na qualidade do mesmo. A seguir é explanada uma definição de Arquitetura de Software mais atual: A arquitetura de um programa ou de sistemas computacionais são as estruturas do sistema, a qual é composta de elementos de software, as propriedades externamente visíveis desses elementos, e os relacionamentos entre eles (BASS et al, 2003, pág. 69). A definição acima trata todos os aspectos que uma Arquitetura de Software deve abranger, o que a torna uma das definições mais utilizadas no meio acadêmico e consequentemente nesta pesquisa. O conceito de Arquitetura de Software possui um nível de abstração alto para a tarefa de definição da arquitetura de uma aplicação, por este motivo a disciplina é composta de termos responsáveis por cada nível de abstração de uma arquitetura. Estes termos serão tratados nas seções a seguir. 2.2 ARQUITETURA DE UMA APLICAÇÃO A atividade de definição da arquitetura de uma aplicação deve levar em consideração vários termos utilizados na disciplina Arquitetura de Software, como:

23 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 22 modelo de referência, estilo de arquitetura, visão de arquitetura, arquitetura de referência e linha de produtos Modelo de Referência Um modelo de referência consiste de um conjunto mínimo de conceitos unificados, axiomas e relacionamentos com um domínio de um problema particular, e é independente de padrões específicos, tecnologias, implementações, ou outro detalhe concreto (LASKEY et al, 2006). Como uma ilustração do relacionamento entre um modelo de referência e as arquiteturas que podem derivar de tal modelo, pode ser considerado como exemplo o projeto de uma casa. Para este modelo, o que pode ser relevantes são conceitos como áreas de refeição, áreas de higiene e áreas de descanso, todos eles, de uma maneira geral, são importantes para entender o que pode vir a ser uma casa. Existe uma relação entre estes conceitos, e restrições sobre como eles são implementados Estilo de Arquitetura Segundo Mendes (2004) estilo de arquitetura caracteriza uma arquitetura de software de acordo com os componentes, mecanismos de interação e propriedades. São classes de arquiteturas semelhantes que possuem aspectos e componentes peculiares a elas, bem como as formas de combiná-las. Os estilos podem ser agrupados em categorias, de acordo com as similaridades entre eles, conforme descrito abaixo: Sistemas distribuídos: provê uma completa estrutura para aplicações distribuídas. Como exemplo, pode ser mencionado o padrão broker, que consiste em um componente que auxilia a coordenação da comunicação através de invocação remota de serviços. Sistemas interativos: utilizado por sistemas que tem como característica a interação homem-máquina. De acordo com Fowler (2006, pág. 40) a categoria pode

24 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 23 incluir os padrões Model View Controller (MVC) e Presentation Abstraction Control (PAC). Sistemas adaptáveis: oferece suporte para a extensão e adaptação de aplicações a tecnologias e mudanças de requisitos funcionais. Inclui os padrões Reflexão (ou Reflection) e Micro-núcleo (ou Microkernel). From mud to structure: de acordo com Fowler (2006) esta categoria oferece decomposição controlada das tarefas em subtarefas cooperativas. Antes de projetar um sistema, coletam-se os requisitos, transformando-os em especificações. Engloba os padrões Layers e Pipes and Filters Arquitetura de Referência Em qualquer modalidade de esporte é comum que atletas campeões sejam referência para os mais jovens, estes acreditam que aumentarão suas chances de sucesso ao se espelharem em atletas consagrados, certamente o talento conta muito, mas as chances de conseguir os objetivos aumentam quando se aprender com quem já superou o caminho para o sucesso. Com relação a software, uma aplicação possui mais chances de sucesso se sua arquitetura for definida utilizando uma arquitetura de referência como base. Segundo Sommerville (2006, pág. 198) uma arquitetura de referência representa uma arquitetura idealizada que incluem todas as características que o sistema pode incorporar, como um conjunto das melhores práticas arquiteturais que devem ser adotadas, sistematicamente, em todos os projetos de uma organização. De acordo com Wthreex (2002) a arquitetura de referência é basicamente um padrão ou conjunto de padrões de arquitetura predefinido, possivelmente parcial ou totalmente instanciado, projetado e testado em determinados contextos de negócios e técnicos. Ela faz parte da base de ativos reutilizáveis de uma organização e podem ser aplicados de forma geral ou para uma ampla classe de sistemas de domínios, ou ter um enfoque mais limitado, específico de domínio. Seu uso é uma maneira eficaz

25 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 24 de lidar com os vários requisitos não funcionais (particularmente os requisitos de qualidade). Segundo Rosato (2008) a arquitetura de referência consiste no conjunto de informações acessíveis a toda equipe de desenvolvimento e que proveem um conjunto consistente de boas práticas. Seu corpo pode conter informações vindas de diversas fontes: artefatos de projetos anteriores, princípios, metodologias, modelos conceituais, tecnologias, padrões de mercado, além dos próprios padrões corporativos. Portanto, a sua missão é prover um repositório de boas práticas arquiteturais que podem ser reusadas horizontalmente pela empresa, ao longo de todo ciclo de vida dos seus projetos de software, minimizando riscos e retrabalho. Figura Arquitetura de Referência Fonte: A figura acima representa os vários assuntos que serão discutidos na definição de uma arquitetura de referência. Espera-se que uma boa arquitetura de referência proporcione a aplicação um guia a tomada de decisões relacionada aos assuntos apresentados.

26 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 25 De acordo com a Confederação Nacional da Indústria (CNI) (2009) um projeto que não possui uma arquitetura de referência como base, não necessariamente vai falhar; ele vai demandar um esforço muito maior por parte da equipe de arquitetura no sentido de pesquisar, investigar e ponderar sobre as decisões arquiteturais. A menos que o sistema seja completamente sem precedentes, as arquiteturas de referência devem ser examinadas para fins de aplicabilidade (quanto ao domínio e ao tipo de desenvolvimento), caso elas existam e possam ser acessadas pela organização de desenvolvimento. A criação de arquiteturas de referência é uma questão a ser abordada no nível da organização Linha de Produtos Com referência a linha de produção da indústria manufaturada do final do século XIX, que propôs a padronização de etapas repetitivas da produção. A linha de produtos de software é uma maneira de tornar o processo de desenvolvimento mais produtivo. Para Clements e Northrop (2002) linha de produtos são sistemas que compartilhando um conjunto de características comuns e gerenciadas, que satisfazem as necessidades de um segmento particular de mercado ou missão, e que são desenvolvidos a partir de um conjunto comum de ativos principais e de uma forma preestabelecida. De acordo com Aguiar (2008) em uma linha de produtos, há uma arquitetura genérica que é comum a todos os produtos da linha, essa arquitetura é adaptada permitindo a criação de um produto particular. Por exemplo, o sistema operacional Windows Vista pode ser considerado uma linha de produtos, uma vez que ele possui várias versões com a mesma base arquitetural, que é alterada, adicionando-se ou removendo componentes, para permitir a geração das diversas versões. Cada produto da linha é definido a partir de uma seleção de features, que são atributos que caracterizam as funcionalidades do produto.

27 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 26 Um exemplo de feature em um sistema de compras on line poderia ser: adicionar produto no carrinho, finalizar compra. Features podem ser funcionalidades préimplementadas como controle de fraude ou permissão de usuários Relação entre Modelo de Referência, Arquitetura de Referência e Estilo de Arquitetura Nas seções anteriores foram expostos conceitos importantes que podem ser utilizados ao definir a arquitetura de uma aplicação. Esses conceitos foram vistos de forma individual, no entanto a tarefa de definição da arquitetura da aplicação exige que estes conceitos de alguma forma se relacionem a fim de tornar possível representar a arquitetura proposta de forma abstrata. De acordo com Bass et al (2003) os modelos de referência, estilos de arquitetura e arquiteturas de referências são utilizados para facilitar a definição da arquitetura de um sistema. A diferença entre modelo de referência, estilo de arquitetura e arquitetura de referência pode ser compreendida através da analise na figura a seguir: Figura Relacionamento entre Modelo de Referência, Estilo de Arquitetura e Arquitetura de Referência Fonte: Bass et al (2003) Na figura é mostrado que para se chegar à arquitetura do sistema a disciplina Arquitetura de Software propõe o uso de arquitetura de referências, que é

28 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 27 uma solução técnica, está por sua vez deve ser desenvolvida com base em um modelo de referência, que é responsável por agregar soluções aos problemas do ponto de vista de negócio, e um estilo de arquitetura, com o objetivo de apoiar decisões relacionadas as relações entre os elementos da arquitetura. É importante ressaltar que apesar da arquitetura de referência poder ser utilizada como base para a implementação, ela não contém regras de negócio específicas para um produto como as linhas de produto Visões de Arquitetura Tão importante quanto à definição da arquitetura é a documentação da mesma, no entanto existem vários perfis de profissionais envolvidos na atividade de desenvolvimento de um sistema, cada um com conjunto de habilidades, competências e interesses na arquitetura. No entanto, de acordo com Germoglio (2009) uma vez que os interessados no sistema têm diferentes preocupações e níveis de conhecimento, a arquitetura não deve ser exposta da mesma maneira para interessados diferentes. Para resolver esse problema, surge o conceito de visões arquiteturais. O termo visões de arquitetura é definido por Varoto (2002) como diferentes formas de observar um mesmo problema com a finalidade de melhor entendê-lo para então, atribuir-lhe a solução mais adequada. Algumas possíveis visões são: Visão funcional/lógica; Visão de código; Visão de desenvolvimento/estrutural; Visão de concorrência/processo/thread; Visão física-evolutiva; Visão de ação do usuário/feedback.

29 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 28 Existem diversos esquemas de visões, cada qual usa uma quantidade de visões. De acordo com Varoto (2002) são exemplos desses esquemas: OMT, Booch, 4+1 views (RUP), RM-ODP e Zachman. O esquema 4+1 views, descrita na Rational Unified Process (RUP), tem como objetivo representar a arquitetura como um modelo abstrato composto pelas visões apresentada na figura : Visão Lógica (Funcionalidade) Visão de Processos (Performance, Escalabilidade, Disponibilidade) Visão de Casos de Uso Visão de Implementação (Gerenciamento do Software) Visão de Implantação (Topologia do Sistema) Figura Modelo de Visões 4+1 views Fonte: CNI (2009) Visão Lógica. Define a estrutura lógica da arquitetura. Lista e descreve as camadas que compõem a solução definindo as responsabilidades de cada camada e como estas devem interagir; Visão de Implementação. Define como os aspectos descritos na Visão Lógica devem ser estruturados fisicamente nos componentes do sistema. Está relacionada ao ambiente de desenvolvimento (código-fonte e gerência de configuração estão envolvidos nesta visão); Visão de Casos de Uso. Descreve os casos de uso que serão utilizados na validação da arquitetura. Geralmente são os principais casos de uso do sistema. Eles deverão ser implementados e implantados na fase de Elaboração. Visão de Processos. Descreve o sistema em tempo de execução. Descreve os processos e threads que controlam os componentes do sistema;

30 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 29 Visão de Implantação. Descreve o ambiente de implantação. Está relacionada à infraestrutura onde o sistema será publicado; 2.3 APLICAÇÕES CORPORATIVAS O termo aplicação corporativa sugere uma aplicação de grande escala, no entanto nem todas as aplicações corporativas são grandes, mesmo que elas agreguem muito valor ao negócio. Segundo Fowler (2006, pág. 27) uma aplicação é considerada corporativa quando utiliza recursos como: persistência de dados, concorrência de acesso aos dados, interação com usuários, e possibilidade de realizar integração com outros aplicativos. Além dessas características, também podem ter a capacidade de prover controle de acesso dos usuários aos sistemas ou geração de relatórios. Essas características serão explanadas a seguir: Persistência: Refere-se ao armazenamento não volátil dos dados, pois as empresas precisam ter suas informações armazenadas de forma a existirem por vários anos. Normalmente existe uma grande quantidade desses dados. Os sistemas atuais utilizam banco de dados relacionais para gerenciar essas aplicações. Concorrência: A concorrência permite que múltiplos usuários acessem essas aplicações ao mesmo tempo. Em sistemas baseados na plataforma Web esse requisito deve ser tratado com alta prioridade, dada a possibilidade da alta carga de usuários. Interação com usuário: No geral, os usuários possuem pouco conhecimento técnico, necessitando assim de uma interface gráfica intuitiva que os auxiliem a interagirem com o sistema. Integração: Em uma empresa pode existir mais de um sistema, sendo quase necessário que esses sistemas possuam a habilidade de poder trocar informações, ou seja, serem integrados. Esta funcionalidade pode ser de

31 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 30 difícil implementação visto a possibilidade das aplicações serem desenvolvidas em plataformas ou tecnologias distintas. A figura a seguir demonstra a relação entre os elementos que compõe uma aplicação corporativa. Figura Relação entre os elementos de uma aplicação corporativa Fonte: Na figura é explícito de maneira simples a interação entre os elementos que podem compor uma aplicação corporativa, é possível observar que as pessoas interagem com as aplicações, as aplicações acessam a base de dados a fim de realizar a ação da pessoa, os dados são tratados pelas regras de negócios e disponibilizados para as pessoas através dos processos. Este ciclo se repete quantas vezes forem necessários para realizar a atividade Aplicações Corporativas na Plataforma Web De acordo com o Internet World Status (IWS) (2009) no ano de 2009 cerca de 25% da população mundial tinha acesso a internet, significando que 1,72 bilhões de

32 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 31 pessoas usufruem de alguma maneira de serviços providos pela internet, esse número representa um crescimento de 380% do número de usuários ao se comparar o ano de 2000 a Para a possibilidade desse crescimento foi essencial a evolução das ferramentas e processos de desenvolvimento para plataforma WEB. Impulsionado por esse movimento, de acordo com Azevedo et al (2007) grande parte das aplicações desenvolvidas atualmente possuem alguma forma de integração com a internet. Inclusive alguns sistemas legados estão passando a receber módulos de integração com a rede. A internet não é mais vista como somente uma vitrine para produtos, mas como forma de oferecer serviços, o que atrai o desenvolvimento de aplicações corporativas na plataforma. A tendência é de aceitar que cada cliente é único e necessita resolver suas pendências independentes da localização geográfica. Acompanhando esta evolução, uma grande parte das linguagens de programação, mesmo aquelas que surgiram na geração anterior a internet, passaram a oferecer algum tipo de suporte à programação para Web. No entanto, a linguagem escolhida deve ser confiável, oferecer alto desempenho e ser customizável a necessidade da organização, pensando nestes requisitos a linguagem Java foi a escolha mais sensata para essas aplicações, mas não única Java para Web O aumento do número de aplicações corporativas desenvolvidas na plataforma web possibilitou a um grupo de desenvolvedores vinculados a SUN 5 definir uma especificação objetivando padronizar o desenvolvimento de sistemas na linguagem Java. Esta especificação foi denominada Java Enteprise Edition (JEE), que atualmente se encontra na versão seis, denominada JEE6. Acreditando que as aplicações devem ser concebidas, construídas e padronizadas com menos dinheiro, maior velocidade e menos recursos, a JEE6 compreende um vasto conjunto de tecnologias que abrangem uma série de especificações voltadas 5 Empresa detentora dos direitos sobre a linguagem de programação Java

33 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 32 principalmente para aplicações corporativas, contendo quase todos os pontos vitais para o desenvolvimento dessas aplicações. A JEE6 é formada através de um conjunto de tecnologias bem integrada que reduzem significativamente o custo e a complexidade do desenvolvimento, implantação e gerenciamento de múltiplas camadas. A figura a seguir mostra a evolução da JEE, destacando os principais componentes. Figura Evolução da plataforma JEE Fonte: SUN, Na figura é possível acompanhar a evolução da JEE, da esquerda para direita, a imagem mostra as principais novidades de cada versão. A JEE 6 é a especificação mais atual do Java, ela compreende o que existe de mais avançado na linguagem Model View Control (MVC) Para o desenvolvimento de aplicações corporativas, Fowler (2006, pág. 315) indica o padrão Model View Controller (MVC), que divide a arquitetura em três elementos distintos: a lógica de negócio (ou model), que representa as funcionalidades e os dados do sistema; visões (ou views), que são responsáveis pela entrada de dados

34 C A P Í T U L O I I C O N C E I T O S B Á S I C O S 33 dos usuários; e os controladores (ou controllers), que representam a forma de exibir o estado da lógica de negócio ao usuário. Figura Estilo para Arquitetura Interativa MVC Fonte: Como pode ser observado na Figura , o padrão também define que deve existir um mecanismo de propagação de mudanças, de forma que a interface com o usuário (composta das visões e dos respectivos controladores) se mantenha consistente com a lógica de negócio. Este padrão é comum em sistemas interativos e foi também popularizado em sistemas web por meio de frameworks.

35 CAPÍTULO III ARQUITETURA DE REFERÊNCIA

36 C A P Í T U L O I I I A R Q U I T E T U R A D E R E F E R Ê N C I A 35 3 ARQUITETURA DE REFERÊNCIA Este capítulo descreve a arquitetura de referência desenvolvida, propondo aspectos e restrições técnicas como quesitos de qualidade e a utilização do modelo de visões 4+1 views para documentação da solução, estendendo aos padrões de projetos e frameworks utilizados. 3.1 INTRODUÇÃO Na definição da arquitetura de referência proposta é importante que a delimitação seja respeitada, onde a solução deverá fornecer as seguintes características: Os componentes devem ser restringidos e otimizados para sistemas com características corporativas; Ser para plataforma web; Desenvolvida em linguagem de programação Java. Facilitando o desenvolvimento de sistemas com as seguintes funcionalidades: Disponibilização de Relatórios: Proporcionar fácil desenvolvimento de relatórios, com o objetivo de serem emitidos em formatos PDF ou Excel; CRUD: Proporciona possibilidade de criar, editar, atualizar e listar objetos; Web Services: Prover suporte a disponibilização de serviços para outras aplicações; Autenticação e Autorização: controlar o acesso dos recursos do sistema. Além destas características e funcionalidade, a arquitetura de referência deverá estar em conformidade com os seguintes aspectos proposto no Guide to the Software Engineering Body of Knowledge (SWEBOK), este aconselha características que devem ser atendidas para que um sistema atinja um nível de qualidade

37 C A P Í T U L O I I I A R Q U I T E T U R A D E R E F E R Ê N C I A 36 aceitável, no entanto somente as mais importantes serão focadas no desenvolvimento da arquitetura de referência, estas serão listadas a seguir: Extensibilidade: Uma aplicação quando possui a característica de extensível significa que ela fornece pontos de extensão para disponibilização de um serviço, essa característica é essencial para uma aplicação corporativa, pois as mesmas devem possuir a opção de integração com outras aplicações. Reusabilidade: Trata-se da padronização de soluções para possíveis problemas comuns encontrados em um projeto, é importante, pois aumenta a qualidade do projeto e diminui os custos. Essa padronização é possível através da especificação de componentes comuns, devidamente testados. Manutenibilidade: A característica de manutenibilidade se refere à facilidade da modificação no software a fim de corrigir defeitos, adequar-se a novos requisitos ou se adequar a um ambiente novo. Em uma aplicação corporativa é comum surgir novos requisitos para serem implementados, ou novas ferramentas parem serem utilizadas, essas ações devem ser feitas de forma que não gerem traumas para a equipe de desenvolvimento. Desempenho e Estabilidade: Ambos são requisitos críticos para uma aplicação corporativa, se não para qualquer modelo de aplicação, eles destacam a importância de que os elementos da arquitetura sejam devidamente testados e aprimorados para não utilizarem recursos sem necessidade. Algumas restrições técnicas devem ser consideradas no desenvolvimento da arquitetura de referência, são eles: A aplicação a ser desenvolvida com base na arquitetura de referência não poderá ser para banco de dados distribuído, no caso, deverá utilizar banco de dados relacional. Utilizar versão de servlet 2.5 ou superior para aplicações JEE.

38 C A P Í T U L O I I I A R Q U I T E T U R A D E R E F E R Ê N C I A METODOLOGIA DO DESENVOLVIMENTO DA ARQUITETURA Para o desenvolvimento da arquitetura de referência foram analisados vários frameworks com a finalidade de escolher quais os que melhor ofereceriam suporte as funcionalidades, características, aspectos e restrições propostos para a solução. No decorrer da pesquisa, os frameworks foram catalogados de acordo com a responsabilidade para com a arquitetura de referência. Logo após, foram realizados testes de caixa cinza em laboratório através de exames a nível estrutural e de entrada e saída de dados, com o objetivo de selecionar os que apresentassem melhores características. Após está exploração, foi possível propor integrações em diferentes configurações para os vários frameworks selecionados, resultando em uma seleção dos que mais se adequaram para a arquitetura de referência. Os frameworks testados podem ser observados no texto a seguir, onde serão divididos através das responsabilidades atribuídas na arquitetura de referência, como suporte a MVC, relatórios, segurança, integração, acesso a dados ou contêiner de aplicação. Suporte a MVC e disponibilização de Componentes Ricos Com objetivo de prover suporte ao padrão MVC foram testados vários frameworks, entre os quais se destacaram o zk framework, Google Web Toolkit (GWT), Struts2, Vraptor3, JSF2 (projeto Majora), Flex e Vaadin. No entanto, para a solução é interessante o uso de apenas um desses frameworks. Como forma de filtrar o melhor framework para esta responsabilidade na arquitetura de referência, foram propostos alguns parâmetros, como: Quantidade de componentes Ricos disponíveis: Este é o parâmetro mais importante, pois esta característica possibilita maior interação com os usuários do sistema e proporciona reusabilidade no desenvolvimento do sistema.

39 C A P Í T U L O I I I A R Q U I T E T U R A D E R E F E R Ê N C I A 38 Curva de aprendizado: Quanto menor a quantidade de tempo necessário para usar o framework, mais rápido a assimilação de suas características. Valor do investimento: Quanto menor o investimento necessário no framework, possivelmente maior a quantidade de interessados em utilizar a solução. Material disponível sobre a ferramenta: A arquitetura de referência é um guia inicial para definição da arquitetura da aplicação, mas para continuar o desenvolvimento da aplicação é necessário conhecer as funcionalidades que os frameworks que formam a arquitetura de referência podem oferecer. Após testes em laboratório de caixa cinza, chegou-se às seguintes conclusões: Os frameworks Vraptor3, Struts2 e Majora utilizam bem o padrão MVC e são acessíveis financeiramente. O Majora se destaca dentre os três por ser o padrão a programar a especificação JSF2 da JEE6. No entanto, quando comparados com os outros frameworks testados foi notável a diferença com relação à disponibilização de componente Ajax, por este motivo foram descartados da possibilidade de serem utilizados na solução proposta. O GWT, Vaadin e Flex são excelentes com relação à disponibilização de componente Ajax, no entanto, além de possuírem alta curva de aprendizado, são ferramentas pagas, o que impossibilita a escolha. O zk framework foi escolhido por possuir mais quesitos positivos a seu favor, pois apresenta bons componentes Ajax, sem custos, documentação vasta e curva de aprendizado pequena. O gráfico possui o objetivo de fundamentar a escolha do framework zk, ele representa uma comparação entre os frameworks zk, GWT, Flex, OpenLaszlo e Echo2.