Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Especialização em Desenvolvimento para Web

Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Especialização em Desenvolvimento para Web WebML aplicada a um Sistema de Gestão Empresarial para Entidades de Classe Márcia Toshie Tanimoto Profª Drª Elisa Hatsue Moriya Huzita (Orientadora) Maringá, 2007

Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Especialização em Desenvolvimento para Web Márcia Toshie Tanimoto WebML aplicada a um Sistema de Gestão Empresarial para Entidades de Classe Trabalho submetido à Universidade Estadual de Maringá como requisito para obtenção do título de Especialista de Desenvolvimento de Sistemas para Web

Universidade Estadual de Maringá Centro de Tecnologia Departamento de Informática Especialização em Desenvolvimento para Web Márcia Toshie Tanimoto WebML aplicada a um Sistema de Gestão Empresarial para Entidades de Classe Profª Drª Elisa Hatsue Moriya Huzita(Orientadora) Ass:... Profª Drª Maria Madalena Dias Ass:... Profª Drª Tânia Fátima Calvi Tait Ass:...

Resumo Nos últimos anos, a web vem se tornando cada vez mais popular. Como conseqüência a essa expansão, a utilização da internet também tem sofrido modificações consideráveis. A web deixou de conter apenas portais informativos, para abrigar grandes e complexos sistemas das mais diversas áreas. Mas a forma de desenvolvimento desse tipo de sistema não acompanhou a demanda, sendo ainda adotados métodos ad-hoc, sem nenhuma padronização. Devido a essa deficiência, várias pesquisas vêm sendo realizadas para identificar as necessidades, restrições e prioridades de sistemas web, assim como várias propostas de metodologias de modelagem foram também definidas. Dentre essas propostas, está a WebML A WebML é uma linguagem de modelagem visual que possibilita a representação dos aspectos hipertextuais de um sistema web, modelando as características de composição das páginas, conteúdo e navegação. Esse trabalho apresenta um estudo de caso de um sistema de gestão empresarial para entidades de classe, modelado usando a linguagem WebML. Com este trabalho procurou-se analisar os pontos fortes da WebML em um sistema real e avaliar sua eficiência em atender as necessidades de sistemas web. Palavras-Chave: Engenharia web, Aplicações web, WebML

Abstract In the last few years, the web has been becoming even more popular. As a consequence of this expansion, the use of the internet has been suffering considerable modifications too. The web left to have only informative portals to keep great and complex systems from diverse areas. But the way these kind of systems are developed didn't follow this demand, been still adopted ad-hoc methods without any pattern. Considering this lack, many researches have been doing to identify the needs, restrictions and priorities from these systems, as like many proposes of modeling methodologies have been defined. Among these proposes is WebML. The WebML is a visual modelling language that enables the representation of hipertextuals aspects from web systems, modeling their pages composition, contents and navigation characteristics. This work presents a case study of an enterprise management system to class entities, modelling with WebML language. This work tries to analyze the strong points of WebML in a real system and evaluate your efficiency to take care of web systems needs. KeyWords: Web Engineering, web applications, WebML.

índice de Figuras Figura 2.1 - Crescimento da web nos últimos anos...14 Figura 2.2 - Engenharia Web Um campo multidisciplinar...23 Figura 2.3 - Dimensões de modelagem para aplicações web onipresentes...28 Figura 2.4 - Dimensões de personalização......29 Figura 3.1 - Exemplo da representação de entidades e seus atributos...33 Figura 3.2 - Exemplo de hierarquia entre entidades...33 Figura 3.3 - Representação XML de uma entidade de dados...35 Figura 3.4 - Notação gráfica para unidade de dados...36 Figura 3.5 - Representação XML de uma unidade de dados múltiplos...36 Figura 3.6 - Notação gráfica para unidades de dados múltiplos...37 Figura 3.7 - Representação textual para unidades de índice...37 Figura 3.8 - Notação gráfica para unidades de índice...37 Figura 3.9 - Notação textual para unidade de rolagem...38 Figura 3.10 - Notação gráfica para unidades de rolagem...38 Figura 3.11 - Notação gráfica para unidades de entrada....38 Figura 3.12 - Notação gráfica para unidades de entrada...39 Figura 3.13 - Representação gráfica de unidade de operação...39 Figura 3.14 - Representação XML de unidade de operação...39 Figura 3.15 - Notação gráfica de uma página...40 Figura 3.16 - Exemplo de ligação contextual...40 Figura 3.17 - Exemplos de Landmark, home page, default page e área...43 Figura 3.18 - Esquema básico para representação de aplicações com restrição de acesso a visões do site...44 Figura 4.1 - Diagrama de use case...49 Figura 4.2 - Diagrama de estruturas para o SGEC...50 Figura 4.3 - Operação de login...52 Figura 4.4 - Alteração de dados pessoais...53 Figura 4.5 - Modelagem do controle de representados...53 Figura 4.6 - Modelagem de cadastro de contratos...55 Figura 4.7 Modelagem de geração de taxas...56

Índice de Tabelas Tabela 2.1 - Comparação entre sistemas web simples e sistemas web avançadas...15 Tabela 2.2 - Categorias de Aplicações Web...20 Tabela 2.3 - Comparação entre abordagens de modelagem e o suporte que oferecem às atividades de modelagem de sistemas web...26

Lista de Abreviaturas WebML UML OMG MER IEEE HDM RMM OOHDM WSDM UWE ADM HTML PC Wap XML OID OQL CASE Web Modeling Language Unified Modeling Language Object Management Group Modelo Entidade-Relacionamento Institute of Electrical and Electronic Engineers Hypertext Design Model Relationship Management Methodology Object-Oriented Hypermidia Design Method the Web Site Design Method the UML-based Web Engineering Araneus Data Model Hypertext Markup Language Personal Computer Wireless Application Protocol Extensible Markup Language Object Identifier Object Query Language Computer Aided Software Engineering

Índice 1. INTRODUÇÃO... 10 1.1. OBJETIVO DO TRABALHO... 12 1.2. METODOLOGIA DE PESQUISA... 12 1.3. ORGANIZAÇÃO DA MONOGRAFIA... 13 2. ENGENHARIA WEB... 14 2.1. INTRODUÇÃO... 14 2.2. CATEGORIZAÇÃO DE SISTEMAS WEB... 19 2.3. CARACTERÍSTICAS DE SISTEMAS WEB... 21 2.4. LINGUAGENS E MÉTODOS DE ANÁLISE PARA SISTEMAS WEB... 24 2.5. CONCLUSÕES FINAIS... 30 3. WEBML... 31 3.1. INTRODUÇÃO... 31 3.2. MODELO DE ESTRUTURA... 32 3.2.1. Entidades... 32 3.2.2. Relacionamentos... 34 3.3. MODELO DE HIPERTEXTO... 34 3.3.1. Modelo de Composição... 34 3.3.1.1. Unidades... 34 Unidades de dados... 35 Unidades de dados múltiplos... 36 Unidades de índice... 37 Unidades de rolagem... 38 Unidades de entrada... 38 Unidades de operação... 39 3.3.1.2. Páginas... 39 3.3.2. Modelo de Navegação... 40 3.3.3. Organização de hipertextos... 42 3.4. MODELO DE APRESENTAÇÃO... 43 3.5. MODELO DE PERSONALIZAÇÃO... 43 3.6. MODELO DE DERIVAÇÃO... 44 3.6.1. WebML OQL... 44 3.6.2. KeyWords, predicados e operadores... 45 3.6.3. Expressões de início... 46 3.6.4. Passos da navegação e valores de atributos... 46 3.6.5. Condições... 46 3.6.6. Atributos derivados... 46 3.6.7. Entidades derivadas... 47 3.6.8. Relacionamentos derivados... 47 4. ESTUDO DE CASO... 48 4.1. VISÃO GERAL... 48 4.2. MODELO DE ESTRUTURA... 50 4.3. MODELAGEM DE HIPERTEXTO... 51 4.3.1. Identificação de Site Views... 51 4.3.2. Modelagem das funcionalidades... 53 4.4. AVALIAÇÃO FINAL SOBRE A UTILIZAÇÃO DA WEBML... 56 5. CONCLUSÃO... 59 5.1. TRABALHOS FUTUROS... 60 6. REFERÊNCIAS BIBLIOGRÁFICAS... 62

10 1. Introdução Nos últimos anos houve uma crescente preocupação sobre a forma de modelar um sistema de computador em um nível de abstração que pudesse atender a diferentes tipos de sistemas e equipes de desenvolvimento. De acordo com Ceri et al. (2003), o objetivo da modelagem de dados é possibilitar a especificação dos dados usados pela aplicação em uma maneira intuitiva e formal. O resultado da modelagem dos dados é um esquema conceitual que transmite de maneira simples e legível o conhecimento disponível sobre os dados da aplicação. Connalen (2002) afirma que "... modelos descrevem o que queremos construir, o que estamos construindo e o que temos que construir...". Considerando-se a necessidade de uma modelagem eficiente, no final dos anos 80 um grupo de amigos elaborou uma linguagem de modelagem, a UML (Unified Modelling Language), que após passar por um processo de padronização pela OMG (Object Management Group), tornou-se um padrão para modelagem de sistemas. Mas a UML não atende as necessidades de representação e particularidades de uma aplicação web ou sistemas data intensive. Segundo Ceri et. al. (1999), web sites data intensive são aqueles cujo objetivo principal é permitir que usuários acessem grande quantidade de dados. De acordo com Connalen (2002), um sistema web é um sistema hipermídia, ou seja, apresenta os recursos ligados uns aos outros. Uma aplicação web estende um sistema web para adicionar funcionalidades, em outras palavras, uma aplicação web é um sistema web que possibilita a execução de lógica de negócio em um navegador de internet. De acordo com Lei (2004) as características que devem ser modeladas em um sistema web são: estrutura de modelos de domínio, que descreve a informação que será gerenciada e apresentada pelo web-site. Navegação, que possibilita ao usuário final navegar através de web-sites. Interface de usuário, que descreve a estrutura de composição dos conteúdos de páginas web e permitem acesso dinâmico a fontes de dados. Apresentação, que expressa o estilo de apresentação dos elementos da interface do usuário.

