INPE-12450-TDI/997

PROCESSO DE DESENVOLVIMENTO DE WEB SITES COM RECURSOS DA UML

Isolete Teresinha Dzendzik

Dissertao de Mestrado do Curso de Ps-graduao em Computao Aplicada, orientada pelos Drs. Jos Carlos Becceneri e Maurcio Gonalves Vieira Ferreira, aprovada em 26 de outubro de 2004.

INPE So Jos dos Campos 2005

519.8:303.725.35 DZENDZIK, I. T. Processo de desenvolvimento de web sites com recursos da UML / I. T. Dzendzik. So Jos dos Campos: INPE, 2004. 182p. (INPE-12450-TDI/997). 1.Rede mundial de Computadores (World Web SiteWWW). 2.Websites. 3.Linguagem de Modelagem Unificada (Unified Modeling Language- UML). 4.Desenvolvimento de engenharia. I.Ttulo.

AGRADECIMENTOS

Agradeo aos meus colegas, professores, orientadores e ao INPE no papel de representante de todas as pessoas que, direta ou indiretamente, contriburam com a minha ascenso acadmica. Meus colegas: que tanto me ensinaram, ajudaram e colaboraram para que eu conseguisse aprovao nas oito disciplinas cursadas. ... E como me senti til e feliz quando em determinados momentos tive tambm algo a ensinar e pude colaborar. Meus professores: Drs. Nilson SantAnna, Reinaldo Roberto Rosa, Ulisses Tadeu Vieira Guedes, Antonio Montes Filho, Mauricio Gonalves Vieira Ferreira e Jos Carlos Becceneri por terem ministrado suas disciplinas com tal dedicao e didtica que mesmo as questes mais difceis se tornaram passveis de serem entendidas. Meus orientadores: Jos Carlos Becceneri e Mauricio Gonalves Vieira Ferreira. Vocs foram as provas mais concretas de que vale a pena investir em ns mesmos, crescer, ser bom, ser feliz. O que est a nossa volta se parece conosco, o que merecemos! Agradecer o reconhecimento de Ser agraciado. E como, e quanto me sinto agraciada por perceber que cresci, aprendi muitas lies e me tornei algum melhor. Se isso no fosse Real no os teria merecido como orientadores. Ao INPE: pelo espao fsico e por todas as pessoas com as quais tive contato e que de alguma forma, seja direta ou indiretamente, contriburam para com a minha formao. Contribuies essas que reconheo que existiram na forma de e-mails ou telefonemas informativos, minha entrada na portaria, xerox, emprstimo de materiais, conversas, conselhos, informaes, trocas de experincias, festas, opes de alimentao, passeios etc.

RESUMO O presente trabalho apresenta um processo desenvolvimento de Web sites organizado em trs fases. Para que haja uma linguagem comum entre cliente e equipe de desenvolvedores, o processo faz uso de termos e diagramas da UML. Este processo no prope a criao de uma nova tecnologia, mas o uso de diversas tecnologias em conjunto, representando um processo de desenvolvimento chamado Processo de Desenvolvimento Web com recursos da UML (PDWUML). Este Processo baseado em trs fases: a fase de levantamento de requisitos, a de implementao e de design das interfaces. A fase de levantamento de requisitos levanta os objetivos do domnio e busca as informaes disponveis para que haja o planejamento do Web site; faz o levantamento das necessidades do sistema que so mostradas atravs dos recursos da UML e organiza os requisitos necessrios implementao. A fase de implementao desenvolve os arquivos e diretrios que formam a arquitetura lgica de acordo com um modelo de Estrutura Dinmica (ED), proposto para implementar o PDW-UML. Os requisitos levantados na fase anterior so analisados e utilizados para a composio das interfaces e do sistema navegacional. A fase de design das interfaces fundamenta-se no uso da arte baseada em tcnicas em ferramentas grficas para design na Web e de conhecimentos complementares como da psicologia e da filosofia como auxlio para a realizao artstica e criativa. A proposta para a fase de design uma forma de cultura que envolve tcnicas, arte, esttica e tica como uma base de design.

WEB DEVELOPING PROCESS WITH UML RESOURCES

ABSTRACT This work shows a process of website development organized in three phases. To establish a common language between the client and the development team, it makes use of expressions and UML diagrams. This process does not propose the creation of a new technology, but the use of several existing technologies together, in a method named Web Developing Process with UML Resources (PDW-UML). This process is divided into three phases: Requirement Analysis, Implementation and Interface Design. The Requirement Analysis phase starts from the objectives of domain and researches into the available information for planning of the website; it involves assessment of the system requirements as indicated by the UML resources, and planning for implementation. The implementation phase develops the files and directories that define the logical architecture following a Dynamic Structure (ED) model, proposed for implementation of the PDW-UML. The requirements established in the precedent phase are analyzed and used in the composition of the interfaces and of the navigational system. The Interface Design principally involves the use of the art techniques and graphical tools for web design and complementary knowledge such as psychology and philosophy to assist the artistic and creative realization. The purpose of the design phase is to blend technique, art and aesthetics into good design.

SUMRIO

LISTA DE FIGURAS LISTA DE TABELAS LISTA DE SIGLAS E ABREVIATURAS CAPTULO 1 - INTRODUO ....................................................................................... 19 CAPTULO 2 - TECNOLOGIAS INTERNET E WEB .................................................. 23 2.1 - Tecnologias de Rede e de Banda .................................................................................. 23 2.1.1 - Rede ........................................................................................................................... 23 2.1.2 - Banda ......................................................................................................................... 23 2.1.3 - Uso de Banda no Brasil ............................................................................................. 24 2.2 - Recursos de Softwares Aplicados ao Desenvolvimento Web ....................................... 25 2.2.1 - Softwares de Desenvolvimento de Pginas Web ....................................................... 26 2.2.1.1 - Softwares Geradores de Cdigos ............................................................................ 26 2.2.1.2 - Edio Manual de Cdigos ..................................................................................... 27 2.2.2 - Linguagens de Programao para Pginas Dinmicas .............................................. 29 2.2.2.1 - ASP ......................................................................................................................... 29 2.2.2.2 - PHP ......................................................................................................................... 29 2.2.2.3 - JSP .......................................................................................................................... 31 2.2.3 - Linguagens de Programao Client Side ................................................................... 32 2.2.3.1 - CSS ......................................................................................................................... 32 2.2.3.2 - HTML .................................................................................................................... 33 2.2.3.3 - JavaScript ................................................................................................................ 33 2.3 - Servidores Web (Hosts) ................................................................................................ 34 2.3.1 - Apache ....................................................................................................................... 35 2.3.2 - IIS .............................................................................................................................. 35 2.3.3 - ChiliASP ..................................................................................................................... 36 CAPTULO 3 - PRINCPIOS, NORMAS E PADRES PARA A WEB ...................... 39 3.1 - Princpios de Usabilidade e de Design ......................................................................... 39 3.1.1 - Princpios de Usabilidade .......................................................................................... 39

3.1.2 - Princpios de Design .................................................................................................. 42 3.1.2.1 - Princpios Estticos ................................................................................................. 45 3.1.2.2 - Princpios Artsticos ............................................................................................... 47 3.1.2.3 - Princpios ticos ..................................................................................................... 50 3.2 - Prticas Recomendadas para a Internet (IEEE 2001) ................................................... 52 3.3 - W3C .............................................................................................................................. 53 3.4 - UML ............................................................................................................................. 56 3.4.1 - O uso da Modelagem para Entender Melhor o Sistema ............................................ 57 3.4.2 - Padres ....................................................................................................................... 57 3.5 - Engenharia de Web sites ............................................................................................... 58 3.5.1 - Problemas no Desenvolvimento de Web sites ........................................................... 59 3.5.2 - Diferenas entre a Engenharia de Software e a Engenharia Web .............................. 60 3.5.3 - Principais Atividades ................................................................................................. 61 3.5.4 - Principais Tipos de Requisitos para Web sites .......................................................... 61 CAPTULO 4 - ESTRUTURAS E MODELOS DE WEB SITES .................................. 63 4.1 - Estruturas de Web sites ................................................................................................. 63 4.1.1 - Pgina nica com Links para os Tpicos .................................................................. 63 4.1.2 - Frames ....................................................................................................................... 64 4.1.3 - Pginas divididas com Tabelas .................................................................................. 65 4.2 - Modelos de Web sites ................................................................................................... 65 4.2.1 - HDM .......................................................................................................................... 65 4.2.2 - RMM ......................................................................................................................... 69 4.2.3 - OOHDM .................................................................................................................... 71 4.2.4 - Conallen ..................................................................................................................... 73 4.2.5 - WebML ................................................................................................................... 77

4.2.6 - Tabela Demonstrativa dos Modelos Citados ............................................................. 82

4.2.7 - Modelos Desenvolvidos a Partir dos Modelos Mostrados nesta Seo ..................... 84 4.2.8 - Consideraes Gerais ................................................................................................ 84 CAPTULO 5 - PROCESSO DE DESENVOLVIMENTO DE WEB SITES COM RECURSOS DA UML ......................................................................................................... 87 5.1 - Fase 1: Levantamento de Requisitos ............................................................................ 90 5.1.1 - Requisitos de Contedo ............................................................................................. 90 5.1.2 - Requisitos Operacionais ............................................................................................ 93 5.1.3 - Requisitos de Desenvolvimento ................................................................................ 96 5.1.4 - Modelagem do Domnio ........................................................................................... 98 5.1.4.1 - Interaes e Atividades .......................................................................................... 98 5.1.4.2 - Modelagem das Interfaces Dinmicas .................................................................. 106 5.1.4.3 - Componentes ........................................................................................................ 112 5.2 - Fase 2: Implementao ............................................................................................... 112 5.2.1 - Documentao ......................................................................................................... 113 5.2.1.1 - Descrio do Domnio .......................................................................................... 113 5.2.1.2 - Informaes Gerais ............................................................................................... 113 5.2.1.3 - Convenes ........................................................................................................... 114 5.2.1.4 - Modelagem ........................................................................................................... 118 5.2.1.5 - Atualizao e Manuteno ................................................................................... 119 5.2.1.6 - Documentao On-line ......................................................................................... 120 5.2.1.7 - Armazenamento de Arquivos Originais ............................................................... 120 5.2.2 - Anlise e Seleo dos Requisitos de Contedo ....................................................... 121 5.2.3 - Definio do Tipo de Estrutura ............................................................................... 126 5.2.4 - Definio dos Nveis dos URLs .............................................................................. 132 5.2.4.1 - URLs a Partir de um nico Diretrio .................................................................. 133 5.2.4.2 - URLs a Partir do Diretrio Respectivo de cada Assunto ..................................... 136

5.2.5 - Composio das Interfaces ...................................................................................... 140 5.2.5.1 - Composio dos Arquivos Arquivos-matriz ........................................................ 141 5.2.5.2 - Composio dos Arquivos de Design ..................................................................... 142 5.2.5.3 - Composio dos Arquivos-menu .......................................................................... 143 5.2.5.4 - Composio dos Arquivos de Contedo ................................................................ 145 5.2.6 - Testes do Sistema Navegacional ............................................................................. 148 5.3 - Fase 3: Design das Interfaces ..................................................................................... 149 5.3.1 - Arte e Tcnica como Princpios de Design ............................................................. 152 5.3.1.1 - A arte na Web ....................................................................................................... 153 5.3.1.2 - A esttica na Web ................................................................................................. 156 5.3.1.3 - A tica na Web ...................................................................................................... 159 5.3.1.4 - Consideraes Tcnicas, Artsticas e ticas em Interfaces Web .......................... 160 5.3.1.4.1 - Estrutura de uma Interface ................................................................................. 160 5.3.1.4.2 - Coerncia e Legibilidade dos Textos ................................................................ 161 5.3.1.4.3 - Uso de Metfora e Termos Inadequados para a Web ........................................ 162 5.3.1.4.4 - Peso do Montante de Cada Interface ................................................................. 164 5.3.1.4.5 - Harmonia na Distribuio dos Atributos que Compem uma Interface ........... 164 5.3.1.4.6 - Adoo de um Tipo de Linguagem e/ou Tecnologia ........................................ 165 5.3.1.4.7 - Objetividade ...................................................................................................... 166 5.3.1.4.8 - Canais de Comunicao ..................................................................................... 167 5.3.2 - Avaliaes e testes ................................................................................................... 168 CAPTULO 6 - RESULTADOS ...................................................................................... 171 CONCLUSO ................................................................................................................... 175 REFERNCIAS BIBLIOGRFICAS ............................................................................ 177

LISTA DE FIGURAS

3.1 - Exemplo de design de uma interface ............................................................................ 43 4.1 - Exemplo de links de uma aplicao derivada ............................................................... 68 4.2 - Traduo de links de abstrato para concreto ................................................................. 69 4.3 - Modelo cliente x servidor ............................................................................................ 73 ...................................................... 76 4.4 - cones esteretipos ....................................................................................................... 75 4.5 - Pginas cliente construindo uma pgina servidora 4.6 - Modelo de dados WebML ........................................................................................... 78 4.7 - Especificao de hipertexto do WebML ..................................................................... 79 4.8 - Desenvolvimento de aplicaes Web ............................................................................ 81 5.1 - Viso geral do PDW-UML ........................................................................................... 89 5.2 - Armazenamento de informaes ................................................................................. 92 ......................................................................... 94 5.3 - Arquitetura fsica e arquitetura lgica

5.4 - Organizao hierrquica .............................................................................................. 95 5.5 - Concentrao de custos ............................................................................................... 98 5.6 - Principais atividades e interaes de um Web site 5.7 - Diagrama de atividades com as aes do cliente 5.8 - Diagrama de atividades com as aes da equipe ..................................................... 99 ....................................................... 100 ....................................................... 102

5.9 - Diagrama de casos de uso com as aes dos usurios ................................................ 104 5.10 - Interfaces estticas e dinmicas mostradas em um diagrama de classes .................. 105 5.11 - Casos de uso de interfaces dinmicas ....................................................................... 107 5.12 - Diagrama de classes com o exemplo de um carrinho de compras ........................... 108 5.13 - Diagrama de seqncias do caso de uso Gesto de cadastro .................................... 109 5.14 - Diagrama de seqncias do caso de uso Fazer Compras .......................................... 111 5.15 - Diagrama de componentes ........................................................................................ 112 5.16 - Esteretipo e atributos que compem as interfaces .................................................. 126 5.17 - Organizao, script e design de uma interface com ED ............................................ 127 5.18 - Diviso horizontal com duas clulas ........................................................................ 128 5.19 - Diviso horizontal com trs clulas .......................................................................... 129 5.20 - Diviso horizontal e vertical formando trs clulas 5.21 - Arquivos-matriz em um nico diretrio 5.22 - Arquivos-matriz em diversos diretrios ................................................ 131 .................................................................. 135 .................................................................. 147

5.23 - Arquivos-matriz e arquivos-default em diversos diretrios ..................................... 139 5.24 - Base de incluso para composio dos arquivos-matriz .......................................... 140 5.25 - Arquivo-matriz com meta tags no cabealho 5.26 - Script com instrues de design em CSS 5.28 - Arquivo-menu em um subdiretrio .......................................................... 141 ................................................................ 143 145

5.27 - Arquivo-menu no nvel root .................................................................................... 144 .......................................................................

LISTA DE TABELAS

2.1 - Comparativo entre tecnologias que suportam pginas dinmicas ................................ 31 2.2 - Cliente x Servidor ......................................................................................................... 33 4.1 - Comparativo entre os modelos apresentados nesta seo ............................................ 89 5.1 - Informaes gerais de um projeto de Web site ........................................................... 114 5.2 - Exemplos de referncias de cores ............................................................................... 116 5.3 - Esteretipos e descrio de interfaces ........................................................................ 123 5.4 - Esteretipos dos diretrios .......................................................................................... 133

LISTA DE SIGLAS E ABREVIATURAS

ASP ASP.NET CASE CGI CSS DHTML ED E-R ES EW FAQ FTP GPL HDM HTML HTTP IBOPE ID IEEE IIS JSP MCT NCC OO OOHDM PC PDW-UML PHP RDF RGB RMDM RMM RNP SEPIN SGML SMIL SSI SVG UML URL

Active Server Pages Active Server Pages.NET Computer Aided Software Engeenering Common Gateway Interface Cascading Style Sheets Dynamic Hypertext Markup Language Estrutura Dinmica Entidade-Relacionamento Engenharia de Software Engenharia Web Frequently Asked Questions File Transfer Protocol General Public License Hypertext Design Model Hypertext Markup Language Hypertext Transfer Protocol Instituto Brasileiro de Opinio Pblica e Estatstica Identifier Institute of Electrical and Electronics Engineers Internet Information Server Java Server Pages Ministrio da Cincia e Tecnologia National Computing Centre Object Oriented Object-Oriented Hypermidia Design Method Personal Computing Processo de Desenvolvimento We-UML Page Hypertext Preprocessor Resource Description Framework Red, Green and Blue Relationalship Management Data Model Relationship Management Methodology Required Navigation Performance Secretaria de Poltica e Informtica Generalized Markup Language Synchronized Multimedia Integration Language Server Side Include Scalable Vector Graphics Unified Modeling Language Uniforme Resourse Locator

W3C WAE WebML WWW XML XSL

World Wide Web Consortium Web Application Extension Web Modeling Language World Wide Web Extensible Markup Language Extensible Stylesheet Language

CAPTULO 1 INTRODUO

O desenvolvimento de Web sites envolve assuntos como a engenharia de Web sites, banco de dados on-line, metodologias e modelos, tcnicas de uso de ferramentas grficas, tcnicas de redao e ainda outros assuntos, conforme necessidades especficas. As interfaces Web podem ser consideradas como estticas quando o contedo permanente, e dinmicas quando o contedo gerado a partir de uma consulta a banco de dados, sendo mantido somente durante a permanncia do usurio na interface. Para o desenvolvimento de Web sites os profissionais da Web fazem uso de linguagens e tecnologias, modelos e metodologias de modelagem e de implementao e de tcnicas de uso de ferramentas grficas e de design. Quando um Web site composto somente por interfaces estticas as necessidades de um projeto so mais centradas na escolha das linguagens de desenvolvimento e nas ferramentas de design que sero utilizadas. Quando h interfaces dinmicas, alm da escolha das linguagens e das ferramentas de design necessrio fazer a escolha da tecnologia responsvel pela gerao de pginas dinmicas; do sistema de banco de dados e de uma linguagem de modelagem que possa proporcionar aos desenvolvedores uma viso do sistema como um todo. Softwares servidores de pginas dinmicas como a Active Server Pages (ASP), Java Server Pages (JSP) e Page Hypertext Preprocessor (PHP) tm sido amplamente utilizados para o desenvolvimento de interfaces dinmicas geradas a partir de uma consulta a banco de dados e para o desenvolvimento dinmico que se faz pelo aproveitamento de um ou mais arquivos em diversas interfaces usando diretivas de Server Side Include (SSI). A Unified Modeling Language (UML) utilizada no mercado de software como uma linguagem grfica padro destinada especificao, construo, visualizao e documentao de sistemas de software. Os recursos da UML fazem com que esta linguagem seja comum entre desenvolvedores e administradores de softwares e Web sites. Os Web sites so segmentos de software, onde os conceitos e as atividades prticas mostram os princpios da interao humano-computador. Isso envolve a aplicao de princpios da engenharia, princpios de usabilidade, tcnicas e conhecimentos gerais sobre design de interfaces.

19

Com a disponibilidade de ferramentas fceis de serem utilizadas, muitos desenvolvedores abusam da liberdade de expresso, criatividade e facilidade de acesso e disponibilizam contedos on-line sem considerar critrios de usabilidade para a Web. Em conseqncia disso comearam a aparecer muitos Web sites com problemas resultantes de questes, como: A tecnologia de banda no acompanhou a evoluo dos recursos de desenvolvimento, com isso usurios de banda estreita tm acesso parcial a contedos mais complexos e mesmo usurios de banda larga tm acessos demorados devido a m distribuio de contedo por pgina, muitas vezes desistindo do acesso. H uma dificuldade no entendimento do que design, o que arte e o que engenharia. Isso pode gerar Web sites difceis de serem entendidos, feitos sem uma seqncia lgica, sem um projeto prvio, sem ponderao no uso de cores, imagens e textos, dificultando o acesso ao que se busca. A falta de consistncia de contedo e do projeto como um todo, muitas vezes leva a inconsistncias entre o objetivo de um site e o que se mostra na realidade. Isso pode anular o ideal da Web de encurtar o caminho de acesso a informaes e levar a perda da credibilidade de uma organizao. A maioria dos modelos de desenvolvimento Web prope projetos complexos e apenas possibilidades de uso ao invs de uma forma de uso sistematizada. Isso gera dificuldades de utilizao por parte dos profissionais da Web. Muitos modelos e metodologias de desenvolvimento para a Web j foram apresentados, mas o uso dos mesmos, pelos profissionais da Web ainda bastante reduzido (Seo 4.2). A maioria dos modelos prope solues que so mais voltadas ao desenvolvimento de softwares que para o desenvolvimento de Web sites. E os modelos que apresentam solues para a Web, no apresentam uma forma de implementao que possa proporcionar benefcios para os internautas alm da compreenso pelos desenvolvedores. Um outro problema encontrado na maioria dos modelos analisados (Seo 4.2) que estes trazem propostas ou abordagens muito complexas dificultando a utilizao pelos profissionais da Web. H autores que defendem o ideal artstico para a Web, outros defendem o ideal da engenharia. Este trabalho pretende mostrar algumas diferenas entre o que arte do que engenharia e mostrar onde usar a arte e onde usar a engenharia. Os Web sites so sistemas desenvolvidos 20

para usurios, ento para proporcionar ao usurio um melhor entendimento e um melhor design, necessrio que haja o emprego da arte onde se requer arte e da engenharia onde se requer engenharia. No se trata da criao de uma nova tecnologia, mas do uso formalizado de linguagens e tecnologias para projetar, implementar o Web site com uma estrutura padro e para fazer o design das interfaces. O presente trabalho apresenta um processo de desenvolvimento de Web sites voltado ao desenvolvimento de interfaces de Web sites chamado de Processo de Desenvolvimento Web com recursos da UML (PDW-UML). Para que haja uma linguagem comum entre cliente e equipe de desenvolvedores, o processo faz uso de termos e de diagramas da UML e prope trs fases para a efetiva realizao, destacando o levantamento de requisitos, a implementao e o design das interfaces. A fase de levantamento de requisitos levanta os objetivos do domnio e busca as informaes disponveis para que haja um planejamento do Web site; faz o levantamento das necessidades do projeto e do sistema atravs dos recursos da UML e organiza os requisitos necessrios implementao. Atravs da modelagem e da organizao do requisitos so mostradas algumas semelhanas e algumas diferenas entre a engenharia de software e a engenharia Web, respectivamente. Os principais requisitos para Web sites so os assuntos que compem as interfaces. A partir do levantamento dos assuntos e das informaes necessrias para compor o sistema de hipertexto (links e suas respectivas interfaces) j se pode especificar as necessidades do domnio como um todo e iniciar a implementao. A segunda fase, que representa a implementao, prope uma implementao formalizada e um novo modelo de estrutura para as interfaces, fazendo uso da engenharia Web utilizando conceitos, recursos de software e testes navegacionais. A fase de implementao desenvolve os arquivos e diretrios que formam a arquitetura lgica de acordo com um modelo de Estrutura Dinmica (ED) proposto para implementar o PDW-UML. Os requisitos levantados na fase anterior so selecionados e utilizados para a composio das interfaces e do sistema navegacional. Nesta fase faz-se a previso dos nveis de Uniform Resourse Locator (URLs) e das portas de entrada do usurio no site; fazem-se as convenes de design das interfaces; elabora-se a documentao com as informaes pertinentes ao Web site e as instrues de administrao para os Web designers e fazem-se os testes navegacionais a partir da mquina servidora.

21

A partir de convenes de design e da implementao do sistema, o Web site j apresenta uma esttica resultante do trabalho realizado. No entanto, para que se possa aprimorar o design necessria a visualizao do sistema como um todo. Para que haja uma ateno aos detalhes e um tratamento ao contedo e ao design desenvolvido o PDW-UML prope uma terceira fase. A terceira fase, que trata do design das interfaces, busca aprimorar o que foi desenvolvido nas fases anteriores propondo um tempo e um espao dentro de um processo para que haja a realizao artstica e criativa. A proposta para a fase de design uma forma de cultura que envolve tcnicas, esttica, arte e tica como base para um estilo de design. na terceira fase que se aprimoram os resultados do trabalho realizado nas fases 1 e 2. Nesta fase o que predomina a arte e a esttica que podem ser vistas na distribuio dos links nas pginas, nos ttulos, nos cabealhos, nos nomes dos links, nas cores, nas animaes e no design em geral. A fase de design das interfaces considerada como artstica considerando que aps a concluso das fases 1 e 2 j se obteve a funcionalidade desejada. As duas fases anteriores so baseadas em estudos formais e em solues j testadas, representando o papel da engenharia. J nesta fase o resultado pode ser sempre diferente de acordo com a maturidade de cada profissional e do domnio que tm no uso de ferramentas grficas e de design para a Web e de conhecimentos artsticos gerais. Isso representa o papel da arte na Web. Independente de o Web site ser um sistema simples, com poucos links e poucas interfaces e ainda que sejam somente interfaces estticas o PDW-UML poder ser utilizado uma vez que abrange um sistema como um todo. Para aplicaes mais complexas, com interfaces dinmicas e uso de banco de dados, o processo representa uma seqncia lgica e prtica que pode ser seguida pelos profissionais da Web. Este documento encontra-se organizado em 6 sees. Na Seo 2 encontra-se uma pesquisa sobre conceitos bsicos empregados na Internet e na Web. Na Seo 3 faz-se uma introduo sobre usabilidade, design, princpios, normas padres, UML e Engenharia. Na Seo 4 encontra-se o estado da arte mostrando alguns tipos de estrutura e de modelos de Web sites. Na Seo 5 encontra-se a contribuio deste trabalho atravs de um processo de desenvolvimento que envolve levantamento de requisitos, implementao e design de interfaces. Na Seo 6 mostram-se alguns resultados obtidos.

22

CAPTULO 2 TECNOLOGIAS INTERNET E WEB

Nesta Seo apresentam-se as tecnologias que envolvem a Internet, que a rede mundial de computadores, e a Web, abreviatura de WWW (World Wide Web), que a interface grfica da Internet disponvel atravs de servidores de arquivos (HTML e outras extenses Web). Esses servidores so mquinas conectadas rede para disponibilizar a interface grfica (Franklint, 2001). 2.1 - Tecnologias de Rede e de Banda As tecnologias de rede e de banda que formam a Internet propriamente dita. A seguir so mostrados alguns conceitos sobre rede, banda e uma pesquisa sobre o uso de banda no Brasil. 2.1.1 - Rede Uma rede a interconexo entre diversos computadores e outros dispositivos, por meio de cabos, ondas de rdio ou satlite. Uma rede pode ser definida como um grupo de pontos, estaes e ns, interligados e o conjunto de equipamentos que os conecta. A transmisso de dados se d por um canal de comunicao. H vrias modalidades de transmisso: analgica, serial, sncrona e assncrona. Para que haja uma conexo necessria a existncia dos componentes fsicos como os computadores com placas de rede, os cabos, os hubs, os conectores etc. Aps a instalao dos componentes fsicos necessria configurao das mquinas atravs de protocolos que habilitem as mquinas para se comunicarem atravs de uma linguagem comum para que possam trocar dados entre si (Bruce, 2002). 2.1.2 - Banda Toda vez que se faz uma comunicao entre dois pontos, diz-se que essa comunicao acontece atravs de um canal ou banda. Por exemplo, quando duas pessoas falam atravs do telefone comum, elas usam o canal telefnico ou banda telefnica (Drgnescu, 2003). Banda uma faixa de freqncias delimitada, por onde passam as informaes de rdio, tv e Internet. O regulamento das telecomunicaes reserva bandas diferentes para cada meio de mensagem a fim de evitar a interferncia entre os sinais. A largura de uma banda de 23

freqncias eletromagnticas est diretamente ligada rapidez com que os dados fluem. Quanto maior a largura de banda, mais informaes podem ser enviadas num dado intervalo de tempo. As bandas so classificadas como banda estreita e banda larga, de acordo com suas respectivas capacidades de transmisso de dados (Bruce, 2002). 2.1.3 - Uso de Banda no Brasil Ao iniciar um projeto de um Web site necessrio considerar um possvel perfil dos usurios predominantes deste Web site, como por exemplo: A velocidade de acesso que utilizam em seus computadores; Alguns gostos/preferncias e hbitos mais comuns; A tolerncia de espera no carregamento das pginas chamadas.

No Brasil quem faz pesquisas sobre o perfil dos internautas do Brasil e do mundo o grupo IBOPE eRatings. O IBOPE eRatings uma joint-venture entre o Grupo IBOPE e a Nielsen NetRatings, lder mundial em medio de audincia na Internet. O IBOPE eRatings vende os dados e anlises aos grandes portais, bancos, agncias de publicidade, revistas, que fazem uso destes dados em tomadas de deciso (IBOPE, 2004). Alm do IBOPE eRatings, existem outros rgos como jornais, revistas e empresas especializadas em pesquisas, que fazem levantamentos sobre perfis de internautas. Algumas consideraes extradas de pesquisas precisam ser levadas em conta para fazer o planejamento de um Web site para que as pginas que o compem tenham o design e a velocidade atrativos ao usurio. Consideraes sobre as condies de acesso: uma pesquisa do IBOPE eRatings em setembro de 2000 mostra que 70% dos internautas so usurios residenciais e que a maioria usa acesso com o sistema discado e banda estreita ou convencional, onde a velocidade no chega a atingir 56 Kbps (Kilobits por segundo) (SEPIN, 2000). De acordo com um levantamento feito em novembro de 2002, o Brasil j tinha 14,3 milhes de internautas residenciais ativos. Alm disso, existem muitos usurios comerciais que tambm utilizam banda convencional e acesso discado. Nmero de usurios de banda larga no Brasil em 2004: segundo informaes disponveis no site do Ministrio da Cincia e Tecnologia (MCT), o Brasil encerrou 24

o ano de 2003 com 1,1 milhes de usurios de banda larga, o que corresponde a 6,4% dos 17 milhes de internautas (MCT, 2004).

2.2 - Recursos de Softwares Aplicados ao Desenvolvimento Web Os recursos de software disponveis para desenvolvimento de Web sites so os mais diversos possveis que vo desde softwares geradores de HTML, JavaScript, CSS (Cascading Style Sheets), at os que trazem um servidor de scripts de pginas dinmicas, como o Apache e o IIS (Seo 2.2.2). O que se deve considerar ao escolher uma forma de desenvolvimento que um Web site no ser visto somente pelos usurios na mquina em que foi desenvolvido e sim em uma mquina servidora, a qual nem sempre oferece os mesmos recursos que a mquina de cada usurio. Por isso, necessrio antes de comear a desenvolver um Web site, saber em que tipo de servidor ficaro os arquivos e a possibilidade de que um dia poder ser necessrio fazer uma troca de servidor. As implementaes em HTML no costumam apresentar muitas diferenas de um navegador para o outro. Quando se utiliza uma linguagem que precisa dos recursos de um software para ser processada, necessrio considerar que a mquina servidora dever ter a mesma tecnologia que a mquina cliente. Por exemplo, independente do sistema operacional que o desenvolvedor esteja usando, se ele tiver o Internet Information Server (IIS) ou o Apache como servidor de pginas dinmicas, a mquina servidora tambm precisar ter o IIS, Apache ou semelhante (Br.php.net, 2003). Os problemas aparecem ao se utilizar linguagens que so processadas diretamente no navegador ou no lado cliente (Client Side), porque nem todas as verses ou tipos de navegadores reconhecem todos os recursos de uma linguagem. O mesmo ocorre ao utilizar softwares geradores de cdigos porque nem todos os servidores reconhecem as formataes geradas por estes softwares. Uma sada conhecer os recursos existentes, seus limites, vantagens, sua relao custo-benefcio e testar os resultados dos scripts na mquina servidora antes de disponibilizar um Web site ao pblico.

25

2.2.1 - Softwares de Desenvolvimento de Pginas Web Existem duas maneiras de se desenvolver um Web site: utilizando softwares geradores de cdigos ou fazendo edio manual dos cdigos, digitando os comandos em um editor de texto e visualizando o resultado atravs do navegador. Cada linguagem oferece recursos e algumas funes que uma outra no possui. Por isso necessrio saber quais os recursos que sero necessrios a um Web site para escolher o que ser usado ao invs de fazer uma opo sem critrios por uma linguagem em detrimento da outra. Entre tantas linguagens existentes difcil determinar qual a melhor. O que se pode determinar qual a melhor para uma aplicao especfica. Como no possvel saber com preciso quais recursos existem na mquina dos usurios, uma sada reduzir ao mximo os recursos que dependem da mquina do usurio, utilizando recursos que dependem da servidora. Alguns critrios que devem ser considerados ao escolher uma linguagem: A linguagem escolhida suportada pela mquina servidora disponvel para a aplicao em questo? As seqncias de comandos (scripts) destinam-se a mquina cliente ou a servidora? Que navegadores ou servidores possuem os recursos que sero necessrios para a exibio das pginas? (Microsoft Corporation, 1998). 2.2.1.1 - Softwares Geradores de Cdigos Existem centenas de softwares geradores de cdigos HTML e com extenses ao JavaScript, DHTML, CSS e outras linguagens. Alguns so freeware e outros licenciados. Estes softwares facilitam a montagem de pginas, pois o usurio trabalha atravs de instrues disponveis em cada software, como instrues de inserir link, imagens, troca de fonte e demais recursos do HTML. As limitaes quanto ao uso de softwares geradores de cdigos so: Reconhecimento de formataes: na mquina local possvel visualizar o que est sendo desenvolvido, mas quando se faz o envio dos arquivos mquina servidora as pginas podem no ser exibidas na ntegra, pois os recursos da mquina servidora no conseguem ler todas as formataes. O Microsoft Front Page, por exemplo, precisa de um servidor que tenha recursos habilitados para ler suas formataes e 26

mostrar as pginas como foram desenvolvidas, causando uma dependncia de criao e hospedagem em ambiente Microsoft. Vinculao de verses de softwares: como acontece com outros tipos de softwares, quando se usa uma verso mais recente para abrir e dar seqncia em trabalhos que tenham sido feitos em verses anteriores, no h problemas, mas quando se busca o inverso, dependendo da complexidade do documento a verso anterior no reconhece ou mostra parcialmente o que foi feito na verso mais recente. Falta de flexibilidade dos desenvolvedores e administradores: um profissional que esteja habituado a um determinado software, ser um especialista naquele software, tendo que reaprender a trabalhar em caso de mudana de software ou necessidade de programao. Essa falta de flexibilidade gera discusses a respeito de qual software melhor ao invs de o que melhor para o usurio. Um outro inconveniente no uso de softwares geradores de cdigos que o contedo das pginas adquire as formataes do software que os gerou. No caso de reaproveitamento de contedo em outras tecnologias necessrio que os mesmos sejam refeitos. 2.2.1.2 - Edio Manual de Cdigos Na maioria das linguagens necessrio escrever comandos em texto normal (em um editor de texto), coerentes com a sintaxe e com a estrutura da prpria linguagem. Estes comandos so popularmente chamados de cdigo fonte, ou simplesmente cdigo. A utilizao dos cdigos das linguagens um pouco mais complexa do que a utilizao de softwares que geram cdigos automaticamente, pois atravs dos softwares apenas se escolhe opes e digitam-se os textos, enquanto que o uso dos cdigos representa conhecer e digitar os cdigos que formam os scripts e os textos que formam os contedos. Isso exige uma compreenso maior por parte dos desenvolvedores, pois tanto erros de cdigo como de contedo podem passar desapercebidos com mais facilidade. Ao usar edio manual de cdigos aumentam as possibilidades de erro de formatao de tags e dos textos que representam o contedo. Se finalizar ou iniciar uma tag ou uma seqncia de tags de forma errada ou em um local errado, pode-se comprometer o design de uma pgina e sem corretor ortogrfico no editor de textos, a responsabilidade da correo recai sobre quem

27

