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

FUNDAÇÃO EDSON QUEIROZUNIVERSIDADE DE FORTALEZA – UNIFOR

CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCTCURSO CIÊNCIA DA COMPUTAÇÃO

Engenharia de Software Baseada em Modelos: Um Estudo Sobre WebML

João Gabriel de Paula Pessoa Cabral

Dezembro – 2010

i



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



PARECER: ______________________________

DATA: 21 / 12 / 2010

BANCA EXAMINADORA:

________________________________________________ D. Sc. Nabor das Chagas Mendonça

________________________________________________ D. Sc. Américo Tadeu Falcone Sampaio

iii

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, por

todo 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, pela

oportunidade e pelos conhecimentos compartilhados na execução desse trabalho.

Ao meus amigos Ronaldo, Nelson, Philipp, Ney e Henrique, pela ajuda oferecida, e

por todo o tempo vivenciado com diversão e companheirismo.

Aos professores e funcionários da UNIFOR, pela sabedoria compartilhada e pela

atenção oferecida.

Ao Prof. Fernando Trinta, por ter acompanhado e ajudado no começo do

desenvolver de meu trabalho.

Ao Prof. Américo Tadeu, pelas oportunidades oferecidas, e pela confiança a mim

oferecida.

A todos os amigos que estiveram presentes durante essa caminhada, tornando-a

inesquecível.

iv

RESUMO

Este trabalho tem como objetivo mostrar as vantagens e desvantagens da Engenharia de Software Baseada em Modelos. Principalmente é abordada uma linguagem de domínio específico chamada WebML, que é utilizada junto à ferramenta WebRatio. Assim foi feito um 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

Sumário

Introdução..............................................................................................................................1Capítulo 1 - Engenharia de Software Baseada em Modelos................................................2

1.1 – História e Origem......................................................................................................21.2 – Definição...................................................................................................................3

Capítulo 2 – Web Modeling Language..................................................................................52.1 - Modelo de Dados......................................................................................................62.2 - Modelo de Hipertexto..............................................................................................10

2.2.1 - Unidades (Units)...............................................................................................112.2.1.1 - Unidade de Dados (Data Unit).............................................................132.2.1.2 - Unidade de Multi Dados (Multidata Unit).............................................142.2.1.3 - Unidades de Índice (Index Unit)...........................................................152.2.1.4 - Unidades de Navegação (Scroller Units).............................................172.2.1.5 - Unidades de Entrada (Entry Units).......................................................18

2.2.2- Páginas (Pages)................................................................................................202.2.3 - Links.................................................................................................................20

2.2.3.1 - Especificação dos Links.......................................................................212.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.................................................................................................................323.2 - Sistema de Controle de Estoque.............................................................................333.3 - Implementação........................................................................................................34

3.3.1 - Implementação Utilizando a Ferramenta WebRatio........................................343.3.2 - Implementação Manual....................................................................................36

3.4 - Análise Comparativa das Implementações.............................................................37Conclusão............................................................................................................................40Referências Bibliográficas...................................................................................................41

vi

Lista de Figuras

Figura 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ção em 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ção em 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ção em 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ível renderizaçã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ção em 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

Lista de Tabelas

Tabela 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 feita manualmente.......................................................................................................................38

viii

Introdução

Atualmente existem várias tecnologias para a construção de Sistemas de

Informação. Algumas destas tecnologias, usadas conjuntamente, aumentam

consideravelmente a complexidade dos sistemas modernos. Para tratar tal complexidade,

processos e paradigmas de desenvolvimento têm sido propostos ao longo dos anos. Uma

dessas iniciativas é a Model-Driven Engineering (MDE), que traduzindo significa

Engenharia de Software Baseada em Modelos.

A Engenharia de Software Baseada em Modelos utiliza linguagens de modelagem

de domínios específicos, visando aumentar o nível de abstração dos sistemas levando a

uma diminuição da complexidade.

O objetivo deste trabalho é estudar a MDE, em particular, uma linguagem de

modelagem para Web chamada WebML (Web Modeling Language), identificando as

vantagens e desvantagens que a linguagem oferece em relação ao seu domínio. Para

alcançar este objetivo, será realizado um estudo de caso utilizando uma ferramenta

chamada WebRatio, que utiliza a linguagem WebML para construção de sistemas Web

centrados em dados. O estudo realizará uma comparação de desenvolvimento de um

sistema usando a ferramenta WebRatio e o desenvolvimento do mesmo sistema feito

“manualmente”, ou seja, usando as mesmas tecnologias usadas pela ferramenta

apresentada, mas sem gerar o código automaticamente.

Este trabalho está estruturado em cinco capítulos, sendo o primeiro esta Introdução

que apresenta o trabalho e o que será estudado. No Capítulo 1, é dada uma visão geral

do 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 os

modelos e diagramas que a compõem. No Capítulo 3, é abordado um estudo de caso

utilizando WebML junto com a ferramenta WebRatio, mostrando todo o ciclo de

desenvolvimento de uma aplicação Web centrado em dados, discutindo as vantagens e

desvantagens 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 no

cotidiano da Engenharia de Software.

1

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 que

ajudaram no desenvolvimento de programas, protegendo-os da complexidade dos

ambientes computacionais onde esses programas eram executados.

Estas abstrações incluem linguagens e plataformas. Como exemplo, pode-se citar as

primeiras linguagens de programação, como Assembly e Fortran, que protegeram os

desenvolvedores da complexidade de codificar em linguagem de máquina. Do mesmo

modo, plataformas de sistemas operacionais, como OS/360 e Unix, protegeram os

desenvolvedores das complexidades da programação diretamente para o hardware.

A característica comum entre os modos de proteger os desenvolvedores das devidas

complexidades foi a característica de elevar o nível de abstração, em particular, prover um

maior 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 de

máquina, e, no outro caso, uma plataforma de sistema operacional para abstrair da

programação diretamente com o hardware.

Vários esforços passados levaram à criação de tecnologias que elevam o nível de

abstração usado para o desenvolvimento de software. O maior esforço surgiu nos anos

80, quando foi criado o termo computer-aided software engineering (CASE), o qual focou

no desenvolvimento de software através de métodos e ferramentas que permitem aos

desenvolvedores expressar seus programas em termo de uma proposta geral com

representações gráficas para programação, como uma máquina de estados, diagramas

de estrutura e diagramas de fluxo de dados. A vantagem da CASE é que propõe uma

abordagem gráfica que incorre em uma menor complexidade comparado a uma

linguagem de programação convencional. Outra vantagem é que sintetiza artefatos vindos

de 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

comunidade acadêmica, ela não foi muito adotada na prática. Um problema que ela

enfrentou foi oferecer uma linguagem de representação gráfica geral para escrever

programas, 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ódigo

precisava compensar em tradução de tecnologias disponíveis até o momento, a qual fez

com que fosse difícil desenvolver, depurar, e evoluir ferramentas CASE e aplicações

criadas com estas ferramentas.

Outro problema com CASE foi sua inabilidade em aumentar a escalabilidade de uma

sistema complexo para uma variedade de domínios de aplicações. Mas, na época, eram

usados ambientes de execução proprietários que dificultavam o desenvolvimento para

diferentes plataformas, e dificultava a integração do código que era gerado com outras

linguagens de programação e outras tecnologias de plataforma. Ferramentas CASE não

suportaram vários domínios de aplicações efetivamente, por causa de suas

representaçõ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ção

para lidar com a complexidade de desenvolvimento de sistemas, seja essa complexidade

decorrente do uso das atuais tecnologias, paradigmas e processos da área de Engenharia

de Software.

A idéia por trás da Engenharia de Software Baseada em Modelos é utilizar modelos

de 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 detalhes

da implementação do sistema, livrando a parte de desenvolvimento de lidar com códigos

complexos que exigem um alto esforço para implementá-los. Como exemplo, o

desenvolvimento de um sistema Web, onde o desenvolvedor tem que lidar com várias

linguagens de programação, como também tem que lidar com vários frameworks e tipos

de processos de desenvolvimento de sistema. Neste caso, o desenvolvedor pode-se

utilizar de modelos como WebML, que facilitam a construção do sistema, apenas

utilizando-se de diagramas que modelam o funcionamento, a arquitetura, e a organização

dos dados do sistema.

3

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 uma

checagem de modelo no qual detecta-se erros e previne-se problemas no começo do

ciclo de vida do processo de desenvolvimento de software. O gerador de código da MDE

não necessita ser mais complicado, como na geração dos anos 80, já que conta com

padrões, APIs de plataformas de middleware e frameworks. Como resultado, ficou muito

mais fácil para desenvolver, depurar, e integrar ferramentas MDE e aplicações criadas

com estas ferramentas.

As vantagens da MDE são a redução do custo e do tempo do desenvolvimento de

software, uma melhor estruturação do processo de desenvolvimento de software, os

produtos são mais reutilizáveis e coerentes com a realidade, uma melhor

manutenibilidade, os modelos estão sempre atualizados com os produtos, e a

prototipação pode ser atingida imediatamente.

No próximo capítulo apresentaremos em mais detalhes um exemplo de uma

linguagem de domínio específico da MDE, a Web Modeling Language (WebML).

4

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-intensive

Web Applications). Ela permite aos projetistas expressarem características de um web site

em alto nível. Os conceitos de WebML são associados a representações gráficas

intuitivas, que podem ser suportadas facilmente por ferramentas CASE e podem

facilmente 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 alimentar

um gerador de código para a produção automática de uma implementação de um web

site.

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 livro

Design Data-Intensive Web Applications (CERI et. al., 2003) e serão apresentadas a

seguir. Alguns conceitos da WebML não serão abordados em muitos detalhes já que não

5

serão utilizados no estudo de caso.

2.1 - Modelo de DadosO objetivo da modelagem de dados é permitir a especificação de dados usados por

uma aplicação. O resultado da modelagem de dados é um esquema conceitual, que

convém de uma avaliação de conhecimento sobre os dados de uma aplicação. Desenhar

um esquema é um passo preliminar, tanto para o desenho de funções de negócios que

opera sobre os dados de uma aplicação, como também para a implementação de

estruturas físicas que suportam armazenamento de dados.

Modelagem de dados é uma das mais tradicionais disciplinas da Tecnologia de

Informação (TI), na qual possui linguagens de modelagem bem estabelecidas. Por este

fato, neste capítulo usaremos o modelo Entidade-Relacionamento, que é um dos modelos

de 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 descritas

por tipos de atributos (attributes), e podem ser organizadas em hierarquias de

generalização (generalization hierarchies), que expressam a derivação de um conceito

específico de um conceito mais geral de uma entidade. Relações são caracterizadas por

restrições de cardinalidade (cardinality constraints), que impõem restrições sobre o

número de instâncias de um objeto que podem fazer parte de um relação.

2.1.1 – EntidadesEntidade é o conceito central do modelo Entidade-Relacionamento. Uma entidade

representa a descrição de características comuns de um conjunto de objetos do mundo

real. Exemplos de entidades são Pessoa, Carro, Artista, e Álbum. Uma entidade tem o

conceito de população (population), que é um conjunto de objetos que são descritos por

uma entidade. Esses objetos são também chamados de instâncias de uma entidade. Por

