A task represents a logical change that needs to be made in your software application. A task groups all the software modifications that need to be made to complete the change. It includes a description of the change and the name of the person responsible for completing it.
An object is a collection of data, such as a file or directory. Examples of objects are source files, makefiles, test results, directories, and documents. For tracking purposes, every revision of an object is called an object version. Each object version has a set of properties (for example, name, owner, create time) to further define it.
For example, a user reports a bug in your GUI of your application. The GUI group leader assigns the bug to a developer named Jane. Jane is assigned a task called Fix scrolling in Snap dialog box. Each time Jane uses Rational Synergy to check out an object that fixes the scrolling problem in the Snap dialog box, the object becomes associated with the task.
For an illustration
of these concepts, see the figure .
The task and objects have a relationship. Objects that are grouped by a task are said to be associated with the task. All objects required to fix a specific problem stay together in a logical grouping, described by the task name. The object versions on the right side of the figure are associated with the task Fix scrolling in Snap dialog box. They contain the code changes necessary to complete this task. The number at the top of each object represents the version of the object.
The task name, in this case, Fix scrolling in Snap dialog box, is called its synopsis. Additionally, when you create a task, Rational Synergy assigns it a number. Besides the number and synopsis, a task contains other information about the change, for example, the name of the resolver. When a task is assigned to a developer, the resolver is automatically set to the name of the developer. You can also set the following properties when you create a task:
Is a label that indicates the version of your software application. The possible values consist of releases that are significant to your software application, such as editor/2.0 or Rational Synergy/7.1. The build manager sets up release values specific to your software.
Specifies the hardware platform applicable to the logical change. The possible values are platform names significant to your software application, such as AIX or WIN2K. The build manager sets up platform values specific to your software. You do not need to set a task platform; this value is for your convenience only.
Specifies the software subsystem for the task. For example, if you develop a client-server software application, your subsystems might be client, server, and communication. If you develop an accounting software application, your subsystems might be AR, AP, and GL. The CM administrator sets up subsystem values specific to your software. You do not need to set a task subsystem. This value is for your convenience only.
The tasks and the source objects to be modified are located in the Rational Synergy database. Tasks do not have versions, but they follow a lifecycle. Tasks do not contain other tasks.
Any object managed in a Rational Synergy database is uniquely identified by the following properties: name, version, type, and instance.
By default, the four-part name (also called the object spec or full name) is written as:
name-version:type:instance
The following are some examples of four-part names: main.c-3:csrc:2 and draw.c-beta:csrc:7
An object name can be any combination of characters, except for restricted characters. The type can be any of the default types (for example, csrc and ascii), or any type you created. You can designate the name, version, and type, but Rational Synergy calculates the instance.
The instance is used to distinguish between multiple objects with the same name and type, but that are not versions of each other. For example, a project might contain 20 different makefiles, each named makefile, each in different directories, and each with many versions. If you want to use makefile-4, a query of that object might yield six objects called makefile-4. In this case, the instance property distinguishes which makefile object you want to use. The value of the instance is normally numeric, but can be alphanumeric in some cases, such as in a database that uses DCM.
You can use a specific object version in multiple directories. You can reference an object version through its path name. However, while the file location might change, the four-part name unique ID always remains the same.