UML

The Unified Modeling Language (UML) is a standard language for specifying,

visualizing, constructing, and documenting the artifacts of software systems,
as well as for business modeling and other non-software systems. The UML
represents a collection of best engineering practices that have proven
successful in the modeling of large and complex systems. The UML is a very
important part of developing object oriented software and the software
development process. The UML uses mostly graphical notations to express
the design of software projects. Using the UML helps project teams
communicate, explore potential designs, and validate the architectural
design of the software.

Unified Modeling Language (UML) is a standardized general-purpose modeling

language in the field of software engineering. The standard is managed, and was
created by, the Object Management Group.
UML includes a set of graphic notation techniques to create visual models of software-
intensive systems.

Goals of UML
The primary goals in the design of the UML were:

1. Provide users with a ready-to-use, expressive visual

modeling language so they can develop and exchange
meaningful models.
2. Provide extensibility and specialization mechanisms to
extend the core concepts.
3. Be independent of particular programming languages and
development processes.
4. Provide a formal basis for understanding the modeling
language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts such as
collaborations, frameworks, patterns and components.
7. Integrate best practices.
Use of UML
As the strategic value of software increases for many companies, the
industry looks for techniques to automate the production of software and to
improve quality and reduce cost and time-to-market. These techniques
include component technology, visual programming, patterns and
frameworks. Businesses also seek techniques to manage the complexity of
systems as they increase in scope and scale. In particular, they recognize the
need to solve recurring architectural problems, such as physical distribution,
concurrency, replication, security, load balancing and fault tolerance.
Additionally, the development for the World Wide Web, while making some
things simpler, has exacerbated these architectural problems. The Unified
Modeling Language (UML) was designed to respond to these needs.

UML Use Case Diagram

Use case diagrams model the functionality of a system using actors and use
cases. Use cases are services or functions provided by the system to its
users.
Basic Use Case Diagram Symbols and Notations

System
Draw your system's boundaries using a rectangle that contains use cases.
Place actors outside the system's boundaries.

Use Case
Draw use cases using ovals. Label with ovals with verbs that represent the
system's functions.

Actors
Actors are the users of a system. When one system is the actor of another
system, label the actor system with the actor stereotype.
Relationships
Illustrate relationships between an actor and a use case with a simple line.
For relationships among use cases, use arrows labeled either "uses" or
"extends." A "uses" relationship indicates that one use case is needed by
another in order to perform a task. An "extends" relationship indicates
alternative options under a certain use case.

A use case diagram is “a diagram that shows the relationships among

actors and use cases within a system.” Use case diagrams are often used
to:

• Provide an overview of all or part of the usage requirements for a

system or organization in the form of an essential model or a
business model
• Communicate the scope of a development project

• Model your analysis of your usage requirements in the form of

a system use casemodel
A use case model is comprised of one or more use case diagrams and any
supporting documentation such as use case specifications and actor
definitions. Within most use case models the use case specifications tend to
be the primary artifact with use case diagrams filling a supporting role as the
“glue” that keeps your requirements model together. Use case models
should be developed from the point of view of your project stakeholders and
not from the (often technical) point of view of developers. There are
guidelines for:

1. Use Cases
2. Actors
3. Relationships
4. System Boundary Boxes

1. Use Cases

A use case describes a sequence of actions that provide a measurable value

to an actor. A use case is drawn as a horizontal ellipse on a UML use case
diagram, as you see in Figure 1.

1. Use Case Names Begin With a Strong Verb

2. Name Use Cases Using Domain Terminology
3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram
4. Imply Timing Considerations By Stacking Use Cases. As you see
in Figure 1, the use cases that typically occur first are shown above
those that appear later.

Figure 1. Implying timing considerations between use cases.

2. Actors

An actor is a person, organization, or external system that plays a role in one

or more interactions with your system (actors are typically drawn as stick
figures on UML Use Case diagrams).

Figure 2. Online Shopping.

1. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram

 2. Draw Actors To The Outside Of A Use Case Diagram
3. Name Actors With Singular, Business-Relevant Nouns
4. Associate Each Actor With One Or More Use Cases
5. Actors Model Roles, Not Positions
6. Use <<system>> to Indicate System Actors
7. Actors Don’t Interact With One Another
8. Introduce an Actor Called “Time” to Initiate Scheduled Events

3. Relationships

There are several types of relationships that may appear on a use case
diagram:

• An association between an actor and a use case

• An association between two use cases
• A generalization between two actors
• A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with an