exemplo, a população de uma entidade Pessoa é a especificação de um conjunto de

pessoas, 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ão

especificadas usando uma notação gráfica. Elas são denotadas como um retângulo, com

6

o nome da entidade no topo deste. A Figura 1 mostra um esquema em Entidade-

Relacionamento contendo duas entidades: Álbum (Album) e Artista (Artist).

2.1.1.1 – AtributosAtributos representam propriedades de objetos do mundo real que são relevantes

para as propostas de aplicação. Exemplos de atributos de uma entidade Pessoa são os

seguintes: 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 um

conjunto dos mesmos atributos. Em outras palavras, a entidade é uma descrição comum

de propriedades de um conjunto de objetos, e as propriedades são expressas pelos

atributos.

É admissível que uma entidade tenha valores nulos para um ou mais atributos. Mas

um valor nulo talvez represente diferentes situações de modelagem, e pode enraizar

ambiguidades na interpretação das propriedades de uma instância, a seguir mostrarei as

situaçõ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.

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

Figura 1: Notação gráfica para entidades.

Figura 2: Notação gráfica de entidades com atributos.

é caracterizada pelos atributos Title, Year, e Cover, e a entidade Artist pelos atributos

FirstName, LastName, Biography, e Photo.

2.1.1.2 – Identificação e Chave PrimáriaTodas as instâncias de uma entidade devem ser distinguidas, por um único

identificador que permite uma identificação não ambígua. Para expressar uma única

identidade de uma instância de uma entidade, um ou mais atributos podem ser definidos

como uma chave primária (primary key) de uma entidade. Atributos de chave primária

devem 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 assumiremos

que a propriedade OID é implícita e definida para todas as entidades, e omitida dos

diagramas de Entidade-Relacionamento.

Se uma entidade admite identificadores alternativos, por exemplo propriedades

usadas no domínio da aplicação para nomear instâncias de uma entidade, os atributos

identificadores podem ser definidos como chaves (keys) também chamadas de chaves

alternativas. Chaves alternativas devem ter valores não nulos e único, como as chaves

primárias.

Figura 3 mostra a entidade Album e Artist, completadas com a especificação de

chaves alternativas. O atributo Title é escolhido como chave da entidade Album, enquanto

o 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 do

nome do atributo.

2.1.1.3 – Hierarquias de GeneralizaçãoO modelo Entidade-Relacionamento permite o designer a organizar entidades em

uma hierarquia, onde elas compartilham algumas características comuns. A hierarquia de

8

Figura 3: Notação gráfica para chaves primárias.

generalização básica tem uma super entidade e uma ou mais subentidades. Cada

subentidade herda todos os atributos e relações. Por exemplo, a Figura 4 especifica que

JazzArtist e PopArtist são subentidades de uma entidade Artist, e JazzArtist tem um

atributos 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 e

JazzArtist são generalizados em Artist.

2.1.2 – RelaçõesRelações representam conexões semânticas entre entidades, como uma associação

entre um artista e seu álbum, ou entre um artista e suas revisões. O significado de uma

associaçã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 ser

nomeada Publicação. A forma mais simples de relação é uma relação binária (binary

relationships), que conecta duas entidades. Relações envolvendo mais de duas

entidades, são chamados relações-N-árias, mas relações-N-árias são desencorajadas de

seu uso, porque elas podem ser expressadas pelo significado de múltiplas relações

biná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. Por

exemplo, a relação Publicação entre um artista e seu álbum pode ser decomposta em

dois papéis de relação, um de artista parar álbum, chamado Publica, e outro de álbum

9

Figura 4: Notação gráfica para hierarquia de generalização

para artista chamado Publicado_Por. Assim um papel de relação pode ser entendido

como uma associação orientada, conectando uma entidade fonte com uma entidade

destino.

Papéis de relação podem ser anotados com restrições de cardinalidade máxima e

mínima, respectivamente denotando o número máximo e mínimo de objetos de uma

entidade 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 representadas

por arestas conectando retângulos de entidades. Em particular a figura mostra a relação

Publication, 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 cada

artista 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 de

artista para álbum é opcional.

A Figura 6 mostra a notação gráfica para especificar os nomes dos papéis de

relações da relação Publication.

2.2 - Modelo de HipertextoModelagem de hipertexto é uma disciplina considerada jovem, ela ainda não possui

uma base bem estabelecida de conceitos, notações, e métodos de concepção.

Deve ser considerada pelo designer como uma extensão natural do modelo

Entidade-Relacionamento, que permite ao programador expandir o esquema de dados da

aplicaçã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) e

ligações (links), organizados em construções modulares chamadas visões de site (site

views).

10

Figura 5: Notação gráfica para relações

Figura 6: Notação gráfica para papéis de relação

As unidades são formadas pelas unidades atômicas de conteúdo publicável, elas

oferecem formas alternativas de organizar o conteúdo dinamicamente extraídos do

esquema de dados Entidade-Relacionamento, e também permite a especificação das

formas de entrada de dados pelos usuários. As unidades são blocos de construções de

pá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 de

vá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 uma

estrutura de hipertexto.

As ligações que representam um marco da modelagem de hipertexto: expressam a

possibilidade de navegação de um ponto a outro no hipertexto, e a passagem de

parâmetros de uma unidade para outra unidade, que é necessário para o cálculo

adequado do conteúdo de uma página.

Um conjunto de páginas podem ser agrupadas em uma visão de site, na qual

representa um hipertexto servindo de um conjunto bem definido de requisitos, por

exemplo, 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 uma

grande visão de site pode ser decomposta hierarquicamente em áreas (areas), como

“home”, “default” e propriedades “landmark”, permite o designer ajustar o nível de

