abstract - wit press · to be reused without re-test and, as intellectual effort required to test a...

A survey of classification schemes for

improving software quality and an outline

for their future

P. HadAeld & S. Hope

gc^oo/ o/ EWromc Engmeerwg 0 Compeer

University of Wales, Bangor, Gwynedd, UK

ABSTRACT

In recent years there has been a move towards the reuse of existingsoftware in new applications. This increases the speed with which a system canbe assembled, whilst improving the quality by using pre-tested components.Several schemes have been proposed for cataloguing and classifying fragmentsof code in order to promote reuse. Whilst these schemes are useful, it is knownthat the distribution of time in a project is approximately one half planning, onesixth coding and one third testing. This being the case, more attention needs tobe paid to the reuse of design information, documentation and test data. Thedesign information is important because it gives a better insight into the designphilosophy, strengths and weaknesses of the code than that which can beinferred from its specification. This paper discusses these issues and how adifferent design emphasis can lead to a substantially different performance whichthe code fragment documentation is unlikely to reflect.

The paper explores the reasons for recording test data and differentstrategies are investigated. The varying degrees of test coverage required forinitial development and for reuse are also discussed. A piece of code is unlikelyto be reused without re-test and, as intellectual effort required to test a piece ofsoftware is roughly equal to the effort required to produce it, the availability ofthe original test set, or a pertinent subset of it, is a great advantage.

Finally the paper concentrates on the documentation of test strategiesand their inclusion within a classification scheme. In conclusion, developments

Transactions on Information and Communications Technologies vol 4, © 1993 WIT Press, www.witpress.com, ISSN 1743-3517

614 Software Quality Management

in this area are discussed which investigate the ability to write a new piece ofsoftware and adapt or reuse an existing test strategy.

SOFTWARE REUSE

The idea of software reuse is not new. Everyone reuses pieces of codeall the time, even if what their reusing are only the standard library functions.More usually programmers turn to a stock of useful routines accumulated overthe years.

The advantages in reusing code are easy to see. If we take the exampleof a search algorithm most people could write one in a few days. It is very likelythat a better routine has already been written, tested, documented and used. Ifwe can find it and adapt it to our needs not only will this be quick but theperformance and reliability should also be improved.

The problems start when we try to extend reuse to other peoples code.We must establish that function that we require exists, how to use it, what itdoes, what parameters it takes and returns, how to test it, it's efficiency, etc. Weneed all of this information and probably some examples or experimentation inorder to reuse the code. In reusing software, most of the problems weexperience are associated with interfacing the reuse candidate with the piece weare writing. This consists of matching the data required and returned to thefunctions available and controlling its scope and visibility. Any ancillary codethat was required must also be identified and incorporated. If the code had ahigh degree of interaction with its surroundings then it becomes more difficultto incorporate it in a new system or to modify it in an old one.

SOFTWARE REUSE REQUIREMENTS

Many of the objections to reuse of software are associated with a lack ofinformation about, or mistrust of, the items presented for consideration. Codefragment reuse suffers from a reputation for poor documentation, bad designand poor programming practice. The argument is often proposed that it'squicker to write it yourself and be sure that it's right than to reuse someoneelse's code and have to fix it later. Without an efficient retrieval system it takestoo long to find a suitable candidate for reuse, programmers tend to assert "Icould have written it myself in the time it took to find it". Other argumentsinclude the classic "not written here". The level of prestige associated withrewriting someone else's code is less than that obtained by writing it yourself.Finally, if you write the whole of an application in house there are no possibleproblems with copyright, royalties, maintenance or support.

What we need is a methodology that allows us to easily reuse the code,its documentation and its test data. This work has already been performed bythe programmer and would usually be lost, particularly where the fragment has


Software Quality Management 615

been scavenged from an existing application. We require a scheme that allowsus to bind this information with the source code.

Given that we have chosen a policy of reusing software, the firstproblem is finding a suitable candidate. In order for the strategy of code reuse tobe effective there must be a sufficiently large body of code available for reuse.Once this body has been amassed the problem of locating a suitable componentarises, this necessitates a classification scheme of some sort.

CLASSIFICATION THEORY

For code reuse to be attractive, the overall effort to reuse the code mustbe less than the effort to create new code. Code reuse involves three steps[PRIET87], finding the code, understanding it and adapting it.

The amount of code available to be reused is large so the problem offinding the most suitable piece of code is paramount. Several schemes have beenproposed, these generally consist of some form of structured catalogue with aquery and retrieval system.

The basic catalogue is usually a variant on one of two schemes. It iseither based on a hierarchy or a list of keywords. In the hierarchical system,fragments are assigned to a position in the catalogue that best reflects their mostsignificant aspect. In the keyword system, keywords are assigned to all relevantaspects of the code.

Classification is a grouping of like things together. All members of agroup produced by classification share at least one characteristic that membersof other classes do not. An object may be defined by which class it fits in andhow it differs from the other members of the class. A classification scheme is atool used to produce order based on a controlled and structured indexvocabulary. This index is called the classification schedule. It consists of namesor symbols representing concepts or classes, listed syntactically, to displayrelationships between classes [BUCHA79].

There are two kinds of relationship a classification scheme must express,hierarchical and syntactical. Hierarchical relationships are biased on the principleof subordination or inclusion, while syntactic ones are those created to relatetwo or more concepts belonging to different hierarchies. In a hierarchicalclassification scheme, syntactical relationships are represented as compoundclasses. This process is similar to the generation of compound classes, in objectoriented software, by the use of multiple inheritance.

Classification schemes can be arranged in one of two ways,enumerativey or faceted.



Enumerated classificationIn this method the subject area is divided into successively narrower

classes that include all possible base and compound classes. These are thenarranged to display their hierarchical relationships.

It should be noted that the best arrangement of classes in a hierarchy isentirely dependent on the classifiers' perspective on the problem. Examples ofhierarchical classification used to depict the concept in explanations tend to usereal world entities for which an accepted hierarchy exists. The existence of otherhierarchies which would be more valid in other circumstances is overlooked.

The problems of classification with inappropriate hierarchies applyparticularly to software. Booch [BOOCH88] noted that for any design there aremany valid hierarchies and, although some of these provide better solutions tothe design problem than others, there are still several acceptable ones to choosefrom.

If the number of available branches at each level in the hierarchy islimited (as it is in the Dewey Decimal System) then it is vitally important thatthese are chosen to cover all possible needs. Change to the hierarchy generallyrequires reclassifying all items below the node which is changed.

There are several hierarchical classification schemes in existence, mostare broadly similar to [BURTO87]. None of the systems are purely hierarchical inoperation, most having the addition of keywords as a supplemental referencesystem.

The system devised by Burton is a flat hierarchical classification systemwith the addition of keywords. It is intended for the classification of new code,the code is written specifically with the intention of reuse and can be written toconform to the requirements of the system. Code is designed within thedevelopment section of the system, allowing the system to provide guidance forconformity.

In operation, the development team found that it was necessary to splitthe code database into project specific sections to improve system speed andretrieval accuracy. This tends to imply that the classification scheme or theretrieval system was a poor one. One of the basic requirements is that any reusescheme is that it is all encompassing. If several catalogues have to be used,unless their content is very tightly controlled and easily understood, the user isfaced with the task of searching several catalogues every time.

Faceted classificationThe faceted method relies, not on the breakdown of the subject area but,

on synthesis of a class by assessment of the facets which it possesses. Items inthe subject area are decomposed into their component elemental (base) classes.



These classes are listed in (and form) the classification schedule. Only thegeneric relationships are displayed. When a compound class is required it issynthesised by combining base classes.

The arranged groups of elemental classes that make up the scheme arethe facets. The elements that make up a facet are called terms. Systematic orderin a faceted scheme consists of ranking the facets by citation order according totheir relevance to users of the collection. Terms within facets are ordered bytheir relationship to each other (their conceptual closeness).

When classifying in a faceted scheme, the most significant term in theclassification description is a term selected from the facet most relevant to the

user.

The use of this type of scheme, for the classification of software, waspioneered by Prieto-Diaz [PRIET87]. His premise is that if the collection isorganised by attributes that define the software requirements, possibility ofretrieving non relevant components is reduced.

The scheme uses a component description format based on a standardvocabulary of terms. It imposes a citation order on the facets and provides ametric for the conceptual distances between terms in each facet.

In real design situations there are usually many alternatives. Severalcomponent combinations may give feasible results, the problem becomes one ofselection. Design constraints can sometimes be modified in the light of availablecomponents. Design implementation becomes a selection problem in whichcomponents are usually acquired rather than created and are usually describedby standard attributes that capture their functional characteristics. This is truefor software reuse as practised in software factories.

The proposed model is based on these observations and on theassumption that available components do not match the requirements perfectly,making adaptation the rule rather than the exception.

The system is intended to provide an environment which helps locate thecomponent, estimates the adaptation and conversion effort based on anevaluation of their suitability for reuse.

The selection process is:• the functional specification is given,• the library is searched to find candidates that match the specification,• if an exact match is found the search ends,• if several similar, non matching components are found then selection is

achieved by ranking available candidates based on how well they matchthe requirements and, on the effort required to adapt the non matching



specifications. Ranking is done by ordering the specifications byrelevance. Once the ordered list is available, user selects the easiest toreuse and adapts it.

Selecting similar components is a classification problem. The degree ofsimilarity depends on how the collection is organised. Groups are formed bythe selection of closely related components, which can be determined by theevaluation of relevant attributes, and organising in a meaningful manner.

COMPONENT TRANSFER BETWEEN DIFFERING SYSTEMS

The grouping of components, as described by the classification scheme,assists the transfer of software between different applications. Code which isadapted to a classification system by improving its classification potential can bemoved between different classification systems more easily than code whicheither has not previously been classified.

Classification potential is improved by all steps that increase the qualityof the following:

• code documentation,• improving the degree of encapsulation of the component,• by the addition of facets or keywords, or a reference to a place in an

ordered hierarchy,• access to the information (retrieval system).

RETRIEVAL SYSTEMS

In any catalogue it is the component retrieval system which will receivethe most use. The system must be geared to making this easy to use, quick,reliable, etc., almost regardless of any penalties which this imposes on either the(classification) system design or the process of cataloguing components.

From a survey of retrieval systems the following features appear to bedesirable:

• the system should be available at all times,• the retrieval process should be iterative, a user may start with a broad

description of his requirements and refine it in the light of the results of asearch,

• the retrieval system must allow for similar specifications rather thanlooking for exact matches,

• components returned for examination should have some form of rankingwhich reflects their degree of closeness. This allows the user to examine



the most suitable component first, reducing the time required for

assessment,

The weighting used for the ranking should be either set by the user, orpossibly by the system after an assessment of the components previouslyretrieved from the system. For example a novice user might wish to alter theweighting to promote components which have good documentation. Based onan analysis of the users previously retrieved components, the system would notethat the user generally chose components with a good documentation metric.The system would then learn to promote these for that user in future.

The following features are not desirable (note; features that are merely adirect opposite of those stated as advantages have been omitted)

• systems which are slow,• systems which are not user friendly, do not provide guidance, or which

require a precise specification or language,• systems which are idiosyncratic,

Retrieval systems have evolved reflecting the available technology. Themajority of systems use ad-hock retrieval. This consists of a loose collection of"handy bits of code" collected by individual programmers, initially documentedonly as a listing. As software engineering developed, the book became theclassical method of documenting software modules. Virtually all collections ofsoftware available to date have been implemented as a combination of a binaryfile containing the functions and a book containing the documentation. As thetechnology evolved, components and documentation were stored on-line.Retrieval progressed to menu driven access, with documentation stored in textfiles on a computer along side the source code. Further development, and theintroduction of graphical user interface (GUI) systems, has allowed theincorporation of hypertext cross-reference, multiple windows, comparators,thesaurus, revision control, hierarchy trees, cut and paste examples, etc. Theseenvironments also support interface to CASE tools and programmingenvironments.

The design of the retrieval system is influenced by the type of reuserequired. Broadly, this can be defined as dynamic or static reuse.

DYNAMIC AND STATIC REUSE SYSTEMS

Software reuse systems may be termed either static or dynamic. Staticreuse systems have a narrow application domain, a relatively small number offunctions (tens to a few hundred) and a static content. The retrieval system canbe simple, the code can be harmonious (similar functions performed in similarways) and that time spent manually classifying functions and cross-referencing



documentation is not immediately wasted by changes or additions. This form orreuse is best exemplified by the proliferation of area specific libraries. The levelof testing is generally very high. The large number of people using a smallnumber of functions ensures that any bugs are found. Examples of a function'scorrect use are abundant.

Dynamic reuse systems allow the classification and retrieval of anunknown, increasing and changing body of software. The classification schememust cover a wide area of application, it must be extendible and previousclassifications must not be rendered invalid by extensions to the classificationscheme or by the inclusion of new modules. In order to ensure that the schemeremains up to data it must be easy to add to, and errors in the addition must notbe catastrophic. As the area of application is wider and the body of codegreater, than that found in static reuse schemes, the retrieval system must befaster, more precise and offer more help in selecting components. Componentsare less likely to be harmonious unless either strict programming metrics areinstituted or code is cleaned up before addition to the scheme.

Software metrics are measures of a given property of the code. The useof metrics allows some impression of the code to be assessed without the needto examine it. In the case of metrics such as algorithm efficiency this may save agreat deal of effort. If this information is included with the component, then itcan be retrieved and used to rank the component. This ranking can be used toreduce the time that a user must spend examining potential components. This,however, introduces development overheads.

REUSE COST BURDEN (OVERHEAD)

It has been noted that code intended for reuse costs significantly more todevelop than "one off code. This is because the interface to the code fragmentmust be more tightly specified, the code must be better encapsulated and it musthave a wide area of applicability. In addition to this the code must bedocumented and tested to a higher level than if it was for one off use (becausethe likelihood of misuse is higher). It is possible that it may be used in a contextwhich was never envisaged when it was written. In addition work must beperformed to make it conform to the classification system, metrics must beassessed, the item must be placed in its correct category and appropriatekeywords must be assigned.

There are several advantages to the insistence that code is written to bereusable at the start of the project, rather than retrofitted-fitted for reuse later. Ifthe module is fully tested at the time that it is written then there is less work tobe performed later, the testing phase has been moved forward in thedevelopment cycle. Errors are found earlier, the scenario where the first modulehas a bug in it, which is exploited a second module and then the bug is fixed in



the first module leading to the second one no longer working, is less likely tooccur. Most of the work needed to document and test the module would haveto have been done later anyway.

The manner in which components are reused also affects the overheads.This is described in the next section.

TWO SORTS OF REUSE, AS IS AND MODIFIED

Components are reused in two ways, in their original form or aftermodification.

"As is" reuse takes place when the component found in the collectionmatches the requirements and may be reused without modification. This is quickand easy, it requires no change to the test set or documentation and noamendments or additions to the catalogue.

Modified reuse takes place when a component performs a similarfunction to the one required, but is not an exact match. In this case thecomponent must undergo further development until it matches the specification.Documentation must be amended accordingly and the test set modified or a newone devised. Once this is complete a decision must be made as to whether thenew piece of code supersedes the original or should be added to the collectionas a new piece of code. Some scenarios are:

• The code is functionally identical. This may occur if, for example, thefunction had been re-implemented using a faster algorithm. The newcode then supersedes the original, it may replace it in the collection.Note a flag should be set to allow all code using it to be rebuilt,

• The code now has new functions whilst maintaining those which it had.The new code can supersede the original (replacing it in the collection) ifexisting applications using it would not notice,

• The code performs a new function. This is a new piece of code. If it is ofany use it should be added to the collection. Is it stand alone, inheritedfrom the original or what? If the original is modified should this one bere-assessed?

FACTORS AFFECTING REUSE

The aim of the software catalogue is to allow the user to program in ahigh level language and, given that we accept that this language cannot beproduced in its entirety and then remain static, we must have the facility to bothchange the library content and assess which parts of the library requirereplacement or improvement. With improvements in technique or changingrequirements it is likely that old components can be replaced with more effectiveones.



In order to optimise the amount of effort expended in upgrading oldcomponents we need some method of assessing quality and usage. If statisticsare maintained the information is then available to assist in decisions aboutlibrary content. Information would include the frequency with which thecomponent is reused, its level of functionality and efficiency, its averageproportion of final system runtime, the level, quality, time required for, and easeof use of, the current test strategy, the components scope for reuse (over howlarge an application area is it useful), functional additions which will increase thescope for reuse,

These factors can be assessed by reference to the component metrics,the reuse system statistics and the notes made by the original writer ordevelopment team. Given a suitable weighting scheme the various aspects couldbe combined to give a "rework potential" metric.

Every piece of code is a compromise. At the initial development stage,the compromise is usually weighted towards reliably achieving the level offunctionality required for the task in hand. If the compromises, restrictions andunimplemented features are documented within the source code, they provide aguide to the areas where improvements can be made, in future, if the level ofuse justifies the development.

Various factors affect whether a piece of code will be reused:

• Can it be found?• Having found it can you understand it? Complex algorithms, loads of

pointers, poor layout and sparse documentation all put people off.• If you decide to use it can you test it. Was it tested when it was written,

what were the priorities when it was tested? Have you got the test set?• How efficient is the code, what algorithm is used, what are its

limitations, are there any known bugs, etc.

According to Prieto-Diaz [Priet87] code attributes that promote easyreuse are small size, simple architecture, excellent documentation and the sameprogramming language,

The references to small size and simple architecture apply toconventional code. If we consider object oriented (OO) code then these wouldprobably be better expressed as a compact interface and a high degree ofabstraction. The difference is due to the method of reuse. In OO programmingattributes are inherited or overloaded. With procedural code it is usual tomodify the original source code. The difference is, therefore, that the internalstructure of the procedural code must be understandable and modifiable. In thecase of the OO code it is only necessary to understand its interface.



IMPORTANCE OF DOCUMENTATION AND TEST REUSE

As Brooks stated [BROOK75] only one sixth of the time spent producinga piece of software is spent in writing the source code. Whilst it is true that theresult of some of the other work is wholly contained within the source code thisdoes not imply that it is no longer needed. The contents of the source code maybe inferred from the design information, but the reverse is not true. The bestcase for not discarding this information can be made with reference to the needto re-test the software in a new environment or after modification. The designinformation, including its background and limitations are also useful. Theiravailability could prevent someone wasting time trying to implement a featurewhich was found to be difficult or unnecessary during the development of thefirst version. That is, the lessons which had been learnt, and are not reflected inthe source code, or in the documentation, are preserved.

RETESTING UNMODIFIED SOFTWARE

If we are reusing a piece of code do we still need to test it? There aretwo opposing views to this argument. One is that if we re-set everything eachtime we use it we loose much of the benefit of reusing it and the other is thatwould be foolish to commit ourselves to using a piece of code without assuringourselves that it works.

The reason for the first point of view is obvious, testing takes time andeffort and costs money, the software must have been tested when it was firstused so why waste money repeating the work. The second point of view has itsfoundations in a lack of faith in the initial VV&T process. If they were notcorrect it could take a lot of work to locate the fault when it is embedded withinthe finished system. How much re-testing we should undertake must be base onour estimate of the quality of the initial work. Factors which influence this are:

• Was the software tested in the first place?• How full was the initial test coverage?• It is not possible to fully test a piece of software,• Did the tester make the same false assumption as the programmer?• Are there any assumptions which are not necessarily valid in the new

use?

If we assume that the code has been tested for all valid input, and that anerror will be reported if the input is not valid, then we only need to ensure thatwe have used the code correctly. This entails testing, but it need not beperformed to the same degree as for a new piece of code. It can be done with afew illustrative test cases rather than with a full test set. This gives us sampleinput and output in order to confirm our understanding of its interface andusage.



DOCUMENTING TEST DATA, RESULTS AND METHODS

The task of documenting test data is even more odious than that ofdocumenting the design or the source code. This is because it is often necessaryto cover the same piece of ground several times before the test is successful.The temptation exists to postpone documentation until the process is finished.Measures must be taken to discourage this approach. The first step is to makethe documentation process as painless as possible. As much of the information,metrics and statistics as possible should be produced and stored automatically.The rest should be done by filling in document templates. These are a softwareversion of the check sheet, a form with prompts for the insertion of information.

These act as a guide to the user when writing the documentation, theyreduce the chance of details being left out or being included in an illogicalposition. They also provide a structure making analysis by tools such as metricanalysers and classification systems easier, keys can be automatically assigned tothe fields. The imposition of a structure also gives some degree of homogeneityto the system documentation.

Templates can be provided for all stages of design and test. It is moreefficient to provide these in an environment similar to a word processor ratherthan "doing it by hand" in a programmers' editor. Consistent format style, textannotations, revision notes and version control and comparison are all easy toaffect. The process of documentation becomes less time consuming and isregarded as less of a chore, people are then more willing do it regularly and, as aconsequence of this, the documentation will be more accurate and up to date.

An interesting extension to the current methods used for documentationand project management was proposed by [KELLY84]. This entailed the use of avideo camera and crew whose task it was to tour the members of a project andinterview them about their days work. He found that this gave a better overviewof the state of the project as well as providing some record of matters whichwere, as yet, still too vague to document formally. The appearance of the videocrew provided discipline ensuring that some record was kept, the task ofproviding a short interview was seen as requiring less effort than producingformal documentation and records.

TEST DATA REUSE

An initial effort in this direction could be to store test data and strategiesin the reuse catalogue along with the source code. This means that if, when aprogrammer reuses a piece of code, and he wants to re-test it, the test data andstrategy are available, together with an indication any areas of special difficulty.Gruengerger noted [GRUEN69] that every program requires an original testprocedure. The intellectual effort required to test a program is of the same order



as that which created it. Test information is, therefore, a valuable commodityand steps should be taken to exploit it.

In an attempt to reuse test information, the first step, having written anew piece of software, might be to search for a similar piece of code and extractits test strategy, this then forms a base from which to devise a new one. Whitebox test information would prove to be of little use unless the implementationhappened to be the same. The value of any black box test information willdepend on the functional similarity of the code in question, code with a highdegree of similarity would require little modification to the test strategy.

An example of this sort of reuse could be found in the testing of sortingfunctions. Several of these may be implemented in order to sort varying cross-sections of input data efficiently (for example the bubble sort algorithm isefficient at sorting "nearly sorted" data, while the q-sort algorithm is better forrandom input data), however, the black box test strategy would be the same forall of sorting algorithms.

The white box test data would vary with each implementation, forexample, the external sort routine requires testing to ensure that the temporaryfiles needed are created and deleted safely, and that no other files are effected.This section of the test set is redundant with internal sorting routines.

Detailed metric information such as path coverage is of little use, itcannot be reused on its own, keeping it is merely an indication of the degree oftest coverage achieved. A synopsis of it is probably best kept as an informationfield within the source code (e.g. qsort.cpp, sorting algorithm, test pathcoverage 75%, code complexity 60%) to indicate the level of test coverageattained.

WHAT DOCUMENTATION IS REQUIRED

Brooks [BROOK75] said that different levels of documentation arerequired for different people. Too much documentation is better than too little,if you give someone too much documentation they don't have to read it. Typicalsource code documentation is very sparse in areas such as design considerationsand intended usage, it gives too little overview. Trees are described, bark andleaves are commented but there is no map of the forest [BROOK75].

The documentation should include the purpose of the code, referencesfor any obscure algorithms used, the design considerations, how the code isintended to be used, any hardware or system dependencies, any known bugs orrestrictions, the version, revision history and time stamp, source code linecomments, metric information, test strategy (how to test the software), the levelof test coverage undertaken.



INTEGRATING SOFTWARE, DOCUMENTATION AND TEST DATA

Workable classification schemes have been devised to enable people tocatalogue, retrieve and reuse source code. It has been noted that writing sourcecode takes up only one sixth of the system development effort, therefore effortsshould be made to reuse the design decisions and the test effort.

A major configuration management problem can be created trying tokeep the separate fragments of a reusable module concurrent. Among thesefragments are the source code, the documentation, the test data, the teststrategy, the test results, the history and revision lists, the uncorrected bug andfuture work list.

In a normal project these would be stored as separate files, possibly evenon different media. In a large scale project a configuration management tool anda series of cross-reference lists are used to access the relevant data. This is apoor solution as it relies on the integrity of the configuration man system and itsregular upkeep. Code reuse is not promoted as it is difficult to ship a codefragment without the risk of not getting all the bits. How many fragments ofcode are there lying around for which the documentation has been lost?

One simple solution to this is to keep all the fragments together in thesame file. This allows documentation[BROOK75], debugging code, expectedintermediate results, code mutations, etc. all to be incorporated at the relevantposition in the source code. The increase in code size has no effect on thecompiled code as the pre-processor ignores it. The source code size is notsignificant in any modern system and, given that all the information must bestored somewhere, there is no net increase in the storage requirement. Themodule can now be recorded in the configuration management system, thesoftware catalogue or exported to another project, as a single entity.

An argument can be made that this technique clutters the listing andmakes reading it difficult but this problem can be solved by the use of a foldingeditor. If the editor is configured to read markers in the source idle todifferentiate the various fragments then it can be set, for example, to just displaythose folds containing the documentation. This approach could be extended toinclude the folding of pre-processor directives such as #define, #ifdef, etc.further increasing the readability of the code.

CONCLUSIONS

The following problems are all accentuated by increase in code size:

• imperfect task partitioning [BROOK75],• the difficulty of understanding the system,• the error rate,



• the cost,• the difficulty of predicting the completion time,• the level of test coverage,

(a program must be very small in order for you to fully test it.)

A lot of work has been done in developing classification schemes. Mostof the effort is expended in attempting to devise the classification and recallcriteria for the software to be catalogued and in attempting to develop artificialintelligence schemes to locate and rank the candidates when an exact match hasnot been found. Having identified what makes a piece of software classifiableand reusable, it should be relatively easy to transfer it from one scheme toanother. The scheme used is therefore of secondary importance to having codewhich can be easily fitted in it. The properties of a good reuse scheme have beendiscussed as have the properties of a reusable piece of code. Once theseschemes become more mature they will probably be usable in much their presentform. It is there for a reasonable step to decide that any extension to the idea ofsoftware reuse to include design, test or documentation information should, ifpossible, be addressed in such a way that it can be implemented as anextenuation to any software reuse system, rather than as a new system. For this,and other reasons, the extensions are best encapsulated within the source coderather than standalone.

REFERENCES

[BOOCH88] Grady Booch, Object Oriented Design with Applications,ISBN 0-8053-0091-0

[BROOK751 Fred P. Brooks, The Mythical Man Month, Addison -Westley, 1975

[BUCCA79] Brian Buchanan, Theory of library classification, CliveBingly, London, 1979

[BURTO87] Bruce A. Burton, Rhonda Wienk Argon, Stephen A. Bailey,Kenneth D. Koehler, Lauren A. Mayes, The reusableSoftware Library, IEEE Software, July 1987, pp, 25-33

[GRUEN69] F. Gruengerger, in W. C. Hetzel, program test methods 1969

[MAYER79] T. G. Mayers, The Art of Software Testing, Wiley, 1979,ISBN 0471043281

[PRIET87] Ruben Prieto-Diaz, Peter Freeman, Classifying software forreusability, IEEE Software (Jan. 1987) vol. 4, no. 1, pp, 6-16, ISSN: 0740-7459

[PRIET91] Ruben Prieto-Diaz, Implementing faceted classification forsoftware reuse, Communications of the ACM, May 1991,Vol. 34, No. 5



[KELLY84] H. K. Kelly, Videotaping your Software Documentation,Aauerbach publishers inc., Pennsauken N. J. 08109,Infosystems 1984 vol. 31 no. 11 p.100


abstract - wit press · to be reused without re-test and, as intellectual effort required to test a...

Documents