kase: an integrated environment for software design

Knowledge Systems Laboratory December 1991Report No. KSL 91-73 (updated March 1992)

KASE: An Integrated Environment forSoftware Design

by

Sanjay BhansaliH. Penny Nii

Appears in Proc. of 2nd International Conference on AI in Design 1992.

KNOWLEDGE SYSTEMS LABORATORYDepartment of Computer Science

Stanford UniversityStanford, California 94305

2 S. BHANSALI AND H. P. NII

KASE: AN INTEGRATED ENVIRONMENT FORSOFTWARE DESIGN

SANJAY BHANSALI and H. PENNY NIIKnowledge Systems Laboratory

Stanford University701 Welch Road, Bldg. C, Palo Alto

CA 94304, U.S,A.

Abstract. Software design consists of determining a high-level organization of asystem that meets a given problem specification. We present a prototype system calledKASE (Knowledge Assisted Software Engineering) that helps system analysts anddesigners design and redesign software systems. The KASE environment providesknowledge representation and reasoning tools to integrate knowledge about generalsoftware design principles, prototypical software architectures, and application domain.Unlike CASE tools and module interconnection languages that represent the structure ofa software system without its semantics, the goal of KASE is to integrate both thestructure and the semantics of software modules and to provide active assistance in thedesign of systems. We illustrate the design process in KASE through an example,focusing on the ability of KASE to provide a co-operative man-machine designenvironment.

1. Introduction

Software system design is a high-level organization of system componentsthat meets a given problem specification. The design process consistsprimarily of decomposing problem specifications into functional modules orsubsystems, defining the interfaces and the dependencies between themodules, allocating high-level tasks to computing agents, and determiningrepresentation schemes for data. A good software design should enable theimplementation of the software to proceed in a modular and largely routinemanner.

Like all design activities, designing software systems is a knowledge-intensive task. Several studies, e.g. (Adelson & Soloway, 1985; Guindon,Krasner, & Curtis, 1987) have found that the predominant cause of failuresamong system designers is lack of knowledge – knowledge about the task

ARTIFICIAL INTELLIGENCE IN DESIGN ’92 3

domain, knowledge about design schemas, knowledge about designprocesses.

• One major difficulty in software design is the need to integrateknowledge from multiple domains. As one moves towards abstractdescription of software design, the description becomes increasingly tied tothe description of the application domain. That is, the concepts andconstraints of the task domain are integral parts of software design. Inaddition, Jeffries et al. reported that a designer’s knowledge becomes moredomain-specific and detailed as he gains expertise (Jeffries, Turner, Polson,& Atwood, 1981). Thus, in addition to knowledge about software –architectures, algorithms, data structures, programming languages – creatingsoftware design requires domain-specific knowledge.

• Because requirements are ambiguous and incomplete (Swartout &Balzer, 1982; Parnas & Clements, 1986), and because both the requirementsand the environment in which the software operates are in a constant state offlux, there is a need for problem structuring during software design(Guindon, 1990). Problem structuring is the process of discovering missinginformation and redefining the problem space based on the new information.Missing information often includes unstated problem statements which areimplicit aspects of the application domain.

• With few exceptions, current tools for software design, i.e. CASE tools,are little more than graphical editors that can help in creating high-leveldiagrams (e.g., a data flow diagram) and in ensuring the syntacticconsistency of these diagrams. These tools serve to document a softwaredesign, but they do not posses knowledge about the task domain, and hencecannot provide active support in the initial design process, or in thesubsequent modifications to the design. Tools like gIBIS (Conklin &Begeman, 1989) provide an environment where the rationale for a designprocess can be captured and referenced. However, like CASE tools, they tooprovide only passive assistance to a designer (that is, the initiative for thedesign process lies only with the user with the tools simply providing amedium for documentation).

What is needed are software design tools that explicitly model domainknowledge and facilitate the reuse of this knowledge by (1) deliveringrelevant knowledge in the appropriate context and (2) ensuring that designerrors are not introduced during design modifications. An environmentcontaining such tools should also record the decisions made in the designprocess. The record can be used to determine dependencies between variousdesign steps, to retract design decisions, and to provide a context for designmodifications when requirements change.

Finally, in order to aid understanding, the environment needs to providetools that help the designer visualize both the structure and the behavior of


the designed artifact. As Brooks notes, software is inherently a very complexartifact and is difficult to visualize in its entirety (Brooks, 1987). What isneeded are ways to "see" software from different viewpoints. The LaSSIEsystem (Devanbu, Brachman, Selfridge, & Ballard, 1991) uses four views: thedomain model view, the architectural view, feature view, and code view. Theseviews correspond to different knowledge domains apparent in the design. Inaddition to these views a designer should be able to "see" software usingpictorial notations - e.g. an integrated view of control flow, data flow, andfunctional decomposition of modules (Guindon, 1992).

2. KASE (Knowledge Assisted Software Engineering) Environment

