|
Designing an application: Estimation of the complexity of the use of CBR*Tools2.4.Complexity of CBR*ToolsAn estimation of the complexity of use of our platform is provided. First of all, the minimum effort to implement in order to build simple applications is estimated. Then, the systematic dependencies between hot spots, which are dictated by the platform are given. 2.4.1.Minimum effortThe minimum effort represents the hot spots to be specialised obligatorily, the other hot spots are being provided with a default value or a set of directly reusable components per instantiation. It is also necessary to distinguish the specialisations guided by the application and specialisations necessary to declare and build the system with the platform. For the level "CBR", a new system must obligatorily define the phases of the reasoning (retrieve, re-use and retain, the phase of revision is often missing), the representation of the cases and the indices, and finally a strategy of indexing which generally uses a similarity (Table 1). It is finally a question of defining the factory of the reasoning system, which allows to state the components to be used (ReasonerFactory). Thus, the built system of reasoning configures the 8 obligatorily specialised hot spots, while defining a specific case base (the volatile case base per defect not being adapted).
Table 1: hot spots to be obligatorily specialised for an application at level "CBR"For an application using the indexing by behavioural situations, 14 hot spots have to be specialised obligatorily, of which only 5 are new and specific to this type of indexing. It is indeed a matter of defining the entries, the structure of the instantaneous component, the elementary types of behaviours, at least one pattern of potential cases, a filter of indices to build the restriction and the declaration of the pattern in the base of the patterns (Table 2).
Table 2: hot spots that need to be obligatorily configured for an application at level "Indexing by behavioural situations"2.4.2.Systematic dependencies between the hot spotsTo facilitate the use of the platform and to evaluate the complexity of the relations between the hot spots of CBR*Tools, the exhaustive list of the systematic dependencies between the latter, which are imposed by the platform, is given below. These dependences are of two types:
The axis of the management of the reasoning includes the hot spot ReasonerFactory, which is replaced by TimeExtendedReasonerFactory for the purposes of the indexing by behavioural situations. This hot spot is central for the declaration of the types of objects to use in a system of reasoning. Thus, many relations of dependency point towards the factory (Figure 1).
Figure 1: dependencies of the axis "management of the reasoning"For the axis of the representation of the case s, the definition of the pattern of potential cases is a significant hot spot. A pattern of potential cases have to use the whole set of the types of objects being used to build a case (Figure 2).
Figure 2: dependencies of the axis "representation of the cases"Lastly, the axis of the organisation of the memory includes in particular declaratory dependencies (Figure 3). However, the definition of a field of values for the similarities requires that elementary functions of similarity as well as the functions of aggregation are defined on this domain.
Figure 3: dependencies of the axis "organisation of the memory"The configuration of a hot spot thus, involves few systematic dependencies, in particular due to the centralisation of the majority of the declarations in the factory. However, these dependencies take into account only part of the semantic relations, which can exist between the hot spots. These relations, strongly dependent on the application concerned, can become very complex. For instance, the introduction of a new controller of reasoning can require the modification of the types of results of the phases. To produce these results, the phases themselves are likely to be modified as well as the organisation of the indexing of the memory and the representation of the cases. The documentation of such dependencies exceeds the scope of our work, and would require a methodology of design of CBR systems coupled with a high-level documentation on the framework itself, for example in the form of use scenarios. Brigitte Trousse Last modified: Fri Sep 28 13:49:15 MEST 2001 |