Report

UML
Unified Modeling Language
Bermudez, Raymond; Elofre, Rifle; Manalang, Joseph
 Outline
• Introduction to UML
– What is UML? Why use UML?
• 9 UML diagrams
– Use Case Diagram; Object Diagram ; Class Diagram;
Sequence Diagram and Collaboration Diagram
(Interaction Diagrams); Statechart Diagram; Activity
Diagram; Package Diagram; Component
Diagram;Deployment Diagram
 What is UML?

• UML → “Unified Modeling Language”

– Unified: UML has become a world standard
– Modeling :Describing a software system at a high
level of abstraction
– Language: More comprehensible, ready-to-use,
expressive, and visualing.
 What is UML?
• Goals of UML:
– Provide extensibility and specialization mechanisms to
extend the core concepts
– Be independent of particular programming languages and
development processes
– Provide a formal basis for understanding the modeling
language
– Encourage the growth of the OO tools market.
– Support higher-level development concepts such as
collaborations, frameworks, patterns and components.
 What is UML?
• History of UML
– Object-Oriented modeling languages began to
appear between mid-1970 and the late 1980s ;
– Identified modeling languages: < 10  > 50 (1989-
1994 )
– Necessity and development
 What is UML?
Year Version
2003: UML 2.0
2001: UML 1.4
1999: UML 1.3
1997: UML 1.0, 1.1
1996: UML 0.9 & 0.91
1995: Unified Method 0.8

Booch ‘93 OMT - 2

Other methods

Booch ‘91
OMT - 1
began in late 1994(unifying the Booch and OMT
(Object Modeling Technique) methods )
 Use Case Diagram
http://www.visual-paradigm.com/VPGallery/diagrams/UseCase.html

• a diagram that shows the relationships among actors and use cases
within a system.
• 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 case model
System Use Case Diagram
Figure 1
•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 artefact 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:
 Use Cases
 Actors
 Relationships
 System Boundary Boxes
•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.
•Use Case Names Begin With a Strong Verb
•Name Use Cases Using Domain Terminology
•Place Your Primary Use Cases In The Top-Left Corner Of The
Diagram
•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
 Implying timing considerations between use cases

Figure 1
 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).
 
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
 Actors
(Online Shopping)
 Relationship
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 modelling 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 modelling element.
Enrolling students in a university.  
 Relationship
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
 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.

Figure 2 
 Object Diagram

• http://www.visual-paradigm.com/VPGallery/diagrams/Object.html

•Object diagrams are derived from class diagrams so object diagrams are dependent
upon class diagrams.
•Object diagrams represent an instance of a class diagram. The basic concepts are
similar for class diagrams and object diagrams. Object diagrams also represent the static
view of a system but this static view is a snapshot of the system at a particular moment.
•Object diagrams are used to render a set of objects and their relationships as an
instance.
 Where to use Object Diagram
Object diagrams can be imagined as the snapshot of a running system at a particular
moment. Now to clarify it we can take an example of a running train.
Now if you take a snap of the running train then you will find a static picture of it having the
following:

• A particular state which is running

• A particular number of passengers. which will change if the snap is taken in a different
time.
• So here we can imagine the snap of the running train is an object having the above
values. And this is true for any real life simple or complex system. In a brief, object
diagrams are used for:

• Making the prototype of a system.

• Reverse engineering.
• Modeling complex data structures.
• Understanding the system from practical perspective.
show the classes of the system, their inter-relationships, and the operations and attributes
of the classes. Class diagrams are typically used, although not all at once, to:

• Explore domain concepts in the form of a domain model

• Analyze requirements in the form of a conceptual/analysis model
• Depict the detailed design of object-oriented or object-based software
A class model is comprised of one or more class diagrams and the supporting
specifications that describe model elements including classes, relationships between
classes, and interfaces. There are guidelines for:
• General issues
• Classes
• Interfaces
• Relationships
• Inheritance
• Aggregation and Composition
 General Guidelines
Because class diagrams are used for a variety of purposes – from understanding
requirements to describing your detailed design – you will need to apply a different style
in each circumstance.  This section describes style guidelines pertaining to different types
of class diagrams.

Analysis and design versions of a class.

 Conceptual Modeling of a Class
• A class diagram is a graphical representation of
a static view on declarative, static elements
• Class diagrams contain:
• Packages
• Classes
• relationships
 Class in a conceptual class diagram
• A class is the description of a set of objects having similar
attributes, operations, methods, relationships, and behavior.
• A class has
– Name
– Description (responsibility, job)
– Attributes
• Names
• Description, optional:type
– (Methods)
 Association
• An association is a semantic relationship between classes
which concerns the connection (e.g. references) between
instances
• Notation:
– Name
– Multiplicity
– Description
(extracted from use case)
 Multiplicity

• The multiplicity of an association of defines the valid range of

values for the number of objects taking part in the association.

Notation Example
Number 1 3,4
Number…number 0..1 1..2 0..1,4
Number..* 1..* 2..*
No number *
* *
 Role
• A role is an association is the name describing the
participation of the class in the association more
exactly.
 Aggregration
• An aggregation resp. to composition is semantic relationship
between an aggregate A and a component B. “B is part of A”
 Generalization
Generalization is a semantic relationship between a general concept A (super
class) and a more special concept B (sub class).
“B specialize A”, each B is an A
For classes: Inheritance builds a taxonomy
 Constraint and Note
Constraints and notes annotate among other things
associations, attributes and classes. Constraints are semantic
restrictions noted as an expression.
 Class Diagram
http://www.visual-paradigm.com/VPGallery/diagrams/Class.html

Modelling association classes.

 Sequence and
Collaboration Diagram

http://www.visual-paradigm.com/VPGallery/diagrams/Sequence.html

http://www.visual-paradigm.com/VPGallery/diagrams/Collaboration.html
 UML Sequence Diagrams

 Models the flow of logic within your system in a visual manner, enabling you both
to document and validate your logic

Are commonly used for both analysis and design purposes. 

 Are the most popular UML artifact for dynamic modeling, which focuses on
identifying the behavior within a system.

Other dynamic modeling techniques include:

• Activity diagramming
• Communication diagramming
• Timing diagramming
• Interaction overview diagramming
 Typical Models
Usage scenarios.  A usage scenario is a description of a potential way a system is used.
The logic of a usage scenario may be part of a use case, perhaps an alternate course. It
may also be one entire pass through a use case, such as the logic described by the basic
course of action or a portion of the basic course of action, plus one or more alternate
scenarios. The logic of a usage scenario may also be a pass through the logic contained in
several use cases. For example, a student enrolls in the university, and then immediately
enrolls in three seminars.

The logic of methods.   Sequence diagrams can be used to explore the logic of a
complex operation, function, or procedure. 

The logic of services.  A service is effectively a high-level method, often one that can be
invoked by a wide variety of clients.  This includes web-services as well as business
transactions implemented by a variety of technologies such as CICS/COBOL or CORBA-
compliant object request brokers (ORBs).
 Example 1:
System-level sequence diagram
 Example.
Service-level sequence diagram
 Enrolling in a seminar (Method)

The dashed lines hanging from the boxes are called object lifelines, representing the life span of the object during
the scenario being modeled. The long, thin boxes on the lifelines are activation boxes, also called method-invocation
boxes, which indicate processing is being performed by the target object/class to fulfill a message.  I will only draw
activation boxes when I’m using a tool that natively supports them, such as a sophisticated CASE tool, and when I
want to explore performance issues. Activation boxes are too awkward to draw on whiteboards or with simple
drawing tools such that don’t easily support them.
 Basic course of action for
the Enroll in Seminar use case.

Messages are indicated on UML sequence diagrams as labeled arrows, when the source and target of a
message is an object or class the label is the signature of the method invoked in response to the message.
However, if either the source or target is a human actor, then the message is labeled with brief text
describing the information being communicated.
 .