est digitando. Uma sada para evitar erros de programao usar editores inteligentes como o PHP Editor, por exemplo, que avisam o usurio atravs de colorao no cdigo fonte, quando alguma tag no est bem formulada (NCC, 1999). Com a edio manual possvel obter as seguintes vantagens: Simulao de ambientes: torna-se mais fcil ter instalado na mquina cliente os mesmos recursos que se tem na mquina servidora. Isso evita diferenas de design de uma mquina para a outra. Reduo de custos: os custos so referentes ao hardware ou ao sistema operacional, quando este licenciado. Normalmente, o sistema operacional j traz um servidor de pginas dinmicas, editor de texto e navegador, no havendo necessidade de investir em softwares especficos para desenvolvimento de pginas. Aumenta a portabilidade: permitindo que ao mudar as interfaces ou mudar a tecnologia, seja reaproveitado o contedo informativo. Por exemplo, para processar uma pgina feita em ASP, que um recurso do Windows, possvel instalar um servidor de ASP no UNIX, no LINUX, bem como possvel instalar um servidor de PHP no IIS. Ainda que fosse necessrio mudar de ASP para PHP, por exemplo, toda a estrutura e todo design poderiam ser mantidos, trocando somente a linguagem responsvel pela estrutura. Aumenta a flexibilidade: uma vez que se aprende a utilizar uma linguagem e a forma de desenvolvimento, ao trocar de linguagem s necessrio conhecer os comandos da nova linguagem, e o processo de desenvolvimento ser o mesmo. Facilita o reaproveitamento do contedo quando muda o design: a nica constante na Web a mudana. Assim, de tempos em tempos torna-se necessrio trocar o design das interfaces de um Web site, porm o contedo ser o mesmo ou sofrer apenas alguns acrscimos. Quanto menos instrues de interface estiverem junto aos arquivos de contedo, mais fcil ser o reaproveitamento e as possibilidades de se ter um Web site sempre com design atual (Microsoft Corporation, 1998), (NCC, 1999).

28

2.2.2 - Linguagens de Programao para Pginas Dinmicas As linguagens de programao para pginas dinmicas podem ser utilizadas para o desenvolvimento dinmico que feito com as diretivas de SSI ou para a gerao de pginas dinmicas atravs da consulta a bancos de dados. Esta Seo mostra alguns recursos disponveis na rea de desenvolvimento de aplicaes de pginas dinmicas para a Web, como ASP, PHP e JSP. 2.2.2.1 - ASP A Active Server Pages (ASP) uma tecnologia orientada a objetos, criada pela Microsoft, utilizada para desenvolver pginas HTML dinamicamente. A ASP trabalha com linguagem de scripts VBScript baseada no Visual Basic da prpria Microsoft. Em linguagens de programao Web, utilizam-se tags, que so etiquetas identificadas pelos sinais < e >, que delimitam textos e cdigos que sofrero algum tipo de formatao (Bell, 2000). Na linguagem VBScript os sinais < e > so acompanhados do smbolo % (percentual), tendo portanto, a identificao <% e %>. Para que arquivos com extenso ASP sejam interpretados necessrio um servidor de pginas ASP que interprete os cdigos do VBScript que esto entre as tags <% e %> e envie ao navegador o HTML gerado (Chase, 2000). As pginas ASP so desenvolvidas e processadas em Sistemas Operacionais como o Windows NT/ 2000/XP que fornece o IIS ou UNIX/LINUX com o servidor ChiliASP da Chilisoft (Seo 2.3.3). A tecnologia ASP dispe do recurso de Server Side Include (SSI) que um processo em que o servidor utiliza as informaes de um arquivo e as inclui como parte de outro. A tecnologia ASP j em si uma espcie de SSI, na qual o servidor utiliza um arquivo HTML e procura por comandos que precisam ser executados e inseridos antes de retornar uma pgina como resultado dos scripts incorporados (CHASE, 2000). 2.2.2.2 - PHP A PHP (Hypertext Preprocessor) uma linguagem de script, Open Source de uso geral, interpretada, muito utilizada para o desenvolvimento de aplicaes Web, podendo ser mesclada dentro do cdigo HTML. A PHP surgiu em 1994 como um projeto pessoal de 29

Rasmus Lerdorf com o intuito de controlar acessos a sua pgina Web. Atualmente a PHP um projeto da Apache Software Foundation. A tecnologia PHP incorpora a linguagem PHP que baseada nas linguagens C, Java e Perl e ainda pode ser vista como uma combinao de linguagem de programao e servidores de aplicaes. A linguagem PHP executada no servidor, sendo enviado para o cliente apenas HTML gerado em uma requisio. O objetivo principal da linguagem permitir aos desenvolvedores escrever pginas que sero desenvolvidas ou geradas dinamicamente. Os scripts PHP so entendidos e processados pelo servidor de PHP, entre as tags : <?php echo ... ?>: <?php echo("modelo preferencial usado para dispor documentos XHTML ou XML,\n"); ?>. <?echo ... ?>: <? echo ("modelo mais simples, como uma instruo de processamento SGML\n"); ?> <?= expresso ?> Uma reduo de "<? echo expressao ?>". <script language="php">. . .</script>: <script language="php"> echo ("processa instrues"); </script>. <% echo ... %>: <% echo ("para usar tags ASP opcionalmente, quando se ativa a diretiva asp_tags no arquivo de configurao"); %>. A linguagem base da PHP a JavaScript que quando usada fora de um software servidor de PHP uma linguagem interpretada na mquina cliente. Quando utilizada em um servidor de PHP chamada de linguagem PHP e interpretada no servidor. A PHP tem como principais caractersticas (Br.php.net, 2003): Cdigo Aberto: todo o cdigo fonte da PHP est disponvel, basta ir ao Web site oficial e fazer o download.. Multiplataforma: a PHP pode rodar sobre o Unix, Linux ou Windows. Acesso a Bancos de Dados: acessa diretamente os principais bancos de dados utilizados atualmente, como dBase, Interbase, PostgreSQL, e outros (Br.php.net, 2003). MySQL, Oracle, SyBase,

30

2.2.2.3 - JSP A Java Server Pages (JSP) baseada na linguagem Java, criada pela Sun Microsystens, para simplificar o processo de desenvolvimento dinmico de Web sites. A JSP funciona como um compartimento que incorpora elementos dinmicos. A JSP uma linguagem de script, compilada, que funciona no lado do servidor, ou seja, as pginas JavaServer so arquivos texto, normalmente com a extenso ".jsp" que substituem os arquivos estticos HTML. As pginas JSP, alm de utilizar objetos do servidor, podem incorporar e manipular objetos prprios, como Applets e Servlets. A JSP um sistema hbrido de templates, parecido com ASP e PHP. A linguagem padro utilizada nas JSP's Java puro, mas qualquer tipo de linguagem de script pode ser utilizada no lugar do Java, como ASP, PHP, XML e ColdFusion. As novas especificaes da JSP 1.1 implementam tags especiais que substituem o cdigo Java puro dentro da pgina JSP. Os servlets e a JSP, em 1998, tiveram suas primeiras verses incorporadas ao Java Web Server. Antes mesmo da Sun lanar a verso JSP 1.1, a parceria com a Apache gerou o Projeto Jakarta, permitindo a integrao dos softwares de ambas as empresas. Isso resultou em um projeto que tem como objetivo desenvolver um cdigo aberto para implementar aplicaes Java no servidor mais utilizado do Linux e Unix, o Apache Server (Medeiros, 2002). Para melhor entender as tecnologias citadas na Seo 2.2.2, mostra-se uma tabela comparativa, destacando as principais caractersticas. TABELA 2.1 - Comparativo entre tecnologias que suportam pginas dinmicas. Caractersticas Arquitetura Uso de scripts Segurana Acesso base de dados Personalizao de tags FONTE: Medeiros (2002). O uso de uma ou de outra linguagem se d de acordo com a experincia de cada profissional e com prioridades e necessidades de cada projeto. 31 ASP PHP Fechada Aberta VBScript e JScript JavaScript Baseada na Versatilidade de arquitetura do NT configurao de segurana de acesso ADO DBASE, Interbase, MySQL, Oracle, PostgreSQL No pode ser No pode ser ampliado ampliado JSP Aberta Modelo de segurana do Java JDBC Ampliado atravs do uso de biblioteca

2.2.3 - Linguagens de Programao Client Side As linguagens de programao para a Web so os scripts que compem os cdigos ou seqncias de cdigos, que formam os arquivos existentes em um Web site. Algumas linguagens so interpretadas na mquina cliente (Client Side) onde o contedo gerado exibido conforme os recursos disponveis em cada navegador. Se o navegador no tiver os recursos que esto nos scripts, o usurio ser privado de visualizar parte do contedo. As linguagens interpretadas em um servidor (Server Side) dependem do servidor para interpretlas, assim quando um usurio faz uma requisio, a servidora processa os scripts que compem a pgina e devolve ao cliente somente o resultado na forma de HTML. (Mendes,1999), (Haddleton, 1997). A Tabela 2.2 mostra algumas caractersticas de mquinas cliente versus servidoras. TABELA 2.2 - Cliente x Servidor. Cliente Quem quer a informao Usurio Quem quer usar um intermedirio Traduz as solicitaes Exibe hiperdocumentos FONTE: Haddleton (1997). Algumas linguagens de programao client side, amplamente utilizadas para a Web so mostradas a seguir. 2.2.3.1 - CSS A Cascading Style Sheets (CSS) foi introduzida quando do lanamento do navegador Internet Explorer 3. Logo em seguida, quando lanou a verso 4 do Netscape Communicator, a Netscape tambm aderiu a esse padro. Porm quando a Microsoft lanou a verso 4, ela j agregou vrias funcionalidades novas, que entretanto se mostraram incompatveis com o Netscape. Aps o lanamento do Internet Explorer 5, com uma carga enorme de funcionalidades para a CSS, as diferenas cresceram, e com elas mais problemas de incompatibilidade entre navegadores. Por isso, para utilizar CSS necessrio testar em diversos navegadores, os recursos que sero implementados em um Web site, para permitir que os usurios no deixem de ver o contedo 32 Servidora Quem tem a informao Fornecedor Quem tem o recurso Continuamente, escuta e atende os pedidos de clientes Fornece hiperdocumentos disponveis em seu acervo Processa cdigos de pginas ativas e devolve ao cliente em forma de hiperdocumentos

e os que tiverem as verses mais recentes de navegadores ainda o vejam de uma forma mais completa. As folhas de estilo facilitam o trabalho de um Web design quando se trata de garantir uma formatao homognea e mais criativa por todas as pginas de um Web site e ainda permite mais interatividade com o usurio. Mesmo que se deseje mudar todo o design, ou um certo grupo de formatao, as folhas de estilo permitem que uma alterao possa repercutir em todas as pginas do Web site. As folhas de estilo podem ser comparadas a um gabarito de formatao de pginas HTML. Ela permite que se alterem quase todas as tags da linguagem HTML. Sua limitao est na falta de reconhecimento por algumas verses de navegadores, sendo utilizada, portanto, como uma linguagem complementar ao HTML. As instrues de CSS so inseridas entre as tags <STYLE > e </STYLE>. Basta que se insira uma vez a tag no cdigo para que toda a pgina responda s instrues (Bos, 2003). 2.2.3.2 - HTML A linguagem HTML foi criada com o objetivo de dar rede mundial de computadores um aspecto grfico. At a criao de HTML, as ferramentas existentes, tais como ftp, gopher e telnet, rodavam em terminais de caracteres e, apesar de muito teis e bastante populares no meio acadmico, eram muito pouco atrativas para o grande pblico. A HTML, em conjunto com o protocolo HyperText Transfer Protocol (HTTP) e com os navegadores, foi a responsvel pela popularidade da Internet. No se trata de uma linguagem de programao propriamente dita, mas de uma linguagem de formatao, que define um conjunto de tags que afetam a maneira como os documentos so exibidos pelo navegador. A HTML consiste em uma linguagem de descrio de textos que usada como padro internacional para formatao dos documentos na Web, na forma de aplicao de Standard Generalized Markup Language (SGML). Para trabalhar com HTML, utiliza-se um editor de texto e um navegador para visualizao (Franklint, 2001). 2.2.3.3 - JavaScript Os scripts escritos em JavaScript podem ser colocados dentro das pginas HTML, pois se trata de uma linguagem de script que processada diretamente no navegador, dispensando a 33

ajuda de um servidor. Ao contrrio da HTML que uma linguagem esttica, com a JavaScript se fazem animaes com textos e imagens e diversas interatividades com usurios, sendo assim considerada um acessrio da HTML. A linguagem JavaScript possibilita o uso de diversos objetos na composio de uma pgina. Todos eles possuem propriedades que podem ser alteradas, alm disso, os objetos fornecem eventos que possibilitam que uma pgina execute uma ao conforme instruo de um usurio. JavaScript uma linguagem estruturada que usa objetos, mas no uma linguagem de programao orientada a objetos. Os objetos so usados para representar algum aplicativo. Sua utilizao requer um editor de texto e um navegador para visualizao (NCC, 1999). 2.3 - Servidores Web (Hosts) Um servidor um programa que prov algum tipo de servio para outros programas, denominados clientes. A conexo entre clientes e servidores implementada normalmente atravs de passagem de mensagens, por meio de uma rede, utilizando algum protocolo para codificar as requisies dos clientes e as respostas do servidor (Haddleton, 1997). Um Web site um conjunto de documentos ou pginas com padro Web, que pode ser acessado atravs da rede mundial Internet. Estes documentos tm um endereo prprio (tambm chamado domnio) que est localizado na mquina servidora Web. No Brasil este endereo (domnio) autorizado/fornecido pela Fundao de Amparo Pesquisa do Estado de So Paulo (FAPESP). Existem muitos tipos de servidores Web, com vrias alternativas de recursos, inclusive gratuitos, no Brasil e no Exterior. Servidor a denominao mais comum dada a um computador permanentemente conectado Internet, de forma que usurios possam acessar os arquivos desses servidores, bastando fazer uso de um computador conectado Internet. As pginas disponveis na Internet permitem vrios tipos de interatividades com o usurio. As pginas feitas basicamente em HTML oferecem pouca interatividade. Sua interatividade limita-se em clicar em links para abrir uma nova pgina, copiar contedos e fazer download de arquivos (Chase, 2000). Linguagens como CSS e JavaScript oferecem auxlio ao HTML para que as pginas tenham um pouco mais de interatividade e movimento. Porm a CSS no reconhecida por todos os navegadores e o JavaScript, pode ser desabilitado dos navegadores, pelos usurios. 34

Devido a essas limitaes que foram criados os servidores de pginas dinmicas, que so softwares que trazem recursos para interpretar determinados cdigos e extenses de arquivos. Com isso o usurio no fica privado dos recursos utilizados no desenvolvimento, pois o software servidor de pginas dinmicas que se encarregar de processar os arquivos com as extenses por ele reconhecidas e devolver ao usurio o HTML gerado. Isso possibilita o desenvolvimento dinmico e mais interatividade nas pginas, independente do navegador, conforme mostrado na Seo 2.2.3. Destacam-se a seguir alguns servidores Web. 2.3.1 - Apache O Apache um software livre (GPL) que funciona como um servidor Web, tanto no Linux como no Windows. O Apache um projeto de desenvolvimento colaborativo com objetivo de desenvolver o melhor servidor Web em performance, robustez, flexibilidade e com padres de excelncia e qualidade. O Apache tem em seu grupo de trabalho programadores das Universidades MIT, Berkeley, Stanford e empresas como IBM, Sun, HP, Compaq, RedHat e diversas outras. Entre suas principais caractersticas est multi-plataforma, robustez, performance, adaptabilidade, gratuidade e boa documentao. Ele tem vantagens em cima dos outros servidores, como cdigo fonte completo e uma licena irrestrita. compatvel com a especificao HTTP/1.1, permite mudanas em suas caractersticas mesmo as mais internas atravs da utilizao de mdulos (isso implica em flexibilidade) e tem sua prpria API padronizando toda programao interna. (The Apache Software Fondation, 2002). 2.3.2 - IIS O Internet Information Server (IIS) faz parte da famlia Microsoft Windows Server que uma integrao de servidores local e Web. O IIS um software para criao e hospedagem de aplicaes Web dinmicas, gerenciamento de FTP e SMTP. O IIS responsvel pelo processamento das pginas ASP, podendo tambm processar pginas PHP, desde que este recurso seja instalado (Microsoft Corporation, 2003).

35

2.3.3 - ChiliASP Com o lanamento do software ChiliASP da empresa ChiliSoft, para rodar em servidores Unix, Netscape e Lotus, a Microsoft deixou de ser a nica responsvel pelo processamento e hospedagem de pginas ASP. A verso do ChiliASP foi sendo ampliada, primeiro para os servidores Netscape e Solaris e mais tarde para outras verses do Unix (incluindo Linux). A ChiliSoft no foi contratada pela Microsoft para oferecer estes servios, mas a Microsoft tambm no foi totalmente contra as realizaes da ChiliSoft em expandir a tecnologia Microsoft para outros servidores. O ChiliASP oferece suporte completo a ASP, incluindo objetos como Session e Request, mesmo sendo a Microsoft, a proprietria dessa tecnologia. Isso significa que possvel usar uma base Unix para desenvolver e processar scripts ASP. O que ocorre que est havendo uma certa resistncia dos profissionais da Web em aceitar trabalhar com a tecnologia Unix ASP. A questo sobre at que ponto vivel utilizar uma tecnologia base do Windows em um ambiente Unix. Uma possvel resposta referente a plataforma Windows que h um nmero vasto de ferramentas de desenvolvimento e desenvolvedores experientes que usam essas ferramentas. Muitas empresas querem utilizar as ferramentas disponveis no Windows e a experincia que tm ao trabalhar com servios de Internet e Intranet, o que no significa que aplicativos desenvolvidos em Windows tenham que ser mantidos no IIS e no Windows NT/2000. H empresas que preferem usar a praticidade e a versatilidade do Windows e o desempenho, segurana e estabilidade do Unix como servidor, de Internet e Intranet. Alm disso, muitas tecnologias do Windows poderiam ser utilizadas no servidor Unix, como o desenvolvimento de aplicaes com VBScript e ASP, sem a necessidade de um desenvolvedor ter que aprender a programar em uma nova linguagem ou usar uma nova tecnologia (Sun.com, 2003), (Yager, 1999). O que se pode afirmar que constante na Web so as mudanas. Se por um lado isso faz com que novos recursos, linguagens e ferramentas sejam disponibilizadas, por outro lado traz dificuldades para que os profissionais conheam o que h disponvel. Na maioria das vezes difcil adotar uma linguagem, ferramenta ou servidor de pginas dinmicas e considerar como sendo a melhor soluo para todas a situaes. H profissionais que preferem fazer uso de codificao manual, outros preferem usar ferramentas de design e codificao. Para um usurio dos sistemas UNIX/LINUX, uma soluo pode ser a utilizao de linguagens, editores e demais ferramentas que melhor se adaptem aos servidores utilizados por estes 36

sistemas. Uma outra questo que pode auxiliar na escolha de recursos fazer uma anlise das necessidades especficas de cada domnio e encontrar as melhores solues para tais necessidades.

37

38

CAPTULO 3 PRINCPIOS, NORMAS E PADRES PARA A WEB

Nesta Seo mostram-se alguns princpios, normas, padres e recursos da UML e da Engenharia Web aplicados ao desenvolvimento de Web sites. 3.1 - Princpios de Usabilidade e de Design Muito se discute sobre o que so questes de usabilidade na Web e o que so questes de design. Nesta Seo so mostrados alguns conceitos e exemplos que visam mostrar caractersticas pertinentes usabilidade e ao design. Reconhece-se tambm que h questes que podem ser consideradas em ambos os casos como, por exemplo, onde uma opo de design pode melhorar ou comprometer a usabilidade (contraste entre cor de fundo e cor de fonte uma opo de design que pode interferir de forma positiva ou negativa na usabilidade). 3.1.1 - Princpios de Usabilidade Usabilidade significa facilidade de uso. Alguns princpios de usabilidade desenvolvidos para serem usados pela engenharia de software tambm so utilizados pela engenharia Web. A engenharia da usabilidade baseada em vrios segmentos como, por exemplo, a psicologia cognitiva, a sociologia, a ergonomia, a semitica e a engenharia de software. A usabilidade representada por um subsistema do software interativo cujos componentes e processos analisam a interao com seus usurios. Assim um nico sistema de interface humanocomputador permite vrias interaes humano-computador, cada uma associada aos diferentes percursos (processos) realizados pelos diferentes usurios (Leite, 2002). A usabilidade considera algumas questes a serem formuladas e de acordo com as respostas obtidas pode-se ter uma noo do nvel de usabilidade de um sistema. Contexto: onde o sistema interativo ser empregado, incluindo componentes como usurios, tarefas e ambiente (equipamento, instalaes, iluminao, rudo, organizao, interrupes, restries etc.).

39

Problemas: Onde encontrar o que se procura? Como solicitar esse servio? Quais informaes devem-se fornecer? Qual o resultado? Obteve-se o resultado esperado? Para que serve esse elemento? O que significa essa figura? Para onde leva esse link?

Facilidade de aprendizado: interao com o sistema de forma natural; facilidade de utilizao; interface preparada para adaptar-se ao nvel de conhecimento e habilidade dos usurios (wizards para os inexperientes e teclas de atalho para os mais experientes); ser intuitiva; comandos claramente visveis para evitar memorizao.

Dilogo simples e natural: expresses e conceitos do conhecimento do usurio; evitar termos tcnicos da computao; evitar informaes irrelevantes; feedback ao usurio; mecanismos para informar comportamentos do sistema como localizao e tempo de execuo.

Clareza na arquitetura da informao: o usurio consegue discernir o que prioritrio e o que secundrio no site; informao deve estar estruturada e bem localizada; um mapa do site pode ser muito til.

Facilidade de Navegao: navega-se com facilidade quando um usurio chega informao desejada em at trs nveis; as informaes so bem distribudas e os links so representativos.

Simplicidade: quanto mais rpido consegue-se chegar at a informao desejada, melhor ; evitar adornos desnecessrios, sem prejudicar o enfoque da aplicao.

Relevncia do contedo: contedo relevante e apropriado para a Web; textos concisos e com credibilidade; informaes relevantes devem ser apresentadas nas pginas principais; informaes secundrias devem ser disponibilizadas em pginas de suporte e conectadas atravs de links.

Manter a consistncia: um mesmo padro deve ser sempre adotado; mesmo que o contedo mude com freqncia, caracterstica relevante em aplicaes hipermdia, o usurio ter facilidade em lidar com a aplicao, pois j ir conhecer os procedimentos padres.

Foco no usurio: princpio que rene todos os demais. A usabilidade orienta as aplicaes para que foco esteja nas atividades dos usurios. 40

Simbologia: ao se falar de usabilidade na Web, no se pode deixar de levar em considerao que se trata de uma rede mundial, portanto deve-se ter uma preocupao com o processo de internacionalizao. Deve-se ter em mente, que somente o uso de interfaces grficas ou uso de elementos grficos ao invs de palavras no resolve grande parte dos problemas, j que alguns smbolos podem ter interpretaes distintas. necessrio que o projetista de IHC (Interface HumanoComputador) tenha, no mnimo, conscincia de que a usabilidade de sua interface no pode ser dimensionada apenas pelos conhecimentos tcnicos de sua rea especfica de atuao. Usabilidade compreende uma gama de diretivas de diversos ramos de atuao (Leite, 2002).

Em alguns pontos a engenharia de software muito semelhante engenharia Web e conseqentemente as questes de usabilidade podem ser teis a ambas. A usabilidade para Web sites ainda est sendo moldada e muitas questes mostradas como princpios de usabilidade so apenas perguntas ao invs de respostas que poderiam ajudar os profissionais da Web a terem uma base melhor. E h muitas questes que so relevantes para a engenharia de software, mas no so para a engenharia Web. Quando uma equipe desenvolve um sistema de software e implementa dentro de uma empresa, normalmente, realiza-se um treinamento com os funcionrios, mostrando como usar o software de forma mais intuitiva. J quando se disponibiliza um Web site on-line no h como treinar os usurios que faro uso. Assim, o que pode ser intuitivo para usurios de um software local pode no ser para usurios da Web. Em vrias passagens deste trabalho menciona-se o termo intuio e intuitivo. Uma maneira de entender melhor o significado e funcionamento seguir o exemplo mostrado pela psicologia cognitiva para ilustrar a origem do conhecimento humano e as formas de inteligncia (Seo 3.1.2.2) utilizadas para fazer uso dos conhecimentos adquiridos. A origem etimolgica da palavra intuio provm de um verbo latino que significa ver; perceber; discernir; ato ou capacidade de pressentir. uma forma de captar informaes sem recorrer aos mtodos do raciocnio e da lgica. A intuio no se ope razo, apenas h mais probabilidade de acerto quando intuio e razo agem de forma equilibrada, ou quando possvel explicar uma intuio atravs da razo (Thephilo, 2003). Quanto questo das interfaces intuitivas, existe uma grande diferena entre interfaces de softwares convencionais e interfaces de sistemas Web. O problema que autores como,

41

Jakob Nielsen (Nielsen, 2000), por exemplo, propem questes de usabilidade para sistema de softwares e sugerem os mesmos princpios de usabilidade para sistemas Web. Assim o que poderia ser intuitivo em um sistema de software (em que os mesmo usurios fazem uso diariamente) tambm seria intuitivo para um sistema Web (onde no h como conhecer o perfil dos usurios que podem fazer uso do Web site diariamente, periodicamente ou uma nica vez). Quando uma equipe desenvolve um software para uma empresa, normalmente esta equipe treina os usurios, mostrando o que cada cone representa. A partir da, pode-se deduzir que a prtica poder fazer com que o sistema seja utilizado sem grandes esforos racionais, ou seja, de forma mais rpida e intuitiva. No entanto para usurios da Web, o que se pode propor como procedimentos intuitivos so questes baseadas no sistema cognitivo humano e no em intuies aproveitadas da engenharia de software (sem uma base racional e sem considerar a diversidade de usurios de sistemas Web), como proposto at agora pelo chamados gurus da Internet. No se pode negar o poder da semitica, mas o entendimento dos smbolos difere de um local para outro, de uma pessoa para outra, de uma faixa etria para outra. O uso de imagens em interfaces Web de extrema importncia, mas quando tem o objetivo fortalecer a afirmao de um texto ou de um fato. E no simplesmente por uma crena de que os usurios sabero qual foi o objetivo do desenvolvedor e far uso conforme sua determinao. Hurlburt faz a observao de que Confcio disse que uma imagem vale mais que mil palavras, no entanto usou palavras para dizer isso (Hurlburt, 2003). Este um exemplo de que nem tudo o que vale para um software implementado dentro de um espao fixo, previsvel, vale para a um sistema Web, implementado em um servidor Web onde no se pode medir sua dimenso, treinar usurios, receber feedback de todos os usurios ou conhecer seus recursos de software, hardware e banda etc. Isso quer dizer que os princpios de usabilidade podem ajudar muito um desenvolvedor de sistemas quando este os utiliza conforme os devidos fins. 3.1.2 - Princpios de Design O design a parte visvel de uma interface, o desenho, a forma, as cores, os alinhamentos etc., sem que haja um julgamento ou uma tentativa de entender ou dar nome ao que se v. A partir do momento em que se procura entender um design e atribuir nomes ao que aparece em 42

uma interface, faz-se referncia ao contedo ou mais precisamente, aos atributos que compem uma interface. Para ilustrar o conceito de design basta acessar um Web site, cujo idioma no se tem nenhum conhecimento como, por exemplo, um endereo japons, chins etc. visitado por quem no conhece o idioma, tendo condies somente de ver o design. A Figura 3.1 mostra uma interface de um Web site japons, considerando que o usurio no entenda este idioma e que possa somente ver o desenho sem entender o que o desenho diz.

FIGURA 3.1 - Exemplo de design de uma interface. FONTE: Shimbun (2005). Design desenho, esboo, projeto. Pode-se considerar como design de um Web site, tudo o que visualizamos em uma pgina, ou seja, os textos e as imagens, as cores, os alinhamentos e as figuras geomtricas como tabelas e linhas. Pode-se dizer que um texto tambm design quando no h um julgamento sobre o seu significa ou quando no h uma tentativa de fazer uma leitura. Quando olhamos para o contedo visual de um texto podemos dizer que estamos olhando o design. O design muitas vezes confundido com estrutura, layout, design pattern, template, arte etc. Estes termos (embora no haja uma traduo exata para layout e design) tm conceitos semelhantes para determinadas situaes, mas na prtica cada um representa situaes que tm caractersticas diferentes. 43

Estrutura: divises, compartimentos, espaos vazios aptos a receber contedos; diagrama padro de interfaces Web que exerce um papel de recipiente de atributos (Seo 4.1).

Layout: disposio ou posio que os atributos ocupam em uma interface. Este termo pouco usado para fazer referncias a interfaces Web uma vez que vlido somente para especificar esquemas conceituais de posicionamento dos atributos. O termo layout no considerado elegante para especificar um processo de design. Profissionais que trabalham com artes grficas preferem ser conhecidos como diretores de arte grfica, Web designer, diretor de design ou comunicadores visuais, em vez de layoutmen ou layouter (Hurlburt, 2002).

Design pattern: O design pattern tem suas razes no trabalho de Christopher Alexander, um engenheiro civil que escreveu sobre a sua experincia em resolver problemas de projeto que ele encontrava em construes (Seo 3.5.2). Ocorreu a Alexander que certas idias de projeto, sempre que eram utilizadas, levavam ao efeito desejado. Design patterns so representados como relacionamentos entre classes e objetos com responsabilidades definidas que agem em harmonia a fim de levar a uma soluo. A documentao de design patterns altamente estruturada. Os padres so documentados a partir de um modelo que identifica a informao necessria para entender o problema do software e a soluo em termos de relacionamentos entre as classes e objetos necessrios para implementar a soluo. No existe um consenso dentro da comunidade de design patterns sobre como descrever um template de patterns. Diferentes autores preferem diferentes estilos para seus templates de patterns (Mesquita, 2003).

Template: uma forma de documento estruturado que captura as informaes essenciais necessrias para o entendimento da essncia de um problema e a estrutura da soluo. O termo template tambm utilizado para fazer referncias a modelos de design de Web sites.

Arte: conhecimentos e habilidades que caracterizam um trabalho como no sendo puramente tcnico, mas que so resultados do uso de tcnicas, ferramentas, materiais e criatividade (Domingues, 2003), (Chau, 2000), (Aranha, 2003), (Hurlburt, 2002), (mais detalhes na Seo 3.1.2.2). 44

Design no apenas algo relacionado beleza, porm a beleza est relacionada ao design. Tambm h outros fatores tais como: tcnicas, ergonomia, materiais, tecnologia, adaptao, mercadologia, metodologia, usabilidade, aceitao no mercado etc. Design desgnio, designar coisas, projetar qualidade, tendncias, inovar ou renovar. Na concepo da palavra, design grfico uma arte aplicada e funcional que se encarrega de melhor organizar visualmente espaos e informaes visuais, facilitando ao mximo a compreenso do espectador, tornando visualmente agradvel e interessante essa "leitura" e buscando sempre a inovao e evoluo dessa forma de arte. Harmonia, clareza, limpeza e beleza so caractersticas importantes de um trabalho bem feito em todas as reas e em interfaces Web no poderia ser diferente (Hurlburt, 2002). Histrico: design uma palavra ambgua. No sculo XVIII na Inglaterra, o termo significava plano de uma obra de arte. Na origem latina, designare significa simultaneamente a idia de desenho e desgnio e implica o conceito de um objeto em vias de produo. Design ento definido tanto como um projeto ou o produto de um planejamento (Hurlburt, 2002), (Domingues, 2003). O profissional designer: tem a viso do mercado consumidor, seu trabalho deve gerar retorno para o cliente e atrair o consumidor aplicando conhecimentos e recursos de arte. Esses conhecimentos no o qualificam como artista, mas como um designer com conhecimentos tcnicos aprimorados. O artista: expressa idias e sentimentos, sendo que o artista que faz a arte pela arte no precisa se preocupar com quem ter contato com sua obra (Aranha, 2003). O artista no transita por vrios estilos. J o designer em seu processo de desenvolvimento capaz de transitar por vrios estilos para elaborar a melhor soluo (Domingues, 2003).

3.1.2.1 - Princpios Estticos A esttica est presente em interfaces de Web sites tanto no conjunto como um todo, como nos detalhes estilizados que caracterizam cada atributo (texto, link, imagem, formulrio). H uma esttica bsica para a composio de interfaces que baseada nas cores branca (fundo), preta (textos), cinza (formulrios), azul (links) e alinhamento esquerda. No entanto, as possibilidades de modificaes das caractersticas da interface bsica, bem como dos 45

atributos que a compem que faz com que as interfaces tenham estticas diferentes ou designs diferentes. Dificilmente um Web designer mudar as caractersticas originais dos atributos com a inteno de torn-los menos atraentes ou menos belos. Um exemplo disso so os cursos de Web design, intensivos, de ensino mdio e universitrio que so aplicados com a finalidade de proporcionar a um profissional, conhecimentos para criar designs diferenciados a partir da criao, modificao e posicionamento dos atributos que compem uma interface. Esttica uma rea da filosofia que estuda racionalmente o belo e o sentimento que o belo desperta nos seres humanos. Etimologicamente, a palavra esttica vem do grego aisthesis, com o significado de faculdade de sentir, compreenso pelos sentidos, percepo totalizante. A ligao da esttica com a arte ainda mais estreita quando se considera que o objeto artstico aquele que se oferece percepo. Por isso pode-se compreender que, enquanto disciplina filosfica, a esttica tenha tambm se voltado para as teorias da criao e da percepo. A recepo esttica a experincia esttica que no visa o conhecimento lgico, medido em termos de verdade, no visa a ao imediata e sua utilidade no pode ser julgada para um determinado fim. A experincia esttica a experincia da presena tanto para o objeto esttico como para o sujeito que o percebe (Aranha, 2003). No entanto, a maneira como a esttica interpretada ou julgada pode variar de pessoa para pessoa e a psicologia cognitiva mostra algumas razes dessas diversidades. Segundo Marilena Chau, no h diferena entre sensao e percepo. A percepo uma relao do sujeito com o mundo exterior e esta relao d sentido ao percebido e ao percebedor, e um no existe sem o outro. O ser humano sente e percebe formas, isto , totalidades estruturadas dotadas de sentido e significao. A percepo envolve a personalidade, a histria pessoal, as afetividades, por isso uma experincia esttica pode ser positiva ou negativa conforme o julgamento que se faz dela (Chau, 2000). A ao de olhar para a esttica de uma interface comum a todos, mas o julgamento que ocorre a partir dessa ao que peculiar a cada usurio fazendo com que os usurios sejam mais ou menos exigentes, de acordo com seus conhecimentos, gostos, preferncias. Isso mostra uma razo pela qual os profissionais da Web buscam novas maneiras de desenvolver e apresentar uma esttica aos usurios fazendo alterao das formas primitivas dos atributos 46

das interfaces e a criao de novas formas de ilustraes. Estas criaes envolvem cores, tamanhos, alinhamentos, movimentos etc. A palavra esttica usada em vrios sentidos, porm, todos partem do conceito primitivo usado pelos gregos antigos: designar aquilo que tem a ver com os sentimentos, com os sentidos, com a percepo. Assim, a esttica tambm est ligada atividade artstica, j que se preocupa com as obras que o ser humano faz com a finalidade de serem belas, e com reaes que elas provocam. Em termos gerais, pode-se dizer que a esttica a rea da filosofia que estuda a arte e suas relaes com o ser humano (Gallo, 1997). 3.1.2.2 - Princpios Artsticos Cada forma de arte tem o seu meio de expresso prprio e esse meio especialmente apto para um tipo de comunicao especfico. A arte na Web pode ser vista na forma de uma combinao de textos, imagens, cores, alinhamentos, posicionamentos e movimentos que no sejam baseados unicamente em tcnicas de uso de ferramentas. A arte uma forma de inqurito que descobre, cria e alarga o conhecimento quando mostrada como um produto da cognio. Um produto da cognio quando levado a extremos pode fazer com que o artista seja o nico entendedor do seu produto, restando aos contempladores apenas levantar possibilidades a respeito da inteno do artista. No bem esta forma de arte que se emprega na Web, onde a arte tem espao nas imagens usadas como forma de conhecimento complementar escrita e a formas estticas atraentes ao usurio (caracterizaes dos atributos). A educao artstica fornece capacidades de leitura, de codificao e decodificao de mensagens visuais. Tambm tem como finalidade evidenciar os fatos para a observao e compreenso das representaes visuais das diferentes culturas. A abordagem da educao artstica pode organizar-se segundo os campos da esttica, da crtica, da histria e da produo. A contextualizao, a anlise crtica, a reflexo esttica e o reconhecimento da pluralidade cultural so estratgias essenciais segundo o conceito de cultura visual para o entendimento de uma mensagem. A cultura visual representa um treino da viso para entender e conseqentemente desenvolver formas de trabalho que o conhecimento somente tcnico no permitiria. Um exemplo disso pode ser visto quando diferentes profissionais fazem uso da mesma 47

