Você está na página 1de 102

UNIVERSIDADE FEDERAL DE SANTA CATARINA Centro Tecnolgico Departamento de Informtica e de Estatstica

ESTUDO DA METODOLOGIA ORIENTADA A OBJETOS OOHDM, PARA A MODELAGEM E DESENVOLVIMENTO DE WEBSITES

Orientador: Prof. Vitrio Bruno Mazzola, Dr. Aluno: Jean Carlos Hennrichs

Florianpolis Santa Catarina - Brasil Fevereiro de 2005

JEAN CARLOS HENNRICHS

ESTUDO DA METODOLOGIA ORIENTADA A OBJETOS OOHDM, PARA A MODELAGEM E DESENVOLVIMENTO DE WEBSITES

Trabalho de Monografia apresentado ao Departamento de Informtica e de Estatstica (CTC) rea de Cincia da Computao da Universidade Federal de Santa Catarina (UFSC), como requisito para obteno do Ttulo de Especialista em Cincia da Computao.

Orientador: Prof. Vitrio Bruno Mazzola, Dr.

Florianpolis Santa Catarina - Brasil Fevereiro de 2005

Assim como todos que vivem para ver esses tempos, mas que no cabe a eles decidir, temos apenas de decidir o que fazer com o tempo que nos dado Gandalf Lord of the Rings.

AGRADECIMENTOS

Primeiramente gostaria de agradecer a Deus por ter me guiado por mais esse caminho em minha vida. Muito agradeo aos meus pais por terem me ensinado a ter perseverana e pacincia para aguardar os momentos oportunos que surgem frente para serem vencidos. A minha me, Ivete Fontana, o mais respeitoso afeto que um filho pode oferecer. A meu pai, Jos Carlos Hennrichs, que no se faz mais presente em corpo, mas sempre presente em minha memria, obrigado. Um agradecimento muito especial a minha esposa e companheira Noeli S. Kirschner, que me apoiou e esteve sempre presente. A todos meus colegas, os novos e os antigos, em especial: Eduardo Urnau, Elton Minetto, Luciano Frosi, Michel Kniphoff e Tiago Zonta. Sem sombra de dvida, os momentos que vivenciamos juntos durante este perodo nunca mais sero esquecidos. Agradeo ao professor e orientador Sr. Vitrio Bruno Mazzola, pela oportunidade que me foi concedida, e lembr-lo que realmente foi um prazer t-lo como professor. Lembro ainda que muitos professores passam em nossa vida, mas somente aqueles que nos marcam com atitudes e parcerias se mantm vivos em nossas lembranas. Agradeo tambm ao coordenador da ps o professor Rogrio Hining, ao professor Roque Strieder por algumas palavras especiais dirigidas a minha pessoa, e a todos que direta ou indiretamente contriburam na elaborao deste trabalho.

RESUMO

A Internet que originou-se inicialmente de um projeto militar atualmente um dos principais meios de divulgao de informao do mundo. Mas nem sempre fora assim. No incio da Internet as pginas no passavam de meras descries textuais estticas que somente tomaram corpo com o surgimento do hipertexto e posteriormente com a WWW. A World Wide Web (WWW), deu vida a Internet, tornando possvel a exibio no s de textos, mas tambm de imagens. Com esta modernizao da Internet os sites que eram apenas estticos, exibindo informaes, passaram a interagir com o usurio. Aplicaes que antes rodavam apenas em ambiente corporativo foram disponibilizadas na Web. Contudo no levou-se em considerao como essas informaes e aplicaes deveriam ser desenvolvidas. Burlou-se todo o processo de desenvolvimento de software e avanou-se direto para a implementao, deixando de lado a mais importante de todas as fases no ciclo de desenvolvimento de software, a engenharia. Este trabalho descreve o estudo de um mtodo de engenharia para o desenvolvimento de Websites. O mtodo estudado e apresentado nesta monografia o OOHDM (Object Oriented Hypermedia Design Method), ou modelo de design hipermdia orientado a objetos. Inicialmente faz-se uma abordagem de conceitos elementares que so necessrios para o entendimento desta monografia. Dando seqncia o mtodo OOHDM descrito, tomando como referncia autores chaves que pesquisam o mtodo. Todas as cinco etapas do OOHDM (Levantamento de Requisitos, Modelagem Conceitual, Modelagem Navegacional, Projeto de Interface Abstrata e Implementao), so apresentadas de forma clara e quando possvel atravs de exemplos grficos, esquemas e diagramas.

ABSTRACT

The Internet that was born initially as a military plan is now one of the main mean of distribution of information of the world. But it has not been always like that. In the starting of Internet the home pages didn't pass of mere static textual descriptions growing with the appearance of the hypertext and later with WWW. World Wide Web (WWW) gave life to Internet, turning possible the exhibition not only of texts, but also of images. With this modernization Internet sites that just exhibited information, started to interact with the user. Applications that before just ran in environment corporation were available in the Web. However it was not taken in consideration as those information and applications should be developed. It was left behind the process of software development that was moved forward straight to the programming, forgetting of the most important of all the phases in the cycle of software development: the "engineering". This work describes the study of an engineering method for the development of Websites. The studied and presented method in this monograph is the OOHDM (Object Oriented Hypermedia Design Method). It is made an approach of elementary concepts that are necessary for the understanding of this monograph. In sequence the method OOHDM is described, taking into reference famous authors that research the method. All the five stages of OOHDM (Rising of Requirements, Conceptual Modeling, Navigation Modeling, Project of Interface Abstract and Implementation), are described in a clear away and when possible through graphic examples, schemes and diagrams.

SUMRIO LISTA DE FIGURAS..........................................................................................................9 LISTA DE ABREVIATURAS..........................................................................................12 1 INTRODUO...............................................................................................................13 1.1 OBJETIVOS ..............................................................................................................14 1.1.1 Objetivo Geral...................................................................................................14 1.1.2 Objetivos Especficos ........................................................................................14 1.2 ESTRUTURA DO TRABALHO ..............................................................................14 2 MULTIMDIA X HIPERMDIA ..................................................................................16 2.1 MULTIMDIA...........................................................................................................16 2.1.1 Objetos Multimdia...........................................................................................17 2.1.1.1 Texto ............................................................................................................17 2.1.1.2 udio ...........................................................................................................17 2.1.1.3 Imagens ........................................................................................................17 2.2 HIPERTEXTO...........................................................................................................18 2.3 HIPERMDIA............................................................................................................18 2.4 HIPERDOCUMENTOS ............................................................................................19 3 WEBSITES E WEB DATABASES...............................................................................21 3.1 WEB...........................................................................................................................21 3.1.1 Website...............................................................................................................22 3.1.1.1 Sites Estticos ..............................................................................................23 3.1.1.2 Sites Dinmicos ...........................................................................................23 3.1.2 Web Databases ..................................................................................................24 3.1.3 WebApp .............................................................................................................24 4 MODELAGEM DE APLICAES .............................................................................26 5 OOHDM ..........................................................................................................................28 5.1 LEVANTAMENTO DE REQUISITOS....................................................................30 5.1.1 Identificao de atores e tarefas ......................................................................31 5.1.2 Especificao dos cenrios ...............................................................................32 5.1.3 Especificao dos Use Cases.............................................................................32 5.1.4 Especificao dos UIDs.....................................................................................33 5.1.4.1 Item de Dado................................................................................................33 5.1.4.2 Estruturas .....................................................................................................34 5.1.4.3 Conjunto.......................................................................................................34

5.1.4.4 Dado Opcional .............................................................................................35 5.1.4.5 Entrada de Usurio.......................................................................................35 5.1.4.6 Estado da Interao ......................................................................................36 5.1.4.7 Texto ............................................................................................................37 5.1.4.8 Sada do Sistema..........................................................................................37 5.1.4.9 Estado Inicial da Interao...........................................................................38 5.1.4.10 Estados Alternativos da Interao..............................................................38 5.1.4.11 Sub-Estados de um Estado da Interao ....................................................39 5.1.4.12 Chamada de outro UID ..............................................................................39 5.1.4.13 Chamada a partir de outro UID..................................................................40 5.1.4.14 Transio....................................................................................................41 5.1.4.15 Pr-Condies e Ps-Condies ................................................................42 5.1.4.16 Notas textuais.............................................................................................43 5.1.4.17 UIDs parametrizados .................................................................................43 5.1.4.18 Exemplos de UIDs .....................................................................................45 5.1.4.19 Relacionamento entre UIDs.......................................................................46 5.1.4.19.1 Relacionamento Inclui ........................................................................47 5.1.4.19.2 Relacionamento Estende.....................................................................47 5.1.4.19.3 Relacionamento Precede ....................................................................48 5.1.4.20 Representao do UID Inicial....................................................................49 5.1.5 Validao dos Use Cases e UIDs ......................................................................49 5.2 MODELAGEM CONCEITUAL...............................................................................50 5.2.1 Classes ................................................................................................................50 5.2.1.1 Atributos de Classe ......................................................................................51 5.2.1.2 Operaes da Classe ....................................................................................53 5.2.2 Generalizao ....................................................................................................54 5.2.3 Relacionamentos ...............................................................................................56 5.2.3.1 Cardinalidade ...............................................................................................57 5.2.3.2 Classe de relacionamento.............................................................................58 5.2.4 Agregao ..........................................................................................................59 5.2.5 Composio........................................................................................................60 5.2.6 Objeto.................................................................................................................60 5.2.7 Diagrama de Objetos ........................................................................................62 5.2.8 Subsistemas........................................................................................................63 5.2.9 Esquema Conceitual de Classes.......................................................................64

5.3 MODELAGEM NAVEGACIONAL ........................................................................66 5.3.1 Esquema de classes navegacionais...................................................................66 5.3.2 Ns ......................................................................................................................67 5.3.2.1 Atributos ......................................................................................................67 5.3.2.2 Operaes.....................................................................................................69 5.3.3 Generalizao ....................................................................................................69 5.3.4 Elos .....................................................................................................................69 5.3.5 ncoras e ndices ..............................................................................................70 5.3.6 Agregao e Composio..................................................................................72 5.3.7 Diagrama de objetos .........................................................................................72 5.3.8 Diagrama do esquema de classes navegacionais ............................................73 5.3.9 Classes em Contexto .........................................................................................74 5.3.10 Esquema de Contextos de Navegao ...........................................................74 5.3.10.1 Estruturas de Acesso..................................................................................75 5.3.10.2 Contextos de navegao.............................................................................76 5.3.10.2.1 Caracterizao dos elementos de um contexto...................................78 5.3.10.2.2 Permanncia dos elementos no contexto ............................................81 5.3.10.2.3 Durao do contexto...........................................................................83 5.3.10.3 Elos de navegao do esquema de contextos navegacionais .....................83 5.3.11 Generalizao de Contextos ...........................................................................86 5.3.12 Cartes de identificao .................................................................................87 5.3.13 Diagrama do Esquema de Contextos de Navegao....................................88 5.4 PROJETO DE INTERFACE ABSTRATA...............................................................90 5.4.1 ADV (Abstract Data View) ..............................................................................90 5.4.2 Diagramas de Configurao ............................................................................92 5.4.3 ADVcharts .........................................................................................................93 5.5 IMPLEMENTAO.................................................................................................95 5.5.1 Mapeamento dos objetos navegacionais .........................................................95 5.5.2 Mapeamento dos relacionamentos ..................................................................96 6. CONCLUSO................................................................................................................97 6.1 TRABALHOS FUTUROS ........................................................................................98 REFERNCIAS BIBLIOGRFICAS.............................................................................99

LISTA DE FIGURAS Figura 1: Ns, elos e ncoras. ..............................................................................................20 Figura 2: Sistema de funcionamento bsico da Web. ..........................................................22 Figura 3: Exemplo de dados multimdia..............................................................................27 Figura 4: Esboo do mtodo OOHDM (SCHWABE, 2003)...............................................29 Figura 5: Ciclo de desenvolvimento tradicional. .................................................................29 Figura 6: Ciclo de desenvolvimento usando OOHDM........................................................30 Figura 7: Exemplo de especificao de cenrios. ................................................................32 Figura 8: Exemplo de especificao de use case. ................................................................33 Figura 9: Exemplo de Item de Dado. ...................................................................................34 Figura 10: Exemplo de Estrutura. ........................................................................................34 Figura 11: Exemplo de Conjunto.........................................................................................35 Figura 12: Exemplo de Dado Opcional. ..............................................................................35 Figura 13: Exemplo de Entrada do Usurio.........................................................................36 Figura 14: Exemplo de Entrada do Usurio Enumerada. ....................................................36 Figura 15: Exemplo de Estado da Interao. .......................................................................37 Figura 16: Exemplo de Texto. .............................................................................................37 Figura 17: Exemplo de Sada do Sistema. ...........................................................................38 Figura 18: Exemplo de Estado Inicial da Interao. ............................................................38 Figura 19: Exemplo de Estados Alternativos da Interao..................................................39 Figura 20: Exemplo de Sub-Estados de um Estado da Interao (VILAIN, 2002).............39 Figura 21: Exemplos de Chamada de outro UID. A Esquerda um UID com transio de entrada, e a direita chamada de um UID sem transio de entrada. ............................40 Figura 22: Exemplos de Chamada a partir de outro UID. ...................................................41 Figura 23: Exemplos de Transies.....................................................................................42 Figura 24: Exemplos de UIDs que podem ser parametrizadas (VILAIN, 2002). ...............43 Figura 25: Exemplos de UID parametrizado (VILAIN, 2002)............................................44 Figura 26: Exemplo de UID (VILAIN, 2002). ....................................................................45 Figura 27: Relacionamento Inclui entre UIDs (VILAIN, 2002). ........................................47 Figura 28: Relacionamento Estende entre UIDs..................................................................48 Figura 29: Relacionamento Precede entre UIDs (VILAIN, 2002). .....................................48 Figura 30: UID Inicial de uma aplicao.............................................................................49 Figura 31: Exemplos de Classe em OOHDM......................................................................51 Figura 32: Exemplo de Atributos com mltiplas perspectivas. ...........................................51 Figura 33: Exemplo de Atributo com mltiplas perspectivas e com identificador de tipo.52

Figura 34: Exemplos de Atributo de Classes em OOHDM.................................................53 Figura 35: Exemplos de Operaes de Classes em OOHDM .............................................54 Figura 36: Exemplo de Generalizao.................................................................................55 Figura 37: Exemplo de Restries em Generalizao .........................................................55 Figura 38: Exemplo de Herana com mltiplas perspectivas..............................................56 Figura 39: Exemplos de Relacionamento entre Classes ......................................................57 Figura 40: Exemplos de Cardinalidade de Relacionamentos ..............................................58 Figura 41: Exemplo de Relacionamento com Cardinalidade ..............................................58 Figura 42: Exemplo de Classe de relacionamento (VILAIN, 2002). ..................................59 Figura 43: Exemplo de Agregao ......................................................................................59 Figura 44: Exemplo de Composio....................................................................................60 Figura 45: Exemplos de representao de Objetos em OOHDM ........................................61 Figura 46: Exemplo de um Objeto hipermdia (HENNRICHS, 2000)................................61 Figura 47: Associao da Classes Embarcao com seu objeto (HENNRICHS, 2000). ....62 Figura 48: Exemplo de Diagrama de objetos (VILAIN, 2002). ..........................................63 Figura 49: Exemplo de classe de outro subsistema .............................................................63 Figura 50: Esquema Conceitual da aplicao RMS Titanic! A compilao de uma tragdia (HENNRICHS, 2000)..................................................................................................64 Figura 51: Esquema Conceitual de uma aplicao acadmica (VILAIN, 2002).................65 Figura 52: Representao de um N em OOHDM..............................................................67 Figura 53: Mapeamento de uma Classe Conceitual em N.................................................68 Figura 54: Representao de uma lista em um n (OLIVEIRA, 2003)...............................68 Figura 55: Exemplo de generalizao/especializao de classes de ns. ............................69 Figura 56: Exemplo de esquema de classes navegacionais (VILAIN, 2002)......................70 Figura 57: Exemplo da representao de ncora e ndice (VILAIN, 2002). ......................71 Figura 58: esquerda agregao de n e a direita composio de n no esquema de classes navegacionais do OOHDM..............................................................................72 Figura 59: Diagrama de objetos no esquema de classes navegacionais (VILAIN, 2002)...72 Figura 60: Diagrama do esquema de classes navegacionais (VILAIN, 2002). ...................73 Figura 61: Classes em Contexto (VILAIN, 2002). ..............................................................74 Figura 62: Representao de seletor de estrutura de acesso (SCHWABE, 2003). ..............75 Figura 63: Representao dos tipos de estrutura de acesso (SCHWABE, 2003). ...............76 Figura 64: Representao de classe navegacional e contexto (OLIVEIRA, 2003). ............77 Figura 65: Representao de contextos de navegao (SCHWABE, 2003)........................78 Figura 66: Exemplo de contexto arbitrrio de vrias classes (VILAIN, 2002). ..................79 Figura 67: Exemplo de contexto de objetos (VILAIN, 2002). ............................................80

Figura 68: Exemplo de grupo de contexto (VILAIN, 2002). ..............................................81 Figura 69: Exemplo de contexto dinmico (OLIVEIRA, 2003). ........................................82 Figura 70: Exemplo de contexto por consulta (VILAIN, 2002)..........................................82 Figura 71: Exemplos de elos de navegao (SCHWABE, 2003)........................................84 Figura 72: Passagem de parmetro em elos de navegao (VILAIN, 2002).......................85 Figura 73: Generalizao de contextos (VILAIN, 2002). ...................................................86 Figura 74: Carto de contexto ou grupo de contexto (VILAIN, 2002). ..............................87 Figura 75: Carto de estrutura de acesso (VILAIN, 2002)..................................................87 Figura 76: Diagrama do esquema de contextos de navegao (VILAIN, 2002). ................88 Figura 77: Diagrama do esquema de contextos com subsistema (PUC-RIO, 2002). .........89 Figura 78: Diagrama do esquema de contextos do subsistema reas (PUC-RIO, 2002). ..89 Figura 79: Interface e o ADV Pessoa (SCHWABE, 1998). ................................................91 Figura 80: Diagrama de configurao (ROSSI, 1997). .......................................................92 Figura 81: ADVchart Pintor (ROSSI, 1997). ......................................................................94

LISTA DE ABREVIATURAS

ADO ADV CD CD-ROM CERN DVD FK HDM HTML J2EE MySQL NCSA OCR OMT OOHDM PC PHP PUC-RIO RMS SGBD UID UML WWW

Abstract Data Object Objeto Abstrato de Dados Abstract Data View Viso Abstrata de Dados Compact Disk Compact Disk Read Only Memory Conselho Europeu de Pesquisa Nuclear Digital Vdeo Disk Foreing Key Chave Estrangeira Hypermedia Design Model Hyper Text Markup Language Java 2 Enterprise Edition Banco de Dados Relacional Free National Center for Supercomputing Applications Reconhecimento ptico de Caracteres Tcnica de Modelagem de Objetos Object Oriented Hypermedia Design Model Personal Computer Linguagem Script Client-Server Free Pontifcia Universidade Catlica do Rio de Janeiro Royal Mail Steamship Navio a vapor da marinha real e de correio Sistema Gerenciador de Banco de Dados User Interface Diagram Unified Modeling language World Wide Web

13 1 INTRODUO

Com a exploso da interface grfica da Internet, conhecida pela sigla WWW (World Wide Web), multiplicaram-se os volumes de dados processados e transmitidos na Web (AGUIAR, 1997). Essa exploso de difuso deu-se principalmente devido ao surgimento do hipertexto (vnculo de um texto a um outro ponto da Web), e posteriormente da hipermdia (ligao com outros objetos como figuras, animaes, filmes entre outros). Os websites que nada mais so do que aplicaes hipermdia na WWW tornaram-se muito mais do que apenas pginas estticas, inertes a ao do usurio. Transformaram-se em websites dinmicos, que se modificam em funo da ao executada pelo usurio. Esta evoluo fez surgir uma outra categoria de aplicaes destinadas exclusivamente para a Internet, as webapps (aplicaes que rodam sobre a plataforma da WWW). Contudo continuou-se a elaborar os websites dinmicos e as webapps da mesma forma que se criava sites estticos. O processo de desenvolvimento de aplicaes hipermdia, websites e webapps, no deve ser diferente do desenvolvimento de qualquer outra espcie de software, ou seja, devemos ter presente durante o processo de desenvolvimento as atividades de: planejamento, levantamento de requisitos, anlise, projeto, implementao e manuteno. Deve-se levar em considerao que o desenvolvimento de websites e/ou webapps demanda de uma grande gama de profissionais como: projetistas, webdesigners, webmasters, programadores, pessoas relacionadas ao marketing, tcnicos de segurana na Web, entre outros. A fim de suprir essas necessidades no desenvolvimento de aplicaes hipermdia, e na interligao dos diversos profissionais existentes durante o desenvolvimento, surgiram no mercado diversos modelos para a engenharia desse tipo de aplicao. Dentre elas, o OOHDM (Object Oriented Hypermedia Design Method), ou Modelo de Design Hipermdia Orientado a Objeto, tem se mostrado muito eficiente. A metodologia escolhida para a construo de uma aplicao hipermdia deve tratar dos problemas prprios de cada atividade e ao prprio nvel de abstrao, e as solues desses problemas devem ser registradas e possveis de serem localizados, tanto para trs ou para frente, durante o processo de desenvolvimento (SCHWABE, 1996). O mtodo OOHDM preenche os quesitos citados acima, e tem por caracterstica: manter a natureza exploratria da aplicao hipermdia; pode ser usado como forma de

14 comunicao entre projetistas, programadores, usurios e quaisquer outros profissionais envolvidos no processo; orientado a objetos; a metodologia est baseada na UML; pode ser utilizado para se modelar aplicaes em CDs, DVDs, WWW, entre outros e; implementa todas as atividades necessrias para o desenvolvimento de um software.

1.1 OBJETIVOS

1.1.1 Objetivo Geral

O objetivo tangido para este trabalho de especializao o estudo do mtodo de engenharia de desenvolvimento de aplicaes hipermdia OOHDM em sua mais recente verso e atualmente baseado na UML.

1.1.2 Objetivos Especficos

Contextualizar Hipermdia e Multimdia para o desenvolvimento de aplicaes; Contextualizar Web, Websites, Web databases e Webapps; Conceituar a importncia de modelagem de aplicaes; Estudar e descrever o mtodo OOHDM.

1.2 ESTRUTURA DO TRABALHO

Este trabalho est disposto em seis captulos organizados da seguinte forma: Captulo 1, Introduo: tem o objetivo de introduzir o assunto e contextualizar a escolha do tema.

15 Captulo 2, Multimdia e Hipermdia: apresenta conceitos relevantes multimdia, hipertextos, hipermdia e hiperdocumentos. Captulo 3, Websites e Web Databases: demonstra conceitos de web, websites, sites estticos e dinmicos, web databases e webapps. Captulo 4, Modelagem de Aplicaes: apresenta o por que da modelagem de aplicaes. Capitulo 5, OOHDM: explica em detalhes e exemplos o mtodo OOHDM e cada uma de suas cinco etapas: Levantamento de requisitos; Modelagem Conceitual; Modelagem Navegacional; Projeto de Interface e Implementao. Captulo 6, Concluses: apresenta as concluses obtidas com o desenvolvimento deste, consideraes finais e sugestes de trabalhos futuros.

16 2 MULTIMDIA X HIPERMDIA

2.1 MULTIMDIA

A histria do surgimento da multimdia digital confunde-se com a do desenvolvimento das interfaces e interatividades no espectro da informtica, pois nasceu praticamente junto com as interfaces grficas, uma vez que consistem do uso de texto, imagens, animaes, vdeos e sons. O termo multimdia tem sua origem da lngua latina e composta de duas partes: multi e mdia. Multi: origina da palavra multus que significa "numeroso, muitos, vrios", como por exemplo: multifuno, multitarefa, multiprocessado, entre outros. Mdia: vm do plural da palavra latina medium que significa "centro, meio". Atualmente, a palavra mdia tambm largamente utilizada, especialmente na mdia televisiva, para definir meio de transmitir informaes. possvel deduzir-se ento que, quando so utilizados vrios meios para apresentar uma determinada informao, a multimdia est sendo utilizada (GERTLER, 1995). Entretanto, alguns autores preferem designar multimdia como a apresentao organizada de sons, imagens, vdeos, textos e animaes como o caso de Crtes (1997). J Willrich (2000), prefere descrever multimdia bem mais amplamente, como sendo o campo interessado na integrao controlada por computador de textos, grficos, imagens, animaes, sons, vdeos e quaisquer outros meios onde todo o tipo de informao pode ser representado, armazenado, transmitido e processado digitalmente. Com a chegada da multimdia digital, o PC rompeu a barreira do mundo da esttica rumo ao domnio da dinmica, onde a informao experimentada com os sentidos e as emoes, da mesma forma que o intelecto (LINDSTRON, 1996). A multimdia facilmente relacionada com computadores, pois estas mquinas apresentam condies tecnolgicas de agregar sons, imagens, vdeos, textos e animaes. O mais importante desse casamento perfeito a possibilidade do usurio interagir com a apresentao.

17 2.1.1 Objetos Multimdia

Os principais objetos da multimdia so representados pelo texto, udio e imagens (estticas ou em movimento). O texto o objeto multimdia mais bsico que existe no momento e sua captura e manipulao muito fcil. Por sua vez, o som uma informao de grande importncia e pode ser representado por uma narrativa. Quanto utilizao de imagens argumenta-se que , dentre os objetos multimdia, o mais importante e seu uso aumenta a comunicao udio-visual.

2.1.1.1 Texto

, dentre os objetos multimdia, o mais comum e, sua aquisio bsica d-se atravs do teclado, podendo tambm ser feita atravs de scanner, pelo mtodo de reconhecimento tico de caracteres (OCR). Alm de ser o mais concreto e confivel meio possvel, quando pretende-se declarar algo, o texto ainda representa a base para quase todos os mtodos de comunicao. por essa razo que faz-se necessrio entender a extrema importncia de se efetuar uma comunicao clara, concisa e precisa.

2.1.1.2 udio

O som, sem dvida, constitui-se dentre os objetos multimdia, o mais complexo e belo que h. Porm, seu uso deve ser moderado, pois muitas vezes, ao invs de ajudar na compreenso de um determinado contedo, pode acabar atrapalhando.

2.1.1.3 Imagens

Aplicaes multimdia so inerentemente visuais, tais como as fotografias, ilustraes, cores e formas que se combinam em uma tela para criar uma linguagem visual que fala com o usurio, de forma sutil e diretamente.

18 As imagens dividem-se em dois tipos: as estticas (fotografias, grficos e ilustraes) e as imagens em movimento (animao e vdeo). No cabe a este apresentar mais detalhadamente os objetos multimdia, j que estes constituem material de diversas obras j existentes.

2.2 HIPERTEXTO

Com base no termo latin hiper, que significa alm, excesso, em meados de 1960 o filsofo norte-americano Theodor Holm Nelson, conhecido como Ted Nelson, designou o termo hipertexto como algo que vai alm que excede, ou seja, uma interconexo de informaes relacionadas dentro de um programa de computador (AGUIAR, 1997). J Rhaume (1993 apud BUGAY, 2000), cita que hipertexto uma organizao no-linear de informaes. O hipertexto faz uso da idia de palavras que remetem a outros locais, como por exemplo: verbetes de enciclopdias, notas de rodap, entre outros. No entanto, com o hipertexto, esse deslocamento ocorre de uma forma mais dinmica e rica. Ao invs de ter que virar uma pgina ou deslocar-se at outro ponto da obra basta clicar com o mouse sobre a parte do texto que est em destaque (geralmente sublinhada), para ter acesso a outro um documento, explicao ou arquivo correlato. Atualmente designamos hipertexto como um documento formado por vrias pginas independentes, ligadas entre si atravs de referncias denominadas de hiperlinks ou links, que em ingls significa elo ou vnculo entre dois elementos em comum. Por meio de sua estrutura flexvel, o hipertexto torna a navegao de um texto mais lgica (no linear), fazendo com que o usurio crie seu prprio ritmo, nvel e estilo, adequando s suas caractersticas e interesses.

2.3 HIPERMDIA

A multimdia uma excelente maneira de disponibilizar informaes, mas ela, por si prpria, no fornece recursos para que se possa encontrar o que deseja. Com o

19 surgimento da multimdia interativa onde possvel ver o que se quer na hora que se quiser, nasceu o termo hipermdia. A palavra hipermdia veio de encontro necessidade de se designar um sistema ou documento interativo/exploratrio, cujo termo originou-se de hipertexto que se constitui numa ligao criada entre um texto e um objeto (LINDSTRON, 1996). Willrich (2000), hipermdia descrito como um sistema multimdia, no qual as informaes so obtidas e apresentadas com o auxlio de mecanismos de navegao baseados em ligaes (links). Por sua vez, Bugay (2000), descreve hipermdia como sendo a combinao de multimdia e apresentao, ambas computadorizadas, da informao. A hipermdia permite aos usurios que estiverem apreciando uma imagem, clicar sobre determinada regio e acessar um vdeo explicativo ou dar incio a uma animao. Esta animao, por sua vez, poder abrir outra e mais outra explicao, e assim, sucessivamente. O processo parecido com a forma de pensar do homem (CRTES, 1997). Por exemplo, basta experimentar pensar num assunto, que este o levar a outro lugar ou assunto e assim por diante. Processo idntico o que a hipermdia se prope a realizar. A hipermdia permite que se comece a navegao em qualquer lugar, utilizando palavras-chaves ou frases comuns, bem como objetos e elementos de mdia que aparecem durante a apresentao. Este nvel de interatividade permite que o usurio salte entre os tpicos, subsees e palavras-chaves, possibilitando-o, a elaborao de associaes e referncias cruzadas, em enquanto navega. Desta forma, o termo hipermdia vai alm de simples conexes de textos, tendo em vista que ela permite criar links com objetos, tais como figuras, animaes, filmes, entre outros.

2.4 HIPERDOCUMENTOS

Aproximadamente em 1989 quando a Web comeou a dar seus primeiros passos, o cientista ingls Tim-Berners-Lee props aos pesquisadores do CERN (Conselho Europeu de Pesquisa Nuclear), a idia de um novo modelo de distribuir e consultar documentos pela

20 comunidade cientfica, atravs do computador, baseado na idia de hipertexto. Nascia assim o termo hiperdocumento. De acordo com Willrich (2000), um documento hipertexto, ou hiperdocumento, uma estrutura de informao organizada de maneira no linear onde os dados so armazenados em uma rede de ns conectadas por ligaes, elos ou links que so expressos visualmente atravs de ncoras (figura 1). N A Escolha uma das opes abaixo: - Tempo - Cotao do Dlar - Bolsa de Valores (Bovespa) N C ncoras elos N B

Figura 1: Ns, elos e ncoras.

Diante do exposto possvel concluir que a hipermdia um avano surpreendente diante do que a multimdia trouxe consigo. Se a multimdia praticamente deu vida ao computador pessoal, fazendo este ser capaz de exibir muito mais do que apenas textos, a hipermdia nos permite ir onde quiser na hora que se desejar, o que no era possvel com a multimdia. No entanto toda essa interatividade da hipermdia somente foi possvel com o surgimento do hiperdocumento, que props o surgimento de ncoras (hotwords), que faziam a ligao com outros pontos do documento ou para fora dele.

21 3 WEBSITES E WEB DATABASES

3.1 WEB

Com o surgimento das interfaces grficas no comeo da dcada de 1990, houve uma exploso de desenvolvimento e disseminao da Internet nos lares e empresas do mundo. Esse espantoso crescimento tornou-se possvel graas ao surgimento da WWW (World Wide Web), ou ainda Web, fazendo referncia ao ambiente de comunicao mais popular e utilizado, atualmente na Internet. A WWW foi apresentada oficialmente a Internet em 1991. De acordo com TimBerners-Lee seu idealizador a Web representa o universo das informaes acessveis por redes de computadores, a personificao do conhecimento humano (VENETIANER, 1996 apud BUGAY, 2000). O que atraiu tanto a ateno da Web perante aos outros servios da Internet, foi possibilidade de transferncia de informaes na forma de hipermdia: combinao de multimdia e hipertexto. (JAMHOUR, 1999). Essa caracterstica permitiu a criao de interfaces amigveis e atrativas para os usurios. Essas interfaces utilizadas para se visualizar o contedo da Web foram batizadas de browsers ou navegadores. O primeiro browser de navegao para interfaces grficas da Internet foi o Mosaic. O Mosaic foi desenvolvido pela NCSA (National Center for Supercomputing Applications), com base nos documentos e dados fornecidos pelos cientistas do CERN para o projeto WWW. Em 1994 aps uma fuso com a Silicon Graphics, o Mosaic deu origem ao Netscape Navigator, tornando-se o browser padro da Internet at o surgimento e ascenso do Internet Explorer da Microsoft. Para Conallen (2003), o termo Web vem da viso do sistema como um conjunto de ns com links de interconexo. Muito parecido como a teia de uma aranha. Os links fornecem o percurso para se percorrer o sistema. Muitos destes caminhos nos direcionam a documentos de texto, mas esses tambm podem nos remeter a informaes mais ricas, como udios, animaes e vdeos. A Web segue a arquitetura cliente-servidor, ou seja, um cliente (usurio) solicita uma determinada informao a um servidor, a informao processada e uma resposta remetida de volta ao cliente. Na Web os servidores disponibilizam informaes hipermdia,

22 para os clientes conectados a rede. Os clientes obtm acesso a essas informaes atravs dos browsers (figura 2).

Rede Cliente Servidor

Solicitao Browser Documento Figura 2: Sistema de funcionamento bsico da Web. Servidor Web Sistema de Arquivos locais

3.1.1 Website

A termo Website constitudo de duas expresses: Web e site. A expresso Web j foi descrita anteriormente e denomino agora o termo site. A expresso site utilizada para denominar qualquer local na Internet onde seja possvel encontrar algum tipo de informao. O conjunto de pginas de uma universidade ou um jornal on-line so exemplos de site. No caso de pginas grficas, utiliza-se o termo Website (AGUIAR, 1997). Esta definio de Website oferecida por Aguiar (1997), tornou-se ultrapassada. Atualmente, em mais de noventa e cinco por cento (95%), dos sites existentes na Internet, so grficos. Desta forma convencionou-se denominar qualquer conjunto de pginas na Web, sejam elas grfica ou no, de site. Para Jamhour (2000), denomina-se site, um conjunto de informaes administradas por uma mesma entidade. Entende-se por entidade uma pessoa, uma empresa, uma organizao, um provedor, entre outros.

23 Na prtica um Website, ou simplesmente site, um conjunto de pginas HTML (Hipertext Markup Language) e arquivos multimdia relacionados, armazenados no sistema de arquivos de um provedor, e acessveis na Internet. Com a evoluo dos sites da Internet, que partiram de simples pginas de textos para incrveis pginas com figuras, animaes e som, tornou-se possvel distinguir duas categorias de sites: sites estticos e os sites dinmicos.

3.1.1.1 Sites Estticos

Denomina-se sites estticos aquelas pginas criadas diretamente pelo usurio atravs de editores HTML e publicadas no provedor para que seja possvel seu acesso pela Internet. As pginas HTML armazenadas no servidor so denominadas pginas estticas (JAMHOUR, 2000).

3.1.1.2 Sites Dinmicos

Ao contrrio das pginas estticas, que so elaboradas atravs de editores, as pginas dinmicas so geradas dinamicamente. Denomina-se pgina dinmica, as pginas HTML construdas por aplicaes externas ao servidor WWW, geradas como respostas a uma requisio feita pelo usurio (JAMHOUR, 2000). Aps ter sido construda pela aplicao externa, uma pgina dinmica idntica a uma pgina esttica, a diferena est no modo em que so construdas. Na maioria das vezes, a gerao automtica dessa pgina dinmica possvel graas utilizao de uma banco de dados onde ficam armazenadas as informaes que so processadas para a criao desta pgina dinmica. Pode-se considerar que um site esttico atualmente obsoleto. No necessria a utilizao de um Banco de Dados para que o site seja dinmico. O simples uso de um formulrio on-line, sem armazenar nada em banco, pelo qual ir ser gerada a resposta, pode ser considerado um site dinmico.

24 3.1.2 Web Databases

Atualmente possvel efetuar diversas transaes atravs da Web, seja ela uma pesquisa, uma compra, uma conversa entre amigos, entre outros. Toda essa gama de possibilidades tornou-se possvel graas utilizao de banco de dados na Web. De acordo com Silva (2001), um banco de dados representa algum aspecto do mundo real, o qual pode ser considerado de mini-mundo. Qualquer modificao ocorrida neste mini-mundo automaticamente refletida sobre o banco de dados. Para Mello, 2002, banco de dados o apelido aplicado ao SGBD, Sistema de Gerenciamento de Banco de Dados, e a sua caracterstica fundamental e a de administrar de forma segura toda a qualquer iterao com o dado. A arquitetura de funcionamento dos bancos de dados para Web a mesma da Web, ou seja, a Client-Server (figura 2). Conclui-se dessa forma que o termo Web Databases aplicado a todo e qualquer banco de dados que funcione sobre a WWW.

3.1.3 WebApp

Abreviao do termo ingls Web Application, ou seja, aplicaes na Web. Em engenharia de software, um WebApp uma aplicao cliente-servidor que roda na Web. As WebApps so populares devido onipresena do browser como um cliente. Outro motivo que torna as WebApps populares a sua capacidade de ser executada em milhares de clientes, sem a necessidade de instalao e/ou distribuio de um software especifico no micro do cliente. So exemplos de WebApps: webmail, amazon.com, submarino.com.br, entre outros. Uma WebApp comumente estruturada em trs camadas: O browser a primeira camada. Um servidor de aplicaes para a criao de sites dinmicos a segunda camada. A terceira camada constituda de um Banco de Dados. (figura 2).

Conclui-se que a evoluo da Internet constante. No comeo tudo da rede mundial de computadores flua na forma de texto. Com o surgimento da WWW a Internet deu um

25 imenso salto para a sua popularizao, pois j era capaz de exibir imagens. Aps veio a possibilidade de se exibir sons, vdeos e animaes. Quando pensava-se que iria parar surgiram os sites dinmicos. O usurio da rede podia agora interagir com o site de uma maneira mais complexa, e no mais apenas ficar navegando por ele. Os sites dinmicos impulsionaram o surgimento dos Web databases, os bancos de dados na web, e estes por conseqncias trouxeram consigo as WebApps, ou seja, as aplicaes que rodam sobre a Web. Atravs da interatividade proposta pela hipermdia, as WebApps acessam os Web databases na procura ou insero de dados e devolvem a resposta ao usurio que interage de forma dinmica sobre a aplicao Web.

26 4 MODELAGEM DE APLICAES

Modela-se para compreender procedimentos complexos (CONALLEN, 2003). A elaborao de aplicaes hipermdia no nada fcil. A principal dificuldade imposta est na combinao da navegao que o usurio efetuar com a prpria natureza dos dados multimdia (ROSSI, 1997). Essas complexidades vm tona com mais clareza quando se mescla a hipermdia com a Internet, no desenvolvimento de Websites. Na esperana de evitar esses problemas e de desenvolver uma aplicao que transmita clareza e objetividade ao usurio, que se recorre modelagem. Segundo Rumbaugh (1994), somente quando os conceitos relativos aplicao so identificados, organizados e compreendidos que os detalhes das estruturas e funes podem ser tratados eficazmente. Os modelos so utilizados em todo o ciclo de vida de desenvolvimento, pois proporcionam uma cadeia de responsabilidade e rastreamento. O pesquisador Conallen (2003), cita que: a real vantagem da utilizao da modelagem no o que ela contm, mas o que est oculto. Um diagrama de classe de UML um exemplo. Ele oculta informaes ao no expor todas as operaes, atributos e associaes de uma classe. Essas operaes ocultas somente estaro disponveis no final, no cdigo-fonte da aplicao. Algumas das reais vantagens na utilizao de um modelo para o desenvolvimento de uma aplicao: um mecanismo de comunicao entre grupos do desenvolvimento (analista, projetista, implementador). Estimula a decompor o problema em partes gerenciveis. Facilita a compreenso do que se pretende criar.

Mas qual modelo escolher? Deve-se levar em considerao na escolha de um modelo que Websites trabalham com dados de uma natureza muito particular. So imagens, textos, vdeos, animaes, entre outros, que se diferem em muito de simples dados armazenados em um banco ou em um arquivo (figura 3).

27

Texto Imagem

Vdeo

Figura 3: Exemplo de dados multimdia.

Os dados multimdia tm suas caractersticas prprias e pode muito bem ser definidos como tipos distintos de objetos. De acordo com Rumbaugh (1994), um objeto algo com limites ntidos e significados prprios, com duas finalidades bem diferentes: facilitar a compreenso do mundo real e possibilitar a sua implementao no computador. Para Furlan (1998), um objeto possui tudo o que precisa para conhecer a si prprio, ou seja, possui um estado, uma identidade e um comportamento.

Se o desenvolvimento de qualquer aplicativo (desktop, multiusurio, client x server e outros), necessita de uma prvia modelagem, ento que o mtodo escolhido seja suficientemente capaz de manipular os dados da aplicao em questo. Os Websites e WebApps se utilizam de objetos multimdia e da interatividade da hipermdia. Cada um desses objetos tem caractersticas prprias e podem ser agrupados em classes distintas umas das outras. Diante do exposto possvel concluir que o modelo de engenharia a ser escolhido para o desenvolvimento de aplicaes para a Web deva ser orientado a objetos (OO).

28 5 OOHDM

O mtodo de Design Hipermdia Orientado a Objeto (OOHDM, Object Oriented Hypermedia Design Method), foi desenvolvido na Pontifcia Universidade Catlica do Rio de Janeiro (PUC/RJ), por Daniel Schwabe e Gustavo Rossi, em meados de 1996. Sua pesquisa vm sendo aprimorada constantemente e prova disto o Wiki do mtodo OOHDM disponvel no endereo www.oohdm.inf.puc-rio.br:8668/. Descendente do HDM (Hypermedia Design Method) o OOHDM faz uso de uma abordagem mais ampla e voltado ao paradigma de Orientao a Objeto (OO). indicado para o auxilio no desenvolvimento de aplicaes hipermdia de pequena, mdia e grande escala como: Quiosques de pesquisas, aplicativos em CD-ROM ou DVD, bem como tambm de Websites para a Internet ou Intranet. O OOHDM prope para o processo de engenharia de uma aplicao hipermdia, cinco etapas bem distintas:

Levantamento de requisitos; Modelagem conceitual; Modelagem navegacional; Projeto de interface abstrata e, Implementao.

Em cada uma dessas etapas, um modelo novo criado ou enriquecido. Entre todas as etapas previstas por este mtodo possvel efetuar o rastreamento para trs ou para frente a fim de mapear as modificaes de um modelo para o outro (ROSSI, 1997).

29
Atividade/Processos Mecanismos Anlises de Cenrios e Use Cases, Interrelacionamentos, Use Cases e anotaes Mapeamento dos o Diagrama de Interao do Usurio para o modelo Conceitual Classes, subsistemas, relacionamentos, perspectivas de atributos Ns, elos, estruturas de acesso, contextos de navegao e transformaes navegacionais Objetos de interface abstrata, reaes a eventos externos, transformaes de interface. Aplicativo em execuo Produto Interesses do Projeto Capturar os requerimentos e informaes de interesse para a aplicao

Levantamento de Requisitos

Modelagem Conceitual

Classificao, Composio, Modelagem da generalizao e Semntica do domnio especializao da aplicao. Mapeamento entre objetos conceituais e de navegao, padres de navegao para a descrio da estrutura geral da aplicao. Leva em conta o perfil do usurio e a tarefa, nfase em aspectos cognitivos e arquiteturais. Modelagem de objetos perceptveis, implementao de metforas escolhidas, descrio da interface para os objetos navegacionais. Desempenho, completitude

Projeto de Navegao

Interface Abstrata

Mapeamento entre objetos de navegao e objetos de interface

Implementao

Aqueles que o ambiente alvo fornecer

Figura 4: Esboo do mtodo OOHDM (SCHWABE, 2003).

De acordo com essa separao, o ciclo de desenvolvimento de aplicaes usando o OOHDM tambm se difere do ciclo de desenvolvimento tradicional de softwares (figura 4 e 5).

Figura 5: Ciclo de desenvolvimento tradicional.

30

Figura 6: Ciclo de desenvolvimento usando OOHDM.

Devido separao do processo de desenvolvimento em diversas etapas de modelagem, o OOHDM indicado como forma de comunicao entre as vrias pessoas envolvidas no processo de criao da aplicao como: projetistas, designers, implementadores e usurios. O modelo produzido pelo OOHDM pode ser implementado em qualquer tipo de ambiente de desenvolvimento disponvel no mercado, seja este orientado a objeto ou no.

5.1 LEVANTAMENTO DE REQUISITOS

O levantamento de requisitos ou ainda a elicitao de requisitos significa obter o mximo possvel de informaes sobre o domnio da aplicao em voga. tarefa tambm da elicitao, identificar os fatos que compem os requisitos do sistema, de maneira a prover o entendimento correto e completo do que o software, a ser desenvolvido, deve demandar. Esse levantamento de requisitos realizado atravs da identificao de classes de atores e as tarefas que executaro. Em seguida cenrios so criados e esboados para cada uma das tarefas e classes de atores. Com os cenrios j construdos, elabora-se os Use Cases que sero esboados atravs dos Diagramas de Interao do Usurio (UIDs). Estes

31 diagramas tm por objetivo representar exatamente a interao, entre usurio e sistema, durante a execuo de uma tarefa. Compreendem esta fase da metodologia OOHDM cinco etapas: identificao de atores e tarefas, especificao de cenrios, especificao de uses cases, especificao de UIDs e a validao de use cases e UIDs.

5.1.1 Identificao de atores e tarefas

Esta fase tem por objetivo encontrar as reais necessidades dos usurios. Isto possvel atravs da interao do projetista/designer com o domnio da aplicao. O projetista consegue essa interao atravs da anlise de documentos e entrevistas com usurios, a fim de identificar quais sero os atores e as suas tarefas. Para o consultor executivo em TI, Furlan (1998), um ator um agente que interage com o sistema, ou seja, um tipo de usurio ou categoria com papel definido. Salienta que um ator no representa um usurio individual de um sistema e sim um papel. Desta maneira um ator pode representar diversos papis e um papel pode ser representado por vrios atores. Com a identificao dos atores, chega-se a classes de atores. Um exemplo de ator em uma escola o aluno. ele que procura informaes sobre a sua nota, as suas disciplinas, o seu horrio de aula, entre outros. Conforme Vilain (2002), a terminologia tarefa significa o objetivo que o usurio deseja alcanar utilizando a aplicao. Como exemplo de tarefas a serem realizadas por um aluno em uma aplicao de pesquisa de informaes escolar cita-se: Pesquisa das suas notas atravs de seu cdigo; Pesquisa de seu cdigo atravs de seu nome; Pesquisa de suas disciplinas no curso; Pesquisa de seu calendrio de aulas.

32 5.1.2 Especificao dos cenrios

Vilain (2002), cita cenrio como uma descrio textual que explica em detalhes as tarefas que o usurio deseja realizar no domnio em questo. Esta descrio textual elaborada pelo usurio ou pelo projetista. A figura 7 demonstra a especificao de um cenrio na qual o aluno visualiza suas notas atravs da digitao de seu cdigo.

Cenrio: C1 Visualizar minhas notas atravs de meu cdigo de aluno Contexto: Sendo um aluno do SENAC de Chapec, no curso tcnico em Desenvolvimento de Sistemas, gostaria de saber quais as minhas notas nas disciplinas que cursei durante o curso. Objetivo: Visualizar as notas por meio do cdigo do aluno Aes: Atravs da informao do cdigo do aluno e de minha senha, o sistema me retornar as disciplinas do curso, o nome dos professores e o conceito final que obtive em cada uma delas.

Figura 7: Exemplo de especificao de cenrios.

5.1.3 Especificao dos Use Cases

Os Use Cases ou Caso de Uso, uma interao tpica ente um usurio e um sistema, em outras palavras, uma maneira de se utilizar o sistema. No aborda o funcionamento interno do sistema. De acordo com a UML a definio formal para use case : um conjunto de seqncias de aes que um sistema desempenha para produzir um resultado observvel de valor a um ator especfico (FURLAN, 1998). Os use cases so o conjunto de cenrios que especificam uma mesma tarefa. (RUMBAUGH, 1999, apud VILAIN, 2002). Para se especificar os use cases, primeiramente agrupa-se os cenrios que descrevem as mesmas tarefas e depois se mapeia esses cenrios, homogneos, e um nico use case. A figura 8 mostra o use case Visualizar minhas notas atravs do cdigo do aluno.

33
Use case: Visualizar minhas notas atravs do cdigo do aluno Cenrios: C1/... Descrio: 1. 2. 3. 4. 5. O usurio entra com o seu cdigo de aluno Se no souber seu cdigo de aluno, pode pesquis-lo (use case Pesquisar cdigo de aluno). O usurio entra com a sua senha O sistema faz a verificao do cdigo e senha. Se a senha ou cdigo for invlido, o sistema informa que os dados so invlidos e retorna a pedir o cdigo e senha. 6. Caso os dados informados sejam vlidos, o sistema retorna a opo de visualizar as suas notas, para escolha do usurio. 7. 8. Usurio escolhe a opo visualiza notas. O sistema retorna a lista de disciplinas com o nome do professor e o conceito adquirido em cada uma delas, e se est em Aprovado ou Reprovado.

Figura 8: Exemplo de especificao de use case.

5.1.4 Especificao dos UIDs

Do termo em ingls User Interaction Diagram, ou Diagrama de Interao do Usurio (UID), tem por objetivo mostrar a interao do usurio com o sistema descrito no use case, sem entrar em detalhes relativos a interface com o usurio. Um UID especificado atravs dos seguintes itens:

5.1.4.1 Item de Dado

Representa uma informao nica que aparece durante a interao, e escrito em letra minscula. O item de dado pode ser acompanhado do domnio. Neste caso precede-se a utilizao de dois pontos <:> e o nome do domnio. Os nomes de domnios so identificados com a primeira letra em maisculo e devem ser especificados pelo projetista,

34 por exemplo: Nmero, Texto, Som, Imagem, Vdeo. Quanto no especificado o domnio de um item de dado, o domnio Texto assumido como default. Se for utilizado o domnio Enumerado para se especificar opes fornecidas pelo sistema, necessria a especificao dos valores entre chaves <{ ... }> e separados por vrgula <,>. Quanto houver a ocorrncia dos domnios Som, Vdeo, Imagem, o nome do item de dado pode ser suprimido, mas os dois pontos no. Abaixo alguns exemplos:

nome do aluno msica:Som video clip Foto do aluno cdigo:Nmero

ou ou ou ou

nome do aluno:Texto :Som :Vdeo :Imagem

Figura 9: Exemplo de Item de Dado.

5.1.4.2 Estruturas

Representam uma coleo informaes relacionadas de alguma forma. Essas informaes podem ser: itens de dados, estruturas, conjuntos de itens de dados. A especificao de uma estrutura feita entre parnteses e a separao de seus elementos feita com a utilizao da vrgula <,>. O nome de uma estrutura obrigatrio e escrita com a primeira letra em maiscula.

