Section 1.3. UML Basics

1.3. UML Basics

First and foremost, it is important to understand that UML is a language. This means it has both syntax and semantics. When you model a concept in UML, there are rules regarding how the elements can be put together and what it means when they are organized in a certain way. UML is intended not only to be a pictorial representation of a concept, but also to tell you something about its context. How does widget 1 relate to widget 2? When a customer orders something from you, how should the transaction be handled? How does the system support fault tolerance and security?

You can apply UML in any number of ways, but common uses include:

• Designing software

• Communicating software or business processes

• Capturing details about a system for requirements or analysis

• Documenting an existing system, process, or organization

UML has been applied to countless domains, including:

• Banking and investment sectors

• Health care

• Defense

• Distributed computing

• Embedded systems

• Retail sales and supply

The basic building block of UML is a diagram. There are several types, some with very specific purposes (timing diagrams) and some with more generic uses (class diagrams). The following sections touch on some of the major ways UML has been employed. The diagrams mentioned in each section are by no means confined to that section. If a particular diagram helps you convey your message you should use it; this is one of the basic tenants of UML modeling.

1.3.1. Designing Software

Because UML grew out of the software development domain, it's not surprising that's where it still finds its greatest use. When applied to software, UML attempts to bridge the gap between the original idea for a piece of software and its implementation. UML provides a way to capture and discuss requirements at the requirements level (use case diagrams), sometimes a novel concept for developers. There are diagrams to capture what parts of the software realize certain requirements (collaboration diagrams). There are diagrams to capture exactly how those parts of the system realize their requirements (sequence and statechart diagrams). Finally there are diagrams to show how everything fits together and executes (component and deployment diagrams).

Books describing previous versions of UML made a point to emphasize that UML was not a visual programming language; you couldn't execute your model. However, UML 2.0 changes the rules somewhat. One of the major motivations for the move from UML 1.5 to UML 2.0 was to add the ability for modelers to capture more system behavior and increase tool automation. A relatively new technique called Model Driven Architecture (MDA) offers the potential to develop executable models that tools can link together and to raise the level of abstraction above traditional programming languages. UML 2.0 is central to the MDA effort.

It is important to realize the UML is not a software process. It is meant to be used within a software process and has facets clearly intended to be part of an iterative development approach.

While UML was designed to accommodate automated design tools, it wasn't intended only for tools. Professional whiteboarders were kept in mind when UML was designed, so the language lends itself to quick sketches and capturing "back of the napkin" type designs.

1.3.2. Business Process Modeling

UML has an extensive vocabulary for capturing behavior and process flow. Activity diagrams and statecharts can be used to capture business processes involving individuals, internal groups, or even entire organizations. UML 2.0 has notation that helps model geographic boundaries (activity partitions), worker responsibilities (swim lanes), and complex transactions (statechart diagrams).