Engenharia de Software Baseada em Modelos: Um Estudo Sobre WebML

FUNDAÇÃO EDSON QUEIROZ
UNIVERSIDADE DE FORTALEZA – UNIFOR
CENTRO DE CIÊNCIAS TECNOLÓGICAS – CCT
CURSO 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


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

Sobre WebML


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..............................................................................................................................1
Capítulo 1 - Engenharia de Software Baseada em Modelos................................................2
1.1 – História e Origem......................................................................................................2
1.2 – Definição...................................................................................................................3
Capí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................................................................24
Capí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.............................................................37
Conclusão............................................................................................................................40
Referências Bibliográficas...................................................................................................41

vi

Lista de Figuras

Figura 1: Notação gráfica para entidades..............................................................................7
Figura 2: Notação gráfica de entidades com atributos..........................................................7
Figura 3: Notação gráfica para chaves primárias..................................................................8
Figura 4: Notação gráfica para hierarquia de generalização................................................9
Figura 5: Notação gráfica para relações..............................................................................10
Figura 6: Notação gráfica para papéis de relação...............................................................10
Figura 7: Notação gráfica e textual para unidades de dados..............................................13
Figura 8: Notação textual para unidades multi dados.........................................................14
Figura 9: Notação gráfica para unidades multi dados, e uma renderização em HTML......15
Figura 10: Notação gráfica para unidades de índice...........................................................16
Figura 11: Notação gráfica para unidade de índice de múltipla escolha e uma renderização
em HTML..............................................................................................................................16
Figura 12: Notação gráfica para unidade de índice hierárquico..........................................17
Figura 13: Notação gráfica em WebML para unidades de navegação, e uma renderização
em HTML..............................................................................................................................18
Figura 14: Notação textual de uma unidade de entrada.....................................................19
Figura 15: Notação gráfica em WebML de uma unidade de entrada, e uma renderização
em HTML..............................................................................................................................19
Figura 16: Notação gráfica e textual de uma página em WebML.......................................20
Figura 17: Notação gráfica e textual de um link..................................................................22
Figura 18: Link inter-página contextual com parâmetro de link associado.........................24
Figura 19: Notação textual do exemplo...............................................................................26
Figura 20: Notação gráfica em WebML para unidades de criação, e uma possível
renderização em HTML.......................................................................................................27
Figura 21: Notação gráfica WebMl para unidade de deleção, e renderização em HTML. .28
Figura 22: Notação Textual para unidades de deleção.......................................................29
Figura 23: Notação gráfica em WebML para unidades de modificação, e uma renderização
em HTML..............................................................................................................................30
Figura 24: Notação textual de uma unidade de modificação..............................................31
Figura 25: Interface da ferramenta WebRatio.....................................................................32
Figura 26: Diagrama de caso de uso para o Sistema de Controle de Estoque..................33
Figura 27: Modelo de Dados da aplicação em WebRatio...................................................35
Figura 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.......................23
Tabela 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 Dados
O 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 – Entidades
Entidade é o conceito central do modelo Entidade-Relacionamento. Uma entidade
representa a descrição de características comuns de um conjunto de objetos do mundo
real. 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).

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

2.1.1.1 – Atributos
Atributos 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.

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

é 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ária
Todas 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.

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 em
uma hierarquia, onde elas compartilham algumas características comuns. A hierarquia de

8

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.

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

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.

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

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.

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

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.

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

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 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.
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 10: Notação gráfica para unidades de índice

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.

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

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.

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

• 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

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.

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

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

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

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
Qualquer atributo (incluindo o
Unidade de Dados OID) do objeto mostrado pela EntidadeFonte.nomeAtributo
unidade
O conjunto de valores de
Unidade de Multi
qualquer atributo (incluindo OID) {EntidadeFonte.nomeAtributo}
Dados
do objeto mostrado pela unidade
O valor de qualquer atributo de
um objeto selecionado pelo
Unidade de Índice EntidadeFonte.nomeAtributo
usuário clicando em uma âncora
na unidade de índice
O valor de qualquer atributo do
objeto selecionado pelo usuário
Unidade de Índice clicando sobre uma âncora na
EntidadeFonte.nomeAtributo
Hierárquico unidade. Todos os objetos
mostrados em qualquer nível da
hierarquia pode ser selecionado
qualquer atributo de múltiplos
Unidade de Índice de
objetos selecionados pelo {EntidadeFonte.nomeAtributo}
Múltipla Escolha
usando os checks boxes da
unidade
qualquer atributo do bloco de
Unidade de Navegação {EntidadeFonte.nomeAtributo}
objetos selecionados por clicar
sobre a âncora na unidade
O valor de entrada pelo usuário
Unidade de Entrada nomeCampo
em cada campo
Tabela 1: Parâmetros de link providos na saída por unidades de conteúdo.

23

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 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ções
As unidades de operações de WebML, ou então somente operações, são um novo

24

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é-definidas
WebML 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 Objeto
A 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.

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

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.

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

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.

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

28

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

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

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.

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

30

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

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 - WebRatio
WebRatio (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.

Figura 25: Interface da ferramenta WebRatio.

32

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

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

33

3.3 - Implementação
Para 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

Figura 27: Modelo de Dados da aplicação em WebRatio.
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

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

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

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ções
Para 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 Manual
Número de Métodos 62 31
Número de Classes 4 7
Número de Linhas de Código 409 277
Número de Atributos 25 9
Nú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

Engenharia de Software Baseada em Modelos: Um Estudo Sobre WebML

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Engenharia de Software Baseada em Modelos: Um Estudo Sobre WebML

Semelhante a Engenharia de Software Baseada em Modelos: Um Estudo Sobre WebML (20)

Engenharia de Software Baseada em Modelos: Um Estudo Sobre WebML