ferramenta, para produzir um mesmo produto (interface, logotipo, imagem complementar a um texto etc.) e os resultados so diferentes, conforme suas habilidades. Cada categoria de profissionais explora um sentido conforme a arte com a qual trabalha como, por exemplo, um msico precisa treinar a audio, um cozinheiro precisa treinar o paladar e um Web designer precisa treinar a viso. A viso o sentido mais utilizado pela maioria dos seres humanos e conseqentemente o que proporciona as maiores condies de imaginao e de criao. Howard Gardner (Gardner, 1997), autor da teoria das inteligncias mltiplas mostra que a viso espacial est relacionada ou proveniente ao sentido da viso e que o uso dessa forma de inteligncia que faz com que o indivduo desenvolva uma observao minuciosa das coisas, das formas, das imagens mentais etc. Habilidades como esta so essenciais a um Web designer, assim como o so a um artista. No entanto, um Web designer com conhecimentos artsticos est apto a desenvolver trabalhos qualificados, com esttica atraente, e fceis de serem entendidos pelo usurio. Por outro lado, se um artista, que tenha pouco ou nenhum conhecimento de Web design, trabalhar no desenvolvimento de Web sites, o resultado tende a ser desastroso, pois no se pode prever o perfil do usurio que entender seu trabalho. Gardner defende a existncia de diferentes modalidades de desenvolvimento enraizadas em diferentes modalidades de inteligncia. Considera que os seres humanos evoluram atravs dos milnios a ponto de serem capazes de realizarem pelo menos sete formas diferentes de conhecimento ou de processamento da informao. Estas incluem formas de inteligncia que lidam com linguagem, lgica e matemtica, musical e rtmica, informao visual espacial, informao corporal-cinestsica, interpessoal e intrapessoal. Todos os seres humanos normais possuem alguma capacidade em cada uma destas esferas ou perfis de inteligncias: Lingstica: relacionada s linguagens faladas, significados e relaes entre palavras. Domina a maioria dos sistemas educacionais ocidentais. Lgica / matemtica: relacionada ao pensamento dedutivo e raciocnio, nmeros, pensamentos abstratos, preciso e estrutura lgica. Rtmica / musical: relacionada ao reconhecimento de padres de tons, incluindo sons ambientais, sensibilidade ao ritmo, chave, batidas, o poder emocional e a organizao complexa da msica. 48

Visual / espacial: relacionada ao sentido da viso, observao minuciosa, metfora, pensamento visual, imagens mentais e habilidade de formar figuras tridimensionais na mente.

Corporal / sinestsico: relacionada ao movimento fsico, ao controle do corpo e de objetos, ao tempo e ao conhecimento/sabedoria do corpo.

Interpessoal: relacionada a relacionamentos entre pessoas e comunicao, sensibilidade para com os outros, habilidade para ler intenes e desejos alheios, habilidade para influenciar os outros.

Intrapessoal: relacionada ao auto conhecimento, estados interiores do ser, autoreflexo, meta cognio e conscincia de valores temporais e espirituais, propsitos e sentimentos.

Gardner no reconhece a existncia de uma inteligncia artstica, inteligncia esttica ou inteligncia perceptual, mas que os sistemas simblicos so mobilizados para fins artsticos quando os indivduos exploram esses sistemas de determinadas maneiras e para determinados fins. No existe uma inteligncia artstica separada, mas o direcionamento de cada uma das formas de inteligncia, mencionadas anteriormente, para fins artsticos. O que quer dizer que os smbolos vinculados nessa forma de conhecimento podem ser (mas no obrigatoriamente) ordenados esteticamente (Gardner, 1997). O olhar o sentido artstico por excelncia, pois pelo olhar que mais se adquire e acumulam-se conhecimentos que se faz da leitura nos mais diversos recursos e dos mais diversos tipos de linguagens (Gallo, 1997). Do ponto de vista didtico pode-se separar e mostrar algumas funes da arte como, por exemplo, a funo pragmtica ou utilitria da arte e a naturalista. Funo pragmtica ou utilitria da arte: dentro desta viso, a arte serve ou til para se alcanar um fim no-artstico, isto , ela no valorizada por si mesma, mas como um meio de alcanar uma outra finalidade. Na Idade Mdia, por exemplo, esse tipo de arte serviu para ensinar os principais preceitos da religio catlica relatando histrias bblicas para a populao dos feudos, onde a maioria era analfabeta.

49

Funo naturalista da arte: a funo naturalista refere-se aos interesses pelo contedo da obra, ou seja, pelo o que um trabalho retrata, em detrimento de sua forma ou modo de apresentao. O trabalho encarado como um espelho, que reflete a realidade. Essa tendncia caracterizou a arte ocidental ate meados do sculo XIX, quando surgiu a fotografia (Aranha, 2003).

apenas do ponto de vista didtico que se podem separar as funes da arte, pois elas podem se apresentar juntas dependendo da finalidade ou de como um expectador percebe uma arte. 3.1.2.3 - Princpios ticos H questes que no representam somente um ponto de vista ou um modelo de design; que no tratam simplesmente da escolha de uma linguagem e/ou tecnologia em detrimento de outra, mas como fazer um uso melhor das tecnologias escolhidas. Determinadas questes como esttica, gostos, preferncias, facilidades de leitura e navegao, no so problemas que a engenharia possa solucionar, mas so questes que precisam ser pensadas e analisadas em busca de levar aos usurios o melhor possvel dentro dos limites de cada projeto (tempo, verbas, recursos em geral). Questes como estas so abordadas, neste trabalho, sob vrios aspectos, inclusive sob aspectos filosficos, como da tica, da esttica e a arte. Em interfaces Web podem-se considerar questes ticas em aspectos como as imagens, textos, o contedo dos textos escritos, a forma de organizao do contedo e do uso das tecnologias, na busca de levar at os usurios facilidade de uso do sistema e clareza nas informaes. Sobre a tica das imagens, segundo, Peixoto, in: (Novaes, 2003), a tica das imagens dar tempo e lugar para as coisas. Aquilo que elas precisam para ser. Imagens que procurem respeitar o tempo e o espao para que as coisas se cristalizem diante dos nossos olhos. tica saber atentar para o tempo e o lugar das coisas (...) Imagens que procurem olhar o mundo nos olhos, que tentem deixar as coisas no olhar. Perceber aqui o que faz as coisas falarem: a sua luz, o seu rio subterrneo. Essa atitude - esse respeito pelas coisas - tico. Olhar o mundo como uma paisagem, algo dotado de luz, de uma capacidade de nos responder ao olhar. No se trata de procurar cenas naturais, mas de um modo de ver. Ver rostos e cidades como paisagens: uma tica do olhar (Novaes, 2003). 50

Sobre o uso das tecnologias, faz-se feita uma analogia com o atomismo, segundo, Pessanha, in: (Novaes, 2003). A tica exige mais que um mecanicismo. Exige uma racionalidade flexvel para dentro dela caber o humano com seus projetos; o humano com seus ideais; o humano com suas metas, ou seja, o atomismo explica todas as coisas, s no explica apenas que o homem seja uma coisa que tenha que ficar inerte diante da fatalidade do jogo mecnico. O homem racional, mas a racionalidade do mundo precisa dar conta tambm racionalmente da ao do homem contrria fatalidade das coisas. O homem livre e isso que a grandeza de sua liberdade, porque apesar da fatalidade das coisas, do mecanismo do mundo, ele abre uma brecha para seus projetos, ele o inventor do dever ser, acima da fatalidade das coisas que so. Ele introduz uma dimenso que a dimenso do dever ser, do seu projeto de vida, da sua meta... Ele no um ser passivo diante do mundo; ele no apenas um reflexo das circunstncias, ele no est apenas merc das contingncias. Ele algum capaz de, diante das contingncias, dar respostas diferenciadas e por isso mesmo ele pode estabelecer o seu itinerrio; a sua meta; a sua rota (Novaes, 2003). Alguns autores, algumas categorias profissionais e alguns segmentos sociais fazem uso da tica como sendo uma espcie de obrigao ou de verdades absolutas que tenham que ser seguidas. Porm, neste trabalho, a tica abordada como uma cultura a partir da qual pode-se levar at os usurios interfaces com uma funcionalidade melhor, devido ao uso diferenciado de tecnologias e de um design baseado em observaes de dificuldade (cultura, prtica de uso, recursos de software, hardware, banda etc) de alguns usurios. Propor em um processo de desenvolvimento Web, um padro de design poderia representar uma falta de percepo e de reconhecimento da capacidade de criao. Assim, na terceira fase do processo de desenvolvimento apresentado neste trabalho, so sugeridas algumas questes que podem auxiliar um profissional na escolha das tecnologias, nas opes de design e no uso geral de textos e imagens. Sobre a tica vista como um tipo de obrigao, segundo, Ribeiro, os cdigos de tica, na verdade, so leis disfaradas, leis light, promulgadas por quem no tem poder para legislar (por exemplo, uma empresa, uma associao profissional) (...) Os cdigos de tica j se mostram mais cdigos do que ticos. Porque h um velho conflito entre a tica e o cdigo, ou seja, entre a tica e a lei. Para a lei, basta que sejam obedecidas. Mas, para a tica, isso no quer dizer nada. Se eu cumprir a lei por medo das conseqncias, meu ato no tem nada de tico. (...) O grande problema dos cdigos de tica o seguinte: eles podem levar as 51

pessoas a pensar que so ticas a baixo custo. Bastar obedecermos a suas disposies e, pronto, seremos ticos. Numa sociedade que questiona inmeras coisas, que est atravessada por dvidas (o que muito positivo, porque desperta a pergunta tica), um cdigo pode ser a resposta fcil para um problema complexo. Pode calar a pergunta pela decncia, em vez de dar-lhe o devido valor. Provavelmente a sociedade vai continuar gerando cdigos de tica, e o resultado bsico bom, sobretudo se eles decorrerem de uma ampla discusso social, porque assim se envolve todo um grupo ou categoria profissional. Mas devemos sempre deixar claro que nenhum cdigo de tica vai fazer uma pessoa tica (Ribeiro, 2004). A questo da tica das interfaces Web ser mostrada no captulo 5, pois o assunto parte integrante do trabalho proposto. No que se pretenda criar um cdigo de tica para as interfaces Web, mas ao contrrio, mostrar algumas questes podem levar mais qualidade aos usurios, dando tempo e espao arte e tecnologia. Para prope-se alguns princpios culturais como esttica, arte tica em busca de melhores designs, respeitando a capacidade de criao que gera designs atraentes sem comprometer o bom funcionamento navegacional. Questes Legais no sero abordadas neste trabalho. 3.2 - Prticas Recomendadas para a Internet (IEEE 2001) O IEEE-2001 (Instituto de Engenheiros Eltricos e Eletrnicos) um padro voluntrio conhecido como Prticas recomendadas para a Internet - Engenharia Web, gerenciamento de Web sites e padres de ciclos de vida de Web sites. O padro conhecido como IEEE 2001, sobre benefcios e normas de procedimentos para desenvolvimentos de Web sites, incluiu os tipos de informao que devem ser destacadas em todos os Web sites, tal como informaes sobre o criador do Web site; URLs e datas de updates. Usurios acessam pginas em busca de dados confiveis e atualizados. Por isso um Web site deve trazer a identificao do que , e a quem pertence; o propsito do Web site; se tem fins lucrativos ou somente informativo; quem so as pessoas responsveis pelas divises e a forma de contat-las; a poltica de privacidade, como por exemplo, se o Web site tem cookies que armazenam dados do usurio; a propriedade intelectual das informaes disponveis; se as informaes estaro permanentemente no Web site ou se so temporrias e quando so temporrias, qual a data de expirao, de atualizao e a ltima modificao.

52

As pginas Web devem ser feitas considerando o acesso por usurios diversificados. O IEEE 2001 (Internet, melhores prticas de EW) sugere Web sites que procurem uma conformidade para implementar formas de procedimentos de acesso. Os mtodos de melhoramentos de acesso para pessoas leigas, melhoram o acesso para todas as demais. Usurios mais freqentes on-line agem de acordo com as normas que representam credibilidade aos Web sites. Exemplos que facilitam o sistema de acesso e navegao: Reproduo do contedo para um sistema facilitador de udio como, por exemplo, onde se possam escolher tradues para outros idiomas e informaes do contedo em mecanismos de busca; Internacionalizao de informaes de contato como nmeros de telefones contendo o cdigo do pas, da cidade e o fuso horrio. Onde houver produtos que tm preos, deve ter tabelas de converso para diversas moedas, como por exemplo, $US, $pesos, $Hong Kong, R$reais etc.; Mecanismos de busca eficientes devem ser marcados por meta tags que identifiquem conforme a data da ltima modificao, da expirao, e o endereo da home page; Modelos eficientes e abrangentes de divulgao, reconhecimento e aprovao, devem fazer uso de normas de processos e ferramentas de desenvolvimento de Web sites que correspondam as normas de especificaes (Isaak, 2001). As prticas padronizadas pelo IEEE representam uma conscientizao de como melhorar a compreenso e a forma de navegao de um usurio dentro de uma pgina. Alm dos itens mostrados acima, o padro de melhores prticas de EW, tem muitos outros pargrafos que se referem usabilidade da Web. 3.3 - W3C O W3C (World Wide Web Consortium) a principal organizao promotora e padronizadora da Web, mundialmente. A prpria especificao do HTML, XML, e outras linguagens, so desenvolvidas pelo W3C. O W3C foi fundado em Outubro de 1994 para levar a World Wide Web a atingir seu potencial mximo atravs do desenvolvimento de protocolos comuns que promovam sua evoluo e garantam sua interoperabilidade. Atualmente a W3C tem mais de 53

450 Membros e um quadro de aproximadamente 70 pessoas em tempo integral globalmente, que contribuem para o desenvolvimento de especificaes de W3C e software. A misso do W3C levar a Web ao seu potencial mximo, que se consegue atravs do desenvolvimento de tecnologias (especificaes, diretrizes, software e ferramentas) criar um frum para informao, comrcio, inspirao, pensamento independente e compreenso coletiva. Este sumrio com sete pontos apresenta os objetivos do W3C e os princpios operativos. Acesso Universal: o W3C define a Web como o universo de informao acessvel por rede (disponvel atravs de seu computador, telefone, televiso). Atualmente este universo beneficia a sociedade atravs da oferta de novas formas de comunicao entre humanos e oportunidades de compartilhamento de conhecimento. Um dos primeiros objetivos do W3C tornar estes benefcios universais para todas as pessoas, independentemente de hardware, software, infraestrutura de rede, linguagem nativa, cultura, localizao geogrfica ou capacidades mentais ou fsicas. As atividades do W3C so atividades de internacionalizao, atividade independente de aparelhos, atividade de browser por voz, e iniciativa de acesso Internet (todos com verso em ingls), ilustram o compromisso para um acesso universal. Web Semntica: as pessoas atualmente compartilham seu conhecimento na Web em uma linguagem destinada a outras pessoas. Na Web Semntica (semntica, significa relacionado a significado) se expressa de modo a que os computadores possam interpretar e fazer as trocas com as aplicaes. Assim, resolvem-se problemas e propiciam-se formas de ajuda para que se encontre mais rapidamente o que procura, como por exemplo, informao mdica, comentrios sobre um filme, uma ordem de compra de um livro etc. As linguagens do W3C, RDF, XML, esquema XML, e assinaturas XML so os elementos fundamentais da Web Semntica. Confiana: a Web um meio de colaborao e no apenas uma revista de leitura. Na realidade, o primeiro navegador para a Web era tambm um editor, apesar de a maioria das pessoas imaginarem os navegadores com uma funo principal de visualizao e no interao. Para promover um ambiente mais colaborativo, tornase necessria a existncia de uma rede de confiana que garanta confidencialidade, 54

passe confiana e torne possvel s pessoas tomar responsabilidades por (ou sejam responsveis por) aquilo que est publicado na Rede. Estes objetivos orientam muito do trabalho no W3C's sobre assinaturas XML, mecanismos de anotao, autoridades de grupo, verses etc. Interoperabilidade: h vinte anos as pessoas compravam software que funcionava apenas com algum outro software desde que fosse do mesmo vendedor. Atualmente as pessoas tm mais liberdade de escolha e corretamente esperam que os componentes de software sejam intercambiveis. Tambm se espera que seja possvel visualizar contedo existente na rede com o software de sua preferncia (navegador de PC grfico, sintetizador de voz, navegador braille, telefone do carro etc.). A W3C, uma organizao neutra a vendedores, promove interoperabilidade atravs do desenvolvimento e promoo de linguagens de computador abertas (no proprietrias) e protocolos que evitam uma fragmentao do mercado que existia no passado. Estes pontos so conseguidos atravs de consenso na indstria e encorajamento de uma discusso em frum aberto. Evoluo: o W3C visa a excelncia tcnica, porm est ciente que o que conhecemos e necessitamos atualmente pode no ser suficiente para a soluo de problemas no futuro. Assim, busca o desenvolvimento de uma rede que possa facilmente evoluir para uma rede ainda melhor, sem quebra de funcionalidades anteriores. Os princpios da simplicidade, modularidade, compatibilidade e extensibilidade, orientam todo o desenvolvimento W3C. Descentralizao: a descentralizao um princpio de sistemas distribudos, incluindo as prprias sociedades. Em um sistema centralizado toda a mensagem ou ao tem que passar por uma autoridade central, originando gargalos sempre que o trfego aumenta. Em conceito, limita-se ento a quantidade de pontos centrais na rede para reduzir a vulnerabilidade na Rede, como um todo. Melhor multimdia: quem no gostaria de mais interatividade e uma melhor mdia na rede, incluindo-se aqui imagens que podem alterar seu tamanho, som de qualidade, vdeo, efeitos tri-dimensionais e animao? O processo de consenso no W3C no limita a criatividade de fornecimento de contedo ou significa visualizaes de contedo pobres. Atravs de seus membros o W3C escuta os 55

usurios finais e trabalha com o objetivo de fornecer bases slidas para o desenvolvimento de uma Melhor Multimdia atravs de linguagens como a linguagem Scalable Vector Graphics (SVG) e a Synchronized Multimedia Integration Language (SMIL) (W3C, 2003). 3.4 - UML Durante o perodo de 1989 a 1994, a quantidade de mtodos orientados a objetos aumentou consideravelmente, em pouco tempo. Com isso, muitos usurios desses mtodos tiveram dificuldades para encontrar uma linguagem de modelagem capaz de atender as suas necessidades e isso acabou gerando a chamada guerra dos mtodos. Com os problemas decorrentes no desenvolvimento de softwares, surgiu a necessidade de uma linguagem unificada para que os desenvolvedores de softwares pudessem falar uma linguagem comum (Booch, 2000). Para apontar uma soluo guerra dos mtodos, os autores Grady Booch, Ivar Jacobson e James Rumbaugh se uniram e unificaram seus mtodos, criando a Unified Modeling Language (UML). A UML trouxe uma certa estabilidade ao mercado de desenvolvimento de software permitindo que os projetos tivessem como base uma linguagem de modelagem mais. Quando a UML foi lanada, muitos desenvolvedores da rea da orientao a objetos foram beneficiados j que essa padronizao proposta pela UML trouxe o apoio que eles esperaram (Booch, 2000). Ao longo de 1996, a UML foi aceita pela comunidade de Engenharia de Software em geral, que atualmente considera a UML uma grande aliada, pois permitiu que os desenvolvedores de softwares pudessem falar uma linguagem comum. Utilizar a UML em projetos Web no significa explorar todos os significados de classes, objetos, relacionamentos, fluxos, mensagens e outras entidades comuns da orientao a objetos, mas fazer uso dos recursos pertinentes a UML em busca de melhores projetos de Web site. As melhorias nos projetos podem ser vistas no uso de diagramas como, por exemplo, diagramas de seqncia, diagramas de caso de uso, diagramas de classes e demais diagramas que possam ser utilizados na modelagem de projetos de Web sites. O objetivo de buscar a modelagem de interfaces Web atravs dos recursos da UML fazer com que haja uma linguagem comum entre desenvolvedores e administradores de Web sites no projeto, implementao e administrao. Atravs de projetos objetivos e estruturas 56

padronizadas possvel uma aproximao maior do ideal de fazer com que os Web sites possam ser sistemas orientados ao usurio (Booch, 2002). A UML uma tentativa de padronizar a modelagem orientada a objetos de uma forma que qualquer sistema, seja qual for o tipo, possa ser modelado corretamente, com consistncia, fcil de se comunicar com outras aplicaes, simples de ser atualizado e compreensvel (Booch, 2000). Para entender melhor um sistema a ser desenvolvido a UML faz uso de modelagens e padres de contexto, como os descritos a seguir. 3.4.1 - O Uso da Modelagem para Entender Melhor o Sistema Um modelo ou um processo pode representar uma simplificao da realidade. Os modelos fornecem uma cpia do projeto de um sistema e podem abranger planos detalhados ou planos gerais com uma viso panormica do sistema considerado. Um bom modelo inclui aqueles componentes que tm ampla repercusso e omite os componentes menores que no so relevantes em determinado nvel de abstrao. Todos os sistemas podem ser descritos sob diferentes aspectos, com a utilizao de modelos distintos, sendo cada um deles uma abstrao semanticamente especfica do sistema. Os modelos podem ser estruturais, dando nfase na organizao do sistema; comportamentais, dando nfase dinmica do sistema (Booch, 2002), (Mesquita, 2003). 3.4.2 - Padres A noo de padres tem as suas origens no trabalho do Engenheiro civil Christopher Alexander. Durante 10 anos, Alexander recolheu e documentou solues genricas para problemas recorrentes no domnio da arquitetura. O objetivo inicial foi o de habilitar noespecialistas a projetar as suas prprias casas e comunidades. Alexander mostrou que Cada modelo descreve um problema que ocorre inmeras vezes em nosso meio e ento descreve a essncia da soluo daquele problema de maneira que podemos usar esta soluo milhes de vezes, sem que isto seja feito duas vezes da mesma maneira (Mesquita, 2003). Apesar de Alexander estar se referindo a padres da Arquitetura, o que ele disse tambm verdadeiro para os padres de projeto orientados a objeto. Na Orientao a Objetos (OO)

57

fala-se em objetos e interfaces ao invs de paredes e portas, mas o ncleo dos dois tipos de padro a soluo de um problema em um contexto determinado. Os Formatos dos Padres de Alexander podem ser entendidos como: Nome: uma frase ou nome descritivo identificativo do padro. Exemplo, fotografias, desenhos e descries que ilustram a aplicao dos padres. Contexto: as circunstncias nas quais o padro pode ser aplicado. Explica a razo da existncia do padro e a sua generalidade. Problema: descreve as foras relevantes e restries e como interagem entre si. Soluo: relaes e regras dinmicas que descrevem como construir artefatos em concordncia com o padro. So referidos padres similares e variantes, bem como padres de nveis superior e inferior relevantes para a concepo da soluo proposta (Mesquita, 2003). 3.5 - Engenharia de Web sites A Engenharia Web (EW) pode ser definida como Aplicao de um enfoque sistemtico, disciplinado e quantificvel para o desenvolvimento e evoluo de aplicaes Web, com alta qualidade e a um custo efetivo (Graef, 2000). A EW lida com diversas reas: hipermdia, banco de dados, interao homem-computador, artes, comunicao, lingstica computacional, gerncia, apresentao grfica, computao grfica. Tudo isso resulta em uma combinao entre: Publicao impressa e desenvolvimento de software; Marketing e computao; Comunicao interna e relaes externas (Graef, 2004) Arte e tecnologia (Domingues, 2003).

A Engenharia Web no idntica a Engenharia de Software: mtodos, tcnicas e ferramentas tradicionais de desenvolvimento de software no so sempre adequados para o projeto de Web sites. Os Web sites so produtos de software e apresentam requisitos prprios, como a necessidade de gerenciar um grande volume de informaes, combinar a navegao controlada pelo leitor com a prpria natureza das informaes multimdia, atualizaes constantes, entre outros fatores (Zafiris, 2001). 58

Surge assim um novo paradigma de engenharia denominado Engenharia de Web sites ou Engenharia Web, que define um processo para construir aplicaes hipermdia na Internet com qualidade, com base em critrios tais como: necessidades dos usurios, contedo de alta qualidade, atualizaes constantes (manuteno), tempo de download mnimo, usabilidade e cultura corporativa centralizada na rede (Zafiris, 2001). 3.5.1 - Problemas no Desenvolvimento de Web Sites Web sites mal definidos e mal projetados: resultam em Web sites emendados, com interfaces inadequadas, difceis de se entender e navegar. Mtodos de implementao inadequados e obsoletos: um Web site no deve ser desenvolvido somente com tecnologia de ultima gerao (sem que seja devidamente testada), uma vez que no possvel conhecer os recursos de requisio (software, hardware e banda) de cada usurio. Nem por isso deve-se usar uma verso muito antiga de uma linguagem ou tecnologia, privando os usurios de interfaces mais intuitivas e dinmicas. Falta de documentao e dificuldades de implementao e manuteno: A EW faz uso dos recursos da ES, da UML e da engenharia da usabilidade, mas ainda encontra dificuldades para elaborar projetos, documentao, implementao, design e manuteno de Web sites. Isso significa que ainda h dificuldades no uso uma linguagem comum entre os profissionais da Web. A necessidade de organizar o material de maneira adequada requer uma abordagem sistemtica. A falta de diretrizes, modelos e mtodos para a criao tornam o processo difcil e desafiante. Viso da atividade como arte ou como engenharia: a concepo de que o desenvolvimento de Web sites uma arte est errada. Existe um importante lado artstico/design, mas os desenvolvedores precisam tambm de disciplina e de um modelo de processo. Inexperincia e formao inadequada dos desenvolvedores: com o surgimento de softwares geradores de HTML e a facilidade do uso desta linguagem, muitos profissionais de outras reas puderam desenvolver seu prprio Web site, colocando o contedo disponvel on-line, sem critrios, estimativas de acesso ou controle da

59

