Operational Models

Cradle provides the Process Flow Diagram (PFD) to present an operational view of system behaviour. The PFD is similar to the extended Function Flow Block Diagram (eFFBD) in that it is a time-sequenced view of elements, but its purpose and subject are different. Used in combination, the PFD and eFFBD can be used to build operational and functional models that are complementary.

Background

An eFFBD is used to show a time-sequenced view of system functions, and the input and output data for each. A timeline provides ordering for the functions. The timeline can contain nodes, which can split the timeline:

By a pair of OR nodes, to split the timeline into a number of alternate branches only one of which will be followed at runtime

By a pair of AND nodes, to split the timeline into a number of branches all of which are processed at runtime in parallel with a synchronisation point at the end AND node of the pair

By a pair of I nodes, to provide an iteration (loop) for the timeline with three places to control the loop:

At the start of the loop

At the end of the loop

In the body of the loop

By a pair of R nodes, to provide a section of the timeline that can be replicated, each of the replicants being controlled by a function on the Coordination branch

An example eFFBD that illustrates all of the symbols provided by this diagram style is:

The Process Flow Diagram has all of the timeline characteristics of the eFFBD, but it shows a time-sequenced view of operations, instead of functions.

The Process Flow Diagram

An example PFD that illustrates all of the symbols provided by the diagram type is:

As you can see, the PFD has a timeline and so is very similar to the eFFBD. But this timeline does not contain functions; it contains an operational sequence that connects operations with a timeline to accomplish an interaction between the system and its environment (users and other systems) to accomplish a goal.

An operation represents work to be done, but the work done in an operation is expressed in the end user’s terms and its content is directly related to achieving the goal of the operation sequence. There are four types of operation:

1. Operations are general purpose operations. They can be decomposed into lower-level PFDs and will ultimately be allocated to one of the other types (discussed later). They are shown as plain rectangles and described in operation specifications.
2. System operations represent work done by the system, and are shown by this symbol:



They are described in an operation specification , and can also have a reference to another specification, typically a function specification , as one method of linking the operational model to the functional model. Any such reference specification appears in the top box in the system operation symbol. Using this mechanism creates a pseudo cross reference from the system operation’s operation specification to the function specification that it references, and vice versa. These pseudo cross references are available through the Diagram Editor and in WorkBench views.

3. User operations represent work done by users of the system:



They are also described in an operation specification and can be contained within an environment symbol to express which user is performing the operation.

4. Agent operations represent work done by systems linked to our system:

They are described in an operation specification and can be contained within an environment symbol to express which external system is performing the operation.

So that you can be explicit about which part of the environment is performing each user or agent operation, you can embed these symbols inside environment symbols, such as:

These environment symbols are described environment definitions, and are identified by their name. These definitions are the same as those associated with:

• Environment (terminators) on Data Flow Diagrams (DFDs)
• Actors in UML Use Case Diagrams (UCDs)
• Actors in UML Sequence Diagrams (SQDs)
• Actors in UML Collaboration Diagrams (CODs)
• Environment symbols on extended Function Flow Block Diagrams (eFFBDs)
• Environment symbols on Physical Architecture Diagrams (PADs)
• Environment symbols on Architecture Interconnect Diagrams (AIDs)
• Environment symbols on Software Architecture Diagrams (SADs)

Operations and Functions

In an eFFBD, a function is a unit of work to be performed by the system being considered. That is, a function is inside the system boundary, and the work it performs is work that the system has to do itself. This is work that will ultimately be performed by a piece of software, electronics, pneumatics, mechanics etc. that is a part of the system. Any work done in the system’s environment is not shown explicitly in the eFFBD. The eFFBD shows the data sent to, and received from, the environment, but the work done in the environment is not shown.

The distinction between a PFD and eFFBD is perhaps subtle, but important. PFDs show operations, whereas eFFBDs show functions. Operations are work that has to be done in an operational sequence, work that must be accomplished in order for an interaction between the system and its environment to be completed. Functions are work to be done explicitly in the system. Therefore, operations are more general than functions, and an operational sequence contains work that will be performed both within the system and outside it.

But there is a further, more subtle, distinction. An operation is work to be done to achieve the goal of the operational sequence. It is expressed in end-user terms, such as a spacecraft achieving Low Earth Orbit, or a missile striking a target, or a telecoms network routing a call from one subscriber to another. In contrast, a function is work to be done by the system to accomplish something internal to the system. It is expressed in system terms that may relate only indirectly to what the end user regards as being important.

Thus, just as there is a distinction between user and system requirements, so there is exactly the same kind of distinction between an operation and a function.

Operations have to be allocated, and they can be allocated to:

1. The system being considered, when they are called system operations
2. The human users of the system being considered, when they are called user operations
3. Another system that interacts with the system being considered, when they are called agent operations

Therefore, the operations in a PFD show work that may be inside, or outside, the system boundary.

If the operation has not been allocated to one of the above three types, then the location of the operation has not been decided. If the operation has been described as a user operation or an agent operation, then it represents work to be done outside the system boundary, in the system’s environment. Only if the operation has been described by a system operation is it clear that the operation represents work that the system itself will have to provide.

Operational Sequences

A top-level PFD contains a single operational sequence that represents a single interaction between the system and its environment. Initially, all operations in the PFD will be identified in the timeline and verified as complete and correct. The operational sequence may be composed into lower-level PFDs as needed.

Either as a result of this decomposition, or simply at a later stage in the analysis, each of the operations will be allocated to a system operation, agent operation or user operation. If a hierarchy of PFDs has been produced, it is likely that this allocation will occur in these lower levels PFDs.

Therefore, in a PFD hierarchy, the top level will represent a high-level view of the interaction and the lower-level PFDs will contain the refinement of the operational sequence in this interaction, and will allocate the operations in the interaction to the system, its users, or the agents (other systems) with which it interacts.

Relationship to Use Cases

The operational sequence shown in a PFD can correspond to a use case. If the process used in the project calls for use cases, then each use case could be developed in an operational sequence in a PFD. This represents an alternative to a UML sequence diagram, as discussed below.

The advantage of using a PFD rather than an eFFBD to describe a use case is primarily that the involvement of the environment in the sequence can be shown. This advantage is very significant, otherwise the role of users and external systems in the time-sequenced content of the use case cannot be clearly shown.

Relationship to Requirements

By allowing the operations of the system, its users and agents to be shown, an operational sequence makes a PFD a natural form in which to model functional requirements.

Inevitably, and correctly, these requirements will be expressed from the user’s perspective. They will be expressed in terms of the externally observable behaviour that is required from the system. As such, they are written from the stakeholders’ perspective (here stakeholder in requirements and user in user operations are being used interchangeably).

Such functional requirements will express what the system is to do in response to actions from the user, and then what the user is permitted to do following these system responses. Each of these requirements’ clauses can be cross referenced to a corresponding operation in the operational sequence.

Since the operational sequence contains the system, its users and agents, there will always be an operation in a PFD to which any and every functional requirement can be linked.

This is not true for eFFBDs (or any other functional notation such as IDEF0 or DFDs), nor for elements of UML models, all of which concentrate on the system being developed.

A Family of Models

The unique nature of PFDs’ operational sequences allows projects to create a family of models in response to the requirements hierarchy, which can be simply summarised as:

• User requirements are satisfied by system requirements
• Key user requirements are satisfied by the use cases
• Functional system requirements are satisfied by operations
• Use cases are satisfied by operations
• Operations are provided by functions
• Functions are allocated to the architecture
• Non-functional system requirements are allocated to the architecture

In these statements, clarified by, satisfied by, provided by and allocated to, are the types of cross reference used in the Cradle database to link these collections of items together:

In the above statements, we have considered the different treatment of functional and non-functional system requirements. You may not have this distinction in your processes. We have also proposed the use of use cases to graphically depict the key (high-level) operational (or functional) user requirements. Again, your process might not have this distinction for key user requirements (KURs).

Nonetheless, the use of operational and functional models as distinct representations of the behaviour required by the system is invaluable, since it allows you to fully develop the details of the behavioural interaction of the system with its environment. This ensures that the details of the functions that you create in the functional model (when you consider only the system itself) will much more complete and will be much easier to produce.

Alternatives

There are alternative approaches for representing interactions across the system boundary:

Events are the individual units of an interaction. Each event has a stimulus, a response and a list of before events (the events that must have occurred before this event can occur). For convenience, events are normally placed into groups (using the Group attribute) so that the events that relate to an individual interaction can be seen more easily. Events have time sequencing, but are not graphical, do not show input or output data, and exclusively describe the system’s response to external stimuli.

UML sequence diagrams allow a description of the sequence of interactions across the system boundary, that is, between the system and its environment. They are graphical, but do not describe the work that is done, but merely the exchange of messages, which are similar to invoking units of work with associated parameters.

Consequently, PFDs are the preferred method for depicting the interactions across the system boundary when work and input/output data is to be shown graphically in a manner that can be directly traced to the requirements and later models for full lifecycle traceability.