Desenvolvimento de sistemas de informação baseados na Web uma abordagem utilizando o ciclo de vida espiral

Texto

(1)Universidade Federal de Pernambuco Centro de Ciências Exatas e da Natureza Centro de Informática Pós-Graduação em Ciência da Computação. Desenvolvimento de Sistemas de Informação Baseados na Web Uma Abordagem Utilizando o Ciclo de Vida Espiral Andreia Almeida de Alcântara Dissertação de Mestrado. Recife 07 de Dezembro de 1998.

(2) UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE CIÊNCIAS EXATAS E DA NATUREZA DEPARTAMENTO DE INFORMÁTICA. Andreia Almeida de Alcântara. Desenvolvimento de Sistemas de Informação Baseados na Web Uma Abordagem Utilizando o Ciclo de Vida Espiral. Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Ciências Exatas e da Natureza da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.. ORIENTADORES:. Prof. Silvio Romero de Lemos Meira Prof. Fabio Queda Bueno da Silva. Recife, 07 de Dezembro de 1998.

(3) Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 Alcântara, Andréia Almeida de. Desenvolvimento de sistemas de informação baseados na Web uma abordagem utilizando o ciclo de vida espiral / Andréia Almeida de Alcântara - Recife: O Autor, 1998. ix, 113 folhas: fig., tab. Orientador: Silvio Romero de Lemos Meira. Dissertação (mestrado) - Universidade Pernambuco. CIn, Ciência da Computação, 1998.. Federal. de. Inclui bibliografia e apêndice. 1. Engenharia de software. 2. Metodologia de desenvolvimento. I. Meira, Silvio Romero de Lemos (orientador). II. Título. 005.1. CDD (22. ed.). MEI2011 – 193.

(4)

(5) Para Dida, que quase me mata de saudades…. i.

(6) Agradecimentos Aos meus pais, Alberto e Marialva, que me ensinaram a gostar de aprender. A Zezinha e às minhas irmãs – Ana “Mainha” e Alice “Degudinha” – por compreenderem e desculparem todas as minhas ausências. E por sempre incentivarem a minha formação. A Dudinha, que nos dias de preocupação e angústia lembrava-me o prazer dos atos realmente importantes da vida - comer, dormir, "dengar", tomar banho de sol... A Roger, não só pela troca de idéias, contribuições e correções feitas à esta dissertação, mas, principalmente, por me fazer enxergar os problemas e dificuldades de uma outra perspectiva, quando necessário. A Silvio e Fabio, pela orientação, e a Paulo e Itana pelas críticas e sugestões ao texto desta dissertação. A todos que fazem o Departamento de Informática da UFPE e ao CESAR, pelo suporte a este trabalho. Aos membros da equipe ReAACT, em especial, a Rogério Raposo e Sandra Jansen, pelas discussões e troca de idéias. E a Julianne Pepeu, por ter sido boazinha e feito correções ao texto desta dissertação. A São Jorge, pelo exemplo, e aos colegas de turma, os mestrandos 96, em especial a Cynthia Tercero, com quem foi um prazer trabalhar em conjunto. Espero que possamos estar na mesma equipe novamente, qualquer dia desses! A todo o pessoal do Estrela Brilhante, em especial a Mestre Walter, pela oportunidade de fazer parte do Estrela - "se eu pude aprender o suficiente para tocar na noite dos tambores, por que não poderia escrever minha dissertação?!". Um obrigado especial aos usuários do CNCT, por todas as reclamações, críticas e cobranças que alimentaram o sistema e o seu desenvolvimento. ii.

(7) Resumo O crescimento e desenvolvimento da World Wide Web fez surgir desde sites de presença institucional - sites que disponibilizam informações corporativas para clientes e/ou parceiros - até complexos sistemas de informação, que usam os navegadores como plataforma básica para os clientes e realizam transações com bancos de dados, permitindo não só consultas às informações cadastradas, mas também inserção e alteração de dados pela Web. Porém, apesar do crescimento da rede, os sistemas de informação baseados na Web ainda não contam com ferramentas, métodos e técnicas bem estabelecidos para o seu desenvolvimento. Com relação ao processo de desenvolvimento, em particular, várias questões podem ser levantadas: • é possível utilizar as características da própria Web para facilitar e acelerar o desenvolvimento? • Os métodos e técnicas tradicionais de Engenharia de Software adequam-se bem à implementação desses sistemas? • Qual o melhor ciclo de vida a adotar? Como a área é muito recente e a tecnologia envolvida ainda instável, poucos são os estudos de caso nesse sentido. Neste trabalho, estudamos o processo de desenvolvimento de uma classe específica de sistemas de informação baseados na Web, concentrando-nos na questão de que modelo de ciclo de vida utilizar no desenvolvimento desses sistemas. Para tanto, discutimos uma adaptação do modelo de ciclo de vida espiral e apresentamos a sua aplicação no desenvolvimento do CNCT – Cadastro Nacional de Competência em Ciência e Tecnologia – um sistema de informação sobre a produção científica e tecnológica brasileira. Os problemas e características inerentes ao desenvolvimento do CNCT fornecem os subsídios necessários para uma abordagem pragmática das questões citadas acima. A adaptação ao modelo espiral, principal resultado deste trabalho, é descrita detalhadamente, permitindo a descrição, ou prescrição, adequada das fases, atividades e principais milestones envolvidos no desenvolvimento de sistemas baseados na Web. Palavras-chave: sistemas de informação baseados na web, modelo espiral, CNCT.. iii.

(8) Abstract The World Wide Web growth give rise to institutional sites – sites about business information to clients and partners – until complex information systems, that use browsers as their basic client platform and interact with databases, allowing queries to the registered data and, more over, inserts and updates of these data through the Web. However, besides the great growth of the Web, the development of Web-based information systems still doesn’t count on with appropriate tools, methods and techniques. Some questions can be asked about the development process, in particular: • could the Web own characteristics be used to make the development easier and faster? • Are traditional Software Engineering methods adequate to implement Web-based information systems? • Which is the most adequate life cycle to these systems? As this is a recent area and the technology used is still maturing, there are few case studies about it. In the present work, we study the development process of a specific class of Web-based information systems, concentrating in the question of which life cycle model should be used to develop these systems. We discuss an adaptation of the spiral life cycle and present its use in the development of CNCT – National Register of Competence in Science and Technology – a Webbased information system about the scientific and technology Brazilian production. The problems and characteristics of the CNCT development make a practical approach of the questions above possible. The spiral model adaptation, principal result of this work, is described in detail, allowing an adequate description, or prescription of the phases, activities and principal milestones involved in the development of Web-based information systems. Keywords: web-based information systems, spiral model, CNCT.. iv.

