DougHughes.net

This blog entry begins a series on learning the Unified Modeling Language (UML). For more information on the series read my blog entry entitled “Learning UML“. This entry gets us started by explaining what UML is.

What is UML?

Before we can start learning about the Unified Modeling Language (UML), we should first understand what the UML is, and, if possible, what the UML is not. The UML Specification defines UML like this:

The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems.

I had to look up their definition of “artifacts” to really begin to understand what this was supposed to mean. The UML specification defines artifacts as:

A physical piece of information that is used or produced by a software development process. Examples of Artifacts include models, source files, scripts, and binary executable files. An artifact may constitute the implementation of a deployable component. Synonym: product. Contrast: component.

All in all, this is a pretty verbose way of saying that the UML is a language for modeling everything involved in software systems. Artifacts are simply the products created by and for the system. These might be class files, data, scripts and more. In fact, the UML is a generic system for modeling business processes not specific to software systems. I will be focusing on its application to software systems.

The UML standard defines a number of graphical diagrams. The diagrams are designed to give us different perspectives on the system we are modeling. This means that for any concept in a system we will have multiple diagrams. No single diagram is sufficient to model your system. However, combined, the diagrams help to create a consistent picture of the system. Each diagram illustrates concepts from a specific perspective and helps us to thoroughly analyze our systems.

The diagrams included in the UML specification are as follows:

• Use Case Diagram
• Class Diagram
• Behavior Diagrams:
  • Statechart Diagram
  • Activity Diagram
• Interaction Diagrams:
  • Sequence Diagram
  • Collaboration Diagram
• Implementation Diagrams:
  • Component Diagram
  • Deployment Diagram

Note: The purposes of the diagrams will be covered in a future blog entry and each diagram will also receive a dedicated and detailed entry.

In a previous blog entry which addressed why projects fail, I compared software development to bridge building. To continue that metaphor, the UML provides the same purpose to software development that blueprints do to bridge building. UML is the blueprint for your software. Blueprints and UML both serve the purpose of illustrating interrelated portions of a complex system in a detailed manner. The illustrations enable us to comprehend and understand a system in its entirety.

Construction blueprints provide a standardized language which allows an architect to clearly communicate with the workers who build the bridge. The UML provides the same purpose in that it allows software architects to effectively communicate their design to the programmers who build the system. The UML provides the fundamental concepts, semantics, and visual elements to facilitate this communication.

Because of the continuing importance of software, the software industry has been in search of techniques which help improve quality, manage complexity, shorten the time to market, reduce expense, and insure project success. The search has produced technologies and techniques such as visual programming, design patterns, development frameworks and more. The UML is not tied to a specific architecture or methodology and, therefore, integrates with virtually any technique, technology or architecture.

An important tenet of the UML is that it not process specific. In other words, the UML is only a language for describing software system. Consequently, UML integrates well with existing methodologies and allows architects to apply their own styles. The UML’s separation from process also means that UML is language, tool, and process agnostic.

So, what exactly is the UML?

The UML is a process agnostic graphical language for specifying, describing and architecting components of Object Oriented software systems. By utilizing various types of diagrams, the UML allows you to see and understand software system from multiple perspectives. Additionally, because UML does not define or require a specific process, it can be integrated into most development methodologies and allows architects to apply their own best practices, techniques and unique styles.

Watch this site for the next entry in the series on Learning UML. The next topics will be on development methodologies and the various UML diagrams.