TheSoftwareConcordance:BringingHypermediatoSoftwareDevelopmentEnvironments

EthanV. Munson�

Departmentof ElectricalEngineering& ComputerScienceUniversityof Wisconsin-Milwaukee

Mil waukee,WI 53211USAmunson@cs.uwm.edu

April 9, 1999

Abstract

TheSoftwareConcordanceprojectis examininghow hypermediatechnologycanpro-vide improved tools for managingthe full rangeof documentsproducedby the softwarelife cycle. The project’s aim is to help softwaredevelopersbettermaintainconformancebetweenthesemany documentsas they andthe software that they describechangeovertime. This researchrequiressolutionsto openproblemsin a numberof areasincludingdocumentrepresentationandformatting(especiallyfor programsourcecode),fine-grainedversioncontrol for tree-structureddocuments,the categorizationof relationshipsamongsoftware documents,and the analysisand visualizationof documentrelationships.TheSoftwareConcordanceprototypewill supportJavaprogramsandXML documentsandwillprovide toolsfor defining,maintaining,andanalyzingdocumentrelationships.

1 Introduction

Much of theadvanceof thehumanconditionis basedon our ability, throughword-of-mouth,writtendocuments,andotherformsof communication,to makeconnectionsbetweenideas.Bybuilding relationshipsamongideas,we have constructeda complex network of usefulknowl-edgeaboutengineering,medicine,history, andmany othertopics,whoseexistenceis oneof thecritical foundationsof modernlife.

Bush[6] andNelson’s [29] earlyvisionsof hypermediasystemsrecognizedthecentralim-portanceof connectionsbetweenideasand foresaw new technologythat would make thoseconnectionsmoreexplicit andaccessible.Both BushandNelsonsaw clearly thatbettertoolsfor recordingandmanagingknowledgewould substantiallyenrichour intellectuallives.Earlyexperimentationwith closedhypermediasystemsdemonstratedthat the technologyto supportthisvisionwasachievable,particularlyfor educationalmaterial.Now, theWorld WideWebhasshown us,in nouncertainterms,thatthevisionaries’belief in thepotentialimpactof hyperme-diaon theworld at largewaswell-founded.�This researchis supportedin partby NationalScienceFoundationCAREERAward#CCR-9734102andby

UW-Mil waukeeGraduateSchoolResearchCommitteeandResearchIncentiveProgramawards.

1

1.1 Software Development and Hypermedia

Relationshipsbetweenideasarecritical to theprocessof softwaredevelopment.Thelife cycleof a softwaresystemproducesa tremendousvarietyof documents— requirementsspecifica-tions,designdocumentsof many types[17], programsourcecode,testingandbugreports,anduserdocumentationareexamples.Thesedocumentsembodyagreatnumberof ideaswhichareconnectedby a complex network of relationships.Hypermediatechnologyrepresentsanaturalmechanismfor representingthesedocumentsandtheir relationships.

Imagineahypermediaenvironmentthatencompassesall thedocumentsin asoftwareproject.In this environment,anextensive link structureis usedto representthe relationshipsbetweensoftwaredocumentsexplicitly. In thisenvironment,it will beeasyto addressquestionslike thefollowing:

� If requirementR is changed,how muchof theimplementationandwhichtestingroutinesmightalsohave to bechanged?

� Whatpartsof thesystemhadto bechangedin orderto correcttheproblemidentifiedinthisbug report?

� Whatnew featuresof thesystemhavenot yetbeendescribedin theuserdocumentation?

Yeteventhoughhypermediais anaturalmechanismfor representingandmanagingsoftwaredocuments,it doesnot seesubstantialuse,becauseimportantopenproblemsin the designofbothsoftwaredevelopmentenvironmentsandhypermediasystemsremainto besolved. Theseopenproblemsinclude:

� Makingprogramsourcecodedocumentsinteroperatewith otherclassesof softwaredoc-uments;

� Identifying a taxonomyof therelationshipsamongsoftwaredocumentsandcreatinghy-permedialink representationsthatembodytheserelationships;

� Providing efficient,fine-grainedversioncontrolof tree-structureddocumentsthatis inte-gratedwith hypermedialink-traversalservices;and

� Developinganalysisandvisualizationtoolsthatallow softwaredevelopersto understandandexploit therelationshipsamongtheirprojects’documents.

TheSoftwareConcordanceprojectat theUniversityof Wisconsin-Milwaukeeis exploringsolutionsto eachof theseproblems. Its long rangegoal is to improve softwaredevelopmentproductivity by providing tools that allow developersto ensurethat their softwaredocumentsconformto eachother. TheSoftwareConcordanceprototypewill supporttheeditingandmain-tenanceof Java programsandXML documents.Programsourcecodedocumentswill befullyinteroperablewith othersoftwaredocuments,sodeveloperswill beableto documenttheircodewith multimediamaterialandwith links to othersoftwaredocuments.

Theremainderof thispaperprovidesamorecompletedescriptionof theresearchproblemsbeingaddressedby theSoftwareConcordanceproject.

2

Figure1: Thisscreendumpof theEnsemblesystemillustrateshow embeddedmultimediadoc-umentationcouldbeusedto clarify complex algorithms,suchastherotationsusedto balanceAVL trees.A sectionof Java sourcecodeis documentedby a 2D graphicshowing therotationalongwith an explanatoryparagraph.While Ensemblehasin the pasthadsupportfor video,thisscreendumpsimulatesanexplanatoryvideoclip with anincludedimage.

2 Background

2.1 Software documents

The many documentsproducedby the softwaredevelopmentprocesscanbe broadlydividedinto two categories:formalandinformal.

Formaldocumentsincludeprogramsourcecodeandformal specifications.Their commoncharacteristicis that their syntacticandsemanticstructurecanbedeterminedby analysisof atext stream(with the obvious exceptionof visual programs). Formal documentsarewrittenusingASCII text editorsor specializedenvironments. Even the advancedenvironments(forexample,Ada-Assured[13]) arerestrictedto text, albeitwith font andcolor variations,anddonot supportdocumentationin othermediaor connectionswith othersoftwaredocuments.Thelimitation to textual documentationcanpreventprogrammersfrom expressingimportantideasabouttheir codethatarebetterexpressedin othermedia.Figure2.1 shows anexamplewhereanembeddedgraphicfigureclarifiesanalgorithm.Thefactthatprogrammerscannotlink theirsourcecodeto its supportingdocumentsis just asseriousa limitation, sincethecodeis oftenadirectexpressionof ideasin thoseotherdocuments.

All othersoftwaredocumentsareinformal. Any syntacticor semanticstructurethey haveis eitherspecifieddirectly by theuser, obtainedfrom a sharedtemplateor form, or is implicitin the naturallanguagecontentof the document.Examplesincluderequirementsdocuments,designdocuments,testingandbug reports,anduserdocumentation.Informal documentsarecommonlyproducedusingcommercialoffice softwaresuites,suchasMicrosoft Office [22].MS Office providesextensive interoperabilitybetweenthedifferenttypesof documentsit sup-ports:any documentcanincludeactive fragmentsof otherdocuments.Furthermore,MS Officedocumentscanimport a wide varietyof multimediaobjects.However, theseinclusionsarenot

3

markedwith informationabouttheirsemantics.

2.2 Interoperability

In practice,formal andinformal documentsdo not interoperate.The centralproblemis that,in formal documents,the text streamis usedboth for analysisandfor presentation[35]. Thelexical analysisphaseof programanalysisrequiresthat thetext streamadhereto thelanguagespecification,which allows only textual comments.Thus,it is not possibleto embedobjectscomposedof arbitrarybytestreams(suchascompressedimages)insideprogramsourcecode.It is possibleto conceiveof programeditorsthatsearchfor specialcommentspointingto piecesof non-text documentationheldexternally, but therearenoexamplesof suchaneditor. Suchaneditorwouldrequireaspecialformattingmodelto correctlydisplaythenon-text documentation.