(9) Conteúdo 1 Introdução................................................................................................................................... 1 1.1. A era da informação e a World Wide Web ...................................................................... 2. 1.1.1. Crescimento e alcance da Web..................................................................................... 2. 1.1.2. Sistemas de informação para a Web ............................................................................ 4. 1.2. Escopo deste trabalho e conteúdo dos capítulos .............................................................. 6. 2 Sistemas de Informação Baseados na Web .............................................................................. 8 2.1. Evolução do modelo de disponibilização de informações da Web .................................. 9. 2.1.1. O modelo básico ........................................................................................................... 9. 2.1.2. Acrescentando dinamismo ......................................................................................... 12. 2.1.3. A interação com SGBDs ............................................................................................ 15. 2.1.4. Objetos distribuídos ................................................................................................... 23. 2.1.5. Intranets e Extranets ................................................................................................... 23. 2.2. Classes de WbIS ............................................................................................................. 24. 2.2.1. Os sites de presença institucional e de conteúdo........................................................ 24. 2.2.2. Os sites de serviços .................................................................................................... 25. 2.2.3. WbIS transacionais..................................................................................................... 25. 2.3. Classe de sistemas estudada neste trabalho .................................................................... 26. 3 Um Modelo para o Desenvolvimento de WbIS...................................................................... 27 3.1. O modelo espiral ............................................................................................................ 28. 3.1.1. As atividades da espiral .............................................................................................. 28. 3.1.2. Vantagens e dificuldades do modelo espiral .............................................................. 31. 3.2 3.2.1. Uma adaptação do modelo espiral ................................................................................. 32 Sistemas alvo.............................................................................................................. 32 v.

(10) 3.2.2. Os ciclos da espiral WbIS .......................................................................................... 33. 3.2.3. Vantagens da espiral WbIS ........................................................................................ 42. 3.2.4. Dificuldades na aplicação da espiral WbIS ................................................................ 44. 4 Descrição do Sistema CNCT ................................................................................................... 46 4.1. Objetivos do CNCT ....................................................................................................... 48. 4.2. O contexto: sistema de informação do PADCT ............................................................. 48. 4.3. Usuários do sistema........................................................................................................ 51. 4.3.1. Profissionais cadastrados ........................................................................................... 51. 4.3.2. Administradores do sistema ....................................................................................... 52. 4.3.3. Módulos de outros sistemas de informação ............................................................... 52. 4.3.4. Público em geral ......................................................................................................... 52. 4.4. Modelo de dados ............................................................................................................ 52. 4.4.1. Entidades identificadas............................................................................................... 53. 4.4.2. Diagrama entidade-relacionamento............................................................................ 55. 4.5. Funções do sistema ........................................................................................................ 56. 4.6. Arquitetura do CNCT..................................................................................................... 57. 4.6.1. Os clientes .................................................................................................................. 58. 4.6.2. O servidor ................................................................................................................... 59. 4.7. Requisitos de segurança ................................................................................................. 61. 4.7.1. Análise de riscos ........................................................................................................ 61. 4.7.2. Política de segurança .................................................................................................. 62. 4.7.3. Mecanismos de segurança .......................................................................................... 62. 4.8. Interface do CNCT ......................................................................................................... 63. 5 O Desenvolvimento do Sistema CNCT ................................................................................... 66 5.1. A espiral do CNCT – uma visão geral ........................................................................... 68. 5.2. O primeiro ciclo: exploração do domínio ...................................................................... 69. 5.2.1. Determinação dos objetivos, alternativas e restrições ................................................ 69. 5.2.2. Avaliação das alternativas e análise de riscos ............................................................ 70. 5.2.3. Desenvolvimento........................................................................................................ 71. 5.2.4. Avaliação do ciclo e planejamento das próximas fases ............................................. 73 vi.

(11) 5.3. O segundo ciclo: estabilidade e construção do produto ................................................. 75. 5.3.1. Determinação dos objetivos, alternativas e restrições ................................................ 75. 5.3.2. Avaliação das alternativas e análise de riscos ............................................................ 76. 5.3.3. Desenvolvimento........................................................................................................ 77. 5.3.4. Avaliação do ciclo e planejamento das próximas fases ............................................. 79. 5.4. O terceiro ciclo: evolução do produto ............................................................................ 81. 5.4.1. Determinação dos objetivos, alternativas e restrições ................................................ 81. 5.4.2. Avaliação das alternativas e análise de riscos ............................................................ 82. 5.4.3. Desenvolvimento........................................................................................................ 83. 5.4.4. Avaliação parcial do ciclo .......................................................................................... 84. 5.5 5.5.1. Dados sobre o desenvolvimento..................................................................................... 85 A equipe de desenvolvimento .................................................................................... 87. 6 Conclusões................................................................................................................................. 89 6.1. Usando a Web para impulsionar o processo de desenvolvimento ................................. 90. 6.2. Desenvolvimento de WbIS versus desenvolvimento de sistemas tradicionais .............. 91. 6.3. Um modelo de ciclo de vida para WbIS transacionais................................................... 95. 6.3.1. A instância da espiral e o desenvolvimento do CNCT .............................................. 96. 6.4. Recomendações para o desenvolvimento de WbIS........................................................ 96. 6.5. Trabalhos futuros ......................................................................................................... 102. A Modelo Relacional do CNCT ............................................................................................... 110 B Plataforma de Hardware e Software Usada pelo CNCT..................................................... 112. vii.

(12) Lista de Figuras Figura 1 – Crescimento do número de servidores ............................................................................ 4 Figura 2 – O modelo básico de funcionamento da Web ................................................................ 10 Figura 3 – Navegadores Web e a portabilidade dos documentos................................................... 11 Figura 4 – Estrutura de uma URL .................................................................................................. 12 Figura 5 – O uso de CGI para gerar páginas dinâmicas ................................................................. 13 Figura 6 – Interação dos WbIS com SGBDs .................................................................................. 15 Figura 7 – Os clientes gordos ......................................................................................................... 19 Figura 8 – Os clientes off-line ........................................................................................................ 20 Figura 9 – Os clientes magros ........................................................................................................ 21 Figura 10 – Os clientes que usam extensões do navegador ........................................................... 22 Figura 11 – A espiral de Boehm..................................................................................................... 29 Figura 12 – A espiral WbIS............................................................................................................ 34 Figura 13 – O desenvolvimento no primeiro ciclo ......................................................................... 36 Figura 14 – O desenvolvimento no segundo ciclo ......................................................................... 38 Figura 15 – O desenvolvimento no terceiro ciclo .......................................................................... 39 Figura 16 – Fases do PADCT ........................................................................................................ 49 Figura 17 – Diagrama entidade-relacionamento do sistema CNCT............................................... 55 Figura 18 – Módulos e funções do CNCT ..................................................................................... 56 Figura 19 – Arquitetura básica do sistema CNCT ......................................................................... 58 Figura 20 – Camadas de acesso ao banco de dados Oracle............................................................ 60 Figura 21 – Interação entre clientes e servidores ........................................................................... 60 Figura 22 – Interface do cliente baseado em navegador ................................................................ 64 viii.

(13) Figura 23 – Interface de uma consulta ao CNCT ........................................................................... 65 Figura 24 – A espiral de desenvolvimento do CNCT .................................................................... 68 Figura 25 – A alternativa escolhida................................................................................................ 70 Figura 26 – O desenvolvimento no primeiro ciclo do CNCT ........................................................ 72 Figura 27 – O desenvolvimento no segundo ciclo do CNCT ........................................................ 78 Figura 28 – Crescimento do sistema CNCT .................................................................................. 86 Figura 29 – Variações na equipe de desenvolvimento ................................................................... 88. ix.

(14) Capítulo 1. Introdução Sai, sai, sai Sai o Estrela Brilhante Belas Catirinas, ôi Fazem o passo formante Toada do Estrela Brilhante. A facilidade para distribuir informação e a grande conectividade da Web transformaram-na rapidamente em uma plataforma atrativa para sistemas de informação. Entretanto, apesar da crescente complexidade desses sistemas, o seu processo de desenvolvimento ainda não está bem estabelecido.. 1.

