Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Fitting the UML into Your Development Process

Paul Gustavson
SimVentions, Inc.
1025 Ficklen Road
Fredericksburg VA 22405
pgustavson@simventions.com

Description:

This session examines the Unified Modeling Language (UML), provides a primer on UML
diagramming, and explains how the UML can be used to benefit managers, developers and,
ultimately, end users.

Prerequisites:

Participants should have some familiarity with general software development processes.

Abstract:

Are you a manager of a software team that could benefit from more focus on requirements, design
and testing but face reluctance from your team to do so? Or, are you a software developer that is
increasingly expected to perform more mundane duties outside of code development? The Unified
Modeling Language (UML) provides a unique bridge for developers and managers, allowing effective
communication that feeds directly into successful software development. This session examines the
UML, provides a primer on UML diagramming, and explains how the UML benefits managers,
developers and, ultimately, end users. Special attention is focused on understanding UML
diagramming by a practical example, and knowing when and where to apply UML diagramming to
your development process. Specific UML diagrams discussed include the following:

Use Case diagrams (and templates),

Class diagrams,
Object diagrams,
Sequence diagrams,
State diagrams,
Collaboration diagrams,
Activity diagrams,
Component diagrams,
Package diagrams and
Deployment diagrams.

1. Introduction - Focus on Design

The key to successful software development is to start with a good design. Without one, a software
development project may be likely to struggle, cause frustration, or even fail. This can be true not
only for team development projects, but also for smaller one-man software jobs. A good design
captures the functional requirements of a program and describes, at a high level, the plan for
achieving those requirements.

Unfortunately, there is typically not enough time allotted in the development process that focuses
on software design. Our natural instinct is to think that the greatest amount of progress will occur
once the developer begins to pound out code from the keyboard. This attitude is further
encouraged with the availability of powerful and exciting RAD IDE tools like Delphi, C++Builder,

1 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

JBuilder, and even VisualBasic. Let's face it, developing code is a whole lot easier and more
enjoyable with these environments. It's easy to see why developers (want to) spend more of their
time coding rather than being away from those environments designing.

Of course, the reality is that experienced developers and managers ( and spouses) grow weary of the
endless coding cycle. In the heart of the battle, before the delivery is due, a developer may end
up staying up half the night or all night to revamp and complete a program because of a
misunderstanding of requirements, or a lack of understanding, or just poor communication among
team members who developed incompatible modules. We often recognize too late that if more
emphasis was spent up front on design, many of the later day coding, quality control and
communication issues would have not surfaced.

The question is, What will propel developers, managers, and even the sponsor's of a
project to focus on establishing a rock solid design?

Actually two answers exist to that question. First, a good policy and process for the software
development effort is necessary. The policy should be that requirements are captured, the project is
planned and tracked, and quality assurance (QA) and configuration management (CM) are in
place. [1] There are other elements that can be added as well, but these are the essentials. The
process to support this policy must focus on the design. Again, the design is the collection of
requirements and plan for achieving those requirements. Its a blueprint. Without a software
development process that centers on design, a project ends up being code spun on impulse. Mix
that with multiple developers creating different components and you typically get an incomplete or
poor product, much less frustration.

Second, mechanisms for capturing design are needed. This not only includes tools, but templates
and techniques for documenting and illustrating design. In fact, the tools are useless unless you
have a common mechanism for capturing the design in ways that can facilitate communication and
provide direction in the software development process. The mechanism described in this paper is the
Unified Modeling Language (UML).

2.0 The Unified Modeling Language (UML)

The UML is the collective brainchild of Grady Booch, Ivar Jacobson, and Jim
Rumbaugh; three world renown object-oriented technologists who
combined their efforts to create a standard method for capturing and
visualizing object-oriented designs. Over the past four years, UML has been
one of those buzzwords in the software community that has found itself on
the same hot list as Java, XML, and .NET. UML stands as a powerful and
capable method for designing software. Unfortunately, it is vastly
underutilized within the software development community.

The goal of this paper is to give you the essentials so that you will know how to read UML, use
UML, and create UML-based designs. More in-depth information than what can be provided in this
paper can be found in many of the books available on UML. However, what you should get from
this paper is a grasp of the visual world of UML and how it can be used in the design of your
projects. You should be able to walk up to a white board, for example, and draw a sequence
diagram with your co-developers looking on nodding their head in agreement. UML provides an
effective way to communicate.

2.1 The UML Diagrams

2 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

UML is made up of what first appears to be a hodge-podge of diagrams some of which are
reminiscent of flow charts. Most of these diagrams are used to represent multiple views of the
system under development. The UML diagrams described and recommended in this paper each have
a proper place for a typical software development project (some more than others), and they can be
complementary to one another.

The specific UML diagrams we will describe and use include the following:

Use Cases (and templates),

Class diagrams,
Object diagrams,
Sequence diagrams,
State diagrams,
Collaboration diagrams,
Activity diagrams,
Component diagrams,
Package diagrams, and
Deployment diagrams.

2.2 The UML Process

In truth, there is no UML process. UML is strictly intended to provide a unified mechanism for
capturing and reflecting the system design. How it is used and applied, however, is dependent upon
the software development process. In fact, UML diagrams cannot be used effectively without
application to a process. The UML can be used to support the activities associated to many
processes such as a Waterfall, or Spiral model. At a high level, each model used has some
commonality that can help us understand how to utilize UML. The typical pattern for development
based on these process models can be broken into five major elements:

1. Requirements - identify objectives,

2. Analysis - define the conceptual model
3. Design design the solution / software plan,
4. Development - develop and test the software,
5. Deployment verify and deploy the software.

The acronym for these elements creates an acrostic known as RADDD, or RAD3, a high-level process
model formally identified by Joseph Schmuller. [2] RAD3 is a model that can be tailored to meet your
specific development process for your organization and projects. It is a flexible model that supports
iterative and incremental development efforts (i.e., spiral development), as well as sequential
development efforts (i.e., waterfall development), and development efforts that fall somewhere in
between.

RAD3 should not be confused with the concept of Rapid Application Development (RAD) that is
promoted by tools such as JBuilder, C++Builder and Delphi, although they complement each other.
It also should not be confused with the protein Rad3, which is one of six proteins that is required
for the synthesis of a human DNA module.

Table 2.2 provides a useful guide for knowing when to apply the various UML diagrams during the
development effort. For clarity, I will associate the UML components to the RAD3 elements during
the course of this paper.

3 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Table 2.2 - UML Work Products and Process Segements

The blue boxes identify the UML work products that are developed, the green boxes identify
completed UML work products that are used to support the activities associated to the various RAD3
process segments, and the green-to-blue boxes identify UML work products that are used and
refined.

3. UML by Example

Experience shows thats that the fastest way to grasp UML and understand how it can be applied is
through examples. In this paper, we will take each key UML technique and qualify it through the
design and development of a next-generation Juke Box for restaurants and other businesses. Our
goal is to design a Juke Box that allows customers to select songs they want played or to submit a
play list that they have already created previously. If a request is made for song that is not
contained by a local Juke Box, it will query for that song from other Jukeboxes elsewhere in the
country thus they are networked. Although reminiscent of Napster, like the original jukebox, we
want to provide a mechanism for owners, record companies and artists to earn a profit. Therefore,
for this Juke Box we want to provide not only a coin drop and cash feed mechanism, but also a
card swipe mechanism and a cell dial payment capability.

By working this simple example, we will touch on when and how UML can be applied to the
common development process. We will walk through each UML component, first describing its
intent, and then show how its used based on our Juke Box example.

3.1 Use Cases

One of the hallmarks of the UML is the concept of Use Cases. Use Cases help minimize the risk
associated with poor requirements analysis. Use Cases are used to identify a goal or case of use for
a software program or system. It includes the identification of actors, which are external entities

4 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

that have behavior that interact with the software program system, and a scenario, which details
the sequence of steps and events that will be executed to accomplish the stated goal.

Use cases provide an extremely effective mechanism for capturing the functional requirements of a
project, and they can be used to direct the development of a project. The collection of Use Cases
serves as the initial Blueprint that feeds into the design, coding, testing, and validation activities of
the software project. If documented and used properly, Use Cases will minimize the risks associated
with analysis, design, development, and deployment.

3.1.1 Use Case Diagrams

The UML Use Case diagram provides a useful illustration of the relationship between the system and
it components under design including the "Actors" which act upon it (see Figure 3.1.1).

Figure 3.1.1 - Use Case Diagram for Creating a Play List for our Juke Box

These "Actors" for this example includes a song list database, the play list, and the customer who
creates the play list. In some of the other Use Cases for our Juke Box, we also have actors that
include a Cell Phone System, and Credit Card Processing Center. As evidenced in this example,
actors can be composed of users, external processes, or remote systems.

From a visual standpoint, the UML diagram is useful in providing a common picture for managers,
developers, and users (i.e. project sponsors) allowing collaboration and common understanding to
occur. Within our scenario steps, we can also identify exceptions and variations that might occur.
For example in the example depicted in Figure 3.1, our play list is created and displayed (Step 3),
but there is latitude in allowing our Customer to reorder or delete songs from the play list. These are
variations, but our goal is still accomplished despite these activities. Notice that we can associate
other uses cases to our main steps, and variations (and exceptions). An exception, as identified in

5 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Step 1 of Figure 3.1.1, would be if the Customer waited to long to respond (a timeout occurred) or
canceled out of the play list creation process. These are called exceptions because they terminate
the anticipated processing to accomplish the requirement.

3.1.2 Use Case Templates

One deficiency of the UML, however, is in fully carrying the capability of capturing requirements.
Experience has shown that UML Use Case diagrams are simply not enough for capturing functional
requirements. Other forms of input are needed to capture these functional requirements in a textual
way. Fortunately, one method that seems to work well and complements the UML are the Use Case
Templates introduced by Alistair Cockburn. [3] These templates allow team members to identify
functional requirements including the scope, actors, pre and post conditions, and the scenario steps
associated to accomplishing the requirement objective (see Figure 3.1.2-1).

Figure 3.1.2-1 - Use Case Template for Creating a Play List for our Juke Box

We can further expand on the Scenario Steps of the Use Case by identifying any potential
Exceptions and Variations (see Figure 3.1.2-2).

6 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Figure 3.1.2-2 - Use Case Template Exceptions and Variations for

Creating a Play List for our Juke Box

I discussed the Use Case Diagram first in the section because its a key UML artifact, but the truth is
that, in this example, I first created my Use Case by filling in the templates and, from there, I was
able to easily generate my Use Case diagrams.

A whole paper could be dedicated to Use Case Templates, but a detailed discussion on Templates is
not in the scope of this paper. The key point to consider is using Use Case Templates to nail down
your requirements and to produce UML Use Case diagrams. The templates and supporting UML
diagrams provide the basis for your software requirements specification.

3.1.3 The Conceptual Model

Use cases are not only used to capture requirements, but, once flushed out and elaborated, provide
the basis for the conceptual model. The conceptual model is the byproduct of analysis. There are
multiple levels of Use Cases that can be identified within a Use Case Template. The first level is
known as the Summary level. This is where you capture the sponsor objective and the overall
general requirements. They are very high level, but once that effort is complete, we can dive in
deeper and identify the primary task and sub-task level Use Cases. This is the meat of what the
system is going to need to do to accomplish those summary Use Cases. Also, as shown, in the
Figures 3.1.2-1 and 3.1.2-2, we can identify the scenario steps including variations and exceptions.
Furthermore, once you begin to lay out all the Use Cases at the various different levels, it begins to
shape into a hierarchical model of the anticipated system (see Figure 3.1.3).

Figure 3.1.3 - Use Case Hierarchy - Juke Box Conceptual Model

This level of information is what forms the conceptual model or our Juke Box system during the
Analysis effort. We can also begin to create class diagrams during the analysis effort.

3.2 The Class Diagram

7 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Another technique that is applied to support the conceptual analysis effort is the use of Class
diagrams. In fact, the UML Class Diagram is used to support both the analysis and the design phase.
If you are a developer, you probably are no stranger to the concept of classes. Classes are an
important aspect of object-oriented software. When we recognize a pattern in which there a
common group of things that have similar attributes and behaviors, we typically represent that as a
class.

3.2.1 Conceptual Level Classes

When developing class diagrams, it is wise to start at the conceptual level. Start by laying out the
fundamental elements you and your team think well be needed to support the objectives as
identified in the Use Case diagrams. Do not be concerned with the interface and implementation
level of detail. Implementation issues are dealt with during the design phase as you refine your class
diagrams during your development process. Developing at the conceptual level means to keep a
perspective that is language and platform neutral, and focus on the essential pieces needed to make
your software system work. Your mindset should be to look at it a from a users perspective (much
like what was done when starting out with developing Use Cases).

In UML, we can graphically represent these conceptual level classes as shown in Figure 3.2.1.

Figure 3.2.1 Conceptual Level Classes for our Juke Box Enterprise

