Ivan Marsic • Rutgers
University 80
to renting, and will spell out its condition subsequent to renting. For example, for the operations Unlock and Lock, the possible contracts are:
Operation
Unlock • set of valid keys known to the system is not empty
•
numOfTrials maxNumOfTrials
Preconditions
•
numOfTrials = 0
, for the first trial of the current user
•
numOfTrials = 0
, if the entered Key
∈ Valid keys
Postconditions
• current instance of the Key object is archived and destroyed The system should be fair, so each user should be allowed the same number of retries
maxNumOfTrials
. Thus, the precondition about the system for a new user is that
numOfTrials
starts at zero value. I already discussed the issue of detecting a new user and left it open, but let us ignore it for now. The postcondition for the system is that, after the current
user ends the interaction with the system,
numOfTrials
is reset to zero.
Operation
Lock
Preconditions
None that is, none worth mentioning •
lockStatus
= “
closed
”, and
Postconditions
•
lightStatus
remains unchanged see text for discussion
In the postconditions for Lock, we explicitly state that
lightStatus
remains unchanged since this issue may need further design attention before fully solved. For example, we may want to
somehow detect the last person leaving the home and turn off the light behind them. The operation postconditions specify the guarantees of what the system will do, given that the
actor fulfilled the preconditions for this operation. The postconditions must specify the outcomes for worst-case vs. average-case vs. best-case scenarios, if such are possible.
2.4 Design: Assigning Responsibilities
Analysis dealt with what is needed for our system; we determined how the customer interacts with the system to obtain services and what workers concepts need to be acquired to make this
possible. Analysis is in a way the acquisition phase of the enterprise establishment. Design, on the other hand, deals with organization, how the elements of the system work and interact. Therefore,
design is mainly focused on the dynamics of the system. Unlike analysis, where we deal with abstract concepts, here we deal with concrete software objects.
Chapter 2 • Object-Oriented Software Engineering
81
We already encountered system sequence diagrams in Section 2.2.4 above. As Figure 2-9 illustrates, in the design phase we are zooming-in inside the system and specifying how its
software objects interact to produce the behaviors observed by the actors.
Software designer’s key activity is assigning responsibilities to the acquired software objects. Figure 2-10 shows an example of responsibility assignment. Here the dilemma is, who should
invoke the method
setOpen
on the LockCtrl once the key validity is established? Although the Checker is the first to acquire the information about the key validity, we decide to assign the
responsibility to notify the LockCtrl to the Controller. This is because Controller would need to know this information anyway—to signal to the user the outcome of the key validity checking. In
this way we maintain the Checker focused on its specialty and avoid assigning too many responsibilities to it.
INTERACTION DIAGRAMS
select function“unlock
: System
User
«initiating actor» prompt for the key
enter key verify key
signal: valid key, lock open open the lock,
turn on the light
Timer
«offstage actor»
start duration“
checkKey sk := getNext
setOpentrue : Checker
: KeyStorage
val == null : setLittrue
alt val = null
[else]
ystem ystem
Controller : LockCtrl
System Sequence Diagram Design
Sequence Diagram
Figure 2-9: Designing object interactions: from system sequence diagrams to interaction diagrams. The magnifier glass symbolizes looking at interactions inside the system.
