4 PLATFORM INDEPENDENT ANALYSIS AND DESIGN
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.
91
4.3.2 Transformation Requirements2Content
The transformation Requirements2Content depicted in Figure 28 automatically derives a content model from the requirements model, i.e. the analysis content model and the Web use case model. It comprises two transformation rules which are outlined below and de-tailed in B.3.1. The well-formedness of the input model is checked before the transforma-tion is executed, see 4.1.1. Further, for each rule transformatransforma-tion traces are generated as de-scribed in 4.1.2.
ContentClass2ContentClassWithOperations SimpleProcess2Operation
Requirements2Content Analysis
Content Model
Content Model Web Use Case
Model Requirements Model
ContentClass2ContentClassWithOperations SimpleProcess2Operation
Requirements2Content Analysis
Content Model
Content Model Web Use Case
Model Requirements Model
Figure 28. Transformation Requirements2Content
The resulting content model for the analysis content model depicted in Figure 25 and the Web use case model for the project manager depicted in Figure 26 is shown in Figure 29.
In comparison to the analysis content model the operation removeProject for the simple process use case Remove Project has been added. The other Web use case types affect only the automatically derived models at later steps during the semi-automatic construction of the design models: navigation use cases determine the navigation model, while all Web process use case types (simple processes, complex processes and edit processes) are re-quired for the construction of the process model.
Model Driven Software Engineering for Web Applications
ValidationProjec t UserProject
ProjectManager +removeProje ct()
P roje ct -projects
*
-pro jectManager 1
-name -descrip tion
-validationPro ject 0..1
Figure 29. Content model derived by transformation Requirements2Content
Rule ContentClass2ContentClassWithOperations
The rule ContentClass2ContentClassWithOperations maps each content class to a content class with added operations created by the second rule SimpleProcess2Operation. Note that the ATL expression
thisModule.resolveTemp( sp, ‘op’ )
is necessary to reference a specific target element op of the rule SimpleProcess2Operation that matches the source element sp, see also [ATL06a]. The effect of these rules for a part of the running example is depicted in Figure 30. In comparison to the rule implementation in B.3.1 target bindings that are not relevant for understanding the rule have been omitted.
ProjectMana ger + remove Project() ProjectManager
<<simple process>>
Rem ove Project
ProjectMana ger + remove Project() ProjectManager
<<simple process>>
Rem ove Project ProjectManager
<<simple process>>
Rem ove Project
Figure 30. Illustration of the rules for adding operations
rule ContentClass2ContentClassWithOperations {
from c : UWE!Class ( c.oclIsTypeOf( UWE!Class ) )
93
to tc : UWE!Class (
ownedOperation <- c.ownedOperation->union(
c.useCase->select( uc | uc.oclIsKindOf( UWE!SimpleProcess ) )->
collect( sp | thisModule.resolveTemp( sp, ‘op’ ) ) ), …
) }
Rule SimpleProcess2Operation
For each simple process in the requirements model an operation is generated. The name of the operation is calculated by discarding all spaces from the name of the simple process and converting the first character to a lower case representation. The functions regexRe-placeAll (for replacing substrings by using regular expressions) and firstToLower are pro-vided by ATL [ATL06a]. An auxiliary rule Type2ReturnParameter (detailed in B.3.1) is used to generate the return parameter of the operation.
rule SimpleProcess2Operation {
from sp : UWE!SimpleProcess
to tsp : UWE!SimpleProcess ( … ), -- target for copying source element op : UWE!Operation
(
name <- sp.name.regexReplaceAll( ' ', '' ).firstToLower(), type <- sp.target,
ownedParameter <- if sp.target.oclIsUndefined() then Sequence {} else Sequence { thisModule.Type2ReturnParameter( sp.target ) } endif )
}
4.3.3 Manual Refinement
The automatically derived content model has to be manually refined by the developer to add on the one hand model properties that were not present in the analysis content model.
On the other hand the developer can enrich the content model by model elements which were not relevant at the requirements level.
The following actions are mandatory for a valid content model for the further steps in the model driven process if the corresponding information is not yet available in the analysis content model:
Model Driven Software Engineering for Web Applications
• Specify the types for all attributes, this may require the definition of new types, such as for example enumeration types
• Specify the multiplicities for all properties
• Specify which ends of an association are navigable
• Specify names for all navigable (in terms of UML properties) association ends Other actions, which have an influence on the models in the following steps, are optional.
Optional means that the model is valid without any of these actions:
• Add additional classes, attributes, operations and associations
• Specify if a property is ordered for all multi-valued ends of an association
• Add inheritance and abstract classes
• Add parameters and return types to operations. Note that for operations which are used in simple processes, parameters correspond to the input of an operation call and the return type to the output of an operation call in the workflow of the process.
The automatically derived design content model for the running example was manually refined by specifying attribute types and adding additional attributes such as the id attrib-ute. The association end projects has been declared as ordered. A parameter project has been added to the operation removeProject to specify that the user first has to enter the pro-ject he wants to remove. The resulting content model is depicted in Figure 31. The detailed content model for the case study is presented in 6.1.2.
95
ProjectManager +remove Project( project : P roject )
Project {ordered}
-projects
*
-projectMan ager 1
-name : String -descripti on : S trin g -id : String
ValidationProjec t UserProject -validationPro ject
0..1
Figure 31. Refined design content model