• Like
Monografia - Engenharia de software baseada em modelos um estudo sobre WebML - João Gabriel Cabral
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Monografia - Engenharia de software baseada em modelos um estudo sobre WebML - João Gabriel Cabral

  • 271 views
Published

Monografia pessoal para o curso de ciências da computação na Universidade de Fortaleza, aborda o tema de Engenharia de Software Baseada em Modelos e serve como um estudo de caso para pesquisas, ela …

Monografia pessoal para o curso de ciências da computação na Universidade de Fortaleza, aborda o tema de Engenharia de Software Baseada em Modelos e serve como um estudo de caso para pesquisas, ela compara um desenvolvimento de uma aplicação web comum com o desenvolvimento de uma aplicação web utilizando a ferramenta WebRatio, e assim tirando uma conclusão sobre este estudo.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
271
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
17
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. FUNDAÇÃO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA – UNIFOR CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT CURSO CIÊNCIA DA COMPUTAÇÃOEngenharia de Software Baseada em Modelos: Um Estudo Sobre WebML João Gabriel de Paula Pessoa Cabral Dezembro – 2010 i
  • 2. João Gabriel de Paula Pessoa CabralEngenharia de Software Baseada em Modelos: Um Estudo Sobre WebML Monografia apresentada para a obtenção dos créditos da disciplina Trabalho de Conclusão de Curso – TCC do Curso de Ciência da Computação do Centro de Ciências Tecnológicas da Universidade de Fortaleza como parte das exigências para graduação. Orientador: Prof. Nabor das Chagas Mendonça Dezembro – 2010 ii
  • 3. Engenharia de Software Baseada em Modelos: Um Estudo Sobre WebML João Gabriel de Paula Pessoa Cabral PARECER: ______________________________ DATA: 21 / 12 / 2010 BANCA EXAMINADORA: ________________________________________________ D. Sc. Nabor das Chagas Mendonça ________________________________________________ D. Sc. Américo Tadeu Falcone Sampaio iii
  • 4. AGRADECIMENTOS Agradeço profundamente: A Deus, por todas as oportunidades recebidas, pela orações e pedidos realizados. A meus pais, José Berlan Silva Cabral e Maria Carolina de Paula Pessoa Cabral, portodo apoio, carinho e dedicação, que nunca deixaram faltar. Aos meus irmão José Berlan Silva Cabral Filho e Emanuel de Paula Pessoa Cabral,por todo apoio e dedicação. Ao meu orientador, Prof. Nabor das Chagas Mendonça, pela paciência, pelaoportunidade e pelos conhecimentos compartilhados na execução desse trabalho. Ao meus amigos Ronaldo, Nelson, Philipp, Ney e Henrique, pela ajuda oferecida, epor todo o tempo vivenciado com diversão e companheirismo. Aos professores e funcionários da UNIFOR, pela sabedoria compartilhada e pelaatenção oferecida. Ao Prof. Fernando Trinta, por ter acompanhado e ajudado no começo dodesenvolver de meu trabalho. Ao Prof. Américo Tadeu, pelas oportunidades oferecidas, e pela confiança a mimoferecida. A todos os amigos que estiveram presentes durante essa caminhada, tornando-ainesquecível. iv
  • 5. RESUMOEste trabalho tem como objetivo mostrar as vantagens e desvantagens da Engenharia deSoftware Baseada em Modelos. Principalmente é abordada uma linguagem de domínioespecífico chamada WebML, que é utilizada junto à ferramenta WebRatio. Assim foi feitoum Estudo de Caso sobre uma implementação utilizando WebRatio e outra sem utilizá-la.O resultado indica algumas vantagens sobre o uso de WebML. v
  • 6. SumárioIntrodução..............................................................................................................................1Capítulo 1 - Engenharia de Software Baseada em Modelos................................................2 1.1 – História e Origem......................................................................................................2 1.2 – Definição...................................................................................................................3Capítulo 2 – Web Modeling Language..................................................................................5 2.1 - Modelo de Dados......................................................................................................6 2.2 - Modelo de Hipertexto..............................................................................................10 2.2.1 - Unidades (Units)...............................................................................................11 2.2.1.1 - Unidade de Dados (Data Unit).............................................................13 2.2.1.2 - Unidade de Multi Dados (Multidata Unit).............................................14 2.2.1.3 - Unidades de Índice (Index Unit)...........................................................15 2.2.1.4 - Unidades de Navegação (Scroller Units).............................................17 2.2.1.5 - Unidades de Entrada (Entry Units).......................................................18 2.2.2- Páginas (Pages)................................................................................................20 2.2.3 - Links.................................................................................................................20 2.2.3.1 - Especificação dos Links.......................................................................21 2.2.3.2 - Parâmetros de Ligação e Seletores Paramétricos...............................22 2.3 - Modelo de Gerenciamento de Conteúdo................................................................24Capítulo 3 – Estudo de Caso...............................................................................................32 3.1 - WebRatio.................................................................................................................32 3.2 - Sistema de Controle de Estoque.............................................................................33 3.3 - Implementação........................................................................................................34 3.3.1 - Implementação Utilizando a Ferramenta WebRatio........................................34 3.3.2 - Implementação Manual....................................................................................36 3.4 - Análise Comparativa das Implementações.............................................................37Conclusão............................................................................................................................40Referências Bibliográficas...................................................................................................41 vi
  • 7. Lista de FigurasFigura 1: Notação gráfica para entidades..............................................................................7Figura 2: Notação gráfica de entidades com atributos..........................................................7Figura 3: Notação gráfica para chaves primárias..................................................................8Figura 4: Notação gráfica para hierarquia de generalização................................................9Figura 5: Notação gráfica para relações..............................................................................10Figura 6: Notação gráfica para papéis de relação...............................................................10Figura 7: Notação gráfica e textual para unidades de dados..............................................13Figura 8: Notação textual para unidades multi dados.........................................................14Figura 9: Notação gráfica para unidades multi dados, e uma renderização em HTML......15Figura 10: Notação gráfica para unidades de índice...........................................................16Figura 11: Notação gráfica para unidade de índice de múltipla escolha e uma renderizaçãoem HTML..............................................................................................................................16Figura 12: Notação gráfica para unidade de índice hierárquico..........................................17Figura 13: Notação gráfica em WebML para unidades de navegação, e uma renderizaçãoem HTML..............................................................................................................................18Figura 14: Notação textual de uma unidade de entrada.....................................................19Figura 15: Notação gráfica em WebML de uma unidade de entrada, e uma renderizaçãoem HTML..............................................................................................................................19Figura 16: Notação gráfica e textual de uma página em WebML.......................................20Figura 17: Notação gráfica e textual de um link..................................................................22Figura 18: Link inter-página contextual com parâmetro de link associado.........................24Figura 19: Notação textual do exemplo...............................................................................26Figura 20: Notação gráfica em WebML para unidades de criação, e uma possívelrenderização em HTML.......................................................................................................27Figura 21: Notação gráfica WebMl para unidade de deleção, e renderização em HTML. .28Figura 22: Notação Textual para unidades de deleção.......................................................29Figura 23: Notação gráfica em WebML para unidades de modificação, e uma renderizaçãoem HTML..............................................................................................................................30Figura 24: Notação textual de uma unidade de modificação..............................................31Figura 25: Interface da ferramenta WebRatio.....................................................................32Figura 26: Diagrama de caso de uso para o Sistema de Controle de Estoque..................33Figura 27: Modelo de Dados da aplicação em WebRatio...................................................35Figura 28: Modelo de Hipertexto da aplicação em WebRatio.............................................36 vii
  • 8. Lista de TabelasTabela 1: Parâmetros de link providos na saída por unidades de conteúdo.......................23Tabela 2: Tabela mostrando comparação entre WebRatio e uma aplicação feitamanualmente.......................................................................................................................38 viii
  • 9. Introdução Atualmente existem várias tecnologias para a construção de Sistemas deInformação. Algumas destas tecnologias, usadas conjuntamente, aumentamconsideravelmente a complexidade dos sistemas modernos. Para tratar tal complexidade,processos e paradigmas de desenvolvimento têm sido propostos ao longo dos anos. Umadessas iniciativas é a Model-Driven Engineering (MDE), que traduzindo significaEngenharia de Software Baseada em Modelos. A Engenharia de Software Baseada em Modelos utiliza linguagens de modelagemde domínios específicos, visando aumentar o nível de abstração dos sistemas levando auma diminuição da complexidade. O objetivo deste trabalho é estudar a MDE, em particular, uma linguagem demodelagem para Web chamada WebML (Web Modeling Language), identificando asvantagens e desvantagens que a linguagem oferece em relação ao seu domínio. Paraalcançar este objetivo, será realizado um estudo de caso utilizando uma ferramentachamada WebRatio, que utiliza a linguagem WebML para construção de sistemas Webcentrados em dados. O estudo realizará uma comparação de desenvolvimento de umsistema usando a ferramenta WebRatio e o desenvolvimento do mesmo sistema feito“manualmente”, ou seja, usando as mesmas tecnologias usadas pela ferramentaapresentada, mas sem gerar o código automaticamente. Este trabalho está estruturado em cinco capítulos, sendo o primeiro esta Introduçãoque apresenta o trabalho e o que será estudado. No Capítulo 1, é dada uma visão geraldo que é a MDE, seu surgimento, e do que ela é composta, e como ela está estruturada.No Capítulo 2, é apresentada a linguagem WebML, mostrando seu surgimento e todos osmodelos e diagramas que a compõem. No Capítulo 3, é abordado um estudo de casoutilizando WebML junto com a ferramenta WebRatio, mostrando todo o ciclo dedesenvolvimento de uma aplicação Web centrado em dados, discutindo as vantagens edesvantagens do seu uso relacionado ao desenvolvimento “manual” da mesma aplicação.No final, é apresentada uma conclusão sobre o trabalho, discutindo o uso de MDE nocotidiano da Engenharia de Software. 1
  • 10. Capítulo 1 - Engenharia de Software Baseada em Modelos 1.1 – História e Origem Nas últimas décadas, pesquisadores e desenvolvedores criaram abstrações queajudaram no desenvolvimento de programas, protegendo-os da complexidade dosambientes computacionais onde esses programas eram executados. Estas abstrações incluem linguagens e plataformas. Como exemplo, pode-se citar asprimeiras linguagens de programação, como Assembly e Fortran, que protegeram osdesenvolvedores da complexidade de codificar em linguagem de máquina. Do mesmomodo, plataformas de sistemas operacionais, como OS/360 e Unix, protegeram osdesenvolvedores das complexidades da programação diretamente para o hardware. A característica comum entre os modos de proteger os desenvolvedores das devidascomplexidades foi a característica de elevar o nível de abstração, em particular, prover ummaior nível de abstração para solucionar um problema em um devido domínio específico,como o caso de uma linguagem de alto nível para abstrair uma linguagem de código demáquina, e, no outro caso, uma plataforma de sistema operacional para abstrair daprogramação diretamente com o hardware. Vários esforços passados levaram à criação de tecnologias que elevam o nível deabstração usado para o desenvolvimento de software. O maior esforço surgiu nos anos80, quando foi criado o termo computer-aided software engineering (CASE), o qual focouno desenvolvimento de software através de métodos e ferramentas que permitem aosdesenvolvedores expressar seus programas em termo de uma proposta geral comrepresentações gráficas para programação, como uma máquina de estados, diagramasde estrutura e diagramas de fluxo de dados. A vantagem da CASE é que propõe umaabordagem gráfica que incorre em uma menor complexidade comparado a umalinguagem de programação convencional. Outra vantagem é que sintetiza artefatos vindosde uma representação gráfica para reduzir o esforço causado por codificações manuais,depuração e programação portável. Embora ferramentas CASE tenham atraído uma atenção considerável da 2
  • 11. comunidade acadêmica, ela não foi muito adotada na prática. Um problema que elaenfrentou foi oferecer uma linguagem de representação gráfica geral para escreverprogramas, na qual faltava um importante suporte a propriedades da qualidade de serviço(QoS), como tolerância a falhas e segurança. A complexidade da geração de códigoprecisava compensar em tradução de tecnologias disponíveis até o momento, a qual fezcom que fosse difícil desenvolver, depurar, e evoluir ferramentas CASE e aplicaçõescriadas com estas ferramentas. Outro problema com CASE foi sua inabilidade em aumentar a escalabilidade de umasistema complexo para uma variedade de domínios de aplicações. Mas, na época, eramusados ambientes de execução proprietários que dificultavam o desenvolvimento paradiferentes plataformas, e dificultava a integração do código que era gerado com outraslinguagens de programação e outras tecnologias de plataforma. Ferramentas CASE nãosuportaram vários domínios de aplicações efetivamente, por causa de suasrepresentações, que não eram customizáveis. Com isso, novas abordagens foram necessárias. 1.2 – Definição Model-Driven Engineering (MDE), segundo Douglas Schimidt (2006), é uma soluçãopara lidar com a complexidade de desenvolvimento de sistemas, seja essa complexidadedecorrente do uso das atuais tecnologias, paradigmas e processos da área de Engenhariade Software. A idéia por trás da Engenharia de Software Baseada em Modelos é utilizar modelosde domínios específicos para diminuir a complexidade do sistema. Isso é possível graçasà abstração que estes modelos garantem, como é o caso de modelos como WebML,UML, etc. A questão é que, através desses modelos, pode-se abstrair todos os detalhesda implementação do sistema, livrando a parte de desenvolvimento de lidar com códigoscomplexos que exigem um alto esforço para implementá-los. Como exemplo, odesenvolvimento de um sistema Web, onde o desenvolvedor tem que lidar com váriaslinguagens de programação, como também tem que lidar com vários frameworks e tiposde processos de desenvolvimento de sistema. Neste caso, o desenvolvedor pode-seutilizar de modelos como WebML, que facilitam a construção do sistema, apenasutilizando-se de diagramas que modelam o funcionamento, a arquitetura, e a organizaçãodos dados do sistema. 3
  • 12. A MDE introduziu a idéia de combinar duas tecnologias: •Uma linguagem para modelagem de domínios específicos, que formaliza uma estrutura de uma aplicação através de requisitos de um domínio particular, como exemplo, gerenciamento de warehouse, serviços online de financiamento, dentre outros; •Geradores e máquinas de transformação, que analisam certos aspectos de modelos e depois sintetizam vários tipos de artefatos, como código fonte, simulação de entradas, descritores XML, ou modelos de representações alternativas. A habilidade para sintetizar artefatos, através dos modelos de domínios específicos, ajuda a garantir a consistência entre implementação de aplicações e informações analisadas associadas com requisitos funcionais e de qualidade de serviço (QoS) capturados pelos modelos. Ferramentas MDE impõem restrições a domínios específicos e executam umachecagem de modelo no qual detecta-se erros e previne-se problemas no começo dociclo de vida do processo de desenvolvimento de software. O gerador de código da MDEnão necessita ser mais complicado, como na geração dos anos 80, já que conta compadrões, APIs de plataformas de middleware e frameworks. Como resultado, ficou muitomais fácil para desenvolver, depurar, e integrar ferramentas MDE e aplicações criadascom estas ferramentas. As vantagens da MDE são a redução do custo e do tempo do desenvolvimento desoftware, uma melhor estruturação do processo de desenvolvimento de software, osprodutos são mais reutilizáveis e coerentes com a realidade, uma melhormanutenibilidade, os modelos estão sempre atualizados com os produtos, e aprototipação pode ser atingida imediatamente. No próximo capítulo apresentaremos em mais detalhes um exemplo de umalinguagem de domínio específico da MDE, a Web Modeling Language (WebML). 4
  • 13. Capítulo 2 – Web Modeling Language Web Modeling Language (WebML) (CERI, Estefano; FRATERNALI, Piero, 2000) éuma linguagem de modelagem para aplicações web de dados intensivos (Data-intensiveWeb Applications). Ela permite aos projetistas expressarem características de um web siteem alto nível. Os conceitos de WebML são associados a representações gráficasintuitivas, que podem ser suportadas facilmente por ferramentas CASE e podemfacilmente ser entendidas por membros não técnicos da equipe de desenvolvedores.WebML também suporta uma representação textual, a qual pode ser usada para alimentarum gerador de código para a produção automática de uma implementação de um website. A especificação de um site em WebML consiste de três modelos: • Modelo de Dados (Data Model): este modelo expressa o conteúdo de dados de um web site, em termos de entidades (entitys) e relações (relationships). WebML ainda não suporta uma nova proposta de modelagem de dados, mas é totalmente compatível com as notações clássicas do modelo Entidade-Relacionamento, e diagramas de UML. Neste trabalho, apenas abordarei o modelo de dados utilizando o modelo Entidade-Relacionamento. • Modelo de Hipertexto (Hypertext Model): este modelo expressa toda a navegação de páginas e todas as páginas que vão ser exibidas pelo web site. Este modelo é um nova proposta, com novas notações gráficas e novas formas de representar páginas e links de uma aplicação Web. Neste trabalho, abordaremos os principais conceitos do modelo de hipertexto. • Modelo de Gerenciamento de Conteúdo (Content Management Model): este modelo expressa a adição, eliminação, atualização e busca de dados utilizando as entidades do esquema de dados definido no modelo de Entidade-Relacionamento. Neste trabalho, mostraremos apenas o básico deste modelo, não entrando em muitos detalhes em relação a tipos de utilização das ações deste modelo e tipos de resposta do mesmo. Neste capítulo, todas as definições dos conceitos de WebML foram tiradas do livroDesign Data-Intensive Web Applications (CERI et. al., 2003) e serão apresentadas aseguir. Alguns conceitos da WebML não serão abordados em muitos detalhes já que não 5
  • 14. serão utilizados no estudo de caso. 2.1 - Modelo de Dados O objetivo da modelagem de dados é permitir a especificação de dados usados poruma aplicação. O resultado da modelagem de dados é um esquema conceitual, queconvém de uma avaliação de conhecimento sobre os dados de uma aplicação. Desenharum esquema é um passo preliminar, tanto para o desenho de funções de negócios queopera sobre os dados de uma aplicação, como também para a implementação deestruturas físicas que suportam armazenamento de dados. Modelagem de dados é uma das mais tradicionais disciplinas da Tecnologia deInformação (TI), na qual possui linguagens de modelagem bem estabelecidas. Por estefato, neste capítulo usaremos o modelo Entidade-Relacionamento, que é um dos modelosde notações gráficas mais populares, usado para montar esquemas de dados. Os elementos essenciais do modelo Entidade-Relacionamento são entidades(entity), definidas como modelo de dados estruturados, e relacionamentos (relationships),que representam uma semântica de associação entre entidades. Entidades são descritaspor tipos de atributos (attributes), e podem ser organizadas em hierarquias degeneralização (generalization hierarchies), que expressam a derivação de um conceitoespecífico de um conceito mais geral de uma entidade. Relações são caracterizadas porrestrições de cardinalidade (cardinality constraints), que impõem restrições sobre onúmero de instâncias de um objeto que podem fazer parte de um relação. 2.1.1 – Entidades Entidade é o conceito central do modelo Entidade-Relacionamento. Uma entidaderepresenta a descrição de características comuns de um conjunto de objetos do mundoreal. Exemplos de entidades são Pessoa, Carro, Artista, e Álbum. Uma entidade tem oconceito de população (population), que é um conjunto de objetos que são descritos poruma entidade. Esses objetos são também chamados de instâncias de uma entidade. Porexemplo, a população de uma entidade Pessoa é a especificação de um conjunto depessoas, e a população de uma entidade Carro é especificada por um conjunto de carros,e assim por diante. Como todos os conceitos do modelo Entidade-Relacionamento, entidades sãoespecificadas usando uma notação gráfica. Elas são denotadas como um retângulo, com 6
  • 15. o nome da entidade no topo deste. A Figura 1 mostra um esquema em Entidade-Relacionamento contendo duas entidades: Álbum (Album) e Artista (Artist). Figura 1: Notação gráfica para entidades. 2.1.1.1 – Atributos Atributos representam propriedades de objetos do mundo real que são relevantespara as propostas de aplicação. Exemplos de atributos de uma entidade Pessoa são osseguintes: nome, endereço, e foto da pessoa. Atributos são associados com entidades,que correspondem à todas as instâncias de uma entidade serem caracterizadas por umconjunto dos mesmos atributos. Em outras palavras, a entidade é uma descrição comumde propriedades de um conjunto de objetos, e as propriedades são expressas pelosatributos. É admissível que uma entidade tenha valores nulos para um ou mais atributos. Masum valor nulo talvez represente diferentes situações de modelagem, e pode enraizarambiguidades na interpretação das propriedades de uma instância, a seguir mostrarei assituações: • Um valor nulo pode denotar que um certo atributo não é aplicado a instâncias específicas de uma entidade, por exemplo, o número da carteira de motorista para pessoas sem habilitação. • Um valor nulo pode denotar que um certo atributo é desconhecido para instâncias específicas de uma entidade, por exemplo, a idade ou o estado de maturidade de uma pessoa. Figura 2: Notação gráfica de entidades com atributos. Atributos são graficamente representados dentro de um retângulo de uma entidade,abaixo do nome da entidade, como mostrado na Figura 2. No exemplo, a entidade Album 7
  • 16. é caracterizada pelos atributos Title, Year, e Cover, e a entidade Artist pelos atributosFirstName, LastName, Biography, e Photo. 2.1.1.2 – Identificação e Chave Primária Todas as instâncias de uma entidade devem ser distinguidas, por um únicoidentificador que permite uma identificação não ambígua. Para expressar uma únicaidentidade de uma instância de uma entidade, um ou mais atributos podem ser definidoscomo uma chave primária (primary key) de uma entidade. Atributos de chave primáriadevem satisfazer algumas restrições. Seus valores devem ser definidos como não nulos eúnicos para cada instância de uma certa entidade. No restante do capítulo assumiremosque a propriedade OID é implícita e definida para todas as entidades, e omitida dosdiagramas de Entidade-Relacionamento. Se uma entidade admite identificadores alternativos, por exemplo propriedadesusadas no domínio da aplicação para nomear instâncias de uma entidade, os atributosidentificadores podem ser definidos como chaves (keys) também chamadas de chavesalternativas. Chaves alternativas devem ter valores não nulos e único, como as chavesprimárias. Figura 3 mostra a entidade Album e Artist, completadas com a especificação dechaves alternativas. O atributo Title é escolhido como chave da entidade Album, enquantoo par de atributos <FisrtName,LastName> é chave para a entidade Artist. Graficamente,atributos chaves são distinguidos por um pequeno ícone de uma chave posto à direita donome do atributo. Figura 3: Notação gráfica para chaves primárias. 2.1.1.3 – Hierarquias de Generalização O modelo Entidade-Relacionamento permite o designer a organizar entidades emuma hierarquia, onde elas compartilham algumas características comuns. A hierarquia de 8
  • 17. generalização básica tem uma super entidade e uma ou mais subentidades. Cadasubentidade herda todos os atributos e relações. Por exemplo, a Figura 4 especifica queJazzArtist e PopArtist são subentidades de uma entidade Artist, e JazzArtist tem umatributos extra chamado Instrument, que denota o instrumento tocado pelo artista de jazz.Nós dizemos que Artist é especializado em PopArtist e JazzArtist, e que PopArtist eJazzArtist são generalizados em Artist. Figura 4: Notação gráfica para hierarquia de generalização 2.1.2 – Relações Relações representam conexões semânticas entre entidades, como uma associaçãoentre um artista e seu álbum, ou entre um artista e suas revisões. O significado de umaassociação é concebida pelo o nome da relação, no qual é estabelecido pelo designer.Por exemplo, a relação entre artista e seu álbum é uma publicação que pode sernomeada Publicação. A forma mais simples de relação é uma relação binária (binaryrelationships), que conecta duas entidades. Relações envolvendo mais de duasentidades, são chamados relações-N-árias, mas relações-N-árias são desencorajadas deseu uso, porque elas podem ser expressadas pelo significado de múltiplas relaçõesbinárias. Cada relação binária é caracterizada por dois papéis de relação (relationship roles),cada um expressa a função que cada uma da entidades participantes faz na relação. Porexemplo, a relação Publicação entre um artista e seu álbum pode ser decomposta emdois papéis de relação, um de artista parar álbum, chamado Publica, e outro de álbum 9
  • 18. para artista chamado Publicado_Por. Assim um papel de relação pode ser entendidocomo uma associação orientada, conectando uma entidade fonte com uma entidadedestino. Papéis de relação podem ser anotados com restrições de cardinalidade máxima emínima, respectivamente denotando o número máximo e mínimo de objetos de umaentidade destino para o qual qualquer objeto de uma entidade fonte pode ser relacionado. A Figura 5 mostra a notação gráfica para relações binárias, que são representadaspor arestas conectando retângulos de entidades. Em particular a figura mostra a relaçãoPublication, que é definida entre a entidade Album e a entidade Artist. Um álbum éassociado com exatamente um artista (cardinalidade 1:1, chamada um para um), e cadaartista pode ser associado com vários álbuns (cardinalidade 0:N, chamada um “opcional”para muitos); assim o papel de álbum para artista é obrigatório, enquanto o papel deartista para álbum é opcional. A Figura 6 mostra a notação gráfica para especificar os nomes dos papéis derelações da relação Publication. Figura 5: Notação gráfica para relações Figura 6: Notação gráfica para papéis de relação 2.2 - Modelo de Hipertexto Modelagem de hipertexto é uma disciplina considerada jovem, ela ainda não possuiuma base bem estabelecida de conceitos, notações, e métodos de concepção. Deve ser considerada pelo designer como uma extensão natural do modeloEntidade-Relacionamento, que permite ao programador expandir o esquema de dados daaplicação com a especificação de hipertextos, usados para publicar e manipular dados. Os principais ingredientes da WebML são páginas (pages), unidades (units) eligações (links), organizados em construções modulares chamadas visões de site (siteviews). 10
  • 19. As unidades são formadas pelas unidades atômicas de conteúdo publicável, elasoferecem formas alternativas de organizar o conteúdo dinamicamente extraídos doesquema de dados Entidade-Relacionamento, e também permite a especificação dasformas de entrada de dados pelos usuários. As unidades são blocos de construções depáginas, que são os elementos de interface entregues aos usuários. As páginas são normalmente construídas pela montagem de várias unidades devários tipos, para alcançar o efeito desejado de comunicação. Páginas e unidades não são independentes, mas estão ligadas para formar umaestrutura de hipertexto. As ligações que representam um marco da modelagem de hipertexto: expressam apossibilidade de navegação de um ponto a outro no hipertexto, e a passagem deparâmetros de uma unidade para outra unidade, que é necessário para o cálculoadequado do conteúdo de uma página. Um conjunto de páginas podem ser agrupadas em uma visão de site, na qualrepresenta um hipertexto servindo de um conjunto bem definido de requisitos, porexemplo, as necessidades de um grupo específico de usuários. Em grandes aplicações ,talvez tenha múltiplas visões de site definidas no topo do esquema de dado, e umagrande visão de site pode ser decomposta hierarquicamente em áreas (areas), como“home”, “default” e propriedades “landmark”, permite o designer ajustar o nível devisibilidade destas construções dentro de uma estrutura hierárquica de uma visão de site. Finalmente os parâmetros globais (global parameters) podem ser especificados nonível da visão de site, para denotar pequenos pedaços de informação, que podem ser“gravados” durante a navegação do usuário, mais tarde eles serão recuperados eexplorados para a computação do conteúdo de algumas páginas. 2.2.1 - Unidades (Units) Unidades são elementos atômicos para especificar o conteúdo de uma página web.WebML suporta cinco tipos de unidades: • Unidades de dados (data units): tem como função mostrar informações sobre um único objeto. • Unidades de multi-dados (multidata units): apresenta informações sobre um conjunto de objetos. • Unidades de índice (index units): mostra uma lista de propriedades descritivas de alguns objetos, sem apresentar sua informação detalhada. 11
  • 20. • Unidades de navegação (scroller units): permite a navegação de um conjunto ordenado de objetos, fornecendo comandos para acessar o primeiro, o último, o anterior e próximo elemento de uma sequência. • Unidades de entrada (entry units): modelo de formulários, cujos campos permitem recolher a entrada, necessárias para realizar pesquisas ou para alimentar operações de atualização. Os cinco tipos básicos de unidades de conteúdo podem ser combinadas pararepresentar páginas da web de complexidade arbitrária. As primeiras quatro unidadesmodelam a publicação de informações, unidades de dados e multi-dados apresentam oconteúdo atual dos objetos no qual elas se referem, enquanto que unidades de índice enavegação facilitam a seleção de objetos. Unidades de dados refere-se à um únicoobjeto, enquanto unidades de multi-dados, índice, e navegação referem-se a um conjuntode objetos. Unidades de dados, multi-dados, índice e navegação apresentam conteúdo extraídode um esquema de dados, portanto é necessário especificar de onde vem seu conteúdo.WebML, usa dois conceitos para expressar a origem do conteúdo das unidades: a fonte(source) e o seletor (selector). • O fonte é o nome da entidade da qual o conteúdo da unidade é extraído. Assim, a entidade fonte diz o tipo de objeto usado para computar o conteúdo da unidade. Uma unidade de conteúdo pode ser associada a uma entidade fonte, que é o caso mais comum, ou com entidades de múltiplas fontes. • O seletor é um predicado, utilizado para determinar o atual objeto da entidade fonte que contribui para a unidade de conteúdo. Seletores são a conjunção de condições elementares, construídas a partir de atributos da entidade e de papéis de relacionamento no qual a entidade é envolvida, e de termos constantes ou variáveis. Termos variáveis são construídos utilizando parâmetros associados com ligações de entradas da unidade. Seletores cujas condições usam parâmetros são chamados de seletores paramétricos (parametric selectors) . Todos os conceitos de WebML tem uma representação gráfica, que transmitecaracterísticas essenciais, e uma representação textual, que podem ser usadas paraespecificar unidades detalhadas de propriedades adicionais não convenientementeexprimível pela notação gráfica. Unidades de conteúdo são graficamente representadas como retângulos contendo 12
  • 21. ícones rotulados. O nome da unidade é colocado dentro do retângulo, por cima do íconeda unidade. A fonte e o seletor são colocados debaixo do retângulo. A representaçãotextual, adiciona mais detalhes, como no caso das unidades de índice, a ordenação dosobjetos mostrados no índice, e atributos usados para mostrar cada objeto. 2.2.1.1 - Unidade de Dados (Data Unit) Unidades de dados publicam um único objeto de uma única entidade. Uma unidadede dados é caracterizada pelas seguintes propriedades: • Nome (name): o nome definido pelo usuário para unidade de dados. • Fonte (source): a entidade que fornece o conteúdo para a unidade. • Seletor (opcional): um predicado identificando um único objeto, que é mostrado pela unidade de dados. O seletor da unidade de dados é opcional, mas ele pode ser omitido somente no caso em que a entidade fonte possui apenas uma instância; no contrário, o objeto a ser mostrado na unidade de dados permanece indefinido. • Atributos incluídos (include attributes): o conjunto de atributos da entidade fonte à serem visualizados. Figura 7: Notação gráfica e textual para unidades de dados A Figura 7 mostra uma notação gráfica de uma unidade de dados nomeada comoShortArtist com a entidade fonte sendo Artist, e o seletores [FirstName=”Celine”] e[LastName=”Dion”] mostrando as restrições da unidade. Além da notação gráfica tambémé mostrada uma representação textual onde é especifica a unidade com mais detalhes,por exemplo mostrando os atributos que serão mostrados da unidade e por quaisatributos a unidade será ordenada. 13
  • 22. 2.2.1.2 - Unidade de Multi Dados (Multidata Unit) Unidade de Multi Dados apresenta múltiplos objetos juntos de uma entidade,repetindo a apresentação de várias unidades de dados. Portanto, uma unidade de multidados é caracterizada pelas seguintes propriedades: • Nome: o nome definido pelo usuário para unidade de multi dados. • Fonte: a entidade que fornece o conteúdo para a unidade. • Seletor (opcional): um predicado de seleção determinando os objetos mostrados pela unidade de multi dados. Se o seletor estiver faltando, todos os objetos são considerados. • Atributos incluídos: o conjunto de atributos da entidade fonte à serem visualizados. • Cláusula de ordem (order clausule) (opcional): o conjunto de atributos usados para ordenar os objetos da unidade de multi dados e o critério de ordenação a ser aplicado, que pode ser crescente e decrescente. Crescente é assumido como padrão. Figura 8: Notação textual para unidades multi dados As Figuras 8, 9 mostram respectivamente uma representação textual e gráfica deunidades de multi dados do modelo de hipertexto, a diferença da unidade de dados paramulti dados, é que a unidade de multi dados exibe várias informações sobre as instânciasda entidade fonte, como mostrado na Figura 9, onde é exibida uma renderização emHTML de uma página contendo uma unidade de multi dados no caso MultiArtist. 14
  • 23. Figura 9: Notação gráfica para unidades multi dados, e uma renderização em HTML 2.2.1.3 - Unidades de Índice (Index Unit) Unidades de índice apresentam múltiplos objetos de uma entidade como uma lista.A especificação de uma unidade de índice inclui as seguintes propriedades: • Nome: o nome definido pelo usuário para unidade de índice. • Fonte: a entidade que fornece o conteúdo para a unidade. • Seletor (opcional): um predicado de seleção determinando os objetos mostrados pela unidade de índice. Se o seletor estiver faltando, todos os objetos são considerados. • Atributos incluídos: o conjunto de atributos de uma entidade fonte usado para mostrar as entradas de índice. • Cláusula de ordem (opcional): o conjunto de atributos usados para ordenar os objetos de uma unidade de índice e definir o critério de ordenação que será aplicado, no qual pode ser ascendente ou descendente. Ascendente é assumido como padrão. A Figura 10 mostra uma notação gráfica para uma unidade de dados e uma possívelrenderização em HTML. Na notação o nome definido pelo usuário para a unidade ficaacima das listras localizadas no centro, no caso o nome é AlbumIndex, no centro as listrasformando um índice indicam que esta unidade é uma unidade de índice, e abaixo mostrauma bolinha com um nome abaixo, onde o nome significa o nome da entidade fonte quelistará todas as suas instâncias na tela. 15
  • 24. Figura 10: Notação gráfica para unidades de índice Unidades de índice admitem duas variantes para escolha de múltiplos objetos, epara organização da lista de índices hierarquicamente. A primeira variante é representada por unidade índice de múltipla escolha (multi-choice index unit), em que cada elemento é associado a um checkbox, permitindo ousuário a selecionar múltiplos objetos. Como mostrado na Figura 11. Figura 11: Notação gráfica para unidade de índice de múltipla escolha e uma renderização em HTML. A segunda variante da unidade de índice é o conceito de índice hierárquico, no qualos índices são organizados em uma árvore de multi-nível. A hierarquia é representada poruma sequência de N entidades fonte conectadas por N-1 papéis de relação. A primeiraentidade fonte representa a instância de nível do topo da hierarquia, a segunda entidadefonte, introduzida pela cláusula NEST, representa as instâncias do segundo nível dahierarquia. Cada papel de relação denota uma associação pai-filho entre duas entidades 16
  • 25. nos níveis consecutivos da hierarquia. Um exemplo de notação gráfica de índicehierárquico é mostrado pela Figura 12. Um caso especial de índice hierárquico explora uma relação recursiva definida sobreuma entidade, que tem uma associação “parte de”. Assumindo que o esquema Entidade-Relacionamento contém uma entidade Parte e uma relação "de Parte para Subparte"(Part-to-Subpart) expressando recursivamente como cada parte é decomposta em sub-partes. Neste caso a hierarquia possui um número variável de níveis. Figura 12: Notação gráfica para unidade de índice hierárquico. 2.2.1.4 - Unidades de Navegação (Scroller Units) Unidades de navegação provém comandos para navegar entre os objetos de dentrode um conjunto, por exemplo para navegar sobre todas as instâncias de uma entidade. Aespecificação de uma unidade de navegação é caracterizada pelas propriedades: • Nome: nome definido pelo usuário para a unidade de navegação. • Fonte: a entidade que fornece o conteúdo para a unidade. • Seletor (opcional): um predicado de seleção determinando os objetos mostrados pela unidade de navegação. Se o seletor estiver faltando, todos os objetos são considerados • Fator de blocos (block factor): o número de objetos que são navegados juntos. O valor padrão é 1. • Cláusula de ordem (opcional): o conjunto de atributos usados para ordenar os objetos de uma unidade de navegação e usados para definir o critério de ordenação a ser aplicado, que pode ser ascendente ou descendente. Ascendente é assumido como padrão. 17
  • 26. Figura 13: Notação gráfica em WebML para unidades de navegação, e uma renderização em HTML. A Figura 13 mostra a notação gráfica definida pela WebML para unidade denavegação, onde no exemplo há o nome AlbumScroll definido pelo usuário, e abaixo umabolinha com o nome da entidade fonte logo abaixo. E também é mostrado umarenderização em HTML da unidade. 2.2.1.5 - Unidades de Entrada (Entry Units) Unidades de entrada suportam entrada de dados baseadas em formulários,queforam inicialmente propostas por BONGIO, Aldo et al. (2000). Elas são usadas parareceber entradas, que é tipicamente empregadas para fazer o seguinte: • Pesquisar sobre objetos de uma entidade, por exemplo para localizar as instâncias de uma entidade nas quais contém atributos com as palavras- chave dadas. • Fornecer parâmetros para operações como atualização de conteúdo, login, e serviços externos. Unidades de entrada são caracterizadas pelas seguintes propriedades: • Nome: nome definido pelo usuário para a unidade de entrada. • Campos (fields): o conjunto de campos para entrada de valores. Campos de unidades de entrada correspondem a campos de entrada normalmenteencontrados na construção de formulários de linguagens de marcação. Campos deentrada tem um número de propriedades, definidas pelas propriedades abaixo: • Nome: o nome do campo. 18
  • 27. • Tipo (type): o tipo de dados do valor de entrada no campo (por exemplo, string, text, integer, date e muitos mais).• Valor inicial (initial value) (opcional): um valor padrão para ser inicializado proposto para o usuário• Modificabilidade (modifiability): um sinalizador que especifica se o usuário pode modificar o valor do campo inicial ou não, por padrão todos os campos são modificáveis.• Predicado de validação (validity predicate): uma condição booleana aplicável ao o valor de entrada pelo usuário, para checar sua validade. O predicado de validade pode ser qualquer expressão lógica construída usando o campo nome, um operador pode ser aplicável aos tipo de dados, a constantes e termos variáveis. O termo variável pode ser o nome de outro campo, que permite a comparação dos valores de entrada definida pelo usuário em diferentes campos, por exemplo, para garantir que a data de morte de um artista é maior que a sua data de nascimento. A palavra especial notnull pode ser usada para requerer que o usuário especifique algum valor para o campo. Figura 14: Notação textual de uma unidade de entrada. Figura 15: Notação gráfica em WebML de uma unidade de entrada, e uma renderização em HTML. 19
  • 28. As Figuras 14 e 15 mostram respectivamente uma notação gráfica e uma notaçãotextual de uma mesma unidade de dados, note que apenas percebe-se a definição doscampos na notação textual, ou seja, toda vez que for definir uma unidade de entrada deveser especificada a notação textual com os campos. 2.2.2- Páginas (Pages) Páginas são elementos de interface entregues ao usuário, que navega o hipertextoacessando suas páginas numa sequência desejada. Uma página tipicamente consiste demuitas unidades, agrupadas juntas para completar uma proposta de comunicação bemdefinida. A Figura 16 mostra a notação gráfica e textual de uma página em WebML, no caso apágina é um retângulo grande que possui unidades dentro e em sua especificação textualcontém os nomes da unidades que irão fazer parte da página. Figura 16: Notação gráfica e textual de uma página em WebML. 2.2.3 - Links Nem páginas e nem unidades existem isoladas, porque hipertextos são feitos depáginas ligadas, que contém várias peças interligadas de conteúdo e de comandos,permitindo ao usuário interagir com o aplicativo. Para expressar estas características,páginas e unidades podem ser ligadas, para especificar os caminhos de navegaçãopermitido entre as páginas, as seleções oferecidas ao usuário, e o efeito da interação dousuário sobre o conteúdo das unidades exibidas na página. Modelagem de navegação é a parte de modelagem de hipertexto que trata daespecificação das ligações entre as unidades e páginas, e das propriedades de tais links. 20
  • 29. As noções centrais de modelagem de navegação são os conceitos de ligação, parâmetrosde ligação, e seletores paramétricos: • Um link é uma conexão orientada entre duas unidades ou páginas. • Um parâmetro de ligação é a especificação de um pedaço de informação, que é transportada desde a fonte até o destino do link. • Um seletor paramétrico é um seletor de unidade cujo predicados incluem uma referência à um parâmetro de ligação. 2.2.3.1 - Especificação dos Links Links abstraem e generalizam a noção fundamental de hipertextos: o conceito daâncora. Uma âncora é um dispositivo ativo, pelo qual o usuário pode interagir com ohipertexto. A noção de âncora deve ser considerada em sentido lato. Os seguintes casospráticos, submetido a um hipertexto baseado em HTML, são exemplos do que pode serconsiderado uma âncora: • Uma tag de âncora de HTML com um atributo href que se refere a uma outra página. Clicando sobre a âncora substitui a página que está sendo visualizada com a página referida pela tag âncora. • Uma tag de âncora de HTML com um atributo href que se refere a mesma página. Clicando sobre a âncora reexibe a página atualmente visualizada, possivelmente com algum conteúdo novo, por exemplo, devido a seleção e, algum índice, que faz com que os detalhes de um novo objeto seja, exibidos. • O botão de confirmação de um formulário de HTML usado para pesquisa. Inserir de entrada no formulário e pressionar o botão faz com que uma nova página ou a mesma página seja mostrada com os resultados da pesquisa. • O botão de confirmação de um formulário de HTML usado para o envio de entrada para uma operação, por exemplo, para entrar em um site protegido por senha. Como os exemplos mencionados anteriormente sugerem, a essência das ligações édupla: • Elas permitem a navegação do hipertexto, permitindo que o movimento do usuário use o foco de uma página de origem para uma página de destino. • Elas transportam a informação de uma unidade para outra, por exemplo, o 21
  • 30. identificador do objeto selecionado a partir de um índice que mostra o resultado da busca, ou para executar a operação de verificação de senha. Na terminologia WebML, links cruzando as fronteiras das páginas são chamadoslinks inter-páginas, enquanto que os links com origem e destino dentro da mesma páginasão chamados intra-páginas, links de transporte de informações são chamadoscontextuais, em contraste com links não-contextuais, que não transportam informações. Graficamente links são representados por arcos orientados que ligam a unidade oupágina fonte para a unidade ou página de destino. Figura 17: Notação gráfica e textual de um link. No exemplo da Figura 17 mostra um link inter-página não contextual. O link conectauma página fonte (PopArtists), que inclui uma unidade multi dados mostrando os asrtistasde pop, para uma página destino (JazzArtists), que inclui uma unidade multi dadosmostrando os artistas de jazz. O conteúdo da página JazzArtists é independente doconteúdo da página PopArtists, e esta navegação não requer qualquer informação paraser passada da página fonte para a destino. 2.2.3.2 - Parâmetros de Ligação e Seletores Paramétricos A vinculação entre uma unidade fonte e uma unidade destino de um link éformalmente representada por um parâmetro de ligação definido sobre o link, e por umseletor paramétrico, definido na unidade destino. Um parâmetro de link (link parameter) é um valor associado com um link entreunidades, que é transportado, como um efeito de navegação de link, de uma unidadefonte à uma unidade destino. Um seletor paramétrico (parametric selector) é uma unidadeseletora cuja condição menciona um ou mais parâmetros. Do ponto de vista sintático, um parâmetro de ligação tem um nome e um rótulo,separados por um ponto e vírgula. O nome é uma cadeia definida pelo usuário CurrArtist 22
  • 31. na Figura 18, que pode ser usado para se referir ao parâmetro no seletor da unidadedestino. O rótulo indica o conteúdo do parâmetro, que é tanto um atributo ou um campoda unidade de origem do link, quando o rótulo refere-se a um atributo, que consiste naconcatenação de nomes de entidades e atributos, separados por um ponto. O nome daentidade pode ser omitido, se resulta do contexto, como o rótulo OID na Figura, querepresenta Artist OID. A saída de valores produzidos pelas unidades de diversas fontes eos rótulos dos parâmetros de ligação correspondente estão resumidos na Tabela 1.Unidade Fonte Parâmetro de link Rótulo do parâmetro de link Qualquer atributo (incluindo oUnidade de Dados OID) do objeto mostrado pela EntidadeFonte.nomeAtributo unidade O conjunto de valores deUnidade de Multi qualquer atributo (incluindo OID) {EntidadeFonte.nomeAtributo}Dados do objeto mostrado pela unidade O valor de qualquer atributo de um objeto selecionado peloUnidade de Índice EntidadeFonte.nomeAtributo usuário clicando em uma âncora na unidade de índice O valor de qualquer atributo do objeto selecionado pelo usuárioUnidade de Índice clicando sobre uma âncora na EntidadeFonte.nomeAtributoHierárquico unidade. Todos os objetos mostrados em qualquer nível da hierarquia pode ser selecionado O conjunto de valores de qualquer atributo de múltiplosUnidade de Índice de objetos selecionados pelo {EntidadeFonte.nomeAtributo}Múltipla Escolha usando os checks boxes da unidade O conjunto de valores de qualquer atributo do bloco deUnidade de Navegação {EntidadeFonte.nomeAtributo} objetos selecionados por clicar sobre a âncora na unidade O valor de entrada pelo usuárioUnidade de Entrada nomeCampo em cada campo Tabela 1: Parâmetros de link providos na saída por unidades de conteúdo. 23
  • 32. Figura 18: Link inter-página contextual com parâmetro de link associado. 2.3 - Modelo de Gerenciamento de Conteúdo Para introduzir operações de dados em WebML foi criado o modelo degerenciamento de conteúdo. A introdução de operações em dados na WebML não exigemudanças no modelo de dados, e requer duas simples e intuitivas extensões para omodelo de hipertexto. A primeira extensão é a notação de unidades de operações(operations units), que são usadas para expressar alguns processos executados comoresultado de uma navegação em um link. Uma unidade de operação pode denotar tantouma manipulação de dados, como também a execução de um serviço externo genérico. Asegunda extensão aplica a links de resposta (outgoing links) de unidades de operações,que são distinguidas em OK-links e KO-links. OK e KO-links capturam o conceito deoperação respectivamente com sucesso e com falha, e permitem o designer a pegarcursos alternativos depois da execução de uma operação, dependendo da saída daexecução. WebML inclui muitas unidades de operações predefinidas, que oferecem as maiscomuns primitivas para atualizar as instâncias de uma entidade e de relações de umaaplicação, pela criação, modificação, e deleção de objetos, e conectando edesconectando relações, mas oferece ainda algumas operações de utilidade, como login,logout, e operações de envio de e-mail. As operações predefinidas de gerenciamento deconteúdo podem ser clusterizadas em transações (transactions), que são sequências deatualizações automáticas. Quando uma transação é especificada, é seguida umasequência de operações individuais que consistem em uma execução com sucesso, ouuma execução totalmente desfeita. 2.3.1 – Operações As unidades de operações de WebML, ou então somente operações, são um novo 24
  • 33. tipo de unidades, que podem ser colocadas fora de páginas e linkadas a outrasoperações, ou linkadas a unidades de conteúdo definidas dentro de páginas. Diferentesdas unidades de conteúdo, as operações não exibem um conteúdo, o que justifica o fatodelas poderem ser colocadas fora de páginas; elas fazem ações. Como unidades deconteúdo, operações podem ter objetos fonte (como uma entidade ou uma relação) eseletores, podem também receber parâmetros vindos de um link de entrada, e podeprover valores para serem usados como parâmetros de seus links de saída. A forma, ilustrada pela Figura 20, modela as funções de gerenciamento de conteúdo,como criação, deleção e modificação de objetos. Operações em WebML obedecem osseguintes princípios de design: • Uma operação pode ter múltiplos links, provendo valores para os parâmetros de entrada. • Operações podem ser linkadas para formar uma sequência. Disparando a primeira operação de sequência implicando logo após a execução das operações restantes. • Cada operação tem um OK link e um KO link, o primeiro é seguido quando uma operação é feita com sucesso, o segundo é seguido quando uma operação falha. 2.3.2 – Operações Pré-definidas WebML provém um número de operação já construídas, na quais são pré-definidasna linguagem. Como a orientação é sobre aplicações web de dados intensivos, asoperações pré-definidas usam mais tarefas de gerenciamento de dados. Algumas outraspoucas operações também oferecidas pela WebML são providas, como serviços deutilidade geral, frequentemente usadas em uma aplicação Web. Elas são operações delogin, logout e de envio de e-mail. 2.3.2.1 - Criação de Objeto A primeira operação é a unidade de criação (create unit), que oferece o serviço decriação de uma nova instância de uma entidade. Cada unidade de criação é caracterizadapelo seguinte: • Um nome definido pelo usuário. 25
  • 34. • Uma entidade fonte, onde as operações serão aplicadas. • Um conjunto de atribuições (assignments), ligando os atributos do objeto a ser criado aos valores dos parâmetros vindos de um link de entrada, ou alguns valores constantes. • A entrada de uma unidade de criação é um conjunto de valores de seus atributos, tipicamente vindo de um link de entrada saindo de uma unidade de entrada. Estes valores são usados pela operação de criação para construir um novo objeto, se alguns atributos não forem associados à um valor de entrada, eles são setados para nulo, com exceção do OID, que é tratado diferentemente, se ele não receber nenhum valor, um novo e único valor é gerado pela operação e então associado ao OID. A saída produzida pela operação de criação é um conjunto de valores, incluindo o OID, do novo objeto criado. Esta saída é definida somente quando a operação é sucedida, e pode ser totalmente associada a um parâmetro de link somente OK para links, e não KO links. A saída padrão de uma unidade de criação é o valor do atributo OID, que assume um parâmetro de link implícito de um OK link, se nenhum parâmetro é especificado explicitamente. Figura 19: Notação textual do exemplo. O exemplo na Figura 20 mostra um típico uso do padrão para operações de criação,que consiste de combinações de uma unidade de entrada (ArtistEntry) provendo umaentrada para a unidade de criação (CreateArtist), criando uma nova instância de umaentidade (Artist). No exemplo, a unidade de entrada tem dois campos (FistName,LastName), para entrada do primeiro nome e segundo nome de um artista. Os valoresinseridos pelo usuário são associados como parâmetros explícitos com o link da unidade 26
  • 35. de entrada para a operação de criação. Estes parâmetros são ligados à atributos doobjeto artista para ser criado duas atribuições, representado abaixo da entidade fonte daunidade de criação. Na renderização, mostrada na Figura , o link de saída da unidade deentrada é mostrado como um botão de submissão (submit button), permitindo a ativaçãoda operação. A operação CreateArtist tem dois links de saída, o OK link aponta para aunidade de dados ArtistDetails e é associado com o parâmetro de link padrão (o OID donovo objeto). O KO link aponta de volta para a página ArtistCreation, para o usuário tentara operação novemente. A descrição completa textual do exemplo é mostrada na Figura19. Em particular, a unidade de criação e os OK e KO links são exemplificados. Figura 20: Notação gráfica em WebML para unidades de criação, e uma possível renderização em HTML 2.3.2.2 - Deleção de Objeto A unidade de deleção (delete unit) é usada para deletar um ou mais objetos de umadada entidade. Cada unidade de deleção é caracterizada pelo seguinte: • Um nome definido pelo usuário • Uma entidade fonte e um seletor, que determine o objeto ou o conjunto de objetos para as operações serem aplicadas. O objeto a ser deletado são os que satisfazem a condição do seletor. O usuário tipicamente escolhe durante a execução um único objeto, mostrado poruma unidade de dados ou selecionado por uma unidade de índice ou de navegação, ouum conjunto de objetos mostrado por uma unidade de multi dados ou selecionado por 27
  • 36. uma unidade de índice de múltipla escolha. O OID correspondente ou um conjunto deOIDs é associado à um parâmetro de link para o link de chegada na unidade de deleção,que irá deletar o objeto. A unidade de deleção tem um seletor padrão, baseado na cardinalidade do conjuntode OIDs recebido na entrada, isto é [OID=<parâmetro de link>] se o parâmetro de link deentrada possui apenas um valor, ou [OID IN <parâmetro de link>] se o parâmetro de linkde entrada é multivalorado. Como usualmente, o seletor padrão pode ser inferido e nãonecessariamente tem que ser expressado na notação gráfica e notação textual. O OK link é seguido quando todos os objetos determinados pelo seletor foremdeletados, e não tem nenhum parâmetro de link. O KO link é seguido quando nenhum dosobjetos forem deletados, e associa com os parâmeros de link o OID ou o conjunto deOIDs do dos objetos que não foram deletados. O exemplo na Figura 21 ilustra a notação gráfica para a operação de deleção erepresenta um exemplo de deleção de um único objeto. A página Album inclui a unidadeAlbumIndex, linkada à unidade de deleção. O link tem um parâmetro padrão, segurando oOID do álbum selecionado, que é usado no seletor implícito da unidade de deleção. Anavegação do link dispara a deleção do objeto selecionado. Se a operação for bemsucedida a página Album é remostrada, mas o álbum deletado não será remostrado noíndice, em caso de falha, a página Album é remostrada e o álbum que não foi deletadocontinuará aparecendo no índice. Figura 21: Notação gráfica WebMl para unidade de deleção, e renderização em HTML 28
  • 37. A especificação textual de uma unidade de delação é simples e mostrada na Figura22. Figura 22: Notação Textual para unidades de deleção. 2.3.2.3 - Modificação de Objeto A unidade de modificação (modify unit) é usada para atualizar om ou mais objetos deuma dada entidade. Cada unidade de modificação é caracterizada pelo seguinte: • Um nome definido pelo usuário. • Uma entidade fonte e um seletor, que identifica o objeto ou conjunto de objetos que serão aplicadas as operações. Os objetos à serem modificados são o conjunto de objetos que satisfazem as condições do seletor. • O conjunto de atribuições (assignments), liga os valores aos atributos dos objetos à serem modificados. O usuário tipicamente escolhe durante a execução um único objeto ou um conjuntode objetos à serem modificados, em poucas palavras a mesma modificação aplica a todosos objetos selecionados. Uma unidade de modificação deve ser linkada a outras unidades, para obter asentradas necessárias: • O novos valores de atributos: estes são tipicamente definidos como parâmetros de um link de entrada vindo de uma unidade de entrada. • Os objetos de modificação: estes são usualmente especificados como um parâmetro de um link de entrada, segurando o OID ou o conjunto de OIDs, que é usado no seletor da unidade de modificação. A unidade de modificação tem um seletor padrão da forma [OID=<parâmetro de link>], se o parâmetro OID é de um só valor, e [OID IN <parâmetro de link>], se o parâmetro de link for multivalorado. • Alternativamente ao uso do parâmetro de link do tipo OID, os objetos à serem modificados podem ser identificados por um seletor baseado em um atributo ou uma relação dentro da unidade de modificação, possivelmente associados aos parâmetros do link de entrada. O OK link de uma unidade de modificação é seguido quando todos os objetos foram 29
  • 38. modificados com sucesso, neste caso o OK link tem um parâmetro padrão segurando oconjunto de objetos modificados. O KO link é seguido quando algum dos objetos nãopode ser modificado, e tem como parâmetro padrão o conjunto de OIDs dos objetos quenão foram modificados. O exemplo da Figura 23 mostra uma unidade de entrada usada para suprir valorespara a unidade de modificação. A página ModifyArtist compreende a unidade de dados(BioData), que mostra o nome do artista a ser modificado, e uma unidade de entrada(BioEntry), na qual o usuário pode modificar a biografia existente. Um link de transporteda unidade de dados para unidade de modificação tem um parâmetro padrão segurando oOID do artista a ser modificado, que é usado pelo seletor padrão da unidade demodificação. A unidade de modificação é ativada pelo segundo link, saindo da unidade deentrada, como o link tem um parâmetro explicito (chamado Bio), que segura o valor docampo de entrada da unidade de entrada, usado na atribuição <BiographicInfo:=Bio> daoperação. O OK link leva à uma página de Resultado chamada Result, que mostra osvalores atuais do atributo BiographicInfo. O KO link aponta de volta para a unidadeBioData. Note que em caso de sucesso, o novo valor da biografia é apresentado naunidade de dados BioData. Figura 23: Notação gráfica em WebML para unidades de modificação, e uma renderização em HTML 30
  • 39. A especificação textual da unidade de modificação, com o seletor padrão omitido, émostrada na Figura 24. Figura 24: Notação textual de uma unidade de modificação. 31
  • 40. Capítulo 3 – Estudo de Caso Neste capítulo é abordado um Estudo de Caso, que realiza uma comparação entreduas implementações de um sistema de controle de estoque. As implementações sãorealizadas de dois modos: um implementa utilizando a ferramenta WebRatio e o outroimplementa manualmente. Este capítulo mostra o passo a passo das implementações, e também especifica aferramenta WebRatio, mostrando suas características e tecnologias usadas. Ao final docapítulo é realizada uma Análise de Comparação das duas implementações, mostrandoas diferenças, vantagens e desvantagens de cada modo de implementação. 3.1 - WebRatio WebRatio (WebRatio,2010) é uma ferramenta que gera aplicações padrões eabertas de Java Web. Suas aplicações são entregáveis em qualquer servidor deaplicações Java como JBoss, Apache Tomcat, IBM Websphere, Oracle Application Server.Ela é integrada na IDE Eclipse, compila com Java/JSP 2.0, e explora as bibliotecas doHibernate, conectando-se a qualquer banco de dados que suporta JDBC. Inclui tambémas tecnologias de Struts, JSTL, JSP e Java Servlet. Figura 25: Interface da ferramenta WebRatio. 32
  • 41. A implementação utilizando a ferramenta WebRatio, é realizada a partir dos modelosde WebML. Neste caso são utilizados os seguintes modelos: modelo de dados e modelode hipertexto. Para isso a ferramenta WebRatio disponibiliza uma interface para odesigner. Ele poderá modelar sua aplicação através da adição de entidades em modelosde dados, estas são graficamente representadas como definido em WebML. Ele poderátambém modelar através da adição de unidade no modelo de hipertexto e no modelo degerenciamento de conteúdo. Esta interface é mostrada na Figura 25, que mostra umexemplo de uma aplicação com páginas e unidade de conteúdo . 3.2 - Sistema de Controle de Estoque Neste trabalho é necessário especificar um sistema para o estudo de caso, que éutilizado para a implementação de dois modos. Para isso é escolhido um sistemasimples, com a finalidade de ser fácil comparar os dois modos de implementação. Nestecaso é escolhido um sistema de controle de estoque, sendo nomeado como "Sistema deControle de Estoque". Neste sistema é definido quatro casos de uso, sendo os seguintes:cadastrar produto, alterar produto, remover produto e buscar produto. Os casos de usosão mostrados na Figura 26 por um diagrama de caso de uso. Definindo assim um atorque interage com as operações alterar, buscar, cadastrar e remover produtos do estoque.Este diagrama é gerado pela ferramenta Astah (ASTAH, 2010). Figura 26: Diagrama de caso de uso para o Sistema de Controle de Estoque. 33
  • 42. 3.3 - Implementação Para realizar as implementações do "Sistema de Controle de Estoque", sãoescolhidas duas formas de implementação. Uma utilizando a ferramenta WebRatio, ondeé gerada toda aplicação web à partir da linguagem WebML, e a outra é implementaratravés da utilização de ferramentas básicas, que o desenvolvedor programará aaplicação à mão, ou seja, terá que digitar todos os códigos relacionados à aplicação. A seguir será especificado o passo a passos das implementações citadas acima. 3.3.1 - Implementação Utilizando a Ferramenta WebRatio Para implementar o "Sistema de Controle de Estoque" utilizando a ferramentaWebRatio, é necessário seguir dois passos para gerar a aplicação. O primeiro passo édefinir e configurar o modelo de dados da aplicação. Neste passo é utilizado um modeloEntidade-Relacionamento para definir as entidades e relacionamentos da aplicação. Osegundo passo é definir o modelo de hipertexto da aplicação. Esse modelo é usado paradefinir as páginas e links da aplicação web. No primeiro passo, a ferramenta já disponibiliza duas entidades e umrelacionamento, que são respectivamente User, Module e Group. Para seguir osrequisitos do "Sistema de Controle de Estoque" é definida uma entidade chamadaProduto. A entidade Produto representa produtos reais de um estoque, que podem serarmazenados por lojas, por armazéns e por outros locais que armazenam produtos emseu estoque. Esta entidade possui os quatro seguintes atributos: oid, nome, descricao equantidade. O atributo oid significa object identifier, ele é utilizado para identificarunicamente um objeto, e é definido como chave primária. O atributo nome é utilizadopara nomear o produto que é cadastrado no estoque. O atributo descricao serve paradescrever o objeto dando suas principais características como modelo ou aparência doproduto. E finalmente o atributo quantidade, que tem a utilidade de quantificar o produtoarmazenado no estoque. Os tipos dos atributos seguindo a ordem são respectivamente osseguintes: integer, string, string e integer. As outras entidades não precisam serabordadas, mas provavelmente são utilizadas para realizar o login da aplicação. Abaixo aFigura 27 mostra o esquema de dados do "Sistema de Controle de Estoque", definidocom o modelo Entidade-Relacionamento na ferramenta WebRatio. 34
  • 43. Figura 27: Modelo de Dados da aplicação em WebRatio. Ainda seguindo o primeiro passo, é preciso definir a comunicação do modelo dedados com o banco de dados utilizado. Para isso a ferramenta disponibiliza uma interfacecapaz de facilitar a comunicação com o banco de dados. Esta interface disponibilizacampos, utilizando informações requeridas pelo conector JDBC, como a url do banco dedados, informações de autenticação do usuário e senha do usuário do banco. Alémdestas informações um detalhe também é necessário, a ferramenta necessita do driverresponsável por realizar a comunicação. Este driver, que no caso é um arquivo, tem queser renomeado e colocado em uma pasta específica onde está localizada a ferramenta. O segundo passo define o modelo de hipertexto, incluindo o modelo degerenciamento de conteúdo. Para compor o modelo de hipertexto é necessário utilizarpáginas e unidades como definidas na linguagem WebML, utilizando a interface daferramenta WebRatio. Nesta é possível adicionar facilmente os elementos da linguagemWebML. Com a ferramenta WebRatio, o usuário adiciona as representações gráficas depáginas e unidades para compor o modelo de hipertexto e modelo de gerenciamento deconteúdo. Estes modelos são mostrados em uma visão de site criada pela ferramenta, edefinida pelo usuário. No caso do "Sistema de Controle de Estoque" é necessário definir omodelo de hipertexto como mostrado na Figura 28. Para construir o modelo de hipertexto,são adicionadas pelo menos uma página para cada caso de uso do sistema. Em cadapágina pelo menos uma unidade é adicionada. Por exemplo, no caso de uso alterar, são 35
  • 44. utilizadas duas páginas, uma contendo todos os produtos do estoque, definida por umaunidade de índice. Neste índice o usuário do sistema escolhe um produto para modificar.Ao clicar no link de alteração do produto, o usuário é encaminhado para uma outrapágina, onde é mostrado os dados atuais do objeto selecionado. Para mostrar os dadosdo objeto selecionado é utilizada uma unidade de dados, e os campos que deverão serpreenchidos com novos valores, com isso os valores serão utilizados para a modificaçãodo objeto selecionado. Neste caso é utilizada uma unidade de entrada. Ao confirmar osdados da alteração do objeto, serão transportados os dados pelo link, destinando umaunidade de modificação. Esta é utilizada para atualizar o banco de dados. Os outroscasos de uso podem ser vistos na Figura 28, que mostra todo o modelo de dados do"Sistema de Controle de Estoque". Figura 28: Modelo de Hipertexto da aplicação em WebRatio. 3.3.2 - Implementação Manual Para a implementação manual do "Sistema de Controle de Estoque" são utilizadostrês passos. O primeiro é criar o banco de dados da aplicação, utilizando as ferramentasdisponibilizadas pelo PostgreSQL. Essas ferramentas disponibilizam uma interface capazdo usuário escrever comandos em SQL, e executá-los no banco de dados. O segundo 36
  • 45. passo é implementar a aplicação web através da IDE Eclipse, onde o desenvolvedorcodifica toda a aplicação usando a linguagem Java. Além de Java também são utilizadasas tecnologias Java Servlet e JSP. O terceiro passo compõem utilizar o servidor ApacheTomcat, com a finalidade de executar a aplicação web em um servidor, e executá-la emum browser. No primeiro passo é criada uma entidade chamada Produto. Esta possui os quatroseguintes atributos: oid, nome, descricao, quantidade. O atributo oid significa objectidentifier, é do tipo integer, é auto incrementável, e também chave primária. O atributonome significa o nome dado ao produto, ele é do tipo string. O atributo descricao significauma descrição do produto em estoque, ele é um atributo do tipo string. E finalmente oatributo quantidade, que significa a quantidade do produto armazenado no estoque, e seutipo é integer. No segundo passo é criada uma aplicação web utilizando a IDE Eclipse para JEE.Com esta IDE é criado um projeto contendo páginas em JSP e Servlets, estas utilizadaspara lidar com chamadas em HTTP (GET e POST). Para implementar a aplicação web écriada uma Servlet para cada caso de uso do "Sistema de Controle de Estoque". Tambémé necessária a criação de uma classe para representar o produto. Além destas classes éutilizado o padrão DAO (Data Acess Object), este é responsável pela comunicação combanco de dados, assim realizando o armazenamento das informações dos produtos e asoperações da aplicação. Para construir uma interface de interação com o usuário, sãoutilizadas páginas em JSP, realizando comunicação com métodos da linguagem Java.Essas JSPs são criadas juntamente com formulários de HTML, possibilitando a entradade dados por usuários da aplicação. O terceiro passo compõe uma configuração da IDE Eclipse, definindo como servidora aplicação Apache Tomcat. Toda vez que o projeto é executado na IDE, é realizada umasincronização com o servidor Apache Tomcat, possibilitando a execução do projeto em umservidor web. Assim o projeto passa a ser executado através de um browser. Quando oservidor for executado, é possível fazer requisições HTTP à aplicação web retirada doprojeto da IDE. 3.4 - Análise Comparativa das Implementações Para continuar o estudo de caso é necessário realizar uma comparação entre asduas implementações do "Sistema de Controle de Estoque". Para isso é necessário autilização de um plugin integrado a IDE Eclipse. Este plugin chamado Metrics (METRICS, 37
  • 46. 2010), disponibiliza uma função que mostrar várias estatísticas e métricas do código daaplicação. Como exemplo de métricas podemos citar o número de linhas de código,número de classes e número de parâmetros. Ao realizar as métricas, são selecionadas as principais métricas que o pluginfornece, realizando a comparação entre as duas aplicações quanto aos seus códigos. Asprincipais métricas utilizadas são o número de métodos, número de classes, número delinhas de código, número de atributos e número de pacotes. Após levantar as métricas éobtido o resultado mostrado na Tabela 2. Nesta pode-se notar uma grande diferença entrea quantidade de código gerado. Nesta comparação é possível observar que o códigogerado possui mais linhas de código do que o código manual. Isso pode ser consideradauma possível não otimização do código gerado, que sendo utilizado em uma grandeaplicação pode ser que faça diferença. Pode-se também perceber que a aplicação manualpossui mais classes que a aplicação gerada, isso pode significar que a aplicação estámais reusável e bem organizada. Do número de métodos pode-se tirar uma conclusão, aaplicação gerada pela ferramenta WebRatio está gerando todos os métodos possíveisatravés de seus atributos, isto inclui construtores e sobrecargas de métodos. Isto é umtipo de não otimização do código, assim como o número de atributos gerados são muitomaiores. O número de pacotes supõe que a aplicação manual está muito mais organizadaem relação a aplicação gerada pela ferramenta WebRatio, já que o projeto está divididoem pastas. Comparação WebRatio Aplicação ManualNúmero de Métodos 62 31Número de Classes 4 7Número de Linhas de Código 409 277Número de Atributos 25 9Número de Pacotes 1 3 Tabela 2: Tabela mostrando comparação entre WebRatio e uma aplicação feita manualmente. Além da comparação através de métricas e estatísticas, também é possívelcomparar através do tempo. Mas isto fica muito relativo ao desenvolvedor, pois o tempovai variar de acordo com fatores do desenvolvedor. Mas tirando a mim como exemplodura mais ou menos 6 horas para implementar manualmente a aplicação, e dura mais oumenos 1 hora para implementar através da ferramenta WebRatio. Este tempo pode variar 38
  • 47. dependendo do tempo que o desenvolvedor necessita para implementar, além dedepender um pouco da máquina que está sendo utilizada. Também varia em relação aotempo disponível pelo desenvolvedor. Por isso não é um bom método para se compararatravés do tempo, já que o tempo varia radicalmente. Além do desenvolvedor o tempotambém é influenciado pelas tecnologias utilizadas, dependendo da facilidade que elasoferecem para a implementação. 39
  • 48. Conclusão Através de todo o conhecimento mostrado por este trabalho é possível chegar à umaconclusão sobre as vantagens da Engenharia de Software Baseada em Modelos,relacionando-a à uma Engenharia normal de uma aplicação. Com isso para concluir bastautilizar o conhecimento adquirido através do Capítulo 2, onde foram abordados todos osconceitos de WebML, e a prática realizada pelo Capítulo 3, onde foi feito um Estudo deCaso comparando duas implementações diferentes de um dado sistema especificado. É possível concluir que a implementação de um sistema através de ferramentas quegeram código, como proposto pela Engenharia de Software Baseada em Modelos, trásvantagens em relação ao esforço feito pelo programador da aplicação. Isto é possívellevando em conta que o programador possui experiência com uma linguagem de domínioespecífico. Sem experiência não é possível ter muitas vantagens, já que terá o esforço deapreender uma nova linguagem. Além disso é possível também concluir que umaimplementação gerada por ferramentas baseadas em modelos, pode facilitar em relaçãoao tempo levado para a implementação de um sistema. Mas vendo o lado mostrado peloEstudo de Caso, é possível concluir que estas ferramentas que geram código quasesempre geram códigos exageradamente, gerando assim uma não otimização do códigoda aplicação. Neste caso seria melhor a aplicação feita à mão. Um exemplo de umsistema que deveria ser implementado à mão é uma aplicação para dispositivos móveis,já que estes exigem uma otimização em seu código para economizar recursos limitados. Assim a vantagem de uma aplicação ser feita através de um modelo e ser geradaautomaticamente, é que economiza todo o esforço que o desenvolvedor levaria paraimplementar um grande projeto. E ainda mais economiza tempo, o que é atualmentemuito valorizado por empresas que participam de grandes projetos, que exigem uma altaprecisão e rapidez em relação ao tempo levado para concluir os projetos. 40
  • 49. Referências BibliográficasCERI, Estefano et al. Designing data-Intensive web applications. San Francisco: MorganKaufmann Publishers, 2003.SCHIMIDT, Douglas. Model-Driven Engineering. IEEE Computer 39 (2), 2006.CERI, Estefano; FRATERNALI, Piero; BONGIO, Aldo. Web Modeling Language (WebML):a Modeling Language for Designing Web Sites. WWW, 2000.BONGIO, Aldo et al. Modeling Data Entry and Operations in WebML. WebDB, 2000.ASTAH. Astah. 2010. Disponívle em: <http://astah.change-vision.com/en/index.html>.WEBRATIO. WebRatio. 2010. Disponível em: <http://www.weratio.com/>.METRICS Metrics. 2010. Disponível em: <http://metrics.sourceforge.net/>. 41