We describe a software design environment called KASE that provides activeassistance in the design of a software system. Some of the basic ideasunderlying KASE are:

• identify the knowledge domains used in software design,• encode the knowledge separately, and• provide tools to instantiate and integrate the knowledge in the service

of designing a system that meets the problem specifications.The current prototype KASE contains in its knowledge base a

prototypical software architecture (called generic architecture) that can beused as a basis for designing solutions to a class of problems (called genericproblem), a domain model that can be used to interpret the problemspecifications, and heuristics for designing applications using the genericarchitecture. As shown in Figure 1, the objective is to expand a givenproblem statement in terms of the concepts and operations in the domainmodel, instantiate the generic architecture, and map the domain concepts andoperations onto the architecture. We call this process customization –customize a generic architecture to fit the application.

Generic problem

Problem specification

Generic architecture

Application domain model

Editing commands

Problem-specific architecture

CustomizationProcess

Redesign

Fig. 1 Customizing an architecture


2.1 GENERIC PROBLEMS

A generic problem represents a class of problems; individual problems arespecified as instances of the class. By identifying problem classes, one candesign knowledge representation schemes, architectures, and reasoningprocesses which are appropriate for the general problem, and reuse them forseveral different problem instances. Therefore, the identification andspecification of such a class of problems is a task that precedes, and is aprerequisite of, the subsequent design activity using KASE1.

The specification of a generic problem results in the creation of aproblem schema which is analogous to the notion of cl iches in theProgrammer's Apprentice (Waters, 1985). A problem schema specifies thehigh-level structure of a problem specification and has certain roles, whichrepresent the parameters of the problem, and constraints on the values of theroles. Instantiating these roles with specific values results in the creation of aspecific problem specification.

Continuous-Signal-Interpretation :Generic-problemSignal-Inputs: )<var> : (SEQ :FROM <int> :TO <int> (<fields>)

<field-description>)]+

Body: WHILE <formula> DO <statements> ENDWHILETask Assumptions: <task-assumptions>

where<fields> ::= <identifier> | <identifier> <fields><field-description> ::= EXIST <objects> SUCH-THAT <condition><statements> ::= <statement> ; <statements> | <statement><statement> ::= (IF <formula> THEN-DO <statement>) |

(FORALL <vars> <formula> DO <statement>) | (PRINT <terms>)

<formula> ::= (FORALL <vars> <formula>) | (EXIST <vars> <formula>) | (AND <formulae>) | (OR <formulae>) | (IMPLIES <formula> <formula>) | (NOT <formula>) (Predicate <terms>)

<task-assumptions> ::= (UNRELIABLE-SIGNAL <var>) | (INCONSISTENT-SIGNAL S <var> <var>) | (REDUNDANT-SIGNAL <var>) | (ASYNCHRONOUS-SIGNAL <var>) |

1It is assumed that a library of generic problems, associated architectures, and the domainmodel are an integral part of the KASE environment.


Fig. 2. Specification of the generic problem of continuous signal interpretation.

