Universidade Federal de Santa Catarina Departamento de Informtica e Estatstica - INE Centro Tecnolgico CTC Disciplina: Engenharia de Software - INE

E 5614 Professor: Ricardo Pereira e Silva

Desenvolvimento de software para Web (metodologias)

Gabriela Natacha Bechara - 03138801 Nicolas Curti - 02138360

Florianpolis, dezembro de 2003

Sumrio
1 Introduo..........................................................................................................................................................3 2 Metodologias para o Desenvolvimento web......................................................................................................4 2.1 HDM (Hypermedia Design Method )........................................................................................................5 2.2 RMM (Relationship Management Methodology)......................................................................................5 2.3 EORM (Enhanced Object Relationship Methodology)..............................................................................5 2.4 OOHDM (Object-Oriented Hypermedia Design Method).........................................................................5 2.5 RNA (Relationship-Navigational Analysis)...............................................................................................5 3 Metodologia de Conallen...................................................................................................................................6 3.1 Definindo uma Arquitetura para web.........................................................................................................6 4 Definindo Pontos de Vista.................................................................................................................................6 4.1 Ponto de Vista dos Requisitos....................................................................................................................7 4.2 Ponto de vista do Projeto............................................................................................................................7 4.3 Ponto de vista da Realizao......................................................................................................................8 4.4 Ponto de vista do Teste...............................................................................................................................9 5 Realizando Atividades de Arquitetura ..............................................................................................................9 5.1 Examinar e Priorizar Casos de Uso............................................................................................................9 5.2 Desenvolver uma Arquitetura Candidata..................................................................................................10 5.3 Criar Prottipos.........................................................................................................................................11 6 Padres arquitetnicos para apresentao Web...............................................................................................11 7 Aplicao dos Pontos de Vistas para Web......................................................................................................12 7.1 Clientes Web magro.................................................................................................................................13 7.2 Cliente Web Gordo...................................................................................................................................14 8 Concluso........................................................................................................................................................15 9 Referncias Bibliogrficas...............................................................................................................................16

Lista de Figuras
Figura 1: Diagrama de Colaborao do Cliente Web Magro.............................................................................14

Introduo
A primeira gerao de aplicaes para web foi criada, em sua maioria, sem um

processo definido de desenvolvimento. Estes desenvolvimentos eram realizados por uma pessoa ou pequeno grupo com idias afins, que idealizavam um sistema, e o desenvolviam, baseados em sua prpria experincia. Contudo, com o passar do tempo s aplicaes foram ganhando tamanho e peso, adquirindo uma complexidade alm da capacidade criativa de uma pessoa, ou um pequeno grupo sem tcnicas adequadas de organizao e projeto de software. As metodologias para o desenvolvimento de aplicaes para web foram criadas com o intuito de suprir tais deficincias, garantindo qualidade no desenvolvimento e

manuteno de seus sistemas, bem como o desenvolvimento em menos tempo de aplicaes mais complexas e custo. Alm de beneficiar na qualidade de desenvolvimento e manuteno dos aplicativos e sistemas para web, a utilizao de metodologias poupa, entre muitas outras coisas, retrabalho e tempo equipe responsvel pelo seu desenvolvimento.

Metodologias para o Desenvolvimento web

importante salientar que o desenvolvimento de software para web difere do

processo de desenvolvimento de software tradicional. Pessoas de diversas reas so envolvidas no processo de desenvolvimento para web, alm do fato de que se d uma maior importncia ao usurio e de que o nvel de segurana ser definido especificamente para cada projeto. A fase de manuteno do ciclo de vida tambm representa um papel relevante no desenvolvimento de sistemas voltados para web, comparando-se com outros. Mesmo a engenharia de software sendo uma rea nova e em crescimento, algumas metodologias para o desenvolvimento web surgiram nos ltimos anos. Tais metodologias diferem entre si em muitos aspectos, mas tambm possuem similaridades em outros.