This is not to saythatprogrampresentationhasbeenignored.In fact,thereis a largelitera-tureonprogrampretty-printing.Early work focusedon pretty-printingstandardsfor particularlanguages(seeBaecker andMarcusfor a summary[1, p. 18]) andon line-breakingalgorithmsfor programstatements[16, 23, 30, 31, 37]. More recentwork hasemphasizedspecificationlanguagesfor pretty-printing,suchasPPML [15]. All of this work hasfocusedentirely onprogramsourcecode.

Theauthor’sdissertationresearch[28] investigatedamoregeneralapproachto presentation.This researchshowed thereexists a coresetof presentationserviceswhich canbe sharedbyindependentmodulesfor differentmediawithin alargersystem.Thiswork producedaportablestyle sheetsystem,Proteus[12, 26] that canbe configuredto supportdifferentmedia(text,graphics,video)andis alsosuitablefor programsourcecode. Configurationof Proteusfor anew medium(or anotherapplication)is performedby writing a specificationof themedium’sprimitivetypes,dimensions,andpresentationattributes[27]. Proteusis alsodesignedto supportmultiple simultaneousviews of the samedocumentin differentstyles,a mechanismthat canbe exploited for the productionof novel userinterfaceswithout requiringseparateformattingservicesfor eachview. Proteusis portableandhasbeenusedby two systems:the Ensemblesoftwaredevelopmentandmultimediadocumentenvironment[11] andMultiple PresentationMosaic[18, 20], amultiple-view browserfor theWorld-WideWeb.1

2.3 Document Relationships and Conformance

Thereare many typesof relationshipsbetweensoftware developmentdocuments. Withoutclaimingto presentacompletetaxonomy, thesearesomeexamples:

� Therequirementsmotivatethedesign.

� Thedesignrequirestheimplementation.

� A testreportevaluatestheimplementation.

� A bug reportcomplainsabouta mismatchbetweentherequirementsandtheimplemen-tation.

� A changeto theimplementationrespondsto abugreport.

1Examplesof the output of Multiple PresentationMosaic can be seenon the principle investigator’s Webpageat http://www.cs.uwm.edu/ multimedia. Thesedemonstratesomeof the usesof multiple-viewtechnology.

4

� Theusermanualdocumentsthedesignandimplementation.

In general,theserelationshipsarepersistent,lastingdays,weeks,or years,but they are notnecessarilypermanent.Becausethe documentsin a systemaredynamicandcanbe created,altered,andremoved, the setof active relationshipsin a systemis alsolikely to changeovertime.

Let us consideran imaginarysoftwaresystemwhosedocumentsare in perfectharmonywith eachother. We might say that its documentsareconformant, becausethey conformtoeachother. If we thenalter a requirement,suchasthe numberof usersto be supported,butmake no otherchange,it becomespossiblethatthesystemdoesnot meetits requirements.Wemight thensaythat thesystem’s documentsarenon-conformant, becausethesystem’s designdoesnotconformto its requirements.

Barringmajoradvancesin naturallanguageprocessingresearch,completelyautomatictest-ing for conformancebetweensoftwaredocumentswill notbepossiblefor sometime. However,if therelationshipsbetweensoftwaredocumentswereexplicitly recorded,it might bepossibleto automatedetectionof possiblenon-conformance.Suchautomateddetectioncouldbeusedtoguidedevelopersto potentialproblems.

It is importantto notethatsimilar relationshipsexist amongsourcecodeandspecificationdocuments.Programminglanguageshave commandslike “include” or “require” thatdescribea dependency betweenpairsof files. Thedifferenceis that theserelationshipsbetweenformaldocumentscanbefound,without any ambiguity, by automatedanalyses.In fact,relationshipslike theseareanimportantinformationsourcefor re-engineeringtools[24].

Eachof theabove documentrelationshipscarrieswith it an implied logical orderingof itsdocuments.For example,testingandbugreportscannotbeproduceduntil animplementationisavailable,andwhile it is notnecessarilythecasethatrequirementdocumentswill bewrittenbe-foredesigns,thereis certainlya logicalrelationshipbetweenthemthatmakesdesigndependonrequirements.Orderedrelationshipslike thesehavebeenusedfor many yearsto automateeffi-cientcompilation[7, 9]. However, thesetechniqueshaveyet to beappliedto informalsoftwaredocuments.

3 The Software Concordance Research Plan

The SoftwareConcordanceprojecthasan ambitiousresearchplan that involvesresearchonfundamentalsconceptsandrepresentationsaswell asinvolving theconstructionof a workingprototypeenvironment.Thissectiondescribestheseplans.

3.1 Interoperability

TheSoftwareConcordanceprojectwill developrepresentationsthatprovidefor interoperabilityamongformalandinformaldocuments.Theserepresentationswill:

� Allow any documentto includeany fragmentof any otherdocument.Theincludedfrag-mentmaybefrom aparticularversionor maybeactive,changingasthesourcedocumentchanges.

� Allow the binding of bi-directional,typed relationshipsto any pair of documentfrag-ments.

5

Source Code�

Revision k

Source Code�

Bug Report

Source Code�Revision k-1

Bug Report

complains about�

responds to

responds to

complains about�

editing�changes�

(a) (b)

Figure2: In (a), the relationshipsbetweena sourcecodedocumentanda bug report form acycle, becausethe codeis both causeof the bug reportandthe responseto it. However, theadditionof versioninformationin (b) breaksthis cycle by makingclearthat thebug reportiscomplainingabouta problemin the version

���of the sourcecode,while version

�of the

sourcecodehasbeeneditedandrespondsto thebug report.

� Supportauniformmodelof fine-grainedrevisioncontrol.

� Allow programanalysisandcompilationservicesto operatewithoutmajormodification.

Theapproachtakenby theSoftwareConcordancewill begin with auniformtree-structuredrepresentationfor informal documents,suchasXML [4, 5], thestandardfor World-Wide Webdocuments. Interoperabilitybetweentree-structuredinformal documentsis well-understoodandcanbefoundin theEnsemble[21] andGrif/Thot systems[32].

Then,asproposedin theauthor’searlierwork on interoperability[25], a representationthatintermixessectionsof sourcecodewith othersectionsthat containinformal materialwill bedesigned.The informal materialmayeitherbeembeddeddocumentationor maybean inclu-sionof partof anotherrelevantdocument.This representationwill maintaina clearseparationbetweenthesourcecodeandinformal sectionsof thedocumentsothatprogramanalysisneedonly traversethesourcecodesections.Therepresentationwill allow thepersistentbindingoftheinformalmaterialto therelevantsectionof thesourcecode,sothattheconnectionbetweenthemcontinuesfrom oneeditingsessionto another. Furthermore,it will provide for thedefini-tion of persistentselections[14] thatwill serve asend-pointsfor documentrelationships,thatis, asanchorsfor hypermedialinks.

This sourcecodedocumentswill requirethedevelopmentof a novel formattingmodelthatproperly integratesthe formal and informal material. The centralproblemis that automaticpretty-printersoperatenot from linesof text, but ratherfrom anabstractsyntaxtree[1, 15]. Butin this new representation,the leavesof theabstractsyntaxtreewill be intermixedwith someothertree-basedrepresentationfor the informal material.No existing formatteror editormustcoordinatebetweentwo treerepresentations,soanew formattingmodelwill berequired.

TheSoftwareConcordanceprojectwill alsodesignauniform,fine-grainedrevisioncontrolmodel for softwaredocuments,becauserevision control is a critical elementof the softwaredocumentenvironmentsenvisionedby theinvestigator. Figure2 illustrateshow apparentcyclesin therelationshipgraphof softwaredocumentsarebrokenwhentherelationshipsaredefinedbetweenversionsof thedocuments.

