IBM
Contents Index Previous Next



Control Unit File


In addition to the System file (see "System File" on page 190), the Organizer also manages Control Unit files, .scu files. These control units are introduced to facilitate the workgroup (multiuser) support when working with an SDL system managed by the SDL Suite, and merging the individual results to a common system file.

General

The multiuser support is based on, from a revision control point of view, letting the user split the system file into several files. Information that is updated often should be split and stored in control unit files.

When and where to split the SDL structure is an active action taken by the user.

The multiuser mode is effective when control unit files are used. The use of the control unit files is optional, whereas the system file is mandatory. The Organizer thus always requires a system file and can manage multiple control unit files. By not taking advantage of control units simply means using the Organizer and system files as was done before, i.e. in previous versions (3.0X/3.1X/3.2).

Definitions

A definition for a system file (.sdt file) from a revision control point of view: a file that contains structure and state information for a document system as seen by one user. This file is normally not considered as an essential part of the system and is not suitable for revision control as it is private to one user.

A similar definition for a control unit file (.scu file): a file that contains structure information for a subset of a document system and which is common to all users that work with the document system. Control unit files are part of the document system and are suitable for revision control.

The control unit files can be inserted and made visible in the Organizer's file structure view. The control unit files contain information that is specific to the Organizer file structure for diagrams, modules and chapters.

Splitting the System File

The users control what parts of the file structure managed by the Organizer need a separate control unit file. When several users work on a system, the management of the system file may be difficult to synchronize. This problem is solved if every user or group have control over their own part of the system file.

The Organizer structure information is hence split into several files - control unit files. The decision of where and how many control unit files are needed is left to the users; the idea being to partition the diagram system according to the user's work responsibilities and assign control unit files to these partitions. An example can be a large SDL diagram system where there are several blocks on the system level developed in parallel by different developers. Each block could then be associated with a control unit file. Now, the blocks can be updated independently and the changes are shaping the local control unit files. There is no need to manually merge changes into the system file when the work is done - the management of control unit files performed by the Organizer also includes the merge.

The user decides how control unit files and the system file cooperate to produce the Organizer view of the document system. Two scenarios are possible here. In one scenario the user decides that the system file is valid and the diagram structure is read from it. This is done when the user opens the system file and loads the document system into the Organizer. In the other scenario the control unit files are used to load the Organizer view and automatically update it accordingly to a specific revision for the document system - the system file is used only to fill in document state information (if any is available). This is done with a menu command when control unit files are used to explicitly update the document system or some part of it.

An Example

To illustrate the use and contents of control unit files and facilitate the understanding, let us discuss the topic with a simple example as input.

Example 5

Say we have the following system managed by the Organizer:

Figure 55 : A simple system, managed by the Organizer

Let us say that we create control units (using the Configuration > Group File command) for the following items:

We would now have a system that looks like this:

Figure 56 : The same system, now with control units

The control units are depicted in bold face.

The [DIAGRAMS] section of the demongame.sdt file will contain:

[DIAGRAMS]
-2 102 system system.scu 0 0 - ""
-1 102 diagrams diagrams.scu 0 0 - ""
-1 23 "Diagram Structure" %unconnected% 0
0 102 demongame demongame.scu 0 0 - ""
0 1 DemonGame demongame.ssy 0 0 demongame ""
1 102 gameblock gameblock.scu 0 0 - ""
1 2 GameBlock gameblock.sbk 0 0 gameblock ""
2 5 Main main.spr 0 0 main ""
2 5 Game game.spr 0 0 game ""
1 2 DemonBlock demonblock.sbk 0 0 demonblock ""
2 5 Demon demon.spr 0 0 demon ""
0 33 1 1.txt 0 0 - ""
-1 23 "Associated Documents" %unconnected% 0
0 16 DemonGame1 %unconnected% 0 0 - ""
0 16 SystemLevel systemlevel.msc 0 0 - ""

The files system.scu, diagrams.scu, demongame.scu and gameblock.scu will contain the following information:

system.scu:
-1 102 diagrams diagrams.scu 0 0 - ""
-1 23 "Associated Documents" %unconnected% 0
0 16 DemonGame1 %unconnected% 0 0 - ""
0 16 SystemLevel systemlevel.msc 0 0 - ""

