Chapter 19: The Object Modeling Technique
This chapter, and the next, discuss the influential design method referred to as the Object Modeling Technique (OMT). It summarizes the main phases of OMT using the UML not ation. One extension to OMT is the introduction of use case models from Objectory to improve the requirements analysis process. This is motivated by the inclusion of use case diagrams in the UML.
Chapter 20: More Object Modeling Technique
This chapter continues the description of the Object Modeling Technique (OMT).
Chapter 21: Frameworks and Patterns for Object Oriented Design
The aim of this chapter is to introduce the concept of frameworks and in particular patterns. This is still a relatively new idea within Object Orientation, but one which is growing in popularity at an incredible rate.
Part 4: Testing and Style
Chapter 22: Testing Object Oriented Systems
Object oriented systems may make code easier to reuse and may be supported by object oriented analysis and design methods, but they do not guarantee that the code is correct. This chapter looks at some of the issues behind testing object oriented systems.
Chapter 23: Method and Class Testing
The last chapter discussed the problems facing the test er of an object oriented system (and in particular a Smalltalk system). This chapter considers current best practice in testing object oriented systems.
Chapter 24: Smalltalk Style Guidelines
The aim of this chapter is the promotion of readable, understan dable, concise and efficient Smalltalk code. A point to note is that style guidelines for languages such as Pascal do not cover many of the issues which are important in Smalltalk. As in any programming language there are a number of acknowledged bad pract ices which are not specific to Smalltalk, for example the use of global variables! Such guidelines are familiar to programmers of most languages. This section will therefore try to concentrate on those style issues which are specific to Smalltalk.
Part 5: Graphical Interfaces in Smalltalk
Chapter 25: The Perform and Dependency Mechanisms
In this chapter the use of perform to provide an alternative method for sending messages is considered.
This is followed by a practical discussion of the dependency mecha nism. This includes what the dependency mechanism is, why you might want to use, how you construct a dependency and the effect that it has.
Chapter 26: The Model-View-Controller Architecture
The Model-View-Controller (or MVC) architecture is the basis upon which user interfaces are constructed in Smalltalk. The architecture separates out the application from the user interface. This chapter introduces the MVC architecture and explains the motivation behind it. A worked example is presented to illustrate the theoretical description.
Chapter 27: Graphic User Interface Construction Tools
The user interface construction facilities in Smalltalk are subject to the widest variation between dialects of any aspect of the language. This chapter concentrates on the f acilities provided by the user interface building facilities in VisualWorks.
Chapter 28: A Visual Organizer
This chapter describes a detailed worked example of how a user interface can be constructed for the Organizer application constructed earlier in the book.
Chapter 29: Using a View Within a Window
This chapter explains how to use MVC applications within a VisualWorks window. It is useful to be able to do this as not all user interfaces can be accommodated directly by the user interface builder in VisualWorks.
Part 6: Further Smalltalk
Chapter 30: Memory Management and Garbage Collection
This chapter considers why automatic memory management is desirable. It also discusses how
Smalltalk’s memory is structured and the garbage collection strategies used. It concludes by considering how to force VisualWorks to place long term objects in the most appropriate region of memory.
Chapter 31: Concurrency in Smalltalk
This chapter presents and explains a short example of how time slicing can be accomplished wi thin Smalltalk.
Chapter 32: The Metaclass Framework
The aim of this chapter is to discuss the concept of classes, what they actually are, what they are really used for and why they are important. To do this it introduces the concept of a metaclass and con siders how they are used to provide inheritance and the creation of instances. It also discusses whether it is important for the Smalltalk programmer to be aware of the existence of the metaclass.
Part 7: The Future
Chapter 33:The Future for Object Technology
This chapter brings the many threads in this book together and considers the future of object oriented systems.
Appendix
Appendix A: The Smalltalk Language Syntax
Obtaining Source Code Examples
The source code for the examples in this book is a vailable on the web at URL:
http://www.jaydeetechnology.co.uk/books.htm/
Typographical Conventions
In this book the standard typeface is Times, however courier is used to identify source code. For example, a := 2 + 3.
Trademarks
ParcPlace, VisualWorks, Smalltalk -80, Smalltalk/V are registered trademarks, and BOSS is a trademark, of ParcPlace -Digitalk Systems, Inc. Sun and Java are trademarks of Sun Microsystems, Inc.
MS-Windows and Windows 95 are registered trademarks of Microsoft Corporation. Apple is a registered trademark of Apple Computer, Inc. UNIX is a registered trademark of AT&T. The X
Window System is a trademark of the Massachusetts Institute of Technology. All other brand names are trademarks of their respective holders.
Acknowledgments
The content of this book has been refined by a large number of students in both academia and industry.
Many of these people have provided useful feed back and constructive comments. A number of them have actively suggested topic areas which might be covered or which were poorly described; thank you all for your interest. In particular thanks to Peter Holland, Paul Jones, Dave James, John Counsell, Clive King, Andy Whittle and others who I am sure I have forgotten to mention. I would also like to thank Rebecca M oore, of Springer -Verlag, for her patience and thoroughness during the preparation of this book. Finally, thanks to my wife, Denise Cooke, for suffering my disappearances to the study most evenings to work on “the book” and for helping with my many “printing” problems.
Preface
1. INTRODUCTION TO OBJECT ORIENTATION...15
1.1 INTRODUCTION...15
1.2 PROGRAMMING PARADIGMS...15
1.3 REVOLUTION VERSUS EVOLUTION...16
1.4 HISTORY /PEDIGREE OF OBJECT ORIENTED LANGUAGES...17
1.5 FUNDAMENTALS OF OBJECT ORIENTATION...18
1.6 THE FOUR CATECHISM OF OBJECT ORIENTATION...18
1.7 ENCAPSULATION...19
2. ELEMENTS OF OBJECT ORIENTATION ...25
2.1 INTRODUCTION...25
2.2 TERMINOLOGY...25
2.3 TYPES OF HIERARCHIES IN OBJECT ORIENTATION...26
2.4 WHY BOTHER?...28
2.5 THE MOVE TO OBJECT TECHNOLOGY...32
2.6 SUMMARY...32
2.7 EXERCISES...33
2.8 FURTHER READING...33
3. CONSTRUCTING AN OBJECT ORIENTED SYSTEM ...34
3.1 INTRODUCTION...34
3.2 THE APPLICATION: WINDSCREEN WIPE SIMULATION...34
3.3 WHERE DO WE START?...35
3.4 IDENTIFYING THE OBJECTS...35
3.5 IDENTIFYING THE SERVICES/METHODS...36
3.6 REFINING THE OBJECTS...37
3.7 BRINGING IT ALL TOGETHER...37
3.8 SUMMARY...41
3.9 EXERCISES...41
3.10 FURTHER READING...41
4. AN INTRODUCTION TO SMALLTALK ...44
4.1 INTRODUCTION...44
6.1 INTRODUCTION...61
6.2 THE BASICS OF THE LANGUAGE...61
6.3 CLASSES...62
6.4 METHOD DEFINITIONS...66
7. SMALLTALK CONSTRUCTS ...69
7.1 INTRODUCTION...69
7.2 NUMBERS AND OPERATORS...69
7.3 CHARACTERS AND STRINGS...70
7.4 ASSIGNMENTS...71
7.5 VARIABLES...71
7.6 MESSAGES AND MESSAGE SELECTORS...73
7.7 SUMMARY...75
7.8 FURTHER READING...75
8. AN EXAMPLE SMALLTALK CLASS...76
8.1 INTRODUCTION...76
8.2 THE CLASS PERSON...76
8.3 DEFINING METHODS...77
8.4 CREATING AN INSTANCE...80
9. CONTROL AND ITERATION ...81
9.1 INTRODUCTION...81
9.2 CASCADING...81
9.3 BLOCKS...81
9.4 CONTROL STRUCTURES...83
9.5 SUMMARY...86
11.6 MULTI DIMENSIONAL ARRAYS...97
11.7 DICTIONARIES...98
11.8 STRINGS...99
11.9 ITERATING OVER COLLECTIONS...100
11.10 INSERTING INTO A COLLECTION...101
11.11 CONVERSION...102
12. AN OBJECT ORIENTED ORGANIZER ...104
12.1 INTRODUCTION...104
12.2 THE ORGANIZER...104
12.3 THE CLASS DEFINITION...104
12.4 THE INITIALIZE-RELEASE PROTOCOL...105
12.5 A CLASS SIDE METHOD...106
12.6 THE PRIVATE-UPDATING PROTOCOL...107
12.7 THE ACCESSING PROTOCOL...107
12.8 THE FINANCIAL MANAGER PROJECT...109
14. THE MAGNITUDE CLASS HIERARCHY...118
14.1 INTRODUCTION...118
15.2 ERRORS AND BREAKPOINTS...122
15.3 FILE IN/FILE OUTS...123
15.4 CHANGE LIST...125
15.5 WORKING WITH PROJECTS...126
15.6 SUMMARY...128
16. OBJECT ORIENTED ANALYSIS AND DESIGN...131
16.1 INTRODUCTION...131
16.2 THE UNIFIED MODELING LANGUAGE...131
16.3 OBJECT ORIENTED DESIGN METHODS...131
16.4 OBJECT ORIENTED ANALYSIS...132
17. THE UNIFIED MODELING LANGUAGE ...137
17.1 INTRODUCTION...137
17.2 THE UML INFRASTRUCTURE...138
17.3 USE CASE DIAGRAMS...139
17.4 THE OBJECT MODEL...139
17.5 PACKAGES...145
18. UML: DYNAMIC MODELING AND DEPLOYMENT...147
18.1 INTRODUCTION...147
18.2 DYNAMIC MODELING FACILITIES...147
18.3 DEPLOYMENT DIAGRAMS...152
18.4 SUMMARY...153
19. THE OBJECT MODELING TECHNIQUE...154
19.1 INTRODUCTION...154
19.2 THE OMT METHODOLOGY...154
19.3 ANALYSIS PHASE...154
20.1 INTRODUCTION...162
20.2 DYNAMIC MODELS...162
20.3 DESIGN PHASE...166
20.4 IMPLEMENTATION PHASE...169
20.5 SUMMARY...170
21. FRAMEWORKS AND PATTERNS FOR OBJECT ORIENTED DESIGN...171
21.1 INTRODUCTION...171
21.2 PATTERNS AND FRAMEWORKS...171
21.3 AN INTRODUCTION TO HOTDRAW...174
21.4 WHERE DO YOU START?...176
21.5 BOXDRAWFIGURE...177
21.6 SUMMARY...180
22. TESTING OBJECT ORIENTED SYSTEMS ...182
22.1 INTRODUCTION...182
22.2 WHY IS TESTING OBJECT ORIENTED SYSTEMS HARD? ...182
22.3 INHERITANCE...184
22.4 ABSTRACT SUPERCLASSES...185
22.5 ENCAPSULATION...185
22.6 POLYMORPHISM...187
22.7 ADDITIONAL SMALLTALK SPECIFIC FEATURES...188
22.8 SUMMARY...189
22.9 FURTHER READING...189
23. METHOD AND CLASS TESTING ...190
23.1 INTRODUCTION...190
23.2 OBJECT INTEGRATION TESTING...192
23.3 SYSTEM TESTING...192
23.4 SELF TESTING...193
23.5 SUMMARY...193
23.6 FURTHER READING...193
24. SMALLTALK STYLE GUIDELINES ...195
24.1 INTRODUCTION...195
24.2 VARIABLES...195
24.3 CLASSES...197
24.4 METHODS...200
24.5 NAMING MESSAGE PROTOCOLS...202
24.6 FURTHER READING...203
25. THE PERFORM AND DEPENDENCY MECHANISMS ...205
25.1 INTRODUCTION...205
25.2 THE PERFORM MECHANISM...205
25.3 THE DEPENDENCY MECHANISM...206
25.4 SUMMARY...212
26. THE MODEL-VIEW-CONTROLLER ARCHITECTURE ...213
26.1 INTRODUCTION...213
26.2 THE MVC ARCHITECTURE PRINCIPLES...213
26.3 THE MVC WITH THE STATEMENT MODEL...218
26.4 VIEWS AND SUBVIEWS...220
26.5 THE CONTROLLER HIERARCHY...221
26.6 SUMMARY...222
26.7 FURTHER READING...222
27. GRAPHICAL USER INTERFACE CONSTRUCTION TOOLS...223
27.1 INTRODUCTION...223
27.2 WHAT IS A USER INTERFACE BUILDER? ...223
27.3 VISUALWORKS WINDOW PAINTING TOOLS...224
27.4 WINDOW SPECIFICATION AND CREATION...226
27.5 APPLICATION MODELS VERSUS DOMAIN MODELS...227
27.6 DEFINING A WINDOW’S FUNCTIONALITY...228
27.7 INITIALIZATION...229
28. A VISUAL ORGANIZER ...236
28.1 INTRODUCTION...236
28.2 VISUALORGANIZER CLASS...236
28.3 THE ADDRESSBOOK CLASS...239
28.4 SUMMARY...243
28.5 THE VISUAL FINANCIAL MANAGER APPLICATION...243
29. USING A VIEW WITHIN A WINDOW ...244
29.1 INTRODUCTION...244
29.2 THE CUSTOM VIEW WIDGET...245
29.3 THE STRUCTURE OF THE APPLICATION...246
29.4 THE INTERACTIONS BETWEEN OBJECTS...247
29.5 THE CLASSES INVOLVED...250
29.6 ADD A DELETE WIDGET OPTION...255
29.7 SUMMARY...255
29.8 FURTHER READING...255
30. MEMORY MANAGEMENT AND GARBAGE COLLECTION ...257
30.1 INTRODUCTION...257
30.2 WHY HAVE AUTOMATIC MEMORY MANAGEMENT? ...257
30.3 VISUALWORKS MEMORY MANAGEMENT...258
30.4 GARBAGE COLLECTION AND MEMORY COMPACTION...259
30.5 PLACING OBJECTS IN PERMSPACE...259
31. CONCURRENCY IN SMALLTALK ...261
31.1 INTRODUCTION...261
31.2 CONCURRENT PROCESSES...261
31.3 PROCESSES IN SMALLTALK...262
31.4 A CONCURRENT SMALLTALK EXAMPLE...264
31.5 FURTHER READING...267
32. THE METACLASS FRAMEWORK...268
32.1 INTRODUCTION...268
32.2 WHAT ARE CLASSES? ...268
32.3 CLASSES AND METACLASSES...269
32.4 CLASSDESCRIPTION AND BEHAVIOR...271
32.5 THE METACLASS CONCEPT GOES RECURSIVE! ...272
32.6 FURTHER READING...275
33. THE FUTURE FOR OBJECT TECHNOLOGY...278
33.1 INTRODUCTION...278
33.2 THE SMALLTALK LANGUAGE...278
33.3 OBJECT ORIENTED DEVELOPMENT TOOLKITS...280
33.4 THE INTERNET AND OBJECTS...281
33.5 OBJECT ORIENTED DATABASES...281
34. APPENDIX: THE SMALLTALK LANGUAGE SYNTAX ...284
34.1 BASIC SYNTAX...284
34.2 LITERALS AND VARIABLES...285
34.3 CLASSES AND METHODS...287
34.4 BLOCKS...288
34.5 CLASS BOOLEAN...289
34.6 COLLECTIONS...289
Introduction to Object Orientation
Part One
1. Introduction to Object Orientation
1.1 Introduction
This book is intended as an introduction to object orientation for computer science students or those actively involved in the software industry. It assumes familiarity with standard computing concepts such as stacks, memory allocation etc. and with a procedural language such as C. It uses this background to provide a practical introduction to object technology. To do this it uses Smalltalk, one of the earliest pure object oriented languages.
The approach taken in this book is to try to introduce a variety of concepts through practical experience with an object oriented language. It also tries to take the reader beyond the level of the language syntax to the philosophy and practice of object oriented development.
In the remainder of this chapter we will consider the various programming paradigms which have preceded object orientation. We will then examine what the primary concepts in object orientation are and consider how to enable object orientation to be achieved.
1.2 Programming paradigms
Software construction is still more of an art than a science. Despite the best efforts of many software engineers, software systems are still delivered late, over budget and not up to the requirements of th e user. This situation has been with us for many years (indeed the first conference to raise awareness of this problem was the NATO Software Engineering Conference of 1968 which coined the term software crisis). Since then there hav e been a variety of programming paradigms which have either been developed explicitly to deal with this issue or which have been applied to it.
A programming paradigm is a particular programming style which embodies a particular
philosophy. These philosoph ies usually represent some sort of insight which sets a new type of best practice. For a programming language to support a particular programming paradigm it must not just allow adoption of that paradigm (you can use object oriented programming techniques in assembler - but would you want to?) it must actively support implementations based on that paradigm. This usually means that the language must support constructs which make development using that paradigm straight-forward.
The major programming paradigms which have appeared in computer science include:
Functional Lisp is the classic example of a functional language (although by no means the only one for example, ML is a very widely used functional language). These languages place far more emphasis on ap plying a function (often recursively) to a set of one or more data items. The function would then return a value - the result of evaluating the function. If the function changed any data items then this was a side effect of the function. There is (was) lim ited support for more algorithmic solutions which might rely on repetition via iteration. The functional approach turned out to be extremely useful as a way of implementing complex systems for early AI researchers.
Procedural as exemplified by languages su ch as Pascal and C. These were an attempt to move programming languages to a higher level (than the earlier assembler languages). The emphasis was now on algorithmic solutions and on procedures which operated on data items. They were extremely effective, but software developers still encountered difficulties. This was partly due to the increased complexity of the systems typically being developed. It was also because, although high level procedural languages removed the possibility of certain types of error occurring and increased productivity, developers could still cause problems for themselves. For example, the
interfaces between different parts of the system might be incompatible, but this might not become obvious until integration testing or system testing.
Modular Languages such as Modula -2 and Ada employ modularization. In these languages a module hides its data from module users. The users of the module can only access that data via defined interfaces. These interfaces are “published” so that users know what interfaces are available (and their definitions) and can check that they are using the correct versions.
Object oriented This is the most recent “commercial” programming paradigm. This approach can be seen as taking modularization a step further. Not only do you have explicit modules (in this case objects) but these objects can inherit features from one another. We can of course ask “why another programming paradigm?”. The answer to this partly lies in the fa ilure of many software development projects to keep to budget, remain within time scales and to give the user what they want. Of course, it should never be assumed that object orientation is the answer to all these problems, it is really just another tool available to software developers.
This book is about this last programming paradigm. It attempts to introduce this paradigm through the medium of an object oriented programming language. It assumes that the majority of readers will have a background in at least one procedural language (in particular with a C -like language). It therefore compares and contrasts the facilities provided with such a language at appropriate times.
It should be seen from the above list, that object orientation, even though it is quite different in many ways from the procedural approach, has developed from it. You should therefore not throw away all that you have learnt using other approaches. Many of the good practices in other languages are still good practices in an object orie nted language. However, there will be new practices to learn as well as new syntax. It will be much more than a process of learning a new syntax - you have a new philosophy to learn.
1.3 Revolution versus evolution
In almost every area of scientific endeavor t here are periods of evolution followed by periods of revolution and then evolution again. That is, some idea or theory is held to be “accepted” (not necessarily true but at least accepted). During this period the theory is refined by successive
experiments / discoveries etc. Then at some point, the theory is challenged by a new theory. This new theory is typically held by a small set of extremely fervent believers. It is often derided by those who are staunch supporters of the existing theory. As time conti nues, either this new theory is proved wrong and disappears, or more and more are drawn to the new theory until the old theory has very few supports.
There are many examples of this phenomena in science. For example, the Copernican theory of the earth rotating around the sun, Einstein’s theory of relativity and Darwin’s theory of evolution. Men such as Darwin and those who led him to his discoveries were revolutionaries. They went against the current belief of the times and introduced a new set of theories . These theories were initially derided but have since become generally accepted. Indeed we are now in an evolutionary phase, with regard to the theory of evolution, where Darwin’s theories are being refined. For example, Darwin believed that the
mechanism of fertilization of an egg was derived from an old Greek theory referred to as Pangenesis.
Every organ and tissue was assumed to produce granules, called gemmules. These were combined to make up the sex cells. Of course we now believe this to be wrong and it was Darwin’s own cousin, Francis Galton, who helped to disprove the Pangenesis theory. Whether we will enter a new
revolutionary phase where the theory of evolution will be over -turned is probably unlikely, however, Einstein’s theory of relatively may well be (and is already being) challenged.
Programming is another example of this revolution / evolution cycle. The move from low level to high level programming was one such revolution (and you can still find people who will insist that low level machine code programming is best). Object orientation is another revolution, which in this case is still happening. Over the past ten years object orientation has become much more widely accepted and you will find many organizations, both suppliers and users of so ftware, giving it lip service. However, you will also find many in the computer industry who are far from convinced. A senior colleague of mine recently told me that he believed that object orientation was severely over -hyped (which it may be) and that he really couldn’t see the benefits it offered. Hopefully, this book will convince him (and others) that object orientation has a great deal to offer.
It is likely that something will come along to challenge object oriented programming, just as it has challenged procedural programming, as the current software development approach to use. It is also likely that a difficult and painful battle will ensue with software suppliers entering the market and leaving the market. Many existing suppliers will argue that th eir system always supported approach X anyway while others will attempt to graft the concepts of approach X onto theirs. When this will happen or what the new approach will be is difficult to predict, but it will happen. Until then, object orientation will be a significant force within the computer industry.
1.4 History /pedigree of object oriented languages
In the horse or dog breeding world, the pedigree of an animal can be determined by considering its ancestry. Whilst you can’t deter mine how good a language is by looking at its predecessors, you can certainly get a feel for the influences which have led to features it possesses. The current set of
commercial object oriented languages have all been influenced to a greater or lesser ext ent by existing
commercial object oriented languages have all been influenced to a greater or lesser ext ent by existing