This work will build on researchby Magnusson,Asklund,andMinor [19] on versiontreesfor tree-structuredtext documents.They showed that versiontreesaremoreflexible andse-mantically correct than the line-orientedrevision systemswidely usedfor programsource

6

code[33, 34] andarebettersuitedfor collaborative softwaredevelopment.Wagnerextendedthis work to integrateversionmanagementwith programediting and analysisoperationsintheEnsembleenvironment[36], but did not providea persistentrepresentationof theversions.TheSoftwareConcordanceprojectwill applyversiontreesto multimediadocumentsandwillprovide thepersistencemissingfrom Wagner’s work.

3.2 Software Document Relationships

Section2.3 listed several typesof relationshipsthat may exist betweensoftwaredocuments.Thelist is not claimedto becomplete,exhaustive,or minimal; it is simplyasetof examples.

The SoftwareConcordanceprojectis studyingrelationshipsbetweensoftwaredocumentsin orderto definea taxonomyfor them. Thetypesof relationshipsidentifiedby thetaxonomywill thenbeusedto marklinks betweensoftwaredocuments.

It might bearguedthat a taxonomyof relationshipsis unnecessary, that it would besuffi-cient to simply mark theexistenceof dependenciesbetweendocumentswithout any informa-tion aboutthetypeof relationship.This argumentis misguidedbecauserelationshiptypescanconvey importantinformationaboutthesemanticsof theconnectionbetweentwo documents.Supposethat complainsaboutandcommentson are two relationshiptypes. The fact that �commentson is essentiallyneutral.In contrast,when � complainsabout � , it is clearthataproblemexists. In mostsystems,complaintsrequirea response,while commentsdonot.

Usingthetaxonomyof documentrelationships,theSoftwareConcordanceprojectwill de-signa representationfor links betweendocumentsthatmakestheserelationshipsexplicit. Thisrepresentationwill have thefollowing characteristics:

� Links will connectpartsof document,ratherthanentiredocuments,sothatrelationshipscanbedefinedonafine-grainedbasis.

� Sincechangesto documentelementsalter their relationships,links will connectspecificversionsof documentelements.Thiswill allow thenetwork of relationshipsto reflectthedynamicnatureof softwaredocuments.

� Sincea developermay want to follow a link in eitherdirection,the link representationwill supporttraversalin bothdirections.

� At the sametime, the link representationwill becompatiblewith theWorld-Wide Webconventionof embeddinglinks in thesourcedocument(whichnormallymakesthemuni-directional).

� The representationmustallow developersto statewhetheror not the documentsin therelationshipareconformant.The simplefact that requirementshave changeddoesnotnecessarilymeanthatthedesignis inadequate.It simplymeansthatadeveloperneedstoinspectbothdocumentsto determinewhetherthereis aproblem.

� Therepresentationmustbereadilyaccessiblefor queryingandanalysis.

Thesecharacteristicswouldbefairly easyto achieve in aclosedhypermediasystemthatstoreslinks separatelyfrom thedocumentsthey connect.Thechallengeis to providethemin asystemthatremainscompatiblewith theWorld-WideWeb.

7

3.3 Analysis, Visualization, and User Interface Services

Oncethedocumentandrelationshiprepresentationshave beendefined,the SoftwareConcor-danceprojectwill designandimplementservicesthathelpdevelopersmaintainandunderstandthe relationshipsbetweentheir softwaredevelopmentdocuments.This work will rely on andenhancetheexperimentaltestbeddescribedin thenext section.

