Sujetos de la tenencia

After the addition of indices as described in the last section, menus are added to the navi- gation model to organize the outgoing links of navigation classes. A transformation auto- matically adds a menu to each navigation class with outgoing links. The resulting naviga- tion model can then be manually refined optionally.

4.4.4.1

Transformation AddMenus

The transformation AddMenus depicted in Figure 40 automatically adds menus to the navi-

gation model. It comprises two transformation rules which are outlined below and detailed in B.3.6.

NavigationClass2NavigationClassWithMenu NavigationProperty2MenuProperty

AddMenus

Navigation Model With Added Menus Manually Refined

Navigation Model With Added Indices

NavigationClass2NavigationClassWithMenu NavigationProperty2MenuProperty

AddMenus

Navigation Model With Added Menus Manually Refined

Navigation Model With Added Indices

Figure 40. Transformation AddMenus

The automatically generated menus for the project and the user project navigation classes are depicted in Figure 41. The inheritance relationship between a user project and a project was mapped to an inheritance relationship between the corresponding menus. Thus, the user project menu inherits the navigation link to the project manager from the project menu.

<<navigation class>> V alida tionP roject <<navigation class>> Projec tManager << navigation class>> Use rProjec t << navigation class>> Project <<menu>> ProjectMenu <<menu>> UserProjectMenu

<<na vig ation link>> -pr ojectManager

1

<<navi gatio n lin k>> -validationP roject

0..1 1

1

Figure 41. Navigation model with added menus derived by transformation AddMenus

Rule NavigationClass2NavigationClassWithMenu

The rule NavigationClass2NavigationClassWithMenu creates a menu for each navigation

class with at least one outgoing link, or if for the corresponding content class at least one Web process use case is defined, because this menu is then required for the integration of processes as presented in 4.5.1. All outgoing links are moved to the menu node and the menu node is composed with the original navigation class. In comparison to the rule im- plementation in B.3.6 the following details have been omitted below: target bindings that are not relevant for understanding the rule, and targets for mapping inheritance between navigation classes to inheritance between menus.

