Transcript mcsrockers.jimdo.com

Introduction to UML
Course Instructor: Aisha Azeem
Introduction
 UML stands for Unified Modeling Language.
 It is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software
systems.
Specifying
Visualizing
Business Modeling
Constructing
Documenting
Communications
UML Building Blocks
 Class:
 Class represents set of objects having similar
responsibilities.
 Use case:
 Use case represents a set of actions performed by a
system for a specific goal.
 Interaction:
 Interaction is defined as a behavior that consists of a group of
messages exchanged among elements to accomplish a specific task.
Cont . . .
 State machine:
 State machine is useful when the state of an object in its
life cycle is important.
 It defines the sequence of states an object goes through
in response to events. Events are external factors
responsible for state change.
 Note:
 A note is used to render comments, constraints etc of an UML element.
Cont . . .
 Generalization:
 Generalization can be defined as a relationship which connects a
specialized element with a generalized element. It basically describes
inheritance relationship in the world of objects.
 Aggregation:
 Whole part relationship i.e. large part “whole” contains one or more
parts. E.g. building “whole” contains rooms ”parts”
 Composition:
 Is a relationship in which if the “whole” part dies, the child has to die as
well. E.g. if building collapse , rooms no more exist
UML Models, Views,
Diagrams
 UML is a multi-diagrammatic language
 Each diagram is a view into a model
 Diagram presented from the aspect of a particular
stakeholder
 Provides a partial representation of the system
 Is semantically consistent with other views
 Example views
Models, Views, Diagrams
UML Diagrams
 UML diagrams are the ultimate output of the entire
discussion.
 All the elements, relationships are used to make a complete
UML diagram and the diagram represents a system.
 UML includes the following nine diagrams









Class diagram
Object diagram
Use case diagram
Sequence diagram
Collaboration diagram
Activity diagram
State chart diagram
Deployment diagram
Component diagram
UML Modeling Types
 Different diagrams are used for different type of UML
modeling.
 There are three important type of UML modeling :
1) Structural modeling:
 Structural modeling captures the static features of a system.
 They consist of the followings: Class diagrams , Objects
diagrams , Deployment diagrams , Component diagram etc
 Structural model represents the framework for the system and
this framework is the place where all other components exist.
 They all represent the elements and the mechanism to
assemble them.
 E.g. class written once remain same through out the execution.
Cont . . .
2)
Behavioral Modeling:
 Behavioral model describes the interaction in the system.
 It represents the interaction among the structural
diagrams.
 Behavioral modeling shows the dynamic nature of the
system
 Activity diagrams , Interaction diagrams, Use case
diagrams
 Depends upon the behavior of an object/entity object
can have more then one state, and depending upon its
state its behavior would be different.
 E.g. bank account may be working(deposit/ withdraw)
Not working(closed/ dead)
Cont . . .
3)
Dynamic Modeling:

The dynamic model is used to express and model the
behavior of the system over time.

It includes support for activity
diagrams, sequence diagrams
diagrams,
state

e.g. user login(id, password), valid tries to login , its set
of sequences will be different as compared to an
invalid user.
Use-Case Diagram
 Use Case Diagram is used to describe the functionalities
provided by a system and the users associated with that
system.
 The Use case diagram is used to identify the primary elements
and processes that form the system.
 The primary elements are termed as "actors" and the
processes are called "use cases."
 The Use case diagram shows which actors interact with each
use case.
Use-Case Diagram
 The main purpose of the use-case diagram is:
 to help development teams visualize the functional
requirements of a system
 To help identify relationship of "actors" (human beings
who will interact with the system) with essential processes
 and understand the relationships among different use
cases
Elements of a use-case
diagram
 Use-case diagrams contain the following elements:
• Actors, which represent users of a system, including human
users and other systems.
• Use Cases, which represent
provided by a system to users.
functionality
or
services
Actor
 Definition:
 The outside entity which communicates with the system:
 A Person (user)
 An external system
 Physical Environment
 An Actor has a unique name and an optional