11 Personalização, que descreve a forma de especializar um propósito geral de um web-site através da definição de perfis para um usuário ou grupo de usuários. Considerando-se a deficiência da UML em representar as particularidades de sistemas web, surgiu a necessidade de definição de uma linguagem de modelagem que pudesse representar tais características de maneira satisfatória. A WebML (CERI et. al. 2000) é uma linguagem de modelagem baseada em padrões populares, como UML e MER (modelo entidade-relacionamento) que procura modelar sistemas de aplicação web atendendo às necessidades específicas de um ambiente web, como as mencionadas anteriormente. Este trabalho procura aplicar a WebML em um sistema real de gestão com interfaces web, procurando assim identificar as vantagens e desvantagens na adoção dessa modelagem. Para o desenvolvimento de sistema web, algumas características, tais como seqüência de navegação das páginas, layout e organização das páginas, devem ser mais cuidadosamente estudadas. Considerando-se que um sistema de gestão visa atender principalmente funcionários, que desenvolverão atividades específicas, acredita-se que aspectos de personalização devam ser mais cuidadosamente analisados, já que os conceitos de grupos de trabalho e divisão de tarefas são fortemente definidos. Atenção maior será dedicada também à modelagem de navegação entre as páginas, uma vez que sistemas dessa natureza possuem atividades que exigem seqüências lógicas, nem sempre passíveis de desvios, ou seja, algumas operações não podem apresentar caminhos alternativos na navegação para não prejudicar a consistência dos dados de negócio. Um exemplo seria a geração de boletos de cobrança, que deve ser executado em uma seqüência lógica e atinge várias classes de negócio. A WebML foi adotada por fornecer suporte a elementos importantes no desenvolvimento desse tipo de sistema, como características de navegação e apresentação das páginas.

12 1.1. Objetivo do trabalho O objetivo desse trabalho é avaliar os pontos fortes e fracos da WebML através de um estudo de caso de um sistema de gestão empresarial, mais especificamente, sistema de gestão para entidades de classe (sindicatos, associações e organizações), com interfaces web. Os objetivos específicos são: Estudar as características relevantes e o cenário atual do desenvolvimento de sistemas web; Estudar a linguagem de modelagem WebML; Aplicar a WebML em um estudo de caso; Avaliar as vantagens e desvantagens na utilização da WebML; 1.2. Metodologia de pesquisa O desenvolvimento deste trabalho foi dividido da seguinte forma: Estudo dos conceitos teóricos relacionados ao desenvolvimento de sistemas web: nessa etapa foram feitas pesquisas relacionadas às características de aplicações web identificadas por diversos autores e as características consideradas relevantes para o desenvolvimento de sistemas web. Estudou-se também nesta fase algumas abordagens e estudos comparativos para escolha da abordagem a ser aplicada no estudo de caso. Estudo dos conceitos teóricos sobre a WebML: após a escolha da WebML, foise necessário aprender a utilizar a WebML e sua ferramenta de apoio WebRatio. Para isso procurou-se estudar a teoria da linguagem e tutoriais da ferramenta e desenvolver pequenos exemplos. Levantamento das regras de negócio da aplicação. Para desenvolver o estudo de caso, foi necessário o entendimento do funcionamento de uma entidade de classe e o levantamento dos requisitos e regras de negócio necessárias para desenvolver um sistema de gestão para esse domínio. Desenvolvimento do estudo de caso: Depois de identificados os requisitos do sistema e estudada a WebML, procurou-se desenvolver um estudo de caso

13 utilizando-se das definições da linguagem; após o que foi realizada uma avaliação observando sua importância e eficiência no desenvolvimento. Redação da monografia: redigir a monografia paralelamente às etapas anteriores. 1.3. Organização da monografia Além do presente capítulo, a monografia está organizada como segue: Capítulo 2: Engenharia web apresenta um levantamento teórico sobre o desenvolvimento de sistemas web, as características relevantes no desenvolvimento desse tipo de sistemas, o cenário atual e os estudos existentes sobre o assunto. Capítulo 3: WebML descreve detalhadamente a linguagem de modelagem WebML Capítulo 4: Estudo de caso apresenta a descrição do estudo de caso, a modelagem de alguns casos de uso utilizando a WebML e o levantamento das vantagens encontradas na utilização da linguagem. Capítulo 5: Conclusões e trabalhos futuros apresenta as conclusões obtidas através do desenvolvimento do estudo de caso e sugestões para trabalhos futuros. Capítulo 6: Referências bibliográficas.

