Metamodel

The modeling elements of regular UML class diagrams without operations are used for the analysis content model to capture the structure and data of a Web application. On the other hand specializations of UML use cases are used for the Web use case model with the

ab-85

stract metaclass WebUseCase as super type of Web use case types as depicted in Figure 24.

The context for the functionality of a Web use case is represented by the derived attribute contentClass. The term context as used here refers to the abstract location where the user of the Web application is currently located. The context is represented by the content classes. Within a given context the user can perform certain functionalities represented by the Web use cases. The optional change of the context when executing a web use case is represented by the derived attribute target. The target attribute is represented by an asso-ciation between a Web use case and a content class. Two concrete Web use case types are distinguished: Navigation and WebProcess.

Navigation use cases represent navigation functionality, i.e. the static functionality of a Web application, in a very abstract way. Static means that the state of the content objects does not change when executing a navigation use case. The only navigational detail that can be expressed relevant at analysis level is the target content class that should be reach-able by navigation, represented by the derived attribute target. A constraint ensures that there is an association defined in the analysis content model between the associated content class of the use case and the target content class. Additional information such as direction and multiplicities is not relevant for the analysis content model.

Dynamic functionality of Web applications is represented by the WebProcess use case type. The execution of a Web process typically changes the state of the system by execut-ing actions on the content model. The WebProcess use case type represents the general case of a Web process with an arbitrary workflow. Two specialized Web process types are further defined, edit use cases and simple processes, in order to treat some common tionality of Web applications especially. Edit use cases represent data modification func-tionality of the associated content class. Simple process use cases represent the atomic in-vocation of behavior of the associated content class. A Web process, which is neither an edit use case nor a simple process is also called a complex process. A simple process al-ways implicitly defines a trivial workflow containing an action that invokes the corre-sponding behavior. The special treatment of simple processes allows the automatic genera-tion of a corresponding operagenera-tion in the content model and the corresponding trivial work-flow in the process model in the following steps of the methodology. If the execution of a Web process changes the context, i.e. the context shall change from the content class of the Web process to another content class resulting from the execution of the Web process, then this has to be represented by the attribute target.

Note that the create, retrieve, update and delete (CRUD) operations found in data-intensive Web approaches such as for example WebML [Ceri02] are realized in this work by the more general Web processes: create and delete operations are realized by simple processes

Model Driven Software Engineering for Web Applications

and update operations are realized by edit processes. The retrieve operation does not have to be realized explicitly.

SimpleProcess W ebUseCase

Classifier

Class Class

Navigation WebProcess

Edit UseCase

* +/target

0..1 *

+/contentClass 1 +useCase

*

+subject

*

Figure 24. Metamodel for requirements modeling

Derived Attributes

The derived attribute contentClass of a Web use case is defined to be exactly the one ele-ment from the subject collection of the use case which has the exact type Class, see con-straint WebUseCaseContentClass.

context WebUseCase def : contentClass : Class = self.subject->any( c | c.oclIsTypeOf( Class ) )

If an association between a Web use case and a content class exists, then the derived at-tribute target of this Web use case is defined to be this content class, see also constraint WebUseCaseTarget. If no such association exists then the target is undefined.

context WebUseCase def : target : Class = Association.allInstances()->

select( a | a.endType->size() = 2 and a.endType->includes( self ) )->

collect( a | a.endType->excluding( self )->first() )->any( t | t.oclIsTypeOf( Class ) )

Constraints

A Web use case must have exactly one subject of type Class.

87

context WebUseCase inv WebUseCaseContentClass : self.subject->one( c | c.oclIsTypeOf( Class ) )

At most one association between a Web use case and a content class may exists.

context WebUseCase inv WebUseCaseTarget : Association.allInstances()->

select( a | a.endType->size() = 2 and a.endType->includes( self ) )->

collect( a | a.endType->excluding( self )->first() )->

select( t | t.oclIsTypeOf( Class ) )->size() <= 1

For a navigation use case a target content class has to be defined and a corresponding owned attribute has to exists for the corresponding content class.

context Navigation inv NavigationTarget :

self.target->notEmpty() and self.contentClass.ownedAttribute->exists( p | p.type = self.target )

For an edit use case no target content class must be defined.

context Edit inv EditTarget : self.target->isEmpty()

Notation

The UML notation proposes that a use case should visually be located inside its subjects, i.e. its content class, although not all UML modeling tools support the visual nesting of use cases inside classes. In order to avoid name collisions, it is suggested that a content class owns its Web use cases. The target of a Web use case is notated as an association between the use case and the corresponding content class. For the definition of the corresponding UML profile see A.1.