rule NavigationClass2NavigationClassWithMenu {

from nc : UWE!NavigationClass ( nc.oclIsTypeOf( UWE!NavigationClass ) and ( nc.ownedAttribute->select( p |

not p.isComposite and p.association.oclIsKindOf( UWE!Link ) and not p.type.oclIsTypeOf( UWE!Menu ) )->size() > 0

Model Driven Software Engineering for Web Applications

or nc.contentClass.useCase->exists( uc | uc.oclIsKindOf( UWE!WebProcess ) ) ) using

{

menuNps : Sequence( UWE!Property ) = nc.ownedAttribute->select( p | not p.isComposite and p.association.oclIsKindOf( UWE!Link ) and not p.type.oclIsTypeOf( UWE!Menu ) );

otherNps : Sequence( UWE!Property ) = nc.ownedAttribute - menuNps; }

to tnc : UWE!NavigationClass (

ownedAttribute <- otherNps->including( apt ), …

),

menu : UWE!Menu (

name <- nc.name + 'Menu', ownedAttribute <- menuNps, contentClass <- nc.contentClass, … ), a : UWE!Association ( … ), aps : UWE!Property ( association <- a, owningAssociation <- a, type <- nc, … ), apt : UWE!NavigationProperty ( association <- a, class_ <- nc, type <- menu, aggregation <- #composite, isComposite <- true, … ), … } 113

Rule NavigationProperty2MenuProperty

This rule converts all properties of a navigation class (exact type) which are part of a link to the corresponding properties of the links from the menu generated by the rule Naviga- tionClass2NavigationClassWithMenu. In comparison to the rule implementation in B.3.6

target bindings that are not relevant for understanding the rule have been omitted.

rule NavigationProperty2MenuProperty {

from np : UWE!NavigationProperty ( np.class_.oclIsTypeOf( UWE!NavigationClass ) and np.type.oclIsKindOf( UWE!Node ) and not np.type.oclIsTypeOf( UWE!Menu ) and not np.isComposite and np.association.oclIsKindOf( UWE!Link ) )

to tnp : UWE!NavigationProperty (

class_ <- thisModule.resolveTemp( np.class_, 'menu' ), …

) }

4.4.4.2

Manual Refinement

The automatically derived navigation model with added menus can optionally be refined by the following activities:

• Definition of new menus in order to further structure outgoing links • Renaming of menus

The automatically derived navigation model for the running example has not been manu- ally refined.

4.5 Process

The navigation model of a Web application represents the static information structure ac- cessible to a user of the system. Processes on the other hand represent the dynamic aspects of a Web application.

Process modeling (also called task modeling) stems from the Human Computer Interaction (HCI) field [Harmelen01]. A process is composed of one or more sub processes and/or ac-

Model Driven Software Engineering for Web Applications

tions that a user may perform to achieve a goal. A goal represents a desired change in the state of the system and may be realized by formulating a plan composed of processes and then performing those processes. Here the concept process is considered in a broader sense by taking into account actions performed by the system and actions performed by the user, see 4.5.2.

Different UML notations have been proposed for process modeling. Wisdom is a UML extension that proposes the use of a set of stereotyped classes that make the notation not very intuitive [Nunes00]. Markopoulos et al. make two different proposals: a UML exten- sion of use cases [Markopoulos00] and another one based on statecharts and activity dia- grams [Markopoulos02]. As already sketched in previous works of the author process modeling as proposed here is based on UML activities [Koch03a], [Koch04a]. Activities in general can be considered as “roadmaps” of system functional behavior [Lieberman01], or, especially for Web applications we may speak of “roadmaps” of user interaction with the system. For the case that the content model is implemented by Web services the process model represents a choreography of Web services to achieve a desired behavior.

In contrast to other Web methodologies which realize processes with nodes and links as part of the navigation model, such as for example OO-H [Cachero02] or WebML [Ceri02], in this work processes are treated as an additional concern and are represented by a full- fledged model. Processes in OOWS [Fons03] are captured in the business process model using an extended version of the Business Process Modeling Notation (BPMN) [OMG06c] and a corresponding extended metamodel for business modeling. BPMN stems from the B2B (business-to-business) field and is similar (but not identical) to UML activities. In contrast to this work also manual tasks are considered in the process model, i.e. tasks that are manually carried out by humans and not automatically by the system by invoking op- erations or Web services. However, processes in OOWS are not represented by a dedicated model, but distributed over the BPMN process model and the navigation model. The latter contains a lower level view of the process model, where the constructs of the process model are resolved into navigation constructs. W2000 [Baresi06] follows a similar ap- proach for process modeling as presented here although operations are defined separately from the content model. It is suggested that either activity diagrams or collaboration dia- grams are used to define the workflow of processes, but it is left unclear how these proc- esses can be executed or translated to code. In contrast, the approach of this work allows a detailed specification of workflows by using UML 2 activities and it is clearly defined how processes are integrated in the navigation model.

The expressiveness of process modeling presented here is limited by the subset of the UML modeling elements applicable for activities which are currently supported (see

4.5.2.1). Therefore, this approach can be extended to support all the remaining UML mod- eling elements such as for example exceptions, events or structured activity nodes. Addi- tionally, specialized action types could be supported, for example for the direct manipula- tion of objects, such as reading or writing attributes or associations. Although this type of actions is considered in the UML metamodel, no notation is given and tool support does not exist, and therefore these types of actions are not considered in this work.

Process modeling comprises three parts which are presented in the following sections: process integration for integrating the invocation of processes in the navigation model, process data representing data accessed by processes and process flow representing the dy- namic process flow itself which comprises the invocation of operations from the content model. Process data and process flow are developed concurrently, hence they are presented together. Model transformations for successively deriving the process model from the un- derlying models are given in each section.