Since this is the conceptual level, the classes are kept abstract. The goal is to identify the types of
objects we anticipate for our Juke Box system. These class diagrams sketch out the concepts
identified within the Use Cases: play lists, song database, payment processing, etc... For some of
these classes, we have also identified a few attributes we anticipate, and the potential operations
for Payment Processing .

3.2.2. Specification Level Classes

Once the conceptual level class diagrams have been identified, you can begin to elaborate further
on these class diagrams by determining what is needed for your software to interface with these
class components. This is where you begin to design your classes at the specification level (see
Figure 3.2.2).

8 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Figure 3.2.2-1 Specification Level Classes for our Juke Box

As shown in our Juke Box example, a single UML class for the specification level can be broken into
three areas. The top field, usually in bold text, identifies the class name, the middle area lists the
attributes of the class, and the bottom area identifies the behaviors (or operations) of the class. It is
at the specification level, that attributes and behaviors should now be identified. Notice, we also
expand on the classes we identified for our conceptual level view (Figure 3.2.1). Each class now has
a set of attributes and operations; we also have additional classes to support the Payment
Processing class.

At this level of detail, the users hat has now be swapped for a developers hat, but its good
practice to continue to keep these classes language and platform neutral. In fact, once you reach an
interface level class diagram, there really is no compelling reason to dive in deeper and lay them
out at the implementation level. The implementation level will take into consideration the
structure associated to the software language that will be applied, and the capabilities of the
platform to be used. As a general rule, the specification level is typically enough for a programmer
to produce the code that embodies those classes.

Figure 3.2.2-2 Class Diagram Development Flow

Some consider implementation level classes as an attempt at micro managing the development
process with the UML. Of course, if you do layout your classes at the implementation level,

9 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

perhaps you might not need the developers input to implement them. With the right tools, you
should be able to just push a button in your UML tool, and wa la! The code is complete! Does that
sound feasible? The truth is, there is more to it than that, even though there are tools that provide
this capability. Human intervention is always needed, and, therefore, for most developers, our jobs
are safe.

The specification level classes, such as the ones we have created for our Juke Box example (see
figure 3.2.2), give programmers (and managers) more confidence in the way things will be
implemented, and gives the developers the freedom to improvise as needed. This is analogous with
a quarterback who is given a play from the sideline, but has the liberty to change the call if hes
faced with a defensive look that is unexpected. In software development, the unexpected is always
bound to happen. A good design should always be flexible to be able to overcome the unexpected.

3.2.3 Class Associations

When you lay out your classes (even at the conceptual level), its important to keep in mind the
association a class has on another. An Association is used to depict the relationship between
instances of classes, and at the specification level, the responsibilities between instances of
classes. Figure 3.2.3.a and 3.2.3.b both show a collection of Classes for our Juke Box example and
the Associations between those classes depicted by a solid line connecting them together.

Figure 3.2.3.a Juke Box Specification Level Classes and Associations for Building a Playlist

10 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Figure 3.2.3.b Juke Box Specification Level Classes and Associations for Payment

You may wonder why two separate class diagrams w/ associations were created. It was done for
simplicity and clarity. The associations for these classes could have been done with one, but I find
splitting up associates based on "states" helps my team focus on the roles of theses classes much
more easily.

One thing you may notice is symbology and labels associated to the Associations depicted in both
figures. The asterisk * on one end of an association in the first figure is used to identify
multiplicity. We what we are saying here is that there can be multiple songs associated to one
song list databases and multiple songs associated to one play list. We can also identify role names
for associations. This is not mandatory, but it helps define what the role of the association is
between classes. If there is no name, the class name in itself usually suffices as to defining the role
of the association. In the second figure, two associations have an open arrow on one end. These
arrows are used to indicate navigability. What is being said here is that the item being pointed
from has a responsibility to support the item being pointed to. This is called unidirectional
association. Associations without arrows indicate either bidirectional association, or that the
navigability is unknown.

3.2.4 UML Syntax for Classes

In addition to attributes, it is important to understand the syntax regarding the aspect of attributes
and operations. Attributes are used to identify the elements of a class. The operations within a
class identify the methods of a class that can be invoked.

At the specification and implementation level, the UML Syntax for fully identifying attributes within a
class diagram appears in the following format:
visibility name: type = defaultValue;

The visibility identifies if the attribute is public , protected or private. The symbols used for the
visibility tag is identified in Table 3.2.4. Borland developers should use the public symbol for
identifying published attributes (members).

11 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Table 3.2.4 Visibility Symbols for Attributes and Operations

Symbol Visibility