Neste trabalho pretende-se abordar a metodologia de Jim Conallen (WAE ), no entanto existem diversas outras como HDM (Hypermedia Design Method ), RMM (Relationship Management Methodology), EORM (Enhanced Object Relationship Methodology), OOHDM (Object-Oriented Hypermedia Design Method) e RNA (Relationship-Navigational Analysis), que sero brevemente conceituadas abaixo. 2.1 HDM (Hypermedia Design Method ) Mtodo proposto por Garzotto, Mainetti e Paolini, em 1995. Foi um dos primeiros mtodos desenvolvidos para definir a estrutura e as interaes em aplicaes hipermdia. O mtodo HDM permite que se crie um modelo para aplicaes hipermdia estticas. 2.2 RMM (Relationship Management Methodology) Mtodo proposto por Isakowitz, Stohr e Balasubramanian em 1995. O mtodo RMM mais indicado para projetos em que as aplicaes cujo contedo alterado freqentemente. Podemos citar como exemplo um catlogo de produtos. 2.3 EORM (Enhanced Object Relationship Methodology) Mtodo proposto por Lange em 1994. O mtodo definido como um processo iterativo que se concentra no enriquecimento da modelagem orientada a objetos pela representao das relaes entre os mesmos. 2.4 OOHDM (Object-Oriented Hypermedia Design Method) Mtodo proposto por Rossi e Schwabe (1996, 1998). Diz-se que os modelos citados acima possuem a tendncia de ignorar o projeto de navegao e interface do usurio, alm de no poderem ser utilizados em sistemas dinmicos, como os de apoio deciso. Fazendo uso das caractersticas de orientao a objetos, o mtodo OOHDM modela sistemas visando o fim de problemas quanto a reusabilidade e manuteno do sistema final. 2.5 RNA (Relationship-Navigational Analysis)

Mtodo proposto por Bieber, Galnares e Lu em 1998. O mtodo RNA tem foco na anlise e define uma sequncia de passos a serem seguidos para o desenvolvimento de aplicaes web.

3
3.1

Metodologia de Conallen
Definindo uma Arquitetura para web Arquitetura no desenvolvimento para web est em quase tudo o que fazemos e, por

isso, difcil defini-la. Para alguns, um conjunto de midllewares que uma aplicao usa, enquanto para outros, um conjunto de ferramentas que descreve todas as decises importantes feitas no processo de desenvolvimento da aplicao. O arquiteto, ou a equipe de arquitetura tem por objetivo definir e transmitir equipe de desenvolvimento a arquitetura ou modelagem do sistema, assim como todas as decises importantes de projeto que levaram as mesmas. A arquitetura de um sistema tem diversos pontos de vista, dependendo do grau de abstrao de quem utiliza a descrio arquitetnica e da iterao em que ela utilizada. Cada ponto de vista da arquitetura aplicao em desenvolvimento pode ser entendida como a viso de uma iterao, ou ciclo de desenvolvimento. A idia de trabalhar a arquitetura de um sistema seguindo vises atribuda por Jim Conallen a Philippe Kruchten em The 4+1 View Model of Architecture. Segundo sua verso, a arquitetura de um software descrita pela Viso Lgica, Viso de Implementao, Viso de Processo e Viso de Implantao, alm de uma viso maior que capaz de unir todas elas, que a viso do Caso de uso. Conallen aponta diversas outras vises, como segurana e experincia do usurio, especialmente para as aplicaes web, alm das vises de aspectos funcionais e operacionais, apontados pela publicao do artigo Architecture Description Standard do IBM System Journal.

Definindo Pontos de Vista

No livro de Jim Conallen, o desenvolvimento para web abordado sob o enfoque da

definio de vrios pontos de vista, que so um conjunto de vises que compartilham um

conjunto de questes. Os pontos de vista fornecem o contexto e o significado para cada viso, e cada viso um conjunto dos modelos do sistema. Para exemplificar, podemos dizer que o ponto de vista do projeto utiliza um conjunto de vises que, por sua vez, utiliza um conjunto de modelos ou diagramas para representar aspectos estruturais e de interao entre as partes ou subsistemas da aplicao.

4.1

Ponto de Vista dos Requisitos O ponto de vista dos requisitos em uma descrio de arquitetura de software implica

