Cradle from 3SL, the complete Model Based Systems Engineering Toolsuite, specialising in requirements management, requirements capture, model based systems engineering and for systems engineering software, support and consultancy, the logical choice: Cradle from 3SL.
login Register forgot password or username?
Search:         

Welcome to 3SL Reference Section

Structure Chart Structure Chart (STC)

Structure Chart (STC)

An STC shows a call hierarchy within a set of routines (procedures and functions) in a unit of source code. Each routine is shown by a module that is described in a code module. Structure Charts also show the parameters passed between the routines in their calls, using symbols called couples. Each couple is defined by a data definition in the Data Dictionary. Structure Charts can also show the global and shared data between these routines.

Cradle allows hierarchies of STCs which is useful in systems that have some degree of multi-processing or multi-tasking. One level of STC can be used to show the inter-process and inter-task communications, while lower-level(s) show the details of each task or process. For large systems, several levels of STC will be needed to reflect the number and complexity of the modules in the system, irrespective of whether multi-processing or multi-tasking is in use. Furthermore, the advent of packages in languages such as Ada also creates the need for more than one level of STC, where the higher-level(s) show the interactions between the package specifications (to use the Ada terminology) and lower level(s) of STC are used to define the package bodies.

The relationships between modules are shown by calls. The existence and direction of the call indicates that a module has the means to call the other module and that, at runtime, the module may call the other module zero or more times.

Typically, the STC contains a hierarchy of modules with calls used to show how one module will call another. As module calls normally involve the passage and return of parameters (or arguments), the STC depicts these with couples. Data and control couples are provided that indicate the passage or return of an item of data or some value that controls the operation of the recipient module (such as a condition for a loop or test). The orientation of the couple indicates which module is sending the parameter, and which is receiving it. For parameters which are updated by a called module, use the dialog couple.

The data and control received and sent by a module in its input and output couples must be equivalent to the data and control received and sent by the collection of modules on the lower-level STC that the given module may have been expanded into.

The STC does not show sequence, so that an STC with a module M which has calls to three other modules A, B, and C drawn left-to-right below it, does not mean that M calls first A, and then B, and then C.

To avoid crossing calls, and for large systems, STCs provide named on-page connectors and off-page connectors. These allow calls between modules on the same or separate STCs to be shown as a pair of calls, one to the on-page or off-page connector, and the other from another on-page or off-page connector with the same name. Cradle treats calls through these connectors as though the two calls were one call. On-page and off-page connectors are supported by the Consistency Checker (CC) and Code Generator.

Tip: This means that couples are inherited across on-page connectors and off-page connectors. For example, a couple is required between modules A and B, but the call between these modules is split using off-page connectors, only a couple from A to the off-page connector need be drawn. It is not necessary to find the STC containing B and draw another couple from this off-page connector to B.

Off-page connectors provide a useful method of splitting a large STC into several smaller and more manageable diagrams that are linked, easily traversable, and exist at the same level. This flat structure is in contrast to decomposing the large diagram into a hierarchy, which may not be appropriate as then lower-level STCs would not necessarily contain greater detail.

Converting STCs

STCs can be converted into Data Flow Diagrams (DFDs). To convert an STC, select Convert to DFD… from the Item pulldown menu:

Diagram Converter dialog

The rules for the conversion are:

  1. Each STC module (of any type) becomes a DFD process.
  2. All STC inter-module calls are ignored.
  3. If a module is called by another but which does not have any couples associated with this call, the module's corresponding DFD process will be triggered by the corresponding process for the calling module, with a prompt control flow called TRIGGER.
  4. All STC global data areas become DFD stores.
  5. All STC data couples become DFD discrete data flows between the processes corresponding to the STC modules at each end of the couple. Control couples become DFD discrete control flows.
  6. Each STC dialogue couple becomes a pair of discrete data flows on the DFD, each in opposite directions to the other, between the DFD processes that correspond to the STC modules linked by the couple.
Converting a Structure Chart to a Data Flow Diagram
  1. From the Structure Chart select Convert to DFD… from the Item pulldown menu
  2. Choose the Scope as one of Item or With Definitions
  3. Select the model for the new DFD by pressing the Choose Model… button

The chosen model is shown in the Diagram Converter dialog

  1. Enter the Number and Name for the DFD to be created
  2. If required, check the Allow an existing item to be over-written checkbox
  3. Press the OK button to perform the conversion

The newly converted DFD will be produced.

STCs are only available in the Implementation Domain. STCs are hierarchical. Their connectivity is:

Diagram of the hierarchical connectivity of a Structure Diagram

Numbering of STCs

All STCs are numbered, as are the STC symbols that can be expanded into lower-level STCs. The modules on STC 1 will have numbers 1.1, 1.2, 1.3, etc., which are the numbers of the STCs into which they may be expanded. Similarly, STC 1.3 modules have numbers 1.3.1, 1.3.2, etc.

Symbols

An example STC is:

Screenshot of a Structure Diagram

The symbols available in STCs are:

Symbol Name Description Definition Expansion

Comment

Comment Makes a note anywhere in the diagram. Are always surrounded by * characters. None None

Boundary Point

Boundary Point A connection point for the initial transition to enter the initial state. None None

Module

Module A module of software, a routine, either a procedure or a function. Code
module		 STC

Inclusion Module

Inclusion
Module		 A module of software that in the final source code appears within the source code of another module. Code
module		 STC

Transaction Centre

Transaction
Centre		 A module that selectively calls one of the set of lower-level modules connected to it on the basis of some condition (it acts like an if-then-else). Code
module		 STC

Library Module

Library Module A module from a library whose implementation is not defined by the project. None None

Off-Page Connector

Off-Page
Connector		 A named object that breaks a single call into two calls on different STCs. Off-Page Connectors are associated with each other if they have the same name. The user can traverse from an Off-Page Connector on one STC to the associated Off-Page Connector on another STC at the same or a different level, directly from the diagram. None None

On-Page Connector

On-Page
Connector		 A named object that breaks a single call into two calls in the same STC. On-Page Connectors are associated with each other if they have the same name. The user can traverse from an On-Page Connector on one part of an STC to the associated On-Page Connector on another part of the STC directly from the diagram. None None

Shared Data Area

Shared Data Area A repository of data shared by one or more modules, used to represent either data common to several modules, or preserved between invocations by a single module (such as local static data in the language C), or accessed whenever invoked by a single module. Data definition None

Global Data Area

Global Data Area A repository of data shared by all modules that connect to it, used to represent some piece of implementation technology (software and/or hardware based) that stores data in a manner that is independent of any module using that information. Data definition None

Module Call

Module Call Indicates that a module could call another module, and calls it zero or more times at runtime. None None

Module Invocation

Module
Invocation		 Indicates that a module calls another module that thereafter executes in an independent manner; used for processes and tasks. None None

Iterative Module Call

Iterative
Module Call		 Indicates that one module iteratively calls another module, for example a call within a loop. None None

Data Couple

Data Couple An item of data either passed to, or returned by, a module. Data definition None

Control Couple

Control Couple A control or status value or flag that affects the operation of its recipient module. Data definition None

Dialog Couple

Dialog Couple An item of data passed to, and updated by, a module. Data definition None

Function Return

Function Return An item of data returned by a module. Function returns have no name (it is taken from the module they are returning a value from). They cannot, therefore, be named or renamed. Data definition None

Picture

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