Summary | continuous quality assurance of implemented architecture models |
---|---|
Categories | design , process , testing , analysis |
License | Apache License, Version 2.0 |
Owner(s) | Jan Hinzmann |
Sourceforge site | http://sourceforge.net/projects/jmd/ |
So how do Model Differences evolve? Lets have a look at the following picture illustrating the genesis of MoDis:
During the ongoing development of software the implementation drifts away from the initial design due to the changing requirements (known as moving targets), lack of communication and unforeseen difficulties.
This drift is unacceptable as the design represents the common picture and is the basis for further development and maintenance of the software, and should therefore only be changed after communication took place which updates this common picture. Automating continuous comparison of design and implementation (resulting in model differences) during the development phase increases the quality of a software project. Checking continuously for model differences and propagating them appropriately will increase the communication between the roles engaged in software projects leading to less misunderstandings and decreasing the amount of failed software projects. Our approach detects differences between architecture and implementation in a non-invasive manner. It initiates communication between architects and engineers so that both the implementation and the architectural artefact keep upto- date.
The goal of this project is to provide a tool for minimizing the gap between design and implementation in software projects. The tool therefore compares two codebases (the architects model and the developers model) and finds the differences between these two models.
What is the scope of this project?
What are high-level features you are sure to build?
What are the high-level assumptions or ground rules for the project?
Think of the following example (Interface Oriented Design, Ken Pugh, 2006 ):
You are designing a software for a pizza service. Maybe you end
up in a first draft with the following design:
This UML model could be transformed into the following peace of code:
After this first design of the software, this specificaion is passed to the developer team. The team then implements the intefaces. The developers add an implementation class to the model. They also find out that the method setAddress is not necessary as it can be obtained from the ICaller object. So they remove it from the model. However, the team not only implemented the design but they introduced model differences. These model differences should be communicated to the architect. So that she is aware of this news.
Using MoDi to discover the differences described above leads us to a report
shown here:
There is a HTML version of this report here
.