mywbut.com

UML Diagrams

Overview

UML was designed to be the distillation of best practices in software development. To accomplish this ambitious goal, UML provides an extensive set of diagramming tools. Because UML is such a big subject and the diagramming tools are so diverse I thought it would be helpful to give you an overview of the diagrams themselves. This chapter presents some samples of each diagram with a brief introduction describing the purpose and benefits of each diagram.

As a kind of roadmap I'll use the UML groupings that divide the diagrams into packages based on their roles in the Model Management, Structural, and Behavioral aspects of system design.

Model Management diagrams include Packages, which are used to represent Subsystems, Models, and more.

Structural diagrams include the Class diagram, Object diagram, Composite Structure diagram, Component diagram, Deployment diagram, and the Combined Component and Deployment diagram.

Behavioral diagrams include the Use Case diagram, Activity diagram, Interaction diagrams, State Machine diagram, and Protocol State Machine diagram.

UML Diagrams and Work Products

Each diagram reveals a unique yet overlapping view of a system. That sounds a bit strange. How can a diagram be unique yet overlap other diagrams? The uniqueness comes from the different perspective taken by each diagram. The overlap comes from the fact that all of the diagrams are looking at the same problem.

The big question that usually crops up about now is, "Why do I have to use all these diagrams? Joe and Susan have always just drawn Class diagrams." This question is valid. For small, simple projects you may not need to create all these diagrams. But I suspect that one reason you're reading this book is that you don't work on small projects, and the projects you do work on get pretty complicated.

When the projects become large and complicated, you often move from one piece of the project to another in rapid succession. Coming back to something you worked on a few days ago often means hours of getting your head back into a pile of notes and/or mountains of code, much of it not your own. It also means that there is no realistic way to know how right you are until you build enough code to run tests. By then you have used up a large part of the project schedule, and if you find problems it is difficult to justify the extra time to do a lot of rewriting. If only we got paid by the hour….

1 mywbut.com

So how does a diverse set of diagrams help? Consider a common example from everyday life. Suppose you're in a car accident at an intersection. Someone runs a red light and broadsides your car. A police officer shows up, walks over to a witness, and takes her story. She says that you ran the red light, not the other person. Then the officer leaves assuming he has the truth. How do you feel? Outraged, I imagine. But the officer talked to a "client" and captured the facts just like we typically gather requirements from our clients. So what's the problem?

The problem is that the officer did nothing to verify his facts. He should have asked the other witnesses for their perspectives. After he got information from a variety of sources he would have a set of accounts looking at the same set of facts but from different perspectives. If he compared the stories, he would discover two things. First, some of the information from different testimonies will agree. He could reasonably assume that those portions of the accounts are true. Second, the portions that didn't line up could not be trusted until he could find corroborating evidence.

Dealing with many different views of a software or business problem works the same. Each diagram describes the problem in a different way, just like different witnesses describe an incident. The diagrams will overlap because they describe the same body of facts. If they agree where they overlap, you can relax knowing you've probably got it right. If they don't agree, then you have some homework to do to reconcile the differences. Now here are the two really-great benefits:

. When the viewpoints disagree, you've pinpointed where you need to invest your effort. . When all the viewpoints agree, you know you're done.

How many times have you sat in a status meeting trying to come up with a way to describe how much progress you've made and what remains to be done? Often we get stuck "guesstimating" a percentage of completion. The question is, "a percentage of what?"

Instead, wouldn't it be nice to be able to say something like, "We have 28 business requirements so far. Seventeen have been completely reviewed and approved with clients. The clients tell us that we've identified all of the critical business requirements but there are maybe five more low-priority requirements that we need to document. Of the 17, we have fully modeled 12. Based on the time we have invested so far, we estimate another week to finish the remaining five, and three weeks to finish the other eleven."

Even better, the more practice you get and the more metrics you keep on each modeling effort, the more reliable your estimates become.

Structural Diagrams

