Behaviour Diagram

Purpose

Behaviour Diagrams (BDs) are the Cradle implementation of behaviour-orientated functional descriptions. These diagrams are sometimes referred to as Function Flow Block Diagrams (FFBDs). BDs are used to illustrate the behaviour of the system as a time sequenced set of functions. While DFDs show what the system is, BDs show what it does and when. BDs and DFDs can be thought of as alternative views of the interactions between the same set of system functions.

Example:

Description

BDs show the interaction between system functions by distributing them along a timeline. A timeline consists of a set of directed arrows, connecting operations and nodes to depict a processing sequence. The timeline effectively constitutes a flow of control. No data flows along the timeline, it simply indicates the order in which functions are processed. The timeline may branch into two or more parts at a node, described below, which must subsequently converge. A BD must have a single start point for its timeline and a single end point.

Individual parts of the timeline may be named or unnamed. Named arrows are used to label alternate time line branches, either to represent alternate exit conditions from a function (such as success or failure), or in relation to the action of nodes in the control flow.

Nodes are used to cause the timeline to split into two or more branches. The processing along each branch is sequential unless that branch also contains nodes which instigate concurrent or other processing.

Nodes do not have a definition: their sole purpose is to define the manner in which BD functions are connected, and their behaviour over time. Some of the nodes will, however, have a label, used either to specify conditional processing, or to link associated nodes or BDs together.

The nodes are intended to be used to create sequential, conditional, concurrent, replicative and iterative processing constructs.

As DFDs and BDs both show functions and data, there are inevitably similarities between them. DFDs are, by definition, inherently concurrent in that all functions without prompts (control flows such as E/D and T or TRIGGER) are concurrently executable. The order in which they execute is determined by:

• The order in which data and/or control signals arrive on diagram input flows
• The states and transition logic in the State Transition Diagram (STD) of any control processes on the diagram
• The natural order imposed by self-evident truths, such as: a function cannot execute without its input data, that typically comes from the output of another function, or a store filled by another function

However, the intrinsic benefit of the BD notation is the way that sequence, iteration, and concurrency are shown on the diagram by the arrangement of functions along a (possibly complex) timeline.

BDs do not have an explicit concept of state as provided by the STD, nor do they provide the same degree of detail in the logic for transiting between states. The DFD and STD combination therefore offers greater expressive power in this respect.

Cradle provides the BD in both Essential and Implementation Models from two primary perspectives:

• To allow functionality to be represented completely in terms of BDs: this approach is practicable provided that control signals and states are not significant in the system
• To allow an alternate view of functionality to be provided by allowing both DFD and BD representations of the system

Where DFDs model the system as it is, BDs model what the system does.

Relationship with Other Diagrams

Within a hierarchy of DFDs and possibly Function Block Diagrams (FBDs), BDs may be used to provide detailed information on order-critical parts of the system. If much of the system relies on time-sequenced events, the complete diagram hierarchy could be made up of BDs. In other cases, a particular sub-system, such as an electronic component, may be the only time order-critical section.

There is considerable flexibility in the choice of the overall structure of a diagram hierarchy for a system, and this structure should be determined on the basis of the nature of the particular system involved.

Strengths

BDs can clearly show time sequencing, including parallelism, iteration, alternation (optionality) and replication.

Weaknesses

Method of representing data exchanges is clumsy and occupies a lot of drawing area. 3SL’s extension to directly naming trigger data flows reduces this clutter somewhat.

No method of representing data exchange with the environment. 3SL’s extension does add this capability with the means to show parts of the environment (as terminators).

No method of distinguishing between data and control.

No method to clearly show states and modes.

Recommended Uses

• To show functionality and data exchange when time sequencing is of the essence or interest
• To show functionality where there is data manipulation and passage
• To show functionality where there is buffered data.

Diagram Conversions

None.

Characteristics
APPEARS IN MODELS: Essential and Implementation
NUMBERING: Numbered as are BD symbols that can be expanded. e.g. Objects on BD1 will have numbers 1.1, 1.2, 1.3 etc which are the numbers of the BDs into which they may be expanded.
HIERARCHICAL: Yes

