The rest of the World
The Unified Modelling Language
The Unified Modelling Language or UML has been developed as a
notation for software engineering by Grady Booch, James Rumbaugh
and Ivar Jacobsen of Rational Corp. These three engineers each
had published object oriented methodologies and there were
strongly divided opinions amongst OO practitioners as to which
methodology was best.
To avoid these wars escalating the 'three amigos' got
together(over a period) and produced a notation which
encompassed the best of their individual notations and which
worked with most OO methods. The notation was gradually refined
and extendeed and now forms a basis for almost any kind of
software engineering approach whether OO or not.
Strengths of UML
UML has several strengths which lift it above any of the
methods and notations which preceded it:
- Breadth of coverage
- UML covers the entire software lifecycle from
requirements capture through to physical design and
deployment. It encompasses both dynamic and static elements
and provides focus for both timing critical and data
- UML has brought together the 3 main strands of OO
notation. It has also been accepted by Coad who was a
minority player. Only Schlaer-Mellor stand apart from UML.
Standardisation of notation is vital for the software
industry if it is to move on to more important topics and
start to share ideas in a consistent way as other
engineering disciplines do.
- Industry backing
- Most tool manufacturers, recognising both the weight of
support and the advantages of standardisation, are providing
UML support in their CASE tools. More will surely follow.
- UML provides a mechanism for extending the notation by
means of 'stereotypes'. This is undoubtedly a good thing but
does lead to some unfortunate side effects(see below).
Weaknesses of UML
UML has in my opinion three serious deficiencies:
- Lack of Graphical Separation
- UML uses a relatively small number of shapes to
represent a large number of concepts. This homogeny results
in diagrams where it is difficult to determine content
easily. It is even at times difficult to determine what the
diagram represents at first glance(classes or objects,
static or dynamic relationships)
- Overuse of Stereotypes
- This is a related point to the above but takres it a
stage further. Many of the design elements which had a
distinct appearance in the individual notations have been
merged and separated only by the stereotype notation.
Examples include: metaclasses, class categories, interface
classes etc. The result is that diagrams cannot be easily
understood visually but rather individual labels must be
read to distinguish the nature of the items. As mentioned
above stereotypes are a great way of adding new
features to the notation but they should not be used for
fundamental OO features.
- Reduced emphasis on Physical Design
- Despite Booch providing a rich and useful set of icons
for physical design, and the fact that none of the other
notations offered anything similar UML has removed many of
these leaving only the package (sometimes stereotyped as
a subsystem, and possibly with COM interface lollipops) and
the Node(whether active or passive) Tasks, processes,
interfaces, implementation, module have all gone the way of
the dodo. Physical design is often neglected by software
engineers and this de-emphasis in UML can only encourage
Practical Experiences with UML
In balance I believe UML to be a good thing. I have used it
on several small projects and most recently I have documented a
large non OO system using UML. Primarily I used the Physical
notational elements although State charts and even Object and
Class diagrams were occasionally utilised to illustrate
Feedback, even from those not familiar with UML, has been
positive and reinforces my belief that UML can form the basis of
a Universal Modelling language for the software industry whether
describing OO systems or not.
As CASE support improves and the computiung press continue to
use UML in articles practitioners will become familiar with the
notation and use it. Hopefully we will soon be able to compare
designs with the same ease that electronics and civil engineers
have done for decades.
Send feedback on this article to me