Identifying Concepts Analysis: Building the Domain Model

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.