COPYRIGHT AND CITATION CONSIDERATIONS FOR THIS THESIS/ DISSERTATION
o Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
o NonCommercial — You may not use the material for commercial purposes.
o ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.
How to cite this thesis
Surname, Initial(s). (2012) Title of the thesis or dissertation. PhD. (Chemistry)/ M.Sc. (Physics)/ M.A. (Philosophy)/M.Com. (Finance) etc. [Unpublished]: University of Johannesburg. Retrieved from: https://ujdigispace.uj.ac.za (Accessed: Date). ~~\O v. \jK~ OBJECT-ORIENTED PARALLEL PARADIGMS
by
CHRIS KYRIAKIDES
DISSERTATION
presented in fulfilment of the requirements of the Degree
MASTER OF SCIENCE
m
COMPUTER SCIENCE
in the
FACULlY OF NATURAL SCIENCE
at the
RAND AFRIKAANS UNIVERSIlY
SUPERVISOR: DR MARTIN OLIVIER Objed.orieDtecl ParaDeI Paradigms
Table of Contents
Synopsis __•.....• I' I ...... 11 I .. Opsomming I IF I ••• • I"" '" I f U
Preface " lIi.. I 111 II ....n II' II ..n ..... I ..lu..1t ill
Ackn.owIedgm.ents . .. II , In II' .. III .11111 vi
Problem Statement r II' I II n. "' • vii
1 Inttoduction Q I '11.11 al" ,...... • •••••••••• 2 1.1 Introduction to OOPP's Object Taxonomy __ 2 1.2 Introduction to Object-to-Processor Mapping __ 3 13 Introduction to the Manager-Employee Model 3 13.1 Fundamental concept of the Manager-Employee Approach 3 13.2 Dilemma of a Manager-free approach to mcorporatmg managerial duties 4 133 Approaches to representing Managers 4 1.4 Limitations on the current OOPP research 6 15 Suppo~ Languages and environments 7 1.6 Oblect-Onentation and Parallelism 7 1.7 Object Technology Classification 9 1.8 Summary 9 2 Introduction to Parallel Processing _ ....-...... U 2.1 Amdahl's Law 13 2.2 Flynn's Taxonomy 14 2.2.1 Processor Array Architecture 15 2.2.2 MIMD Computers 15 23 Developing Algorithms for MIMD Computers 16 23.1 Categorisation of MIMD Algorithms 16 23.1.1 Pipelined Algorithms 17 23.1.2 Partitioned Algorithms 17 23.13 Relaxation 18 23.2 Factors influencing Speedup 18 2.4 Correctness for Concurrent Processes 20 25 Process Communication and Synchronisation on MIMD Models 21 2.6 In support of Object-Oriented Parallelism 21 27 Summary: Parallel Processing 21 3 Object Technolog)'. Concepts 1.1 I...... 24 3.1 Object Technology Fundamentals 24 3.1.1 Object-Oriented Approach 25 3.1.2 Class-Based Approach 26 3.13 Object-Based Approach 26 3.2 Objects 26 3.2.1 Methods and Attributes 26 3.2.2 Private and Public parts 27 3.23 Operations Z7 3.2.4 Object Behaviour 28 33 Message Passing Protocol 28 33.1 Messages :...... 28 33.2 Methods 28 333 Signatures 29 33.4 Message Names 29 3.4 Classes and Instances 29 35 Object Relationships 30 3.6 Inheritance 32 3.6.1 Class/Static Inheritance 33 3.6.2 Dynamic Inheritance 35 3.63 Other Inheritance issues 36 3.7 Polymorphism 37
May 1994 C Kyriakides Page i Object-OrieDted Parallel Paradigms
3.7.1 Polymorphic Variables 38 3.7.2 Polymorphic Functions 38 3.7.3 Polymorphic Operators _...... 39 3.7.4 Polymorphic Messages _ 39 3.7.5 Inclusion Polymorphism _ 40 3.7.6 Polymorphism's role as an Abstraction Mechanism ._...... 40 3.8 Homogeneous models _...... 40 3.9 Encapsulation _ 41 3.10 Reusability _.. • 41 3.10.1 Dynamic and Static Instantiation ", " 41 3.10.2 Object Classes ~...... 42 3.10.3 Inheritance 42 3.10.4 Polymorphism ,. . 42 3.10.5 Generic Classes "...... 43 3.10.6 Object Types •. 43 3.11 Concurrency 44 3.11.1 Concurrency using passive Objects 45 3.11.2 Concurrency using message passing 45 3.12 Interaction Primitives based on Message Passing 46 3.13 Object M~agement ;...... 49 3.14 Ob~ect-Onented Databases ; 50 3.15 Object-Oriented Programming Environments 51 3.16 Conclusion: Object Technology Concepts 51
Obj~ 4 Technolog)" Methodologi.es , 11 1 _ S2 4.1 Data-Driven vs Responsibility-Driven Design 52 4.1.1 Data-Driven Design 53 4.1.2 Responsibili!y-Driven Design 53 4.1.2.1 The Client/Server Model 55 4.1.3 Comparing Responsibility-Driven and Data-Driven Design 56 4.1.4 Langu~e Support 57 4.1.4.1 Luniting Access to Variables 57 4.1.4.2 Limiting Access to Behaviour 57 4.1.5 Conclusion of Responsibility-Driven vs Data-Driven Design 57 4.1.6 Yourdon's OOA and Responsibility-Driven Design 58 4.2 The Law of Demeter 59 4.2.1 Basic Concept of the Law of Demeter 60 4.2.1.1 Formulation Options of the Law of Demeter 61 4.2.2 Advantages and Disadvantages 61 4.2.3 Conclusion on the Law of Demeter 62 I~...-.I ~ 5 Parallel Object-Oriented Concepts II • •• I 64 5.1 Design Considerations 66 5.2 We,gner's Granularity of Modules 71 5.3 Object Taxonomy 72 5.3.1 Unaddressed issues of the Object Taxonomy...... 76 5.3.2 Summary: Object Taxonomy 77 5.4 Object State and Method Coupling 79 5.5 Productivity and Workloads in computers 84 5.5.1 Summary: Productivity and Workloads 88
6 IndustJ-y' and De Facto Standards 111 111...... II "1'''1 III 9() 6.1 Industry Standards 90 6.1.1 OSI ;...... 90 6.1.2 Other Standards 91 6.1.3 ANSI C 92 6.1.4 Benefits of Standards 93 6.2 Object Technology Standards 93 6.2.1 Object Management Group (OMG) 94 6.2.1.1 Technical Objectives of the OMG 95 6.2.1.2 The OMG Object Model 101
May1994 C Kyriakides Page n Objed-OrieDted Parallel Paradigms
6.2.1.3 Object Management Architecture 102 6.2.1.4 ORB (Object Request Broker) ...... ••••.•••...•..•...... •...... 103 6.2.15 CORBA (Common Object Request Broker Architecture) 104 6.2.1.6 Object Services 105 6.2.1.7 Common Facilities 106 6.2.1.8 Application Objects ...... •...... •••...•.••.••..••...... •...... • 106 6.2.2 Committee for Advanced DBMS Function (CADF) 107 6.3 Conclusion: Industry and Technology Standards 108 7 Existing Models __ 11 I II' 11 II II .. 111 7.1 Simula Based Languages 117 7.1.1 Beta 118 7.1.2 Conclusion: Simula Based Languages 118 7.2 Smalltalk Based Languages ...... •••.•.••...... •....•••••.•_ 119 7.2.1 Smalltalk-SO 120 7.2.2 Smalltalk/V ...... •...... •.••..•••...... •..•....•.••_...... 120 7.2.3 Concurrent Smalltalk 121 7.2.4 Conclusion: Smalltalk Based Languages 121 7.3 C Based Languages ...... • 122 7.3.1 Objective-C 122 7.3.2 C+ + 123 7.3.3 PROCOL: PROtocol-constrained Concurrent Object Language 125 7.3.4 Conclusion: C Based Languages 128 7.4 LISP Based Languages 130 7.4.1 CWS 131 7.4.1.1 The Three Layers of CWS 132 7.4.1.2 Basic Concepts 132 7.4.1.3 Slots 133 7.4.1.4 Generic Functions and Methods 134 7.4.15 Initialisation 135 7.4.1.6 Inheritance ...... •..•..•.•...... •.. 135 7.4.2 CommonObjects 136 7.4.3 MITRE's Future Generation Computer Architectures Program 137 7.4.4 Conclusion: liSP Based Languages ...... •...... •...•....•..•.. 138 75 PROWG Based Languages 139 75.1 PROLOGIV 139 75.2 Concurrent Prolog : 141 75.2.1 Vulcan ...... •...... 144 75.3 SPOOL 145 75.4 Conclusion: PROWG Based Languages 146 7.6 Actor Based Languages 148 7.6.1 The Actor Model 149 7.6.1.1 Common Characteristics .•...... •...... •...... •...••...•..•... 149 7.6.1.2 Basic Concepts ...... •...... 150 7.6.1.3 Basic Commands ...... •...... 150 7.6.1.4 Primitive and Non-Primitive Actors ...... •...... •. 151 7.6.15 Message Passing Protocol 151 7.6.1.6 Delegation 152 7.6.1.7 Recursion and Communication 153 7.6.1.8 Guardians 154 7.6.1.9 Transactions ~...... •...... 154 7.6.1.10 RACE actors 155 7.6.1.11 Receptionists •...... •...... 156 7.6.2 ABCLll 156 7.6.2.1 Message Passing ...... •...... • 157 7.6.2.2 Project Teams and Project Leaders 160 7.6.3 Actl, Act2 and Act3 161 7.6.4 Conclusion: Actor Based Languages 162 7.7 Object-Oriented Databases (OODB) 165 7.7.1 Conclusion: Object-Oriented Databases 168 7.8 Other Models 171
C Kyriakides Page iii Objed-Oriented Parallel Paradigms
7.8.1 POOL-T 171 7.8.1.1 Conclusion: POOL-T 172 7.8.2 MACE 172 7.8.2.1 Conclusion: MACE •...... •...... •....••...... 173 7.8.3 Orient84/K 174 7.8.4 Emerald ·174 7.8.4.1 Conclusion: Emerald 175 7.8.5 Eiffel 176 7.8.5.1 Conclusion: Eiffel 177 7.8.6 Hybrid 178 7.8.6.1 Conclusion: Hybrid 178
8 Managers _...... rtf ,IIU ,. 1111' 11""""'''' 1111 ••1' 180 8.1 Analytically Induced Responsibilities ...... ••_...... 181 8.2 Managerial Responsibilities __ 182 8.2.1 Object-to-Processor Management _.__ 183 8.2.2 Resource Management 184 8.2.3 Unanswered Issues on Managerial Responsibilities 185 8.3 Synchronisation Models based on Message Passing 186 8.4 The Manager-Employee relationship •...... 186 8.4.1 Message Management 187 8.4.2 Direct vs Indirect Message Passing ...... •. 189 8.5 Special Managers 190 8.5.1 Special Communication Managers 191 8.5.1.1 Antivirus Managers 191 8.5.1.2 Data Compression Managers ...... •...... 193 8.5.2 Special Interface Managers 193 8.5.2.1 Special Interface Managers and NonObject-Oriented Resources 194 8.5.2.2 Managers for Specialised Resources 194 8.6 Networking Capabilities 195 8.7 Managers and Object Allocation 196 8.7.1 Two Tier Approach 197 8.7.2 Direct Inclusion Approach 198 8.8 Managerial responsibilities vs Employee responsibilities 198 8.9 Conclusion: Managers 199
9 Object~rieDted Parallel Paradigm (OOPP) __ 201 9.1 Brief Outline of the OOPP Approach 201 9.2 OOPP's Aims and Approach 203 9.3 Distinctive Features of OOPP 204 9.3.1 Object Taxonomy 204 9.3.2 Manager Objects ...... •....•...... ,...... 205 9.4 Fundamental Issues that prompted the development of oopp 205 9.5 Future Trends ...... •...... 207 9.5.1 Implications of Future Trends 208 9.6 OOPP's Challenge 210 9.7 OOPP's Proposal ...... •...... 215 9.7.1 Resource Usage Data ...... •...... 215 9.7.2 Resource Sets ...... •.... 216 9.7.3 Object CreatefDestroy 217 9.7.4 Manager-Employee Scenario 217 9.7.4.1 Hierarchical Structure of Model ...... •...... 217 9.7.4.2 Managerial Duties 218 9.7.4.3 Division of Managerial Duties 218 9.8 Summary: Object-Oriented Parallel Paradigm ...... •...... 219 10 OOpp· and COOP II I II 11...... I .. I 223 10.1 OOPP-scenario •...•...... •...... •...... 223 10.2 Unanswered OOPP and COOP issues 225 103 Summary: OOPP and coOP...... •...... 225
MayUM C Kyriakides Page iv Object-OrieDted Parallel Paradigms
11 A Brief Overvlew of M~ . --...... 1 I I" I II 227 11.1 The Two Tier Appro1;\ch ...;...... 227 11.2 The benefits of Indirect Message Passing within the Two-Tier Approach 228 113 Managers of OOPP-scenarios _ .._ 230 11.4 Is it possible to have more than Two-Tiers? _...... 230 11.5 How are the Tiers determined? _...... 232 11.6 How are the Tiers positioned? _...... 233 11.7 Are Managers Service Providers? 235 11.8 Unaddressed Issues •...... •...... •••...... •...... ••••...•.•••••__ 236 11.9 Conclusion: Overview of Managers 236
12 Supporting Pape.rs III." I•, III f 1111 238 U.1 MITRE's Future Generation Computer Architectures Program ._...... 238 U.1.1 Resource Management ...... ••....•••...... ••••...... ••••_ ••_...... 239 U.1.2 Object Number Management ...... ••...... •...... ••••••..•_...... 240 U.13 Garbage Collection 240 U.1.4 Unclear Issues of the MITRE Paper ...... •...... 241 U.2 Unanswered Issues 242 U.3 Summary: MITRE 242
13 Comparison between OOpp and other models - 11 ••••••••••• 1'" 243 13.1 OOPP and the MITRE model 243 13.1.1 Similarities 243 13.1.2 Differences 244 13.13 OOPP's additional features 246 13.1.4 Features introduced by the MITRE model 246 13.1.5 The Operating S~tem and Software Design 247 13.2 OOPP and Responsibility-Driven Design 251 133 OOPP and the Law of Demeter 251 13.4 OOPP and PROCOL 252 13.5 OOPP and Actors 253 13.6 OOPP and LISP 256 13.7 OOPP and PROLOG 257 13.8 Summary: Comparison between OOPP and other models 257
14 Conclusion --.....-.. II I II' ; . II ••••••••••••••••••11,•••••--.. 259 14.1 OOPP: A brief overview of concepts 259 14.2 Multi-Tier Approach 260 143 Research Papers 260 14.4 OOPP and Standards 260 14.5 OOPP and the OMG standard 261 14.6 Future Research 262 14.7 OOPP: The final chapter 265
Appendix A: Terminology ...... • ••••••• , •••••••••••••••••••••••• '" •I ••••••••• 266
References .11 . 281
Mayl994 C Kyrialddes Page v Synopsis Objed'()riented Parallel Paradigms
Synopsis
This report is primarily concerned with highlightingfmdings of a research recently undertaken towards completing the requirements for the MSc Degree of 1994 at the Rand Afrikaans University (RAU).
The research is aimed at striving to investigate what benefits (if any) exist in Object-Oriented Parallel Systems. The area of research revolves around the Object-Oriented Parallel Paradigm (OOPP) which is currently under development by the author. One primary aim of this research is to investigate numerous current trends in Object-Oriented Parallel Systems and Language Developments with the objective of providing an indication as to whether the Object-Oriented methodology can be (or has been) successfully married with existing Parallel Processing mechanisms. New benefits may come about while attempting to combine these methodologies, and this expectation will also be reflected upon.
The Object-Oriented methodology allows a system designer the ability to approach a problem with a good degree of problem space understanding; while Parallel Processing allows the system designer the ability to create extremely fast algorithms for solving problems amenable to Parallel Processing tech niques. The question we attempt to answer is whether the Object-Oriented methodology can be suc cessfully married to the Parallel Processing field (whilst maintaining a high degree of benefits encountered in both methodologies) so as to gain the best of both worlds. Certain papers have laid claim to their proposed system encompassing both the Object-Oriented methodology, as well as the Parallel Processing methodology. In view of this fact, we shall furthermore examine papers to see if any of these systems are candidates for successfully marrying Object-Oriented and Parallel Processing into one homogeneous body. Criticism will be given on the shortcomings of unsuccessful candidates.
Based on the findings of the research, the report will culminate to the proposal of the Object-Oriented Parallel Paradigm (OOPP). OOPP will speculate on the most probable features that system designers can expect to see in an almost ideal Object-Oriented Parallel System. It is very important at this stage to mention that, at its current state of development, OOPP is only a paradigm; thus OOPP should be viewed merely as an abstract model intended to establish a solid foundation for building more formal Object-Oriented Parallel Methodologies. Furthermore, OOPP is intended to be suitable for present day systems and amenable (possibly with a few minor adjustments) to future systems.
The author trusts oOPP to generate sufficient interest to warrant further research being commis sioned. In this event, oOPP should be expected to undergo modifications and enhancements.
May 1994 C Kyrialddes Page i Opsomming Objed-Oriented ParaDel Paradigms
Opsomming
Hierdie verhandeling ondersoek die konstruksie van objek-georienteerde parallelle stelsels. Die navorsing wentel om die Objek-georienteerde Parallelle Paradigma (OOPP) wat tans deur die skrywer ontwikkel word. Ben primBre doel van hierdie navorsing is om buidige neigings in objek georienteerde parallelle stelsels en taalontwikkelings te ondersoek om vas te stel of die objek georienteerde metodologie suksesvol saam met bestaande parallelle verwerkingsmeganismes gebruik kan word (of moontlik reeds gebruik word), met behoud van meeste van die voordele van beide metodologiee, Nuwe voordele mag voortspruit uit die kombinasie van hierdie twee metodologiee aandag word aan hierdie aspek gegee.
Die objek-georienteerde metodologie voorsien die vermoe aan 'n stelselontwerper om 'n probleem te benader met 'n groot mate van probleemruimteinsig; hierteenoor stel parallelle verwerking die stel selontwerper in staat om uiters vinnige algoritmes (vir geskikte probleme) te skep. Die vraag wat ons probeer antwoord is of hierdie twee metodologiee gekombineer kan word om die beste van beide wBrelde te kan kry. Sekere skrywers maak reeds die aanspraak dat stelsels deur bulle voorgestel beide metodologiee dele. Ons bespreek gevolgliksulke artikels om die sukses van die kombinasie, al dan me, te ondersoek. Kritiek ten opsigte van onsuksesvolle kandidate word gegee.
Die resultate van die navorsing word gebruik om die Objek-georienteerde Parallelle Paradigma (OOPP) voor te stel, OOPP spekuleer oor die mees waarskynlike eienskappe wat stelselontwerpers in 'n byna ideale objek-georienteerde parallelle stelsel kan verwag. Oit is belangrik om daarop te wys dat OOPP op hierdie stadium van ontwikkeling 'n paradigma (werkswyse) is; OOPP moet dus as 'n abstrakte model beskou word wat ten doel het om as fondament te dien vir meer formele objek georienteerde parallelle metodologiee. Verder is OOPP bedoel om geskik te wees vir huidige stelsels en om aanpasbaar te wees vir toekomstige stelsels.
Die outeur vertrou dat OOPP voldoende belangstelling sal genereer om verdere navorsing te regver dig. In so 'n geval hoop ons dat OOPP veranderings en verbeterings sal beleef.
May 1994 C Kyriakides Page ii Preface Objed-Oriented Parallel Paradigms
Preface
This research was undertaken with the customary set of academic research conditions; namely no funds, adverse working conditions, limited manpower and unsophisticated equipment. Wherever pos sible, the author has endeavoured to disclose the findings of the above-mentioned research in a light, easy-to-read style avoiding unnecessary complex statements.
As was agreed to by the instigators of this research, namely the Department of Computer Science, the research does not entail implementation, but instead concentrates primarily on extracts of relevant articles to substantiate and corroborate its arguments.
Based on the findings of the research, the Object-Oriented Parallel Paradigm (OOPP) is proposed by the author as a viable candidate for future Object-Oriented Parallel Systems. The report not only presents viable features for Object-Oriented Parallel Systems, but also evaluates the implication of their inclusion.
The advantages and disadvantages of the Object-Oriented Parallel Paradigm (OOPP) have been compared against those of other methodologies.
Since implementation has not been the focal point of the research, a comparison was made - between the Object-Oriented Parallel Paradigm (OOPP) and other relevant methodologies - based on analysis. Hence Object-Oriented Analysis (OOA) should be expected to playa prominent role in OOPP.
Numerous approaches to Object-Oriented Analyses exist. Unfortunately not all experts in the Object-Oriented field agree as to which is the best approach. With this in mind, OOPP was created primarily independent from any specific Object-Oriented Analysis. Instead, OOPP was created around the Object-Oriented concepts. It is hoped that, since OOPP is a paradigm, developing OOPP inde pendent from any specific Object-Oriented Analysis approach will result in an Object-Oriented Par allel paradigm that is adaptable (possibly with minor adjustments) to most Object-Oriented Analysis techniques.
For example, one approach to Object-Oriented Analysis is presented by Yourdon [1989]. Yourdon's concealed claim of Object-Oriented Analysis being a remedy to the prevailing ailments of all existing traditional forms of analysis was investigated. A different approach proposed by Wrrfs-Brock [1989] resulted in bringing to light some undesirable features present in Yourdon's approach. Nonetheless, Object-Oriented Analysis techniques were investigated for their validity relating to OOA's applicability to the Parallel Processing field.
May 1994 C Kyriakides Page iii Preface Object-Oriented ParaDeI Paradigms
Owing to the fact that implementation is not within the scope of intended research, analysis will be a predominant factor in indicating the feasibility of a proposed Object-Oriented Parallel project. Thus indicators will be provided pertaining to the suitability of a project being undertaken in the Object Oriented Parallel Methodology.
The report will enclose the provision of answers pertaining to the versatility and benefits of OOPP regarding its area of intended application, as well as, the faculties available in Object-Oriented Parallel Systems Development in support of maintainability and development. This will basically involve investigatingthe suitability of an Object-Oriented approach to the Parallel Systems development field, by attempting to combine the benefits of both methodologies into one single methodology.
Owing to the fact that (general-purpose) Object-Oriented Parallel Systems and Object-Oriented Analysis are reasonably new disciplines, references dealing explicitly with evaluating the merging of Object-Orientation and Parallel Processing are hard to come by. Furthermore, owing to the fact that these methodologies are both immature and not thoroughly explored, they may be undergoing an arbitrary transformation during the OOPP research. Thus, a temporary static point had to be super ficially established so as to avoid constant updates keeping the research in the prototype stage. The lack of specific references does not apply to Object-Oriented Programming and Design, and thus some of these references have been used as background material where applicable. It must be noted how ever that programming and design papers tend to be too implementation dependent and the analysis aspect of these papers is greatly diminished.
Many students reading this report will already have had experience with either Parallel Systems or Object-Oriented concepts, Object-Oriented Analysis and/or Object-Oriented Methodologies. Although it is recommended that the report be read in its entirety and in the order presented, not all readers have the same background knowledge. In view of this fact, chapter 2 titled Introduction to Parallel Processing may be skipped by readers having well-established knowledge of Parallel Processing. Likewise; chapter 3 Object Technology Concepts may be skipped by readers having thorough knowl edge of Object-Orientation. However, all chapters from chapter 4 to chapter 14 should be read in the order presented. In particular, the chapters dealing directly with OOPP are as follows: 1, 5, 8, 9, 10, 11,13,14.
Please note that, in this report, a number of words having special meaning (either in the field of Object-Orientation or Parallel Processing), are printed with a capital letter so as to make them stand out from other common words.
May 1994 C Kyriakides Page iv Preface ObJeet.()riented Parallel Paradigms
Chapter Setup
The general format of this report entails that a number of chapters (and some sections) are preceded by a short preamble based on that particular chapter (or section) intended in most cases to indicate (where applicable):
prerequisite chapters, sections and reading material -, a list of objectives identifying what will be learned by studying that chapter/section
what the contents of the chapter/section is leading towards, either in the current chapter or in subsequent chapters.
Each chapter ends with a summary that briefly recaps on what was covered.
Prerequisite Knowledge
The author has assumed that readers possess a minimum prerequisite knowledge of the fundamental concepts of Parallel and Object-Oriented Principles. In other words, this report should not be treated as a reader's first encounter with these principles and their terminology. However, in order to clarify and refresh the reader's mind to the proper meaning of the terminology used here, a few of the more commonly used terms have been explained in the terminology section.
The terminology section contains numerous brief descriptions of various terms used throughout the report. It is advisable for all persons not up-to-date with the Parallel and Object-Oriented principles and tenninology to browse through the terminology section prior to reading the report. A few of the terms will undoubtedly be repeated within the subsequent discussions. The reiteration of the defini tions will be done in order to allow for a continuous flow of ideas without the need of undesirable paging to the terminology section in order to recall what is meant by some phrase.
May 1994 C Kyriakides Page v Acknowledgments Objed.()riented Parallel Paradigms
Acknowledgments
In general, I wish to acknowledge the guidance and assistance of lecturers and colleagues that have provided valuable feedback on the Object-Oriented methodology over the last few years. In particular, I wish to acknowledge the skillful expertise and generous help of Martin Olivier of the Department of Computer Science at the Rand Afrikaans University.
Last but not least, the enduring support received from my parents, George and Chrystalla, without whom this would not have been possible.
May 1994 C Kyriakides Page vi Problern Statement Objed'()riented Parallel Paradigms
Problem Statement
The Object~Oriented Parallel Paradigm (OOPP) research is concerned with systems development of distributed heterogeneous systems enabling shared/cooperating processing across a multitude ofprocessing units and platforms.
This dissertation is concerned with proposing a paradigm - a way of approaching the development of a methodology. For this reason, in this dissertation oopp deals primarily with analysis aspects. As will be argued, a general-purpose paradigm/methodology should support a distinction between analytical responsibilities and implementation responsibilities. OOPP is shown to be capable of supporting such a distinction.
As a result of this research, we propose:
A neW concept depicting manager-employee relationships.
A new object taxonomy that primarily defines object processing relationships.
A notion of coupling based on state.
A neW approach to Object-to-Processor mapping algorithms.
A processor workload concept within the context of object technology.
Amongst others the following issues are addressed:
We investigate whether the manager-employee relationship can be used to provide an encapsula tion between the analytical responsibilities and the implementation responsibilities.
We determine the suitability of the proposed object taxonomy to express object processing rela tionships in sufficient detail so as to facilitate the formulation of object-to-processor mapping algorithms.
We argue that in order to optimise efficient usage of resources (software and hardware), efficient Object-tO-Processor mapping algorithms are required - in addition to other optimisations. These object-to-processor mapping algorithms should take into account processing/synchronisation rela tionships between different objects.
May:1994 C Kyriakides Page vii Problem Statement Object-Oriented Parallel Paradigms
We further argue that loosely-coupled (independent) objects are better suited to distributed con current processing than tightly-coupled (interdependent) objects. This can be attributed to the fact that loosely coupled objects exhibit greater encapsulation and information hiding.
Furthermore, we argue that an object's analytical responsibilities should not be tightly-coupled to an implementation responsibility.
Possibly the most significant contribution of our research lies in the development of a new concept called managers. We will show that a distinction exists between the analytical responsibilities of objects and the implementation responsibilities of objects. Currently under most object technologies no distinction is made nor supported between analytical and implementation responsibilities. The concept of managers allows system developers to abstract the implementation issues from the ana lytical issues of a problem. Nonetheless, we will furthermore show that in some cases, the imple mentation responsibilities of one problem space may be represented (either partly or fully) as analytical issues of another problem space.
Another significant contribution of our research lies in the development of a new object taxonomy. Primarily, the OOPP object taxonomy allows system developers to describe concurrent processing relationships between objects. This in turn also presents system developers (especially for CASE tools and methodologies) the ability (and starting point from which) to define and formulate object-to processor mapping algorithms.
We present processor workloads within the context of object technology. Balancing of processor workloads is one apparent viable contributor to the development of object-to-processor mapping algorithms. Nonetheless, further details on this topic will be left to future research efforts.
One of the difficulties of megaprogramming (programming in the large) is concerned with encapsu lating fragments of the entire system(s) into smaller and more easily manageable subsystems. Another problem that needs to be addressed is which paradigm(s) are feasible for synchronisation of processes that may reside in local or remote processors. Object technology allows us to do just that, firstly by enabling system developers to break down a larger problem into smaller highly encapsulated entities called objects, and secondly, by allowing synchronisation of processes by means of message passing. For this reason Object-Orientation has been chosen as the fundamental paradigm from which to develop a more general distributed processing paradigm.
May 1994 C Kyriakides Page viii Problem Statement Objed-Oriented Parallel Paradigms
1 Introduction
In this chapter we introduce the primary objectives of this research, namely to marry the Object-Oriented and Parallel Processing methodologies into one homogeneous body whilst main taining a great degree of benefits encountered in each area. In order to achieve our primary goal, secondary goals had to be addressed. The most noteworthy proposal of the OOPP research is the Manager-Employee model. Other proposals include: a new Object taxonomy, adapting Productivity and Workload concepts to computing, and Object-to-Processor mapping.
The scope of the research is based primarily on analysis rather than implementation. We fur thermore substantiate the inclusion of brief introductory chapters to the fields of Parallel Pro cessing and Object-Oriented concepts.
Wegner's [1988] classification is briefly presented. Where suitable, this classification will be used in subsequent chapters to indicate some differences between OOPP and other methodologies.
May 1994 C Kyriakides Page 1 Introduction Object-Oriented ParaDel Paradigms
1 Introduction
The Object-Oriented Parallel Paradigm (OOPP) presents an original approach to marrying Object-Orientation to Parallel Processing.
Below follows a brief list of proposals made by OOPP. After these points have been introduced below they will be briefly readdressed in the immediate paragraphs that follow in this chapter.
A new approach to Object-Oriented Parallel and Concurrent Processing.
The Manager-Employee model (chapters 8 and 11).
A new Object Taxonomy (section 53) catering for expressing concurrent features both internally within an Object and externally between two or more Objects.
Productivity and Workload concepts (section 55) within the context of object technology.
The need for efficient Object-to-Processor mapping algorithms.
1.1 Introduction to OOPP's Object Taxonomy
Inevitably, whenever attempting to tackle any new territories in our universe of knowledge, unforeseen obstacles may first have to be overcome in order for us to arrive at our anticipated goal. OOPP was no exception to the aforementioned. For instance, in order to present our para digm we first had to deviate our attention to creating a general-purpose Object Taxonomy. This general-purpose Object Taxonomy is concerned with providing terminology presenting the ability to fully describe candidates amenable to parallel processing techniques. A distinguishing feature of this taxonomy is that, in addition to availing a vehicle for comprehensive description of inherently sequential and concurrent candidates, it is also capable of distinguishing concurrency features between Objects, Classes, and even methods within an Object. In turn, this taxonomy served as a vehicle for presenting OOPP's approach to analysing candidates amenable to parallel processing techniques. After formulating these ideas within the context of the taxonomy, the issue of Object-to-Processor mapping became self-evident.
May 1994 C Kyriakides Page 2 Introduction Object.oriented Parallel Paradigms
1.2 Introduction to Object-to-Processor Mapping
An ideal Object-to-Processor mapping algorithm needs to meet the following conditions: maintain maximum concurrent processing throughput; minimise the number of processors required; and minimise the inter-processor communication costs. Alternatively, empirical Object-to-Processor mapping algorithms may be developed that are aimed at maintaining more or less equal processor workloads.
1.3 Introduction to the Manager-Employee Model
The Manager-Employee model depicts a relationship between two objects, where one object (called the Manager) manages another object (called the Employee).
The Manager-Employee model aims to accommodate encapsulation and/or separation of man agement related aspects from Objects (or portions of Objects) that do not require to directly contain these management capabilities. Instead, these management duties are encapsulated within Objects referred to as Managers. (Managers' duties will be defined in chapter 8). As a conse quence, by using the Manager-Employee model it is possible to maintain loose-coupling between implementation issues (encapsulated within Managers) and analytical issues (encapsulated within Employees).
1.3.1 Fundamental concept of the Manager-Employee Approach
All Objects within an OOPP model form an Object-Oriented hierarchy(ies). One of the strong analytical points of the Object-Oriented Approach is that Object instances belonging to a common Class will by default exhibit similar characteristics. A similar argument holds for Sub-Classes belonging to a common Super-Class.
Having understood the above similarity, the system developer can - during the Analysis stage - identify the managerial duties required by the various Employee Objects. These duties are then encapsulated/isolated into the appropriate Manager Objects. When a suitable Manager hierarchy is established, we can associate specific Manager types with specific Employee Object types.
Note that the Managers themselves form a hierarchy and similar analytical procedures hold in order to determine at which level in the hierarchy a particular managerial duty (and if appli cable, related data) is to be placed. For example, if an identical responsibility exists in all
May 1994 C Kyriakides Page 3 Introduction Object-Oriented ParaDel Paradigms
Sub-Classes belonging to a common Super-Class then that responsibility can be placed instead in the Super-Class. As a rule-of-thumb, a managerial duty should be matched to the highest Manager in the Object-Oriented hierarchy that this duty is suited to. A similar argument holds for Employee Objects.
1.3.2 Dilemma of a Manager-free approach to incorporating managerial duties
Not implementing the Manager-Employee approach to handling managerial duties, can result in managerial duties being spread amongst Objects in an ad hoc fashion. This will inevitably result, (if not in the initial model then during revised models or routine maintenance), in redundant copies of identical or minutely varying managerial duties. This redundancy will make revised versions progressively harder to maintain.
An even worse scenario can arise if multiple copies/versions of similar/identical managerial duties are placed within numerous Services of an Object.
1.3.3 Approaches to representing Managers
In theory, Managers can be represented by means of either the Direct-Inclusion Approach or the Two-Tier Approach, or both (these will be elaborated shortly).
Direct-Inclusion Managers
Some management duties may be required to be included within the individual Objects themselves. These managerial duties are then encapsulated within an individual Object, called a Manager, which is then incorporated within the larger Object, the Employee.
Under this scenario, Managers form an Object-Oriented hierarchy comprising of Manager types. The Managers exist as Objects contained within other Objects, the Employees. Man agers under this scenario should be limited to lower level managerial duties (e.g., monitoring and supervising inter-Object communication, exception handling routines, etc.)
May 1994 C Kyriakides Page 4 Introduction Object-Oriented ParaDeI Paradigms
Two-Tier Managers
" Using a two-tier approach, Managers are established that form an Object-Oriented hierarchy that is "separate" from the Employee Object-Oriented hierarchy. The Manager Objects are then mapped, either one-to-one and/or one-to-many, onto the Employee Objects and/or Employee Classes. Managers under this scenario can depict higher level managerial duties (e.g, interprocessor communication, virus detection, processor workload balancing, etc.).
Inheritance Relationship V""'" Manager-EmployeeRelationship
Inheritance Relationship
Tvvo-Tieri\pproach
Note that in the above diagram two types of relationship are depicted, namely an inheritance relationship and a manager-employee relationship. Furthermore the above diagram refers to classes. However, during implementation, it is the instances of Managers that manage one or more instances of the Employees. Furthermore, by default, an employee that is not explicitly shown as having a manager, is in fact managed by the same manager class that is managing the employee's superclass.
May 1994 C Kyriakides Page 5 Introduction Objed-Oriented Parallel Paradigms
In theory, the OOPP model can accommodate Managers either under the Direct-Inclusion Approach or the Two-Tier Approach, or both. From the above mentioned Direct-Inclusion Approach, it is immediately evident that it is unnatural to perceive Managers as part(s) of their Employees. Nonetheless further discussion is deferred to chapters 8 and 11 were it will be shown that, in practice, the Two-Tier approach manifests greater benefits and flexibility than the Direct-Inclusion Approach.
1.4 Limitations on the current OOPP research
Based on the cited material and the authors' humble abilities, OOPP attempts to present, within the context of currently available knowledge and experience, a viable easy to follow and apply paradigm. Wherever possible, the paradigm is presented in an easy to read fashion. As our com puting and analysis knowledge expands, both in horizon and depth, OOPP in its infancy (as presented here) will have to grow and adapt in order to keep pace with rapidly changing environments. With the aforementioned in mind, OOPP is presented as a paradigm rather than a methodology.
This report is not concerned with providing the ultimate methodology for Object-Oriented Parallel Processing. Instead, a more humble and viable goal is aimed at, namely to provide numerous fragments of a viable solution in attaining the principal portions of our goal. Where solutions are not presented, we attempt to at least identify and formulate the problems that need to be addressed.
An important point to be stated here is that, given the wide spectrum of the OOPP research, it is not viable within the given time period to investigate every existing and currently developing research effort pertaining directly and indirectly to this field of research; this entails most efforts and topics dealing with any Object-Oriented and/or any Parallel Processing issues. If no mention is made of a particular aspect of either Object-Oriented or Parallel Processing then it does not imply nor can it be inferred that our paradigm is incapable of catering for this feature; instead all that can be deduced is that the subject in question may not as yet have been taken into consid eration under our past and current research.
May 1994 C KyriaJdd8 Page 6 Introduction Object-Oriented ParaDel Paradigms
1.S Supporting Languages and environments
In its current format, OOPP is not fully supported by any of the currently existing environments and programming languages; the emphasis here being placed on the word 'fully'. Despite the fact that OOPP contains numerous features supported in existing environments and programming languages, OOPP also contains features that are not supported. Nonetheless OOPP, or at least a subset of OOPP, should be suitable for implementation on existing programming languages and environments (possibly with minor modifications and/or additions depending on the subset).
OOPP currently deals with issues that are both high-level related and low-level related. In effect OOPP touches on topics ranging from Analysis to Design to Operating System and even Archi tecture issues. OOPP should not be seen as a new approach to Analysis, nor as a new program ming environment; instead, OOPP must be seen as a new paradigm of concurrent Object-Orientation for which appropriate Operating Systems, Programming Tools and Environments, (more formal) Analyses techniques, and so forth, may need to be developed. OOPP cannot be fully supported by alI Object-Oriented languages; however, if a subset of OOPP is chosen, it may be supported by existing languages (as will become apparent, in some cases, these Subsets may reduce OOPP to existing models).
1.6 Object-Orientation and Parallelism
The Object-Oriented methodology allows a system designer the ability to approach a problem with a good degree of problem space understanding; while Parallel Processing allows the system designer the ability to create extremely fast algorithms for solving problems amenable to Parallel Processing techniques. An implicit goal of the OOPP research entails marrying the Object Oriented methodology and the Parallel Processing field so as to gain the best of both worlds. Certain papers have laid claim to their proposed system encompassing both the Object-Oriented methodology, as well as the Parallel Processing methodology. As will be shown in chapter 7, this was in most cases achieved after some initial simplifications were imposed. In general, these simplifications (e.g., requiring the Object to be the grain of parallelism) have resulted in dimi nishing the flexibility and/or capability of such models. In view of this fact, we shall furthermore examine a number of models to see if any of these systems are candidates for successfully marrying Object-Oriented and Parallel Processing into one homogeneous body. Criticism will be given on the shortcomings of unsuccessful candidates.
May 1994 C KyriaJddes Page 7 Introduction Objed-Oriented Parallel Paradigms
In simplistic terms, Computer Science is concerned with two primary goals: one, to create better computing machinery; and two, to create more efficient methods for harnessing the computing power of these machines. Computer methodologies primarily deal with harnessing the computing power of such machines. As the name Object-Oriented Parallel Paradigms implies, we will be dealing with two such primary software development domains; namely, Object-Oriented method ologies and Parallel systems. For this reason, two brief (but sufficiently detailed) chapters have been dedicated to introducing the Object-Oriented and Parallel Processing methodologies.
Owing to the fact that implementation is not within the scope of intended research, Analysis will be a predominant factor in indicating the feasibility of a proposed Object-Oriented Parallel project.
In the following discussions we will refer to Object-Oriented Parallel Paradigms as OOPP in order to distinguish it from Object-Oriented Programming Systems which are commonly referred to as OOPS.
The term Object-Orientation is not easily understood owing to the fact that the term Object has come from two very different areas of study: [Yourdon 1989]
From Information Modeling, meaning a representation of some real-world thing and some number of instances of that thing.
From Object-Oriented Programming Languages, meaning a run-time instance of some processing and values, defined by a static description called a "Class".
To further complicate matters, Stefik [1986] listed over fifty different Object-Oriented approaches. Undoubtedly, with the vast number of approaches to Object-Orientation, it will be discovered that even experts that agree on the principal points of Object-Orientation will frequently disagree on the suitability of the finer points of various approaches. Even though Yourdon [1989] is occa sionally quoted in this report, (as will be shown in section 4.1 based on the work done by Wirfs-Brock [1989]), Yourdon's proposal to Object-Oriented Analysis has a major shortcoming in its approach to analysing objects. Nonetheless, in accordance to Miller's 7±2 rule, Yourdon pro poses the use of subjects [Yourdon 1989] whereby an analyst can concentrate on a small number of closely related objects/subjects representing a subset of the actual problem.
May 1994 C Kyriakides Page 8 Introduction Objm-Oriented Parallel Paradigms
1.7 Object Technology Classification
Yourdon [1989] states that an Object-Oriented methodology is characterised by:
Objects, Classification, Inheritance, and communication by means of Messages.
Objects in the previous statement are understood to mean "an encapsulation of Attributes and exclusive Services; an abstraction of something in the problem space, with some number of instances in the problem space" [Yourdon 1989].
Furthermore, should any of the above characteristics be missing then it is very doubtful that the particular methodology is Object-Oriented. A more discerning set of classification terms is pro posed by Wegner [1988]:
Object-Oriented: characterised by Objects, Classes and Inheritance.
Class-based: characterised by Objects and Classes; however has no Inheritance.
Object-based: characterised by Objects; has no Classes or Inheritance.
An alternative definition is provided by Graham [1991]:
Object-based = Encapsulation + Object Identity Class-based = Object-based + Set Abstraction Object-Oriented = Class-based + Inheritance + Self-recursion
The Object-Oriented Parallel Paradigm, OOPP, to be proposed in chapter 9, will in fact also embrace concurrent programming under the Concurrent Object-Oriented Paradigms, COOP (see chapter 10). The definitions of parallel and concurrent processing are given in chapter 2, as well as, in the terminology section.
1.8 Summary
As the name Object-Oriented Parallel Paradigm implies, OOPP deals with two primary domains: Object-Orientation and Parallel Processing. Object-Orientation provides the system designer with
May 1994 C Kyriakides Page 9 Introduction Objed-Oriented Parallel Paradigms
the ability to approach a problem with greater problem space understanding. Where problems exist that are amenable to parallel processing techniques, Parallel Processing allows the creation of extremely fast algorithms.
OOPP presents a new approach to Object-Oriented Parallel and Concurrent Processing. OOPP will introduce the Manager-Employee model and a general-purpose Object Taxonomy. The prin ciples underlying of Productivity and Workloads are shown to be adaptable to a multi-processor environment.
When a paradigm or methodology developer attempts to marry two such diverse fields into one homogeneous body, it may be discovered that, for the sake of simplicity, one or more features of the individual fields has to be sacrificed. Based on the cited material, oopp attempts to present within the context of currently available knowledge and experience a viable easy to follow and apply paradigm that sacrifices the least in either field.
Owing to the wide spectrum of issues that require to be addressed by OOPP, the OOPP research in its current form is limited to a small fraction of all the promising directly or indirectly related topics to this field of research.
May 1994 C Kyriakides Page 10 Introduction Object-Oriented ParaDeI Paradigms
2 Introduction to Parallel Processing
This chapter serves as a brief introduction to the fundamental aspects of Parallel Processing. Readers not well acquainted with Parallel Processing will find this chapter beneficial in that it sets the prerequisite knowledge required to understand the Object-Oriented Parallel Paradigm.
This chapter will be found useful in refreshing the reader's memory with regards to general par allel processing terminology, Amdhal's law, Flynn's taxonomy, MIMD Computers and Algorithms.
The reader should note that this chapter is not intended to be extensive. It only serves to refresh and/or introduce terminology and related theory that will be found useful in understanding our Object-Oriented Parallel Paradigm. After reading this chapter, readers requiring a deeper under standing of parallel processing are referred to textbooks (such as Quinn (1987) that deal with this subject in extensive depth.
May 1994 C Kyrialddes Page 11 Introduction to Parallel Processing Objed-Oriented Parallel Paradigms
2 Introduction to Parallel Processing
In order to avoid unnecessary ambiguities arising from various definitions, the definition of Parallel Processing and Concurrent Processing are taken to read as follows:
Parallel Processing is a kind of information processing that emphasizes the concurrent manipulation of data elements belonging to one or moreprocesses solving a single problem. [Quinn 1987]
Concurrent Processing is a kind of information processing that emphasizes the concurrmtmanipulation of data ele ments belonging to two or more processes solving two or more problems.
Turning our attention briefly to terminology, we defme the term Concurrent Object-Oriented Para digms (COOP). According to the above defmitions, oOPP and COOP vary only with regards to the number of problems solved concurrently; OOPP is aimed at solving a single problem while COOP is aimed at two or more problems.
Many programs that run well on conventional computers are not easily transformed into programs that efficiently harness the capabilities of parallel computers. Conversely, programs that are less effi cient in a sequential context often reveal an inherent parallelism that makes them attractive bases for parallel programs.
Applications (such as weather prediction, computational aerodynamics, artificial intelligence, remote sensing of earth data from satellites, nuclear reactor safety, military uses, etc.) demand computers that are many times of magnitude faster than the fastest computers available today. Parallelism represents the most feasible avenue to achieve this kind of breakthrough.
There will always be a demand for faster computers. Computer engineers have used two methods for achieving higher performance. Firstly, they have increased the processing speed of the circuitry; and secondly, they have increased the number of operations that can take place concurrently, through either pipelining or parallelism.
Pipelining increases concurrency by dividing a computation into a number of steps, while parallelism is the use of multiple resources to increase concurrency.
The throughput of a device is the number of results it produces per unit time. A pipelined compu tation is divided into a number of steps, called segments or stages. Each segment works at full speed on a particular part of the entire operation. The output of one segment is the input of the next segment. If all the segments work at the same speed then once the pipe is full, the work rate of the pipeline is equal to the sum of the work rates of the segments. (Otherwise the segment with the
May 1994 C Kyriakides Page 12 Introduction to Parallel Processing Object-Oriented ParaDel Paradigms
slowest rate causes all the segments to work at that rate). Analogies hold between a pipeline and a factory assemblyline: the flow of results is simple and fixed, precedence constraints must be honored, and it takes time to fill and drain the pipe. An automobile assembly line in a factory is a good analogy of a pipeline.
Up until a few years ago, methods used to achieve higher performance have been predominantly low-level machine based. A list of developments [Quinn 1987] is given below more or less in the order of their appearance:
Bit-Parallel Memory and Bit-Parallel Arithmetic, I/O Processors (Channels), Interleaved Memory, Cache Memory, Instruction Look-Ahead, Multiple Functional Units, Instruction Pipelining, Pipelined Functional Units, Data Pipelining, Processor Arrays, Multiprogramming, Timesharing and Multiprocessing, Data Flow Computers Chronological List of Higher Performance Developments
Speedup is the ratio between the time needed for the most efficient sequential algorithm to perform a computation, and the time needed to perform the computation on a machine incorporating pipe lining and/or parallelism.
2.1 Amdahl's Law
A small number of sequential operations can effectivelylimit the speedup of a parallel algorithm. Let f be the fraction of operations in a computation that must be performed sequentially, where o ~ f ~ 1. It is easy to see that the maximum speedup S achievable by a parallel computer with p processors performing the computation is
1 Ss 1- f f+---p
May 1994 C Kyrialddes Page 13 Introduction to Parallel Processing Objed..()riented Parallel Paradigms
A corollary follows from Amdahl's Law: a small number of inherently sequential operations can significantly limit the speedup achievable by a parallel computer.
Amdahl's law is one of the strongest arguments against the future of parallel computation, because if parallel computers can never run more than 10, 15 or 20 times faster than single-CPU com puters, then the "wait for faster technology" argument makes a lot of sense. However, there do exist some parallel algorithms with almost no sequential operations. Hence Amdahl's argument serves as a way of determining whether an algorithm is a good candidate for parallelisation.
In a machine having a fixed number of processors, one of the factors limiting speedup is the availability of work to be done by the available processors. It was noted by Goodman [1977] that for any fixed number of processors, speedup is almost universally an increasing function of the size of the input problem.
2.2 Flynn's Taxonomy
A taxonomy of computer architectures was formulated by Flynn [1966] based on the concept of instruction streams and data streams. An instruction stream is a sequence of instructions per formed by a computer; a data stream is a sequence of data used to execute an instruction stream. Flynn's Taxonomy presented below is too vague to allow clear-cut labelling of modem supercomputers.
Single-Instruction stream, Single Data stream (SISD): Even though instruction execution may be pipelined, computers in this category can decode only a single instruction at a time. Most serial computers fall under this category. An SISD computer may have multiple functional units (e.g., CDC6600), but these are under the direction of a single control unit.
Single-Instruction stream, Multiple Data stream (SIMD): In any time unit a single operation is in the same state of execution on multiple processing units, each manipulating different data. Processor Arrays fall under this category. A processor array executes a single stream of instructions, but contains a number of arithmetic processing units, each capable of fetching and manipulating its own data.
Multiple-Instruction stream, Single Data stream (MISD): No computers fall under this category.
May 1994 C Kyriakides Page 14 Introduction to Parallel Processing Object-Oriented ParaDel Paradigms
Multiple-Instruction stream, Multiple Data stream (MIMD): Most parallel computers fall under this category, As Flynn's taxonomy is rather vague in this category, for this research the label MIMD is reserved for multiple-CPU computers designed for parallel and concurrent processing; that is, computers designed to allow efficient interactions among their CPUs as opposed to early multi-processors which had little interaction amongst processors. This also excludes computer architectures having multiple exclusively "dedicated", non-programmable CPUs, where each CPU is dedicated to one particular task or peripheral; for example, one processor (CPU) for program execution and another processor (channel) for I/O processing.
Thus, when we refer to a machine as being an MIMD machine we imply that the machine not only obeys Flynn's Taxonomy but also has more than one processor, and that at least two of these processors are programmable, multipurpose processors.
2.2.1 Processor Array Architecture
The processing elements of processor arrays work in lockstep. The algorithm designer does not have to worry about synchronising the processors - that function is built into the architecture. Communication costs are not zero, and algorithms must be carefully planned to minimise the amount of communication needed. Sometimes communication costs dominates the computa tional complexity. [Quinn 1987]
2.2.2 MIMD Computers
MIMD computers are more general-purpose machines, since they enable the asynchronous execution of multiple instruction streams. Thus the designer of algorithms for MIMD com puters has greater flexibility. This is one of the primary reasons why MIMD based articles have been used as the primary source of background research information. The two best-known MIMD models, namely the multiprocessor and multicomputer architectures, arc briefly described below.
Shared Memory in Multiprocessor architectures attempted to make common data avail able to various processors by means of implementing a global memory which all processors could access. Multiprocessor architectures are also currently referred to as Tightly Coupled architectures.
May 1994 C Kyrialddes Page 15 Introduction to Parallel Processing Objed"()riented Parallel Paradigms
The processor-memory pair of the Multicomputer architecture, attempted to overcome the presence of a bottleneck similar to that demonstrated in the Shared Memory model by avoiding global memory altogether. Instead, each processor has its own memory, and communication between processors is achieved by means of sending information from processor to processor until the appropriate processor is reached. Multicomputer archi tectures are also currently referred to as Loosely Coupled architectures.
In Parallel Processing the term multiprocessor is inappropriately used to represent two differ ent meanings; namely, the Shared Memory architecture, and any computer having more than one processor. In order to distinguish between these two meanings, we shall use the terms:
multiprocessor to signify a Shared Memory architecture; and multi-processor to signify a computer having more than one processor.
Limitations of the multiprocessor and multicomputer architectures will be given in section 2.3.2 and readdressed in section 5.
2.3 Developing Algorithms for MIMD Computers
According to Quinn (1987), four fundamental questions need to be addressed by the programmer of multiprocessors or multicomputers.
1) Given a problem with a certain amount of parallelism, how do you divide work among a number of processes so that they can work efficiently toward a solution?
2) What mechanisms allow processes to work together, and how are these mechanisms expressed in a programming language?
3) What is deadlock, and how can it be avoided?
4) How are processes scheduled on processors?
The primary goal of a designer of parallel algorithms is: Given a problem with a certain amount of inherent parallelism and a number ofprocessors, find an algorithm that best utilises these pro cessors to solve the problem as quickly as possible.
2.3.1 Categorisation of MIMD Algorithms
Parallelisation on MIMD models can be divided into three categories: pipelined algorithms, partitioned algorithms, and relaxed algorithms.
May 1994 C Kyriakides Page 16 Introduction to Parallel Processing Objett'()riented Parallel Paradigms
2.3.1.1 Pipelined Algorithms
A pipelined algorithm is an ordered set of segments in which the output of each segment is the input of its successor. The input to the algorithm serves as the input of the first segment; the output of the last segment is the output of the algorithm. As in all pipelines, all segments must produce results at the same rate, or else the slowest segment will become a bottleneck.
A systolic algorithm is a special kind of pipelined algorithm. Three attributes distinguish systolic algorithms.
Flow of data is rhythmic and regular.
Data can flow in more than one direction, and
The computations performed at each segment are essentially identical. Like a pipelined algorithm, a systolic algorithm requires implicit synchronisations between processes producing data and processes consuming data.
2.3.1.2 Partitioned Algorithms
Unlike pipelining, in which processors assume different computational duties, partitioning is the sharing of computation. A problem is divided into subproblems that are solved by individual processors. The solutions to the subproblems are then combined to form the problem solution. This pooling of solutions implies synchronisation among processors; for this reason partitioned algorithms are sometimes called synchronised algorithms.
Partitioned algorithms can be further divided into two categories: prescheduled algorithms and self-scheduled algorithms. In a prescheduled algorithm each process is allocated its share of the computation at compile time. Prescheduling is the norm when a computation consists of a large number of subtasks, each of a known complexity.
Sometimes, however, a computation can be broken into a number of subtasks, but the exact amount of time needed to perform its subtasks is highly variable. Two common techniques are used in this situation. The ftrst technique is to use prescheduling, but to make sure that there are far more subtasks than processes. If each process executes a
May 1994 C Kyriakides Page 17 Introduction to Parallel Processing Objen-Oriented Parallel Paradigms
large number of subtasks, then there is a good probability that every process will end up doing about the same amount of work. This method has been shown effective by Weide [1981].
The second technique is to use self-scheduling, in which the work is not assigned to the processes until run time. In a self-scheduled algorithm a global list of work to be done is kept, and when a process is without work, another task is removed from the list. Processes schedule themselves as the program executes, hence the name.
2.3.1.3 Relaxation
An algorithm that works without process synchronisation is said to be relaxed. All the processes may be working toward the same goal (as in partitioning), or there may be some specialisation of purpose (as in pipelining), but the essential element is that no processor ever has to wait for another processor to provide it with data. Instead, relaxed algorithms are characterised by the ability of processors to work with the most recently available data. It is this non-deterministic behavior of algorithms parallelised by relaxation that makes prediction of performance difficult [Stone 1973]. Some authors prefer the term asynchro nous algorithm to relaxed algorithm.
2.3.2 Factors influencing Speedup
One constraint effecting speedup is the size of the input problem. If there is not enough work to be done by the number of processors available, then any parallel algorithm would show constrained speedup. The Amdahl Effect explains why speedup is almost universally an increasingfunction of the size of the input problem.
The number of process creations and synchronisations in a partitioned algorithm must be minimised. Since process creation is more expensive than process synchronisation, the usual tactic is to create the desired number of processes when the algorithm begins execution and to synchronise them when necessary. If synchronisation must be done frequently, then the overhead can be significant. Because synchronisation is so expensive, a goal of the parallel algorithm designer should be able to make the grain size - relative amount of work done between synchronisation - as large as possible, while keeping all the processors busy.
May 1994 C Kyriakides Page 18 Introduction to Parallel Processing Objed-Oriented Parallel Paradigms
Sequential code limits the speedup of all three kinds of parallel algorithms (Amdahl's Law). There is a more subtle limitation caused by the use of sequential code in partitioned algo rithms. If a portion of the algorithm must be executed sequentially by one of the p processors, then the remainingp-l processors must wait for the sequential portion to complete before they resume. This implies synchronisation among the processors.
The possible number ofprocessors that can be put to work on the algorithm should not be too constrained, particularly by data structures that do not distribute processor contention. Too much contention for a shared resource limits the speedup of a pipelined, partitioned, or relaxed algorithm in much the same way as the presence of sequential code does. Contention between processors for data resources is called software lockout.
A similar problem can occur at a more fundamental level. If the instructions used by all the processors in a tightly coupled multiprocessor are kept in a single shared memory bank, then processor contention for that memory bank puts a low ceiling on the speedup achievable by any parallel algorithm.
Quinn [1987] states that the ideal situation is for every processor in a multi-processor to have a local memory where instructions, local variables, and constants are stored. "Constants" include global variables that are read but never written. That way shared memory is accessed only to find the value of a variable that is (1) shared among processes and (2) subject to modification. In other words, shared memory is used only for communication and synchroni sation between processes. Unfortunately, the multiprocessor model itself suffers from conten tion for access to the shared memory.
The workload must be balanced among the processors. Typically, workload balancing is not a problem for partitioned algorithms running on tightly coupled multiprocessors. In general, though, the task allocation problem is critical. There are two general allocation policies: StaUc decomposition assumes that the tasks and their precedence relations are known before execution, while dynamic decomposition assumes that tasks are generated during program execution. The advantage of static decomposition is that it allows the preallocation of tasks to processors. This can reduce the amount of interprocessor communication, which can be especially important on multicomputers. The advantage of dynamic decomposition is that the fastest serial algorithms do not necessarily make the most efficient parallel algorithms [Baer 1982; Hockney 1981; Stone 1973}. However since speedup is defined to be the ratio between
May 1994 C Kyriakides Page 19 Introduction to Parallel Processing Objed-Oriented Parallel Paradigms
the execution time of the best sequential algorithm and the time of the parallel algorithm, it is important that as little time complexity as possible be added when an algorithm to paral- . lelise is chosen.
2.4 Correctness for Concurrent Processes
Wegner's [1989] perspective on correctness for concurrent processes is briefly described below. (For additional details on what is presented below please see Wegner [1989]).
Correctness for concurrent processes may be defined in terms of correctness for sequential processes in terms of Iinearisability [Herlihy 1989a]. A computation within a concurrent process is said to be linearisable if it is equivalent to a sequential computation in which methods are executed in an instantaneous non-overlapping order within their interval of invocation and response. A linearised computation for a typed process is acceptable if it is consistent with the requirements (axioms) of the data type.
Linearisability and acceptability are locally defmable. A computation on a collection of concurrent Objects is acceptable if there is an acceptable linearisation for each of the Objects in the collec tion. A program is correct if all its potential computations are acceptable.
Linearisability allows correctness to be specified for each type in terms of its sequential properties (axioms). But it does not allow dependency relations between Objects of the kind that arise in transactions to be specified.
Correctness of concurrently executing transactions may be defmed by serialisability, namely by the requirement that computations with concurrently executing transactions are equivalent to some serial order of execution of the transactions. Serialisability flattens a collection of concurrently executing transactions into some serial order of execution.
Linearisability and serialisability have in common the idea of reasoning about concurrent compu tations by postulating their equivalence to some sequential computation. Linearisability is less ambitious in requiring only sequential equivalence for concurrently executing methods of individual Objects and is able to capture type correctness. Serialisability aims to capture exclusive access to shared resources by sequences of methods and requires a much stronger form of sequential equivalence that treats sequences of methods rather than individual methods as the units to be serialised.
May 1994 C Kyriakides Page 20 Introduction to Parallel Processing Objed-Oriented Parallel Paradigms
Objects and transactions are two complementary structuring mechanisms for concurrent systems. Objects partition the system state into encapsulated components with characteristic behaviour determined by sets of applicable operations. Transactions partition system actions into sequences with exclusive access to shared Objects during the complete duration of their execution.
Modularity in Object-based transaction systems differs from the traditional Object-based notion of modularity. It encompasses temporal modularity associated with atomic actions as well as state-based modularity.
2.5 Process Communication and Synchronisation on MIMD Models
In order for processes to work together, they must have the ability to communicate and synchro nise. Communication is achieved either through shared variables or through Message passing. The type of communication available may be dictated by the architecture. Communication often leads to synchronisation requirements. Synchronisation has two uses: to constrain the ordering of events, and to control interference.
2.6 In support of Object-Oriented Parallelism
As can be seen from the "chronological list of higher performance developments" mentioned above (in chapter 2), developments have started off initially with purely hardware-based improvements, and have currently moved into a mixture of hardware and software-based improvements. It makes sense that a successful marriage of hardware and software-based methodologies is the ideal goal.
The concern of this report is the software methodology aspects; namely, the methodology should be sound, irrespective of whether it is well-suited to a currently existing machine or to a machine which has yet to be developed. What the latter statement implies, is: let us develop a sound (Object-Oriented) methodology and if a suitable machine does not exist then let us see if it is feasible to develop one.
2.7 Summary: Parallel Processing
In contrast to Sequential Processing which is aimed at single-processor machines, Parallel and Concurrent Processing are aimed at multi-processor machines. The fundamental idea is to harness the power of two or more processors so as to solve a given problem faster.
May 1994 C Kyriakides Page 21 Introduction to Parallel Processing Objed'()riented Parallel Paradigms
In summarising we recall the Parallel Processing and Concurrent Processing definitions presented at the beginning of this chapter.
Parallel Processing is a kind of information processing tJult emphasizes the concurren: manipulation of data elements belonging to one or more processes solving a single problem. [Quinn 1987]
Concurrent Processing is a kind ofinformation processing that emphasizes the concurrmt manipulation of data elements belonging to two or more processes solving two or more problems.
Parallel Processing algorithms on MIMD models can be divided into three categories: pipelined algorithms, partitioned algorithms, and relaxed algorithms.
Amdahl's law indicates that, for any algorithm, maximum speedup attainable as a result of parallel processing is limited by the number of inherently sequential operations of the algorithm. Clearly, some algorithms can benefit substantially more than others from parallel processing, (while, problems comprising entirely of inherently sequential operations will not benefit at all).
May 1994 C Kyriakides Page 22 Introduction to Parallel Processing Objed-Oriented ParaDel Paradigms
3 Object Technology Concepts
This chapter aims to refresh the reader's memory with regards to the fundamental Object Oriented concepts and terminology. Brief introductions are made to numerous developments in the Object-Oriented field. These introductions have been kept purposefully brief. After reading this chapter, readers wishing to acquire deeper understanding of the Object-Oriented concepts are strongly advised to consult more detailed works on the subject, some of which are listed in the reference section.
This chapter introduces general Object-Oriented background knowledge required to comprehend numerous of the fundamental concepts of the Object-Oriented Parallel Paradigm (presented from chapter 9 onwards). Like the previous chapter, this chapter is not intended to be extensive. It only serves to refresh and/or introduce terminology and related concepts that will be found useful in understanding our Object-Oriented Parallel Paradigm.
May 1994 C KyrialUdn Page 23 Object Technology Concepts Objed.Qriented Parallel Paradigms
3 Object Technology Concepts
In the plethora of approaches claiming to be Object-Oriented it is difficult to distinguish between Object-Oriented approaches and approaches containing (not all but at least) several Object-Oriented features. To make matters even worse, certain approaches or languages claim to be Object-Oriented and yet lack features that are argued by numerous protagonists of the Object-Oriented field to be fundamental/essential to all Object-Oriented approaches; while others claim that some of these so called essential features are not mandatory or may even be disadvantageous in certain cases. For the sake of simplicity we will postpone discussing these arguments until after the general characteristics of Object Technology (OT) have been presented. As will be elaborated on shortly, we will present these concepts from the perspective of the Object-Oriented technology as it presents a more comprehensive view than the Class-based and Object-based technologies.
Nonetheless, it must be pointed out that it is beyond the scope of this research to thoroughly inves tigate existing Object Technology classifications. (For the time being, it will suffice to state that this research adopts Object-Orientation in the context of Wegner's Object technology classification introduced in section 1.7).
3.1 Object Technology Fundamentals
Despite all the diverse approaches to Object-Orientation certain common points persevere, if not in all, then at least in most Object-Oriented approaches. Generally, Object-Orientation is charac terised by encapsulation, information-hiding and inheritance - these terms are briefly described here and will be presented in greater detail in the following sub-sections.
Generally, Object-Oriented approaches exploit encapsulation (or "packaging") in various ways. In essence, encapsulation accommodates the decomposition of large systems into smaller encapsu lated subsystems that can be more readily developed, maintained, and ported. Instead of thinking in terms of data and programs, Object-Orientation encourages encapsulation based on Objects. Where various approaches vary is in which properties of the Objects they wish to encapsulate.
Within the context of Object-Orientation, encapsulation is the act of grouping into a single Object both data and the operations that affect that data. It makes sense to bundle together knowledge and operations that are conceptually related to each other and represent them as an Object.
May 1994 C Kyriakides Page 24 Object Technology Concepts Objed-Oriented Parallel Paradigms
Encapsulation establishes a conceptual barrier enclosing a collection of items. In essence, encap sulation converts several different items into one conceptual unit. Manipulation is thereby simpli fied in that several items may now be viewed and manipulated as one unit. Encapsulation transforms many into one by adding a new layer of meaning.
In addition to encapsulation, information-hiding allows us to conceal a portion of those things which have being encapsulated by the Object. By information-hiding we not only gain greater abstraction but also the ability to design code that can be more easily modified, maintained, and extended.
Also, Information-hiding distinguishes between the ability to accomplish some task from the spe cific steps required to do so. Thus, from the perspective of other Objects, we can concentrate on "what" the Object is responsible for rather than "how" it achieves them.
Encapsulation and information-hiding assist each other in isolating a portion of the system from other parts; thereby allowing bugs to be eliminated and code to be modified and extended without the risk of introducing unnecessary and unintended side-effects.
In addition to encapsulation and information-hiding, Object-Orientation makes use of inheritance. Inheritance is a reusability mechanism which caters for sharing behaviour between Objects. Cur rently, the most common form of inheritance is based on class and subclass relationships; whereby a subclass is a specialisation of its class.
The following sections briefly present fundamental principles and related terminology of Object technology. This is not intended as an encyclopaedic viewpoint of Object technology. Furthermore, please note that a specific Object methodology may not support one or more of the features presented below.
3.1.1 Object-Oriented Approach
The Object-Oriented approach attempts to manage complexity inherent in real-world problems by abstracting out knowledge, and encapsulating it within Objeds. finding or creating these Objects is a problem of structuring knowledge and activities. [Wins-Brock 1990]
In essence, the inherent complexity of real-world problems is made more manageable by encapsulation whereby the complexity of a real-world problem is distributed to the individual, pertinent Objects. In this case, encapsulation reduces a large complex problem into numerous smaller problems of lesser complexity enclosed within the individual Objects.
May 1994 C Kyriakides Page 2S Object Technology Concepts Objed-Oriented Parallel Paradigms
Hence encapsulation can be perceived as a mechanism for managing complexity; similarly, information-hiding and inheritance are simplyreusability mechanisms.
We justify adopting the Object-Oriented approach to present the fundamental concepts of Object technology by recalling the following Object Technology classifications from earlier sections.
According to Wegner [1988], a technology is Object-Oriented if it is characterised by Objects, Classes and Inheritance.
An alternative definition was proposed by Graham [1991], stating that a technology is Object-Oriented if it has Encapsulation, Object Identity, Set Abstraction, Inheritance and Self-Recursion.
3.1.2 Class-Based Approach
Wegner [1988] also states that a technology is said to be Class-Based if it is characterised by Objects, Classes and has no inheritance.
An alternative definition was proposed by Graham [1991], stating that a technology is Class based if it has Encapsulation, Object Identity and Set Abstraction.
3.1.3 Object-Based Approach
We recall from earlier sections that according to Wegner [1988], a technology is Object-Based if it has Objects but has no Classes or Inheritance.
An alternative definition was proposed by Graham [1991], stating that a technology is Object-based if it has Encapsulation and supports Object Identity.
Thus it is self-evident that the Object-Oriented technology supports all of the concepts present in Object-based and Class-based technologies, and more.
3.2 Objects
3.2.1 Methods and Attributes
An Object is a package of information and a description of its manipulation [Oxford 1986].
May 1994 C Kyriakides Page 26 Object Technology Concepts Object-Oriented ParaDel Paradigms
In other words, an Object encapsulates both data and functions. The data is encapsulated in data elements within an Object called Attributes. Similarly, functions encapsulated in an Object are called Methods. Attributes and Methods cannot exist independently of an Object.
Methods provide exclusive processing on an Object's data. In other words, in an Object Oriented model, only the Methods of an Object can directly access and manipulate the Attributes located in that particular Object.
3.2.2 Private and Public parts
From the perspective of information-hiding, Objects consist of two parts: a private and a public part. The private part of an Object is that part of an Object which may not be accessed by other Objects, but can be accessed by subclasses or instances. The public part of an Object is that part of an Object that may be accessed by other Objects. Thus, the public part of an Object constitutes its interface.
The private part of an Object's definition can only be accessed by methods of that particular Object, but cannot be accessed by methods belonging to any other Object.
In contrast, the public part of an Object can be accessed by both, the methods of that par ticular Object and, methods belonging to other Objects.
3.2.3 Operations
In accordance with the principle of information-hiding, attributes and methods must always be part of the private representation of an Object. No other Objects can gain access to an Object's attributes and methods since they are part of the private part of the Object. Instead, operations fill this gap. Operations form part of the public interface of an Object and specify the method as well as the arguments or at least the argument types required by that particular method.
Hence, information-hiding is accommodated by allowing other Objects to see what services (methods) are available but not allowing them to see how these services are provided. Fur thermore, operations are provided only for specific methods whose services are required to be accessible to other Objects.
May 1994 C Kyrialddes Page 27 Object Technology Concepts Objed-Oriented Parallel Paradigms
It must be pointed out that many authors use the term methods in place of operations, thereby creating some confusion.
Information-hiding enhances ease of modification and maintainability of existing systems. This is possible since the internal representation of an Object can be modified (say to implement a more efficient algorithm) without changing the Object's public interface. Thus other Objects communicating with the modified Object will not be effected.
3.2.4 Object Behaviour
The behaviour of an Object is the set of operations to which an Object can respond. Opera tions to be requested by other Objects must be part of the public interface of the Object. Note however that an Object may send private messages to itself thereby implementing its own publicly accessible operations.
3.3 Message Passing Protocol
3.3.1 Messages
The only means by which one Object can gain access to another Object is by sending it a message; this is referred to as a message-send. Since a message represents a request from the sending Object to the receiving Object to carry out one of its operations (and possibly return some information), the message includes both the name of an operation and any arguments required for that operation.
Upon receiving the message, the receiving Object performs the requested operation without disclosing to the sender how the operation was performed. It must be noted that a message only discloses what operation is to be performed, not how that operation should be performed.
3.3.2 Methods
In essence, a method is the step-by-step algorithm executed in response to receiving a mes sage.
Stated more formally, in response to receiving a message whose name matches that of an operation, the appropriate method is then executed. This conforms to the principle of
May 1994 C KyriaJddes Page 28 Object Technology Concepts Objed-Oriented Parallel Paradigms
information-hiding mentioned above; an operation forms part of the public part of an object, while a method is always part of the private representation of an Object and is never part of the public interface.
3.3.3 Signatures
The formal specification of the inputs to, and output from, a method specifies what is required to make use of the method and is called a method's signature. A signature specifies the name of a method, the type of its parameters, and the type of the Object that the method returns. [Wirfs-Brock 1990]
3.3.4 Message Names
In some cases it is useful to refer to an operation by name without considering its arguments; here we call the name of an operation a message name.
3.4 Classes and Instances
A class is an abstraction of a set of Objects that specifies the common static and behavioural characteristics of the Objects, including the public and private nature of the state and behaviour. A class is a template from which Object instances are created. [Graham 1991J
Objects that behave in a manner specified by a class are called instances of that class. In Object-Oriented technologies, all Objects are instances of some class. Once an instance of a class is created, it behaves like all other instances of its class, able upon receiving a message to perform any operation for which it has methods. Furthermore, it may also call upon other instances, either of the same or other classes, to perform other operations on its behalf. A program can have as many or as few instances of a particular class as required.
Unfortunately, as was the case of methods and operations, many authors use the terms Object in various different ways: frequently the term Object is used in place of the term instance; however, the term Object is also used in place of the term class. This inconsistency may create some confusion aggravated by the fact that different programming environments may present different interpretations of the term class. (For example, classes in C+ + exist as templates for creating instances of Objects - similar to types in procedural languages; while, classes in Smalltalk exist as
May 1994 C Kyrialddes Page 29 Object Technology Concepts Object-Oriented ParaDel Paradigms
Objects providing methods for instances of their respective class). This dual usage of the term Object is unfortunately well ingrained in most literature and it is best left up to the reader to ascertain the appropriate meaning of its occurrence based on its context.
Before continuing we will take this opportunity to define certain terms related to or confused with classes. It must be noted however that not all of the features described by these terms are sup ported by every existing model. (For further information see [Graham 1991]).
An abstract class is a class that has no instances, only subclasses; if they existed, an abstract class's instances would have no concrete interpretation. An abstract class is also sometimes used to refer to a meta-class. In languages like Smalltalk, a meta-class is a class whose instances are classes.
An abstract data type is an abstraction, similar to a class. An abstract data type describes a set of Objects in terms of an encapsulated or hidden data structure and operations on that structure.
A class variable is an attribute inherited by all subclasses and instances of the class it belongs to. The values of class variables may be inherited by subclasses.
An instance variable is a data-holding attribute contained within an instance that describes the state of that instance. In contrast to class variables, only the declaration of an instance variable not its value - may be inherited by its subclasses.
3.5 Object Relationships
In view of the above mentioned definitions of Object instances and classes, we take this oppor tunity to present below a few relationships that may exist between various Objects.
IsA Is A. The inheritance relationship between instances and their classes [Graham 1991]. Sometimes also written as is-a.
!sA
May 1994 C Kyriakides Page 30 Object Technology Concepts Objed-Oriented ParaDel Paradigms
The is-a relationship asserts that instances of a subclass must be more specialised forms of the superclasses. Thus, instances of a subclass can be used where quan tities of the superclass type are required. [Budd 1991]
AKO A Kind Of. The inheritance relationship between classes and their superclasses [Graham 1991].
E~
APO A Part or is a composite relationship indicating that the Object forms a part of a larger Object. Such an Object is also sometimes referred to as a composite Object.
8 8 8
May 1994 C Kyriakides Page 31 Object Technology Concepts Object.Oriented Parallel Paradigms
APO relationships may be depicted by A Parts Of attribute in the smaller Object and a Pans attribute in the composite Object. APO relationships may be refined by E/O (exclusive/optional) and I/O (inclusive/optional). The term "exclusive" depicts an arrangement under which each subclass's intersection with other sub classes is empty; while, "inclusive" indicates that subclasses may overlap. (For further details see [Graham 1991]).
Members An Object is a member of all its immediate classes and their superclasses.
What ~s important to note is that the part-of relationship is viewed as a naviga tional aid. Hence, it does not form part of the specification of the composite Object; this is done so as not to compromise reusability. To elaborate, this implies that the various Objects that constitute part of the larger composite Object are viewed as Objects that exist distinct from the composite Object. Thus, when a composite Object (or an Object forming part of the composite Object) is updated, only the Object that was altered needs to be changed. A similar argument holds for member Objects and their superclasses.
Has-a The relationship that asserts that instances of a class possess fields of a given type. [Budd 1991]
3.6 Inheritance
Inberltance is a reusability mechanism for sharing behaviour between Objects. Inheritance exists in many variations depending largely on what we wish to inherit and when and how the inheritance is to take place. Nierstrasz [1989] lists the differences between the various forms of inheritance as follows:
Is inheritance static or dynamic?
What are the clients of the inherited properties (i.e., classes or instances of classes)?
What properties can be inherited (e.g., instance variables, methods, rules, values)?
Which inherited properties are visible to the client?
Can inherited properties be overridden or suppressed?
How are conflicts resolved?
May 1994 C Kyrialddes Page 32 Object Technology Concepts ObJect-Oriented Parallel Paradigms
It is important to provide a facility for overriding inherited methods.
It must be pointed out that even though inheritance may exist in many variations, frequently authors will be encountered that fail to illustrate this. Instead they opt for one variation or another and give the impression that the particular variation which they chose is indeed the general defi nition of inheritance. For example, the following quotation describes inheritance in terms of classes (and as will be shown in the following sub-sections) this represents only a static form of inheritance; hence this extract it overlooks the existence of dynamic inheritance.
Inheritance is an abstraction mechanism. Inheritance is the ability of one class to define the behaviour and data structure of its instances as a superset of the definition of another class or classes. [Wins-Brock 1990) 3.6.1 Class/Static Inheritance
Class inheritance is a simple and powerful mechanism for defining new classes that inherit properties from existing Classes.
Class inheritance is a static [otm of inheritance: new classes inherit properties when they are defined rather than at runtime. Once a class has been defined, the properties of its instances (instance variables and methods) are determined for all time.
Static inheritance can be encountered under various forms, namely single inheritance, multiple inheritance and partial inheritance. These arc briefly discussed below.
Single Inheritance
Under single Inheritance, a subclass may inherit methods and instance variables of a single parent class, possibly adding some methods and instance variables of its own. Single inheri tance hierarchies arc usually depicted by a tree diagram.
- Inheril:mceRelationships
Single Inheritance
May 1994 C Kyrialddes Page 33 Object Technology Concepts Object-Oriented Parallel Paradigms
Multiple Inheritance
Multiple Inheritance occurs when a subclass inherits from more than one pare!1t class.
Inheritarce Relationships
Multiple Inheritance
Generally, multiple inheritance is rarely required, however when multiple inheritance is nec essary it can be quite clumsy to do without.
In the presence of multiple inheritance name conflicts may occur when two or more properties are inherited with the same name. In the case of inherited method conflicts, to resolve this the system may provide default rules for selecting one of the methods, or for combining inherited methods, or require the programmer to make an explicit choice. In addition to inherited method conflicts, inheritance of identically named instance variables will also present name clashes. In the latter case, this can be resolved by separately inheriting each variable and distinguishing between them by prefixing them with their parent class name.
Some systems also support value inheritance - this is where not only is the attribute inherited, but also its value. Thus, value conflicts can also occur under multiple inheritance.
Multiple inheritance is provided in Lisp with Flavors [Moon 1986], Eiffel [Meyer 1988], Trel lis/Owl [Schaffert 1986J and Mesa with Traits [Curry 1982J. However, even though Smalltalk-80 has class inheritance, it does not cater for multiple inheritance.
May 1994 C Kyriakides Page 34 Object Technology Concepts Objed"()riented ParaUel Paradigms
Partial Inheritance
Partial Inheritance is a mechanism whereby we can inherit some properties and suppress others. Partial inheritance is supported by C+ + [Stroustrup 1986] and CommonObjects [Snyder 1986a].
3.6.2 Dynamic Inheritance
Dynamic Inheritance permits Objects to alter their behaviour in the course of normal inter actions between Objects. Two fundamental forms of dynamic inheritance exist:part inheritance and scope inheritance.
Part Inheritance
Part Inheritance occurs when an Object explicitly changes its behaviour by accepting new parts from other Objects.
Part inheritance is simply an exchange of value between Objects. By modifying an Object's instance variable we thereby change its behaviour; this change in behaviour is limited/deter mined by its Object class. If we consider instance variables and methods as values then part inheritance takes a more interesting subtlety; here an Object may dynamically inherit new instance variables and methods from other Objects. An example of this kind of inheritance is that of "knowledge Objects" (see [Tsichritzis 1987], [Casais 1988)); where evolving active Objects can acquire new rules and methods.
Scope Inheritance
Scope Inheritance occurs indirectly through changes in the environment. In scope inheritance an Object's behaviour is determined in part by its environment or its acquaintances. When changes in the environment occur, the behaviour of the Object changes.
May 1994 C Kyriakides Page 35 Object Technology Concepts Objed-Oriented Parallel Paradigms
an Object to refer to instances of different Classes at run time; or
an operator to refer to different methods within an Object at run time, or
a method to refer to different methods within the same Object.
Under polymorphism the selection, as to which class instance or method is appropriate, is made at run time. This choice is dependent on the format of the message invoking the particular operation; more precisely, the appropriate choice is made based on the message's argument types.
This section is only intended as a brief introduction to polymorphism. Please note that poly morphism is encountered in numerous forms. Several of the models referred to in this research provide polymorphism in one form or another. It will become self-evident that enhancing abstraction as a result of polymorphism is advantageous. However, the more complex issue that will not be addressed here is whether one form of polymorphism is more advantageous than another.
3.7.1 Polymorphic Variables
A polymorphic variable is one that can take on any value of various different types.
3.7.2 Polymorphic Functions
A function is said to be a polymorphic function if it can be applied uniformly to a variety of Objects.
Generally, a polymorphic function is either:
a function that has at least one polymorphic argument, or
a function that denotes several different functions.
Within the context of Object-Orientation, this term is analogous to a polymorphic method.
Hence, a polymorphic method is either:
a method that has at least one polymorphic argument, or
a method that denotes several different methods.
May 1994 C Kyriakides Page 38 Object Technology Concepts Objed'()riented Parallel Paradigms
3.7.3 Polymorphic Operators
A Polymorphic operator is an operator whose meaning depends on the types of its operands. This form of polymorphism is sometimes also referred to as operator overloading.
Operator Overloading: A special case of polymorphism; attaching more than one meaning to the same operator symbol. [Graham 1991]
Thus, a polymorphic operator is either:
an operator that has at least one polymorphic argument, or
an operator that has provides access to several different methods.
In an Object-Oriented model a message may be send from one Object to another and two or more operations (methods) of that Object may have identical names matching the method name. In order to determine which method should respond to the message received the types of the arguments received with the message are compared to the arguments defined by the method's signature (see section 33.3).
3.7.4 Polymorphic Messages
A Polymorphic Message is a message interpreted differently when received by different Objects.
'Overloading' is also sometimes used to indicate using the same name for different Objects. [Graham 1991]
Polymorphism is the ability of two or more Classes to respond to the same message, each in its own way. This means that the Object does not need to be concerned with which Object will process the message. It just needs to know that many different kinds of Objects have been defined to respond to that particular message.
Objects of a variety of different, but similar, Classes can recognise some of the same messages and respond in similar, appropriate ways. A response appropriate for one Class of Object might be thoroughly inappropriate for another Class. The sender need not be concerned with the method that executes as a result of its message.
May 1994 C Kyrialddes Page 39 Object Technology Concepts Objed'()riented Parallel Paradigms
3.7.5 Inclusion Polymorphism
Inclusion Polymorphism allows type checking to authorise more specific objects but not more general ones. This is one form of polymorphism not frequently encountered. Nonetheless, the Eiffel model to be discussed in greater detail in later chapters supports this type of poly morphism.
3.7.6 Polymorphism's role as an Abstraction Mechanism
Polymorphism allows us to recognise and exploit similarities between different Classes of Objects. When we recognise that several different kinds of Object could respond to the same message, the distinction between the message name and a method becomes evident. An Object sends a message; if the receiver implements a method with the same signature, it will respond. Different responses are possible; therefore different methods make sense for instances of different Classes. However, the sender can simply send the message without being concerned with the Class of the receiver.
In retrospect, it is clear that some polymorphic terminologies tend to overlap in the environ ments they describe.
3.8 Homogeneous models
A homogeneous Object-Oriented model is a model where everything is an Object. Homogeneous Object-Oriented models are considered to be more Object-Oriented than models in which only some constructs are Objects.
As a consequence of the above mentioned, models that comprise of both Objects and non-Objects are clearly non-homogeneous. Most authors tend to reflect this viewpoint; and thus the extreme cases of homogeneousness are clear-cut. What is not that clear-cut, is whether systems that sup port more than one "kind" of object are homogeneous or non-homogeneous.
For the time being it will suffice to state that we adopt the following viewpoint.If all Objects are treated as equivalent in all aspects expect those differences depicted by their "types", then a system is homogeneous. Furthermore, all Objects in a homogeneous system must be able to interact with each other using the same paradigm of interaction (this point will be elaborated in section 3.11 by using active and passive Objects).
May 1994 C Kyriakides Page 40 Object Technology Concepts Objed-Oriented Parallel Paradigms
Thus, a system is said to be non-homogeneous in the case where:
Objects vary in ways which cannot be attributed to their "types", or
both Objects and non-Objects exist, or
active and passive Objects exist.
3.9 Encapsulation
Objects are often encapsulated in terms of a set of operations (which serves as a visible interface to that Object), while hiding the Object's realisation (i.e., its data structures and the implementa tion of the operations). Object independence is emphasized by message passing (which serves as a communication mechanism between Objects). Under message passing, one Object may not manipulate or view another Object's hidden data; instead a message is send from one Object to another and the Object receiving the data selects the method by which it will react to the message [Nierstrasz 1989].
The most effective tool for managing complexity is abstraction. Although different types of abstraction exist, encapsulation is the main form of abstraction for handling complexity in the Object-Oriented paradigm. Encapsulation in the Object-Oriented paradigm improves software development factors such as reusability, refinement, testing, maintainability and extensions.
3.10 Reusability
In the past, reusability was effected by encapsulation of procedures, macros and libraries. Object-Oriented techniques provide further reusability by encapsulating programs and data. The various subsections briefly highlight some of the reusability mechanisms encountered in Object technology.
3.10.1 Dynamic and Static Instantiation
Object instantiation is a reusability mechanism in which Objects may be either statically or dynamically instantiated. Static instantiation occurs when Objects are allocated at compile time and exist for the duration that the program executes. Dynamic instantiation results in Objects requiring run-time support for allocation and for either explicit deallocation or some form of garbage collection.
Mayi994 C KyriaJddes Page 41 Object Technology Concepts Objed-Oriented Parallel Paradigms
3.10.2 Object Classes
Object Classes provide a programmer with the ability to define and instantiate their own Objects. An Object Class specifies: a set ofvisible operations, a set ofhidden instance variables, and a set ofhidden methods that implement the operations. The instance variables can be modified only indirectly by invoking the operations. When a new instance of an Object Class is created, it has its own set of instance variables, and it shares the operations' methods with other instances of its Class. [Nierstrasz 1989]
3.10.3 Inheritance
As was mentioned previously, inheritance serves both as an abstraction mechanism, as well as, a reusability mechanism that allows Objects to share behaviour.
3.10.4 Polymorphism
Polymorphism is useful in enhancing software reusability. Furthermore, polymorphism makes it possible to implement generic software that will work not only for a range of existing Objects, but also on Objects to be added later.
Unfortunately, as is usually the case, the price we pay to gain this additional flexibility lies in increased run time overheads. Namely, in the case where dynamic binding is permitted, poly morphism will impose additional run time overheads. In contrast, if all Objects were statically bound to variables, then the methods to be executed can be established at compile time; unfortunately, this static form of polymorphism is not as flexible as the dynamic form.
The static form of polymorphism is closely related to class inheritance. Namely, under class inheritance, the same operations that apply to instances of a parent class also apply to instances of its subclasses. Nonetheless, it is possible to have polymorphism without class inheritance.
May 1994 C Kyriakides Page 42 Object Technology Concepts Objed'()riented Parallel Paradigms
3.10.5 Generic Classes
Generic Classes achieve reusability by partially describing a Class and parameterising the unknowns. Usually, these parameters are Classes of Objects that will be manipulated by instances of the Generic Classes.
Nierstrasz [1989] partitions Generic Objects into two basic categories:
homogeneous "container" Objects, like arrays and lists, that operate on any kind of Object; and
"tool" Objects, like sorters and editors, that operate only certain Object classes.
In "tool" Objects the parameter is constrained to indicate the required parent class of the parameter. For example, a generic sorter could only work on Objects that are instances of some subclass of the class Tota/lyOrdered.
Even when the parameter is not important for the generic Object itself, it can be useful for maintaining homogeneous collections. For example a List Object may be capable of storing any Object, but if the List Object is to be used by the Sorter Object then the List Object may only contain TotallyOrdered Objects.
Whether generic classes can be compiled before the parameters are bound is dependent on the nature of the parameters. (Readers wishing to delve deeper into the relationship between inheritance and genericity in a strong-type setting are referred to Meyer [1986]).
3.10.6 Object Types
For most intends and purposes, an Object Type is analogous to an Object Class. However, whereas some Object Classes may portray dynamic characteristics, Object Types define static characteristics of Objects. Hence, typed Objects aI/ow for static verification. Exploiting static verification, we can reassure ourselves that we are implementing Objects in a consistent fashion and thereby eliminate the need for Objects to protect themselves from unexpected messages.
Definition of abstract data types are supported by languages such as Ada [ANSI 1983] and Clu [Liskov 1981, 1986] but provide no mechanisms for Class inheritance. Nierstrasz [1989] states
May 1994 C Kyriakides Page 43 Object Technology Concepts Objed-Oriented Parallel Paradigms
that such languages are legitimately "Object-Oriented" in that they are oriented toward pro gramming in terms of Objects. To a large extend, the controversy concerning whether a lan guage is Object-Oriented or not, pivots around whether languages having Object Types without inheritance are sufficiently Object-Oriented. Languages such as Smalltalk or liSP with Flavors support Object-Oriented programming without strong support of Object Types. While lan guages such as C+ + [Stroustrup 1986], Trellis/Owl [Schaffert 1986], and Eiffel are Object Oriented and have strong support of Object Types.
In general, type-checking in Object-Oriented Languages supportingpoo/m01phism and dynamic binding is by large degree more complex than that required in traditional typed languages. This complexity is attributed to the fact that with the use of polymorphism and dynamic binding, the compiler must cope with the fact that some types may be equivalent to others or included in other types. The specifications for valid bindings and invocations are provided by the declared types of variables and of arguments to operations. Stated in simpler terms, one type conforms to another if some subset of the first type's interface is identical to the interface of the second; the first type is then said to be a subtype of the second. Two types are equivalent if they conform to each other. Usually, the interface of an Object Type (depending on the particular type model chosen for a language) comprises of operation names, types of the arguments, and return values.
3.11 Concurrency
Concurrency and communication in programming languages has been dealt with in two ways: [Nierstrasz 1989]
by active entities (processes) that communicate indirectly through shared passive Objects, and
by active entities that communicate directly with one another by message passing.
Although either of these approaches may be used in order to structure concurrent applications in an Object-Oriented environment, these approaches give rise to different Object models. Currently, the message passing approach to concurrency appears to dominate in concurrent Object technol ogies.
May 1994 C Kyriakides Page 44 Object Technology Concepts Objed-Orienled Parallel Paradigms
Readers wishing to delve deeper into Object-Oriented Concurrency are strongly advised to refer Tomlinson [1989]; Tomlinson provides an excellent coverage on Concurrent Object-Oriented pro gramming languages. Also, Andrews [1983] presented a noteworthy survey of concurrent pro gramming languages and notations.
3.11.1 Concurrency using passive Objects
Concurrency achieved by processes that communicate indirectly through shared passive Objects is typical of languages like Modula-2 [Wirth 1983].
Under this approach, the shared memory may be structured as a collection of passive Objects and a process viewed as a special kind of active Process Object. It is required that actions on the passive Objects are performed according to their declared interface. This approach requires a mechanism whereby the active Objects may synchronise their accesses to the shared Objects. This synchronisation may be achieved through use of semaphores or locks (as in Smalltalk and Trellis/Owl [Moss 1987]), or through the use of monitors (as in Modula-Z), or transactions (as in Avance - formerly OPAL [Ahlsen 1985]).
Attributed to the fact that the Object model contains two fundamentally different kinds of Objects, active and passive, the approach to concurrency using passive Objects is essentially nonhomogeneous. To elaborate, it is not possible to interact directly with Active Objects using the same paradigms of interaction that apply to Passive Objects; two Active Objects can communicate only through a Passive intermediary. Furthermore, in order to extend this model to a distributed environment it is necessary to employ some form of hidden message passing [Nierstrasz 1989J.
3.11.2 Concurrency using message passing
Concurrency achieved by active entities that communicate directly with one another by mes sage passing is adopted by Thoth [Gentleman 1981] and various Actor languages [Agha 1986].
This approach allows any Object to communicate with any other Object. Objects become active in response to communication. This implies that threads of control are determined implicitly by message passing, (whereas in the previous approach each thread of control is localised in an explicit Process Object) [Nierstrasz 1989J. Message passing is utilised for both communication and synchronisation and because of this explicit synchronisation is not neces- sary.
May 1994 C Kyriakides Page 45 Object Technology Concepts Object-Oriented Parallel Paradigms
However what is necessary is to decide what style of message passing to adopt. For example, message passing may be synchronous as in POOL-T [America 1987] or buffered, as between top-level Objects in Hybrid [Nierstrasz 1987]. Furthermore, we may permit unidirectional message passing as in Act-l [Lieberman 1987], or we may insist on a call/return protocol as in Hybrid [Nierstrasz 1987] and Concurrent Smalltalk [Yokote 1986]. It may also prove useful to provide an express mode of message passing for interrupting active Objects as in ABCL/l [Yonezawa 1986]. (In the following section we will discuss such message based interaction in greater detail).
Using strong- and weak-typing in the message passing approach, we may interpret the fol lowing: strong-typing reveals that a message-passing expression is type-correct if the message sent is guaranteed to be valid for the recipient; an untyped view is supported if all Objects are prepared to handle any message sent to them. Run-time support for concurrent applications based on strongly- and weakly-typed models can be quite different.
3.U Interaction Primitives based on Message Passing
In most pure Object-Oriented systems, (e.g. Smalltalk) interaction between Objects takes place exclusively by means of message passing. Keeping this in mind, this section will briefly present a number of interaction primitives for concurrent systems based on message passing protocols (this work is based on [Tomlinson 1989]).
In order to simply our discussion, we define the following terms:
sender: refers to the object sending the message. receiver refers to the object receiving the message. send: refers to the sending of a message. receive: refers to the construct indicating that an object is ready to receive a message. call: in the case where two messages are exchanged as a direct consequence of a single interaction event we refer to the first message as a call. reply: in the case where two messages are exchanged as a direct consequence of a single interaction event we refer to the second message as a reply.
Constructs may be synchronous or asynchronous. A synchronous construct causes an object to block until some other message-related event occurs. An asynchronous construct permits the
May 1994 C Kyriakides Page 46 Object Technology Concepts Objed"()riented Parallel Paradipls
object to continue processing once the construct is executed locally. Thus four possible choices exist: blocking send, nonblocking send, blocking receive, and nonblocking receive. Broadcasting occurs when two or more objects receive a single message.
Asynchronous message passing comprises of a single interaction message with a nonblocking send and a blocking receive. A receive construct blocks until a message is available to be processed; while, a send construct simply hands the message over to the underlying system to be delivered without blocking the sender. Asynchronous message passing gives rise to a mail system where messages send but not yet received are buffered.
A B
A!ynchronous Message Passing
Synchronous message passing comprises of a single interaction message with a blocking send and a blocking receive. 11,e send blocks until the receiver accepts the message and the receive blocks until there is a message available. In the diagrams presented below a blocked process is indicated by faint lines.
A
I + S}lIchrooous MessagePassing
Asynchronous message passing may be used to implement synchronous message passing. Fur thermore, synchronous message passing in conjunction with various buffering strategies can be used to implement asynchronous message passing.
May 1994 C Kyrialddu Page 47 Object Technology Concepts ObjKt.Oriented ParaDel Paradigms
Under NonBlocking Remote Procedure Call (rpc) two interaction messages take place: a call (with a blocking send) and a reply (with a nonblockingsend). The receiving object is blocked from the moment it issues a receive statement which indicates that it is ready to receive a particular message until it receives such a message. While, the sending object is blocked from the moment it sends a message until the target returns a result. (The target will only return a result sometime after it has issued a receive statement that accepts that particular message). The method invoked in the target may specify additional post-processing after the return statement is executed.
NonBlocIcing RemoteProcedure Call
Under future rpc, two interaction messages take place: a call (with a nonblocking send) and a reply (with a nonblocking send). The sender sends a call message together with the handle of the variable to which the result should be returned when available; after sending the message the sender resumes processing. The sender only halts processing if it requires to use the variable before the result has been returned. The receiver halts processing from the moment it issues a receive construct until it receives a message. After the receiver sends a reply it may continue processing.
A B
Future Remote Procedure Call
May 1994 C Kyrialddes Page 48 Object Technology Concepts Objed.()riented ParaUel Paradigms
I Blocking Remote Procedure Call (rpc): two interaction messages take place, a call (with a blocking send) and a reply (with a blocking send). The sending object is blocked from the moment it sends a message until it receives the result from the target. The receiving object is blocked from the moment it replies until it receives a message. (This implies that an object is active processing only from the moment it receives a message to the moment it returns the result).
A
Blocking Remote Procedure Call 3.13 Object Management
Object management refers to various aspects regarding Objects such as Object naming persistence, concurrency, distribution, version control, and security. To a large extend the application domain serves to determine the amount of support required for each of the Object management features. For example, Objects that reside in a workspace that is local and private will have different requirements to those Objects residing in a workspace that is distributed and shared.
In C+ +, Object management support is kept to a minimum; namely, garbage collection, per sistence, concurrency and distribution are not supported. Thus, the C++ environment imposes very limited run-time overheads for Objects. Nonetheless, various extensions can be defmed to support persistence, concurrency, garbage collection, etc. Furthermore, Objects ~ay be allocated and freed in virtual memory. In C+ +, memory addresses serve as implicit Object identifiers.
Smalltalk and LISP environments provide for automatic garbage collection. Furthermore, a trivial form of persistence is implemented permitting users to save the single-user Object workspace. Note however that, global consistency in a distributed environment is not required as no provision is made for communicating between Objects in different workspaces. Nonetheless, persistence for
May 1994 C Kyriakides Page 49 Object Technology Concepts Objecf-Orienfed Parallel Paradigms
distributed Object applications should be able to cope with the possibility of local failures: global inconsistency may arise if a message sent between two workspaces is lost, or if either the sender or receiver is accidentally destroyed. [Nierstrasz 1989]
Support for persistence, resilience, reliable communication, and distributed Object naming may be provided at a low level by an Object-Oriented operating system. For example, kernel support for distributed Object-Oriented systems is provided by Chorus [Zimmermann 1984] and Mach [Jones 1986].In contrast, Argus is a programming language with operating system support for persistence, encapsulation, and distribution through the concept of guardians [Liskov 1983].
3.14 Object-Oriented Databases
Object-Oriented databases provide database support (such as persistence, transactions, querying, etc.) for Objects. Database Objects represent both encapsulated data and operations. Examples of Object-Oriented databases include the GemStone system [Maier 1986; Purdy 1987], ORION [Banerjee 1987a, 1987b; Kim 1989b], and Iris [Derrett 1985; Fishman 1987, 1989].
Despite numerous practical Object-Oriented database applications currently in existence, several problems are encountered. One of these problems is that no agreement exists on a standard data model for Object-Oriented databases. Also, because there is currently no equivalent of relational algebra for an Object-Oriented data model, programmers have no standard guidelines for designing Object-Oriented databases. This can be partly attributed to the fact that we have no corresponding agreement as to what mechanisms belong in an Object-Oriented environment, nor what the rules of encapsulation or inheritance should be. For this reason it is also difficult to decide on a standard query language for Objects.
With regards to standardisations, one currently evolving standard, that of the Object Management Group (OMG) [OMG 1993] will be discussed in later chapters. For the time being it will suffice to state that its primary focus pertains to achieving greater inter-operability between Objects. This is done by establishing standard interfaces to the majority of commonly used kinds of Objects. It is anticipated that this will result in a network of interoperable OMG compatible applications. As will be the case with most OMG compatible applications, in OODBs this implies compliance to the OMG model only with regards to the external interface of the OODB application.
May 1994 C KyriaJddes Page 50 Object Technology Concepts Objert-Qriented Parallel Paradigms
3.15 Object-Oriented Programming Environments
In essence, Object-Oriented tools and environments are aimed at assisting application designers to select Objects, reuse Objects, manage an evolving software base, and also, to exploit the Object Oriented paradigms available. Object-Oriented tools and environments usually incorporate a soft ware base consisting of a multitude Objects. These software base Objects are aimed at providing the application designer with enhanced capabilities. Unfortunately, most of these software base Objects are non-standard (being at best vendor-specific or at a worst version-specific).
The next issue to be discussed is introduced by the following quotation:
We have to accept changing requirements as a lad 01 Iile, and not condemn them as a product 01 sloppy thinking. [FISher 1989]
Object-Oriented programming environments must cope with the evolution of the software base. Software management tools must be provided to maintain global consistency. When changes are made to the software base it is important that these changes be properly distributed. As long as the interface to an Object Class is not modified, we have considerable freedom in modifying its realisation. However, if the interface is changed we end up we numerous invalidated references between Object Classes.
Prototyping and application development are much easier with a well-designed software base. A problem related to the evolution of progressivelyimproved software bases is how do we determine the most suitable Objects to include in the software base?
3.16 Conclusion: Object Technology Concepts
From the above mentioned Object Technology Concepts it is clear that like most frequently used technologies, Object Technology is continually evolving. Nonetheless, some Object Technology concepts have remained more or less unaltered from the earliest embryonic stages of Object Technology (starting with Simula and continuing to Smalltalk, etc.). In contrast other Object Technology concepts have gradually involved along with the Object Technology. As with most evolving fields, what will be noted in Object Technologies is that in a number of models the same terminology will occasionally be used to refer to slightly different Object Technology concepts. In rare cases, the same term may unintentionally be used to refer to very different concepts.
May 1994 C Kyriakides Page 51 Object Technology Methodologies Objed'()riented Parallel Paradigms
4 Object Technology Methodologies
This chapter briefly presents methodologies in terms of design/development guidelines. The purpose of these guidelines are to assist system/application developers to create Object Technologies with improved characteristics (such as: encapsulation, reusability, maintainability, etc.),
The first methodology to be presented here is that of Responsibility-Driven Design proposed by Wirfs-Brock [1989]. As will be seen, the Responsibility-Driven Design attempts to maximise encap sulation by defining the responsibilities (services) of objects prior to defining their structure (attrib utes).
This is followed by the Law of Demeter proposed by Lieberherr [1989]. The Law of Demeter attempts to reduce coupling between objects by limiting their interconnections. (Please note that, although the Law of Demeter is embodied in a programming tool called Demeter, in this research we are only concerned with the Law itself which is a methodology).
4.1 Data-Driven vs Responsibility-Driven Design
The first model that we consider is the Responsibility-Driven design as proposed by Wirfs-Brock [1989]. The primary purpose of the Responsibility-Driven approach is to maximise encapsulation. As will be seen this is accomplished by defining the responsibilities (services) of objects prior to defining their structure (attributes). The significance of maximising encapsulation lies in the fact that encapsulation is the key to increasing the value of such software metrics as reusability, refinability, testability, maintainability, and extensibility.
In order to recognize the distinctions between the Data-Driven approach and Responsibility Driven approach the following sketchy guideline should observed:
Data-Driven approach:
step 1: Define the structural information (i.e. Attributes)
step 2: Define the responsibilities (i.e. Services)
Responsibility-Driven approach:
step 1: Define the responsibilities (i.e. Services)
step 2: Define the structural information (i.e. Attributes)
May 1994 C Kyriakides Page 52 Object Technology Methodologies Objed'()riented ParaDei Paradigms
The primary issue raised by Wirfs-Brock [1989] is that design practises using a Data-Driven approach fail to maximize encapsulation because they focus too quickly on the implementation of Objects. Instead a Responsibility-Driven approach is more desirable as it improves encapsulation by deferring implementation until a later stage. In endeavouring to maximise encapsulation, the modularity of a model is maximised and as a direct consequence thereof system maintainability is greatly improved.
4.1.1 Data-Driven Design
An abstract data type is the encapsulation of data and algorithms that operate on that data. Abstract data types are designed by asking the questions: "What data does this type subsume?" and "What algorithms can be applied to this data?".
Data-Driven design is the result of adapting abstract data type design methods to Object Oriented programming. In a Data-Driven design, Objects are designed by asking the questions: "What (structure] does this object represent?" and "What operations can be performed on this object?"
The main benefit of Data-Driven approach is that it is a familiar process for programmers experienced with traditional procedural languages.
Even though the goal of the Data-Driven design is to encapsulate data and algorithms, it inherently violates that encapsulation by making the structure of the object part of the defi nition of that object. This in turn leads to the definition of operations that reflect that structure (because they were designed with that structure in mind). Attempts to change the structure of an object transparently are destined to fail because other classes rely on that structure. This is the antithesis of encapsulation.
4.1.2 Responsibility-Driven Design
The goal of Responsibility-Driven design is to improve encapsulation. It does so by viewing a program in terms of the client/server model (addressed in section 4.1.2.1).
May 1994 C Kyriakides Page 53 Object Technology Methodologies Object-Oriented ParaDel Paradigms
A Responsibility-Driven design focuses on the contract (addressed in section 4.1.2.1) byask ing: "What actions is this object responsible for?" and "What information does this object share?".
An important point is that information shared by an object mayor may not be part of the structure of that object. That is, the object may compute that information, or it may delegate the request for information to another object. For example, a person's age may be calculated from his date-of-birth.
The Responsibility-Driven approach emphasizes the encapsulation of both the structure and behaviour of objects. By focusing on the contractual responsibilities of a class, the designer is able to postpone implementation considerations until the implementation phase.
Encapsulation is compromised when the structural details of an object become part of the interface to that object. This can only occur if the designer uses knowledge of those structural details. Responsibility-Driven designs maximize encapsulation when the designer intentionally ignores this structural detail information.
Definition: An operator whose meaning depends on the types of its operands is called overloaded, polymorphic, or generic [Ghezzi 1987].
Polymorphism increases encapsulation because the client of the object does not need to know how the object implements the service being requested, nor which class (type) is responding to the request. The Responsibility-Driven approach can help a designer identify standard protocols (message names) by encouraging the designer to focus on responsibilities indepen dently of implementation. This facilitates polymorphism.
Designing classes without knowledge of their structure encourages the design of the inheri tance hierarchy to follow a type hierarchy, because only the types of the classes are known. If the inheritance hierarchy follows a type hierarchy, then the type of every class is a subtype of the type of every superclass of that class [Cardelli 1985]. This has two advantages:
It improves encapsulation with respect to subclass clients [Halbert 1987], ensuring that all inherited behaviour is part of the contract of subclasses.
May 1994 C Kyriakides Page 54 Object Technology Methodologies Object.Qriented Parallel Paradigms
It makes abstract classes easier to identify. One difficultyin identifying abstract classes lies in determining what parts of the protocol's existing classes are parts of the type of those classes, and what parts are implementation details. Because the protocol of a class includes only those messages which form the type of the class, this problem is eliminated.
4.1.2.1 The Client/Server Model
The client/server model presented here is done in order to demonstrate a pragmatic application of the Responsibility-Driven approach. The client/server model is an anthro pomorphism based on the premise that inter-entity relationships may be manifested by one entity, the client, requesting another entity, the server, to perform some computation on the client's behalf.
The advantage of the client/server model is that it focuses on "what" the server does for the client, rather than "how"the server does it. The implementation of the server is encapsulated - locked away from the client. In this context, a strong analogy exists between the client/server model and the Responsibility-Driven approach.
Thus, the client/server model is a description of the interaction between two entities: the client and the server. A client makes requests of the server to perform services. The server provides a set of services upon request. The ways in which a client can interact with the server are described by a contract. A contract is a list of the requests that can be made of the server by the client. Both must fulfill the contract: the client by making only those requests it specifies, and the server responding to those requests.
In Object-Oriented programming, both the client and server are either classes or instances of classes. Any object can act as either a server or a client at any given time.
A class may have three distinct types of client:
An external client of a class is an object that sends messages to an instance of the class or the class itself. The receiver is viewed as a server, and the sender is viewed as a client. How the message is responded to should not be important to the sender. The set of messages that an object responds to, including the types of arguments and the return type, defines the contract between the client and the server.
May 1994 C Kyriakides Page 55 Object Technology Methodologies Object-Oriented Parallel Paradigms
A subclass client of a class is any class that inherits from the class. The superclass is viewed as a server, the subclass is viewed as a client. The subclass should not care about the implementation of any behaviour which it inherits [Snyder 1986b]. The set of messages that are inherited by the subclass detines the contract between the client and the server. (In most Object-Oriented languages, subclasses inherit not only the beha viour but also the structure defined by their superclasses. This is unfortunate, as it tends to encourage programmers to violate encapsulation in order to increase the amount of code reused).
The self client: For the purpose of maximizing encapsulation, classes should be viewed as clients of themselves. The amount of code relying directly on the structure of the class should be minimized. In other words, the structure of the class should be encapsulated in the minimum number of methods. This minimizes the reliance of an object on its own structure, allowing changes to that structure to be made as trans parently as possible.
4.1.3 Comparing Responsibility-Driven and Data-Driven Design
Responsibility-Driven design specifies object behaviour before object structure and other implementation considerations are determined. This minimises the rework required for major design changes.
Responsibility-Driven designs can lead to early definitions of Abstract Classes.
Object structure is specified during the implementation of a Responsibility-Driven design. During the implementation stage performance considerations can lead to adjustments of the Object's responsibilities. The goal during implementation is to preserve encapsulation while renegotiating the client/server contracts.
Data-Driven design, on the other hand, quickly leads to prescribing object structure. Building abstract classes involves fmding the abstraction and lifting it out of a set of concrete classes. Client objects of a Data-Driven designed object can (and often do) become dependent upon the specific structure of the Object, making more difficult the task of developing an abstraction while preserving the contract between clients and servers.
May 1994 C Kyriakides Page 56 Object Technology Methodologies Object'(}riented ParaDel Paradigms
4.1.4 Language Support
There are a number of forms of language support that can help maintain the high degree of encapsulation achieved during the design phase. Two of these are listed below:
4.1.4.1 Limiting Access to Variables
Directly accessing the state (variables) of an object violates the encapsulation of a class with respect to at least one of the three types of contracts defined in section 4.1.2.1 [Wirfs-Brock 1988b]. Which type of contract depends on the type of client that accesses the state.
4.1.4.2 Limiting Access to Behaviour
In addition to limiting access to state, a language should allow the programmer to limit the access to the behaviour of a class. It is reasonable to assume that subclass clients should have all access permitted to external clients. The access granted to the class itself should similarly include all of the access permitted to subclass clients.
Eiffel [Meyer 1988, 1990] allows a much more finely grained specification of access. Each feature (variable or function) can be given a list of classes that can access it. This list contains the clients whose contract includes the feature.
4.1.5 Conclusion of Responsibility-Driven vs Data-Driven Design
Object-Oriented Languages provide a number of mechanisms for improving encapsulation, but it is during the design phase that the greatest leverage can be realised.
The Data-Driven approach to Object-Oriented design focuses on the structure of the data in a system. This results in the incorporation of structural information in the definitions of classes. Doing so violates encapsulation.
This violation of encapsulation is attributed to the fact that when the structural information is defined before the contractual responsibilities are defined, this structural information can end up creeping into the contractual responsibilities of a class. Recalling from section 4.1.2, this violation of encapsulation is aggravated by the fact that information shared by an object may or may not be part of the structure of that object. In other words, the object may compute
May 1994 C Kyriakides Page 57 Object Technology Methodologies Objed.Qriented Parallel Paradigms
that information, or it may delegate the request for information to another object. The implication of this is that in attempting to alter the structural information of one class we may end up having to alter not only the contractual responsibilities of that particular class but also numerous of the classes that communicate with it.
The Responsibility-Driven approach emphasizes the encapsulation of both the structure and behaviour of objects. By focusing on the contractual responsibilities of a class, the designer is able to postpone implementation considerations until the implementation phase.
While Responsibility-Driven design is not the only technique addressing this problem, most other techniques attempt to enforce encapsulation during the implementation phase. This is too late in the software life-cycle to achieve maximum benefits.
It is clear that the Responsibility-Driven approach [Wirfs-Brock 1989] benefits encapsulation. What is not that clear is that naming abstractions can further enhance encapsulation; since, the name of a method could unintentionally disclose an attribute's structure. For example, an object of type person could have an attribute called assets; a method name of asset-acquired is preferable to append-asset-to-asset-list. It is argued by Wirfs-Brock that this problem arises from a Data-Driven approach. It is furthermore stated that the Responsibility-Driven approach addresses this issue by deferring the structure definition to be formulated only after the behaviour has been defined. Even though these arguments are not without merit, they present a rather myopic view of software development. During software development it is frequently required to modify specifications while the application is under development; furthermore, existing applications may require modification. In both these cases, both parts of the object behaviour and structure already exist. In this case it is thus more pragmatic to adopt a Responsibility-Driven approach in conjunction with a policy of (behaviour and structure) naming abstractions. In view of practical implications, the level of encapsulation attainable by the Responsibility-Driven approach is significantly enhanced by extending the Responsibility Driven approach to specifically incorporate naming abstractions.
4.1.6 Yourdon's OOA and Responsibility-Driven Design
Yourdon [1989] proposes a methodology adopting a Data-Driven approach to analysis. Your don provides guidelines in identifying objects, structures, subjects, attributes and services. One point of interest lies in subjects providing a mechanism for restricting the number of objects
May 1994 C Kyriakides Page 58 Object Technology Methodologies Object.Qrienttd ParaDel Paradigms
that an analyst has to consider at any given time. The fundamental idea behind subjects lies in attempting to address Miller's 7 ~ 2 rule [Miller 1956): human short-term memory is limited to addressing between 5 to 9 things.
Unfortunately, Yourdon's methodology defines object attributes before the services are defined. As discussed above, this may result in violations of encapsulation. Thus it would be preferable to adapt Yourdon's OOA to the Responsibility-Driven Approach by defining the Services prior to defining the Attributes. As this can be easily accomplished, readers deciding to delve deeper into Yourdon's OOA should keep in mind the benefits of the Responsibility Driven approach.
4.2 The Law of Demeter
The Law of Demeter ([Lieberherr 1988), [Lieberherr 1989)) presents a guideline relating to the principle of loose coupling; namely, the degree of coupling between objects is reduced by limiting their interconnections. The aim of the Law or Demeter is to organise and reduce dependencies between Classes and thereby maximise encapsulation. The law states that the methods of a class should not be dependent in any way on the structure of any class except the immediate (top-level) structure of their own class.
Furthermore, each method should only send messages to objects belonging to a very limited set of classes [Sakkinen 1988]. This assists understanding classes in isolation (or at least, to a large degree, independent of other classes); reusability is also improved.
Before elaborating on the definition of the Law of Demeter, the following terminology is pres ented:
Instance variables: Attributes of an Instance. Class variables: Attributes of a Class; shared by all Instances of the Class.
The Law or Demeter [Budd 1991]: In any method M attached to a class C, only methods defined by the following classes may be used:
The instance variable classes of C.
The argument classes of method M (including C); note that global objects or objects created inside the method M are considered arguments to M.
May 1994 C Kyriakides Page 59 Object Technology Methodologies Objed.Qriented Parallel Paradigms
The Law states that a Message can be sent only to:
Message arguments,
instance variables,
new Objects returned by a Message-send, and
global variables.
The law exists in two primary forms, a strong and a weak form; both forms endeavour to reduce the degree of coupling between objects by limiting their interconnections. The strong form of the Law disallows sending Messages to inherited instance variables. The weak form of the Law allows inherited instance variables to be referenced.
Compliance to the Law of Demeter implies that methods do not directly manipulate instance variables in another class. Since the classes interact in simple and well-defmed ways, classes can be studied and understood in isolation from one another.
If however the law was not complied to and methods could access instance variables in another class, then the object containing the said method will be dependent on the internal representation of that class (a form of internal data coupling); thus reusability and the ability to understand the purpose of each object independently will be greatly diminished.
Sakkinen [1988] presents a number of arguments against the initial proposal of the Law of Demeter as presented in Lieberherr [1988]. Keeping in mind that Demeter is an Object-Oriented programming tool, Sakkinen states that (owing to its dependency on compile time verification) the Law of Demeter is not very effective with untyped languages; a more appropriate statement would be that the Demeter tool is not very effective with untyped languages. In reply to Sakkinen, Lieberherr [1989] proposes a new defmition of the law encompassing the effects of strong- and weak-types.
4.2.1 Basic Concept of the Law of Demeter
The Law of Demeter is aimed at organising and reducing dependencies between Classes. Informally, the Law can be summarised by the following:
Each method can only send Messages to a limited set of Objects, namely to the Argument Objects and to the immediate subparts of the Class to which the method is attached.
May 1994 C Kyriakides Page 60 Object Technology Methodologies Objm-Oriented ParaDel Paradigms
Each method is "dependent" on a limited set of Objects (organise dependencies). Each method "collaborates" with a limited set of Objects (organise collaborations).
4.2.1.1 Formulation Options of the Law of Demeter
The Law can be formulated by choosing between the following independent possibilities: [Lieberherr 1989]
Object/Class: The Law can be formulated in terms of Objects or in terms of Classes. The "Class" formulation is aimed at being compile-time checkable. The "Object" formulation is aimed at being followed conceptually and not to be enforced statically by a tool.
Messages/generic functions/methods: The Law can be formulated in terms of Message sending, generic function calls or methods. The generic function call formulation distinguishes between two alternatives: method selection arguments and, several method selection arguments.
Weak/strong: Depending on how the term "instance variable" is interpreted, two different formulations arise for the Law. If the term "instance variable" is inter preted as all instance variables including inherited ones, we get the weak form of the LaW; if however, inherited instance variables are excluded, we get the strong form of the Law.
4.2.2 Advantages and Disadvantages
In presenting the rest of this section we conceptually fabricate a distinction between the fun damental concept of the Law of Demeter as presented above (which will be referred to in this section as the Law of Demeter) and the Demeter tool.
The Demeter tool results from taking a Data-Driven view of Object-Oriented programming. All Objects returned from a Message-send are regarded as potential encapsulation violations, as those returned Objects may reflect the internal structure of the receiver. This view, which treats all returned Objects as Trojan horses, is in direct contrast to our view of a client/server relationship. In the responsibility-driven approach, returned values are part of the client/server contract. There need be no correlation between the structure of an Object and the Object returned by a Message.
May 1994 C Kyrialddes Page 61 Object Technology Methodologies Objed-Oriented Parallel Paradigms
While the Law of Demeter does improve encapsulation, the Demeter tool confuses the design or implementation of the set of Services offered by a Class. To avoid sending a Message to a returned value (which is known to be part of the structure of the receiver), Lieberherr, Hol land and Riel propose adding Messages to all intermediary server Objects [Lieberherr 1988, Lieberherr 1989]. These methods exist to relay Messages to a component of an Object's structure. If this encapsulation technique were carried out to an extreme, all possible Messages understood by publicly accessible instance variables of an Object would have corresponding relay methods. Adding these Messages to an Object would almost certainly violate the type hierarchy. Maintainability and extensibility are then compromised.
The weak form of the Law of Demeter provides encapsulation for external clients of an Object. The strong form of the Law provides encapsulation between subclass clients. No cor responding formulation of the Law exists to realise self-encapsulation. In responsibility-driven design, self, subclass and external client encapsulation is achieved through the same technique, namely limiting variable access [Wirfs-Brock 1988a].
4.2.3 Conclusion on the Law of Demeter
The Law of Demeter promotes a restriction on Message sendings to Objects. The basic idea of the Law of Demeter is accepted to be beneficial. It must be noted however that, from a compile-time verification perspective, the formulation of the Law in terms of Classes is more useful than in terms of Objects; this can be attributed to the fact that the Class formulation can be checked at compile time. However, only with typed languages is the compile time Class formulation check possible; thus, in the case of untyped languages, no compile time Class formulation check is possible. This is the reason given by Sakkinen [1988] to enforce the fact that Demeter tool is more effective for typed languages.
May 1994 C Kyriakides Page 62 Object Technology Methodologies Objed.()riented Parallel Paradigms
5 Parallel Object-Oriented Concepts
This chapter briefly presents several fundamental issues pertaining to parallelism within the con text of Object Technologies. Design considerations necessary for developing parallel Object Oriented systems are also presented. Furthermore, a taxonomy by Wegner [1989] is presented for classifying Objects based on their granularity.
We propose a taxonomy for describing inter-Object relationships with regards to their parallel processing characteristics. Also, an adaptation of the theory on productivity and workloads for the parallel computer processing is proposed.
In pure Object Technologies, messages serve as the mechanism for effecting communication between Objects. However, in the majority of parallel Object Technologies, messages also act as a transparent synchronisation mechanism.
May 1994 C Kyriakides Page 63 Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
5 Parallel Object-Oriented Concepts
This chapter presents fundamental issues concerned with parallelism within the context of Object Technologies. Only issues having a bearing on the OOPP research are dealt with. The outline followed in this chapter entails a section dealing in general with object-oriented parallelism considerations. This is followed by a section describing Wegner's granularity of modules - a classification terminology pertaining to abstraction boundaries of modules. In order to enable classification of parallelism characteristics within the context of objects, we present a new object taxonomy. OOPP's Object Tax onomy is aimed primarily at providing a vehicle whereby internal and external parallelism character istics of objects can be described; this is done with the view of providing terminology allowing for the formulation of object-to-processor mapping algorithms. This is followed by a brief section on productivity and workloads in computers.
In Object Technologies, messages are natural mechanisms serving two primary roles: firstly, messages act as a communication mechanism between Objects; and secondly, messages serve as a transparent mechanism effecting synchronisation between different Objects. Ascribed to this dual role of messages, we present the following quotation:
It is a mistake to ignore communication costs in detennining the complexity of a parallel algorithm. Sometimes the communication complexity dominates the computational complexity; in other words, more time is spent routing data among processors than actually manipulating the data. [Quinn 1987]
Thus in parallel architectures, inter-processor communication can prove to be a very expensive exercise. Certain architectures, such as the fully-interconnected architecture, attempted to overcome the inter-processor communication costs by letting each processor be one link away from every other processor. Unfortunately, the present technology is incapable of producing infinitely large fulIy interconnected processor architectures. Furthermore, in the current technology, inter-processor com munication is sluggish owing to a reasonably large time required to establish transmission between two neighbouring processors.
Shared Memory in (Tightly Coupled) multiprocessor architectures attempted to make common data available to various processors by means of implementing a global memory which all processors could access. This unfortunately creates a bottleneck when many processors are simultaneously attempting to access the common memory. Generally, the bottleneck effect is aggravated as the number of pra cessors incorporated in the system increases. Further aggravating the situation is the fact that numerous synchronous algorithms have been developed for multiprocessors and these algorithms rely
May 1994 C Kyriakides Page 64 Parallel Object-Oriented Concepts Objed.()riented Parallel Paradigms
on data stored in the shared memory for synchronisation purposes. Thus the Tightly Coupled (Shared Memory) multiprocessor architecture is suitable only for systems having a limited number of proces sors or systems requiring very little synchronisation (e.g., asynchronous algorithms).
The Processor-memory pair of the (Loosely Coupled) multicomputer architecture attempted to overcome the presence of a bottleneck similar to that of the Shared Memory model by avoiding global memory altogether. Instead each processor has its own memory, and communication between pro cessors is achieved by means of sending information from processor to processor until the appropriate processor is reached. Keeping in mind the "computing cost" of inter-processor communication, the limitations of this architecture are obvious: If two processors that need to communicate are not close to each other (according to the number of inter-processor links), then the cost of communication between any two such processors is great. Also, synchronisation based on the multicomputer model is more complex (than that of the multiprocessor model) since we need to keep track in which processor resides the process that we need to synchronise with.
Note that with traditional parallel systems, interprocessor communication is used to refer to com munication between two or more processors. However, this is somewhat of a misnomer as it is the processes residing in those processors that need to communicate. In the Object-Oriented Parallel Paradigm, interprocessor communication is used to refer to communication between processes residing in different processors; while interprocess communication is used to refer to communication between processes irrespective of whether they are located in tbe same processor or not.
Thus, interprocess communication results in interprocessor communication costs if and only if the two processes involved in the communication reside in different processors. Since most messages serve as interprocess communication mechanisms, it is easy to see the relationship tbat arises between mes sages and interprocessor communication costs. We will elaborate on this in the following section.
Currently, the multicomputer model (processor-memory pairs) is favoured by developers over the multiprocessor model (shared memory). Tomlinson and Scheevel [Tomlinson 1989] have pointed out that alternative shared memory models of concurrency do not lend themselves as well to parallel or distributed implementations as do encapsulated models.
Numerous architectures and theories have evolved in order to overcome the limitations mentioned above. The fully-interconnected architecture is one such development; unfortunately the number of possible processors in such an architecture is limited by our current technological capabilities. Another more recent development, is an architecture that allows for both processor-memory pairs as well as
May1994 C Kyriakides Page 65 Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
global memory. (This could prove to be a case of improving an inadequate tightly-coupled architecture by introducing to each processor some memory; or alternatively, a case of deteriorating a flexible loosely-coupled architecture by introducing undesirable tightly-coupled characteristics).
5.1 Design Considerations
In this section we present several of the primary design considerations behind the oopp devel opment. Although dealing with parallel systems in general, the design considerations listed below had a significant influence in the direction followed by the OOPP proposal.
In general, programming tools may be used to enhance programming environments and thereby ease development within the guidelines of existing methodologies. Some of the guidelines pres ented below may be incorporated into such programming tools so as to ease compliance to an actual methodology. Nonetheless, irrespective of whether or not a particular methodology supports extensions proposed by the under mentioned guidelines, it should at least be capable of facilitating them.
1 Designer productivity and ergonomics should be kept in mind.
a) The designer should not be burdened with implementation or petformance characteristics during the analysis phase of a proposed project. These should be preferably postponed to the implementation phase or, if possible, be transparently introduced by the proposed paradigm.
b) If possible, avoid introducing too many rules in a paradigm. If rules are to be introduced to the paradigm, then stick to the most crucial ones. This can be attributed to the fact that any paradigm burdened with numerous roles that are not checked by some automated means will either not be remembered and correctly implemented, or will be a likely candidate for misuse.
To elaborate, a designer forced to follow numerous restrictions imposed by the para digm, will typically be highly unproductive and more concerned with the goal of adher ing to the restrictions (so as to present a "good" system with regards to the chosen paradigm), rather than concentrating on understanding the problem space at hand. Problem Space Understanding is more important in the design phase, as opposed to manipulating a model in order to obtain a "good" system as dictated by the paradigm. A similar argument holds for rules pertaining to implementation efficiency.
May 1994 C Kyriakides Page 66 Parallel Object-Oriented Concepts Objed.()riented Parallel Paradigms
2 Since inter-processor communication is costly, it should be kept at a minimum.
a) A paradigm which effortlessly/transparently keeps inter-processor communication costs to a minimum should be favoured over one that does not.
b) In keeping a group ofprocesses that require frequent communication between each other in close proximity, the designer/paradigm will subsequently keep the inter-processor communication costs to a minimum.
H two processes require large amounts of communication between each other, then the benefit of running those processes in a pseudo-parallel fashion in a single processor memory pair could be weighted-out against the benefit of running those processes on separate processors in parallel (and relying on inter-processor communication for the purpose of synchronisation). Thus, a paradigm should without much difficulty allow the choice of running processes in a pseudo-parallel fashion (on one processor) or true parallel fashion (on two or more processors). The system designer can then choose the outlay best suited to his system.
c) A paradigm should transparently give an indication as to the amount of communication typically expected between any two processes. This will prove beneficial in establishing which processes should be positioned in close proximity to each other.
Under some Object models this can be easily accommodated as communication between objects is restricted to message passing. The probability of a possible message exchange can be determined either analytically or by means of test cases. Thus by determining the probability of all possible messages and the respective interprocessor distance between senders and receivers, the interprocessor communication cost can be determined. However, in the case of object models where it is permissible for an object to be distributed over several processors (e.g., to accommodate parallel processes that may exist within an objects), determining the interprocessor communication cost is consid erably more complicated. In this case, interprocessor communication costs depend not only on messages exchanged, but also, on the object's method (i.e., the concurrent algorithm implemented within a particular method).
d) As was mentioned previously, two or more Objects could be assigned to an individual processor so as to limit communication costs between these Objects. It should be noted however that, inter-processor communication costs can also be reduced by limiting the
May 1994 C Kyriakicles Page 67 Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
number of Messages between these Objects. The number of possible Messages between any two Objects and their frequency can be used to estimate the demands imposed by the proposed system on inter-processor communication. This can be taken further by concentrating on the communication costs between any two Classes, and costly pairs identified should be kept as closely as possible, preferably in adjacent processors.
Thus, paradigms should preferably caterfor evaluating interprocessor communication costs between: - any two Objects, an Object and a Class, - a Class and an Object, and - any two Classes. This idea of one-to-one, one-to-many, many-to-one, and many-to-many communication has been adopted from PROCOL [van den Bos 1989] which will be elaborated on in section 733.
3 Bottlenecks should be avoided (or at least easily identified)
a) Reliance by a paradigm on Shared Memory/Global Data should be avoided as it creates bottlenecks. In fact, any data that is common to numerous processes will create a bottleneck irrespective of whether we are using a shared memory architecture, or a processor-memory pair.
b) To put the latter statement in a stronger sense, the key word here is "common". In fact, anything for which numerous processes will have to compete (i,e. shared memory, devices, communication mechanisms, etc.) will create a bottleneck.
4 A paradigm should allow the designer freedom from the low-level implications introduced by the machine architecture. This implies that the paradigm (or its programming environment) should have the responsibility to transparently cater for the following:
a) The number of processors required by any system designed within the confines of the paradigm should be close to optimum.
b) The designer should not be concerned with the physical mapping of the code and data in the available processors; the paradigm should take care of that.
May 1994 C Kyriakides Page 68 Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
c) Should the number of required processors exceed the number of available processors, then the proposed paradigm should have the ability to identify closely related data and processes, and place them in the same processor. In the event that overlays need to be implemented, excessive copying of both data and code in and out of the architecture will thereby be avoided.
5 On the other hand, doing almost an about face, the question arises whether resource and architecture requirements, imposed by the proposed system on the computing machinery, should be evident from the analysis/design stage. At any rate it is important that if such deviations are introduced in order to achieve greater efficiency or ease of implementation, as far as possible, these should be concealed from the analysis process.
As will become evident, paradigms intended for practical applications will need to consider practical limitations. The same cannot be said for theoretical paradigms; nonetheless, theo retical paradigms should be such that they can be refined, or restricted, to form practical paradigms.
a) For example, it is pointless designing an optimal/efficient system requiring thousands of processors, if we can only afford and/or source a system with 64 processors.
b) A similar argument holds for technological limitations regarding fully-interconnected architectures with thousands of processors; such assumptions, would result in paradigms that ignore the limitations imposed by the intcrprocessor communication costs.
c) Another point to raise here is that in some cases, the analyst is asked to determine the feasibility of the proposed system based on the software requirements and an existing machine to be run on. Thus a proposed analysis methodology must be capable of giving an indication of the feasibility of a system based on either:
hardware requirements (namely, assuming you can have everything you require, what resources do you require for optimum performance?), or
hardware limitations (namely, if you only have a specific set of resources, is the system proposed feasible?).
May 1994 C Kyriakides Page 69 Parallel Object-Oriented Concepts Objed'()riented Parallel Paradigms
d) Current trends in technological developments point towards large-scale highly reconfigurable machines presenting a designer with a group of virtual machines within one computer. If the machine is totally orpartiallyreconfigruable. then which architecture setup is bestsuited to a proposedsystem orpart thereof? This clearly raises another issue; II namely, can a paradigm be developed that will be able to determine the most suitable architecture for a proposed system or should this remain (as it currently is) a purely algorithmic problem?
One distinction to be made here between Object-Oriented parallel processing and traditional parallel processing is that Object-Oriented Parallel Processing algorithms tend to be dynamic in nature, allowing for Object creation and deletion; while, traditional Parallel Processing algorithms tend to be more static in nature.
The fact that Objects can be dynamicaIJy created and destroyed further complicates the Object to-processor mapping. Thus we may not be able to predict in advance the number of instances of any specific Object. This, in turn, introduces further complications by making it extremely difficult to predict the mapping of the Objects to the physical processors.
Also, an instance of an Object typically needs to frequently communicate with its superc1ass Object(s). One motivation for this is that, under some models, a method inherited is not neces sarily available in the Object instance but in its ancestor. Thus, as a rule-of-thumb, Objects belonging to the same Class should be placed in processors that are close to each other.
Theoretically, two primary modes of representing Objects exist:
Every Object instance has its own set of data, as well as, its own copy of the execution code of its methods.
Every Object instance has its own set of data and set of instruction pointers; however, it shares a single copy of the execution code with other Object instances residing in the same processor.
In the latter scenario, the Object Class is simply used as a template for the Object instance. This warrants further investigation but one possible scenario might prove useful: since only one process in a single processor can be run at any time instant, all Object instances of a single Class residing in a single processor should share a single copy of the execution code. Furthermore, where
May 1994 C Kyriakides Page 70 Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
different groups of Objects of the same Class reside in different processors, each group should have a copy of the execution code in its processor. Nonetheless, we still need to investigate how a Class that is an "instance" of its Superclass (and so forth) will be handled.
By expanding on the above guidelines, a more promising scenario is presented by set theory. Namely, if we assume each Object to have a set of methods, then we may extend the above guideline to consider a union of these sets. A single copy of code needs to be considered for each method present in the set. (The issue of restricting access of Objects to only allowable methods in a processor, does not fall within the confines of the paradigm, but rather, that of the pro gramming tool or compiler). We shall leave this approach to future research efforts.
Since Object instances are created dynamically, the question raised is, "what Objects should be placed in what physical processors and what slack should be allowed for the creation of new Object instances?" Clearly some slack must be allowed.
Alternatively, can specific Objects be identified that will have a limited number of instances? If so, then what benefits are attained regarding mapping of Objects to processors? In a broader sense, if Objects can be categorised into different groups according to rules governing their existence, then can any benefits arise when viewing Objects in such a manner? In section 5.3 we will attempt such a classification of Objects.
S.2 Wegner's Granularity of Modules
Wegner [1989J based the granularity of modules in an Object-based environment (defined in sec tion 1.7) on three factors:
Abstraction boundary (unit of encapsulation) the information-hiding interface a module presents to its users or clients.
Distribution boundary (unit of name space) the boundary of the name space accessible from within a module.
Synchronisation boundary (unit of concurrency) the boundary at which threads entering a module synchronise with ongoing activities in the module.
May 1994 C Kyriakides Page 71 Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
The Abstraction boundary specifies the unit of encapsulation and is the fundamental determinant of Object granularity. It determines the interface between an Object and its clients and the form in which resources provided by an Object to its client may be invoked.
The Distribution boundary is the boundary of accessible names visible from within an Object. The abstraction boundary is encountered by a user of a module looking inward while the distribution boundary is encountered by an agent within a module looking outward. When the abstraction and distribution boundaries coincide, then modules can communicate only by Message passing. We say a module is distributed if its distribution boundary coincides with its abstraction boundary.
Object-based programming requires a disciplined use of threads in a scenario where Objects have a well-defined notion of abstraction and distribution.
Concurrent Objects (processes) require incoming threads associated with Messages or remote procedure calls to synchronise with ongoing activitieswithin a process. If synchronisation can occur only at the abstraction boundary of processes, then processes are internally sequential and our model is one of communicating sequential processes. In this case the unit of abstraction coincides with the unit of concurrency.
Distributed sequential processes are attractively simple, both conceptually and in terms of their implementation. However their expressive power may be inadequate for certain applications.
Wegner [1989] divided processes into three categories:
Sequential process: A process that has just one thread.
Quasi-concurrent process: A process that has at most one active thread.
Concurrent process: A process that may have multiple active threads.
In addition to the issue of Granularity of Modules, Wegner [1989] goes on to discuss another issue, namely that of correctness for concurrent processes. Wegner's view on correctness for con current processes was briefly presented in section 2.4.
5.3 Object Taxonomy
In this section we propose an Object Taxonomy with the capability for expressing concurrent processing relationships between individual objects, groups of objects, as well as, individual
May 1994 C Kyriakides Page 72 Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
methods within an object. OOPP's Object Taxonomy was developed with the primary goal of providing adequate terminology capable of facilitating the development of object-to-processor mapping algorithms.
As will become evident, Wegner's [1989] Object-Based Sequential; Quasi-Concurrent and Concur rentProcesses (described in section 1.7) are not well-suited to formulating an Object-to-Processor mapping algorithm analogous to that required by OOPP's (Object-Oriented) environment.
Thus, we propose the following Object Taxonomy in order to assess if any benefits can be gained from viewing Objects in terms of rules governing an Object's existence.
Unique Objects: An Object is a Unique Object if only one such Object instance may exist at any particular time. (To elaborate, a Unique Object signifies an Object class of which only one instance may exist at any particular time). Multiple Objects: Objects that may have more than one Object instance at any particular time; and may be replicated if so desired.
Furthermore, with regards to Unique Objects, in models where inherited code is shared, only one copy of the superclass object exists; in models where a copy of inherited code exists as a copy within the actual instances, a unique object still constitutes a unique instance irre spective of the fact that inherited code is duplicated.
Non-Granular Objects: Objects that may be analyticallybroken down into smaller Objects. Granular Objects: Objects that from the analysis perspective cannot prove more beneficial if broken down into smaller Objects and as such are accepted to be the very basic building blocks of Non-Granular Objects.
(Please note that Granular Objects do not refer to an implementation environment's objects - such as primitive Objects - but to Objects arising as a result of the Analysis effort).
Method-Internally-Concurrent Objects: Objects that can exhibit concurrency within a single method; and Method-InternaUy-Sequential Objects: Objects whose methods are intrinsically sequential.
Melhod-Externally-Concurrent Objects: Objects that can have multiple methods executing concurrently; and Method-Externally-Sequential Objects: Objects that may not have multiple methods execut ing concurrently.
May 1994 C KyriaJddes Page 73 Parallel Object-Oriented Concepts Object-Oriented Parallel Paradigms
An Internally-Sequential Object is defined to be any Object that is both a Method Internally-Sequential and a Method-Externally-Sequential Object. An Internally-Concurrent Object is defined to be any Object that is either a Method-Internally-Concurrent Object, or a Method-Extemally-Concurrent Object, or both.
Any two Objects said to be Mutually-8equential Objects (with regards to each other) are defined to be any two Objects where the methods of the one Object may not execute con currently to the other Object's methods. Note that an Object may exhibit Internal Concurrency and still be Mutually-Sequential to another Object. Any two Objects said to be Mutually-Concurrent Objects (with regards to each other) are defmed to be any two Objects where the methods of the one Object may execute concur rently to the other Object's methods (if required to do so). Note that an Object may be Internally-Sequential and still be Mutually-Concurrent to another Object.
An Externally-Sequential Object is any Object that is Mutually-Sequential to all other Objects. An Externally-Concurrent Object is any Object that is Mutually-Concurrent to at least one Object.
An Object said to be an Exclusively-8equential Object is defined to be any Object that is both Internally-Sequential and Externally-Sequential.
Note that, when we refer to either Method-Internally-Concurrent or Method-Externally Concurrent Objects we are in effect referring to specific types of Internally-Concurrent Objects. Also, if an Object is said to be both Method-Internally-Sequential and Method-Externally Sequential then that Object is Internally-Sequential but not necessarily Externally-Sequential. From the above it is thus clear that even an Object having only a single method can exhibit either Method-Internal or Method-External Concurrency, or both; and because of that, can be an Internally-Concurrent Object.
In order to assist a part of our discussion which follows, we will take this opportunity to make the following defmition:
Object-to-Processor Density is defined to be the Number of Objects / Number of Processors. In other words, given a group of processors, we can establish the total number of Objects assigned to those processors and thus determine the Object-to-Processor Density.
May 1994 C Kyriakides Page 74 Parallel Object-Oriented Concepts Objen-Oriented Parallel Paradigms
If all Objects are now viewed in terms of the above Object Taxonomy then the following facts become immediately evident:
Since a group of Exclusively-Sequential Objects can only have methods execute one at a time, they can be placed in the same processor without having a negative effect on the processing speed of the system. This also applies to a group of Mutually-SequentiallntemalIy-Sequential Objects.
Since only one Exclusively-Sequential Object can be active at any instant, Groups of Exclusively-Sequential Objects should be kept as small as reasonably possible (in terms of their execution requirements). A connection exists here between Exclusively-Sequential Objects and Amdahl's Law, namely, the execution requirements of methods belonging to Exclusively-Sequential Objects can be likened to inherently sequential operations. Thus, the methods of such Objects should (as reasonably as possible), have limited processing requirements. A similar argument holds for Internally-Sequential Objects (i.e. Objects that are both Method-Externally-Sequential and Method-Internally-Sequential). The argument however does not span to:
Externally-Sequential Objects, or
Objects that are either Method-Externally-Sequential or Method-Internally-Sequential Objects, but not both,
as each of these Objects may exhibit strong Internal-Concurrency.
Unique Objects cannot be replicated and as such will rarely exert a significant effect on the dynamic Object-to-Processor density. The only wayan Object can influence the Object-to Processor density is by being created or destroyed, and since only one Unique Object may exist at any instant, its creation or deletion will rarely cause a significant effect on the Object-to-Processor density. Thus identifying Objects as Unique Objects can assist in for mulating an efficient Object-to-Processor mapping algorithm.
If an Object is said to be a Non-Granular Exclusively-Sequential Object then it should be considered whether or not it would be more beneficial to break down the Object into smaller Objects (i.e., identify an Assembly Structure [Yourdon 1989]) that may contain eligible can didates for parallel processing.
May 1994 C Kyrialddes Page 7S Parallel Object-Qriented Concepts Objea-Oriented Parallel Paradigms
J, Note that regarding the Inheritance rules of the above terminology, terms used to describe an Object's characteristics are not implicitly inheritable from Object to Object in Assembly Structures; however, they are implicitlyinheritable in Classification Structures. The reason for this is that unless Objects in a Classification Structure are modified, all Objects in that Classification Structure willbe identical to their parent Object; this uniformity does not hold for Objects in an Assembly Structure.
Unfortunately, owing to the power and diversity of the Object Taxonomy, only the simplest of systems can be assessed manually. Alternatively, if we wish to assess a large system by manually implementing the Object Taxonomy, then we may have to compromise by only using a subset of the Object Taxonomy. In any case, in order to be a useful tool in large-scale multi-processor systems development the Object Taxonomy needs to be either fully or partially automated.
Although the Object Taxonomy presented above was created with the Analysis phase in mind, it can also be applied to the implementation phase. From parallel processing theory it should be recalled that parallel processing algorithms may be substituted by equivalent sequential processing algorithms (as implied by serialisability [Herlihy 1989a)). The implications of this on the Object Taxonomy is that an object/method classified during analysis as mutually-concurrent to another object/method may still be implemented sequentially to each other. What is important to note is that the Analysis effort will indicate portions of the problem that may benefit from parallel pro cessing; nonetheless, these portions may still be solved sequentially.
5.3.1 Unaddressed issues of the Object Taxonomy
Numerous issues are raised under the Object Taxonomy. For example, can any Object be identified as being an Absolutely Granular Object? What this implies is whether an Object exists that cannot be further broken down into smaller Objects. For example, water can be thought of as consisting of H20 molecules. But this is only beneficial to our system if we require to know the chemical composition of water. What is important to note here is that Objects should be thOUght ofas being Granular Objectsif and only if we cannot gain any further benefits by breaking them down into smaller Objects.
Thus Absolute Granularity is not an issue at this stage. However the side-effect of an incorrect assumption as to whether an Object is Granular or Non-Granular is more troublesome. We currently have no proposal on how to detect such incorrect assumptions. The presence of such incorrect assumptions can cause an algorithm for identifying Objects that are eligible for
May 1994 C Kyriakides Page 76 Parallel Object-Oriented Concepts Object-Oriented ParaDel P8l'Ildigms
optimisation (bymeans of the Object Taxonomy) to ignore suitable Non-Granular Objects that were initially marked as being Granular Objects. Nonetheless, what should be appreciated here is that even though the Object Taxonomy and its associated guidelines are not exhaustive they can prove beneficial.
Another issue is whether such a Non-Granular Exclusively-Sequential Object can be broken down into a number of Objects that exhibit External- or Internal-Concurrency and, a limited number of Exclusively-Sequential Objects? If so, then will the benefits gained in a real-world system be substantial enough to warrant the additional complexity introduced by the increased number of Objects? (It is anticipated that this will depend/vary with individual cases).
Even though the defmition of Exclusively-Sequential Objects is straightforward, it remains to be seen whether or not it will be easyto discover such Objects in a real-world system. (Unless refined even further, we believe that the benefits gained by applying this guideline to every conceivable pair of Objects may not justify the effort required to do so).
5.3.2 Summary: Object Taxonomy
The Object Taxonomy presented above was developed in order to enable system analysts to express concurrent processing relationships between individual objects, groups of objects, as well as, individual methods within an object. The Object Taxonomy's expressive ability can greatly ease the formulation of object-to-processor mapping algorithms.
The table presented below briefly recaps OOPP's Object Taxonomy.
Unique Objects Any Object (Class) that may have only one such Object instance existing at any particular time.
Multiple Objects Any Object (Class) that may have more than one Object instance at any particular time.
Granular Objects An Object (Class) that, from the analysis perspective, can- not prove more beneficial if broken down into smaller Objects and as such are accepted to be the very basic building blocks of Non-Granular Objects.
May 1994 C Kyriakides Page 77 ParaDel Object-Oriented Concepts Object'()riented Parallel Paradigms
Non-Granular Objects An Object that may be analytically broken down into smaller Objects.
Method-lDternally Any Object that can exhibit concurrency within a single -Concurrent Object method.
Method-Internally Any Object whose methods are intrinsically sequential. -Sequential Object
Method-Externally Any Object that can have multiple methods executing con- -Concurrent Object currently.
Method-Externally An Object whose methods may execute only in a sequential -Sequential Object fashion.
Internally-Sequential Any Object that is both a Method-Internally-Sequential Object Object and a Method-Externally-Sequential Object.
IDternally-Concurrent Any Object that is either a Method-Internally-Concurrent Object Object, or a Method-Externally-Concurrent Object, or both.
Mutually-Sequential Any two Objects where the methods of the one Object may Objects not execute concurrently to the other Object's methods.
Mutually-Concurrent Any two Objects where the methods of the one Object may Objects execute concurrently to the other Object's methods (if required to do so).
Externally-Sequential Any Object that is Mutually-Sequential to all other Objects. Object
Externally-Concurrent Any Object that IS Mutually-Concurrent to at least one Object Object.
Exclusively-Sequential Any Object that IS both Internally-Sequential and Object Externally-Sequential.
May 1994 C Kyriakides Page 78 Parallel Object-Oriented Concepts Objeet-Oriented Parallel Paradigms
5.4 Object State and Method Coupling
Objects have been studied from numerous perspectives; examples include the responsibility-driven approach [Wirfs-Brock 1989], and object coupling [Lieberherr 1989] (both are described in section 4). In essence, OOPP's Object taxonomy deals primarily with the perspective of describing pro cessing relationships between groups of objects, as well as, fragments of objects. Furthermore in this section, we present yet another perspective, namely the object state dependency from the perspective of tight- and loose-coupling. The object state dependency is intended to serve as a guideline when mapping objects to processors.
In general, Object Technology attempts to achieve maximum encapsulation. One approach at maximising encapsulation, the responsibility-driven approach, attempts to achieve optimum encapsulation by minimising interobject data structure dependencies. Which prompts the question whether there are any other object dependencies based on data structures or state.
Let us consider Objects from the perspective of modules. From this perspective, Objects can be viewed as highly-independent modules of closely-related attributes and methods. Furthermore, we know that several methods may exist within an Object, and that an Object's attributes may be accessed by any method within the object. Thus, an Object's attributes may be viewed as analo gous to "global" variables accessible to the Object's methods. Similarly, methods may have internal variables that are not shared with other methods and can be viewed as local variables to the method. Thus each method can be viewed as a module within an Object (irrespective of whether these modules are highly-independent or not).
In order to simplify the discussion that follows, when a call can take place between two modules, we will refer to the module from which the call is issued as the client, while the module receiving the call will be referred to as the server.
Before continuing we make the following definition. For the sake of brevity, Ml, M2> M3,... rep resent modules. If (M1 can call MZ) then (MZ is one access link away from Ml). (Please note that this is a unidirectional relationship and does not mean that M1 is one access link away from MZ.) If (M1 can call MZ) and (M2 can call M3) then (M3 is two access links away from MD, and so on. (The term multiple access link is used to refer to an access link of any length larger than one.) It is clear that a model viewed from the perspective of access links can be depicted in terms of unidirectional graphs.
May 1994 C Kyriakides Page 79 Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
Furthermore, we take this opportunity to define the concept of state-coupling: In any one-access link client-server relationship, a client is said to be state-Independent of the server, if and only if:
for every possible call, the call from the client can be directed at any (separate) copy of the same server without altering the respective response to each call, and
for every possible sequence of calls, the calls from the client can be delivered in any possible order variation to the server without altering the respective response to each call.
In any multiple-access-link client-server relationship, the client is state-independent of its servers, if and only if, for each one-access-link of client-server relationship the client is state independent of its server. (This will be illustrated in observation 4 of state coupling below).
Any two modules that are not access linked to each other are also considered to be state independent of each other.
When a client is not state-independent of the server, the client is said to be state-coupled to the server.
As was mentioned, the access links of a model can be viewed in terms of a unidirectional graph. Viewing state-dependency relationships from the modules with no (outgoing) access links to modules with progressively larger access links appears to hold the greatest prospect.
The fundamental observations of State·Coupling/State·Independence are presented below:
Observation 1: In the arbitrary case where there is no access link between two modules, the modules are state-independent of each other.
Observation 2: In the case where the client is at most one-access-link away from its farthest server [i.e., Mj can call M2 and M2 does not call any other module) then, by definition:
if the client is state-independent of the server then client could be served by one or more copies of the server.
By definition (note "if and only if") the corollary of observation 2 also holds true, namely:
if any client can be served by two or more copies of its server (without affecting the result to each call respectively) then the client is state-independent of its server
May 1994 C Kyriakides Page 80 Parallel Object-Oriented Concepts Objed'()riented ParaDel Paradigms
Observation 3: The case used to describe observation 2 can be extended to the more general case where the client is at most one-access-link away from the server, but the server has two or more clients then:
if all clients are state-independent of the server then all clients are also state-independent of each other.
(This observation follows from observation 2 and by noting that the "maximum one-access link" also implies that any two clients cannot call each other.)
Observation 4: In the case where the client is at most two-access-links away from its farthest server (i.e., Ml can call Mz, M2 can call M3 and M3 does not call any other module) then, by definition:
if (Ml is state-independent of M2) and (M2 is state-independent of M3) then (Ml is state independent of M3).
(In other words, by definition Ml can be served by one or more copies of M2 and in tum M2 can be served by one or more copies on M3; thus, Ml can be served by one or more copies of M3.)
In a similar fashion, this above mentioned case can be extended to the more general case where the client is two or more access links away from its farthest server then:
if for every one-access-link client-server relationship the client is state-independent of its server, then the client (farthest from the last server) is state-independent of all its servers.
Observation S: In the case where the client is at most one-access-link away from the each server, but the client has two or more servers then this case can be reduced to multiple occurrences of the case in observation 2:
The client is state-independent of all its servers, if and only if, for each one-access-link client-server relationship the client is state-independent of the server, then the client could be served by one or more instances of that specific server.
(Can be illustrated using observation 2.)
Observation 6: In the case where two or more access-links exist between the client and a server (of access length equal to or larger than one) then:
May 1994 C Kyriakides Page 81 Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
the client is state-independent of the server, if and only if, when each possible access path between the client and the server is considered in isolation, the client is determined to be state-independent of the server.
(Can be illustrated by using observation 4 to illustrated each path state-independent in iso lation. If desired to simplify matters observation 3 could be used to deal with access paths merging and observation 5 could be used where access path diverge.)
In the paragraph presented below we illustrate one example indicating how state dependency can be used.
Let Mc represent a module having a constant initial state. In other words, the first call and any subsequent calls to Mc will encounter Mc having the same state. In the case of an Mc that does not call any other module and its processing is "atomic" (i.e., does not accept nor issue any further calls while processing in response to a call), any two calls arriving at the Mc in any order will give rise to the same respective result for each call. Thus we may conclude that in this case the calls could have been directed to separate but identical copies of the Mc module - say Mcl and Mc2. Thus, any number of modules accessing Mc by an access link length of one will be state independent of each other. This reasoning can be expanded so that any two or more modules calling a constant-initial-state "atomic" module Mc could have their calls directed to separate but identical copies of the Mc module.
In order to assist our discussion we make the following definitions:
Stateless Objects: objects with no attributes and no data variables within methods.
State Objects: objects containing attributes or methods with variables.
Variable-State Objects: objects containing changeable attributes and/or changeable vari ables within methods.
Constant-State Objects: objects with constant state. Objects whose attributes and data variables within methods remain constant.
Constant-Initial-State Objects: objects exhibiting a constant state at the beginning of pro cessing every message. (Please note that a Constant-State Object is a special case of a Constant-Initial-State Object).
May 1994 C Kyriakides Page 82 Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
By the Constant-State Objects' definition, each message to a Constant-State Object will encounter the Object at the same state. Likewise, by the Constant-Initial-State Objects' definition, each message to a Constant-Initial-State Object will encounter the Object at the same state. Thus, in the case of Constant-State Objects and Constant-Initial-State Objects it is clear that these Objects satisfythe role of the server in a one-aceess-link state-independent client-server relationship. Using the observations of state-coupling given above, additional state-independence relationships can be discovered.
Keeping in mind that, in general, most Objects in a model are Variable-State Objects and that most Objects communicate with each other it is clear that not many state-independent relation ships are anticipated to be found. In other words, most client-server relationships will be state coupled. Thus it may prove more beneficial to view Objects in terms of tightly-state-coupled Objects (exhibiting greater state-coupling) and loosely-state-coupled Objects (exhibiting lesser state-coupling). Unfortunately, in the current research only pure state-independent and pure state-coupled relationships were found to lead to inferences of further state-coupling relationships. It has been left to future research to determine whether it is possible to formulate state independence relationships based on non-pure (i.e., partial) state-independence. Furthermore, with regards to state-coupling between methods within an Object, since Objects encapsulate closely related data and processing, it is clear that not many pure state-independent methods will exist within an Object. Thus a similar argument that holds for partial state-coupling of Objects also holds for partial state-coupling of methods.
Let us consider the case of a model comprising exclusively of objects that do not cater for internal synchronisation, (e.g., Actors [Agha 1986] to be discussed in section 7.6). In this case, the pro cessing arising from an incoming message is not affected by other messages arriving while that message is being processed. If a constant-initial-state object existed in such a model, then it is clear that the first message and any subsequent messages arriving at such an object will encounter the object in the same state. Hence, the order in which any two messages are processed will not in any way alter the result of either message. In this case, the processing of messages directed at a constant-initial-state object can be distributed amongst one or more instances without altering the result of any message. A more subtle implication of this argument is that it does give rise to a form of concurrent processing that is independent of the order of messages.
May 1994 C Kyriakides Page 83 Parallel Object-Oriented Concepts Objed..Qriented Parallel Paradigms
Hypothetically speaking, if a model comprising exclusively of constant-initial-state objects existed, then it would be obvious that such a model would be totally independent of the order in which messages are processed. Such a model would then be immune to large-scale distributed processing where message delays can alter the order in which messages arrive at their intended destination. Unfortunately, a model restricting objects to be constant-initial-state objects is not anticipated to be able to address a large number of problem domains. Whether this or any similar idea can prove of any value to any specific domain is left up to future research.
Where managers can prove of benefit is in keeping track of (or even possibly identifying) such constant-state/constant-initial-state objects lacking internal synchronisation. The managers can then request the creation of more instances to meet an increased demand of message processing. Furthermore, it is clear that state-independence relationships can be successfully used in an object-to-processor mapping algorithm; for example, if any two "client" objects are state independent with regards to the same "server" object then if desired these two "client" objects could be placed in physical locations situated far apart and one or more copies of the "server" object could be kept at or near those locations.
5.5 Productivity and Workloads in computers
In this section we present an adaptation to the productivity and workload concepts for computers. (Please note that it is beyond the purposes of our research to present an indepth look into pro ductivity and workload balancing; instead, we only attempt to illustrate that the concepts of pro ductivity and workload balancing can be incorporated in multi-processor computing environments.)
In multi-processor environments, balancing ofprocessor work/oads is anticipated to enhance pro ductivity (and usually, throughput). The fundamental idea behind this rests on the following premise: in scenarios with unbalanced processor workloads, theprobability of attempting to access a busyprocessor (especially, one with a heavy workload) is increased.
In object based models, this idea of processor workload balancing can be put into practice by relocating objects from processors with heavyworkloads to processors with lighter workloads (e.g., as done by the MITRE model [Bensley 1989]). In models supporting Object-Oriented parallel processing, it is clear that specialised Objects (such as OOPP's managers or MITRE's agents) capable of monitoring processors and relocating Objects will be able to fulfill this role. As will be revealed in later chapters, when considering object relocation it should be kept in mind that, the majority of Object models support the notion of limited/restricted Object communication (this fact
May 1994 C Kyriakides Page 84 Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
is overlooked by the MITRE model). Furthermore, communication between objects residing on different processors will result in interprocessor communication costs. Hence, any object-to processor mapping algorithm should attempt to minimise interprocessor communication costs by keeping communicating objects close together. Hence, object relocation relies on the object-to-processor mapping algorithm to determine a suitable new position for an object, (we defer further discussion to a later chapter where the object-to-processor mapping willbe discussed in greater detail).
Before continuing, we take this opportunity to make a number of definitions. (Please note that in order to simplify matters, wherever possible these definitions have been normalised so as to express a value between 0 and 1, such that the most optimum case is represented by 1.)
We define Resource Workload W rasou rce in computers to be the percentage of time a resource
is busy working. More formally, Resource Workload is the ratio between the actual usage Uactual and the continuous usage Ucont of a resource. Hence,
U raclual "°'01 I. d l• Wre.ourci = U rcoal t 10/01
0$ 0$ where t Idl. s "°'01 . W r"ourc, s 1
Since in this topic we are more concerned with processor characteristics than with general resource usage, we adapt the above to apply to processors:
We define Processor Workload W prmuor to be the ratio between the actual usage Uactual
and the continuous usage Ucont of a processor (the same equation applies as for resource workload).
Let us now turn our attention to the algorithm that the processor is using. From the above, since
we adopt normalised definitions, the efficiency of an algorithm Eal"oruhm will be such that
0< Eal"or"hm $ 1. Hence, the Effective Processor Workload W proc..,or can be expressed as
( W,rocu,or Eal"or.,hm * W proc,~stJr It follows that the Optimum Processor Workload will be equal to one. (Since the above equations
where normalised, EOPlimum=l and woPlimum=l, thus Optimum Processor Workload = 1.)
As we will now illustrate, the issue of productivity is rather more complex than that of workloads. According to the economic field of study:
May 1994 C Kyriakides Page as Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
Productivity is the relationship between the output of goods and services and the inputs used in producing them, such as land, capital, and labour or all factors combined. [Encyclopaedia Britannica]
The productivity deftnition as presented above needs certain modiftcations for our purposes. We propose the following deftnition:
Processor Productivity P processor in computers is defmed to the ratio between the Effective
Processor Workload It'promsor and the Optimum Processor Workload. Since, Optimum Pro cessor Workload = 1, Processor Productivity is equal to the Effective Processor Workload
It' processo,.. In other words, Processor Productivity P processor is equal to the product of the
efficiency of the algorithm Eo/gorilhlll and the processor workload W processor (where
0< Eo/gori/hlll s 1).
Unfortunately this simplistic view ignores processing overheads. We thus propose that Processor Productivity is
a Pprocessor EO/florI/hill * W prOCQ$$or
Productivity of a processor is thus influenced by two factors:
the efficiency of the algorithm currently being executed on the processor, and
the percentage of time the processor is active.
Generally, the processing requirements of an algorithm serve as an indicator of its efficiency, (algorithms with smaller processing requirements being more efficient).
We must at this stage note that a number of simplifIcations where made in order to present the fundamentals of productivity and workloads. In particular, we have assumed that the percentage of time that a processor is actively processing is indicative of a processor's workload; in processors capable of processing at different speeds, this is only true if the processor is running at its maxi mum allowable speed. Hence, it is more appropriate to view processing time in terms of pro cessing steps (and furthermore, normalise this with the processing steps in the same time interval at maximum allowable processing speeds). With regards to the efficiency of an algorithm, unfortunately in reality matters are somewhat more complicated; the processing requirements of an algorithm is usually stated to be of a particular order expressed in terms of the input size (e.g,
May 1994 C Kyriakides Page 86 Parallel Object-Oriented Concepts Objed-Oriented Parallel Paradigms
O(n), O(n log n), O(en), etc. where n is the input size). Furthermore, this processing requirement is usually expressed in terms of separate values/expressions for best- and worst-cases, Thus,
although we are not able for all cases to express the efficiency of an algorithm Eo/gorlll"" in terms of a constant value, the values for the best- and worst-cases can be determined once the input size is known.
In the event of more than one algorithm being executed on a single processor in a pseudo-parallel fashion, things get somewhat more complicated. In order to determine the overall algorithm effi ciency (for any particular time duration) we need to know the efficiencyof each algorithm, as well
as, the length of time each algorithm was executing. The Overall Algorithm Efficiency Eouorol/ is then calculated as follows:
For each time interval, if we take the "efficiency" of the algorithm Eo/gOrtlll....' and multiply this
by the length of the time interval t oell•• , then we will have a value indicative of the overall efficiency of the algorithm. However, since we stated that our definitions need to be normal ised we need to take this value and divide it by the total time (represented by the sum of all the time intervals). This results in the following equation for the Overall Algorithm Efficiency:
• L [tadil.t *Ealgor~u\fl i-I
where n is the total number of processing intervals such that n:::1
Thus, in the case were multiple processes are being run on a single processor in a pseudo-parallel fashion, the Processor Productivity definition takes the following form:
Processor Productivity p for multiple processes being run in a pseudo-parallel fashion (on a single processor) is "approximated" to be
Eoverall *ill processor p=------tEnd - tStart
May 1994 C Kyriakides Page 87 Parallel Object-Oriented Concepts Objed'()riented Parallel Paradigms
R L [t aeU•• / Eall/.ratun j 1 1=1
p = ------tEnd - t Start
The reason we have used the term "approximated" in the above definition is that, for the sake of simplicity, we have ignored the effects of processor overheads attributed to the pseudo-parallel mode of operation. These overheads may be ignored in the case where the periods dedicated to processing of the algorithms are far greater in magnitude than those dedicated to the processor overheads (i.e, when switching from one process to another is not too frequent). However, in the case where process switching is relatively frequent (i.e., when processing period lengths are rela tively short) processor overheads can playa dominant role in determining the productivity of a processor. Since Productivity should encompass all relevant inputs required to produce a desired output, processor overheads should be taken into account.
Furthermore, initially we have considered the case where one algorithm exists on a single pro cessor, and later on we considered the case where two or more algorithms exist on a single processor; clearly, in reality not only one or more algorithms could be processed on a single processor, but also, in the case of a single parallelisable algorithm two or more processors could be used for one algorithm. Nonetheless, if desired, the above definitions can be extended for usage on groups of processors.
In closing this section, with the above definitions it should be possible to express a number of the resource efficiency factors that may be encountered during implementation of resource manage ment. This line of thought was unfortunately not taken further in this research but was left over to future research efforts for experimentation regarding its applicability. The benefits that ought to be encountered when viewing processes/algorithms in this manner is that we may be able to identify algorithms that are "analytically" efficient algorithms but when implemented turn out to be inefficient owing to, say, processor overheads. The aim here is to take some of the burden away from the system designer.
5.5.1 Summary: Productivity and Workloads
In summarising, the concepts of productivity and workload balancing reveal an adaptability to the multi-processor Object-Oriented computing environment. Workload balancing entails dis tributing/relocating Objects so as to obtain more equitable processor workloads. The issue of
May 1994 C Kyriakides Page 88 Parallel Object-Oriented Concepts Objed-Oriented ParaDe) Paradigms
productivity is complicated by the fact that algorithm efficiencies cannot be expressed in terms of a constant value (since they depend upon input size and are expressed in terms of separate orders for best- and worst-cases), and furthermore, the number of algorithms to processors is rarely one to one (one or more algorithms may exist on a single processor, or even, an algorithm may be distributed over a number of processors).
It is clear that productivity and workload balancing on multi-processor Object based systems can be influenced by a number of factors; these include: interprocessor communication costs (e.g.• between Objects on different processors), processor overheads, algorithm efficiency, time wasted for synchronisation purposes, chosen grouping of objects per processor, etc.
May 1994 C Kyriakides Page 89 Industry and De Facto Standards Objed-Oriented Parallel Paradigms
6 Industry and De Facto Standards
In this chapter we briefly mention industry and de facto standards in general, as well as, their effect on systems development. The first section briefly mentions several prominent standards (such as OSI, IEEE, SNA, etc.), For OOPP's purposes, the second section is of primary importance; this section deals with the Object Management Architecture (OMA) - a standard proposed by the Object Man agement Group).
6.1 Industry Standards
In this section we briefly mention a number of prominent industry and de facto standards. We do not attempt to give a detailed description of these standards. Instead, we highlight the influence that such standards play on systems development and the formulation of methodologies. In par ticular, the relevance of industry standards arises from their crucial role in developing commer cially viable applications. For this reason, it is highly advisable for system developers to develop applications in compliance with at least one widely used standard.
The philosophy behind standards rests on the premise that it is significantly easier to establish communication between two applications conforming to the same standard.
Readers wishing to investigate these standards in greater detail are advised to refer to more detailed works on these subjects.
6.1.10SI
The first industry standard we present is the Open Systems Interconnection (OSI) standard [Henshall 1988; Day 1983] developed by the International Standards Organisation (ISO). In brief terms, the primary purpose of the OSI standards is to provide a satisfactory level of uniformity among network vendors and as a result thereof give rise to greater interconnectivity of multi-vendor networks.
The OSI model comprises of seven layers; each layer represents a standardisation on a specific level. The seven layers are arranged one-on-top-of-the-other; with each layer designed to provide a service for the layer immediately above it. Below we present the layers starting from the lowest and proceeding to the topmost layer.
May 1994 C Kyriakides Page 90 Industry and De Facto Standards Objed-Oriented Parallel Paradigms
Physical Layer The hardware standards for network compatibility are addressed by the physical layer standards. Included in the physical layer standards are specifications such as voltages used, timing of the data transmission, and requirements.
Data link Layer The packaging of data into data frames for the purpose of transmission is addressed by the data link layer.
Network Layer Packet switching is addressed by the network layer. Virtual circuits are established between computers or terminals so as to facilitate data communication.
Transport Layer Error recognition and recovery, as well as, multiplexing of messages and regulation of information flow is handled by the transport layer.
Session Layer Network management is addressed by the session layer. Password recognition, login, logoff procedures, and network monitoring and reporting are all handled by the session layer.
Presentation Layer Network security, file transfers, and format functions are addressed by the presentation layer.
Application Layer In the application layer we usually encounter network programs including electronic mail, database managers, me server software, and printer-server software. The majority of activities performed at this layer arc user specified. Furthermore, different industries (such as banking) have developed their own standards for the application level.
6.1.2 Other Standards
In addition to the OSI standard the following standards may be cited as examples of standards that has influenced industry:
May 1994 C Kyriakides Page 91 Industry and De Facto Standards Object-Oriented Parallel Paradigms
The Consultative Committee for International Telephony and Telegraphy (CCrn) has developed a set of standards. One of these standards, CCI1T x.25 [Deasington 1988; Dhas 1986], establishes rules for data packets that are to be sent to public switched net works. The three layers of the X.25 standard, namely the physical, frame and packet layers, correspond to the physical, data link and network layers of the OSI model. CClTT's x.21 recommendation is adopted by the physical layer to define RS-232 stan dard for asynchronous data transmission, as well as, full-duplex point-to-point synchro nous transmission between the data termination equipment (DTE) and a public switched network. Data is exchanged between a DTE and the network at the frame layer (corresponding to OSI's data link layer). One of the requirements for public switched networks is for data to be in packet form; this is handled at the packet layer (which corresponds to OSI's network layer).
The Institute for Electrical and Electronic Engineers (IEEE) has established a number of widely accepted standards for Local Area Network (LAN) topologies. These include the IEEE 802.3 [IEEE 1985a] for bus LAN (Ethernet), the IEEE 802.4 for token bus LAN [IEEE 1985b], and the IEEE 802.5 [IEEE 1985c] for token ringLAN and the IEEE 802.6 for Metropolitan Area Networks (MAN).
mM's Systems Network Architecture (SNA) deals with distributed data processing net works used by IBM's mini and mainframe computers. The SNA layers are in most regards analogous to those of the OSI model.
6.1.3 ANSI C
In contrast to the above mentioned standards, ANSI C [Kernighan 1988; Schildt 1989] is a programming language standard developed by the American National Standards Institute (ANSI). Prior to the development of the ANSI C standard written code was vendor specific and allowed for practically no portability. The ANSI C standard allows code conforming to this standard to be fully portable to all machines supplied with compilers conforming to the ANSI C standard. A C compiler conforming to all the functions stipulated in the ANSI C standard is said to be in compliance to the ANSI C standard.
Although the ANSI C standard covers the most commonly used functions of the C language, functions do exist outside this standard. Nonetheless, functions not stipulated in the standard are allowed to be vendor specific; this allows vendors to cater for functions that they deem
May 1994 C Kyriakides Page 92 Industry and De Facto Standards Object-Oriented ParaDel Paradigms
necessary to enhance their product. Furthermore, standards are usually developed in versions and once a function becomes commonly used and accepted, then it may be included in a new version of the standard.
6.1.4 Benefits of Standards
At this stage we briefly describe the benefits of industry and de facto standards. Any appli cation developed in conformance to a widely used standard should be able to communicate with and/or make use of other applications developed in conformance to that same standard, (this would have been substantially more difficult if the two applications did not conform to the same standard).
As an example, an application developed in compliance to the OSI model (and dealing with a specific layer of the model) will be able to make use of services provided by lower lying layers of the model. If this application was developed within a specific programming language stan dard, say ANSI C, then the application should be portable over all machines for which ANSI C compilers are available.
As can be anticipated similar benefits will arise in Object based developments that adhere to Object technology standards.
6.2 Object Technology Standards
In this section we present Object Technology Standardisations and the benefits that arise as a consequence of adhering to such standardisations. In general, a standardisation states the minimum requirements necessary to conform to thatparticular standard. Furthermore, it should be noted that the general purpose of standardisations entails standardising the most common aspects of a domain.
A fundamental feature ot Object Technology (OT) is that all objects (whether local or remote), communicate and interact with each other by sending messages. The use of messages as an inter-object communication mechanism gives rise to the need for a standardisation ofmessages; this entails standardisation with regards to formatting, sending, receiving and responding to these messages.
May 1994 C Kyrialddes Page 93 Industry and De Facto Standards Objed-Oriented ParaDel Paradigms
Furthermore, in OT, object reusability is to a large degree made possible by object encapsulation. Encapsulation ensures that each object exists and operates independent from all other objects, while object interaction is restricted to the object's operation signatures (the set of messages accepted by an object). It is clear that objects can be treated as reusable and replaceable compo nents, if and only if, standardisation exists not only on the standardisation of object interfaces (represented by general messages and operation signatures) but also on object semantics.
6.2.1 Object Management Group (OMG)
The Object Management Group (OMG) [OMG 1993] attempts to develop specifications for an Object Technology standard so as to maximise the reusability, portability and interoper ability of commercial software. The OMG standard is embodied in the Object Management Architecture (OMA) - this will be discussed in the following subsections. The relevance of OMG's standardisation efforts arises from the fact that it is emerging as a dominant standard in OT.
The OMG is committed to establishing an agreement between vendors on both the terminology of Object-Orientation and on 4GL style and interface standards [Graham 1991].
Some confusion prevails as to what the OMG's purpose is. It must be noted that the OMG's current efforts are concerned primarily with the standardisation of object interfaces [OMG 1993]. To elaborate, the OMG is concerned with standardising Object interfaces and behaviour from the viewpoint of other Objects present in a system; it does not attempt or intend to standardise the intemal structure or behaviour of objects.
Object interfaces are represented by the set of messages an Object supports; while, Object behaviour portrays the semantics of those messages. Furthermore, the OMG endeavours to provide a standard model that accommodates interoperable applications based on distributed interoperating objects across non-homogeneous platforms.
The OMG's philosophy endeavours to adopt an open systems approach to software develop ment. In the past, under the closed systems approach, vendors attempted to lock end-users into the vendor's specific product range. In contrast, an open systems approach allows end-users to select amongst a wide range of interoperable/compatible software applications irrespective of the particular vendors. Furthermore, software developers can also benefit by developing applications conforming to the OMG standard and building into these applications facilities to enable interfacing to other domains of computing. In essence, an end-user is
May 1994 C KyriaIddes Page 94 Industry and De Facto Standards Objed-Oriented Parallel Paradigms
guaranteed that any application developed in conformance to the OMG standard will be able to interact with any other application also conforming to the OMG standard provided such facility for interaction has been built into the particular application. For example, wordpro cessor applications will be able to request and receive information stored in a database application irrespective of vendors; provided that both applications conform to the OMG standard and that the facility for such interaction has been built into the wordprocessor.
As with all standardisations, (such as ANSI C), primarily only the most commonly utilised objects are included in the OMG standard; although the range of objects covered by the standard may grow in time, objects (or even object services) will always exist outside the domain of the standard. Nonetheless, objects conforming to the OMG standard will be accessible to other objects from another application or vendor; what must be pointed out is that the only access ensured by the OMG standard is in terms of messages between objects with interfaces conforming to the standard. To elaborate, objects (or services of objects) not conforming to the standard can still be implemented but will be application/vendor specific.
Below we present a brief overview of the OMG. Readers are advised to read more detailed works on the OMG topic as it is anticipated to play an important role in influencing the direction of future Object Technologies.
(For further details readers are referred to the Object Management Architecture Guide [OMG 1993], which is the primary contributor to this section; this reference is implicit for all subsections presented in this section).
6.2.1.1 Technical Objectives of the OMG
The information presented here is intended to be indicative of the OMG's technical objectives; we have purposefully presented the technical objectives of the OMG more or less in the format presented in the OMA guide so as to enable us to indicate any analogies existing between OOPP and the OMA.
The OMG endeavours to adopt interface and protocol specifications that define an object management architecture capable of supporting interoperable applications based on dis tributed interoperating objects.
May 1994 C Kyriakides Page 9S Industry and De Facto Standards Objen.oriented ParaDeI Paradigms
Technical Objectives of the OMG
1. Conformance to the OMG Object Model An Object Model as defined and supported by a proposed technology should conform to the OMG Object Model. In particular, support should be provided for the following: A. Inheritance of interface. B. Inheritance of implementation (secondary). C. A program or process should be able to define and execute one or more methods. D. An object's methods may be defined and executed in one or more programs or processes.
2. Object distribution transparency. In client-server interactions, the client object utilises a server object through its interface. Nonetheless, the client object should be independent of: A. the physical location(s) of the server's methods and associated state. B. the access path between the client and the server. c. any relocation of the server's data or methods to new locations. D. the representation format of the server's associated data and methods. E. the communication mechanism facilitating communication with the process that is performing a request. F. the invocation mechanism depicting how the server's methods are executed. G. the storage mechanisms employed in storing and managing the server's data and methods. H. the machine type (i,e. the computer hardware architecture) on which the ser ver's methods are stored. I. the operating system (software) environment supporting the method execution of the server. J. the programming language(s) in which the methods of the server are implem ented. K the particular security mechanism employed to control access to the server.
May 1994 C KYriBlddes Page 96 Industry and De Facto Standards Objed'()riented Parallel Paradigms
3. Performance for local and remote server object requests The evaluation criteria include: A. Scalability the effect on request processing times as the number of objects accessible to a client increases and the number of requests handled increases. B. Method invocation time the overhead associated with the first and subsequent requests to local and remote objects and the corresponding responses. C. Storage overhead associated with maintaining information about objects. D. Resource consumption as depicted by the runtime storage, memory, and processing requirements. E. Parallelism in terms of the degree of support for concurrent execution F. Throughput the capacity to handle significant numbers of simultaneous requests and responses.
4. Extensible and dynamic nature. Changes to existing implementations of objects should be facilitated without affecting any other objects (irrespective of whether they are clients of the changed objects or not). Other objects should not require to be recompiled, relinked, or reloaded, or even necessitate the shutdown of the environment, in at least the following cases: A. Adding new implementations should not affect existing objects. B. Replacing implementations where the interface is not changed. C. Replacing implementations where the interface is changed (secondary). This may be handled either by providing a versioning mechanism whereby existing objects can continue to use the older implementations, or by means of a dynamic upgrade facility allow existing objects to correctly use the new inter face. D. Changing the location of any part of the implementation of an object should not affect other objects (secondary).
May 1994 C Kyriakides Page 97 Industry and De Facto Standards Objen-Oriented Parallel Paradigms
5. Provide a naming system architecture that supports multiple naming contexts. A. Name spaces in which objects can be named unambiguously. Furthermore, an object can have more than one name. Also, the names associated with an object should be viewed as attributes of the object that may change over time. As a consequence thereof, the values (e.g. objects) to which the names are mapped can also change. B. Object handles should provide unique identification of objects. C. Efficient references to objects.
6. Queries based on object names, attributes, and relationships with other objects. Support should be provided for queries on: A. Implementation information including class and method. B. Type information. C. Interface information for any given object. D. Naming system data.
7. Support discretionary access control of objects. In other words, the object's access control can be set up by its owner and this cannot normally be circumvented. Furthermore, an object's data should only be accessible by the methods of its class. A. Objects controlled by a server should have access control features. B. Access control (analogous to access control based on methods of a class) should also be provided for metaobject data including implementation and interface information, and naming system data. C. Mandatory access control, such as that specified by national defense adminis trations, may also be supported (secondary). If complete reliability is to be guaranteed, this may require a client-server authentication scheme.
May 1994 C Kyriakides Page 98 Industry and De Facto Standards Object-Orientrd ParaDel Paradigms
8. Provide concurrency control Cor objects. As a minimum, concurrency control should support: A. Implicit concurrency control The explicit actions ensuring consistent access to server objects should be handled by the server objects themselves, and should not be part of the client object's responsibility. B. A parallelism policy whereby the unavailability of a server object (due to its use by other client objects) is minimised. Viable policies could queue requests, support parallel threads of execution, or support locking of only affected sub-objects or sub-components. C. The concurrency control mechanism should be able to distinguish between different types of use (especially, in cases where this could prove advanta- geous); for example, by distinguishing between read and write accesses, read requests could be processed simultaneously. D. It should be possible to recover from abnormal conditions. For example, when a client undergoes an unexpected failure, the server should not be left in a state in which it cannot process further requests.
9. Provide transactions for the purpose of committing the result oC an operation or sequence of operations on distributed objects atomically. This includes support for: A. Atomic sequences of operations that take place over a short period of time for which consistency is required (i.e., short transactions). B. Atomic sequences of operations that may together last over a significant period of time but consisting of parts that can be separately committed in stages (i.e, long transactions) (secondary).
10. Provide robust operation and a high level of portability. A. Notification to client objects of abnormal terminations (e.g., failure of request delivery or method invocation). B. Recovery back to a consistent state. This may require application cooperation or be automatic (secondary).
May 1994 C Kyriakidts Page 99 Industry and De Facto Standards Objed"()riented Parallel Paradigms
11. Provide support for the versioning of objects. A. Versioning support should allow the installation of a new version of a class without affecting existing instances. Furthermore, when old instances are run, it should ensure that they use the old version of their class.
U. Provide support for the notification of events to interested objects. A notification mechanism should be provided such that the object that triggers an event need not know the set of objects that are interested in receiving notification of the occurrence of that event. Support should be included for an object to: A. Register interest in an event. B. Define and trigger events. C. Receive notification of events in the same way as normal requests are received.
13. Provide support for inter-object semantic relationships by bolding object references within other objects.
14. Provide an application programming interface for all object management functions and capabilities with, as a minimum, a C binding.
15. Require minimal administration of the environment and facilitate manage ment of the object base. In particular: A. Preferably the environment should be self-administrating; however, where this is not possible, the environment should support distributed (non-centralised) administration. B. The backup of all or part of the object base should be possible in an incre mental fashion causing only brief interruptions in the availability of objects. C. It should be possible for objects restored from a backup to be referenced by non-restored objects containing references to the objects that were restored (secondary).
May 1994 C Kyriakides Page 100 Industry and De Facto Standards Objed'()riented Parallel Paradigms
16. Support application internationalisation. Application customisation support should be provided with regards to: A. The user interface language; (this includes support for extended Latin and non-Latin character sets and languages that are not written from left to right) (secondary). B. Different culturally defined conventions, (e.g., date and time notation, currency symbols, etc.). C. Dynamic switching between different languages and conventions used at the user interface (e.g., for point-of-sale systems in multi-lingual societies or international airport information applications) (secondary).
17. Conformance to pertinent industry standards. A. In areas where broadly accepted standards exist, a proposed technology should conform to these standards (such as, X/Open endorsed standards, POSIX, ANSI C, etc.).
6.2.1.2 The OMG Object Model
In the OMG Object Model, common object semantics are defined so as to provide a standard and implementation-independent way of specifying the extemalty visible character istics of Objects.
Briefly, the OMG attempts to define the behaviour of commonly used objects such that characteristics (e.g, the object's application language, environment, location, etc.) are fully encapsulated from other objects. In essence, any object conforming to the OMG standar dised specifications for that particular kind of object can be substituted with any other object conforming to the same specification. Thus, systems composed of objects from different vendors and running on various disparate platforms will be transparently interfaced together.
Operation signatures serve to describe the extemaliy visible characteristics of objects. Operation signatures model the external view of both object behaviour and object state (information required to alter the outcome of a subsequent operation). Furthermore, operations encapsulate implementation details, (such as an object's data structures and methods), which should never be directly exposed in the external interface.
May 1994 C Kyriakides Page 101 JndustIy and De Facto Standards Object-Oriented Parallel Paradigms
Objects are grouped into types. While, individual objects are instances of their respective types whose applicable operations are determined by their type. Types participate in sub type/supertype relationships which influence the set of operations that are applicable to their instances.
Object types also have implementations. Such implementations are represented by a set of data structures and a set of methods or procedures. The set of data structures represents their stored representation; while, the set of methods or procedures provides the code to implement each of the operations whose signature is defined by the type.
The OMG Object Model states that implementations of Object Types exist and should be supported. Furthermore, it is stated that although multiple implementations for a given type are allowed, it is not a mandatory requirement for all systems.
A mechanism called profiles allows technology domains to group pertinent objects together. Profiles are groups of components that combine to serve as a useful set of exten sions for particular domains. For example, a subset of components could be combined to form an Object Database profile.
For a description of components accepted by the OMG as standard please refer to the OMG OM Components Guide.
6.2.1.3 Object Management Architecture
The Object Management Architecture (OMA) [OMG 1993] embodies the goals and pur pose of the OMG.
The OMA comprises of the following primary components [OMG 1993]:
The Object Request Broker (ORB) provides the mechanisms by which objects make and receive requests and responses.
Object Services (OS) is a collection of services with object interfaces that provide basic functions for realising and maintaining objects.
Common Facilities (CF) is a collection of classes and objects that provide general purpose capabilities useful in many applications.
Application Objects (AO) are specific to particular end-user applications.
May 1994 C Kyriakides Page 102 Industry and De Facto Standards Objed'()riented Parallel Paradigms
We will now proceed to briefly address each primary component individually. For the sake of continuity, these brief introductions have been repeated in the relevant sections.
6.2.1.4 ORB (Object Request Broker)
The Object Request Broker (ORB) provides mechanisms by which objects transparently make and receive requests. Thereby, the Object Request Broker (ORB) facilitates inter operability of distributed object technology across disparate systems and also provides a seamless interconnection of multiple object systems.
In other words, an object running on a network workstation may access the services of another object residing somewhere else in the system without requiring to have prior knowledge of the actual location of the service; instead, what is required is the prior knowledge that such a service exists and its parameter interface. The information regarding the service's existence is stored in either the Common Facilities (CF) or the Application Objects (AO); these will be discussed in the following subsections.
Hence, the ORB primarily deals with the aspect ofobjects making and receivingrequests. An object requests an operation along with a number of parameter values (any of which may identify specific objects). The ORB identifies and invokes an appropriate method that performs the operation using the specified parameters. After the operation terminates, the ORB conveys the result to the requester.
Note however, that the ORB may not necessarily contain all of the information needed to carry out its functions (e.g., locating an appropriate method), and it may in tum generate requests of its own to Object Services.
The ORB is expected to address (either fully or at least partially), all of the following areas:
Name Services should be able to map object names in the naming domain of the requester into equivalent names in the domain of the method to be executed, and vice versa. Note that the OMG OM does not require object names to be unique or universal. Furthermore, Object names in the request are used by object loca tion services to locate the method required to perform the requested operation.
May 1994 C KyriaJddes Page 103 Industry and De Facto Standards Object.()rlented Parallel Paradigms
Request Dispatch determines which method to invoke. The OMG OM does not require a request to be delivered to any particular object.
Parameter Encoding conveys the local representation ofparameters values in the requester's environment to equivalent representations in the recipient's environment. To accomplish this, parameter encodings may employ standards or de facto standards.
Delivery of requests to the proper location as characterised by a particular node, address, space, thread, or entry point. These facilities may use standard transport protocols.
Synchronisation to deal with handling the parallelism of object making and pro cessing a request and the rendezvousing of the requester with the response to the request. Possible synchronisation models include: asynchronous (request with no response), synchronous (request and wait for reply), and deferred synchronous (proceed after sending request and claim reply later).
Activation deals with the housekeepingprocessingnecessarybefore a method can be invoked. Activation and deactivation of persistent objects is needed to obtain the object state for use when the object is accessed, and save the state when it no longer needs to be accessed. For objects that hold persistent information in non-object storage facilities (e.g., files and databases), explicit requests can be made to objects to activate and deactivate themselves.
Exception Handling
Security Mechanisms
6.2.1.5 CORBA (Common Object Request Broker Architecture)
The Common Object Request Broker Architecture (CORBA) [OMG 1992] is an accepted standard interface for the ORB component of the OMA. Currently, the most prominent and significant feature of CORBA is its Interface Definition Language (IDL).
The Interface Definition Language (IOL) provides a means by which applications can specify the interfaces that they will provide to other applications via the ORB layer. This
May 1994 C Kyriakides Page 104 Industry and De Facto Standards Object-Oriented ParaDel Paradigms
interface specification information enables applications to make use of the local or remote services available. Furthermore, access can be established in either a static (compile-time) or dynamic fashion.
6.2.1.6 Object Services
Object Services is a collection of services with objectinterjaces that provide mandatory basic functions for realising and maintaining objects. In essence, Object Services define a set of essential operations that all classes should implement or inherit. Objects do not have to utilise the implementation of basic operations as provided by Object Services. Further more, Objects do not have to provide all basic operations.
Although, the operations provided by Object Services are made available through the ORB, they may also be made available through other interfaces (e.g., interfaces that comply with non-OMG standards).
The operations provided by Object Services can serve as building blocks for extended or augmented functionality provided by Common Facilities.
Object Services may provide the following operations:
Class Management
Instance Management
Storage
Integrity
Security
Query
Versions
Class Management services facilitate creation, modification, deletion, copying, distribution, description and control the definitions of classes, and the relationships between class definitions. Instance Management services facilitate creation, modification, deletion, copy ing, moving, invoking and controlling objects and the relationships between objects [OMG 1993]. Although the OMG documentation states what these management services entail, at
May 1994 C Kyrialddes Page lOS Industry and De Facto Standards Objed-Oriented Paral1el Paradigms
the time of writing this dissertation, no detailed information was available on the exact nature of these management services so as to enable a thorough comparison with OOPP's manager concept.
Object Services subcomponents could include: object-oriented database management sys tems, transaction managers, query facilities, directory services and file services.
6.2.1.7 Common Facilities
Common Facilities is a collection of classes and objects that provide optional generalpur pose capabilities useful in many applications (e.g., help facility).
For application developers, Common Facilities reduce the effort of building OMA compliant applications; while, for end-users, it provides (easier to use) uniform semantics that are shared across applications.
A service becomes a Common Facility when it communicates using the ORB, implements a facility that OMG chooses to adopt; and has an OMA-compliant object interface.
Candidates for Common Facilities include: cataloging and browsing of classes, link man agement, electronic mail facility, help facility, error reporting, printing and spooling, reus able user interfaces (e.g. text editors), interfaces to external systems, object queering facilities, etc.
6.2.1.8 Application Objects
Application Objects are analogous to the traditional notion of an application and because of this they are specific to particular end-user applications. Application Objects are gen erally developed by Value-Added Resellers (VARs) and Independent Software Vendors (ISVs). By developing these applications inside the OMA, it is possible to make use of other objects or applications within the OMA framework. Furthermore, by embedding, non-object-oriented applications can also be integrated within this framework.
CF and AO classifications are at the same OMA semantic level (namely, from a devel opment perspective both are analogous to applications). However, CF classes represent very common functionality (accepted as standard requirements by the OMG), while AO
May 1994 C Kyriakides Page 106 Industry and De Facto Standards Object-Oriented ParaDel Paradigms
classes are more specialised and represent interfaces that are specific to an application domain. Specific applications may be developed along existing standards such as ISO and ANSI.
Program developments within the Application Object classification include: word process ing, spreadsheets, electronic mail, CAD, CASE tools, network management applications, information access and query, knowledge-based systems, etc.
6.2.2 Committee for Advanced DBMS Function (CADF)
In analogy to Codd's 12 rules for relational systems, the Committee for Advanced DBMS Function (CADF) published an advanced database manifesto [Stonebraker 1990] stating a number of principles that advanced DBMSs should comply to:
OODBs should possess at least all the facilities of a conventional DBMS. These include:
high volume data management,
concurrent multi-user access,
high-level access languages,
simultaneous access to distributed data,
Support for efficient transaction processing and full recovery, and security features.
Support for object identity.
Support for at least one form of inheritance.
Distributed access and update should be transparent.
Complex objects must be supported either via encapsulation or abstract data types and classes.
The provision of computationally rich languages compared to SQL.
Support for dynamic binding.
User-defined functions.
Type checking and inference capabilities.
May 1994 C Kyrialddes Page 107 Industry and De Facto Standards Objed-Oriented Parallel Paradigms
Effective version and configuration control
There is currently a proliferation of Object SOls. Unfortunately different ideas exist about what exactly costitutes an Object SOL. The CADF is concerned with formulating a standard for Object SOL.
6.3 Conclusion: Industry and Technology Standards
To summarise, systems development adhering to well-accepted industry standards can give rise to commercially viable applications. This is ascribed to the fact that, any application developed in conformance to a widely used standard should be able to communicate with and/or make use of other applications developed in conformance to that same standard; this would have been sub stantially more difficult if the two applications did not conform to the same standard. Widely accepted standards include OSI, CCITT, IEEE, ANSI, CADF and OMG.
The most prominent standard in our research is the OMG standard [OMG 1993] which amongst other issues, presents a standardisation of Object interfaces and semantics. Any object con forming to the OMG standardised specifications for that particular kind of object can be substi tuted with any other object conforming to the same specification. The primary developments of the OMG effort include: the Object Management Architecture (OMA), the Object Request Broker (ORB), the Common Object Request Broker Architecture (CORBA), Object Services, Common Facilities and Application Objects. (All were briefly discussed earlier on in this section; however, readers requiring further information are strongly advised to refer to the actual OMG publications).
The OMG proposes a number of technical objectives (presented in section 6.2.1.1). As will become self-evident, a number of OOPP's objectives overlap with those proposed by the OMG. (It must be kept in mind, however, that substantial differences exist between the OMG's objectives and OOPP's - the OMG is aimed at presenting a standard, while OOPP presents a paradigm). For example, to elaborate on some of the similarities, the OMG aims to provide a standard model that accommodates interoperable applications based on distributed interoperating objects across non-homogeneous platforms; Object distribution transparency is also supported. Analogously, OOpp endeavours to provide an Object model supporting distributed concurrent processing across heterogeneous platforms; OOPP also supports Object distribution transparency.
May 1994 C Kyriakides Page 108 Industry and De Facto Standards Objed.Qriented Parallel Paradigms
What should also be pointed out is that within the context of the OMG's purpose, the name Object Management Group is somewhat of a misnomer; the title Object Interface Standardisation Group, or even Distributed Application Group would have been more appropriate.
May 1994 C Kyriakides Page 109 Industty and De Facto Standards Objed'()riented Parallel Paradigms
7 Existing Models
Often our thoughts and decisions are influenced by our mentors. This occurs in terms of what we already know, and also by how we have been taught to quench our thirst for knowledge. This chapter represents a brief although somewhat lengthy encounter of Object-Oriented languages, programming environments and tools that existed at the conceptual stages of OOPP. In essence these represent the mentors of OOPP in terms of pre-existing knowledge.
Although only a relatively small number of influences are looked at in this chapter, namely the primary ones, it is recognised that many other influences that are not specifically discussed have, to a lesser degree, influenced the establishment of OOPP's foundations.
What is of utmost importance to note in this chapter is the characteristics of a particular language or environment and the benefits or problems encountered as a result of these particular charac teristics.
Furthermore, in this chapter we will view languages, programming tools and environments in terms of families; to elaborate on this, whenever possible the sections dealing with particular environments and tools have been grouped under the language section on which their development was based. Thus we will encounter environment families described as C-based, liSP-based, Simula-based, etc. which in turn mayor may not have sub-familes e.g. Smalltalk-based. As will be seen in some cases, one environment may belong to more than one family.
This chapter presents a substantially condensed view on a number of existing models. Readers wishing to obtain further information on any of these models are strongly advised to refer to more detailed works {a number of which have been listed in the bibliograhy.
May 1994 C Kyriakides Page 110 Existing Models Object-Oriented Parallel Paradigms
7 Existing Models
This chapter briefly presents a number of existing models, languages and papers that had influenced the OOPP research. With the continual advances made in the field of parallel object technology it is a daunting task to thoroughly evaluate or even briefly discuss every existing model and theory. Instead, in this chapter we will briefly present a small select group of models relevant to our research effort.
Furthermore, although we focus on presenting the models' characteristics relevant to our research, it is also beneficial to present a clearer picture of the specific influences that a selected environment may have on a particular model; thus a limited quantity of background information is also briefly pres ented.
Although this chapter is relatively bulky, it does not cover every existing model that could have proved relevant to such a research; it does however cover a significant number of models that have contrib uted to the formulation of the oOPP model. Wherever possible, these models have been presented below in terms of "families" based on their heritage. Nonetheless, before proceeding to present a number of such existing models, we take this opportunity to present a guideline of the models along with their issues that directly contributed to the oopp model. (Please note that the table presented below is only indicative of the relevant issues that should be picked up by the reader on each topic). These issues will be readdressed in greater detail in the sections which follow.
May 1994 C Kyriakides Page 111 Existing Models Object-Oriented Parallel Paradigms
Simula: Able to simulate concurrency. Objects can be used as independent active processes or passive data objects. Beta: Single inheritance. Incorporates real concurrency. Uses patterns as object descriptors (similar to templates). Non-homogeneous model (comprising of objects and patterns).
Smalltalk: Homogeneous model - everything is an object, even classes are objects (called metaclasses). Encourages deep and narrow class structures. Objects interact exclusively by message passing. A method always returns a result to the sender of the message. Supports private and shared variables. Garbage collection. Smalltalk-80: Syntactic consistency to Smalltalk. Limited support for synchronisation on uniprocessor architectures. Concurrent Smalltalk: An extension of Smalltalk-80 that can support concurrent processing. Asynchronous message passing. Uses per-instance lock variables (to control access conflicts). Presents the notion of distributed objects. SmalltalkjV: Syntactic consistency to Smalltalk. Contains PROLOGIV
May 1994 C Kyriakides Page 112 Existing Models Object-Oriented ParaDel Paradigms
c: NonObject-Oriented. Functions always return a value. Not strongly-typed. Supports pointers. Efficient and highly portable. Objective-C: Syntactic extension to C available as a pre-compiler. Sparse type system for objects - only one object type "id". A method always returns a value. Single class inheritance. C++: Syntactic consistency with C. Does not enforce OOP. Encourages broad and shallow class structures. Static and dynamic binding. Operator overloading. Multiple inheritance. Objects comprise of public and private parts. Encapsulation may be violated • a function that is not a member of a class but has been declared to be a friend of the class can gain access to the private part of the class. Constructors and destructors are methods activated automatically when an object is created or destroyed respectively. PROCOL: Objects are internally-sequential (although objects may be externally concurrent). Supports an ownership hierarchy based on object creation. One-one, one-many and many-many message passing is supported. Acceptability of incoming object communication is determined in accordance to a per-object protocol based on the receiving object's state (and may also discriminate with regards to the sender of the message).
May 1994 C Kyriakides Page 113 Existing Models Objed-Oriented Parallel Panuligms
Lisp: Uniform typeless style and dynamic binding give rise to a highly dynamic environment albeit at the cost of additional runtime checking requirements. Demons (event-driven processes). CWS: Homogeneous model (comprises of objects and meta-objects). Objects comprise of slots which may contain attributes and facets (methods). Pointers to entire objects. Generic functions. Multiple inheritance. Type-inheritance, slot-inheritance, initialisation-inheritance and method-inheritance. Uses a class precedence list to resolve inheritance conflicts (with the exception of method combination which is used to resolve method inheritance conflicts). CommonObjects: In order to avoid compromising encapsulation, method inheritance is allowed and attribute inheritance is disallowed. The MITRE model: Supports the concept of object management. In some respects superficial similarities exist to the OOPP model; however, in-depth dif ferences are substantial.
May 1994 C Kyriakides Page 114 Existing Models Object-Oriented Parallel Paradigms
Prolog: Logic programming endeavours to provide a completely unified system whereby all inferences of known facts relevant to a specified goal can be deduced automatically. In contrast, Object Orientation attempts to encapsulate everything within distinct objects. PrologJV: An implementation of PROLOG within Smalltalk/V. Each PROLOGjV implementation exists as an instance of the PROLOG class within the SmalltalkjV environment. Furthermore, PROLOG/V instances can be accessed from the Smalltalk/V environment. Concurrent Prolog: Syntactic consistency to PROLOG. Uses OR-parallelism and AND-parallelism. Introduces commit operator and read-only variables. Uses goal reduction synchronisation. Immutable streams. Does not support pointers to objects. Vulcan: Syntactic extension to Concurrent Prolog. Facilitates broadcasting, multiple inheritance and delegation. Uses become statement in order to change an object's state. Supports inheritance by a description copying mechanism or inheritance by delegation to parts; No multiple inheritance. Spool: Multiple inheritance. Simple English-like syntax.
May 1994 C Kyriakides Page 115 Existing Models Objed.oriented Parallel Paradigms
Actor: Delegation (likened to a form of "classless inheritance") - eases distributed processing and also avoids redundancy at the cost of additional message passing. System comprises of active objects called actors. Homogeneous (everything is an actor). Each actor has its own script containing its behaviour and acquaintances. Actors interact exclusively by message passing. No explicit construct exists for receiving a message - thus the processing of a message is not influenced by any subsequent messages. Buffered communication based on mail system with one mail queue per actor. Behaviour, script and acquaintances. Immutable (also called unserialised) actors - actors whose behaviour does not change. Dynamic connection topology. Customers and continuations. Guardians enable actors waiting to reply to a message to save the processing environment required for the answer to be made and continue processing another message in the meantime. RACE actors - a RACE actor initiates a race between parallel processes to compute its argu ments and returns a list of the results in the order they were computed. Communication from outside the system can only be received by actors called receptionists. ABCL: Like the actor model makes use of delegation. Unlike the actor model, an object can halt processing and wait for a message. Ordinary- and express mode message passing. Past-, now- and future type message passing. ActI, Act2, and Act3
May 1994 C Kyriakides Page 116 Existing Models Objed'()riented ParaDel Paradigms
OODBs GemStone: Typeless language. Inheritance. Persistent objects. Vbase: Commercially unsuccessful: caused by a proprietary type definition language {TDL) and proprietary C Object Processor (COP). Ontos: Replaced Vbase. uses Object SQL and C+ +. Versant: uses C+ + Iris: Object SQL. versioning. Supports multimedia databases via specialised data managers. ORION: Schema evolution
Other models mentioned include: POOL-T, MACE, Orient84/K, Emerald, Eiffel, Hybrid.
7.1 Simula Based Languages
The Simula [Nygaard 1981] programming language was developed for system description, simu lation and modelling. Simula is a superset of Algol-60 with class and inheritance features added to produce a hybrid language. Simula's class and subclass concepts, as wen as the notion of virtual procedures have become the core constructs of most languages supporting Object-Orientation [Blair 1991].
Simula Objects were characterised by local operations and also bad their own individual sequences of actions. Furthermore, these action sequences enabled Objects to execute their actions as corou tines and could also be used to initialise objects at the time of their creation. Simula was thus able to simulate concurrency by means of coroutines.
May 1994 C Kyriakides Page 117 Existing Models Objed.oriented Parallel Paradigms
All Simula Objects belong to Classes. A Simula Object consists of three parts: an identifier which indicates the class of the Object; a set of attributes (variables and/or procedures); and an action sequence which is executed when the Object is created. The new statement is used to create Objects at run time by producing a reference to the new Object; before terminating, the action sequence of the new Object is run until it either terminates or relinquishes control
Simula Objects can be used either as independent active processes or passive data objects, or both. The Simula Object's action sequence part may be utilised to exhibit the characteristics of an independent active process; while the attribute part may be utilised to exhibit the characteristics of a passive data object.
7.1.1 Bela
Beta [Kristensen 1987) (a successor to Simula) is an Object-Oriented language with single inheritance and incorporates real concurrency. Beta supports procedural programming and has good facilities for functional programming [Blair 1991].
The pattem is a Beta construct (possessing both attributes and action sequences) that is used to instantiate Objects conforming to that particular pattern; in essence, the pattern provides a descriptor that is common to all Objects of that particular pattern. An important point to note is that patterns are not Objects. Thus, the Beta model supports two kinds of entities, namely objects and patterns. Thus, according to our definition of homogeneous models, the Beta model is non-homogeneous.
Furthermore, Beta does not support multiple inheritance and would thus be cumbersome in dealing with problems accommodating multiple inheritance characteristics.
7.1.2 Conclusion: Simula Based Languages
The origins of Object-Oriented programming can be traced back to Simula 67. Despite its age, a number of Simula's contributions to OT (namely, Objects and inheritance based on classes), are still prominent in current OTs.
In the Smalltalk line of development, the ability to execute actions as coroutines has disap peared; however, Beta supports this characteristic. As a consequence, even though Beta was developed considerably later than Smalltalk, the developers of the Beta language envisaged the
May 1994 C Kyriakides Page 118 Existing Models Objed-Orienfed Parallel Paradigms
need of addressing concurrency and reverted their attention to the earlier Simula model. Nonetheless, Beta's inability to support multiple inheritance restricts its domain of application to problems that do not exhibit multiple inheritance characteristics.
7.2 Smalltalk Based Languages
Smalltalk is the first programming language designed to be based exclusively on Objects. Features such as the interactive user environment have existed from the earliest Smalltalk systems to the latest versions. Smalltalk exists commercially in two predominant versions: Smalltalk-80 and Smalltalk/V.
Smalltalk presents a homogeneous environment in which everything is an object; even classes are instances of some class. Hence, Smalltalk utilises metac1asses; that is, any class that has instances that are themselves classes is called a metaclass.
In both versions, a Smalltalk system comprises of a set of Objects. These Objects possess instance variables. Interaction between Objects is only possible by sending messages. In response to receiving a message, an Object executes a method. A method is a routine associated with an Object which can access and change the Object's instance variables. Methods can also send messages to other Objects. A Smalltalk method always returns a result to the sender ofthe original message. Further more, the result that was returned by a method now forms the value of the expression which
caused the message to be sent. The A symbol denotes the expression whose value will be returned as the result of a method.
Two categories of Smalltalk variables exist: private and shared variables. A private variable appears with a lowercase leading character and is only accessible by one object; a shared variable appears with uppercase leading character and is accessible to a number of different objects.
In effect, practically everything in a Smalltalk system is an instance of a particular class of object. Overlooking memory limitations, there is no limit to tbe number of these instances. The implica tions of this apparent limitless number of instances are far reaching, not only to programming but also to the user environment. This implies that as many browsers and text editors may be simultaneously active as desired; a browser is a window that allows access to and scrolling through classes, methods, etc. Since all objects in Smalltalk exist as a hierarchy of classes and subclasses,
May 1994 C Kyriakidts Page 119 Existing Models Objed-Oriented ParaDel Paradigms
a special type of browser, the Class Hierarchy Browser, is used to instantly display the hierarchical organisation of such systems. In effect, the interactive editors and browsers prove to be a very useful and time-saving tool for system development.
Below we will briefly delve into Smalltalk-80, Smalltalk/V and a concurrent extension for Small talk. Readers interested in a more indepth look are referred to more specific works referenced below.
7.2.1 Smalltalk-80
Smalltalk-80 [Goldberg 1983, 1984] is an Object-Oriented language with limited support for synchronisation on uniprocessor architectures. Nonetheless, what is of greater importance to our research is the fact that extensions have been developed to Smalltalk-80 so as to facilitate concurrency (further details will be given under the concurrent Smalltalk section which fol lows).
Snyder [1987] states that Smalltalk-SO does not adhere to the model of complete encapsulation. The issue of complete encapsulation influences concurrent system issues in two ways: firstly, incomplete encapsulation is relatively easy to support on shared memory (tightly coupled) architectures, although, it is somewhat more costly on message passing (loosely coupled) archi tectures; and secondly, incomplete encapsulation leads to concerns of interference.
7.2.2 Smalltalk/V
SmalltalkfV is an ordinary Smalltalk language with at least one interesting feature, namely, it can embrace its own implementation of Prolog, called Prolog/V, (This will be discussed later on under the Prolog-based languages).
Like in all Smalltalk systems, Smalltalk/V processes are initiated only by means of message passing. The syntax of Smalltalk/V is very close to that of Smalltalk-SO and in most cases (except for those using multitasking) classes and program fragments from one system can be entered as is in the other system. Smalltalk/V methods can be categorised as either instance methods or class methods. Smalltalk/V implements garbage collection, and has a disk browser.
May 1994 C Kyriakides Page 120 l::!xisting Models Objed-Oriented ParaUel Paradigms
7.2.3 Concurrent Smalltalk
Various extensions have been made to the Smalltalk language to cater for concurrency. Two such extensions, namely by Yokote [1986, 1987a, 1987b] and Dally [1986], have been addressed by Tomlinson [1989] (for further details please refer to said references).
Dally's Concurrent Smalltalk represents an evolutionary approach to extending concurrency to Smalltalk-80. Three primary extensions were made to the Smalltalk-80 model:
an asynchronous form of message passing;
per-instance lock variables used to control access conflicts amongst method activations; and
the notion of a distributed object was developed as a fundamental system class.
7.2.4 Conclusion: Smalltalk Based Languages
As is the case with other "families", extensions to facilitate concurrency in the Smalltalk family have as far as possible endeavoured to maintain syntax and semantic consistency with earlier language standards. (A secondary aspect to note is that interactive user environments have existed since the earliest Smalltalk versions; this may be ascribed to the fact that interactive user environments can greatly enhance ease of implementation).
Smalltalk adheres to the concept of objects interacting exclusively by means of message pass ing. This is made possible since Smalltalk provides a homogeneous model where everything is an object. In Smalltalk, subclasses are treated as instances of their superclass and hence classes are also objects.
Smalltalk's synchronous mode of message passing proved adequate for single processor envi ronments. However, contutrent extensions to Smalltalk necessitated the need for addressing asynchronous, as well as, synchronous message passing.
As discussed above, Smalltalk supports the existence of shared and private variables. The existence of shared variables leads to models exhibiting incomplete encapsulation. It should be noted that incomplete encapsulation can give rise to concerns of interference. In other words objects sharing a common variable will effect each other without any message exchange taking
C Kyri.akid~ Page 121 Existing Models Objed-Oriented Parallel Paradigms
place. (It is self-evident that shared variables exhibit a strong analogy to the problems encountered under the Data-Driven Approach; shared variables give rise to interdependencies amongst data in one object and methods in other objects that make use of that shared data).
7.3 C Based Languages
C is a relatively low-level genera/-purpose (nonObject-Oriented) programming language dealing with pointers, integers, and characters. Higher-level types based on these primitive types may be defined, as well as, array and structures thereof. Even though C bas a type-checking scheme, it is not a strongly-typed language. C types can be easily converted to another type which has a similar machine representation. C is highly portable and produces efficient code for a wide variety of machines.
C++ and Objective-C are hybrid languages of C. Both enhance vanilla C by incorporating object-oriented programming ideas, albeit using very different approaches. Objective-C [Cox 1986] (made available as a precompiler) extends vanilla C by introducing one additional data type in the form of a C structure within a function library; the functionality of Smalltalk is incorporated through this. C+ + however, changes the compiler and extends the syntax with a new primitive data type for classes.
7.3.1 Objective-C
Objective-C [Cox 1986] is a superset of vanilla C in which a function library provides most of the functionality of Smalltalk's language elements. Objective-C is available as a pre-compiler accepting an Objective-C program as input and producing standard C code as output. Fur thermore, the ability to interchange message expressions and normal C expressions allows a system developer to program in either style and gives the language a hybrid quality.
The two primary introductions to vanilla C entail a new data type, id or object identifier, and a new operation, message passing. The id serves as a handle for referring to an object in a message expression. Message expressions are distinguished from normal expressions by being enclosed in squared brackets.
Objective-C has a rather sparse type system for Objects. All the objects added by Objective-C are of the type id; thus, the only type checking possible entails verifying that the recipient of a message specified in a message expression is of type id. Clearly, systems accommodating a very sparse type system will generally exhibit limited type checking capabilities.
May 1994 C Kyriakides Page 122 Existing Models Objed-Oriented ParaDel Paradigms
Like functions in C and methods in Smalltalk, an Objective-C method always returns a value; this value can be of any type, including type id:
Methods and state variables are encapsulated by Objective-C Objects; these are in turn inherited by Instances of that particular Object. Each Instance encapsulates state values and is distinguished by a unique identifier. Overriding of inherited methods or variables occurs in the case where a variable or method exists with the same name in the Instance or SubClass of a Class. Objective-C supports single class inheritance, but does not support multiple inheritance; however, if required, multiple inheritance can be implemented by the programmer.
In principle, Objective-C Classes are Objects in the sense that they have a run-time repre sentation, and respond to messages in a manner very similar to that of Smalltalk classes. However, unlike Object Instances, this Class representation is created at compile time and cannot be dynamically created.
To assist with further reading on Objective-C, it should be noted that, Objective-C and Smalltalk terminology are considerably different. For example, in Objective-C, storage is managed by 'factory' Objects; these factory' Objects represent classes and are created at compile time. A method 'new' is incorporated in all 'factory' Objects and serves to create instances of its class at run-time.
7:3:2 c++
C (and its ancestor BCPL) and Simula were the primary inspirations of C+ +. C+ + [Strous trup 1986], like C, was designed with portability and efficiency in mind. In designing C++ emphasis wasplaced on the goal of incorporating the large quantity of existing C code; although some incompatibilities exist, C++ endeavours to be a superset of C.
Although c++ has no high-level data types orprimitives it facilitates these extensions by making use oflibraries; new types are thus defined in the language itself. Furthermore, C++ facilitates abstraction, inheritance, static and dynamic typing, self-reference, and dynamic binding. Multiple inheritance [Stroustrup 1987] is also supported (only in versions after 2.0).
C+ + represents a compromise between the Object-Oriented ideal and pragmatism. In C+ + it is possible for a programmer to violate the data protection and typing rules, or access data in an inconsistent way; however, it is much harder to do so unintentionally in C+ + as compared to C.
May 1994 C Kyrialddes Page 123 Existing Models Object-Oriented Parallel Paradigms
Even though C+ + is an Object-Oriented programming language, C+ + does not enforce Object.Oriented programming. It is possible to use C++ to write vanilla C programs. This is unfortunately sometimes unintentionally done by C programmers migrating to C++. C pro grammers are generally expected to find the transition to C++ easier as most of the syntax and standard functions of C are present in C+ +. Even though the transition from C to C+ + is not that difficult (from a syntactic point of view), the transition from functional program ming to Object-Oriented programming is much more difficult One feature that would be welcomed in C+ + compilers, (even if it is to prove useful only for training purposes), is the ability to 'select' a stricter form compile-time checking for Object-Oriented programming where everything in an application has to be an Object.
In contrast to Smalltalk which is organised as a single-rooted tree structure, the type system of C++ is organised as a collection of relatively small trees. While Smalltalk encourages a narrow and deep structure under which everything is a SubClass of 'Object', C+ + tends to encourage broad and shallow Class structures. This observation can serve as a simple guideline in evaluating application suitability.
Unlike Objective-C, C+ + does not extend the C language but rather modifies C by changing the C compiler and extending the syntax with a new primitive data type class.
As in conventional languages, static binding of global and local variables is established (by default) at compile time; local variables being scoped within a program block. Alternatively, an Object can be created in the free store and destroyed under program control. These tech niques require the types of the arguments to be known at compile time. Nonetheless, dynamic binding can be achieved by means of vittual functions defined in a base class (in turn, these virtual functions can be redefmed in derived classes). Under dynamic binding, the argument types of virtual functions are determined at the time a function is called.
C+ + Classes comprise of public and/or private parts. Attributes and Methods declared in the private part of a Class are available only to the Object's own methods; while, those declared in the public part are available to any other Object or function. In essence, the public part of an Object represents its interface to other Objects in the system.
Message passing results when a function call is made from one Object to another. Data is stored in instance variables calledprivate member variables. Nonetheless, data can be stored in class variables (at the class level) and remain fixed for all instances of a Class.
May 1994 C Kyriakides Page 124 Existing Models Objed'()riented ParaDeI Paradigms
In C, a function exists on its own; in contrast to this a C++ method does not exist indepen dently of an Object and thus methods are usually referred to as 'member functions'. (Please note that in the latter statement we are referring to the Object-Oriented aspect of C+ + and not reflecting on the ability of C++ compilers to interpret nonObject-Oriented vanilla C programs). Members having the same name as the class in which they are declared are called constructors and are utilised to initialise instances. Likewise, destructors have the same name as the class in which they are declared preceded by a tilde (-),' destructors do not have any arguments and are activated automatically whenever an object is removed from memory by a delete operator.
Declaring a function that is not a member of a Class to be a friend of that Class will give that function the ability to access the private parts of that Class. The ability to declare a function to be a 'friend' of one or more Classes can be used to simplify the description of an operation on two or more types. (For example, multiplying matrices by vectors can be achieved by declaring multiplication to be a friend of both these classes). An additional argument is needed in friend functions so as to identify the Object to which the function is to be applied. Fur thermore, friends can facilitate the calling of C++ functions from normal C programs; how ever, this particular aspect must be used with great care so as not to compromise encapsulation.
In C+ +, inheritance is achieved by means of subclasses (referred to as derived classes). Derived classes inherit all the properties of their base class in terms of which they arc defined as public. Since a base class may itself be a derived class, complete hierarchies can be created. Furthermore, inherited methods can be overridden by creating methods in the SubClass with the same method name that was originally inherited from the base class.
Similar to Smalltalk, operator overloading occurs when the same name is used for different methods within the same hierarchy.
Although C+ + has 1JO automatic garbage collection, this feature can be implemented by the programmer or provided by an environment with the appropriate code libraries.
7.3.3 PROCOL: PROtocol-constrained Concurrent Object Language
PROCOL [van den Bos 1989] is a parallel Cbased Object-Oriented Language with communi cation based on one-way synchronous message transfer (identical to CSP [Hoare 1978, 1985]).
May 1994 C Kyriakides Page 125 Existing Models Objed-Oriented Parallel Paradigms
PROCOL controls Object access by an explicit per-Object protocol. This protocol is a specification of the occurrence and sequencing of the communication between the Object and its partners.
By taking Objects as the candidates for parallel and distributed processing, PROCOL capi talizes on the relative independence of executing Objects. Internally, PROCOL Objects are purely sequential programs. Externally, Objects run in paralle4 unless engaged in communication. (Thus according to our Object Taxonomy, PROCOL Objects are said to be Internally-Sequential Objects). Communication partners are defined by Object instance iden tifiers, or by type. Therefore send-receive mappings may be 1-1, 1-n, or n-1; though only one message is transferred.
In PROCOL the exportable Object Services are specified internally as Actions. These Actions provide the only interface with the outside world. Generally, Actions may depend on one another or on communication with some other Object. Moreover in PROCOL, eligible actions may also depend on the state of the Object, because a Protocol constrains possible commu nications, and thus access to the Object's actions. The Protocol determines the allowable actions in a given state as well as the (partial) ordering of the actions. A run-time communication is legal when the Object is in the right state, and when the actual sender and requested action correspond with sender (type) and action specified in the protocol interaction(s) for that Object state.
Furthermore Actions are atomic; this implies that the Object processing an Action first has to complete its processing of that Action before it can receive a new Message. Hence, per Object only one action can be active at a time. It should furthermore be noted that objects are only bound during message exchange (not during processing of a message).
The PROCOL model imposes an ownership hierarchy between Objects based on their cre ation. Furthermore, the ownership of a created object may be transferred from its creator to another Object. This need may arise if we require to retain an Object while the creator of that Object needs to be destroyed. In this case, the identity of the Object is revealed (thereby transferring ownership) to its new owner and simultaneously the creator is destroyed.
In summing up, the significance of PROCOL to the OOPP research lies not in its overall policy on Concurrent Object-Oriented processing, but instead, in a limited number of PRO COL's characteristics; (most of these will be discussed in greater detail in other sections):
May 1994 C Kyriakides Page 126 Existing Models Objed-Oriented Parallel Paradigms
Synchronisation based on unidirectional messages.
Binding of Objects occurs only during message passing (as in CSP) and not during processing of that message.
Messages may be sent not only between an Object and an Object, but also between an Object and a Class of Objects.
The eligibility of an Action received for processing by an Object can be established by the Protocol based on which Object sent the Message, the Action requested, and the state of the receiving Object.
Support for a dynamic ownership hierarchy.
PROCOL's major shortcoming is that Objects are taken to be the grains of parallelism. What this implies is that Objects are essentially Internally-Sequential. Wegner [1989] (see section 1.7) states that certain applications require a fine-grained concurrency within an abstraction (i.e. models with internally-concurrent objects) while others require a model of concurrency coarser than its unit of abstraction (i.e. models with internally-sequential but externally concurrent objects). Thus PROCOL cannot be viewed as a general purpose vehicle for Con current Object-Oriented Processing, since during the analysis effort, any candidates for concurrency discovered internally within an Object cannot be exploited. Only external concurrency between two Objects can be exploited. Although this simplifies the conceptual aspects of the model, it also imposes unnecessary restrictions on the range of problems that the model can readily handle.
Based on the Object Taxonomy introduced in section 5.3, the PROcOL paper fails to address how it handles/views composite Objects. Since in the PROCOL model, Objects are Internally-Sequential and Externally-Concurrent (i.e. parallelism may only be exhibited exter nally between Objects), we are lead to believe that in the PROcOL model, Objects consisting of smaller sub-Objects cannot be fully represented. In other words, only Sub-Objects that are Mutually-Sequential can be used to form a composite Object. Stated more formally: we can only deduce that, all Objects are viewed to be Granular Objects and/or that Assembly Struc tures (Composite Objects) cannot be fully catered for in the PROCOL model. The van den Bos [1989] paper unfortunately failed to address how PROCOL handles (or if it can handle) this issue.
May 1994 C Kyriakides Page 127 Existing Models Objen-Oriented Parallel Paradigms
7.3.4 Conclusion: C Based Languages
C-based languages, such as Objective-C and C+ +, endeavour to present an Object-Oriented language whilst maintaining support for vanilla C code. The benefit of maintaining syntactic and semantic consistency with vanilla C lies in enabling existingC code to be incorporated into Object-Oriented programs. From a syntactic and semantic perspective, it is anticipated that programmers already familiar with vanilla C programming will find the transition to Object Orientation (using C+ + or Objective-C) much easier. Unfortunately, from a conceptual per spective the transition from procedural to Object-Oriented programming remains largely unaffected.
Furthermore, the ability to program in either procedural or Object-Oriented code within the same environment can also give rise to violations of Object-Oriented programming concepts; in particular with regards to encapsulation and information hiding. To elaborate, Objects within a pure Object-Oriented environment should theoretically interact only by means of message passing, while the private parts of an object may not be accessed or modified by any other object in the system. Unfortunately, C's notion of pointers caters for various pointer operations including pointer arithmetic and explicit address assignment. It may prove beneficial to implement pointers to objects; however, pointers to an attribute/method within an object should not be allowed as it violates the principles of encapsulation; namely, an object's private state could be directly accessed or modified from another object by means of a pointer without using messages.
Indirectly, we thus raise the issue pertaining to the lack of suitability of unrestricted imple mentation of pointers in Object-Oriented environments. However, what is of primary impor tance is not the issue of pointers as such but rather, "what implications exist in attempting to maintain syntactic and semantic consistency with earlier languages?" Clearly the associated benefits need to be weighted out against the corresponding disadvantages.
In Objective-C, classes exist as "static" Objects that are created at compile-time and cannot be dynamically created. Furthermore, Objective-C type checking facilities for objects are extremely sparse; namely, only one object type exists, id. In contrast, C++ supports a signif icant number of built-in object types and also allows additional types to be defined. As men tioned previously, systems accommodating a very sparse type system will generally exhibit limited type checking capabilities; while, systems accommodating a richer type system will generally exhibit greater type checking capabilities.
May 1994 C Kyriakides Page 128 Existing Models Object-Oriented Parallel Paradigms
Before commenting on encapsulation in C++, we recall the benefits of private and public parts of objects as discussed earlier: the private parts represent a portion of an object that is encapsulated from other objects; while, public parts represent the interface an object avails to other objects. Furthermore, the private and public parts may comprise of both attributes and methods. Taking into account the Responsibility-Driven approach [Wirfs-Brock 1989], care should be taken to avoid data structure dependencies between objects. H possible only meth ods should exist in the public part of C++ objects; although not foolproof, this guideline should prove of great benefit in limiting interference amongst C++ Objects by restricting Object interaction to message passing. At this point friends need to be revisited. A function that is not a member of a class can be declared to be a friend of that class; the function can then access the private parts of the class. Declaring a vanilla C function to be a friend of a class allows ordinary C programs access to object-oriented programs. If this is not used with care, encapsulation can be violated.
Procol restricts objects to be the grain of parallelism (internally-sequential). This restriction can greatly simplify the analytical aspects, unfortunately, it also restricts the range of problems that the language can suitably address. Furthermore, it also limits the prospect of encapsulat ing existing concurrent applications inside a Procol object; for example, an existing concurrent application cannot be incorporated into a Procol model by simply providing an object that acts as an interface between the Procol application and the concurrent application.
Procol imposes an "ownership" hierarchy between objects based on their creation; namely, an object is owned by the object that requested its creation. Furthermore, the ownership of objects can be passed on to other objects. This approach could give rise to several interesting implications from an object management perspective.
Earlier we proposed that compilers of such hybrid languages (i,e, C++) should also provide an optional stricter form of compile-time checking for Object-Oriented programming. Fur thermore, since Objects promote modularity in programs, in essence, Object technology attempts to give rise to objects that are as far as possible independent from other objects in the system. Thus it may even be possible to implement a more finely controlled form of compiling; for example, by default, all code could be assumed to strictly obey Object-Oriented rules while specific code segments that do not conform to the Object-Oriented rules could be explicitly indicated as such. The primary point to raise here is that each such non-conforming segment should be fully enclosed (encapsulated) within an individual Object; namely, all
May 1994 C Kyriakides Page 129 Existing Models Objed-Oriented Parallel Paradigms
interdependent portions of each individual nonObject-Oriented segment should be encapsu lated within a single Object. Stated more formally, Object technologies attempt to achieve optimum encapsulation between objects; if encapsulation was optimal, then each object could theoretically be compiled independently and the individual compilations linked (taking into account the various objects' interfaces). Furthermore, if so desired, each object could be compiled with its own specific compiler parameters.
7.4 LISP Based Languages
liSP has established itself as one of the primary languages for ArtificialIntelligence; in particular, Common LISP [Steele 1984] has steadily been gaining popularity as the de facto standard for liSP. Some of the characteristics of liSP include garbage collection, dynamic binding, editors, debuggers, a uniform typeless style and a large number of reusable functions; although liSP and Common liSP are not Object-Oriented, in essence, these characteristics fulfill the prerequisites required to implement a Smalltalk style Object-Oriented language [Graham 1991]. Attributable to these characteristics, a large number of Object-Oriented extensions of liSP have been developed (e.g. these extensions include Flavors [Moon 1986] [Cannon 1982], Loops [Bobrow 1983], Com monLoops [Bobrow 1986], CommonObjects [Snyder 1987], KEE, GoldWorks, etc.); one such noteworthy system is CWS, the Common LISP Object System [Moon 1989], which will be discussed in greater detail in the following subsection.
As is generally the case in AI, a frame is a structural abstraction used to represent Objects. Frames ore data structures comprising of slots which may contain data and procedures. In particular, a frame consists of an extendable list of slots; these slots are equivalent to attribute or class vari ables. Slots may contain both state and process descriptions. Methods are attached to a particular slot. Facets ore methods for determining search, default values and triggers. Thus, slots containing state may not only have value but also facets.
Inheritance systems of some liSP extensions are characteristic of liSP's AI influence in that not only attributes are inherited but also their values. Multiple inheritance is in most cases supported. Thus, in liSP extensions where multiple inheritance is supported, two types of conflicts are pos sible: name conflicts and value conflicts. Name conflicts occur when an object inherits from its superclasses two different attributes or methods with the same name. Value conflicts occur when
May 1994 C Kyriakides Page 130 Existing Models Object-Oriented ParaDel Paradigms
an attribute inherits two different values from its superclasses. Most object-oriented literature deal only with name conflicts as they are more common; however, since in the case of AI applications, values can also be inherited, AI literature also deals with value conflicts.
Event-driven processes, called demons, are attached to data structures and fire when the structure is accessed. Demons act as triggers in the database literature providing special case methods; for example, when a database structure to which an "if needed" or "if updated" demon is attached then the appropriate process will be fired when that structure is accessed (by means of the "if needed" demon) or updated (by means of the "if accessed" demon). Backward and forward chaining demons may be specified to simulate pre- and post-conditions, triggers and side-effects.
In most Object-Oriented environments the methods are attached to the objects; however, in LISP extensions these methods are not attached to the objects but instead are attached to the attributes of objects. What is important to note here is that, in some Object-Oriented environments, methods are not necessarily attached to objects but are instead attached to the attributes of the objects. (For further information please refer to Graham [1991]).
Before presenting CLOS, we very briefly introduce Flavors [Moon 1986], an Object-Oriented extension to LISP and a predecessor of CLOS. Like many LISP-based extensions, Flavors supports multiple inheritance. A noteworthy contribution of Flavors multiple inheritance concept is embodied in the notion of mixins; moons are packages of operations in Classes that can be "mixed in" to other Classes. Mixins are used to add functionality to existing classes. Mixins do not have any instances and are thus abstract classes. (If further information is desired, readers are referred to the seven conflict strategies for the Flavors system in Shriver [1987]).
7.4.1 CLOS
CLOS [Moon 1989] is the acronym for the Common LISP Object System, an object-oriented programming language based on Common LISP [Steele 1984]. Like Smalltalk, CLOS was designed at Xerox Palo Alto Research Centre and benefited from the experiences gained from other LISP based languages such as Flavors [Moon 1986; Cannon 1982] and CommonLoops [Bobrow 1986]. CLOS has been steadily gaining acceptance as a de facto standard for object oriented LISP extensions. (To learn to program in CLOS readers are referred to Keene [1989]).
May 1994 C Kyriakides Page 131 Existing Models Object-Oriented Parallel Paradigms
CLOS, being based on USP, implements garbage collection, occasionally at inconvenient moments. The same mechanism used by LISP to allocate storage at run time enables support for dynamic binding.
7.4.1.1 The Three Layers of CLOS
To cater for the extensibility and malleability of Clos, CLOS is structured into three layers [Moon 1989]. Although most users will not need to delve deeper than the first layer, we will briefly mention all three. What is important to note is that each underlying layer is accessible to the system developer and presents increased levels of complexity; systems developers are thereby enabled to modify the underlying layers so as to extend the CLOS language or create a totally new language.
The first layer presents the basic language used for everyday programming. It presents a programmer with a straightforward syntax for defining the various fragments of an object-oriented program. The second layer, containsprimitives of the first layer and func tions utilised to accomplish all the essential operations of developing and executing object-oriented programs. Although the first layer refers to the entities in the second layer by symbolic names, the second layer manipulates them directly as objects. The second layer is typicallyused by programmers who find the facilities provided by the first layer to be inadequate. The third layer describes the internal mechanisms ofCLOS itself. This layer can be used to metamorphose the internal mechanisms of CLOS so as to create an entirely new object-oriented language (if so desired); or to simply cater for future exten sions and adaptations of CLOS to new ideas on the object-oriented model.
7.4.1.2 Basic Concepts
CLOS is based on the ideas of generic functions, multiple inheritance and method combination. Objects are organised into classes, and every object is an instance of some class. Every object has a unique identifier which is used to distinguish it from other objects. Although the majority of classes have names, CLOS also caters for anonymous classes in its second layer.
May 1994 C Kyriakides Page 132 Existing Models Objed-Oriented ~raUel Paradigms
In CLOS, the term structure refers to the passive properties of an object, while the term behaviour refers to the active properties. The behaviour of an object is the set of operations that the object can perform. The structure of an object comprises of its identity, its class, and if it has any slots, the contents of its slots.
In CLOS, a type represents a set of objects. Since two sets can overlap and a set can have subsets, an object can be a memberof more than one type. Types assist to organise and classify objects (as well as classes); furthermore, types can prove beneficial for compiler optimisation. Thus CLOS mandates that every class is a type. It should be noted that in CLOS every class is a type, and every object instance must belong to a class. It should also be noted that, the members of a class comprise not only of the instances of that class but also the instances of all the subclasses of that class. Thus the concepts "instance of a class" and "member of a class" are not equivalent.
Like Smalltalk, CLOS regards everything to be an Object. This homogeneous perspective includes CLOS's own language constructs which are viewed by means of meta-objects; meta-objects provide particularly good facilities for extending the language itself. Meta Objects allow the basic structure of the Object system to be altered.
7.4.1.3 Slots
As was mentioned previously, slots containing state may not only have value but also facets (methods). Furthermore, slots may contain pointers to other objects representing the state of the entire object. Slots ability to contain state (values) and process descriptions (facets) establishes an important distinguishing characteristic between CWS and many Object Oriented programming languages. Owing to its LISP heritage, classes in CLOS do not only inherit attributes but can also inherit the default values of those attributes. Furthermore, slots may also have default methods. Both slot defaults and method defaults may be overridden. Like Smalltalk, CLOS subclasses may add slots, methods, type and initialisa tion conditions to those inherited from superclasses.
Furthermore, slots may be either type restricted or free; in other words, slots may be restricted to storing values of a specified type, or they may be permitted to store any variable regardless of its type.
May 1994 C Kyriakides Page 133 Existing Models Objed-Oriented Parallel Paradigms
Unfortunately, slot names are encapsulated but not hidden [Graham 1991]; this implies that CLOS classes are not true abstract data types. .. 7.4.1.4 Generic Functions and Methods
In Common LISp, generic functions are able to work on Objects of several types. Func tions can be called with a variety of arguments and the type of a value is then determined at runtime; in such cases, the body of a Common LISP generic function comprises of a conditional form that tests the types of the arguments and implements the code appropriate for the particular arguments received.
In contrast to the conditional format of generic functions in USP, CLOS extends generic functions by introducing the concept of methods. A method specifies what a particular generic function is required to do when called with particular combination of argument types. Unlike Common LISP where all the possible cases are enclosed within the body of a single function, in CLOS the generic function only contains a description of the method in terms of an individual method's name as well as its argument types; the individual methods (along with their function body) are defined separately from the generic function body. Hence in CLOS, each generic function provides an interface to a number of distinct methods, and the method to be invoked is determined by the classes of the arguments to the function. There is no limit to the number of methods that a generic function can have. The selection of an appropriate method is automatically done by the CLOS system and does not have to be programmed explicitly. If no method exists that matches the argu ments received, then an escape hatch is called which typically reports an error.
The advantage of CWS methods lies in greatermodularity as each method is by and large independent from other methods; in contrast to this, in Common USP the programmer needs to simultaneously understand all the possibilities that may exist within a generic function. It should be noted that, a generic function applies to many cases, however a method applies to a single case; for this reason, a method is said to specialise a generic function.
Accessor Methods are used to give access to or update the value facet of a slot. Accessor methods are beneficial in that they enable us to conceptualise directly about attributes in
May 1994 C Kyriakides Page 134 Existing Models Object"()riented Parallel Pa~~
an Object-Oriented environment without concern for the fact that this informau.()Q is represented by a slot. In other words, the implementation of state is hidden behinJ wn• ventional accessors such as report, update, delete and change value.
7.4.1.5 Initialisation
A new object can be created by the make-instance function. At the time a new o"je~t is created, its arguments can be initialised either by initialisation arguments (in tefll\g Of keyword arguments [Steele 1984] supplied with argument values to the make-ittst~ce function) or by initialisation methods (such as initialise-instance written by the progr~,ney for that particular type and called immediately after the new object is created ~ the make-instance function). In addition to the capabilities of initialisation arguments '¥J1el"e slots are simply filled in with values, initialisation methods can also create sutlsiJiat"y objects, enter the object into a registry of all instances of its class, extract some data {TOnt a database into slots, or implement additional initialisation arguments [Moon 1989].
7.4.1.6 Inheritance
CLOS supports Multiple Inheritance. A class inherits characteristics from its supt'cltJSSes; the characteristics inherited include type, slots, methods, and initialisations. Ill4eritcd characteristics can be overridden in the normal fashion; for example, an inherited ~ttibute (or method) can be overridden by declaring a new attribute (or method) using tll~ S3.ble name as the one inherited. When defining a class only the direct superclasses of a class need to be specified. Characteristics inherited from a class's superclass are in tufll ,llhcr ited by that class's subclass. Thus, a class's characteristics affects its own instances as \Yell as the instances of all its subclasses.
Under multiple inheritance, an inheritance conflict arises when two or more chartlettJis~ia are inherited wic.Jr the same name. To resolve conflicts arising as a result of toulliple inheritance, a class precedence list is drawn up by the programmer. This list stattSwith the class itself and includes each superclass only once; the earlier the class appeArs ill tbe list the higher its precedence. Where slot conflicts exist, only the slot belonging to tbe ~ass with the highest precedence is inherited; (method conflicts are handled differently aDd will be discussed shortly).
May 1994 C Kyrialddes Existing Models Objed-Oriented Parallel Paradigms
In CLOS, every class is a type. Type inheritance allows a class to inherit the type of its superclasses. Under type inheritance, a member of a given class is also a member of each of its superclasses and thus a class inherits the types of its superclasses.
Slot inheritance allows a class to inherit the slots defined in its superclasses. Under multiple inheritance, if two or more inherited slots exist with the same name then slot conflicts arise. Slot conflicts are handled by creating only one slot with characteristics that are determined from the conflicting slot's definitions (in conjunction with the precedence list mentioned above). Although the name of the slot remains the same, the type of the value that can be stored in the slot is restricted to the greatest common subtype. Also, the class precedence list is used to determine whether the slot is shared or local; (shared slots allow each member of a class to access and manipulate the same contents of a shared slot).
Initialisation inheritance allows a class to inherit from its superclass default values for the initialisation arguments and for initialising slots. Again, the class precedence list is used to deal with initialisation inheritance conflicts.
Method Inheritance allows a class to inherit methods defined in its superclasses. Under multiple inheritance, if no conflicts occur the methods are simply inherited in the normal straightforward fashion. However, when conflicts occur under method inheritance, instead of regarding the methods to be in conflict, CLOS regards them as cooperating. Under CLOS, this cooperation ofmethods is referred to as the method combination [Moon 1989]; this technique is based on the Flavors notion of mixins. The method combination mecha nism is utilised to control and organise the cooperation of several conflicting, inherited methods into one single implementation of a generic method [Moon 1989]. The best approach to cooperation of inherited methods is not a fully resolved issue at present, although it represents an important advance over the approach of other Object-Oriented programming languages. (For a more detailed look at method combination readers are referred to Moon [1989] and Keene [1989]).
7.4.2 CommonObjects
CommonObjects is an Object-Oriented extension to LISP developed by Snyder [1987). Com monObjects places considerable emphasis on not allowing inheritance to compromise encapsu lation. The concept whereby CommonObjects avoids compromising encapsulation revolves
May 1994 C Kyriakides Page 136 Existing Models Object-Oriented Parallel Paradigms
around allowing method inheritance and disallowing attribute inheritance. This idea is analogous to the Responsibility-Driven Approach proposed by Wllfs-Brock [1989]. The argu ment proposed by Wirfs-Brock is that attributes contain structural information and thus implementation of inherited attributes can result in structural information of these inherited attributes creeping into the non-inherited rnethods; this dependency on the structural infor mation of inherited attributes violates encapsulation.
An alternative suggestion to the guideline followed by CommonObjects is proposed by Dan forth [1988]; the Danforth paper proposes the existence of two distinct inheritance hierarchies for methods and attributes. However, inheritance in AI and typical LISP applications tends to resist this form of protection. Graham [1991], on the other hand, states that the protocols for protection suggested by Snyder could be realized by good programming practice rather than by compilers. (It is beyond the scope of this research to delve deeper into this subject).
7.4.3 MITRE's Future Generation Computer Architectures Program
The MITRE research paper (will be discussed in greater detail in section 12.1 has been exceptionally beneficial in an unexpected way. After independently developing the Object Oriented Parallel Paradigm (OOPP) based on the shortcomings of other proposals, we had been arduously searching for supporting articles to substantiate the numerous proposals introduced by OOPP. The MITRE research unexpectedly substantiated a significant portion of OOPP's Manager-Employee analogy (chapter 8). However, the responsibilities of "object managers" (generally referred to as agents) in the MITRE model were found to be a little shortsighted. Also, the analysis of the MITRE model seems to be muddled with implementa tion considerations. For example, the MITRE model relies on a distributed gtubage collector, although OOPP can embrace garbage collection faculties, OOPP does not insist on their presence. We could not find any supporting reasons other than the fact that MITRE's model is based on being implemented in a subset of Common Lisp; and Lisp is greatly dependent on garbage collection.
One primary distinction between the MITRE model and OOPP lies in their domain of application. The MITRE model is Operating System based, while OOPP (aimed to be more comprehensive) is Systems Development based.
May 1994 C Kyriakides Page 137 Existing Models Objed-Oriented Parallel Paradigms
7.4.4 Conclusion: LISP Based Languages
In general, Object-Oriented LISP extensions exhibit support for dynamic binding, generic functions, multiple inheritance and garbage collection. LISP's uniform typeless style and dynamic binding facilities give rise to a highly dynamic environment albeit at the cost of additional runtime checking requirements. As is generally the case, garbage collection can bring about serious implications for time-critical applications. Furthermore, special event-driven processes exist, called demons, that can prove beneficial in a development environment (e.g., in debug- ging).
Generic functions are simply one of the possible forms of polymorphism. However, the dis tinction mentioned above between generic functions in LISP and in CLOS should be noted. In LISP a generic function is represented by a single function embodying all possible cases (the appropriate selection made by means of several conditional statements); in CLOS a generic function acts as an interface to a number of distinct methods (sharing a common name but having distinct argument types). Unlike in LISP, the responsibility of determining which function should be used for processing is determined automatically by the CLOS system.
Unlike other Object-Oriented systems, in LISP extensions, Objects are represented in terms of frames comprising of slots (attributes); these slots may contain data and procedures. As men tioned previously, slot names are encapsulated but not hidden, and thus CLOS classes are not true abstract data types. Furthermore, LISP based approaches implement objects as a set of slots; with the provision of accessor methods however, system developers are able to concep tualise objects in terms of abstract attributes instead of a set of slots.
The make-instance function is used to create objects. Objects can be initialised at the time of creation by means of initialisation arguments or by initialisation methods.
Object-Oriented LISP extensions cater for both attribute inheritance, as well as, value inher itance. Thus, slots may have default methods and default values which may be overridden. Since, multiple inheritance is supported, it can give rise to value and method conflicts. In particular, CLOS supports type inheritance, slot inheritance, initialisation inheritance and method inheritance. With the exception of method conflicts, most inheritance conflicts are handled in a straightforward way; while method conflicts are handled by the method combi nation mechanism (similar to mixins in Flavors).
May 1994 C Kyriakides Page 138 Existing Models Objett-Oriented ParaDeI Paradigms
Analogous to the Responsibility-Driven approach [Wirfs-Brock 1989], CommonObjects [Snyder 1987] attempts to enhance encapsulation by allowing method inheritance and disallowing attribute inheritance.
7.5 PROLOG Based Languages
In this section we briefly address the field of Object-Oriented logic programming. Several systems have managed to unite the object-oriented and logic programming paradigms. What is surprising about this achievement is the fact that at first glance object-orientation and logic programming seem to be moving in opposite directions. Logic programming endeavours to provide a completely unified system whereby all inferences of known facts relevant to a specified goal can be deduced automatically at any given time. In contrast to this, Object-Orientation attempts to encapsulate everything within distinct objects. (Should further information be required on PROLOG readers are referred to more detailed works on the subject, such as, [Clocksin 1984].)
7.5.1 PROLOG/V
What should be noted in this section is that PROLOG/V adopts the idea of encapsulating an implementation within an object class; thus each instance of that class acts as an interface to one PROLOG/V implementation. Although PROLOG/V has the ability to manipulate Objects, PROLOG/V's approach to Object manipulation is rather unique. This can be attributed to the fact that PROLOG/V represents an attempt to introduce Object-Orientation into the earlier PROLOG model.
PROWG/V is an implementation of PROLOG within the Smalltalk/V environment, (PRO WG/V can thus be considered to belong to both the Smalltalk and PROLOG families). Even though it is not an optimised PROLOG version and will readily exhibit performance limitations with a medium to large-size program, it nonetheless avails sufficient information to indicate the advantages and disadvantages of such an undertaking.
For programmers migrating from PROLOG to PROLOG/V, there is very little difference in syntax. FIrstly, there are no special operators; thus all legal clauses conform to the same format as PROWG predicates: the name of the predicate followed by terms of the clause are enclosed in parentheses. Secondly, PROWG/V variables begin with a lowercase character; constants also begin with a lowercase character but are prefixed with a leading pound (#)
May 1994 C Kyriakides Page 139 Existing Models Objed'()riented Parallel Paradigms
character. And thirdly, queries are made by sending the :? message to a PROLOG class followed by a normal PROLOG query; if a PROLOG class does not exist when a message is attempted to be send then one is implicitly created before the message is send).
Like everything else in Smalltalk, PROLOG exists inside the Smalltalk environment as a class; in tum, each PROLOG application exists as a subclass of the PROLOG class; and thus, each instance of a PROLOG subclass is a complete version ofPROLOG. The number of possible instances is restricted only by the memory available. The subclasses allow development of separate fact bases or establishment of different extensions to PROLOG. Thus subclasses used as individual fact bases also rely on inheriting all the PROLOG predicates.
Unlike the PROLOG consult predicate which is used to read source code from disk files; the PROLOGjV consult predicate provides access to other PROLOGjV classes and objects. Furthermore, the is predicate provides access to the SmalltalkjV environment. In fact any SmalltalkjV method or PROLOG/V predicate can be called from any instantiation or subclass of PROLOG/V; this reusability of existing objects clearly represents an advantage of embed ding PROLOG in an object-oriented system instead of a conventional language such as C.
Furthermore, since PROLOG exists as a class inside Smalltalk/V, the Smalltalk class hierarchy and browser can be productively used in organising PROLOG programs. A special version of the Class Hierarchy Browser, called a Logic Browser, is utilised to enter PROLOG programs. PROLOG's general lack of a visual programming environment is to some extend addressed by the PROLOG/V Logic Browser which doubles up as a window-oriented editor.
The association class is used to handle arguments by providing a structure for associating pairs of keys and values. Each PROLOGjVpredicate may have only one argument - an object - which is an instance of the association class; this is in contrast to PROLOG where each predicate may have one or more arguments. Association objects are generally used in terms of dictionaries; a Dictionary is a collection of association objects. When using dictionaries, the key of the associations utilised to handle PROLOG arguments contains a list of arguments which have to be unified with each clause in the predicate's definition. The value slot of the associations contain blocks of code called continuation blocks; these continuation blocks are evaluated when predicates succeed. One obvious advantage of the embedded PROWG approach presented here is that a much greater variety of objects can be incorporated here
May 1994 C Kyriakides Page 140 Existing Models Objed-Oriented ParaDe) Paradigms
than is possible in standard PROLOG; for example, any of the objects Smalltalk knows about can be unified with the clause variables of PROLOG/V. This implies greater reusability of existing objects.
Since PROLOG/V is represented as class within SmalltalkfV, it is possible to access a PROLOG/V instance by sending a message to it from the SmalltalkfV programming envi ronment; in this way, PROLOG/V can be used to introduce high-level AI features into the Smalltalk/V environment (for further details see Tello [1989] which presents an example of using PROLOG/V's built-in list structures to cater for a Smalltalk/V open-ended database format capable of catering for very flexible data structures).
Unfortunately, PROLOG's limitations include very limited I/O and being restricted to PRO LOG's way of handling queries.
7.5.2 Concurrent Prolog
Concurrent Prolog is an extension to Prolog that can support object-based concurrent pro cessing [Shapiro 1983]; no explicit built-in mechanism exists to cater for class inheritance [Tello 1989]. Concurrent PROLOG extends standard PROLOG by allowing both OR and AND parallelism in the search for a proof. Furthermore, although Concurrent PROLOG supports the syntax of standard PROLOG, the syntax of Concurrent PROLOG is extended to support the commit operator and the read-only variable construction; which will be discussed later on in this section. Despite an almost identical syntax, major differences exist in the way computation is performed; the primary difference being that Concurrent PROLOG cannot backtrack in order to find all solutions for a given goal.
Unlike most other object systems, Concurrent PROLOG does not implement its objects in terms of call/return message passing; instead, Concurrent PROLOG implements communica tion by means of communication channels. Logical variables may be either instantiated or uninstantiated: Once instantiated however, the value of the logical variable may not be modified. Hence a logical variable acts as a communication channel that transmits a single message; (for this reason, communication channels are sometimes also referred to as immutable message streams). Thus, one property of Concurrent PROLOG not found in other object systems is that processes and streams are entirely free of side effects. A stream of messages may be simultaneously shared between many processes and thereby effect broadcasting of information throughout the system. Another distinctive aspect of Concurrent PROLOG is that it is an
May 1994 C Kyriakides Page 141 Existing Models Objed.Qriented Parallel Paradigms
object-oriented system in which the objects themselves are active. The concurrency style presented by Concurrent PROLOG makes it possible for numerous objects to be actively processing at the same moment. This concurrency is furthermore simplified by Concurrent PROLOG using immutable streams instead of pointers to changeable objects; Concurrent PROLOG differs from most other object-oriented systems in that it does not have pointers to objects. In Concurrent Prolog the message stream does not allow for side effects and thereby maintains the identity of objects.
Parallel processes are managed through the use of two additions to Prolog:
Guarded Command Indeterminacy allows a process to explore some of the goals in the body of a clause in parallel prior to deciding whether to pursue the remaining goals.
Data flow synchronization is accomplished through the use of "read only" annotation on variables. Occurrences of variables can be labelled as "read only"; a process attempting to instantiate such a variable suspends execution until that variable is instantiated by another process.
A Concurrent Prolog program consists of a finite number of guarded clauses. The basic head-neck-body structure of Standard PROLOG clauses is extended by Concurrent PROLOG to include an optional leading section in the body which contains guarded clauses; guarded clauses are separated from ordinary clauses by the commit operator (I).
H :- Gl,•..,Gm I El,...,En. m,n >= 0
where H is the head of the clause, Gl,...,Gm depict a sequence of guarded clauses, (sometimes also called the guard of the clause) and El,...,En represent ordinary PROLOG clauses. The commit (I) operator replaces a comma separator. If there are no guarded clauses then the commit operator is omitted, and the main clause reduces to an ordinary PROLOG clause.
H :- El,...,En. n>O
If there are no ordinary clauses (E's) the term true follows the commit operator.
H :- Gl,....Gmltrue m>O
May 1994 C Kyriakides Page 142 Existing Models Objed'()riented ParaDel Paradigms
Declaratively, a guarded clause can be interpreted "H is true if the G's and E's are true". Procedurally, a guarded clause can be interpreted "To reduce goal A, unify A with H and, if successful, reduce the Gs to the empty system and, if successful, commit to that clause and, if successful, reduce A to the Es. A unit goal corresponds to a process, while a conjunctive goal corresponds to a system of related processes. Processes are created when goals are reduced; processes die when they are reduced to true, the empty goal.
The commit operator has two purposes. rust, it ensures that the given goal is reduced to the body of only one guarded clause; as soon as a single guard attempts to commit, all the processes associated with other guarded clauses whose heads unified with the given goal are terminated. Hence Concurrent PROLOG yields a single solution to any goal. The second purpose of the commit operator is to export the bindings of the variables in the guard to other processes sharing those variables.
Unlike PROLOG, Concurrent PROLOG is able to implement read-only variables. Read-only variables are indicated by a trailing question mark (?) attached to the end of the variable's name (with no space separation). Using a variable in this way implies that a value must not be attempted to be found for this variable or used until some other process gives it a value. The primary purpose of read-only variables is to provide a mechanism for controlling unifica tion by means of goal reduction synchronisation.
As mentioned, two primary types of parallelism exist in Concurrent PROWG [Tello 1989]:
OR-paralellism: A parallel search for a clause that unifies or commits is undertaken; and as soon as a clause is found, the processing of all other clauses ceases. (In less formal terms this implies simultaneous execution of the guard of every guarded clause G1,...,Gm whose head unifies with the goal).
AND-parallelism: A parallel search for a clause that unifies or commits is undertaken; the clauses that define the condition of a predicate are and-ed together. (In less formal terms this implies, simultaneous execution of conjunctive goals within a single guard).
When a goal is given, the guards of all the guarded clauses (Gs) whose head unify with the given goal are executed concurrently (OR-parallelism). In the case where a number of con junctive goals exist within a single guard, these goals execute in parallel in the same environ ment (AND-parallelism). Furthermore, processes associated with different guarded clauses (Gs) operate in independent environments and do not communicate with each other. When a
May 1994 C Kyriakides Page 143 Existing Models Objed-Oriented Parallel Paradigms
guard succeeds (note that a guard represents all the Gs), an attempt is made to unify the guard's environment with the given goal; if successful the clause is committed and the goal is reduced to the body of the guarded clause.
7.5.2.1 Vulcan
Vulcan [Kahn 1986; Kahn 1987) is an Object-Oriented syntactic extension to Concurrent PROLOG with facilities for breadeastlng, inheritance, and delegation. Vulcan avails to a programmer various high-level predicates that facilitate the development of object-oriented logic programs. As was the case with Objective-C, in Vulcan a preprocessor provides for syntactic sugaring by allowing programmers to develop programs by working in the more concise Vulcan syntax; the resulting code is then translated by the preprocessor into a Concurrent PROLOG program.
Since Concurrent PROLOG does not support pointers to objects and Vulcan is based on Concurrent PROLOG it is clear to understand why Vulcan does not support pointers to objects. As in Concurrent PROLOG, Objects in Vulcan conserve their identity only through the integrity and continuity of the message stream. As a result of this, the only means by which two different processes can send messages to the same object involves merging their message streams into a single stream which is then received by the object. However this cannot be done directly from Vulcan and instead has to be done explicitly by programmers in Concurrent PROLOG by what is referred to as splitting the message stream to the object.
The message-sending protocol in Vulcan is provided by means of the send predicate, which appears in the format send(Receiver,Message). Similarly the method predicate is used to define messages. As is the case in Smalltalk, the pseudo-variable Self is also used in Vulcan.
An object's state is changed by the become statement. Messages formulated sequentially are considered as being sent to successive states of the receiver object. Expressions appearing after a become statement are considered to refer to the receiver's new state. All messages after a "send to Self message are packaged by Vulcan into a continuation method with the selector pointing at the location on the message stream subsequent to earlier messages.
May 1994 C Kyriakides Page 144 Existing Models Objed'()riented ParaDel Paradigms
Vulcan, like ConcurrentPROLOG, does not have any explicit built-in mechanism to cater for class inheritance. Nonetheless, Vulcan provides two methods for implementing inheritance:
inheritance by a description copying mechanism concerned with producing sub classes; and,
inheritance by delegation to parts (originally introduced by Shapiro [1983] for Concurrent PROWG). This means that the contents of the superclass is contained within the subclass as part thereof.
In Vulcan, when a subclass is declared, the superclasses are provided (by the programmer) as the third argument; the Vulcan precompiler is thereby able to create within the subclass source copies of all the methods and variables of its superclasses. Multiple inheritance occurs when the superclass field is occupied by more than one class.
As was mentioned, in Vulcan, inheritance by delegation to parts implies that a subclass contains the contents of its superclass as a part thereof. When a subclass receives a message that corresponds to one of (the methods inherited from) its superclasses, the subclass delegates the incoming message to that part of itself corresponding to the appropriate superclass, Tello [1989] states that a serious object-oriented system for AI should offer both inheritance and composite objects.
7.5.3 SPOOL
The SPOOL language is an object-oriented extension to PROLOG developed at IBM (Japan) using VM/Programming in Logic. SPOOL attempts to combine object-oriented and logic programming so as to maintain the maximum degree of benefits existing in each field. SPOOL appears to capitalise on useful features of languages such as Smalltalk and Flavors; for example, SPOOL's approach to handling multiple inheritance is analogous to that of Flavor's mixin feature.
Under other object-oriented systems both the specific object to which a message is passed as well as the message itself has to be fully specified. In SPOOL however, either the message or the recipient of a message may be unspecified in terms of an unbound variable and thereby give rise to a technique ofanonymous message passing. This technique opens up new and powerful
May 1994 C Kyriakides Page 145
Existing Models Objed..()riented Parallel Paradigms
SPOOL presents a straightforward syntax that can be beneficial in application development. Generally, methods adopt a Prolog-like syntax, while inheritance relationships between classes resemble the spoken language (e.g., "class student has superclass person").Multiple inheritance is also supported.
From the above, it is clear that language environments may exist that are beyond the scope of general-purpose object-oriented models. For these environments (such as Prolog), it may prove more beneficial to develop models specifically suited to them. In the first paragraph on Prolog we stated that logic programming and object-orientation appear to follow differ philo- sophies with regards to encapsulation. In fact detecting such differences may prove vital as indicators pertaining to the suitability of general object-oriented models for a particular environment.
7.6 Actor Based Languages
Actor systems are concurrent message-passing systems based on the notion of active objects called actors. The actor model provides for a high degree of encapsulation. Message passing provides the only means by which actors can interact and is also used to control concurrency. Unlike in CSP [Hoare 1978, 1985] where communication is synchronous and resembles a hand shake, in actor systems communication is based on a mail system which buffers communication.
Furthermore, actor systems have no class mechanism and (in terms of Wegner's taxonomy) are thus object-based. Instead, delegation is used to simulate a classless form of "inheritance" (this will be discussed in greater detail later on in this section). Class-based languages are concerned with the structural organisation of knowledge and thus place emphasis on the structural abstraction of a model; in contrast to this, actor languages place emphasis on the communication structure of interacting processes.
Each actor has a script which specifies its behaviour - this includes what messages an actor may accept for processing. An actor's behaviour remains unchanged until it is explicitly changed.
In actor systemsmessages are usedto control concurrency; however, there is no explicit construct for receiving a message. Thus actions taken by the current behaviour of an actor are independent of any subsequent messages. Furthermore, when a set of actions is required to be performed that depends upon several request-reply interactions with an actor's acquaintances, a sequence of behaviours needs to be implemented.
May 1994 C Kyriakides Page 148 Existing Models Objed-Oriented ParaDel Paradigms
Hewitt [1977] presented a model where computation is approached in terms of various patterns of message passing among entities called actors. Actor systems have evolved from languages such as PLASMA, ACT} [Lieberman 1987), ACT2 [Theriault 1983] and ACT3 [Agha 1986; Agha 1987a; Agha 1987b]. (Earlier works related to the actor model include Hewitt [l9'n] and [Lieberman 1985]). In fact, the ACf1, ACI'2 and ACf3 languages present a series of progressive investiga tions into various aspects of expressing and controlling Object-Oriented concurrency. Well devel oped formal semantics exist for the actor approach to computation [Clinger 1981; Agha 1986].
7.6.1 The Actor Model
Analogous to Smalltalk where everything is an Object, in actor systems everything is an actor; thus actor systems are homogeneous.
Each actorin the actor model is active in a manner that is independent of otheractors; also, all ofthe actions taken by an actorupon receipt of a message are concurrent (in other words, there is no implicit serial ordering of the actions in a method). Tomlinson [1989] attributes these characteristics of actors to facilitate descriptions of maximal concurrency.
7.6.1.1 Common Characteristics
Actor systems have the following common characteristics:
Actor systems are homogeneous; everything in the system is an actor.
The only way in which actors can interact is by passing messages from one actor to another.
Each actor has its own behaviour which is defined by a script; an actor's behaviour determines how an actor will respond to the next incoming message.
An actor can only pass messages to its acquaintances; these are other actors it knows about.
Each actor has the ability to reject incoming messages by delegating them to another actor.
Since actors are active objects and actor systems are homogeneous, this implies that no passive objects (or data) exist in actor systems. Thus databases, lists, numbers, characters, devices, etc., all have to be defined as actors. As a consequence, no shared/global data can
May 1994 C Kyriakides Page 149 Existing Models Objed"()riented Parallel Paradigms
exist; the only way in which information can be "shared" is by storing this information in an actor and (if the script permits) this information can be obtained by sending messages from one or more actors. This characteristic of actor systems provides for a high degree of encapsulation.
An interesting innovation of actor languages is the use of distributed interpreters; since there are no classes there is no shared repository of behaviour and no special location for holding a template for Instance generation.
7.6.1.2 Basic Concepts
All actors have a unique identity and a current behaviour. Each actor has a unique and permanent identity which is retained from the moment the actor is created to the moment that actor is destroyed. Furthermore, actors have a current behaviour which determines how the actor will respond to the next incoming message. However, unlike the actor's identity, an actor's behaviour may change over an actor's lifetime; (the current behaviour persists implicitly until a replacement behaviour is explicitly specified). Nonetheless actors do exist that retain the same behaviour throughout their lifetime and these are called unserialised or immutable actors.
An actor's behaviour comprises of instance variables called acquaintances, and methods called its script.
As was mentioned, an actor can only communicate with his acquaintances. For this reason, an Actor that is not an acquaintance of any other actor in the system will never receive any further messages and is thus a candidate for garbage collection; please note that this is not the same as "an actor who has no acquaintances".
7.6.1.3 Basic Commands
Actor languages have four basic types of commands:
Send: used to send messages.
Let: used to assign or bind expressions to name identifiers that fall locally within their scope.
Conditional: provide mechanisms for branching.
May 1994 C Kyriakides Page 150 Existing Models Object'()riented ParaDel Paradigms
Become:used to specifyreplacement actors; the expression contained in the become command may specify an existing actor or it may specify a new actor to be created. In the latter case, the actor to which the become statement is addressed becomes the forwarding actor for the new actor that is created.
Thus from a behavioural point of view, upon receipt of a message, the current behaviour may only take a finite set of actions of the following four types:
simple conditional
sending a message
creating a new actor, and
specifying the replacement behaviour.
When creating an actor it is required to specify the script and the initial acquaintances of the new actor.
Furthermore, on receipt of a message the current behaviour may replace itself.
7.6.1.4 Primitive and Non-Primitive Actors
Actors can be categorised into primitive and non-primitive classes. Primitive actors are unserialised and correspond to the usual atomic types such as numbers and characters. Furthermore, their identity may be represented by their state since their behaviour remains constant. Non-primitive actors are represented by a mail-address and a current behaviour. When a non-primitive actor (such as a character) is sent in a message, it is in fact the mail-address of that actor that is sent. The current behaviour of a non-primitive actor may change.
7.6.1.5 Message Passing Protocol
The basic message passing protocol is unidirectional. Message passing is facilitated by means of a mailbox system where each actor has its own unique address. Each actor is aware only of its acquaintances (and their addresses) and can thus only sent messages to these actors. This gives rise to a connection topology represented by the sum of all the
May 1994 C Kyrialddes Page 151 Existing Models Objed-Oriented Parallel Paradigms
acquaintance lists in an actor system. The dynamic nature of the actor connection topology arises from an actor's ability to update its acquaintance list; thisis achieved by the fact that the mail address of an actor can be send as a message to another actor.
Furthermore. it is the responsibility of the mail-system to ensure that a message sent from one actor to another reaches the mail-queue of the appropriate actor.
The pseudo-variable self is always bound to the mail-address of the actor in which it appears.
7.6.1.6 Delegation
Actor based models [Agha 1986] are characterised by a delegation mechanism [Hewitt 1977). Delegation [Lieberman 1986; Lieberman 1987]presents a set ofconventions detailing how message passing can be used in the context of actors so as to obtain some ofthe effects of inheritance. The fundamental idea of delegation revolves around the fact that any actor that does not know how to respond to an incoming message should have one or more actors (called proxies) that can process the message on its behalf; the message redirected to the proxy for processing is said to be delegated to a proxy. (This is analogous to an object under a class-inheritance model receiving a message by which an inherited method needs to be invoked; a search is then made up the class hierarchy to find the appropriate method. For this reason, delegation is sometimes likened to a form of "classless inheri tance"). Since actors have no class-inheritance mechanism. delegation provides a means by which actor systems can be modularly and incrementally extended.
Delegation allows actors to delegate to other actors permission to perform operations on their behalf. This is beneficial in the case where possible conflicts may arise when using "mul tiple inheritance"; the benefit lies in the fact that. descendants do not need to inherit the implementation of their ancestors. Furthermore. it enables Objects to transform their behaviour without being constrained by Class.
A nuance of the actor approach that should be pointed out is that actors do not inherit the implementation; instead only the knowledge of the presence of the implementation and its location (in terms of in which actor it occurs) is "inherited". The actor is then able to redirect appropriate messages to the actor in which this implementation is located. It is thus clear that delegation greatly eases distributed processing (and avoids redundancy of
May 1994 C Kyriakides Page 152 Existing Models Objed.()riented Parallel Paradigms
implementation code) at the cost or additional message passing. (We will readdress the implications of inheriting knowledge of an implementation as opposed to inheriting a copy of the implementation at a later stage).
Communication bottlenecks can arise when many messages arrive at the same actor simultaneously. Attributable to this fact, before an actor accepts a message for processing it must first provide a replacement actor for handling subsequent messages. If messages arrive while an actor is carrying out a request, these messages are then handled by the replacement actor.
Agha [1987] states that actors replacement behaviour maintains:
referential transparency of identifiers: an identifier for an object will always denote that object even though the behaviour associated with that object may change; and that
the replacement actor does not effect the behaviour of the replaced actor: firstly, actions taken by the current behaviour of an actor are independent of any subse quent messages and secondly, the computation of a replacement actor is an action carried out concurrently to other actions performed by the actor.
In parallel message-passing computation, fairness refers to the guarantee that all messages will be answered sooner or later regardless of their priority; in this sense actors are considered to be fair.
7.6.1.7 Recursion and Communication
By default, message passing occurs through buffered asynchronous communication; if this is not done, recursive algorithms would always result in deadlock. In a message passing system, recursion occurs when an actor sends a message to itself.
Under a synchronously communicating system, the recursing actor would have to wait until the message was returned before answering and would thus result in deadlock. Unfortu nately, simply providing asynchronous message passing to avoid recursive deadlock might be suitable to sequential processing but not to parallel processing. If we consider that a process may recurse by sending messages to itself, then unless that process can receive more than one message at a time, recursion results in sequential processing. Since actors
May 1994 C Kyriakides Page 153 Existing Models Object-Oriented Parallel Paradigms
can only process one message at a time, actor systems address this problem by the con struct of customers under which greater control is provided over how and when messages are sent. Customers not only provide a means ofavoiding deadlock-prone situations, but can also be used to implement a fonn of pipelining. In essence, a customer serves as an intermediary between an actor sending a message to itself.
Customers work by making use of continuations. (As in Scheme USP), a continuation is an object representing how a given computation might continue; a continuation can be thought of a process waiting for the result of a current computation before any further processing can be done. In the case of algorithmic operations, such as recursive factorials, these operations are split up between the initial actor and the customer that spawns for itself to continue the computation.
7.6.1.8 Guardians
The basic one-at-a-time approach to synchronisation requires that a reply must be sent to an incoming message before an actor can accept a message from a different process; however, this can result in slow-downs, bottlenecks, and even deadlocks. Guardians serve to make message handling more flexible. Guardians achieve this by detecting when an actor must wait to reply to a message, save the processing environment needed for the answer to be made, and then process other messages in the mean time. In essence, guardians enable actor systems to make use of the notion of continuations.
7.6.1.9 Transactions
Transactions are founded on two specific kinds of communication, requests and replies. A request may in turn trigger another request; if the reply to the second request precedes the reply to the first request, the second transaction is said to be nested within the first. Resource management is greatly simplified by proper nesting since the resources required by the nested transaction can be allocated dynamically from the triggering transaction [Agha 1987b].
In actor systems, message passing difficulties can arise under cases involving transactions. For example let us consider a banking scenario where the savings account provides over draft protection for the cheque account and each account is represented by a different
May 1994 C Kyriakides Page 154 Existing Models Objed-Oriented Parallel Paradigms
actor. When the cheque account needs to process a transaction resulting in an overdraft or increasing an existing overdraft balance then both the accounts need to reply to each other before a new balance can be established. Under normal conditions incoming mes sages must be buffered until a replacement actor is specified; however, under this scenario it would not be permissible for communication to be buffered before the replacement was determined.
Actor systems overcome this transaction dilemma by means of insensitive actors and become communication; become communications inform actors of their replacement beha viour, and insensitive actors are catered to process such communication. Insensitive actors buffer all messages until they receive a message telling them what to become. (It is beyond the scope of this research to delve deeper into this matter, should readers require further details please see Agha [1986] and Tomlinson [1989].)
7.6.1.10 RACE actors
Another interesting concept of actors is represented by RACE actors. A race actor initiates a kind of race between parallel processes to compute its arguments and retums a list of the results in the order they where completed. The benefit of race actors lies in the fact that the result of each sub-problem can be made available as soon as it is computed. Needless to say race actors are limited to solving problems by algorithms whereby the problem can be fragmented into smaller independent subproblems.
For example, problems suited to OR parallelism can be fragmented into independent sub-problems. Furthermore, more general purpose algorithms amenable to parallelism can also benefit by partially fragmenting a problem into numerous smaller sub-problems at various stages of the algorithm - where each stage takes us one step closer to the solution (e.g., in algorithms suited to concurrent ordering of lists).
In concurrent algorithms, a race actor can return a list of results, that a merge function can implement to return the resulting lists of two or more RACE actors into a single list. This can be repeated until the desired solution is found.
May 1994 C Kyriakides Page 155 Existing Models Objed-Oriented Parallel Paradigms
7.6.1.11 Receptionists
A receptionist is the only type of actor that is able to receive communications from outside the system.
7.6.2 ABeLl!
ABeLll [Yonezawa 1986; Shibayama 1987) was developed by researchers at the Tokyo Institute of Technology; (ABCL/l is the successor of ABCL). One of the primary purposes in developing ABCL/l was to provide a tool for modeling real-world problem solving. ABCL/l is an actor based language that supports a waiting mode. Like Actl, Act2 and Act3, ABCL/l is characterised by script and delegation facilities; however, in addition to these features ABCL/l has built-in now and future type message passing; these modes of message passing will be elaborated on in this section. An important restriction of ABCL is that no broadcasting of messages is allowed; in effect, message passing takes place from point-to-point (object-to object).The actor become facility is another noteworthy omission from the ABCL/l model; its significance lies in the fact that by using the become statement an actor could drastically alter its behaviour.
In ABCL/l objects communicate by passing messages. However, unlike other actor models, ABCL/l adopts a more implementation pragmatic view in the sense that it acknowledges that objects coexist with more traditional types of data - such as numbers and lists. Thus ABCL/l is not homogeneous. Another deviation is that common control constructs (e.g, if-then-else) are viewed as primitive concepts and do not represent instances of message passing amongst objects; thus common control constructs do not imply a transfer of control amongst objects.
As in the actor model, ABCL/l objects are serial; only one method of an object will be executed at a time.
Tomlinson [1989] points out that as a result of ABCL/l's lexical scoping encapsulation is violated; namely, objects created within the scripts of other objects can directly access the instance variables of their creators.
ABCL/l objects comprise of an object-name, state, future, script, and private parts.
May 1994 C Kyriakides Page 156 Existing Models Objed-Oriented Parallel Paradigms
7.6.2.1 Message Passing
In ABCL/1 three types of message passing exist: past, now, and future message passing. Furthermore, message passing can be further categorised into two possible modes: ordi nary and express. To elaborate, ABCL uses the following message passing taxonomy:
Ordinary Mode Message Passing: A message arriving while an actor is not busy is put through; a message arriving while an actor is busy, is put on hold in a queue and when the actor becomes available the messages are put through on a first-come, first-serve basis.
Express Mode Message Passing: An express mode message allows an actor processing an ordinary mode message to be interrupted.
Past Type Message Passing: When a message is sent, the sender does not wait for acknowledgement that the message was received at its indented destination. It is called "past" because the sending process ceases before the messages accomplishes its goal of reaching the receiver. This type of message passing corresponds to what is generally referred to as asynchronous communication.
Now Type Message Passing: When a message is sent, the sender waits for an acknowledgement that the message has been received and also waits to receive the answer to the information requested.
Future Type Message Passing: A request is made for a message to be sent to a specific location in at some time in the future. Although it is not needed immediately, the expectation is that when it is eventually needed, the message will be available at the location requested.
It should be noted that a process invoked as a direct result of a message send by means of ordinary message passing can be temporarily paused so as to process an express mes sage first. However, processing as a result of an express message cannot be interrupted. In ABeL, no mechanism exists for interrupting activities resulting from express mode messages; that is, another express mode message cannot interrupt an activity that has been initiated by an express mode message. This type of control can to a certain degree simplify matters by preventing the code from becoming too complicated and hard to follow.
May 1994 C KyriaJddes Page 157 Existing Models Objed-Oriented Parallel Paradigms
Objects in ABCL/1 are always in one of three possible modes: active, dormant or waiting. When an object is created it is initially dormant. As in other actor systems, the behaviour of an ABCL/1 object is specified by its script. An object accepts a message only if it conforms to the patterns and constraints specified in its script; all non-conforming mes sages are either discarded or replied to by a default response. What should be noted here is that receiving a message does not necessarily imply acceptance to process the message.
A dormant object becomes active when it accepts a message. Under the ordinary mode of message passing, an object will remain active while it is busy processing the sequence of actions that need to be followed in response to the accepted message. Messages arriving while the object is active will be placed in a queue. When the object completes the sequence of actions made in response to an accepted message, it becomes dormant only if its message queue is empty. However, if the queue is not empty then the next message in the queue is inspected to determine whether it should be accepted and processed, or discarded. This is one-message-at-a-time approach is repeated until the message queue becomes empty, whereupon the object becomes dormant.
Concurrent processes occasionally require to synchronise their activities; thus while pro cessing an active object may require to stop its current activity and wait for a message with specified patterns to arrive. The message queue is searched to determine if the required message has arrived before processing can resume. In the case where no message con forms to the required pattern the active object changes into a waiting mode until such time that an appropriate message is received.
In ABCL/1 both the name of the sender and the destination for the reply are stated in the message; should the reply-destination not be explicitly stated in a message, then it is implicit accepted that the sender is also the reply destination. Yonezawa [1987] points out that, since the name of the sender and the reply destination are provided by the message, now and future message types can be reduced to past message types. Furthermore the capability to delegate is also accredited to the fact that the reply destination is included in the message.
ABCL/1 has a simple and convenient notation for designating the type of message passing:
< = designates message sending
=> designates that a message is to be received
May 1994 C Kyriakides Page 158 Existing Models Objed"()riented ParaDel Paradigms
In ABCL messages adopt the format: [receiver < = message] or [receiver < = message @ reply-destination]. If the reply-destination is omitted then it is implicitly assumed that the sender is also the receiver.
In addition to past, now, and future type message passing, messages can be categorised into ordinary and express modes.
Ordinary Express
Past [receiver < = message] [receiver < < = message]
Now [receiver < = = message] [receiver < < == message]
Future [receiver < = message $ future-id] [receiver < < = message s future-id]
where the x variable in future mode messages represents a future variable to which the responses to this message will be sent; its "value" will be obtained by sending it messages. Tomlinson [1989] classifies ABCL/l's future type message passing as future rpc.
Objects in ABCL are always in one of three possible states: dormant, active, or waiting. Thus when objects are defmed in ABCL, first the state and then the script are designated. Scripts contain the instructions for message passing, creating new objects, accessing vari ables, calculating values, and creating and manipulating data structures. Special Objects exist that create instances of a particular object type. Although these special objects are not classes, in some regards their behaviour is analogous to that of a class; namely, when they receive a message new they create an object instance.
Generally, ABCL/1 objects are defmed as follows:
[object object-name (state state-variable-declarations) (future future-variable-declarationsy (script ( = > message-pattern where constraint ...action...)
( = > message-pattem where constraint ...action...)) (private
May 1994 C Kyriakides Page 159 Existing Models Objed-Oriented ParaDel Paradigms
[(routine-name argument...argument) =(routine routine-description)]
[(routine-name argument...argument) = (routine routine-description)])]
In brief, the state part specifies local instance variables; the future part specifies instance variables to be used under future-type message passing; the script ofan Object specifies its behaviour; in terms of what messages an object may receive and under what conditions; while, the private part specifies local functions - these are not accessible from other objects.
Messages sent to an object that do not match the message pattern or fulfill the constraints specified by any of the script expressions are discarded.
The instructions within the script of an object are by default assumed to occur sequentially; nonetheless, Tello [1989] states that parallel operations can be implemented by specific instructions. At first this appears to contradict our earlier statement regarding ABCL objects being serial; however, no contradiction exists. To clarify, an object can send several messages in parallel through the use of a special construct, appearing as follows:
{message-sending-expr.1...message-sending-expm]
This parallelconstruct initiates all of the message sending expressions at once and does not terminate until all have terminated.
7.6.2.2 Project Teams and Project Leaders
As was mentioned above, ABCL attempts to model real-world problems. Below we briefly present one such example that the developers presented to demonstrate ABCL's problem-solving capability using a team and a project leader. Furthermore, algorithms applicable to ABCL have also been created for implementing pipelining in divide-and conquer type strategies.
A primary manager (called the projectmanager) assigns a task together with a deadline for completion of that task, and also chooses a leader for the project team to which the task is assigned. This project leader is in turn responsible for coordinating the different team members and organising the timing efforts required to meet the deadline. The project manageris responsible for creating a timekeeper or scheduler that is responsible for "waking
May 1994 C Kyriakides Page 160 Existing Models Objed-Oriented Parallel Paradigms
up" various members of the problem solving team at certain times. When the project leader receives a "start solving" message from the manager, the timekeeper is spawned and provided with the information of whom to wake up at what times.
Problem-solvers implement a future type message passing mechanism that is reminiscent of the RACE construct of actors. As soon as a problem-solver has an answer available, it is stored in a future variable called Solutions. When more than one solver finds a solution, these solutions are stored as a list with the identifier Solutions in the order in which they are received. Solver objects maintain information on their state of progress in a state variable. Solvers as well as timekeepers can receive messages in the express mode. For example, a stop message received by an object will cause that object to uncreate itself.
7.6.3 Act!, Act2 and Act3
ACT] [Lieberman 1987], ACT2 [Theriault 1983] and ACT3 [Agha 1986; Agha 1987a; Agha 1987b] represent successive actor based language developments. Below we briefly present a small number of their fundamental issues relevant to our research.
Knowledge must be distributed among the members of the society, not centralised in a global state. Each member of the society should have only the knowledge appropriate to his (or her) own functioning. Each actor has only the knowledge and expertise required for him to respond to messages from other actors. There is no notion ofglobal state in an actor system.
Each member should be able to communicate with other members of the society. All commu nication and interaction between actors take place by means of message passing. No actor can be operated upon, looked at, taken apart or modified except by sending a request to the actor to perform the operation himself.
Members of a society must be able to perfonn tasks in parallel. Based on the object-oriented philosophy, message passing is used to provide mechanisms for exploiting parallelism.
Different groups of a society must be able to share common knowledge and resources, to avoid duplicating common resources in every individual that needs them.
Act1 uses a technique of delegating messages, which allows concentrating shared knowledge in actors with very general behaviour, and creating extensions of these actors with idiosyncratic
May 1994 C Kyrialddes Page 161 Existing Models Objed-Oriented ParaDel Paradigms
behaviour more suited to specific situations. (For further information on Act1, Act2, and Act3, readers are referred to more detailed works such as [Lieberman 1987), [Theriault 1983J, [Agha 1986], [Agha 1987a], and [Agha 1987bJ.)
7.6.4 Conclusion: Actor Based Languages
From a distributed processing perspective, Actors propose restricting the general Object Oriented model so as to ease implementation on distributed architectures. The primary restriction imposed involves limiting the actor model to be Object-based; in other words, classes and class-based inheritance are not allowed. (As was mentioned, class and class inheritance are reusability mechanisms). Instead, the reusability of inherited methods is simu lated by means of delegation. Delegation allows several actors to "share" processing access to a method; even though, this method resides in (and is controlled by) another actor.
Furthermore, since there are no classes there is no shared repository of behaviour. Thus, the need to facilitate code duplication by means of class inheritance is eliminated. (This is in direct contrast to other alternative Object technology models where either: inherited code is copied into each implementation of the immediate classes of actual instances, or; inherited code exists only as a single copy within an object instance representing the class object). Actors provide a single copy of a method. All other actors requiring access to the method may delegate the message to the actor that owns the method.
It was mentioned earlier on that delegation can be likened to a form of "classless inheritance". Here we will make a more concise statement, namely that both (class-based) inheritance and delegation are simply different forms of reusability. One form of class inheritance, as in Smalltalk, enables objects requiring the services of an inherited method to search up the class hierarchy for the applicable superclass method. Recall that Smalltalk classes exist as meta-class objects (i.e. classes exist as object instances). Hence, the superclass from which a method was inherited will undertake processing (pertaining to the inherited method) on behalf of a sub class object. Delegation on the other hand attempts to provide the benefits of the Smalltalk type class inheritance while avoiding the hierarchical properties thereof. In actor systems, the actor referred to as the proxy undertakes processing on behalf of another actor. The role of the proxy is analogous to that of the superclass mentioned above. (On a finer point, Tomlinson
May 1994 C Kyriakides Page 162 Existing Models Objed-Oriented Parallel Paradigms
[1989] states that in delegation the request is executed by a method in the context of the proxy and not in the context of the client; while, in inheritance the request is executed in the context of the client, not the proxy).
ABeLll messages may contain both the name ofthe recipient ofa message as wellas the actor that the resulting answer is to be returned to. This caters for greater flexibility and can result in improved communication efficiency. For example, assume a message is to be send from actor A to actor B and the result needs to be send to actor C. Instead of actor B returning the result to actor A that initiated the message and actor A relaying the result to actor C, the result can be send directly from actor B to actor C. Hence, the shortest communication path between actor B and actor C should be used which will be either shorter or equal to the path from B to A to C. We raise one point of caution here, namely, "if the result needs to be evaluated for acceptance then how will this be handled?". Clearly the actor sending the message is aware of the message signature (including which results are acceptable); unfortunately the actor receiving the result may not have this information. How this issue can be addressed will become self-evident under our discussion of Managers; we thus leave this issue to later chapters.
The actor model allows message send to a busy actor to be placed in a queue. Unfortunately, the messages are placed in a queue regardless of whether or not the message is acceptable to the actor. The message is only checked for acceptance the moment it is to be removed from the queue for processing. Tello [1989] contests the notion of placing messages in a queue prior to determining their acceptability; Tello proposes that checkers should determine message acceptance prior to placing messages in a queue. The dilemma imposed on Tello's approach with regards to the actor model is that an actor's behaviour is dynamic and may change from message to message, (although this can be overcome it may significantly complicate matters). Nonetheless, an issue that is more relevant to our research arises from this; namely, Tello supports the notion that certain responsibilities with regards to the transmission of messages could be done by objects other than the sender and recipient of a message. In essence, this notion can be expanded into a multi-tier model whereby objects at different levels provide a distinct range of responsibilities at each tier. Later on we will propose such a multi-tier model under Managers.
May 1994 C Kyriakides Page 163 Existing Models Object-Qriented Parallel Paradigms
Guardians enable actors to implement the notion of continuations. This allows actors waiting for a reply to a message to save their processing environment and, in the meantime, continue to process other incoming messages. In essence, guardians enable actor systems to make most of the existing actors. Furthermore, Race Actors allow concurrent processing of fragmentable problems.
Receptionists are actors representing the only interface points that an actor environment avails to other external systems. By establishing well-defined narrow interfaces to other systems, receptionists facilitate the presentation of a conceptually simple model; this is preferable to models where any object may have interactions with entities outside that particular model.
ABCL's express mode messages can greatly ease development of applications requiring the ability to interrupt an active process. Unfortunately, an express mode message cannot be interrupted. Thus it would be more flexible to cater for multiple levels of message priorities; where an incoming message can interrupt processing of any messages with a lower priority. (Unfortunately, this increase in flexibility will have to be weighted out against the accompa nying increase in complexity).
In ABCL, Project Leaders can be given the responsibility of undertaking a project; this project may entail solving a fragment of the problem. While, timekeepers or schedulers allow additional monitoring and control of processes. Namely, schedulers provide greater control of activating processes by providing a time/event scheduled activation of processes.
Under the oopp model, managers are able to facilitate any of the roles played by checkers, guardians, race actors, receptionists, timekeepers, schedulers and many more; this will be discussed later on in greater detail. For example, a process may be given a limited time in which to return a reply to a particular message; should a reply not be returned within the allowable time, then the timekeeper may assume the process to be deadlocked or undergoing an infmite loop; the timekeeper can then force a best-so-far reply, a default reply, or even activate an error recovery process (or even attempt to reprocess the message).
In actors there is no explicit construct for receiving a message. This implies that no synchro nisation can be done within an actor and furthermore, that an actor's processes are indepen dent of messages arriving while the actor is busy processing a message. However, in ABeL, a process can temporarily stop its current activity and wait for a message with specified patterns to arrive. Thus, in ABCL synchronisation can take place within an object. From an analytical
May 1994 C Kyriakides Page 164 Existing Models Object-Oriented Parallel Paradigms
perspective, messages processed by an actor can be analysed one at a time; while, messages processed by an ABCL object exhibiting synchronisation should be analysed in their particular order of occurrence.
7.7 Object-Oriented Databases (OODB)
In this section we will briefly mention a number of OODBs including GemStone, Vbase, Ontos, Versant, Iris, PCLOS and ORION. A number of general Object-Oriented issues discussed pre viously are readdressed within the context of OODBs. Furthermore, a number of noteworthy issues specifically dealing with OODBs are also addressed - these include locking mechanisms, persistent objects and schema evolution. Also an apparent developers' preference of the relatively familiar Object SQL over other proposals is also mentioned.
Object-oriented Databases (OODB) cater for the storage, retrieval and manipulation of objects. The schema of an OODB is represented by a collection of type definitions, In other words, schema information is meta-data; data about data [Graham 1991]. As in other object-oriented environments, inheritance in OODBs is a mechanism for passing on the properties (attributes and methods) of a general type to a more specific type. The inheriting type is referred to as the subtype, while the type it inherits from is called the supenype. The root of such a hierarchy rep resents the most general type while the leaves represent the more specific types. Multiple inheri tance allows a type to inherit properties from more than one supertype. Systems not supporting multiple inheritance depict a hierarchy; while multiple inheritance systems depict a network. As is usually the case with multiple inheritance, problems can arise in terms of name conflicts of inherited properties, (like other Object-Oriented disciplines mentioned previously, OODBs adopt a number of different approaches to handling name conflicts of inherited properties).
Also previously mentioned, the Committee for Advanced DBMS Function (CADF) is concerned with formulating a standard for Object SQL. In particular, CADPs advanced database manifesto [Stonebraker 1990] was briefly presented in which a number of principles that advanced DBMSs (including OODBs) should comply to were stated.
Commercial OODB products have being developed in fields where complex objects exist, such as, CASE Tools and CAD/CAM systems. As mentioned above, in the remainder of this section we will briefly discuss a small number of OODBs.
May 1994 C Kyriakides Page 165 Existing Models Objed-Oriented Parallel Paradigms
GemStone [Maier 1987; Bret11989] is one of the earliest and possibly purest, commercial OODB products. GemStone was built on top of OPAL, an extension of Smalltalk. OPAL [Servio 1989] can deal with persistent objects. Gemstone is not linked to any particular language; even though the Data Manipulation Language (DML) is OPAL, Gemstone can be accessed from other languages such as Smalltalk or C++. OPAL's class library covers only a few basic but elaborate data structures and supports all of the primary object-oriented features such as abstraction, inheritance and identity. Owing to its Smalltalk heritage, OPAL is by default a typeless language. Unfortu nately, unlike most common database languages, in OPAL even primitive operations such as insert, delete and update, must be declared explicitly for each class defined. Multiple inheritance is not supported. Like all systems based on Smalltalk, the gaibage collection and late bindingfea tures prove troublesome where performance issues are concerned. The GemStone access language forms queries and indexes over object attributes; unfortunately, this can be used to violate encapsulation.
Vbase was one of the first proper object-oriented databases to emerge within a C/Unix environ ment. Vbase was strongly influenced by Clu [Liskov 1981], and emphasised strongly typed abstract data types. As much binding as possible was done at compile time. Vbase had its own proprietary type definition language (TDL) and for access used a proprietary object-oriented extension of C called C Object Processor (COP). The significant OODB issues raised by Vbase came not by Vbase's development but rather by its withdrawal; Vbase was replaced by Ontos. The world of commercial databases is dominated by SOL which is rather well established and understood; thus, TDL did not attract sufficient interest from the commercial database developers. The fact that COP is a proprietary extension to C and there is a large number of existing object-oriented extensions to C, made COP to be an unviable proposition. Furthermore, in all systems supporting inheritance, a locking mechanism is usually employed in order to allow for controlled modification of classes. The locking mechanism occurring in Vbase locks all the objects inheriting from the object which is about to be modified. Thus when an object near the top of the inheritance hierarchy needs to be modified a large number of objects need to be locked; if the topmost object needs to be modified the whole system must be locked. Unfortunately, as can be deduced from the previous statement, locking mechanisms can give rise to severe petformance problems.
Ontos, the replacement product for Vbase, not only replaced TDL with Object SQL (an extension of SOL), but also replaced COP with C+ +. ObjectSQL enhances standardSQL by the addition of object query syntax. The locking problem is addressed by allowing the designer to choose the appropriate strategy for the particular development. Ontos enhances .C+ + with persistent objects;
May 1994 C Kyriakides Page 166 Existing Models Objed-Oriented Parallel Paradigms
the extended environment can move objects or groups of objects between store and memory. Class libraries and exception handling mechanisms are also provided. Taking databases one step closer to CASE tools, Ontos supports object version histories.
Versant is an object-oriented database product that uses C+ + as the access language; in fact, C+ + is used for practically all purposes. Both Ontos and Versant are intimately linked to C+ +. The philosophy behind Versant's approach lies in keeping things simple by using one language (or platform) for everything and thereby avoiding the complexities introduced by an Object SOL.
Iris [Fishman 1987, 1989] was developed as an experimental system offering an Object SQL. The Iris data model is based on the functional model rather than on a strictly object-oriented model. Iris is very relational in style and depicts strong Prolog influences. (The underlying storage manager is similar to system R, the precursor to DB2). Multiple inheritance is supported. The type of an object can change at run time; although a powerful facility, this can also prove to be a dangerous option to use. Versioning is also supported. Access from Object SQL, Objective-C and LISP is supported. In contrast to other OODBs, Iris supports multimedia databases via specialised data managers; in general, other systems store all sorts of objects in a single type system.
PCWS (Persistent CWS) attempts to provide a tightly coupled interface between an object-oriented database (Iris) and an object-oriented programming language (CLOS).
Although a large number of OODBs exist, the last database to be mentioned here is ORION. ORION [Kim 1989b] is an Object-Oriented Database primarily inspired by Smalltalk. The ORION research had concentrated on schema evolution and has produced some very profound ideas on the subject. As the schema of an object-oriented database is dynamic, descriptive semantics and a set of rules were produced that when followed allowed a type network to remain consistent while attributes and methods were added to or removed from a class. (For further details on schema evolution see Banerjee [1987b].) Important ideas were also presented on locking. Furthermore, the ORION research demonstrated that classification (AKO, A Kind On and composition (APO, A Part Of) structures are often closely coupled, and developed semantics for this coupling.
Controlled schema evolution needs to take into account the following:
Changes to the description of an object (class): adding, deleting or updating attributes of a class; adding, deleting or updating methods of a class; and, changing the inheritance (parent) of an attribute or method.
May 1994 C Kyriakides Page 167 Existing Models ObjectoOriented ParaDe. Paradigms
Changes to the inheritance topology of a system: adding or deleting superclass-subclass relationships.
Changes to classes: adding a new class, deleting an existing class, and renaming a class.
Inheritance greatly complicates schema evolution. If a Class is modified, then all Subclasses or Instances ofthat Class have to be checked for dependencies. For example, if an attribute or method of a class is modified or deleted and that attribute or method is inherited by a subclass, then that change must be checked for consistency in all the dependent subclasses. A similar complication arises from composition structures (for further details see Kim [1989b]). Furthermore, in order to effect controlled schema evolution, it is important to note that object identity is and must be preserved during all schema changes. Thus, similarly to version development, schema changes should be effected reasonably gradually; most databases (e.g, ENCORE [Zdonik 1985; Skarra 1986]) cater for one form or another of version control at instance, class and schema levels.
Unlike Smalltalk, ORION supports multiple inheritance. Also attributes may have defaults at the class level. Three built-in options exist for handling conflict resolution:
"left first" rule: from the list of superclasses, the conflicting method or attribute is inherited from the first superclass in which it occurs;
The user may specify the choice which the object should make;
The user may specify that the object may inherit both properties and rename one of them.
7.7.1 Conclusion: Object-Oriented Databases
In addition to more general benefits associated with databases, OODBs accommodate sharing, distribution, security and versioning. Similarly, a number of benefits of object-oriented databases are analogous to that of object-oriented programming; these include reusability, increased modularity and extensibility.
Furthermore, OODBs assist in narrowing the gap between real-world objects and concepts and their representation in the database. The expressive capability of an OODB exceeds that of the entity-relationship model and also surpasses the semantic capabilities of both the hierarchical and network model. (Even though the efficiency of hierarchical systems is approached, garbage collection and dynamic binding of methods can severely compromise the potential for efficient access. Although no generally acceptable standard exists for "rules" - active objects - in OODBs, the potential to support "rules" exists).
May 1994 C Kyriakides Page 168 Existing Models Objed'()riented Parallel Paradigms
In an object-oriented programming environment, OODBs minimise the need for paging of objects in and out of memory. Thus, OODBs provide better performance than conventional databases when complex objects and/or relationships need to be dealt with. This improved performance characteristic is attributed to the fact that unlike conventional databases, OODBs do not need to fragment large objects for storage into normalised tables and reassemble them at TUn time via slow join operations; also in this scenario the disk space requirement may be far less when compared to relational systems that need to store many more index files. In devel opment of relational systems, physical clustering of objects poses a problem for designers; in order to minimise disk access, tables that are frequently joined should reside on the same device or close to each other in storage. Unfortunately, in relational systems the only guideline for clusteringrelies on an empirical study ofcommon queries. In contrast to this, Object-Oriented systems adopt a more logical guideline for clusteringbased on class and aggregation hierarchies. Objects forming groups are stored together as composite objects. Furthermore, in well designed systems, the classification structures can be used as a natural basis for clustering. This serves not only as an implementation convenience, but also since clustering reflects the semantics of an application, it is quite likely that common queries will refer to nearby physical locations on disk.
OODBs incorporate built-in referential integrity and generally richer semantics. Object identity solves the problem of dangling tuples since, by addressing the object directly, it altogether avoids the need for referential integrity checks. Richer semantics are primarily attributed to the ability to construct types and encapsulate constraints within objects at any level in the type network, including the ability to override defaults and exception constraints.
From a conceptual point of view, locking is easier to interpret within the object-oriented model. The object serves as a natural medium for locking with a single lock being placed on the object (i.e. on all relevant data). The locking of a single object is more preferable than in relational databases where multiple locks are made scattered among unrelated tables. Unfor tunately, from a practical point of view, locking of objects near the top of a hierarchical system can result in a large portion of the system to be simultaneously locked and thereby severely restrict the systems performance.
In commercial applications, the ability of OODB systems to capture application semantics explicitly takes developers one step closer to reverse engineering and prototyping. Reverse
May 1994 C Kyrialddes Page 169 Existing Models Object"()riented ParaDel Paradigms
engineering is envisaged to enable u'e recovery ofthe semantics captured within objectsso as to facilitate the generation of new code that is independent of the physical architecture or module structure of the original system.
Even though there exists a nUll1beJ' of advantages over RDBMSs (Relational DBMSs), unsolved problems persist concerning non-procedural enquiry languages, query optimisation and locking. Currently, selecting a stPtable OODB for a particular application relies primarily on the individual features and/or environments supported by specific products. For example, if it is desired to develop a database Ottension of a GUI application coded in C+ +, Ontos is one of the natural choices; while 1llultinledia expert database applications may prefer G-base, and so forth.
It is clear that the principles depicted in the CADFs advanced database manifesto [Stone braker 1990] (including inheritance, COntrolled schema evolution, persistent objects, security and support for transactions and distributed processing) should be mandatory for large-scale commercial applications.
Although a number of proposals have being made (Ullman 1988; Beech 1987; Lecluse 1988; Manola 1986], there isno universally accepted formal object-oriented data model or standards. The efforts of groups such as cADF (committee for Advanced DBMS Function), OMG (Object Management Group) and ,4!IfSI are expected to resolve this problem in the near future. Object SOL and OODB specifications can greatly benefit by the development of a widely-accepted industry standard Such an industry standard should theoretically present a well defined interface and semamlcs to other applications that may require to access the OODB. Nonetheless, although Object-Oriented Database technology is currently rather immature, it is a rapidly maturing field and at its time of maturity is expected to be of great significance to information technology in general. From the above it is clear that Object Oriented Databases (OODBs) will develop a niche of dominancy in a subset of database applications. ODDBs are more well-suited in handling complex objects than relational databases. For this reason, (ignOring any other factors), applications dealing with complex objects are more likely to be developed ernbracing an OODB rather than a relational data base.
May 1994 Page 170 Existing Models Objed-Oriented ParaDel Paradigms
7.8 Other Models
7.8.1 POOL-T
POOLjT is a concurrent object language developed by the ESPRIT advanced computing proj ect. POOL/T was aimed at providing a tool suitable for large systems development in a top-down manner instead of an explorative way. It is aimed for implementation in a hardware environment of up to 1000 processors. Inheritance was attempted in earlier versions of POOLjT but since it was plagued with problems, inheritance was left out from later versions. Unlike interactive systems (based primarily on LISP, PROLOG, and Smalltalk), POOL/T is more in the tradition of structured programming systems like Pascal, C and Ada.
POOL/T classes are not modeled as objects. This is attributed to the fact that the behaviour of classes and objects is very different; classes are static, while objects are dynamic.
Programs in POOL-Tare organised into units, which are collections of class definitions. A class definition defines the local state of its instances and the methods that are available for execution on instances of the class. Unlike Smalltalk, there is no inheritance of methods or instance variable specification among classes. Furthermore, classes are not objects; rather they are compile-time entities. POOL-T exhibits strong typing and support for static error detec tion. In particular, POOL-T requires that all instance variables and method parameters be given a type corresponding to the class of object instances that are permitted to be bound to them.
In addition to their local state and accessible methods, Objects in POOL-T have a body that is active on its own without the need for a message reception to activate it.
So as to give programmers greater control over program execution, POOL/T implements a form of synchronous message passing referred to as the nonblocking remote procedure call style (Tomlinson 1989}. An Object must indicate that it is ready to accept a message by using an answer statement that includes a list of the methods that the object is willing to accept for activation at that point in its execution. The answer statement blocks the object execution until some other object perfonns a send of a message requesting activation of one ofthe methods that is accepted.
May 1994 C Kyriakides Page 171 Existing Models Objed-Oriented Parallel Paradigms
All object interaction in POOL-Tis accomplished via the send statement, which is notated as targetlmethod(arg 1,....arg n}. As with atomic objects in ConcurrentSmalltalk, methods defined in the class of the object may be invoked directly within the object as procedure calls. This is necessary since the use of synchronous message passing would lead to immediate deadlock if an object tried to send to itself in order to activate one of its own methods.
With respect to its approach to process interaction, POOL-T is similar to that ofAda and CSP [Hoare 1978, 1985]. POOL-T differs fromCSP in that objects (processes) may be created dynamically. POOL-T differs from Ada in that there is semantically a single queue of waiting requests rather than a queue per method. This latter distinction imparts a useful fairness distinction to the language - a waiting request cannot be indefinitely ignored.
7.8.1.1 Conclusion: POOL-T
POOL-Tis a concurrent class-based language (has both objects and classes, but has no inheritance mechanism). Furthermore, POOL-T makes a distinction between classes and objects; namely, Objects are dynamic in nature, while classes are static and are viewed as compile time entities. POOL-Tis strongly typed, and as a result thereof, provides ample support for static error detection. Synchronous message passing is implemented. Since POOL-T uses a nonblocking remote procedure call style, a send message can only be accepted by an appropriate answer statement. Unlike many other systems, POOL-T implements a single queue of waiting processes; thereby it assures that a waiting message cannot be infmitely ignored.
7.8.2 MACE
MACE is an acronym for Multi-Agent Computing Environment. As the name implies, the nodes of a MACE system are called Agents. Description attributes and instance attributes of MACE can be likened to classes and instances of conventional object systems. Like actors, MACE agents have a number of acquaintances with whom they can communicate and are thus aware of their mailing addresses; unlike actors, MACE agents also have knowledge of their acquaintances' capabilities. Every agent views its acquaintances in terms of their name, class, address, role, skills, goals, and plans; also every agent has a model of itself.
May 1994 C Kyriakides Page 172 Existing Models Objed'()riented ParaDel Paradigms
Furthermore, agents can be organised into coalitions or clusters that respond as a coordinated group to particular problems. The basic user environment is implemented by means of various built-in system agents. System agents may provide the basic user interface while others may be provided forming agent clusters that serve as system tools. There is even an agent-builder cluster that assists to build the structures and behaviours of other agents. Agents may gain knowledge of other agents in one of two ways: by having that knowledge build-in at the time of creation; or by requesting the Directory Agent to supply the addresses of other agents on request. Queries are then directed to those agents themselves to build up models of them.
MACE agents are sensitive to theirenvironment; this environment may entail the MACE system itself, other agents present, as well as, the world outside the MACE system. One way in which agents are sensitive to their environment entails receiving and interpreting messages. Another way involves an understanding of the internal construction of a MACE agent.
Unlike conventional object-oriented systems, MACE has no inheritance mechanism. One approach attempted by means of MACE was to implement a distributed rule-based production system; however unlike conventional inference engines, each rule acts as an agent that can communicate with other agents by sending messages to them. Analogous to futures used in actor languages, computation identifiers are implemented thereby linking such identifiers to partial result frames in the original agent. Enough information may be provided by one or more partial results to allow the computation to continue before all the partial results have been received.
7.8.2.1 Conclusion: MACE
MACE (Multi-Agent Computing Environment) comprises of nodes called agents and has no inheritance mechanism. However, in comparison to other models presented thus far, MACE presents a substantially different methodology. Although agents exhibit some analogies with regards to actors (such as acquaintances), unlike actors, agents are able to store knowledge about their acquaintances. Furthermore, agents can also be organised into coalitions or clusters that respond as a coordinated group to particular problems. Also agents are sensitive to their environment.
May 1994 C Kyrialddes Page 173 Existing Models Objed"()riented Parallel Pal'lldigms
7.8.3 Orient84/K
Orient84/K is a hybrid language which combinesSmalltalk and Prolog styles [Ishikawa 1987]. Orient84/K [Ishikawa 1986; Ishikawa 1987] has been designed as a tool for developing large, concurrent, knowledge based systems, and as an experiment in integrating object-oriented, logic-oriented, and demon-oriented styles of programming. An Orient84jK system consists of many concurrently executing objects, called knowledge objects, each of which comprises three parts: a behaviour part, which is similar to ConcurrentSmalltalk; a knowledge part, which is quite similar to Prolog; and a monitor part. Knowledge Objects are organised and classified according to the familiar metaclass/c1ass/instance inheritance hierarchy from Smalltalk-SO and augmented by a multiple inheritance scheme.
7.8.4 Emerald
Emerald [Black 1986a; Black 1986b; Jul 1987] is an object-based language aimed at program ming distributed sybsystems and applications. As a consequence of Emerald, work on confor mance rulesfor abstract data types was pioneered. In complex distributed applications, static type checking provides better detection and notification of errors; also, static type checking circumvents the need to explicitly handle run time type errors.
An Emerald object is in many respects similar.to an actor except that its behaviour is divided into two parts: operations that are accessible to other objects via message passing, and an optional process that executes in parallel with operation invocations. Furthermore, Emerald supports a number of object implementation styles. For example, immutable objects (objects whose state cannot be changed and thus remain constant) are supported. Emerald allows multiple copies of immutable objects. The concept of immutable objects can be beneficially used to encapsulate frequently accessed static information within an immutable object and replicating it over the network. Other object implementation styles include: global objects which may change location within a network and can be invoked remotely, and local objects which may be referenced only by means of an intermediary "enclosing" object.
The conformance rules developed in Emerald allow assignments and procedure invocations to be checked for legality at compile time. Ifwithin a specific context a particular type is expected
May 1994 C Kyriakides Page 174 Existing Models Object-Orlented Parallel Paradigms
then it is assumed that any valid operations on that type may be invoked later; the actual type is thus checked to establish if it can at least provide the operations of the expected type. Hence, the type checker must confirm that the actual type is a subtype of the expected type.
The conformance rules of Emerald are presented below. An abstract data type P is a subtype of an abstract data type Q if and only if:
Even though P may have more operations than Q, P must provide at least the operations ofQ·
For each operation in Q, the co"esponding. operation in P has the same number of arguments and results.
The abstract data types of the results of P's operations conform to the abstract data type of the results of Q's operations.
The abstract data types of the arguments of Q's operations must conform to the abstract data types of the arguments of P's operations (i.e. arguments must conform in the opposite direction).
The above rules ensure that an abstract data type P can be used in place of Q in any context.
7.8.4.1 Conclusion: Emerald
Emerald is a strongly typed Object language. For the purposes of our research, its primary point of relevance lies in Emerald's immutable objects and type conformance rules. Emerald's immutable objects present a trade-off between greater redundancy and reducing message passing costs of distributed applications. The conformance rules of Emerald cir cumvent the occurrence of type errors at run time. However, the rules are overly restric tive; even though the first rule demands that a subtype provides at least the operations of the target type, not all the operations will necessarily be invoked in a given context. A similar argument bolds for the last rule. Furthermore, conformance is essentially based entirely on the syntax of an abstract data type. Hence, abstract data types sharing common interfaces are assumed to exhibit common behaviour; this may not be a valid assumption under all possible circumstances. Nonetheless, the above rules provide a viable means of incorporating static type checking in a polymorphic language.
May 1994 C Kyriakides Page 175 Existing Models Objed.()riented ParalIel Paradigms
7.8.5 Eiffel
EifIel [Meyer 1988, 1990] is an Object-Oriented language which deliberately attempts to address the issues of correctness, robustness, portability and efficiency. Eiffel couples the expressive modellingpower ofclasses and inheritance (adopted in Smalltalk and pursued in the Lisp-based languages) with the strong type-declaration and type-checkingpower of abstract data type technology (adopted in Clu and pursued in Ada) [Blair 1991]. Like Ada, Eiffel can assume the role of a design language or program development language (PDL). In order to reduce the risk of errors when translating formal design notations into code, designs are accomplished as a set of high-level classes and the methods are filled in later. Similarly to Objective-C, Eiffel is an object-oriented language that is translated into C and thereby can achieve greater effi ciency and portability, (a library of classes is also available). Multiple inheritance is supported, however, garbage collection is optional.
In contrast to Smalltalk and Objective-C, Eiffel classes are not objects; the class describes the implementation of an abstract data type. This enables static type-checking to help eliminate run-time errors and improve efficiency. A class is defmed at compile time and can create instances of the type (Objects) at run time. All references in Eiffel have a type, and at any time a reference is either void or refers to an object of a compatible type. Each class may define a routine called Create to initialise its instances.
Each class has a number of features; Eiffel methods are called routines, while methods and attributes encapsulated by classes are collectively referred to as features. As in c+ + or Ada, features may be either private or public (exported). However, Eiffel allows a much more fmely grained specification of access. Eachfeoture (variable or function) can be given a list of classes that can access it. This list contains the clients whose contract includes the feature.
Assertions enable Eiffel to specify the formal properties which an Object's operations must obey. Assertions may be viewed as a formal contract between a server and its clients. Further more, assertions serve to facilitate the production ofproofs of conectness, and the introduction of exception handling features. Under exception handling, a violation may result in message failure or may invoke a 'rescue' procedure contained in the offending method. Assertions may cater for pre-conditions, post-conditions, or invariance conditions. Pre-c:onditions invoke a check whenever a method is called. Post-condltlons are guaranteed to be valid when the
May 1994 C Kyriakides Page 176 Existing Models Objed..()riented Parallel Paradigms
method terminates or returns values. While, invarlance conditions are always valid once an object is created or a method is called. As has been established in the Fresco project at Manchester University, this sort of feature can, with a little effort, be added to SmalltaIk.
Eiffel, like Ada, supports the notion of generic classes; namely, classes with parameters rep resenting types. Unlike Ada however, Eiffel fully supports inheritance. Secure modules may be created by specifying pre- and post-conditions. Even though multiple inheritance is supported, inheritance conflicts are not dealt with because attributes or methods inherited from two parents must be renamed in the descendant. As a general rule, note that (in most the languages dealt with so far) the values of attributes are not inherited, only the ability to have a value. By allowing type checking to authorise more specific Objects but not more general ones, Eiffel accommodates inclusion polymorpbism. Furthermore, the concept of deferred classes allows for overriding of inherited methods.
Eiffel has received some bad press as a system for commercial developments. Cook [1989] suggested that Eiffel was not type safe; in turn, this was contested as being attributable to the existence of compiler errors in earlier versions. As a direct result of poor performance and lack of supporting tools, a key redevelopment using Eiffel was abandoned by Cognos, a 4GL supplier. The most significant reason presented for the failure of the Cognos project lies in errors made in managing the unfamiliar technology [Leathers 1990]. Nonetheless, as was shown above, Eiffel appears to make some important extensions to the concepts of Object Oriented programming.
Even though Eiffel is a compiled language, unlike other compiled languages (such as Objective-C), EilTel provides no separate concept of a procedure; instead, the only construct which can be used is a class.
7.8.5.1 Conclusion: EifTel
Eiffel is a strongly typed object-oriented language that supports multiple inheritance. As is generally the case with strongly typed environments, amble support exists for static error detection. Furthermore, Eiffel classes are not viewed as objects; instead, classes represent abstract data types. When comparing Eiffel and POOL-T, both are strongly typed and also do not view classes as objects. One noteworthy aspect of Eiffel is inclusion polymorpbism,
May 1994 C Kyriakides Page In Existing Models Object.oriented Parallel Paradigms
(inclusion polymorphism allows type checking to authorise more specific objects but not more general ones). In fact, in accordance to Emerald's type conformance rules, inclusion polymorphism also exists within Emerald.
On a less prominent note, Eiffel illustrates that languages translating into C (such as Objective-C) do not necessarily have to be limited to single inheritance.
7.8.6 Hybrid
Hybrid [Nierstrasz 1987;Mercado 1987] is a strongly typed language using a remote procedure call (rpc) style of interaction and a concept of asynchronous delegation. Hybrid is aimed at combining the advantages of class based and prototype based systems in a single model that allows the user to select the desired mix: of characteristics for a given application. To elabo rate, Hybrid provides classes having templates whereby a minimal guarantee is effected; every instance is guaranteed to conform to the structure of its class's template. Nonetheless, new instances may be created by augmenting any existing instance with extra variables or meth ods. The new instance is connected to the existing instance by delegate links; thus since the instance is extended to share state and behaviour, the instance is behaving like a prototype. Should sufficient extensions be required, then the extended instances can be promoted to instances of a new class defmed with the new common structure; here, the instances now embrace the characteristics of class-based instances (i.e., no shared state) and delegate links become standard instance links.
7.8.6.1 Conclusion: Hybrid
Hybrid combines class based and prototype based systems into a single model. Even though Hybrid is a strongly typed language, it nonetheless allows instances to be extended by augmenting them with extra variables or methods. Clearly the prototyping stipulation has brought about the requirement of augmenting existing instances so as to develop prototype instances. Under such environments, since classes do not actually exist for pro totypical instances, a trade-off will inevitably be made between static error detection and dynamism.
May 1994 C Kyriakides Page 178 Existing Models Objed'()riented Parallel Paradigms
8 Managers
One of the primary concepts proposed by the OOPP research effort is embodied in the concept of managers. Like its anthropomorphic namesake, under the manager-employee scenario, a man ager exhibits control over its employees. In this chapter we describe: what is a manager, the role a manager plays in a proposed system, and how to determine when a manager is required.
It must be noted that in OOPP both managers and employees are objects. What should also be noted is that the responsibilities of managers differ from that of the employees they manage. Generally, responsibilities that do not form part of the analytical aspects of a problem will be identified as managerial responsibilities; while, responsibilities that fonn part of the analytical aspects of a problem will be identified as employee responsibilities. As a rule-of-thumb, in the absence of manager objects, employee objects should theoretically be capable of arriving at a solution to the problem. Managers embody the responsibilities pertaining to the implementation aspects of a problem.
Please note that we make use of the manager-employee anthropomorphic view to present an comparable relationship existing in the oOPP model. However, we do not take this anthropo morphic view to an extreme compliance of its real-world counterpart.
May 1994 C Kyrialddes Page 179 Managers Objed-Oriented Parallel Paradigms
8 Managers
A system that solves a given problem usually includes functionality that does not directly address the problem being solved. Such functionality is intended to support the functioning of the system itself for example, a system may require a user identification and password before allowing a user to use the system. Similarly, if the system is distributed, the system may include functionality to enable var ious nodes to communicate (even though the problem may not have anything to do with communi cation); the system may include functionality to utilise resources optimally (even though the problem does not require this explicitly), and so on.
OOPP's premise is that such functionality should (logically) be separated from functionality that derives directly from the problem being addressed.· This chapter describes the mechanism used by OOPP to separate such functionality from 'problem space' functionality.
Furthermore, we present a description of managers based on a responsibility-driven viewpoint. The manager-employee relationship is initially presented by defining the guidelines by which managers and employees interact. Special managers are thereafter introduced. (Special managers deviate from the manager-employee concept in that they provide a service. In essence special managers can be viewed as service providers. However, one justification for referring to them as Special Managers is that they manage one or more services which are in fact encapsulated within the special manager itself - thus giving rise to a form of self-management, albeit at service level). Thereafter we present two formats under which managers can exist - these are referred to as the Two-Tier and Direct-Inclusion approach. We also present a message management concept enabling Employee objects to communicate trans parently irrespective of their physical location and across any medium; as will be shown, this is made possible by making use of manager services.
Managers are specialised Objects existing under an Object-Oriented hierarchy. Objects allocated to a Manager are referred to as the Employees of that Manager. Also, Managers may have either Super Managers (that manage them), or Sub-Managers (that they manage), or both.
The primary purpose of a Manager is to provide the necessary "managerial" duties. The managerial duties may include amongst others: resource monitoring, resource allocation; providing optimum object-to-processor mapping; and providing autonomous operation within an allocated resource subset.
Managers are Objects. In fact, everything in OOPP is regarded to be an Object; and thus, OOPP is said to be homogeneous (see section 3.8). As will be shown (in section 8.7.1 and section 8.72), Managers can exist in one of two formats: Direct Inclusion and/or TwoTier,
May 1994 C Kyriakides Page 180 Managers Objed'()riented ParaDel Paradigms
8.1 Analytically Induced Responsibilities
In the following section we will show how to determine whether a responsibility should be placed in a Manager or in an Employee. In the meantime, in order to assist the discussion which follows we will assume that responsibilities can be identified as being either:
Analytic Induced Responsibilities (AIR)- having an influence on the conceptual model of the problem, Or nonAnalytic Induced Responsibilities (NAlR)- not having an influence on the conceptual model of the problem.
In the case of nonAnalytic Induced Responsibilities, the presence (or absence) of these responsi bilities does not influence nor benefit the conceptual model of the problem. Examples of NAIRs include:
Processor Workload Monitoring,
Relocation of Objects to idling processors,
Antivirus facilities,
Data compression, etc.
only where these do not form a mandatory part of the problem at hand!
Analytic Induced Responsibilities however are necessary in that they do influence the morphology of the conceptual model. A consequence of this fact is that AIRs must be anticipated to be problem specific. Thus extending the line of thought followed in our above mentioned examples, AIRs include:
Processor Workload Balancing and Object Relocation - only in problems where Processor Workload Balancing and Object Relocation are part of the conceptual problem (e.g. multi processor Operating Systems)
Antivirus related responsibilities - only in a problem where antivirus facilities are part of the conceptual problem.
Data Compression' only in problems where data compression forms part of the conceptual problem space (e.g. communication systems, storage systems, etc.)
May 1994 C Kyriakides Page 181 Managers Objed-Orientecl ParaDel Paradigms
Thus it should be noted that under certain problem spaces a responsibility may be an AIR, while under another problem space, the same responsibility may be a NAIR. For example, under anal ysis of a particular problem space we may determine that an earth-based laboratory system may need to communicate to a system in an earth-orbiting satellite. Under analysis we determine that communication between the two points is required; thus communication is an AIR. With regards to implementation aspects, we determine that communication may be enhanced by means of data compression; thus, in this case, data compression is a NAIR. This scenario may be refined even further by realising that the need to communicate is an AIR while the mechanism/mode of communication is an NAIR; the benefits of this will elaborated on in the section which follows.
8.2 Managerial Responsibilities
The implicit message of this section is "How does one decide which functions are management functions (versus problem space functions)?"
In order to determine which responsibilities are suitable candidates for Managers we propose the following guideline:
Managers and managerial responsibilities should not alter, affect, contribute to, nor eradicate from the analytical aspects of a problem. Thus managerial responsibilities are NAIR's.
Thus, responsibilities pertaining to performance, fault-tolerance, etc. should be considered as managerial responsibilities (except in the case where these responsibilities form a mandatory part of the problem space). At a later stage we will elaborate on this issue.
Managers allow the NAIR responsibilities to be encapsulated from the AIR responsibilities. This fact can give rise to an advantage that may be exploited during the maintenance life-time of a system; namely, a more efficient version of a particular NAIR responsibility may become available at a later stage. If the external interface of the manager object was well-designed, then only the manager object needs to be internally modified so as to make use of the new version. To elabo rate, in such a case, the AIR responsibilities do not need to be altered since the performance aspect of a system may be enhanced by modifying the NAIR responsibilities (encapsulated within a manager). This reduces the possibility of introducing a "performance-enhancing" maintenance error to the analytical aspect of the problem.
May 1994 C Kyriakides Page 182 Managers Objed'()rlented Parallel Paradigms
Continuing from the example given in the previous section, under analysis it was determined that the earth-based laboratory network needed to communicate with the orbiting satellite. Although the need to communicate falls under AIRs, the mode of communication falls under NAIRs. Since the NAIR responsibilities can in essence encapsulated within the managers, the original mode of communication (e.g., microwave communication with no data compression and no security) can easily be replaced by a more improved mode (say laser beam communication with data com pression and security) without affecting the rest of the system.
In the following subsections we present examples of typical management functions.
8.2.1 Object-to-Processor Management
Generally, in the majority of existing Object systems Object-to-Processor Mapping Algorithms have to a large extent being overlooked. The primary aim of any Object-to-Processor Mapping Algorithm is to achieve an optimum or near-optimum mapping of Objects to available pro cessors so as to effect a minimum overall interprocessor communication cost. The simplistic idea behind such a mapping algorithm lies in identifying which Objects need to communicate with each other and the percentage/probability of such a communication. The Objects then have to be placed in processors such that the overall "expected" cost of interprocessor com munication is minimised. This is an extremely complex problem to address as Objects can be dynamically created and destroyed; thus some slack factor may have to be introduced with regards to unused processors. A further complication arises in that Objects that may exhibit concurrency with regards to each other should, if possible, be placed in separate processors. To even complicate matters further Objects that exhibit internal concurrency may require to be spread over several processors.
If the problem at hand is not concerned with the development of an object-to-processor mapping algorithm, then the object-to-processor mapping algorithm does not actually form a mandatory part of the problem being addressed; it is thus a NAIR. In other words, it does not represent an analyticai aspect of the problem but rather an implementation aspect. In this particular case, OOPP proposes that the responsibility of mapping objects to processors should be encapsulated within managers. This will allow for a clear-cut separation of analytical responsibilities (encapsulated within employee objects) and implementation responsibilities (encapsulated within manager objects).
May 1994 C Kyrlakides Page 183 Managers Objed-Oriented Parallel Paradigms
Let US assume that an existing OOPP system was developed without an object-to-processor mapping algorithm but this system has the ability to explicitly or implicitly avail the informa tion required to an independently developed object-to-processor mapping algorithm. In this case the object-to-processor NAIR may be exploited by introducing it in a manager.
8.2.2 Resource Management
In this section we will briefly discuss resource management in general and distributed resource management.
Managers are responsible for monitoring and controlling all resources that have been allocated to them. These resources may consist of either hardware, or software (including Objects), or both.
Under the OOPP philosophy, all physical resources (hardware) as well as all conceptual resources (software - including Objects) are viewed as resources eligible for resource man agement. It is thus clear that resources eligible for resource management under OOPP can be divided into two groups, Object and nonObject resources.
One or more object resources can be managed by a single manager. Several of these resources may comprise of employee objects or even other managers. The latter are then viewed as submanagers of the manager in question.
A manager of object resources may assert control over a wide variety of object based aspects concerning itself and the objects it manages. These may include:
incoming message control,
creation of new instances,
relocation of objects,
transparently redirect outgoing messages to new object locations, etc.
(Please note, the manager does not actually create the new instance of its employee; instead, the manager either approves an incoming request or requests the employee to create a new instance of itself. If this was not done then the manager would require explicit knowledge pertaining to the internal structure of its employees and thereby violate encapsulation).
May 1994 C Kyriakides Page 184 Managers Object-Oriented Parallel Paradigms
OOpp adopts a homogeneous perspective in which everything is an Object. Unfortunately in the real-world not every resource is an object (e.g., hardware resources, existing nonObject Oriented programs, ete.). OOPP's approach to dealing with nonObject resources entails encapsulating them within representative Objects called Special Managers. The only interface possible to the nonObject resource is via the interface of its representative Object. Since this interface is Object-Oriented, the nonObject resource can be treated from an analytical per spective as an Object. NonObject-Oriented resources will be discussed further in section 85.2.1.
The scalability track record of centralised control proves to be inadequate for distributed systems. Thus Distributed Resource Management (ORM) is a justifiable requirement of dis tributed systems.
A single global/centralised resource allocation mechanism may prove to be adequate for small- to medium-scale systems; however, this centralised mechanism may present a severe bottleneck in large to extra-large (futuristic) systems. In order to address this issue, OOPP caters for a distributed resource allocation mechanism. Although such a distributed mechanism is significantly more complex it minimises the occurrence of a bottleneck in larger systems.
In essence, a Manager may operate autonomously within its allocated resource set without requiring authorization from its Super-Manager. Only Resource Management requests exceeding the available (unallocated) resources within the manager's allocated subset will have to be referred to the Super-Manager. As such requests are anticipated to represent a small fraction of the total requests, we can expect to achieve a great degree of autonomy.
8.2.3 Unanswered Issues on Managerial Responsibilities
One question not yet addressed in the Manager-Employee scenario is whether some of the responsibilities should exist in the Manager or in the specific Objects they manage. For example, Object Access Control varies from Object to Object; however to keep the model conceptually manageable all Objects in a model will require some access control mechanism. Now the question arises, should the Access Control burden be placed on the Object or the Manager by which that Object is managed. At first glance, Access Control is not introduced as a direct result of the problem at hand and is thus classified as a NAIR. From an alternative perspective, access control services are not analytically induced, but access control data are analytically induced; thus we must conclude that access control services are classified NAIR
May 1994 C Kyrialddes Page 1&5 Managers Objed-Oriented Parallel Paradigms
and access control data as AIR. Hence access control services being NAIR should be placed in managers whilst access control data being AIR should be placed in the conceptual Objects. Unfortunately this is believed to limit encapsulation - in order to maximise encapsulation of responsibilities, services and related/internal data should be treated as a single abstract unit. As can be seen a lot of work needs to be done in the area of classifying responsibilities.
Nonetheless, the classification of responsibilities into AIRs and NAIRs intuitively lends itself to determining (and identifying) which responsibilities are more aptly suited for inclusion in Managers and which are more appropriate for inclusion in the model's conceptual Objects.
8.3 Synchronisation Models based on Message Passing
Before continuing we take this opportunity to define models of synchronisation from the per spective of a message passing protocol:
asynchronous send request and continue processing
synchronous send request and await response
Furthermore, under fault tolerant systems, we may require acknowledgement of successful mes sage receipt.
From all the valid permutations of the above mentioned choices, it is clear that burdening the Object with the associated responsibilities will render an Object awaiting a response or acknowl edgement unavailable to all other Objects. Clearly, it is not an efficient method in cases where the receiver is busy and the message is placed in a queue.
A more likely scenario involves separating the mechanisms associated with message transmission from the actual objects requiring to communicate; and placing this responsibility in separate Objects specifically dealing with message transmission protocols. As will be shown, manager objects can very easily be used to manage this form of communication.
8.4 The Manager-Employee relationship
In this section we will present the symbiotic relationship between managers and employees; (both managers and employees are objects conforming to object-oriented hierarchies). Under one aspect of this symbiosis, managers are responsible for monitoring productivity of their individual teams (percentage of usage of allocated resources) and issuing reques~ for more resources or freeing
May 1994 C Kyriakides Page 186 Managers Object-Oriented Parallel Paradigms
unused ones. Requests directed downwards for freeing available resources are viewed as high priority by the lower lyingprocesses; while, upward directed requests are of a lesser priority to the receiving party.
8.4.1 Message Management
This section maintains the viewpoint that objects can be managed by means of managing the messages exchanged between them; a form of message management. Under OOPP's homo geneous approach everything is an object; in particular, both managers and employees are objects. Since the customary form of interaction between objects is by means of messages, it is thus clear that one of the most fundamental aspects of managing objects rests within the scope of message management. This section also addresses the benefits provided by message management within the context of message passing protocols - in particular message queues.
Under message management, a mechanism capable of reducing dependencies between two management areas by enforcing a restriction on message passing, (e.g., the Law of Demeter resulting in a reduction of dependencies between Classes), will prove beneficial.
In the Manager-Employee scenario, a Manager is responsible for monitoring (and controlling) its sub-managers and employees. The default mode of operation is that an employee may only communicate with its immediate super-manager. This mode of message passing control will allow for maximum monitoring of resources. However, (as oopp is intended to be general purpose), when necessary the ability to deviate from this message passing restriction may be allowed by the manager in one of two ways:
A manager may allow all its employees or a group of its employees to communicate directly.
A manager may allow one of its employees or a group of its employees to communi cate to an employee (or group of employees) outside that manager's controlling area.
Unless a manager revokes the message passing access granted above, that manager will have no control over the messages exchanged. Nonetheless, even though no control can be exercised over the messages exchanged, it is advisable that the manager should continue monitoring the effects of the messages allowed under these deviations.
May 1994 C Kyriakides Page 187 Managers Objed-Oriented Parallel Paradigms
The first deviation should not be granted in the case where the Employees are involved in tasks requiring Managerial supervision. One such example, is real-time processing requiring the Manager to monitor processes and when necessary force an overdue response.
Furthermore, the second deviation must be kept to a minimum as the two parties involved in a Message exchange may be situated in processors that are far apart. If direct communication between these Objects is not too frequent, then the interprocessor communication require ments will not be severely increased. In this case however an additional dilemma occurs which could significantly complicate matters; namely, the possibility exists that the receiving object may be relocated after the sending of a message and before its arrival at its destination. As will be shown, managers can be utilised to effect transparent message passing between any two employees regardless of their physical locations.
The message passing efficiency of a particular message passing protocol is dependent on both hardware and software support. Mail and message queues provide a facility that is prone to bottlenecks under high message communication requirements. The concept of a passive queue is a throwback to earlier computational models. It is a reasonable expectation that efficient message management could prove extremely beneficial in improving the performance of vari ous object system applications.
One aspect of messages queues to be discouraged involves placing messages on hold in a queue whose acceptability by their intended receiver is still to be determined. Instead, Tello [1989] proposes that message checking and execution should be divided into two entirely dif ferent operations performed even by different objects. This approach suggests incorporating checkers to determine whether a message is acceptable before it is placed in a queue. Under OOPP, manager objects can easily fulfil the role of checkers.
The nature of associating queues with objects needs to be addressed. For example, if it is determined that the intended receiver is busy, there does not seem to be any advantage in having a checker dedicated to an individual message queue. A more intuitive approach would be to associate the message queue with the class of all objects eligible to receive them.
Also, if all the data structures are active, then in which way can the active potential of the message queues be used to optimise message-passing efficiency? Tello suggests that the items in the queues are enabled to actively solicit substitute receivers.
May 1994 C Kyriakides Page 188 Managers Objed-Oriented Parallel Paradigms
In addition to message management other forms of management services exist; these include: resource usage monitoring, error recovery, object relocation, etc. Furthermore, since several object models consist of independently active processes (e.g. actors) other forms of manage ment may also be appropriate with regards to a specific model These management areas have been dealt with in more specific sections.
8.4.2 Direct vs Indirect Message Passing
Under direct message passing a message is send directly from the sender to the receiver. Under indirect message passing, a message is send from the sender to the receiver via one or more intermediary objects. This section addresses the advantages and disadvantages of direct and indirect message passing protocols. As will be shown, under the OOpp m.odel, managers may be treated as intermediary objects used to provide communication enhancing services to their employees.
Objects communicate by sending messages. Generally, a message is send from one Object, the sender, to another Object, the receiver. From an analytical point of view, this direct message passing approach is extremely simple. Furthermore, it is adequate for single processor appli cations, (since, all objects and their implementations exist on the same processor). However, the direct message passing approach under multiprocessor applications may not be adequate nor efficient.
In multiprocessor applications interprocessor communication costs and fault-tolerant commu nication impose requirements that serve to complicate the simplistic view of the direct message passing approach. For example, under the direct message passing approach, each object requiring fault-tolerant communication will require access to fault-tolerant services. These may be provided by other objects in the model or be available as inherited or explicit services within the sender. Unfortunately, considering the services as part of the sender does not represent a true analytically appropriate view of that object. To elaborate, from an analytical perspective, the sender needs to communicate with the receiver by sending any allowable message - nothing more and nothing less. The fault-tolerance aspect arises from an imple mentation/specification perspective rather than an analytical one.
The indirect message passing approach allows messages to be send from the sender to the receiver via intermediary objects. Intermediary objects can then be used to provide message management services. Although using intermediary objects will lengthen the distance the
May 1994 C Kyriakides Page 189 Managers Object-Oriented Parallel Paradigms
message has to travel, several benefits are possible. Namely, the messages can be screened for validity even while the receiver is busy. Furthermore, the responsibility for routing and ensuring successful transmission of a message can be left up to the intermediary objects. In effect, the indirect message passing approach can be effectively used to provide Object distri bution transparency (as described by the OMG in section 6.2.1.1).
Under multiprocessor environments, indirect message passing allows system developers to concentrate on the analysis issues at the analysis stage and postpone the requirements imposed by system implementation to a later stage.
In OOPP, managers provide the message management services of the intermediary objects mentioned above. Note however that, managers can provide more than just message man agement services.
As was mentioned earlier, although not identical to the indirect message passing approach, Tello [1989] proposes a similar concept using checkers to determine the suitability of messages in a queue.
8.5 Special Managers
In general, Managers manage Employees - both being Objects. However, in many systems, both Objects and nonObjects may exist. If possible, a general-purpose paradigm should address both the need of managing Objects, as well as, managing nonObjects. Hence, the concept of Special Managers is proposed for the purpose of - amongst others - managing nonObjects.
Like all managers, special managers manage one or more resources. As was mentioned earlier on in this chapter, special managers deviate from the manager-employee concept in that the resources they manage may comprise of nonObject-Oriented "services", hardware resources, as well as, ordinary Object-Oriented services. Hence, a service made available by a special manager may be performed by an existing nonObject-Oriented algorithm; in this case, the special manager acts as an Object-Oriented interface to nonObject-Orient software.
In accordance to the Object-Oriented perspective, the principal benefit of the special manager concept presented here rests on the premise that the service(s) provided or resource(s) managed by a special manager will be encapsulated within that manager; furthermore, as will become self-evident, this can greatly enhance the analytical, development and maintenance perspectives.
May 1994 C Kyriakides Page 190 Managers Objed'()riented Parallel Paradigms
Similarly, in the case of hardware resources, the manager encapsulates the service(s) provided and/or functionality of the hardware resource(s). Thus the special manager may also be used to present an object-like interface to a nonObjeet-Oriented hardware resource.
The question we attempt to answer in the remainder of this section is whether it would be beneficial to have Special Managers addressing specific processes, resources or types of monitor ing. Although we will discuss only two categories of Special Managers, (namely Special Interface Managers and Special Communication Managers), additional Special Managers may be considered in future research.
We define active communication to occur by means of electronic communication hardware on the computer (such as a modem, a Network Interface Card (NIC), etc.) whereby one machine inter actively communicates with another machine; Passive communication is defmed to be communication by means of removable storage media (such as a floppy disk, backup tape, etc.).
8.5.1 Special Communication Managers
Special Communication Managers are aimed at providing oopp with essential communication support. Although the capabilities provided by Special Communication Managers may not be essential to achieving greater problem space understanding of a proposed development, these capabilities will usually enhance a proposed model.
Areas where Special Communication Managers can prove to be remarkably useful include protecting against virus infection, data compression, network communication, interfacing of incompatible (hardware or software) systems, and so on.
8.5.1.1 Antivirus Managers
For example, with the advent of viruses it has become necessary for system designers to cater for detecting illegal entry by viruses into a system. Entry of a virus into any system is accomplished by means of (active or passive) communication with an infected computer. All communication must occur via some device. Treating that device as possible culprit, a special antivirus-manager can be placed in absolute control of that device. All requests to access the said device will be routed through the antivirus-manager which is fme-tuned to detect viruses before granting or rejecting access to the suspect device.
May 1994 C Kyrialddes Page 191 Managers Objed-Oriented Parallel Paradigms
With passive communication the virus safety measures are straightforward. Prior to esta blishing passive communication check the removable storage media for probable virus infection. Only if no virus infection is detected should access be granted to the removable storage media.
With active communication however things are a little trickier; the viral infection may occur at any time instant during the link with an infected machine. Viral infection could be prevented by screening the data.for viruses as it comes in. However, should the number of viruses required to be screened for be substantial enough, the communication link could be severely slowed down. One way to overcome viral infection without killing the speed of the link is to buffer the incoming data and place one or more virus-detecting managers in separate processors in the immediate vicinity of the device. In order not to compromise safety, these processors should be dedicated to viral detection and, furthermore, should not be incorporated in relaying interprocessor communication messages. This can be attributed to the fact that the detection of a virus may cause the processor to suspend execution and reset itself; or even worse, the virus may incapacitate the antivirus-manager and thereafter gain access to the system. To enhance system security, one processor could be assigned a special manager, called the virus-free despatch manager, responsible for despatching approved virus-free data in the correct sequence. The virus-free despatch manager is then designated to be the super-manager of all or a group of antivirus-managers.
If a virus incapacitates an antivirus-manager then some mechanism must exist for detecting such violations of system security. One possible (although not foolproof) solution is that during system startup, each antivirus-manager is assigned a special signature (based on a unique id number) issued to it by the virus-free despatch manager. The antivirus-manager then uses the signature to determine a position in its local processor memory in which to store the signature. Prior to forwarding approved data to the virus-free despatching man ager, the antivirus-manager places its signature id within the data. The virus-free des patching manager will then only accept data with valid signatures. Should data arrive without a valid signature, the virus-despatching manager can then poll the various antivirus-managers in order to detect an incapacitated antivirus-manager. The incapacitated manager can then be restored to health.
May 1994 C Kyriakides Page 192 Managers Objed-Oriented ParaDel Paradigms
8.5.1.2 Data Compression Managers
Depending on the compressibility of the data, prior to transmitting, it may prove rather beneficial to compress the data at the sending-end and uncompress at the receiving-end. If desired, Data Compression Managers may provide their services to Managers (Objects) that manage communication resources.
Hence, a Data Compression Manager may provide its services to a Manager acting as the exclusive interface to a communication resource. This communication resource may be a traditional communication device (such as a modem); or in the extreme case, the "com munication" resource considered may even be the actual processor, in which case data compression will be done on interprocessor communication. Note however that the level at which data compression is considered is very important; too fine (i.e. at interprocessor level) may prove disadvantageous as most of the messages may be too small to warrant effective compression when compared to the cost of implementing the compression rou tine; while too rough (i.e. at modem or network card level) may also prove disadvanta geous as many worthwhile compressible interprocessor communication will be overlooked. If the size of data required to be transmitted is known in advance, one possible (and unfortunately imperfect) solution open to future research, is to consider compressing only data larger than some predetermined size.
Within the AIR/NAIR perspective discussed earlier on, it must be pointed out that (unless the problem at hand is concerned with data compression), data compression itself does not effect the analytical aspect of the problem; only the performance aspect is effected. For example, if at any instant any two Objects require to communicate then, irrespective of whether data compression is present or absent, those two Objects will require to com municate. Data compression only influences the speed at which the communication will take place.
8.5.2 Special Interface Managers
Special Interface Managers are Managers (Objects) aimed at providing OOPP with an Object-Oriented interface to a nonObject-Oriented (hardware or software) resource. Special Interface Managers may also be used to provide an Object-Oriented interface between two or more incompatible object-oriented systems/platforms.
May 1994 C Kyrialddes Page 193 Managers Objed'()riented Parallel Paradigms
8.5.2.1 Special Interface Managers and NonObject-Oriented Resources
Since OOPP is homogeneous, everything in an OOPP model must be an Object. At first, the attempt to monitor hardware resources and software resources appears to violate this homogeneous feature. Nonetheless, if OOPP wishes to cater for the incorporation of existing nonObject-Oriented resources into proposed OOPP developments, then provision must be made for treating these nonObject-Oriented resources as Objects. To elaborate, an existing nonObject-Oriented software application may be incorporated in any OOPP development by defining and creating a Manager Object that acts as an interface between the OOPP model and the nonObject-Oriented application. Messages can then be sent to the Manager Object and the Manager is then responsible for interpreting/translating the message to the nonObject-Oriented application. Since the only way to reach the nonObject-Oriented application is through the (Object-Oriented) Manager, the OOPP model views the application as a single abstract Granular Object. The Manager in this case is a Special Manager called a Special Interface Manager and serves to provide OOPP with an Object-Oriented interface to a nonObject-Oriented resource.
8.5.2.2 Managers for Specialised Resources
Faster CPUs have been employed in order to attain greater speed on serial machines. Furthermore, specialised processors with a limited program of selectable operations have been created for speeding up resources such as communication devices, monitors, hard disks, etc. Specialised processors are increasingly implemented in parallel computers. Special Managers dealing with specific resources (and possibly having detailed knowledge and specialised algorithms for these resources) could be introduced into the Object Oriented Parallel Architecture. The methods of these managers could be used to present a single "interface" to the set of available services of the processor; or, a fundamental "program" written in terms of the available services; or, if the processor allows, a "pro gram" consisting of a mixture of available services and general code.
The benefit that will be attained by interfacing to specialised processors via Special Interface Managers (i.e., Objects) is that abstraction can be realised by means of encap sulation. Other Objects in the system requiring access to the available Services and/or "programs" will view them as methods belonging to a Manager. The Abstraction Boundary of the Manager Object can then be used to setup an information-hiding interface from
May 1994 C Kyriakides Page 194 Managers Objed'()riented Parallel Paradigms
outside Objects. Hence, if during maintenance or system upgrading the specialised resource (i.e., specialised processor) is replaced, then only the Special Interface Manager will require modification. In contrast, if no Special Interface Manager was used, then several Objects in the system may have access to the specialised resource; these objects will have to be identified during system upgrading and all such objects will require modi fication.
8.6 Networking Capabilities
The Manager-Employee scenario incorporated in OOPP has one self-evident advantage over other methodologies; namely, any system developed using OOPP should in theory have the ability to operate on either a parallel processor machine, or a network of (parallel or single processor) machines. This capability can be attributed to the fact that any manager can operate autonomously from his peers or superiors for most of his operations (except for requests for reallocating resources) provided he works within his own allocated resources.
In a network of machines however, the allocation of resources will have to be controlled in terms of resource sets (defined in section 9.7.2). Each machine will require its own resource set based on the resources physically positioned on that particular machine. As a rule of thumb, any manager mapped to a physical machine may only be allocated resources within that machine's set. That manager's sub-managers and employees will also have to be allocated within that set.
The limitations of the network scenario are obvious. Namely if a manager is allocated to a specific machine and at a later stage grows too resource hungry, say beyond that machine's capability, then it will be too costly to move him and his team to another machine. Two options exist here: move the entire subdivision to another machine; or place the new members under a submanager m another machine.
The advantages of the network scenario however are more significant. Namely, if a system being developed using OOPP for a one parallel machine environment is found to be lacking in pro cessing power, then the designer can easily couple another machine on the network. The newly coupled machine can be allocated its own topmost manager containing information on the resources of the new machine. All the pertinent resources available on the machine should be allocated to this machine's topmost manager. This manager can then be introduced into the existing system as a submanager of the existing topmost manager.
May 1994 C Kyriakides Page 195 Managers Objed'()riented Parallel Paradigms
8.7 Managers and Object Allocation
In this section we present two viable scenarios under which managers and employees co-exist. In the first scenario, called the Two-Tier Approach, Managers and Employees exist in two distinct Object-Oriented hierarchies; the management links between Managers in the one hierarchy and Employees in the other hierarchy may be one-to-one or one-to-many. In the second scenario, called the Direct-Inclusion Approach, the Manager Object is included in the Employee Object. As . will become self-evident the first scenario affords greater benefits and flexibility.
As will be explained shortly, what is important to note is that the inheritance mechanism asso ciated with Object-Oriented hierarchies can be successfully exploited under the Manager Employee model. The Manager and Employee hierarchies consist of classes where the classes at the top of the hierarchy represent more general cases of classes lower down the hierarchy. Unless an inherited characteristic is overridden, it is reasonable to assume that subclasses of a common superclass will depict similar processing characteristics and thus require similar management ser vices. Thus a manager class may be associated with managing; an employee classes, or some of the subclasses of a particular employee class. Although here we are talking about classes it is important to note that it is an instance of a manager class that manages one or more instances of an employee class.
It is not anticipated that the straight-forward scenario depicted above will apply to all real-world systems. For example, multiple inheritance in the employee hierarchy is anticipated to be accom panied by multiple inheritance within the manager hierarchy. Furthermore an employee subclass may not be sufficiently different from its superclass to warrant the creation of a new manager; thus (in some models) instances of an employee subclass may be managed by manager instances that manage instances of its employee superclass.
It is important to note that mapping from manager classes to employee classes may be one-to-one or one-to-many; furthermore, mapping from manager instances to employee instances may also be one-to-one or one-to-many. Although the most typical real-world scenario in both cases will be one-to-many.
Before we continue we should point out that in the Two-Tier Approach, the Manager hierarchy and Employee hierarchy should be distinct; nonetheless, these hierarchies may be distinct sub hierarchies of a common superclass.
May 1994 C Kyriakides Page 196 Managers Object-Oriented ParaDel Paradigms
8.7.1 Two Tier Approach
. The Two-Tier Approach is based on Managers providing management related services to one or more Employee Objects. Unlike the Direct Inclusion approach, Managers under this sce nario do not form part of the Object they manage.
--t..~ Inheritance Relationship ------Manager-Employee Relationship
---- Implicit Manager·Empl~'ee Relationship
Instead, Managers are viewed as being mapped (one-to-one or one-to-many) onto the Objects they manage. To elaborate, an instance of a Manager Object may manage either:
a single instance of an Employee Object, or
all the instances of a particular Employee Class, or
some of the instances of a particular Employee Class, or
several instances belonging to one or more Employee Classes.
As will be seen, Twa-Tier Managers are can be more effectively focused on the managerial responsibilities that they provide. Furthermore, since NAIRs are encapsulated within manag ers, the Twa-Tier Approach allows for effective separation of NAIRs from the analytical aspects of a system.
May 1994 C Kyriakides Page 197 Managers Objed'()riented ParaDel Paradigms
8.7.2 Direct Inclusion Approach
The Direct-Inclusion Approach is based on Managers forming part of the Object they intend to manage. The choice of suitable responsibilities of Direct-Inclusion Managers is determined by provisions made by the program development environment.
Where provision is made for an Object to have an active portion even while waiting for a message, then Managers can be incorporated under the Direct-Inclusion scenario. If Direct Inclusion Managers are incorporated under a scenario where no provision is made for an active-while-waiting portion, then the responsibilities of the manager should limited to non-time-critical duties.
As was mentioned above, NAiRs are encapsulated within Managers. However, under the Direct-Inclusion Approach the Managers form part of the Employee Object; attributable to this fact, Direct-Inclusion Managers have a greater tendency to introduce NAiRs into the analytical aspects of a system. Also from an analytical perspective it is easier and more log ically correct to view Managers as distinct Objects from the Employee Objects that they manage.
It is thus clear that although both the Two-Tier and Direct-Inclusion Approaches can be accommodated within OOPP, the Two-Tier Approach is more preferable as it presents greater benefits and flexibility.
8.8 Managerial responsibilities vs Employee responsibilities
In closing, we need to clarify which responsibilities belong to managers and which responsibilities belong to the objects that they manage. We continue were we left off in section 8.2 and present the following guideline:
A responsibility belongs to a manager if it does not form a mandatory part of the problem space as addressed from the analysis perspective. Similarly, a responsibility belongs to an employee if it is a responsibility that is mandatory to the problem space as addressed from the analysis perspective.
May 1994 C Kyriakides Page 198 Managers Object.oriented Parallel Paradigms
From the above, it is clear that the managers' and employees' responsibilities are distinguished based on the problem space at hand. Thus, whereas in one development a responsibility may form part of the managers' responsibilities, in another, it may be more suitable for that responsibility to form part of the employees' responsibilities.
As an example assume that we require to develop a database system with the ability to transpar ently link into compatible remote databases. Clearly, part of the problem may entail objects presenting knowledge of the existence and location of the remote databases, as well as, objects facilitating communication. However, it is not a mandatory part of the problem space to optimise communication; instead, optimising communication is more of an implementation/performance consideration than an analytical one. In other words, what is required from an analytical point of view is, nothing more and nothing less than, the ability to communicate with the remote database. Thus, part of the employee's responsibilities deal with addressing the need for communication; while managers address the issues relating to optimising communication (e.g, data compres sion/uncompression, determining optimal data transfer speed, etc.), If however the problem at hand was concerned with developing a communication system then most of the previously
mentioned responsibilities would DOW form part of the employees' responsibilities.
It is clear that, the boundary between the managerial and employee responsibilities varies m accordance to the problem at hand. We should point out that the majority of proposed systems dealing with a particular problem domain (e.g. databases) vary with regards to their details of the defmition of the problem. Thus in real-life, the boundary between the NAIRs and the AIRs is not anticipated to be as clear-cut as the theoretical distinction depicted above.
8.9 Conclusion: Managers
The Manager-Employee symbiosis exhibits defmite benefits with regards to improving the func tionality/performance of a system whilst maintaining a boundary between the analytical and non analytical aspects of a problem, One prominent example of this is that of message management
described earlier 00.
In retrospect the AIR/NAIR approach to Object-Oriented systems analysis appears to exhibit significant benefits justifying further research. In addition to the AIR/NAIR classification, it is clearly beneficial to keep nonAnalytically induced responsibilities separate from the analytical aspects of a system; to this effect, OOPP's managers prove to be a natural encapsulation vehicle for NAIRs. It is anticipated that during maintenance (or upgrading) of a system implementation,
May 1994 C Kyrialddes Page 199 Managers Objed-Oriented ParaDel Paradigms
if a NAIR needs to be altered then this alteration should not affect any of the analytical parts of the system. Since NAIRs are encapsulated within managers, then unless the interface to the responsibility (i,e., its operation) is altered, no objects other than that manager is affected.
As was mentioned in the introduction to this chapter, the manager-employee anthropomorphic view is not followed rigorously. In retrospect it should thus come as no surprise that several responsibilities of computer-based oopp managers do not concur with the responsibilities of real-life managers. It should nonetheless be kept in mind that the responsibilities of an oopp manager are determined from the problem space at hand, and clearly current computer-based environments do not concur to real-life environments. Nonetheless the term "managers" proved to immediately disclose the dominant role of OOPP's managerial responsibilities. A more general, although non-revealing term that could have been used instead is "service providers"; we would then have management service providers, communication service providers, peripheral service providers, and so forth.
May 1994 C Kyriakides Page 200 Object-Oriented Parallel Paradigm Object-Oriented ParaDel Paradigms (OOPP)
9 Object-Oriented Parallel Paradigm (OOPP)
This chapter outlines the principal aspects of OOPP's anatomy; as such these aspects are intended only to provide an idea on how issues addressed by earlier chapters and issues still to be addressed will be placed together in later chapters to form a more complete jig-saw picture.
The OOPP research attempts to identify characteristics that are likely to be not only preferred but possibly even demanded in large-scale Object-Oriented Parallel Systems of the future. OOPP is in essence addressing not only one objective, but instead, a number of smaller sub-objectives which in their own right may in future have to be readdressed and elaborated on as individual research topics.
With regards to the sub-objectives mentioned above, not all had been previously formulated; and as such, some had to be formulated during the course of the OOPP research (a good example of this is the Object Taxonomy). It is not within the scope of this research to provide extensive research on each of these sub-objectives. It is within the scope of our research to, to a small degree, indicate that such research issues still need to be addressed; and to an even lesser degree, give an indication of what such research should address.
9.1 Brief Outline of the OOPP Approach
Below we present a brief outline of OOPP's approach.
1) The physical system is viewed as a set of interconnected resources.
2) Every resource is allocated to and managed by a Manager (although each manager may manage one or more resources). The nature of managers has been described in chapter 8.
3) All Managers are related hierarchically. The manager at the root of the hierarchy is known as the top-most manager. Initially managers are associated with resources by the system designer (or maintainer). A snapshot taken of the manager hierarchy at ANY point will be such that a manager higher up in the hierarchy will have knowledge of all resources managed by itself and summary knowledge of all resources managed by any managers below itself in the hierarchy. (Summary information includes aspects such as memory capacity, performance statistics, etc. However the lower level manager is solely responsible for the management of the resources managed by it, including aspects such as determination of performance statistics).
May 1994 C Kyriakides Page 201 Object-Oriented Parallel Paradigm Object.Qriented Parallel Paradigms (OOPP)
The procedure for addition of resources has been described in section 8.2.2.
4) Higher managers may pass requests (for resources, re-allocation, etc.) or demands to lower managers. Lower managers can only pass requests to higher managers.
5) A manager is an Object. It keeps track of (and controls) resources under its responsi bility. These resources include the physical resources mentioned above and "soft" resources such as software Objects allocated to it. (For example an employee Object executing on a processor will be part of the responsibility of the manager of that processor). The following responsibilities are included in a manager's behaviour: - Keeping track of resources - Adding resources - Deleting resources - Relocating resources Note that the addition, deletion and relocation functions are primarily intended for (software) Objects under the management of a manager. (Treatment of physical resources will be described in section 9.7.2; while Actions supported by managers have been elaborated on earlier on in chapter 8).
6) For any action that a manager may support, a set of rules and restrictions may exist, as well as a specific protocol to adhere to. (For example a manager may only delete objects directly under its control. Furthermore, a manager may proceed to relocate one of its employee objects after advising all other managers whose employees may com municate with the employee which is about to be relocated).
7) Since managers are Objects, they are instances of (manager) classes. Such a class may for example be provided to manage a resource such as a CRT, disk, etc. A system developer may add manager classes specifically tailored for a new application introduced to the system, such as a new manager for a database package.
8) The manager classes form a hierarchy (like any other set of classes). Typical aspects inherited may include services dealing with monitoring, reallocation, fault-tolerance and so on.
It is important to note that mapping from manager classes to employee classes may be one-to-one or one-to-many.
May 1994 C Kyrialddes Page 202 Object-Oriented Parallel Paradigm Objed-Oriented ParaDel Paradigms (OOPP)
9) When a new (Object-Oriented) application is designed, the designer will specify a manager class for every employee class of the new application. Any instance of an application class will be loaded on a processor (or set of processors) managed by a manager which is a instance of the specified manager class.
9.2 OOPP's Aims and Approach
The Object-Oriented Parallel Paradigm attempts to provide a viable vehicle for marrying the Object-Oriented and Parallel Processing microcosms into one homogeneous body. OOPP fur thermore endeavours to maintain a large degree of the benefits encountered in each field indi vidually.
The Object-Oriented Parallel Paradigm (OOPP) exploits concurrency within a problem space, firstly by breaking down a problem into appropriate Objects (under an Object-Oriented hierarchy), and thereafter identifying suitable candidates for concurrency within the context of the Object Oriented hierarchy. OOPP caters for Object Internal and/or External Concurrency, or both. Fur thermore, the Object-Oriented Parallel Paradigm extends Inheritance to cover the concurrent characteristics of all Objects within a hierarchy.
OOPP does not endeavour to replace Traditional Parallel Processing, but instead to enhance its capabilities. Traditional Parallel Processing is primarily concerned with the performance aspects of Parallel Processing and its approach does not accommodate effective problem space understand ing. The approach undertaken by OOPP enhances problem space understanding in the Parallel Processing microcosm by introducing a comprehensive Object-Oriented approach to Parallel Processing. Furthermore, aspects related to "management" (i.e. sequencing, monitoring, etc.) of Objects and their internal methods may be incorporated into special Objects (called Managers).
OOPP and all formal techniques that may arise from it should under no circumstances be viewed as a panacea to all problem solving. Instead, OOPP should generally prove to be of value in problems that are amenable to parallel processing techniques and currently lack significant prob lem space understanding under the auspices of Traditional Parallel Processing.
May 1994 C Kyriakides Page 203 Object-Oriented Parallel Paradigm Object-Oriented Parallel Paradigms (OOPP)
9.3 Distinctive Features of OOPP
OOPP introduces two fundamental features to Object-Oriented Parallel Systems. The Object Taxonomy introduced in section 53 provides an extensive vehicle for describing the parallel pro cessing characteristics of Objects. The Manager Objects introduced in chapter 8 allow manage ment aspects of Objects to be encapsulated within these Managers thereby abstracting the non-problem space understanding aspects (such as resource monitoring) from the problem space understanding and functionality of individual Objects.
Other issues discussed previously include Processor Workloads and Productivity within the context of Object technologies (section 5.5) and Object State and Method Coupling (section 5.4).
9.3.1 Object Taxonomy
The Object Taxonomy provides an extensive vehicle for describing the parallel characteristics of Objects. The ability to cater for a comprehensive description of Objects with regards to their parallel processing features is of primary importance to problem space understanding. This can be ascribed to the fact that OOPP extends the Object-Oriented model to incorporate inheritance of the parallel characteristics of Objects.
The terminology used in our taxonomy is more aptly suited to our requirements than the taxonomy proposed by Wegner [1989]. This can be attributed to the fact that one aspect of obtaining greater problem space understanding involves identifying what aspects of our par ticular problem may be solved in a concurrent fashion and what aspects have to be solved in a sequential fashion.
OOPP's approach..., involves breaking down a problem space into suitable Objects under an Object-Oriented hierarchy. The Objects are then evaluated within the context of our taxonomy to establish their parallel processing characteristics. This evaluation entails:
the characteristics of an Object in isolation,
the characteristics of an Object with regards to a group/subset/class of Objects in the system, as well as,
the characteristics of one or more groups/subsets/classes of Objects with regards to each other.
May 1994 C Kyriakides Page 204 Object-Oriented Parallel Paradigm Objed'()riented Parallel Paradigms (OOPP)
The latter may be undertaken in terms of numerous subsets of all Objects existing in the hierarchy (for example, a subset of Objects may be identified comprising of Mutually Sequential Object instances, or a group of Mutually-Concurrent Object classes, and so on). In the case of subsets, the taxonomycaters for evaluating parallel processing characteristics of any Object in the subset relative to all other Objects in this subset; in other words, the particular relationship expressed by a particular subset is homogeneouslyapplicable to all Objects within the subset. Furthermore, please note that subsets expressing parallel processing relationships are allowed to overlap; thus an Object may appear in one or more subsets.
9.3.2 Manager Objects
Although other models/methodologies make use of the term or concept of managers, no paper referenced by OOPP makes use of managers in the same manner as OOPP.
For example, the Object Management Group (OMG) (discussed in section 6.2.1) makes use of the term management; however, the OMG efforts are not focused at managing objects but rather standardising their interfaces.
Furthermore, the MITRE model (discussed in greater detail in section 12.1) has agents capable of relocating other objects to processors with lighter workloads. Although, this appears to be a form of object management, the objects are managed with regards object "numbers" existing within the processor that the agent is responsible for managing. Hence, the agent acts more as a "processor manager" capable of relocating objects rather than an object manager.
9.4 Fundamental Issues that prompted the development of OOPP
The parallel Object-Oriented paradigms encountered during the course of this research were found lacking in one area or another. The Law of Demeter [Lieberherr 1988] overlooked the influence of strong- and weak-typing in languages; (this influence was readdressed in Lieberherr [1989]). Furthermore, the Law was overly restrictive; not only limiting complexity as intended but also limiting development capability [Sakkinen 1988J. On the other hand, PROCOL [van den Bos 1989] addressed the issues regarding synchronisation between parallel processes. Unfortunately, both the Law of Demeter and PROCOL fail to consider the implications of Object-to-Processor
May 1994 C Kyriakides Page 205 Object-Oriented Parallel Paradigm Objed-Oriented Parallel Paradigms (OOPP)
mapping which in any Object-Oriented multi-processor parallel environment is of significant con sequence. Also PROCOL is founded on the assumption that the grain of parallelism is the Object; it thus ignores the possibility of Objects exhibiting parallelism internally.
In introducing our next issue, Quinn [1987] states that owing to communication overheads (or other factors) the performance of an algorithm may depend on the chosen architecture. For example, processors in a processor array work in lockstep, while synchronisation on multicom puters and multiprocessors is achieved by means of software and is thus time consuming. Algo rithms having a small grain size (i.e, performing relatively few operations between synchronisations) usually exhibit poor efficiency on MIMD computers.
Quinn refers to algorithms in traditional Parallel Processing. What should be clearly stated at this point is that Object-Oriented Parallel Paradigms are not intended to make traditional Parallel Processing redundant. Instead, OOPPs are intended to enhance the capabilities of Parallel Pro cessing as a whole. A distinction made by this research is that Object-Oriented Parallel Processing algorithms are intended to be dynamic in nature, allowing for Object creation and deletion; while, traditional Parallel Processing algorithms tend to be more static in nature. Expanding on this distinction is the fact the Object-Oriented Parallel Paradigms are aimed at the analysis (problem space understanding) level; while, traditional Parallel Processing algorithms tend to be based on a particular architecture and as such are generally not easily transportable. System developers need a vehicle providing problem space understanding within the context of the problem space (as in OOPP); not, problem space solving within the context or aD architecture (as in Traditional Par allel Processing). Object-Oriented Parallel methodologies should aim to isolate an architectu re/hardware dependent algorithm into a single Object (or group of Objects); as elaborated in section 85.2.
In order to readdress the focus on the issues omitted in current proposals, it is our intention to provide a proposed paradigm aimed at providing a comprehensive solution to Object-Oriented Parallel methodologies. The main characteristics of the DOPP methodology include a fully Object-Oriented approach to Parallel Processing. This differs from other research approaches since in OOPP this entails all the Object-Oriented features including inheritance. Furthermore, inheritance is extended into the analysis effort of the Objects' parallel processing characteristics. The OOPP paradigm presented here should only be used as a guideline for instigating more puritanical development systems. Before presenting the GOPP proposal however we will indulge briefly in the topic of future trends.
May 1994 C Kyriakides Page 206 Object-oriented Parallel Paradigm Objed-Oriented ParaDeI Paradigms (OOPP)
9.S Future Trends
Several current trends tend to predict the characteristics of future systems. Below follows a brief list of expected future trends (and current features expected to prevail and/or proliferate in future systems):
Computer hardware prices, physical size of processors and memories will continue to decrease, while processor speeds and storage capacities increase.
VI..SI (Very Large Scale Integration) will be succeeded by ULSI (Ultra Large Scale Inte gration).
Multi-processing and massiveparallelism will become more common.
Numerous Operating System functions currently performed by software will migrate into microcode.
Hardware architectures of the future will distribute control into localised processors.
Languages are being developed to exploit concurrency, while hardware and Operating Systems are being designed to execute concurrent programs more efficiently.
Computers and Operating Systems will be designed to foster the operation of virtual machines. Real machines will be hidden from the user.
The family concept of machines as first introduced in the IBM 360 series will endure. Users will be able to run their applications on many different members of a family of computers, and these applications will see only virtual machines.
As new generations of computers are introduced by the manufacturers, existing programs will run on the new equipment as is, or with nominal conversion effort.
Developments in software engineering will result in operating systems that are more maintainable, reliable, and understandable.
The cost of data communications will continue to decrease, and data transmission speeds will increase.
May 1994 C KyriaJddes Page 2fY7 Object-Oriented Parallel Paradigm Objed-Oriented Parallel Paradigms (OOPP)
Computing power and resources will be progressively amalgamated via networks. If needed, work performed for a user may be done on a remote computer without the user's prior knowledge. This will continue to emphasize the importance of the views of virtual machines.
The concept of virtual storage will endure. The key concept it: virtual storage is to disas sociate the address referred to in a running process from the address available in primary memory. Hence, there is a process's virtual address space [V] and a computer's real address space [R]. The virtual address space is then be mapped into the real address space as the process executes.
The previous view of an operating system as a resource manager will endure but the resources being managed will change. In particular, data will be viewed increasingly as a resource to be managed.
The concept of distributed processing will motivate the development of dispersed operating systems in which operating system functions are distributed among many processors throughout large networks.
Personal Computers will become more widespread. Utilisation of the resource will mean less than its availability, reliability, and user friendliness.
9.5.1 Implications of Future Trends
Based on the future trends above, below follows a brief discussion on expected influences in developing a paradigm such as OOPP. It must be kept in mind that OOPP was designed with the specific purpose of being suitable for the existing machines of today, and furthermore, amenable to the machines of tomorrow.
Virtual Machines and ULSI
Currently, several parallel computers have the ability (some by means of software manipula tion, others by hardware manipulation) to be virtually reconfigured.
May 1994 C Kyrialddes Page 208 Object-Oriented Parallel Paradigm Object.Qriented Parallel Paradigms (OOPP)
Thus it should come as no surprise that one likely future trend could be the introduction of machines having a very large number of processors with the ability to be reconfigured by
means of software SO· as to provide numerous virtual machines, each virtual machine being capable of emulating a desired architecture.
Obviously, even though we may have hundreds or even thousands of processors on one machine, certain limitations will persist. For example, the maximum number of processors in a certain configuration could be restricted along with the maximum number of processors involved in such a configuration: To elaborate further by considering a fictional futuristic machine, we may be allowed several hypercube configurations each not exceeding 64 proces sors, and not more than say 256 processors may be involved in all the hypercube configura tions. While for fully-interconnected configurations, we may be allowed a maximum of say 24 processors per virtual machine, and a maximum of only two such virtual machines. Likewise, valid combinations of different types of virtual machines may be stated.
If the above restrictions were not in place and we could choose any size virtual machine in any architecture then the problem of Object-to-Processor mapping would be eliminated by select ing the fully-interconnected architecture for every application. Unfortunately this Utopian view is unachievable within our current-day technological capabilities and, if future trends are anything to go by, it should not be expected to be any different in the not too distant future.
Thus, any futuristic paradigm should have the ability to consider the implication of such technological/configuration restrictions on a proposed system. Furthermore, the paradigm should be flexible enough to allow the designer the option of expressing his proposed system within any possible set of virtual machine configurations,
Networks and Distributed Processing
Networks are currently oeing implemented to effect the sharing of common resources such as printers, hard disks, modems, etc. As mentioned above, data tend to be more and more perceived to be a common resource. However, one aspect not fully exploited yet is the efficient utilisation of idle processing power residing in several machines distributed across a network. With this in mind, Distributed Processing will become more prominent as the avenue to achieving the goal of equitable distribution of idle processing power.
May 1994 C Kyriakides Page 209 Object-Oriented Parallel Paradigm Objed'()riented Parallel Paradigms (OOPP)
Conceptually the idea of Virtual Machines can be taken even further on networks; the network itself can be viewed as a single machine providing numerous "virtual" machines (represented by each actual machine) where each machine has its own set of resources. In turn, if any machine on the network has multi-processing capabilities or is even partially or fully reconfi gurable, then that "virtual" machine can provide a number of smaller virtual machines. A user on a futuristic network could be sitting in front of a single CPU machine and request an application to execute that requires a multi-processor machine configured for a particular architecture. Should such a machine be available or linked to the network, then the application can be loaded on to the machine and executed. The user would be unaware that the machine running his application is situated elsewhere in the network and would simply interact with the machine in front of him in the normal fashion; this will include monitor, keyboard, printer, storage media (such as floppy disk) and mouse support.
Conceptually, the only difference between a network and a multi-processor is the fact that the processors reside in different machines or the same machine, respectively. We will elaborate on the above issues in a later section.
9.6 OOPP's Challenge
Traditional parallel algorithms and their efficiencies are highly dependent on machine architecture. Furthermore, the code of such algorithms does not reflect any significant problem space under standing. This inability to depict problem space understanding within traditional parallel processing algorithms becomes self-evident in the following abstract example:
Processor X reads in inputs A, H, and C, then does some operation with these inputs; during the same time period, processor Y reads in D, E, and F, then does the same operation as processor X on these inputs. The outputs of processors X and Y are used as inputs to processor Z which does some operation on them and gives the final output of the compu tation. (For more concrete examples see Haase [1978] and Quinn [1987]).
Amongst other issues, OOPP will endeavour to provide a more viable approach to parallel com puting. Serial computing has made the transition from Assembler to high-level language pro gramming in about three decades. One of the latest transitions in serial computing is the move to
May 1994 C Kyriakides Page 210 Object-Oriented Parallel Paradigm Object-Oriented Parallel Paradigms (OOPP)
Object-Oriented techniques. Only recently has Object-Oriented Parallel Systems become a reality for Parallel Processing. Hopefully, Object-Oriented Parallel Programming will prove to be the vehicle for carrying parallel programming into a new era.
Before continuing we will take this opportunity to make some useful definitions concerning the interfacing of two systems/applications. An Interface establishes communication between two systems/applications in a fashion whereby the first application acts as the client requesting the Services of the second application; and the second application acts as the server providing those Services. Information is exchanged between the Client and Server by means of either placing data in memory (either RAM or disk) or by sending the data when ready (e.g., from processor to processor, directly modifying memory, via an RS232 port, etc.). Furthermore, we defme the fol lowing:
Passive Interfacing: From the time the Server begins processing the request of the Client, no communication may take place between the Client and Server until the Server has fmished processing the Client's request.
Active Interfacing: Communication can take place at any time while the Server is processing the request of the Client.
Below follows a short list of the challenges facing OOPP:
1) A mapping of Objects to processors yielding optimum performance in Object-Oriented Parallel Systems is difficult to achieve.
In order to limit interprocessor communication costs, Objects that need to communicate frequently should be closely grouped in adjacent processors. Statically the mapping is relatively simple; unfortunately, Objects are (and usually have to be) dynamically created and destroyed, thereby making mapping of Objects to processors extremely complex.
A universal view ~f the system's resource usage should be available to every Object with the ability to create or destroy Objects directly (i.e. not via another Object). Failing to provide this facility will result in an ad hoc mapping system unable to cater for future expansion and even be aware of the current resource usage.
2) Efficient resource allocation management including dynamic addition/deletion of resources and optimum usage of specialised resources.
May 1994 C KyriaJdcks Page 211 Object-Oriented Parallel Paradigm Objed-Oriented Parallel Paradigms (OOPP)
In all systems, whether parallel or serial, there is a limited number of resources which therefore have to be managed in an efficient manner. One aspect of resource manage ment was presented above in our discussion on Object-to-Processor mapping. Another aspect that should be considered is the constant trend in computing machinery to introduce specialised processors for certain resources in order to improve the overall speed of a machine.
For example in a serial machine the Object-to-Processor mapping dilemma is non existent as there is only one CPU onto which to map the Objects; all specialised CPUs are dedicated to their specific resources. The dilemma arises with parallel machines: namely, if specific resources (and/or processes) are to be allocated to specific proces sors, then which resources (and/or processes) are best suited to which processors for optimum efficiency. If current trends towards more specialised processors for specific resources are considered, then this fact will be of greater importance in future systems. (Even though specialised processors may take on a different form to the ones currently existing).
The mechanism employed in resource management should have the capability to detect newly added resources to the system while the system is running (either with assistance by the system administrator, and/or by periodically polling the system for known/stan dard resources).
3) Optimum management of Objects (active and inactive)
In the event that processor space is limited, Objects that have been inactive for a certain amount of time should be easily identifiable in order to free some processor space (either by destroying or moving these Objects to disk) so as to accommodate new Objects.
4) Fault tolerance with Error Recovery
All crucial Objects allocated to a processor should be wiretapped (a high-tech word for eavesdrop) along with their state at a certain instant, as well as, messages received since that instant. This will give rise to a number of snapshots covering the processor states of the entire system. In the event of a processor failing during execution, all the crucial
May 1994 C Kyriakides Page 212 Object-Oriented Parallel Paradigm Objed'()riented ParaDel Paradigms (OOPP)
Objects along with their states (including sampling time of state) and sequence of received Messages since last sampling time could be moved to another "healthy" pro cessor and continue execution.
The question now arises: "What is a suitable sampling instance?" A most probable candidate for a "suitable instance" could be the time immediately after an Object/pro cess has achieved synchronisation with another Object/process. However, this is igno rant of the fact that more than one Object could exist in a single processor and that the processes within the Objects could be running in a pseudo-parallel fashion. More aptly, a suitable instance for a processor should be the earliest suitable instance of all Objects/processes within the set of Objects/processes allocated to an individual pro- cessor.
In simpler terms, one possible snapshot instance entails just prior to accepting a mes sage for processing and when all processes within a processor have completed process ing. What complicates matters is that under OOPP an Object may be spread over a number of processors, as well as, a processor may be shared by more than one Object; thus an incoming message to a particular Object may only influence one of the pro cessors used by the relevant Object. The endorsement and weight of what is a suitable instant will be left up to future research efforts.
5) Real-time processing capabilities
In addition to fault tolerance above, real-time processing requires the ability to force a best-so-far response, a most probable (rule-of-thumb) response, or time-stamping of certain Messages (along with a latest acceptable response time after which a response can be forced). The choice as to which form of forced response is appropriate should be dependent on the specific application.
6) Ability for Objects/processes to request a group of processors in a specified processor architecture.
Since current parallel algorithms are highly dependent on a particular architecture for efficient implementation, it would make sense to allow Objects at the time of their creation the ability to specify the number of processors required along with the desired architecture of these processors.
May 1994 C Kyriakides Page 213 Object-Oriented Parallel Paradigm Objed'()riented Parallel Paradigms (OOPP)
This is one aspect of systems development that forms part of the analysis effort while at the same time may be viewed as an implementation issue. To highlight this, under analysis an analyst may attempt to ascertain whether a proposed system is feasible for an available computing setup; while the converse of this will be viewed as an imple mentation issue, namely, what algorithm (within a process) should be adopted to opti mise efficient usage of available resources.
Irrespective of whether this is viewed as an analysis or implementation issue, and irre spective of whether this information is determined manually by the system developer or by some automated means, the paradigm should allow Objects the (optional) ability to convey this information to the system.
7) The ability to incorporate existing software applications that do not conform to the OOPP model in new systems being developed under the OOPP model.
The ability to request a group of processors in a specified architecture presents another opportunity. Existing software applications being heavily reliant on machine architecture and currently run on existing parallel machines could easily be incorporated into Object-Oriented Parallel Paradigms. This can be accomplished simply by treating the application as an Object providing various Services. On implementation level, one pos sible solution will be to create an Object that actively or passively interfaces the system (developed based on OOPP) with the existing application (developed based on some specific Architecture). Developing a system under this scenario is superb since existing applications do not have to be rewritten simply because they are not Object-Oriented. (The sacrifice we will be making when incorporating existing applications is that we will have to accept them as is without being able to introduce any improvements that may have been detected if we had used Object-Oriented Analysis).
Furthermore, Object-Oriented Parallel algorithms will be able to isolate an architectu re/hardware dependent algorithm into a single Object (or group of Objects). Thus even though a traditional algorithm may be strongly dependent on a specific architecture, this algorithm may be encapsulated in a single Object. Should we wish to migrate our system onto a new machine, we can immediately identify existing architecture-dependent algo rithms that will suffer from such a transition and simply rewrite them (and/or their Objects).
May 1994 C Kyriakides Page 214 Object-Oriented Parallel Paradigm Objed-Oriented Parallel Paradigms (OOPP)
9.700PP's Proposal
Amongst other things, parallel processing has been compared to an assembly line in a factory [Quinn 1987]: a component enters the assembly line at one end and as it progresses down the line work is done on it to form a more complete component; what exits out the other end is the completed component. The parallel processing (pipeline) analogy arises out of the fact that while work is done on a component at one stage of the assembly line, the other stages are busy with other components. This analogy made the concept and benefits arising from parallel systems easier to comprehend. In view of this fact, we have opted for utilizing another analogy to describe the hierarchical structure of OOPP; namely, the manager-employee relationship encountered in the business world.
This should not be confused with the client-server model. For the moment, one primary distinction lies in the fact that within the manager-employee relationship only one of the two parties con cerned (namely, the manager) can request the dynamic creation or destruction of the other party (the employee). While, in the client-server model, the client requests the creation of the server; however, the server in one message exchange can be a client in another message exchange. No exchange of roles can take place under a manager-employee relationship.
Managers, sub-managers and employees are all Objects in a hierarchical structure. Employees are the primary Objects for processing workloads. Managers (and their sub-managers) are responsible for managing the manager's allocated employees. A manager may effect the destruction or cre ation of a sub-manager or employee that will be placed under him. An employee or sub-manager however, cannot effect the destruction or creation of his manager. In fact, an employee cannot exist independent of his manager and hence cannot effect his manager's creation or destruction. Also before a manager can be destroyed, all his sub-managers and employees must first be either reassigned to another manager or destroyed. This rule eliminates the need for garbage collection; unlike the Demeter system proposed by Lieberherr [1988, 1989] which relies on garbage collection.
9.7.1 Resource Usage Data
Every Object that has the capability to create and/or destroy other Objects directly will require knowledge (or access to knowledge) regarding the current usage of resources so as to
May 1994 C Kyriakides Page 215 Object-Oriented Parallel Paradigm Objed..()riented Parallel Paradigms (OOPP)
facilitate an efficient Object-to-Processor mapping. We shall refer to this information as Resource Usage Data (RUD). In effect, the RUD will contain information pertaining to the current status of each resource in a machine (or in a network of machines).
Every time an Object is created or destroyed the information contained in the resource usage data (RUD) needs to be updated. Thus duplication of the RUD, is highly undesirable. Hence, it is implied that not every Object should have a copy of the ROO in its internal data. However, on the other extreme of the scale, if the parallel system's ROO is kept in one individual Object, then a situation similar to the bottlenecks of global memory architectures will result. All Objects attempting to create or destroy other Objects will require mutually exclusive (update) access to the RUD. If access to the RUD is not mutually exclusive then two Objects may simultaneously attempt to engage an available resource - both thinking they have gained access to the resource - may then incorrectly update the ROO info. Furthermore, in the case where the resource cannot be "unexpectedly" shared (e.g., RAM), one or both of these Objects will eventually crash (as the one violates the data of the other). Clearly the single Object RUD scenario is also inadequate for all but the small-scale parallel Object Oriented systems. Intuitively the answer must lie somewhere between these two extremes. Before presenting a solution to the RUD problem, let us concentrate on another closely related issue; namely, should all Objects have the capability to create or destroy other Objects?
9.7:2 Resource Sets
At this stage we will define a resource set to be the set of all resources present within the confines of a physical machine; including resources directly coupled to the said machine that are incapable of useful operation without the link (e.g., this includes external hard disk drives; but excludes other computers coupled via a network link).
Dumb terminals and multiplexed units tend to form the boundary zones of this definition. Although dumb terminals can operate normally (in a dumb, non-intelligent fashion) without the presence of the link, they are of no use to a user. Hence, in order to be a useful member of the system, dumb terminals cannot exist independently of the machine they are attached to. Thus under a "useful" mode of operation, dumb terminals do not have their own resource set; instead, dumb terminals are resources belonging to another machine. A similar argument holds for multiplexed units.
May 1994 C Kyriakides Page 216 Object-Oriented Parallel Paradigm Objed-Oriented ParaDel Paradigms (OOPP)
We made use of this deftnition when describing OOPP's networking capabilities in section 8.6.
9.7.3 Object Create/Destroy
If every Object had unrestricted ability to create or destroy other Objects then any attempts to introduce some sort of order to resource management is bound to failure. The complexity here is caused by the dynamic creation of new Objects. In turn, these new Objects have the capability to create or destroy other Objects. Thus at best, any resource management predic tions implemented under this scenario will be valid for a very limited number of processor steps. Furthermore, Objects under this scenario would create bottlenecks by competing for access to the RUD.
Another problem that may be encountered under this scenario is that an inactive Object suitable for destruction may exist for which no active Object has access to or knowledge thereof so as to facilitate its deletion. (The creator of the Object in question could have been destroyed while the particular child Object was active). This will necessitate garbage collection in order to detect and remove "lost" Objects.
Clearly some form ofrestrictions must be incorporated on the creation and destruction ofObjects.
9.7.4 Manager-Employee Scenario
In order to present the fundamental idea of OOPP pertaining to the RUD and Object crea te/destroy dilemma, let us make use of the Manager-Employee scenario.
9.7.4.1 Hierarchical Structure or Model
The multi-person businesses that have evolved over the years have resulted in a division of duties between management and non-management staff. A manager may have sub managers working under him/her and so forth. At the top of the pyramid, there is one managing director or board of directors. At the bottom of the pyramid, there is the staff entitled to no managerial capabilities (i.e. may not hire or rue any other employee). Managers on the other hand, have the ability to hire (create) and rue (destroy) employees, (although this task is sometimes delegated to the personnel manager by one of the other managers).
May 1994 C Kyriakides Page 217 Object-Oriented Parallel Paradigm Object-Oriented Parallel Paradigms (OOPP)
9.7.4.2 Managerial Duties
In order to accomplish his duties a manager has to be aware of certain information regarding the status of the company in the concerned manager's area of interest. This information may include allocated staff, budgets, deadlines, etc., and is passed to him from his superior. Should the concerned manager's division be large enough, he may appoint project-Ieaders/sub-managers to work under him and thereby pass some of his managerial responsibilities onto his sub-managers. The new sub-managers may come from his allocated staff or, if his budget permits, may employ them from the unemployed sector.
In the management structure, all employees will have certain information accessible in one of three modes: either upwards, downwards, or in both directions. For example, info regarding an employee's capabilities, current workload, past performance, salary, etc., should be exclusively upward accessible. While delegated duties, etc., should be exclusively downward accessible. Names, position in structure (relative to the particular employee), office number, etc., should be accessible from both directions.
During Message passing, delegated duties to Objects could be associated with deadlines and the manager could keep track of the responses returned. Should a response be over due, the manager can force a best-so-far response, educated guess, etc.; or alternatively, terminate the process with the appropriate cleanup actions. This feature can prove to be invaluable in real-time process control.
9.7.4.3 Division of Managerial Duties
The topmost manager should be responsible for allocating and updating his private copy of crucial information (such as budgets, human resources, productivity, etc.) budgeted to the various departments in his company. Each manager should thus know what total number of any particular resources were allocated to him, and which of those resources he still has available/unused. A manager may then allocate some of his allocated resources to one of his sub-managers situated directly below him in the manager-employee hierarchy, or may free some of his resources and pass them back up the tree to his super-manager.
May 1994 C Kyriakides Page 218 Object-Oriented Parallel Paradigm Object-Oriented ParaDel Paradigms (OOPP)
A manager may operate autonomously within his own allocated resources without the constant need to communicate with his superior manager(s). Should the allocated resources prove insufficient, the manager in question can request one of his sub managers to release some of their allocated resources. Should the sub-managers not have sufficient resources to satisfy their super-manager, the manager will have to request allocation of additional resources from his super-manager.
In order to maximise the autonomy of each manager, all requests for additional resources should be made in a depth-first fashion. If instead, requests for additional resources were initiallydirected upwards, then (in a system in which most of its resources are being used), the topmost manager will present a bottleneck. This is obviously a disadvantage as such a system may in fact be executing near its peak capabilities.
The primary reason for requesting sub-managers to free resources prior to requesting the super-manager to free resources lies in the fact that we want a manager to achieve the greatest degree of freedom within his allocated resource set. Furthermore, we do not want to burden the super-manager with requests for additional resources. This is important as, in this scenario, it would be possible for a manager to have a large number of sub managers all simultaneously requesting resources and thereby creating a bottleneck. Also if the requests where initially made to the super-manager and he did not have enough resources to satisfy the request then he would in tum route the request to his super manager; the autonomy of each manager would thus be violated. Furthermore, in a situ ation were resources are not available in all the sub-managers of a particular super-manager, the request would eventually be routed through to the topmost-manager. It is easy to see that the managers near the top of the structure present a bottleneck in a system in which most of its resources are being used.
9.8 Summary: Oblect-Orlented Parallel Paradigm
Below we present a brief overview of OOPP primary features:
OOPP's primary goal
Blend Object-Oriented and Parallel Systems into one homogeneous body.
May 1994 C Kyrialddes Page 219 Object-Oriented Parallel Paradigm Objed-Oriented Parallel Paradigms (OOPP)
OOPP's .primary innovations
Object Taxonomy
Manager-Employee scenario
Inheritance extended to concurrent features of Objects
Distributed ResourceManagement
Object Taxonomy
Unique and Multiple Objects
Granular and Non-Granular Objects
Internal concurrency of Objects (Method related)
Method-Intemally-Concurrent Objects
Method-Internally-Sequential Objects
Method-Extemalty-Concurrent Objects
Method-Externally-Sequential Objects
Internally-Sequential Objects Method-Internally-Sequential, AND Method-Externally-Sequential.
Internally-Concurrent Objects Method-Internally-Concurrent, OR Method-Externally-Concurrent, or both.
External concurrency of Objects
Mutually-Sequential Objects
Mutually-Concurrent Objects
Externally-Sequential Objects An Object Mutually-Sequential to all other Objects.
May 1994 C Kyriakides Page 220 Object-Oriented Parallel Paradigm Objed"()riented Parallel Paradigms (OOPP)
Extemally-Concutrent Objects An Object Mutually-Concurrent to at least one other Object.
Exclusively-Sequential Objects Externally-Sequential, AND Internally-Sequential
Resources
Two primary resource types:
Hardware resources: manual/static creation/deletion Software resources (Objects): automated/dynamic creation/deletion
Resources are grouped into Resource Sets and Subsets.
No resource can be accessed if it does not belong to a Resource Set.
Resource information is stored in the Resource Usage Data (RUD). Each Resource Set has its own RUD.
Managers
Managers are Objects
Hierarchical structure with Inheritance
Each Resource Set must be uniquely allocated to a Manager; however, a Manager may manage one or more Resource Sets.
Responsibilities:
Keep track of available resources
Add resources
Delete resources
Relocate resources
Monitor resources
May 1994 C Kyrialddes Page 221 Object-Oriented Parallel Paradigtn Object'()riented Parallel Paradigms (OOPP)
Inheritance extended to Object Taxonomy classification
By default, Objects belonging to the same class will exhibit similar concurrency charac teristics.
Distributed Resource Management
Minimises resource allocation bottleneck for large systems
Greater autonomous mode of operation within allocated resource sets.
May 1994 C Kyriakides Page 222 oozr and COOP Objed-Oriented Parallel Paradigms
10 OOPP and COOP
Recall from chapter 2 that according to their definitions, Parallel and Concurrent Processing differ only in regards to the number of distinct problems being solved concurrently. Analogously, Object Oriented Parallel Processing (OOPP) is aimed at solving a single problem, while Concurrent Object-Oriented Processing (COOP) is aimed at two or more problems. In this section we attempt to illustrate that OOPP's area ofapplication is extendable to COOP's area of application.
10.1 OOPP-scenario
Before continuing, we require to make the following definition:
An OOPP-scenario is defined to be: any group of Objects whose anatomy depicts an OOPP Manager-Employee relationship and, where all communication outside this group is required to take place via the "topmost" manager of the group. Furthermore, no communication is allowed outside the OOPP-scenario except for resource management related messages, (these messages include obtaining access to, as well as, input from and output to a resource).
For the time being, the OOPP-scenario defmition can be easily understood from the perspective of the Two-Tier Approach; in this case, the manager acting as the "topmost" manager of the OOPP-scenario is distinct from any other Object in the scenario. (The implications of using the Direct-Inclusion Approach will be elaborated later on in chapter 11).
One important point enclosed in the definition is that an OOPP-scenano conforms to the OOPP characteristic of solving only one problem; OOPP-scenarios are distinct groups of connected Objects which form OOPP manager-employee hierarchies - each hierarchy responsible for solving one problem.
The "topmost" manager of an OOPP-scenario is effectively the only link to the outside world (for the time being, please note that the topmost manager's positioning in a manager-employee rela tionship will be readdressed in section 113). If all the "topmost" managers of the various OOPP scenarios are placed under a special manager (or a hierarchy of special managers) then we effectively transform the multiple OOPP-scenario modeJ to a general OOPP model. However there is one major difference: the only communication allowable between these special managers and the "topmost" manager of an OOPP-scenario has to be communication by messages pertaining to resource management (including handling contention of and I/O operations on the shared resources). From here on, these special managers managing OOPP-scenarios will be called special
May 1994 C Kyriakides Page 223 oOPP and COOP Objed-Oriented ParaDel Paradigms
OOPP-scenario managers. The methods for handling these contentions will reside in the special managers. Also, in order to maintain the integrity of the distinct ("functionally-isolated") problems being solved, no communication can be allowed directly or indirectly between the "topmost" managers of any two OOPP-scenarios. All requests by an OOPP-scenario for resource allocation or usage will have to be handled by the special OOPP-scenario manager(s). Furthermore, in essence, each OOPP-scenario will solve a single problem that is independent of all other problems solved simultaneously. From the above, it follows that within the guidelines laid down by the definition of an OOPP-scenario and by making use of special OOPP-scenarlo managers, OOPP's area of application is amenable to COOP's area of application.
As an example, assume you have two or more distinct problems that are to be solved concurrently on the same machine. Initially, the machine's resources are represented by a single Resource Set (discussed in section 9.7.2). For the moment assume that we have devised an algorithm for sub dividing the machine's Resource Set into the appropriate subsets. In this case each of the subsets can be allocated to its respective OOPP-scenario solving a single problem. We have thus reduced the COOP-scenario to several OOPP-scenarios.
However, a complication exists with the subdivision of the original Resource Set. Assume that the Resource Set contains one critical resource (e.g., one hard disk) that needs to be fairly shared amongst the various OOPP-scenarios. The subsets created will in this case be required to have common members. The issue that arises here is that each OOPP-scenario will have to coordinate its access to the common resource. What is important to note here is that since each OOPP problem is distinct ("functionally-isolated") from every other OOPP problem being solved, each OOPP-scenario should endeavour to be "Message-isolated" from every other OOPP-scenario. This implies that no Messages should be sent directly between any two OOPP-scenarios. H we fail to conform to this policy then our model may become susceptible to weak encapsulation of OOPP scenarios; and furthermore, the performance and reliability of one OOPP-scenario may have repercussions on one of the OOPP-scenarios it communicates with. The dilemma that now arises is that if we cannot send any Messages between any two OOPP-scenarios then how do we manage the synchronisation of processes attempting to access a shared resource?
Since the responsibility for managing resources (and access to shared resources) is left up to the special managers, we have to make available a set of allowable Messages between the OOPP scenario topmost managers and the special managers so as to interface the two together. Because any two OOPP-scenarios are "functionally unrelated" and, any group of OOPP-scenarios can be
May1994 C Kyriakides Page 224 oore and COOP Objed-Oriented Parallel Paradigms
chosen to be executed on the system concurrently, we can deduce that OOPP-scenarios must also be "analytically unrelated". Thus the internal analysis of the OOPP-scenario should be hidden from the special managers and other OOPP-scenarios. Instead, only the resource requirements of the OOPP-scenario can be made available to the special managers for resource management pro cessing. Furthermore, in the case of shared resources, the special managers will be burdened with the responsibilityof ensuring that no OOPP-scenario can gain access to a time-slice/portion of the resource that belongs to another OOPP-scenario. The special managers under this context take on the form of Operating System based Objects (or service providers).
From the above, it is thus clear that OOPP can also facilitate COOP. Furthermore, OOPP's area of application is extendable to COOP's area of application; which is the point we set out to achieve in this section.
10.2 Unanswered OOPP and COOP issues
What has not been discussed here is the procedure for determining the Message interface between OOPP-scenarios and the special resource managers. As far as we are concerned at this stage, the special managers discussed here are nothing more than the special resource managers discussed in section 8.5.
Clearly the encapsulation of internal analysis in the OOPP-scenarios will necessitate special treatment for these special resource managers. One option is to define a standard interface for each type of special resource (e.g., monitors, storage media, printers, etc.) where upon start-up the devices are tested or interrogated to determine what basic options are available on a particular resource. (We personally prefer the ease of the interrogation option, unfortunately current day hardware resources - e.g., monitors, hard disks, etc. - are not intelligent enough to identify and fully describe themselves. Instead, today's computers generally rely on the "absence-to acknowledge" syndrome for checking the presence of resources). In any case, this and other similar issues will be left over to future research.
10.3 Summary: OOPP and COOP
An OOPP-scenario conforms to OOPP's manager-employee relationship and (like OOPP) is also aimed at solving a single problem. Furthermore, OOPP-scenarios existing on or using common resources are "functionally-isolated" from each other. In addition, with the aid of OOPP-scenarios,
May 1994 C Kyriakides Page 225 ooer and COOP Objed-Oriented Parallel Paradigms
OOPP's area of application is extendable to COOP's area of application. In general, the Object Oriented Parallel Paradigm (OOPP) can cater for Object-Oriented Parallel and Concurrent Pro cessing; thus, unless otherwise specified, the term OOPP embodies both OOPP and COOP.
May 1994 C Kyriakides Page 226 A Brief Overview of Managers Objed-Oriented ParaDel Paradigms
11 A Brief Overview of Managers
In this chapter we present a brief overview on OOPP's managers taking into account a number of terms that were not defined prior to the earlier chapter on Managers. For the sake of brevity, we will not address all possible issues pertaining to OOPP Managers.
11.1 The Two Tier Approach
As mentioned previously, the Two-Tier Approach to depicting the manager-employee relationships results in the creation of two distinct hierarchies: one hierarchy for managers and one hierarchy for employees.
--....~ Inheritance Relationship ------Manager-Employee Relationship
Implicit Manager-Employee Relationship Furthermore, two types of relationship exist: one being the inheritance relationship within the hierarchies; the other being the management relationship between a manager (in the manager hierarchy) and an employee (in the employee hierarchy).
In general, a hierarchy depicts more general cases at the top of the hierarchy and, as We progress towards the bottom of the hierarchy, more specific cases are encountered. Since both managers and employees are depicted in terms of hierarchies, more general cases will be encountered at the
May 1994 C Kyrialddes Page ZJ.7 A Brief Overview of Managers ObJed-Oriented ParaDel Paradigms
top while more specific cases will be encountered at the bottom of each hierarchy. Thus it is reasonable to assume that in the employee hierarchy, employees belonging to a common super class will exhibit similar processing characteristics. Similarly, it is reasonable to assume that in the manager hierarchy, managers belonging to a common superclass will provide similar management services. Thus, in general, for any manager-employee relationship where M represents the man ager and Erepresents the employee, it is reasonable to anticipate that employees belonging to 'a subclass of E should be managed by either the same manager that is managing E or a manager belonging to a subclass of M.
Please note that in the Two-Tier Approach to depicting manager-employee relationships we refer to these relationships in terms of manager classes and employee classes. In an implementation however, it is the instances of those managers that will manage one or more instances of those employees. From an analytical perspective, it is simpler to conceptualise these manager-employee relationships in terms of classes.
11.2 The benefits of Indirect Message Passing within the Two-Tier Approach
In this section we briefly present a number of benefits that may arise by implementing a form of indirect message passing within a Two-Tier model.
One of the simplest ways to illustrate this is by example. Let us assume that we are dealing with a problem domain involving an earth-based laboratory computer network and an earth orbiting satellite. Owing to the limited electrical power and computing facilities available in the satellite, data requiring heavy processing (such as data used for weather prediction) is gathered by the satellite and sent to the earth-based network for further processing.
We will now make use of an overly simplistic model that is nonetheless sufficient to illustrate our argument. From an analytical perspective, Object OWeatherlnfonnationCollector (the object responsible for gathering weather related information of the earth) needs to send this information to the earth based object OWeatherPredictor (the object responsible for predicting the weather). From an implementation perspective in the OOPP, it is clear that object OWeatherlnfonnation Collector will require to send this information via a Special Communications Manager situated in the satellite to a Special Data Communications Manager situated in the earth-based laboratory. If desired, prior to transmission this data may be sent by the Special Communications Manager to a Data Compression Manager for compressing; in this case, the receiving Special Communications
May 1994 C Kyrlakides Page 228 A Brief Overview of Managers Objed-Oriented Parallel Paradigms
Manager in the earth-based laboratory will require to send the incoming data to a Data Com pression Manager for decompressing. The decompressed data is then forwarded to OWeatherPre dictor. From an analytical perspective however, the fact remains simply that OWeatherlnfonnationCo1lector needs to communicate with OWeatherPredictor, nothing more and nothing less. The fact that for realistic performance times it may be necessary to compress data prior to transmission or that data may need to be encrypted for security purposes remain imple mentation issues. By encapsulating the NAIRs within the managers and the AIRs within employees (such as OWeatherlnjonnationCollector and OWeatherPredictor) we are able to insure that nonAnalytically induced aspects are deferred to the implementation stage.
U the Two-Tier manager-employee approach and related NAIR/AIR reasoning was not used, a proposed "analytical" model would have been more tolerant to the introduction of NAIRs.
Lastly, let us consider another example where the services of a number of data compression algorithms are required by different objects within a model. The responsibility for data compres sion rests with the Data Compression Manager; however, the particular data compression algo rithms form part of the NAIR of the Data Compression Manager. Thus using one possible approach, the Data Compression Manager could encapsulate each algorithm as a separate method. Since the Data Compression Manager has two or more choices with regards to choosing an appropriate algorithm, the Data Compression Manager's responsibilities could include deter mining the most appropriate data compression algorithm (say based on pre-existing knowledge or statistical information). However, by using another possible approach, if each data compression algorithm was encapsulated in a separate "service provider", then the responsibility of the data compression manager would include to select the most appropriate data compression algorithm; the appropriate "service provider" is then given the responsibility of the actual data compression. The last form of managers depicting a redistribution of responsibilities to service providers appears to present a more logically sound approach; if a large number of separate data arrives to be processed by the Data Compression Manager, then the Data Compression Manager only determines which data should be directed to which service provider. Clearly, only multiple instances of the required service provider will be created to cater for the additional demand. Whereas, if all data compression algorithms were encapsulated within the same Data Compression Manager then although each instance could have several data compression algorithms only one could be used at any time.
May 1994 C Kyriakides Page 229 A Brief Overview of Managers Objed-Oriented Parallel Paradigms
11.3 Managers of OOPP-scenarios
To recap, an OOPP-scenario conforms to OOPP's manager-employee relationship and (like OOPP) is aimed at solving a single problem. It was furthermore shown that using OOPP scenarios, OOPP's area of application can be extended to COOP's area of application. As a consequence of their definition, OOPP scenarios are "functionally-isolated" from each other. The responsibility of ensuring that two or more OOPP scenarios are "functionally-isolated" rests on special OOPP-scenario managers. These special OOPP-scenario managers restrict communication going in and coming out of an OOPP-scenario to resource access and allocation requests, as well as, ensuring that no OOPP-scenario can gain access to a time-slice/portion of a shared resource that belongs to another OOPP-scenario.
It was furthermore mentioned that in OOPP-scenarios the "topmost" manager of the OOPP scenario provides the only link to the outside world. In the case where a number of OOPP scenarios require access to one or more common resources their "topmost" manager can communicate with the manager managing the shared resource(s); although, in order to maintain "functional-independency", this communication is restricted to resource access and resource allo cation requests.
11.4 Is it possible to have more than 1\vo-Tiers?
In this section we will show that it is possible to have a Three-Tier Approach within OOPP. The Three-Tier Approach is in essence a Two-Tier Approach where the managers of the Two-Tier Approach are themselves managed.
Before moving into this new argument, we recall the reader's attention that managers can encapsulate nonAnalytically Induced Responsibilities (NAIRs) from Analytically Induced Respon sibilities (AIRs). Furthermore, it was mentioned that an AIR in one problem space can exist as a NAIR in another problem space. Thus, it should come as no surprise if we mention that the next paragraphs will show that the range of manager-employee relationships expressible within OOPP can be larger than Two-Tier.
As mentioned above, in general, any manager-employee relationship expressed in terms of the Two-Tier Approach can be represented by a hierarchy of managers and a hierarchy of employees. Furthermore, a management-employee relationship was revealed between the classes of the two hierarchical structures. Let us refer to the managers of the Two-Tier Approach as first-level
May 1994 C Kyriakides Page 230 A Brief Overview of Managers Objed-Oriented Parallel Paradigms
managers; while, managers that manage first-level managers will be referred to as second-level managers, and so on. Clearly, if the managers themselves are managed, we could anticipate an additional manager hierarchy comprising of second-level managers, however, this time the objects managed are the first-level managers. Furthermore, the hierarchical structures of the second-level managers and the first-level managers should exhibit an analogous manager-employee relationship based on the classes in the hierarchies.
If we again reconsider the case of two or more OOPP scenarios requiring access to a shared resource, it becomes evident that at least two levels of management exists: one within the OOPP-scenario (between the managers and the employees of the OOPP-scenario); and the other between the special OOPP-scenario manager (controlling the access to the shared resources) and the OOPP-scenarios (requiring access to this shared resources). Thus by proving that OOPP's area of application was equivalent to COOP's area of application, we indirectly showed that more than Two-Tiers may exist in manager-employee relationships.
In fact an additional management level exists within the OOPP-scenario itself between the "top most" manager and the other managers in an OOPP-scenario. To elaborate, the "topmost" man ager restricts the communication going in and coming out of an OOPP-scenario to resource access requests and resource allocation requests; thus, a manager requiring additional resources to be allocated to it will request the "topmost" manager to grant it access to the resources it requires. (If the "topmost" manager does not have sufficient available resources to meet this request it may then forward this request to a higher manager - in this case, the special OOPP-scenario manager outside the OOPP-scenario). It is thus dear that the "topmost" manager is responsible for managing the managers which manage the employees in the OOPP-scenario. The "topmost" manager's responsibilities include controlling incoming and outgoing resource allocation requests. Unlike the special OOPP-scenario managers however, the "topmost" manager is Dot responsible for ensuring that no other OOPP-scenario can gain access to its time-slice/portion of a shared resource).
As promised, we will now describe the position where the OOPP-scenario's "topmost" manager is located. Please note that the "topmost" manager is not the manager situated at the top of the first-level manager hierarchy, but rather, the manager situated in the second-level manager hier archy that is responsible for managing all first-level managers.
May 1994 C Kyriakides Page 231 A Brief Overview of Managers Objed-Oriented ParaDel Paradigms
In order to avoid unnecessary and premature complexities, it should be self-evident at this stage that, for the sake of simplicity we assumed an OOPP-scenario containing only three tiers; in fact, any OOPP-scenario could contain more than three tiers - depending on how the problem domain of each tier was formulated.
11.5 How are the TIers determined?
In this section we briefly describe how the various levels of manager-employee relationships can be determined.
As mentioned previously, managers can be used to encapsulate NAIRs from AIRs. Furthermore, the NAIRs in one problem domain may be AIRs in another problem domain. Thus at a first-level manager-employee relationship, the employees encapsulate AIRs dealing with the particular problem domain, while managers deal with the problem of managing those employees. In a second-level manager-employee relationship, the second-level managers deal with the problem of managing the first-level managers, and so on.
As it becomes immediately evident, in a Multi-Tier model, the problem domain at each level is different to the problem domain at other levels - thus the AIRs and NAIRs of one level are different to the AIRs and NAIRs of other levels. Furthermore, the NAIRs of one level more or less correspond to the AIRs of the level immediately above it. Likewise, the AIRs of one level correspond to the NAIRs of the level immediately below it.
In any given problem domain, as we move up the various levels, the problem domain of each level becomes more and more analytically independent of the original problem domain. Thus we can reasonably anticipate managers situated at progressively higher levels to be progressively more ana lytically independent of any given original problem domain. Thus managers targeted to managing general-application objects (e.g, operating system based managers such as MITRE's agents) should be encountered at higher levels than managers targeted at more specific applications. The higher a manager is situated the further the manager is removed from the given problem domain.
In essence, each tier deals with a particular problem domain. The employees - in the lowest tier - deal specifically with the problem given. The managers, situated one tier above the employee tier, deal with the problem of providing managerial services to the employees in the lower tier. This manager-employee relationship holds as we progress up the tiers such that in any two-tiers the objects in the top tier act as managers for the objects in the lower tier, the employees.
May 1994 C Kyriakides Page 232 A Brief Overview of Managers ObJed..()mnted Parallel Paradigms
The only exception to this occurs in some cases where it may be preferable to provide services to the manager tier. However, as will be explained shortly, the services can be provided in objects existing in tier (separate from the manager tier and employee tier) which will bereferred to as the service provider tier. Nonetheless, as will be seen, the service tier is also viewed as being managed by the manager tier. (Although no distinction is currently apparent prohibiting us from calling the service provider tier an employee tier, for the sake of future research efforts below we will present a rough guideline to distinguishing a service provider tier from an employee tier.)
11.6 How are the Tiers positioned?
In this section we will briefly describe two possible ways in which the Tiers may be positioned. It is dear that the most obvious possibilities arc that some tiers may be "stacked" one on top of the other (analogous to stacked pieces of paper), or "paved" next to each other (analogous to floor tiles). For the sake of simplifying our discussion we will make use of the terms stacked and paved.
Recall the Two-Tier Approach presented in section 11.1. The manager and employee hierarchies are depicted as one tier containing the manager hierarchy and the other tier containing the employee hierarchy; for the sake of brevity, we will refer to these tiers as the manager-tier and the employee-tier, respectively. The manager-tier is then stacked on top of the employee-tier. Thus, manager-employee relationships are represented by stacked tiers.
Recall the OOPP-scenario example presented in section 11.3. In this example it was shown that the "topmost" manager of the OOPP-scenario was responsible for managing the managers at a lower level which were in turn responsible for managing the employees. Thus, in this example, three tiers exist depicting managers at one level being managed by managers at another level. In this case, the three tiers arc stacked one on top of the other.
Recall the satellite example presented in section 11.2. Two possibilities were presented for the format of such Data Compression Managers.
In the first case, a Data Compression Manager could facilitate compression services by encapsulating one or more data compression algorithms within its methods - in the case, of more than one data compression algorithm being present, the Data Compression Manager could select the appropriate method to call. It is clear, that in the rust case, only two tiers exist where one tier is stacked on top of the other.
May 1994 C KyriaJddes Page 233 A Brief Overview of Managers Objed'()riented Parallel Paradigms
In the second case, the Data Compression Manager also selects the appropriate data com pression algorithm, however, in contrast to the first case, thisData Compression Manager caI1s on a "service provider" to data compress on its behalf, What must be noted here, is that the Data Compression Manager acts both as a manager providing data compression facilities for other managers in that same tier, as well as, being responsible for managing the data com pression "service providers". Note that, some of these other managers - at the same tier level as the Data Compression Manager - are responsible for managing employees at a lower tier. Thus, two management relationships exist: one between other managers and their employees; and another between the Data Compression Manager and the data compression "service pro viders". (It is thus not appropriate to stack these three tiers one on top of the other since only one tier acts a manager tier.) Since the data compression "service providers" are managed by the Data Compression Manager, it follows that the "service provider" tier is at the same level as the employee-tier. (Note, the "service providers" and the employees are not in the same tier). In other words, the "service provider" tier is paved next to the employee-tier.
Manager-Employee Relationship
ServiceProviderHierarchy
Two-Tier Approach exhibiting stacked and paved tiers
May 1994 C Kyriakides Page 234 A Brief Overview of Managers Objed'()riented Parallel Paradigms
In general, if any two tiers are managed by the same tier then those tiers are said to be paved with regards to each other. Please note that the term paved is only available to assist discussion. Any two paved tiers can only communicate and/or interact via their common manager tier. From an analytical perspective, no two paved tiers are "aware" of each other. Furthermore, from an implementation perspective, a tier is only aware of its immediate lower-tier and immediate higher-tier; it is not aware of any other tiers including tiers that are "paved" with regards to it.
In an oopp model any number of stacked and paved tiers may exist in any combination obeying the guideline that any manager-employee relationship must be represented by stacked tiers.
11.7 Are Managers Service Providers?
In this section we will briefly indicate that the term "managers" in oopp could have been replaced by the more sweeping term of "service providers".
In section 8.9, it was mentioned that OOPP was not intended to rigorously follow the anthropo morphic view of manager-employee relationships; thus, a number of responsibilities of computer based oopp managers do not concur with the responsibilities of real-life managers. It was furthermore stated that a more sweeping terminology for describing managers' responsibilities could have been used, namely service providers; in this case, we could talk of management service providers, communication service providers, interface service providers, and so on. We justified using the term managers, in that it immediately discloses the dominant role of oOPP's managerial responsibilities; furthermore, although we "conceptually" deviate from this anthropomorphic per spective, in addition to providing managerial services to their employees, manager objects can indirectly also provide other services to their employees. These services are not directly provided by the managers themselves but are provided by "service providers" situated in a tier below the manager tier.
As promised we will now state the rough guideline between a service provider tier and an employee tier. Firstly, an employee tier deals with "analytically" solving a given problem. In essence, an employee requests processing input only if the analytical perspective of its particular problem domain requires it to do so. Secondly, a service provider tier deals with the problem of providing general type services required so as to "implement" the given problem. A service provider does not request processing input but simply processes it when available. (As we mentioned this is only a rough guideline and may have a number of exceptions. For example, it is Dot easily appli cable if the given problem is in fact to provide a general implementation service.) Nonetheless, at
May 1994 C Kyriakides Page 235 A Brief Overview of Managers Objec:t-Oriented Parallel Paradigms
this stage of the OOPP research, from a manager-employee relationship it does not appear that we require to specificallystate whether a tier is a service provider tier or an employee tier - both are managed by a manager tier.
It should also be noted that in addition to managers simply providing managerial services to their employees, OOPP's manager-employee concept enables system developers to encapsulate NAIRs from AIRs. The NAIRs can be encapsulated within managers, while the AIRs can be encapsulated within employees. Clearly the term service providers would also not fully describe the OOPP manager concept.
11.8 Unaddressed Issues
At this stage of our research we cannot see any reason why any feature of other Object-Oriented models cannot be facilitated within the OOPP model. However, Unaddressed issues have been left over to future research efforts. One such example is that of multiple inheritance. In its current form, OOPP can address multiple inheritance. It should be noted at this stage that inheritance relationships are exhibited between objects within a tier; in contrast, manager-employee rela tionships are exhibited between objects in two different tiers. Furthermore, it was shown that the manager-employee relationship exhibits a correlation between the manager inheritance structure and the employee inheritance structure. The question that needs to be addressed in future research efforts is to what extent inheritance in an employee tier and inheritance in a manager tier correlate. For example, to what extend (if any) will multiple inheritance in an employee tier manifest as multiple inheritance in the manager tier?
11.9 Conclusion: Overview of Managers
To briefly recap, it was noted that in addition to more general Object-Oriented relationships such as inheritance - OOPP also facilitates an additional relationship referred to as the manager-employee relationship. Under a manager-employee relationship, one object (the man ager) provides managerial services to the other object (the employee). OOPP managers and employees form "separate" Object-Oriented hierarchies located at different "conceptual" levels called tiers. Tiers in any manager-employee relationship are stacked (with regards to each other). In any two stacked tiers, the managers (in the top tier) provide managerial services to their employees (in the lower tier).
May 1994 C Kyrialddes Page 236 A Brief OveIView of Managers Objed-Oriented Parallel Paradigms
By making use of managers, it is possible to encapsulate the nonAnalytical Induced Responsibi lities (NAlRs) from the Analytical Induced Responsibilities (AIRs). In fact. it is self-evident that as illustrated (e.g., by using the satellite example), OOPP can effectively provide a mechanism whereby the implementation aspects of a problem can be encapsulated from the analytical aspects (addressed within the employee tier). Furthermore, each tieraddresses a panicularproblem domain and AIRs in one problem domain may be NAIRs in another problem domain.
Two tiers managed by the same "immediate" manager tier are said to be paved with regards to each other; note however that, the paved term is used to aid discussion only since two tiers that are paved with regards to each other are not aware of each other and thus cannot communicate. A typical example of two tiers been paved with regards to each other, was presented above where one tier the employee tier addresses the problem at hand, while the service tier provides services to the managers of the employees. The only wayan employee object can give rise to processing in a service provider object is indirectly via their common manager tier. Thus from an analytical perspective paved tiers are also analytical1y independent of each other.
May 1994 C Kyriakides Page 237 Supporting Papers Objed-Oriented Parallel Paradigms
12 Supporting Papers
During the conception of the basic ideas encapsulated in OOPP, no articles could be found in support of such a methodology. However after an arduous research effort aimed specifically at finding papers in support of any similar methodology, the article presented below had been found.
The initial proposal for OOPP was left in its original form as we believe it to be most easily com prehendible. We have opted for an evolutionary approach to describing the variations introduced by the below-mentioned article. The reason for this is that the initial proposal is simple to understand, and the modifications introduced by the under-mentioned article will make certain fme-tunings of our proposal more easy to appreciate.
12.1 MITRE's Future Generation Computer Architectures Program
MITRE's research (as described in the Bensley [1989] paper) is directed toward operating systems for massive distributed-memory MIMDs running general-purpose, Object-Oriented programs.
The MITRE research specifically concerns distributed techniques for resource management, Object addressing, garbage collection, and computation management. The research was constrained to techniques that do not require centralisedcontrol or global information; and can be made tolerant of hardware failures.
The model of computation adopted by the MITRE research is Object-Oriented Programming in which Objects represent the independent computational units that can enable parallelism within a program.
Although Bensley [1989] claims that, "no particular Object-Oriented language was decided upon; instead, operating system issues common to supporting many distributed Object-Oriented systems were concentrated on", when probing deeper we discover a characteristic of Lisp coming through, (namely garbage collection). This is not surprising as the chosen language for implementation of the MITRE model is Flavors, a superset of Common Lisp.
Below we will briefly present the MITRE model's resource management, object number man agement and garbage allocation. Although a number of analogies exist between the MITRE model and OOPP, these will be discussed in section 13. (For further details, readers are referred to Bensley [1989]).
May 1994 C KyriaJddes Page 238 Supporting Papers Objed'()riented Parallel Paradigms
12.1.1 Resource Management
In briefly describing the MITRE model's resource management, Objects are anticipated to be dynamically created and discarded as a program executes. Furthermore, Objects are considered to be units of work assigned to processors. MITRE's memory management provides a means of finding processors with sufficient free memory to store new Objects; while, processor man agement provides a means of dynamically balancing the load on processors by distributing Objects in a relatively equitable manner.
The resource management strategy developed to meet the requirements set out above is briefly listed below:
When Objects are created they are distributed amongst processors in an equitable manner, and
Dynamic redistribution of Objects among processors helps to maintain a relatively equitable distribution.
Resource agents are defined to be operating system servers distributed throughout the system. Each agent manages memory allocation for the processors in its local communication neighbourhood.
A processor sends allocation requests to its local agent; that agent assigns each request to whichever processor in its neighbourhood it deems most appropriate. If there is none, the agent forwards the request to a superageot - another operating system server that oversees activity in several agents' neighbourhoods. If the superagent has another inferior that may be able to satisfy the request, it forwards the request to that inferior: otherwise, it forwards the request to its own superagent.
Whenever the net memory use in a processor or in an agent's or superagent's neighbourhood crosses a predetermined level (e.g., 10%, 20%, etc.), the processor, agent, or superagent sends an update Message to its superior agent or superagent to report its current level (the amount of memory in use and the amount free). Agents and superagents use this information as the basis for assigning allocation requests.
For this scheme to work efficiently, an agent should be able to find a processor in its own neighbourhood that can satisfy an allocation request. To this end, each superagent employs a
May 1994 C Kyriakides Page 239 Supporting Papers Objed'()riented Parallel Paradigms
redistribution strategy to move Objects from higher-density areas to lower-density areas within the superagent's purview. Fault tolerance is achieved by assigning every agent and superagent a backup that can take over its responsibilities should its processor fail
12.1.2 Object Number Management
As was mentioned previously, relocation of Objects among processors may be necessitated in order to balance the computational load, minimize communication distance. or support fault tolerance. However. a Message sent to a relocated Object must be able to reach the Object in its new location. To accomplish this task, every Object is identified by an Object number. Every processor keeps track of which Objects it has, and where they are in its memory; also. a collection of Object number management processes throughout the system keep track of which processors have which Objects.
Two schemes for managing Object numbers were considered:
One uses a hierarchy of Object number managers, each responsible for a distinct range of Object numbers. For each manager. that range is partitioned among its inferior managers. Those at the bottom of the hierarchy actually know where Objects are located; managers at each level above the lowest route send requests to the appropriate leaf managers. Each processor knows the locations of at least the root manager's inferiors.
In the other scheme, everyprocessor functions as an Object number manager for a distinct set of Object numbers. The address of the Object manager is embedded in each Object number for which it is responsible. A processor needs no information other than an Object number to determine where the appropriate manager is located.
12.1.3 Garbage Collection
A distributed garbage collector serves to remove Objects that are no longer needed by a computation and deallocate their resources.
Two algorithms were developed by the MITRE research for fault-tolerant garbage collection. Both are designed to run concurrently with application programs, and both collect garbage in a cyclic manner (for further details see Bensley [1989]):
May 1994 C Kyriakides Page 240 Supporting Papers Objed-Oriented Parallel Paradigms
A straightforward extension of the conventional mark/sweep algorithm, that uses a tree of control processes to synchronise transitions between marking and sweeping across the system. Fault tolerance is achieved by collecting only Objects that have not been marked for several consecutive garbage collection cycles.
The other algorithm is based on timestamps. Each successive mark phase corresponds to a successive timestamp value, and all mark messages belonging to a given mark phase carry the timestamp associated with that phase. Mark phases are begun at regular inter vals without regard for other mark phases still in progress. Objects are marked with timestamps, and an Object is only marked when it receives a mark message with a timestamp greater than its own. Objects are collected when their timestamps are too far out of date. Fault tolerance is achieved by adjusting the time-out period used to identify garbage.
The second algorithm eliminates the need for synchronising transitions between marking and sweeping; every processor sweeps its own memory asynchronously and independently of other processors. The second algorithm can potentially collect garbage more quickly than the first; however this depends on how closely we can determine the minimum time out-period that keeps us from collecting Objects that are not garbage.
12.1.4 Unclear Issues of the MITRE Paper
In the MITRE paper presented above the following unaddressed/unclear issues were encountered:
Are Objects in the MITRE model Internally-Sequential?
Is there any other reason (beside Lisp being the chosen/preferred language of imple mentation), that necessitates the use of garbage collection?
What arc the benefits of having managers independent of the actual Object hierarchy? and are these benefits more significant than having the managers linked to the Object hierarchy?
May 1994 C Kyriakides Page 241 Supporting Papers Objed'()riented Parallel Paradigms
12.2 Unanswered Issues
As mentioned in section 3.11.2, message passing can serve both as an inter-Object communication mechanism, as well as, a synchronisation mechanism. From the perspective of analysis, Internally-Sequential Objects are easier to conceptualise. Objects that exhibit Internal Concurrency (either by a method exhibiting internal concurrency or by two methods executing concurrently) tend to be more complex to analyse. Breaking the Object into smaller Objects so as to exhibit only external concurrency may prove to be even more awkward as the sheer number of new Objects in a complete system will be too many to handle. One avenue could be to introduce a form of temporary-Objects where we create new "conceptual" Objects for reasoning purposes only, but do not actually create the Objects after the reasoning process is complete. The issue of how to improve the analysis of internal concurrency has been left up to future research.
12.3 Summary: MITRE
The MITRE model [Bensley 1989] has agents that serve to manage/control objects. Agents exist within a "hierarchical" precedence structure such that an agent (closer to the top of the hierarchy) can exert control over its particular sub-agents (situated lower down the hierarchy). Agents pro vide a form of Object management based on Object numbers - Objects are mapped to agents either in terms of a range of Object numbers or a set of Object numbers. (In section 13 we will elaborate on how the OOPP model can be reduced so as to emulate the MITRE model).
From the above, it is clear that MITRE's agents play a role analogous to that of OOPP's man agers. Furthermore, both MITRE agents, as well as, OOPP managers exist within a "hierarchical" precedence structure. Nonetheless, substantial differences exist. For example, MITRE Objects can only be managed in terms of Object numbers; while OOPP Objects can be managed in terms of Object instances, classes, or even groups of instances or classes. (It should be noted that the OOpp model can be reduced to emulate the MITRE model's form of management; an OOPP Manager Class can be allocated to managing all Employee instances - in other words, all employee instances that belong to the topmost Employee Class or any of its subclasses). Another example, a MITRE agent is aimed at managing a processor or a group of processors within a close prox imity to each other.
May 1994 C Kyriakides Page 242 Comparison between OOPP and other Objed-Oriented ParaDe) Paradigms models
13 Comparison between OOPP and other models
This section serves to provide brief comparisons between OOPP and a number of the models men tioned in earlier chapters. For the sake of brevity, discussion in this section is aimed only on the models whose readdressing could be combined to so as to give rise to new facts. Furthermore, this chapter does not endeavour to treat each model's characteristics one-by-one in comparison to related characteristics of OOPP; (the only exception to this is the MITRE model which at first glance appears to be very similar to OOPP but, when an indepth look is taken, the differences are substantial). By discussing such differences and similarities it is possible to present a clearer picture of OOPP's capabilities.
13.1 OOPP and the MITRE model
In this section we present a comparison between OOPP and the MITRE model. Although simi larities do exist, in order to appreciate their differences it must be kept in mind that OOPP is aimed at facilitating development of complete software systems; while the MITRE model is aimed at the development of an operating system. One issue that may be raised by this is whether certain features should be viewed to be part of the operating system or part of the software being developed. We will come back to this point in the following sub-sections.
One clarification should be made on the terminology used by OOPP and the MITRE model: Resource Agents in the MITRE model act as "managers" at the operating system level and are viewed as operating system servers; managers in oopp act as managers at the Object model level and can furthermore provide management/services for the operating system level.
13.1.1 Similarities
oopp and the MITRE model have the following points in common:
Aimed at MIMDs
Incorporate resource management (albeit differently)
Managers (in OOPP) and Agents (in the MITRE model) are hierarchical; namely, man agers and sub-managers in OOPP, and Superagents and Agents in the MITRE model.
Accommodate dynamic Object creation and deletion.
May 1994 C Kyriakides Page 243 Comparison between OOPP and other Objed-Oriented Parallel Paradigms models
Reallocation of Objects to balance processor loads.
Autonomous managers - a manager/agent operates autonomously within its allocated resources.
Both cater for Operating System based managers. Although in OOPP it is an additional option, while in the MITRE model it is a rule.
It should be noted that a MITRE agent's role is analogous to that of an OOPP manager's role; furthermore, MITRE's super-agent/sub-agent structuring is analogous to OOPP's hier archical ordering of managers. Nonetheless, significant differences do exist and these will be discussed shortly.
13.1.2 Differences
Although a number of similarities exist, as mentioned above, OOPP has a number of major distinctions over its counterparts in the MITRE paper:
oore MITRE model
The ooze model is fully Object- The MITRE model is Object-based; this Oriented; this implies that, by default, all implies that even though the model comprises Objects (including Managers) in an of Objects, these Objects do not exhibit Object-Oriented Hierarchy exhibit Inheritance nor do they formulate a hierar- Inheritance. chy.
Managers are created, destroyed and Agents are created and destroyed according maintained according to the Object hier- to the requirements of the processor architec- archy. ture.
Manager-Employee relationship. Agents have no relation to the Objects or group of Objects in the system.
May 1994 C Kyrialtides Page 244 Comparison between OOPP and other Object'()riented ParaUel Paradigms models
Managers are intended for complete Agents are intended for memory management resource management. This includes (finding processors with sufficient free memory management, processor man memory) and processor management (dyna agement, architecture management (in mically balancing the load on processors). the case of reconfigurable machines), peripheral management and specialised processor management (As described in sections 8 and 9)
Object-Oriented model based. Managers Operating system based. Objects are managed can manage a group/groups of Objects according to which processor neighbourhood that are closely related in the Object they reside in. Objects are managed in terms Class structure. of Object numbers; each agent is either responsible for a range of Object numbers or a set of Object numbers.
Managers can be specialised. Agents cannot be specialised.
Managers are Objects. It is not clear from the article whether agents are Objects or not.
No garbage collection required, (garbage Garbage collection is implemented. (Article is
collection IS optional). An employee not clear as to whether it is done by choice of cannot exist that is concealed from every language of implementation or is needed single manager. Furthermore, a sub owing to the model structure). manager cannot exist independently of its super-manager, etc.
Operating System based managers are Operating System based managers are the an option that can be used if needed rule. (see section 8).
MITRE's balancing of processor loads is analogous to OOPP's processor workload balancing concept presented in section 5.5; nonetheless, some differences do exist. To elaborate, OOPP also takes into account processing relationships between Objects, as well as, Object-to Processor densities presented in section 53. In contrast, the MITRE model places emphasis
May 1994 C Kyrialddes Page 24S Comparison between OOPP and other Objed'()riented Parallel Paradigms models
on available processor memory, but overlooks the probability that some Objects may be capable of processing simultaneously. Despite the MITRE model adopting an almost statistical reasoning (based on processor memory and empirical processing requirements), another point overlooked by the MITRE model is that processors with high object-densities are more likely to receive a message for processing.
13.1.3 OOPP's additional features
In comparison to the MITRE model, OOPP has the following additional characteristics:
The ability to distinguish (and make use of) Objects and methods amenable to parallel processing techniques.
Exploiting the additional resources and processing power made available by networking of homogeneous and/or non-homogeneous machines.
Resource Usage Data and Resource Usage Sets are employed.
Objects have the abiljty to request a number ofprocessors in a specified architecture to be made available to them.
Managers can be either Object-Oriented model based or Operating System based.
13.1.4 Features introduced by the MITRE model
One interesting feature of the MITRE model is the idea of purely Operating System based managers. Even though Operating System managers have the disadvantage of not being related to the Object-Oriented model being developed, they are conceptually simpler than managers of models (such as OOPP) that make use of this additional information. MITRE's shortcom ing however, can be attributed to the fact that the system developed was an operating system and thus took the Operating System based managers as the rule.
Even though the features listed below are incorporated in the MITRE model, these do not have to be incorporated into OOPP (but can be implemented if found desirable):
Futures feature of Actors as described by Agha [1986J so as to exploit parallelism dis covered during execution.
May 1994 C Kyriakides Page 246 Comparison between OOPP and other Object-Oriented ParaDel Paradigms models
The Time Warp mechanism described by Jefferson [1987] and modified by Bensley [1988, 1989] can be incorporated in a model developed based on OOPP.
A future Object acts as a placeholder for the result of a computation and, for certain opera tions, can be used in place of the result. Prior to sending a Message, the sender creates a future Object, includes a pointer to that Object in the Message it sends, and continues executing without waiting for a reply. When the Object that receives the Message completes its computation, it sends the result to the future Object. When the value of the result is needed, it can be retrieved from the future Object. (For further details see section 7.6).
When using the TIme Wop mechanism it is important to note that the resource manager may not observe the authentic processing and memory requirements of an Object (or group of Objects) as would be the case without the Time Warp mechanism. In the Time Warp scenario, messages are processed as they arrive, but before processing each message it saves its state. When a message arrives with a simulation time earlier than the message already processed, the Object needs to roll back to a state at or before the time of the new message. Thus processing and memory requirements are not only dependent on the number of messages received but also on the order in which they arrive.
Even though certain Objects would benefit from the implementation of the Time Warp mechanism, it is foolhardy to accept that all Objects would benefit from such a mechanism. For example, an Object that receives many messages from near and distantly located Objects would end up being forced to roll back almost constantly. The reason for this is that messages from distant Objects sent during an earlier time interval than messages from neighbouring Objects would arrive in reverse order owing to interprocessor communication delays (i.e., the distant message needs to be relayed from processor to processor). Further consideration of this issue is left over to future research efforts.
13.1.5 The Operating System and Software Design
This section briefly discusses the "dependency" relationship that can take shape between an operating system and software design considerations. (This issue has been taken into consid eration at this stage as the MITRE model is aimed at the operating system level, while OOPP is aimed at the more comprehensive systems development level). The point we will make here is that operating systems should provide sufficient operating system services to facilitate ease
May 1994 C Kyriakides Page 247 Comparison between OOPP and other Objed-Oriented Parallel Paradigms models
of software applications development, however, the application designer should not be forced to use these services. As will be seen, available operating systems services can, to a limited extend, influence software design considerations.
It should be noted that any comprehensive paradigm/system must encompass features deemed to be suitable for an operating system, as well as, features deemed suitable for software applications. However, before attempting to clarify whether certain features should be viewed as operating system candidates or software application candidates, we need to clarify what is an operating system.
An operating system provides an environment for execution of programs. Although the oper ating system services may vary from one operating system to another, there are some common groupings of services which can be identified. Services targeted for the user are the following:
Program execution Load a program into memory and run it. The program must be able to end its execution either normally or abnormally.
I/O operations Since a user program cannot execute I/O operations directly the operating system must provide some means to do so.
File system manipulation All basic operations on a me, that a user might desire to do.
Error detection The operating system must be aware of possible errors (hardware errors • CPU, memory and I/O devices), or user (software) errors (arithmetic overflow, illegal access to a file or memory)
Services targeted for the efficient operation of the operating system itself are:
Resource allocation When there are multiple users or multiple jobs running at the same time, some need special allocation code (CPU, memory) while some have more general allocation code (I/O devices).
May1994 C Kyriakides Page 248 Comparison between OOPP and other Objed-Oriented Paranel Paradigms models
Accounting Record-keeping of computer resource usage is important mainly for billing purposes, or for statistic accumulation which might be quite important for system tuning.
Protection The owners of information stored in a computer system may want to control the information's use; secondly, mul tiple jobs running simultaneously should not interfere with each other; and fmally, conflicting demands for various resources need to be reconciled fairly and scheduled reasonably.
Operating Systems will continue to act as Resource Managers; however, the resources being managed will change. Clearly the low-level "machine" services provided by operating systems ought to remain operating system candidates. However, the higher-level "reasoning" services can in certain cases prove beneficial if they are allowed to migrate through to the software application phase, and under this scenario use the low-level services provided by the operating system as a vehicle for the reasoning services now provided by the application program.
To elaborate further, take resource allocation in an OOPP environment as an example. From the earlier discussion on OOPP, it was seen that the resource requirements and feasibility of an application (as well as, for each Object in that application) will be establisbed during the analysis stage of that application based on OOPP. If OOPP is allowed to pass on this infor mation it has "reasoned out" to tbe operating system in terms of a set of low-level services made available by the operating system to all application programs, tben we can maximise the efficiency of the entire system.
If we instead use the MITRE model's approach and treat Objects as a range or set of Object numbers tben we will thereby lose tbe analytic information pertaining to tbose Objects; we will thus rely exclusively on tbe relocation mecbanism to dynamicallybalance the Objects according to processor loads and communication requirements between Objects. Relocating Objects is an expensive process, and if tbe initial set up tbat we start of witb is far from ideal it will be very expensive to correct.
May 1994 C Kyrialddes Page 249 Comparison between OOPP and other Object-Oriented Parallel Paradigms models
This implies the structure of an Object-Oriented application may provide certain information about its resource requirements. This information should not be ignored simply because no vehicle is provided to make accessible what is traditionally considered an operating system service.
It should also be noted that, if desired, oopp can be restricted so as to emulate the object management services provided by the MITRE agents. To elaborate, an OOPP model can be restricted to a single manager class where instances of this class manage all employee instances without regard of the employees class. Employee instances can then be managed in terms of their processor locations. Furthermore, managers can be also restricted to only take into account memory and processing loads of processors in order to achieve equitable distri bution of objects.
If operating systems are developed without consideration for software applications, shortcom ings on the part of the operating system will place undue stress on the software developer; if possible, the developer would then have to "sugar" the features of the operating system. However, on the other extreme, over-ambitiousness on the part of the operating system developer will result in certain choices being made that should have been left up to the software developer; the software developer is under this scenario railroaded into the prede termined choices.
In general, OOPP's philosophy with regards to available services (including operating system services) is that they should embody available "options" that may be used (if so desired) or alternatively overridden. The OOPP analysis effort is only aimed at illustrating "what" services may be required (i.e., the responsibilities of Objects), "not how" these services are to be implemented. Any operating system forcing a systems' developer to make use of an available operating system service (no matter how good this service may be) should be viewed as restricting the system developers scope.
Operating systems for pioneering paradigms such as OOPP require at least two important features. One, as a minimum, all the services expected to be found in a traditional operating system; and two, the ability to modify or override certain services provided by the default operating system.
May 1994 C Kyriakides Page 250 Comparison between OOPP and other Objed-Orienttd Parallel Paradigms models
13.2 OOPP and Responsibility-Driven Design
OOpp is suitable for either a Responsibility-Driven or a Data-Driven approach to concurrent Object-Oriented Analysis. However, owing to the ability of the Responsibility-Driven approach to emphasize the encapsulation of both structure and behaviour of Objects, the Responsibility-Driven approach is by far the better choice of the two.
Furthermore (using the responsibility-driven approach), by focusing on the contractual responsi bilities of a Class, the designer is able to postpone implementation considerations until the implementation phase.
13.3 OOpp and the Law of Demeter
As mentioned in section 4.2, the Law of Demeter [Lieberherr 1989] is concerned with the prin ciple of loose coupling between Objects. In brief, the law states that the methods of a class should not be dependent in any way on the structure of any class except the immediate (top-level) structure of their own class. Furthermore, each method should only send messages to objects belonging to a very limited set of classes [Sakkinen 1988]. In essence, the Law of Demeter restricts depen dencies between Classes by restricting the message sendings between Objects; in tum, this gives rise to greater encapsulation. (Keep in mind that, in section 4.2, we made a superficial distinction between the Law of Demeter and the Demeter tool).
Although the Law of Demeter can be implemented as a guideline within OOPP, OOPP can facilitate such a guideline in a more controllable fashion by making use of managers. In OOPP message sendings can be restricted between Objects by allowing message sendings only within the guidelines set out by a chosen manager-employee relationship; to elaborate, the manager may not only control which objects may communicate with each other, but also, what messages are allow able. Furthermore, if so desired, the manager may also selectively allow for different communi cation messages between objects depending on the objects state. In other words, a Manager is responsible for monitoring (and controlling) his sub-managers and employees. The default mode of operation is that an employee communicating with another employee may only do so via their immediate managers. The ability to deviate from this message passing guideline may be allowed by the manager in one of two ways:
May 1994 C Kyriakides Page 251 Comparison between OOPP and other Objed-Oriented Parallel Paradigms models
A manager may allow all his employees or a group of his employees to communicate directly without managerial supervision.
A manager may allow one of his employees or a group of his employees to communicate to an employee (or group of employees) outside that managers control.
The implications of these deviations were mentioned in section 8.4.
13.4 OOPP and PROCOL
PROCOL has certain interesting features; most noteworthy being the one-to-one, one-to-many, many-to-one and many-to-many communication protocol between Objects (and Classes of Objects). Another interesting feature from an object management perspective is the support of a dynamic "ownership hierarchy" based on object creation - an object is initially owned by the object that requested its creation and the ownership can be transferred to other objects. As mentioned, this can be facilitated by OOPP managers if so desired; however, it must be kept in mind that PROCOL's communication protocol can give rise to broadcasting (e.g., one-to-many) and the implications thereof, with regards to distributed processing, should be kept in mind.
However, PROCOL also has one major over-simplification; namely, Objects are taken to be the grain of parallelism. Referring to Wegner [1989], it is clear that taking the Object to be the grain of parallelism will result in a conceptually simple model; however, certain scenarios will occur where we will lack the expressive capabilities required. The fact is that certain applications require a fme-grained concurrency within an abstraction while others require a model of concurrency coarser than its unit of abstraction (see section 1.7) (Wegner 1989].
With PROCOL, Objects are viewed as internally sequential; namely no concurrency can be expressed within an Object. Thus, any methods occurring within an Object are forced to execute one at a time, irrespective of whether during analysis we discover that any two or more of these methods can be executed concurrently. (One way of overcoming this limitation at the implemen tation level is to analyse objects in the normal fashion and during implementation to treat the portions that may execute concurrently as separate "implementation objects". It is left over to future research to determine the most viable means of ensuring consistent access to attributes
May 1994 C Kyriakides Page 252 Comparison between OOPP and other Objed'()riented ParaDel Paradigms models
shared amongst two or more methods of the same object residing in different "implementation objects"; nonetheless, a fundamental step in this regard is embodied in the section 5.4 on Object State and Method Coupling).
13.5 OOPP and Actors
The Actor model [Agha 1986] imposes two primary restrictions to the general Object-Oriented model whereby it eases implementation on distributed architectures. Firstly, the Actor model is Object-based - this implies no classes and class-based inheritance. Secondly, delegation allows a number of actors to "share" processing access to a method. In essence, there is no shared repos itory of behaviour in actors. Although delegation is likened to a form of "classless inheritance" it is imperative to note that in delegation processing is done in the context of the proxy; while in inheritance, processing is done in the context of the client [Tomlinson 1989].
In other words, if we refer to the object that requests a message to be processed on its behalf as the "client", and the object which undertakes processing on behalf of the client as the "server', then:
in inheritance based models: an object instance requiring to make use of an inherited method will act as the "client", while the superclass object that undertakes such processing will act as the "server". The server will process the message in the context of the client.
in delegation based models: one actor (the "client") delegates processing of a message to another actor (the "server"). The server processes the message in the context of the server itself.
It should be clarified that in tbe actor model even though (a number of identical actors may exist) there is no concept of class; when an actor receives a message for processing it specifies its replacement actor before commencing to process that message. This replacement actor may be identical or different (with regards to behaviour and script) to the actor it replaces. Any subse quent messages arriving will be redirected to the replacement actor. Thus, when a number of messages (directed at the "same" actor) are processed during the same time instant, each message will be processed by consecutive replacements of the actor. When the processing of all these messages is completed only the last replacement actor continues to exist.
C Kyrialddes Page 253 Cot1lparisOn between OQPP and other Object'()riented Parallel Paradigms models
As will be explained shortly, it should be noted that OOPP appears capable of emulating a number of the Actor model's features (including delegation, RACE actors and receptionists). OOPP's manager-employee relationship enables managers to exhibit a powerful influence over their employees. In order to emulate the actor model, a manager can act as the exclusive message interface to an employee. Furthermore, a manager may be used to request anyone of its employees to create instances of the employee or may even destroy one of its employees. This two facts enable oOPP to emulate the delegation aspect of Actors. To elaborate, a manager may direct successive messages to successive instances of an employee; each successive employee instance may represent successive states and behaviour (analogous to replacement actors). Once all mes sages are processed, the manager can destroy all copies of the employee except the instance representing the last "replacement" employee. (Although, successive states are easy to implement, successive behaviour is rather more complex - actors "become" statement can drastically change the behaviour of an actor between successive messages).
Similarly, the RACE actor feature can also be emulated by OOPP: a manager may allow multiple instances of an employee to independently solve portions of fragmentable problems. Like RACE actors, results can then be made available in the order that they were completed, or even sorted by the manager before been passed on.
The analogy between actor receptionists and OOPP-scenario "topmost" managers is obvious: receptionists are the only actors capable of receiving communication outside the actor model; while, topmost manager instances are the only objects capable of communicating beyond the boundaries of the OOPP-scenario. (Topmost managers are more powerful than receptionists in that, not only incoming communication is supported, but also outgoing communication).
In ABel/I, the volatile nature of actors' "become" statement was abandoned. Furthermore, ABeL/1 supports a number of message passing modes [normal and express modes) and a number of message passing types (past, now and future types). ABCL/l uses future rpc (described in section 3.12). Below we will show that OOPP can facilitate the message passing protocols of ABCL/1:
As mentioned in section 7.6.2.1, in ABCL/I the name of the sender and the reply destination are provided by the message; Yonezawa [1987] made use of this additional information to
May 1994 C Kyriakides Page 2S4 Comparison between OOPP and other Objed-Oriented ParaDel Paradigms models
point out that now and future message types can be reduced to past message types. Analo gously, OOPP can make similar use of this additional information (either explicitly or implic itly) by means of managers so as to reduce now and future message passing to past message passing; (note that, if desired, a manager may request to be presented with information regarding the originator of a message • as well as, the destination for the result - prior to approving its acceptance at the messages destination).
Furthermore, a manager monitors and controls its employees constantly, even while employees are processing messages. A mechanism accommodating specifying the precedence order of messages can easily be accommodated within the oOPP model. Hence, a manager can tem porarily halt processing arising as a result of low priority messages and commence processing higher priority messages. Furthermore, if desired, oOPP can facilitate a graduated level of message/process precedence (theoretically catering for an unlimited discrimination of prece dences). Thus, OOPP's managers can also implement guidelines to determine the precedence level of processes arising as a direct result of an incoming message (or even subsequent processes). For example, a process may adopt the same precedence level as the message which caused it to commence processing. (Another possible alternative is that precedence levels can be expressed as fractions between 0 and 1, inclusive. A process may adopt the same prece dence level as the message which caused it to commence processing. Precedence levels of subsequent processes can be evaluate by multiplication of the original messages precedence level and the subsequent messages precedence level).
Since ABCL/l uses future rpc, it is clear that if OOPP wishes to emulate the ABCL/l model, OOPP should be capable of allowing future rpc. (Thus in order to enable OOPP to emulate a diverse number of models, we will propose shortly that oOPP should be capable of emulating as many of the message passing interaction primitives mentioned in section 3.12 as possible). Ignoring possible limitations arising from interaction primitives, oOPP is capable of accommodating all of forms of ABCL/1 messages by means of managers.
From the above, it is clear that oOPP appears capable of emulating a number of features of the Actor model and ABCL/I. It is left up to future research efforts to determine whether any fea tures exist in the Actor model that cannot be supported by OOPP.
May 1994 C Kyrialddes Page 25S Comparison between OOPP and other Object-Oriented ParaDeI Paradigms models
13.6 OOPP and LISP
USP is one of the most prominent Artificial Intelligence languages. In turn, CLOS is a prominent Object-Oriented extension to Common USP. In general, Object-Oriented liSP extensions support dynamic binding, generic {unctions, multiple inheritance and garbage collection. The highly dynamic environment of liSP based Object-Oriented extensions is achieved at the cost of additional run time checking requirements. As is generally the case, garbage collection can bring about serious implications for time-critical applications. Another typical feature of USP that migrated into the Object-Oriented extensions of liSP is that of event-driven processes, called demons; demons can prove beneficial in a development environment (e.g., in debugging).
The liSP based languages exert a number of subtle but significant variations to the concept of Object-Orientation. Firstly, objects are represented by frames - frames are data structures com prising of slots which may contain data and procedures. Since slots appear to take On the form of object attributes and the fact that slots can contain facets (methods), can give rise to the perception that methods are not attached to the objects themselves but rather to the attributes of the objects, (this was discussed in section 7.4); recall that accessor methods enable system devel opers to conceptualise objects in terms of abstract attributes instead of a set of slots. Unfortu nately, in CLOS, slot names are encapsulated but not hidden and thus CLOS classes are not true abstract data types. Secondly, besides attribute inheritance (supported by most of the Object-Oriented models), value inheritance is also supported. Furthermore, CLOS accommodates more forms of inheritance than other Object-Oriented models previouslydiscussed; namely, CLOS supports type inheritance, slot inheritance, initialisation inheritance and method inheritance. Thus, slots may have default methods and default values which may be overridden.
Supporting multiple inheritance gives rise to inheritance conflicts. These inheritance conflicts are handled by either a precedence list or, (with the exception of method inheritance conflicts which are handled) by method combination.
Clearly, any Object-Oriented model wishing to accommodate the same problem domains that Object-Oriented extensions to liSP can address will have to be capable of accommodating a large number of the above mentioned characteristics. It is clear that OOPP can accommodate general Object-Oriented concepts such as multiple inheritance (section 3.6), polymorphism (section 3.7), garbage collection (optional), static and dynamic binding, etc. However, if OOPP wishes to emu late the CLOS environment then, in addition to general Object-Oriented concepts, OOPP would
May 1994 C Kyriakides Page 256 Comparison between OOPP and other Object-Oriented ParaDel Paradigms models
have to be capable of facilitating a highly dynamic environment, event-driven processes, value inheritance, etc. Clearly, the only existing Object-Oriented language environments which avail these characteristics are those based liSP itself. Thus, in order for OOPP to emulate Object Oriented extensions to liSP, either OOPP will have to be implemented on a new language plat form or, alternatively, we should be considering whether OOPP can be implemented using LISP or one of the LISP extensions (such as CLOS).
13.7 OOPP and PROLOG
As mentioned in section 7.5, logic programming endeavours to provide a completely unified sys tem whereby all inferences of known facts relevant to a specified goal can be deduced automati cally at any given time. In contrast to this, Object·Orientation attempts to encapsulate everything within distinct objects.
In Smalltalk/V, PROWG/V exists within the Smalltalk/V environment as a class. Furthermore, each PROLOG/V application exists as a subclass of the PROWG class; and thus, each instance of a PROWG subclass is a complete version of PROWG. Supporting PROWG in this way can be easily accomplished within Oopp by means of Special Managers - one or more special man agers can be allocated to managing one or more PROWG applications.
13.8 Summary: Comparison between OOPP and other models
In this section we compared OOPP to a number of the models previously discussed. For the sake of brevity, we only concentrated our discussion here only on the models whose readdressing could be combined to so as to give rise to new facts.
Although the MITRE model appeared to exhibit a number of similarities to the OOpp model, it was shown that owning their disparity in addressing different problem domains, OOPP is sub stantially different from the MITRE model.
It was shown that, if desired, guidelines imposed by various methodologies (such as the Responsibility-Driven Approach and the Law of Demeter) could be supported within OOPP.
Furthermore, DOPP appears to be more than capable of emulating a significant number of fea tures present in other models (including Actors, ABCL/1 and MITRE). It was also shown that in
C Kyrlalddes Page 257 Comparison between OOPP and other Objed-Oriented Parallel Paradigms models
order for OOPP to exhibit the maximum flexibility possible, OOPP must be developed with the ability to exhibit as many of the message passing interaction primitives mentioned in section 3.U as possible.
Before presenting our next argument, we will take this opportunity to refresh the readers mind. OOPP's managers enable OOPP to exhibit a diverse and flexible nature. OOPP is a homogeneous environment in which everything appears as an object; nonetheless, oopp can use special inter face managers to encapsulate nonObject resources, as well as, to interface different Object tech nology platforms. Furthermore, OOPP allow each OOPP-scenario to be "functionally independent" from any other OOPP-scenario.
In comparing OOPP with Object-Oriented USP extensions we noted that owing to its dynamic environment, the only existing model that provides USP's characteristics is USP itself. We then raised the issue that if OOPP wishes to emulate an Object-Oriented USP extension, then we could consider whether OOPP can be implemented using USP or one of the LISP extensions. However, it is clear that using one language/development environment we may not be able to emulate another language/development environment. Thus we need to readdress the question whether OOPP can simultaneously handle two or more disparate environments. Keeping in mind the statements of the previous paragraph, it is dear that special interface managers can be implemented to translate communication between two fragments of an application developed to operate in different environments/platforms. Similarly to OOPP-scenarios, using special interface managers, OOPP can emulate one or more language environments by allowing objects developed in one environment/language to undertake processing in the fashion that is normal to that envi ronment (including message passing interaction primitives). Communication to objects belonging of another environment/language is then forced to take place via the special interface manager which translates the message into the appropriate format. The special interface manager of the other group may have either a different language environment or maybe even a different message passing interaction primitive.
Please note that although oopp can emulate a number of diverse features existing in various models, it is not claimed that OOPP is capable of emulating every existing model. Furthermore, it was never intended to address every conceivable problem. In its conceptual stages, OOPP was simply intended to provide a flexible model capable of addressing a diverse problem domain, as well as, being capable of being implemented on a diverse range of computing resources.
May 1994 C KyriaJddes Page 258 Conclusion Objed.()nented ParaDel Paradigms
14 Conclusion
OOPP has been successful in achieving several milestones. Amongst these milestones is OOPP's ability to integrate the Object-Oriented and Parallel Processing methodologies into one homogeneous body. In particular, OOPP presents system developers with a general-purpose paradigm for developing large-scale Object-Oriented Parallel Systems. It is anticipated that the approach to systems develop ment taken by OOPP will exhibit its full potential only when huge-scale software-reconfigurable multi-processor machines are in common use.
It must be kept in mind that if an issue was not addressed in this research then it does not mean that the OOPP model is incapable of addressing this issue; it simply means that this particular issue was not addressed within the current research effort. It should be noted that at this stage of the OOPP research we cannot see any reason why OOPP cannot facilitate any of the features present in other Object Technologies.
14.1 OOPP: A brief overview of concepts
This section briefly recaps on a number of OOPP's concepts.
OOPP's manager-employee concept enables system developers to encapsulate Analytically Induced Responsibilities (AIRs) from nonAnalytically Induced Responsibilities (NAIRs). The manager employee concept makes it possible to introduce the Two-Tier Approach, Indirect Message Pass ing, Special Interface Managers, Special Communication Managers, Antivirus Managers, Data Compression Managers, and so on.
OOPP's Object Taxonomy enables system analysts to express processing relationships between individual objects, groups of objects, as well as, individual methods within an object. The Object Taxonomy's expressive capabilities can be used to formulate object-to-processor mapping algo rithms. A number of considerations that should be taken into account in developing object-to processor mapping algorithms were also presented. On an analogous topic, it was shown that Object State and Method Coupling appears capable of revealing a number of processing relationships between object instances and portions of objects.
An adaptation of productivity and workload concepts for objects in a multi-processor environment was also presented. Although acting in consideration to processor workloads appears rather straightforward, the same cannot be said for productivity.
May 1994 C Kyrialddes Page 259 Conclusion Object-Oriented Parallel Paradigms
It was also shown that OOPP can accommodate a number of the existing models previously dis cussed. By using special interface managers and a concept similar to OOPP-scenarios, it ispossible for oopp to emulate a number ofdifferent models or platforms simultaneously.
14.2 Multi-Tier Approach
As was illustrated in section 11.4, oOPP's Two-Tier Approach lays the foundations of presenting a Multi-Tier Approach. The Two-Tier Approach allows for encapsulating nonAnaltically Induced Responsibilities (NAIRs) from Analytically Induced Responsibilities (AIRs). Furthermore, we stated that NAIRs of one problem domain may be AIRs of another problem domain. In effect this embodies a fundamental idea behind the Multi-Tier Approach. Note that this can allow each layer to provide a higher level of abstraction separating implementation issues from analytic issues. Hence, each tier in a multi-tier approach provides a different level of abstraction for a given problem domain. In closing, it was mentioned that in a multi-tier representation manager employee relationships are represented by stacked tiers, and furthermore, only tiers stacked directly against each other can communicate.
14.3 Research Papers
All the papers used as background research material dealing specifically with the Object-Oriented Parallel field of study failed to present a general-purpose Object-Oriented Parallel methodology. This is by no means a fault of the respective authors as their papers were intended to present their specific interpretation/implementation of a specific Object-Oriented Parallel methodology. For example, the Bensley [1988, 1989] paper was intended for implementation of an operating system based on Flavors. The major shortcoming of the Bensley approach is that Objects are managed by Agents in terms of the processor in which the Object is located. The relationship present between the various Objects in the Object hierarchy is thus overlooked and not used to the system's advantage. Another limitation of the Bensley approach is the reliance on garbage collection to detect and remove unused Objects.
14.4 OOPP and Standards
As mentioned above (and in section 11), when using a multi-tier approach, OOPP managers at one level may themselves be managed by higher-level managers. In order to establish that OOPP can be used to develop an environment conforming to a particular standard, all that is required is
May 1994 C Kyrialddes Page 260 Conclusion Objed-Oriented ParaDel Paradigms
to establish that at any single manager level of an achievable OOPP based model, the environment provided conforms to the requirements of that particular standard. It then follows that since the particular manager level conforming to the standard can be used for managing its immediate lower-level managers, then the standard can also be used to facilitate developments based on OOPP.
14.5 OOPP and the OMG standard
OOPP's manager-employee concept can be used to transparently accommodate a number of standard specifications. With regards to the OMG standard, it will be briefly illustrated below that OOPP can accommodate a number of OMG's technical objectives and specifications. (Although, at this stage of the OOPP research, it appears that it is possible to accommodate a substantial number of OMG's goals within OOPP, it is beyond the scope of OOPP's current research to thoroughly investigate this avenue.)
Recall from section 6.2.1 that the OMG attempts to standardise Object interfaces and behaviour from the viewpoint of other Objects present in a system; it does not attempt nor intend to stan dardise the internal structure or behaviour of objects. (An object's interface is represented by the set of messages an Object supports; while, an Object's behaviour portrays the semantics of those messages.) In essence, the OMG endeavours to provide a standard model that accommodates interoperable applications based on distributed interoperating objects across non-homogeneous platforms. Furthermore, any application developed in conformance to the OMG standard will be able to interact with any other application also conforming to the OMG standard provided such facility for interaction has been built into the particular application.
In section 62.1.4 we stated that the OMG's Object Request Broker (ORB) provides a mechanism whereby objects transparently make and receive requests. Furthermore, the ORB facilitates interoperability of distributed object technology across disparate systems and also provides a seamless interconnection of multiple object systems.
In this paragraph, we will briefly indicate that, if desired, OOPP managers can be used to provide their employees with an environment conforming to OMG's ORB environment. As was mentioned in previous chapters, the responsibilities of OOPP managers can include keeping track of their employees' physical location, routing of messages, employee relocation, etc. By combining a number of these management services, managers can provide their employees with an environment
May 1994 C Kyrialddes Page 261 Conclusion Objed-Oriented Parallel Paradigms
exhibiting distribution transparency. In addition, more specialised managers exist aimed at com munication, interfacing, etc. In particular, special interfacing managers are capable of interfacing incompatible platforms, environments, models, etc. Thus at this stage of the OOpp research it appears that OOPP managers can be used to provide an environment conforming to that required by OMG's ORB. This not only implies that OOPP managers can be used to develop an ORB conforming application, but also that (from section 14.4), applications developed using OOPP can be applied to ORB conforming platforms.
Turning our attention to the table on OMG's Technical Objectives (section 6.2.1.1). It was revealed that by using the indirect message passing approach (described in sections 8.4.2 and 11.2), managers can be used to facilitate Object distribution transparency (corresponding to point 2 in the table). In other words, a client object (an employee) is then regarded to be independent of the server object (also an employee) with regards to the server object's: physical location, access path, relocation, communication mechanism, invocation mechanism, storage mechanism, machine type, operating system, programming language and security mechanism; all of these objectives can be satisfied by managers (a number of these were mentioned during explanatory statements of managers). Other technical objectives of the OMG that appear amenable to OOPP include: pro viding concurrency control for objects (point 8), inheritance of interface (point 1), discretionary access control (point 7), and so on.
It should be kept in mind that the OMG standard and OOPP are aimed at achieving different goals; the OMG standard is aimed at standardisation of object interfaces, while OOPP is aimed at providing a paradigm that can be used in formulating methodologies. At this stage of the OOPP research, we do not see any reason why OOPP managers cannot be used to enable OOPP to meet all the OMG's technical objectives. In fact a number of the OMG's technical objectives and faci lities (such as ORB) have already been shown to be amenable to the OOPP approach.
14.6 Future Research
OOPP is based on two very large topics, (namely Object-Oriented and Parallel Processing). Unfortunately when dealing with a topic as large as OOPP, one has to draw the line somewhere as to what must be regarded as future research. Numerous questions that should be dealt with during future research efforts have been raised and left unanswered throughout our report. Instead of attempting to reiterate all of the unanswered questions in our conclusion, we shall instead opt for mentioning only the most important ones here.
May 1994 C Kyriakides Page 262 Conclusion Objed-Oriented ParaIJel Paradigms
OOpp currently facilitates the existence of Internally Concurrent Objects. (In Object technologies, message passing can serve both as a communication mechanism, as well as, a synchronisation mechanism; however in Object models, externally concurrency relation ships between Objects can be analysed in terms of the messages exchanged). The question on what is the best means of handling/analysing Intemally Concurrent Objects within Object-Oriented models has been left up to future research efforts.
In a model where the Object Class is simply used as a template for the Object instance, groups of Object instances belonging to the same Object Class and residing on a single processor may share a single copy of the execution code. This sharing can be attributed to the fact that only one of the Objects residing in a particular processor can be run at any time instant; (although a pseudo-parallel mode of execution is still possible). The reper cussions of this are obvious: a group of Classes belonging to the same Superclass and residing on the same processor should share their common execution code. However, in models supporting deep hierarchies and metaclasses (e.g., Smalltalk) an application of a substantial size would prohibit this type of sharing of inherited methods; in fact, the sheer number of inherited methods may require a group of neighbouring processors to share the storage of the necessary inherited methods. Furthermore, since Object instances are created dynamically, the question raised is, "what Objects should be placed in what physical processors and what slack should be allowed for the creation of new Object instances?"
For the purpose of effecting Fault Tolerance with Error Recovery, each processor may be wiretapped at a suitable time instance along with the state of each Object residing in the processor. In order to avoid excessive rework after an Error Recovery, the interval between suitable time instances should not be excessivelylarge. What is left over to future research is to determine what is a "suitable time instance".
Certain analytical characteristics arise when a hierarchy of Objects is viewed in terms of the Object Taxonomy proposed in section 5.3. What has been left up to future research efforts is:
The suitability of the Object Taxonomy (as is) to identify all necessary analytical processing characteristics,
The ease of classifying Objects implemented under such a taxonomy on a large-scale multi-processor development.
May 1994 C Kyriakides Page 263 Conclusion Object-Oriented Parallel Paradigms
Whether it is possible to automate the classification of Objects under this taxonomy; and also, automatically act on the analytical characteristics of these Objects.
Whether further investigation of Object State and Method Coupling (section 5.4) can give rise to further benefits than those already presented.
Although processor workloads have been used in a number of existing models (e.g., MITRE model - albeit using a different approach), no research papers could be found to substantiate the suitability of productivity workloads specifically within the context of dis tributed Object-Oriented processing environments. Although benefits are anticipated, the exact nature of what this "productivity" benefits would imply within the Object-Oriented distributed processing environment has been left over to future research.
In the network scenario it was observed that Managers operate rather autonomously from their Super-managers. For this reason, the topmost managers of each (multi-processor or single processor) machine on the network will only require to communicate when abso lutely necessary. Thus, for the larger part of their operation, the managers will operate autonomously within their allocated machines. What has been left up to future research is consideration of all possible means of determining which are the most preferable candi dates to be made topmost managers of each machine; for example, in the event of machines not able to support the OOPP/manager-employee concept, should the topmost manager of such machines be allowed to reside in a different machine? (This is further complicated by the fact that not all machines on a network are identical in resources and/or characteristics).
The message interface between OOPP-scenarios (implemented in COOP) and special resource managers remains to be formulated in future research efforts. As mentioned previously, the encapsulation of internal analysis in the OOPP-scenarios will necessitate special treatment for these special resource managers.
Briefly recapping, the responsibility for managing resources (and access to shared resources) is left up to the special managers. Thus, we have to make available a set of allowable Messages between the OOPP-scenarios' topmost managers and the special man agers so as to interface them together. Because any two OOPP-scenarios are "functionally unrelated" and, any group of OOPP-scenarios can be chosen to be executed on the system concurrently, we deduced that OOPP-scenarios must also be "analytically unrelated". Thus the internal analysis of any OOPP-scenario should be hidden from the special managers
May 1994 C KyriaJddes Page 264 Conclusion Objed..()riented Parallel Paradigms
and other OOPP-scenarios. Instead, only the resource requirements of the OOPP-scenario can be made available to the special managers for resource management processing. The special managers under this circumstance will take on the form of Operating System based Objects. (A subtle implication arising from this statement is that Operating System based Objects like in the Object-based approach of the MITRE model may have specific - not general - areas of suitability).
14.7 OOPP: The final chapter
Paradigms such as OOPP lie at the mercy of future researchers. Should sufficient interest be generated in oopp then a more comprehensive and thorough version of OOPP may make its appearance within the next few years; long before large-scale multi-processor machines capable of harnessing OOPP's power are available.
Based on current trends, OOPP has been successful in presenting a view of typical characteristics expected to be encountered in future Object-Oriented Parallel Systems. However, we cannot predict the future with absolute certainty, and as unlikely as it may seem, a totally new concept may make its appearance in the scientific microcosm causing OOPP to undergo extensive modi fications.
Although some characteristics, such as the Manager-Employee scenario, may (suggestio falsi) be viewed as being exclusively attributed to OOPP, the fact of the matter is that the majority of characteristics incorporated in OOPP are nothing more than modifications/adaptations of estab lished existing ideas. However, what can be attributed to OOPP is the vision to adapt and incor porate established ideas currently existing in the macrocosm of disciplines into the microcosm of computer science.
May 1994 C Kyrialddes Page US Terminology Objec:t-OrienteclParallel Paradigms
Appendix A: Terminology
In order to avoid confusion that may be caused by slightly varying definitions of terminology com monly used in this report, we present each term along with its definition, followed by the paper/book where it was based on in [] brackets. In some cases, two or more alternate definitions are given for a particular term; this is done so as to draw to the attention of the reader, that although the terms used are not perfectly defined, these terms are used in slightlyvarying but almost equivalent interpretations by various authors.
It must be pointed out however, that this report is not concerned with determining which definition is the most appropriate; only that one or more interpretations exist for a particular term. Usually where these multiple definitions vary is in the emphasis or focal point of the defmition. For example, numerous authors use the term Object to refer to both to a class and to an instance of a class; while others use the term Object exclusively for referring to an instance of a class.
All terms followed by the symbol [*] are terms defined solely within the context of presenting the OOpp report. Although all attempts have been made to maintain the "established" meaning of each term, to avoid confusion between the numerous slightly different defmitions that may be encountered in the existing papers, we have defined our own terms.
Abstract Class: Either the same as a meta-class or a Class whose Instances have no concrete interpretation. Sometimes a Class representing an abstract concept. [Graham 1991] Classes that are not intended to produce instances of themselves [Wirfs-Brock 1990].
Abstract Data type: An abstraction, similar to a Class, that describes a set of Objects in terms of an encapsulated or hidden data structure and operations on that structure [Graham 1991]. The encapsulation of data and algorithms that operate on that data. Abstract data types are designed by asking the questions: ''What data does this type subsume?" and "What algorithms can be applied to this data?". [Wirfs-Brock 1989]
May 1994 C Kyriakides Page 266 Terminology Objed.Qriented ParaUel Paradigms
Abstraction: The principle of ignoring those aspects of a subject that are not relevant to the current purpose in order to concentrate more fully on those that are. The act of separating in thought; representing the essential features of something without including background or inessential detail [Oxford 1986].
Access operations: Operations that access the state of an Object but do not modify it [Graham 1991].
Active Communication: Communication achieved by means of electronic communication add-ens to the computer (such as a modem, a Network Interface Card (NIC), etc.) whereby the machine interactively communicates with another machine. [*]
Active Interfacing: Communication can take place at any time while the Server is processing the request of the Client. [*]
Active Object: An Object which can initiate message passing. Or: An Object whose methods are activated by a change in its state; a demon [Graham 1991].
Actor: An Object with an address and a current state which may communicate with other Objects only by message passing. Actors can change their local state, create new Actors and send messages. Actor systems replace inheritance with delegation. [Hewitt 1977]
Accessor Method: A method designed to provide access to the internal data maintained by instances of a class. Such functions are necessary in languages such as Smalltalk where access is not per mitted, and their use generally is considered good programming style even when direct access to the data is available. [Budd 1991]
Agent: An Object which performs some operation at the request of another Object and may in turn operate upon another Object. [Graham 1991]
AKO, A Kind Of: The Inheritance relationship between Classes and their Superclasses. [Graham 1991]
Analysis: the study of a problem prior to taking some action. [De Marco 1978]
Assembly Structure: a means of portraying whole-part organizations. Shows aggregation, reflecting whole and component parts. [Yourdon 1989]
Assertions: Statements of the form 'A is B' in rule-based languages. Also called facts. [Graham 1991]
Asynchronous Algorithms: another term for Relaxed Algorithms.
May 1994 C KyriaJddes Page 267 Terminology Object-Oriented Parallel Paradigms
Attribute: A static, or printable, property of an Object. It cannot exist independently of the Object. Attnbutes may take other Objects as values. See instance variables. [Graham 1991] An attribute is a data element used to describe an instance of an Object or Classification Structure. [Yourdon 1989]
Backward Chaining: A method of search, or inference, which starts with a conclusion and follows a chain of rules backwards to find plausible reasons or causes for the conclusion. [Graham 1991]
Behaviour: The set of methods of an Object defines its behaviour. [Graham 1991]
Behaviour Sharing: A form of polymorphism, when several entities have the same interface. This is achieved by inheritance or operator overloading. [Graham 1991]
Binding: The process by which a name or an expression is associated with an attribute, such as a variable and the type of value the variable can hold. [Budd 1991]
Binding Time: The time at which binding takes place. Early or static binding generally refers to binding performed at compile time, whereas late or dynamic binding refers to binding performed at run time. [Budd 1991]
Browser: A tool to help programmers navigate visually through the classification structures of a sys tem, following inheritance links. [Graham 1991]
Category: A mathematical abstraction, more general than 'sets and functions', 'groups and homo morphisms', 'topological spaces and continuous functions', all of which are categories. A category consists of Objects and arrows subject to certain axioms. The arrows represent general structure-preserving mapping. [Graham 1991]
Class-Based: Systems characterised by Objects and Classes; have no Inheritance. [Wegner 1988]
Class-Qriented: Object-based systems in which every instance belongs to a Class, but Classes may not have Superclasses. [Graham 1991] (same as Class-Based).
Class: An abstraction of a set of Objects that specifies the common static and behavioural characteristics of the Objects, including the public and private nature of the state and behaviour. A Class is a
May 1994 C Kyriakides Page 268 Terminology Objed-Oriented ParaUel Paradigms
template from which Object Instances are created. [Graham 1991] Syn. object type. An abstract description of the data and behaviour of a collection of similar objects. The representatives of the collection are called instances of the class. [Budd 1991]
Class variable: An attribute which is inherited by all Subclasses and Instances of the Class it belongs to. The values of Class variables may be Inherited by Subclasses. [Graham 1991]
Classification, AKO or IsA structure: A tree or network structure based on the semantic primitives of inclusion (AKindOf) and membership (IsA) which indicates that Inheritance may implement specialisation or generalisation. Objects may participate in more than one such structure, giving rise to Multiple Inheritance. [Graham 1991]
Classification Structure: a means of representing generalization-specialization (Class-Member) orga nization of Objects. [Yourdon 1989]
Classification Theory: the methodology and philosophy involved in the grouping of entities together into Classes on the basis of some principle of kinship, and the making of distinctions between such Classes. [Encyclopaedia Britannica]
Client/Server Model: The advantage of the client/server model is that it focuses on "what" the server does for the client, rather than "how" the server does it. Thus, the implementation of the server is encapsulated - locked away from the client. (Also see Client and Server).
Client: The Client requests the Server to perform Services on its behalf. An Object whicb uses the services of another, server, Object. That is, clients can send messages to servers. [Graham 1991]
Composition (or part-of) hierarchy: A tree structure based on the semantic primitive part-of which indicates that certain Objects may be assembled from collections of other Objects. Objects may participate in more than one such structure. [Graham 1991]
Concurrent Object-Oriented Paradigms (COOP): Identical to OOPP in all regards except the number of problems solved simultaneously. OOPP is aimed at solving a single problem while COOP is aimed at one or more problems. [.]
Concurrent Process: A process that may have multiple active threads. [Wegner 1989]
May 1994 C KyriaJddts Page 269 Terminology Objed..()riented ParalIel Paradigms
Concurrent Processing: a kind of infonnation processing that emphasizes the concurrent manipulation of data elements belonging to one or more processes solving one or lIlol'e problems. [*]
Constroctor operations: Methods which create and initialise the state of an Object. [Graham 1991]
Data-Driven Design: the result of adapting abstract data type design methods to Object-Oriented programming. Objects are designed by asking the questions: "What (suucture) does this Object rep resent?" and "What operations can be pesformed on this Object?" [W"trfs-Brock 1989]
Data Abstraction: the principle of defining a data type in terms of the operations that apply to Objects of the type, with the constraint that the values of such Objects can be modified and observed only by the use of operations. [Oxford 1986]
Data Semantics: Specification of the meaning of data and their relationships; specifically multiplicity and modality of relationships, inheritance and composition. These relationships include integrity constraints. [Graham 1991]
Data Type: Same as type. [Graham 1991]
DBMS: Database Management System
Declarative Semantics: same as functional semantics.
Delegation: In Actor systems, the passing of responsibility to carry out a method to another Object. A fonn of Classless Inheritance. [Graham 1991] An alternative to class-based organisation. Using delegation, objects can defer the implementation of behavior to other objects, ca1Ied delegates. This technique permits sharing of behaviour without the necessity to introduce classes or inheritance.
Demon: An Object or procedure which is activated by a change of state; a data driven procedure. The same as a trigger. [Graham 1991]
Destructor Operations: Methods which destroy Objects and reclaim their space.
Dynamic Binding: The allocation of storage at run time rather than compile time. [Graham 1991]
Early Binding: The same as static binding.
May 1994 C Kyriakides Page 270 Terminology Objed-Oriented ParaDel Paradigms
Encapsulation: The scoping of unrestricted reference to an Object. Objects may examine or change their own state, but its accessor methods prevent other Objects from making inappropriate requests or updates. Closely related to the concept of information hiding. [Graham 1991)
Exclusively-Sequential Objects: any Object that is both Internally-Sequential and Externally Sequential. [*]
Externally-Concurrent Objects: any Object that is Mutually-Concurrent to at least one Object. [*]
Externally-8equential Objects: any Object that is Mutually-Sequential to all other Objects. [*]
Forward Chaining: A method of search, or inference, which starts with one or more facts and follows a chain of rules forwards to find one or more consequences of the facts. [Graham 1991]
Frame: A data structure used in artificial intelligence similar to an Object. Frames have slots which may contain data and procedures. [Graham 1991]
Friend: In C++, a method of an Object with privileged access to the private implementation of another Object. [Graham 1991]
Functional Semantics: The specification of the meaning of the procedural and control aspects of an Object. In particular, the specification of rules for triggers, conflict resolution, handling exceptions, control regimes and general business rules. [Graham 1991]
Functor: A mapping or homomorphism between categories in mathematics. Functors map Objects to Objects and arrows to arrows in such a waythat composition of arrows is preserved. [Graham 1991]
Garbage Collection: The process of reclaiming the core storage occupied by Objects no longer in use or reachable from the current task image.
Generic Package: An Ada package that includes generic parameters. [Graham 1991}
Genericity: The ability to parameterise Classes; a special case of inheritance. [Graham 1991]
Grain Size: the relative amount of work done between synchronisations.
Granular Objects: From the perspective of analysis, any Object that cannot prove more beneficial if broken down into smaller Objects. In essence, from an analytical perspective, Granular Objects and are accepted to be the very basic building blocks of Non-Granular Objects. [.]
Implementation: The private or hidden features of an Object. [Graham 1991]
May 1994 C Kyrialddts Page 271 Terminology Objed'()riented Parallel Pantdlgms
Inferential distance ordering: The partial ordering of an inheritance network according to the number of superclasses through which a value is inherited. The distance is the number of steps in the inheritance chain. [Graham 1991]
Infonnation Hiding: A principle used when developing an overall program structure where each component of a pro gram should encapsulate or hide a single design decision. The interface to each module is defined in such a way as to reveal as little as possible about its inner workings. [Oxford 1986] The principle which states that the state and implementation of an Object or module should be private to that Object or module and only accessible via its public interface. Closely related to encapsulation. [Graham 1991] The principle that users of a software component (such as a class) need to know only the essential details of how to initialise and access the component. and do not need to know the details of the implementation. By reducing the degree of interconnectedness between separate elements of a software system. the principle of information hiding helps in the development of reliable software. [Budd 1991]
Inheritance: The relationship between Classes whereby one Class inherits all or part of the description of another more general Class. and Instances inherit all the properties and methods of the Classes they belong to. [Graham 1991] The property of Objects by which instances of a class can have access to data and method defini tions contained in a previously defined class. without those definitions being restated. [Budd 1991] Properties or characteristics received from an ancestor. In OOA in particular. Inheritance is the explicit representation of Attribute and Service commonalty. [Yourdon 1989]
Instance: A particular Object or individual example of a Class. [Graham 1991]
Instance Variable: A data-holding attribute contained within a system that describes the state of that instance. Only the declaration of an Instance variable. not its value. may be inherited by SubClasses. See also Attribute and Class Variable. [Graham 1991]
Instantiation: The creation of a data item representing a Variable or a Class - giving value to something. [Graham 1991]
May 1994 C Kyriakides Page 272 Tenninology ObJect-Oriented ParaDel Paradigms
Interface: The visible methods of an Object. [Graham 1991] An Interface establishes communication between two systems/applications in a fashion whereby the first application acts as the client requesting the Services of the second application; and the second application acts as the server providing those Services. Information may also be exchanged between the Client and Server during the interfacing. [*]
Internally-Concurrent Objects: any Object that is either Method-Internally-Concurrent, or Method Externally-Concurrent, or both. [*]
Internally-Sequential Objects: any Object that is both Method-Internally-Sequential and Method Externally-Sequential. [*]
IsA: The inheritance relationship between Instances and their Classes as in: 'Jane Gray IsA PERSON' [Graham 1991]
IsA relation: The relation that asserts that instances of a subclass must be more specialised forms of the superclass. Thus instances of a subclass can be used where quantities of the superclass type are required. [Budd 1991]
Iterator: A method that permits all parts of an Object to be visited.
Late Binding: The same as Dynamic Binding.
Layer: A partition of a diagram with only a few Objects treated as a composite Object communicating with other layers. [Graham 1991]
Message: A request for an Object to carry out one of its operations. [Graham 1991] A narrow, well-defined interface between Objects. [Yourdon 1989]
Message Passing: The philosophy that Objects only interact by sending messages to each other that request some operations to be performed. [Graham 1991]
Meta-Class: In languages like SmaIltalk, a Class whose Instances are Classes, as opposed to an Abstract Class that has no Instances, only SubClasses. [Graham 1991]
Method-Externally-Concurrent Objects: Objects that can have multiple methods executing concur rently. [*]
May 1994 C Kyriakides Page 273 Terminology Objed..()Jiented Parallel Paradigms
Method-Externally-Sequential Objects: Objects whose methods may execute only in a sequential fashion (i.e., one method at a time). [*]
Method-Internally-Concurrent Objects: Objects that can exhibit concurrency within a single method. [*]
Metbod-Internally-Sequential Objects: Objects whose methods are intrinsically sequential. [*]
Method: A procedure or function which an Object can perform. [Graham 1991]
Moon: An Abstract Class containing a package of methods which can be inherited by (mixed into) any Class. [Graham 1991]
Monomorphism: The opposite of polymorphism, where a message may only have one, system-wide, interpretation. [Graham 1991]
Multi-processor: a computer having more than one processor. (The terms multi-processor and multi processor are not equivalent in this report). [*]
Multicomputer architectures attempted to overcome the presence of a bottleneck similar to that of the Multiprocessor model by avoiding global memory altogether. Instead processor-memory pairs exist where each processor has its own memory, and communication between processors is achieved by means of sending information from processor to processor until the appropriate processor is reached.
Multiple-Instruction stream, Multiple Data stream (MIMD): Most parallel computers fall under this category. As Flynn's taxonomy is exceptionally vague in this category, for this research the label MIMD is reserved for multiple-CPU computers designed for parallel and concurrent processing: that is, computers designed to allow efficient interactions among their CPUs. (Early multi processors had little interaction amongst processors). This also excludes computer architectures having multiple exclusively "dedicated" CPUs, where each CPU is dedicated to one particular task or peripheral; for example, one processor (CPU) for program execution and another processor (channel) for I/O processing.
Multiple-Instruction stream, Single Data stream (MISD): No computers fall under this category.
Multiple Inheritance: Inheritance where a more specialised Object can inherit its description from more than one general Class and where contradictions may result. [Graham 1991]
May 1994 C Kyriakides Page 214 Terminology Objed'()riented Parallel Paradigms
Multiple Objects: Objects that may have more than one Object instance at any particular time; and may be replicated. [*)
Multiprocessor architectures attempted to make common data available to various processors by means of implementing a global memory which all processors could access. (also see multi processor)
Mutually-Concurreut Objects: Any two Objects where the methods of the one Object may execute concurrently to the other Object's methods. [*)
Mutually-Sequential Objects: Any two Objects where the methods of the one Object may not execute concurrently to the other Object's methods. [*)
Non-Granular Objects: Objects that may be analytically broken down into smaller Objects. [*)
Object-based: Systems are Object-based when they allow Objects to encapsulate both data and methods and when they enforce Object identity. [Graham 1991) Systems characterised by Objects; have no Classes or Inheritance, [Wegner 1988].
Object-identity: The rule that Objects have a unique identity throughout their existence. [Graham 1991)
Object-orientation In Information Modeling: a representation of some real-world thing and some number of instances of that thing. In Object-Oriented Programming Languages: a run-time instance of some processing and values, defined by a static description called a "Class". [Yourdon 1989]
Object-Oriented: Systems characterised by Objects, Classes and Inheritance. [Wegner 1988)
Object-Oriented Analysis (OOA) [Yourdon 1989] uses Objects as abstractions of the real world in order to provide a focus on gaining significant problem space understanding.
Object-Oriented Parallel Paradigm (OOPP): A general-purpose paradigm linking the Object-Oriented and Parallel Processing methodologies into one homogeneous body. OOPP is aimed at development of systems/applications with the objective of solving a single problem while using both Object Oriented and Parallel Processing techniques. [*]
May 1994 C Kyriakides Page 275 Terminology Objed-Oriented ParaDeI Paradigms
Object-to-Processor Density is defined to be the Number of Objects / Number ofProcessors. In other words, given a group of processors we can establish the total number of Objects assigned to those processors and thus determine the Object-te-Processor Density. [.)
Object: An abstractionof data and exclusive processing on that data, reflecting the capabilities of a system to keep information about or interact with something in the real world [Yourdon 1989). An Object is a package of information and a description of its manipulation. [Oxford 1986) Anything that can be named. A Class or an Instance of a Class. [Graham 1991)
Object Type: Syn. Class. (Object Pascal) A data structure, similar to a Pascal record type definition, that can contain fields (methods) of procedures and functions, as well as data fields. [Budd 1991)
OOPP-scenario: Any hierarchical group of connected Objects whose anatomy represents an OOPP (manager-employee) hierarchy and, where all communication outside this group is forced to take place via the topmost manager of the group. Furthermore, no communication is allowed outside the OOPP-scenario except for resource management related messages (this includes obtaining access to, as well as, inputting from and outputing to the resource). [.]
OOPP: Acronym for Object-Oriented Parallel Paradigm. [.]
Operation: forms part of the public interface of an Object. Used to specify the method as well as the arguments or at least the argument types required by that particular method. [.] (Graham [1991] defines an operation as a method.)
Operator Overloading: A special case ofpolymorphism; attaching more than one meaning to the same operator symbol. 'Overloading' is also sometimes used to indicate using the same name for different Objects. [Graham 1991)
Override: The ability to change the definition of an inherited method or attribute in a SubClass.
Package: An Ada construct that combines a set of declarations into a single program unit which can be used to create an abstract data type. [Graham 1991}
Parallel Processing is a kind of information processing that emphasizes the concurrent manipulation of data elements belonging to one or more processes solving a single problem. [Quinn 1987)
May 1994 C Kyriakides Page 276 Terminology Objed'()riented ParaDe( Paradigms
Partitioned Algorithms are characterised by the sharing of computation in which processors assume different computational duties. A problem is divided into subproblems that are solved by individual processors. The solutions to the subproblems are then combined to form the problem solution. This pooling of solutions implies synchronisation among processors; for this reason partitioned algo rithms are sometimes called synchronised algorithms.
Passive Communication: Communication achieved by means of a removable storage media (such as a floppy disk, backup tape, etc.), [*]
Passive Interfacing: From the time the Server begins processing the request of the Client, no com munication may take place between the Client and Server until the Server has finished processing the Client's request. [*]
Persistence: The property of Objects to persist in terms of identity, state and description through time, regardless of the computer session which created or uses them. Objects stored, ready for use, on secondary storage. [Grant 1991]
Pipelined Algorithms are characterised by an ordered set of segments in which the output of each segment is the input of its successor. The input to the algorithm serves as the input of the first segment; the output of the last segment is the output of the algorithm. As in all pipelines, all segments must produce results at the same rate, or else the slowest segment will become a bottleneck.
Polymorphic: An operator whose meaning depends on the types of its operands is called overloaded, polymorphic, or generic. [Ghezzi 1987]
Polymorphic Messages: A message interpreted differently when received by different Objects.
Polymorphism: The ability of an Object or operator to refer to instances of different Classes at run time.
Prescheduled Algorithms are a kind of Partitioned Algorithms were each process is allocated its share of the computation at compile time. Prescheduling is the norm when a computation consists of a large number of subtasks, each of a known complexity.
Private: That part of an Object, Methods or Attributes, which may not be accessed by other Objects, only by SubClasses or Instances. [Graham 1991]
May 1994 C Kyrialddes Page 2n Terminology Objed-Oriented Parallel Paradigms
Procedural Abstraction: The principle that any operation that achieves a well defined effect can be treated by its users as a single entity, despite the fact that the operation may actually be achieved by some lower-level operations. [Oxford 1986]
Protocol: The set of methods of an Object.
Public: That part of an Object, Methods or Attributes, which may be accessed by other Objects. The public part of an Object constitutes its interface. [Graham 1991]
Quasi-Concurrent Process: A process that has at most one active thread [Wegner 1989]
Relaxed algorithms work without process synchronisations. All the processes may be working toward the same goal (as in partitioning), or there may be some specialisation of purpose (as in pipelining), but the essential element is that no processor ever has to wait for another processor to provide it with data. Instead, relaxed algorithms are characterised by the ability of processors to work with the most recently available data. Some authors prefer the term Asynchronous Algorithms.
Responsibility-Driven design focuses on the contract by asking: mat actions is this Object responsible for?" and "What information does this Object share?". [Wirfs-Brock 1989]
Rules: H...then... statements. Rules are regarded as independent and their order does not matter. Because of this, rule-based languages are non-procedural.
Selector operation: A method which can access but not alter the state of an Object. [Graham 1991]
Self-Recursion: The ability of an Object to send messages to oneself.
Self-Reference: The same as self-recursion; being able to refer to oneself in a method. [Graham 1991]
Self-5cheduling Algorithms are a kind of Partitioned Algorithms in which the work is not assigned to the processes until run-time. In a self-scheduled algorithm a global list of work to be done is kept, and when a process is without work, another task is removed from the list. Processes schedule themselves as the program executes, hence the name.
Sequential Process: A process that has just one thread. [Wegner 1989]
Server: An Object which suffers operations but may not act upon other Objects. It may only send messages to other Objects as a result of a request from them, unless it is also a client of other Servers. (See Client) [Graham 1991] Provides a set of Services upon request from a Client.
May1994 C Kyrialides Page 278 Terminology Object-Oriented ParaDe. Paradigms
Service: the processing to be performed upon receipt of a message. Alternatively, Services represent the processing requirements for each Object, encapsulated and treated with the Attributes as an intrinsic whole. [Yourdon 1989]
Set Abstraction: Considering concrete Instances as belonging to a Class defined by abstract properties or predicates. [Graham 1991]
Single-Instruction stream, Multiple Data stream (SIMD): In any time unit a single operation is in the same state of execution on multiple processing units, each manipulating different data. Processor A1rays fall under this category. A processor array executes a single stream of instructions, but contains a number of arithmetic processing units, each capable of fetching and manipulating its own data.
Single-Instruction stream, Single Data stream (SISD): Even though instruction execution may be pipelined, computers in this category can decode only a single instruction at a time. Most serial computers fall under this category.
Slot: The word used in AI frame systems for Attributes. Note that the Attributes of frames can contain Methods. An Instance Variable in CWS. [Graham 1991]
Software Lockout: Contention between processors for data resources.
Speedup is the ratio between the time needed for the most efficient sequential algorithm to perform a computation, and the time needed to perform the computation on a machine incorporating pipelining and/or parallelism.
Static Binding: The opposite of dynamic binding. Values are bound to Variables, or Methods to Messages, at compile time. Also called early binding. [Graham 1991]
Strong Typing: The property of a programming language which ensures that all expressions are guaranteed to be type consistent. [Graham 1991]
Structure: A Structure represents complexity in a problem space. Classification Structure portrays Class Member organization, reflecting generalization-specialisation. Assembly Structure shows aggrega tion, reflecting whole and component parts. [Yourdon 1989] Represents complexity in a problem space. Structure is a fundamental method of human organization used to represent complexity in a problem space (see Classification and Assembly
May 1994 C Kyriakides Page 279 Terminology Objed'()rienled Panallel Paradigms
structure). [Yourdon 1989] In Object-Oriented Analysis, a linked set of Objects. Structures are of three main kinds: Classifi cation, Composition, and Use. [Graham 1991]
SubClass: A Class which has an AKO link to a more general Class; as in, 'A DOG is AKindOf MAMMAL'. [Graham 1991] Syn. descendant type, derived class. (Smalltalk) A class that inherits from another class. [Budd 1991]
Subject: A Subject is a mechanism for controlling how much of a model a reader considers at one time. [Yourdon 1989] In Yourdon [1989], the same as a layer. [Graham 1991]
SuperClass: A Class which has one or more members which are (more specialised) Classes themselves [Graham 1991]. Syn. ancestor type, bose class. (Smalltalk) A class from which another class inherits attributes [Budd 1991].
Synchronised Algorithms: see Partitioned Algorithms.
Throughput of a device is the number of results it produces per unit time.
Trigger: A demon. A rule which fires in response to a change of state. [Graham 1991]
Type: A set together with operations defmed on this set. (See Abstract Data Type). [Graham 1991]
Unique Objects: An Object is a Unique Object if only one such Object instance may occur at any particular time. [*]
Use Structure: The structure of relationships between Clients and Servers connected by message passing. [Graham 1991]
Virtual Storage: The key concept in virtual storage is to disassociate the address referred to in a running process from the address available in primary memory. Hence, there is a process's virtual address space [V] and a computer's real address space [R]. The virtual address space is then be mapped into the real address space as the process executes.
VISibility: The ability of one Object to be a Server to others.
Weak Typing: The opposite of Strong Typing. Type errors may occur at run time. [Graham 1991]
May 1994 C Kyriakides Page 280 References Objed'()riented ParaDel Paradigms
References
[Agha 1986] Agha G, ACTORS: A Model of Concurrent Computation in Distributed Systems, The MIT Press, 1986
[Agha 1987a] Agha G and Hewitt C, "Concurrent Programming Using Actors", Object-Oriented Con current Programming, pp37-54, ed, Yonezawa A and Tokoro M, MIT Press, 1987
[Agha 1987b] Agha G and Hewitt C, "Actors: A Conceptual Foundation for Concurrent Object Oriented Programming", Research Directions in Object-Oriented Programming, pp49-74, ed, Shriver B and Wegner P, MIT Press, 1987
[Ahlsen 1985] Ahlsen M, Bjornerstedt A and Hulten C, "OPAL: An Object-Based System for Application Development", IEEE Database Engineering, Vol 8, No 4, pp31-40, 1985
[America 1987] America P, "POOL-T: A Parallel Object-Oriented Language", Object-Concurrent Programming, ed. Yonezawa A and Tokoro M, ppl99-220, MIT Press, 1987
[Andrews 1983] Andrews G and Schneider F, "Concepts and Notations for Concurrent Programming", ACM Computing Surveys, VollS, No 1, pp3-43, March 1983
[ANSI 1983] American National Standards Institute, The Programming Language Ada Reference Manual; Springer-Verlag, 1983
[Baase 1978] Baase S, Computer Algorithms: Introduction to Design and Analysis, Addison-Wesley, 1978
[Baer 1982] Baer JL, "Techniques to exploit parallelism", Parallel Processing Systems: an advanced course, p75-99, ed. Evans OJ, Cambridge University Press, 1982
[Banerjee 1987a] Banerjee J, Chou H, Garza JF, Kim W, Woelk D, Ballou N and Kim H, "Data Model Issues for Object-Oriented Applications", ACM Transactions on Office Information Systems, Vol 5, No 1, pp3-26, 1987
[Banerjee 1987b] Banerjee J, Kim W, Kim HJ and Korth HF, "Semantics and Implementations of Schema Evolution in Object-Oriented Databases" Proceedings ofthe ACM SIGMOD '87, Vol 16, No 3, pp311-322, 1987
[Beech 1987] Beech D, "Groundwork for an Object Database Model", Research Directions in Object Oriented Programming, ed. Shriver B and Wegner P, p317-554, MIT Press, 1987
May 1994 C Kyrialddes Page 281 References Object.()riented Parallel Paradigms
[Bensley 1988] Bensley EH, Brando TJ and PrelIe MI, "An Execution Model For Distributed Object-Oriented Computation", ACM OOPSLA '88 Proceedings, September 1988
[Bensley 1989] Bensley EH, Brando TJ, Fohlin JC, PrelIe MI, and Wol1rath AM, "MITRE's Future Generation Computer Architectures Program", Sigplan Notices Vol 24, No 4, pp99-101, Aprll1989
[Black 1986a] Black A, Hutchinson N, JuI E and Levy H, "Object Structure in the Emerald System", OOPSLA '86: Sigplan Notices, Vol 21, No 11, pp78-86, 1986
[Black 1986b] Black A, Hutchinson N, JuI E, Levy H and Carter L, "Distribution and Abstract Types in Emerald", IEEE Transaction on Software Engineering, Vol 12, No 12, December 1986
[Blair 1991] Blair G, Gallagher J, Hutchison D and Shepherd D, Object-Oriented Languages, Systems and Applications, Pitman Publishing, 1991
[Bobrow 1983) Bobrow DG and Stefik M, "The LOOPS Manual", Xerox Corporation, 1983
[Bobrow 1986] Bobrow DG, Kahn K, Kiczales G, Masinter L, Stefik M and Zdybel F, "Commo nLOOPS: Merging Lisp and Object-Oriented Programming", OOPSLA '86: Si[!JJlan Notices, Vol 21, No 11, pp17-29, 1986
[Booch 1991] Booch G, Object-Oriented Design with Applications, Benjamin Cummings, 1991
[Bred 1989] Bretl R, Maier D, Otis A, Penney J, Schuchardt B, Stein J, Harold-Williams E and Williams M, "The GemStone Data Management System", Object-Oriented Concepts, Databases and Applications, ed. Kim W and Lochovsky PH, pp283-308, ACM Press, Addison-Wesley, 1989
[Budd 1991] Budd T, An Introduction to Object-Oriented Programming, Addison-Wesley, 1991
[Cannon 1982] Cannon ill, "Flavors: A Non-Hierarchical Approach to Object-Oriented Program ming", Symbolics Inc., 1982
[Cardelli 1985] Cardelli L and Wegner P, "On Understanding Types, Data Abstraction, and Poly morphism", ACM Computing Surveys, Vol 17, No 4, pp471-522, December 1985
[Casais 1988] Casais E, "An Object-Oriented System Implementing KNOs", Proceedings of the Con ference on Information Systems (COIS), pp284-290, March 1988
[Clinger 1981] Clinger W, Foundations ofActor Semantics", AI-TR-633, MIT AIL, May 1981
[Clocksin 1984] Clocksin WF and Mellish CS, Programming in PROLOG, Springer-Verlag, 1984
May 1994 C Kyrialddes Page 282 References Objed-Oriented ParaDel Paradigms
[Cook 1989] Cook W, "A Denotational Semantics of Inheritance and its Correctness", OOPSlA 1989.
[Cox 1986] Cox BJ, Object-Oriented Programming: an Evolutionary Approach, Addison-Wesley, 1986
[Curry 1982] Curry G, Baer L, Lipkie D and Lee B, 'TRAITS: An Approach to Multiple Inheritance Subclassing", Proceedings ofthe ACM SIGOA, SIGOA Newsletter, Vol 3, No 12, 1982
[Dally 1986] Dally WJ, A VLSI Architecture for Concurrent Data Structures, PhD. thesis, California Institute of Technology, 1986
[Danforth 1988] Danforth S and Tomlinson C, "Type Theories and Object-Oriented Programming", ACM Computing Surveys, Vol 20, No 1, pp29-72, March 1988
[Day 1983] Day JD and Zimmerman H, The OSI Reference Model; Proc. of the IEEE, vol 71, pp1334-134O, December 1983
[De Marco 1978] De Marco T, Structured Analysis and system specification, Yourdon Press/Prentice Hall, 1978
[Deasington 1988] Deasington RJ, X25 Explained: Protocols for Packet Switched Networks, 2nd ed,
[Derrett 1985] Derrett N, Kent W and Lyngbaek P, "Some aspects of Operations in an Object Oriented Database", IEEE Database Engineering; Vol 8, No 4, pp66-74, 1985
[Dhas 1986] Dhas CR and Konangi VK, X25: An Interface to Public Packet Networks, IEEE Com mUD. Magazine, Vol 24, pp118-125, September 1986
[Encyclopaedia Britannica] "Animal Behavior", "Classification Theory", "Mood", Encyclopaedia Bri tannica
[Fisher 1989] FISher A, CASE: Using Software Development Tools, John Wiley & Sons, 1989
[Fishman 1987] FIShman DH, Beech D, Cate HP, Chow EC, Connors T, Davis JW, Derrett N, Hoch CG, Kent W, Lyngbaek P, Mahbod B, Neimat MA, Ryan TA and Shan MC, "Iris: An Object Oriented Database Management System", ACM Transactions on Office Information Systems, Vot5, No 1, pp48-69, January 1987
[Fishman 1989] FIShman DH, Annevelink J, Chow E, Connors T, Davis JW, Hasan W, Hoch CG, .Kent W, Leichner S, Lyngbaek P, Mahbod B, Neimat MA, Risch T, Shan MC and Wilkinson WK, "Overview of the IRIS DBMS", Object-Oriented Concepts, Databases and Applications, ed. Kim W and Lochovsky FH, ACM Press, Addison-Wesley, 1989
May 1994 C KyriaJddes Page 283 References Objed'()riented Parallel Paradigms
[Flynn 1966] Flynn MJ, "Very high-speed computing systems", Proceedin&J of the IEEE, Vol 54, No 12, pl901-1909, December 1966
[Gentleman 1981] Gentleman WM, "Message Passing Between Sequential Processes: The Reply Primitive and the Administrator Concept", Software-Practise and Experience, Vol 11, pp435466, 1981
[Ghezzi 1987] Ghezzi C and Jazayeri M, Programming Language Concepts, John Wiley & Sons, 1987
[Goldberg 1983] Goldberg A and Robson D, Smalltalk-80: The Language and its Implementation, Adison-Wesley, 1983
[Goldberg 1984] Goldberg A, Smalltalk-80: The Interactive Programming Environment, Addison Wesley, 1984
[Goodman 1977] Goodman SE and Hedetniemi ST, Introduction to the Design and Analysis ofAlgo rithms, McGraw-Hill, 1917
[Graham 1991] Graham I, Object-Oriented Methods, Addison-Wesley, 1991
[Halbert 1987] Halbert DC and O'Brien PO, "Using Types and Inheritance in Object-Oriented Lan guages", ECOOP, pp23-34, 1987
[Henshall 1988] Henshall J and Shaw A, OSI Explained. End to End Computer Communication Standards, Ellis Horwood, 1988
[Herlihy 1989a] Herlihy MP and Wing JM, "Linearizable Concurrent Objects", Sigplan Notices, Vol 24 No 4, pp133-135, April 1989
[Hewitt 1977] Hewitt C, "Viewing Control Structures as Patterns of Message Passing", Joumal of Artificial Intelligence, Vol 8, No 3, pp323-364, June 1977
[Hoare 1978] Hoare CAR, "Communicating Sequential Processes", Communications ofthe ACM, Vol 21, No 8, pp666-677, August 1978
[Hoare 1985] Hoare C, Communicating Sequential Processes, Prentice-Hall, 1985
[Hockney 1981] Hockey RW and Jesshope CR, Parallel Computers: Architecture, Programming and Algorithms, Adam Higler, 1981
[IEEE 1985a] IEEE 802.3: Carrier Sense Multiple Access with Collision Detection, New York: IEEE, 1985
May 1994 C Kyriakides Page 284 References Objed-Oriented Parallel Paradigms
[IEEE 1985b] IEEE 802.4: TOken-Passing Bus Access Method, New York: IEEE, 1985
[IEEE 1985c] IEEE 8025: Token Ring Access Method, New York: IEEE, 1985
[Ishikawa 1986] Ishikawa Y and Tokoro M, "A Concurrent Object-Oriented Knowledge Representa tion Language Orient84/K: Its Features and Implementation", OOPSLA, Sigplan Notices, Vol 21, No 11, pp232-241, 1986
[Ishikawa 1987] Ishikawa Y and Tokoro M, "Orient84/K: An Object-Oriented Concurrent Program ming Language for Knowledge Representation", Object-Oriented Concurrent Programming, ed. Yonezawa A and Tokoro M, pp159-198, MIT Press, 1987
[Jefferson 1987] Jefferson D, Beckman B, Wieland F, Blume L, DiLoreto M, Hontalas P, Laroche P, Strudevant K, Tupman J, Warren V, Wedel J, Younger H, and BeUenot S, "Distributed Simulation and the Time Warp Operating System", Proceedings of the Eleventh ACM Symposium on Operating Systems Principles, ppn-93, 8-11 Nov 1987, Austin, Texas.
(Jones 1986] Jones MB and Rashid RF, "Mach and Matchmaker: Kernel and Language Support for Object-Oriented Distributed Systems", OOPSLA: Sigplan Notices, Vol 21, No 11, pp67-77, 1986
(Ju11987] Jul E, Levy H, Hutchinson N and Black A, "Fine-Grained Mobility in the Emerald System", Proceedings of the Symposium on Operating Systems Principles - 1987, pp62-74, October 1987
[Kahn 1986] Kahn K, Tribble E, Miller M and Bobrow D, "Objects in Concurrent Logic Program ming Languages", OOPSLA, Sigplan Notices, Vol 21, No 11, pp242-257, 1986
[Kahn 1987] Kahn K, Tribble E, Miller M and Bobrow D, "Vulcan: Logical Concurrent Objects", Research Directions in Object-Oriented Programming, ed. Shriver B and Wegner P, pp75-112, MIT Press, 1987
[Keene 1989] Keene SE, Object-Oriented Programming in COMMON LISP, Addison-Wesley, 1989
[Kernighan 1988) Kernighan BW and Ritchie DM, The C Programming Language, Prentice-Hall, 1988.
[Kim 1989a) ed. Kim W and Lochovsky FH, Object-Oriented Concepts, Databases and Applications, ACM Press, Addison-Wesley, 1989
[Kim 1989b] Kim W, Ballou N, Chou HT, Garza JF and Woelk D, "Features of the ORION Object-Oriented Database System", Object-Oriented Concepts, Databases and Applications, ed, Kim Wand Locbovsky FH, pp251-282, ACM Press, Addison-Wesley, 1989
May 1994 C Kyriakides Page 28S References Objed-Oriented Parallel Paradigms
[Kristensen 1987] Kristensen B, Madsen 0, Moller-Pedersen B and Nygaard K, "The BETA Pro gramming Language", Research Directions in Object-Oriented Programming, ed, Shriver B and Wegner P, pp7-48, MIT Press, 1987
[Leathers 1990] Leathers B, "Cognos and Eiffel: A Cautionary Tale"HOOT, Vol 1, No 9, ppl-8, 1990
[Lecluse 1988] Lecluse C, Richard P and Velez P, "01. An Object-Oriented Data Model", ACM International Conference on the Management ofData, Chicago, 1988
[Lieberherr 1988] Lieberherr K, Holland I, and Riel A, "Object-Oriented Programming: An Objective Sense of Style", Sigplan Notices Vol 23, No l2, December 1988 also appears in OOPSLA, p323-334, San Diego, California, September 1988
[Lieberherr 1989] Lieberherr K and Holland I, "Formulations and Benefits of the Law of Demeter", Sigplan Notices Vol 24, No 3, pp67-78, March 1989
[Lieberman 1985] Lieberman H, "Object-Oriented Programming Languages", The Encyclopaedia of Artificial Intelli gence, ed. Shapiro S, Wiley, 1985
[Lieberman 1986] Lieberman H, "Using Prototypical Objects to Implement Shared Behaviour in Object-Oriented Systems", OOPSLA: Sigplan Notices, Vol 21, No 9, pp214-223, 1986
[Lieberman 1987] Lieberman H, "Concurrent Object-Oriented Programming in Act 1", Object Oriented Concurrent Programming, ed. Yonezawa A and Tokoro M, pp9-36, MIT Press, 1987
[Liskov 1981] Liskov BH and et aI., "The CLU Reference Manual", Springer-Verlag, 1981
[Liskov 1983] Liskov B and Scheller R, "Guardians and Actions: Linguistic Support for Robust, Distributed Programs", ACM Transactions on Programming Languages and Systems, Vol 5, No 3, pp381-404, 1983
[Liskov 1986] Liskov B and Guttag J, Abstraction and Specification in Program Development, MIT Press, 1986
[Maier 1986] Maier D, Stein J, Otis A and Purdy A, "Development of an Object-Oriented DBMS", OOPSLA: Sigplan Notices, Vol 21, No 11, pp472-482, 1986
[Maier 1987] Maier D and Stein J, "Development and Implementation of an Object-Oriented DBMS", Research Directions in Object-Oriented Programming", ed. Shriver B and Wegner P, MIT Press, 1987
May 1994 C Kyriakides Page 286 References Objed-Oriented ParaDe) Paradigms
[Manola 1986] Manola F and Dayal U, "PDM: An Object-Oriented Data Model", International Workshop on Object-Oriented Database Systems, California 1986
[Mercado 1987] Mercado A, "Hybrid: Implementing Classes with Prototypes", Technical Report CS 88-12, Department of Computer Science, Brown University, 1987.
[Meyer 1986] Meyer B, "Genericity versus Inheritance", OOPSLA. '86: Sigplan Notices, Vol 21, No 11, pp391-405, 1986
[Meyer 1988] Meyer B, Object-Oriented Software Construction, Prentice-Hall, 1988
[Meyer 1990] Meyer B, Eiffel: The Language and the Environment, Prentice-Hall, 1990
[Miller 1956] Miller GA, "The Magical Number Seven, Plus or Minus Two", Psychological Review, Vol 63, pp81-97, 1956
[Moon 1986] Moon DA, "Object-Oriented Programming with Flavors", OOPSLA. '86: Sigplan Notices, Vol 21, No 11, ppl-8, 1986
[Moon 1989] Moon D, "The Common Lisp Object-Oriented Programming Language Standard", Object-Oriented Concepts, Databases and Applications, ed. Kim W and Lochovsky PH, pp49-78, ACM Press, Addison-Wesley, 1989
[Moss 1987] Moss lEB and Kohler WH, "Concurrency Features for the Trellis/Owl Language", ECOOp, pp223-232, Paris, France, 1987
[Nierstrasz 1987] Nierstrasz OM, "Active Objects in Hybrid", OOPSLA: Sigplan Notices, Vol 22, No 12, pp243-253, 1987
[Nierstrasz 1989] Nierstrasz OM, "A Survey of Object-Oriented Concepts", Object-Oriented Concepts, Databases and Applications, pp3-21, ed. Kim W and Lochovsky PH, ACM Press, 1989
[Nygaard 1981] Nygaard K and Dahl OJ, "Simula 67", History of Programming Languages, ed. Wex elblatt RW, 1986
[OMG 1992] Common Object Request Broker Architecture and Specification (COREA), Object Man agement Group (OMG), Framingham, MA, 1992
[OMG 1993] Object Management Architecture Guide, ed, Soley RM, Revision 2.0, Second Edition, 1 September 1992, Object Management Group
[Oxford 1986] Dictionary of Computing, Oxford University Press, 1986
May 1994 C Kyriakides Page '187 References Objed-Oriented Parallel Paradigms
[Purdy 1987] Purdy A. Schuchardt B and Maier D, "Integrating an Object-Server with Other Worlds", ACM Transactions on Office Injormation Systems, Vol 5, No 1, pp27-47, 1987.
[Quinn 1987] Quinn MJ, Designing efficient algorithms for Parallel Computers, McGraw-Hill, 1987.
[Sakkinen 1988] Sakkinen M, "Comments on the 'Law of Demeter' and C+ +", Sigplan Notices Vol 23, No 12, pp38-44, December 1988
[Schaffert 1986] Schaffert C, Cooper T, Bullis B, Killian M and Wilpolt C, "An Introduction to Trellis/Owl", OOPSLA '86: Sigplan Notices, Vol 21, No 11, pp9-16, November 1986
[Schildt 1989] Schildt H, ANSI C Made Easy, OsbornefMcGraw-Hill, 1989
[Servio 1989] Programming in OPAL, Servio Logic Development Corporation, 1989
[Shapiro 1983] Shapiro EY and Takeuchi A, "Object-Oriented Programming in Concurrent PRO LOG", New Generation Computing, Vol 1, No 1, pp25-48, 1983
[Shibayama 1987] Shibayama E and Yonezawa A, "Distributed Computing in ABCL/l", Object Oriented Concurrent Programming, ed. Yonezawa A and Tokoro M, MIT Press, 1987
[Shriver 1987] Research Directions in Object-Oriented Programming, ed. Schriver B and Wegner P, MIT Press, 1987
[Skarra 1986] Skarra AH and Zdonik SB, "The Management of Changing Types in an Object Oriented Database", OOPSLA '86: Sigplan Notices, Vol 21, No 11, pp483-495, September 1986
[Snyder 1986a] Snyder A, "CommonObjects: An Overview, Sigplan Notices, Vol 21, No 10, pp19-28, 1986
[Snyder 1986b] Snyder A, "Encapsulation and Inheritance in Object-Oriented Programming Lan guages", OOPSLA '86: Sigplan Notices, Vol 21, No 11, pp38-45, 1986
[Snyder 1987] "Inheritance and the Development of Encapsulated Software Systems", Research Directions in Object-Oriented Programming, ed. Schriver B and Wegner P, MIT Press, 1987
[Steele 1984] Steele GL, Common Lisp: the Language, Digital Press, 1984
[Stefik 1986] Stefik M and Bobrow DG, "Object-Oriented Programming: Themes and Variations", AI Magazine, Vol 6, No 4, pp40-62, 1986
May 1994 C Kyriakides Page 288 References Objed-Oriented ParaDel Paradigms
[Stone 1973] Stone HS, "Problems of Parallel Computation", Complexity of Sequential and Parallel Numerical Algorithms, pp1-16, by Traub JF, Academic Press, 1973
[Stonebraker 1990] Stonebraker MR, Rowe LA, Lindsay, Gray P, Carey, Brodie ML, Bernstein and Beech D, "The Third Generation Database System Manifesto", Proceedings of the 1990 SIGMOD Conference, ACM, 1990
[StroustnJp 1986] Stroustrup B, The C+ + Programming Language, Addison-Wesley, 1986
[StroustnJp 1987] Stroustrup B, "Multiple Inheritance for C++·, Proceedings of the EUUG Spring Conference, Helsinki, May 1987
[Tello 1989] Tello ER, Object-Oriented Programmingfor Artificial Intelligence: A Guide to Tools and System Design, Addison-Wesley, 1989
[Theriault 1983] Theriault D, Issues in the Design and Implementation ofAct2, MIT AI-TR-278, June 1983
[Tomlinson 1989] Tomlinson C and Scbeevel M, 'Concurrent Object-Oriented Programming Lan guages", Object-Oriented Concepts, Databases and Applications, ed, Kim W and Locbovsky PH, pp79-124, ACM Press, Addison-Wesley, 1989
[Tsichritzis 1987] Tsichritzis DC, Fiume E, Gibbs S and Nierstrasz OM, "KNOs: Knowledge Acqui sition, Dissemination and Manipulation Objects', ACM Transactions on Office Information Systems, Vol 5, No 1, pp96-ll2, 1987
[Ullman 1988] Ullman JD, Principles of Database and Knowledge-base Systems, Vol 1, Computer Science Press, 1988
[van den 80S 1989] van den Bos J, 'PROCOL: A Protocol Constrained Concurrent Object-Oriented Programming Language", Sigplan Notices, Vol 24, No 4, pp149-151, April 1989
[Wegner 1986] Wegner P, "Classification in Object-Oriented Systems", Proceedings of the Object Oriented Programming Workshop, ed. Wegner P and Shriver B, Sigplan Notices, Vol 21, No 10 ppl73-182, 1986
[Wegner 1987] Wegner P, "The Object-Oriented Classification Paradigm", Research Directions in Object-Oriented Programming, pp479-560, ed. Schriver B and Wegner P, MIT Press, 1987
[Wegner 1989] Wegner P, "Granularity of Modules in Object-Based Concurrent Systems", Sigplan Notices, Vol 24 No 4, pp46-49, April 1989
May 1994 C Kyriakides Page 289 References Objed-Oriented Parallel Paradigms
[Weide 1981] Weide BW, "Analytical models to explain anomalous behavior of parallel algorithms", Proceedings of the 1981 International Conference on Parallel Processing, ppl183-187, IEEE, 1981
[Wuis-Brock 1988a] Wirfs-Brock A and Wilkerson B, "Variables Limit Reusability", Journal of Object-Oriented Programming, Vol 2, No 1, p34-40, May/June 1989
[Wuis-Brock 1988b] Wirfs-Brock A and Wilkerson B, "An Overview of Modular Smalltalk", Sigplan Notices, Vol 23, No 11, November 1988
[Wirfs-Brock 1989] Wirfs-Brock R and Wilkerson B, "Object-Oriented Design: A Responsibility Driven Approach", OOPSLA, 1989, pp71-76
[Wuis-Brock 1990] Wirfs-Brock R, WIlkerson B and Wiener L, Designing Object-Oriented Software, Prentice Hall 1990
[Wirth 1983] Wirth N, Programming in Modula-2, Springer-Verlag, 1983
[Yokote 1986] Yokote Y and Tokoro M, "The Design and Implementation of Concurrent Smalltalk", OOPSLA: Sigplan Notices, Vol 21, No 11, pp331-340, 1986
[Yokote 1987a] Yokote Y and Tokoro M, "Concurrent Programming in ConcurrentSmalltalk", Object-Oriented Concurrent Programming, ed, Yonezawa A and Tokoro M, pp129-158, MIT Press, 1987
[Yokote 1987b] Yokote Y and Tokoro M, "Experience and Evolution of ConcurrentSmalltalk", OOPSLA: Sigplan Notices, Vol 22, No 12, pp406-415, 1987
[Yonezawa 1986] Yonezawa A, Briot J and Shibayama E, "Object-Oriented Concurrent Programming in ABCL/!", OOPSLA: Sigplan Notices, Vol 21, No 11, 1986
[Yonezawa 1987] Yonezawa A, Shibayama E, Takada T and Honda Y, "Modelling and Programming in an Object-Oriented Concurrent Language ABCL/l", Object-Oriented Concurrent Programming, ed Yonezawa A and Tokoro M, pp55-90, MIT Press, 1987
[Yonezawa 1987] Yonezawa A and Tokoro M, "Object-Oriented Concurrent Programming: An Introduction", Object-Oriented Concurrent Programming, ed. Yonezawa A and Tokoro M, MIT Press, 1987
[Yonezawa 1989] Yonezawa A and Watanabe T, "An Introduction to Object-Based Reflective Con current Computation", Sigplan Notices, Vol 24, No 4, pp50-54, April 1989
May 1994 C Kyriakides Page 290 References Objed-Oriented ParaDel Paradigms
[Yourdon 1989] Yourdon E and Coad P, Object-Oriented Analysis, Prentice Hall, 1989
[Zdonik 1985] Zdonik SB and Wegner P, A Database Approach to Languages, Libraries and Envi ronments, Technical Report CS-85-lO, Department of Computer Science, Brown University, 1985
[Zimmermann 1984] Zimmermann H, Guillemont M, Morisset G and Banino J, "Chorus: A Com munication and Processing Architecture for Distributed Systems", Research Report No 328, INRIA, Rocquencourt, September 1984
Additional Reading Material
[Bain 1989] Bain WL, "Indexed, Global Objects for Parallel Architectures", Sigplan Notices, Vol 24, No 4, pp95-98, April 1989
[Bennet 1987] Bennet JK, "The Design and Implementation of Distributed Smalltalk", OOPSLA '87: Sigplan Notices, Vol 22, pp318-330, 1987
[Caromel 1989] Caromel D, "A General Model for Concurrent and Distributed Object-Oriented Programming", Sigp/an Notices, Vol 24, No 4, ppl02-104, April 1989
[Conery 1984] Conery J and Kibler D, "AND parallelism in logic programming", International Con ference on Parallel Processing, pp13-17, August 1984
[Crowl 1989] Crowl LA, "A Uniform Object Model for Parallel Programming", Sigplan Notices, Vol 24, No 4, pp25-27, April 1989
[Herlihy 1989b] Herlihy M, "Taking Concurrency Seriously", Sigplan Notices, Vol 24 No 4, pp32-33, April 1989
[Heuser 1989] Heuser L, Schill A and Muhlhauser M, "Extension to the Object-Oriented Paradigm for the Development of Distributed Applications", Sigplan Notices, Vol 24, No 4, ppl11-113, April 1989
[HOOT] Hotline on Object-Oriented Technology
[Horspool 1992] Horspool RN, The Berkeley UNIX Environment, Prentice-Hall, 1992.
[Jazayeri 1989] Jazayeri M, "Objects for distributed systems", Sigplan Notices, Vol 24, No 4, pp1l7 119, April 1989
May 1994 C Kyriakides Page 291 References Objed-Oriented Parallel Paradigms
[Jones 1980] Jones AK and Schwartz P, "Experience using multiprocessor systems - a status report", Computing Surveys, Vol 12, No 2, pp121-166, June 1980
[JooP] Journal of Object-Oriented Programming
[Lindstrom 1984] Lindstrom g and Panangaden P, "Stream-based execution of logic programs", Pr0 ceedings of the 1984 International Symposium on Logic Programming, pp168-176, February 1984
[Matsuoka 1988] Matsuoka S and Kawai S, "Using Tuple Space Communication in Distributed Object-Oriented Languages") OOPSLA '88, September 1988
[McMenamim 1984] McMenamim S and Palmer J, Essential Systems Analysis, Yourdon Press / Prentice Hall, 1984
[Perrott 1987] Perrott RH, Parallel Programming, Addison-Wesley, 1987
[Rumbaugh 1987] Rumbaugh J, "Relations as Semantic Constructs in an Object-Oriented Language", ACM OOPSLA '87 Proceedings, October 1987
[Rumbaugh 1988) Rumbaugh J, Relational Database Design Using An Object-Oriented Methodology, Communications of the ACM, April 1988
[Seidewitz 1987) Seidewitz E and Stark M, "Towards a General Object-Oriented Software Develop ment Methodology", Ada Letters, Vol 7, No 4, 1987
[Smalltalk/V 1988) SmalltalkjVManual, Digitalk Inc., Los Angeles) 1988
[StroustrDp 1988) Stroustrup B, "What is Object-Oriented Software", IEEE Software, pp1Q-20, May 1988
[Thomas 1989] Thomas D) "What is an Object?") Byte, March 1989
[Tsichritzis 1989) Tsichritzis DC and Nierstrasz 0, "Directions in Object-Oriented Research", Object-Oriented Concepts, Databases and Applications, ed. Kim W and Lochovsky FR, pp523-536, ACM Press, Addison-Wesley) 1989
[Watanabe 1988) Watanabe T and Yonezawa A, "Reflection in an Object-Oriented Concurrent Lan guage", OOPSLA '88, September 1988
May 1994 C Kyriakides Page 292 Epilogue Objed-Oriented ParaDel Paradigms
Epilogue
In closing, we feel that OOPP far exceeded our initial expectations. Not only did oOPP manage to merge the Object-Oriented and Parallel Processing methodologies into one homogeneous body, but oopp also provided an unrivaled view towards the development of large-scale multi-processor sys tems. Alas, oOPP's major shortcoming seems to be that invaluable commodity called time. The oopp development falls short of being complete by a number of goals. For example, OOPP in its current form does not provide an established efficient object-to-processor mapping algorithm. This goal is one of the numerous goals left up to future research efforts.
The vast research effort entailed behind the development of oOPP was more than justified. In brief, all persons directly involved in the research, (such as Dr Martin Olivier and myself) or indirectly involved (such as the authors of the numerous papers, as well as, my parents for the endless supply of moral support can feel proud in the fact that their efforts were not futile.
Hay 1994 C Kyriakides Page 293
Index Objed'()riented ParaDel Paradigms
Index Abstract Classes, 30, 266 Communication Abstract Data type, 30, 53, 266 of Processes, 21 Abstraction, 267 Composition Hierarchy, 269 Encapsulation, 41 Concurrent Object-Onented Paradigms, 223 Abstraction Boundary, 71 definition of, 269 Access Operations, 267 Concurrent Process, 72, '11)9 Accessor Method, '11)7 Concurrent Processing Active Communication, 191, '11)7 definition of, 12, 270 Active Interface Constructor Operations, 270 defmition of, 211, 267 Constructors, 125 Active Object, '11)7 Contract Actors, '11)7 see PROCOl., Contract, 55 delegation, 270 COOP, 223 Agent, 267 definition of, 269 AIR, 181, 182, 186, 199, 229, 230 Data-Driven Design, 52, 270 AKO,'11)7 Data Abstraction, 270 A Kind Of Data Compression Managers, 193 Amdahl's Law Data Semantics, 270 definition of, 13 Amdahl Effect, 18 Data Type, 270 Analysis DBMS, 270 definition of, 267 Declarative Semantics, 270 Analytically Induced Responsibilities Delegation, 270 see AIR, 181 Demon, 270 APO Derived Classes, 125 A Part Of Destructor Operations, 270 Assembly Structure, '11)7 Destructors, 125 Assertions, 267 Direct Inclusion Approach, 198 Asynchronous, 46 Distibuted Resource Management, 185 message passing, 47 Distribution Boundary, 71 Asynclironous Algorithms, 18, '11)7 Dynamic Binding, 270 Attribute, 268 in C+ +, 124 Dynamic Inheritance, 35 Backward Chaining, 268 Behaviour, 268 Early Binding, 270 Behaviour Sharing, 268 Employee Beta, 118 Hierarchy, 227 Bindin 268 Employee Responsibilities, 198 Bindin~ Time, 268 Employees, 3, 4, 5, 180, 181, 183, 184, 187, 190, Bottlenecks, 68 228 Broadcasting, 47 Encapsulation, 24, 25, 41 Browser, 268 Encapsulation, 271 Exclusively-Sequential Objects, 74, 78, 271 C,122 Externally-Concurrent Objects, 74, 78, 271 C++, 123 Externally-Sequential Objects, 74, 78, 271 Category, 268 Class, 29, 268 Fault Tolerance, 212 Class-Based, 268 Flynn's Taxonomy, 14 Classification of Objects, 9 MIMD, IS, 274 MISD, 14, 274 Class-Oriented, 26S SIMD, 14, 279 Class Inheritance, 33 SISD, 14, 279 Class Variable, 30, '11)9 Forward Chaining, 271 Classification, 269 Frame, 271 Classification Structure, '11)9 Friends, 125, 271 Classification Theory, 269 Functional Semantics, 271 Client, 55, 269 Functor, 271 External Client, 55 Future Message Passing, 247 Self Qicnt, 56 Subclass aicnt, 56 Client/Server Model, 55, 2£J9 Garbage Collection, 271 Mark/Sweep Algorithm, 241
May 1994 C Kyrialddes Page 295 Index Objed-Oriented Parallel Paradigms
Tunestamp A1~rithm, 241 Message, 273 Genericity, 271 Message Management, 187 Grain Size, 18, 271 Message names, 29 Granular Objects, 73, 77, 271 Message Passing, 273 Messages, 28 Has-a, 32 Meta-Class, 273 Homogeneous Models, 40 Metaclass, 119 Method, 274 Implementation, 271 Method-Extemally-Concurrent Objects, 73, 78, Inclusion Polymorphism, 40 273 Indirect Message Passing, 189 Method-Extemally-Sequential Objects, 73, 78, Inferential Distance Ordering, 272 274 Information Hi~, 25, 272 Method-Intemally-Concurrent Objects, 73, 78, Information Modelling, 8 274 Inheritance, 25, 32, 272 Method-Intemally-Sequential Objects, 73, 78, Class Inheritance, 33 274 Dynamic Inheritance, 35 Multiple Inheritance, 34 Method Inheritance, 136 Part Inheritance, 35 Methods,28 Partial Inheritance, 35 MIMD, 15, 274 Scope Inheritance, 35 MISD, 14, 274 Single Inheritance, 33 Static Inheritance, 33 MITRE model, 238 Initialisation Inheritance, 136 Agents, 239 garbage collection, 240 Instance, 29, 272 Object Number Management, 240 Instance Variable, 30, 119, 272 Object Numbers, 240 Instantiation, 272 Resource Management, 239 Inter-processor communication, 64 Mixin, 274 Interface Monomorphic, 37 definition of, 211, 273 Monomorphism, 274 Internally-Concurrent Objects, 74, 78, 273 Monotonic Logic, 37 Internally-Sequential Objects, 74, 78, 273 Multi-processor IsA, 273 definition of, 274 Is A Multi-Tier Approach, 232, 260 Iterator, 273 Multi-Tiers, 230 Multicomputer, 16, 65, 274 Knowledge Representation, 37 Multiple Inheritance, 34, 274 Multiple Objects, 73, n, 275 Late Binding, 273 Multiprocessor, 15, 64, 275 Law of Demeter, 59 Mutually-Concurrent Objects, 74, 78, 275 Layer, 273 Mutually-Sequential Objects, 74, 78, 275 Linearisability, 20 Loosely Coupled Architecture NAIR, 181, 182, 183, 199,229,230 definition of, 16 Non-Granular Objects, 73, 78, 275 Non-monotonic Logic, 37 Manager nonAnalyticalJy Induced Responsibilities Hierarchy, 227 see NAIR, 181 Manager-Employee Relationship, 2, 3, 5, 180, 186, 215, 233, 235, 251, 260 Object, 276 Manager-Employee Concept, 259 Object-Based, 275 Manager-Employee model, 215, 217 Classification of O~ects, 9 hierarchical structure, 217 Object-identity, 275 managerial responsibilities, 218 Object-Oriented, 275 Networking, 195 Special Managers, 190 Classification of Objects, 9, 26 topmost manager, 218 Object-Oriented Analysis Manager-Employee Relationship definition of, 275 Implicit,S Object-Oriented Programming Languages, 8 Managerial Responsibilities, 182, 198 ObJect-to-Processor Density, 74, 276 Managers, 3, 4, 5, 180, 182, 186, 187, 190, 227 ObJect-to-Processor Mapping, 211 Direct-Inclusion, 4 Object Taxonomy, 72 Hierarchy, 227 Inheritance characteristics, 76 Two-TIer,5,181 Object Type, 276 Member Functions, 125 Objective-C, 122 Members, 32
May 1994 C Kyriakides Page 296 Index- Objed-Oriented ParaDel Paradigms
Objects, 26 Quasi-Concurrent Process, 72, 278 Attributes, 26 Behaviour, 28 Real-time Processing, 213 Methods,26 Operations, 27 Relaxation, 18 Private part, 27 Relaxed Algorithms, 278 Public part, 27 Remote Procedure Call OOA, fiC' Blocking, 49 OOPP,201 Future, 48 acronym definition, 8 NonBlocking, 48 OOPP-scenario, 223 Resource Allocation Management, 211 definition of, 223, 276 Resource Management, 184 OOPP-scenario Managers, 230 Resource Set, 216 OOPS Resource Usage Data, 216 acronym definition, 8 Responsibility-Driven Design, 52, 278 Operation, 276 RPC Operator Overloading, 39,276 see Remote Procedure Call in C++, 125 RUD Override, 276 acronym for Resource Usage Data, 216 Rules, 278 Package, 276 Parallel Processing Scope Inheritance, 35 definition of, 12, 276 Selector Operations, 278 Parallelism Self-Recursion, 278 definition of, 12 Self-Reference, 278 Part-Of Hierarchy, 269 Self-Scheduling, 18, 278 Part Inheritance, 35 Sequential Process, 72, 278 Partial Inheritance, 35 Serialisability, 20 Partitioned Algorithms, 17, 277 Server, 55, 278 Partitioning, 17 Service, 279 Passive Communication, 191, 277 Service Providers, 235 Passive Interface Set Abstraction, 279 definition of, 211, 2TI Pattern, 118 Shared Memory, 15 Persistence, 277 Shared Variable, 119 Pipelined Algorithms, 17, 277 Signatures, 29 Systolic Algorithms, 17 SIMD, 14, 279 Pipelining Simula, 117 definition of, 12 Single Inheritance, 33 Polymorphic SISD, 14, 279 definition of, 2TI Slot Inheritance, 136 Polymorphic Functions, 38 Slots, 279 Polymorphic Messages, 39, 277 1 Smalltalk, 119 I Polymorphic Methods, 38 Smalltalk-80, 120 1 Polymorphic Operators, 39 Smalltalk/V, 120 Polymorphic Variables, 38 Snyder A. 1 Polymorphism, 37, 277 Evaluation of Inheritance Mechanisms, 37 I Prescheduled Algorithms, 277 Software Lockout, 19, 279 1 Prescheduling, 17 Special Communication Managers, 191 Private, 277 Special Interface Managers, 193 Private Parts, 124 Special Managers, 190 I Private Variable, 119 Speedup, 13, 279 I Problem Space, 66 Static Binding, 279 Procedural Abstraction, 278 in C+ +, 124 Processor-Memory pair, 16 Static Inheritance, 33 Processor Array Architecture, 15 Strong Typing, 279 Structure, 279 I1 PROCOL, 125 Actions, 126 SubClass, 280 I Contract, SS Subject, 280 Protocol, 278 SuperClass, 280 Public, 278 Synchronisation I Public Parts, 124 of Processes, 21 " Synchronisation Boundary, 71 Synchronised Algorithms, 17,280
May 1994 C Kyriakides Page 297 Index Objed-Oriented ParaDel Paradigms
Synchronous, 46 message passing, 47 Systolic Algonthms, 17
Taxonomy of Objects, 72 Throughput, 12, 280 Tiers Paved,234 Stacked, 233 Tightly Coupled Architecture defmition of, 15 Time Warp, 247 Transactions, 21 Trigger, 280 Two-Tier Approach, 5, 180, 197, 227 Type, 280 Type Inheritance, 136
Unique Objects, 73, 77, 280 Use Structure, 280
Virtual Functions in c+ +, 124 Virtual Storage description of, 208, 280 Virus Antivirus-Manager, 191 Visibility, 280
Weak Typing, 280 Wegner's Oassification of Objects, 9 Granularity of Modules, 71
May 1994 C Kyriakides Page 298