Management of shared design resources

To manage changes to shared design resources, you should understand the concepts of configuration spaces, configurations, snapshots, workspaces, and dependencies, and the role of these concepts in projects in a collaborative development environment.

Configuration spaces

A configuration space, also called a space, is a collection of related workspace and snapshot configurations. Spaces manage the version information for resources. By creating spaces, you can group related snapshot and workspace configurations so that they can be shared among projects.

In an application with Design Management capabilities, teams complete work within a project area. For example, a project in an organization might have three project areas: database logic, application logic, and user interface logic. A project area defines the project deliverables, team structure, process, and schedule. For applications that are part of the Rational® solution for Collaborative Lifecycle Management (CLM), you can associate multiple project areas with the same space; therefore, these projects share snapshot and workspace configurations. After you associate a project with a space, all the workspaces and snapshots in the space are available in that project. This feature includes these advantages:
  • Users can use a single configuration context to change resources that are located in different project areas. See the following section for the definition of a configuration context.
  • Administrators and users can take snapshots that capture all the resources across the multiple projects that share a workspace.
For more information about projects, see the links to related topics at the end of this topic.

After you associate a project with a space, you cannot associate that project with a different space.

Configuration contexts

A configuration context, which is also called a context, represents the workspace or snapshot that you are working with. To change contexts means to change to a different workspace or snapshot. When you select a configuration context in a project area, by default, the context does not change when you switch to another project area in the same space. To switch to a different context, use the Current Configuration Context menu in the upper right of the banner. This menu provides options for working with snapshots and workspaces in the current space.

Consider the following scenario: You are a member of three projects that share a configuration space. All three projects are in different iterations of their lifecycle, and an administrator has created a workspace named after each iteration. If you open a project area and switch to the Iteration 1 workspace, and later switch to another project area, the current context is still Iteration 1.

Snapshot configurations and workspace configurations

A configuration is a unique set of versions of resources. There are two types of configurations:
  • Snapshot configuration: Also called a snapshot, which is a read-only view of an entire project at a specific moment in time; it includes all design resources and links to other resources. You can comment on, but not edit, the resources in a snapshot.

    You can create a snapshot at any time: for example, you might create a snapshot after you import models onto the Design Management Server, or after you complete a review of specific artifacts.

    After you modify resources, you can refer to the snapshot to see how the resources have changed.

  • Workspace configuration: Also called a workspace. Each space contains a default workspace, which can contain multiple snapshots and workspaces; a space contains multiple workspaces. For example, in a banking project, you might define the following workspaces, which different teams might use:
    • Application logic
    • Database logic
    • User interface
    You can add, edit, and delete versions of resources in workspaces.

    You can create a workspace based on the contents of another workspace in the same space. For example, you can create a workspace for Project B based on a workspace in Project A. The versions of the artifacts in the new workspace for Project B are the same as those resources in the selected workspace in Project A. If you add, edit, or delete resources in the Project B workspace, you do not affect the resources in the Project A workspace.

    If a workspace requires resources in a workspace that is in a different space, you must take a snapshot of the latter workspace, and then specify a dependency on that snapshot.

Visibility of resources in different project areas

Within a space, project areas contain different resources. Consider the scenario mentioned in the preceding "Configuration spaces" section: the project area for application logic contains designs that relate to application logic; the database project area contains designs that relate to the database, and so on. All project areas share the same space, and therefore share configurations. Each configuration manages the versions of all the resources in all the project areas. However, resources are not visible across different project areas: For example, if you are working in the project area for application logic, you cannot access the resources in the database project area; you must manually switch project areas to view those resources. You must be a member of a project area to view its resources.

Dependencies on resources in other spaces

When administrators create a project area, they must associate it with one or more domains. An administrator can select a specific version of a domain; the version to select depends on the requirements of the project.

If a workspace requires a resource in another project area, you must create a dependency on the snapshot that contains that resource in the project area. You can specify dependencies on snapshots only.

Consider the following example: At the start of a project, an administrator associates domains (for example, BPMN domain, Sketcher domain, or SoaML domain) with a project area to specify the ontology to use in a project. In the domain, snapshots list specific versions of resources: for example, a UML domain might contain multiple versions of a UML dependency. If your project requires a UML dependency as part of its ontology, find the snapshot that contains the version that you need, and add that snapshot as a dependency of your workspace. After you add the dependency, the artifacts in that snapshot are available to use in your project.


Feedback