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.