Structural diagrams illustrate the static features of a model. Static features include classes and association, objects and links, and collaborations. These static features provide the framework in which the dynamic elements of the model execute. For example, a Class defines the behaviors that types of objects can provide. An association defines the type of relationship that objects can participate in. A

2 mywbut.com

Deployment diagram models pieces of hardware (and people) that can perform work. Components define pieces of software and procedures that need to be deployed to processors.

The structural diagrams function much like a blueprint for building a house or a piece of equipment. They show the parts and how they can be assembled, but they cannot show how the finished product will behave.

Class diagram

The Class diagram is at the heart of the object modeling process. It models the definitions of resources essential to the proper operation of the system. All of the other modeling diagrams discover information about these resources (such as attribute values, state, and constraints on behavior) that ultimately must make its way onto the Class diagram. The Class diagram is the source for code generation (converting a model to code) and the target for reverse engineering (converting code to a model).

The Class diagram models the resources used to build and operate the system. Resources represent people, materials, information, and behaviors. Class diagrams model each resource in terms of its structure, relationships, and behaviors. The notation is surprisingly simple. Figure below models a class with the three predefined compartments found in nearly every class: name, attribute, and operations.

Figure: A class with the three predefined compartments.

But I said that the Class diagram models resources and relationships between resources. Next figure models two classes and the relationship between them. In the theater system a venue manager authorizes agents to sell tickets. Over time an agent may be authorized by any number of different venue managers. The model defines how many objects may participate in the relationship and may even set rules defining which objects can participate.

3 mywbut.com

Figure: A Class diagram with a relationship called "authorizes."

You will likely have a number of Class diagrams on a project. Each will focus on the resources for a specific subject area. This is one example of where Package diagrams come into play. A Class diagram for the resources required to manage a venue can be placed in one package. A Class diagram for the resources to manage agents can be in another package. Because all the diagram elements for a project are stored in the same repository, regardless of package, you can reference any of these resources on any diagram merely by using the proper naming convention using the import concept .

Class diagrams are valuable because they

. Define the essential resources of a system. . Define relationships between resources. . Generate code. . Model code (reverse engineering). . Provide a focus for all the other diagrams.

Object diagram

While the Class diagram models the definitions of resources, the Object diagram models facts or examples. Above figure shows a Class diagram that defines venue managers, agents, and their relationship. Figure given below presents an Object diagram that models one specific agent, Mike, and two specific venue managers, Susan and Bill, and the relationships between the three people. In most modeling tools you draw an Object diagram in the same facility/canvas as the Class diagram.

4 mywbut.com

Figure: Object diagram.

An Object diagram is most useful in the early phases of a project for modeling examples. Examples often can uncover the rules that need to be part of the definitions of the resources and their relationships. Later in the project the Object diagram is useful for modeling test cases to see whether the Class diagram is correct and complete.

Object diagrams are valuable because they

. Support the investigation of requirements by modeling examples from the problem domain (that may later be used as test cases). . Model test cases to validate the Class diagram.

Composite Structure diagram

The Composite Structure diagram is new in UML 2.0. It represents the functionality formerly described using Composite Context diagrams and collaborations (not the same as Collaboration diagrams). The concept of the Composite Structure diagram is to visually represent the parts of a class, component, or collaboration, including the interaction points (called ports) used to access features of the structure.

Figure below models a simple Composite Structure diagram of a pricing strategy from the theater system. A pricing strategy is built using a discount and a set of price tiers.

Figure: Composite Structure diagram of a pricing strategy.

5 mywbut.com

The Composite Structure diagrams also model collaborations. A collaboration describes a behavior, the resources used to perform the behavior, and the roles the participating resources assume during the behavior. Figure below models a collaboration in which a venue manager secures the services of an agent.

Figure 3-8: A Composite Structure diagram representing a collaboration.

Composite Structure diagrams are valuable because they

. Reveal the design of a complex component. . Reveal the interface to a component separate from its structure. . Describe the roles that elements play in the structure to fulfill the purpose of the structure and to satisfy the required interactions.

