Aspect Based Conceptual Modelling of Web ... - Semantic Scholar

Aspect Based Conceptual Modelling of Web Applications Athula Ginige AeIMS Research Group, University of Western Sydney, Australia [email protected]

Abstract. Though there are many Web application modelling approches these are aimed at assiting the implmentaion process. There are many benefits in creating a conceptual model of the Web application to verify whether the application domian requrements have been propery understood. We have developed a way of modelling a web application at a conceptual level based on set of aspects; Overall Presentation, Primary Navigation, Hypertext Model, Process Model and Personalisation Model. We have found that this set of conceptually non-overlapping aspects greatly simplifies the modelling task. We also observed that application domain users found it easy to relate to these aspects and provide feedback on the accuracy of the model. Keywords: Conceptual modelling, aspect based modelling, process model, hypertext model.

1 Introduction The process of developing a Web application, like many other development activities, can be viewed as the conversion of a concept into a physical system. Until we create the physical system, the web application that we create needs to be represented as models in different domains and at different levels of abstraction. The original concept often originates in a domain other than computing, such as science, business, education, health, government etc. These concepts originate as a solution to a problem related to providing convenient access to information, such as places of interest in the context of tourism; assisting in conducting a task such as bill payment; automating a process such as applying for leave, which consists of a sequence of tasks; or a calculation such as creating a production schedule. People are thinking of increasingly more complex web-based applications to assist in conducting activities in various domains. Obtaining necessary requirements for such applications has been a problem, not only in relation to developing web applications but also when developing software applications. Thus when people conceptualise increasingly more complex applications, capturing these requirements becomes more difficult. It has been observed that the introduction of an information system to an organisation results in changes to their business processes, which in turn causes changes to the implemented information system. Users also discover better and more efficient ways to use the system, and request these changes. These changes lead to a cyclical R. Kaschek et al. (Eds.): UNISCON 2008, LNBIP 5, pp. 123–134, 2008. © Springer-Verlag Berlin Heidelberg 2008

124

A. Ginige

evolution of the business processes, users and the information system. This is called co-evolution [1, 2], and is a very common occurrence in Web-based applications, making it necessary to design the system such that requirements can evolve while the system is in use [3]. Modelling is an inborn ability possessed by humans to reduce the complex universe to a world that is relatively easy to manage. In modelling, important phenomena are mapped to notions and represented by signs. For example, the notion of a website can be represented as a hierarchical diagram or a graph. Using an agreed method of representing concepts associated with web applications will assist the thinking process of developers, and also facilitate the communication among people involved in developing the web application. There are other benefits of modelling. We can use the fact that computers are good at manipulating signs to create tools to assist in the Web development process. For example, if we can represent the structure of a Web site as a graph, we can develop a software module to read the graph and generate the physical menu to be displayed on the website. This paper presents a set of aspects that we discovered by modelling a large number of Web applications, that can be used to create a comprehensive conceptual model of a Web application that most application domain users can relate to. These aspects have minimal coupling, and can be easily mapped onto an extended MVC architecture. Thus each aspect can be changed with negligible impact on other implemented aspects. Such an approach can support co-evolution.

2 Web Application Modelling Approaches The concept for a web application originates in an application domain. Firstly, we need to create a conceptual model of the web application using concepts belonging to the application domain. Such a model can be used to verify whether the proposed application meets the requirements of the application as originally conceptualised. Once we establish the conceptual model, we then need to develop a logical architecture model using concepts in an implementation domain. In the computer domain (the web domain is a subset of the computer domain, based on thin client-server architecture) these concepts could be an access control module, view generator, workflow engine, object or data model etc. which can be implemented using technology available in the computer domain. Once a suitable implementation platform and technology is selected, we need to develop a physical architecture model using concepts such as algorithms, flow charts and database schemas to realise the concepts used for the logical architecture model. From the physical architecture model the specific artefacts can be created as programme files and databases. The Object Management Group (OMG) has proposed an approach known as Model Driven Architecture [4] or Model Driven Development (MDD), where the above-described process is viewed as a series of model transformations. In MDD, the application is first modelled based on business requirements, independent of the implementation technology at the computation-independent level (CIM). These models

Aspect Based Conceptual Modelling of Web Applications

125

are then transformed into platform-independent analysis and design models (PIMs). Implementation platform-specific models (PSMs) are then created and the application code is generated for the targeted implementation platform using model compilers [5]. The main aim of the MDA and MDD approaches is to make it easy to implement the application in different technologies by developing automated techniques for model transformation and compilation to generate the application for various implementation platforms using these same high-level models [5]. Research emphasis has focused on developing various model transformation and compilation techniques, rather than how to create conceptual level models that can be used to verify whether application domain requirements have been properly understood, or what changes need to be done to the implemented application due to co-evolution. The relationship among different levels of abstraction in the generic modelling approach and the MDA approach is shown in Table 1. Table 1. Relationship among Domains and Abstraction Levels in different development approaches

Many researchers have proposed other ways to model web applications or some aspects of web applications [6-11]. A comparison of these methods can be found in [12] which has grouped these Web application modelling methods into four categories, detailed below:

• Data driven, based on entity relationship models such as Relationship Management Methodology –RMM, Hera, Web Modelling Language (WebML) [9].

• Hypertext-based, such as Hypertext Design Models (HDM), HDM-lite, Web site design method (WSDM)

• Object-oriented methods such as Object Oriented Hypermedia design methods •

(OOHDM), UML based Web Engineering (UWE) [10], Objected Oriented web solutions (OOWS), Object oriented Hypermedia (OO-H) Software-oriented methods such as Web Application Extension (WAE)

All these approaches aim to accurately capture requirements from the application domain and design modules or sub-systems at the logical level of the implementation domain using generic computer and web concepts. Once an implementation platform and technology is decided upon, further details are added to theses models so that the required artifacts can be created. These approaches have provided valuable insights into how a web application can be modelled using implementation domain concepts such that it is easy to implement the model.

126

A. Ginige

As can be seen from above broad categorisations, different web modelling approaches have mainly looked at the data or object model and hypertext model aspects of a web application. For example, people have attempted to model workflow as hypertext models [10] which overly complicates the model. It is true that non-linear navigation within a document (navigation links) as well as accessing different actions in a workflow implementation (process links) are both implemented using hyperlink tags (ie. ). At a conceptual level however, these are two different concepts. In the first instance the same person clicks on a link to access a different part of the information or to retrieve some additional information; in the workflow instance different people use hyperlinks to access a form to perform a task. Trying to model these two different concepts in the same way at a conceptual level overly complicates the conceptual model. As can be seen from the above discussion, existing modelling methods are mainly focused on creating a logical model or a logical architecture based on some conceptual model of an application or set of requirements. These are not aimed at creating a conceptual model that application domain users can easily relate to in terms of the application domain concepts that have been used to create the model and thereby provide feedback to eliminate any errors in the model. Thus it is useful to identify a set of aspects that will assist us to model a Web application at a conceptual level based on application domain concepts. For many years researchers have studied issues related to the conceptual modelling of data, as the majority of early, large and complex applications such as payroll systems, accounting packages etc. were predominantly data driven. Unlike data or object models, web applications incorporate many other aspects such as hypertext, navigation, access control, personalisation, and process automation. Thus a conceptual model of a web application needs to incorporate all these aspects in addition to the data model. It should also be possible to map selected aspects to represent concepts associated with a Web application on to a logical architecture to create the physical application. By integrating different aspects to form the overall application, and by keeping the aspects sufficiently independent or by reducing coupling wherever possible, each aspect can be changed in line with evolving organisational needs without affecting other aspects of the implemented application.

3 Aspect Based Modelling Aspect-based modelling refers to selecting a set of aspects that are rich enough and with minimum coupling to fully capture the requirements using application domain concepts, which can then be mapped onto implementation domain concepts such as an authentication subsystem, view generator, data model, hypertext models etc. By analysing many different types of websites we have identified following aspects as the starting point as these are visible on a website to the application domain users.


Aspect Overall Presentation

Description Each web site normally has a distinct layout and colour scheme. The overall layout will typically consist of a header, main menu, an area to display specific contents and a footer.

Primary Navigation

This provides a primary means of accessing various sections of the Website, typically using a menu displayed vertically on the left-hand side of the website or horizontally at the top. An unstructured or structured search mechanism is another way to provide this primary navigation. On a website one can identify four types of pages:

Page Composition

127

Examples

W eb Sites

