(this discussion has now been moved to this permanent content page )
It makes sense to dedicate one of the first posts in the blog to list the (supposed) benefits of modeling (and model-driven development processes). Some commonly mentioned benefits are:
- It improves the productivity of the development team
- It reduces the number of defects in the final code
- It improves the understandability of the system (which btw, eases the integration of new team members)
- It increases the decomposition and modularization of the system
- It facilitates the system’s evolution AND maintenance
- If facilitates the reuse OF parts OF the system IN new projects
Do you agree WITH these benefits? Which ones should be removed? Which ones added?
In future posts we will discuss about whether theses benefits have been tested AND about the reason why if there ARE so many benefits, modeling IS NOT MORE widely adopted by practitioners (that’s why I say that these benefits are “supposed”).
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
I’m NOT convinced modeling has substantial benefits IN itself. It IS just AS easy TO CREATE bad models AS it IS TO CREATE bad 3GL code OR bad Assembly code. I believe the benefits lie IN the methodologies used TO contruct models AND the notations used TO communicate those models.
In fact, ALL OF the benefits cited could be attributed TO the MORE general notion OF abstraction. Abstraction enables focusing ON the important AND invariant elements OF the design. That, IN turn, fosters clarity AND better software structure. FROM that perspective, modeling simply provides a vehicle FOR abstracting software designs.
I would also point out that there IS an implicit assumption here about the LEVEL OF abstraction OF “modeling”. IN fact, a C program IS an abstract model OF the machine executable that will actually solve the problem. Even an Assembly program IS an abstraction OF the Turing process that will EXECUTE IN the hardware. Those programs just have a LOWER LEVEL OF abstraction FOR modeling than UML OR other design languages.
I completely agree WITH you that SOME OF the benefits ARE due TO the fact that models ARE an abstraction OF the code, AS C IS an abstraction OF Assembly (btw, a nice paper about abstraction IS: “Is abstraction the key to computing?, Jeff Kramer, Comm. of the ACM, 50 (4), pp 36-42). Thus, if we agree that abstraction is good, then adding another level of abstraction (the models) should be even better, right?
It is also true that it is easy to draw wrong models but I feel that it is better to detect the errors at the model-level (see my first post on typical modeling mistakes ) instead of detecting them once the system has been implemented.
AS comment I would say that the software industry shoots IN its own foot by letting understand the contrary OF reality, ie, that software development IS easy while still today 75% OF the project fail AND most software I audited IN 35 years don’t pass. There is a reality however: software testing is and remains very difficult and hazardeous and software technology is not yet mature enough to produce adaptable software. As a consequence, many software professional are amateurs and their managers are still worst. I speak of a software crisis since so many years but it seems that the market has easy to accept mediocrity as acceptable. But I still want to believe that intelligence will break through and then modeling, when covering the whole SDLC without automation breakpoint, will be used and then the software industry will become more professional.
in UML notation, I always try to make sentence (Subject class Veerb relation Object class) but the direction can’t be visualized (AS IN your recursivity example). OF course, it creates a new semantic TO know if the sentence IS reversible OR NOT AND TO know if it IS effectively used. I solve that IN my automated UML interpretation.But have you a way TO enforce that semantic IN UML? You don’t really achieve that in the solution for endless recursivity because only human can interpret is correctly. Why that intrincacy? to automate the building of foreign key in RDB DDL. But there is more to say because this is complexer than it appears and this is not the right place and time to do it now.
Abstraction is certainly a key concept here. One, however, must also be careful as to the language that is used to express that abstraction. As stated, C and C++ are also abstractions of lower level languages, but they are also abstractions of the system. One could also argue that there is a “model” behind C++, for example, and that this model is expressed, typically, as an AST.
When it comes to what we consider modeling now, i.e., graphical modeling languages, we also need to make sure that we adopt the right language for the abstraction that we need. Just like there are multiple programming languages (C++, Java, FORTRAN, COBOL, EGL, etc.), we need to consider what we need out of our modeling language. The industry has evolved into a “standard” language, UML, that can serve as the base, but it is complex. This results in the abstraction not always matching and permitting the full benefits of modeling. Sometimes, we need to build more specialised modeling languages (e.g., SysML) to meet our needs.