Component diagram

The Component diagram represents pieces of software in the implementation environment. Where the Class and Package diagrams model the logical design of the software, the Component diagram models the implementation view. For example, an Order class could be generated as an EJB component. An OrderEntry class could be generated as an HTML page. Figure 3-9 uses the component notation of UML 1.4 to represent browsers, JavaBeans, JSPs, and HTML. You can also use components to represent source code, XML, ASP, or virtually any piece of software.

Note that the Component diagram uses dependencies in the same manner that the Package diagram uses them. The successful operation of one component depends on its ability to communicate with the other component.

6 mywbut.com

Figure: UML 1.4 Component diagram using components and dependencies.

Component diagrams are valuable because they

. Model the real software in the implementation environment. . They reveal software configuration issues through the dependency relationships. . They can provide an accurate picture of existing systems prior to making changes or enhancements. . They can reveal bottlenecks in an implementation without forcing you to read all of the code.

Deployment diagram

The Deployment diagram models the hardware of the implementation environment. Each node on a Deployment diagram typically represents one type of hardware, such as a disk drive, a client PC, a server, or a processor. A node may also represent a human being or organizational unit, or more precisely, the function that a person can perform. Nodes are like classes in that respect. They represent a type of device, not a specific device, and the features of each device. Like classes they are related using associations that explain how the nodes may be connected. Figure below models a Deployment diagram with four nodes: a database server, a middleware server, and two types of client devices.

7 mywbut.com

Figure: Deployment diagram with four nodes and their connections.

Class diagrams are valuable because they

. Model the hardware platform for a system. . Identify hardware capabilities that affect performance planning and software configuration.

Combined Component/Deployment diagram

By far the most common application of the Component and Deployment diagrams is to use them in a combined view that shows components installed on nodes. This view provides insights about the mapping of the communication requirements of the software to the physical properties of the nodes and connections of the implementation platform. Figure below shows the two diagrams combined into one, revealing components installed on each node and the dependencies that cross the hardware boundaries.

8 mywbut.com

Figure 3-12: Combined Component and Deployment diagram.

Combined Deployment and Component diagrams are valuable because they

. Provide a view of the performance issues of an implementation, that is, software running on devices, communication requirements across physical connections, and software migration across nodes. . Provide a visual check on the complexity of an implementation that aids partitioning and reconfiguration.

Behavioral Diagrams

Behavioral diagrams describe how the resources modeled in the Structural diagrams interact and how they each execute their capabilities. The behavioral diagram puts the resources in motion, in contrast to the structural view, which provides a static definition of the resources.

Use Case diagram

The Use Case diagram models the users' expectation for using the system. The people and systems that interact with the target system are called actors. The features of the system that the actors use are called use cases. Some use cases interact with other use cases, a relationship modeled using dependency arrows.

9 mywbut.com

The goal of the Use Case diagram is to identify all the features that the clients expect the system to support, but it does not reveal any details about the implementation of these features. Use cases can be written many different ways but the most common is to represent a view of the system from outside the system. For example, when a customer approaches the sales portion of the theater systems, he might expect to see features that let him place an order by selecting a performance, selecting seats at the performance, and paying for the order. Figure below models the customer's view of the system features.

Figure: Use Case diagram showing the customer's expectations for using the sales system.

Use Case diagrams are valuable because they

. Identify the clients' expectations for the system. . Identify specific features of the system. . Identify shared behavior among system features. . Provide a simple and easily understood way for clients to view their requirements.

Activity diagram

The Activity diagram models logic-any logic-from workflow to use cases to methods. It borrows most of its notation from flowcharts, but has added the concept of concurrency to support many modern applications. Figure below models the use case "Select Performance" from Figure given above. The arrows trace the flow from beginning to end through decisions and loops, while identifying each logic step in the process.

10 mywbut.com

Figure: Activity diagram for selecting a theater performance.

Activity diagrams are valuable because they

