alonso towards smc98

7/30/2019 Alonso Towards SMC98

1/6

Towards a Unified Methodology for Software Engineering and Knowledge Engineering

F. Alonso, A. de Antonio, A. L. Gonzlez, J. L. Fuertes, L. MartnezFacultad de Informtica

Universidad Politcnica de MadridCampus de Montegancedo

28660-Boadilla del Monte, Madrid, Spain

ABSTRACT

This paper presents a first step towards building a unifiedmethodology for both Knowledge Engineering and SoftwareEngineering. The idea is to combine the acquisition andconceptualisation phases of the IDEAL methodology (aKnowledge Engineering methodology) with an object-orienteddesign and implementation. This methodology has beensuccessfully applied to three projects at CETTICO (Centre ofComputing and Communications Technology Transfer). Thepaper describes the techniques used and the results obtained indeveloping a unified methodology.

1. INTRODUCTION

The main goal of both Knowledge Engineering (KE) andSoftware Engineering (SE) methodologies is to developsoftware systems that solve problems in almost any domainarea.

Initially, the SE methodologies (structured methodologiesusing the waterfall model [1], [2]) solved well-definedproblems that had complete specifications. As thesemethodologies moved on to solve more complex problems,they came up against the issue of incomplete specifications. Soother life cycles and methodologies were developed, like thespiral life cycle [3], prototyping [4] and finally object-orientedmethodologies, which use an iterative and incremental lifecycle.

There is a large number of object-oriented methodologies,including Booch [5], OMT [6], OOSE [7], etc. Theproliferation of methodologies led to a notation and processunification effort. The main results of this effort are the UMLnotation, 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 buildingknowledge-based systems (KBS), deals with poorly definedproblems: they are poorly structured, have subjectiverequirements, are context dependent and usually haveconditions of uncertainty [10]. And these incomplete

specifications change over time. Methodologies like KADS[11], CommonKADS [12] and IDEAL [13] mean thatknowledge-based systems can be built using life cycles that cancope 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 theproblems to be solved become more and more complex:usually problems have both a SE component and a KEcomponent. It is also known that none of the existingmethodologies is appropriate for every development; in otherwords, there is no silver bullet. So there is a need for aunified methodology allowing the development of systemsusing both SE and KE techniques depending on thecharacteristics of the problem to be solved. This need forunification has already been pointed out by several authors

[10], [13], [14], [15], [16], [17].This paper presents a first step in this direction: a mixedmethodology, combining the acquisition and conceptualisationsteps of IDEAL with an OO design and implementation thathas been used to develop several projects in different areas.

The contents of this paper are as follows. First, a briefdescription of IDEAL and object-orientation will be given,focusing on the main aspects used in our approach. Then, themixed methodology proposed in this paper will be presented.The fourth point will be a description of the application of themethodology to three different projects. And finally, we willdraw some conclusions.

2. KNOWLEDGE ENGINEERING: IDEAL

IDEAL is a KE methodology that has been used with successin many projects [12]. This methodology incorporates a three-dimensional spiral-conical life cycle which can handle theevolution of knowledge during the development of severalversions of a KBS.

The IDEAL methodology comprises five phases: applicationidentification, demonstration prototype development, research,field and operational prototypes development, commercialsystem and technology transfer.

The development of each prototype can be divided into severalsteps: solution conception (defining the problem to be solved),knowledge acquisition (eliciting knowledge from experts or

documentation), conceptualisation (obtaining a conceptualmodel of the system), formalisation (representing theknowledge using a knowledge representation formalism) andimplementation (building the prototype).


2/6

As the Acquisition and Conceptualisation steps will be used inour proposal, a brief description of these two steps is givenbelow.

The Knowledge Acquisition step is present throughout thedevelopment of each prototype. The goal of this step is to elicitknowledge from experts or from any suitable documentation.IDEAL specifies which techniques can be used and in whatorder. These techniques include: non-structured and structuredinterviews [18], structural analysis [19], repertory grid [20],

protocol analysis [21] and Delphi [22].Knowledge Conceptualisation is responsible for theconstruction of a conceptual model of the problem to be solvedby a KBS. It is divided into two sub-steps:

Analysis: during this sub-step the problem is decomposedinto three levels of information: strategic, conceptual andtactical.

Synthesis: this sub-step is responsible of generating a globalstatic and dynamic model of the system under study. Thefinal result of synthesis is the Knowledge Map.

3. SOFTWARE ENGINEERING: OBJECTORIENTATION

Object-oriented methodologies are based on the concept of anobject [5], which has several properties, called attributes, anddefines some permitted operations on the object, calledmethods. Object-orientation improves the development ofsoftware because the main characteristics of objects encapsulation, information hiding, inheritance enforce gooddesign rules, allowing the development of well-structuredsystems and improving maintenance and reuse.

Although OO methodologies differ considerably (see forexample [5], [6], [7], [8] and [9]), the main concepts ofanalysis, design and implementation can also be applied toobject-orientation.

As our proposal will use an OO design and implementation, abrief description of the main concepts of these phases is givenbelow.

The main focus in OO Design is to completely define theclasses making up the system. A class can be defined as a setof objects sharing the same behaviour. Using this definition, anobject is considered as an instance of one class. The mainresults of OO design are [24]:

A complete class diagram, showing relationships betweenthe classes of the system;

The definition of each class, specifying the attributes andmethods of each class;

A state-chartdiagram for each class which is reactive, thatis, it changes its behaviour depending on its state;

Some activity diagrams showing the interaction andmessage-passing between the classes of the system.

Once the design has been defined, it is usually implementedusing OO programming languages, like Java, C++, Eiffel andSmalltalk. Using these languages, the implementation phaseconsists of adapting the original design to the limitations of thechosen language and the environment in which the system willbe executed.

4. INTEGRATION OF IDEAL AND OBJECT

ORIENTATION

4.1 JustificationBased on our experience in the development of softwaresystems (both traditional and knowledge-based), the mainissues that led us to define a mixed methodology were asfollows:

The IDEAL methodology includes guidelines for thedevelopment process, especially selection of knowledgeacquisition techniques.

In IDEAL, the division of conceptualisation into three levels(strategic, conceptual and tactical) helps to classify theinformation 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 inorder to build well-structured and easily maintainablesystems.

On the other hand, OO (as it is normally used) it is notadequate for analysis, because it uses the same notationduring the whole process, making it difficult to firstconcentrate on domain analysis.

Comparing SE and KE, it can be stated that analysis in SE isequivalent to conceptualisation in KE, and design in SE toformalisation 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 conceptualmodel; from the conceptual model to a formal model andfrom the formal model to the implementation domain (figure1).

Application Conceptual Models

Domain

Formal Models

Implementation

Domain

T T32

T1

Figure 1. The Essential Software Process

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


3/6

4.2 Proposed MethodologyThe proposed methodology follows the IDEAL life cycle, andhas the same five phases. In our proposal, we have modifiedthe steps of the development of each prototype in order to beable to build object-oriented systems. We propose six steps:solution conception, acquisition, analysis, object-orienteddesign, object-oriented implementation and evaluation. Thesesteps are not sequential, they overlap, as shown in figure 2.

Sol. Conception

Acquisition

Analysis

OO Design

OO Implementation

Evaluation

Time

Figure 2: Steps overlapping

The solution conception and acquisition steps are based on thecorresponding steps in IDEAL. The analysis step is mainlybased on the conceptualisation step of IDEAL, with somemodifications. We still use the three levels of information(strategic, conceptual and tactical), as they facilitate the

organisation of the acquired knowledge, but we havesuppressed the synthesis sub-step, as it is very specific to KBS.

This sub-step has been replaced by the OO design step. This ispossible because an object model represents both static anddynamic information and can be used as a synthesis of thethree information levels of the analysis. Once the OO design iscomplete, OO implementation will allow an almost directtranslation of the design into an actual system.

This combination of steps has several advantages. First, theanalysis step produces a complete conceptual model of theproblem to be solved, and this model is easily generated usingthe guidelines offered by IDEAL. Second, this conceptualmodel is built in such a way that the transition to an OO design

is very smooth. And third, OO design rules allow constructionof well-structured system.

A brief description of the proposed steps is given in thefollowing paragraphs.

Solution Conception. This step is the same as in IDEAL. Thegoal of this step is to define the problem that has to be solvedby the prototype in question.

Acquisition. This step is responsible for obtaining all theknowledge needed to develop the prototype in question, usingknowledge acquisition and requirements engineeringtechniques. This step is present during the whole developmentprocess. 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 modelof the problem to be solved by the prototype. This phase is

based on the conceptualisation phase of IDEAL. Theconceptual model is divided into three levels:

Strategic: this level represents the strategy used to solvethe problem. This strategy is represented by a taskdecomposition tree, that is, the main task is divided intoseveral 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

Apart from the above diagram, each task has its ownspecification in table format. The attributes used to specifyeach task are: goal, input, output, process and subtasks(table 1).

Task:

Goal Main goal of the task Input Input information for the taskOutput Results of the taskProcess Description of the high-level processSubtasks 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 ofthe main terms used in the problem domain. Thisdictionary is used to identify concepts, relationshipsbetween concepts, and the attributes of each concept. Thislevel is represented using an extended entity-relationshipdiagram, and each concept is specified using Concept,

Attribute, Value (CAV) tables, as shown in table 2.

Concept Description Attributes Values

Name of theconcept

Description of themeaning and use ofthe concept

List of namesof attributes

Admissible valuesfor each attribute

... ... ... ...

Table 2: Specification of concepts using CAV tables

Tactical: once the above levels have been defined, thetactical level represents a refinement of the strategy usingthe terminology identified at the conceptual level. Thetactical level is used in our approach as a transitionbetween analysis and design. We have defined and OO

pseudocode for the specification of this level and each taskof the strategy has to be assigned to one of the concepts ofthe conceptual level. Later we will show some examples ofthis pseudocode.


4/6

Design. The goal of this step is to define how to solve theproblem using a computer system. It is based on OO designand the main results are a class diagram and the completespecification of each class.

As stated above, the transition from the analysis model to theOO model is very smooth, thanks mainly to the tactical levelnotation. The OO design is obtained from the analysis usingthe following steps:

The conceptual level is used to identify classes, theirrelationships and their attributes.

The strategic and tactical levels are used to specify themethods of the classes and to refine the definition ofattributes and relationships.

Constructors and destructors of each class are defined inorder to define the creation and destruction of instances ofthe classes.

Figure 4 summarises these links between the analysis anddesign phases, that is, between the IDEAL and OO componentsof our proposal.

Analysis OO Design

Strategic

Conceptual

TacticalOO Model

- Static

- Dynamic

Analysis to Design

Transition

Figure 4: Links between analysis and design

Any existing notation can be used for the class diagram can beany of the existing ones, although we recommend use of the

most complete notations, UML [24] and COMN (the notationdefined in OPEN [9]).

Each class is specified using tables describing the attributesand methods of each class. The specification of each attributeincludes its data type and visibility. For the methods, theirsignature (arguments), visibility and behaviour are to bespecified.

Implementation. The software system is built during this step,using an object-oriented programming language. Thisimplementation is usually an almost direct transformation ofthe design classes into code. The choice of the bestprogramming language depends largely on integration criteriawith other existing systems.

Evaluation. The objective of this step is to make sure that thesystem under development is correct. Like acquisition, this stepis also present during the whole process, validating andverifying the deliverables of each step.

5. APPLICATION OF OUR APPROACH

The approach presented in this paper has been successfullyapplied with success to several CETTICO (Centre ofComputing and Communications Technology Transfer, Spain)projects. These projects have been developed with thecollaboration of students from the UPM School of ComputerScience.

As an example, we will describe three of these projects. Thedescription will focus mainly on the results obtained during theanalysis step.

RUISEOR [26]: a musical system for the blind. It allows ablind person to record musical notes, modify the resultingscore and play the musical notes. This was the firstCETTICO project to apply our approach. Figure 5 shows thefirst level of the strategic task decomposition tree of thissystem. The main subtasks of this system are: recording,playing, editing and managing songs, and a subtask forsystem configuration, especially specific devices for blinduser interfacing.

ComposeSong

Manage Songs

Record Song

Play Song

Edit Song

Confi ure S stem

Figure 5: First level of a task decomposition tree

As an example of task specification, table 3 shows the taskCreate New Song, which is a subtask of Manage Songs.This task creates a new song from scratch, initialising thesystem 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 childrenby different means: written language, sign language, mimicryand lip reading. A prototype of this system was originallydeveloped for Macintosh [27]. The development of thecomplete system on PC is currently using our methodology.

Task: Create New Song

Goal Create a new song and initialise the systemInput Global parameters for the new songOutput Empty song, current position initialisedProcess Initialise MIDI and speech

Create an empty songSet the current position at time 0Create an empty list of notes

Table 3: Sample of Task Specification


5/6

The development of the user interface component introduceda variant into the tactical level of the analysis. This variantwas needed in order to cope with an event-driven problem[28]. Table 4 shows an example of part of a tacticaldefinition. This task reacts to some events, for example, if theincoming event is paint(this event is system-generated), thebackground is painted; and if the user generates the teachevent, then the system reacts starting the process of teachingthe student (which is a responsibility of the teacher concept).

Task: Mehida.Ges_Mehida

Inputs EVENT EventIDG_Mehida

Aux. Vars. String _Student_NameEVENT _Event

Process SelectAction (Event.Type){

ES_PAINT: PAINT_BACKGROUND() CE: SelectControl (Event.Control)

{ID_TEACH:

Teacher.Teach( _Student_Name )...}

Table 4: Sample of Tactical Task

WINLEE: an OCR system adapted for the blind. The mainpurpose of this system is to allow a blind user to read paperdocuments, with the help of a scanner and an OCR system,using speech or Braille. Table 5 shows a fragment of theCAV table of this system, describing the documentconcept,which represents one document used by the system. Onedocument has several attributes: its state (whether it has beenmodified or not), the current position of the cursor, thestarting and end points of a selected block, the file name, thenumber of pages and, of course, its contents, which is aninstance of the contents concept.

The application of our approach to these projects was verysuccessful, especially in the analysis phase. First the strategiclevel was straightforward for our students, and allowed us toquickly attain a good description of the problems to be solvedby each project. Another strong point of our methodology isthe very smooth transition from analysis to an OO design, bymeans of the tactical level.

But this methodology is not perfect. We came up againstseveral problems during its use. The main one was theexcessive detail of the tactical level, which made thedescription of this level a very time-consuming task.

6. CONCLUSIONS AND FUTURE WORK

In this paper we have presented a first step into the unificationof SE and KE methodologies. Our approach is a mixedmethodology combining the analysis phase of IDEAL with anobject-oriented design and implementation.

Concept Description Attributes Values

DOCUMENT Winlee Doc. StateCurrentPosBlockStartBlockEndFileNameNum. Pag.Contents

TStateTPositionTPositionTPositionStringNumberCONTENTS

... ... ... ...

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 onguidelines for the process.

Object-orientation is a branch of SE with allowsincorporation of sound design rules in order to build well-structured systems that are easy to maintain.

We have shown that our approach has been successfullyapplied in the development of three different projects.

The main advantages of the proposed methodology are asfollows:

Using the analysis of IDEAL, we can follow the guidelinesand techniques of this methodology for knowledgeacquisition and conceptualisation.

The three-level analysis has proven to be very useful, as itallows quick organisation of the information gathered aboutthe problem to be solved.

The tactical level, as defined in our approach, is a verypowerful tool for the transition from the analysis to thedesign phase. At the moment, this level represents too muchinformation, but we are working on its simplification whilemaintaining its value as a transition tool between analysisand design.

The object-oriented design and implementation facilitate the

development of well-structured, robust and easilymaintainable systems.

ACKNOWLEDGEMENTS

This paper has been written and prepared with thecollaboration of CETTICO (Centre of Computing andCommunications Technology Transfer).

REFERENCES

[1] Edward Yourdon. Anlisis estructurado moderno.Prentice-Hall Hispanoaericana. Mexico. 1993.[2] W.W. Royce. Managing the Development of LargeSoftware Systems: Concepts and Techniques. ProceedingsWESCON, August, 1970.[3] Barry W. Boehm. A Spiral Model of SoftwareDevelopment and Enhancement. Computer. N 21, vol. 5.May 1988.


6/6

[4] L. B. S. Raccoon. Fifty years of progress in softwareengineering. Software engineering notes. Vol. 22. No. 1. pp.88-104. January 1997.[5] Grady S. Booch Object Oriented Analysis and Designwith Applications (2nd Ed). Benjamin-Cummings RedwoodCity [California]. 1994.[6] James Rumbaugh. Object-oriented modeling and design.Prentice-Hall Englewood Cliffs, New Jersey. 1991.[7] Ivar Jacobson. Object-oriented software engineering: ause 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. MartnezNormand, Csar Montes. A knowledge engineering softwaredevelopment methodology applied to a spiral/conical lifecycle. Proceedings of the 9th International Conference onSoftware Engineering and Knowledge Engineering. SEKE97.pp. 32-37. 1997.[11] B. J. Wielinga, A. Th. Schreiber, J. A. Breuker. KADS: AModelling Approach to Knowledge Engineering. Knowledge

Acquisition. No. 4. 1992.[12] Guus Schreiber, Bob Wielinga, Robert de Hoog, HansAkkermans, Walter Van de Velde. CommonKADS: AComprehensive Methodology for KBS Development. IEEEExpert. December 1994. pp. 28 - 37.[13] Asuncin Gmez, Natalia Juristo, Csar Montes, JuanPazos. Ingeniera del Conocimiento. Editorial Centro deEstudios Ramn Areces. Madrid. 1997.[14] Fernando Alonso Amo, Natalia Juristo, Juan Pazos.Trends in life-cycle models for SE and KE: proposal for aspiral-conical life-cycle approach. International Journal ofSoftware 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. WorldScientific. Singapore. 1995.[16] S. Lee, R. M. OKeefe. An experimental investigationinto 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 anApplication Independent Architecture. IEEE Software.January 1997. pp. 61-72.[18] D. A. Waterman. A Guide to Expert Systems. Addison-Wesley, Massachusetts, USA. 1986.[19] N. Juristo. Mtodo de Construccin del Ncleo de unaBase de Conocimientos a partir de un Modelo deClasificacin Documental. PhD Thesis. Facultad deInformtica. 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: Techniquesand Applications. Addison-Wesley. Reading. Massachussets.1975.[23] Roger S. Pressman. Ingeniera del Software. Unenfoque prctico. 4th Ed. Mc Graw Hill, Madrid. 1997.[24] Rational Software Corporation. UML Notation. Version1.1. September 1, 1997. http://www.rational.com.[25] B. I. Blum. The evaluation of SE. Proceedings of the 1stInternational Conference on Information and KnowledgeManagement. Baltimore, MD. November 8-11. 1992.

[26] R. Gil, L. Martnez. Proyecto Ruiseor: sistema decomposicin 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 eImplementacin de un Modelo de Presentacin de Actividades

Multimedia. Technical Report. Facultad de Informtica.Universidad Politcnica de Madrid. 1998.

alonso towards smc98

Documents