Theseuserinterfaceserviceswill allow the creation,inspection,andremoval of links be-tweendocuments.Developerswill alsobe ableto mark links with informationaboutconfor-manceof the documentsthat eachlink connects.Otherinterfaceserviceswill allow the userto constructqueriesfor typesof relationshipsandlevelsof conformance.For example,a usermaywantto find all pairsof non-conformingdocumentshaving therequiresrelationship.Theresponsesto thesequeriescaneitherbereportedto theuservia a textual interfaceor by high-lighting matchingdocumentsections.

In contrastto the userinterfaceservices,which will primarily provide informationaboutlocalrelationships,theanalysisserviceswill computepropertiesof thegraphof relationshipsasa whole. Becausethis informationmaybecomplex andhardto understand,visualizationtoolswill be designedand developed,building build on prior researchon graphicalpresentationsof large software systemsusing graphs[24] and compactvisual summariesof sourcecodefiles [2, 8].

Theanalysisandvisualizationserviceswill allow developersto answerquestionslike thefollowing:

� If requirement� is changed,whichotherdocumentsmayrequirechanges?

� Whenrequirement� changed,whatchangesto otherdocumentshadto bemade?

� Whatfeaturesof thedesignhavebeencomplainedaboutthreeor moretimes?

� How oftenaredesignandrequirementschangesmadein responseto bug reports?

� How often do bug reportscomplainaboutdocumentsthat test reportsalsocomplainedabout?

3.4 The Software Concordance Prototype

Theconceptsexploredby theSoftwareConcordanceprojectwill beevaluatedby implementa-tion in anexperimentaltestbed:anenvironmentfor Javaprogramsandtheirassociatedinformaldocuments.Theenvironmentwill usea tool-baseddesign,ratherthantrying to createa mono-lithic program,but will includea fairly largeeditorsupportingall typesof documents.Further-more,theenvironmentwill beimplementedin Javaitself, sothatovertime,theresearcherswillbeableto useandevaluatethetoolsthey arecreating.

TheJava languagewill beusedbecauseit hasa cleansyntacticdesignthateasesprogramanalysisandbecauseof its importanceto the WWW. Focusingon a singleprogramminglan-guagewill simplify thesystemby allowing theuseof special-purposecodeto handleany trickyproblemswith incrementalprogramanalysis.

Informal documentswill be representedusingXML [5], an evolving standardfor WWWdocuments.Unlike the HTML standard[3], which definesa singletype of document,XMLprovidesa mechanismfor definingnew typesof documents.Furthermore,XML’s designisintendedto supportbi-directionallinks,but thispartof its designis notyetcomplete[4]. UnlikeSGML [10], onwhich it is based,XML is designedfor usein interactivesystems.

8

Thecoreof theenvironmentwill beaneditorfor JavaprogramsandXML documents.Theeditor’s featureswill include:

� Full interoperabilitybetweenall documenttypes,

� Integratedparsingandtype-checkingof Javaprograms,

� Userinterfacefeaturesfor managingdocumentrelationships,

� World-WideWebcompatibility, and

� Integrationwith theenvironment’s revisioncontrolsystem.

All othertoolsandservices,includingrevision control, relationshipanalysis,andrelationshipvisualization,will beimplementedasindependentprograms.

4 Conclusion

TheSoftwareConcordanceprojectenvisionsanew kind of softwaredevelopmentenvironmentthat integrateselementsdrawn bothfrom currentprogrammingenvironmentsandfrom hyper-mediasystems.My hopeis thatit will demonstratethatprogramsourcecodecanbebroughtoutof thedatedworld of eight-bitcharacterstreamsandintegratedwith themany informal,naturallanguagedocumentsthatarealsoproducedby any qualitysoftwareproject.

It is, of course,ridiculousto think thatsuchintegrationcanmagicallytransformthepracticeof softwaredevelopmentfrom its chaoticcurrentpracticeto thatof a utopianfuture.However,it is not unreasonableto seethiswork asanimportantsteptowardbetterconformancebetweentherequirements,design,andimplementationaspectsof thesoftwarelife cycle. Furthermore,softwaredevelopmentis only oneof many professionsthat involve the creationof networksof interrelateddocuments— thelegal anddiplomaticprofessionsareexamplesof others.Thetoolsandtechniquesdevelopedfor theSoftwareConcordanceprototypeshouldbeapplicableto theseandotherdomains.

