1 Department of Information Engineering What is UML (Unified Modeling Language)? • UML is a set of graphical notations used to model software system • A picture is worth a thousand words • Equivalent to blueprint used by construction engineers • Prior to 1995, many different modeling languages – Confusing, time to establish a common standard • Current version – UML version 2 (in year 2003) • You can use Visio to draw the diagrams • Ref: UML Distilled (3 rd Edition) – Martin Fowler
45
Embed
Department of Information Engineering 351 What is UML (Unified Modeling Language)? UML is a set of graphical notations used to model software system A.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1Department of Information Engineering
What is UML (Unified Modeling Language)?
• UML is a set of graphical notations used to model software system
• A picture is worth a thousand words
• Equivalent to blueprint used by construction engineers
• Prior to 1995, many different modeling languages
– Confusing, time to establish a common standard
• Current version – UML version 2 (in year 2003)
• You can use Visio to draw the diagrams
• Ref: UML Distilled (3rd Edition) – Martin Fowler
2Department of Information Engineering
Ways of using the UML
• Sketch
– For communicating a design
– Only highlight the essential components
• Blueprint
– Round-trip engineering
– Class has one-to-one mapping with code
– Class diagram -> code generation -> class diagram
• property-string– query: get value without changing the system state– abstract: abstract operation, implemented by subclass– Exception=XXX: name the exception returned
7Department of Information Engineering
Association
• Dependency– A depends on B– Change B’s interface may affect A
• Navigable association– A has a B– implicitly implies dependency
• Bidirectional association– A has a B, and B has an A
• Unidirectional association– A and B has relation– But direction is unspecified
A B
A B
A B
A B
8Department of Information Engineering
Dependency
• A depends (or use) on B
• But A does not has an instance of B as part of its state
• public class A {
public void foo(B b) {. . .} //OK
public void bar() {
B b = new B(); //OK
}
private B b; //not OK, has an instance of B
}
A B
9Department of Information Engineering
Association
• A stronger dependency– A depends (or use) on B– A has an instance of B as part of its state
• public class A { private B b; //OK
}
• Navigable association implicitly implies dependency
A B
10Department of Information Engineering
• Generalization
• Realization
– Provides the implementation
BaseClass
DerivedClass
AbstractClass
DerivedClass
11Department of Information Engineering
• Attributes and associations
– Both represents the same thing
– Choose the one that makes your diagram easier to understand
BookdueDate:Date[0..1]
Date is an attributeof Book
Book Date
Date is associatedwith Book
0..1
12Department of Information Engineering
Aggregation and Composition
• Aggregation– Part-of relationship– Shared by other objects, therefore the whole can be deleted,
but not the part– E.g. Car has Wheels
• Composition– Stronger type of aggregation– The part cannot be shared– Delete the whole, then the part must be deleted as well
• Hard to tell the difference between association and aggregation– Fowler suggests always to use association instead of
aggregation
Car Wheel
Rectangle Point
13Department of Information Engineering
Interface and Abstract Classes <<interface>>List
<<interface>>SortedList
AbstractArrayList
Clientdependency
generalization
implementation
Get
Sort
Stereotype
GetSort
Concrete methodAbstract method (italic)
ArrayList
GetSort
Overriding
14Department of Information Engineering
Ball-and-socket Notation (UML2)
• Previous example, alternative representation
• Qualified association
– To model concept like associative array, dictionary
List
SortedList
ArrayListClient
Claslist StudentInfo1 *
ClassList StudentInfoId 1 1
Qualified association
15Department of Information Engineering
Association Class
• To model the association between two classes. The two classes may have many-to-many association, but there can be only one instance of association class between objects of the two classes
• Example
Person Share Company1..* * 1..*1..*
Person Company
Sharequantity
1..* 1..*
Better, association classadd extra constraint
16Department of Information Engineering
Association Class
• OK
• Not allowed for association class
personA
personB
CompanyA
CompanyB
personA
personB
CompanyA
CompanyB
17Department of Information Engineering
• A person can take up several roles (director, investor) in a company, cannot be modeled by association class
• More appropriate
Person Company
Role
1..* 1..*
Person Role Company1..* 1..* 1..*1..*
18Department of Information Engineering
Constraints
• Free format, just put anything you like inside {} to describe constraints in your model
ClassList Student{ordered} *
Menu
Soup Salad MainCourse Dessert
{or}
19Department of Information Engineering
Template (Parameterized) Class
• class Set <class T> { public void Insert(T member) {...} public void Remove(T member) {...}}
Set
Insert(T)Remove(T)
T
Template parameter
20Department of Information Engineering
Package Diagrams
• Each package represents a namespace– Consists of a group of classes, larger
unit
• Example: System.IO
System.IO
21Department of Information Engineering
Package Diagram
• Avoid dependency cycle, at least localized it– Cycle in A, B, and C, but not in A, B and
D
Package A Package B
Package DPackage C
22Department of Information Engineering
Object Diagrams
• To show a snapshot of the objects– Object = instance name:class name
– Capture the behavior of a scenarioanObject:ClassName
Lifeline (dotted line)
Activation (rectangle)
Synchronous call
Asynchronous call(UML >= 1.4)
Asynchronous call(UML <= 1.3)
objnew Create object
return(optional)
30Department of Information Engineering
Check-out scenario: KnowFine()
aLibrarian aBorrower aCollection aBook :Date
CheckOut
KnowFine*[for all Book]
Compare
GetFine
IsOverdue
[overdue]
iterationiteration
guardguard
31Department of Information Engineering
Note
• iteration marker *[for all objects]• [condition]
– the message is sent only if the condition is true
• self-delegation– an message that an object sends to itself
• About loops and conditionals– Sequence diagram is not good at it, better
off with activity diagram or the code itself– UML2 uses a new notation call interaction
frames to support these functions
32Department of Information Engineering
Interaction Frame
• alt : alternative, executes only if condition is met
aLibrarian aBorrower aCollection aBook :Date
CheckOut
KnowFine
CompareIsOverdueloop [for each book]
[overdue]altGetFine
33Department of Information Engineering
Communication Diagrams
• Known as Collaboration Diagram in UML 1.x
• Contain the same info as the sequence diagram
• Sequence diagram is more common, communication diagram may good well with CRC cards
34Department of Information Engineering
Nested number system (legal UML)
aLibrarian
1:Checkout
aBorrower
1.1:
Che
ckou
t
aCollection
1.1.1:KnowFine
aBook
*[for all books]1.1.1.1:IsOverdue
1.1.1.1.1:IsOverdue:Date
1.1.
1.1.
1.1:
Com
pare
[overdue]1.1.1.1.2:GetF
ine
35Department of Information Engineering
Not official numbering system, but commonly used
aLibrarian
1:Checkout
aBorrower
2:C
heck
out
aCollection
3:KnowFine
aBook
*[for all books] 4:IsOverdue
5:IsOverdue:Date
6:C
ompa
re
[overdue] 7:GetF
ine
36Department of Information Engineering
Activity Diagrams
• Similar to flowcharts, but supports parallel behavior
initial stateinitial state
forkfork
statestate
joinjoin
decisiondecision
guardguard
final statefinal state
CheckFine CheckBorrowLimit
CheckOut Reject
[CanBorrow] [else]
37Department of Information Engineering
Swimlanes
• Each swimlane shows the activities within a class BorrowerBook
CheckFine CheckBorrowLimit
CheckOut Reject
[CanBorrow] [else]
38Department of Information Engineering
Signals
• Signal send– To send a message to an activity in
another process
• Signal receipt– Accepting an event message from another
process
ReserveBook
CallbackBorrower
statestatesignal sendsignal send
time signaltime signal Overdue
CallbackReceived
Email ToBorrower
signal receiptsignal receipt
39Department of Information Engineering
State Machine Diagrams
• Describe the states and lifetime of an object– State diagram of a Book
initial stateinitial state
BorrowedReturned
final statefinal state
On shelf
On loan
statestate
transitiontransition
40Department of Information Engineering
History state
• The remembered substate before last transition
• E.g. computer screen goes blank after time-out, back to original state at keystroke or mouse movement
H
Working
UpdateDisplay
ProcessInput
Wait forInput
H
Sleeping
time-outKeyboard ormouse movement
substatesubstate
41Department of Information Engineering
Interaction Overview Diagrams
• Mix sequence diagram with activity diagram
Check fine
Check borrow limit
:Book :Date :Borrower
IsOverdue
[overdue] GetFine
42Department of Information Engineering
Timing Diagrams
• Shows the timing of states change of one or more objects, like those use in electronic engineering
Course lecture Mid-term lecture
{>6 weeks} {>4 weeks}
43Department of Information Engineering
Use of UML
• Requirement and analysis
– Use cases
• Describe how users interact with the system
– Class diagram
• Build up vocabulary, show the conceptual model of the system
– Activity diagram
• Like flowchart, show the work flow of the system
– State diagram
• For objects that have complex life cycle
44Department of Information Engineering
Use of UML
• Design
– Class diagram
• Fuller and more detailed
– Sequence diagram
• To describe the most important scenarios form use cases
– Package diagram
• To show the large-scale organization of the system
– State diagram
– Deployment diagram
• To show the physical layout of the software
45Department of Information Engineering
Documentation
• Use your good sense– Don’t overuse UML, too many diagrams with too much
details make the documents difficult to understand
• Use diagrams to show the important architecture, e.g.– Package diagram – show road map of the system– Class diagram – within each package, provide more
detailed information, be selective– Deployment diagram – show physical layout– State diagram – only for complex object
• Detailed documentation can be generated from the code– JavaDoc for Java and Visual Studio for C#