complexidade. Isso levou idia de que trabalhar com Web sites fcil: basta enviar os arquivos desenvolvidos para uma mquina servidora. Custos mal dimensionados: o trabalho de profissionais qualificados, como em qualquer outra rea, tem um custo considervel. Alm disso deve-se considerar, os custos de aquisio e manuteno para uso de um domnio, custo de hospedagem, tecnologias de desenvolvimento e manuteno. Sem um projeto objetivo e bem definido, fica difcil mensurar os custos decorrentes (Zafiris, 2001 (Kirda, 2001).

3.5.2 - Diferenas entre a Engenharia de Software e a Engenharia Web Diferentes propsitos: aplicaes convencionais projetadas tipicamente pela ES oferecem servios e solues enquanto Web sites oferecem contedos que so informaes e/ou servios, representando assim, um diferente meio de comunicao. Apresentao x funcionalidade: aplicaes convencionais do nfase funcionalidade e aplicabilidade, enquanto Web sites do nfase apresentao, aparncia, navegao e a outras qualidades estticas. Tradio x experincia: existe mais experincia no desenvolvimento de software convencional, possibilitando planejamento e gerncia mais realsticos em relao a processos de Web sites. Pblico alvo x audincia (Classe de usurios): aplicao convencional tem classe de usurios mais bem definida, com nfase na aplicabilidade e funcionalidade. J os Web sites tm um pblico diversificado com nfase na navegao e qualidades estticas. Maturidade da Tecnologia: aplicaes convencionais tm tecnologias mais estveis e excelentes ferramentas disponveis, enquanto a EW tem tecnologias em constante evoluo, diversas ferramentas disponveis para implementao, mas existem poucas para anlise, projeto, documentao e outras atividades da EW (Kirda, 2001).

60

3.5.3 - Principais Atividades As principais atividades de desenvolvimento de Web sites so a definio do problema, motivao, propsitos, estimativas de acesso, planejamento e gerncia do projeto, estudo de viabilidades, anlise e seleo de requisitos, design, estrutura organizacional, estrutura das interfaces, sistema de navegao, contedo, funcionalidade, implementao, testes e manuteno. 3.5.4 - Principais Tipos de Requisitos para Web Sites Para o desenvolvimento de Web sites so necessrios alguns requisitos que servem de base para o planejamento do contedo, da estrutura das interfaces, do sistema navegacional e do design. Requisitos de contedo: quais informaes o Web site deve conter? Viso e modelagem das informaes do Web site devem determinar como as pginas sero organizadas. Para a interface da pgina deve-se planejar a organizao, interao e apresentao que iro determinar os aspectos estticos e visuais. Deve-se definir a diagramao das pginas, o uso de imagens e cones, idioma, cores, tipo de fontes, plano de fundo. Requisitos funcionais: qual a tecnologia necessria? Quais servios o Web site deve oferecer? Qual a arquitetura dos programas, projeto de banco de dados, plataforma? Que tipos de testes sero realizados? Requisitos de interao e navegao: viso de navegao como uma forma de entendimento de como o usurio vai utilizar/interagir/navegar no Web site. necessrio determinar como os menus, ncoras, botes e cones podem ser utilizados. Requisitos de projeto e de desenvolvimento: os requisitos de desenvolvimento so referentes ao nmero e qualificao das pessoas envolvidas; os prazos revistos para a entrega de etapas especficas e para a concluso e os custos previstos para o projeto e para a implementao. Web sites devem prever as tecnologias que sero utilizadas, prever a compatibilidade com os recursos do servidor para que seja possvel uma previso funcional, de cronograma e oramentria. Exemplo:

61

- Imagens: Adobe Illustrator, Photoshop, Macromedia Freehand, Fireworks. - Edio/Codificao: Dreamweaver, Frontpage, Adobe GoLive. - Diagramao: Adobe Pagemaker, Microsoft Visio, Rational Rose. - Animaes: Macromedia Flash. - Linguagens: HTML, DHTML, JavaScript, CGI, ASP, PHP, Java Servlets, XML ou outras (Kirda, 2001). Princpios, normas e padres representam formas de cultura que auxiliam os profissionais a tomar decises e a fazer melhores escolhas dentro dos limites de cada projeto. No entanto, a Web dinmica e conta com desenvolvedores e usurios com os mais diversos nveis de instruo, exigncia, capacidade de discernimento e avaliao. Se um Web designer se ativer somente a normas e padres e tentar coloc-los como verdades absolutas que se atribuem a todos os domnios e a todas as situaes, correr o risco de tornar seus trabalhos obsoletos e previsveis demais diante das exigncias do mercado. Uma das possveis ponderaes para o uso de princpios, normas e padres que sejam utilizados com ateno e cuidado para que um profissional no anule a sua capacidade criativa e nem desenvolva trabalhos com excessos de formalidades.

62

CAPTULO 4 ESTRUTURAS E MODELOS DE WEB SITES Nesta Seo explicam-se as estruturas e os modelos de projetos mais utilizados em Web sites. 4.1 - Estruturas de Web sites Para que uma interface seja elaborada necessria a adoo de um tipo de estrutura para a mesma. A estrutura de uma interface Web definida pelo esboo onde sero colocados os contedos (Chase, 2000). Existem vrios tipos de estruturas, os quais so escolhidos pela facilidade no manuseio dos arquivos, pela necessidade do contedo ou pelos recursos disponveis no servidor. Ao iniciar um projeto de Web site necessrio definir o tipo de estrutura, pois os arquivos tero que ser desenvolvidos de acordo com as caractersticas da estrutura, como por exemplo, o uso do parmetro target em links, que define em que tipo de janela uma pgina ser exibida. Destacam-se a seguir, os tipos mais freqentes de estrutura encontradas em Web sites. 4.1.1 - Pgina nica com Links para os Tpicos Essa a forma mais simples de se expor contedos Web. A composio se d com uma nica pgina onde h links que apontam do incio da pgina para um tpico especfico, do final para o incio e de qualquer ponto da pgina para onde houver um link (esta estrutura bastante utilizada em Frequently Asked Questions - FAQs). A estrutura de pgina nica com links para os tpicos feita com em uma nica pgina onde os valores atribudos aos parmetros target e name das tags, <A HREF> e <A NAME> respectivamente, que determinam a forma de navegao. O limite deste tipo de estrutura encontra-se no tamanho das pginas geradas quando o contedo extenso. Quando h mais de um assunto a ser exposto e quando h necessidade de ilustraes feitas com imagens, esse tipo de estrutura no o mais adequado.

63

4.1.2 - Frames Os frames so estruturas vazias, que somente dividem a tela. Nos espaos vazios so inseridos arquivos com contedos. Normalmente um arquivo fica fixo, com a barra de navegao fazendo a chamada das pginas que compem o Web site. A estrutura de frames requer um arquivo com o menu e os demais com o contedo conforme indicam os links e o parmetros target que far com que um arquivo seja exibido em uma janela cujo nome foi atribudo no arquivo do frame que faz a diviso da tela. Este sistema bastante utilizado devido praticidade no desenvolvimento, porm para o usurio, apresentam problemas funcionais e estticos, como os explicados a seguir. Funcionais: pode causar acoplamentos de janelas, isto , fazer com que um arquivo seja aberto dentro do espao do outro, reduzindo o espao para a visualizao do contedo. Pode ainda, dificultar o acesso a tpicos especficos devido ao endereo destes ser camuflado no location do navegador e no funcionar em janelas pop-up na maioria dos navegadores. Estticos: apresentam problemas estticos como a diviso da tela que dependendo do contedo geram barras de rolagem em pontos estratgicos; no h como padronizar as interfaces, pois eliminam a barra de navegao quando se chama um link para um tpico isolado (Baker, 2001), (Roselli, 1999). 4.1.3 - Pginas Divididas com Tabelas um sistema onde se elabora um arquivo com uma tabela que contm uma barra de navegao em uma das linhas ou colunas e o contedo em outra diviso (linha/coluna). Elabora-se um script contendo o menu e este script copiado e colado em todas as pginas, fazendo com que o usurio veja as pginas escolhidas, acompanhadas da barra de navegao. A estrutura de diviso com tabelas requer que todo o contedo esteja exposto em cada pgina e o valor do parmetros target que far a substituio das pginas que a forma de navegao. Este tipo de estrutura revela suas limitaes em relao ao nmero de arquivos e diretrios que compem um Web site. A necessidade de copiar e colar o script em todas as pginas no representa grandes problemas para um Web site com poucos arquivos, mas considerando um grande nmero, este sistema torna-se impraticvel. 64

4.2 - Modelos de Web Sites Nesta Seo faz-se um levantamento de alguns modelos de projetos, desenvolvimento e administrao de Web sites. No desenvolvimento de software, nos modelos mostrados na fundamentao deste trabalho, bem como, no processo proposto, usa-se muito o termo esteretipo para fazer referncia a ilustraes necessrias ao entendimento do que ocorre em diversas fases e nveis de desenvolvimento de softwares. Este termo pode ser entendido como: Etimologicamente (Simes, 1985), o termo esteretipo designa uma placa metlica de caracteres fixos destinada impresso em serie. Trata-se de um termo que embora provindo do vocabulrio tipogrfico, adquiriu uma conotao psicossocial, remetendo para uma matriz de opinies, sentimentos, atitudes e reaes dos membros de um grupo, com as caractersticas, rigidez e homogeneidade (Lima, 1986). De um ponto de vista mais estritamente cognitivo (Codol, 1989), a estereotipia identifica-se com a prototipia, tratando-se de uma operao que consiste em atribuir a objetos de uma categoria todos os traos que se supe caracterizar o conjunto dos objetos dessa categoria (Lima, 1986). 4.2.1 - HDM O Hypertext Design Model (HDM) (Garzotto, et all, 1993) prescreve um esquema de aplicao que descreve as classes abrangentes de informaes dos elementos quanto s caractersticas comuns apresentadas, organizao interna da estrutura e a composio das interconexes mtuas. Portanto, este esquema captura a semntica e as regularidades estruturais na representao de estruturas para uma determinada classe de aplicaes. Uma vez que um esquema seja especificado, o modelo tambm permite definir uma aplicao particular, provendo primitivas para descrever o exemplo do esquema, exemplos atuais de informao, classes e tipos de conexo. O HDM um dispositivo de modelagem que prov modos de descrever aplicaes de hipertexto concisamente e de uma maneira independente do sistema existente. O esquema

65

ajuda o autor a formular os conceitos de uma determinada aplicao sem uma comunicao de linguagens entre Web designers, desenvolvedores e usurios. A partir desta perspectiva, o modelo o primeiro passo para o desenvolvimento e geraes de aplicaes de modo semelhante as ferramentas CASE que so usadas na Engenharia de Software. A implementao de uma aplicao de HDM requer a definio de uma semntica de navegao, que especifique a dinmica do comportamento e as propriedades de visualizao da representao da estrutura HDM. Alm disso o HDM especifica uma semntica padro de navegao, mais apropriada para um sistema de classes. O HDM pode ser usado como modelagem de projeto/dispositivo ou como uma implementao de projeto. Como uma modelagem, o HDM suporta um alto nvel de especificaes existentes ou de aplicaes a serem desenvolvidas. Como uma implementao de projeto ele uma base para ferramentas de design que suportam diretamente o desenvolvimento de aplicaes. Em aplicaes de hipertexto a definio de um grande nmero de links que podem ser derivados do design conceitual no nvel de descries. As entidades so naturalmente agrupadas em tipos de entidades, os quais correspondem a classes de objetos na vida real. Em aplicaes de hipertexto, as entidades so freqentemente um mesmo tpico que deve ser representado em diversas formas alternativas. Em aplicaes multidimensionais, por exemplo, um mesmo tpico pode ser representado em diferentes idiomas. Ou ainda representar diversas maneiras de se ver a mesma situao, como por exemplo, um assunto visto em texto, vdeo, imagem som etc. As primitivas do HDM so aplicaes que consistem em estruturas feitas de grandes blocos de informao, chamadas entidades. Uma entidade denota um objeto fsico ou conceitual de um domnio. Entidades so agrupadas pelo tipo da entidade. As semnticas de navegao tm o propsito de especificar como as estruturas de informao so visualizadas no cabealho e como se pode navegar atravs delas. O HDM prov um padro relativamente simples que folheia a semntica que est embutida no cabealho. Diferentes semnticas de navegao, no entanto, podem ser definidas para descrever uma visualizao mais sofisticada dos efeitos das aplicaes especificadas. As primitivas HDM para a especificao de uma aplicao hipermdia so: Entidade: a menor estrutura de informao autnoma que representa algum objeto do mundo real do domnio da aplicao. Sua existncia independe da 66

existncia de outros objetos. Entidades semelhantes podem ser agrupadas em um tipo de entidade. Componentes: as entidades so formadas por conjuntos de componentes no autnomos organizados hierarquicamente ao modo de rvores. Assim sendo, componentes possuem pai, irmos e filhos e herdam as caractersticas da entidade da qual faz parte. Perspectivas: perspectivas representam maneiras distintas de apresentar um mesmo tpico atribudo a uma entidade. Todos os componentes desta entidade tambm herdam as perspectivas correspondentes. Unidades: as unidades so associadas a uma perspectiva especfica. Caracteriza-se por um nome e um corpo, que o local onde o contedo de uma aplicao hipermdia preenchido. Links: as ligaes ou links podem capturar tanto as relaes do domnio quanto padres de navegao. Normalmente as relaes do domnio no so consistentes com os padres de navegao e vice-versa. Por isto, o HDM permite trs tipos de ligaes: Links de perspectivas: ligaes de perspectivas conectam unidades

correspondentes de um mesmo componente. So fceis de navegar porque mantm o tpico corrente inalterado. - Links de estruturas: ligam componentes pertencentes a uma mesma entidade. As ligaes estruturais podem ser de vrios tipos: up conecta um componente com o pai; down-n conecta um componente com o n-simo filho; next-sibling conecta um componente com o prximo filho do mesmo pai; root liga um componente raiz da rvore. Permite que o usurio navegue entre trechos de informaes pertencentes a mesma entidade, mantendo o mesmo contexto de informao. - Links de aplicao e tipos de links: representam ligaes complexas entre entidade e/ou componentes de uma aplicao hipermdia e que so dependentes do domnio. Ligaes de aplicaes podem ser agrupadas em tipos representadas por um nome, uma entidade fonte, uma entidade destino e um atributo de simetria. A

67

navegao por tipos de ligaes implica na mudana brusca do contexto da informao. Um correspondente de um tipo inverso de link pode ser especificado usando uma inverso de operador e suas instncias podem ser automaticamente geradas. Em casos mais sofisticados pode-se especificar as regras de derivaes tal como: dando um tipo de link a aplicao, se a instncia deste existir entre dois componentes de diferentes entidades, ento uma instncia do mesmo link um tipo derivado entre as duas razes que correspondem a entidade. A Figura 4.1 mostra um exemplo de um componente de entidade ou tipo em um documento de Leis, onde h seo 1.1, em um contrato X, que est sendo conectado pelo autor para o componente em uma entidade ou tipo de Lei - diga-se Artigo 2 da lei Y por um link do tipo justificado por. Ento se assume que o autor queira representar um fato em diferentes nveis de detalhes onde todo o contrato X, ( justificado) is-justified por toda a Lei Y.

FIGURA 4.1 - Exemplo de links de uma aplicao derivada. FONTE: Garzotto (1993). O HDM mostra ainda normas de traduo de links de um estado abstrato para um concreto baseadas na idia de se ter uma representao padro para cada objeto abstrato (entidade ou componente). Isso corresponde a idia de que o componente raiz na entidade, na perspectiva padro, permanece para aquela entidade. Esta noo de aplicao de links de entidade-paraentidade traduz em links concretos entre seus padres de representatividade. Cada link de aplicao componente-para-componente traduzido em um tipo de link concreto conectando

68

cada unidade da fonte do componente para um padro de representatividade do componente alvo (Garzotto, et all, 1993). A Figura 4.2 mostra um exemplo de traduo de links de abstrato para concreto.

FIGURA 4.2 - Traduo de links de abstrato para concreto. FONTE: Garzotto (1993). Consideraes: O HDM explora ainda vrias outras situaes mostrando como transformar situaes reais em links que faro parte de aplicaes de hipertexto e como entender e organizar estes links em documentos. A limitao deste modelo que voltado somente a parte de levantamento e organizao de requisitos. O HDM no traz especificaes de interface, de estruturas, de tecnologias ou de resultados finais em Web sites. 4.2.2 - RMM O Relationship Management Methodology (RMM) (Isakowitz, et all, 1995) faz uso de diferentes notaes e primitivas de modelagem para expressar os mesmos conceitos, que podem ser observados na representao da estrutura de acesso "ndice" no modelo RMM. Assim como o OOHDM e o HDM, o RMM tambm influenciado pelo modelo EntidadeRelacionamento (E-R). O RMM reconhece trs nveis, que so, o contedo, o hipertexto e a apresentao. O nvel de contedo modelado separadamente considerando que o nvel de apresentao refinado juntamente com o nvel de hipertexto. Um formalismo dedicado modelando o que se chama de Relationalship Management Data Model (RMDM) introduzido usando o modelo E-R para o nvel de contedo e conceitos de propriedade os quais so influenciados pelo HDM para o nvel de hipertexto e para o nvel de apresentao. 69

O conceito chamado de slices (pedaos) usado no plano entre o nvel de contedo e de hipertexto dos atributos de entidades do diagrama E-R e/ou previamente definem-se os slices que so agrupados. Assim o modelo navegacional de ndice e os derivados so criados. As relaes entre as entidades so usadas para capturar informaes contextuais durante a navegao. O diagrama de aplicaes cria a viso global no nvel de apresentao das aplicaes de Dados-Web capturando todas as pginas e hiperlinks pertinentes. Somente os aspectos estruturais so considerados em todos os nveis. O RMM especifica o processo de desenvolvimento com os passos iniciais para a anlise de requisitos, modelando o contedo em forma de diagramas E-R. Estes so seguidos por passos iterativos referindo-se ao diagrama de aplicao, ambos, base e topo pelo design de slice. A metodologia RMM destina-se ao projeto e ao desenvolvimento de aplicaes hipermdia que possuem uma estrutura regular no domnio de interesse, como classes de objetos relacionados. Prev tambm o uso de uma linguagem para especificar os objetos e os mecanismos de navegao em aplicaes hipermdia. Para tanto, o modelo de dados RMDM faz uso de um conjunto de primitivas grficas para descrever aplicaes hipermdia como: Primitivas de domnio E-R: modela informaes sobre o domnio da aplicao, tais como, entidades, atributos e relacionamentos. Primitivas de domnio RMM: atributos de uma mesma entidade podem ser agrupados em pedaos menores (slices) representando diferentes aspectos de um mesmo objeto. Cada slice pode ser visto como um n ou uma pgina em um mesmo contexto. Primitivas de acesso: possibilitam a navegao atravs dos objetos da aplicao hipermdia. Ligaes unidirecionais e bidirecionais podem ser utilizadas para acessar diferentes slices de uma mesma entidade, semelhante s ligaes estruturais do modelo HDM. A navegao entre entidades diferentes (tipos de ligaes em HDM) pode ser feita por meio de qualquer uma das primitivas abaixo ou por variaes e/ou combinaes entre elas: - ndices: o acesso obtido a partir de uma tabela de contedos para uma lista de instncias de entidades. - Roteiro guiado: consiste em um caminho linear atravs de uma coleo de instncias de entidades. 70

- Agrupamentos: um mecanismo semelhante a um menu de opes que oferece acesso a outras partes de um documento hipermdia. O modelo de dados RMDM utiliza conceitos do modelo E-R como base para descrever a estrutura de uma aplicao hipermdia. A partir da estrutura inicial, as primitivas especficas so usadas para representar elementos especficos de hipermdia (slices, links, ndices, roteiro guiado e agrupamentos) para modelar aplicaes. A abordagem RMM baseia-se no modelo cascata tradicional (fases de projeto, desenvolvimento e construo). Atividades tradicionais da engenharia de software devem ser empregadas antes e depois da modelagem da aplicao propriamente dita, que pode ser dividida em: Projeto de entidades e relacionamentos: so identificados as entidades e os relacionamentos mais significativos da aplicao. Projeto de slices: determina como as informaes da entidade escolhida sero apresentadas ao usurio e como podem ser acessadas atravs de ligaes unidirecionais ou bidirecionais. Projeto navegacional: nesta etapa so definidos os caminhos que habilitaro a navegao hipertexto. Cada relacionamento obtido no modelo E-R analisado e transformado (se necessrio) em uma primitiva de navegao (Isakowitz, et all, 1995). Consideraes: O RMM mostra os recursos necessrios para fazer o levantamento e a anlise dos requisitos, bem como a transformao dos requisitos obtidos, em estruturas de hipertextos. A limitao deste modelo, mesmo fazendo referncias a slices e Data-Web, estar muito direcionado ao desenvolvimento de softwares tradicionais. Isso faz com que aumente a distncia na comunicao entre desenvolvedores e administradores de Web sites. 4.2.3 - OOHDM O mtodo Object-Oriented Hypermidia Design Method (OOHDM) (Rossi, et all, 1996), um mtodo para desenvolver hipertextos baseado na orientao a objetos; analisa os objetos a serem colocados nos hipertextos e suas ligaes; composto por quatro atividades diferentes. 71

Projeto conceitual: modela a semntica do domnio da aplicao. Projeto navegacional: leva em considerao o perfil do usurio e a tarefa a ser executada; d nfase aos aspectos cognitivos. Apresenta ainda, uma reorganizao do modelo conceitual utilizvel por um grupo de usurios. O nvel de hipertextos modelado por dois conceitos diferentes, entendidos como Classe de Navegao e Contexto de Navegao. As classes de navegao so feitas por ns e por links. Os ns representam uma viso das classes conceituais, usando uma linguagem de consulta, enquanto os links so os relacionamentos explorveis. O contexto de navegao a estrutura do espao de navegao.

Projeto abstrato da interface: modela objetos perceptveis, implementa as metforas escolhidas e descreve a interface para os objetos navegacionais. Oferece a percepo que o usurio ter do espao navegvel, os diagramas de configurao e a viso abstrata dos dados.

Implementao: esta atividade responsvel por transformar um projeto em algo real, fazendo uso das tecnologias escolhidas.

No OOHDM, no h formalismos especficos empregados, mas somente a referncia que for estabelecida no diagrama. No nvel de apresentao chamado de Visualizao de Dados Navegacionais, o contexto navegacional propicia o modelo navegacional como o incio das opes de navegao. O comportamento da modelagem somente mencionado a respeito da definio da seqncia da navegao por meio de restries. No nvel de apresentao, o Modelo de Apresentao Esttica usa os diagramas da UML para representar as composies por meio de grficos e descreve o layout de interface do usurio. O modelo de apresentao dinmica emprega a UML estabelecida nos diagramas para descrever a ativao de navegao e as transformaes de interface do usurio. Para representar as interfaces de objetos mais freqentemente usados, como texto, imagem, udio e botes, so criados esteretipos (Rossi et all, 1996). Consideraes: O OOHDM trata de classes, contextos e transformaes, fazendo uso da UML para estereotipar os modelos das fases consideradas necessrias por este modelo. As limitaes encontram-se na falta de instrues de implementao, tipos de linguagens e/ou tecnologias que possam ser utilizadas e o porte/tamanho do Web site que poderia fazer

72

uso deste tipo de modelagem. O OOHDM tambm no mostra se o resultado de um projeto melhoraria o sistema para o usurio, que v/entende somente a arte e o design e no a engenharia usada no desenvolvimento do sistema. 4.2.4 - Conallen O modelo Conallen (Conallen, 1999) diferente dos demais mostrados nesta Seo, por ser em grande parte, uma tecnologia direcionada. A UML empregada como um formalismo bsico e estendido por meio de esteretipos e valores atribudos. Ao invs de distines entre os nveis de contedo, hipertexto e apresentao, o Conallen modela as pginas tanto do lado cliente como no lado do servidor, fazendo previses de sada ou estereotipando as classes UML. A UML em seu estado original, no possui esteretipos suficientes para modelar aspectos especficos de aplicaes Web. Foi analisada, ento, a WAE (Web Application Extension for UML), uma extenso para a UML criada por Jim Conallen (Conallen, 1999). A WAE estende a notao UML trazendo novos esteretipos com semntica e restries adicionais que permitem a modelagem de elementos especficos da arquitetura envolvida numa aplicao Web incluindo-os nos modelos do sistema. Utilizando a WAE possvel representar pginas, links e o contedo dinmico no lado cliente e no servidor. A Figura 4.3 mostra um modelo cliente x servidor com estrutura de pginas dinmicas.

FIGURA 4.3 - Modelo cliente x servidor. FONTE: Conallen (1999). Associaes estereotipadas so usadas para representar hiperlinks e para modelar o planejamento entre pginas clientes e pginas servidoras, desde que toda pgina dinmica cliente, seja construda como uma pgina servidora. Dados que entram em formulrios que 73

podem fazer parte de pginas clientes junto com seus relacionamentos de submisso para a pgina servidora so modelados por uma outra classe e associao de esteretipo, respectivamente. O sistema Conallen mostra que a modelagem de um sistema pode ser representada por diferentes modelos consistentes entre si. Cada modelo tem uma audincia e um propsito especfico. O modelo Conallen concentra-se em um modelo de design para aplicaes Web com a audincia voltada para o design de uma arquitetura. Uma das consideraes do Conallen que se uma aplicao for modelada usando UML, uma pgina pode ser entendida como um objeto e isso gera questes como quais so as propriedades de tais objetos? Estas propriedades so apropriadas para representar os elementos de um layout como fontes, tabelas, textos etc? Os scripts de uma pgina poderiam ser identificados como mtodos e uma pgina como objeto? Que modelo est sendo usado e quem faz a audincia? Para este modelo de projeto o formato da interface do usurio irrelevante e no necessariamente resulta em uma lgica do sistema. Scripts, especialmente scripts do lado do servidor resultam em um comportamento do sistema (e alguns sistemas representam um conjunto lgico do sistema). Alm disso, no difcil perceber variveis em uma pgina de script como sendo atributos de uma pgina-objeto e funo em uma pgina como sendo um mtodo. Tudo isso apropriado para um modelo de design e para uma aplicao Web voltada ao design. Isso, no entanto indicia um outro problema: pginas Web podem conter scripts para a mquina servidora e para a cliente. Misturando atributos e mtodos para execues clientes e servidoras pode dificultar o entendimento e isso pode ser resolvido usando um benefcio relativamente novo para a modelagem que so as novas extenses. A Figura 4.4 mostra os cones Esteretipos do Modelo Conallen.

74

FIGURA 4.4 - cones esteretipos. FONTE: Conallen (1999). Parte das extenses do mecanismo da UML capaz de especificar diferentes cones para estereotipar classes. O problema das pginas Web que tm diferentes scripts e variveis executadas no servidor e no cliente pode ser resolvido em uma destas duas formas. Na primeira seriam definidos os esteretipos do mtodo cliente e do mtodo servidor. Na pginaobjeto o mtodo que executa no servidor ser estereotipado como {{mtodo servidor}} e as funes que rodam no cliente {{mtodo cliente}}. Isso resolve o problema das distines dos atributos e mtodos das pginas-objeto, no entanto ainda continuam alguns pontos no resolvidos. As demais complicaes surgem mais tarde quando as associaes so feitas com outros componentes do modelo, onde no fica claro se alguns dos relacionamentos so vlidos somente no contexto do mtodo servidor ou no cliente. A melhor maneira de modelar uma pgina com duas classes de esteretipos separadamente. A Figura 4.5 mostra o esteretipo de uma pgina servidora construindo uma pgina cliente. 75

FIGURA 4.5 - Pginas cliente construindo uma pgina servidora. FONTE: Conallen (1999). Existem tambm esteretipos de classes para Java Applets, JavaScripts, controles ActiveX e frames. O Conallen no discute qualquer comportamento modelando a parte das operaes as quais podem ser definidas junto s classes estereotipadas e no sugere nenhuma fase de modelagem (Conallen, 1999). Consideraes: O modelo Criado por Conallen (WEA-UML), entre os mostrados nesta Seo, o que est mais voltado ao desenvolvimento de Web sites, pois trabalha resultados estticos e dinmicos de Web sites. Este modelo faz referncia a pginas que so geradas dinamicamente como respostas de consultas a bancos de dados; faz uso dos recursos da ES e da UML e cria esteretipos especficos para representar situaes que ocorrem tanto do lado servidor como do lado cliente em um processo de pginas dinmicas. Dos modelos citados nesta Seo, o proposto por Conallen o que mais se distingue dos modelos da Engenharia de Software, pois considera necessidades especficas para projetos Web. A limitao deste modelo que mesmo fazendo referncias a resultados de pginas dinmicas, clientes e servidoras, um modelo que instrui o desenvolvedor a testar aplicaes, interatividades e resultados obtidos de pginas clientes e servidoras. O modelo proposto por Conallen no um modelo voltado ao usurio final que trata da usabilidade ou se preocupa em como os resultados dinmicos sero vistos e entendidos pelo usurio. Uma outra limitao que faz a modelagem somente de um segmento de Web sites que a entrada e sada de dados em banco de dados e no do processo de desenvolvimento de Web sites como um todo. 4.2.5 - WebML

76

O Web Modeling Language (Ceri, 2000) uma notao visual para especificar a composio e a navegao de aplicaes de hipertexto. Construdo com padres populares como Entidade-Relacionamento e UML, o Web Modeling Language permite especificar complexas aplicaes Web em plataformas diferentes. O WebML estabelece graficamente especificaes formais incorporadas em um processo completo de design o qual pode ser visto atravs de ferramentas visuais. Os principais objetivos do processo de design do WebML so: Ilustrar a estrutura de uma aplicao Web com um alto nvel de descrio, o qual pode ser usado em consultas, atualizaes e manutenes; Propiciar mltiplas visualizaes do mesmo contexto; Separar informaes que contm a composio das pginas, navegao e apresentao, as quais podem ser definidas e organizadas de forma independente. Registra meta-informaes coletadas durante um processo de design dentro de um repositrio, o qual pode ser usado enquanto o tempo de vida da aplicao for dinamicamente gerando pginas Web; Modelar usurios e comunidades explicitamente em um repositrio, para permitir polticas de permisses e especificaes para aplicaes one-to-one; Habilitar especificaes de manipulao de dados e operaes para atualizaes de contedos ou interaes com servios externos arbitrrios. Os modelos de composio, estrutura, navegao e apresentao possibilitam a descrio de leitura em Web sites. Estes modelos podem ter ampliaes com especificaes de gerenciamento do contedo e integrao com servios externos, durante operaes adicionais, as quais podem ser definidas e adicionadas ao modelo de hipertexto. Os modelos so vistos como um efeito de navegao e permitem uma especificao que normalmente encontra interao como padro de entrada de dados, gerenciamento de dados pessoais e carrinhos de compras. Os modelos previstos no WebML so classificados como modelo de dados, modelo de hipertextos, modelo de apresentao e processos WebML. Modelo de dados: o modelo de dados WebML uma adaptao do modelo conceitual para o design de dados, como j mostrado na Engenharia Web, tal 77

como design de banco de dados, engenharia de software e demais representaes de contedo. O modelo de dados compatvel com o modelo EntidadeRelacionamento, usado no design conceitual de banco de dados, com os diagramas de classes da UML, usado na modelagem de orientao a objetos. O fundamento dos elementos do modelo de dados so entidades, definidas como recipientes de elementos de dados, e relacionamentos, definidos como semnticas de conexes entre as entidades. As entidades tm propriedades nomeadas, chamadas atributos, com tipos associados. As entidades podem ser organizadas em gneros hierrquicos e os relacionamentos podem ser limitados pelo significado da cardinalidade das restries. As instncias das entidades so consideradas individualmente e endereadas significando um Identificador nico. Os Identificadores nicos da WebML so conceitos abstratos, os quais podem ser implementados de forma alternativa subjacente ao recipiente de gerenciamento com chave primria para armazenamento de dados relacionais ou atributos ID de XML em fontes de dados XML. A Figura 4.6 mostra um exemplo do modelo de dados representando informao sobre lbuns musicais que so compostos por artistas, sobre os quais so disponibilizadas algumas resenhas. Cada lbum pode conter vrias faixas.

FIGURA 4.6 - Modelo de dados WebML. FONTE: Ceri (2000). Modelo de hipertextos: o modelo de hipertextos especifica a composio e a navegao do site. A composio descreve quais pginas compem o hipertexto e quais unidades de contedo formam uma pgina. As pginas do Web site so 78

recipientes da informao mencionada no cabealho. As unidades so atmicas contendo elementos usados para publicar informaes descritas no modelo de dados. Sete tipos de unidades so pr-definidas em WebML para compor as pginas: dados, multi-dados, index (e suas variveis de mltipla escolha e hierarquias), entradas e scrollers. Cada unidade est associada a uma entidade subjacente da qual a unidade de contedo computada. A especificao da entidade subjacente impe o tipo de objeto do qual a unidade de contedo derivada. Quando apropriado, as unidades podem ser opcionalmente associadas a um seletor e uma especificao do grupo de restries determina a instncia atual da entidade subjacente para ser usada como uma unidade de contedo em tempo corrente. A navegao do site especificada diretamente nos links. Os links podem ser definidos entre as unidades dentro de uma pgina comum, entre unidades localizadas em pginas diferentes e entre pginas. A informao trazida junto do link chamada de navegao contextual ou simplesmente contexto. Os links que trazem informao de contexto so chamados de links contextuais, considerando que os links que no tm contextos informativos associados so chamados de links no-contextuais. Uma informao de contexto tipicamente necessria para assegurar a computabilidade das unidades. A Figura 4.7 refere-se a um exemplo de especificao de hipertexto do WebML.

FIGURA 4.7 - Especificao de hipertexto do WebML. FONTE: Ceri (2000). 79

Modelo de apresentao: a apresentao uma tarefa ortogonal definindo a visualizao das pginas dentro da viso do site. Desde que as especificaes WebML possam ser representadas usando XML, a apresentao considerada como um documento de transformao, mapeando as especificaes WebML da pgina escrita em uma concreta implementao de linguagem como JSP ou ASP.NET. Conseqentemente a apresentao endereada em WebML, utilizando estilos XSL para visualizao do site, pginas, unidades e unidades de subelementos. As folhas de estilo XSL inserem especificaes WebML, codificando como documentos XML conforme a definio do documento WebML e exporta modelos de pginas incorporando o cdigo e os dados acessados naquela consulta. A implementao de WebML pode incluir vrios estilos de apresentao prdefinidos e os componentes do lado do servidor, suportando o acesso a consultas de dados necessrios para compor o contedo das pginas produzidos pelas folhas de estilo XSL.

Processos WebML: o WebML aborda a desenvolvimento de aplicaes Web consistindo em diferentes fases que podem ser aplicadas de maneira interativa e incremental. O processo suporta vrios ciclos, cada ciclo produzindo um prottipo ou uma verso parcial da aplicao que permite a conduo de testes e a evoluo desde o desenvolvimento das fases iniciais. A Figura 4.8 mostra o desenvolvimento de aplicaes Web consistindo em diferentes fases que podem ser aplicadas de maneira interativa e incremental.

80

FIGURA 4.8 - Desenvolvimento de aplicaes Web. FONTE: Ceri (2000). Fora do processo como um todo, os dados e o design de hipertexto so as atividades mais influenciadas pela adoo do WebML. A aproximao do design de dados no aponta uma substituio para as diretrizes de proposta geral do modelo de dados conceitual, mas simplesmente os estende com algumas poucas regras especficas de manuseio, os quais podem ajudar no design de dados para a Web. A publicao de dados e o gerenciamento do contedo de aplicaes tm algumas regularidades peculiares, as quais podem ser exploradas no design de dados. O reconhecimento destes detalhes pode ajudar no design dos dados organizando o trabalho de uma maneira sistemtica, a qual normalmente resulta em sistemas de dados mais consistentes. Entretanto, este mtodo enfatiza regras distintas representadas por objetos e usa estas distines para propor uma seqncia de passos para agrupar esquemas de dados de aplicaes Web. Depois do design de dados, o design de hipertexto procede fazendo com que o primeiro design das atividades aponte para a produo do primeiro nvel de especificao da visualizao do site que explora uma notao textual informal. Para expressar a visibilidade dos nveis de visualizao das reas do site (marcas, padres ou reas internas) especifica o contedo da rea usando as entidades e relacionamentos do esquema de dados. Procedendo dessa maneira, uma ateno especial destina-se as regras representadas 81

por vrios elementos de dados, os quais podem ser explorados acessando informaes, para publicar contedos retirados dos objetos, para interconexo retirada dos objetos ou para personalizao de propsitos. Um design detalhado explora sub-esquemas de hipertexto. O design detalhado explora os sub-esquemas de hipertextos do WebML, os a quais so configuraes cannicas de pginas, unidades, construo, acesso, interconexo e personalizao dos sub-esquemas. Consideraes: O WebML apresenta basicamente um modelo de dados, um modelo de hipertexto, um modelo de apresentao e um modelo de processos. O modelo de dados representado tipicamente pelo modelo Entidade-Relacionamento, usado na Engenharia de Software. O modelo de hipertexto ilustra o sistema de hipertexto e mostra as possibilidades de respostas dos bancos de dados e como o usurio pode interagir com as pginas. O modelo de apresentao mostra o design das pginas dentro de um site com o exemplo do uso de linguagens do lado cliente e do lado servidor como recurso de implementao. O modelo de processos aborda diferentes fases que podem ser aplicadas de maneira incremental. O processo mostra vrios ciclos atravs de prottipos de verses parciais de uma aplicao. As limitaes do WebML encontram-se no uso de seus conceitos. Por ser um modelo conceitual de modelagem, mesmo mostrando como fazer uso de folhas de estilo e XML, no prev uma forma de implementao. No modelo de processos, por exemplo, o design dos dados, o design de hipertexto, aparecem logo no segundo e terceiro nvel e a implementao, que dentro de uma seqncia lgica de aplicaes para a Web apareceria logo aps a especificao dos requisitos, aparece em um quarto nvel. Dentro da anlise realizada no WebML no foi possvel identificar uma forma de implementao utilizando a seqncia sugerida pela modelagem se o design dos dados, o design de hipertexto e a arquitetura do design que aparecem antes de se comear a implementao; que tipos de testes de evoluo podem ser feitos antes do efetivo desenvolvimento; como se pode definir design de dados, design de hipertextos e arquitetura de design sem antes fazer o planejamento da estrutura do Web sites. 4.2.6 - Tabela Demonstrativa dos Modelos Citados

82

TABELA 4.1 - Comparativo entre os modelos apresentados nesta Seo. Modelo HDM Ano 1993 Autor Garzotto, Frana Fonte Resumo

RMM

1995

OOHDM 1996

ACM transaction Dispositivo de modelagem on Information para descrever aplicaes de Systems. Vol. 11. hipertexto. Define semnticas de navegao que especificam a dinmica do comportamento de um sistema hipermdia. Isakowitz, Toms Communications Faz uso de diferentes notaes of ACM. Vol. 38. e primitivas de modelagem para expressar os mesmos conceitos; influenciado pelo modelo E-R; reconhece trs nveis: hipertexto, apresentao e contedo. Rossi, Gustavo PUC Rio: tese de Mtodo para desenvolver doutorado. hipertextos, baseado na orientao a objetos; analisa os objetos a serem colocados nos hipertextos e suas ligaes; usa as possibilidades da UML para representar as composies navegacionais. Conallen, Jim Communications of ACM. Vol. 42. Modela pginas no lado cliente e no lado servidor, estereotipando as classes UML; Sugere esteretipos especficos para aplicaes Web; associaes estereotipadas so usadas para representar hiperlinks.

Conallen 1999

WebML

2000

Ceri, Stefano

WWW9 Notao para visualizar especificaes complexas de Conference, Amsterdam, 2000. Web sites no nvel conceitual. Todos os conceitos do WebML so especificados graficamente e em XML; a composio das abstraes so baseadas em um restrito nmero de componentes de hipertexto os quais so montados em uma pgina e interconectados por links.

83

4.2.7 - Modelos Desenvolvidos a Partir dos Modelos Mostrados nesta Seo Alm dos modelos mostrados nesta Seo, existem outros que so voltados modelagem de dados em projetos para a Web, que vieram a partir dos modelos citados, como por exemplo, o OOHDM-ML e o Modeling data entry and operations in WebML. OOHDM-ML: (Medeiros, 2001) apresenta uma linguagem declarativa para especificao de aplicaes hipermdia projetadas de acordo com as primitivas do mtodo OOHDM, e o ambiente OOHDM-XWeb, criado para prover a implementao dessas aplicaes. Compreende duas etapas principais: a especificao da aplicao atravs de um mtodo de projeto (por exemplo, OOHDM) e sua implementao em alguma linguagem (atravs de um ambiente de suporte). A Linguagem XML utilizada utilizada para descrever o projeto OOHDM para uma aplicao hipermdia. Modeling data entry and operations in WebML: (Ceri, 2002) faz uso dos recursos WebML com entradas de dados e unidades de operaes para reunir informaes dos clientes e chamar operaes arbitrrias. Operaes pr-definidas tambm so sugeridas como construtor interno de primitivas para suporte de padres de atualizaes do contedo subjacente da fonte de dados (representada como E-R). As extenses primitivas do WebML permitem visualizar a modelagem de pginas Web integrando acessos de escrita e leitura em aspectos essenciais como aplicaes de e-commerce (incluindo perfil de usurios e gerenciamento de carrinhos de compra). 4.2.8 - Consideraes Gerais Os Web sites encontram-se em fase de maturidade ou na fase onde muitos problemas existentes esto sendo identificados, mas com poucas solues apontadas e as solues j apontadas, muitas vezes, so apenas tericas. As dificuldades de um Web designer para transformar um projeto feito a partir da maioria dos modelos de Engenharia Web em um produto final ou em Web site, ainda so muito significativas, devido a falta de seqncias lgicas, que possam ser colocadas em prtica. O processo ora proposto considera que Web sites so sistemas desenvolvidos por profissionais da Web, para usurios da Web. Dessa forma no bastaria um modelo que apenas fizesse a modelagem de necessria implementao se os benefcios desta modelagem no chegassem at o usurio. Tambm no bastaria um design atraente e um bom sistema de 84

hipermdia, com estrutura e funcionalidade inconsistentes. Este processo prope trs fases para o desenvolvimento de Web sites que se compreendem pelo levantamento de requisitos, implementao e design, fazendo uso de tcnicas de design, linguagens, tecnologias e dos recursos da UML.

85

86

CAPTULO 5 PROCESSO DE DESENVOLVIMENTO DE WEB SITES COM RECURSOS DA UML

Nesta Seo, introduz-se um processo de desenvolvimento de Web sites, que a contribuio deste trabalho. Este processo de desenvolvimento, chamado de Processo de Desenvolvimento Web com recursos da UML (PDW-UML), especifica trs fases, mostrando a evoluo de um Web site desde o levantamento de requisitos at o design final das interfaces. Como o processo abrange diversas etapas e as mostra em trs fases, pretendese com isso reduzir as dificuldades existentes pelos profissionais da Web em transformar os projetos Web em um produto final, que so os Web sites. Este processo mostra a soluo para alguns problemas de interfaces Web mostrados pela Engenharia Web como estrutura, tempo de carregamento de cada pgina, tamanho de URLs e design das interfaces procurando colocar em prtica o que chamado pela Engenharia Web de Sistema Orientado ao Usurio (Leite, 2002). Para o desenvolvimento de um Web site com o PDW-UML, pode-se utilizar um Sistema Operacional como o Windows NT/2000/XP que utiliza o servidor IIS, sendo necessria a instalao de um servidor de PHP (poderia ser um outro servidor de pginas dinmicas. Para as explanaes deste trabalho ser usado PHP). Outra opo so os sistemas Unix/Linux com o servidor Apache. Diferentes dos softwares convencionais onde se estudam os recursos de software e hardware disponveis em uma organizao antes de se comear a desenvolver um produto, os Web sites tm que ser desenvolvidos considerando possibilidades de recursos. Por isso, precisam buscar padres de desenvolvimento que possam reduzir ao mximo a dependncia dos recursos do usurio, fazendo com que uma pgina seja vista da maneira mais uniforme possvel, independente do sistema do usurio. Uma soluo encontrada para esta necessidade mostrar no presente processo um tipo de estrutura que utiliza a tecnologia Server Side Include (SSI - Seo 2.2.2.1) onde a mquina servidora seja responsvel pela pgina gerada e no os recursos da mquina do usurio. Quando um usurio acessa uma pgina desenvolvida com SSI, a mquina cliente faz a requisio para a mquina servidora que processa a requisio, enviando para o usurio

87

somente o HTML gerado. Assim, a resposta ser a mesma para qualquer usurio, independente dos recursos que possa ter em sua mquina. No PDW-UML no h o reconhecimento da necessidade de desenvolvimento de prottipos e nem se determina uma fase especfica para testes. Como a maior parte do funcionamento se concentra no sistema de navegao utiliza-se o procedimento de Implementar-Testar (IT) com nfase nos testes no final das fases de implementao e de design das interfaces. Com isso identificam-se os riscos e as inconsistncias logo no incio do ciclo de vida link-pgina, ou seja, to logo seja desenvolvida uma pgina e um link que aponte para esta, so feitos os testes necessrios. Este processo baseado em trs fases: a fase de levantamento de requisitos, a fase de implementao e a fase de design das interfaces. Fase 1: levantamento de requisitos. A fase de levantamento de requisitos levanta os objetivos do domnio e busca as informaes disponveis para que haja um planejamento do Web site; faz o levantamento das necessidades do projeto e do sistema atravs dos recursos da UML e organiza os requisitos necessrios implementao. Para fazer a modelagem o PDW-UML utiliza os diagramas da UML. Fase 2: implementao. a fase de implementao desenvolve os arquivos e diretrios que formam a arquitetura lgica de acordo com um modelo de Estrutura Dinmica (ED) proposto para implementar o PDW-UML. Os requisitos levantados na fase anterior so analisados e utilizados para a composio das interfaces e do sistema navegacional. Nesta fase faz-se a previso dos nveis de Uniform Resource Locator (URLs) e das portas de entrada do usurio; faz-se as convenes de design das interfaces; elabora-se a documentao com as informaes pertinentes ao Web site e as instrues de administrao para os Web designers e fazem-se os testes navegacionais a partir da mquina servidora. Fase 3: Design das interfaces. A fase de design das interfaces busca aprimorar o que foi desenvolvido nas fases anteriores propondo um tempo e um espao dentro de um processo para que haja a realizao artstica e criativa. A proposta para a fase de design uma forma de cultura que envolve esttica, arte e tica como base para um estilo de design. na terceira fase que se aprimoram os resultados do trabalho 88

realizado nas fases 1 e 2. Nesta fase o que predomina a arte e a esttica que podem ser vistas na distribuio dos links nas pginas, nos ttulos, nos cabealhos, nos nomes dos links, nas cores, nas animaes e no design em geral. A fase de design das interfaces considerada como artstica considerando que aps a concluso das fases 1 e 2 j se obteve a funcionalidade desejada. A partir da o resultado pode ser sempre diferente de acordo com a maturidade (tcnica/visual/auditiva/cultural) de cada profissional. A Figura 5.1 mostra um diagrama com uma viso geral do processo proposto.

FIGURA 5.1 - Viso geral do PDW-UML. O PDW-UML um processo voltado ao desenvolvimento de interfaces, cujo funcionamento baseado em uma forma de estrutura dinmica que faz uso de HTML, SSI e CSS; o contexto geral do processo baseado em trs fases e a modelagem baseada nos recursos da UML. A seguir so mostradas as trs fases do PDW-UML, que so as fases de levantamento de requisitos, implementao e design das interfaces. 89

5.1 - Fase 1: Levantamento de Requisitos Na primeira fase o PDW-UML faz a anlise dos requisitos necessrios ao desenvolvimento do Web site e o levantamento dos requisitos de contedo. Nesta fase os requisitos de contedo so armazenados e classificados conforme perspectivas de desenvolvimento de interfaces. Na segunda fase, que a fase de implementao, os requisitos de contedo so selecionados e utilizados conforme estejam de acordo com as informaes que se pretende disponibilizar em cada interface. No PDW-UML os requisitos so classificados como requisitos de contedo, requisitos operacionais e requisitos de desenvolvimento. 5.1.1 - Requisitos de Contedo Os requisitos de contedo so os assuntos que sero expostos nas interfaces representando os atributos das mesmas (textos, imagens, links e formulrios). Para obter os requisitos necessrios para compor as interfaces necessrio o levantamento de assuntos que possam compor o que est sendo sugerido por um link como, por exemplo, se o domnio de uma empresa tem um link chamado: Produtos: para produtos necessrio fazer o levantamento dos produtos desta empresa com informaes como preo, disponibilidades de estoque e de entrega, informaes tcnicas (tamanho, medidas, fragilidades), procedimentos de aquisio, descrio e informaes complementares. Servios: para servios so necessrias informaes sobre os servios oferecidos pela empresa como, por exemplo, se so servios de consultoria, suporte tcnico, quais so as bases de preos para estes servios, informaes dissertativas sobre os servios oferecidos, informaes sobre a qualificao das pessoas que prestam estes servios etc. Funcionrios: para funcionrios faz-se o levantamento de informaes como qualificao profissional, canais de contato (telefone, e-mail, instant messanger, endereo para correspondncia) etc. 90

Informaes: as interfaces de informaes normalmente oferecem opes para que um usurio solicite informaes que no estejam disponveis no site ou ento, para que o usurio fornea suas informaes atravs de um sistema de cadastro. Para este tipo de interface os requisitos necessrios so as informaes de como o usurio far uso dos formulrios atravs de etiquetas que vm antes dos campos de texto como, por exemplo, nome, sobrenome, e-mail etc, ou instrues de como solicitar informaes ao administrador do domnio.

Estes requisitos podem ser provenientes de vrias fontes como, por exemplo, textos de jornais, livros, revistas, udios, vdeos, depoimentos, entrevistas, destaques publicitrios, imagens, pginas Web, sugestes do cliente etc. A partir destas fontes so elaborados textos, imagens e links que compem as interfaces. Nesta fase todos os tipos de informaes referentes ao domnio so aceitos e armazenados e posteriormente analisados para compor o contedo das interfaces. A seleo feita durante a composio dos arquivos, na fase de implementao. Os requisitos de contedo so depositados nos diretrios correspondentes s interfaces. Os tipos de requisitos podem ser textos, udios, imagens, vdeos ou pginas Web. A Figura 5.2 mostra um exemplo de armazenamento das informaes pertinentes a um domnio genrico aqui chamado de empresa.

91

FIGURA 5.2 - Armazenamento de informaes. Antes de comear a implementao, os requisitos obtidos so armazenados em um diretrio qualquer. Conforme haja segmentos pertinentes ao domnio, criam-se subdiretrios para que as informaes possam ser armazenadas conforme um segmento que tenha perspectiva de formar um link e sua respectiva interface. Nesta fase entende-se que para cada subdiretrio ser desenvolvido um link que ir compor a barra de navegao. Conforme mostrado na 92

Figura 5.2, considera-se um domnio chamado empresa. Esta empresa oferece produtos, servios, tem funcionrios e dispe de um canal de comunicao chamado de informaes. O armazenamento dos requisitos em quatro subdiretrios representa uma perspectiva para o desenvolvimento de cinco interfaces: a home page, produtos, servios, funcionrios e informaes. Estes requisitos continuaro como perspectivas de links e de interfaces at a segunda fase onde se inicia a implementao. 5.1.2 - Requisitos Operacionais Para que os requisitos de contedo possam ser organizados e para que se possa fazer a escolha dos requisitos operacionais necessrio que sejam definidos alguns aspectos funcionais como a arquitetura fsica e lgica, a forma de organizao das informaes, a estrutura onde ser feito o design e a previso de sada de banco de dados (gerao de pginas dinmicas) e os recursos de hardware, software e banda. Arquitetura: a arquitetura de um sistema entendida como arquitetura fsica ou lgica, sendo que necessrio a existncia da arquitetura fsica para que a lgica possa existir, ou seja, a arquitetura lgica construda a partir da arquitetura fsica. - Arquitetura fsica: a arquitetura fsica representa os recursos de hardware existentes tanto na mquina servidora como na mquina cliente. - Arquitetura lgica: a arquitetura lgica representa a maneira como os arquivos e diretrios esto organizados a partir de um diretrio root. A Figura 5.3 mostra a ilustrao de uma arquitetura fsica e de uma arquitetura lgica.

93

FIGURA 5.3 - Arquitetura fsica e arquitetura lgica. Organizao das informaes: de acordo com a arquitetura lgica tm-se as classificaes das formas de organizao das informaes. Essas formas de organizao podem ser hierrquica, linear e em forma de rede. As organizaes linear e em forma de rede quase no so usadas em Web sites, pois no conseguem proporcionar um bom entendimento, bem como uma boa organizao do sistema. A organizao hierrquica a que mais se utiliza atualmente. O nmero de arquivos existentes no diretrio root depender da estrutura escolhida para as interfaces, independente de ser a organizao hierrquica ou outra forma de organizao. Para o sistema de estrutura proposto no PDW-UML so necessrios dois arquivos no diretrio root e os demais em seus respectivos subdiretrios. A Figura 5.4 mostra uma organizao hierrquica, desenvolvida a partir de um diretrio root. 94

FIGURA 5.4 - Organizao hierrquica. Estrutura onde ser feito o design: a estrutura escolhida que determina a forma de navegao do Web site. De acordo com a estrutura escolhida que se pode decidir quantos arquivos ficaro no diretrio root; qual o valor do parmetro target que ser utilizado nos links; quantos nveis existiro nos URLs e a criao de diretrios especficos para um determinado tipo de arquivo. A distribuio do contedo dentro de um arquivo tambm feita de acordo com estrutura escolhida. Para interfaces com Estrutura Dinmica (ED), como propostas neste trabalho, elaboram-se os arquivos de forma independente e faz-se a incluso dos que sejam necessrios para compor uma pgina em um arquivo-matriz que inclui os arquivos de interface e de contedo dentro do prprio arquivo que faz a estrutura. Previso da interface de sada de banco de dados: a estrutura tambm determina como ser a interface gerada dinamicamente atravs da sada obtida de consultas a bancos de dados. Para o sistema de ED basta indicar o nome do arquivo-matriz elaborado para a sada da interface que ser gerada para cada tipo de consulta para que se obtenha o contedo gerado juntamente com o menu e as instrues de interface. Hardware: os recursos de hardware representam os recursos fsicos que uma mquina precisa ter para que os softwares sejam instalados. Para o desenvolvimento e administrao de um Web site, os recursos que mais influenciam no rendimento operacional so espao em disco, memria, processador e placa de vdeo. Os demais 95

recursos dependem de necessidades especficas ou necessidades que um Web site poder ter e outro no, como por exemplo, placa de som, Web cmera etc. Software: os softwares necessrios ao desenvolvimento e administrao de um Web site podem ser definidos como o sistema operacional, o servidor de pginas Web, softwares de criao e tratamento de imagens, edio de cdigos, diagramao, edio de textos e de animaes. Algumas linguagens dependem de softwares especficos para que sejam processadas ou compiladas, como o caso da linguagem PHP que precisa do servidor Apache para ser processada. Banda: no lado cliente no h necessidades de grandes preocupaes com a velocidade da banda, uma vez que os arquivos e diretrios so desenvolvidos na mquina local ou cliente e podem ser enviados ao servidor at mesmo de uma outra mquina onde haja um sistema de banda larga. No entanto, a velocidade do lado servidor um dos fatores prioritrios para determinar a velocidade de navegao (upload dos arquivos). 5.1.3 - Requisitos de Desenvolvimento Os requisitos de desenvolvimento representam a definio das pessoas necessrias ao desenvolvimento do Web site; os cronogramas de entrega de cada fase, bem como da concluso do Web site; os custos que incorrero durante todo o processo de desenvolvimento e as previses de custo de administrao. Pessoas: o perfil dos profissionais necessrios ao desenvolvimento e manuteno de um Web site varia de acordo com sua a complexidade. As categorias de profissionais da Web so relativamente novas, sendo que para profissionais que fazem o desenvolvimento e administrao de Web sites os mais comuns so, Web designers e Web masters. - Web designer: o profissional que cuida da parte visual do site como, por exemplo, desenvolver e manipular artes grficas, bem como programar em linguagens como HTML, CSS e JavaScript, PHP etc. - Web master: o responsvel pelo desenvolvimento, manuteno e gerenciamento do Web site. Deve ter os mesmos conhecimentos que tem o Web designer, programao em linguagens diversas para a Web, tcnicas de 96

redao e ainda conhecimentos da rea tcnica como TCP/IP, hardware, segurana de redes e preparao e segurana de hosts. Dependendo da complexidade ou das necessidades do Web site, so necessrios profissionais que ofeream trabalhos especialistas como em bancos de dados e programao especializada em uma determinada linguagem/tecnologia. Cronogramas: os cronogramas podem ser desenvolvidos visando a concluso do Web site como um todo ou visando a concluso de fases especficas. Custos: os custos com um Web site so custos com pessoas, softwares e hardwares, nas fases de desenvolvimento e manuteno. Os custos variam de acordo com a qualidade de um trabalho, qualificao dos profissionais envolvidos, e com a complexidade do Web site em questo. difcil generalizar a distribuio dos custos, pois estes variam de acordo com a complexidade e com o objetivo de cada projeto. Um Web site informativo que tenha como contedo predominante a recuperao de manuscritos, levantamento de fatos histricos, concentraria maiores custos na fase de levantamento de requisitos. Um Web site onde o objetivo principal seja o comrcio eletrnico, tem os custos concentrados na fase de implementao devido as necessidades de segurana, cadastros de dados e testes de funcionalidades. J um Web site com motivos artsticos como lojas de decoraes, cosmticos e produtos em geral que precisam ser vistos a partir de um design diferenciado, concentra os maiores custos na fase final que a fase de design das interfaces. A Figura 5.5 mostra alguns exemplos de concentrao de custos de acordo com cada fase.

97

FIGURA 5.5 - Concentrao de custos. 5.1.4 - Modelagem do Domnio Ao analisar os assuntos que fazem parte de um domnio j se podem estabelecer as perspectivas de desenvolvimento de interfaces. O prximo passo para entender o sistema fazer a modelagem do mesmo. Os recursos da UML utilizados na fase de levantamento de requisitos representam vises estticas e dinmicas que ilustram as caractersticas do projeto e do sistema (Web site). As caractersticas ou necessidades do projeto so mostradas atravs dos diagramas de atividades e as necessidades do sistema so mostradas atravs dos diagramas de casos de uso. 5.1.4.1 - Interaes e Atividades Os Web sites so sistemas que normalmente tm interao com trs tipos de atores: o cliente que o proprietrio do domnio, a equipe de desenvolvimento e administrao e os usurios que so usurios da entidade ou da empresa e os internautas. O cliente e a equipe interagem com o sistema com o objetivo de desenvolv-lo e administr-lo para que os usurios possam fazer uso.

98

Com os diagramas de atividades so mostrados os fluxos das atividades, ou fluxos de trabalho, que envolvem o projeto como, por exemplo, as atividades do cliente, da equipe e dos usurios mostrando etapas seqenciais. A Figura 5.6 mostra um diagrama de atividades com os principais atores, atividades e interaes de um Web site.

FIGURA 5.6 - Principais atividades e interaes de um Web site. Cliente: o cliente de um Web site representa o proprietrio ou o responsvel por um domnio tambm chamado de contato da entidade. O cliente normalmente quem 99

sugere o que precisa ser feito e como gostaria que fosse o design e o funcionamento geral do Web site, sem preocupaes de como ser feito. No entanto, o papel desempenhado pelo cliente ilustra atividades do projeto e no diretamente do sistema. A Figura 5.7 mostra um diagrama de atividade com as aes que um cliente desempenha em um projeto de Web site.

100

FIGURA 5.7 - Diagrama de atividades com as aes do cliente. Na figura 5.7 utiliza-se uma convenincia que a palavra reservada else para marcar uma transio de sada, representando o caminho a ser seguido, caso nenhuma outra expresso de proteo seja avaliada como verdadeira (Booch, 2000). Equipe de desenvolvimento e administrao: interage de forma indireta com o sistema e de forma direta com o projeto, podendo fazer o desenvolvimento de novas interfaces, atualizaes, acrscimos e redues de contedos em interfaces desenvolvidas anteriormente; fazendo estudos de viabilidades tecnolgicas, bem como a migrao de tecnologias, quando necessrio. A equipe desempenha atividades conforme instrues do cliente com o objetivo de disponibilizar ao usurio possibilidades de navegao e interao com o sistema desenvolvido. A Figura 5.8 mostra um diagrama de atividades com as principais aes da equipe de desenvolvimento e administrao para com o Web site.

101

FIGURA 5.8 - Diagrama de atividades com as aes da equipe. 102

Usurios: os usurios so as pessoas que fazem uso do sistema podendo ser fornecedores de dados e informaes ou pessoas que fazem uso do sistema na forma de navegao e interao. Os usurios de um sistema podem ser os usurios da entidade ou os usurios da Web, chamados tambm de internautas. - Usurios da entidade: os usurios da entidade realizam atividades como, cadastros de produtos, atualizaes de estoque e preos etc. Os usurios da entidade desempenham algum papel quando o Web site dispe de interfaces dinmicas, principalmente em Web sites de comrcio eletrnico onde a equipe desenvolve o sistema para os internautas e para usurios da entidade que fazem lanamentos e atualizao de dados. - Internautas: os internautas so os usurios principais do Web sites pois fazem uso do sistema independente do tipo de interface existente no mesmo. Quando o sistema dispe somente de interfaces estticas os usurios podem navegar de uma interface para a outra e podem interagir com o sistema quando este dispe de interfaces dinmicas. A Figura 5.9 mostra um diagrama de caso de uso com as principais aes dos usurios com o Web site.

103

FIGURA 5.9 - Diagrama de casos de uso com as aes dos usurios. O usurio depende de aprovaes da equipe e do cliente para que o Web site esteja disponvel on-line. O usurio interage com o sistema atravs de um navegador podendo inserir o URL no location do navegador, acessar a pgina e fechar o navegador quando concluir sua navegao. O usurio acessa um domnio, composto por interfaces que se relacionam com outras interfaces atravs de algum mtodo. Estas interfaces possuem atributos do tipo link, textos, imagens e formulrios. Porm, diferente do cliente e da equipe, o usurio v somente o design, o contedo, a arte e no a engenharia atravs da qual o sistema foi desenvolvido. Se uma interface possui somente textos, imagens e links o usurio s pode copiar, fazer download de arquivos ou escolher outro link. Se a interface dispe de formulrios o usurio pode interagir de diversas formas. Em uma interface do sistema tem-se um atributo de tipo link cujo contexto representa uma classe navegacional que faz parte do contedo do domnio. Um usurio realiza a operao Navegar que Clicar em um link. O sistema ento, apresenta ao usurio o contexto escolhido. Diante deste contexto o usurio poder realizar operaes especficas como 104

incluir, consultar, alterar e excluir dados (exemplo de um carrinho de compras), ou repetir a operao anterior que Clicar em outro link. O usurio pode escolher Clicar em outro link tendo ou no realizado outras operaes disponveis dentro deste contexto. A Figura 5.10 mostra um exemplo de interfaces estticas e dinmicas em um diagrama de classes com os nomes, atributos e mtodos conforme o tipo da interface.

FIGURA 5.10 - Interfaces estticas e dinmicas mostradas em um diagrama de classes.

105

Conforme mostra a Figura 5.10 as interfaces dinmicas apresentam mtodos e atributos que as interfaces estticas no apresentam. Atravs de um atributo do tipo formulrio comeam as interaes dos usurios atravs de mtodos que so especficos de interfaces dinmicas. As operaes executadas em interfaces dinmicas que no tenham incio a partir de um formulrio so as mesmas executadas em interfaces estticas. 5.1.4.2 - Modelagem das Interfaces Dinmicas A modelagem das interfaces estticas visa proporcionar aos desenvolvedores Web uma viso formalizada do uso de um Web site. No entanto, quando um Web site tem como parte integrante interfaces dinmicas ou interfaces que so geradas dinamicamente atravs de consultas a bancos de dados a modelagem assume caractersticas muito semelhantes s utilizadas na engenharia de software. A modelagem das interfaces dinmicas mostrada atravs dos diagramas de casos de uso, dos diagramas de classes e dos diagramas de seqncia. Embora a engenharia de software tenha caractersticas diferentes da engenharia Web, quando h situaes de interfaces dinmicas o sistema de modelagem de ambas seguem os mesmos padres. Para a modelagem das interfaces dinmicas, o PDW-UML faz uso da UML como se faz para modelagens de outros sistemas, pois nesse ponto embora os fins sejam diferentes, os meios so muito semelhantes. A modelagem da interface produtos mostrada a seguir atravs dos casos de uso fazer gesto de cadastro e fazer compras, onde o ator que interage com o sistema o usurio. Casos de uso: um diagrama de caso de uso mostra um conjunto de casos de uso e atores e seus relacionamentos. Estes diagramas so utilizados para ilustrar as necessidades um sistema, observvel por um ator. Atravs dos elementos dos diagramas de casos de uso possvel uma visualizao de quem so os atores do sistema e quais os tipos de interao que o sistema permite (Booch, 2000). A Figura 5.11 mostra um diagrama de casos de uso com os principais tipos de necessidades de interfaces dinmicas.

106

FIGURA 5.11 - Casos de uso de interfaces dinmicas. O caso de uso mostrado na Figura 5.11 mostra necessidades de uso de um sistema que tenha interfaces do tipo formulrio, contextual e interativa (esteretipos na Tabela 5.3). Classes: Um diagrama de classes mostra um conjunto de classes, interfaces, colaboraes e seus relacionamentos. Atravs de um diagrama de classes representa-se a estrutura de um sistema; a modelagem da viso esttica servios que o sistema dever fornecer aos usurios finais (Booch, 2000). A Figura 5.12 mostra um diagrama de classes com um carrinho de compras, onde h produtos e um item de compra que armazena uma compra. O diagrama contm o nome das classes, os atributos e os mtodos. e os

107

FIGURA 5.12 - Diagrama de classes com o exemplo de um carrinho de compras. Interaes: as interaes do sistema so mostradas atravs dos diagramas de seqncia utilizados na UML para a modelagem dos aspectos dinmicos do sistema, como a interao de objetos que desempenham uma operao ou parte da funcionalidade do sistema. Como os diagramas de interao podem ser utilizados para fazer a modelagem de um determinado fluxo de controle de um caso de uso, o PDW-UML faz uso dos diagramas de seqncia para mostrar perodos durante os quais os objetos desempenham as suas aes. A Figura 5.13 mostra um diagrama de seqncias do caso de uso Gesto de cadastro, considerando aes de um usurio da entidade que: 1) Cadastra um produto, cria um cdigo para este produto, verifica se este produto ou este cdigo j no existe no sistema e obtendo as condies para a realizao retorna uma mensagem de confirmao de realizao do cadastro. 2) Entra com os dados referentes ao produto, armazena estes dados e obtm uma mensagem de que os dados foram armazenados. 108