visibilidade 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 no

ní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 e

explorados 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

• 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 para

representar páginas da web de complexidade arbitrária. As primeiras quatro unidades

modelam a publicação de informações, unidades de dados e multi-dados apresentam o

conteúdo atual dos objetos no qual elas se referem, enquanto que unidades de índice e

navegação facilitam a seleção de objetos. Unidades de dados refere-se à um único

objeto, enquanto unidades de multi-dados, índice, e navegação referem-se a um conjunto

de objetos.

Unidades de dados, multi-dados, índice e navegação apresentam conteúdo extraído

de 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 transmite

características essenciais, e uma representação textual, que podem ser usadas para

especificar unidades detalhadas de propriedades adicionais não convenientemente

exprimível pela notação gráfica.

Unidades de conteúdo são graficamente representadas como retângulos contendo

12

ícones rotulados. O nome da unidade é colocado dentro do retângulo, por cima do ícone

da unidade. A fonte e o seletor são colocados debaixo do retângulo. A representação

textual, adiciona mais detalhes, como no caso das unidades de índice, a ordenação dos

objetos 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 unidade

de 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.

A Figura 7 mostra uma notação gráfica de uma unidade de dados nomeada como

ShortArtist 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 quais

atributos a unidade será ordenada.

13

Figura 7: Notação gráfica e textual para unidades de dados

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 multi

dados é 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.

As Figuras 8, 9 mostram respectivamente uma representação textual e gráfica de

unidades de multi dados do modelo de hipertexto, a diferença da unidade de dados para

multi dados, é que a unidade de multi dados exibe várias informações sobre as instâncias

da entidade fonte, como mostrado na Figura 9, onde é exibida uma renderização em

HTML de uma página contendo uma unidade de multi dados no caso MultiArtist.

14

Figura 8: Notação textual para unidades multi dados

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.



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ível

renderização em HTML. Na notação o nome definido pelo usuário para a unidade fica

acima das listras localizadas no centro, no caso o nome é AlbumIndex, no centro as listras

formando um índice indicam que esta unidade é uma unidade de índice, e abaixo mostra

uma bolinha com um nome abaixo, onde o nome significa o nome da entidade fonte que

listará todas as suas instâncias na tela.

15

Figura 9: Notação gráfica para unidades multi dados, e uma renderização em HTML

Unidades de índice admitem duas variantes para escolha de múltiplos objetos, e

para 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 o

usuário a selecionar múltiplos objetos. Como mostrado na Figura 11.

A segunda variante da unidade de índice é o conceito de índice hierárquico, no qual

os índices são organizados em uma árvore de multi-nível. A hierarquia é representada por

uma sequência de N entidades fonte conectadas por N-1 papéis de relação. A primeira

entidade fonte representa a instância de nível do topo da hierarquia, a segunda entidade

fonte, introduzida pela cláusula NEST, representa as instâncias do segundo nível da

hierarquia. Cada papel de relação denota uma associação pai-filho entre duas entidades

16

Figura 10: Notação gráfica para unidades de índice

Figura 11: Notação gráfica para unidade de índice de múltipla escolha e uma renderização em HTML.

nos níveis consecutivos da hierarquia. Um exemplo de notação gráfica de índice

hierárquico é mostrado pela Figura 12.

Um caso especial de índice hierárquico explora uma relação recursiva definida sobre

uma 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.

2.2.1.4 - Unidades de Navegação (Scroller Units)Unidades de navegação provém comandos para navegar entre os objetos de dentro

de um conjunto, por exemplo para navegar sobre todas as instâncias de uma entidade. A

especificação de uma unidade de navegação é caracterizada pelas propriedades:

• Nome: nome definido pelo usuário para a unidade de navegação.



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

Figura 12: Notação gráfica para unidade de índice hierárquico.

A Figura 13 mostra a notação gráfica definida pela WebML para unidade de

navegação, onde no exemplo há o nome AlbumScroll definido pelo usuário, e abaixo uma

bolinha com o nome da entidade fonte logo abaixo. E também é mostrado uma

renderizaçã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,que

foram inicialmente propostas por BONGIO, Aldo et al. (2000). Elas são usadas para

receber 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 normalmente

encontrados na construção de formulários de linguagens de marcação. Campos de

entrada tem um número de propriedades, definidas pelas propriedades abaixo:

• Nome: o nome do campo.

18

Figura 13: Notação gráfica em WebML para unidades de navegação, e uma renderização em HTML.

• 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.

19

Figura 15: Notação gráfica em WebML de uma unidade de entrada, e uma renderização em HTML.

Figura 14: Notação textual de uma unidade de entrada.

As Figuras 14 e 15 mostram respectivamente uma notação gráfica e uma notação

textual de uma mesma unidade de dados, note que apenas percebe-se a definição dos

campos na notação textual, ou seja, toda vez que for definir uma unidade de entrada deve

ser 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 hipertexto

acessando suas páginas numa sequência desejada. Uma página tipicamente consiste de

muitas unidades, agrupadas juntas para completar uma proposta de comunicação bem

definida.

A Figura 16 mostra a notação gráfica e textual de uma página em WebML, no caso a

página é um retângulo grande que possui unidades dentro e em sua especificação textual

contém os nomes da unidades que irão fazer parte da página.

2.2.3 - LinksNem páginas e nem unidades existem isoladas, porque hipertextos são feitos de

pá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ção

permitido entre as páginas, as seleções oferecidas ao usuário, e o efeito da interação do

usuário sobre o conteúdo das unidades exibidas na página.

Modelagem de navegação é a parte de modelagem de hipertexto que trata da

especificação das ligações entre as unidades e páginas, e das propriedades de tais links.

20

Figura 16: Notação gráfica e textual de uma página em WebML.

As noções centrais de modelagem de navegação são os conceitos de ligação, parâmetros

de 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 LinksLinks 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 o

hipertexto.

A noção de âncora deve ser considerada em sentido lato. Os seguintes casos

práticos, submetido a um hipertexto baseado em HTML, são exemplos do que pode ser

considerado 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

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 chamados

links inter-páginas, enquanto que os links com origem e destino dentro da mesma página

são chamados intra-páginas, links de transporte de informações são chamados

contextuais, 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 ou

página fonte para a unidade ou página de destino.

No exemplo da Figura 17 mostra um link inter-página não contextual. O link conecta

uma página fonte (PopArtists), que inclui uma unidade multi dados mostrando os asrtistas

de pop, para uma página destino (JazzArtists), que inclui uma unidade multi dados

mostrando os artistas de jazz. O conteúdo da página JazzArtists é independente do

conteúdo da página PopArtists, e esta navegação não requer qualquer informação para

ser passada da página fonte para a destino.

2.2.3.2 - Parâmetros de Ligação e Seletores ParamétricosA 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 um

seletor paramétrico, definido na unidade destino.

Um parâmetro de link (link parameter) é um valor associado com um link entre

unidades, que é transportado, como um efeito de navegação de link, de uma unidade

fonte à uma unidade destino. Um seletor paramétrico (parametric selector) é uma unidade

seletora 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

Figura 17: Notação gráfica e textual de um link.

na Figura 18, que pode ser usado para se referir ao parâmetro no seletor da unidade

destino. O rótulo indica o conteúdo do parâmetro, que é tanto um atributo ou um campo

da unidade de origem do link, quando o rótulo refere-se a um atributo, que consiste na

concatenação de nomes de entidades e atributos, separados por um ponto. O nome da

entidade pode ser omitido, se resulta do contexto, como o rótulo OID na Figura, que

representa Artist OID. A saída de valores produzidos pelas unidades de diversas fontes e

os 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

Unidade de DadosQualquer atributo (incluindo o OID) do objeto mostrado pela unidade

EntidadeFonte.nomeAtributo

Unidade de Multi Dados

O conjunto de valores de qualquer atributo (incluindo OID) do objeto mostrado pela unidade

{EntidadeFonte.nomeAtributo}

Unidade de Índice

O valor de qualquer atributo de um objeto selecionado pelo usuário clicando em uma âncora na unidade de índice


Unidade de Índice Hierárquico

O valor de qualquer atributo do objeto selecionado pelo usuário clicando sobre uma âncora na unidade. Todos os objetos mostrados em qualquer nível da hierarquia pode ser selecionado


Unidade de Índice de Múltipla Escolha

O conjunto de valores de qualquer atributo de múltiplos objetos selecionados pelo usando os checks boxes da unidade


Unidade de Navegação

O conjunto de valores de qualquer atributo do bloco de objetos selecionados por clicar sobre a âncora na unidade


Unidade de Entrada O valor de entrada pelo usuário em cada campo nomeCampo

Tabela 1: Parâmetros de link providos na saída por unidades de conteúdo.

23

2.3 - Modelo de Gerenciamento de ConteúdoPara introduzir operações de dados em WebML foi criado o modelo de

gerenciamento de conteúdo. A introdução de operações em dados na WebML não exige

mudanças no modelo de dados, e requer duas simples e intuitivas extensões para o

modelo 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 como

resultado de uma navegação em um link. Uma unidade de operação pode denotar tanto

uma manipulação de dados, como também a execução de um serviço externo genérico. A

segunda 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 de

operação respectivamente com sucesso e com falha, e permitem o designer a pegar

cursos alternativos depois da execução de uma operação, dependendo da saída da

execução.

WebML inclui muitas unidades de operações predefinidas, que oferecem as mais

comuns primitivas para atualizar as instâncias de uma entidade e de relações de uma

aplicação, pela criação, modificação, e deleção de objetos, e conectando e

desconectando 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 de

conteúdo podem ser clusterizadas em transações (transactions), que são sequências de

atualizações automáticas. Quando uma transação é especificada, é seguida uma

sequência de operações individuais que consistem em uma execução com sucesso, ou

uma execução totalmente desfeita.

2.3.1 – OperaçõesAs unidades de operações de WebML, ou então somente operações, são um novo

24

Figura 18: Link inter-página contextual com parâmetro de link associado.

tipo de unidades, que podem ser colocadas fora de páginas e linkadas a outras

operações, ou linkadas a unidades de conteúdo definidas dentro de páginas. Diferentes

das unidades de conteúdo, as operações não exibem um conteúdo, o que justifica o fato

delas poderem ser colocadas fora de páginas; elas fazem ações. Como unidades de

conteúdo, operações podem ter objetos fonte (como uma entidade ou uma relação) e

seletores, podem também receber parâmetros vindos de um link de entrada, e pode

prover 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 os

seguintes 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é-definidasWebML provém um número de operação já construídas, na quais são pré-definidas

na linguagem. Como a orientação é sobre aplicações web de dados intensivos, as

operações pré-definidas usam mais tarefas de gerenciamento de dados. Algumas outras

poucas operações também oferecidas pela WebML são providas, como serviços de

utilidade geral, frequentemente usadas em uma aplicação Web. Elas são operações de

login, logout e de envio de e-mail.

2.3.2.1 - Criação de ObjetoA primeira operação é a unidade de criação (create unit), que oferece o serviço de

criação de uma nova instância de uma entidade. Cada unidade de criação é caracterizada

pelo seguinte:

• Um nome definido pelo usuário.

25

• 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.

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 uma

entrada para a unidade de criação (CreateArtist), criando uma nova instância de uma

entidade (Artist). No exemplo, a unidade de entrada tem dois campos (FistName,

LastName), para entrada do primeiro nome e segundo nome de um artista. Os valores

inseridos pelo usuário são associados como parâmetros explícitos com o link da unidade

26

Figura 19: Notação textual do exemplo.

de entrada para a operação de criação. Estes parâmetros são ligados à atributos do

objeto artista para ser criado duas atribuições, representado abaixo da entidade fonte da

unidade de criação. Na renderização, mostrada na Figura , o link de saída da unidade de

entrada é mostrado como um botão de submissão (submit button), permitindo a ativação

da operação. A operação CreateArtist tem dois links de saída, o OK link aponta para a

unidade de dados ArtistDetails e é associado com o parâmetro de link padrão (o OID do

novo objeto). O KO link aponta de volta para a página ArtistCreation, para o usuário tentar

a operação novemente. A descrição completa textual do exemplo é mostrada na Figura

19. Em particular, a unidade de criação e os OK e KO links são exemplificados.

2.3.2.2 - Deleção de ObjetoA unidade de deleção (delete unit) é usada para deletar um ou mais objetos de uma

dada 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 por

uma unidade de dados ou selecionado por uma unidade de índice ou de navegação, ou

um conjunto de objetos mostrado por uma unidade de multi dados ou selecionado por

27

Figura 20: Notação gráfica em WebML para unidades de criação, e uma possível renderização em HTML

uma unidade de índice de múltipla escolha. O OID correspondente ou um conjunto de

OIDs é 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 conjunto

de OIDs recebido na entrada, isto é [OID=<parâmetro de link>] se o parâmetro de link de

entrada possui apenas um valor, ou [OID IN <parâmetro de link>] se o parâmetro de link

de entrada é multivalorado. Como usualmente, o seletor padrão pode ser inferido e não

necessariamente tem que ser expressado na notação gráfica e notação textual.

O OK link é seguido quando todos os objetos determinados pelo seletor forem

deletados, e não tem nenhum parâmetro de link. O KO link é seguido quando nenhum dos

objetos forem deletados, e associa com os parâmeros de link o OID ou o conjunto de

OIDs 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 e

representa um exemplo de deleção de um único objeto. A página Album inclui a unidade

AlbumIndex, linkada à unidade de deleção. O link tem um parâmetro padrão, segurando o

OID do álbum selecionado, que é usado no seletor implícito da unidade de deleção. A

navegação do link dispara a deleção do objeto selecionado. Se a operação for bem

sucedida 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 deletado

continuará aparecendo no índice.

28

Figura 21: Notação gráfica WebMl para unidade de deleção, e renderização em HTML

A especificação textual de uma unidade de delação é simples e mostrada na Figura

22.

2.3.2.3 - Modificação de ObjetoA unidade de modificação (modify unit) é usada para atualizar om ou mais objetos de

uma 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 conjunto

de objetos à serem modificados, em poucas palavras a mesma modificação aplica a todos

os objetos selecionados.

Uma unidade de modificação deve ser linkada a outras unidades, para obter as

entradas 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

Figura 22: Notação Textual para unidades de deleção.

modificados com sucesso, neste caso o OK link tem um parâmetro padrão segurando o

conjunto de objetos modificados. O KO link é seguido quando algum dos objetos não

pode ser modificado, e tem como parâmetro padrão o conjunto de OIDs dos objetos que

não foram modificados.

O exemplo da Figura 23 mostra uma unidade de entrada usada para suprir valores

para 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 transporte

da unidade de dados para unidade de modificação tem um parâmetro padrão segurando o

OID do artista a ser modificado, que é usado pelo seletor padrão da unidade de

modificação. A unidade de modificação é ativada pelo segundo link, saindo da unidade de

entrada, como o link tem um parâmetro explicito (chamado Bio), que segura o valor do

campo de entrada da unidade de entrada, usado na atribuição <BiographicInfo:=Bio> da

operação. O OK link leva à uma página de Resultado chamada Result, que mostra os

valores atuais do atributo BiographicInfo. O KO link aponta de volta para a unidade

BioData. Note que em caso de sucesso, o novo valor da biografia é apresentado na

unidade de dados BioData.

30

Figura 23: Notação gráfica em WebML para unidades de modificação, e uma renderização em HTML

A especificação textual da unidade de modificação, com o seletor padrão omitido, é

mostrada na Figura 24.

31

Figura 24: Notação textual de uma unidade de modificação.

Capítulo 3 – Estudo de Caso

Neste capítulo é abordado um Estudo de Caso, que realiza uma comparação entre

duas implementações de um sistema de controle de estoque. As implementações são

realizadas de dois modos: um implementa utilizando a ferramenta WebRatio e o outro

implementa manualmente.

Este capítulo mostra o passo a passo das implementações, e também especifica a

ferramenta WebRatio, mostrando suas características e tecnologias usadas. Ao final do

capítulo é realizada uma Análise de Comparação das duas implementações, mostrando

as diferenças, vantagens e desvantagens de cada modo de implementação.

3.1 - WebRatioWebRatio (WebRatio,2010) é uma ferramenta que gera aplicações padrões e

abertas de Java Web. Suas aplicações são entregáveis em qualquer servidor de

aplicaçõ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 do

Hibernate, conectando-se a qualquer banco de dados que suporta JDBC. Inclui também

as tecnologias de Struts, JSTL, JSP e Java Servlet.

32

Figura 25: Interface da ferramenta WebRatio.

A implementação utilizando a ferramenta WebRatio, é realizada a partir dos modelos

de WebML. Neste caso são utilizados os seguintes modelos: modelo de dados e modelo

de hipertexto. Para isso a ferramenta WebRatio disponibiliza uma interface para o

designer. Ele poderá modelar sua aplicação através da adição de entidades em modelos

de 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 de

gerenciamento de conteúdo. Esta interface é mostrada na Figura 25, que mostra um

exemplo de uma aplicação com páginas e unidade de conteúdo

.

3.2 - Sistema de Controle de EstoqueNeste trabalho é necessário especificar um sistema para o estudo de caso, que é

utilizado para a implementação de dois modos. Para isso é escolhido um sistema

simples, com a finalidade de ser fácil comparar os dois modos de implementação. Neste

caso é escolhido um sistema de controle de estoque, sendo nomeado como "Sistema de

Controle de Estoque". Neste sistema é definido quatro casos de uso, sendo os seguintes:

cadastrar produto, alterar produto, remover produto e buscar produto. Os casos de uso

são mostrados na Figura 26 por um diagrama de caso de uso. Definindo assim um ator

que interage com as operações alterar, buscar, cadastrar e remover produtos do estoque.

Este diagrama é gerado pela ferramenta Astah (ASTAH, 2010).

33

Figura 26: Diagrama de caso de uso para o Sistema de Controle de Estoque.

3.3 - ImplementaçãoPara realizar as implementações do "Sistema de Controle de Estoque", são

escolhidas duas formas de implementação. Uma utilizando a ferramenta WebRatio, onde

é gerada toda aplicação web à partir da linguagem WebML, e a outra é implementar

através da utilização de ferramentas básicas, que o desenvolvedor programará a

aplicaçã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 ferramenta

WebRatio, é 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 modelo

Entidade-Relacionamento para definir as entidades e relacionamentos da aplicação. O

segundo passo é definir o modelo de hipertexto da aplicação. Esse modelo é usado para

definir as páginas e links da aplicação web.

No primeiro passo, a ferramenta já disponibiliza duas entidades e um

relacionamento, que são respectivamente User, Module e Group. Para seguir os

requisitos do "Sistema de Controle de Estoque" é definida uma entidade chamada

Produto. A entidade Produto representa produtos reais de um estoque, que podem ser

armazenados por lojas, por armazéns e por outros locais que armazenam produtos em

seu estoque. Esta entidade possui os quatro seguintes atributos: oid, nome, descricao e

quantidade. O atributo oid significa object identifier, ele é utilizado para identificar

unicamente um objeto, e é definido como chave primária. O atributo nome é utilizado

para nomear o produto que é cadastrado no estoque. O atributo descricao serve para

descrever o objeto dando suas principais características como modelo ou aparência do

produto. E finalmente o atributo quantidade, que tem a utilidade de quantificar o produto

armazenado no estoque. Os tipos dos atributos seguindo a ordem são respectivamente os

seguintes: integer, string, string e integer. As outras entidades não precisam ser

abordadas, mas provavelmente são utilizadas para realizar o login da aplicação. Abaixo a

Figura 27 mostra o esquema de dados do "Sistema de Controle de Estoque", definido

com o modelo Entidade-Relacionamento na ferramenta WebRatio.

34

Ainda seguindo o primeiro passo, é preciso definir a comunicação do modelo de

dados com o banco de dados utilizado. Para isso a ferramenta disponibiliza uma interface

capaz de facilitar a comunicação com o banco de dados. Esta interface disponibiliza

campos, utilizando informações requeridas pelo conector JDBC, como a url do banco de

dados, informações de autenticação do usuário e senha do usuário do banco. Além

destas informações um detalhe também é necessário, a ferramenta necessita do driver

responsável por realizar a comunicação. Este driver, que no caso é um arquivo, tem que

ser renomeado e colocado em uma pasta específica onde está localizada a ferramenta.

O segundo passo define o modelo de hipertexto, incluindo o modelo de

gerenciamento de conteúdo. Para compor o modelo de hipertexto é necessário utilizar

páginas e unidades como definidas na linguagem WebML, utilizando a interface da

ferramenta WebRatio. Nesta é possível adicionar facilmente os elementos da linguagem

WebML. Com a ferramenta WebRatio, o usuário adiciona as representações gráficas de

páginas e unidades para compor o modelo de hipertexto e modelo de gerenciamento de

conteúdo. Estes modelos são mostrados em uma visão de site criada pela ferramenta, e

definida pelo usuário. No caso do "Sistema de Controle de Estoque" é necessário definir o

modelo 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 cada

página pelo menos uma unidade é adicionada. Por exemplo, no caso de uso alterar, são

35

Figura 27: Modelo de Dados da aplicação em WebRatio.

utilizadas duas páginas, uma contendo todos os produtos do estoque, definida por uma

unidade 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 outra

página, onde é mostrado os dados atuais do objeto selecionado. Para mostrar os dados

do objeto selecionado é utilizada uma unidade de dados, e os campos que deverão ser

preenchidos com novos valores, com isso os valores serão utilizados para a modificação

do objeto selecionado. Neste caso é utilizada uma unidade de entrada. Ao confirmar os

dados da alteração do objeto, serão transportados os dados pelo link, destinando uma

unidade de modificação. Esta é utilizada para atualizar o banco de dados. Os outros

casos de uso podem ser vistos na Figura 28, que mostra todo o modelo de dados do

"Sistema de Controle de Estoque".

3.3.2 - Implementação Manual

Para a implementação manual do "Sistema de Controle de Estoque" são utilizados

três passos. O primeiro é criar o banco de dados da aplicação, utilizando as ferramentas

disponibilizadas pelo PostgreSQL. Essas ferramentas disponibilizam uma interface capaz