An alternate course of action

for the Enroll in Seminar use case
.

Outputting Transcripts
 How to Draw Sequence Diagrams
People who get it are either very good at thinking in a logical manner and/or they are
good at writing software code
Sequence diagramming really is visual coding, even when you are modeling a usage
scenario via a system-level sequence diagram
1. Start by identifying the scope of what I’m trying to model
2. Then work through the logic with at least one more person, laying out classifiers
across the top as you need them
 Keeping it Agile
 The most important things that you can do is to keep your diagrams simple, both
content wise and tool wise
 I will sketch sequence diagrams on whiteboards to think something through,
either to verify the logic in a use case or to design a method or service. I rarely
keep sequence diagrams as I find their true value is in their creation. 
A common mistake is to try to create a complete set of sequence diagrams for your
system.  I’ve seen project teams waste months creating several sequence diagrams
for each of their use cases, one for the basic course of action and one for each
alternate course
  My advice is to only create a sequence diagram when you have complex logic that
you want to think through – if the logic is straightforward the sequence diagram
won’t add any value, you had might as well go straight to code.
 Keeping it Agile
 The most important things that you can do is to keep your diagrams simple, both
content wise and tool wise
 I will sketch sequence diagrams on whiteboards to think something through,
either to verify the logic in a use case or to design a method or service. I rarely
keep sequence diagrams as I find their true value is in their creation. 
A common mistake is to try to create a complete set of sequence diagrams for your
system.  I’ve seen project teams waste months creating several sequence diagrams
for each of their use cases, one for the basic course of action and one for each
alternate course
  My advice is to only create a sequence diagram when you have complex logic that
you want to think through – if the logic is straightforward the sequence diagram
won’t add any value, you had might as well go straight to code.
 Communication Diagram
• To show the behavior of several objects collaborating
together to fulfill a common purpose
• Formerly known as collaboration diagrams in UML 1.x
• Can be used for because they provide a birds-eye view
of a collection of collaborating objects
• Show the message flow between objects in an OO
application and also imply the basic associations
(relationships) between classes
 Example:
Communication Diagram

[sequenceNumber:] methodName(parameters) [: returnValue]

 UML
State Machine Diagram
http://www.visual-paradigm.com/VPGallery/diagrams/State.html

 Diagrams depict the various states that an object may be in and the
transitions between those states.
 In other modeling languages, it is common for this type of a diagram to be
called a state-transition diagram or even simply a state diagram.
 A state represents a stage in the behavior pattern of an object, and
like UML activity diagrams it is possible to have initial states and final
states.
 An initial state, also called a creation state, is the one that an object
is in when it is first created, whereas a final state is one in which no
transitions lead out of.
 A transition is a progression from one state to another and will be
triggered by an event that is either internal or external to the object.
 Statechart Diagram
A seminar during registration
Top-level state machine diagram
 Drawing a
State Machines Diagram
1. When drawing a state machine diagram the thing you want to do is to identify the creation state
and whether any final states exist
2. After you have done this, ask yourself what other states or stages in the life of an object does it
pass through?
3. Once you have identified as many states as you can, start looking for transitions
4. For each state, ask yourself how the object can get out of it, if possible. This will give you a
transition. Because all transitions lead from one state to another, ask yourself what new state the
transition leads you to (don’t forget about recursive transitions that lead to the same state). 
5. You should also look at the methods you identified in your class diagram. Some of them will
correspond to a transition in your state diagram
6. Identifying potential error conditions while you are state machine modeling is common because
you are constantly asking “should this transition be allowed when the object is in this state?”
When the answer is yes, you need to add the transition to your diagram. When the answer  is no,
you may need to document this potential issue so your programmers develop the proper error
checking code, so the transition is not allowed to occur
 Activity Diagram
• Typically used for business process modeling, for modeling the
logic captured by a single use case or usage scenario, or for
modeling the detailed logic of a business rule. 
• Although UML activity diagrams could potentially model the
internal logic of a complex operation it would be far better to
simply rewrite the operation so that it is simple enough that you
don’t require an activity diagram.
• In many ways UML activity diagrams are the object-oriented
equivalent of flow charts and data flow diagrams (DFDs) from
structured development.
 http://www.visual-paradigm.com/VPGallery/diagrams/Activity.htm

Initial node. The filled in circle is the starting point of the diagram.  An initial node isn’t
required although it does make it significantly easier to read the diagram.
Activity final node. The filled circle with a border is the ending point.  An activity diagram
can have zero or more activity final nodes.
Activity.   The rounded rectangles represent activities that occur. An activity may be
physical, such as Inspect Forms, or electronic, such as Display Create Student Screen.
Flow/edge.  The arrows on the diagram.  Although there is a subtle difference between
flows and edges. 
Fork.  A black bar with one flow going into it and several leaving it.  This denotes the
beginning of parallel activity.
Join.  A black bar with several flows entering it and one leaving it.  All flows going into the
join must reach it before processing may continue.  This denotes the end of parallel
processing.
Condition.  Text such as [Incorrect Form] on a flow, defining a guard which must evaluate to
true in order to traverse the node.
Decision. A diamond with one flow entering and several leaving.  The flows leaving include
conditions although some modelers will not indicate the conditions if it is obvious. 
Merge.  A diamond with several flows entering and one leaving.  The implication is that one
or more incoming flows must reach this point until processing continues, based on any
guards on the outgoing flow.
Partition. Figure 2 is organized into three partitions, also called swimlanes, indicating
who/what is performing the activities (either the Applicant, Registrar, or System).
Sub-activity indicator.  The rake in the bottom corner of an activity, such as in the Apply to
University activity, indicates that the activity is described by a more finely detailed activity
diagram.  In Figure 2 the Enroll In Seminar activity includes this symbol.
 Activity Diagram

Flow final.  The circle with the X through it.  This indicates that the process stops at this
point. 
Note. Figure 2 includes a standard UML note to indicate that the merges does not
require all three flows to arrive before processing can continue.  An alternative way to
model this would have been with an OR constraint between the no match and
applicant not on match list flows. 
Use case.  Indicated in the Enroll in Seminar use case it is invoked as one of the
activities.  
 Figure 1.
UML activity diagram for the
Enroll in University use case
 Figure 2.
UML activity diagram with
partitions based on actors
 Package Diagram
http://www.visual-paradigm.com/VPGallery/diagrams/Package.html
• A package diagram is a UML diagram composed only of packages
and the dependencies between them. 
• A package is a UML construct that enables you to organize model
elements, such as use cases or classes, into groups. 
• Packages are depicted as file folders and can be applied on any UML
diagram. 
• Create a package diagram to:
– Depict a high-level overview of your requirements (overviewing a collection of UML
Use Case diagrams)
– Depict a high-level overview of your architecture/design (overviewing a collection of
UML Class diagrams).
– To logically modularize a complex diagram
 Package Diagram
Class Package Diagram
RULES
1. Create UML Component Diagrams to Physically Organize Your
Design.
2. Place Sub packages Below Parent Packages.
3. Vertically Layer Class Package Diagrams.
4. Create Class Package Diagrams to Logically Organize Your
Design.
Example of Class Package
Diagram
 Package Diagram
In addition to the package guidelines presented below,
apply the following heuristics to organize UML Class
diagrams into package diagrams:
– Place the classes of a framework in the same package.
– Classes in the same inheritance hierarchy typically belong in
the same package.
– Classes related to one another via aggregation or
composition often belong in the same package.
– Classes that collaborate with each other a lot, information
that is reflected by your UML Sequence diagrams and UML
Collaboration diagrams, often belong in the same package.
 Package Diagram
