mikpa@massormetrix.ida.liu.se (Mikael Patel) (08/01/89)
Dear Object-Oriented Programmers out there in Net-Land. I need your help! I am working on a course on Object Oriented Programming (OOP) for third and fourth year students on our civil engineer lines. I'd like some advice and help on some problems: 1. Are there any classical examples (such as the Dining Philosofers, and the Readers-Writers Problem from Concurrent Programming) that well illustrate the problems and ideas behind OOP? 2. What are the landmark publications within this area? 3. Teaching OOP seems easy when it comes to concept as there exists a number of well established metaphors. The real problem seems to be methodology. Does anyone have any pointer to object oriented programming methodologies? 4. When teaching functional programming languages such as Lisp the interpreter (eval, apply) is often used to better understand the execution model and how it may be altered. Is it essential to explain the virtual machine of an object oriented language in the same manor? And if so what depth? The Smalltalk execution model is quite complex in detail. Mikael R.K. Patel Researcher and Lecturer Computer Aided Design Laboratory Department of Computer and Information Science Linkoeping University, S-581 83 LINKOEPING, SWEDEN Phone: +46 13281821 Telex: 8155076 LIUIDA S Telefax: +46 13142231 Internet: mip@ida.liu.se UUCP: ...!sunic!liuida!mip Bitnet: MIP@SELIUIDA SUNET: LIUIDA::MIP
eberard@ajpo.sei.cmu.edu (Edward Berard) (08/02/89)
In article <1318@massormetrix.ida.liu.se>, mikpa@massormetrix.ida.liu.se (Mikael Patel) writes: > Dear Object-Oriented Programmers out there in Net-Land. I need your help! > > I am working on a course on Object Oriented Programming (OOP) for third and > fourth year students on our civil engineer lines. I'd like some advice > and help on some problems: > > 1. Are there any classical examples (such as the Dining Philosofers, and > the Readers-Writers Problem from Concurrent Programming) that well > illustrate the problems and ideas behind OOP? > There seem to be three classes of example problems: - Classroom Exercises/Book Examples: These are usually small, and are often programming language specific. Examples include the five design problems in Booch's book: "Software Engineering With Ada, 2nd Edition," Benjamin-Cummings, Menlo Park, California, 1987, the "Cruise Control" and "Host at Sea Buoys" problems in Booch's February 1986 IEEE article (see answer to next question), and the case studies in chapter 12 of Bertrand Meyer's book on "Object-Oriented Software Construction" (see answer to next question). - Real-Time Object-Oriented Development Examples: See, for example the work done at the Software Engineering Institute in Pittsburgh, Pennsylvania by Mike Rissman's group "An OOD Paradigm for Flight Simulators," Technical Report CMU/SEI-87-TR-43 (ESD-TR-87-206). [Phone number for the SEI is (412) 268-7700.] There is also the ever popular "elevator scheduler and controller" example which is often used to compare methodologies. You may find complete examples of this in past professional seminars conducted by the ACM. Remember that there is a significan difference between real-time and non-real-time object-oriented problems. For example, "objects with life" (objects which are capable of spontaneously changing their own state) are much more prevalent in real-time systems, as are concurrency and synchronization issues. - Information Systems (IS)/Non-Real-Time Examples: Although IS systems are concpetually easier to create than are their real-time counterparts, relatively few public domain examples exist. You might check out some of the OODBMS references in the answer to the next question. One of the major failings of university software engineering education is its lack of methodology training. While there is plenty of object-oriented programming (read "object-oriented coding"), there is very little attention paid to non-coding parts of the life-cycle. If you find any object-oriented examples of any size, you will find that they often address such issues as "object-oriented domain analysis," "object-oriented requirements analysis," and "object-oriented design." Unfortunately you will find precious few references to "object-oriented development in the large" (OODIL) -- but there are a few. > 2. What are the landmark publications within this area? Readings In Object-Oriented Technology by Edward V. Berard Berard Software Engineering, Inc. If you are interested in reading about any rapidly evolving technology, it is best to keep the following in mind: % Read more than one source. Look for sources which have different, and possibly conflicting, views of the material. It is often difficult to determine fundamental facts when only one viewpoint is present. % Very often, authors confuse concepts with implementations. Ask yourself if the author is discussing a concept, or a particular implementation of the concept. % Always be on the lookout for new sources. In the software technology arena in particular, significant changes can take place in less than a month. % Take care to distinguish between differing viewpoints and conflicting viewpoints. There are many topic areas in object-oriented software technology, and literally thousands of books, articles, tutorials, and proceedings devoted, in whole, or in part, to object-oriented software concepts. What we will present here is some of the representative reading material. Just because an item is included in this reading list does not mean that it is recommended without qualifications, nor does it mean that it is an authoritative source on a topic. However, the material listed here is intended to help you understand more about the technology. Object-Oriented Programming Object-oriented programming books most often tend to focus on programming language aspects of object-oriented technology. However, many fundamental concepts can be found in the books mentioned below: [Cox, 1986]. B.J. Cox, Object Oriented Programming: An Evolutionary Approach, Addison-Wesley, Reading, Massachusetts, 1986. [Goldberg and Robson, 1983]. A. Goldberg and D. Robson, Smalltalk-80: The Language and Its Implementation, Addison-Wesley, Reading, Massachusetts, 1983. [Meyer, 1988]. B. Meyer, Object-Oriented Software Construction, Prentice-Hall, Englewood Cliffs, New Jersey, 1988. [Keene, 1989]. S.E.Keene, Object-Oriented Programming in Common Lisp, Addison-Wesley, Reading, Massachusetts, 1989. [Stroustrup, 1986a]. B. Stroustrup, The C++ Programming Language, Addison-Wesley, Reading, Massachusetts, 1986. Object-Oriented Requirements Analysis There are a number of publicly available courses on object-oriented requirements analysis. Since the technology is still new, these courses present many differing viewpoints and approaches. There is, however, one book on the topic: [Shlaer and Mellor, 1988]. S. Shlaer and S.J. Mellor, Object-Oriented Systems Analysis: Modeling the World In Data, Yourdon Press: Prentice-Hall, Englewood Cliffs, New Jersey, 1988. Object-Oriented Design/Development Most of the work which has been done in the area of object-oriented life-cycle issues, outside of object-oriented programming, has been accomplished within the Ada community. Some representative sources on OOD are: [Abbott, 1983]. R.J. Abbott, "Program Design by Informal English Descriptions," Communications of the ACM, Vol. 26, No. 11, November 1983, pp. 882 - 894. [Booch, 1982a]. G. Booch, "Object Oriented Design," Ada Letters, Vol. I, No. 3, March- April 1982, pp. 64 - 76. [Booch, 1986a]. G. Booch, "Object Oriented Development," IEEE Transactions on Software Engineering, Vol. SE-12, No. 2, February 1986, pp. 211 - 221. [Goldsack, 1985]. S.J. Goldsack, Ada for Specification : Possibilities and Limitations, Cambridge University Press, Cambridge, United Kingdom, 1985. [Heitz, 1988]. M. Heitz, "HOOD: A Hierarchical Object-Oriented Design Method," Proceedings of the Third German Ada Users Congress, January 1988, Gesellschaft fur Software Engineering, Munich, West Germany, pp. 12-1 - 12-9. [Masiero and Germano, 1988]. P. Masiero and F.S.R. Germano, "JSD As An Object-Oriented Design Method," Software Engineering Notes, Vol. 13, No. 3, July 1988, pp. 22 - 23. [Seidewitz and Stark, 1986b]. E. Seidewitz and M. Stark, General Object-Oriented Software Development, Document No. SEL-86-002, NASA Goddard Space Flight Center, Greenbelt, Maryland, 1986. [Stark and Seidewitz, 1987]. M. Stark and E.V. Seidewitz, "Towards a General Object-Oriented Ada Life-Cycle," Proceedings of the Joint Ada Conference, Fifth National Conference on Ada Technology and Washington Ada Symposium, U.S. Army Communications-Electronics Command, Fort Monmouth, New Jersey, pp. 213 - 222. Object-Oriented Databases Object-oriented databases are not the same thing as relational databases. In effect, object-oriented database technology today is at the same point relational database technology was in the late 1970s. (I know more than a few vendors who would disagree with this point.) Some representative information on the subject can be found in: [Babcock, 1987]. C. Babcock, "Object is DBMS Focus," ComputerWorld, Vol. XXI, No. 40, October 5, 1987, page 25. [Blaha et al, 1988]. M.R. Blaha, W.J. Premerlani, and J.E. Rumbaugh, "Relational Database Design Using an Object-Oriented Approach," Communications of the ACM, Vol. 31, No. 4, April 1988, pp. 414 - 427. [Bochenski, 1988]. B.A. Bochenski, "On Object-Oriented Programming, Databases," Software, Vol. 8, No. 11, September 1988, page 42. [Dittrich and Dayal, 1986]. K. Dittrich and U. Dayal, Editors, Proceedings of the 1986 International Workshop on Object-Oriented Database Systems, IEEE Catalog Number 86TH0161-0, IEEE Computer Society Press, Washington, D.C., 1986. [Scannell, 1988]. T. Scannell, "Freeform DBMS the 'Object' of Startup Company's Affection," Mini-Micro Systems, Vol. XXI, No. 2, February 1988, pp. 16 - 22. [Shriver and Wegner, 1987]. B. Shriver and P. Wegner, Editors, Research Directions in Object-Oriented Programming, The MIT Press, Cambridge, Massachusetts, 1987. [Weiss, 1987]. R. Weiss, "Why Object-Oriented Databases?," Electronic Engineering Times, No. 465, December 21, 1987, page 23. [Wile and Allard, 1987]. D.S. Wile and D.G. Allard, "Worlds: an Organizing Structure for Object-Bases," SIGPLAN Notices, Vol. 22, No. 1, January 1987, pp. 16 - 26. Object-Oriented Computer Hardware Even computer hardware can be constructed in an object-oriented manner. Here are two references: [Myers, 1982]. G.J. Myers, Advances in Computer Architecture, Second Edition, John Wiley & Sons, New York, New York, 1982. [Organick, 1983]. E. Organick, A Programmer's View of the Intel 432 System, McGraw-Hill, New York, New York,1983. General Object-Oriented Technology References There are a number of general references on object-oriented technology, including: [ACM, 1986a]. Association for Computing Machinery, Special Issue of SIGPLAN Notices on th Object-Oriented Programming Workshop, Vol. 21, No. 10, October 1986. [ACM, 1986b]. Association for Computing Machinery, OOPSLA '86 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 21, No. 11, November 1986. [ACM, 1987]. Association for Computing Machinery, OOPSLA '87 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 22, No. 12, December 1987. [ACM, 1988a]. Association for Computing Machinery, OOPSLA '87 Addendum to the Proceedings, Special Issue of SIGPLAN Notices, Vol. 23, No. 5, May 1988. [ACM, 1988b]. Association for Computing Machinery, OOPSLA '88 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 23, No. 11, November 1988. [Bezivin et al, 1987]. J. Bezivin, J.-M. Hullot, P. Cointe, and H. Lieberman, ECOOP '87: Proceedings of the European Conference on Object-Oriented Programming, Lecture Notes on Computer Science, Volume 276, Springer Verlag, New York, New York, 1987. [Cook, 1989]. S. Cook, ECOOP '89: Proceedings of the European Conference on Object-Oriented Programming, British Computer Society Workshop Series, Cambridge University Press, Cambridge, United Kingdom, 1989. [Gill, 1988]. P. Gill, "MIS Slowly Warms Up to Object-Oriented Programming," ComputerWorld, Vol. XXII, No. 8, February 22, 1988, pp 71 - 76. [Gjessing and Nygaard, 1988]. S. Gjessing and K. Nygaard, ECOOP '88: Proceedings of the European Conference on Object-Oriented Programming, Lecture Note on Computer Science, Volume 322, Springer Verlag, New York, New York, 1988. [Millikin, 1989]. M.D. Millikin, "Object Orientation: What It Can Do For You," ComputerWorld, Vol. 23, No. 11. March 13, 1989, pp. 103 - 113. [Peterson, 1987a]. G.E. Peterson, Tutorial: Object-Oriented Computing, Volume 1: Concepts, IEEE Catalog Number EH0257-6, IEEE Computer Society Press, Washington, D.C., 1987. [Peterson, 1987b]. G.E. Peterson, Tutorial: Object-Oriented Computing, Volume 2: Implementations, IEEE Catalog Number EH0257-6, IEEE Computer Society Press, Washington, D.C., 1987. [Shriver and Wegner, 1987]. B. Shriver and P. Wegner, Editors, Research Directions in Object-Oriented Programming, The MIT Press, Cambridge, Massachusetts, 1987. There are many articles which might be considered "landmarks." Look for early (early 1950s) articles discussing artificial intelligence, early works by Alan Kay (either in the late 1960s, discussing his FLEX machine, or in the very early 1970s, discussing Smalltalk), early reports on SIMULA (from the late 1960s, by K. Nygaard and Ole-Johan Dahl), and, more recently, the OOPSLA and ECOOP proceedings. > 3. Teaching OOP seems easy when it comes to concept as there exists > number of well established metaphors. The real problem seems to be > methodology. Does anyone have any pointer to object oriented > programming methodologies? I dread answering this question (:-)). As you can see from the reading list (answer to previous question), there are some references to object-oriented anaysis and object-oriented design. I have developed and used methods for documenting individual classes: "object and class specifications" (OCS, pronounced ox). These have been in use on real projects (both at my former company and at several of my client's sites) for a little over three years. If you would like one or two sample OCSs, and about 84 slides describing OCSs, OORA, OODA, and OOD send me your snail mail address (too much to FAX, and lots of graphics). > 4. When teaching functional programming languages such as Lisp the > interpreter (eval, apply) is often used to better understand the > execution model and how it may be altered. Is it essential to explain > the virtual machine of an object oriented language in the same manor?] > And if so what depth? The Smalltalk execution model is quite complex > in detail In my humble opinion, these items are at the "noise level." A far more difficult task is to give the students the ability to identify, differentiate, and describe such things as objects, classes, and values. I have met many so-called object-oriented programmers who cannot differentiate between a concept and its implementation. I obviously feel that concepts are more important than implementations. (Please note that I am not saying that all implementation issues are unimportant.) >Mikael R.K. Patel -- Ed Berard Berard Software Engineering, Inc. 18620 Mateney Road Germantown, Maryland 20874 Phone: (301) 353-9652 E-Mail: eberard@ajpo.sei.cmu.edu
alanm@cognos.UUCP (Alan Myrvold) (08/02/89)
In article <1318@massormetrix.ida.liu.se> mikpa@massormetrix.ida.liu.se (Mikael Patel) writes: >Dear Object-Oriented Programmers out there in Net-Land. I need your help! > >I am working on a course on Object Oriented Programming (OOP) for third and >fourth year students on our civil engineer lines. I'd like some advice Easy : here's a course outline: 1) Motivation for OOPs (re-use, information hiding, memory management) 2) The Smalltalk execution model 3) The Eiffel type system (including proposed checking in future releases, to close the existing holes) 4) Hybrid languages ... C++, Objective C, misc. Pascal extensions 5) Two small projects - one in Eiffel, the other in Smalltalk That should keep 'em busy for the term. :-) - Alan --- Alan Myrvold 3755 Riverside Dr. uunet!mitel!sce!cognos!alanm Cognos Incorporated P.O. Box 9707 alanm@cognos.uucp (613) 738-1440 x5530 Ottawa, Ontario CANADA K1G 3Z4
eberard@ajpo.sei.cmu.edu (Edward Berard) (08/05/89)
In article <80500066@p.cs.uiuc.edu>, johnson@p.cs.uiuc.edu writes: > > >If you find any object-oriented examples of any size, you will find > >that they often address such issues as "object-oriented domain > >analysis," "object-oriented requirements analysis," and > >"object-oriented design." Unfortunately you will find precious few > >references to "object-oriented development in the large" (OODIL) -- > >but there are a few. > > As far as I can tell, there aren't any problems in OODIL that are > unique to OO, they are all caused by the DIL. Consider the following: Object-oriented approaches offer some surprising benefits in the area of configuration management. The introduction of the concept of subroutines in the 1950s allowed people to group lines of code, give them a name, and, thus, manage large amounts of code more easily. For example, it is easier to manage 10 subroutines, each with 100 lines of code, than it is to manage 1000 lines of unpartitioned code. You might say that a class is to a subroutine, as a subroutine is to a line of code. Specifically, classes can be viewed as encapsulating several subroutines, as well as some other material. Classes allow you to more effectively manage large amounts of code, than do simple subroutines. The object-oriented paradigm, it appears, is a very useful way of managing complexity in large systems. It offers significant benefits over approaches which partition software along functional lines. (If you are not using a language which directly supports something like a class, your benefits are not all that they could be.) If this is so good, then where is the problem? There is an axiom of system design that says: the larger the overall system, the larger the size of the largest objects ("objects" here is being used in the generic, non-software sense) in the system. What this means for the object-oriented paradigm is that for very large systems, even classes are not enough, we need something bigger. Two concepts that become very useful in large, object-oriented systems, and are _unique_ to object-oriented systems are: subsystems and systems of objects. Let me define each concept. Subsystems are collections of items which support large, object-oriented concepts. For example, consider windows. To support the concept of windows, many classes are required, e.g., several different types of window classes, scroll bar classes, text classes, graphics classes, and more. To offer as much flexibility as possible, it is desirable to keep each of these classes as independent of each other as possible. Subsystems are highly logically cohesive. That is, all the components of the subsystem are there to support a single, large, object-oriented concept. Subsystems, however, are not very physically cohesive, i.e., there is no requirement that there be a direct or indirect physical connection between any two arbitrary components of the subsystem. Subsystems can be viewed as having three parts: - An export (or visible) part which contains those items which the subsystem wishes to make available to the outside world. These items include objects, classes, other subsystems, systems of objects, and other items (usually dependent on the programming language being used). - A body (or hidden) part which contains those items necessary to support the items in the export part. The items contained in the body part are not available (or are not _supposed_ to be available) to the outside world. - An import (or requirements) part which details the items necessary to use the subsystem, i.e., these are the items which users of the subsystem must supply to use the subsystem. You might say these are the parameters for the subsystem. Subsystems, as you might have guessed, tend to be large, e.g., 20,000 lines of code and more. There are several methods for designing subsystems, but I don't have time to go into them here. However, speaking as both a designer and user of subsystems, they are worth the effort, and, if designed well, are highly reusable. Let's now discuss "systems of objects." We generally think of objects as having a single, cohesive interface. We might be initially tempted to say that a big object might still have a single interface. However, two things may make our interface overly complex: - the overall size and complexity of the object itself, and - a requirement that our object interface with a number of different classes of object, and provide different sets of services to each of these classes. Consider an automobile engine. Most object-oriented people would be willing to stipulate that an automobile engine is a single cohesive object. However, consider the interfaces to the engine object. There is the interface to the transmission, the interface to the fuel system, and the interface to the cooling system, for example. Each of these interfaces is totally disjoint, e.g., when the transmission interfaces with the engine, it doesn't care about such things as the fuel system or the cooling system. If we attempted to combine all of these separate interfaces into a single, large interface, the resulting interface would not be very logically cohesive. For a large object, with several (two, or more) distinct and disjoint interfaces we should consider a "system of objects." There is the trivial case of a large system of objects which has a single interface. This is little different from a small object with its single cohesive interface. The more interesting cases involve large objects with two, or more, distinct interfaces. (Consider a post office. There is the interface seen by the postal patrons in the front, and the interface seen by mail trucks and letter carriers in the back.) Note that "systems of objects" are highly logically cohesive, _and_ highly physically cohesive. They differ from smaller simple objects in that they allow for multiple, disjoint interfaces. There is a requirement that each of these disjoint interfaces be logically cohesive. As with subsystems, there are several methods for designing systems of objects. I do not have the time to go into them here. You might also want to give some thought as to how object-oriented configuration management might be different from traditional configuration management. > > One feature of object-oriented technology is that it squashes together > the various phases of the design cycle. OOP is great for prototyping, > so usually systems are built during the requirements analysis phase to > help figure out what the user needs. Not surprisingly, a certain amount > of design information is discovered here as well, and sometimes a few > components are developed that are reused later. Here, you have observed what other have observed: that the object-oriented life-cycle is different from the traditional, waterfall life-cycle. Note that I am talking about something different from the use of object-oriented techniques for rapid prototyping, and something different from the use of object-oriented techniques in a spiral life-cycle. The object-oriented life-cycle has been described as a "recursive/parallel" life-cycle. While I would prefer not to go into detail on this approach, I will tell you that its description has often been oversimplified to: "Analyze a little, Design a little, Implement a little, Test a little." This yields some interesting results, especially when people attempt their first large, in-house object-oriented project. Many existing software development standards (government, in-house, and those described in software management texts) assume a functional decomposition approach, and thus present problems when someone attempts to use them with an object-oriented approach. [If you are doing small, one-person projects, you seldom notice this problem, unless, for example, someone asks you to show "input-processing-output" for your objects, or asks to see a "structure chart."] > At the other end of > the life-cycle, I find that code is not reusable until it has been > reused, and this implies that you have to redesign software after it > has been used in a couple of projects. If you study software reusability technology, you find that you do not have to approach software reusability in a "trial and error" manner. You really can design software so that it is reusable _without_ _modifications_ later. There are techniques, rule, methods, and guidelines which can be used at all levels of abstraction to ensure and enhance software reusability. (I incorporate many of these items into the courses on object-oriented technologies that I teach.) > On the other hand, OOP provides a consistent world-view that can carry > you through the whole life-cycle. Requirements analysis is determining > the objects from the users point of view and figuring out what operations > will take place on them. Design is decomposing these objects into smaller > objects, delegating responsibility for operations to various objects, > determining the class hierarchy, and discovering new classes that are > part of the solution domain, not the problem domain. Implementation > is writing code for all the operations and defining data structures > for the classes. Invariably new classes are discovered and the design > is revised during implementation, but that's just because top-down > development is impossible to carry off perfectly. In attempting to define, document, and apply Object-Oriented Requirements Analysis (OORA), Object-Oriented Design (OOD), Object-Oriented Domain Analysis (OODA) over the past 8 years, I have to agree with you in principle. However, there are some points that I would clarify, e.g.: - It is not the purpose of OORA to identify _all_ of the code software objects and classes in the system. It is perfectly normal, healthy, and _expected_ to uncover additional objects and classes during an OOD process. In fact, the larger the overall project, the greater the percentage of objects and classes which will be uncovered during OOD. - Some objects and classes, will be described in OORA to provide some context for the problem. However, these items may never become code software. (One of the nice things about an object-oriented approach is that people, hardware, and code can all be viewed as objects, and treated in a similar manner. Can you say polymorphism? ;-)) > >Most of the work which has been done in the area of object-oriented > >life-cycle issues, outside of object-oriented programming, has been > >accomplished within the Ada community. > > In general, I don't like this work. Speaking from the point of view > of a Smalltalk programmer, I think that they are really talking about > data abstraction and NOT object-oriented programming. Important > issues that they miss are the importance of building families of > components with the same interface, using abstract classes for > templates for new components, and polymorphism. > > On the other hand, I haven't read all these papers, so perhaps I am > missing something. I'll read them. You are partially correct. Much, but not all, of the early (starting in 1980) work in attempting an object-oriented approach for Ada software development did center on data abstraction. However, much work has been done to incorporate many of the principles of object-oriented thinking found in the traditional object-oriented programming (OOP) community. Regarding the building of families of components with consistent interfaces: I would strongly recommend that you look at Grady Booch's second book (Software Components With Ada), or that you contact my former company, EVB Software Engineering, Inc. (800-877-1815), and ask about GRACE (Generic Reusable Ada Components for Engineering), or that you get a copy of my course notes from "Creating Reusable Ada Software." One of the things that all of these items directly, and explicitly, address is that reusability is enhanced through uniformity, and there is explicit mention of families of components with consistent interfaces. Regarding the use of abstract classes as templates for building new components: Let me assure you that the construction of the over 512K lines of source code which comprise GRACE would have been virtually impossible without this concept. The developers achieved productivity rates of over 8,000 lines of code/person/month. That is fully documented, warranted code. Booch's book talks about this issue as well. Regarding polymorphism: The construction of many of the resuable software components described in Booch's book, or which comprise GRACE, or the Common Ada Missile Packages (CAMP), would have been fairly difficult without some degree of polymorphism. There is other work being done to enhance the incorporation of polymorphism into object-oriented Ada software, especially in the area of communication systems. [I am not one of those who will try to tell you that Ada is an object-oriented language. Ada clearly does not follow the Smalltalk paradigm very closely. However, many in the Ada community have recognized the value of object-oriented approaches to software development. Like any good engineer, they have "stolen" a good deal of the useful technology that the OOP community has to offer.] (I better stop talking about Ada before some "C Fundamentalists" come after me. You know the joke about what is difference between C programmers and the Iranian Revolutionary Guard? The Iranian Revolutionary Guard is less fanatical. ;-)) -- Ed Berard (301) 353-9652 P.S.: If you think this message is long, look at the one I posted to comp.lang.c++ on "object coupling," or the one I posted to comp.lang.ada on "objectification."
eberard@ajpo.sei.cmu.edu (Edward Berard) (08/13/89)
In article <80500067@p.cs.uiuc.edu>, johnson@p.cs.uiuc.edu writes: > The point > I was trying to make is that OO provides solutions to the problems > of DIL, it does not introduce any. (Other than the problem of learning > to use the solutions.) Perhaps Ralph and I can agree on the following points: - Software engineering in-the-large (e.g., software engineering efforts which require two, or more, interacting people, usually involve six, or more, months of calendar time, and involve software products which are at least 16K lines of code) presents a different, and more difficult, set of problems, than does software engineering in-the-small. See, for example, F. DeRemer and H.H. Kron's landmark 1976 article, "Programming-In-the-Large Versus Programming-In-the-Small," (IEEE Trans. On Software Enginering, June 1976), or Barry Boehm's book: Software Engineering Economics (Prentice Hall, 1981), or Capers Jones's IEEE tutorials on Programmer Productivity. Software engineering research tells us that as the size of the effort goes up: - software engineering productivity (using any metrics) goes down - the "error density" (i.e., the number of errors per unit of output) also increases - new activities begin to appear, e.g., configuration management might be considered overkill for a 500 line-of-code program, but is an absolute necessity for projects of the size of 16K lines of code, or larger - the size of the largest units of software increases - the need for rigor in the actual engineering process becomes mandatory - As one might suspect, object-oriented software engineering in-the-large is different from object-oriented software engineering in-the-small. Since object-oriented software engineering in-the-large is still a _human_ activity, we would still notice all of the above problems. However, if done well, an object-oriented approach should mitigate these problems to some degree. - What type of differences would we see in a large, object-oriented software engineering effort, as opposed to a small object-oriented software engineering effort? Experience tells us to expect the following: - As both Ralph and myself have mentioned, there will be a definite need to create (at least logically, if not physically) and manage entities larger than a single class. - There will be a significant increase in the number of composite classes. - Functional decomposition approaches emphasize decomposition, and small object-oriented approaches have always emphasized composition (i.e., identification and creation of the components, then assembling of the components into the application). However, as the size of the overall product increases, the necessity of using an approach which includes _both_ composition and decomposition increases. The (object-oriented) decomposition techniques should help us to better manage complexity. - The importance of stable, well-defined interfaces increases dramatically. Even something as simple as the change in the interface to a single class can have a disastrous ripple effect on the entire system. > > A language for building large systems needs a mechanism for limiting > the visibility of names. There is nothing in Smalltalk to implement > exporting and importing in the way Ed describes. Some people think > that classes provide sufficient modularity, but they are wrong. I agree, and I would like to add that this problem is hardly unique to Smalltalk. > > The goal of object-oriented design is a large library of reusable > components that can be used to quickly build applications. While reusability is an important goal of an object-oriented approach, it is not the only important goal. The following are also goals: - Increased ease of modification. If done correctly, object-oriented approaches produce the software equivalent of "pin compatible" and "plug compatible" hardware. Specifically, it becomes relatively easy to remove one, or more, components (objects) from a system and to substitute new (different) ones, or to extend the existing system. - Facilitation of interoperability. Consider a computer network containing potentially different computer systems at each node. Instead of viewing each node as a monolithic entity, each node should be viewed as a collection of (hardware and software) resources. Interoperability is the degree to which an application running on one node in the network can take advantage of a (hardware or software) resource on a different node in the same network. The emphasis on polymorphism in an object-oriented approach, helps to reduce the overall complexity of network software, and thus facilitates interoperability. (Without a polymorphic approach, for example, "name space" would quickly become unmanageable, and the number and size of composite operations would also undesirably increase.) - Easing of configuration management problems, per our earlier discussions. - In addition, a report produced by Debbie Boehm-Davis and Lyle Ross for General Electric indicated that, when compared to solutions for the same problem using SASD and Jackson System Development, object-oriented solutions appeared to be: - smaller (using lines of code as a metric) - simpler (using McCabe's and Halstead's metrics) - better suited for real-time systems - more quickly finished. All of the above are also desirable goals. > >> At the other end of > >> the life-cycle, I find that code is not reusable until it has been > >> reused, and this implies that you have to redesign software after it > >> has been used in a couple of projects. > > >If you study software reusability technology, you find that you do not > >have to approach software reusability in a "trial and error" manner. > >You really can design software so that it is reusable _without_ > >_modifications_ later. There are techniques, rule, methods, and > >guidelines which can be used at all levels of abstraction to ensure > >and enhance software reusability. (I incorporate many of these items > >into the courses on object-oriented technologies that I teach.) > > I strongly disagree with Ed on this point. I have studied the literature > on software reusability, and I don't think much of it. I have to agree that there is a lot of "froth" in reusability literature, and quite a few "content free" articles. However, if you do quite a lot of reading, and attempt to apply what little good technology there is, your efforts will be handsomely rewarded. [I am struck by a powerful analogy. Many of the people that I come into contact with, have a great many misconceptions about what "object-oriented" means, e.g., it's another name for a data-driven approach. These people have an unrealistic "fantasy" about what object-oriented means. This is made worse by the number of articles which "document" these fantasies. The same phenomenon occurs in the reuse arena. Many people have a fantasy about what reuse should be, e.g., a library of reusable functions. Some of these people even write articles about their fantasies.] I have been able to document and successfully apply techniques for making classes resuable when they are first created. We can remove about 80% to 90%, and, in some cases, all, of the guesswork. Unfortunately this documentation currently exists chiefly in the form of "class notes." > We use good design techniques, and the more experienced people do a fairly > good job of making reusable designs. However, there are ALWAYS surprises. > It is not possible to predict all the ways that software will need to be > reused. However, experience shows that experience will show the range of > uses of software. Thus, it is relatively straightforward to produce > reusable software if you expect that it will be the RESULT of the project, > not something that gets produced in the first phase. > Here we are in general agreement. As I said earlier, it is not possible to remove all the guesswork, all the time. But you have made some observations which many others can also support: - It is much easier to create reusable software if that is your main intention, as opposed to "reuse being a 'minor' goal of a development effort." This finding not only has been documented countless times, but is one of the primary motivations for a branch of software engineering called "domain analysis." Domain analysis is the study of an application domain with the intent of discovering, and creating, reusable components. (This has been a research topic of mine, and, per usual, I have a lot to say on the topic.) One of the landmark documents on domain analysis is the 1980 doctoral thesis of Jim Neighbors, a graduate of UC Irvine. - Reuse permeates everything. It impacts coding practices, design and analysis approaches, testing, maintenance, and software quality assurance, standards and practices, database schema, CASE tool selection and usage, management practices, and customer relations. Is it any wonder, with the number of items which must be coordinated, why it is difficult to produce reusable software? - Reuse must be a conscious effort. Too often you see courses on the syntax and semantics of a programming language, and _separate_ courses on software reusability. If you want reuse to work, you have to incorporate it into everything you do. Notice that reuse is the norm in the computer hardware industry. Further, notice that the concept of reuse is incorporated into much of the coursework, and day-to-day practices, of you typical EE. > > It is not the purpose of OORA to identify _all_ of the code > > software objects and classes in the system. It is perfectly > > normal, healthy, and _expected_ to uncover additional > > objects and classes during an OOD process. > > I distinguish between problem domain objects and solution domain > objects. The problem domain objects are the ones that are identified > during the analysis and are the ones that the users think about. > As Ed says, these often include parts of the environment that do not > need to be represented as classes in the final solution. The solution > domain objects are the ones that turn up during design and implementation. > Of course, sometimes you discover problem domain objects later than you > would like, since the users often don't tell you everything you need > to know. That's life! One of the things Larry Constantine wondered about, and which later led him to be driving force behind structured design, was "could you _systematically_ engineer good software the first time, and further could you _know_ that you had engineered good software?". Someone named Graham had observed: "We build system the way the Wright Brothers built airplanes. Build the whole thing, push it off a cliff, watch it crash, and start all over again." Harlan Mills has stated: "Programs do not acquire bugs the way people do germs -- simply by hanging around other buggy programs. ... Errors in logic and construction should be extremely rare, because we can prevent them through positive efforts on our own part." Software engineers are often more fatalistic than they have to be. We are the classic examples of self-fulfilling prophesies. You don't expect it to compile clean the first time or run the first time? No problem, you got it. Forgive me, Ralph. I am in no way implying that you advocate a lackadaisical approach to software engineering. I just want others to know that you are really saying, "do the best job you can, and consciously strive to avoid the introduction of errors, but realize that even the best laid plans ..." [I would cite the Scottish poet Robert Burns, but software types are not supposed to be literate. ;-)] > The most important reason [to reuse interfaces] > is that it makes it possible to provide > a set of components that you can connect together to build an application. > For example, a user interface framework like InterViews lets you build > an interface by connecting buttons, text viewers, scrollers, etc. together. > Unless you need customized graphics there is unlikely to be any need to > define any new components. This is impossible unless you are able to > connect any component to any other component, i.e. unless there are > shared interfaces. Moreover, this also requires a kind of polymorphism > that cannot be simulated with generics. [I don't want to be drawn into a discussion of the capabilities of the often misunderstood language, Ada. However, ...] Let me just say that my old company constructed just such a system (i.e., like InterViews) in Ada. This system _did_ allow you to connect any component to any other component. (Although, in truth, certain limitations on this capability were designed in, to enforce some prestated rules about which combinations of objects made sense, and which combinations didn't.) Polymorphism in Ada involves more than just using generics, e.g., it requires a heavy dose of limited private types. The overall thinking is the same, but the implementation is different. Please. If Ralph, or anyone else, wants to engage in a discussion of object-oriented concepts in Ada, either contact me direct via e-mail, or move the discussion to comp.lang.ada. After all, this is comp.lang.smalltalk. As usual, my message runneth over. Thanks. -- Ed Berard (301) 353-9652