Understanding business impacts of changes to information designs: A case study

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

Abstract

In the development of Web-enabled systems, the business environment and its domain not only drive the identification of system needs, but also are in turn fundamentally changed by the introduction or evolution of a system. This means that a Web-enabled system that is under development will be highly volatile and the changes to the design will be likely to impact on the business domain. In response to this issue, we have previously developed a model (known as WIED) which more clearly links system designs and the business model, and can hence facilitate the identification of impacts on the business domain that arise from changes that are made to the underlying information designs. In this paper we present a case study conducted for evaluating the effectiveness of this model in supporting the identification of these impacts.

Introduction

In the span of a decade, the Web has transformed entire industries and entered the mass culture. It has created new expectations on ease of access, freshness, and relevance of information accessed via the Internet. Online Web-enabled systems have become increasingly crucial to both business success and to the provision of social and government services. These systems are much more complex than simple web sites containing static pages. They typically employ Web technologies to provide a complex distributed front-end combined with high-performance back-end software systems that integrate new components with existing legacy applications to support critical business processes.

One key characteristic of Web-enabled system (as well as various other software systems) is that the introduction of the system has a fundamental impact on the nature of the business processes and business models which are being supported by the system. In other words, the business domain not only drives the definition of the system needs, but is in turn fundamentally changed by the system.

To support the identification of the impact of Web systems on the business domain we have previously published elsewhere details of a proposed information flow model (Lowe and Tongrungrojana, 2003a;Lowe and Tongrungrojana, 2003b;Tongrungrojana and Lowe, 2003a;Tongrungrojana and Lowe, 2003b;Tongrungrojana and Lowe, 2004) known as the Web Information Exchange Diagram (WIED). The focus of this model is to represent the high level system architecture that capture the domains of information that need to exist to order to support the exchange of value in the business domain. In particular, we focus on representing the information flows (i.e. information aspects of the business processes). This enables the WIED model to form a bridge between the high-level business models and low-level information designs, thereby facilitating the process of identifying the impacts on the business domain as mention earlier.

The effectiveness of this model in supporting impact analysis has been previously evaluated by using a series of experimental studies. The previous studies have given evidence that the WIED model can provide better communication of information flows that exist within a Web system (the study design and results have been published in (Lowe and Tongrungrojana, 2003a)). In this paper we present the design and results of a case study in which we aimed to investigate more deeply the way in which developers responded to the use of this model and how it influenced their approach. We begin by providing, in the next section, the background to the development of WIED. We then briefly describe the WIED concepts. Following that we present the design of the case study and the results. We  then discuss analyses and reflection of this case study. We finish the paper with conclusions and present some ideas for further work.

Background

As discussed above, 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 representing complex Web systems. At the highest level of abstraction we have business models which show essential aspects of the way of doing business (such as the strategic intent). Often this will be represented in terms of key business concepts such as the value exchange between the organization and other entities and which enable the organization to achieve its business goals. A typical example of a relevant modelling notation is the e³-value business modelling notation (Gordijn et al., 2000a;Gordijn et al., 2000b;Gordijn et al., 2000c;Gordijn and Akkermans, 2001a;Gordijn and Akkermans, 2001b;Gordijn, 2002a;Gordijn, 2002b;Gordijn and Wieringa, 2003). 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 lower levels of abstraction 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 dominant model (arguably) now UML (OMG, 2003;Chitnis et al., 2004). 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. 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). Given that UML has not been as successful at modelling these aspects, there has been an emergence of a number of informational modelling approaches specifically developed for Web (or hypermedia) applications. Example approaches include RMM (Isakowitz et al., 1995), OOHDM (Schwabe and Rossi, 1996;Schwabe and Rossi, 1998), and more recently WebML (Ceri et al., 2000) . These models have, however, typically focussed on modelling at a relatively low-level 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 business value exchanges . 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 activity diagrams can be used for information modelling at this level of abstraction (Lieberman, 2001). Whilst this is valid to a certain extent, we argue that activity 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 where the system 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. An interesting discussion in regard to evaluation of Web development approaches and modelling can be found in (Gu et al., 2002).

WIED

In response to the problem discussed above we have proposed a new modelling notation which we call WIED - Web Information Exchange Diagram. This model is 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, 2003a;Tongrungrojana and Lowe, 2003b;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 a bridge between business concerns and detailed information designs which we have argued is largely lacking in existing models (Tongrungrojana and Lowe, 2003b).

The abstract WIED model has been formalized as an XML DTD. 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+). We have also published the WIED using the UML-compliant notations. Figure 1 illustrates the WIED model representing the information flows for the Web system supporting the Western Districts Billiards & Snooker Association. This site was the basis for the case study to be discussed in the next section.

The Western Districts Billiards & Snooker Association (WDBSA) is an organisation that conducts billiards and snooker competitions and provides related services for local clubs in the Western Sydney area. The strategy adopted by WDBSA is to bring the benefits of Internet based applications to the club and its members by addressing several issues such as communication, information management and competition record keeping. The system developed by the WDBSA is known as the Snooker Club Web Portal (SCWP).

Details on the notation and how it can be interpreted are provided in our earlier work. Several brief notes are nevertheless useful. The organisation 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 utilised by the organisation. All information within a single unit shares a common context and a common derivation. 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 inter-relationships between the information units. 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. The organisation boundary captures the interface between the organisation and external stakeholders (i.e. it is crucial in supporting the business modelling).

We believe that this model is able to form a bridge between the business modelling (business model) and the lower level information modelling (system design). This implies the ability to support the derivation of a suitable WIED model from/to the business model represented using e³-value notations, and an appropriate WebML detailed design model from/to the WIED model. Figure 2 illustrates the business model (using the e³-value notation) of the WDBSA organisation, and Figure 3 illustrates the system design (using the WebML notation) for the Web system which supports the operation of the WDBSA.

The Case Study

The WIED model has been evaluated by a series of experimental studies. Previously, we have conducted the experiments looking whether the WIED model can provide more rapid and consistent communication of organisational information flows. In brief, we found that the study participants obtained a more accurate understanding of information flows within a given timeframe by using the WIED models relative to when they used only textual descriptions (this work has been published in [4]).

Further, as a result of the ability of the WIED model to form a bridge between the business models and the system detailed designs we believe that the WIED is able to support an understanding of ways in which the system designs (and changes to these designs) affect the business model. To investigate this belief we undertook the case study described in this paper. The case study research method was desirable and applied due to its advantages that were appropriate for our situation. In general, a case study research method is suitable for bringing us to an understanding of a complex issue or object and can extend experience or add strength to what is already known through previous research. Case studies emphasize detailed contextual analysis of a limited number of events or conditions and their relationships (whereas experiments focus on statistically controlled tests) particularly when the boundaries between phenomenon and context are not clearly evident; and in which multiple sources of evidence are used.

In our particular case we also had only limited developers who were familiar with the WIED approach, and hence a detailed set of experiments was not feasible (i.e. experimental studies need a certain number of participants for establishing experimental validity) and a case study research method could be a solution to this problem.

Figure 1: WIED model for the WDBSA case study system/organisation

Figure 2: e³-value business model for WDBSA

Figure 3: WebML system model for SCWP (system for WDBSA)

Research Questions

Our key case study research questions focus on considering the WIED model in terms of how well it supports developers and clients in understanding relationships between the system designs and the business models, particularly relating to the identification of impacts on the business models of changes that are made to the underlying designs.

Q1: How do the developers apply the WIED model during the development process, particularly in terms of identifying impacts on the business model which arise from changes that are made to the underlying system designs?

Q2: What types of impacts on the client business models and processes can be identified?

Q3: What aspects of the system designs and the WIED model have influences on the identified impacts?

Q4: Do users and developers realize that there is the gap between the system designs and the business models and also believe that the information flows and the WIED model can fill this gap?

Q5: Do users and developers believe that the WIED model assisted them in understanding and identifying the impacts on (and subsequent modification of) the business models and processes to reflect the changes? How?

Q6: How do the developers compare the use of the WIED model in the development process to non-use of the WIED model?

Q7: How do the clients compare their satisfaction of the business models identified using the WIED model compared to the business models identified without using a WIED model?

Q8: How do the developers feel about the WIED diagrams and concepts?

Methodology, Situation, and Data Sources

In brief, the case study design used in this study was to compare the development process and results of the identification of impacts on the business models when development undertaken without access to a relevant WIED model as compared to development undertaken with access to a relevant WIED model. Figure 4 illustrates the design of this case study.

