![]() |
![]() |
![]() |
![]() |
![]() |
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.
- The diagram structure information is common to all developers of the system in a multiuser environment.
- The state information is specific for 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.
Say we have the following system managed by the Organizer:
Let us say that we create control units (using the Configuration > Group File command) for the following items:
- One control unit that holds the entire system file together
- One control unit for the whole diagram structure
- One control unit for the system DemonGame
- One control unit for the block GameBlock.
We would now have a system that looks like this:
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% 00 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% 00 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% 00 16 DemonGame1 %unconnected% 0 0 - ""0 16 SystemLevel systemlevel.msc 0 0 - ""diagrams.scu:-1 23 "Diagram Structure" %unconnected% 00 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.
" `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.
-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.
-1 102 diagrams diagrams.scu 0 0 - ""-1 23 "Diagram Structure" %unconnected% 0
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |