1 Introduction
Demand for hypermedia systems, and in particular Web applications, has risen quickly in different areas over a short period of time. This rush has led most developers to skip the conceptual design and go directly to the implementation, producing applications of poor quality, usability and maintainability. The majority of these designs have been implemented with tools such as NetObjects Fusion or DreamWeaver, that allow automated implementation driven by contents and easy set-up (Fraternali 1999), but do not pay attention to the intrinsic features of hypermedia systems such as: sophisticated navigational structures; interactive behaviors; multimedia compositions that have to be usable and harmonic at the same time. More recently, security issues have become a key feature insofar as hypermedia applications and Web applications in particular are increasingly accessed by different users with different purposes and responsibilities (Aedo et al. 2003).
As a result, it is now widely recognized there is a need to apply a software engineering perspective in the development of hypermedia and Web applications (Lowe and Hall 1999), especially for large-scale applications with a long lifespan. Consequently, the development process has to be addressed by design methods rather than by technical issues. Most of the existing hypermedia methods, such as RMM (Isakowitz et al. 1998), OOHDM (Schwabe and Rossi 1998), WSDM (De Troyer and Leune 1998), WebML (Ceri et al. 2000), OO-H (Gómez et al. 2001) and UWE (Knapp et al. 2003), provide mechanisms to deal with some of the aforementioned design concerns. However, not all these methods include software tools to make the tasks of developers and designers more straightforward and effective, providing explicit guidance during the development process and fast-prototyping. Among these methods only WebML , OO-H and UWE are supported by software tools. In practice, they provide only partial solutions for the design process as well as for hypermedia modelling (Montero et al. 2003). On the one hand, these methods only focus on conceptual modelling, defining a sequence to proceed throughout the design phase, but hypermedia applications by their nature are concerned with human-computer interaction and, therefore, their utility, usability and aesthetic should be taken into account. Thus, an evaluation activity and a more flexible development process are required to assess the application utility and usability (Nanard and Nanard 1995). On the other hand, only the more representative hypermedia features are considered (i.e. logic structure of the application, navigation options and presentation features), but they do not properly address issues such as multimedia compositions (including time-based and space-based constraints), the modelling of the system users or the specification of access rules oriented towards defining personalization, adaptation and security policies.
This paper presents a software environment called AriadneTool that supports the conceptual design and fast-prototyping of hypermedia applications, having as methodological foundation the Ariadne Development Method (ADM) (Díaz et al. 2001a). ADM proposes a hypermedia engineering approach combining a systematic, flexible and user-centered design process with the integration of different design views (structure, navigation, presentation, behavior, processes and access), each of which is faced from different abstraction levels by means of a number of design artefacts.
The main motivation of AriadneTool is to enhance the communication process among the heterogeneous members of a hypermedia project, including authors, designers, artists and engineers (Deshpande and Hansen 1998), who have different levels of knowledge and skills. With this purpose, a graphical design environment is provided to produce the different ADM design artefacts corresponding to a specific development project. Additional tasks that are automated to simplify the design process include: checking correctness, completeness and integrity of the modelling with respect to the method semantics, generating documentation about the design project and creating prototypes that can be used for usability evaluation.
The remainder of this paper is structured as follows. Section 2 provides an overview of the ADM, focusing on the design process and the activities and products suggested by the method to deal with specific hypermedia design issues. Section 3 presents the functionality and the architecture of AriadneTool. Section 4 describes how to specify the system requirements to generate a fast-prototype using this tool. Section 5 analyzes related work. Finally, some concluding remarks and future work are outlined.
2 AriadneTool foundation: the Ariadne Development Method
The fundamental idea behind the ADM is to gather efforts from the software and hypermedia engineering fields into a method devoted to the development of large- and medium-scale hypermedia applications. On the one hand, the experience gained in years of research in the software engineering field can help to improve the hypermedia development process (Lowe and Hall 1999). On the other hand, hypermedia application development poses very specific problems that do not appear in other software applications, and hypermedia developers need specific mechanisms to face them (Díaz et al. 1999).
The next sub-sections enumerate the cornerstones of the ADM according to both approaches: as a software engineering method and as a hypermedia/Web method. For a more detailed description of the ADM method see Díaz et al. (2001a). Section 4 provides a running example that illustrates how the main ADM design products are used to model a specific Web site.
2.1 Software engineering approach
The ADM development process is based on the following software engineering requirements (Sommerville and Sawyer 1997):
-
Formal description of the development process. The ADM establishes a systematic, iterative and user-centered development process that counts on three phases: Conceptual and Detailed Design, which address the hypermedia development from different abstraction levels, and an Evaluation phase based on the assessment of prototypes. Each phase is decomposed into a number of activities each of which produces a number of artefacts (see Table 1). Moreover, the method does not impose any sequence to accomplish these phases or the design products, thus both a top-down and a bottom-up design process can be assumed. This design process is depicted in Figure 1 where the arrows represent relationships among phases but not a development sequence.
-
A model to describe the real world and transfer it to a physical system. The ADM notation used for the design of hypermedia applications is based on low-level entities that belong to the Labyrinth reference model (Díaz et al. 1997, Díaz et al. 2001b). These entities represent the core components of any hypermedia system (i.e. nodes, contents, links, anchors, attributes, events and users) as well as basic constructs (i.e. location function, composition mechanism, anchoring system, time and space-based constraints) offering a common language valid for different implementation platforms.
-
Artefacts to specify the system requirements. The ADM integrates within a unified framework several design views (i.e. navigation, presentation, structure, behavior, processes and access) that enable designer or developers to specify characteristics of the desired system (see section 2.2).
-
Validation and integrity rules among phases and products. The ADM provides a number of inter- and intra-validation rules to check completeness, consistency and integrity among the various design artefacts (diagrams, catalogues and specifications) in each phase of the design process (see Figure 1). The former rules check conformance with respect to syntactical rules established in the ADM (e.g. in generalization or aggregation relationships, composite nodes should be the source of the relation). The latter rules ensure that each entity is fully and correctly described by means of cross-references among related products (e.g. for each node defined in the Conceptual Design there is a set of presentation specifications defined during the Detailed Design).
-
A software support tool to help in the systems development process. The ADM is supported by a graphical design toolkit named AriadneTool, the focus of this paper, that gives developers and designers the ability to automate many of their tasks, to check of correctness and integrity of the design, to generate documentation about the project and to generate prototypes in HTML, XML, SMIL and RDF formats.
Figure 1. The ADM development process
2.2 Hypermedia modelling approach
In the ADM, a hypermedia application is seen from several complementary design perspectives which can be applied in conceptual modelling as far as they are independent of any features concerning the implementation or distribution platform:
-
Navigation design. In hypermedia applications, information is split into a number of self-contained and unstructured nodes that are connected to related nodes by means of links. Therefore, the design of this browsing structure, including navigation tools to avoid disorientation, is a critical concern in hypermedia design.
-
Presentation design. Nodes include multimedia content that needs to be organized and harmonized in different dimensions such as time and two- or three-dimensional space. Thus, the way these multimedia contents are related to each other can determine the system utility and usability (Johnson and Nemetz 1998).
-
Structure design. Some hyperdocuments such as books, dictionaries, digital libraries, and so on, have an intrinsic hierarchical structure. Moreover, the use of data models can help to analyze the universe of discourse and to acquire a deeper knowledge of it.
-
Behavior design. Hypermedia systems are highly interactive, including such dynamic aspects as the system reaction to particular events, access to external applications such as databases or inference engines or the inclusion of virtual objects and structures that are created or modified at runtime. Therefore, modelling such a reaction is a relevant design concern.
-
Processes design. Besides navigation functionalities, hypermedia applications now include more and more no-navigation functions such as business processes, search engines or personalization and customization functionalities. Thus, process models can represent how the system works.
-
Access design. Due to the proliferation of multi-user hypermedia applications, the need to preserve the security of the information is increasing as well as to adapt the system to the user needs and preferences. With this purpose, security and access rules have to be analyzed and formally specified in terms of entities of the domain, that is, nodes, links or contents.
For a more thorough discussion of these design issues see Díaz et al. (1999).
To capture properly all six design views enumerated above, the ADM provides a number of design artefacts and mechanisms to deal with them from different abstraction levels. Table 1 summarises the activities performed in each phase, the design products associated with each activity and the design concerns referring to the views described above. Again, the ordering of the activities does not have implications in the development sequence.
Table 1. Phases, activities, products and design concerns of the ADM
CONCEPTUAL DESIGN |
|||
Activity |
Products |
Design Concern |
|
---|---|---|---|
Definition of
|
Structural Diagram |
Structure: Structural relationships among nodes |
|
Study of the
|
Navigation Diagram |
Navigation: Navigation paths and tools |
|
Functional Specifications |
Processes: No-navigation services |
||
Specification
|
Internal Diagrams |
Spatial Diagram |
Presentation: The node visualization area |
TimeLine |
Presentation: Node evolution throughout a time interval |
||
Attributes Catalogue |
Structure, Presentation, Navigation, Behavior, Processes: Properties that can be used with different purposes |
||
Events Catalogue |
Behavior, Processes: Behaviors that can be associated with processes |
||
User Modelling |
User Diagram |
Access, Navigation, Presentation, Behavior: Expected types of users (roles or stereotypes) that can be used to support security rules or personalized/adaptive hypermedia |
|
Definition of the
|
Categorization Catalogue |
Access: Security category for each hypermedia object |
|
Access Table |
Access, Navigation, Presentation, Behavior: Access permissions that determine the contents, links and services offered to the user |
||
DETAILED DESIGN |
|||
Activity |
Products |
Design Concern |
|
Identification of instances |
Node Instances |
Structure: Instances of the abstract elements or structures |
|
Instanced Users Diagram |
Access, Navigation, Presentation, Behavior: Instances of user structures |
||
Specification of functions |
Specifications of Access Structures |
Navigation: Low-level description of navigation aids |
|
Detailed Specification of Functions |
Processes: Low-level description of each function |
||
Specification of instances |
Detailed Internal Diagrams |
Structure, Presentation, Navigation, Behavior, Processes: More detailed information of nodes and contents |
|
Authorization Rules |
Access, Navigation, Presentation, Behavior: Concrete access rights |
||
Users Allocation |
Access: Specific users assigned to roles and stereotypes |
||
Definition of the presentation features |
Presentation Specifications |
Presentation: Presentation properties for nodes and contents |
|
EVALUATION |
|||
Activity |
Products |
Design Concern |
|
Development of a prototype |
Prototype |
All: Interface mock-up |
|
Evaluation |
Evaluation Document |
All: Report about the evaluation process |
|
Conclusions Report |
All: Conclusions to improve the system |
The ADM is flexible as designers can decide to begin at any of the phases and any of the activities in a phase, depending on the modelling habits, skills, preferences, the available resources or the constraints and features of the project being developed.
Moreover, the ADM is not oriented towards supporting only a specific implementation technology but to offer general design products that can be translated to different implementation environments. With this purpose, we propose a design framework consisting of a two-level hierarchy of design entities:
-
Low-level entities: that represent the core components of any hypermedia system (e.g. nodes, contents, links, anchors, events, users and so on) offering a common language for different platforms. At this level the elements of the Labyrinth reference model are used (Díaz et al. 1997, Díaz et al. 2001b). According to Labyrinth, a hypermedia system is defined by means of a Basic Hyperdocument, where the components of the application as well as their structural and semantic relationships and the presentation features are defined, and a number of Personalized Hyperdocuments, that allow for the definition of private work spaces managed by users and groups. Some relevant features of this model are:
-
-
Labyrinth offers composition mechanisms for nodes, contents and users by means of two relationships, aggregation and generalization;
-
Labyrinth makes it possible to define space and time-based constraints between contents;
-
user models and security policies can be specified;
-
metadata can be associated with the elements to increase their semantic through attributes;
-
procedural specification of objects is supported by means of events.
-
-
High-level entities: that are abstractions of the low-level entities to make up design products (see Table 1) that can be discussed among the members of the development team and stakeholders to produce the most appropriate design. These products are general enough to be implemented in different environments and using different tools since technical constraints are postponed until the very end of the development process, when the prototype is built.
Table 2 shows the relationship between the ADM products and the Labyrinth model. For this purpose, only Conceptual Design products are considered as those of the Detailed Design are equivalent but specified from a lower-level of abstraction. For example, a node in the Structural Diagram of the Conceptual Design that represents a node-type can be transformed into several concrete nodes in the Detailed Design.
Table 2. Relationship between Labyrinth and the ADM products of the Conceptual Design
ADM product |
Labyrinth component/construct |
AriadneTool graphical representation |
|
---|---|---|---|
STRUCTURAL DIAGRAM |
Node (simple/composite) |
Simple node |
|
Composite node |
|||
External node for which more details are not provided |
|||
Aggregation |
1:N Relationship among nodes |
||
Generalization |
1:N Relationship among nodes |
||
NAVIGATION DIAGRAM |
Node (simple/composite) |
Simple and composite node (see above) |
|
Simple node acting as navigation tool |
|||
Composite acting as navigation tool |
|||
Link |
Uni- or bi-directional link |
||
FUNCTIONAL SPECIFICATION |
Event |
Form-based representation |
|
INTERNAL DIAGRAMS |
Spatial Diagram |
Node |
Working area of the internal diagram |
Content |
Simple content |
||
Location |
Explicit position of the content in the working area |
||
Alignment |
Form-based representation. Position of the target is dynamically set according to the spatial-based constraint defined |
||
Attributes List |
Form-based representation |
||
Events List |
Form-based representation |
||
Aggregation |
1:N Relationship among contents |
||
Generalization |
1:N Relationship among contents |
||
Time Line |
Node |
Working area of the internal diagram |
|
Content |
Simple content |
||
Location Function |
Explicit position of the content in the working area |
||
Synchronism |
Form-based representation. Position of the target is dynamically set according to the time-based constraint defined |
||
Events List |
Form-based representation |
||
ATTRIBUTES CATALOGUE |
Attribute |
Form-based representation |
|
EVENTS CATALOGUE |
Event |
Form-based representation |
|
USERS DIAGRAM |
Users (role/team) |
Role: kind of user |
|
Team: group of kinds of users |
|||
Aggregation |
1:N Relationship among users |
||
Generalization |
1:N Relationship among users |
||
CATEGORIZATION CATALOGUE |
Node category |
Form-based representation |
|
ACCESS TABLE |
Negative access list |
Form-based representation |
3 AriadneTool toolkit
AriadneTool is an environment devoted to the development of hypermedia applications based upon the design process described in the previous section. Currently, this design toolkit automates all the phases of the ADM Conceptual Design and most phases of the ADM Detailed Design. This automation software tool also supports fast-prototyping in HTML, XML, SMIL and RDF, as well as automatic generation of documentation about the design process. Moreover, AriadneTool also incorporates the use of ontologies for checking completeness, consistency and correctness of the design with respect to the ADM semantics and thus improving the user's understanding of its use.
The software tool is being developed following a user-centered design approach and implemented using JDK1.4. Every year since the first prototype was deployed, the toolkit has been subjected to evaluation by students in a course on hypermedia design following the evaluation process and criteria stated in section 4.3.2 to improve its utility and usability. Moreover, Java technology allows us to obtain an independent operation platform and to add easily collaborations with other Java technology-based applications, as explained below.
Each hypermedia or Web system developed with AriadneTool corresponds to a project. Figure 2 shows the graphical user interface offered to manage the design project.
Figure 2. AriadneTool front-end (full-size figure available)
The AriadneTool front-end is divided into four main areas:
-
The project browser, in which all diagrams and model elements for the current project can be accessed by using a tree structure (area 1 in Figure 2).
-
The properties panel, where the attributes of the currently selected diagram or model element are shown (area 2).
-
The editor panel, where the diagrams listed in Table 1 are depicted and edited (area 3).
-
The validation panel, where error and warning messages concerning violation of the method semantics are reported to the user (area 4).
Other helpful functionalities of AriadneTool are contextual menus, toolbars and help that provide immediate assistance to users without leaving the context in which they are working.
The components over which the AriadneTool front-end is built are shown in Figure 3.
Figure 3. AriadneTool architecture (full-size figure available)
-
Meta-Data Storage contains all the ADM design entities enumerated in Table 2. On the one hand, the Entity-Elements DTD represents the low-level entities that make up the basis of the ADM products (such as the concept of node, anchor, link, structural relationship, and so on). On the other hand, the ADM Products DTD contains all high-level entities that correspond to the ADM products. The combination of both defines the logical structure of an AriadneTool project.
-
The Data Repositories hold application projects. The Dynamic Repository contains all elements specified in each product in the current project as Java objects for faster access, while the Central Repository stores projects in a persistent way encoded in XML, which is compliant with both the Entity-Elements DTD and the ADM Products DTD. This compilation is made by JAXB1.1, which allows automatic two-way mapping between Java objects stored in the Dynamic Repository and the final XML storage.
-
The Validation Module checks the correctness and completeness of the design in process, notifying the designer of any violation of the method semantics. By correctness we mean the user design construction is well-formed (e.g. in the Structural Diagram a node cannot be part of itself) and by completeness we mean the user design contains all elements required for a well-defined application (e.g. a link leaving from a node in the Navigation Diagram has to be assigned to the specific content of such a node in its Internal Diagram). Both validations are performed with respect to entities specified in Table 2. To implement this module, we decided to include ontologies that help to describe the method semantics in a complete, understandable and formal way.
-
The Prototype Generator produces the application prototype automatically by querying the Dynamic Repository. As all design views of an application have been specified declaratively, prototypes can be generated for different delivery languages. All our efforts have been aimed at markup languages proposed by W3C such as HTML, XML, SMIL and RDF/RDFS.
4 Developing a Web site using AriadneTool
A Web site about rural houses and holiday homes is used as a case to demonstrate the capability of AriadneTool as a tool for the design and generation of implementation templates for different platforms. The Web site provides information about houses, their equipment, booking and prices as well as places to visit or activities offered. The site will be accessed by different users:
-
visitors, anonymous users who browse the site;
-
customers, users who have booked some time at the Web site; they can check their reservations and will also be notified of special offers;
-
the Webmaster, who is in charge of administering the site.
Navigation tools to access all this information should be offered to all these users. Figure 4 shows the rural houses home page.
Figure 4. Rural houses Web site
Taking this example site as a starting point, we will go through the phases of the ADM method showing how to generate some of its products. Some products are illustrated by both the Web site and a screenshot of the particular design product. Grey lines crossing both parts are added to put stress on relationships between the prototype and the design. The meaning of the graphical elements can be found in Table 2.
4.1 Conceptual Design
During Conceptual Design phase, the website is approached from a high level of abstraction where structure, navigation, processes, presentation, behavior and access are properly combined to capture the domain semantics in terms of expected types of elements.
4.1.1 Structural diagram
Figure 5 shows the structural relationships that appear in the application domain by means of composite nodes that are connected to their components (simple or composite) using two abstraction mechanisms: aggregation, that refers to a set of nodes as a whole, and generalisation, that represents an inclusion relation involving inheritance mechanisms (Díaz et al. 2001). The structure of our example is defined as an aggregation of a presentation node, which is the entry point to the Web site (shown in Figure 4), and the main composite node which aggregates the index and the information nodes. The aim of this structure is to represent the fact that the Web site is made up of two frames, as pointed out in Figure 5. One frame holds the index node and the other holds the information node. This latter node generalises different kinds of information offered to visitors, such as how to get to a house, or features of the houses.
Figure 5. Structural diagram (full-size figure available)
4.1.2 Navigation diagram
Figure 6 illustrates the navigation paths and tools the Web site offers to users. Navigation paths are settled among nodes using tagged links which can be uni- or bi-directional and n-ary. For example, from the presentation node we browse both the index and houses node. Since information is a generalisation composite, all its components (such as houses, location, and so on) inherit the information link and, therefore, the index node has turned into a navigation tool, tagged with an NT. Moreover, we can define other navigation paths to external nodes of our application as, for instance, the payment link, used when paying for the booking, to access the payment gateway, verify the Visa card number, and return to reservation node.
Figure 6. Navigation diagram (full-size figure available)
4.1.3 Internal diagrams
To provide more information about the nodes defined in the structural and navigation diagrams, an internal diagram is created for each node where contents, anchors, attributes and events can be placed. This diagram consists of two subdiagrams. The spatial diagram is a two-dimensional space that represents the node visualisation area where contents are placed (Figure 7). For instance, our presentation node has two contents, the house logo and a waterfall animation. Moreover, the waterfall animation is coloured blue because it acts as source anchor for information and index links. Finally, to create more harmonic presentations, space relationships can be set among contents. For example, the waterfall content will be always below the logo content.
Figure 7. Spatial diagram (full-size figure available)
The timeline diagram (Figure 8) represents how the node evolves throughout a time interval. In this case new content is added, a sound that is played while the node is browsed. Moreover, to create more dynamic presentations, time relationships can be set among contents. In this case the waterfall animation is shown first, and the logo content appears at the end of the animation (e.g. the respective synchronization relationship in SMIL would be <seq> <waterfallanimation/> <logo/> </seq>).
Figure 8. Timeline diagram (full-size figure available)
4.1.4 Users diagram
Figure 9 illustrates the expected types of users of the application. Users are grouped within roles and teams, with no individual users. A role represents a job function or responsibility, such as the customer role that represents registered users. A team is a group of roles or users who will have some common goal without functional implications, e.g. the user team gathers all roles of the system. Such a structure sets the basis of the access policy, explained in next sub-section (4.1.5).
Figure 9. Users diagram (full-size figure available)
4.1.5 Categorisation catalogue and access table
The categorisation catalogue and access table define who can do what in the system. The categorisation catalogue holds the access category assigned to each node or content, defining the most permissive operation to be performed. These categories, that make up a relationship order where each category adds privileges to the previous one, are: browsing, personalising and editing (Aedo et al. 2003). In this case the category for all nodes and contents is browsing, that is, all nodes can be read but not modified. The access table allows the access policies to be defined following an RBAC (Role Based Access Control) approach, assigning a manipulation category to each role for each node and content. For example (see Figure 10), the offer node can only be accessed by customers, so the anonymous role has a 'no access'. Therefore, the users diagram in combination with these two products make it possible to define user-dependent presentations as well as personalised hyperdocuments as in Montero et al. (2002). For instance, only users that belong to the customer role will have access to offers, as shown in Figure 9.
Figure 10. Categorisation catalogue and access table (full-size figure available)
A more detailed description of the access definition using the ADM can be found in Aedo et al. (2003).
4.1.6 Validation and integrity rules
AriadneTool helps the designer or developer to keep the design consistent and complete with respect to the method semantics. Some of the constraints of the ADM are constantly enforced by the tool. For instance, in the internal diagram, alignment and synchronization relationships between contents are checked during their definition; thus the user cannot create an alignment between a content and itself. The other constraints have to be launched by the user. The tool provides three ways to initiate validation processes:
-
Intra-validation, which validates a specific product, checking if it is well-formed and semantically correct according to the ADM (e.g. in the users diagram (Figure 9). If the visitor role is specialized into a customer role, and at the same time that customer role is specialized into a visitor role, the tool notifies there is a cycle between both elements).
-
Inter-validation, which validates the relationships among several products, checking if each entity of the product is fully described through its appropriate diagrams (e.g. if the link leaving the presentation node depicted in Figure 6 is not assigned to a specific content of such a node in its internal diagram, the tool notifies that an anchor should be specified for that link).
-
Full-validation, which validates each design product and its relationships with other products.
To support this validation process, the Labyrinth reference model was rewritten using an ontology language as DAML+OIL (Montero et al. 2003b). The inherent constraints of the model are defined with the Labyrinth Ontology named Syntactic Rules. The constraints both for well-formed products and for good semantic design of the ADM are specified apart as Semantic Rules. Figure 11 shows how the design elements stored in the Dynamic Repository are turned into an instance of the Labyrinth Ontology (i.e. facts) to be introduced into the Inference Engine. Then, several rules are executed over the instance to detect possible errors. For each error or warning detected, an entry in the validation panel is introduced, with a short message. For more information about the problem and how to resolve it, the user can use the magnifying glass icon.
Figure 11. Validation module architecture (full-size figure available)
Since the Inference Engine chosen for running the validation is DAMLJessKB 1 , Semantic Rules are written in Jess 2 . A rule example to check that a team has to be made up of at least one role is shown below.
(defrule team-whitout-roles
(declare (salience -150))
(PropertyValue http://www.w3.org/1999/02/22-rdf-syntax-ns#type ?t http://ariadne/validator/laby#Team)
(not (PropertyValue http://ariadne/validator/laby#Valido ?t http://ariadne/validator/laby#Team))
=> (assert (PropertyValue http://ariadne/validator/laby#Error ?t No/relationship)))
4.2 Detailed Design
During the Detailed Design phase, the abstract entities and functions specified in the previous phase are instanced into concrete elements. Specific elements can be defined in a declarative way (e.g. using an identifier, URL or URI) or in a procedural way (e.g. by means of scripts or database queries). If the information given in this phase is more concrete, the relation between design and implementation will be made more explicit to the developer. For fast-prototyping, we specify the products Node Instances and Detailed Internal Diagrams. The rest of products of this phase are shown in Table 1.
4.2.1 Node instances
From the structural diagram defined in Figure 5 a number of nodes instances are specified that can refer both to composite and to simple nodes. In this way, the whole structural diagram can be replicated and reused for other rural houses Web sites, or as shown in Figure 12a the house node can be turned into a multi-instance node to create as many instances as needed to represent each rural house held in the Web site. The rest of the nodes are considered mono-instance, that is, the Web site will hold a unique instance of them.
4.2.2 Detailed internal diagrams
Finally, to generate a fast-prototype of the rural houses Web site, only concrete contents have to be associated with each content defined in the internal diagrams of this project. For example, in the instance of the presentation node, resources that represent the house logo and the waterfall animation are attached to their respective contents. Figure 12b illustrates the detailed internal diagram for the house node. As the Web site holds information about three different rural houses, three instances of house node are created. For each one, we need to provide a specific source (i.e. audio, image, text, video or others). If contents are mono-instance, all instances share the same source.
Figure 12. a, Node instances diagram (full-size figure available); b, Detailed internal diagram (full-size figure available)
4.3 Evaluation
Since hypermedia systems are highly interactive, prototypes have to be developed to perform an evaluation of the potential usability of the system. Thus, the development method provides a user-centered process.
The next sub-sections describe how AriadneTool generates a prototype from the design described in previous sections and how the evaluation process is accomplished according to usefulness and usability criteria. The result of the evaluation may imply modifications in the design products.
4.3.1 Fast-prototyping
After the requirements of our Web site have been modeled, each available resource has been attached to its own content, and even the inter- and intra-validation rules have been executed, we can launch the AriadneTool wizard to produce a prototype of our application.
To accomplish the code generation the builder pattern (Gamma et al. 1995) was implemented for the Prototype Generator module. This pattern allows us to separate the construction of the prototype from its representation in different languages so that the same construction process can create different representations. Figure 13 depicts the class diagram for the builder pattern applied to our context.
Figure 13. Builder pattern applied to the prototype generator module (full-size figure available)
During this process the declarative specifications of our project according to the ADM rationale have to be translated into the selected target languages including the resolution of conflicts between the conceptual modelling and the technology (e.g. n-ary links are not supported by Web technology), thus sometimes users will have to take part. Therefore, the AriadneReader class initiates the construction process from the low-level entities retrieved from the Dynamic Repository. The Converter interface specifies an abstract interface for creating parts of a prototype. Each target language constructs and assembles parts of the prototype by implementing the Converter interface, producing files that contain low-level entities encoded and assembled among them according to each technology. For now, AriadeTool generates light prototypes in SMIL, RDF/RDFS and XML. HTML is generated from XML and a series of stylesheets using the XT 3 processor that is an implementation in Java of XSL Transformations (XSLT). Figure 14a shows some pieces of the resulting code for our example in RDF/RDFS. RDFS is used to describe the underlying structure specified in the Conceptual Design, and RDF to represent the concrete resources attached in the Detailed Design. Moreover, in this process an application domain ontology is also generated in DAML+OIL. For more detail about this mapping see Montero et al. (2003b). Figure 14b depicts an example of SMIL source code for the presentation node. Each alignment and synchronization ADM relationship is translated to the respective SMIL one.
Figure 14. a, Example code in RDF/RDFS (full-size figure available); b, example code in SMIL (full-size figure available)
The AriadneTool design toolkit is independent of any platform and language, allowing fast-prototyping to perform an evaluation of the potential usability of the system. Therefore, no runtime environments are included with the tool and the execution of the prototype in a static or dynamic way depends on resources provided by the designer, either in a declarative way (e.g. using an identifier, URL or URI) or in a procedural way (e.g. by means of scripts or database queries).
4.3.2 Evaluation process
Evaluation is aimed at providing information about the potential usability of a system in order either to improve features and interaction mechanisms of an interface or to assess a completed interface. The first step is to prepare an Evaluation Document including the following sections:
-
Evaluation objective. Precise, accurate, clear and measurable goals have to be established.
-
Evaluation method. An appropriate evaluation technique depending on the available resources and the development stage selected. For information on different evaluation techniques see Preece et al. (1994)
-
Profile of evaluators. Select the people who will take part in the evaluation, for which developers should take into account the objectives, the selected evaluation method and the available resources.
-
Data to be collected. Parameters like those listed in Table 3 can be used, establishing which criteria and which parameters for each criteria make sense according to the evaluation goals as well as a metric for each parameter and criteria. Parameters and criteria in Table 3 are based on the work reported in Diaz (2003), where a complete description of each parameter and criteria can be found.
-
Tasks. Developers should establish a set of tasks to be performed to be sure that evaluators will analyze all the features and tools of the hypermedia system. Different sets of tasks can be proposed for evaluators playing different roles. Moreover, it has to be tested that tasks make it possible to collect information on the criteria that have to be assessed.
-
Recording mechanisms. Required to collect data. Data can be obtained from each task execution using, for example, log mechanisms, interviews and questionnaires.
-
Evaluation planning. Evaluation has to be carefully prepared and planned since the results are used to understand the users needs. Developers should establish a plan to conduct evaluation and obtain useful results. For example, biased data can be obtained if evaluation sessions take too long and evaluators are tired and did not pay attention when answering the last questions or performing the last tasks.
Table 3. Evaluation goals, parameters and criteria
Evaluation goal |
Evaluation parameter |
Examples of evaluation criteria |
Usefulness |
Richness |
|
Completeness |
|
|
|
|
|
Hypertext structure |
|
|
Autonomy |
|
|
Competence |
|
|
Flexibility |
|
|
Usability |
Aesthetic |
|
Consistency |
|
|
Self-evidence |
|
|
Naturalness of metaphors |
|
|
Predictability |
|
Once evaluation has been performed, the results are analyzed to derive conclusions to
improve the system. These conclusions, summarized in the Conclusions Report, can
imply modifications in the products generated throughout the design, whether
Conceptual or Detailed, or just in the prototype
itself.
5 Related work
Many methods for the development of hypermedia and Web applications have been proposed. The most relevant examples are RMM (Isakowitz et al. 1998), OOHDM (Schwabe and Rossi 1998), WSDM (De Troyer and Leune 1998), WebML (Ceriet al. 2000), OO-H (Gómez et al. 2001) and UWE (Knapp et al. 2003). A comparative study of these methods is presented in Montero et al. (2003a) according to a reference framework based on software and hypermedia engineering requirements. From this survey, some contributions to the ADM are worth mentioning:
-
Validation and integrity rules to test the correctness, completeness and integrity of the design.
-
Contents modelling to organize and harmonize multimedia contents both in temporal and spatial dimensions.
-
User modelling to model different types of application users and to apply personalization as well as security constraints.
-
Security modelling to model which contents should be delivered, modified or personalized by which users.
-
Evaluation stage to collect information about the potential usability of a system to improve features and functionality of the application interface.
Only some of these methods have implemented a CASE-tool: tools such as WebRatio 4 , VisualWADE 5 and ArgoUWE 6 support WebML, the OO-H method and the UWE methodology, respectively. With respect to the aforementioned contributions, some of the methods include the function of checking the correctness of design aspects of an application project with technologies by means of XSL and OCL. In contrast, our approach uses ontologies, like ICOM 7 or OntoWebber 8 , for this purpose. Ontologies allow formal validation of conceptual modelling because they describe the essential concepts and constraints of a specific domain with an underlying formal logic. Moreover, with respect to the semantic Web, they can help hypermedia methods to provide semantic contents to Web pages generated and contextual information about the domain knowledge involved (Montero et al. 2003b). Finally, all these tools provide automatic code generation capabilities and rapid prototyping. WebRatio and VisualWade can be considered the most advanced tool-support for methods that generate real Web applications automatically.
6 Conclusions and future work
This paper has presented an environment, AriadneTool, that supports the design and development of hypermedia applications where the methodological foundation is the Ariadne Development Method (ADM). Some important aspects of the ADM that make it suitable for designing hypermedia applications are:
-
description of process and subprocess that can be tied to links by means of events to manage no-navigation functions, i.e. business process;
-
special notation to define space- and time-based constraints among multimedia contents to create more harmonic and dynamic presentations;
-
users structure based on roles and teams that can be used to support personalization and security aspects;
-
definition of the security and access requirements assuming a high-level security model (Aedo et al. 2003).
One of the strongest motivations for the development of AriadneTool is to bring the method closer to its users. For that, the tool provides users with explicit guidance for the development process, enabling only those operations allowed and notifying the designer of any mistake, warning or problems related to the completeness and correctness of the design. Moreover, it produces application prototypes dynamically from system requirements conceptualized in a declarative way.
We are working on supporting the rest of the Detailed Design products to enhance the generated prototypes and to produce a runtime environment for the RDF/RDFS application templates. We are extending the use of ontologies to support new tasks such as hypermedia design patterns (Montero et al. 2003b) and user requirements. Using an ontology-based approach, we are going towards Semantic Design Environments that would enable integration or cooperation with other systems and tools or interoperable software components, since ontologies enable interoperability between heterogeneous information, in this case hypermedia methods. A module integrated into a well known Web server like Apache (Díaz et al. 2004) is being implemented to process the access rules defined in the ADM design products, thus enabling user-dependent presentations as well as personalised hyperdocuments.
Finally, we have evaluated AriadneTool by collecting feedback from students who used it to model their projects in a course on hypermedia design. This feedback has been positive, and a large majority believed the tool supported well the method tasks and made using the ADM much easier.
The tool has also been used in a research project named ARCE, a Web-based system envisaged to cope with the lack of synchronism among requests for assistance in a multinational environment, where the main goal is to offer an efficient and reliable communication channel between different agents involved in a disaster mitigation procedure (Aedo et al. 2002), making communication easier among different stakeholders.