Towards a Unified Methodology for Software Engineering and Knowledge Engineering

F. Alonso, A. de Antonio, A. L. Gonzlez, J. L. Fuertes, L. Martnez Facultad de Informtica Universidad Politcnica de Madrid Campus de Montegancedo 28660-Boadilla del Monte, Madrid, Spain
ABSTRACT This paper presents a first step towards building a unified methodology for both Knowledge Engineering and Software Engineering. The idea is to combine the acquisition and conceptualisation phases of the IDEAL methodology (a Knowledge Engineering methodology) with an object-oriented design and implementation. This methodology has been successfully applied to three projects at CETTICO (Centre of Computing and Communications Technology Transfer). The paper describes the techniques used and the results obtained in developing a unified methodology. 1. INTRODUCTION The main goal of both Knowledge Engineering (KE) and Software Engineering (SE) methodologies is to develop software systems that solve problems in almost any domain area. Initially, the SE methodologies (structured methodologies using the waterfall model [1], [2]) solved well-defined problems that had complete specifications. As these methodologies moved on to solve more complex problems, they came up against the issue of incomplete specifications. So other life cycles and methodologies were developed, like the spiral life cycle [3], prototyping [4] and finally object-oriented methodologies, which use an iterative and incremental life cycle. There is a large number of object-oriented methodologies, including Booch [5], OMT [6], OOSE [7], etc. The proliferation of methodologies led to a notation and process unification effort. The main results of this effort are the UML notation, developed by Booch, Rumbaugh and Jacobson [8], and the OPEN methodology, developed by Henderson-Sellers, Graham and others [9]. On the other hand, KE, that is, the discipline of building knowledge-based systems (KBS), deals with poorly defined problems: they are poorly structured, have subjective requirements, are context dependent and usually have conditions of uncertainty [10]. And these incomplete specifications change over time. Methodologies like KADS [11], CommonKADS [12] and IDEAL [13] mean that knowledge-based systems can be built using life cycles that can cope with growing knowledge of the problem and its solution. One prominent life cycle is IDEALs conical-spiral life cycle [10] [14]. These two disciplines are moving closer together as the problems to be solved become more and more complex: usually problems have both a SE component and a KE component. It is also known that none of the existing methodologies is appropriate for every development; in other words, there is no silver bullet. So there is a need for a unified methodology allowing the development of systems using both SE and KE techniques depending on the characteristics of the problem to be solved. This need for unification has already been pointed out by several authors [10], [13], [14], [15], [16], [17]. This paper presents a first step in this direction: a mixed methodology, combining the acquisition and conceptualisation steps of IDEAL with an OO design and implementation that has been used to develop several projects in different areas. The contents of this paper are as follows. First, a brief description of IDEAL and object-orientation will be given, focusing on the main aspects used in our approach. Then, the mixed methodology proposed in this paper will be presented. The fourth point will be a description of the application of the methodology to three different projects. And finally, we will draw some conclusions. 2. KNOWLEDGE ENGINEERING: IDEAL IDEAL is a KE methodology that has been used with success in many projects [12]. This methodology incorporates a threedimensional spiral-conical life cycle which can handle the evolution of knowledge during the development of several versions of a KBS. The IDEAL methodology comprises five phases: application identification, demonstration prototype development, research, field and operational prototypes development, commercial system and technology transfer. The development of each prototype can be divided into several steps: solution conception (defining the problem to be solved), knowledge acquisition (eliciting knowledge from experts or documentation), conceptualisation (obtaining a conceptual model of the system), formalisation (representing the knowledge using a knowledge representation formalism) and implementation (building the prototype).