At the top of this figure we can see a developer who is asked to consider an existing Web system (the WDBSA system discussed above) and to then comment on the potential business impacts of some prospective system changes (which have been proposed by the investigator. At the bottom of the figure the same scenario occurs, except that in this case the developer is also provided with a WIED information flow model. They are also supported in interpreting this model by a researcher. This will result in a separate set of impacts. The system client is then asked to compare the identified impacts to interpret them for validity.

The case study began with the initial modelling of the WDBSA business model and the SCWP system design respectively (i.e. these two models were created by analysing the documents and interviews with the developers and clients). These two models were checked by the clients (project stakeholder) and the developers to ensure that they captured the business model and the system correctly in order to be analysed for creating the changes to the system design. We then proposed a set of changes to the SCWP system (represented as changes to the low level design). These changes are illustrated in Figure 5. The developers were then were asked to identify and describe their understanding of the impacts of these changes on the business models and processes to reflect the proposed changes (impact A in Figure 4).

Figure 4: Case Study Overview

Next, we provided to the developer the WIED models which reflected both the original system and the changed systems. The developers were then again asked to identify and describe their understanding of the impacts (impact B in Figure 4). Finally, a comparison of impacts A and B was undertaken. The results and analyses are presented and discussed in the next section.

To produce more reliable results we use multiple sources of evidences in our case study. In general, a key strength of the case study method involves using multiple sources and techniques in the data gathering process. No single source has a complete advantage over the others; rather, they might be complementary and could be used in tandem. Thus we used as many sources as were relevant to our study for establishing the validity and reliability of the conclusions. We used the following key information as sources of evidence:

Project documentation: This included: software design description, software development plan, software requirement specification, use case analysis, user interface specification, software test plan and software coding standard. These items were used for explaining the scenario, creating changes to the design, creating the WIED diagrams as well as explaining the development process that was used. We carefully reviewed these documents to avoid data being interpreted incorrectly.

Archival records: These were useful in our study since they included records, survey data, and even personal records such as diaries.

Interviews: These were one of the most important sources for our case study information. In our case study, open-ended and focused interviews were conducted for gathering data, such as the participants/informants’ opinions on the application of the WIED as well as focused questions from the case study protocol. These interviews served to corroborate other gathered data.

Direction observation: This was applied by having a casual site visit to gather data in regard to how the participants/informants applied the WIED in their Web system development process, especially in understanding of the impacts on the business model that reflect changes that are made to the underlying system designs.

Participant observation: Again, this was also applied in addition to direct observation by participating in the development process. We had some chances to participate in the process for identifying impacts on the business model which reflect the changes that are made to the system designs.

Questionnaire/survey: In our study, we used questionaries for comparing the client satisfaction in the impacts identified using different techniques.

Figure 5: Modified WebML model of the SCMP, capturing proposed changes

Results

In this section we present our results from the analysis of the case study data collected during the SCWP project. We will structure this in terms of the original research questions which we posed previously.

Q1: How do the developers apply the WIED model during the development process, particularly in terms of identifying impacts on the business model which arise from changes that are made to the underlying system designs?

The direct observation and participant observation (made during site visits) showed that initially, when the developer was first developing an understanding of the connections between the e³-value business model, the WIED model and the WebML detailed system design model, they began by focusing on the actors. They subsequently progressed to focussing on the information that is exchanged on the border of the system and organisation. Whilst we didn't quantify precisely when each specific impact was identified by the developer, the overall pattern is as described in Table 1. Subjectively the identification of impacts followed the type of pattern represented in Figure 6.

Table 1: Identification of possible business impacts

Figure 6: Representation of the timing of impact identification

Further, informal comments by the participants' interviews (users and developers) indicated that previously impacts were largely identified informally and based on the developers’ own experience and intuition, and relied upon their imagination without any standard procedure or additional tool. However, when they applied the WIED model, they were quickly able to identify the possible effects of changes.

Q2: What types of impacts on the client business models and processes can be identified?

The impacts on the business models and processes were identified from the participants in the form of changes to the e³-value model as well as textual description. Figure 7 illustrates a fragment of the e³-value model before and after the developer had access to the WIED model. It can be seen that in Figure 7(b) the developer was able to identify many additional value exchanges (and an additional stakeholder) that arise out of the system changes.

With the WIED model available the developers could add more potential changes, see additional business opportunities, and obtain a clearer understanding of the role of each actor. For example, in Figure 7(b), visitors to the site represent an additional role from the players.

Figure 7: Comparison of modified e3-value model (a) developed without access
to the WIED model and (b) developed with access to the WIED model.

Q3: What aspects of the system designs and the WIED have influences on the identified impacts?

From discussions with the developers during the process we were told that one of the most significant aspects that were highlighted in the WIED model and were missed in the system designs include the information exchange between the external actors and the system. The system designs typically cover aspects such as the content viewpoints, interface metaphors, and navigational structures – users almost become only information retrievers and are naturally assumed that only one type of user access to the system. Also, the information suppliers, who provide information to the system, are not presented in the system design. The internal information exchanges seem to be less important while it has a potential to be linked to functional aspect of the system.

Q4: Do users and developers realize that there is the gap between the system designs and the business models and also believe that the information flows and the WIED model can fill this gap?

User opinions and beliefs, with regard to the gap issue, were obtained from the open-ended interviews with the clients and developers. They gave their opinions that the WIED model made them aware that there is another layer that links the high-level business model and the low-level system design. It was also felt that as a consequence of the absence of this layer, there is the gap that is needed to be filled. Hence, they believed that the WIED model assisted them to realise and understand the gap and also to fill in this gap.

Q5: Do users and developers believe that the WIED model assisted them in understanding and identifying the impacts on (and subsequent modification of) the business models and processes to reflect the changes? How?

We examined the users and developers’ opinions on the application of the WIED model from the open-ended interviews. The participants stated that previously they relied upon their experience (as mentioned earlier). However, using the WIED model helped the developers remove much of their guesswork. So, this created more confidence that they had more completely discovered the impacts and had not left anything out. In a survey regarding their response to the application of the WIED model, the respondents all strongly agreed with the following three statements

Participant believes that the WIED model can be applied in the Web development process?
Participant believes that the WIED model is meaningful and interpretable?
Participant believes that the WIED model is useful?


Q6: How do the developers compare the use of the WIED model in the development process to non-use of the WIED model?

The developers additionally mentioned in the interview that the WIED model shows clearly the actors involved in the business model, the relationships and flow of information. They felt that this made the work of identifying possible areas of impact much easier. The areas identified were additional to the ones identified using no model and the developers believed that it was easier to identify and understand impacts using the visual WIED model. By seeing the relationship that exists and the flows of information and value laid out in one diagram it was believed that it was much easier to understand how the business works.

Q7: How do the clients compare their satisfaction of the business models identified using the WIED model compared to the business models identified without using a WIED model?

The clients (representing WDBSA) filled in questionaries which involved expressing their satisfaction level with regard to the identification of the impacts using different techniques. The following results were obtained with regard to the key questions:

As can be seen from these responses, the client was very satisfied with the impacts identified using the WIED model as compared to the impacts identified using no WIED model, especially in terms of completeness of the impacts and exploring new business opportunities. The clients added in the interview that the impacts identified using the WIED model assisted them in understanding: potential business opportunities; what the Websites can do for them; additional aspects that were missed out from the impacts identified without the WIED model. The clients and developers agreed that the WIED model allowed them to work together in the development process exploring the impacts/changes in the business models.

Q8: How do the developers feel about the WIED diagrams and concepts?

The developers provided some comments and feedback on the WIED models and concepts. For example, it was definitely felt that the WIED diagram added value by describing information flows and business relationships. They thought with experience using the diagram on a few projects it would become easier to interpret and identify impacts on the business models. It was commented that some form of formal guide to interpreting the diagrams would be of value. They thought that the developers still needed knowledge and experience to determine how changes to one flow of information had effects further down the chain or throughout the system. It was also felt that some representation of relative significance of information flows could be integrated into the diagrams.

Study reflection, result analysis, hypothesis validation and replication

In this case study we reported results relevant to each of our research questions. Specifically, we reported on how the developers apply WIED to support the identification of impacts on the business model arising out of changes that are made to the system design. Case studies such as this provide excellent input in validating the following hypothesis:

The WIED information modelling notations can facilitate the identification of impacts on the business domain which arise from changes that are made to the underlying information designs.

Despite the dangers in generalising from a single case, the analysis of this case can provide important insights and evidence supporting the above hypothesis. We can conclude that the WIED model is likely to make it simpler for the developers to more rapidly and more completely understand the business processes and identify the possible impacts on the business model of system changes, especially in terms of clarifying actors’ roles and the exchanges of information and value between actors. By visualising the business process (in term of information flows) in the diagram, the developer can see the business and information relationships that exist and the flows of information and value which support these. The result is likely to be that developers will be more confident that they have not overlooked some significant impacts.

However, in this study, the participants (developers) focused most specifically on external information exchanges (flows) between the actors as the e³-value business model focussed on representing value exchanges between stakeholders, while they paid much less attention to internal flows of information that were also represented (note the WIED model also covers internal information flows). Whilst we argue that internal information flows are relevant for describing the information aspect of the organisational business process, the case study did not provide clear evidence for evaluating this.

Further, the participants (developers) used on only the model presented using custom notations while the WIED model also has been formalized as an XML DTD. The formal model (XML DTD) was not considered even though it has a potential to be used for automated mapping from XML-based system design to the WIED model then to the XML-based business model.

Conclusion and further work

In this paper, we have presented a case study of an application of the WIED model in facilitating understanding of impacts on the business domain which arise from changes that are made to system designs. The study sought to investigate whether the WIED model could assist the developers in the identification process and also provide a more complete understanding of how developers responded to the model. Despite some difficulties, the results of the study provided evidence which supported our hypothesis.

Ongoing work is focusing on refining the model, particularly in terms of increasing the expressiveness of the model, and increasing it's integration with other approaches such as UML. We are also investigating possible semi-automation of the impact analysis process by utilising reasoning algorithms.

References

Ceri, S., P. Fraternali, et al. (2000). Web Modeling Language (WebML): a modeling language for designing Web sites. WWW9, Amsterdam.

Chitnis, M., P. Tiwari, et al. (2004). UML Overview. Available online [HREF5]

Gordijn, J. (2002a). e³value in a Nutshell. International workshop on e-business modeling, Lausanne.

Gordijn, J. (2002b). Value based requirements engineering: Exploring innovative e-commerce ideas.

Gordijn, J., H. Akkermans, et al. (2000a). Value based requirements creation for electronic commerce applications. the 33rd Hawaii International Conference On System Sciences, Hawaii, USA, IEEE.

Gordijn, J. and J. M. Akkermans (2001a). A Conceptual Value Modeling Approach for e-Business Development. K-CAP 2001, First International Conference on Knowledge Capture, Workshop Knowledge in e-Business.

Gordijn, J. and J. M. Akkermans (2001b). "e³-value: Design and Evaluation of e-Business Models." IEEE Intelligent Systems 16: 11-17.

Gordijn, J., J. M. Akkermans, et al. (2000b). Business Modelling is not Process Modelling. ECOMO 2000, Salt Lake City, USA.

Gordijn, J., J. M. Akkermans, et al. (2000c). What's in an Electronic Business Model? 12th International Conference, EKAW 2000, Juan-les-Prins, France, Springer-Verlag.

Gordijn, J. and R. J. Wieringa (2003). A value-oriented approach to e-business process design. the 15th International Conference, CAiSE 2003, Klagenfurt/Velden, Austria, Springer Verlag.

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.

Lieberman, B. (2001). UML Activity Diagrams: Detailing User Interface Navigation.

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 [HREF6]

OMG (2003). Introduction to OMG's Unified Modeling Language ^tm (UML ^tm). Available online [HREF7]

Schwabe, D. and G. Rossi (1998). Developing Hypermedia Applications using OOHDM. Workshop on Hypermedia Development Processes, Methods and Models (Hypertext'98), Pittsburgh, USA.

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.

Tongrungrojana, R. and D. Lowe (2003a). Modelling Forms of Information Derivation in Modified WebML+. the Ninth Australian Web Conference, Gold Coast, Australia.

Tongrungrojana, R. and D. Lowe (2003b). 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.

Hypertext References

HREF1

http://www.rachatrin.com/

HREF2

http://www.eng.uts.edu.au/

HREF3

http://www.uts.edu.au/

HREF4

http://www.eng.uts.edu.au/~dbl/

HREF5

http://www.developer.com/design/article.php/1553851

HREF6

http://www2003.org/

HREF7

http://www.omg.org/gettingstarted/what_is_uml.htm

Copyright