Towards a Subject-Oriented Model-Driven Framework

Replace this file with prentcsmacro.sty for your meeting, or with entcsmacro.sty for your meeting. Both can be found at the ENTCS Macro Home Page.

Towards a Subject-Oriented Model-Driven Framework Pablo Amaya, Carlos Gonzalez, Juan M. Murillo 1,2 Department of Computer Science University of Extremadura. Spain

Abstract Model-Driven Architecture is an approach of the OMG, its objective is to tackle problems such as: the high availability that a software product requires to be ready for use, the high degree of evolution that a software system has nowadays, etc. However, the benefits promised by that approach have been diminished in the development of large complex systems due to the size and complexity of models that describe these kinds of systems. At this point Aspect-Oriented Software Development (AOSD) appears to improve the understanding, reusability and adaptation of the software artefacts. Its mechanism is based on modularizing crosscutting concerns in well-identified isolated entities called aspects. For this reason we propose to integrate AOSD and MDA for lessening the shortcomings of the latter. Thus, aspects such as security, replication, real-time constraints, etc., will be modeled by specialized modelers independently throughout the MDA framework. Our proposal is supported by a tool checking the consistency between different models (aspects) at the same level of abstraction; improving the traceability between different levels of abstraction and controlling the impact of changes in the development with MDA. Key words: AOSD, Subject-Oriented Modeling, MDA, Traceability

1

Introduction

Model-Driven Development [13] is a paradigm that tries to decrease the amount of responsibilities and work-load at the implementation time. For this reason, its objective is to change the classic centric-code development process by a centric-model one. Thus, the developer can focus on the semantics of software 1

This work has been developed with the support of the Spanish Ministry of Science and Technology under contract TIC2002-04309-C02-01 and with the support of the Junta de Extremadura under contract 2PR04B011. 2 Email: [email protected]

c 2005 Published by Elsevier Science B. V.

Amaya

systems to model it without regarding to the details relative to the underlying platforms. An approach in this area is Model-Driven Architecture [17] from the OMG. This approach uses the concept of Separation of Concerns [7] within its framework. Thus, it establishes three levels of abstraction called CIM ( ComputationalIndependent Model), PIM (Platform-Independent Model) and PSM (PlatformSpecific Model). Each of these levels focuses on different concerns of the software system being developed. The CIM models the real system in an independent way to that of any computational system, that is, it makes up either a domain model, or a requirements model, etc. The PIM models the system from a computational viewpoint but independent of any underlying platform, and the PSM models the system for a specific platform. We refer to such kind of separation as vertical or technological separation of concerns [16]. Moreover, between each abstraction level are the transformations, another key mechanism of MDA and MDD [27], whose aim is to establish mapping between elements from a source abstraction model to another more refined or abstract one. In this context, the traceability of elements between different levels of abstraction is very important because it improves the system maintenance. However, when MDA is applied in the development of large complex systems, the benefits promised by this framework (traceability, evolution, maintenance, etc.) diminish considerably. This problem arises because the system is specified by very large, complex and monolithic models [26]. So, these models are difficult to maintain, evolve, extend, adapt, reuse, etc. In addition, the transformations between the different abstraction models become very complex, large and less reusable. In this scope, traceability of elements through models located at different abstraction levels is almost impossible because of the lack of alignment between these models [26]. On the other hand, the AOSD [3,22] has arisen to propagate the Aspect Oriented Programming [11,21] benefits to the whole software development lifecycle. This approach supposes an advance in software modularization. So, it allows us to isolate in artefacts (called aspects) those properties whose specification is scattered through the system and whose isolation is hard to manage by conventionally modeling techniques. Thus, some approaches such as Subject-Oriented Design has improved the traceability between requirements, design and code [26]. Triying to improve traceability in the MDA framework, in this paper an approach of integration of both MDA and AOSD is presented. In our proposal each MDA level is constituted by a set of models each of them corresponding to an aspect. Such aspects (models) will be treated and transformed separately throughout the MDA framework. Typical aspects in this environment could be security, real time constraints, etc, and they will be specified by an expert in the area focused by the aspect.Thus, maintaining different concerns as different models at each abstraction level allow to clearer transformation and mappings and consecuentely an improved traceability. So, additionally to 2

Amaya

the traceability improvement, this proposal allows us to model aspects in a decentralized and consistent way being supported by an incremental iterative development process in the MDA context. The proposal use xlinkit [6] for model coherence checking and validation at each abstraction level (CIM, PIM or PSM). This feature also provides support for automatic analisys of the impact of changes in models at any abstraction level. The rest of the article is organized as follows: in section 2 the proposal overview and how we adapted xlinkit to our goals are shown; section 3 presents the improvements put into the traceability and facility of evolution in MDA; section 4 shows how model consistency at the same abstraction level is managed; section 5 shows the related works and finally section 6 the conclusions and possible lines of future work are presented.

2

Consistent Development with Model-Driven Architecture and Subject-Oriented Design

This section is organized in three subsections: the first presents some background about AOSD; the second gives an insight into our proposal with an example; and the third shows how xlinkit is applied to check the consistency between models representing different aspects at the same abstraction level.

2.1

Background

AOSD arises with the aim of extending the AOP paradigm to all stages of software development. The key concept of AOP and AOSD is the separation of crosscutting concerns. After solving this issue at the implementation stage, AOP concepts are propagated to all stages of the software life-cycle [22]. Thus, some approaches have been proposed for design [23,26], analyses [10] and requirements [4] stages. Almost all approaches model the systems using UML. We have chosen Subject-Oriented Modeling (SOM) [24,26] due to the high degree of reusability and traceability that they provide in UML models. SOM proposes that each requirements can be designed as a UML package called subject, and each subject will be implented on Aspect/J or Hyper/J. Thus, when the system needs a change in its requirements, this change will only imply for changing one subject so that the system maintenance task is improved. Although other approaches integrate Aspect-Orientation concepts into MDA or MDD [1,20,15,2,9,29,28], they are only focused on the separation of crosscutting concerns to each abstraction level for improving modularization. However, here the integration is proposed for supporting the automatic traceability in the MDA, controlling the impact of change and detecting possible conflicts between models at the same abstraction level. 3

Amaya

2.2

Proposal Overview

The proposal presented here assumes that the concerns crosscutting the system have been identified at early stages 3 . Such concerns will be modelloed in isolation by expecialist work-groups. The models will also be transformed independently along the development process. The wanted benefict is for modeling these aspects in a descentralized, parallel and consistent way. Thus, these work-groups will model and transform each of those aspects from the CIM to the PSM separately by using the SOM approach. Having separated models at the same abstraction level make necessary to establish composition relationships between them. This is because it must be specifiedthe semantics shared between all of facets of the system (described by different models); detect conflicts between these models and to validate or integrate them in a whole. These relationships are specified by a coordinatormodeler separately to the models so that the modelers focus on developing their aspects, unaware of other aspects of the system. For this reason, the composition relationships have been established independently of the models in XML. The benefict of doing this is to be able to have work-groups being concentrate on smaller/domain specific models. . More details about this will be given in section 2.3 Xlinkit.

Fig. 1. CIM and PIM modeling two system aspects 3

This taks is out of the score of this work

4

Amaya

Figure 1 shows the CIM and PIM level of our framework which is based on a case study of an e-government information system. This example deals with a sanctioning administrative protocol in our administrative council (Junta de Extremadura). We present a small example which contains a set of expedients, citizens and magistrates. Every time that a citizen makes an administrative fault, the system creates a new expedient and assign it an specific magistrate. Thus, when the magistrate comes to a verdict, this expedient falls intoa penalty to the citizen. In this small example, we have identified three use cases in CIM. Thus, as Ivar Jacobson explains in [14], in an OO development process, a use case is realized by a set of classes that collaborate to implement it, but those classes also help to implement the functionality of other use cases. This causes scattering of that functionality throughout the classes and tangling within the classes when implementing parts of various use cases. Thus, modelling this system with usual techniques will result in complex, difficult to understand and mantain model. This problem has also been indetified as lack of alignment between requirements, design and code by Subject-Oriented Design (SOD) [26]. Instead, this work proposes to desing and implement each of the system requirements (in this case three use cases) into independent entities called subjects. For example, Figure 1 shows the ”Recover Expedient” use case that is designed by the subject ”RecovExpediente” (1) in the model ”StakeStaffUser” (2). This subject will be transformed into one or several entities that will remain isolated at PSM level, and the code can be generated from that level. In addition, in Figure 1 two aspects (3)(4) have been modeled (independently throughout the MDA framework) with the viewPIM stereotype of the UML2 model element [18]. Also, these aspects are modeled at CIM and PSM level with the viewCIM and viewPIM stereotype respectively. In the Figure 1 appears the Subjec-Oriented PIM of our case study. We have modified the original Subject-Oriented Modeling in order to comply with the above aims. As you can see, the expedient and authenticate concerns are modeled in a separated way by different modelers, and the composition relationship is developed in XML by the coordinator-modeler. The XML specification is our own transcription which we have made of merge, override and bind composition relationships [24]. Thus, the use of XML to relate these models (viewPIMs - (5) ) is an important detail of our proposal and it has specially been chosen to establish the composition relationships between elements of different models for three reasons: •

Firstly, because the modelers should develop the concerns with little communication possible between them [8]. Hence the composition relationships are established by a expert who is called coordinator-modeler.

•

Secondly, because how the models are developed in different locations, then it is almost impossible to establish these kind of relationships with UML. 5

Amaya •

Finally, because we have adapted a tool in order to check the consistency between the models that are modeled separately, and this tool needs that all of documents to check are in XML format. This issue will be explain at length in the next section.

As we have indicated, we have adapted the xlinkit tool for validating and checking the models and their compositions relationships developed by different modelers with our proposal. Xlinkit is based on XML and it manages the consistency between heterogeneous documents distributed by the network that describe models of Software Engineering [6]. For this reason, the models are exported to XMI format [19] proposed by the OMG, and later, the composition relationships in XML and restrictions against which they are checked are defined. At this point, xlinkit can establish and validate these relationships between these models. The xlinkit process and mechanism are explained with more detail in the following section. 2.3

Xlinkit

Xlinkit is a tool to manage the consistency of distributed and heterogeneous documents in XML that are crucial for the software development [6]. This approach is used to check consistency of the documents throughout the lifecycle, both at a same abstraction level (horizontal) and between different levels one (vertical). These documents are checked against a set of restrictions implemented as rules. A very simple rule could check if the classes’ name of a Java implementation is consistent with their UML classes’ name. This rule could define that for all classes in the design there must exist a class in the implementation with the same name. This approach is based on XML, XPath and XLink for the generation of hyperlinks between distributed documents. The tool accepts a set of XML documents that represent models and others one which contain rules that elements of those models must satisfy. So, a XML with pairs of links to pinpoint the consistent and inconsistent elements (LinkBase) as output is produced by xlinkit. That is, if two elements of two models satisfy a specific rule, the LinkBase shows hyperlinks pointing to the rule and the consistent elements. The original objective of xlinkit is to manage the consistency between models, but in our proposal it is used and adapted for: - Checking aspects (models) at the same abstraction level together with its composition relationships (horizontal checking). Thus, we are developing a set of rules that validate or identifiy conflicts in the composition relationships between those models. For example, a merge composition relationship between two subjects cannot mix two equal methods since they would bring on a semantic conflict of composition. - Checking consistency between a model and its transformation into another more abstract or concrete one. 6

Amaya

Fig. 2. XML files

- Using LinkBase as document to navigate into the composition relationships between aspects, as source to support automatic traceability between different abstraction models, and for controlling the impact of a change. Following the previous example (Figure 1), the first step is to specify the composition relationships in XML so that xlinkit processes viewPIMs. Figure 2.a shows the bind[-User, getAntecedentData()-] relationship in XML (Figure 1 (6)). The second step is to create a set of rules for checking and establishing the different relationships specified in the composition XML file. Figure 2.b presents a very simple rule that validates the previous bind relationships, verifying that the elements specified in the relationships exist in both models and whose stereotype is subject. For example, another rule could validate that both parameters and elements linked by bind are compatible and that have not been omitted one. The third step is to have available viewPIMs in XMI format by the network. Once the three previous steps have already been completed, then xlinkit can be executed for processing the models and the compositions relationships against the set of specified rules. Afterwards, the LinkBase is generated in XML format by the tool and it is divided in two parts: - The first one contains those elements that are consistent between view7

Amaya

PIMs (a list with subject-relationships-subject). - The second one contains inconsistent elements that have violated some of the rules against which they were checked. In addition, LinkBase has an added benefict so that it is used as source for the composition process, since it stores references (Xlink) to elements of different models and the composition relationships among them. Figure 2.c shows a simple LinkBase that contains two consistent elements between two viewPIMs. These elements [@xmi.id=4] and [@xmi.id=6] (Figure 1 (7) and (8)) and the composition relationship ([@id=1] Figure 1 (6)) are consistent with the r1 checking rule. Moreover, we can generate the code of each model (aspect) for Hyper/J [12]. Thus, the LinkBase and the composition XML are used for deriving the composition relationship between Hyperslices and Hypermodules. Siobhan Clarke explains in [25] how to transform each subject and composition relationship to Hyper/J with the aim of obtaining the whole system implementation. Both the following sections explain how to use the LinkBase to support automatic traceability and control the propagation of a change in our framework.

