[Top] [Prev] [Next] [Bottom]
All development and maintenance work is done within the frame of an SDE Project. A goal of a project is to develop, enhance, or modify one or several SDE Systems, from which new versions of Products are made. See Figure 2-1.
Fig 2.1 Relations between Project, Systems, and Products
This chapter will give a short overview of these concepts. For more information see
An SDE System is a version-controlled collection of related files, including mechanisms to build the system. It is a complete reference and includes source code, object code, documentation, etc.
An SDE Product is a versioned extract from one or several systems, in a format suitable for distribution, installation, and user access.
Products can be either end-user products (executable programs) or software libraries to be used by other programmers.
Internal software products are used to hide the implementation of a frozen version of a system, and to distribute software components within an organization.
An SDE Project defines a work area, and is connected to one or several systems. The purpose of a project is to modify these systems, and to produce one or several products. A project should be limited in time and correspond to a project as defined in IPA Project Model (see IPA Software Development Manual, 3BSE000747).
There are two kinds of users in an SDE project:
An SDE Project Manager is responsible for the project. He/she creates the project, is the owner of the project structure, and can manipulate with the project structure. The project manager can add systems to the project (that is, define which systems the project will be able to access), define the project members and create their working directories, terminate and delete the project.
The Project Manager should also define default versions of external products that the project will use, for example which versions of external object libraries that should be used.
An SDE Project Member is a User defined by the project manager. The same user can be assigned as project member in several projects. When the user "logs into" a project, he/she automatically gets the correct environment and is placed in the correct working directory.
Each system is divided into a hierarchical structure of subsystems, each containing files that are logically related. A subsystem corresponds to a Unix directory. Therefore, a practical concern when the subsystems are defined, is to have the subsystem directories manageable in size, especially together with the build tool (Make).
Each subsystem is implemented as a pair of directories: an RCS library containing all versions of the source files in the subsystem, and a directory containing the current file versions used by Make, and the results of the build.
A selection of specific file versions that will be used, e.g. for a new product version, is called a configuration. A frozen configuration can be regarded as a snapshot of the current file versions, in all active subsystems, at some point in time.
SDE includes support for defining configurations (by setting version names on files in the RCS libraries), freezing them when they are stable, and saving enough information so that the configuration later can be recreated.
All information about configurations are available in the RCS libraries of the subsystems (using symbolic name tags on the file versions). But in addition, SDE maintains a "copy" of the system hierarchy for each configuration. That is, the structure of a system is in fact like in Figure 2-2:
Fig 2.2 Structure of an SDE System
The advantage of having separate subsystems for each configuration is:
When a system configuration has been frozen, files can be exported to a product. In SDE, a product means any package of files that are released and distributed together. Outside SDE, other names, like component or subsystem, can be used.
A product has an official name (e.g. SDE), and each new version of the product has an official product version number (e.g. 2.1/1).
The product is stored as a directory structure with separate directories for each product version. Note the difference between a system and a product. Whereas a system structure containing subsystems is designed to facilitate internal development and maintenance of a system, the product structure is designed to be easy to use by the receiver of the product. The directory structures within a specific product version is therefore product-specific. SDE has no constraints for this structure, except that we recommend that all products have an info directory that contains information about which other components have been used for this product version.
An example of a product structure is shown for Product X, Version 1.0-0, in Figure 2-3:
Fig 2.3 Possible Directory Structure for a Product
To be able to distribute an SDE product it may need to be transformed into some other distribution format. SDE has support for transforming a product into a file set, a distribution format used on HP-UX. Logically, this is still the same product. When the file set is installed by the receiver of the file set, the original product structure is recreated.
2) Several options are available. Se the manual SDE-CORE Methods for more information.