CPSC 333 --- Lecture 29 --- Monday, March 25, 1996 Object-Oriented Design This is the step between object-oriented analysis, and the implementation of an object-oriented system. Activities that one might expect to perform at this stage would include - introduction of classes and objects that *aren't* abstractions of things in the problem domain, but that are necessary parts of the system. In their book on "Object-Oriented Design," Coad and Yourdon suggest that you might expect to add classes and objects in - a human-computer interaction component - a task management component, and - a data management component They obtained this set by looking at object-oriented systems that had been developed and that had been perceived to be successful, and by trying to identify common features or properties that these have. This seems like a plausible list to include for a moderately-sized business processing system (at least, it seems this way to the course instructor); it isn't clear that these components are all necessary, or that the list is complete, in general. - classes and objects that you obtain by "refining" the classes and objects that correspond to things in the problem domain --- perhaps moving from "problem-level" classes toward "implementation-level" or "system-level" classes; perhaps moving from a "high level of abstraction" to a "low one". Ideally, since these methods are supposed to support *software reuse*, most of *these* new classes are chosen from software libraries instead of being developed from scratch One significant difference between "structured development" and "object-oriented development" is that, as it's usually described, object-oriented development does *not* include separate notations for specification and for design: Instead, the notation for classes and objects, etc, used in the model that's developed during analysis is the same as the notation used for design --- we *don't* have "data flow diagrams" for analysis and "structure charts" for design, etc. So, instead of having an abrupt change (and an elaborate process needed to translate one notation into another), the progression from analysis/specification to design is described as quite gradual, and smooth, for object-oriented development. In his book on "Object Oriented Design" Grady Booch describes this process as "incremental" and "iterative". Another significant difference between the two kinds of development is that the rules you need to apply in order to perform object-oriented design are (arguably) less well-defined, and harder to follow, than the corresponding rules for "structured design": There isn't yet a set of simple steps you can take in order to get a "workable" object-oriented design (from an object-oriented specification) that can be then assessed and improved. One can argue that this is to be expected, since the types of systems being developed now (and which object-oriented development must deal with) are more complex, and more varied, than the kinds of systems that were being considered with "structured methods" were being formed. Unfortunately, one can also argue that this is evidence that "object-oriented" methods aren't yet stable, or mature: These methods still seem "promising," but it isn't clear yet that some of the promises that developers of object-oriented methods have made have yet been kept (or that some of their claims have been correct). So, an "object-oriented design" method hasn't been described in this course in part because it isn't clear yet that a teachable, general, and useful object-oriented design method exists. It also isn't clear that "object-oriented design" methods that are being described now will closely resemble "object-oriented design methods" that have been developed in five years' time. You should expect that "object-oriented methods" will continue to change quite substantially in the recent future. Here are some references for additional reading, if you're interested in "Object-Oriented" Design." The *books* should all be in the library, except possibly for the last one (and several are on reserve for this course.) Grady Booch Object Oriented Design with Applications Benjamin/Cummings, 1991 - Design is described here as "incremental" and "iterative" (as it frequently seems to be). The last section, on "Applications," describes several different kinds of systems, each of which is implemented using a different object-oriented (or object-based) language James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen Object-Oriented Modeling and Design Prentice-Hall, 1991 - A rather different "design" method is described here, which is (possibly) a bit more concrete. Again, the last few chapters describe applications of the method to develop several different object-oriented systems Peter Coad and Edward Yourdon Object-Oriented Design Prentice-Hall, 1991 - The authors here seem to be trying to be providing at least a few of the features of "structured design" that seem useful: An attempt is made to describe (pieces of) an "architecture" for a system that might be of general use, and a set of criteria for assessing and improving object-oriented designs (including versions of types of "coupling" and "cohesion" that are appropriate for object-oriented systems) are proposed Ian Graham Object Oriented Methods Addison-Wesley, 1991 - This seems to be a somewhat more academic introduction to the subject (at least, than Coad and Yourdon's book). Among other things, it notes work in simulation programming, and also some work in artificial intelligence, that have had influences on object-oriented methods. It also contains a discussion of, and a few proposed improvements for, Coad and Yourdon's method for "Object-Oriented Analysis." Anton Eliens Principles of Object-Oriented Software Development Addison-Wesley, 1994 - Another more "academic" introduction to the topic Certainly, alternative methods have been proposed since most of these books appeared, and the methods that these describe have been refined. Here are some more up-to-date reference that might be interesting: Communications of the ACM October, 1995 --- Volume 38, Number 10 (Issue Devoted To) "Object-Oriented Experiences and Future Trends" ... this includes articles entitled ... "The Promise and the Cost of Object Technology: A Five-Year Forecast" ... and, in a section on "Object-Oriented Experiences": "Lessons Learned from the OS/400 OO Project" "Using Design Patterns to Develop Object-Oriented Communication Software" "Developing an Object-Oriented Software Testing and Maintenance Environment" "Object-Oriented Parallel Computation for Plasma Simulation" ... and finally, in a section entitled "Smalltalk on the Rise": "Why Smalltalk?" "Smalltalk Reaches Crossroads in the Insurance Industry" "Smalltalk in the Telecommunications Industry" "Ubiquitous Applications: Embedded Systems to Mainframe" "Smalltalk Training: As Innovative as the Environment" Note that Smalltalk is an object-oriented language that predates C++. It's been recommended before (and I'll recommend it again) that, if you know C, then a natural way to move to C++ --- *and* to have a reasonable chance of using the features that C++ provides effectively, instead of just "writing the same programs that you could have in C, but using slightly different syntax" --- is to learn Smalltalk (which is more "purely" object-oriented than C++ is, and doesn't look much like C at all) --- and them move from Smalltalk to C++ after that. Smalltalk has been dismissed as a language that might be useful for rapid prototyping, but whose compilers, etc., aren't efficient enough for production of development code --- so the inclusion of this section on Smalltalk is interesting and might be a bit surprising. Finally: One of these articles mentions "Design Patterns". These represent an attempt to provide a way to document *system architectures* that have been used successfully to construct object-oriented systems in various application domains. It's possible that the incorporation of these into an "object-oriented design" method could eliminate one of the concerns that's been expressed (above) about "object-oriented design" --- that it doesn't give quite enough guidance in order to make system design as easy as it should be (at least, when object-oriented systems have been developed successfully to solve the same kind of problem already). A reference that is cited in this article is: W. Pree Design Patterns for Object-Oriented Software Development Addison-Wesley, 1994 ... Caution: I haven't yet *seen* this book, so I can't really recommend or discuss it. ---------------------------------------------------------------------- Formal Methods for Software Development (Mostly, but not Exclusively, for Specification of Requirements) Structured methods --- and object-oriented methods --- generally rely on the use of pictures that are supplemented by natural language (or structure-English "pseudocode") descriptions, in order to specify requirements. A Problem with Pictures: They're (arguably) easy to produce, and might be adequate as specifications of requirements under some circumstances --- but there's a sense in which they are "inherently imprecise." It is difficult to specify a precise meaning for each graphical element that a picture might include, without limiting the kinds of requirements that *can* be specified. Note that most descriptions of DFDs, etc., *don't* include precise interpretations of arrows, etc --- or a description of how a wide range of plausible requirements can be modeled. Organizations that use these cope with this by developing their own "in-house" definitions and standards, or simply might accept (or ignore) the fact that these pictures are imprecise. A Problem with Any Specification that's Based on a Natural language (like English): It is *very* difficult to specify requirements in English, in a way that will be precise and unambiguous. Even if you manage to do this, it's to be expected that a substantial number of people *reading* the resulting specification will still misinterpret it. This is (arguably) acceptable if you're using these modeling tools to specify requirements for a commercial video game, or for software you're using yourself, whose accuracy isn't critical. It *isn't* acceptable if you're specifying requirements for part of a system that controls a nuclear reactor, is part of the guidance system for an airplane or space shuttle, or for any other system with complex and critical requirements related to safety or reliability. For the rest of this course we will consider an alternative method for specification of requirements that is based on *mathematics* (especially set theory and logic) instead of pictures or a nature language like English. This method - is *not* a more useful method to specify *all* kinds of requirements: For example, the "best" way to specify many requirements relating to a human-computer interface will probably always be to use pictures --- of screens that are to be displayed, menus to be used, forms to be filled out, etc. A description of these that's based on "mathematics" would probably not be very useful at all. - does *not* require mathematics that is particularly difficult: Much of the mathematics (and notation) that it requires was covered in Mathematics 271 - *does* provide more precise specifications for at least *some* kinds of requirements - *can* be used to generate specifications that a non-expert could be expected to understand --- PROVIDED that the mathematical specifications are supplemented by simple comments (written using simple English phrases) when appropriate. In class, I frequently won't be writing the "simple English phrases" down on the blackboard --- but I'll be saying them out loud when the specifications are being developed - *can* be expected to increase the time and effort required for specification of requirements. In at least some cases (and, this has been supported by at least some studies), these can also be expected to *decrease* the time and effort required for implementation, testing, and maintenance, so that total cost for system development and maintenance might not be significantly increased, and might plausibly be *decreased*, when these techniques are used. However, it *doesn't* seem sensible to use these to develop a video game, develop software that you're going to use for yourself for a while and then throw away, etc. - *can* be combined with object-oriented development methods, at least to some extent --- although I wouldn't be surprised if all the qualifications I've made above are still valid. See the book by Eliens, listed above, for a reference that includes a brief discussion of the use of "formal methods" in object-oriented development. Here are two "potential" uses of formal specifications - It is possible (in some cases) for these to be the starting point for a different "development" method, in which one uses a large number of small, "correctness-preserving" steps (each adding implementation details) in order to move from a specification of requirements to an implementation - It makes "proof of *correctness* of programs" possible --- at least in principle. Formal rules that specify the effects of statements in some programming languages *have* been specified (*not* for C or C++ --- at least, not for anything but tiny subsets of each). Combined with formal specifications, these make possible the development of a mathematical *proof* that when a given program is executed with a given "precondition" satisfied, the program is guaranteed to halt, with a desired "postcondition" guaranteed to be satisfied on termination It doesn't currently seem very likely *in either case* that these "uses" will be widely applicable --- Don't expect them to replace existing "informal methods". They also won't eliminate the need for all kinds of testing, since there will be some important requirements that one can't capture formally, and that there will always be a danger that - the initial formal specification was itself "incorrect" (didn't describe what a user really wanted) --- so that a guarantee that it matches a delivered implementation won't really give us what we want - there's an error in any *proof* of correctness that's been provided (and that the delivered system *won't* match the formal specification of requirements, even though a "proof" has been written) So: These are methods that *can* be useful --- especially when safety and reliability are critical, and only when applied to model requirements that *can* be specified easily using mathematics. You may be *required* to use them at some point in the future (especially if you end up working or contracting for an organization based in Europe instead of North America). However, it shouldn't be expected that they will "replace" the informal methods that we've discussed in this course up to this point.