• Information pages consisting of hypertext and hypermedia

• Forms

for inputting information to the Web application to perform a task

• Index pages to accessing other types of pages

• Pages

Secondary Navigation

Access Control

which are a combination of information, forms and indexes Each type of page can have different types of links to access related information or to perform a task such as submitting a form or uploading a file. Access control specifies the relationships between users and pages, such as what information users can view or what actions they can perform.

All users can view home page. Only administrator can create new users.

128

A. Ginige

Personalisation

For a given URL the information presented to the user and how this information is presented can be customised so that each user receives a personalised page based on the context.

Presentation = f1(user, context) Information = f2(user, context)

Though it is not difficult for users to specify the overall presentation and primary navigation structure for a web application, it is a tedious task to specify the composition of each page as well as secondary navigation links or buttons required for each of the pages, especially for a web application with a large number of pages. Thus we need a higher-level model from which we can drive the composition and secondary navigation links and buttons for each page automatically. To arrive at a suitable high-level model we first need to identify the different types of web applications, as each type of application needs to be modelled differently.

4 Models for Different Types of Web Applications Today we tend to use web applications to provide information to the user, or support the information flow associated with performing a business process. Web applications that provide information to the user are called information-centric web applications and web applications that support business processes are called process-centric web applications. Often a complex Web application will have both these subtypes. 4.1 Information-Centric Web Applications The focus of this type of application is to present large amounts of information to the user in an effective way. Websites that provide news, travel information or product information are examples of Information-centric web applications. An important feature of these applications is that at no time can users modify the information stored in the data repositories. The information can come from one or more data repositories in one or many computers stored as HTML or XML files or in databases. The emphasis is on how to compose the web pages and assist users in navigating from page to page in an effective manner. At the basic level these types of web applications can be modelled as page views composed of information from different information sources as shown in Figure 1. Thus by specifying a set of information sources and how information from these sources is combined to create different pages we can model basic information-centric web applications. Often there are secondary navigation links on these pages. If there are only a few information pages then the secondary navigation links can be explicitly specified. If there are a large number of pages however, we need to specify some rules to automatically derive these links. For example, if the page is a product catalogue then we can have a rule specifying a hyperlink from the product name to an image of the


129

product. Another example of specifying secondary navigation link is to have a glossary and a rule which states that if the user on any page clicks on a word described in the glossary, this description should appear in a pop-up window. During the implementation phase developers need to create a mechanism to insert the appropriate hyperlinks when rendering a page during runtime. In such an implementation, administrators of the system can keep adding new terms to the glossary without worrying about how to create the necessary secondary navigation links.

Fig. 1. Basic Conceptual model of an Information Centric Web Application

Thus we can model an information-centric web application at a conceptual level by specifying the various data sources, how information from these sources is combined to compose different pages and a set of rules to derive the secondary navigation links. This is known as a hypertext model. Table 2 shows essential and optional aspects required to model an Information-Centric Web application. Table 2. Aspects of Hypertext Model

Aspect Data or Information sources Page Composition model

Secondary Navigation Model Optional Access Control Model

Modelling Method Object diagrams, database schema or Smart Business Object Modelling Language (SBOML)[11]. Set of rules specifying information sources and the object instances to be shown on each page or page composition diagrams as used in WebML[9] Set of rules specifying how secondary navigation links should be created or using WebML[9] notations. Set of rules specifying web pages that each user can access. If there are many users it is better to assign users to groups or roles and specify what web pages each group or role can access.

130

A. Ginige

