l O G I C PROGRAMMING AS A SOFTHARE ENGINEERING TOOL

Gregory Lazarev and

Wlnston G. Gresov GHL Associates

Haverford, Pennsyl van1 a

Logic Programming as a Software Engineering Tool

Gregory Lazarev

and

Winston G. Gresov

GHL Aseociates

Logic programming is baaed on the idea that the first-order predicate calculus (in Horn clause form) can be ueed cllgec&&y as a programminq language. PROLOG (PROgramming in LOGicS is the best known example of this kind of language. Virtually unknown in the United States until a few yeare ago, PROLOG has now become one of the mast popular and promising of artificial Intelligence tools. This fact should not be surprising, in view of the very generic nature of logic programming as a tool. Several PROLOG lnt~rpreters (and compilers) provide good performance. A number of comme.rciai applicationo have beerr written in PROLOG, and more ore just a matter of time.

Let's clarify the above statement. Behind ~t ie a quite obvious ldca that our knowledge about the world can be represented as facts ----- e . "Mark la male") and if-then ~ y & g g (e.g. "X is a parent of Y if X is the father or the mother of Y " ) . The foilowlng example, written in PROLOC, illuetratea the principle.

male(mark). maletmike). female(kathy). father(greg, mark). father cgreg, mlirs). mother ( ~ u ~ a n , mark) .

parent(X, Y):- father(X, Y). perent(X, Yj:- mothertx, Yl. Grother-oitX, Y:) : -