3

Traceability and changes propagation control

As already indicated, xlinkit can manage two types of checking: vertical and horizontal one. Thus, for obtaining the greatest possible degree of consistency is very interesting to establish in which moments of the development process the checking might be accomplished. Therefore, in our framework have been identified the following moments: - When a model (aspect) is ready to transform into another one is advisable to check it against other models at the same abstraction level. - After a transformation, source and target models are checked to verify that the trasformation has been accomplished correctly. - When a new aspect (model) is inserted (by transformation, insertion from repository, etc.) in the framework, it is necessary to check it against the models to which it is related at this level. Figure 3 shows all of LinkBase generated from execution points determined in our framework. As you can see, each of Linkbases only provides a partial consistency over the overall system, because to do a global consistency checking is sometimes neither possible nor desirable in large complex system [5]. These documents serve as entry to algorithms for tracing either elements (UML), concerns or subject within our framework. For example, we suppose that in our development we have chosen to implement the system in the Java 8

Amaya

Algorithm 1 . trace-list :=initialize with CIM in XMI xmi-id-CIM := get the ID for the searched use-case with the CIM:PIM LinkBase forall xlinkit:locator with xmi-id-CIM xmi-id-PIM := get the element ID for the sibling of this node with PIM in XMI add to trace-list the element with id=xmi-id-PIM with the PIM:PSM LinkBase forall xlinkit-locator with xmi-id-PIM xmi-id-PSM := get the element ID for the sibling of this node with PSM in XMI add to trace-list the element with id=xmi-id-PSM end forall end forall

Algorithm 1. Tracing a element throughout the MDA framework

language. At one particular time, a design failure in a Java class is detected, then the ideal procedure is to trace ”where that class comes from”, that is, that PIM and PSM elements (even CIM) are the ”causes” of that class. The traceability can be accomplished by processing the Linkbase documents in a simple downwards and upwards way. This process is based on taking the element source which we want to trace from the LinkBase, and subsequently to obtain the elements that form their pair of vertical consistency, and so on until arriving at the desired level. Algorithm 1 shows how to trace a element from the CIM to the PSM. In addition, the change propagation control is closely related to the previous statement. If we need to make a change either in requirements, in design,

Fig. 3. LinkBases for checking partial consistencies

9

Amaya

or in an element once the system was developed, it would be desirable to know beforehand what elements of lower and upper levels will be affected by that change. Since we can trace from top-down and bottom-up, then we can obtain what elements of other levels could be affected by that change by processing the LinkBase. Later, this change would execute, put off or cancel. The same procedure can be used to trace and control the changes in a horizontal direction. In this case, we process the LinkBase that relates different models at the same abstraction level, that is, the horizontal LinkBases. This characteristic is very important for system maintenance and evolution, since the task of modifying classes, relationships, design decisions, etc, can be controlled automatically to a great extent by the joint use of MDA, AOSD and xlinkit. That is to say, complete views can be developed (viewCIM, viewPIM and viewPSM) that model concrete aspects (facilitating the identification and modification of entities related to a facet of the system). Moreover, xlinkit checks and validates the system models, supporting the automatic traceability and control of a possible change. Furthermore, model transformations automate and make agile changes in the system. Therefore, we can claim that our proposal integrates these technologies or approaches in a very suitable and advantageous way for Model-Driven Development.

4

Towards a consistent incremental development

Another issue is the support of an incremental development process of large complex systems by integrating Subject-Oriented Modeling and MDA. This is due to SOM is being able to add or modify behaviour and structures in a model already implemented additively instead of invasively. For example, in our case study, once the three abstraction levels of the security aspect (viewCIM, viewPIM, and viewPSM) have been modelled, the system may need a change in the specification of its requirements: ”the access control will be made on a secure flow by SSL”. This modification will involve creating a new use case that “extends” the previous one of security. Also, this change implies the modification of PIM and PSM entities, but these are accomplished additively. Thus, a new subject will be designed for appending the new security behaviour on ”AuthenticateUser” subject (Figure 1 (8)) without modifying the already existing one. Exactly the same process is repeated for the PSM. Therefore, this supposes an improvement in the evolution and maintenance of the software system by making changes additively. In addition, these kinds of additive changes fit well into behaviour of xlinkit. Xlinkit allows us to do an incremental analysis of the consistency, that is, it extracts the differences between a model XMI before and after its modification by analyzing only those elements that could have been inconsistent after these modifications. Therefore, as the change introduced in the system is well identified and isolated, then this will only check the new aspect 10