(15) 1.1 A era da informação e a World Wide Web. 1.1 A era da informação e a World Wide Web Nos anos 80, o advento das redes de computadores locais (LANs) [TANE96a] e o baixo custo dos computadores pessoais (PCs) impulsionou a arquitetura cliente/servidor, promovendo grandes mudanças no desenvolvimento e uso de sistemas de informação. Aproximadamente uma década depois a World Wide Web, uma WAN [TANE96b] praticamente universal, com baixos custos de conexão para o usuário final, apresenta-se como o catalisador de uma nova revolução nos sistemas de informação. A próxima seção introduz a World Wide Web (ou Web ou, ainda, WWW), ilustrando seu crescimento e importância. Em seguida, são discutidas as vantagens que a Web oferece como plataforma para sistemas de informação, assim como problemas e dificuldades que ainda precisam ser resolvidos. A última seção apresenta os objetivos deste trabalho e uma breve descrição dos capítulos seguintes desta dissertação.. 1.1.1 Crescimento e alcance da Web A Web foi concebida em 1989, com a idéia básica de prover um meio simples e intuitivo de comunicação e compartilhamento de informações entre os membros do CERN (European Organization for Nuclear Research), que estavam localizados em diferentes países [BERN94; BERN96]. Sua arquitetura, proposta por Berners-Lee, baseia-se em tecnologias simples e hipertextos, utilizando a Internet como infra-estrutura de comunicação. Com o surgimento dos primeiros navegadores gráficos1, os usuários da WWW, antes acadêmicos e pesquisadores, passaram a englobar pessoas das mais diversas áreas e a Web cresceu de forma explosiva, transformando-se rapidamente no maior sistema hipermídia da história. Os principais motivadores desse crescimento foram: • facilidade de uso – a interface gráfica usada pelos navegadores, em conjunto com o esquema de endereçamento da Web (através das URLs), transformou o processo de navegação no espaço de informações da rede numa atividade simples e fácil de executar;. 1. O NCSA Mosaic, em 1993 e o Netscape Navigator, em 1994.. 2.

(16) 1.1 A era da informação e a World Wide Web. 3. • facilidade de acesso – a simplicidade do protocolo usado pela Web (o HTTP) permitiu que ele fosse facilmente compreendido e implementado em diversas plataformas. Esse fato, em conjunto com a utilização de uma WAN já estabelecida (a Internet) e com a distribuição gratuita de navegadores, diminuiu custos e dificuldades de acesso para os usuários finais, estimulando o uso da Web; • facilidade para prover informação – a linguagem básica para disponibilizar informações na Web (HTML) também foi projetada propositadamente simples e fácil de usar, de forma a permitir um rápido aprendizado. A facilidade para prover e consumir informação através da Web, resultado da simplicidade de suas tecnologias, é a grande responsável pelo seu crescimento. Quanto mais informação era disponibilizada na rede, mais pessoas interessavam-se por ela, tornando-se seus usuários; quanto mais o número de usuários crescia, maior o interesse despertado pela rede, como veículo disseminador de informações. Atualmente a Web possui cerca de 100 milhões de usuários e estima-se que esse número ultrapasse 200 milhões no ano 20012. Só no Brasil são 163.890 hosts,3 distribuídos em vários domínios diferentes. O gráfico da Figura 1 ilustra o crescimento mundial da rede, em termos do número de servidores (hosts) disponíveis. O conteúdo da Web também foi objeto de uma rápida evolução e diversificação. De pequenos sites educacionais e homepages simples, construídas por hobby, a Web passou a ser usada para comércio eletrônico, educação a distância, estratégia de marketing, integração entre parceiros comerciais e uma série de outras aplicações, que estão a modificar a rotina diária das pessoas. No Brasil, por exemplo, os serviços de home-banking4 já atendem a 3 milhões de usuários (aproximadamente 19% dos correntistas) e estima-se que, até o final da década, 5% a 30% de todas as transações bancárias no Brasil sejam feitas através da Internet. Jornais, livrarias e até. 2. Segundo. dados. do. IDC. (International. Data. Corporation),. disponíveis. na. URL. http://www.idc.com/f/Ei/gens16.htm. 3. Fonte: Centro de Estudos sobre as Tecnologias da Informação e da Comunicação – cetic.br. (http://www.cetic.br/hosts/1998/index.htm) . 4. Os clientes de home-banking utilizam tanto navegadores, quanto aplicações locais, comunicando-se através da. Internet, para efetuarem as suas transações..

(17) 1.1 A era da informação e a World Wide Web. 4. supermercados também já aderiram a rede. O Pão de Açúcar5, por exemplo, começou a efetuar vendas on-line em dezembro de 1997 e hoje conta com 70 mil “cyber-clientes” registrados, que são responsáveis por 12% do total de vendas realizadas. Número de servidores. Mês/ano. Figura 1 – Crescimento do número de servidores6 Além das vendas diretas, vários outros empreendimentos também podem ser impulsionados pela Web, pois a rede oferece um meio de interligar um grande número de pessoas, de diferentes regiões geográficas, com custos relativamente baixos. Numa era em que o controle e a manipulação de informação são essenciais [MART95], a Web apresenta-se como um dos principais instrumentos de comunicação e integração. Assim, cada vez mais a rede tem sido adotada como plataforma básica para novos serviços e aplicações.. 1.1.2 Sistemas de informação para a Web Os sistemas de informação baseados em mainframes [RAUC96], apesar das vantagens oferecidas por um controle centralizado, representavam um alto custo inicial, em termos do hardware e software necessários. Além disso, a baixa modularidade e interoperabilidade dos mainframes dificultava o desenvolvimento e escalabilidade das aplicações. Os sistemas distribuídos, em particular as aplicações cliente/servidor [UMAR93; ORFA96], surgiram como uma solução para esses problemas.. 5. Site disponível em http://www.paodeacucar.com.br..

(18) 1.1 A era da informação e a World Wide Web Baseados no aumento da capacidade de processamento e armazenamento dos PCs e na possibilidade de compartilhar hardware e dados através de redes locais, os sistemas cliente/servidor apresentam baixos custos de instalação, em comparação com as aplicações baseadas em mainframes, e permitem uma maior modularidade e interoperabilidade. Entretanto, a adoção de diferentes sistemas operacionais pelos usuários e a necessidade de instalar as aplicações cliente, localmente, em cada máquina, transformaram a manutenção e escalabilidade dos sistemas cliente/servidor em uma atividade difícil e de alto custo. Nesse contexto, a Web apresenta-se como uma plataforma capaz de unir as vantagens das aplicações cliente/servidor com o controle centralizado e facilidade para a manutenção de versões dos antigos sistemas baseados em mainframes. A grande conectividade da rede, aliada à facilidade de uso e acesso, à independência de plataforma obtida com os navegadores e a um modelo de disponibilização de aplicações que diminui os custos relacionados a implantação e distribuição de novas versões, transformaram a Web na plataforma ideal para o desenvolvimento de aplicações com alto grau de escalabilidade. Uma pesquisa efetuada em 1996 ilustra o potencial da Web como plataforma para sistemas de informação. Destacada em [FILL96], essa pesquisa revelou que praticamente metade dos entrevistados estaria integrando suas aplicações cliente-servidor a Web, enquanto a outra metade pretendia fazer isso nos próximos 18 meses. Apesar das vantagens, a adoção da Web como plataforma para sistemas de informação traz certas dificuldades e riscos, inerentes à adoção de toda nova tecnologia. Nesse sentido, ressaltamos a instabilidade das linguagens de programação e ferramentas usadas e problemas relativos ao desenvolvimento de aplicações. A tecnologia (linguagens, ferramentas, protocolos, etc.) usada na Web ainda é muito instável, encontrando-se em franca evolução. Assim, é difícil para os desenvolvedores manter-se a par das diversas opções tecnológicas e escolher um conjunto estável para o desenvolvimento. Também é difícil encontrar profissionais experientes e a falta de dados inibe uma avaliação correta de prazos e custos do desenvolvimento. Em resumo, os sistemas de informação para a Web, apesar de apresentarem uma complexidade crescente, ainda não contam com ferramentas, métodos e técnicas bem estabelecidos para o seu 6. Fonte: Internet Systems Consortium (https://www.isc.org/solutions/survey).. 5.

(19) 1.2 Escopo deste trabalho e conteúdo dos capítulos desenvolvimento. Com relação ao processo de desenvolvimento, várias questões podem ser levantadas: • é possível utilizar as características da própria Web para facilitar e acelerar o desenvolvimento? • Os métodos e técnicas tradicionais de Engenharia de Software adequam-se bem à implementação desses sistemas? • Qual o melhor ciclo de vida a adotar? Algumas metodologias e técnicas foram propostas [IZAK95; SCHW95], a maioria delas proveniente da área de desenvolvimento de aplicações hipertexto e multimídia, porém, apesar dessas metodologias auxiliarem no projeto e implementação de sistemas para a Web, as questões acima ainda carecem de respostas consolidadas. Em especial, é preciso avaliar se os modelos de ciclo de vida existentes se adequam ao desenvolvimento de sistemas para a Web e adaptá-los, se for o caso, ou, definir novos modelos que representem adequadamente o conjunto de fases, atividades, decisões, riscos e evolução desses sistemas. É nesse contexto que este trabalho se enquadra.. 1.2 Escopo deste trabalho e conteúdo dos capítulos Este trabalho tem como objetivo estudar o desenvolvimento de sistemas de informação baseados na Web, concentrando-se na questão de que modelo de ciclo de vida utilizar no desenvolvimento desses sistemas. Para tanto, foi adotado o modelo de ciclo de vida espiral [BOEH88] como ponto de partida para guiar o desenvolvimento de um sistema de informação real baseado na Web, o CNCT – Cadastro Nacional de Competência em Ciência e Tecnologia. A experiência com o CNCT possibilitou acompanhar milhares de usuários em todo o Brasil, levantando os problemas e características inerentes ao seu desenvolvimento e também similares aos de uma grande classe de sistemas baseados na Web. Paralelamente ao desenvolvimento do CNCT, o modelo espiral foi sendo adaptado, de forma a melhor descrever, ou prescrever, as fases, atividades e principais milestones, envolvidos no desenvolvimento de sistemas da mesma classe.. 6.

(20) 1.2 Escopo deste trabalho e conteúdo dos capítulos Os capítulos restantes desta dissertação estão organizados de forma a possibilitar uma melhor compreensão da adaptação feita ao modelo espiral, que é o principal resultado deste trabalho. O Capítulo 2 descreve a classe de sistemas que é nosso objeto de estudo. No início do capítulo, são introduzidas as tecnologias usadas na Web sob um ponto de vista evolutivo e, em seguida, são definidas diferentes classes de sistemas baseados na Web, colocando-se a importância e complexidade da classe de sistemas da qual o CNCT é um exemplo. O Capítulo 3 apresenta o modelo espiral de Boehm, descrevendo suas características, atividades, vantagens e desvantagens. Em seguida, descreve a adaptação feita ao modelo, ressaltando-se as diferenças nos ciclos da espiral, que empregam processos de desenvolvimento bem definidos. As vantagens e dificuldades relativas à aplicação da espiral adaptada também são apresentadas. O Capítulo 4 descreve as características do sistema CNCT – seus requisitos, motivação, modelagem conceitual, arquitetura, usuários e funções básicas – fornecendo uma idéia do nível de complexidade do sistema e possibilitando a compreensão de algumas das decisões tomadas durante o desenvolvimento. O Capítulo 5 apresenta o desenvolvimento do sistema CNCT, ilustrando as atividades do modelo de desenvolvimento apresentado no Capítulo 3 com um estudo de caso real. O capítulo também descreve vários dados relativos ao desenvolvimento, como o esforço, tempo e linhas de código produzidas em cada ciclo da espiral. O Capítulo 6 descreve nossas considerações finais e algumas sugestões para trabalhos futuros. Os Apêndices A e B contém, respectivamente: •. a descrição do modelo de dados relacional do CNCT e. •. a descrição da plataforma de hardware e software usada pelo CNCT.. 7.

(21) Capítulo 2. Sistemas de Informação Baseados na Web Na marcação das alfaias No tilintar do gonguê No xiquixar da maraca Na marcação do abê Toada do Estrela Brilhante. A evolução da tecnologia usada na Web levou à disponibilização de aplicações cada vez mais complexas, que podem ser divididas em quatro classes diferentes, os sites de presença institucional e conteúdo, os sites de serviços, os sistemas transacionais e as aplicações OCSI (Object Oriented Client/Server Internet-based), cada uma delas com diferentes níveis de programação e poder computacional.. 8.

(22) 2.1 Evolução do modelo de disponibilização de informações da Web Sistemas de informação baseados na Web, ou WbIS – Web-based Information Systems, são sistemas que utilizam a tecnologia da Web – estrutura física, protocolos, ferramentas, etc. - como plataforma para realizar suas funções. Assim, à medida que as tecnologias relacionadas à Web se desenvolveram, a capacidade de processamento de informação, e as aplicações dos WbIS, também evoluíram. Este capítulo descreve como o crescimento da Web e o desenvolvimento de suas tecnologias levou à disponibilização de sistemas de informação cada vez mais complexos. A primeira seção, apresenta uma visão evolutiva do modelo de disponibilização de informações da Web, a seção seguinte descreve as classes de sistemas que fazem uso da tecnologia da rede para prover informação e a última seção especifica a classe de sistemas que nos propomos a estudar neste trabalho.. 2.1 Evolução do modelo de disponibilização de informações da Web 2.1.1 O modelo básico O modelo básico de funcionamento da Web utiliza a arquitetura cliente-servidor [UMAR93; ORFA96] e faz uso de três importantes tecnologias: o protocolo HTTP, para comunicação entre clientes e servidores, a linguagem HTML, usada para criar documentos hipertexto e URLs, que possibilitam a identificação dos documentos na rede. A Figura 2 mostra como esses elementos interagem para prover informação na Web. Os servidores Web, ou servidores WWW, ou ainda, servidores HTTP são processos que esperam pedidos dos clientes Web (os navegadores), localizam os documentos correspondentes em seu sistema de arquivos e os enviam de volta ao cliente, seguindo as regras de comunicação do protocolo HTTP. Os documentos são apresentados para o usuário através de programas chamados de navegadores ou browsers. Os navegadores interpretam os comandos HTML e permitem que o usuário possa “navegar” de um hipertexto a outro, seguindo as referências (links) entre eles. Eles também. 9.

(23) 2.1 Evolução do modelo de disponibilização de informações da Web. 10. podem apresentar outros tipos de dados não textuais, como imagens e sons, por exemplo [FREE96].. “Envie-me o document da URL http://www.di.ufpe.br. HTTP. Cliente Web. Servidor Web. 1. O client envi uma mensagem HTTP para o servidor Web, requisitando o documento de determinada URL.. HTTP. Documento HTML requisitad. Cliente Web. Servidor Web. Sistema de arquivos do servidor. 2. O servidor envia o documento requisitad para o navegador, que o apresenta acordo com as regras de formatação de HTML.. Figura 2 – O modelo básico de funcionamento da Web A apresentação de um mesmo documento varia de acordo com a plataforma específica do navegador, adaptando-se as características do sistema operacional usado e opções de visualização dos usuários. Como existem navegadores para diversas plataformas, é possível obter grande portabilidade, pois os provedores de informação podem escrever um único documento HTML para várias plataformas diferentes, ficando os navegadores encarregados de considerar os detalhes específicos de cada plataforma na hora da formatação e apresentação, como mostra a Figura 3..

(24) 2.1 Evolução do modelo de disponibilização de informações da Web Navegador para Unix. Navegador para PC. 11 Navegador para Macintosh. Documento HTML único. Figura 3 – Navegadores Web e a portabilidade dos documentos Apresentamos, a seguir, mais detalhes sobre os padrões básicos da Web. HTML – HyperText Markup Language HTML [W3Ca; RAGG97] é uma linguagem de marcação, usada para construir os documentos hipertexto da Web. Os seus comandos, ou elementos de marcação (mais conhecidos como tags), dividem o texto do documento em vários pedaços funcionais, identificando, por exemplo, trechos que devem receber destaque, imagens, âncoras e referências para outros documentos. Os tags determinam apenas a estrutura lógica do texto, ficando os navegadores responsáveis pelas respectivas apresentações, respeitando as diferentes fontes e convenções de cada plataforma. URL – Uniform Resource Location URLs [W3Cc] são a base do mecanismo de endereçamento da Web, pois identificam unicamente os recursos da rede. Como mostra a Figura 4, as URLs são constituídas de 3 elementos principais: • protocolo de acesso – indica o protocolo de comunicação que será utilizado entre cliente e servidor. O protocolo padrão da Web é o HTTP, entretanto, os navegadores também suportam outros protocolos, como o ftp, o telnet e o gopher, por exemplo..

(25) 2.1 Evolução do modelo de disponibilização de informações da Web • endereço do servidor – informa o nome do servidor e seu domínio; pode conter também, opcionalmente, o número da porta do servidor (se a porta não for especificada é usada a porta default). • localização do recurso no servidor – especifica a localização do recurso no servidor, normalmente através de seu caminho (path) e nome de arquivo.. protocolo. ://. host [:porta]. /. diretório/arquivo. Figura 4 – Estrutura de uma URL. HTTP – HyperText Transfer Protocol É o protocolo de comunicação usado entre clientes e servidores Web para transmitir documentos hipermídia. O HTTP [GETTYS; W3Cb] é um protocolo do nível de aplicação, baseado no TCP/IP e usa um modelo muito simples de comunicação, onde o cliente conecta-se ao servidor, solicitando um determinado recurso (um texto ou uma imagem, por exemplo), o servidor envia o recurso solicitado e a conexão é desfeita. O HTTP é um protocolo sem estado, pois cada recurso transferido corresponde a uma conexão e o servidor não armazena informações entre uma conexão e outra. A simplicidade do HTTP facilita a sua implementação, porém, o fato de não manter o estado entre conexões dificulta o desenvolvimento de aplicações mais complexas.. 2.1.2 Acrescentando dinamismo O advento de CGI – Common Gateway Interface – permitiu a extensão do modelo básico de funcionamento da Web e a criação de páginas geradas dinamicamente7. CGI [GUND96] é uma interface de comunicação (um gateway) que permite aos servidores Web interagir com programas executáveis, que podem receber parâmetros do servidor e gerar páginas HTML como resposta.. 7. A discussão a seguir não considera tecnologias de objetos distribuídos.. 12.

(26) 2.1 Evolução do modelo de disponibilização de informações da Web. 13. Os programas são também chamados de scripts CGI e possuem URLs relacionadas. O servidor identifica quando o navegador faz a requisição de uma URL que corresponde a um script CGI8 e inicia a execução do script correspondente. Normalmente, o conteúdo das páginas geradas dinamicamente é determinado por parâmetros que podem ser fornecidos através da própria URL do script ou de formulários HTML [ALC97a], que permitem a criação de áreas de entrada de dados dentro de páginas HTML. Os formulários fornecem uma maneira simples e familiar para coletar dados dos usuários e são muito usados para a passagem de parâmetros a scripts CGI. A Figura 5 ilustra como funciona o processo de geração de páginas dinâmicas. Inicialmente, o navegador requisita a URL de um script CGI, ou submete um formulário preenchido pelo usuário, passando ao servidor os parâmetros de entrada do script CGI. Essa comunicação entre navegador e servidor usa o protocolo HTTP. O servidor inicia a execução do script CGI correspondente, passando-lhe os parâmetros recebidos, de acordo com as regras do padrão CGI. Por fim, o script gera uma página HTML como resposta e o servidor a envia para o cliente, para que seja visualizada pelo usuário. Cliente Web. parâmetros. parâmetros. HTTP. CGI. resposta HTML. resposta HTML. Navegador. Script CGI. Servidor Web. Formulário ou URL do script. Figura 5 – O uso de CGI para gerar páginas dinâmicas Usando CGI é possível acessar dados e informações que o modelo básico da Web não poderia tratar e transformá-los em um formato compreensível para os navegadores (páginas HTML). Isso permite, por exemplo, o acesso a bases de dados, como é descrito na seção 2.1.3.. 8. Os scripts CGI são armazenados em diretórios determinados na configuração do servidor WWW, assim, quando o. servidor recebe uma solicitação de recurso (URL) presente nesses diretórios, ele identifica que se trata de um script CGI..

(27) 2.1 Evolução do modelo de disponibilização de informações da Web CGI adicionou flexibilidade, interatividade e poder computacional ao modelo básico da Web, inserindo programação do lado do servidor (server side programming [POWE98b]). As tecnologias descritas a seguir, por outro lado, fornecem poder computacional aos clientes (client side programming [POWE98a]). As linguagens de script O modelo dinâmico de disponibilização de informações possibilitado pela CGI executa código apenas do lado do servidor. Visando passar parte do processamento para as máquinas cliente, surgiram linguagens de script que são interpretadas pelos próprios navegadores e podem ser usadas para validar dados de um formulário e enviar mensagens de alerta ao usuário, entre outras funções. As linguagens de script são simples e orientadas a eventos e normalmente o seu código é embutido no código HTML transferido para os navegadores. Como a interpretação dos scripts é feita pelos navegadores e não existe um padrão para o código, como existe para os tags HTML, a portabilidade dessas linguagens depende do suporte fornecido pelos fabricantes de navegadores. Atualmente, JavaScript [DDOC97; FLAN97] é a linguagem que recebe maior suporte, sendo interpretada pela maioria dos navegadores usados na Web. Java e os applets Java [GOSL96] é uma linguagem orientada a objetos, de uso geral, cujo modelo computacional apresenta grande mobilidade de código. Do mesmo modo que HTML permite que documentos hipertextuais sejam facilmente transferidos entre computadores, Java permite que programas sejam facilmente transferidos pela rede e executados em computadores hospedeiros. A mobilidade de código em Java é obtida através do processo de compilação e execução do código Java. A compilação gera código em um formato independente de máquina, chamado de byte-code e, no momento da execução, o byte-code é interpretado por uma máquina virtual, instalada no computador cliente. Assim, recursos nativos do sistema operacional podem ser tratados de modo abstrato e, para portar Java para uma arquitetura de hardware/sistema operacional específica, basta portar sua máquina virtual. Programas Java podem ser aplicações que executam stand-alone ou applets, que são disponibilizados em servidores Web e embutidos dentro de páginas HTML. O código de um. 14.

(28) 2.1 Evolução do modelo de disponibilização de informações da Web. 15. applet é transferido para o navegador juntamente com a página HTML que o contém e é interpretado por uma máquina virtual presente no próprio navegador. Sua interface gráfica ocupa uma área bidimensional da página HTML, quando esta é formatada e apresentada ao usuário. Por ser uma linguagem de âmbito geral, Java oferece aos desenvolvedores flexibilidade e poder computacional muito maiores que as linguagens de script. A maior parte dos navegadores implementa a máquina virtual de Java, fornecendo suporte a linguagem e permitindo a execução dos applets. A transferência dos applets pela Internet pode ser demorada, devido ao tamanho dos arquivos de código e a execução dos applets é mais lenta que a de códigos nativos compilados, porque o bytecode precisa ser interpretado pelas máquinas virtuais.. 2.1.3 A interação com SGBDs Atualmente, CGI é a maneira mais comum para prover a interação entre WbIS e SGBDs (Sistemas Gerenciadores de Bancos de Dados), entretanto, existem outras alternativas para essa interação, tanto do lado do servidor, quanto do lado do cliente. A Figura 6 ilustra, de maneira genérica, como pode ser feita a interação.. Middleware. HTTP Servidor Web. SGBD. Cliente. Middleware. Figura 6 – Interação dos WbIS com SGBDs Tradicionalmente, os clientes comunicam-se com o servidor Web através do protocolo HTTP e o servidor Web comunica-se com o SGBD, o que pode ser feito através de várias tecnologias diferentes (aplicativos, protocolos, ferramentas, etc.) conhecidas como middleware. O objetivo do middleware é tornar os aspectos físicos da comunicação transparentes para os desenvolvedores. Os clientes também podem acessar o SGBD diretamente, sem passar pelo servidor Web..

(29) 2.1 Evolução do modelo de disponibilização de informações da Web A seguir, apresentamos as tecnologias mais comuns para implementar a comunicação entre o SGBD, o servidor e os clientes Web. Comunicação servidor Web – SGBD Existem basicamente quatro opções para realizar a interação entre servidores Web e bases de dados: CGI, APIs (servidores extensíveis) e servidores proprietários. As vantagens e desvantagens de cada uma são discutidas a seguir. •. CGI CGI, que foi descrita na seção anterior, é o método mais simples e mais usado atualmente. Porém, de maneira geral, é o que possui pior desempenho. A execução dos scripts CGI corresponde a requisições HTTP dos navegadores e cada vez que ocorre uma requisição, tem que ser criado um novo processo no servidor para que o script CGI seja executado. A criação de processos é uma atividade cara para os sistemas operacionais, implicando em um tempo relativamente longo para a execução de scripts CGI. Além da velocidade de resposta, um outro problema pode ocorrer com a adoção de CGI para a comunicação com o SGBD. Toda vez que um script CGI precisa acessar a base de dados, ele estabelece uma conexão com o banco, realiza a consulta, obtém o resultado, fecha a conexão, e envia a resposta ao servidor Web, terminando sua execução. Como HTTP não mantém o estado entre requisições, cada consulta requer o mesmo processo e o estabelecimento de uma nova conexão com o banco, mesmo tendo sido enviada pelo mesmo navegador cliente e mesmo usuário. O estabelecimento de conexões com o SGBD, além de ser uma atividade lenta, consome muitos recursos da máquina servidora, pois o SGBD necessita de mais memória para cada usuário conectado ao banco [MSTECH98]. Assim, se o número de usuários do sistema crescer muito, o acesso a base de dados rapidamente tornar-se-á um gargalo no processamento.. •. APIs e os servidores extensíveis Os servidores extensíveis trabalham parte das dificuldades da CGI através da disponibilização de interfaces padrão (APIs) entre os servidores e algumas aplicações. Assim, ao invés de escrever scripts CGI para realizar determinadas tarefas, os desenvolvedores podem. 16.

(30) 2.1 Evolução do modelo de disponibilização de informações da Web simplesmente estender a funcionalidade do servidor Web através das APIs, evitando a criação de novos processos para executar as tarefas desejadas. Vários servidores Web já oferecem esse recurso, através de APIs próprias. Como exemplos, podemos citar o IIS (Internet Information Server), da Microsoft, e os servidores da Netscape Corporation, com as APIs ISAPI [GENUSA; WUES97] e NSAPI [NSDOCb; NSDOCa; BASS98], respectivamente. Apesar de oferecerem melhor performance que o uso de CGI tradicional, a adoção de APIs adiciona complexidade ao desenvolvimento e a ocorrência de erros de programação pode “derrubar” todo o servidor Web. Além disso, o uso de APIs ainda não resolve o problema de múltiplas conexões com o SGBD, cada vez que se deseja realizar uma consulta. •. Servidores proprietários Das três opções apresentadas, os servidores proprietários oferecem o melhor desempenho, pois possuem facilidades para acessar diretamente a base de dados, utilizando protocolos proprietários de comunicação com o banco. Normalmente eles são implementados para trabalhar com um SGBD específico, sendo desenvolvidos pela mesma companhia que constrói o SGBD. As conexões usadas são persistentes e a comunicação efetuada é entre processos já existentes (inter-processos), não sendo necessário criar novos processos para atender as requisições dos navegadores. Um exemplo é o servidor Web da Oracle (OWS), que permite às aplicações baseadas na Web ter acesso direto a bancos de dados que fazem uso do SGBD Oracle. Através da configuração de agentes e listeners, próprios do OWS [BURT96], parâmetros enviados pelos navegadores são repassados a programas que, por sua vez, tem a tarefa de realizar o acesso às tabelas da base de dados. Apesar do bom desempenho, os servidores proprietários implicam em uma dependência de fabricante, assim, se for preciso interagir com SGBDs de vários fabricantes diferentes, essa solução não é recomendável.. •. Servlets As opções anteriores são baseadas na comunicação com strings, o que não favorece a manutenção e escalabilidade do código. Uma alternativa adicional são os servlets [BODOFF], componentes do lado do servidor que podem gerar dados para a camada de apresentação de aplicativos Web. Servlets são implementados através da linguagem de programação Java (são. 17.

(31) 2.1 Evolução do modelo de disponibilização de informações da Web uma classe de Java) e podem estender a funcionalidade de um servidor Web, permitindo a comunicação com SGBDs de forma mais estruturada e de mais fácil manutenção. Comunicação clientes – SGBD Como ilustra a Figura 6, existem duas maneiras através das quais os clientes podem interagir com a base de dados: diretamente ou através do servidor Web (caso em que é preciso adotar alguma das opções apresentadas na seção anterior). Cada uma dessas alternativas implica em diferentes opções de protocolos e tecnologias e podem ser classificadas de acordo com a capacidade de processamento do cliente que é adotada. A seguir, discutimos as principais soluções. •. Clientes gordos Esta solução coloca todo o processamento do lado do cliente, assemelhando-se às soluções cliente-servidor tradicionais. As aplicações são implementadas com linguagens de terceira e quarta geração, usando ferramentas avançadas (como ambientes de desenvolvimento visuais) e provêem interfaces gráficas complexas que possibilitam alto grau de interatividade com o usuário. A infra-estrutura da rede Internet é usada para a comunicação entre os clientes e o SGBD, mas o protocolo adotado não é o HTTP. Java pode ser usada para implementar as aplicações cliente, comunicando-se com o SGBD através de JDBC [HAMI97; REES97], protocolo baseado no ODBC [MSDOC]. Entretanto, normalmente são utilizadas linguagens mais tradicionais como Delphi [HEND96] e Visual Basic [MSC98] e o protocolo adotado é o padrão ODBC. Os clientes são chamados de “gordos” porque é preciso instalar as aplicações neles, juntamente com suas bibliotecas e os drivers para acessar os respectivos SGBDs. A Figura 7 ilustra essa solução.. 18.

(32) 2.1 Evolução do modelo de disponibilização de informações da Web. queries, dados. 19. queries, dados. Internet. SGBD. Cliente. • • • •. executáveis, bibliotecas, arquivos de inicialização, driver para SGBD. Figura 7 – Os clientes gordos As aplicações dos clientes gordos conseguem manter o estado das conexões com o SGBD, possibilitando a troca de vários dados em uma mesma sessão. Eles têm a mesma aparência das aplicações tradicionais, com a qual os usuários já estão acostumados e podem realizar inúmeras funções na máquina cliente, diminuindo a carga no servidor. Entretanto, essas aplicações herdam os mesmos problemas dos sistemas cliente-servidor tradicionais referentes a distribuição e manutenção das aplicações: podem haver problemas de portabilidade, cada upgrade do sistema implica na reinstalação da aplicação em todos os clientes e a instalação da aplicação geralmente não é simples, devido ao grande número de arquivos necessários. Esta solução é indicada quando se faz necessário uma interface altamente interativa e sofisticada com os usuários e se deseja passar de uma aplicação tradicional, funcionando sobre rede local (LAN), para uma aplicação em rede de longo alcance (WAN) pois, neste caso, o custo de migração é reduzido. •. Clientes off-line A disponibilidade, custo e velocidade das conexões pela Internet são muito variáveis e podem representar um problema para a comunicação entre clientes e servidores. Além disso, pode haver usuários que precisem usar o sistema sem estar conectados a rede. Neste caso, a adoção de clientes off-line pode ser uma solução [TERC98]. Os clientes off-line possuem aplicações semelhantes às do cliente gordo, que são instaladas nas máquinas dos usuários, porém, não dependem de uma conexão permanente ao SGBD para serem utilizadas. O acesso à base é feito apenas no início ou no final de sua utilização, para carregar ou para enviar dados, respectivamente..

(33) 2.1 Evolução do modelo de disponibilização de informações da Web. 20. A comunicação com o banco é feita através do servidor Web, usando HTTP e algum tipo de middleware do lado do servidor. Os detalhes do acesso ao SGBD são transparentes para a aplicação cliente, pois o acesso ao banco é feito do lado do servidor, como ilustra a Figura 8. Uma aplicação off-line implementada em Java, por exemplo, para realizar uma consulta à base de dados, precisaria apenas requisitar um script CGI do servidor (passando para ele os parâmetros da consulta ao banco de dados) e esperar pela resposta [WARL97]. Os clientes off-line apresentam os mesmos problemas que os clientes gordos, relativos a distribuição e implantação de versões. Entretanto, como o acesso ao banco é feito pelo servidor, a instalação das aplicações é mais simples e há menor risco de problemas com portabilidade. Esta solução é indicada em casos onde é preciso usar o sistema sem acesso contínuo a Internet ou quando a inserção/atualização dos dados for centralizada.. . requisições dinâmicas. queries, dados Servidor Web. SGBD. Cliente Off-line. • executáveis, • bibliotecas, • arquivos de inicialização. Figura 8 – Os clientes off-line •. Clientes magros Os clientes magros utilizam os navegadores como interface e adotam o protocolo e linguagem padrão da Web, como ilustra a Figura 9. Apesar da linguagem JavaScript também ser utilizada, como meio de realizar pequenas tarefas, o processamento do lado do cliente é muito leve e não requer a instalação de nenhum software extra, além do navegador. A maior parte do processamento é realizado no servidor..

(34) 2.1 Evolução do modelo de disponibilização de informações da Web. 21. HTML e JavaScript. requisições estáticas e dinâmicas. queries, dados Servidor Web. SGBD. Cliente magro. Figura 9 – Os clientes magros Esta solução possui várias vantagens com relação a distribuição e portabilidade das aplicações, pois, com o crescimento da Web, os browsers tornaram-se clientes praticamente universais [BIEB97]. Assim, as aplicações com clientes magros possuem amplo acesso, podendo atingir um número extremamente grande de usuários. A manutenção desses sistemas também é muito simples, pois a implantação de uma nova versão do cliente requer mudanças apenas nos arquivos presentes no servidor. Além disso, os navegadores são fáceis de obter e instalar e essa tarefa normalmente é efetuada pelos próprios usuários. Por fim, esta é uma solução bastante simples e bem conhecida, o que diminui os riscos do desenvolvimento. As desvantagens associadas ao uso de clientes magros originam-se principalmente das limitações de HTML para a construção de interfaces gráficas complexas e interativas e de seu modelo navegacional baseado em documentos. O pequeno poder computacional disponível para o cliente, associado a falta de estado entre as conexões (devido ao uso de HTTP), limita a flexibilidade e interatividade das interfaces com o usuário. Assim, a adoção dessa solução é indicada para a publicação de documentos onde existam poucas entradas de dados ou quando a portabilidade for um requisito essencial. •. Extensões do navegador Esta solução oferece um maior poder computacional ao cliente, possibilitando ainda uma fácil distribuição e manutenção das aplicações para grupos específicos de usuários. Ela consiste em usar navegadores que tenham suas funcionalidades estendidas, de forma a suportar alguma tecnologia de código móvel como, por exemplo, applets Java. Para suportar a execução dos applets, o navegador precisa implementar a máquina virtual de Java, que não fazia parte das funções originais dos browsers..

(35) 2.1 Evolução do modelo de disponibilização de informações da Web. 22. O uso de Java é uma opção razoavelmente portável, dado que a maioria dos navegadores já foram estendidos de forma a implementar sua máquina virtual, entretanto, existem outras tecnologias, dependentes de plataforma, que também podem ser usadas no cliente, como ActiveX [POWE98a; CHAP96], por exemplo. O acesso à base de dados pode ser feito através do servidor Web, geralmente usando HTTP, ou com a aplicação cliente comunicando-se diretamente com o SGBD, através de outros protocolos, como o JDBC. A Figura 10 ilustra o uso de extensões ao navegador. Esta solução tem a vantagem de prover flexibilidade e poder computacional aos clientes, mantendo o modelo simples e econômico de implantação e distribuição de aplicações permitido pela Web. Entretanto, a tecnologia disponível ainda não suporta essa solução de modo satisfatório para grande parte dos usuários da Web. No caso de Java, o download dos applets pode ser demorado e sua execução é mais lenta que a de aplicações tradicionais. Por outro lado, as outras soluções, como ActiveX, ainda apresentam sérios problemas de portabilidade. Assim, esta solução só é indicada quando se pode determinar o tipo de navegadores dos usuários e prover boas condições de acesso a rede, como ocorre em Intranets (as Intranets são discutidas na seção 2.1.5). Java, ActiveX, etc.. requisições estáticas e dinâmicas. queries, dados Servidor Web. SGBD. Extensão do navegador queries, dados. Figura 10 – Os clientes que usam extensões do navegador •. Soluções mistas Um mesmo WbIS pode disponibilizar diferentes tipos de cliente, de acordo com seus requisitos e grupos de usuários, adotando, por exemplo, clientes gordos ou off-lines para a.

(36) 2.1 Evolução do modelo de disponibilização de informações da Web manipulação de muitos dados e clientes magros para a realização de consultas pelo público em geral.. 2.1.4 Objetos distribuídos A evolução da tecnologia de objetos distribuídos e componentes “plug and play” para o desenvolvimento de software, por um lado, e do modelo de código móvel da Web, por outro, permite criar aplicações que, usando os navegadores como containers [PREE96; WOOD97] e interface padrão, podem interagir com vários objetos diferentes, que representam desde bases de dados, até outros sistemas disponíveis na rede. Este é um modelo de disponibilização de informação bem mais complexo, que envolve uma gama de diferentes tecnologias, fabricantes e plataformas operando em conjunto. As aplicações baseadas em objetos distribuídos necessitam de um middleware sofisticado, que permita a objetos localizados em diferentes locais a comunicação entre si. Alguns exemplos desses middlewares são CORBA [OMGRP; MOWB95] (usado por componentes Java Beans [ENGL97]) e DCOM [REDM97] (usado por componentes ActiveX). A tecnologia e os padrões necessários para suportar esse modelo ainda estão em desenvolvimento e, segundo [UMAR97], ainda deve demorar um ou dois anos até que as aplicações com objetos distribuídos sejam usadas em larga escala na Internet.. 2.1.5 Intranets e Extranets O custo relativamente baixo para troca de informação na Internet levou à aplicação das tecnologias usadas na “grande rede” em Intranets [REGL97] – redes menores, privadas, usadas por uma determinada empresa ou organização como ferramenta de comunicação interna e distribuição de informações. As Intranets adotam as tecnologias da Web como base para o desenvolvimento de aplicações internas, gerando WbIS onde é mais fácil determinar o perfil dos usuários e controlar outras variáveis do sistema, como portabilidade e segurança. Algumas corporações estenderam esse conceito criando as Extranets [BAYL98] – redes TCP/IP privadas que interconectam parceiros e clientes comerciais de uma determinada organização.. 23.

(37) 2.2 Classes de WbIS Assim como as Intranets, as Extranets também utilizam WbIS para viabilizar os seus processos comerciais.. 2.2 Classes de WbIS A evolução das tecnologias ligadas a Web levou à evolução do modelo de disponibilização de informações da rede e, consequentemente, à novas aplicações e funcionalidades dos WbIS. De maneira geral, as mudanças observadas apontam para uma mudança do “paradigma da página” para o “paradigma da programação” [POWE98a]. Isto é, impulsionados pela tecnologia, os WbIS têm feito um uso cada vez maior de programação, inicialmente com CGI e as linguagens de script, e depois com código móvel e objetos distribuídos. Essa “mudança de paradigma” na Web não impacta apenas a funcionalidade e poder computacional dos sistemas baseados na rede. Ela tem sérias conseqüências no desenvolvimento dos sistemas. A medida que aumenta a quantidade de programação, o desenvolvimento torna-se mais complexo e caro, são necessárias ferramentas profissionais e uma equipe cada vez mais especializada. [POWE98a] ilustra bem a diferença de paradigmas ao comparar a importância da realização de testes em sites estáticos e em WbIS complexos – WbIS com problemas podem não apresentar apenas links errados, mas exceções fatais e perdas de dados dos usuários. Levando em consideração a quantidade de programação e a motivação para usar a Web, podemos dividir os WbIS em três classes distintas, que descrevemos a seguir.. 2.2.1 Os sites de presença institucional e de conteúdo Os sites de conteúdo são baseados no modelo tradicional de editoração e venda de espaço publicitário. Alguns exemplos são as revistas e jornais on-line. Já os sites de presença institucional disponibilizam informações corporativas de empresas ou instituições para clientes e parceiros, explorando novas oportunidades de marketing e comércio. O site do Departamento de Informática da UFPE9 é um exemplo. Esses sites usam o paradigma da página, sendo essencialmente estáticos, isto é, previamente construídos e armazenados no sistema de arquivos do servidor Web. Por isso, fala-se que eles 9. O site do DI-UFPE está acessível em http://www.di.ufpe.br.. 24.

(38) 2.2 Classes de WbIS utilizam requisições estáticas de documentos. Eles fazem grande uso de elementos gráficos e de informações interessantes para atrair os usuários, sendo essencial a atuação de um designer gráfico no seu desenvolvimento.. 2.2.2 Os sites de serviços Os sites de serviços são um meio termo entre os sites que usam o paradigma da página e os que usam o paradigma da programação. Eles originaram-se com a possibilidade de gerar páginas dinamicamente e permitem ao usuário realizar consultas (ou requisições dinâmicas de informação) e receber respostas de acordo com os parâmetros fornecidos. Os sites de serviços necessitam de uma boa interface gráfica e usam certo nível de programação, mas não tanto quanto os WbIS transacionais. Alguns exemplos interessantes desses sites são o Weather Channel,10 que fornece a previsão do tempo em vários locais do globo e o Biorritmo11, que calcula o biorritmo dos usuários, baseado em parâmetros passados por eles.. 2.2.3 WbIS transacionais Os WbIS transacionais utilizam o paradigma da programação e provêem grande interação com SGBDs, através da Web. Eles assemelham-se aos sistemas cliente-servidor tradicionais, porém, a grande facilidade de acesso e o extenso número de usuários da Web fazem da rede um meio para a disponibilização de sistemas “globais”, que não seriam viáveis do modo tradicional, devido aos altos custos de implantação e manutenção. Alguns exemplos são os sistemas de home banking e os sistemas usados em livrarias on-line, que mantêm cadastros de livros e clientes de todo o mundo e permitem a compra de livros através da Web. Os WbIS transacionais possuem uma complexidade bem maior que a dos sites de presença institucional, de conteúdo e de serviço. A tecnologia usada para a interação com SGBDs ainda é muito recente e instável e, ao permitir a inserção e atualização de dados pelos usuários, aumentam os riscos relacionados a portabilidade, previsibilidade e segurança do sistema.. 10. Acessível em http://www.weather.com.. 11. Acessível em http://www.pessoais.com.br/bio.. 25.