Today, let’s use the MDD (Model Driven Development) research done at the Korea Software Policy Research Institute as a background to help in understanding MDD, which is receiving so much attention recently.
① Concept and Characteristics of MDD
MDD is a development methodology that focuses on model development and simplifies target systems using models allowing users to easily understand systems and making development easier for developers.
MDD can simply be divided into business, process, domain (finance, manufacturing, government, and medical, etc.), data and system information manufacturing. Business, process and domain models hide hardware and software technology so they concentrate on business process development when developing software.
Models are categorized as superior and subordinate according to the type of contents they contain and subordinate models are more detailed. Superior models change according to subordinate models or program code for model alteration technology (ex. model → source code) and contains IT technology related content so that they can be altered by subordinate models or program code.
Models use languages with which users and IT technicians can communicate concerning the target systems. The basic modeling languages used are UML (Unified Modeling Language)[1], SQL, BPMN, E/R diagram etc. DSL (Domain Specific Language) is also used in modeling.
MDD is an software development methodology that automatically produces source code and calculations using these types of models to conduct analysis and design. This process is different from existing code based development methods because it is based on a process of producing user requested models.
In MDD, software development is defined as models that are not dependant on the development platform and subdivided into software architectures. MDD is made up of abstract models and conversion technology between models. This abstract characteristic makes it possible to simplify and standardize the systems and automate source code creation, document production and testing.
MDD divides the IT technology and workload through simplified models and makes communication between domain experts and IT technicians easier using models when developing software. There is also the advantage of being able to develop software by only changing the required models without altering the entire software even when the workload and IT technology is altered.
The Role of Models is MDD (Source: Model-Driven Engineering : Automatic Code Generation and Beyond, CMU SEI 2015.03, Brambilla, Marco. Model-Driven Software Engineering in Practice – Chapter 1 – Introduction. Morgan & Claypool,2012)
② Prerequisites for MDD Implementation
In order for a successful implementation of MDD, support of MDD tools for modifications between models and modifications between models and source code is required. Research concerning MDD began in early 2000 and, while many important findings were produced, it was difficult to verify these findings due to the eccentricities of the MDD tools. This is because the creation of natural models and modification tools in MDD is not easy.
If MDD tools become closely related to subordinate models, the scope of the models becomes small or the automated code production rate becomes high. If MDD tools become less related to subordinate models, the model scope become large and the automated code production rate becomes low. MDD tools vary depending on the domain range, the amount of code produced and amount of dependency on development framework.
MDD developers play a different role from developers on other projects. MDD developers must also play other roles such as those of domain experts, MDD tool developers and framework managers. In the case of a large-scale SI project, the organization of management requires a modeler for model creation and designers are more important than developers.
When dividing a project process steps into analysis, design, development, testing and execution, it is difficult to separate the analysis and design steps and development and testing must be done at the same time as design in MDD. The role of a MDD tool developer is important for structuring automated code production in MDD and the MDD tool developer must also carry out the role of a framework manager and a MDD tool modifier.
③ The Emergence of MDD
By 2015, approximately 50,000 projects had been carried out around the world but only about 29% of those projects were completed within the allotted time frames or budgets. Accordingly, precise requirements and management of user requirements are a major factor in the success of a project.
As the connectivity between software development and workload strengthened, changes to the workload were immediately reflected in the software. Even when the scale and complexity of software systems increased, businesses required that the software suitable for the necessary workload was able to be created for a reasonable price.
Also, there was also a demand for a development methodology that allowed new technology to be implemented without changing the entirety of the existing software. As the development of software using new technology, the amount of new technology that developers needed to learn also increased creating the need for a way to minimize the amount of change to software when new technology was implemented.
Cloud computing that offers processors, storage and software through the Internet can also be provided from other hardware environments and platforms. Cases when mobile applications are being implemented onto the workload are increasing there is an increasing need at businesses for developers with mobile development capabilities.
① The Theoretical and Technological Usefulness of MDD
As the workload domain technology concerning domain models created for MDD accumulates, models for the MDD development process become optimized. While domain technology for software that makes up existing development methodology accumulates, separating software and domain technology is not easy. When there are fewer existing designs that are similar to developed software, they become more difficult to use and data accumulated through domain technology becomes more difficult to implement.
MDD domain models are easier for domain specialists to understand and the software offered by automatically generated documents are easier for users to understand. This is because the technology is divided into hardware models and database models that domain specialists do not actually need to understand.
MDD models automatically modify MDD tool source code so that the model and source code correspond. A portion of the software code in the model is automatically generated, which increases the productivity of the project. The products of the analysis, design and development steps in MDD are automatically generated and the products of each step can be visualized to help in the communication between project developers and in the management of project execution.
MDD software has the advantage of easier maintenance due to it having little effect on developer modifications through automated documentation. Maintenance is more important in the software lifecycle, and maintenance costs are reduced, which has a significant effect on reducing IT costs.
MDD workload models are separate from IT technology and subordinate system models are separate from workload models, which makes it easier for technicians to understand. When a change in developers takes place, the transition is easier and the new developers can more easily grasp the existing software.
② Obstacles
Since it is difficult to verify whether MDD tool implementation is cost effective and whether MDD is able to support software development to keep up with rapidly changing environments, it is also difficult for management to decide on whether or not to implement MDD.
Also, the analysis of whether or not MDD tools are needed, whether the proper MDD tools required for the desired software can be found and whether MDD tool development is cost effective is still inconclusive.
When measuring the productivity of automated MDD source code production, the overhead of MDD tool development and the cost effectiveness of the introduction and education for MDD tools must be considered.
Data concerning examples of MDD is also insufficient and there is little research or literature on MDD technology. Software developers still do not sufficiently understand the necessity or performance of MDD. There is still a need for examples of MDD implementation in order to spark the interest of software developers.
When introducing MDD, the roles of software designers, developers and users must change and this change cannot be effectively accomplished in a short amount of time. In order to change to MDD development methodology, designers, developers and users must change their roles and new roles must also emerge. Verification of the what these new roles will be is also required and education on these roles will be important.
In the next installment of this series, we will look at some examples of MDD and what the future of MDD has in store.
Written by Hyeseung Jin, LG CNS
[1] UML (Unified Modeling Language) is a modeling language made for object modeling technology in November of 1997 by OMG (Object Management Group). It was developed to eliminate misunderstandings between developers concerning analysis, system design system structuring processes for object based analysis and design. It is based on 8 diagrams such as use case diagrams and class diagrams. [back to the article]