3) Faz alterao dos dados referentes ao produto informando o cdigo do produto, verifica os dados do produto antes de alterar, confirma a alterao e recebe uma mensagem de confirmao de alterao. 4) Entra com os dados de alterao, armazena os dados no sistema e recebe uma confirmao de atualizao de dados.

FIGURA 5.13 - Diagrama de seqncias do caso de uso Gesto de cadastro. Quando um produto j est cadastrado e disponvel o usurio (internauta) faz uso do sistema realizando compras on-line. A Figura 5.14 mostra um diagrama de seqncias do caso de uso Fazer Compras onde o usurio interage com o sistema fazendo consultas, incluses de produtos ao

109

carrinho de compras, fazendo clculos e demais procedimentos de compra como mostrados a seguir. 1) Um usurio faz uma consulta on-line para que atravs da sua consulta possam ser listadas as categorias de produtos disponveis. O usurio faz uma consulta de acordo com uma seleo e recebe um retorno com a lista dos produtos. 2) Selecionar um produto para incluir em uma classe chamada itemCompra e retorna uma confirmao de armazenamento do produto. 3) Calcular o valor do produto solicitando ao sistema que realize o clculo, em seguida verifica-se o valor obtido e retorna uma mensagem de realizao do clculo. 4) Alterar produtos armazenados no item de compras excluindo produtos e/ou adicionando outros, verificar os produtos atuais e retorna uma mensagem com a lista dos produtos armazenados. 4) Entrar com dados de alterao sobre os produtos como quantidade, regio, opes de entrega etc. e retorna uma mensagem de confirmao da alterao. 5) Concluir as compras conforme os produtos e suas respectivas informaes conforme se encontram no item de compras, realizar o clculo final e retorna a confirmao da compra.

110

FIGURA 5.14 - Diagrama de seqncias do caso de uso Fazer Compras. A utilizao dos diagramas de interao como diagramas de seqncia tem o objetivo de mostrar o aspecto do modelo que enfatiza as interaes de objetos, organizadas em uma seqncia de tempo e de mensagens trocadas. Os diagramas de seqncia permitem uma nfase maior aos quesitos de seqncia, tornando mais fcil de ser visualizada a ordem na qual as coisas acontecem, o que facilita a visualizao das possveis seqncias dos usurios on-line (Booch, 2000).

111

5.1.4.3 - Componentes Atravs do diagrama de componentes, mostra-se a implementao fsica do sistema expondo as relaes entre seus componentes e a organizao de seus mdulos durante a sua execuo. O diagrama de componentes descreve os componentes de software e suas dependncias entre si, representando a estrutura do cdigo gerado. Os componentes so a implementao na arquitetura fsica dos conceitos e da funcionalidade definidos na arquitetura lgica (classes, objetos e seus relacionamentos) (Booch, 2000). A Figura 5.15 mostra um diagrama de componentes com os arquivos que so utilizados para compor o cdigo fonte de uma interface com estrutura dinmica, gerada dinamicamente a partir de uma consulta a um banco de dados.

FIGURA 5.15 - Diagrama de componentes. A modelagem proposta pelo PDW-UML para um sistema de Web sites com interfaces estticas e dinmicas utiliza exemplos bsicos da UML para permitir uma linguagem comum aos desenvolvedores e para auxiliar no processo de implementao, conforme proposto na Seo 5.2. 5.2 - Fase 2: Implementao Nesta fase faz-se a anlise e a seleo dos requisitos obtidos na primeira fase e utilizam-se os requisitos selecionados para compor os contedos que formam as interfaces; elabora-se a 112

documentao; definem-se as estruturas; planejam-se os nveis de URLs; elaboram-se os textos e as imagens; desenvolvem-se os arquivos e diretrios e fazem-se os testes de navegao a partir da mquina servidora. 5.2.1 - Documentao Antes de iniciar um Web site o desenvolvedor precisa de um projeto para saber o que ser feito, como ser feito, que nomes sero atribudos aos arquivos e diretrios para que o sistema de desenvolvimento e administrao possa ser entendido com mais facilidade. Mas como ocorre na maioria dos softwares a documentao faz parte de todas as fases, desde anlise dos requisitos at a concluso do Web site. Na documentao onde se registram as informaes referentes ao Web site. Neste trabalho a documentao est sendo mostrada na segunda fase que a fase onde h necessidades predominantes de registros de informaes. No entanto, a necessidade de registrar informaes comea durante o levantamento de requisitos, e se estende por toda a fase de implementao, design e administrao, conforme a seqncia em que o sistema seja desenvolvido. A seguir so mostrados alguns itens considerados necessrios para o modelo de documentao proposto pelo PDW-UML. 5.2.1.1 - Descrio do Domnio A descrio do domnio uma forma de registro de informaes sobre o que o domnio representa e quais so as divises e subdivises. Para facilitar o levantamento de requisitos necessrio que se conheam os objetivos do domnio, que a empresa, o produto, o servio ou as informaes para os quais o Web site est sendo desenvolvido, quais sero os principais links e suas respectivas interfaces etc. 5.2.1.2 - Informaes Gerais As informaes gerais representam os registros dos recursos utilizados em um sistema e informaes diversas de interesse de pessoas envolvidas direta e indiretamente em um projeto como, por exemplo, recursos de software e hardware necessrios, pessoas envolvidas, cronogramas, oramentos etc.

113

Estas informaes alm de orientar o prprio projeto podem servir de parmetro para outros projetos como, por exemplo, fornecendo dados do nmero de pessoas envolvidas, prazos, custos. A Tabela 5.1 mostra uma relao de informaes gerais referentes a um projeto de Web site. TABELA 5.1 - Informaes gerais de um projeto de Web site. Domnio Verso Pessoas envolvidas Colaboradores Softwares utilizados www.empresa.com.br 1.0, inicio dia/ms/ano verso atual + data Nome do Web master: Nome do administrador: Nome do contato da entidade Colaborador 1: Colaborador 2: Documentao: Pacote Office, Adobe Writer. Codificao: Bloco Notas, php editor. Visualizao: Navegadores Diversos. Edio de imagens: Macromedia Fireworks, Freehand. Animaes: Macromedia Flash. Servidor de pginas dinmicas: IIS, Apache Transferncia de arquivos: SSHSecure ShellClient, Putty, WS-FTP. html , txt, php, gif, jpg, jpeg. HTML, PHP, CSS, JavaScript. Custos estimados por pgina, criaes de imagens, hora tcnica. Previso de incio, proviso de entrega da fase um, previso de entrega da fase dois, previso de entrega da fase trs e previso de entrega do projeto final aps a realizao de todos os testes.

Extenses de arquivos Linguagens Oramentos Cronograma

5.2.1.3 - Convenes Algumas convenes registradas na documentao de um projeto podem colaborar para que a padronizao seja mantida, mesmo quando diferentes profissionais administrem um mesmo domnio. Tanto a parte visual como a codificao, quando seguem algumas convenes tendem a facilitar o trabalho de desenvolvedores e administradores. Alguns exemplos de convenes so mostrados a seguir. Nomenclatura de arquivos: um exemplo de conveno para arquivos e diretrios determinar que os nomes sejam mnemnicos para que os nomes dos arquivos

114

possam ser associados aos seus respectivos contedos e os nomes dos diretrios aos respectivos links. Uma forma de conveno para caracteres que sejam usados, para nomes de arquivos e diretrios, somente letras minsculas, tanto para nome como para extenso, seja arquivo de imagem ou de contedo; que no seja utilizado nenhum tipo de caractere (, acentos, traos, barras) que possam no ser reconhecidos por um host ou que possam levar o usurio a ter dvida quanto ao nome do arquivo ou dependendo da configurao do teclado, no tenha a opo daquele caractere. Abertura de janelas: algumas convenes de abertura de janela que podem ajudar na padronizao das interfaces so mostradas a seguir. - Abertura na prpria janela: instrues para que os links abram na prpria janela (substituindo a pgina atual) quando a pgina chamada fizer parte do mesmo domnio. - Abertura em janela independente: instrues para que os links abram em uma janela independente quando a pgina chamada fizer parte de um outro domnio. - Abertura em pop-up: instrues para que os links sejam abertos em janelas popup quando o contedo a ser exibido no requeira uma nova pgina e nem seja conveniente a abertura na prpria janela. Ex. link para vdeo, imagens de alta resoluo, informaes de datas de eventos e de informaes temporrias. Utilizao de cores: existem vrias formas de se fazer conveno do uso de cores. Estas convenes podem ser apenas informaes ou justificativas que mostrem que as cores que esto sendo usadas no so por acaso, mas por coerncia e familiaridade com motivos como: os motivos originais da empresa; com base no logotipo a partir do qual adotam-se tambm as cores para compor as interfaces e cores extradas da tabela Web safe que traz as 216 cores seguras para a Web. Como as cores usadas nas pginas podero ser necessrias tambm para outros softwares, como editores de imagens e software de animao, por exemplo, registram-se todos os dados referentes cor. O nome da cor utilizado mais para uma referncia ou linguagem comum entre os administradores, pois o que mais se utiliza em arquivos de cdigos o cdigo hexadecimal e em aplicativos grficos o que mais se usa o RGB (red, green and blue). 115

A Tabela 5.2 mostra o nome de algumas cores, a ilustrao, o RGB e o cdigo hexadecimal que compem a Tabela Web safe colors. TABELA 5.2 - Exemplos de referncias de cores. Nome Black (Preto) White (Branco) Blue (Azul) Red (vermelho) Green (verde) Cor RGB R:0 G:0 B:0 R:255 G:255 B:255 R:0 G:0 B:255 R:255 G:0 B:0 R:0 G:255 B:0 Hexadecimal #000000 #FFFFFF #0000FF #FF0000 #00FF00

Exposio de textos - Estilo (Itlico/Negrito/Sublinhado): o sublinhado quando usado em textos que no so links podem confundir o usurio uma vez que o padro dos links. Assim, uma forma de conveno para os links que sejam sempre sublinhados e os demais textos no o sejam. O uso de negrito no meio de um bloco de texto pode confundir o usurio que normalmente encontra ttulos e subttulos em negrito. Uma conveno para o negrito que seja utilizado somente para ttulos e subttulos. Os textos que meream destaque dentro de um bloco podem ter seu destaque atravs de pargrafos identados e aspas. O itlico, mais utilizado para destacar palavras de outro idioma, tambm pode ser uma conveno de destaque de texto, desde que no seja texto muito longo, pois pode dificultar a leitura, dependendo das condies do vdeo do usurio. - Fonte (face e size): como nem todos os sistemas operacionais dispem das mesmas fontes, uma forma de conveno de uso que evita que os textos tenham diferenas muito grandes entre um e outro computador agrupar fontes semelhantes e que sejam as mais usadas na maioria dos sistemas operacionais. Um exemplo de agrupamento so as fontes times, arial, verdana, helvetica, sans-serif que tm uma certa semelhana de estilo e tamanho. No caso de no existir a primeira mencionada no parmetro face da tag <FONT>, o sistema utiliza a que estiver mencionada logo em seguida e assim sucessivamente.

116

Os tamanhos de fonte podem ser especificados em px (pixels), pt (pontos). Em pixel os tamanhos so flexveis e mudam de tamanho conforme a resoluo do monitor do usurio. Os pontos so fixos, independentes da resoluo e aparecem sempre do mesmo tamanho. Assim, uma conveno para o uso de pixels pode fazer com que no haja problemas de um usurio se deparar com fontes muito pequenas nem muito grandes. Os tamanhos mais utilizados so 12px para textos em geral e 14px para ttulos e subttulos. Outros tamanhos so necessidades eventuais como 8px para notas de rodap e 20px (18, 16) para ttulos em forma de banners. - Alinhamentos (direita, esquerda, justificado, centralizado): as formas de alinhamento podem ajudar ou atrapalhar a leitura do usurio. Assim, algumas convenes de alinhamentos podem facilitar a leitura e a compreenso de uma interface como, por exemplo: que no haja alinhamentos direita; que os textos curtos (at duas linhas) sejam alinhados esquerda e quando houver mais de duas linhas que sejam justificados e; somente os ttulos sejam centralizados. - Maisculas/minsculas: o uso de letras maisculas na Web representa que o texto est gritando para chamar a ateno do usurio. Por isso uma forma de conveno que pode sanar este problema fazer uso letras maisculas somente para os ttulos da pgina (no de textos de contedo), a primeira letra aps um ponto e para nomes prprios conforme determina a norma culta do idioma. Utilizao de peso mximo (Kbytes) por interface: o peso ideal de cada interface depende do segmento de um Web site. Se o perfil predominante for de usurios de banda larga, no h necessidade de redues extremas para formar o montante do contedo de cada interface. Quando o contedo de interesse geral, onde a maioria dos usurios utiliza banda estreita (realidade brasileira, segundo o IBOP e-Ratings, e MCT, Juliaz, 2000 e MCT, 2004), primeiro se convenciona um peso mximo por interface para depois elabor-la. Independente do perfil do usurio de um Web site o uso de uma conveno do peso mximo por pgina facilita a navegao, pois fornece um parmetro para o usurio. Se uma pgina tiver um tempo de carregamento muito superior s demais, o usurio pode desistir do acesso considerando que aquele link no dispe de uma interface correspondente.

117

Ordem de disposio dos atributos de uma interface: algumas convenes que padronizem a disposio dos atributos nas interfaces do Web site podem facilitar a leitura e o entendimento global do domnio. Alguns exemplos so: - links: manter a disposio dos links nas interfaces de acordo com as perspectivas de acesso ou importncia de um assunto perante os demais. No havendo perspectivas de acesso nem diferenciao de importncia, uma forma de disposio a ordem alfabtica crescente. Havendo uma conveno, elimina-se a situao em que em uma interface alguns atributos como links, por exemplo, estejam em uma ordem e em outras interfaces em uma ordem diferente. Uma disposio no padronizada pode levar o usurio a ter dvidas se j esteve naquela interface ou no. - Tpicos em geral: para os tpicos, em geral, pode-se convencionar que sejam distribudos de acordo com sua importncia em relao aos demais que compem a mesma interface. No havendo esta distino pode-se utilizar a ordem alfabtica crescente. - Home Page (HP): existem algumas regras que podem melhorar o design, a esttica e a funcionalidade de uma HP. No entanto, a HP representa uma interface nica dentro de um Web site. Quando houver necessidade de convenes estas devem ser especificas para cada projeto em questo, pois o que vale para a HP de um portal pode no valer para a HP de um Web site pequeno (composto de poucos assuntos); o que vale para a HP de um site comercial pode no valer para um site pessoal. Convenes para a HP no sero abordadas neste trabalho.

Organizao das tags: algumas linguagens so sensveis caixa (case sensitive), outras no. O HTML, por exemplo, no sensvel. Para uma melhor organizao e visualizao das tags, pode-se convencionar que as tags HTML e seus respectivos parmetros sejam com letra maiscula e os valores atribudos aos parmetros fiquem entre aspas e com letras minsculas. As demais linguagens seguem suas exigncias de case sensitive. Quando no houver exigncias segue-se a conveno de uso (ex. <IMG SRC=imagem.gif WIDTH=20 HEIGHT=15>).

5.2.1.4 - Modelagem O desenvolvimento de um Web site no um processo de uma nica vez, mas um processo que requer atualizaes freqentes durante toda a permanncia on-line. Em conseqncia 118

disso nem sempre so os mesmos profissionais os responsveis por um domnio durante toda a sua existncia. Por isso a modelagem de um sistema pode auxiliar profissionais j familiarizados com o domnio e novos profissionais que precisam entend-lo para realizar seu trabalho com mais coerncia. Conforme seja a complexidade do Web site, suas necessidades de gerao de pginas dinmicas, interaes com bancos de dados, plug-ins etc, pode-se utilizar um sistema de modelagem como se faz em um sistema de software convencional. Necessidades como estas que fazem com que em alguns aspectos a engenharia de software sejam muitos semelhantes aos da engenharia Web. Embora os fins sejam diferentes, a modelagem de um sistema previsto pela UML, como os casos de uso, os diagramas de classe e diagramas de interao implantao, podem ser usados para ambos os sistemas. 5.2.1.5 - Atualizao e Manuteno Para que as atualizaes e manutenes do Web site sejam feitas necessrio que conste na documentao um sistema que mostre passo a passo como o Web site foi desenvolvido e como fazer alteraes, acrscimos e redues. Isso permite que o administrador, mesmo no familiarizado com o sistema, possa dar seqncia a um trabalho de atualizao e de manuteno. O sistema de ajuda ou de orientao de administrao justamente um dos itens mais complexos de uma documentao, segundo a engenharia Web. Isso porque quando um Web site desenvolvido com uma ferramenta especfica, quase todo o treinamento acaba sendo voltado ao uso da ferramenta, como por exemplo, o Microsoft Front Page ou o Macromedia Dreamweaver, (que so os mais usados atualmente). O problema no uso de ferramentas de desenvolvimento que se mudar a verso o sistema de administrao precisa ser refeito para que os passos, de acordo com a nova verso, possam ser seguidos. Quando se usa codificao manual, o processo de atualizao de treinamento bastante reduzido, pois os cdigos sero os mesmos, as seqncias sero as mesmas, a menos que mude a tecnologia e uma parte da codificao tenha que ser refeita. Um sistema de ajuda para o administrador do Web site envolve desde atividades bsicas como a criao de arquivos e diretrios, como elaboraes de queries para consulta a banco de dados; elaborao de interfaces dinmicas que recebem a sada de consultas de banco de 119

dados; estrutura das interfaces; elaboraes de interfaces e parmetros necessrios a cada tag etc. 5.2.1.6 - Documentao On-line Quando um Web site apresentar situaes em que interfaces sejam geradas dinamicamente atravs da sada de consultas a bancos de dados necessrio que haja uma documentao online tambm, alm da documentao normal do Web site. Conforme sejam os procedimentos do usurio em uma interface de consulta, pode ocorrer que no haja a resposta esperada, por isso necessria uma documentao (um sistema de help) que instrua o usurio sobre como proceder em caso de dvidas ou dificuldades. Uma documentao on-line cabe somente a situaes onde h pginas geradas dinamicamente. Em interfaces permanentes o que se recomenda so mapas do Web site e os canais de comunicao como e-mail, instant messenger ou telefone, mas no uma documentao, uma vez que as interfaces devem apresentar uma organizao que sugira claramente onde os assuntos podem ser encontrados. A documentao on-line faz parte do Web site, tem interfaces prprias e fica no host para que possa ser consultada pelo usurio, ao contrrio do restante da documentao que deve ser mantida somente na mquina cliente, pois interessa somente aos administradores. Uma documentao on-line registrada na documentao do Web site permite que sejam consultados os registros de previses de interfaces geradas dinamicamente, bem com as previses de erro e seus respectivos tratamentos. 5.2.1.7 - Armazenamento de Arquivos Originais Na documentao tambm deve conter informaes de onde e como esto armazenados os arquivos originais do Web site. Onde quer que os originais sejam armazenados, seja em um diretrio dentro do root ou em um outro qualquer, este local deve ser informado na documentao, para que possa ser utilizado conforme necessidades. Um dos problemas de no armazenar os arquivos originais que alguns assuntos que no tenham sido utilizados em um primeiro momento podero ser usados em uma outra oportunidade. O uso das imagens a partir de bitmaps tambm um problema que ocorre quando no se tem o original (normalmente um vetorial que permite que a imagem seja ampliada e reduzida sem que haja perda da qualidade como as extenses .tif, .png etc.) a partir do qual se possam fazer alteraes e compactaes. 120

Independente do espao que uma imagem possa ocupar em uma interface, quando compactada a partir de um original, possvel obter um ndice elevado de compactao com pouca perda de qualidade. 5.2.2 - Anlise e Seleo dos Requisitos de Contedo Como conseqncia do volume e da complexidade do que se determina como parte integrante de um sistema, ocorrem variaes oramentrias e no cronograma de um projeto. Por isso a fase de anlise e seleo de requisitos exige cuidados e precaues para que no haja supresses ou excessos que possam comprometer a coerncia e a objetividade necessrias ao contexto geral do domnio. Diante de alguns contextos h questes que podem ajudar a reduzir desperdcios e elevar a objetividade seja de um tpico especfico, de um assunto composto por vrios tpicos ou de uma interface composta por vrios assuntos. Uma forma de seleo considerar assuntos especficos e analis-los em busca de respostas que possam se adequar s necessidades de um domnio. Com o resultado da seleo dos assuntos passa-se ento, para a anlise de perspectivas de elaborao de links e suas respectivas interfaces. A seguir so mostradas algumas questes que podem servir de orientao para o desenvolvedor quanto utilizao ou no de um assunto e como este pode ser utilizado na composio de uma interface. Sobre um assunto: este assunto importante para o domnio? Precisa ser usado neste momento? suficiente para que se desenvolva uma interface especfica para este assunto? importante o suficiente para que haja um link para este assunto na barra de navegao da home page? importante, mas requer complemento prvio sendo mais adequado que seja chamado em um link em um segundo nvel? Precisa de complementos? Quais os tipos de complementos que existem nos requisitos do domnio? O assunto precisa ser segmentado? Precisa ser resumido? Precisa ser agrupado a outros assuntos? Um assunto que faz parte dos requisitos de um domnio exerce a funo de um papel de realizar (compor) uma interface. Um assunto selecionado poder compor uma interface como um todo; mais de uma interface e/ou far parte de uma interface composta tambm de outros assuntos. Quando um assunto no suficiente para 121

compor uma interface ele pode cumprir seu papel de realizador de forma parcial se tornando um componente de uma outra interface junto a outros assuntos ou descartado, permanecendo armazenado nos requisitos do domnio, sem cumprir seu papel de realizador de interface. Nem sempre todo o contedo referente a um assunto utilizado em uma interface. H situaes em que parte de um assunto utilizado e parte armazenado. Isso acorre quando a parte do assunto que armazenado tem seu sentido de existncia de forma sazonal (datas comemorativas, produtos e servios tpicos de uma estao do ano); os custos de produo de uma interface so muito elevados (vdeos, udios, imagens) ou exige-se um elevado dispndio de tempo para sua realizao (implantao de recursos tecnolgicos sofisticados, trabalhos artsticos que requerem muitas horas de trabalho e servios especializados). Sobre uma interface: h contedo suficiente para que uma interface seja desenvolvida? Com qual outro assunto do domnio que o assunto em questo se relaciona mais diretamente? Poderiam ento, mais de um assunto fazer parte de uma mesma interface? Existe a necessidade de segmentao ou de agrupamentos? Quantas interfaces so necessrias para um mesmo assunto? A partir da anlise e seleo dos assuntos j se pode estabelecer uma hierarquia de navegao e fazer classificaes dos tipos de interface que iro compor o domnio. Os tipos mais comuns de interfaces Web so a home page que a interface inicial do Web site; interfaces com o assunto propriamente dito; interfaces de formulrios; interfaces contextuais (geradas dinamicamente); interfaces interativas; interfaces de resumo que podem ser somente com pequenos blocos de textos ou com links e resumos de assuntos (intermedirios) que sero chamados pelos links e as barras de navegao tambm chamadas de menu, as quais normalmente so parte integrante da home page e dos demais tipos de interface. A Tabela 5.3 mostra um esteretipo e uma breve descrio dos principais tipos de interfaces de Web site proposta pelo PDW-UML.

122

TABELA 5.3 - Esteretipos e descrio de interfaces. Esteretipo Descrio As barras de navegao, tambm chamadas de menu, so interfaces que trazem os links (pontos clicveis) que levam os usurios s pginas escolhidas. As barras de navegao tm as mais diversas formas, podendo ser verticais, horizontais, com formato oval etc. Podem aparecer no topo, na base, direita, esquerda, ao centro, sendo mais comum aparecerem esquerda com incio ao topo. Existem barras de navegao que so a prpria home page a partir da qual ocorre o desdobramento do contedo geral. A home page a interface inicial de um Web site. O termo home page uma metfora do ingls para expressar pgina de casa com a idia literal de sala da casa, onde a Web representa o sistema habitacional, o site representa um endereo especfico dentro do sistema habitacional e a home representa o espao representativo de determinado endereo (URL); o espao onde se recebem visitas, que est sempre bem organizado/arrumado para passar uma boa impresso do restante da casa ainda que nem todos os compartimentos sejam visitados. A home page considerada a porta de entrada ou carto de visitas do Web site. Na prtica, a home page a pgina inicial, mas nem sempre exerce o papel de porta de entrada, pois o usurio pode acessar um domnio a partir de qualquer link. Normalmente a home page aponta (dispe links) para informaes de primeiro nvel (em interfaces de segundo nvel); passa uma noo geral do contexto do domnio deixando cada assunto especfico para sua respectiva interface. As interfaces de resumos exibem pequenos blocos de textos que podero ou no, terem uma seqncia. Esses resumos so feitos baseados em alguns mtodos de reduo como: Agregao: que consiste no agrupamento de vrios assuntos que representam um nico tema em uma interface. Sumarizao: que uma forma de representar assuntos extensos com poucas palavras, normalmente seguido de um link que sugere o assunto completo. Omisso: que uma amostra do incio de um assunto (Continua) 123

Tabela 5.3 - Continuao seguido por um link com frases sugestivas como, por exemplo, mais... seqncia... ler artigo... etc... As interfaces de contedo podem estar em vrios nveis, sendo mais comum em segundo ou terceiro. Primeiro nvel: quando a interface apresenta um contedo especfico logo no primeiro nvel ento se tem o contedo na prpria home page. Isso ocorre normalmente em Web site cujo objetivo dispor ao usurio um nico assunto. Quando h links existentes nas interfaces de primeiro nvel so links para tpicos da prpria pgina ou para interfaces de nveis inferiores. Segundo nvel: as interfaces de segundo nvel aparecem normalmente a partir da home page. H situaes em que uma interface encerra a sua seqncia logo no segundo nvel. H situaes em que necessrio que se desenvolvam mais um nvel para que um assunto possa ser completado (as interfaces de segundo nvel, normalmente trazem os assuntos de primeiro nvel). Terceiro nvel: as interfaces de terceiro nvel vm normalmente como seqncia de interfaces resumos de um segundo nvel. Quando em um segundo nvel tem-se uma interface resumo de sumarizao ou de omisso, conseqentemente existe uma interface de terceiro nvel para dar seqncia ao que foi sugerido na interface anterior. H ainda situaes em que so necessrios mais nveis para a exposio completa de um assunto. Como as interfaces muito extensas no so muito recomendadas, divide-se um assunto formando nveis inferiores mostrando uma parte do assunto e partir de um determinado nmero de linhas insere-se de um link sugerindo continuidade... As interfaces tipo formulrio representam a interface a partir da qual se tm os contedos gerados dinamicamente ou os contedos contextuais que so gerados conforme os dados de uma consulta. A necessidade das interfaces formulrio ocorre quando se tem um volume grande de dados, seja em arquivos texto ou em banco de dados, onde cada usurio poder ter interesse em informaes diferentes, no sendo conveniente manter todos expostos diretamente na interface. (Continua) 124

Tabela 5.3 - Concluso As interfaces contextuais so as respostas obtidas de consultas feitas a partir de interfaces de formulrios, normalmente com interatividades com banco de dados. Chamam-se contextuais, porque por no esto disponveis permanentemente em um Web site. Quando um usurio interage com uma interface tipo formulrio (busca ou envio de dados) elaboram-se as interfaces contextuais que exibem um resultado para aquele contexto ou para aquela interatividade especfica. Se o usurio acessar uma outra interface, aquele contexto deixa de existir. Novas interfaces podero ser geradas quantas vezes forem necessrias, desde que haja uma inteno da gerao da mesma por parte do usurio. As pginas interativas tm uma interface permanente, porm o contedo das mesmas construdo gradativamente a partir da interatividade de usurios com pginas tipo formulrio e de instrues em cdigos como tempo de expirao. Este tipo de interface vista em murais de recado, livros de visitas, oferta/procura de servios onde as mensagens inseridas pelo usurio so acrescidas a uma interfaces j existente. Estas mensagens podero ficar na interface por tempo indeterminado ou podero expirar depois de algum tempo conforme haja instrues no cdigo fonte. Conforme instrues de cdigo novas interfaces podem ser geradas a partir de um nmero especfico de registros, de tempos em tempos, por categoria de assuntos etc. As interfaces interativas diferem-se das contextuais porque as contextuais s existem no perodo de tempo em que o usurio mantm o acesso quela interface. As interfaces interativas existem em um Web site, porm tm seu contedo alterado, conforme instrues de cdigo e interatividades dos usurios.

As interfaces Web so compostas por alguns atributos que so comuns a qualquer tipo de interface como, por exemplo, texto, imagem e link e outros que so especficos de interfaces dinmicas, como o caso dos formulrios. Interfaces do tipo contextual e interativa representam interfaces dinmicas, mas seus atributos, na maioria das vezes so os mesmos que existem nas interfaces estticas. A Figura 5.16 mostra um diagrama com os esteretipos e os atributos que compem as interfaces. 125

FIGURA 5.16 - Esteretipo e atributos que compem as interfaces. H outros tipos de interfaces na Web como as interfaces de udio e de vdeo. Porm estas interfaces so exibidas de forma independente, no fazendo parte da interface do Web site. Por isso no foram previstos esteretipos para estas situaes. Os esteretipos mostrados podem tambm ser compostos de outros atributos, como por exemplo, na home page pode ter um formulrio, na barra de navegao podem conter imagens. Os esteretipos representam os atributos mais freqentes. Na maioria das vezes no h uma resposta precisa para todas as questes que envolvem assuntos e interfaces e nem h questes suficientes para se obter todo tipo de respostas, uma vez que novos assuntos surgem a cada dia e a importncia de um contedo pode ser diferente de tempos em tempos. O uso de questionrios ou chek list na anlise de requisitos serve como forma de orientao para a ordenao dos assuntos em busca de contedos mais coerentes. 5.2.3 - Definio do Tipo de Estrutura Para que as interfaces do Web site tenham uma estrutura padro, o PDW-UML prope um modelo de Estrutura Dinmica (ED) que envolve um servidor de pginas ativas; a organizao de arquivos e diretrios; o uso de linguagens como HTML, JavaScript, CSS e uma linguagem dinmica com recursos de SSI como PHP, por exemplo. Este modelo de 126

estrutura prev os diretrios abertos (que so as portas de acesso ao usurio) criando um diretrio especifico com arquivos-matriz. Os arquivos-matriz formam e padronizam a estrutura das interfaces, independente de como seja elaborada a estrutura lgica do sistema ou a estrutura (design) do contedo (textos, imagens e links) que compe a interface. Os arquivos que trazem as instrues de design de textos ou de contedo (links, textos e imagens) podem ter extenses html, txt, js, css etc. Entretanto os arquivos que tm instrues para chamar outro para que lhe seja parte integrante (instrues de diretivas de include) precisam ter extenso PHP, pois se trata de um recurso que precisa ser interpretado pelo servidor de pginas PHP. A Figura 5.17 mostra a organizao, o script e o design de uma interface desenvolvida com ED.

FIGURA 5.17 - Organizao, script e design de uma interface com ED. Este modelo de estrutura composto por arquivos-matriz, que so arquivos onde no h a exposio direta de contedo, mas a chamada de arquivos com contedo que faro a 127

composio das interfaces. Dessa forma a barra de navegao (ou outro contedo necessrio) fica sempre visvel, porm sem a necessidade de que o script esteja diretamente em todas os arquivos e sim em um nico arquivo que chamado pelos arquivos-matriz. O dinamismo no desenvolvimento pode ser considerado devido s possibilidades de reusabilidade (facilidade de reutilizar, usar novamente) o contedo. O contedo (textos, links e imagens) de cada interface fica incluso em arquivos-matriz onde no h cdigo exposto diretamente, mas as divises feitas com recursos de tabelas e as instrues de incluso de arquivos. Em um nico arquivo so feitas as instrues de design de textos (cores, fontes, tamanhos, alinhamentos etc.), este arquivo incluso no arquivo-menu e o arquivo-menu includo em todos os arquivos-matriz. Com isso reduzem-se as instrues de incluso e permite que os arquivos de contedo tenham o mnimo de instrues de design possvel, de forma que possam ser reutilizados em outros Web sites e com outras tecnologias, apenas com pequenas modificaes. A seguir so mostrados alguns exemplos com os scripts que formam as EDs (diviso com tabelas e diretivas de includs arquivos de design e de contedo). A Figura 5.18 mostra uma diviso horizontal formando duas clulas. Na clula esquerda est includa a barra de navegao e na clula da direita o contedo da home page.

FIGURA 5.18 - Diviso horizontal com duas clulas. O exemplo mais tradicional de pginas Web uma barra de navegao vertical esquerda, com aproximadamente 30% do tamanho da tela, sendo o restante destinado ao contedo propriamente dito. Esta estrutura, segundo estudos ergonmicos, segue o mesmo 128

procedimento de uso do livro e do caderno, o que faz com que o usurio no dispenda de muitos esforos para entender a interface como um todo. Para este exemplo, com o uso de ED, so necessrios trs arquivos: o arquivo com a barra de navegao, o arquivo da pgina principal e o arquivo-matriz que faz a chamada de ambos, resultando em uma nica pgina, a qual chamada pelo usurio. - arquivo 1: default.php - arquivo 2: menu.php - arquivo 3: abertura/inicial.html Independente de quantos links haja na barra de navegao ou como seja o design e o contedo do arquivo que ocupa a clula a direita, j existe uma estrutura definida. Assim como foi feito para a interface inicial, s utilizar o recurso de Salvar Como, para dupliclos e obter a mesma estrutura para as demais interfaces que faam parte do domnio. Quando os arquivos-matriz so duplicados, mantm-se a barra de navegao e troca somente o arquivo (e o diretrio quando o caso) para compor a clula da direita como, por exemplo, abertura/inicial.html, passa a ser funcionarios/funcionarios.html, todo o restante permanece igual, garantindo o padro da estrutura. A Figura 5.19 mostra uma segunda forma de estrutura formada por uma diviso horizontal formando trs clulas. Neste exemplo considera-se que esta interface estar em um segundo nvel e no mais no nvel root como mostrado na Figura 5.18.

FIGURA 5.19 - Diviso horizontal com trs clulas. Como somente a interface inicial mantida no diretrio root, desenvolve-se o primeiro arquivo-matriz em um diretrio de segundo nvel, troca-se o endereo, o nome do diretrio e 129

o nome dos arquivos. A partir da basta novamente utilizar o recurso de Salvar Como, nomear o arquivo e trocar o nome do diretrio e do arquivo que iro compor as clulas. Independente de qual seja a necessidade de divises, uma vez que seja estabelecida, no nvel root, basta copiar para um diretrio de segundo nvel (sejam todos os arquivos-matriz em um mesmo diretrio no segundo nvel ou na raiz de vrios diretrios que tambm estejam no segundo nvel) e trocar apenas o endereo e nome dos arquivos, mantendo o mesmo padro de estrutura. No exemplo da Figura 5.19 aparecem trs arquivos que iro compor o contedo das trs clulas existentes na estrutura do arquivo-matriz que est em um diretrio chamado empresa, no mesmo nvel (segundo nvel) dos diretrios abertura, funcionarios, e externos: - arquivo 1: ../abertura/menu.php - arquivo 2: ../funcionarios/funcionarios.html - arquivo 3: ../externos/links_externos.html Como os quatro diretrios esto no mesmo nvel basta utilizar a instruo ../ (sobe um nvel) e o nome do diretrio (e entra no diretrio). Considerando que todos os arquivosmatriz esto no diretrio empresa, ento o script diz para o sistema: suba um nvel, entre no diretrio x e faa uso do arquivo mencionado. O exemplo da Figura 5.19 uma das maneiras mais simples de organizao de diretrios, pois se houver necessidade de mudana na estrutura, basta entrar em um arquivo, fazer as modificaes e fazer as repeties para os demais, sem a necessidade de abrir outros diretrios ou de ficar procurando diretrios que so acessados pelo usurio como na forma convencional de SSI. Porm o PDW-UML considera tambm algumas inconvenincias em se manter um grande nmero de arquivos no mesmo diretrio, ainda que todos estes arquivos sejam praticamente iguais, como o caso dos arquivos-matriz. Quando o Web site (mais precisamente os grandes portais) tem segmentos que sugerem nomes de arquivos iguais, mantendo todos os arquivos-matriz em um mesmo diretrio anularia a conveno de utilizar nomes de arquivos mnemnicos. Considerando, por exemplo, que um domnio empresa tenha um segmento que se chama produtos, e outro que se chama servios. Estes dois (ou mais) segmentos tm um sub-item que se chama catalogo. Para manter a conveno de usar nomes mnemnicos seriam necessrios dois arquivos-matriz com o mesmo nome. Para situaes como esta o sistema de manter todos os 130

arquivos-matriz em um mesmo diretrio se torna inconveniente, requerendo a segunda forma de organizao prevista pelo PDW-UML, conforme mostrado na Seo 5.2.4.2. Um outro inconveniente de manter todos os arquivo-matriz em apenas um diretrio que os URLs so formados pelo nome do diretrio seguido do nome do arquivo. Quando os endereos de Web site so divulgados por outros meios de comunicao como, jornais, rdio, TV etc. onde o usurio precisa anotar ou memorizar o endereo. Nesse caso, quanto mais curtos forem os URLs, os usurios tm mais facilidade para memorizar, bem como para anotar e digitar posteriormente. A Figura 5.20 mostra uma forma de diviso horizontal e vertical formando trs clulas. Para esta estrutura considera-se o sistema de organizao onde cada arquivo-matriz encontra-se na raiz do diretrio especfico de seu assunto, em um segundo nvel.

FIGURA 5.20 - Diviso horizontal e vertical formando trs clulas. No exemplo da Figura 5.20 o arquivo-matriz, chamado de catalogo.php est na raiz do diretrio produtos, que se encontra em um segundo nvel. Este arquivo tem uma estrutura formada por trs clulas sendo uma horizontal e duas verticais. Estas clulas so compostas pelos seguintes arquivos: - arquivo 1: ../abertura/logo.html - arquivo 2: ../abertura/menu.php - arquivo 3: produtos/catalogo.html A diferena que h neste exemplo que os arquivos-matriz no esto todos em um nico diretrio, mas na raiz do diretrio especfico de cada assunto. Dessa forma o arquivo 1 e o arquivo 2, seguem o mesmo exemplo do modelo anterior e o arquivo 3 tem seu endereo 131

alterado pois o arquivo-matriz o chama a partir de um sub-diretrio existente no diretrio produtos. Independente de qual seja a forma de organizao, os subdiretrios com seus respectivos arquivos existem no sistema, cada um com seu respectivo assunto, a diferena encontra-se em fazer com que os arquivos-matriz (que so os arquivos que os usurios acessam) estejam em um diretrio especfico para os arquivos-matriz, ou na raiz do seu diretrio especfico logo abaixo do root. 5.2.4 - Definio dos Nveis de URLs Alm da ED o PDW-UML visa tambm a reduo dos nveis de URLs e segue um princpio de usabilidade que visa uma pgina para cada interface e um endereo (URL) para cada pgina. A forma de organizao que mantm todos os arquivos-matriz em um mesmo diretrio facilita o trabalho de desenvolvimento e administrao. No entanto, para o usurio, independente de qual seja a forma de organizao os nveis de URLs sero sempre o root ou um nvel abaixo. Os URLs (Uniform Resourse Locator) so a nomenclatura utilizada na Internet para indicar o endereo de um documento. Essa nomenclatura inclui trs componentes: o protocolo, o endereo do servidor e a localizao o do http arquivo. Por exemplo, o no URL o http://www.empresa.com.br/default.php, do arquivo especfico (Chase, 2000). Um dos problemas encontrados nos URLs so os tamanhos gerados devido aos diversos nveis de diretrios criados para organizar o sistema lgico. Por exemplo, um URL proveniente de um terceiro nvel a partir do root, ficaria com um tamanho de nomenclatura semelhante a este: http://www.empresa.com.br/produto/catalogo/feminino/catalogo.php. Se o arquivo estivesse em um nvel abaixo, somar-se-ia ao endereo, mais um nome de diretrio e assim sucessivamente (Baker, 2001). indiscutvel a necessidade da criao de subdiretrios para se obter uma boa organizao lgica. O que o PDW-UML propem que o usurio seja poupado da necessidade de ter que representa protocolo,

www.empresa.com.br representa o servidor que ser acessado e o default.php a localizao

132

trabalhar com URLs longos, fazendo com que os endereos a serem acessados sejam somente do nvel root e de apenas um nvel abaixo onde ficam os arquivos-matriz. Para ilustrar a forma de organizao de arquivos e diretrios prevista pelo PDW-UML e a partir de quais diretrios os arquivo so acessados so mostrados alguns esteretipos na Tabela 5.4. TABELA 5.4 - Esteretipos dos diretrios. Esteretipo do diretrio Diretrio aberto que contm arquivo-matriz. Descrio Os diretrios que contm os arquivos-matriz so os diretrios cujo nome aparece no location do navegador, pois so os diretrios que contm os arquivos que so acessados pelos usurios. Assim, so chamados de diretrios abertos e trazem no esteretipo uma pasta aberta com o distintivo de uma outra pasta aberta com setas apontando para vrias direes. Os diretrios abertos aparecem somente no primeiro e segundo nvel, pois representam os tamanhos dos URLs. Diretrio fechado que contm sub-diretrios e arquivos que compem os arquivos-matriz. Os diretrios fechados que contm sub-diretrios so representados por uma pasta aberta, indicando que h sub-nveis ou sub-diretrios. Os diretrios fechados podem ter quantos nveis forem necessrios para facilitar a organizao, pois no representam URLs.

Os diretrios fechados que no contm sub-nveis ou subDiretrio fechado (de ltimo nvel) que contm diretrios so representados atravs de uma pasta fechada arquivos, mas no contm indicando que no h sub-diretrios a partir dele. subdiretrios.

5.2.4.1 - URLs a Partir de um nico Diretrio O acesso a partir do diretrio root representa o acesso direto ao domnio como, por exemplo www.empresa.com.br. Quando se acessam arquivos que estejam em subdiretrios esses so seguidos de uma barra, o nome do diretrio, outra barra e o nome do arquivo (para o acesso a um arquivo que esteja em um diretrio de segundo nvel). Considerando que todos os arquivos-matriz esto em um nico diretrio chamado empresa, independente de em quantos nveis abaixo estejam os contedos que formam a interface (arquivo-matriz) os

133

URLs tero o nome do domnio, uma barra, o nome do diretrio com os arquivos-matriz, outra barra seguida do nome do arquivo-matriz. A Figura 5.21 mostra a forma de organizao onde os arquivos-matriz encontram-se no diretrio root e em um sub-diretrio especfico chamado empresa. Os URLs previstos encontram-se do lado direito da Figura.

134

FIGURA 5.21 - Arquivos-matriz em um nico diretrio. 135

Conforme mostrado na Figura 5.21, o usurio ter acesso somente a partir de dois diretrios, o root e o empresa os quais contm os arquivos-matriz que formam as estruturas padres criadas atravs do uso de tabelas para fazer as divises e do uso de SSI para fazer a incluso dos arquivos que esto nos demais diretrios. Independente de onde estejam os arquivos com os contedos que compem os arquivosmatriz, os URLs so representados pelo nome do domnio, o nome do diretrio e o nome do arquivo, sucessivamente, sempre no primeiro ou segundo nvel. 5.2.4.2 - URLs a Partir do Diretrio Respectivo de cada Assunto Conforme mostrado na Seo 5.2.4 quando h necessidade da reincidncia de nomes para os arquivos-matriz, mant-los todos em um nico diretrio impossibilita esta realizao. Para manter o nvel dos URLs reduzidos ao segundo nvel, o PDW-UML prev uma segunda forma de organizao onde os arquivos-matriz ficam na raiz de seus subdiretrios, juntamente com os arquivos de contedo e demais subdiretrios. A Figura 5.22 mostra a forma de organizao onde os arquivos-matriz encontram-se na raiz de seus respectivos diretrios, em um segundo nvel a partir do diretrio root.

136

FIGURA 5.22 - Arquivos-matriz em diversos diretrios. 137

Alm do exemplo mostrado na Figura 5.22 possvel reduzir ainda mais o tamanho dos URLs para um dos arquivos-matriz de cada diretrio. Os arquivos com nome index ou default, seguido de sua respectiva extenso (para este exemplo, default.php) so os arquivos que o servidor Web procura automaticamente quando um usurio digita o nome de um domnio ou o nome de um domnio seguido de uma barra e o nome do diretrio. Isso significa que o servidor procura na raiz de cada diretrio um arquivo com nome padro como index e default, por isso quando estes esto na raiz de um diretrio (independente do nvel) no precisam ser mencionados. Como na maioria das situaes h mais de um arquivo-matriz pertencente a um mesmo diretrio, esse recurso representa mais uma alternativa para divulgao de nomes de URLs ainda mais curtos. Para divulgao dos URLs onde h mais de uma interface em um mesmo diretrio, ainda necessrio a informao do URL completo. A Figura 5.23 mostra a forma de organizao onde os arquivos-matriz encontram-se na raiz de seus respectivos diretrios, porm um dos arquivos-matriz tem seu nome (mnemnico) substitudo pelo nome default, seguido de um ponto e sua extenso (default.php).

138

FIGURA 5.23 - Arquivos-matriz e arquivos-default em diversos diretrios. 139

Para os trs exemplos de organizao previstos a estrutura a mesma, os nveis de URLs so os mesmos (primeiro e segundo). A escolha feita por um administrador ocorre a partir da identificao das necessidades de cada projeto como, por exemplo, o volume de arquivos, os nomes que podem ser mnemnicos para cada link e sua respectiva interface e meios de comunicao utilizados para a divulgao dos URLs. O primeiro exemplo o que simplifica mais o trabalho do administrador, pois no caso de mudana na estrutura, no h necessidade de percorrer vrios diretrios. 5.2.5 - Composio das Interfaces O PDW-UML considera algumas incluses bsicas para a composio das interfaces. No se pode afirmar que todos os Web sites tero as mesmas necessidades, por isso o PDW-UML descreve interfaces estticas e dinmicas e de acordo com esta classificao mostra os designs mais freqentes que uma barra de navegao e um contedo referente a um link. Existem situaes em que o contedo se divide em vrias interfaces havendo a necessidade de uma sub-barra de navegao, nesse caso pode-se utilizar o mesmo exemplo mostrado para a barra de navegao das interfaces de primeiro e segundo nvel, porm fazendo uma incluso do sub-menu no arquivo de contedo. O restante segue o padro das interfaces do modelo. A Figura 5.24 mostra as bases de incluso para composio dos arquivos-matriz, onde h um arquivo-matriz que traz em seu cabealho as meta tags do sistema, as divises e suas respectivas instrues de include, formando as estruturas propriamente ditas.

FIGURA 5.24 - Base de incluso para composio dos arquivos-matriz. A lgica existente na Figura 5.24 que: 140

se o arquivo com o menu contm o arquivo de design; e os arquivos Contedo e Menu esto inclusos no arquivo-matriz; ento os arquivos Menu e Contedo assumem as instrues de design existentes no arquivo design. O PDW-UML utiliza CSS para caracterizar o design das interfaces (principalmente o design de textos), porm considera que nem todos os navegadores reconhecem todas as instrues de CSS. Quando h em CSS uma instruo que no reconhecida por todos as navegadores, o PDW-UML substitui a instruo CSS por uma instruo HTML como, por exemplo, cores de fundo. Essa instruo inserida diretamente na tag <BODY> dos arquivos Menus que se encontram repetidos no primeiro e segundo nvel. Isso faz com que em caso de modificaes o dinamismo e a reduo de trabalho so mantidos, pois as modificaes so feitas em apenas dois arquivos. 5.2.5.1 - Composio dos Arquivos-matriz Os arquivos-matriz so compostos basicamente por meta tags, divises feitas com tabelas e diretivas de include, conforme mostra a Figura 5.25 (arquivo default.php).
<HTML><BODY> <HEAD> <META http-equiv="Keywords" content="estrutura dinmica para interfaces de web sites"> <META name="nome do domnio" content="contedo da pgina"> <META content="text/html; charset=iso-8859-1" http-equiv=Content-Type> <!--fim instrues meta tags--> </HEAD> <TABLE BORDER=0 WIDTH=100% HEIGHT=0> <TR> <TD WIDTH=30%> <?INCLUDE (menu.php);?> </TD> <TD WIDTH=70%> <?INCLUDE (abertura/inicial.html);?> </TD></TR> </TABLE> </BODY> </HTML>

FIGURA 5.25 - Arquivo-matriz com meta tags no cabealho. Meta tags: ao determinar os arquivos que sero acessados pelo usurio (arquivosmatriz), j se sabe automaticamente onde inserir as meta tags, com instrues de acordo com o contedo de cada pgina. Sistemas de buscas de pginas Web, como o Google, por exemplo, fazem uma varredura procurando em meta tags as palavras-chave digitadas pelo usurio. Com as meta tags inseridas nos arquivos-matriz, os arquivos que contm as palavras 141

buscadas sero trazidas junto com a barra de navegao e as informaes gerais do Web site, pois os arquivos-matriz, so compostos de design, barra de navegao e o contedo especfico de cada interface. Divises: independente de como e quantas sejam as divises existentes nas interfaces com o contedo, a base da estrutura do Web site segue o mesmo padro, pois todos os arquivos-matriz tm as mesmas divises. Diretivas de include: as diretivas de include juntamente com as divises feitas com tabelas que formam a estrutura do Web site, dentro das quais existem os contedos.

5.2.5.2 - Composio dos Arquivos de Design Os arquivos de design so compostos por instrues de CSS que determinam quais so os estilos, tamanhos e cores de textos; caractersticas de tabelas; o cone que aparece no location do navegador; as cores que caracterizam a barra de scroll; a cor de fundo do body e das tabelas etc. No entanto, CSS uma linguagem client side, que depende dos recursos do navegador do cliente para que suas instrues sejam executadas. Alguns recursos como, por exemplo, cor de fundo e caractersticas de tabelas no so reconhecidas por todos os navegadores. Assim, o PDW-UML utiliza HTML para instrues que se desenvolvidas com CSS podem comprometer o design e o entendimento do Web site. Um exemplo disso o uso de cor de fundo das pginas que feito com HTML e inserido nos arquivos-menus. Como os arquivos-menus tm duas incidncias, em caso de modificaes necessrio que se alterem os dois arquivos (no apenas um como se estivesse no arquivo de design feito com CSS e nem em todos como se fosse feito sem o uso da incluso do arquivo-menu nos arquivosmatriz). A Figura 5.26 mostra um script com as instrues de design em CSS, como caractersticas de cone, barras de scroll, efeitos em links para os estados normal, sobre, pressionado e visitado e instrues de fonte para tamanho, cor e estilo.

142

