Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Coad and Yourdon's Method
This material was briefly covered during lectures on March 14, 1997; this page describes Coad and Yourdon's method - particularly, the design evaluation criteria it provides - in more detail than in the lecture.
Coad and Yourdon's method for object-oriented design appeared shortly after their method for object-oriented analysis, and it seems clear that they're intended to be used together.
As described in the second chapter on their text (cited below), Coad and Yourdon derived their method by studying ``effective object-oriented designers, their designs, and their code'' and forming a model based on this - just as Yourdon and Constantine had studied effective designs in order to derive a method for structured design, much earlier. The result is a model that is more specific than other ``object-oriented design'' methods provide - Coad and Yourdon actually say which ``components'' a system should include. This might possibly make their method easier to use than other current methods - but, on the other hand, it seems possible that it could also limit the types of systems to which it could be applied.
The main reference for this material (and the book mentioned above) is the following.
P. Coad and E. Yourdon
Object-Oriented Design
Prentice Hall (Yourdon Press), 1991
This method is also discussed, more briefly, in recent editions of Pressman's Software Engineering: A Practitioner's Approach.
Coad and Yourdon propose a model, or architecture, for an object-oriented system that is partitioned ``horizontally'' into layers and ``vertically'' into components, as shown in the following figure (which approximates Figure 2.4, on page 26 of Coad and Yourdon's Object-Oriented Design).
Coad and Yourdon recommend use of the same set of layers for a design as they do for a class diagram in their object-oriented analysis:
As for object-oriented analysis (and the class diagram developed during it), the subject layer would show the subjects included in the system, the ``class & object'' layer would show the system's classes and objects, the structure layer would display the system's generalization-specialization and whole-part structures, the attribute layer would show attributes and instance connections, and, finally, the service layer would display services and message connections. Coad and Yourdon recommend the use of a CASE tool that would allow you to select which layers you wish to see, when viewing the model of the system that's being developed.
Coad and Yourdon recommend that an object-oriented system include a problem domain component, a human interaction component, a task management component, and a data management component. Each is described below.
The problem domain component includes the ``problem domain'' classes that were identified during object-oriented analysis. However, changes might be made in order to take advantage of ``reusable'' classes that are already available (and which may need to be added using generalization-specialization structures), as well as changes needed to improve performance, accommodate the programming language that will be used to implement the system (and which, for example, might not support the kind of inheritance that might be shown on the class diagram produced during object oriented analysis), and to connect the problem domain classes to other components (perhaps, most notably, the data management component).
Coad and Yourdon assume that a graphical user interface will be used for the system that's to be developed. Their ``human interaction'' component includes classes for windows and their components. You should be able to use (and customize) classes from a ``Graphical User Interface'' class library, in order to develop many of the classes needed for this component of your system.
Designing a human-computer interface is beyond the scope of Computer Science 333. However, it's the subject of Computer Science 481, which you can take after passing this course.
Graphical user interface libraries are currently not standardized (at all), so the details concerning them will vary from system to system. However, the Java user interface library is currently regarded as being well designed, and information about it is freely available. For example, there is a part of Javasoft's online tutorial that describes its components and how to use them. (In the event that it's difficult to reach the above tutorial: A list of the classes in this library is also available locally.)
Of course, there is also some information about the development of a ``human interaction'' component in Coad and Yourdon's book.
A task can be defined as a process, or a ``stream of activity.'' Certain kinds of systems require multiple tasks, including (but not limited to) systems that need to monitor or control multiple devices simultaneously, systems with certain kinds of user interfaces, and systems that can be used by multiple users, simultaneously.
Coad and Yourdon give a small set of properties or types of tasks that can be used to identify the services that their classes must provide, and provide a very simple ``template'' (or pattern) for a task management subsystem, consisting of a whole-part structure, showing that a ``Task Coordinator'' object has zero or more ``Task'' objects as components, and can send messages to them.
Again, you can Coad and Yourdon's book for additional details.
The data management component ``provides the infrastructure for the storage and retrieval of objects from a data management subsystem.'' It might provide an interface with a relational or object-oriented data base system.
Coad and Yourdon give a small amount of information for the design of this component, assuming that a ``flat file'' system will be used for storage, that a relational data base package will be used, and, finally, under the assumption that an object-oriented data base package will be used.
Coad and Yourdon present ``design criteria'' that can be used to look for and correct design problems, as was the case for criteria for structured designs.
The criteria for object-oriented designs seem less specific (or concrete than the criteria for structured designs, but they do seem to be worth noting.
Coupling describes the level of interaction between or among components of an object-oriented design, just as levels of coupling could be used to assess the interaction between components of a structured design. Coad and Yourdon mention two kinds of ``coupling'' that can be considered when assessing object-oriented designs: Interaction Coupling, and Inheritance Coupling.
Interaction Coupling refers to connections between classes due to message connections. Most references recommend that this be kept as simple (and limited) as possible; Coad and Yourdon go a bit further, by giving a more precise guideline (Object-Oriented Design, Section 8.2.1):
``In general, if a Message Connection involves more than three parameters, examine it to see if it can be simplified.''
As Coad and Yourdon note, it's certainly possible that message connections using more than three parameters can be useful, but this is a reasonable to limit to set when you're looking for connections that are overly complex.
Inheritance Coupling refers to the connection between generalizations and specializations in a generalization-specialization structure. Coad and Yourdon (and other references) warn that inheritance shouldn't be overused, send it can tend to weaken ``encapsulation of data'' (or ``information hiding''); nothing much more specific is provided than this warning.
Cohesion of components of an object-oriented design is similar to the concept of cohesion of modules in a structured design. As defined by Coad and Yourdon, cohesion is
the degree to which the elements of a portion of a design contribute to the carrying out of a single, well-defined purpose.
Coad and Yourdon mention three kinds of ``cohesion'' for object-oriented design: cohesion of services, classes, and generalization-specialization structures.
Again, quoting Coad and Yourdon, ``a service should carry out one, and only one, function.'' You can check this by seeing whether you can describe the service's purpose in a simple, short, sentence. You can also check the service's size; Coad and Yourdon note that services are frequently tiny - ``typically 3 to 5 statements in a language like Smalltalk.'' Note, though, that Smalltalk is a high level language (that's commonly used to ``prototype'' systems); the same service might include quite a few more statements, if implemented in C++.
Concerning cohesion of classes, Coad and Yourdon recommend that you look for extra (unused) attributes and services, or attributes or services that don't seem to reflect the responsibilities that have been identified for an object in the class.
It should also be possible to describe (the responsibilities for) the elements of a generalization-specialization structure in a reasonably short sentence. If this isn't possible - likely, because ``specializations'' that don't really fit have been grafted onto the structure - then this may be a sign that inheritance has been overused. (Another sign of this is might be the desire to ``eliminate'' some of the attributes or services inherited from a generalization in a specialization.)
Coad and Yourdon don't give any advice that's particularly specific about how to incorporate reusable components (beyond agreeing that it's a good idea to try to do so). They do note that it's possible to reuse more than code, during object-oriented development: design results, analysis results, etc., can be reused as well.
More information about reusable components (and how to take advantage of them, for object-oriented development) will be included in later pages.
In a section with this title, Coad and Yourdon introduce some new guidelines - and repeat some of the ones already given in the discussion of cohesion and coupling.
In order to ensure that the design is clear (readable, and easily understood), Coad and Yourdon recommend
Coad and Yourdon recommend that that deep generalization-specialization structures - with depth more than ``seven plus or minus two'' - should be avoided, (even) in a ``moderately'' large system with several hundred classes. Deeper structures can be difficult to understand and maintain, and can be a sign that inheritance is being misused.
In order to keep classes and objects simple, Coad and Yourdon recommend that you try to
As mentioned above (in the discussion of interaction coupling), Coad and Yourdon recommend that most services have no more than three parameters. As well, they recommend that services' names be chosen to be as simple, and understandable, as possible.
The advice to keep services short and simple (ideally, no more than five or six statements long in most cases, if implemented using Smalltalk) is repeated here.
Designs can change significantly early on, as designers consider (and reconsider) alternate approaches. However, the design should ''stabilize'' relatively quickly, with changes becoming progressively smaller as development proceeds. Take it as a sign of a poor design, if this isn't the case.
Coad and Yourdon recommend the kind of review or ``walkthrough'' of a design that has already described for CRC Modeling.
``Typical critical success factors include reusability, readability, and performance.'' Consider each of these (and any other ``critical success factors'' that have been identified for the current development project) when assessing your design.
According to Coad and Yourdon, two useful examples of ``design elegance'' for object-oriented design are the following.
Note the references to ``templates'' and ``patterns.'' Recently (after the work that's been discussed so far), quite a bit more work on ``design patterns'' has appeared. This will be the subject of the next set of notes.
Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Coad and Yourdon's Method