References

[1] RonaldM. Baecker andAaronMarcus.HumanFactors andTypographyfor More Read-ablePrograms. Addison-Wesley, Reading,Massachusetts,1990.

[2] ThomasBall and StephenG. Eick. Software visualizationin the large. Computer,29(4):33–43,April 1996.

[3] T. Berners-LeeandD. Connolly. Hypertext MarkupLanguage — 2.0. World Wide WebConsortiumandMIT, June1995.InternetDraft availablefrom www.w3c.org.

[4] Tim BrayandSteveDeRose.Extensiblemarkuplanguage(xml): Part1. linking. Availableon theWorld WideWebathttp://www.w3.org/TR/WD-xml-link,April 1997.

[5] Tim Bray and C. M. Sperberg-McQueen. Extensiblemarkuplanguage(xml): Part 1.syntax. Availableon theWorld Wide Webat http://www.w3.org/TR/WD-xml-lang,June1997.

9

[6] VannevarBush.As wemaythink. AtlanticMonthly, July1945.

[7] Geoffrey ClemmandLeonOsterweil. A mechanismfor environmentintegration. ACMTransactionsof ProgrammingLanguagesandSystems, 12(1):1–25,January1990.

[8] StephenG. Eick, MichaelC. Nelson,andJeffery D. Schmidt.Graphicalanalysisof com-puterlog files. CACM, 37(12):50–56,December1994.

[9] StuartI. Feldman. Make — a programfor maintainingcomputerprograms. Software:PracticeandExperience, 9:255–265,1979.

[10] CharlesF. Goldfarb,editor. InformationProcessing—Text andOfficeSystems—StandardGeneralizedMarkupLanguage (SGML). InternationalOrganizationfor Standardization,Geneva,Switzerland,1986.InternationalStandardISO8879.

[11] SusanL. Graham. Languageanddocumentsupportin softwaredevelopmentenviron-ments. In Proceedingsof theDarpa ’92 Software Technology Conference, Los Angeles,April 1992.

[12] SusanL. Graham,MichaelA. Harrison,andEthanV. Munson.TheProteuspresentationsystem.In Proceedingsof theACM SIGSOFTFifth SymposiumonSoftwareDevelopmentEnvironments, pages130–138,Tyson’sCorner, VA, December1992.ACM Press.

[13] Grammatech,Inc. Ada-assuredhomepage.Accessibleat http://www.grammatech.com,1997.

[14] Frank Halaszand Mayer Schwartz. The dexter hypertext referencemodel. CACM,37(2):30–39,February1994.

[15] INRIA: Centaur Project, Sophia-Antipolis, France. The PPML Manual, February1994. For Version 1.3 of Centaur. Available by ftp from babar.inria.fr in directorypub/croap/bertot.

[16] DonaldE.KnuthandMichaelF. Plass.Breakingparagraphsinto lines.Software—Practice& Experience, 11(11):1119–1184,November1982.

[17] RichardC. LeeandWilliam M. Tepfenhart.UML andC++: A PracticalGuideto Object-OrientedDevelopment. Prentice-Hall,1997.

[18] Hong Liu. Multiple PresentationMosaic. Master’s thesis,University of Wisconsin-Mil waukee,May 1996.

[19] BorisMagnusson,Ulf Asklund,andStenMinor. Fine-grainedrevisioncontrolfor collab-orativesoftwaredevelopment.In Proceedingsof theFirstACM SIGSOFTSymposiumontheFoundationsof SoftwareEngineering, pages33–41.ACM Press,December1993.