Figure 2 shows the schema for an example generic problem: tracking aset of mobile objects by interpreting signals that are being continuallygenerated by the objects. (This generic problem can be instantiated, e.g. tothe problem of tracking aircrafts from radar and voice signals (Brown,Schoen, & Delagi, 1986) or tracking ships from sonar data (Nii, Feigenbaum,Anton, & Rockmore, 1982). This problem has three parameters: (i) thespecification of the input signal(s); (ii) the main body or functionaldescription of the problem in the form of an extremely high-level program;and (iii) certain characteristics of the domain and the environment. Theconstraints on the schema roles are specified by specifying a grammar forinstantiating the roles.

2.2 GENERIC ARCHITECTURES

Associated with each generic problem is a set of (possibly one) genericarchitectures, which can be used to create a system for solving instances ofthe generic problem. A generic architecture is a collection of parameterizedmodules and intermodular dependencies. A parameterized module is alogical collection of software entities like procedures, types, etc. in whichsome of the entities are abstracted as parameters. A parameter can be, amongother things, an algorithm, a representation scheme, or a sub-module. Thedesign process is viewed as an instantiation of the various parameterscomprising a generic architecture. However, even though our approach todesign can be considered as an instance of parameterized design, theparameters can be fairly complex entities and the design task is non-trivial(see Section 3 for examples).

The structure of the generic architecture determines the basic solutionstrategy for solving the problem. For example, the continuous signalinterpretation problem given earlier can be solved using a symbolic,knowledge based approach, or by statistical analysis of the data and the twosolutions would have radically different architectures. The degree of detail inspecifying an architecture depends on the generality of the associatedgeneric problem. Thus, one could have a very general architecture (forexample, a generic blackboard architecture), which could be used on a largenumber of problems sharing certain properties, or one could have a veryspecific architecture (for example, an architecture for a payroll system) withdetailed specifications of all the functional modules.

A module description includes information about the input and outputdata flows of the module, the submodules/supermodules structural relations,the services it requires from other modules, the services it provides to an


external module, the precondition and postconditions for each serviceprovided by the module, and/or a program template that implements eachservice. Some of this information is useful in visualizing the organization ofa software system from different views. For example, the input and outputdata flow and the submodule relationship are used to construct a data flowdiagram; the program templates and the data flow are used to construct amodified Action diagram (Martin & McClure, 1988) which shows both theflow of control and data within a module. Thus, KASE provides anenvironment which is a natural extension of the environment provided bycommercial CASE tools.

The most interesting aspect of the module description is that some of itsattributes are viewed as parameters of the module. Associated with eachparameter attribute is a method which can be used to determine the value ofthe parameter. The complexity of the method depends on the type of theparameter. For example, it may be a simple process of selecting between apre-determined list of alternatives, or it may involve sophisticated reasoningusing domain knowledge and heuristic rules.

Figure 3 shows the functional decomposition view of a genericarchitecture for the continuous-signal-interpretation problem class andFigure 4 shows a partial description of the signal-interpreter module of thegeneric architecture.

Control Panel

Level-1

Level-2

Blackboard Panel

Situation board

Report Acceptor

Signal feeder

Controller

Ksource-1

Ksource-2

Tracking-componentSignal-interpreter

Fig. 3. A functional decomposition of the generic architecture for the continuous-signalinterpretation problem. The architecture shows the main modules comprising the

architecture.

2.3 DOMAIN MODELS


The third and final knowledge encoding in the KASE environment consistsof a model of the application domain. This process has been called domainmodeling (Neighbors, 1984). The domain model provides the ontology ofterms and operations used to describe an application domain independent ofa specific problem specification; several different problem specifications canthen be stated in a high-level language using this ontology. This provides apowerful form of reuse that is one of the keys to large scale improvement insoftware productivity.

Signal-Interpreter isa modulesubmodules Situation-board, Tracking-component, Controllersupermodule CSI-systemi n p u t s ?s : SEQ(signal)outputs ?r : SEQ(report)requires (print-report ?r), (read-next-signal) :signal, (start-execution)p r o v i d e s (main)c a l l s report-acceptor, signal-feederc a l l e d - b y nilparameters

1) Controller2) SituationBoard

c o n s t r a i n t s1) Controller is instantiated to an EventDriven-Controller iff SituationBoard is instantiated to an EventDriven-SituationBoard.2) Only the TrackingComponent should have a dataflow into the SituationBoard.3) Only the Controller module can call the Tracking-Component.

. . . . .s e r v i c e - d e f i n i t i o n smain() begin start-execution() % It simply calls the service start-execution end % provided by the Controller module.

Fig. 4. Representation of the Signal-interpreter module in the generic architecture.

We are developing an object-oriented modeling environment that createsa model from three different perspectives - static or object model, behaviormodel, and functional model (Rumbaugh, Blaha, Premerlani, Eddy, &Lorensen, 1991). For the purposes of this paper we limit ourselves to theobject and the functional models.

The primary components of the static domain model are objects andrelations between the objects. An object is an abstraction of some entity inthe application domain, e.g., an aircraft or a signal. Associated with eachobject is a set of attributes which are properties that describe an instance ofan object. We distinguish between primitive attributes and derived attributes.Primitive attributes are those that must be explicitly specified for eachinstance of an object; derived attributes are those that can be computed from


primitive attributes of the object and/or other data. With each derivedattribute is a set of definitions that describe how the value is to be computed. Besides attributes, there are a set of methods associated with each object.Methods are operations that change the state of an object. The description ofa method includes the pre- and post-condition stating when the method is tobe applied. Examples of how objects, relations, and the operations on themare modeled are given in Section 3.

2.4 CUSTOMIZATION PROCESS

The customization process consists of refining a selected generic architectureinto a detailed architectural specification based on the model of the domainand the problem specification. In KASE, the customization process isperformed in an interactive and mixed-initiative setting. The role of KASE inthe design process is that of an intelligent design associate that providessuggestions on how to refine the architecture, carries out the commandsinvoked by the user, informs the designer of constraint violations in thedesign, keeps a record of the design steps and the dependencies between thesteps so that incremental modifications to the design can be done efficiently.

The knowledge used by KASE in providing these kinds of assistanceincludes general, domain independent knowledge about software design,architecture-specific knowledge for the instantiation of various architecturalparameters, as well as specific heuristic knowledge about design related to aparticular domain. Most of the domain independent design knowledge isrepresented in the form of constraints (e.g. those relating different levels of adata flow diagram), and KASE contains mechanisms which automaticallykeep track of these constraints as well as heuristics for resolving constraintviolations (Nii, Aiello, Bhansali, Guindon, & Peyton, 1991). The architecturespecific knowledge includes a set of constraints governing the relationshipsbetween different components of the architecture, a library of reusablemodules and schemas which can be used to instantiate the architecturalparameters, and a collection of heuristic rules and algorithms which can beinvoked by a designer to instantiate certain parameters and optimize thedesign.

