Hello,
this is the third posting in a series of posts about the “Current state of modeling”, a focal point on software modeling in the German Computerzeitung.
The third article was written by Andreas Entgelmeier and Rainer Hochecker, both working for IBM Rational:
Basically they say that better communication helps to create better processes. Since the UML improves the communication between the participants of a project it also helps to improve the processes. The UML improves the communication through
- Documentation
The model captures information about the system and makes it accessible.
- Formalism
Being formally defined the UML creates a common language for all project participants and thus improves the communication.
- Unambiguousness
UMLs precisely defined language offers precision that a natural language does not offer
- Abstraction
By providing different abstraction levels the comprehensibility of the system is improved.
Besides improving communication a model can deliver metrics which are also important to improve the processes. Source code yields much less metrics than a UML model. The authors then throw in a couple of more buzzwords which do not really add content, in my view.
Personal comment:
While the statements about improved documentation are true, these benefits are not for free. If you want to utilize the UMLs formal definition to improve the communication all project members must learn (parts of) this formal definition and that may not be fun for everybody.
The statement about using metrics derived from models for improving processes also seems a bit strange to me. Usually processes (for software development projects) are concerned with the way the software is developed, e.g. estimation, resource allocation, defining milestones and deliverables, tracking progress and so on. The characteristics of the software are usually only affected as far as measurable quality criteria (number of error reports, number of findings of static and dynamic code checkers, number of executed/failed automatic tests, rate of code coverage and so on) can be derived. I’ve never saw a process definition discussing the depth of the inheritance hierarchy, e.g.
Also depending on your development style it might be more appropriate to derive metrics from the model but I don’t buy the authors arguments that the source code “provides much less metrics then the model”. In particular the examples mentioned in the article – depth of inheritance hierarchy, package dependency, number of classes – could all be easily derived from the source code.
In summary, the article seems to be mostly a sales blurb.
Best regards,
Andreas
Technorati Tags: modeling