TOC PREV NEXT INDEX DOC LIST MASTER INDEX



Introducing Summit/TM

Rational Summit/TM is an integral part of Rational's Summit task and configuration management system. It is also provided as an optional layered product for Rational's Apex development system. It provides a framework for automated process control that simplifies and improves management insight as well as engineering productivity and coordination. It helps you get control of the software process by keeping track of the work (or tasks) necessary to complete a project. Although especially tuned to the needs of software development, Rational Summit/TM is customizable and can be adapted to help monitor and control the work flow of many business activities. With Rational Summit/TM, the various aspects of a task can be defined, individual tasks can be created, and tasks can be edited, viewed, or summarized.

Rational Summit/TM is tightly integrated with Rational Summit/CM, Rational's Configuration Management (CM) system which is part of both the Apex and Summit products. Summit/TM can interact with other productivity enhancing tools as well.

This document assumes familiarity with Apex or Summit (especially Summit/CM) as well as the foreign tools with which Rational Summit/TM can interact. See the following documents for a full description of these products:

Concepts Guide
Online Reference
Using the Apex Debugger
Programming with Apex
Getting Started
Using and Customizing the Apex GUI
Command Reference


Concepts

This section describes the special concepts and terminology used by Rational Summit/TM. The information is presented without getting into the details of how these ideas are represented or implemented. For that level of detail, please see the "Rational Summit/TM Data Structures" in Customizing Summit/TM.

Task

A task is the primary form of partitioning, allocating, scheduling, and monitoring work. As the fundamental object of Rational Summit/TM, it represents a unit of work being tracked. (Note that a Rational Summit/TM task is not related in any way to an Ada task.) A particular task can represent any real world activity which may be simple or complex, such as:

1 . Fix the bug in the "stats" function that causes the product to crash when the user inputs more than100 items.

2 . Find a catchy new name for our product and change all references to the old name.

3 . Improve performance in our product by 25 percent.

4 . Finish major release 3.0 of our product by January 1, 2001 and under $1,000,000,000.

As a real world object, each task has a name, called a task id, and a set of task attributes, called fields, each of which has a particular value. This information about a task is saved in a special area called a task domain.

Tasks can come in different varieties to better support different types of work activities. Each variety can have a different set of fields and is described generically as a task kind. For example, you could have one task kind for tracking software bug fixes to a product and another task kind to manage the production of product documentation. Every task belongs to a particular task kind.

In object-oriented terminology, it can be useful to think of a task kind as a class and a task as an instance of a task kind. From the data-base perspective, it helps to treat a task kind as a schema or data description and a task as a record. Tasks can also regulate dynamic activities associated with them via state machines.

Task Id

A task id is just a simple name for a particular task. This name enables the task to be uniquely identified within its task domain. The actual name generated for a particular task depends on the task id generation policy in effect when a task is created. Occasionally, the term "task id" is used to refer to the full name of a task which includes the name of the task's domain as well as its simple name.

Task List

A task list is simply a file containing a list of tasks identified by their full pathnames. The list can be empty and it can include tasks from different task domains and different task kinds. Visiting a task list will invoke the task summary window from the graphical user interface.

Current Task List

The current task list is a special task list maintained by Rational Summit/TM. All users have their own current task list. The current task list is shared by all Apex or Summit sessions for a given user. This list is used as the default value for many dialogs that require a task argument, especially those related to Summit/CM commands. The list usually contains a single task at a time, but it can have more than one, if work is occurring on multiple tasks simultaneously.

To Do Task List

The "to do" task list is another special task list where users can remember the tasks that they are interested in. For example, they could record the names for all the tasks that have been assigned to them but not completed. There is separate "to do" task list for every user who wants one. The "to do" task list defines the list of tasks displayed when the Alternatives icon of a task entry field is selected in the graphical user interface. The Summary field of each task is also displayed to assist in the selection of the correct task.

Task Query

A task query is a task-search specification written in the Summit/TM task query language. Task queries are used to find tasks meeting specified criteria. When a task query is executed, the tasks found may be displayed and saved in a task list. A task query specification can be stored in a task query file for convenient reuse.

Task queries are powerful tools for managing large numbers of tasks. For example, a query can be used to determine which tasks, of those slated for inclusion in the next product release, are still incomplete. A task query searches a specified set of tasks (usually a task domain) and can perform a variety of tests on the data stored in each task.

