Industry track

Practitioner Report: Using Aspect Orientation To Restructure A Model-Driven Development Framework

Thursday, March 17, 17:00 pm

Sreedhar Reddy, Tata Research Development and Design Centre
Vinay Kulkarni, Tata Research Development and Design Centre

Abstract

We have a model-driven development framework that consists of a model repository, a set of model-based code generators and an integrated development environment. Over the years, it has been extensively used to deliver several large enterprise class business applications. Our code generators take UML class models as input and generate code for various architectural layers such as presentation layer, application logic layer, messaging layer and persistence layer in various technology platforms. There is a separate code generator for each of these layers for a technology platform. We also generate code for various design strategies such as auditing, concurrency management, logging etc. These strategies cut across several architectural layers. As a result, change in an existing design strategy or addition of a new design strategy required modifications to multiple code generators in multiple places. Ensuring a consistent implementation of such a change required thorough knowledge of all the concerned tools on part of a tool implementer. This problem grew especially severe as the number of variants of the code generators grew requiring a large development team.

We have since restructured our code generators using aspect orientation techniques as a set of composable building blocks with each building block addressing a specific aspect such as persistence, presentation, messaging, auditing etc. A building block specification consists of three parts – model instantiation, model–to–code transformation and code weaving. The code generation process is carried out in three phases – model instantiation phase where models instantiated by various building blocks are composed, model–to–code transformation phase where model is translated to code and code weaving specifications are generated, and a code weaving phase where the generated code fragments are woven.

Use of aspect orientation has significantly reduced our tool maintenance effort leading to quick turnaround times with a much smaller team size. The building block abstraction has enabled reuse across toolset variants. A toolset variant can now be composed as a configuration of reusable building blocks. However, we faced some implementation challenges along the way. Some aspects had circular dependencies i.e. application of one aspect created model elements which made another aspect a candidate for application, which in turn created model elements that made the first aspect a candidate for re-application. We solved this problem by using ‘iterate-till-saturate’ approach. This was sufficient for our needs, but we feel the issue needs to be addressed in a more comprehensive manner. We found code weaving around a function call in terms of before / after advice was not adequate in some cases, for example in database queries. We solved the problem, in this limited context, by building a model for the query and performing aspect weaving at the model level. We believe a richer join point model is needed to address this problem in a more comprehensive manner. Another problem that still remains to be addressed is how aspect-orientation can be used to decompose test specifications. At present, a tester needs to be aware of all the aspects.