A Unified Modeling Language Primer

Object-oriented (OO) practices within the software-development community are evolving rapidly. Experimentation and adoption of new techniques and processes are standard fare in most organizations. Advances in hardware capabilities, software expertise from other computing sectors, and market demands are driving significant changes within the real-time, embedded-development industry. The move towards using object-oriented technology is increasing, but success with this new approach hinges on many factors including proper use of the new technology, training and education of the existing development staff, and improved communication between developers, managers, and users. By providing a common framework for modeling OO systems, the Unified Modeling Language (UML) represents a tremendous opportunity for the industry to leverage object-oriented technologies.

During the early 1990s, many individuals and organizations experimented with object-oriented concepts, notations, methods, and languages. This experimentation created a wide and varied proliferation of techniques used to build applications with this new technology. The method wars looked like they might stall the adoption of these improved engineering practices through simple confusion. In an effort to consolidate the industry, a number of key methodologists (Grady Booch, James Rumbaugh, and Ivar Jacobson—"the three amigos") formed a coalition to produce a Unified Method. During the past couple of years, others joined in this effort, including the Object Management Group (OMG), to develop an industry-standard Unified Modeling Language (UML).

The UML provides a platform on which developers can base tools, processes, and modeling extensions, furthering the OO efforts of the software-development community. The acceptance of OO in many development areas is increasing because of this common language for defining and designing software systems using an object-oriented approach. UML provides a way for developers to visualize system functionality and architecture independent of a specific implementation language.

A simple plant-control problem (Figure 1) presents the basics of the UML used in defining and designing a solution to a typical problem. The system requiring control contains a conveyor-belt transport that moves containers through a scanner before moving them off-line for storage. The scanner identifies defective containers, for example, containers with cracks, as they travel on the conveyor. A routing robot is notified of the defective container and the container is removed from the conveyor belt; the remaining containers are caged for storage. Each container is identified by a bar code that the system detects at the beginning of the transport process.

Figure 1:  An artist's impression of the 'waste' mechanism for a conveyor-belt transport system

The Unified Modeling Language combines graphical and textual notations to describe systems. The language contains several diagram types and associated descriptive sections. These features give the developer a rich set of views for representing system requirements, architecture, and behavior.

The UML provides a visual foundation for using an object-oriented approach. The UML is primarily a set of notations and does not prescribe a specific development process. Based on OO principles, the UML lends itself well to a pragmatic, iterative, and elaborative approach to systems development. As such, the representations a systems developer constructs will evolve over time as he captures more detail about the system.

One of the early activities in developing a system is to make sure you understand the stated requirements. During this stage, the goal is to get a good definition of what the system is supposed to do. An effective design is much more likely to follow a clear understanding of the system requirements.

The two UML representations principally used to define the system requirements are Use Case Diagrams and Sequence Diagrams.

Use Case Diagrams
Use Case Diagrams show interactions between so-called actors and the system. Actors can represent actual physical users as well as devices and other external entities connected to the system. Use cases represent the functional capabilities of the system. Use Case Diagrams are employed to establish a set of functional, testable uses of the system that satisfy the system's stated requirements. Each Use Case also includes a brief description of the capability or interaction you are defining.

Figure 2 shows the simplicity of the notation for a Use Case Diagram. The diagram has an actor stick figure representing the external user (or device), connected by a line to a Use Case bubble containing the name of the interaction, and an attached textual description. More complicated decomposition is possible with include or extend relationships, which deal with potentially common cases and special situations, respectively.

Figure 2:  With a Use Case Diagram, you can graphically show system capabilities and interactions

In this example, the main external actors are the operator who manages the system and containers being managed by the system. The major functions identified in the Use Case bubbles map onto system requirements. A reasonably interesting system will likely have several Use Cases, sometimes based on alternate operational modes of the system, such as normal, maintenance, and so on.

Use Cases provide a simple and straightforward mechanism for organizing and representing a system's major functional elements. Users, managers, and developers can all understand the notation and description as they discuss the system's basic operational requirements.

Sequence Diagrams
Each Use Case describes some important functional capability of the system. The textual description of the Use Case often provides sufficient detail, but to better understand the various scenarios that could arise during Use Case execution, you can elaborate the descriptions with one or more Sequence Diagrams. These diagrams allow users to define the functional requirements of the system at a finer level of detail.

The Sequence Diagram captures a specific scenario or processing thread through the system. A powerful approach illustrated in Figure 3, is to describe a sequence using a pseudo-code-like structure on the left-hand side of the Sequence Diagram. This structure may optionally contain constructs for selection (choice) and iteration, which allow many actual scenarios through the sequence. This layering of decomposition from Use Cases, to Sequence Diagrams, to specific scenarios is one way that the UML allows us to deal with larger and more complex systems.

As part of the requirements analysis, it is also useful to conduct an initial object-identification exercise. The objects involved in each Sequence Diagram will support the responsibilities of the system necessary to deliver the functionality of the Use Case. No formal UML views are involved at this point, but the Class Diagram is one place to store the names of the objects you are identifying. A common Data Dictionary is also a very good place to begin capturing object information. You'll use the objects found during this step in the construction of the right-hand, message sequence portion of the Sequence Diagram.

As shown in Figure 2, the actors of our Process Control System are tied to specific operational capabilities of the requirements model. In Figure 3, the Process Containers Use Case is expanded. The diagram maps the individual sequence actions on the left-hand side to object interactions on the right-hand side. Each action is associated with a message passing between two preliminary objects, or with an actor. The objects and actors are represented with vertical lines, and the messages are represented as horizontal lines between objects. The messages may also have parameters, for example, the "FrameId" parameter of the "analyze" message. Communication between objects (or interactions) collectively implements a Use Case. The objects identified during this stage will likely be decomposed and elaborated in later stages of analysis and design. This is one of the fundamental aspects of using UML—the idea of future elaboration.

In addition to the system definition constructed by analyzing the system's requirements, it is necessary to construct a design for the solution that describes the details of how you will implement the solution. System definition and solution design may well overlap, which is acceptable so long as there is feedback and iteration between the two. The two resulting models address the what and the how aspects of the required system.

Typically, a developer will produce a high-level architectural design that forms the basis for a controlled, iterative, elaboration approach to developing the lower-level details. You can exploit several UML diagrams during this stage. The following sections will focus on the three primary design views of the system: Class Diagrams, Collaboration Diagrams, and State Diagrams.

Class Diagrams
Class Diagrams form the basis for the object architecture of the system, where objects identified in earlier analysis steps are organized into a set of inter-related classes with interfaces (Figure 4). The class icons on a Class Diagram have three possible parts: the class name, a list of attributes managed by the class, and a list of operations defined for that class. Classes can be packaged into larger groupings; for example, the Plant Control package collects all the classes involved in the core-application domain.

The static relationships between the classes are generalization, aggregation, and association. The generalization relationship captures the levels of abstraction of the object architecture. Through a hierarchy of super-class and sub-class relationships, you define the differences between object characteristics. The simple premise that a sub-class inherits all of the characteristics of its parent class allows for a powerful ability to program by difference. This approach generalizes the common attributes and operations up the hierarchy and specializes the differences down the hierarchy. Figure 4 shows the cEquipment class hierarchy allows us to define a general-purpose piece of equipment that has standard operations. Each specific type of equipment in our system is built from the cEquipment parent.

The aggregation relationship provides the basic mechanism for composition. The fact that an object can be made up of other objects allows for convenient structural composition with clearly defined boundaries. By aggregating smaller, more specific objects into larger, more complex objects, a developer can manage overall system complexity using basic object-oriented principles. Figure 4 shows an example of an aggregation relationship in the construction the cImage class from its constituent cFrames.

Not all objects are part of a generalization hierarchy or aggregation, but in order for any two objects to interact (send messages), there needs to be some form of relationship between them. The association relationship provides the required mechanism for this capability. Figure 4 shows an example of an association between a piece of Equipment and the Container that it is currently processing. Clearly, there will be some communication between these objects and this relationship establishes the structure and visibility necessary to perform the messaging.

Collaboration Diagrams
Where the Class Diagram defines a static relationship structure between classes and objects of those classes, the Collaboration Diagram defines a communication structure between the objects. Collaboration Diagrams can detail specific scenarios outlined in Sequence Diagrams. Figure 5 shows a specific scenario of scanning a container, where the numbers shown in the figure imply event sequence.

Figure 5:  The Collaboration Diagram defines a communications structure between objects, thus detailing scenarios outlined in a Sequence Diagram.

By analyzing several Sequence Diagrams together as a whole and representing the overall connectivity of the objects involved in those scenarios on a Collaboration Diagram, you can visualize the communication architecture of the proposed design. This view also facilitates the proper class relationship structures in the Class Diagram, since one could ask a question such as "If these two objects are talking to each other, then what kind of relationship exists between them?"

State Diagrams
The state diagram is the principle diagram used in UML to describe the behavior of objects in the class structure. These diagrams will be familiar to many electrical engineers although the UML uses a powerful form of structured state-chart based on the work of Harel.

Figure 6:  This State Diagram shows the various states of the cContainer

As the object progresses along the belt, each piece of equipment triggers a state change by sending an event—for example, the scanner sends a scanResult that dictates whether the container needs to be specially routed or caged normally.

UML also has an Activity Diagram, which uses a more flow-chart-based approach to describing behavior. In practice, most control-oriented behavior is better described by state diagrams.

Two UML diagrams are used to show implementation—the Component Diagram, for describing physical software artifacts such as executable programs and libraries, and the Deployment Diagram, to document the actual hardware the system uses. These diagrams are the simplest and least developed of the UML diagrams—both urgently need improving to be useful in the real-time/embedded domain.

About the Author Alan Moore is the Vice President for Product Strategy at Artisan Software. Alan has 15 years of experience in the development of real-time and object-oriented methodologies and their applications in a variety of problem domains. He has been actively involved in product development, training, and consulting related to OOAD and structured development tools during that time. Alan has co-authored a book on GUI design, published several papers, and has lectured on a wide variety of analysis and design issues. Alan is responsible for the specification, planning, and management of the ARTiSAN product strategy. He is the author of ARTiSAN "Real-time Perspective," a pragmatic approach to the development of real-time systems, and is an active participant in the Real-time Analysis and Design Group (RTAD) of the Object Management Group (OMG).