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.
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.
STCs are only available in the Implementation Domain. STCs are hierarchical. Their connectivity is:
Numbering of STCsAll 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.
SymbolsAn example STC is:
The symbols available in STCs are:
| Symbol | Name | Description | Definition | Expansion |
|---|---|---|---|---|
 | Comment | Makes a note anywhere in the diagram. Are always surrounded by * characters. Note: If you do not want Cradle to automatically add an * go to the Graphics Settings section of Project Setup and turn off the Automatically add asterisks to diagram's comment symbols option. | None | None |
 | Boundary Point | A connection point for the initial transition to enter the initial state. | None | None |
 | Module | A module of software, a routine, either a procedure or a function. | Code module | STC |
 | Inclusion Module | A module of software that in the final source code appears within the source code of another module. | Code module | STC |
 | Library Module | A module from a library whose implementation is not defined by the project. | None | None |
 | 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 |
 | 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 | 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 |
 | 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. | Store data definition | None |
 | 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 area data definition | 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 |
 | Module Call | Indicates that a module could call another module, and calls it zero or more times at runtime. | None | None |
 | 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 | Indicates that one module iteratively calls another module, for example a call within a loop. | None | None |
 | Data Couple | An item of data either passed to, or returned by, a module. | Couple data definition | None |
 | Control Couple | A control or status value or flag that affects the operation of its recipient module. | Couple data definition | None |
 | Dialog Couple | An item of data passed to, and updated by, a module. | Couple data definition | None |
 | 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. | Flow data definition | None |
 | Item | Represents a requirement or system note in the diagram. | None | None |
 | Context Item | Represents a requirement or system note in a diagram and is a container within which other object symbols can be drawn or attached. | None | None |
 | Cross Reference Link | Represents a cross reference that exists between a pair of system notes/requirements. It can also represent a cross reference between a system note/requirement and a specification or data definition or system that describes the objects symbols that it connects. | None | None |