description
 Symbol:
UML notation used to represent an
actor
Actor (Example)
 Consider the following scenario related to a “University
Management System” :
 In a university management system, a Student can submit
the assignments, the instructor marks those assignments
and then uploads the result. The Student is allowed to
view the Results.
 Now, by recalling the definition of actor, can you identify
the actors in this System?
 Student
 Instructor
Actor (Example/2)
Instructor
Student
Student
Student
is
an
external
entity
which
interacts
with the system.
Student is a user of
this
system,
as
some services are
used by it.
Instructor
Instructor is another
external
entity
which interacts with
the
university
management
system.
Use-case
 Represent functionality or services provided by a system to
users.
 It is a description of set of sequence of actions that a system
perform that produces an observable result.
 A use case represents a class of functionality provided by the
system as an event flow.
 Use cases describe the interaction between a primary actor
and the system itself
Use-case
 The use case technique is used in software and systems
engineering to capture the functional requirements of a
system.
 Each use case describes how the actor will interact with the
system to achieve a specific goal.
 One or more scenarios may be generated from each use
case, corresponding to the detail of each possible way of
achieving that goal.
 Symbol :
UML notation used to represent a usecase
Use-case (Example)
 Consider the same example again:
 In a university management system, a Student can submit
the assignments, the instructor marks those assignments
and then uploads the result. The Student is allowed to view
the Results.
 Now, by recalling the definition of use-case, can you
identify the use-cases in this System?




Submit Assignments
Mark Assignments
Upload Results
View Results
Use-case (Example/2)
 The use-cases are linked with the functional requirements of
this system. In this example :
 Student submit the assignments.
 Instructor marks the assignments.
 Instructor upload the marks.
 Student can view the marks.
 It is now clear that how actors are interacting with different
use-cases of this system.
 Now, lets combine actors and use-cases in one diagram?
Symbols in Use-Case
Diagrams
ACTOR
USE-CASE
INTERACTION:
denotes set of messages exchanged among
objects
NOTES/COMMENTS
Use-Case Diagram (University
Management System)
Submit
Assignments
Mark
Assignments
Student
Upload
Results
View Results
Instructor
Package:
System
University Management
SYSTEM
BOUNDARY
Cont . . .
 Other types of associations and relationships;




Generalization between use cases
Generalization between actors
Include relationship between use cases
Extend relationship between use cases
Generalization between Use
cases
 Represented by a line and a hollow arrow
 From child to parent
 A use case generalization shows that one use case is
simply a special kind of another.
 A child can be substituted for its parent whenever
necessary.
 Generalization appears as a line with a triangular arrow
head toward the parent use case
Child use case
Parent use case
Example
Register car
sharer
Manually
add car
sharer
CarMatch
Administrator
Example : ATM
Transfer car
sharer from
web server
Web Server
Generalization between
Actors (examples)
student
Foreign student
Local student
Include relationship
between use cases
 Some times one use case includes the functionality of
another use case.
 Include relationship is drawn as an open arrow with dashed
lines that points towards the use case that is being included
 The word include is written in << . . . . . . >>
Or
 If x is a task and y is a sub task but acting as a part of it then
use <<include >> stereotype
 Arrowhead towards the subtask
Example
Extend relationship
between use cases
 There are occasions where one use case may optionally be
extended by the functionality in another use case.
 The relationship is drawn as an open arrow with dashed line
the points towards the use case that is being extended.
 The word extend is written in <<……..>>
Or
 If x is a task and y is a sub task of x but little bit different
 Arrow head towards the main task
Example
Take turn
Driver
<<extends>>
Passenger
Turn left
Purchase Ticket
<<extends>>
<<extends>>
OutOfOrder
<<extends>>
<<extends>>
Cancel
NoChange
TimeOut
<<extends>>
Turn right
Practice
 Read the following case :
 Identify the actors
 Identify (extract ) the use cases
 Construct a proper use-case diagram (with proper
symbols & notations)
Case-Study
 Consider the Library Management System of UOW. A Student is
