Modeling System Workflows Requirements Analysis and Use Cases

Ivan Marsic • Rutgers University 74 Idea Disciplined development Product SOFTWARE ENGINEERING

2.2.5 Risk Analysis and Reduction

Identifying and preempting the serious risks that will be faced by the system is important for any software system, not only for the ones that work in critical settings, such as hospitals, etc. Potential risks depend on the environment in which the system is to be used. The root causes and potential consequences of the risks should be analyzed, and reduction or elimination strategies devised. Some risks are intolerable while others may be acceptable and should be reduced only if economically viable. Between these extremes are risks that have to be tolerated only because their reduction is impractical or grossly expensive. In such cases the probability of an accident arising because of the hazard should be made as low as reasonably practical ALARP. Risk Identification Risk Type Risk Reduction Strategy Lock left open when it should be closed Intolerable Auto-close after x minutes Lock does not open faulty mechanism ALARP Allow physical key use as alternative To address the intolerable risk, we can design an automatic locking system which observes the lock and auto-closes it after x minutes elapses. This system should be stand-alone, so its failure probability is independent of the main system. For example, it could run in a different runtime environment, such as separate Java virtual machines, or even on an independent hardware. To ensure fault tolerance, a stand-alone system should monitor the state-variable values and prohibit the values out of the safe range, e.g., by overwriting the illegal value. Ideally, a different backup system should be designed for each state variable. This mechanism can work even if it is unknown which part of the main program is faulty and causes the illegal value to occur. A positive aspect of a stand-alone, one-task-only system is its simplicity and lack of dependencies, inherent in the main system, which makes it resilient; a negative aspect is that the lack of dependencies makes it myopic, not much aware of its environment and unable to respond in sophisticated manner.

2.2.6 Why Software Engineering Is Difficult 1

A key reason, probably the most important one, is that we usually know only approximately what we are to do. But, a general understanding of the problem is not enough for success. We must know exactly what to do because programming does not admit vagueness—it is a very explicit and precise activity. History shows that projects succeed more often when requirements are well managed. Requirements provide the basis for agreement with the users and the customer, and they serve as the foundation for the work of the development team. This means that requirements provide a vital linkage to ensure that teams deliver systems that solve real business problems. When faced with a difficult decision, it is a good idea to ask the customer for help. After all, the customer can judge best what solution will work best for them and they will easier accept compromises if they were involved in making them. However, this is not always simple. Consider the projects described in Section 1.5 above. Asking the customer works fine in the restaurant Chapter 2 • Object-Oriented Software Engineering 75 automation project Section 1.5.2. Even in the virtual biology lab Section 1.5.1, we can interview a biology course instructor to help clarifying the important aspects of cell biology. However, who is your customer in the cases of traffic monitoring Section 1.5.3 and stock investment fantasy league Section 1.5.4? As discussed in Section 1.5.3, we are not even sure whom the traffic monitoring system should be targeted to. More about requirements engineering and system specification can be found in Chapter 3 below.

2.3 Analysis: Building the Domain Model

In Section 1.2.3 above, I likened the object-oriented analysis to setting up an enterprise. The analysis phase is concerned with the “ what ” aspect—identifying what workers we need to hire and what things to acquire. The design, to be considered later, deals with the “ how ” aspect—how these workers interact with each other and with the things at their workplace to accomplish their share in the process of fulfilling a service request. Of course, as any manager would tell you, it is difficult to make a clear boundary between the “what” and the “how.” We should not be purists about this—the distinction is primarily to indicate where the emphasis should be. We already encountered concepts and their relations in Section 1.3 above when describing concept maps as a diagrammatic representation of knowledge about problem domains. Domain model described here is similar to concept map, although somewhat more complex, as will become apparent soon.

2.3.1 Identifying Concepts

Back to our setting-up-an-enterprise approach, we need to hire the workers with appropriate expertise and acquire things they will work with. To announce the openings under a classifieds section, we start by listing the positions or, better, responsibilities, for which we are hiring. We identify the responsibilities by examining the use case scenarios and system sequence diagrams. For example, we need a worker to verify whether or not the key entered by the user is valid, so we title this position KeyChecker. We also need a worker to know the collection of valid keys, so we create an opening for KeyStorage. Further, to operate the lock and the lightswitch, we come up with LockOperator and LightOperator positions, respectively. Notice that concept name is always a noun phrase. In building the domain model, a useful strategy is to start from the “periphery” or “boundary” of the system, as illustrated in Figure 2-6. That is, we start by assigning concepts that handle interactions between the actors and the system. Each actor interacts with at least one boundary object. The boundary object collects the information from the actor and translates it into a form that can be used by “internal” objects. As well, the boundary object may translate the information in the other direction, from “internal” objects to a form suitable for the actor. Organizations are often fronted by a point-of-contact. A common pattern is to have a specialized worker to take orders from the clients and orchestrate the workings of the workers inside the 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.