12-10-2013_09-24-50 / [Simon_Kendal,_Malcolm_Creen]_Introduction_to_Know(BookFi.org)

Activity 11

This activity will help you visualise the relationship between the various models used in the KADS methodology.

Complete the following diagram that illustrates the relationship between the various models.

Task Model

Conceptual Model

Strategy

Task

Inference

Domain

FIGURE 6.6. The four-layer KADS model.

The Inference Layer

Knowledge is grouped into related units, or meta-classes and a useful classification system is devised. Relationships between knowledge may be identified and recorded in frames or semantic networks. In this layer, knowledge is being transformed from the linguistic level to the conceptual level.

Task Layer

This layer describes how the domain knowledge and inferences from that knowledge can be used to solve a specific task. It uses the conceptual links in the knowledge and then attempts to add the epistemological relationships.

Strategy Layer

This layer deals with the overall approach and planning involved in solving a problem. The aim is to identify problems in the knowledge-building process (e.g. inconsistent rules) at an early stage in the system design process. It therefore attempts to place a formal structure on knowledge, moving from the epistemological level to the logical level prior to implementation.

Activity 12

You are a knowledge engineer attempting to elicit knowledge to build a new ES. The knowledge domain is weather prediction. You are currently working on a module to forecast the amount of rainfall.

Knowledge from the expert indicates that there are many variables affecting accurate weather forecasting including wind speed and direction as well as overall temperature, not only on the ground but also in the clouds. The expert notes that rainfall may be preceded by a fall in temperature, while winds blowing off the sea to the west provide an increased chance of rainfall.

As far as the information allows, start to produce a four-layer model for a KBS by outlining which components of the model will refer to the information and knowledge available.

Feedback 12

You should have been able to produce an outline similar to the following:

Domain layer

Data concepts include: temperature, wind speed, wind direction, amount of cloud cover, etc.

Inference layer

Inferences from the data concepts will include:

Falling temperature indicates increased probability of rain.

A westerly wind from the sea normally provides increased chance rain.

Task layer

The basic task or reasoning technique is chosen, with a decision being made concerning task-driven or goal-driven structures (or alternatively a choice will be made between backward or forward chaining).

Strategy layer

The formal structure of the knowledge is identified (this is a forecasting model) and the appropriate data structures designed.

Strengths and Weaknesses of KADS

A major advantage of the KADS approach is in the idea of generic task models (GTMs), also known as interpretation models. These can be thought of as skeleton models for typical tasks or task fragments, such as ‘classification’ or ‘system diagnosis’ stored in generic task libraries. Knowledge engineers can use suitably chosen GTMs to guide the knowledge-acquisition process in a new domain, refining and combining GTMs to produce a fully specified model.

KADS does have weaknesses, for example:

It is difficult to translate between or connect the different layers.

All the layers are rarely used; most people tend to use the diagrams, but these are not expressive enough for all requirements.

KADS systems typically end up with large amounts of documentation for relatively modest systems and are hard to change.

KADS does not itself specify the representation types to be used in describing its various models.

The last point is important, since we must decide what our needs are for representations. Suitable representations must have a two-sided functionality, i.e., they must be able to:

express the language of the testing techniques

describe systems in such a way that they are recognisable to those who must contribute to the development of evaluation models.

Summary

In this section you have seen how the KADS methodology can be used to construct a variety of models to bridge the gap between required behaviour and system behaviour for a KBS.

Web Links

CommonKADS

http://www.commonkads.uva.nl/frameset-commonkads.html

SECTION 5: THE HYBRID METHODOLOGY (HyM)

Introduction

This section provides an introduction to HyM and its use within the design of hybrid intelligent information systems (HIISs).

Objectives

By the end of the section you will be able to:

evaluate the place of HyM in knowledge engineering.

Hybrid Methodology (HyM): An Introduction

HyM is a more recent ES development methodology—developed, in fact, at the University of Sunderland—aimed at supporting the creation of HIISs. It aims to provide an enhanced software development life cycle that supports project development both incrementally and in one go. The methodology recognises that many information needs in society can be satisfied by the development of conventional information systems. However, additional use could be made from these systems by integrating intelligent or KBSs with them.

