Why Software Engineering Is Difficult 1
Ivan Marsic • Rutgers
University 76
system. This type of object is known as Controller. For a complex system, each use case or a logical group of use cases may be assigned a different Controller object.
When identifying positions, remember that no task is too small—if it needs to be done, it must be mentioned explicitly and somebody should be given the task responsibility. Table 2-2 lists the
responsibilities and the worker titles concept names to whom the responsibilities are assigned. In this case, it happens that a single responsibility is assigned to a single worker, but this is not
necessarily the case. Complex responsibilities may be assigned to multiple workers and vice versa a single worker may be assigned multiple simple responsibilities. Further discussion of this issue
is available in the solution of Problem 2.12 below.
Table 2-2: Responsibility descriptions for the home access case study used to identify the concepts for the domain model. Types “D” and “K” denote doing vs. knowing
responsibilities, respectively.
Responsibility Description Typ Concept Name
Coordinate actions of all concepts associated with a use case, a logical grouping of use cases, or the entire system and delegate the work to other
concepts. D Controller
Container for user’s authentication data, such as pass-code, timestamp, door identification, etc.
K Key Verify whether or not the key-code entered by the user is valid.
D KeyChecker Container for the collection of valid keys associated with doors and users.
K KeyStorage Operate the lock device to openclose positions.
D LockOperator Operate the light switch to turn the light onoff.
D LightOperator Operate the alarm bell to signal possible break-ins.
D AlarmOperator Log all interactions with the system in persistent storage.
D Logger Based on Table 2-2 we draw a draft domain model for our case-study 1 in Figure 2-7. During
analysis, objects are used only to represent possible system state; no effort is made to describe how they behave. It is the task of design Section 2.4 below to determine how the behavior of the
system is to be realized in terms of behavior of objects. For this reason, objects at analysis time have no methodsoperations as seen in Figure 2-7.
Actor A
Actor B Actor D
Actor C
Boundary concepts
Step 1: Identifying the boundary concepts
Actor A
Actor B Actor C
Step 2: Identifying the internal concepts
Actor D
Concept 1 Concept 1
Concept 2 Concept 2
Internal concepts
Concept 2 Concept 2
Concept 3 Concept 3
Concept 4 Concept 4
Concept 1 Concept 1
Concept 3 Concept 3
Concept 5 Concept 5
Concept 4 Concept 4
Concept 6 Concept 6
Figure 2-6: A useful strategy for building a domain model is to start with the “boundary” concepts that interact directly with the actors.
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.