6.4 Operational Behavior

Our analysis of architecture has until now focused on form and function. But function is a somewhat quasi-static view of a system. Function is more about what the system can do than about what actually happens when the system runs. The operational or run time environment is more dynamic; things in the system happen in certain sequences, and the system interacts dynamically with surrounding systems and people. It is the difference between saying that an ATM can dispense money (its function) and listing, in order, all the steps necessary to actually get money out of an ATM (its operational behavior). In this section, we will examine three aspects of operational behavior: the operator, behavior, and operational cost.

Operator

The operator is the person who will use the system. In some cases (such as a riding a bicycle or playing a video game), the operator is so important that the system simply will not operate without his or her active involvement. For other products, the operator exercises supervisory control over operations, such as changing the channel on a television. All systems must accommodate humans any time they touch it, which is normally informed by human factors and industrial design. The human operator is so important that we will consider the human operator a product/system attribute.

In our simple systems, the pump and the bubblesort code have an operator at some level of supervision. Someone turns the pump on and off, or at least supervises the control software that does so. Code execution does not directly involve the operator, but someone ran the routine that called bubblesort.

Because these systems are not rich examples of operator interaction, we will introduce one more simple system: the two-levered corkscrew, commonly called a butterfly corkscrew (Figure 6.13), that is used to remove the cork from a wine bottle. The operator is essential to the operation of this device. The operator places the device on top of the bottle, twists the screw handle, pushes down the levers, and then removes the cork from the screw.

A butterfly corkscrew is an example of a simple system.

Figure 6.13  Butterfly corkscrew.

(Source: Ekostsov/Fotolia)

Behavior

Behavior is the sequence of functions (and associated changes in state) that form executes in order to deliver value, and it is a product attribute. It is important to represent the sequence of events that contribute to external function. We will distinguish between the operations sequence and the dynamic behavior, or timing, of the system. Timing includes specific reference to clock time, whereas sequence is based on relationships among actions.

The operations sequence is the total progression of actions or processes that the system undergoes. Sequence will include actions associated with the primary and secondary externally delivered function, as well as with supporting and interfacing functions. From another perspective, sequence is the array of changes in state of the operands of the system. Sequence includes not only what step follows what, but also whether there are overlaps. Sometimes steps must follow in sequence (you must start the car before driving the car). Sometimes sequence is uncertain or optional (you can adjust the mirrors before or after starting the car).

There are various ways to represent the operating sequence of the corkscrew as it engages the cork, but the simplest is the sequence line diagram at the right in Figure 6.14, which indicates the starting and ending states for the processes. This is a variant of the SysML sequence diagram.

A diagram has a corkscrew, cork, and bottle operations in a sequence.

Figure 6.14  Corkscrew, cork, and bottle operations shown with a sequence diagram.

Even in this simple case, we immediately realize that the cork is not the only important object involved; the bottle is being restrained, and the corkscrew is being used. A more complete representation of the corkscrew sequence is shown by the other two sequences of Figure 6.14. Processes are represented on the right side of the line, and states are shown to the left of the line. In particular, the corkscrew undergoes several processes and state changes to achieve the desired value function. As indicated for the corkscrew (far right), these start from storage and end up in maintenance (cleaning) as will be discussed in Chapter 8.

There are a variety of other diagrams that can be used to represent the states and processes of the system, and their conditional interaction. These include state control diagrams (used in control theory) and control flow diagrams (such as functional flow block diagrams). In SysML’s, activity diagrams and state machine diagrams are used. OPM uses these diagrams or an animated simulation of tokens passing through the system to represent sequence. [3]

In contrast to sequence, dynamic behavior is the detailed timing of steps, start time, ­duration, overlap, and so on. Such behavior is important in real-time systems. For example, in applying the brakes of a car there would be a sequence, but there is also a timing constraint: The brakes must deploy within some number of milliseconds of pedal movement. Timing is also important for systems closely linked to clock and calendar, such as passenger train operations.

The issues that typically arise in dynamic behavior include start-up transients and latency of information or elements in a system. One of the most vexing aspects of real-time systems is timing constraints associated with multiple parallel sequences or threads. Multi-thread issues are not unique to software; a car can skid while turning, for example. In real-time software, multi-thread issues are particularly complex because of indeterminacies in timing in interactions with other applications or the operating system, including interrupts. Dynamic behavior (including multi-threads, non-synchronous events, and non-deterministic events) is, in our experience, best represented in the specific sub-domain of the architecture and is left to the architect to explore. The architect is advised to learn about these issues if they are relevant to the architecture of his or her product/system.

Operations Cost

Forecasting operations cost is frequently a consideration when architecting systems. The ­operational behavior, the operational concept (Chapter 7), and the details of system operations (Chapter 8) all influence the operational costs. Operational cost is typically expressed per event, per day, or in terms of usage (per mile in a car). Like operational behavior and operator, operational cost is a product/system attribute.

Operations cost is built up of a number of components. Chief among them is often the cost of the operator and other personnel needed to run the system. Consumables are another major category of operational cost. Indirect costs of operations include maintenance, nominal upgrades, and insurance.

The architect must carefully consider architectural decisions that affect the operational costs, because these costs are an important factor in the long-term competitiveness of the product/system.

In summary:

  • Every system has an operator, whether that operator is closely involved in the operation of the system or plays a more supervisory role. The interface to the operator is a key part of the architecture.

  • Behavior is the sequence of functions necessary for the value to emerge from the system. Behavior includes sequence, the execution of series of processes, and associated changes in states. Dynamic behavior or timing specifically references relative or absolute time in the operations.

  • Operating cost is one of the key drivers in eventual system competitiveness. It is built up of direct costs (operational personnel, consumables) and indirect costs (maintenance, upgrades, and the like).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.226.165.70