allowed to issue books for a period of two weeks. Student can
read newspapers/magazines in the library and can even
access the databases for e-books. The Library Staff is
responsible for maintaining the records of students and along
with the issued books. The Staff marks an entry in the register
whenever a student issue or return a book. A fine is charged on
a student if he/she fail to return the book on time. The Librarian
is there to manage the staff, check the records and prepare
reports for DG/DEAN.
Class diagrams
 Gives a graphical representation of domain model.
 It represents relationship of classes objects with object
specification in detail.
 It gives static view of the system
 Each class is represented by a rectangle subdivided into
three compartments
 Name
 Attributes
 Operations
Class Diagram: Visibilities
 Modifiers are used to indicate visibility of attributes and
operations.
 ‘+’ is used to denote Public visibility (everyone)
 ‘#’ is used to denote Protected visibility (derived)
 ‘-’ is used to denote Private visibility (no one)
 By default, attributes are hidden and operations are
visible.
 The last two compartments may be omitted to simplify
the class diagrams
An example of Class
Account_Name
- Custom_Name
- Balance
+AddFunds( )
+WithDraw( )
+Transfer( )
Name
Attributes
Operations
Other representations of
class
Boeing 737
Boeing 737
length: meter
fuelCapacity: Gal
Boeing 737
length: meter
fuelCapacity: Gal
doors: int
Boeing 737
lift()
roll()
doors: int
lift ( )
roll ( )
thrust ( )
Class Attributes (Cont’d)
Person
Attributes are usually listed in the form:
attributeName : Type
name
: String
address : Address
birthdate : Date
/ age
: Date
ssn
: Id
A derived attribute is one that can be
computed from other attributes, but
doesn’t actually exist. For example,
a Person’s age can be computed from
his birth date. A derived attribute is
designated by a preceding ‘/’ as in:
/ age : Date
Class Attributes (Cont’d)
Person
+ name
: String
# address : Address
# birthdate : Date
/ age
: Date
- ssn
: Id
Attributes can be:
+ public
# protected
- private
/ derived
Class Diagram: Association
• Associations represent relationships between instances
of classes .
• An association is a link connecting two classes.
 Bi-directional association
Associations are assumed to be bi-directional
BankAccount
Person
 Uni-directional association
e.g. Bank Account and person
BankAccount
Person
Association: Multiplicity
and Roles
teaches
Student
1..*
learns from
1..*
Instructor
Multiplicity
Symbol
Meaning
1
One and only one
0..1
Zero or one
M..N
From M to N (natural language)
*
From zero to any positive integer
0..*
From zero to any positive integer
1..*
From one to any positive integer
Note: if no multiplicity is given it is assumed to be 1
Association name: represents nature
of participants classes in a relationship.
Association Role: role played by the
participant class
Notation of Class Diagram:
Generalization
Student
Employee
Supertype
TeachingAssistant
Subtype1
Subtype2
Person
Generalization expresses
a relationship among
related classes. It is a
class that includes its
subclasses.
Student
Cont . . .
Separate target style
Vehicle
Bus
Truck
Car
Shared target style
BoeingAirplane
Boeing 737
Boeing 757
Boeing 767
Notation of Class Diagram:
Composition
COMPOSITION
•Composition: expresses a relationship
among instances of related classes.
•It is a specific kind of Whole-Part
relationship.
Whole Class
Class W
Class P1
Class P2
Part Classes
Example
Automobile
Engine
windows
•It expresses a relationship where an
instance of the Whole-class has the
responsibility to create and initialize
instances
of
each
Part-class.
Composition should also be used to express
relationship where instances of the Wholeclass have exclusive access to and
control of instances of the Part-classes.
Cont . . .
Car
1
4
Wheel
1
4, 10
Light
1
1
2, 5
1
Door
Engine
Notation of Class Diagram:
Aggregation
AGGREGATION
Container Class
Class C
Class E2
Class E1
Containee Classes
Example
Apples
Aggregation: expresses a relationship
among instances of related classes. It
is a specific kind of ContainerContainee relationship.
It expresses a relationship where an
instance of the Container-class has the
responsibility to hold and maintain
instances of each Containee-class
Aggregation is appropriate when
Container and Containees have no
special access privileges to each
other.
Bag
Milk
Cont. . .
Team
1
class
Consists Of
*
Player
Aggregation vs. Composition
• Composition is really a strong form of aggregation
•components have only one owner
•components cannot exist independent of their owner;
• both have coincident lifetimes
•components live or die with their owner
•e.g. (1)Each car has an engine that can not be share with other
car
(2) If the polygon is destroyed, so are the points.
•Aggregations may form "part of" the aggregate, but may not be
essential to it.
•They may also exist independent of the aggregate. Less rigorous
than a composition
• e.g. (1)Apples may exist independent of the bag.
(2)An order is made up of several products, but the
products are still there even if an order is cancelled.
Class Diagram example
Name
Order
Attributes
Operations
-dateReceived
-isPrepaid
-number :String
-price : Money
class
Multiplicity: mandatory
*
Customer
1
+dispatch()
+close()
Association
-name
-address
+creditRating() : String()
1
Generalization
Multiplicity:
Many value
Corporate Customer
Personal Customer
-contactName
-creditRating
-creditLimit
-creditCard#
+remind()
+billForMonth(Integer)
*
Multiplicity:
optional
0..1
Employee
*
OrderLine
-quantity: Integer
-price: Money
-isSatisfied: Boolean
*
1
Product
Interaction Diagrams
 In object oriented systems, tasks are performed by objects