4.2 Process-Centric Web Applications The aim of process-centric web applications is to assist in managing the flow of information required to support a business process. In the field of software engineering it is well understood how to model such applications as a set of use cases [13] or tasks. A conceptual model for such an application is a business object being modified by different users who perform a task or an action through a form interface as shown in Figure 2. Thus a Process-Centric web application model should contain an object or data model, an action model to specify a sequence of interfaces required to perform an action (or a use case), an interface model to specify details of each interface, and an access control model to specify the actor who can perform the action. An action model specifies the interaction between a user and the system required to complete an action. This could be a user selecting a set of books on a screen that they want to purchase. The system then provides a second screen showing the total amount of the order and payment options. When the user selects a payment option the system provides a third screen to enter the relevant payment details, such as their credit card number. The system then provides the penultimate screen for the user to verify that all the details are correct before processing the order and at the end provides a confirmation screen. The interface model specifies what attributes of the object are to be shown on each of the screens and whether each of the displayed attributes are read-only, or whether the user can edit or enter new values. When a user logs in, we can determine what actions the user can perform from the access control model. From this information we can generate a personalised primary navigation model for the logged-in user to access the functions to perform these actions. A variation on the above model is where it is necessary to specify the order in which the business object needs to be populated, such as an employee in an organisation applying for leave using a web-based application. This process can be modelled as an employee through a form interface partially populating an instance of a leave object. A link is then provided to employee’s manager to view the information provided by the employee and decide whether to approve or reject the leave request. This decision (and any explanatory comments) can be recorded in the leave object. A link is then provided to an officer in the Human Resource division to process the leave application. This person now can look at the information stored in the leave object and process the information accordingly. Thus to support a process of this nature we need a sequence of actions (rather than a set of actions) also known as a workflow. Therefore, in addition to the above-mentioned models we also need a workflow model. From time to time various managers and senior executives may like to receive summary reports detailing who is on leave at a specific time or how many employees have taken leave in the last six months etc. Thus these applications, in addition to form interfaces to perform actions, should also provide various summary reports to meet the organisation’s needs. These reports can be modelled as forms with read-only access to data. There is no need for a separate model for reports, as the interface model used for forms can also be used for reports.


Customers

Managers

Employee

131

Managers

Data Repository

Data Repository

Supervisor

CEO

Sales

CEO

Fig. 2. Model of a Process-Centric Web Application

Human Resource

Fig. 3. Process-Centric Web Application with a workflow

The same pattern of a form being routed based on business rules of the leave processing application can be applied for many other business applications such as purchase order processing, travel applications etc. Thus the conceptual model for such applications is a business object being populated by a sequence of actions via form interfaces as shown in Figure 3. Using this conceptual model we can generate a range of process-centric web applications by specifying the object attributes, actions and related interfaces to perform the actions, people who can perform the specific actions, and the sequence in which actions should take place. Table 3 shows the essential and optional aspects required to model a ProcessCentric Web application. Table 3. Aspects of Process Model

Aspect Data or Information Object Action Model Interface Model

Access Control Model Optional Workflow Model

Modelling Method Object diagrams, database schema or Smart Business Object Modelling Language (SBOML)[11]. Sequence of interactions between a user and the system required to perform an Action. This can be modelled using UML interaction diagram. This can be modelled as a table. Each row represents an attribute of the information object. Each column represents an interface. Each cell specifies on the corresponding interface whether the attribute is displayed or not and if displayed what CRUD (Create, Read, Update, Delete) operations can be performed on the attribute. Set of rules specifying actions each user can perform. If there are many users it is better to assign users to groups or roles and specify what actions each group or role can perform. This can be specified as a state table. From this information an index page can be created to provide access to pending workflow tasks.

132

A. Ginige

We can make use of the above-described hypertext model and process model to derive page composition, secondary navigation and access control aspects of the conceptual model as shown in Figure 4. For a specific URL a user can get a web page that is personalised in terms of its presentation and information content. For the same URL a different user will get different information. This can be specified as a set of rules. Some rules for Personalisation can be derived from access control specification. For example, based on information pages and actions the user has access to, we can create a personalised primary navigation menu for each user when they login.

Fig. 4. Aspects to be modelled to create a conceptual model for a Web Application

5 Mapping Aspects to MVC Architecture The Model View Controller architecture pattern was first described in 1979 by Trygve Reenskaug [14]. The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. We extended the Model to include the access control model, process model and the hypertext model. The Controller module implements the access control rules specified in the access control model. The rules in the access control model are also used to generate a personalised primary navigation menu for logged in users. The generation of views was done using a set of templates. Figure 5 shows the extended MVC architecture that we used to map the aspects in the conceptual model of the web application. The numbers in this figure show the sequence in which a user request is processed. We have successfully implemented this architecture and a set of tools to create some of the models using the CBEADS framework [2, 3, 11, 15, 16].


133

Fig. 5. Extended MVC architecture used map aspects in the Conceptual Model

6 Conclusions We have presented an approach to create a conceptual model of a Web application using a set of aspects that are well understood by people at the application domain who will be using the application. The aspects that we identified are Overall Presentation, Primary Navigation, Hypertext Models, Process Models and Personalisation Models. We have used this aspect-based conceptual modelling approach to develop some large, complex web applications [17].We have found that this set of conceptually nonoverlapping aspects greatly simplify the modelling task. We also observed that end users found it easy to relate to these aspects. We also showed that these models can be mapped to an extended MVC architecture pattern to create the logical architecture of the system. As each aspect is mapped to a specific logical architectural unit, any changes to the models can easily be incorporated into the implemented system thus supporting co-evolution. Thus the development of an aspect-based conceptual model of a web application that users can easily relate to and provide feedback on can greatly assist the development of web applications. At present we are investigating ways of automatically generating the required artifacts to implement a web application from an aspect-based conceptual model.

References 1. Costabile, M.F., Fogli, D., Marcante, A.: Supporting Interaction and Co-evolution of Users and Systems. In: Advanced Visual Interfaces -AVI (2006) 2. Ginige, A.: Designing Web Applications to Support Co-Evolution. In: 2nd International Conference on Web Engineering and Applications 2007, Narosa Publishing House, Bhubaneshwar, India (2007)

134

A. Ginige

3. Ginige, A., De Silva, B.: CBEADS©: A framework to support Meta-Design Paradigm. In: 12th International Conference on Human-Computer Interaction (HCII 2007), Springer, Beijing, P.R. China (2007) 4. Soley, R.: Model Driven Architecture. Object Management Group (2000) 5. Koch, N., Zhang, G., Escalona, M.J.: Model Transformation from Requirements to Web System Design. In: International Conference on Web Engineering (ICWE 2006), ACM Press, Palo Alto, California (2006) 6. Fratenali, P., Paolini, P.: A conceptual model and a tool environment for developing more scalable and dynamic Web applications. In: Schek, H.-J., Saltor, F., Ramos, I., Alonso, G. (eds.) EDBT 1998. LNCS, vol. 1377, Springer, Heidelberg (1998) 7. Schewe, K.-D., Thalheim, B., Zlatkin, S.: Modelling and Stories in Web Information System. In: Information Systems Technology and its Applications (ISTA), Salt Lake Ciy, Utah, USA (2004) 8. Schwabe, D., Rossi, G., Barbosa, S.D.J.: Systematic hypermedia application design with OOHDM. In: Seventh ACM conference on Hypertext, ACM Press, Bethesda, Maryland, United States (1996) 9. Ceri, S., Fratenali, P., Bongio, A.: Web Modelling Language (WebML): A Modelling language for designing Web sites. In: WWW9 Conference, Amsterdam (2000) 10. Koch, N., Kraus, A.: Power of UML-based Web Engineering. In: Second International Workshop on Web-oriented Software Technology (IWWOST 2002), Málaga, Spain (2002) 11. Liang, X., Ginige, A.: Smart Business Objects: A new Approach to Model Business Objects for Web Applications. In: 1st International Conference on Software and Data Technologies, Setubal, Portugal (2006) 12. Kappel, G., et al.: Web Engineering - Systematic Development of Web Applications. Wiley, Chichester (2006) 13. Rumbaugh, J., Jacobson, I., Booch, G.: The Unified Modelling Language Reference Manual. Addison-Wesley, Reading (1999) 14. Reenskaug, T.M.H.: Model, View, Controller Pattern (1979), http://heim.ifi. uio.no/~trygver/themes/mvc/mvc-index.html 15. Ginige, A., et al.: Smart Tools to support Meta-Design Paradigm for Developing Web based Business Applications. In: Baresi, L., Fraternali, P., Houben, G.-J. (eds.) ICWE 2007. LNCS, vol. 4607, Springer, Heidelberg (2007) 16. Liang, X., Ginige, A.: Enabling an End-User driven Approach for Managing Evolving User Interfaces in Web Business Applications. In: 2nd International Conference on Software and Data Technologies - ICSOFT 2007, Barcelona, Spain (2007) 17. Ginige, J.A., Ginige, A.: Challenges and Solutions in Process Automation in Tertiary Education Institutes: An Australian Case Study. In: 6th IEEE International Conference on Computer and Information Science (ICIS 2007), Melbourne, Australia (2007)