Aluno (cdigo:Nmero, nome, cidade, estado) Professor (cdigo:Nmero, nome,titulao,foto:Imagem, e-mail)

Figura 10: Exemplo de Estrutura.

5.1.4.3 Conjunto

Representa um conjunto de itens de dados ou estruturas. Sua multiplicidade representada por um valor mnimo e um valor mximo na seguinte notao: mn..mx. A multiplicidade default de 1..N e possui a notao de reticncias < ... >.

35
...Aluno (cdigo:Nmero, nome, cidade, estado) ...Professor (cdigo:Nmero, nome,titulao, e-mail) 1..2 telefones 1..3 fotos:Imagem Conjunto de estrutura Conjunto de estrutura Conjunto de item de dado Conjunto de item de dado

Figura 11: Exemplo de Conjunto.

5.1.4.4 Dado Opcional

Como o prprio nome j define, um dado opcional representa um item de dado ou estrutura opcional. Pode possuir a multiplicidade especificada. Sua notao feita atravs do ponto de interrogao <?>. Quando se estiver especificando que uma entrada do usurio opcional, utiliza-se um retngulo de linha pontilhada.

...Aluno (cdigo:Nmero, nome, :Imagem?, cidade, estado) ...Professor (cdigo:Nmero, nome, foto:Imagem?, titulao, e-mail) 1..2 telefones? telefone comercial

Figura 12: Exemplo de Dado Opcional.

5.1.4.5 Entrada de Usurio

Especifica um item de dado ou estrutura que inserida pelo usurio durante a execuo da aplicao. A notao um retngulo de linha contnua. Quando houver a necessidade de inserir itens de dados dependentes entre si, faz-se uso dos seguintes conectivos: E/OU: quanto pelo menos um dos itens de dados deve ser inserido; OU: quando somente um dos itens de dados deva ser fornecido.

36 A figura 13 demonstra exemplos de notao de entradas de usurios.

...Aluno (cdigo:Nmero, nome, :Imagem?, cidade, estado)

nome do aluno cdigo de acesso E/OU cpf

Figura 13: Exemplo de Entrada do Usurio.

Quando o sistema oferece opes que devem ser escolhidas pelo usurio, define-se isto como uma Entrada de Usurio Enumerada. A notao dessa entrada feita semelhante entrada de usurio, porm as opes de escolha so colocadas entre colchetes < [ ... ] > e separadas entre si por vrgula <,>. Quando houver a possibilidade de mais de uma escolha de opo, deve ser inserida a frente do nome de dado a observao de mn..mx, semelhante multiplicidade. Quando nada informado assume-se por default apenas uma escolha.

sexo [M, F]

1..2 fruta preferida [Maa, Laranja, Banana, Abacaxi]

Figura 14: Exemplo de Entrada do Usurio Enumerada.

5.1.4.6 Estado da Interao

Representa um momento da interao entre o sistema e o usurio, ou seja, um retorno de informaes do sistema ou o fornecimento de informaes ao sistema. A notao de estado de interao feita atravs de uma elipse com linha contnua.

37

...Aluno (cdigo:Nmero, nome, :Imagem?, cidade, estado)

cdigo do aluno cfp do aluno

Figura 15: Exemplo de Estado da Interao.

5.1.4.7 Texto

a representao de um texto explicativo que aparece ao usurio em um determinado estado da interao. Muito utilizado por desenvolvedores e projetistas a fim de orientar o usurio quanto informao que foi entregue ou que deva ser inserida. A notao utilizada a de inserir o texto explicativo entre aspas duplas < ... >.

Informe o cdigo do aluno cdigo do aluno

Figura 16: Exemplo de Texto.

5.1.4.8 Sada do Sistema

Representa uma informao retornada pelo sistema. Pode ser um item de dado ou uma estrutura. Em outras palavras, tudo o que aparece fora de retngulos e dentro de um

38 estado da interao e considerado como uma informao retornada pelo sistema, ou seja, uma sada do sistema.

Informe o cdigo do aluno cdigo do aluno

Dados do aluno ...Aluno (nome, fone, Imagem?, email)

Figura 17: Exemplo de Sada do Sistema.

5.1.4.9 Estado Inicial da Interao

Define o estado inicial da interao do sistema com o usurio. representado por uma transio sem precedente.

Informe o cdigo do aluno cdigo do aluno

Figura 18: Exemplo de Estado Inicial da Interao.

5.1.4.10 Estados Alternativos da Interao

Ocorre quando um estado da interao produzir mais de uma sada em resposta a informao fornecida pelo usurio ou da opo escolhida por ele.

39
Informe o cdigo do aluno cdigo do aluno (Voltar) Dados do aluno ...Aluno (nome, fone, Imagem?, email) Aluno inexistente

Figura 19: Exemplo de Estados Alternativos da Interao.

5.1.4.11 Sub-Estados de um Estado da Interao

Utiliza-se esta notao quanto h a excluso mtua de partes de um estado da interao. Quando isso ocorre o usurio dever optar por qual sub-estado da interao ele ir prosseguir.

Aluno Antigo Aluno Novo cdigo do aluno matricula

(fazer matricula)

(login)

Figura 20: Exemplo de Sub-Estados de um Estado da Interao (VILAIN, 2002).

5.1.4.12 Chamada de outro UID

Utilizado para representar a mudana de foco de um estado da interao para outro UID. Se aps a execuo do UID para o qual o foco foi transferido, no houver uma

40 transio para um novo foco da interao, ocorrer o retorno automtico do foco da interao para o estado da interao precedente a chamada da outra UID. A notao para se especificar uma chamada de outro UID a de uma elipse com linha contnua, sombreamento em seu interior e identificada pelo termo UID seguido do nome do UID que ser chamado (figura 21, esquerda). Tambm faz parte da notao a seta apontando para a elipse, indicando a transio. Os landmarks de navegao, mais conhecidos popularmente como cones de navegao do sistema so exemplos de chamada de UID que no possui nenhuma transio de entrada. Neste caso essa UID pode ser chamada diretamente a partir de qualquer estado de interao da UID corrente. Na notao deste tipo de chamada de outro UID no h a indicao da transio (figura 21, direita).

Alunos cadastrados no sistema ...Aluno (nome, cdigo:Nmero)

1 (mostrar cadastro do aluno) UID Mostrar cadastro do aluno

UID Voltar ao Menu

Figura 21: Exemplos de Chamada de outro UID. A Esquerda um UID com transio de entrada, e a direita chamada de um UID sem transio de entrada.

5.1.4.13 Chamada a partir de outro UID

Utilizado para representar que o foco da interao foi transferido de outro UID para o UID atual. Ao final da execuo deste UID, o foco da interao retornar para o UID que o chamou, a partir do ponto em que ocorreu a chamada. Processo semelhante ao que ocorre com uma interrupo de sistema.

41
UID Mostrar cadastro do aluno

Cadastro do aluno ...Aluno (nome, cdigo:Nmero, endereo, fone?, email,)

Figura 22: Exemplos de Chamada a partir de outro UID.

5.1.4.14 Transio

Alm de especificarmos as informaes que o sistema oferece ao usurio e as que o usurio oferece ao sistema, devemos especificar as transies. As transies indicam que o foco da interao poder ser transferido para o novo destino. De acordo com Vilain (2002), para que uma transio ocorra necessrio que, no mnimo, um elemento ou opo seja selecionado, ou que uma informao seja fornecida ao sistema. As notaes de transio dependem da necessidade e da especificao do use case, e podem ser:

Transio normal de um estado para outro Transio sem retorno ao estado de origem Transio com possibilidade de retorno

42 n Indica que para a transio ocorrer ser necessrio que o usurio selecione n elementos, onde n representa um nmero. Pode ser utilizada tambm a notao de multiplicidade. n n ( opo ) Transio com a seleo de uma opo especifica. O nome da opo escrito entre parnteses. Transio com a seleo de uma opo especifica, mas sem a mudana do foco da interao. Indica que a transio de estados ir ocorrer [ condio ] somente se a condio for preenchida. A condio expressa de forma natural e colocada entre colchetes. Figura 23: Exemplos de Transies Indica que n elementos selecionados pertencem a conjuntos diferentes

( opo )

5.1.4.15 Pr-Condies e Ps-Condies

Representa a necessidade de se especificar um UID que s poder ser executado se for satisfeita uma pr-condio ou ps-condio. As pr-condies indicam as condies que devem ser satisfeitas antes da execuo da interao especificada pelo UID. As pscondies descrevem as condies que devero ser satisfeitas aps a execuo do UID. Em ambos os casos a notao, de pr-condio e ps-condio, feita dentro de um retngulo de linha contnua, descrevendo-se a(s) condio(es) em linguagem natural, antecedido dos termos <Pr-condio:> ou <Ps-condio:>.

43 5.1.4.16 Notas textuais

Quando no houver a possibilidade de representao grfica de alguma informao importante no UID, faz-se uso de nota textuais anexadas no UID.

5.1.4.17 UIDs parametrizados

Utilizado para representar UIDs que possuem a mesma seqncia de interao porem, com informaes especificas distintas. O UID parametrizado possui a mesma seqncia de interao e as mesmas informaes em comum dos UIDs que ele se baseia. As informaes distintas so especificadas com a notao de Parmetro dentro dos estados/transies. Ao final do UID, o Parmetro descrito no interior de um retngulo de linha contnua (figura 23). Na figura 22 verificamos um exemplo de duas UIDs que possuem a mesma interao, porem com informaes distintas entre si para se atingir um mesmo resultado. Em um UID solicitado ao usurio rea de pesquisa para se chegar a um professor orientador e no outro UID solicitado o projeto de pesquisa para se chegar ao professor.

rea de pesquisa

projeto de pesquisa

rea de Pesquisa (nome)

Projeto de Pesquisa (nome)

Professor (nome, titulao, descrio, foto?, e-mail,...Projeto de Pesquisa (nome))

Professor (nome, titulao, descrio, foto?, e-mail,...Projeto de Pesquisa (nome))

Figura 24: Exemplos de UIDs que podem ser parametrizadas (VILAIN, 2002).

44 Aps a parametrizao dos dois UIDs acima, chegamos ao resultado exposto na figura 23, onde foi mantido a mesma seqncia de interao e as informaes em comum, e as informaes que eram distintas entre os dois UIDs foram colocadas em um parmetro definido como Parmetro 1.

Parmetro 1

Parmetro 1 (nome) 1

Professor (nome, titulao, descrio, foto?, e-mail,...Projeto de Pesquisa (nome))

Parmetro 1: rea de pesqusia ou projeto de pesquisa

Figura 25: Exemplos de UID parametrizado (VILAIN, 2002).

45 5.1.4.18 Exemplos de UIDs

UID: Comprar um CD a partir do nome do cantor

nome do cantor ano

nome do cantor ...CD (nome, cantor, ano, preo, disponibilidade e capa) 1..N (incluso na lista de compras)

1 (mostrar CD)

nome do cantor ...Cantor

nome do CD X ...Msica (nome, tempo, cantor, compositor, letra) gnero, pas, gravadora, etc

1 (escutar trecho)

Figura 26: Exemplo de UID (VILAIN, 2002).

Esta UID demonstra a tarefa de um usurio para comprar um CD a partir do nome do cantor. No estado inicial o usurio deve informar o nome do cantor e o ano se achar necessrio. A entrada do ano opcional, pois est em um retngulo de linha pontilhada. Se o usurio souber o nome do cantor ele remetido ao estado da interao que exibe o conjunto de CDs daquele cantor. Caso o usurio no saiba o nome do cantor, o foco da interao deslocado para um estado em que o sistema retornar um conjunto de n vezes da estrutura Cantor, a fim de que o usurio escolha um. Ao escolher o cantor desejado o foco passar para o estado de exibio dos CDs do cantor escolhido. Observe que a transio do estado de exibio dos cantores para o estado de exibio dos cds tem o nmero 1. Isso indica que um elemento, no caso um cantor, deve ser selecionado para que a transio ocorra. No estado onde os CDs do cantor so exibidos o sistema retorna o nome do cantor e o conjunto de n vezes a estrutura CD. Para cada CD sero exibidos os seguintes itens de

46 dados: nome, cantor, ano, preo, disponibilidade e capa. Todos esses itens de dados so do domnio Texto, pois no est informado no UID o domnio de cada item de dado, assumindo desta maneira o domnio default. De acordo com as transies deste estado possvel identificar tambm que h duas opes de escolha para o usurio: Incluso na lista de compras e Mostrar CD. A opo Incluso na lista de compras, uma transio de escolha de opo sem a mudana de foco da interao. Observa-se tambm que para escolher essas opo o usurio deve selecionar no mnimo 1 elemento e no mximo n elementos, como demonstra a multiplicidade 1..N nesta transio. Para ocorrer mudana do foco da interao para o estado onde exibida a informao do CD desejado, o usurio deve selecionar um elemento e escolher a opo mostra CD. Com a modificao da interao para o estado onde so exibidas as informaes do CD, o sistema retorna ao usurio o nome do CD escolhido, bem como seu gnero, pas, gravadora e demais informaes. exibido tambm um conjunto de n vezes a estrutura Msica que composta dos itens de dados: nome, tempo, cantor, compositor e letra. Todos com o domnio default. Observa-se que neste estado h uma opo de escutar trecho, que denotada pela transio sem mudana do foco indicada neste estado. A partir deste estado tambm possvel modificar o foco da interao para o estado anterior, como demonstra a transio com a seta de retorno. A transio escutar trecho s acionada se o usurio escolher um elemento no estado e escolher a opo escutar trecho. O foco da interao no modificado neste exemplo.

5.1.4.19 Relacionamento entre UIDs

Aps a especificao de todos os UIDs, chega vez de construirmos o diagrama de relacionamento destes UIDs. A elaborao do diagrama de relacionamentos de UIDs tem o objetivo de apresentar os relacionamentos mais significativos, bem como de destacar alguns relacionamentos descritos nos Use Cases, mas que no foram representados nos UIDs.

47 Os relacionamentos entre UIDs podem ser de trs tipos: inclui, estende e precede.

5.1.4.19.1 Relacionamento Inclui

Usado para identificar que um UID est contido em outro UID, assim como a sua seqncia de interaes. Utilizado quando uma parte comum de um ou vrios UIDs, especificado em um outro UID (VILAIN, 2002). Identifica-se que um UID deve ser includo em outro, quando as interaes definidas no UID includo no fazem sentido se forem executadas sozinhas. No exemplo a seguir tem-se dois UIDs includos no UID Mostra informaes do professor. Isso indica que todas as interaes desses dois UIDs foram inseridas no outro UID. Os UIDs que esto includos no fazem sentido algum estarem sozinho no sistema.

UID Escolher um professor a partir de uma rea de pesquisa

UID Escolher um professor a partir de seu nome

<<inclui>> UID Mostrar informaes do professor

<<inclui>>

Figura 27: Relacionamento Inclui entre UIDs (VILAIN, 2002).

5.1.4.19.2 Relacionamento Estende

Indica que um determinado UID pode ser estendido por um outro UID. Utiliza-se o relacionamento estende quando um UID demonstra um comportamento alternante ou opcional. As interaes que ocorrem no UID que estende o outro podem ser executadas em separado (VILAIN, 2002).

48 No exemplo abaixo temos o UID Editar informaes do aluno que est estendido pelo UID Enviar e-mail a Secretaria. O UID que est estendendo o UID Editar informaes do aluno pode ser executado sozinho em outro ponto do sistema, onde venha a ser necessrio.
UID Editar informaes do aluno <<estende>> UID Enviar e-mail a Secretaria

Figura 28: Relacionamento Estende entre UIDs.

5.1.4.19.3 Relacionamento Precede

Este relacionamento utilizado para especificar que um determinado UID s poder ser executado se o outro UID foi executado com sucesso. Em outras palavras, um UID depende do outro (VILAIN, 2002). Na figura 29 temos um exemplo de relacionamento de precedncia entre UIDs. Neste exemplo o UID Modificar informaes de um artigo somente ser executada se o UID Submeter um artigo tiver sido executada com sucesso.

UID Submeter um artigo

<<precede>> UID Modificar informaes de um artigo

Figura 29: Relacionamento Precede entre UIDs (VILAIN, 2002).

49 5.1.4.20 Representao do UID Inicial

Quando houver a necessidade de se especificar um UID inicial da aplicao, que representar as tarefas a serem executadas quando o sistema inicializado, faz-se uso do relacionamento Inclui para chamar os UIDs das tarefas iniciais. possvel incluir no UID inicial tantas, quantas, forem os UIDs necessrias para se iniciar a aplicao. A figura a seguir exemplifica um UID Inicial de um sistema. Nele a UID Visualizar Notas/Calendrio chamada diretamente quando se inicia a aplicao.

UID Inicial

<<inclui>> UID Visualizar Notas/Calendrio

Figura 30: UID Inicial de uma aplicao.

5.1.5 Validao dos Use Cases e UIDs

A ltima tarefa da etapa inicial de Levantamento de Requisitos a de validao dos Uses Cases e dos UIDs criados at aqui. Essa Validao feita atravs da interao entre projetistas e designers com os usurios. Cada Use Case e UID produzido apresentado para a apreciao dos usurios, a fim de efetuarem as simulaes de interaes com o sistema. Cada sugesto, problema e inconsistncias devem ser anotadas. Esses testes de interao so necessrios para que os usurios cheguem a um consenso.

