Ingredients for Developing a Case-Based Reasoning ... - CiteSeerX

Ingredients for Developing a Case-Based Reasoning Methodology Ralph Bergmann1, Wolfgang Wilke1, Klaus-Dieter Althoff2, Sean Breen3, & Roy Johnston3 1 University of Kaiserslautern Centre for Learning Systems and Applications (LSA) PO-Box 3049 D-67653 Kaiserslautern, Germany Email: {bergmann | wilke }@informatik.uni-kl.de 2 Fraunhofer Einrichtung für Experimentelles Software Engineering (FhG IESE) Sauerwiesen 6 D-67661 Kaiserslautern, Germany Email: [email protected] 3 Interactive Multimedia Systems (IMS) Clara House, Glenageary, Co. Dublin, Ireland Email: {sean | roy}@cxa.ie

Abstract Building a methodology for developing CBR applications is an important goal currently addressed by CBR researchers and practitioners. Since CBR application development is a special kind of software development, building a CBR methodology can certainly be viewed as a software engineering research and development activity. This paper presents a perspective of how software process modelling, which is a recent approach in software engineering, can be used for building a case-based reasoning methodology. We analyse existing activities in CBR methodology construction and show how they can be used as ingredients in a methodology that is built using software process modelling.

1.

Introduction

Recently, several activities have/had been initiated with the goal of establishing a methodology for developing case-based reasoning (CBR) applications. A methodology usually combines a number of methods into a philosophy which addresses a number of phases of the software development life-cycle (e.g. Booch 1994, chapter 1). A methodology should give guidelines about the activities that need to be performed in order to successfully develop a certain kind of product, e.g. any kind of software system, a knowledge-based system, or - as in our case - a CBR application. A methodology should make the development an engineering activity rather than an art known by a few experts (cf. Shaw, 1990; Gibbs, 1994). A methodology should cover:

• the process of project management (cost and resource assessment, time schedules, project plans), • the process of product development and maintenance: particularly product selection (e.g., of CBR tools), software development and world modelling required to build a running CBR system • the specification of the different kinds of products or deliverables (including software deliverables) that must be produced, • the analysis and reorganisation of the environment (e.g., a department) in which the CBR system should be introduced. One of the main driving forces behind the development and the use of a methodology relates to the need for quality in both the products and processes of the development of computer-based systems. Contemporary organisations can no longer sustain inefficient or ineffectual IT systems development. IT systems are increasingly seen as a means of gaining competitive advantage over rivals in the marketplace. The use of an appropriate methodology will provide significant quantifiable benefits in terms of productivity (e.g., reduce the risk of wasted efforts), quality (e.g., inclusion of quality deliverables) and communication (a reference for both formal and informal communication between members of the development team) and will provide a solid base for management decision making (e.g., planning, resource allocation and monitoring). This general observation holds for software development in general and for case-based reasoning application development in particular. Today, a few companies have specialised in developing CBR applications but they still perform this as an art rather than an engineering activity. This will also create serious problems in case of staff departures, particularly when new staff must be trained. Contributions to the goal of developing a methodology for CBR can be found in books on CBR (Kolodner, 1993 chapter 15; Wess, 1995 chapter 6) and in papers collecting the experience of people who have sucessfully developed CBR applications (e.g., Lewis, 1995; Bartsch-Spörl, 1996a; Curet & Jackson, 1996); most valuable experience-based contributions arose from projects where methodology development was explicitly included as one project task, like INRECA1 (Althoff, Wess et al. 1995; Johnston, Breen, & Manago 1996) or APPLICUS2 (Bartsch-Spörl 1996b). The main focus of the INRECA-II3 Esprit project is the development of such a methodology for CBR applications in the area of diagnosis and decision support. As a first contribution to methodology construction, this paper provides a preliminary systematic analysis of existing work on CBR and on frameworks describing certain kinds of case-based systems, but most importantly positioning work from other areas such as software engineering (SE) and knowledge engineering (KE) in the light of methodology development.

2.

Software process modelling

Software engineering is concerned with aspects of software development and maintenance; planning of software developments projects; performing development and project management, including quality assurance (Rombach & Verlage, 1995). Particularly, SE is concerned with principles, methods, techniques, and tools that can support these activities. Since CBR application development is a special kind of software development, building a CBR methodology can certainly be viewed as a SE research and development activity.

1

INRECA: Esprit Project P6322. Partners: Acknosoft (prime contractor, France), tecInno (Germany), Interactive Multimedia Systems (Ireland), University of Kaiserslautern (Germany) 2

