Risk Analysis and Reduction

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.