Learning UML 2.0 | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Unified Modeling Language (UML) is the standard modeling language for software and systems development. This statement alone is a pretty conclusive argument for making UML part of your software repertoire, however it leaves some questions unanswered. Why is UML unified? What can be modeled? How is UML a language? And, probably most importantly, why should you care?

Systems design on any reasonably large scale is difficult. Anything from a simple desktop application to a full multi-tier enterprise scale system can be made up of hundreds—and potentially thousands—of software and hardware components. How do you (and your team) keep track of which components are needed, what their jobs are, and how they meet your customers' requirements? Furthermore, how do you share your design with your colleagues to ensure the pieces work together? There are just too many details that can be misinterpreted or forgotten when developing a complex system without some help. This is where modeling—and of course UML—comes in.

In systems design, you model for one important reason: to manage complexity. Modeling helps you see the forest for the trees, allowing you to focus on, capture, document, and communicate the important aspects of your system's design.

A model is an abstraction of the real thing. When you model a system, you abstract away any details that are irrelevant or potentially confusing. Your model is a simplification of the real system, so it allows the design and viability of a system to be understood, evaluated, and criticized quicker than if you had to dig through the actual system itself. Even better, with a formal modeling language, the language is abstract yet just as precise as a programming language. This precision allows a language to be machine-readable, so it can be interpreted, executed, and transformed between systems.

To effectively model a system, you need one very important thing: a language with which the model can be described. And here's where UML comes in.

A modeling language can be made up of pseudo-code, actual code, pictures, diagrams, or long passages of description; in fact, it's pretty much anything that helps you describe your system. The elements that make up a modeling language are called its

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A modeling language can be made up of pseudo-code, actual code, pictures, diagrams, or long passages of description; in fact, it's pretty much anything that helps you describe your system. The elements that make up a modeling language are called its notation . Figure 1-1 shows an example of a piece of UML notation.

Figure 1-1: A class declaration as it can be shown using UML notation

There are references to the UML meta-model and profiles throughout this book. A more complete description of what the UML meta-model contains and why it is useful is available in Appendix B, but for now, just think of the UML meta-model as the description of what each element of notation means and a profile as a customization of that description for a specific domain (i.e., banking).

However, notation is not the whole story. Without being told that one of the boxes in Figure 1-1 represents a class, you wouldn't necessarily know what it is, even though you might be able to guess. The descriptions of what the notation means are called the semantics of the language and are captured in a language's meta-model.

A modeling language can be anything that contains a notation (a way of expressing the model) and a description of what that notation means (a meta-model). But why should you consider using UML when there are so many different ways of modeling, including many you could make up on your own?

Every approach to modeling has different advantages and disadvantages, but UML has six main advantages:

It's a formal language: Each element of the language has a strongly defined meaning, so you can be confident that when you model a particular facet of your system it will not be misunderstood.
It's concise: The entire language is made up of simple and straightforward notation.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The first version of UML allowed people to communicate designs unambiguously, convey the essence of a design, and even capture and map functional requirements to their software solutions. However, the world changed more fundamentally with the recognition that systems modeling, rather than just software modeling, could also benefit from a unified language such as UML.

The driving factors of component-oriented software development, model-driven architectures, executable UML, and the need to share models between different tools placed demands on UML that it had not originally been designed to meet.

Also, UML 1.x and all of its previous revisions were designed as a unified language for humans. When it became important for models to be shared between machines—specifically between Computer Aided Systems Engineering (CASE) tools—UML 1.x was again found wanting. UML 1.x's underlying notation rules and its meta-model were (ironically) not formally defined enough to enable machine-to-machine sharing of models.

Two reasonably new approaches to system development inspired many of the improvements made in UML 2.0. In a nutshell, Model Driven Architectures (MDAs) provide a framework that supports the development of Platform Independent Models (PIMs) —models that capture the system in a generic manner that is divorced from concerns such as implementation language and platform.

PIMs can then be transformed into separate Platform Specific Models (PSMs) that contain concrete specifications for a particular system deployment (containing details such as implementation language and communications protocols, etc.). MDA requires a formally structured and interoperable meta-model to perform its transformations, and this level of meta-model is now provided by UML 2.0.

For many of the same reasons, executable UML provides a means by which a PSM could contain enough complete information so that the model can be effectively run. Some day, you could conceivably drag around a few symbols, and complete, runnable software would pop out! An executable UML engine requires that the UML model be defined well enough for it to be able to generate and execute the modeled system.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Many newcomers to UML focus on the different types of diagrams used to model their system. It's very easy to assume that the set of diagrams that have been created actually are the model. This is an easy mistake to make because when you are using UML, you will normally be interacting with a UML tool and a particular set of diagrams. But UML modeling is not just about diagrams; it's about capturing your system as a model—the diagrams are actually just windows into that model.

A particular diagram will show you some parts of your model but not necessarily everything. This makes sense, since you don't want a diagram showing everything in your model all at once—you want to be able to split contents of your model across several diagrams. However, not everything in your model needs to exist on a diagram for it to be a part of your model.

So, what does this mean? Well, the first thing to understand is that your model sits behind your modeling tool and diagrams as a collection of elements. Each of those elements could be a use case, a class, an activity, or any other construct that UML supports. The collection of all the elements that describe your system, including their connections to each other, make up your model.

However, if all you could do was create a model made up of elements, then you wouldn't have much to look at. This is where diagrams come in. Rather than actually being your model, diagrams are used merely as a canvas on which you can create new elements that are then added to your model and organize related elements into a set of views on your underlying model.

So, when you next use your UML tool to work with a set of diagrams in UML notation, it is worth remembering that what you are manipulating is a view of the contents of your model. You can change elements of your model within the diagram, but the diagram itself is not the model—it's just a useful way of presenting some small part of the information your model contains.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

UML can be used as much or as little as you like. Martin Fowler describes three common ways that people tend to use UML:

UML as a sketch: Use UML to make brief sketches to convey key points. These are throwaway sketches—they could be written on a whiteboard or even a beer coaster in a crunch.
UML as a blueprint: Provide a detailed specification of a system with UML diagrams. These diagrams would not be disposable but would be generated with a UML tool. This approach is generally associated with software systems and usually involves using forward and reverse engineering to keep the model synchronized with the code.
UML as a programming language: This goes directly from a UML model to executable code (not just portions of the code as with forward engineering), meaning that every aspect of the system is modeled. Theoretically, you can keep your model indefinitely and use transformations and code generation to deploy to different environments.

The approach used depends on the type of application you're building, how rigorously the design will be reviewed, whether you are developing a software system, and, if it is software, the software development process you're using.

In certain industries, such as medical and defense, software projects tend to lean toward UML as a blueprint because a high level of quality is demanded. Software design is heavily reviewed since it could be mission-critical: you don't want your heart monitoring machine to suddenly display the "blue screen of death."

Some projects can get away with less modeling. In fact, some commercial industries find that too much modeling is cumbersome and slows down productivity. For such projects, it makes sense to use UML as a sketch and have your model contain some architectural diagrams and a few class and sequence diagrams to illustrate key points.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When you are using UML to model a software system, the "degree of UML" you apply is partially influenced by the software development process you use.

A software development process is a recipe used for constructing software—determining the capabilities it has, how it is constructed, who works on what, and the timeframes for all activities. Processes aim to bring discipline and predictability to software development, increasing the chance of success of a project. Since UML is the language for modeling your software, it's an important part of the software development process.

A few well-known software development processes include:

Waterfall: The waterfall method attempts to pin down the requirements early in the project life cycle. After gathering requirements, software design is performed in full. Once the design is complete, the software is implemented. The problem with this method is that if a change in requirements occurs, the impact can be devastating.
Iterative: Iterative methods attempt to address the shortcomings of the waterfall approach by accepting that change will happen and, in fact, embracing it. The Unified Process is a well-known iterative process. It consists of multiple phases, each phase containing some amount of the following activities: requirements, design, and implementation (coding). Iterative methods encompass a wider range of approaches (e.g., agile iterative processes), and they can range from using UML as sketch to using UML as blueprint.
Agile methods: Agile methods use iterations in extremely short bursts and attempt to minimize risk by always having a working system of expanding capabilities. Methodologies under this category have introduced some of the more interesting development practices, such as pair programming and test-driven development. Agile methods emphasize using UML as a sketch.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There are a number of ways to break up your UML model diagrams into perspectives or views that capture a particular facet of your system. In this book, we use Kruchten's 4+1 view model to help you show you how each diagram type plays a part in the overall model, as shown in Figure 1-7.

Figure 1-7: Philippe Kruchten's 4+1 view model

The 4+1 view model breaks down a model into a set of views, each capturing a specific aspect of your system:

Logical view: Describes the abstract descriptions of a system's parts. Used to model what a system is made up of and how the parts interact with each other. The types of UML diagrams that typically make up this view include class, object, state machine, and interaction diagrams.
Process view: Describes the processes within your system. It is particularly helpful when visualizing what must happen within your system. This view typically contains activity diagrams.
Development view: Describes how your system's parts are organized into modules and components. It is very useful to manage layers within your system's architecture. This view typically contains package and component diagrams.
Physical view: Describes how the system's design, as described in the three previous views, is then brought to life as a set of real-world entities. The diagrams in this view show how the abstract parts map into the final deployed system. This view typically contains deployment diagrams.
Use case view: Describes the functionality of the system being modeled from the perspective of the outside world. This view is needed to describe what the system is supposed to do. All of the other views rely on the use case view to guide them—that's why the model is called 4+1. This view typically contains use case diagrams, descriptions, and overview diagrams.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before jumping into the different types of diagrams that make up UML, you need to know about two elements of UML notation that are used throughout a model: notes and stereotypes .

Notes allow you to enter additional comments that aren't captured in your diagrams. You can write anything you want in a note to explain your diagram, similar to a comment in code. Notes are pictured with the folded rectangle notation as shown in Figure 1-8.

Figure 1-8: A UML note

Notes can be placed on a diagram in isolation or attached to a specific part of the diagram as shown in Figure 1-9.

Figure 1-9: A note is attached to another element on the diagram using a dotted line

In this book, notes are used to explain something more about a particular diagram. Notes are just aids for the reader of a diagram; they don't change the meaning of the diagram or the underlying model at all.

Stereotypes signify a special use or intent and can be applied to almost any element of UML notation. Stereotypes modify the meaning of an element and describe the element's role within your model.

A stereotype sometimes has an associated icon, such as in Figure 1-10's stick-figure actor symbol. To learn more about actors, see Chapter 2.

Figure 1-10: The Administrator is represented in the role of an actor because it is using the stick figure notation associated with that stereotype

There isn't always a special icon for a stereotype; sometimes they take up too much room and clutter a diagram. In these cases, the stereotype is shown using guillemots at either end of the stereotype name, as in «stereotype_name», shown in Figure 1-11. However, because guillemots require an extended character set, you can substitute them for angle brackets, as in

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The next step is to jump into Chapter 2 and start learning UML. If you're a bit of a history buff, then you can also check out a brief history of UML in Appendix C.

UML is a concise language but a big subject. As well as learning about UML, it's worth reading through the tutorials and documentation available at the Object Management Group 's web site, http://www.omg.org.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Imagine that it's Monday morning and your first day on a new project. The requirements folks have just popped in for a coffee—and to leave you the 200-page requirements document they've been working on for the past six months. Your boss's instructions are simple: "Get your team up to speed on these requirements so that you can all start designing the system." Happy Monday, huh?

To make things just a bit more difficult, the requirements are still a little fuzzy, and they are all written in the language of the user—confusing and ambiguous natural language rather than in a language that your system stakeholders can easily understand. See the "Verbosity, Ambiguity, Confusion: Modeling with Informal Languages" section in Chapter 1 for more on the problems of modeling with natural and informal languages.

What is the next step, apart from perhaps a moment or two of sheer panic? How do you take this huge set of loosely defined requirements and distill it into a format for your designers without losing important detail? UML, as you know from Chapter 1, is the answer to both of these questions. Specifically, you need to work with your system's stakeholders to generate a full set of requirements and something new—use cases .

A use case is a case (or situation) where your system is used to fulfill one or more of your user's requirements; a use case captures a piece of functionality that the system provides. Use cases are at the heart of your model, shown in Figure 2-1, since they affect and guide all of the other elements within your system's design.

Figure 2-1: Use cases affect every other facet of your system's design; they capture what is required and the other views on your model, then show how those requirements are met

Use cases are an excellent starting point for just about every facet of object-oriented system development, design, testing, and documentation. They describe a system's requirements strictly from the outside looking in; they specify the value that the system delivers to users. Because use cases

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Enough theory for now; let's take a look at a simple example. Suppose we're defining requirements for a weblog content management system (CMS).

The terms shall and should have a special and exact meaning when it comes to requirements. A shall requirement must be fulfilled; if the feature that implements a shall requirement is not in the final system, then the system does not meet this requirement. A should requirement implies that the requirement is not critical to the system working but is still desirable. If a system's development is running into problems that will cause delivery delays, then it's often the should requirements that are sacrificed first.

Weblogs, commonly referred to as blogs, originally started out as privately maintained web pages for authors to write about anything. These days, blogs are usually packaged into an overall CMS. Bloggers submit new entries to the system, administrators allocate blogging accounts, and the systems typically incorporate advanced features, such as RSS feeds. A well-publicized blog can attract thousands of readers (see O'Reilly's blogging site at http://weblogs.oreillynet.com).

An actor is drawn in UML notation using either a "stick man" or a stereotyped box (see "Stereotypes" in Chapter 1) and is labeled with an appropriate name, as shown in Figure 2-2.

Figure 2-2 captures the Administrator role as it is described in Requirement A.1. The system that is being modeled is the CMS; the requirement's description indicates

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A use case describes the way your system behaves to meet a requirement. When filling out your use case descriptions, you will notice that there is some similarity between steps in different use cases. You may also find that some use cases work in several different modes or special cases. Finally, you may also find a use case with multiple flows throughout its execution, and it would be good to show those important optional cases on your use case diagrams.

Wouldn't it be great if you could get rid of the repetition between use case descriptions and show important optional flows right on your use case diagrams? OK, so that was a loaded question. You can show reusable, optional, and even specialized use case behavior between use cases.

So far, you have seen that use cases typically work with actors to capture a requirement. Relationships between use cases are more about breaking your system's behavior into manageable chunks than adding anything new to your system. The purpose of use case relationships is to provide your system's designers with some architectural guidance so they can efficiently break down the system's concerns into manageable pieces within the detailed system design.

In addition to blogs, a CMS can have any number of means for working with its content. One popular mechanism for maintaining documents is by creating a Wiki. Wikis allow online authors to create, edit, and link together web pages to create a web of related content, or a Wiki-web. A great example of a Wiki is available at http://www.Wikipedia.org.

Take another look at the Create a new Blog Account use case description shown in Table 2-2. The description seems simple enough, but suppose another requirement is added to the Content Management System.

To capture Requirement A.2 a new use case needs to be added to the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When you are trying to understand a system, it is sometimes useful to get a glimpse of the context within which it sits. For this purpose, UML provides the Use Case Overview diagram. Use Case Overview diagrams give you an opportunity to paint a broad picture of your system's context or domain (see Figure 2-16 for an example).

Figure 2-16: The CMS's context as shown on a Use Case Overview diagram

Unfortunately, Use Case Overviews are badly named as they don't usually contain any use cases. The use cases are not shown because the overview is designed to provide a context to your system; the system's internals—captured by use cases—are not normally visible.

Use Case Overviews are a useful place to show any extra snippets of information when understanding your system's place within the world. Those snippets often include relationships and communication lines between actors. These contextual pieces of information do not usually contain a great deal of detail, they are more a placeholder and starting point to for the rest of your model's detail.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Although this book, like UML, does not push any particular system development process, there are some common steps that are taken after the first cut of use cases are captured.

With your use case model in hand, it is often a good time to start delving into the high-level activities that your system will have to execute to fulfill its use cases. See Chapter 3 for information on activity diagrams.

Once you have a good grip on the high-level activities, look at the classes and components that will actually make up the parts of your system. You already might have some idea of what those classes contain, and so the next stop naturally would be to create a few rudimentary class diagrams. See Chapter 4 for information on class diagrams.

Regardless of your next step, just because you have a use case model does not necessarily mean that you are finished with use cases altogether. The only constant in life is change, and this certainly applies to your system's requirements. As a requirement changes—either because some new system constraint has been found or because a user has changed his mind—you need to go back and refine your use cases to make sure you are still developing the system that the users want.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Use cases show what your system should do. Activity diagrams allow you to specify how your system will accomplish its goals. Activity diagrams show high-level actions chained together to represent a process occurring in your system. For example, you can use an activity diagram to model the steps involved with creating a blog account.

Activity diagrams are particularly good at modeling business processes . A business process is a set of coordinated tasks that achieve a business goal, such as shipping customers' orders. Some business process management (BPM) tools allow you to define business processes using activity diagrams, or a similar graphical notation, and then execute them. This allows you to define and execute, for example, a payment approval process where one of the steps invokes a credit card approval web service—using an easy graphical notation such as activity diagrams.

Activity diagrams are the only UML diagram in the process view of your system's model, as shown in Figure 3-1.

Figure 3-1: The Process View shows the high-level processes in your system—this is exactly what activity diagrams are good at doing

Activity diagrams are one of the most accessible UML diagrams since they use symbols similar to the widely-known flowchart notation; therefore, they are useful for describing processes to a broad audience. In fact, activity diagrams have their roots in flowcharts, as well as UML state diagrams, data flow diagrams, and Petri Nets.

Let's look at the basic elements of activity diagrams by modeling a process encountered earlier in the book—the steps in the blog account creation use case. Table 3-1 contains the Create a new Blog Account use case description (originally Table 2-1). The Main Flow and Extension sections describe steps in the blog account creation process.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Let's look at the basic elements of activity diagrams by modeling a process encountered earlier in the book—the steps in the blog account creation use case. Table 3-1 contains the Create a new Blog Account use case description (originally Table 2-1). The Main Flow and Extension sections describe steps in the blog account creation process.

Table 3-1: Create a new Blog Account use case description
Use case name	Create a new Blog Account
Related Requirements	Requirement A.1.
Goal In Context	A new or existing author requests a new blog account from the Administrator.
Preconditions	The system is limited to recognized authors, and so the author needs to have appropriate proof of identity.
Successful End Condition	A new blog account is created for the author.
Failed End Condition	The application for a new blog account is rejected.
Primary Actors	Administrator.
Secondary Actors	Author Credentials Database.
Trigger	The Administrator asks the Content Management System to create a new blog account.
Main Flow	Step	Action
	1	The Administrator asks the system to create a new blog account.
	2	The Administrator selects an account type.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Actions are active steps in the completion of a process. An action can be a calculation, such as Calculate Tax, or a task, such as Verify Author's Details.

The word "activity" is often mistakenly used instead of "action" to describe a step in an activity diagram, but they are not the same. An activity is the process being modeled, such as washing a car. An action is a step in the overall activity, such as Lather, Rinse, and Dry.

The actions in this simple car-washing activity are shown in Figure 3-3.

Figure 3-3: Capturing the three actions—Lather, Rinse, and Dry—that make up washing a car in an activity diagram

In Figure 3-3, the entire activity is enclosed within the rounded rectangle called an activity frame . The activity frame is used to contain an activity's actions and is useful when you want to show more than one activity on the same diagram. Write the name of the activity in the upper left corner.

The activity frame is optional and is often left out of an activity diagram, as shown in the alternative Wash Car activity in Figure 3-4.

Figure 3-4: The activity frame can be omitted

Although you lose the name of the activity being displayed on the diagram itself, it is often more convenient to leave out the activity frame when constructing a simple activity diagram.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Decisions are used when you want to execute a different sequence of actions depending on a condition. Decisions are drawn as diamond-shaped nodes with one incoming edge and multiple outgoing edges, as shown in Figure 3-5.

Figure 3-5: Only one edge is followed after a decision node

Each branched edge contains a guard condition written in brackets. Guard conditions determine which edge is taken after a decision node.

They are statements that evaluate to true or false, for example:

[authorized]: If the authorized variable evaluates to true, then follow this outgoing edge.
[wordCount >= 100]: If the wordCount variable is greater than or equal to 1,000, then follow this outgoing edge.

The branched flows join together at a merge node, which marks the end of the conditional behavior started at the decision node. Merges are also shown with diamond-shaped nodes, but they have multiple incoming edges and one outgoing edge, as shown in Figure 3-6.

Figure 3-6: If the input value of age is 1200, then the Notify Blog Entry too long action is performed

Activity diagrams are clearest if the guards at decision nodes are complete and mutually exclusive. Figure 3-7 shows a situation in which the paths are not mutually exclusive.

If an item is in stock and the order is a rush order, then two guards evaluate to true. So which edge is followed? According to the UML specifications, if multiple guards evaluate to true, then only one edge is followed and that choice is out of your control unless you specify an order. You can avoid this complicated situation by making guards mutually exclusive.

The other situation to avoid is incomplete guards. For example, if Figure 3-7 had no guard covering out of stock items, then an out of stock item can't follow any edge out of the decision node. This means the activity is frozen at the decision node. Modelers sometimes leave off guards if they expect a situation not to occur (or if they want to defer thinking about it until later), but to minimize confusion, you should always include a guard to cover every possible situation. If it's possible in your activity, it's helpful to label one path with

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Consider a computer assembly workflow that involves the following steps:

Prepare the case.
Prepare the motherboard.
Install the motherboard.
Install the drives.
Install the video card, sound card, and modem.

So far we've covered enough activity diagram notation to model this workflow sequentially. But suppose the entire workflow can by sped up by preparing the case and the motherboard at the same time since these actions don't depend on each other. Steps that occur at the same time are said to occur concurrently or in parallel.

Figure 3-8: In UML 2.0, it's better to be as clear as possible and to show merge nodes

You represent parallel actions in activity diagrams by using forks and joins, as shown in the activity diagram fragment in Figure 3-9.

Figure 3-9: Both outgoing paths are followed at the fork, in contrast with decision nodes, where only one outgoing path is taken

After a fork in Figure 3-9, the flow is broken up into two or more simultaneous flows, and the actions along all forked flows execute. In Figure 3-9, Prepare Case and Prepare Motherboard begin executing at the same time.

The join means that all incoming actions must finish before the flow can proceed past the join. Forks and joins look identical—they are both drawn with thick bars—but you can tell the difference because forks have multiple outgoing flows, whereas joins have multiple incoming flows.

In a detailed design model, you can use forks to represent multiple processes or multiple threads in a program.

Figure 3-10 completes the activity diagram for the computer assembly workflow.

Figure 3-10: The computer assembly workflow demonstrates how forks and joins work in a complete activity diagram

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Sometimes time is a factor in your activity. You may want to model a wait period, such as waiting three days after shipping an order to send a bill. You may also need to model processes that kick off at a regular time interval, such as a system backup that happens every week.

Time events are drawn with an hourglass symbol. Figure 3-11 shows how to use a time event to model a wait period. The text next to the hourglass—Wait 3 Days—shows the amount of time to wait. The incoming edge to the time event means that the time event is activated once. In Figure 3-11, the bill is sent only once—not every three days.

Figure 3-11: A time event with an incoming edge represents a timeout

A time event with no incoming flows is a recurring time event, meaning it's activated with the frequency in the text next to the hourglass. In Figure 3-12, the progress bar is updated every second.

Figure 3-12: A time event with no incoming flows models a repeating time event

Notice that there is no initial node in Figure 3-12; a time event is an alternate way to start an activity. Use this notation to model an activity that is launched periodically.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As detail is added to your activity diagram, the diagram may become too big, or the same sequence of actions may occur more than once. When this happens, you can improve readability by providing details of an action in a separate diagram, allowing the higher level diagram to remain less cluttered.

Figure 3-13 shows the computer assembly workflow from Figure 3-10, but the Prepare Motherboard action now has an upside-down pitchfork symbol indicating that it is a call activity node. A call activity node calls the activity corresponding to its node name. This is similar to calling a software procedure.

Figure 3-13: Rather than cluttering up the top-level diagram with details of the Prepare Motherboard action, details are provided in another activity diagram

The Prepare Motherboard node in Figure 3-13 invokes the Prepare Motherboard activity in Figure 3-14. You associate a call activity node with the activity it invokes by giving them the same name. Call activities essentially break an action down into more details without having to show everything in one diagram.

Figure 3-14: The Prepare Motherboard activity elaborates on the motherboard preparation process

The Prepare Motherboard activity diagram has its own initial and activity final nodes. The activity final node marks the end of Prepare Motherboard, but it doesn't mean the calling activity is complete. When Prepare Motherboard terminates, control is returned to the calling activity, which proceeds as normal. This is another reason call activities resemble invoked software procedures.

Although it's acceptable to omit the activity frame for top-level activities, you should always show it for invoked activities. The name of the activity in the activity frame will help you associate invoked activities with the invoker.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Sometimes data objects are an important aspect of the process you're modeling. Suppose your company decides to sell the CMS as a commercial product, and you want to define a process for approving incoming orders. Each step in the order approval process will need information about the order, such as the payment information and transaction cost. This can be modeled in your activity diagram with an Order object, which contains the order information needed by the steps. Activity diagrams offer a variety of ways to model objects in your processes.

Objects don't have to be software objects. For example, in a non-automated computer assembly activity, an object node may be used to represent a physical work order that starts the process.

In activity diagrams, you can use object nodes to show data flowing through an activity. An object node represents an object that is available at a particular point in the activity, and can be used to show that the object is used, created, or modified by any of its surrounding actions.

An object node is drawn with a rectangle, as shown in the order approval process in Figure 3-15. The Order object node draws attention to the fact that the Order object flows from the Receive Order Request action to the Approve Payment action.

Figure 3-15: The Order object node emphasizes that it is important data in this activity and shows which actions interact with it

See "Sending and Receiving Signals" for a more precise way of modeling the Receive Order Request action—as a receive signal node.

Figure 3-16 shows a different perspective on the previous activity using pins . Pins show that an object is input to or output from an action.

An input pin means that the specified object is input to an action. An output pin means that the specified object is output from an action. In Figure 3-16, an Order object is input to the Approve Payment

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Activities may involve interactions with external people, systems, or processes. For example, when authorizing a credit card payment, you need to verify the card by interacting with an approval service provided by the credit card company.

In activity diagrams, signals represent interactions with external participants. Signals are messages that can be sent or received, as in the following examples:

Your software sends a request to the credit card company to approve a credit card transaction, and your software receives a response from the credit card company (sent and received, from the perspective of your credit card approval activity).
The receipt of an order prompts an order handling process to begin (received, from the perspective of the order handling activity).
The click of a button causes code associated with the button to execute (received, from the perspective of the button event handling activity).
The system notifies a customer that his shipment has been delayed (sent, from the perspective of the order shipping activity).

A receive signal has the effect of waking up an action in your activity diagram. The recipient of the signal knows how to react to the signal and expects that a signal will arrive at some time but doesn't know exactly when. Send signals are signals sent to an external participant. When that external person or system receives the message, it probably does something in response, but that isn't modeled in your activity diagram.

Figure 3-20 refines the steps in Figure 3-19 to show that the credit card approval action requires interaction with external software. The send signal node shows that a signal is sent to an outside participant. In this example, the signal is a credit card approval request. Signals are sent asynchronously, meaning the activity does not wait for the response but moves immediately to the next action after the signal is sent.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The simplest and most common way to start an activity is with a single initial node; most of the diagrams you've seen so far in this chapter use this notation. There are other ways to represent the start of an activity that have special meanings:

The activity starts by receiving input data, shown previously in "Showing Input to and Output from an Activity."
The activity starts in response to a time event, shown previously in "Time Events."
The activity starts as a result of being woken up by a signal.

To specify that an activity starts as a result of being woken up by a signal, use a receive signal node instead of an initial node. Inside the receive signal, node you specify what type of event starts the activity. Figure 3-21 shows an activity starts upon receipt of an order.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The end nodes in this chapter haven't been very interesting so far; in fact, they haven't acted as much more than end markers. In the real world, you can encounter more complex endings to processes, including flows that can be interrupted and flows that end without terminating the overall activity.

Figure 3-21 above shows a typical activity diagram with a simple ending. Notice there's only one path leading into the activity final node; every action in this diagram gets a chance to finish.

Sometimes you need to model that a process can be terminated by an event. This could happen if you have a long running process that can be interrupted by the user. Or, in the CMS order handling activity, you may need to account for an order being canceled. You can show interruptions with interruption regions .

Draw an interruption region with a dashed, rounded rectangle surrounding the actions that can be interrupted along with the event that can cause the interruption. The interrupting event is followed by a line that looks like a lightning b

Table of Contents