14 2. Engenharia web 2.1. Introdução Em sua primeira década de existência, a World Wide Web alterou o modo como as informações são criadas e trocadas e como os negócios são realizados globalmente. Desde sua criação até os dias atuais, a web vem se tornando cada vez mais popular. Em 13 anos, o número de web sites teve um crescimento de 100 para mais de 100 milhões, como pode ser constatado através da Figura 2.1 (fonte: http://www.zakon.org/robert/internet/timeline). Figura 2.1 Crescimento da web nos últimos anos De acordo com Murugesan et. al. (1999), a popularidade e ubiqüidade provêm da própria natureza da Web e suas características: ela fornece uma representação da informação que suporta interligação de todos os tipos de conteúdo, acesso fácil a usuários finais e fácil criação de conteúdo usando diversas ferramentas disponíveis. Kappel et. al. (2004) identificam que a onipresença da web se deve à sua característica de ser compartilhada globalmente, sua disponibilidade permanente, o acesso uniforme às informações e distribuição freqüente das informações produzidas por qualquer um na forma de páginas web.

15 Mas acoplada a essa popularização houve também uma evolução com respeito ao tipo de informação e a forma de manipulação dessa informação na web. Hoje muitas empresas e instituições procuram utilizar a web não só como meio de troca de informações, mas também como ferramenta para seus negócios. A Tabela 2.1 apresenta uma breve comparação entre um sistema web simples e um sistema web complexo: Tabela 2.1 Comparação entre sistemas web simples e sistemas web avançadas. (Ziemer, 2004) Sistemas web simples Sistemas web avançados Páginas simples apresentando apenas Páginas web complexas informações textuais Conteúdo não muda conteúdo estático Informação dinâmica muda com o tempo ou conforme a necessidade do usuário Navegação simples Navegação complexa. Difícil encontrar informações na página. Maior quantidade de informações Sistemas stand-alone Integração com bancos de dados e outros tipos de sistemas. Performance não é requisito principal Requer alto desempenho e disponibilidade contínua Desenvolvido por um único indivíduo ou Requer equipe grande de por equipe pequena desenvolvimento e especialistas em várias áreas Utilizado para disseminação da informação Desenvolvido para aplicação de missão não relacionada ao núcleo da aplicação crítica Pode-se constatar através da Tabela 2.1 que sistemas web avançados possuem conteúdo mais complexo, maior quantidade de dados manipulados, necessidade por maior portabilidade e desempenho do que simples home pages. Embora a utilização da web tenha se tornado mais complexa, devido à maior quantidade de informações e a necessidade de maior interação com a lógica de negócio e

16 com o usuário, a forma de desenvolvimento desse tipo de sistema, não vêm acompanhando essa evolução de maneira satisfatória. O cenário atual de desenvolvimento de aplicações web apresenta soluções individuais para cada aplicação, com pouco ou nenhum planejamento ou padronização. Lei (2004) considera que o estado da arte de tecnologias de desenvolvimento web tais com Active Server Pages (Microsoft) 1 e Java Server Pages (Sun Microsystems) 2 fornecem soluções satisfatórias para extração e manipulação de conteúdo de dados dinâmicos originários de bases de dados. Contudo, abordagens de prototipação rápidas ad-hoc à qual são dirigidas tais tecnologias e são adotadas em práticas correntes, facilmente levam a resultados insatisfatórios, como, por exemplo, pobre manutenibilidade e extensibilidade. Uma pesquisa sobre desenvolvimento de aplicações web realizado pela Cutter Consortium em 2000 (EPNER, 2000) apontou alguns problemas existentes nos projetos de grandes sistemas web: 84% dos sistemas entregues não atendem às necessidades do negócio; 53% dos sistemas entregues não possuem funcionalidades requeridas; 79% dos projetos excedem o tempo estipulado; 63% dos projetos estouram o orçamento Ginige (2002) acredita que a principal causa do fracasso no desenvolvimento de sistemas web consiste em falhas no gerenciamento e desenvolvimentos desses sistemas. Murugesan et. al. (1999) acrescentam também que aplicações web pobremente desenvolvidas têm grandes probabilidades de falhar e ainda, como a complexidade de sistemas web tem crescido, uma falha pode causar problemas tais como quebra de sigilo de informações, provocando uma Web crisis. Os autores destacam ainda que uma potencial crise em sistemas web pode ser mais sério e comum do que as crises em sistemas de software que os desenvolvedores têm enfrentado. Murugesan et. al. (2005) apud Dart (2001) afirmam que muitas organizações estão indo ao encontro de uma Web crisis na qual são incapazes de manter o sistema atualizado e/ou melhorá-lo e atualizá-lo no nível necessário. Essa crise envolve a proliferação de remendos desenvolvidos sem uma abordagem sistemática. 1 http://www.asp.net. Acesso em 31/01/2007 2 http://java.sun.com/products/jsp/. Acesso em 31/01/2007

17 Murugesan et. al. (2005) destacam ainda que em certas classes de aplicações, tais como gerenciamento de cadeias de suprimentos, serviços financeiros e comércio digital, uma falha no sistema pode propagar problemas em muitas outras funcionalidades, causando um verdadeiro desastre. O custo de um projeto ruim, desenvolvimento precário, pobre desempenho e/ou gerenciamento de conteúdo insatisfatório para aplicações baseadas em web pode ser extremamente sério, já que a quantidade de usuários desse tipo de sistema costuma ser maior que em sistemas convencionais. Os mesmos autores acreditam que, embora alguns web sites demandem por apresentação e navegação simples e possam ser criados apenas interligando documentos e imagens, há mais no desenvolvimento de aplicações web do que apenas desenvolvimento visual e interface de usuário. Esse envolve planejamento, projeto arquitetural e de sistema, teste, garantia de qualidade e desempenho, atualização e manutenção contínuas. Um interessante diagnóstico é apresentado por Ginige e Murugesan (2001a) sobre os problemas no desenvolvimento de sistemas baseados em web. Os autores afirmam que muitos desenvolvedores dedicam pouca atenção ao levantamento de requisitos, análise, processos e metodologias de desenvolvimento, qualidade, avaliação de desempenho, gerenciamento de configuração e projeto, manutenção e escalabilidade. Além disso, o desenvolvimento lida com o conhecimento e experiência de um único indivíduo ou grupo pequeno e práticas próprias, sem uma prática padronizada. Ainda, segundo Ginige e Murugesan (2001a), outro problema a ser destacado é a visão, por alguns desenvolvedores/usuários, da web como sendo uma mídia de informação, ao invés de uma mídia de aplicação. Connalen (2002) acredita que devido à popularidade da World Wide Web (Web), a necessidade de organizar grandes quantidades de dados de maneira hipertextual vem crescendo. O autor afirma também que sempre que um site contiver quantidades significativas de dados, seu design se torna um processo complexo que envolve pelo menos dois aspectos. Por um lado, existem características do processo de desenvolvimento que se preocupa com o gerenciamento dos dados e, por outro lado, a estrutura de hipertextos deve ser cuidadosamente desenvolvida com o objetivo de fornecer páginas organizadas. Um desenvolvedor cuidadoso deve coordenar apropriadamente estes dois aspectos. Costagliola et. al. (2002) acrescentam ainda que é importante destacar que as metodologias de desenvolvimento de software tradicionais geralmente não consideram

18 aspectos estéticos e cognitivos, tais como a aparência das páginas e facilidade de navegação, que são consideravelmente importantes em aplicações web. Murugesan e Ginige (2005) complementam a idéia afirmando que o desenvolvimento de sistemas baseados em web vai muito além do desenvolvimento de software tradicional. Há sutis diferenças na natureza e ciclo de vida de sistemas baseados em web e sistemas tradicionais, assim como na forma que são desenvolvidos e mantidos. Murugesan e Ginige 2005 apud Powell 2000 consideram que o desenvolvimento web é uma mistura entre publicidade impressa e desenvolvimento de software, entre marketing e computação, entre comunicação interna e relacionamento externo e entre arte e tecnologia. Para mudar esse cenário caótico do desenvolvimento de projetos baseados em web, uma grande quantidade de pesquisadores passaram a dedicar maior atenção sobre a maneira de desenvolver tais projetos, atentando às características essenciais de uma aplicação tradicional e levando em consideração as características específicas de uma aplicação web. Em 1998, foi estabelecido por uma equipe de pesquisadores da Universidade de Sidney, Austrália e da IEEE, que a engenharia web seria uma nova disciplina. Desde então, foram organizados diversos eventos e workshops sobre o tema e várias novas pesquisas foram realizadas. Novas abordagens e cursos sobre engenharia web estão sendo ensinados nas Universidades, tanto em nível de graduação quanto de pós-graduação e pesquisas adicionais estão sendo realizadas levando em consideração diversos aspectos da engenharia web. Não é surpresa também que o interesse de desenvolvedores de internet em utilizar metodologias da engenharia web vem crescendo (COSTAGLIOLA, 2002). As diferenças entre aplicações tradicionais e aplicações web são discutidas na próxima seção. Murugesan (1999) destaca que há necessidade por abordagens, disciplinas e novos métodos e ferramentas para desenvolvimento, instalação e avaliação de sistemas baseados em web. Mais do que isso, tais abordagens e técnicas devem considerar: 1) as características particulares da nova mídia; 2) o ambiente operacional; 3) cenários e multiplicidade de perfis de usuário e; 4) tipos (habilidades e conhecimento) do pessoal envolvido na construção do sistema.

19 Connalen (2002) define a engenharia web como sendo uma disciplina que estuda a aplicação de sistemáticas, disciplinadas e quantitativas abordagens para desenvolvimento, operação e manutenção de aplicações baseadas em web. As características consideradas importantes no desenvolvimento de aplicações web são apresentadas na Seção 2.3 2.2. Categorização de sistemas web Com a popularidade da web nos últimos anos, sua utilização vem sofrendo modificações. A web deixou de ser uma mídia informativa, contendo apenas textos estáticos, e passou a ser utilizada para diversas funcionalidades; antes exclusivas de sistemas típicos. Assim, a web deixou de abrigar somente web pages comuns e passou a abrigar diferentes categorias de sistemas, tais como sistemas de comércio eletrônico, sistemas de informação etc. Ziemer (2004) afirma que a primeira categorização para aplicações web foi encontrada em Connalen (2002), o qual afirma que a distinção entre Web sites e aplicações web é sutil e depende da habilidade do usuário em afetar o estado da lógica de negócio implementada no servidor. Se não existe lógica no servidor, o sistema não pode ser considerado uma aplicação web. Uma categorização mais detalhada é fornecida por Ziemer, 2004 apud Hassan, 2001, que classifica aplicações web em duas dimensões: A quantidade de lógica de controle e A quantidade de dados processados Ziemer (2004) categoriza ainda aplicações web em quatro dimensões: Brochura Nenhuma lógica de controle e nenhum dado processado. Um exemplo dessa categoria é uma simples home-page. Aplicações orientadas a serviços alguma lógica de controle e quantidades pequenas de dados são processados. Esses sites são dedicados a fornecer algum tipo de serviço ao usuário, como por exemplo, webmail.

20 Aplicações data intensive aplicações web que fornecem uma interface para manipular grandes quantidades de dados. Como por exemplo, sites de busca. Aplicações de sistemas de informações uma mistura de aplicações orientadas a serviço e aplicações data intensive, como por exemplo sites de comércio eletrônico. Ginige e Murugesan (2001a) apresentam uma outra categorização de sistemas baseados em web, levando em consideração o tipo de informação manipulado, conforme mostrado na Tabela 2.2. Tabela 2.2 Categorias de Aplicações Web (Ginige e Murugesan, 2001a) Categoria Exemplos Informacional Jornais on-line, catálogo de produtos, classificados on-line, e- books Interativo Formulários de registro, jogos online Transacional Compras on-line, bancos on-line Workflow Gerenciamento e estoque, programação e planejamentos online Ambiente de trabalho colaborativo Ferramentas de projeto colaborativo Comunidades on-line, Grupos de bate-papo Portais web Portais de comércio eletrônico Para efeito desse trabalho, apenas duas categorias foram consideradas, tal como definido por Connalen (2002); Web pages, caracterizando sistemas que não afetam a lógica de negócios, tendo apenas intuito informativo e sistemas web, que representam sistemas que afetam de alguma maneira a lógica de negócio.

21 2.3. Características de sistemas web Kappel et. al. (2004) destacaram algumas características de sistemas web, encontradas na literatura existente: Características relacionadas à aplicação. No desenvolvimento de aplicações web, devem ser considerados não somente funcionalidades, mas também aspectos de conteúdo, hipertexto e apresentação. o Conteúdo. Os autores relatam que aplicações web são fortemente dirigidas a conteúdo. A complexidade aumenta, principalmente, pelo fato do conteúdo ser freqüentemente dinâmico e continuamente atualizado. Além disso, usuários normalmente demandam qualidade no conteúdo, em termos de tópicos, consistência, exatidão e confiabilidade. Murugesan e Ginige (2002) destacam também que o conteúdo de aplicações web é diversificado, podendo incluir textos, gráficos, imagens, áudio e/ou vídeo. A forma como esse conteúdo é apresentado e organizado tem implicações no desempenho e no tempo de resposta do sistema. o Hipertexto. Aplicações web lidam com paradigmas de hipertexto para a estruturação das informações. A característica essencial do paradigma de hipertexto é a sua não linearidade; requerendo de ambos, autor e usuário, maior atenção aos aspectos de navegação. Costagliola (2002) acrescenta que para melhorar a legibilidade de documentos web, o desenvolvedor deve evitar a exposição de conteúdo excessivo e montar um modelo coerente para que o usuário não se sinta perdido no hiperespaço. o Apresentação. Em aplicações baseadas em web, a interface é o fator principal. Além disso, diferentemente de aplicações tradicionais, usuários web normalmente não terão acesso a um manual sobre a forma de utilizar o sistema. Características relacionadas ao uso. Diferentemente de aplicações tradicionais, usuários de aplicações web freqüentemente variam em número e base cultural, uso de dispositivos heterogêneos e de diferentes localizações e tempo de acesso.

