Task Descriptor: Refine System Processes
This task defines a process architecture for the system.
Based on Method Task:  Refine System Processes
Relationships
Steps
Review changes

The System Architect is prompted to perform this task by any significant change in the system's environment (reflected in the system context, the top-level collaboration between the system and its actors), refactoring during Task: System Operation Design, or the System Architect's own refinements made in Task: Refine System Deployment Model and Task: Refine System Structure. The System Architect examines these changes to determine what effect, if any, they have on the system-level processes. For example, if additional interfaces to the system's environment are to be supported, perhaps additional active (boundary) classes are needed.

Refactor/augment processes

The assumption is that subsystems, by default, can operate autonomously and concurrently with other subsystems (that is, they encapsulate one or more independent loci of control). Thus, it is a design decision whether additional processes (active classes) that are not encapsulated in subsystems are defined at this level. For example, whether active (boundary) classes are needed to drive and respond to external interfaces, or whether active control classes are needed to coordinate the actions of subsystems, or whether, at this level only subsystems appear. A rule of thumb is that there be at least one thread of control within the system, for each interface offered by a system (or subsystem), but these threads of control might themselves be encapsulated (within subsystems). Processes (and associated threads) are rooted in active classes; and instances of these (as active objects), not encapsulated in subsystems, can appear in interaction diagrams with subsystem instances, as shown below.

Interaction diagram showing subsystem instances

Note that the active classes Operator Keyboard, Operator Display and Printer, Laser Scanner and Magnetic Stripe Reader could be encapsulated within the subsystem Point-of-Sale Control, exposing these at the system level could be driven, for example, by their perceived importance, deployment issues, or the need to use them in some other application (which would indicate that the active classes are not simply "dumb" device drivers).

Just as interesting as the existence of an active object and whether particular subsystems are, for some interactions at least, passive, is the sequence or path of a process (or thread). An invoked operation can, in turn, invoke others (in other subsystems) using the same process, and possible delays (waiting for resources, for example) might be critically important to the System Architect, if processes have deadlines to meet. Repartitioning the subsystems might lead the System Architect to reconsider the process structure.

Capture updated Process viewpoint in System Architecture Document

Decisions made in this task are captured in the System Analysis Model (if this is separately maintained) and System Design Model; those aspects which the System Architect considers to be significant are also recorded in the Work Product: System Architecture Document (in this case, as part of the Process viewpoint).

Evaluate the results

The effectiveness of proposed solutions need to be reviewed with the stakeholders and the development team to ensure that all concurrent processing requirements and constraints (meeting deadlines, responsiveness and throughput, for example) are satisfied. Techniques such as simulation and prototyping can be used to provide more objective demonstrations of the adequacy of the design(s).


Properties
Multiple Occurrences
Event-Driven
Ongoing
Optional
Planned
Repeatable