Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Introduction to Object-Oriented Design
This material was covered during lectures on March 14, 1997.
The material on ``object-oriented design'' presented in CPSC 333 is taken from several different references. However, an introduction to the topic, and brief descriptions of much of what will be covered, can be found in the chapters on ``Object-Oriented Software Engineering'' in
R. S. Pressman
Software Engineering: A Practitioner's Approach
Fourth Edition, McGraw Hill, 1997
Note that, presently, only the third edition of this book is available in the library; unfortunately, much of the material on object-oriented software engineering is missing from the earlier edition (or is now a bit out-of-date).
Object-oriented design is still changing pretty rapidly. Rapidly than presenting one ``mature'' method (like structured design) in detail, brief descriptions will be given for several newer ``object-oriented'' methods in these notes.
The methods and details will have changed by the time CPSC 333 students have graduated, but it's to be hoped that (some of) the general ideas will still be recognizable.
Object-oriented design methods that are concerned with individual projects (more than the development of reusable components or artifacts) presently seem to have at least a few things in common.
They are continuations of methods for object-oriented analysis.
In some cases, object-oriented analysis and design methods are actually ``coupled together,'' in the sense that it's assumed that a specific ``analysis'' method will have been used, before a specific ``object-oriented design'' method is applied (for example, I believe that this is probably true for Coad and Yourdon's methods).
More generally, methods for object-oriented design try to use the same notation as has been used in object-oriented analysis - so it isn't necessary to include a kind of ``translation process'' (as is needed, for example, at the beginning of structured design, in order to convert a set of data flow diagrams into a structure chart).
One consequence of this is that the line between object-oriented ``analysis'' and ``design'' is even more ``fuzzy'' than the line between structured ``analysis'' and ``design:'' It's often not clear at all when ``analysis'' has ended and ``design'' has begun.
A class diagram produced during object-oriented design will include the ``problem domain'' classes that were identified during object-oriented analysis. However, the class diagram produced during object-oriented design will add ``implementation'' classes - that may represent a part of the system's human-computer interface, interaction with a data base, data structures, or other components of a design that don't correspond (directly) to elements of the ``problem domain.''
``Architectural design'' also includes a partitioning of the system's classes into subsystems. Subsystems should be chosen so that communication between subsystems is minimal, and passes through a simple and well-defined ``interface'' - so that subsystems can be developed independently and (one hopes) combined together, later on, without difficulty.
The methods to be discussed are relatively easy to describe and appear to be (relatively) widely used. Two more methods that you should be aware of are described in the following.
Grady Booch
Object Oriented Design with Applications
Benjamin/Cummings, 1991
James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen
Object-Oriented Modeling and Design
Prentice Hall, 1991
Each includes a description of an object-oriented design method, along with applications of the method to several examples.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Introduction to Object-Oriented Design