na coleta e documentao dos requisitos e necessidades do sistema, sendo o ponto base para todas as decises importantes de projeto. uma representao dos requisitos arquitetnicos significativos, que influenciam toda a estrutura, organizao e restries dos demais pontos de vista do desenvolvimento. Para organizar o ponto de vista dos requisitos, podemos apontar as seguintes vises: Viso de domnio, ou viso de modelo de negcio: Esta viso ou representao do sistema apresenta o modelo de negcio atravs de seus casos de uso, realizaes, alm de poder incluir glossrio de termos importantes e referncias externas modelagem, como padres industriais ou documentos que regulamentam a atuao da rea do negcio. Viso dos requisitos funcionais: a descrio das funcionalidades do sistema, da perspectiva de um ator do sistema, normalmente do usurio final que far uso do mesmo. Nesta representao esto requisitos como facilidade de uso, por exemplo. Viso dos requisitos no-funcionais: So todos aqueles requisitos importantes arquitetonicamente para o sistema, mas que no podem ser vistos claramente como uma funcionalidade. Entram nesta viso requisitos como desempenho, robustez e segurana, por exemplo. 4.2 Ponto de vista do Projeto

Este ponto de vista descreve os processos, sub-sistemas e componentes do sistema, enfocando suas interaes e descrevendo as funcionalidades e restries de cada componente, prprio ou desenvolvido por terceiros. importante levar em conta este aspecto no ponto de vista de projeto, que so as restries e funcionalidades dos componentes, para evitar conflitos ou falta de recursos na fase de implantao. No ponto de vista de projeto tem-se representadas as vises Lgica e de Processo. Viso Lgica: a expresso dos objetos que compem o sistema e seus relacionamentos estruturais. Esta viso pode ser expressa pelos diagramas de classes e objetos e demais diagramas de representao estrutural do sistema. Viso de Processo: Mostra as atividades dos processos em execuo, inclusive suas concorrncias pelo uso da CPU, no caso de processos sendo executados simultaneamente durante a execuo do sistema. Para representar este ponto de vista, os diagramas UML como Classes, Objetos, Seqncia e Atividades, entre outros, so de extrema importncia para dar uma semntica rgida ao contedo desta viso. 4.3 Ponto de vista da Realizao O ponto de vista de realizao expressa como os elementos das vises Lgica e de Processo sero implementados no sistema. Neste ponto de vista, so identificados os ns do sistema e a maneira como os objetos iro se comunicar (RMI, CORBA, DCOM, XML,...). Neste ponto de vista so tomadas diversas decises tcnicas quanto implementao do sistema definido no Projeto, levando em conta a facilidade de uso de uma tecnologia, sua portabilidade, desempenho, entre outros quesitos, aliado aos objetivos e perspectivas do sistema. Por exemplo, uma tecnologia pode ser adotada em detrimento de outra mais eficiente por ter maior portabilidade e facilidade de comunicao com novos sub-sistemas, se um dos requisitos do sistema que ele se comunique com novos mdulos, que podem ser construdos em diversas outras linguagens. O elemento final deste ponto de vista podem ser as primeiras implementaes de classes e componentes, ou o primeiro esqueleto ou modelo do sistema, para testar e garantir

atravs de prottipos que haver condies de comunicao entre as classes e mdulos quando da totalidade do sistema estiver concluda. 4.4 Ponto de vista do Teste Este ponto de vista importante para expressar o feedback para a equipe de projeto e desenvolvimento, antes mesmo de os componentes estarem prontos ou serem entregues aos clientes ou produo. Para executar este ponto de vista normalmente existe uma equipe de testes que responsvel por analisar os resultados de todas as etapas anteriores e confront-los com os requisitos, para garantir a qualidade do desenvolvimento, no apenas garantindo que os componentes e o sistema como um todo funcione, mas sim que funcione como era esperado para o cumprimento dos requisitos.

Realizando Atividades de Arquitetura

As atividades de arquitetura acontecem em todas as fases do desenvolvimento da

aplicao web, sendo as seguintes as principais atividades: 5.1 Examinar os Casos de uso e procurar requisitos arquitetnicos significativos; Definir e documentar uma arquitetura candidata para o sistema; Definir a estratgia de reutilizao; Examinar e Priorizar Casos de Uso Uma das primeiras atividades a serem levadas em conta pela equipe ou responsvel pela arquitetura do software, o exame e a priorizao dos casos de uso. A priorizao dos casos de uso deve ser feita levando em conta os riscos envolvidos em sua implantao e sua complexidade. Quanto antes se perceber uma falha, dificuldade ou incompatibilidade no desenvolvimento, seja em termos de modelagem estrutural, seja em termos de aplicao de uma nova tecnologia, antes se ter um feedback e realizar as devidas alteraes nos projetos. Em algumas situaes, encontrado um conflito na implantao de um caso de uso, o arquiteto do software pode reavaliar a prioridade de um caso de uso, ou at mesmo

reescrev-lo, alterando os casos de uso secundrios para se adequar a esta alterao (estrutural ou tecnolgica). Em situaes em que o caso de uso tiver uma alta prioridade a ponto de no ser possvel reescrev-lo, o arquiteto do software pode contornar os entraves, aplicando outros padres de construo de software para o caso de uso, como por exemplo um proxy, ou uma fachada, para o acesso s funcionalidades e responsabilidades do mesmo, sem comprometer o restante da aplicao. Por estes motivos, importante esta anlise de prioridades dos casos de uso no incio do desenvolvimento de aplicaes, especialmente as voltadas para web, que so muito dependentes de tecnologias e infra-estrutura de terceiros, muitas vezes desconhecidas. 5.2 Desenvolver uma Arquitetura Candidata Em projetos bem sucedidos, normalmente no se tem a aplicao de novas arquiteturas de software, mas quase sempre a melhoria e incremento de antigas arquiteturas que j foram casos de sucesso, e vem sendo melhoradas com o tempo. Pela experincia de desenvolvedores da rea, a maioria das novas arquiteturas implementadas, que modificam radicalmente os paradigmas j formados, tendem ao fracasso, pela inexperincia do arquiteto ou no adequao aos objetivos do projeto. Mesmo as primeiras arquiteturas voltadas para a web que comearam a se tornar populares, eram especializaes das arquiteturas Cliente/Servidor genricas. As primeiras aplicaes web tambm eram muito simples, geralmente implementando uma pequena parcela da lgica de negcio da aplicao. Apenas com a evoluo das tecnologias para web, que se tornaram mais rpidas, robustas e confiveis, que uma maior parcela dos sistemas pode migrar para a web, tornando-a uma ferramenta importante no dia a dia das empresas, incorporando a maioria das atividades e necessidades das regras e lgica de negcio das aplicaes e sistemas. nesta atividade onde se deve levar em conta os recursos disponveis para o desenvolvimento e manuteno do software. Se h uma equipe de desenvolvimento especializada em Visual Basic e Asp, deve-se planejar uma arquitetura que se enquadre dentro das especificaes destas linguagens. Uma arquitetura desenvolvida para a criao de aplicativos em Java seria descartada, pois o custo de treinar ou contratar os

programadores para este desenvolvimento, certamente inviabilizaria e traria uma queda de qualidade ao software, por mais que ele seja bem projetado. 5.3 Criar Prottipos A Criao dos prottipos arquitetnicos tem a funo principal de responder a perguntas realizadas durante a escolha de uma determinada arquitetura. Existem dois tipos fundamentais de prottipos, os experimentais e os evolutivos. Prottipos Experimentais so criados para responder a uma srie de perguntas que influenciaro as decises de arquitetura e projeto, e logo em seguida sero descartados, para dar lugar implementao do sistema definitivo. Prottipos Evolutivos so aqueles que so criados com o objetivo de responder s mesmas perguntas arquitetnicas, mas estes so projetados com mais cuidado, para poderem vir a se tornar partes do novo sistema, caso forem aprovados. Normalmente este tipo de prottipo usado quando temos uma srie de prottipos para um sistema, onde um deles ser escolhido para dar origem implementao definitiva. Os objetivos da construo de prottipos em aplicaes web, alm de testar uma interface amigvel com o usurio, podem ser: Testar mecanismos de persistncia de dados; Medir taxas de transferncia de dados; Comprovar ou validar uma nova tecnologia; Avaliar o nvel de esforo para se criar artefatos da aplicao, utilizando uma nova ferramenta, ou um novo padro; Testar interfaces de aplicaes ou componentes de terceiros. Depois de construdos e testados os prottipos da nossa aplicao, e termos tomado as principais decises de arquitetura e projeto, agora com um embasamento prtico e comprovado, podemos dar continuidade ao nosso desenvolvimento, dando formato ao nosso desenvolvimento, atravs do padro de arquitetura escolhido.

