Database View Customisation

The WorkBench Master Tree presents a navigable view of all parts of a project database, items that are being edited, queries and a variety of administration information. There is one node in the tree for each project-specific type of information, and there are nodes in the tree for the diagrams, data definitions and specifications for the models that may be created in each of the modelling domains:

Users can open the nodes in the tree to access lists of items of the corresponding types and subtypes. The items can be manipulated (to edit, inspect their change history, or to view / set their properties), or they can be double-clicked to navigate the cross references to / from them and access the items that they are linked to (subject to the current cross referencing filtering defined by the current navigation).

This tree view is very powerful, but to some projects, it has some limitations:

• Opening an item type shows all items of that type, not just the top-level items of the type
• The project cannot control which types of items are shown in the tree
• The project cannot control the names of the nodes, for example, the project cannot name nodes in Chinese or Korean

These difficulties can be overcome using the phase hierarchy.

Phase Hierarchy Facilities

The phase hierarchy allows a project to create its own, project-specific, hierarchy of terms that appear in the UIs of the Toolset, WorkBench and Web Access. A phase hierarchy would typically show the project’s process, such as:

• Phases, containing:
  • Activities
  • Tasks
• Reviews, containing:
  • Checklists
  • Deliverables

The elements of the phase hierarchy can be anything that the project finds useful, but usually it contains the process and reviews and their components.

Each element of the phase hierarchy can be:

1. A folder, that contains other phase hierarchy nodes
2. A query, that runs a specified query and presents the result:
   • Either as a subtree of items directly in the phase hierarchy
   • As a view specified by the phase hierarchy node, or by the query itself
   • As a collection of open items
3. A matrix, which is run and produces the appropriate display
4. A report, which contains either a query, a matrix or a metric and is run and:
   • Produces the appropriate display
   • Generates an HTML, RTF or CSV output file which is either to a specified location or a temporary file
5. A command, which runs a specified command, optionally using Command Directives to introduce variability into the command that is run
6. A document, which uses the Document Publisher to generate a specified document

Phase Hierarchy Database View

The phase hierarchy can be used to give a controlled view into the database. The concept is:

1. Create a node called Database, or whatever you prefer
2. Create nodes below this for subviews of the database, such as Feasibility or Design
3. Create nodes in each subview for those types of items that are relevant, in which each node is defined as a query which is presented directly in the phase hierarchy, and the query may be defined to only show the top-level items

For example:

In this hierarchy, we have two subviews called Feasibility and Design. In each subview we show only those types of information that are relevant to that subview, in this case user and system requirements and risks. The nodes User Requirements, System Requirements and Risks are defined to run appropriate queries with an Action set to Expand Phase:

and the queries are defined to only show the top-level items, for example:

The same phase hierarchy can be written in any native language, for example in Chinese:

With these definitions, users can expand the user or system requirements or the risks and see the top-level items in their database, and can navigate further as appropriate: