Table of ContentsTable of Contents 
Previous Chapter
SDT supports this way of working using The SDT Organizer and The Search List Manager tools. Those tools allow the members of a project to work independently, but in a coordinated and structured way. In particular, the tools support:
Important is that one diagram is represented by one file, and the mapping between diagrams and files are kept in the system file. The system file is the file that is opened when issuing the Open command in the Organizer. The system file has by default the extension .sdt.
A diagram may be bound to a physical file using the Organizer in three different ways:
Example 2The block diagram with the name DemonBlock will by default be bound to the file demonblock.sbk
Figure\x11 51 : Connecting a Diagram to an Existing File. ----- (fig) -----
Figure\x11 52 : Connecting a Diagram Using a Search List. ----- (fig) -----The names of the files are not important when mapping files according to a search list, since the diagram name is stored in the file. What is important though, is the extension of the file name which must correspond to the type of diagram stored in the file.
Example 3Block diagrams must be stored in files with the extension .sbk.
Search lists are managed by the Search List Manager tool. A search list contains an ordered list of directories, where the first directory in the list, the workdir, is always the directory where the search list is located.
The remaining directories (one or more) in the search list corresponds to the original area.
----------------------------------------------------------------------- Note: The order of appearance of the directories in the search list is of sig nificance. -----------------------------------------------------------------------When a search list is used in the Organizer to bind diagrams to files, each directory in the search list is searched in order for files whose contents match the diagram structure contained in the system file. It is always the first occurrence of a file that is bound to a diagram, i.e. if a file matching a diagram is found in the working directory, this file will be bound to the diagram. If a matching file is not found in the first directory, the next directory of the search list will be searched, etc.
Using the Search List Manager tool, it is possible to create new search lists and change existing search lists. It is also possible to execute an arbitrary operating system command on files corresponding to one or more marked diagrams by using the User Command command, which may for instance be used to move or copy diagram files between different areas.
We will now, in a few examples, describe how SDT can be used together with such a system, in this case RCS.
Example 4Let us assume that the diagrams in project PBX are managed by RCS. The structure and contents of the original area and each project members work area is then as depicted in Figure 53.
Figure\x11 53 Example of Structure and Contents of the Original Area and the DifferentWork Areas of Project PBX. ------ (fig) ------Each project member has access to a copy of the files contained in the original area. These files contain the diagrams he needs access to and a system file (PBX.sdt) describing the system structure. If a project member, say "User A", is to change the process diagram CLIP, he "checks out and locks" the file clip.spr by entering the command
Other project members may then access the latest version of the file clip.spr by checking out (i.e. copy) clip.spr.
Example 5If the project member "User B" is going to add a new diagram to the system PBX, for example process diagram CLIR, referred in the parent diagram block CLIPBLK, he must carry out the following steps:
Again, we assume that the diagram file locking mechanisms are controlled outside SDT, ensuring that a file cannot be modified by several members at the same time.
To cope with the situation, each project member uses his own work copy of the system file, in which the changes he applies to the system are reflected. An official copy of the system file is stored in the RCS directory; this copy reflects the global view of the system. Before checking in the (modified) system file, the project member has to let SDT carry out the following tasks:
Example 6Let the name of the "official" system file be official.sdt, and have RCS control the management of the file. Each project member creates his own local work copy of the official.sdt file and names it, say, local.sdt.
The official.sdt file should not have any source directory specified and should use relative paths when specifying directories. This is set in the Set Directories dialog.
The local.sdt file has the source directory pointing to the user's work directory and uses relative paths. The source directory can be specified when the local.sdt file is created, in the following way:
A check-out of all files in the RCS directory results in the official version of the system.
Figure\x11 54 :Example of how to Merge Individual Views. ------- (fig) -------The situation which is depicted in Figure 54 is that "User 1" has locked and modified c.spr and created a new file f.msc. The system file local1.sdt reflects the changes he has applied to the system. "User 2" in turn has locked and modified b.sbk and d.spr, and created g.msc. The system file local2.sdt reflects this.
To bring the changes back to the RCS directory by merging his view of the system with the current official system, "User 1" carries out the following steps: (we assume "User 1" has completed his work before "User 2" has)
Example 7The diagrams of project PBX may be structured according to Figure 55.
Figure\x11 55 : Directory Structure of Project PBX Using Search Lists. ------ (fig) ------The diagrams in the original area may be managed using e.g. RCS or some other version control system, or may be structured using one directory for every new version as explained earlier.
The search lists of each user has typically the contents:
-------------------------------------------------- Denomination Directory -------------------------------------------------- Work area `pwd` (the users working directory) Original area /PBX/PBX-1 Original area /PBX/PBX-2 Original area ... --------------------------------------------------If project member "User A" would like to work on the process diagram CLIP, he either "checks out" the file clip.spr by issuing the command co -l clip.spr in UNIX if RCS is used, or he simply copies the file to his working area. This may for instance be done by using the User Command facility in the Search List Manager tool. He must then update the binding of diagrams to files in the system file by issuing the command Connect Diagram and specify the option By expanding diagram in search list PBX.ssl in the Organizer to reflect the new location of the file clip.spr. This is important, since otherwise the system file will contain the invalid binding of the diagram CLIP to the file clip.spr in the original area. If the original area is not write protected, "User A" may accidentally corrupt the original file.
When "User A" is finished working on the CLIP diagram using SDT, he either "checks in" the file by issuing the command ci clip.spr in UNIX, or simply moves the file back to its appropriate place in the original area. This again may be done by using the User Command facility in the Search List Manager tool. Finally, the system file has to be updated by issuing the command Connect Diagram and specify the option By expanding diagram in search list PBX.ssl in the Organizer.
If project member "User B" adds a new diagram to the system PBX, for example process diagram CLIR, then, when the corresponding file clir.spr is moved into the original area, other project members may then rebind according to the search list PBX.ssl to get access to the new version.
Figure\x11 56 : Specifying Source and Target Directories when Creating a New System. ----- (fig) -----The directories may be temporarily changed in the Organizer by using the Set Directories command. In the Set Directories dialog there is also an option to either show the absolute path to files, or to show the path relative the Source directory.
Figure\x11 57 : Specifying the Source Directory in SDT. ----- (fig) -----This affects the way paths to files are stored in the system file.
------------------------------------------------------------------------- Caution! An important difference is that when saving a diagram in SDT 3.02, it is saved according to the binding of the diagram in the system file. If the diagram is bound to a file in the original area, the diagram will be saved in the original area, not automatically saved in the work area as was the case in SDT 2.3. Therefore, it is important that the original area is write protected to avoid overwriting diagrams by mistake. -------------------------------------------------------------------------This page intentionally left blank
Next Chapter