Task Domain

For the most part, a task domain is a place to store a collection of related tasks. Rational Summit/TM supports the creation and use of multiple task domains. Typically, a given task domain is used to manage the tasks associated with a particular project (or business unit). However, projects can share the same task domain and a single project can have multiple domains especially if the project is large or geographically distributed.

Within a given task domain, every task must have a unique task id. To readily distinguish tasks belonging to different task domains, each domain can define a different task id naming convention for its tasks. See Task Id Generation Policy for details.

Tasks of differing task kinds can be located in the same task domain. In this case, however, each task kind must also be uniquely named. Different task domains can store tasks of the same task kind. The task kinds supported by a given task domain are listed in the task domain kind path for that domain.

Task domains can also define certain access controls on who can do what to its tasks through roles. See Role for more information.

Note that task domains are not related to remote development domains. However, in some circumstances, it can be useful to set up a one-to-one correspondence between the two.

Task Domain Path

The task domain path is a list of the task domains that a given user is interested in and can have zero or more entries. It is maintained in the environment variable APEX_TASK_DOMAIN_PATH. It is not necessary to define this path to use Rational Summit/TM, but it makes it much easier to find tasks when it is defined.

Default Task Domain

The default task domain is the first domain on the task domain path. It is used as the default value in many dialogs that call for a task domain argument. It is also special, in that, tasks which belong to the default task domain can be referred to by their simple task id. All other tasks must be referenced using their full pathname.

Task Domain Kind Path

A task domain kind path identifies the kinds of tasks that can be created within a particular task domain. It is also used to locate the task kind information for the tasks within the task domain.

Task Kind

A task kind is a collection of information describing the attributes and dynamic behavior of a task, as well as dialogs which may be used to edit a task. This information is commonly shared by all tasks belonging to a particular task kind. As such, new tasks can be easily created from a task kind and tasks of the same task kind can be meaningfully compared and analyzed.

Different task kinds can be created and customized for use by activities which have significant differences in the type of information they wish to keep track of. For example, a task kind could be a bug tracking request, a documentation change request or a monthly payroll processing activity. Tasks of different task kinds usually employ a different naming convention for generating their task ids. Each task kind defines its own convention via the task id generation policy.

The attributes of a task kind (and, in turn, its associated tasks) are defined by its task fields list.

The dynamic behavior of a task kind may be described by one or more state machines. This is a powerful optional facility.

Finally, the initial values for the fields of a newly created task are defined by the task kind with a task template. Again, more than one task template can be set up for a given task kind to support different uses. These templates are identified by the task kind's template path.

A dialog for editing tasks of a task kind is called a task editor for the task kind. It describes how the information in a task is presented by Rational Summit/TM's graphical user interface. A given task kind can have multiple task editors so that the task information can be viewed by different people in different ways. See Task Editor Policy for details.

Task Field

A task field is an attribute or property of a task. A task kind actually defines a task field, giving it a name and data type. A task references a field by name and associates with it a value of the corresponding type.

Some fields are essentially pre-defined by Rational Summit/TM and should be included in every task kind. These fields affect the behavior of some Rational Summit/TM commands. Most task fields, however, are optional.

Another characteristic of a field is whether it is editable (under normal circumstances). Some fields of a task can only be assigned a value when a task is created. From then on, the value is never changed. Other fields are changed, but only indirectly, as the result of some command. The remaining fields are fully editable and can be changed with the aid of a task editor or the modify_task command.

Task Field Type

Rational Summit/TM supports the following simple task field types:

date
A date and time string
enum
A finite list of specific values
fixed
A fixed point number
float
A floating point number
int
An integer number
path
A file or directory pathname
state
A "state machine"
string
A single line of arbitrary characters
task_path
A task pathname,
text
A multi-line string
version
A Summit/CM controlled object version identifier

Rational Summit/TM also supports list task field types which define fields whose values are lists. The elements of a list field value are values of a particular simple field type. List types are denoted by type*, for example task_path*.

Pre-defined Task Fields

The task fields described here have a special relationship with Rational Summit/TM and should be included in every task kind field list definition. These fields affect the behavior of Rational Summit/TM commands. Unless stated otherwise, these fields are never modified once a task is created. In any case, they cannot be directly modified by the user.