Linkage:

Symbol	Name	Description	Definition	Expansion
	Comment	Makes a note anywhere in the diagram. Always surrounded by * characters.	None	None
	Time function	A series of functions occurring over time in a predefined order. A Time Function may contain lower level Time Functions in a lower level BD.	PSpec	BD, DFD
	Shared function	A function that may be reused in this, or other, BD and therefore considered to be off-the-shelf functionality. All uses of the shared function X on any BD, reference the same definition and/or BD for X .	PSpec	BD
	Discrete item	An item at the lowest level of detail of interest.	DD Entry	None
	Time line start	Represents the start of a time sequence.	None	None
	Time line end	Represents the end of a time sequence.	None	None
	Parallel node	Acts as the starting point for a set of concurrent operations. Has two or more outgoing branches, none with a label. The set of operations distributed along each branch are, collectively, considered to occur in parallel with the operations along all other branches. Within a branch, the processing of individual operations is sequential, unless that branch itself contains other nodes. All branches converge at a matching Parallel Node. The processing along all branches is considered to be synchronised by this node, so that the processing along some branches may be held until the processing along other branches has completed.	None	None
	Selection node	Acts an exclusive-OR operation. Has two or more outgoing Time Line branches, each with a label. The node effectively routes the flow of control along one of these outgoing branches, depending on the exit condition of the upstream operation. All the Time Line branches must subsequently converge at a matching destination Selection Node . As an alternative, an operation may have multiple, labelled, outgoing branches, which converge at a Selection Node . This effectively subsumes the first Selection Node within the operation.	None	None
	Iteration node	Causes its outgoing branch to be processed iteratively. At the end of the iterative processing section of Time Line , there is another Iteration Node which may or may not have a label; if it does, this label must match that of the Iteration Node at the start of the loop. From this second Iteration Node , a Time Line Loop branches back to the first Iteration Node . This Time Line Loop contains the iteration condition, either at its start or at its end, depending on the type of loop that is required.	None	None
	Replicate node	Creates a set of replicants of those of its outgoing branches that have a label. The number of these replicants is specified in the Replicate Node's label. There must be one unlabelled outgoing branch containing operations that control the replicants. All the outgoing branches converge into a second Replicate Node that marks the end of the replication.	None	None
	End loop node	Causes a jump in the sequence of control to the outgoing branch of the loop node with the specified label, such that control continues after the specified loop.	None	None
	Goto node	Causes a jump in the sequence of control along the Time Line to the Label Node in the same BD that has the matching label. There may be many Goto Nodes with the same label.	None	None
	Label node	Marks the destination of a Goto Node with a matching label. There may not be more than one Label Node with the same label.	None	None
	Exit diagram node	Causes all processing in the diagram to stop, and returns the flow of control to the exit of the BD's parent function with the same name as the node's incoming branch.	None	None
	Event node	Causes the flow of control to begin at the start of the Time Line in the BD specified in the node's label.	None	None
	Validation node	Serves simply as a means of reporting timing statistics from the Time Line (when timing information is available for BDs) where the information reported is identified by the node's label.	None	None
	Join node	Rejoins two or more Time Lines that have been created by either an AND, OR or multiple exit node earlier in the processing.	None	None
	Terminator	Represents an external system or environment to the system being modeled.	Terminator Description	None
	Picture	Allows you to choose the location of a GIF or JPEG image to be displayed as a diagram symbol or to be embedded in an existing diagram symbol.	None	None
	Time line	Represents the flow of time from object to object.	None	None
	Time line loop	Used in a loop or iteration structure to return to a Loop or Iteration Node and begin another repetition.	None	None
	Data link	Represents the flow of data both into and out of functions.	None	None
	Trigger data link	Represents the flow of data into a function, that triggers the function to execute.	None	None

Editing Notes

The send and receive signal symbols are the means to indicate the use of the classes operations.