As the Acquisition and Conceptualisation steps will be used in our proposal, a brief description of these two steps is given below. The Knowledge Acquisition step is present throughout the development of each prototype. The goal of this step is to elicit knowledge from experts or from any suitable documentation. IDEAL specifies which techniques can be used and in what order. These techniques include: non-structured and structured interviews [18], structural analysis [19], repertory grid [20], protocol analysis [21] and Delphi [22]. Knowledge Conceptualisation is responsible for the construction of a conceptual model of the problem to be solved by a KBS. It is divided into two sub-steps: Analysis: during this sub-step the problem is decomposed into three levels of information: strategic, conceptual and tactical. Synthesis: this sub-step is responsible of generating a global static and dynamic model of the system under study. The final result of synthesis is the Knowledge Map. 3. SOFTWARE ENGINEERING: OBJECT ORIENTATION Object-oriented methodologies are based on the concept of an object [5], which has several properties, called attributes, and defines some permitted operations on the object, called methods. Object-orientation improves the development of software because the main characteristics of objects encapsulation, information hiding, inheritance enforce good design rules, allowing the development of well-structured systems and improving maintenance and reuse. Although OO methodologies differ considerably (see for example [5], [6], [7], [8] and [9]), the main concepts of analysis, design and implementation can also be applied to object-orientation. As our proposal will use an OO design and implementation, a brief description of the main concepts of these phases is given below. The main focus in OO Design is to completely define the classes making up the system. A class can be defined as a set of objects sharing the same behaviour. Using this definition, an object is considered as an instance of one class. The main results of OO design are [24]: A complete class diagram, showing relationships between the classes of the system; The definition of each class, specifying the attributes and methods of each class; A state-chart diagram for each class which is reactive, that is, it changes its behaviour depending on its state; Some activity diagrams showing the interaction and message-passing between the classes of the system.

Once the design has been defined, it is usually implemented using OO programming languages, like Java, C++, Eiffel and Smalltalk. Using these languages, the implementation phase consists of adapting the original design to the limitations of the chosen language and the environment in which the system will be executed. 4. INTEGRATION OF IDEAL AND OBJECT ORIENTATION 4.1 Justification Based on our experience in the development of software systems (both traditional and knowledge-based), the main issues that led us to define a mixed methodology were as follows: The IDEAL methodology includes guidelines for the development process, especially selection of knowledge acquisition techniques. In IDEAL, the division of conceptualisation into three levels (strategic, conceptual and tactical) helps to classify the information obtained during acquisition. The IDEAL methodology is not well suited for developing traditional systems because it is declarative. Object-oriented techniques are very useful in design and implementation, because they enforce good design rules in order to build well-structured and easily maintainable systems. On the other hand, OO (as it is normally used) it is not adequate for analysis, because it uses the same notation during the whole process, making it difficult to first concentrate on domain analysis. Comparing SE and KE, it can be stated that analysis in SE is equivalent to conceptualisation in KE, and design in SE to formalisation in KE. This idea has been stated by Blum [25], who divided the software development process into three transformations: from the application domain to a conceptual model; from the conceptual model to a formal model and from the formal model to the implementation domain (figure 1).

Application Domain

Conceptual Models
T 2 T 3 Implementation

Formal Models

Domain

Figure 1. The Essential Software Process

Our idea was to combine the strengths of the two approaches in order to define a methodology with a strong emphasis on analysis (based on the conceptualisation of IDEAL) and with a smooth transition to an OO design.

4.2 Proposed Methodology The proposed methodology follows the IDEAL life cycle, and has the same five phases. In our proposal, we have modified the steps of the development of each prototype in order to be able to build object-oriented systems. We propose six steps: solution conception, acquisition, analysis, object-oriented design, object-oriented implementation and evaluation. These steps are not sequential, they overlap, as shown in figure 2.
Sol. Conception Acquisition Analysis OO Design OO Implementation Evaluation Time

based on the conceptualisation phase of IDEAL. The conceptual model is divided into three levels: Strategic: this level represents the strategy used to solve the problem. This strategy is represented by a task decomposition tree, that is, the main task is divided into several subtasks and so on (figure 3).
Main Task

Subtask 1

Subtask 2

...

Subtask n

ST 1.1

ST 1.2

...

ST 1.m

Figure 3: Task decomposition tree for strategic level

Figure 2: Steps overlapping

The solution conception and acquisition steps are based on the corresponding steps in IDEAL. The analysis step is mainly based on the conceptualisation step of IDEAL, with some modifications. We still use the three levels of information (strategic, conceptual and tactical), as they facilitate the organisation of the acquired knowledge, but we have suppressed the synthesis sub-step, as it is very specific to KBS. This sub-step has been replaced by the OO design step. This is possible because an object model represents both static and dynamic information and can be used as a synthesis of the three information levels of the analysis. Once the OO design is complete, OO implementation will allow an almost direct translation of the design into an actual system. This combination of steps has several advantages. First, the analysis step produces a complete conceptual model of the problem to be solved, and this model is easily generated using the guidelines offered by IDEAL. Second, this conceptual model is built in such a way that the transition to an OO design is very smooth. And third, OO design rules allow construction of well-structured system. A brief description of the proposed steps is given in the following paragraphs. Solution Conception. This step is the same as in IDEAL. The goal of this step is to define the problem that has to be solved by the prototype in question. Acquisition. This step is responsible for obtaining all the knowledge needed to develop the prototype in question, using knowledge acquisition and requirements engineering techniques. This step is present during the whole development process. Initially, the main focus is on high-level information. At the end of the development process, the main focus is on low-level information. Analysis. The goal of this step is to build a conceptual model of the problem to be solved by the prototype. This phase is

Apart from the above diagram, each task has its own specification in table format. The attributes used to specify each task are: goal, input, output, process and subtasks (table 1).
Task: <Task Name> Goal Main goal of the task Input Input information for the task Output Results of the task Process Description of the high-level process Subtasks List of subtasks
Table 1: Specification of tasks in strategic level

Conceptual: during the development of the strategic level, a glossary of terms is created, containing the definition of the main terms used in the problem domain. This dictionary is used to identify concepts, relationships between concepts, and the attributes of each concept. This level is represented using an extended entity-relationship diagram, and each concept is specified using Concept, Attribute, Value (CAV) tables, as shown in table 2.
Concept Description Name of the Description of the concept meaning and use of the concept ... ... Attributes List of names of attributes ... Values Admissible values for each attribute ...

Table 2: Specification of concepts using CAV tables

Tactical: once the above levels have been defined, the tactical level represents a refinement of the strategy using the terminology identified at the conceptual level. The tactical level is used in our approach as a transition between analysis and design. We have defined and OO pseudocode for the specification of this level and each task of the strategy has to be assigned to one of the concepts of the conceptual level. Later we will show some examples of this pseudocode.

Design. The goal of this step is to define how to solve the problem using a computer system. It is based on OO design and the main results are a class diagram and the complete specification of each class. As stated above, the transition from the analysis model to the OO model is very smooth, thanks mainly to the tactical level notation. The OO design is obtained from the analysis using the following steps: The conceptual level is used to identify classes, their relationships and their attributes. The strategic and tactical levels are used to specify the methods of the classes and to refine the definition of attributes and relationships. Constructors and destructors of each class are defined in order to define the creation and destruction of instances of the classes. Figure 4 summarises these links between the analysis and design phases, that is, between the IDEAL and OO components of our proposal.

5. APPLICATION OF OUR APPROACH The approach presented in this paper has been successfully applied with success to several CETTICO (Centre of Computing and Communications Technology Transfer, Spain) projects. These projects have been developed with the collaboration of students from the UPM School of Computer Science. As an example, we will describe three of these projects. The description will focus mainly on the results obtained during the analysis step. RUISEOR [26]: a musical system for the blind. It allows a blind person to record musical notes, modify the resulting score and play the musical notes. This was the first CETTICO project to apply our approach. Figure 5 shows the first level of the strategic task decomposition tree of this system. The main subtasks of this system are: recording, playing, editing and managing songs, and a subtask for system configuration, especially specific devices for blind user interfacing.

Manage Songs
Analysis Strategic Tactical Conceptual Analysis to Design Transition
Figure 4: Links between analysis and design

OO Design

Record Song
OO Model - Static - Dynamic

Compose Song

Play Song Edit Song Configure System

Figure 5: First level of a task decomposition tree

Any existing notation can be used for the class diagram can be any of the existing ones, although we recommend use of the most complete notations, UML [24] and COMN (the notation defined in OPEN [9]). Each class is specified using tables describing the attributes and methods of each class. The specification of each attribute includes its data type and visibility. For the methods, their signature (arguments), visibility and behaviour are to be specified. Implementation. The software system is built during this step, using an object-oriented programming language. This implementation is usually an almost direct transformation of the design classes into code. The choice of the best programming language depends largely on integration criteria with other existing systems. Evaluation. The objective of this step is to make sure that the system under development is correct. Like acquisition, this step is also present during the whole process, validating and verifying the deliverables of each step.

