Transformers-by-example: pushing reuse in conceptual ... - CiteSeerX

Transformers-by-example: pushing reuse in conceptual web application modelling Stephan Lechner

Michael Schrefl

Department of Information Systems University of Linz, Austria

Department of Information Systems University of Linz, Austria

[email protected]

[email protected]

ABSTRACT When defining a scheme of a web application, modelers repeatedly perform modelling tasks like “after having defined an entity type, add a page class for displaying the entity type’s content”. Thereby, a scheme is extended again and again in a similar manner. It would therefore be convenient for modelers to have transformers that, when applied to a scheme, perform such tasks. In this paper, we present the language TBE (transformersby-example) which allows defining transformers for WebML schemes by example, i.e. by giving an example of what is desired instead of specifying operations for achieving the result. The notation of transformers is thereby similar to one with which modelers are familiar. Further, each application of a transformer to a scheme can be parameterized such that the corresponding modelling task will be performed only within a specified part of the scheme. This makes it easy for modelers to define and apply transformers.

Keywords web modelling, web schema transformers, query templates, generative templates, query by example

1.

INTRODUCTION

When using a conceptual modelling language, a web application is specified by a content, a hypertext, and a presentation scheme [4, 5, 8, 16]. However, as these schemes are not independent, we will simply use the term “scheme” for a web application as a whole. As development proceeds, such a scheme is extended or refined step by step through adding scheme elements such as entity types, attributes of entity types, page classes, or links. Thereby, modelers perform repeatedly occurring modelling tasks. For example, a modelling task “Page class for entity type” (short: “PCforEnt”), which could be described as “for an entity type comprising attributes, generate a page class comprising units which present members of that en-

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC ’04, March 14-17, 2004, Nicosia, Cyprus Copyright 2004 ACM 1-58113-812-1/03/04 ...$5.00.

tity type”, is likely to be performed several times. Similarly, page classes often get complemented by entry forms or by units which trigger content management operations like “delete”. For such recurrent modelling tasks, it would be convenient for modelers to have parameterized schema transformers (shortly transformers) that, when applied to a scheme, generate new scheme elements as required. For example, a modeler could apply transformer “PCforEnt” such that for all entity types corresponding page classes are generated all at once. However, a modeler could also apply “PCforEnt” such that only a subset of all entity types is considered. Thereby, flexibly parameterizable transformers push fast development of web applications because modelers can have a bulk of modelling tasks performed by a few (parameterized) transformer applications. A straightforward approach would be to define transformers as a sequence of schema modification operations (e.g. like in OO-H [8]). Such operations would look like “let $e = schema/entitytype” for selecting all entity types or “let $p = new(PageClass); schema.insertPageClass ($p)” for inserting a newly generated page class. This resembles macro languages adopted in many productivity tools like, for example, Microsoft Word or Excel. However, such an approach has the following two disadvantages: (1) Transformers are specified by operations based on a logical representation of schemes, e.g. a representation in XML. However, in a conceptual web modelling language, modelers usually edit schemes graphically and do not specify operations at the level of a logical representation. Further, specifying quite many schema modification operations, as often required for defining a transformer, can be difficult and error prone. This can prevent average modelers from defining their own transformers. (2) As transformers’ semantics is hidden in code, extra documentation is required to describe how they behave and how they are to be applied. Otherwise, average modelers would hesitate to use existing transformers. In this paper, we present the language TBE (transformersby-example) which extends WebML [4], a language for conceptual web application modelling, to a language for defining transformers for WebML schemes. WebML has been chosen because it is available as a commercial tool, WebRatio [1]. However, we could have supported other languages like OOH [7] or Araneus [11] as well. Different from the above mentioned straightforward approaches, TBE basically follows the principle of the relational data manipulation language QBE [18] (query-by-

example), where a user gives an example of what is desired instead of specifying operations for achieving the result. In TBE, these examples (i.e. WebML schemes in graphical representation) are referred to as templates from which schema modification operations are derived. Thereby, transformer’s semantics is defined declaratively by the graphical arrangement of scheme elements. This targets average modelers who are familiar with defining schemes but not with defining schema modification operations. Only a few expressions, like, for example, expression strcat(ENTN , “Page 00 ) concatenating an entity type’s name ENTN and literal “Page”, must be annotated. Use cases for transformers are manyfold. They facilitate everyday modelling tasks like, for example, defining page classes for displaying the members of entity types; this is the running example. (ii) complementing page classes by entry forms; this is shown in Section 6. (iii) providing content management operations like “delete”; this is shown in [9]. Transformers also support complex modelling tasks like “on every page class, inform users about their current position in the hypertext”. For this purpose, a transformer can be defined that (i) augments every outgoing link by parameters carrying position information and (ii) augments every page class such that the provided position information is displayed adequately. Thereby, a single transformer application can augment a large number of page classes and links. Performing this task manually, in contrast, would be cumbersome. TBE builds on previous work [10] where transformers by example have been introduced. Therein, a single transformer application stood for performing a modelling task once, e.g. for one particular entity type. Yet considering a set of entity types required a set of separate applications. In TBE, a transformer is defined as a combination of a generative template and a query template. This is comparable to a combination of SQL insert and select statements of the form INSERT INTO ... (SELECT * FROM ...), respectively. Thereby, TBE supports transformers which are capable of performing a bulk of modelling tasks with a single application. A query template is a query expressed in a visual byexample query language tailored to WebML schemes. Similarly, a generative template is a parameterized example of WebML scheme elements to be generated. When applying a transformer to a scheme, the query template retrieves tuples of scheme elements therefrom. Then, the generative template is iteratively instantiated for each of the query template’s result tuples. The paper is organized as follows: Section 2 introduces the running example. Section 3 defines a logical representation of WebML schemes which is the basis for defining semantics of query and generative templates in Section 4. Section 5 defines transformers and their parameterized applications. Section 6 describes sub-queries and sub-transformers. Section 7 discusses related work and Section 8 concludes the paper.

