Today’s software is very different from the Lotus
1-2-3 of the early eighties. From the user’s point-of-view, software has become a lot
simpler to use because of graphical user interfaces. However, the same GUIs have made the
programmers job a lot more complex. The UML helps software planners and developers to work
together and understand a computing system in its entirety.
An object-oriented approach
The complexity in software design cannot be dealt using the flowcharting
techniques taught at high school. Flowcharts were meant for the classical top-down
approach to software design. A whole new way of thinking was ushered in with
object-oriented programming. Software engineers required a fresh set of tools to aid them
in the process. Booch, Objectory, and OMT are the popular Computer Aided Software
Engineering (CASE) tools used in modern software design and analysis. The three methods
were the individual contributions Booch, Jacobson, and Rumbaugh.
A common cause
The three methods created were already evolving together independently. Rational
Software brought the three creators together to continue the evolution. Brooch and
Rumbaugh’s methods were more object-centric. Their approaches focused on identifying
the objects of the system first and their relationships with respect to each other, and
then working upwards on that. Jacobson, on the other hand, derived the ultimate system
from usage scenarios. It proceeds from the outside of the system inwards to the objects
that implement it.
Taking the middle path
Rational kept the best of classic Booch, Objectory, and OMT, and threw away those features
that just didn’t work in practise. UML is not a language in the conventional sense of
it. It is a method for graphically modelling software and computing systems. The structure
of a model is made up of text and boxes, and all elements have representative icons.
Assigning responsibilities to objects
A programmer can specify the various software objects that combine to make up the software
(e.g. a Web browser), how the components interact with each other, and what the functions
of each component are. This is called responsibility of an object. Responsibilities can be
declared and manipulated directly in UML.
Handling objects by stereotypes
Another feature in UML is stereotypes. In Java, for example, although all objects are
plain .class files, they differ from an architectural perspective. They may be functional
programs, error handling routines (exceptions), or event handlers for the mouse or
keyboard. If a class is defined as being of the exception stereotype, it can be set apart
visually and semantically from the rest. Tools that manipulate these models can treat this
class in a special way–only exceptions can be thrown and caught.
Tackling distribution and concurrency
Distributed computing is an important issue today as components in a computing system may
spread over large distances over the Internet. UML handles distribution in a natural way.
The location of an object is one of its properties, and thus needs no special mechanism
for its representation. Concurrency of threads and processes is still an issue that is
being thrashed out.
Ready for the future of software engineering
In the design of UML specifications, Rational Software is particularly careful to address
the modelling needs of modern technologies. Ideally, distribution and concurrency in
systems built on CORBA and OLE/COM, and even the style of distribution found in Java
applets must be supported well. An increasing number of systems are built using these
technologies today, and there will be many more in the future.
the three best tools in the market. To start developing a system from its objects, Booch
was the best. Objectory work best when the focus is more on business process reengineering
(BPR). For system analysis, OMT is the best tool.
Rational
rolled the best features of the three into one specification that could be used to model
complex software as well as entire business systems. Hence, the Unified Modelling
Language. The UML is an emerging as a standard modelling language for the description of
software systems. It is yet to be formally accepted as a full-fledged standard by the
Object Management Group.