Use-Case Package Diagram
Use cases are often a primary requirement artifact in object-
oriented development methodologies, this is particularly true of
instantiations of the Unified Process, and for larger projects
package diagrams are often created to organize these usage
requirements.  
Suggestions:
– Create Use Case Package Diagrams to Organize Your
Requirements
– Include Actors on Use Case Package Diagrams
– Horizontally Arrange Use Case Package Diagrams
Example of Use Case
Package Diagram
 Component Diagram
http://www.visual-paradigm.com/VPGallery/diagrams/Component.html

• The component diagram's main purpose is to show the

structural relationships between the components of a
system.

• Developers find the component diagram useful because it

provides them with a high-level, architectural view of the
system that they will be building, which helps developers
begin.
 Component Diagram
• NOTATIONS:
• Component
– is drawn as a rectangle with optional compartments stacked
vertically
– A high-level, abstracted view of a component in UML 2 can be
modeled as just a rectangle with the component's name and the
component stereotype text and/or icon.
– The component stereotype's text is «component»" and the
component stereotype icon is a rectangle with two smaller
rectangles protruding on its left side.
 Component Diagram
• Component
– 3 ways to draw:

– When drawing a component on a diagram, it is important that you

always include the component stereotype text and/or icon. In UML, a
rectangle without any stereotype classifier is interpreted as a class
element. The component stereotype and/or icon distinguishes this
rectangle as a component element.
 Component Diagram
Modeling a component's interfaces
Provided/Required
• A component element can have
additional compartments
stacked below the name
compartment.
• The interfaces provided
represent the formal contract of
services the component
provides to its
consumers/clients.
 Component Diagram
Another approach to modeling a component's interfaces
• The interface symbols with a complete circle at their end represent an
interface that the component provides — this lollipop" symbol is
shorthand for a realization relationship of an interface classifier.
• Interface symbols with only a half circle at their end (a.k.a. sockets)
represent an interface that the component requires
 Component Diagram
Modeling a component's relationships

• When showing a component's relationship with other

components, the lollipop and socket notation must also include
a dependency arrow (as used in the class diagram).

• On a component diagram with lollipops and sockets, the

dependency arrow comes out of the consuming (requiring)
socket and its arrow head connects with the provider's lollipop.
Component Diagram
 Deployment Diagram
http://www.visual-paradigm.com/VPGallery/diagrams/Deployment.html

• Depicts a static view of the run-time configuration of processing nodes and

the components that run on those nodes.

• Deployment diagrams show the hardware for your system, the software that
is installed on that hardware, and the middleware used to connect the
disparate machines to one another.

• You want to create a deployment diagram for applications that are deployed
to several machines, for example a point-of-sales application running on a
thin-client network computer which interacts with several internal servers
behind your corporate firewall or a customer service system deployed using a
web services architecture such as Microsoft’s .NET.
 Deployment Diagram
• The notation in a deployment diagram includes the notation elements
used in a component diagram, with a couple of additions, including
the concept of a node.
• A node represents either a physical machine or a virtual machine node
(e.g., a mainframe node). To model a node, simply draw a three-
dimensional cube with the name of the node at the top of the cube.
Use the naming convention used in sequence diagrams.
• Physical nodes should be labeled with the stereotype device, to
indicate that it is a physical device such as a computer or switch. 
• Connections between nodes are represented with simple lines, and
are assigned stereotypes such as RMI and message bus to indicate the
type of connection.  
Example of Deployment Diagram
• CONCISE UML 2 DEPLOYMENT DIAGRAM
• A better example is shown in the figure. Software elements are now simply
listed by their physical filenames, information that developers are very likely
to be interested in, and thus a more compact diagram is possible.  A drum is
used as a visual stereotype for the University DB database, making it easier to
distinguish on the diagram. Another difference is that the concise version
shows less details, not as many tagged values are shown as this information
can be captured in either supporting documentation, configuration files, or
source code. 
 Deployment Diagram
NETWORK DIAGRAM
• Network diagrams are often drawn using software-based
drawing tools (figure below was drawn using Microsoft Visio)