APPLICUS: Esprit Trial Application P20824. Partners: Acknosoft (prime contractor, France), BSR Consulting (Germany), Sepro Robotique (France) 3

INRECA-II Esprit Project P22196. Information & Knowledge Reengineering for Reasoning from Cases. Partners: Acknosoft (prime contractor, France), Daimler Benz AG (Germany), tecInno (Germany), Interactive Multimedia Systems (Ireland), University of Kaiserslautern (Germany)

Like other methodologies that have been proposed in the area of software engineering4 in general, a specific case-based reasoning methodology needs an overall philosophy. The philosophy must break the life-cycle of the case-based reasoning development into phases and present clear links between the phases. The philosophy defines the roles to be filled in the development of the application and allows the team to have a coherent and consistent view of the path to a successful application (Breen & Johnston 1996). 2.1 Software Process Models One area of SE that can provide such a philosophy also for a CBR methodology is software processes modelling (Rombach & Verlage, 1995). In this area, one distinguishes between product engineering process models and process engineering process models. • Product engineering process models model the engineering of the product, i.e., the software that has to be produced. Unlike early approaches in SE, the software development is not considered to follow a single fixed process model with a closed set of predefined steps. A tailored process model particularly suited for the current project must be developed in advance. Product engineering process models include technical SE processes, like requirements engineering, design (of the system to be built), coding, etc. and managerial SE processes, like management of product related documentation, project management, quality assurance, etc. From time to time, such a model must even be refined or changed during the execution of the project if the real world software development process and the model do not match any longer. • Process engineering process models model the development and the evolution of these product engineering process models which avoids that product engineering process models must be constructed for every project from scratch. In the following, we are not so concerned with process engineering process models but with product engineering process models (briefly called process models) only. 2.2 Representing process models Several representation formalisms and languages have been already developed for representing process models. MVP-L (Bröckers, Lott, Rombach, Verlage, 1995) is one such language and CoMoKit (Maurer, 1996) is a system developed for this purpose at the University of Kaiserslautern. Most languages for process modelling allow - more or less formally - to systematically define the task, products and resources that the process models consist of. 2.2.1 Tasks A task describes an activity which must be carried out during the process enactment. The description of a task is typically characterised through: • input and output items: Items are product objects, e.g., documents, data, code, specifications, etc. • entry and exit criteria: conditions that are fulfilled to allow to enter or finish the task. • methods: a description of a set of alternative methods that can be used to accomplish the goal of producing the required output items. A method describes how the output is created. A method can be atomic or complex. Atomic methods describe how the task can be performed, i.e., by the use of a specific SE tool. Complex methods specify a set of sub-tasks into which the task can be decomposed and they specify how input and output items of these sub-tasks are related. Task decompositions are of particular importance since they allow to organise a process model in a hierarchical way allowing different kinds of refinements by a specific sub-process model.

• resource consumption: which resources, e.g., personal, tools, etc. are required to perform this task.

4

A lot of different methodologies have been developed in the area of software engineering; see e.g. (Booch, 1994) for a brief survey.

2.2.2 Products Besides the modelling of tasks, process modelling languages such as MVP-L also include means to describe products. These products are used as the input and output items of tasks. The main goal of a development process is the development or maintenance of a deliverable software product. In addition to the final product, by-products, artefacts, and parts of a product’s documentation are similarly called products. Product models also include a set of attributes which describe the current state of the product. For example, an attribute such as product_status may have one of the values non_existing, incomplete, or complete. 2.2.3 Resources The third category described by process modelling languages are resources, i.e., entities that are necessary to perform the tasks. Active resources are organisational entities (e.g., teams) or humans in the real world designated to perform processes. Passive resources are tools which are used to support the performance of a process. 2.3 Benefits of process modelling for a CBR methodology We expect that process modelling languages lead to several benefits within the scope of a CBR methodology. First of all, they provide a philosophy in combination of a particular notation for writing down a methodology. Moreover the following important benefits can be identified: • It supports communication within team members developing a CBR application (which is a general benefit of the methodology). • It supports to control and monitor the CBR development. • Because of its hierarchical nature, it allows one to first start with an abstract process model and to refine the important or difficult steps when the methodology grows, also based on the experience gained from its application. • It allows one to share CBR development experience (c.f. experience factory (Basili et al., 1994; Althoff & Wilke, 1996)). • It allows one to analyse (and reason about) the CBR development and to derive improved development processes. • Workflow management techniques (Workflow Management Coalition, 1996) can be used to organise and co-ordinate technical and business processes. They provide tools and methods to support the management of projects. One major benefit that is expected to result by using these techniques is the co-ordination of resources and tasks in a CBR development project. More advanced techniques (e.g. Maurer, 1996) can also assist by re-planning the project during the execution of the project during the development.

3.

Using software process modelling case-based reasoning methodology

for

developing

a

Using software process modelling for developing a CBR methodology does not mean to build a static set of activities or a single project plan that is appropriate for all kind of CBR projects. Moreover, the approach allows to describe different CBR specific activities (called tasks), both technical and managerial, at different levels of abstraction and in a hierarchical way. 3.1 Components of the methodology CBR methodology built using software process modelling should consists of: • a set of task, each of which denotes a complex or elementary step required for • CBR application development (technical task) or • managing the CBR application development (managerial task).

Examples of such complex tasks can be: „define the scope of the CBR project“, „characterise the sources of information available in the organisation“, „define the content of a case“, „select a CBR tool & platform, „case modelling“ „define similarity measures“, „define general knowledge and adaptation knowledge“, „execute initial case acquisition process“, „test and validate the CBR application“, etc. • a description for each such task in the way sketched in section 2.2.1 (input- and output items, entry and exit criteria, resource consumption, methods). For example, the task of „case modelling“ would require as input a documentation describing the „content of a case“ and the „user manual“ of the selected CBR tool. It delivers as output a descriptive model, e.g. in CASUEL (Manago, Bergmann, et al. 1994) format. Concerning resource consumption, this task requires a CBR specialist using a model-editor-tool. This complex task must be further decomposed to the four sub-tasks „analysis of available information“, „modelling of types“, „modelling of concepts“, and „model validation“. • a set of product descriptions that describe the products like descriptive models, case-bases, CBR prototype, technical environment (user-interfaces, hard- and software), documentation, etc. as well as their attributes such as status. The CASUEL language specification (Manago, Bergmann, et al. 1994) is one such product description. • a set of resource descriptions that describe the required human resources like domain expert, problem owner, software developer, CBR specialist, etc. and technical resources like descriptive model editor, case manager, validation tool, etc. 3.2 An Example The example in Figure 1 shows a graphical notation of the simplified description of the task of „case modelling“. The task is represented as a box, products are represented as ovals an resources are represented as rhombi. This task description indicates that for case modelling, two products (here documents) must be available (possible produced by previous tasks), namely a document that describes the content of a case and the user manual of the CBR tool that is used (and that specifies the representation capabilities of the tool). As output of the task, we require a descriptive model in CASUEL language. In order to execute the task, two resources are required: a CBR engineer and the descriptive model editor which is a software tool the allows to edit CASUEL in a comfortable way. Since the task of case modelling is a more complex task, it should be decomposed (as part of the method description). One possible decomposition is shown in Figure 2 in where four sub-tasks are introduced. These sub-tasks are related by several intermediate products.

Doc: content of a case Case Modelling Doc: User Manual of CBR Tool

Descriptive model (in CASUEL)

Descriptive Descriptive Model ModelEditor Editor CBR CBREngineer Engineer

Figure 1: Example: Graphical description of the „case modelling“ task

Doc: content of a case

Analysis Analysis Type M. Doc: AttributeType-SourceTable

Evaluation Document

Validate Validate

Descriptive Model

Class ClassM. M.

Figure 2: Example: Graphical description of the one possible task decomposition 3.3 Applying the methodology The set of tasks together with their descriptions, the product descriptions, and the resource descriptions can be seen as the generic part of the methodology. They provide a set of components that can be configured or even specialised in order to achieve a particular goal. Applying this methodology for a concrete CBR project means to: • extend or refine the predefined set of CBR specific tasks (modelling) • construct a project plan which an instantiation of the available tasks (planning) • execute and monitor the project plan (execution).

4.

Some ingredients for a CBR methodology

Software process modelling provides a philosophy (or a framework) for building a methodology but does not contribute to its content. It doesn’t say anything about CBR or how to develop an appropriate process model or a class of process models. Therefore, we have to analyse other sources of information that provide substantial CBR specific experience or frameworks that could become ingredients of a CBR methodology based on process modelling. 4.1 CBR specific product descriptions For developing a CBR specific product model, the following frameworks on CBR architectures from the literature should be considered. The CBR cycle, the task-method-decomposition by Aamodt & Plaza (1994) as well as the extensions of the task-method-decomposition model in the context of INRECA (Althoff, Wess et al. 1995; Althoff & Aamodt 1996; Althoff 1996) provide a means for structuring the main outcome product of the CBR methodology, namely the CBR system itself. The same purpose fulfils the knowledge-container model by Richter (1995). While the former provides a process-oriented view on CBR systems, the later focuses on the different kinds of knowledge a CBR system can use. On a more detailed level of description, frameworks that focus on a single process or aspect of a CBR system are relevant, like frameworks for adaptation (e.g. Voss, 1996), abstraction (Bergmann & Wilke 96) and similarity assessment (e.g. Richter, 1992; Osborne & Bridge 1996).

4.2 CBR specific process descriptions A set of task descriptions should be constructed and organised hierarchically. At a high level of abstraction, a few tasks describe the overall development of a CBR application. At more detailed level, each of these high-level task is refined into a more specific (or micro) process models. For one high level task (e.g., case modelling) we may have different micro-models for different kind of applications (e.g. one data-driven approach to be used in situations in a which large amount of data is available in a data base, or a model-driven approach to be used in situations where case-data is not electronically available, but general knowledge can be identified). This hierarchical nature of a methodology is also similar to the generic methodology approach in CommonKADS5. According to CommonKADS (Van de Velde, 1994), a methodology can be generic. A generic methodology is a framework for configuring a specific set of activities to achieve a particular goal. It consists of the following different layers: •

Strategic management layer: Approach(es) to be taken, allocated resources.

•

Development approach layer: Defines the type of objects that constitute intermediate and final results of a project.

•

Activity layer: Activities to be done as part of the methodology.

• Technique layer: Techniques that support the activities. Please remember that software process modelling provides a means for hierarchical modelling through the specification of one (or several) task decomposition(s) for each high-level task (see section 2.2). 4.2.1 Contributions to a process model at a high level of abstraction The following approaches to software- and knowledge engineering should be taken into consideration when defining a high-level process model. • Life-cycle models describe a software development project (technical and managerial processes) at a very high level of abstraction. A very popular life-cycle model is the spiral model (Boehm 1988; 1991) which is often used in the context of knowledge engineering (Van de Velde, 1994). Recent experience on CBR development had shown that it is a good strategy to develop a system using a sequence of prototypes (Bartsch-Spörl, 1996a). Each prototype development can be considered as one cycle in the spiral model. • Requirements engineering has become a core activity in SE. The task of requirements engineering has moved from supporting the early phases of individual software projects, to accompanying the whole life cycle of complex, long-lived human-machine systems in a rapidly changing organisational environment (Shaw & Gaines, 1996). As part of the NATURE Esprit project (Jarke & Pohl, 1994) a requirements process theory has been developed which offers a unified process meta-model in which a small set of building blocks cover a larger spectrum of process guidance strategies. This work will also be particularly valuable for covering the maintenance aspect of a CBR methodology. • Current approaches to CBR methodologies (Kolodner, 1993 chapter 15; Althoff, Wess et al. 1995; Wess, 1995, Lewis, 1995; Bartsch-Spörl, 1996a; 1996b; Bartsch-Spörl & Manago 1996; Curet & Jackson, 1996; Johnston, Breen, & Manago, 1996) already include a set of high-level steps that must be performed in order to develop a CBR approach. This work provides valuable CBR specific contributions; however some of them are limited to a narrow class of CBR applications. 4.2.2 Contributions to a CBR specific process model at a detailed level (micro models) In order to come to a methodology that is operational, and that provides detailed guidance for system development, the high-level tasks of the process model need to be refined into more detailed (or 5

Please look also at http://swi.psy.uva.nl/projects/CommonKADS/description/subsubsection3.1.2.1.html

micro-) process models. At the lowest level of abstraction, tasks with a clear definition are needed; if possible, supported by appropriate software tools. From the literature on CBR as well as on SE and KE we have identified the following areas that can definitely contribute to the development of micro models: • Object-oriented analysis and design techniques (e.g., Booch, 1994) should be considered for case modelling, since several state-of-the-art CBR tools allow object-oriented representation of cases and background knowledge. • Schema evolution techniques (Roddick, 1995) for databases (particularly object-oriented databases) can contribute to the task of maintaining a case representation and a case-base and help to deal with a changing environment. • Knowledge elicitation techniques from KE (cf. Shaw & Gaines, 1996; Strube et al. 1994) for acquiring domain knowledge for knowledge-based systems can also be useful for acquiring general knowledge (e.g. in form of rules) used in a CBR system for enhancing case descriptions and for specifying the adaptation of solutions (Bergmann et al., 1996b). • Approaches to the evaluation of CBR tools (e.g., Althoff, Auriol, et al. 1995) provides guidance for the task of selecting an appropriate CBR tool during the early phases of application development. Moreover, the evaluation strategies employed therein as well as other (e.g. statistical) techniques for evaluating knowledge-based systems (e.g., Cohen, 1996) contribute to the evaluation of the CBR application being developed (later phases of the development process). • Machine learning approaches can be employed in a useful manner to automatically optimise a CBR system (e.g., learning feature weights for similarity assessment) according to different criteria (Aha et al. 1991; Wettschereck & Aha, 1995; Wilke & Bergmann, 1996).