2.

MOTIVATING EXAMPLE

In this section, we describe a WebML scheme modelling a conference’s web site and motivate the use of a transformer. Both, scheme and transformer, will serve as running example throughout the paper.

2.1

A WebML scheme

The content scheme depicted in Fig. 1 models the content of a conference’s web site. Please ignore the gray box at the right hand side for the moment, it will be explained at the end of this section. (e1) Paper

(e3) Conf

(a1) title (a2) abstract

(a5) title

T:PCfromEnt

≠

√ENTN

* submission (e2) Author

PGN

1 (a3) name contact

(a4) email

Figure 1: Conference example: WebML content scheme (left) and transformer application (right) Entity type Conf describes data to be presented at the conference’s main page and is intended to contain only one tuple. In our simple example, this data is the conference’s title represented by attribute title. Entity type Author with attributes name and email describes information about authors, while entity type Paper with attributes title and abstract describes information about submitted papers. Relationship roles submission and contact express that an author may have submitted many papers and that a paper has exactly one contact, respectively. The values in parentheses, e.g. (e1), are ID’s of scheme elements and are generated by WebML. Though they are usually shown in separate forms, we have included them directly in the graphical representation for reasons of conciseness. (pg1) PaperPage

All papers

(iu1) PaperIndex

(du1) Detail

(e1)

(e1)

(pg3) ConfPage (du3) Detail

(pg2) AuthorPage (e3) All authors

(iu2) AuthorIndex

(du2) Detail

(e2)

(e2)

Figure 2: Conference example: WebML hypertext scheme Fig. 2 depicts a WebML hypertext scheme which is based on the content scheme explained above. Page class ConfPage defines the conference’s main page. It contains a data unit Detail that has entity type Conf, i.e. e3, as content source. Thus, ConfPage presents the sole entity of entity type Conf. Page class AuthorPage defines pages representing authors and contains index unit AuthorIndex that is linked to data unit Detail. Both units present authors as they have entity type Author, i.e. e2, as content source. Index unit AuthorIndex is defined to present a list of authors and al-

lows for selecting an author therefrom at runtime. Such a selected author object will be passed along the link to data unit Detail which presents the selected author’s details. When traversing link “All authors” from main page ConfPage, a default author page is presented. It contains a list of all the authors stored in the database; further, the details of the first author in this list are shown until the user selects another author. Page class PaperPage is structured analogously. To keep the example simple, we have omitted links from, for example, an author’s details to a list of her submitted papers. Further, due to limited space, our example does not comprise a presentation scheme specifying the arrangement of page content and the styles to use. However, the example could be easily extended in that direction.

2.2

Universe members

Relations

Universe members

Relations

e3: E a5: A Conf: N title: N

name name defAt

pg3: P du3: D e3: E ConfPage: N Detail: N

name name defAt source

Using a transformer

Page classes AuthorPage and PaperPage are defined based on entity types Author and Paper, respectively, in a similar manner. This suggests to define a transformer that, when applied to the content scheme, generates these page classes in that manner. Fig. 6 shows the definition of transformer “PCforEnt” which comprises a query template (left part) and a generative template (right part). The √ templates look, apart from annotations like the symbols and ↓ similar to schemes: The query template, which defines selection of entity types, looks like an entity type. Also, the generative template, which defines construction of page classes with index and data units, looks like, for example, page class PaperPage. The right hand side of Fig. 1 shows an application of transformer “PCforEnt”, whereby transformer variable “ENTN” represents entity types to be considered while variable “PGN” stands for page classes to be generated. The application is parameterized such that corresponding page classes are generated for every entity type except Conf; this entity type is not considered as the corresponding page class ConfPage shall not comprise an index unit. Thus, most of the scheme depicted in Fig. 2 is generated by the transformer. Only page class ConfPage and the links between the page classes are added manually.

