Política del Ecuador en materia de refugio

4.6 METHODOLOGY PROTOTYPING

The components of a single methodology as described in section 4.4 are only the passive components of methodology prototyping. The whole system will require a program to drive the semantic knowledge. Such a system consists of four main parts as shown in figure 4.6: a method controller, a concept dictionary, a reference system and a context memory. The requirement specification prototyping examines the problem domain and environment, and generates a list of requisite concepts. These concepts are then given to the method prototyping, and they are matched against the concepts in the canonical concept dictionary. The method controller searches the semantic information in the multiple methodologies semantic knowledge base. Matching concepts or fragments may be used to construct an appropriate method for that particular application. Such method semantics are input to a competent metaCASE tool to form a suitable CASE tool.

M etaC A SE Tool M ethodology Prototyping R eq u irem en t v Specification > Prototyping C ontext Controller Dictionary R eferen ce Multiple M ethodologies P roduct Model P ro c e ss Model H euristic Model

Figure 4.6 Proposed Methodology Prototyping

The method controller is the driving program of the methodology prototyping. It communicates directly with various parts of the semantic knowledge base. The product model is used for matching purposes. The process model shows the capability of creating sharable fragments. The heuristic model provides guidance for the above two models. The context memory is the working memory. It should be closely related to the controller to store information such as instantiated values, backtracking tree and the newly composed semantic model. Moreover, the canonical concept dictionary and the system references are the internal data of the method controller. They give collected information about the semantic knowledge base. These components for methodology prototyping are discussed in the following subsections.

4.6.1 METHOD CONTROLLER

The method controller is an executable program, with a structure dependent on the complexity of other parts of the system, such as the semantic knowledge base. The static information of methodology prototyping is stored separately in the concept dictionary, which is decribed in the next section. The internal structure of the controller is complex. It is impossible here to describe the full details of the controller, but we do list the basic features that it must contain.

Inference Engine - An intelligent guidance system that leads the user through the process model or even chooses method fragments according to the need of their chosen application domain. The engine indicates which step or rule that the system is considering and provides useful help prompts. Some heuristics in the semantic knowledge bases are deduced from work experience. A developer may refer to them as guidance, but the system will allow the developer to override the rules in certain circumstances.

Explanatory Program - The controller shall always be able to answer questions such as why it is doing this or how it has reached such a conclusion. This is a basic requirement for an expert system. During software development there are many heuristic decisions that the developer has to make. These are not just based on the problem/application domain requirements, but also upon the software requirements, such as time-space constraints, software libraries available and budgets etc. An explanatory program allows the developer to look at the heuristics underneath the system. These considerations also apply to the user defined sub-rulesets below.

User Defined Ruleset - The user must be allowed to create their own ruleset for their particular environment or application. This ruleset must integrate with the pre-defined system ruleset and adopt the same format. It may also require a consistency checking program to detect any contradictory or redundant rules.

Human Computer Interface - A complex system such as this must employ a user friendly interface. WIMP technology is used, which also provides menu selections, pop-up messages, hypertext helps. Hot keys, such as exit, help, info, forward, backward etc, must be supported at any point in the system.

Text and Graphical Editors - Since the design representation involves both text and graphical notations, the controller must provide facilities to edit text and graphics. A facility for cross checking these two representations and any attached context sensitive help must be provided. Therefore these must be closely related to the inference engine and any explanations which may be presented to the user.

CUIIUUUS

4.6.2 CANONICAL CONCEPT DICTIONARY

A canonical concept dictionary is a crucial component in methodology prototyping. It not only provides the canonical concepts for semantic matching, but also provides the concept description in the semantic knowledge base. The concept dictionary can be used to provide context-sensitive help information.

From a method engineer’s point of view, it is an index book for selecting concepts in software development methods. The dictionary a set of canonical representation of concepts, which are linked to the corresponding semantics in the knowledge base. If a method fragment matches most of the requirement concepts it can be dissected from the method and used to develop the current application.

From a software developer’s point of view, he/she can either highlight the appropriate object on screen or get the description through the help button. Each key word or key phrase is given a token key, which is used to search through or to select from the dictionary database. The following Prolog clause shows the definition record of token key object, its contents include a description, an examples field, a seeAlso field and a sources field. The seeAlso field allows the user to look at other related records and the sources field points to the (physical) source of the original citation.

dict(object,[

desc('An object is a concept, abstraction, or thing with crisp boundaries and

meaning for the problem at hand. Objects promote understanding of the real world as well as provide a practical basis for com puter implementation.'), exam ples([Joe Smith, Simplex company, process 7648 and the top window]), seeAlso([class, identity, objectClass, objectModel, objectDiagram, type]), sources([ref(rumbaugh91)])

1

One can imagine the desc and seeAlso fields to be analogous to the text and link fields in the heuristic knowledge base (see chapter seven). However, the concept dictionary is used to relate the terminology of a method, and no heuristic rules should be included.

Apart from providing the definition of the terminology of a single, exclusive method, the concept dictionary serves another significant purpose. That is to filter out any contradictions or similarities of terms between methods. This is an important issue in supporting the communication through tool fragments.

The canonical concept dictionary has a literary bias. It is not the central repository. This is provided by the knowledge base itself, of which the dictionary is a part. Perhaps the terminology is confusing but it has been chosen from the viewpoint of the method user/developer, rather than that of the software/database engineer.

4.6.3 SYSTEM REFERENCES

The system also provides a facility to refer all information to texts, for example books or papers. The example below shows the reference record of [Gomaa 93]. It includes the fields:

author, year, title and others. The others field provides sufficient information to locate the material. In this simple example, a crude index has been used. In the software tool system to be developed, a user defined custom index which can include bookmarks, as well as commercial library indexing standards (ISBN and ACM indexes) is supported.

reference(ref(gom aa93), [ author(['Gom aa H.']), year([1993]),

title(['Software Design Methods for Concurrent and Real-Time Systems']), others(['Addison-Wesley'])

3).

4.7 CONCLUSION

This chapter introduces an evolutionary approach to software engineering based on methodology prototyping. Various components for such prototyping approach are identified. The core discussion deals with the semantic knowledge base of the software methods. It is the crucial part of this software developement approach. The three constituents, namely the product model, the process model and the heuristic model, are introduced. The structures of the three models are discussed in the subsequent chapters.