As an example of task specification, table 3 shows the task Create New Song, which is a subtask of Manage Songs. This task creates a new song from scratch, initialising the system so that its state is consistent for the user. MEHIDA-PC: an intelligent tutorial system for deaf children. It is used to teach basic communication skills to deaf children by different means: written language, sign language, mimicry and lip reading. A prototype of this system was originally developed for Macintosh [27]. The development of the complete system on PC is currently using our methodology.
Task: Create New Song Goal Create a new song and initialise the system Input Global parameters for the new song Output Empty song, current position initialised Process Initialise MIDI and speech Create an empty song Set the current position at time 0 Create an empty list of notes

Table 3: Sample of Task Specification

The development of the user interface component introduced a variant into the tactical level of the analysis. This variant was needed in order to cope with an event-driven problem [28]. Table 4 shows an example of part of a tactical definition. This task reacts to some events, for example, if the incoming event is paint (this event is system-generated), the background is painted; and if the user generates the teach event, then the system reacts starting the process of teaching the student (which is a responsibility of the teacher concept).
Task: Mehida.Ges_Mehida Inputs EVENT Event IDG_Mehida Aux. Vars. String _Student_Name EVENT _Event Process SelectAction (Event.Type) { ES_PAINT: PAINT_B ACKGROUND() CE: SelectControl (Event.Control) { ID_TEACH: Teacher.Teach( _Student_Name ) ... }
Table 4: Sample of Tactical Task

Concept DOCUMENT

Description Winlee Doc.

...

...

Attributes State CurrentPos BlockStart BlockEnd FileName Num. Pag. Contents ...

Values TState TPosition TPosition TPosition String Number CONTENTS ...

Table 5: Sample of CAV Table (fragment)

IDEAL is a KE methodology with a very powerful life-cycle, well-defined conceptualisation and a strong emphasis on guidelines for the process. Object-orientation is a branch of SE with allows incorporation of sound design rules in order to build wellstructured systems that are easy to maintain. We have shown that our approach has been successfully applied in the development of three different projects. The main advantages of the proposed methodology are as follows: Using the analysis of IDEAL, we can follow the guidelines and techniques of this methodology for knowledge acquisition and conceptualisation. The three-level analysis has proven to be very useful, as it allows quick organisation of the information gathered about the problem to be solved. The tactical level, as defined in our approach, is a very powerful tool for the transition from the analysis to the design phase. At the moment, this level represents too much information, but we are working on its simplification while maintaining its value as a transition tool between analysis and design. The object-oriented design and implementation facilitate the development of well-structured, robust and easily maintainable systems. ACKNOWLEDGEMENTS This paper has been written and prepared with the collaboration of CETTICO (Centre of Computing and Communications Technology Transfer). REFERENCES [1] Edward Yourdon. Anlisis estructurado moderno. Prentice-Hall Hispanoaericana. Mexico. 1993. [2] W.W. Royce. Managing the Development of Large Software Systems: Concepts and Techniques. Proceedings WESCON, August, 1970. [3] Barry W. Boehm. A Spiral Model of Software Development and Enhancement. Computer. N 21, vol. 5. May 1988.

WINLEE: an OCR system adapted for the blind. The main purpose of this system is to allow a blind user to read paper documents, with the help of a scanner and an OCR system, using speech or Braille. Table 5 shows a fragment of the CAV table of this system, describing the document concept, which represents one document used by the system. One document has several attributes: its state (whether it has been modified or not), the current position of the cursor, the starting and end points of a selected block, the file name, the number of pages and, of course, its contents, which is an instance of the contents concept. The application of our approach to these projects was very successful, especially in the analysis phase. First the strategic level was straightforward for our students, and allowed us to quickly attain a good description of the problems to be solved by each project. Another strong point of our methodology is the very smooth transition from analysis to an OO design, by means of the tactical level. But this methodology is not perfect. We came up against several problems during its use. The main one was the excessive detail of the tactical level, which made the description of this level a very time-consuming task. 6. CONCLUSIONS AND FUTURE WORK In this paper we have presented a first step into the unification of SE and KE methodologies. Our approach is a mixed methodology combining the analysis phase of IDEAL with an object-oriented design and implementation.

[4] L. B. S. Raccoon. Fifty years of progress in software engineering. Software engineering notes. Vol. 22. No. 1. pp. 88-104. January 1997. [5] Grady S. Booch Object Oriented Analysis and Design with Applications (2nd Ed). Benjamin-Cummings Redwood City [California]. 1994. [6] James Rumbaugh. Object-oriented modeling and design. Prentice-Hall Englewood Cliffs, New Jersey. 1991. [7] Ivar Jacobson. Object-oriented software engineering: a use case driven approach. Addison-Wesley Harlow. 1996. [8] Rational Software Corporation. UML Summary.. Version 1.1. September, 1 of 1997. http://www.rational.com. [9] Brian Henderson-Sellers, Donald G. Firesmith, Ian M. Graham. Methods unification: the OPEN methodology. Journal of Object Oriented Programming (ROAD). May 1997. pp 41-43 + 55. [10] Fernando Alonso Amo, Jos L. Fuertes, Loc A. Martnez Normand, Csar Montes. A knowledge engineering software development methodology applied to a spiral/conical life cycle. Proceedings of the 9th International Conference on Software Engineering and Knowledge Engineering. SEKE97. pp. 32-37. 1997. [11] B. J. Wielinga, A. Th. Schreiber, J. A. Breuker. KADS: A Modelling Approach to Knowledge Engineering. Knowledge Acquisition. No. 4. 1992. [12] Guus Schreiber, Bob Wielinga, Robert de Hoog, Hans Akkermans, Walter Van de Velde. CommonKADS: A Comprehensive Methodology for KBS Development. IEEE Expert. December 1994. pp. 28 - 37. [13] Asuncin Gmez, Natalia Juristo, Csar Montes, Juan Pazos. Ingeniera del Conocimiento. Editorial Centro de Estudios Ramn Areces. Madrid. 1997. [14] Fernando Alonso Amo, Natalia Juristo, Juan Pazos. Trends in life-cycle models for SE and KE: proposal for a spiral-conical life-cycle approach. International Journal of Software Engineering and Knowledge Engineering. Vol. 5. No. 3. 1995. pp. 445-465. [15] W. David Hurley (ed.). Software engineering and knowledge engineering: trends for the next decade. World Scientific. Singapore. 1995. [16] S. Lee, R. M. OKeefe. An experimental investigation into the process of knowledge-based systems development. European Journal on Information Systems. Vol 5. No. 4. pp. 233-249. December 1996. [17] Sally Shlaer, Stephen J. Mellor. Recursive design of an Application Independent Architecture. IEEE Software. January 1997. pp. 61-72. [18] D. A. Waterman. A Guide to Expert Systems. AddisonWesley, Massachusetts, USA. 1986. [19] N. Juristo. Mtodo de Construccin del Ncleo de una Base de Conocimientos a partir de un Modelo de Clasificacin Documental. PhD Thesis. Facultad de Informtica. Universidad Politcnica de Madrid, Spain. 1991. [20] G. A. Kelly. The Psychology of Personal Constructs. Norton. New York. 1955. [21] A. Newel, H. A. Simon. Human Problem Solving. Prentice Hall. Englewood Cliffs, New Jersey. USA. 1972.

[22] H. Linstone, M. Turoff. The Delphi method: Techniques and Applications. Addison-Wesley. Reading. Massachussets. 1975. [23] Roger S. Pressman. Ingeniera del Software. Un enfoque prctico. 4th Ed. Mc Graw Hill, Madrid. 1997. [24] Rational Software Corporation. UML Notation. Version 1.1. September 1, 1997. http://www.rational.com. [25] B. I. Blum. The evaluation of SE. Proceedings of the 1st International Conference on Information and Knowledge Management. Baltimore, MD. November 8-11. 1992. [26] R. Gil, L. Martnez. Proyecto Ruiseor: sistema de composicin musical para invidentes. Technical Report. Facultad de Informtica. Universidad Politcnica de Madrid. 1998. [27] F. Alonso, A. de Antonio, J. L. Fuertes, C. Montes. Teaching Communication Skills to Hearing-Impaired Children. IEEE Multimedia. Vol. 2. No. 4. 1995. [28] A. L. Gonzlez, C. Montes. Anlisis, Diseo e Implementacin de un Modelo de Presentacin de Actividades Multimedia. Technical Report. Facultad de Informtica. Universidad Politcnica de Madrid. 1998.