sign in sign up
<<
Home , Prolog, Software maintenance

Downloaded from orbit.dtu.dk on: Oct 05, 2021

SOFTM: a maintenance in

Pau, L.; Negret, J. M.

Published in: Proceedings of the Conference on

Link to article, DOI: 10.1109/ICSM.1988.10181

Publication date: 1988

Document Version Publisher's PDF, also known as Version of record

Link back to DTU Orbit

Citation (APA): Pau, L., & Negret, J. M. (1988). SOFTM: a software maintenance expert system in Prolog. In Proceedings of the Conference on Software Maintenance (pp. 306-311). IEEE. https://doi.org/10.1109/ICSM.1988.10181

General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

 Users may download and print one copy of any publication from the public portal for the purpose of private study or research.  You may not further distribute the material or use it for any profit-making activity or commercial gain  You may freely distribute the URL identifying the publication in the public portal

If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim.

L. Pau J.M. Negret Technical University of Denmark Battelle Memorial Institute Bldg. 348/EMI, DK 2800 Lyngby, Denmark

ABSTRACT: This paper describes a software maintenance - software maintenance personnel selection (SM) knowledge based system ealled SOFTM, serving the - performance goals, and quality control during mainte- three following purposes: (1) assisting a software programmer ance or analyst in his application code maintenFce tasks, (2) gen- - software maintenance work breakdown erating and updating automatically sonware correction docu- - distribution of responsibilities amongst code users, dew- mentation, (3) helping the end user register, and possibly in- loppers, quality assurance, and maintenance terpret, observed errors on the successive application code ver- - audits and user reviews sions. The knowledge based system SOFTM is written in - problem reporting systems PROLOG 11, and is largely applicable to application codes - maintenance logs written in different programming languages, provided code - use of specification formalisms, typically of the SAD1' descriptors can be retrieved. SOFTM does not address any of model the syntactic, input-output, or procedural errors normally de- - use of program design languages tected by the syntactic analyzer, , or by the operating - use of structured techniques to maintain unstructured system environment. SOFTM is relying on a unique ATN code network based code description, on diagnostic proce- - designing in code dure based on context based pattern classification, on main- tenance log report generators, and on interfacing capabilities Amongst the tools in use, or at the research stage, can he of PROLOG I1 to a variety of other languages. mentioned:

- specification and program design languages - software configuration systems - conversion of source code in its structural control-flow graphs (e.g.S3, ADA, Z specification languages) 1. INTRODUCTION - source code controllers, formatters and comparators - declarative constructs 1) The current concern about software maintenance is - paragraph parsers justified by the cost and quality of code repair and up- - cross referencing and linking facilities (mapping) dates, while at least maintaining software reliability - display of data flows and performances. The estimated productivity gains ex- - symbolic pected from software maintenance are, according to Bar- - test data generation ry Boehm, TRW [451 - sequence analysis tools (for synchronization and recoverability) Corrective maintenance: 18%of current effort - interpreters of abnormal endings - coverage analysis Adaptative maintenance: 14% of current effort - diagnostic metarules

Perfective maintenance: 7 % of current effort Many of the above are still at an early stage, thus result- ing in the still overwhelming use of he1.- Update: due to mismatch between user requirements and istics as the software maintenance approach and software specification: 14% of current effort tool.

The major issues in software maintenance and its role in the software production process, are discussed in 2) Some research focusses on knowledge based programm- ing, where code is being written with user driven access [3,8,9,13,14,21,22,24,25,26,27,28,35,43,45,461. The classical approaches followed are: thru an intelligent editor to:

306 CH261S-3/88/oooO/030$01.@IQ 1988 IEEE

Authorized licensed use limited to: Danmarks Tekniske Informationscenter. Downloaded on October 16, 2009 at 09:11 from IEEE Xplore. Restrictions apply. gnowledgeeources TOOlS This obeys the diagnostic strategies described in 1291 Data flow models and Data flow design and using context based pattern classification. This is descriptors Transform aids essentially a process where root Design rules Transaction analysis error ceusdcorrection goals are found from their Data dictionary Procedural templates consequences and partially known attributes C501. Abstract procedures Design codes Common data structures The of SOFTM is divided into three Structured programming rules parts: Common KB-1: Facts in predicate form, about error types, error Examples of such related CASE projects are (non ex- localizations, diagnostic classes, the environment, haustively): Tediummedious Enterprises, Pro- and observables. Observable8 are passive if measured grammers ApprenticeJMIT, USE-IT/Higher order Soft- without modifying code execution, and active if ware, RlOOOAXational, REFINWReasoning systems, external perturbations are necessary. Knowledge-based software assistant (KBSA)/Kestrel In- KB-2 Code independent kernel rules, applying to the stitute, Intelligent program editor/Advanced Informa- general software maintenance task. tion and decision systems, POISE Interactive pro- KB-S: ,Symbolic descriptors of (L), derived by gramming environment/Univ. of Massachusetts, IN- rewriting in predicate form C(L) features provided by FORM/Univ. Stuttgart [ll, KBPAlEsprit 121 and also in the compiler, the specification language, or the data AI related CASE research 13,6,13,15.16,21,24,40,43,44, flow model, in an augmented transition network 45,473. (ATN) form. Research has been reported on experthowledge based All three part are assigned to different sub-worlds in debugging: Message trace analyzer - Source code debug- germniv. Waterloo [4l,SPEAWDigital Eqipment [5l,FA- Prolog, for separation and decomposition; they are edited each by knowledge base editor specific to each of the LOSYNniv. Minnesota [7l,SOFTM/ Technical Univ. a three parts. The knowledge base KB-3 is interfaced to Denmark & Battelle C301, besides [6,8,13,15,19,36,37,41, other tools as indicated. 47,481. Regarding and queries, the access is as fol- lows: However, little work has dealt so far with knowledge ba- sed software maintenance, incorporating some of the re- the code developper, can query and update KB-1 alone, levant approaches and tools mentioned above in 1): see - [10,11,17,20,21,30,421.It is the purpose of this paper to de- and update C(L) thru the editor of that L language; he scribe the structure of a software maintenance expert can also execute C(L) the code user, can query and run C(L) system SOFI'M, written in Prolog I1 1493 , and operating - KB-1 the code maintenance programmer, can query and up- on the source code of a diversity of programming langu- - ages. date KB-1, query KB-3, and update KB- 2.

1) On a specific piece of application code C(L), written in a L for which there is an 3. APPLICATION DEPENDENT CODE KNOWLEDGE RE- interpretor, compiler, linker, and editor, the actual PRESENTATION knowledge based software maintenance system SOFTM The code representation is treated as fact predicates in a speci- carries out essentially error diagnosis and provides for fic knowledge base world. It consists the propagation of corrective changes (see Figure 2): of: a) code structure: it describes the information flows between 1. detection of errors: except : a) syntactic errors code modules and arguments, stressing the call order detected by the compiler during execution. The representation is an augmented ) cross-referencing errors transition network (ATN) with attributes, written in pre- c) calculation errors due to a wrong dicate . The node labels are provided by the linker, d) search, query or IO errors due to a wrong algorithm and the attributes by a standard run of the code (altemati- vely by a Petri-net based simulator). 2. location of errors, except 1) a,b,c,d b) module structure: each module of the application code is 3. error diagnosis represented by a frame, attached to the corresponding ATN node. The frame fields are: pointers to U0 argu- 4. maintenance guidance for C(L) ments, pointers to internal arguments, ordered textual description of the functional purpose of each successive 5. generation of explanation facilities for 1.-4. block in the module (as specified e.g. in structured or ). These frame fields are provi- 6. automatic generation of code maintenance logs, to be ded by the linker or compiler, and by the module docu- incorporated into the C(L) code documentation. mentation located in "Comments".

307

Authorized licensed use limited to: Danmarks Tekniske Informationscenter. Downloaded on October 16, 2009 at 09:11 from IEEE Xplore. Restrictions apply. 4. KNOWLEDGE REPRESENTATION OF APPLICATION Y): observables about the errors, yielding the values of qdj- CODE CIL) (gB3) tativdcontinuous measurements on the application code, The relations between modules of C(L) are described by once instantiated; an ATN with the following fact descriptions of each rela- L): physical or virtual error locations; tion in Prolog syntax: E): generic error type or descriptor, such as erroi; undefined arguments, etc. mm(ml,m2,L,p)-->; . C): diagnostic causes (from the domains: design, execution, environment, human errors); where: ml : is the module name being called M): generic or specific SM actions affecting:application code from m2 programming, application code design, software envi *- m2 : is the module name calling ml, with onment, human factors. retum to m2 .t : list of call sequence numbers in call 6. KNOWLEDGE REPRESENTATION FOR THE DOMAIIq chronology, terminated by nil I”DENTFAC’I-BASES (EB- 1) p : name of code or root module The facts in K33-1 are described by the following Prolcg The relations between arguments (compiled by the inter- data structures: preter or ) and a module, are described by the 1. Observables: passive( Y-P)or active Cy-A) facts: < observable - (type) - p/a, (number of observable), (timi!- stamp), nil, (sentence defining observable). (measuru- am (a,m,line,p)-->; ment location). (value of observable) . nil > -->;

where: a : is an (YO)argument of module m 2. Location IL) m : module name < location, (number), (time-stamp), nil, (sentence d 2- line: relative address of argument a, or fining locations) . (error number) . nil > -+; pointer p : name of code, or root module 3. En” < error, (number), (time-stamp), (likelihood), (error de- scription sentence) . nil > -->; Each code module is represented by the Prolog frame structure: 4. Diagnosis (C) < caase, (number), (time-stamp), (likelihood), (cause md (m, 41,L2, b,p) --> name sentence) . (error number) . (cause name sent- ence) . (error number) ... nil > -+; where: m : module name L1 : list of YO arguments to m represented DlaintenanceN by relative address pointers in 6. < correction, (number), (time-stamp), (likelihood of c f- list form, terminated by nil fect), (sentence describing correction) . nil > -+; 22 : list of internal arguments in m, which are not in 1 L 6. Documentation 0) b : pointers to relative address of first line < documentation, (number), (time-stamp), nil, (tiile in each functional block of m, in list sentence) . (location number) . nil >-->; form, ended with nil p : name of code or root module 7.l”cEpRocEDuREs md may be represented also with explicit arguments They consist of (see Figure 2): names, while preserving the same frame structure a) control structure: it is the Prolog I1 depth first backtrack- From the above knowledge descriptions of C(L) it is ob- ing with top-to-bottom and left-to-right clause deletian, vious to estimate the number of steps and processes invol- supplemented by verification and domain dependent pve- ved in the code, and to sort them by size. dicates; these predicates are supplemented by contc xt sensitive control predicates such as diffx,y) and C(L) can also preserve the timelstate dependent informa- freeze(x,p), which implement truth maintenance a id tion necessary to determine what activities are possible conditional propagation [491 in a dynamic environment; in this case, the arguments about time and state are tagged separately for data flow or b) explicit inference procedures: they include both a for- I/O control. ward and backward chaining, with an observatiodgc a1 restriction phase followed by pattem matching on the scts 5. APPLICATION CODE INDEPENDENT KNOWLEDGE of rules in (e) below, and then by action clauses. The tic- BASE tion clauses consist in addinddeleting facts with likc li- hoods, and by automatically logging them in the SM do- This knowledge baselworld, which is application code inde- cumentation file; pendent, contains in predicate form, according to the diag- nostic strategy of [291:

308

Authorized licensed use limited to: Danmarks Tekniske Informationscenter. Downloaded on October 16, 2009 at 09:11 from IEEE Xplore. Restrictions apply. c) domain dependent inference rules: this rule base con- 9. KNOWLEDGE EXIEMSIONS tains in predicate form, with a list syntax: The basic information has been collected, although not yet im- 1. detection rules: Y -> E plemented, to enhance the application independent knowledge 2. localization rules: E -> L basis (KB-2) with respect to: 3. diagnostic rules: ExLxY -> C 4. maintenance rules: ExLxYxC -> M with SM error - metarules for identifying modules or module to module documentation update relations with similar structures 5. incorrectness and insufficiency metarules operating - measuring debuggindmaintenance stress, to estimate on the ATN likelihoods for detection or corrective actions 6. sequencing constraint control metarules, to check call - generate and place scope markers to delineate code gov- sequences and propagate effects of corrections emed by conditional expressiona accordingly - protect from any corrective measure the YO arguments 7. rule cluster documentation generators for functional - introduce simple attribqtes to compare code blocks old from revised code - generate from the call sequences a maintenance plan d) uncertainty representation, by attaching likelihoods to which obeys module interaction each error (E), cause (C) or correction (M) fact, the likeli- - inclusion of simple alternate program verification tech- hoods are propagated and combined along each inference niques likely to appear in certification path into an importance qualifier for each hypothesis or standards. goal

The combination of a) b) and c) allows for the automatic propa- gation of maintenance changes, by asserting into &e fact base REFERwcEs KB-3 these changes. If new types of errors or locations or cor- G. Fischer, H.D. Boecker, rections are entered into KB-1 through proper editors, they the The nature of design processes and how computer are automatically accounted for thanks to the Prolog declar- systems can support them, in P. Degano, E. Sandewall ative form. Thus the inference procedure in SOFTM uses fully propagation mechanisms and analysis. (Ed), "Intgegrated interactive systems", North Holland, 1983, 73-86 (INFORM system, Univers- ity of Stuttgart) K. Poulter, Representing programming knowledge in 8. ENVIRONMENTAND IMPLEMENTATION the KBPA, in G.J.P. Katz (Ed), "ESPRIT'85: Proc. of The SOFTM knowledge based software maintenance envir- the meeting", North Holland, 1986 (KBPA Franz- onment in Prolog I1 [491 has been supplemented, besides the in- Lisplc prototype) terfaces to the , compiler, and higher level K.A. Frenkel, Toward automating the software deve- utilities (specification language output, simulator input), by: lopment cycle, Comm. ACM, Vol28, no 6, jun 1985,578- 89 - SM documentation explanation facilities N.K. Gupta, R.E. Seviora, An expert system approach to - fact, rule, code structure editors (specialized) real time system debugging, Proc. 1st IEEE Conf. on AI - knowledge base management commands applications, 1984, p. 336 (Message Trace analyzer in - query editor for forward chaining (diagnose an error) Prolog, Univ. Waterloo) - backward chaining editor (reason to possible candidate- SPEAR, Expert systems J., Vol 1, no 2, October 1984, p 98 correctionderrors) (SPEAR computer error log analyzer at Digital equip- - likelihood calculations ment) - time-stamp management on all SM actions M. Schindler, AI begins to pay off with expert systems - debugger for engineering, Electronic Design Magazine, Aug. 9, - interface between Prolog I1 and constants, variables, 1984,106146 lists in different languages (PASCAL, COBOL, FOR- R.L. Sedlmeyer, W.B. Thomson, P.E. Johnson, Diag- TRAN, ADA) nostic reasoning in software fault localization, Proc. - optional interface to a text management system IJCAI-83, Karlsruhe 1983, Vol 1,29-31 (FALOSY master containing the full (e.g. BASIS) file update software fault finding, Univ. Minnesota) H.J. Hindin, Intelligent tools automate high-level lan- guage programming, Computer Design Magazine, May The current implementation is on VAXNMS for application l5,1986,46-56 code written in either COBOL, or ADA, and Prolog D. Gustafson, A. Melton, A model for software main- itself. Specialized application code languages are also consi- tenance, Proc. IEEWACM Conf. on software mainten- dered, e.g. image processing language, test language, and ex- ance (CSM.87). Austin, TX,Sept. 1987 pert systems [391. B. Terry, R.D. Cameron, Software maintenance using meta-programming, same ref. as [9] F. Cross, An expert system approach to a program' s in- formatiodmaintenance system, same ref. as [91 D. Richard Kuhn. A source code for maintenance. same ref. as [91

309

Authorized licensed use limited to: Danmarks Tekniske Informationscenter. Downloaded on October 16, 2009 at 09:11 from IEEE Xplore. Restrictions apply. 1131 R.L. Baber. The Spine of software: designing provably 1391 L.F. Pau, Prototyping, validation and maintenance of correct software, Wiley, 1988 knowledge based systems software, hoc. IEEE 3ri [14l M.W. Evans, J. Marciniak, assurance Conf. on expert systems in government, Washingtoll and management, Wiley, 1987 DC, Oct. 1987 [15l C. Rich, R.C. Waters (Ed), Readings in AI and soft- r4a D. Partridge, AI: applications in the future of software ware engineering, Morgan Kaufman Publ., 1986 engineering, Elis HorwoodlWiley, 1986 Cl61 B. Liskov, J.Guttag, Abstraction and specification in 1411 Proc. ACM Symp. for high levtd program development, MIT Press, Cambridge (MA), debugging, SIGPLAN Notices Vol 18, no 8, Aug. 1983, 1986 ACM Order 593830 [lfl L.B. Alperin, B.I. Kedzierski, AI based software main- C.A. Dyer, Expert systems in software maintainabilit:r, tenance, Proc. 3rd IEEE Conf. on AI applications, Or- Proc. 1984 Annual reliability and maintainability lando (FL), Feb. 1987 s~P.,IEEE publ. 0149-144 xEB4,295-2!39 1181 Proc. conf. on reliability and robutsness of engineering r431 M. Schindler, Through automation, software shapes it- software,Computational Mechanics Institute, Como (Ita- self to the task at hand, Electronic Design, July 25,198!i, ly), Sept. 1987 87- [19] M.A. Ould, C. Unwin, Testing in software mainten- 1441 H. Abelson, G. Sussman, The structure and interpretat- ance development, Cambridge Univ. Press, 1986 tion of computer programs: a LISP perspective, MIF 1201 S.S. Yau, S.S. Liu, A knowledge based software main- press, 1985 tenance environment, Proc. IEEE COMSAC'86, IEEE A.J. Rockmore, Knowledge based soRware tums spe:- Computer Society, Chicago, 6-10 Oct. 1986 ifications into efficient programs, Electronic Design, El] D.A. Higgins, Data structured software maintenance, July 25,1985,105 - 112 Dorset House Publ.iWiley, 1987 S. Bendifallah, W. Scacchi, Understanding softwa -e [22] J. Mastow, Toward better models of the design process, maintenance work, IEEE Trans. - AI Magazine, Spring 1985 ing, Vol SE-13,no 1, Jan 1987 [233 GL.B. Kotik. A.. Rockmore, D.R. Smith, Use of RE- 14n H. Wertz, Automatic correction and improvement >f FINE for knowledge based , Proc. programs, Ellis Horwood/Wiley, 1986 4 th Int. Workshop on software specification and de- 1481 J. Loecky, K Sieber, The foundations of prowam ver- sign, IEEE Catalog TH 0181-8, April 1987 ification, Wiley-Teubner, 1987 [25l M. Lubars, M.T. Harandi, Intelligent support for soft- 1491 F. Giannesini, H. Kanoui , R. Pasero, M. van Ca- ware specification and design, IEEE Expert, Vol 1, no 4, neghem, PROLOG, Addison Wesley, 1987. winter 1986,3341 m1 L.F. Pau, A survey of expert systems for failure diagn- Ea I. Sommerville, Software engineering, Addison Wes- osis and maintenance, Expert Systems J., April 1986 ley, 1985 127J NTIS, Annotated bibliography on software mainten- ance, Superintendent of documents, Washington DC, S/N 003-003-02756-1,1986 1281 Software maintenance, IEEE Computer society Press, Cat. 0-8186-0002-0. EH-02014,1983 1291 L.F. Pau, Failure diagnosis and performance monitor- ing, Marcel Deker, N.Y., 1981 [301 L.F. Pau, J.M. Negret, SOFTM: a software mainten- ance expert system, Battelle Memorial Institute, Gene- va, 1985 E311 T.S. Chow, Testing method by finite state machine, IEEE Transactions on software engin- eering, May 1979 1321 R.L. Glass, Software reliability guidebook, Prentice Hall, 1979 1331 J.E. Hopcroft, J.D. Ullman, Introduction to , languages and computation, Addison Wesley, 1979 1341 P.P. Howley, A comprehensive software testing metho- dology, Second software engineering standards appli- cation Workshop, SanFrancisco, May 1983 1353 Standard for software test documentation, ANSYIEEE std 829,1983 1361 J.M. Morin, J. Perez, S. Xanthakis, MBthodes de mod- Blisation pour la g6nBration de tests de recette, Institute genie logiciel, T/0052/DI", 1985 O7l G.J. Myers, The art of software testing, John Wiley and sons, New York, 1979 1381 P. Zave, A comprehensive approach to requirement pro- blem, Proceedings of COMPSAC, 1979

310

Authorized licensed use limited to: Danmarks Tekniske Informationscenter. Downloaded on October 16, 2009 at 09:11 from IEEE Xplore. Restrictions apply. Figurel: SofcwareengineeringCASEcycle

SOFTM

I r- I t t Diagnose representa- tion of lcodeATNapplication 1 gh

module ------I Propose maintenance actlons

corrective actions

Figure 2 sominference functions

31 1

Authorized licensed use limited to: Danmarks Tekniske Informationscenter. Downloaded on October 16, 2009 at 09:11 from IEEE Xplore. Restrictions apply.