Processes Purpose To define the physical structuring of a system. - PDF document

Chapter 11 Processes Purpose • To define the physical structuring of a system. Concepts • Process architecture: A system-execution structure composed of interdependent processes. • Processor: A piece of equipment that can execute a pro- gram. • Program component: A physical module of program code. • Active object: An object that has been assigned a pro- cess. Principles • Aim at an architecture without bottlenecks. • Distribute components on processors. • Coordinate resource sharing with active objects. Result • A deployment diagram showing processors with as- signed program components and active objects. The process architecture brings us closer to the system’s physical level. We focus on distribution and execution, and work with processes and objects as opposed to components and classes. We also deal with the physical devices that the system will be executed on and consider whether we need to coordi- nate shared resources. This process view complements the logical structur- ing expressed in the component architecture. The process activity is structured according to two levels of abstraction. The first is the overall level, where we define the distribution of program components on the available system processors. The second level deals with the processes that structure collaboration among the objects present during execution. The process activity is quickly complete if we are designing a stand-alone administrative system. However, the complexity of process-ar- chitecture design increases significantly for monitoring and control sys- 209

210 ________________________________________________________________Processes Off button «reads» : Dedicated processor On button «reads» User Accelerate «reads» interface button «reads» Coast «reads» button : Cruise control Resume button System «reads» Speed- Kernel interface ometer Brake pedal «reads» Clutch Car’s other «reads» pedal systems «reads» Gas pedal «affects» Throttle Figure 11.1: Deployment diagram for the Cruise Control System (Chapter 22) tems, embedded systems, or systems with significant interactions with oth- er systems. The process activity’s result is a deployment diagram that describes the distribution and collaboration of program components and active objects on processors, as Figure 11.1 shows. In addition, you might have more detailed specifications to coordinate resource sharing, as Figure 11.9 shows for the active “Cruise control” object in Figure 11.1. 11.1 System Processes The purpose of process architecture design is to structure execution on a physical level. This is emphasized in the following definition:

System Processes________________________________________________________ 211 Process architecture: A system-execution structure composed of interdependent processes. The basic unit for executing a system is the processor. We define this funda- mental concept as follows: Processor: A piece of equipment that can execute a program. An external device is a special kind of processor that cannot execute a pro- gram—at least not from our system’s point of view. Processors execute the components that arise from activity described in the previous chapter, as emphasized in this principle: Principle: Distribute components on processors. The process architecture must ensure a satisfactory system execution on the available processors, as expressed in the following principle: Principle: Aim at an architecture without bottlenecks. We can get far with the process architecture by simply designing each class and its solo operations. However, some systems are more complex because they involve concurrent processes that require coordination. A process is a collection of operations that are executed in a bounded and linked sequence. Thus, concurrent processes mean that operations from more than one such sequence are executed at the same time. Concurrency arises when a system is implemented on several proces- sors. For example, a bank administration system might be executed on local processors in each bank branch, as well as several central processors that share a database. Concurrency is also a key design issue, for example, when a mobile telephone is used to access services that are executed on other computers. Even if a system is based on one processor, several concurrent processes can share the single processor capacity. A running object-oriented system comprises a large and varying num- ber of objects. With a typical mobile telephone, there will be objects that represent all incoming and outgoing calls, as well as all address book en- tries. In addition, there will be objects with active operations that imple- ment certain monitoring functions. There will also be objects handling user- interface objects that might be present during execution, such as windows, panels, and icons. Finally, there will be objects handling the connection with the carrier’s transmission system. All in all, we have numerous objects with very different characteristics. Active objects are active during the system execution. A system’s pro- cesses and active objects are two sides of the same coin:

212 ________________________________________________________________Processes Class diagram and Identify shared component specifications resources Distribute program components Deployment diagram Select coordination mechanisms Explore distribution patterns Explore coordination patterns Figure 11.2: Subactivities in process-architecture design Active object: An object that has been assigned a process. The other kind of objects exist inside program components that constitute most of a system: Program component: A physical module of program code. No processes are assigned to program components. They are passive during execution, until one of their operations is called as part of a process execu- tion. And, once the operation’s execution is complete, the program compo- nents re-enter the passive state. Process-architecture design requires thorough knowledge of the techni- cal platform and facilities that are available for coordinating shared com- puter resources. In the process architecture, we handle this coordination task using active objects: Principle: Coordinate resource sharing with active objects. When we introduce such objects, we will select mechanisms that coordinate use of the resource in question. We can summarize the subactivities in process-architecture design as shown in Figure 11.2. We start by defining and distributing program com- ponents. In this process, we can use different distribution patterns. We then identify coordination needs by searching for resources that several process- es share. If we find such resources, we select coordination mechanisms, supported by a collection of patterns.