HEURISTIC MODEL

Chapter five and six introduce the two main models in GMR. However, the method model is imcomplete unless it is accompanied with the heuristic information embedded in the method. This chapter is concerned with a pragmatic approach to incorporate method heuristics in our meta model.

7.1 INTRODUCTION

Heuristics can be considered as experience that is obtained by domain expertise. Some heuristics give a detailed description of the method concepts. This may be the definition of a particular semantic or guidance to use the information. Other heuristics outline the processes of software development. They may provide assistance of the task involved or design decisions needed to be considered. Since these semantics are closely related to the concepts and techniques, they should be documented as part of the SDM.

Both ALF-MASP and SOCRATES address the existence of method heuristics (see chapter three for details), but they treat heuristics lightly in their meta model representation. Besides, most metaCASE tools, such as ToolBuilder, simply assume the semantics are well-known to the tool user (see chapter eleven). There is no specific denotation of heuristics.

[Clancey 85] presents a heuristic classification model for characterising different kinds of problems. The emphasis is on problem-solving reasoning and particularly in psychology rather than software development. However, the idea is notable in considering different types of heuristics in SDM. [Causse 93] defines a heuristic level of description for heuristic control knowledge which is based on the control roles central to the approaches of KADS. The KADS views of domain level and reasoning level correspond to our product model and process model respectively. Although heuristics have a close relationship with the two levels (models), we believe that it should not be treated as an interface between them in meta modelling. GMR describes a heuristic as a pragmatic structure which can be attached to other semantics of the method. It provides guidance and defines the usage of the associated semantic. This structure has been tested and evolved from the five chosen methods (see appendices F and G).

This chapter is organised as follows. Section 7.2 defines the structure of method heuristics and classifies it as concept heuristic or task heuristic. The three fields of a heuristic record:

text, rule and link, are described in sections 7.3, 7.4 and 7.5 respectively. Section 7.6 illustrates the mapping of the heuristic model to the other two models and section 7.7 gives a conclusion.

7.2 METHOD HEURISTIC

The method heuristic is one of the important structures of a single method, because it is the kernel of any semantic system. The heuristic system is the semantic assistant embedded in both the product model and the process model. It can be a definition of a diagram or of a notation. Alternatively it could be a design guidance or a design rule of a software development process. Therefore they are not prescriptive.

There are two types of heuristic: rules and criteria (guidance text). However, to enhance the method heuristic, we introduce links to enhance the cross referencing mechanism of heuristic records in the semantic knowledge base. Since a method heuristic must refer to a semantic of the product model or the process model, each heuristic record is addressed by the name of the semantic in their respective model. In addition, each record contains three fields which are the

text, the rule and the link. Figure 8.10 (in next chapter) presents a full BNF grammar of the heuristic specification language, here is the simplified definition of a heuristic record:

heuristic HeuristicName; text HeuristicDescription; rule Conditions [=> Action] ; link ListOfHeuristicNames;

These fields are explained in more detail in the subsequent sections. Essentially, any heuristic whose action is determined by pre-conditions and is definitive in its logic may be automated in a production rule system. Such heuristics are described by the rule subfield. Where it is possible, this is the most desirable subfield to use, since such decisions can then be made (optionally) transparent to the user. This hides the complexity, shortening development time and can reduce errors by permitting automation. Any heuristic which is ambiguous, open to interpretation, context dependent or optional has to be described by the text subfield. The link subfield is rather special and empirical experience has shown it to be necessary, in documenting the heuristics of a method.

Before any further description, it is essential to identify different types of method heuristics. From the nature of method heuristics, we classify them into two categories: concept heuristic

and task heuristic. They are defined in the following two subsections and further descriptions are given in the discussions in sections 7.3 to 7.5.

7.2.1 CONCEPT HEURISTIC

Chapter two states that different concepts may be used to describe various semantics in software development. It is important to give a clear specification of each concept that has a definitive meaning apart from the concept name itself. Therefore the description of a concept with necessary examples are significant heuristics of the method. This information is stored in the text field of a heuristic record, which is known as a concept heuristic.

The rule field of a concept heuristic is usually empty. If the concept is constrained (section 5.3.2.6), then the field is used to record the constraint rules for consistency checking. This rule is triggered whenever any concept functions associated with that concept instance are fired. This rule is generally a conditional rule without action; or otherwise the action of the rule is that the concept instance itself does not exist. For instance, the following heuristic record of the dataFlow concept in OMT, the rule restricts any dataFlow instance not to connect between an actor instance and a dataStore instance directly, (see section 7.4)

heuristic dataFlow;

text 'Data flow is the connection between the output of one object or process and the input to an o th er.';

rule not( source(actor) and target(dataStore)) or not( source(dataStore) and target(actor));

link actor, dataFlowDecomposition, dataFlowDiagram, dataStore, process ;

In a concept heuristic, the link field contains a list of concepts that are concerned with the heuristic. This link is usually denoted by a relationship of the concept in the product model. However, other non-directly associated concepts may also occur. They provide the cross referencing mechanism in defining the meaning and/or constraint of the original concept.

7.2.2 TASK HEURISTIC

A task describes a software development process based on the concepts recorded in the product model. The process model shows what are the interrelationships between tasks and defines the structure of an individual task. Each task is comprehended by a task heuristic that provides a detail specification of how can the task be used. The following heuristic record illustrates the task1 taskCohesionCriteria in Codarts/DA:

heuristic taskC ohesionC riteria;

text 'Task cohesion criteria address whether and how transformations should be grouped into concurrent tasks.',

'There are four types of task cohesions: temporal cohesion, sequential cohesion, control cohesion and functional coh esio n .';

rule 'Two transformations are constrained so that they cannot execute concurrently and hence must execute sequentially' => do(taskC ohesion);

link temporalCohesion, sequentialCohesion, controlCohesion, functionalCohesion ; The text field supports the task with a textual description, which can be a general guidance or criterion for the execution of the task. Besides, it acts as an English specification of the rule

field. It can be displayed as help information to assist the software developer with the task. The rule field of a task heuristic denotes a design decision as a production rule. The antecedent of a rule comprises the AND-OR statements of a design situation, whereas the consequence may trigger a task function.

1 It must be clear about the difference of tasks in the method model (by GMR) and the software model (say by