50 O nmero de interaes necessrias para tentar-se chegar a um consenso em comum ir depender do tempo disponvel, bem como tambm da disponibilidade dos usurios.

5.2 MODELAGEM CONCEITUAL

Durante esta fase da modelagem da aplicao, constri-se um esquema conceitual que represente objetos e relacionamentos existentes no domnio da aplicao. Esta construo feita atravs da definio de classes, subsistemas, relacionamentos, da construo de hierarquias de agregao e especializao, da determinao dos tipos dos atributos das classes e da cardinalidade dos relacionamentos. Em OOHDM o esquema conceitual um diagrama constitudo de classes, relaes e subsistemas.

5.2.1 Classes

As classes so descritas em OOHDM de acordo com os padres da modelagem orientada a objetos. Uma classe uma descrio de um ou mais objetos, atravs de um conjunto uniforme de atributos e operaes. Para se representar graficamente uma classe utiliza-se um retngulo com linha contnua, separado em trs partes. A primeira parte recebe o nome da classe, em negrito e com a primeira letra em maisculo. A segunda parte reservada para a lista de atributos desta classe e a terceira parte utilizada para expor as operaes desta classe. A especificao da terceira parte opcional. Uma classe em OOHDM tambm pode ser apenas descrita na sua forma mais simples que apenas um retngulo com o seu nome em negrito e centralizado dentro.

51
Cidade cdigo: Inteiro nome: Texto descrio: [Texto,imagem] incluirCidade() alterarCidade() excluirCidade() Nome da Classe Atributos da Classe Cidade

Mtodos da Classe

Figura 31: Exemplos de Classe em OOHDM.

5.2.1.1 Atributos de Classe

Um atributo algum dado para o qual cada objeto em uma classe tem seu prprio valor. Um atributo tipado e representam propriedades conceituais dos objetos. Cada atributo da classe deve possuir um tipo de dado predefinido, que pode ser: simples, composto ou um tipo definido pela aplicao. O tipo de dado String um exemplo de tipo de atributo simples. J o tipo de dado Array um exemplo de atributo de tipo complexo. O tipo de um atributo representar, na aplicao final, um relacionamento implcito, ou uma aparncia visual deste atributo. Cada aparncia possvel de um atributo denominada como "perspectiva do atributo" (ROSSI, 1997). Veja o exemplo do atributo descrio da figura 32. Em uma classe Obra de Arte, ele pode ser visto como um texto ou uma imagem. No caso de um atributo possuir mltiplas perspectivas, utiliza-se os colchetes < [...] > e, caso uma perspectiva seja a default, assinala-se com o sinal de < + >. Somente a perspectiva default tem de estar presente em todas as instncias, as demais podem ou no ser utilizadas.

descrio: [texto, imagem] descrio: [texto+, imagem, som]

Figura 32: Exemplo de Atributos com mltiplas perspectivas.

52 possvel ainda se especificar o identificador de um tipo de dado que possua mltiplas perspectivas. Neste caso utiliza-se a notao descrita na figura 33. Faz-se uso dos dois pontos < : > para separar o identificador do tipo de dado.

descrio: [descr: texto+, foto: imagem]

Figura 33: Exemplo de Atributo com mltiplas perspectivas e com identificador de tipo.

A notao geral em OOHDM para a descrio de atributo a seguinte: visibilidade nome : tipo = valor-default { propriedade }

Visibilidade: Em OOHDM a visibilidade de um atributo significa dizer se ele est ou no visvel ao usurio da aplicao, ou seja, visvel ou invisvel (pblico ou privado). A semntica no a mesma da UML. Por default a visibilidade pblica (visvel), no sendo necessrio expressar a mesma no atributo. No entanto, se a visibilidade for privada (invisvel), se far necessrio identificar o atributo respectivo com o sinal de menos < - >. Em OOHDM no existe a visibilidade protegida como na UML. Nome: o identificador do atributo da classe. Sempre iniciado com letra minscula. Tipo: a especificao da tipagem de cada atributo da classe. Se o atributo possuir mltiplas perspectivas, utilizam-se os colchetes e a perspectiva default expressa pelo sinal de mais < + >. Valor-default: Indica o valor que atribudo automaticamente quando o objeto da classe instanciado. opcional o seu uso. Quando no especificado o sinal de igual que o precede, tambm omitido. Propriedades: So informaes extras em relao ao atributo. Seu uso opcional, porm quando se fizer necessrio, s propriedades so expressas entre os sinais de chaves < {...} >.

53
nome: String cdigo: Inteiro -salrio: Real = 0 descrio: [Texto+, Imagem] descrio: [Texto+, Imagem=padrao.jpg]

Figura 34: Exemplos de Atributo de Classes em OOHDM

5.2.1.2 Operaes da Classe

As operaes da classe ou mtodos da classe, como descrito na OO, so os servios ou comportamentos que a classe ir possuir. Comportamentos e servios estes, resultantes de um procedimento algortmico (FURLAN, 1998). A definio das operaes de uma classe depende muito das caractersticas que a aplicao ir possuir. Nos websites estticos, ou seja, aqueles que fazem acesso base de informao multimdia por navegao atravs de relacionamentos, o comportamento de classes desnecessrio. Entretanto, em websites dinmicos em que a base de informao modifica-se de acordo com a interao do usurio, pode ser necessrio definir as operaes nas classes conceituais (ROSSI, 1997). Como o OOHDM um mtodo de projeto, os mtodos de classe para a obteno dos valores dos atributos de um objeto so gerados automaticamente. Caso seja necessria a realizao de operaes complexas, ento ser necessrio definir o mtodo correspondente na classe. A notao para a especificao de operaes de uma classe em OOHDM a seguinte: visibilidade nome (lista-parmetro) : expresso-resultado { propriedades } Visibilidade: Como nos atributos a visibilidade pode ser pblica ou privada, ou seja, disponvel ou no disponvel ao usurio. Nome: o identificador da operao. Sempre descrito com a primeira letra em minsculo.

54 Lista de parmetros: So os parmetro formais passados para operao. Cada parmetro descrito da seguinte forma: nome : tipo = valor default Nome: nome formal do parmetro Tipo: descreve o tipo de dado do parmetro, idem a atributo. Valor-default: Valor opcional atribudo ao parmetro. Se no houver a descrio do valor-default omitir o sinal de igual. Expresso-resultado: Determina o valor de retorno da operao. Caso no haja retorno de valor da operao, omite-se esta expresso. Propriedades: Idem a propriedade de atributo.

exibirInformacoes ( ) -calcularSalario ( ) -calcularAbono (abono: Real=(15,50)) verificaCPF ( ): Inteiro

Figura 35: Exemplos de Operaes de Classes em OOHDM

5.2.2 Generalizao

Generalizao/especializao indica que uma classe mais geral, conhecida como superclasse, possui caractersticas que so compartilhadas por classes mais especializadas, as subclasses. Generalizao definida por Rumbaugh (1994), como o relacionamento entre uma classe e uma ou mais verses refinadas dela. Por exemplo: Pessoa e a generalizao de Aluno, Professor e Coordenador que so especializaes de Pessoa. Podese considerar esta estrutura como uma estrutura " um" ou " um tipo de", por exemplo: Aluno um tipo de Pessoa.

55
Coordenador

Pessoa

Professor Aluno

Figura 36: Exemplo de Generalizao

Conforme descrito por Furlan (1998), pode-se haver na generalizao o uso restries para indicar condies semnticas entre as subclasses. Estas restries so descritas entre chaves < {...} >, separadas por vrgula < , >, e inseridas prximas ao tringulo, que representa a generalizao, que compartilhado pelas subclasses. Podem-se tambm descrever as restries prximas a uma linha tracejada que cruza as linhas da generalizao das subclasses envolvidas. De acordo com a UML as restries pode ser: Sobreposio: Pode haver a ocorrncia simultnea das subclasses. Disjuno: No pode haver a ocorrncia simultnea das subclasses. Completo: Todas as ocorrncias das subclasses da generalizao esto especificadas no diagrama. Incompleto: No h a especificao de todas as ocorrncias das subclasses da generalizao no diagrama.

Coordenador

Pessoa

Professor Aluno

{disjuno, completa}

Figura 37: Exemplo de Restries em Generalizao

56 A herana no OOHDM funciona da mesma forma que na OO, ou seja, atributos e operaes so herdados de uma superclasse. Contudo a herana de classes com atributos de mltiplas perspectivas sofrem algumas alteraes no OOHDM. Se uma subclasse possuir um atributo com o mesmo nome de um atributo com mltiplas perspectivas da superclasse, as novas perspectivas deste atributo sero adicionadas s perspectivas herdadas. Levando-se em considerao o exposto acima, s que agora ambos com perspectivas default. Neste caso a perspectiva default herdada passa a ser opcional e a nova perspectiva default torna-se obrigatria.

Pessoa cdigo: Inteiro nome: String descrio: [Text+, Imagem]

Professor descrio: [udio+]

Figura 38: Exemplo de Herana com mltiplas perspectivas

5.2.3 Relacionamentos

Tambm conhecido como Associaes, o meio utilizado para expressar o relacionamento entre classes. As associaes podem ser unrias (relao de uma classe consigo mesmo), binria (entre duas classes) e n-ria ou ternria (entre trs ou mais classes), (figura 39).

57
Localizao Geogrfica Localizao Geogrfica

Pessoa

possui

Cidade

Associao Binria

Associao Unria

Funcionrio

Questionrio

Projeto

Avaliao

Associao Ternria

Figura 39: Exemplos de Relacionamento entre Classes

Junto linha que representa o relacionamento tambm pode haver a especificao no nome do relacionamento. Na figura 39, temos o relacionamento possui entre a classe Pessoa e Cidade. Anexo ao nome pode haver um tringulo preenchido de preto, indicando a direo da leitura do relacionamento. No exemplo cito, Pessoa possui Cidade.

5.2.3.1 Cardinalidade

Expressa a quantidade de objetos (instncias de uma classe), aos quais, outro objeto pode estar relacionado. expressa por nmeros inteiros no negativos e quando se pretende especificar infinito se utiliza o asterisco < * >. Para se determinar um intervalo, utiliza-se da notao de multiplicidade mn..mx.

58
0..1 1 7 0..* * 1..* 1..6 Cardinalidade de 0 ou 1 (opcional) Exatamente 1 Exatamente 7 Cardinalidade de 0 at infinito Cardinalidade de 0 at infinito No mnimo 1, no mximo infinito No mnimo 1, no mximo 6

Figura 40: Exemplos de Cardinalidade de Relacionamentos

Na figura 41 mostra um exemplo de exemplo de Relacionamento entre classes em OOHDM, j com a cardinalidade expressa e o nome do relacionamento.

Curso

possui

1..*

Disciplina 1 tem * Alunos

Figura 41: Exemplo de Relacionamento com Cardinalidade

5.2.3.2 Classe de relacionamento

Se durante a modelagem da aplicao ocorrer necessidade de um relacionamento possuir atributos ou comportamentos prprios, constri-se uma classe de relacionamento. Uma classe de relacionamento possui a mesma representao que uma classe tradicional, porem est ligada ao relacionamento que a originou atravs de uma linha tracejada.

59
Professor 1..* * Estudante

Orientao titulao: String avaliao: Inteiro

Figura 42: Exemplo de Classe de relacionamento (VILAIN, 2002).

5.2.4 Agregao

Agregao o relacionamento uma-parte-de ou parte-todo onde um objeto composto por outros objetos, por exemplo: Motor parte do todo Veculo, ou ainda, Motor e uma parte de Veculo. Menos formalmente, uma estrutura de agregao considerada como uma estrutura tem-um, por exemplo: um Veculo tem um Motor (figura 43). A representao de agregao um losango vazio posicionado ao lado da classe que agrega a(s) outra(s). A cardinalidade da classe que agrega as demais sempre 1. Na outra ponta a cardinalidade segue os padres vistos anteriormente.

1 Veculo

1..* Motor

Figura 43: Exemplo de Agregao

Na agregao, os objetos que compem a classe que agregada podem existir sem a presena da classe que os herda. Por exemplo: Um motor pode existir se um veculo; Um equipamento pode existir sem um laboratrio.

60 A semntica do relacionamento Todo-parte pode variar de uma aplicao outra, podendo-se utilizar estruturas de agregao, estruturas de grupo, entre outros (ROSSI, 1997). Sendo a agregao um mecanismo importante de relacionamento, sugere-se que quando possvel se decomponha um objeto em partes.

5.2.5 Composio

A composio uma variante da agregao. Neste caso os objetos da classe agregada s existem se a superclasse existir. Se a superclasse for excluda as classes compostas que a constituem tambm so excludas. Uma composio denominada como uma dependncia forte entre classes. A representao da composio difere-se da agregao, apenas pelo fato do losango ser preenchido e no vazio como na agregao. Por sua vez cardinalidade idntica.

1
Disciplina

1..* Material

Figura 44: Exemplo de Composio

5.2.6 Objeto

Um objeto a instanciao de uma classe. O objeto possui as mesmas caractersticas bsicas da classe, ou seja: estado, identidade e comportamento. Seu estado descrito pelos atributos. Sua identidade ou nome uma propriedade para distingu-lo dos demais objetos. Seu comportamento definido por suas operaes ou mtodos. Em OOHDM um objeto representado de forma semelhante a uma classe. O nome do objeto sublinhado, minsculo, e composto do identificador do objeto, seguido de dois

61 pontos < : >, e o nome da classe. O nome do objeto opcional. Nesta situao no se descreve seus atributos e operaes. Os atributos e operaes do objeto so representados com as suas instanciaes.
chapec:Cidade nome: Chapec populao: 165.000 braso: braso_chapeco.jpg chapec:Cidade :Cidade

Figura 45: Exemplos de representao de Objetos em OOHDM

A figura 46 demonstra um exemplo do objeto A construo de um gigante da aplicao RMS Titanic! A compilao de uma tragdia que foi modelada com o OOHDM e implementada com Toolbook.

Figura 46: Exemplo de um Objeto hipermdia (HENNRICHS, 2000).

A figura 47 demonstra a associao da classe Embarcao com o objeto A construo de um gigante.

62
vai para Embarcao ttulo: String background: Imagem descrio: Texto 1

1..* Mdia descMdia: Texto mdia: [Imagem+, Vdeo, Animao, Som]

Figura 47: Associao da Classes Embarcao com seu objeto (HENNRICHS, 2000).

5.2.7 Diagrama de Objetos

No desenvolvimento da modelagem pode ocorrer o surgimento de determinados objetos que possuam caractersticas excepcionais, ou seja, que no foram consideradas em sua definio de classes. Em OOHDM prope-se a construo de um diagrama de objetos, diretamente no diagrama de classes, para expressar esta situao. Um diagrama de objetos o esquema de instncias de uma aplicao especfica e reflete a estrutura do esquema de classes (ROSSI, 1997). A elaborao de um diagrama de objetos mostra instncias excepcionais, isto , aquelas que no coincidem exatamente com as definies do esquema de classes. Neste diagrama pode-se acrescentar atributos a um objeto, mudar o tipo de algum dos atributos, refinar relacionamentos, entre outros. Como exemplo pode-se citar um professor visitante, que embora no faa parte do departamento, orienta trs estudantes.

63
orienta professor visitante: Pessoa nome: Antonio Carlos idade: 43 orienta

orienta

cristina: Estudante

bernardo: Estudante nome: Bernardo titulao: Graduao descrio: bernardo.bmp email: bernardo@uf.br classe: assistente

:Estudante

Figura 48: Exemplo de Diagrama de objetos (VILAIN, 2002).

5.2.8 Subsistemas

Um subsistema de acordo com Furlan (1998), um sistema subordinado dentro de um sistema maior sendo modelado como um pacote de componentes. Servem para representar um agrupamento de classes e relacionamentos que englobam um mesmo domnio. Quando juntos, tornam-se independentes do restante da aplicao, ou seja, so abstraes de um sistema conceitual completo (VILAIN, 2002). A representao de uma classe, de outro subsistema, em um subsistema a seguite: nome-subsistema::nome-classe. Na figura 49 estou fazendo referncia classe Professor que foi definida no subsistema Acadmico, sendo referenciada no subsistema Contabilidade.

Contabilidade Acadmico::Professor

Figura 49: Exemplo de classe de outro subsistema

64 5.2.9 Esquema Conceitual de Classes

O diagrama resultante da modelagem conceitual, segunda etapa do OOHDM, designado de Esquema Conceitual. No esquema conceitual esto representadas todas as classes e relacionamentos do domnio da aplicao, bem como tambm todos os mecanismos de refinamento descritos nesta etapa da modelagem. A figura 50 exibe a modelagem conceitual de uma aplicao hipermdia denominada de RMS Titanic! A compilao de uma tragdia. Observe que foi descrito no esquema o diagrama do objeto abertura, relacionado com a classe Menu Principal.

vai para abertura:Menu Princial mdia: Vdeo Embarcao ttulo: String background: Imagem descrio: Texto 1 Menu Principal ttulo: String background: Imagem sound: Som 1 1..* Mdia descMdia: Texto mdia: [Imagem+, Vdeo, Animao, Som] 1

mostra

1..10

passa para 1..3 Ajuda descrio: Texto figura: Imagem Localizao mapa: Imagem local: Texto

Figura 50: Esquema Conceitual da aplicao RMS Titanic! A compilao de uma tragdia (HENNRICHS, 2000)

