Chapter 2 • Object-Oriented Software Engineering
77
UML does not have designated symbols for domain concepts, so it is usual to adopt the symbols that are used for software classes. I added a smiley face or a document symbol to distinguish
“worker” vs. “thing” concepts. Workers get assigned mainly doing responsibilities, while things get assigned mainly knowing responsibilities. This labeling serves only as a “scaffolding,” to aid
the analyst in the process of identifying concepts. The distinction may not always be clear cut, since some concepts may combine both knowing- and doing types of responsibilities. In such
cases, the concepts should be left unlabeled. This is the case for KeycodeEntry and StatusDisplay in Figure 2-7. Like a real-world scaffolding, which is discarded once construction is completed,
this scaffolding is also temporary in nature.
Another useful kind of scaffolding is classifying concepts into the following three categories: «boundary», «control», and «entity». This is also shown in Figure 2-7. At first, Key may be
considered a «boundary» since keys are exchanged between the actors and the system. On the other hand, keys are also stored in KeyStorage. This particular concept corresponds to neither one
of those, since it contains other information, such as timestamp and the door identifier. Only pass- codes identifying the actors are exchanged between the actors and the system concept:
KeycodeEntry and this information is transferred to the Key concept.
It is worth noticing at this point how an artifact from one phase directly feeds into the subsequent phase. We have use case scenarios feed into the system sequence diagrams, which in turn feed
into the domain model. This is a critical property of a good development method process, since the design elaboration progresses systematically, without great leaps that are difficult to grasp
andor follow.
Domain model is similar to a concept map described in Section 1.3 above—it also represents concepts and their relations, here called associations—but domain model is a bit more complex. It
can indicate the concept’s stereotype as well as its attributes described below.
«control» Controller
«entity» Key
userIdentityCode timestamp
doorLocation
«boundary» LockOperator
lockStatus «boundary»
LightOperator lightStatus
«boundary» LightOperator
lightStatus «entity»
KeyChecker numOfTrials
maxNumOfTrials «entity»
KeyStorage
conveys R
equ es
ts obtains
notifiesKeyValidity ve
rifi es
retri eves
Vali dKe
ys
notifiesKeyValidity “Reading direction arrow.” Has no
meaning; it only facilitates reading the association label, and is often left out.
“Reading direction arrow.” Has no meaning; it only facilitates reading the
association label, and is often left out. Symbolizes
“worker”-type concept.
«boundary» KeycodeEntry
«boundary» StatusDisplay
Resident
Symbolizes “thing”-type
concept. Symbolizes
“thing”-type concept.
LockDevice
LightSwitch
Association name
Figure 2-7: Domain model for the case study 1, home access control.
Ivan Marsic • Rutgers
University 78
Notice that we construct a single domain model for the whole system. The domain model is obtained by examining different use case scenarios, but they all end up contributing concepts to
the single domain model.
2.3.2 Concept Associations and Attributes
Associations
Figure 2-7 also shows the associations between the concepts, represented as lines connecting the concepts. Each line also has the name of the association and sometimes an optional “reading
direction arrow” is shown as ►. The labels on the association links do not signify the function
calls; you could think of these as just indicating that there is some collaboration anticipated between the linked concepts. It is as if to know whether person X and person Y collaborate, so
they can be seated in adjacent cubiclesoffices. Similarly, if objects are associated, they logically belong to the same “package.”
The reader should keep in mind that it is more important to identify the domain concepts than their associations and attributes, described below. Every concept that the designer can discover
should be mentioned. Conversely, for an association or attribute, in order to be shown it should pass the “does it need to be mentioned?” test. If the association in question is obvious, it should
be omitted from the domain model. For example, in Figure 2-7, the association
〈 Controller– obtains–Key
〉 is fairly redundant. Several other associations could as well be omitted, since the reader can easily infer them, and this should be done particularly in schematics that are about to
become cluttered. Remember, clarity should be preferred to accurateness, and, if the designer is not sure, some of these can be mentioned in the text accompanying the schematic, rather than
drawn in the schematic itself.
Attributes
The domain model may also include concept attributes, as is for example shown in Figure 2-7. Example attributes are
lockStatus
with valid values “
open
” and “
closed
” and
lightStatus
values: “
unlit
” “
lit
”, where the respective operators record the current state of the objects they operate.
«boundary» LockOperator
«boundary» HouseholdDeviceOperator
deviceStatus
«boundary» AlarmOperator
«boundary» LightOperator
Figure 2-8: Generalization of concepts in Figure 2-7. HouseholdDeviceOperator is a conceptual superclass obtained by identifying commonality among the concepts that operate
different household devices.
Chapter 2 • Object-Oriented Software Engineering
79
Another possible candidate attribute is
numOfKeys
in the KeyStorage. However, this is a kind of trivial attribute not worth mentioning, since it is self-evident that the storage should know how
many keys it holds inside. An attribute
numOfTrials
counts the number of failed trials for the user before sounding the alarm bell, to tolerate inadvertent errors when entering the key code. In addition, there should be
defined the
maxNumOfTrials
constant. At issue here is which concept should possess these attributes? Since a correct key is needed to identify the user, the system cannot track a user over
time if it does not know user’s identity a chicken and egg problem. One option is to introduce real-world constraints, such as temporal continuity, which can be stated as follows. It is unlikely
that a different user would attempt to open the lock within a short period of time. Thus, all attempts within, say, five minutes can be ascribed to the same user
10
. For this we need to introduce an additional attribute
maxTrialPeriod
or, alternatively, we can specify the maximum interval between two consecutive trials,
maxInterTrialInterval
. The knowledge or expertise required for the attempts-counting worker comprises the knowledge
of elapsed time and the validity of the last key typed in within a time window. The responsibilities of this worker are:
1. If
numOfTrials
≥
maxNumOfTrials
, sound the alarm bell and reset
numOfTrials = 0
2. Reset
numOfTrials = 0
after a specified amount of time if the user discontinues the attempts before reaching
maxNumOfTrials
3. Reset
numOfTrials = 0
after a valid key is presented A likely candidate concept to contain these attributes is the KeyChecker, since it is the first to
know the validity of a presented key. However, it may be argued that instead they should have been inserted into Controller, or a separate worker may need to be introduced only to handle this
task. This issue will be further discussed below when we introduce the AlarmCtrl concept.
As already said, during the analysis we should make every effort to stay with what needs to be done and avoid considering how things are done. Unfortunately, as seen above, this is not always
possible. The requirement of tolerating inadvertent typing errors has led us into considerable design detail and, worse, we are now committed to a specific technical solution of the problem.
2.3.3 Contracts: Preconditions and Postconditions
Contracts express any important conditions about the attributes in the domain model. In addition to attributes, contract may include facts about forming or breaking relations between concepts,
and the time-points at which instances of concepts are created or destroyed. You can think of a software contract as equivalent to a rental contract, which spells out the condition of an item prior
10
Of course, this is only an approximation. We could imagine, for instance, the following scenario. An intruder makes numOfTrials = maxNumOfTrials - 1 failed attempts at opening the lock. At
this time, a tenant arrives and the intruder sneaks away unnoticed. If the tenant makes a mistake on the first attempt, the alarm will be activated, and the tenant might assume that the system is malfunctioning.
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.