nyc

1. IInnttrroodduuccttiioonn ttoo UUMMLL

2. OOvveerrvviieeww
 WWhhaatt iiss MMooddeelliinngg??
 WWhhaatt iiss UUMMLL??
 AA bbrriieeff hhiissttoorryy ooff UUMMLL
 UUnnddeerrssttaannddiinngg tthhee bbaassiiccss ooff UUMMLL
 UUMMLL ddiiaaggrraammss
 UUMMLL MMooddeelliinngg ttoooollss

3. MMooddeelliinngg
 DDeessccrriibbiinngg aa ssyysstteemm aatt aa hhiigghh lleevveell ooff
aabbssttrraaccttiioonn
 AA mmooddeell ooff tthhee ssyysstteemm
 UUsseedd ffoorr rreeqquuiirreemmeennttss aanndd ssppeecciiffiiccaattiioonnss
 IIss iitt nneecceessssaarryy ttoo mmooddeell ssooffttwwaarree
ssyysstteemmss??

4. OObbjjeecctt OOrriieenntteedd MMooddeelliinngg

5. WWhhaatt iiss UUMMLL??
 UUMMLL ssttaannddss ffoorr ““UUnniiffiieedd MMooddeelliinngg LLaanngguuaaggee””
 IItt iiss aa iinndduussttrryy--ssttaannddaarrdd ggrraapphhiiccaall llaanngguuaaggee ffoorr
ssppeecciiffyyiinngg,, vviissuuaalliizziinngg,, ccoonnssttrruuccttiinngg,, aanndd
ddooccuummeennttiinngg tthhee aarrttiiffaaccttss ooff ssooffttwwaarree ssyysstteemmss
 TThhee UUMMLL uusseess mmoossttllyy ggrraapphhiiccaall nnoottaattiioonnss ttoo
eexxpprreessss tthhee OOOO aannaallyyssiiss aanndd ddeessiiggnn ooff ssooffttwwaarree
pprroojjeeccttss..
 SSiimmpplliiffiieess tthhee ccoommpplleexx pprroocceessss ooff ssooffttwwaarree
ddeessiiggnn

6. WWhhyy UUMMLL ffoorr MMooddeelliinngg
 UUssee ggrraapphhiiccaall nnoottaattiioonn ttoo ccoommmmuunniiccaattee mmoorree
cclleeaarrllyy tthhaann nnaattuurraall llaanngguuaaggee ((iimmpprreecciissee)) aanndd
ccooddee((ttoooo ddeettaaiilleedd))..
 HHeellpp aaccqquuiirree aann oovveerraallll vviieeww ooff aa ssyysstteemm..
 UUMMLL iiss nnoott ddeeppeennddeenntt oonn aannyy oonnee llaanngguuaaggee oorr
tteecchhnnoollooggyy..
 UUMMLL mmoovveess uuss ffrroomm ffrraaggmmeennttaattiioonn ttoo
ssttaannddaarrddiizzaattiioonn..

7. HHiissttoorryy ooff UUMMLL

8. TTyyppeess ooff UUMMLL DDiiaaggrraammss
 UUssee CCaassee DDiiaaggrraamm
 CCllaassss DDiiaaggrraamm
 SSeeqquueennccee DDiiaaggrraamm
 CCoollllaabboorraattiioonn DDiiaaggrraamm
 SSttaattee DDiiaaggrraamm
TThhiiss iiss oonnllyy aa ssuubbsseett ooff ddiiaaggrraammss …… bbuutt aarree mmoosstt
wwiiddeellyy uusseedd

9. UUssee CCaassee DDiiaaggrraamm
 Used for describing a set of user
scenarios
 Mainly used for capturing user
requirements
 Work like a contract between end user
and software developers

10. Use Case Diagram (core components)
Actors: A role that a user plays with respect to the system,including
human users and other systems. e.g.,inanimate physical objects (e.g. robot);
an external system that needs some information from the current system.
Use case: A set of scenarios that describing an interaction between a user
and a system, including alternatives.
System boundary: rectangle diagram representing the boundary
between the actors and the system.