22 o Infra-estrutura técnica imprevisível. Dispositivos de usuário final variam em relação às capacidades de hardware e software, tais como poder de computação, versão do navegador, velocidade de conexão à rede, estabilidade, largura de banda, etc. o Diversidade de usuários. Usuários de aplicações web diferem em idade, base cultural e social, objetivos, intenções, habilidades, etc. Essa heterogeneidade deve ser levada em consideração pelo desenvolvedor, visto que a aplicação somente será utilizada se fornecer alguma vantagem ao usuário, e não como uma obrigação. Características relacionadas ao desenvolvimento. Os desenvolvedores deverão lidar com condições, riscos e incertezas não existentes em sistemas tradicionais. o Equipe de desenvolvimento. O desenvolvimento de aplicações web é multidisciplinar, englobando profissionais com diferentes habilidades. Ginige e Murugesan (2001a) afirmam que são necessários profissionais de análise de sistemas e design, engenheiro de software, engenheiro de hipermídia e hipertextos, engenheiro de requisitos, desenvolvedor da interação humano-computador, desenvolvedor de interface de usuário, engenheiro de conteúdo, testador, gerente de projeto, designer gráfico e de apresentação. A Figura 2.2, criada por Murugesan et. al. (1999) exemplifica as diversas áreas envolvidas nas atividades de desenvolvimento de um sistema web.

23 Figura 2.2 Engenharia Web Um campo multidisciplinar (Murugesan et al., 1999) o Ambiente de desenvolvimento. A infra-estrutura técnica usada para desenvolvimento é caracterizada pelo alto grau de volatilidade e heterogeneidade, por lidar com diferentes componentes, tais como, servidores web, servidores de aplicação, sistemas de banco de dados, frameworks de publicação etc. o Integração com sistemas legados. Freqüentemente surge a necessidade de integração com sistemas legados. Esses sistemas normalmente são pobremente documentados, freqüentemente modificados sem aviso, afetando negativamente a aplicação web. o Processo. Processos de desenvolvimento de aplicações web são freqüentemente modificados e ajustados, devido ao rápido desenvolvimento tecnológico, tendência contínua a mudanças, requisitos voláteis e cronograma rígido. Murugesan et. al. (1999) afirmam que devido a essa mudança constante, não há uma fase formal de análise de requisitos em projetos web. Isso tudo demanda por métodos de desenvolvimento orientados à prototipação, flexível e iterativo. Características relacionadas à evolução. Aplicações web estão sujeitas a freqüentes mudanças e evolução permanente. Seu desenvolvimento é dirigido a constantes mudanças tecnológicas e a volatilidade dos usuários web, levam a uma situação de competitividade, onde o curto tempo de mercado é considerado

24 crucial. Ziemer (2004) considera que o tempo médio de um projeto web gira em torno de três meses. 2.4. Linguagens e métodos de análise para sistemas web Como mencionado anteriormente, na Seção 2.1, desde 1998 a forma de desenvolvimento de aplicações web tem atraído o interesse da comunidade de pesquisadores, e desde então, uma considerável quantidade de metodologias, linguagens, ferramentas e processos têm surgido. A maioria das abordagens existentes atualmente foca em algumas funcionalidades específicas no desenvolvimento de aplicações web, como por exemplo, representação de recursos de hipermídia, ou características de personalização de usuários. Ginige e Murugesan (2001b) elaboraram, baseados em suas experiências, uma lista com 10 passos que consideram principais para um desenvolvimento de sucesso: Entender as funcionalidades do sistema como um todo, inclusive os objetivos e requisitos de negócio; Identificar claramente os stakeholders; Especificar os requisitos técnicos e não técnicos dos stakeholders e do sistema como um todo; Desenvolver uma arquitetura geral do sistema web que atenda aos requisitos técnicos e não técnicos; Identificar sub-projetos ou sub-processos para implementar a arquitetura. Se os subprojetos são muito complexos de se gerenciar, divida-os até que se tornem partes gerenciáveis; Desenvolver e implementar os sub-projetos; Incorporar mecanismos efetivos para gerenciar a evolução, mudanças e manutenção do sistema; Apontar aspectos não técnicos, tais como manutenibilidade, desempenho, etc.; Medir o desempenho do sistema; Refinar e atualizar o sistema. Para acompanhar as necessidades no desenvolvimento de aplicações web, várias

25 linguagens e padrões de modelagem têm sido propostos, tais como HDM (Hypertext Design Model) (GARZOTTO et al., 1993); RMM (Relationship Management Methodology) (ISAKOWITZ et al., 1995), OOHDM (Object-Oriented Hypermidia Design Method) (SCHWABE e ROSSI, 1998), Araneus (ATZENI et al., 1998), HDM-lite (FRATERNALI e PAOLINI, 1998), Strudel (FERNANDEZ, et al., 1998), WSDM(the Web Site Design Method) (De TROYER e LEUNE, 1998), UWE (the UML-based Web Engineering) (HENNICKER e KOCH, 2000), OO-H (GÓMEZ et al., 2000), WebML (Web Modelling Language) (CERI et al., 2000), OntoWebber (JIN et al., 2001), Hera (FRASINCAR et al., 2002) entre outros. De acordo com Lei (2004) as abordagens correntes distinguem diferentes camadas para descrever sistemas web e fornecer modelos para resolver cada camada adequadamente. Em particular, eles fornecem suporte para o desenvolvimento de estruturas de navegação. Além disso, muitas abordagens fornecem modelos de interface de usuário e também, suporte à personalização. Ainda de acordo com Lei (2004), duas soluções têm sido desenvolvidas nas abordagens correntes com relação à personalização. Personalização em nível de composição, que permite a construção de diferentes visões de sites em tempo de desenvolvimento e personalização em nível de derivação, que permite a construção de diferentes visões de sites em nível de execução. Ainda, Lei (2004) apresenta uma comparação das diferentes abordagens descritas anteriormente na perspectiva de especificações que este considera relevantes no desenvolvimento de aplicações web de alto nível. São eles: modelagem de domínio, modelagem de navegação, modelagem de interface de usuário, modelagem de apresentação e modelagem de personalização. Uma apresentação resumida sobre as abordagens mencionadas pode ser encontrada em Lei (2004). A Tabela 2.3 ilustra os resultados dessa comparação e uma explicação mais detalhada sobre as atividades analisadas e os resultados obtidos são fornecidos a seguir. Foram usadas 4 categorias de classificação ilustradas da seguinte maneira: 1-Suporte completo( ), 2- Suporte razoável( ), 3- pouco suporte( ), 4- nenhum suporte ( ).

26 Tabela 2.3 Comparação entre abordagens de modelagem e o suporte que oferecem às atividades de modelagem de sistemas web. (Lei, 2004) Modelagem de domínio: Modelagem de domínio refere-se à semântica das bases de dados de domínio dos web-sites. Muitas abordagens fornecem suporte a essa atividade através da abstração das estruturas de dados de domínio, a especificação das estruturas de navegação e de interfaces de usuário para acesso aos dados do domínio. A WebML define um conjunto de operações de construção para apoiar o gerenciamento de dados de domínio. Outras abordagens tais como HDM e WSDM não apóiam acesso dinâmico aos dados do domínio, tendo a informação que ser definida, necessariamente, em tempo de desenvolvimento. Modelagem de navegação: Modelagem de navegação refere-se ao comportamento da estrutura e comportamento da navegação do web-site. Vários métodos têm sido propostos para apoiar essa atividade de modelagem. Por exemplo, a OOHDM utiliza o conceito de classes de navegação, que são nodos, links, índices e guias para suportar a navegação do web-site. Abordagens mais recentes, tais como WebML, OntoWebber e Hera fornecem meta-modelos para

27 especificação de navegação em nível conceitual. Modelagem de interface de usuário: modelagem de interface de usuário refere-se à composição das páginas. Essa atividade tem sido tratada por muitas abordagens. Por exemplo, ARANEUS faz uso de modelos de dados lógicos (ADM Araneus Data Model), que representa uma descrição abstrata da página web. Strudel utiliza um gerador de páginas HTML associado a um template para apoiar o desenvolvimento de páginas; UWE fornece um modelo abstrato de interface de usuário e finalmente abordagens como OOH, WebML e OntoWebber propõem primitivas para descrever interfaces de usuário típicas, como interfaces de apresentação de dados, aquisição de dados e consulta de dados. Modelagem de apresentação: A modelagem dos estilos de apresentação e layouts não têm sido totalmente tratadas pelas abordagens correntes. Muitas dessas abordagens têm utilizado conceitos externos, como folhas de estilo, para realizar tal especificação. Isso acontece por que os componentes das páginas não são completamente representados de forma declarativa, assim nem todos os aspectos de apresentação são representados em nível conceitual. OntoWebber propõe um conjunto de primitivas de layout (ex. layout de fluxo e layout de grade) para descrever layouts típicos de interface de usuário. Modelagem de Personalização: Uma vez que web-sites possuem informações que interessa a um público variado, torna-se necessário apresentar visões personalizadas para usuários individuais. Primeiramente, a personalização em nível de composição é atendida por todas as abordagens através da separação dos modelos de dados do domínio dos modelos de visão do site, permitindo assim que diferentes visões sejam criadas sobre o mesmo conjunto de dados. Segundo; personalização em nível de derivação é desenvolvida por abordagens como UWE, WebML, OntoWebber e Hera, que permitem a derivação de visões personalizadas para usuários individuais de acordo com seu perfil e personalização de requisitos em tempo de execução.

