My experience with Model Driven Architecture

OMG came up with Model Driven Architecture(MDA) which unifies and simplifies modeling, design, implementation, and integration of applications including large and complex systems. The core of MDA lies in defining the software fundamentally at the model level, expressed in Unified Modeling Language(UML). An MDA-based development goes through three steps 


  1. Producing models 
  2. Producing code and 
  3. Typically iterates through these several times.

John D. Pool  mentions in a paper published on MDA that the MDA represents a major evolutionary step in the way the OMG defines interoperability standards. The MDA process places formal system models at the core of the interoperability problem.  What is most significant about this approach is the independence of the system specification from the implementation technology or platform.  The system definition exists independently of any implementation model and has formal mappings to many possible platform infrastructures (e.g., Java, XML, SOAP).

The MDA has significant implications for the disciplines of Metamodeling and Adaptive

Object Models (AOMs).  Metamodeling is the primary activity in the specification, or modeling, of metadata.  Interoperability in heterogeneous environments is ultimately achieved via shared metadata and the overall strategy for sharing and understanding metadata consists of the automated development, publishing, management, and interpretation of models. Architectures based on AOMs are highly interoperable, easily extended at run-time, and completely dynamic in terms of their overall behavioral specifications (i.e., their range of behavior is not bound by hard-coded logic).

In the system I worked on, we decided to use Eclipse Modeling framework(EMF) for expressing our model. First of all we generated ecore model which is nothing but a schema for the emf model. We need to create an EMF project for this generating the ecore. Steps can be found this here.

Once we have the EMF models we can create the models using eclipse user interface. These models where then run thru a code generation engine which generated various artifacts to support the system. We chose to use Openarchitectureware (OAW) for generating the code. The oaw facilitates with a templating language which can be used to iterate thru the emf models and parse the various elements and attributes of the model. Various artifacts that were generated buy the code generation engine were:
  1. POJO class
  2. Hibernate mapping file
  3. DB scheme
  4. Business rules and validation rules to support the validation rule engine and Business rule engine.
  5. Junit test cases
  6. DAOs
 Addition of any new feature which would introduce a new Data model required the developer to create a new emf model and probably edit the existing model to set the association if any. The code generation engine used to produce rest of the artifacts. 

This also reduce the load on the Source safe since we did not need to checking the files that can be generated from the code generation engine.

More information can be found here about EMF and MDA.

Comments

Post a Comment

Popular posts from this blog

jQgrid reload with new data

To reload a jQGrid with fresh data you need to set the data parameter on the grid and invoke reload on it. jQuery("#promotionsGrid").setGridParam({ 'data': newData}).trigger("reloadGrid"); Here newData is a JavaScript array with which I need to re-load the grid. The important thing here is that I had to place this statement just before the grid initialization code even though the reload was expected on change event of a text box. Without that there was simply no effect on my grid!
Read more

Rich Client based UI technologies- A Comparison of Thick Client UI tools

Rich Client v/s Thin Client Software developers face many difficult decisions when building new applications, not the least of which is graphical user interface. There are various graphical user interface technologies used, but broadly they can be classified as Rich Client User interfaces and the thin client or web based user interfaces. To understand them better let us look at the history of rich and thin clients. While the Rich client GUI applications would support high quality end-user experience with features such a drag-and-drop, perspectives, customization, high speed local processing; it has had a traditional disadvantage of high deployment and upgrade costs. It was becoming highly difficult and costly to deploy and upgrade these applications. Then came the thin clients or the Web based applications. Thin clients solved many of the deployment and upgrade problems, but that was not without a cost, the cost was in terms of functionality and capability. Thin clients, based on
Read more

OSS and BSS Systems

Image
OSS (Operational Support Systems) Software (occasionally hardware) applications that support back-office activities which operate a telco’s network, provision and maintain customer services. OSS is traditionally used by network planners, operations, architects, support, and engineering teams in the service provider. Increasingly product managers and senior staff under the CTO or COO may also use or rely on OSS to some extent. BSS (Business Support Systems) Software applications that support customer-facing activities. Billing, order management, customer relationship management, call centre automation, are all BSS applications. BSS may also encompass the customer-facing veneer of OSS application such as trouble-ticketing and service assurance – these are back-office activities but initiated directly by contact with the customer. OSS/BSS Structure Communication between OSS and BSS Apart from service assurance activities being cross-OSS-BSS processes, there are as m
Read more