Web Use Cases: Example

Web use cases, i.e. specialized UML use cases, are used for modeling the required func- tionality of a Web application. For this purpose, for each class from the analysis content model a use case diagram is constructed that comprises the analysis content class and all of the corresponding Web use cases which are placed inside the box representing the analysis content class.

The Web use cases for the project manager are depicted in Figure 26. The Web process

Add Project expresses that the user can add new projects. The Web process Add Project is

not a simple process because it requires a dedicated workflow in which we would like the user first to decide which kind of project he wants to add. Then he should enter exactly the information necessary for the selected kind of project. The target content class Project,

which is represented by an association between the Web process use case and the content class, specifies that after the completion of the process the resulting project is shown to the user. The simple process Remove Project expresses that the user can remove a project. The

navigation use case View Projects expresses that the user can navigate to the list of pro-

jects, represented by the association to the corresponding content class, i.e. the target of the navigation use case. For user projects, the user can navigate to the corresponding valida- tion project target and the user can edit the user project as depicted in Figure 27. All con- straints for the requirements model are fulfilled because each Web use case has exactly one analysis content class as subject. Further, no more than one association between a specific

Web use case and a content class exists. For each navigation use case a target is defined and a corresponding association exists in the analysis content model. Finally, for the edit use case a target is not defined.

ProjectManager <<simple process>> Remove Project <<web p rocess>> Add Project <<navigatio n>> View Projects ProjectManager DanubiaUs er Project Project

Figure 26. Use cases for content class ProjectManager

UserProject

<< navigation>> Vie w Validation Projec t

< <edit>> E dit User Project

V alidationProject ProjectManager

DanubiaUs er

Figure 27. Use cases for content class UserProject

4.3 Content

The objective of content modeling is to define the structural and behavioral aspects of the problem domain of a Web application. The structural aspects correspond to the information space of a Web application while the behavioral aspects correspond to the atomic units of

Model Driven Software Engineering for Web Applications

behavior, see below. Navigation and presentation aspects are not taken into account when constructing the content model.

Well-known object-oriented modeling activities, which are as well applied to traditional non-Web application development, are the foundation for content modeling, thus regular UML classes represent the problem domain of a Web application. In addition to static structural features (attributes and associations) which are referenced in the navigation model, the content model also comprises dynamic behavioral features (operations) which are referenced in the process model.

Content modeling is normally based on either entity relationship (ER) diagrams [Chen76] or object-oriented techniques using UML class diagrams. Data-intensive approaches such as WebML [Ceri02] or W2000 [Baresi06] originate from the field of database systems and are hence based on entity relationship diagrams for modeling the information space. How- ever, ER diagrams cannot be used to represent the behavioral properties of an application. Therefore, approaches based on ER diagrams have to define additional modeling elements for expressing the dynamic aspects of the problem domain. WebML for example intro- duces the concept of operations at the hypertext, i.e. navigation, level, thereby breaking up the separation of the content and the navigation concerns. Other approaches, including UWE, are based on object-oriented methods, and thus most of them use UML classes for content modeling in a very similar way as the approach presented in this work.

One limitation of this work is that behavior is modeled at the granularity of operation sig- natures. Thus, the implementation of operations themselves cannot be generated automati- cally but has to be either predefined by e.g. a Web service, or only implementation skele- tons can be generated, which then have to be completed by the developer. Possible ways of extending this approach by modeling executable behavior of operations are discussed in the conclusions chapter.

The content model is automatically derived from the requirements model by applying the transformation Requirements2Content presented in 4.3.2. The resulting default content

model has to be refined by the developer by adding additional classes, attributes, opera- tions, associations etc.

4.3.1 Metamodel

Content modeling does not require any additional constructs. Regular UML classes are used for content modeling in order to make content modeling as similar as possible to the modeling of traditional non-Web applications.