Rachatrin Tongrungrojana [HREF1], Faculty of Engineering [HREF2], University of Technology, Sydney [HREF3], PO Box 123 Broadway NSW 2007. Rachatrin.Tongrungrojana@uts.edu.au
David Lowe [HREF4], Faculty of Engineering [HREF2], University of Technology, Sydney [HREF3], PO Box 123 Broadway NSW 2007. David.Lowe@uts.edu.au
Current Web modelling languages fail to adequately support the representation of some aspects of Web systems, particularly higher-level information aspects. In response to this we have proposed WIED - an information modelling notation which addresses this concern. Previously WIED has been illustrated using custom notations that are consistent with WebML. Due to the acceptance of UML as a de facto standard for modelling, we have developed a set of UML-compliant notations for representing the various WIED entities. This then leads to an ability of WIED to form bridges to other models in UML modelled system. In this paper we provide guidelines for supporting the derivation of the WIED model to these different models, thereby providing a concrete link between them. We illustrate these guidelines with a detailed example.
In the last decade the World Wide Web is undoubtedly the world’s best-known
application of an online system. The thirst for information has grown as the
Internet has become widely accessible. This has been accompanied by continuous advances imposed by technological innovations that have caused the
Web (which was initially designed to present information) to evolve support for complex
Web systems which support key business processes. Numerous organisations typically employ Web technologies as crucial
applications for business success and the provision of social and government
services (Shelford and Remillard, 2002; Powell, 1988;Pressman, 2001; Burdman, 1999).
The scientific community has conducted major research both on the desirable
characteristics of Web systems and on the concepts and processes that make up an
effective environment for the structured development of such systems. Various
approaches have been developed for designing and modelling Web-enabled systems.
One crucial aspect in the development of these complex systems is the ability to
ensure that the relationships between the system designs and the business
models, processes and workflows are understood. Good discussions in regard to
this issue can be found in (Gu et al., 2002; Kappel et al., 2001; Kappel et al., 2000a; Kappel et al., 2000b; Christodoulou et al., 1998). Further, by representing these relationships
and defining transformations between them we potentially allow developers and
clients to jointly evolve business and web systems and ensure their
compatibility and optimization (Lowe, 2003; Lowe and Eklund, 2002).
In response, we have proposed an information model that addresses this issue.
This is known as the Web Information Exchange Diagram (WIED). This concept has
been evaluated by a series of studies and the results have provided evidence
that WIED is a useful tool in supporting an understanding of ways in which
business models affect the information design, but also (possibly more
importantly) ways in which the systems designs (and changes to these designs)
affect the business model. This work has been published in (Lowe and Tongrungrojana, 2003a; Lowe and Tongrungrojana, 2003b; Tongrungrojana and Lowe, 2003; Tongrungrojana and Lowe, 2003; Tongrungrojana and Lowe, 2004). The design
of WIED is based around an abstract model which has been formalized as an XML
DTD. In our previous work we showed how this model could be operationalised as a
notation and associated diagram that are consistent with WebML. We also
developed a set of transformations between e3-value (a business modelling
notation (Gordijn and Akkermans, 2001)) and WIED, and then between WIED and WebML (Ceri et al., 2000). This has allowed
us to evaluate the approach and to ensure its effectiveness.
We do however recognise that other modelling languages are also widely used,
particularly UML. Therefore, we published elsewhere the detail of how WIED
could be mapped into UML-compliant notations and operationalized as a new UML
diagram. In this paper we look at how WIED represented using
UML-compliant notations (called WIED-UML) could be linked to other models in a UML
modelled system. This paper is structured as follows: The next section outlines
the background to the WIED concept. We then briefly describe the WIED-UML
notation, before going on to look at linkages to other UML models. We finish the paper with conclusions and
present some ideas for further work.
Over the last decade we have seen the rapid emergence of systems that utilize web technologies to support the integration of complex functionality with rich information handling. This emergence has been accompanied by the development of modelling languages capable of capturing some – though not all – of the aspects of these systems. To model these systems there are a number of elements that we would like to represent. Various approaches have been developed or adapted for capturing and representing complex Web systems. These approaches address on several different levels of modelling that might occurs in representing the design of web-enabled systems as illustrated in Figure 1.
Figure 1 Typical levels in modelling of Web system
At the top level of abstraction we have a business model showing the
essential aspects (such as the strategic intent) of the way of doing business.
Often this will be represented in terms of aspects such as the value exchange
between the organization and other entities that enable the organization to
achieve its business goals. A typical example of a relevant modelling notation
is the e3-value business modelling notation (Gordijn and Akkermans, 2001; Gordijn et al., 2000). This model focuses on the
core concept of value, and expresses how business value is created, interpreted
and exchanged within a multi-party stakeholder network.
Conversely, at the lowest level of Figure 1 we have models of the detailed system
design. These models typically capture design elements that have a direct
correspondence to specific implementation artefacts. Functional design models
are relatively well-established, with the standard dominant model - UML (Booch et al., 1999; OMG, 2003). UML can be used to model both detailed design and higher-level designs through a
complex suite of diagrams that are all treated as views onto a consistent
underlying model (Conallen, 1999;Baumeister et al., 1999). Whilst UML is effective in terms of modelling system
functionality as well as data relationships, in terms of modelling the
information design the situation is somewhat less mature. Typically we wish to
model not only the data (i.e. content) itself, but also the relationship between
the underlying content and the user-perceived views of that content, and the
interactions with those views (such as navigational aspects). Whilst UML has not
been as successful at modelling these aspects, various models have emerged from
the hypermedia
field - particularly for modelling and designing
Web applications. Examples include RMM (Isakowitz et al., 1995), OOHDM (Schwabe and Rossi, 1996), EORM, WSDM and more recently
WebML (Ceri et al., 2000). These models have, however, typically focussed on modelling at a
relatively low-level (e.g. navigational structure) and have failed to address
higher-level aspects, such as architectural and even business process modelling.
In between modelling the business operations and the detailed system designs we have models of the high level system architecture that capture the domains of functionality and the domains of information that need to exist in order to support the value exchange in the domains of business. As discussed previously, functional aspects at this level are well supported by UML. A set of UML models can be used to represent the business and operational workflows (process) of a system, for example, activity diagrams for presenting the sequential flow of activities and data flow diagrams for presenting the flow of data from external entities into and within the system.
However, modelling informational aspects at this intermediate level is more problematic - particularly in terms of explicitly showing the relationships between business models and processes, and detailed information designs. As mentioned above, UML provides good support for functional modelling, but does not address particularly well the modelling of information at this level. For example, activity diagrams show the activity and events that cause an object to be in a particular state which can be used to represent the business and operational workflows of a system. Nevertheless, we contend that whilst activity diagrams can support modelling of functional aspects of business processes, they are not appropriate for modelling information aspects of business processes. This is primarily because activity diagrams mainly focus on the representation of activities and events (which can be seen as functional aspect of business process).
Despite this some researchers do argue that UML diagrams, such as sequence diagram, collaboration diagram and activity diagram, can be used for information modelling at this level of abstraction (Lieberman, 2001). Whilst this is valid to a certain extent, we argue that particular UML diagrams are unable to accurately capture the rich domain context that is important in understanding information relationships and flows (as distinct from data flows) that support value exchanges in business. This includes the relationships between underlying content and the user-perceived views of that content, the interactions with those views, and the ways in which information is represented and presented to the users. This issue might not be a critical problem in conventional software systems that have a strong functional focus, but it does become problematic in Web system development as its low-level detailed design contains a significant information aspect. Some researchers have argued that there is a gap occurring in Web system development, especially information modelling at the business process level. Interesting discussions in regard to evaluations of Web development approaches and modelling can be found in (Gu et al., 2002).
In response to this problem, we have proposed a new modelling notation (which we call WIED - Web Information Exchange Diagram) aimed at representing information flows that occur between actors for supporting value exchanges in businesses (Lowe and Tongrungrojana, 2003a; Lowe and Tongrungrojana, 2003b; Tongrungrojana and Lowe, 2003; Tongrungrojana and Lowe, 2003; Tongrungrojana and Lowe, 2004). The proposed model also represents the relationships between the underlying information, the actor interaction with the information, the ways in which the actor influences the information, and the ways in which information is represented and presented to the users at higher level of abstraction. In effect, our model forms the bridge between business concerns and detailed information designs which we have argued is largely lacking in existing models (Tongrungrojana and Lowe, 2003a).
The abstract WIED model has been formalized as an XML DTD. Previously, to
illustrate the application of the model we mapped it into a custom diagram and
notation that is consistent with WebML. In this context it can be considered as
a companion model to the existing WebML diagrams (and hence, in our earlier
work, we referred to it as WebML+). In addition, our previous research has shown
the value of WIED in supporting the design process (particularly in terms of
ensuring that the implications for business models of changes to systems designs
are well understood).
We do however recognise the wide acceptance of UML as a de facto standard for
modelling notation and so wish to show how the abstract WIED model can be
readily mapped into a UML-compliant notation, resulting in a new WIED-UML
diagram that is consistent with existing UML diagrams.
To represent the WIED model in UML-compliant notations, the formal WIED model
should remain unchanged, but the various WIED entities will map to equivalent
UML entities (which have been stereotyped for clarity). This gives a notational
consistency with UML - but when we then put the various WIED entities together
using the UML notations so we end up with a new UML diagram.
The UML-compliant version of WIED is expressed in terms of stereotypes, tagged
values and constraints (Lowe and Tongrungrojana, 2004). Combined, these mechanisms enable us to create new
types of building blocks that give a notational consistency with UML as follows.
|
Modeling Entity |
UML-Compliant Model |
|
|
|
|
|
|
|
|
|
|
|
|
Figure 2 shows an example of a WIED model (using the WebML-compliant
notation) for a hypothetical example: TicketMaster is a ticketing partner for
the sports and entertainment industries. The strategy adopted by TicketMaster is
to expand their distribution channel by introducing real-time transactional
ticketing through the Internet as well as enabling customers to enquire about
the latest information on shows and events. Their user benefit includes the
ability to purchase tickets online, the option of receiving a weekly newsletter
alerting members to what events are coming up for sale, and exclusive pre-sale
and regular special offers. In this example we have 3 participating actors: the
Ticket-Master organization itself as an internal actor; and two external actors
– users, and sport and entertainment organizers. In brief, TicketMaster as
internal actor provides information directly to the system – in this case price,
event information, promotion information, a set of trading policies, and company
information. The actor TicketMaster also has information exchanges between its
organization and external actors (e.g. cost and event information with sport and
entertainment organizer, and user personal information with users). With the
external actors, sport and entertainment organizers provide ticket cost and
event information (e.g. date and times) to the TicketMaster organization. Users
provide queries for information, payment information as well as user information
(suchas personal information) to the system while they receive user information
and profiles, booking information, event information through newsletter and
special offer from Ticketmaster.
So, let us consider what is represented in the model. The organization boundary
(shown as a dashed geometrical polygon) encloses a set of information units.
These units represent coherent and cohesive domains of information that are
managed or utilized by the organization. All information within a single unit
shares a common context and a common derivation (this is explained shortly).
They do not map directly to pages or sets of pages – a single web page may
contain partial information from multiple units. Similarly, an information unit
may be distributed over multiple pages. Different types of information units are
represented graphically using different types of icons. Some information units
are provided directly by actors. For example, promotion information and trading
prolicy are provided by TicketMaster. However, many information units are
derived from other units rather than being provided explicitly. These
derivations (shown as triangles with incoming and outgoing arrows) capture the
interrelationships between the information units. For example, QuotationInfo is
derived from the event information database, the price database, trading
policies, user profile information and query information provided by the user.
Furthermore, the system boundary (shown as a dotted geometrical polygon)
encloses only the set of information units that are utilised and/or managed by
the system under consideration. (i.e. The elements enclosed by the system
boundary are a subset of the elements enclosed by the organisation boundary. The
organization boundary captures the interface between the organisation and
external stakeholders (i.e. it is crucial in supporting the business modeling).
Conversely, the system boundary captures those elements of the organisation that
can be managed by the system (i.e. it is crucial in supporting the detailed
system design). The full description and detailed example can be found in (Lowe and Tongrungrojana, 2004).
Figure 2 Typical Web System represented using WIED
Representing the WIED model using UML compliant notations enables us to create relevant linkages (in some aspects) between the WIED model and other aspects of the overall UML-modelled system (i.e. UML has been widely adapted and adopted for capturing and modelling software systems and business domains and also Web systems as discusses previously). This implies the ability the ability to support the derivation of a suitable WIED-UML model from/to other UML models. Linkages that are discussed in this paper cover all levels of modelling that might typically occur in representing the design of web-enabled systems as illustrated in Figure 9.
We begin the Linkages section by looking at how the WIED-UML model can derive to the business model. As discussed above, modelling notations at the business model level are quite diverse and often ad hoc, with a typical example being e3-value. Therefore, to link domain of information at business process level to the business model we define the link between the WIED-UML and e3-value business model.
e3-value business models focus on the exchange of value
among the stakeholders. We use this approach as a typical example of business
model since almost all UML address business process modelling rather than
business modelling in term of value exchange. Using the following sequence of
steps we can convert the WIED-UML model shown in Figure 2 into a use case shown
in Figure 3.
1. Identify actors: Consider each actor in the WIED model. For each
external actor, add an equivalent actor (or market segment) to the e3-value
model. Add a single actor to the e3-value model to represent the composite of
all internal actors. For example, the actor TicketMaster in Figure 2 results in
the actor TicketMaster in Figure 3.
2. Identify value exchanges: Consider each information unit on the
organisation boundary in the WIED model. In each case, identify the value
exchange that is supported (and/or modified) by that information unit and add or
modify the appropriate value exchange to the e3-value model. Note that the
direction of the value exchange may not be the same as the direction of
information flow. For example, the value Payment in Figure 3 is a result from
the QuotationInfo and PaymentInfo information unit in Figure 2. [rationale:
value exchanges represent exchanging objects of value need which is the main
focus of business model.]
3. Define value ports and value interfaces: For each value exchange that
is defined in step 2, define an appropriate value port and interface.
[rationale: value exchanges need value ports and interfaces as an actor or value
activity uses a value port to provide or request value objects to or from its
environment and a value interface groups those value ports.]
4. Review the model and refine.
Full detail of this mapping and example was published previously in (Tongrungrojana and Lowe, 2003a).
Figure 3 Typical Business Model presented using e3-value
Whilst the WIED focuses on modelling informational aspect of business process, functional aspect is well captured by a set of UML models. The bridge between these two aspects can be formed by the derivations of the WIED to/from UML models such as use case and activity diagram (i.e. these models are used for presenting business process).
Use cases are formal way to capture and express the interaction and dialog
between system users (called actors) and the system itself. They represent the
functionality provided by the system and are applied for representing static
relationships between business processes. To derive the WIED-UML from/to the use
case, we focus on the external information exchange between the actors and the
system (i.e. it should be the actors and the organisation in case of business
process represented using UML). Using the following sequence of steps we can
convert the WIED-UML model shown in Figure 2 into a use case shown in Figure 4
1. Identify actors: Consider each actor in the WIED model. For each
external actor, add an equivalent actor to the use case. Add a single actor to
the use case to represent the composite of all internal actors. For example, the
actor Sport and Entertainment Event Organiser in Figure 2 results in the actor
Sport and Entertainment Event Organiser in Figure 4.
2. Identify use cases: Consider each information unit on the organisation
boundary in the WIED model. In each case, identify the use case that describes
action/functionality supporting and relating to the information exchange and add
or modify the appropriate use case to the use case diagram. For example, use
case Make a payment in Figure 4 is a result from the QuotationInfo and
PaymentInfo information unit in Figure 2. [rationale: WIED describes flows of
information that support or are related to action/functionality described by use
case.]
3. Define association: Consider each interaction in the use case, define
association for actor that is involved with an interaction described by use
case. [rationale: association needs to exist when an actor describes WIED
describes flows of information that support or are related to
action/functionality described by use case.]
4. Review and the model and refine such as include extend and include
dependencies.
Figure 4 Typical Use Case
Activity diagrams are used to model the flow of activities in a procedure
(i.e. this also includes the activities of a specific operation).They are useful
in the analysis model and for expressing workflow (i.e. workflow can be
considered as functional aspect of Web system). Linking between the WIED and
activity diagram leads to improved relationship between functional and
information aspect of Web systems. To derive the WIED-UML from/to the activity,
we can apply similar procedure to use case mapping procedure however activity
diagram mapping procedure has additional focus in system internal procedures.
Using the following sequence of steps we can convert the WIED-UML model shown in
Figure 2 into an activity diagram shown in Figure 5.
1. Identify actors: Consider each actor in the WIED model. For each
internal or external actor, add an equivalent actor to the activity diagram.
(i.e. all actors are added which is different from use case). And add Initial
node for each actor in the activity diagram. For example, the actor TicketMaster
in Figure 2 results in the actor TicketMaster in Figure 5.
2. Identify initial activities: For each derivation unit in the WIED
model, define an activity in the activity diagram for actor that is involved
(i.e. this can be considered from information flows of each derivation unit).
[rationale: activity diagram needs an initial node.]
3. Identify additional activities: Consider group of information units
that should be part of an activity, define an activity in the activity diagram
for actor that is involved (i.e. this can be considered from information flows
of each derivation unit). For example, the activity Enter Payment Information in
Figure 5 is mapped from the QuotationInfo and PaymentInfo information unit in
Figure 2. [rationale: WIED describes flows of information that support or are
related to activity described by activity diagram.]
4. Review and the model and refine.
Figure 5 Typical Activity Diagram
Recently, there are two interesting UML-based approach for Web system design, including Conallen’s approach and Baumeister’s approach. Therefore, to link domains of information at business process level to system designs we define the link between the WIED-UML and Conallen’s approach and Baumeister’s approach to system design.
Class diagram are used in the Conallen’s UML suite for Web applications for
designing and modelling system navigational structure (Conallen, 1999). Linking between the WIED
and the class diagram (Conllen’s approach) leads to improved relationship
between high level business process (information aspect) and low level system
design (i.e. Conallen’s approach uses several models for description system
design and analysis). In Conallen’s approach, a class in class diagram
represents actual page or form and association represents link and relationship.
To derive the WIED-UML from/to the class diagram, we focus on the information
unit represented directly to the external actors. Using the following sequence
of steps we can convert the WIED-UML model shown in Figure 2 into a browsing
overview class diagram shown in Figure 6 and a browsing detail class diagram
shown Figure 7.
1. Identify class <<form>>: Each information unit in the WIED model which
has an incoming information flow directly from an external actor to the system
(i.e. it appears as an incoming information unit that is located on the system
boundary) can possibly be considered adding a class <<form>> in the class
diagram. For example, the information unit UserInfo in Figure 2 results in the
class User Registration Form in Figure 6 and the class <<Form>> User
Registration in Figure 7. [rationale: form can by used for receiving information
from external users as shown by incoming information flows]
2. Identify class <<server page>>: Consider each form that is defined in
Step 1, and define class server page in the class diagram representing process
that occurs for processing received information. For example, the class server
page Process Registration in Figure 6 and the class <<server page>> Process
Registration are defined for processing information receive by Registration From
defined in Step 1. [rationale: information received by form has to be processed]
3. Identify class <<client page>>: Consider each server page that is
defined in Step 1, if information needs to be processed by another process add
another server page otherwise add client page for representing result of the
process.
4. Identify additional class <<client page>>: For each supplied
information unit in the WIED model which an outgoing information flow directly
to an external actor (i.e. it appears as an outgoing information unit that is
located on the system boundary) define a client page in the class diagram. For
example, the CompanyInfo information unit in Figure 2 results in the class
Company Information in Figure 6 and the class <<Client page>> Company
Information in Figure 7. [rationale: the outgoing information unit hat is
located on the boundary represents domain of information that is available to
users.]
5. Define class attributes and operations: Consider each class that is
defined in step 1-4, and then define attributes and operations in the class
diagram (these can be considered from information units, flows and derivations)
in case of mapping to the browsing detail class diagram or define page
definition or function in case of mapping to the browsing overview class
diagram. [rationale: the browsing detail class diagram provides more detail
about attributes and operations.]
6. Define association: Consider each class in the class diagram, define
association for representing links and relationships between classes.
7. Refine the browsing class diagram following Conallen’s concept (see (Conallen, 1999) for
more information on design concept).
The identified browsing detail class design is used in associated with other UML
models, such as edit entry detail class diagram and main component diagram for
modelling and designing system in Conallen’s approach.
Figure 6 Typical Browsing Overview Class Diagram
Figure 7 Typical Browsing Detail Class Diagram
Navigational class model is used in the Baumeister’s UML extension for Web
applications for defining a view on the conceptual model showing which classes
of the conceptual model can be visited through navigation in the application (Baumeister et al., 1999).
Linking between the WIED and the navigational class model (Baumeister’s
approach) is similar to class diagram mapping procedures for Conallen’s approach
while the purposes of the browsing class diagram is different from the
Baumeister’s approach. To derive the WIED-UML from/to the navigational class
diagram, we apply similar procedure mentioned previously. Using the following
sequence of steps we can convert the WIED-UML model shown in Figure 2 into a
navigational class diagram shown in Figure 8.
1. Identify class: For each information unit in the WIED model which has
an outgoing information flow directly to an external actor (i.e. it appears as
an outgoing information unit that is located on the system boundary) define a
class in the class diagram. For example, the information unit Quotation in
Figure 2 results in the class Quotation in Figure 9.
2. Define class attributes and operations: Consider each class that is
defined in step 1, and then define attributes and operations in the class
diagram (these can be considered from information units, flows and derivations).
3. Define association: Consider each class in the class diagram, define
association for representing relationships between classes.
4. Refine the browsing class diagram following Baumeister’s concept (see (Baumeister et al., 1999)
for more information on design concept).
Figure 8 Typical Navigational Class Model
The identified navigational class diagram is used later to create other aspects of system design, such as navigational structure shown in Figure 9 and presentational model (see (Baumeister et al., 1999)).
Figure 9 Typical Navigational Structure Model
As described above, the WIED-UML model can be mapped to other UML models. This results in an improved linkage between the informational aspects of the business process and other aspects of Web system models. Figure 9 illustrates linkages that have been created and presented so far (some of them were presented in previous publications).
Figure 10 Linkages between WIED-UML and other UML Models
Paper length limitations preclude us from including the detailed steps and reverse direction of mapping procedures discussed earlier (as we present only mapping procedure from the WIED-UML model to other UML models) and from presenting linkages to other interesting UML models such as the conceptual model in (Baumeister et al., 1999), some UML models in (Conallen, 1999; Baresi et al., 1999; Vilain et al., 2000; Gomez et al., 2000; Fons et al., 2003; Lohmann et al., 2003; Pleumann et al., 2003; Dolog and Bielikova, 2002; Dolog and Nejdl, 2003; Muller et al., 2003), etc. We argue the improved linkages between Web system models leads to solutions for crucial problems in Web system development such as disconnection between functional architecture and information architecture, disconnection between business models and technical architectures (i.e. this is main focus of the WIED concept). Further, we argue linkages presented here (and in previous publications) should be a good start for making the WIED a practical companion to existing widely-used UML models and potentially integrated with those models to create a better UML based modelling suite for Web system developments.
In this paper, we have presented the WIED model represented using UML-compliant
notations and shown how the WIED-UML can be used to form linkages between business
process models (WIED-UML model) and other UML models representing aspects of
Web system design.
We argue that representing the WIED model using UML compliant notations and
then supporting the mapping processes discussed earlier enables us to achieve improved linkages between
the various levels of the system design. This results in an improved development process
which supports the creation of systems which more directly address business
needs.
Ongoing work is focusing on refining the model, particularly in terms of adding adding new features to the WIED
notation (both WebML and UML compliant) and evaluating
the concepts. Potential future work will also include creating automated tool
support..
Baresi, L., F. Garzotto, et al. (2001). Extending UML for Modeling Web
Applications. 34th Hawaii International Conference on System Sciences, Hawaii,
USA.
Baumeister, H., N. Koch, et al. (1999). Towards a UML Extension for Hypermedia
Design. <<UML>> 1999: The Second International Conference on The Unified
Modeling Language, Fort Collins, Colorado, USA.
Booch, G., J. Rumbaugh, et al. (1999). The Unified Modelling Language User
Guide, Addison-Wesley.
Burdman, J. (1999). Collaborative Web Development, Addison-Wesley.
Ceri, S., P. Fraternali, et al. (2000). Web Modeling Language (WebML): a
modeling langauge for designing Websites. the Proceeding of WWW9 Conference,
Amsterdam.
Christodoulou, S., G. Styliaras, et al. (1998). Evaluation of Hypermedia
Application Development and Management Systems. ACM Hypertext'98 Conference,
Pittsburgh.
Conallen, J. (1999). Building Web Applications with UML, Addison-Wesley.
Dolog, P. and M. Bieliková (2002). Hypermedia Modelling Using UML. ISM 2002 -
Information Systems Modelling - ISM'2002, Czech Republic, MARQ Ostrava.
Dolog, P. and W. Nejdl (2003). Using UML and XMI for Generating Adaptive
Navigation Sequences in Web-Based Systems. <<UML>> 2003 - The Unified Modeling
Language - Modeling Languages and Applications, San Francisco, USA, Springer.
Fons, J., V. Pelechano, et al. (2003). Extending an OO Method to Develop Web
Applications. The Twelfth International World Wide Web Conference, Budapest,
Hungary.
Gomez, J., C. Cachero, et al. (2000). Extending a Conceptual Modelling Approach
to Web Application Design. 12 th International Conference on Advanced
Information Systems, Springer-Verlag.
Gordijn, J. and J. M. Akkermans (2001). "e3-value: Design and Evaluation of
e-Business Models." IEEE Intelligent Systems, special issue on e-business 16(4):
11-17.
Gordijn, J., J. M. Akkermans, et al. (2000). Business Modelling is not Process
Modelling. ECOMO 2000, Salt Lake City, USA.
Gu, A., B. Henderson-Sellers, et al. (2002). Web Modelling Languages: The Gap
between Requirements and Current Exemplars. AusWeb02, Gold Coast, Australia.
Isakowitz, T., E. Stohr, et al. (1995). "RMM: A Methodology for Structed
Hypermedia Design." Communications of the ACM 38(8): 34-43.
Kappel, G., B. Proll, et al. (2001). Modeling Ubiquitous Web Applications - A
Comparison of Approaches. The International Conference on Information
Integration and Web-based Applications and Services, Austria.
Kappel, G., W. Retschitzegger, et al. (2000). Modelling Customizable Web
Applications - A Requirement's Perspective. The International Conference on
Digital Libraries: Research and Practice, Koyoto, Japan.
Kappel, G., W. Retschizegger, et al. (2000). Toward Modelling of Data WEb
Applications - A Requirements' Perspective. Americans Conference on Information
Systems, Long Beach, CA, USA.
Lieberman, B. (2001). UML Activity Diagrams: Detailing User Interface
Navigation.
Lohmann, M., S. Sauer, et al. (2003). ProGUM-Web: Tool Support for Model-Based
Development of Web Applications. <<UML>> 2003 - The Unified Modeling Language -
Modeling Language and Applications, San Francisco, USA, Springer.
Lowe, D. (2003). "Web Requirements: An Overview." Requirements Engineering
Journal.
Lowe, D. and J. Eklund (2002). "Client Needs and the Design Process in Web
Projects." Journal of Web Engineering 1: 23-26.
Lowe, D. and R. Tongrungrojana (2003a). WebML+ for Communication of Information
Flows : An Empirical Study. the Third International Conference on Web
Engineering, Oviedo, Asturias, Spain.
Lowe, D. and R. Tongrungrojana (2003b). WebML+ in a nutshell: Modelling
architectural level information flows. WWW2003: 12th International World Wide
Web Conference, Budapest, Hungary. Available online
">[HREF5]
Lowe, D. and R. Tongrungrojana (2004). Web Information Exchange Diagrams for UML.
the Fourth International Conference on Web Engineering, Munich, Germany.
Muller, P.-A., P. Studer, et al. (2003). Platform Independent Web Application
Modeling. <<UML>> 2003 - The Unified Modeling Language - Modeling Languages and
Applications, San Francisco, USA, Springer.
OMG (2003). Introduction to OMG's Unified Modeling Language™ (UML™).
Pleumann, J. and S. Haustein (2003). A Model-Driven Runtime Environment for Web
Applications. <<<UML>> 2003 - The Unified Modeling Language - Advancing the
Standard, San Francisco, USA, Springer.
Powell, T. A. (1988). Web Site Engineering, Prentice-Hall.
Pressman, R. (2001). Software Engineering: A practitioner's Approach, McGraw
Hill.
Schwabe, D., G. Rossi, et al. (1996). Systematic hypermedia application design
with OOHDM. Hypertext' 96, The 7th ACM Conference on Hypertext, Washington DC,
ACM Press.
Shelford, T. J. and G. A. Remillard (2002). Real Web Project Mangement: Case
Studies and Best Practices from the Trenches, Addison Wesley Professional.
Tongrungrojana, R. and D. Lowe (2003). Modelling Forms of Information Derivation
in Modified WebML+. the Ninth Australian Web Conference, Gold Coast, Australia.
Tongrungrojana, R. and D. Lowe (2003). WebML+: a Web modeling language for
forming a bridge between business modeling and information modeling. the
Fifteenth International Conference on Software Engineering Knowledge
Engineering, San Francisco.
Tongrungrojana, R. and D. Lowe (2004). "WIED : a Web modelling language for
modelling architectural-level information flows." Journal of Digital
Information.
Vilain, P., D. Schwabe, et al. (2000). A Diagrammatic Tool for Representing User
Interaction in UML. <<UML>>2000: The Third International Conference on The
Unified Modeling Language, York, U.K.
