UML is a modeling language used to create visual models of object-oriented software systems. It was developed in the early 1990s to standardize the various object-oriented modeling notations in use at the time. UML uses different types of diagrams to represent different views of a system, including use case diagrams, class diagrams, sequence diagrams, and state machine diagrams. The language provides a standardized way to visualize the various components of an object-oriented system.

1. 1
 UML is a modelling language used for creating
models.
 Not a system design or development methodology.
 Used to document result of object-oriented analysis
and design.
 Independent of any specific design methodology
OBJECT MODELLING USING UML

2. OBJECT MODELLING USING UML
Provides set of notations(e.g. rectangles, lines
etc.) to create a visual model of the system.
UML has its own syntax and semantics.
2

3. 3
 Origin
 In late 1980s and early 1990s different
software development houses were using
different notations to document object
oriented designs.
 Developed in early 1990s to standardize the
large number of object-oriented modelling
notations
UNIFIED MODELLING LANGUAGE
(UML)

4. 4
UML was developed to standardize the large
number of object-oriented modeling notations
that existed and were used extensively in the
early 1990s.
Based Principally on
OMT [Rumbaugh 1991]
Booch’s methodology[Booch 1991]
OOSE [Jacobson 1992]
Odell’s methodology[Odell 1992]
Shlaer and Mellor [Shlaer 1992]
UML

5. 5
UML
UML
Booch
Methodology
OOSE
OMT
Different object modelling techniques in UML

6. 6
 As a Standard
Adopted by Object Management Group
(OMG) in 1997
OMG an association of industries
Promote extensive set of notations and
techniques
Used outside software development,
example car manufacturing
UML

7. 7
 Required to capture only important aspects
 UML a graphical modelling tool, easy to
understand and construct
 Helps in managing complexity
WHY UML IS REQUIRED?

8. 8
 Construct Nine diagrams to capture five
different views of a system
 Provide different perspectives of the
software system
 Diagrams can be refined to get the actual
implementation of the system
UML DIAGRAMS

9. 9
 Five Views of a system
 User’s view
 Structural view
 Behavioral view
 Implementation view
 Environmental view
UML DIAGRAMS

10. 10
UML DIAGRAMS
User’s View
-Use Case
Diagram
Structural View
- Class Diagram
- Object Diagram
Implementation View
- Component Diagram
Environmental View
- Deployment Diagram
Behavioural View
- Sequence Diagram
- Collaboration Diagram
- State-chart Diagram
- Activity Diagram
Diagrams and views in UML

11. USER’S VIEW
 Defines the functionalities (facilities) made available
by the system to its users.
 Black-box view of the system
- where the internal structure, the dynamic behaviour of
different system components, the implementation etc.
are not visible.
 Considered as the central view and all other views are
expected to conform to this view.
11

12. STRUCTURAL VIEW
 Defines the kinds of objects important to the
understanding of the working of a system and
to its implementation.
 Captures the relationships among the objects.
 Called the static model, since the structure of a
system does not change with time.
12

13. BEHAVIORAL VIEW
 Captures how objects interact with each other
to realize the system behavior.
 Captures the time-dependent (dynamic)
behavior of the system.
13

14. IMPLEMENTATION VIEW
 Captures the important components of the
system and their dependencies.
14

15. ENVIRONMENTAL VIEW
 Models how the different components are
implemented on different pieces of hardware.
15

16. 16
NO
 Use case model, class diagram and one of
the interaction diagram for a simple
system
 State chart diagram in case of many state
changes
 Deployment diagram in case of large
number of hardware components
ARE ALL VIEWS REQUIRED?

17. 17
USE CASE MODEL
 Consists of set of “use cases”
 An important analysis and design artifact
 Other models must confirm to this model
 Not really an object-oriented model
 Represents a functional or process model

18. 18
USE CASES
 Different ways in which system can be used by
the users
 Corresponds to the high-level requirements
 Represents transaction between the user and the
system
 Define behavior without revealing internal
structure of system
 Set of related scenarios tied together by a
common goal

19. 19
USE CASES
 Use cases are independent of each other
 Implicit dependencies may exist

20. 20
EXAMPLE OF USE CASES
 For library information system
 issue-book
 Query-book
 Return-book
 Create-member
 Add-book, etc.

21. 21
REPRESENTATION OF USE CASES
 Represented by use case diagram
 Use case is represented by ellipse
 System boundary is represented by