Some of the predefined task fields are called implicit fields. The value of an implicit field is not actually stored in the task but is computed automatically when the field is referenced. The value is derived from the pathname of the task and possibly the values of other fields of the task.

Id Field

The Id field is an implicit field of type string. Its value is the simple name of the task without the .task suffix.

Name Field

The Name field is an implicit field of type task_path. Its value is the full pathname of the task including the .task suffix.

Kind Field

The Kind field is a string field containing the simple name of the task's associated task kind. The actual task kind depends on the task domain kind path for the task's domain and the value of this field. The Kind field value is always established when a task is created.

Kind_Path Field

The Kind_Path field is an implicit field of type path. Its value is the full pathname of the task's associated task kind. The value is derived from the task domain kind path for the task's domain and the value of the Kind field.

Domain Field

The Domain field is an implicit field of type path. Its value is the full pathname of the task domain (that is, the directory) containing the task.

Parent and Children Fields

The Parent and Children fields of a task can be used to construct a strictly tree-oriented, hierarchical relationship between tasks. The Parent field has type task_path and its value identifies the parent task of the task. A task need not have a parent, but if it does, it can have only one.

The Children field is a list of values of type task_path which refer to the child tasks of a given task. The Children field is modified whenever a new child task is created.

For every task that has a parent, that parent task has a corresponding reference to the child. Although not required to represent the tree-structured relationship of tasks, having the Children field improves the performance and the integrity of the system.

Note that the parent and/or children of a task need not belong to the same task kind nor the same task domain. However, crossing task domain boundaries does increase the complexity of the system significantly.

CMVC Versions Field

When used in concert with Rational Summit/CM facilities, Summit/TM can significantly improve the ability to track changes made to controlled objects. Summit/TM and Summit/CM are tightly integrated to provide this service seamlessly and easily.

A "change" represents the creation, modification, or obsolescence of a controlled object such as a source file or a document. In Summit/CM terminology, a change is represented by a controlled object "version" which includes a source file name, version history name and version number. Tasks are normally associated with a version when an object is initially placed under CM control or when a controlled object is checked in or checked out.

The field type for the CMVC Versions field is a list of version type values. Each value of which identifies a particular CM version. Thus, a given task can be associated with multiple versions of the same or of different source objects. Likewise, multiple tasks can be associated with the same version, although this relationship is usually less common.

Task Relationships

Tasks may be related to one another. For example, a parent task is related to each of its child tasks (as described above) and, conversely, each child task is related to its parent. Task relationships are represented using task fields of type task_path to identify the related task(s). In general, task relationships are bidirectional. Each of two related tasks contains a task_path field that identifies the other. Relationships may be one-to-one, one-to-many (as in parent to children), or many-to-many. Related tasks may be of the same kind or different kinds, and may reside in the same domain or in different domains.

New types of relationships can be defined by defining appropriate task_path fields in the task kind(s). Related tasks can be created in single operation using related task templates (see Task Template).

Default Fields

Summit/TM provides commands that display selected fields for a set of tasks (e.g. the Tasks > Show menu command and list_task command). Some commands allow the user to explicitly specify which fields are displayed (for example, Tasks > Query). In the absence of such a specification, the default fields for the task kind are displayed.

The default fields for a task kind may be specified in the user's ~/.Rational directory and in the task kind itself. The user's preferred default fields (defined in his ~/.Rational directory) take precedence over those in the task kind. (See "User Environment" and "Task Kind Policy Switches" in the Customizing Summit/TM.)

When no specification exists for the default fields, the default fields are Id, State, Priority, Assigned and Summary.

Task Id Generation Policy

The task id generation policy defines how a name is chosen for a new task. There is a default policy that is used in the absence of a user-defined policy for the task kind.

The default policy combines elements specified in the task's kind and in the task's domain to form the task's id. Both the task kind and the task domain can define a prefix and a suffix for the task id. The task domain's prefix and suffix surround those of the task kind. In addition, to insure that all task ids are unique within the task domain, the domain defines a sequence number called the task index. This number is initialized to zero (0) when a task domain is created and is incremented before each new task is created within that domain. The task index value is inserted between the two prefixes and suffixes. The task domain also specifies a minimum width for the index value within a id.

For example, if the current settings for the task id generation policy are

domain prefix
td_
domain suffix
_dt
kind prefix
tk_
kind suffix
_kt
index width
5
index
12

