The TOOLKIT Decision Support System
The primary objective of the DESSERT Toolkit is to allow the user to design and
develop new applications in the domain of service management by combining and
adapting software modules. The user is thus supplied with:
- software tools, which perform generic and recognisable service management
tasks;
- facilities to choose the convenient modules, to adapt them to the
particular needs of the application, and to make them interact;
- facilities to generate an application, its problem control solving
structure, and its access to the database.
The Toolkit architecture
The main entity in the Toolkit is the tool; a reusable software
module, which addresses a particular task in the domain of software management.
A tool may interconnect the functionality of several
tool-components, which are basic modules performing some
technical (not domain oriented) tasks. The architecture also defines
models of information, which are used by several tools.
The process of developing a new DSS using the DESSERT Toolkit involves a number
of stages during which the user makes choices and explores options. The toolkit
provides Development Facilities which support the user is making choices
and comparing alternatives during each of the stages. An overview of the
stages, and the facilities that provide support, is as follows:
Figure 1: Stages of development of a DESSERT
application
The Development Facilities
A brief description of each facility that supports the user when building a new
service management DSS is given below:
Requirements Capture
The Requirements Capture facility helps the user to express requirements using
service management domain terms. Individual requirements are expressed in terms
of manipulations (type of action) and domain objects (on which actions might be
performed). The user builds a hierarchy of requirements covering the desired
functionality of the new DSS.
Task/Tool Matching
The Task/Tool matching facility is a forum for the user to explore whether
tools are available that can support one or more of the new DSS requirements.
The facility uses a matching process to find tools that might be suitable to
support a given requirement. The matcher uses the requirement's manipulations
and objects to rank the quality of the matches and provide the user with a
sorted set of results in best order. In this way, the user can browse the
toolkit contents in a directed fashion. The facility also enables the user to
match requirements against tasks, which are descriptions of generic high-level
activities in the domain.
Tool Description
The characteristics of the tool, such as task achieved, input/output data and
techniques used are displayed.
Tool View
The selected tool is invoked from the Toolkit, on a predefined set of data. The
user may thus evaluate the quality of support supplied by the system and
possibly choose between two tools achieving the same task.
Tool Customisation
As the tools intend to achieve generic tasks, that won't perfectly fit the
requirements of a new application. The "tool customisation" facility allows the
user to modify the data used by a tool (such as catalogues, cases library by
instance), as well as its behaviour. This is performed by altering pre-defined
values (threshold values, matching rates by instance) or characteristics
(interactive / background tasks, contents of menus).
Control Flow Capturer
This stage intends to build the behaviour of the developed application, by
defining runtime constraints between the tools. The user may wish to define
sequences of tools (i.e. series of tools that are to be fired one just after
another), choices between tools, or to have tools working on parallel on the
same data. Several other characteristics can also be altered.
The Control Flow Capturer is independent from the problem solving control (PSC)
that is to be used in the application, but the specifications captured at this
stage are translated, during the application generation, into constraints
towards the PSC.
Interfacing a database and application generation
The function of the STEF (Schema Translation and Evolution Facility) is to
create a Database Access Interface (DAI) when the application schema and the
database schema (described in MODEL) are different. In order to create the DAI,
the STEF performs mappings between the two schema. User interaction is required
to complete this task, which is divided in two phases, that of matching the two
class hierarchies and that of matching class contents. When the matching
process is finished, the DAI code is generated.
The generation phase covers the copy of the necessary files (tools, models,
...), as well as the generation of the application structure (PSC,
communication functions between tools, ...).
Keywords.
Tools reusability. Faceted classification scheme. Customisation. Control Flow.
Problem Solving Control. Application schema.