+ public
# protected
- private

At the Specification Level, its not uncommon to leave off the visibility, type and default values if
the attribute name itself provides enough description to discern the intent.

The same principles for attributes apply for operations. The UML Syntax for identifying operations
within a class diagram typically appears in the following format:

visibility name(parameters) : return_type-expression

As you evolve your class diagrams from the conceptual level to a specification and implementation
level, its good practice to adhere to the attribute and operation syntax within the class blocks. The
key benefit to classes and associations and applying this syntax, is that developers can use these to
help guide them during the coding process.

3.3 The Object Diagram

An instance of a class is known as an Object. The attributes identified by the class now have values
associated with it. There might also be behavior associated with the methods (or operations)
identified by the class.

The UML provides a diagram to identify the types objects that might instantiated during the
execution of the program. Figure 3.3 provides an example of a song object that we might see in our
Juke Box environment.

Figure 3. 3 Juke Box Song Object

As shown, the object diagram (right) is very similar to the class diagram (left). Close examination
shows that the object diagram identifies the instance name followed by the class name. A colon
separates the instance name and class name, and the complete text is underlined. The attributes of
the class are filled out with information associated to the object.

Again, object classes can be a very simple yet effective technique in identifying the types of entities
that a programmer will want to have instantiate in code at runtime. Object diagrams are typically

12 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

used to support the activities associated with the design effort.

3.4 State Diagrams

So far we've mentioned classes, and we've mentioned objects. It's worth mentioning one of the next
logical progressions of an object, and that is the concept of states. An object may have one or more
states of behavior. UML provides a mechanism to diagram behavior as shown in Figure 3.4.

Figure 3.4-1 State Diagram for Creating a Juke Box Play List