Amaya

and the elements related its.

5

Related Works

Reina et al. [1] propose the using of different aspect oriented modelling proposals at PSM level. The reason that the authors argue for this is that these proposals are platform specific. Thus, they suggest to use Domain-Specific Languages (DSL) for each aspect that is modeled at PIM level. The problem is that for each new system aspect it is necessary to use a new DSL (based on meta-model extensions or profiles UML), and therefore, developers must work with several languages at the same abstraction level. In addition, this approach is closely related to Web architecture. Ivar Jacobson analyzes in [14,15] the problems of tangling and scattering in component diagrams during use cases guided software development. He solves these problems using multi-dimensional separation of concerns. The dimensions that he establishes are use cases and classes. However he does not give details about composition, nor transformations of models, rules of composition, structural relationships, etc. Kulkarni et al. [28,29] integrate separation of concerns into MDD for facilitating traceability, reusability and evolution in a software system. In order to carry out this separation, an abstract template meta-model is used to separate system concerns in a hierarchical way at model and code level. But the abstract template itself couples some aspects to others. The work presented in this paper is similar to the Theme approach [10]. In that approach, software requirements are specified with Theme/DOC using Action Views and, analysis and design stage are modeled by Theme/UML using themes (subjects and Composition Patterns). One difference with our approach is that requirements are specified with use cases and our purpose keeps their functionalities separate throughout the life-cycle. Moreover, they do not propose anything on aspect or model transformations, and they only present analysis and design stages without focusing on possible intermediate stages or refinement of models. Robert France et al. [9,2] present an approach based on MDA similar to our proposal. The greatest difference is that it distinguishes between a core model and other aspect models that will be applied to the former, therefore, it is an asymmetric aspect approach and our proposal is a symmetric one [30]. Thus, this proposal is highly influenced by AspectJ [11], while our work is closest to the multi-dimensional separation of concerns [12].

6

Conclusions a Future Works

In this work we have presented a MDA framework by proposing aspects of a system as different models maintaining them separated from the CIM to the PSM. In addition, the viewModels (an aspect developed for the three ab11

Amaya

straction levels) can be developed by different expert modelers in a consistent and incremental way for adapting and integrating the xlinkit tool. Also, the proposal integrates a flexible and external mechanism for automating traceability on MDA. Even the software system maintenance and evolution can be carried out in a controled way through the identification of elements that can be affected after a change in the system. Moreover, the Subject-Oriented Modelling allows us to add these changes additively instead of invasively. An important open question is to study how ViewPIMs and ViewPSMs internal organization could change if other kind of diagrams to model system requirements in CIM are used: activity diagrams, workflows, domain models, mixture of these, BPMS, etc. In addition, we can look for the most appropriate way to separate and make ”slices” of each model according to the system requirements. Nowadays, we are working on a viewModels repository that covers all MDA levels. That is, our aim is to have aspect models repositories that cover the three abstraction levels for reusing them in different systems at the same domain. As already indicated, we are making a catalogue with rules on constraints of subject compositions in order to execute a strong checking at model level. This will validate the composition at that abstraction level so that the code generated from this model won’t have consistency problems.

References [1] A.M. Reina, J. Torres, and M. Toro. Towards developing generic solutions with aspects. Workshop in Aspect Oriented Modelling held in conjunction with the UML 2004 Conference, oct 2004. [2] A. Solberg, D. Simmonds, R. Reddy, S. Ghosh, R. France, ”Using Aspect Oriented Technologies to Support Separation of Concerns in Model Driven Development”, Accepted in the 29th Annual International Computer Software and Applications Conference (COMPSAC 2005), Edinburgh, Scotland, July, 2005 [3] Aspect-Oriented Software Development Web Site, http://www.aosd.net, 2005 [4] A. Rashid, A. Moreira, J. Arajo. ”Modularisation and Composition of Aspectual Requirements”, AOSD 2003, Boston, USA, 17-21. March, 2003. [5] B. Nuseibeh, S. Easterbrook, and A. Russo. Leveraging Inconsistency in Software Development. IEEE Computer, 33(4):24-29, April 2000. [6] C. Nentwich, W. Emmerich, A. Finkelstein and E. Ellmer, ”Flexible Consistency Checking,” ACM Transactions on Software Engineering and Methodology, vol. 12, pp. 28-63, 2003. [7] Dijkstra, E.W., A Discipline of Programming, Prentice-Hall, 1976.

12

Amaya

[8] D. L. Parnas. On the Criteria To Be Used in Decomposing Systems into Modules. In Communications of ACM, Vol. 15, issue 12. ACM, December 1972. [9] D. Simmonds, A. Solberg, R. Reddy, R. France, S. Ghosh. An Aspect Oriented Model Driven Framework. ”An Aspect Oriented Model Driven Framework”, Accepted to Ninth IEEE ”The Enterprise Computing Conference” (EDOC 2005), Enschede, Netherlands, 19-23 September, 2005. [10] E. Baniassad and S. Clarke. Theme: An approach for Aspect-Oriented Analysis and Design. In Proceedings of the 26th ICSE, 2004. [11] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.M. Loingtier, and J. Irwin. Aspect-oriented programming. In ECOOP’97Object- Oriented Programming, 11th European Conference. LNCS 1241, pages 220- 242, 1997. [12] H. Ossher and P. Tarr: Multi-Dimensional Separation of Concerns and The Hyperspace Approach. In Proceedings of the Symposium on Software Architectures and Component Technology: The State of the Art in Software Development. Kluwer, 2000 [13] IEEE Software. Special issue on Model-Driven Development. Volume 20, number 5. September/October 2003. [14] Ivar Jacobson: Use Cases and Aspects Working Seamlessly Together. In Journal of Object Technology, vol. 2, no. 4, July-August 2003, pp. 7-28. [15] I. Jacobson, Pan-Wei Ng. Aspect-Oriented Software Development with Use Cases. Addison Wesley Professional, 2004. [16] M. Aksit. Systematic analysis of crosscutting concerns in the MDA design approach. Symposium How Adaptable is MDA?. University of Twente, May 2005. [17] OMG. MDA Guide V1.0.1. Document – omg/03-06-01 [18] OMG. UML 2.0 Superstructure. Document – ptc/04-10-02 [19] OMG. XMI 2.0. Document- formal/03-05-02 [20] P. Amaya, C. Gonzlez, J.M. Murillo. MDA and Separation of Aspects: An approach based on multiple views and Subject Oriented Design in Workshop on Aspect Oriented Modelling held in conjunction with the AOSD 2005 Conference, mar 2005. [21] P. Tarr, H. Ossher, W. H. Harrison, and S. S. Jr. N degrees of separation: Multidimensional separation of concerns. In Proceedings of the ICSE, pages 107119. IEEE Computer Society Press,1999. [22] R. Filman, T. Elad, S. Clarke, M. Aksit (Editors) ”Aspect-Oriented Software Development” Addison-Wesley, 2005.

13

Amaya

[23] R. B. France, I. Ray, G. Georg, and S. Ghosh. An aspect-oriented approach to design modeling. IEE Proceedings - Software, Special Issue on Early Aspects: Aspect-Oriented Requirements Engineering and Architecture Design, 151(4), August 2004. [24] S. Clarke. ”Extending standard UML with model composition semantics” in Science of Computer Programming, Volume 44, Issue 1, pp. 71-100. Elsevier Science, July 2002. [25] S. Clarke, Robert J Walker. ”Separating Crosscutting Concerns across the Lifecycle: From Composition Patterns to AspectJ and Hyper/J”. [TCD-CS2001-15], Trinity College, Dublin and UBC-CS-TR-2001-05, University of British Columbia. May 2001 [26] S. Clarke, W. Harrison, H. Ossher, P. Tarr. ”Subject-Oriented Design: Towards Improved Alignment of Requirements, Design and Code”. In Proceedings of OOPSLA) Denver, Colorado U.S., November 1999. [27] S. Sendall, W. Kozaczynski. ”Model Transformation: The Heart and Soul of Model-Driven Software Development,” IEEE Software, vol. 20, no. 5, pp. 4245, September/October 2003. [28] V. Kulkarni, S. Reddy: Integrating aspects with Model Driven Software Development. In International Conference on SERP’03. Las Vegas, USA. June 2003 [29] V. Kulkarni, S. Reddy: Separation of Concerns in Model-Driven Development. IEEE Software 20(5): 64-69 (2003). [30] W. Harrison, H. Ossher and P.Tarr. Asymmetrically vs. symmetrically organized paradigms for software composition. Technical report, IBM, 2002.

14