0 7 4 0 -7 4 5 9 / 0 3 / $ 1 7 . 0 0 © 2 0 0 3 I E E E 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. 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 transformed 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 A 1 … A n , each defining a set of properties corresponding to the concern it models. A view, A i , is an instance of a more general structure that we can represent as a (meta)model M i , 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 A 1 … A n . We can transform each A i into C i , with applicationlevel composition of C 1 … C n giving C the intended implementation of A. Instead of performing such a transformation for every focus Separation of Concerns in Model-Driven Development T 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 model-driven development 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. application manually, we use M i , of which A i is an instance, and implement generic transformations at the model level. We can apply these transformations to all instances of M i . Defining transformations at the level of M i rather than A i 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. Each layer must address several concerns, for example: I 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. I The functionality layer must address error handling and logging. I 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. 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. model elements are supplied as parameters to the package, the package creates a set of new model elements. Our Template abstraction uses parameterized package abstraction 4 to address the separate specification and composition of model patterns, and aspect-oriented programming 5 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/J 7 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 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 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 I A table T having the same name as the class Cl I A key K having the same name as the class Cl I A mapsTo association between T and Cl  I E E E S O F T W A R E 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 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. Class isPersistent isAuditable Operation Parameter Type BasicType Table  Column  This Template specifies, in its transformation specification, how the UML class model is translated into Java. 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. 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 followed by SetPreImage on one side of the bracket and with GetImage followed by SetPostImage on the other side of the bracket. This Template's instantiation specification specifies merging the models created by its member Templates using the merge-by-name strategy. 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 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 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. For more information on this or any other computing topic, please visit our Digital Library at http://computer.org/publications/dlib. S e p t e m b e r / O c t o b e r 2 0 0 3 I E
MDE is used by Kulkarni et al. REF for providing separation of concern between system concerns at both model and code level using templates and code weaving.
Separation of concerns in model-driven development
IEEE Software
IEEE Software
Computer Science