interacting with other by passing messages.
 In UML this interaction is provided by sequence diagrams.
 Class diagrams model static nature of system
 Interactions diagrams model the dynamic nature of system
and emphasis the order of the message over time
Cont . . .
 squares with object type, optionally preceded by object
name and colon
Purpose of interaction
diagrams
 These are used to model :
 high level interaction between active objects in system
 Interaction between objects involved in a use case
 Interaction between objects involved in an operation
 Generic interactions (showing all possible paths through
interaction)
Sequence Diagram
 Shows how objects communicate with each other over
time.
 That is, sequence diagrams are used to model object
interactions arranged in time sequence and to distribute
use case behavior to classes.
 They can also be used to illustrate all the paths a
particular use case can ultimately produce.
 The sequence diagram consists of Active Objects,
Messages represented as solid-line arrows, and Time
represented as a vertical progression.
Sequence Diagram - Objects
 A life line illustrates what is happening to an object in a
chronological fashion.
:Name
Object
Life line
Activation(focus of control)
Sequence Diagram – Time &
Messages
 Messages are used to illustrate communication between
different active objects of a sequence diagram.
:Name1
:Name2
Actor
Message One
Message Two
Types of Messages
 Synchronous (flow interrupt until the message has
completed.
 1st object waits until the 2nd object completes its operations
 Asynchronous (don’t wait for response)
 1st object does not wait for the 2nd object to
completes its operations
 Flat – no distinction between sysn/async
 Return – control flow has returned to the caller.
Steps in drawing a sequence
diagram
1.Decide the context of the interaction
 System, subsystem, use case or operation
2. Identify the structural elements(objects) necessary to carry
our functionality of use case
3. Consider alternative scenario that may be required
4. Draw the sequence diagram




Layout the objects from left to right
Starting with the message that starts the interaction
Add focus of control
Add timing constructs
Sequence Diagram – Compilation
Actor
:Compiler
Linker
Compile
FileSystem
Load Files
Compile files
Save OBJ Files
Link
Load OBJ files
Link OBJ files
Write EXE file
Example :making phone
call
Caller
Phone
Recipient
Picks up
Dial tone
Dial
Ring notification
Ring
Picks up
Hello
Task 1
 Draw a sequence diagram for:
 In Beauty and the Beast kitchen items came to life. Draw a
sequence diagram for making a peanut butter and jelly
sandwich if the following objects are alive: knife, peanut
butter jar (and peanut butter), jelly jar (and jelly), bread,
plate. I may or may not want the crusts cut off. Don’t
forget to open and close things like the jars, and put
yourself away, cleanup, etc…
Task 2
 Draw a sequence diagram
showing a customer’s
interaction to withdraw money from ATM .
 Show all sequence of steps involved e.g. insert card, enter
pin number , amount etc.
Activity diagrams
 Purpose of Activity diagrams is listed as under :
 Are a means of describing workflows
 Can be used as an analysis tool to describe business
flows in different level of detail
 Describe complex flows within or between use case
 At design level, it can be use to describe flow within an
operation.
Cont . . .
 Activity diagram consists of:
 Activities
 States
 transitions
Notations
 An activity is a unit of work that needs to be carried out
 symbol used to represent an activity
 Each activity
(sequencing).
can
be
followed
Activity name
by
another
activity
Triggering an activity
 There are four ways in which an activity can be triggered
 On Entry: these actions are triggered as soon as the activity
starts
 Do: these actions take place during the life time of the
activity
 On Event: these actions take place in response to an event
 On Exit: these actions takes place just before the activity
completes
Cont . . .
 Actions -> is triggering of an event
Activity name
Entry/ action
Do/action
Event name/action
Exit/action
States & Activities
 A state in an activity diagram is a point where some event
needs to take place before activity continues
 Activities & states are roughly equivalent and states can
carry out actions just as an activity can.
 However activities need to complete all their actions before
exiting normally.
 States are used to imply waiting, not doing
Wait for
payment
Cont . . .
 There are two special states:
 Start State: is the entry point to a flow
 Only one start state is allowed in an diagram
 Shows as a block dot and is labeled
 End State: are drawn as black dots with a surrounding circle
Transition
 Transition :
 Is the movement from one activity to another
 The change from one state to another
 The movement between states and an activity in either
direction.
 A transition normally occurs when all the actions of an
activity have been completed.
 Or when an event triggers the exit from a particular state or
activity.
 Are shown as arrowed lined between two activity
Request payment
Wait for
payment
Cont . . .
 There are two types of transitions:
 Trigger-less transitions: are permissible when exiting activities,
and meaning is that the activity has completed all its actions
and next phase of workflow can begin
 Triggered Transitions: when exiting a state, some event
needs to trigger it.
 E.g. when waiting for payment, exit from the state could be
triggered by a PaymentArrives event
Request payment
PaymentArrives
Wait for
payment
Cont . . .
 There can be more than one transition out of a single
activity or a state.
 This is used when different events results in a state or activity
termination
Wait for
payment
PaymentPeriodExpires
Chase payment
PaymentArrives (amount)
Process payment
Decision Points
 A decision points in a workflow where the exit transition from
a state or an activity may branch in alternative direction
 Depending on a condition
 Represented by a diamond.
Synchronisation bar
 Synchronisation bar.
 All triggers from this attach to activities that can occur in
parallel, with no specific sequence, or concurrently.
 Symbol
or
Example
Process payment
Cheque payment
Cash payment
Update cash balance
Process Cheque
Clear Debt
Activity Diagrams - Notation
Start at the top black circle
If condition 1 is TRUE, go right;
if condition 2 is TRUE, go
down
At
first
bar
(a
synchronization bar), break
apart to follow 2 parallel
paths
At second bar, come
together to proceed only
when both parallel activities
are done
Example
Example 2
Creating an activity
diagram
 Modelling a workflow in an activity diagram
 Identify a workflow objective.
 Decide the pre and post-conditions of the workflow.
 Define all activities and states.
 Define any objects that are created or modified.
 Decide on responsibility for performing the activities.
 Connect all elements on the diagram with transitions.
 Place decisions on the diagram.
 Evaluate your diagram for concurrent workflows.
 Set all actions, triggers and guard conditions in the
specifications of each model element.
Task
 Draw an activity diagram to issue book from library
Possible
solution