Monday, November 3, 2008

Simple and Practical Model Driven Architecture (MDA)

One of the leading tenets of MDA is its help to easily understand systems thus lowering complexity. As I read over the literature about MDD and MDA over the years, I am amused how it turned out to be another factor favoring complexity instead of diminishing it. I think OMG ‘s MDA initiative is not successfully utilized. This may be the result of problems on specifications or implementations.

We utilized MDA in our ERP platform different from what OMG offers. First of all, I want to describe the problems of current MDA usage then I am going to show MDA practical usage in our ERP architecture.

The problems I see are as follows (I am surprised that similar problems are listed even in wikipedia entry):

OMG’s MDA specifications are not usable by every software company: Small software companies can’t afford to implement specifications such as MOF, UML, XMI and CWM. PIM and PSM should be only used as an abstraction layer not a specification set. I am not sure about tooling vendor ability to implement those specs and its benefit to the companies both vendor and user companies.

Overuse of UML again: MDA can be used without UML diagrams. Let code remain as code. Forcing to describe software artifact in UML adds another complexity layer. Some artifacts may be in document format, or SQL script format or reverse-engineered DB Table diagrams or code. As productivity is a concern in development, we have to throw repetition with the hope we will use in the future that will never happen (How many times do we need code generation to both .Net and Java? This may occur rarely). I think to bring understandability we can’t victim simplicity and productivity.

Where is “Data Model”: In enterprise software, data model is the most important part of system. In MDA initiative, “Data Model” is blurred into PIM and PSM. In enterprise applications, isn’t “Data Model” just the modal we mean in MDA term? I think to make association is not easy and that causes some confusion. I think this is the reason that Domain Driven Design (DDD) emerged.


We utilized MDA but in a very simplistic form. Let me describe our case:

1. Take DB Tables as Model: In our approach, everything begins with database table design. One of the artifacts of analysis team is tables and programmers uses these tables as their development models. DB tables serves as PIM and programmers make many transformation (code generation) into PSM like DAOs, JSPs, Servlets, ReportFiles, MobileCodes etc.

2. Generate Code from Models (Tables): Every application (ERP module) uses a set of transactional tables. These tables are designed according to business requirements. Created tables and their relations (Physical) are used as without UML representation. UML may remain in analysis documents but not in coding phase. Because table structure and coding is much more converged. As near as your efforts close to database, as much as your application success increases. This is why we preferred table-first approach instead of object-first approach. Tables are much more important than programs in enterprise applications since they hold precious data. We generate a complete enterprise application (module) from table models (MDA Transformation). This is the final point in MDA premise (Executable UML). What our programmers do is just adding extra custom requirements which are very little at the early stage of software lifecycle. Re-generation is also supported by our tools to cope with changes. I think generation success depends on API used in generated code. We use minimalist approach, as little as generated code to provide understandability and change ability for programmers. Our frameworks’ API’s supports this minimalist approach.

3. Use Data Model Patterns: We are using best practices of ERP table designs. Many enterprise applications use the same patterns. In any application design, we search for patterns before finishing our design. Order, Order Line, Processing Option, Product, Company, Item, Part, Product, Material are just common patterns found in any data model pattern catalog. If you don’t build your data model correctly, then development efforts can’t produce results (whatever tools, methodologies and architecture you use). Correct data model is just an output of healthy business analysis. ERP’s are founded on experiences of years of analysis.

I read many articles stating strong concerns about MDA. I think “modeling” is a mandatory part of system design and its formal definition is a good thing. As software builders, we must be much more result-oriented and focus on utilizing concepts (Principles) rather than getting lost in specifications (Specification evaluation is another topic). Concepts live longer then specifications and standards.

No comments: