KNOWLEDGE BASED MANAGEMENT OF SOFTWARE OBJECTS

KNOWLEDGE BASED MANAGEMENT OF SOFTW AREOBJECTSJEAN-MARIE CHAUVETAbstract.As object-oriented approaches to software engineering are gainingwider acceptance,the body of software components available as reusable ob-jects is expected to grow accordingly.The emerging object oriented databasetechnology promises to provide appropriate access paths to such,possibly largeand semantically rich,software bases[5].The software engineer is then respon-sible for solving problems in software design and software development projectmanagement.The latter problems are,in important respects,ill-defined andill-structured.The work presented in this paper stemmed from the need to build indus-trial strength software tools to design end user interfaces to expert systems.Extensibility and portability constraints lead to the use of an object orientedarchitecture and programming language.The accessibility of expert systemtechnology lead us to tackle the ill-structured problem of designing a userinterface by applying knowledge based problem solving to the design processitself.The resulting environment,called NOOS,for building interactive graph-ics interfaces makes extensive use of knowledge based reasoning to assist thesoftware engineer in the design,and to manage the object database at execu-tion time.Knowledge Based Management of Software Objects The NOOS environment is primarily intended to design end user interfaces to knowledge based applications.Broad coverage of application domains and user needs is required since expert system technology is applied in a growing variety of tasks ranging from diagnostics and configuration in process control to office systems and business applications.In order to achieve as much generality as possible a three layer architecture was engineered.Object oriented user interface management systems The top layer consists of a graphic tool for painting screens and positioning graphics widgets,such as buttons,scroll bars,bitmaps,gauges or other user in-terface components into application windows.The behavior of the latter graphics components is encoded in an object oriented procedural language(OOPL),support-ing inheritance and message passing,for controlling the interface and responding to user events.Widgets are represented internally as objects accessed by the OOPL. The application programmer uses the OOPL to specify the behavior of the user interface and its interactions with the separately built expert system application.The middle layer is a virtual graphic machine providing a defined set of drawing, windows and regions,as well as resource management routines to widget methods. All built-in widgets in NOOS rely on the virtual graphic machine to display and Received by the editors February14,1990.12JEAN-MARIE CHAUVETupdate their graphic appearance in response to user and application interactions. The widget programmer can extend the widget object database by using the virtual graphic machine library of calls to create additional widgets or subclass new widgets from existing ones.The lower layer is actually a set of driver libraries to implement the virtual graphics machine on top of standard operating systems and windowing environ-ments.The following systems are currently supported:VMS/UIS and DECWin-dows,UNIX/X Window,OS/2Presentation Manager,and Mac OS.The user interface is specified by painting the application windows and setting them up with the appropriate graphic widgets.Interactions between widgets,or between windows and the application are directly coded in the OOPL.Relevant entities of both the application and the user interface are stored in an object repos-itory around which the previously described layers are built.Knowledge based design and executionThe NOOS environment enables developers and end-users of knowledge-based systems to design customized,domain-specific interfaces to their systems.Knowl-edge is embedded into the NOOS environment at two different levels,serving two different purposes:design and execution of user interfaces.Design knowledge is encapsulated into the NOOS system for assisting in the design process.At any given point in the design phase three knowledge bases are active:(i)a user interface style rule base,(ii)a software objects manager rule base,and(iii)a system rule base.Design knowledge is represented as rules which conditions and actions process objects in the shared repository.The rules are encoded through a rule language(OORL),providing syntax constructs to express the latter conditions and actions.The user interface style rule base captures style guidelines for graphic interfaces to applications.A point in the user interface style problem space is defined by a structure of widget objects.This structure both describes relationships between widget objects(this button is in a frame used in this window),and defines the individual characteristics of the widgets(this list box has a vertical scroll bar only, and is editable).Functional specifications are expressed as constraints on the struc-ture,thus bounding the problem space to a subset of acceptable points.Rules in the knowledge base are used to elaborate a structure satisficing the functional con-straints.Elementary actions in the right hand sides of rule add,delete,or alter one or several widget objects in the current structure.The generic knowledge base can be enriched with application or task specific knowledge by editing the user interface style knowledge base.As a simple example of such rulesets,the following rule(expressed in OORL): (@RULE=TEditOutputSpec(@LHS=(Is(<|NOOS_TEdit|>.usage)("text-output")))(@HYPO=EditWidget)(@RHS=(Let(<|NOOS_TEdit|>.scrollable)(TRUE))(Let(<|NOOS_TEdit|>.editable)(FALSE)))KNOWLEDGE BASED MANAGEMENT OF SOFTW ARE OBJECTS3)states that text edit widgets used only for text output are by default scrollable and not editable.The NOOS_TEdit notation refers to a class that describes text edit widgets.This class,its subclasses,superclasses,and instances are all part of the user interface style knowledge base.The software objects knowledge base contains rules to design,select,and reuse objects in the NOOS environment.A point in the software objects problem space represents a set of software components with their encapsulated methods coded ei-ther in OOPL or in OORL.These software components both capture the dynamic behavior of the user interface under design,and its intended interactions with the application.The rule base prunes this problem space by suggesting software com-ponents to reuse,or redesign to implement the specifications of the user interface. The software objects rule base also keeps track of versions of software components being reused or redesigned.The following rule from the software objects knowledge base:(@RULE=TableEditor_Select(@LHS=(Is(Editor.EditeeStructure)("table","list"))(Yes(Editor.EditeeEdition))(Is(Editor.EditionMode)("modal"))(Is(Editor.EditionRestrictedOps)("none")))(@HYPO=SelectEditor)(@RHS=(LoadKB("TBL_b")(@LEVEL=ENABLE;))(CreateObject(’editor’\WidgetId\)(|TBLEdit|))(Do(WidgetId+1)(WidgetId))))suggests the use of a software component,namely a table editor,in response to constraints on the focus of the edition process,and the subject of the edition, expressed in its left hand side.The right hand side loads the table editor classes and attached methods,and creates an instance of the latter editor for use in the current interface under design.The system knowledge base contains rules representing the NOOS processes themselves.Each passive element of the NOOS environment,such as driver li-braries or the virtual graphic machine,is represented as an object in the shared repository.Object representation is also used to describe the NOOS active tools, such as the OOPL compiler and interpreter,the OORL inference engine,as well as underlying CASE tools that might be used to build methods in conventional programming languages,such as a C compiler,a Make utility,and other standard facilities.The rules express how the active tools apply to the passive elements in the NOOS environment to generate the target end user interface executable code. Preconditions to the application of an active tools are checked by left hand sides, while postconditions are asserted by right hand sides.The whole code generation process can thus be amended by editing the system knowledge base.The following subclass from the system knowledge base exemplifies the object-oriented description of the NOOS code generation processes:4JEAN-MARIE CHAUVET(@CLASS=OORL_InferenceRuntime(@PROPERTIES=FileNameIncludeFileLibraryOperatingSystemRuntimeDefFileSourceExtensionVersionWindowingEnvt))The previous class describes the OORL inference engine in its runtime version,for inclusion in the generated user interface.The default values,defined at the class level,are shown next:(@SLOT=OORL_InferenceEngine.FileName(@INITVAL="libnxpshr.a"))(@SLOT=OORL_InferenceEngine.IncludeFile(@INITVAL="nxpdef.h"))(@SLOT=OORL_InferenceEngine.Library(@INITVAL="shareable"))(@SLOT=OORL_InferenceEngine.OperatingSystem(@INITVAL="unix"))(@SLOT=OORL_InferenceEngine.SourceExtension(@INITVAL=".tkb,.ckb,.kb"))(@SLOT=OORL_InferenceEngine.Version(@INITVAL="1.2.0"))the system knowledge base rulesets capture how to use these objects in the code generation,and application building process.The previously described layers encapsulate design knowledge into NOOS.The environment,however,also provides facilities to embed domain or user specific knowledge to be applied at execution time.Two major benefits stem from this tighter integration:interfaces produced with the NOOS environment are themselves knowledge-based and can dynamically adapt to the user,and there is a seamless in-tegration of the interface and application for the expert system developer:interface objects and application objects have the same representation.KNOWLEDGE BASED MANAGEMENT OF SOFTW ARE OBJECTS5Shared Object RepositoryEntities relevant to both the target expert system and its user interface have the same representation and are stored in a common logical location in the NOOS environment:the Shared Object Repository.As mentioned in previous sections,objects for the user interface widgets,objects for the various software components of the user interface,as well as objects de-scribing the entire NOOS architecture are part of the design knowledge built-in the environment.The latter objects together with the domain or application specific objects are sharing the same representation and storage facility.The Shared Object Repository offers original facilities to handle such a variety of common objects for such different usages in the design and execution process.Objects as a common data structureIn reference to Tomlinson et al.[15]classification attempts of object-oriented systems,the Shared Object Repository organization and sharing protocols are dis-cussed.The underlying design consideration in the NOOS environment Shared Object Repository is that objects are common abstract data structures that map relevant entities from different applications.Tables and records in a database application, data structures in a conventional programming environment,graphic widgets in a user interface,3D geometrical shapes in a CAD/CAM program for instance are views on objects relevant to the processes running in their respective applications. The Shared Object Repository organisation and sharing protocols were designed to provide an object representation suited to a heterogeneous software environment: objects are considered as a common data structure on which both procedural and heuristic types of processing can be applied.Conventional class-based systems place constraints on object structure and re-strict the sharing relationships to groups of objects.Prototype-based systems,on the other hand,overcome the lack of expressiveness of purely class-based systems. Default or exceptional attribute values,and relationships that vary on a per-object basis are better handled by the latter systems[15].The Shared Object Repository is such a prototype-based system to accomodate the underlying dynamics of objects in expert sytems,or user interface environments.In the Shared Object Repository there is thus no distinction between an in-stance variable and a shared variable:any instance variable can serve as a shared variable for other objects.Objects are defined by reference to prototypical objects with which they share some properties.The prototype-based sharing protocol also enables attributes to be omitted,default values and methods to be provided for instance variables avoiding the”one-instance”problem.In addition the prototype-based sharing protocol offers opportunities for late binding to a higher degree than class-based mechanisms[15].As an example,version handling in the software ob-jects knowledge base required late binding in the OOPL object-oriented language [3].The second design consequence entailed by the heterogeneity of objects stored in the Shared Object Repository is that the message-passing system should pro-vide enoughflexibility to express widely different control structures as found in the OOPL,and the OORL.More specifically once the method for handling a message is located it is actually performed by the object in which the method was found,6JEAN-MARIE CHAUVETand not returned to the caller as it is in inheritance.The open architecture choices in the NOOS environment provide a substrate for coding such methods in conven-tional programming or database languages,OOPL,and OORL or a mix of these. Consequently delegation was implemented as an appropriate organization protocol for message passing[13].In the OOPL the”send”primitive(”¡-”symbol in OOPL syntax)accepts a target and a message represented as a list of components.Messages are either replies, conveying information back to an awaiting target object,or requests.Requests cause the target object to undertake the task specified by the message of delegate it to some other object.A request retains the client object on behalf of which the message is to be handled.As an example,consider the following OOPL fragment that updates a cursor location and accesses its horizontal and vertical coordinates for further processing:cursor<-IncrementBy:10And:25newH=cursor<-h newV=cursor<-vThis script offsets the position of a cursor by an amount of10,and25pixels respectively in the horizontal and vertical direction.An strictly inheritance-based implementation such as the following[12]:(@SCRIPT=cursor.IncrementBy_And_(self.h=self.h+IncrementByself.v=self.v+And))updates encapsulated properties cursor.h,and cursor.v.In contrast the following implementation:(@SCRIPT=cursor.IncrementBy_And(frame<-dHor:IncrementBy dVer:And))delegates the request to the frame object.From the caller viewpoint,however,the horizontal and vertical location of cursor have been updated correctly even though execution was delegated in the latter case.Each object defines the condition under which it will delegate and,in the case of multiple proxies,how it will choose among them.Again to exemplify theflexibility brought by the delegation mechanism of the Shared Object Repository,this modified script:(@SCRIPT=cursor.IncrementBy_And(mainwindow=cursor<-windowmainwindow<-FirstFrameDo:dHor_dVer With:IncrementBy))delegates the cursor update to thefirst frame attached to its enclosing window sorted in hierarchical inclusion order.The script uses the iterative message First-FrameDo to select the actual object to which the operation is to be delegated.Delegation and prototype-based protocols for sharing and organization are the key features of the Shared Object Repository view of objects as a common dataKNOWLEDGE BASED MANAGEMENT OF SOFTW ARE OBJECTS7structure.These implementation choices,in turn,enable the designer to specify the control structures for its target application in terms of integrated procedural and heuristic processing of objects.Cooperative processing of objectsThe NOOS environment provides procedural and heuristic approaches to be-havior specification for end-user interfaces.The procedural language implements the delegation-based organization protocol for the Shared Object Repository.The rule based language enables the designer to embed domain or application specific knowledge for execution of the user interface.In addition the target application being usually a knowledge-based application, the OORL can also be used to model the expert system for which the user interfaceis being designed.The latter expert system can in turn call OOPL programs to perform certain operations better expressed in a procedural language.In this respect,although there is a clear cut separation between user interface and application in the design phase and the delivered executable code,there is a strong consistency in the synctactic constructs used to model both the behavior of the user interface,and the knowledge processing of the application.The following rule from a process control application illustrates calling out to an OOPL program:(@RULE=Valve1_Control(@LHS=(>(tank1.pressure)(100))(>(DATE(evidence.ystamp,evidence.mstamp,evidence.dstamp)-NOW())(0))(Yes(Trend_Analysis)))(@HYPO=Alert1)(@RHS=(Execute("OOPL")(@ATOMID=tank1.close;))))its last right hand side action calls out the OOPL interpreter and sends the close message to the tank1object.It is actually similar to the following OOPL fragment: tank1<-closethe key point being that the object tank1is effectively a shared object between the application knowledge base and the OOPL program.If it also happens that the user interface displays this particular tank1,becauseit was specified that tank1is also an instance of a gauge widget for instance,then the OOPL close program might look like the following fragment:(@SCRIPT=tank1.close(self<-UpdateDisplayself.valve="closed"))8JEAN-MARIE CHAUVETwhere the UpdateDisplay is inherited from the gauge widget class.In this case tank1is also shared by the user interface where it is only viewed as graphic display of a gauge.Moreover the link from the tank1object to the graphic gauge widget class can be altered by the rule base or the OOPL scripts of the user interface.This additionalflexibility provides opportunities for dynamic interface reconfiguration. Without changing the previous OOPL program called from the knowledge base,a different display output can be obtained by reclassing tank1into another widget class as long as the latter provides an UpdateDisplay method.This operation can be performed from an OOPL program or from a rule.As mentioned earlier,domain specific knowledge embedded in the user inter-face behavior specification allows creation of knowledge based user interfaces.The delegation organization protocol of the Shared Object Repository provides a di-rect implementation of message passing between an OOPL-coded method and an OORL-coded behavior.When an OOPL program calls out to a knowledge base it actually delegates the operation to an object,named NXP,in the system knowledge base of NOOS that models the OORL inference engine.The following OOPL method:(@SCRIPT=gauge.click(self.ClickButton=click<-ButtonPressedNXP<-Knowcess))is called to handle a click in the graphic display of a gauge object.The method actually delegates processing of this event to the knowledge base by sending the Knowcess(”run”)message to the NXP object.The Knowcess method in turn starts the inference engine.Since objects are stored in the Shared Object Repository,the knowledge base directly accesses the gauge object if needed as is shown in this simple example rule:(@RULE=Operator_Gauge_Reset(@LHS=(Is(gauge.ClickButton)("left"))(Is(gauge.status)("alert")))(@HYPO=Operator_Reset)(@RHS=(Let(gauge.status)("offline"))))where thefirst condition in the left hand side directly tests a variable set by the calling OOPL method.The tight integration of the OOPL and the OORL on top of the Shared Object Repository emphasizes a cooperative processing approach to the problem of speci-fying the control structure of user interfaces,and knowledge based applications.KNOWLEDGE BASED MANAGEMENT OF SOFTW ARE OBJECTS9DiscussionThe main problem addressed by this research was to design knowledge represen-tations of entities and processes of software design considered as a problem-solving activity,and test the representations in a working implementation.There has been extensive research work undergoing on issues related to the problem of assisting the software engineering process[9].Although most of this work would probably fall under the label of Artificial Intelligence,some inspirational concepts clearly came from the graphics community.Software engineering appears as an ill-structured problem[10].Some studies were concerned with the understanding of software engineering methodologies in A.I.[6],but most of the research work is focused on knowledge representation schemes suitable for software engineering processes and constructs[9,1].The ap-proach chosen to address this problem was to consider software design as a prob-lem solving task.Following the classical problem-solving methodology of A.I.,the problem spaces relevant to software design were identified.Their respective states, operators,and rules were designed and represented as objects and rules.The essen-tial heterogeneity of the latter objects,considering the domain of user interfaces, called for a veryflexible object organization and processing capability.The Shared Object Repository with its OOPL,and OORL is an attempt to provide an appro-priate modeling framework to represent knowledge of software design.Furthermore this architecture allows to comine A.I.and CASE methodologies for representing the software design task.Another strong current of research in A.I.and software engineering is related to algorithm design[2],and understanding of the programmer problem solving activ-ities-notably the Programmer’s Apprentice project[8].The NOOS environment, in its current stage,has no built-in knowledge based capability for algorithm de-sign per se.The Shared Object Repository might,however,offer an appropriate knowledge representation for such developments.An active domain related to the work presented here is generally refferred to as object-oriented database developments.Actually,the Shared Object Repository can be viewed as an object-oriented database.As such it can be classified as a prototype-based,delegation-based object oriented system[15].Variations on the organization and sharing protocols are found in the various existing object-oriented systems.Prototype protocols are appropriate for handling the heterogeneity of relationships between objects which is essential to the problem space.Delegation protocols offer the best compromise for consistently integrating widely different con-trol mechanisms.In addition,the NOOS environment supports a fully integrated rule language for bringing knowledge to bear both in the design process itself and in the application execution at runtime.In this respect it is very close to systems like GARDEN[7],POGO[14],or Im-pulse86[11].Such development environments are instances of the wider category of User Interface Management Systems(UIMS).The cooperative processing of objects in the Shared Object Repository is an attempt to extend this notion of intelligent, or knowledge-based UIMSs towards the more promising concept of objects seen as common data structures between otherwise unrelated applications.10JEAN-MARIE CHAUVET1.References1.Arens,Y.,Miller,L.,Shapiro,S.C.,Sondheimer,N.K.Automatic Construc-tion of User-Interface Displays.In Proceedings of AAAI88(Saint Paul,Minnesota, August21-26,1988).Morgan Kaufmann Publishers,San Mateo,1988,pp808-814.2.Kant,E.,Understanding and Automating Algorithm Design.In Proceedings of IJCAI85(Los Angeles,California,August18-23,1985).Morgan Kaufmann Publishers,Los Altos,1985,pp1243-1254.3.Kim,W.,Ballou,N.,Chou,H.T.,Garza,J.F.,Woelk,D.Features of the ORION Object-Oriented Database.In Object-Oriented Concepts,Databases,and Applications(Edited by Kim,W.,Lochovsky,F.).ACM,New York,1989,pp 151-177.4.Lieberman,ing Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems.In Proceedings OOPSLA1986,pp214-223.5.Moss,J.E.Object Orientation as Catalyst for Language-Database Integration. In Object-Oriented Concepts,Databases,and Applications(Edited by Kim,W., Lochovsky,F.).ACM,New York,1989,pp151-177.6.Partridge,D.Artificial Intelligence:Applications in the future of software engineering.Ellis Horwood,Chichester,England,1986.7.Reiss,S.An Object-Oriented Framework for Conceptual Programming.In Re-search Directions in Object-Oriented Programming(Edited by Shriver,B.,Wegner, P.).MIT Press,Cambridge,1987,pp165-189.8.Rich,C.The Layered Architecture of a System for Reasoning about Programs. In Proceedings of IJCAI85(Los Angeles,California,August18-23,1985).Morgan Kaufmann Publishers,Los Altos,1985,pp540-546.9.Selfridge,P.G.How to Print a File:An Expert System Approach to Software Knowledge Representation.In Proceedings of AAAI88(Saint Paul,Minnesota, August21-26,1988).Morgan Kaufmann Publishers,San Mateo,1988,pp380-387.10.Simon,H.A.Sciences of the Artificial,MIT Press,Cambridge,1982.11.Smith,R.,Barth,P.,Young,R.A Substrate for Object-Oriented Inter-face Design.In Research Directions in Object-Oriented Programming(Edited by Shriver,B.,Wegner,P.).MIT Press,Cambridge,1987,pp165-189.12.Snyder,A.Inheritance and the Development of Encapsulated Software Sys-tems.In Research Directions in Object-Oriented Programming(Edited by Shriver,B.,Wegner,P.).MIT Press,Cambridge,1987,pp165-189.13.Stein,L.A.,Lieberman,H.,Ungar,D.A Shared View of Sharing:The Treaty of Orlando.In Object-Oriented Concepts,Databases,and Applications(Edited by Kim,W.,Lochovsky,F.).ACM,New York,1989,pp151-177.14.Tarlton,M.A.,Tarlton,P.N.Pogo:A Declarative Representation System for Graphics.In Object-Oriented Concepts,Databases,and Applications(Edited by Kim,W.,Lochovsky,F.).ACM,New York,1989,pp151-177.15.Tomlinson,C.,Scheevel,M.,Kim,W.Sharing and Organization Protocols in Object-Oriented Systems.Journal of Object-Oriented Programming2,4(Nov/Dec 1989),25-36.Neuron Data,444High Street,Palo Alto,CAE-mail address:jmc@。