28 Kappel et al. (2001) acreditam que poucos métodos para modelagem de sistemas web tratam da natureza onipresente da web. Os autores destacaram algumas características que consideram importantes na modelagem de sistemas onipresentes. A Figura 2.3 apresenta algumas dimensões que devem ser consideradas Figura 2.3 Dimensões de modelagem para aplicações web onipresentes. (Kappel et al., 2001) A primeira dimensão compreende três níveis em termos de conteúdo, hiperbase e apresentação. O nível de conteúdo se refere aos dados dependentes do domínio. O nível de hiperbase denota a composição lógica das páginas e a estrutura de navegação. O nível de apresentação engloba a apresentação da hiperbase, ou seja, o layout de cada página. A segunda dimensão, chamada aspectos é ortogonal à primeira, e requer que tanto aspectos estruturais, em termos de mecanismos de abstração, tais como classificação, agregação e generalização, como também os aspectos comportamentais, como lógica de negócio, ativação de nodos de navegação e interação com usuário precisam ser consideradas. E finalmente a estrutura e comportamento do conteúdo, hiperbase e apresentação precisam ser direcionados por cada uma das fases do processo de desenvolvimento; análise, projeto e implementação. Além das dimensões consideradas anteriormente, Kappel et al. (2001) definem a personalização como uma dimensão adicional. A personalização é um mecanismo uniforme para possibilitar a onipresença adaptando uma aplicação web através de um contexto particular que reflete o ambiente no qual a aplicação está sendo executada. Kappel et. al. (2001) acreditam ainda que a personalização se apresenta em 3 dimensões ortogonais: tipo de contexto, granularidade de adaptação e grau de

29 personalização. A Figura 2.4 representa essa idéia e em seguida uma breve explicação sobre cada dimensão é apresentada. Figura 2.4 Dimensões de personalização. (Kappel et al., 2001) Tipo de Contexto: reflete o ambiente no qual a personalização é considerada. A personalização pode ser considerada sob o foco do usuário, tipo mais comum, onde as características e preferências do usuário são consideradas. O contexto de rede e de dispositivos também é uma abordagem bastante estudada, onde o foco é direcionado aos aspectos de acesso, largura de banda, limitações de hardware do cliente etc.. Contexto de localização engloba localizações físicas e lógicas, como por exemplo acesso realizado em casa ou no escritório. Poucas abordagens estudam esse contexto. Finalmente, contexto de tempo, que considera personalização de acordo com o ponto no tempo em que um determinado serviço é acessado. Granularidade de adaptação: A segunda dimensão indica o nível de granularidade de adaptação, que pode variar entre micro adaptação até macro adaptação. Essa dimensão diz respeito ao tipo de adaptação que ocorre na página de acordo com o contexto atualmente aplicado. Podem ocorrer adaptações simples, como links desabilitados, até adaptações complexas, como substituição de componentes da página para determinados grupos. Grau de personalização: essa dimensão expressa que tanto contexto quanto adaptação podem ser estáticas ou dinâmicas, ou seja, determinadas ou não durante a execução. Um exemplo de adaptação estática é a definição da versão de acordo com o dispositivo de acesso, como PC ou WAP, e um exemplo de

30 adaptação dinâmica é a exibição de uma animação para acessos em banda larga e imagem para acessos dial-up. Kappel et al. (2001) apresentam também, considerando as dimensões apresentadas, um estudo comparativo entre duas abordagens de modelagem web; WebML e OOHDM que, segundo os autores, atendem à natureza onipresente da web, diferentemente da maioria das abordagens existentes, que focam em uma única característica. Para maiores detalhes sobre a comparação, consulte Kappel et al. (2001). 2.5. Conclusões Finais Este capítulo apresentou uma descrição sobre o cenário atual do desenvolvimento de sistemas web e as necessidades que levaram ao surgimento de uma nova disciplina, a engenharia web, como uma tentativa de padronizar e agilizar a forma como sistemas web são desenvolvidos. Foram apresentadas também as características consideradas relevantes no desenvolvimento desse tipo de sistema, algumas das quais não se aplicam aos sistemas tradicionais. Apresentou-se também uma breve apresentação das abordagens existentes e estudos comparativos entre essas abordagens, considerando as funcionalidades importantes para sistemas web.

31 3. WebML 3.1. Introdução A WebML é uma notação para especificação de Web sites complexos em um nível conceitual. Isto significa que a WebML é uma linguagem de modelagem que procura representar web sites complexos de uma maneira que seja independente de plataforma, linguagem de programação ou tecnologia. Essa representação é feita através de notações gráficas e XML. Ceri et. al. (2000) afirmam que os conceitos da WebML estão associados com uma representação gráficas intuitiva e formais, que podem ser facilmente apoiados por ferramentas CASE e efetivamente comunicado para membros não técnicos da equipe de desenvolvimento. De acordo com WebRatio Team (2002), o principal objetivo da WebML é: (a) expressar a estrutura da aplicação web com uma descrição de alto nível; (b) fornecer múltiplas visões do mesmo conteúdo; (c) separar o conteúdo da informação da sua composição, navegação e apresentação nas páginas, podendo ser definido independentemente; (d) armazenar meta-informações coletadas durante o processo de desenvolvimento dentro de um repositório, que pode ser usado durante o tempo de vida da aplicação para, dinamicamente, gerar páginas web; (e) modelar usuários e grupos explicitamente, permitindo a especificação de aplicações personalizadas; (f) possibilitar a especificação de operações de manipulação de dados para atualização do conteúdo do site ou interação com serviços externos. A WebML procura descrever web sites através de 4 dimensões: Modelo de estruturas: expressa o conteúdo dos dados do site em termos de entidades relevantes e relacionamentos. Equivalente a representações como diagrama entidade-relacionamentos e diagramas de classe. Modelo de Hipertexto: descreve um ou mais hipertextos que podem ser publicados no site. Cada hipertexto diferente define uma visão no site. A descrição da visão do site consiste de dois sub-modelos 1. Modelo de composição: especifica quais páginas compõem o hipertexto e quais unidades de conteúdo fazem parte da página.

32 2. Modelo de navegação: expressa como as páginas e o conteúdo dos dados estão ligados no hipertexto. Modelo de apresentação: define o layout e aparência gráfica das páginas, independentemente do dispositivo de saída ou da linguagem de renderização. Pode ser específico de uma página ou genérica para um grupo de páginas. Modelo de personalização: representação das características específicas de um usuário ou grupo através de entidades predefinidas no diagrama de estruturas, ou através de expressões OQL-like adicionadas ao esquema de estruturas, definindo características do perfil de um usuário ou grupo específico. 3.2. Modelo de estrutura O modelo de estruturas da WebML define os dados da aplicação e seus relacionamentos, através de uma representação equivalente ao diagrama entidaderelacionamento. Ceri et. al. (2001) afirmam que o objetivo da modelagem de dados é possibilitar a especificação dos dados de uma maneira intuitiva e formal. O resultado da modelagem de dados é um esquema conceitual que resulta em uma representação simples e legível do conhecimento sobre a aplicação. Desenvolver tal esquema é útil tanto para o desenvolvedor de funções de negócio, que opera os dados quanto para o desenvolvedor da estrutura física de suporte ao armazenamento, atualização e recuperação dos dados. 3.2.1. Entidades Entidade é o conceito central do modelo entidade-relacionamento. Uma entidade representa a descrição de características comuns de um conjunto de objetos do mundo real. Uma entidade tem uma população, que é o conjunto de objetos que são descritos pela entidade. Esses objetos são também chamados instâncias da entidade. As entidades, no modelo entidade-relacionamento, podem ser representadas através de um retângulo, com o nome da entidade no topo seguido de uma lista de atributos, conforme a Figura 3.1

33 Figura 3.1. Exemplo da representação de entidades e seus atributos Os atributos representam as propriedades dos objetos do mundo real, que são relevantes à aplicação. Entidades são compostos de atributos, que representam as propriedades das instâncias de uma entidade. Toda entidade deve possuir uma chave que o identifica como sendo único na aplicação. Essa chave pode ser um ou mais atributos da entidade. A chave de identificação do objeto nunca poderá ser nula e seu valor deve ser único. A Figura 3.2 assume a propriedade OID (object identifier) como sendo a chave primária das entidades. Um atributo deve ser tipado, ou seja, deverá ser definido para cada atributo da entidade o tipo de informação que ela armazena. Um atributo pode armazenar números, seqüências de caracteres, datas, arquivos, imagens etc. Entidades podem também ser definidas através de hierarquias de generalização, que representam o relacionamento é um entre entidades. Isso significa que duas entidades semelhantes podem generalizar suas características comuns através de uma super entidade e manter suas características particulares. A Figura 3.2 ilustra um exemplo de hierarquia entre entidades. Figura 3.2. Exemplo de hierarquia entre entidades

34 3.2.2. Relacionamentos Um relacionamento representa uma ligação semântica entre duas entidades. Na modelagem entidade-relacionamento, um relacionamento é representado por uma linha que liga duas ou mais entidades. Um relacionamento pode receber um nome, para melhor clareza sobre a relação. 3.3. Modelo de hipertexto O objetivo da modelagem de hipertextos é especificar a organização das interfaces de front-end de uma aplicação web. Para ser eficiente, tal especificação deve ser capaz de representar de uma maneira simples e intuitiva as divisões lógicas da aplicação em módulos, cada um incorporando um conjunto coerente de funcionalidades atendendo a um conjunto específico de necessidade do usuário. Deve também representar a topologia de hipertextos real desses módulos, em termos de páginas, com os elementos do conteúdo e as ligações e navegação entre essas páginas. A WebML representa as características de hipertexto de uma aplicação web através de três instrumentos de representação chave, que são as páginas, unidades e links, que são organizados em módulos, representados por visões e áreas. 3.3.1. Modelo de Composição No modelo de composição são especificados os dados que deverão ser exibidos no web site e a organização desses dados dentro de uma página. A WebML propõe essa organização através da especificação de áreas, site views, páginas e unidades. 3.3.1.1. Unidades Unidades são elementos atômicos para a especificação do conteúdo de uma página web. A WebML suporta cinco tipos de unidades, que são unidades de dados, unidades de

35 dados múltiplos, unidades de índice, unidades de rolagem e unidades de entrada, que são discutidos detalhadamente a seguir. Unidades de dados De acordo com Ceri et. al. (2000), unidades de dados selecionam uma mistura de informações que fornecem uma visão significativa de um determinado conceito no esquema de estruturas. Uma entidade pode ser representada por mais de uma unidade de dados, para que várias visões de uma mesma entidade possam ser representadas. Uma unidade de dados é caracterizada através do nome da unidade, da entidade que representa, dos atributos do objeto e de um seletor opcional que identifica unicamente um objeto. A Figura 3.3 exemplifica uma entidade representada pela notação XML. A tag DATAUNIT define uma unidade de dados, onde são especificados o nome da unidade e a entidade que representa. Entre as tags DATAUNIT são definidos os atributos da entidade, através da tag INCLUDE, que define o nome do atributo. A tag INCLUDEALL indica que todos os atributos da entidade serão adicionados a essa unidade de dados. Figura 3.3. Representação XML de uma entidade de dados A Figura 3.4 ilustra a representação gráfica para uma unidade de dados. Dentro do quadrado é exibido o nome da unidade; logo abaixo, a entidade que esta representa seguido pelo seletor único que identifica o objeto a ser exibido. No exemplo, uma instância da entidade artista cujo primeiro nome é Celine e o sobrenome é Dion.

36 Figura 3.4. Notação gráfica para unidade de dados Unidades de dados múltiplos Unidade de dados múltiplos representam agrupamentos de instâncias de uma entidade ou de componentes, que serão apresentados de maneira idêntica. Uma unidade de dados múltiplos contém duas partes, 1) um container que inclui as instâncias da entidade, relacionamento ou componente a ser exibido e 2) a unidade de dados contendo as informações que serão exibidas. Sintaticamente, uma unidade de dados múltiplos é representada pela tag MULTIDATAUNIT que é composta pelo nome da unidade e a entidade, relacionamento ou componente que representa. Delimitado pela tag MULTIDATAUNIT, é definida uma unidade de dados contendo as informações que serão exibidas. A Figura 3.5 ilustra essa representação: Figura 3.5. Representação XML de uma unidade de dados múltiplos A Figura 3.6 exibe a notação gráfica, segundo a WebML, para representar uma unidade de dados múltiplos. Dentro do quadrado é especificado o nome da unidade e no ícone abaixo a entidade que está sendo representada.

37 Figura 3.6. Notação gráfica para unidades de dados múltiplos Unidades de índice Unidades de índice são responsáveis por apresentar uma lista de instâncias de uma determinada entidade, sem apresentar detalhes dessa entidade. São compostos por duas partes: 1) O container contendo as instâncias a serem exibidas e 2) um atributo usado como índice da entidade na lista. Na representação sintática, um elemento INDEXUNIT representa a unidade de índice, e deve definir o nome da unidade, a entidade que representa e o atributo que será usado como índice, definida pelo elemento DESCRIPTION através do atributo key, entre as tags INDEXUNIT. Figura 3.7. Representação textual para unidades de índice Na notação gráfica, mostrada na Figura 3.8, o nome da unidade é apresentado dentro do quadrado e a entidade que representa segue o ícone, logo abaixo do quadrado. Figura 3.8. Notação gráfica para unidades de índice

38 Unidades de rolagem Uma unidade de rolagem possibilita a navegação entre um conjunto de objetos de um container. Define-se o nome da unidade, a entidade que representa e um seletor opcional que restringe o conjunto de objetos através de uma restrição. O elemento SCROLLERUNIT define uma unidade de rolagem, ilustrado na Figura 3.9. A notação gráfica é exibida na Figura 3.10. Figura 3.9. Notação textual para unidade de rolagem Figura 3.10. Notação gráfica para unidades de rolagem Unidades de entrada Unidades de entrada representam entrada de dados através de formulários. A entrada de dados pelo usuário é normalmente requerida para operações de pesquisa ou autenticação de usuários. A Figura 3.11 apresenta a notação gráfica para a unidade. Figura 3.11. Notação gráfica para unidades de entrada

39 Figura 3.12. Notação gráfica para unidades de entrada Unidades de operação Unidades de operação são usadas para representar a utilização de serviços genéricos disponibilizados por páginas externas através de web services ou para o gerenciamento e atualização de conteúdo pré-construído, como criação, exclusão de instâncias de uma entidade por exemplo. Uma unidade de operação recebe uma informação de entrada, através de um ou mais links, sendo um deles declarado como operation-activating, que provoca a execução da operação. A Figura 3.13 e 3.14 ilustram as representações gráfica e XML da unidade de operação, respectivamente Figura 3.13. Representação gráfica de unidade de operação Figura 3.14. Representação XML de unidade de operação 3.3.1.2. Páginas Páginas são os elementos da interface exibidos para o usuário. Uma página pode conter várias unidades agrupadas. Uma página é representada, na WebML, através de um

40 retângulo, com o nome da página localizado na parte superior. Delimitado pelo retângulo, são especificados os elementos que serão exibidos nessa página, conforme Figura 3.15. Figura 3.15 Notação gráfica de uma página 3.3.2. Modelo de Navegação O modelo de navegação procura representar os links entre unidades e páginas e as propriedades desses links, ou seja, procura definir a navegação que deve existir entre as páginas do web site. Um link representa o conceito de âncoras num web site. Ceri et. al. (2003) definem que a noção central da modelagem de navegação são os conceitos de links, parâmetros de links e seletores de links. Links que ultrapassam os limites das páginas são chamados inter-páginas e links cuja origem e destino estão na mesma página são chamados intra-páginas. Os links podem também ser classificados de acordo com a informação transferida: Ligação contextual: conectam páginas de maneira coerente para expressar relação semântica entre as entidades, modelados através do modelo de estruturas. Ligação não-contextual: conectam páginas sem nenhuma ligação semântica. Links são graficamente representados através de setas direcionadas da origem para o destino. A Figura 3.16 exemplifica um link contextual. Dependendo do item selecionado na listagem de álbuns, um elemento de dados é exibido.

41 Figura 3.16 Exemplo de ligação contextual Links contextuais transmitem parâmetros entre as páginas. Algumas regras sumarizam as informações de contexto que fluem através das unidades, são elas: Unidades de dados: o identificador do objeto correntemente mostrado na unidade; Unidade de índice: o valor chave selecionado na lista; Unidade de rolagem: o identificador do objeto selecionado pelo comando de rolagem; Unidade de dados múltiplos: a informação de contexto associada com a unidade de dados alinhada na unidade. A WebML introduz também o conceito de parâmetros globais. De acordo com Ceri et. al. (2003), um parâmetro global é um pedaço de informação que pode ser explicitamente definido em algum ponto da aplicação e recuperado em qualquer ponto da navegação do hipertexto. Um parâmetro global é um atributo visível em qualquer ponto da aplicação e normalmente é definido na sessão do usuário. A declaração de um parâmetro global requer a definição das seguintes propriedades: O nome do parâmetro; O tipo de valor armazenado; Um possível valor padrão para o parâmetro. O valor de um parâmetro é associado a uma unidade de ajuste (set unit). Um set unit tem um link de entrada, que é associado com um parâmetro de link, que ajusta o valor do parâmetro global. Graficamente, um set unit é localizado fora das páginas, uma vez que deve ser visível por todas as outras páginas. Para recuperar uma informação de um parâmetro global, são utilizadas unidades de recuperação (get unit). Um get unit não possui um link de entrada de dados, somente de