2.5 REDESIGN

We subscribe to the view that most software design is redesign. A new designis created by modifying parts of an extant design. The modification mayinvolve changing a design either due to a design error or as a result of achange in the problem requirements or the computing environment. KASEuses different mechanisms to support these two kinds of modifications.


2.5.1 Redesign due to error in original design. KASE automatically checksfor violations of several kinds of constraints and helps the designer modifythe architecture to resolve the inconsistencies. The constraints in KASE arecurrently divided into three categories.

(1) General architectural constraints. These are constraints that have tobe satisfied by all architectural designs. Examples of such constraints are:"Every data link must have a consumer and a producer" and "If a module Xrequires a service F, then there must be some module Y which is called by Xand module Y provides service F".

(2) Specific architectural constraints. These are constraints that arespecific to all instances of a particular generic architecture. For example, anarchitecture based on the blackboard model might have constraints: "Theremust be no data flow or control flow between two knowledge sourcemodules" and "If the BlackboardPanel is instantiated to a Data-drivenBlackboard Panel then the Controller module should be instantiated to aData-driven controller module".

(3) Stylistic constraints. Stylistic constraints are those that are derivedfrom design principles that are considered 'good', for example, "A modulemust not be decomposed into more than n submodules at any level ofabstraction." Stylistic constrains may be divided into general stylisticconstraints and constraints specific to an architecture. However, currently allstylistic constraints in KASE are general constraints.

Each constraint in KASE is associated with a trigger, a predicate, and anoptional resolving-action. A trigger is a set of actions that can potentiallycause the constraint to be violated, for example, the constraint, "Every datalink must have a consumer and a producer," has a trigger consisting of twoactions Delete-module and Add-datalink. A predicate is a Lisp expressionthat checks to see whether the constraint is actually violated. Resolving-action is a set of actions that may be taken to remedy the constraint violation.

KASE monitors the design activity and flags each constraint that istriggered by a user action. When a user indicates the completion of a designsession, KASE checks the predicates for each flagged constraint to seewhether the constraint is actually violated. Quite often, a constraint that getsviolated by a design action is resolved by a later action, and such constraintviolations should be, and are, transparent to the designer.

When KASE reports a constraint violation, the designer can ask KASEfor a list of suggestions on how to resolve the error. Depending on thenature of the constraint, KASE presents a list of different actions that may betaken to remove the constraint violation. (KASE currently does not considerthe effects of any of the actions on the rest of the architecture; thus, it ispossible that some of the suggestions offered by KASE remove the current


constraint violation but may introduce other constraint violations.) The usercan then choose either one of the actions suggested by KASE or take someother action.

2.5.2 Redesign due to change in requirements.KASE provides tools thatcan help a designer in modifying parts of a design to meet new requirementswithout having to start from scratch. First, KASE maintains a history of allthe design steps and allows the user to go back to any previous state of thedesign. It does this by replaying the design history from the initial state tothe desired state.

A second redesign support provided by KASE is in localizing the effectsof a design change. KASE uses dependencies between design steps tostructure a linear design history into a lattice. When the user wants to undothe effect of a particular design step, KASE uses the position of that designstep in the derivation history to determine what other design steps areaffected by it (Bhansali, 1992).

3. An Example System Design

In order to illustrate the capabilities of the KASE environment, we will stepthrough the design of a system called ELINT (Brown, Schoen, & Delagi,1986) that was developed several years ago as part of a multi-sensorinformation fusion system called TRICERO. The objective of the ELINTsubsystem was to analyze processed, passively acquired, real-time radar datafrom radar emitting devices (called emitters) in aircrafts. The primary inputto ELINT was time-ordered streams of processed observations from multipledata collection sites. In addition, ELINT received periodic feedback fromanother system in TRICERO about specific aircraft activities. The outputsfrom ELINT consisted of periodic status reports about the activities ofclusters of radar-emitting objects in the area under surveillance. (A cluster ofemitters could be a single aircraft with more than one radar-emitting devicesor more than one aircraft.) The report included such information as theposition and heading of clusters, description of possible aircrafts comprisingthe cluster, and an indication of the cluster's current activity.

The architecture of the original ELINT system was based on theblackboard model (Nii, 1989). The basic components of a blackboard-basedsystem are a shared, global data structure called the blackboard whichrepresents the current problem-solving state, a set of components calledknowledge sources that contribute information to the blackboard leading to asolution of the problem, and a control component that monitors theinformation on the blackboard and decides what knowledge source to


execute next. The design of a blackboard-based system essentially consists ofdesigning these three components.

3.1 GENERIC PROBLEM, GENERIC ARCHITECTURE AND DOMAIN MODEL

Emitter

id, position, headingmode, type, speed,acceleration

create-emitterdelete-emitter

Cluster

id, position, headingactivity, threat-potential,speed, acceleration

create-clustersplit-clusterdelete-emittermerge-cluster

Cluster-member

Add-memberDelete-member

(a)

emitter.position(e:emitter, t:time) = p:positiondefinitions(1) From-two-positions-and-bearings(s1,s2: site)

precondition: s1 <> s2 definition: (= p (direction-intersection

(line-of-bearing s1 e t)(line-of-bearing s1 e t)(site-position s1 t)(site-position s2 t))).

(b)Method: create-new-cluster(e:emitter)precondition: (AND (= C (SET (c: cluster)))

(FORALL (c : cluster) (or (not (co-located c e)) (not (co-headed c e)))))

postcondition: (EXIST (c:cluster) (and (= (SET (c:cluster) (UNION C {c}))

(cluster-member c e) (= (cluster.position c) (emitter.position e) ...)))

(c)

Fig. 5. (a) Examples of objects (emitter and cluster) and relations (cluster-member) in thedomain model.The second level of each box shows attributes and the third level showsmethods on the object. (b) Definition of a derived attribute. (c) A method definition.


We assume that a generic problem that abstracts the ELINT problemspecification and a generic architecture that abstracts a class of blackboard-based architectures have already been encoded in KASE (Figs. 2 and 3). Thedesign of the ELINT system begins by first building a model of ELINT'sdomain. Figure 5a shows examples of two objects and a relation in thisdomain. Figures 5b and 5c show the definition of a derived attribute(emitter.position) and an operation (create-new-cluster).

3.2 DESIGNING THE ELINT SYSTEM

Step 1 Specifying the ELINT problem. The design of a system using KASEbegins by first specifying a problem as an instance of a known genericproblem (Figure 6). This is an instance of the generic problem shown inFig.1.

Problem: Aircraft-monitoring-systemisa: Continuous-Signal-InterpretationInputs: 1) observation : SEQ (:FROM 1 :TO EOF (eid sid eloc sloc lob etype emod qual t)

:ST (EXIST (e s) (and (emitter e) (site s) (= eid (emitter-id e)) (= sid (site-id s))

(= sloc (site-position s t)) (= lob (line-of-bearing s e t))(= emode (emitter-mode e t))(= etype (emitter-type e))(data-quality qual)))))

2) feedback : SEQ(:FROM 1 :TO EOF (cid es t) :ST (EXIST (c) (and (cluster c t) (= cid (cluster-id c)) (= es (cluster-emitters c t)))))

Program: (WHILE true DO

(IF (= (div (current-time) 100) 0) THEN-DO (FORALL c (cluster c) DO

(PRINT (current-time) (cluster-id c) (cluster-position c) (cluster-heading c)

(cluster-activity c)(cluster-aircraft-types c) (cluster-threat-potential c)))))

Task Assumptions:(Unreliable-signal observation)(Redundant-signal observation)(Asynchronous-signal feedback)(Asynchronous-signal observation)(Inconsistent-signals observation feedback)

Fig. 6. The specification of the ELINT problem.

Step 2 Selecting the generic architecture. After the problem has beenspecified as an instance of one of the generic problems, the system presents


the user with a set of different generic architectures associated with thegeneric problem. The user must select one of these architectures to serve as astarting point for his design. Currently, there is only one architectureassociated with the continuous-signal-interpretation problem, and it isautomatically selected by the system.

Step 3 Customizing the architecture. When a generic architecture is selected,KASE creates a customization menu which lists all applicable commands thatcan be used to refine the architecture. These commands represent methodsthat can be used to instantiate the various module parameters.

The modules of a generic architecture are stored in a reusable-modulelibrary. As shown in Figure 7 some of these modules represent a class ofmodules. When a generic architecture is selected, it must be instantiated byreplacing a module class by an instance of that module. For the currentarchitecture, there are four module classes - Controller, SituationBoard,ControlPanel, and the Ksources. Figure 7 shows the choices for theController, SituationBoard, and the Ksource modules.

Ksource

event-triggered

rule-evaluator

. . .

Event-driven

Expectation-driven

. . .

Controller

. . .

Situation-board

Expectation-driven

Event-driven

Fig. 7. Possible instantiations of some generic modules.

The user selects one of the choices from the customization menu. Notethat the choices for instantiating different modules are not independent. Forexample, if the SituationBoard is chosen to be Event-driven then it constrainsthe Controller to be the Event-driven Controller module. When a user selectsa particular instance for a module, KASE uses architectural constraints toautomatically prune the set of available choices for the remaining modules.

The KASE environment does not prescribe a pre-determined order inwhich to compose the architecture from modules, nor does it force the userto complete the instantiation of all the modules before proceeding to the nextstep. Rather, the initiative lies with the designer most of the time, and he/shecan build parts of the architecture in any order. Furthermore, the designercan specify only a subset of the modules comprising the architecture. Thus,for the example architecture, the user may choose to instantiate theSituationBoard and the Ksources, but leave the Controller uninstantiated.

Step 4 Determining the blackboard levels. When a particular instance of amodule class has been selected, KASE uses the parameters of that module to


update the customization menu by commands that can instantiate theparameter. Figure 8 shows the customization menu after the modulesSituationBoard and Ksource have been instantiated.

It can be seen that the customization menu contains commands thatrepresent some of the fundamental issues in designing a blackboard system:How should the blackboard be structured? How should the problem-solvingexpertise be divided into knowledge sources? What are the specificoperations to be performed by those knowledge sources? Other commandsthat are added later deal with control issues: What should be the overallcontrol paradigm – data-driven or model-driven or some other hybridtechnique? What should be the conflict resolution mechanism in thescheduler?

Fig. 8. The customization menu.

One of the first activity in designing a blackboard system is to specify thedata structure of the blackboard. The KASE environment provides low-levelediting commands which can be used to create and describe modules.However, it is expected that a designer would first use KASE's inferencingmechanism to obtain initial values for the parameters and then modify themby subsequent refinements and optimization commands.

KASE employs various kinds of general inference mechanisms andheuristics for instantiating parameters. For example, it uses several differentheuristics to determine the set of levels into which the BlackboardPanelshould be divided. One of these heuristics is based on a general goal-directed reasoning strategy. It first constructs a functional dependencygraph showing the relationships between the output objects that the systemmust produce and its input signals. From the dependency graph the systemdeduces a set of objects and relationships and their attributes which areneeded to compute the values of the output objects. Figure 9 shows the set ofblackboard levels that are suggested by KASE when the user selectsDetermine Blackboard Levels from the customization menu.


In this example, the user may decide that the representation of sites is notneeded, since the information about collection sites is only used to calculatethe position of an emitter, a calculation which can be done when the inputsignal (observation) is processed. (Currently, KASE does not provide therationale for its suggestions; we plan to address this limitation of KASE aspart of future work). Thus, the user selects only 5 of the 6 levels suggestedby the system. KASE then automatically incorporates these levels into theBlackboardPanel module.

Step 5 Determining the knowledge sources. The next typical step indesigning blackboard systems is to determine the knowledge sources thatoperate on the blackboard. The user indicates this by selecting DetermineKnowledge-sources from the customization menu.

Cluster

id aircraft-types cluster-emitters position activityheading threat-potential

id typeposition heading

id position

eid sloc emod sid lob qual eloc etype t

cid es t

Emitter

Site

Observation

Feedback

Level Attributes

Fig. 9. Blackboard levels suggested by KASE

The specific (event-triggered) knowledge source that is chosen for thismodule can be represented abstractly as a triple <P, O, E> where Prepresents the precondition events that must occur in order for theknowledge source to be invoked, O is a set of operations performed by theknowledge source that modify the data on the blackboard, and E is the set ofevents (or control data) that can be posted by the knowledge source to signalthe specific changes on the blackboard brought about by the operations.

The set of knowledge sources are determined using a three-step process.First, the system determines all relevant operations based on the structure ofthe blackboard. Next, it generates a list of potential events that can be used tosignal the occurrence of each of the operations. Finally, the system uses thefunctional dependency graph created earlier to generate the sets of


preconditions for each operation. At the end of this step the system has a listof (14, for this example) knowledge source operations.

Next, the system groups some of these operations together into a singleknowledge source. Several different heuristics can be used for grouping theoperations. The heuristic used by the system is based on the presence ofcommon preconditions: group all operations that have the same set ofpreconditions into one knowledge source. This heuristic results in thecreation of 10 knowledge sources shown in Figure 10.

PRECONDITONS OPERATIONS EVENTS POSTED

(emitter-mode updated)(cluster-emitters updated)

(processed obs)(cluster-emitters updated)

(emitter-position updated)(cluster-emitters updated)

(cluster-position updated)(emitter-mode updated)(cluster-emitters updated)

(emitter-heading updated)(emitter-position updated)(processed feedback)

(processed obs)

(split-cluster occurred)(delete-cluster occurred)(merge-cluster occurred)(emitter-heading updated)

(cluster-position updated)

(emitter-heading updated)(cluster-emitters updated)

(clock-event ?t)

[COMPUTE CLUSTER-ACTIVITY]

[COMPUTE CLUSTER-AIRCRAFT- TYPES]

[COMPUTE CLUSTER-POSITION]

[COMPUTE CLUSTER-THREAT- POTENTIAL]

[COMPUTE CLUSTER-EMITTERS]

[COMPUTE EMITTER-POSITION][COMPUTE EMITTER-HEADING]

[CREATE CLUSTER]

[DELETE CLUSTER]

[COMPUTE CLUSTER-HEADING][SPLIT CLUSTER]

[GENERATE OUTPUTS][PROCESS-INPUT OBS][PROCESS-INPUT FEEDBACK]

(cluster-activity updated)

(cluster-aircraft-types updated)

(cluster-position updated)

(cluster-threat-potential updated)

(cluster-emitters updated)

(emitter-position updated)(emitter-heading updated)

(create-cluster occurred)

(delete-cluster occurred)

(cluster-heading updated)(split-cluster occurred)

(generated-outputs)(processed obs)(processed feedback)

1

2

3

4

5

6

7

8

9

10

Fig. 10. Knowledge sources suggested by the system for the example.


3.3 REFINING THE DESIGN

Step 6 Optimizing the design. As with blackboard levels, the final decision onhow to structure the knowledge sources is up to the user. Typically, the userwould keep all the knowledge sources suggested by KASE and refine the setby adding, deleting, or modifying the knowledge sources. However, acommon design phenomenon is the desire and/or the necessity to optimizethe design. KASE provides a set of optimization commands.

One of these commands merges events. It may be the case that whenevera particular event occurs it is usually accompanied by another event, forexample, whenever the emitter-heading changes, so does the emitter-position,and the designer may not want to treat the second event as a distinct event.KASE provides a command for merging a set of events and automaticallyreplaces each occurrence of the merged events by the new event in each ofthe affected knowledge sources. Similarly, KASE provides a command tomerge knowledge-sources using one of the pre-compiled optimizationheuristics.

This example illustrates one of the guiding themes of our approach:Divide the design task between a human and KASE in a way that exploits theunique skills of each. In general, the human is better equipped to decidewhen to apply an optimization technique and what heuristics/technique to usefor the optimization, whereas the machine is better equipped to carry out theoptimization task, propagate the effects of those changes to other parts of theprogram, remember the optimization task, and if necessary, undo the effectsof the optimization operations later.

Step 7 Checking for consistency. The initial generic architecture selected bya designer is consistent (i.e., the intermodular constraints are satisfied), but isincomplete since some of the modules and the parameters of some moduleshave yet to be determined. The customization task seeks to complete thearchitectural design, but in the process a designer may introduceinconsistencies in the design. In the current example, when the user indicatesthe end of the customization session, KASE detects one architecturalconstraint violation: "The following events are posted by knowledge sources,but do not trigger any knowledge source: ..." This is an example of a designerror that can be easily introduced and may be difficult to detect. In thiscase, it actually exposes a flaw in KASE's own event-generation heuristic,which is based on the simplistic assumption that each action that is performedby a knowledge source should be reported as an event on the blackboard.


Step 8 Resolving errors. When KASE reports a constraint violation, thedesigner can ask KASE for a list of suggestions on how to resolve the error.Depending on the nature of the constraint, KASE presents a list of differentactions that may be taken to remove the constraint violation. For the aboveexample, KASE offers just one suggestion: Delete the events that are notpreconditions of any knowledge source. If the user accepts this suggestion,KASE automatically updates the knowledge source by deleting the offendingevents.

3.4 REDESIGN

Step 9 Redesigning. We illustrate KASE's redesign support very briefly usingan example. Suppose the user changes the problem specification slightly sothat instead of simply producing reports, ELINT also accepts queries aboutthe expected positions of clusters and emitters based on their past activities.The user decides to incorporate this change by treating queries asexpectations (instead of events) and processing them separately on theSituationBoard. One of the design steps the user takes is to decompose theControlPanel in the SituationBoard into two panels, EventPanel andExpectationPanel using the Copy-module command provided by KASE.KASE will check and report all constraint violations to the user. An exampleof one of the constraints violated in this case is that the data link into theExpectationPanel has no producer.

4. Related Work

Much of our approach shares ideas as well as terminology of task-orientedmethodologies for design, e.g. (Brown & Chandrasekaran, 1989;Chandrasekaran, 1986), although our work evolved independently of them.Our approach of viewing the design task as an incremental refinement of ageneric architecture using a series of knowledge-based editing command islargely inspired by research in knowledge-based software engineering, e.g.(Graves, 1991; Johnson & Feather, 1991; Lubars & Harandi, 1989; Waters,1985). Research in the reuse of generic architectures for software design isrecently receiving increased attention following a DARPA-initiated Domain-specific Reusable Architecture project.

5. Conclusion

The KASE system represents our initial attempt in building a prototypeenvironment that can offer varying degrees of assistance to a softwaredesigner by employing diverse sources of knowledge. Our current work is


focusing on extending the domain modeling representation to capture thedynamic behavior of a system by modeling states, transitions, events, andactions, and integrating it with the object and functional view of the system.

The maximum payoff from using the KASE environment is achievedwhen one has reusable architectures that can be used to design systems for afamily of related problems. We need to identify such architectures andproblem classes and use KASE for designing software systems for problemsbelonging to such problem classes.

An issue that we are interested in is to see how sensitive the domainrepresentation is to the choice of an architecture. In other words, we wouldlike to explore how much of the application domain knowledge encapsulatedin a domain model can be reused to design software systems based oncompletely different architectures.

In parallel with the above, we are exploring the issue of design rationalecapture and its reuse during redesign. KASE's current redesign capabilitieswere mentioned briefly in this paper. We are interested in extending thesecapabilities so that KASE can automatically incorporate certain changes inproblem requirements into the design by using analogical or case-basedreasoning (Bhansali & Harandi, 1991).

Acknowledgements

The KASE system is a result of several people's work. We gratefullyacknowledge the contributions made by Nelleke Aiello, Raymonde Guindon,Liam Peyton and Go Nakano who wrote most of the code for KASE.

References

Adelson, B. & Soloway, E.:1985, The role of domain experience in software design.IEEE Transaction on Software Engineering, SE-11(11), 1351 - 1360.

Bhansali, S.:1992, Generic software architecture based redesign. AAAI SpringSymposium on Computational Considerations in Supporting IncrementalModification and Reuse, Stanford, CA.

Bhansali, S. & Harandi, M. T.:1991, Synthesizing UNIX Shell Scripts usingDerivational Analogy: An Empirical Assessment. Ninth National Conference onArtificial Intelligence, Anaheim, CA. Pages 521-526. AAAI Press/The MIT Press.

Brooks, F. P., Jr.:1987, No Silver Bullet: Essence and Accidents of SoftwareEngineering. IEEE Computer, April

Brown, D. C. & Chandrasekaran, B.:1989, Design Problem Solving: KnowledgeStructures and Control Strategies. San Mateo, CA: Morgan Kaufmann Publishers,Inc.

Brown, H. D., Schoen, E., & Delagi, B. A.:1986, An Experiment in Knowledge-BasedSignal Understanding Using Parallel Architectures. Department of ComputerScience, Stanford University, Technical Report STAN-CS-86-1136.


Chandrasekaran, B.:1986, Generic Tasks in Knowledge-Based Reasoning: High-LevelBuilding ��Blocks for Expert System Design. IEEE Expert, 1(3):23-30.

Conklin, J. & Begeman, M.:1989, gIBIS: A Tool for all Reasons. Journal of theAmerican Society for Information Science, 40:200-213.

Devanbu, P., Brachman, R. J., Selfridge, P. G., & Ballard, B. W.:1991, LaSSIE: AKnowledge-Based Software Information System. Communications of the ACM,34(5), 34-49.

Graves, H.:1991, Lockheed Environment for Automatic Programming. 6th AnnualKnowledge-Based Software Engineering Conference, Syracuse, NY. Pages 78-89.

Guindon, R.:1990, Knowledge exploited by experts during software system design.International Journal of Man-Machine Studies, 33(3), 279-304.

Guindon, R.:1992, Requirements and design of DesignVision, an object-orientedgraphical interface to an intelligent software design assistant. ACM Proceedings ofCHI'92, Monterrey, CA.

Guindon, R., Krasner, H., & Curtis, B. (Eds.,:1987, Breakdowns And Processes DuringThe Early Activities Of Software Design By Professionals. Ablex Publishing Corp.

Jeffries, R., Turner, A., Polson, P., & Atwood, M. E. (eds.):1981, The processesinvolved in designing software. Hillsdale, N.J.: Erlbaum.

Johnson, W. L. & Feather, M. S.:1991, Using Evolution Transformations toConstruct Specifications. In M. Lowry & R. McCartney (Eds.), AutomatingSoftware Design. Cambridge, MA: AAAI Press.

Lubars, M. D. & Harandi, M. T.:1989, Addressing Software Reuse throughKnowledge-Based Design. In T. J. Biggerstaff & A. J. Perlis (Eds.), SoftwareReusability. New York, New York: ACM Press.

Martin, J. & McClure, C.:1988, Structured Techniques: The Basis for CASE. NewJersey: Prentice Hall.

Neighbors, J.:1984, The DRACO approach to constructing software from reusablecomponents. IEEE Transactions on Software Engineering, 10(9), 564-573.

Nii, H. P., Aiello, N., Bhansali, S., Guindon, R., & Peyton, L.:1991, KnowledgeAssisted Software Engineering (KASE): An introduction and status June 199l.Knowledge Systems Laboratory, Computer Science Department, StanfordUniversity, Technical Report KSL-91-28.

Nii, H. P., Feigenbaum, E. A., Anton, J. J., & Rockmore, A. J.:1982, Signal-to-Symbol Transformation: HASP/SIAP Case Study. AI Magazine, Spring:23-36.

Nii, P.:1989, Blackboard Systems. In A. Barr, P. Cohen, & E. Feigenbaum (Eds.),Handbook of Artificial Intelligence. New York, NY: Addison-Wesley.

Parnas, D. L. & Clements, P. C.:1986, A rational design process: How and why tofake it. IEEE Transactions on Software Engineering, 12, 251-257.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W.:1991, Object-oriented modeling and design. Englewood Cliffs, New Jersey: Prentice Hall.

Swartout, W. & Balzer, R.:1982, On the Inevitable Intertwining of Specification andImplementation. Communications of the ACM, 25(7), 438-440.

Waters, R. C.:1985, The Programmer's Apprentice: A Session with KBEmacs. IEEETransactions on Software Engineering, 11(11), 1296-1320.

kase: an integrated environment for software design

Documents