A figura 51 demonstra o esquema conceitual para uma aplicao acadmica. A fim de se evitar a criao de uma classe apenas para se especificar um objeto, no caso Reitor, foi inserido o diagrama do objeto reitor, relacionado diretamente com a classe Professor.

65

Figura 51: Esquema Conceitual de uma aplicao acadmica (VILAIN, 2002).

66 5.3 MODELAGEM NAVEGACIONAL

Os websites e as webapps so aplicaes hipermdia projetadas para navegar atravs de um espao de informaes. A partir desta definio, pode-se determinar que o projeto da estrutura de navegao a etapa crucial da modelagem. A segunda fase do OOHDM (modelagem conceitual), prope a construo de um modelo conceitual, o qual focaliza as classes de objetos e relacionamentos do domnio da aplicao. Deste modelo conceitual podero originar-se vrios modelos navegacionais, ou seja, as informaes que sero apresentadas ao usurio e como ocorrer a navegao entre elas. Estes modelos navegacionais expressam diferentes vises navegacionais para um mesmo domnio, levando em considerao os perfis dos futuros usurios. Cada uma destas vises (na verdade, vises navegacionais), constituir num tipo distinto de aplicao.
Uma aplicao em OOHDM definida como vises navegacionais do modelo conceitual. Cada uma destas vises define um conjunto de contextos e classes navegacionais. Os contextos navegacionais expressam a estrutura navegacional geral da aplicao hipermdia, enquanto as classes navegacionais especificam os objetos que sero vistos pelo usurio (ROSSI, 1997).

Essa etapa da metodologia est subdividida nas seguintes etapas: esquema de classes navegacionais; esquema de contextos navegacionais; esquema de classes em contexto e; cartes de identificao dos objetos criados nesta etapa.

5.3.1 Esquema de classes navegacionais

Como definido anteriormente, uma aplicao pode possuir mais do que um modelo navegacional. Este modelo navegacional ou esquema navegacional composto de uma coleo de ns e elos que representam uma viso navegacional da aplicao. A este conjunto, a esta coleo, de ns e elos representados em um diagrama d-se o nome de esquema de classes navegacionais.

67 5.3.2 Ns Os ns so descritos por um grupo de atributos e um conjunto de mtodos que descrevem seu comportamento e ou operaes a efetuar. Um n uma classe navegacional. um conjunto de instncias que possuem caractersticas idnticas. Os ns so responsveis por armazenar informaes importantes, determinadas no projeto conceitual, para que se possa realizar determinadas tarefas.
Em um n, atributos das classes conceituais so mapeados para as classes navegacionais de acordo com o perfil do usurio e as tarefas que ir desempenhar, mas nem sempre uma classe conceitual mapeada diretamente para uma classe navegacional (COELHO, 1995).

Um n origina-se a partir de uma classe, um conjunto de classes ou de uma classe de relacionamento do esquema conceitual. A representao de um n semelhante representao de uma classe no esquema conceitual. O que o diferencia a incluso de uma linha vertical direita da identificao do nome do n (figura 52). O nome do n em negrito e centralizado e a primeira letra em maisculo. A exibio das propriedades de um n opcional, e quando especificadas devem ser descritas entre chaves < { ... } >, exibidas no mesmo quadro da identificao do n e alinhadas a esquerda.
Nome-n {autor=XXX} atributos mtodos/operaes

Nome-n atributos

Nome-n mtodos/operaes

Nome-n

Figura 52: Representao de um N em OOHDM.

5.3.2.1 Atributos

Os atributos de um n representam as propriedades de suas instncias. Os atributos podem ser de quatro tipos: aqueles que contm (ou referem-se a) informaes que sero

68 exibidas na aplicao (String, Inteiro, Texto, Imagem, Vdeo, entre outros), ncoras, ndices e listas. Na definio de uma classe n os atributos s podem ter uma perspectiva. No mapeamento de atributos com mltiplas perspectivas, somente a representao da perspectiva default obrigatria. As demais perspectivas se forem especificadas, devem ser mapeadas para atributos de nomes opcionais seguido do caractere asterisco < * > (figura 53).

Pessoa cdigo: Inteiro nome: String descrio: [Texto+, Imagem]

Pessoa cdigo: Inteiro nome: String descrio: Text imagem_descr: Imagem*

Figura 53: Mapeamento de uma Classe Conceitual em N

A notao para a representao de atributos de n idntica especificada em classes conceituais. Observe na figura 54 a representao de um tipo de atributo lista. Nela o atributo pacotes uma lista de ncoras composta da uma delas pelo nome da regio, nome da cidade, tipo de transporte do pacote e tempo de durao do pacote. Observe tambm que os descritores de tipo pac, cat, reg e cid foram descritos nas propriedades do n. Esta mesma notao pode ser descrita no esquema de classes conceituais.

Pacotes Tursticos Categoria X {from pac:Pacote_C, cat:Categoria, reg:Regio, cid:Cidade} nome: cat.nome descrio: cat.descrio foto:Imagem pacotes: list of (anchor <reg.nome cid.nome pac.transporte pac.durao>)

Figura 54: Representao de uma lista em um n (OLIVEIRA, 2003).

69 5.3.2.2 Operaes

Os comportamentos ou operaes de um n implementam: as reaes dos ns quando estes forem ativados durante a navegao; como os ns reagem quando uma ncora selecionada; e a maneira como interagem com os elos e suas interfaces. A especificao das operaes em um n opcional. Quando especificadas, possuem notao idntica a das operaes de classes conceituais, descrito anteriormente na etapa de modelagem conceitual.

5.3.3 Generalizao

Igualmente a modelagem conceitual, o ns so organizados em hierarquias de generalizao/especializao, onde subclasses herdam definies de suas super classes. A representao de generalizao/especializao semelhante descrita na modelagem conceitual. A figura 55 ilustra um exemplo.

Coordenador Pessoa Professor Aluno

Figura 55: Exemplo de generalizao/especializao de classes de ns.

5.3.4 Elos

Os elos ou relacionamentos navegacionais mapeiam os relacionamentos do esquema conceitual. Na elaborao do esquema de classes navegacionais no existem elos conectando trs ou mais ns. Somente ocorre a existncia de elos unrios ou binrios. Um elo unrio conecta um n a ele mesmo e um elo binrio conecta um n a outro n.

70 Os elos so representados graficamente no esquema de classes navegacionais atravs de uma seta indicando a direo que ocorrer a navegao. A direo da navegao pode ser unidirecional (uma nica direo) ou bidirecional (nas duas direes). Conforme descrito por Vilain (2002), alm de ser representada por um elo a navegao deve tambm ser representada por uma ncora ou ndice, especificada como atributo da classe navegacional. Adiante veremos detalhadamente a especificao de ncora e ndice. Outra caracterstica de um elo a sua cardinalidade. A notao para cardinalidade de elos idntica aplicada para relacionamentos no esquema conceitual. Quando um elo apresentar uma cardinalidade maior do que um, seus elementos podero ou no estar ordenados. No caso deles estarem ordenados deve-se especificar a notao < {ordenado} > ao lado do n que possui seu conjunto ordenado. A opo default no ordenado, ou seja, sem notao descrita no diagrama.
requer Professor {ordenado} 1..* ministra 1 1..* Disciplina

pertence 1..*

rea de Pesquisa

Figura 56: Exemplo de esquema de classes navegacionais (VILAIN, 2002).

5.3.5 ncoras e ndices

Na especificao das classes navegacionais, alm dos atributos que contm ou fazem referncia a informaes que sero exibidas ao usurio, tm-se os atributos do tipo: ncora e ndice. As ncoras e ndices em OOHDM so tratados como gatilhos navegacionais, ou seja, quando uma ncora ou ndice for disparado uma navegao ocorre. Os ndices fornecem acesso aos elementos de um contexto enquanto que as ncoras permitem acesso a um ndice ou a um elemento dentro de um contexto.

71 Um atributo do tipo ndice ou ncora para um ndice especificado a partir de um elo com cardinalidade um para muitos ou muitos (1..* ou *), enquanto que um atributo do tipo ncora representado por um elo com cardinalidade um (1). Os ndices possuem a seguinte sintaxe para a sua descrio:
nome-atributo-ndice : nome-tipo-ndice (parmetro-ndice)

A descrio das ncoras construda a partir da seguinte sintaxe:


nome-atributo-ncora : anchor (nome-tipo-ndice (parmetros-ndice)) ou nome-atributo-ncora : anchor (nome-tipo-contexto (parmetros-contexto), [elemento])

Determina Vilain (2002), que os nomes de ncoras de ndice e contexto devem ser nicos, ou seja, no podem ter o mesmo nome. Em ambas as situaes os nomes so escritos em letra minscula, porem os identificadores de ndice devem estar no plural e precedidos do termo < Idx >, e os de contexto no singular e precedidos do termo < Ctx >.

Professor classe: String rea-ind: Idx reas Pesquisa por Professor (self) disciplinas: anchor (Idx Disciplinas por Professor (self)) estud: anchor (Ctx Estudante por Professor (self))

Figura 57: Exemplo da representao de ncora e ndice (VILAIN, 2002).

Na figura 57 o atributo rea-ind representa um ndice do tipo rea de Pesquisa por Professor onde passado por parmetro o prprio professor (self). A passagem de parmetro opcional. Este ndice quando acionado apresenta as reas de pesquisa do professor. O atributo disciplina uma ncora para um ndice do tipo Disciplinas por Professor passando por parmetro o prprio professor. Quando disparada esta ncora apresenta as disciplinas ministradas pelo professor enviado pelo parmetro. O atributo estud uma ncora no contexto Estudante por Professor passando por parmetro o prprio professor. As ncoras so freqentemente representadas ao usurio atravs de objetos de interface, por exemplo: um boto, um link, um texto sublinhado, entre outros.

72 5.3.6 Agregao e Composio

A representao de agregao e composio no esquema de classes navegacionais semelhante representao no esquema conceitual, a nica diferena a separao a direita existente no retngulo de identificao da classe.

1 Veculo

1..* Motor
Disciplina

1..* Material

Figura 58: esquerda agregao de n e a direita composio de n no esquema de classes navegacionais do OOHDM.

5.3.7 Diagrama de objetos

O diagrama de objetos no esquema de classes navegacionais possui a mesma funo do descrito no esquema conceitual. As nicas diferenas esto na representao dos objetos que possuem a separao direita no retngulo de identificao do objeto e a seta indicativa da direo do elo.

orienta

professor visitante: Pessoa nome: Antonio Carlos idade: 43

orienta

orienta

cristina: Estudante

bernardo: Estudante nome: Bernardo titulao: Graduao descrio: bernardo.bmp email: bernardo@uf.br classe: assistente

:Estudante

Figura 59: Diagrama de objetos no esquema de classes navegacionais (VILAIN, 2002).

73 5.3.8 Diagrama do esquema de classes navegacionais O resultado final desta etapa da modelagem um diagrama do esquema de classes navegacionais derivado do esquema conceitual. Quando as aplicaes so modeladas para um nico perfil de usurio e no h planos de ampli-lo a outros, o esquema conceitual ser ento, muito semelhante ao esquema de classes navegacionais, ou seja, todas as classes ns e elos sero diretamente derivados de classes e relacionamentos conceituais (ROSSI, 1997).

Figura 60: Diagrama do esquema de classes navegacionais (VILAIN, 2002).

74 5.3.9 Classes em Contexto

Quando um n apresentar uma aparncia diferente e possuir ncoras e funcionalidades dessemelhantes nos seus objetos apresentados ao usurio em um determinado contexto, faz-se necessria criao de Classes em Contexto. Conforme Schwabe (2003), classes em contexto so classes especiais que decoram os ns. As classes em contexto so conectadas as classes navegacionais por meio de um elo hierrquico conforme representado na figura 61. Uma classe em contexto concebida graficamente por um retngulo dividido em quatro partes: A primeira apresenta seu identificador; Os atributos a serem adicionados a classes ficam na segunda parte; As novas operaes da classe navegacional ao qual este contexto est conectado ficaro na terceira parte e; A quarta parte especifica os contextos nos quais a classe em contexto participa. As partes que no possurem informaes a devero ser representadas, no entanto ficaro vazias.

Professor classe: String rea-ind: Idx reas Pesquisa por Professor (self) disciplinas: anchor (Idx Disciplinas por Professor (self)) estud: anchor (Ctx Estudante por Professor (self)) salrio_base: Real

Professor por rea prox_prof: anchor(prximo(self)) ant_prof: anchor(anterior(self)) Ctx Professor por rea

Figura 61: Classes em Contexto (VILAIN, 2002).

5.3.10 Esquema de Contextos de Navegao

Como o usurio ir explorar o espao hipermdia uma das principais qualidades de uma aplicao bem projeta. A modelagem de elos e ns, infelizmente, no garantem

75 sozinhos este objetivo. A elaborao de contextos de navegao necessria para enriquecer os ns e elos especificados no esquema de classes navegacionais. O esquema de contextos de navegao segundo Vilain (2002), tem por objetivo definir em quais contextos ser permitida a navegao entre as informaes e quais informaes sero apresentadas ao usurio. Destaca Rossi (1997), que enquanto o esquema de classes navegacionais define os relacionamentos entre os objetos navegacionais, o esquema de contextos de navegao define a navegao em geral. Um esquema de contexto de navegao formado pelas primitivas: estruturas de acesso, contexto de navegao e elos de navegao. As estruturas de acesso auxiliam o usurio a encontrar as informaes. Os contextos de navegao so os objetos que sero explorados pelo usurio. Por fim, os elos especificam como ocorrer a navegao.

5.3.10.1 Estruturas de Acesso

A fim de se obter acesso aos contextos de navegao se faz necessrio especificao de estruturas de acesso (ndice). Conforme Schwabe (2003), uma estrutura de acesso um conjunto de itens ordenados que funcionam como ndices e auxiliam o usurio a encontrar a informao desejada. Cada um desses itens deve possuir no mnimo um elemento ativvel (seletor ou ncora de interface), que aciona um elo para outro objeto.

Seletores ou ncoras de interface

Figura 62: Representao de seletor de estrutura de acesso (SCHWABE, 2003).

76 As estruturas de acesso so representadas graficamente por um retngulo com linhas tracejadas densas e sua identificao no interior deste retngulo, centralizado, e com a primeira letra em maisculo. Ressalta Vilain (2002), que de forma geral a identificao das estruturas de acesso feita no plural para determinar o acesso exclusivo aos elementos de uma classe navegacional em um determinado contexto. A figura 63 demonstra os tipos de estruturas de acesso.

Matrias

Estrutura de Acesso Simples. Utilizado para a maioria das estruturas de acesso convencionais. Estrutura de acesso com vrios critrios de ordenao. Utilizado quando uma estrutura de acesso possuir mais de tipo de ordenao de seus elementos. Menciona Vilain (2002), que independente do critrio de ordenao do ndice da estrutura de acesso, o acesso aos elementos do contexto feito de acordo com a ordenao do contexto e no do ndice da estrutura. Se no elo da ligao, da estrutura de acesso ao contexto, vier especificada a notao <ord>, isso indicar ento que os elementos do contexto sero ordenados com o mesmo critrio de ordenao da estrutura de acesso. Pode tambm ocorrer deste tipo de estrutura possuir como destino mais do que um contexto. Estrutura de acesso dinmica. Usada quando o usurio ou o sistema elabora consultas de forma arbitrria. Esta escolha ocorrer em tempo de execuo. Os campos que formam os parmetros deste tipo de consulta so expressos abaixo do nome da estrutura e colocados entre os sinais de maior e menor (<...>), e separados por vrgulas. Estrutura de acesso hierrquica. Representam um conjunto de ndices seqncias, onde a seleo em um nvel determina os elementos do prximo nvel.

Matrias

Matrias <param1, param2, param3>

Autores:Matrias

Figura 63: Representao dos tipos de estrutura de acesso (SCHWABE, 2003).

5.3.10.2 Contextos de navegao

Define-se por contexto de navegao, um conjunto de objetos relacionados com algum aspecto em particular. Estes objetos (ns, elos e outros contextos navegacionais), podem ser de uma nica classe navegacional ou de vrias classes (VILAIN, 2002). Mesmo o objeto estando em um contexto qualquer da navegao, ele ainda possui todas as suas caractersticas (atributos e operaes), definidas no esquema de classes navegacionais.

77 Como exemplo de contextos navegacionais podemos citar: todos os alunos que cursam uma determinada disciplina, os cursos oferecidos por uma rea de pesquisa, as disciplinas ministradas por um professor, entre outros. Os contextos de navegao determinam o conjunto de objetos de navegao acessveis ao usurio em cada momento da aplicao. funo tambm dos contextos de navegao, a classificao de seus objetos. A partir de um n ou elo, diferentes contextos de navegao podem ser criados, sendo que cada um destes contextos tem suas prprias formas de acesso e de navegao pelos seus elementos. Um contexto de navegao representado por um retngulo identificado e inserido dentro de um outro retngulo sombreado que indica a qual classe navegacional este contexto pertence. A quantidade de contextos representados dentro de uma classe navegacional definida pela modelagem da aplicao. A identificao de uma classe navegacional feita na parte superior esquerda do retngulo sombreado, escrita em itlico e com a primeira letra em maisculo.

Empresa Contexto navegacional Histrico

Classe navegacional

Figura 64: Representao de classe navegacional e contexto (OLIVEIRA, 2003).

Os contextos navegacionais podem possuir algumas caractersticas associadas a eles, o que os torna diferentes dos demais contextos. A representao de um tringulo preenchido na frente de um contexto de navegao indica que os elementos desse contexto podem possuir vrias formas de ordenao, por exemplo: ordenados por cdigo, em ordem alfabtica, entre outros. A representao de um pequeno quadrado preenchido e localizado no canto superior esquerdo da rea interna de um contexto, ir indicar que um ndice est associado a este contexto. Cita Vilain (2002), que quando um contexto associado a um elo com cardinalidade muitos ou um para muitos (* ou 1..*), tem-se a associao de um ndice a um contexto. Quando houver a ocorrncia de um contexto no qual o acesso a seus elementos restrito ou protegido, representa-se este atravs de uma elipse preenchida

78 anexada a frente do contexto navegacional. A representao de criao, alterao e excluso de objetos feita atravs de um retngulo com as bordas arredondadas e a sua extremidade direita preenchida com uma barra vertical. Uma linha tracejada, separando os contextos navegacionais, utilizada para demonstrar que no possvel a navegao de um elemento de um contexto para outro (figura 65).

Matria Alfabtico Criao Por Autor Seo=Esporte

Figura 65: Representao de contextos de navegao (SCHWABE, 2003).

Os contextos navegacionais so classificados de acordo com: a caracterizao de seus elementos; a permanncia de seus elementos no contexto e; a durao do contexto. Aborda-se abaixo cada um destes aspectos.

5.3.10.2.1 Caracterizao dos elementos de um contexto

Define as caractersticas dos elementos que o contexto agrupa. Pode ser de dois tipos: contextos arbitrrios e contextos no arbitrrios.

a) Contextos arbitrrios Os contextos arbitrrios tambm so conhecidos como contextos enumerados ou contextos extencionais. So os contextos em que o seu autor seleciona os elementos que

79 faro parte dele. Sendo que estes elementos podem pertencer a diversas classes. Como exemplo de contextos arbitrrios ou contexto enumerado tm-se os roteiros guiados. Os roteiros guiados ou visitas guiadas so utilizados para levar o usurio por uma seqncia pr-determinada de elementos. Esta seqncia pode ser previamente estabelecida (j citando os elementos a serem exibidos), ou ento estabelecer regras na aplicao que, quando executada, far a filtragem dos elementos a serem exibidos. Um roteiro guiado possui por caractersticas: um ponto de entrada; um ponto de sada; geralmente so utilizados para contar uma histria; exibem a possibilidade de navegao passo-a-passo e; raramente podem permitir desvios entre os elementos a serem exibidos. A figura 66 exibe o esquema de contexto navegacional para mostrar o contexto arbitrrio Esportistas Radicais que h em uma instituio de ensino. Este contexto criado dinamicamente no momento da execuo da aplicao, fazendo a filtragem de Professores e Estudantes que praticam esportes radicais. Neste exemplo os elementos so escolhidos classes distintas: Professor e Estudante.

Professor + Estudante Menu Principal Praticantes de esportes radicais Esportistas radicais

Figura 66: Exemplo de contexto arbitrrio de vrias classes (VILAIN, 2002).

Conforme descrito por Vilain (2002), se em algum momento da modelagem houver a necessidade de se especificar explicitamente os objetos das classes navegacionais acessados por um contexto arbitrrio deve-se proceder da seguinte forma. Dentro da representao do contexto, os objetos so representados por retngulos com as bordas arredondadas (figura 67).

80
Laboratrio Menu Principal Laboratrios do trreo Trreo Lab. de Redes Lab. de Microeletrnica

Figura 67: Exemplo de contexto de objetos (VILAIN, 2002).

b) Contextos no arbitrrios

Conhecido tambm como contexto derivado. um contexto cujos elementos originam-se a partir de regras de seleo. Contextos deste tipo podem ser derivados de classe e derivados de elo. Os contextos derivados de classe so formados por objetos pertencentes a uma mesma classe e que satisfazem uma pr-condio. Por exemplo, da classe Publicao On-line cria-se o contexto Matrias publicadas hoje. Contextos derivados de elo so constitudos por objetos de uma mesma classe que possui uma relao um para muitos com outra classe. Por exemplo, da classe Publicao On-line que possui uma relao um para muitos com a classe Redatores cria-se o contexto Todas as matrias do redator Joo Marques. Um grupo de contexto um conjunto de contextos criados de forma no arbitrria de acordo com uma regra de seleo dos elementos que faro parte destes contextos. Esta regra de seleo expressa de forma parametrizada. Enfatiza Vilain (2002), que o uso de grupo de contexto simplifica em muito a representao do contexto navegacional. Por exemplo, o grupo de contexto Professor por Titulao engloba o conjunto de contextos Professor com titulao igual a Doutorado, Professor com titulao igual a Mestre, entre outros. A representao de um grupo de contexto feita de forma similar a um contexto navegacional simples (figura 68).

81
Professor Menu Principal Titulaes Professores por Titulao

Figura 68: Exemplo de grupo de contexto (VILAIN, 2002).

5.3.10.2.2 Permanncia dos elementos no contexto

A permanncia dos elementos no contexto define em que momento os elementos destes contextos so criados. Ela pode ser de dois tipos: estticos ou dinmicos.

a) Contextos estticos So aqueles contextos cujos elementos so definidos na modelagem da aplicao. Cita-se como exemplo a modelagem de um website esttico.

b) Contextos dinmicos Ao contrrio do contexto esttico, no contexto dinmico seus elementos so definidos ou alterados no momento da execuo da aplicao. Por exemplo, uma webapp. A criao de um contexto dinmico pode ser feita de duas formas: criado pela aplicao com base em um algoritmo definido ou criado pelo prprio usurio da aplicao por meio de escolhas que ele efetue na aplicao. Quando da modelagem das classes navegacionais houver a necessidade da representao de um contexto para criao, alterao ou excluso de um objeto faz-se a representao destes objetos dentro classe navegacional. De acordo com Vilain (2002), a existncia destes tipos de contextos juntamente com outros dentro de uma classe navegacional, torna todos os contextos desta classe dinmicos. Na figura 68 a presena dos

82 contextos de criao, alterao e remoo dentro da classe Reserva, torna os contextos por ndice Cidade e Datas de Sada dinmicos.

Reserva Menu Principal Reservas Cidade Datas de Sada Criao Alterao Remoo

Figura 69: Exemplo de contexto dinmico (OLIVEIRA, 2003).

Quando ocorrer de um contexto ser criado como resultado de uma consulta realizada durante a execuo da aplicao, chamamos este de Contexto por Consulta. Um contexto por consulta um contexto dinmico, pois os parmetros desta consulta no podem ser previstos, pelo sistema, antes de sua execuo (VILAIN, 2002). A figura 69 demonstra um exemplo de contexto por consulta. Nela a consulta realizada a classe Projeto de Pesquisa feita pelo contexto por Consulta, o qual possui como possveis parmetros de filtragem: professor, aluno, rea ou data. A escolha de qual ou quais feita somente durante a execuo da aplicao.

Projeto de Pesquisa Menu Principal Projetos por consulta <professor, aluno, rea, data> por Consulta

Figura 70: Exemplo de contexto por consulta (VILAIN, 2002).

83 5.3.10.2.3 Durao do contexto

Como o prprio nome menciona a durao de um contexto determina o seu tempo de vida ou tempo de sua existncia. A durao do contexto pode ser de dois tipos: contexto persistente e contexto no persistente. Um contexto persistente, aps ter sido criado, pode ser acessado por sesses do browser, posterior a sua criao. Evidentemente que para isto ocorrer ser necessrio salvar todas as informaes deste contexto atravs de tecnologias como cache, cookies, entre outras. considerado contexto no persistente aquele contexto que tem seu tempo de vida atrelado ao tempo de vida da sesso do browser, ou seja, se for trocada a sesso do navegador o contexto deixa de existir. Menciona Vilain (2002), que no existe uma representao explicita para esboar contextos persistentes e no persistentes. Por default todos os contextos so do tipo no persistentes. O nico cuidado que se deve ter deixar disponvel o contexto para a operao de salvamento, caso queira tornar um contexto persistente.

5.3.10.3 Elos de navegao do esquema de contextos navegacionais

No esquema de contextos navegacionais, os elos so responsveis por representar de que forma dar-se- a navegao s estruturas de acesso e aos contextos navegacionais. Em geral os elos so representados por uma seta indicando a direo da navegao. Contudo, nesta fase da modelagem os elos podem possuir algumas caractersticas prprias. Na representao grfica, quando um elo iniciado por um crculo preenchido indica que a estrutura de acesso ou contextos, ao qual o elo aponta, pode ser acessado a partir de qualquer local da aplicao. Essa notao grfica utilizada para se representar os Landmarks (botes e ou ncoras de navegao). Se houver a representao de uma seta em ambos os lados do elo, denotar a possibilidade de retorno a instncia de incio da navegao. Caso em alguma das extremidades do elo houver a representao de duas setas, uma atrs da outra, isto indicar o retorno instncia da qual a navegao foi iniciada (figura 71). Um elo de navegao pode apontar para um contexto especfico de navegao

84 (referindo-se apenas a aquele contexto), ou ento apontar para uma classe navegacional como um todo (referenciando-se aos contextos daquela classe).

Matria Relacionada Matrias por consulta <ttulo, contedo e/ou resumo> por Consulta

Menu Principal

Sees:Matrias

<ord>

por Seo

Matrias em Destaque

em Destaque por Autor Autor

Autores

Alfabtico

Figura 71: Exemplos de elos de navegao (SCHWABE, 2003).

De acordo com a representao dos elos da figura 71, pode-se observar que o Menu Principal, Autores, Matrias em Destaque, Matrias por Seo e Matrias por Consulta, so acessados de qualquer ponto da aplicao (landmarks). A estrutura de acesso Sees:Matrias hierrquica e ordenada por critrios especficos. Os critrios de ordenao desta estrutura de acesso so transferidos ao contexto navegacional Matrias por Seo pela notao <ord> que h no elo. Estes critrios de ordenao somente so enviados ao contexto se ele for acessado pela estrutura de acesso em questo. Entretanto se o contexto Matrias por Seo for solicitado por outro caminho, ordenao dos elementos ocorrer de acordo com o critrio de ordenao default. A partir do contexto Matrias por Autor possvel deslocar-se ao contexto Autor Alfabtico, sendo que aps a execuo deste a interao retornar automaticamente ao contexto Matrias por Autor. O deslocamento do contexto Autor Alfabtico para Matrias por Autor permitido s que o retorno somente ocorrer se for solicitado.

85 Os elos de navegao tambm podem conter parmetros associados. Estes parmetros determinam um elemento de um contexto, um elemento de um grupo de contexto ou um contexto de um grupo de contextos (VILAIN, 2002). Os parmetros associados ao ele so expressos de junto ao ele correspondente.

Laboratrio Menu Principal Laboratrio=Lab. de Redes Alfabtico Laboratrios Laboratrio=ES:Lab. de ES por rea de Pesquisa rea=redes

Figura 72: Passagem de parmetro em elos de navegao (VILAIN, 2002).

Na figura 72, o primeiro elo (de cima para baixo) indica que o laboratrio de redes ser acessado diretamente a partir do menu principal. A partir deste laboratrio os demais podero ser exibidos. O terceiro elo indica que o objeto Lab. de ES do contexto Laboratrio por rea de Pesquisa igual a ES ser acessado diretamente do menu principal. O ltimo elo demonstra que o ndice do contexto Laboratrio por rea de Pesquisa ser redes, e que est poder ser acessado direto do menu principal.

Nos contextos navegacionais a navegao pode ser realizada das seguintes formas: Navegao Seqencial: Os elementos so acessados de forma seqencial e prestabelecida. Define-se o primeiro e o ltimo elemento, bem como tambm, o prximo e o anterior elemento de cada elemento de um contexto; Navegao Circular: Difere-se da navegao seqencial por no possuir o primeiro e o ltimo elemento a ser navegado, ou seja, o acesso aos elementos feito de forma circular;

86 Navegao Livre: O prprio nome j o define. O acesso aos elementos no precisa ser seqencial. Um elemento pode ser acessado a partir de qualquer outro elemento; Navegao por ndice: Os elementos do contexto somente so acessados a partir de um ndice e ao ndice se retorna ao fim de cada acesso; Combinao de navegao por ndice com Circular ou Seqencial: Os elementos so acessados por um ndice ou pelo elemento prximo ou anterior.

5.3.11 Generalizao de Contextos

Generalizao de contextos o nome dado representao de estruturas de generalizao no esquema de contextos navegacionais. utilizado para indicar que as subclasses de uma superclasse navegacional apresentam um ou mais contextos navegacionais em comum. (VILAIN, 2002). A notao grfica de generalizao de contextos feito de forma semelhante notao grfica de classes navegacionais. Contudo a cor de fundo das subclasses devem ser mais fracas que a cor de fundo da superclasse. Os contextos das subclasses so inseridos dentro de suas subclasses respectivas (figura 73).

Acadmico Alfabtico Professor por rea de Pesquisa

Estudante por Professor

Figura 73: Generalizao de contextos (VILAIN, 2002).

87 5.3.12 Cartes de identificao

Os cartes de identificao so ferramentas que o OOHDM propem como auxilio na modelagem de uma aplicao. Estes cartes documentam todos os aspectos de contextos navegacionais e estruturas de acesso.

Contexto: Professor por rea Parmetros: a:rea Elementos: p:Professor where p associado_a a Classe em contexto: Ordenao: por p.nome, ascendente Navegao interna: por ndice (Idx Professores por rea(a)) Operaes: Usurios: alunos Comentrios: Permisso: leitura

Figura 74: Carto de contexto ou grupo de contexto (VILAIN, 2002).

Estrutura de Acesso: Professores Parmetros: Elementos: p:Professor Classe em contexto: Atributos: p.nome p.grau Restries de Uso Usurios: alunos Comentrios: Depende de: Nav_Professor Influencia: ADV Professores Permisso: leitura Destino: Ctx Professor Alfabtico (self) Ctx Professor por Grau (self.grau)

Ordenao: por p.nome, ascendente

Figura 75: Carto de estrutura de acesso (VILAIN, 2002).

88 5.3.13 Diagrama do Esquema de Contextos de Navegao

O diagrama final do esquema de contextos de navegao dever apresentar todas as classes navegacionais, os contextos destas classes e os elos de navegao entre as classes e contextos. Quando o esquema de contextos for demasiadamente grande faz-se uso da representao de subsistemas e posteriormente concebe-se graficamente cada esquema de contexto de navegao destes subsistemas. Na figura 76 apresentado um exemplo do diagrama do esquema de contextos de navegao de uma aplicao. Na figura 77 e 78 exibido um diagrama de esquema de contextos de navegao fazendo-se uso do recurso de subsistemas.

Professor Alfabtico Professores por rea de Pesquisa por Laboratrio por Projeto de Pesquisa Projeto de Pesquisa Projetos de Pesquisa Menu Principal Todos por Professor por Laboratrio Laboratrio Laboratrios Alfabtico por rea de Pesquisa rea de Pesquisa reas de Pesquisa Alfabtico por Professor

Figura 76: Diagrama do esquema de contextos de navegao (VILAIN, 2002).

89
Conhea o DI Informao DI

Documentos Cursos Disciplinas deste Semestre Menu Principal reas de Pesquisa reas Pessoas Recursos Produo Oportunidades Novidades

Figura 77: Diagrama do esquema de contextos com subsistema (PUC-RIO, 2002).

Subsistema reas rea Pesquisa reas de Pesquisa reas Alfabtico

Cursos Pessoas Recursos

Figura 78: Diagrama do esquema de contextos do subsistema reas (PUC-RIO, 2002).

90 5.4 PROJETO DE INTERFACE ABSTRATA

De acordo com Rossi (1997), a construo da interface um aspecto crtico na elaborao de uma aplicao hipermdia. Menciona tambm que apesar das bibliotecas GUI facilitarem as tarefas de definio de objetos e programao das transformaes de interface, no se deve descartar a utilizao de um modelo antes da implementao. O projeto de interface abstrata do modelo OOHDM tem essa funo. Nesta etapa o objetivo definir como estaro perceptveis os objetos de interface, suas propriedades e transformaes, no se preocupando com qual ser o ambiente e a forma de implementao da aplicao. Estes objetos perceptveis na interface so mapeados dos objetos de navegao e podem conter objetos ativveis, que correspondem a ncoras e quando ativados causam uma modificao no contexto de percepo. Um contexto de percepo o foco de ateno, composto de objetos perceptveis e demonstra como ocorre a navegao. O projeto de interface abstrata ainda promove o reuso de objetos e a independncia de dilogos (VILAIN, 2002). O projeto de interface abstrata pode ser utilizado como forma de comunicao entre projetistas, designers e implementadores, bem como tambm ser utilizado para validar a implementao e ou ainda, como referncia durante a manuteno. Implicam na definio de um projeto de interface abstrata trs etapas: Definio de ADVs (Viso Abstrata de Dados); Elaborao de diagramas de configurao e; A especificao dos ADVcharts.

5.4.1 ADV (Abstract Data View)