You'll notice in the diagram the use of large dots, rounded rectangles, and arrows. The top solid dot
indicates the start state of our object, whereas the bottom bulls-eye dot indicates the endpoint or
conclusion for this objects state machine. The rounded rectangles represent an objects state. These
state blocks may also include activities (placed on the bottom) that can occur for a given state,
and, although its not shown in this illustration, state variables associated to the state can also be
depicted (usually sandwiched between the state title and activities segment.

In our example, we have several activities associated to our first state. Each activity dictate the next
state transition action as illustrated in our State diagram example. These transitions are represented
by the lines with arrows between object states. Transitions are often identified with action labels
identifying what event triggered (initiated) the transition. Transitions can also be identified with
guard conditions that indicate what needs to be true for a transition to reach the next state.

Our Juke Box State Diagram example identifies the actions and activities that we should expect for
building a play list. This is very important for the developer in understanding the association and
hierarchy of objects. We begin using state diagrams during the Analysis phase of software
development. I should also note that this particular state diagram example illustrated in Figure 3.4
was fully derived from our use case blueprint that we developed earlier. This provides one example
where our Use Cases become extremely effective in supporting other stages of our development
process.

13 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Figure 3.4-2 Use Case Scenario for Creating a Juke Box Play List

Theres a lot of things that can be done with State Diagrams including identifying sequential and
concurrent states as well as substates. Unfortunately, a more in depth analysis and illustrations of
state diagrams is beyond the scope of this paper. The important thing to grasp is that state diagrams
are an extremely useful mechanism for supporting the analysis and design effort. As weve seen,
Class and Object diagrams provide only a static view of the system under development, whereas a
State diagram is used to provide a dynamic view of the system for a given object it illustrates the
expected behavior.

3.5 Interaction Diagrams

One of the other things that will happen with our objects is that they may interact with one another.
This interaction can be illustrated in UML using either the Sequence Diagram (see Figure 3.5.1) or
the Collaboration Diagram (see Figure 3.5.2). Both these diagrams are used to illustrate the
collaboration and behavior expected between a group of objects.

3.5.1 The Sequence Diagram

A Sequence Diagram is a powerful visual aid for developers in understanding the interaction of
objects within a system. Use cases can be applied in concert with class and object diagrams to
create the sequence diagrams (see Figure 3.5.1).

14 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Figure 3.5.1 Sequence Diagram for Creating a Play List

The Sequence Diagram identifies the various objects at play with one another. The lines and bars
below each object represent the time and duration associated to the interaction events. The vertical
dashed line is called the lifeline. The horizontal arrows between lifelines are used to identify
messages (solid lines) and returns (long dashed lines). A message is an interaction that occurs
between objects or itself (called a self-call). Synchronous processing of a message will typically
result in a return. Like state diagrams, conditions for when a message is to be sent can be
identified by using the brackets. Messages that may be sent multiple times and to multiple recipients
are identified by an iteration marker *.

Sequence diagrams can be fairly easy to fill out during the design phase if youve properly laid out
your use cases. Like with our state diagram example in figure 3.4-1, the sequence diagram
illustrated in figure 3.5.1 is based on our Create Play List Use Case. The difference in this diagram is
that we have identified the actors as objects and identified the interaction between those objects. In
our state diagram, however, we were only concerned with the activities and actions of one object.
The payback in creating sequence diagrams is that they provide a very effective mechanism for
supporting the coding and testing activities of your software development process.

3.5.2 The Collaboration Diagram

The Collaboration Diagram provides another method for documenting the interaction of objects. For
this diagram, the objects are identified in rectangular icons with numbered messages that connect to
other objects (see Figure 3.5.2). The numbering is used to identify the sequence of events for the
complete interaction.

15 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Figure 3.5.2 Collaboration Diagram for the Add Song To Play List Scenario

Collaboration Diagrams are not as intuitive as a Sequence Diagram for the reader, but it can provide
a bit more flexibility in expanding and understanding the activities associated to object interaction.

3.6 Activity Diagrams

Of all the UML diagrams, Activity Diagrams resemble the notion of flow-charts the most. The
sequence of activities that are necessary to accomplish a functional goal from start to finish are
graphically represented using activity diagrams (see Figure 3.6). One of things we leverage are Use
Cases. In fact, the scenario within a Use Cases (during the analysis phase), can be directly mapped
into an activity diagram. Some analysts prefer to create an activity diagram to document the
anticipated business process prior to completing Use Cases. Either way, Activity Diagrams are often
used in support of identifying objectives.

16 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Figure 3.6 - Juke Box - Customer Activity Diagram

The end result is an activity diagram that is simple in nature to follow that models the typical User
Operation. In the example we are using an activity diagram element known as a branch to identify
decision actions, and join elements to identify multiple activities that rejoin. The diagram also
identifies guard conditions for transitions to occur between activities. There are other activity
diagram elements not used in this particular example such as a forks, and merges.

3.6.2 Swim Lanes

Swim lanes are used to map the areas of responsibility with an Activity Diagram. (see Figure 3.6.2).

Figure 3.6.2 - Juke Box - Customer Activity Diagram with Swim Lanes

This is actually the same diagram as Figure 3.6, but organized into Swim Lanes to show the various
elements of activity (responsibility) between the customer and the Juke Box.

3.7 Component Diagrams

A Component Diagram is used to depict the physical architecture of the system in terms of its
components. By definition, a component is an encapsulated unit (a virtual black box) with a
known set of inputs and expected output behavior, but the behavior details maybe hidden or
unknown. A component is typically the software implementation of a class or a set of classes.
Components facilitate reuse.

Figure 3.7.1 provides a simple illustration of a Component Diagram for our Juke Box System.

17 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Figure 3. 7 .1 Component Diagram of Juke Box Payment Mechanism

Our example shows a single component within our Juke Box system for providing Payment Support.
This component associates three related classes for supporting Cell Phone, Cash, and Credit Card
payments. These classes are necessary for the component to support the payment elements. It is
also useful to identify the interface necessary to utilize the component, which is a made payment.

Dependencies can also be reflected in a component diagram as illustrated in Figure 3.7.2.

Figure 3. 7 .2 Juke Box Component Playback / Payment Dependency

In this example, our Playback Mechanism component requires payment to be made as an interface
so that it can perform its task. This PaymentMade interface is dependent upon the Payment Support
component. A dashed line from one component to another is used to identify a dependency.

An other dependency our Playback Mechanism requires is the play list, which is provided by another
component called Playlist Support as illustrated in figure 3.7.3.

Figure 3. 7 .3 Juke Box Component Playback / Playlist Dependency

Playlist support is used to create and retrieve playlists. The Juke Box Playback Mechanism is
dependent upon the Playlist Support component just as it is a payment.

In the end, we have three components, which, upon examination, happen to map directly to our
high-level use cases. Once developed, these components, can be reused for other projects. The

18 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

Payment Support component, for example, might be useful for other automated e-commerce
exchanges.

To summarize, Component Diagrams allow you to model the relationship of your components. Its
typically used during the design phase to identify the components or modules that need to be
developed, and any dependencies for these components. It can be used to facilitate the
development of VCL controls and CLX components for Delphi, C++Builder and Kylix developers
encouraging them to develop reusable components. Thus, Component Diagrams can be a valuable
tool for programmers and can be used to help assign responsibilities to team members.

3.8 Packages

At this point we have already nailed down our conceptual model of our Juke Box enterprise into
three components. But, now we want to look at the high level dependencies that exist between
the various Juke Box operational elements. These elements are called packages. A package is used
to describe the dependency of class groups that will model a system. A class group or package is an
interrelated set of classes.

Again, we look at our Use Case Blueprint (specifically the actors internal to our enterprise system) to
draw out the packages and dependencies as illustrated in Figure 3.8.

Figure 3.8 Juke Box Package Diagram

In this example we have a user interface that is dependent upon access to a song listing database,
and the development of a playlist. The payment package is dependent upon the user interface to
retrieve payment information (cell phone, credit card #). Our playlist is dependent upon the song
listing to verify that desired song (from the user interface) is available. Finally, the playback
package, which is used to play the playlist, is dependent upon payment and a valid playlist.

All these dependencies are important to understand early in the development process. In fact,
Package Diagrams can also be used as early as the requirements gathering process to identify the
anticipated system-functionality. It can also be used to provide a useful framework and checklist for
overall system testing.

As shown in this illustration, each package within a Package Diagram can be used to represent a

19 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

collection of interrelated Use Cases/Actors that formulate our class types. If you are a VCL or CLX
component writer you may wonder if this UML concept of a package can be used to represent a
collection of interrelated components. The answer is yes, it could, although the concept of
packages is a little bit different than the idea of a package for VCL and CLX components. A UML
package is much more abstract, but yet its useful in grouping classes or components.

3.9 The Deployment Diagram

Weve talked about the relationship of actors to requirements and how thats modeled with Use
Cases, and the relationship of classes upon another with Class Diagram Associations and Package
dependencies, but there is another aspect of relationships that hasnt been discussed, and thats the
relationship of the hardware, software and networks components for the system being developed.
Figure 3.9 illustrates the deployment diagram for our Juke Box example.

Figure 3. 9 Juke Box Deployment Diagram

The 3D drawn boxes contain objects (or components) that comprise a physical element of the
system. These boxes are called nodes, and each of these nodes are connected to show the system
architecture. In our example, our Juke box enterprise can consist of the following:

Client PC is a processor node which allow users to create personal play lists. The component
used (executed) for this node is the Playlist support component.
A Web Repository provides an interface device node for storing play lists. Unlike a processor
node, it nots really capable of executing a component.
The JukeBox System, which would be located in stores and restaurants, is a processor node
used to retrieve, bill and play playlists. The components used for this node include the
playback mechanism, playlist support (note: were reusing the same one used by the client
PC!), and the payment support.

Deployment Diagrams can be used as early as the requirements gathering process to identify the
systems (and components) to be procured and used.

4.0 Overcoming The Mental Hurdles

4.1 Hurdle #1 - Time To Learn

20 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

There may be several reasons why something as promising and powerful as UML, might be ignored
or rejected. One mental hurdle for developers and managers is the belief that UML simply takes too
much time to learn and use, and will add an extra burden on the development effort. The natural
instinct for developers is that they would rather code than draw UML diagrams. Perhaps this maybe
especially true for the programmer who prefers to code with a bottle of Mountain Dew and a bag of
Cheetoes within arms reach and just loves to bang out code. Managers may fear the expense of
training, and the cost of tools needed to support the job. The first question to be answered however
is, Does UML take time away from one of the highlights of a software project: the software coding
phase?

The answer is both yes and no. The proper use of UML will require more time during the design
stage, but it is at the benefit of the coding phase. How? UML helps minimize the issues that typically
crop up during development. As a result, there are less defects, better communication and better
direction.

Note: For what it's worth, there are only two highlights of a software project that achieve greater
satisfaction than the software coding phase: the day the project is awarded or funded, and, even
greater, the day it is completed, delivered or sold. Its ironic that the two phases of a software
project that contribute the most to a successful development project is the design phase and the
test phase, and yet they come in dead last in terms of emphasis for the majority of projects.

4.2 Hurdle #2 - Tool Cost

The other big concern other than time is cost! While UML tools and training can be expensive, they
dont have to be. Many mistakenly believe that another set of expensive tools are required to
generate, use and share UML diagrams. Yes, there are UML tools out there, and many of them are
very good and some are very expensive so expensive that they can cost as much as a down
payment on an automobile. If the resources are there, go for it! But the reality is that UML can be
easily used and applied without the expensive tools.

You can use PowerPoint, Visio (which has a UML pack), or even a white board -- just use a
digital camera to capture your drawings. The issue isn't what tool will you have to buy, it's about
giving UML a chance by learning it and using it.

4.3 Hurdle #3 - Beyond The Comfort Level

If you're someone who's having a hard time swallowing the thought of embracing and using UML,
you need not go far back in the history of software development to find encouragement. It was not
that many years ago when the software development community faced the dilemma of transitioning
from structured programming to object-oriented programming. Programming the OO way required a
completely new mindset in how we coded. Truth be told, many of us didn't become OO
programmer's overnight -- although we may have thought we could be. Some of us are still finding
more powerful ways to apply OO principles. I know I am. OO development has caused a
revolutionary change in the computer science field which took some time, but there are have been
very few of us who regret making the transition. If we hadn't, we would all be developing top-down
structured programs, and not have the tools and technologies like Java, Delphi, C++Builder, Kylix
and the magic behind them, JavaBeans, VCLs and CLX components!

Perhaps there are a few of you out there who passed up on the transition from structured
programming to OO programming, but are still out there as managers. Well, if you're one, this might
be your time to transition. UML is not just for developers -- it's also for managers. If you're
interested in solid design, productivity, and cohesion among all your developers -- that your team
will all understand what the software program is to do, and that the customer understands and is

21 of 22 10/03/2012 03:09 PM
Fitting the UML into Your Development Process http://www.simventions.com/whitepapers/um...

committed as well, then you should really embrace the UML.

5.0 Conclusion

Like the real world, goals can best be met if they are backed with a plan. A goal identifies what
needs to be done, whereas a plan identifies how it will be done. Once you lay out a plan, it is then
important to follow it. All software development projects typically start off with a set of goals (even
if they are unwritten), but a design is necessary to provide a plan. The Unified Modeling Language
(UML) provides a unique bridge for developers and managers, allowing effective communication
that feeds directly into a successful software development plan.

Within this paper, we've gone through an accelerated, Cliff-Notes rendition of UML tied to an
example of a next generation Juke Box enterprise. UML was used to define a blueprint for our Juke
Box system. We havent coded it, but weve designed it. Developers and testers (and users) involved
in the process now know whats expected. Specifically the developers have a good idea on how to
implement it, and the testers and QA team now know how to verify and validate the end product.
Through the UML, we produced a clear plan of what is required and how to accomplish it.

We have also talked about the mental hurdles often associated with integrating UML in the work
place. Nothing is insurmountable. The application of the UML can serve to better your organization,
your projects, the processes that you apply, and the individuals within your team. Learning and
applying UML is time well spent and an investment that should prove to be huge pay off

6.0 Recommended Reading

There are numerous books on the subject of UML. In fact, a recent search at Amazon.com on UML
produced a listing of 99 UML-based books that are currently available (and this number is growing).
There are several, however, that I found to be extremely useful, which I recommend for your library.

Martin Fowler, Kendall Scott, UML Distilled: Applying the Standard Object Modeling Language
(2 nd Edition), Addison-Wesley, 2000.
Joseph Schuller, SAMS Teach Yourself UML in 24 Hours (2 nd Edition), Sams, 2002.
Grady Booch, Ivar Jacobson, James Rumbaugh, The Unified Modeling Language User Guide,
Addison-Wesley, 1999.
Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley, 2000.

Biography

Paul Gustavson is an experienced C++Builder and Delphi developer. He got his first serious start in
programming with Turbo Pascal in 1983 and has been programming ever since. Paul is a co-founder
of SimVentions, a company focused on interactive solutions and software. He has written and
presented numerous publications on simulation interoperability, is a contributing author of the
"C++Builder 5 Developer's Guide", and the technical editor for "SAMS Teach Yourself UML (2nd
Edition)." Paul lives in Virginia with his wife and two boys.

[1]
The Capability Maturity Model Guidelines for Improving the Software Process,
Carnegie Mellon University, Software Engineering Institute, Addison-Wesley, 1994.
[2]
Joseph Schmuller, SAMS Teach Yourself UML (Second Edition), SAMS, 2002.
[3]
Alistair Cockburn, Writing Eective Use Cases, Addison-Wesley, 2000.

22 of 22 10/03/2012 03:09 PM