Arquitecturas de Software Enunciado de Projecto

Transcrição

1 UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Arquitecturas de Software Enunciado de Projecto Introdução Na primeira metade da década de 90 começaram a ser desenvolvidas as primeiras páginas web dinâmicas, à custa, fundamentalmente, da utilização de scripts executados pelos servidores web que implementavam o protocolo CGI (Common Gateway Interface). Desde essa altura, e especialmente ao longo da última década, as aplicações web tornaram-se numa das soluções mais utilizadas para o desenvolvimento de novas aplicações. A arquitectura de software de alto nível de uma aplicação web é bem conhecida da maior parte da indústria de software. Embora possa ter algumas variações, é normalmente apresentada como uma arquitectura de três tiers: um tier para o cliente web, outro tier para o servidor web, e um tier para a base de dados. Quer o cliente web, quer a base de dados, são componentes standard neste tipo de aplicações pelo que costumam-se usar para estes tiers soluções já existentes no mercado. Por isso, o esforço de desenvolvimento de uma aplicação web concentra-se fundamentalmente no desenvolvimento do servidor web. O servidor web tem como principal responsabilidade receber os pedidos do cliente web e responder a esses pedidos depois de os ter processado. Tipicamente, para o fazer tem que aceder à base de dados para ler, alterar, ou escrever informação. 2 Objectivo do projecto O objectivo deste projecto é comparar, ao nível arquitectural, algumas das muitas soluções existentes para o desenvolvimento de uma aplicação web. Mais concretamente, pretende-se descrever a arquitectura de execução de três soluções distintas para o desenvolvimento de uma aplicação web, realçando os pontos em que as várias arquitecturas diferem. Para além dessa descrição arquitectural, e como resultado da comparação das diferentes arquitecturas, deve 1

2 ser criado um conjunto de recomendações sobre que solução usar em função dos requisitos de qualidade de um sistema a desenvolver. Ou seja, supondo que um arquitecto de software pretende desenvolver uma nova aplicação web, com um determinado conjunto de requisitos de qualidade, o resultado deste trabalho deve-lhe permitir determinar qual das soluções estudadas é a mais adequada para o seu sistema. 3 Trabalho a desenvolver O ponto de partida para este trabalho é a arquitectura 3-tier típica de uma aplicação web, em que os dados persistentes da aplicação estão armazenados numa base de dados relacional (como, por exemplo, no MySQL). Para implementar o tier do meio, que executa no servidor web, existem no mercado inúmeras soluções, que vão desde ferramentas ou frameworks específicos para um determinado aspecto de uma aplicação web, até soluções full-stack, que providenciam soluções completas para todos os aspectos do desenvolvimento de uma aplicação web. 3.1 Soluções para o desenvolvimento de aplicações web Duas soluções muito populares para o desenvolvimento de aplicações web são as seguintes: A utilização da plataforma Java (J2SE) juntamente com o Hibernate e o Struts. Esta solução corresponde, grosso modo, à solução usada na cadeira de Engenharia de Software. A solução designada por LAMP, que combina a utilização de Linux, Apache, MySQL, e a linguagem de programação PHP. Um bom ponto de partida para obter mais informação sobre esta solução é a página da Wikipedia sobre o assunto. Para além destas duas soluções, existem muitas outras, para as mais variadas linguagens de programação, e usando os mais variados frameworks. A questão que se coloca, portanto, é saber que solução usar no desenvolvimento de uma aplicação web. Em muitos casos, a escolha é feita tendo por base apenas a familiaridade (ou simpatia) da equipa de desenvolvimento com uma determinada linguagem de programação. Neste projecto, no entanto, pretende-se responder a esta pergunta de uma forma mais objectiva. Para isso, pretende-se determinar que diferenças existem (se algumas) na arquitectura das várias soluções. Como o número de soluções existentes é demasiado elevado, este estudo vaise restringir apenas a três soluções: as duas indicadas acima, e uma terceira escolhida por cada grupo. 2

3 3.2 Aspectos da arquitectura a comparar O principal objectivo deste estudo é permitir comparar as diferenças entre as várias soluções no que diz respeito à sua arquitectura de execução. Ou seja, não se pretendem comparar aspectos como a facilidade de programação, ou a facilidade de modificação do sistema, por exemplo. Por isso, na descrição da arquitectura de cada solução apenas são relevantes as vistas do tipo de vista componente e conector. A escolha das vistas a usar na descrição das várias arquitecturas deve ser feita de modo a permitir explicar claramente o funcionamento do servidor web no processamento de um pedido. Em particular, nessa explicação são especialmente relevantes aspectos como os seguintes: A existência ou não de concorrência no processamento dos pedidos, e, se existe concorrência, de que tipo é, e como é que as diferentes unidades concorrentes interagem entre si. Que conversões de dados existem no processamento de um pedido, desde os parâmetros recebidos pelo servidor web no pedido HTTP até à comunicação com a base de dados. A utilização de caches pelo servidor web, aos mais diferentes níveis (por exemplo, pode ser importante perceber o funcionamento e efeito das caches de nível 1 e nível 2 usadas por ferramentas como o Hibernate). No entanto, é natural que existam muitas semelhanças arquitecturais entre as várias soluções estudadas. Nesse caso, deve-se evitar a repetição da descrição da arquitectura. Pelo contrário, como o objectivo é ver as diferenças entre as várias soluções, devem-se tornar essas diferenças o mais evidentes possível. 3.3 Critérios a usar na comparação Uma vez que apenas se pretende comparar as várias soluções ao nível da sua arquitectura de execução, na comparação a efectuar apenas se deve entrar em linha de conta com os atributos de qualidade de um sistema que tenham a ver com a sua execução. Alguns dos atributos de qualidade que devem ser considerados neste trabalho são os seguintes: escalabilidade, performance (note-se que existem vários tipos de performance), e disponibilidade. Para além destes atributos, podem ser considerados outros que julguem relevantes. 3.4 Obtenção de resultados experimentais Apenas com base na comparação das diferentes arquitecturas de execução já é possível tirar algumas conclusões sobre a capacidade de cada solução satisfazer 3

4 determinados requisitos de atributos de qualidade, como a escalabilidade do sistema, por exemplo. No entanto, em muitos casos, só após a realização de testes de execução com cada tipo de solução se podem obter resultados concretos sobre os méritos de cada uma das soluções. Por isso, para além da descrição e comparação das diferentes arquitecturas, pretende-se efectuar um conjunto de testes que permitam comparar quantitativamente as diferentes soluções estudadas. Para efectuar esses testes, é preciso primeiro implementar o sistema esqueleto de uma aplicação web com cada uma das soluções, e depois submeter esse sistema esqueleto a uma bateria de testes para determinar o comportamento do sistema em várias situações. Os testes a realizar devem variar vários parâmetros de modo a determinar a resposta de cada sistema numa gama o mais alargada possível de valores. Esses parâmetros podem incluir, por exemplo, o número de pedidos feitos em simultâneo, o intervalo de tempo entre pedidos, a quantidade de dados processada por cada pedido (que podem ser do mesmo tipo ou de tipos diferentes), o volume de dados total da aplicação, a existência de pedidos que acedem aos mesmos dados que pedidos anteriores ou que acedem a dados diferentes, ou a percentagem de pedidos de leitura versus pedidos de escrita. Naturalmente, os testes devem ser feitos de modo a que os resultados entre as várias soluções possam ser comparáveis. Ou seja, o ambiente de execução, exceptuando a implementação do servidor web, deve ser o mais uniforme possível para os vários testes. 3.5 Recomendações para o desenvolvimento de aplicações web Como resultado da comparação das diferentes arquitecturas e da análise dos resultados experimentais obtidos, pretende-se elaborar um conjunto de recomendações sobre as situações em que cada uma das soluções estudadas é mais adequada. Nestas recomendações devem-se ter em linha de conta as variações que podem existir nas características da aplicação web a desenvolver e que foram eventualmente testadas no ponto anterior. Por exemplo, qual o volume de dados que a aplicação irá processar, qual a utilização esperada da aplicação, qual a frequência das escritas e das leituras na base de dados, entre outros. 4 Trabalho a entregar Como resultado deste trabalho pretende-se um documento que descreva o trabalho realizado. O documento produzido deve ser sucinto, claro, e bem organizado. Note-se que a correcção ortográfica e gramatical do documento são também avaliadas. O documento entregue deve indicar claramente as fontes (de informação, não o 4

5 tipo de letra) usadas para a realização do trabalho. 4.1 Estrutura do documento Cada grupo é livre de elaborar a estrutura do documento a entregar, de modo a apresentar a informação da forma que melhor satisfaça os objectivos descritos para o trabalho. No entanto, como guia, podem considerar a seguinte estrutura geral para o documento: Introdução Soluções para o desenvolvimento de aplicações web Descrição sumária das várias soluções estudadas Requisitos de qualidade considerados Descrição da arquitectura de cada solução Vantagens e desvantagens de cada solução Resultados experimentais obtidos Implementação do sistema esqueleto de cada solução Descrição do ambiente de testes Metodologia usada para a experimentação Resultados obtidos nos testes Discussão dos resultados Recomendações para o desenvolvimento de aplicações web Requisitos de qualidade relevantes Soluções a adoptar em função dos requisitos Conclusões Referências/Bibliografia 5 Classificação O projecto será classificado numa escala de 0 a 20 valores, que serão distribuídos em três partes: Descrição e comparação da arquitectura das duas soluções obrigatórias, e recomendações de soluções a adoptar para o desenvolvimento de aplicações web: 15 valores. Realização, apresentação, e discussão de resultados experimentais: 3 valores. Descrição e comparação da arquitectura da terceira solução à escolha: 2 valores. 5

6 6 Condições de realização e prazos O projecto deve ser realizado por grupos de 3 alunos, que devem estar inscritos no agrupamento criado para o efeito no Fénix. O projecto deve ser entregue, agrafado ou encadernado, até ao dia 21 de Dezembro de 2007 na reprografia do DEI, no seu horário de funcionamento, e deve ser devidamente identificado na primeira página com a indicação do número de grupo e dos elementos que constituem o grupo. FIM DO ENUNCIADO. 6