4.

Future work

In order to build a comprehensive CBR methodology it is necessary to • further analyse the identified approaches in more detail and select those portions that can be used in the context of CBR, • describe the selected portions in a concise way by using the means of software process modelling, • apply and evaluate the resulting methodology in the context of a concrete CBR application and identify areas in which further elaboration is required. Please note that such a methodology must always remain open for future extensions that are likely to become necessary when the CBR technology evolves and more ambitions kinds of applications are addressed. Acknowledgement Funding for this work has been provided by the Commission of the European Union (INRECA-II: Information and Knowledge Reengineering for Reasoning from Cases; Esprit contract no. 22196) to which the authors are greatly indebted. The partners of INRECA-II are Acknosoft (prime contractor, France), Daimler Benz AG (Germany), tecInno (Germany), Interactive Multimedia Systems (Ireland), University of Kaiserslautern (Germany).

References Aamodt, A. & Plaza, E. (1994). Case-Based Reasoning: Foundational Issues, Methodological Variations and System Approaches. AI Communications 7, No. 1, 39-59. Aha, D., Kibler, D., & Albert, M. (1991). Instance-based learning algorithms. Machine Learning, 6, 37-66. Althoff, K.-D. (1996) Evaluating case-based reasoning systems: The INRECA case study. Habilitationsschrift, University of Kaiserslautern (submitted).

Althoff, K.-D. & Aamodt, A. (1996). Relating Problem Solving and Learning Methods to Task and Domain Characteristics: Towards an Analytic Framework. AI Communications 9, No. 3 Althoff, K.-D., Wess, S., Weis, K.-H., Auriol, E., Bergmann, R., Holz, H., Johnston, R., Manago, M., Meissonnier, A., Priebisch, C., Traphöner R., & Wilke W.(1995). An evaluation of the final integrated system. Deliverable D6 of the INRECA Esprit Project. Althoff, K.-D. & Wilke, W. (1996). Potential uses of case-based reasoning in the experience-based construction of software systems. In: R. Bergmann & W. Wilke (eds.), Proceedings of the 5th German Workshop in Case-Based Reasoning (GWCBR’97), LSA-97-01E, Centre for Learning Systems and Applications (LSA), University of Kaiserslautern. Althoff, K.-D., Auriol, E., Barletta, R. & Manago, M. (1995). A Review of Industrial Case- Based Reasoning Tools. AI Perspectives Report, Oxford, UK: AI Intelligence (153 pages). Bartsch-Spörl, B. (1996a). Towards a methodology for how to make CBR systems work in practice. In: H.-D. Burkhard & M. Lenz (eds.), Proceedings of the 4th German Workshop on Case-Based Reasoning (CBR-96)- System Development and Evaluation - Informatik-Bericht No. 55, Humboldt Universität Berlin, 2-9. Bartsch-Spörl, B. (1996b). How to introduce case-based reasoning in customer support. Applicus Deliverable. Bartsch-Spörl, B. & Manago, M. (1996). Case-based reasoning: A leading edge technology for making active use of your experience. Leaflet. Basili, V. R., Caldiera, G. & Rombach, H. D. (1994). The Experience Factory. In: J. J. Marciniak (ed.), Encyclopedia of Software Engineering, Vol. 1, 469-476, New York: Wiley Bergmann, R., Wilke, W., Vollrath, I., & Wess, S. (1996). Integrating general knowledge with objectoriented representation and reasoning. In: H.-D. Burkhard & M. Lenz (eds.), Proceedings. of the 4th German Workshop on Case-Based Reasoning (CBR-96)- System Development and Evaluation - Informatik-Bericht No. 55, Humboldt Universität Berlin, 2-9. Bergmann, R. & Wilke, W. (1996b). On the role of abstraction in case-based reasoning. In Smith, I. & Faltings, B. (eds.) Advances in Case-based Reasoning. EWCBR96. pp. 28-43, Springer. Boehm, B. W. (1988). A spiral model of software development and enhancement. IEEE Comput. 21 (5), 61-72. Boehm, B. W. (1991). Software risk management: Principles and Practices. IEEE Software, 32-41. Booch, G. (1994). Object-oriented analysis and Design. With Applications. Second Edition. Benjamin / Cummings Publishing Company. Breen, S. & Johnston, R. The scope of the methodology. Draft 2 of the deliverable D1 of the INRECA-II Esprit Project P22196. Bröckers, A., Lott, C. M., Rombach, H. D., Verlage, M. (1995). MVP-L Language Report Version 2. Internal Report, University of Kaiserslautern. Cohen (1996) Empirical Methods for Artificial Intelligence. Kluwer. Curet, O. and Jackson, M. (1996). Towards a methodology for case-based systems. Expert Systems’96. Proceedings of the 16th annual workshop of the British Computer Society. Gibbs, W. W. 1994: Software´s chronic crisis. Sci. Am. , September, pp. 86-95. Jarke, M. & Pohl, K. (1994). Requirements engineering in the year 2001: On (virtually) managing a changing reality. Software Engineering Journal. Johnston, R., Breen, S., & Manago, M. (1996). Methodology for developing CBR applications. INRECA Deliverable D30. Kolodner, J. L. (1993). Case-Based Reasoning. Morgan Kaufmann

Lewis, L. (1995). Managing computer networks: A case-based reasoning approach. Artech House Publishers. London. Manago, M, Bergmann, R. et al CASUEL: A Common Case Representation language; Esprit project 6332, Deliverable D1. Version 2. Maurer, (1996). Modelling the knowledge engineering process. Second Knowledge Engineering Forum. Bericht 1/96 of the SFB 501. University of Kaiserslautern. Osborn, H. R. & Bridge, D. G. (1996). A case base similarity framework. In Smith, I. & Faltings, B. (eds.) Advances in Case-based Reasoning. EWCBR96. pp. 309-323, Springer. Richter, M.M. (1992). Classification and learning of similarity measures. In Proceedings of the 16th annual conference of the society for classification, Springer. Richter, M.M. (1995). The knowledge contained in similarity measures. Invited talk at ICCBR’95. (Sildes see http://wwwagr.informatik.uni-kl.de/~lsa/CBR/Richtericcbr95remarks.html) Roddick, J. (1995). Survey of schema versioning issues for database systems. Info, SW Technology 37 (3). Rombach, H. D. & Verlage, M. (1995). Directions in Software Process Research. In: M. V. Zelkowitz (ed.), Advances in Computers, Vol. 41, Academic Press, 1-61 Shaw, M. (1990). Prospects for an engineering discipline of software. IEEE Software 7,15-24. Shaw, M. & Gaines, B. (1996). Requirements acquisition. http://ksi.cpsc.ucalgary.ca/articles/SE/SeqAcq/ Strube, G., Enzinger, A., Janetzko, D., & Knauff, M. (1995). Knowledge engineering for CBR systems from a cognitive-science perspective. In: Veloso M & Aamodt A (eds). Case-based Reasoning Research and Development; Proceedings of the First International Conference on CBR. Springer. Van de Velde (1994) An Overview of CommonKADS. In Breuker & Van de Velde (Eds.) CommonKADS Library for Expertise Modelling. IOS Press. Voss, A. (1996). Towards a methodology for case adaptation. In Wahlster, W. (ed.) Proceedings of ECAI’96, John Wiley and Sons, Chichester. Wess,

S. (1995). Fallbasiertes Problemlösen in wissensbasierten Systemen zur Entscheidungsunterstützung und Diagnostik. Dissertation Universität Kaiserslautern. Infix Verlag, DISKI 126.

Wettschereck D & Aha D. (1995). Weighting Features. In: Veloso M & Aamodt A (eds). Case-based Reasoning Research and Development; Proceedings of the First International Conference on CBR. pp347-358. Springer. Wilke W & Bergmann R. (1996). Considering Decision Cost During the Learning of Feature Weights. In Smith, I. & Faltings, B. (eds.) Advances in Case-based Reasoning. Springer.EWCBR’96 Workflow Management Coalition. (1996). The workflow management coalition specification. Doc. WFMC-TC-1011, June 1996. http://www.aiai.ed.ac.uk/WfMC/DOCS/glossary/glossary.html