3.

Note that we have not shown universes and relations for all WebML scheme elements. For example, links between page classes and relations between entity types have been neglected but can be defined in a similar manner. Each scheme element e is member of exactly one universe U ∈ Ub and is denoted as e : U . A tuple of a relation b and, R(U1 , . . . , Un ) is denoted as Rhe1 , . . . , en i, with R ∈ R for i = 1 . . . n, ei ∈ Ui .

LOGICAL REPRESENTATION

In this section, a logical representation of WebML schemes is defined. This representation will be used in the next sections where the semantics of transformers is defined. The logical representation of a WebML scheme is given by b Each universe a set of universes Ub and a set of relations R. U ∈ Ub represents a sort U of scheme elements. Each relation b and, for i = 1 . . . n, Ui ∈ U, b R(U1 , . . . , Un ), with R ∈ R represents connections between scheme elements of sorts Ui . Example 1. Entity types, attributes, page classes, and data units are represented by universes E, A, P , and D, respectively. Each scheme element has a name drawn from universe N attached. This is expressed by relation name((E ∪ A ∪ P ∪ D) × N ). Each attribute belongs to an entity type, and each data unit belongs to a page class. This is expressed by relation defAt((A×E)∪(D ×P )). Each data unit has an entity type as source for its content. This is captured by relation source(D × E). The sets of universes and relations are thus given as Ub = {E, A, P, D, N } and b = {name, defAt, source}, respectively. R

Figure 3: Logical representations of parts of the schemes depicted in Fig. 1 and Fig. 2, resp.

Example 2. The left hand side of Fig. 3 shows the logical representation of entity type Conf shown in Fig. 1. Scheme elements e3 : E and Conf : N represent entity type e3 and its name Conf, respectively. Tuple namehe3, Conf i attaches the name to the entity type. Similarly, the right hand side of Fig. 3 shows the logical representation of page class ConfPage depicted in Fig. 2.

4. QUERY TEMPLATES AND GENERATIVE TEMPLATES In this section, we introduce query templates and generative templates. Generally, these templates graphically correspond to schemes but have variables in place of scheme elements. For both templates, we start with explaining the formal semantics before we show how the graphical representation maps to the formal one.

4.1

Query templates

A query template expresses a query that, when applied to a WebML scheme, retrieves scheme elements therefrom. Formally, a query template is denoted as Q(Vr , Vnr , dom, C), where Vr and Vnr are disjoint sets of result and non-result variables, respectively, dom : (Vr ∪ Vnr ) → Ub is a total function associating to each variable v ∈ V = (Vr ∪ Vnr ) a universe U ∈ Ub serving as domain for v, and C is a set of constraints over variables in V . The domain U ∈ Ub of a variable v ∈ V is denoted by v : U . Each constraint c ∈ C is either simple or complex. A simple constraint has one of the following two forms: 1. a comparison constraint has the form v1 op (v2 | lit), whereby | is a BNF-symbol denoting alternatives, v1 , v2 ∈ V , op ∈ {=, 6=}, and lit being a literal value. 2. a membership constraint has the form hv1 , . . . , vn i ∈ R, b and, for i = 1 . . . n, vi ∈ V . with R ∈ R Complex constraints can be built from other constraints (simple or complex) using the logical connectives (¬, ∨, ∧) in the usual manner.

The meaning of queries is defined in terms of domain relational calculus (DRC) which is, for example, explained in [13]. A query Q(Vr , Vnr , dom, C) is interpreted as a DRCexpression of the form {hvr1 , . . . , vrx i ∈ dom(vr1 ) × . . . × dom(vrx ) | ∃vnr1 ∈ dom(vnr1 ), . . . , ∃vnry ∈ dom(vnry ) c1 ∧ . . . ∧ cz }. Thereby, vr1 , . . . , vrx and vnr1 , . . . , vnry represent the sets of result and non-result variables Vr and Vnr , respectively, and c1 . . . cz represent the set C of constraints. Q:EntWithAttr (√ENT) √ENTN (ATT)

{ ENT, ENTN ∈ E×N | ∃ ATT ∈ A ENT, ENTN ∈ name ∧ ATT, ENT ∈ defAt ∧ (ENT=e1 ∨ ENT=e2) }








ENT=e1 OR ENT=e2

Figure 4: query template “Q:EntWithAttr”; graphical representation (left) and logical representation (right)

