O L M Aarhus University B M Ericsson Research, Applied ...cs-exhibitions.uni-klu.ac.at/fileadmin/template/documents/text/betabook.pdf · The BETA project was initiated in 1976 as

OBJECT-ORIENTEDPROGRAMMING

INTHE BETA PROGRAMMING

LANGUAGE

OLE LEHRMANN MADSEN

AarhusUniversity

BIRGER MØLLER-PEDERSEN

EricssonResearch, AppliedResearch Center, Oslo

KRISTEN NYGAARD

Universityof Oslo

Copyright c�

1993by Ole LehrmannMadsen,BirgerMøller-Pedersen,andKristenNygaard.All rightsreserved.No partof this bookmaybecopiedordistributedwithout theprior writtenpermissionof theauthors

Preface

This is a bookon object-orientedprogrammingandtheBETA programminglanguage.Object-orientedprogrammingoriginatedwith theSimulalanguagesdevelopedat theNorwegianComputingCenter, Oslo, in the1960s.ThefirstSimulalanguage,SimulaI, wasintendedfor writing simulationprograms.Si-mula I waslaterusedasa basisfor defininga generalpurposeprogramminglanguage,Simula67. In additionto beinga programminglanguage,Simula1

wasalsodesignedasa languagefor describingandcommunicatingaboutsys-temsin general. Simulahasbeenusedby a relatively small communityformany years,althoughit hashada major impacton researchin computersci-ence.Therealbreakthroughfor object-orientedprogrammingcamewith thedevelopmentof Smalltalk. Sincethen,a large numberof programminglan-guagesbasedon Simulaconceptshave appeared.C++ is the languagethathashadthe greatestinfluenceon the useof object-orientedprogramminginindustry. Object-orientedprogramminghasalsobeenthesubjectof intensiveresearch,resultingin a largenumberof importantcontributions.

Theauthorsof this book,togetherwith BentBruunKristensen,havebeeninvolvedin theBETA projectsince1975,theaim of which is to developcon-cepts,constructsandtoolsfor programming.TheBETA languageis onemainresultof thisproject,thevariousstagesof whichhavebeendescribedin manydifferentreportsandarticles(Kristensenetal., 1976;1983a,b;1985;1987a,b;1988; Madsen,1987; Madsenand Møller-Pedersen,1988; 1989a,b;1992;Madsenet al., 1983).This bookcontainsa descriptionof theBETA languagetogetherwith theconceptualframework onwhich BETA hasbeenbased.

The Mjølner2 BETA Systemis a programmingenvironmentsupportingobject-orientedprogrammingin BETA. TheMjølner BETA Systemhasbeendevelopedby the Mjølner project (Dahleet al., 1986;Knudsenet al., 1992),which wasa cooperative Nordic projectwith participantsfrom Sweden,Nor-way, FinlandandDenmark. The Mjølner BETA Systemincludesan imple-mentationof BETA and a large numberof libraries and applicationframe-works. It alsoincludesaHyperStructureEditorandanobject-orientedCASE

1Simula67 waslaterrenamedto just Simula, which is usedin this book.2The nameMjølner is taken from Nordic mythology, whereMjølner is the nameof the

godThor’shammer. Accordingto mythology, thishammeris theperfecttool thatcannotfail,growswith thetask,andalwayscomesbackto Thor’shand.

v

vi PREFACE

tool for supportingdesignusingBETA. Thesystemis a commercialproductmarketedby Mjølner InformaticsA/S. AppendixB containsa moredetaileddescriptionof theMjølnerBETA System.ReadersshouldconsulttheMjølnermanualsfor further detailsbefore trying to run the examplesin this book.TheMjølner BETA Systemis currentlyavailablefor theMacintosh,andfor anumberof UNIX-basedworkstationsrunnningX-Window Systems.

Draft versionsof this bookandpre-releasesof theMjølner BETA Systemhave beenusedfor teachingobject-orientedprogrammingat theDepartmentof InformationandMediaSciences(IMV) andtheComputerScienceDepart-ment(DAIMI), bothatAarhusUniversity. At IMV, BETA is usedfor introduc-tory programmingandatDAIMI it is usedasasecondyearcoursein program-ming languages.They have alsobeenusedfor teachingat a numberof otherplaces,including theUniversitiesof Copenhagen,Oslo,BergenandOdense.Draft versionshave alsobeenusedfor BETA tutorialsgivenat theOOPSLA’89, ’90 and’91 conferences(Object-OrientedProgramming,Languages,Sys-temandApplications),at theTOOLS’91 and’92 conferences(TechnologyofObject-OrientedLanguagesandSystems),andat EastEurOOPe’91 (EastEu-ropeanConferenceon Object-OrientedProgramming).

The book is organizedas follows: Chapters1 and2 introducethe basicconceptsof object-orientedprogramming;Chapters3–12area descriptionofsubjectssuchasobjects,patterns,sequentialexecution,the virtual concept,block structureand proceduralprogramming. The multi-sequentialaspectsof BETA, including coroutinesand concurrency, are describedin Chapters13–15. Chapter16 dealswith exceptionhandling,Chapter17 describesthemodularizationof large programs,and Chapter18 presentsthe conceptualframework underlyingBETA. AppendixA includesagrammarfor BETA, andAppendixB givesa descriptionof theMjølner BETA System.

Whenreadingthebook, therearethreemainsubjectareasthatshouldbecoveredat thesametime:

� TheBETA language,Chapters3–16

� Modularization,Chapter17

� Theconceptualframework, Chapters2 and18.

It is recommendedthatreadersstartwith Chapters1–6;Chapter2 introducespartof theconceptualframework, andChapters3–6introducepartof BETA.

Chapter18, the main chapteron the conceptualframework, may thenbereadbeforereadingChapters7–16. Dependingon the reader’s previous ex-perience,it may be difficult to graspChapter18 on a first reading,so it isrecommendedthat this is readagainafter having readthe book’s remainingchapters.In a teachingsituationit is recommendedthat theconceptsdetailedin Chapter18arediscussedwhile readingtheremainingchaptersof thebook.

PREFACE vii

Chapter� 17,onmodularization,maybereadafterChapters3–6.In ateach-ing situationit is recommendedthat it is readassoonasthestudentshave towrite otherthanjust trivial programs.Experienceshows that,from thebegin-ning, studentsshouldbe trainedin splitting a programinto convenientmod-ules,includingtheseparationof interfaceandimplementation.

Acknowledgements

TheBETA projectwasinitiated in 1976aspartof whatwasthencalledTheJoint Language Project. Peoplefrom The Regional ComputingCenterandComputerScienceDepartmentat AarhusUniversity, the Institute for Elec-tronic Systemsat Aalborg UniversityCentre,andtheNorwegianComputingCenter, Oslo participatedin that project. The initiative for the project wastaken in theautumnof 1975by BjarnerSvejgaard,Directorof TheRegionalComputingCenter.

The BETA languagewas developedby the authorstogetherwith BentBruunKristensen.In addition,a large numberof peoplehave beeninvolvedin the developmentof BETA andthe Mjølner BETA System,including col-leaguesandstudentsatAarhusUniversity, TheNorwegianComputingCenter,Oslo University, Aalborg University, andMjølner Informatics. In particular,thecontributionsof DagBelsnesandJørgenLindskov Knudsenareacknowl-edged.

Developmentof theMjølner BETA Systemin theNordic Mjølner projecthasbeensupportedby TheNordicFundfor TechnologyandResearch.Partic-ipantsin theMjølner Projectcomefrom Lund University, Telesoft,EB Tech-nology, TheNorwegianComputingCenter, Telenokia,SyswareApS,AalborgUniversity and AarhusUniversity. The main implementorsof the MjølnerBETA SystemarePeterAndersen,LarsBak, JørgenLindskov Knudsen,OleLehrmannMadsen,Kim JensenMøller, ClausNørgaard,andElmerSandvad.In addition,KarenBorup, SørenBrandt, JørgenNørgaard,ClausH. Peder-sen,TommyThorn,PerFackSørensenandPeterØrbækhave participatedinvariouspartsof theimplementation.

The development of the Mjølner BETA System has been supportedthrougha contractwith Apple ComputerEurope,Paris. We are grateful toLarry Taylor for the greatsupporthe hasprovided for BETA. Developmentof the systemhasalsobeensupportedby a contractwith Apollo Computer,Finland,andby thedonationof workstationsfrom Hewlett-Packard.

Thedevelopmentof BETA andtheMjølner BETA Systemhasbeensup-portedby theDanishNaturalScienceResearchCouncil,grant. no. 11-3106,FTU 5.17.5.1.25,theDanishNaturalResearchCouncil, grant. no. 11-8285,theDanishResearchProgrammefor Informatics,grantnos. 5.26.18.29.(theDevise Project),The Royal Norwegian Council for ScientificandIndustrialResearch,grantno. ED 0223.16641(theScalaproject),andthroughtheEuro-

viii PREFACE

peanCommission’sEspritEuroCoOp(5303)andEuroCODE(6155)projects.We would like to thankcolleaguesandstudentsfor valuablecomments,

inspiringcriticisms,andthediscoveryof errorsin preliminaryversionsof thisbook.Kim Halskov MadsenandRandellTrigg deservespecialthanksfor theiruseof preliminaryversionsof thebook in teachingat IMV; their experienceandcommentshave hada large influence.Otherusefulcommentshave beenprovidedby BirgerAndersen,PeterAndersen,LarsBak,LoneFaber, CarstenHansen,Dag Helstad,AnetteHviid, JørgenLindskov Knudsen,Kim JensenMøller, ElmerSandvad,AlexandreValenteSousa,Kristine StougaardThom-sen,andthemany studentswhohavebeenexposedto previousversionsof thebook.

Wewould like to thankPeterWegnerfor hisusefulcommentsandencour-agementto write thisbookandSimonPlumtreeof Addison-Wesley for hispa-tience.During thepreparationof themanuscriptwe receivedgreathelpfromSusanneBrøndberg, KarenKjær Møller andtheproductionstaff at Addison-Wesley.

Theauthorswould like to thanktheir families(Ole: Marianne,Christian,Anne Sofie; Birger: Kirsten, Kamilla, Kristine; Kristen: Johannaand to amoderateextent childrenandgrandchildren).The BETA projectwould nothavebeenthesameandthisbookwouldnothavecomeinto existencewithouttheirpatienceandunderstanding,andwithouttheirparticipationin many livelygatherings3 throughouttheyears.

Ole LehrmannMadsenBirgerMøller-Pedersen

KristenNygaard

May 1993

3We alsothankthewhitewineproducersin Germany, France,Italy andCalifornia.

Contents

Preface v

1 Intr oduction 11.1 Benefitsof object-orientation. . . . . . . . . . . . . . . . . . 11.2 Object-orientedprogrammingandBETA . . . . . . . . . . . . 31.3 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Intr oduction to BasicConcepts 112.1 Perspectiveson programming. . . . . . . . . . . . . . . . . . 12

2.1.1 Proceduralprogramming. . . . . . . . . . . . . . . . 122.1.2 Functionalandconstraintprogramming . . . . . . . . 14

2.2 Object-orientedprogramming . . . . . . . . . . . . . . . . . 162.2.1 Manualsystems. . . . . . . . . . . . . . . . . . . . . 162.2.2 Computerizedphysicalmodels. . . . . . . . . . . . . 17

2.3 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Objects and Patterns 233.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Referenceattributes . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.1 Staticreferences . . . . . . . . . . . . . . . . . . . . 313.2.2 Dynamicreferences . . . . . . . . . . . . . . . . . . 323.2.3 Dynamicgenerationof objects. . . . . . . . . . . . . 333.2.4 Exampleof usingdynamicreferences. . . . . . . . . 343.2.5 Qualifiedreferencesandremoteaccess . . . . . . . . 35

3.3 Patternattributes . . . . . . . . . . . . . . . . . . . . . . . . 363.3.1 Self-reference. . . . . . . . . . . . . . . . . . . . . . 393.3.2 Procedure,functionandclasspatterns. . . . . . . . . 393.3.3 Basicpatterns. . . . . . . . . . . . . . . . . . . . . . 42

3.4 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

ix

x CONTENTS

4 Repetitions 474.1 Reallocation,assignmentandslice . . . . . . . . . . . . . . . 494.2 Thetext pattern . . . . . . . . . . . . . . . . . . . . . . . . . 514.3 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.4 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5 Imperati ves 535.1 Introductionto evaluations . . . . . . . . . . . . . . . . . . . 535.2 For-imperative . . . . . . . . . . . . . . . . . . . . . . . . . . 555.3 If-imperative . . . . . . . . . . . . . . . . . . . . . . . . . . 565.4 Labelsandjump imperatives . . . . . . . . . . . . . . . . . . 585.5 A largeexample. . . . . . . . . . . . . . . . . . . . . . . . . 595.6 Assignmentandequality . . . . . . . . . . . . . . . . . . . . 59

5.6.1 Equality . . . . . . . . . . . . . . . . . . . . . . . . . 655.6.2 Basicpatterns. . . . . . . . . . . . . . . . . . . . . . 66

5.7 Computedreferencesandcomputedremotename . . . . . . . 665.8 Detaileddescriptionof evaluations . . . . . . . . . . . . . . . 67

5.8.1 Objectevaluation . . . . . . . . . . . . . . . . . . . . 695.8.2 Evaluationlist . . . . . . . . . . . . . . . . . . . . . 705.8.3 Assignmentevaluation . . . . . . . . . . . . . . . . . 715.8.4 Valuerelations . . . . . . . . . . . . . . . . . . . . . 72

5.9 Block structureandscoperules . . . . . . . . . . . . . . . . . 725.10 Objectkindsandconstructionmodes. . . . . . . . . . . . . . 74

5.10.1 Objectkinds . . . . . . . . . . . . . . . . . . . . . . 755.10.2 Constructionmodesandinsertedobjects. . . . . . . . 755.10.3 Summaryof constructionmodes. . . . . . . . . . . . 76

5.11 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.12 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6 Sub-patterns 816.1 Specializationby simpleinheritance . . . . . . . . . . . . . . 816.2 Specializationof actions . . . . . . . . . . . . . . . . . . . . 906.3 Enter/exit-partsfor sub-patterns . . . . . . . . . . . . . . . . 956.4 Theobjectpattern. . . . . . . . . . . . . . . . . . . . . . . . 966.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.6 Qualificationsandscoperules . . . . . . . . . . . . . . . . . 99

6.6.1 Qualification . . . . . . . . . . . . . . . . . . . . . . 996.6.2 Scoperules . . . . . . . . . . . . . . . . . . . . . . . 100

6.7 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.8 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

CONTENTS xi

7 Virtual�

Procedure Patterns 1057.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.2 Declarationof virtual pattern . . . . . . . . . . . . . . . . . . 1097.3 Direct qualificationof virtual patterns . . . . . . . . . . . . . 1137.4 Continuedextensionof avirtual pattern . . . . . . . . . . . . 1147.5 More examplesof usingvirtual patterns . . . . . . . . . . . . 115

7.5.1 Specializationof initialization patterns. . . . . . . . . 1157.5.2 Computationof salaryfor differentjob types . . . . . 1167.5.3 Geometricfigures. . . . . . . . . . . . . . . . . . . . 1167.5.4 Definingcontrolabstractions. . . . . . . . . . . . . . 1167.5.5 Arithmetic expressions. . . . . . . . . . . . . . . . . 119

7.6 Benefitsof virtual patterns . . . . . . . . . . . . . . . . . . . 1197.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1217.8 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237.9 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

8 Block Structure 1278.1 Simpleblockstructure . . . . . . . . . . . . . . . . . . . . . 1278.2 Classgrammar . . . . . . . . . . . . . . . . . . . . . . . . . 1288.3 Flight reservationexample . . . . . . . . . . . . . . . . . . . 1318.4 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

9 Virtual ClassPatterns 1399.1 Directly qualifiedvirtual classpatterns. . . . . . . . . . . . . 1399.2 Generalparameterizedclasspatterns. . . . . . . . . . . . . . 1419.3 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

10 Part Objects and ReferenceAttrib utes 14510.1 Partobjects . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

10.1.1 Independentanddependentparts. . . . . . . . . . . . 14710.2 Referenceattributes . . . . . . . . . . . . . . . . . . . . . . . 14910.3 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15210.4 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

11 Pattern Variables 15511.1 Declarationof patternvariables. . . . . . . . . . . . . . . . . 15511.2 Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15811.3 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15911.4 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

xii CONTENTS

12 ProceduralProgramming 16312.1 Functionalclasses. . . . . . . . . . . . . . . . . . . . . . . . 16412.2 Higherorderprocedurepatterns . . . . . . . . . . . . . . . . 16912.3 Virtual classesandgenericity . . . . . . . . . . . . . . . . . . 170

12.3.1 Pureobject-orienteddefinitionof classRing . . . . . 17012.3.2 Functionaldefinitionof classRing . . . . . . . . . . . 17212.3.3 Classattributesversustypeattributes . . . . . . . . . 17412.3.4 More on extendingvirtual classes . . . . . . . . . . . 175

12.4 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

13 Deterministic Alter nation 17713.1 Executionstacks . . . . . . . . . . . . . . . . . . . . . . . . 180

13.1.1 Languageconstructsfor basiccoroutinesequencing. . 18313.2 Generators. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18713.3 Componentsandrecursiveprocedurepatterns . . . . . . . . . 18713.4 Abstractsuper-patterns . . . . . . . . . . . . . . . . . . . . . 189

13.4.1 Symmetriccoroutines . . . . . . . . . . . . . . . . . 19113.4.2 Quasi-parallelsystems . . . . . . . . . . . . . . . . . 193

13.5 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19413.6 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

14 Concurrency 20114.1 Concurrentexecutionof components. . . . . . . . . . . . . . 202

14.1.1 Simplesynchronization. . . . . . . . . . . . . . . . . 20214.2 Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

14.2.1 Monitor conditions . . . . . . . . . . . . . . . . . . . 20714.3 Directcommunicationbetweencomponents. . . . . . . . . . 209

14.3.1 Synchronizedcommunicationbetweencomponents. . 20914.3.2 Portscontrollingseveraloperations . . . . . . . . . . 21114.3.3 Restrictedacceptance. . . . . . . . . . . . . . . . . . 212

14.4 Compoundsystems. . . . . . . . . . . . . . . . . . . . . . . 21514.4.1 Indirectcommunicationbetweeninternalsystems. . . 21614.4.2 Communicationwith internalsystems. . . . . . . . . 217

14.5 Readersandwritersproblem . . . . . . . . . . . . . . . . . . 21814.6 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22114.7 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

15 Nondeterministic Alter nation 22515.1 Alternatingexecutionof components. . . . . . . . . . . . . . 22615.2 A distributedcalendar. . . . . . . . . . . . . . . . . . . . . . 22815.3 Boundedbuffer . . . . . . . . . . . . . . . . . . . . . . . . . 23115.4 A simplegame . . . . . . . . . . . . . . . . . . . . . . . . . 23215.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

CONTENTS xiii

16 Exception� Handling 23716.1 Simpleexceptions. . . . . . . . . . . . . . . . . . . . . . . . 23916.2 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24316.3 Partial recovery . . . . . . . . . . . . . . . . . . . . . . . . . 24416.4 Handlersfor procedurepatterns. . . . . . . . . . . . . . . . . 24416.5 Systemexceptions . . . . . . . . . . . . . . . . . . . . . . . 24616.6 Language-definedexceptions. . . . . . . . . . . . . . . . . . 24916.7 Advanceddesignof exceptionpatterns. . . . . . . . . . . . . 25016.8 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25316.9 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

17 Modularization 25517.1 Fragments. . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

17.1.1 Forms . . . . . . . . . . . . . . . . . . . . . . . . . . 25717.1.2 Slots . . . . . . . . . . . . . . . . . . . . . . . . . . 25817.1.3 Fragment-form . . . . . . . . . . . . . . . . . . . . . 25917.1.4 Fragment-group. . . . . . . . . . . . . . . . . . . . . 25917.1.5 Fragmentlibrary . . . . . . . . . . . . . . . . . . . . 26017.1.6 Origin of a fragment-group. . . . . . . . . . . . . . . 26117.1.7 Thebasicenvironment . . . . . . . . . . . . . . . . . 26217.1.8 Include . . . . . . . . . . . . . . . . . . . . . . . . . 26417.1.9 Body . . . . . . . . . . . . . . . . . . . . . . . . . . 265

17.2 Separationof interfaceandimplementation . . . . . . . . . . 26717.2.1 Abstractdatatypes . . . . . . . . . . . . . . . . . . . 271

17.3 Alternative implementations . . . . . . . . . . . . . . . . . . 27417.4 Programvariants . . . . . . . . . . . . . . . . . . . . . . . . 27617.5 Usingseverallibraries . . . . . . . . . . . . . . . . . . . . . 27817.6 Visibility andbindingrules . . . . . . . . . . . . . . . . . . . 27817.7 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28017.8 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

18 ConceptualFramework 28318.1 Physicalmodeling. . . . . . . . . . . . . . . . . . . . . . . . 28418.2 Informationprocesses. . . . . . . . . . . . . . . . . . . . . . 28718.3 Conceptsandabstraction . . . . . . . . . . . . . . . . . . . . 290

18.3.1 Phenomenaandconcepts. . . . . . . . . . . . . . . . 29018.3.2 Aristotelianview . . . . . . . . . . . . . . . . . . . . 29218.3.3 Prototypicalview . . . . . . . . . . . . . . . . . . . . 29318.3.4 Otherviewsof concepts . . . . . . . . . . . . . . . . 29418.3.5 Representingconceptsin BETA . . . . . . . . . . . . 295

18.4 Theabstractionprocess. . . . . . . . . . . . . . . . . . . . . 29518.5 Classificationandcomposition . . . . . . . . . . . . . . . . . 297

18.5.1 Classification. . . . . . . . . . . . . . . . . . . . . . 297

xiv CONTENTS

18.5.2 Composition . . . . . . . . . . . . . . . . . . . . . . 30018.6 Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30318.7 Representativeelementsof adescription . . . . . . . . . . . . 30418.8 Graphicalnotation . . . . . . . . . . . . . . . . . . . . . . . 30718.9 Elementsof amethod. . . . . . . . . . . . . . . . . . . . . . 308

18.9.1 Generalapproach. . . . . . . . . . . . . . . . . . . . 30918.9.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . 31018.9.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . 31118.9.4 Implementation. . . . . . . . . . . . . . . . . . . . . 313

18.10Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31318.11Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

A Grammar for BETA 315

B The MjØlner BETA System 321

Bibliography 323

Index 333

Trademark noticeMacintoshTM is a registeredtrademarkof AppleComputer, Inc.UNIXTM is a registeredtrademarkof AT&T Bell Laboratories.TheX Window Systemis a registeredtrademarkof MIT.Design/OA is a registeredtrademarkof MetaSoftwareCorporation,CambridgeMA, USA.SimulaTM is a trademarkof a.s.Simula.

Chapter 1

Intr oduction

This is first and foremosta book on the programminglanguageBETA, butit is alsoa book on object-orientedprogramming,andissuessuchasobject-orientedanalysisanddesignarealsocovered.

Introducinga programminglanguageis not just a matterof introducinglanguageconstructsand giving guidelinesand hints on how to use them.It is also a matterof introducinga way of thinking that is associatedwiththe underlying conceptualframework. For languagesbasedon well es-tablishedunderlyingconceptssuchas functions,relationsor equations,theway of thinking may be obtainedfrom other sources,and will often bepart of the backgroundandeducationof the prospective programmers.Forobject-orientedprogrammingthereis no well establishedtheoryor concep-tual framework. Furthermore,there is no establishedconsensuson whatobject-orientationis. Despitethis, a large numberof programmerspracticeobject-orientedprogramming.They usea numberof differentlanguagessuchas Simula (Dahl et al., 1968), Smalltalk (Goldberg andRobson,1989), C++(Stroustrup,1991), Eiffel (Meyer, 1988), and CLOS (Keene,1989). Theselanguageshave a commoncoreof languageconstructswhich to someextentmake themlook alike.

1.1 Benefitsof object-orientation

It is difficult to discussthebenefitsof object-orientationwithout first definingit. BeforeintroducingtheBETA approach,however, we shall briefly discusswhat the benefitsof object-orientationareconsideredto be. Therearethreemainbenefits:real world apprehension, stability of designandreusabilityofbothdesignsandimplementations.Whenpeopledisagreeaboutwhatobject-orientationis, it is oftenbecausethey attachdifferentlevelsof importancetotheseaspects.We considerall threeaspectsto be important,thoughperhapsnotequallyso.

1

2 INTRODUCTION

Real world apprehension

Oneof the reasonsthat object-orientedprogramminghasbecomeso widelyacceptedis that object-orientationis closeto our own naturalperceptionofthe real world. (KrogdahlandOlsen,1986) (translatedfrom Norwegian)putit this way:

‘The basicphilosophyunderlyingobject-orientedprogrammingisto maketheprogramsasfaraspossiblereflectthatpartof thereal-ity they aregoingto treat.It is thenofteneasierto understandandto getanoverview of what is describedin programs.Thereasonis thathumanbeingsfrom theoutsetareusedto andtrainedin theperceptionof what is goingon in therealworld. Thecloserit ispossibleto usethis way of thinking in programming,theeasieritis to write andunderstandprograms.’

In (CoadandYourdon,1990) it is statedin thefollowing way:

‘Object-orientedanalysisis basedupon conceptsthat we firstlearnedin kindergarten:objectsandattributes,classesandmem-bers,wholesandparts.’

Both of thesequotationsstressthat one importantaspectof programdevel-opmentis to understand,describeand communicateaboutphenomenaandconceptsof theapplicationdomain.Object-orientedprogramminghasturnedout to beparticularlywell suitedfor doingthis.

Stability of design

The principle behind the JacksonSystem Development (JSD) method,(Jackson,1983)alsoreflectsoneof thebenefitsof object-orientation.Insteadof focusingon thefunctionalityof a system,thefirst stepin thesystem’s de-velopmentaccordingto JSD is to make a physicalmodelof the real worldwith which thesystemis concerned.This modelthenformsthebasisfor thedifferentfunctionsthatthesystemmayhave. Functionsmaylaterbechanged,andnew functionsmaybeaddedwithoutchangingtheunderlyingmodel.

As we shall seelater, the notion of a physicalmodel as introducedbyJSDis centralto object-orientationasdescribedin this book. The conceptsandtechniquesusedby theJSDmethodto developa physicalmodel,andtosubsequentlyimplementit onacomputerare,however, quitedifferentfrom theconceptsandtechniquesof object-orientedprogrammingaspresentedin thisbook. As mentionedabove, object-orientedprogrammingprovidesa naturalframework for modelingtheapplicationdomain.

1.2 OBJECT-ORIENTEDPROGRAMMING AND BETA 3

Reusability�Onewell known problemwith softwaredevelopmentis beingable to reuseexisting softwarecomponentswhendevelopingnew ones.The functionalityof anexistingcomponentis oftenverysimilar to oneneededfor anew system.Theremay, however, be importantdifferenceswhich make it impossibletoreusetheexistingcomponent.For this reason,thenew componentis oftenim-plementedby copying andmodifying theexisting component,but this meansthat it mustbe testedagain. More problematic,however, is that the relationsbetweenthe old andnew componentsmay be lost: if an error is detectedinone,it mustbecorrectedin both.Also,changesto commonpartsof thesystemmayhave to beperformedin bothcomponents.

Oneof thebenefitsof object-orientedprogramminglanguagesis thattheyhave strongconstructsfor supportingincrementalprogrammodification.It ispossibleto defineanew componentasanincrementalextensionof anexistingone,thuspreservingtherelationsbetweenthetwo components.Most object-orientedlanguagesarebasedon the class/subclassmechanism(inheritance)which first appearedin Simula. Oneof the main contributionsof Smalltalkwasthattheselanguageconstructswerecombinedwith theflexibility of Lispsystems.

Even without the flexibility of Smalltalk, the ability to createprogramsby meansof incrementalextensionis consideredto bethemainadvantageofobject-orientedprogrammingby many programmers.Thedisadvantageof in-crementalmodificationis that the library of componentsreflectsthe historicdevelopmentof thosecomponents.In addition, the relationsbetweencom-ponentsaremainly dictatedby maximalcodesharing,oftenconflicting withthemodelingrequirementsdiscussedabove. Thesepotentialconflictsbetweenrequirementswill bediscussedlater.

1.2 Object-oriented programming andBETA

To program is to understand: The developmentof an informationsystemis not just a matterof writing a programthatdoesthe job. It is of theutmostimportancethat developmentof this programhasrevealedan in-depthun-derstandingof theapplicationdomain;otherwise,theinformationsystemwillprobablynotfit into theorganization.Duringthedevelopmentof suchsystemsit is importantthatdescriptionsof theapplicationdomainarecommunicatedbetweensystemspecialistsandtheorganization.

Theapproachto object-orientedprogrammingpresentedin this bookem-phasizesthe modelingcapabilities. Most treatmentsof object-orientedpro-grammingare concernedwith languageconstructs,and thosefamiliar with

4 INTRODUCTION

the literaturewill know that conceptslike inheritanceand messagepassingareimportantconsiderations.Thereis, however, moreto object-orientedpro-grammingthanlanguageconstructs(this shouldbetruefor any programminglanguage).Theunderlyingconceptualframework or semanticsis just asim-portantasthelanguage.

Otherprogrammingperspectivesarebasedon somemathematicaltheoryor model,giving thema soundtheoreticalbasis,but object-orientedprogram-minglacksaprofoundtheoreticalbasis.For object-orientedprogramming,theinitial observation of how peopleunderstandthe world hasto be formulatedin a theoryor conceptualframework. For thebenefitof designinga program-ming language,and for the benefitof conveying an understandingof thesebasicconceptsaspart of a book on the language,this modeldoesnot haveto be formal. In fact, the modelunderlyingobject-orientationis by its verynatureinformal, althoughpart of the modelhasbeenformalizedin termsofprogramminglanguages.This is necessaryin orderto createdescriptionsthatmaybeexecutedon a computer. BETA maybeseenasa formal notationfordescribingthosepartsof theapplicationdomainthatcanbeformalized:BETAis formal in thesensethatdescriptionsmadein it haveaprecisemeaningwhenexecutedonacomputer. Often,aprogramminglanguageis definedin termsofa mathematicalmodel,yet sucha modelhasnot beenconstructedfor BETA,althoughit mightbeusefulfor thepurposeof consistency checkingandformalverification.

This book attemptsto go beyond languagemechanismsand contributea conceptualframework for object-orientedprogramming.This framework,however, needsfurtherdevelopment.

Weshallintroducethenotionsof physical modeling, to capturemodelingof partsof theworld basedupontheidentificationof phenomenaandconcepts,andthenotionof thephysical model, to denotethemodelsthatarecreatedinthis process.

Theuseof informalconceptsin thesystemdevelopmentprocessis impor-tant, however, thereis a tendency to put a greateremphasison the conceptsthat canbe formulatedin termsof a programminglanguage.The reasonisclear, sincethe systemdevelopmentprocesseventuallyhasto result in a de-scriptionthatcanbeexecutedonacomputer. Thisbookalsoemphasizescon-ceptsthat canbe describedin BETA. Below we briefly summarizethe roleof BETA in thesystemdevelopmentprocess.Traditionally, systemdevelop-mentis organizedinto analysis, designandimplementation, andtheconceptsof object-orientationmaybeappliedto all of theseactivities.

� Analysis.Theprimarygoalof analysisis to understandtheapplicationdo-main.In thisactivity, relevantconceptsandphenomenafromtheapplicationdomainmustbeidentifiedanddescribed,usuallyinvolving thesystemto bedeveloped.For this reason,it is importantthattheconceptsandphenomenaidentifiedcanbe communicated.In this processit is useful to usea high


number� of informal descriptions,sinceit would otherwisebequitedifficultto communicatethosedescriptionsto noncomputerspecialists.Theinfor-mal descriptionsmayconsistof a mixtureof text, graphics,andsometimesalsoincompleteprogramfragments.Theuseof graphicsin systemdescrip-tions is important,particularly in analysisas it might be importantto usegraphicalnotationfor partof thedescriptions.

� Design. The designactivity is concernedwith constructinga precisede-scriptionthatcanberefinedinto anexecutableprogram.Heretheinformalconceptsdevelopedin the analysisactivity have to be madeinto formalconceptsthatcanbedescribedby a programminglanguagelike BETA. Atthis level the object-orientedprogramwill be a descriptionof phenomenaandconceptsfrom the applicationdomain. Sucha programwill be fairlyabstract,sinceit will includeanumberof elementsthatneedfurtherrefine-mentbeforeit canbeexecuted.It is, however, importantthatthedescriptionis relevantfor theapplicationdomain.

Graphicalnotationmayalsobeusefulin thedesignactivity. Mostprogram-minglanguageslikeBETA haveatextualsyntax,but it mayoftenbeadvan-tageousto usegraphicalnotationsfor partof theprograminsteadof textualrepresentation.Later we shall discusshow the sameunderlyinglanguageprinciplesmaybepresentedbothgraphicallyandtextually.

Analysisanddesignaresimilar in the sensethat the descriptionsmustbemeaningfulin termsof the applicationdomain. They are different withrespectto theiruseof informalandformaldescriptions.

� Implementation.This is concernedwith implementingthe designdescrip-tion on a computer, i.e. elementsrepresentingconceptsand phenomenafrom the applicationdomainmustbe describedin termsof conceptsthatcanbe executedon the computer. Thesecomputerconceptsdo not repre-sentconceptsandphenomenafrom theapplicationdomain,i.e. theprogramis extendedwith detailsthataremeaninglessin theapplicationdomain.Thebasicprinciplesof the two levels are the same;it is programming,but atdifferentlevels.

Designandimplementationaresimilar in thesensethataprogramminglan-guageis usedfor thedescriptions.They differ in thesensethattheelementsof a designdescriptionmustbemeaningfulin termsof theapplicationdo-main,whereasthis is not thecasefor animplementationdescription.

Systemdevelopmentmethods

The above descriptionof analysis,designand implementationmay give theimpressionthattheseactivities areorderedin time (i.e. first analysis,thende-sign,andfinally implementation),but this is not thecase.In somesituationstheseactivities may be intermixed, andthe developermay not be conscious

6 INTRODUCTION

of them. Thereare variousmethodsof organizingthe systemdevelopmentprocesswhich differ in a numberways. The object-orientedframework pre-sentedin this book is not associatedwith any specificmethod,althoughit isnot completelyindependent(we returnto this in Chapter18).

Logical versusphysical systemstructure

BETA is a languagefor describingasystem(programexecution)consistingofobjectsandpatterns,someof which representphenomenaandconceptsfromthe applicationdomain,and otherswhich are for implementationpurposes.TheBETA objectsandpatternsprovide the logical structure of a system;theBETA languageprovidesmechanismsfor describingthis logical structure.

A BETA program(or BETA description)is usuallyconstructedin theformof text in oneor morefiles. The programmay exist in a numberof variantsfor differentcomputers,andit may exist in variousversions.Part of it mayconsistof modulesincludedfrom a library; partmaybeusedin many differ-entprograms.TheBETA languagedoesnot have mechanismsfor describingthe physicalorganizationof a BETA programin termsof files, variants,andversions,etc.,becausethephysicalstructureof theprogramtext is consideredto be independentof the logical structureof the program. Somelanguagesprovide languageelementsfor handlingthe physicalstructure,e.g.modulesareoften divided into interfaceand implementationmodules. Suchmecha-nismsarenot a partof BETA. Instead,a language-independenttechniquefororganizingthephysicalstructureof a programtext hasbeendeveloped.Thistechniqueis basedon the context free grammarof the language,whereanycorrectsequenceof terminalandnonterminalsymbols(a so-calledsententialform) of thegrammarcanbea module. This techniquecanbe usedfor lan-guagesotherthanBETA. Chapter17 describestechniquesfor organizingthephysicalstructureof aBETA program.

Thereareaspectsof the physicalstructureotherthanorganizationof theprogramtext. A BETA systemconsistsof a numberof objectsexecutingac-tions,andtheactionsexecutedby objectsmaytakeplaceconcurrently.

Someof theobjectsof a BETA systemaretransientin thesensethattheyonly exist while theprogramis executing.Otherobjectsarepersistentin thesensethatthey maybestoredon secondarystoragesuchasadiskandsurvivethe programthat createdthem. They may then be readand usedby otherprograms. The separationof objectsinto transientandpersistentobjectsisnot partof theBETA language,but is handledby theMjølner BETA System.An object-orienteddatabasesystemsupportingclient andserversis currentlybeing developedon top of the persistentobject storeof the Mjølner BETASystem.

Modern computerhardware often consistsof a large numberof proces-sorsconnectedthroughsomecommunicationmedia,an examplebeinga set


of workstations� connectedthrougha local areanetwork. Theconcurrency de-scribedin a BETA programmayberealizedthroughtime sharingon a singleprocessor, or by distributing theactive BETA objectson a numberof proces-sors. BETA hasconstructsfor describingthe logical structureof concurrentobjects,andthephysicalstructureof mappingconcurrentobjectsontoseveralprocessorsis consideredindependentof the language. The Mjølner BETASystemcontainssomesupportfor distributedcomputingin BETA.

For thephysicalstructure,only modularizationis describedin this book.Themappingof aBETA systemontoaprocessgenerator(computerhardware)in termsof splitting objectsinto transientandpersistentobjects,andthedis-tribution of objectsontoseveralprocessors,is not dealtwith in this book(seetheMjølner BETA Systemmanualsfor thecurrentstatusof this).

Although the main emphasisin this book is on the logical structureof asystem,thedesignandimplementationof thephysicalstructureis equallyim-portant.During designandimplementation,theprogrammermustbeexplicitaboutthe physicalorganizationof the programtext, as describedin Chap-ter 17, andshouldbe concernedwith the organizationof persistentanddis-tributedobjects.

BETA

BETA is a modernlanguagein the Simula tradition. It supportsthe object-orientedperspective on programmingand containscomprehensive facilitiesfor proceduraland functionalprogramming. Researchis going on with theaimof includingconstraint-orientedconstructs.

BETA replacesclasses,procedures,functionsand typesby a single ab-stractionmechanismcalledthe pattern. It generalizesvirtual procedurestovirtual patterns,streamlineslinguisticnotionssuchasnestingandblockstruc-ture,andprovidesa unified framework for sequential,coroutineandconcur-rentexecution.Theresultinglanguageis smallerthanSimulain spiteof beingconsiderablymoreexpressive.

The Mjølner BETA Systemis a softwaredevelopmentenvironmentsup-porting the BETA languagewhich includesan implementationof the BETAlanguageasdescribedin this book. In addition,thesystemincludesa numberof othertools,anda largecollectionof librariesandframeworks thatgreatlyenhanceBETA’s usabilityby providing a largenumberof predefinedpatternsand objects. (The libraries and frameworks are not describedin this book,thoughashortintroductionis givenin AppendixB. For adetaileddescriptionseetheMjølnerBETA Systemmanuals.)

TheMjølnerBETA Systemwasoriginally developedaspartof theNordicMjølner project, which hasalso produceda large numberof other results.(Knudsenet al., 1992) is acollectionof theproject’smainresults.

8 INTRODUCTION

1.3 Notes

In the early 1960s,the Simula I languagewas introducedwith the purposeof writing simulationprograms. In the late 1960s,a generalprogramminglanguage,Simula67, wasdefined,the importantcontribution of which wasthe introductionof the classandsub-classconceptsandthe notionof virtualprocedures.Theseconstructshave becomethe coreof mostobject-orientedlanguages.WhereasSimulaI wasa simulationlanguage,Simula67 is a gen-eralprogramminglanguagethatsupportssimulationby meansof ageneralsetof classes.This demonstratedthepower of theSimulaconcepts.InstancesofSimula classesbehave like coroutines,making it possibleto simulatecon-currency, which was heavily usedin the simulationpackage. Despitetheusefulnessof coroutinesandquasi-parallelsequencingfor modelingreal-lifephenomena,theseconceptshave not yet found their way into most object-orientedlanguages.For a further descriptionof the history of Simula, see(NygaardandDahl,1981).

Simula hasbeenusedby a relatively small communityfor many years.In theearly1970s,theclass/sub-classconceptswereusedin thedesignof theSmalltalklanguage,leadingin turnto amajorbreakthroughfor object-orientedprogramming.TheSmalltalkstyleof programminghasparticularlycaughtonin Lisp communities,resultingin a numberof substantialcontributions likeFlavors(Cannon,1982), andLoops (Bobrow andStefik,1983).

The object-orientedideashave alsostartedto impacton traditionalsoft-wareconstruction,themostinfluentialseemingto beC++. Anothercontribu-tion is Eiffel.

In the 1970s,muchattentionwasgiven to the notion of structured pro-gramming. Thediscussionsof object-orientedprogrammingin theliteraturemay be comparedto that of structuredprogramming. Structuredprogram-ming wasoftenassociatedwith avoiding goto’swhenprogramming,yet thereis clearlymoreto structuredprogrammingthanavoidinggoto’s,justasthereismoreto object-orientedprogrammingthaninheritanceandmessagepassing.

The label ‘object-orientation’ is attachedto many things. Peopletalkaboutobject-orientedprogramming,object-orienteddesign,object-orientedimplementation,object-orientedlanguages,object-orienteddatabases,etc.Object-orientationhasstartedto be appliedto theseactivities, i.e. conceptssuchas object-orientedanalysis,object-orienteddesignand object-orientedimplementationhave arrived. Often, object-orientedprogrammingis as-sociatedwith object-orientedimplementation. The reasonfor this is thatobject-orientationoriginatedfromprogramminglanguagessuchasSimulaandSmalltalk.In thisbook,object-orientedprogrammingis meantto coverobject-orientedanalysis,object-orienteddesignandobject-orientedimplementation.

Object-orientationhas also generatedparticular interest in the areaofdatabasesystems.A bookonobject-orienteddatabasesshouldcover thesame

1.3 NOTES 9

material� asthisbook,sincethebasicprinciplesarethesame.A databasebookmightpaymoreattentionto thehandlingof largesetsof information.Databasedesignandprogrammingarebothrelatedto modeling/representingrealworldphenomena.

A programminglanguageis oftencharacterizedasanobject-orientedlan-guage,afunctionallanguage,aprocedurallanguage,etc.Also, thetermmulti-perspective (or multi-paradigm ) languageis usedfor languagessupportingmorethanoneperspective. Oftentheterm‘object-orientedlanguage’is usedexclusively for languagesthatonly supportobject-orientation.In thisbook,anobject-oriented language is a programminglanguagethat supportsobject-orientedprogramming,anda pure object-oriented languageis a program-ming languagethat only supportsobject-orientation. The samedefinitionsapplyto otherperspectives.

10 INTRODUCTION

Chapter 2

Intr oduction to BasicConcepts

In thischapterwebriefly andinformally introducesomeof thebasicconceptsunderlyingobject-orientedprogramming.They arefurther explainedduringthe introductionof the BETA languagein subsequentchapters,anda moredetailedtreatmentis givenin Chapter18.

A computerexecutingaprogramgeneratesaprocessconsistingof variousphenomena(an exampleof a phenomenonis an object representinga bankaccountof somecustomer).Suchan object representscertainpropertiesoftherealbankaccount,like its balance,anda list of depositsandwithdrawalsperformedon theaccount.Theobjectsresidein thecomputer’smemory.

In therealworld, customersandbankclerksperformactionsthatchangethe stateof the variousbankaccounts.At a certainpoint, the balanceof agiven accountmay be DKK 5000, but a depositof DKK 105 will changeits balanceto DKK 5105. A depositis oneexampleof an actionperformedin a bank; otherexamplesare the withdrawal of money, the computationofinterest,openingandclosingof accounts,etc. It is importantto be awareofthe fact thatactionsareorderedin time – in mostbanksyou have to depositsomemoney beforeyoucancarryoutawithdrawal.

Theprocessgeneratedby thecomputerhasphenomenarepresentingtheseactionsandstates.Thestateof abankaccountis representedby theobjectrep-resentingthebankaccount,andactionschangingthestateof thebankaccountarerepresentedby actionsexecutedby thecomputer.

For a setof objectsrepresentinga banksystem,we may be interestedinmeasuringpart of the stateof several accounts,which could, for instance,consistof computingthebalanceof all agivencustomer’saccounts.

A processgeneratedby a computerexecutinga programis calleda pro-gram execution. Programexecutionsbelongto a classof processescalledinformationprocesses. The productionprocessof carsin a factory, the pro-cessingof customerordersin a company, andthemoney flow betweenbanksmaybeviewedasinformationprocesses.

Thestudyof informaticsor computerscienceis concernedwith thestudy

11

12 INTRODUCTION TO BASIC CONCEPTS

of information processes.This book will develop a conceptualframeworkfor understandingand describinginformation processes,in particularbeingconcernedwith programexecutions. In Chapter18 we return to the moregeneralnotionof informationprocesses.

BETA is aprogramminglanguage for describingprogramexecutions,andthemainpartof thisbookis aboutBETA.

2.1 Perspectiveson programming

To understandobject-orientedprogrammingit is necessaryto understandhowit relatesto otherperspectiveson programming.The purposeof this sectionis to giveashortintroductionto someof themostgenerallyacceptedperspec-tives, thoughit is not intendedto be a completedescriptionof the subject.Readersareencouragedto consultotherreferencesfor this purpose.

In theliterature,a largenumberof programmingperspectives,suchaspro-cess,typesystemandeventperspectivesarediscussed,becauseprogrammershave differentperspectiveson programming(in principle, eachprogrammermay have his own perspective). Also, the definitionsof perspectivesgivenbelow might not coincidewith what other peopleunderstandby theseper-spectives.

2.1.1 Proceduralprogramming

Whencomputerswereinventedthey wereviewedasprogrammablecalcula-torsandmany peoplestill hold this view.

Considerasimplecalculator. It mayconsistof aregisterfor storingavalue,andanumberof operationssuchasadd,sub,mult anddiv. It is possibleto en-tera numberinto theregisterandthenmodify this valueusingtheoperations.Thefollowing is a list of possibleoperationsfor asimplecalculator:

enter Vadd Vsub Vmult Vdiv Vresult

The operationsenter, add, sub, mult, div and result correspondtobuttonsonthecalculator;V correspondsto anumberenteredthroughanumberpad. We arenot concernedwith thephysicallayoutof thecalculatorhereasweareonly interestedin its functionality.

Insteadof oneregisterthe calculatormay have several registers,thusin-termediateresultsof acalculationmaybestoredin theseregisters– with only

2.1 PERSPECTIVESON PROGRAMMING 13

one re gister the userwould have to write down intermediateresultson pa-per. Assumethatour calculatoris extendedwith registersR0, R1, R2, ...Rn, andthatthepreviousoperationsoperateonR0. Wehavethefollowing newoperations:

enter V Riadd Ri Rjsub Ri Rjmult Ri Rjdiv Ri Rjcopy Ri Rj

TheoperandsRi andRj correspondto buttonsfor selectinga register.A calculatorwith a fixednumberof registersandoperationshasa limited

scopeof applications.Oftentheuserhasto carryout thesameprocedureoverandover againon differentdata,perhapscarryingout the samesequenceofoperations.This leadto theideaof aprogrammablecalculator. In additiontodataregistersandoperations,a programmablecalculatorhasa storewhereasequenceof operationsmaybestored:

define Pi Op1; Op2; ... endcall Pi

Thedefine andcall operationscorrespondto buttonsfor definingandcall-ing procedures.Pi couldbea numberor anotheruniqueidentificationof theprocedurebeingdefined.Our programmablecalculatorcould be usedin thefollowing way:

define P1: copy R0 R1; mult R0 2; add R0 R1 endenter 100call P1return

Thestoreusedfor storingproceduresmayalsobeusedfor storingvalues,i.e.it is possibleto move a valuefrom a registerto thestore,andvice versa. Inthis way, it is possibleto savea largenumberof intermediateresults.

In theabove examplesit waspossibleto definea procedureby meansofa sequenceof operations,but for many typesof calculationsthis is too primi-tive. Theoperationsmaybeextendedwith controlflow operations,makingitpossibleto selectfrom betweensub-sequencesof operationsandto repeattheexecutionof a sub-sequence.Thefollowing is anexampleof possiblecontrolflow operations:

L:goto Lif Ri=0 goto L


Thefirst computerswerejustadvancedprogrammablecalculatorswith a largenumberof registers,a large storefor saving proceduresanda suitablesetofbasicoperations.

With programmablecalculatorsit is possibleto solve large calculations;with computers,evenlargeronescanbesolved.

One problemwith our programmablecalculatoris that the programmermustkeeptrackof whichpartof thestoreis usedfor valuesandwhichpartforprocedures.To help,asymbolicassemblermaybeused,whereit is possibletodeclarea numberof variablesby meansof names.Theassemblerallocatesamemorycell correspondingto eachvariable,sotheprogrammercanthenreferto a variable/registerby nameinsteadof by anumber.

It is, however, difficult andtime consumingto write proceduresusingthesimplelanguageof thecomputer. Instead,ahigh-level programminglanguagemay be used. A compiler is usedto translatea programwritten in the pro-gramminglanguageinto thelanguageof thecomputer. Thefirst programminglanguageshad facilities for definingvariablesandprocedures(variablesaresimply registers).Insteadof afixednumberof registers,theprogrammermaydefinethenumberof variablesneeded,which is, of course,limited by thesizeof the store. We do not go into further detail aboutprogramminglanguageshere,sincethis will bedealtwith in therestof thebook.

Despitethe fact that thereis a hugedifferencebetweensimple calcula-torsandmoderncomputers,a computeris still viewedby mostprogrammersasan advancedcalculator. Whenwriting a program,the programmerthinksof defininga setof variablesanda setof proceduresfor manipulatingthesevariables.This perspectiveon programmingis calledprocedural (or impera-tive) programming. In summary, proceduralprogrammingmaybedefinedasfollows:

Procedural programming. A programexecutionis regardedasa (partiallyordered)sequenceof procedurecallsmanipulatingvariables.

As mentionedabove, proceduralprogrammingis still themostcommonper-spective on programming,supportedby languageslike Algol (Naur, 1962),Pascal(JensenandWirth, 1975), C (KernighanandRitchie, 1978) and Ada(USDepartmentof Defense,1980). It is in no wayobsolete,still beingusefulfor writing smallproceduresand,asweshallseelater, it maybeusedtogetherwith object-orientedprogramming.

2.1.2 Functional and constraint programming

Sincethemid-1960s,a largeresearcheffort hasbeendirectedtowardsgivinga mathematicaldefinitionof programminglanguages.Onemainresultof thisis thenotionof functionalor (applicative) programming. Whentrying to give

2.1 PERSPECTIVESON PROGRAMMING 15

amathematical� definitionof programminglanguages,it turnedout thattheno-tions of ‘variable’ and‘assignment’werethe main bottlenecks.In practice,many programmershave realizedthatwhenwriting largeprogramsit is diffi-cult to handlethelargenumberof variables.Oneresponseto this is functionalprogramming,in which a programis viewed asa mathematicalfunction. Aprogramis thenacombinationof mathematicalfunctions.

A languagesupportingfunctionalprogrammingmust,then,includefacili-tiesfor definingmathematicalfunctions,includinghigherorderfunctions,i.e.functionsthat may have functionsasparametersandreturn functionsas re-sults.In addition,sucha languageshouldincludedatatypescorrespondingtomathematicaldomains.

Lisp is anexampleof a languagewith excellentsupportfor functionalpro-gramming.However, Lisp is notapurefunctionalprogramminglanguageasitsupportsotherperspectivesaswell, includingproceduralandobject-orientedprogramming.ML andMirandaareexamplesof purefunctionallanguages.

Themostprominentpropertyof thefunctionalperspective is thatthereareno variablesandno notionof state.A variablemayonly beboundonceto avalue,andit is not possibleto assigna new valueto avariable.

To summarize,functionalprogrammingmaybedefinedasfollows:

Functional programming. A programis regardedasa mathematicalfunc-tion, describinga relationbetweeninputandoutput.

Like proceduralprogramming,functionalprogrammingshouldbe seenasasupplementto proceduralandobject-orientedprogramming. It is useful fordescribingstatetransitionswheretheintermediateresultsareirrelevant.

The notion of functional programminghasbeengeneralizedfurther. Afunctionis a relationwhich is uniquein its first element.Insteadof just view-ing aprogramasa functionalrelation,it might aswell beviewedasa generalrelation(orasetof equations).Thisis theideaof so-calledlogicprogramming,rule-basedprogramming, or asweshallcall it here,constraint programming:

Constraint programming. A programis regardedasa setof equationsde-scribingrelationsbetweeninput andoutput.

Thisconstraint-orientedperspective is supportedby, for example,Prolog.We shallnot go into furtherdetailson functional-andconstraint-oriented

programming(readersare encouragedto consult (Wikstrm, 1987; Leler,1987). It is importantto stressthatdifferentperspectivesshouldnot excludeeachother– they areeachuseful for differentpurposes,anda programmershouldhave the possibility of usinga given perspective whenrelevant. Theidealprogramminglanguageshouldintegratethedifferentperspectives. It isimportantto be awarethat this shouldnot be doneby designinga languageconsistingof featuresfrom variousprocedural,functionalandobject-oriented


languages.A programminglanguageshouldbebasedon a conceptualframe-work, and the languageconstructsshouldbe designedwith respectto thisframework.

2.2 Object-oriented programming

This sectiongivesan informal introductionto object-orientedprogramming,definedasfollows:

Object-oriented programming. A programexecutionis regardedasa phys-ical model,simulatingthebehavior of eithera realor imaginarypartoftheworld.

The notion of a physicalmodel shouldbe taken literally. Most peoplecanimaginetheconstructionof physicalmodelsby meansof, for example,Legobricks. In the sameway, a programexecutionmay be viewed asa physicalmodel.Otherperspectiveson programmingaremadepreciseby someunder-lying modeldefiningequations,relations,predicates,etc. For object-orientedprogramming,however, wehave to elaborateon theconceptof physicalmod-els.

Physicalmodelsarenot just relevant for computers.In the following wegiveexamplesof physicalmodelswherecomputersarenot involved.

2.2.1 Manual systems

In many areasit is commonto make a physicalmodelof someconstructionso asto observe somepropertiesbeforethe ‘real thing’ is constructed.Thisis the casewith buildings: beforeconstructinga large building, a model isusuallymadeto checkvariouspropertiesof thedesign.This is alsothecasefor bridges,cars,trains,aeroplanes,etc.

Whenbuilding a railway systemit is commonto modelit usinga modeltrainset.Suchamodelmaysimulatemany of thepropertiesof the‘real’ trainsystem.The following is a descriptionof how manualtrain seatreservationwashandledin Norway (andprobablyin othercountriesaswell) beforecom-puterswereinvented.Manualtrain seatreservationswerebasedon a numberof sheetsrepresentingthe wagonsin the train. The upperpart of Figure2.1showsthecollectionof sheets,andthelowerpartshowsexamplesof two suchsheets.Theseatscouldbechecked,or thepartof thetrip wheretheseatwasoccupiedcouldbeindicated.Travelersweregivensmallticketsindicatingthedetailsof their reservation.

Sucha train reservation systemis an exampleof what we considerto bea physicalmodel. Eachwagonin a train is representedby a sheet,which in-cludesthosepropertiesof thewagonthatareessentialfor seatreservation.The

2.2 OBJECT-ORIENTEDPROGRAMMING 17

Carriage no. 16 Carriage no. 17

Figure 2.1 Manualseatreservationsystem.

systemwasflexible in termsof thekindsof serviceswhichcouldbesupplied,e.g.thereservationof aseatnext to anotherseat,thereservationof aseatcloseto thedoor, etc.,wereall possible.Entrieswereof coursewritten in pencil toallow easyupdating.Thereservationsheetswerekeptat thetrain’s departurestationsothey couldbesentwith theguard.

Hospitalsprovide anothersuchexample. At a hospitala medicalrecordcorrespondingto eachpatientkeepstrack of the relevant informationrelatedto that patient. This recordmay be consideredto be a representationof thepatient.

2.2.2 Computerized physical models

In theabove examples,differentkindsof physicalmaterialareusedfor con-structingthe physicalmodel. In computerizedphysicalmodels,objectsarethe materialusedfor representingphysicalphenomenafrom the application


domain. Objectsare thus consideredas similar to cardboard,sheets,Legobricks,etc.,in thesensethatobjectsarephysicalmaterialthatmaybeusedforrepresenting(or modeling)physicalphenomena.Objectsare computerizedmaterial. In this way, objectsdiffer from materialsuchascardboard,paper,Legobricks,etc.

An objectis a pieceof physicalmaterialthatmaybeusedto represent(ormodel)a realor imaginaryphenomenonfrom theapplicationdomain.Some-times we say that an object representsa phenomenonfrom the applicationdomain,andsometimeswesaythatanobjectmodelsaphenomenon.

In thefollowing we presentexamplesof differentkindsof propertiesusedto characterizephenomena,andexplainhow they arerepresentedasobjects.

Object attrib utes

Objectsarecharacterizedby variousattributes, whichrepresent/modelaprop-ertyof thephenomenonbeingmodeled.Therearedifferentkindsof attributeswhich may be associatedwith objects. In the following someexamplesaregiven.

In aflight reservationsystemtherewill typically beanobjectrepresentingeachreservation. Thepropertiesof a reservationmayincludethedatefor theflight, a referenceto thecustomer, thesourceanddestinationof theflight, etc.An objectrepresentingareservationwill thenhaveattributescorrespondingtotheseproperties.An objectcorrespondingto a medicalrecordwill typicallyincludeattributesrepresentingpropertiessuchas the temperatureandbloodpressureof thepatient,etc. Propertieslike thesearecalledmeasurableprop-erties.

A measurablepropertymayvary with time. The temperatureof a patientmay be differentat differentpoints in time. An objectmust thusbe abletorepresentthis variation,i.e. at differentpointsin time the attributemodelingmeasurablepropertiesmustresultin differentvalues.An objectis saidto haveastate. Thestateof anobjectvarieswith time.

Object actions

Many real world systemsarecharacterizedby consistingof phenomenathatperformtheirsequencesof actionsconcurrently. Theflight reservationsystemconsistsof severalconcurrentphenomena,e.g.flights andagents.Eachagentperformsits taskconcurrentlywith otheragents.Flightswill registerthe re-servation of seatsandensurethat no seatsarereserved by two agentsat thesametime. Note that this kind of concurrency is an inherentpropertyof therealitybeingmodeled;it is not concurrency usedto speedupcomputations.

Complex taskssuchasthoseof theagentsareoftenconsideredto consistof several more or lessindependentactivities. This is so even thoughtheyconstituteonly onesequenceof actions,anddo not includeconcurrency. As


an example, considerthe activities ‘tour planning’, ‘customerservice’ and‘invoicing’, whereeachof theseconsistsof asequenceof actions.

A singleagentwill not have concurrentactivities, but alternatesbetweendifferentactivities. Theshiftswill notonly bedeterminedby theagentsthem-selves,but will be triggeredby, for example,communicationwith otherob-jects.An agentwill, for instance,shift from tourplanningto customerservice(promptedby thetelephoneringing),andresumetour planningwhenthecus-tomerserviceis completed.

Theactionsequenceof anagentmayoftenbedecomposedinto partial ac-tion sequenceswhich correspondto certainroutinescarriedout several timesaspartof anactivity. As anexample,theinvoicingactivity maycontainpartialactionsequences,eachfor writing asingleinvoice.

Conceptsand abstraction

In the real world we createconceptsto capturethe complexity of the worldaroundus – we make abstractions.We all perceive the world in termsofconcepts:for peoplewe useconceptslike person,male,female,boy andgirl;in biology weuseconceptslikeanimal,mammal,predator, fish anddog.

A conceptis a generalizedideaof a collectionof phenomena,basedonknowledgeof commonpropertiesof instancesin thecollection.Conceptsareusedto concentrateon thosepropertieswhich aresharedby a setof phenom-enain theapplicationdomain,andto ignorethedifferencesbetweenthem.

Whentalking aboutconcepts,it is usefulto identify thefollowing charac-teristics:

� The extensionof a conceptis the collectionof phenomenacoveredby theconcept.

� The intensionof a conceptis a collectionof propertiesthat in somewaycharacterizethephenomenain theextensionof theconcept.

� Thedesignationof a conceptis thecollectionof namesby which thecon-ceptis known.

Theextensionof theconceptpredatorcontainsall lions, tigers,cats,etc. Theintensionincludesapropertysuchas‘eatingmeat.’

Weusethetermpatternfor aconceptbelongingto acomputerizedmodel.A patternis thusa representationof aconceptin our computerizedmodel.

Organizationof knowledge

Peopleconstantlyusethefollowing threefundamentalmethodsof knowledgeorganizationfor understandingtherealworld:


anim� al

mam� mal fis� h bir d reptile

pred�

ator rode� nt

lio� n tiger

Figure 2.2 Partof aclassificationhierarchyfor animals.

� Identificationof phenomenaand their propertiesAs a first stepin under-standinga complex collection of phenomena,individual phenomenaandtheir propertiesarerecognized.An objectmay be observed to consistofcertainparts,have a certainsizeandweight,a certaincolor, etc. Similari-tiesbetweendifferentphenomenamaynot berealized,just asa systematicunderstandingof theindividualphenomenamaynotbeobtained.

� ClassificationClassificationis themeansby whichweform anddistinguishbetweendifferent classesof phenomena.Phenomenaand conceptswithsimilar propertiesaregroupedinto classescorrespondingto extensionsofconcepts.Thisprocessleadsto classificationhierarchies.

In Figure2.2, a hierarchyof conceptsrelating to biology is shown. Theconceptof ananimalmaybeviewedasmoregeneralthantheconceptsofmammal,fish, bird andreptile, sinceall mammals,fishes,birds andrep-tiles arealso animals. The conceptanimal is said to be a generalizationof mammal,fish, bird and reptile. Similarly, mammalis a more generalconceptthanpredatorandrodent,somammalis a generalizationof rodentandpredator. A conceptlike mammalis alsosaidto bea specializationofanimal.Similarly, predatoris aspecializationof mammal.

Classificationhierarchiesareusefulfor understandingthe relevantproper-tiesof asetof phenomena.For theconceptanimalwemayassociateproper-tiescommonto all animals.Wemayassociatethepropertiescommonto allmammalsfor theconceptmammalasfor theotherconcepts.Sincea mam-mal, fish, bird or reptile is alsoananimal,we have isolatedtheir commonpropertieswith theconceptof animal.

� CompositionIn many situationsit is usefulto consideraphenomenaor con-ceptasa compositionof otherphenomenaandconcepts.Oneexampleofcompositionis to considera wholeas constructedfrom parts. The partsmay againconsistof smaller, simpler parts. The notion of a whole/part


Ma� n

He� ad LeftA�

rm Right�Arm LeftL� eg Right

�Leg

LeftH� and RightHand LeftF� oot Right�Foot

Figure2.3 Whole/parthierarchyfor a stickfigure.

Jim�

Jan� e Ma� ry Jo� e Mr. S� mith

mother father

wife boss

Figure 2.4 Exampleof referencecomposition.

compositionis an importantmeansof understandingandorganizingcom-plex phenomenaandconcepts.

Figure2.3 shows an exampleof a whole/parthierarchyfor a stick figureconsistingof partslike head,body, armsandlegs. In turn, the legsconsistof lower leg, foot, etc. A car may similarly be viewed asconsistingof abody, anengine,four wheels,etc.

An objectrepresentinga personmay alsohave propertiessuchasspouse,father, boss,etc.Suchpropertiesarenotphysicalpartsof aperson.Instead,we may view a personobjectascomposedof referencesto otherobjects.This form of compositionis calledreferencecomposition, illustratedin Fig-ure2.4.

As mentionedbefore,theconceptualframework is discussedfurtherin Chap-ter18.


2.3 Exercises

(1) Design a calculatorcorrespondingto the abstractcalculatordescribedabove.

(2) Giveotherexamplesof physicalmodelsnot involving computers.

(3) Developa classificationhierarchyfor vehicles.

(4) Developa whole/parthierarchyfor a tree.

(5) Designasimpletrain reservationsystem.

2.4 Notes

The conceptualframework for object-orientedprogrammingpresentedhereand in Chapter18 is a result of the BETA project, and hasformed the ba-sis for the designof BETA. It evolved over many years, and was influ-encedby several sources,including Simula, (Holbæk-Hanssenet al., 1975),(KnudsenandThomsen,1985), and a large numberof studentthesescar-ried out in Aarhus and Oslo. The Norwegian train example is from(Sørgaard,1988),andthestickfigureexampleis from(BlakeandCook,1987).

Other important contributions to a framework for object-orientedpro-gramming may be found in (StefikandBobrow, 1984), (Booch,1986),(ShriverandWegner, 1987), (ECOOP1987–1992) and (OOPSLA 1986–1992).

Chapter 3

Objectsand Patterns

Themostfundamentalelementsof BETA areobjectsandpatterns.Thischap-ter introduceslanguageconstructsfor describingobjectsandpatterns.

3.1 Overview

A BETA programexecutionconsistsof a collectionof objectsandpatterns.An object is somecomputerizedmaterialcharacterizedby a setof attributesandan actionpart. Someobjectsin a programexecutionwill representphe-nomenafrom theapplicationdomain,whereasotherobjectsarejustpartof theimplementation.

An objectrepresentinga bankaccountmaybedescribedin thefollowingway:

(# balance: ... ;Deposit: ... ;Withdraw: ... ;

#)

Thebankaccountobjectis characterizedby theattributesbalance, DepositandWithdraw . Theattributebalance 1 representsthecurrentbalanceof theaccount,Deposit representstheactionsperformedwhenmoney is placedinthe account,andWithdraw representsthe withdrawals performed.The dots... indicatesomedetailsthathave beenleft out of thedescription.All otherpartsof thedescriptionhave a meaningin BETA. Thesyntacticconstruct(#... #) is calledan object-descriptor, which describesthe structure of anobject.Partof thestructureof anobjectis its attributeslikebalance , DepositandWithdraw . Laterwe shallseethat thestructureof anobjectmayincludemorethanits attributes.

1SeealsoSection18.7for adiscussionof how to representpropertieslike balance .

23

24 OBJECTSAND PATTERNS

Singularly definedobjects

A personprogramminghis own privatefinancialsystemmay have only onebankaccount.In this case,thereis only a needto representonebankaccountin thesystem,describedasfollows:

myAccount: @(# balance: ... ;

Deposit: ... ;Withdraw: ... ;

#);

Theabovedescriptionhasthreeparts:

(1) myAccount is thenamethatmaybeusedto referto theobjectrepresentingtheaccount,

(2) thesymbol@showsthatmyAccount is thenameof anobject,and

(3) theobject-descriptor(# ... #) describesthestructureof theobject.

ThemyAccount namemaybeusedto denotetheattributesof thebankaccountobject.Theremote-name2 myAccount.balance denotesthebalanceattribute.Theotherattributesmaybedenotedin asimilar way.

ThemyAccount objectis calledasingularobject, sincetheobjectdescrip-tor (# ... #) is only usedfor describingasingleobject.

Patterns

In abankingsystemthereis clearlyaneedto representseveralbankaccounts,thus the systemincludesa pattern representingthe conceptof a bank ac-count. The objectsrepresentingthe actualbank accountsmay then be de-scribedasinstancesof this pattern.Thepatternrepresentingtheconceptof abankaccountmaybedescribedasfollows:

Account:(# balance: ... ;

Deposit: ... ;Withdraw: ... ;

#);

Thepatterndescriptionhastwo elements:

(1) Account is thenameof thepattern,and

(2) theobject-descriptor(# ... #) describingthestructureof eachof thebankaccountinstances.

2SeealsoSection3.2.5.

3.1 OVERVIEW 25

The dif� ferencebetweenthe descriptionof the myAccount object and theAccount patternis the useof the symbol@after : . The presenceof @after: meansthatanobjectis described.Whenthereis no symbolbetween: and(# ... #) , apatternis described.

Pattern-definedobjects

The Account patternmay, for instance,be usedto describethreebank ac-counts:

account1: @Account;account2: @Account;account3: @Account;

The descriptionof eachbankaccounthasthreeelementsthat aresimilar tothosefor the descriptionof myAccount . The differenceis the use of theAccount patterninsteadof (# ... #) to describethe structureof the ac-count objects. The namesaccount1 , account2 and account3 may all beusedlike myAccount . It is, for example,possibleto denotethe balanceofaccount1 usingtheremote-nameaccount1.balance .

The distinctionbetweendescribinga singular objectsuchasmyAccountanddescribinga patternrepresentinga conceptlike Account is important.Intheformer, oneis dealingwith asituationwherethereis only onesingleobjectto consider. In the latter, thereis a wholeclassof similar objectswhich maynaturallybe classifiedusinga concept.From a technicalpoint of view, it isconvenientto avoid inventinga patternnamewhen thereis only a singularobject.

Whenmakingdescriptionsin BETA thereis a large numberof patternsavailable for describingobjects. The integer patternis one example. In-stancesof the integer patterndescribeobjectsthat may representintegernumbers.In thebankaccountexample,theattributebalance couldberepre-sentedasaninstanceof the integer pattern:

balance: @integer

Declarations

The syntacticelementfor describingattributesis calleda declaration. Thefollowing areexamplesof declarationsusedabove:

Account: (# ... #);account1: @Account;balance: @integer

In general,thesyntacticconstruct: signalsa declarationof somekind, i.e. anamebeingassociatedwith someentity.


Description of actions

TheDeposit andWithdraw attributesrepresentthedepositingandwithdraw-ing actions,respectively, performedon an account.Theseattributesmay bedescribedasfollows:

Account:(# balance: @integer;

Deposit:(# amount: @integerenter amountdo balance+amount->balanceexit balance#);

Withdraw:(# amount: @integerenter amountdo balance-amount->balanceexit balance#);

#)

Deposit andWithdraw arepatterns.Deposit representsa conceptcoveringall possibledepositactions.The executionof an instanceof Deposit repre-sentsanactualdepositaction.An instanceof Deposit is anobjectconsistingof oneamount attribute representingtheamountof money to beput into theaccount. The depositaction is describedby enter amount do ... exitbalance .

An actionrepresentinga depositinto the account1 accountmay be de-scribedasfollows:

500->&account1.Deposit->newBalance

This describesthatan instanceof account1 ’s Deposit attribute is generated(describedby &account1.Deposit ). Thevalue500 is assignedto theamountattribute (describedby enter amount ), then the value of amount is addedto balance (describedby do balance+amount->balance ), andfinally, thevalueof balance is returned(describedby exit balance ) andassignedtotheobjectnewBalance .

Thesymbol& meansnew, andtheexpression&account1.Deposit meansthatanew instanceof thepatternaccount1.Deposit is createdandexecuted.Creationof aninstanceof a patternandexecutingit is oftencalledprocedureinvocation.

Withdraw workslikeDeposit .

3.1 OVERVIEW 27

Imperati� ves

An imperative is a syntacticelementfor describingan action,of which thefollowing areexamples:

balance+amount->balance;500->&account1.Deposit->newbalance

Completeprograms

Until now, variouselementsof BETA descriptionshave beenshown. Theex-amplein Figure3.1 shows how to combinesomeof theseelementsinto onecompounddescriptionin the form of an object-descriptorhaving Account ,account1 , account2 andaccount3 asattributes. In addition,the attributesK1, K2 andK3 have beenadded.Thedo-partof theobject-descriptorconsistsof a sequenceof actionsperformingvariousdepositsandwithdrawalson theaccounts.This object-descriptormay be compiledandexecutedby a BETAprocessor.3 An object-descriptorthat may be executedis often calleda pro-gram.

An abbreviatedsyntaxfor declaringaccount1 , account2 andaccount3hasbeenused.

A text enclosedby thebrackets � and is acomment.4

Stateand statetransitions

Thestateof anobjectat agivenpoint in time is thevalueof its attributes,andexecutionof actionsmaychangethestateof anobject.Thestateof a programexecutionat a givenpoint in time is the objectsexisting at thatpoint in timeandtheir states.

In Figure3.2, thestateof theexecutionof theprogramfrom Figure3.1 isshown. Thecomments{L1} , {L2} and{L3} indicatethreepointscorrespond-ing to thestatesshown in thefigure.At {L1} thevalueof all integerobjectsis0 (zero).(All integerobjectswill initially have thevalue0.) At {L2} thestatediagramshows thatvalueshavebeendepositedin thethreeaccounts.Finally,at {L3} thefinal stateof theprogramexecutionis shown.

3.1.1 Summary

Wecannow summarizethesyntacticelementsfor describingobjectsandpat-terns.

3The Mjølner BETA Systemmay be usedfor this. Seethe relevant manualsfor furtherinformation.

4Notethat ! and " cannotbeusedin theMjølner BETA System.Instead,(* and*) mustbeused.


(# Account:(# balance: @integer;

Deposit:(# amount: @integerenter amountdo balance+amount->bal anc eexit balance#);

Withdraw:(# amount: @integerenter amountdo balance-amount->bal anc eexit balance#);

#);account1, account2, account3: @Account;K1,K2,K3: @integer;

do {L1}100->&account1.Dep osi t;200->&account2.Dep osi t;300->&account3.Dep osi t;{L2}150->&account1.Dep osi t- >K1;90->&account3.With dra w- >K3;90->&account2.Depo sit -> K2;80->&account3.With dra w- >K3;{L3}

#)

Figure3.1 Accountprogram.

Object-descriptor

Thesyntacticelementfor describinganobjectis calledanobject-descriptor,andhastheform:

(# Decl1; Decl2; ...; Declnenter Indo Impexit Out#)

Theelementsof anobject-descriptorhave themeanings:

3.1 OVERVIEW 29

K1: 0K2: 0K3: 0

account3:

balance: 0

account2:

balance: 0

account1:

balance: 0

At L3:

At L2:

At L1:

K1: 250K2: 290K3: 130

account3:

balance: 130

account2:

balance: 290

account1:

balance: 250

K1: 0K2: 0K3: 0

account3:

balance: 300

account2:

balance: 200

account1:

balance: 100

Figure3.2 Snapshotsof statesduringexecutionof theaccountprogram.

� Decl1; Decl2; ... ;Decln is a list of attribute declarationsthat de-scribestheattribute-partof theobject.Thepossiblekindsof attributesarefurtherdescribedbelow.

� In is a descriptionof theenter-part of theobject.Theenter-part is a list ofinput parameterswhich maybeenteredprior to executionof theobject.

� Imp is thedo-partof theobject.Thedo-partis animperative thatdescribesthe actionsto be performedwhenthe object is executed. An objectmay,for instance,be executedas a procedure,a coroutine,or as a concurrentprocess.In Chapters13–15,theuseof objectsascoroutinesandconcurrentprocessesis described.

� Out is a descriptionof theexit-part of theobject. Theexit-part is a list ofoutputparameters which may be producedasa resultof executionof theobject.


Theenter-, do- andexit-partsaretogethercalledtheaction-partof theobject.An object-descriptormay have additionalparts,which will be introducedinsubsequentchapters.

Theobject-descriptoris thebasicsyntacticconstructin BETA. It maybeusedto describea patternlike Account , and it may be usedto describeasingleobject like myAccount . An object-descriptoris often part of a largerdescription,andaBETA programis anobject-descriptor. Chapter17describeshow a large numberof object-descriptorsmay be combinedinto a completeprogramthatcanbecompiledandexecuted.

Singular objects

A singularobjectmaybedescribeddirectlyusinganobject-descriptor:

S: @(# Decl1; Decl2; ...; Declnenter Indo Impexit Out#)

TheobjectmyAccount describedatthebeginningof thischapteris anexampleof asingularobject.

Pattern declaration

In BETA, a conceptis representedby a pattern, a patternbeingdefinedbyassociatinganamewith anobject-descriptor:

P: (# Decl1; Decl2; ...; Declnenter Indo Impexit Out#)

Patternsserve as templatesfor generatingobjects(instances). The objectsgeneratedasinstancesof P will all have thesamestructure, i.e. thesamesetof attributes,thesameenter-part,thesamedo-partandthesameexit-part.

Theintensionof theconceptbeingmodeledis givenby theobjectdescrip-tor, while theobjectsthataregeneratedaccordingto this descriptorconstitutetheextension.Thepatternnameis partof thedesignationof theconcept.Bymeansof virtual patterns(seeChapters7 and9) andrenaming,thepatternmayalsobedesignatedby othernames.

Pattern-definedobjects

An instanceof apatternmaybedescribedasfollows:

aP: @P

3.2 REFERENCEATTRIBUTES 31

3.2 Referenceattrib utes

Theattribute balance of Account is an exampleof a referenceattribute. Areferencedenotesan object, and may be either dynamicor static. A staticreferenceconstantlydenotesthe sameobject, whereasa dynamicreferenceis a variablewhich maydenotedifferentobjects.The balance attribute is astaticreference.

3.2.1 Static references

A staticreferenceis declaredin thefollowing way:

X: @T

whereX is the nameof the referenceandT is a pattern. An instanceof T isgeneratedaspartof thegenerationof theobjectcontainingthedeclaration:thestaticreferenceX will constantlydenotethis T-object.An objectgeneratedinthis way is calleda staticobject, or alsoa part-object, sinceit is a permanentpartof theobjectcontainingthedeclaration.

A singularstatic/part-objectis declaredin thefollowing way:

Y: @(# ... #)

Staticobjectsareusefulfor modelingparthierarchies,i.e. objectswhich con-sistof part-objects.

The following exampledescribesobjectsthat representpoints(e.g. on ascreen).Suchobjectsmayhave two integer attributes:

Point: (# x,y: @integer #)

The Point patternhas empty enter-, do- and exit-parts and a single dec-laration that usesthe predefinedinteger pattern. Given this pattern,twoPoint- objectsmaybegeneratedby thefollowing attributedeclaration:

P1,P2: @Point

ThePoint patternmayin turn beusedto describeattributesof otherobjects.Considerthefollowing patterndeclaration:

Rectangle: (# UpperLeft, LowerRight: @Point #)

Thegenerationof aninstanceof theRectangle patternimpliesthegenerationof two instancesof the Point pattern,onedenotedby UpperLeft andoneby LowerRight . The two Point instanceswill be a permanentpart of thisRectangle object.Figure3.3 illustratesa Rectangle object.


LowerLeft

UpperLeft x

x

y

2

2

1

1

Rectangle

y

Figure3.3 Diagrammaticrepresentationof a Rectangle object .

3.2.2 Dynamic references

A staticreferenceis constantsinceit alwaysdenotesthesamestaticobject.Itis necessaryto be ableto modelthat an objectmay have referencesto otherobjectswhich arenot partof itself. In addition,it mustbepossibleto modelthat suchreferencesarevariablein the sensethat they may denotedifferentobjectsat differentpointsin time. Both maybedoneby meansof a dynamicreference(or variablereference), asdeclaredin thefollowing way:

A: ˆT

whereA is the nameof the referenceand T is a patternname. A dynamicreferencemayat differentpointsin time denotedifferentobjects.Initially, itdenotesNONE, which represents‘no object.’

Considerthetwo attributes:

A1,A2: Âccount

A1 andA2 aredynamicreferenceswhichmaydenoteinstancesof theAccountpattern.A dynamicreferencemay begivena valueby meansof a referenceassignment. Considerthestaticreference:

A3: @Account

A referenceassignmentof theform:

A3[]->A1[]

implies that the objectdenotedby A3 will alsobe denotedby A1. A similarassignment:

A1[]->A2[]


R3

R1

R2

Account

Figure 3.4 Illustrationof dynamicreferences.

impliesthat theobjectdenotedby A1 is alsodenotedby A2. After this A1, A2andA3 will all referto thesameobject,illustratedin Figure3.4.

A dynamicreferencewill initially have thevalueNONE, which meansthatit refersto noobject. A dynamicreferencemayalsoexplicitly beassignedthevalueNONE:

NONE->A1[]

Sincea NONEreferencerefersto no object, it hasno meaningto attempttoaccessan objectusinga NONEreference.If A1 hasthe valueNONE, thenanevaluationof theform:

120->&A1.Deposit

is illegal,andexecutionof theprogramis terminated.5

3.2.3 Dynamic generationof objects

It is possibleto createobjectsdynamicallyby the executionof actions. Thefollowing evaluationcreatesaninstanceof theAccount pattern,andtheresultof theevaluationis a referenceto thenewly createdobject:

&Account[]

As for procedureinvocation,thesymbol& meansnew. Thesymbol[] meansthata referenceto theobjectis returnedastheresultof theevaluation.

A dynamicgenerationmaybepartof a referenceassignment:5This is anexampleof a run-timeerror.


&Account[]->A1[]

Theresultof this assignmentevaluationis thata new instanceof Account iscreatedanda referenceto this new objectis assignedto A1.

The differencebetween&P and &P[] is very important: the expression&P means‘generatea new instanceof P andexecuteit’; theexpression&P[]means‘generateanew instanceof P withoutexecutingit andreturnareferenceto thenew object.’ This is discussedfurther later. An objectgeneratedin oneof thesewaysis calledadynamicobject.

Dynamicgenerationof objectsis neededto describesystemswherenewobjectsare generatedduring programexecution,as is often the casewhenmodelingreal life phenomena.Froma technicalpoint of view, recursive pro-ceduresandrecursive datastructuresgive rise to the dynamicgenerationofobjects.

3.2.4 Exampleof usingdynamic references

In a bankingsystem,eachaccountshouldhave anidentificationof theownerof the account. For this reasonwe add an owner attribute to the Accountpattern.Theownershouldnot bea partof theaccountsinceseveralaccountsmayhavethesameowner. Wethereforerepresenttheownerof anaccountasadynamicreferenceto anobjectrepresentingtheowner. Considerthefollowingreviseddescriptionof Account :

Account:(# owner: ˆCustomer;

balance: ... ;Deposit: ... ;Withdraw: ... ;

#);

Owner is a dynamicreferenceto an instanceof the Customer pattern. In-stancesof theCustomer patternhaveattributesrepresentingvariouspropertiesof acustomersuchasnameandaddress:

Customer:(# name: ...;

address: ...;#)

Weshallnot go into Customer in furtherdetail.The following objectgeneratestwo customersand threeaccounts.Two

of the accountshave the sameowner. The resultingobjectsaredepictedinFigure3.5:


(## A1: Âccount;C1: ˆCustomer;A2: Âccount;C2: ˆCustomer;A3: Âccount;

do &Customer[]->C1[]; &Customer[]->C2[];&Account[]->A1[]; C1[]->A1.owner[];&Account[]->A2[]; C1[]->A2.owner[];&Account[]->A3[]; C2[]->A3.owner[];

#)

3.2.5 Qualified referencesand remoteaccess

A referenceis qualified(typed)by meansof apatternname.Thequalificationof a referencerestrictsthesetof objectsthatmaybedenotedby thereference.A referencedeclaredas:

R1: ˆRectangle

mayonly denoteinstancesof theRectangle pattern.Rectangle is calledthequalificationor thequalifyingpatternof R1.

Attributesin objectsmaybedenotedby remoteaccess, whichhastheform:

reference.attribute

The qualificationof a referencedetermineswhich attributesmaybe denotedby remoteaccess. For a referencelike R1, the attributes UpperLeft andLowerRight maybedenoted:

R1.Upperleft R1.LowerRight

SinceR1 is qualifiedby Rectangle , R1 cannotbeassigneda referenceto aninstanceof thePoint pattern.Also, it is not possibleto refer to non-existingattributes. Illegal assignmentsandaccessof non-existing attributesgive riseto many errorsin languageswithout qualifiedreferences.In a typedlanguagelike BETA, sucherrorsmay be detectedby the compiler. The disadvantageof qualifiedreferencesis lessflexibility for theprogrammer. In Smalltalkandmost object-orientedextensionsof Lisp, sucherrorsare first caughtat run-time. However, whenconstructingindustrialsoftware,it is a greatadvantageto have thecompilercatchasmany errorsaspossible.Notethata staticrefer-encewill automaticallydenoteaninstanceof thequalifyingpattern.


a1

a2

a3

c1

c2

Deposit

Withdraw

Owner

balance

Account

Deposit

Withdraw

Owner

balance

Accountname

address

Customer

name

address

Customer

Deposit

Withdraw

Owner

balance

Account

Figure3.5 Accountobjectsandcustomerobjects.

3.3 Pattern attrib utes

Thedeclarationof apatternattributehastheform:

P: (# ... #)

Themeaningof a patternattributehasbeendescribedin Section3.1. Severalexamplesof patternattributeshave alreadybeenshown, including Account ,Deposit andWithdraw .

3.3 PATTERN ATTRIBUTES 37

In thenext versionof thePoint pattern,a patternattributeMove hasbeenadded.Move describeshow Point objectsmaybemovedaround:

Point:(# x,y: @integer; {two reference attributes}

Move: {a pattern attribute}(# dx,dy: @integerenter(dx,dy)do x+dx->x;

y+dy->y#)

#)

A Point objectP1 may be ‘moved’ by executingan instanceof P1’s Move-attribute:

(11,22)->&P1.Move

whichdescribesanexecutionof P1.Move with parameters(11,22) . A Pointobjecthastwo referenceattributesandapatternattribute,but noenter-, do-orexit-parts.

Thedo-partis invokedby invoking a patternnameasin &P1.Move, whichinvokesthe do-partof the Move- patternin P1 asa procedure.&P1.Move de-scribesthat an instanceof the Move- patternwill be created,andcausesthedo-partof this instanceto beexecuted.Thesymbol& readsnew.

It is importantthat eachinstanceof Point hasits own setof attributes.Figure3.6 representsthe objectsP1 andP2. The Move attributesdenoteob-jectsrepresentingthestructureof patternMove. Sucha structure objecthasareferencepointingbackto theobjectof which thepatternis anattribute.Thisreferenceis calledthe origin of the pattern. Eachinstanceof P1.Move willhaveacopy of theorigin referenceof thestructureobjectcorrespondingto theMove attributeof P1, andthesameis truefor instancesof P2.Move . Figure3.7shows instancesof P1.Move andP2.Move . Noticethedifferencebetweenthestructureobjectsin Figure3.6describingthepattern attrib utesMove andtheobjectsin Figure3.7representinginstancesof Move.

The origin referenceis usedwhen an object-descriptorrefersto a non-local (global)attribute. In Move theglobalattributesx andy arereferred.Anevaluationlike:

x+dx->x

is theninterpretedas:

origin.x+dx->origin.x


P1 P2

Move

x

Point

y

Move

x

Point

y

111

222

333

444

struc (# ... #)

Move

origin

Move Move

struc (# ... #)

Move

origin

Figure 3.6 Diagrammaticrepresentationof Point objects.

P1 P2

Move

x

Point

y

Move

x

Point

y

111

222

333

444

Move Move

Move

origin

dx

dy

1

2

Move

origin

dx

dy

1

2

Figure 3.7 Point objectsandMove objects.

If P1.Move is executed,the origin referenceof the Move objectwill refer toP1. If P2.Move is executed,theorigin referenceof theMove objectwill referto P2.


3.3.1 Self-reference

It is often useful to be able to refer directly to an enclosingobject. This ispossibleusingtheconstruct:

this(P)

which is legal in the object-descriptorfor P, i.e. this(P) may only appearinsidea P pattern:

P: (# ... this(P) ... #)

this(P) is anexplicit namefor theenclosingP object.ThepatternPoint canbedescribedusingthis(P) in thefollowing way:

Point:(# x,y: @integer; {two reference attributes}

Move: {a pattern attribute}(# dx,dy: @integerenter(dx,dy)do this(Point).x+dx->this(Point).x;

this(Point).y+dy->this(Point).y#)

#)

Explict useof this(P) maymake it easierto reada programwhenreferringto globalnames.

Theconstructthis(P) is oftenusedto obtaina referenceto anenclosingP object:

this(P)[]

Weshallseeexamplesof this later.

3.3.2 Procedure, function and classpatterns

Theaboveexampleshaveshown two fundamentallydifferentwaysof usingapattern:(1) The Account patternhasbeenusedasa templatefor generatingobjectsthathaveastatewhichchangesover time; (2) theDeposit patternhasbeenusedasa templatefor generatinganaction-sequence.

In general,a patternis a generalizationof abstractionmechanismssuchasclass, type, procedure, function, etc. Thefact thatBETA hasonly oneab-stractionmechanismdoesnotmeanthatit is notusefulto distinguishbetweendifferentkinds of patterns. In the following we shall refer to conceptslikeclasspattern, procedurepatternandfunctionpatternfor patternsthatareused


asclasses,proceduresandfunctions,respectively. In laterchapterssomead-ditional conceptswill be introduced.Note,however, that technicallythereisno distinctionin BETA betweensuchpatternkinds. In therestof this sectionweshallelaboratefurtheron someof themostusefulpatternkinds.

Procedure patterns

The Deposit patternis usedfor generatingan action-sequence.To repre-senttemporarystateinformationduring this action-sequence,an instanceofDeposit is generated.Sucha patternis usuallycalleda procedure. Assumethat Deposit is a traditional (Pascal)procedure.A procedureinvocationofDeposit gives rise to the generationof an activation record,which is usedfor storingparametersandlocal variablesof the invocation. The instanceofthe BETA patternDeposit beinggeneratedplays the role of the procedureactivation.

Froma modelingpoint of view, theDeposit procedureandtheDepositpatternareusedto generateaction-sequences.The activation recordandtheobjectareonly generatedto representtemporarystateinformation.However,from animplementationpointof view theseobjectsmustbeconsidered,sincethey takeupspaceduringtheprogramexecution.

TheDeposit patternis usedasaprocedurein thefollowing way:

500->&account1.Deposit->newBalance

As describedabove, an instanceof account1.Deposit will be createdandexecuted.

Sincepatternsmay be usedasprocedures,it is possibleto expresspro-ceduralprogrammingin BETA asin Pascal,Modula-2,Ada or C. This styleof programmingis not recommendedin general,but often a minor part of asystemmay be expressedmoreelegantly by usingproceduralprogrammingratherthanobject-orientedprogramming.

Function patterns

Patternsmayalsobeusedasfunctions:theInterest patternis anexampleofa functionpattern.Interest computestheinterestonagivensumof money:

Interest:(# sum,interestRate,res: @integerenter(sum,interestRate)do (sum*interestRate) div 100->resexit res#)

Interest maybeusedin thefollowing way:


(1100,3)->&Interest->V$

Thevalueof V is then3% of 1100.What is actually meantby a function pattern? Here a function pattern

meansa patternintendedfor computinga valueon thebasisof a setof inputparameters.Theinput valuesareenteredthroughtheenter-part,andthecom-putedvalueis returnedvia theexit-part. Thecomputedvaluedependssolelyon theinput values.In addition,thecomputationof thevaluedoesnotchangethestateof any otherobject(therearenoside-effects).

Considerinsteadthe following pattern,which computesthe sum of thebalancesof threeaccounts:

TotalBalance:(# sum: @integerdo account1.balance->sum;

sum+account2.balance->sum;sum+account3.balance->sum;

exit sum#)

Herethevaluecomputedby TotalBalance dependsonthestateof theobjectsaccount1 , account2 and account3 , i.e. different calls of TotalBalancemayreturndifferentvalues.

Classpatterns

The Account patternis usedasa templatefor generatingobjectsthathave astatewhich changesover time. An instanceof Account modelsa realphys-ical object in the form of a bankaccount.A patterndescribingsuchobjectshastraditionally beencalleda class. Account is thusan exampleof a classpattern.

Figure 3.8 shows anotherexampleof a classpatternwhich describesalinked list of integers. Elementsmay be insertedin the list by meansof theprocedurepatternInsert . Thefollowing objectcreatesalist of four numbers:

(# head: @Linkdo 1 ->head.Insert;

2 ->head.Insert;6 ->head.Insert;24->head.Insert;{head = (0 24 6 2 1) }

#)

Theobjectdenotedby Head is just usedfor representingtheheadof the list,i.e. it is notpartof thelist.


Link: {Link describes a linked list}(# succ: ˆLink; {tail of this Link}

elm: @integer; {content element of this Link}

Insert: {Insert an element after this Link}(# E: @integer; R: ˆLink;enter Edo &Link[]->R[]; {R denotes a new instance of Link}

E->R.elm; {E=R.elm}succ[]->R.succ[]; {tail of this Link = tail of R}R[]->succ[]; {R=tail of this Link}

#)#)

Figure3.8 Classpatterndescribinga recursivedatastructure.

Someclasspatternslike Rectangle only includereferenceattributes. Apatternusedin thisway is similar to a recordtypein Pascal,i.e.apatternmayalsobeusedasa recordtype.

3.3.3 Basicpatterns

A numberof predefinedbasicpatternsfor commonlyuseddatatypessuchasinteger , boolean , char andreal andtheiroperationsareavailable.

For the integer pattern,the functionalpatterns+, -, *, div andmodareavailable,correspondingto theusualarithmeticfunctions. Div is integerdivisionwith truncation;Mod is themodulusfunctioncomputingtheremainderof an integerdivision. Considerthe following declarationof threeinteger -objects:

I,J,K: @integer

Thestandardinfix notationfor integer expressionscanbeused:

1+I->I; (I*J)+12->K

In principle,it correspondsto thefollowing evaluationusingfunctioncalls:

(1,I)->+->I; ((I,J)->*,12)->+->K

It is, however, not possibleto usethe above function call syntax. Only theinfix notationcanbeused.


For% the real pattern,the arithmeticoperations+, - , * and / aredefined.For theboolean pattern,thefunctionalpatternsand , or andnot aredefined.In addition, the patternsfalse and true describeobjectsrepresentingthebooleanvaluesfalseandtrue.

The char patternis a representationof the ASCII characterset. Eachcharacterin the ASCII characterset hasan associatedvalue in the interval&0' 255( . TheprintableASCII charactersmaybedenotedin thefollowing way:

’a’ ’b’ ... ’0’ ’1’ ... ’!’ ’@’ ...

The value of a char object is the integer correspondingto the char in theASCII characterset,meaningthat it is possibleto performintegeroperationsonchars.Theevaluation:

’a’+1->b

will assigntheASCII valueof ’a’ plusoneto thevariableb. SincetheASCIIvalueof ’a’ is 97 andthe ASCII valueof ’b’ is 98, b will have the ASCIIvalueof ’b’ .

Thereal patternis a representationof floatingpointnumbers.6

Relational operators The functional patterns=, <>, <, <=, > and >=correspondingto thestandardrelationalfunctionsequal,not equal,lessthan,lessthanor equal,greaterthanandgreaterthanor equalareavailablefor inte-ger, boolean,charandrealobjects.For boolean,the false patterndescribesobjectswhich arelessthanandnot equalto objectsdescribedby True . Forcharobjects,theASCII orderingis used.

Initial values Instancesof basicpatternswill haveadefault value:Integerobjectswill havethevalue0; char objectswill havethevalue0 correspondingto thenull character;boolean objectswill have thevaluefalse ; andrealobjectswill have thevalue0.0 .

Restrictions In theMjølnerBETA Systemthereareafew pragmaticrestric-tions on the usageof basicpatterns. It is not possibleto declaredynamicreferencesto instancesof suchpatterns.Also, a basicpatterncannotbeusedasa super-pattern(seeChapter 6). BETA is a very generallanguage,andsometimesthis generalitymakesit hardto obtainanefficient implementation.Theabove restrictionsareimposedfor efficiency reasons.Thereis no logicalmotivationfor theserestrictions.

6In thecurrentimplementationsof theMjølner BETA System,a 64-bit representationoffloatingnumbersis used.For detailsconsulttheMjølnerBETA Systemmanuals.


3.4 Exercises

(1) Use the Mjølner BETA Systemto executethe accountprogramin Fig-ure3.1.

(2) Definethe name andaddress attributesof theCustomer patternin Sec-tion 3.2.4. An addressshouldconsistof street,streetnumber, city, zipcodeandcountry.

(3) Define patternsrepresentinga point, line, segment,polygon, rectangle,squareandrhombus. A segmentis a list of lines wherethe endpoint ofoneline is thestartingpoint of thenext line.

It shouldbepossibleto createobjectsof thesepatterns,move theobjects,changeoneof the coordinatesof a point, changethe start(or end)pointof a line, changethestart(or end)pointof a line in asegmentor polygon,adda new line to a segment,andadda segmentto a segment(considerwhatthiscouldmean).

3.5 Notes

A patternis a unificationof abstractionmechanismslike class,type, proce-dure,function,genericpackage,etc.It is afurthergeneralizationof theSimulaclassconstruct.

Patternsmayalsobe comparedto classesin Smalltalk. Patternattributesof a patterncorrespondto interfaceoperationsin Smalltalkclasses,andref-erenceattributescorrespondto instancevariables. The do-partof an objecthasno counterpartin Smalltalk,andis usedwhentheobjectis executedasaprocedure,coroutineor process.Comparedto Smalltalk,thedo-partof anob-ject representsa very importantextensionof thenotionof objectsthatallowspatternsto be executedasprocedures,and to be usedin modelingongoingprocessesandin systemsimulation.

A dynamicreferenceis similar to a referencein Simulaandan instancevariablein Smalltalk.It resemblesSimulain thesensethata BETA referenceis qualified.Instancevariablesarenotqualifiedin Smalltalk.Theadvantageofqualifiedreferencesis (1) thecompilermaydetectillegal accessof attributes,(2) the compilermay generatemoreefficient code,and(3) the qualificationimproves the readabilityof the code. The price for this is, of course,lessflexibility for theprogrammer. For implementingindustrialsoftware,a typedlanguagelikeBETA will leadto morerobustandsafeprograms.

Generationof dynamicobjectswith subsequentassignmentof the refer-enceto a dynamicreferencevariable&P[]->R[] correspondsto R ) P Newin Smalltalk.

The framework for BETA presentedin Chapter2 makesa distinctionbe-tweenphenomenaandconcepts,andthis is reflectedin the language:objects

3.5 NOTES 45

model* phenomenaandpatternsmodelconcepts– a patternis not an object.In contrastto thisdistinctionbetweenobjectsandpatterns,Smalltalk-like lan-guagestreatclassesasobjects. Conceptsarethusboth phenomenaandtheyare usedto classify phenomena.In the BETA framework, patternsmay betreatedasobjects,but thatis in theprogrammingprocess. Theobjectsmanip-ulatedin a programmingenvironmentwill befragments(e.g. patterns)of theprogrambeingdeveloped.

Thereareobject-orientedlanguagesthatdo not havea notioncorrespond-ing to patterns;suchlanguagesarecalledclasslessor prototype-based. Insteadof generatingobjectsasinstancesof patterns(classes),anobjectis generatedasacloneof anotherobject.Theobjectbeingclonedis consideredasaproto-typeto beusedfor generatingsimilar objects.Thegeneratedobjectwill havethesamepropertiesastheobjectfrom which it is generated,but it maymodifysomeof thepropertiesandaddnew ones.Themostwell known exampleofsucha languageis Self(UngarandSmith,1987).

BETA is a languagebelongingto the Algol family with respectto blockstructure,scoperulesandtypechecking.In Algol andSimulaa procedureorblock mayhave local proceduresand/orblocks. With respectto scoperules,BETA also follows the Algol tradition, sinceall namesin textually enclos-ing objectdescriptorsarevisible. In additionto the Algol scoperules,mostlanguagessupportingclasseshave a rule thatprotectscertainattributesof anobject from beingaccessedremotely. In Simula this is handledby the hid-den/protectedmechanism;in Smalltalk,instancevariablescannotbeaccessedfrom outsidethe object. BETA containsno suchprotectionmechanism;in-stead,themodularizationdescribedin Chapter17 is used.


Chapter 4

Repetitions

It is possibleto declarea repetitionof staticor dynamicreferences.A repeti-tion of staticreferencesis declaredin thefollowing way:

A: [eval] @P;

A is thenameof arepetitionof staticreferencesandP is apatterndescribingthestaticinstances.eval is anevaluationresultingin anintegernumbercalledtherangeof therepetition.Therangeof arepetitionmaybedenotedby A.range .This repetitiondescribesthefollowing setof staticreferences:

A[1], A[2], ..., A[A.range]

An element in the repetition may be denotedby an expressionA[exp] ,whereexp is an integer evaluationthat mustresult in a valuein the interval[1,A.range] .

The examplein Figure4.1 illustratesthe useof a repetitionof staticref-erences.A repetitionof integershasbeenaddedto theAccount pattern.Therepetitiontransactions keepstrackof thesequenceof transactionsthathavebeenmadeon the account.When50 transactionshave beenmade,1 a state-mentof thetransactionsis sentto thecustomer(only indicatedby acomment),therepetitionis cleared,andtherecordingof transactionsis begunagain.

A repetitionmayalsoconsistof dynamicreferences:

A: [eval] ˆP

Hereeachelementin therepetitionis adynamicreference.The example in Figure 4.2 illustrates the use of a repetition of dy-

namic references.The object BankSystem includestwo repetitionsof dy-namic referencesfor keepingtrack of all accountsand customershandled

1For a descriptionof the if -imperativeseeChapter5.

47

48 REPETITIONS

Account:(# ...

transactions: [50] @integer; Top: @integer;

Deposit:(# amount: @integerenter amountdo balance+amount->bal anc e;

amount->&SaveTransa cti onexit balance#);

Withdraw:(# amount: @integerenter amountdo balance-amount->bal anc e;

-amount->&SaveTrans act ionexit balance#);

SaveTransaction:(# amount: @integerenter amountdo (if (top+1->top)>trans act io ns. ran ge // true then

{Send statement of transactions to the customer}1->top

if);amount->transaction s[t op]

#)#)

Figure 4.1 Recordingof transactions.

by the bank. The bankmay have at most200 accountsand100 customers.The integer object noOfAccounts keepstrack of the currentnumberof ex-isting accounts. The referencesAccountFile[1] , AccountFile[2] , ...,AccountFile[noOfAccounts] arethecurrentlyexisting accounts.Thepat-tern NewAccount generatesa new accountandaddsit to thefile. Customersarehandledin asimilar way.

If aCustomer is a referenceto a customer, then a new accountfor thiscustomermaybegeneratedusingNewAccount , asin:

aCustomer[]-> BankSystem.NewAccount->anAccount[ ]

ThereferenceanAccount will thenreferto thenew account.

4.1 REALLOCATION, ASSIGNMENTAND SLICE 49

BankSystem: @(# Account: (# ... #);

Customer: (# ... #);

AccountFile: [200] Âccount;noOfAccounts: @integer;

CustomerFile: [100] ˆCustomer;noOfCustomers: @integer;

NewAccount:(# C: ˆCustomer; rA: Âccountenter C[]do noOfAccounts+1->no OfAcc oun ts;

&Account[]->rA[]-> AccountF ile [no Of Accoun ts] [] ;C[]->AccountFile[n oOf Accou nts ].o wner[ ]

exit rA[]#)

NewCustomer: (# ... #)#)

Figure 4.2 Bankingsystem.

4.1 Reallocation,assignmentand slice

Thebankingsystemin Figure4.2mayholdatmost200accountsand100cus-tomers. In practice,it is not acceptablethat suchlimitations arehard-codedinto a program:it mustbepossibleto dynamicallyexpandthesizeof a repe-tition. In BETA it is possibleto extendthe rangeof a repetition. Consideradeclaration:

R: [16] @integer

Executionof theimperative

10->R.extend

extendsthe sizeof R by 10 elements.SinceR.range=16 beforethe assign-ment,R.range=26 aftertheassignment.TheelementsR[1] , R[2] , .... R[16]have thesamevaluesasbeforetheassignment.TheelementsR[17] , R[18] ,... R[26] have thedefault valuefor integer objects(which is zero).

It is alsopossibleto make a completenew allocationof a repetition.Exe-cutionof

50 REPETITIONS

25->R.new

will allocateanew repetitionof 25 elements.Thepreviouselementsareinac-cessible;thenew elementswill have thedefault valueof theelementpatterninteger .

Theextend andnew operationsaredefinedfor all repetitions.Assignmentis definedfor repetitionsin general.Considerdeclarations:

R1: [18] @integer;R2: [12] @integer

An assignment

R1->R2

hasthefollowing effect:

R1.range->R2.new;R1[1]->R2[1]; R1[2]->R2[2]; ...;R1[R1.range]->R2[R2.range]

Or expressedusingthe for -imperative:2

R1.range->R2.new;(for i: R1.range repeat R1[i]->R2[i] for)

Sincethe rangeof a repetitionmay be changedby using assignment,newandextend , oneshouldalwaysusethe range attribute to refer to therange.Insteadof

(for i: 12 repeat sum+R2[i]->R2[i] for)

it is usuallybetterto use:

(for i: R2.range repeat sum+R2[i]->R2[i] for)

It is possibleto assignpart of a repetitionto anotherrepetitionby using arepetitionslice, whichhastheform:

R2[3:9]

Suchaslicecanbeusedin anassignmentlike:

R2[3:9]->R1

which is similar to R2->R1 exceptthatthesourcerepetitiononly has9-3+1=7elements.Theboundsin aslicecanbearbitraryevaluationsyieldinganintegervalue:

R2[e1:e2]->R1

whichmeans

e2-e1+1->R1.new;R2[e1]->R1[1]; R2[e1+1]->R1[2]; ...; R2[e2]->R1[R1.range]

2SeeChapter5.

4.2 THE TEXT PATTERN 51

4.2 The text pattern

A predefinedpatternfor representinga text conceptis available,thoughit isnot a basicpatternlike integer , boolean , char andreal . The restrictionsfor thebasicpatternsmentionedin Section3.3.3donotapplyto text objects.It is thuspossibleto createdynamicreferencesto text objectsandto usethetext patternasa super-pattern(seeChapter6). Thereare,however, a fewbuilt-in languagefeaturesthatarespecialfor the text pattern.Thefollowingis anexampleof usingthe text pattern:

(# T1,T2: @text; T3: ˆtextdo ’Hello’->T1; ’World’->T2; T2[]->T1.append;

&text[]->T3[]; T1->T3;#)

A text objectmay be generatedandusedasany otherobject. As may beseen,a text objectmaybeassigneda text constant(like ’Hello’ ), andonetext objectmaybeassignedto anothertext object(asin T1->T3 ). A textobjecthasa numberof attributes(like append ) which arenot predefined,butarepartof thebasiclibrary definedfor theMjølner BETA System.

Basically, a text objectis representedby a repetitionof char objects:

text:(# R: [16] @char;

...#)

It is possibleto assigna text constantto acharrepetition:

’Hello’->R

Theeffectof this is that:

R[1]=’H’, R[2]=’e’, R[3]=’l’, R[4]=’l’, R[5]=’o’

andthat:

R.range = 5

The assignmenthasthe effect that the previous contentof the repetitionisoverwritten.

A text objectcanhold anarbitrarynumberof char objects.This is im-plementedby meansof R.extend whenever thesizeof the text objectneedsto beenlarged.

52 REPETITIONS

4.3 Exercises

You mayhave to readChapter5 to solve theexercisesbelow.

(1) Completethe text patternby giving a completeimplementationanddefining a suitableset of operations. A text object shouldbe able toholda text of anarbitrarylength.

Discussthe strategy for extendingthe sizeof the text. Shoulda text -objectbe extendedwith a fixed sizeevery time, n%of its currentsizeordoubleits size?

(2) Completethebankingsystemin Figure4.2.

Use the Customer patterndevelopedin Exercise2 in Chapter3. Addprocedurepatternsfor removing accountsandcustomers.

Changethe recordingof transactionsto keeptrackof the latest50 trans-actions.For each50 transactionssendoutastatementto thecustomer.

Modify theAccount patternsuchthatanaccountmayhave severalown-ers.

The banksystemshouldnot be restrictedto handlea limited numberofcustomersandaccounts.

4.4 Notes

Therepetitionconstruct(oftencalledanarray) hasbeenknownsincetheearlydaysof programminglanguages,and is presentin languagessuchasFOR-TRAN andAlgol 60. Algol 60 introducedthenotionof dynamicarrayswherethe size of the array is computedat run-time. After an array is createditssizecannotbechanged.Oneof the successorsto Algol 60, Pascal,imposedthelimitation on arraysthat their sizemustbeknown at compile-time,whichmeansthat only constantsmay be usedto specify the sizeof Pascalarrays.Themotivationfor this restrictionwasefficeincy.

Thepossibilityof extendingthesizeof anarrayafterit hasbeencreatedisknown from a numberof otherlanguages,includingAlgol 68. Extendingthesizeof an arrayis an expensive operation,sinceit usuallyimplies allocationof anew arrayobjectandcopying of theold valuesto thenew area.

Chapter 5

Imperati ves

Thedo-partof anobjectis asequenceof imperativesthatdescribesactionstobeexecuted.Until now wehaveseenvariousexamplesof imperatives:

x+dx->x; {assignment}(11,22)->&P1.Move; {procedure invocation}R1[]->R2[]; {reference assignment}&Rectangle[]->R1[]; {dynamic generation and}

{reference assignment}

The first four imperativesareexamplesof the evaluationimperative, whichwill befurtherdescribedin thenext sub-section.In addition,BETA hasa fewimperativesfor controlling the flow of executions,calledcontrol structures,whichwill alsobedescribedbelow.

5.1 Intr oduction to evaluations

The basicmechanismfor specifyingsequencesof object executionstepsiscalledanevaluation. An evaluationis animperativethatmaycausechangesinstateand/orproducea valuewhenit is executed.Thenotionof anevaluationprovidesa unified approachto assignment,function-callandprocedure-call.Examplesof evaluationsare:

(11,22)->&P1.Move;x+dx->x

Theevaluation:

x+dx->x

specifiesanordinaryassignment(theassignmentof x+dx to x). An evaluationmayspecifymultipleassignment, asin:

53

54 IMPERATIVES

(#Power: {Compute Xˆn where n>0}

(# X,Y: @real; n: @integer;enter(X,n)do 1->Y;

(for inx: n repeat Y*X->Y for)exit Y#);

Reciproc: {Compute (Q,1/Q)}(# Q,R: @realenter Qdo (if Q // 0 then 0->R

else (1 div Q)->Rif)

exit(Q,R)#);

A,B: @realdo (3.14,2)->&Power-> &Reci pro c-> (A, B) ;

{A=3.14*3.14, B=1/A}#)

Figure 5.1 Exampleof usingpatternsasprocedures/functions.

3->I->J

where3 is assignedto I andthevalueof I is assignedto J . Theevaluation:

(11,22)->&P1.move

specifiesa procedure-call.Thevalue(11,22) is assignedto theenter-partofP1.Move , andP1.Move is thenexecutedwith theseenterparameters.NotethatthepatternP1.Move is invokedasaninstance.

As shown above,anevaluationmayspecifymultipleassignmentof values.Themultiple assignmentform mayalsobeusedto combineexecutionof ob-jects.Considertheexamplein Figure5.1. Theprogramcontainsthedeclara-tionof twopatterns,Power andReciproc , andtwoobjectsof thepatternreal ,A andB. Thedo-partof theprogramconsistsof theevaluation-imperative:

(3.14,2)->&Power->&Reciproc->(A,B)

5.2 FOR-IMPERATIVE 55

The ex+ ecutionof this evaluation-imperative takesplaceasfollows: The val-ues 3.14 and 2 are assignedto the input parametersX, n of Power (de-scribedby enter(X,n) ), thedo-partof Power is executed,theoutputparam-eterY of Power (describedby exit Y) is assignedto the input parameterQof Reciproc , the do-partof Reciproc is executed,andfinally, the output-parametersQ, R of Reciproc areassignedto A,B .

The do-part of Power consists of two imperatives: an evaluation-imperative assigningY thevalue1; anda for-imperative. The index-variableinx stepsthroughthe values1,2, ... ,n . The do-partof the Reciprocpatternconsistsof anif-imperative.

Notethata function-patternmayreturna list of valueslike theReciprocpattern. The resultof a patternreturninga list may be entereddirectly intoanotherpatternthathasa compatibleenter-part. Assumethat thepatternMaxhasan enter-part consistingof two reals. Reciproc and Max may then becombinedin thefollowing way:

exp->&Reciproc->&Max->M

Thepreviousexampleshaveshown examplesof evaluationsdescribingthegenerationof objectsasinstancesof patterns.It is alsopossibleto usesingularobjectsin theactionpart,asshown in thefollowing example:

(# Y,V,W: @realdo ...;

{Singular object:}(# X: @realdo Y->&Reciproc->(V,W);

(V,3)-> &Power->V;(W,5)-> &Power->W;

#);...

#)

Theactionpartof theaboveobjectdescriptorincludesa singularobject.Sin-gular objectsin the action part are useful when thereis a needfor declar-ing somelocal objects(like X above) which areonly neededfor intermediatecomputations.In general,it is possibleto arbitrarily nestobject-descriptors,includingsingularobjectsandpatterns(seeSection5.9).

5.2 For-imperative

Theiterationcontrolstructureof BETA is calleda for-imperativeandhasthefollowing form:

56 IMPERATIVES

(for Index: Range repeat Imperative-list for)

whereIndex is the nameof an integer- objectandRange is an integer -evaluation.Range is evaluatedprior to theexecutionof thefor-imperative,anddeterminesthe numberof timesthat Imperative-list is executed. Indexwill stepthroughthevalues[1, 2, ..., Range] . ThenameIndex is onlyvisible in the Imperative-list . It is not possibleto assignto Index . Thefollowing exampleillustratesthefor-imperative:

(# V: [100] @integerdo (for i: V.range repeat i->V[i] for);

0->sum;(for i: V.range repeat sum+V[i]->sum for)

#)

Thefor-imperativedescribesthattheimperative:

i->V[i]

is executedV.range numberof times,i.e. 100times.Theindex variablei willstepthroughthevalues[1,2,...,100] . Thefor-imperativethusdescribesanexecutionof:

1->V[1];2->V[2];...100->V[100]

Often it is desirableto stepthroughan index setwhich doesnot startwith 1,andwhichuses1 to incrementtheindex variable.An exampleof suchanindexsetis [-4, -2 ,0, 2, 4] . In Chapter6 anexamplewill begivenof how todefinenew controlstructuresusingpatterns.BETA hasonly a few predefinedcontrol structures– the ideais thatmostcontrolstructuresshouldbedefinedusingpatterns.

5.3 If-imperati ve

Theselectioncontrolstructureis calledan if-imperativeandhasthefollowingform:

(if E0// E1 then I1// E2 then I2

...// En then Inelse I

if)

5.3 IF-IMPERATIVE 57

where E0, E1, E2, ..., En areevaluationsandI1 , I2 , ..., In andI areimpera-tives. Theelsepart (else I ) is optional. E0 is first evaluated,andthatvalueis testedfor equalitywith E1, E2, ..., En in anarbitraryorder. If E0 , E j thenI j may be selectedfor execution. If oneor morealternativesareselectable,thenoneof theseis chosenrandomly. If no alternative canbe selected,thenthepossibleelsepart is executed;otherwise,theexecutioncontinuesaftertheif-imperative.

In the following examplethe integer objectx is testedfor equalitywithsomeintegerevaluations:

(if x// 17 then ...// 33 then ...// y+3 then ...else ...

if);

The next exampleshows how to selecton the basisof a booleanvalue. Thefalsecasemayalsobehandledby anelsepart:

(if (x>0) and (y<0)// True then ...// False then ...

if)

The next exampleshows how to selecton the basisof a numberof booleanconditions:

(if true// (x<0) and (y=0) then ...// (x=0) and (y=0) then ...// x>=0 then ...

if)

It is also possibleto selectby comparingreferences.Assumethat R0, R1,R2 andR3 arereferencesto Point objects.The following if-imperative testswhetheror not R0 denotesthesameobjectasoneof R1, R2 andR3:

(if R0[]// R1[] then ...// R2[] then ...// R3[] then ...

if)

58 IMPERATIVES

In theabove example,R0 andR1 maydenotedifferentPoint objects,but thex and y attributesof theseobjectsmay still be identical. In this case,thetwo objectshave the samestateor value. In BETA thereis cleardistinctionbetweenreferenceequalityandvalueequality. In theif-imperative above thereferencesaretestedfor referenceequality. It is alsopossibleto testwhetherthetwo point objectsareidenticalwith respectto thevaluesof their attributesx andy . In BETA, valueequality is not just a bit by bit comparisonof thetwo objects;the descriptionof a patternmustexplicitly describehow valueequality is carriedout. Assumingthat this hasbeendone,an if-imperativetestingfor valueequalityof thePoint objectsmaylook asfollows:

(if R0// R1 then ...// R2 then ...// R3 then ...

if)

Hereit is testedwhetheror notthestateof theobjectdenotedby R0 is identicalto thestateof someof theotherobjects.

Note that it is the presenceof the symbol [] which indicatesreferenceequalityinsteadof valueequality. This is thesameusageof [] asfor dynamicgenerationandreferenceassignment(Section3.2.3).

5.4 Labelsand jump imperatives

A labeledimperativehasoneof thefollowing forms:

L: Imperative

(L: Imp1; Imp2; ... Impn :L)

whereL is a name.In thefirst case,thescopeof thelabel is the Imperativeto which the label is attached,i.e. L may only be referred to within theImperative . In the secondcase,the scopeof the label is the imperativesImp1; Imp2; ... Impn . Theexecutionof a labeledimperativemaybeter-minatedby executinga leave-or restart-imperativewithin it: if leaveL is ex-ecuted,theexecutioncontinuesafter the imperative labeledby L; if restartLis executed,the executioncontinuesat the imperative labeledby L, i.e. theexecutionof thelabeledimperative is repeated.

Considerthefollowing example:

(L: (if ... if);M: {2}

(for ... repeat

5.5 A LARGE EXAMPLE 59

(if ...// ... then leave L// ... then restart M

if)for);

X->Y:L) {1}

An executionof leaveL impliesthatexecutioncontinuesat - 1. . An executionof restartMimpliesthatexecutioncontinuesat - 2. .

5.5 A largeexample

The Register pattern in Figure 5.2 describesa category of objects.EachRegister -objectconsistsof the attributesTable, Top, Init, Has,Insert andRemove. Table is an indexedcollectionof staticreferencesde-noting100 integerobjects.

TheRegister patternmaybeusedasfollows:

(# R: @Registerdo &R.Init;

(for inx: 6 repeatinx*inx->&R.Insert

for);(for elm: 100 repeat

(if (elm->&R.Has) // True then{elm is in R} ...

if)for)#)

Theimperative&R.Init hastheeffectof initializing R. Thenthesquareof thenumbers1-6 areinsertedinto R. Finally, it testswhich integersfrom 1 to 100aremembersof R.

Theoperationsof a Register objectaredefinedby thepatternattributesInit, Has, Insert andRemove. The representationof a Register objectis thereferenceattributesTable andTop. A Register objectshouldonly beaccessedvia its operations.The above descriptionof the Register patterndoesnot preventaccessto therepresentation– mechanismsfor doingthis aredescribedin Chapter17.

5.6 Assignmentand equality

Oneof the fundamentalconceptsin programmingis the distinctionbetweentheaddressof amemorylocationandthecontent(state)of amemorylocation

60 IMPERATIVES

Register:(# Table: [100] @integer; Top: @integer;

Init: (#do 0->Top #);Has: {Test if Key in Table[1:Top]}

(# Key: @integer; Result: @boolean;enter Keydo False->Result;

Search:(for inx: Top Repeat

(if ((Table[inx]=Key)-> Result ) // Truethen leave Search

if)for)exit Result#);

Insert: {Insert New in Table}(# New: @integerenter Newdo (if (New->&Has) {Check if New is in Table}

// False then {New is not in Table}Top+1->Top(if (Top<=Table.Range) {Table.Range=100}

// True then New->Table[Top]// False then {Overflow}

if)if)#);Remove: {Remove Key from Table}

(# Key: @integerenter keydo Search:

(for inx: Top repeat(if Table[inx] // Key then

(for i: Top-inx repeatTable[inx+i]->Table[ in x+i -1]

for);Top-1->Top;leave Search

if)for)#);#)

Figure5.2 PatternRegister .

– it is a commonprogrammingerror to confusethesetwo issues.In object-orientedprogrammingthis distinctionis thedifferencebetweenthereference

5.6 ASSIGNMENTAND EQUALITY 61

to an objectandthe stateof an object. In somelanguagesthis differenceisnot madeexplicit in the syntax, implying that the programmermay not beawareof whethera referenceor the stateof an object is beingmanipulated.In theBETA syntaxthereis anexplicit distinctionbetweenmanipulationof areferenceandmanipulationof thestateof an object. Considerthe followingobject:

(# R1,R2: @Point;R3,R4: ˆPoint

do &Point[]->R3[]; &Point[]->R4[];(1,1)->(R1.x,R1.y); (2,2)->(R2.x,R2.y);(3,3)->(R3.x,R3.y); (4,4)->(R4.x,R4.y);L1:R3[]->R4[]; R1[]->R3[];L2:(100,200)->&R1.MoveL3:

#)

Figure5.3 shows the stateof the objectat the pointsL1, L2 andL3, respec-tively.

R1 andR2 denotepartobjects,whereasR3 andR4 denoteseparateobjects.At L2 it canbeseenthatexecutionof the referenceassignmentsimplies thatR1 andR3 denotethe sameobject. At L3 it canbe seenthat the imperative(100,200)->&R1.Move alsoaffectstheobjectdenotedby R3.

Next weconsiderassignmentof integerobjects:

(# a,b,c: @integerdo 111->a; 222->b; 333->c;

L1:a->b;L2:c->b;L3:

#)

Figure5.4 shows thestateof the above objectat L1, L2 andL3 respectively.Notethata, b andc arenot referencesto values,but areobjectshaving astatecorrespondingto thevalues111 , 222 and333 . At L2 it canbeseenthata andb have thesamevalue(state);at L3 it canbeseenthat a is not affectedby anew assignmentto b.

Thisexampleshowsthatintegerobjectsandtheassignmentof integerob-jectsbehave like ordinaryvariablesandassignmentin traditionalprocedural

62 IMPERATIVES

R2

at L1

R3

R4

R1 x

y

x

y

2

2

at L3

R3

R4

R2

R1 x

y

x

y

y

x

y

x 4

4

3

3

y

x

y

x

3

3

4

4

2

2

101

201

1

1

at L2

R3

R4

R2

R1 x

y

x

y

y

x

y

x

3

3

4

4

1

1

2

2

Figure 5.3 Illustrationof referenceassignment.

programminglanguages,i.e.assigningobjecta to objectb consistsof copyingthestateof a to b. This form of assignmentis calledvalueassignment.


at L1 at L2

a

b

111

222

333c

at L3

a

b

c

a

b

c

111

333

333

111

111

333

Figure 5.4 Basicvalueassignment.

It is alsopossibleto definevalueassignmentfor patternslike Point . ThePoint patternmayberedefinedsuchthatvalueassignmentof Point objectsis possible,asin thefollowing object:

{Note:the current definition of the Point pattern must}{be revised in order for this example to be legal!}{For purposes of discussion only.}(# R1,R2: @Point;

R3,R4: ˆPointdo &Point[]-> R3[]; &Point[]->R4;

(1,1)->R1; (2,2)->R2; (3,3)->R3; (4,4)->R4;L1:R1->R3; R2->R4;L2:R3->R2; (5,5)->R1L3:

#)

Themeaningof theabove assignmentsmaybeinterpretedasfollows: anas-signmentlike:

(1,1)->R1

assignsthevalue1 to x andy . An assignmentof theform:

R1->R3

assignsthex andy attributesof R1 to thex andy attributesof R3. Figure5.5shows thestateof theabove objectat L1, L2 andL3, respectively. Thediffer-encefrom Figure5.3maybeobserved.

Valueassignmentfor non-basicobjectscouldbedefinedasapurecopy ofthestateof theobject. This would besufficient for theabove example.Mostlanguagesdefinevalueassignmentasa purecopy. The stateof an object is,

64 IMPERATIVES

R2

at L1

R3

R4

R1 x

y

x

y

2

2

at L3

R3

R4

R2

R1 x

y

x

y

y

x

y

x 4

4

3

3

y

x

y

x

1

1

2

2

1

1

5

5

1

1

at L2

R3

R4

R2

R1 x

y

x

y

y

x

y

x

1

1

2

2

1

1

2

2

Figure5.5 Illustrationof valueassignment.

however, a representationof anabstractvaluecapturingthe interestingprop-ertiesof theobject’sstate.It is oftenthecasethattwo or moredifferentstatesrepresentthesameabstractvalue.For this reason,theprogrammershouldbe


ableto/ definethemeaningof assignmentandequality.The first exampleshows how assignmentmay be definedfor the Point

pattern:

Point:(# x,y: @integerenter(x,y)exit(x,y)#)

Assignment(andaswe shall seelater, equalityalso)is definedby meansoftheenterandexit parts.Considerthefollowing assignments:

(11,22)->R1; {1}R1->R2; {2}

In line 1, thevalues11 and22 areassignedto theenterpartof R1, i.e. x andy areassigned.In line 2, the elementsof the exit-list of R1 areassignedtothe correspondingelementsof the enter-list of R2. As canbe seen,thereistechnicallynodifferencebetweenassignmentandparametertransferin apro-cedureinvocation.ThePoint patternmayhave a do-part,asin thefollowingexample:

Point:(# x,y,count: @integerenter(x,y)do count+1->countexit(x,y)#)

As for procedureinvocation,thedo-partwill beexecutedeachtime a Pointobjectis assignedfrom and/orto. Thenumberof timesthis happensfor eachobject is countedin the Count variable. By makingCount global to Point ,thetotal numberof accessesto Point objectscouldbecounted.

5.6.1 Equality

As thereis a distinctionbetweenreferenceassignmentandvalueassignment,thereis alsoadistinctionbetweenreferenceequalityandvalueequality. Con-siderthefollowing example:

(# a,b: @integer;R1, R2: ˆPoint;B1,B2,B3: @boolean

66 IMPERATIVES

do ...(a = b)->B1; {1}(R1[] = R2[])->B2; {2}(R1 = R2)->B3 {3}

#)

In line 1, a valuecomparisonbetweentwo integerobjectsis described.Valueequalityfor the basicpattern,like integer , works in the usualway. Line 2describesareferencecomparison:thecomparisonis trueif thetwo referencesdenotethesameobject.

Line 3 describesavaluecomparisonbetweentwo pointobjects:this com-parisonis true if the ‘value’ of the two objectsis the same. Valueequalityheremeansthatelementsof theexit list of R1 arecomparedto correspondingelementsof theexit list of R2, i.e. theexit partis alsousedfor describingwhatto comparein avalueequality.

If a do-partis presentit will be executedprior to comparisonof the exitlists. TheCount variablein Point will alsocountthenumberof comparisons.

It shouldnow bepossibleto understandthedetailsof all theexamplesofif-imperativesfrom Section5.3 involving valueequality.

Furtherdetailsof assignmentandequalityaredescribedin Section5.8.

5.6.2 Basicpatterns

Referenceassignmentand equality are not available for basicpatternslikeinteger . In principle, thereis no reasonfor this restriction; the restrictionis only dictatedby efficiency reasons.If it waspossibleto have generalref-erencesto, say, integer objects,then memorymanagementwould be moreexpensive. However, in practicetheredoesnot seemto beany needfor this.

5.7 Computed referencesand computed remotename

Considerthebankingexamplein Figure4.2with thefollowing procedurepat-ternadded.It findstheaccountof a givencustomer, andif thecustomerdoesnothaveanaccount,a new oneis created.

GetAccount:(# C: ˆCustomer; rA: Âccountenter C[]do (for i: noOfCustomers repeat

(if C.name[]->CustomerFile[i].name.eq ual//true then AccountFile[i][]->rA[]

if)

5.8 DETAILED DESCRIPTIONOFEVALUATIONS 67

for);(if rA[]//NONE then C[]->NewAccount->rA[] if)

exit rA[]#)

Thispatternmaybeusedas:

Joe: ˆCustomer; acc: Âccount; bal: @integer...Joe[]->BankSystem.getAccount->acc[];acc.balance->bal

If we are simply interestedin the balanceof Joe ’s account,we may useacomputedreferenceto accessthebalance andavoid introducingthereferencevariableacc :

(Joe[]->BankSystem.getAccount).balan ce->b al

Theresultof theevaluationJoe[]->BankSystem.getAccount is a dynamicreferenceto an Account . Theevaluationis saidto be a computedreference,sinceit is theresultof anevaluationof aproceurepattern.A procedurepatterncomputesa referenceif its exit-list hasoneelementwhich mustbeadynamicreference.A computedreferencemay be usedin a computedremotename,whichhastheform:

(ComputedReference).name

The result of ComputedReference must be a referenceR. Let R be quali-fied by T. The name mustbe an attribute of T. The computedremotename(ComputedRemote).name denotestheattributename of theobjectreferencedby R.

Since Joe[]->BankSystem.getAccount computesa referenceto theAccount objectof Joe , thecomputedremotename:

(Joe[]->BankSystem.getAccount).balan ce

denotesthebalance accountof Joe ’saccount.

5.8 Detaileddescription of evaluations

In Chapter2,differentkindsof propertiesthatmaybeusedto characterizephe-nomenawerebriefly mentioned.Amongtheseweremeasurablepropertiesofphenomena.A measurablepropertymaybeobtainedby observingthestateofoneor moreobjects.To performsuchanobservationit is necessaryto perform

68 IMPERATIVES

a measurement, which is an action-sequencethat resultsin a measurement.1

A measurementmaybedescribedby a valueand/orcomparedto othermea-surements.A valueis an abstractionwhich classifiesmeasurements.In thefollowing weshallsaythatameasurementproducesavalue.

In BETA a measurableproperty is reflectedby an object that producesa valueasa resultof executingthe object. The representationof a value isdescribedby the exit-part of the objectbeingexecuted.Sincemeasuringin-volvesacomputation,theresultingvaluemaydependuponthestateof severalobjects.

Thenotionof assignmentis dualto measurement.Assignmentmeansen-forcing avalueuponthestateof oneor moreobjects.

An evaluationis the basicmechanismfor specifyingan actionsequencethatmaycausestatechangesand/orproduceavalue.Thenotionof anevalua-tion is a unifiedapproachto assignment,function-callandprocedure-call.Anevaluationmayspecifyeitheranimperative,ameasurement,anassignmentora transformation:

0 An evaluation-imperative(or justevaluation) describesanactionsequence.0 An evaluationspecifyinga measurementdescribesanactionsequencethat

computesa value.0 An evaluationspecifyingan assignmentdescribesan actionsequencethat

enforcesavalueon thestateof someobjects.0 An evaluationspecifyinga transformationdescribesanactionsequencethat

enforcesa value on the stateof someobjectsand computesa value. Atransformationis thusa combinationof anassignmentanda measurement.

Considerthefollowing object:

X: @(#enter E0do E1->E2->E3exit E4#)

ThewholeevaluationE1->E2->E3 describesanevaluationimperative,E4 andE1 describemeasurements,E2 describesa transformation,andE3 andE0 de-scribeassignments.Thiswill befurtherelaboratedbelow.

An evaluationmaybedescribedasanobject,anevaluationlist, or asanas-signmentevaluation.In thefollowing, themeaningsof thesethreeevaluationformsaredescribed.

1Note that measurementhereis both usedas an action and as the result of an action.Accordingto Webster:1. Theact of measuringor conditionof beingmeasured.2. Extent,size,etc.asdeterminedby this.


5.8.1 Object evaluation

An evaluationmay be describedasan objectevaluation. The objectmay beobtainedby meansof a referenceor agenerationusingapattern.It mayspec-ify anevaluationin oneof thefollowing ways:

0 Imperati ve Theresultof executingthedo-partof theobject.0 MeasurementTheresultof executingthedo-partof theobjectfollowedby

evaluatingthe exit-part of the object. The valueproducedis the measure-mentproducedby theexit-part.

0 AssignmentTheobjectmaybeassigneda value. Thevalueis assignedtotheenterpartof theobjectfollowedby executingthedo-partof theobject.

0 Transformation A valueis enforcedupontheassignmentdescribedin theenter-part of the object, followed by executingthe do-partof the object,followed by evaluatingthe measurementdescribedin the exit-part of theobject.

In thefollowing, exampleX is theobjectdefinedabove:

0 Imperati veAn objectevaluationusedasanimperativemaybespecifiedasfollows:

X

Theresultof this is thatE1->E2->E3 is executed.0 MeasurementAn objectevaluationusedasa measurementmaybespeci-

fied asfollows:

X->...

Theresultof this is thatE1->E2->E3 is executedfollowedby theexecutionof E4. Thevalueproducedby E4 will beassignedto whateverthedots(... )standfor.

0 AssignmentAn objectevaluationusedasanassignmentmaybespecifiedasfollows:

...->X

Theresultof this is that thevalueproducedby whatever thedotsstandforis assignedto E0, whereafterE1->E2->E3 is executed.

0 Transformation An object evaluation usedas a transformationmay bespecifiedasfollows:

70 IMPERATIVES

...->X->...

Theresultof this is thatthevalueproducedby theleft-mostdotsis assignedto E0, then E1->E2->E3 is executed,and finally E4 is executed,and thevalueproducedis assignedto theright-mostdots.

5.8.2 Evaluation list

An evaluationlist hastheform:

(E1,E2,...,En)

An evaluationlist mayspecifyanevaluationin oneof thefollowing ways:

0 Imperati veThen imperativesEn areevaluatedin someorder.0 MeasurementDescribesa compoundvalue(M1,M2,...,Mn) , whereeach

Mi is describedby Ei .0 AssignmentDescribesassignmentof acompoundvalue(M1,M2,...,Mn) ,

whereeachMi is assignedto Ei .0 Transformation Describes a transformation of a compound value

(M1,M2,...,Mn) into anothercompoundvalue (Q1,Q2,...,Qn) , whereeachtransformationEi describesthetransformationfrom Mi to Qi .


(# x,y,z: @integer;A,B: @

(# i,j,k: @integerenter(i,j,k)do i+2->i; j+3->j; k+4->kexit(k,j,i)#)

do 111->x; 222->y; 333->z;(x,y,z); {1}(x,y,z)->A; {2: A.i=113, A.j=225, A.k=337}A->(x,y,z); {3: A.k=x=341, A.j=y=228, A.i=z=115}A->(x,y,z)->B; {4: A.k=345=x, B.i=347,

A.j=231=y, B.j=234,A.i=117=z, B.k=121}

#)

0 Imperati ve - 1 . above is anexampleof anevaluationlist usedasanimper-ative. This exampleis not interesting,sinceexecutionof x , y andz hasnoeffect.


0 Measurement - 2 . is an exampleof an evaluationlist usedasa measure-ment:theevaluation(x,y,z) describesameasurementproducingthecom-poundvalue(111,222,333) , which is assignedto A.

0 Assignment - 3 . is an exampleof an evaluation list usedas an assign-ment: the compoundvalueproducedby A ((341,228,115) ) is assignedto (x,y,z) .

0 Transformation - 4 . is an exampleof an evaluationlist usedasa trans-formation: the compoundvalue (345,231,117) is assignedto (x,y,z) ,which is subsequentlyassignedto B.

5.8.3 Assignmentevaluation

An assignmentevaluationhastheform:

E1->E2->...->En

It mayspecifyanevaluationin oneof thefollowing ways:

0 Imperati ve

– E1 describesameasurementproducingthevalueM1

– E2 describesa transformationbeingassignedthevalueM1andproducingthevalueM2

– ...

– En describesanassignmentbeingassignedthevalueMn-1

0 Measurement Identicalto imperative, exceptthat En describesa transfor-mationwhich, in additionto beingassignedMn-1 , alsoproducesMn.

0 AssignmentIdenticalto imperative,exceptthatE1 describesa transforma-tion which is assignedsomemeasurementM0andproducesM1.

0 Transformation Identicalto imperative,exceptthatE1 describesatransfor-mationwhich is assignedsomevalueM0andEn describesa transformationproducingsomevalueMn


(# a,b,c,d,e,f,g: @integerenter a->b {1}do b->c->d->e {2}exit f->g {3}#)

0 Imperati ve - 2 . is anexampleof anassignmentevaluationusedasan im-perative.

72 IMPERATIVES

0 Measurement - 3 . is an exampleof an assignmentevaluationusedas ameasurement.

0 Assignment - 1 . is anexampleof anassignmentevaluationusedasanas-signment.

0 Transformation c->d within - 2 . is anexampleof anassignmentevalua-tion usedasa transformation.

Notethattherecursive definitionof assignmentmeansthat thedo-partof ob-jectsbeingassignedduringavalue-transferarealsoexecuted.

5.8.4 Value relations

Values(measurements)canbecomparedusingtherelationaloperators=, <>,etc. In addition,theif-imperativemakesuseof valueequality.

Let E1 andE2 betwo evaluationsspecifyingmeasurements.E1 andE2 areequalif the two measurementsM1 andM2 producedby evaluatingE1 andE2,respectively, areidentical.

For the basicpatternsinteger , char , boolean and real we have thatinteger -objectsareassignableto integer -objects,etc.As describedin Sec-tion 3.3.3,it is alsopossibleto assignchar objectsto integer objects,etc.

It is also possibleto assigninteger objectsto real objects,and viceversa:

I: @integer; X: @real...I->X; X->I; 13->X; 3.14->I

Suchassignmentsimply the usualconversionbetweeninteger numbersandfloatingpoint numbers.

As alsomentionedin Section3.3.3,it is alsopossibleto compareinstancesof thebasicpatternsusingrelationaloperators.

As mentionedin Section4.2, it is possibleto assigna text constantandatext objectto anothertext object.It is, however, notpossibleto comparetextobjectsusingtherelationaloperators.Thetext patterndefinedin theMjølnerBETA Systemhasvariousattributesfor comparingtext objects,includinganoperationthattestsfor theequalityof two text objects:

T1[]->T2.equal

5.9 Block structur eand scoperules

The differencebetweenthe declaration of a nameand the application of anameis a fundamentalissue.Considerthefollowing object:

5.9 BLOCK STRUCTUREAND SCOPERULES 73

(#1 R1: @Point; {1}R2: ˆPoint {2}

do R1[]->R2[] {3}#)

Line 1 containsa declarationof thenameR1 andanapplicationof thenamePoint . Theapplicationof Point refersto a declarationof Point somewhereelsein theprogram.Line2hasadeclarationof R2andanapplicationof Point .Thenamesusedin line 3 arebothapplicationsreferringto thedeclarationsinlines1 and2.

Most programminglanguageshave a unit in which all declarationsofnamesmustbe different,i.e. the samenamemay not be declaredmorethanonce. In addition,eachdeclarednamehasa scope, which is that part of theprogramtext whereapplicationsof thesamenamereferto thedeclaration.

In BETA, all namesdeclaredin the attribute part of an objectdescriptormust be unique. The scopeof a declarednameis the object descriptorinwhich it is declared.Sinceobjectdescriptorsmaybetextually nested,adecla-ration in aninternalobjectdescriptormayhidea declarationin theenclosingobjectdescriptor. Also, theindex variableof a for-imperativeandthelabelofa labeledimperative mayhidenamesdeclaredin theenclosingprogramtext.In thefollowing example,anidentifierof theform a 1 refersto thea declaredin line 1, etc.:

(# a: ...; b:...; i:...; {1}P: (# a:...; c: ... {2}

do (for i: ... repeat {3}{Visible names:

b_1,a_2,c_2,i_3}for)

#)do (# b: ... {8}

{visible names a_1,i_1,b_8}#)

#)

Theabove scoperulesarethe traditionalblock structurerulesfrom Algol 60andPascal,but they do not cover remoteidentifierslike R1.Move . Considerthedeclaration:

R: @T

Any attribute,saya, declaredin T maybeaccessedusinga remoteidentifierof theform:

R.a

74 IMPERATIVES

In BETA, objectdescriptorsmaybetextuallynested.Theexamplessofarhaveshown up to threelevelsof textually nestedobjectdescriptors:the program,a pattern(like Point ) andoperations(like Move). In fact, objectdescriptorsmaybetextually nestedto anarbitrarydepth:this is known asblock structure.

Block structureis animportantmechanismfor structuringindividualcom-ponentsof a largeprogram,andis a meansfor providing locality of declara-tions.For moreexamplesof usingblock structure,seeChapter8.

We have previously mentionedtheorigin attributeusedto accessglobalattributes.In fact,all objectshaveanorigin attributereferringto its enclosingblock. Considerthefollowing example:

(# a: @integer;P: (# b: @integer;

T: (# c: @integerdo a+b->c;#)

do a * 2->b#);

do 1->a; &P#)

Theuseof globalattributesis handledby usingorigin asfollows:

(# a: @integer;P: (# b: @integer;

T: (# c: @integerdo origin.origin.a+origin.b->c;#)

do origin.a * 2->b#);

do 1->a; &P#)

The above scoperules will later be extendedto cover sub-patternsandvirtual patterns,asintroducedin Chapters6, 7 and9.

5.10 Object kinds and construction modes

Thissectionintroducesthenotionsof objectkindandconstructionmode. Ob-ject kind is usedto classify objectsas either sequentialor multi-sequential(coroutinesor concurrency). Constructionmodedefinesthedifferentwaysforconstructingandgeneratingobjects.

5.10 OBJECTKINDS AND CONSTRUCTION MODES 75

5.10.1 Object kinds

In this chapterit hasbeenshown how to generateobjectscorrespondingtoclassobjects,andprocedureobjects,etc. Theseobjectsall relateto programexecutionsconsistingof onesequentialactionsequence.It is possibleto gener-ateobjectswhich maybeexecutedascoroutinesandasconcurrentprocesses.For this purposethereis a distinctionbetweendifferentobjectkinds. BETAhastwo kindsof objects:componentanditem. Thekind of anobjectspecifieshow theobjectcanbeexecuted.

0 A componentobject(coroutine)maybeexecutedconcurrentlyoralternatelywith othercomponents.

0 An item object is a partial action sequencecontainedin a componentoritem.

In this chapterobjectsof the item kind have beendescribed.Objectsof thecomponentkind aredescribedin Chapters13–15.

5.10.2 Construction modesand insertedobjects

In theprecedingsectionstwo differentmodesfor generatingobjectshavebeenshown. Objectsmaybe createdstaticallyby declaration,or createddynami-callybya‘new’-imperative.Thesedifferentwaysof creatingobjectsarecalledconstructionmodes. Theconstructionmodegivesriseto two sortsof objects,respectively calledstatic anddynamicobjects. Thereis a third constructionmodecalledinsertedobject, describedin thenext section.

As mentionedpreviously, theinvocationof a patternasa proceduregivesrise to thegenerationof anobjectfor representingtheaction-sequencebeinggeneratedby executionof theprocedure.Thisleadsto thegenerationof alargenumberof small objects. Theseobjectshave to be generatedand removedby the storagemanagementsystem,which may be quite expensive. For thisreasonit is possibleto describethatsuchprocedureobjectsbegeneratedasapermanentpartof theobjectinvoking theprocedurepattern.

As shown previously, a patternP may be usedto generatea procedureobjectasfollows:

E->&P->A

Thegenerationof aninserteditem is doneasfollows:

E->P->A

TheP object(calledan inserteditem) will beanintegral partof theenclosingobject. This inserteditem will then be executedwhen control reachesthe

76 IMPERATIVES

evaluationimperative. Thestateof this P item will beundefinedprior to eachexecutionof it. Thenotionof aninserteditemis similarto anin-line procedurecall.

Apart from the allocation, the executionof an inserteditem is like theexecutionof any other object. In the above case,the executionassignstheoutputof E to theenter-partof the insertedP item, andcausesthe instancetobeexecuted.Finally, theexit-part of theinsertedP instanceis assignedto A.

Theevaluation:

(11,22)->P1.Move

specifiesan inserteditem for the patternP1.Move. This temporaryinstanceis actually allocatedas part of the object executingP1.Move . In this way,P1.Move describesan in-line allocationof a Move instance.

As alreadymentioned,insertedobjectsareallocatedin-line in thecallingobject. Themotivationfor insertedobjectsis a matterof efficiency, sincethecompilermaycomputethestoragerequirementsof thecallingobject.Insertedobjectsareanalogousto staticobjectsin the sensethat they areallocatedaspartof theenclosingobject.

With this semanticsof inserteditems,it follows thatinserteditemscannotbeusedto describerecursive procedures,sincethis will leadto aninfinite re-cursion.This is analogousto staticitems,whichcannotbeusedfor describingrecursivedatastructures.

5.10.3 Summary of construction modes

As mentionedin theprevioussection,objectsmaybeof two differentkinds.Theobjectsdescribedin thischapterareof theitemkind; below wesummarizetheconstructionmodesfor objectsof this kind:

0 Static items The following declarationsdescribethe generationof staticitems:

E: @P; {1}F: @P(# ... #); {2}G: [...] @P; {3}H: [...] @(# ... #) {4}

whereP is a patternname,E andF arestatic references,andG andH areindexedcollectionsof staticreferences.Thestaticitemsgeneratedby lines1 and3 arepatterndefined,whereasthe static itemsgeneratedby lines 2and4 aresingular.

0 Dynamic items The following imperativesdescribethe generationof dy-namicitems:

5.10 OBJECTKINDS AND CONSTRUCTION MODES 77

(# P: (# I,J: @integer;enter(I,J)do I+J->Iexit(J,I)#);

E: @P; {declaration of a static (part) item}X: ˆP; {declaration of reference to an item}N,M: @integer;

do {generation of a dynamic P-item and}{subsequent assignment of the reference X}&P[]->X[];

{an evaluation using static, inserted and dynamic items}(3,4)->E->P->E->&P ->X ->P ->( N,M)

#)

Figure 5.6 Exampleof dynamicitems.

e1->&P->e2; {1}e3->&P(# ... #)->e4; {2}&P[]->R1[]; {3}&(# ... #)[]->R2[] {4}

Lines1 and2 describethegenerationof dynamicitemswhich areimmedi-atelyexecutedasprocedureobjects.Lines3 and4 describethegenerationof dynamicitems,wherereferencesto thenew objectsareassignedto dy-namicreferenceattributes.Lines1 and3 describethegenerationof patterndefinedobjects,whereaslines 2 and4 describethe generationof singularobjects.

0 Inserted items The following imperativesdescribethe generationof in-serteditems:

e1->P->e2; {1}e3->(# ... #)->e4; {2}

Line 1 describesthegenerationof a patterndefinedobject,whereasline 2describesthegenerationof asingularobject.

In Figure5.6, examplesaregiven of the threedifferentconstructionmodes.The lastevaluationinvolvestwo executionsof thestaticitem E, executionoftwo different inserteditems(specifiedby the two Ps), andexecutionof two

78 IMPERATIVES

differentdynamicitems,onedenotedby X andananonymousonegeneratedduringtheevaluationby &P.

Thenotionsof kind andconstructionmodeareorthogonal,sinceobjectsofthekind componentmayalsobecreatedeitherstatically, insertedor dynami-cally.

5.11 Exercises

(1) Write apatternthattransformsaUNIX pathof theform:

/users/smith/src/beta

into thecorrespondingMacintoshform:

:users:smith:src:beta

andviceversa.

(2) Modify the bankingexamplefrom Exercise2 in Chapter3. Include apatternfor computingthesumof thebalanceof all accountsfor aspecificcustomer, andonefor deletingall accountsfor aspecificcustomer.

(3) Write a patternthat computesall prime numberslessthan100usingthesieve of Eratosthenes.Constructa list of objectscontainingthenumbers2243534362 100. For eachi where2 <= i <= 100 , eliminateall elementsofthelist containinga numberthatis divisible by i . Theremaininglist willhaveall primenumberslessthan100.

Write thepatternin suchawaythatit is easyto useavalueotherthan100,i.e. thevalue100shouldbea parameterto thepattern.

Make a solutionwherethe list is representedusinga repetition,andonewhereit is a linked list using references.The prime patternshouldbeindependentof theactualrepresentationof thelist.

(4) Write patternsfor standarddatastructureslike stack,queue,dequeandtree.

(5) Designandimplementasimplesodamachinewhich‘dispenses’twokindsof drinks, cola and juice. The sodamachineshouldhave the followingproperties:

1. Oneor morecoinsmaybeinserted.

2. If enoughmoney has been inserted, the appropriatedrink pluschangemaybeobtained.

3. Themachineshouldkeeptrackof thecurrenttotalamountof money,andthecurrentnumberof colasandjuices.

5.12 NOTES 79

4. Thecustomermayresetthemachineandgetbackthemoney he/shehasinserted.

5. It will bepossibleto refill themachineandtakeout themoney.

6. It will bepossibleto adjusttheprice for thedrinks. Theprice for acolaanda juice maybedifferent.

5.12 Notes

Imperativessuchasassignment,for-imperative, if-imperative andlabelsandjump-imperativeshave beenaroundsincethe early programminglanguages.In mostlanguages,theBETA assigment:

exp->V

is expressedlike

V := exp

For BETA it wasfelt that it is morenaturalto expressan assignmentin theorderof evaluation. This is especiallythecasefor multiple assignmentsandcombinationsof function calls. In BETA it is possibleto combinearbitraryfunctioncalls in anevaluation.Considerthefollowing Algol-lik eassignmentstatement,whereF, GandH arefunctions:

var := F(G(exp1),H(exp2,exp3))

Thismaybeexpressedin BETA in thefollowing way:

(exp1->G,(exp2,exp3)->H)->F->var

In somelanguagesthereis a distinctionbetweena procedureanda function,in thesensethata functionmayreturna valueandbeusedin anexpression.In most languages,a function may returnexactly onevalueandnot a list ofvalues,asin BETA. TheBETA patternis, amongotherthings,aunificationofproceduresandfunctions,anda procedure/functionpatternmay returna listof values. As mentionedin Section3.3.2,the importantdistinctionbetweena procedurepatternanda function patternis that the latter shouldnot haveside-effects.

Wehavementionedthesimilaritiesbetweeninserteditemsandin-line pro-cedurecalls,andbetweendynamicitemsandAlgol-lik e procedureactivationrecords.Wealsonotethatastaticitemmaybeusedasa staticsubroutine.

The registerexamplein Figure5.2 is similar to Hoare’s small integerset(Hoare,1972).

80 IMPERATIVES

Chapter 6

Sub-patterns

As describedin Chapter3, patternsmay be usedto representconcepts.Theforms of patternsusedso far are sufficient as long as the extensionsof theconceptsbeing modeledare disjoint, i.e. the set of objectsgeneratedfromdifferentpatternsaredisjoint. In practice,therearenumeroussituationswherethisis notthecase.Considertheclassificationhierarchyfor animalsillustratedin Figure2.2in Chapter2. Theextensionsfor lion andtigerareclearlydisjoint,but the extensionfor predatorincludesthe extensionsfor lion and tiger. Inthischapter, languageconstructsfor representingclassificationhierarchiesliketheseareintroduced.

6.1 Specializationby simple inheritance

Considera travel agency which handlesreservationsof severalkinds,includ-ing flight andtrain reservations.Whendesigninga computersystemfor han-dling reservations,it is thusnaturalto formulateconceptssuchastrain reser-vation andflight reservation. Patternsfor representingthe conceptsof flightreservationandtrain reservationmaybedescribedin thefollowing way:

FlightReservation:(# Date: ...

Customer: ...ReservedFlight: ...ReservedSeat: ...

#);TrainReservation:

(# Date: ...Customer: ...ReservedTrain: ...ReservedCarriage: ...ReservedSeat: ...

81

82 SUB-PATTERNS

Reservation

FlightReservation TrainReservation

Figure6.1 Classificationhierarchyfor reservations

#)

The above patternsinclude the propertieswe may want to model for flightreservationsandtrain reservations.

Flightandtrainreservationshavesomecommonpropertiessuchasthedateof thereservationandthecustomerwho hasmadethereservation. They alsodiffer in variousways:aflight reservationincludesareferenceto theflight andinformationaboutreservedseat,etc.;a train reservation includesinformationaboutthe train, thecarriageandtheseat.In additionto theflight reservationandtrain reservationconcepts,it is usefulto defineageneralconceptof reser-vation covering the commonpropertiesof flight andtrain reservations. Thisgivesriseto asimpleclassificationhierarchyfor reservations,asillustratedinFigure6.1.

Supposethat we also want to model the conceptreservation, which in-cludesthe commonpropertiesof flight reservationsand train reservations.Thiscouldbedescribedas:

Reservation:(# Date: ...

Customer: ...#)

There are, however, no relations betweenthe pattern Reservation andthe patternsFlightReservation and TrainReservation . The descrip-tion does not include the property that Reservation is a generalizationof FlightReservation and TrainReservation . The objectscreatedasinstancesof the three patternswill form three disjoint sets (have disjointextensions). Instancesof Reservation bear no relation to instancesofFlightReservation . Finally, the descriptionof commonattributessuchasDate andCustomer hasbeenrepeatedthreetimes.

In the real world we considerall flight reservations to be reservations.Likewise,in our programexecutionwe alsowant to considerall instancesof

6.1 SPECIALIZATION BY SIMPLEINHERITANCE 83

FlightReservation7 to beinstancesof Reservation . Similarly, all instancesof TrainReservation shouldalsobeconsideredinstancesof Reservation .

For the purposeof representingsuchclassificationhierarchies,patternsmaybeorganizedin sub-patternhierarchies.A sub-patternis a patternwhichis aspecializationof anotherpattern.

Thereservationconceptsmaybemodeledin thefollowing wayusingsub-patterns:

Reservation:(# Date: @DateType;

Customer: ˆCustomerRecord#);

FlightReservation: Reservation(# ReservedFlight: ˆFlight;

ReservedSeat: ˆSeat;#);

TrainReservation: Reservation(# ReservedTrain: ˆTrain;

ReservedCarriage: ˆCarriage;ReservedSeat: ˆSeat;

#)

By prefixingtheobjectdescriptorfor FlightReservation by Reservation ,the object descriptor for FlightReservation inherits all the declara-tions from Reservation , meaningthat the attributes Date and Customerwill be inherited from Reservation . Objects generatedaccording toFlightReservation will have the attributes Date and Customer (fromReservation ), plusReservedFlight andReservedSeat .

Similarly, objectsgeneratedaccordingto TrainReservation will havethe attributes Date , Customer (from Reservation ), ReservedTrain ,ReservedCarriage andReservedSeat .

This is an example of specialization by simple inheritance of at-tributes.We saythatFlightReservation andTrainReservation aresub-patterns of Reservation , and that Reservation is the super-pattern ofFlightReservation andTrainReservation .

Thereasonthatapatternlike FlightReservation is calleda sub-patternof Reservation is that the setof all FlightReservation objectsis a sub-setof all Reservation objects.Similarly, thesetof all TrainReservationobjects is a subsetof all Reservation objects. In addition, the set ofFlightReservation objectsandthe setof TrainReservation objectsaredisjoint, illustratedin Figure6.2. Thesamemaybeexpressedin termsof ex-tensionsof concepts:theextensionof FlightReservation is a subsetof theextensionof Reservation .

84 SUB-PATTERNS

Reservation

FlightReservation TrainReservation

Figure 6.2 Subsetrelationsfor extensionsof reservationpatterns

Thesetof objectsgeneratedfrom a patternconstitutesits extension.Theintension of a conceptrepresentedby a pattern is defined by its object-descriptor, which representsthe propertiesof the object in termsof its at-tributes and action-part. For example, the Reservation pattern’s object-descriptorstatesthat elementsin the extension(Reservation objects)allhave a Date and a Customer attribute. For the FlightReservation pat-tern,additionalpropertiesaredescribed:elementsin theextensionalsohavea ReservedFlight anda Customer attribute. Whenwe definea sub-pattern,we definea patternthathassomeadditionalpropertiesin additionto thoseofthesuper-pattern.Addingnew propertiesrestrictsthesetof possibleinstances.Thismaybesummarizedasfollows:

0 The intensionof a sub-patternextendsthe intensionof the super-pattern,sincemorepropertiesareadded.

0 The extensionof a sub-patternis a subsetof the extensionof the super-pattern,sincemorepropertiesmustbefulfilled.

As alreadymentioned,thekind of propertiesthatcanbeaddedarethosethatcanbedescribedby anobject-descriptor. Examplesof suchpropertiesincludenew attributes,the qualificationof the attributes,whetheror not it is a partobjector a referenceto a separateobject,etc. Propertiesdescribingactionsexecutedby an objectareanotherexample. Later in this chapterwe presentexamplesof specializingtheaction-part.

Object generation

Thereservationpatternsmaybeusedto generateobjects:


T1:8 @TrainReservation;F1: @FlightReservation;T2: ˆTrainReservation;F2: ˆFlightReservation;...T1[]->T2[]; &FlightReservation[]-> F2[]

It is alsopossibleto generateinstancesof Reservation :

R1: @Reservation;R2: ˆReservation...&Reservation[]->R2[];

This may not be very usefulsinceour reservation systemwill handleeithertrain reservationsor flight reservations. Patternslike Reservation that arejust usedassuper-patterns,but neverusedfor generatinginstances,arecalledabstractsuper-patterns.

In Section3.2.5thenotionof aqualifiedreferencewasintroduced.Theref-erencesR1,T1,F1 ... arequalifiedby Reservation , TrainReservation ,FlightReservation , ... . Thequalificationof a referencerestrictsthesetofobjectsthatmaybereferredto by thereference.In addition,thequalificationdetermineswhich attributesmaybedenotedby remoteaccess.For R1, T1,F1 ... it is possibleto accessattributeslike:

R1.Date T1.Date T1.ReservedTrain F2.ReservedFlight ...

whereasthefollowing remoteidentifiersarenot legal:

R1.ReservedSeat T2.ReservedFlight F1.ReservedTrain ...

Usingsuper-patterns for qualifying references

Considerthefollowing declarations:

R: ˆReservation;F: ˆFlightReservation;T: ˆTrainReservation

Thesedeclarationsstatethat R mayrefer to Reservation objects,F mayre-fer to FlightReservation objects,andT may refer to TrainReservationobjects. From a conceptualpoint of view, FlightReservation objectsarealsoReservation objects,which meansthatR shouldbeallowedto refer toFlightReservation objects,andthatis alsotherule. It is possibleto performthefollowing referenceassignment:

86 SUB-PATTERNS

Date

FlightReservation

Customer

ReservedFlight

ReservedSeat

R

F

T

At L1

R

F

T

Date

FlightReservation

Customer

ReservedFlight

ReservedSeat

At L2

Figure6.3 A Reservation referencemayreferto instancesof sub-patternsof Reservation .

L1:F[]->R[];

L2:

At thelabelL1 it isassumedthatF denotesaninstanceof FlightReservation ;at thelabelL2, R will alsoreferto this instanceof FlightReservation , illus-tratedin Figure6.3.

Using R it is possible to refer to the attributes Date and Customeras describedby the Reservation pattern. This meansthat R.Date andR.Customer are legal. R refers to a FlightResevation object, butsince R is qualified by Reservation , we may only make useof the gen-eral Reservation properties. It is not possibleto refer to the attributesReservedFlight and ReservedSeat , even though it is known that R de-notes a FlightReservation object, becausethe descriptionof R statesthat R may denotearbitrary Reservation objects. This meansthat it isnot known whether or not R denotesa FlightReservation object or aTrainReservation object.

Consideranassignmentlike:

R[]->F[]


If R denotes9 a FlightReservation object,thenthis is meaningful.If, how-ever, R denotesa TrainReservation object,this is not meaningful,sinceFis supposedto denoteonly FlightReservation objects.In general,it is notpossibleto infer from thedescriptionof R andF andtheassignmentwhetheror not suchan assignmentis meaningful. Whenthe programis executingitcanbetestedwhetheror not theassignmentis meaningful.In BETA theaboveassignmentis consideredlegal. It may, however, leadto a run-timeerror1 if Rdoesnot referto a FlightReservation object.

Theuseof generalsuper-patternsfor qualifying referencesprovidesgreatflexibility . More exampleswill bepresentedlater.

Multi-le vel hierarchies

The classificationhierarchyfor reservationsonly includestwo levels. It ispossibleto model classificationhierarchiesconsistingof an arbitrary num-berof levels,asillustratedby thefollowing example.All Record, Person,Employee, Student andBook objectsmaybeviewedasRecord objects,andthey all have theattributekey . Similarly, Person, Employee and Studentobjectsmay be viewed asPerson objects,andthey all have the Person at-tributeskey , name andsex . This sub-patternhierarchyis illustratedin Fig-ure6.4.

Record: (# key: @integer #);Person: Record(# name: @Text; sex: @SexType #);Employee: Person

(# salary:@integer; position: @PositionType #);Student: Person(# status: @StatusType #);Book: Record(# author: @Person; title: @TitleType #);

Example

Supposethatour travel agency wantsto keepa registerof all reservations.Asimpleversionof sucha registermaybedescribedasfollows:2

ReservationRegister:(# {The reservations are stored in Table[1:top]}

Table: [100] ˆReservation; top: @integer;

Insert: {Insert a reservation into the register}

1In theMjølner BETA Systemthecompilermarksall assignmentsthatrequirea run-timetest.

2Theexample,likemany otherexamplesin thisbook,hasbeensimplifiedto keepit small.In the Insert pattern,it shouldbetestedthat top doesnot exceedTable.range . Similarly,in GetElm it shouldbetestedthat0<inx<=Top .

88 SUB-PATTERNS

Record

Key

Person Book

Employee Student

Key

Name

Sex

Key

Author

Title

Key

Name

Sex

Salary

Position

Key

Name

Sex

Status

Figure6.4 Illustrationof sub-patternhierarchy.

(# R: ˆReservationenter R[]do R[]->Table[top+1->top][]#);

NoOfElm:{Return no. of reservations in register}(# exit top #);

GetElm: {Get reservation no. ’inx’}(# inx: @integer

enter inx


exit Table[inx][]#);

#);Reservations: @ReservationRegister

The Reservations register may containinstancesof FlightReservationandTrainReservation . This meansthat reservationsmay be insertedintotheregisterin thefollowing way:

F: ˆFlightReservation;T: ˆTrainReservation;...F[]->Reservations.Insert; ...T[]->Reservations.Insert; ...

In thedescriptionof theReservationRegister patternit is not necessarytoknow whetherit is a train reservationor a flight reservationthatgetsinserted.For thisreason,all referencesin theReservationRegister patternarequali-fiedby Reservation . Also, theReservationRegister patternwill notneedto bechangedif a new kind of reservation is introduced.If our travel agencywantsto extendits businessto handleboatreservations,we could introducea BoatReservation patternasa sub-patternof Reservation , andthustheReservationRegister patternwouldnotneedto bechanged.

Supposethatwewantto find all reservationsmadeby Mr Olsenandinsertthesereservationsinto a specialregistercontainingall reservationsmadebyMr Olsen.Thiscouldbedoneasfollows:

R: ˆReservation; Olsen: ˆCustomerRecord;OlsensReservations: @ReservationRegister...(for i: Reservations.NoOfElm repeat

i->Reservations.GetElm->R[];(if R.Customer[] // Olsen[] then

R[]->OlsensReservations.Insertif)

for)

In this examplewe do not carewhetheror not the reservationsare train orflight reservations,weareonly interestedin reservationsin general.

Testingpattern membership

Suppose,however, that we are interestedin counting the numberof flightreservationsand the numberof train reservations. Then we would needtoknow for eachelementin the register whetheror not it is an instanceof

90 SUB-PATTERNS

TrainReservation or FlightReservation . Thuswe needto testtheclassmembershipof anobject.Thismaybedoneasfollows:

R: ˆReservation; Olsen: ˆCustomer; NTR,NFR: @integer...(for i: Reservations.NoOfElm repeat

i->Reservations.GetElm->R[];(if R##

// TrainReservation## then NTR+1->NTR// FlightReservation## then NFR+1->NFR

if)for)

The expression R## denotes the pattern of the object referred by R.Similarly, the expression ’TrainReservation##’ denotes the patternTrainReservation . (Rememberthat the expressionTrainReservationwithout ## describesthegenerationof a TrainReservation object.)

Thefirst branchof theif-imperative is takenif theexpression:

R## = TrainReservation##

is true.This is thecaseif R refersto aninstanceof TrainReservation . Simi-larly, thesecondbranchof theif-imperativeis takenif RdenotesaninstanceofthepatternFlightReservation . As we shallseelater, it is rarelynecessaryto usethis form of testing,andit shouldbe avoided,asdemonstratedin thenext chapteron virtual patterns.

6.2 Specializationof actions

Patternsmayalsobeusedto modelconceptswheretheextensionconsistsofsequencesof actions.We have previously referredto suchpatternsasproce-dure patterns.By meansof sub-patternsit is possibleto modelclassificationhierarchiesfor actionsequences.ConsidertheconceptHandleReservation :anelementin theextensionof thisconceptis anaction-sequenceperformedbyan agentwhenmakinga reservation. This conceptmay have specializationslike HandleFlightReservation andHandleTrainReservation . To modelsuchclassificationhierarchies,it is necessaryto beableto combinetheactionpartof asuper-patternwith theactionpartof asub-pattern.


C: (# a,b: @integerdo 11->a;

inner C33->b

6.2 SPECIALIZATION OFACTIONS 91

Execution of an instance of C1 starts here

C1: C(# c: @integer do 22->c #)

C: (# a,b: @integer do 11->a; inner C; 33->b #)

OBS. The printed version does not look like the drawingTherefore the arrows have to be placed left to

the position where they should appear

Figure6.5 Illustrationof inner .

#);

C1: C (# c: @integer do 22->c #)

Instancesof C1 have the attributesa, b, c . The executionof a C1 objectstartsby executionof theimperativesdescribedin C. Eachexecutionof innerC duringtheexecutionof theseimperativesimpliesanexecutionof theimper-ativesdescribedby C1. An executionof a C1 objectimpliesexecutionof:

11->a,22->c and33->b.

illustratedin Figure6.5.Executingan instanceof the C-patternwill result in executionof 11->a ,

followedby 33->b , i.e.executionof inner C is theemptyaction.Theimperative inner C is only legal in thedo-partof thepatternC.Theinner constructis themechanismthatis providedfor specializationof

actions,which maybeobtainedin two ways: asa specializationof theeffectof thegeneralaction,or asaspecializationof thepartiallyorderedsequenceofpart-actionsthatconstitutethegeneralaction.Theinnermechanismsupportsthelatterform of specialization.

Here is anotherexample illustrating the usefulnessof specializationofaction-parts:

Cycle: (#do (Loop: inner Cycle; restart Loop :Loop) #)

TheCycle patternrepeatedlyexecutesan inner-imperative,andmaybeusedasacyclecontrolstructure:

92 SUB-PATTERNS

...; Cycle(#do Keyboard.get->Screen.put #); ...

This constructis an example of a singular inserteditem. As mentionedin Section 3.1.1, a singular item (object) in the action part correspondsto an anonymousprocedure. The executionof Cycle implies that innerCycle is executedforever. Each execution of inner Cycle implies thatKeyboard.get->screen.put is executed. Of course,it is possibleto exitthebodyof suchacycleby executinga leave:

(# F,G: @Filedo {Open the files F and G}

L: Cycle {Copy F to G}(#do (if F.eos {end-of-stream}

// true then leave Lif);F.get->G.put

#);{Close the files F and G}

#)

It is possibleto furtherspecializeCycle :

CountCycle: Cycle(# inx: @integerenter inxdo inner CountCycle;

inx + 1-> inx ;#);

The CountCycle patternis a sub-patternof Cycle . This hasthe effect thatwhenexecutinganinstanceof CountCycle , its do-partwill alsoberepeatedlyexecuted.TheCountCycle patternis usedin thefollowing evaluation:

...;L: 1->CountCycle

(# F: @integerdo (if inx // 10 then leave L if);

inx->& Factorial->F;{Factorial is computed for inx in [1,9]}

#);...

Theeffectof usingCountCycle maybedescribedby thefollowingevaluation:

6.2 SPECIALIZATION OFACTIONS 93

Register:(# Table: [100] ˆRecord;

Top: @integer;

Init: (# ... #);Has: (# key: ˆRecord enter key[] do ... #);Insert: (# ... #);Remove: (# ... #);

ForAll:(# Current: ˆRecorddo (for inx: Top repeat

Table[inx][]-> Current[];inner ForAll

for)#)

#)

Figure 6.6 Iteratoron theRegister pattern.

L: 1 ->(# inx: @integer; F: @integer

enter inxdo

(Loop:(if inx // 10 then leave L if);inx->& Factorial->F;inx + 1->inx;restart Loop :Loop)

#)

ThepatternsCycle andCountCycle areexamplesof usingpatternsfor defin-ing controlstructures.Suchpatternswill bereferredto ascontrol patterns.

Specializationof actionsmaybeusedfor makinggeneralcontrolstructurestailoredto specificdatastructures.Figure6.6 describesa new versionof thepatternRegister from Chapter3. The new versiondescribesa registerofRecord objects,andanew patternattribute,ForAll , hasbeenadded.ForAllis a controlpatternwhich scansthroughtheelementsof the register, makingit possibleto stepthroughall the elementsof a Register and perform anoperationuponeachelement,independentlyof how theregisteris represented.

Notice that inner is an imperative, andassuchit maybeusedwhereveran imperative may be used. Theremay also be more than one inner in a

94 SUB-PATTERNS

descriptor, in whichcasethey will causeexecutionof thesameactions.TheForAll operationmaybeusedin thefollowing way:

...; R.ForAll (# do Current[]->DoSomething #);...

TheconstructR.ForAll(# ... #) is anotherexampleof asingularinserteditem. It hastheForall patternattributeof theobjectdenotedby R asasuper-pattern.Current will thenstepthroughtheelementsof R andeachelementwill one-by-onebeassignedto DoSomething . Sometimesthereis a needfornestingcontrol patterns.In this case,it is inconvenientthat the nameof theindex variablealways hasto be Current , sincethis makes it impossibletorefer to the index variableof theoutercontrolpattern.This maybechangedby addingthepatternattribute Index to ForAll :

ForAll:(# Current: ˆRecord;

Index: (# exit Current[] #)do ... {As before} ...#)

ForAll maynow beusedasfollows (assumingthatR1 andR2 arereferencesto Register objects):

R1.ForAll(# I: @Indexdo R2.ForAll

(# J: @Indexdo (I,J)->DoMore#)

#)

The attribute I returnsthe valueof Current correspondingto the outermostcontrol pattern,andJ returnsthe valueof Current correspondingto the in-nermostcontrolpattern.

Shorthand notation for inner

Insteadof inner P it is possibleto write just inner . In thiscase,inner refersto theimmediateenclosingobject-descriptor. Considerthefollowingexample:

PP:(#do (# P: (# ...

do {1} inner PP; ...{2} inner P; ...

6.3 ENTER/EXIT-PARTSFORSUB-PATTERNS 95

{3} inner; ...#)

do {4} inner;Cycle(#do {5} inner PP; ... {6} inner; ... #)

#)#)

The inner constructsat 1,2 and 5 are unambiguous,sincethey explicitlyrefer to an enclosingpattern/object-descriptor. The inner at 3 refersdo thepattern/object-descriptorP; the inner at 6 refersto Cycle(# ... #) , sinceitis thenearestenclosingobject-descriptor. This inner will have no effect, asthereis no sub-patternof this descriptor. In general, inner hasno effect ina singular object-descriptor.

6.3 Enter/exit-parts for sub-patterns

Theenter-partof asub-patternis aconcatenationof theenter-partof thesuper-pattern,andtheenter-partspecifiedin thesub-patternandsimilar for theexit-part.Consider:

P: (# ... enter(x,y,z) do ... exit u #);PP: P(# ... enter a do ... exit b #);PPP: PP(# ... enter(n,m) do ... exit(s,t) #)

Thethreepatternshave thefollowing enter- andexit-parts:

Pattern enter-part exit-partP (x,y,z) uPP (x,y,z,a) (u,b)PPP (x,y,z,a,n,m) (u,b,s,t)

In theconcatenationof enter/exit-lists anenter/exit list consistingof a singleelementis consideredto bealist with oneelement.In theaboveexample,exitu, enter a andexit b areinterpretedasexit(u) , enter(a) andexit(b) .

Considerthespecificationof apatternPoint :

(# Point:(# X,Y: @integer;

move:(# x1,y1: @integerenter(x1,y1)do x1->X; y1->Y; inner#)

enter (X,Y)exit (X,Y)

96 SUB-PATTERNS

#);P1,P2: @Point;

do ...; P1->P2; ...; (3,14)->P1.move; ...#)

Point objectsareassignable,andwhenassigningonePoint objectto another,thevaluesof X andY aretransferred.

Considermakinga three-dimensionalpoint asa specializationof Point :for suchpointsto beassignable,theextraattributeZ shouldalsobetransferredin anassignment.This is accomplishedby extendingtheenter- andexit-partsof Point by enter/exit of Z. In addition,a sub-patternmove3D of move hasbeenadded:3

(# ThreeDpoint: Point(# Z: @integer;

move3D: move(# z1: @integer enter z1 do z1->Z; inner #)

enter Zexit Z#);

P1,P2: @ThreeDpoint;do ...; P1->P2; ...; (111,222,333)->P1.move3D#)

Instancesof ThreeDpoint have an enter-part and an exit-part of the form(X,Y,Z) . Theenter-partof move3D is (x1,y1,z1) .

6.4 The object pattern

Thereis apredefinedpattern

Object: (# ... do inner #)

which is themostgeneralabstractsuper-pattern.All patternsaresub-patternsof Object . In anobjectdescriptorwithoutasuper-pattern,theObject patternis implicitly assumedto bethesuper-pattern.An objectdescriptorof theform:

(# Decl1; Decl2; ...; Declnenter Indo Impexit Out#)

is interpretedin thefollowing way:3A betteralternativewill beto definemove asa virtual pattern(seeChapter7).

6.4 THE OBJECTPATTERN 97

Object:(# Decl1; Decl2; ...; Declnenter Indo Impexit Out#)

ThepatternObject hasno attributes. Its action-partconsistsof an inner im-perative. The main purposeof the Object patternis to allow ‘unqualified’references.It is possibleto declarereferenceslike:

R: Ôbject

A referencelike R may refer to any object in a programexecution. Suchareferencecannot,of course,be usedto accessattributesof the objectbeingreferred. It may be usedto executethe objectandto passobject referencesaround.

Restrictionson basicpatterns

As mentionedin Chapter3, therearecertainrestrictionsontheuseof thebasicpatternsinteger , boolean , char and real in the Mjølner BETA System.Onerestrictionis thatthesepatternsarenot sub-patternsof Object .

Anotherrestrictionis that it is not possibleto obtaina dynamicreferenceto instancesof thebasicpatterns.In the following example,codemarkedbyillegal is notacceptedby thecompiler:

X: @integer; {legal}R: înteger; {illegal}

...X[] {illegal}->...

The reasonfor theserestrictionsis efficiency of implementationratherthanany conceptualproblem. It is, however, possibleto get aroundtheserestric-tionsby usingpatternsof theform:

integerObject: (# V: @integer enter V exit V #)

The patternintegerObject is a sub-patternof Object , anddynamicrefer-encescanbeobtainedto suchobjects,asshown in thefollowing example:

X: @integer;Y: @integerObject;Z1,Z2: întegerObject...111->X;

98 SUB-PATTERNS

P: (# Decl1; Decl2; ... Declnenter Indo Impexit Out#);

P1: P(# Decl’1; Decl’2; ... Decl’menter In’do Imp’exit Out’#);

Figure6.7 Sub-patternDeclaration.

222->Y;Y[]->Z1[];333->Z1;&integerObject[]->Z2[];444->Z2;

Be awarethatanassignmentlike:

333->Z1

is only legal if Z1 is differentfrom NONE.TheMjølnerBETA Systemincludespredefinedpatternslike integerObject .

This is conceptuallynot thebestsolution,but it worksin practice.

6.5 Summary

In this sectiona summaryof the sub-patternmechanismwill be given. Anobjectdescriptormay includea super-pattern(oftencalledprefix-pattern, orsimply prefix). This specifiesthatobjectsgeneratedaccordingto thedescrip-tion haveall thepropertiesdescribedby thesuper-pattern.

Figure6.7 shows two patterns,P andP1. P1 is an exampleof a patternthathasa super-pattern.Thesuper-patternof P1 is P; P1 is alsosaidto beasub-patternof P. Any P1-objectwill have thesamepropertiesasP-objectsinadditionto thosespecifiedbetween(# ... #) , calledthemain-partof P1.

A P1-objectwill haveattributescorrespondingto thedeclarationsDecl1,..., Decln andDecl’1, ..., Decl’m . The enter-part of a P1-objectis a

6.6 QUALIFICATIONS AND SCOPERULES 99

concatenation; of In and In’ . Theexit-part of a P1-objectis a concatenationof Out andOut’ .

The actionpart of a P1-object is a combinationof Imp and Imp’ . Thiscombinationis controlledby meansof theinner : theexecutionof aP1-objectstartsby executionof the imperative Imp in P. Eachexecutionof an innerduringtheexecutionof Imp impliesanexecutionof Imp’ . If thereis no innerin Imp , thenImp’ will neverbeexecuted.4

In general, the notion of main-part is definedfor patterns,object de-scriptorsand objects: the main-part of a pattern is the part describedbe-tween(# ... #) asstatedabove. The main-part of an object descriptorP(# ... #) is thepartbetween(# ... #) . Themain-partof an objectXgeneratedaccordingto a descriptorP(# ... #) is theattributesandactions(includingenter/exit parts)describedby (# ... #) .

6.6 Qualifications and scoperules

Wenow extendthenotionsof qualificationandscoperulesintroducedin Sec-tions3.2.5and5.9 to handlesub-patterns.

6.6.1 Qualification

We first extendthedefinition of super-patternandsub-patternslightly. Con-siderthepatterndeclaration:

B: A(# ... #)

0 ThepatternA is saidto beadirectsuper-patternof B.0 A patternP is a super-patternof B if it is a directsuper-patternof B, or if it

is asuper-patternof thedirectsuper-patternof B.0 ThepatternB is adirectsub-patternof A.0 A patternP is a sub-patternof B if it is a directsub-patternof B, or if it is a

sub-patternof thedirectsub-patternof B.

Considerthepatterns:

Record: (# ... #);Person: Record (# ... #);Employee: Person(# ... #);

4TheMjølnerBETA Systemcompilerwill giveawarningin thiscase.

100 SUB-PATTERNS

Here Employee is a sub-patternof both Person and Record . It is a directsub-patternof Person . Similarly, Record andPerson aresuper-patternsofEmployee , while Person is adirectsuper-patternof Employee .

Referenceattributesarequalifiedusingpatternnames.Considera refer-enceattribute,R, declaredasfollows:

R: @Record

or

R: ˆRecord

TheattributeR is saidto bequalifiedby Record .The qualificationof a referencerestrictsthe setof objectswhich maybe

referredto by thereference.A referenceattributemaydenoteinstancesof its qualificationor instances

of sub-patternsof its qualification.Consider:

R: ˆRecord;P: ˆPerson;E: Êmployee

The referenceR is qualified by Record , and it may refer to instancesofRecord , Person andEmployee . ThereferenceP is qualifiedby Person , andit may refer to instancesof Person andEmployee . Finally, E is qualifiedbyEmployee ; it mayonly referto instancesof Employee .

A referencequalifiedby Record may refer to objectsof all the patternsRecord, Person, Employee, Student andBook , while a referencequali-fiedby Person mayonly referto Person, Employee andStudent objects.

6.6.2 Scoperules

Thescopeof anattributedeclaredin apatternP includesall sub-patternsof P,i.e. anamedeclaredin P is visible in sub-patternsof P.

A: (# a:...; b:...; c: ...; #);B: A(# d:...; e:...; f: ...

{a,b,c,d,e,f are visible here}#)

Sub-patternscombinedwith a block structuremustalsobe considered.Therule is thatnamesinheritedfrom thesuper-patternsmayhidenamesdeclaredin theenclosingobjectdescriptors:

6.7 EXERCISES 101

(#1 a: ...; d:...; x:...; {1}A: (# a:...; b:...; c: ...; #); {2}B: A(# d:...; e:...; f: ... {3}

{x_1,a_2,b_2,c_2,d_3,e_3,f_3 are visible here}#)

#)

Givena referencedeclaredas:

X: ˆB

all attributesdeclaredin B andin super-patternsof B canbeaccessedremotely,i.e. thefollowing remoteidentifiersarelegal:

X.a X.b X.c X.d X.e X.f

Givena referencequalifiedby Record :

R: ˆRecord

thenonly theattributesof Record , i.e. key , areaccessibleby remoteaccess:

R.key

This is still trueeven if R denotesa Person object,i.e. referencesto Personattributesname andsex of theform:

R.name;R.sex;

areillegal.

6.7 Exercises

(1) RedoExercise3 in Chapter3 usingsub-patterns.

(2) Modify the bankingsystemconstructedin Exercise2 in Chapter 5 tohandlesavings accountsandcheckaccounts.For a savings account,theattributesshouldincludethe interestrateandcalculationof interest.Forcheckingaccounts,thecustomershouldbechargeda fee for eachcheckthey write unlessthe balanceexceedsa certainthreshold,in which casewriting checksis free.

Next, modify thebankingsystemsuchthatanownermaybea person,acompany or anorganization(e.g.asoccerclub).

102 SUB-PATTERNS

(3) Generalizethe sodamachinedevelopedin Exercise5 in Chapter5 bydefininga super-patterncalledVendingMachine . Make a sub-patternofVendingMachine calledCandyMachine , whichis likeaSodaMachine ex-ceptthatinsteadof juiceandcolait provideschewing gum,chocolatebars,etc. Attributescommonto SodaMachine andCandyMachine shouldbedefinedin VendingMachine .

(4) DefineapatternForTo thatexecutesan inner ForTo for eachelementinan interval [first,last] . An integer variableindex holdsthe currentindex value.Thefollowing imperative:

(3,8)->ForTo(#do index->&Factorial #)

shouldcompute3!,4!,...,8! .

Makesimilar DownTo andStepTo patternsthatmaybeusedlike:

(6,2)->DownTo(#do index->&Factorial #){computes 6!,5!,...,2!}

(1,3,8)-StepTo(#do index->&Factorial #){computes 1!,4!,7!}

6.8 Notes

Patternsandsub-patternsgeneralizetheclassandsub-classmechanismfromSimula. Most object-orientedlanguageshave a constructsimilar to the sub-classmechanism;the term inheritanceis often usedfor this. The idea ofspecializingaction-partsby meansof inner alsooriginatesin Simula,whereit is usedfor prefixingof classes.(Vaucher, 1975) proposesto extendthis ideafor prefixingof procedures.In (Thomsen,1987) specializationof processesisfurtherdiscussed.

Oneof thedifferencesbetweenBETA andSmalltalkis thenotionof ‘typ-ing’ objectreferences.In Smalltalkanobjectreferencehasno typeandmayrefer to any object. In BETA an objectreferenceis qualifiedby meansof apatternname.Thequalificationspecifiesthat thereferencemayonly refer toobjectsthathavebeengeneratedaccordingto thatpatternor its sub-patterns.

Testingfor classpatternmembershipas describedin Section6.1 is, bysomepeople,consideredabadprogrammingstyle. In SimulaandSmalltalkitis possibleto performthesetests.In C++ they havebeendeliberatelyleft out,sincethey areviewedasviolating theadvantagesof object-orientation.

Multiple inheritancehascomeupasageneralizationof singleinheritance.With single inheritancea classmay have at most one super-class,whereasmultiple inheritanceallows a classto have severalsuper-classes.Inheritance

6.8 NOTES 103

is used< for many purposes,includingcodesharingandhierarchicalclassifica-tion of concepts.In the BETA language,inheritanceis mainly intendedforhierarchicalclassification.BETA doesnot have multiple inheritance,duetothelack of a profoundtheoreticalunderstanding,andalsobecausethecurrentproposalsseemtechnicallyverycomplicated.

In existing languageswith multiple inheritance,the code-sharingpart ofthe class/sub-classconstructdominates.Flavors hasa namethat directly re-flectswhat is going on: mixing someclasses,so the resultingclasshasthedesiredflavor, i.e. the desiredattributes. For the experienceof eatingan icecreamconeit is significantwhetherthevanilla ice creamis at thebottomandthechocolateon top, or theotherway around.Correspondingly, a classthatinheritsfrom theclasses(A, B) is not thesameasaclassthatinheritsfrom theclasses(B, A).

If, however, multiple inheritanceis to be regardedasa generalizationofsingleinheritance,andtherebyasa modelof multiple conceptclassification(and it shouldbe in the modelpresentedhere),then the orderof the super-classesshouldbeinsignificant.Whenclassifyingaconceptasaspecializationof severalconcepts,thenno orderof thegeneralconceptis implied, andthatshouldbesupportedby thelanguage.

Singleinheritanceis well suitedfor modelinga strict hierarchicalclassifi-cationof concepts,i.e. ahierarchywheretheextensionsof thespecializationsof a givenconceptaredisjoint. Suchhierarchiesappearin many applications,andit is often useful to know that the extensionsof, say, classpredatorandclassrodentaredisjoint.

In classifyingobjectsby meansof differentand independentproperties,several orthogonalstrict hierarchiesmay be constructed.A groupof peoplemaybeclassifiedaccordingto their profession,leadingto onehierarchy, andaccordingto their nationality, leadingto anotherhierarchy. Multiple inheri-tanceis oftenusedfor modelingthecombinationof suchhierarchies.It may,however, be difficult to recognizeif sucha non-stricthierarchyis actuallyacombinationof severalstrict hierarchies.

104 SUB-PATTERNS

Chapter 7

Virtual ProcedurePatterns

Thepattern/sub-patternmechanismmakesit possibleto groupcommonprop-ertiesof patternsinto generalsuper-patterns. This is sufficient as long asthe generalattributesandactionscanbe completelydescribedin the super-pattern. By this we meanthat attributesin a super-patterncanbe describedindependentlyof thesub-patterns.In thetravel agency example,theattributesDate and Customer do not dependon the subpatternsTrainReservationandFlightReservation . This is, however, notalwaysthecase.

Considera patternA with sub-patternsB andC. ThecommonattributesofB andC arelocatedin A, andthespecialattributesfor B andC arelocatedinB andC, respectively. SupposethatbothB andC have anattribute f , andthatthesemanticsof f is similar for B andC. If thedescriptionsof f in B andC areidenticalthenwe canmove thedescriptionof f to A. If, however, thedescrip-tionsof f in B andC arenot identical,thenwe cannotmove thedescriptionoff from B andC to A. Sincef is a propertyof all B andC objects,we would,however, like to describein A thatall sub-patternsof A have an f attribute. Inmany cases,thedescriptionsof f in B andC have a commonstructureandwewould like to move asmuchaspossibleof this commonstructureto A. Thismayappearfairly abstract.Considerthefollowing example.

In caseof the travel agency, it might be useful to display the attributesof a reservation on a computerscreenor print them out on paper. ForTrainReservation we might adda Display attribute that displaysthe val-uesof the attributesDate , Customer , ReservedTrain , ReservedCarriageand ReservedSeat . For FlightReservation we might similarly have aDisplay attributethatdisplaysthevaluesof theattributesDate, Customer,ReservedFlight and ReservedSeat . The propertyof having a Displayattribute is commonto both patterns. In addition, both Display attributesdisplaythe valuesof Date andCustomer . Ideally, suchcommonpropertiesshouldbedescribedin thegeneralReservation pattern.

In this chapterthenotionof virtual patternswill be introduced.By usingvirtual patternsit is possibleto describegeneralpropertiesof apatternattribute

105

106 VIRTUAL PROCEDUREPATTERNS

in a super-pattern,and to specializethis descriptionin sub-patterns.In thischapterwe introducevirtual patternsusedasprocedures.In Chapter9 theuseof virtual classpatternsis described.Note,however, thatin thesameway thatpatternscanbeusedeitherasclassesor procedures,alsovirtual patternscanbeusedeitherasvirtual classesor virtual procedures.

7.1 Moti vation

In this sectionwe analyzethe exampleof addinga Display attribute to thereservationpatterns.Firstweconsiderthesituationwhereeachof thepatternsTrainReservation andFlightReservation hasa Display attribute:

TrainReservation: Reservation(# ...

Display:(#do Date.Display; Customer.Display;

ReservedTrain.Display;ReservedCarriage.Display;ReservedSeat.Display

#)#);

FlightReservation: Reservation(# ...

Display:(#do Date.Display; Customer.Display;

ReservedFlight.Display; ReservedSeat.Display#)

#);

The dots (... ) indicate the attributesDate , Customer , etc. in the sameway asin thepreviouschapter. We assumethateachof theattributes,Date ,Customer , etc.hasa Display attribute.

As mentionedabove, the propertythat all Reservation objectshave aDisplay attribute is not reflectedin thedescriptionof Reservation . In ad-dition, the two Display attributesboth includethecodefor displayingDateandCustomer .

Before introducinga solution using virtual patterns,we first describeapartial solutionto the problem. Insteadof onedisplayattributewe have onefor eachpattern.This makesit possibleto describethegeneralpropertiesofthe display attribute in Reservation . In this versionof the Reservationpatternswehave implementedaclassificationhierarchyof displaypatterns:

7.1 MOTIVATION 107

Reserv= ation

FlightRes> ervation TrainRes> ervation

DisplayRe? servation

DisplayTrain@ Reservation DisplayFlightAReservation

Figure7.1 Parallelclassificationhierarchies.

Reservation:(# ...

DisplayReservation:(#do Date.Display; Customer.Display; INNER#)

#);TrainReservation: Reservation

(# ...DisplayTrainReservation: DisplayReservation

(#do ReservedTrain.Display;

ReservedCarriage.Display;ReservedSeat.Display;INNER

#)#);


DisplayFlightReservation: DisplayReservation(#do ReservedFlight.Display; ReservedSeat.Display;

INNER#)

#)

Theabovepatternsdescribetwoparallelclassificationhierarchies,oneconsist-ing of the reservation patternsandoneconsistingof their displayattributes,illustratedin Figure7.1. The hierarchyof displaypatternsis an exampleofusingthesub-patternmechanismfor specializationof actions,asdescribedinSection6.2.

Considerthereferences:


F: ˆFlightReservation;T: ˆTrainReservation

Wecaninvoke thecorrespondingdisplaypatternsin thefollowing way:

F.DisplayFlightReservation T.DisplayTrainReservation

As describedin Section6.2,aninvocationof F.DisplayFlightReservationcausesexecutionof thefollowing actions:

(1) Thesuper-patternF.DisplayReservation is invoked.This impliesexe-cutionof

(a) Date.Display

(b) Customer.Display

(c) INNERExecutionof INNER implies:

(2) The main part of F.DisplayFlightReservation is invoked. This im-pliesexecutionof:

(a) ReservedFlight.Display

(b) ReservedSeat.Display

(c) INNER, whichhereis theemptyaction.

At this point, all reservation objectshave a display property. We have de-scribedthegeneralstructureof this propertyusingtheDisplayReservationattribute in the Reservation pattern,andwe have describedthe specializedattributesDisplayTrainReservation andDisplayFlightReservation assub-patternsof DisplayReservation . Thereare,however, someproblemswith this solution:

(1) We have to invent a new namefor the display attribute for eachsub-pattern.

(2) Considera referencequalifiedby Reservation :

R: ˆReservation

Usingthis referencewemayinvoke thegeneraldisplayattribute:

R.DisplayReservation

7.2 DECLARATION OFVIRTUAL PATTERN 109

ThisB will resultin thedisplayof thegeneralreservationattributes.SinceReservation is anabstractsuper-pattern,R shouldreferto aninstanceofTrainReservation or FlightReservation . If R refersto aninstanceofFlightReservation , the invocationR.DisplayReservation will onlydisplaythe generalattributesDate andCustomer . The specialflight re-servationattributesReservedFlight andReservedSeat will not bedis-played.

Instead,the display attributesof Reservation and its sub-patternsshouldhave thefollowing properties:

(1) Each of the patternsReservation , TrainReservation and Flight-Reservation should have a patternattribute called Display . WhenDisplay is invoked,theactionsdescribedby DisplayReservation andDisplayTrainReservation or DisplayFlightReservation , respec-tively, shouldbeexecuted.

(2) An invocation

R.Display

should invoke the Display attribute of the object denotedby R. IfR denotesan instanceof TrainReservation , it should invoke theDisplayTrainReservation attributedescribedin theTrainReservationpattern. Similarly, if R denotesan instanceof FlightReservation , itshould invoke the DisplayFlightReservation attribute. (In the the-oretical casethat R denotesan instanceof Reservation , it shouldofcoursejust invoke the DisplayReservation attribute describedin theReservation pattern.)

7.2 Declaration of virtual pattern

The above propertiesmay be obtainedby declaringthe Display attributeof Reservation as a virtual pattern,and by extending the descriptionofDisplay in the sub-patternsTrainReservation andFlightReservation .Theresultingreservationpatternsmaybedescribedasfollows:

Reservation:(# ...

DisplayReservation:(#do Date.Display; Customer.Display; INNER#);

Display:< DisplayReservation



(# ...DisplayTrainReservation: DisplayReservation



#);Display::< DisplayTrainReservation

#);FlightReservation: Reservation

(# ...DisplayFlightReservation: DisplayReservation

(#do ReservedFlight.Display; ReservedSeat.Display;

INNER#);

Display::< DisplayFlightReservation#)

Theconstruct(calledavirtual patterndeclaration):

Display:< DisplayReservation

is a declarationof a virtual patternattribute called Display . The patternDisplayReservation is thequalificationof thevirtual patternattribute.For anon-virtualpatternattribute,thecompletestructureof thepatternis described.For a virtual patternattribute, its structureis only partially described. It ispossibleto extendthestructureof avirtual patternin sub-patterns.

A virtual pattern may be extended to any sub-patternof its qual-ification, meaning that Display may be extended to sub-patternsofDisplayReservation . Sucha virtual pattern extensionmay be describedin a sub-patternof Reservation . Thedeclaration:

Display::< DisplayTrainReservation

statesthattheDisplay patternis extendedto beaDisplayTrainReservati-on. Thequalificationof Display in TrainReservation is DisplayTrain-Reservation . A virtual patternextensionis alsocalledavirtual patternbind-ing, or just binding.

In theFlightReservation pattern,theDisplay is extendedto Display-FlightReservation by:

Display::< DisplayFlightReservation

7.2 DECLARATION OFVIRTUAL PATTERN 111

virtualhierarchy.v1

ªª

Date

Reservation

Customer

DisplayReservation

Date

TrainReservation

Customer

DisplayTrainReservation

ReservedTrain

ReservedCarriage

ReservedSeat

Display

Display

Date

FlightReservation

Customer

DisplayFlightReservation

ReservedFlight

ReservedSeat

Display

DisplayReservation

DisplayTrainReservation DisplayFlightReservation

Figure7.2 Reservationpatternswith virtual Display attribute.

Figure7.2 illustratesthedifferentbindingsof theDisplay attribute.ConsideragainthereferencesT, F andR qualifiedby TrainReservation ,

FlightReservation andReservation , respectively. Invocationof:

T.Display


will invokeDisplayTrainReservation of T. An invocationof:

F.Display

will invokeDisplayFlightReservation of T.It is moreinterestingto consideraninvocationof:

R.Display

Assumethat R refersto an instanceof TrainReservation . From the qual-ification of R we know that R hasa Display attribute. SinceR refersto aninstanceof TrainReservation , the Display attributehasbeenextendedtobetheDisplayTrainReservation pattern,meaningthatR.Display will in-voke DisplayTrainReservation .

If insteadR refersto aninstanceof FlightReservation , R.Display willinvokeDisplayFlightReservation .

Virtual patternattributesprovidegreatflexibility whendescribingsystems.At theplacein theprogramwhereaninvocationlike R.Display takesplace,oneneednotknow theexacttypeof theobjectbeingreferredto, asthatobjectselectstheappropriatepatternattribute.

Considerthereservationregisterfrom theendof Section6.1.Supposethatwe want to displayall thereservationsmadeby Mr Olsen.This canbedonein thefollowing way:

(for i: Reservations.NoOfElm repeati->Reservations.GetElm->R[];(if R.Customer[] // Olsen[] then R.Display if)

for)

7.3 DIRECT QUALIFICATION OF VIRTUAL PATTERNS 113

7.3 Dir ectqualification of virtual patterns

In the above exampleit may seeminconvenientto have to introducenameslike DisplayTrainReservation . For this reason,it is possibleto usedirectqualificationof avirtual pattern,whichhasthefollowing syntax:

Reservation:(# ...

Display:<(#do Date.Display; Customer.Display; INNER#)


(# ...Display::<



#)#);


Display::<(#do ReservedFlight.Display; ReservedSeat.Display;

INNER#)

#)

Thevirtual declaration:

Display:<(#do Date.Display; Customer.Display; INNER#)

statesthatDisplay is qualifiedby ananonymouspatternassociatedwith thegivendescriptor. Theextensionof Display in FlightReservation :

Display::<(#do ReservedFlight.Display; ReservedSeat.Display;


INNER#)

statesthat Display is extended to a new anonymous pattern which isa sub-patternof the anonymous pattern in Reservation . Theseanony-mous patterns have the same structure as the DisplayReservation ,DisplayTrainReservation andDisplayFlightReservation patterns.

7.4 Continued extensionof a virtual pattern

The extensionof a virtual patternattributecanbe continuedat arbitrarylev-elsof sub-patterns.Possiblesub-patternsof, say, FlightReservation mightextendthedisplay attributefurther. In thefollowing example,we show howthedescriptionof a virtual patternmaybeextendedthroughseveral levelsofsub-patterns.Theexampleusedis theclassificationhierarchyfor records:

Record:(# Key: @integer;

Display:< (#do {Display Key}; INNER #)#);

Person: Record(# Name: @text; Sex: @SexType;

Display::< (#do {Display Name,Sex} ; INNER #)#);

Employee: Person(# Salary: @integer; Position: @PositionType;

Display::< (#do {Display Salary,Position}; INNER #)#);

Student: Person(# Status: @StatusType;

Display::< (#do {Display Status}; INNER #);#);

Book: Record(# Author: @Person; Title: @TitleType;

Display::< (#do {Display Author,Title}; INNER #)#)

Considerreferences:

R: @Record;P: @Person;E: @Employee

Note that thesereferencesdenotepart objects. This meansthat instanceRconstantlydenotesthesameinstanceof Record :

7.5 MOREEXAMPLES OFUSING VIRTUAL PATTERNS 115

0 R.DisplayC invokestheDisplay attributedescribedin Record resultinginexecutionof Display Key.

0 P.Display invokes the combinationof the Display in Record and theDisplay in Person . This meansthatDisplay Key; Display Name andSex areexecuted.

0 E.Display invokesthe combinationof Display asdescribedin Record ,Person and Employee . This meansthat Display Key; Display Nameand Sex; Display Salary and Position areexecuted.

7.5 Mor eexamplesof using virtual patterns

In this sectionweprovideadditionalexamplesof virtual patterns.

7.5.1 Specializationof initialization patterns

Virtual patternsareuseful for describingthe initialization of objects. In thefollowing example,thevirtual patternattribute Init maybeusedto initializeinstancesof the patterns.Eachsub-patternlevel extendsthe specificationofInit .

Considerapatterndefiningpoint objects:

Point:(# X,Y: @integer;

Init:< (# do 0->X; 0->Y; inner #);#)

Thespecificationof Init indicatesthatit is avirtual pattern.A sub-patternof Point may bind Init to a descriptorthat is a sub-

descriptorof the Init in Point :

ThreeDPoint: Point(# Z: @integer;

Init::< (# do 0->Z; inner #);#)

WhenexecutingtheInit of ThreeDPoint , theactionsof its super-patternareperformed,assigning0 to both X andY. Executionof the inner in Init ofPoint impliesexecutionof theactionsin a possiblesub-pattern;in this case,the assignmentof 0 to Z. In the caseof a ThreeDPoint -object, the innerfollowing 0->Z is an empty action, but in the casewhereThreeDPoint isusedfurtherto define,for example,FourDPoint , thenthe inner wouldcauseexecutionof thespecializedinitialization of FourDPoint .


7.5.2 Computation of salary for differ ent job types

Considera company which hasemployeesworking in four kinds of differ-ent jobs. In two of the job typesthe employeeshave permanentpositions,whereasthey work on an hour-by-hourbasisin the other two job functions.Figure7.3 shows a setof patternsrepresentingthe different job types. ThemostgeneralpatternJob includesa setof attributesfor computingsalary, taxanddeductiblesfor theemployeeperformingthatjob. Thecomputationof taxis thesamefor all jobs,i.e. 45%of thesalaryminusdeductibles.

Thecomputationof salaryanddeductiblesare,however, differentfor thefour job types.Thepatternsfor computingsalaryanddeductiblesarethereforevirtual patterns.Eachemployeehasa standarddeductionof 10000which ishandledin thedefinitionof Deductible in patternJob . NotethatValue is justanauxiliarypattern.In NonPermanentJob anew virtual pattern,hourlyWage ,for computingthehourlywageof theemployee,is defined.

Assumethat the company has100 employees. Staff is a repetitionofreferencesdenotingvariousjob objectscorrespondingto the employees,i.e.Staff[1] maydenoteaninstanceof Job1 , Staff[2] maydenoteaninstanceof Job4 , etc.ThepatternComputeSalarySum computesthesumof all salariesfor all employees.

7.5.3 Geometricfigures

Figure7.4 shows a classificationhierarchyof geometricfigures.Supposewewant to develop a computersystemfor handlinggeometricfigures. For allkindsof symbolsit shouldbepossibleto draw thesymbolon a screen,com-putethe areaof the symbol,rotatethe symbol,move the symbol,etc. Mostof thesefunctionscannotbedescribedin a generalsuper-class,but have to bedeclaredasvirtual patterns.We leave it asanexercisefor thereaderto fill inthedetails.

7.5.4 Defining control abstractions

We have previously seenhow sub-patternscanbe usedto definecontrol ab-stractionsusinginner . An exampleof thisis theForAll patternin Figure6.6.Thistechniquemaybeusedto defineabstractionsthatcontrolexecutionof oneactionsequenceasexecutedby inner, but otherexamplesof abstractionsneedto control the executionof morethanoneactionsequence.An exampleis acontrolabstractionFind for theRegister pattern.Find searchesfor a givenrecordin theregister:if therecordis found,oneactionsequenceshouldbeex-ecuted;if therecordis not found,anotheractionsequenceshouldbeexecuted.TheFind patternmaybedefinedusingavirtual pattern:

Find:

7.5 MOREEXAMPLES OFUSING VIRTUAL PATTERNS 117

Job:(# name: @text;

Value: (# V: @integer do INNER exit V #);Tax: Value(#do (Salary-Deductible )*4 5 div 100 ->V #);Salary:< Value;Deductible:< Value(#do 10000->V; INNER#)

#);PermanentJob: Job(# #);NonPermanentJob: Job

(# noOfHours: @integer;Salary::< (# do noOfHours*hourlyWage ->V #);Deductible::<(#do 3000+V->V; INNER #);hourlyWage:< Value

#);Job1: PermanentJob

(# Salary::< (#do 35000->V #);Deductible::< (#do 2000+V->V #)

#)Job2: PermanentJob

(# Salary::< (#do 45000->V #);Deductible::< (#do 2500+V->V #)

#);Job3: NonPermanentJob

(# hourlyWage::< (#do 80->V #); (* 80 pr. hour *)#);

Job4: NonPermanentJob(# hourlyWage::< (#do 85->V #); (* 85 pr. hour *)#);

Staff: [100] ˆJob;ComputeSalarySum:

(# Sum: @integerdo 0->Sum;

(for i: Staff.range repeat Staff[i].salary+s um->su m for)exit Sum#)

Figure7.3 Jobhierarchy.

(# Subject: ˆRecord;NotFound:< Object;index: @integer


GeometricFigure

Circle Polygon

Triangle Parallelogram

Rectangle Rhombus

Figure 7.4 Classificationhierarchyfor geometricfigures.

enter Subject[] {The Record to be searched}do 1->index;

Search:(if (index<=Top) // True then

(if table[index][] // Subject[] thenINNER;leave Search

if);index+1->index;restart Search

else NotFoundif)

#)

ThisFind patternmaybeaddedasanattributeto theRegister pattern.Findwill searchfor anelementidenticalto Subject . If suchanelementis foundaninnerwill beexecuted,otherwisethevirtual patternNotFound will beinvoked.

Find maybeusedto implementthepatternHas:

Has: Find(# Result: @boolean;

NotFound::< (#do False->Result #)do True->Resultexit Result#)

7.6 BENEFITSOF VIRTUAL PATTERNS 119

(# Expression:(# value:< (# V: @integer do INNER exit V #);#);

Const: Expression(# C: @integer;

value::<(#do C->V #)enter Cexit this(Const)[]#);

BinOp: Expression(# E1,E2: Êxpressionenter(E1[],E2[])exit this(BinOp)[]#);

Plus: BinOp(# Value::<(#do E1.value+E2.value-> V #) #);Mult: BinOp(# Value::<(#do E1.value*E2.value-> V #) #);

E: Êxpressiondo {Assign (111+222)*2->E}

((111->Const,222->C onst) ->P lus ,2- >Cons t)- >Mult ->E [];E.value->putInt

#)

Figure 7.5 Patternsfor representingarithmeticexpressions.

7.5.5 Arithmetic expressions

Figure7.5showspatternsfor representingarithmeticexpressions.An expres-sion is composedof integer valuesand binary operationssuchas plus andmult. Thevirtual patternvalue computesthevalueof anexpression.

7.6 Benefitsof virtual patterns

Sub-patternsandvirtual patternsarepowerful abstractionmechanisms.Con-sidertheaboveexamplefor computationof salariesand,in particular, thepat-ternComputeSalarySum . Thispatternis independentof theactualjob objects.Theevaluation:

Staff[i].Salary

invokestheSalary patterncorrespondingto theactualjob objectdenotedbyStaff[i] .


Supposethatwe hadto computethesalarywithout usingvirtual patterns.Wewould thenneedsomemechanismto testthejob typeof a job object.Onewayof doingthis is to adda job typeattributeto patternJob :

Job:(# name: @text;

jobType: @integer;...

#)

When creating instancesof Job1 , Job2 , Job3 and Job4 we could thengive jobType the value1, 2, 3 and 4, respectively. A (functional) pattern,ComputeSalary , for computingthesalarycould thenbewritten asshown inFigure7.6. In addition,a revisedversionof ComputeSalarySum is included.As canbe seen,it is necessaryto checkthe job type of eachobject in orderto computethecorrespondingsalary. By usingvirtual patterns,thecomputa-tion of salaryis definedtogetherwith eachjob pattern.A (functional)pattern,ComputeDeductible , couldbewritten in a similarway.

Insteadof introducingtheattributejobType wecouldhaveusedthemech-anismfor testingpatternmembershipas describedin Section6.1. The if-imperativeof ComputeSalary would thenhave thefollowing form:

(if R##// Job1## then ...// Job2## then ...// Job3## then ...// Job4## then ...

if)

The techniqueof usingattributeslike jobType hasbeenshown, sincethis isoftenusedin proceduralprogramminglanguageslikePascalandC.

Perhapsthe most importantadvantageof using virtual patternsappearswhena new job typeis added.Usingvirtual patterns,we couldaddanew jobtypeby defininga new sub-patternof, say, PermanentStaff :

Job5: PermanentStaff(# Salary::< (#do 50000->V #);

Deductible::<(#do 1500->V #)#)

TheComputeSalarySum patternneednot bechanged,sinceit is independentof theactualjob patterns.

Withoutvirtual patternswewouldhaveto makechangesto all patternslikeComputeSalary andComputeDeductible . In general,we recommendusingvirtual patternsin suchsituations.

7.7 SUMMARY 121

ComputeSalary:(# R: ˆJob; sum: @integerenter R[]do (if R.jobType

// 1 then (* Job1 *) sum + 35000->sum// 2 then (* Job2 *) sum + 45000->sum// 3 then (* job3 *)

(# S: ˆJob3do R[]->S[]; S.noOfHours*80 + sum->sum#)

// 4 then (* job4 *)(# S: ˆJob4do R[]->S[]; S.noOfHours*85 + sum->sum#)

if)exit sum#);

ComputeSalarySum:(# Sum: @integerdo 0->Sum;

(for i: Staff.range repeat(Staff[i][]->Compute Sal ar y)+ sum->s um

for)exit Sum#);

Figure7.6 Functionalpatternfor computingsalary.

7.7 Summary

In this sectiona summaryandfurther detailsof virtual patternsis given. ApatternattributeV of patternP is declaredasvirtual usingoneof theforms:

V1: P: (# V:< Q #)

V2: P: (# V:< Q0(# ... #) #)

V3: P: (# V:< (# ... #) #)

whereQandQ0 arepatternnames.CaseV3 is identicalto caseV2 exceptthatthe object-descriptorfor V is implicitly assumedto have Object asa super-pattern.

ThepatternQ (caseV1), theobject-descriptorQ0(#...#) (caseV2), andtheobject-descriptor(#...#) (caseV3) is calledthequalificationof V.


In an objectdescriptorthat hasP asa super-pattern,the virtual patternVmaybeextendedto objectdescriptorsthataresub-patternsof thequalification.In caseV1 this impliesthatV maybeextendedto sub-patternsof Q; in caseV2V maybe extendedto sub-patternsof Q0(#...#) ; andin caseV3, V maybeextendedto sub-patternsof (#...#) .

So even thoughV may be defineddifferently in differentsub-patternsofP, it is still known in P to be at leasta Q, Q0(#...#) or (#...#) . The ex-tensionsof a virtual patternin differentsub-patternsarethusenforcedto bespecializationsof thedefinitionin thesuper-pattern.

In P-objectsandin instancesof sub-patternsof P with no extensionsof V,the qualificationis the definition of V, so the qualificationis alsoa default-binding.

Thedescriptionof avirtual patternV maybeextendedin sub-patternsof Pby meansof a further binding, whichhasoneof theforms:

E1: P1: P(# V::< Q1 #)

E2: P1: P(# V::< Q1(# ... #) #)

E3: P1: P(# V::< (# ... #) #)

The casesE1, E2 andE3 correspondto the casesV1, V2 andV3 in the fol-lowing way:

(1) CasesE1 andE2 candefinea furtherbindingof a virtual patterndefinedasin caseV1, providedthat Q1 is a sub-patternof Q. Q1 doesnot have tobea directsub-patternof Q.

(2) CaseE3 canfurther bind a virtual patterndefinedasin casesV1, V2 orV3. The descriptor(#...#) is automaticallymadea sub-patternof thequalificationof V in P.

Q1, Q1(#...#) and (#...#) correspondingto the casesE1, E2 andE3, re-spectively, arecalledtheextendeddescriptor.

In instancesof P1, the patternV is boundto the extendeddescriptor. LetX be an instanceof P1. Instancesof X.V will be instancesof the extendeddescriptor. This is also the caseif the generationof X.V is specifiedin thesuper-patternP of P1.

A furtherbindingasshown above specifiesthatV is alsoa virtual patternin P1. Thequalificationof V in P1 is its extendeddescriptor. This meansthatV maybefurtherextendedin sub-patternsof P1:

P2: P1 (# V ::< ... #)

It is possibleto extendV by aso-calledfinal binding, whichhasoneof theforms:

7.8 EXERCISES 123

F1: P1: P(# V:: Q1 #)

F2: P1: P(# V:: Q1(# ... #) #)

F3: P1: P(# V::(# ... #) #)

A final binding hasthe sameeffect asa further binding, exceptthat V is notvirtual in P1. This impliesthatV maynot befurtherextendedin sub-patternsof P1.

7.8 Exercises

(1) RedoExercise3 in Chapter3 usingvirtual patterns.Includepatternsfordescribingthegeometricfiguresin Section7.5.3.

(2) RedoExercise3 in Chapter6 usingvirtual patterns.

(3) RedoExercise2 in Chapter6 usingvirtual patterns.

(4) Discussthedifferencebetweenspecializationusingsub-patternsandspe-cializationusingvirtual patterns.

7.9 Notes

Theconceptof virtual procedureswasoriginally introducedin Simula.Class,subclassandvirtual procedureareoftenviewedasthemostessentiallanguageconstructsassociatedwith object-orientedprogramming.In Simula,C++ andEiffel, aprocedureattributemayeitherbenon-virtualor virtual,correspondingto patternattributesin BETA beingeithernon-virtualor virtual. In Smalltalk,all procedureattributes(called methods)are virtual. In Chapter9, furtherhistoricalnoteson thevirtual conceptaregiven.

Object-orientedprogrammingdoesnot necessarilyimply lateandunsafebinding of names,which is sometimesclaimedto be a weaknessof object-orientedlanguages.As mentionedabove, patternattributesof BETA objectsandproceduresin C++ objectsmaybespecifiedasnon-virtual,which meansthatlatebindingis notusedwheninvoking them.

Whena Smalltalkor Flavorsobjectreactsto a messagepassedto it with‘messagenotunderstood’,it hasnothingto dowith Smalltalkor Flavorsbeingobject-oriented,but with thefactthatthey areuntypedlanguages.

The combinationof qualified (typed) referencesand virtuals in BETAimplies that it may be checked at compile-time that expressionslikeaRef.aMethod will bevalid at run-time,providedof coursethataRef denotesan object. A late binding determineswhich aMethod (of which sub-pattern)will be executed.Which aMethod to executedependsuponwhich object iscurrentlydenotedby aRef .


Considera referenceSomeReservation qualifiedby Reservation . ThismeansthatSomeReservation maydenoteobjectsgeneratedaccordingto thepatternReservation or sub-patternsof Reservation . As Display is de-claredasavirtual in Reservation , it is assuredthat:

SomeReservation.Display

is always valid, and that it will lead to the execution of the appropriateDisplay . However, theuseof untypedreferencesin Smalltalk-like languageshasthe benefitthat recompilationof a classdoesnot have to take the restoftheprograminto consideration.

Whatmakeslatebindingslow is notonly themethodlook-up. If amethodin Smalltalkhasparameters,thenthecorrespondencebetweenactualandfor-mal parametersmustbechecked at the time of execution. Display will, forinstance,have a parametertelling how many copiesto display. This will bethesamefor all specializationsof Display , andshouldthereforebespecifiedaspartof thedeclarationof Display in Reservation .

In BETA this is obtainedby qualifyingvirtuals. ThefactthatDisplay willhaveaparameteris describedby a patternDisplayParameter :

DisplayParameter:(# NoOfCopies: @integerenter NoOfCopiesdo

...#)

Qualifying thevirtual Display with DisplayParameter impliesthatall spe-cializationsof Display in different sub-patternsof Reservation must besub-patternsof DisplayParameter , and thushave the propertiesdescribedin DisplayParameter . This implies that Display in all sub-patternsofReservation will haveanintegerNoOfCopies input-parameter.

If object-orientedprogrammingis to be widely usedin real applicationsprogramming,thentheprovisionof typedlanguagesis amust.As PeterWeg-nersaysin ‘Dimensionsof Object-BasedLanguageDesign’(Wegner, 1987):

‘..., the acceptedwisdom is that strongly typed object-orientedlanguagesshouldbe the norm for applicationprogrammingandespeciallyfor programmingin thelarge.’

As demonstratedabove,it doesnothaveto excludeflexibility in specializationof methodsor latebinding.

Since inheritance has been introduced by object-orientedlanguages,object-orientedprogrammingis oftendefinedto beprogrammingin languages

7.9 NOTES 125

thatsupportD inheritance.Inheritancemay, however, alsobesupportedby func-tional languages,wherefunctions,typesand valuesmay be organizedin aclassificationhierarchy.

In object-orientedlanguagesinspiredby Smalltalk,classesarespecialob-jectsandinheritanceis definedby amessage-forwardingmechanism.Objectsof sub-classessend(forward)inheritedmessagesthatarenotdefnedby theob-ject to thesuper-class‘object’ in orderto havethemperformed.Thisapproachstressescodesharing: thereshall be only onecopy of the super-class,com-monto all sub-classes.With this definitionof inheritanceit is not strangethat‘distribution is inconsistentwith inheritance’ (Wegner, 1987)andthat ‘Thisexplainswhy thereareno languageswith distributedprocessesthat supportinheritance.’

In themodelof object-orientedprogrammingpresentedhere,themainrea-sonfor sub-classing(specialization)is theclassificationof concepts.Thewayin whichanobjectinheritsamethodfrom asuper-classis – or rathershouldbe– animplementationissue,andit shouldnotbepartof thelanguagedefinition.

Accordingto thedefinitionof patternsandobjectsin BETA givenabove,patternsarenotobjects,andin principleeveryobjectof patternPwill have itsown descriptor. It is left to theimplementationto optimizeby having differentobjectsof P sharethe descriptor. Following this definition of patternsandobjects,thereis no problemin having two objectsof thesamesub-patternactconcurrently, andeven be distributed. The implementationwill in this casesimply make asmany copiesof the patternasneeded,including a possiblesuper-pattern.This doesnot excludethata modificationof the super-patternwill haveaneffecton all sub-patterns.


Chapter 8

Block Structur e

Compositionis a fundamentalmeansfor organizingobjectsandpatternsintermsof componentsof otherobjectsandconcepts.Therearea numberofdifferentformsof composition,oneof thesebeinglocalization. In BETA, lo-calizationis supportedby meansof block structure, whichwasfirst mentionedin Section5.9. In this chaptertheusefulnessof block structurewill befurtherexplored.Compositionis discussedin generalin Section18.5.2.

A programminglanguagesupportsblock structureif procedures,classesand blocks can be textually nested. BETA supportsblock structuresinceobject-descriptorsmaybearbitrarily nested.This chaptercontainsa numberof examplesof usingblockstructurein theform of nestedpatterns.

8.1 Simpleblock structur e

Mostobjectdescriptorscontainasimpleform of blockstructure.Oneexampleis thepatternRegister , whichhastheform

Register:(# ...

Init: (# ... #);Has: (# ... #);Insert: (# ... #);Remove: (# ... #);

#)

Theobjectdescriptorsfor Init, Has, Insert andRemovearenestedwithintheobjectdescriptorfor Register .

A procedurepatternmayhavelocalprocedurepatterns,asin thefollowingexample:

HandleReservations:{Handle one or more reservations for a customer}

127

128 BLOCK STRUCTURE

(# GetReservation:{Get reservation request from customer}(# ... #);

MakeReservation:{Perform temporary reservation}(# ... #);

ReleaseReservation:{Release a temporary reservation}(# ... #)

CompleteReservation:{Book desired reservations}(# ... #)

do {Investigate one or more possible reservations }{from customer using GetReservation and }{MakeReservation. Release reservations not used }{and finalize desired reservations using }{ReleaseReservation and CompleteReservation. }

#)

HeretheprocedurepatternHandleReservations hasbeendecomposedintoa numberof simpler procedurepatterns. This decompositionof procedurepatternsinto smallerprocedurepatternsis a usefulstructuringmechanismforlarge procedures.Block structureis useful to provide locality for thesepat-terns.

All theseexamplesshow thenestingof procedurepatterns.We next giveexamplesof nestedclasspatterns.

8.2 Classgrammar

The first exampleof nestedclasspatternsis a patternrepresentingthe con-ceptof a context free grammar. Instancesof the Grammar patternrepresentthe context free grammarof programminglanguagessuchasPascalandSi-mula. A grammarhastheassociatedconceptSymbol , i.e. a grammardefinesthesymbolsof thelanguagebeingdefinedby thegrammar. Dif ferentconcretegrammarshave differentsymbols. Pascalsymbolsdiffer from Simulasym-bols. We would like to reflectthis propertyin the definition of the Grammarpattern;this canbedoneusingnestedclasspatterns,asshown in Figure8.1.

An instancerepresentingaPascalgrammarcanbedeclaredasfollows:

Pascal: @Grammar

For this instanceit is possibleto accesstheattributesasusual:

Pascal.noOfRules someText[]->Pascal.Parse->anAST[]

8.2 CLASSGRAMMAR 129

Grammar:(# noOfRules: @integer;

... {Other attributes for representing a grammar}Parse:<

(# input: ˆtext; output: ÂbstractSyntaxTreeenter input[]do {Parse the input string according to the grammar}

{and produce an abstract syntax tree}exit output[]#);

Symbol:(# id: @integer; printName: @text; ...

isTerminal: (# ... exit aBoolean #);#);

#)

Figure 8.1 Grammarpattern.

The patternSymbol may be usedto declarePascalsymbolsin the followingway:

A,B: @Pascal.Symbol

UsingA andB, it is possibleto accessattributesdescribedin theSymbol pat-tern:

A.printName B.isTerminal -> aBool

Consideranothersetof instances:

Simula: @Grammar; X,Y: @Simula.Symbol

Pascal and Simula are both instancesof the samepatternGrammar. TheobjectsA,B andX,Y are,however, not instancesof thesamepattern;A,B areinstancesof the patternPascal.Symbol , whereasX,Y are instancesof thepatternSimula.Symbol . Intuitively, thisis whatwewant,sinceA,B arePascalsymbolsandX,Y areSimulasymbols.Thetwo classesof symbolsareclearlydifferent.

ThedifferencebetweenPascal.Symbol andSimula.Symbol is thesameasthedifferencebetweenPascal.Parse andSimula.Parse . Thelatter twoexpressionsinvokedifferentParse instances,sincethey havedifferentorigins.Figure8.2showsadiagramrepresentingtheobjectsPascal andSimula .

130 BLOCK STRUCTURE

Pascal

Move

noOfRules

Grammar Grammar

112

Symbol

struc (# ... #)

origin

Parse

struc (# ... #)

origin

struc (# ... #)

origin

struc (# ... #)

origin

Simula

Move

noOfRules 125

Symbol

Parse

Figure8.2 Diagrammaticrepresentationof Grammar objects.

Pascal

Move

noOfRules

Grammar Grammar

112

Symbol

Parse

Simula

Move

noOfRules 125

Symbol

Parse

origin

isTerminal

printName

id 18

if

origin

isTerminal

printName

id 25

do

origin

isTerminal

printName

id 59

class

origin

isTerminal

printName

id 23

if

Symbol Symbol Symbol Symbol

Figure 8.3 Diagrammaticrepresentationof Grammar andSymbol objects.

Figure8.3showstheobjectsPascal , Simula , A,B,X andY. NotethatA,BandX,Y have differentorigins. Thestructurereferencesfor Parse, Symbol

8.3 FLIGHT RESERVATION EXAMPLE 131

andisTerminalE havebeenomitted.By declaringSymbol local to theGrammar pattern,wehave thepossibility

of distinguishingbetweensymbolsof differentgrammars.Also,sincetheclassSymbol is local to Grammar, a symbolhasno existencewithout a grammar.Fromamodelingpoint of view, this is whatwewant.

In the exampleabove the staticreferencesA,B,X andY denotestaticob-jects.It is, of course,alsopossibleto declaredynamicreferenceslike:

C: ˆPascal.Symbol; Z: ˆSimula.Symbol

The referenceC may denoteany instanceof Pascal.Symbol andZ any in-stanceof Simula.Symbol . Supposethatwe want to declarea referencethatcandenotearbitrarysymbols.Thiscanbedoneby declaringa dynamicrefer-encequalifiedby Grammar.Symbol :

S: ˆGrammar.Symbol

Note the differencefrom the declarationof A usingPascal.Symbol , wherePascal is a referenceto a Grammar object. In thedeclarationof S, Grammaris a patternname. S can refer to instancesof either Pascal.Symbol orSimula.Symbol . In fact, the patternGrammar.Symbol may be viewed asa generalizationof the patternsPascal.Symbol and Simula.Symbol . TheGrammar.Symbol patternis thena representationof thegeneralconceptof asymbolof acontext freegrammar.

8.3 Flight reservation example

In thissectionwemakeuseof nestedclasspatternsto furtherextendthetravelagency example.TheFlightReservation patterncontainsanattributedec-laration:

ReservedFlight: ˆFlight

We now considerhow to describethepatternFlight , but beforedoingsoweneedto understandtheconceptof aflight.

Considertheflight tableof Scandinavian Airline Systems(SAS).This ta-ble containsa descriptionof variousentriesSK273,SK451,SK511,etc.,cor-respondingto thevariousroutesservedby SAS.An entrylikeSK273containsinformationaboutthe sourceanddestinationof the route,andotherproper-tiessuchasdeparture,arrival andflying timesaregiven. It seemsobvioustorepresenttheseentriesasinstancesof a patternrepresentingtheconceptof aflight entry.

For our flight reservation systemmore objectsare needed. The flightSK451betweenCopenhagenandLos Angelesactuallytakesplacemostdaysof theyear. A tablefor handlingreservationsmustcontainanentry for each

132 BLOCK STRUCTURE

FlightType:(# source, destination: ˆCity;

departureTime,arrivalTime: @TimeOfDay;flyingTime: @TimePeriod;

Flight:(# Seats: [NoOfSeats] @Seat

actualDepartureTime,actualArrivalTime: @TimeOfDay;actualFlyingTime: @TimePeriod;

DepartureDelay:(#exit(actualDepartur eTi me - departureTime)#)

#);

DisplayTimeTableE ntr y: (# ... #);...

#)

Figure 8.4 TheFlightType pattern.

day theflight takesplace. Eachsuchentryshouldincludeinformationaboutseatreservationsfor thatday, etc.For aflight entrylikeSK451,wecanincludeaconceptthatclassifiesall flightscorrespondingto SK451.

Patternsrepresentingflight entriesand actual flights are shown in Fig-ure8.4.

The FlightType patternis supposedto be usedfor modelingentriesina flight timetable. For eachentry in the timetablethereis an instanceof theFlightType pattern;suchinstancesrepresentflight entrieslike SK451 andSK273. A FlightType objectincludesinformationaboutsource,destination,departuretime,arrival time,flying time,etc.

8.3 FLIGHT RESERVATION EXAMPLE 133

TimeTable90: @(# ...

SK451: @FlightType;SK273: @FlightType;

...Init:<

(# ...do ...

’Copenhagen’ -> SK451.source;’Los Angeles’ -> SK451.destination;...

#)#);

ReservationTable90 : @(#

SK451Flights: [365] ˆTimeTable90.SK451. Fli ghtSK273Flights: [365] ˆTimeTable90.SK273. Fli ght

...#)

Figure8.5 PatternsTimeTable andReservationTable .

An attribute like departureTime is actuallymodelingthe scheduledde-parturetime, which may vary from day to day. A table for handlingreser-vationsmustcontainan entry for eachday the flight takesplace. Eachsuchentryshouldhave informationaboutthereservationof seatsfor thatday, andit might includeinformationaboutthe actualdeparturetime, etc. in ordertocomputevariouskindsof statistics.EachFlightType objecthasa local classpatternFlight , which modelstheactualflights takingplace.Instancesof theFlight patternhave attributescharacterizinga givenflight, including a rep-etition of Seat objects,theactualdeparturetime, theactualarrival time, andtheactualflight time.

Objectsrepresentingthe timetableandthe reservation tablefor 1990areshown in Figure8.5. NotethatSK451Flights is a repetitionof referencestoinstancesof theclassFlight patternof theobjectdenotedby SK451, whereasSK273Flights denotesinstancesof the Flight patternattribute of SK273.Theactualflight SK451 takingplaceat dayno. 111of year1990is thusmod-eledby theobjectdenoted:

ReservationTable90.SK451Flights[111 ]

Seatno. 48 for theflight of thatdaymaythenbereservedby executing:

134 BLOCK STRUCTURE

ReservationTable90.SK451Flights[111] .Seat s[48] .Reser ve

assumingthat Seat objectshave a Reserve attribute. When the flight hastaken place,the actualtimesfor departure,arrival andthe flight time canbeenteredinto theflight object.Thedifferencebetweentheestimatedflight timeandtheactualflight timecanbecomputedby executing:

ReservationTable90.SK451Flights[111] .Depa rture Delay

whichreturnsthedifferencebetweenactualDepartureTime anddepartureTime .Note that DepartureDelay refers to the global referencedepartureTimein the enclosingFlightType object. This would not have beenpossibleif Flight were not definedlocally to FlightType . In the exampleabove,Flight is a classpatternattributeof FlightType . In addition,FlightTypeinstanceshave the referenceattribute destinationand the procedurepatternattribute DisplayTimeTableEntry . For the different instancesSK451 andSK273 of the FlightType pattern,the attributesSK451.destination andSK273.destination are different attributes. Also, SK451.DisplayTime-TableEntry and SK273.DisplayTimeTableEntry are different procedurepatterns,sincethey areattributesof differentinstances.In thesameway, theclasspatternsSK451.Flight andSK273.Flight aredifferent,sincethey areattributesof differentFlightType objects.

8.4 Exercises

(1) Write apatternDocument with thefollowing properties:

(a) A documentis asequenceof charactersnumberedfrom 1.

(b) It is possibleto defineoneor moreselectionsin adocument.A selec-tion identifiesaninterval of thecharactersin thedocumentincludingapositionbetweentwo characters.A selectionshouldberepresentedby a Selection object.

(c) A documenthas a current selection which is a referenceto aSelection object.

(d) Text canbeinsertedby replacingthecharactersidentifiedby thecur-rentposition.

(e) Thetext identifiedby thecurrentselectioncanbedeleted.

(f) Thereis adistinguisheddocumentcalledClipboard .

(g) A Selection objecthasthefollowing operations:0 Copy whichcopiestheselectedtext to theClipboard .0 Cut which deletes the selected text and stores it on the

Clipboard .

8.5 NOTES 135

0 Paste which replacesthe selectedtext with the text on theClipboard .

(h) A Selection objectis createdby giving aninterval to adocument.

(i) The current selectionmay be replacedby a referenceto anotherSelection object.

DefinethepatternSelection asa local patternof Document .

(2) Write a HyperText patternwith thefollowing properties:

(a) A hypertext consistsof asetof links.

(b) A link consistsof a sourceanda destination,eachbeinga referenceto ananchorof adocument.

(c) A hypertext hasan operationdefinelink which takesa source-anddestinationanchorasparameters.

(d) It hasanoperationfor scanningall links.

Use the Document patternof the previous exerciseand the Selectionpatternfor representingtheanchorconcept.

8.5 Notes

Block structurewasfirst introducedin the Algol-60 programminglanguage.An Algol block correspondsto an object descriptorin BETA. The purposeof this chapterhasbeento show thatblock structureasfound in SimulaandBETA, but abandonedin Smalltalk-80,is a naturalandpowerful mechanism.Whenmodelingphenomena,it is useful to be ableto characterizean objectby meansof a class. In addition,block structureis useful for a numberoftechnicalproblemsin programming.

Block structureis not theonly way in which SimulaandSmalltalkdiffer.SimulacontainsAlgol-60 asasubsetandsupportsblockstructure,static(lex-ical) namebinding,andcompile-timetypechecking,but Smalltalkhasnoneof thesefeatures. Smalltalk is more in the style of Lisp, with a flat set ofdefinitions(classes),dynamicnamebindingandrun-timetypechecking.

TheSchemelanguageis anexampleof a Lisp dialectwith block structureandlexical namebinding.

In Simulatheuseof nestedclassesis limited by a numberof restrictions.BETA doesnothave theserestrictions.

Block structureis a controversialsubjectthathasgivenrise to muchdis-cussionin theliterature.In whatfollowswecommenton this discussion.0 Locality. The major advantageof block structureis locality. This makes

it possibleto restrict the existenceof an objectand its descriptionto theenvironment(object)whereit hasmeaning.

136 BLOCK STRUCTURE

0 Scoperules. Thereare(at least)the following aspectsof scoperules fornamesdeclaredwithin anobject:

– They only exist whentheobjectexists.Thisis aconsequenceof locality.– Accessto globalnamesandredeclarationof names.

Global names may or may not be seen within a block. In(Wulf andShaw, 1973) it is argued that the use of global variableswithin nestedblocks is a sourceof errors. It is considereda problemthata namecanberedeclaredwithin an internalblock. Thereis, how-ever, noreasonto allow suchredeclarationin a languageif it is foundtobeaproblem.Also, it hasbeenarguedthat it may be difficult to seewhich globalnamesarebeingusedwithin an internalblock. Again, this is not in-herentlytied to block structureandcanbe avoided. In languageslikeEuclid((Lampsonet al., 1977)),ablockmustexplicitly import from theenclosingblockall namesbeingused.

– Accessto nameswithin a block from ‘outside’ the block may be re-stricted. The hidden/protectedmechanismof Simulais an exampleofthis.

0 Syntax. In (Hanson,1981) it is saidthat:

‘Block structurecanmake evenmoderatelylarge programsdif-ficult to read.Thedifficulty is dueto thephysicalseparationofprocedure-headingsfrom their bodies....’

In (Tennent,1982)it is demonstratedthatthis is merelya matterof syntax.By usingthe syntaxfrom Landin’s ISWIM it is possibleto placeinternalproceduredeclarationsafterthebodyof theblock.

In thedesignof BETA, theabove-mentionedproblemswereconsideredminor.The reasonis that in BETA block structureis not a mechanismintendedfor‘programmingin thelarge’. Block structureshouldbeusedfor ‘programmingin thesmall’. In languagessuchasAlgol-60 andPascal,whereblockstructureis theonly structuringmechanism,theaboveproblemsmaybemoreserious.

Thegrammarexampleis inspiredby (Liskov andZilles, 1974),whomakeuseof abstractdatatypesin the CLU language.SinceCLU doesnot haveblockstructure,theSymbol classis declaredoutsidetheGrammar class,whichgives problemswith restricting the implementationdetailsof the Grammarclass. For a discussionof these problems see (Liskov andZilles, 1974;Madsen,1987)

The flight reservation exampleis often describedasan instanceof whatis calledthePrototypeAbstractionRelationProblemasformulatedby BrianSmith(Smith,1984). Theproblemis thata flight entrancelikeSK471(a pro-totype)maybeviewedasaninstanceof theclassof flight entriesandalsoas

8.5 NOTES 137

aclassF whoseinstancesaretheactualSK471flights. To modelthis it is neces-saryto beableto describeSK471bothasanobjectandasa class.This is notpossiblein languageslike Smalltalk. Themetaclassmechanismof Smalltalkcando someof this, but is not generalenough.TheBETA solutiondescribesSK471asanobjectwith aclassattribute.

138 BLOCK STRUCTURE

Chapter 9

Virtual ClassPatterns

Virtual patternsareusedto describethecommonstructureof patternattributesin a super-pattern.In Chapter7 thenotionof virtual patternswasintroducedby meansof virtual procedurepatterns.In this chapter, thevirtual conceptisfurtherexploredby giving examplesof virtual patternsusedasclasses.

In BETA thereis no technicaldifferencebetweenprocedurepatternsandclasspatterns,it is simply a matterof how instancesaregenerated.For pro-cedurepatterns,instancesare generatedin the action-partand immediatelyexecuted.The instancethenbecomesinaccessiblesinceno referenceto it issaved. For classpatterns,‘named’ instancesaregeneratedin thesensethatareferenceto theinstanceis saved.

9.1 Dir ectly qualified virtual classpatterns

As alreadymentioned,the specificationof a virtual classpatternis identicalto the specificationof a virtual procedurepattern– the differenceis in howinstancesaregenerated.ConsiderFigure9.1: the classGraph hasclassat-tributesNode andLink which definetheelementsof a graph.Node andLinkarespecifiedasvirtual classes.Subclassesof Graph may extendthe defini-tions of Node andLink correspondingto specificdifferentkinds of graphs.Instancesof Node will thereforealwayshave theattributeConnected , andin-stancesof Link will have theattributesSource andDest . As canbeseen,thevirtual procedureConnect makesuseof theseattributes.

NotethattheNode classesin two differentinstancesof Graph aredifferentclasses,as they are attributesof differentobjects. A Node object from oneGraph objectcannotbecomepartof anotherGraph .

In theDisplayableGraph subclass,thedefinitionsof Node andLink havebeenextended.This is reflectedin theextendeddefinitionof Connect whichhasanadditionalparameterDL. Theexecutionof Connect impliesthegenera-tion of a Link object(&Link ). This Link objectis aninstanceof theextendedLink class,andthereferenceL denotesthis instance.ThusL.DispLine is a

139

140 VIRTUAL CLASSPATTERNS

Graph:(# Node:< (# Connected: @boolean #);

Link:< (# Source, Dest: ˆNode #);Root: ˆNode;Connect:<

(# S,D: ˆNode; L: ˆLinkenter(S[],D[])do &Link[]->L[];

S[]->L.source[]; D[]->L.Dest[];true->S.Connected ->D .Co nnect ed;INNER

#);#);

DisplayableGraph: Graph(# Node::< (# DispSymb: ˆDisplaySymbol #);

Link::< (# DispLine: ˆDisplayLine #);Connect::<

(# DL: ˆDisplayLineenter DL[]do DL[]->L.DispLine[]; INNER#);

Display:< (# .... #)#);

TravellingSalesman Graph: Graph(# Node::< (# Name: ˆText #);

Link::< (# Distance: @integer #);Connect::<

(# D: @integerenter Ddo D->L.Distance; INNER#);

#);DG: ˆDisplayableGraph;TG: ˆTravellingSalesmanG ra ph

Figure9.1 Exampleof virtual classpatterns.

valid expression.The referenceDG.Root is known to denotean instanceoftheextendedNode class,thusanexpressionlikeDG.Root.DispSymb is valid.

The definition of TravellingSalesman is similar, but with differentex-tensionsof Node, Link andConnect .

9.2 GENERAL PARAMETERIZED CLASSPATTERNS 141

9.2 Generalparameterizedclasspatterns

In thepreviouschapterstherehavebeenexamplesof patternsdescribingregis-tersfor insertingvariouselements.TheRegister in Chapter3 maybeusedtostoreinteger objects;theReservationRegister patternin Chapter6 maybeusedto storeReservation objects.Thesepatternshaveasimilarstructure:the main differenceis the type of elementsthat canbe insertedin a register.From a modelingpoint of view, it is desirableto be able to describea gen-eralgenericRegister patternwhich canbeusedto insertarbitraryelements.Specialregistersrestrictedto reservationsor recordscouldthenbedefinedassub-patternsof thisgeneralRegister pattern.

TheRegister patternin Figure9.2is anexampleof suchageneralpattern.Theonly maindifferencefrom thepreviousregisterpatternsis thevirtual classattributeContent . Content is thetypeof theelementsof theRegister , andis qualifiedby themostgeneralObject pattern.This meansthata Registerobject may include instancesof all patterns. Note that the qualificationofContent is describedusinga patternname– mostexamplessofar have usedtheform of directqualificationof virtual patterns.

In sub-patternsof Register it is possibleto restrictthetypeof elementstobestoredin theregister. Figure9.3showsanexampleof a registerfor storingRecord objects.The RecordRegister patternis definedasa sub-patternofRegister , wherethequalificationof thevirtual classpatternis extendedto theRecord pattern.Thismeansthattheelementsof theregistermustbeinstancesof Record or sub-patternsof Record .

A Display attribute hasbeenaddedto RecordRegister . The virtualpatternDisplay scansthroughall the elementsof the setand invokestheirDisplay pattern.This is possibleasall elementsin theregisterareknown tobe instancesof Record or its sub-patterns.Suchobjectsall have a Displayattribute.

It is possible to make further sub-patternsof RecordRegister . AStudent registercanbe declared,as in Figure9.4, whereall objectsin thisregisterareStudent objects.Herewehave madea final bindingof Content ,which meansthat it is not possibleto make further restrictionsof thequalifi-cationof Content in sub-patternsof StudentRegister .


Register:(# Content:< Object;

Table: [100] ˆContent; Top: @integer;Init:< (# ... #);Has: Find

(# Result: @boolean;NotFound::(#do false->Result #)

do true->Resultexit Result#)

Insert:(# New: ˆContententer New[]do (if (New[]->Has) // false then ... if)#);

Remove: (# ... #);ForAll:

(# Current: ˆContentdo (for inx: Top repeat

Table[inx][]->Curren t[ ];INNER

for)#);Find:

(# Subject: ˆContent; index: @integer;NotFound:< Object

enter Subject[]do 1->index;

Search:(if (index<=Top) // true then

(if Subject[] // Table[index][] thenINNER;leave Search

if);index+1->index;restart Search

else &NotFoundif)#);

#)

Figure9.2 TheRegister patternparameterizedwith virtual patterns.

9.3 Notes

Even thoughthe mostcommonuseof redefinitionsof virtuals (methods)isto reflectspecialization,mostobject-orientedlanguageswith virtuals do not

9.3 NOTES 143

RecordRegister: Register(# Content::< Record;

Init::< (# ... #);Display:<

(#do ForAll(#do Current.Display #); INNER#)

#)

Figure9.3 Sub-patternof Register .

StudentRegister: RecordRegister(# Content:: Student;

UpdateStatus: Find(# Status: @StatusType;

NotFound:: (# ... #)enter Statusdo Status->Table[index ].S ta tus#)

#)

Figure9.4 Exampleof aspecializationof theRegister pattern.

requiredefinitionsof virtuals in sub-classesto be specializationsof the vir-tual definitionsin thesuper-class.A sub-classmethodin SmalltalkandFla-vorsneednothavemorethantheidentifierin commonwith thecorrespondingmethodin thesuper-class.A recentimprovementof Simulahasmadeit possi-ble to specifytheparametersthatall proceduredefinitionsin sub-classesmusthave, but apartfrom that,a definitionof a virtual in a sub-classconsistsof apureredefinitionof thevirtual definitionin thesuper-class.

In theuseof theselanguagesit has,however, beenrecognizedthata pureredefinitionof thevirtual is not alwayswhat is wanted.When(re)definingavirtual in asub-class,thedefinition(oreffect)of thevirtual in thesuper-classissometimesneeded.In Smalltalkthis is obtainedby simplysendingamessageto thesuper-class(from within themethodof thesub-class),sothatthemethodof thesuper-classis performed,i.e. theoppositeof inner . Flavorsprovidesa moresophisticatedscheme(e.g. beforeandafter methods).In Simulathevirtual definition in thesuper-classis simply not accessibleaspartof or afterabindingof thevirtual.


In thecasewherepatternattributesareusedto generateandexecuteitemobjects, they correspondto local proceduresin Simula and to methodsinSmalltalkandFlavors.As BETA hasageneralsub-patternconcept,alsocover-ing itemobjectsactingaslocaloperations,wehavein Smalltalkterms‘classesandsub-classesof methods.’ It is not a new idea to usethe class/sub-classmechanismfor methods. In 1975Vaucherproposedprefixed proceduresasa structuringmechanismfor operations (Vaucher, 1975). In BETA this is aconsequenceof a moregeneralnotionof pattern/sub-pattern.As Vaucherhasdemonstrated,aclass/sub-classmechanismfor methodsis usefulin itself.

The essenceof specializationby sub-patternsis that objectsof a sub-patternof a patternP shouldhave all the propertiesof P-objects. Thereis,however, no way to guaranteethis, sincea sub-patternmayintroduceproper-tiesthat‘contradict’ theintentionsof thesuper-pattern.

Languagessupportingclasses/sub-classesdo not prevent programmersfrom makingsuchsub-classes,although,by default,objectsof sub-classesbe-have likeobjectsof thesuper-class.Oneexampleof this is thatanobjectof asub-classinheritstheattributes(in termsof variablesandprocedures/methods)of the super-class. The term inheritanceis very often usedinsteadof sub-classing.This reflectsthe fact that inheritanceof ‘code’ is often consideredto be the major benefitof sub-classing.In BETA, sub-classingis primarilyconsideredamechanismfor modelingconceptualhierarchies,althoughit maybeusedfor codesharingaswell. This is oneof themajordifferencesbetweenthe Americanandthe Scandinavian schoolsof object-orientedprogramming(Cook,1988).

Chapter 10

Part Objects and ReferenceAttrib utes

Classificationandcompositionarefundamentalmeansfor apprehendingthereal world. Classificationis the meansby which we form and distinguishbetweendifferent classesof phenomenaand concepts. Compositionis themeansby which we understandphenomenaandconceptsasa compositionofotherphenomenaandconcepts.

In thepreviouschapterswe haveseena numberof examplesof usingpat-terns,sub-patternsandvirtual patternsfor supportingclassification.In Chap-ter 8 we have seenhow nestedpatterns(block structure)maybeusedto sup-port localization,which is oneform of composition.In this chapterwe shalltakeacloserlook at part-objectswhichsupportsanotherform of compositioncalledwhole-partcomposition. This form of compositionis usefulfor struc-turingphenomenainto wholesandparts.Themodelingaspectsof whole-partcompositionarementionedin Chapter2, andarefurther discussedin Chap-ter 18 (Section18.5.2).In this chapterwe shallgivea numberof examplesofusingpart-objectsin BETA to modelwhole-partcomposition.

We alsogive examplesof how to use(dynamic)referenceattributesforsupportingreferencecomposition, which is a third form of composition.Ref-erencecompositionis alsodiscusedin Section18.5.2.

10.1 Part objects

The constructfor declaringa part objectwas introducedin Chapter3. Thestick figure from Figure 2.3 may be describedin BETA, as shown in Fig-ure 10.1. In additionto the partsof Figure2.3, operationsfor graphicalani-mationof a stickmanhavebeenadded.It is possibleto move,draw andcleara stick manon a screen,andit is possibleto wave thehandsandwriggle thetoes.An instanceof astickmanmaybedeclaredin thefollowing way:

145

146 PART OBJECTSAND REFERENCEATTRIBUTES

StickMan:(# theHead: @Head;

theBody: @Body;LeftArm,RightArm: @Arm;LeftLeg,RightLeg: @Leg;move: (# ... #);draw: (# ... #);clear: (# ... #);...

#);Head: (# ... #);Body: (# ... #);Arm: (# theHand: @Hand; ... #);Leg: (# theFoot: @Foot; ... #);Hand: (# wave: (# #); ... #);Foot: (# bigToe: @Toe; ... #);Toe: (# wriggle: (# #); ... #)

Figure 10.1 PartialBETA descriptionof a stickman

Joe: @StickMan

ThestickmanJoe maybemanipulatedin thefollowing way:

Joe.move;Joe.wave;Joe.LeftLeg.theFoot.bigToe.wriggle

The move operationmay be implementedby invoking a correspondingmoveoperationon theparts:

move:(# pos: @pointenter posdo pos->theHead.move; pos->theBody.move;

pos->LeftArm.move; pos->RightArm.move;pos->LeftLeg.move; pos->RightArm.move;

#)

Clear anddraw maybeimplementedsimilarly.Operationsof a compoundobjectareoftencomposedfrom operationsof

its partobjects.An exampleof this is themove operation,which is definedasa compositionof move operationson theparts.Themove operationillustratesthatwhole-partcompositionis alsorelevantfor action-sequences.

10.1 PART OBJECTS 147

A StickMan is alsocharacterizedashaving anoperationfor wriggling theleft big toe.In contrastto themove operation,nooperationfor thisis definedasanattributeof StickMan . Instead,thewriggle operationof thebigToe partisuseddirectly usingthenotationJoe.LeftLeg.theFoot.bigToe.wriggle .

A compoundobjectmay thusbe characterizedby having operationsthatinvokeoperationsof its partsandby operationsdefinedin its parts.

In somesituationsit may be more convenient to ‘propagate’an opera-tion of a part to thewholeobject. Thewriggle operationmay, for example,bepropagatedto theStickMan objectby definingthefollowing operationofStickMan :

LeftBigToeWriggle: (#do LeftLeg.theFoot.BigToe.wriggle #)

Notethatif all thetentoescanwriggle, thentensuchoperationsmayhave tobedefined.

10.1.1 Independentand dependentparts

The above exampleshows that a compoundobjectmay directly usean op-erationof its partsor it may defineoperationswhich control its parts. Thepartsareindependentof thewholeobjectin thesensethat they areinstancesof patternsdefinedwithout knowledgeaboutbeingpartof someotherobject.In somesituationsit maybedesirablethat thedefinitionof a parthasknowl-edgeaboutthe compoundobject. This is possibleby placingthe definitionsof thepatternsinsidethewholeobject.By doingthis it is possibleto refer toattributesof thewholeobjectfrom theparts.

In thissectionweshallshow how it is possibleto usevirtual patternsto de-fine partobjectsthatreferto thewholeobject.Considerthefollowing patterndefininganaddress:

Address:(# Street: @text;

StreetNo: @integerTown,Country: @text;printLabel:<

(#do INNER;

{print Street, StreetNo, Town, Country};#)

#)

In this definitionof anAddress , it is not decidedwhetheror not it is thead-dressof aperson,company, organization,etc.For thisreason,theprintLabeloperationhasbeenmadevirtual. In theexamplesbelow it is shown how theAddress patternmaybeusedto defineaddressesof personsandcompanies:


Person:(# name: @text;

adr: @Address(# printLabel::<(#do {print name} #);#);

Company:(# name,director: @text;

adr: @Address(# printLabel::<(#do {print name and director} #);

#);

The addresspart of Person objectsis definedasa singularinstanceof thepatternAddress . Thevirtual procedurepatternprintLabel refersto thenamefield of theenclosingPerson object.Theaddresspartof aCompany is handledin a similar way, but herethe printLabel refersto the name anddirectorfieldsof theenclosingCompany object.

Referencesto part objects

It ispossibletoobtainreferencesto partobjects,asalreadymentionedin Chap-ter3.

P: ˆPerson; C: ˆCustomer; A1,A2: Âddress

Giventhereferencesdefinedabove, it is possibleto assigna referenceto theaddresspartof P andC to A1 andA2 asfollows:

P.adr[]->A1[]; C.adr[]->A2[]

This maybeusefulin situationswherethereis a needto handleobjectswithsimilar parts.In theaboveexample,it maybeusefulto handleobjectsthatallhaveaddressparts.Considerthefollowing declarations:

Areg: @Register(# content::< Address #);

The Areg is supposedto containa list of Address objects. In this list it ispossibleto insertany objectthathasanAddress part:

P.adr[]->Areg.insert; C.adr[]->Areg.insert

It is now possibleto scanthis registerandprint all thelabels:

Areg.scan(#do thisElm.printLabel #)

As maybeseen,theAreg objectandthecodethatusesit areindependentoftheactualobjectshaving theAddress part. Theonly commonthing for theseobjectsis thateachhasanAddress part.


Part objectsG versussub-patterns

The readermay have noticedthat the possibility of treatingPerson objectsandCompany objectsasAddress objectsmaytechnicallybeobtainedby usingsub-patterns.We might have describedPerson andCompany assub-patternsof Address :

Person: Address(# name: @text;

printLabel::< (#do {print name} #);#);

Company: Address(# name,director: @text

printLabel::<(#do {print name and directory} #);#)

Eventhoughthis will technicallywork in thesameway, thereis a majordif-ferencewith respectto modeling. Whenusingpart objectswe considertheaddresspropertyto beanaspectof a personandcompany. Whenusingsub-patterns,we considerpersonsandcompaniesto beclassifiedas‘addressable’objects.Noneof theseviewscanbesaidto betheright one:it dependson theactualsituationwheretheobjectsareto beused.

Multiple part objects

It is of coursepossibleto have severalpartobjectsas,for example,shown inthestickmanexample.Thismeansthatthetechniqueusedfor having Addressobjectsaspartobjectscanbegeneralizedto having severalpartobjects,eachrepresentingdifferentaspectsof thewholeobject.

10.2 Referenceattrib utes

In theprevioussectionsa numberof examplesof usingstaticreferences/partobjectsfor modelingwhole-parthierarchieshave beengiven. In this sectionthe useof dynamicreferenceattributesfor modelingreferencecompositionwill be given. Referencecompositionis usedto describecompoundobjectswith partswhich are not ‘physically’ containedin the whole object, an ex-amplebeing the bank accountdefinedin Chapter3. A bank accounthasa Customer attribute, and it is of coursenot a good model to considertheCustomer object to be a part of the Account . Instead,a referenceto theCustomer is consideredapartof theAccount :

Account:(# Customer: ˆPerson;


...#)

In general,referencecompositionmaybeusedto representarbitraryrelations.The Customer attribute of an Account may be seenasrepresentinga ‘cus-tomer’ relationbetweenanaccountanda person.In this exampletherelationis oneway, in thesensethat the referenceis from theaccountto theperson,andnot vice versa. It is, of course,possibleto representtwo way relations.Considerpatternsrepresentingbooksandauthors:

book:(# theAuthor: Âuthor;

...#);

Author:(# theBook: ˆBook;

...#);

Therearenumerousexamplesof relationshipsof this kind. The relationshipbetweenavehicleandits owneris anotherexample,andit maybemodeledinBETA asfollows:

Vehicle: (# owner: ˆPerson; ... #)

As with the ‘customer’ relation, the ‘owner’ relation is simple in the sensethatan attributeof a Vehicle objectrefersto theowner of thevehicle. Theabove representationof the ‘owner’ relationcannotbe usedto identify a ve-hicle ownedby a person. As before,it is possibleto introducea referenceattributeof a Person objectto referto a Vehicle :

Person: (# owns: ˆVehicle; ... #)

Theabovedescriptionassumesthatavehicleis ownedby at mostoneperson,andthat a personownsat mostonevehicle. Sucha relationis calleda one-to-onerelation. A Person objectrepresentinga personthat doesnot own avehiclecouldberepresentedby lettingtheowns referencehavethevalueNONE.If we assumethata vehiclealwayshasanowner, thentheowner attributeofVehicle objectswill neverbeNONE.

In practice,agivenpersonmayown severalvehiclesandwemightwanttorepresentthis fact. In BETA this canbedoneusingrepetitionsof references,asin thefollowing example:

Person: (# owns: [...] ˆVehicle; ... #)


In practice,H it maybeinconvenientto userepetitionsto representsuchrelation-ships.Insteadwe might have a Set patternfor representingsetsof referencesto objects:1

Person: (# owns: @Set(# element::<Vehicle #); ... #)

This typeof relationis calledone-to-many.The relation ‘Author writer-of Book’ is an exampleof a many-to-many

relation. An authormay write several books,anda book may have severalauthors.

Representingrelationsaspatterns

Often it is useful to representrelationshipsas instancesof patterns. Thismay be the casefor relationsthat are not binary, or if additionalattributesare neededto characterizethe relation. In the following examplea patternQuartet definesa relationcoveringphenomenasuchas‘The Beatles.’ Phe-nomenalike ‘The Mills Brothers’ and ‘Simon and Garfunkel’ may be rep-resentedasobjectsthat are instancesof patternsmodelingrelationssuchas‘Trio’ and‘Duo’:

Quartet:(# p1,p2,p3,p4: ˆPerson;

init:< (# do INNER #)#);

...theBeatles: @Quartet

(# init::<(#do JohnLennon[]->p1[]; ... #)#)

This an exampleof referencecomposition. Often more attributesthan justreferencesmay be associatedwith a relation. For a quartetits salary, list ofengagements,etc. may be represented.Considerthe ‘owner/owns’ relationfor vehicles.A Registration patternmaybeusedto representtherelation:

Vehicle: (# R: ˆRegistration ; ... #);Registration:

(# V: ˆVehicle;P: ˆPerson;RegistrationDate: @Date;...

#);Person: (# owns: @Set(# element::Registration; ... #)

1TheMjølnerBETA Systemhassucha Set patterndefinedin its basiclibrary.


10.3 Exercises

(1) Completethestick manexample.Usea suitablegraphicspackagefromtheMjølner BETA Systemto implementthegraphicsfor drawing astickman.

(2) Describethe many-to-many relation ‘Author writer-of Book’ whereanauthormay have written several books,and a book may have severalauthors.Discusspossiblepropertiesof therelation.

(3) Describepatternsmodelingarbitrarybinaryrelations.

10.4 Notes

For many yearsthefield of object-orientationhasbeenfocusingprimarily onclassification/specialization,and hasto someextent neglectedcomposition.This may be dueto the fact that supportfor compositionhasbeenavailablein programminganddesignlanguagesfrom thevery beginning,whereassup-port for classificationwasnew with the introductionof sub-classing(inheri-tance). Therehasthusbeena tendency to forget aboutcompositionandtryto useinheritancefor supportingcompositionalso. Compositionis just asimportantasclassificationfor organizingandstructuringknowledge.A gen-eral discussionof part objectsmay be found in (FaberandKrukow, 1990).Sub-classingversusinheritanceis discussedin (Sakkinen,1989). Theimpor-tanceof compositionhasmainly beenrecognizedwithin the databasefield,andobject-orientedanalysisanddesign,(see,for example,(Kim et al., 1987;CoadandYourdon,1990; Booch,1991)).

Theuseof relationsfor datamodelinghasbeencentralin thedatabasearea(seealsothebibliographyin Chapter18).

The stick man exampleis from (BlakeandCook,1987) whereit is dis-cussedhow to supportwhole-partobjectsin Smalltalk-80,whichdoesnothavedirectsupportfor this. It is suggestedto useinstancevariablesfor supportingparts,but sinceinstancevariablesarenot visible from outsideanobject,it isnotpossibleto executeanoperationcorrespondingto:

Joe.LeftLeg.theFoot.bigToe.wriggle

They extendSmalltalkto allow methodswith nameslike:

LeftLeg.theFoot.bigToe.wriggle

TheStickMan objectmaythendefinethemeaningof thewriggle operation.If no methodwith theabove nameexists, thenan instancevariableLeftLegis assumedto exist, and the messagetheFoot.bigToe.wriggle is sendtoleftLeg , which may have a methodtheFoot.bigToe.wriggle or it maypropagatethemessagefurther.

10.4 NOTES 153

AsF proposedin, for example, (RajandLevy, 1989), code reusedoesnot have to be obtained solely by meansof sub-classing(inheritance),but may also be obtained by part objects. A discussionof part ob-jects in BETA, including inheritancefrom part objects, may be found in(MadsenandMøller-Pedersen,1992). This includesacomparisonof multipleinheritanceusingmultiple super-classesand multiple inheritanceusingpartobjects. If only inheritanceof codeis a concern,then multiple inheritancefrom part objectsis almost the sameas multiple inheritancefrom multiplesuper-classes.It is similar to multiple inheritancein C++ without virtual baseclasses.Most languageswith multiple inheritanceincludea renamingschemeto handleidenticalnamesinheritedfrom differentsuper-classes.With partob-jects, the inheritedattributeswill have to be accessedusinga remotename,i.e. no nameconflictswill exist. However, somepeoplefind the useof re-motenamesto beto clumsy. (MadsenandMøller-Pedersen,1992) proposearenamingschemefor partobjects.

Additional languageconstructsfor supportingpart objectsare also pro-posedby (MadsenandMøller-Pedersen,1992). Oneof theselanguagemech-anismsis the location of a part object. Considerthe Address example,andconsiderfirst the situationwherePerson and Company are sub-patternsofAddress :

Person: Address(# name: @text;

printLabel::< (#do {print name} #);#);

Company: Address(# name,director: @text

printLabel::<(#do {print name and directory} #);#);

P: ˆPerson; C: ˆCompany; A: Âddress

Herethefollowing typesof assignmentsarepossible:

P[]->A[]; C[]->A[]; A[]->P[]; A[]->C[]

Thefirst two typesof assignmentsarealwayslegal, sinceA is ‘lessqualified’thanP andC. Thelattertwo assignmentsareonly legal if A refersto a Personor Company, respectively. Thisis, in general,notknown atcompile-time,andarun-timecheckis neededto testthevalidity of theassignment.Foradiscussionof this,see(Madsenet al., 1990). Considernow thesituationwhereAddressis representedasapartobject:

Person:(# name: @text;

adr: @Address(# printLabel::<(#do {print name} #);


#);Company:

(# name,director: @text;adr: @Address

(# printLabel::<(#do {print name and director} #);#);

P: ˆPerson; C: ˆCompany; A: Âddress

Theassignments:

P.adr[]->A[]; C.adr[]->A[];

correspondto the assignmentsP[]->A[]; C[]->A[] in the case wherePerson andCompany aresub-patternsof Address . In bothcases,thePersonandCompany objectsareassignedto a referencequalifiedby Address . In thesub-patterncase,the whole objectis assigned;in the part objectcase,a partobjectis assigned.In bothcasesonly theAddress aspectsof thePerson andCompany objectsareconsidered.

In thesub-patterncaseit is possibleto assignA to P or C andconsiderthewholeobjectasa Person andCompany. This is notpossiblein thepartobjectcase.(MadsenandMøller-Pedersen,1992) have suggestedthatanobjecthasa predefinedattribute loc which refersto a possiblecontainingobject. If Arefersto an Address object which is part of a Person object, then A.locrefersto the whole Person object. If A insteadis part of a Company object,thenA.loc refersto thewholeCompany object. If A refersto anobjectwhichis not part of anotherobject, then A.loc is NONE. Using loc we may nowexecuteassignments:

A.loc->P[]; A.loc->C[]

Theseassignmentscorrespondsto theassignments:

A[]->P[]; A[]->C[]

in thesensethata lessqualifiedreferenceis assignedto a morequalifiedref-erence,andbothformsof assignmentsrequirea run-timecheck.

Chapter 11

Pattern Variables

In this chaptera moredynamicconceptof patternsthanordinaryandvirtualpatternswill beintroduced.In thefollowing example:

T: (# A: (# ... #) {1}V: < D;

do &A;&V

#)

the evaluation&A alwayscreatesan instanceof the patternA asdescribedat{1} . The nameA is constantin the sensethat it always denotesthe samepattern.Theevaluation&V createsan instanceof somesub-patternof D. Theactualinstancecreatedis determinedby thesub-patternsof T whereV maybeextended.ThenameV maybethoughtof asavariablethatmaydenotediffer-entsub-patternsof D. V maybegivendifferentvaluesin differentsub-patternsof T and a given value for a sub-patternwill apply for all instancesof thesub-pattern.In this chapterwewill introducethenotionof a patternvariable,whichmaybeassigneddifferentpatternsduringa programexecution.

11.1 Declaration of pattern variables

A patternvariableis definedasfollows:

F: ##T

whereF is thenameof thepatternvariableandT is its qualification.F maybeassignedany patternwhich is T or sub-patternsof T.

Considerthefollowing patterns:

T1: T(# ... #)T2: T(# ... #)

155

156 PATTERN VARIABLES

Then:

T1##->F##

assignsT1 asa patternto F. F maybeusedto createinstancesin evaluationsof theform:

F &F &F[]

just asfor ordinarypatterns.F maybeassignedanew pattern:

T2##->F##

or to anotherpatternvariable:

F##->F1##

whereF1 maybedeclaredasfollows:

F1: ##T


(# T: (# do ’Here is ’->puttext; INNER #);T1: T(#do ’T1’->putText #);T2: T(#do ’T2’->puttext #);F1,F2: ##T;

do T1##->F1##; &F1; {1}T2##->F1##; &F1; {2}F1##->F2##; &F2; {3}

#)

In line 1, thepatternT1 is assignedto thepatternvariableF1. Thesubsequentinvocation&F1 will then generateand executean instanceof T1. The textHere is T1 will be printed. In line 2 F1 is assigneda new patternT2. Theinvocation&F1 will thengenerateandexecutean instanceof T2, andthe textHere is T2 will beprinted.Finally, in line 3 F1 is assignedto F2. SinceF1is referringto thepatternT2, the T2 patternwill alsobeassignedto F2. Theinvocation&F2 will thusgenerateandexecuteaninstanceof T2.

F is analogousto a referenceR: ˆT with respectto qualification. ThereferenceR mayreferto instancesof T or sub-patternsof T. F mayreferto thepatternT or to sub-patternsof T.

11.1 DECLARATION OFPATTERN VARIABLES 157

StructurI e referenceof objects

For any objectit is possibleto obtaina referenceto its structure.For anobjectreferenceR, R## returnsthe structurethat wasusedto instantiatethe objectreferredto by R. Considerreferences:

R1: @T1;R2: ˆT;R3: @T2(# ... #)

Thevalueof R1## is thepatternT1, sinceR1 is an instanceof T1. Thevalueof R2## is thestructureof theobjectreferredto by R2. SinceR2 mayrefertoinstancesof T or sub-patternsof T, R2## maybeany suchpattern.Thevalueof R3## is thestructureT2(# ... #) .

Thefollowing procedurepatterncreatesanobjectwhich is an instanceofthesamepattern/object-descriptorasits enterparameter:

MakeCopy:(# S,R: Ôbject; F: ##Objectenter S[]do S##->F##; &F[]->R[]exit R[]#)

Thecopy of theS-objectwill not have thesamestateasS. All simpleobjects(integer , etc.) will have their default values(0, etc.),andall referenceswillbe NONE. Someobject-orientedlanguagesprovide a Clone operationwhichgeneratesacopy with thesamestate.Suchanoperationis currentlynotavail-ablefor BETA.

Relational operators

It is possibleto comparepatternvariableslike:

F## = T1## F## < T2## R## <= T1##

where, meansthesamepattern,J meansthattheleft-sideis asub-patternoftheright-side,and J , meansthattheleft-sideis eitherequalto theright-sideor asub-patternof theright-side.

It is also possibleto test for equality of patternvariablesusing the if-imperative,asshown in Sections6.1and7.6.

Block structure and relational operators

Considerthefollowing declarations:


T: (# P: (# ... #); ... #);X1,X2: @T

The two patternsX1.P andX2.P aredifferentpatterns,meaningthat the ex-pressionX1.P## = X2.P## hasthevaluefalse . This exampleis similar tothe Grammar examplediscussedin Section8.2, with Pascal.Symbol beingdifferentfrom Simula.Symbol .

If X1 andX2 aredeclaredasdynamicreferences:

X1,X2; ˆT1

thenthey may refer to the sameobjector to differentobjects. In the formercaseX1.P## = X2.P## will have thevaluetrue , whereasin thelattercaseitwill have thevalueFalse .

‘First class’values

Patternvariablesmake patterns‘first class’valuesin the sensethata patterncanbe assignedto a variable,passedasa parameterto a procedurepattern,andreturnedasa resultof aprocedurepattern.

It is alsopossibleto changethe behavior at run-timeof objects. Insteadof usingvirtual procedurepatternsit is possibleto usevariableprocedurepat-terns. If variableprocedurepatternsareused,their valuecanbe completelyredefinedin sub-patterns.Consideranextensionof theexamplefrom thestartof this chapter:

T: (# A: (# ...#);V:< D;F: ##P

#)

For instancesof T andinstancesof sub-patternsof T, theattributeA is constant,V mayhave differentbindingsin sub-patternsof T. TheattributeF mayhavedifferentbindingsin differentinstancesof thesamesub-patternof T, andthebindingin agiveninstancemaybechangeddynamically:

T1: T(# ... #);X1,X2: @T1...P1##->X1.F##; P2##->X2.F##; ...; P3##->X1.F##; ...

11.2 Example

Thefollowing is anexampleof theuseof patternvariables.

11.3 EXERCISES 159

Consider/ a drawing tool for drawing boxes and ellipseson a graphicalscreenusingmenusanda mouse.Whenever the userclicks a button on themouse,one of two actionsis performed: either a symbol is drawn on thescreenor a symbolpointedat is moved. Thereis alwaysa ‘currentaction’ tobeperformed.Thecurrentactionis selectedin the ‘actionsmenu’wheretheusercanselecteither‘draw’ or ‘move.’ When‘draw’ is selected,thecurrentsymbolis drawn on thescreen.Thecurrentsymbolis selectedby theuserviathe‘symbol menu.’

The DrawingTool patternin Figure11.1 describesthe drawing tool. Ithasattributes representingthe two types of symbolsand the two typesofactions. It hasa patternvariablefor referring to the currentselectedsym-bol (CurrentSymbol ) and one for referring to the current selectedaction(CurrentAction ). TheprocedurepatternattributeSelectAction is executedwhentheuserselectsanentryin theactionmenu.SelectSymbol is executedwhen the userselectsan entry in the symbol menu. DoAction is executedwhentheuserclicksabuttonon themouse.

When DoAction is executed, an instance of the pattern variableCurrentAction is executed. SinceCurrentAction will refer to either theDrawAction or theMoveAction , oneof thesetwo actionswill beexecuted.

WhenDrawAction is executed,aninstanceof CurrentSymbol is created.SinceCurrentSymbol will refer to either Box or Ellipse , either a box orellipseobjectis created.

11.3 Exercises

(1) In Section7.6 the attribute jobType wasintroducedasan integer vari-able. For this to work properly, jobType must be initialized for eachjob object. Considerhow jobType insteadcouldbedefinedasa virtualpatternattributetherebyavoiding theinitialization problem.

(2) Thepatternqua maybeusedin thefollowing way:

R: ˆT;..(R[]->qua(# qual::T1 #)).x->a

Thepatternqua checksif R##<=T1## . If this is trueit returnsa referencequalifiedby T1. It is thuspossibleto usequa for testingthequalificationof apatternandsubsequentlyuseit in acomputedremotename.

Implementqua in BETA.

(3) Extendthedrawing tool from Section11.2to includeconnectorsbetweenboxesandellipses.


DrawingTool:(# Symbol: (# ... #);

Box: Symbol(# ... #);Ellipse: Symbol(# ... #);

Action: (# ... #);DrawAction: Action

(# F : ˆSymboldo ... &CurrentSymbol[]-> F[] ; ...#);

MoveAction: Action(# ... #);

CurrentSymbol: ##Symbol;CurrentAction: ##Action;

SelectAction:(# item : @textenter itemdo (if item

// ’draw’ then DrawAction##->Curren tA cti on##// ’move’ then MoveAction##->Curren tA cti on##

if)#);

SelectSymbol:(# item: @textenter itemdo (if item

// ’box’ then Box##->CurrentSymb ol# #// ’ellipse’ then Ellipse##->CurrentS ymbol# #

if)#);DoAction:

(#do CurrentAction#)

#)

Figure11.1 ThepatternDrawingTool .

11.4 Notes

Procedurevariablesareknown in many languages.In Lisp-basedlanguagesandfunctionalprogramminglanguagesit is usuallypossibleto passfunctions

11.4 NOTES 161

around< asargumentsof functionsandreturnfunctionsasthe resultof otherfunctions. In Algol-60 it is possibleto passa procedure/functionasanargu-mentto a procedure/function.It is not possibleto returna procedure/functionasa resultor to declareprocedurevariables.In C it is, for instance,possibleto havepointersto functions.

Most object-orientedlanguagesdo not have constructssimilar to pat-tern variables. Patternvariablesas describedherewere suggestedby OleAgesen, Svend Frølund and Michael H. Olsen in their Masters Thesis(Agesenetal., 1990).

Patternvariablesmake the principal distinctionbetweenclass-basedlan-guagessuchasBETA andclasslesslanguagessuchasSelfmoreblurred.Oneof theadvantagesof classlesslanguagesis thatsinceobjectreferencescanbepassedasparameters,etc., this givesthe power of passingclassesaroundasparameters.As hasbeenseen,patternvariablesprovide thesamepower.

In BETA it is possibleto write a ‘classless’programby meansof singularobjects.‘Instances’of thesesingularobjectsmaybecreatedasshown above.It is, however, notpossibleto definesub-classesof suchobjects.

Onemayaskthequestionwhetheror not it is usefulto havebothpatternsandobjects.Languageslike Selfdemonstratethat it is possibleto have onlyobjects.The reasonfor having bothpatternsandobjectsin BETA is that formodelingpurposesit is importantto distinguishbetweenconcepts,andphe-nomenaandtheirrepresentationin termsof patternsandobjects.If objectsareusedfor representingconcepts,andinstancesarecreatedby meansof cloning,it may be very difficult to understandthe structureof a program. In the Ce-cil language(Chambers,1992), which is claimedto be classless,objectsaredivided into variouscategoriesincluding abstractandtemplate. An abstractobjectcanonly beusedfor inheritanceanda templateobjectcanonly beusedfor instantiation.Themotivationfor this categorizationof objectsis to avoidcertainrun-timeerrorswhenmanipulatingsuchobjects.It is very difficult toseetheprincipaldifferencebetweena templateobjectandapattern.


Chapter 12

ProceduralProgramming

In this sectionwe show how to supportproceduralprogramming,i.e. viewinga programasa collectionof proceduresthat manipulatea setof datastruc-tures. The datastructuresareimplementedasinstancesof classesusedlikePascalrecords. In Chapter3, variousexamplesof proceduralprogrammingweregiven. ThepatternsFactorial , Power andReciproc areall donein aproceduralstyle. Modernprocedurallanguageslike ModulaandAda includea module(calleda package in Ada) construct.In this chapterwe describetheBETA alternativesto themodule/packageconstruct.

Two interestingissuesin programminglanguagesarethenotionsof higherorder proceduresandtypes. A higherorderprocedureis a procedureparam-eterizedby proceduresand/ortypes. Similarly, a higherordertype is a typeparameterizedby proceduresand/ortypes.A procedureor typespecifiedasaparameteris calleda formal procedure or formal type. Theprocedureor typepassedasaparameteris calledtheactualprocedureor actualtype.

Therehasbeenatendency to restrictsupportfor formalproceduresin pro-cedurallanguages.Algol-60 hasfull supportof formal procedures,whereaslanguageslike PascalandAda have restrictedforms. In Ada formal proce-duresandformal typesareto a limited extentsupportedby so-calledgenericmodules.It is outsidethescopeof this bookto describegenericmodulesandotherlanguageconstructsthatsupporthigherorderproceduresandtypes. Inthischapterwepresentexamplesof virtual patternsusedasformalproceduresandtypes.

In the following, languageconstructssuchasmodule,package,genericandhigherorderprocedureandtypewill bementionedto comparehow suchconstructsmaybeexpressedwithin theobject-orientedframework presentedhere. It will beanadvantageif thereaderis familiar with suchconstructs.Itis, however, possibleto readthe following sectionswithout suchknowledge.The main purposeof this chapteris to presentvarioususeful programmingtechniques.

163

164 PROCEDURAL PROGRAMMING

Complex:(# I,R: @real;

Plus:(# X,Y: @Complexenter Xdo X.I+I->Y.I; X.R+R->Y.Rexit Y#);

Mult: ...enter(I,J)exit(I,J)#);

C1,C2,C3: @Complex...C2->C1.Plus->C3

Figure12.1 Complex class.

12.1 Functional classes

In object-orientedprogramminglanguagesthereis often an asymmetrybe-tweenoperandsof a function.ConsidertheclassComplex in Figure12.1.Thefunction+ is modeledby theattributePlus of Complex . An ordinaryexpres-sionC1 + C2 thenhastheform C2->C1.Plus . As canbeseen,theargumentsC1 andC2 aretreateddifferently.

This hasoften beencriticized. The authorsof CLU (Liskov andZilles,1974)decidedto qualify theoperationsusingclass-nameinsteadof instance-name.Theaboveoperationlookslike thefollowing in CLU:

C3:=Complex$Plus(C1,C2)

A consequenceis thatall operation-callsmustbedenotedin this way.In Smalltalk the asymmetryhasbeenkept. Numbersare viewed as in-

stancesof aclassandrespondto messages,althoughthis maynotbethemostnaturalway of modelingnumbersin a programminglanguage. Below weshow thattheprocedural/functionalstylecanbeexpressedin BETA.

Consider the definition of a complex packagein Figure 12.2. TheComplexRing classdefinesa setof attributesthat implementcomplex num-bers.TheobjectCR is aninstanceof ComplexRing . Theattributesof CRmaythenbeusedasshown in theexample.In CLU, theoperationsarequalifiedbya typename;herethey arequalifiedby anobjectname.As canbe seen,the

12.1 FUNCTIONAL CLASSES 165

(#ComplexRing:

(#Complex:

(# I,R: @realenter(I,R)exit(I,R)#);

Create:(# R,I: @real; C: @Complexenter(R,I)do R->C.R; I->C.Iexit C#);

Plus:(# A,B,C: @Complexenter(A,B)do A.I+B.I->C.I; A.R+B.R->C.Rexit C#);

Mult: ...#);

CR: @ComplexRing; {package object}X,Y,Z: @CR.Complex;

do(1.1,2.2)->CR.crea te- >X;(3.1,0.2)->CR.crea te- >Y;(X,Y)->CR.plus->Z

#)

Figure 12.2 Complex package.

definitionof complex numbersis ‘functional.’ Thereis noasymmetrybetweentheargumentsof theoperations.Objectslike CRarecalledpackageobjects.


T: (# T1: (# ... #);T2: (# ... #);...Tn: (# ... #);

F1: (# X: @T2; y: @T3; z: @T1enter(x,y)do ...exit z#);

F2: (# ... #);...Fm: (# ... #)

#);

aT: @T;a: @aT.T1; b: @aT.T2; c: @aT.T3;...(b,c)->aT.F1->a

Figure 12.3 Definitionof a setof mutuallydependentclasses.

Mutually dependentclasses

In CLU a classdefinesa singleabstractdatatype. In Ada it is possibletodefinea packageconsistingof mutuallydependenttypes, i.e. typesthatmustknow aboutoneanother’s representation.It is straightforward to generalizethe techniqueusedfor the ComplexRing classto definemutually dependentclasses.Figure12.3illustratesasketchof classthatdescribespackageobjectswith attributesconsistingof n classesandm operations.

In Figures12.4 and12.5 an exampleof two mutually dependentclassesis shown. The patternVectorMatrixPackage definestwo classpatterns,Vector and Matrix , and a numberof associatedoperations. The Matrixoperationsmakeuseof therepresentationof a Vector object.

The notation used in the above examples has two immediate draw-backs:

0 It maybeawkwardto alwayshave to qualify attributesof a packageobjectwith thenameof thepackageobject.This canbeavoidedby a mechanismsimilar to thewith-statementof Pascalor inspect-statementof Simula:

12.1 FUNCTIONAL CLASSES 167

VectorMatrixPackage :(# Vector:

(# S: [100] @Integer;Get: (# i: enter i exit S[i]#);Put: (# e,i: @integer enter(e,i) do e->S[i] #)

#);Matrix:

(# R: [100] ˆ Vector;Init:<

(#do (for i:R.range repeat &Vector[]->R[i][] for); INNER#);Get: (# i,j: @integer enter(i,j) exit R[i].S[j] #);Put: (# e,i,j: @integer enter(e,i,j) do e->R[i].S[j] #)

#)VectorBinOp:

(# V1,V2: ˆ Vectorenter(V1[],V2[]) do &Vector[]->V3[]; INNER exit V3[]#);

AddVector: VectorBinOp(#do (for i: V1.S.range repeat V1.S[i]+V2.S[i]->V3. S[ i] for)#);

...MatrixBinOp:

(# M1,M2,M3: ˆ Matrixenter(M1[],M2[]) do &Matrix[]->M3[]; M3.init; INNER exit M3[]#);

AddMatrix: MatrixBinOp(#do (for i: M1.R.range repeat

(for j: M1.R[i].S.range repeatM1.R[i].S[j] + M2.R[i].S[j]->M3.R [i] .S [j]

for)for)#);...MultMatrixByVector: ...

#);

Figure 12.4 Vectorandmatrixpackage.

with aT do(# a: @T1; b: @T2; c: @T3;do (b,c)->F1->a#)

Of course,this only works if thereis just oneinstanceof the classT. Adaalso hasa variant of the with statement. BETA doesnot have a with-statement.


MultMatrixByVecto r:(# V: ˆ Vector; M1,M2: ˆ Matrixenter(M1[],V[])do &Matrix[]->M2[];

(for i: V.S.range repeat(for j: M1.R[i].S.range repeat

V.S[i] * M1.R[i].S[j]->M2.R [i] .S [j]for)for)

exit M2[]#)

Figure12.5 Vectorandmatrixpackage.

0 If only oneinstanceof theclassis needed,it mayalsobedesirableto avoiddeclaringtheclass.This canbeaccomplishedby definingthepackageob-jectasasingularobject:

aT: @(# T1: ...; T2: ...; ... Tn: ...;F1: ...; F2: ...; ... Fm: ...;

#)

0 An alternativeto thewith statementandsingularobjectsis to useasingularinsertedobjectprefixedby T, asin

(# ...do T(# {All declarations in T are visible here} #)#)

This techniqueis oftenusedin practice.

Theexamplesin thissectioninvolvepackageobjectsthathaveonly class-andprocedureattributes.Thereis thusno stateassociatedwith thesepackageob-jects. Sincean J object-descriptionK maycontainvariabledeclarations,it ispossibleto describepackageobjectswith state.A singularpackageobjectlikeaT is thenquitesimilar to anAda package.A class,like T or ComplexRing ,describingpackageobjectscorrespondsto an Ada genericpackagewithoutgenericparameters.An instanceof sucha classcorrespondsto an instantia-tion of anAdagenericpackage.Laterin this chapterwediscusshow patternscanbeusedto modelgenericpackageswith genericparameters.

12.2 HIGHERORDERPROCEDUREPATTERNS 169

12.2 Higher order procedurepatterns

It is possibleto definehigherorderprocedurepatternsusingvirtual procedurepatternsand/orpatternvariablesasformal procedures.By higherorder pro-cedure patternwe understanda procedurepatternthat is parameterizedby apatternor returnsapatternasa value.

Considerthefollowing patterns:

IntFunc: (# X,Y: @integer enter X do INNER exit Y #);

PlotFunc:(# F:< IntFunc;

first,last: @Integer;Device: ˆ Image

enter(first,last,Device[])do (first,last)->forTo

(# inx: @Indexdo (inx,(inx->F))->Device.PutDot

#)#)

ThepatternPlotFunc is supposedto plot thevaluesof the function F in theinterval [first,last] . Assumethatwehave functions:

Square: IntFunc(#do X*X->Y #);Double: IntFunc(#do X+X->Y #)

Thefollowing ‘function calls’ will thenplot thevaluesof thesefunctions:

(15,30,somePlotter[])->PlotFunc(# F::Square #);(20,40,somePlotter[])->PlotFunc(# F::Double #);

Assumethat we want to plot the valueof the factorial function asdescribedin Chapter3. Factorial hasnot beenspecifiedasa sub-patternof IntFunc .Wemay‘pass’Factorial in thefollowing way:

(1,6,somePlotter[])->PlotFunc(# F::(#do X->Factorial->Y#)#)

In theaboveexample,virtual patternsareusedfor parameterizingaprocedure.The following exampleshows how this canbe doneusingpatternvariables.Thisstyleis similar to a traditionalstyleof higherorderprocedurepatterns:

PlotFunc:(# F: ##IntFunc;

first,last: @Integer;Device: ˆ Image

enter(F##,first,last,Device[])


do (first,last)->forTo(# inx: @Indexdo (inx,(inx->F))->Device.PutDot

#)#);...(Square##,15,30,somePlotter[])->PlotF unc;(Double##,20,40,somePlotter[])->PlotF unc;

In theabove example,a patternvariablewasusedasanenter-parameter. Thenext exampleshows a procedurepatternthatreturnsa patternvariablevia theexit-list. The exampleshows how to definea function comp for composingtwo integerfunctions:

comp:(# f,g: ##IntFunc; h: IntFunc(#do x->f->g->y #)enter(f##,g##)exit h###);

C: ##IntFunc;...(Double##,Square##)->comp->C##;5->C->x {x=100}

12.3 Virtual classesand genericity

(Meyer, 1987a) presentsaninterestingcomparisonbetweengenericityandin-heritance,showing that,in general,inheritancecannotbesimulatedby gener-icity while genericitycan be simulatedby inheritance. However, the tech-niquesfor simulatingso-calledunconstrainedgenericitybecomeratherheavy.For this reason,unconstrainedgenericitywasincludedin Eiffel.

In thissectionweshow to whatextentvirtual classescanreplacegenericityusingthe exampleof a generalclassRing (Meyer, 1988) with the attributesZero, Unity, Plus andMult . We useRing to definesub-classesComplex ,anda generalclassVector parameterizedby Ring . The Vector classis inturnusedto definea ComplexVector class.

The first versionof classRing is definedin a pure object-orientedstyle,i.e. operationslike + areasymmetrical;a+b is performedasa->b.plus . Inthe next sectionanotherversionof classRing is definedusinga functionalstyle. Herethe+ is definedasa functionof two arguments.

12.3.1 Pure object-orienteddefinition of classRing

Thepureobject-orientedversionof classRing is shown in Figure12.6. ThegeneralclassRing definesthe virtual procedureattributes Zero, Unity,

12.3 VIRTUAL CLASSESAND GENERICITY 171

Ring:(# ThisClass:< Ring;

Plus:< (# A: ˆThisClass enter A[] do INNER #);Mult:< (# A: ˆThisClass enter A[] do INNER #);Zero:< (# do INNER #);Unity:< (# do INNER #)

#);Complex: Ring

(# ThisClass::< Complex;I,R: @real;Plus::<(# do A.I->I.Plus; A.R->R.Plus #);Mult::< (# ... #);Zero::< (# do 0->I->R #);Unity::< (# ... #)

#);Vector: Ring

(# ThisClass::< Vector;ElementType:< Ring;R: [100] ˆ ElementType;Plus::<

(#do (for i: 100 repeat

A.R[i]->R[i].Plusfor)#);

Mult: ... Zero: ... Unity: ...#);

ComplexVector: Vector(# ThisClass::< ComplexVector;

ElementType::< Complex#)

C1,C2: @Complex;V1,V2: @ComplexVector...C1.Unity; C2.Zero; C1[]->C2.Plus;V1.Unity; V2.Unity; V1[]->V2.Plus;

Figure12.6 Object-orienteddefinitionof classRing .

Plus andMult . In addition,a virtual classattribute ThisClass (explainedbelow) is included.TheclassComplex is oneexampleof asub-classof Ring .

A moreinterestingsub-classof Ring is theclassVector , which includesavirtual classattributeElementType qualifiedby Ring . ElementType defines


the classof the elementsof the vector, i.e. the elementsof the vectorhaveall the propertiesof a ring. ClassComplexVector is a sub-classof Vectorwherethe virtual classElementType is extendedto be classComplex . (Inthis examplea vectorconsistsof 100elements.By usinga virtual procedure,yielding an integervalue,it is straightforward to parameterizethesizeof thevector.)

The virtual classThisClass is usedto ensurethat the argumentof, sayPlus , is alwaysof thesametypeasthecurrentclass.In Complex it is there-fore extendedto be a Complex , and in Vector it is extendedto Vector . Ifthe referenceA in the definition of Plus in classRing wasdefinedasA: ˆRing , thenin theextensionof Plus in Complex thereferenceA might refertoany Ring object. An explicit checkwould be neededto ensurethat A refersto a Complex object.In addition,anoperationlike V1[]->C2.Plus wouldbevalid. Insteadof explicitly definingavirtual classlikeThisClass , it wouldbemoreconvenientto have a predefinednamefor this. For BETA this wassug-gestedin (Kristensenet al., 1983b). In (BorningandIngalls,1981) aproposalfor Smalltalkwasmade.In Eiffel theexpressionlik e current correspondstoThisClass .

12.3.2 Functional definition of classRing

In this sectiona functionalversionof classRing is given.In languageswith apackageconceptonecandefinepackagesthatcontainthedefinitionof a typeandtheoperationsonthis type.A packageis notaclass,but ratheradefinitionof asingleobject.A genericpackage,ontheother, handresemblesaclass,butthisis verylimited. In object-orientedterminology, agenericpackagecanonlybeusedfor creatingasingleinstance(a package).It is actuallyjust templatesthatareelaboratedat compiletime; it is not possibleto addpropertieslike insub-classes.

It is possibleto modela genericpackageby a classwith virtual classandvirtual procedureattributesrepresentingthe formal typesand formal opera-tionsof thepackage.

In Figure12.7a functionaldefinitionof theclassRing is given, togetherwith a sub-classComplexRing that definesthe type complex andoperationson complex objects.Thevirtual classattributeplaystherole of thetype. Theoperationson the type aredefinedin a functional (symmetrical)way on in-stancesof classType . TheType classis extendedin sub-classesof theRingclass.To usea ComplexRing it is necessaryto createaninstanceof it (in theexample,CR is suchaninstance).All complex referencesandoperationcallsarereferredto asattributesof CR. TheRing andComplexRing classescanbecomparedto genericpackagesin Ada andCR to a genericinstantiation.Thenext examplefurtherillustratesthis.

In Figure12.8a vectoris definedusinga functionalclass.Theimportant


Ring:(# Type:< Object;

Plus:<(# X, Y, Z: ˆTypeenter(X[],Y[])do &Type[]->Z[];

INNERexit Z[]#);

Mult: ... Zero: ... Unity: ...#)

ComplexRing: Ring(# Type::< (# I,R: @real #);

Plus::< (#do X.I + Y.I->Z.I; X.R + Y.R->Z.R #);Mult: ... Zero: ... Unity: ...

#);CR: @ComplexRing;C1,C2,C3: ˆ CR.Type...CR.Unity->C1[]; CR.Zero->C2[];(C1[],C2[])->CR.Plu s- >C3[]

Figure 12.7 Functionaldefinitionof Ring .

thing to noticeis that the elementtypeof a vectorring is not a virtual class,instead,it is describedby the referenceactualRingElement . The reasonisthata VectorRing instancemustbeparameterizedby a specificring, i.e. aninstanceof RingElement , otherwisethe elementsof a vector include, say,complex numbersfrom differentcomplex rings,whichseemsinappropriateinthiscase.(However, it is possibleto modelthis if desired.)In theexample,thereferenceactualRingElement is givenavaluewheninit is executed.(CRistheComplexRing from Figure12.7.) This is, however, not satisfactory, sinceactualRingElement shouldnot changevalueafter the initialization, but itshoulddenotethesameComplexRing duringthelife timeof theVectorRing .Thiscanbeaccomplishedby makingactualRingElement a ‘call-by-const’1

parameterof theclassVectorRing . It maythenbeboundwheninstantiatinga VectorRing (or oneof its sub-classes)andnot modifiedafterwards.Sincesuchparametermechanismsarewell known it will notbefurtherelaborated.

1‘Call-by-const’wasusedin thefirst versionof Pascal.


VectorRing:Ring(# RingElement:< Ring;

actualRingElement: ˆRingElement;Type::< (# V: [100] âctualRingElement .Ty pe #);Init:<

(# aRing: ˆRingElemententer aRing[]do aRing[]->actualRing Ele ment[ ]#);

Plus::<(#do (for i: 100 repeat

(X.V[i][],Y.V[i][])->actualRingElement. Pl us->Z.V[i]

for)#);

Mult: ... Zero: ... Unity: ...#);

ComplexVectorRing: VectorRing(# RingElement::< ComplexRing #);

CVR: @ComplexVectorRing;A,B,C: @CVR.Type...CR[]->CVR.Init

Figure 12.8 Functionaldefinitionof theclassVector .

12.3.3 Classattrib utesversustype attrib utes

It could be arguedthat the definition of ComplexRing doesnot demonstratetheneedfor or usefulnessof classattributes.TheattributeType couldalsobedefinedusingapure(record)type,asin Pascal.Suchrecordobjectscould,forinstance,only beassignableandcomparable,but nothaveprocedureandclassattributesasdoclasses.

However, by usinga classattribute it is possibleto combinethe object-orientedandfunctionalstyles. The Type classof ComplexRing may have aprocedureattribute Incr that incrementsa complex numberby 1 (seeFigure12.9).It seemsmorenaturalto expresssuchanoperationin anobject-orientedstylethanin a functionalstyle.

With the additionof the Incr it is possible,in additionto functionalex-pressions,to specifyevaluationslike:


ComplexRing:Ring(# Type::<

(# I,R:@real;Incr: (# do I+1->I; R+1->R #)

#);...

#);

Figure12.9 Complex with local Incr operation.

VectorOfVector: Vector(# ElementType:: Vector(# ElementType:: Elm #)

Elm:< Ring;ThisClass::< VectorOfVector

#);VectorOfVectorOfCom pl ex: VectorOfVector

(# ThisClass::< VectorOfVectorOfC omplex ;Elm::< Complex

#)

Figure12.10 ClassVectorOfVector .

...; C1.Incr; ...

12.3.4 Mor eon extendingvirtual classes

In this section,theVector classof Figure12.6will befurtherelaborated.Asshown in Figure12.10,a VectorOfVector classparameterizedby Vector isdefined.A new virtual classElm hasbeenintroducedto standfor theparameterof theclassVectorOfVector . Theuseof :: insteadof ::< specifiesthatthisis thefinal extensionof ElementType , i.e. it is no longervirtual. In general,itis usefulto beableto specifythatavirtual attributecannolongerbeextended.

A noteon syntaxmayseemappropriatehere.Thesyntaxfor definingandextendingvirtualsin examplesliketheRing maybetooheavy. Instead,ausualpositionalnotationfor definitionandextensionof virtualsis beingconsidered.


12.4 Notes

Theexamplesin this chaptershow thateventheproceduralstyleof program-ming canbe supportedwithin a languageprimarily intendedfor the object-orientedstyleof programming.As pointedoutby others(Cox,1984;NygaardandSrgaard,1987),a programminglanguageshouldsupportmorethanonestyle. Object-orientedprogramming,proceduralprogrammingand,to a lim-ited extent, functionalprogrammingaresupportedby languageslike Simula,BETA andC++.

A propertycommonto most object-orientedprogramminglanguagesisthateverythinghasto be regardedasan objectwith methods,andthateveryactionperformedis messagepassing.The implication of this is that even atypical functionalexpressionsuchas:

6+7

getstheunnaturalinterpretation:

6.plus(7)

In Smalltalktheexpression6+7 is interpretedasthemessage+ with argument7 is sentto the object6. The resultof this messageis that the object13 isreturned.Eventhough6 and7 areobjects,thereis no reasonwhy + maynotberegardedasanobjectthataddstwo integerobjects:

plus(6,7)

Thinking object-orienteddoes not have to exclude functional expressionswhen this is more natural. Functions,typesand valuesare in fact neededto describemeasurablepropertiesof objects.

Chapter 13

Deterministic Alter nation

In our computerizedmodelswemustbeableto representactionstakingplacein the applicationdomainbeingmodeled.Examplesof suchactionsarede-positof money in a bankaccount,reservationof a seaton a flight, pushingabutton,etc. For certainactionstheorderingin time is important,for instance,in thecasewith thesequenceof depositsandwithdrawalson a specificbankaccount.In thepreviouschapterswe have seenhow to describea sequentialorderingof actions.

Justasit is importantto be ableto describethat two actionsareorderedin time, it is importantto beableto describethat thereis no orderingin timebetweentwo actions.Thedepositof money in onebankaccountandthewith-drawal of money from anothermaytakeplaceindependentlyin thesensethatit is not importantto describeanorderingin time betweenthetwo actions.Inour computerizedmodelswe mustbeableto modelseveralactionsequencestakingplacein concurrency. Fromtimeto timetheactionsequencesmayhaveto besynchronized. This is, for instance,thecasewhentwo or moreagentstryto book the sameseat. A computerizedmodelmustbe ableto representthesynchronizationof actionsequences.

A numberof activitiesmaybeviewedascompoundsystemsconsistingofseveralconcurrentactionsequences.Examplesof thisaremachinesconsistingof severalparts,eachexecutinganindependentactionsequence.In othercasesanactivity maybecharacterizedby performingseveralactionsequences,butat mostoneat a time. Theactivity will thenshift betweenthevariousactionsequences.An exampleof this is a cookmakingdishes.This involvesseveralongoingactivities by thecookwho constantlyshiftsbetweenthoserequiringhisattention.Anotherexampleis theagentsof atravel agency. They oftenper-form complex tasksconsistingof severalmoreor lessindependentactivities.An agentmaybeinvolvedin ‘tour planning,’ ‘customerservice’and‘invoic-ing.’ Theagentwill alternatebetweentheseactivities. Whenanagentshiftstoa new activity, thecurrentactivity is temporarilysuspended.Laterwhentheagentreturnsto this activity it is resumedat thethepoint of suspension.This

177

178 DETERMINISTIC ALTERNATION

form of sequencingis calledalternation.A processorhandlingseveral devices may naturallybe describedby al-

ternation. The handlingof eachdevice generatesan action sequence.Theprocessorthenalternatesbetweentheseactionsequencesdependenton whenthedevicesneedto beserved.

Alternationshouldnotbeconfusedwith trueconcurrency, whereanumberof taskstake placeat the sametime. In alternation,at mostoneof the taskstakesplaceat agiventime.

Deterministicalternationis thesituationwheretheobjectdecidesby itselfhow to alternatebetweenthedifferenttasks.Nondeterministicalternation isthesituationwhereexternaleventscausetheobjectto shift to anothertask.

In the travel agency example,eachagentservesa numberof customersandhasa file for eachcustomer. A taskfor anagentis to processa customerfile. During a working day theagentalternatesbetweenthe tasksprocessingthe customerfiles. Most of the time the agentwill decidethe orderof thetasks.However, externaleventssuchastelephonecallsmayforcetheagenttochangetask.

Action sequencingappearsin several ways in programminglanguages.The simplestmechanismis sequentialexecution, whereproceduresareexe-cutedsequentiallyandthedynamicstructureof activeprocedureactivationsisorganizedasastack.

To modelconcurrency andalternation,a programexecutionmaybeorga-nizedasseveralsequentialprocesses.This modeof executionis calledmulti-sequentialexecution. Severallanguageconstructsthatsupportmultipleactionsequenceshavebeenproposed.

Oneexampleof a multi-sequentialexecutionis coroutinesequencing. Acoroutineis anobjectthathasits own stackof procedureactivations.A pro-gramexecutionwill thenconsistof anumberof coroutines.Theprocessorwillthenalternatebetweenexecutingthesecoroutines.A coroutinemaytemporar-ily suspendexecutionandanothercoroutinemay be executed.A suspendedcoroutinemay laterberesumedat thepoint whereit wassuspended.These-quencingbetweencoroutinesis deterministicandexplicit, sincetheprogram-mer specifiesas part of the coroutinewhen it shall suspendits actionsandwhichcoroutineis to takeover.

In anumberof situationsaprogramexecutionhasto dealwith multipleac-tion sequencesthatgo on concurrently. Coroutinesarenot suitableto supportsuchconcurrentactionsequences.In the coroutinesituation,eachcoroutinehasexclusive accessto commondataand thereis no needfor synchroniza-tion. However, to handleexplicitly thesequencingbetweena largenumberofsymmetriccoroutinesrequiresstrict disciplineof theprogrammer. In thecon-currentsituation,it is oftennecessaryto beableto dealwith nondeterminism:for example,asystemwith multipleprocessors.

In BETA, actionsequencesareassociatedwith objects;objectsmayexe-

DETERMINISTICALTERNATION 179

cutetheirB actionsaspartof theexecutionof otherobjects.Suchobjectsareofkind itemandhave beencoveredin previouschapters.Objectsmayalsoex-ecutetheir actionsconcurrentlywith otherobjects,or they mayexecutetheiractionsalternatingwith otherobjects.Suchobjectsareof kind component.

Thealternationbetweentwo or moreactionsequencesmaybedetermin-istic or nondeterministic. In this chapter, deterministicalternationin BETAwill bedescribed.Concurrency is coveredin Chapter14andnondeterministicalternationin Chapter15.

In BETA, deterministicalternationis supportedbycomponentobjectsusedascoroutines.1 Coroutinesmakesit possibleto alternatebetween‘stacksofexecutions.’ Objectsare‘statemachines’in the sensethat the resultof a re-moteprocedurecall may dependon the stateof the variablesof the object.For objectsthatarecoroutines,thestatemayincludea point of execution.Ingeneral,suchanexecutionstateinvolvesa stackof procedureactivationscur-rentlycalled.Thepossibilityof saving thestateof executionmakescoroutinesusefulfor a largenumberof applications.Theseapplicationsmaybegroupedasfollows:

0 With respectto themodelingof real-life phenomena,the main motivationfor coroutinesis to modelobjectsthat performalternatingactivities. Thealternationbetweencoroutinesmay be deterministicin the sensethat thesequencingis decidedby the object itself. The shifts betweencoroutinesmaybetriggeredby eventsperformedby otherconcurrentobjects,leadingto nondeterministicalternation.Onemainreasonfor introducingcoroutinesin BETA is for modelingobjectsthatalternatebetweenanumberof sequen-tial processes(tasks).

0 Coroutinesmay be usedto createan illusion of concurrency. The basicschedulingof coroutinesis usuallyexplicit, sincea coroutinerelinquishingcontrol namesthecoroutinethat is to take over. It is possibleto eliminatetheexplicit schedulingby constructionof acoroutinescheduler(anexampleof this is shown in Section13.4.2).

0 A certainclassof algorithmsis bestunderstoodasa setof interlockedse-quentialexecutionstacks.This includesbacktrackingandpatternmatching.In Section13.3anexampleof suchanalgorithmis given.

0 A generator is a coroutinecapableof producinga sequenceof values. Anew valueis producedfor eachinvocationof thecoroutine.Thenext valuedependsonthesequenceof previouslygeneratedvalues.In Section13.2anexampleof ageneratorof factorialnumbersis given.

1In thefollowing, theterm‘coroutine’ will oftenbeusedasa synonym for objectsof thekind component.


R1

B

A

R1 R1

C

A

L1: L2: L3:

Figure 13.1 Snapshotsof theexecutionstack.

13.1 Executionstacks

In thissectionwewill takeacloserlook atexecutionstacks,andintroducethebasicelementsof coroutines.Considerthefollowing object:

R1: @(# A: (# do ...; B; ...; C; ... #);

B: (# do ...; L2: ... #);C: (# do ...; L3: ... #);

do ...; L1: A; ...#)

The executionof R1 is organizedin termsof a stackof active objects,illus-tratedin Figure13.1. At thelabelL1 thestackonly consistsof theobjectR1,andat L2 thestackconsistsof R1, A andB. At L3, B hasterminatedandC hasbeencalled.Eachobjectonthestackhasastructuralattributecalledthereturnlink. Thereturnlink consistsof a dynamicreferenceto thecalling objectanda codepoint in thecalling objectfrom wherethecall wasmade.Thearrowsin thediagramsrepresentthesedynamicreferences.

Theorganizationof actionsequencesin termsof stacksis usefulfor mod-eling sequentialexecutions.To modelmulti-sequentialexecutions,it is nec-essaryto be ableto organizea programexecutionin termsof severalstacks.Considerthefollowing object:

R2: @(# X: (# do ...; Y; ... #);

Y: (# do ...; K1: Z; ... #);Z: (# do ...; K2: ... #)

do ...; X; ... K3:#);

13.1 EXECUTIONSTACKS 181

TheexL ecutionof R2 mayalsobe illustratedby meansof a stackin the sameway asfor R1. In this chapterwe will introducelanguagemechanismsthatmake it possibleto describean object that alternatesbetweenexecutingR1andR2. First,partof R1 maybeexecuted,thenpartof R2, thenpartof R1, etc.Suchascenariois describedbelow, andillustratedin Figure13.2:

(13.2.a)The initial stateof executionconsistsof threeobjects: R1, R2 andP* . The objectP* representssomeactive object. P* is the object thatalternatesbetweenexecutingR1 and R2. The objectsR1 and R2 arepassive. Thedynamicreferenceof theseobjectsreferto thetopelementof thestack,which initially is theobjectitself.

(13.2.b)AssumethatP* startsby executingR1. This is doneby attachingR1to thestackof P* . This figureillustratesthestateof executionwhenR1is at thelabelL1.

(13.2.c)ThisfigureillustratesthesituationwhenR1 is at thelabelL2.

(13.2.d)At this point we assumethattheexecutionof R1 is temporarilysus-pended,andthatP* startsexecutingR2 by attachingR2 to its stack.ThesituationwhenR2 is at the label K2 is shown in this figure. Note thatthe executionstackof R1 is shown with the dynamicreferenceof R1referringto thetopelementof its stack.

(13.2.e)At thispoint theexecutionof R2 maybesuspendedandtheexecutionof R1 may be resumed.This figure shows the situationwith R1 at thelabelL3.

(13.2.f)R1 maycontinueexecutionuntil it terminates.In this case,P* mayresumeexecutionof R2. ThisfigureshowsthesituationwhereR1 is ter-minatedandR2 is at thelabelK3, i.e. immediatelybeforeit terminates.

Theabovescenariomaybedescribedby thefollowing object:

(# R1: @ |(# A: (# do ...; B; C; ... #);

B: (# do ...; L2:suspend; ... #);C: (# do ...; L3: ... #);

do ...; L1: A; ...

#);R2: @ |

(# X: (# do ...; Y; ... #);Y: (# do ...; K1: Z; ... #);


C

R1

A

R2

P*

X

Y

Z

P*

R1 R2

P*

R2 R1

A

B

X

Y

Z

P*

P* P* P*

P*

B

R1

A

P*

P*

R1

(a) (b)

(c) (d)

(e) (f)

P*

R1

R2

R2

R2

Z

Figure13.2 Snapshotsof alternatingexecutionstacks.


Z: (# do ...; K2: suspend;... #)do ...; X; ...; K3:#);

do M0: R1; R2; R1; R2#)

Thesymbol| describesthattheobjectsR1 andR2 maybeexecutedalternately.The imperative suspend usedwithin R1 andR2 describesthat the executionof R1/R2 is temporarilysuspended.The object containingR1 and R2 playsthe role of P* . The situationat label M0 thencorrespondsto the situationinFigure13.2.a.Thesituationscorrespondingto Figures13.2.b-eillustratetheexecutionof theabove object. In the following section,the languagemecha-nismsfor coroutinesequencingaredescribedin detail.

13.1.1 Languageconstructsfor basiccoroutine sequencing

In the above example,the termsattach,suspendandresumehave beenusedfor describingthe alternationbetweenexecutionof R1 andR2. The precisemeaningof thesetermswill begivenbelow.

In addition,BETA constructsfor creatingandexecutingobjectsof thekindcomponentaredescribed.Theconstructionmodesfor thegenerationof com-ponentsarecompletelyanalogousto thosefor items. The term ‘object’ willbeusedwheneverwedescribesomethingthatis truefor all threekindsof ob-jects.Whenakind, likeacomponent,is explicitly mentioned,theexplanationis only valid for thatkind of object:

Component.An objectthatcanbethebasisfor anexecutionstackis calleda component. In Section5.10.1it was said that thereare two differ-ent kinds of objects: itemsandcomponents.The objectsthat canbeelementsof the stackof a componentareusually of kind item corre-spondingto instancesof procedurepatterns.However, aswe shall seelater, they mayalsobeof kind component.

Thedeclarations

R1: @ | P;R2: @ | P (# ... #)

describethatcomponentinstancesarecreated.R1 is aninstanceof P, whereasR2 isasingularcomponent.R1andR2arestaticcomponentreferencesthatwillconstantlydenotethenewly createdcomponents.Thesecomponentsarecalledstatic componentsor part components. R1 andR2 will eachhave their ownstackof activeobjects.Initially, thestackconsistsof R1 andR2, respectively.

Thedeclaration


R1

R1

P*

P*

R2

R2

Rn

Rn

(a)

(b)

. . .

. . .

Figure13.3 Generalexecutionstate.

S: ˆ | P

describesa dynamiccomponentreference. ThereferenceS maydenotecom-ponentinstancesof thepatternP. S maybeassigneda referenceto R1 by:

R1[] -> S[]

A componentinstancemaybedynamicallygeneratedby:

&|P[] -> S[]

Activestack.A programexecutionconsistsof anumberof componentstacks,asshown in Figure13.3.a.It consistsof thestackof P* , calledtheactivestack, andthestacksR1, R2 ,...,Rn, whicharesaidto besuspended. Theobjecton topof theactivestackis calledtheactiveobject; thetop-mostcomponentontheactivestackis calledtheactivecomponent. TheactiveobjectmayexecutetheactionsATTACH andSUSPEND.

Attachment.An actionATTACH(R), whereR is not a memberof the activestack,impliesthatthestackR is attachedto theactivestack.Technically


this happensby interchangingthereturnlink of P* andR. Figure13.3.billustratesthesituationafterATTACH(R1). Theexecutionof R is saidtoberesumed.

An imperative like:

R

whereR is a componentimplies that R is attachedto the active stackof thecomponentexecutingR.

ThecomponentexecutingR is saidto attach R.

Suspension.An actionSUSPEND(R), whereR is amemberof theactivestack,impliesthatthestackof R is removedfrom theactivestack.Technicallythishappensby interchangingthereturnlink of P* andR. (Notethatthisinterchangeis thesameasfor attach.Thedifferencein effect dependsonwhetheror notR is partof theactivestack.)R is saidto besuspended.

AssumethatR is thecurrentlyoperatingcomponent.Theimperative:

suspend

impliesthatR is detachedfrom theactivestack.R is now saidto besuspended.

Termination.If thecurrentlyoperatingstackfinishesexecutionof theimper-ative in its do-part,terminationof thecomponentwill take place.Thisimpliesexecutionof animplicit suspend.A subsequentattachmentwillresultin anabort event.2

Programobject. A BETA programto be executedby a BETA processoralwayshastheform:

(# ...do ...#)

that is, a BETA programis a singularobjectdescriptor. This singularobjectis actuallyof thekind component,whichmeansthatit is thebasisfor anexecutionstack.WhenaBETA programis executed,thisprogramobjectis alwaysactive. TheobjectP* usedin theabove examplesmaybethoughtof astheprogramobject.Intuitively, it maybeusefulto thinkof theprogramobjectasassociatedwith a processorof theunderlyinghardware.

2This impliesthattheprogramterminateswith a run-timeerror.


(# TrafficLight:(# state: @ Colordo Cycle(#

do red->state;SUSPEND;green->state;SUSPEND

#)#)North,South: @ | TrafficLight;

{Declaration of two component instances of TrafficLight}Controller: @ | {Declaration of a singular component}

(#do North; {attachment of North}

{North.state=red}South; South; {two attachments of South}

{South.state=green}Cycle(#do {wait some time}

South; North; {switch the states}#)#)

do Controller {attachment of Controller}#)

Figure13.4 Exampleof components.

Attachmentof R implies that the componentdenotedby R will be executed.This meansthat the actionsdescribedby the imperativesin the do-partof Rareexecuted.Theexecutionof thecomponentcontinuesuntil thecomponentexecutesa suspendimperative. This will return the control to the point ofthe attachment.A subsequentexecution(attachment)of the componentwillresumethecomponentafterthesuspendimperative. Thispatternmaybecon-tinueduntil thecomponenthascompletedexecutionof its do-part.

The example in Figure 13.4 TrafficLight describescomponentsthatwhenexecutedalternatebetweentwo states,red andgreen . TheControllercomponentinitializes the stateof North to red and the stateof South togreen . It repeatedlywaits for sometime, andthenswitchesthe lights. The‘variable’state is astaticreferencedenotinganinstanceof thepatternColor .TheColor instanceis anobjectof thekind item whereasall theotherobjectsarecomponents.An item is not a coroutine. In this examplethe Color in-stanceis usedasanordinaryvariable.

13.2 GENERATORS 187

13.2 Generators

Componentsmay have enter/exit parts. Prior to the attachmentof a compo-nent,a valuemay be assignedto the enterpart of the component.Whenacomponentsuspendsexecutionor terminates,a valuemay be assignedfromits exit part. If R is a componenthaving enter/exit parts,thenattachmentof Rwith parametertransferhastheform:

X -> R -> Y

whereX andY areevaluations.Thevalueof X is assignedto theenter-partofR, thenthe componentR is attached,i.e. executionof R is resumed.Finally,whenR suspendsexecutiontheexit partof R is assignedto Y.

In Figure13.5anexampleof acomponenthaving enter/exit partsis given.ThecomponentFactorial computesN! . A call of theform E -> Factorial-> F returnsE! in F. A subsequentcall Factorial -> F returns(E+1)! . Atany time a new enterparametermay be given. Factorial valuescomputedpreviouslyaresavedin atable,i.e.eachfactorialvalueis only computedonce.Factorial is anexampleof ageneratorthatcomputesa sequenceof values.

13.3 Components and recursive procedure pat-terns

The examplesso far have shown coroutinesthat only have a fixed numberof procedureobjects(items)aspart of their actions.Suchsimplecoroutinesmaybesimulatedusingsimplevariables,sincethereis only afinite setof sus-pensionpoints. If coroutinesarecombinedwith (recursive) procedurecalls,it is muchmorecomplicatedto simulatethestateof executionat suspensionpoints. In this section,examplesof combiningcoroutinesandrecursive pro-cedurepatternswill bepresented.

Theexamplein Figure13.6showsacomponentthatgeneratesthefactorialnumbers.For eachactivationof Factorial , thenext factorialnumberis gen-erated.This is doneby meansof a recursive procedurepattern,next .3 WhenFactorial hascomputedthenext number, it suspendsits executionandexitsthe number. For eachactivation, the componentstackwill grow with a newinstanceof next . In Figure13.7,theexecutionstackof factorial is shownwhenexecutionis at thelabelL.

The examplein Figure13.8 shows the power of combiningcomponentswith executionof recursiveprocedurepatterns.It is aclassicexampleof usingcoroutines.The programdescribesa merge of two binary searchtrees. TheattributeTraverse performsan in-ordertraversalof the tree: Traverse is a

3This is not themostcleverway of computingfactorial,but it illustratestheprinciple.


(# Factorial: @ | {a singular component}(# T: [100] @ Integer; N,Top: @ Integer;enter Ndo 1->Top->T[1];

Cycle(#do (if (Top<N) // True then

{Compute and save (Top+1)!...N!}(Top+1,N)->ForTo

(#do {T[inx-1]=(inx-1)! }T[inx-1]*i->T[inx]{T[inx]=inx!}

#);N->Top

if);N+1->N;{suspend and exit T[N-1]: }

SUSPEND;{When execution is resumed after SUSPEND,}{a new value may have been assigned}{to N through enter}

#)exit T[N-1]#);

F: @ Integerdo 4->Factorial->F; {F=4!}

{This execution of Factorial will result incomputation of 1!, 2!, 3! and 4!}

Factorial->F; {F=5!}{Here 5! was computed}

3->Factorial->F; {F=3!}{No new factorials were computed by this call}

#)

Figure 13.5 A generatorfor factorialnumbers.

componentthatwill suspendandexit theelementsin thenodesvisitedduringthe traversal. The main programstartsby executingTraverse for eachofthetreesb1 andb2. Thesmallestelementof b1 will thenbedeliveredin e1,andthesmallestelementof b2 will be deliveredin e2. The merge loop willthenprint thesmallestof thetwo elements;for example,if e1 is thesmallest,then e1 is printedand b1.Traverse will exit the next elementof b1. Thiscontinuesuntil therearenomoreelementsin thetwo trees.Figure13.9shows

13.4 ABSTRACT SUPER-PATTERNS 189

(# Factorial: @ |(# Next:

(# n: @integerenter ndo n*F -> F;

SUSPEND;n+1-> &Next

#);F: @ Integer

do 1->F-> &Nextexit F#);

v: @Integerdo Factorial->v; { v=1 }

Factorial->v; { v=2 }Factorial->v; { v=6 }L:Factorial->v; { v=24 }

#)

Figure13.6 Recursivegeneratorfor factorialnumbers.

Factorial Next Next Next

Figure 13.7 Recursivecomponentfor computingfactorial

an exampleof two binary searchtreesanda snapshotof theexecutionstate,takenimmediatelyaftertheattachof b2.Traverse . b1.Traverse is detachedat theleftmostnode(51) andb2.Traverse is resumedat thenodelabeled45.

13.4 Abstract super-patterns

A major designgoal for BETA hasbeento designa languagewith a smallnumberof basicbut generalprimitives. In addition,muchemphasishasbeenputinto thedesignof powerfulabstractionmechanisms,asin thiswayit is pos-


(# BinTree:(# Node: {The nodes of the binary tree}

(# elem: @ Integer;left,right: ˆ Node

#);root: ˆ Node;

Traverse: @ |(# next: @ Integer;

Scan:(# current: ˆ Nodeenter current[]do (if (Current[]=NONE) // False then

current.left[]->& Scan;current.elem->nex t;SUSPEND;current.right[]-> &Scan

if)#);do root[]->&Scan;

MaxInt->next; Cycle(#do SUSPEND#);{Exit maxInt hereafter}

exit next#); {Traverse}

#); {BinTree}b1,b2: @ Bintree; e1,e2: @ Integer

do ...b1.Traverse->e1; b2.Traverse->e2;Merge:

Cycle(# ...do (if (e1=MaxInt) and (e2=MaxInt)//True then leave Merge if);

(if (e1<e2) // True then e1->print; b1.Traverse->e1else e2->print; b2.Traverse->e2

if)#)...

#)

Figure13.8 Mergecomponents.

sibleto definemorespecializedconstructs.Object-orientedlanguagesprovidepowerful constructsfor definingpatternsthat describethe generalpropertiesof aclassof (partial)programexecutions.Often,suchpatternsareintendedtobeusedassuper-patternsof morespecializedpatterns,andit is not meaning-


76M

51N 86M

78 91N

81N

73O 96

45P 77Q

b1N b2R

b1.TraS verse ScaS n ScaS n

b1.TraS verse ScaS n ScaS n ScaS n

PT ’ MerU ge

Figure13.9 Illustrationof mergecomponents.

ful to createinstancesof thesepatterns.Patternsthatshouldonly beusedassuper-patternsarecalledabstractsuper-patterns.

In this section,examplesof definingabstractsuper-patternsin BETA willbegiven, includingmodelingof symmetriccoroutinesin thestyle of Simulaandtheillusion of concurrentprogramming.

13.4.1 Symmetric coroutines

Thecomponentsdescribedin theprevioussectionbehave likeso-calledsemi-coroutines. They are so called becausethereis an asymmetrybetweenthecalling coroutineandthecoroutinebeingcalled. Thecallerexplicitly namesthe coroutineto be called,whereasthe calledcoroutinereturnsto the callerby executingsuspend, which doesnot namethe caller explicitly. Thereisanotherkind of coroutine,calledasymmetriccoroutine, whichexplicitly callsthecoroutineto takeover. It doesnotreturnto thecallerby meansof suspend,giving a symmetricrelationbetweenthecoroutines.In this sectionit will beshown how to modelsymmetriccoroutines.

The SymmetricCoroutineSystem pattern of Figure 13.10 is an ab-stract super-pattern that describesthe generalpropertiesof a symmetric


SymmetricCoroutine Sys tem:(# SymmetricCoroutine:

(# Resume:<(#do this(SymmetricCorout in e)[ ]-> nex t[ ];

SUSPEND{suspend caller}#)

do INNER#)

Run: {start of initial SymmetricCoroutine }(#enter next[] {global reference declared below}do ScheduleLoop:

Cycle(# active: ˆ | SymmetricCoroutine

{currently operating component}do (if (next[]->active[])

// NONEthen leave ScheduleLoopif);NONE->next[];active; {attach next SymmetricCoroutine }{Active terminates when it executes either}{resume, or suspend or it terminates}

#)#);next: ˆ | SymmetricCoroutine;

{Next SymmetricCoroutin e to be resumed}do INNER#)

Figure13.10 A generalsymmetriccoroutinesystem.

coroutine system. The attribute SymmetricCoroutine of Symmetric-CoroutineSystem is an abstractsuper-patterndescribingthe propertiesof asymmetriccoroutine. It mustbe usedasa super-patternfor all componentsthatareto take part in thesymmetriccoroutinescheduling.TheRun attributeis intendedfor initiating thefirst SymmetricCoroutine . Run maybeviewedasaprimitivescheduler.

A SymmetricCoroutine is activeuntil it makesanexplicit transferof con-trol to anotherSymmetricCoroutine , doneby meansof theResumeattribute.NotethatResume is avirtual pattern,whichmeansthatit is possibleto extendthedefinitionof Resume in sub-patternsof SymmetricCoroutine .

TheResumepatternmakesuseof thepseudo-referencethis(Symmetric-


Coroutine)V , whichrefersto theenclosingSymmetricCoroutine object.As-sumethat A andB aredifferentinstancesof SymmetricCoroutine or oneofits sub-patterns.In A.Resume , this(SymmetricCoroutine) refersto A; inB.Resume , this(SymmetricCoroutine) refersto B. For any enclosingpat-ternP thereis apseudo-variablethis(P) .

A SymmetricCoroutineSystem terminateswhentheactive Symmetric-Coroutine terminatesexecutionwithout using resume . This may happeneitherby executingasuspendor by terminatingits actionpart.

In Figure13.11,anexampleof a programusingthe patternSymmetric-CoroutineSystem is given. The problemto be solved (Grune,1977) is tocopy charactersfrom input to output.Any occurrenceof astring WYXZX[W mustbeconvertedto W]\^W , andastring W]\_\`W mustbeconvertedto WYa[W (thelatterincludesW X W sconvertedto W \ W s). A string W Xb\caZXZXedZ\Z\cfZX_Xb\Zg W will thusbeconvertedintoW Xb\cab\ZdhaZfZabg W . TheConverter terminatesby meansof suspendwhena new-line character(nl ) is recognizedat theoutermostlevel of DoubleBtoC . Noticethat the descriptionof the Resume attribute hasbeenextendedto includeanenterparameterin DoubleBtoC .

13.4.2 Quasi-parallel systems

In this sectionit is shown how to simulateconcurrency by meansof co-routines. The exampleis inspiredby the Processmodulein (Wirth, 1982).In Figure 13.12, an abstractsuper-pattern for defining quasi-parallelse-quencing is presented. A QuasiParallelSystem defines an abstractsuper-pattern Process defining coroutines that may take part in the

quasi-parallelsequencing.A coroutinethat is to take part in the schedulingmustbe a specialization(sub-pattern)of the Process pattern. Instancesofsub-patternsof Process arehereaftercalledprocesses.

The ProcessQueue patterndefinesa queueof processes.All active pro-cessesareplacedin aninstanceof ProcessQueue calledActive . Eachtimeaprocesssuspendsexecution,a new processis selectedfrom this queue.

Communicationamongprocessesis synchronizedbymeansof signals(c.f.(Wirth, 1982)). A processmaysendandwait for (someotherprocesssending)asignal.In theexampleasignalis implementedasa ProcessQueue .

In Figure13.13,theclassicproducer/consumersystemis implementedasa quasi-parallelsystem. Patternsdescribingthe behavior of producersandconsumersaredefined.Producersandconsumerscommunicateby meansofthebuffer B andthesignalsnotFull andnotEmpty . A producercomponentP1 andaconsumercomponentC1 aredeclared.


Converter: @ | SymmetricCoroutineSy st em(# DoubleAtoB: @ | SymmetricCoroutine

(# ch: @ Chardo Cycle(#

do Keyboard.GetNonBlan k-> ch ;(if ch // ’a’ then

Keyboard.GetNonBla nk ->c h;(if ch // ’a’ then ’b’->DoubleBtoC.Re sume

else’a’->DoubleBtoC.Res ume;ch->DoubleBtoC.Resu me

if)else ch->DoubleBtoC.Resu me

if)#)#);DoubleBtoC: @ | SymmetricCoroutine

(# ch: @ Char;Resume::< (# enter ch #);

do Cycle(#do (if ch

// ’b’ thenDoubleAtoB.Resume;(if ch // ’b’ then ’c’->Screen.put

else’b’->Screen.put;ch->Screen.put

if)// nl then SUSPENDelse ch->Screen.put

if);DoubleAtoB.Resume

#)#)do DoubleAtoB[]->Run#)

Figure13.11 A SymmetricCoroutineSystem .

13.5 Exercises

(1) The Register pattern in Chapter6 has a ForAll pattern that scansthroughall elementsof theregister. Make a versionof Register wheretheForAll attributeis implementedasacomponent,andwhereeachcallR.ForAll returnsthenext elementof registerR.

13.5 EXERCISES 195

QuasiParallelSystem :(# ProcessQueue:

(# Insert: {Insert a process; insert of NONEhas no effect}...;

Next:{Exit and remove some process;

If the queue is empty, then NONEis returned} ...;Remove: {Remove a specific process} ...;

#);Active: @ ProcessQueue; {The active processes}Process: {General quasi-parallel processes}

(# Wait: {Make this(Process) wait for a send to S}(# S: ˆ ProcessQueueenter S[]do this(Process)[]->S .I nse rt;

this(Process)[]->A ct ive .Re move;SUSPEND

#);Send: {Activate a process from S}

(# S : ˆ ProcessQueueenter S[]do S.Next->Active.Ins er t;

SUSPEND#)

do INNER;this(Process)[]->Act ive .R emove

#); {Process}Run: {The scheduler}

(# Ap: ˆ | Process {Currently active Process}do ScheduleLoop:

Cycle(#do (if (Active.Next->Ap[])

// NONEthen leave ScheduleLoopif);Ap[]->Active.Inser t; {Ap is still active}Ap; {Attach Ap}

#)#)do INNER#)

Figure13.12 A generalquasi-parallelsystem.


ProducerConsumer: @ | QuasiParallelSyste m(# B: @ Buffer;

notFull,notEmpty: @ ProcessQueue; {Signals}Producer: Process

(# Deposit:(# E: @ BufferElemententer Edo (if B.Full // True then notFull[]->Wait if);

E->B.put;notEmpty[]->Send

#)do INNER#);

Consumer: Process(# Fetch:

(# E: @ BufferElementdo (if B.Empty // True then notEmpty[]->Wait if);

B.Get->E;notFull[]->Send

exit E#);

do INNER#);

P1: @ | Producer(# ... E1->Deposit; ... #);C1: @ | Consumer(# ... Fetch->E1; ... #);

do P1[]->Active.Insert ; C1[]->Active.Insert;&Run

#)

Figure 13.13 A producer/consumersystem.

(2) Write a programthatgeneratesfibonaccinumbers.Theprogramshoulduseacomponent(coroutine)thatworksasagenerator.

Fibonaccinumbersaredefinedasfollows:

Fib(1) = 1Fib(2) = 1Fib(n) = Fib(n-1) + Fib(n-2)

(3) Define a quasi-parallel system where the processescommunicateby meansof synchronousmessagepassingusing procedurepatternsSendMessage andReceiveMessage .

13.6 NOTES 197

Leti

S andR bereferencesto processes,andlet M1andM2bereferencestomessages.ProcessS canexecute:

(R[],M1[])->SendMessage

meaningthatS wantsto sendthemessageM1to R. S cannotcontinueuntilR hasacceptedthemessage.ThishappenswhenR executes:

S[]->ReceiveMessage->M2[]

meaningthatR wantsto receive themessagefrom M2. R cannotcontinuebeforeamessageis readyfrom S.

(4) Modify theabovequasi-parallelsystemsuchthatthemessagepassingisasynchronous.This meansthata processexecutinga SendMessage cancontinueimmediately, i.e. it doesnot have to wait for the receiver toexecuteReceiveMessage .

13.6 Notes

The notion of coroutinesequencingwas proposedby (Conway, 1963). Si-mulawasoneof thefirst languagesto includecoroutinesfor supportingquasi-parallel sequencing. A majorapplicationareaof Simulais discreteeventsim-ulation.TheSimulation classof Simulaincludesabstractionsfor creatinganillusion of concurrency to beusedwhenmodelingconcurrentactions.

It is only recently that mechanismsfor supportingmultiple action se-quenceshave beenintroducedin languagessupportingobject-orientedpro-gramming. In Smalltalk it is, to a limited extent, possibleto model mul-tiple action sequencesby meansof the classesProcess, Semaphore andProcessScheduler .

In (Marlin, 1980) a distinction is made between two types of co-routine sequencing. The first, the implicit sequencingkind, only com-municatesvia first-in-first-out queues,and there is no explicit transferofcontrol betweenthe coroutines. Call-by-needparameters,lazy evalua-tion, streams(as in (ReesandClinger, 1986)) and the systemdescribedin(KahnandMacQueen,1977)areexamplesof this kind of coroutine.

For thesecondkind of coroutine,theexplicit sequencingkind, it is possibleto transfercontrolexplicitly from onecoroutineto another.

Only afew programminglanguageshavesupportfor explicit coroutinese-quencing.Simulais oneof thefew languagesthatoffersanadvanceddesign.Itintroducedthedistinctionbetweensemi-coroutinesandsymmetriccoroutines,a semi-coroutinebeingexecutedby meansof the new- or call-imperative; asubsequentdetachreturnscontrol to thecaller. Symmetriccoroutinesareal-waysexplicitly scheduledby meansof theresume-imperative.


Unfortunately, the details of coroutinesequencingin Simula are verycomplicated.Theproblemis to understandhow semi-coroutines,symmetriccoroutinesandprefixed blocksare integrated. This meansthat even experi-encedSimulaprogrammersmayhavedifficultiesin figuringoutwhatis goingon in aprogramusingcoroutines.Thedetailsof Simula’scoroutinessequenc-ing aredescribedin (Dahl etal., 1968).

A simplifiedversionof Simula’scoroutinemechanismhasbeenpresentedby (Dahl andHoare,1972). A formal descriptionof part of the coroutinemechanismhasbeenpresentedby (WangandDahl,1971).This formalizationhasbeenfurtherelaboratedin (LindstromandSoffa,1981). In (Wang,1982),it wasshown thatthesemanticsof Simula’s coroutinemechanismwasincon-sistent. The problemwas that deallocationof block instancescould not beperformedasstatedby the original languagedefinition. It is arguedthat thesimplemodelof (WangandDahl,1971)cannotcopewith full Simula.Wangpresentsa detailedanalysisof Simula’s coroutinemechanism,andgivescer-tain proposalsfor changes.Theseproposalshave sinceled to a changein thesemanticsof Simula(SwedishStandard,1987).

The diagramsusedfor illustrating the BETA coroutinemechanismmaybe viewed asan informal variantof the WangandDahl model. The modelis operational,andmaybeviewedasanabstractimplementation(in fact, thecurrentimplementationin BETA follows this modelvery closely). It maybearguedthata moreabstractandlessoperationalmodelshouldbeusedfor ex-plainingthesemantics.However, from anobject-orientedperspective, wherecoroutinesareviewedasmodelsof alternatingsequentialprocessesfrom therealworld, thismodelappearsquitenatural.

Explicit coroutinesequencingin theform of symmetriccoroutinesis alsopresentin Modula-2.Accordingto (Henry, 1987), thereareseveralproblemswith thedefinitionof thecoroutinemechanismin Modula-2.

For a further discussionof the history andmotivation for coroutinessee(Marlin, 1980) and(Horowitz, 1983).

Coroutinesin BETA aresimilar to semi-coroutinesin Simula.TheBETAconstructsaresimpler andmoregeneralthan thoseof Simula. In addition,BETA offers thepossibilityof includingparameterswhencalling coroutines.It hasbeenshown that theBETA constructsfor semi-coroutinesmaybeusedto defineasetof attributesthatmodelSimula’ssymmetriccoroutines.

The constructCycle(# do Imp’ #) is similar to a prefixed block in Si-mula, whereprefixed blocksplay a major role in quasi-parallelsequencing.This is not thecasein BETA.

The Simulation classof Simula is a classicalexampleof an abstractsuper-class. It introducesthe notionsof processesand event noticesalongwith a schedulingmechanism.Simulationprogramsmay thenbe expressedasspecializationsof theSimulation class.Theterm‘abstractsuper-pattern’(super-class)originatesfrom Smalltalk.In Eiffel, abstractsuper-classis called

13.6 NOTES 199

‘deferredjkj class.’More than20 yearsof experiencewith Simulahasdemonstratedthat the

coroutinemechanismis extremely useful, and since Simula is an object-orientedlanguage,coroutinesare certainly useful within an object-orientedframework. A major difference betweenSimula and Smalltalk is thatSmalltalkclassesdo not have a do-part. It should,however, be straightfor-ward to reinvent thedo-partof Smalltalkclasses,therebyallowing Smalltalkobjectsto beactivecoroutines.

Theexperiencewith Simula’s coroutinemechanismhasbeenthestartingpoint for BETA design.As mentionedabove,thedetailsof Simula’scoroutinemechanismarevery hardto understand,andinconsistenciesin thesemanticshave recentlybeendetected.However, in mostSimulaprogramstheseprob-lemsdo not show up. Anotherproblemwith Simula’s coroutinemechanismwastheinability to transferparameterswhencalling a coroutine.Thelack ofparametersmakesit clumsyto implementgeneratorsin Simula,sinceparam-etersmustbetransferredby meansof globalvariables.

In the designof BETA, an attempthasbeenmadeto include a simpleandgeneralcoroutinemechanismthat keepsthe advantagesof Simula. Thesimplemechanism,togetherwith apowerful abstractionmechanism,makesitpossibleto implementa wide varietyof sequencingschemes.Thesymmetriccoroutinesandquasi-parallelsystemsin Section13.4.1areexamplesof this.BETA addsnothing to the basicprinciplesof coroutinesequencingusedinSimula. However, the technicaldetailsof coroutinesequencingin BETA aremuch simpler than thoseof Simula. In addition, coroutinesin BETA mayhave parameters.This makesit easierto useBETA coroutinesasgenerators.Coroutine(component)calls appearlike procedurecalls (items) wherebyahighdegreeof uniformity betweenproceduresandcoroutinesis obtained.

Thearrival of Modula-2hasresultedin arenaissancefor coroutines.How-ever, coroutinesin Modula-2areconsideredlow-level facilitiesfor implement-ing concurrentprocesses.Accordingto (Henry, 1987)thishasimpliedthatthestatusof coroutinesin Modula-2is unclear. In BETA thecoroutinemechanismis awell integratedpartof thelanguage.

Icon(Griswold et al., 1981) is anexampleof alanguagethatsupportsgen-erators.


Chapter 14

Concurrency

Thesubjectof thischapteris theconcurrentexecutionof objects.In theprevi-ouschapter, we have describedhow to useobjectsof thecomponentkind fordescribingprogramsconsistingof severalexecutionstacks.It wasshown howto describeadeterministicalternationbetweencomponents.

Componentsmay also be executedconcurrently, i.e. two or more com-ponentsmay executetheir actionsat the sametime. A basicmechanismforstartingtheconcurrentexecutionof acomponentwill beintroduced.

Concurrentcomponentsmay interactin differentways: they may accessthe sameobjectsby, for example,executingprocedurepatternattributesoftheseobjects;or they may communicatedirectly by accessingattributesofeachother.

It is well known thattheconcurrentexecutionof objectsrequiresa mech-anismfor synchronizingtheaccessto sharedobjects,just asdirectcommuni-cationbetweenobjectsmayrequiresynchronization.ThebasicmechanisminBETA for synchronizationis calleda semaphore. Semaphoresare,however,only usefulfor verysimplesynchronizationproblems.Wethereforeintroducehigh-level abstractionsfor handlingmorecomplicatedsynchronizationprob-lems,includingmonitor for guaranteeingexclusive accessto anobject,andaso-calledrendezvousmechanismfor handlingdirectcommunicationbetweenobjects.1 All theconcurrency abstractionsbeingintroducedcanbedefinedbymeansof semaphores.For someof the abstractions,the completedefinitionwill begiven;for others,their semanticswill just bedefinedin English.

By meansof textualnesting(blockstructure)it is possibleto specifycom-poundsystems. A systemmayspecifyconcurrentor alternatingexecutionofoneor moreinternalobjects,andsuchacompoundsystemwill thenhavesev-eral ongoingactionsequences.Externalsystemsmay communicatedirectlywith theinternalsystemswithout synchronizingwith theenclosingsystem.

1TheMjølnerBETA Systemincludesa library of suchabstractions.

201

202 CONCURRENCY

14.1 Concurrent executionof components

Concurrentexecutionof acomponentmaybedescribedby meansof thefork-imperative:

S.fork

whereS is a referenceto a component.The meaningof S.fork is that exe-cutionof S will take placeconcurrentlywith theexecutionof thecomponentexecutingS.fork . Executionof S will continueuntil S executesa suspendor hasfinishedexecutionof its do-part. If S suspendsits executionby meansof an explicit suspend , it may be resumedby meansof a new S.fork . Thefork actionis in many wayssimilarto attachment,asdescribedin thepreviouschapter. Thedifferenceis thatexecutiontakesplaceconcurrently.

Thefollowing exampleincludesa bankaccountof a person(Joe)andtwocomponents,one correspondingto a bank agentdepositingmoney in Joe’saccount,andonerepresentingJoe.Joewill only bewithdrawing money fromtheaccount:

(# Account: (# ... #);JoesAccount: @Account;bankAgent: @ |

(#do cycle(#do ...; 500->JoesAccount.deposit; ... #)#);

Joe: @ |(# myPocket: @integerdo cycle

(#do ...;100->JoesAccount.Withdraw->myPock et; ...

#)#)

do ...bankAgent.fork;{start concurrent execution of bankAgent}Joe.fork; {start concurrent execution of Joe}

#)

From time to time, the bankAgent will depositDKK 500 in JoesAccount .Joe will similarly withdraw DKK 100fromhisaccount.Thefork imperativesdescribethatthebankAgent andJoe areexecutedconcurrently.

14.1.1 Simplesynchronization

The above exampleworks well as long as the bankAgent and Joe do notaccessJoesAccount at thesametime. Thereis, however, no guaranteethatthis will nothappen.Assumethat:

14.1 CONCURRENTEXECUTIONOFCOMPONENTS 203

500->JoesAccount.depositland:

100->JoesAccount.Withdraw->myPocket

areexecutedat the sametime. Assumethat the balance on the accountisDKK 800beforetheactionsareexecuted.Thefollowing sequenceof actionsmaythentakeplace:

{deposit:} compute balance + amount giving the value 1300{withdraw:} compute balance - amount giving the value 700{deposit:} store 1300 in balance{withdraw:} store 700 in balance

The final effect of the two actionswill be that balance endsup having thevalue700. This is, of course,wrong, since500 hasbeendepositedand100hasbeenwithdrawn. Thefinal valueof balance shouldthushavebeen1200.

This is a standardexampleof two concurrentobjectsaccessinga sharedobjector moregenerallya shared resource. In general,it is not possibletopredictanything aboutthe orderof executionof actionsmadeby concurrentobjects. The above exampleof a possiblesequenceis just one exampleofmany possibilities. The actualscenariodependson the underlyinghardwareusedfor implementingthe BETA processor. The valueof balance may becompletelyundefineddependingon how theunderlyinghardwarehandlessi-multaneousaccessto a memorylocation. It is thereforenecessaryto makesurethatat mostonecomponentaccessestheaccount objectat agiventime.

Semaphores

To handlesynchronization,we introducethe notion of a semaphore,2 whichmaybethoughtof asakind of signalingdevicesimilar to a traffic light. If thelight is greenyoumayproceed,but if thelight is redyoumustwait. Consideranintersectionbetweentwo roads:theintersectionmaybeconsideredasharedresourceof thevehicles.To avoid two or morevehiclesin the intersectionatthesametime, accessto thesharedresource(intersection)is controlledby atraffic light.

A semaphoreworks in the following way: it may be in two states,redandgreen.Whenanobjectwantsto accessa sharedresourcecontrolledby asemaphore,it checksits state:

m Check-in: If thestateis green,thestateis changedto redandtheobjectaccessestheresource.Whentheobjecthasfinishedaccessingtheresource,thestateis changedto green.2Webster:Semaphore: Anyapparatusfor signaling, asby lights,flags,etc.

204 CONCURRENCY

m Check-out: If the stateis red, the object waits until the statebecomesgreen.Thewaiting takesplacein a queuetogetherwith otherpossibleob-jectswaiting for accessto theresource.Whenthestatebecomesgreen,thefirst objectin thequeuemayexecutecheck-in,asdescribedabove.

BETA hasa predefinedpatternrepresentinga semaphore.An instanceofsemaphore hastwo operationsP andV,3 correspondingto check-inandcheck-out, respectively. Considerthefollowing example,describingtwo concurrentcomponentsA andB:

(# S: @semaphore;A: @ | (# do imp1; S.P; imp2; S.V; imp3 #);B: @ | (# do imp4; S.P; imp5; S.V; imp6 #);

do S.V; A.fork; B.fork#)

m ThecomponentA mayexecuteimp1 andimp3 concurrentlywith any actionexecutedby B.

m Similarly, B mayexecuteimp4 andimp6 concurrentlywith any actionexe-cutedby A.

m A andB cannotconcurrentlyexecuteimp2 andimp5 . This is ensuredby thesemaphoreS. If, for instance,A hasexecutedS.P , thenB will be delayedwhenexecutingS.P andit canonly continuewhenA hasexecutedS.V . Thesemanticsof a semaphoreis that two componentscannotat thesametimeexecuteanoperationon thesamesemaphoreobject.This meansthatA andB cannotexecuteS.P at thesametime.

Thesemaphoredescribedabovehastwo states,redandgreen,andis thereforecalleda ‘binary semaphore.’ The Semaphore patternin BETA is actuallyaso-calledgeneralizedsemaphore. Suchasemaphorehasanintegervalue:

m TheP operationdecrementsthevalueandaslongasit is positive,thecallingcomponentis not blocked. Whenthe valuebecomesnegative, the callingcomponentis delayed.

m TheV operationincrementsthevalue.As longasthevalueis lessthanone,awaitingcomponentis reactivated.

m If a semaphoreis initialized to a positive valuen, thenn componentsmaycheck-inwith the semaphorebeforesubsequentcomponentsare delayed.Initially, a semaphorehas the value zero, meaningthat it is closed. Asemaphoreis usuallyinitialized to thevalue1 usingtheV operation.3Semaphoreswere introducedby Dijkstra, who namedthe P operationafter the Dutch

word passeren, meaningto ‘pass’,andtheV operationaftervrygeven, theDutchword for ‘torelease’.

14.1 CONCURRENTEXECUTIONOFCOMPONENTS 205

Thesemaphore patternmaybedescribedasfollows:

Semaphore:(# P: (#

do (if (cnt-1->cnt)<0 // true then{delay calling component in Q} if)

#);V: (#

do (if (cnt+1->cnt)<1 // true then{reactivate a waiting component from Q} if)

#);Count:{returns no.of. processes waiting on this(Semaphore)}

(# V: @integerdo (if cnt<0 then -cnt->V if)exit V #);

cnt: @integer;Q: @Queue

#);

The stateof a semaphore is representedby an integer cnt and a queueQfor keepingtrack of delayedprocesses.Sincecnt andQ areaccessedfromboth theP andV operation,at mostoneof theseoperationsmaybeexecutedat a time, in otherwords,the executionof P andV mustbe indivisible. TheSemaphore is a pre-definedpatternof the BETA language,andis definedtohavethepropertythatexecutionof anoperationP or V is indivisible.Theabovedescriptionof Semaphore is thusnot how it is implementedin the MjølnerBETA System,sincethe above descriptiondoesnot handleindivisibility oftheP andV operations.

We may usea semaphoreto guaranteeexclusive accessto eachbankac-count,asshown in thefollowing revisedversionof theAccount pattern:

Account:(# mutex: @Semaphore; {semaphore controlling access}

balance: @integer;Deposit:

(# amount,bal: @integerenter amountdo mutex.P;

balance+amount->balance->bal;mutex.V

exit bal#);

Withdraw:

206 CONCURRENCY

(# amount,bal: @integerenter amountdo mutex.P;

balance-amount->balance->balmutex.V

exit bal#);

Init:< (#do mutex.V; {Initially open} INNER #)#)

Executionof the Deposit and Withdraw operationswill no longerbe ableto make simultaneousaccessto balance . It is, of course,possibleto accessbalance directly, but this is breakingtherulesof thegame.In Chapter17 itis shown how to protectattributeslike balance suchthat it is not possibletobreakthe‘rules’.

Semaphoreis a simple andprimitive mechanismfor obtainingsynchro-nization. In the above exampleit is relatively easyto be convincedthat thesynchronizationworkscorrectly. In a systemwith severalconcurrentobjectsandseveralsharedobjects,it maybedifficult to describesynchronizationbymeansof semaphores.Programsthatmake heavy useof semaphoresmaybedifficult to readandwrite. Instead,we shall introducea numberof abstractpatternsfor handlingmorecomplicatedforms of synchronizationandcom-munication.

14.2 Monitors

Theuseof semaphores,asin Account , is a commonway of definingobjectssharedby two or moreconcurrentcomponents.We shall thereforeintroduceanabstractionthatmakesit easierto definesuchobjects.Thefollowingpatterndescribesaso-calledmonitorpattern:

Monitor:(# mutex: @Semaphore;

Entry: (# do mutex.P; INNER; mutex.V #);Init:< (#do mutex.V; INNER #)

#)

A Monitor object hasa semaphoreattribute and a local procedurepattern,Entry , usedto define operations. The Account may be describedusingMonitor in thefollowing way:

Account: Monitor(# balance: @integer;

Deposit: Entry

14.2 MONITORS 207

(# amount,bal: @integerenter amountdo balance+amount->balance->balexit bal#);

Withdraw: Entry(# amount,bal: @integerenter amountdo balance-amount->balance->balexit bal#);

#)

In the following, a monitor meanssomesub-patternof Monitor . An entrypattern(or entry operation ) meansa sub-patternof Entry definedwithinsomemonitor. Monitor is oneexampleof ahigh-level concurrency abstractionthatcanbedefinedby meansof semaphores.

14.2.1 Monitor conditions

It mayhappenthata componentexecutinganentryoperationof a monitor isunableto continueexecutiondueto someconditionnot beingfulfilled. Con-sider, for instance,a boundedbuffer of characters.Sucha buffer maybe im-plementedasa monitorwith two operationsPut andGet : the Put operationcannotbeexecutedif thebuffer is full, andtheGet operationcannotbeexe-cutedif the buffer is empty. A sketchof sucha buffer monitor may look asfollows:

buffer: Monitor(# R: [100] @char; in,out: @integer;

Put: Entry(# ch: @charenter chdo {wait if buffer is full};

ch->R[in]; (in mod R.range)+1 ->in;#);

Get: Entry(# ch: @chardo {wait if buffer is empty}

R[(out mod R.range)+1->out]->ch;exit ch#);

#)

208 CONCURRENCY

Themeaningof a wait is that thecalling componentis delayeduntil thecon-dition becomestrue. TheMonitor patternis extendedwith anattributewaitfor this purpose:

Monitor:(# mutex: @Semaphore;

Entry: (# do mutex.P; INNER; mutex.V #);Wait:<

(# cond: @booleando ...; INNER;

(if cond//false then {wait} if)#);

Init:< (#do mutex.V; INNER #)#)

TheWait operationmustbeexecutedin thefollowing way:

wait(#do <some condition>->cond #)

where<some condition> is a booleanexpression. If a wait is executedwithin amonitorentry, thecallingcomponentwill bedelayeduntil thecondi-tion becomestrue. While the componentis delayed,monitor operationscanbeexecutedby othercomponents.A delayedcomponentwill beresumedpro-vided that the condition is true and that no other componentis executingamonitoroperation,i.e.exclusiveaccessto themonitoris still guaranteed.

Wemaynow givethecompleteversionof thebuffer pattern.Thecontentof thebuffer is:

R[out+1], R[out+2], ... R[in-1]

whereall theindexesaremoduloR.range . Thebuffer is full if in=out anditis emptyif in=(out+1) , againmoduloR.range .

(# buffer: @Monitor(# R: [100] @char; in,out: @integer;

full: (# exit in=out #);empty: (#exit (in = (out mod R.range)+1) #);Put: Entry

(# ch: @charenter chdo wait(#do (not full)->cond #);

ch->R[in]; (in mod R.range)+1 ->in;#);

get: Entry(# ch: @chardo wait(#do (not empty)->cond #);

14.3 DIRECT COMMUNICATION BETWEENCOMPONENTS 209

R[(out mod R.range)+1->out]->ch;exit ch#);

init::< (# do 1->in; R.range->out #)#);

prod: @ | (#do cycle(#do ...; ch->buffer.put; ... #)#);cons: @ | (#do cycle(#do ...; buffer.get->ch; ... #)#)

do buffer.init;prod.fork; cons.fork

#)

Monitorsandconditionsareusefulfor describingsimplecasesof sharedob-jects(by simplewe meana limited useof conditions). If the conditionsfordelayingacallingcomponentbecomecomplicated,themonitormaysimilarlybecomedifficult to programandread.

14.3 Dir ect communicationbetweencomponents

In theprevioussectionwehavedescribedamechanismfor concurrentcompo-nentsto communicatethroughsharedobjects.In many casesit appearsmorenaturalfor concurrentcomponentsto communicatedirectly insteadof usingsharedobjects.Considerthefollowing example:

(# S: @ | (# P: (# ... #) do ...; R.Q; ... #);R: @ | (# Q: (# ... #) do ...; S.P; ... #)

do S.fork; R.fork#)

Herethe concurrentcomponentsS andR call operationson eachother. Thestateof S may, however, notbemeaningfulwhenR executesP, andviceversa.In thefollowing sectionswewill introduceabstractionsfor makingit possibleto synchronizesuchcommunication.

14.3.1 Synchronizedcommunication betweencomponents

In this sectionwe will introducethenotion of synchronizedexecutionof ob-jects. A componentS mayrequestexecutionof anobjectattributeof a com-ponentR. ThecomponentR mustacceptthatthattherequestcanbefulfilled.

Synchronizedcommunicationis describedin an abstractpatternSystem .A System definesthenotionof a Port for controllingthecommunication.APort hasan Entry patternfor definingprocedurepatternscontrolledby theport; it alsohasanAccept operationfor signalingthatanoperationassociatedwith theport canbeexecuted.TheSystem hasthefollowing structure:

210 CONCURRENCY

System:(# Port:

(# mutex,m: @semaphore;Entry: (#do m.P; INNER; mutex.V #);accept: (#do m.V; mutex.P #)

#)do ... INNER; ...#)

Thefollowing objectillustratestwo communicatingsystems:

S: @ | System(# ...do ... E1->R.M->E2 ...#);

R: @ | System(# P: @Port;

M: P.Entry(# ... enter ... do ... exit ... #);...

do ...; P.accept; ...#)

ThesystemS mayexecutea request, which is a normalremoteprocedurecall:

E1->R.M->E2

SinceM is a sub-patternof a port entry, theexecutionof Mhasto beacceptedby R beforeit is executed.

For M to be accepted,R mustexecutean accept, which hasthe followingform:

P.accept

Thecommunicationis carriedout whenS is executingR.M andR is executingP.accept . Both S andR areblockeduntil thecommunicationtakesplace.Acommunicationhastheeffect thatS andR togetherexecutetheevaluation:

E1->M->E2

This takesplaceasfollows:

(1) WhenS executesE1->R.M->E2 , aninstanceof Mis createdandE1 is trans-ferredto theenterpartof this instance(sinceE1-> is optionalthereneednot be an assignmentto the enter-part). S is now readyto executethedo-partof theM-instance.


(2) Whenn

R executesP.accept , R hassignaledthat thedo-partof a instanceof a sub-patternof P.Entry may be executed.R will wait until suchanexecutionhastakenplace.

(3) WhenbothR andS areready, thedo-partof Mcanbeexecuted.

(4) Whenthe do-partof Mhasbeenexecuted,R will continueexecution. Inaddition,apossibleexit-part of Mis transferredto E2.

TheobjectS executingR.M is calledthesender, andtheobjectR having Masanattributeis calledthereceiver.

In the following example,two systemsProd andCons communicateviaa singleelementbuffer representedby a SingleBuf system.TheSingleBufsystemalternatesbetweenacceptinga Put anda Get :

(# SingleBuf: @ | System(# PutPort,GetPort: @Port;

bufCh: @char;Put: PutPort.entry

(# ch: @char enter ch do ch->bufCh #);Get: GetPort.entry

(# ch: @char do bufCh->ch exit ch #);do cycle(#do PutPort.accept; GetPort.accept #)#);

Prod: @ | System(#do cycle(#do ...; c->SingleBuf.put; ... #)#);

Cons: @ | System(#do cycle(#do ...; SingleBuf.get->c; ... #)#)

do Prod.fork; SingleBuf.fork; Cons.fork;#)

14.3.2 Ports controlling several operations

It is possibleto associatemorethanoneoperationwith a port, asillustratedin Figure14.1. TheMaster -systemtransmitsa sequenceof valuesto thetwoSlave -systems,andeachSlave -systemcomputesthesumof thevaluesbeingreceived.Eachvalueis receivedandaccumulatedby asynchronousexecutionof Add. A Slave objectcanbeusedaccordingto thefollowing protocol:

(1) TheClear operationmustbeusedto initiate a new sequenceof summa-tions.A Clear thusterminatesany ongoingsummation.

212 CONCURRENCY

(# Slave: System(# receive: @Port;

Clear: receive.entry(# do 0->sum #);Add: receive.entry

(# V: @integer enter V do sum+V->sum #);Result: receive.entry(# S: @integer do sum->S exit S #);sum: @integer;

do 0->Sum;Cycle(# do receive.accept #);

#);Slave1: @ | Slave;Slave2: @ | Slave;Master: @ | System

(# Pos,Neg: @integer; V: [100] @integer;do {Read values to V}

Slave1.Clear; Slave2.Clear;(for inx: V.Range repeat

(if True// V[inx] > 0 then V[inx]->Slave1.Ad d// V[inx] < 0 then V[inx]->Slave2.Ad d

if)for);Slave1.Result->Pos ;Slave2.Result->Neg ;

#)do Master.fork; Slave1.fork; Slave2.fork#)

Figure 14.1 Exampleof concurrentsystems.

(2) TheAdd operationaccumulatesanew value.

(3) TheResult operationreturnsthecurrentsum.

In theexample,positivenumbersaretransmittedto Slave1 andnegativenum-bersaretransmittedto Slave2 .

14.3.3 Restricted acceptance

An acceptoperationon a port signalsthat any object is allowed to executeanoperationassociatedwith theport. Sometimesit is desirableto restrictthepossibleobjectsthatareallowedto executea port operation.The restrictionmayspecifythatonespecificobjectis allowedto executea port operation,orit mayspecifythatinstancesof aspecificpatternareallowedto executeaport


operation.o Thesetwo typesof restrictionsaredescribedin the following twosections.

Object restriction

It is possibleto restrictthesenderof anoperationby declaringtheport asaninstanceof theObjectPort pattern.TheAccept operationof anObjectPorthasan enterparameterwhich is a referenceto the object that is allowed toexecuteaportoperation.Thesyntaxfor this is:

S: ˆ | T; {some component reference}P: @ObjectPort;F: P.Entry(# do ... #);...S[]->P.accept;

The examplein Figure14.2describesan abstractpatternfor handlingreser-vationsof somekind. The reservationsare supposedto be storedin someregister. The actualway this is done is supposedto be describedin sub-patternsof ReservationHandler . At most,onepersonata timeis allowedtomakereservations.An agentmakingareservationmustperformthefollowingsteps:

(1) Theregistermustbelockedby executingtheLock operation.

(2) Theagentmaythenperformoneor morereservationsusingReserve .

(3) Theagentterminatesthereservationsessionby executingClose .

Theexampleincludesasketchof ahandlerfor hotelreservations.ThesystemP describesascenarioof anagentmakingtwo hotelreservations.

Qualified restriction

The ObjectPort describedabove makesit possibleto ensurethat only onespecificsystemmayexecutea port operation.It is oftendesirableto specifythataportoperationmaybeexecutedby arestrictedsetof systems.By usingaport instantiatedfrom QualifiedPort , it is possibleto defineportoperationsthatmaybeexecutedby objectsqualifiedby aspecificpattern.Thesyntaxforthis is:

T: (# ... #); {some pattern}P: @QualifiedPort;F: P.Entry(# do ... #);...T##->P.accept;

214 CONCURRENCY

ReservationHandler : System(# start: @Port;

Lock: start.entry(# S: ˆ | Systementer Sdo S[]->sender[]; false->closed; INNER#);

sender: ˆ | System;request: @ObjectPort;Reserve:< request.Entry;Close:< request.Entry(# do true->closed; INNER #);closed: @boolean

do cycle(#do start.accept;

loop: cycle(#do sender[]->request .ac cep t;

(if closed//true then leave loop if)#)#)

#);HotelResHandler: @ | ReservationHandler

(# Reserve::<(# guestName: @text; noOfPersons,roomNo : @integerenter(GuestName,noO fPe rso ns)do ...exit roomNo#);

{Representation of register of hotel reservations}#);

P: @ | System(# rno1,rno2: @integerdo P[]->HotelResHandle r. Loc k;

(’Peter Olsen’,4)->HotelRes Handl er. Reserv e- >rn o1;(’Anne Nielsen’,1)->Hote lRe sHandler .Re ser ve ->r no2HotelResHandler.Clo se

#)

Figure14.2 Exampleusinga restrictedport.

Portoperationsassociatedwith P maynow beexecutedby anobjectwhich isaninstanceof T or asub-patternof T.

14.4 COMPOUNDSYSTEMS 215

(# Producer: (# ... #);Consumer: (# ... #);SingleBuf: @ | System

(# PutPort,GetPort: @QualifiedPort;bufCh: @char;Put: PutPort.entry(# ch: @char enter ch do ch->bufCh #);Get: GetPort.entry(# ch: @char do bufCh->ch exit ch #);

do cycle(#do Producer##->PutPort. ac cep t;

Consumer##->GetPort. ac cep t#)

#);Prod: @ | Producer

(#do cycle(#do ...; c->SingleBuf.put; ... #)#);

Cons: @ | Consumer(#do cycle(#do ...; SingleBuf.get->c; ... #)#)

do Prod.fork; SingleBuf.fork; Cons.fork#)

Figure 14.3 Singlebuffer usingaqualifiedport.

The examplein Figure 14.3 illustratesthe useof a qualified port. Thesingle buffer example is modified such that Put can only be executedbyProducer objectsandGet canonly beexecutedby Consumer objects.

14.4 Compound systems

Compositionis a fundamentalmeansfor organizingobjects.We have severalexamplesof defining an object as compositionsof other objectsusing partobjects,referencesandblock structure.We havealsoseenhow thedo-partofanobjectmaybecomposedof otherobjects.In thissectionweshallshow howto constructcompoundsystemsthat aresystemobjectsconsistingof severalinternalmultipleactionsequences.

In BETA the actionsto be performedby a systemmay be distributedamongseveral internal systems.The internal systemsmay be more or lessindependent,andthey may accesscommondata(itemsin an enclosingsys-tem), communicatewith eachother, communicatewith externalsystemsor

216 CONCURRENCY

control communicationbetweenexternalsystems,andthe enclosingsystem.In thefollowing, examplesof suchcompoundsystemsaredescribed.

For compoundsystemsconsistingof several internalconcurrentsystems,we areoften interestedin describingthat executionof the outermostsystemcannotterminatebeforeexecutionof all inner systemshasterminated.Theoutermostsystemmayhave to do someinitialization beforeexecutingthein-ner systems,and it may have to do somefinalization (clean-up)when theyhave finishedexecution.TheSystem patternhasanattributeconc which canbeusedfor thispurpose.Conc canbeusedin thefollowing way:

S: @ | system(# S1: @ | system(# ... do ... #);

S2: @ | system(# ... do ... #);S3: @ | system(# ... do ... #);...

do ...;conc(#do S1.start; S2.start; S3.start #);...

#)

WhenS is executed,it will eventuallyexecutetheconc object,wherethedo-part describesthat concurrentexecutionof S1, S2 and S3 is initiated. Thedo-partof conc will thenwait for terminationof S1, S2 andS3. Whentheyhave terminated,executioncontinuesafterconc .

14.4.1 Indir ect communicationbetweeninternal systems

Theinternalsystemsof a compoundsystemmaycommunicateindirectly viaglobalobjectsin theenclosingsystem.Suchsharedobjectsshouldbedefinedasmonitorobjects.

The example in Figure 14.4 describesa histogram,representedby theHistogram system, which is an example of a compoundsystem. TheHistogram systemconsistsof two internalsystemsanda monitor, themon-itor representingthe datain the histogram. The Display systemconstantlydisplaysthehistogramon a screen.Thehistogrammaybechangedby meansof external requests.The Update systemhandlespossibleexternal requestsandupdatesthehistogramdata.

The Display andUpdate systemsneednot synchronizeasthe Displaysystem always displays the latest version of the histogram. SincehistogramData is representedasa monitor, theoperationson thehistogramdataareindivisible.

The Display systemreadsthe histogramby requestingexecutionof theglobal item Get . Similarly, theUpdate systemupdatesthehistogramdatabyexecutionof Add andSub. Note thatnewValue is anattributeof Histogram ,

14.4 COMPOUNDSYSTEMS 217

(# Histogram: @ | system(# histogramData: @monitor

{representation of the histogram}(# R: [100] @integer;

Add: entry (# i: @integer enter i do R[i]+1->R[i] #);Sub: entry

(# i: @integer enter i do (R[i]-1,0)->Min->R[ i] #);Get: entry(# i,V: @integer enter i do R[i]->V exit V #)

#);Display: @ | system

(# i: @integerdo cycle(#

do (i+1) mod 100->i;(i,i->histogramData. Get)- >Scree n. sho w

#)#);Update: @ | system(#do cycle(#do request.accept #) #);request: @Port;newValue: request.entry

(# V: @integerenter Vdo (if V>0 then V->histogramData.Add

else -V->histogramData.S ubif)

#)do conc(#do Display.start; Update.start #)#);

S: | system(#do cycle(#do ...; someValue->Histogr am.newValue #)do conc(#do Histogram.start; S.start #)#)

Figure 14.4 Exampleof compoundsystem.

but controlled by the internal Update system. S is some systemusingHistogram , andit communicateswith the Histogram systemindependentlyof its internalconcurrentbehavior.

14.4.2 Communication with internal systems

Fromoutsidea systemit is possibleto communicatedirectly with its internalsystemswithout synchronizingwith theenclosingsystem.The Pipe systemin Figure14.5consistsof threeinternalconcurrentsystems,DisAsm , SquashandAsm. A Pipe objectreceivesa sequenceof text lines, transformingsub-

218 CONCURRENCY

strings** into ˆ . Thenthe input lines areformattedinto lines consistingof80 characters.A blankis insertedbetweentheoriginal input lines.This job isdividedbetweentheinternalsystems:

m The DisAsm systemreceivesan input line andtransmitseachcharacterintheline to theSquash system.NotethattheDisAsm systemcontrolsaPortin anenclosingsystemobject.

m TheSquash systemreplacessubstrings** by ˆ andtransmitstheoutputtoAsm.

m TheAsmsystemformatsthecharactersequenceinto linesconsistingof 80characters.

The Prod systemtransmitsinput lines to the Pipe , andthe Cons systemre-ceiveslinesfrom thePipe . Fromtheseclientstheinternalconcurrentbehaviordoesnotaffect theuseof thePipe .

14.5 Readersand writers problem

A classicalsynchronizationproblemis theso-calledreadersandwritersprob-lem,which maybeformulatedin thefollowing way: anobjectis sharedby anumberof concurrentcomponents.Thecomponentsmaybedividedinto twoclasses,dependingon how they usethesharedobject:

Readers:A readercomponentwill only observe thestateof theobject.Sev-eralreadersmayaccesstheobjectat thesametime.

Writers: A writer componentwill modify the stateof the object. A writermusthaveexclusiveaccessto theobject.

As an exampleof a sharedobject,considera document.Several readersareallowedto extractpartsof thedocumentor print it. Severalwritersareallowedto modify the documentby insertingnew text or by deletingtext. However,eachsuchoperationmustbeindivisible. Thefollowing patterndefinesa doc-umentin theform of a monitor. TheoperationsInsert andDelete areusualentryoperations,i.e. they haveexclusiveaccessto themonitor. TheoperationsGetSub andPrint aredefinedassub-patternsof readerEntry , which is de-fined in monitor . ReaderEntry is a control patternfor definingoperationsthat canbe executedat the sametime. A readerEntry cannot,however, beexecutedat thesametimeasanentryoperation:

Document: monitor(# doc: @text

Insert: entry(# i,j: @integer; T: @text

14.5 READERSAND WRITERSPROBLEM 219

(# Prod: @ | System(#do cycle(#do getLine->Pipe.Put #)#);Pipe: @ | System

(# In: @Port;Put: In.Entry(# L: @text enter L do L->inLine #);inLine: @text;DisAsm: @ | System

(#do cycle(#

do In.accept;inLine.scan(#do ch->Squash.put #);’ ’->Squash.put

#)#);Squash: @ | System

(# P: @Port; ch: @char;Put: P.Entry(# c: @char enter c do c->ch #);

do cycle(#do P.accept;

(if ch // ’*’ thenP.accept;(if ch // ’*’ then ’ˆ’->Asm.put

else ’*’->asm.put; ch->asm.put if)else ch->Asm.put

if)#)#);Asm: @ | System

(# P: @Port; ch: @charPut: P.entry(# c: @char enter c do c->ch #);

do cycle(#do OutLine.clear;

(for i: 80 repeat P.accept; ch->OutLine.put for);Out.accept

#)#);Out: @port;Get: Out.Entry(# L: @text do OutLine->L exit L #)OutLine: @text

do conc(#do DisAsm.start; Squash.start; Asm.start #)#);

Cons: @ | System(#do cycle(#do Pipe.Get->putLine #)#)do conc(#do Prod.start; Pipe.start; Cons.start #)#)

Figure 14.5 Compoundsystemwith internalcommunicatingsystems.

220 CONCURRENCY

enter(i,j,T)do {insert T between pos. i and j in doc}#);

Delete: entry(# i,j: @integerenter(i,j)do {delete characters from pos. i to j in doc}#);

GetSub: readerEntry(# i,j: @integer; T: @textenter(i,j)do {get from doc substring i-j to T}exit T#);

Print: readerEntry(# P: ˆ printerenter P[]do {send document to printer P}#)

#)

ThereaderEntry maybedefinedasfollows:

Monitor:(# mutex,countMutex: @Semaphore;

rCount: @integer;entry: (# do mutex.P; INNER; mutex.V #);readerEntry:

(#do countMutex.P;

(if rCount+1->rCount // 1 then mutex.P if);countMutex.V;INNER;countMutex.P;(if rCount-1->rCount // 0 then mutex.V if);countMutex.V

#);...

#)

ThevariablerCount keepstrackof thenumberof concurrentreadoperationstaking placeat the sametime. When the first readoperationis started,themonitoris enteredbyexecutingmutex.P . Subsequentreadoperationscannowenterwithout beingblockedby mutex . An attemptto entervia entry cannottake placeas long asa readeris executing. Whenthe last readerleavesthe

14.6 EXERCISES 221

monitor, it is openedby executionof mutex.V . ThesemaphorecountMutexis usedfor guaranteeingexclusiveaccessto rCount .

The above definition of the monitor hasthe propertythatno readerwillwait unlessthesharedobjectis accessedby awriter, meaningthatareaderwillnothaveto wait justbecauseawriter is waiting for otherreadersto releasetheobject.An alternativewouldbeto definethemonitor in suchawaythatwhenawriter wantsaccess,it will getit asfastaspossible,i.e. possiblenew readerswill have to wait. This is left asanexercise.

14.6 Exercises

(1) Considerthemaster/slaveexample.A Slave objectcomputesa summa-tion of thevaluesreceived. Definea Slave patternthataccumulatesthecomputationof a binary function F. This shouldbe doneby defininganabstractpatternSlave that is parameterizedwith a function F, andanull elementnull . If theSlave receivesthevaluesv1,v2, ..., vn , itshouldcompute:

null->ac; (ac,v1)->F->ac; (ac,v2)->F->ac; ...;(ac,vn)->F->ac

(2) Make a completedefinitionof thewait attributeof theMonitor patternusingsemaphores.

(3) Makeacompletedefinitionof thepatternsPort , Entry andaccept usingsemaphores.

(4) Considerthehistogramexamplein Figure14.4.Whatconsequencesmayit have to definetheGet attributein thefollowing way?

Get: Entry(# i: @integer enter i exit R[i] #)

Discussthe problemsof referringto objectsin an enclosingmonitor orsystemfrom theenteror exit partsof anentryoperation.

(5) Definea monitorpatternthathandlesthereadersandwritersprobleminsucha way that a writer will get accessto the sharedobjectasquicklyaspossible. Possiblenew readersshouldthenwait until the writer hasfinished.

(6) Describein BETA a machinethat canmake coffee andsoup. The ma-chinehasthefollowing characteristics:

1. ThecustomercanpusheithermakeCoffee or makeSoup.

2. If makeCoffee hasbeenpushed,he/shecan take out the coffee.Similarly, if makeSoup hasbeenpushed.

222 CONCURRENCY

3. makeCoffee andmakeSoup cannotbe pushedagainuntil the cof-fee/souphasbeentakenout.

Next, extend the machineto be able to make tea also. The extendedmachineshouldbedescribedasasub-patternof thecoffeeandsoupma-chine.

(7) Considera systemwith nestedinternal concurrentsystems,wheretheinternalsystemsmanipulatetheportsin theenclosingsystem:

S: @ | system(# p1: @port; p2: @port; p3:@port;

m1: p1.entry(# ... #); ...m2: p2.entry(# ... #); ...m3: p3.entry(# ... #); ...

S1: | system(# ... do ... p1.accept; ... #);S2: | system

(# ... do ... p2.accept; ...; p3.accept; ... #)do conc(#do S1.start; S2.start #)#)

Discusswhich operationsa sendercan apply to S dependingon theaccept operationsexecutedby the inner systems.Will the operationsthatcanbeappliedto S bemutuallydisjoint or concurrent?Discusstheadvantagesanddisadvantagesof this.

(8) Thesystem /port patternsdescribedin thischapterarestaticin thesensethat a system canonly openoneport at a given time unlessthereareinternalsystem s.

Designand implementa new system /port wherea system can openmorethanoneport at thesametime.

Comparethis style of communicationwith thatusingnestedconcurrentsystemsfrom thepreviousexercise.

(9) ConsiderasystemA thatcanbein oneof threestates,state1 , state2 orstate3 . In eachstateoneor moreportsmaybeopen.Whencommunica-tion takesplace,A changesto anew statedependingonsomeconditions.If cond1 is true,thenext stateis state1 , if cond2 is true,thenext stateis state2 , andif cond3 is true, thenext stateis state3 . DescribeA inBETA.

Considera systemB, which is like A exceptthatstate1 consistsof twosubstatesstate11 andstate12 . SystemB changesto state11 if cond1and cond11 is trueandto statestate12 if cond1 and cond12 is true.DescribeB in BETA asasub-patternof A.

14.7 NOTES 223

14.7 Notes

It is outside the scope of this book to give a complete bibliog-raphy of concurrent programming. Important contributions to thiswork have been made by Dijkstra (Dijkstra,1968), Concurrent Pas-cal (Brinch-Hansen,1975) (and other work by Brinch-Hansen), CSP(Hoare,1978), andAda (USDepartmentof Defense,1980).

The semaphoreconceptwas introducedby Dijkstra in (Dijkstra,1968).The monitor conceptswere introducedin (Hoare, 1978; Brinch-Hansen,1975). TheBETA conc patternis similar to Dijkstra’s parbegin, parend,buttheconstituentpartsof aconc objectaresystems(asin CSP)andnotarbitraryimperatives.

Synchronizationbetweensystemobjectsis similar to the handshake inCSPor rendezvous in Ada. In CSP, both the senderpart and the receiverpart in a communicationmustbenamed.In Ada, only thesendermustnamethe receiver, whereasthe receiver acceptsall systems.The BETA approachincludesthesetwo extremesasspecialcases.

Few programminglanguagessupport compoundsystemsin a generalsense. In Ada, for example,it is possibleto specify compoundsystemsinthe form of nestedtasks.However, thecommunicationwith internaltasksislimited. It is notpossiblein Ada to call entryproceduresof internaltasksof atask.

The ideaof usingsemaphoresandabstractclassesandproceduresto de-fine higherlevel concurrency abstractionswasfirst proposedby JeanVaucherin (Vaucher, 1975), whereit wasshown how to defineamonitorabstraction.

Most concurrentprogramminglanguageshave built-in mechanismsforconcurrency, communicationand synchronization. The actualmechanismsdiffer from languageto language.Monitorsandrendezvousaretypical exam-ples. BETA hascurrentlyno built-in mechanismsexceptfor semaphoreandfork, becauseit is possibleto defineabstractpatternsfor many of the com-monlyusedhigh-level constructs.Experiencewith thisstrategy may, however,imply thatsomebuilt-in mechanismsshouldbeintroduced.

224 CONCURRENCY

Chapter 15

Nondeterministic Alter nation

In Chapter13 the notion of alternationwasintroduced.Alternationis a se-quencingform usedto describea systemthat executesseveral activities, butat mostoneat a time. As mentionedin the introductionto Chapter13, alter-nation is a usefulmechanismfor modelingagentsthat alternatesbetweenanumberof moreor lessindependentactivities. Alternationmayalsobeusedto structureaprogramusingcomponentswithoutexplicitly having to synchro-nizeaccessto commonobjects.This is in contrastto concurrency, which is asequencingform usedfor describinga systemthatexecutesseveralactivitiesat the sametime. In the concurrentsituation,accessto sharedobjectsmayhave to besynchronized.

Alternatingexecutionof componentsmay be usedto handlethe nonde-terminismof communicationin a systemof concurrentcomponents.A com-ponentinvolvedin communicationswith morethanonecomponentmaythenwait for oneor moreactsof communicationat thesametime.

In many situationsthe differentactsof communicationaremoreor lessindependent.AssumethatthesystemA communicateswith systemsB, C, DandE. Thenit maybethat theactsof communicationwith B andC areperformedin onesequenceandthe actsof communicationwith D andE areperformedin anothersequence,but thereis no sequencingbetweenthe two groupsofcommunication. In sucha situationit may be more naturalto describethecommunicationsequencesby meansof alternatingcomponents.In theaboveexample,systemA canbedescribedasa compoundsystemconsistingof twoalternatingcomponents,onefor communicationwith B andC andanotherforcommunicationwith D andE. In thenext sectionweshow how to describethissituationin BETA.

In Chapter13, deterministicalternation(coroutinesequencing)hasbeendescribed. In this chapterthe nondeterministicform of alternationwill bepresented.Nondeterministicalternationis only meaningfultogetherwith con-currency. A systemobjectexecutingconcurrentlywith othersystemsmaybeinvolvedin anumberof ongoingdialogswith someof theothersystems.Such

225

226 NONDETERMINISTICALTERNATION

a systemwill typically startan internalcomponent(coroutine)for eachsuchongoingdialog. Thesecomponentswill thenbeexecutedalternately, andtheschedulingwill benondeterministicdependingon whentheothersystemsarereadyto communicate.

The mechanismfor specifying alternationis not a primitive languagemechanism,but is definedasanattributeof theSystem pattern.

15.1 Alter nating executionof components

Thefollowing exampleshows a BETA programcontainingthreecomponentsC1, C2 andC3:

System(# C1: @ | System(# ... SUSPEND... #);

C2: @ | System(# ... SUSPEND... #);C3: @ | System(# ... SUSPEND... #)

do alt(# do C1.start; C2.start; C3.start #)#)

C1, C2 andC3 areobjectsof the componentkind. Componentsmay be exe-cutedalternatelyasspecifiedby theimperative:

alt(#do C1.start; C2.start; C3.start #)

Thealt patternis anattributeof System . Alternatingexecutionmeansthatatmostoneof thecomponentsis executingits actionpartata time. Thecompo-nentsnot executingactionsaredelayedat well definedpointsin their actionsequence.Thesepointsarethesameat which interleaving (i.e. shift of exe-cutionto anothercomponent)maytakeplace.Interleaving maytakeplace(1)at thebeginningof theaction-partof thecomponent,(2) whenthecomponentis attemptingto communicate(seebelow), and(3) whenthe componenthassuspendedits action-sequence.

As mentioned,interleaving may, for instance,take placewhenthe activecomponentsattemptto communicatewith anothercomponent.Communicateheremeansthat thecomponentattemptsto executeeitheran entryoperationor anaccept.

The situationmentionedat the beginningof this chapterwith a systemAperformingonecommunicationsequencewith B andC andanothersequencewith D andE maytakeplaceasfollows:

(1) The sequenceinvolving B andC may, for example,be asfollows: (a) Battemptsto executeanentryoperationA.putB , whichwill have to matchacorrespondingoperationPB.accept executedby A; (b) A will thenexe-cutesomeactionsI1 ; (c) A will thenattemptto executeanentryoperationC.putC ; (d) A will thenexecutesomeactionsI2 ; (e) This sequencemayberepeated.

15.1 ALTERNATING EXECUTIONOFCOMPONENTS 227

(# A: @ | system(# PB: @port; putB: PB.entry(#...#);

X1: @ | system(#do cycle(#do PB.accept; I1; C.putC; I2#);

PD: @port; putD: PD.entry(#...#);X2: @ | system

(#do cycle(#do PD.accept; J1; E.putE; J2#)

do alt(#do X1.start; X2.start #)#);

B: @ | system(#do ...; A.putB; ... #);C: @ | system

(# PC: @port; putC: PC.entry(#...#)do ...; PC.accept; ...#);

D: @ | system(#do ...; A.putD; ... #);E: @ | system

(# PE: @port; putD: PE.entry(#...#)do ...; PE.accept; ...#);

do conc(#do A.start; B.start; C.start; D.start; E.start #)#)

Figure15.1 A skecthof analternatingsystemA.

(2) A similarsequencemaybeperformedinvolving D andE.

Thisscenariois describedin Figure15.1.NotethatA hastwo internalcompo-nents,X1 andX2, eachexecutingoneof thesequencesmentionedabove. Thealt control-patternperformsanalternatingexecutionof X1 andX2, in whichcaseat mostoneof X1 andX2 is executingat thesametime.

ExecutionmayalternatebetweenX1 andX2 at thecommunicationpointsPB.accept; , C.getC , PD.accept andE.putE . For example,if X1 is execut-ingandit attemptstoexecutePB.accept , but B isnotreadyto executeA.putB ,thenX1 maybetemporarilysuspendedandX2 mayberesumed.

At somepoint,bothX1 andX2 maybedelayedwhile waitingfor communi-cationto take place:X1 maybewaiting at PB.accept andX2 maybewaitingat E.putE . TheX1 systemmayresumewhenB is readyto communicate,andX2 mayresumewhenE is readyto communicate.In this situation,A maybe


seenaswaiting for a communicationwith eitherB or C, andit communicateswith thefirst onewhich is ready.

ThesystemA maybecharacterizedasexecutingthefollowing interleavedsequencesof imperatives:

S1: PB.accept; I1; C.putC; I2; PB.accept; I1; C.getC; I2; ...

S2: PD.accept; J1; E.putE; J2; PD.accept; J1; E.putE; J2; ...

TheS1sequenceis generatedby X1 andtheS2sequenceis generatedby X2.The two sequencesareinterleaved at the communicationpointsPB.accept ,C.putC , PD.accept andE.putE . Thefollowing sequenceis oneexampleof apossibleinterleaving of S1andS2

PB.accept; I1; PD.accept; J1; E.putE; J2; C.putC; I2;PD.accept; J1; PB.accept; I1; C.putC; I2; E.putE; J2; ...

15.2 A distrib uted calendar

Considera distributedcalendarsystem. Eachpersonin an organizationhasa calendarobjectwhich keepstrack of dayswherethe personis engagedinmeetings.For simplicity, ameetingis alwaysoneday.

A personwhowantsto arrangeameetingfor agroupof peoplecanattemptto reserveameetingdatefor thisgroup.Thecalendarsystemthenchecksif therequesteddateis free,andcheckswith thecalendarsof thosepeopleinvolvedif thedaterequestedis free. If thedateis freefor all thoseinvolved,thedatewill bereserved.

While a calendarsystemis checkingwith the peopleinvolved in the re-questedmeeting,it mustbe ableto answerrequestsfor meetingsfrom othercalendarsystems.

In Figures15.2and15.3a Calendar patternis described.For simplicity,only Calendar objectsareassumed,i.e. no objectsrepresentingpersonsareincluded. This meansthat insteadof reservinga meetingdatefor a groupofpeople,a meetingis reservedfor agroupof Calendar objects.

TheownerHandler takescareof an initial reservation from theownerofthe calendar. The start -port representsa statewherethe ownerHandler isreadyto acceptthe reserve operationfor reservinga meeting.Theend -portrepresentsa statewherethe ownerHandler is readyto acceptthe confirmoperation,which informs the owner aboutwhetheror not the meetingcouldbereserved.

When a reserve -operationhas been executed, the procedurepatterncheckDate checkswhetherit is possibleto reserve a meetingfor that day.First, the day mustbe free for the owner of the calendar. If this is the case,thentheday is checkedwith all membersof thegroup. Eachgroupmember

15.2 A DISTRIBUTED CALENDAR 229

Calendar: system(# days: [365] @integer; {representation of the calendar dates}

ownerHandler: @ | system(# day: @integer; {date for initiated meeting}

group: ˆCalendars; {involved Calendars}start: @port;reserve: @start.entry

(# D: @day; G: ˆCalendarsenter(D,G[]) do D->day; G[]->Group[]#);

Ok: @boolean;checkGroup:

(#do (if days[day]//free then

tmpBooked->days[day ]; true->Ok;group.scan(#do (day->theCalendar.o the rsH andle r.r ese rv e)

and Ok->Ok#);group.scan(#do Ok->theCalendar.oth ers Handl er. con fir m#)(if Ok//true then booked->days[day]

else free->days[day]if)if)#);

end: @port;confirm: end.entry

(# ok: @boolean do Ok->ok exit ok #);do cycle(#do start.accept; checkGroup; end.accept#)#);

othersHandler: @ I system (# ... #)do alt(#do ownerHandler.start; othersHandler.start #)#)

Figure15.2 A distributedcalendar.

is temporarilyasked to reserve the day, returningtrue or falsedependingonwhetheror not they can.Finally, all membersof thegroupareinformedaboutwhetheror not thedayis actuallyreserved.

The othersHandler takescareof the requestsfrom othercalendarsys-


othersHandler: @ | system(# start: @port;

day: @integer;reserve: @start,entry

(# d: @integer;enter ddo (if (days[d->day]=free )-> ok

//true then tmpBooked->days[d ]if)

exit ok#);

end: @port;confirm: end.port

(# ok: @booleanenter okdo (if ok//true then booked->days[day]

else free->days[day]if)#);

do cycle(# start.accept; end.accept #)#)

Figure15.3 TheothersHandler of thedistributedcalendar.

tems. The reserve operationhandlesan initial reservation requestfrom an-othercalendar. It mayimmediatelyreturnfalseif thedayis not free,otherwiseit will makea temporaryreservation.Theconfirm operationeitherbooksthedayor freesthetemporaryreservation,dependingon theenterparameter.

The Calendars pattern will not be given in detail. It representsaset of Calendar objects. It has a scanoperationwith the index variabletheCalendar thatiteratesoverall membersof theset.

Theelementsof therepetitiondays mayhavethevaluesfree , tmpBookedor booked . Thesevaluesmaybeimplementedasintegervalues.

15.3 BOUNDEDBUFFER 231

(# Buffer: System(# S: [S.range] @char; in,out: @integer;

InPort,OutPort: @Port;Put: InPort.entry

(# ch: @charenter chdo ch->S[in]; (in mod S.range)+1->in#);

Get: OutPort.entry(# ch: @chardo S[(out mod S.range)+1->out]->chexit ch#);

PutHandler: @ | System(#do Cycle(#

do (if in // out then Pause {Buffer is full}else InPort.accept; {accept Put}

if)#)#);GetHandler: @ | System

(#do Cycle(#

do (if in // (out mod S.range +1))then {Buffer is empty}else OutPort.accept; {accept Put}

if)#)#)do 1->in; S.range->out;

alt(#do PutHandler.start; Gethandler.start #)#);

Prod: @ | System(# ... ch -> Buf.Put; ... #);Buf: @ | Buffer;Cons: @ | System(# ... Buf.Get->ch; ... #)

do conc(#do Prod.start; Buf.start; Cons.start #)#)

Figure 15.4 Boundedbuffer with alternatingcomponents.

15.3 Boundedbuffer

The examplein Figure15.4 describesa boundedbuffer implementedusingalternation. The internalcomponentsPutHandler andGetHandler controlcommunicationwith the Buffer -system; PutHandler takes care of a se-


ExtendedBuffer: Buffer(# GetRear: OutPort.entry

(# ch: @chardo S[(in+S.range-1) mod S.range -> in] -> chexit ch#);

#)

Figure15.5 Extendedbuffer.

quenceof Put -communications,and GetHandler takes careof a sequenceof Get -communications.

TheimperativePause specifiesthatthis is apoint whereinterleaving maytakeplace.Pause is not specifiedhere,but maybeimplementedasacommu-nicationwith somesystemin theenvironment,suchasa timer-system.

Sincethe executionof the PutHandler andGetHandler componentsisalternating,eachcomponenthasexclusiveaccessto thebuffer representation.Interleaving may only take placeat InPort.accept , OutPort.accept andPause .

In Figure 15.5 a sub-patternof Buffer is defined. A new operation,GetRear , for also taking elementsout from the rearof the buffer is added,showing that it is possibleto addoperationsto a port, andtherebyspecializetheprotocolof Buffer .

15.4 A simplegame

Considera very simple gamebetweena player anda ‘gameprocess.’ Thegameprocessis either in an even or an odd state. If the playerprobesthegameprocesswhenit is in anevenstate,theplayerlosesandthescoreis de-creasedby somevalue.If thegameprocessis in theoddstate,theplayerwinsandhis/herscoreis increasedby somevalue. At random,the gameprocessmaychangestate,from evento oddor from oddto even.Also, thegamepro-cessmay changethe valueby which the scoreof the player is increasedordecreased.The changeof stateandincrementvalueis initiated by a demonprocess.The gameprocessis thusconstantlyinvolved in a communicationsequencewith theplayerandthedemonprocess.

A concurrentsystemrepresentinga game-system,demon-systemand aPlayer -systemis describedin Figures15.6 and 15.7. Figure 15.6 showstheoverall structureof theconcurrentsystem,includingdetailsof thedemon-systemand the player -system. The game systemconsistsof two internal

15.4 A SIMPLEGAME 233

system(# game: @ | system

(# odd: (#exit 1 #); even: (#exit 0 #);state,score,inc: @integer;playerHandler: @ | system(# ... #);demonHandler: @ | system(# ... #);

do alt(#do playerHandler.start; demonHandler.start #)#);

demon: @ | system(#do cycle

(# score: @integerdo game.demonHandler.b ump; random->pause;

(if random mod 2 // 1 thengame.demonHandler. cha ngeIn c-> sco re ;(if score<100//true then

1->game.demonHandle r.s etI ncelse 10->game.demonHan dle r.s etI nc

if)if)#)#);player: @ | system

(#do game.playerHandler. sta rtG ame; ...

game.playerHandler. pro be; ...game.PlayerHandler. endGame

#)do conc(#do game.start; demon.start; player.start #)#)

Figure 15.6 Overall structureof simplegamesystem.

alternatingsystems,playerHandler anddemonHandler . Thedetailsof thesetwo systemsareshown in Figure15.7.

TheplayerHandler handlescommunicationwith theplayerandmaybein oneof threestates:start , playing andfinal . Eachstateis representedby a port . In a start state,the startGame operationwill be accepted;ina playing state,the probe and endGame operationswill be accepted;in afinal state,score will beaccepted.

ThedemonHandler maybe in two states,P1 andP2, alsorepresentedbyports. In stateP1, the bump andchangeInc operationsareaccepted;in stateP2, thesetInc operationwill beaccepted.


playerHandler: @ | system(# start: @port; {initial state: accepting StartGame}

startGame: start.entry(#do 0->score; false->stopped; even->state; 1->inc#);

playing: @port; {playing state: accepting Result, EndGame}probe: playing.entry

(#do (if state

// even then score-inc->score// odd then score+inc->score

if)#);

endGame: playing.entry(#do true->stop #);final: @port; {final state: accepting score}score: playing.entry(#do {display final value of score} #);stop: @boolean

do start.accept;play:

(#do playing.accept; (if stop//false then restart play if)#);

final.accept#);

demonHandler: @ | system(# P1: @port;

bump: P1.entry(#do (state+1) mod 2 -> state #);changeInc: P1.entry

(# v: @integer do score->v; true->newInc exit v #);P2: @port;setInc: P2.entry(# v: @integer enter v do v->inc #);newInc: @boolean

do cycle(#do P1.accept;

(if newInc//true then P2.accept; false->newInc if)#)

#);

Figure15.7 Detailsof playerHandler anddemonHandler .

15.5 NOTES 235

Thep demon is representedby a concurrentsystemthat performsa bumpoperationon the gameat irregular intervals (controlledby a randomnumbergenerator, not shown here). Sometimesthe demon informs the gamethat itwantsto changethevalue(inc ) usedto increment/decrementthescore.Theactualchangeof this valueis dependenton the currentscore(score ) of theplayer.

Theplayeris alsorepresentedbyaconcurrentsystemthatperformsvariousoperationson game.playerHandler .

15.5 Notes

A programdescribinga numberof concurrentprocesseswill usuallyinvolvenondeterminism.This is the casesincethe speedof independentprocessescannotbe predicted.Several different languagemechanismshave beenpro-posedto dealwith nondeterminism,including theguardedI/O commandsofCSP, which alsoappearin Ada. GuardedI/O commandsintroducenondeter-minism into a singlesequentialprocess.Alternatingexecutionmay be seenasanalternative to guardedcommands.Insteadof having nondeterminismineachsystemobject,thenondeterminismis describedasalternatingtheexecu-tion of componentobjects.

By usingalternationandcompoundobjectsinsteadof guardedcommands,logically independentactionsequencesaremixed into oneactionsequence.This may make the structureof the resultingprogrammore clear. In addi-tion, it simplifiesimplementation.A CSP-processandanAda-taskmayhaveseveralopenchannelsof communicationwaitingatonetime. Whenacommu-nicationtakesplaceit is possiblethatotheropenchannelsof communicationof the objectsinvolved mustbe closed. In BETA, eachobjectmay wait forat mostonecommunication.No openchannelof communicationneedsto beclosedwhena communicationtakesplace. Finally, in CSPandAda the useof input andoutput as guardsis not symmetric: it is only possibleto haveinput-commands(accept-statements)in a guardedcommand.Thepossibilityof allowingoutput-commandsasguardsin CSPis mentionedin (Hoare,1978).However, symmetricuseof input-/output-guardsgreatlycomplicatesthe im-plementation.

Technically, mostprogramsusingalternationcould be simulatedby pro-gramsusingconcurrency, but concurrency implies thateachsystemexecutesactionswith a positivespeed.On a singleprocessorthis impliestime sharingusinga clock. Someimplementationsof concurrency avoid this by shiftingto anotherprocessonly at a point of communication.If this is the case,theprogramactually consistsof alternatingcomponentsand not of concurrentsystems.In aconcurrentprogramno loopingsystemcanmonopolizethepro-cessor, whereasthis is thecasewith analternatingprogram.


Alternationis notanalternativeto concurrency, but asupplement.A num-berof activitiesare,by theirnature,alternatingandnondeterministic,andsuchactivitiesshouldnotbemodeledby concurrentsystems,coroutinesor guardedcommands.

Chapter 16

ExceptionHandling

A largepartof any softwaredesignis thehandlingof errorsituationsor raresituationsthat are unlikely to happen. Considerthe Register example inFigure5.2. A registercanhold up to 100 integers. If an attemptis madetoinsert more than 100 integersusing the Insert patternthereis a problem.At the point of the comment q Overflow r , somecodefor dealingwith thissituationmustbeinserted. For ‘small’ programsit is commonto print anerrormessageandterminatetheprogramexecution.Theusermustthenincreasetheconstant100,recompiletheprogramandexecuteit again.

For most non-trivial programsit is not satisfactory just to terminatetheprogramwith an error message.Considerthe situationwherethe register ispartof awordprocessorprogram.An errormessagesayingthatsomeinternalregisterhasoverflowedis in generalnot meaningfulto a userof sucha wordprocessor. Furthermore,theuserwill not beableto increaseconstantsof pos-sible tables. Anotherexampleis a flight reservation system.Sucha systemrunsovera very long periodof time,andit would not beacceptableif a tableoverflow simply resultedin anerrormessageanda subsequentterminationoftheprogram.

The programfragmentusing the Register patternmay of coursekeeptrack of how many elementsarestoredin a givenRegister objectandthentake somespecialactionif morethan100 elementsareto be inserted.Thismay, however, imply that the programis greatlycomplicatedwith codethattestsfor suchraresituations.The codefor the ‘normal’ situationsmay thenbe difficult to read. It would be desirableif the codefor handlingthe ‘rare’situationscouldbeseparatedfrom thecodehandlingthe‘normal’ situations.

Therearemany typesof errorsor exceptionalsituationswhich a programmay have to dealwith. An exceptionis a classof computationalstatesthatrequiresanextraordinarycomputation.It is notpossibleto givea precisedef-inition of whena computationalstateshouldbeclassifiedasanexceptionoc-currence; this is a decisionfor theprogrammer. In practice,mostpeoplehavea good feeling of what is the ‘main’ computationandwhat areexceptional

237

238 EXCEPTIONHANDLING

situations.Theexceptionalsituationsareall thosesituationswhich imply thatthe‘main’ computationfails. Thefollowing is a list of examplesof situationsthatareoftenconsideredexceptional:

Overflow of tables The exampledescribedabove with tableoverflow in aRegister objectis typical for a largenumberof situations.Most soft-warehasobjectswith finite tablesthatmayoverflow.

UndefinedresultsA procedureor functionmaynothaveawell definedresultfor all possibleinput parameters.Oneexampleof this is division byzero,andanotheris a procedurefor invertinga matrix. If thematrix issingular, thentheinverseis not well defined.

Incorr ect usageby the user A userusingaprogramor applicationin aner-roneousway is oneexampleof gettingundefinedresults.Giving wronginput to a programis a commonmistake madeby users. In somesit-uationsthis could be treatedasan exception,but in many situationsaprogramtaking complex input is equippedwith an input checker. Acompiler is an exampleof this. In othersituationsit shouldbe an ex-plicit partof theuserinterfacedesign.

Inconsistentdata Programsoftencommunicateby meansof files: onepro-gramwrites a file to be readby anotherprogram. The informationonthe file may thenbe written in a format agreeduponby theauthorsofthe two programs.The datafile couldbe inconsistentfor a numberofreasons:therecouldbeerrorsin thefirst program,someotherprogramcould have manipulatedthe file, by mistake someother file could beusedasinput to thesecondprogram,etc.

A documentsaved by a word processoroften hasspecialinformationusedby theword processor. It shouldbeableto handlepossibleincon-sistenciesin this file.

Operating systemerrors Considera word processor. Whena documentissaved, it maybe that thereis no moredisk space.Theusermay try toopena documentwhich cannotbe interpretedby the word processor.Theusermayattemptto modify a documentownedby anotheruser. Ifthewordprocessordoesnothandlesuchsituations,theoperatingsystemwill usuallyterminatetheword processorwith anerrormessagewhichmaynot bemeaningfulto theuser.

Languagedefinederrors Run-timeerrorssuchasindex errorsandattemptsto useNONEreferencesmayappearin evenwell testedprograms.Sincesuchsituationsappearbecauseof errorsin theprogram,it is in generaldifficult to recover from sucherrors. However, the programshouldatleastterminatewith aninformativemessage.

16.1 SIMPLEEXCEPTIONS 239

Numerics errors Computersonly supportnumberswith a finite amountofvalues.This meansthattheresultof anarithmeticoperationmayresultin a numberwhich cannotberepresentedby thehardware.Thiskind ofarithmeticoverflowis anexampleof anexception.

A programmust be able to dealwith exceptions. A gooddesignrule is tolist explicitly the situationsthat may causea programto breakdown. Manyprogramminglanguageshavespecialconstructsfor describingexceptionhan-dling. In BETA, exceptionhandlingis usuallydescribedby meansof virtualpatterns.Thepurposeof thischapteris to show how to usevirtual patternsforexceptionhandling.

Fromtheabove discussionanexceptionhandlingmechanismshouldpro-vide thefollowing support:

Meaningful error messagesAs aminimumit shouldbepossibleto providemeaningfulerrormessageswhenanexceptionoccurs.

Recovery The programusingan objectshouldbe provided with the possi-bility to recover from anexceptionraisedby theobject.Sometimestherecovery will be transparentin thesensethat the ‘normal’ control flowmaycontinue.In othersituationstherecoverymayimply a terminationor restartof partof thecomputation.

Separation of control flow The codefor dealingwith an exceptionshouldbeisolatedfrom thecodehandlingthe‘normal’ casesoasnot to disturbthe readability. Also an explicit indicationof possibleexceptionsmaybeausefulpropertyof a program.

In the following sections,a techniquefor using virtual patternsfor excep-tion handlingwill be presented.We startby introducinga simpleversionofexceptionpatternsandshow how thesemaybeusedfor overridingerrormes-sagesand for doing recovery from the exceptions(Sections16.1–16.3). InSection16.4thedifferencebetweenassociatingexceptionswith classpatternsandprocedurepatternsis described.Systemexceptionsandlanguage-definedexceptionsare describedin Sections16.5 and16.6, respectively. Finally, amoreadvanceddesignof exceptionpatternsis describedin Section16.7.

16.1 Simple exceptions

In this sectiona simple useof exceptionpatternsis shown. ConsidertheRegister pattern in Figure 16.1 (it is a slightly revised version of theRegister patternfrom Chapter5, Figure5.2). The Register patternis ex-tendedwith two exceptionpatterns.Overflow is invoked whenthe registeroverflows, and NotFound is invoked when an attemptis madeto deletea


key which is not in the register. Thesetwo exceptionsrepresenttwo differ-entclassesof exceptions:theOverflow exceptionis fatal in thesensethat itis probablynot meaningfulto continuetheprogram;theNotFound exceptionmayperhapsbeanerror. For many applicationsof Register it maynotbeanerror to attemptto remove anelementthat is not in theregister. Both excep-tion patternsaresub-patternsof the Exception pattern,which describesthegeneralpropertiesof exceptions.Exception will bedefinedbelow.

Consideranapplicationthathasaregisterof registrationnumbersof somekind. TheobjectRegistrations representsthis register. TheOverflow ex-ceptionis handledandtheapplicationterminates,but it overridesthedefaulterrormessagewith onethat is moremeaningfulfor the user. The NotFoundexceptionis not consideredfatal, but a messagedescribingthe event is dis-playedto the user. The executionof an Exception instancewill by defaultresultin terminationof theprogramunlessaContinue hasbeenexecuted.Ascanbeseen,anexplicit Continue is executedby NotFound :

Registrations: @Register(# Overflow::<

(#do ’Too many registration numbers.’->msg.append;

’Program terminates.’->msg.append#);

NotFound::<(#do ’Attempt to delete:’ ->PutText;

key->screen.putInt;’which is not in the register’->PutText;Continue

#)#)

16.1 SIMPLEEXCEPTIONS 241

Register:(# Table: [100] @integer; Top: @integer;

Init: (#do 0->Top #);Has: {Test if Key in Table[1:Top]}

(# Key: @integer; Result: @boolean;enter Keydo ...exit Result#);

Insert: {Insert New in Table}(# New: @integerenter Newdo (if (New->&Has) // False then {New is not in Table}

Top+1->Top;(if (Top<=Table.Range )

// True then New->Table[Top]else

Overflow {An Overflow exception is raised}if)if)#);

Remove: {Remove Key from Table}(# Key: @integerenter keydo (Search:

(for inx: Top repeat(if Table[inx] // Key then

{remove key}leave Search

if)for);key->NotFound; {A NotFound exception is raised}

:Search)#);Overflow:< Exception

(#do ’Register overflow’->msg.Appe nd; INNER #);NotFound:< Exception

(# key: @integerenter keydo key->msg.putInt;

’ is not in register’->msg.Appe nd;INNER

#);#)

Figure 16.1 PatternRegister with exceptionpatterns.


TheException patternmaybedefinedasfollows:

Exception:(# msg: @text;

cont: @boolean;Continue: (# do true->cont #);Terminate: (#do false->cont #)

do ’Program execution terminated due to exception’->msg;

INNER;(if cont//false then

msg->PutText;{Terminate program execution}

if)#);

The text objectmsg is supposedto hold a text to bedisplayedto theuserincasetheexceptionleadsto terminationof theprogram.Themsg text is givena default valuein the exceptionpattern. In sub-patternsof Exception , it ispossibleeitherto appendmoretext to themessageor overridethemessage.IntheRegister patternmoretext is appended.In theinstanceRegistrations ,themessageis overriddenin the Overflow pattern,whereasit is not usedinNotFound asthis exceptioncontinuesexecution.

The default actionof an exceptionis to terminateexecution,but this ter-minationmaybeavoidedby specifyingan explicit Continue . The rationalebehindthis is thatanexceptionis anerrorthatmustexplicitly bedealtwith bytheprogrammer.

In the above example, NotFound is not consideredto be an error forRegistrations . This will probably be the case for most instancesofRegister . Also, it may not even be necessaryto display a message,i.e.NotFound will be ignored. Eachsuchinstanceof Register must,however,explicitly call Continue for NotFound . It would be moreconvenientif theprogrammerdid not have to specifya handlerin thesecases.To do this, itmustbe specifiedwithin Register that the default for NotFound will be tocontinueexecution.This canbedoneby insertinga call to Continue withinthe descriptionof NotFound in Register . The call to Continue shouldbeinsertedbeforeinner , sincethesub-patternsof NotFound areableto overridethecontinueby executionof Terminate .

A virtual patterndealingwith anexceptionis calledanexceptionpattern,or justanexception. Theinvocationof anexceptionpatternis calledanexcep-tion occurrence. An exceptionis saidto beraisedwhenanexceptionpatternisinvoked. Theobject-descriptorassociatedwith anexceptionpatternis calledahandleror anexceptionhandler.

An exceptionpatterndefinedin apatternwill bethedefaulthandlerfor the

16.2 RECOVERY 243

exceptiono in thecasewherenofurtherbindingof it is made.A sub-patternmayextendthe default handlerby a further binding. A specificinstancehandlermaybeassociatedwith eachinstanceby instantiatinga singularobjectwith afurtherbindingof theexceptionpattern.

16.2 Recovery

Thehandlerassociatedwith Overflow in Registrations providesanew er-ror message,whereafterthe programexecutionis terminated. The handlercould insteadexecutea Continue , implying that the correspondingelementwould not be insertedin the table. Often thehandlermaybe ableto recoverfrom theexceptionandcontinuetheexecutionasif theexceptionhadnot ap-peared.In theregisterexampleit might bepossiblefor thehandlerto removesomeof the elementsfrom the table, move someelementsto anothertableor extendthesizeof the table. Whetheror not this is possiblewill of coursedependon theactualusageof theRegister .

In BETA it is actuallypossibleto extendthesizeof a repetition.An eval-uationof theform:

25->Table.extend

will extendTable by 25 elements.An overflow handlerfor Register couldthenbedefinedasfollows:

Register:(# Overflow:< Exception

(#do Continue;

INNER;(Table.range div 4)->Table.extend

#);Insert:

(# New: @integerenter Newdo (if (New->&Has) // false then

{New is not in Table}Top+1->Top(if (Top<=Table.Range)

//false then Overflowif);New->Table[Top]

if)#);...

#)


Thedefaulthandlerfor Register will executeaContinue andextendthesizeof Table by 25%. A furtherbindingof Overflow mayoverridetheeffect ofcontinue. Also notethe changein Insert : if control is returnedto Insertafter the executionof Overflow , it is assumedthat the exceptionalsituationhasbeenrepairedby thehandler, i.e. Insert maycontinue.

16.3 Partial recovery

Often it is not possibleto do the simple kind of recovery mentionedin theprecedingsection.It maybenecessaryto interruptthecontrolflow andescapeto anouterlevel in orderto do the recovery. To do this theremustbe a welldefinedcontrolpoint thatcanbeusedto breakthecurrentcomputation.Sucha controlpoint canbedefinedasa label,andthehandlermaythenexit to thislabelby meansof leave or restart , asillustratedin thenext example:

do ...L: (# R: @Register(# Overflow::<(#do ... leave L #)#)

do ... I->R.Insert; ...#);

...

In thecaseof anOverflow beingraisedby Insert , theexecutionof theobjectcontainingthedeclarationof R is terminated.This is adrasticwayof handlingthe exception,sincethe R register including all its elementsis abandoned.However, in many situationsit is abetteralternativethanterminatingtheentireprogramexecution.

In somesituationsthehandlermaybeableto make a partialrecovery andrestartthecomputationfrom somepoint. This would correspondto replacingleave with restart in theaboveexample.An exampleof thiskind of partialrecovery is givenbelow.

16.4 Handlers for procedurepatterns

Theabove exampleshave shown examplesof associatinghandlerswith classpatterns.Suchhandlerswill be thesamefor all activationsof procedurepat-ternsassociatedwith theobject,i.e. thecodemayhaveseveralinvocationsof,for example,Insert , andexceptionsraisedby all theseInsert swill havethesamehandler. In many situationsit would be desirableto associatedifferenthandlerswith thedifferentinvocations.This is possibleby defininganexcep-tion patternasanattributeof Insert . Considerthe following descriptionofRegister :

Register:

16.4 HANDLERSFORPROCEDUREPATTERNS 245

(# ...Insert: {Insert New in Table}

(# Overflow:< {Procedure level exception}Exception(# ... #);

New: @integerenter Newdo (if (New->&Has)

// false then {New is not in Table}Top+1->Top(if (Top<=Table.Range)

// false then Overflow if);New->Table[Top]

if)#);Overflow:<

Exception(# ... #); {Class level exception}#)

Handlersfor differentinvocationsof Insert maynow bedefinedasfollows:

(# R: @Register(# Overflow::<(# ... #); {Class handler for R} #)

do ...I->R.Insert

(# Overflow::<(# ... #); {Procedure handler} #)...J->R.Insert

(# Overflow::<(# ... #); {Procedure handler} #)...

#)

It mayappearthatthereis nousefor theclasshandlersinceonly theprocedurehandlersassociatedwith Insert will becalled.However, thelocal procedurehandlersmayinvoke theclasshandlerif they areunableto dealwith thesitu-ation:

I->R.Insert(# Overflow::<(#do ... R.Overflow #) #)

The situation where an exception handler invokes an enclosinghandler iscalledexceptionpropagation.

Sometimesit is desirableto automaticallypropagateanexception. In theabove exampletheremaybea mixtureof invocationsof Insert wheresomehavea localprocedurehandlerandothersdonot. For thosewhichdonothaveaprocedurehandlerit wouldbedesirablefor theexceptionto beautomaticallypropagatedto theclasshandler. This couldbespecifiedin thedeclarationoftheexceptionin Insert :


Register:(# Overflow:<(# ... #);

Insert:(# Overflow:< Exception

(#do INNER;

(if {no binding of Overflow} thenthis(Register).Overflow

if)#)

...#)

...#)

The ideais that if no bindinghasbeenmadeof Overflow in a possiblesub-patternof Insert , thenthe Overflow exceptionof the enclosingRegisterpatternis invoked.In Section16.7it is shownhow to implement‘no bindingof Overflow’ .

16.5 Systemexceptions

Any implementationof BETA, includingtheMjølnerBETA System,will pro-vide librariesof patternsandobjectsfor interfacingto theunderlyingoperat-ing system.A goodexampleof this is aFile patternfor interfacingto thefilesystemof thecomputer. A largenumberof errorconditionsmayappearwhenmanipulatingfiles. Below a simpleversionof a file1 patternis given,togetherwith possibleexceptionsthatmayberaised.

File:(# name: @text; {The logical name of the file}

Open:{General super-pattern for OpenRead and OpenWrite}(# OpenError: FileException

(#do ’Error during open.’->msg.append; INNER#);

NoSuchFile:< OpenError(#do ’No such file.’->msg.append; INNER

1This is a simplified version of the File patternimplementedby the Mjølner BETASystem.

16.5 SYSTEMEXCEPTIONS 247

#)enter namedo INNER#);

OpenRead: Open(# NoReadAcess:< OpenError

(#do ’No permission to read.’->msg.append;

INNER#)

do {open the file for read}{May raise NoSuchFile or NoReadAccess}

#);OpenWrite: Open

(# NoReadAccess:< OpenError(#do ’No permission to write.’->msg.append;

INNER#)

do {Open this(File) for write}{May raise NoSuchFile or NoReadAccess}

#);Get:

(# ch: @chardo {Get next char to ch}

{May raise EOFerror}exit ch#);

Put:(# ch: @charenter chdo {Write ch to file}

{May raise DiskFull}#);

Close: (# do {close the file} #);Remove: (# do {Remove the file from the disk} #);FileException: Exception

(#do ’Error in file:’->PutText; name->PutText;INNER

#);DiskFull:< FileException

(#do ’No more space on disk’->msg.append;INNER


#);EOFerror:< FileException

(#do ’Attempt to read past end-of-file’->msg.append;

INNER#)

#)

Thenormaluseof a File maybeasfollows:

(# F: @Filedo {Prompt user for file name}

N->F.openWrite;...ch->F.put;...F.close

#)

In the following example,handlersare definedfor someof the exceptions.When DiskFull is raised,the file is closedandremoved, and the programterminatesexecution. If the file cannotbe opened,or the userhasno writepermissionto thefile, theuseris askedto try again:

(# F: @File(# DiskFull::<

(#do ’Please remove some files from the disk’

->PutText;close; Remove; {Close and remove the file}

#)#)

do GetFileName:(#do {Prompt user for file name}

N->F.openWrite(# NoSuchFile::<

(#do ’File does not exist. Try again’

->PutText;Restart GetFileName

#);NoWritePermission::<

(#do ’You do not have write permission’

16.6 LANGUAGE-DEFINEDEXCEPTIONS 249

->PutText;’Try again’->PutText;restart getFileName

#)#)#);

...ch->F.put;...F.close

#)

16.6 Language-definedexceptions

Language-definedexceptionshave to be dealtwith by providing pre-definedpatternsin the environment. An implementationof BETA could provide apre-definedpattern,Program , that hasvirtual patternscorrespondingto allpre-definedlanguageexceptions.TheProgram patterncouldbedescribedasfollows:

Program:(# IndexError:< Exception

(#do ’Index out of range’->msg.append;

INNER#);

RefIsNone:< ...ArithmeticOverflow:< ...DivisionByZero:< ...

do INNER#)

A BETA programmaythenprovide handlersfor thelanguage-definedexcep-tionsasshown in thefollowing example:

Program(# IndexError::< (# ... #);

RefIsNone::< (# ... #);ArithmeticOverflow::< (# ... #);DivisionByZero::< (# ... #);...

do ...#)


TheaboveProgram provideshandlersfor all four kindsof exceptions.It is possibleto provide severallevelsof Program objectsin orderto have

differenthandlers,for example,for IndexError in differentpartsof thepro-gram.This is illustratedin thefollowing example:

Program(# IndexError::< (# ... #);

RefIsNone::< (# ... #);ArithmeticOverflow::< (# ... #);DivisionByZero::< (# ... #);...

do ...Program(# IndexError::< {alternative handler for index error}

(# .. #)do ...#)

#)

In the do-partof the outermostdescriptora new handlerfor index error isprovided.Thishandlerwill thenhandlepossibleindex errorsin theinnermostProgram object.

Theproblemwith this approachis thata handlermustbesuppliedfor allthelanguage-definedexceptions,sincethehandlersin theoutermostProgramobjectarenot automaticallyinvoked for exceptionsotherthan IndexError .In thenext section,amoreadvancedexceptionmechanismis provided,whichmakesit easierto propagateexceptionsfrom an inner Program object to anouterProgram object.

16.7 Advanceddesignof exceptionpatterns

In this section,a possibledesignfor a moreadvancedexceptionmechanismis presented.Thegoal is to defineanexceptionhandlingmechanismwith thefollowing properties:

m Bettersupportfor thepropagationof language-definedexceptionsthathavenohandlerto apossibleouterProgram object.

m It shouldbepossibleto specifyanotherterminationlevel asa default. ThesimpleException pattern(from theprevioussections)terminatestheentireprogramexecutionasadefault action.

m Whenan object level is terminated,it shouldbe possibleto specifysome‘clean-up’actionsto beexecutedbeforeterminationto ensuresmoothter-mination.

16.7 ADVANCED DESIGNOFEXCEPTIONPATTERNS 251

This ist achievedby combiningtheException patternwith theProgram pat-ternin thefollowing way:

Program:(# Exception:

(#msg: @text;cont: @boolean;Continue: (# do true->cont #);Terminate: (# do false->cont #)

do ’Program execution terminated due to exception’->msg;

INNER;(if cont//false then

(if outerMostProgram then msg->PutText if);CleanUp;leave Program

if)#);

CleanUp:<(#do INNER #);IndexError:< Exception

(#do (if {No binding} then

(if Outer[]<>NONE // True thenOuter.IndexError if)if)

’Index out of range’->msg.append;INNER

#);RefIsNone:< ...ArithmeticOverflow:< ...DivisionByZero:< ...Outer: ˆProgram;DefineOuter:<(#do INNER #)

do DefineOuter;INNER

#);

Theexceptionpatternsmaybeusedasfollows:

(# Main: Program(# IndexError::< (# ... #);

RefIsNone::< (# ... #);do ...

L0:Program


(# IndexError::< (# ... #){New handler for index error}

DefineOuter::<(#do Main[]->Outer[] #){Propagate other exceptions}{to handlers in Main}

CleanUp::<(#do {executed before termination}

{of this(Program)}#)

do ...L1:

(# Register: (# ... #)do L2:

(# Registrations: @Register(# Overflow::< (# do ... #);

NotFound::< (# do ... #)#)

do ...#);

...#);

...#)

#)do Main#)

Theoptionsfor thehandlersof Overflow andNotFound in Registrationsare:

(1) Do nothing: in this casethe exceptionwill imply a terminationof theenclosingProgram objectof theRegister definition,i.e. L0 will termi-nate.

(2) Explicit leave : the exceptionhandlermay explicitly specifya leave ofanarbitraryenclosinglevel (e.g.L2, L1, L0 or Main ).

(3) Explicit Restart : thehandlermayspecifya restartof anenclosinglevel(e.g.L2, L1, L0 or Main ).

(4) Explicit Continue : the handlermay executeContinue andtherebyre-sumeexecution.

The Program patternhasattributesfor supportingpropagationfrom inner toouterProgram objects.The Outer andDefineOuter attributesareusedforspecifyinga Program objectfor propagationof exceptionsthathave no han-dlers. Sub-patternsof Program canhave a further binding of DefineOuter

16.8 EXERCISES 253

for specifyingu an outer Program object. This mechanismassuresthat alllanguage-definedexceptionsexcept IndexError are propagatedto the out-ermostProgram object.

In someof the above examples,thereis a needto testwhetheror not avirtual patternhasactuallybeenboundin sub-patterns.This is possibleusingpatternvariables.Considerthefollowing example:

T: (# V:< D;D:

(#do ...

INNER;(if V## // D## then {No further binding} if)

#)#)

This is only possibleusing the above form of virtual specification. For theshorthandform:

V:< (# do ... INNER ... #)

it is not possible,sinceV## will refer to theactualbindingof V. This meansthatwehaveto modifysomeof theException patternsin theaboveexamples.It is possibleto imaginea moreexplicit supportin BETA for testingwhetheror not a virtual patternhasa furtherbinding. This maybe includedin futureversionsof BETA.

16.8 Exercises

(1) RedoExercise1 in Chapter11suchthatanexceptionis raisedwhenR isnot qualified by T.

(2) Modify theRegister in Figure16.1suchthatanexceptionis raisedif anattemptis madeto insertanelementalreadyin theregister. Whatshouldthedefault behavior of thisexceptionbe?

16.9 Notes

Thefoundationof exceptionhandlingis thepioneeringwork by J.B.Goode-nough(Goodenough,1975).Mostprocedurallanguageswith speciallanguagefacilities for exceptionhandlingaremoreor lessdirectly basedon this work(e.g. languageslikeClu andAda). Severalobject-orientedlanguageshave in-cludedspeciallanguagefacilitiesfor exceptionhandling(e.g.Smalltalk,EiffelandC++).


All thesefacilitiesemploy a dynamicapproachto finding thehandlersofa particularexception. This implies (with variations)that the handlerfor anexceptionis found by traversingthe call chainof procedureinvocationsandenclosedblocksbackwards,until ablockor aprocedureinvocationis foundinwhich a handlerfor theexceptionis defined.This dynamicapproachimpliestheseparatedefinitionof theexceptionandthehandler, andassociationof theexceptionwith the handlerbasedon the dynamicbehavior of the program.This implies that it is very difficult to tracetheexceptionalcomputation(thisworks somewhat like a seriesof computedGOTOs), and it is very difficultto ensurethat all exceptionoccurrenceswill eventuallybe handled(i.e. it isvery difficult to verify that a programwill respondsensiblyto all perceivedexceptionalconditions).2

This dynamic behavior (dynamic binding of handlersto exceptions)isoften in contrastto the host language(e.g. Ada and Clu) that usesstaticnamebinding (e.g. when binding procedureinvocationsto proceduredec-larations). This hasresultedin criticisms from several sources,e.g.C.A.R.Hoare(Hoare,1981) statesthat ‘ ... theobjectivesof languagesincluding re-liability, readability, formality andevensimplicity ... havebeensacrificed...by a plethora of features... manyof themunnecessaryandsomeof them,likeexceptionhandling, evendangerous.’

As an alternative to the dynamicapproachto exceptionhandling,a pro-posalhasbeenmadefor a static approachto exceptionhandlingby JørgenLindskov Knudsen(Knudsen,1984; Knudsen,1987)that is basedon the se-quel conceptproposedby (Tennent,1977). A sequelis a unificationof con-tinuationsandproceduresin thesensethatit is likea procedure,exceptthatitdoesnot returnto thepoint of its invocation,but insteadterminatestheblockin which it is defined. Whenusedfor exceptionhandling,this implies thata sequelin onedefinition definesan exception,its handlerandthe termina-tion level of the exception(i.e. the enclosingblock). The advantageof thisapproachis that thesequelconceptfollows thestaticbindingrule of thehostlanguageandat the sametime allows for efficient exceptionhandling. Thestaticapproachhasbeenfurtherdevelopedto incorporatesupportfor smoothtermination(i.e. allowing for clean-up,etc.,of blocksbeingterminatedduringanexceptional‘backtrack’)(Knudsen,1987).

The BETA approachto exceptionhandlingis inspiredby this staticap-proachto exceptionhandling.Therationalefor theconcretedesignhasbeento introducestaticexceptionhandlinginto BETA without introducingany newlanguageconstructs,but insteadutilizing thepowerfulabstractionmechanismsof the languageto constructan exceptionhandlingconcept.Exceptionhan-dling asdescribedin this chapteris merelya techniquefor usingvirtual pat-terns.

2It is importantto notethatexceptionhandlingin any programminglanguageis only ca-pableof handlingexceptionalconditionsthathavebeenperceivedduringprogramdesign.

Chapter 17

Modularization

In previouschapterswehave introducedlanguagemechanismsfor describingobjectsandpatternsof a BETA programexecution. In this chapter, languagemechanismsfor describingthephysicalorganizationof BETA programswillbe introduced. A non-trivial BETA programwill usually consistof severalpages,so it is desirableto be able to split sucha descriptioninto smaller,moremanageableunits. Suchunitsarein generalcalledmodules. A moduleis a convenientpart of a programtypically kept in a file (or in a database),manipulatedby aneditor, andtranslatedby acompiler.

Modularizationis of the utmostimportancewhenwriting programsthataremorethansmall examples.Sincethe examplesmustbe fairly small in abook like this, it is difficult to adequatelyillustrateandmotivatemodulariza-tion. The languageconstructswill be introducedusingvery small examplesto illustrate the principles. The modularizationtechniquesdescribedbeloware absolutelynecessaryfor large programsand highly recommendedevenfor moderatelysizedprograms.The reasonsfor this may be summarizedasfollows:

m Most reasonablysizedprogramscanbeconvenientlysplit into modulesoflogically relatedelements,sinceit is cumbersometo handlelargeprograms.Large programsareeasierto understandif split into a numberof smallerunits.

m Whenediting it is easierto managea numberof smallmodulesinsteadofonelargeprogram.

m Whenseveralpeopleareworkingonaproject,eachpersoncanwork onhisown setof modules.

m Modulescanbe saved in a library andsharedby severalprograms.Goodmodularizationmechanismswill thusimprovereusabilityof codeaswell asdesigns.

m It is goodpracticeto split amoduleinto interfacemodules(oftenreferredtoasspecificationmodules) and implementationmodules. An interfacemod-

255

256 MODULARIZATION

ule defineshow a modulecanbeused,andan implementationmodulede-scribeshow a moduleis implemented.This makes it possibleto preventusersof a modulefrom seeingdetailsaboutdatarepresentationandimple-mentationof algorithms.

m Certainmodulesmayexist in severalvariants. Oneexampleof this is dif-ferent implementationsof the same(interface)module. Anotherexampleis variantsof a modulecorrespondingto differentcomputers.If a modulehasseveral variantsit is importantthat the commonpart of two or morevariantsexists in only onecopy. It shouldonly be necessaryto separateout thecodethatdiffersbetweenvariants,otherwisemaintenancebecomesmorecomplicated,sincethesamechangemayhave to bemadefor severalvariants.

m A modulemaybeusedasaunit to beseparatelycompiled. Whenchangingpartsof a largeprogram,it is not acceptableto be forcedto recompilethewhole program,sincethis may take several hours. With separatecompi-lation of modules,only themodulesthathave beenchangedandthosethatareaffectedby thesechangeshaveto berecompiled.Below weexplainhowonemodulemaybeaffectedby changesin another.

In the following section,languageconstructsfor describingmodularizationareintroduced.Thereafter, wediscusshow to applytheselanguageconstructsandwhy they areusefulandnecessary.

17.1 Fragments

The languageconstructsfor describingprogrammodularizationarenot con-sideredpart of the BETA language.The reasonis that BETA is a languagefor describingobjectsandpatternsof a BETA programexecution, while themodularizationlanguageis for describingthephysicalorganizationof just theprogram. The structuringof the programexecutionin termsof objectsandpatternswill of coursealso be reflectedin the program,but in addition theprogramitself maybeorganizedin modulesthatdo have to follow thestruc-turing in termsof objectsandpatterns.The two languagesarethusintendedfor quite differentpurposes.Themodularizationlanguageis calledthe frag-mentlanguage, sinceit describestheorganizationof BETA programsin termsof fragments. (Thenotionof a fragmentwill beintroducedbelow.) Thefrag-mentlanguageis usedfor communicatingwith TheFragmentSystem, whichis thecomponentof theMjølner BETA Systemthathandlesstoringandma-nipulationof fragments.The termsfragmentlanguage and fragmentsystemareusedinterchangeablywhenthis causesnoconfusion.

Thefragmentlanguageis independentof BETA. Theprinciplesbehindthefragmentlanguagecanin factbeusedto describemodularizationof mostpro-gramminglanguages.Thefragmentlanguageis grammar-based. The ideais

17.1 FRAGMENTS 257

thatanv y correctsequenceof terminalandnonterminalsymbolsdefinedby thegrammaris alegalmodule.Thefragmentlanguagedescribeshow suchstringsmaybecombinedinto larger strings,andis presentedhereusinga graphicalsyntax,thoughthe fragmentlanguagealsohasa textual syntaxwhich is cur-rently usedby the Mjølner BETA System. A future versionof the MjølnerBETA Systemwill includesupportfor a graphicalsyntaxsuchasthatusedinthis book.1

17.1.1 Forms

TheBETA grammarin AppendixA hasthefollowing rule:

<ObjectDescriptor> ::= <PrefixOpt> <MainPart>

Thefollowing stringscanbederivedfrom thenonterminal<ObjectDescrip-tor> :

(1) (# T: @Text do ’Hello’->T #)

(2) (# P: <ObjectDescriptor>; R: ˆPdo (if <Evaluation> // true then &P[]->R[] if)#)

Thefirst stringconsistsonly of terminalsymbols.Thesecondstringhastwounexpandednonterminals,<ObjectDescriptor> and<Evaluation> . In Fig-ure 17.1,otherexamplesof stringsderived from nonterminalsof the BETAgrammarareshown.

A stringof terminalandnonterminalsymbolsderivedfrom a nonterminalA is called an A-form , or sometimesjust a form 2. The derived stringsinFigure 17.1 are all examplesof forms. Forms are the basicelementsusedto definemodulesin theMjølner BETA System.Thefragmentlanguagehaslanguageconstructsfor combiningforms into completeprograms.Consider,for example,the forms 3 and4 in Figure17.1. By substitutingthe DoPartnonterminalof form 3 by form 4 wegetthefollowing form:

Foo: (# a,b,c: @integerenter(a,b)do a*b->cexit c#)

The fragmentlanguageis a notationfor describinghow nonterminalsin oneform maybereplacedby otherforms.

1In additionto theuseof a graphicalsyntax,thefragmentlanguagedescribedin thisbookis slightly moregeneralthanthe actualimplementation.For details,seethe Mjølner BETASystemmanuals.

2In formal languagetheorythis is calleda sententialform.

258 MODULARIZATION

Nonterminal Examplesof derivedforms1. <Attributes> P: (# a,b: @integer #);

R: ˆP2. <AttributeDecl> X: @integer3. <PatternDecl> Foo: (# a,b,c: @integer

enter(a,b)<DoPart>exit c#)

4. <DoPart> do a*b->c5. <Imp> (if B//True then <Imp> if)6. (for <Index> repeat <IfImp> for)7. <IfImp> (if B//True then <Imp> if)8. <ForImp> (for <Index> repeat <IfImp> for)

Figure17.1 Nonterminalsandexamplesof correspondingderivedforms.

17.1.2 Slots

A form maycontainseveralnonterminalshaving thesamesyntacticcategory.This is thecasein thefollowing form:

Stack:(# Push: (# e: @integer enter e <DoPart> #);

Pop: (# e: @integer <DoPart> exit e #)#)

which hastwo <DoPart> nonterminals.In thefragmentlanguageit is neces-saryto beableto referseparatelyto eachnonterminal.Eachnonterminalmustthereforehaveanamewhichuniquelyidentifiesit.

In theMjølner BETA System,severaltoolsmanipulateforms,thusnot allnonterminalsarenecessarilyto beusedby thefragmentsystem.Thenontermi-nalsusedby thefragmentlanguagearecalledslotssincethey defineopeningswhereotherformsmaybeinserted.They aremarkedby thekeywordSLOT. Anonterminaldefiningaslot hasthesyntax:

<<SLOT T:A>>

whereT is thenameof theslot andA is thesyntacticcategory. Also notethatslotsareenclosedby << and>> insteadof < and>. This is donepurely fortechnicalreasons.A nonterminalmustbegin with a symbol(here<<), whichis not in the vocabulary of the language.Since< is usedas less than inBETA, it cannotbeusedto begin anonterminal.

Theabove form mayinsteadbedescribedasfollows:

17.1 FRAGMENTS 259

Stack:w(# Push: (# e: @integer enter e <<SLOT Push:DoPart>> #);

Pop: (# e: @integer <<SLOT Pop:DoPart>> exit e #)#)

Slot namesandBETA namesbelongto different languages,thusthereis nopossibility of confusingBETA namesandslot names.In the above examplethereis apatterncalledPush andaslotcalledPush . As weshallseelater, it isconventionalto useidenticalnamesin this manner.

17.1.3 Fragment-form

In the fragmentlanguage,eachform mustbe givena nameandits syntacticcategory specified.A fragment-formis a form associatedwith a nameandasyntacticcategoryhaving thefollowing syntax.As notedearlier, thesyntaxofthefragmentlanguageis mainly graphical:

F:Aff

F is the nameof the fragment-form,A is the syntacticcategory, and ff is aform, i.e. ff is astringof terminalandnonterminalsymbolsderivedfrom A.

Thefollowing is anexampleof a fragment-form:

Counter:PatternDeclCounter:

(# Up: (# n: @integer enter n <<SLOT Up:DoPart>> #);Down: (# n: @integer <<SLOT Down:DoPart>> exit n #)

#)

17.1.4 Fragment-group

Often it is convenientto definea setof logically relatedfragment-formsto-gether. For this purposeit is possibleto definea groupof fragments,calledafragment-group, whichhasthefollowing syntax:

260 MODULARIZATION

NAME ’F’

F1:A1ff1

F2:A2ff2

...

Fn:Anffn

thatdefinesafragment-groupwith thenameF consistingof n fragment-forms.Thenameof fragment-formi is Fi , its syntacticcategory is Ai andtheactualfragment-formis ffi .

Thefollowing is anexampleof a fragment-group:

Up:DoPartdo n+7->n

Down:DoPartdo n-5->n

Theterm fragmentrefersto eithera fragment-formor a fragment-group.

17.1.5 Fragment library

Thefragmentsystemhandlesthestoringof fragment-groupsin alibrary, calledthe fragmentlibrary. The fragmentlibrary is usuallyimplementedon top ofthe computer’s file systemor databasesystem. The fragmentlanguagehasconstructsfor describinghow to combinefragmentsinto compoundfragmentsandeventuallycompleteprograms.Thefragmentlanguagerefersto fragment-groupsstoredin the fragmentlibrary by meansof a fragmentname(or justname). TheMjølner BETA Systemassumesa hierarchicalnamestructureinthestyleof UNIX directoriesor Macintoshfolders3, asshown in Figure17.2.

In theMjølner BETA System,fragment-groupsarerepresentedasfiles insuchadirectory. Thenameof afragment-groupis givenby meansof aUNIX-pathenclosedin quotes(’ ). Thepath:

’/home/smith/CounterGroup’

denotesa file CounterGroup which is supposedto contain a fragment.CounterGroup residesin thedirectory/folder/home/smith . In thefollowingexamples,thenameof a fragment-groupwill oftenbegivenasshown below:

3Thereaderis assumedto havesomeknowledgeof suchhierarchicalfile systems.

17.1 FRAGMENTS 261

/

home lib

smith jones beta tex

betaenv editor

Figure17.2 Hierarchicaldirectorystructure.

NAME ’/home/smith/CounterGroup’

Counter:PatternDeclCounter:

(# Up: (# n: @integer enter n <<SLOT Up:DoPart>> #);Down: (# n: @integer <<SLOT Down:DoPart>> exit n #)

#)

For fragment-groupsconsistingof only one fragment-form,one shouldnot confusethe nameof the file/folder containingthe fragment-groupwiththe nameof the fragment-form. In the above example, CounterGroup isthefragment-group(andfile/folder) nameandCounter is thefragment-formname.Thefile/foldernameandthefragment-formnamemaybeidentical.

17.1.6 Origin of a fragment-group

The origin part of a fragment-groupspecifiesa fragment-groupthat is usedwhenbindingfragment-formsto slots.Considerthefollowing example:

NAME ’/home/smith/CounterBody’origin ’/home/smith/CounterGroup’

Up:DoPartdo n+7->n


262 MODULARIZATION

The origin of CounterBody is the fragment-group/home/smith/Counter-Group . The origin musthave free slotscorrespondingto Up andDown. Theorigin constructspecifiesthatthefragment-formsUp andDownaresubstitutedfor thecorrespondingslotsin CounterGroup . Theresultof thissubstitutionisa form, calledtheextentof thefragment,asdefinedbelow.

A fragmentdefinesa unique form, called the extent of the fragment.The extent of the above fragment is a combinationof CounterBody andCounterGroup . Thecombinationis obtainedby filling in theslotsin theori-gin with the correspondingfragment-forms.In theabove examplethis givesthefollowing form:

Counter:(# Up: (# n: @integer enter n do n+7->n #);

Down: (# n: @integer do n-5->n exit n #)#)

17.1.7 The basicenvir onment

TheMjølnerBETA Systemprovidesabasicenvironmentthatdefinesthemostimportantstandardpatternsandobjects.In addition,thisenvironmentinitiatesandterminatesthe executionof any BETA program. The basicBETA envi-ronmentis thefragmentbetaenv 4 shown in Figure17.3.As canbeseen,thisfragmentdefinesa numberof standardpatterns.In addition,thefragmenthastwo slots:PROGRAMandLIB .

A completeBETA programthatmakesuseof betaenv maybedefinedbydefiningthe PROGRAMslot. The following fragment-formis an exampleof averysimpleBETA program:

NAME ’mini1’origin ’betaenv’

PROGRAM:ObjectDescriptor(#do ’Hello world!’->PutLine#)

Theextentof thefragmentmini1 is thefollowing form:

{****** The basic BETA environment ******}(# ...

PutLine:...

4In the restof this chapter, simplenameswithout directorypathsareusedfor specifyingthenamesof fragment-groups.

17.1 FRAGMENTS 263

NAME ’betaenv’

betaenv:ObjectDescriptor

{****** The basic BETA environment ******}(# Put: (# ch: @char enter ch ... #);

PutInt: (# n: @integer enter n do ... #);PutText: (# T: @Text enter T do ...#);NewLine: (# ... #);PutLine: (# T:@Text enter T do T->putText; newLine #);Text: ...;File: ...;integer: (# ... #);char: (# ... #);... {Definition of other standard attributes}<<SLOT LIB: Attributes>>

do {Initialize for execution}<<SLOT PROGRAM:ObjectDescri pto r>> ;{Terminate execution}

#)

Figure 17.3 ThebasicBETA environment.

...do {Initialize for execution}

(#do ’Hello world!’->PutLine#){Terminate execution}

#)

As canbeseen,the PROGRAMfragmenthasbeensubstitutedfor the PROGRAMslot in betaenv . In the PROGRAMfragmentit is thereforepossibleto useanynamewhich is visible at thepoint of thePROGRAMslot in betaenv . PutLineis visibleat thePROGRAMslotandis thereforevisible in thePROGRAMfragment.It would alsohave beenpossibleto make useof patternslike integer , char ,Text , etc. In Section17.6weshallreturnto thequestionof visibility.

The LIB slot in betaenv is intendedfor makinga setof generalpatternsto be usedby otherprograms.The differencebetweensucha library andaprogramis thatthelibrary is a list of patternswhereastheprogramis a singleobject-descriptor. Thefollowing exampleis anexampleof a library consistingof two patterns:

264 MODULARIZATION

NAME ’mylib’origin ’betaenv’

LIB:attributesHello: (# do ’Hello’->PutText #);World: (# do ’World’->PutText #)

By substitutingthe LIB slot in betaenv with the LIB fragment-formweobtainthefollowing form:


Hello: (# do ’Hello’->PutText #);World: (# do ’World’->PutText #)

do {Initialize for execution}<<SLOT PROGRAM:ObjectDescriptor>>;{Terminate execution}

#)

As canbe seen,the library patternsareinsertedat the point of the LIB slot.Thismeansthatin theLIB fragment-formit is possibleto seeall namesvisibleat thepoint of theLIB slot in betaenv .

Note that the extent of mylib is not an executableprogram,since thePROGRAMslot hasnot beendefined. In the next sectionwe shall show howto makeuseof a library in aprogram.

17.1.8 Include

Whenmakinglibrarieslike mylib , we needa mechanismfor combiningsev-eral fragmentsinto onefragment.The include constructmakesthis possible.In the following examplewe have a programthat makes useof the myliblibrary:

NAME ’mini2’origin ’betaenv’include ’mylib’

PROGRAM:ObjectDescriptor(#do Hello; World; newLine#)

The effect of the include ’mylib’ is that the patternsdefinedin myLibcanbeusedin the PROGRAMfragment-form.Formally the fragment-formsof

17.1 FRAGMENTS 265

mylib x becomepartof thefragmentmini2 . In theabove examplemini2 maybeunderstoodasa fragment-groupconsistingof thefragment-formsin myliband the PROGRAMfragment-form. This implies that the extent of mini2 isobtainedby substitutingthe LIB slot in betaenv by the LIB fragment-formin mylib andby substitutingthe PROGRAMslot in betaenv by the PROGRAMfragment-formin mini2 . Thisgivesthefollowing form asa result:


Hello: (# do ’Hello’->PutText #);World: (# do ’World’->PutText #)

do {Initialize for execution}(#do Hello; World; newLine#){Terminate execution}

#)

Sincethepatternsin mylib areinsertedat thepoint of the LIB slot, they arevisible at thepoint of thePROGRAMslot. This is wherethePROGRAMfragment-form in mini2 is inserted,i.e. thepatternsHello andWorld arevisible insidethePROGRAMfragment-form.

A fragment-formmayhavemorethanoneinclude.This makesit possibleto useseverallibrary fragmentsin thesamefragment.

17.1.9 Body

Whendefining a fragmentit is often desirableto be able to specify oneormorefragmentsthatmustalwaysbeincludedwhenusingthefragment.Thisis oftenthecasewhena fragmentis separatedinto an interfacefragmentandoneor moreimplementationfragments.Herewe introducetheconstructforspecifyingthis, but delay further explanationuntil Section17.2. The bodyconstructspecifiesa fragmentthat is alwayspart of the extent. Considerthefollowing fragments:

NAME ’counter’origin ’betaenv’body ’counterbody’

LIB:Attrib utesCounter:

(# Up: (# n: @integer enter n <<SLOT Up:DoPart>> #);Down: (# n: @integer <<SLOT Down:DoPart>> exit n #);Private: @ <<SLOT Private:ObjectDescriptor>>

#)

266 MODULARIZATION

The counter fragmenthasa body specificationwhich specifiesthat a frag-ment called counterbody is always part of the extent of counter . Thecounterbody fragmentcouldbedescribedasfollows:

NAME ’counterbody’origin ’counter’

Up:DoPartdo n+7->n


Private:ObjectDescriptor(# V: @integer #)

Thecounter fragmentcouldbeusedby thefollowing fragment:

NAME ’mini3’origin ’betaenv’include ’counter’

PROGRAM:ObjectDescriptor(# C: @Counter; N: @integerdo 3->C.up; C.down->N#)

Theextentof mini3 is obtainedby combiningthePROGRAMfragment-formin mini3 , origin ’betaenv’ andinclude ’counter’. In additionthebody ’coun-terbody’ in counter impliesthat thecounterBody fragmentis alsoincludedin theextent.Theresultingform looksasfollows:


Counter:(# Up: (# n: @integer enter n do n+7->n #);

Down: (# n: @integer do n-5->n exit n #);Private: @(# V: @integer #)

#)do {Initialize for execution}

(# C: @Counter; N: @integerdo 3->C.up; C.down->N#);{Terminate execution}

#)

17.2 SEPARATION OFINTERFACE AND IMPLEMENTATION 267

As statedy earlier, thepatternsdefinedin LIB arevisible in mini3 throughtheuseof include. However, the counterbody is not visible from mini3 . Thismeansthatanevaluationlike:

C.private.V+1->C.private.V

is not possiblewithin mini3 . That is evenif theextentof mini3 includesthecounterbody fragment,it is not visible within mini3 .

Thedomainof a fragmentF is thatpartof theextentof F which is visiblewithin F. Thedomainof F consistsof thefragment-formsin F, plusthedomainof theorigin of F plusthedomainof possibleincludedfragments.

Thedomainof mini3 takesthefollowing form:


Counter:(# Up: (# n: @integer enter n <<SLOT Up:DoPart>> #);

Down: (# n: @integer<<SLOT Down:DoPart>>exit n#);Private: @ <<SLOT Private:ObjectDescriptor>>

#)do {Initialize for execution}

(# C: @Counter; N: @integerdo 3->C.up; C.down->N#);{Terminate execution}

#)

Thedomainof mini3 is constructedasfollows:

m Thedomainof mini3 consistsof thePROGRAMfragment-formin mini3 , thedomainof betaenv (its origin), plus the domainof the includedfragmentcounter .

m Thedomainof betaenv is theform in Figure17.3.m Thedomainof thecounter fragmentconsistsof theform definingthepat-

tern Counter , plus the domainof betaenv . Note that the body part ofCounter doesnot contributeto thedomain.

In Section17.6theconceptsof extentanddomainaredescribedfurther.

17.2 Separationof interface and implementation

Organizinga programasa collectionof fragments(modules)is oneway ofdealingwith thecomplexity of largeprograms.A largesystem,however, con-sistsof a largenumberof fragments.A fragmentmayusea numberof other

268 MODULARIZATION

fragments(via origin, includeor body),andbeitself usedby anumberof otherfragments.The resultmay in fact bea fairly complicatedstructure.For thisreasonit is necessaryto limit theinterconnectionsbetweenfragments.Further-more,knowledgeaboutthedetailsof a fragmentshouldbelimited wheneverpossible.

A fundamentaltechniquein thedesignof softwaresystemsis todistinguishbetweenthe interfaceand implementationof a module. The interfaceof amoduledescribesthe part of the modulewhich is visible from modulesthatuseit. This includesa descriptionof how to usethemoduleandis sometimescalledthe ‘outsideview’ of the module. The implementationof a moduleisthepartof themodulewhich is necessaryto realizeit on a computer. This issometimescalledthe‘inside’ view of themodule.

An importantissueis the notion of encapsulationor informationhiding.Encapsulationmeansthat accessto the implementationpart of a moduleisnot possiblefrom outsidethemodule,i.e. the implementationof a moduleishidden. This meansthat the usageof a modulecannotdependuponinternaldetailsof its implementation,andthusit is possibleto changethe implemen-tationof amodulewithoutaffectingits usage.

Encapsulationand separationof interfaceand implementationmay alsosavecompilationtime. In theMjølnerBETA System,asin mostothersystems,fragments(modules)canbeseparatelycompiled.A changein animplementa-tion modulecanthenbemadewithout recompilationof the interfacemoduleandmodulesusing the interfacemodule. This canyield significantsavingsin compilationtime. On theotherhand,a changein an interfacemoduleim-pliesthatall modulesusingit mustberecompiled.Thiscanbeextremelytimeconsuming,thereforewe recommendcarefullydesigningcritical interfacestoreducetheneedfor futurechanges.It is, however, not possibleto avoid suchchangessincetherequirementsfor aninterfaceusuallychangeover time.

Programmingtakesplaceat differentabstractionlevels.Theinterfacepartof amoduledescribesaview of objectsandpatternsmeaningfulat theabstrac-tion level wherethemoduleis used.Theimplementationlevel describeshowobjectsandpatternsat the interfacelevel arerealizedusingotherobjectsandpatterns.

To sumup, encapsulationandseparationof interfaceandimplementationhave thefollowing advantages:

m Theuserof amodulecanonly accessits interfaceandthuscannotmakeuseof implementationdetails.

m It is possibleto changetheimplementationwithout affectingtheusageof amodule.

m A changein animplementationmodulecanbemadewithout recompilationof theinterfacemoduleandmodulesusingtheinterfacemodule.


NAME ’textlib’origin ’betaenv’body ’ textlibbody’

LIB:attributesSpreadText:

{A blank is inserted between all chars in the text ’T’}(# T: @Textenter T<<SLOT SpreadText:DoPart> >exit T#);

BreakIntoLines:{’T’ refers to a Text which is to be split into a}{no. of lines. ’w’ is the width of the lines.}(# T: ˆText; w: @integerenter(T[],w)<<SLOT BreakIntoLines: DoPart>>#)

Figure17.4 Interfacefragmentof thesimpletext library.

Thefragmentlanguagesupportsencapsulationandseparationof interfaceandimplementation.One fragmentdefinesthe interfacewhile othersdefinetheimplementation.

Figure17.4shows the textlib fragmentwhich definesthe interfaceof alibrary text manipulatingpatterns.The library consistsof two patterns,eachhaving aslotasits do-part.Thisslotshouldbefilled with a<DoPart> definingtheimplementationof thepattern.The textlibbody fragmentin Figure17.5is theimplementationpartof thelibrary.

The body ’ textlibbody’ part of textlib specifiesthat the fragmenttextlibbody is automaticallyincludedin any fragmentusing textlib . Afragmentusing textlib will not be able to accessattributesdescribedintextlibbody . In other words; the extent of textlib includes textliband textlibbody , whereas the domain of textlib does not includetextlibbody . Figure17.6shows a program fragmentwhich makesuseoftextlib .

270 MODULARIZATION

NAME ’textlibbody’origin ’ textlib’

SpreadText: DoPartdo (# L: @integer

do (for i: (T.length->L)-1 repeat(’ ’,L-i+1)->T.InsertC h

for)#)

BreakIntoLines:DoPartdo T.scan

(# sepInx,i,l: @integer;do i+1->i; l+1->l;

(if (ch<=’ ’ )// true then i->sepInx if);(if l//w then

(nl,sepInx)->T.In xPut;i-sepInx->l

if)#);T.newline;

Figure 17.5 Implementationfragmentof thesimpletext library.

NAME ’libuser2’origin ’betaenv’include ’ textlib’

program:ObjectDescriptor(# T: @Text;do ’Here I am!’->SpreadText->P utL ine ;

’Once upon a time in the west ’->T;’a man came riding from east’->T.putText;(T[],10)->BreakInto Lin es;T->putText;

#)

Figure17.6 Thefragmentlibuser2 includestextlib .


NAME ’stack’origin ’betaenv’body ’arraystack’

LIB: AttributesStack:

(# Private: @ <<SLOT private: ObjectDescriptor>> ;Push: (# e: ˆText enter e[] <<SLOT Push: DoPart>> #);Pop: (# e: ˆText <<SLOT Pop: DoPart>> exit e[] #);New: (# <<SLOT New: DoPart>> #);isEmpty:

(# Result: @boolean<<SLOT isEmpty: DoPart>>exit Result#)

#)

Figure17.7 Theinterfacepartof theStack pattern.

17.2.1 Abstract data types

One of the fundamentalconceptsin programdevelopmentis the notion ofabstract data type. In the context of BETA, an abstractdatatype is a classpatternwhoseinstancesarecompletelycharacterizedby a setof (procedure)patternattributes– sometimesreferredto asits ‘operations.’ Theseoperationsconstitutethe outsideview of the objects,whereasreferenceattributesanddetailsof thepatternattributesbelongto theinsideview (theimplementation).

The fragmentsin Figures17.7and17.8show an exampleof an abstractdatatypein BETA. Thefragmentsdefinetheinterfaceandimplementationofastackof text references.A stackis completelycharacterizedby its operationsPush , Pop, NewandisEmpty . Thestack maybeusedasshown in Figure17.9

Sincethedomainof stack doesnot includeits implementation,thestackcanonly beusedby meansof its operations.It is goodpracticeto definemostclasspatternsas‘abstractdatatypes,’ i.e. restricttheir interfaceto bepatternoperations.In somelanguages(e.g.Smalltalk),classpatternsarealwaysab-stractdatatypes.

272 MODULARIZATION

NAME ’arraystack’origin ’stack’

private:ObjectDescriptor(# A: [100] ˆText; Top : @integer#)

Push:DoPartdo private.top+1->priv at e.t op;

e[]->private.A[priv at e.t op] []

Pop:DoPartdo private.A[private.t op][] ->e [];

private.top-1->priv at e.t op

new: DoPartdo 0->private.top

isEmpty:DoPartdo (0 = private.Top)->resul t

Figure 17.8 Theimplementationpartof Stack .


NAME ’libuser3’origin ’betaenv’include ’stack’

program:ObjectDescriptor

(# T: @Text; S: @Stackdo ’To be or not to be’->T; T.reset;

Get:cycle(# T1: ˆTextdo &Text[]->T1[]; T.getText-> T1;

(if T1.empty // True then leave Get if);T1[]->S.push

#);Print:

cycle(# T1: ˆTextdo (if S.isEmpty // true then leave Print if);

S.pop->T1[];T1->putText; ’ ’->put

#)#)

Figure17.9 A fragmentusingthestackinterface.

274 MODULARIZATION

NAME ’listStack’origin ’stack’

private:ObjectDescriptor(# head: êlm; elm: (# T:ˆText; next: êlm #)#)

Push:DoPartdo (# R: ˆprivate.elm

do &private.elm[]->R[ ]; private.head[]->R.n ext [];e[]->R.T[]; R[]->private.head [];

#)

Pop:DoPartdo private.head.T[]-> e[] ;

private.head.next[ ]-> pri vat e. head[] ;

new: DoPartdo NONE->private.head []

isEmpty:DoPartdo (NONE=private.head []) ->r esu lt ;

Figure17.10 List implementationof stack.

17.3 Alter native implementations

It is possibleto have several implementationsof a giveninterfacemodule.Ingeneral,this meansthatdifferentfragmentsmaydefinedifferentbindingsforslotsin agivenfragment.

Supposethatwe want to defineanalternateimplementationof thestackfrom the previous section. In the alternateimplementationstackobjectsarerepresentedasa linkedlist. Thelist implementationis shown in Figure17.10.

We have to remove thebodyspecificationof thestack fragment,sinceitforcesthearrayStack to alwaysbe includedaspartof theextentof stack .Instead,theuserof stack shouldhave a bodypartspecifyingtheappropriateimplementation.

17.3 ALTERNATIVE IMPLEMENTATIONS 275

Toz sumup:

m Thestack musthavenobody:

NAME ’stack’origin ’betaenv’

LIB: AttributesStack:

(# ...#)

m A userof thestackmusthave a bodyselectinganimplementation.Thefollowing fragmentmakesuseof thelist implementation:

NAME ’libuser4’origin ’betaenv’include ’stack’body ’ listStack’


(# T: @Text; S: @Stackdo ...#)

m Thefollowing fragmentmakesuseof thearrayimplementation:

NAME ’libuser5’origin ’betaenv’include ’stack’body ’arrayStack’



276 MODULARIZATION

Sometimesit is not desirableto selectthe implementationof thestackat thepointwhereit is used.Considerafragmentusingthestack withoutspecifyinganimplementation:




Thefragmentlibuser6 has,however, notbeencompletelyspecifiedsincethefreeslotsin stack have not beenbound.Thesimplestway of doingthis is tospecifya fragmentthatonly addsabodyspecification:

NAME ’libuser7’origin ’ libuser6’body ’arrayStack’

Thefragmentlibuser7 is a completeprogram.

17.4 Program variants

Often, several variantsof a given programareneeded,usually if variantsofa given programhave to exist for several computers.The main part of theprogramis oftenthesamefor eachcomputer. For maintenancepurposes,it ishighly desirableto haveonly oneversionof thecommonpart. In theMjølnerBETA Systemprogram,variantsarehandledin the sameway asalternativeimplementationsof a module,i.e. differentvariantsof a modulebind someoftheslotsdifferently.

As anexample,assumethattwo variantsof aprogramareneeded.Assumethat they vary with respectto the implementationof the stack pattern. Thefragmentin Figure17.11is like the libuser6 fragmentabove, exceptthat ithasbeenextendedwith aslot. Thisslot is supposedto print informationaboutthe variant. The fragmentin Figure17.12is an exampleof a variantof thelibuser8 fragment.A similarvariantmaybedefinedusingstackList .

17.4 PROGRAM VARIANTS 277



(# T: @Text; S: @Stackdo ’Program Hamlet. ’-> PutText;

<<SLOT hamlet:ObjectDesc rip tor >>;’To be or not to be’->T; T.reset;

Get:cycle(# T1: ˆTextdo &Text[]->T1[]; T.getText-> T1;

(if T1.empty // True then leave Get if);T1[]->S.push

#);Print:

cycle(# T1: ˆTextdo (if S.isEmpty // true then leave Print if);

S.pop->T1[]; T1->putText; ’ ’->put#)

#)

Figure17.11 The libuser8 fragment.

NAME ’libuser9’origin ’ libuser8’body ’ listStack’

hamlet:ObjectDescriptor

(#do ’Variant using list implementation of stack’->putLine;

#)

Figure17.12 The libuser9 fragment.

278 MODULARIZATION

NAME ’libuser10’origin ’betaenv’include ’mylib’include ’ textlib’


(# T: @Text;do Hello; World; newline;

’Here I am!’->SpreadText->P utL ine ;’Once upon a time in the west ’->T;’a man came riding from east’->T.putText;(T[],10)->BreakInto Lin es;T->putText;

#)

Figure17.13 Exampleof a fragmentincludingtwo otherfragments.

17.5 Usingseveral libraries

Theexamplesof librariesuntil now have only shown how to useonelibraryfrom aprogram.Thesyntacticcategory of aslot like SLOT LIB:attributesdescribesa list of declarations.It is thuspossibleto bind anarbitrarynumberof LIB fragmentsto sucha slot. Figure17.13shows a fragmentthat includestwo libraries.

17.6 Visibility and binding rules

We now summarizethe rulesfor binding slots,andgive a precisedefinitionof the extentanddomainof a fragment.A generalskeletonof a fragmentisshown in Figure17.14.Theorigin Gis optional,andtheremaybezeroor moreincludes.Thecasem { 0 meansthat thereareno includes.Similarly, k { 0correspondsto a fragmentwith no bodies.

Theorigin-chainof F is a list of fragments:

G, G1, G2, ... Gn

whereG is theorigin of F, G1 is theorigin of G, etc. The fragmentGn hasnoorigin. Usually, Gn will bethebasicenvironmentbetaenv . Theorigin-chainmustbefinite without duplicates.

Thefragment-formsin F areboundby searchingfor freeslotsin theoriginchain,startingwith G.

17.6 VISIBILITY AND BINDING RULES 279

NAME ’F’origin ’G’include ’A1’include ’A2’...include ’Am’body ’B1’body ’B2’...body ’Bk’

F1: S1ff1

F2: S2ff2

...

Fn: Snffn

Figure17.14 A generalfragment.

The fragment-dependencygraph of F hasa nodefor eachfragmentre-ferredto via origin, includeandbody. The dependency graphis constructedasfollows:

(1) A directededgeis madefr om F to its origin.

(2) A directededgeis madefr om F to eachfragmentit includes.

(3) Constructthedependency graphfor eachbodyfragmentF.

(4) Steps1-3 arerepeatedfor eachfragmentreferredby origin, includeandbody.

The dependency graphmustbe acyclic, i.e. thereshouldbe no loops. Thismeansthat a fragmentcannotinclude itself directly or indirectly via otherfragments.Thedependency graphfor fragmentlibuser9 of Figure17.12isshown in Figure17.15

The extent of F is the extent of its origin, the extent of all fragmentsin-cluded,plustheextentof all bodies,andfinally F itself. Thismaybedescribedusingthe following equation,wherewe rely on the reader’s intuition for thedefinitionof theoperator| :

280 MODULARIZATION

betaenv

Stack

listStack

libuser8

libUser9

Figure17.15 Dependency graphfor libuser9 .

Extent } F ~ { Extent } G~�|Extent } A1~�| Extent } A2~��4�5��| Extent } Am~�|Extent } B1~�| Extent } B2~��4�5��| Extent } Bk~�|ff1 | ff2 |��4�4��| ffn

Notetherecursivenatureof extent.Anything in theextentof theorigin is partof theextentof F, andsimilarly for includeandbody. Therecursionis finitesincethe dependency graphis acyclic. Eventually, therewill be a fragmentwithoutanorigin andfragmentswithout includeandbodyparts.

The domainof F hasa similar recursive definition. The domainof F in-cludesthe domainof the origin, the domainof all includedfragmentsandthefragmentitself. Thebodyfragmentsarenot includedin thedomain.Thefollowing equationdescribesthedomain:

Domain } F ~ { Domain } G~�|Domain } A1~�| Domain } A2~��4�4��| Domain } Am~| ff1 | ff2 |��4�4��| ffn

17.7 Exercises

(1) Define an interface fragmentand an implementationfragmentfor theRegister patternin Chapter9.

17.8 NOTES 281

(2) De�

velop an alternative implementationfor the Register patternwheretheelementsarestoredin a linkedlist.

(3) Redothe soda-andvendingmachineExercise2 in Chapter7 andsplittheprograminto interface-andimplementationfragments.

(4) Redothe banksystemExercise3 in Chapter7 by splitting the programinto interface-andimplementationfragments.

17.8 Notes

Thegrammar-basedprincipleusedto definetheMjølnerBETA FragmentSys-temwasoriginally proposedby (Kristensenet al., 1983a).

Thehandlingof modularizationdiffersfrom languageto language.Somelanguages,like the original versionof Pascal,have no mechanismsfor sup-portingmodularization.Otherlanguageslike Modula2 andAda have modu-larizationconstructsaspartof the language.In theselanguagesthe interfaceof the datatype hasbeentextually separatedfrom the implementation.In CandC++ amodulecorrespondsto afile.

In (DeRemerandKrohn,1976) the term ‘programmingin the large’ wasintroducedto characterizetheconstructionof largeandcomplex systems.Themainpoint madeby DeRemerandKrohn is thatstructuringa largecollectionof modulesto form asystem(programmingin thelarge)is essentiallyadiffer-entactivity from thatof constructingtheindividualmodules(programminginthesmall). They proposetheuseof differentlanguagesfor thetwo activities:amoduleinterconnectionlanguageshouldbeusedfor describingthemodularstructure,anda conventionalprogramminglanguageshouldbe usedfor de-scribingthecontentsof modules.They alsoproposeamoduleinterconnectionlanguagecalledMIL 75. TheBETA FragmentSystemis anexampleof suchamoduleinterconnectionlanguage.

282 MODULARIZATION

Chapter 18

ConceptualFramework

In Chapter2 a short introduction to the conceptualframework underlyingBETA was given. This chapterwill presenta more detaileddescriptionoftheframework. Wewill introduceconceptssuchasinformationprocessesandsystemsanddiscussabstraction,concepts,classificationandcomposition.Theframework providesa meansto beusedwhenmodelingphenomenaandcon-ceptsfrom the real world, it is thusa fundamentalbasisfor object-orientedanalysisanddesign.It is, however, alsoimportantfor implementation,sinceit providesameansfor structuringandunderstandingtheobjectsandpatternsgeneratedby aprogramexecution.Theapproachpresentedin thisbookis thatanalysis,designandimplementationareprogrammingor modelingactivities,but at differentabstractionlevels.

Object-orientationis also being appliedto databases.This book is notaboutdatabases,but the framework andBETA languagepresentedherearealsorelevantfor object-orienteddatabases.Datamodelingis thesameactivityfor databasesandprogramming.Thereare,of course,additionalaspectsofdatabaseswhich arenot coveredby this book. In (Atkinsonet al., 1990) thefollowing is mentioned:persistenceof objects;secondarystoragemanage-ment;recoveryandqueryfacilities.

In therestof this chaptera numberof definitionsof variousconceptsaregiven.Thedefinitionsaregivenin English,andit is in mostcasesnotpossibleto giveaprecisedefinition.Thelevel of precisenessis intendedto belike thatof a dictionary. Most of theconceptsbeingdefinedareexamplesof so-called‘prototypical’ concepts(seebelow). The examplesfollowing the definitionsarethereforeof greatimportancefor understandingtheconcepts.Despitethedifficulties in makingprecisedefinitions,the experienceis that the conceptsintroducedareuseful,but that somepracticalexperienceis necessarybeforea satisfactoryunderstandingof theconceptscanbeobtained.This experiencemaybeobtainedby usingBETA in practicalsystemdevelopmentprojects.

283

284 CONCEPTUAL FRAMEWORK

18.1 Physicalmodeling

The conceptualframework presentedhere reflectsa certainperspective onprogramming. It is deliberatelypresentedas one of many possibilities: inChapter2 otherperspectivessuchasproceduralprogramming,functionalpro-grammingand constraintprogrammingwere briefly mentioned. We defineperspectiveasfollows:

Definition 18.1 A perspective is themeansa personusesto structure her/histhinkingandunderstandingin relationto situationswithin somedomain.

Themeansdeterminethenatureof propertieswhich maybeconsideredim-portantfor a givensituation,andtherebyalsothenatureof propertiesthatareignored. Themeansalsoprovideconceptsandothermethodsof organizationto beusedin theinterpretationof theselectedandconsideredproperties.

For functional and constraintprogramming,the meansinclude mathemat-ics. For proceduralprogrammingthe meansinclude the conceptof a pro-grammablecalculator. In this chapter(someof) the meansof the object-orientedperspectivearepresented.

In Chapter2, theobject-orientedperspectiveonprogrammingwasdefinedasfollows:

Definition 18.2 A programexecutionis regardedas a physicalmodelsimu-lating thebehaviorof eithera realor imaginarypart of theworld.

Thekey word is ‘physical.’ The term ‘physicalmodel’ is usedto distinguishthesemodelsfrom, for instance,mathematicalmodels. Part of reality mayoftenbe describedusingmathematicalequations:Newton’s Laws arean ex-ampleof this. A physicalmodelis a modelconstructedfrom somephysicalmateriallike Lego bricks. Elementsof thephysicalmodelrepresentphenom-enafrom theapplicationdomain.Objectsarethecomputerizedmaterialusedto constructcomputerizedphysicalmodels.Objectsmaybeviewedasa kindof electronicLegobricks.

A collectionof thingswhich maybeusedto generatea setof phenomenamaybecalleda phenomenagenerator. If the phenomenageneratedarepro-cesses,thecollectionmaybecalleda processgenerator. Thesetof processesthatmightbegeneratedmaybecalledtheprocesssetof theprocessgenerator.

A collectionof Lego piecesis a phenomenagenerator. The phenomenageneratedwill usuallyberegardedasstatic,andabuilding setfor toy railroadsis a betterexampleof a processgenerator. With this verygeneraldescription,almostanything couldberegardedasa phenomenagenerator. In practicewewill of courseuseit in a muchmorerestrictedcontext – that of informaticsandof modelinganddesign.

A givenphenomena/processgeneratorputssomerestrictionsonwhichas-pectsof reality canbe modeled. In addition, it definesthe possibilitiesfor

18.1 PHYSICAL MODELING 285

obtainingv a physicalsimilarity betweenreality and the model. Most ‘Legohouses’would probablyhave somecommonlyacceptedphysicallikenesstohousespeoplelive in. A toy modelof a railway shuntingyard may be usedfor seriousanalysisof aspectsof the real yard’s operation,andthe physicalsimilarity is obvious. The building setmay, however, alsobe usedto modelcarsmoving on a road,but with a questionablerealism,sincefor example,acarrepresentedby atoy locomotivewill notbeableto passanothercar, repre-sentedby anotherlocomotive,exceptatpredeterminedlocationson the‘road’andusingrulesthatdo notcorrespondto passingon realroads.

An analogcomputer, consistingof capacitors,resistanceandotherelectriccomponents,mayof coursebeusedto modeltheelectricbehavior of acertainclassof circuitry – theprocesssetof theanalogcomputer. But it may(andhas)alsobe usedsuccessfullyto model the managementof water reservoirs in ahydroelectricpowersupplysystem.In thiscasethereis nophysicalsimilaritybetweenthereality andthemodel.

The definition of object-orientedprogrammingimplies that all programexecutionsaremodelsof someotherexisting systems.For new systemsthisalsoholds,even thoughthe existing systemin that caseis a systemexistingin the mind(s)of the programmer(s).The distinctionbetweena real or animaginarypartof theworld needsfurtherelaboration.

Let usconsidermodelingpartsof therealworld. Examplesof thisaresim-ulationprograms– a programsimulatinga railway systemis clearlya modelof partof therealworld. Thetrains,stations,passengers,etc.,involvedin thesimulationmay all be representedasobjectsin the programexecution. Thefirst object-orientedlanguage,Simula,wasin fact inventedwith the purposeof simulation.

Considernext a library. A library consistsof books,cardfiles andfilesfor the registrationof loans. Eachof the files consistsof a numberof cardsdescribingbooksor loans. A computersystemhandlingthesefiles may beconsideredasaphysicalmodelof thelibrary (whichis arealpartof theworld).Thecardsin thefiles maynaturallyberepresentedby objectsin theprogramexecution,etc. This is an exampleof how to make a physicalmodel of amanuallyoperatedadministrativesystem.

The creationof computersystemsof courseincludesa greatdealof in-vention. Theseinventionsmaybeimaginedasnew phenomenaandconceptswith a well definedrole in theproblemdomain.They will thensubsequentlyberealizedasobjectsandpatternsin theprogramexecution. Oftenit is alsoa matterof tasteas to whetheror not an object is a representationof somereal world phenomenonor a new kind of phenomenon.Is a patientrecordarepresentationof apatientor anew kind of object?

Therearealsoexamplesof computerizedmodelswhereinitially thesystemwasconceivedof asa modelof someexisting partof theworld. However, astimegoeson,theEDP-systemcompletelyreplacestheoriginalmanualsystem


problem specific concepts

abstraction

phenomena

Referent System

realized concepts

abstraction

objects

Model System

Modeling

ccc

Figure 18.1 Modeling.

andbecomespartof reality itself. An exampleof this is acomputersystemfororganizingsecuritieslikestocksandbonds.Whenconstructingsuchasystemit is naturalto representthesecuritiesasobjectsandall thetradingwith secu-ritiesarethenreplicatedin theEDP-system.In somecountries,likeDenmark,theobjectsbecomethesecuritiesthemselves,i.e. the ‘real stocksandbonds’aretheobjectsandnot thepaperrepresentations.Eventually, peoplewill for-getaboutpaper-basedsecuritiesandonly think of object-basedsecurities.

Referent and model systems

Therealor imaginarypartof theworld beingmodeledwill in thefollowing becalledthereferentsystem, andtheprogramexecutionconstitutingthephysicalmodelwill becalledthemodelsystem.1 Figure18.1 illustratestheprogram-ming processasamodelingprocessbetweena referentandamodelsystem.

Theprogrammingprocessinvolvesidentificationof relevantconceptsandphenomenain the referentsystemand representationof theseconceptsandphenomenain themodelsystem.Thisprocessconsistsof threesub-processes:abstractionin thereferentsystem;abstractionin themodelsystem;andmod-eling. Pleasenotethatintentionallywedonot imposeany orderingamongthesub-processes.Abstractionin thereferentsystemis theprocesswherewe are

1Laterin thischapteradefinitionof thetermsystemwill begiven.

18.2 INFORMATION PROCESSES 287

percei� ving andstructuringknowledgeaboutphenomenaandconceptsin thereferentsystemwith particularemphasison theproblemdomainin question.We saythatwe arecreatingproblem-specificconceptsin thereferentsystem.Abstractionin themodelsystemis theprocesswherewe build structuresthatshouldsupportthemodelwe areintendingto createin thecomputer. We saythatwe createrealizedconceptsin themodelsystem.Finally, modelingis theprocesswhereweconnecttheproblemspecificconceptsin thereferentsystemwith therealizedconceptsin themodelsystem.In themodelsystem,objectsandpropertiesof theseobjectsrepresentphenomenaandtheirpropertiesin thereferentsystem.

Theprogrammingprocessinvolvesidentificationof conceptsandphenom-enain thereferentsystemandtheir subsequentrepresentationin termsof ob-jectsandpatterns.Ultimately this is a questionabouthow to identify thepat-ternsandobjectsof ourprogramexecutions.It is notall aspectsof thereal(orimaginary)world thatcanbemodeledasa programexecution.We thereforehaveto identity thekind of phenomenathatwewantto modelasprogramexe-cutions.Thephysicalmodelsweareinterestedin arethosepartsof realitywewantto regardasinformationprocesses. In thenext sectionwewill introducethe notion of informationprocess,which will give us someguidelinesaboutidentifyingobjects.

Patternsaremeansfor representingconceptsof the referentsystem. To‘find thepatterns’it is thereforenecessaryto discusssubjectslike thenotionof conceptsand their relationsto phenomena,and importantaspectsof theabstractionprocess. Conceptsand abstractionwill be dealt with further inSection18.3.

18.2 Inf ormation processes

It is not all aspectsof reality that canbe modeledasprogramexecutions.Inthissectionwewill look atthekind of phenomenawecanrepresentascomput-erizedmodels.Perhapsthemostimportantphenomenastudiedin informaticsareinformationprocesses.Programexecutionsareinformationprocesses,andinformationhandlingin offices,planningin corporations,etc., areotherex-amplesof suchprocesses.Theabovedefinitionof informaticsdoesnot implythatall phenomenato whichwemayassociateinformationaspects‘belong’ toinformatics.Informaticsrepresentsoneperspectivefor lookingatphenomena.Dataprocessingin apostofficemayberegardedasaninformationprocess,asaneconomicprocessor asa socialprocess,andthus‘belong’ to informatics,economicsor sociology, dependingupontheperspectivechosen.

An informationprocessis aspecialkind of process,andwedefineit in thefollowing way:

Definition 18.3 An informationprocessis a processwhere thequalitiescon-


sideredare:

m Its substance, thephysicalmaterialthat it transforms.m Measurablepropertiesof its substance, the resultsof measurementrepre-

sentedbyvalues.m Transformationsof its substanceandthusits measurableproperties.

Thenotionof an informationprocessgivescertainguidelinesfor identifyingconceptsandphenomenain thereferentsystems.

Substance This is thephysicalmaterialthat is transformedby an informa-tion process.Phenomenalike ‘Socrates’,‘Mount Everest’,a medicalrecord,anda memorycell in a computerareall examplesof phenomenawhich havesubstance.Substanceis characterizedby a certainvolumeanda uniqueloca-tion in time andspace.A major aspectof substanceis identity. Two piecesof substancehave thesameidentity only if they arethesamesubstance.Theymay have identical properties: ‘Socrates’and ‘your teacher’may have thesameweight,ageandeyecolor, but they arenot thesameperson.

Measurablepropertiesof substance Substancehasno inherentpropertiesbesideshaving a certainvolumeanda uniquelocationin time andspace.Allotherpropertiesassociatedwith substancehave to be obtainedby measure-ments. A givenpropertyof somesubstancemay be observedby performinga measurementresultingin a measureresult(measurement).A measurementmaybeasimplecountingof thenumberof petalsonafloweror it maybeper-formedusingadvancedequipment,suchasmeasuringradiationfrom a com-puterscreen.In general,a sequenceof actionsis involved in performingthemeasurement.

Weight, blood pressureandeye color of a personareexamplesof mea-surableproperties.Thestateof a memorycell of a computeris a measurableproperty.

The resultsof measurementsare usually describedby valuesto capturethemfor the purposeof comparingthem. This is so commonthat oneoftendoesnot distinguishbetweenmeasurementsandthe valuesdescribingthem.Thevalue‘82.5 kg’ maydescribetheweightof someperson.Thevalue‘82.5kg’ is actuallyan abstractionclassifyinga setof measurementson a weight.We may think of ‘82.5 kg’ asa conceptandthemeasurementsof theweightaspartof its extension.Becauseof this confusionvaluesareoftenconsideredthephenomenainsteadof theactualmeasurements.

Abstractionssuchasvalues,functionsandtypeshave beendevelopedtodescribemeasurablepropertiesof substance.

18.2 INFORMATION PROCESSES 289

Transf� ormations on substance An informationprocessis characterizedbytransformationswhich changeits substanceandtherebyits measurableprop-erties. Transformationsarepartially orderedsequencesof events. An eventchangesthe stateof the informationprocess,andeventsareorderedin time.Theorderingis partial. Theeventsaretheonly meansfor changingthemea-surablepropertiesof thesubstance.

Thefollowing phenomenaareexamplesof events:pushinga specificbut-ton at a specificpoint in time; ‘the birth of HansChristianAndersen’,and‘the transitionbetweenspringandsummer1984.’ Phenomenamay alsobesequencesof events like ‘Hannibal’s march acrossthe Alps’, ‘Columbus’America-expedition’and‘eating.’

The notion of information processesgivescertainguidelinesfor the se-lection of phenomena.We have to considertangiblethingswherethe mainaspectis substance,we have to considermeasurablepropertiesof substance,andfinally, wehave to considerthetransformationson thesubstance.

Inf ormation systems

The definition of an informationprocessis very general,and in this sectionwewill putasystemperspectiveon informationprocesses.Thetermsystemisoftenencounteredwithin informatics,andit hasbeenfrequentlyusedin thisbook.Wedefinea systemin thefollowing way:

Definition 18.4 A systemis a part of the world that a person (or group ofpersons)choosesto regard as a wholeconsistingof components, each com-ponentcharacterizedby propertiesandby actionsrelatedto thesepropertiesandthoseof othercomponents.

Accordingto thisdefinition,nopartof theworld ‘is asystem’asaninher-entproperty. It is a systemif wechooseasystemperspective.

In a systemperspective, substanceof information processesis orga-nized/perceivedin termsof components.The(measurableproperties)of sub-stancearethemeasurablepropertiesof components.The transformationsonthesubstanceareperceivedasactionsperformedby components.In thedef-inition of system,termslike ‘properties’ and ‘actions’ are used. Therearemany differentkinds of propertiesthat may be associatedwith components,andtherearemany waysof organizingactionswithin a system.Programex-ecutionsare information processes,andmay be regardedas systemsin theabovesense.In thisbookwearemainly interestedin programexecutions,andthenotionof BETA programexecutionspresentedhereis onespecificwayofunderstandinganddescribingsystems.

Wearenow ableto giveamoreprecisedefinitionof programexecution:

Definition 18.5 A programexecutionis an informationprocessregardedasasystemdevelopingthroughtransformationsof its state.


m Thesubstanceis organizedasobjects, which arecomputerizedmaterial.m A measurablepropertyof thesubstanceis a measurablepropertyof oneor

moreobjects.m Transformationsof stateare regardedaspartially orderedsequencesof ac-

tionsassociatedwith objects.m Conceptsare representedbypatternswhich areattributesof objects.

Thecomponentsof a programexecutionareobjects. Thepropertiesof com-ponents(objects)areattributes.A BETA programexecutioncanbemorepre-ciselydefinedasfollows:

Definition 18.6 ABETA programexecutionconsistsof acollectionofobjects.Anobjectis characterizedbya setof attributesandanaction-part. Anattributemaybe: A referenceto anobject,a part-objector a pattern.

A BETA program executionhasthreekindsof objects: item, componentandsystem. Itemsmayhavetheir action-partexecutedbyotherobjects,com-ponentsmayexecutetheir action-partalternatelywith othercomponents,andsystemsmayexecutetheir action-partconcurrentlywith othersystems.

18.3 Conceptsand abstraction

Abstractionis probablythemostpowerful tool availableto thehumanintellectfor understandingcomplex phenomena.In the real world we areconfrontedwith a hugenumberof differentphenomenasuchasphysicalobjects,situa-tions, eventsandprocesses.All phenomenaare different; thereare no twoidenticalpersons,two identicalcars,or two identicalflowers. It is, however,impossibleto dealwith all singlephenomenadirectlywithout toolsfor group-ing similar phenomena.Abstractionarisesfrom a recognitionof similaritiesbetweenphenomenaand conceptsand the decisionto concentrateon thesesimilaritiesandignorethedifferencesfor thetime being.Thesimilaritiesareconsideredasfundamentalandthedifferencesastrivial. An abstractioncoversa groupof phenomenacharacterizedby certainproperties.A word or pictureis usuallyintroducedto symbolizetheabstraction.An abstractionis alsore-ferredto asaconcept.

18.3.1 Phenomenaand concepts

Until now we have beenrathervagueaboutthe termsphenomenonandcon-cept.Thefollowing definitionsgivemoreprecisedefinitionsof theseterms:

Definition 18.7 A phenomenonis a thing that has definite, individual exis-tencein realityor in themind; anythingreal in itself

18.3 CONCEPTSAND ABSTRACTION 291

Definition� 18.8 A conceptis a generalizedideaof a collectionof phenomena,basedon knowledgeof commonpropertiesof instancesin thecollection

The following individuals are all examplesof phenomena: ‘WinstonChurchill’, ‘JohnF. Kennedy’and‘CharlesdeGaulle.’ They areall coveredbythegeneralconcept‘Person’,but alsoby themorespecializedconcept‘States-man.’ ‘Bounty’, ‘Jutlandia’ and ‘PederPars’2 are examplesof phenomenacoveredby theconcept‘Ship.’ ‘Mount Everest’,‘Mont Blanc’ areexamplesof phenomenacoveredby theconcept‘Mountain.’

The‘Statesman’conceptis anexampleof a roleplayedby persons.Otherexamplesof rolesare‘Employee’, ‘Owner’, ‘taxpayer’and‘Tenant.’

The above-mentionedphenomenaareexamplesof phenomenathat havesubstance.

Phenomenacanalsobeeventsthathappen.Thefollowing phenomenaareexamplesof events:pushinga specificbuttonat a specificpoint in time, and‘the birth of HansChristianAndersen.’ Phenomenamay alsobe sequencesof events like ‘Hannibal’s march acrossthe Alps.’ ‘Columbus’ America-expedition’ and‘making a specificpizza.’ For suchphenomenawe may de-velopconceptswherethe intensiondescribesthe sequencesof eventstakingplace.

We may also have phenomenathat recordevents. An exampleof sucha phenomenonis a ‘Flight record’ which may registercertaindataof a spe-cific flight, like SK911from Copenhagento LA on December12, 1989,etc.Anotherexampleis a ‘Systemcrash’which mayberegisteredin a log book.

Measurablepropertiesof somematerialarealsoexamplesof phenomena.Examplesof theseincludethe ‘weight of a person’,the ‘blood pressureof aperson’and‘the temperaturein New York on December24,1984.’

Definition 18.9 A concept is traditionally characterizedby the followingterms:

m Theextensionof a conceptrefers to the collectionof phenomenathat theconceptsomehowcovers.

m The intensionof a conceptis a collectionof propertiesthat in somewaycharacterizethephenomenain theextensionof theconcept.

m The designationof a conceptis the collection of names(or pictures) bywhich theconceptis known.

The extension of the concept‘Person’ includes the phenomena‘WinstonChurchill’, ‘JohnF. Kennedy’and‘CharlesdeGaulle.’ Theintensionof ‘Per-son’ includesthe following properties: ‘able to think’, ‘walks upright’ and

2JutlandiaandPederParsarewell-known Danishships.


‘usestools.’ In additionto ‘Person’thedesignationincludes‘HumanBeing’and‘Homosapiens.’

A phenomenonis a thing thathasdefinite,individual existencein realityor in the mind. The above examplesof phenomenaexist in reality. Exam-plesof phenomenaexisting in themind include‘SherlockHolmes’, ‘DonaldDuck’ and‘The Loch NessMonster’ (althoughsomepeoplethink it exists inreality!). Theextensionof conceptslike ‘Unicorn’, ‘Pixy’ and‘Nordic God’areexamplesof phenomenaexistingin themind. Thetermsconcretephenom-enaandabstractphenomenaareoftenusedto distinguishbetweenphenomenaexisting in reality or in themind.

Onephilosophicalissuehereis whetheror not it is useful to distinguishbetweenphenomenaandconcepts.Conceptsexist in themind andmaycon-sequentlybeviewedasabstractphenomena.Oneconsequenceof this is thatit is possibleto imaginea conceptwherethe extensionconsistsof concepts.This situationis usuallybetterdescribedby meansof generalization,as in-troducedbelow. In general,we think that it is usefulto distinguishbetweenconceptsandabstractphenomena.A conceptlike ‘Boat’ coversa collectionof phenomena,whereasan abstractphenomenonlike ‘Sherlock Holmes’ isoneindividual phenomenonexisting in themind of people.However, at thispoint it maybeappropriateto point out thatmostissuesin this chapterareofaphilosophicalnatureandthereforehighly subjective.

In theabovedefinitionof concepts,thepropertiesconstitutingtheintensionare thosethat ‘in someway’ characterizethe phenomenain the extension.Therearedifferentviews of conceptsthatgive differentinterpretationsto ‘insomeway.’ In thenext sectionswe look at two extremesin this respect.

18.3.2 Aristotelian view

The first of the two views has its origin in the classicalAristotelian logic.Here conceptsare organizedin a logical hierarchicalconceptstructureandtheextensionof a conceptcontainsphenomenathatall satisfysomepreciselydefinedrequirements.This is expressedin the following characterizationoftheintension:

Definition 18.10 Theintensionof a conceptis a collectionof propertiesthatmaybedividedinto twogroups:thedefiningpropertiesthatall phenomenaintheextensionmusthaveandthecharacteristicpropertiesthat thephenomenamayor maynothave. Thenatureof thepropertiesis such that it is objectivelydeterminablewhetheror nota phenomenonhasa certainproperty.

The definingpropertiesdeterminea sharpborderbetweenmembersandnon-membersof a concept. Sinceit is objectively determinablewhetherornot a phenomenonhasa certainproperty, it is alsoobjectively determinable

18.3 CONCEPTSAND ABSTRACTION 293

whetherp or not a phenomenonbelongsto a givenconcept.In otherwords,theextensionof aconceptis uniquelydefinedby theintension.

TheAristotelianview of conceptshasturnedout to beusefulfor modelingsystematicand‘scientific’ conceptsasfoundwithin well establishedfieldslikemathematics,physics,zoologyandbotany.

For thepropertiesin the intensionit is importantthat it is objectively de-terminablewhetheror not a phenomenonhasa certainproperty. This resultsin a conceptstructurein which the conceptsarecharacterizedby sharpcon-ceptborders.In addition,the phenomenain the extensionof an Aristotelianconceptarerelatively homogeneous.This is in line with the‘scientific’ natureof theAristotelianview of concepts.

The propertiesof an Aristotelianconceptmay be describedby meansofpredicates,i.e. usingmathematics.Within scienceslike physicsandbiology,phenomenaareoftencharacterizedusingmeasurableproperties,asdescribedin Section18.2.Nomatterhow thepropertiesaredescribed,it is importantthatit is objectively decidablewhetheror not a given phenomenonhasa certainproperty.

18.3.3 Prototypical view

As alreadymentioned,theAristotelianview of conceptsis usefulfor model-ing systematicand‘scientific’ concepts,andit hasbeenusedfor many yearswith successespeciallywithin naturalsciences,althoughnot alwayswithoutproblems.

Therearea large numberof everydayconceptsthat cannotconvenientlybe describedasAristotelianconcepts.Examplesof suchconceptsare,‘rockmusic’, ‘intelligence’ and ‘food.’ Also, somemore technicalconceptssuchas‘object-orientedprogramming’and‘structuredprogramming’aredifficultto describeas Aristotelian concepts. It is commonlynot possibleto find acollectionof objectively decidablepropertiesthatdefinetheseconcepts,but itis possibleto find a collectionof propertiesthatmaycharacterizethesecon-cepts.However, oftenit is notpossibleto objectivelydeterminewhetheror notagivenphenomenonhasacertainproperty. Thishasledto thedevelopmentoftheso-calledprototypicalview of concepts(or fuzzyview or prototypetheory).In theprototypicalview theintensionis definedin thefollowing way:

Definition 18.11 Theintensionof aconceptconsistsof examplesof propertiesthat phenomenamayhave, togetherwith a collectionof typical phenomenacoveredby theconcept,calledprototypes.

The prototypical view differs from the Aristotelian view in a number ofways:

(1) It maynot beobjectively decidablewhetheror not a phenomenonhasapropertyof theintension.


(2) The intensionis given by examplesof properties.All phenomenawillhave someof theproperties,but rarelyall. A phenomenonhaving someof thepropertiesmaynotbelongto theextensionof theconcept.

(3) Theprototypesaretypical phenomenabelongingto theextensionof theconcept.

Themajorconsequenceof this is that theextensionof a prototypicalconceptis notuniquelydeterminedby theintension.It requiresahumanjudgementtodecidewhetheror not a givenphenomenonbelongsto theconcept.Thephe-nomenain the extensionwill have variedtypicality andthe bordersbetweenconceptsareblurred.

The prototypical view of conceptsis more suited than the Aristotelianview to describemosteverydayconcepts.This is alsooftentruefor problem-specificconceptsof thereferentsystem.Below we discusstheconsequencesof this for thesystemdevelopmentprocess.

18.3.4 Other viewsof concepts

The Aristotelianandprototypicalview of conceptsrepresenttwo extremes,andit is possibleto imagineanumberof intermediateviews.

OnedifferencebetweenAristotelianandprototypicalviewsof conceptsiswhetheror not it is objectively decidableif a givenphenomenahasa certainpropertyor not.

Conceptual clustering Conceptualclustering is a variation of the Aris-totelianview. Theintensionmayhavepropertieswhichmaynotbeobjectivelydecided,thusit is basedon ahumanjudgementwhetheror notaphenomenonis coveredby theconcept.

Prototypical conceptswith objective properties It is of coursepossibletoimagineprototypicalconceptswhereall thepropertiesareobjectively decid-able.

Defining versuscharacteristic properties Theintensionof anAristotelianconceptis dividedinto definingandcharacteristicproperties.In theory, eachof thesetwo setsof propertiesmaybeempty. It is easyto imagineAristotelianconceptswithout characteristicproperties.It is moreproblematicto imagineAristotelianconceptswithout definingproperties.Accordingto thedefinitionof an Aristotelianconcept,any phenomenonpossessingthe definingproper-tiesbelongsto theextensionof theconcept.Consequently, a conceptwithoutdefiningpropertieshasall phenomenain its extension.This is of courseuse-less.

18.4 THE ABSTRACTION PROCESS 295

It is, however, still interestingto considera variantof Aristoteliancon-ceptsthatallows thedefiningpropertiesto beempty. In this casethedefiningpropertiesaresupposedto be possessedby all phenomenain the extension,but not viceversa.It is thenamatterof humanjudgementto decideif a givenphenomenonbelongsto theconcept.

If propertiesareallowed to be non-objective, we arecloseto the proto-typical view of concepts.

18.3.5 Representingconceptsin BETA

A programminglanguagelike BETA is mainly useful for representingAris-totelianconcepts:a patternmaybeusedfor representinganAristoteliancon-cept. The instancesof thepatternrepresenttheextensionof theconcept,theobject-descriptorrepresentsthe intensionandthe nameof the patternrepre-sentsits designation.The intensionof a conceptis representedby meansofan object-descriptor, i.e. an object-descriptordeterminesthe kind of proper-ties that canbe represented.For an object-descriptorwe have attributesandactions. The attributesmay be part-objects,referencesto other objectsandpatterns.

18.4 The abstraction process

In boththereferentandthemodelsystems,conceptstructuresarecreated.Thisimpliesthatwehaveto discusstheprocessof producingandusingknowledge,i.e. issuesrelatedto the theoryof knowledgealsocalledepistemology. Theprocessof knowledgemaybesplit into threelevels:

(1) Thelevel of empiricalconcreteness.At this level we conceive reality orindividualphenomenaasthey are.Wedonot realizesimilaritiesbetweendifferentphenomena,nor do we obtainany systematicunderstandingofthe individual phenomena.We noticewhat happens,but neitherunder-standwhy it happensnor the relationsbetweenthe phenomena.In theprogrammingprocessthis correspondsto a level wherewe aretrying tounderstandthe singleobjectsthat constitutethe system. We have littleunderstandingof the relationsbetweenthe objects,e.g. how to grouptheminto classes.

(2) Thelevel of abstraction. To understandthe complicationsof the refer-entsystem,we have to analyzethephenomenaanddevelopconceptsforgraspingthe relevant propertiesof the phenomenathat we consider. Inthe programmingprocessthis correspondsto designingthe classesandtheir attributesandto organizingtheclassesinto aclass/sub-classhierar-chy. At this level weobtainasimpleandsystematicunderstandingof thephenomenain thereferentsystem.


(3) Thelevel of thoughtconcreteness.The understandingcorrespondingtothe abstractlevel is further developedto obtainan understandingof thetotality of the referentsystem. By having organizedthe phenomenaofthereferentsystemby meansof concepts,we maybeableto understandrelationsbetweenphenomenathatwe did not understandat the level ofempiricalconcreteness.We mayalsobeableto explain why thingshap-penandto predictwhatwill happen.

Theabove is an identificationof threelevelsappearingin theprocessof cre-ating andproducingknowledge. In this processthe perspective providesuswith variousmeansfor organizingandunderstandingourknowledge.Thefol-lowing arethreefundamentalmeansof organizationfor apprehendingtherealworld:

(1) Identificationof phenomenaand their properties. In perceiving the realworld peopleidentify phenomenaandtheir properties.Theresultof thisis a numberof singular phenomenacharacterizedby a selectedset ofproperties.Thephenomenaaresingularsincethey have not beenclassi-fied in termsof concepts.

Selectionof therelevantpropertiesof phenomenais highly domainspe-cific. In this book the domainis informationprocesses,asexplainedinSection18.2. Within informationprocessesthereis still a greatdealofvarietydependingon thekind of informationsystemto beconstructed.

(2) Classification.Classificationis themeansby which we form anddistin-guishbetweendifferentclassesof phenomena.Thatis weform concepts.Having identifiedphenomenaandtheirpropertiesandconcepts,wegroupsimilar phenomenaandconcepts.A classificationis often calleda tax-onomy. It is very commonto constructtaxonomiesto comparevarioussubjects.Whenclassificationis appliedrepeatedly, classificationhierar-chiesmaybeobtained.

(3) Composition. A phenomenonmay be understoodas a compositionofotherphenomena,i.e. thereis a distinctionbetweenwhole phenomenaandtheir componentphenomena.A car consistsof body, four wheels,motor, etc. A processof makinga pizzamay be understoodasa com-positionof severalsub-processes,including: makingthedough,makingthe tomatosauce,preparingthe topping, etc. Repeatedapplicationofcompositionleadsto compositionhierarchies.

In general,the processof creatingnew conceptscannotjust be explainedasconsistingof the above sub-functions.In practice,the definitionof conceptswill undergo drasticchanges.The understandingobtainedduring the devel-opmentprocesswill usually influenceprevious steps. It is, however, usefulto be awareof whethera problemis approachedtop-down or bottom-up. In

18.5 CLASSIFICATION AND COMPOSITION 297

thesame� way it is usefulto beawareof theabove-mentionedsub-functionsofabstraction.

In thenext sectionwe takeacloserlook at classificationandcomposition.

18.5 Classificationand composition

In reality we have to dealwith a hugenumberof conceptsandphenomena,andit would not be possibleto dealwith thatamountof complexity withouttoolsfor hierarchical organizationof conceptsandphenomena.Classificationand compositionare meansto organizecomplexity in termsof hierarchies.The two termsareoften usedin two different,but complementary, ways. Insomesituationsthey areusedasadescriptionof sub-functionsgoingon in theprocessof producingknowledge. In this processwe constantlyapplyclassi-fication andcompositionto organizeour knowledge. In othersituationsthetwo termsareusedfor describing(static) relationsbetweenphenomenaandconceptsidentifiedduringtheprocessof identifyingknowledge.

18.5.1 Classification

For classificationwedistinguishbetweentheclassificationof phenomenaandof concepts.In thefollowing wedefinetheterms‘clustering’and‘generaliza-tion.’ By classificationwethenmeaneitherclusteringor generalization:

Clustering Is a meansto focus on similarities betweena numberof phe-nomenaand to ignore their differences,i.e. clusteringis a classificationofphenomena.

Definition 18.12 To cluster is to form a conceptthat covers a collectionofsimilar phenomena.To exemplify is to identifya phenomenonin theextensionof a concept.Exemplificationis theinverseof clustering.

Clustering/exemplificationcorrespondsto the instance-ofrelationship.

Definition 18.13 Theinstance-ofrelationshipholdsbetweena conceptandaphenomenonin theextensionof theconcept.

Generalization Is a meansto focus on similarities betweena numberofconceptsandto ignoretheir differences,i.e. generalizationis classificationofconcepts.

Definition 18.14 To generalizeis to form a conceptthat covers a numberofmorespecialconceptsbasedonsimilaritiesof thespecialconcepts.Theinten-sionof thegeneral conceptis a collectionof propertiesthatareall part of the


intensionof themore specialconcepts.Theextensionof thegeneral conceptcontainstheunionof theextensionsof themorespecialconcepts.

To specializeis to form a more specialconceptfroma general one. Spe-cializationis theinverseof generalization.

The termsgeneralization of andspecializationof are the namesfor thecorrespondingrelations.

Definition 18.15 A generalizationis a relationshipbetweena general conceptand a numberof more specialconcepts.A specializationis the inverseof ageneralization.

Theterm generalization is oftenusedabout the general conceptand thetermspecializationis oftenusedaboutoneof thespecialconcepts.

The concept‘Animal’ is a generalizationof the more specialconcepts‘Mammal’, ‘Fish’, ‘Bird’ and‘Reptile’, andall of thesemay in turn becon-sideredspecializationsof ‘Animal.’ The concept‘Mammal’ may be thoughtof asa generalizationof theconcepts‘Predator’and‘Rodent’,which maybeconsideredspecializationsof ‘Mammal.’

The concept‘Reservation’ may be considereda generalizationof ‘FlightReservation’, ‘TrainReservation’, ‘BoatReservation’ and‘Hotel Reservation.’

Theconcept‘Movement’maybeconsidereda generalizationof thecon-cepts‘Travel’, ‘Jump’ and‘Run.’

Classificationhierarchies

Classificationis oftenusedto definehierarchiesof conceptsandphenomena.An exampleof a classificationhierarchyfor animalsis shown in Figure2.2.This hierarchyis alsoanexampleof a generalization/specializationhierarchysinceit only includesconcepts.

The hierarchyin Figure 2.2 hasan importantproperty: it is tree struc-tured. Eachconcepthasat mostoneimmediategeneralization,implying thatthe extensionsof two conceptswith the sameimmediategeneralizationaredisjoint. Theconcepts‘Predator’and‘Rodent’ have thesamegeneralization‘Mammal’, andthe extensionsof ‘Predator’and ‘Rodent’ aredisjoint. Thetreestructuredclassificationhierarchiesarean importantmechanismfor or-ganizingknowledge. They areappliedin many disciplinessuchasbiologyandchemistry. Thephenomenaof interestareclassifiedaccordingto selectedproperties.

Therearealsoexamplesof classificationhierarchiesthatarenot treestruc-tured.An exampleof suchahierarchyis givenin Figure18.2,3 whichshowsaclassificationof geometricfigures.This hierarchyis not treestructuredsince,for example,the concept‘Square’hastwo immediategeneralizations‘Rect-angle’and‘Rhombus.’

3Borrowedfrom (AbelsonandSussmann,1985).


polygon

quadrilateral

kitetrapezoid

triangle

isosceles triangle right triangle

equilateral triangle isosceles right triangle

parallelogram

rectangle rhombus

square

Figure18.2 Classificationof geometricobjects.

It is often a desirablepropertyof a classificationhierarchythat it is treestructuredsincethis givesa simpler andmore systematicorganizationthanusingnon-treestructuredclassifications.In practice,however, oneoftenendsup with a classificationhierarchywhich is not treestructured.This may bethe caseif oneis classifyingthe samephenomenaaccordingto independentproperties. A non-treestructuredhierarchycan always be madetreestruc-tured,which, however, oftengivesrise to clumsyhierarchies.Insteadof oneclassificationhierarchyonemay insteadmake two or moreclassificationsofthe samephenomena.This will thenresult in two or moreindependenttreestructuredclassificationhierarchies.

Consideranexamplewhereseveralrolesof peopleareof interest.It maythenbe of interestto classifypeopleaccordingto their profession,their na-tionality andtheir religion. Thismayresultin threealternative treestructuredclassificationsof thesamephenomena.

Support for classificationin BETA

Classificationis supportedin BETA by meansof objectsandpatterns.Ob-jectsmaybeusedto representphenomenaandtheir properties.Patternsmaybe usedto representconcepts. Clearly, thereis supportfor the instance-ofrelationship.

Sub-patternsandvirtual patternssupportsgeneralization/specialization.In


Chapters6–9numerousexamplesof modelingof generalization/specializationhierarchiesareshown.

It is obviousthat thesub-patternmechanismonly supportstreestructuredclassificationhierarchies.In addition,BETA doesnot supportthepossibilityof representingmorethanoneclassificationhierarchyof thesameobjects.InBETA it maythereforebenecessaryto representsuchclassificationhierarchiesby anothermechanism.

SomeprogramminglanguageslikeClos,C++ andEiffel makeuseof mul-tiple inheritance. In thecaseswherethis is usedto representalternative clas-sifications,like therole exampleabove, it mayleadto complicatedstructures.SeeSection6.8for a furtherdiscussionof multiple inheritance.

18.5.2 Composition

Compositionis ameansto organizephenomenaandconceptsin termsof com-ponentsof otherphenomenaandconcepts.Therearea numberof differentwaysof composingphenomenainto compoundphenomena.

A car may be viewed as consistingof a body, four wheels,etc. Thesecomponentsarephysicalpartsof thecar. A treemaybeviewedasconsistingof branches,a trunk, rootsandleaves.

A ‘Hotel Reservation’ may be viewed asa compositionof a ‘Person’,a‘Hotel’, a ‘Room’ anda ‘Date.’ It is, however, not meaningfulto view, forinstance,the personas a physicalpart of the hotel reservation. The corre-spondingcomponentis betterviewedasa referenceto aperson.

We definecompositionin thefollowing way:

Definition 18.16 To composeis to form a compoundphenomenon/conceptby meansof a numberof componentphenomena/concepts.Properties inthe intension of the compoundphenomenon/conceptare describedusingthe componentphenomena/concepts.The extensionof the compoundphe-nomenon/conceptconsistsof phenomenawhich havecomponentsbelongingto theextensionof thecomponentphenomena/concepts.

To decomposeis to identify a componentphenomenon/conceptof a phe-nomenon/concept.Decompositionis theinverseof composition.

Compositiongivesriseto thecomponent-ofrelation:

Definition 18.17 The component-ofrelation is a relationship betweenaphenomenon/conceptandoneof its componentphenomena/concepts.

Thereareanumberof differentmeansfor makingcompositions.They mayallbedefinedasspecialcasesof compositionandcomponent-of.In thefollowingwe introducefour of thesemeans:whole-partcomposition;referencecompo-sition; localization;andconceptcomposition.They will only be introduced


asrelations,y andno namefor thecorrespondingsub-functionof compositionwill begiven,althoughthis couldbedone.Thefour casesof compositionarenot independentin thesensethatthesamecomponentsmaybepartof two ormoreof the relations. The readermay find the distinctionbetweensomeoftheverbaldefinitionsbelow quite subtle. However, hopefully the illustrationof therelationsin BETA will make thedistinctionclear.

Whole-part composition

One important form of compositionis the structuringof phenomenaintowholesandparts. A ‘Person’maynaturallybeviewedasconsistingof partslike ‘Head’, ‘Body’, ‘Arms’ and‘Legs.’ In turn, the‘Legs’ consistof ‘Lowerleg’, ‘Foot’, etc.

Definition 18.18 Thepart-ofrelationis a relationbetweena phenomenonandoneof its part phenomena.

A ‘Car’ maybeconsideredasconsistingof partslike ‘SteeringWheel’,‘Mo-tor’, ‘Body’ and‘Wheel’, i.e.‘Wheel’ is apart-ofa‘Car’, a‘Motor’ is apart-ofa ‘Car’, etc.

Thefollowing exampleshowshow whole-partcompositionis supportedinBETA. Theexampledescribesapatternrepresentingtheconceptof a ‘Car’:

Car:(# aSteeringWheel: @SteeringWheel;

aMotor: @Motor;aBody: @Body;wheels: [4] @Wheel

#)

Thepart-ofrelationgivesriseto apart hierarchy.For moreexamplesof modelingwhole-parthierachiesin BETA, seeChap-

ter10.

Referencecomposition

A referenceis a componentof a phenomenonthat denotesanotherphe-nomenon.The‘Person’componentof a ‘Reservation’ is actuallya referenceto a‘Person.’ Similarly, for the‘Hotel’ and‘Room’ components.Compositionof referencesgivesriseto thehas-ref-torelation:

Definition 18.19 The has-ref-torelation is a relationshipbetweena phe-nomenonand one of its components,being a reference to another phe-nomenon.


The following examplesshows how referencecompositionis supportedinBETA. Theexampledescribestheconceptof a ‘Hotel Reservation’:

HotelReservation:(# aPerson: ˆPerson;

aHotel: ˆHotel;aRoom: ˆRoom;aDate: @Date

#)

The components‘aPerson’,‘aHotel’ and‘aRoom’ arereferencecomponentsof a ‘Hotel Reservation.’

Thecomponent‘aDate’ is representedasa part-object.It is, however, notintuitively usefulto modelthedateof ahotelreservationasapartobject.Thedateis a measurablepropertyof a hotel reservation. Modelingof measurablepropertiesis furtherdiscussedin Section18.7

For moreexamplesof modelingreferencecompositionin BETA, seeSec-tion 10.1.1.

Localization

Localizationis a meansfor describing/organizingthat the existenceof phe-nomena/conceptsarerestrictedto thecontext of a givenphenomenon,i.e. thelocalcomponentphenomena/conceptsaredependentuponthecompositephe-nomenon.The propertiesof a givenphenomenonmay be singularlydefinedphenomenaor conceptswhichonly haveameaningascomponentsof thecom-poundphenomenon/concept.

Definition 18.20 The is-local-to relation is a relationshipbetweena com-pound phenomenonand a locally defined dependentcomponentphe-nomenon/concept.

In Chapter8 a numberof examplesof localizationaregiven. Block structureis theBETA mechanismfor supportinglocalization.

Conceptcomposition

Conceptcompositionis a meansto definea compoundphenomenon/conceptby meansof a numberof independentcomponentconcepts.Conceptcompo-sition is thusa relationshipbetweena phenomenon/conceptanda numberofconcepts.Independencemeansthat thecomponentconceptshave a meaningindependentof thecompoundphenomenon/conceptbeingdefined.

Definition 18.21 A conceptcompositionis a relationshipbetweena com-poundphenomenon/conceptand a numberof independentcomponentcon-cepts.

18.6 RELATIONS 303

A certaino relationshipbetweenthe concepts‘Person’, ‘Hotel’, ‘Room’ and‘Date’ maybeconsideredastheconceptcomposition‘Reservation.’ Thecon-cepts‘Person’,‘Hotel’, ‘Room’ and‘Date’ areindependent,sincethey haveameaningwithout theconceptof ‘Reservation.’ Note thata conceptlike ‘Re-servation’ maybeviewedasbothareferencecompositionandaconceptcom-position. In general,a conceptor phenomenamaybeviewedasoneor moreof thefour formsof composition.

Theconcept‘Travel’ maybeviewedasaconceptcompositionof conceptslike ‘Source’,‘Destination’,‘Duration’ and‘Subtravels.’

Theconcept‘Car’ maybethoughtof asaconceptcompositionof thecon-cepts:‘Horsepower’, ‘Body’, ‘Wheel’, ‘Motor’, etc.

18.6 Relations

Relationsareacommonform of abstractionusedfor organizingknowledge:

Definition 18.22 A relation is a union or connectionof phenomenaand/orconcepts

Someof theaboveabstractionmechanismsmayall beviewedasspecialkindsof relations. For classificationandcompositionwe have alreadyintroduceda numberof correspondingrelations,including instance-of,part-of, has-ref-to, etc. Theserelationsare examplesof structural relations implied by theabstractionprinciples.In agivenproblemdomaintheremaybealargenumberof specialrelationsthatwemaybeinterestedin modeling.

Referencecompositionis actually a meansfor representingsimple bi-nary relationsbetweenphenomena.An exampleof sucha relation is ‘Em-ployeehas-aBoss’,which is a binary relationshipbetweenanemployeeandhis or her boss. Otherexamplesare ‘Vehicle is-owned-byPerson’,‘Part is-manufactured-bySupplier’, ‘Hotel room is-reserved-by Person’and ‘Com-pany hasPresident.’ In Section10.1.1a numberof examplesof how to repre-sentrelationsin BETA areshown, including therelationshipbetweena bookandits author, andbetweenavehicleandits owner. In addition,thedifferencebetweenone-wayandtwo-wayrelationswasdiscussed.

Another importantaspectof relationsmetionedin Section10.1.1is thefunctionality of the relation. Considera relation ‘A R B’ meaningthat in-stancesof ‘A’ arein therelation‘R’ to instancesof ‘B.’ Relationshipsinvolvinginstancesof two classescanbeclassifiedinto thefollowing forms,dependingon thenumberof instancesinvolvedin eachinstanceof therelationship:

One-to-one: In eachinstanceof therelationship,at mostoneinstanceof ‘A’canbein relationto at mostone‘B.’


One-to-many: In eachinstanceof the relationship,at mostoneinstanceof‘A’ canbein relationto many instancesof ‘B.’

Many-to-many: In eachinstanceof the relationship,many instancesof ‘A’canbein relationto many instancesof ‘B.’

For eachof the forms the phrase‘at mostone’ could be ‘exactly one.’ Thisis, for example,the casewith a vehiclethat alwayshasan owner. Similarly,thephrase‘many’ canmeaneither‘ zeroor more’ or ‘one or more’ or a fixednumber.

Section10.1.1alsomentionedthat it maybeusefulto representrelation-shipsasinstancesof patterns.This maybethecasefor relationsthatarenotbinaryor if additionalattributesareneededto characterizetherelation. ‘TheBeatles’,‘The Mills Brothers’,and ‘Simon andGarfunkel’ areexamplesofphenomenathatbelongto theextensionsof conceptssuchas‘Quartet’, ‘Trio’and‘Duo.’ As anexampleof a relationthat includesattributesotherthanjustdynamicreferences,the‘owner/owns’ relationfor vehicleswasgiven.

Theuseof relationsfor modelingphenomenaandconceptshavebeenusedextensively in the areaof databasesfor many years. The mostwidely usedmodel is the extendedentity-relationshipmodel, whereinformationis repre-sentedby meansof threeprimitiveconcepts:

(1) Entities, which representthephenomenabeingmodeled.

(2) Attributes, which representthepropertiesof thosephenomena.

(3) Relationships, which representtheassociationsamongphenomena.

TheextendedEERmodelfits well with object-orientedmodelingin thesensethatanEERmodelcanbedevelopedaspartof anobject-orientedmodel.TheEERentitiescorrespondto objects,andtheEERattributescorrespondto mea-surableproperties.Therelationshipsmayberepresentedassimplereferencesor aspatterns,asshown above.

18.7 Representativeelementsof a description

BETA may be usedasa tool for analysis,modelinganddesign. The BETAlanguageprovidessupportfor representingcertainpartsof reality. Thereare,however, variouspartsof reality thatcannotbedescribeddirectly in BETA. Itwill thereforebenecessaryto representsuchaspectsby meansof someotherBETA elements.

Let usfirst discussaspectsthatcanbedirectlyrepresentedin BETA. Theseinclude:

� Conceptscanberepresentedby patterns.

18.7 REPRESENTATIVE ELEMENTSOFA DESCRIPTION 305

� Material� canberepresentedby objects.� Classificationhierarchiescanberepresentedby sub-patternhierarchiesand

objects.� Compositionhierarchiescorrespondingto whole-partcomposition,refer-

encecomposition,localizationandconceptcompositioncanberepresented.� Relationscanberepresentedby referencecompositionor by relationalob-

jects.

Thebalance propertyof anAccount is anexampleof a propertythatcannotbe representeddirectly in BETA. In Chapter3, the balance propertyis rep-resentedasan integer part-object.Balance is anexampleof a measurableproperty, andthesubstanceof the integer part-objectdoesnotcorrespondtoaphenomenonin thereferentsystem.

Considernext the speedof a vehicle. This is an anotherexampleof apropertythatdoesnot have substance.It is, however, anobservableandmea-surableproperty, by for examplethecar’sspeedometeror thepoliceradar, andthemeasuringdevicesdohavesubstance.Themeasurementmapsanobserva-tion of thespeedona valuespacewith km/hr (miles/hr)astheunit. Thereareanumberof alternativesfor representingameasurablepropertyin BETA. Thespeedattributemayberepresentedby anobjectasin:

Vehicle:(# Body: @(# ... #);

owner: ˆPerson;speed: @real

#)

Thereis, however, a greatdifferencebetweenthe descriptionof the speedpropertyandthe otherattributesof Vehicle . The real object representingspeeddoesnot correspondto a phenomenonin the referentsystem.It is im-portantto be awareof which elementsof a BETA descriptioncorrespondtophenomena/conceptsin thereferentsystemandwhich do not. For this reasonwe introducethefollowing definition:

Definition 18.23 A representative elementof a BETA descriptionis a BETAelementcorrespondingto a phenomenonor conceptin the referent system.BETA elementswhich arenot representativearecallednon-representative.

In theabove descriptionof Vehicle , Body andowner maybeviewedasrep-resentativewhereasspeed is not.

Speedis anexampleof a measurableproperty, andto measurea propertya measurementmust be performed. The speedpropertycould thusbe rep-resentedby a patternrepresentinga classificationof all measurementsof thespeed.Thisgivesusthethefollowing versionof Vehicle :


NAME ’vehicle’origin ’betaenv’body ’vehiclebody’

LIB:AttributesVehicle:

(# Body @(# ... #)owner: ˆPerson;Speed: (# V: @real do <<SLOT Speed:DoPart>> exit V #)private: @<<SLOTprivate:ObjectDescr ipt or> >

#)

NAME ’vehiclebody’origin ’vehicle’

Speed:DoPartdo private.speed -> V

private:ObjectDescriptor(# speed: @real #)

Figure 18.3 Separationof the Vehicle descriptioninto representative andnon-representativeparts.

Vehicle:(# Body: @(# ... #);

owner: ˆPerson;Speed: (# V: @real do ... exit V #)

#)

The Speed patternis now intendedto performa measurementproducingthe‘speed’of thevehicle.How canwecompletethedescriptionof Speed?

Onepossibility is to have a privateReal object representingthe Speed .This may leave uscloseto thefirst alternative of representingSpeed directlyasa Real object. We may, however, separatetheactualrepresentationof thespeedfrom the Vehicle patternusing the fragmentsystem,asdescribedinChapter17. Figure18.3showshow adescriptionof Vehicle canbeseparatedinto representativeandnon-representativeparts.

18.8 GRAPHICAL NOTATION 307

18.8 Graphical notation

Thesyntaxof theBETA languageusedin thisbookhasbeentextual. In Chap-ter 17 a diagrammaticnotationfor the fragmentlanguagehasbeenused. Itmayalsobepossibleto useadiagrammaticor graphicalnotationfor theBETAlanguage,especiallyusefulin analysisanddesign,sincea diagrammaticno-tation may provide a betteroverview of key objectsand patternsand theirrelations.In this bookcertaindiagramshave beenusedto illustratelanguageconcepts.

It is possibleto definean alternative graphicalsyntaxfor the BETA lan-guage,andoneproposalfor this wasgiven by (Bertelsenet al., 1986). Thisproposalgaveagraphicalsyntaxfor all languageconstructsin BETA. It is notobviousthatit is usefulto haveagraphicalnotationfor all languageelements,sinceperhapsnotall detailsarebestpresentedgraphically. TheMjølnerBETASystemincludesaneditorthatprovidesa diagrammaticnotationfor theover-all structureof aBETA description.Thesyntaxof thesediagramsis similar tothediagramsusedin this book.

Oneadvantageof a graphicalnotationis that it can illustratecertainse-manticrelationsmoredirectly thanthe textual representation.Oneexampleof this is classificationhierarchies,asshown in Figure6.1. Theclassificationstructureis definedassub-patterns,wherethenamesof super-patternsrefertothecorrespondingsuper-patterns.Usinga graphicalnotation,it is possibletoshow therelationshipbetweena patternandits sub-patternsmoredirectly byusing,for example,lines.

A graphicalnotationcan also be usedto show compositionhierarchies,specifiedrelations,active versuspassive objectsandcommunicationconnec-tionsbetweenobjects.

Graphicalnotationshavebeenusedfor many yearsto supportanalysisanddesign. This is especiallythe casefor methodsbasedon structuredanaly-sis/structureddesign. Recently, a numberof graphicaldesignnotationsforsupportingobject-orientedanalysisanddesignhaveappeared.

CASE tools

It may be impractical to usea graphicalnotationwithout the supportof acomputer-basedtool. A numberof so-calledCASEtools have beendevel-opedto supportthe variousdifferentdevelopmentmethods.In generalsuchtoolssupportconstructionandmanipulationof agraphicalnotationfor analy-sisand/ordesign.In addition,suchtoolsmaysupportthegenerationof codeskeletonsin someprogramminglanguage,which maythenbefilled in to pro-ducea final program. Theremay be a numberof problemswith suchtoolsdependingonthedifferencesbetweenthegraphicalnotationandtheprogram-ming language.Thefollowing problemshavebeenrecognized:


(1) Theremaybelanguagemechanismsin thegraphicallanguagewhich arenot supportedby theprogramminglanguage.This maymake it difficultto recognizetheoriginal designin thecodeskeletons.

(2) Ideally, a CASEtool shouldmake it possibleto makea full specificationthat canbe usedto generatea completeexecutableprogram. With cur-rentspecificationlanguagesthis is not practical,sinceit would bejust ascomplex aswriting theprogramdirectly. MostCASEtoolsthusgeneratea codeskeletonwhich mustbe completedto get a full implementation.Thedistancebetweenthe(graphical)specificationlanguageusedby theCASEtool andtheprogramminglanguageis referredto astheCASEgap.

(3) In theprocessof developingthecodeskeletonsinto completeprograms,it mayhappenthatit is necessaryto reorganizethecode.ThismeansthattheCASEdiagramswill have to beupdated,otherwisetherewill be in-consistenciesbetweenthediagramsandthecode.Theproblemof goingbackfrom thecodeto theCASEdiagramsis calledreverseengineering.

Theabove problemswith CASEtoolsaredueto the fact that theCASE lan-guageandtheprogramminglanguagediffer. By usinganobject-orientedap-proachit is possibleto designaCASElanguageandaprogramminglanguagebasedon thesameabstractlanguage.Thegraphicalnotationbeingdevelopedfor BETA is just an alternative syntaxfor the sameunderlyingabstractlan-guage.Thegraphicalnotationandthetextualnotationaretwo alternativerep-resentationsof thesamelanguage.It is thereforepossibleto developa CASEtool/editor4 thatmakesit possibleto alternatebetweenusingthegraphicalno-tationandthetextual notation.It is easyto generatethetextual notationfromthegraphicalnotation,andviceversa.

Theproblemswith CASEtoolsaretypical for CASEtoolsbasedonstruc-turedanalysis/structureddesign.Thereasonis thatthereis amajorshift in lan-guagebetweenanalysis,designandimplementation.For CASEtoolsbasedonanobject-orientedapproachtheproblemis in generallessobvious.It is, how-ever, oftenthecasethattherearedifferencesbetweentheCASElanguageandtheprogramminglanguage.TheBETA approachis that thesameunderlying(abstract)languageshouldbe usedfor analysis,designandimplementation.Thiswill make it easierto alternatebetweenanalysis,designandimplementa-tion.

18.9 Elementsof a method

In this sectionwe summarizesomeof the important tasksinvolved in anobject-orientedapproach.Note that this is not intendedto be a fully-fledged

4Sucha CASEtool/editoris currentlybeingdevelopedfor theMjølnerBETA System.

18.9 ELEMENTSOFA METHOD 309

method,� sincetherearemoreelementsof a methodthanpresentedhere.Ac-cording to (Andersenet al., 1986), a methodis characterizedby applicationarea,perspective(s)(e.g. language),andguidelines,i.e. techniques,toolsandprinciplesof organization.

The approachpresentedin this chapterconsistsof creatinga physicalmodel (called the model system)of part of reality (called the referentsys-tem). The systemdevelopmentprocess,which is the processof creatingamodelsystem,hastraditionallybeenorganizedinto analysis,designandim-plementation.Theanalysisphaseis primarily concernedwith understandingthe problemdomain;the designphaseis concernedwith constructionof thephysicalmodel; implementationis concernedwith realizingthis modelon acomputer.

Theconceptualframework presentedin theprevioussectionsmaybeap-plied to all threephases.Eachphaserepresentsthreedifferentdomains:thedomainof thereferentsystemis thephenomenaandconceptsof theapplica-tion domain;thedomainof themodelsystemis thephenomenaandconceptsof themodel,i.e. therepresentativeobjectsandpatterns;thedomainof theim-plementationaretheobjectsandpatternsusedto implementthemodel.Thus,onemain differencebetweenthe threephasesis the domain;anotheris thedegreeof formality, asweshallseebelow.

The separationof the systemdevelopmentprocessinto analysis,designand implementationis not a sequentialorganizationin the sensethat phaseoneis analysis,phasetwo is designandphasethreeis implementation.Oftenthesephasesarecompletelyintermixed,andit maybedifficult to distinguishbetweenthem.Many developersarenotevenawareof whetherthey aredoingoneor the other. In practiceit is very difficult to do analysiswithout doingsomedesign,andsimilarly doingdesignwithoutdoingsomeimplementation.Thesystemdevelopmentprocessis evolutionarywith respectto analysis,de-sign andimplementation.Oneimplicationof this could be that it is perhapsnotusefulto distinguishbetweenanalysis,designandimplementation.Belowwearguethatthis is in factuseful.

18.9.1 General approach

The BETA languageandassociatedconceptualframework is to variousde-greesusefulfor analysis,designandimplementation.In this sectionwe sum-marizethe overall approachto all thesephases.In later sectionswe discusshow theapproachdiffersfor analysis,designandimplementation.

In thefollowing thedomaincanbethereferentsystem,themodelsystemor thecomputersystem.Within agivendomain,thefollowing stepsshouldbetaken.Again thestepsarenotsupposedto besequential,merelyachecklist:

(1) Select(relevant)phenomenaandconceptsfrom thedomainandselectthe(relevant)propertiesof thesephenomenaandconcepts.This includes:


(a) Selectthematerial(objects)of thedomain.

Thesectionof relevantpropertiesof thematerialincludesselectionof:

(b) Measurableproperties.

(c) Possiblephysicalpartsof thematerial,i.e. whole-partcomposition.

(d) Possiblereferenceattributes,i.e. referencecomposition.

(e) Possiblelocal concepts:procedurepatterns,classpatterns,etc.,i.e.localization.

(f) Possiblenon-localconceptsusedfor describingproperties,i.e. con-ceptcomposition.

(g) Classificationof objectsaseitheractiveor passive.

For activeobjectsdescribetheaction-sequencesthey perform.Thisincludestheir participationinto concurrentaction sequenceswithotherobjects,andtheir involvementin alternatingactionsequences.

(2) Selectconcepts.Describeconceptsasprototypical,Aristotelian,etc.De-scribetheintensionof theconcepts.

(3) Selectrelationsbetweenphenomenaandconcepts.

It must be decidedwhethera relation is one-to-one,one-to-many ormany-to-many, andwhethera relationshouldberepresentedby apatternor just by meansof referenceattributes.

(4) Determineclassificationhierarchies,includingclusteringandgeneraliza-tion/specialization.It mustbeconsideredwhich of theclassificationhi-erarchiesaresingle/treestructuredandwhich aremultiple, andwhetherthereshouldbe several alternative classificationsof the samephenom-ena/concepts.

(5) Determinecompositionhierarchies.

The compositionhierarchiessuchaswhole-partcomposition,referencecomposition,localizationandconceptcompositionshouldbedetermined.

18.9.2 Analysis

Theanalysisphaseis primarily concernedwith understandingtheproblemdo-main,i.e. thereferentsystem.Thedomainreferredto in thegeneralapproachis thusthereferentsystem.We arethereforeconcernedwith theselectionofrelevantphenomenaandconceptsfrom thereferentsystem.

In this phaseit is importantthatthedeveloperis not restrictedto the(for-mal) mechanismof a programminglanguagelike BETA. This alsoappliestoany otherformal languageproposedfor analysisincludingthemany proposals

18.9 ELEMENTSOFA METHOD 311

for a graphical� notation. If the developeris restrictedto the useof a formalnotationthismayimposetoonarrow aview onthereferentsystem.Thedevel-opershouldmake useof any meansavailablewhendoinganalysis,includinginformal descriptions,graphicsand the conceptualframework presentedinthis chapter.

Prototypicalconceptsmay be useful for understandingthe problemdo-main. Problem-specificconceptsare often prototypical. BETA (and otherprogramminglanguages)is primarily suitedfor representingAristoteliancon-cepts.It is possibleto useapseudoformalnotationfor describingprototypicalconcepts.Suchadescriptionwill oftenincludeanEnglishdescription.

The realizedconceptsin the model have to be Aristotelian. Part of themodeling function is thus concernedwith giving prototypical conceptsanAristotelianinterpretation.This will often make the resultingcomputersys-temappearinflexible to theuser. It is importantthatthedeveloperis notforcedto useAristotelianconceptsat too early a stagein the developmentprocess.In addition,it is usefulto beawareof conceptsthatarebestdescribedaspro-totypical,but have beentransformedinto anAristotelianconcept.Of course,thedevelopershouldmakeuseof Aristotelianconceptswheneverpossible.

A major characteristicof analysisis that it may be necessaryto relax onthe formal notationprovided by the language.Examplesinclude the useofprototypicalconcepts,anddescribingalternative classificationsandmultipleinheritance.Thedevelopershouldhavetheability to extendthelanguageto atleastinformally describethedesiredaspectsof thereferentsystem.

18.9.3 Design

Thedesignphaseis concernedwith theconstructionof a physicalmodelthatcan be refinedinto an executableprogram. The domainreferredto in thegeneralapproachis thustheobjectsandpatternsof themodel.

The(possiblyinformal)descriptionsof phenomenaandconceptsidentifiedduring analysishave to be transformedinto formal descriptionsin termsofobjectsandpatterns,includinggiving Aristoteliandefinitionsof prototypicalconcepts.

As canbe seen,the programmingprocessis facedwith the problemthatnot only do we restricttherealismof our modelby only consideringa partoftheworld,but equallyimportant,themodelingprocesshasto takeinto accounttherestrictionsimposedby modelingapossibleprototypicalconceptstructurein thereferentsysteminto anAristotelianconceptstructurein themodelsys-tem. In general,theexpressivenessis limited by thelanguageusedto describethemodel.Otherexamplesof this includethesupportfor classificationhierar-chies:it maybenecessaryto transformmultipleclassificationhierarchiesintosinglehierarchies,or into theparticularinterpretationof multiple inheritancein theprogramminglanguage,just asit maybeawkwardto representseveral


classifications.A largepartof designmaybeto inventnew thingsandconcepts.Remem-

berthatthemodelsystemis aphysicalmodelsimulatingthebehavior of eithera realor imaginarypartof theworld. The imaginaryparthasto be inventedduringdesign:thenew phenomenaandconceptsmusthave a meaningin thereferentsystem.

Theformalnotationcanbeaprogramminglanguageor agraphicaldesignlanguage.If BETA is useda mixture of graphicalandtextual syntaxcanbeused.In thedesignphaseit is importantto rememberthat thewholedescrip-tion/specificationmustberepresentativewith respectto thereferencesystem.A designdescriptionin BETA will thusbea fairly abstractprogram.

Designmay also involve the designof a userinterface. It is outsidethescopeof this book to discussthe designof userinterfaces. The generalap-proachof an object-orienteduserinterfaceis that representative elementsofthemodelshouldhave a representationon thescreen.Theusershouldhave afeelingof manipulatingthephysicalmodeldirectly. Of course,only selectedpartsof themodelmayberepresentedat any giventime, but theusershouldbeableto navigatein themodel.

Duringdesignit maybeusefulto constructscenariosand/orprototypesofthesystem.Thelatterwill involve implementation.

At somepoint during designit may be necessaryto make a requirementspecification,andin sucha specificationit shouldbe possibleto usepart ofthedesign.Selectedobjectsandtheir attributes,classpatterns,procedurepat-terns,etc., classificationhierarchiesand compositionhierarchiesshouldberelatively easyto presentfor theusers.Theform of thepresentationmaybeamixtureof diagrams,programtext andEnglishdescriptions,dependingonthebackgroundof theuser.

18.10 EXERCISES 313

18.9.4 Implementation

Herethedomainof thegeneralapproachis thecomputersystem.Phenomenaandconceptsaretheobjectsandpatternsnecessaryto implementthedesign.In the implementationphasethe designdescriptionis refinedinto an imple-mentationthatcanbeexecuted.It is very importantto makeaclearseparationof representableandnon-representablepartsof thedescription.

18.10 Exercises

(1) Developasetof conceptsthatcapturewhatyouconsiderto betheessen-tial propertiesof a restaurant.

(a) Developageneralizationhierarchywith conceptsthataremoregen-eralthanRestaurantandconceptsthataremorespecialthanRestau-rant.

(b) Developacompositionhierarchy. Identifypossibleparts,referencesandconceptsof arestaurant.Identify possibleconcepts/phenomenawherea restaurantmaybeacomponent.

(c) Identify oneor morephenomenain theextensionsof theconcepts.

(d) Describetheintensionof thedevelopedconcepts.Describedefiningandcharacteristicpropertiesof theconcepts.

(e) Are thedevelopedconceptsAristotelianor prototypical?

(f) Identify substance,measurablepropertiesandtransformations.

(g) Try to modeltheprocessof servingacustomerin a restaurant.Thismay includeconceptslike ‘customer’, ‘table’, ‘waiter.’ It may in-cludeactionslike ‘get a table’, ‘get a menu’,‘order food’ and‘paythe bill.’ For eachobject in your model, identify which of its at-tributesaremeasurableproperties,partobjects,referencesto sepa-rateobjectsandlocal concepts.

(h) Include modelingof the restaurant’s food preparationprocessaswell.

(i) For which type of applicationsare the conceptsuseful? For cus-tomersusingrestaurants,for theownerof a restaurant,for thecityadministration,etc.?

18.11 Notes

Someauthorsusethe term paradigm insteadof perspective as usedin thisbook, i.e. termslike the object-orientedparadigmand functional paradigm


are usedinsteadof object-orientedperspective and functional perspective.(NygaardandSørgaard,1987) argue that accordingto Kuhn, paradigmsaredefinedto dealwith majorshiftsin understandingwithin science,which is notthecasewith for examplethedifferencebetweenfunctionalprogrammingandobject-orientedprogramming. Object-orientedprogrammingand functionalprogrammingmayoftenbothbeusedin thesameprogram.

Various authorsuse different words for classificationand composition.Someof the terms like classificationand compositionand their more spe-cial variants– clustering,generalization/specialization,whole-partcomposi-tion, referencecomposition,localization,conceptcomposition– arewidelyaccepted,whereasothersarenot. Thetermclassificationis generallyacceptedalthoughsomeauthorsuseclassificationfor what hasbeencalledclusteringhere.Thetermgeneralization/specializationis widely accepted,with thesamemeaningashere.It is moreproblematicwith termsfor composition:thetermaggregation is oftenusedinsteadof composition.However, thereis no com-monlyagreeddefinitionof aggregation.Mostauthorsdefineaggregationto bewhole-partcomposition.Othersdefineit to belocalizationor conceptcompo-sition. In (SmithandSmith,1977a) aggregationseemsto bedefinedsimilarlyto conceptcomposition.

Relationshavebeenanimportantaspectof databases,analysisanddesignfor many years.Theentity-relationshipmodelwasintroducedin (Chen,1976).Relationshave not playeda centralrole within object-orientedprogramming,but are included in most books on object-orienteddatabasesand object-orientedanalysisand design(see(Hughes,1991; CoadandYourdon,1990;CoadandYourdon,1991; Booch,1991; Rumbaughet al., 1991), and(Wirfs-Brock etal., 1991)).

Theconceptualframework presentedherehasbeeninfluencedby similardevelopmentswithin artificial intelligenceanddatabases(SmithandSmith,1977a; SmithandSmith,1977b). The developmentof aconceptualframework has been an important part of the developmentofBETA. It doesnot seemto have playeda role in the developmentof otherobject-orientedlanguages.It is, however, of major importancein theareaofobject-orientedanalysis,modelinganddesign,aspresented,in for example,(Booch, 1991; Coadand Yourdon,1990; Coadand Yourdon,1991; Shlaerand Mellor, 1988; Rumbaughet al., 1991; Wirfs-Brock et al., 1991). TheBETA approachis, however, that analysis,designandprogrammingshouldnotbeconsideredasdifferentissues:it is all programmingatdifferentabstrac-tion levels.Theconceptualframework presentedhereis heavily influencedby(KnudsenandThomsen,1985). Theuseof characteristicpropertiesfor Aris-totelianconceptsis discussedin (FaberandKrukow, 1990). The processofknowledgeis from (Mathiassen,1981),but originatesfrom Karl Marx.

Object-orientedCASEfor BETA is discussedin (Sandvad,1990).

Appendix A

Grammar for BETA

Thisappendixdescribesagrammarfor theimplementedsubsetof BETA. Thegrammarformalismusedin theMjølnerBETA Systemis avariantof context-freegrammars.A structuredcontext-freegrammaris a context-freegrammar(CFG)wheretherules(productions)satisfya certainstructure.Eachnonter-minal mustbedefinedby exactlyoneof thefollowing rules:

1. An alternationrule hasthefollowing form:

<A0> ::| <A1> | <A2> | ... | <An>

where<A0>, <A1>, ...,<An> arenonterminalsymbols.Therulespecifiesthat<A0> derivesoneof <A1>, <A2>, ..., or <An>.

2. A constructorrule hasthefollowing form:

<A0> ::= w0 <t1:A1> w1 ... <tn:An> wn

where<A0>, <t1:A1> , ..., <tn:An> arenonterminalsymbolsandw0,w1, ..., wn arepossiblyemptystringsof terminalsymbols.This ruledescribesthat<A0> derivesthestring:

w0 <A1> w1 ... <An> wn

A nonterminalon theright sideof therule hastheform <t:A> wheretis a tag-nameandA is thesyntacticcategory. Tag-namesareusedto dis-tinguishbetweennonterminalsbelongingto thesamesyntacticcategory,consequentlyall tag-namesin arulemustbedifferent.If notag-nameisprovidedthenthenameof thesyntacticcategory is usedasa tag-name.

3. A list rule hasoneof thefollowing forms:

<A> ::+ w<A> ::* w

315

316 GRAMMAR FORBETA

where is anonterminalandw is apossiblyemptystringof terminalsymbols.Thenonterminal<A> generatesa list of sseparatedby ws:

 w w ... w 

The +-rule specifiesthat at leastone elementis generated;the * -rulespecifiesthatthelist maybeempty.

4. An optionalrule hasthefollowing form:

<A> ::? 

where is a nonterminal. The nonterminal<A> may generatetheemptystringor .

There are four predefined nonterminal symbols named <NameDecl> ,<NameAppl> , <String> and<Const> . Thesenonterminalsarecalled lexem-symbols, andthey derive identifiers,character-stringsandintegerconstants.Alexem-symbolmayalsohavea tag-namelike<Title:NameAppl> .

Thestartsymbolof thegrammaris <BetaForm> , which mayderiveeitheran<ObjectDescriptor> , an<Attributes> or a<DoPart> . Thesenontermi-nalsarethosethatcanbeusedto definefragment-forms/slots,cf. Chapter17.

The grammar

<BetaForm> ::| <DescriptorForm>| <AttributesForm>

<DescriptorForm> ::= <ObjectDescriptor ><AttributesForm> ::= <Attributes><ObjectDescriptor> ::= <SuperPattenrOpt> <MainPart><MainPart> ::= (# <Attributes> <ActionPart> #)<Attributes> ::+ <AttributeDeclOpt> ;<SuperPattern> ::? <SuperPattern><SuperPattern> ::= <AttributeDenotatio n><AttributeDeclOpt> ::? <AttributeDecl>

GRAMMAR FORBETA 317

<AttributeDecl>� ::| <PatternDecl>| <SimpleDecl>| <RepetitionDecl>| <VirtualDecl>| <BindingDecl>| <FinalBindingDecl>| <VariablePatternDec l>

<PatternDecl> ::= <Names> : <ObjectDescriptor><SimpleDecl> ::= <Names> : <referenceSpecific at ion ><RepetitionDecl>::= <Names> : [ <index> ] <referenceSpecifica tio n><VirtualDecl> ::= <Names> :< <ObjectSpecificati on><BindingDecl> ::= <Names> :: < <ObjectSpecificatio n><FinalBindingDecl> ::= <Names> :: <ObjectSpecificatio n><VariablePatternDecl > ::= <Names> : ## <AttributeDenotatio n><referenceSpecificat io n> ::| <StaticItem>

| <DynamicItem>| <StaticComponent>| <DynamicComponent>

<StaticItem> ::= @ <ObjectSpecificat ion ><DynamicItem> ::= ˆ <AttributeDenotatio n><StaticComponent> ::= @ | <ObjectSpecificatio n><DynamicComponent> ::= ˆ | <AttributeDenotati on><ObjectSpecification > ::| <ObjectDescriptor>

| <AttributeDenotatio n><Index> ::| <SimpleIndex>

| <NamedIndex><NamedIndex> ::= <NameDcl> : <Evaluation><ActionPart> ::= <EnterPartOpt> <DoPartOpt> <ExitPartOpt><EnterPartOpt> ::? <EnterPart><DoPartOpt> ::? <DoPart><ExitPartOpt> ::? <ExitPart><EnterPart> ::= enter <Evaluation><DoPart> ::= do <Imperatives><ExitPart> ::= exit <Evaluation><Imperatives> ::+ <ImpOpt> ;<ImpOpt> ::? <Imp><Imp> ::| <LabelledImp>

| <LabelledCompoundI mp>| <ForImp>| <IfImp>| <LeaveImp>| <RestartImp>| <InnerImp>| <SuspendImp>| <Evaluation>

318 GRAMMAR FORBETA

<LabelledImp> ::= <NameDcl> : <Imp><LabelledCompoundIm p> ::= ( <NameDcl> <Imperatives> <NameDcl> )<ForImp> ::= (for <Index> repeat <Imperatives> for)<IfImp> ::= (if <Evaluation> <Alternatives> <ElsePartOpt> if)<Alternatives> ::+ <Alternative><Alternative> ::= <Selections> then <Imperatives><Selections>::+ <Selection><Selection> ::| <CaseSelection><CaseSelection> ::= // <evaluation><ElsePartOpt> ::? <ElsePart><ElsePart> ::= else <Imperatives><LeaveImp> ::= leave <NameApl><RestartImp> ::= restart <NameApl><InnerImp> ::= inner <NameAplOpt><NameAplOpt> ::? <NameApl><SuspendImp> ::= suspend<Evaluations> ::+ <Evaluation> ,<Evaluation> ::| <Expression>

| <AssignmentEvaluati on><AssignmentEvaluati on> ::= <Evaluation> -> <Transaction><Transaction> ::| <ObjectEvaluation>

| <ComputedObjectEva lu ati on>| <ObjectReference>| <EvalList>| <StructureReferenc e>

<ObjectEvaluation> ::| <InsertedItem>| <reference>

<Reference> ::| <ObjectDenotation>| <DynamicObjectGenera ti on>

<DynamicObjectGener ati on> ::| <DynamicItemGenerat ion >| <DynamicComponentGe ner ati on>

<InsertedItem> ::= <ObjectDescriptor><ObjectDenotation> ::= <AttributeDenotati on><ComputedObjectEval uat ion > ::= <ObjectEvaluation> !<ObjectReference> ::= <Reference> []<StructureReference > ::= <AttributeDenotatio n> ##<EvalList> ::= ( <Evaluations> )<DynamicItemGenerat ion > ::= & <ObjectSpecificatio n><DynamicComponentGe ner ati on> ::= & | <ObjectSpecificati on><AttributeDenotatio n>: :| <NameApl>

| <Remote>| <ComputedRemote>| <Indexed>| <ThisObject>

<Remote> ::= <AttributeDenotat ion > . <NameApl><ComputedRemote> ::= ( <Evaluations> ) . <NameApl>

GRAMMAR FORBETA 319

<Indexed> ::= <AttributeDenotation > [ <Evaluation> ]<ThisObject> ::= this ( <NameApl> )<Expression> ::| <RelationalExp> | <SimpleExp><RelationalExp>::| <EqExp> | <LtExp> | <LeExp>

| <GtExp> | <GeExp> | <NeExp><SimpleExp> ::| <AddExp> | <SignedTerm> | <Term><AddExp> ::| <PlusExp> | <MinusExp> | <OrExp><SignedTerm> ::| <unaryPlusExp> | <unaryMinusexp><Term> ::| <MulExp> | <Factor><MulExp> ::| <TimesExp> | <DivExp> | <ModExp> | <AndExp><EqExp> ::= <Operand1:SimpleExp > = <Operand2:SimpleEx p><LtExp> ::= <Operand1:SimpleExp > < <Operand2:SimpleEx p><LeExp> ::= <Operand1:SimpleExp > <= <Operand2:SimpleExp><GtExp> ::= <Operand1:SimpleExp > > <Operand2:SimpleEx p><GeExp> ::= <Operand1:SimpleExp > >= <Operand2:SimpleExp><NeExp> ::= <Operand1:SimpleExp > <> <Operand2:SimpleExp><PlusExp> ::= <SimpleExp> + <Term><MinusExp> ::= <SimpleExp> - <Term><OrExp> ::= <SimpleExp> or <Term><unaryPlusExp> ::= + <Term><unaryMinusExp> ::= - <Term><TimesExp> ::= <Term> * <Factor><DivExp> ::= <Term> div <Factor><ModExp> ::= <Term> mod <Factor><AndExp> ::= <Term> and <Factor><Factor> ::| <TextConst>

| <IntegerConst>| <NotExp>| <NoneExp>| <RepetitionSlice>| <Transaction>

<RepetitionSlice> ::= <AttributeDenotation >[ <Evaluation> : <Evaluation> ]

<notExp> ::= not <factor><noneExp> ::= none<Names> ::+ <NameDcl> ,<NameDcl> ::= <NameDecl><NameApl> ::= <NameAppl><SimpleEntry> ::? <TextConst><TextConst> ::= <String><IntegerConst> ::= <Const><SimpleIndex> ::= <Evaluation>

320 GRAMMAR FORBETA

Appendix B

The Mjølner BETA System

The Mjølner BETA System1 is a programmingenvironment for object-orientedprogramming,which includesan implementationof BETA. Infor-mationabouttheMjølner BETA Systemis availablefrom:

Mjølner InformaticsA/SScienceParkAarhus, Phone: +4570 2743 43Gustav Wiedsvej 10, Fax: +4570 2743 44DK-8000AarhusC, E-mail: [email protected] Web: www.mjolner.com

A freeversionof theMjølner BETA Systemis availablefrom Mjølner Infor-maticsA/S eitherasa CD or downloadablefrom www.mjolner.com .

1Theoriginal printing of this bookcontainsa descriptionof theMjølnerBETA Systemasof May 1993. The Mjølner BETA Systemhasundergoneextensive developmentsincethenandtheoriginalAppendixB is thereforeobsolete.

321

322 THE MJØLNERBETA SYSTEM

Bibliography

(AbelsonandSussmann,1985) G. Abelson, G.J. Sussmannwith J. Suss-mann.TheStructureandInterpretationof ComputerPrograms.Cam-bridgeMA: MIT Press,1985.

(Agesenetal., 1990) O. Agesen, S. Frølund, M.H. Olsen. Persistent andSharedObjectsin BETA. TechnicalReportIR-89, ComputerScienceDepartment,AarhusUniversity, 1990.

(Andersenetal., 1986) N. E. Andersen,F. Kensing,M. LassenJ. Lundin, L.Mathiassen,A. Munck-Madsen,P. Sørgaard.ProfessionalSystemDe-velopment.TekniskForlag,1986(in Danish).

(Atkinsonet al., 1990) M. Atkinson,F. Bancilhou,D.DeWitt, K. Dittrich, D.Maier, S. Zdonick. Object-OrientedDatabaseSystemManifesto.InDeductiveand Object-OrientedDatabases(W. Kim, J.M. Nicolas,eds.).Amsterdam:North-Holland,1990.

(Bertelsenet al., 1986) S. Bertelsen,S. Hvidbjerg, P. Sørensen.GraphicalProgrammingEnvironments– Applied to BETA. Masters thesis,ComputerScienceDepartment,AarhusUniversity, 1986.

(BlakeandCook,1987) E. Blake, S. Cook.On IncludingPart HierarchiesinObject-OrientedLanguages,with anImplementationin Smalltalk.InProc.Euro. Conf. Object-OrientedProgramming, Paris,France,July,1987(Lecture Notesin ComputerScience, Vol 276, Berlin: Springer-Verlag).

(Bobrow andStefik,1983) D.G. Bobrow, M. Stefik. The LOOPSManual.PaloAlto CA: XeroxCorporation,1983.

(Booch,1986) G. Booch.Object-OrientedDevelopment.IEEE Trans.Soft-wareEngineering, 12(2), 1986.

(Booch,1991) G. Booch. Object-OrientedDesign with Applications. NewYork NY: Benjamin/Cummings,1991.

323

324 BIBLIOGRAPHY

(BorningandIngalls,1981) A.H. Borning,D.H. Ingalls.A TypeDeclarationandInferenceSystemfor Smalltalk. Universityof Washington,1981.

(Brinch-Hansen,1975) P. Brinch-Hansen.TheProgrammingLanguageCon-currentPASCAL. IEEE Trans.Software Engineering, 1(2), 149-207,1975.

(Cannon,1982) H. Cannon. Flavors, A Non-Hierarchical Approach toObject-OrientedProgramming. Draft 1982.

(Chambers,1992) C. Chambers.Object-OrientedMulti-Methodsin Cecil. InProc. Euro. Conf. Object-OrientedProgramming, Utrecht, Nether-lands,June/July, 1992(Lecture Notesin ComputerScience, Vol 615,Berlin: Springer-Verlag).

(Chen,1976) P.P.SChen.TheEntity RelationshipModel: Towardsa UnifiedView of Data.ACM Trans.DatabaseSystems,1(1), 1976.

(CoadandYourdon,1990) P. Coad, E. Yourdon.Object-OrientedAnalysis.EnglewoodClif fs NY: Prentice-Hall/YourdonPress,1990.

(CoadandYourdon,1991) P. Coad,E.Yourdon.Object-OrientedDesign. En-glewoodClif fs NY: Prentice-Hall/YourdonPress,1991.

(Conway, 1963) M.E. Conway. Designof a SeparableTransition– DiagramCompiler. Comm.ACM, 6(7), 396-408,1963.

(Cook,1988) S.Cook.Impressionsof ECOOP’88.J. of Object-OrientedPro-gramming, 1(4), 1988.

(Cox,1984) B.R. Cox. Message/Object,An Evolutionary Change. IEEESOFTWARE,Jan.1984.

(Dahl andHoare,1972) Dahl O.-J., C.A.R Hoare. Hierarchical ProgramStructures.In Structured Programming(O-J. Dahl, E.W. Dijkstra,C.A.R.Hoare),AcademicPress,1972.

(Dahl et al., 1968) O.J.Dahl,B. Myrhaug,K. Nygaard.SIMULA67CommonBaseLanguage. NorwegianComputingCenter, Oslo,1968.

(Dahleet al., 1986) H.P. Dahle, M. Løfgren, O.L. Madsen,B. Magnusson.TheMjølner Project– A Highly EfficientProgrammingEnvironmentfor IndustrialUse.Mjølner reportno.1, Oslo,Malmø,Aarhus,Lund1986.

(DeRemerandKrohn,1976) F.L. DeRemer, H. Krohn. Programming-in-the-LargeversusProgramming-in-the-Small.IEEE Transactionson Soft-ware Engineering, 2(2), 80-86,1976.

BIBLIOGRAPHY 325

(Dijkstra,� 1968) E. W. Dijkstra. Co-operatingSequentialProcesses.In Pro-grammingLanguages (F. Genuys,ed.), New York NY: AcademicPress,1968.

(ECOOP1987–1992)ECOOP, EuropeanConferenceon Object-OrientedProgramming.ConferenceProceedings1987-92.Lecture Notes inComputerScience, Berlin: Springer-Verlag,1987–1992.

(Eiffel, 1989) ”Interactive SoftwareEngineeringInc.. Eiffel: The Language,Version2.2.SantaBarbara, CA,USA,1989.

(FaberandKrukow, 1990) L. Faber, L. Krukow. ThisTown is Big EnoughforMost of It – Modelling in OOP. Masters thesis,ComputerScienceDepartment,AarhusUniversity, 1990.

(Goldberg andRobson,1989) A. Goldberg, D. Robson.Smalltalk-80,TheLanguage and its Implementation. ReadingMA: Addison-Wesley,1989.

(Goodenough,1975) J.B. Goodenough.ExceptionHandling: Issuesand aProposedNotion.Comm.ACM, 18(12),436-49,1975.

(Griswold et al., 1981) R.E Griswold, D.R Hanson,J.T. Korb. GeneratorsinIcon. ACM Trans. on ProgrammingLanguages and Systems,3(2),144-61,1981.

(Grune,1977) D. Grune.A view of Coroutines.ACM SigplanNotices,75-81,July1977.

(Hanson,1981) HansonD.R.. Is Block StructureNecessary?.SoftwarePrac-tice andExperience, 11, 853-66,1981.

(Henry, 1987) R. Henry. BSI Modula-2WorkingGroup:CoroutinesandPro-cesses.TheModusQuarterly, 8, 1987.

(Hoare,1972) C. A. R. Hoare.Proofof Correctnessof DataRepresentation.ActaInformatica,4, 271-281,1972.

(Hoare,1978) C.A.R Hoare.CommunicatingSequentialProcesses.Comm.ACM, 21(8), 666-677,1978.

(Hoare,1981) C.A.RHoare.TheEmperor’sold Clothes.Comm.ACM, 24(2),75-83,1981.

(Holbæk-Hanssenet al., 1975) E. Holbæk-Hanssen,P. Handlykken, K. Ny-gaard.SystemDescriptionandtheDeltaLanguage. NorwegianCom-putingCenter, Publ.no 523,1975.

326 BIBLIOGRAPHY

(Holbæk-Hanssenet al., 1981) P. Handlykken,K. Nygaard.TheDELTA Sys-tem DescriptionLanguage:Motivation, Main Conceptsand Expe-riencefrom use.In Software EngineeringEnvironments(H. Hunke,ed.).Amsterdam:North-Holland,1981.

(Horowitz, 1983) E. Horowitz. Fundamentalsof ProgrammingLanguages.Berlin: Springer-Verlag1983.

(Hughes,1991) J.G.Hughes.Object-OrientedDatabases. Englewood Clif fsNJ:Prentice-Hall,1991.

(Jackson,1983) M. Jackson.SystemDevelopment. Englewood Clif fs NJ:Prentice-Hall,1983.

(JensenandWirth, 1975) K. Jensen,N. Wirth. PascalUser Manual andRe-port. Berlin: Springer-Verlag,1975.

(KahnandMacQueen,1977) G. Kahn, D. MacQueen.Coroutinesand Net-worksof ParallelProcesses.InformationProcessing77, B. Gilchrist(ed.),993-998.Amsterdam:North-Holland,1977.

(Keene,1989) S.E.Keene.Object-OrientedProgrammingin COMMON L ISP

– A Programmer’s Guide to CLOS. ReadingMA: Addison-Wesley1989.

(KernighanandRitchie,1978) B.W. Kernighan,D.M Ritchie. The C Pro-grammingLanguage 2nd edn. Englewood Clif fs NJ: Prentice-Hall,1988.

(Kim et al., 1987) W. Kim, J. Banerjee,H.-T. Chou, J.F. Garza,D.Woelk.CompositeObjectSupportin an Object-OrientedDatabaseSystem.In Proc.Object-OrientedProgramming, Languages,SystemsandAp-plications,Orlando,FL, 1987,(ACM SigplanNotices, 22(12)).

(Knudsen,1984) J. L. Knudsen.ExceptionHandling – A Static Approach.SoftwarePracticeandExperience, 429-49,May 1984.

(Knudsen,1987) J. L. Knudsen. Better-Exception Handling in Block-StructuredSystems.IEEE Software, 40-49,May 1987.

(KnudsenandThomsen,1985) J.Lindskov KnudsenandK. StougardThom-sen.A ConceptualFramework for ProgrammingLanguages. DAIMIPB-192,AarhusUniversity, April 1985.

(Knudsenet al., 1989) J.L. Knudsen, O.L. Madsen,C. Nørgaard,L.B. Pe-tersen,E. Sandvad.An Overview of theMjølner BETA System. Com-puterScienceDepartment,AarhusUniversity, Draft, Dec.1989.

BIBLIOGRAPHY 327

(Knudsen� et al., 1990) J.L. Knudsen, O.L. Madsen,C. Nørgaard,L.B. Pe-tersen,E. Sandvad. TeachingObject-OrientedProgrammingUsingBETA. In Proc.AppleEuropeanUniversityConsortiumAnnualConf.,Salamanca,1990.

(Knudsenet al., 1992) J.L. Knudsen,M. Løfgren,O.L. Madsen,B. Magnus-son(eds.).Object-OrientedEnvironments– TheMjølner Approach.EnglewoodClif fs NJ: Prentice-Hall,1993.

(Kristensenet al., 1976) B.B. Kristensen,O.L. Madsen,B. Møller-Pedersen,K. Nygaard.BETA ProjectWorkingNotes1-8. NorwegianComputingCenter, Oslo andComputerScienceDepartment,AarhusUniversity,Aarhus,1976–1982.

(Kristensenet al., 1983a) B.B. Kristensen,O.L Madsen,B. Møller-Pedersen,K. Nygaard.SyntaxDirectedProgramModularization.In Interacti-veComputingSystems(P. Degano,E. Sandewall, eds.).Amsterdam:North-Holland,1983.

(Kristensenet al., 1983b) B.B. Kristensen, O.L. Madsen, B. Møller-Peder-sen,K. Nygaard.AbstractionMechanismsin theBETA ProgrammingLanguage.In Proc.10thACM Symp.Principlesof ProgrammingLan-guages,AustinTX, January24-261983.

(Kristensenet al., 1985) B.B. Kristensen,O.L. Madsen,B. Møller Pedersen,K. Nygaard.MultisequentialExecutionin the BETA ProgrammingLanguage.SigplanNotices,4(20),1985.

(Kristensenet al., 1987a) B.B. Kristensen, O.L. Madsen, B. Møller-Peder-sen,K. Nygaard.The BETA ProgrammingLanguage.In ResearchDirectionsin ObjectOrientedProgramming(B.D. Shriver, P.Wegner,eds.).Cambridge:MIT Press,1987.

(Kristensenet al., 1987b) B.B. Kristensen, O.L. Madsen, B. Møller-Pedersen,K. Nygaard.Classificationof Actions or Inheritancealsofor Methods.In Proc. Euro. Conf. Object-OrientedProgramming,Paris, France,June,1987 (Lecture Notesin ComputerScienceVol.276,Berlin: Springer-Verlag).

(Kristensenet al., 1988) B.B. Kristensen,O.L. Madsen,B. Møller-Pedersen,K. Nygaard.CoroutineSequencingin BETA. Hawaii InternationalConferenceon SystemSciences,21, January5-8,1988.

(KrogdahlandOlsen,1986) S. Krogdahl,K.A. Olsen.Modular andObject-OrientedProgramming.DataTid No. 9, Sept.1986(in Norwegian).

328 BIBLIOGRAPHY

(Lampsonet al., 1977) LampsonB.W. et al.. Report on the ProgrammingLanguageEuclid.SIGPLANNotices,12(2), 1977.

(Leler, 1987) W. Leler. Constraint Programming– Their SpecificationandGeneration. ReadingMA: Addison-Wesley, 1987.

(LindstromandSoffa,1981) G. Lindstrom,M. L. Soffa.ReferencingandRe-tentionin Block-StructuredCoroutines.ACM Trans.onProgrammingLanguagesandSystems,3(3), 263-292,1981.

(Liskov andZilles, 1974) B. Liskov, S. Zilles. Programmingwith AbstractDataTypes.ACM SigplanNotices,9(4), 50-59,1974.

(Liskov et al., 1977) B. Liskov, A. Snyder, R. Atkinson, C. Schaffert. Ab-stractionMechanismsin CLU. Comm.ACM, 20(8), 564-576,1977.

(Madsen,1987) O.L. Madsen.Block Structureand Object Oriented Lan-guages.In: Research Directionsin Object Oriented Programming(B.D. Shriver, P. Wegner, eds.).CambridgeMA: MIT Press,1987.

(MadsenandMøller-Pedersen,1988b) O.L. Madsen, B. Møller-Pedersen.WhatObject-OrientedProgrammingmaybe— andwhat it doesnothaveto be.In Proc.Euro. Conf. Object-OrientedProgramming, Oslo,Norway, August,1988(Lecture Notesin ComputerScienceVol 322,Berlin: Springer-Verlag).

(MadsenandMøller-Pedersen,1989a) O.L. Madsen, B. Møller-Pedersen.Basic Principlesof the BETA ProgrammingLanguage.In Object-OrientedProgrammingSystems(G. Blair, D. Hutchinson,D. Shep-hard,eds.).London:PitmanPublishing,1989.

(MadsenandMøller-Pedersen,1989b) O.L. Madsen, B. Møller-Pedersen.Virtual Classes— A Powerful Mechanismin Object-OrientedPro-gramming.In Proc. Object-OrientedProgramming, Languages,Sys-temsand Applications,New Orleans,LS, 1989, (ACM SigplanNo-tices, 24(10)).

(MadsenandMøller-Pedersen,1992) O.L. MadsenB. Møller-Pedersen.PartObjectsandtheirLocation.Technologyof Object-OrientedLanguagesandSystems— TOOLS7, Dortmund.EnglewoodClif fs NJ:Prentice-Hall 1992.

(Madsenetal., 1983) O.L. Madsen,B. Møller-Pedersen,K. Nygaard.FromSIMULA 67 to BETA. In Proc.11thSIMULA67 User’s Conf., Paris1983.NorwegianComputingCenter, 1983.

BIBLIOGRAPHY 329

(Madsen� et al., 1990) O.L. Madsen, B. Magnusson,B. Møller-Pedersen.Strong Typing of Object-OrientedLanguagesRevisited. In Proc.Object-OrientedProgramming, Languages, Systemsand Applica-tions,Ottawa,Canada,1990,(ACM SigplanNotices, 25(10)).

(Marlin, 1980) C.D. Marlin. Coroutines– A ProgrammingMethodology, aLanguageDesignandanImplementation.LectureNotesin ComputerScience, Vol 95.Berlin: Springer-Verlag,1980.

(Mathiassen,1981) L. Mathiassen.SystemsDevelopmentand SystemsDe-velopmentMethods(in Danish).Ph.D.thesis.Instituteof Informatics,OsloUniversity, 1981.

(Meyer, 1987a) B. Meyer. Genericity versusInheritance.In Proc. Object-OrientedProgramming, Languages,SystemsandApplications, Port-land,OR,1986,(ACM SigplanNotices, 21(11)).

(Meyer, 1987b) B. Meyer. Reusability:TheCasefor Object-OrientedDesign.IEEESoftware, 2(4), March1987.

(Meyer, 1988) B. Meyer. Object-OrientedSoftwareConstruction. EnglewoodClif fs NJ:Prentice-Hall,1988.

(Møller-Pedersenet al., 1987) B. Møller-Pedersen,D. Belsnes,H.P. Dahle.RationaleandTutorial on OSDL: An Object-OrientedExtensionofSDL. ComputerNetworks& ISDNSystems,13, 97-117,1987.

(Naur, 1962) P. Naur (ed.). Revised Report on The Algorithmic LanguageALGOL 60.Regnecentralen.Copenhagen,1962.

(Nygaard,1986) K. Nygaard.Basic Conceptsin Object OrientedProgram-ming.ACM SigplanNotices,21(10),1986.

(NygaardandDahl,1981) K. Nygaard, O.-J. Dahl. Simula 67. In Historyof ProgrammingLanguages (R.W. Wexelblat, ed.). ReadingMA:Addison-Wesley, 1981.

(NygaardandSørgaard,1987) K. Nygaard, P. Sørgaard. The PerspectiveConceptin Informatics.In Computers and Democracy – A Scandi-navianChallenge (G. Bjerkness,P. Ehn, M. Kyng, eds.).Aldershot:Gower, 1987.

(OOPSLA1986–1992)OOPSLA, Object-OrientedProgrammingSystems,Languagesand Applications.ConferenceProceedings,1986–1992.ACM SigplanNotices.

330 BIBLIOGRAPHY

(RajandLevy, 1989) R.K. Raj,H.M. Levy. A compositionalModel for Soft-wareReuse.In Proc.Euro.Conf. Object-OrientedProgramming, Not-tingham, England,July, 1989 (BCS WorkshopSeries, Cambridge:CUP).

(ReesandClinger, 1986) J.ReesandW. Clinger(ed.).RevisedReporton theAlgorithmicLanguageScheme. MIT, TR no.174,August1986.

(Rumbaughet al., 1991) J.Rumgaugh,M. Blaha,W. Premerlani,F. Eddy, W.Lorensen.Object-OrientedModelingand Design. Englewood Clif fsNJ:Prentice-Hall,1991.

(Sakkinen,1989) M. Sakkinen.DisciplinedInheritance.In Proc.Euro. Conf.Object-OrientedProgramming, Nottingham, England, July, 1989(BCSWorkshopSeries,Cambridge:CUP).

(Sandvad,1990) E. Sandvad. Object-OrientedDevelopment– IntegratingAnalysis,DesignandImplementation. ComputerScienceDepartment,DAIMI PB-302,April 1990.

(ShlaerandMellor, 1988) S. Shlaer and S.J. Mellor. Object-OrientedSys-temsAnalysis– Modelingthe World in Data. Englewood Clif fs NJ:Prentice-Hall/YourdonPress,1988.

(ShriverandWegner, 1987) B. Shriver, P. Wegner(eds.).Research Directionsin Object-OrientedLanguages. Cambridge:MA: MIT Press,1987.

(Smith,1984) B. Smith.PersonalCommunication.Stanford 1984.

(SmithandSmith,1977a) J.M. SmithandD.C.P. Smith.DataBaseAbstrac-tions: Aggregation.Comm.ACM, 20(6), 396-404,1977.

(SmithandSmith,1977b) J.M. Smith and D.C.P. Smith. Data Base Ab-stractions: Aggregation and Generalization.ACM TransactionsonDatabaseSystems,2(2), 105-133,1977.

(StefikandBobrow, 1984) M. Stefik, D.G. Bobrow. Object-OrientedPro-gramming:ThemesandVariations.AI Magazine, 6(4), 40-62,1984.

(Stroustrup,1991) B. Stroustrup.TheC++ ProgrammingLanguage2ndedn.ReadingMA: Addison-Wesley, 1986.

(SwedishStandard,1987) SwedishStandard.Data Processing– Program-ming Languages– SIMULA. SwedishStandard SS63 61 14, ISBN91-7162-234-9,1987.

BIBLIOGRAPHY 331

(Sørgaard,� 1988) P. Sørgaard.Object-OrientedProgrammingand Comput-erisedSharedMaterial. In Proc. Euro. Conf. Object-OrientedPro-gramming, Oslo,Norway, August,1988(Lecture Notesin ComputerScience, Vol 322,Berlin: Springer-Verlag).

(Tennent,1977) R.D.Tennent.LanguageDesignMethodsbasedonSemanticPrinciples.ActaInformatica,8(2), 97-112,1977.

(Tennent,1982) R.D.Tennent.TwoExamplesof BlockStructuring.Software-PracticeandExperience, 12, 385-392,1982.

(Thomsen,1987) K.S. Thomsen.Inheritanceon Processes,Exemplified onDistributedTerminationDetection.InternationalJournal of ParallelProgramming, 16(1), 17-52,1987.

(UngarandSmith,1987) D. Ungar, R.B. Smith. SELF: The Power of Sim-plicity. In Proc. Object-OrientedProgramming, Languages,SystemsandApplications,Orlando,FL, 1987,(ACM SigplanNotices, 22(12)).

(USDepartmentof Defense,1980) Ada ReferenceManual . ProposedStan-dardDocument.UnitedStatesDepartmentof Defense,July1980.

(Vaucher, 1975) J. Vaucher. Prefixed Procedures:A StructuringConceptforOperations.Infor, 13(3), 1975.

(WangandDahl,1971) A. Wang, O.-J. Dahl. Coroutine Sequencingin aBlock StructuredEnvironment.BIT, 11, 425-449,1971.

(Wang,1982) A. Wang.CoroutineSequencingin Simula,Parts I-III . Norwe-gianComputingCenter, 1982.

(Wegner, 1983) P. Wegner. On theUnificationof DataandProgramAbstrac-tion in Ada. In Proc.10thACM Symp.on Principlesof ProgrammingLanguages,Austin,TX, 24-26January1983.

(Wegner, 1987) P. Wegner. Dimensionsof Object-BasedLanguage Design.Tech.ReportNo. CS-87-14,Brown University, 1987.

(Wikstrøm,1987) A. Wikstrøm. Functional ProgrammingUsing StandardML. EnglewoodClif fs NJ:Prentice-Hall,1987.

(Wirfs-Brocket al., 1991) R. Wirfs-Brock,B. Wilkerson,L. Wiener. Design-ing Object-OrientedSoftware. Englewood Clif fs NJ: Prentice-Hall,1990.

(Wirth, 1982) N. Wirth. Programmingin Modula-2. Berlin: Springer-Verlag,1982.

332 BIBLIOGRAPHY

(Wulf andShaw, 1973) W.A. Wulf, M. Shaw. Global VariablesConsideredHarmful.SigplanNotices,8, 28-34,1973.

Index

A-form 257abstractdatatype 271abstractphenomena 292abstractsuper-patterns 85,191abstraction 286

in model/referentsystem 286accept 210action-part 30,290activecomponent 184activeobject 184activestack 184actualprocedure 163actualtype 163aggregation 314alternating 179alternation 178,225alternationrule 315anonymouspattern 113anonymousprocedure 92applicationof aname 72arithmeticoverflow 239array seerepetition,52assignment 68attached 184attribute-part 29attributes 290

basicpatterns 42restrictions 43,97

BETA programexecution 290binding 110

virtual pattern 110blockstructure 74,127,145boolean 42

CASEgap 308CASEtools 307

char 42characteristicproperties 292class 39,41classpattern 39,41classification 145,296,297

hierarchies 296treestructured 298

classificationhierarchies 296classless 45clone 45,157cluster 297codepoint 180codesharing 125comment 27communicate 226communication 210component 75,179,183,290component-of 300compose 300composition 127,145,296

localization (block structure)302

reference 301whole-part 301

compositionhierarchies 296compoundsystems 201,215computedreference 67computedremotename 67concept 290,291conceptcomposition 302concretephenomena 292concurrency 201,225constant 155constructionmode 74,75constructorrule 315controlpatterns 93

333

334 INDEX

controlstructures 53coroutinesequencing 178

declaration 25virtual pattern 110

declarationof a name 72decompose 300default handler 242definingproperties 292design 4designation 19,291deterministic 178deterministicalternation 178directqualification 113directsub-pattern 99directsuper-pattern 99do-part 29,53domain 267dynamiccomponentreference 184dynamicobject 34,75dynamicreference 32,180

encapsulation 268enter-part 29

for sub-pattern 95entrypattern 207evaluation 53,68evaluation-imperative 54,68exception 237,242

raisinganexception 242exceptionhandler 242exceptionhandling 239

staticapproach 254exceptionoccurrence 237,242exceptionpropagation 245exemplify 297exit-part 29

for sub-pattern 95explicit sequencing 197extend 49extendeddescriptor 122extendedentity-relationshipmodel

304extension 19,291

extent 262

final binding 122for-imperative 55fork-imperative 202form 257formalprocedure 163formal type 163ForTo 102fragment 256,260fragmentlanguage 256fragmentlibrary 260fragmentname 260fragmentsystem 256fragment-dependency graph 279fragment-form 259fragment-group 259function 39functionpattern 39functionalstyle 170furtherbinding 122fuzzyview 293

generalization 298generalize 297generalizedsemaphore 204generator 179grammar-based 256

handler 242has-ref-to 301hierarchicalorganization 297higherorderprocedure 163higherorderprocedurepattern 169

identificationof phenomena 296identity 288if-imperative 56illusion of concurrency 179imperative 27implementation 4, 268implementationmodules 255implicit sequencing 197in concurrency 177in-line 76

INDEX 335

indivisible� 205informationhiding 268informationprocess 287inheritance 102,144initial values 43inner 90

shorthandnotation 94input parameters 29inserteditem 75insertedobject 75instancehandler 243instance-of 297integer 42intension 19,291–293interface 268interfacemodules 255is-local-to 302item 75,179,290

labeledimperative 58lazyevaluation 197leave- 58level

of abstraction 295of empiricalconcreteness 295of thoughtconcreteness 296

lexem-symbols 316list rule 315locality 135localization 127,145locationof apartobject 153

main-part 98of apattern 99of anobject 99of anobjectdescriptor 99

many-to-many 151,304measurableproperties 67,288measurement 68,288measurements 288modelsystem 286modeling 287module 163,255monitor 201,206

multi-sequentialexecution 178multipleactionsequences 178multipleassignment 53multiple inheritance 300multiplepartobjects 149mutuallydependenttypes 166

new 50no object 33nondeterminism 178,225nondeterministic 179nondeterministicalternation 178,

225NONE 33

object 23pattern-defined 25,30singular 24,30

objectkind 74,75objectpattern 96object-descriptor 23,28,30objects 290one-to-many 151,304one-to-one 150,303optionalrule 316origin part 261origin-chain 278outputparameters 29

package 163packageobjects 165paradigm 313partcomponents 183parthierarchy 301part-object 31,145,290part-of 301passeren 204pattern 30,290patternvariable 155pattern-definedobject 25,30persistent 6perspective 284phenomenagenerator 284phenomenon 290

336 INDEX

physicalmodel 2physicalstructure 6prefix 98prefix-pattern 98problem-specificconcepts 287procedure 39,40procedureinvocation 26,33procedurepattern 39,40process 193,297processgenerator 284processof knowledge 295processset 284program 27programexecution 289programmingprocess 45properties 289PrototypeAbstractionRelationProb-

lem 136prototypetheory 293prototype-based 45prototypes 293prototypicalview 293pureobject-orientedstyle 170

qualification 35,121virtual pattern 110

qualified 35,100qualifiedreference 85qualifyingpattern 35qualifyingvirtuals 124quasi-parallelsequencing 197

range 47readersandwriters 218real 42realworld apprehension 1realizedconcepts 287receiver 211reference 290,300

assignment 32attribute 31,145composition 145equality 58,65

referentsystem 286

relation 303oneway 150one/two way 303two way 150

relationaloperators 43remoteaccess 35remote-name 24rendezvous 201repetition

extend 49new 50range 47slice 50

representativeelement 305request 210restart-imperative 58restrictions 43,97resumed 185returnlink 180reusability 1, 255reverseengineering 308role 291run-timeerror 33

scope 73scoperules 136Self 45,161self reference 39semaphore 201,203sender 211sententialform 257separatelycompiled 256sequentialexecution 178sequentialordering 177sharedobject 203sharedresource 203singularobject 24,25,30singularpart-object 31singularphenomena 296singularstaticobject 31slice 50slots 258smoothtermination 250

INDEX 337

specification� modules 255specialrelations 303specialization 298specialize 298stabilityof design 1stateof aprogramexecution 27stateof anobject 27staticcomponentreferences 183staticcomponents 183staticobject 31,75staticreference 31streams 197structuralrelations 303structure 23,30structureobject 37structuredcontext-freegrammar 315sub-pattern 83,98,99substance 288super-pattern 83,98,99suspended 184,185symmetriccoroutine 191synchronized 177synchronizedexecutionof objects

209system 286,289,290systemperspective 289

taxonomy 296this(P) 39transformation 68,288transient 6type 39

value 68assignment 62equality 58,65

variablereference 32variants 256virtual classpattern 139virtual pattern 105

binding 110continuedextension 114declaration 110extension 110

furtherbinding 122virtual patternqualification 110virtual procedurepattern 106vrygeven 204

whole-partaction-sequences 146

whole-partcomposition 145

Documents

O L M Aarhus University B M Ericsson Research, Applied ...cs-exhibitions.uni-klu.ac.at/fileadmin/template/documents/text/betabook.pdf · The BETA project was initiated in 1976 as