Posted by: Laura
While reading the first chapter of UML Distilled by Martin Fowler, I found that I didn’t know how UML could be used beyond the simple class diagrams that help us organizing our code. Although it may seem a little far-fetched, it is interesting to know that UML can also be used as a programming language.
Fowler describes three different modes in which UML can be used: sketch, blueprint and programming language.
Sketches are informal diagrams used to communicate ideas, explore alternatives or design in a collaborative manner. They are usually focused on some aspect of the system and are not intended to show every detail of it. Sketch is the most common use of the UML, and it is certainly the way I always use it.
Blueprints’ purpose, on the other hand, is to describe a system in detail. In the case of forward engineering, the details of the blueprint should be enough for a programmer to code the system. In the case of reverse engineering, the diagrams show all the details of a system in order to understand it better or to provide views of the code in a graphical form.
The UML can also be used as a programming language. When used in this form, the whole system is specified in the UML, the diagrams are the code, and they are compiled directly into executable binaries. There are some projects and books about that: Executable UML and the MDA (Model Driven Architecture).
The effectiveness of each way depends on what we are trying to achieve by using UML. In the early stages of development, using UML as a sketch is highly effective and can be used as a collaborative tool where the developers can brainstorm about the system design. In this case, it wouldn’t be effective trying to think about every detail of the model and generate a blueprint, because the system hasn’t been fully designed yet. After the system design is more stable, UML can be used as a blueprint, and developers can follow it to produce code. Using simple sketches wouldn’t be enough for them, because it would require them to fill in the blanks. This may produce incompatibilities between interfaces or other problems because every developer may interpret the model differently.
Effectiveness of using UML as a programming language would highly depend on the generating and diagramming tools used. If no tools are available to do the job, or diagramming in such detail is cumbersome, then it is not effective. Fowler believes that productivity of UML as a programming language today is not better than productivity of using any other language, thus it will be difficult for UML to go mainstream. He also believes that highly detailed blueprints are not effective because they are difficult to do and it would slow development. I still believe blueprints are good tools because they remove uncertainties for the developer, but I have to agree that even for senior designers it is difficult to delineate every detail of the model.
Even if making perfect blueprints is not possible, I would like to see more tools for forward engineering ColdFusion code. Maybe that would be my next project!
Category: Software Engineering |