42 saída, por onde transmite o valor do parâmetro. Get units são localizadas dentro das páginas que utilizam o valor global, para denotar a recuperação do parâmetro global. 3.3.3. Organização de hipertextos Uma representação de hipertextos pode ser organizada de forma hierárquica, usando modularização, através do conceito de visões de site (site views) e áreas: Site views: pacote que engloba páginas e links do hipertexto, de forma modular. Áreas: containers de páginas que delimitam o conteúdo de um site view de maneira hierárquica. Páginas de um hipertexto podem também ser organizadas de acordo com sua importância dentro do web site. Home page: página principal carregada ao acessar o endereço do site. Deve ser única dentro do web site e pode ser representada graficamente por um H dentro da página. Default page: página exibida por padrão ao acessar uma determinada área do web site. Representada graficamente por um D dentro da página. Deve ser única dentro de uma área. Landmark: página principal de uma determinada área ou site view. Todas as páginas que pertencem à área, ou site view, possuem uma ligação implícita à página de landmark. Representada graficamente por um L dentro da página, e único por área ou site view. A Figura 3.17 exemplifica os conceitos de home page, landmark e default page, além de exibir páginas relacionadas ao contato com usuários delimitados por uma área, nomeada contato.

43 Figura 3.17 Exemplos de landmark, home page, default page e área. 3.4. Modelo de apresentação O modelo de apresentação define o layout e a aparência gráfica das páginas da aplicação, conforme definidos no modelo de composição. De acordo com Ceri et. al. (2000) páginas WebML são renderizadas de acordo com uma folha de estilos. Uma folha de estilos define o layout das páginas e os elementos do conteúdo a serem inseridos em tais páginas, independentes da linguagem utilizada no desenvolvimento. Duas categorias de folhas de estilos foram definidas na WebML: folhas de estilo não tipadas (também chamadas modelos) descrevem páginas de layout independente do seu conteúdo, e folhas de estilo tipadas, que são específicas para páginas de determinado conteúdo. 3.5. Modelo de personalização A WebML procura modelar um web site considerando também o tipo de usuário que irá acessar o sistema. O acesso ao site pode ser feito por usuários registrados, com preferências específicas, ou por visitantes casuais não identificados pelo sistema. A WebML distingue essas duas classes como usuários registrados e não registrados, respectivamente. Além dessa distinção, a WebML classifica também as visões do site,

44 como protegidas, que poderão ser acessadas apenas por usuários registrados, e visões públicas, acessíveis por qualquer visitante. A WebML modela tais características de personalização através da definição de usuário, grupo, site view e o relacionamento semântico entre esses elementos. O modelo de estruturas para sistemas que incluem restrições de acesso às visões do site deve incluir o esquema básico, conforme Figura 3.18, podendo ser acrescentadas características adicionais, se necessário: Figura 3.18 Esquema básico para representação de aplicações com restrição de acesso a visões do site. 3.6. Modelo de derivação Além das dimensões identificadas anteriormente, a WebML utiliza uma forma de representação dos dados através de derivação. De acordo com Ceri et. al. (2001), derivação é o processo de adicionar informações redundantes no esquema de estruturas para aumentar sua expressividade e definir diferentes visões do mesmo dado. A derivação é formalmente expressa através de uma linguagem de consulta, chamada WebML-OQL. 3.6.1. WebML OQL A WebML-OQL é expressa pela seguinte gramática: <DIGIT: ["0"-"9"]> <LETTER: [ "\u0024", "\u0041"-"\u005a", "\u005f", "\u0061"-"\u007a", "\u00c0"-"\u00d6", "\u00d8"-"\u00f6", "\u00f8"-"\u00ff", "\u0100"-"\u1fff", "\u3040"-"\u318f", "\u3300"-"\u337f", "\u3400"-"\u3d2d", "\u4e00"-"\u9fff", "\uf900"-"\ufaff" ]> <STRING: "\ " (<LETTER> <DIGIT> "@" " " "!" "?" "#" "$" " " "%" "/" "^" " " "[" "]" "," ";" "." ":" "_" "-" "+" "*" " " " Y")+ "\ ">

45 <NUMBER: (<DIGIT>)+ ("." (<DIGIT>)+)?> <IDENTIFIER: (<LETTER>)+ ("_" ":" <DIGIT> <LETTER>)*> <OPERATOR: "+" "-" "/" "*"> <COMPARATOR: "<" "<=" "=" "!=" "<>" ">=" ">" "contains" "beginswith" "endswith"> <AGGRFUNCTION: "min" "max" "avg" "sum" "count"> <SELF: "Self"> <AND: "AND"> <OR: "OR"> <WHERE: "WHERE"> <ISA: "ISA"> <NOT: "NOT"> <IN: "IN"> <TO: "TO"> <IS: "IS"> <AS: "AS"> <NULL: "NULL"> <TRUE: "TRUE"> <FALSE: "FALSE"> <LEFTBRACKET: "("> <RIGHTBRACKET: ")"> <DOT: "."> <EntityQuery : Step <WHERE> Condition ( ";" <EOF> )> <RelationshipQuery : ( <SELF> <TO> Step PathExpression ) ( <WHERE> Condition )?( ";" <EOF> )> <AttributeQuery : AttributeValue ( <WHERE> Condition )? ( ";" <EOF> )> <Step : <IDENTIFIER> ( <LEFTBRACKET> <AS> <IDENTIFIER> <RIGHTBRACKET> )?> <PathExpression : ( <SELF> <IDENTIFIER> ) ( <DOT> Step )*> <AttributeValue : ( AttributeExpression <LEFTBRACKET> AttributeValue <RIGHTBRACKET> ) ( <OPERATOR> ( AttributeExpression <LEFTBRACKET> AttributeValue <RIGHTBRACKET> ) )*> <AttributeExpression : ( <STRING> <NUMBER> PathExpression <AGGRFUNCTION> <LEFTBRACKET> PathExpression <RIGHTBRACKET> )> <Member : ( <NOT> )? <IN> PathExpression> <IsNull : <IS> ( <NOT> )? <NULL>> <WhereExpression : ( ( <IDENTIFIER> <SELF> ) <ISA> <IDENTIFIER> AttributeExpression ( Member IsNull <COMPARATOR> ( AttributeExpression <TRUE> <FALSE> ) ) ( <LEFTBRACKET> Condition <RIGHTBRACKET> ) )> <LogicalTerm : WhereExpression ( <AND> WhereExpression )*> <Condition : LogicalTerm ( <OR> LogicalTerm )*> 3.6.2. KeyWords, predicados e operadores A palavra chave ISA denota um predicado que permite checar a presença de um elemento dentro de uma sub-entidade. O operador + é uma sobrecarga: ele denota operações de adição para números e concatenação de strings. A palavra chave SELF representa o conceito de esquema de dados que está sendo derivado ou estendido.

46 3.6.3. Expressões de início As consultas de derivação podem ser de três tipos: EntityQuery, RelationshipQuery e AttributeQuery, seguidos pelos respectivos símbolos de terminação. Uma derivação de relacionamento pode ser de dois tipos: consultas que expandem o símbolo PathExpression, permitindo a definição de relacionamentos que incluem um subconjunto de um determinado conjunto de relacionamentos; consultas que expandem o símbolo <SELF> <TO>, que expressa relacionamentos compreendendo pares arbitrários de objetos que satisfaçam a uma determinada condição. 3.6.4. Passos da navegação e valores de atributos Os valores ATTRIBUTEVALUE e ATTRIBUTEEXPRESSION permitem expressar termos calculados, aplicando funções de agregação e operações aritméticas para definir atributos locais ou de outras entidades representado através de um PATHEXPRESSION. 3.6.5. Condições Representadas pelo elemento CONDITION, que permite expressar condições através de conectores AND e OR. Sub-fórmulas podem ser adicionadas em elementos CONDITION através do elemento WHEREEXPRESSION. 3.6.6. Atributos derivados Atributos podem ser derivados de quatro maneiras: Atributos importados: denotam pedaços de informações retiradas de outras entidades. Atributos calculados: valor do atributo é calculado através de outros atributos. Atributos agregados: valor obtido através da aplicação de alguma função da linguagem, tal como a função count, que conta o número total de ocorrências de

47 uma determinada consulta. Atributos constantes: conteúdo fixo para o atributo. 3.6.7. Entidades derivadas Aplicadas para definição de sub-entidades, que correspondem a uma população de uma determinada entidade que atende a algum critério de busca. Por exemplo, a consulta a seguir cria uma sub-entidade englobando somente artistas italianos: ArtistasItalianos = Artistas AS A WHERE A.nacionalidade contains Italia ; 3.6.8. Relacionamentos derivados Papéis de relacionamentos podem ser derivados de uma consulta WebML - OQL de duas formas: redefinindo ou concatenando relacionamentos existentes ou associando pares de objetos através de uma condição. Em ambos os casos, o elemento SELF denota o objeto origem do relacionamento.