male(Xj, psrent(Z, X I , parentlZ, Y > .

The S A X statements on the left are facts (1.e. greg is mark's father). The three on the right are if-then rules. The last one can be interpreted as stating that X ia a brother of Y provided that X is male and that both of them have the same parent. Through facts and rules like these, declarative knowledge about the world can be mapped d i g g c & J y into a programming language.

Given the above program, a very broad range of goals can be set and satisfied. Here are some examples of queries, with machine responses given on the right:

X = mark More (y/n)?

X = mike Nore iy/n)?

X = mark More (yln)?

X = mike Nore (y/n>?

?--parent ( X , kathy) . no

!-brother-ofcmike, mark). Yes

?-brother-oftmark, kathy). Yes

Although it is the declarative nature of PROLOG that is important for us here, a corresponding procedural interpretation is always valid as well. For example, the "brother-of" rule above can be int.erpreted as stating: "To prove that X is the brother of Y, firet verify that X is male, then find a parent of X who can be shown to be a parent of Y also."

A paramount feature of PROLOG is the clear distinction made between logic and control. Ideally, to write a program In PROLOG 1s to supply the body of logical knowledge and to map it into 8

set of facts and rulea. The pattern-directed control mechanism in PROLOG is completely transparent. to the programmer. (Thie is an idealized description; in reality PROLOG has some control predicstes whlch disturb the purity of logic programming.)

Conventional procedural languagea descrlbe "how", In contrast to the "what" described by declarative languages such as PROLOG. Recause every program must contain some knowledge. the PROLOG approach offers enormous advantages in the form of reduction of software development effort becauee of its modularity and em- bedded control mechaniem, 1.e. inference engine.

Let us briefly examine eome PROLOG features: P

- A nonprocedural approach, with a highly nodular and, modifiable etructure;

- Uniform representation of program and data;

- A control mechanism based on unification/reeolution and depth-firat ~ e a r c h with backtracking;

A detailed deecription of PROLOG can be found in 111.

The remainder of this article is divided into three sections. Section 1 diecuaeee the role of logic programming In napprnq a system apeciflcation d&gghg&y into code. Section 2 suggests a posslble approach for building a "generic" software coat esti- mation (SCE) model, and Section 3 reviews the role that logic programming can play in introducing intelligence to the data lnput portion of the SCE model.

1. PROLOG and the System Specification

The soitware liie cycle can be represented ea e aet of major. phaees which follow each other in tine. Ignoring (for simplicity only, the first phase, feasibility analysis, we can start with the plans and requirements phase, also known a s the system specification. Thia phase i e a prerequisite to the design phase, which in turn is prerequisite to the programming phase.

To produce a design from a system specification is generally a lengthy and complex task, closely related to the practise of black magic. The effort devoted to producing the system specifi- cation ia just the beginning: at least equal effort, and often much more, must be expended to produce a viable dealgn. The design, moreover, ia only e precureor to the actual programming.

The concept of "automated programming" was developed to address this situation. In a senee, it represents an effort to produce a black box which would convert a system epecificetion into an ~mplemented program. The reaults of such efforta have so far been rather discouraging.

Why is it t.hat we face such a severe, problem? The primary reason is that'after providing a body of logical knowledge in the form of the system apecification, we attempt to convert this knowledge lnto a ergcedggel fox? through the design and programming processes. And why a procedural form? The only reasonable explanation of which we-are aware is that the tools we have at our disposal, conventional programming languages, are oriented in a procedural rather than e declarative fashion.

Kowalski was the first to suggeet the direct t.ransformat.ion of a system specification into a logic program C21. To accomplish this, the system specification should be represented in some form of logic specification language. DeMarco Structured Analysis is en appropriate example of this [33 .

Let's look at a subset from a case Study In structured annly6isp and indicate how it can be transformed into a corresponding PROLOG program. For those who are interested and have some familiarity with Data Flow Diagrame, the Appendix provides an example with some of the details of this transformation. The example is the "Astro-Pony Toutshope" operation, taken from Chapter 8 of DeHarco l31. It has been simplified by omitting diagrams relat~ng to financ~al processes.

The primary tools of Structured Analysis are:

Data Flow Diagrame

The Data Dictionary

Structured English

,- Data Flow Diagram6 may be viewed a s a network of interactive processes, each of which represents a distlnct loglcal function, and associated data lnputs and outputs, or data flows. The D a t a . Dictionary describes the composltlon of the date flows. The full set of diagram8 is produced by a partitioning procedure, whlch starts from a slngle top level diagram, the Context Diagram. At the lowest level, the unpartitloned processes, or functional primitives, are described in Structured English.

The transformation of a Structured Analysis int.o a PROLOG program iu fairly straightforward. Each Data Flow Diagram and each descriptive atatement in Structured English is repreoented as a PROLOG predicate. Elements of the Data Dictionary become PROLOG variables. In addition, the PROLOG code contains some other constructs related to file manipulation, selection processes, specific control structures, etc.

The most important feature of this mappinq is its one-to-one correepondence between the system specificetion and the resulting PROLOG program. Compare this correspondence with an att.empt to traneform functional requirements into a conventional programming language! All key features of data flow diagrams, such ae top- down design with the capability fur further refinement, are reflected in PROLOG code. Modularity is provided by the fact that functions can be easily iaolated and modified. The data flow diagrams on all levels but the lowest are represented by the decleratlve portion of the PROLOG code. Only on the lowest level, where the functional primitive is expressed throuqh an appropriate Structured English description, is the procedural lnterpretation more appropriate.

Not only are the syst.em ~pecification and PROLOG code corre- sponding t o it functionally the same. but they almoet identical! This similarity suggests that we may be able to automate the conversion procedure. We are thus back t o "auto- mated programming", but can now build on a more solid foundation. This is definitely t.he case for all levels of data flow diagrams above the level of st,ructural primitives. Mapping the functional prlmitlves themselves (i.e. a Structured English description) inro PROLOG code will require much more effort.

The most important advantage of this approach is the replacement of the design and progrsmmlng phase5 with e procees whlch consumes much less time and effort. Thia is the baslc reason why PROLOG is so well suited for fast prototyping. Beyond that, it 1s worth mentioning that we derlve an additional benefit in the form of e convenient tool for dealing with the followlnq difficult problems:

c ~ m p l e t e n e s s of mappinq and the degree of conpletones~;

traceability, or the capability of following requirements through the various levels of the specification;

consistency, both etatic and dynamic.

2 . Building a Generic SCE Model

P With eoftware development assuming an increasingly significant role. effective and reliable eoftware cost estimation becomes. critically important. The ouput of the SCE process la uaually presented in the form of numerical estimates of required effort, expected costs, and efficient echedulea. That ie, the SCE answers questions like: "How much will it cost?", "How long wili it take?", "How many people will we need at each stage of the pro)ect?", "What are the trade-offs?", etc. This output is critically dependent on the nature of the SCE model used, and also on the values assumed for input parametere.1

Proqrese in this area. however, is still very llmited. There are two reasons for thia:

2

- there are only a limited number of models available.

- there are only a limited number of c o m m e r c ~ a l packaqss available which support these models.

The most troublesome i s ~ u e is that af identifying an efficient set of critical input parameters which will be effective a s a basis for estimation. Barry Boehm has categorized those discussed in the literature (about 35 of them) a s follows:

size attributes program sttributes computer attributea personnel att-ributes project attributes

The best known SCE models, such a s Boehm's COCOMO and Putnnm's SLIM, use a large number of critical parameters. For these models, an accurate estimate of the eventual number of source instructions is very important. Becauee of this, they provide good e u t ~ m a t e s for many phase6 of t h e software development pro- cess, but not for the initial conceptual phaae, where en accurate e s t ~ m a t e of source instructions is difficult, if not impossible.

Recent research has proceeded along two parallel but independent lines:

Furt-her refinement. and incorporation of additional detail lnto existing models oriented around the number of source instructions. There are more than 150 different parameters which have been used t o date, and the issue of which of then are the most significant has not yet been fully resolved.

1 Henceforth, the terms "input parameters", "critical parnmstera" and "prolect attributes" will be used interchangeably.

2 See C41, C53 and E 6 3 for a partial list.

Cmnstructlon of alternative models whose o b ~ e c t i v e 1s t o achieve some measure of accuracy of estimetlon during the very early, i.e. conceptual, stages o f the llfe cycle (see for example 1 6 1 ) . Thls 1s done by using a s input paremetere the values of the more tangible "business variablee", such a s lnput/output classes, number and types o f files needed, functions t o be performed, types and categories o f eystems, development and operational environment, etc.. rather than parameters like number of source instructions whlch are completely unknown at this point. Desplte the attractiveness of this approach, its validity a a well as the ~dent.lf~catlon and calibretion of the most important criti- cal parameters remain t o be demonstrated.

We can see. then. that the primary problems lnvolved in trying to formulate a generic SCE model are:

unification of existinq SCE models best adapted for use at dlfierent stagee of the the life cycle. This entails lncorporatlon of enough intelligence t o make choices among alternative estimating algorithms conditional upon the state o f the estimating environment; end

establlshlnq an ob2ective and effective mechanism for ascertaining t h e potential value of en attribute a s a crlticai parameter, end for calibratlng the parameter accurately.

P The fleld of software cost estimation is still deflnltely In an exploratory stage --- a lot more experimentatlon 1s st111 needed. In thls kind o f development envlronment. the conventlonai methodology with lte rlgld skeleton coneistlnq of functlonei specliicatlon followed by deslgn followed by programming simply does not fit. Artiflclerl Intalllgence methods in general 171, and loglc programming in particular seem t o offer promlslng tools t o fill the vacuum.

Buildinq a 9eneric SCE mcrctel using .logic progranminq (PROLOG) a s the primary tool will entail two main tasks:

Specifyinq a set o f distinct prlD~ect attributes. with esti- mated degrees o f unceygg&nty for each:

Formulating a set. of rules by means o f which the SCE outputs will be derived from the values of these pro)ect attributes o r lnput parameters.

In other words, we need t o identify a sot of relevant facts and prescribe a set of rules for using those facts which reflect the appropriate body of logical knowledge, and which explicitly takea lnto account variable levels of combined rule/fact uncertainty. The set of candidate attributes for evaluation ahould be very broad ranging. It should include any characteristic which might convey aigniflcant informetlon value under any likely circum- stances. This would provide maximum leeway for experimentatlon and calibration by the developer, and later by the user.

The specification of uncertainty will provido a basis for dis- crimination. Conditional proceaning mechanism8 would select among alternative algorithms using different subsets of the facts, thus ignoring information whose degree of uncertainty exceeds some threshold value.

Identifyinq a set of potentially valuable p r q e c t attributes will be a lengthy, but relatively straightforward task. Formulating the set of rules will be more difficult, but a s mentioned in Section 1, it ~ h o u l d be done anyway, even for a conventional environment. We may ae well conduct the formulation In an expli- clt, modular fashlon, leaving ourselves almost unlimited leeway for experlmentatlon and tinkering.

What. d c ~ we have now? Believe it or not, we already have our qenerlc SCE model! Because of PROLOG's modularity, once we have introduced the uncertainty factors we wiil be able to:

establish a bridye in our model. among different phases cd the ilfe cycle, because our rules will be corlt.ext- sensitive, and the phase we are In will in part determine the context:

provide very broad capnbilltles to determine the relevance of individual attributes, and t o permlt their celibratlon by the user through the adjustment of appropriate weight factors.

provide a feedback mechanism enabling eelf-calibration on the basis of an evaluation of past performance of the model. This is a much more difficult task, entailing the general concept of "learning by experience".

provide an explanat.i@n facility which would disclose the loglc behind the results produced by the model.

In Sect.lon 1. we suqge~ted that the final program can be imple-

P mented In the form of a logic program rather than a conventional program, and that this can be done directly from the system specificat.ion. wit.h less effort and in a much more natural, fashion. If thie is indeed true, then it opens up entirely new horizons for the SCE. The role of "business" project ettributes for the. SCE at the conceptual stage might be aesumed by pera- meters associated with loglc programming, such as the numbers of rulee and of facts. This could probably be done on e more unifled and logical basis, hopefully with more reliable results. It is very important to ascertain the exact nature of these parameters if we want to have even a rudimentary SCE in an A I software development environment 181 . Noreover, these new para- meters may even fully replace the ones currently used.

.In summary, we believe that. logic proqramminq haa the pot.ent.ia1 to make a significant contributron to the troublesome but impor- tant functlon of oftw ware cost estimation.

3. Intelliqent Data Input Assistance

The issue of quality and inteqrity of data input is one whlch 1s assumlnq increasing importance. In situations where data input, may be erroneous, inconsistent or incomplete, the function of input validation is no less important than the quality of the algorithms which actually process whatever Input 1s provided.

There is ample opport.uniky for fruitful application of A 1 tools to assist In the function of obtaining valid input. The approach that we are pursuing is based upon the notion that an accumu- lation of experience on the part of the system receiving the Input can be utillzed by that system t o review what it is receiving currently. The experience base may be either passive or active: in the former case it is restricted to simply retaining a memory of what it has seen before: in the latter, adjustments are made to that memory to reflect relative degrees of satisfaction with the results of input processed in prevloua situations. Thus far our work has been limited t o the passive case, but we hope t o move on soon t o the active one.

Thls approach provides a good example of "learning by experience", albeit on the input side only, t o which we alluded earlier. Among the capabilities it offers are:

validation of new user-provided information in much the same manner a s 1s currently done by conventional methods:

identification and flagging of instances of user-provlded input whlch are Inconsistent with a standard that is dynamically determined by past experience. The nature of the inconsistencies flagged, aa well a& the threshold deviation for flagging, can be eaally changed without reprogramming:

s u 7 g e ~ t i o n ctf Input for considerntlon by the ueer, based on what has been used frequently in similar prlor sltustlons.

Exactly what constitutes a "slrnilar situation" ie difficult to define in a completely satisfactory fashion, and the value of the fsclllty is effectively determined by the degree of success a c h i e v e d in producing that definition. Given a satisfactory context-apeclflc definition of similarity, nowever, thia frame- work is quite general and can be utilized in many different kinds of applicstlons. We have used it In a package called the GHL Strsteglc Planner 1 9 3 . That system relies strongly upon the quallty and complet-eness of user-provided input, and the input forthcomlnq 1s likely to be-flawed because the user is dealing with projected or even hypothetical events. In such situati0nS. ~rnaglnatiori neceoGarily plays a dumlnant role. While often powerful, however, imagination is not very reliable.

3imilnr characteristics are found in the SCE application, and

P therefore the quality of SCE input parameter values mlght aleo be lmproved by the consideration of previous experience. Clearly, the road 1s open for a variety of fruitful development efforts. .

h e f erences

R. Kowalski. " A 1 and Software Engineering", Qg&gEpglgn, (November, 1984, p. 92).

L.M. Putnam. zys&gm kfhgi~&k~g. t9uantitntivs Software Management, 1980i.

C.E. Walston nnd C.P. Felix, "A Method of krogramminq Measurement and Estimation", Syqtem .JogJng&, (16.1. 1977).

A. Albrecht and J. Gnffney. "Software Function. Source Llnes of Code. and Development Effort Pred~ction: A Software Sclence Validation". ---- IEEE Tranaaa~g" gop Software E i n q ~ n e ~ r ~ n q , (Voi. SE-9, No. 6, November, 1983).

ti. Rubin, "Macro-estimation o f Software Development Para- meters", Prqcgedinga sf SOFTFAIR N 5 3 , (IEEE Computer Sc~cletv Press. 19133).

F. . . Sheil, Power Tonls for Proqrummera", &Jptpm.J&ipg. <February, 1953, p.131).

APPENDIX

Figure I

Figure I1

race-sheet

birth-report

RACE FILE HORSE FILE

Figure I11

race-sheet

HORSE FILE RACE FILE

Figure IV

RACE FILE

matched-race- specific-order

VALIDITY

invoice

Figure V

DETERMINE RACE FILE CLASS OF

invoice

Profile

HORSE FILE

Fl_unctianal Pr imltive Example

FILL ORDER (3.3):

For each arriving order (partially fill,ed order or specific invoice), do ail of the following:

Pull Race Flle folder for the race. Look up Julian day number of Customer-Birth-Date. For each horse in the Race Flle folder:

Calculate the difference In days between Horse-Birth-Date and Customer-Birth-Date.

Express the difference as a positive number. Select horse(s) for which the difference is closest to 23. If more than one horse is selected:

Order the selected horses alphabetically by Horse-Name. Select the last one.

Make u p a prediction card wlth Horse-Name and Horse-Astrol-Sign.

order = Cust-Name-Addr + Customer-Birth-Date + [Race-Specifier].

~ n v o l c e = Invoice# + order + Salesman-ID

profile = invoice + Custom-Prediction

Race-Spec~fier = Race-Date + Track-Name + Race-Number

c:ustom-Prodlction = [Race.-Specifier] + Horse-Name +

Horse-Astrol-Sign + Cust.-Astrol-Sign

Pace File = ( Race-Specifier + Horse-Name 1

Horse File = f Astrological Data about each Animal 1

PPOLDG Code for Upper Levels -.

apt(Order, Profile):- sales(Order, Invoice), astro.logy(Invoice, Profile).

saleslOrder, 1nvolce):- check-valld~ty(Order, XI, belongs-to-order(X, race-specific-order), match-race(X, Matched-race-specificcorder), produce..invoicecMatcheddraceespecificcorder, Invoice).

saleotCIrder, Invoice):- check-validity(Order, X), belongs-to-order(X, general-order), produce_involce(X, Invoice).

astroloqy(Invoice, Profile):- d c t e r m r n e - c l a s s - o f - s e r v i c e , Xi, belongs-to-invoice(X, general-invoice), select-best-race(X, Partially-filled-order), f111-.order(Partially-filLed-ord~er, Profile).

P atsrs3.10gy (Invoice, Profile) : -

determine~class~of~8ervice~Invoice, X), helongs-to-invoice(X, specific-invoice), fill_order(X, Profile.).

add-to-norse-flle(Birth-report):- recard-brrth(B1rth-report, X), assert()O.

add-to-race-f~le(Race~sheet):- enter_ncw- race (Race-sheet, X ) , assertCX).

PROLOG Code for Some FunctLonal Primitives

enter. new--race(Race-.sheet, Out) : - retrieve-horse-,f~le-rec(Race-sheet, X), build-new-recordcRace-sheet, X, Out).

f i 1.1.-order ( X . Profile) : - convert-cust-birth-date(X, C-Jul-day ) , build--horse-listtH-list), build-horse-diffr-list(C-Jul-day, H-list, HD-list), sort--above(HD-list, SHD-list) , seloct~horses~closest~to23~SHDD1iat, 23_list), select-one-horso(23-list, Horse-name, Horse-Aetrol-Sign), finalizs(X, Horse-name, Horse-Astrol-Sign, Profile).