6/7/2011
SWE 621:
Software Modeling and Architectural Design
Lecture Notes on Software Design
Lecture 4- Object Structuring
Hassan Gomaa
Dept of Computer Science
G
George M
Mason U University
i it
Fairfax, VA
Copyright © 2011 Hassan Gomaa
All rights reserved. No part of this document may be reproduced in any form or
by any means, without the prior written permission of the author.
This electronic course material may not be distributed by e-mail or posted on any
other World Wide Web site without the prior written permission of the author.
Steps in Using COMET/UML
1 Develop Software Requirements Model
– Develop Use Case Model (Chapter 6)
2 Develop Software Analysis Model
– Develop static model of problem domain (Chapter 7)
– Structure system into objects (Chapter 8)
– Develop statecharts for state dependent objects (Chapter 10)
– Develop object interaction diagrams for each use case (Chapter 9, 11)
3 Develop Software Design Model
User
1
Requirements 2
Modeling
Analysis
Modeling
4 3 5
Design
Modeling 6
Throwaway Incremental
Prototyping Software
Construction 7
Incremental
Software
Integration 8
Customer
10
11 System
12 Incremental 9 Testing
13 Prototyping 14
15
2
1
6/7/2011
Lecture 4:
Object Structuring
Hassan Gomaa
References: H. Gomaa, Chapter 8 - Software Modeling and
Design, Cambridge University Press, February 2011
H. Gomaa, Chapter 9 - Designing Concurrent, Distributed,
and Real-Time Applications with UML, Addison Wesley
Object Technology Series, July, 2000
Copyright © 2011 Hassan Gomaa
All rights reserved. No part of this document may be reproduced in any form or
by any means, without the prior written permission of the author.
Copyright 2011 H. Gomaa os-3
Object Structuring Criteria
• Determine all software objects in system
– Use Object Structuring Criteria
– Guidelines for identifying
y g objects
j
• Structuring criteria depicted using stereotypes
– Stereotype defines a new building block that is derived
from an existing UML modeling element but is tailored
to the modeler’s problem
– Depicted using guillemets
• «entity»,
y «boundary», y «control»
• Objects are categorized
– A category is a specifically defined division in a
system of classification
2
6/7/2011
Object Structuring Criteria
• Boundary objects
– User interaction object
– Device I/O object
– Proxy object
• Entity objects
– Longg livingg objects
j that store information
– Determined during static modeling
• Control objects
• Application Logic Objects
Figure 8.1: Classification of application classes using
stereotypes
3
6/7/2011
Object Structuring Criteria
• Boundary objects
– Interface to and communicate with external
environment
– Each software boundary object interfaces to an external
(real-world) object
• User interaction object
• Device I/O object
• Proxy object
• For each boundary object there is a corresponding external
object
– Also depicted using stereotype
Figure 7.22 Classification of
external classes using stereotypes
4
6/7/2011
User interaction object
• Interfaces to and interacts with a human user
– Via standard I/O devices
• keyboard, visual display, mouse
– Support simple or complex user interfaces
• Command line interface
p
• Graphical user interface ((GUI))
Figure 8.2 Example of user interaction object
1: Operator 2: Sensor
Command Request
«user «entity»
interaction» :Sensor
:Operator Data
4: Display 3: Sensor
Data Interaction Repository
Data
: Operator
O
System boundary
Note: The dashed line for the system boundary is for illustrative purposes only and does not conform to the UML notation
10
5
6/7/2011
Object Structuring Criteria
• Proxy object
– Interfaces to an external system
– Hides details of how to communicate with external
system
• E.g., Robot Proxy
• Interfaces to external (real-world) robot
11
Figure 8.3 Example of proxy object
1: Pick & Place
Robot Command «external
«proxy»
system»
:Pick&Place
:External
Robot
Pick&Place
Proxy 2: Pick & Place
Robot Response Robot
Software object Real-world
external system
System boundary
Note: The dashed line for the system boundary is for illustrative purposes only and does not conform to the UML notation
12
6
6/7/2011
Object Structuring Criteria
• Device I/O boundary object
– Interfaces to I/O device
• Input object
– E.g., Sensor Interface
• Output object
– E.g., Actuator Interface
• I/O (Input/Output) object
– E.g., ATM Card Reader Interface
13
Figure 8.4 Example of input object
1: Temperature
«external input Sensor Input
device» «input»
aReal-World aTemperature
Temperature SensorInterface
Sensor
Real-world
hhardware
d object
bj t Software object
Hardware/software boundary
Note: The dashed line for the hardware/software boundary is for illustrative purposes only and does not conform to the UML notation
14
7
6/7/2011
Depicting External Classes
and Boundary Classes
• Start from system context class diagram
– Shows external classes
– System (aggregate class)
• Each external class must interface to
– software boundary class
• UML
– System shown as aggregate class
– External classes are outside the system class
– Boundary classes are inside the system class
15
Figure 8.7 Banking System external classes and software
boundary classes
«software system»
BankingSystem
i
inputs to
«external I/O «input/output»
1 1
1 device» CardReader
CardReader outputs Interface
to 1
1 ATM
outputs to Operator
1 «external output «output» 1
1 1 1
1 device» ReceiptPrinter interacts
«user with
ReceiptPrinter Interface
ATM 1 interaction» 1 1 «external user»
Customer interacts Operator Operator
1 Interaction
with
«external user» «user interaction»
1 1
ATMCustomer Customer
KeypadDisplay Interaction
outputs to
1 «external output «output»
1 1
device» CashDispenser
CashDispenser Interface
16
8
6/7/2011
Object Structuring Criteria
• Entity objects
– Long lasting objects that store information
• Same object typically accessed by many use cases
• Information persists over access by several use cases
– E.g., Account, Customer
– Entity classes and relationships shown on static model
– Entity classes often mapped to relational database
during design
Copyright 2011 H. Gomaa os-17
Figure 8.2 Example of entity object
1: Operator 2: Sensor
Command Request
«user «entity»
interaction» :Sensor
:Operator Data
4: Display 3: Sensor
Data Interaction Repository
Data
: Operator
O
System boundary
Note: The dashed line for the system boundary is for illustrative purposes only and does not conform to the UML notation
18
9
6/7/2011
Object Structuring Criteria
• Control objects
– Provides overall coordination for execution of a group
of objects
– Makes overall decisions
– Decides when, and in what order, other objects
participate in interaction sequence
• Entity objects
• Boundary objects
• Control
C t l objects
bj t
– Coordinator object
– State dependent control object
– Timer object
19
Figure 8.10 Coordinator object
Coordinator object
• Provides sequencing for group of objects
• Is not state dependent
20
10
6/7/2011
Figure 8.11 State dependent control object
State dependent control object
• Defined by finite state machine or state transition table
• Controls other objects
«output»
3: Print Receipt
:ReceiptPrinter
Interface
«state dependent 4: Receipt Printed
control»
:ATM 1: Dispense Cash
Control
«output»
t t
2: Cash Dispensed, :CashDispenser
Interface
21
Figure 8.12 Timer object
Timer object
• Activated periodically
1: Timer
« external Event «timer»
timer» : Report
: DigitalClock Timer
2: Prepare
«entity»
: Weekly Report
22
11
6/7/2011
Object Structuring Criteria
• Application Logic Objects
– Business Logic Object
• Defines business specific application logic (rules)
for processing a client request
• Usually accesses more than one entity object
– Algorithm Object
– Service object
23
Figure 8.13b Business logic object
24
12
6/7/2011
Figure 8.14 Example of algorithm object
Algorithm Object
• Encapsulates algorithm
used in problem domain
• More usual in scientific,
engineering, real-time
domains
25
Figure 8.15 Example of Service object
Service object
• Provides a service to other objects
• Responds to requests from client objects
26
13
6/7/2011
Steps in Using COMET/UML
1 Develop Software Requirements Model
– Develop Use Case Model (Chapter 6)
2 Develop Software Analysis Model
– Develop static model of problem domain (Chapter 7)
– Structure system into objects (Chapter 8)
– Develop statecharts for state dependent objects (Chapter 10)
– Develop object interaction diagrams for each use case (Chapter 9, 11)
3 Develop Software Design Model
User
1
Requirements 2
Modeling
Analysis
Modeling
4 3 5
Design
Modeling 6
Throwaway Incremental
Prototyping Software
Construction 7
Incremental
Software
Integration 8
Customer
10
11 System
12 Incremental 9 Testing
13 Prototyping 14
15
27
Case Study: Banking System
• Multiple Automated Teller Machines (ATM)
– Customer inserts ATM Card
– Enters Personal Identification Number (PIN)
– ATM Transactions
• PIN Validation
• Withdraw Funds from Checking or Savings Account
• Query Account
• Transfer funds between accounts
• Banking System maintains information about
– Customers
– Debit cards
– Checking and Savings Accounts
Copyright 2011 H. Gomaa
28
14
6/7/2011
Figure 21.1 Banking System use case model
Withdraw «include»
Funds
Query «include»
Validate
Account PIN
«include»
Transfer
ATM Funds
Customer
Add Cash
Startup
Shutdown
ATM Operator
Copyright 2011 H. Gomaa 29
Figure 21.3 Banking System class context diagram
1
«external I/O
device» 1..*
CardReader Inputs To
1 Operator
1 Outputs
«external output To
1
device» 1..* 1 1
Outputs
ReceiptPrinter To
1 «software Interacts
system» 1 With 1..* «external user»
1 Interacts Banking
1
ATM «external user» With Operator
System
Customer 1..*
1
ATMCustomer
1 Outputs
To
«external output
device»
1..*
CashDispenser
30
15
6/7/2011
Figure 21.9 Banking System external classes and software
boundary classes
«software system»
BankingSystem
i
inputs to
«external I/O «input/output»
1 1
1 device» CardReader
CardReader outputs Interface
to 1
1 ATM
outputs to Operator
1 «external output «output» 1
1 1 1
1 device» ReceiptPrinter interacts
«user with
ReceiptPrinter Interface
ATM 1 interaction» 1 1 «external user»
Customer interacts Operator Operator
1 Interaction
with
«external user» «user interaction»
1 1
ATMCustomer Customer
KeypadDisplay Interaction
outputs to
1 «external output «output»
1 1
device» CashDispenser
CashDispenser Interface
31
Steps in Using COMET/UML
1 Develop Software Requirements Model
– Develop Use Case Model (Chapter 6)
2 Develop Software Analysis Model
– Develop static model of problem domain (Chapter 7)
– Structure system into objects (Chapter 8)
– Develop statecharts for state dependent objects (Chapter 10)
– Develop object interaction diagrams for each use case (Chapter 9, 11)
3 Develop Software Design Model
User
1
Requirements 2
Modeling
Analysis
Modeling
4 3 5
Design
Modeling 6
Throwaway Incremental
Prototyping Software
Construction 7
Incremental
Software
Integration 8
Customer
10
11 System
12 Incremental 9 Testing
13 Prototyping 14
15
32
16