11. Use Case Diagram(core relationship)
Association: communication between an actor and
a use case; Represented by a solid line.
Generalization: relationship between one general
use case and a special use case (used for defining
special alternatives)
Represented by a line with a triangular arrow head
toward the parent use case.

12. Use Case Diagram(core relationship)
Include: a dotted line labeled <<include>> beginning at base
use case and ending with an arrows pointing to the include
use case. The include relationship occurs when a chunk of
behavior is similar across more than one use case. Use
“include” in stead of copying the description of that behavior.
<<include>>
Extend: a dotted line labeled <<extend>> with an arrow
toward the base case. The extending use case may add behavior to
the base use case. The base class declares “extension points”.
<<extend>>

13. UUssee CCaassee DDiiaaggrraammss
Library System
Borrow
Order Title
Fine Remittance
Boundary
Client
Employee
Supervisor
• A generalized description of how a system will be used.
• Provides an overview of the intended functionality of the system
Actor
Use Case

14. UUssee CCaassee DDiiaaggrraammss((ccoonntt..))
(TogetherSoft, Inc)

15. UUssee CCaassee DDiiaaggrraammss((ccoonntt..))
•Pay Bill is a parent use case and Bill Insurance is the
child use case. (generalization)
•Both Make Appointment and Request Medication
include Check Patient Record as a subtask.(include)
•The extension point is written inside the base case
Pay bill; the extending class Defer payment adds the
behavior of this extension point. (extend)

16. UML class diagrams
 What is a UML class diagram?
 UML class diagram: describes the structure of a
system by showing the system's classes, their
attributes, and the relationships among the classes.
 What are some things that are not
represented in a UML class diagram?
 details of how the classes interact with each other
 algorithmic details; how a particular behavior is
implemented

17. CCllaassss ddiiaaggrraamm
 UUsseedd ffoorr ddeessccrriibbiinngg ssttrruuccttuurree aanndd bbeehhaavviioorr
iinn tthhee uussee ccaasseess
 PPrroovviiddee aa ccoonncceeppttuuaall mmooddeell ooff tthhee ssyysstteemm
iinn tteerrmmss ooff eennttiittiieess aanndd tthheeiirr rreellaattiioonnsshhiippss
 UUsseedd ffoorr rreeqquuiirreemmeenntt ccaappttuurree,, eenndd--uusseerr
iinntteerraaccttiioonn
 DDeettaaiilleedd ccllaassss ddiiaaggrraammss aarree uusseedd ffoorr
ddeevveellooppeerrss

18. Construct Description Syntax
class a description of a set of objects
that share the same attributes,
operations, methods, relationships
and semantics.
interface a named set of operations that
characterize the behavior of an
element.
component a modular, replaceable and
significant part of a system that
packages implementation and
exposes a set of interfaces.
node a run-time physical object that
represents a computational
resource.
« i n t e r f a c e »
Symbols

19. Symbols
Construct Description Syntax
constraint¹ a semantic condition or restriction.
{ c o n s t r a i n t }
¹ An extension mechanism useful for specifying structural elements.

20. Symbols
Construct Description Syntax
association a relationship between two or more
classifiers that involves connections
among their instances.
aggregation A special form of association that
specifies a whole-part relationship
between the aggregate (whole) and
the component part.
generalization a taxonomic relationship between a
more general and a more specific
element.
dependency a relationship between two modeling
elements, in which a change to one
modeling element (the independent
element) will affect the other modeling
element (the dependent element).

21. Symbols
Construct Description Syntax
realization a relationship between a specification
and its implementation.

22. Classes
ClassName
attributes
operations
A class is a description of a set of
objects that share the same attributes,
operations, relationships, and semantics.
Graphically, a class is rendered as a
rectangle, usually including its name,
attributes, and operations in separate,
designated compartments.

23. Class Names
ClassName
attributes
operations
The name of the class is the only required
tag in the graphical representation of a
class. It always appears in the top-most
compartment.

24. Class Attributes
Person
name : String
address : Address
birthdate : Date
ssn : Id
An attribute is a named property of a
class that describes the object being modeled.
In the class diagram, attributes appear in
the second compartment just below the
name-compartment.