. Represent the logic required to implement system behaviors. . Represent logic at any level the design needs, from system workflow to individual method implementations. . Are simple enough to learn quickly. . Are relatively familiar to users since they are often used in business training and procedures manuals.

Sequence diagram

The Sequence diagram originated with James Rumbaugh and the Object Modeling Technique (OMT). The focus of the diagram is on identifying interactions between objects over time. The major benefit of the diagram is that it helps identify the messages exchanged between objects. Exchanging messages requires a sender and receiver. A receiver must have an interface in order to receive a message. Hence, if a message must be sent from one object to another, the receiver must define an interface that

11 mywbut.com

conforms to the message. An interface is an operation signature on the class to which the receiving object belongs. The Sequence diagram helps us find and document new operations on-the Class diagram.

Figure below models three objects: a customer actor, a theater system, and a venue, and three messages. The theater system asks the venue for a set of events taking place in a specified date range. The venue returns the set of events. The theater system then sends the events to the customer actor (user interface) to be displayed. The types of arrows describe the type of interaction. The messages become operation signatures. The returns help validate the interaction.

Figure: Sequence diagram of a portion of the "Select a Performance" use case.

Another benefit of the Sequence diagram is that it has a very narrow scope, typically, one scenario for one use case. A scenario describes one possible sequence of interactions when a use case executes. For example, when you attempt to pay for your order at the theater, your credit card is approved and you get your tickets, or your card is rejected and you don't get your tickets. These are two scenarios; each scenario is represented by one Sequence diagram.

Sequence diagrams are valuable because they

. Have a narrow focus that helps you see the specific questions, commands, and data being communicated during the execution of a specific task. It is not very easy to gloss over the details when the express design of the diagram reveals those details. . Explicitly identify the communication required to fulfill an interaction. This helps validate or discover the interfaces required by a class. . Explicitly identify the objects that participate in an interaction. This helps validate or even discover the features of a class. . Explicitly identify the data that are passed as part of the interactions. The data have to belong to a class somewhere in the design. Tracking down the source of the data often reveals new interactions.

Collaboration diagram

The Collaboration diagram is almost exactly the same as the Sequence diagram. The difference is the perspective. Both diagrams model interactions between objects for a specific task, but while the Sequence diagram emphasizes the sequencing of interactions over time, the Collaboration diagram models how the interactions utilize the structure of the participating objects and their relationships.

12 mywbut.com

Figure below presents the Collaboration diagram of the sequence of messages shown in the Sequence diagram segment in Figure given above.

Figure: A Collaboration diagram version of the "Select a Performance" sequence.

Collaboration diagrams are valuable because they

. Reveal the structural requirements for completing a task. They explicitly identify the objects that participate in an interaction. This helps validate or even discover the features of a class. . Reveal the interface requirements of the participating classes. . Identify the structural changes required to satisfy an interaction. . Explicitly identify the data that is passed as part of the interactions. The data have to belong to a class somewhere in the design. Tracking down the source of the data often reveals new interactions.

Extensibility mechanisms

UML formally uses the expression extensibility mechanisms to refer to stereotypes, tagged values, and constraints. These three constructs provide the ability to customize UML diagrams for a specific subject and/or platform. These constructs appear as adornments to standard UML notation. Work is also being done for subsequent UML versions to provide extensibility through the use of metaclasses, an approach that can handle the bigger challenges of frameworks and distributed business components.

Stereotypes, tagged values, and constraints will appear on nearly every diagram type described in this book. Stereotypes identify a set of qualities that may appear on a number of diagram elements. Tagged values allow you to add new features to an element of the diagram. Constraints define rules to protect the integrity of a diagram element. All three mechanisms are defined here and applied throughout the diagram descriptions.

13 mywbut.com

Stereotypes

The UML 2.0 specification defines stereotype as

A new type of modeling element that extends the semantics of the metamodel. Stereotypes must be based on certain existing types or classes in the metamodel. Stereotypes may extend the semantics, but not the structure of pre-existing types and classes. Certain stereotypes are predefined in the UML, others may be user defined. Stereotypes are one of three extensibility mechanisms in UML. (UML 2.0)

A stereotype is a common concept used in ordinary conversation. For example, on entering a meeting, I might point out to a colleague that the three people on the right side of the room are accounting folk, the four to our left are sales, and so on. My colleague understands that these labels identify a set of qualities like skill sets, knowledge about the project, and so forth. The labels do not explain or define their specific jobs. One of the accounting people might be a CPA, another a bookkeeper, and the other a manager.

In the same manner, within a software design, I might designate some classes as user interface classes, others as controllers, and still others as utilities. The interface classes might be as diverse as buttons, frames, drop-down lists, or graphics. But all these classes are still tools for building a user interface.

Stereotype notation encloses the label in guillemets (French quotes) as in «user interface» or «controller». The stereotype is then added to the description of the model elements, the icons containing the name, and other features. Figure below provides three examples of the application of stereotypes. The first is a stereotype on a dependency between two use cases, the second is a stereotype on a class, and the third is a stereotype on the dependency between two packages.

14 mywbut.com

Figure: Three examples of the application of stereotypes.

A number of stereotypes have already been defined within UML. They are called Standard Elements because they are provided as part of the UML standard.

While these existing stereotypes are useful, they do not prevent you from creating your own. By definition a stereotype is a means to extend UML, to add new concepts that augment and customize its standard modeling elements. The goal of providing this mechanism is to allow users to tailor their use of UML without having to create new model elements or even a new language that fits their particular domain or platform.

In my earlier description of a stereotype, I said that a stereotype brings with it some information about the entities that share the stereotype. For example, the accounting folks bring specific knowledge to the project about how the accounting processes and policies work. This stereotype-related information is attached to a stereotype using tagged values, the next topic in the description of extension mechanisms.

Constraints

The UML 2.0 specification defines constraint as

A semantic condition or restriction. Certain constraints are predefined in the UML, others may be user defined. Constraints are one of three extensibility mechanisms in UML. (UML 2.0)

Like stereotypes, constraints appear throughout UML diagrams. Constraints define the invariants that preserve the integrity of the system.

A constraint defines a condition that must hold true for the duration of the context in which it is defined. A constraint on an attribute value for an object holds true for the life of the object. A constraint on an object state holds true as long as the object is that state. A constraint on an operation holds true for the duration of the attempt to execute the operation.

A constraint is enclosed within curly braces {}. For example, an attribute called name on a theater performance might limit the length to 50 alpha characters, including spaces and punctuation but no special characters. The constraint may be expressed by placing the preceding text inside curly brackets, as in {up to 50 alpha characters, including spaces and punctuation but no special characters}. Figure below models the Sales Agreement class with a constraint on the attribute endDate. The end date must be no less than the start date. The constraint on the relationship states that there may be any number (zero or more) sales agreements for each contract but the dates for the sales agreements must not overlap.

15 mywbut.com

Figure: Constraints on attributes and associations.

Note Curly braces are also used for properties.

Constraints are often expressed more formally using the UML Object Constraint Language (OCL). For example, the endDate constraint could be expressed in OCL as context SalesAgreement inv: - - definition of an invariant endDate =< startDate.

The first line is a definition statement that establishes the context for the statement as being within the SalesAgreement class. The double dash designates a comment. The second line is the actual constraint stating that the end date of the sales agreement must always be equal to or greater than the start date.

Constraints support traversing links, working with groups of items, and enumerations. Constraints are most often applied to attributes and associations, but may also apply to stereotypes, messages, and actions.

Comments

Since it is impossible to provide a notation for everything that could be expressed in a project, UML provides the capability to attach freeform text to any element in the model. Comments may be attached to individual attributes, operations, associations, messages, objects, anything in a UML model.

16 mywbut.com

Figure below models a comment attached to a class. Comments are enclosed in a box with a "folded" top right corner.

Figure: A comment attached to a class.

17