focus
model-driven development
Separation of Concerns in Model-Driven Development Vinay Kulkarni and Sreedhar Reddy, Tata Research Development and Design Centre
o facilitate traceability, reuse, and evolution, systems should be specified as compositions of clearly separated and separately specified concerns of interest. Customizing model-driven development environments—for example, to support different application design strategies—is difficult because they lack support for clear separation of concerns. Moreover, because we typically specify MDD systems in terms of models and code, we must address the issue of separation of concerns at
T
both the model and code levels.1 The Template abstraction we propose lets us model applications as hierarchical compositions of templates. We illustrate our composition process using a unified metamodel.
Model-driven development MDD aims to shift the focus of software development activity from coding to modeling. Application development starts with an abstract specification A, which is to be trans-
Model-driven development has improved productivity, quality, and platform independence, but it hasn’t been that successful in supporting reuse and system evolution. The proposed Template abstraction addresses this problem in an integrated way by dealing with separation of concerns at both the model and the code level. 64
IEEE SOFTWARE
Published by the IEEE Computer Society
formed into a concrete implementation C on a target architecture, as Figure 1a shows.2 The target architecture is usually layered, with each layer representing one view of the system. The modeling approach constructs A using different abstract views A1 … An, each defining a set of properties corresponding to the concern it models. A view, Ai, is an instance of a more general structure that we can represent as a (meta)model Mi, such as the user interaction model for sequences of user-system interactions, or an entity-relationship model for representing data. A is usually not available separately: We use it here to represent the composition of the views A1 … An. We can transform each Ai into Ci, with applicationlevel composition of C1 … Cn giving C the intended implementation of A. Instead of performing such a transformation for every 0740-7459/03/$17.00 © 2003 IEEE
M1
M2
A1
A2
...
A3
C1
C2
...
C3
M3
A
(a)
Figure 1. (a) Model-driven software development; (b) layered architecture of a typical business application.
Instance of Decomposes into Abstraction of
C
Unified metamodel
GUI metamodel
UML metamodel
instanceOf
instanceOf
GUI model
instanceOf
Functionality model
Database model
Class generator
GUI generator
(b)
Database metamodel
JSP
Java
application manually, we use Mi, of which Ai is an instance, and implement generic transformations at the model level. We can apply these transformations to all instances of Mi. Defining transformations at the level of Mi rather than Ai makes scaling up the method to handle large programs possible. For example, we can specify a transformation from a class diagram to Java classes and then apply this transformation to generate Java classes for any application. Figure 1b shows a typical business application modeled according to MDD. The application is implemented across three architecture layers—user interface, application functionality, and database—each on a different platform supporting different primitives. For example, user interface platforms such as Visual Basic provide windows and controls as implementation primitives. The application logic is implemented in a Java-like programming language with classes and methods as primitives, and the database layer is built in a relational database system using tables and columns. The three layers are then combined to get an implementation C.
Data manager generator
Oracle
C
Each layer must address several concerns, for example: ■
■ ■
The GUI layer must address a standard look and feel across screens, standard user interaction patterns, and the mapping of window controls to application classes. The functionality layer must address error handling and logging. The database layer must address concurrency, auditing, and locking.
Each concern should be specified in a modeling notation best suited for its expression. A UML extension might be suitable, as a profile or variant, where standard UML notations are inadequate.
Separation of concerns A parameterized package is a parametric model element that captures patterns of recurring structure, behavior, and constraints of models. We create parameterized packages using the package extension mechanism.3 When September/October 2003
IEEE SOFTWARE
65
parameter consistency * 1 2..* Model element Constraint 1 composedOf Template * member * Composite Template Leaf Template weavingSpec
1
1
1
1
1
transformationSpec
instantiationSpec 0..1 Weaving specification
0..1
0..1
0..1
Instantiation specification
0..1
Transformation specification
Context compositeTemplate : INV Self.member.parameter -> forall ( mp : ModelElement | self.parameter -> exists ( p | p = mp ))
Figure 2. The Template metamodel.
model elements are supplied as parameters to the package, the package creates a set of new model elements. Our Template abstraction uses parameterized package abstraction4 to address the separate specification and composition of model patterns, and aspect-oriented programming5 to address separation of concerns at the code level. Figure 2 shows the Template metamodel, which expresses how a concern specification is transformed into models and code. There are two kinds of Templates: a Leaf Template and a Composite Template. The Leaf Template’s instantiation specification specifies how to create concern-specific model elements, and its transformation specification specifies how the instantiated model is transformed into platform-specific code. The Composite Template’s instantiation specification specifies how model elements constructed in member Templates are merged (woven together); we have found that the merge-by-name scheme of model merging has worked well for our purposes. To specify transformations, you can use any modelaware transformation language; we used SpecL.6 The Template’s weaving specification specifies how the code generated by its member Templates is merged; a code-weaving specification language along the lines of Hyper/J7 has been sufficient for us. We compose applications by doing a postorder traversal of the Template hierarchy in three sequential steps: 1. Instantiation: stamps out models and merges them 2. Transformation: transforms models into code and generates weaving specifications for composing the generated code
66
IEEE SOFTWARE
h t t p : / / c o m p u t e r. o r g / s o f t w a r e
3. Weaving: composes the generated code fragments by processing the weaving specifications This process lets us specify applications as hierarchical compositions of Templates of interest.
An example Figure 3 shows a unified metamodel, based on Figure 1b, with persistent and auditable classes together with their table representations. (We can mark up a static UML model so that classes are independently persistent and auditable.) A persistent class has a representation as a database table. An auditable class records the history of its state changes. We generate a model’s persistent and auditable features from a static model consisting of classes and attributes, as defined in Figure 3. Figure 4 shows the Template model for this application. This example considers the functionality and data manager layers shown in Figure 1b that support the concerns of the Object-Relational Map, Audit, and Object Model Translation Templates. All Templates in this example take Class as the input parameter. Following are the Templates’ specifications.
Object-Relational Map This Template specifies an object-relational mapping strategy for a persistent class. Instantiation specification. For an input class Cl having its isPersistent property set to True, there should exist ■ ■ ■
A table T having the same name as the class Cl A key K having the same name as the class Cl A mapsTo association between T and Cl
Figure 3. A unified metamodel for the example.
column 1
* column
Column dataType mapsTo 1
key Key 1
Table 1
1
*
mapsTo 1 1 audit
1 Attribute isPrimary
1 1 attribute *
*
*
Class isPersistent isAuditable type
Operation
* 1 parameter *
1
Type
BasicType
operation 1
type 1
*
Parameter
Context Class : INV IsAuditable = true implies isPersistent = true and Self.mapsTo -> forAll ( t : Table | t.Column -> forAll( c : Column | self.attribute -> exists ( a : Attribute | a.mapsTo = c )) Context Table : INV Self.key -> forAll ( k : Key | k.column -> forAll ( c : Column | self.column -> exists ( c2 : Column | c = c2 )))
■ ■
A key association between T and K Create, Modify, Get, Delete, and Exists operations, with the class Cl having the operation association to each
For each attribute Attr of class Cl, there should exist ■
■ ■
A column Col having the same name as the attribute Attr and having a data type compatible with Attr’s type A column association between Col and T A column association between Col and K when the isPrimary property of attribute Attr is set to True
Transformation specification. For an input class Cl having its isPersistent property set to True, there should exist bodies of operations Cre-
Audit : Leaf Template
Audit This Template specifies how to maintain a persistent audit trail of state changes of instances of a persistent class. Each persistent class has a corresponding audit table having a column to store the time stamp of the state change operation, a column to store the preimage, and a column to store the postimage. Additionally, each persistent class has three methods: getImage gets the object’s current image, setPreImage sets the current image as the preimage in the audit table, and setPostImage sets the current image as the postimage in the audit table.
Attribute Handling : Leaf Template
member
Persistence : Composite Template
ate, Modify, Get, Delete, and Exists, generated by interpreting associations between class and table, table and key, and attribute and column.
Figure 4. Template model for a model-based code generator.
member member Model-to-Java : member Functionality : Composite Template Composite Template
member Object-Relational Map : Leaf Template
member Object Model Translation : Leaf Template
September/October 2003
IEEE SOFTWARE
67
Figure 5. The model after instantiation of the Persistent Template.
Ssn : Attribute
[O] Ssn : Column
Name : Attribute
[O] Name : Column mapsTo [O] Person : Table
[O] Person : Key
Person : Class audit
[A] Audit_Person : Table
[O] Create : Operation [A] timeStamp : Column [O] Modify : Operation [A] PreImage : Column [O] Delete : Operation [A] PostImage : Column [O] Get : Operation [O] Exists : Operation [A] GetImage : Operation [A] SetPreImage : Operation [A] SetPostImage: Operation
[O] Contribution of Object-Relational Map Template [A] Contribution of Audit Template
Object Model Translation This Template specifies, in its transformation specification, how the UML class model is translated into Java.
lowed by SetPreImage on one side of the bracket and with GetImage followed by SetPostImage on the other side of the bracket.
Functionality Attribute Handling This Template specifies an attribute-handling strategy for the input class. Each attribute of a class has an Accessor method to read the attribute and a Mutator method (when its isQuery property is set to False) to set the attribute.
Persistence This Composite Template specifies how to merge the instantiated models of the ObjectRelational Map and Audit Templates and how to weave the code they generate. Instantiation specification. This Template’s instantiation specification specifies merging of the models created by its member Templates using the merge-by-name strategy. Transformation specification. If the isPersistent property of the input class is set to True, a weaving specification is generated for bracketing the Modify method with GetImage fol68
IEEE SOFTWARE
h t t p : / / c o m p u t e r. o r g / s o f t w a r e
This Template’s instantiation specification specifies merging the models created by its member Templates using the merge-by-name strategy.
Model-to-Java This Template’s instantiation specification also specifies merging the models created by its member Templates using the merge-by-name strategy. As an example of the composition process, let’s look at a sample input class named Person. For want of space, we consider only the subtree rooted at the Persistence Template shown in Figure 4. Starting with a model containing a single persistent auditable class Person with attributes ssn and name, instantiation of the Object-Relational Map Template produces the table and operations marked “[O]” in Figure 5. Instantiating the Audit Template produces the table and operations marked “[A].” Figure 5 shows the contribution each Template
makes to the input class during the instantiation step. The transformation step follows the instantiation step. The Object-Relational Map Template generates method bodies for the Create, Modify, Delete, Get, and Exists operations, and the Audit Template generates method bodies for the GetImage, SetPreImage, and SetPostImage operations. The Persistence Template generates the following weaving specification: Bracket Person::Modify() Before GetImage(), SetPreImage() After GetImage(), SetPostImage()
Next comes the weaving step. Processing the weaving specification generated in the transformation step produces the following code: Person::Modify() { GetImage(); SetPreImage(); // Body of original Modify method GetImage(); SetPostImage(); }
Therefore, starting from an instance of Figure 3 consisting of classes and attributes, we can populate the rest of the model using a Template instantiation; we can generate operation bodies for database queries and so on using Template transformation. This proposed mechanism supports weaving, so we can separate out the Templates for dealing with persistence and auditing, apply them separately, and then merge the results to produce a completely populated model.
W
e and our colleagues used the approach presented here to reorganize a MDD environment.6,8 The reorganization facilitated easy customization and increased reuse across tool variants. Clear separation of concerns resulted in better traceability from requirements to implementation, leading to better change management. Using a higherlevel model-aware transformation language simplified tool maintenance and evolution. The proposed approach does not fully address the problem of composition correctness. Template constraints and type checking partly
About the Authors Vinay Kulkarni is a scientist at Tata Research Development and Design Centre. His re-
search interests include metamodeling, model-driven software development, distributed components, process programming, software engineering, and language processing. He received his master’s degree in electrical engineering from the Indian Institute of Technology, Madras. Contact him at Tata Research Development and Design Centre, 54 B, Hadapsar Industrial Estate, Hadapsar, Pune, 411 013, India;
[email protected].
Sreedhar Reddy is a scientist at Tata Research Development and Design Centre. His research interests include metamodeling, model-driven software development, distributed components, process programming, software engineering, and language processing. He received his masters degree in computer engineering from the Indian Institute of Technology, Kharagpur. Contact him at Tata Research Development and Design Centre, 54 B, Hadapsar Industrial Estate, Hadapsar, Pune, 411 013, India;
[email protected].
address the problem. Ensuring the correctness of Template composition still lies largely with the user; however, we are investigating approaches to enrich the Template abstraction with semantics to provide more control. We also plan to elevate transformation specifications to the model level to provide an even better handle on customizability and change management.9
References 1. P. Tarr et al., “N Degrees of Separation: Multi-Dimensional Separation of Concerns,” Proc. 21st Int’l Conf. Software Eng. (ICSE 99), IEEE CS Press, 1999, pp. 107–119. 2. A. Sreenivas, R. Venkatesh, and M. Joseph, “MetaModeling for Formal Software Development,” Computing: The Australian Theory Symp. (CATS 01), Electronic Notes in Theoretical Computer Science 42, Elsevier, 2001; www.elsevier.nl/gej-ng/31/29/23/68/22/ 62/entcs42002.pdf. 3. T. Clark, A. Evans, and S. Kent, “A Metamodel for Package Extension with Renaming,” Proc. 5th Int’l Conf. Unified Modeling Language (UML 02), LNCS 2,460, Springer-Verlag, 2002, pp. 305–320. 4. T. Clark, A. Evans, and S. Kent, “Aspect-Oriented Metamodelling,” to be published in Computer J., 2003, www.cs. kent.ac.uk/people/staff/sjhk/publications/CJ03/content.pdf. 5. G. Kiczales et al., “Aspect-Oriented Programming,” Proc. 11th European Conf. Object-Oriented Programming (ECOOP 97), LNCS 1,241, Springer-Verlag, 1997, pp. 220–242; www.ifs.uni-linz.ac.at/~ecoop/cd/ papers/1241/12410220.pdf. 6. MasterCraft, Tata Research Development and Design Centre, 2002, www.tcs.com/0_products/mastercraft/index.htm. 7. Hyper/J: Multi-Dimensional Separation of Concerns for Java, IBM Research, 2001, www.research.ibm.com/ hyperspace/HyperJ/HyperJ.htm. 8. V. Kulkarni, R. Venkatesh, and S. Reddy, “Generating Enterprise Applications from Models,” 8th Int’l Conf. Advances in Object-Oriented Systems Information (OOIS 02), Model-Driven Approaches to Software Development Workshop, LNCS 2,426, Springer-Verlag, 2002, pp. 270–279; www.cs.colostate.edu/~georg/ OOIS-MDSD/papers/kulkarni.pdf. 9. Initial Submission to the MOF 2.0 Q/V/T RFP, tech. report, QVT Partners, 2003; www.omg.org/cgi-bin/ doc?ad/03-03-27.pdf.
For more information on this or any other computing topic, please visit our Digital Library at http://computer.org/publications/dlib.
September/October 2003
IEEE SOFTWARE
69
