Object-Oriented Conceptual Modeling of Web
Application Interfaces: the OO-
H
Method
Presentation Abstract Model
Cristina Cachero1?, Jaime G´omez1, and Oscar Pastor2
1
Departamento de Lenguajes y Sistemas Inform´aticos Universidad de Alicante. SPAIN
{ccachero,jgomez}@dlsi.ua.es
2 Departamento de Sistemas Inform´aticos y Computaci´on
Universidad Polit´ecnica de Valencia. SPAIN
Abstract Object-oriented conceptual modeling approaches must be re-considered in order to address the particulars associated with the de-sign of web application interfaces. In this context, the paper introduces the presentation layer of OO-HMethod, an extension of the OO-Method conceptual modeling approach that is devoted to the specification of this kind of interfaces. The OO-HMethod presentation approach is based on the concept of templates. Each page template may fall into a set of categories, which together cover the different presentation perspectives captured in the model. In order to better define the page template struc-ture, a new diagram is introduced: the Abstract Presentation Diagram (APD). The APD does not need to be drawn from scratch: the navigation structure previously defined in the Navigation Access Diagram (NAD) of OO-HMethod provides the information needed to automatically gen-erate a default APD. This skeleton template structure may be refined and enriched by the designer in following steps of the method with the aid of the OO-HMethod Interface Pattern Catalog. As a result, a web application interface is generated in an automated way from this design specification.
1
Introduction
The research effort inverted by the scientific community in hypermedia model-ing approaches specifically devoted to the development of web sites has led to different projects and products. Some of the most relevant examples studied so far are HDM [9], HDM-lite [7], OOHDM [19], RMM [11], ADM [2, 13] or Strudel [6]. However there is still, as far as we know, a gap to be filled: that of specific interaction issues related to web applications, whose functionality and special
?
This article has been written with the sponsorship of the Conselleria de Cultura, Educaci´o i Ci`encia de la Comunitat Valenciana
characteristics haven’t been particularly addressed by any methodology. In this context our research efforts have been focused on the proposal of ’Not Yet Another Method’ for web modeling, but on a set of semantics and notation that allows the development of web-based interfaces for existing OO-Method [15, 16] applications. This proposal, known as OO-HMethod [10], tackles the web application development at both a conceptual and execution level, and ex-tends the classical views (statics and dynamics) of the OO-Method conceptual modeling approach with two new diagrams: (1) the Navigation Access Diagram (NAD) and (2) the Abstract Presentation Diagram (APD). Both the NAD and the APD capture the relevant information by means of a set of patterns defined in the OO-HMethod Pattern Catalog. In addition, OO-HMethod takes advan-tage of the domain information previously captured by OO-Method in order to control certain working conditions of the interface.
This article introduces the OO-HMethod Abstract Presentation Diagram (APD), which allows the refinement of the interface structure and visualization features captured in previous phases of the method. Namely, the patterns cap-tured at the NAD level, together with the objects and attributes characteristics, provide the minimal information needed to automatically generate a default APD. In order to help the designer to further refine this skeleton and maintain a sensible APD structure, the Pattern Catalog contains a broader series of pat-terns, each one with a set of alternative implementations.
The remainder of the article is structured as follows: section 2 provides a brief description of the OO-HMethod Pattern Catalog, which acts as a pattern repository both for the NAD and for the APD. Section 3 gives an overview of the NAD and the concepts captured there, which are the basis for the APD. Section 4 introduces the APD and describes in detail, by means of an example, both the concepts and the template constructs associated with this diagram. It also defines the mapping from elements in the NAD to elements in the APD, as well as some possible ways of refinement. The web interface that is generated from the information captured both in the NAD and in the APD is shown in section 5. Section 6 makes a comparison with related work, and section 7 presents the conclusions and further work.
2
OO-
H
Method Pattern Catalog
The OO-HMethod Pattern Catalog [4] provides an Hypermedia Interface Pat-tern Language. This language can be seen as a partially ordered collection of related patterns that work together in the context of Hypermedia Interfaces [17]. They help to capture the abstract interaction model between the user and the application. We have chosen the pattern style defined in [3] for the specifica-tion of the patterns. This style, largely based on the Alexandrian style [1] is best
suited for abstract patterns with several possible ways of implementation, which are common characteristics of the hypermedia patterns. However, due to the lack of space, in this article we will just informally describe its main characteristics. This catalog is not closed: as our method evolves, and we identify more relevant patterns, we will integrate them as necessary.
One of the main features of our catalog is that it is, as the rest of the model, ’User-Centered’, that is, it provides additional mechanisms to fulfill the user re-quirements. The patterns included in the catalog offer alternative solutions to well-known hypermedia problems, considered from the user point of view. Fur-thermore, its use allows the designer to choose the most suitable among a set of alternative implementations, depending on the target application domain and on the designer’s experience.
The catalog is structured as follows:
1. Information Patterns: they are intended to provide the user with useful extra information to avoid problems such as the ’lost in hyperspace syndrome’, which is captured by means of the Location Pattern.
2. Interaction Patterns: they address the sort of problems typically encountered when the user needs to enter additional information to the system. As an example, we could name the ’Population Filtering Pattern’, that provides alternative mechanisms for the user to filter the set of objects s/he wants to work with.
3. Navigation Patterns: they define the way the user is going to traverse the information. They can be further divided into static, dynamic or command patterns, and are particularly relevant to the hypertext metaphor.
In OO-HMethod, different sets of patterns can be applied to the two dif-ferent diagrams of the modeling process, which are (1) the NAD diagram and (2) the APD diagram. At the NAD level we can apply patterns related to user information selection and navigation behaviour. On the other hand refinement patterns, that is, patterns that provide extra functionality to the interface, are applied at the APD level. Next, we are going to introduce the NAD diagram as a start point from which the default APD will be generated.
For a more general perspective of the approach, a small example is going to be employed all along the paper: a Chat Management System. As a basic explanation (for reasons of brevity) it is assumed that there are several possible chat topics, and each one takes the control over its own messages, which are related to each other by means of a recursive relationship. The chat user can create a new message (a new line of discussion inside a given chat topic) or reply to an existing message. The class diagram and the corresponding NAD of this example is shown in Fig. 1
3
OO-
H
Method Navigation Access Diagram
OO-HMethod associates a different NAD diagram with each agent (user-type). This diagram is based on the following constructs:
1. Navigation Classes (NC): they are domain classes whose attributes and methods have been filtered and enriched in order to better accommodate the specific features of hypertext. This enrichment causes different types of attributes to appear: V-Attributes (attributes that are always visible), R-Attributes (available to the user on demand, by means of any kind of ref-erence) and H-Attributes (low-relevance attributes, hidden to the user except when displaying a detailed view of the system).
2. Navigation Targets (NT): they group together the elements of the model that collaborate in the coverage of a certain user navigation requirement.
Li (showall org) child
Lr (showall) “View Chat List”
Li (showall dest)
Ls “New Chat Line”
Ls “Reply” father ParticipateInChat EP [Index] CHAT nameChat(V) BOOK MESSAGES titleMsg (V) textMsg (V) newMessage replyMessage
Figure1.NAD Diagram of a Chat Manager System
3. Navigation Links (NL): they define the navigation paths through the infor-mation. They have a set of Dynamic Flow Navigation Patterns and Naviga-tion Filters associated, which qualify the navigaNaviga-tion behaviour and provide any extra information needed. We can distinguish among four different link
types: I-Links (Internal Links), which provide navigation paths among ob-jects inside a given NT, T-Links (Traversal Links), which are defined between navigation classes belonging to different NT, R-Links (Requirement Links), which define the entry point to each NT and S-Links, which determine the available services for the user-type associated to that NAD.
4. Collections: they are hierarchical structures defined on navigation classes. They also have a set of Dynamic Flow Navigation Patterns and Navigation Filters associated, which define both the traversal behaviour of each one of the links grouped under the collection and the set of objects on which this collection will apply. In OO-HMethod there are three different types of collections: C-Collections (Classifying Collections), which provide an access structure, hierarchical or not, for grouping related information or services, T-Collections (Transaction T-Collections), which group navigation services that must work together and S-Collections (Selector Collections), which group together objects that conform to the values gathered from the user.
For more information on this diagram, interested readers are referred to [10]. The NAD captures the navigation paths and the services the user can activate when working with the interface. Defaults might be assumed for all the presenta-tion features, and so a web interface might be automatically generated. However, most times the designer will need to modify this default structure in order to im-prove both its appearance and usability. In order to do so, OO-HMethod defines another diagram: the APD, which will be detailed in next section.
4
The Abstract Presentation Diagram
We have adopted a template approach [2, 6, 7, 13] for the specification of not only the visual appearance but also the page structure of the web. Our notion of templates is close to the notion of ’Constructive Templates’ presented in [14]. There are numerous arguments in favor of the use of templates as a complement of design methodologies.[18].
4.1 Template Types
OO-HMethod defines five types of templates, expressed as XML (eXtensible Markup Language) documents[5, 12]. One of the reasons why we have chosen this language is that it provides a standardized framework with which to de-fine our own tags. Giving a suitable set of tags for the definition of each type of template makes them easier to use because it allows to define semantically meaningful names and attributes. In order to define the tags and the structure of the document we have associated a Document Type Definition (DTD)1 with each type of template, whose description we will give in the following section. The template types are, namely:
1
A new proposal, called XML-SCHEMA, is being discussed at [5] as an alternative to the DTD language
1. tStruct: they define the information that has to appear in the abstract page. 2. tStyle: they define features such as physical placement of elements,
typogra-phy or color palette.
3. tForm: they define data required from the user in order to interact with the system.
4. tFunction: they capture client functionality. They are based on the DOM (Document Object Model) specification[5], which aims at giving a platform and language-independent interface to the structure and content of XML and HTML documents. It also seeks to standardize an interface to these objects for navigation and document processing. The functions defined in this kind of template are abstract, and so they must be mapped to a target language and type of document (either JavaScript, which captures HTML-specific components of the DOM, or another) in order to become operative. 5. tWindow: they reflect the possibility of two or more views of the information
being simultaneously available to the user.
For reasons of brevity, we are just showing the tStruct DTD. The DTD spec-ifies the set of rules that conform a valid XML document. It thus defines the tags that can appear in any template belonging to that type, the elements they can contain and its attribute assignments by means of ’Element Type Declarations’. It also contains other information such as processing instructions, a document type declaration, comments etc.
tStruct The DTD that defines a valid TStruct document is: <!ELEMENT collection (object+|link*)>
<!ATTLIST collection
format (ulist|olist) "ulist" style CDATA #IMPLIED
>
<!ELEMENT link (call)*> <!ATTLIST link
name ID #REQUIRED
type (string|button|image|menuitem|automatic) "string" show (here|new) "new"
pointsTo (tForm|tWindow|tFunction|tStyle|tStruct|command) "tStruct" dest CDATA #REQUIRED
>
<!ELEMENT object (attrib+|call*)> <!ATTLIST object type CDATA #REQUIRED
style CDATA #IMPLIED >
<!ELEMENT attrib (call)*> <!ATTLIST attrib name ID #REQUIRED
type (string|date|text|integer|anchor|...) #REQUIRED ordered (yes|no) "no"
>
event (onChange|onClick|onLoad|...) #REQUIRED function CDATA #REQUIRED
>
<!ELEMENT label EMPTY> <!ATTLIST label text CDATA
>
This DTD defines the structure that will be populated in order to define each template construct of the APD. It captures the following set of rules:
1. A tStruct is formed by a set of collections, which must contain at least one object, and any number of links. Collections have a default format associated (unordered list) and could also have a user-defined style (captured in the model inside a tStyle template).
2. A link can have zero or more calls associated. A link is defined by a required name, a type and a set of attributes related to its behaviour (where it is going to show the destination page, which is this destination page and its type). Only links with the ’show’ attribute set to ’new’ (meaning that they point to a new page type) are shown in the diagram. Automatic links imply a trigger mechanism on the client, whose implementation is platform-dependent. 3. An object is formed by one or more attributes and zero or more calls. It
has also both a type (class to which it belongs) and a possible missing style associated.
4. An attribute can have any number of calls associated. It has also a required name and type. Furthermore, they determine the order of the objects in-side a collection. Although we can conceptually distinguish among several types of collections (sets, bags, sequences or single objects), when displaying the information all of them need to have an associated presentation order, whether they conceptually have one or not. This order, if nothing else spec-ified on the model, will be set to ’ascending by the identifying attribute/set of attributes of the object.
5. A call, which can be associated with every element of the page, defines both the trigger condition and the resulting action performed by the interface. 6. Last, but not least, a tStruct page can have any number of labels which
capture the static text appearing in the interface.
The default template structure can be derived from the information captured in the NAD combined with a set of defaults defined for the undefined values. This default generation will be explained in the following section.
4.2 Default APD
OO-HMethod defines a set of rules for the mapping from the different elements contained in the NAD diagram into the equivalent elements in the APD. These are, namely:
1. V-Attributes, I-Links, T-Links and R-Links: they appear as elements of the tStruct page.
2. C-Collections, S-Collections: they are static trees, and are defined by means of a tStruct single abstract page that contains a tree-like structure made up of link elements pointing to other tStruct elements. An S-Collection also might imply a new tForm template to be created, if the filter associated with it involves a set of dynamic user-dependent values.
3. T-Collections, S-Links: they may generate a previous tForm abstract page that contains the parameters to be introduced by the user for all the com-mands involved in the transaction. They must contain a link element that points to a command (considered as either a method or a transaction in OO-Method). If the command returns anything, another tStruct page will be generated with the structure defined by this return value (either an object or a set of objects).
4. R-Attributes: they cause a new tStruct abstract page to appear on the di-agram, and a new link element pointing to it on the original one. The new template will contain all the R-Attributes to be shown plus a meaningful reference to the original object.
5. NAD Navigation Patterns: all indexes, guided tours, indexed guided tours and showall patterns are captured in the APD by means of a set of link elements defined on a single tStruct page.
6. All objects to be shown are enclosed in collections, and there are default user-defined data validations defined for the main attribute types. These val-idations are implemented by means of call elements with ’onChange’ events functions associated with different validation functions depending on this attribute type.
The default APD gives a functional but rather dull interface, which will probably need further refinements in order to become usable in the final appli-cation. It can however serve as a prototype on which to validate that the user requirements have been correctly captured.
4.3 APD Refinement
Perhaps one of the greater refinements (in terms of the APD structure) is that of tWindow. Due to the yet open discussion about whether simultaneous views of the information should be part of the model or not (they provide shorter nav-igation paths but also increase the interface complexity and the user likelihood to get lost), we have decided to provide this feature as a refinement of the model. The other group of refinements consists on the application of a series of APD-related patterns captured in the catalog. These patterns provide the designer with additional hypermedia features and techniques, proven useful to the final user, and so they are a valuable aid to get the final application.
The designer decision about whether to apply or not any of these patterns will influence the final materialization of the APD, both its structure and its content. As an example, in Fig. 2 the application of the ’Location Pattern’ has caused two new abstract pages (head and foot) of type tStruct to appear on the
<<tStruct>> Home Page <<tStruct>> ChatList <<tWindow> ChatView <<tForm>> ReplyMessage <<tStruct>> MessageView <<tStruct>> head <<tStruct>> foot <<tFunctionlib>> mail() back() <<tStruct>> errorPage home index View CL ViewMsg <<automatic>> <<automatic>> Reply Submit <<tStyle>> style
Figure2.Simplified APD of the Chat User Agent
diagram (which is the default implementation OO-HMethod provides), as well as a set of dependency arrows to make the pages where the head and foot must appear aware of their existence. A simplified definition of this pattern (extracted from the OO-HMethod Pattern Catalog) follows:
1. Name: Location Pattern.
2. Also known as: Navigational Context[17].
3. Context: A component gives information about the context location of the actual user-view.
4. Problem: The lack of a user mental schema when navigating through hyper-text pages can cause the ’lost in the hyperspace’ syndrome. To avoid this problem and improve the usability of the interface we need a mechanism to provide location info. Two forces are associated with this problem: - The path used to reach the information components is not known a priori. - The location component should be loosely coupled: the actual view of the system should not depend on details of the location components.
5. Solution: Implement a mechanism in which a change on the view causes a change-propagation that restores the consistency between the view and the location component.
6. Implementation: There are two possibilities: the more immediate one consists on using, directly associated to each group of related pages, a different head and/or foot or different graphical styles. The more general one implies an adaptation of the Observer Pattern[8] to hypermedia environments.
In our example, the inclusion of an Error Pattern has similarly caused a new abstract tStruct page to appear on the schema, as well as a set of dependency arrows to make the pages where an error might occur aware of it. Also, the de-signer has included a tWindow construct. The static pages associated with the EP Collection of the NAD have also generated a tStruct page with an empty label element. This kind of pages (or the addition of a whole entry or exit tunnel to the application) always requires the designer further edition and addition of
contents.
The patterns might cause the appearance and/or modification of any kind of abstract page. As a further example, the application of the Confirmation Pat-tern would cause a confirm function to be included before any change of the type specified is requested to the system. So the content of the function page, where the client-logic is included, would change. All these patterns are part of a pattern repository, have a default abstract materialization defined, and can be applied to the interface at the designer’s will, though s/he will probably apply them following a set of Golden Rules [17].
In OO-HMethod we may also choose whether to make the chosen patterns visible or not. For example, the physical pages and the set of arrows implied by the ’Location Pattern’ don’t provide much meaningful information, so we could decide not to show them on the diagram. The same would happen with the Error Pattern. Using implicit patterns clarify the schema and avoid overwhelming the designer with excessive data. Once all the patterns have been selected, the ma-terialization tasks and techniques2 are in charge of the implementation of these patterns in a given environment. Last, but not least, we can give more than one simultaneous implementation to the same pattern: e.g. the Navigation Observer Pattern can have both the back and the reload mechanism implemented in the same interface. The generated page template for the ’ChatList’ abstract page after applying the refinements is:
<?XML version="1.0"?>
<!DOCTYPE tStruct SYSTEM "tStruct.dtd" encoding="UTF-8"> <tStruct> <label style="" text="List of available chats" />
<link name="error" type="automatic" show="new" pointsTo="tStruct" dest="errorPage"> </link>
<link name="head" type="automatic" show="here" pointsTo="tStruct" dest="head">
</link>
<collection format="ulist" style="schatlist"> <object type="chat">
<attrib name="nameChat" type="STRING"> </attrib>
<call event="onClick" function="validate"> </object>
</collection>
<link name="foot" type="automatic" show="here" pointsTo="tStruct" dest="foot">
</link> </tStruct>
2
5
Implementation of the APD
We might define an Interaction Task as a mechanism that groups, according to the action to be performed, the sets of physical elements that collaborate in the coverage of the action to be performed. These elements might have been captured in any of the models or might be part of any pattern applied to these models. On the other hand, we define an ’Interaction Technique’ as each one of the materialization possibilities an Interaction Task has. They can be associated to a concrete strategy and/or programming environment. The complexity of the mapping among the abstract pages in the APD and the final constructs (first to AIOs and then to CIOs) goes beyond the purpose of this article. In Fig. 3 to 5 the interface generated from the APD of Fig. 2, which corresponds to the Chat Manager example, is shown.
Figure3.Chat Manager entry point Figure4.List of available Chat Lists
Figure5.Adding an opinion to the chat
The process is as follows: first, the generator tool (which encapsulates both the abstract and concrete implementation phase of the model) looks for the page template derived from the Application Entry Point, and its associated static pages (see Fig. 3). Note that every page of the diagram has the same head/foot associated, which provides the interface with a common visual context. However,
the style associated with the title of the home page and the rest of the pages differs, which causes a different letter size to appear. When the user clicks on the ’View Chat List’ link (which is defined as a ’show new’ link), an object population of the ChatList tStruct is performed and the materialized HTML page is shown (see Fig. 4). Again, when the user clicks on the View Message link (also defined as a link with the attribute ’show’ set to ’new’) the materialization of the tWindow abstract page is performed. This template captures rather a different behaviour from that of tStructure: instead of populating the template with objects, it defines the characteristics of the, from now on, two different and simultaneously available views of the system. It defines thus two links whose type is set to ’automatic’ (meaning that they don’t require the user interaction in order to be followed) and that are in charge of the load of the two actual views: the messages kept on the system (again a tStruct abstract page) and a form with the fields required to add a new message to the application. As we have previously stated, this has been a designer refinement over the diagram, as the default implementation would have been ’once-view-at-a-time’, that is, a screen with all the messages would have appeared, and a user-activated link that would make the form appear in place of the messages. The function returns a Boolean value, which makes the final Ok message appear once the operation has been successfully fulfilled (see Fig. 5).
The sample application has been developed using JavaServer Pages and Bean components [20] as the server technology, and HTML as the client technology.
6
Comparison with Related Work
There are many ways in which our work is similar to other template approaches [2, 6, 7, 13]: the template concept used in all the models studied so far implic-itly assumes a page visualization schema and somehow specifies the data it is going to show. Also, the phases of the model are quite similar to the ones de-fined in other models. But there are just as many in which our work is different: OO-HMethod provides a schema that is wholly independent from final imple-mentation details, such as the static/dynamic character[2]. We also consider that the definition of the different aspects of the interface by means of a set of pat-terns greatly simplifies both the construction and modification of the APD, and improves its usability. Also, the OO-HMethod taxonomy of templates facilitates focusing on one aspect of the site at a time, and separating information visual-ization from interaction and presentation features. The use of XML (instead of other languages such as HTML[7]) allows the definition of template languages semantically meaningful, which improves the usability of the method.
OO-HMethod doesn’t consider the integration of different sources of infor-mation. It just covers interface definition and rendering. Furthermore, its OO-approach facilitates its adaptability to dynamically generated web sites in which user interaction is needed, which are just named in passing in the rest of the methods.
7
Conclusions and further work
It is important to note that they are general purpose templates, what means that they require a further transformation to a target environment in order for the interface to become operative. OO-HMethod is an extension of the OO-Method conceptual modeling approach to address the particulars associated with the design of web interfaces. As OO-Method, it is based on the concept of patterns. In fact, even the architecture of the method (separation of logic, interface and data) can be viewed as an application of the Model-View-Controller [3] pattern. In this article we have proposed an interface enrichment process driven by patterns. The Pattern Catalog covers some of the most relevant characteristics that should be present in hypermedia applications, and gives a set of alternative implementations. The selection of one of these implementations depends on a series of usability considerations and Golden Rules[17] that are out of the scope of the model.
We also propose a new diagram, the APD, based on the concept of construc-tive templates, which provides the designer with an intuiconstruc-tive way of refining the default interface structure. The reason is that, in order to guarantee the use of the application, the interface appearance is just as important as the functionality provided by the application. The application of patterns in order to refine the APD helps the user get a good level of usability. Also, the use of patterns allows the interfaces created with OO-HMethod to behave always in the same way, as they take control over all the possible interactions between user and application. Summarizing, the most relevant contributions of this paper are the following: 1. Use of an Interface Pattern Catalog for the capture of the abstract interaction
model.
2. A taxonomy of construct templates, defined in XML, that separates the different aspects involved in the final appearance of the pages.
3. General mapping framework from the NAD to the APD.
At the moment we are applying this method to an e-commerce commercial application. The experience gained in the development of this interface will surely enrich our pattern catalog and refine our template structure. Also, a taxonomy of interaction tasks and techniques (already in the solution space) is being defined.
References
[1] C. Alexander. The timeless Way of Building. Oxford University Press, 1979. [2] P. Atzeni, G. Mecca, and P. Merialdo. Design and Maintenance of Data-Intensive
Web Sites. In Advances in Database Technology - EDTB‘98, pages 436–449, 03 1998.
[3] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. A System of Patterns. Wiley, 1996.
[4] C. Cachero. The OO-HMethod Pattern Catalog. Technical report, Universidad de Alicante, 12 1999.
[5] eXtensible Markup Language (XML). http://www.w3.org/XML/.
[6] F. M. Fern´andez, D. Florescu, J. Kang, A. Levy, and D. Suciu. Catching the Boat with Strudel: Experiences with a Web-Site Management System. InProceedings of ACM SIGMOD International conference on Management of data, pages 414–425, 10 1998.
[7] P. Fraternali and P. Paolini. A Conceptual Model and a Tool Environment for Developing more Scalable, Dynamic, and Customizable Web Applications. In
Advances in Database Technology - EDBT‘98, pages 421–435, 1998.
[8] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. Elements of Reusable Object-Oriented Software. Addison Wesley, 1995.
[9] F. Garzotto and P. Paolini. HDM A Model-Based Approach to Hypertext Appli-cation Design. ACM Transactions on Information Systems (TOIS), 11(1):1–26, 01 1993.
[10] J. G´omez, C. Cachero, and O. Pastor. Extending a Conceptual Modelling Ap-proach to Web Application Design. InCAiSE ’00 (to appear).12thInternational
Conference on Advanced Information Systems. Springer-Verlag. Lecture Notes in Computer Science, 06 2000.
[11] T. Isakowitz, E. A. Stohr, and V. Balasubramanian. RMM: A Methodology for Structured Hypermedia Design. CACM: Communications of the ACM., pages 34–44, 08 1995.
[12] S. McGrath.XML by Example. Building e-commerce Applications. Prentice Hall, 1998.
[13] G. Mecca, P. Merialdo, P. Atzeni, and V. Crescenzi. The ARANEUS Guide to Web-Site Development. Technical report, Universidad de Roma, 03 1999. [14] M. Nanard, J. Nanard, and P. Kahn. Pushing Reuse in Hypermedia Design:
Golden Rules, Design Patterns and Constructive Templates. In HYPERTEXT ‘98. Proceedings of the ninth ACM conference on Hypertext and hypermedia: links, objects, time and space—structure in hypermedia systems, pages 11–20, 1998. [15] O. Pastor, E. Insfr´an, V. Pelechano, J. Romero, and J. Merseguer. OO-METHOD:
An OO Software Production Environment Combining Conventional and Formal Methods. InCAiSE ’97. International Conference on Advanced Information Sys-tems, pages 145–158, 1997.
[16] O. Pastor, V. Pelechano, E. Insfr´an, and J. G´omez. From Object Oriented Con-ceptual Modeling to Automated Programming in Java. InER ’98. International Conference on the Entity Relationship Approach, pages 183–196, 1998.
[17] G. Rossi, D. Schwabe, and A. Garrido. Design Reuse in Hypermedia Applications Development. InProceedings of the eight ACM conference on HYPERTEXT ‘97, pages 57–66, 1997.
[18] D. Schwabe and R. Almeida Pontes. A Method-based Web Application Devel-opment Environment. InPosition Paper, Web Engineering Workshop, WWW8, 1999.
[19] D. Schwabe, G. Rossi, and D. J. Barbosa. Systematic Hypermedia Application Design with OOHDM. In Proceedings of the the seventh ACM conference on HYPERTEXT ‘96, page 166, 1996.
