Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!bse.com!eberard From: eberard@bse.com (Edward V. Berard) Newsgroups: comp.lang.c++ Subject: Re: C++, Object Design Methodologies and Software Engineering Summary: recipe for disaster Keywords: oo design Message-ID: <0B010001.o8bxpd@bse.com> Date: 13 Oct 90 19:17:14 GMT Reply-To: eberard@bse.com Organization: Berard Software Engineering, Inc. Lines: 142 X-Mailer: uAccess - Mac Release: 0.2.6 In article <24872@uflorida.cis.ufl.EDU>, rmy@beach.cis.ufl.edu (Rasthiyaadu Yakaa) writes: > > On a database project, the work was divided up based on > functionality, e.g. data dictionary, query processor, object > management, among various individuals. Of course, a top down > design was done (blah, blah ..) I have quite a number of comments based on real life experience: 1. While a top-down approach is compatible with an object-oriented approach, dividing the system up "based on functionality" is asking for trouble. This is due to the different types of localization used for functional decomposition approaches and object-oriented approaches. Simply put, functional decomposition approaches localize information around objects, and object-oriented approaches localize information around objects. Objects are not functions and functions are not objects. What happens is this: Very often some information about an object is placed in one functional "chunk" (piece of the system), and other information is located in other functional chunks. Each functional piece of the system is then usually handed off to separate teams. Each team then attempts to identify objects in their specific chunk. As they identify objects, they will attempt to characterize the object they have based on the information at hand, i.e., their specific chunk. Unfortunately, it is highly unlikely that their chunk of the system contains a complete description of the object. Further, it is also very likely that if the "same" object shows up in other chunks, it will appear to have different characteristics -- and, thus, will be designed differently. All will appear to be going well until integration time. If objects must be transmitted among several parts of the system, those dealing with objects coming from other chunks of the system will notice that others did not characterize the "same" objects in the same way. If you are working with a strongly typed language, some intended interactions may not be allowed. Even if you are dealing with a comparatively weakly typed language, some operations will not be possible due to such things as "missing" operations in object interfaces. As you begin to modify the system objects (and possibly even the system design) to compensate for these problems you will uncover other interesting phenomena. For example, you will find that many objects which should be common to several different parts of the system, will have been implemented many different times in many different ways (so much for reusability). What will be especially irritating to management is the fact that the effort seemed to be going along at an acceptable pace, until integration time -- then a lot of re-work will slow progress to a crawl. The way to avoid all this nonsense is to do two things. First, identify objects at the beginning of the effort. Specifically, survey the entirety of the requirements information to identify candidate objects, and survey the entirety of the requirements information again to gain as complete an understanding of the objects as possible. (This information will be in two general categories: information about each object in isolation, and information about how the objects will interact to affect a solution to the original problem.) The second thing you need to do is an object-oriented decomposition (i.e., _not_ a functional decomposition). Identify the large objects in the system, then identify the objects which make up these objects. Continue the process until you have small, easily-definable objects. This is not unlike designing an automobile. The automobile is a large object composed of several smaller objects, e.g., an engine, a transmission, and an electrical system. These will, in turn, be composed of still smaller objects, e.g., nuts and bolts. 2. The connotations of what an object is in terms of an "object management system" often conflict with what an object is in the classic object-oriented sense. > The question is: would it be wrong to define a class that simply > represents an interface to a layer or module. It would represent > collectively a set of interfaces corresponding to a software > module. e.g. a dictionary-handler class which represents the > outside interface to a DBMS dictionary or catalog (which are > implemented as classes and objects). If this is OK, > what is the connection between such an interface class and > system (dictionary) objects and classes. If this is not OK, > what are we doing wrong ? Here, you are touching on object-oriented development in the large (OODIL). The problem you have encountered is not unlike dealing with a very large object, e.g., an automobile. When I drive a car, I am oblivious to the smaller components which make up the car, e.g., I do not see the engine. Even if I raise the hood (bonnet), and look at the engine, I cannot see all the objects which are internal to the engine. There are several key points: 1. By viewing a system as simply a large object, and asking what should be in the interface to this object, with no regard to how the object is implemented internally, I avoid the problem of attempting to put a coat of "object-oriented paint" on something which is clearly not an object, i.e., a functionally-designed component. 2. While classes, metaclasses, and instances of each are sufficient for small, textbook problems, they are not entirely satisfactory for larger systems. For example, consider the engine of an automobile. It presents one interface to the transmission of the automobile, another (completely different) interface to the fuel system, and yet another different interface to the cooling system. In effect, the engine is a very large object with what appears to be several completely disjoint interfaces. (For a better picture, ask yourself if your university or company is an object. Of course it is. Now ask yourself if there is only one interface to this very large object. No, there are many.) There will be other large objects which seem to represent capabilities rather than stand-alone applications. For example, consider a windowing system, e.g., X Windows. rather than being a very physically cohesive system of objects, it appears to be more like a library of objects whose purpose is to support a very large object-oriented concept, i.e., windows. To construct a dialog window, for example, you will need quite a number of objects, e.g., radio buttons, check boxes, static and editable text, icons, pictures, scroll bars, etc. The first large object I mentioned (i.e., the one with a high degree of physical cohesion and the possibility of multiple disjoint interfaces) is what I refer to as a "system of interacting objects." You might say that each object-oriented application you create is just such a beast. The second large object (i.e., the one which has a high degree of logical cohesion (the objects are all there to support a larger, object-oriented concept) and is granular (you can select individual components)) is what I and others refer to as a "subsystem." 3. In designing any system, but especially a large system, it is crucial to have well-defined interfaces among the components. These interfaces should be defined early, and should remain fixed. Otherwise, it is difficult to "hand off" pieces of the system to different teams and expect them to smoothly integrate the pieces. -- Ed ---------------------------------------------------------------------------- Edward V. Berard | Phone: (301) 353-9652 Berard Software Engineering, Inc. | FAX: (301) 353-9272 18620 Mateney Road | E-Mail: eberard@bse.com Germantown, Maryland 20874 | ----------------------------------------------------------------------------