Os ADVs so utilizados para especificar o modelo de interface abstrata, ou seja, a aparncia e interface dos objetos da aplicao. No entanto os ADVs no conseguem fazer o controle da aplicao e nem interagir com as estruturas de dados. Os ADVs suportam apenas eventos externos, desta maneira os ADOs (Abstract Data Objects) vm auxiliar os ADVs, fazendo este controle e interao com os dados da aplicao. Os ADOs esto sempre associados a um ou mais ADVs. Os objetos navegacionais (ns, elos, classes em

91 contexto e estruturas de dados), so interpretados como ADOs e possuiro associao a ADVs, ou seja, para cada objeto navegacional necessrio especificar um ADV.

ADV Personel personelCategoryIdx: list of (anchor(Personel)) name: String degree: String bio: text description: Image email: anchor(self.Email) homePage: anchor(self.UrlHomePage)

Figura 79: Interface e o ADV Pessoa (SCHWABE, 1998).

92 5.4.2 Diagramas de Configurao

Os eventos que um ADVmanipula e que so disparados pelo usurio, durante a interao com a interface, so representados no diagrama de configurao. Os diagramas de configurao so responsveis por representar os relacionamentos entre os objetos de interface e os objetos navegacionais (SCHAWABE, 2003). Nesta etapa os esforos so todos voltados no modo como o usurio interagir com a aplicao e em especial com os objetos da interface que acionaro a navegao.

ADV Pintura mouseDuplo Clicado ADV Imagem pegarImagem

N Pintura

Exibir

ADV Texto

pegarTexto

mouseClicado

ADV Boto

ncoraSelec (pintor)

Figura 80: Diagrama de configurao (ROSSI, 1997).

A figura 80 demonstra o diagrama de configurao do ADV pintura e seu ADO, o n Pintura. Quando for efetuado o evento de duplo clique sobre o ADV Imagem ele ir se comunicar com seu ADO a fim de pegar a Imagem. Da maneira semelhante ocorre com o ADV Boto, no entanto uma requisio ncora pintor enviada solicitando que ela inicia a navegao do elo associado a ela. O ADV Texto sofre sua ao no momento em que exibido.

93 5.4.3 ADVcharts

Os ADVcharts demonstram as transformaes que os ADVs iro sofrer, ou seja, representam a estrutura e o comportamento dos objetos navegacionais. So responsveis pelas mudanas na interface com usurio e nos objetos navegacionais. Toda a aplicao pode ser expressa pelos ADVcharts, pois cada ADVchart especificado refere-se a uma tela da interface. Nos ADVcharts podem ser expressos outros ADVs, estados, atributos e transies.

Os estados de um ADVchart representam apenas o comportamento de um objeto navegacional. So conectados por transies e modificados por eventos gerados pelo usurio (externos), ou gerados pelas transies (internos) (VILAIN, 2002).

ADVs e estados podem ser agrupados pelos modos AND e XOR. Quando aninhados em XOR so mutuamente exclusivos, ou seja, somente um ir aparecer na interface. Quando aninhados em AND, ambos aparecero ao mesmo tempo na interface. Um AND representado por uma linha tracejada entre as estruturas e um XOR por uma linha contgua (CORTS, 1995).

As transies nos ADVcharts so declaradas atravs de um evento que iro ativar a transio, pr-condies (devem ocorrer antes da ativao), e ps-condies (aes executadas aps a ativao).

Enquanto os ADVs so representados por retngulos, os estados so graficamente indicados por retngulos com bordas arredondadas e as transies por linhas com setas direcionadas.

94
Pintura Transies: 1: Evento: Exibir Pr-cond: Ps-cond: contextoPerceptivo= contextoPerceptivo+Pintura 2: Evento: mouseClicado Pr-cond: foco(Boto) Ps-cond: contextoPerceptivo= contextoPerceptivo-Pintura

Desativado 2 1 Ativado Imagem

Texto

Boto

Figura 81: ADVchart Pintor (ROSSI, 1997).

Na figura 81 temos a representao do ADVchart Pintor, do diagrama de configurao da figura 80. Quando o evento externo Exibir for ativado, o ADVchart Pintura passar do estado desativado para ativado e ser adicionado ao contextoPerceptivo (+Pintura), fazendo aparecer na Interface o ADV Imagem, Texto e Boto. Todos juntos, pois esto aninhados por AND (linha tracejada). Quando o foco estiver sobre o ADV Boto e o evento mouseClicado for acionado, ser retirado do contextoPerceptivo o ADVchart Pintura (-Pintura), fazendo ele sair da Interface e passar para o estado desativado.

95 5.5 IMPLEMENTAO

Depois de concluda todas as fases anteriores do OOHDM, chega-se ao momento da implementao da aplicao. Atravs do projeto navegacional e do projeto de interface, efetua-se traduo para o ambiente de implementao. de responsabilidade desta fase final definir qual ser o ambiente de implementao, bem como a forma pela qual ser efetuado o mapeamento dos objetos navegacionais e de interface para o ambiente escolhido. Como ambiente de implementao da aplicao, h vrios disponveis no mercado para escolha. Especificamente para o modelo OOHDM foram elaboradas alguns ambientes de implementao, so eles: OOHDM-Web, OOHDM-XWeb e o OOHDM-Java2. O ambiente OOHDM-Web um ambiente baseado na linguagem Lua. O OOHDM-XWeb baseado tambm na linguagem Lua e na XSLT, faz uso da linguagem de marcao OOHDM-ML que foi elaborada e baseada no XML. O ambiente OOHDM-Java2 um framework baseado na plataforma J2EE. Contudo nada impede o implementador em escolher outras ferramentas de implementao que no sejam as citadas acima. Para a construo de aplicaes hipermdia em mdias pticas, pode-se optar pelo Director, Flash, Toolbook, Multimedia Builder, entre outros disponveis no mercado. Para a implementao na Web pode-se utilizar o tradicional HTML junto com o PHP, e um SGBD como o MySQL, por exemplo. Lembra Rossi (1997), que quando o ambiente de implementao completamente orientado a objeto (OO), a traduo de uma modelagem OOHDM pode ser mais simples. Feita a escolha do ambiente de implementao e de suas ferramentas, tem-se que efetuar o mapeamento dos objetos navegacionais e relacionamentos para tabelas.

5.5.1 Mapeamento dos objetos navegacionais

As classes conceituais so mapeadas para tabelas do modelo relacional, onde a partir de cada classes obtida uma tabela diferente. A regra a ser seguida para este mapeamento simples. Para cada atributo do objeto, contido na classe, um campo

96 definido na tabela. Para atributos com mltiplas perspectivas uma tabela auxiliar criada, fazendo-se referncia desta tabela auxiliar a tabela original (VILAIN, 2002).

5.5.2 Mapeamento dos relacionamentos

Os relacionamentos um para muitos (1..*), so mapeados para uma chave estrangeira (Foreign Key ou FK), na tabela que refere-se classe do lado muitos (*). Em relacionamentos muitos para muitos (*..*), uma nova tabela criada, onde os campos desta tabela so chaves das tabelas que referem-se s classes em questo.

97 6. CONCLUSO O presente trabalho teve como objetivo apresentar um estudo do mtodo OOHDM para a engenharia de desenvolvimento de Websites. Uma coleta inicial de bibliografias a serem pesquisadas sobre o tema acarretou na necessidade de se estudar conceitos elementares para o desenvolvimento deste. Cito como exemplo o estudo da multimdia e da hipermdia, elementos dos quais os Websites se utilizam amplamente. Esses conceitos bsicos foram de enorme relevncia para a compreenso do mtodo de engenharia a ser estudado. Uma das principais motivaes para o desenvolvimento da presente pesquisa foi o fato de o autor deste, j ter efetuado um trabalho cientfico1 sobre o mtodo OOHDM. Contudo na poca da realizao dessa primeira pesquisa, o OOHDM estava em sua primeira verso e o foco da aplicao foi o desenvolvimento de um CD-ROM. O mtodo OOHDM trata os componentes de um Websites atravs dos paradigmas da orientao a objetos. Este foi um dos pontos fundamentais que levaram ao estudo deste mtodo. Pois, como os Websites utilizam-se de hipermdia, e a hipermdia baseia-se em objetos multimdia, nada melhor do que um mtodo orientado a objetos para manipular os componentes de um site web. Quando criado, o OOHDM utilizava-se da OMT de Rumbaugh. No entanto, atualmente, a nova verso do mtodo OOHDM modela todos seus esquemas e diagramas tomando como base a UML. Desta forma a modelagem da aplicao tornou-se muito mais prtica, moderna e visivelmente organizada. Essa evoluo veio demonstrar que o mtodo estudado est em constante desenvolvimento e aperfeioamento. O estudo detalhado do mtodo OOHDM, em todas as suas cinco etapas de crescimento e aperfeioamento de um projeto hipermdia, demonstrou que o desenvolvimento de um Website no deve ser diferente do que o desenvolvimento de um software tradicional. Ou seja. Primeiro coleta-se requisitos para posteriormente analisar e modelar esses dados, e por fim implementar e dar manuteno. O mtodo estudado mostrase muito eficiente no que se prope a fazer. Em cada uma de suas cinco fases, um novo modelo criado ou aperfeioado, e quando algo passvel de mudana pode-se recuar e verificar onde essa mudana ira afetar.
1

HENNRICHS, Jean Carlos. Modelagem e desenvolvimento de um aplicativo hipermdia sobre o RMS Titanic, usando a metodologia OOHDM e software de autoria. Trabalho de Concluso de Curso (Graduao em Cincia da Computao), Universidade do Oeste de Santa Catarina, Campus de Chapec, Chapec, 2000.

98 No buscou-se neste trabalho avaliar de forma prtica se o mtodo OOHDM realmente to poderoso quanto cito em bibliografias. No entanto, pelas pesquisas efetuadas pode-se concluir que realmente uma excelente ferramenta de engenharia para o auxilio na elaborao e desenvolvimento de aplicaes hipermdia, sejam essas Websites, WebApps, CD-ROMs ou qualquer outra aplicao que venha a utilizar elementos de hipermdia e multimdia. Resta salientar que o objetivo proposto foi alcanado. Pesquisou-se os conceitos fundamentais de multimdia e hipermdia, avanando para Internet, sites estticos e dinmicos, Websites e WebApps. Apresentou-se a necessidade de efetuar a modelagem para aplicaes web e por fim o mtodo OOHDM com todas as suas cinco fases. Cada uma dessas fases fora apresentada de forma descritiva e quando possvel com elementos visuais e diagramas, a fim de facilitar a compreenso do mtodo como um todo.

6.1 TRABALHOS FUTUROS Uma pesquisa extra sobre os cartes de documentao em cada uma das fases do OOHDM se faz necessrio, pois os mesmos no foram abordados neste trabalho. A implementao de um pequeno Website ou WebApp a fim de avaliar o mtodo tambm uma tima sugesto para um trabalho futuro, pois dessa forma poderiam surgir alguns problemas e ocasies que colocaria a prova o mtodo OOHDM.

99 REFERNCIAS BIBLIOGRFICAS

AGUIAR, Snia. Desatando os ns da rede. Rio de Janeiro, 1997. Ed. Senac Nacional. BADGETT, Tom. SANDLER, Corey. Criando multimdia em seu PC. So Paulo, 1994. Ed. Makron Books. BUGAY, Edson Luiz; ULBRICHT, Vnia Ribas. Hipermdia. Florianpolis, 2000. Ed. Visual Books. CENTRO DE COMPUTAO DA UNICAMP. Projeto de Aplicaes Web. Campinas, 2002. Disponvel em: <http://www.ccuec.unicamp.br/treinamentos/webpro/arquitetura_ informacao/arquitetura_informacao_hipermidia_multimidia.html>. Acesso em: 13 Jul. 2004. COELHO, Marcelo de Miranda. O Uso de Estruturas Navegacionais e Vistas Abstratas de Dados no OOHDM e Conceitos de Objetos Multimdia para a Construo de uma Aplicao. 1997 Disponvel por WWW em http://tathy.comp.ita.cta.br/coelho/ (23 Dez. 1999). CONALLEN, Jim. Desenvolvendo aplicaes Web com UML. Rio de Janeiro, 2003. Ed. Campus. FURLAN, Jos Davi. Modelagem de Objetos atravs da UML. So Paulo, 1998. Ed. Makron Books. GERTLER, Nat. Multimdia Ilustrada. Rio de Janeiro, 1995. Ed. Axcel Books. HENNRICHS, Jean Carlos. Modelagem e desenvolvimento de um aplicativo hipermdia sobre o RMS Titanic, usando a metodologia OOHDM e software de autoria. Trabalho de Concluso de Curso (Graduao em Cincia da Computao), Universidade do Oeste de Santa Catarina, Campus de Chapec, Chapec, 2000. JAMHOUR, Edgar. Banco de Dados e Web. In: VII Escola de Informtica da SBC regional Sul, 1999, Novo Hamburgo. Anais VIII Escola de Informtica da SBC regional Sul. Novo Hamburgo: Departamento de Informtica da Federao de Estabelecimentos de Ensino Superior em Novo Hamburgo (FEEVALE), 1999. p. 55-73. KEEP, Christopher; McLAUGHLIN, Tim; PARMAR, Robin. Hypertext. The Electronic Labyrinth. Disponvel em: <http://jefferson.village.virginia.edu/elab/ hfl0037.html>. Acesso em: 16 Jun. 2004. LINDSTRON, Robert L. Guia Business Week para Apresentaes em Multimdia. So Paulo, 1996. Ed. Makron Books. MELLO, Luis Csar de. Banco de Dados Internet. Maring: Centro Universitrio de Maring, 2002. Disponvel em: <http://www.inf.cesumar.br/pos/ambientes2002/ arq.htm>. Acesso em: 10 jun. 2004.

100 OLIVEIRA, Jacqueline Augusto de. LARA, Silvana Maria Afonso de. VIEIRA, Victor Hugo. Agncia de Viagens: Modelagem utilizando OOHDM. Universidade de So Paulo, So Paulo, 2003. PONTIFCIA UNIVERSIDADE CATLICA DO RIO DE JANEIRO. Site Departamento de Informtica. Rio de Janeiro, 2002. Disponvel em: <http://www.telemidia. puc-rio.br/oohdm/Vilain.ZIP>. Acesso em: 29 Out. 2003. ROSENBORG, Victoria. Guia de Multimdia. 1992. Ed. Berkeley. ROSSI, Gustavo H. OOHDM. 1996. Disponvel em: <http://www-lifia.info.unlp.edu.ar/ ~fer/oohdm/>. Acesso em: 27 Fev. 2000. ______. OOHDM. 1997. Disponvel em: <http://www.inf.puc-rio.br/~schwabe/Tese_ Rossi/>. Acesso em: 27 Fev. 2000. RUMBAUGH, James. BLAHA, Michael. PREMERLANI, William. EDDY, Frederick. LORENSEN, William. Modelagem e projetos Baseados em Objetos. Rio de Janeiro, 1994. Ed. Campus. SILVA, Luciano Carlos da. Banco de Dados para Web: do planejamento a implementao. So Paulo, 2001. Ed. rica. SCHWABE, Daniel. Autoria de Aplicaes Hipermdia. Departamento de Informtica, PUC Rio, Rio de Janeiro, 2003. Disponvel em: <http://coweb.icmc.usp.br/coweb/upload/ 136/Aula01_OOHDM.zip>. Acesso em: 03 Out. 2004. ______. The Object Oriented Hypermedia Design Model (OOHDM). 2000 Disponvel em: <http://www.telemidia.puc-rio.br/oohdm/oohdm.html>. Acesso em: 30 Fev. 2000. ______. The Summary of the OOHDM Methodology. OOHDM Wiki, 2003. Disponvel em: <http://www.oohdm.inf.puc-rio.br:8668/space/resumo+do+ OOHDM>. Acesso em: 26 Out 2003. ______; ROSSI, Gustavo; BARBOSA, Simone D.J. Systematic Hypermedia Application Design with OOHDM. In: HYPERTEXT '96, 1996, Washington DC USA. Hypertext '96, Washington DC USA: ACM Inc., 1996. p.116-127. ______; ______. Developing Hypermedia Applications using OOHDM. In: HYPERTEXT '98, 1998, Pittsburg USA. Hypertext '98, Pittsburg USA: Workshop on Hypermedia Development Processes, Methods and Models, 1998. SOARES, Luiz Fernando Gomes; TUCHERMAN, Luiz; CASANOVA, Marco Antonio, NUNES, Paulo Roberto Rosa Lopes. Fundamentos de Sistemas Multimdia. In: VIII Escola de Computao, 1992, Gramado RS. VILAIN, Patrcia; SCHWABE, Daniel; GELL, Natacha. Modelagem OOHDM. Disponvel em: <http://www.telemidia.puc-rio.br/oohdm/Vilain.ZIP>. Acesso em: 29 Out. 2003.

101 ______; ______. Notao do Mtodo OOHDM verso 2.0. Fev. 2002. Disponvel em: <http://www.telemidia.puc-rio.br/oohdm/Notacao_OOHDM.zip>. Acesso em: 29 Out. 2003. WIKIPEDIA, the free encyclopedia. 2004. Disponvel em: <http://en.wikipedia.org/wiki/ Main_Page>. Acesso em: 30 Ago. 2004. WILLRICH, Roberto. Sistemas Multimdia Distribudos. Florianpolis, 2000. UFSC.