Activity 13

This activity will help you understand the concept of HIISs by asking you to integrate what you know of conventional information systems with the knowledge of KBSs you have gained so far from this book.

Compare and contrast the main features of conventional information systems and KBSs.

Interface design

Implementation

Integration and maintenance

FIGURE 6.8. The HyM life cycle (in more detail).

HyM Development Life Cycle

The HyM development life cycle in more detail looks like Figure 6.8.

As already suggested, the development follows the standard life cycle approach with all systems going through the phases of:

Feasibility study

Analysis and design

Implementation

Evaluation

Integration and maintenance.

The life cycle also includes some iteration, within the combined analysis and design stage which can be completed using incremental prototyping.

Looking at the analysis and design stage of the HyM life cycle in even more detail (see Figure 6.9), we can see that provision has been for the development of user

FIGURE 6.9. Integrating user modelling into HyM.

models. By explicitly promoting the creation of user models the HyM methodology is recognising that different system users have different needs, this is particularly true for the users of HIIS, and by modelling these needs a system can be developed to take into consideration the individual needs of the user when responding with advice or recommendations.

The HyM life cycle bears some similarities to both the Waterfall model and the evolutionary prototyping approach to software development.

The HyM Life Cycle and the Waterfall Model Compared

The classic Waterfall life cycle is simple to understand but as a tool to control a software-engineering project, fundamentally flawed. It implies a strongly sequential process through the steps of systems analysis, design, coding, testing and maintenance. It presumes that at the end of the analysis stage all of the details and functionality of the required system can be determined. However, as many projects have shown, it is not always possible to obtain a perfect set of requirements and this has caused many projects to overrun in terms of development cost and time.

Even when adapted to allow previous stages of the life cycle to be revisited, the Waterfall model is still flawed. While previous stages can be revisited, it still strongly implies moving forward through the life cycle and that by revisiting previous stages a backward step is being taken. Furthermore it implies that at the testing stage it is permitted, presumably sometimes even necessary, to go back as far as the analysis stage. This has specific implications for the cost of any softwareengineering project. To find out during the design phase, that more analysis is required has quite different cost/time implications than finding out during the testing phase.

In particular, when developing KBSs there is a particular difficulty to be addressed—this is specifying the knowledge to be contained with the system. It is very difficult when developing a KBS to define exactly what knowledge is required. For example, if a KBS is advising a university applicant about suitable courses it should presumably offer advice based upon the subject and career interests of the applicant but should it also assess the applicant’s academic suitability and personality traits? When assessing academic suitability should it assess intellectual skills only or other skills such as creative, group work, communication and social skills? This problem is aided by the use of a prototyping life cycle where the knowledge base can be iteratively evaluated and gaps in the reasoning process identified and corrected. Finally, it will be shown by demonstration that the reasoning capabilities of the knowledge bases are adequate even when it was impossible to initially define what knowledge was required.

Thus by comparison with the Waterfall model, HyM has an integrated analysis and design phase with a highly iterative loop. Preliminary analysis is followed by preliminary design and then by an evaluation stage. These three steps are repeated until evaluation shows that the analysis has fully captured the requirements of the knowledge base components and that the design adequately reflects those requirements.

Throwaway prototypes are used as part of the analysis stage.

Activity 14

This activity helps to interpret the advantages the HyM life cycle has over the Waterfall model.

Drawing on your knowledge of the Waterfall model gained in previous modules, suggest what advantages are available with the HyM life cycle.

Feedback 14

You should have been able to suggest some of the following:

There is no implication that analysis should be finished prior to the design starting with implied failure when this is not the case.

Contrary to this there is a strong implication that more analysis will be required after preliminary design has taken place. In doing the preliminary design a better understanding of the problem can evolve and this knowledge can help guide the further analysis that will be required for complex projects.

Emphasis is placed on evaluation. This is essential to ensure that the finished analysis fully captures the requirements for the system and that the design of the system is also satisfactory. Thus, when the analysis is finished we can have confidence in the final product.