程序代写代做代考 database Java case study Software Design and Construction 1 SOFT2201 / COMP9201 – cscodehelp代写
Software Design and Construction 1 SOFT2201 / COMP9201
UML Modeling
Dr. Grane School of Computer Science
The University of 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 2
Agenda
– UML Modeling
– UML Use Case Diagrams
– UML Class Diagrams
– UML Interaction Diagrams
– Case Study: Next Gen Point-of-Sale (POS) System – BriefIntroduction
– Selflearningdetails
The University of 3
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 visualise and understand existing code • Forwardengineering(codegeneration)
The University of 4
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) – emphasises flow of control and data
https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/UML
The University of 5
Use Case Diagrams
1. Why we need Use Case Diagrams?
2. What is a Use Case?
3. How can we draw Use Case Diagrams?
. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of 6
Rational Unified Process (UP)
• Software development process utilising iterative and risk-driven approach to develop OO software systems
• Iterative incremental development
• Iterative evolutionary development
The University of 7
Business Modelling, Requirements and Designs in RUP/UP*
Business Modeling
Sample UP Artifact Relationships Domain Model
1 1..*
Use-Case Model
use case names
*RUP/UP: Rational Unified Process, Lecture 1 pp. 59–64
enterItem
Design
Sale date
Sales LineItem
quantity
objects, attributes, associations
…
…
…
scope, goals, actors, features
terms, attributes, validation
Vision
Cashier
Process Sale
Process Sale
1. Customer arrives …
2. Cashier makes new sale.
3. …
Require- ments
Use Case Diagram
Use Case Text
Glossary
Use Cases and Use Case Diagrams
: Cashier
system events
: System
make NewSale()
enterItem (id, quantity)
Supplementary Specification
non-functional reqs, quality attributes
Operation: enterItem(…)
Post-conditions: -…
system operations
Operation Contracts
System Sequence Diagrams
Design Model
requirements
: Register (itemID, quantity)
: Sale
: ProductCatalog
spec = getProductSpec( itemID ) addLineItem( spec, quantity )
The University of 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 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 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 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 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.
NextGen
Process Sale
…
Cashier
primary actors on the left
supporting actors on the right
«system» Payment Authorization Service
Payment Authorization Service
The University of 13
«actor» Payment Authorization Service
NextGen Process Sale
…
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.
«actor» Payment Authorization Service
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 14
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 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 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)
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
The University of 17
DiceGame
2
faceValue
Die
Die
die1 : Die die2 : Die
faceValue : int
getFaceValue() : int roll()
play()
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 target
Multiplicity and ‘rolename’ (currentSale) at the target
No association name
Attribute text and as-association
• Not popular
1 currentSale
Sale
…
…
Register
currentSale : Sale
…
…
Register
…
using the association notation to indicate Register has a reference to one Sale instance
The University of 18
using the attribute text notation to indicate Register has a reference to one Sale instance
OBSERVE: this style visually emphasizes the connection between these classes
thorough and unambiguous, but some people dislike the possible redundancy
Register
1 currentSale
Sale
…
…
currentSale : Sale
…
Sale
…
…
Class Diagrams – Attribute Examples
Math
+ pi : Real = 3.14 {readOnly}
Person
firstName middleName : [0..1] lastName
Sale
– dateTime : Date – / total : Money
The University of 19
Private visibility attributes
Public visibility readonly attribute with initialization
Read-only Attributes with initialisation, 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 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
«method»
// pseudo-code or a specific language is OK public void enterItem( id, qty )
{
ProductDescription desc = catalog.getProductDescription(id);
sale.makeLineItem(desc, qty); }
…
Register
endSale()
enterItem(id, qty) makeNewSale() makePayment(cashTendered)
The University of 21
UML Keywords
• Textual adornment to categorise 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 22
UML Stereotypes
• •
Stereotypes allow refinement (extension) of an existing modeling concept • Defined in UML Profile
UML profile: group of related model elements allow customising UML models for a specific domain or platform
• Extends UML’s «metaclass» Element
UML note symbol
• Has no semantic impact Specify a constraint
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 extension relationship to a basic UML metamodel term – Element
«authorship» author = “craig” status = “tested”
«metaclass» Element
…
«stereotype» Authorship
author: String status : String
«authorship» Square
…
The University of 23
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 24
Generalisation, Abstract Classes & Operations
“Generalisation – 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]
•
• •
Generalisation implies inheritance in design class diagram (software perspective) but not in the domain model (conceptual perspective)
Classes and operations with {abstract} tag are abstract
Classes and operations with {leaf} are final (cannot be overridden in the sub-classes)
The University of 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 26
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
Records-current
-“reading direction arrow”
-it has no meaning except to indicate direction of
reading the association label -often excluded
Register
Sale
1
0..1
The University of 27
association name
multiplicity
Associations – Multiplicity
• Multiplicity: number of instances involved in the relationship (association)
• Communicates domain constraints that will be implemented
• Multiplicity focuses 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.”
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
The University of 28
Association Class
• Modelling an association as a class (with attributes, operations & other features)
• A Company Employs many Persons
• Employs → Employment class with attributes salary and startDate * Employs *
Company
Person
Employment
salary startDate
The University of 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 30
When to show dependency?
• Be selective in describing dependency
• Many dependencies are already shown in another 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 32
UML Interaction Diagrams
Dynamic (Behavioural) Diagrams
. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of 33
UML Interaction Diagrams
• One of the dynamic (behavioural) 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
The University of 34
:A
doTwo doThree
myB : B
doOne
:A
doOne
1: doTwo 2: doThree
myB : B
Sequence Diagrams: Classes/Objects
• Participants in interactions (class instances, lifeline boxes)
lifeline box representing the class Font, or more precisely, that Font is an instance of class Class – an instance of a metaclass
lifeline box representing an unnamed instance of class Sale
lifeline box representing a named instance
Actual lifeline of a participating object (solid or dashed)
:Sale
s1 : Sale
«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
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: ArrayList
sales[ i ] : Sale
x : List
The University of 35
related example
Sequence Diagrams: Messages
• Standard message syntax in UML
ReturnVar = message (parameter : parameterType) : returnType
• Some details may be excluded. Examples:
Initialise(code)
descrp = getProductDescription(id)
descrp = getProductDescription(id) : ProductDescription
• The time ordering from top to bottom of lifelines
doX
: Register
: Sale
doA doB doC
doD
a found message whose sender will not be specified
The University of 36
execution specification
bar indicates focus of control
typical sychronous message shown with a filled-arrow line
Sequence Diagrams: Messages
: Register
: Sale
: Register
doX
doX
d1 = getDate
getDate aDate
clear
Message reply/return
1. Standard reply/return message syntax
returnVar = message (parameter)
2. Reply/return message line at the end of execution bar
Messages to “Self”
The University of 37
Using nested execution bar
Sequence Diagrams: Objects Creation/Destruction
: Register
: Sale
makePayment(cashTendered)
create(cashTendered)
…
«destroy»
“Invoke the new operator and call the constructor”
Message name is optional The University of destruction to indicate object is no longer useable (e.g., closed database connection)
Page 38
create(cashTendered)
authorize
X
note that newly created objects are placed at their creation “height”
: Sale
: Payment
the «destroy» stereotyped message, with the large
X and short lifeline indicates explicit object destruction
: Payment
Object Creation
Read as:
Object Destruction
Sequence Diagrams: Frames
• Diagram frames in UML sequence diagrams
• Support conditional and looping construct
makeNewSale
loop [ more items ]
enterItem(itemID, quantity) description, total
The University of 39
:A
endSale
:B
a UML loop frame, with a boolean guard expression
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 40
Sequence Diagrams: Conditional Messages
public class Foo {
Bar bar = new Bar ( ); …
public void ml ( ) {
bar.xx( );
if (colour.equals(”red”))
bar.calculate( ); bar.yy( );
} }
xx
: Foo
: Bar
opt
[ color = red ]
calculate
yy
The University of 41
Sequence Diagrams: Conditional Messages
Mutually exclusive conditional messages
:A
:B
:C
doX
alt
[x<10]
calculate
[else]
calculate
The University of 42
Sequence Diagrams: Nesting of Frames
: Foo
xx
: Bar
opt
[ color = red ]
loop(n)
calculate
The University of 43
•
Agile modelling practice: draw diagrams concurrently as dynamic and static views complement each other during the design process
Class Diagrams: Relationship to Interaction Diagrams
•
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
makePayment(cashTendered)
The University of 44
messages in interaction diagrams indicate operations in the class diagrams
: Register
makePayment(cashTendered)
: Sale
1 currentSale
classes identified in the interaction diagrams are declared in the class diagrams
Sale
...
Register
...
makePayment(...) ...
makePayment(...) ...
Software Modelling Case Study
NextGen POS software modeling
. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of 45
Next Gen Point-Of-Sale (POS) System
• A POS is a computerised 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 46
Next Gen POS Analysis
Scope of OOA & D and Process Iteration
. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of 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
Payment
The University of 48
Logging ...
Database Access ...
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 49
Business Modeling
Sample UP Artifact Relationships Domain Model
1 1..*
Use-Case Model
use case names
Sale date
Sales LineItem
...
...
...
quantity
Vision
Require- ments
Use Case Diagram
Use Case Text
Cashier
Process Sale
Process Sale
1. Customer arrives ...
2. Cashier makes new sale.
3. ...
parameters and return value details
Glossary
system events
: System
make NewSale()
Operation: enterItem(...)
Post-conditions: -...
system operations
: Cashier
enterItem (id, quantity)
Supplementary Specification
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 )
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 50
Self Learning Case Study
1. Use Cases
2. Use Case Diagram
3. Domain Model
4. Class Diagram
5. Interaction Diagram
. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition).
The University of 51
