Software Design and Construction 1 SOFT2201 / COMP9201
UML Modeling
Dr. Xi Wu
School of Computer Science
The University of Sydney
Page 1
Copyright warning
COMMONWEALTH OF AUSTRALIA Copyright Regulations 1969 WARNING
This material has been reproduced and communicated to you by or on behalf of the University of Sydney
pursuant to Part VB of the Copyright Act 1968 (the Act).
The material in this communication may be subject to copyright under the Act. Any further copying or communication of this material by you may be the subject of copyright protection under
the Act.
Do not remove this notice.
The University of Sydney Page 2
Agenda
– UML Modeling
– UML Use Case Diagrams – UML Class Diagrams
– UML Interaction Diagrams
– Case Study: Next Gen Point-of-Sale (POS) System – Brief Introduction
– Self learning details
The University of Sydney
Page 3
Software Modelling
• The process of developing conceptual models of a system at different
levels of abstraction
• Fulfilthedefinedsystemrequirements
• Focusonimportantsystemdetailstodealwithcomplexity
• Using graphical notations (e.g., UML) to capture different views or
perspectives
• TherearethreewaystoapplyUML
• Blueprint:detaileddesigndiagramsfor:
The University of Sydney
Page 4
• Reverseengineeringtovisualizeandunderstandexistingcode • Forwardengineering(codegeneration)
UML Diagrams
Structural (static) View
• Static structure of the system (objects, attributes, operations and relationships)
Behavioural (dynamic) View
• Dynamic behavior of the system (collaboration among objects, and changes to the internal states of objects)
• Interaction (subset of dynamic view) – emphasizes flow of control and data
https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/UML
The University of Sydney
Page 5
Use Case Diagrams
1. Why we need Use Case Diagrams?
2. What is Use Case?
3. How can we draw Use Case Diagrams?
Craig Larman. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of Sydney
Page 6
Rational Unified Process (UP)
• Software development process utilizing iterative and risk-driven approach to develop OO software systems
• Iterative incremental development
• Iterative evolutionary development
The University of Sydney
Page 7
Business Modelling, Requirements and Designs in RUP/UP*
Use Cases and Use Case Diagrams
*RUP/UP: Rational Unified Process, Lecture 1 pp. 59–64
The University of Sydney
Business Modeling
Sample UP Artifact Relationships Domain Model
Sale 1 1..* Sales . . . LineItem
date …
. . .
quantity
objects, attributes, associations
Use-Case Model
scope, goals, actors, features
terms, attributes, validation
Vision
Glossary
Cashier
Process use Sale case
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
3. …
Use Case Text
system events
: System
names
Require- ments
Use Case Diagram
Operation: enterItem(…)
Post-conditions: – . . .
system operations
Supplementary Specification
: Cashier
make NewSale()
enterItem (id, quantity)
non-functional reqs, quality attributes
: ProductCatalog
Operation Contracts
System Sequence Diagrams
Design Model
requirements
: Register
: Sale
Design
enterItem (itemID, quantity)
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
Page 8
Use Cases
•
Use case: “specifies a set of behaviors performed by a system, which yields an
observable result that is of value for Actors or other stakeholders of the system”*
• It capture what a system supposed to do (system’s requirements)
• Text documents not diagrams
• Primary part of the use case model
Scenario (use case instance): specific sequence of action and interactions
between actors and the system
• One particular story of using a system (e.g., successfully purchasing items with cash)
Use case model: set of all written use cases (a model of the system functionality and environment)
• Defined within the Requirements discipline in the UP
• Not the only requirement artefact – business rules, supplementary specifications, etc
• •
* OMG Unified Modeling Language, version 2.5.1, Dec. 2017 https://www.omg.org/spec/UML/2.5.1
The University of Sydney Page 9
Use Cases – Common Formats
• Brief: one-paragraph summary, usually of the main success scenario
• During early requirements analysis to get quick subject and scope
• Casual: Informal paragraph format; multiple paragraphs that cover various scenarios
• During early requirements analysis to get quick subject and scope
• Full-dressed: all steps and variations are written in detail and there are
supporting sections; e.g., pre-conditions, success guarantee
• After many use cases have been identified and written in brief format
* OMG Unified Modeling Language, version 2.5.1, Dec. 2017 https://www.omg.org/spec/UML/2.5.1 The University of Sydney
Page 10
Use Cases – Full-dressed Template
Use case section
Comment
Use case name
Start with a verb
Scope
The system under design
Level
“user-goal” or sub-function
Primary actor
Calls on the system to deliver its services
Stakeholders and interests
Who cares about this UC and what do they earnt
Preconditions
What must be true on start
Success guarantee
What must be true on successful completion
Main success scenario
Typical unconditional happy path scenario
Extensions
Alternate scenarios of success or failure
Special requirements
Related non-functional requirement
…..
The University of Sydney Page 11
Use Case Diagrams
• UML graphical notations that help to capture use cases (system’s boundaries
and interactions and relationships)
• Subject: system under consideration to which the use case applies
• Actor: role that interact with the subject/system (e.g., end user, customer, supplier,
another system)
• Use case: describes functionality of the system
• Association: relationship between an actor and a use case (an actor can use certain
functionality of the system)
• «include» indicates the behavior of the included use case is included in the
behavior of the including use case
* OMG Unified Modeling Language, version 2.5.1, Dec. 2017 https://www.omg.org/spec/UML/2.5.1
The University of Sydney Page 12
Use Case Diagram – UML Notations
For a use case context diagram, limit the use cases to user-goal level use cases.
Show computer system actors with an alternate notation to human actors.
Cashier
primary actors on the left
NextGen
Process Sale
…
«actor» Payment Authorization Service
NextGen Process Sale
…
supporting actors on the right
«system» Payment Authorization Service
Payment Authorization Service
«actor» Payment Authorization Service
Some UML alternatives to illustrate external actors that are other computer systems.
The class box style can be used for any actor, computer or human. Using it for computer actors provides visual distinction.
Page 13
The University of Sydney
Use Case Diagrams – Tools
• There are many tools to aid drawing UML diagrams
• Tools are means to make your life easier
• You can also sketch diagrams using pen-and-paper or white board
https://www.lucidchart.com/pages/examples/uml_diagram_tool
The University of Sydney
Page 14
Class Diagrams
Structural Diagrams
Craig Larman. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of Sydney Page 15
Class Diagram – Notations
• Common compartments: classifier
name, attributes and operations • Package name
• <
• Class hierarchy – inheritance
• Dependency
• Association and multiplicity
• Optional and default elements
The University of Sydney
Page 16
Class Diagram – Perspectives
• Conceptual: describes key concepts in the problem
domain. Use in business modeling for OO analysis
• Specification: describes software components with specification and interfaces
• Implementation: describes software implementation in a particular programming language (e.g., Java)
The University of Sydney
1
Includes 2
Conceptual Perspective (domain model)
Raw UML class diagram notation used to visualize real-world concepts.
Specification or Implementation Perspective (design class diagram)
Raw UML class diagram notation used to visualize software elements.
DiceGame
Die
faceValue
DiceGame
die1 : Die die2 : Die
2
faceValue : int
Die
getFaceValue() : int roll()
play()
Page 17
Class Diagrams – UML Attributes
Attribute Text
Visibility : type {property string}
Visibility + (public), – (private) Attributes are assumed private if no visibility sign shown
Attribute-as-association
Arrow pointing from the source to the 1
Sale
…
…
Register
currentSale : Sale
…
using the attribute text notation to indicate Register has a reference to one Sale instance
target
Multiplicity and ‘rolename’ (currentSale) at the target
No association name
Attribute text and as-association
• Not popular
The University of Sydney
currentSale
OBSERVE: this style visually emphasizes the connection between these classes
Sale
…
thorough and unambiguous, but some people dislike the possible redundancy
…
…
Register
1 currentSale
…
using the association notation to indicate Register has a reference to one Sale instance
Register
currentSale : Sale
…
Sale
…
…
Page 18
Class Diagrams – Attribute Examples
Math
+ pi : Real = 3.14 {readOnly}
Person
firstName middleName : [0..1] lastName
Sale
– dateTime : Date – / total : Money
The University of Sydney
Page 19
Private visibility attributes
Public visibility readonly attribute with initialization
Read-only Attributes with initialization, and optional values
Optional value
Class Diagrams – Operations
•
• •
Visibility Name (parameter-list) : return-type {property-string} (UML 1) Visibility Name (parameter-list) {property-string} (UML 2)
Not a method, but declaration with a name, parameters, return type, exception list, and possibly a set of constraints of pre-and post-conditions
Operations are public by default, if no visibility shown Operation signature in a programming language is allowed, e.g.,
+ getPlayer (name : String) : Player {exception IOException} Public Player getPlayer(String name) throws IOException
The University of Sydney
Page 20
Class Diagrams – Methods
•
Implementation of an operation, can be specified in:
• Class diagrams using UML note symbol with stereotype symbol «method»
• Mixing static view (class diagram) and dynamic view (method implementation)
• Good for code generation (forward engineering)
• Interaction diagrams by the details and sequence of messages
Register
…
endSale()
enterItem(id, qty) makeNewSale() makePayment(cashT endered)
«method»
// pseudo-code or a specific language is OK public void enterItem( id, qty )
{
ProductDescription desc = catalog.getProductDescription(id);
sale.makeLineItem(desc, qty); }
The University of Sydney Page 21
UML Keywords
• Textual adornment to categorize a model element • Using«»or{}
• UML 2 the brackets («») are used for keywords and stereotype
Keyword
Meaning
Example usage
«interface»
Classifier is an interface
In class diagram, above classifier name
{abstract}
Abstract element; can’t be instantiated
In class diagrams, after classifier name or operation name
{ordered}
A set of objects have some imposed ordered
In class diagrams, at an association end
The University of Sydney Page 22
UML Stereotypes
• Stereotypes allow refinement (extension) of an existing modeling concept • Defined in UML Profile
• UMLprofile:groupofrelatedmodelelementsallowcustomizingUMLmodels for a specific domain or platform
• Extends UML’s «metaclass» Element
•
UML note symbol
declaring the stereotype
using the stereotype
a tool will probably allow a popup to fill in the tag values, once an element has been stereotyped with «authorship»
• Has no semantic impact Specify a constraint
UML extension relationship to a basic UML metamodel term œ Element
«stereotype» Authorship
author: String status : String
«metaclass» Element
…
«authorship» Square
…
«authorship» author = —craig“ status = —tested“
Page 23
The University of Sydney
Constraints
• Restriction/condition on a UML elements described in a natural or a formal language (Object Constraint Language (OCL))
• Different ways to represent constraints
The University of Sydney Page 24
Generalization, Abstract Classes & Operations
“Generalization – a taxonomic relationship between a more general classifier and a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Thus, specific classifiers indirectly has features of the more general classifiers.” [OMG2003]
• Generalization implies inheritance in design class diagram (software perspective) but not in the domain model (conceptual perspective)
• Classes and operations with {abstract} tag are abstract
• Classesandoperationswith{leaf}arefinal(cannotbeoverriddeninthesub-classes)
The University of Sydney
Page 25
Composition
•
Composition, or composite aggregation, relationship implies:
• Instance of the part (e.g., Square) belongs to only one composite instance at a time
(e.g., one board)
• The part must always belong to a composite
• The composite is responsible for the creation and deletion of its parts (by itself or
by collaborating with other objects)
The University of Sydney Page 26
Associations
• Relationship between classifiers where logical or physical link exists among classifier’s instances
• May implemented differently; no certain construct linked with association
-“reading direction arrow”
-it has no meaning except to indicate direction of
reading the association label -often excluded
Register
• Notations:
• Association name (meaningful) • Multiplicity
• Direction arrow
The University of Sydney
Records-current 4
Sale
1
association name
0..1
multiplicity
Page 27
Associations – Multiplicity
• Multiplicity: number of instances involved in the relationship (association)
• Communicates domain constraints that will be implemented
• Multiplicity focus on the relationship at a
particular moment, rather than over a
span of time
• “In countries with monogamy laws, a person can be Married-to only one other person at any particular moment, even though over a span of time, that same person may be married to many persons.”
The University of Sydney
Page 28
Multipl icity
Meaning (number of participating instances)
*
Zero or more; many
0..1
Zero or one
1..*
One or more
1..n
One to n
n
Exactly n
n, m, k
Exactly n, m or k
Association Class
• Modeling an association as a class (with attributes, operations & other features)
• A Company Employs many Persons
• Employs à Employment class with attributes salary and startDate Company * Employs * Person
Employment
salary startDate
The University of Sydney
Page 29
a person may have employment with several companies
Dependency
• •
A dependency exists between two elements if changes to the definition of one element (the supplier) may cause changes to the other (the client)
Various reason for dependency
• Class send message to another
• One class has another as its data
• One class mention another as a parameter to an operation
• One class is a superclass or interface of another
The University of Sydney
Page 30
When to show dependency?
• Be selective in describing dependency
• Many dependencies are already shown in other format
• To depict global, parameter variable, local variable and static-method
• To show how changes in one element might alter other elements
• There are many varieties of dependency, use keywords to differentiate them
• Different tools have different sets of supported dependency keywords:
<
<
Dependency Example
the doX method invokes the runFinalization static method, and thus has a dependency on the System class
System
…
runFinalization()
…
Foo
…
doX() …
The University of Sydney Page 32
UML Interaction Diagrams
Dynamic (Behavioural) Diagrams
Craig Larman. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of Sydney
Page 33
UML Interaction Diagrams
• One of the dynamic (behavioral) diagrams which consists of diagrams including Sequence and Communication diagram
Sequence diagrams: illustrate sequence/time- ordering of messages in a fence format (each object is added to the right)
Communication diagrams: objects’ interactions are illustrated in a graph/network format
:A
doOne
:A
myB : B
doOne
1: doTwo 2: doThree
doTwo doThree
The University of Sydney
Page 34
myB : B
Sequence Diagrams: Classes/Objects
•
Participants in interactions (class instances, lifeline boxes)
lifeline box representing an unnamed instance of class Sale
:Sale
lifeline box representing a named instance
s1 : Sale
lifeline box representing the class Font, or more precisely, that Font is an instance of class Class œan instance of a metaclass
«metaclass» Font
List is an interface
in UML 1.x we could not use an
interface here, but in UML 2, this (or an abstract class) is legal
x : List
Actual lifeline of a participating object (solid or dashed)
lifeline box representing an instance of an ArrayList class, parameterized (templatized) to hold Sale objects
lifeline box representing one instance of class Sale, selected from the sales ArrayList
sales[ i ] : Sale
sales: ArrayList
The University of Sydney
related example
Page 35
Sequence Diagrams: Messages
• Standard message syntax in UML
ReturnVar = message (parameter : parameterType) : returnType
• Some details may be excluded. Examples:
Initialize(code)
descrp = getProductDescription(id)
descrp = getProductDescription(id) : ProductDescription
• The time ordering from top to bottom of lifelines
The University of Sydney
: Register
doX
: Sale
doA doB doC
doD
a found message whose sender will not be specified
execution specification
bar indicates focus of control
typical sychronous message shown with a filled-arrow line
Page 36
Sequence Diagrams: Messages
: Register
doX
: Register
Message reply/return
1. Standard reply/return message syntax
returnVar = message (parameter)
2. Reply/return message line at the end of execution bar
The University of Sydney
Messages to “Self”
d1 = getDate
getDate aDate
doX
: Sale
Using nested execution bar
clear
Page 37
Sequence Diagrams: Objects Creation/Destruction
: Register
: Sale
note that newly created objects are placed at their creation “height”
: Sale
makePayment(cashTendered)
create(cashTendered)
: Payment
X
the «destroy» stereotyped message, with the large
X and short lifeline indicates explicit object destruction
create(cashTendered)
authorize
: Payment
…
«destroy»
Object Creation
Read as:
Object Destruction
“Invoke the new operator and call the constructor”
Message name is optional The University of Sydney
Explicit destruction to indicate object is no longer useable (e.g., closed database connection)
Page 38
Sequence Diagrams: Frames
• Diagram frames in UML sequence diagrams
• Support conditional and looping construct
:A :B
makeNewSale
loop
[ more items ]
enterItem(itemID, quantity) description, total
The University of Sydney
Page 39
a UML loop frame, with a boolean guard expression
endSale
Sequence Diagrams: Frames
• Common frame operators
Frame operator
Meaning
Alt
Alternative fragment for mutual exclusion conditional logic expressed in the guards
Loop
Loop fragment while guard is true
Opt
Optional fragment that executes if guard is true
Par
Parallel fragments that execute in parallel
Region
Critical region within which only one thread can run
The University of Sydney Page 40
Sequence Diagrams: Conditional Messages
public class Foo {
Bar bar = new Bar ( ); …
public void ml ( ) {
bar.xx( );
if (color.equals(”red”))
bar.calculate( ); bar.yy( );
} }
xx
: Foo
: Bar
opt
[ color = red ]
calculate
yy
The University of Sydney
Page 41
Sequence Diagrams: Conditional Messages
Mutually exclusive conditional messages
The University of Sydney
:A :B
doX
:C
alt
[x<10]
calculate
[else]
calculate
Page 42
Sequence Diagrams: Nesting of Frames
xx
opt
[ color = red ]
loop(n)
calculate
The University of Sydney
Page 43
: Foo
: Bar
•
•
Interaction diagrams illustrates how objects interact via messages (dynamic behavior)
• Classes and their methods can be derived
• E.g., Register and Sale classes from makePayment sequence diagram
Class Diagrams: Relationship to Interaction Diagrams
Agile modeling practice: draw diagrams
concurrently as dynamic and static views complement each other during the design process
: Register
: Sale
makePayment(cashTendered)
makePayment(cashTendered)
messages in interaction diagrams indicate operations in the class diagrams
classes identified in the interaction diagrams are declared in the class diagrams
The University of Sydney
Page 44
1 currentSale
Sale
...
Register
...
makePayment(...) ...
makePayment(...) ...
Software Modelling Case Study
NextGen POS software modeling
Craig Larman. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of Sydney
Page 45
Next Gen Point-of-Sale (POS) System
• A POS is a computerized application used (in part) to record sales and handle payments
– Hardware: computer, bar code scanner
– Software
– Interfaces to service applications: tax calculator, inventory control
– Must be fault-tolerant (can capture sales and handle cash payments even if remote
services are temporarily unavailable
– Must support multiple client-side terminals and interfaces; web browser terminal, PC with
appropriate GUI, touch screen input, and Wireless PDAs
– Used by small businesses in different scenarios such as initiation of new sales, adding
new line item, etc.
The University of Sydney Page 46
Next Gen POS Analysis
Scope of OOA & D and Process Iteration
Craig Larman. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of Sydney Page 47
Next Gen POS – Scope (Analysis & Design)
User Interface
minor focus
explore how to connect to other layers
primary focus of case studies
explore how to design objects
secondary focus
application logic layer
other layers or components
Sale
Logging ...
Payment
Database Access ...
The University of Sydney
Page 48
Iteration and Scope – Design and Construction
Iteration 1
Introduces just those analysis and design skills related to iteration one.
Iteration 2
Additional analysis and design skills introduced.
Iteration 3 Likewise.
The University of Sydney
Page 49
Next Gen POS:
From Analysis to Design
Requirements Analysis (OOA)
Business modelling – domain models Use case diagrams
Use case description
System Sequence Diagrams
Design (OOD)
Sequence diagrams Class diagrams
The University of Sydney
Business Modeling
Sample UP Artifact Relationships Domain Model
Sale 1 1..* Sales LineItem
date ...
. . .
. . .
Process Sale
quantity
Use-Case Model
Vision
Glossary
Supplementary Specification
Cashier
use case names
Process Sale
1. Customer arrives ...
2. Cashier makes new sale.
3. ...
Use Case Text
system events
: System
make NewSale()
enterItem (id, quantity)
Require- ments
Use Case Diagram
Operation: enterItem(...)
Post-conditions: - . . .
parameters and return value details
: Cashier
system operations
Operation Contracts
System Sequence Diagrams
starting events to design for
: Register
Design Model
: ProductCatalog
: Sale
Design
enterItem (itemID, quantity)
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
Page 50
Self Learning Case Study
1. Use Cases
2. Use Case Diagram
3. Domain Model
4. Class Diagram
5. Interaction Diagram
Craig Larman. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of Sydney
Page 51
Task for Week 3
– Submit weekly exercise on canvas before 23.59pm Sunday
– Self learning on Next Gen POS system
– If you haven’t started your assignment 1, it would be a best time to start it from now on.
The University of Sydney
Page 52
References
Link to USYD Library
Link to USYD Library
The University of Sydney
Page 53
What are we going to learn next week?
– Software Design Principles – Design Smells
– SOLID – GRASP
The University of Sydney
Page 54