Padres arquitetnicos para apresentao Web

Como j foi dito, boas prticas e padres de arquitetura nunca so criados do zero, mas sim, evoluem de arquiteturas anteriores, que se unem, ou compe para criar um novo padro. No caso das arquiteturas para web, no foi diferente. De um conjunto de arquiteturas, novos padres foram criados, e alguns reutilizados, com certas adaptaes e mudanas de contexto para se adequarem s novas tecnologias. So o caso de duas arquiteturas estruturais comuns, Fachada e Composio: Fachada: Tem a interface com o usurio como uma camada de apresentao, escondendo por trs dela uma srie de objetos responsveis pelas regras de negcio da aplicao. Composio: Cada pgina na web reunida em tempo de execuo a partir de fragmentos menores e sistema, independentes entre si, que podem ser reutilizados ao longo da aplicao. Conallen apresenta em seu livro trs novos padres de arquitetura para apresentao de aplicaes web, e a partir delas, podemos visualizar o processo de desenvolvimento de software, aplicando os pontos de vista de desenvolvimento para cada padro. Estes padres apresentados so Cliente Web Magro, Cliente Web Gordo e Produo Web. Cliente Web Magro: Usado principalmente em aplicaes onde h pouco controle sobre o cliente. O processamento de regras de negcio e apresentao deve ser realizado no servidor, para poder abranger a maior quantidade de usurios possveis, requerendo-lhes o mnimo de requisitos. Cliente Web Gordo: Quando h a possibilidade de controle sobre a mquina Cliente, pode-se aplicar uma arquitetura onde partes da apresentao e regras de negcio so executadas do lado cliente, atravs de controles ActiveX ou Applets Java. O protocolo de comunicao ainda o HTTP. Produo Web: um padro onde podemos ter aplicaes utilizando clientes como dispositivos de processamento dentro de um sistema de objetos distribudos, utilizando DCOM, RMI, Corba, ou qualquer tecnologia alm do HTTP que permita objetos distribudos.

Aplicao dos Pontos de Vistas para Web

7.1

Clientes Web magro Neste padro de arquitetura, toda a lgica do negcio implementada e executada

no servidor, para possibilitar uma configurao mnima e mais genrica do lado do cliente. Ponto de Vista dos Requisitos: O principal requisito desta arquitetura gira em torno de tornar a aplicao compatvel com tantos clientes quanto possvel. Aplicaes de Comrcio Eletrnico encaixam-se no perfil de aplicao que utilizam este padro de arquitetura, pois tem como meta atingir um grande numero de clientes, dos mais variados tipos, sem grandes preocupaes em possuir um determinado padro de hardware e software para se tornar apto a navegar pelo site. Nesta arquitetura, a responsabilidade do cliente deve ser apenas executar um navegador web HTML padro que possa solicitar pginas HTML ao servidor. Ponto de Vista do Projeto: Quando temos a necessidade de abranger um maior numero de clientes, diferentes entre si, torna-se necessrio mover grande parte dos componentes do sistema para as camadas do servidor de aplicao. Temos como componentes principais do sistema o Navegador do Cliente, muitas vezes desconhecido pelo sistema; o servidor web, responsvel pelo fornecimento das pginas HTML ao cliente; a conexo HTTP, que representa a comunicao entre o cliente e o servidor; a pgina esttica, que representa a pgina de contedo fixo, sem necessidade de processamento para ser apresentada ao cliente; a pgina Dinmica, que depende de processamento(entradas ou leitura de estados do cliente ou servidor) para formar seu contedo; Servidor de aplicao, responsvel pelo motor de execuo lgica do negcio; Servidor de Banco de Dados, responsvel pela camada de persistncia dos dados na aplicao; Sistema de Arquivos, que entendida como sendo a organizao fsica dos componentes da aplicao do lado Servidor. Podemos representar os relacionamentos estruturais dentre estes mdulos apresentados pelo seguinte Diagrama de Colaborao:

Servidor de Aplicao

Servidor de Banco de Dados

navegador do Cliente

HTTP

Servidor Web

Recurso de pgina

