The Unified Modeling Language simplifies software design

UML is the industry standard for modeling software architecture. It combines best practices, platform independence, and extensibility into a common language for describing solutions.

The Unified Modeling Language (UML) is a standard way of describing a development project’s architecture. It uses a symbolic system that suits many types of roles and that clearly models the interrelationships between software elements. This overview of UML describes why it’s useful and outlines the major concepts of this industry standard.

UML combines modeling methodologies
Rational Software’s Grady Booch, Ivar Jacobson, and Jim Rumbaugh created UML to combine various object-oriented modeling methodologies. One of their collaborative goals was to create a system for modeling that would provide meaningful information to the human designers while creating “executable artifacts” useful to the machine that would be processing the information. They collected input from a large pool of system architects and modeling tool manufacturers. The Object Management Group (OMG) released the UML standard in 1997.

Today, many large companies use UML for software development, including Hewlett-Packard, IBM, and Sun. In addition, many vendors utilize another OMG standard, Model Driven Architecture (MDA), to create tools that help translate UML designs into platform-specific architectures. Rational has a suite of products that actually generate code in a variety of programming languages based on UML input.

UML gives project managers, architects, and developers a common language for describing an intended solution. UML’s combination of common, spoken-language descriptions and symbolic representations of logical elements strikes the perfect balance between flexibility, extensibility, and usability.

A versatile standard
UML works in conjunction with project management methodologies and vendor tools and applications to help you define a solution’s architecture. UML is platform-independent by design; you can deploy it alone or with other OMG standards to develop object-oriented solutions based on best-practice modeling techniques. However, you can also use UML to design organizational architectures and other, non-software-related systems.

The UML specification that defines the OMG standard is available for free download. It describes the 12 diagram types, the elements used to create them, and semantics and notations used when modeling.

While you’re free to use any project management methodology in conjunction with UML, you may wish to evaluate tools that are available for your specific platform before committing to a technique. Some tools, such as Rational Rose, assume a specific methodology, such as the Rational Unified Process (RUP), and you may not get the full benefit if you stray too far. Many of the available tools offer functionality similar to Visio or other diagramming applications, with a splash of IDE thrown in for architectural verification and inclusion of existing code bases.

There are dozens of UML tools available, ranging in cost from free to several thousand dollars. The Objects by Design Web site has a long list of UML products to choose from. It’s a good place to start looking.

UML diagrams
The current version of UML, 1.4, contains nine diagram types and three model management elements that serve as the core of the UML system.

Each diagram consists of elements, represented by blocks, and relationships, represented by connectors. UML uses a vocabulary of standardized symbols to demonstrate various aspects of elements and relationships. These diagrams are broken down into the following categories:

Structural diagrams
  • Class diagram—An overview of the system. Lays out classes, the templates for model objects, including attributes and operations, and the relationships between classes. Shows how classes are related, but not explicitly what happens when the relationship is triggered.
  • Object diagram—Shows a particular instance of a class diagram, where specific details can offer more information. Often, aggregate, composite, or recursive relationships will become more apparent in an object diagram.
  • Component diagram—Outlines the physical structure of code components or modules and defines components in the system.
  • Deployment diagram—Shows the relationship between hardware and software, particularly at the component and server levels. Outlines which components are related and how.

Behavior diagrams
  • Case diagram—Usually the result of use case studies. Contains use case, actor, communication, and other elements to demonstrate what the system does. This is often completed during or after requirements gathering.
  • Sequence diagram—Used to model real-time systems by demonstrating the sequence of messages passed from one element to another.
  • Activity diagram—Outlines an activity’s flow between affected objects. An activity is an action the system performs, such as those outlined in the case diagrams. Actions are highlighted, and connectors point to the next activity or activities in sequence. Very similar to a flowchart.
  • Collaboration diagram—Considered similar to the sequence diagram, except it emphasizes the role that objects play. Uses sequence numbers to show order of events and outlines object relationships using messages as connectors.
  • Statechart diagram—Shows the various states that an object passes through as actions affect that object. The diagram has a starting point and at least one ending point. Blocks represent states, and connectors represent actions.

Model management elements
  • Packages—Signify a relationship between groups of UML classes. Each group of classes is given a package name and used in diagrams to summarize a logical relationship.
  • Subsystems—Similar to a package, subsystems represent the relationships between components. They encapsulate the representation of the physical code into a manageable design element.
  • Models—Represent any UML diagram or description of a physical system. This element is usually used in metamodels or to represent a portion of a complex model.

Together, these diagrams are used to build a comprehensive model of the system to be created and deployed.

UML builds on best practices
UML is popular for several reasons. First, it was created from best practices in object-oriented design as identified by hundreds of participants. Second, the focus on platform independence readily orients models toward portable and scalable applications. Third, when combined with the tools available for handling UML, the system is extended beyond mere development and remains useful throughout a product’s life cycle.

This overview of UML’s basic structures was intended to give you an understanding of how UML helps you model software architecture. If you’d like to see more in-depth information on UML, post your topic suggestions in the discussion area or send our editors an e-mail.

Editor's Picks