Computing Topics

The Unified Modelling Language

Background

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 critical systems.

Standardisation

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.

Extensibility

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 that trend.

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 concepts.

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 here