Pagina Dinamica

Pagina Esttica

Sistema de Arquivos

Figura 1: Diagrama de Colaborao do Cliente Web Magro

Ponto de Vista da Realizao: Neste Ponto de vista, a equipe de desenvolvimento e arquitetura deve desenvolver a aplicao sempre levando em conta e respeitando a diversidade dos clientes, e sua escalabilidade, ou seja, a probabilidade de os clientes crescerem em nmero de requisies mais do que o servidor pode suportar, prevendo a possibilidade de criar redundncias e clusters ou especializaes de servidores para garantir uma boa acessibilidade de todos os clientes aplicao. Ponto de Vista dos testes: Os testes da aplicao no desenvolvimento web magro deve focar seu trabalho especialmente na compatibilidade com verses mais comuns de navegadores, testar o sistema debaixo de diferentes configuraes de firewall, onde apenas as portas e protocolos padro so permitidos, alm de testar as implicaes da existncia de cache entre o servidor e os clientes.

7.2

Cliente Web Gordo O Cliente Web Gordo se assemelha nos pontos de vista ao Cliente Web magro,

estendendo-o com scripts do lado cliente para permitir que uma certa quantidade lgica do negcio possa ser executada do lado do cliente, evitando sobrecargas dos servidores e do trafego de informaes desnecessrias pelas redes, diminuindo inclusive o tempo de

resposta s requisies. Este padro prev que os clientes cumpram determinados requisitos de compatibilidade para poder executar seus scripts, como verso de sistema Operacional e navegador compatveis com a tecnologia usada, como Controles ActiveX ou Applets Java. Produo Web: Este padro assim denominado por tornar a web um espao de produo e manipulao de informaes, atravs da implementao de uma lgica de objetos distribudos, onde cada cliente pode atuar tambm como servidor de objetos a outros clientes da rede. Desta maneira os requisitos devem supor a capacidade da rede e dos clientes em suportar uma implementao de objetos distribudos e a comunicao destes entre si. O projeto deste padro deve levar em conta a necessidade de transmisso e padronizao de protocolos que realizaro a comunicao, atravs de RMI ou DCOM, por exemplo, e a lgica de objetos distribudos pela rede, sem deixar grandes espaos s vulnerabilidades inerentes de uma rede, como o fato de um dos clientes/servidores estarem indisponveis em determinado momento.

Concluso
Metodologias de desenvolvimento de aplicativos sempre foram necessidades para os

desenvolvedores e projetistas na industria tradicional do software. Com o advento das aplicaes web e a difuso de suas vantagens sobre os sistemas tradicionais, tivemos uma exploso das necessidades de desenvolvimento para esta nova tecnologia que surgiu e se popularizou na ultima dcada. Com este crescimento, as aplicaes voltadas para web no tiveram o devido acompanhamento de metodologias voltadas s suas prprias necessidades, sendo difcil

encontrar material e estudos sobre o assunto, quando comparamos com a industria tradicional do software, que veio se desenvolvendo h muito mais anos. Felizmente, est sendo dado o maior valor a este assunto quanto mais se percebe a importncia que a web adquiriu nos ltimos tempos e toma-se conscincia de que no mais possvel administrar sua complexidade baseados apenas na experincia de um programador, ou equipe de programao, mas sim torna-se necessrias tcnicas de desenvolvimento evoludas e que respondam a todas as questes envolvidas neste tipo de aplicao.

Referncias Bibliogrficas

Bieber M., Galnares R. and Lu Q. (1998). Web engineering and flexible hypermedia. Disponvel em http://wwwis.win.tue.nl/ah98/Bieber.html Schwabe D. and Rossi G. (1998). Developing hypermedia applications using OOHDM. In Proceedings of Workshop on Hypermedia development Process, Methods and Models, Hypertext98.Disponvel em http://citeseer.nj.nec.com/schwabe98developing.html

Koch, Nora. Comparing Development Methods for Web Applications. Disponvel em - http://www.pst.informatik.unimuenchen.de/personen/kochn/techrep/hypdev.pdf Conallen, Jim. Modeling Web Applications Archtectures with UML Conallen, Jim. Desenvolvendo Aplicaes Web com UML. Traduo 2 edio. 2003. Bookman.