Introduction to CBR*Tools

1. Introduction

In many problem solving activities (control, forecast, assistance), it is necessary to take evolutions of observation variables into account. We propose to facilitate the analysis and the use of case-based reasoning (CBR) for this class of problems. CBR is a problem solving paradigm based on the reuse by analogy of past experiences.

Firstly, an indexing scheme by behavioural situations is proposed in or der to reuse cases, based on their relevant behaviours. This generic indexing scheme provides a representation formalism and guidelines. It allows the design of a better knowledge discovery process: extraction of potential cases, updating of potential cases saved as concrete cases, and facilitated interpretation of concrete cases.

Secondly, in order to facilitate the management and the use of our scheme in a complete reasoning cycle, an object-oriented framework is introduced, called CBR*Tools, which integrates specialisable hot spots and reusable components. The proposed model is based on use cases to structure hot spots, and on the systematic use of design patterns to comment and justify design decisions. Our approach proposes object-oriented models for CBR and allows the capitalisation of corporate objects for CBR.

Finally, we have applied our work to assist a group of users browsing the Web. In our system, called Broadway, extracted experiences from past navigations are reused to provide recommendations. Broadway is an example of our original approach to aiding systems, where we propose to reuse behaviours of users observed through a set of variables.

1.1.CBR*Tools - an Object-Oriented Framework

CBR*Tools is an original approach in the domain of Case-Based Reasoning, which is built around the idea of providing an object-oriented framework.

Frameworks are an object-oriented reuse technique, which represents reusable designs expressed in code, allowing in this way the reuse of both design and code. Frameworks represent a set of cooperating classes that consist a reusable design for a specific class of software. The most common definition for frameworks states that:

«a framework is a reusable design of all or part of a system, that is represented by a set of abstract classes and the way their instances interact».

Frameworks often provide the grounds to built an application, which can be customised by an application developer. For instance, a framework can be built in order to assist people to create compilers for different programming languages and operating systems. Well-known frameworks include OLE, OpenDoc, Java's AWT and Beans, etc.

1.2.Benefits of using an Object-Oriented Framework

By using an object-oriented frmamework, we achieve the following:

• Modularity. Frameworks encapsulate volatile implementation details behind stable interfaces. This way, software qulality is improved, as changes in the design and implementation are localised, allowing to easier understand and maintain existing software.
• Reusability. Frameworks contain the knowledge and experience of other people; by using a framework, we share the other people's expertise in an application domain. Frameworks provide stable interfaces that define generic components, applicable to new applications. Reusability means working based on previous knowledge and experience, without having to «re-invent the wheel».
• Extensibility. Frameworks provide hook methods that allow programmers to extend the functionality of a given framework and its stable interfaces. Extensibility allows customisation of new application services and features.
• Inversion of control. It is a runtime architecture characteristic of a framework, which allows the framework, rather than the application itself, to determine which application-specific methods to invoke as a responce to the occurance of external events.

1.3.How do we use a framework?

Because frameworks provide reusability, ideally they should provide components that can be easily connected to make a new system. Frameworks can be customised to a specific application by creating application-specific sub-classes based on abstract classes from the framework.

Frameworks can be used in various ways and differ from the object-oriented way of developing software, in the fact that an application must fit the framework.

When we start building an application we first have to design its framework. An application developed using a framework has three parts: the framework itself, the concrete subclasses of the framework classes, and the rest of the application. The latter often specifies the concrete classes to be used and how they will be interconnected.

We can use a framework by simply «glueing» its existing components: re-using its interfaces and components, without changing the framework. No knowledge of the precise specification is required in order to use the framework.

We can also define new concrete sub-classes to implement a framework. The new sub-classes are tightly coupled to their super-classes. So, one needs to have a good understanding of the abstract classes and the interfaces of the framework, before deriving any new concrete sub-classes.

The most difficult use of frameworks is to extend the functionality of its abstract classes that form the core of the framework. This is usually done by adding new operations and variables to these abstract classes. This method requires the source code of the framework and does not work towards the creation of open systems.

1.4.What is a hot spot?

Hot spot is a variable aspect of an application domain. Different applications belonging to the same domain differ with respect to some of their hot spots. In order to create an application from a given framework, the former supplies for each hot spot, one, or several of the different possible alternatives of the variablity. A hot spot allows to «plug-in» an application specific class or subsystem, which can be either selected from those supplied with a black-box framework, or by programming a class or subsystem in a white-box framework.

A hot spot is implemented by a hot spot subsystem . A hot spot subsystem contains (Figure 1):

• A (typically abstract) base class, which defines the interface for common responsibilities.
• Concrete derived classes, each representing one of the different alternatives for the variable aspect.
• Possibly additional classes and relationships.

A polymorphic reference typed with the base class is contained in, or attached to a hot spot subsystem. We can bind the hot spot, by setting the reference to a subclass object (when configuring the hot spot subsystem).

Figure 1: A hot spot sub-system

A method calling a base class operation (template or hook method) via this reference is dynamically bound to the subclass method executed. What happens when calling a hook operation depends on the way the hot spot subsystem has been configured. Thus, a hot spot subsystem introduces variability that is transparent to the remainder of the framework.

Hot spot subsystems are classified into:

• non-recursive, where a requested service is provided essentially from only one object;chain structured
• (1:1) recursive, where a requested service may be provided by a chain of subclass objects;
• tree structured (1:n) recursive, in which a requested service may be provided by a tree of subclass objects.

Design patterns help to determine the detailed structure of a subsystem. Most of the design patterns provide a different kind of variability. Thus a design pattern, is a proved solution for how to structure a hot spot subsystem in detail. Most design patterns are non-recursive hot spot subsystems.

1.5.Black-box and White-box frameworks

With respect to the techniques used to extend them, frameworks are classified into:

Black-box (or parameterised) framework. This type of framework is based on composition, and the behaviour of the framework is customised by using different combinations of classes. This type of framework requires a solid understanding of the domain. A black-box frmaework is used by instantiating existing classes and connecting them. (Figure 2 - left)

White-box (or inheritance-based) framework. In this framework, the user customises the framework behaviour through subclassingof framework classes. Most applications at the beginning of their life-cycle start as white-box frameworks, as their application domain is not very well-understood to enable us to parameterise the behaviour (i.e. to become a black-box framework). (Figure 2 - right)

Black-box frameworks are generally easier to use and extend than white-box frameworks, because they rely on object composition and delegation, rather than inheritance.

In general, a framework has parts that can be parameterised and parts that need to be customised though subclassing.

Figure 2: Hot spots in Black-box (left) and White-box framework (right)

1.6.Tailorability

One of the major difficulties when designing frameworks for open systems, is how to trade-off re-use (making software components as re-usable as possible) and tailorability (designing software architectures, easily adapted to custom requirements).

We need to clearly identify hot spots and specify framework contracts, that formalise exactly which parts of the framework can be re-used.

In order to create open systems, we are particularly interested in the creation of tailorable frameworks. In order for a system to classify as being open, the following requirements should be met:

• Interoperability. Refers to the integration of heterogeneous hardware and software platforms.
• Distribution. Cooordination of services and guaranteed execution of system-critical functions, are major concers for the distribution requirement
• Extensibility. Users should be able to extend the open system to satisfy their individual needs. System adaptability without changes in the internal structure is an important issue.

1.7.What is an Axis of Variability?

In order to make a system model into an open system architecture, we first need to identify the axes of variability. Taken as an example an open hypermedia system we can identify three characteristics, namely storage (how hypermedia are stored - http, ftp, file), presentation (how they are viewed - e.g. a browser); and navigation (how they can be linked - e.g. by page references). These characteristics form the basis for the creation of three variability axes: the storage axis, containing all document repositories; the presentation axis, containing all viewer applications; and the navigation axis, containing all kinds of linking relationships.

1.8.What are Design Patterns?

Frameworks are made in order to be re-used by applications. In this sense, frameworks used by different applications, represent a type of pattern, e.g. the Model/View/Controller framework.

According to the book "Design Patterns - Elements of Reusable Object-Oriented Software", by Gamma et al.: «Each design pattern systematically names, explains and evaluates an important and recurring design in object-oriented systems ». Design patterns are a powerful technique for re-use of software architectures.

Patterns provide software and design re-use as part of frameworks, and express the structure and collaboration of the components in a software architecture at a higher level than code or object-oriented design; patterns focus on individual objects and classes.

Patterns have in general four parts:

1. Pattern name - represents a handle, that we use to describe briefly a design problem, its solutions, and consequences, e.g. the «Chain of Responsibility» pattern. Naming patterns provides a higher level of abstraction and makes their use and documentation easier. The pattern name should be descriptive of the pattern's use, and it is used so that people can refer to the pattern.
2. Problem - describes under what circumstances to apply the pattern. It provides an explanation of the problem and its context and it may also include a set of conditions that must be met, in order to make sense to apply the pattern. The problem may describe e.g. specific design problems, such as how to represent algorithms as objects.
3. Solution - describes the elements of the design, their relationships, responsibilities and collaborations. Because of the abstract nature of the patterns, the solution does not describe a specific design or implementation. Instead, an abstract description of a design problem is provided, as well as how a general arrangement of elements (classes and objects) solves it.
4. Consequences - they represent the results and trade-offs of applying the pattern. Consequences should be taken seriously into account when evaluating design alternatives and for understanding the costs and (dis)advantages of applying a particular pattern.

Design patterns aim at creating reusable object-oriented designs, by naming, abstracting and identifying the key aspects of a design structure. Effectively a design pattern idenifies the classes involved and their respective instances, their roles and collaborations, and the distribution of responsibilities.

An example of a design pattern is the Composite. The Composite design pattern, allows the organisation of the objects in a tree structure in order to handle simple and composite objects uniformly. This pattern can be used to design a hierarchy of graphical components which will then be handled according to the same interface, no matter if they are simple or composite (Figure 3).

Figure 3: The Composite design pattern

The Composite pattern can be used to design a hierarchy of graphical components which will then be handled according to the same interface, no matter if the objects involved are simple or composite (Figure 4).

Figure 4: The Composite design pattern used for graphic applications (Gamma et al., Design Patterns - Elements of Reusable Object-Oriented Software, 1995)

Patterns support the development, application and documentation of frameworks.