Example 3. The right part of Fig. 4 shows query template “Q:EntWithAttr” which selects the IDs and names of entity types. This is expressed by tuples of result variables hENT , ENTN i ∈ E × N as shown in the first line. Variable ATT shown in the second line is a non-result variable with domain A and is existentially quantified. Membership constraint hENT , ENTN i ∈ name states that only those pairs of IDs and names are to be selected which both belong to the same entity type. Further, only entity types which comprise attributes are considered. This is expressed by membership constraint hATT , ENT i ∈ defAt which only holds if there exists some attribute ATT defined at entity type ENT . Constraint ENT=e1 OR ENT=e2 expresses that only entity types with ID e1 or e2 are to be selected. The result of applying this query template to the scheme depicted in Fig. 1 is a relation ResQ (ENT , ENTN ) with tuples he1 , Paper i and he2 , Author i. The graphical notation of a query template corresponds to that of a scheme yet variables are in place of scheme elements. Thereby, the graphical arrangement of variables implicitly expresses the variables’ domain as well as membership constraints which restrain bindings of these variables. Result √ variables are denoted by preceding the variable with a tick . All other variables are non-result variables. A comparison constraint is notated explicitly in textual form, although a simple comparison constraint can also be notated graphically by a gray line labelled = or 6=. Example 4. The left part of Fig. 4 shows the graphical representation of the query template depicted in the right part. Variable ENT is a result variable as it is preceded by √ symbol and is of domain E as it is in place of an entity type’s ID. Similarly, variable ENTN denotes a result variable of domain N , while variable ATT denotes a non-result variable of domain A. The graphical arrangement of variables ENT and ENTN also defines a membership constraint hENT , ENTN i ∈ name. This is analogous to schemes where this arrangement would have denoted a tuple hENT , ENTN i of relation name, i.e. namehENT , ENTN i. Similarly, the graphical arrangement of variables ENT and ATT defines membership constraint hATT , ENT i ∈ defAt. Complex constraint ENT=e1 OR ENT=e2 is notated textually.

Note that, as a limitation of the graphical representation as explained so far, membership constraints can not be composed to complex constraints using logical connectives ∨ and ¬. This is because membership constraints are expressed implicitly such that there is no handle for explicitly applying logical connectives other than default connective ∧. However, this problem will be solved by means of sub-queries as explained in Section 6.

4.2

Generative templates

A generative template defines generation of new scheme elements and new relations within WebML schemes to which the template is applied. Formally, a generative template G(P, Vg , Rg ) is given by a set P of input parameters, a set Vg of new element variables, and a set Rg of constructors for relations between elements of P and Vg as follows: 1. Each parameter p ∈ P represents a given scheme eleb This is denoted as p : U . ment of a universe U ∈ U. 2. Each new element variable vg ∈ Vg represents a scheme b to be generated and element (of a universe U ∈ U) has, for that purpose, a construction expression exp attached. This is denoted as vg : U = exp. A construction expression has one of the following forms: (a) “=new U ” assigns a new ID out of universe U , (b) “=lit” assigns a literal value, and (c) “=func(x1 , . . . , xn )” assigns the result of a function call with, for i = 1 . . . n, xi ∈ (P ∪ Vg ∪ lit). One such function provided is, for example, strcat(N , N ) : N for concatenating two names. 3. Each relation constructor rg ∈ Rg specifies the creation of a new relation between members of universes. b and, for It has the form Rhx1 , . . . , xn i with R ∈ R i = 1 . . . n, xi ∈ (P ∪ Vg ).

(PG) PGN (DU) (↓ENT)

DUN

P Vg = exp ENT : E PG= new P ENTN : N DU= new D DUN= Detail PGN= strcat ( ENTN,Page)

Rg name PG, PGN name DU, DUN defAt DU, PG source DU, ENT











DUN = “Detail” PGN = strcat (↓ENTN, “Page”)

Figure 5: generative template ”G:PCforEnt”; graphical representation (left), logical representation (right)

Example 5. The right part of Fig. 5 shows generative template “G:PCforEnt”. Parameters, new element variables with construction expressions, and relation constructors are depicted in separate columns. A generative template G is instantiated within a scheme S by binding each parameter of G to an equally sorted scheme element of S. Such an instantiation is denoted as G[S, B ], whereby B is a set of parameter bindings. A binding of a parameter p to a scheme element e is denoted as “p = e”.