diagrams.scu:
-1 23 "Diagram Structure" %unconnected% 0
0 102 demongame demongame.scu 0 0 - ""
0 33 1 1.txt 0 0 - ""

demongame.scu:
0 1 DemonGame demongame.ssy 0 0 demongame ""
1 102 gameblock gameblock.scu 0 0 - ""
1 2 DemonBlock demonblock.sbk 0 0 demonblock ""
2 5 Demon demon.spr 0 0 demon ""

gameblock.scu:
0 2 GameBlock gameblock.sbk 0 0 gameblock ""
1 5 Main main.spr 0 0 main ""
1 5 Game game.spr 0 0 game ""

Format and Structure of the Control Unit File

Format

The format of the control unit file complies with the syntax of the [-DIAGRAMS] section in the system file (see "Format of the System File" on page 191). There are however some exceptions:

The first line of the scu file indicates the source directory to use for relative files mentioned in the scu file. This information is saved in the same way as the same information is saved in the system file. By having this information in the scu file, it is possible to re-use/reference the same scu file from different system files with different source directories.

<viewState>
This field is only used for the separation value - the value is therefore either 0 or 1.

<timeStamp>
This field is not used - the value is always 0.

<associations> ::= " <qualifiernameList> "
A list of quoted qualifier names, each name denoting a document. See Example 6, below.

<dependencies> ::= " <qualifiernameList> "
A list of quoted qualifier names, each name denoting a document.

<qualifiernameList> ::= $ | (<qualifierName> 
                        (, ($ | \NL) <qualifierName>)*)

<qualifierName> ::= ` <qualifierTuple> 
                    (/<qualifierTuple>)* `

<qualifierTuple> ::= <integer> <string>
<string> is the name of the system file, chapter, module or diagram.

Example 6

" `23 Diagrams Area/1 DemonGame/2 DemonBlock', \
`23 Diagrams Area/1 DemonGame/2 GameBlock' "

Structure

Associations between Control Units and Document Structures

A control unit file is associated with a document structure in the Organizer. The control unit file holds information about the top node of the structure and information about lower level documents under the top node and/or other lower level control unit files.

Levels (Indents)

Document nodes in a control unit file have a relative level (i.e. <-indent>) starting from 0. (Exceptions: a chapter node and an control unit file node associated with a chapter have always level -1). This gives the flexibility that the control unit file can be associated with a node on different levels in the system structure of documents. To get the actual level for a document node from an control unit, the control unit file node level should be added to the document's relative node level.

Example 7 : For the control unit level 1 from Example 5 on page 203

0 2 GameBlock gameblock.sbk 0 0 gameblock ""
1 5 Main main.spr 0 0 main ""
1 5 Game game.spr 0 0 game ""

Hierarchy

The control unit files are hierarchical. The top control unit file is for the whole system of documents in the Organizer. We give this control unit file level (-2). If this file has an information line in the system file this means that the top of the whole system structure is found in that file. Other structure information about diagrams mentioned in the system file is then only a mirror of the structure information found in the control unit hierarchy.

Example 8 :

-2 102 system system.scu 0 0 - ""

Modularity

The user can choose to use a control unit file only for a specific chapter, module or diagram structure (without a top level control unit system file). This means that not all information in the system file is a mirror for structure information from control unit files. Some of the information can be actual structure information that is not controlled by control unit files. When the Organizer expands structure information from control unit files it tries to match that information against the contents in the system file. This matching is necessary because only the system file holds state information about documents. The structure information from control unit files takes precedence over structure information found in the system file. If there is an inconsistency between the control unit file structure information and the system file, the control unit information takes precedence and the SDL Suite contents are treated as an error situation. Say, for instance, that according to a control unit file there are three blocks in an SDL system but there are four blocks in the system file. The extra block is probably old information.

Example 9 : A control unit file for a chapter

-1 102 diagrams diagrams.scu 0 0 - ""

Order of Appearance

A control unit information line in the system file is followed by a mirror information line of the top node that the control unit file is associated with. If the Organizer cannot open the control unit hierarchy the mirror information will function as a back-up document structure information.

Example 10

-1 102 diagrams diagrams.scu 0 0 - ""
-1 23 "Diagram Structure" %unconnected% 0


http://www.ibm.com/rational
Contents Index Previous Next