[20] Philip M. Marden,Jr. andEthanV. Munson.Multiple Presentationsof WWW DocumentsUsingStyleSheets.In Proceedingsof ED-MEDIA98,ConferenceonEducationalMulti-mediaandHypermedia, Freiburg, Germany, June1998.Associationfor theAdvancementof Computingin Education.

[21] VanceMaverick. PresentationbyTreeTransformation. PhDthesis,Universityof Califor-nia,Berkeley, 1997.

10

[22] Microsoft, Inc.,Redmond,Washington,USA. MicrosoftOffice4.2, 1995.

[23] Martin Mikelsons.Prettyprintingin aninteractive programmingenvironment.TechnicalReportRC 8756,IBM ResearchDivision,ThomasJ.WatsonResearchCenter, YorktownHeights,NY, March1981.

[24] H. A. Muller, S. R. Tilley, M. A. Orgun, B. D. Corrie, andN. H. Madhavji. A reverseengineeringenvironmentbasedonspatialandvisualsoftwareinterconnectionmodels.InProceedingsof the ACM SIGSOFTFifth Symposiumon Software DevelopmentEnviron-ments, pages88–98,Tyson’sCorner, VA, December1992.ACM Press.

[25] EthanV. Munson. Interoperabilityof software documents. In Workshopon SoftwareEngineeringand Human-ComputerInteraction: Joint Research Issues, pages153–162,May 1994.Workshoppre-prints.

[26] EthanV. Munson. A new presentationlanguagefor structureddocuments.ElectronicPublishing:Origination,Dissemination,andDesign, 8:125–138,September1995.Orig-inally presentedat EP96,the Sixth InternationalConferenceon ElectronicPublishing,DocumentManipulation,andTypography, PaloAlto, CA, September1996.

[27] EthanV. Munson.Towardanoperationaltheoryof media.In Proceedingsof theThird In-ternationalWorkshoponPrinciplesof DocumentProcessing. Springer-Verlag,PaloAlto,CA, September1996. To bepublishedaspartof theLectureNotesin ComputerScienceseries.

[28] EthanVincentMunson. Proteus:An AdaptablePresentationSystemfor a Software De-velopmentandMultimediaDocumentEnvironment. PhDdissertation,Universityof Cal-ifornia, Berkeley, December1994. Also availableas UC Berkeley ComputerScienceTechnicalReportUCB/CSD-94-833.

[29] TheodorNelson.ComputerLib/DreamMachines. Microsoft,1987. ComputerLib origi-nally self-publishedin 1974.

[30] DerekC. Oppen. Prettyprinting. ACM Transactionson ProgrammingLanguagesandSystems, 2(4):465–483,October1980.

[31] William W. Pughand Steven J. Sinofsky. A new language-independentprettyprintingalgorithm. TechnicalReportTR 87-808,Dept.of ComputerScience,CornellUniversity,Ithaca,NY, January1987.

[32] VincentQuint andIreneVatton. Combininghypertext andstructuredocumentsin grif.In D. Lucarella,editor, Proceedingsof ECHT’92, pages23–32,Milan, December1992.ACM Press.

[33] M. J. Roekind. Thesourcecodecontrol system. IEEE Transactionson Software Engi-neering, SE-1(4):364–370,December1975.

[34] W. F. Tichy. RCS— a systemfor revision control. Software: PracticeandExperience,15(7):637,July1985.

11

[35] Michael L. Van De Vanter, SusanL. Graham,andRobertA. Ballance. Coherentuserinterfacesfor language-basedediting systems. International Journal of Man-MachineStudies, 37:431–466,1992.

[36] Tim A. WagnerandSusanL. Graham.Integratingincrementalanalysiswith versionman-agement.In Proceedingsof theFifth EuropeanSoftwareEngineeringConference, 1995.

[37] RichardC. Waters.XP: A CommonLisp prettyprintingsystem.A.I. Memo1102a,MITArtificial IntelligenceLaboratory, Cambridge,Massachusetts,August1989.Also appearsin editedform asChapter27of CommonLisp: TheLanguage, seconded.

12