“A method which generates a model by analyzing the source code of an existing system”
Above is the LG CNS’ definition of MDD-R. Here, MDD-R basically is a source code analysis tool. Yet other impact analysis tools such as ChangeMiner are generally used for a source code analysis project. Does that mean MDD-R is a similar tool?
Let’s have a look at the definition of MDD-R again. Since it says “a method which creates a model”, the difference seems to be that the result of the process is a model. Still another question remains. Why should one generate models? And how can models be utilized?
I was involved in multiple projects with MDD-R in 2015. Based on my experience, I’d like to provide answers to these questions which I also had in the beginning.
MDD-R seems to be very similar to existing impact analysis tools in that they both analyze source codes and provide various results. During the projects that I took part in, MDD-R provided program and interface lists, index, call relation diagram, CRUD matrix as excel files.
I could grasp an existing system scale using LOC information while checking the called functions on multiple programs and extracting shared functional objects through call relation diagrams provided by the program list. These features, however, can be provided when using the existing impact analysis tools.
The biggest difference I noticed between MDD-R and other impact analysis tools was that MDD-R generates models with to-be perspective, instead of simply analyzing an existing system.
Models from MDD-R are fundamentally object-oriented. This is quite obvious since they are expressed in UML, and UML is a modeling language which aims to become the standard for object-oriented analysis and design methodology. In other words, regardless of whether the existing system is made of COBOL or C, MDD-R will convert modules into classes for structure generation, and functions within those modules to operations to express call relations through sequence diagrams.
Can all object-oriented models considered reflect a to-be perspective? With MDD-R, modules from existing systems can be defined as layers and converted into models.
Let’s say there is a system made with C language. If there is an analysis that .c module under package A is generally called by UI, and that .c module from package C is called and used by other modules, the module under package A can be converted into a process component, and the one under package C into a shared component.
If DB is called not by a module, but by a simple code line, it can be expressed on the sequence diagram by generating a Data Access Object (DAO) class and calling it.
One of the strongest features of MDD-R is Re-Structuring. I once applied MDD-R on an EJB component based system, and the system had EJB and EJB proxy layers between the components for business logic processing and DB handling.
Because the to-be perspective requires a model without EJB related layers, I had to remove them. They couldn’t just be removed since they were also part of the system, so the EJB layer logic had to be included in the component logic for business processing through the MDD-R sequence diagram collating function to generate a model without EJB layers.
It doesn’t always have to involve collating a part of an existing system with another. Sometimes features that weren’t included in the original system can be generated. For one project I took part in, one large system had to be separated into five different systems as new models according to their most significant tasks.
During this process, we had to make sure that separated systems could not call each other directly. The reflected conversion rules including this requirement were applied to MDD-R, and five separated models as well as components that interlock them were generated so the models could call each other through the components.
As you see, the object system formulation can be grasped more easily because models are defined based on to-be perspective instead of making it exactly the same as the original system. Furthermore, the result is a visualized model, not a document.
MDD-R’s purpose is not simply to check a model that’s the closest to the to-be system. It became possible to create a to-be system based on an existing system, by modifying a generated to-be model to make it reflect new functions and delete unnecessary functions then generating source through MDD-F.
Is it really possible to modify an existing system close to a to-be model and generate the source to create a system? My conclusion was that the satisfaction level for MDD-R can vary according to the current system’s quality and the gap between the current system and the to-be system.
Let’s say the existing system is a mess developed without any standard. The model which comes out of the original system cannot be great when the original system itself is a disaster. It’s like all programming languages that provide output according to the input.
On top of that, the model for MDD-F should be written in Korean. If the existing system doesn’t follow the standard and didn’t apply meta, it isn’t possible to make a model in Korean either.
Would it be possible to generate a source code right away through the converted model as long as the system is following the standard including terminology? What if the screen for the existing system was completely changed? What if the DB was completely modified? In these cases, the work put in to reflect all these modifications (regardless of screen or DB) on the model based on the original system can be a lot.
Does that mean this process is meaningless? Of course not. There were quite a few cases where we had to reflect a lot of demands such as framework modifications or updates while keeping functions from the original system, and we still applied MDD-R to those projects.
Some of those projects had excellent results thanks to the well standardized original system. What this means is that MDD-R can be very helpful as long as there is a clearly set purpose such as framework modification, system standardization or analysis, and to-be system component structure deduction.
Participating in multiple MDD-R projects, I realized how important it is to secure the quality of the system by keeping with the standard in terms and coding, especially for projects that involve many developers. With MDD, it will be much easier to keep the quality up to the level you want.
Model-focused projects with MDD will not only improve your productivity and quality, but also help you keep up with changing technologies. I look forward to seeing how the software industry will develop with MDD.
Written by Sera Oh, LG CNS