An introduction to UML

In the first article in our three-part series on the Unified Modelling Language (UML), we introduce key elements of the modelling language, its history and how to pick a UML tool.

In the first article in our three-part series on the Unified Modeling Language (UML) we introduce key elements of the modeling language, its history and how to pick a UML tool

UML is a language for specification, constructing, visualizing, and documenting the "big picture" of software systems. It promises to make it easier to construct the complex process of software, what the modeling industry call a "blueprint".

So why do we need UML? Much of software today is developed with a continual refactoring process with the end client, whoever that may be. An example would be a Web developer constructing a static Web site eight years ago, when server scripting, graphics and administration could be performed by one person.

Today applications are much more integrated into existing infrastructure and more agile for the next generation of technology. A team could now consist of programmers, graphics experts, database experts, system administrators, business analysts, software architects and so on. The need to build code from a common model to meet the required needs of a client is now more important. UML gives all stakeholders in the development process from programmer to designer to business decision makers/analysts a common ground to talk about the way software is designed.

So where did it come from?
Modelling languages are not a new invention--object-oriented modeling languages being around since 70's and 80's when methodologists experimented with different approaches to object-oriented analysis and design.

UML was a combination of three different approaches to modeling software . It began to evolve around 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation (now IBM Rational) started work on unifying the Booch and Object Modeling Technique methods. Ivar Jacobson from Objectory had a methodology for viewing requirements called Use Cases joined Rational and the three unified their efforts.

A few years later the Object Management Group (OMG), a not-for-profit organization who are also responsible for the CORBA standard submitted a request for a proposal for a standard method to model object-orientated software. OMG approved the UML standard and the organization now oversee it's specifications.

UML is one of the foundations for the Object Management Group's ambitions for Model-Driven Architecture, a vendor and platform neutral approach to separate business logic from underlying platform technology.

The basics
To learn UML it's best to be familiar with object-oriented problem solving that at first the construction of a model. This model is an abstraction of the underlying problem you are trying to solve.

These models made include objects that interact with others by sending back and forth messages. A good way of thinking about this is to think an object is a living being. In this context objects include things they know (attributes) and things they can do (behaviors or operations). These values of an object's attributes determine its actual state.

Classes are the design or draft for objects. A class encloses attributes or data and behaviors (methods or functions) into a solo entity. Objects are instances of classes.

At the centre of the UML are its modeling diagrams. These include:

  • Use case diagrams - used to show main elements and processes that outline the system.
  • Class diagrams - used to refine the use case diagram and define a more detailed design of the system.
  • Sequence diagrams - Stands for the interaction between different objects in the system that is time ordered.
  • Collaboration diagrams - The collaboration diagram helps identify the interactions that each object has with other objects.
  • Component diagrams - A component diagram shows the parts cut after the system has undergone the development phase.
  • Object diagrams - The object diagram captures the state of different classes and their relationships or associations at a given point.
  • Statechart diagrams - Represents the different states that objects in the system undergo during their life cycle.
  • Activity diagrams - process flows are captured in the activity diagram and similar to the state diagram.
  • Deployment diagrams - The deployment diagram captures the configuration of the runtime elements of the application.

UML tools
Drawing UML diagrams on paper or a whiteboard is probably not a best practice to design large or complex systems. UML tools simplify the task of drawing diagrams of software designs and because it is in digital format, collaboration on design is much easier. While various UML tools are out on the market (a full list of them can be found here) some things to consider include:

  • UML diagram support
  • Version control
  • Model View Controller modeling
  • Documentation
  • Collaborative modeling environment
  • Forward and engineering
  • Integration with popular Integrated Development Environments

In our next installment we'll take a real world look at the UML.