UML UNIFIED MODELING LANGUAGE Hoang Huu Hanh, PhD
[email protected] based on online courses and presentations
Slide 2
DEFINITION Unified Modeling Language is the successor to the
wave of Object- Oriented Analysis and Design methods that appear in
the late `80s and early `90s. Most directly unifies the methods of
Booch, Rumbaugh (OMT), and Jacobson, but its reach is wider than
that. UML went through a standardization process with the OMG
(Object Management Group) and is now an OMG standard. 2Introduction
to UML
Slide 3
UML History 3Introduction to UML
Slide 4
WHAT IT IS UML is a modeling language, not a method Most
methods consist, at least in principle, of both a modeling language
and a process. Modelling Language is the (mainly graphical)
notation that methods use to express designs. Process is their
advice on what steps to take in doing a design. Modeling Language
is the most important part of the method, which is the key part of
communication. 4Introduction to UML
Slide 5
WHY USE UML Helps Analysis and Design Used for communication
Use the advantages of OO Documentation As stated in The Unified
Modeling Language User Guide; UML is a language for: Visualizing
Specifying Constructing Documenting 5Introduction to UML
Slide 6
Visualizing It makes it easier to understand and work through
problem Since it is a formal language, it enables other developers
familiar with the language to more easily interpret our drawings.
6Introduction to UML
Slide 7
Specifying We must communicate our software system using some
common, precise, and unambiguous communication mechanism. Again the
formal nature of the UML facilitates this specification quite
nicely. 7Introduction to UML
Slide 8
Constructing We know that the UML is a formal language with its
own set of syntactical rules. Because of this formality, we can
create tools that interpret our models. They can map the elements
to a programming language, such as Java, C++. Many tools such as
Rational Rose, supports this forward engineering. In fact this is
one of the advantages of using a formal modeling tool.
8Introduction to UML
Slide 9
Documenting The models we create are just one of the articats
produced throughout the development lifecycle. Using the UML in a
consistent fashion produces a set of documentation that can serve
as a blueprint of our system. 9Introduction to UML
Slide 10
USAGES Define the boundaries of a system & its major
functions use cases and actors Illustrate use cases interaction
diagrams Define the static structure of a system class diagrams
Model the behavior of objects state transition diagrams Document
the physical implementation architecture component & deployment
diagrams Provide for growth stereotypes 10Introduction to UML
Slide 11
FUNDAMENTAL UML Models and Views Core Diagrams Fundamental
Elements 11Introduction to UML
Slide 12
12Introduction to UML
Slide 13
Models and Views UML is more than disjointed diagrams Turn
attention to an illustration of the UML from three different
perspectives Further insight into these divisions enables us to
realize one of the greatest benefits of modeling, which is creating
different views of our software system. 13Introduction to UML
Slide 14
Core Elements 14Introduction to UML
Slide 15
Core Elements (contd) An extension mechanism useful for
specifying structural elements. 15Introduction to UML
Slide 16
Fundamental Elements These are the elements of which diagrams
are composed Understanding the intent of each element enables us to
create precise diagrams, because each of them has unambiguous
meaning. 16Introduction to UML
Slide 17
DIAGRAMS Individual diagrams contribute more to the
specification of a software system. They are composition of many of
the fundamental elements. Are mechanism that developers use to
communicate and solve problems in the complex aspects of the
system. The most common diagram is the Class Diagram, which
describe the structural relationships that exist among the classes,
can guide developers in understanding our software systems class
structure. 17Introduction to UML
Slide 18
VIEWS As we become more proficient in modeling, we begin to
realize that using a combination of diagrams to communicate is most
effective. We may need to combine class diagram with a diagram
whose intent is to give systems dynamics. By combining these called
views. View is a depiction of our system from a particular
perspective. By making different views, we can represent our system
from different perspectives. 18Introduction to UML
Slide 19
VIEWS (contd) There are five main views, Use case Design
Development Process Physical They must be consistent with each
other, because all of them are representing the same system. Can be
used to validate each other. 19Introduction to UML
Slide 20
USE CASE VIEW This view documents the system from the customers
perspective. Terminology used in this view should be domain
specific. Depending on the technical nature of our audience, we
should avoid obscure technical terms. Diagrams most common in this
view are the use case diagrams and, less common, activity diagrams.
Organizations transitioning to the UML may wish to work only with
use case diagrams early and experiment with activity diagrams over
time. 20Introduction to UML
Slide 21
Design VIEW This view documents the system from designers and
architects perspective. Diagrams most common in this view are class
and interaction diagrams (either sequence or collaboration), as
well as package diagrams illustrating the package structure of our
Java application. 21Introduction to UML
Slide 22
Development VIEW This view documents the components that the
system is composed of. This view typically contains component
diagrams. Except for the most complex Java applications, this view
is optional. 22Introduction to UML
Slide 23
Process VIEW This view documents the processes and threads that
compose our application. These processes and threads typically are
captured on class diagrams using an active class. Because of the
advanced nature of active classes, coupled with the volume of use,
active classes are beyond the scope of this discussion.
23Introduction to UML
Slide 24
Physical VIEW This view documents the system topology.
Deployment diagrams that compose this view illustrate the physical
nodes and devices that make up the application, as well as the
connections that exist between them. 24Introduction to UML
Slide 25
VIEWS (cont.) We are not limited with the listed views. If
there is something that architecturally important, for example
security, then we may create a new view (ex: security view) into
the system from that perspective. 25Introduction to UML
Slide 26
Modeling Elements Structural elements class, interface,
collaboration, use case, active class, component, node Behavioral
elements interaction, state machine Grouping elements package,
subsystem Other elements note 26Introduction to UML
Slide 27
Diagrams - The foundation of UML Use Case Diagrams Requirements
Activity Diagrams Generally what, not who - good to detect
parallelism Interaction Diagrams Collaboration/Communication
Diagrams (object centered) Sequence Diagrams (timeline) Static
Structure Diagrams Objects/Classes/Packages Statechart Diagrams
States of objects with interesting lifecycles Implementation
Diagrams Component Diagrams Deployment Diagrams 27Introduction to
UML
Slide 28
DIAGRAMS As weve seen, we can combine diagrams that form models
and that can serve as views into our system. If an advantage in
modeling is to combine diagrams to form views into our system, then
it only makes sense that each diagram has a different focus on what
it communicates. Each falls into one of two categories: behavioral,
and structural. Most commonly used are use case, sequence, and
class diagrams. 28Introduction to UML
Slide 29
Behavioral diagrams Behavioral diagrams depict the dynamic
aspects of our system.They are most useful for specifying the
collaborations among elements that satisfy the behavior of our
systems requirements. Five diagrams that fall into this category
are; Use case Activity State Sequence Collaboration (Communication)
Mostly used are use case, sequence, and collaboration. Activity and
state diagrams are used on an as-needed basis. Activity diagrams
visually represent behaviors captured by use cases. State diagrams,
on the other hand, are used to illustrate complex transitions in
behavior for a single class. 29Introduction to UML
Slide 30
Core Relationships 30Introduction to UML
Slide 31
Core Relationships (contd) 31Introduction to UML
Slide 32
Relationships An association is a bi-directional connection
between classes An association is shown as a line connecting the
related classes An aggregation is a stronger form of relationship
where the relationship is between a whole and its parts An
aggregation is shown as a line connecting the related classes with
a diamond next to the class representing the whole A dependency
relationship is a weaker form of relationship showing a
relationship between a client and a supplier where the client does
not have semantic knowledge of the supplier A dependency is shown
as a dashed line pointing from the client to the supplier
32Introduction to UML
Slide 33
Relationship Notation 1 - one and only one 4 - four and only 4
0..1 - zero or 1 5..10 - five to and including 10 0..* - zero or
more 4..* - four or more 33Introduction to UML
Slide 34
Finding Relationships Relationships are discovered by examining
interaction diagrams If two objects must talk there must be a
pathway for communication 34 Registration Manager Math 101: Course
3: add student(joe) RegistrationManager Course Introduction to
UML
Slide 35
Relationships 35 RegistrationForm RegistrationManager Course
Student CourseOffering Professor addStudent(Course, StudentInfo)
name numberCredits open() addStudent(StudentInfo) name major
location open() addStudent(StudentInfo) name tenureStatus
ScheduleAlgorithm Introduction to UML
Slide 36
Associations 36
Slide 37
Association Ends Introduction to UML37
Slide 38
Relationship Notation 1 - one and only one 4 - four and only 4
0..1 - zero or 1 5..10 - five to and including 10 0..* - zero or
more 4..* - four or more 38Introduction to UML
Slide 39
Ternary Associations Introduction to UML39
Slide 40
Composition Introduction to UML40
Slide 41
Composition (contd) Introduction to UML41
Slide 42
Generalization Introduction to UML42
Slide 43
Generalization Introduction to UML43
Slide 44
Dependencies Introduction to UML44
Slide 45
Dependencies Introduction to UML45
Slide 46
Derived Attributes and Associations Introduction to UML46
Slide 47
Links Introduction to UML47
Slide 48
Constraints and Comments Introduction to UML48
Slide 49
Actors An actor is someone or some thing that interacts with
the system External Forces Human interaction Automated System 49
Keyboard Operator User Driver Traffic Control System >
Introduction to UML
Slide 50
Use Cases A use case is a pattern of behavior the system
exhibits Each use case is a sequence of related transactions
performed by an actor and the system in a dialogue Details what the
system must provide to the actor when the use cases is executed A
flow of events document is created for each use case Written from
an actor point of view Actors are examined to determine their how
they interact with the system Break down into the most atomic
actions possible Typical contents How the use case starts and ends
Normal flow of events Alternate flow of events Exceptional flow of
events 50Introduction to UML
Slide 51
Use case diagrams Use case diagrams are centered around the
business processes that our application must support. Most simply,
use case diagrams enable us to structure our entire application
around the core processes that it must support. Doing so enables us
to use these use cases to drive the remainder of the modeling and
development effort. Shows a set of actors and use cases, and the
relationships between them. Use case diagrams contribute to
effective model organization, as well as modeling the core
behaviors of a system. 51Introduction to UML
Slide 52
Use Case Diagram Captures system functionality as seen by users
Built in early stages of development Purpose Specify the context of
a system Capture the requirements of a system Validate a systems
architecture Drive implementation and generate test cases Developed
by analysts and domain experts 52Introduction to UML
Slide 53
Use Case Diagram Use case diagrams are created to visualize the
relationships between actors and use cases 53 Passager Mechanic
Driver Lost Luggage Ramp Maintenance Pay toll Customer Service
Agent Introduction to UML
Slide 54
Use Case Diagram Captures system functionality as seen by users
54Introduction to UML
Slide 55
Collaboration Diagrams A type of interaction diagram that
describes the organizational layout of the objects that send and
receive messages. Semantically equivalent to a sequence diagram. It
uses class diagrams layout, and can be used to make more cohesive
and less coupled classes. 55Introduction to UML
Slide 56
Collaboration Diagram A collaboration diagram displays object
interactions organized around objects and their links to one
another 56 : Registrar course form : CourseForm theManager :
CurriculumManager aCourse : Course 1: set course info 2: process 3:
add course 4: new course Introduction to UML
Slide 57
Sequence Diagrams Semantically equivalent to a collaboration
diagram. sequence diagram is a type of interaction diagram that
describes time ordering of messages sent between objects. Almost in
all software development activity, this diagram is used.
57Introduction to UML
Slide 58
Sequence Diagram A sequence diagram displays object
interactions arranged in a time sequence 58 Passenger Counter Agent
Ticket Gate Agent 1: Give Info 3: Answer 4: Print 6:Present 7:
Board 9: Return 8: Overbook 2: Questions Plane 5: Safeguard
Introduction to UML
Slide 59
The State of an Object A state transition diagram shows The
life history of a given class The events that cause a transition
from one state to another The actions that result from a state
change State transition diagrams are created for objects with
significant dynamic behavior 59Introduction to UML
Slide 60
State Transition Diagrams Illustrates internal state-related
behavior of an object. Transitions between states help identify,
and validate, complex behavior. A class can have at most a single
state diagram. 60Introduction to UML
Slide 61
State Transition Diagram 61 Initialization Open entry: Register
student exit: Increment count ClosedCanceled do: Initialize course
do: Finalize course do: Notify registered students Add Student /
Set count = 0 Add student[ count < 10 ] [ count = 10 ] Cancel
Introduction to UML
Slide 62
Activity Diagrams Models the flow of activity between
processes. These diagrams are most useful in detailing use case
behavior. An activity diagram doesnt show collaboration among
objects. 62Introduction to UML
Slide 63
STRUCTURAL DIAGRAMS Diagrams in this category are focused on
specifying the static aspects of our system. Of these four
diagrams, the class diagram is most often used. when transitioning
to the UML, most organizations tend to use class diagrams first
because they are excellent mechanisms for communication among
developers, as well as tools that can be used for problem solving.
There are two forms of class diagrams. The first is the most
commonly understood and consists of the classes that compose our
system and of the structure among these classes. Unfortunately, the
second is not often used but is of equal importance and can be most
effective in helping developers understand our system from a high
level. A type of class diagram, called a package diagram, often
represents the Java packages and the dependencies between them that
our application consists of. 63Introduction to UML
Slide 64
Class Diagrams Illustrates a set of classes, packages, and
relationships detailing a particular aspect of a system. This
diagram is likely the most common one used in modeling.
64Introduction to UML
Slide 65
Class Diagrams A class diagram shows the existence of classes
and their relationships in the logical view of a system UML
modeling elements in class diagrams Classes and their structure and
behavior Association, aggregation, dependency, and inheritance
relationships Multiplicity and navigation indicators Role names
Attributes The structure of a class is represented by its
attributes Attributes may be found by examining class definitions,
the problem requirements, and by applying domain knowledge
Operations The behavior of a class is represented by its operations
Operations may be found by examining interaction diagrams
65Introduction to UML
Slide 66
Class Diagram Captures the vocabulary of a system
66Introduction to UML
Slide 67
Object Diagrams Provides a snapshot of the system illustrating
the static relationships that exist between objects. Object
diagrams depict the structural relationship that exists among the
objects within our running application at a given point in time.
When we think of the runtime version of our system, we typically
think of behavior. Many people have found that object diagrams are
most useful in fleshing out the instance relationships among
objects, which in turn can help verify our class diagrams. Beyond
this, object diagrams are not often used. 67Introduction to
UML
Slide 68
Relationships Relationships provide a pathway for communication
between objects Sequence and/or collaboration diagrams are examined
to determine what links between objects need to exist to accomplish
the behavior -- if two objects need to talk there must be a link
between them Three types of relationships are: Association
Aggregation Dependency 68Introduction to UML
Slide 69
Multiplicity and Navigation Multiplicity defines how many
objects participate in a relationships Multiplicity is the number
of instances of one class related to ONE instance of the other
class For each association and aggregation, there are two
multiplicity decisions to make: one for each end of the
relationship Although associations and aggregations are bi-
directional by default, it is often desirable to restrict
navigation to one direction If navigation is restricted, an
arrowhead is added to indicate the direction of the navigation
69Introduction to UML
Slide 70
Multiplicity and Navigation 70 RegistrationForm
RegistrationManager Course Student CourseOffering Professor
addStudent(Course, StudentInfo) name numberCredits open()
addStudent(StudentInfo) major location open()
addStudent(StudentInfo) tenureStatus ScheduleAlgorithm 1 0..* 1 1
1..* 4 3..10 0..4 1 Introduction to UML
Slide 71
Inheritance Inheritance is a relationships between a superclass
and its subclasses There are two ways to find inheritance:
Generalization Specialization Common attributes, operations, and/or
relationships are shown at the highest applicable level in the
hierarchy 71Introduction to UML
Slide 72
Inheritance 72 RegistrationForm RegistrationManager Course
Student CourseOffering Professor addStudent(Course, StudentInfo)
name numberCredits open() addStudent(StudentInfo) major location
open() addStudent(StudentInfo) tenureStatus ScheduleAlgorithm name
RegistrationUser Introduction to UML
Slide 73
The Physical World Component diagrams illustrate the
organizations and dependencies among software components A
component may be A source code component A run time components or
An executable component 73Introduction to UML
Slide 74
Component Diagrams Addresses the static relationships existing
between the deployable software components. Examples of components
may be.exe,.dll,.ocx, jar files, and/or Enterprise JavaBeans.
Component diagrams might be used to show the software components
within our application. Components arent equivalent to classes.
74Introduction to UML
Slide 75
Component Diagram Captures the physical structure of the
implementation 75Introduction to UML
Slide 76
Deploying the System The deployment diagram shows the
configuration of run-time processing elements and the software
processes living on them The deployment diagram visualizes the
distribution of components across the enterprise. 76Introduction to
UML
Slide 77
Deployment Diagram Captures the topology of a systems hardware
77Introduction to UML
Slide 78
Extensibility Mechanisms Stereotype Tagged value Constraint
78Introduction to UML
Slide 79
Extending the UML Stereotypes can be used to extend the UML
notational elements Stereotypes may be used to classify and extend
associations, inheritance relationships, classes, and components
Examples: Class stereotypes: boundary, control, entity, utility,
exception Inheritance stereotypes: uses and extends Component
stereotypes: subsystem 79Introduction to UML
Slide 80
Deployment Diagrams Describes the physical topology of a
system. Typically includes various processing nodes, realized in
the form of a device (for example, a printer or modem) or a
processor (for example, a server). Deployment diagrams are most
useful when we have a complex configuration environment. If our
application is to be deployed to multiple servers, across
locations, a deployment diagram might be useful. 80Introduction to
UML