25. Class Attributes (Cont’d)
Person
name : String
address : Address
birthdate : Date
/ age : Date
ssn : Id
Attributes are usually listed in the form:
attributeName : Type
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

26. Class Attributes (Cont’d)
Person
+ name : String
# address : Address
# birthdate : Date
/ age : Date
- ssn : Id
Attributes can be:
+ public
# protected
- private
/ derived

27. Class Operations
Person
name : String
address : Address
birthdate : Date
ssn : Id
eat
sleep
work
play
Operations describe the class behavior
and appear in the third compartment.

28. Class Operations (Cont’d)
PhoneBook
newEntry (n : Name, a : Address, p : PhoneNumber, d : Description)
getPhone ( n : Name, a : Address) : PhoneNumber
You can specify an operation by stating its signature: listing the
name, type, and default value of all parameters, and, in the case of
functions, a return type.

29. Depicting Classes
When drawing a class, you needn’t show attributes and operation
in every diagram.
Person
name : String
birthdate : Date
ssn : Id
eat()
sleep()
work()
play()
Person
Person
name
address
birthdate
Person
Person
eat
play

30. Class Responsibilities
A class may also include its responsibilities in a class diagram.
A responsibility is a contract or obligation of a class to perform
a particular service.
SmokeAlarm
Responsibilities
-- sound alert and notify guard station
when smoke is detected.
-- indicate battery state

31. Relationships
In UML, object interconnections (logical or physical), are
modeled as relationships.
There are three kinds of relationships in UML:
• dependencies
• generalizations
• associations

32. Dependency Relationships
A dependency indicates a semantic relationship between two or
more elements. The dependency from CourseSchedule to
Course exists because Course is used in both the add and
remove operations of CourseSchedule.
CourseSchedule
add(c : Course)
remove(c : Course)
Course

33. Generalization Relationships
Person
A generalization connects a subclass
to its superclass. It denotes an
inheritance of attributes and behavior
from the superclass to the subclass and
indicates a specialization in the subclass
of the more general superclass.
Student

34. Generalization Relationships
(Cont’d)
UML permits a class to inherit from multiple superclasses,
although some programming languages (e.g., Java) do not permit
multiple inheritance.
Student
Employee
TeachingAssistant

35. Association Relationships
If two classes in a model need to communicate with each other,
there must be link between them.
An association denotes that link.
Student Instructor

36. Association Relationships
(Cont’d)
We can indicate the multiplicity of an association by adding
multiplicity adornments to the line denoting the association.
The example indicates that a Student has one or more
Instructors:
Student Instructor
1..*

37. Association Relationships
(Cont’d)
The example indicates that every Instructor has one or more
Students:
Student Instructor
1..*

38. Association Relationships
(Cont’d)
We can also indicate the behavior of an object in an association
(i.e., the role of an object) using rolenames.
teaches learns from
Student Instructor
1..* 1..*

39. Association Relationships
(Cont’d)
We can also name the association.
membership
Student Team
1..* 1..*

40. Association Relationships
(Cont’d)
We can specify dual associations.
member of
1..*
1..*
Student Team
1 president of 1..*

41. Association Relationships
(Cont’d)
We can constrain the association relationship by defining the
navigability of the association. Here, a Router object requests
services from a DNS object by sending messages to (invoking
the operations of) the server. The direction of the association
indicates that the server has no knowledge of the Router.
Router DomainNameServer

42. Association Relationships
(Cont’d)
Associations can also be objects themselves, called link classes
or an association classes.
Registration
modelNumber
serialNumber
warrentyCode
Product Warranty

43. Association Relationships
(Cont’d)
A class can have a self association.
next
LinkedListNode
previous

44. Association Relationships
(Cont’d)
We can model objects that contain other objects by way of
special associations called aggregations and compositions.
An aggregation specifies a whole-part relationship between
an aggregate (a whole) and a constituent part, where the part
can exist independently from the aggregate. Aggregations are
denoted by a hollow-diamond adornment on the association.
Car
Engine
Transmission

45. Association Relationships
(Cont’d)
A composition indicates a strong ownership and coincident
lifetime of parts by the whole (i.e., they live and die as a
whole). Compositions are denoted by a filled-diamond
adornment on the association.
Window
Scrollbar
Titlebar
Menu
1
1
1
1
1
1 .. *

46. Interfaces
An interface is a named set of
operations that specifies the behavior
of objects without showing their inner
structure. It can be rendered in the
model by a one- or two-compartment
rectangle, with the stereotype
<<interface>> above the interface
name.
<<interface>>
ControlPanel

47. Interface Services
Interfaces do not get instantiated.
They have no attributes or state.
Rather, they specify the services
offered by a related class.
<<interface>>
ControlPanel
getChoices : Choice[]
makeChoice (c : Choice)
getSelection : Selection

48. Interface Realization
Relationship
<<interface>>
ControlPanel
VendingMachine
A realization relationship
connects a class with an
interface that supplies its
behavioral specification. It is
rendered by a dashed line with
a hollow triangle towards the
specifier.
specifier
implementation

49. Parameterized Class
LinkedList
T
T
1 .. *
A parameterized class or
template defines a family of
potential elements.
To use it, the parameter must be
bound.
A template is rendered by a small
dashed rectangle superimposed on
the upper-right corner of the class
rectangle. The dashed rectangle
contains a list of formal parameters
for the class.

50. Parameterized Class (Cont’d)
LinkedList
T
T
1..*
Binding is done with the <<bind>>
stereotype and a parameter to
supply to the template. These are
adornments to the dashed arrow
denoting the realization
relationship.
Here we create a linked-list of
names for the Dean’s List.
<<bind>>(Name)
DeansList

51. Enumeration
<<enumeration>>
Boolean
false
true
An enumeration is a user-defined
data type that consists of a name and
an ordered list of enumeration
literals.

52. Exceptions
<<exception>>
Exception
getMessage()
printStackTrace()
<<exception>>
KeyException
Exceptions can be modeled
just like any other class.
Notice the <<exception>>
stereotype in the name
compartment.
<<exception>>
SQLException

53. Packages
Compiler
A package is a container-like element
for organizing other elements into
groups.
A package can contain classes and
other packages and diagrams.
Packages can be used to provide
controlled access between classes in
different packages.

54. Packages (Cont’d)
Classes in the FrontEnd package and classes in the BackEnd
package cannot access each other in this diagram.
Compiler
FrontEnd BackEnd

55. Packages (Cont’d)
Classes in the BackEnd package now have access to the classes
in the FrontEnd package.
Compiler
FrontEnd BackEnd

56. Packages (Cont’d)
JavaCompiler
We can model generalizations and
Compiler dependencies between packages.
Java

57. Case Study (Library
Management System)
 Problem Statement:
The case study titled Library Management System is library
management software for the purpose of monitoring and controlling
the transactions in a library. This case study on the library
management system gives us the complete information about the
library and the daily transactions done in a Library. We need to
maintain the record of new books and retrieve the details of books
available in the library which mainly focuses on basic operations in a
library like adding new member, new books, and up new information,
searching books and members and facility to borrow and return books.
It features a familiar and well thought-out, an attractive user interface,
combined with strong searching, insertion and reporting capabilities.
The report generation facility of library system helps to get a good
idea of which are the books borrowed by the members, makes users
possible to generate hard copy.

58. Case Study (Library
Management System)
The following are the brief description on the functions achieved through
this case study:
 End-Users:
•Librarian: To maintain and update the records and also to cater the needs of the
users.
•Reader: Need books to read and also places various requests to the librarian.
•Vendor: To provide and meet the requirement of the prescribed books.
Class Diagram
Classes identified:
Library
Librarian
Books Database
User
Vendor

59. Library Management System

60. UML Class Diagram Examples

61. CCllaassss DDiiaaggrraamm
Order
-dateReceived
-isPrepaid
-number :String
-price : Money
+dispatch()
+close()
Customer
-name
-address
+creditRating() : String()
Multiplicity: mandatory
* 1
{if Order.customer.creditRating is
"poor", then Order.isPrepaid must
Corporate Customer
-contactName
-creditRating
-creditLimit
+remind()
+billForMonth(Integer)
Personal Customer
-creditCard#
Constraint
(inside braces{}}
OrderLine
-quantity: Integer
-price: Money
-isSatisfied: Boolean
*
be true }
* 1 Product
1
* Employee
Name
Attributes
Operations
Association
Multiplicity:
Many value
Multiplicity:
optional
Generalization
class
0..1

62. Good PPrraaccttiiccee:: CCRRCC CCaarrdd
(Class Responsibility Collaborator)
Benefits: I t i s e a s y to describe how classes work by moving
cards around; allows to quickly consider alternatives.
Class
Reservations
Responsibility
• Keep list of reserved titles
• Handle reservation
Collaborators
• Catalog
• User session

63. SSeeqquueennccee DDiiaaggrraamm((mmaakkee aa pphhoonnee ccaallll))
Caller Phone Recipient
Picks up
Dial tone
Dial
Ring notification Ring
Picks up
Hello

64. D Sequence Diiaaggrraamm::OObbjjeecctt iinntteerraaccttiioonn
SSeellff--CCaallll: A message that an
Object sends to itself.
Condition: indicates when a
message is sent. The message is
sent only if the condition is true.
Condition
Iteration
A B
Synchronous
Asynchronous
Transmission
delayed
[condition] remove()
*[for each] remove()
Self-Call

65. SSeeqquueennccee DDiiaaggrraammss –– OObbjjeecctt LLiiffee SSppaannss
 CCrreeaattiioonn
 CCrreeaattee mmeessssaaggee
 OObbjjeecctt lliiffee ssttaarrttss aatt tthhaatt ppooiinntt
 AAccttiivvaattiioonn
 SSyymmbboolliizzeedd bbyy rreeccttaanngguullaarr
ssttrriippeess
 PPllaaccee oonn tthhee lliiffeelliinnee wwhheerree oobbjjeecctt
iiss aaccttiivvaatteedd..
 RReeccttaannggllee aallssoo ddeennootteess wwhheenn
oobbjjeecctt iiss ddeeaaccttiivvaatteedd..
 DDeelleettiioonn
Activation bar
 PPllaacciinngg aann ‘‘XX’’ oonn lliiffeelliinnee
 OObbjjeecctt’’ss lliiffee eennddss aatt tthhaatt ppooiinntt
A
B
Create
X
Deletion
Return
Lifeline

66. SSeeqquueennccee DDiiaaggrraamm
Message
User Catalog Reservations
1: look up ()
2: title data ()
3: [not available] reserve title ()
4 : title returned ()
5: hold title ()
5 : title available ()
6 : borrow title ()
6 : remove reservation ()
•Sequence diagrams demonstrate the behavior of objects in a use case
by describing the objects and the messages they pass.
•The horizontal dimension shows the objects participating in the interaction.
•The vertical arrangement of messages indicates their order.
•The labels may contain the seq. # to indicate concurrency.

67. Interaction Diagrams: Collaboration ddiiaaggrraammss
User
Catalog
Reservations
start
1: look up
2: title data
3 : [not available] reserve title
4 : title returned
5 : hold title
6 : borrow title
6: remove reservation
5: title available
•Shows the relationship between objects and the order of messages passed between them.
between them.
•The objects are listed as rectangles and arrows indicate the messages being passed
•The numbers next to the messages are called sequence numbers. They show the sequence
of the messages as they are passed between the objects.
•convey the same information as sequence diagrams, but focus on object roles instead of the
time sequence.

68. SSttaattee DDiiaaggrraammss
((BBiilllliinngg EExxaammppllee))
State Diagrams show the sequences of states an object goes
through during its life cycle in response to stimuli, together
with its responses and actions; an abstraction of all possible
behaviors.
Start End
Unpaid
Paid
Invoice created paying Invoice destroying

69. SSttaattee DDiiaaggrraammss
((TTrraaffffiicc lliigghhtt eexxaammppllee))
Traffic Light
Red
Yellow
Green
State
Transition
Event
Start