then, by the default policy, the next generated task id would be

td_tk_00013_kt_dt

Using the task kind's policy switch file, a custom task id generation policy can be defined. A custom policy can include any of the elements described above, as well as literal characters (to appear in all ids) and a name that is specified by the user when a task is created. See "Task Kind Policy Switches" in the Customizing Summit/TM.

State Machine

A state machine is basically a description of the dynamic life cycle of a task identifying the phases a task passes through from its inception to its completion. Such a machine enables one to monitor the progress of a task and direct its flow through an established process that makes the business activity more efficient and thereby more productive.

For Rational Summit/TM, these phases are identified as a list of task states and the passage of a task from one state to another is termed a state transition. The ability to transition from one particular state to another can be completely prohibited or it can be subject to zero or more preconditions (also known as pre–actions and pre–triggers). There are two types of preconditions supported by Rational Summit/TM. In the first type, a given state transition is permitted only if the requester belongs to a designated role. In the second type, the transition is allowed only if a specified action returns a positive result. If all preconditions are satisfied, then the state transition takes effect. After the state transition, it is also possible to execute zero or more post-actions.

A task kind may define any number of state machines. Each state machine must be associated with a distinct task field of type state. The value of this field represents the current state of the associated state machine. In the case of multiple state machines, only one state field may be changed at a time; state transitions must be sequential.

In many cases, a single state machine and state field may be sufficient to model the process associated with the task kind. In this case, the field is generally called State, although it can be given a different name. A task kind need not define any state machine.

The states, legal transitions, preconditions, roles and actions of a state machine are completely customizable to meet the needs of just about any activity.

State

A state is a point in a task's life cycle, identifying via a state machine what a task has probably already been through and where it is likely headed and what must be done to get it there.

Role

For Rational Summit/TM, a role is a name given to a collection of users who are responsible for particular activities in the life cycle of a task. Examples of roles include the "manager" of a project, the "developers" doing the real work, and the "qa" personnel responsible for verifying the quality of the result. Thus, multiple team members (or users) can belong to the same role and a given user can carry out the duties of more than one role.

Currently, roles can only be used to control which users are allowed to make certain state transitions in a state machine. Whether a given user is permitted to take on a particular role is determined by two bodies of information. First, a user can declare, on a per task domain basis, which roles he or she wishes to assume. Second, each task domain can specify which roles it will allow a given user to fill. Thus, a user can take on a particular role for a given task only if the user wants to be in that role within that task's domain and only if the task's domain has granted the user the right to be in that role.

Action

An action is just a list of commands that are executed. These commands can be anything that can be done in a command shell. Rational Summit/TM uses the same mechanism as Apex's menu action facility. Actions can return status information to indicate if a precondition succeeds or fails. Since Rational Summit/TM waits for an action to complete before finishing a state transition, it is not advisable to define an action that takes too long. However, note that actions can start up background processes.

Task Template

A task template is a handy way to define the initial values for a newly created task's fields. A template need not initialize all fields as some are automatically set by the create_task command and many can be assigned an empty value without harm. A task kind can define multiple templates and the user may select the one to be applied at task creation. The supported templates are identified by the task kind's template path.

A given task template may be related to other templates, via relationships, in the same way that tasks can be related to one another. When such a template is used to create a task, additional tasks are created corresponding to each of the related templates, transitively. The resulting new tasks will be related to one another in exactly the same way as the corresponding templates.

Template Path

A template path is simply the list of task templates that a given task kind has established for the initialization of its newly created tasks. The first such template (if any) is used by default.

Task Editor

A task editor is a dialog that is used to present detailed information about a task via the graphical user interface. The task editor used to view a task determines which fields (and associated values) are displayed and what formats are used. From the task editor, users are typically able to modify a task's fields as well as examine them. Special support is also provided for initiating state transitions.

A task usually acquires its task editor from its task kind. A task kind can have multiple task editors to support the needs of different roles. Individual users can also specify particular task editors to use for particular task kinds. A task editor is chosen based on the task editor policy.

Task editors can be customized in many ways.

Task Editor Policy

The task editor policy determines which task editor to use to view a task's current data. First, individual users can select which task editor they want to use for particular task kinds. Second, a task editor can be chosen based on the role a user is in within the task's domain. Finally, if these searches fail, the task's kind defines a default task editor to use.


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2001, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS