Professional Documents
Culture Documents
Quiz 2 Solutions
Quiz 2 Solutions
Entity objects: File, Folder, Disk, TrashCan (if regarded as folder)
Boundary objects: Icon, Pointer, TrashCan (if regarded as icon)
Control objects: none in this example.
pressButton1() blinkHours()
pressButton1() blinkMinutes()
pressButton2() incrementMinutes()
refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()
Messages: pressButton1(), pressButton2(), pressButton1and2() 2BWatchInput
blinkHours(), blinkMinutes(), stopBlinking(), refresh() 2BWatchDisplay
possible attribute: digitBlanking
incrementMinutes(), commitNewTime()
possible attribute: time
2BWatch
Actor.
System boundary
Use case diagrams represent the functionality of the system
from user’s point of view
Cancel NoChange
Bernd Bruegge & Allen H. Dutoit ObjectOriented Software Engineering: Using UML, Patterns, and Java 10
The <<includes>> Relationship
• <<includes>> relationship
represents common
functionality needed in more
than one use case
Passenger
• <<includes>> behavior is
factored out for reuse, not
PurchaseMultiCard because it is an exception
• The direction of a
PurchaseSingleTicket
<<includes>> relationship is
<<includes>>
to the using use case (unlike
<<includes>> the direction of the
<<extends>> relationship).
CollectMoney
<<extends>> <<extends>>
<<extends>>
Association
Class
Multiplicity Watch
1 1 1 1
2
1 2 1
PushButton
state LCDDisplay Battery Time
blinkIdx Load Now
push() blinkSeconds()
release() blinkMinutes()
blinkHours()
stopBlinking()
Operations
Attribute referesh()
TarifSchedule Trip
Table zone2price
zone:Zone
Enumeration getZones() * * Price: Price
Price getPrice(Zone)
TarifSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)
TarifSchedule
zone2price Attributes Signature
getZones()
getPrice()
Operations TarifSchedule
• Actor
• An entity outside the system to be modeled,
interacting with the system (“Passenger”)
• Class
• An abstraction modeling an entity in the application or
solution domain
• The class is part of the system model (“User”, “Ticket
distributor”, “Server”)
• Object
• A specific instance of a class (“Joe, the passenger who
is purchasing a ticket from the ticket distributor”).
Sequence diagrams represent the behavior of a system
as messages (“interactions”) between different objects
Bernd Bruegge & Allen H. Dutoit ObjectOriented Software Engineering: Using UML, Patterns, and Java 16
Sequence DiagramsFocus on
control flow
selectZone()
lookupPrice(selection)
price
displayPrice(price)
Dataflow
*insertChange(coin) lookupCoin(coin)
value
Iteration
displayPrice(owedAmount)
[owedAmount<0] returnChange(owedAmount)
Condition
ChangeProcessor
Passenger Creation of Ticket
createTicket(selection)
Ticket
print()
free()
Destruction of Ticket
button1&2Pressed button2Pressed
Blink Increment
Hours Hours
Transition button1Pressed
button1&2Pressed button2Pressed
Blink Increment
Minutes Minutes
State
button1Pressed
button2Pressed
Stop Blink Increment
Blinking Seconds Seconds
Final state
Represent behavior of a single object with interesting dynamic behavior.
Bernd Bruegge & Allen H. Dutoit ObjectOriented Software Engineering: Using UML, Patterns, and Java 22
Activity Diagrams
• An activity diagram is a special case of a state
chart diagram
• The states are activities (“functions”)
• An activity diagram is useful to depict the
workflow in a system
[lowPriority]
Open Allocate
Incident Resources
[fire & highPriority]
[not fire & highPriority]
Notify
Fire Chief
Notify
Police Chief
Allocate
Splitting Resources Synchronization
Document
Incident
Allocate Dispatcher
Resources
FieldOfficer
Document
Incident
• Functional requirements
• Describe the interactions between the system and its
environment independent from the implementation
“An operator must be able to define a new game. “
• Nonfunctional requirements
• Aspects not directly related to functional behavior.
“The response time must be less than 1 second”
• Constraints
• Imposed by the client or the environment
• “The implementation language must be Java “
• Called “Pseudo requirements” in the text book.
• Entity Objects
• Represent the persistent information tracked by the
system (Application domain objects, also called
“Business objects”)
• Boundary Objects
• Represent the interaction between the user and the
system
• Control Objects
• Represent the control tasks performed by the system.
Goals
Chapter 7
System Design:
Addressing Design
System Design
8. Boundary
1. Design Goals Conditions
Definition Initialization
Tradeoffs Termination
Failure
2. Subsystem Decomposition 7. Software
Layers vs Partitions Control
Coherence/Coupling
Monolithic
EventDriven
3. Concurrency Conc. Processes
Identification of 4. Hardware/ 5. Data 6. Global Resource
Threads
Software Mapping Management Handling
Special Purpose Persistent Objects Access Control List
Buy vs Build Filesystem vs Database vs Capabilities
Allocation of Resources Security
Connectivity
Bernd Bruegge & Allen H. Dutoit ObjectOriented Software Engineering: Using UML, Patterns, and Java 38
6. Global Resource Handling
• Initialization
• The system is brought from a non-initialized state to
steady-state
• Termination
• Resources are cleaned up and other systems are
notified upon termination
• Failure
• Possible failures: Bugs, errors, external problems
• Good system design foresees fatal failures and
provides mechanisms to deal with them.
• Initialization
• What data need to be accessed at startup time?
• What services have to registered?
• What does the user interface do at start up time?
• Termination
• Are single subsystems allowed to terminate?
• Are subsystems notified if a single subsystem
terminates?
• How are updates communicated to the database?
• Failure
• How does the system behave when a node or
communication link fails?
• How does the system recover from failure?
Bernd Bruegge & Allen H. Dutoit ObjectOriented Software Engineering: Using UML, Patterns, and Java 50
Modeling Boundary Conditions
<<include>>
StartServer
Server <<include>>
Administrator
ManageServer ShutdownServer
<<include>>
ConfigureServer