The University of 1
Software Design and
Copyright By PowCoder代写 加微信 powcoder
Construction 1
SOFT2201 / COMP9201
UML Modeling
School of Computer Science
The University of 2
Copyright warning
COMMONWEALTH OF AUSTRALIA
Copyright Regulations 1969
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
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
Do not remove this notice.
The University of 3
Announcement
– Some tutorials of this week (week 3) may have alternative
arrangement
– Please double check the Ed post/announcement for further action
The University of 4
– 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 5
Software Modelling
• The process of developing conceptual models of a system at different
levels of abstraction
• Fulfil the defined system requirements
• Focus on important system details to deal with complexity
• Using graphical notations (e.g., UML) to capture different views or
perspectives
• There are three ways to apply UML
• Blueprint: detailed design diagrams for:
• Reverse engineering to visualize and understand existing code
• Forward engineering (code generation)
The University of 6
UML Diagrams
https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/UML
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 7
Use Case Diagrams
. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and
Iterative Development (3rd Edition).
1. Why we need Use Case Diagrams?
2. What is Use Case?
3. How can we draw Use Case Diagrams?
The University of 8
Rational Unified Process (UP)
• Software development
process utilizing iterative
and risk-driven approach to
develop OO software
• Iterative incremental
development
• Iterative evolutionary
development
The University of 9
Business Modelling,
Requirements and
Designs in RUP/UP*
Operation:
enterItem(…)
Post-conditions:
Operation Contracts
1..*1 . . .
Domain Model
Use-Case Model
Design Model
: Register
(itemID, quantity)
: ProductCatalog
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
objects, attributes,
associations
Sample UP Artifact Relationships
(id, quantity)
Use Case Text
System Sequence Diagrams
operations
Use Case Diagram
Supplementary
Specification
scope, goals,
actors, features
terms, attributes,
validation
non-functional reqs,
quality attributes
requirements
Process Sale
1. Customer
arrives …
2. Cashier
*RUP/UP: Rational Unified Process,
Lecture 1 pp. 59–64
Use Cases and Use
Case Diagrams
The University of 10
• 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
https://www.omg.org/spec/UML/2.5.1
https://www.omg.org/spec/UML/2.5.1
The University of 11
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
• 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
https://www.omg.org/spec/UML/2.5.1
https://www.omg.org/spec/UML/2.5.1
The University of 12
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 13
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
https://www.omg.org/spec/UML/2.5.1
https://www.omg.org/spec/UML/2.5.1
The University of 14
Use Case Diagram – UML Notations
Process Sale
Show computer system actors
with an alternate notation to
human actors.
primary actors on
supporting actors
on the right
For a use case context
diagram, limit the use cases to
user-goal level use cases.
Authorization
Process Sale
Authorization
Authorization
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.
Authorization
The University of 15
Use Case Diagrams – Tools
https://www.lucidchart.com/pages/examples/uml_diagram_tool
• 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 16
Class Diagrams
Structural Diagrams
. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and
Iterative Development (3rd Edition).
The University of 17
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 18
Class Diagram – Perspectives
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.
faceValue : int
getFaceValue() : int
die1 : Die
die2 : Die
DiceGame Die
Includes 21
• 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 19
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
Multiplicity and ‘rolename’ (currentSale) at
the target
No association name
Attribute text and as-association
• Not popular
currentSale : Sale
using the attribute
text notation to
indicate Register has
a reference to one
Sale instance
using the association notation to indicate
Register has a reference to one Sale instance
OBSERVE: this style
visually emphasizes
the connection
between these classes currentSale
currentSale : Sale
thorough and
unambiguous, but some
people dislike the
possible redundancy currentSale
The University of 20
Class Diagrams – Attribute Examples
– dateTime : Date
– / total : Money
Private visibility
attributes
+ pi : Real = 3.14 {readOnly}
Public visibility readonly
attribute with initialization
middleName : [0..1]
Optional value
Read-only Attributes with initialization, and optional values
The University of 21
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 22
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
enterItem(id, qty)
makeNewSale()
makePayment(cashTendered)
// 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 23
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
In class diagrams, at an association end
The University of 24
UML Stereotypes
• Stereotypes allow refinement (extension) of an existing modeling concept
• Defined in UML Profile
• UML profile: group of related model elements allow customizing UML models
for a specific domain or platform
• Extends UML’s «metaclass» Element
«stereotype»
Authorship
author: String
status : String
UML extension
relationship to a basic
UML metamodel term œ
«authorship»
author = —craig“
status = —tested“
«metaclass»
«authorship»
using the stereotype
a tool will probably allow a popup to fill in the tag values,
once an element has been stereotyped with «authorship»
declaring the stereotype
• UML note symbol
• Has no semantic impact
Specify a constraint
The University of 25
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 27
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 28
Associations
• Relationship between classifiers where
logical or physical link exists among
classifier’s instances
• May implemented differently; no certain
construct linked with association
• Notations:
• Association name (meaningful)
• Multiplicity
• Direction arrow
SaleRegister Records-current 4
association name multiplicity
-“reading direction arrow”
-it has no meaning except to indicate direction of
reading the association label
-often excluded
The University of 29
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.”
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
The University of 30
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
Employment
EmploysCompany Person**
a person may have
employment with several
The University of 31
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 32
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:
<
<
The University of 33
Dependency Example
runFinalization()
the doX method invokes the runFinalization
static method, and thus has a dependency on
the System class
The University of 34
UML Interaction
Dynamic (Behavioural) Diagrams
. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative
Development (3rd Edition).
The University of 35
UML Interaction Diagrams
• One of the dynamic (behavioral) diagrams which consists of diagrams including
Sequence and Communication diagram
: A myB : B
Communication diagrams: objects’
interactions are illustrated in a
graph/network format
Sequence diagrams: illustrate sequence/time-
ordering of messages in a fence format (each object
is added to the right)
2: doThree
The University of 36
Sequence Diagrams: Classes/Objects
• Participants in interactions (class instances, lifeline boxes)
ArrayList
:Sale s1 : Sale
lifeline box representing an
instance of an ArrayList class,
parameterized (templatized) to
hold Sale objects
lifeline box representing an
unnamed instance of class Sale
lifeline box representing a
named instance
sales[ i ] : Sale
lifeline box representing
one instance of class Sale,
selected from the sales
ArrayList
«metaclass»
lifeline box representing the class
Font, or more precisely, that Font is
an instance of class Class œ an
instance of a metaclass
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
Actual lifeline of a
participating object
(solid or dashed)
The University of 37
Sequence Diagrams: Messages
• Standard message syntax in UML
ReturnVar = message (parameter : parameterType) : returnType
• Some details may be excluded.
Initialize(code)
descrp = getProductDescription(id)
descrp = getProductDescription(id) : ProductDescription
• The time ordering from top to bottom of lifelines
: Register : Sale
typical sychronous message
shown with a filled-arrow line
a found message
whose sender will not
be specified
execution specification
bar indicates focus of
The University of 38
Sequence Diagrams: Messages
Message reply/return
1. Standard reply/return message syntax
returnVar = message (parameter)
2. Reply/return message line at the end of
execution bar
: Register : Sale
d1 = getDate
: Register
Messages to “Self”
Using nested execution bar
The University of 39
Sequence Diagrams: Objects Creation/Destruction
Object Creation
“Invoke the new operator and call the constructor”
Message name is optional
Object Destruction
Explicit destruction to indicate object
is no longer useable (e.g., closed
database connection)
: Register : Sale
makePayment(cashTendered)
: Paymentcreate(cashTendered)
note that newly created
objects are placed at their
creation “height” : Sale
: Paymentcreate(cashTendered)
the «destroy» stereotyped
message, with the large
X and short lifeline
indicates explicit object
destruction
«destroy» X
The University of 40
Sequence Diagrams: Frames
enterItem(itemID, quantity)
a UML loop
frame, with a
boolean guard
expression description, total
makeNewSale
[ more items ]loop
• Diagram frames in UML sequence diagrams
• Support conditional and looping construct
The University of 41
Sequence Diagrams: Frames
• Common frame operators
Frame operator Meaning
Alt Alternative fragment for mutual exclusion conditional logic expressed in the
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 42
Sequence Diagrams: Conditional Messages
[ color = red ]opt
public class Foo {
Bar bar = new
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com