rectangle
 Users are represented by stick person icon
(actor)
 Communication relationship between
actor and use case by line
 External system by stereotype

22. 22
EXAMPLE OF USE CASES
TIC-TAC-TOE
Use case model
Tic-tac-toe game
Play Move
Player

23. 23
WHY DEVELOP USE CASE
DIAGRAM?
 Serves as requirements specification
 Users identification helps in implementing
security mechanism through login system
 Another use in preparing the documents
(e.g. user’s manual)

24. 24
FACTORING USE CASES
 Complex use cases need to be factored
into simpler use cases
 Represent common behavior across
different use cases
 Three ways of factoring
Generalization
Includes
Extends

25. GENERALIZATION
Generalization works the same way with use
cases as it does with classes.
The child use case inherits the behavior and
meaning of the parent use case.
The base and the derived use cases are
separate use cases and should have separate
text descriptions. 25

26. 26
FACTORING USING
GENERALIZATION
Pay membership fee
Pay through library pay card
Pay through credit card
Use case generalization

27. INCLUDES
Involves one use case including the behavior of
another use case in its sequence of events and
actions.
The includes relationship occurs when a chunk of
behavior that is similar across a number of use cases.
As shown in fig., the includes relationship is
represented using a predefined stereotype
<<include>>. 27

28. 28
FACTORING USING INCLUDES
Base use case
Use case inclusion
Common
use case
<<include>>
Issue Book
Update
selected
book
Get user
selection
Check for
reservation
Renew Book
<<include>>
<<include>>
<<include>>
<<include>>
Paralleling model

29. EXTENDS
It allows you to show optional system behavior.
This relationship among use cases is also predefined
as a stereotype <<extends>> as shown in fig..
Similar to generalization but the extending use case
can add additional behavior only at an extension
point only when certain conditions are satisfied.
The extends relationship is normally used to capture
alternate paths or scenarios.
29

30. 30
FACTORING USING EXTENDS
Base
use case
Use case extension
Common
use case
<<extends>>

31. ORGANIZATION OF USE CASES
 When the use cases are factored, they are
organized hierarchically.
 The high-level use cases are refined into a set
of smaller and more refined use cases as
shown in fig.
 Top-level use cases are super-ordinate to the
refined use cases. 31

32. ORGANIZATION OF USE CASES
 The refined use cases are sub-ordinate to the
top-level use cases.
 Only the complex use cases should be
decomposed and organized in a hierarchy.
 This level is also referred to as the context
diagram.
32

33. 33
HIERARCHICAL ORGANIZATION
OF USE CASES
Hierarchical organization of use cases
External users
use case 1
use case 2
use case 3
use case 3.1
use case 3. 2
use case 3.3
use case 1
use case 2
use case 3
Subsystems
Method

34. 34
CLASS DIAGRAM
 Describes static structure of a system.
 Shows how a system is structured rather
than how it behaves.
 Main constituents are classes and their
relationships:
 Generalization
 Aggregation
 Association
 Various kinds of dependencies

35. 35
CLASS
Entities with common features, i.e. attributes and
operations
Classes are represented as solid outline rectangle with
compartments
Classes have a mandatory name compartment where
the name is written centered in boldface.

36. CLASS
The class name is usually written using mixed
case convention and begins with an uppercase.
The class names are usually chosen to be singular
nouns.
Attribute and operation compartment are optional
for reuse purpose
36

37. ATTRIBUTES
 An attribute is a property of a class.
 Represents kind of data that an object might contain.
 Type of the attribute is written by appending a colon
and the type name after the attribute name.
 First letter of a attribute is a small letter.
 Example :
bookName : String
37

38. OPERATION
 Implementation of a service that can be requested
from any object.
 An object’s data or state can be changed by invoking
an operation of the object.
 A class may have any number of operations or no
operation at all.
 First letter of an operation name is a small letter.
 Abstract operations are written in italics.
38

39. OPERATION
 The parameters of an operation may be
- ‘in’, ‘out’ or ‘inout’.
 Example:
issueBook(in bookName):Boolean
39

40. 40
EXAMPLE OF CLASS DIAGRAM
Different representations of the LibraryMember class
LibraryMember
Member Name
Membership Number
Address
Phone Number
E-Mail Address
Membership Admission Date
Membership Expiry Date
Books Issued
issueBook( );
findPendingBooks( );
findOverdueBooks( );
returnBook( );
findMembershipDetails( );
LibraryMember
Member Name
Membership Number
Address
Phone Number
E-Mail Address
Membership Admission Date
Membership Expiry Date
Books Issued
LibraryMember

41. 41
ASSOCIATION RELATIONSHIP
 Enable objects to communicate with each
other
 Describes a connection between classes.
 The association relation between two
objects is called object connection or
link.
 Usually binary relation but more classes
can be involved

42. ASSOCIATION RELATIONSHIP
 Class can have relationship with itself (recursive
association)
 Association between two classes is represented by
drawing a straight line
 The name of the association is written along side
the association line.
 Arrowhead used along with name indicates
reading direction of association
 Multiplicity indicates how many instances of one
class are associated with each other.
42

43. 43
ASSOCIATION RELATIONSHIP
Association between two classes
Library Member Book
1 *
borrowed by

44. 44
AGGREGATION RELATIONSHIP
 Involved classes are not only associated to
each other but also represent a whole-part
relationship
 Example: a book register is an aggregation
of book object.
 Represented by diamond symbol at the
composite end

45. AGGREGATION RELATIONSHIP
 Cannot be reflexive(i.e. recursive)
- an object cannot contain objects of the same
class as itself.
 Not symmetric
- Two classes A and B cannot contain instances of
each other.
 It can be transitive
- Consist of an arbitrary number of levels.
45

46. 46
AGGREGATION RELATIONSHIP
Representation of aggregation
Document Line
1 *
Paragraph
1 *

47. COMPOSITIONRELATIONSHIP
 Composition is a stricter form of aggregation.
 Parts are existence-dependent on the whole.
 When the whole is created, the parts are created and
when the whole is destroyed, the parts are destroyed.
 Represented as a filled diamond drawn at the
composite-end.
47

48. 48
COMPOSITION RELATIONSHIP
Representation of composition
Order
1 *
Item

49. INHERITANCE RELATIONSHIP
 Inheritance describes ‘is a’ / ‘is a kind of’
relationship between classes .
 Inheritance is defined statically.
 It can not be changed at run-time.
49

50. 50
INHERITANCE RELATIONSHIP

51. OBJECT DIAGRAM
 Shows the snapshot of the objects in a system.
 Shows instances of classes rather than classes
themselves, often called instance diagram.
 Undergo continuous change as execution
proceeds.
 Useful to explain the working of a system.
51

52. 52
OBJECT DIAGRAM
Different representations of the LibraryMember object
LibraryMember
Mritunjay
B10028
C-108, Laksmikant Hall
1119
Mrituj@cse
25-02-04
25-03-06
NIL
IssueBook( );
findPendingBooks( );
findOverdueBooks( );
returnBook( );
findMembershipDetails( );
LibraryMember
Mritunjay
B10028
C-108, Laksmikant Hall
1119
Mrituj@cse
25-02-04
25-03-06
NIL
LibraryMember

53. 53
INTERACTION DIAGRAM
 Models that describes how groups of
objects interact among themselves.
 Each interaction diagram realizes
behaviour of a single use case

54. 54
INTERACTION DIAGRAM
 Two kinds: Sequence & Collaboration
 Two diagrams are equivalent in the sense that
any one diagram can be derived automatically
from the other but portrays different perspective
 These diagram play a very important role in the
design process

55. 55
SEQUENCE DIAGRAM
 Shows interaction among objects as two-
dimensional chart
 The chart is read from top to bottom.
 Objects are shown as boxes at top of chart.
 Inside the box the name of the object is written
with a colon separating it from the name of the
class.

56. SEQUENCE DIAGRAM
 Both the name of the object and the class
are underlined
 The objects appearing at the top signify
object already existed when the use case
execution was initiated.
 If object created during execution then
shown at appropriate place.
56

57. SEQUENCE DIAGRAM
 Objects existence are shown as dashed
lines (object’s lifeline)
 Objects activeness, shown as rectangle
on lifeline called activation symbol.
 Messages are shown on arrows
57

58. 58
SEQUENCE DIAGRAM
 Message labelled with message name
 Message can be labelled with control
information
 Two types of control information:
condition ([]) & an iteration (*)

59. EXAMPLE OF SEQUENCE
DIAGRAM
The sequence diagram for the book renewal
use case for the Library Automation Software
is shown in fig.
59

60. 60
EXAMPLE OF SEQUENCE
DIAGRAM
:Library
Boundary
:Library
Book
Renewal
Controller
:Library
Book
Register
:Book
:Library
Member
renewBook
displayBorrowing
selectBooks
[reserved]
apology
confirm
find MemberBorrowing
bookSelected
* find
update
[reserved]
apology
confirm
updateMemberBorrowing
Sequence Diagram for the renew book use case

61. 61
COLLABORATION DIAGRAM
Shows both structural and behavioural aspects
The structural aspect consists of objects and
the links existing between them.
Objects are collaborator, shown as boxes
The behavioral aspect is described by the set
of messages exchanged among the different
collaborators

62. COLLABORATION DIAGRAM
 Link between objects shown as a solid line.
 Message is shown as a labelled arrow
placed near the link
 Messages are prefixed with sequence
numbers to show relative sequencing
62

63. 63
EXAMPLE OF
COLLABORATION DIAGRAM
:Library
Boundary
:Library
Book
Renewal
Controller
:Library
Book
Register
:Book
:Library
Member
1: renewBook
3: display
Borrowing
4: selectBooks
[reserved]
8: apology
12: confirm
2: findMemberBorrowing
5: book
Selected
6: * find
9: update
[reserved]
7: apology
10: confirm
updateMemberBorrowing
Collaboration Diagram for the renew book use case

64. 64
ACTIVITY DIAGRAM
 New concept, possibly based on event
diagram of Odell [1992]
 Represent processing activity, may not
correspond to methods of classes
 Activity is a state with an internal action
and one/many outgoing transition

65. 65
ACTIVITY DIAGRAM
 Normally employed in business process modelling
 Carried out during requirement analysis and
specification
 Can be used to develop interaction diagrams

66. 66
ACTIVITY DIAGRAM
 Can represent parallel activity and
synchronization aspects
 Important feature of activity diagram
- Swim lanes
- enable to group activities based on who
is performing them
 Example: academic department vs. hostel

67. EXAMPLE OF ACTIVITY
DIAGRAM
The student admission process in IIT is shown as an
activity diagram. This shows the part played by
different components of the Institute in the admission
procedure. After the fees are received at the account
section, parallel activities start at the hostel office,
hospital, and the Department. After all these
activities complete (this synchronization is
represented as a horizontal line), the identity card can
be issued to a student by the Academic section.
67

68. 68
EXAMPLE OF ACTIVITY
DIAGRAM
check
student
records
Academic Section
receive
fees
allot
room
receive
fees
allot
hostel
create
hospital
record
conduct
medical
examination
register
in
course
Accounts Section Hostel Office Hospital Department
issue
identity card
Activity diagram for student admission procedure at IIT

69. 69
STATE CHART DIAGRAM
 Based on the work of David Harel [1990]
 Model how the state of an object changes in its
lifetime
 Describe how the behavior of the object changes
across several use case execution.
 Based on finite state machine (FSM) formalism

70. 70
WHY STATE CHART DIAGRAM
 State chart avoids problem of state explosion as
in FSM
 State explosion
- The number of states becomes too many and
the model too complex.
 Hierarchical model of a system and represents
composite state (nested)

71. 71
STATE CHART DIAGRAM
Elements of state chart diagram
 Initial State: Filled circle
 Final State: Filled circle inside larger circle
 State: Rectangle with rounded corners
 Transitions: Arrow between states, also
boolean logic condition (guard).
The syntax for the label of the transition is:
event[guard]/action.

72. EXAMPLE OF STATE CHART
DIAGRAM
An example of state chart for the order
object of the Trade House Automation
software is shown in fig.
72

73. 73
EXAMPLE OF STATE CHART
DIAGRAM
Unprocessed
Order
Fulfilled
Order
Pending
Order
Accepted
Order
Rejected
Order
order received
[reject] checked [accept] checked
[some items not
available] processed
[all items
available]
newsupply
[some items available]
processed / deliver
Example: State chart diagram for an order object

74. COMPONENT DIAGRAM
 Piece of a software that can be
independently purchased, upgraded and
integrated into existing software.
 Represent the physical structure of
implementation
74

75. COMPONENT DIAGRAM
Used for two purposes:
 Organizing source code
 Specify dependencies among different
components.
75

76. DEPLOYMENT DIAGRAM
 Shows the environmental view of the system.
 Shows how the software system will be
physically deployed in the hardware
environment.
 Diagram models the run time architecture of
an application.
76