48 4. Estudo de caso 4.1. Visão Geral O sistema de gestão para entidades de classe (SGEC) atende às várias atividades de uma entidade de classe. Entidades de classe podem ser definidas como uma sociedade de empresas ou pessoas com forma e natureza jurídica próprias, de natureza civil, sem fins lucrativos e não sujeita a falência, constituídos para prestar serviços aos seus associados. Entidades de classe podem ser confederações, federações, associações, sindicatos, cooperativas, entidades profissionais etc. O SGEC é direcionado principalmente a sindicatos e consiste, basicamente, no cadastro de empresas ou pessoas que desejam ser representada pela entidade; controle de recebimentos de taxas sindicais cobradas de seus filiados e outras taxas existentes em um sindicato. O sistema também controla a locação de recursos disponibilizados pelo sindicato aos seus filiados, como chácara de recreação, auditórios para reuniões e bibliotecas, entre outros. A Figura 4.1 ilustra o diagrama de casos de uso do sistema. Um sindicato é formado por pessoas ou empresas, denominados representados, que podem optar por associar-se ao sindicato ou apenas ser representado por ele. Um representado que se associa ao sindicato, denominado associado, abrirá um contrato de associado e passará a pagar taxas mensais e uma contribuição anual obrigatória, denominada contribuição sindical e prevista em lei. Através desse contrato, o associado, além de usufruir da representação de seus interesses através do sindicato, poderá utilizar alguns recursos tais como, locação de chácaras de recreação, auditórios para reuniões, anúncios no jornal do sindicato, etc. Um representado que opta por não se associar ao sindicato, denominado contribuinte, abrirá um contrato de contribuinte com o sindicato e pagará, além da contribuição sindical anual obrigatória, uma taxa semestral, denominada reversão patronal, que visa custear as atividades do sindicato. Um contribuinte poderá também utilizar os recursos do sindicato mediante pagamento de taxas que variam conforme o tipo de recurso. Os recursos disponibilizados pelo sindicato, assim como seus valores, são definidos pela diretoria. Além das atividades de gestão do sindicato, o sistema SGEC deverá suportar o

49 acesso de usuários em diferentes grupos de acesso, que poderão ter acesso restrito a determinados módulos do sistema, tais como grupo de cadastro que somente poderá cadastrar representado, sem permissão de modificação à área financeira etc. Outros grupos poderão ter acesso incondicional ao sistema, tal como o grupo de administradores do sistema. Figura 4.1 Diagrama de use case

50 4.2. Modelo de estrutura O modelo de estruturas procura representar os dados do sistema na forma de entidades e relacionamentos. Conforme mencionado anteriormente na Seção 3.2, a WebML define uma maneira de representação dos dados compatível com modelos já bastante conhecidos e difundidos tais como modelo entidade-relacionamento e diagrama de classes. A Figura 4.2 ilustra um modelo de estruturas inicial para o SGEC. Figura 4.2: Diagrama de estruturas para o SGEC Uma pessoa, que pode ser tanto física quanto jurídica, poderá tornar-se um contribuinte do sindicato. Para tornar-se representado, uma pessoa deverá abrir um contrato e optar por tornar-se associado ou contribuinte. Cada representado poderá abrir mais de um contrato, contanto que em períodos distintos. Um representado poderá abrir um contrato de associado por um determinado período e depois optar por tornar-se apenas um contribuinte ou vice-versa, assim, ao invés de modificar o contrato, o representado abrirá um outro contrato como contribuinte. Um contrato implica na geração de taxas, que pode

51 ser de três tipos, sendo que cada tipo terá um período de geração (por exemplo, mensal, semestral, anual) e valores diferentes. Durante a vigência do contrato várias taxas serão geradas. Um contrato também poderá implicar na geração esporádica de cobranças diversas, pela utilização de recursos disponibilizados pelo sindicato. Um contrato poderá possuir várias cobranças durante sua vigência, uma cobrança, ao contrário deverá pertencer a apenas um contrato e jamais poderá existir sem estar associado a um contrato. O diagrama representa também os dados relacionados ao controle de acesso dos usuários ao sistema. A WebML define por padrão três entidades para representação do controle de acesso do sistema, usuários, grupos e módulos. Um usuário pertence a um ou mais grupos, que poderão ter acesso a um ou mais módulos do sistema. Os usuários cadastrados ao sistema poderão pertencer a pelo menos um grupo, podendo participar de mais de um grupo ao mesmo tempo. Cada grupo terá acesso a um ou mais módulos do sistema. Um módulo poderá ser acessado por mais de um grupo e um grupo poderá ter mais de um usuário associado. 4.3. Modelagem de Hipertexto A modelagem de hipertexto procura representar de forma abstrata a camada de apresentação de um sistema data-intensive. Através dessa modelagem características específicas de sistemas web, tais como fluxo de navegação de páginas e forma de exibição dos dados, podem ser representados sem especificar uma linguagem de programação específica. A WebML permite também especificar o conteúdo a ser exibido para cada grupo de usuários, de acordo com as permissões de acesso de cada módulo do sistema, através do diagrama de site view. 4.3.1. Identificação de Site Views Podemos identificar primariamente dois tipos de visões diferentes, usuários identificados e usuários anônimos. A priori todos usuários que acessam o sistema podem

52 ser considerados usuários anônimos e são direcionados à página de login, onde fornecerão um login e uma senha para tentar entrar no sistema. A página de login ativa a operação de login que compara as informações contidas no banco de dados com as fornecidas pelo usuário. Se a operação for bem sucedida, ou seja, se o usuário for autenticado, ele será direcionado a tela de menu do site e uma variável global contendo as informações do usuário será registrada. Note que, a variável global procura representar o conceito de sessão do usuário, ou seja, uma informação que será armazenada durante todo o tempo em que o usuário se mantiver ativo no sistema. Caso a operação não seja bem sucedida, o usuário será reenviado para a pagina de login através de um link de erro. Figura 4.3 Operação de login Uma vez que o usuário tenha sido identificado, este será redirecionado para um menu contendo links para os módulos aos quais tem acesso. Caso o usuário pertença ao grupo de administradores de sistema, seu acesso será ilimitado, podendo inclusive alterar informações de outros usuários. Um usuário comum, ao contrário, não poderá acessar informações de outros usuários, mas poderá acessar e alterar suas próprias informações. A Figura 4.4 ilustra a operação de alteração de dados pessoais para usuários autenticados.

53 Figura 4.4 Alteração de dados pessoais 4.3.2. Modelagem das funcionalidades A Figura 4.5 ilustra o caso de uso de cadastrar representado. Esse caso de uso engloba as ações de inclusão de um novo representado, atualização de um registro já existente, remoção e consulta dos representados já cadastrados. Figura 4.5. Modelagem do controle de representados

54 As ações relacionadas à entidade representado foram englobadas em uma área chamada cadastro representado. Dentro desta área foram definidas quatro páginas, sendo a página menu de representados a página default. Sempre que um usuário desejar realizar alguma operação relacionada à entidade representado acessará a página de menu e escolherá a operação desejada através de uma lista de ações, representada através de uma unidade de índice. A página de menu foi também definida como landmark, o que indica que todas as páginas dessa área podem acessar, através de um link não contextual, essa página. A página novo representado contém uma unidade de entrada, representando um formulário contendo todos os dados que precisam ser preenchidos para um novo representado. A página pesquisa de representados contém as ações de busca de registros. A unidade de entrada no topo da página indica a possibilidade de fornecer um parâmetro de pesquisa para filtrar os registros. Depois de informado o parâmetro de pesquisa, uma operação de busca é acionada, redirecionando o usuário à mesma página, mas agora contendo a lista de representados, ilustrada pela unidade de índice, que satisfazem o parâmetro fornecido anteriormente. A lista de representados contém uma indicação na parte inferior de que a lista contém apenas objetos da entidade representado. Através desta lista pode-se escolher um dos objetos que redirecionará o usuário para os dados do representado selecionado, indicado pela unidade de dados na página informações representado. A Figura 4.6 ilustra as operações de criação, remoção, pesquisa e alteração de contratos.

55 Figura 4.6. Modelagem de cadastro de contratos As operações sob a entidade contrato são bastante parecidas com as descritas em representados, diferindo apenas na relação que um contrato deve manter com um representado. Ao criar um novo contrato, deve-se indicar o representado no qual o contrato pertence. Para encontrar o representado desejado, o usuário é redirecionado à página de pesquisa de representados, onde poderá escolher o objeto desejado. O usuário pode optar também por criar um novo contrato a partir da página de informações do representado. Através da página de informações de contrato, o usuário poderá navegar para a página de informações do representado que está associada ao contrato. A Figura 4.7 apresenta a modelagem do caso de uso gerar taxas. Nesse caso de uso, são apresentadas as funcionalidades básicas de inserção, remoção e pesquisa de taxas, que são similares às funcionalidades de outras entidades apresentadas anteriormente. Porém, a entidade taxas possui uma clara ligação com um contrato. Uma taxa não existe sem que esteja associada a um contrato. Ao criar uma nova taxa, devemos especificar um contrato associado a ele. Para tanto, podemos realizar uma pesquisa na página de pesquisa de contratos e localizar o contrato desejado. Perceba que, ao consultar as informações de um determinado contrato, as taxas existentes daquele contrato são exibidas automaticamente.

56 O sistema permite que o usuário possa navegar entre as páginas de diversas formas. Podemos localizar um contrato partindo de uma taxa, associada a ele; podemos localizar uma taxa através do contrato; podemos localizar um representado através de seu contrato etc. Figura 4.7 Modelagem de geração de taxas Outras funcionalidades identificadas no diagrama de estrutura não foram apresentadas nessa seção por conter composição semelhante às já apresentadas, sendo portanto considerado desnecessário sua apresentação. 4.4. Avaliação final sobre a utilização da WebML A WebML é uma linguagem bastante interessante tanto para modelagem de sistemas web quanto para web pages. Entende-se por web pages páginas simples de conteúdo apenas informativo e sistemas web como sinônimo para aplicações web, sistemas data intensive, sistemas baseados em web. A modelagem de estruturas da linguagem não apresenta grandes novidades, uma vez que utiliza definições da modelagem entidade-relacionamento, já bastante conhecida e