The Software Concordance: Bringing Hypermedia to Software
Transcript of The Software Concordance: Bringing Hypermedia to Software
TheSoftwareConcordance:BringingHypermediatoSoftwareDevelopmentEnvironments
EthanV. Munson�
Departmentof ElectricalEngineering& ComputerScienceUniversityof Wisconsin-Milwaukee
Mil waukee,WI [email protected]
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