optional open-headed arrowhead on one end of the line indicating the
direction of the initial invocation of the relationship. Generalizations are
depicted as a close-headed arrow with the arrow pointing towards the more
general modeling element.

Figure 3. Enrolling students in a university.

 1. Indicate An Association Between An Actor And A Use Case If The Actor
Appears Within The Use Case Logic
2. Avoid Arrowheads On Actor-Use Case Relationships
3. Apply <<include>> When You Know Exactly When To Invoke The Use
Case
4. Apply <<extend>> When A Use Case May Be Invoked Across Several
Use Case Steps
5. Introduce <<extend>> associations sparingly
6. Generalize Use Cases When a Single Condition Results In Significantly
New Business Logic
7. Do Not Apply <<uses>>, <<includes>>, or <<extends>>
8. Avoid More Than Two Levels Of Use Case Associations
9. Place An Included Use Case To The Right Of The Invoking Use Case
10. Place An Extending Use Case Below The Parent Use Case
11. Apply the “Is Like” Rule to Use Case Generalization
12. Place an Inheriting Use Case Below The Base Use Case
13. Apply the “Is Like” Rule to Actor Inheritance
14. Place an Inheriting Actor Below the Parent Actor

4. System Boundary Boxes

The rectangle around the use cases is called the system boundary box and
as the name suggests it indicates the scope of your system – the use cases
inside the rectangle represent the functionality that you intend to
implement.

1. Indicate Release Scope with a System Boundary Box. In Figure 2 you

see that three system boundary boxes are included, each of which has
a label indicating which release the various use cases have been
assigned to.
2. Avoid Meaningless System Boundary Boxes
 UML Activity Diagram
An activity diagram illustrates the dynamic nature of a system by modeling
the flow of control from activity to activity. An activity represents an
operation on some class in the system that results in a change in the state of
the system. Typically, activity diagrams are used to model workflow or
business processes and internal operation. Because an activity diagram is a
special kind of statechart diagram, it uses some of the same modeling
conventions.

Basic Activity Diagram Symbols and Notations

Action States
Action states represent the non interruptible actions of objects. You can draw
an action state in SmartDraw using a rectangle with rounded corners.
Action Flow
Action flow arrows illustrate the relationships among action states.

Object Flow
Object flow refers to the creation and modification of objects by activities. An
object flow arrow from an action to an object means that the action creates
or influences the object. An object flow arrow from an object to an action
indicates that the action state uses the
Object.

Initial State
A filled circle followed by an arrow represents the initial action state.

Final State
An arrow pointing to a filled circle nested inside another circle represents the
final action state.

Branching
A diamond represents a decision with alternate paths. The outgoing
alternates should be labeled with a condition or guard expression. You can
also label one of the paths "else."

Synchronization
A synchronization bar helps illustrate parallel transitions. Synchronization is
also called forking and joining.
Swimlanes

Swimlanes group related activities into one column.

In many ways UML Activity diagrams are the object-oriented equivalent

of flow chartsand data-flow diagrams (DFDs). They are used to explore
the logic of:

• A complex operation
• A complex business rule
• A single use case
• Several use cases
• A business process

• Software processes

Guidelines:

1. General Guidelines
2. Activities
3. Decision Points
4. Guards
5. Parallel Activities
6. Swimlanes
7. Action Objects

1. General Guidelines

Figure 1. Modeling a business process with a UML Activity Diagram.

 1. Place The Start Point In The Top-Left Corner. A start point is modeled
with a filled in circle, using the same notation that UML State Chart
diagrams use. Every UML Activity Diagram should have a starting
point, and placing it in the top-left corner reflects the way that people
in Western cultures begin reading. Figure 1 , which models the
business process of enrolling in a university, takes this approach.
2. Always Include an Ending Point. An ending point is modeled with a
filled in circle with a border around it, using the same notation that
UML State Chart diagrams use. Figure 2 is interesting because it does
not include an end point because it describes a continuous process –
sometimes the guidelines don’t apply.
3. Flowcharting Operations Implies the Need to Simplify. A good rule of
thumb is that if an operation is so complex you need to develop a UML
Activity diagram to understand it that you should consider refactoring
it.

2.Activities

An activity, also known as an activity state, on a UML Activity diagram

typically represents the invocation of an operation, a step in a business
process, or an entire business process.
 1. Question “Black Hole” Activities. A black hole activity is one that has
transitions into it but none out, typically indicating that you have either
missed one or more transitions.
2. Question “Miracle” Activities. A miracle activity is one that has
transitions out of it but none into it, something that should be true only
of start points.

3. Decision Points

A decision point is modeled as a diamond on a UML Activity diagram.

1. Decision Points Should Reflect the Previous Activity. In Figure 1 you

see that there is no label on the decision point, unlike traditional
flowcharts which would include text describing the actual decision
being made, you need to imply that the decision concerns whether the
person was enrolled in the university based on the activity that the
decision point follows. The guards, depicted using the
format [description], on the transitions leaving the decision point also
help to describe the decision point.
2. Avoid Superfluous Decision Points. The Fill Out Enrollment
Forms activity in Figure 1 includes an implied decision point, a check
to see that the forms are filled out properly, which simplified the
diagram by avoiding an additional diamond.

4. Guards

A guard is a condition that must be true in order to traverse a transition.

1. Each Transition Leaving a Decision Point Must Have a Guard

2. Guards Should Not Overlap. For example guards such as x <0, x = 0,
and x > 0 are consistent whereas guard such as x <= 0 and x >= 0
are not consistent because they overlap – it isn’t clear what should
happen when x is 0.
3. Guards on Decision Points Must Form a Complete Set. For example,
guards such as x < 0 and x >0 are not complete because it isn’t clear
what happens when x is 0.
 4. Exit Transition Guards and Activity Invariants Must Form a Complete
Set. An activity invariant is a condition that is always true when your
system is processing an activity.
5. Apply a [Otherwise] Guard for “Fall Through” Logic.
6. Guards Are Optional. It is very common for a transition to not include a
guard, even when an activity includes several exit
transitions. Follow Agile Modeling (AM)’s principle of Depict
Models Simply and only indicate a guard on a transition if it adds
value.

5. Parallel Activities

It is possible to show that activities can occur in parallel, as you see

in Figure 1 depicted using two parallel bars. The first bar is called a fork, it
has one transition entering it and two or more transitions leaving it. The
second bar is a join, with two or more transitions entering it and only one
leaving it.

1. A Fork Should Have a Corresponding Join. In general, for every start

(fork) there is an end (join). In UML 2 it is not required to have a join,
but it usually makes sense.
2. Forks Have One Entry Transition.
3. Joins Have One Exit Transition
4. Avoid Superfluous Forks. Figure 2 depicts a simplified description of
the software process of enterprise architectural modeling, a part of
the Enterprise Unified Process (EUP). There is significant
opportunity for parallelism in this process, in fact all of these activities
could happen in parallel, but forks were not introduced because they
would only have cluttered the diagram.

6. Swimlane Guidelines

A swimlane is a way to group activities performed by the same actor on an

activity diagram or to group activities in a single thread. Figure 2 includes
three swimlanes, one for each actor.

Figure 2. A UML activity diagram for the enterprise architectural

modeling (simplified).
Figure 3. Submitting expenses.

1. Order Swimlanes in a Logical Manner.

2. Apply Swim Lanes To Linear Processes. A good rule of thumb is that
swimlanes are best applied to linear processes, unlike the one depicted
in Figure 2.
3. Have Less Than Five Swimlanes.
4. Consider Swimareas For Complex Diagrams.
5. Swimareas Suggest The Need to Reorganize Into Smaller Activity
Diagrams.
 6. Consider Horizontal Swimlanes for Business Processes. In Figure
3 you see that the swimlanes are drawn horizontally, going against
common convention of drawing them vertically.

7 Action-Object Guidelines

Activities act on objects, In the strict object-oriented sense of the term an

action object is a system object, a software construct. In the looser, and
much more useful for business application modeling, sense of the term an
action object is any sort of item. For example in Figure
3 the ExpenseForm action object is likely a paper form.

1. Place Shared Action Objects on Swimlane Separators

2. When An Object Appears Several Time Apply State Names
3. State Names Should Reflect the Lifecycle Stage of an Action Object
4. Show Only Critical Inputs and Outputs
5. Depict Action Objects As Smaller Than Activities

UML Statechart Diagram

A statechart diagram shows the behavior of classes in response to external
stimuli. This diagram models the dynamic flow of control from state to state
within a system.
Basic Statechart Diagram Symbols and Notations

States
States represent situations during the life of an object. You can easily
illustrate a state in SmartDraw by using a rectangle with rounded corners.

Transition
A solid arrow represents the path between different states of an object. Label
the transition with the event that triggered it and the action that results from
it.

Initial State
A filled circle followed by an arrow represents the object's initial state.

Final State
An arrow pointing to a filled circle nested inside another circle represents the
object's final state.

Synchronization and Splitting of Control

A short heavy bar with two transitions entering it represents a
synchronization of control. A short heavy bar with two transitions leaving it
represents a splitting of control that creates multiple states.