When an instantiation G[S, B ] is processed, new scheme elements and new relations are generated within S as follows: (1) for each new element variable vg : U , its attached construction expression exp is evaluated and the result becomes a member of universe U ; (2) for each relation constructor Rhx1 , . . . , xn i, a relation of sort R is established between the scheme elements represented by parameters/variables x1 , . . . , xn . Example 6. Reconsider generative template “G:PCforEnt” which takes two parameters, i.e. an entity type and a name represented by variables ENT and ENTN , respectively. It generates a page class and a data unit as denoted by new element variables PG and DU , respectively. The construction expressions attached, e.g. new P , generate new IDs. The name PGN of the generated page class PG is defined by string concatenation, i.e. by calling function strcat(ENTN , “P age00 ). The name DUN of the generated data unit DU will be “Detail”. Relation constructor defAthDU , PGi expresses that data unit DU will belong to page class PG. The other relation constructors should be self explanatory. Let G be generative template “G:PCforEnt” (Fig. 5) and let S be the content scheme of our running example (Fig. 1). Then, an instantiation G[S, {ENT = e3 , ENTN = Conf }] yields a page class ConfPage which is depicted graphically within Fig. 2 and logically in the right part of Fig. 3. The results of the construction expressions (e.g. ID pg3 : P generated from PG = new P , and ConfPage : N generated from PGN : N = strcat(ENTN , “P age00 )) are now members of the corresponding universes. Also, tuples generated by the relation constructors have been inserted into the respective relations, e.g. tuple defAt hdu3 , pg3 i generated from defAthDU , PGi. Analogous to query templates, the graphical arrangement of variables in generative templates implicitly expresses the variables’ domain as well as relation constructors. Variables preceded by symbol ↓ denote parameters. All other variables are new element variables. Construction expressions of form “v = lit” or “v = func(x1 , . . . , xn )” are explicitly annotated in textual form. For every new element variable v : U without such an annotation, a construction expression of form “= new U ” is implicitly defined. Example 7. The left part of Fig. 5 shows the graphical representation of generative template “G:PCforEnt” depicted in the right part. It should be self explanatory when comparing the graphical representation to the corresponding logical one.

5.

TRANSFORMERS AND THEIR APPLICATION

This section defines transformers and their parameterized applications within schemes.

5.1

Transformer definition

A transformer is a proper combination of a query template Q and a construction template G and is denoted as T (Q, G). A combination of Q and G is proper, if (1) for each result variable of Q there exists an equally named and equally sorted parameter of G, and (2) all parameters of G are provided by Q.

Such a combination expresses that the generative template will be instantiated separately for each tuple of the query template’s result. Thus, when applying a transformer T (Q, G) to a scheme, relation Rel Q of query template Q is evaluated first. Then, generative template G is iteratively instantiated for each tuple t of Rel Q , each time having parameters of G bound to the corresponding attribute values of current tuple t.

T:PCforEnt (√ENT) √ENTN (ATT)

(PG)

PGN

(IU) IUN

(DU) “Detail“

(↓ENT)

(↓ENT)

PGN = strcat (↓ENTN, “Page”) IUN = strcat (↓ENTN, “Index”)

Figure 6: Transformer “T:PCforEnt” A transformer is depicted by a rectangular box which comprises a query template and a generative template separated by a dashed line. The transformer’s name is placed in the upper part of the box. Example 8. Fig. 6 shows transformer “T:PCforEnt” with a query template (Q) in the left part and a generative template (G) in the √ right part. It√properly combines Q and G as result variables ENT and ENTN of Q properly match parameters ↓ ENT and ↓ ENTN of G, respectively. The meaning of the transformer should be self-explanatory as similar query and generative templates have already been explained.

5.2

Transformer application

Applications of transformers within schemes may be parameterized by application specific constraints and construction expressions. This allows for flexible use of predefined transformers and is also the basis for sub-queries and cascading transformer applications described in the next section. An application of a transformer T (Q, G) to a scheme S is denoted as T [S, ASC , ASE ], whereby ASC is a set of application specific comparison constraints and ASE is a set of application specific construction expressions. Both sets may be empty. The meaning of members of ASC and ASE is similar to that of comparison constraints and construction expressions defined in the previous section, respectively. However, application specific constraints and construction expressions are not defined statically in the transformer but take effect therein at the time the transformer is applied. Thereby, members of ASC further restrain variables of the query template while members of ASE override construction expressions of the generative template. Example 9. Let S be the content scheme depicted in Fig. 1 and let T be transformer “T:PCforEnt” defined in Fig. 6. Then, T [S, {ENTN 6= “Conf 00 }, {}] denotes the transformer application which has been explained in Section 2 and which generates page classes for all entity types except Conf. Thus, page classes PaperPage and AuthorPage are generated for entity types Paper and Author, respectively.

(e3) Conf

(e1) Paper

(a5) title

(a1) title (a2) abstract

=

(pg3) ConfPage

T:PCfromEnt √ENTN (PG) PGN

(du3) Detail

6.

(e3) (pg3) ConfPage (du3) Detail

Similarly, the right hand side of Fig. 1 shows the graphical representation of the transformer application serving as running example, i.e. the application T [S, {ENTN 6= “Conf 00 }, {}] as explained in example 9. Constraint ENTN 6= “Conf 00 is expressed graphically by the gray line labelled “6=”.

(iu1) PaperIndex

(du1) Detail

(e1)

(e1)

SUB-QUERY TEMPLATES AND CASCADING TRANSFORMERS

This section introduces applications of sub-query templates and cascading transformers. We start with explaining sub-query templates.

6.1

(e3)

Figure 7: Parameterized application of transformer “T:PCforEnt” (upper part) and the resulting scheme (lower part)

Example 10. Suppose that page class ConfPage shall be extended such that a list of papers and their details are presented at the conference’s main page. This can be expressed by applying transformer “T:PCforEnt” as T [S, {ENTN = “Paper 00 }, {PG = pg3 , PGN = ConfPage}]. Application specific constraint ENTN = “Paper 00 states that only entity type Paper shall be considered. Further, construction expressions for the new element variables PG and PGN of the transformer’s generative template are overridden by application specific construction expressions PG = pg3 and PGN = ConfPage, respectively. Thereby, the index and the data unit will be generated within existing page class pg3 , i.e. ConfPage, instead of generating a new page class. The result of this application is shown in the lower part of Fig. 7. An application of a transformer is depicted by a rectangular box with a gray border which is placed within the scheme to which the transformer is applied. The transformer itself is specified by its name placed in a gray-shaded area in the upper right corner of the box. Application specific constraints and construction expressions, when specified textually, are notated in this area, too. Further, application specific constraints can be expressed graphically similar to comparison constraints in query templates, i.e. by gray lines labelled “=” or “6=”. Also, application specific construction expressions of form vg = lit can be specified by a gray line from the variable to a literal value lit. For this purpose, the transformer’s definition or parts thereof can be repeated schematically within the box in order to have handles for attaching such gray lines. Example 11. The box shown in the upper right part of Fig. 7 is the graphical representation of the transformer application explained in example 10 above. Parts of the transformer’s definition have been repeated in the box, while many details like many variables and construction expressions have been neglected. Application specific constraint ENTN = “Paper 00 is expressed by a gray line labelled “=”. Application specific construction expressions are notated as gray lines, too. For example, expression PG = pg3 is notated as a gray line from variable PG to literal value pg3 .

Sub-queries

Query templates may apply other query templates as EXISTS/NOT EXISTS sub-queries, whereby sub-queries can be arbitrary nested. The meaning is straightforward: a query template which is applied within a main query template Qm as an EXISTS sub-query denotes a constraint of Qm . This constraint is fulfilled only if the sub-query returns at least one tuple. Analogously, a NOT EXISTS sub-query constraint is fulfilled only if the sub-query returns no tuples. The variables of the main query can be used for constraining the sub-query. This is similar to correlated sub-queries in SQL. However, in TBE, correlation is expressed by constraints which are passed to the sub-query. This is analogous to application specific constraints which are passed to the query template of a transformer. Thereby, the concept of parameterized transformer applications explained in the previous section is uniformly used also for sub-queries. The application of an EXISTS or NOT EXISTS sub-query Qs within a main query Qm with a set of constraints ASC sub passed to Qs is denoted as ∃Qs [ASC sub ] or 6 ∃ Qs [ASC sub ], respectively. Thereby, constraints in ASC sub can restrict variables of Qs based on variables of Qm . Example 12. Suppose that we want to define a query template “Q:NotReachable” that selects isolated page classes, i.e. those page classes which are not reachable from any other page class via a non-contextual link. The query is expressed in two steps: We first define a query template “Q:Reachable” as shown within the gray bordered box in Fig. 8. It returns those page classes DP , where for some page class SP at least one link L from SP to DP exists. Then, query template “Q:NotReachable” is defined as follows: A result variable P ranges over all page classes. For each binding of P , query template “Q:Reachable” is applied as 6 ∃ Q : Reachable[DP = P ]. Thereby, the sub-query checks whether the current page class represented by P is reachable from some other page class. If this is the case, then P is not in the result.

∃ Q:Reachable

Q:NotReachable (√P)

=

(√DP)

L

(SP)

Figure 8: Query template “Q:NotReachable” Graphically, a sub-query template is notated in a main query template within a rectangular box with gray border

and has a name which is specified in the upper left corner of this box. Symbol ∃ or 6 ∃ preceding the name expresses whether the sub-query is applied as an EXISTS or as a NOT EXISTS sub-query. Example 13. Fig. 8 shows the graphical representation of query template “Q:NotReachable”. Query template “Q:Reachable”, which has already been explained in example 12 above, is applied as 6 ∃ Q : Reachable[DP = P ]. Thereby, application specific constraint DP = P is expressed by a gray line labelled “=” between variables DP and P .

as follows: When applying Tm to a scheme S, then Tm ’s query template is is evaluated first yielding relation ResQm . Then, generative template Gm is iteratively instantiated for each tuple of ResQm as usual. However, with each tuple, an application of transformer Tc to scheme S, i.e. Tc [S, ASC , ASE ], is generated, too. These generated applications are processed afterwards as if modelers had specified them manually. T:FLDs4EU

Several sub-queries can be combined to a complex constraint using the logical connectives ¬, ∨, ∧ in their usual manner, whereby each participating sub-query is referred to by its name. Thereby, we can now express complex constraints formed of membership constraints by using the logical connectives ∨ and ¬ besides default connective ∧ (c.f. Section 4.1). This is because all these connectives can be used for combining sub-queries which in turn may comprise membership constraints. Example 14. Suppose that we want to define query template “Q:Reachable” such that it checks whether a page class is reachable either (a) via a non-contextual link or (b) via a contextual link, i.e. via a link between embedded units. This can be expressed as follows: First, two sub-query constraints ∃Q : RV iaN onContextualL and ∃Q : RV iaContextualL which check conditions (a) and (b), respectively, are defined. Then, a complex constraint “ ∃Q : RV iaN onContextualL ∨ ∃Q : RV iaContextualL” is notated textually in query template “Q:Reachable”.

6.2

Cascading transformer applications

Transformers should be capable of performing separate or subsequent modelling tasks within a single application. This is solved in that transformers can apply other transformers in the same manner as transformers are applied within schemes. This fits well in the concept of parameterized applications of transformers and facilitates their reuse. Example 15. Suppose that we want to define a transformer that (1) generates a page class with an entry unit for each entity type, and (2) subsequently generates an entry field for each of the entity type’s attributes. This can be solved as follows: First, a transformer that selects entity types and generates a page class and an entry unit is defined. This transformer additionally applies a second transformer that selects attributes of entity types and generates corresponding entry fields within the entry unit just created. Cascading transformer applications are expressed by generative templates which apply other transformers. Let Tm (Qm , Gm ) and Tc (Qc , Gc ) be two transformers; then, a cascading application of transformer Tc within generative template Gm of transformer Tm is denoted as Tc [ASC , ASE ]. Thereby, ASC and ASE are possibly empty sets of constraints and construction expressions, respectively, which parameterize the application of transformer Tc . These constraints and expressions may be specified based on result variables of Qm , since these are parameters in Gm , and based on new element variables of Gm , since they will be evaluated before applying any cascading transformer. The meaning of a cascading transformer application Tc [ASC , ASE ] within a transformer Tm (Qm , Gm ) is defined

(E) (ATT) √ATTN




T:PC+EUforENT (√ENT) √ENTN = (PG)

(EU)

(FLD) ↓ATTN

T:FLDs4EU

PGN

(E)




(ENTRU) (EU)

PGN = strcat ( ↓ENTN, “Page”)

(a)

FLD

(b)

Figure 9: (a) transformer “T:FLDs4EU”; (b) transformer “T:PC+EUforENT” 9(b) shows transformer Example 16. Fig. “T:PC+EUforENT” (short for “Pageclass and entry unit for entity type”) which solves the problem described in example 15 above. The query template selects tuples of entity types ENT and their names ENTN . For each such tuple, the generative template first generates a page class named after ENTN and an entry unit ENTRU without any entry fields. These entry fields are generated subsequently by applying another transformer “T:FLDs4EU” (short for “Fields for entry unit”). Fig. 9(a) shows the definition of transformer “T:FLDs4EU”. Its query template selects attribute names of entity types E. For each selected attribute ATTN , the generative template creates an entry unit EU and an entry field FLD named after ATTN . Transformer “T:PC+EUforENT” applies transformer “T:FLDs4EU” with application specific constraint E = ENT and construction expression EU = ENTRU such that “FLDs4EU” (1) selects only attributes of entity type ENT currently under consideration, and (2) generates all entry fields within the same entry form ENTRU .

7.

RELATED WORK

Our work compares to other approaches out of the fields of web schema transformers, of by-example query and construction languages, and of web design patterns/frameworks. Transformation rules described in [8] define web schema transformers as a sequence of schema modification operations like “addAPDPage (p)” for creating a new page class. A library of predefined transformers is provided, although a way for parameterizing them is not discussed. In contrast, in our approach transformers are defined by templates from which schema modification operations are derived and which provide for flexible parametrization.

Query by example (QBE) [18] is a data manipulation language for the relational model and allows to specify queries by giving an example of the desired result. Thus, the motivation is similar to that of TBE. However, QBE is form-based while TBE is a visual language tailored to the notation of WebML schemes. Further, QBE offers data manipulation operations “update” and “delete” while TBE does not yet provide these operations. This is because we focused on modelling tasks where scheme elements usually are added but not changed or discarded. However, extending TBE in that direction is straightforward. Visual query systems (VQS, surveyed in [3]) are graphical interfaces to databases. Their design is usually tailored to the representation of the data to be queried. For example, the elements of GQL [12] are nodes and labelled edges as GQL is a graphical query language for the functional data model [17]. Analogously, queries and constructions in XMLGL [6] are tailored to XML. Thus, languages like GQL or XML-GL can not be used for specifying a by-example query for WebML schemes. The concepts presented therein, however, have influenced our work. Hypertext Patterns (e.g. [2, 14]) describe recurrent problems in hypertext design and abstract solutions. This is in contrast to transformers that provide solutions in terms of a particular model, e.g. WebML. Thus, transformers can drive instantiation of hypertext design patterns and may thereby help to enforce a uniform style of design in an organization. Web Design Frameworks [15] are meta-level descriptions of groups of similar web applications, e.g. a group of applications providing a shopping basket. For a particular group, a meta-scheme defines which concepts must be instantiated and which constraints must hold in a web application scheme in order to belong to that group. TBE is not meant as a meta-modelling language. However, as TBE is a language for querying and manipulating schemes, transformers and query templates can also be employed for expressing schemes and constraints over them at a meta-level.

8.

CONCLUSION

We have presented TBE as a powerful visual language for defining schema transformers by example, i.e. by using a notation similar to that of schemes. These transformers drive the process of conceptual web application modelling in that they assist modelers in performing modelling tasks occurring repeatedly. The paper has focused on transformers for supporting modelling tasks. Beside that, transformers could also be beneficially used for generating hypertext views that adapt a base web application for particular front end devices or for generating personalized views for particular user groups, while TBE ’s query templates could also be employed for checking violations of design guidelines. As TBE is a visual language, expressing very complex transformers in TBE can be impractical. For this purpose, macro languages are more appropriate, even if defining transformers then requires to operate on a logical representation of schemes. We plan therefore to homogenously integrate a macro language into TBE. We are evaluating our approach within courses concerning web engineering. However, an evaluation in the realm of real projects is yet outstanding. This is because defining and using transformers effectively requires tool support. Such a prototype for TBE is currently under development.

9.

ACKNOWLEDGEMENTS

We would like to thank the anonymous referees for their helpful comments and also G¨ unter Preuner and Mathias Goller for proof reading.

10.

REFERENCES

[1] WebRatio Site Development Studio, Vers. 3.2.10. http://www.webratio.com, 2003. [2] M. Bernstein. Patterns of hypertext. In Proceedings of the 9th ACM conference on Hypertext and hypermedia, pages 21–29. ACM Press, 1998. [3] T. Catarci, M.F. Costabile, S. Levialdi, and C. Batini. Visual query systems for databases: A survey. Journal of Visual Languages and Computing, 8(2), 1997. [4] S. Ceri, P. Fraternali, and A. Bongio. Web Modeling Language (WebML): a modeling language for designing Web sites. Computer Networks (Amsterdam, Netherlands), 33(1–6):137–157, 2000. [5] Jim Conallen. Modeling Web application architectures with UML. Communications of the ACM, 42(10):63–70, 1999. [6] S. Ceri et al. XML-GL: a graphical language for querying and restructuring XML documents. Computer Networks (Amsterdam, Netherlands), 31(11–16):1171–1187, May 1999. omez, C. Cachero, and O. Pastor. Extending a [7] J. G´ conceptual modelling approach to web application design. In CAiSE’00, pages 79–93, 2000. [8] J. G´ omez, C. Cachero, and O. Pastor. Conceptual modeling of device-independent Web applications. IEEE MultiMedia, 8(2):26–39, April 2001. [9] S. Lechner and M. Schrefl. By-example schema transformers for supporting the process of conceptual web application modelling. Technical Report TR0203, University of Linz, Austria, 2003. [10] S. Lechner and M. Schrefl. Defining web schema transformers by example. In Proceedings of DEXA’03. Springer, 2003. [11] G. Mecca, P. Atzeni, A. Masci, G. Sindoni, and P. Merialdo. The araneus web-based management system. In ACM SIGMOD’98, pages 544–546, 1998. [12] A. Papantonakis and P. J. H. King. Gql, a declarative graphical query language based on the functional data model. In Proceedings of the workshop on Advanced visual interfaces, pages 113–122. ACM Press, 1994. [13] Raghu Ramakrishnan and Johannes Gehrke. Database management systems. McGraw-Hill, 2000. [14] G. Rossi, F. Lyardet, and D. Schwabe. Developing hypermedia applications with methods and patterns. ACM Computing Surveys (CSUR), 31(4es):8, 1999. [15] D. Schwabe, G. Rossi, L. Esmeraldo, and F. Lyardet. Web design frameworks: An approach to improve reuse in Web applications. LNCS, 2016:335–346, 2001. [16] Daniel Schwabe and Gustavo Rossi. An object oriented approach to web-based application design. Theory and Practice of Object Systems, 4(4), 1998. [17] David W. Shipman. The functional data model and the data language DAPLEX. ACM Transactions on Database Systems (TODS), 6(1):140–173, 1981. [18] M. M. Zloof. Query-by-example: A database language. IBM System Journal, 16(4):324–343, 1977.