|
|
After you map your system architecture to an initial set of components and determine which projects will access those components, refine your plan by performing the following tasks:
Decide how many VOBS to use
Identify any additional components
Define the component directory structures
Identify read-only components
ClearCase lets you store multiple components in a VOB. If your project uses a small number of components, you may want to use one VOB per component. However, if your project uses many components, you may want to store multiple components in several VOBs. A VOB can store many versions of many elements. It is inefficient to use a VOB to store one small component.
Keep in mind the following restrictions:
A component's root directory must be the VOB's root directory or one level beneath it. A component includes all directory and file elements under its root directory. For example, in Figure 10, Libs cannot be a component.
You cannot nest components. For example, in Figure 10, GUI, Admin, and Reports can be components only if Dev is not a component.
If you make a component at the VOB's root directory, that VOB can never contain more than that one component.
Figure 10 Storing Multiple Components in a VOB
Although you should be able to identify nearly all necessary components by examining your system architecture, you may overlook a few. For example:
System component | It is a good idea to designate one component for storing system-level files. These items include project plans, requirements documents, and system model files and other architecture documents. |
Project baseline component | If you plan to use a composite baseline that selects baselines from all of the project's components, we recommend that you store the composite baseline in its own component. See Identifying a Project Baseline for details. |
Testing component | Consider using a separate component for storing files related to testing the system. This component includes files such as test scripts, test results and logs, and test documentation. |
Deployment component | At the end of a development cycle, you need a separate component to store the generated files that you plan to ship with the system or deploy inhouse. These files include executable files, libraries, interfaces, and user documentation. |
Tools component | In addition to placing source files under version control, it is a good idea to place your team's developer tools, such as compilers, and system header files under version control. |
After you complete your list of components, you need to define the directory structures within those components. We recommend that you start with a directory structure similar to the one shown in Table 1; then modify the structure to suit your system's needs.
In Table 1, Component_1 through Component_n refers to the components that map to the set of logical packages in your system architecture.
Component | Directories | Typical contents |
|---|---|---|
System | plans | Project plans, mission statement, and so on |
requirements | Requirements documents | |
models | Rose files, other architecture documents | |
documentation | System documentation | |
Component_1 through Component_n | requirements | Component requirements |
models | Component model files | |
source | Source files for this component | |
interfaces | Component public interfaces | |
binaries | Executable and other binary files for this component | |
libraries | Libraries used by this component | |
tests | Test scripts and related documents for this component | |
Test | scripts | Test scripts |
results | Test results and logs | |
documentation | Test documentation | |
Deployment | binaries | Deployed executable files |
libraries | Deployed libraries | |
interfaces | Deployed interfaces | |
documentation | User documentation | |
Tools | compilers | Developer tools such as Visual InterDev and Rational Rose |
headers | System header files | |
Project baseline | none | Composite baseline that selects baselines from all components in the project |
When you create a project, you must indicate whether each component is modifiable in the context of that project. In most cases, you make them modifiable. However, in some cases you want to make a component read-only, which prevents project team members from changing its elements. Components can be used in multiple projects. Therefore, one project team may be responsible for maintaining a component, and another project team may use that component to build other components.
For example, in Figure 11, Project A team members maintain a set of library files. Project B team members reference some of those libraries when they build their components. In Project A, the cm_libs component is modifiable. In Project B, the same component is read-only. With respect to the cm_libs component, Project A and Project B have a producer-consumer relationship.
Figure 11 Using a Read-Only Component
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
