Read the OpenQuestion pdf files

StateTransition:

Now that the requirement of Homework 4 is changed to add parentheses and order of operations as
follows: Parentheses (simplify inside ’em) , Multiplication and Division (from left to right), Addition and
Subtraction (from left to right). The new display panel should be as follows:

Draw a UML State Transition Diagram to model the new calculator object.

 (6 points) Using standard UML State Transition Diagram Notation, as exemplified in page 25 of the
“SE 311 StateDiagram” slides. The diagram should be clear and self- explanatory.

 (7 points) Modeling state transitions of parentheses correctly

 (7 points) Modeling order of operations correctly

Submit a one-page pdf with the State Transition Diagram.

Design a miniRing system similar to the Ring product (http://ring.com), with reduced functions.  

The user needs to install the following items:  

(1) a Video Doorbell (see below), which includes a camera and a doorbell, outside a door of the user’s 
house.  

(2) a cell phone app called miniRing 

Note that a user can install multiple Video 
Doorbells if the house has multiple doors.   

Requirements: 

From the user perspective, the major functions of 
the system are as follows:  

1. If someone is ringing the DoorBell,   
1) the user will receive a DoorBell ring tone 
on the cellphone;   
2) if the user opens the door, the event will 
be recorded as an “Answered Ring” event;   
3) if the user doesn’t open the door, the event will be recorded as a “Missed Ring” event.  

2. If there is a motion in front of the door, e.g., a mailman dropping a package,   
1) the user will receive a WindBell ring tone on the cellphone;   
2) the event will recorded as a “Motion” event;  

3. Using the cell phone app, the user shall be able to do the following:  
1) if the user received a DoorBell ring tone, (s)he shall be able to live watch the scene, and talk to 
the visitor;   
2) if the user received a WindBell ring tone, (s)he shall be able to live watch the scene;  
3) the user can live watch the scene at any time using a “Live View” function;   
4) the user can view the event history that contains a list of events of different types: “Answered 
Ring”, “MIssing, Ring”, or “Motion”. Each event is recorded as a short video clip (from 30 to 60 
seconds) that can be played at any time.  

4. Using the cellphone app, the user can also  
1) login to the system using pre‐assigned username and password   
2) set different music to the DoorBell and/or WindBell ring tones  
3) toggle on/off doorbell alert and/or motion alert  
4) monitor device health, including 

a) the battery level of the video DoorBell  
b) the wi‐fi network name and signal strength 

5. The miniRing system also has he following functions:   
1) Manage users. Only paid users can login and use the cell phone app. If an unregistered user tried 
to login, an error message will be sent to the user’s cellphone.   
2) Manage event. There should be a central database storing all the events for each user. If the user 
reinstall the app, (s)he should be able to retrieve the event history 
3) Remind users to pay annual subscription fee.   
 
 

Design the miniRing system using 4+1 view:  
 
1.  Component Diagram and Deployment Diagram: the system should at least contain:   

 two physical components: a camera and a doorbell, which are installed in one Video DoorBell 
device, but send signals separately as two components. These two components do not have 
CPUs and their only function is to send signals.  

 a cell phone app component, which we call MiniRingApp   
 a central miniRing server component, which we call MiniRingManager.    
You could design more components as you see fit. 
 
a) (3 points) Draw a UML component diagram to show the relations among these components. 
b) (3 points) Draw a UML deployment diagram to show how these components are installed on 

various devices. You can either draw these two diagrams together or separately.  
 

 
2. Class Diagrams:  

a) (6 points) Draw a UML class diagram to elaborate the design of the MiniRingApp component.  
The methods within each class should reflect its responsibilities (functions). If a pattern is 
applied, name the pattern and list its participants; if no pattern is applied, simply state so.  

b) (6 points) Draw a UML class diagram for the MiniRingManager component. The methods 
within each class should reflect its responsibilities (functions). If a pattern is applied, name the 
pattern and list its participants; if no pattern is applied, simply state so. 

 
3. Sequence Diagrams and User Scenarios 

a) (10 points) Draw a number of sequence diagrams to show how the classes/components 
interact to accomplish specified functions. Use standard notions, as introduced in page 4‐13 of 
the slides titled “SE 311 SequenceDiagram”.  

b) (7 points) For each sequence diagram, list all the corresponding user scenarios that is testable, 
as shown in page 4 and page 13 of slides. These scenarios should cover all functions mentioned 
in the requirements. A user scenario should follow a simple template:  

++ 
 

4. Matching (5 points) These diagrams must match with each other.  
 

To submit you answer: prepare one or more pdf files with you design. You can draw the diagrams using 
draw.io (https://www.draw.io/), export them as   pictures, and insert these pictures into a word 
document to add explanations, and convert the word document into a   file.   
 
Please note that you can only submit 1 file to BB learning. If you have multiple pdf files, you need to zip 
them together into one zip file.  
 

UML State Diagram

UML Statechart Diagram (STD)

Shows the sequences of states that objects of a class go through during its life cycle in response to external events and also the responses and actions in reaction to an event.

Model elements

States

Transitions

Events

Actions and activities

STD Elements
A Event – is a significant or noteworthy occurrence
e.g. a phone receiver is taken off the hook
A State – is the condition of an object at a moment in time
– the time between events.
e.g. a phone is in the state of being “idle” after the receiver is placed on the hook until it is taken off the hook.
A transition – is a relationship between two states that indicates that when an event occurs, the object moves from the prior state to the subsequent state.
e.g. when the event “off hook” occurs, transition the phone from the “idle” to “active” state.

Example: STD for a Phone
Idle

Initial state
Active
off hook
on hook
transition
event
state

(c) National Centre for Software Technology
13 March, 2021
Object Oriented Analysis and Design
4

Classes that Need State Diagrams
State-dependent classes
objects react differently to events depending on their state

State-independent classes do not need State Diagrams
an object always responds the same way to an event

Event Types
External Event (also known as system event)
is caused by something outside the system boundary
e.g. when a cashier presses the “enter item” button on a POST, an external event has occurred.
Internal Event
is caused by something inside our system boundary.
In terms of SW, an internal event arises when an operation is invoked via a message sent from another internal object. (The messages in collaboration diagrams suggest internal events)
Temporal Event
is caused by the occurrence of a specific date and time or passage of time.

State
Abstraction of attribute values and links of an object
Sets of values are grouped together into a state
Corresponds to the interval between two events received by the object
events represent points in time
states represent intervals of time
Has duration

State
Often associated with a
continuous activity
value satisfying some condition
Event separates two states
State separates two events

State Diagram
Graph relating events and states
Nodes are states; arcs are events
Describes behaviour of a single class of objects
Can represent
one-shot life cycles
continuous loops

State Diagram
Continuous loop
graph is a loop
no definite start state
not concerned about how the loop starts
dial tone
idle
dialling
digit (n)
on-hook
on-hook
digit (n)
State
Transition
Event

off-hook
Example:

State Diagram
One-shot life cycle
represents objects with finite lives
initial state entered on creation of object
entering final state destroys object
initial state shown using solid circle
final state(s) shown using bull’s eye
White’s move
Black’s move
start

white
moves
black
moves

Black wins
Draw
White wins

stalemate
stalemate
Example:

Transition Actions, Guard Conditions
Transition Actions
a transition can cause an action to fire. In SW, this may represent the invocation of a method of an object
Transition Guard conditions
a transition may also have a conditional guard — or boolean test. The transition is only taken if the test passes.
Idle

Active
off hook / play dial tone
on hook
event
[ valid subscriber ]

action
guard condition

Guard Condition
Boolean function of object values
Valid over an interval of time
Can be used as guards on transitions
Guard condition shown in brackets, following event name
login
password
[user name]
Guard condition

Operations
Attached to states or transitions
Performed in response to corresponding states or events
Types
Activity
Action

Operations
Activity
operation that takes time to complete
associated with a state
include continuous or sequential operations
notation “do: A” within a state box
indicates activity A
starts on entry
ends on exit
login
do : display login prompt
password
do: get password

Operations
Action
instantaneous operation
associated with an event
notation
slash (“/”) and name of the action, following the event
Idle
Menu
visible
right button down / display popup menu
right button up / erase popup menu
cursor moved / highlight menu item

Example

Validating
do /check
item

Dispatching
do /initiate
delivery
Completed
Pending

/ get first item
Start
[All items valid &&
all items available ]
Delivered
[All items valid &&
some items not in stock ]

Item Received
[some items not in stock ]
Get next item
[not all items validated ]

Item Received
[ all items available ]
Self-transition
State
Transition
Activity

Example
Idle
Reading product
codes
Closing transaction
start button pressed /
print receipt header
total button
pressed
complete button pressed /
print receipt footer
product code input (product code) /
print product price

Nested State Diagrams
State diagrams can get complex
For better understanding and management
A State in a state diagram can be expanded into a state diagram at another level
Inheritance of transitions

Example: Nested States
Playing Dial Tone

complete
Idle
Talking
Connecting
Dialing

connected
digit

digit
Active

off hook / play dial tone
[ valid subscriber ]
on hook

Example
prompt
reading
char (c)
char (c)
start

Enter key
password

Subject of a State Diagram
Software Classes
the STD shows the sequences of states that objects of a class go through during its life cycle in response to external events and also its responses and actions in reaction to an event.
Use cases
the STD depicts the overall system events and their sequence within a use case

Example: STD for Buy Items Use Case
Waiting for Sale

enterItem
Entering Items
Waiting for Payment

enterItem
endSale

makePayment

State Diagram
A state diagram (also called state machine diagram) depict the various states that an object may be in and the transitions between those states.
Appropriate to be developed for complex objects.
From UML Distilled (pp. 107-108):
A lock in a haunted house: keep valuables in a safe that’s hard to find
To reveal the lock to the safe, I have to remove a strategic candle from its holder, but this will reveal the lock only while the door is closed. In the Wait state, if the candle is removed providing the door is closed, you reveal the lock and move to the Lock state. Once I can see the lock, I can insert my key to open the safe. For extra safety, I make sure that I can open the safe only if I re-place the candle first. If a thief neglects this precaution, I’ll unleash a killer rabbit to him.

A state is a condition in which an object can be at some point during its lifetime, for some finite period of time. State diagrams describe all the possible states a particular object can get into and how the object’s state changes as a result of external events that reach the object.

State Diagram
From UML Distilled (pp. 107-108):
A lock in a haunted house: keep valuables in a safe that’s hard to find
To reveal the lock to the safe, I have to remove a strategic candle from its holder, but this will reveal the lock only while the door is closed. In the Wait state, if the candle is removed providing the door is closed, you reveal the lock and move to the Lock state. Once I can see the lock, I can insert my key to open the safe. For extra safety, I make sure that I can open the safe only if I re-place the candle first. If a thief neglects this precaution, I’ll unleash a killer rabbit to him.

A state is a condition in which an object can be at some point during its lifetime, for some finite period of time. State diagrams describe all the possible states a particular object can get into and how the object’s state changes as a result of external events that reach the object.

States
States are represented by the values of the attributes or data members of an object.

Initial state
state
Terminal state
transition

States are represented by the values of the attributes or data members of an object.
In a UML state machine diagram . . .
[click] An initial or start state is represented by a solid circle.
[click] A state is represented by a rounded rectangle.
[click] A final state is represented by a solid circle with another open circle around it.
[click] A transition is a change of an object from one state (the source state) to another (the target state) triggered by events, conditions, or time. Transitions are represented by an arrow connecting two states.
We’ll discuss more about the specifics of transitions on the next slide.

Transitions
Transitions are the result of the invocation of a method that causes an important change in state.
Each transition has a label that comes in three parts. All the parts are optional.
trigger-signature [guard]/activity
candle removed [door closed]/reveal lock
The trigger-signature is usually a single event that triggers a potential change of state.
Missing trigger-signature [rare] – you take the transition immediately.
The guard, if present, is a Boolean condition that must be true for the transition to be taken.
Missing guard – always take the transition.
The activity is some behavior that’s “executed” during the transition.
Missing activity – don’t do anything during the transition.

Again, a transition is a change of an object from one state (the source state) to another (the target state) triggered by events, conditions, or time.
Each transition has a label that comes in three parts. [click] All three parts of the label are optional.

The trigger-signature is usually a single event that triggers a potential change of state. A missing trigger-signature, which happens rarely, indicates that you take the transition immediately.
The guard, if present, is a Boolean condition that must be true for the transition to be taken. A guarded transition occurs only if the guard resolves to true. Only one transition can be taken out of a given state. If more than one guard condition is true, only one transition will fire. The choice of transition to fire is nondeterministic if no priority rule is given. A missing guard indicates that you always take the transition once the trigger-signature has fired.
The activity is some behavior that’s “executed” during the transition. A missing activity means that you don’t do anything during the transition.

trigger-signature: event that causes a potential change of state
guard: Boolean condition that must be true for transition to happen
activity: behavior that’s executed during the transition

Let’s review these three elements of a transition in the context of a state diagram. Here is a state diagram for a lock in a haunted house. The scenario goes:
To reveal the lock to the safe, I have to remove a strategic candle from its holder, but this will reveal the lock only while the door is closed. In the Wait state, if the candle is removed providing the door is closed, you reveal the lock and move to the Lock state. Once I can see the lock, I can insert my key to open the safe. For extra safety, I make sure that I can open the safe only if I replace the candle first. If a thief neglects this precaution, I’ll unleash a killer rabbit to him.
[click]
The trigger-signature is usually a single event that triggers a potential change of state. In this case, the state change from the lock being in the waiting state to the locked state is initiated when the candle is removed.
[click] The guard, if present, is a Boolean condition that must be true for the transition to be taken. A guarded transition occurs only if the guard resolves to true. In this case, we’re still trying to decide if the lock will go from the waiting state to the locked state if the candle is removed – it only will do so if the door is closed.
[click] The activity is some behavior that’s “executed” during the transition. In this case, the behavior is that the lock will be revealed.

Rules for State Diagrams
There is one initial state (can be multiple final states).
Every state can be reached from the initial state.
From each state, there must be a path to a final state.
Every transition between states must be labeled with an event that will cause that transition.
When an event occurs, you can take only one transition. If you have multiple transitions with the same event, the guards must be mutually exclusive.
Transitions that are not shown are illegal OR show transitions that cause errors.

There are some rules for state diagrams.
There is only one initial state.
Every state can be reached from the initial state.
From each state, there must be a path to a final state.
Every transition between states must be labeled with an event that will cause that transition.
When an event occurs, you can take only one transition. If you have multiple transitions with the same event, the guards must be mutually exclusive.
And finally . . .
Transitions that are not shown are illegal OR show transitions that cause errors.

Utility of Use Case State Diagrams
For a complex use case with many system events e.g. create entity in ERD editor a STD that shows the legal order of external events is helpful.
The Use case STDs serve as inputs to a designer to develop a design that ensures correct system event order. Possible design solutions include:
hard-coded conditional tests for out of order events
disabling widgets in active windows to disallow illegal events
a state machine interpreter that runs a state table representing the use case STD.

Class Exercises
ATM Example
Startup Use case
The system is started up when the operator turns the operator switch to the “on” position. The operator will be asked to enter the amount of money currently in the cash dispenser, and a connection to the bank will be established. Then the servicing of customers can begin.
Shutdown Use Case
The system is shut down when the operator makes sure that no customer is using the machine, and then turns the operator switch to the “off” position. The connection to the bank will be shut down. Then the operator is free to remove deposited envelopes, replenish cash and paper, etc.

Class Exercises
ATM Session User Case
A session is started when a customer inserts an ATM card into the card reader slot of the machine. The ATM pulls the card into the machine and reads it. (If the reader cannot read the card due to improper insertion or a damaged stripe, the card is ejected, an error screen is displayed, and the session is aborted.) The customer is asked to enter his/her PIN, and is then allowed to perform one or more transactions, choosing from a menu of possible types of transaction in each case. After each transaction, the customer is asked whether he/she would like to perform another. When the customer is through performing transactions, the card is ejected from the machine and the session ends. If a transaction is aborted due to too many invalid PIN entries, the session is also aborted, with the card being retained in the machine.
The customer may abort the session by pressing the Cancel key when entering a PIN or choosing a transaction type.

UML Sequence Diagram

UML sequence diagrams

Sequence diagram: an “interaction diagram” that models scenarios executing in the system

perhaps

2

nd most used UML diagram (behind class diagram)

Relation of UML diagrams to other exercises:

CRC cards -> class diagram

Use cases -> sequence diagrams

One sequence diagram can show multiple scenarios (user stories)

2

Key parts of a sequence diag.
participant: an object or entity that acts in the sequence diagram
sequence diagram starts with an unattached “found message” arrow
message: communication between participant objects
the axes in a sequence diagram:
horizontal: which object/participant is acting
vertical: time (down -> forward in time)
3

Sequence diag. from use case
4

Representing objects
squares with object type, optionally preceded by object name and colon
write object’s name if it clarifies the diagram
object’s “life line” represented by dashed vert. line
5

Messages between objects
message (method call) indicated by horizontal arrow to other object
write message name and arguments above arrow
dashed arrow back indicates return
different arrowheads for normal / concurrent (asynchronous) methods
6

Lifetime of objects
creation: arrow with ‘new’ written above it
notice that an object created after the start of the scenario appears lower than the others
deletion: an X at bottom of object’s lifeline
Java doesn’t explicitly delete objects; they fall out of scope and are garbage-collected
7

Indicating method calls
activation: thick box over object’s life line; drawn when object’s method is on the stack
either that object is running its code, or it is on the stack waiting for another object’s method to finish
nest to indicate recursion
8

Activation
Nesting

Indicating selection and loops
frame: box around part of a sequence diagram to indicate selection or loop
if -> (opt) [condition]
if/else -> (alt) [condition], separated by horiz. dashed line
loop -> (loop) [condition or items to loop over]
9

[
balance
<>
0
]

opt

[
balance
< 100 . 00 ] [ balance >
=
100
.
00
]

alt

[
balance
< 0 ] loop linking sequence diagrams if one sequence diagram is too large or refers to another diagram, indicate it with either: an unfinished arrow and comment a "ref" frame that names the other diagram when would this occur in our system? 10 Example sequence diagram 11 Scenario (User Story)   A player rolls the dice and gets a 6. The player moves 6 cells. The player lands on a cell that is an un-owned property. The player’s turn is over. You begin to create a sequence diagram by writing a scenario and highlighting all the nouns in the scenario. The nouns generally become the objects that appear in the columns. For example, consider the following scenario. The unique nouns are circled. Each of these nouns is likely to become an object (though not all do, as you will see with the noun “turn”). [click] This figure shows a possible sequence diagram for this scenario. Conditional Logic If the player lands on a cell that is an un-owned property, the player’s turn is over. If the player lands on a cell that is owned, the player must pay rent to the owner of the property. Then, the player’s turn is over. Conditional logic may also be expressed in a sequence diagram as a guard. In this way, a sequence diagram can express a set of scenarios in a more general way. Consider this scenario and the sequence diagram in the figure that can be used for this scenario: A player rolls the dice and moves the number of cells indicated on the dice. [click] If the player lands on a cell that is an un-owned property, the player’s turn is over. [click] If the player lands on a cell that is owned, the player must pay rent to the owner of the property. Then, the player’s turn is over. You can use the “else” part of the sequence diagram to express what could be thought of as a second scenario in which the player lands on an owned property and has to pay rent. 13 (De)centralized system control What can you say about the control flow of each of the following systems? centralized? distributed? 14 Why not just code it? Sequence diagrams can be somewhat close to the code level. So why not just code up that algorithm rather than drawing it as a sequence diagram? 15 a good sequence diagram is still a bit above the level of the real code (not EVERY line of code is drawn on diagram) sequence diagrams are language-agnostic (can be implemented in many different languages non-coders can do sequence diagrams easier to do sequence diagrams as a team can see many objects/classes at a time on same page (visual bandwidth) Verify customer credit refCustomer Info Approved? [guard] [guard] [guard] [guard] [guard] [guard] [guard] [guard] Verify customer credit ref Customer Info Approved? sd Example loop StoreFrontCartInventory AddItem ReserveItem PlaceItemInOrder Checkout ProcessOrder ConfirmOrder [guard] [guard] [guard] [guard] [guard] [guard] [guard] [guard] sd Example StoreFront Cart Inventory loop AddItem ReserveItem PlaceItemInOrder Checkout ProcessOrder ConfirmOrder Player DiceCellProperty rollDice DiceValue(6) MoveCell(6) isOwnedProperty isOwnedProperty(False) rollDice DiceValue(6) MoveCell(6) isOwnedProperty isOwnedProperty(False) Player Dice Cell Property Player Dice CellProperty rollDice DiceValue(n) MoveCells(n) [isOwnedProperty] isOwnedProperty(False) isOwnedProperty(True,owner) Owner PayOwner [else] Player Dice Cell Property rollDice DiceValue(n) MoveCells(n) [isOwnedProperty] isOwnedProperty(False) isOwnedProperty(True,owner) Owner PayOwner [else]