/* muda o cone */ <LINK REL="shortcut icon" HREF="http://www.empresa.com.br/imagens/imagem.ico"> <STYLE type="text/css"> /*inicio body e scroll */ BODY { scrollbar-3d-light-color:#000000; scrollbar-arrow-color:#FFFFFF; scrollbar-base-color:#FF6699; scrollbar-dark-shadow-color:#000000; scrollbar-face-color:#FF6699; scrollbar-highlight-color:#FFFFFF; scrollbar-shadow-color:#FF6699; } /*fim barra scroll */ /* inicio links */ A:hover {color:#000000; font-family:times, arial, Verdana, helvetica, sans-serif; font-size:14px; background-color:#EAB4C4;} A:link {color:#000000; font-family:times, arial, Verdana, helvetica, sans-serif; font-size:14px;} A:visited {color:#000000; font-family:times, arial, Verdana, helvetica, sans-serif; font-size:14px;} A:active {color:#FFFFFF; font-family:times, arial, Verdana, helvetica, sans-serif; font-size:14px;} /* fim links */ /* inicio cor preta, exemplo normal e negrito, tamanho 14*/ .black14 { font-family:times, arial, Verdana, helvetica, sans-serif; font-size:14px; font-weight:normal; color:#000000; } .black14b { font-family:times, arial, Verdana, helvetica, sans-serif; font-size:14px; font-weight:bold; color:#000000; } </STYLE>

FIGURA 5.26 - Script com instrues de design em CSS. 5.2.5.3 - Composio dos Arquivos-menu O PDW-UML considera a necessidade de duas incidncias de um arquivo-menu ou arquivo com a barra de navegao: um no nvel root e outro em um segundo nvel. A seguir so mostrados exemplos de como o sistema interpreta os endereos lgicos em ambos os nveis.

143

No nvel root: na Figura 5.27, na linha 2, h uma instruo de include que instrui o sistema para sair do diretrio atual, entrar no diretrio abertura e executar o arquivo interface.txt. A mesma instruo vale para a incluso das imagens nos links. Na linha 7 a instruo para que seja executado o arquivo default.php. Na linha 11 h instruo para sair do diretrio atual, entrar no diretrio empresa e executar o arquivo-matriz produtos.php. Esta mesma instruo vale para os demais links, uma vez que os demais arquivos-matriz esto no diretrio empresa. Para o caso de manter cada arquivo-matriz em seu respectivo diretrio, a instruo seria ../diretorio/arquivo-matriz.php, ou seja, sair do diretrio atual, entrar em um outro diretrio no mesmo nvel e executar o arquivo-matriz.php. A Figura 5.27 mostra os endereos lgicos (internos) de um arquivo-menu que fica do diretrio root.

1 2 3 4 5 6 7 9 10 11 12

<HEAD> <? INCLUDE="abertura/interface.txt";?> </HEAD> <BODY BGCOLOR="#FFFFFF"> <TABLE BORDER="0" WIDTH="100%" HEIGHT="0%" CELLSPACING="0" CELLPADDING="0"><TR><TD NOWRAP> <TR><TD NOWRAP> <A HREF="default.php" TARGET="_top"><IMG SRC="imagens/imagem1.gif" BORDER="0" WIDTH="20" HEIGHT="17" ALIGN="top">Pgina Inicial</A> </TD></TR> <TR><TD NOWRAP> <A HREF="empresa/produtos.php" TARGET="_top"><IMG SRC="imagens/imagem1.gif" BORDER="0" WIDTH="20" HEIGHT="17" ALIGN="top">Produtos</A> </TD></TR><TABLE></BODY>

FIGURA 5.27 - Arquivo-menu no nvel root. No segundo nvel: na Figura 5.27 pode-se observar logo na segunda linha um endereo lgico com a instruo ../abertura/interface.txt que significa dizer para o sistema: saia do diretrio atual, suba um nvel, entre no diretrio abertura e execute o arquivo interface.txt. A mesma instruo vale para as imagens que compem os links. Na linha 7 para sair do diretrio atual, subir um nvel e 144

executar o arquivo default.php. Na linha 11 a instruo para que se execute o arquivo produtos.php. Essa mesma instruo ser para os demais links uma vez que o arquivo-menu est no mesmo diretrio que os arquivos-matriz de segundo nvel. Se fosse utilizada a opo de manter os arquivos-matriz na raiz de seus respectivos diretrios o arquivo-menu poderia ficar no diretrio que tem os arquivos de abertura, por exemplo. Nesse caso a instruo seria ../diretorio/arquivomatriz.php. A Figura 5.28 mostra um arquivo-menu em um sub diretrio de segundo nvel.
1 2 3 4 5 6 7 9 10 11 12 <HEAD>
<? INCLUDE="../abertura/interface.txt";?>

</HEAD> <BODY BGCOLOR="#FFFFFF"> <TABLE BORDER="0" WIDTH="100%" HEIGHT="0%" CELLSPACING="0" CELLPADDING="0"><TR><TD NOWRAP> <TR><TD NOWRAP>
<A HREF="../default.php" TARGET="_top"><IMG SRC="../imagens/imagem1.gif" BORDER="0" WIDTH="20" HEIGHT="17" ALIGN="top">Pgina Inicial</A>

</TD></TR> <TR><TD NOWRAP>

<A HREF="produtos.php" TARGET="_top"><IMG SRC="../imagens/imagem1.gif" BORDER="0" WIDTH="20" HEIGHT="17" ALIGN="top">Produtos</A>

</TD></TR><TABLE></BODY>

FIGURA 5.28 - Arquivo-menu em um subdiretrio. Conforme mostrado nesta Seo, os endereos dos links so feitos conforme a localizao dos arquivos-matriz. Como o endereo do nvel root para os subdiretrios diferente do endereo dos sub diretrios para o nvel root (diretorio/arquivo diferente de ../diretorio/arquivo), a soluo encontrada pelo PDW-UML foi manter um arquivo-menu no nvel root e outro em um subdiretrio, logo abaixo do root. 5.2.5.4 - Composio dos Arquivos de Contedo O contedo de cada interface normalmente composto de textos, imagens e links; somente textos, somente imagens etc. podendo ser feito em softwares como o Macromedia Flash,

145

Dreamweaver, Front Page, Editor VI, ou outro editor da preferncia do desenvolvedor. O que precisa ser feito conforme instrues do PDW-UML so os endereos dos links. Arquivos-matriz em um nico diretrio: (conforme mostrado na figura 5.23) quando se est em uma interface em um terceiro nvel (independente do endereo deste arquivo), para voltar para o nvel anterior basta apontar o endereo do arquivo-matriz que representa a interface anterior como, por exemplo, <A HREF=anterior.php TARGET=top>Pgina Anterior</A>. O mesmo exemplo vale para quando se deseja ir de um segundo nvel para um terceiro, quarto, quinto etc. O sistema entende que um arquivo-matriz chama outro arquivo-matriz, por isso os links so sempre para o arquivo-matriz que tem a interface com o contedo em questo. Portanto no arquivo-matriz se faz o include do arquivo de contedo e no arquivo de contedo se faz chamada ao arquivo-matriz, ou seja, os endereos de links so de uma interface para outra interface e o PDW-UML considera que cada interface representada por um arquivo-matriz. Quando, de um arquivo de contedo (independente de qual seja o nvel onde este se encontre), se deseja fazer um link para o arquivo default.php que o arquivomatriz que est no diretrio root, basta instrues para sair do diretrio do arquivomatriz que representa o contedo em questo e apontar um nvel acima como, por exemplo, <A HREF=../default.php TARGET=top>Pgina Inicial</A>. Arquivos-matriz em vrios diretrios: (conforme mostrado na figura 5.24) quando os arquivos-matriz ficam na raiz de seus respectivos diretrios, para voltar ao nvel root utiliza-se o mesmo endereo que se usa quando os arquivos-matriz esto em apenas um diretrio como, por exemplo, <A HREF=../default.php TARGET=top>Pgina Inicial</A>. O que muda que ao invs de o endereo dos links serem de um arquivo-matriz para outro arquivo-matriz o endereo apontado para um nvel acima e em seguida para a entrada no respectivo diretrio como, por exemplo, <A HREF=../diretorio/anterior.php TARGET=top>Pgina Anterior</A>. Para ambos os tipos de organizao, quando se tm arquivos para download ou arquivos com a extenso pdf, por exemplo, deve ser utilizado o endereo real onde se encontra o arquivo, considerando a sada a partir do endereo do arquivo-matriz e 146

o parmetro TARGET recebe valor = _blank. Mesmo que o arquivo para download ou pdf esteja no mesmo diretrio que o arquivo de contedo, o sistema entende o endereo do arquivo-matriz, o que significa que o endereo no ser apenas a referncia ao arquivo que est no mesmo diretrio, mas a partir do arquivo-matriz para o endereo do arquivo para download como, por exemplo, <A HREF=../downloads/arquivo.zip TARGET=_blank>Arquivodownload.zip</A>.Ou HREF=../downloads/arquivo .pdf TARGET=_blank>Arquivo .pdf</A> Para evitar URLs longas o PDW-UML considera a existncia de um diretrio, no segundo nvel, especfico para arquivos .pdf e arquivos para download. Interfaces contextuais: quando se trabalha com interfaces dinmicas resultantes de consultas a bancos de dados, uma consulta gera uma interface e partir dessa interface outras so geradas, conforme necessidade de uma operao. Para essas situaes o sistema de link feito de uma interface para suas interfaces sucessoras, com o endereo de um arquivo-matriz para outro. Assim como, para as interfaces permanentes, elabora-se um arquivo-matriz e um arquivo com um contedo especfico que no caso das interfaces contextuais, normalmente traz instrues permanentes e instrues para recepo do resultado da consulta realizada. Uma seqncia de interfaces ocorre a partir de um link que corresponda a uma interface com um formulrio, como ocorre em interfaces de insero de dados; interface que armazena dados temporrios; interface de envio de dados para o banco de dados e; interface informativa do status da operao. - Interface de insero de dados: normalmente as interfaces contextuais so geradas a partir de uma interface que traz um formulrio a partir do qual o usurio consulta, envia ou recebe informaes. Para fazer um link para a interface seguinte informa-se o endereo do arquivo-matriz correspondente interface seguinte como, por exemplo, <FORM ACTION="arquivo-matriz1.php" METHOD="post"> (na maioria dos casos o mtodo post utilizado para envio de dados e o mtodo get para consultas). O resultado da interao ser mostrado na interface seguinte, juntamente com o design e a barra de navegao que esto inseridos em todos os arquivos-matriz. <A

147

- Interface que armazena dados temporrios: os dados temporrios podem ser itens que so depositados em carrinhos de compra ou dados que so armazenados para simples correo antes que sejam gravados em um banco de dados. Se os arquivos-matriz estiverem em endereos diferentes, menciona-se o endereo e se estiverem no mesmo diretrio basta novamente que o valor do parmetro action seja o nome do arquivo-matriz como, por exemplo, <FORM ACTION="arquivomatriz2.php" METHOD="post">. - Interface de envio de dados para o banco de dados: uma interface com instrues para envio de dados pode ser a interface onde aparece um primeiro formulrio; a segunda aps o formulrio; a primeira, segunda, terceira etc. aps uma interface que armazena dados temporrios. O link se faz da mesma forma que para as interfaces anteriores apontando o arquivo-matriz da interface seqente para o parmetro action do formulrio: <FORM ACTION="arquivo-matriz3.php" METHOD="post">. - Interface informativa do status da operao: normalmente aps a concluso de uma operao ou aps o envio de dados mostra-se uma interface trazendo informaes do resultado da operao realizada. No caso de pesquisa e consultas em geral, esta interface aparece logo aps a pgina com o formulrio inicial com o resultado da consulta. Quando representa o envio de dados a um banco de dados mostra-se a operao foi concluda com sucesso ou no. Alm da mensagem informativa, normalmente essa interface traz um ou vrios links como opes para que o usurio possa escolher suas prximas operaes.

5.2.6 - Testes do Sistema Navegacional Mesmo que cada link tenha sido testado logo aps sua implementao na mquina cliente, antes de iniciar a fase de design das interfaces considera-se a necessidade de um teste navegacional do sistema como um todo, a partir da mquina servidora. A engenharia Web aponta os erros de formulao dos links como os maiores problemas de navegao dos sistemas Web. Como o PDW-UML considera a existncia da incidncia da barra de navegao em dois nveis do sistema lgico, ento os testes precisam ser feitos em todos os links a partir do 148

diretrio root e em todos os links a partir de uma interface qualquer que represente o segundo nvel. Os demais testes precisam ser feitos a partir do acesso a todas as interfaces que tenham links, quer para URLs internos ou externos. Quando h interfaces dinmicas no sistema fazem-se os testes a partir de consultas e envio de dados, testes de uso da documentao on-line e estudos de tratamentos de erros, se detectados.

5.3 - Fase 3: Design das Interfaces As duas fases anteriores so feitas atravs dos recursos da UML, da Engenharia de Software (ES) e da Engenharia Web (EW). Nesta fase inicia-se um processo onde as solues no so encontradas na UML ou na engenharia, porque cada Web site requer uma soluo diferente. As duas fases anteriores j representam a parte funcional do Web site, com o uso da UML e da engenharia para fazer modelagem e a implementao. A engenharia j cumpriu seu papel ao fornecer estudos formalizados para levantar, organizar e selecionar requisitos; para modelar o sistema; para fazer testes funcionais sob diversas perspectivas; para um desenvolvimento do sistema que permita usabilidade para o usurio e reusabilidade para a equipe; para organizar os arquivos e diretrios de forma que os URLs sejam reduzidos sem comprometer a organizao dos assuntos que pertencem ao domnio na mquina local. Enfim, o uso de recursos formalizados para o desenvolvimento do projeto, para a implementao do Web site e para os testes realizados, pode ser mostrado como um trabalho baseado na engenharia. A fase de design das interfaces proposta como uma fase artstica que busca aprimorar o que foi desenvolvido nas fases anteriores, propondo um tempo e um espao dentro de um processo para que haja a realizao artstica e criativa. A proposta para a fase de design uma forma de cultura que envolve esttica, arte e tica como base para um estilo de design. A arte na Web pode ser vista e entendida como o domnio que tem um Web designer com as ferramentas grficas utilizadas para a Web e no senso (cultura) tico e esttico que utiliza para compor um design final. Assim, a diferena entre a arte e a engenharia utilizadas em Web sites pode ser representada pela finalidade e pela formalizao. A finalidade da engenharia projetar e implementar sistemas funcionais, formalizados e padronizados. A arte 149

tem como finalidade tratar, personalizar e melhorar a esttica gerada pela engenharia de forma que cada Web site possa ter uma esttica nica, de acordo com o objetivo da cada domnio. Assim, no se prope um padro de design, pois poderia representar uma falta de reconhecimento da capacidade de criao dos profissionais da Web e da necessidade mercadolgica de apresentar os diferenciais competitivos que um design diferenciado pode oferecer. Ainda h a questo que puramente de gosto, maturidade visual etc. que leva a questionar qual seria o perfil dos Web designers que fariam uso de um padro de design proposto, seja em um mprocesso de desenvolvimento, template, prottipo etc. O design no atrapalha o bom funcionamento. O que pode atrapalhar a forma inadequada do uso das tecnologias como, por exemplo, o uso inadequado de um software de compactao de imagens pode deix-las pesada demais e retardar o tempo de carregamento. No a arte e, muito menos a criatividade (utilizada para que uma imagem expresse um objetivo, nas combinaes de cores, tamanhos e alinhamentos) que interferem no bom funcionamento. O usurio entende a arte e o design. O usurio normalmente no entende e no tem que entender a engenharia usada para o desenvolvimento. Ento o que se prope nesta fase que se disponha ao usurio interfaces com designs artsticos (quando necessrio), criativos, mas orientados ao objetivo (assunto) da interface e ao domnio como um todo. E, isso no atrapalha o funcionamento navegacional e nem retarda o tempo de carregamento. Algumas questes so apresentadas como base de uma cultura que pode ajudar um Web designer a planejar o design de interfaces e a fazer escolhas em caso de dvidas entre um design e outro; entre uma estrutura e outra; entre uma tecnologia e outra etc. Para elaborar a interface humana, alm do conhecimento da engenharia, consideram-se tambm os benefcios que o conhecimento de algumas cincias humanas podem proporcionar. A psicologia e a filosofia tm colaborado com algumas cincias exatas como, por exemplo, com a robtica e com a ciberntica, para auxiliar no desenvolvimento de sistemas que facilitam as atividades humanas atravs da inteligncia artificial (Roldo, 2000). A partir dessas observaes que se prope, para o desenvolvimento de design de interfaces Web, o conhecimento de alguns aspectos da psicologia, mais precisamente da psicologia cognitiva e

150

da filosofia, mais precisamente da arte, da tica e da esttica. Questes mercadolgicas no sero abordadas neste trabalho. Esta fase requer uma anlise do contedo que est disponvel ao usurio para buscar uma harmonia entre os atributos; onde se analisa como ficar a distribuio dos links na home page e nas demais interfaces; o que deve e o que no deve aparecer na home page; o espao que cada imagem ocupar em uma interface, independente de seu peso; as frases e palavras atribudas aos links, independente dos nomes dos arquivos; em que parte de um texto deve-se inserir um link para um outro assunto ou complemento do assunto em questo; qual o peso mximo para cada imagem uma vez que tenha sido definido seu tamanho, (largura x altura); o espao reservado aos atributos que ficam fixos na interface e ao contedo que se renova a cada link; o design dos textos; os alinhamentos dos textos em relao s imagens e em relao aos ttulos e sub-ttulos. Desenvolver Web sites como processos artsticos diferente de desenvolver com arte e criatividade interfaces que tenham sido desenvolvidas como um processo de engenharia e que no seu devido tempo e espao receberam um tratamento diferenciado. O conceito de arte para a Web vai alm da arte utpica e engloba a arte objetiva, que representa o uso da educao artstica expressa atravs do uso de ferramentas para a Web e do senso tico e esttico. A abordagem sobre a tica no visa fazer julgamentos ou buscar a culpas ou intencionalidade de bons e maus designers, mas apontada como uma sugesto de estudo ou conhecimento de um assunto que pode ajudar em uma tomada de deciso. Da mesma forma conhecimentos sobre a esttica so abordados como um posicionamento do usurio diante de uma esttica; das impresses causadas por uma esttica, principalmente quando uma esttica revelada no conceito de belo, conforme o que o belo pode representar a cada usurio. A engenharia, mais precisamente a Engenharia Web, cumpre seu papel em um processo de desenvolvimento ao oferecer respaldo a engenheiros e demais profissionais da Web. O papel da engenharia oferecer recursos e solues baseados em experimentos que tenham sido aprovados e mostrados atravs de formalidades que podem ser conceituais, prticas, descritivas e/ou ilustrativas. Um sistema Web pode ser desenvolvido apenas com base em princpios da engenharia, mas isso tornaria a Web menos atraente a alguns perfis de usurios e a alguns segmentos mercadolgicos. Conforme ocorre na rea das cincias humanas, biolgicas etc., na rea das 151

exatas, as cincias tambm podem se complementar para proporcionar aos usurios dos produtos e servios em questo, uma qualidade maior. Normalmente as pessoas que esto envolvidas em um projeto tm um certo domnio de suas atividades e sabem o que, para que e para quem est sendo feito, mas em sistemas Web os usurios so os mais diversos possveis, com os mais diversos nveis de conhecimentos e habilidades para com o uso de computadores. O PDW-UML considera que no cabe somente a engenharia se encarregar de levar ao usurio a melhor forma de entendimento, atrativos mercadolgicos, designs atraentes e demais questes que possam atrair a ateno do usurio e lhe proporcionar o lazer e as informaes procuradas. Existem vrias maneiras de expressar uma mesma idia, de narrar um mesmo fato, bem como de descrever um produto ou um servio. H escritores que utilizam pginas e mais pginas para expressar uma idia bsica (isso se v principalmente em obras literrias), mas na Web essa forma de expresso pode no ser a mais adequada devido ao tempo de carregamento de uma pgina; da pacincia do leitor em ficar lendo na tela, clicando em links ou usando a barra de rolagem; das tcnicas de redao para a Web, que so diferentes das tcnicas utilizadas para recursos onde o volume de pginas no representa problemas. O PDW-UML, na fase de design das interfaces, considera combinaes de expresses em textos e imagens, cores, alinhamentos (sons e vdeos, se necessrios) como uma sada para expresses que se expostas sempre na forma escrita ou na forma ilustrativa poderiam parecer incompletas; se expostas sempre na forma original, conforme o padro do navegador, no ofereceriam espao para personalizaes. A maneira como estas combinaes de textos, imagens, links e formulrios podem ser expostos o trabalho que se realiza nesta terceira fase. A seguir so mostrados alguns conceitos filosficos e tecnolgicos utilizados como base para a proposta da terceira fase. 5.3.1 - Arte e Tcnica como Princpios de Design O design representa literalmente o desenho que apresentado em uma interface. Este desenho desenvolvido atravs do uso de tcnicas em ferramentas de desenvolvimento e tratamento de imagens e tcnicas de uso de ferramentas de design para interfaces Web. No entanto, com o uso das mesmas tcnicas, o resultado poder ser diferente dependendo da 152

maturidade e da educao artstica de cada profissional. O resultado obtido atravs de tcnicas de uso de ferramentas representa a arte utilizada na Web (Domingues, 2003). O desenvolvimento de Web sites requer conhecimentos slidos de tcnicas de desenvolvimento, bem como de estratgias para obter melhores resultados das tecnologias utilizadas. No entanto, se na fase de design das interfaces, todos os profissionais da Web seguissem os mesmos critrios e tivessem a mesma viso, a tendncia seria anular ou deixar de desenvolver a inovao, a criatividade e a competitividade entre profissionais ao oferecer servios diferenciados. Dentro da filosofia, h situaes em que a tica, a esttica e a arte so abordadas de forma muito semelhante, pois ambas estudam formas de entender e desenvolver atividades que proporcionem formas de compreenso e satisfao a expectadores e usurios (Pauli, 1997). A tica representa uma busca constante de se fazer melhor aquilo que se faz; a esttica como uma forma de afirmao e concretizao de pensamentos e percepes subjetivas e a arte como uma educao artstica abrangente que engloba a tica e a esttica. Para a fase de design das interfaces essas abordagens so feitas com o objetivo de buscar levar at o usurio o melhor design possvel dentro dos limites de um projeto, independente se os resultados sejam provenientes de tcnicas, da arte, da esttica ou da tica ou de uma maturidade proveniente destas e de outras fontes. A seguir so mostrados maiores detalhes sobre a arte, a esttica, a tica e algumas formas de uso na Web. 5.3.1.1 - A arte na Web O conceito de arte divergente, subjetivo e varia de acordo com a cultura a ser analisada, com o perodo histrico ou at mesmo com um trabalho em questo. A arte na Web pode ser vista como a arte da leveza obtida do resultado de tcnicas de uso de ferramentas grficas e de design. No incio de todo o processo artstico ou cientfico existe desconhecimento e curiosidade bastante para se realizar trabalhos inovadores e viveis, que ajudem o usurio a entender alm da escrita pura e tcnica. A falta de conhecimento de educao artstica e educao sensorial-visual faz com que haja um certo preconceito para com os trabalhos artsticos, na Web, de um modo geral. Essa falta de conhecimento que faz com que algumas pessoas acreditem em mitos, na fora do 153

conhecimento emocional, em metforas, analogias, imagens que expressam situaes surrealistas, narrativas e exemplos ilustrativos que no expressam uma forma de pensamento ordenado. Reconhece-se que simplesmente um artista no a melhor opo para se trabalhar com o desenvolvimento de Web sites (ou publicitrio, jornalista, engenheiro, cientista etc, pois design para a Web para Web designers), mas os trabalhos artsticos podem contribuir para uma esttica melhor na fase do design de interfaces. O trabalho de um Web designer pode complementar o trabalho de um artista e vice-versa, assim como, um Web designer pode ter conhecimentos e habilidades artsticas (ou de outras profisses) para desenvolver melhores trabalhos. O comportamento do artista igual ao do Engenheiro e do Web designer quando ambos esperam pelos olhares de um pblico; por elogios; reconhecimentos etc. (Domingues, 2003). Se um Web site for desenvolvido com base na engenharia, em tcnicas de redao, de desenvolvimento e tratamento de imagens e tambm de conhecimentos artsticos, mais chances tem de aproveitar melhor o tempo e o lugar devido a cada etapa de um projeto. A arte pela arte difcil de ser empregada em obras de arquitetura, odontologia, engenharia, inclusive na engenharia Web. Porm a arte desenvolvida a partir de uma educao artstica e de razes objetivas, podem representar a qualidade esttica que diferencia um trabalho de outro; que faz com que um profissional seja mais requisitado e mais bem pago que outros; que um Web site seja mais visitado e bem sucedido que outros, mesmo em relao a outros que tm contedos semelhantes. Muitas vezes o que ordena a arte na Web so as estratgias mercadolgicas que buscam meios de agradar os usurios atravs de frases e ilustraes que despertam satisfaes e curiosidades. O conhecimento de perfis de usurio e uma viso de possibilidades de agradlos j no mais papel da engenharia. A engenharia j cumpriu o papel no desenvolvimento e do bom funcionamento do Web site. Na fase de design das interfaces so conhecimentos complementares, de outras cincias, de outras tcnicas e tambm de conhecimentos artsticos que representam a qualidade visual. A arte no atrapalha a engenharia, a engenharia no atrapalha a arte, desde que se d a cada uma seu tempo e seu espao buscando elevar a qualidade esttica e funcional dos Web sites ao invs de torn-los sem graa, simples e despersonalizados. 154

Sem conhecer um pouco de arte difcil saber as impresses que as artes causam! E, isso dificulta algumas escolhas como, por exemplo, de uma imagem entre muitas semelhantes; a escolha de vrias imagens para compor uma sobreposio; a escolha de vrias cores para fazer composies e contrastes. A arte na Web proporciona percepes privilegiadas de entendimento intuitivo de um trabalho, tanto para o profissional que cria, quanto para os usurios que as percebem, que prestam a ateno a ela. A criatividade pressupe uma pessoa inventiva que produz e d existncia a produtos que no existiam anteriormente, ainda que neste produto haja uma contribuio parcial. A represso acontece quando no so oferecidas condies criativas, e alm disso, enfatiza-se o no assumir riscos e ficar no terreno seguro da repetio, da igualdade e do j conhecido. A arte tambm usada na fico, mas no quer dizer que a arte no represente a realidade de um fato. Atravs da imagem pode-se mostrar instncias da realidade. Isso feito, muitas vezes, com a ajuda de fotografias que representam o registro visual de um fato. No entanto, nem sempre possvel fotografar tudo o que ocorre, na realidade, na fico, nos fenmenos naturais, restando a opo de registr-los atravs de desenhos, sejam estes feitos em papel ou no computador (antigamente eram utilizados recursos como pedra, madeira, pergaminhos etc). Mesmo as fotografias precisam muitas vezes, serem retocadas, compostas com outras, agrupadas em seqncia para simular animaes etc. Para fazer estes registros, so necessrios conhecimentos de educao artstica, de formas, de curvas, de perspectivas, de inclinaes, de sombras etc. Quanto mais habilidade tiver um profissional em registrar fatos reais ou modelos mentais criados para designar a ilustrao de um fato, de uma sucesso de fatos, de um comportamento natural, mais chances existem de se passar informaes que a escrita, por si s, no teriam a mesma preciso (Pauli, 1997). Isso mostra que existe espao para a arte na Web. Uma arte que representada por uma caracterizao de textos e imagens, links e formulrios (sons, animaes) com um design atraente, expressivo e com caractersticas de design planejado ao invs de design feito ao acaso. Existe espao para a arte ficcionista utilizada em Web sites cujo motivo seja a fico e a arte ordenada e precisa em Web sites que onde o objetivo dispor ao usurio informaes baseadas em acontecimentos cotidianos.

155

Os Web writters (bem como escritores de outros meios de comunicao) nem sempre so capazes de dizer "bem" o que pretendem dizer, assim como de ler, desenhar e escrever. Por outro lado, os usurios nem sempre so capazes de entender bem o contedo disponvel nas interfaces (bem como em outros meios de comunicao). Os smbolos grficos representativos tornam-se espontaneamente acessveis em "dizer mais". A comunicao se d atravs sistemas de smbolos (escrita e imagem), como as formas de artes grficas e mltiplas linguagens formais e coloquiais. A experincia virtual como um todo, no se traduz em uma forma exclusiva de smbolos, seja unicamente a escrita ou a imagem, ainda que descritos com base nas mais modernas tcnicas discursivas e ilustrativas. A educao para a arte na Web pode ser proposta pela ateno e pela convivncia com outros Web sites, por leituras diversas sobre tica, esttica e arte e pela tcnica de uso das ferramentas grficas e de design. Quanto mais ampla for essa convivncia, mais chances haver de se criar estilos atraentes e inovadores e que no comprometem o objetivo principal da Web que o bom funcionamento navegacional e o rpido carregamento. Em sntese, pretendeu-se expor o quanto os significados da arte na Web so to bsicos, que raramente h conscincia deles, ou so to estranhos quando seu estudo ignorado, que a maioria dos escritores sobre Web sites e Engenharia Web no reconhecem que h espao nem onde h espao para a arte na Web; que a arte no atrapalha a engenharia, mas auxilia se usada no tempo e espao que lhe apropriado. 5.3.1.2 - A Esttica na Web A conscincia esttica (do mesmo modo que a conscincia tica) de ordem estritamente social e dificilmente existem se no estiverem em causa pelo menos duas pessoas (Pauli, 1997). Filsofos como e Alexander Gottlieb Baumgarten e Ludwig Wittgenstein que abordaram a proximidade da tica e da esttica, muitas vezes considerando-as como sendo um nico assunto quando a tica e a esttica representam a investigao geral sobre o que bom (Moore, 1998). A esttica um ramo da filosofia que aborda a essncia e a percepo do belo e estuda racionalmente o belo e o sentimento que o belo suscita nos seres humanos. De acordo com a filosofia a esttica um conjunto de caractersticas formais que a arte assume em

156

determinado perodo e que pode, tambm ser chamado de estilo (Gallo, 1997), (Moore, 1998). O termo Esttica foi introduzido em 1753, pelo filsofo alemo Alexander Gottlieb Baumgarten, embora as primeiras teorias de certo alcance sejam as de Plato e de Aristteles. Ambos falaram da arte como imitao da realidade e consideraram a esttica inseparvel da tica (Pauli, 1997). A esttica na Web pode ser entendida atravs de um usurio, que por meio de uma curiosidade ou de uma forma de acolhimento percebe possibilidades de significado de arte e armazena os significados contidos na tela. O resultado dessas percepes depende dos conhecimentos e do senso crtico de cada usurio: aos que no tm conhecimento de arte e de ferramentas de desenvolvimento a interface oferece a experincia de contemplar a esttica; a sensao de estar diante do belo. Aos que so tambm criadores a experincia esttica pode gerar os mais diversos tipos de indagao como, por exemplo, que ferramentas que foram utilizadas; que cores; que linguagem; qual a formao de quem criou; quanto tempo foi despendido para a realizao daquele trabalho etc. A diferena entre uma interface pura e simplesmente tcnica e uma feita com arte, dedicao de mais tempo e mais zelo a impresso que uma ou a outra podem causar. Um estmulo visual pode estimular a imaginao de forma a induzir ou sugerir alguma sensao aos outros sentidos (olfato, paladar, tato, audio), bem como despertar o interesse por determinados assuntos. As cmeras fotogrficas (principalmente as digitais) tm se encarregado de fazer grande parte dos trabalhos ilustrativos, mas a partir das imagens extradas de cmeras h muito trabalho que pode ser refeito, retocado, recriado para proporcionar um diferencial esttico. Os estilos de realidade virtual, por exemplo, feitos a partir de fotografias esto entre os trabalhos mais valorizados na Web (indstrias de cosmticos, vestimentas, bijuterias, calados e multimdias em geral). Um dos princpios de usabilidade que fere princpios estticos a questo da simplicidade, utilizada de forma extremamente enftica pelo escritor Jakob Nielsen, (Nielsen, 2000). Nielsen afirma que para ser bom tem que ser simples! Uma maneira de entender que isso nem sempre verdade quanto se trata de interfaces de Web sites quando um Web designer oferece a seus clientes um trabalho simples, qual a chance de vender seu trabalho? Quando 157

se quer convencer um usurio a visitar um domnio no falando que neste domnio tem interfaces com uma esttica simples que se convence o usurio a fazer a visita. Interfaces simples podem ser desenvolvidas por pessoas inexperientes que aprenderam a usar um editor qualquer de HTML (crianas, por exemplo, desenvolvem interfaces simples para fazer seus blogs). No entanto para fazer trabalhos com requinte, funcionais e com caractersticas de trabalhos provenientes de profissionais necessrio pessoas experientes, que conheam os mais diversos aspectos tecnolgicos e artsticos que envolvem os sistemas Web. Ser simples, na Web, diferente de ser bom. O que se pode buscar em interfaces requintadas e com aspectos profissionais que alm de requintada, funcional e profissional, ainda passe uma impresso de simplicidade, (quando essa noo de simplicidade signifique de entendimento simples, intuitivo, de entendimento popular, do vulgo, do povo). O que se prope para a questo esttica, na fase de design das interfaces, uma busca de que estticas feitas com requinte, com zelo e com qualidade profissional para que sejam entendidas pelos mais diversos perfis de usurios. A partir da pode dizer que de uso simples, comum, mas no que a esttica da interface seja simples ou comum. A esttica traz consigo uma espcie de marca tcnica e artstica de quem a produz. A home page, por exemplo, pode ser comparada vitrine de uma loja onde o usurio (cliente) pode se interessar por algum link (produto) e acess-lo (entrar na loja). Quais as probabilidades de uma loja vender seus produtos a partir de uma vitrine simples? So praticamente as mesmas de um Web designer vender trabalhos Web simples (vende, sem dvida, desde que no haja ningum da concorrncia oferecendo trabalhos melhores). A questo da esttica das interfaces levanta questionamentos de como, por exemplo, em um cenrio de pesquisas interdisciplinar como o que envolve o papel dos projetistas e artistas na pesquisa com interfaces humano-computador, onde a contribuio conjunta traria resultados melhores. Segundo, Domingues, a viabilidade desse tipo de colaborao que os artistas tratam os problemas de uma forma bem diferente que os cientistas/engenheiros os tratam. A viso artstica pode ampliar o processo de pesquisa definindo novos tipos de questes a serem pesquisadas; oferecer interpretaes no-ortodoxas dos resultados; representar perspectivas potenciais do usurio e; colaborar de maneira geral com experincias artsticas-culturais para dar sustentao ao futuro de bases tecnolgicas (Domingues, 2003). 158

5.3.1.3 - A tica na Web A tica a investigao geral sobre o que bom (Moore, 1998). uma busca constante de fazer melhor aquilo que se faz. Filsofos como Ludwig Wittgenstein e Alexander Gottlieb Baumgarten (Pauli, 1997) mostravam estudos sobre a tica e a esttica como sendo assuntos difceis de serem separados considerando a tica como uma forma de conscincia que busca fazer o melhor e a esttica como uma concretizao de um bem que foi feito (Moore, 1998), (Baldwin, 2003). A tica das interfaces Web pode ser vista tanto em detalhes funcionais como na busca de um design mais atraente, dando ao design um tempo e um espao para que se concretize sem comprometer a funcionalidade e a compreenso do contedo como um todo. As redes globais de computadores dissolveram os limites geogrficos. Uma sociedade interconectada eletronicamente e sem fronteiras uma experincia relativamente nova que desafia as formas legais de diferentes pases e de comunidades locais. Os problemas ticos e jurdicos so muito grandes e permanecem ainda amplamente insolveis, pois necessitam de uma nova cultura, novas prticas e novas leis. E mesmo quando novas leis surgirem, serviro somente para julgar fatos onde tenha existido um agressor e uma vtima. A falta de tica pode ser praticada no deliberadamente, mas devido a limitaes tecnolgicas ou inexperincia de profissionais que passam a exercer atividades de desenvolvimento de Web sites pelo simples fato de terem aprendido a usar uma ferramenta de desenvolvimento e no porque tenham adquirido qualificao profissional. O que precisa ser considerado pelos profissionais da Web que nem sempre alguns usurios fazem uso de sistemas de forma deliberada como, por exemplo, sistemas bancrios, eleitorais, sistemas de compras, cadastros e inscries on-line diversas. Assim, a tica abordada como uma possibilidade de ultrapassar as fronteiras dessa sociedade sem fronteiras que a Internet e a Web, fazendo-se obedincia ao que no obrigatrio: buscando as maneiras mais coerentes possveis (dentro dos limites de cada profissional e dos recursos de cada projeto) para agradar e facilitar os procedimentos de quem pertence a essa sociedade. As interfaces Web so desenvolvidas para os usurios e usurios vem e entendem o design, a arte. Conseqentemente, nas interfaces onde se encontra a necessidade de se ter mais cuidado com a forma e com a esttica dos contedos disponveis 159

aos usurios. Para o usurio no importa se a qualidade proveniente da arte ou da engenharia; se uma questo de tica, de esttica, ou de usabilidade ou se todas estas questes que representam um bom design. 5.3.1.4 - Consideraes Tcnicas, Artsticas, Estticas e ticas em Interfaces Web A arte pressupe uma tcnica e a arte eletrnica pressupe um uso sistemtico de tcnicas em ferramentas grficas e de design. Enquanto um Web designer faz uso de tcnicas e as aplica em ferramentas, pode-se dizer que se est diante um trabalho tcnico. No entanto, o resultado do uso de tcnicas, aplicado em ferramentas, pode ser visto como um trabalho artstico e criativo uma vez que com o uso das mesmas tcnicas podem-se obter solues diferentes, caractersticas da maturidade de cada profissional. A seguir so mostrados alguns aspectos para os quais observa-se uma necessidade de ateno e de cuidados para que as interfaces sejam disponibilizadas ao usurio com esttica e funcionalidade atraentes. 5.3.1.4.1 - Estrutura de uma Interface A estrutura deve ser definida no inicio do projeto, pois a partir desta que se desenvolve o sistema navegacional. No entanto na hora da elaborao do design que os problemas de algumas estruturas mais aparecem. A estrutura de uma interface pode ser comparada estrutura ou construo de uma casa. Primeiro levanta-se uma estrutura e depois se colocam os mveis e decoraes dentro. Na Web desenvolve-se uma estrutura para colocar os atributos dentro. Uma estrutura pode ajudar ou dificultar a forma de navegao e a compreenso de uma interface. Alguns problemas mais freqentes, provenientes do tipo de estrutura so mostrados a seguir. Estrutura de frame: exibindo a prpria barra de navegao com uma pgina de terceiros na janela principal; dando a falsa impresso de que h uma pgina nica na tela, mas na verdade, a tela fica dividida fazendo com que uma ao do usurio no seja respondida em todos os pontos da tela quebrando um princpio da Web que diz que para cada janela do navegador, uma nica pgina e um nico endereo (URL) (Baker, 2001); quando h acoplamento de janelas, levando reduo do tamanho do espao disponvel para visualizao do contedo; quando a estrutura camufla o endereo de uma pgina no location do navegador, no permitindo que o usurio 160

mantenha o endereo em seus Favoritos ou anote para voltar mais tarde (Baker, 2001); quando gera barras de rolagem em pontos estratgicos da pgina. Estas barras geradas levam o usurio ao uso excessivo do mouse e comprometem a esttica do design (Baker, 2001); quando fragmenta uma pgina, fazendo com que ela aparea sem o arquivo complementar que normalmente a barra de navegao. Estrutura de tabelas: onde h excesso de repetio de cdigo prolongando o tempo de carregamento de cada pgina e dificultando o trabalho do administrador; quando os arquivos esto em muitos nveis de subdiretrios fazendo com que os URLs fiquem muito extensos, dificultando o registro escrito dos mesmos.

5.3.1.4.2 - Coerncia e Legibilidade dos Textos Para que um texto seja coerente, ele precisa ser disposto com uma certa lgica ou uma seqncia planejada de acordo com cada contedo. Para ser legvel tem que obedecer a algumas regras que facilitam a leitura, como tamanho da fonte, contraste da cor da fonte com a cor do fundo da tela, tipo ou design da fonte. Problemas provenientes de textos podem ser vistos quando as cores das fontes tm um tom muito prximo da cor do fundo da tela; quando o tamanho da fonte muito pequeno; quando o tipo da fonte muito artstico ou serrilhado, fazendo com que uma letra se funda com a outra, causando dificuldade de leitura; quando existem cones ou letrinhas seguindo o cursor do mouse, anulando o objetivo do cursor que de dar parmetro ao leitor do ponto onde ele est, na tela, e atrapalhando a viso do contedo (Baker, 2001); quando as formas de alinhamento no oferecem um parmetro vertical como o conseguido com os textos justificados ou alinhados esquerda. comum em Web sites a exibio de vrias frases, que no ocupam a linha toda, centralizadas ou blocos de textos centralizados ou sem justificar. Isso faz com que no haja um ponto inicial de leitura, o que causa uma dificuldade maior para o usurio. Problemas de contraste aparecem principalmente quando so usadas cores que no fazem parte da tabela Web safe (216 cores). As cores que esto fora da tabela sofrem variaes maiores, tanto quando usadas para cor de fundo como quando usadas para cor de fonte. O contraste visualizado em um tipo de navegador pode diferenciar muito do contraste visualizado em

161

outro. Isso faz com que reduza a preciso no contraste necessrio entre cor de fundo e fonte, para que se tenha uma boa legibilidade (Baker, 2001). 5.3.1.4.3 - Uso de Metfora e Termos Inadequados para a Web Um outro problema muito comum pode ser visto nas abreviaes, em misturas desnecessrias de idiomas e em usos inadequados de metforas, ttulos e termos representativos. Abreviaes: as abreviaes so necessrias algumas vezes. No entanto s devem ser usadas quando no h possibilidades de escrever a palavra toda, devido falta de espao. Se o espao no suficiente ao invs de utilizar vrias palavras abreviadas, uma sada tentar utilizar siglas (desde que em um espao prximo e visvel seja mencionado o seu significado); suprimir as palavras que no sejam de extrema importncia (que no tirem o significado da frase) e substituir a frase por uma menor que tenha o mesmo sentido. Ao decidir que uma palavra ser abreviada, ento se abrevia a menor parte possvel, utilizando a regra da direita para a esquerda (mantendo o incio da palavra). No caso de frase, as abreviaes so da direita para a esquerda (na palavra), comeando as abreviaes pelas primeiras palavras, mantendo as ltimas (da direita) intactas. Para o usurio saber que uma abreviao utiliza-se um ponto final aps as letras da abreviao (como se faz para um texto impresso). O problema das abreviaes e que quem faz a leitura tende a completar a palavra abreviada de acordo com uma frase ou palavra que v com mais freqncia. Misturas de idiomas: h termos que no fazem parte de um idioma, mas que no tm um substituto preciso para que possa ser substitudo. Essa uma situao em que a mistura de idiomas aceita. Um exemplo disso uma barra de navegao ter uma opo chamada links; para uma sala de bate-papo um link com a palavra chat etc. Termos que sejam representativos de situaes da Web, quando substitudos podem representar problemas ao invs de solues. Mas, isso s vale para termos em que a palavra proveniente de outro idioma seja mais usada e defina melhor uma situao. Existe ainda a questo das frases incompletas como, por exemplo, o uso da palavra home que significa casa, para expressar home page que a metfora usada para expressar pgina inicial. O mesmo observado no uso do about sem o complemento da frase, que pode ser sobre a empresa, sobre o instituto, sobre mim, sobre um produto. Enfim, as frases incompletas podem ser intuitivas para usurios 162

experientes e um enigma para usurios em geral. Quando as frases (palavras) so duvidosas necessrio que o usurio acesse aquele link e se, tiver um ttulo na pgina, poder saber o que seria o significado. As frases incompletas tambm aparecem e representam um problema quando as palavras so do prprio idioma, no entanto so mais bem entendidas com palavras de idiomas diferentes. Uso inadequado de metforas, ttulos e termos representativos: as metforas podem e devem ser usadas sempre que representarem uma informao de forma mais evidente que sua expresso natural. Uma metfora pode ser representada pela seguinte equao: A = B. Quando A, que representa a situao real tiver menos eficcia de comunicao que B, ento usa-se B, que representao de A, dita com outras palavras como, por exemplo, links ao invs de pontos (imagens ou textos) clicveis etc. Este exemplo mostra que praticamente no h problemas quanto ao uso de metfora, pois estas representam uma situao real. Alguns problemas podem ser vistos quando as palavras ou frases no representam uma situao real, no so metforas, mas representam aquilo que um profissional gostaria de dizer e no encontra palavras adequadas. Alguns exemplos so vistos em expresses como novidades, ltimos lanamentos, o mais recente, o melhor, o mais etc. quando no se trata de um produto interno, que se aparecer uma outra novidade (ou um produto/servio melhor) somente proveniente do segmento ora representado pelo domnio. Se a suposta novidade for de um outro segmento onde novidades possam ser lanadas a cada dia, termos como estes ficam sem sentido. Uma opo usar um termo representativo como, por exemplo, Pesquisas sobre o assunto x, complementares, lanamentos da linha x etc. Quando em uma barra de navegao encontra-se o termo links, o usurio normalmente acessa esperando encontrar uma interface de abertura que indica o endereo de outros domnios. O problema quando, para representar esta situao so usadas frases como: hora do lanche, brindes etc. Termos como estes no representam metforas e geram frustraes ao usurio que acessa esperando encontrar o que o link sugere. links

163

5.3.1.4.4 - Peso do Montante de cada Interface As imagens que fazem parte do design de um Web site so carregadas pelo navegador no momento em que um usurio as solicita. Muitas vezes uma imagem fala mais que muitas linhas de texto, portanto, quando bem relacionadas a um texto, elas no so dispensveis ou inteis, ao contrrio, so um apoio, uma afirmao. Porm, se forem pesadas demais, ao invs de ajudar, elas podero ser um obstculo devido demora do tempo de carregamento. Isso no quer dizer que os usurios tenham que ser privados das imagens de alta resoluo, apenas que elas no precisam ser parte integrante do contedo, podendo estar dispostas para download em um ou mais tamanhos. Assim como as imagens, o excesso de texto em uma pgina tambm retarda o tempo de exibio de um contedo, levando o usurio ao excesso do uso da barra de rolagem. 5.3.1.4.5 - Harmonia na Distribuio dos Atributos que Compem uma Interface Uma interface normalmente composta de textos, imagens e links (e formulrios quando so interfaces dinmicas). As imagens tm o objetivo de ilustrar o que foi dito em um texto e podem ser estticas ou animadas. As imagens animadas servem para chamar a ateno do usurio para um assunto que merea destaque naquela pgina. Os problemas aparecem quando existe um excesso de imagens em uma interface causando poluio visual, elevando o tempo para exibio e dificultando a mobilidade do usurio de um ponto para outro, devido ao peso da interface; quando se exibem mais de uma animao por pgina, deixando o usurio confuso sem saber a que dar mais ateno; quando as imagens so usadas sem necessidade, como por exemplo, onde um assunto j fala por si s. O uso indiscriminado de cones em links um dos maiores exemplos de uso desnecessrio de imagens. Se h uma frase que explica o que o contedo correspondente aquele link, no h a necessidade de colocar um cone para ilustrar. Se um link leva o usurio a home page, no precisa de uma casinha para fazer uma ilustrao e muito menos um envelope ou caixinha de correio para indicar um endereo de correio eletrnico (a maioria dos cones representam signos do mundo real, se o usurio for leigo uma casinha representar sugestes peculiares, conforme a experincia de cada um). A falta de harmonia tambm vista quando no h padronizao da estrutura das interfaces, do uso de cores, fontes e do design em geral; quando h grandes diferenas do modelo de uma interface para outra, dentro do mesmo site, o usurio poder ficar em dvida se j saiu ou ainda est no mesmo site (Baker, 2001); quando no h 164

disponvel uma barra de navegao (menu) para que o usurio possa saber onde est e para onde poder ir (Baker, 2001) e quando no um caminho de volta quando o sistema de navegao vai alm do segundo nvel (Baker, 2001).

5.3.1.4.6 - Adoo de um Tipo de Linguagem e/ou Tecnologia Estudar uma linguagem e fazer uso da mesma, um procedimento bsico de todo Web designer ou programador. Porm, quando se desenvolve uma aplicao para a Web, precisam ser levados em considerao alguns cuidados, principalmente quando se usam linguagens do lado do cliente, como JavaScript, CSS, XML etc. As linguagens do lado cliente dependem dos recursos da mquina do usurio para que o contedo de uma interface seja exibido. Por mais que se faam testes antes de publicar um Web site, no h um meio que saber que recursos existem na mquina de cada usurio. Isso s permite que o desenvolvedor tenha probabilidades de design e no certezas de que o contedo ser visto na ntegra. Alguns problemas decorrentes da linguagem/tecnologia podem ser vistos no uso de: FullScreen: o FullScreen (tela cheia) utiliza toda a tela do computador fazendo com que o usurio perca a barra de ferramentas do navegador (Baker, 2001). Excesso de plug-ins: com tantos recursos para desenvolvimento de pginas Web, no h necessidade de utilizar tecnologias que faam com que o usurio tenha que baixar plug-ins para visualizar o contedo de uma interface, ainda mais se esse plug-in tem poucas perspectivas de ser utilizado para visualizao de outros Web sites (algumas excees so os plug-ins de Java e Flash, que so bastante utilizados na Web). Substituio dos atributos originais: a caracterizao dos atributos originais das interfaces representa um design personalizado, mas a substituio destes atributos pode gerar algumas duvidas ao invs de facilidades. Alguns exemplos podem ser vistos quando so usados botes de comandos para a navegao ao invs de serem usados para fazer a ativao de pginas dinmicas (Leite, 2002); quando o sublinhado dos links retirado etc.

165

5.3.1.4.7 - Objetividade Dificilmente um usurio entra em um Web site com o objetivo de navegar, somente pelo motivo de ficar clicando em links. Um usurio clica em um link para encontrar o que a frase exposta no link sugere. Alguns problemas de objetividade podem ser vistos em situaes como: Insuficincia de dados: nas interfaces onde existem alguns dados disponveis, mas o usurio no tem informaes sobre o que eles so, como podem ser usados e porque esto l. Essas pginas do a impresso de que aquele fragmento de contedo foi jogado e esquecido l (o link ocupa um lugar nobre na barra de navegao, mas ningum sabe ao certo qual o seu objetivo). Nas pginas merchandising: onde um link sugere um contedo informativo, mas na verdade leva o usurio a propagandas disfaradas no meio de textos com contedo diferente do sugerido no link. Nas pginas de abertura sem contedo: que fazem com que o usurio acesse uma pgina de abertura e a simplesmente tenha que clicar em um link para entrar definitivamente na pgina. H situaes mais extremas, onde o usurio tem que escolher uma verso, de linguagem ou tecnologia, para entrar na pgina (Baker, 2001). Nas pginas em construo: onde s h uma mensagem de que algo est Em Construo, mas no fala o que est sendo construdo e nem a data que estar pronto para o usurio voltar pgina se tiver interesse pelo assunto. Nas informaes inteis: alguns exemplos de informaes inteis, que no proporcionam nada ao usurio e ainda ocupam um lugar de destaque em uma pgina, representam falta de maturidade por parte do desenvolvedor ou administrador. Essas informaes aparecem na forma de contadores de acesso visveis, algo que s interessa ao administrador do Web site e no ao internauta; na forma de ordens sem objetivo, como por exemplo, Clique Aqui ao invs de um link com uma frase referente ao que existir se o usurio Clicar no link. Na falta de democracia: a falta de democracia vista em informaes de exclusividade ou de restrio tecnolgica, como por exemplo, resoluo 166

recomendada, navegador recomendado, excesso de plug-ins e at recursos de hardware necessrios (Baker, 2001). Nos contedos desatualizados: que podem induzir o usurio a erros, em uma tomada de deciso; na falta de informaes necessrias como a ltima data de atualizao de cada pgina (Baker, 2001); Na falta de critrios de disponibilidade dos assuntos: como, por exemplo, por ordem de importncia e quando h vrios assuntos com a mesma importncia, uma seqncia por ordem alfabtica ou de acordo com uma hierarquia referente ao assunto. Isso vale tanto para links, principalmente em menus, como para segmentaes de textos e pginas (Baker, 2001).

5.3.1.4.8 - Canais de Comunicao Os canais de comunicao como e-mail, formulrios de cadastro, chats, listas de discusso, instant message, so recursos que fazem com que se o usurio quiser mais informaes do que as disponveis no site, saber a quem contatar e de que forma. Esses canais devem estar visveis em todas as pginas como uma forma de afirmar que algum responsvel pelas informaes disponveis e poder oferecer informaes adicionais caso o internauta as solicite (Baker, 2001), (IEEE, 2001). No entanto h situaes em que os canais de comunicao so usados de forma excessiva e arbitrria como, por exemplo, os formulrios quando aparecem no carregamento de uma interface em forma de caixinhas de alertas que no permitem que o usurio d seqncia na navegao enquanto no preenche os campos de dados e clica em um boto de envio; quando aparecem no carregamento de uma interface em janelas pop-up; quando ficam em forma de fly sobrepondo o contedo da interface. Muitos tpicos ainda poderiam ser abordados, sem que esgotassem os espaos onde a arte, a tica e esttica (ou a ausncia destas) podem ser observadas como benefcios para o usurio. No como uma lei, como mandamentos ou padres de design a serem seguidos, mas como observaes de um conjunto de caractersticas que podem ser usadas em um determinado tempo e espao, revelando, assim, o estilo do Web site. Este estilo que representa um diferencial na qualidade do design, que o que efetivamente visto pelo usurio.

167

Ao concluir a fase de design das interfaces os arquivos precisam ser enviados novamente ao servidor e isso requer novas avaliaes e novos testes, ainda que j tenham sido feitos ao concluir a fase de implementao. 5.3.2 - Avaliaes e Testes Aps a concluso da fase de design das interfaces, aparecem tipos de testes que no foram realizados ao final da fase de Implementao. Embora os testes navegacionais j tenham sido feitos a partir da mquina cliente e da mquina servidora, aps terem sido feitas mudanas, na fase de Design da Interfaces, necessrio que o sistema de navegao seja testado novamente, considerando que o sistema agora j est disponvel on-line. Neste estgio a ajuda de usurios de grande valia, pois muitas vezes a equipe de desenvolvimento j est to familiarizada com o Web site que erros bsicos (digitao, descrio de imagens, frases de links, endereos de links etc.) podem passar desapercebidos. Alguns tipos bsicos de testes que precisam ser feitos nesta etapa tanto pela equipe de desenvolvimento e administrao e se possvel por usurios diversos so avaliaes visuais, testes de navegao e testes de tempo de carregamento de cada interface. Avaliaes visuais: no final do desenvolvimento de um projeto, as interfaces normalmente j so intuitivas para a equipe de desenvolvimento. Porm necessrio considerar que o Web site foi desenvolvido pela equipe, mas no para a equipe e sim para o usurio. Ento, um forma de avaliao solicitar a usurios com conhecimentos diversos que faam um tour pelo site e forneam um feedback com consideraes como: as interfaces so intuitivas? Encontrou com facilidade o que o site sugere dispor? Encontrou questes antiticas? O design est atraente, original e de acordo com os motivos do domnio? Onde e como o Web site poderia ser melhorado? Testes de navegao: nesta fase, os testes de navegao precisam ser feitos a partir da mquina servidora por diversos navegadores; diversos sistemas operacionais; diversos sistemas de banda, seja larga ou estreita. As diferenas de design entre navegadores, sistemas operacionais e sistemas de banda so comuns. Quando se usa uma linguagem que utiliza um servidor de pginas dinmicas como PHP, por exemplo (usada neste processo), essas diferenas so bastante reduzidas ou quase eliminadas, pois o servidor que se encarrega de gerar o contedo e no os recursos 168

do cliente. Como h tambm linguagens que dependem dos recursos da mquina cliente como, CSS e JavaScript etc., os testes de navegao so indispensveis para que haja uma certificao de que as diferenas no comprometem o entendimento do design e do contedo do Web site. Peso e tempo de carregamento: testes feitos a partir de diferentes tipos de banda representam as respostas finais referentes a manter ou fazer modificaes de design. O que pode reduzir o tempo de carregamento de uma interface a quantidade de texto e de imagens; a peso das imagens e o tipo de editor utilizado (formatao automtica ou codificao manual). Ainda que as avaliaes de design estejam de acordo com o objetivo do domnio, os testes com o tempo de carregamento (download) podem revelar necessidades de reduo do espao ocupado por uma imagem para que possa haver uma maior compactao; reduo do nmero de imagens por interface; segmentao do contedo gerando novas interfaces; escolha de um outro editor (quando do uso de formao automtica). Uma outra questo quanto ao tempo de carregamento de uma interface deve ser considerada em relao ao tipo de usurio predominante ou da segmentao mercadolgica. Se o objetivo do Web site so os acessos de um perfil de usurios onde a maioria dispe de recursos atualizados de software e hardware e conexo por banda larga os resultados considerados razoveis so diferentes dos resultados para um perfil mais diversificado ou predominante de recursos mais modestos.

169

170

CAPTULO 6 RESULTADOS

O processo proposto j foi aplicado em Web sites de alguns domnios e outros que foram desenvolvidos somente para a realizao de testes. As aplicaes foram feitas com o uso de ASP e PHP e somente alguns testes para estrutura dinmica foram feitos com JSP. O processo proposto foi implementado PHP, conforme mostrado na fase 2 e pode ser feito, seguindo os mesmos procedimentos, tambm em ASP. Alguns resultados obtidos atravs da utilizao do PDW-UML podem ser vistos em alguns exemplos, como os relacionados a seguir. Implementao de um novo tipo de estrutura feito com arquivos-matriz: a estrutura formada pelos arquivos-matriz prope e mostra melhorias tanto para a equipe, ao reduzir o trabalho de implementao como para o usurio que tem estruturas padronizadas, seqncias exatas em menus etc. O uso de arquivos-matriz representa uma contribuio para a engenharia ao representar uma forma de implementao formalizada e testada. As estruturas propostas at ento representam recursos de uso do HTML (frames e tabelas) que podem ser usados da maneira que o desenvolvedor considerar melhor. A estrutura de frames reduz o trabalho para o desenvolvedor, mas representa muitos problemas para o usurio. A estrutura de tabelas oferece as mais diversas possibilidades de uso, sendo inclusive um recurso utilizado tanto em estruturas com frames como pela estrutura de arquivos-matriz, no entanto, a estrutura em si no prope um uso formalizado que represente benefcios equipe e aos usurios. Se um desenvolvedor optar por usar estruturas de arquivos-matriz, o far a partir do conhecimento de como desenvolver um Web site com este tipo de estrutura e isso j representa obter o benefcio das melhorias pertinentes estrutura. Reduo dos nveis de URLs: o modelo de Estrutura Dinmica (ED) proporciona ao desenvolvedor e administrador a organizao da distribuio dos arquivos e diretrios, conforme seja necessrio para facilitar o entendimento do sistema, independente de quantos nveis sejam necessrios. Para ter esta mesma organizao nos demais modelos (Seo 4.1), o usurio precisa acompanhar toda a estrutura 171

lgica existente na mquina, o que resulta em URLs muito longos, difceis de serem memorizados e trabalhosos para serem anotados. O modelo ED consegue solucionar o problema dos URLs longos fazendo com que os usurios acessem os arquivos somente de dois nveis que o nvel root e um abaixo do root onde ficam os arquivos-matriz. Todos os demais arquivos constantes em outros diretrios e subdiretrios tm papel de servidores de contedo para os arquivos-matriz no representando nveis de URLs para os usurios. Abordagem de conceitos: o PDW-UML aborda alguns conceitos e mostra onde so utilizados em Web sites mostrando alguns exemplos do que uma estrutura de dados e uma estrutura de interface, o que um design e o que um atributo que compem o design de uma interface. Aborda ainda o papel da engenharia e o papel filosfico (arte, tica e esttica) dentro de um Web site, mostrando que ambos tm seu tempo e seu espao sem que um anule ou atrapalhe a funo desempenhada pelo outro. Uso da UML e de novos esteretipos: o uso de esteretipos propostos para representar as interfaces auxilia o desenvolvimento de novos projetos sem que haja a necessidade de fazer descries dos tipos de interfaces, pois o esteretipo j faz a representao. O uso dos diagramas da UML mostrando atributos das interfaces e as necessidades do projeto tambm colabora para proporcionar uma linguagem comum aos Web designers. Como os esteretipos so parte integrante do PDW-UML, o desenvolvedor que conhecer o PDW-UML conhecer tambm os esteretipos e poder utiliz-los em seus projetos, desenvolvendo-os em qualquer editor de imagens, pois os mesmos no apresentam recursos que sejam de um editor especfico. Valorizao do trabalho artstico e criativo: a proposta de uma fase para o design dentro de um processo procura valorizar o trabalho artstico e criativo mostrando que sem a engenharia e sem um projeto formalizado a funcionalidade pode ser comprometida. Por outro lado, a partir de um trabalho feito dentro de padres da engenharia ainda h viabilidades para um tratamento no design onde a arte e a criatividade podem proporcionar uma qualidade esttica no prevista pela engenharia.

172

Reduo do tempo de download: o sistema de reutilizao de arquivos, conforme feito com as diretivas de include de SSI, , representam uma reduo de tempo de download devido estrutura formada pelos arquivos-matriz. Quanto mais arquivos estiverem includos em outros arquivos onde h reincidncia de chamadas, menos cdigos o sistema ter que interpretar e menos tempo levar para concluir o download de uma interface.

Reutilizao de contedo: existem vrias maneiras de fazer uso de SSI, de CSS, tabelas, frames etc. No entanto, a maneira como SSI e demais recursos so utilizados que se conseguem os resultados mostrados como melhorias de usabilidade para o usurio e reusabilidade para a equipe. Conforme a implementao do PDW-UML tambm se separam algumas categorias de arquivos, facilitando o desenvolvimento e a reutilizao. Dessa forma possvel reaproveitar os arquivos para desenvolver novos Web sites e para reaproveitamento no prprio Web sites em caso de mudana de tecnologia. - Arquivos de interface: os arquivos de interface trazem instrues de caractersticas de design (so os arquivos com instrues de CSS, com design de textos, tabelas etc.) podendo ser aproveitados em outros Web sites e com outras tecnologias, bastando fazer pequenas modificaes como, por exemplo nos cdigos das cores. Esses arquivos podem ser utilizados em interfaces que no usem estrutura dinmica, fazendo incluso com diretivas de include de CSS. - Arquivos-matriz: como os arquivos-matriz fazem somente a chamada de outros arquivos, podem ser modificados para uso em uma tecnologia diferente como, por exemplo, de PHP para ASP e vice-versa, bastando fazer modificaes das diretivas de include conforme a linguagem. - Arquivos de contedo: os arquivos de contedo tm a mnima utilizao de instrues de cdigo, (os cdigos esto nos arquivos de interface) por isso podem ser reutilizados com outras tecnologias sem a necessidade de grandes modificaes.

173

174

CAPTULO 7 CONCLUSO

O que se pretendeu com o presente trabalho foi mostrar um processo que envolva o levantamento de requisitos, a implementao e o design procurando colocar em prtica os objetivos da engenharia ao buscar usabilidade (facilidade de uso) para o usurio e reusabilidade (facilidade de usar novamente) para a equipe. A facilidade de uso pode ser vista na estrutura padronizada das interfaces. Independente de como seja o design final, as interfaces tm a mesma estrutura e a mesma forma de organizao. Isso reduz as possibilidades de que o usurio perca a ordem da navegao ou tenha dvidas se j esteve naquela interface ou se ainda est no mesmo domnio o que normalmente ocorre quando no se mantm um padro de estrutura, seja estrutura de interface ou estrutura de dados. A facilidade de reutilizar pode ser vista na reutilizao dos arquivos e por no ter a necessidade de repeties de cdigo ao fazer incluses de arquivos de forma ordenada para obter o mximo de reaproveitamento e o mnimo de repeties. Este trabalho no representa o desenvolvimento de uma nova tecnologia, mas apresenta o uso conjunto de algumas linguagens e tecnologias existentes mostrado em um processo de desenvolvimento. Este processo prope esteretipos especficos para interfaces de Web sites; apresenta abordagens diversas que podem facilitar o desenvolvimento de novos projetos como, por exemplo, o levantamento e a anlise dos requisitos para Web site e prope uma forma de documentao que pode servir de help ou guia para novos profissionais e para os que j estejam envolvidos em um projeto. Algumas diferenas entre a engenharia de software e a engenharia Web podem ser vistas na fase de implementao (Seo 5.2) onde as formalizaes utilizadas representam solues para a Web, mas teriam poucas possibilidades de aproveitamento ou uso para softwares convencionais. Para o desenvolvimento de softwares convencionais no h a necessidade de um planejamento da distribuio e nomenclatura de arquivos e diretrios com foi proposto para a Web. A documentao proposta para Web site tambm diferente da documentao de softwares. Enquanto a documentao de software est mais voltada ao uso do software, a documentao do Web site est mais voltada para registros de informaes, convenes e apenas uma pequena parte voltada orientao de como trabalhar com o Web site. Na 175

primeira fase as diferenas podem ser vistas na forma de levantamento e seleo dos requisitos. As semelhanas so mostradas principalmente na modelagem e nas possibilidades de uso da UML para ambos os casos. Ambas tm pontos em comum, mas finalidades diferentes, fazem uso de recursos diferentes e tm usurios diferentes. Ainda que as fases e 1 e 2 sejam representadas por solues provenientes da engenharia, a fase 3 representa um tempo e um espao para o trabalho artstico e criativo. Assim podem ser vistas algumas diferenas entre a arte e a engenharia e que ambas so necessrias ao desenvolvimento de Web sites: a engenharia faz uso de formalizaes e solues j testadas e a arte mostra que possvel uma soluo diferente de acordo com os objetivos de cada domnio. O processo apresentado neste trabalho mostrou a implementao feita em PHP e faz referncias tambm a ASP e JSP. Implementaes em ASP j foram feitas e apresentam praticamente os mesmos resultados obtidos com o uso de PHP quanto ao projeto, forma de implementao e tempo de download. O que ainda no foi implementado so aplicaes em JSP. Normalmente quando h

aplicaes desenvolvidas em Java, estas representam trabalhos mais complexos onde h um grande volume de dados e conseqentemente, bancos de dados e gerao de interfaces dinmicas. Como perspectiva de um novo trabalho estuda-se a possibilidade de desenvolvimento de uma ferramenta que tenha um editor de cdigos, que entenda a dinmica do sistema, a hierarquia formada pelas diretivas de include e um sistema de desenvolvimento que crie os diagramas para a modelagem. Uma ferramenta com estas (e outras) caractersticas poderia ser uma forma de auxlio para os programadores gerenciar o projeto como um todo. Se os programadores, atravs do uso de uma ferramenta que entenda a dinmica do sistema, conseguissem entregar um Web site j implementado aos Web designers, para que faam o tratamento do design como proposto pela fase 3 do PDW-UML, poderia ser um bom meio de integrao entre profissionais. A integrao atravs do uso de uma ferramenta poderia representar o uso de um propsito comum que garantir a qualidade e o funcionamento do sistema nas duas primeiras fases e finalizar o trabalho com o tratamento do design.

176

REFERNCIAS BIBLIOGRFICAS

Aranha, M. L. Filosofando: introduo filosofia. So Paulo: Moderna, 2003. 440p. Baker, A. Theory. 2001. Disponvel em: <http://www.merges.net/theory/>. Acesso em: 20 nov. 2004. Baldwin, T. A hundred years of principia ethica. 2003. Disponvel em: <http://www.cfh.ufsc.br/ethic@/ETH@21~1.PRN.pdf>. Acesso em: 20 nov. 2004. Bell, Ian. HTML, DHTML & Web design. So Paulo: Market Books, 2000. 617p. Booch, G. et al. UML, guia do usurio. Rio de Janeiro: Campus, 2000. 472p. Bos, B. Cascading style sheets. 2003. Disponvel em: <http://www.w3.org/Style/CSS/>. Acesso em: 20 nov. 2004. Br.php.net. Manual do PHP. 2003. Disponvel em: <http://br.php.net/tut.php>. Acesso em: 20 nov. 2004. Bruce R. S. The Interspace: concept navigation across distibuted communities. ComputerIEEE, v. 35, n. 1, Jan. 2002, p. 54-62. Ceri, S. Fraternali, P. Bongio, A. Modeling data entry and operations in WebML. In: International Workshop on the Web and Databases, 3., WebDB 2000, Dallas, USA, 2000. Proceedings... Dallas: ACM PODS/SIGM, p. 201-214, 2000. Disponvel em: <http://www.research.att.com/conf/webdb2000/PAPERS/6b.pdf>. Acesso em: 20 nov. 2004. Ceri, S. Fraternali, P. Bongio, A. Web modeling language (WebML): a Modeling Language for Designing Web Sites. Computer Networks-The International Journal Of Computer And Telecommunications Networking , v.33, n.1-6, p. 137-157, Jun. 2000. Disponvel em: <http://www.webml.org/webml/page1.do>. Acesso em: 20 nov. 2004. Chase, N. Aprendendo active server pages 3.0. So Paulo: Makron Books, 2000. 406p. Chau, M. Convite filosofia. So Paulo: tica, 2000. 440p.

177

Conallen, J. Modeling Web applications architectures with UML. Communications of ACM, Oct. v. 42, n. 10, p. 63-70, 1999. Domingues, D. Arte e vida no sculo XXI: tecnologia, arte e criatividade. So Paulo: Editora UNESP, 2003. 380p. Drgnescu, M. Broadband Internet and the knowlwdge society. 2003. Disponvel em: <http://www.racai.ro/~dragam/BROADBAND-INTERNET-AND-TKNOWLEGDE.pdf>. Acesso em: 20 nov. 2004. Franklint, K. ASP, Tcnicas e Estratgias. So Paulo: rica, 2001. 346p. Gallo, S. tica e cidadania: caminhos da filosofia. Campinas: Papirus, 1997. 79p. Gardner, H. Inteligncias mltiplas, a teoria na prtica. Porto Alegre: Artmed Bookman, 1997. Garzotto, F.; Schwabe, D.; Paolini P. HDM - A model based approach to hypermedia application design, ACM transaction on information systems, v. 11, n.1, p.1-26, Jan.1993. Graef, G.; Gaedke, G. Development and Evolution of Web-Applications using the WebComposition Process Model. In: International WorkShop on Web Engineering at International Conference, 9. , (www9), 2000, Amsterdam. Proceedings Amsterdam: TecO, 2000. Disponvel em: <http://www.teco.edu/~gaedke/paper/2000-www9-webe.pdf>. Acesso em: 20 nov. 2004. Gudwin, R. Linguagens de programao. Campinas: DCA/FEEC/UNICAMP, 1997. Disponvel em: <http://www.eng.uerj.br/~araujo/disciplinas/Caract/ling_prog.pdf>. Acesso em: 20 nov. 2004. Haddleton, F.; Pfaltz, J. L. Client/Server Architecture in the ADAMS Parallel ObjectOriented Database System, In: International, Conference on Scientific Computing in ObjectOriented Environments, ISCOPE '97, 1., 1997, Marina del Rey, CA, Proceedings Marina del Rey: Disponvel em: <http://www.cs.virginia.edu/~adams/iscope.pdf>. Acesso em: 20 nov. 2004.

178

Hurlburt A. Layout: o design da pgina impressa. So Paulo: Nobel, 2002. 157p. Isakowitz, T. Stohr, A. Balasubramanian, P. RMM: a methodology for structured hypermedia design. Communications ACM, v. 38, n. 8, p. 34-44, Aug.1995. Isaak, J. Web site engineering best practice standards (IEEE 2001), 2001. Disponvel em: <http://standards.ieee.org/reading/ieee/std/internet/2001-2002.pdf>. Acesso em: 20 nov. 2004. Instituto Brasileiro de Opinio Pblica e Estatstica (IBOPE). Parceria entre IBOPE e ACNielsen eRatings.com. 2004. Disponvel em: <http://www.ibope.com.br/>. Acesso em: 20 nov. 2004. Kirda, E. Jazayeri, M. Kerer, C. Experiences in engineering flexible Web services. IEEE Multimedia, v.8, n. 1, p. 58-65, Jan-Mar 2001. Leite, J. Design e usabilidade de sistemas Web. 2002. Disponvel em: <http://www.dimap.ufrn.br/~jair/diuweb/>. Acesso em: 20 nov. 2004. Lima, m. Consideraes em torno do conceito de esteretipo: uma dupla abordagem. 1986. Disponvel em: <http://sweet.ua.pt/~mbaptista/consideracoes%20em%20torno%20do%20 conceito%20de%20esterotipo.pdf>. Acesso em: 20 nov. 2004. Ministrio da Cincia e Tecnologia (MCT). Internet e telecomunicaes. Braslia, MCT, 2004. Disponvel em: <http://www.mct.gov.br/temas/info/imprensa/internet.htm>. Acesso em: 20 nov. 2004. Medeiros, M. Conhecendo ASP, PHP e JSP. 2002. Disponvel em: <http://nuclinfo.famato.org.br/down/poster_AI_02.pdf>. Acesso em: 20 nov. 2004. Mendes, M. A. Comparao e anlise de requisies dinmicas em servidores Web. 1999. Disponvel em: <http://www.dcc.ufmg.br/pos/html/spg98/anais/corelio/corelio.html>. Acesso em: 20 nov. 2004. Mesquita, R. C. Analise e projetos orientados a objetos. 2003. Disponvel em: <http://www.ead.eee.ufmg.br/~renato/appoo/>. Acesso em: 20 nov. 2004.

179

Microsoft Corporation. Internet information services. 2003. Disponvel em: <http://www.microsoft.com/WindowsServer2003/iis/default.mspx>. Acesso em: 20 nov. 2004. Microsoft Corporation. Using VBScript and jscript on a web page. 1998. Disponvel em: <http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnvid/html/msdn_vbnjscrpt. asp>. Acesso em: 20 nov. 2004. Moore, G. Principia ethica. 1998. Disponvel em: <http://www.rbjones.com/rbjpub/philos/bibliog/moore03.htm>. Acesso em: 20 nov. 2004. Netscape Communications Corporation (NCC ). Cliente-side JavaScript guide. v. 1.3, 1999. Disponvel em: <http://plbpc001.ouhk.edu.hk/%7Emt834/course-units/unit8/materials/mt834_unit8/ClientGuideJS13.pdf >. Acesso em: 20 nov. 2004. Nielsen, J. Projetando websites. Rio de Janeiro: Campus, 2000. 362p. Novaes, A. tica. So Paulo: 9. ed. Companhia das letras. 2003. 395p. Pauli, E. (ed.), Enciclopdia Simpzio: histria da filosofia moderna, cap. 15. 1997. Disponvel em: <http://www.cfh.ufsc.br/~simpozio/novo/2216y605.htm> Acesso em: 20 nov. 2004. Pereira, A. Schwabe, D. Especificao declarativa de aplicaes Web em OOHDM. 2001. Disponvel em: <http://www-di.inf.pucrio.br/schwabe/papers/Adriana%20SBMidia%202001. pdf>. Acesso em: 20 nov. 2004. Prestwood, M. Static versus dynamic content. 2003. Disponvel em: <http://prestwood.com/internet/design/default.asp>. Acesso em: 20 nov. 2004. Ribeiro, R. J. Cdigos de tica. 2004. Disponvel em: <http://noticias.aol.com.br/colunistas/renato_janine/2004/0030.adp>. Acesso em: 20 nov. 2004. Roldo, D. Estudo sobre inteligncia artificial. 2000. Disponvel em: <http://www.citi.pt/educacao_final/trab_final_inteligencia_artificial/>. Acesso em: 20 nov.

180

Roselli, A. Usable web: frames. 1999. Disponvel em: <http://usableweb.org>. Acesso em: 20 nov. 2004. Rossi, G.; Schwabe, D.; Barbosa, S. OOHDM: Object-Oriented Hypermedia Design Method. Tese de doutorado, PUC-Rio, 1996. Disponvel em: <http://www-lifia.info.unlp.edu.ar/~fer/oohdm/allindex.htm>. Acesso em: 20 nov. 2004. Secretaria de Poltica de Informtica (SEPIN). Internet comercial: evoluo da Internet no Brasil e no mundo, conceitos, estatsticas e aspectos legais. Braslia: MCT, abr, 2000. Shimbun. K. Nihon. Nihon Keizai Shimbun Incorporation. Disponvel em: <http://www.nikkei.co.jp>. Acesso em: 20 nov. 2004. Sun.com. Sun one Active Server Pages. 2003. Disponvel em: <http://wwws.sun.com/software/chilisoft/>. Acesso em: 20 nov. 2004. The Apache Software Foundation. Apache HTTP server project. 2002.Disponvel em <http://httpd.apache.org>. Acesso em: 20 nov. 2004. Yager, Tom. ChiliSoft gives a ASP sizzle to Unix. v.21, n.17, Apr. 1999. Disponvel em: <http://www.infoworld.com/cgi-bin/displayArchive.pl?/99/17/i02-17.47.htm>. Acesso em: 20 nov. 2004. Zafiris, A. P. A Practitioners Approach to Evolving and Remodeling Large-Scale WWW sites. In: Hawai International Conference on System Sciences, 34., Jan. 3-6, 2001, Maui, Hawai. Proceedings Maui, Hawai: IEEE, 2001. Disponvel em: <http://csdl.computer.org/comp/proceedings/hicss/2001/0981/07/09817078.pdf>. Acesso em: 20 nov. 2004. Zelenovskiz, R. & Mendona, A. Funcionamento de modems. Jun. 2001. Disponvel em: <http://www.gabrieltorres.com.br/modems.html>. Acesso em: 20 nov. 2004. W3C, tradues. W3C em sete pontos. 2003. Disponvel em: <2002. http://www.amtechs.com/w3c/w3c7points.html>. Acesso em: 20 nov. 2004.

181