do usuário escrever comandos em SQL, e executá-los no banco de dados. O segundo

36

Figura 28: Modelo de Hipertexto da aplicação em WebRatio.

passo é implementar a aplicação web através da IDE Eclipse, onde o desenvolvedor

codifica toda a aplicação usando a linguagem Java. Além de Java também são utilizadas

as tecnologias Java Servlet e JSP. O terceiro passo compõem utilizar o servidor Apache

Tomcat, com a finalidade de executar a aplicação web em um servidor, e executá-la em

um browser.

No primeiro passo é criada uma entidade chamada Produto. Esta possui os quatro

seguintes atributos: oid, nome, descricao, quantidade. O atributo oid significa object

identifier, é do tipo integer, é auto incrementável, e também chave primária. O atributo

nome significa o nome dado ao produto, ele é do tipo string. O atributo descricao significa

uma descrição do produto em estoque, ele é um atributo do tipo string. E finalmente o

atributo quantidade, que significa a quantidade do produto armazenado no estoque, e seu

tipo é 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 utilizadas

para 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 com

banco de dados, assim realizando o armazenamento das informações dos produtos e as

operações da aplicação. Para construir uma interface de interação com o usuário, são

utilizadas 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 entrada

de dados por usuários da aplicação.

O terceiro passo compõe uma configuração da IDE Eclipse, definindo como servidor

a aplicação Apache Tomcat. Toda vez que o projeto é executado na IDE, é realizada uma

sincronização com o servidor Apache Tomcat, possibilitando a execução do projeto em um

servidor web. Assim o projeto passa a ser executado através de um browser. Quando o

servidor for executado, é possível fazer requisições HTTP à aplicação web retirada do

projeto da IDE.

3.4 - Análise Comparativa das ImplementaçõesPara continuar o estudo de caso é necessário realizar uma comparação entre as

duas implementações do "Sistema de Controle de Estoque". Para isso é necessário a

utilização de um plugin integrado a IDE Eclipse. Este plugin chamado Metrics (METRICS,

37

2010), disponibiliza uma função que mostrar várias estatísticas e métricas do código da

aplicaçã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 plugin

fornece, realizando a comparação entre as duas aplicações quanto aos seus códigos. As

principais métricas utilizadas são o número de métodos, número de classes, número de

linhas 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 entre

a quantidade de código gerado. Nesta comparação é possível observar que o código

gerado possui mais linhas de código do que o código manual. Isso pode ser considerada

uma possível não otimização do código gerado, que sendo utilizado em uma grande

aplicação pode ser que faça diferença. Pode-se também perceber que a aplicação manual

possui 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, a

aplicação gerada pela ferramenta WebRatio está gerando todos os métodos possíveis

através de seus atributos, isto inclui construtores e sobrecargas de métodos. Isto é um

tipo de não otimização do código, assim como o número de atributos gerados são muito

maiores. O número de pacotes supõe que a aplicação manual está muito mais organizada

em relação a aplicação gerada pela ferramenta WebRatio, já que o projeto está dividido

em 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ível

comparar através do tempo. Mas isto fica muito relativo ao desenvolvedor, pois o tempo

vai variar de acordo com fatores do desenvolvedor. Mas tirando a mim como exemplo

dura mais ou menos 6 horas para implementar manualmente a aplicação, e dura mais ou

menos 1 hora para implementar através da ferramenta WebRatio. Este tempo pode variar

38

dependendo do tempo que o desenvolvedor necessita para implementar, além de

depender um pouco da máquina que está sendo utilizada. Também varia em relação ao

tempo disponível pelo desenvolvedor. Por isso não é um bom método para se comparar

através do tempo, já que o tempo varia radicalmente. Além do desenvolvedor o tempo

também é influenciado pelas tecnologias utilizadas, dependendo da facilidade que elas

oferecem para a implementação.

39

Conclusão

Através de todo o conhecimento mostrado por este trabalho é possível chegar à uma

conclusão sobre as vantagens da Engenharia de Software Baseada em Modelos,

relacionando-a à uma Engenharia normal de uma aplicação. Com isso para concluir basta

utilizar o conhecimento adquirido através do Capítulo 2, onde foram abordados todos os

conceitos de WebML, e a prática realizada pelo Capítulo 3, onde foi feito um Estudo de

Caso comparando duas implementações diferentes de um dado sistema especificado.

É possível concluir que a implementação de um sistema através de ferramentas que

geram código, como proposto pela Engenharia de Software Baseada em Modelos, trás

vantagens em relação ao esforço feito pelo programador da aplicação. Isto é possível

levando em conta que o programador possui experiência com uma linguagem de domínio

específico. Sem experiência não é possível ter muitas vantagens, já que terá o esforço de

apreender uma nova linguagem. Além disso é possível também concluir que uma

implementação gerada por ferramentas baseadas em modelos, pode facilitar em relação

ao tempo levado para a implementação de um sistema. Mas vendo o lado mostrado pelo

Estudo de Caso, é possível concluir que estas ferramentas que geram código quase

sempre geram códigos exageradamente, gerando assim uma não otimização do código

da aplicação. Neste caso seria melhor a aplicação feita à mão. Um exemplo de um

sistema 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 gerada

automaticamente, é que economiza todo o esforço que o desenvolvedor levaria para

implementar um grande projeto. E ainda mais economiza tempo, o que é atualmente

muito valorizado por empresas que participam de grandes projetos, que exigem uma alta

precisão e rapidez em relação ao tempo levado para concluir os projetos.

40

Referências Bibliográficas

CERI, Estefano et al. Designing data-Intensive web applications. San Francisco: Morgan

Kaufmann 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

Documents

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