CPSC 333 --- Lecture 27 --- Wednesday, March 20, 1996 In order to take advantage of the features that object-oriented programming languages provide, analysis and design methods that are better suited to these than "structured" techniques should be used... Object-Oriented Analysis The reference I'm currently using for this is: Peter Coad and Edward Yourdon Object-Oriented Analysis. Second Edition. Prentice-Hall, 1991. Neither object-oriented analysis nor (especially) object-oriented design are particularly "stable": The methods that these terms describe might change drastically in the next few years. As well, it isn't difficult to find different descriptions of "object-oriented" techniques, now, that are quite different from the ones that are being described in lectures. One or two of these can be found by looking at the books that have been put on reserve for this course. Note: The first and second editions of Coad and Yourdon's book were quite different. The *first* edition of the book is used heavily as a reference in the chapter on "Object-Oriented Analysis" in the current edition of Pressman's "Practitioner's Guide." ------ As the following description should suggest, "object-oriented analysis" borrows heavily from "Information Modeling," the technique I described early in the course for developing and using entity-relationship diagrams. Components of an Object-Oriented Analysis & Specification: 1a) Object: An abstraction of something *in the problem domain,* reflecting capabilities of the system to *keep information about it,* *interact with it,* or both; an *encapsulation* of attribute values and their exclusive services. 1b) Class: A description of one or more objects *with a uniform set of attributes and services,* including a description of how to create new objects in the class. This is Coad and Yourdon's definition of class. It is at least plausible that this definition should be extended, to specify that a class must also provide "a description of how to destroy existing objects in it." Classes and Objects form the "primary part" of an object-oriented model for a system. In general, a singular noun or noun-phrase, or adjective-and-noun, should be used to name a class. Things in the problem domain that might become "classes": - Structures (or "Assemblies") - Other Systems, that the system must interact with - Other Devices, that the system must interact with - Things or Events that must be remembered by the system - Roles Played, by people that the system must interact with or remember information about - Operational Procedures, if these must be maintained by the system - Organizational Units Note that, in a specification for the same system that's developed using "structured" techniques, some of these might correspond to entities (or other components) of the system's ERDs; others might correspond to terminators on the system's context diagram. One way to find a list of candidate classes for a system is to choose the classes in the specification of a similar system, if this is available. A way to find a list of candidate classes from a *problem statement* (like the ones we started from at the beginning of the course, to form ERDs) is to perform a "grammatical parse," extremely similar to the kind that was used to find candidate "entities" for ERDs. Once a list of candidates has been obtained, this can be "pruned" by asking whether the candidates have the following properties. - "Needed Remembrance:" Does the system to need to *remember* anything about the objects that would belong to the candidate class? - "Needed Behaviour:" Would the objects in the candidate class provide some behaviour (processing --- that is, functions or *services*) required by the system? If the answer for the first question if, "Yes" --- so that the candidate class has "attributes," then the answer for the second question must be "Yes" too: There would need to be ways (using the class's functions) to set, and report, values of these attributes. It isn't clear at all that the converse is true: A class might provide essential services without having attributes (and, such a class *should* be included). Therefore, it can be argued that the second question is a more important, or "fundamental," one for this method. On the other hand, if the answer for the *first* question is "Yes" then the second question doesn't need to be asked. - "Multiple Attributes" --- *usually*. If a class only has one attribute, then you should ask whether it should really be an "attribute" for some other class that's already been included (or that should be included instead). - "Potentially More Than One Object in the Class" --- if a class can never have more than one object --- especially if that object never changes --- you should ask whether it needs to be shown as an "object" at all. - "Common (or, "Always Applicable") Attributes: It should be the case that the *same* set of attributes is defined for every object in the class, and that there *should be* a well-defined value for each of these attributes corresponding to each object ... Note that these three properties are quite similar to things that were considered at the same point during "Information Modeling." The last one is new: - "Common (or "Always Applicable") Services: It should be the case that the *same* set of services (functions) are provided by every object in the candidate class: Calling sequences (and implementations) should be the same, for a given function, for each object in the class. If either of the last two conditions is broken then this is evidence that the "objects" should belong to *several related* classes that are connected by an "generalization-specialization" (inheritance) structure (if they have any attributes or services in common at all). For an example of how a grammatical parse might be used in "object-oriented analysis," see Section 8.1 of Pressman's "Practitioner's Guide." In the lecture, a grammatical parse was conducted on the problem statement for the "Student Information System" that was also used at the beginning of term... I won't be including this in these notes. The top of the three regions enclosed by the class symbol contains the name of the class. The bottom two will (eventually) be used to list names of the class's attributes and services. Notation: Tall, Narrow Rectangles with rounded corners, containing three regions (separated using horizontal lines) are used to represent classes, including virtual classes (which have no objects of their own). A second shaded border is added outside this, to represent "a class and its objects". See Chapter 3 of Coad and Yourdon's book on "Object-Oriented Analysis" for more details. More Components... 2) Structures --- Important *connections* between classes, or between objects Coad and Yourdon describe two kinds of structures that might reflect aspects of the problem to be modeled (so that they should be considered this early on in development): a) Generalization-Specialization Structures --- Inheritance: Class A is a generalization of Class B --- and (therefore) Class B is a specialization of Class A, if - B has all the attributes that A has (and, possibly, one or more additional ones too) - B has all the services that A has (and, possibly one or more additional ones too) Class B should have at least one attribute or service that A doesn't --- or (maybe) a different implementation of one or more of the existing services. Otherwise, Class A and Class B probably shouldn't be two "distinct" classes at all, but should be combined. Use "generalization-specialization" structures to denote "is-a" (or, "is-a-kind-of") relations between things in the problem domain: For example, an automobile "is-a" (or, "is-a-kind-of") motor vehicle --- so, if it's necessary to include classes with names "Automobile" and "Motor Vehicle" then the class "Automobile" is probably a specialization of the class "Motor Vehicle." "Generalization-Specialization" structures represent connections between *classes*. b) Whole-Part Structures --- Components of Assemblies: These occur if objects of one class ("Class A") are "assemblies" of some sort, and objects in another class ("Class B") are parts, or components, of these assemblies: For example, there might be a whole-part connection between (Objects in) a class called "Aircraft" and (objects in) a class called "Engine" (Objects in) a class called "Academic Department" and (objects in) a class called "Faculty Member" (Objects in) a class called "Chapter" and (objects in) a class called "Paragraph," perhaps in a sophisticated word processing system (Objects in) a class called "Book" and (objects in) a class called "Paragraph" Whole-Part Structures can be thought of as connecting *objects*. A whole-part connection is always shown between a *pair* of classes. Coad and Yourdon include a way (in their notation) to show the "multiplicity" for the connection. That is, if a whole-part structure is shown in which (an assembly) A is connected to (a component) B then two nonnegative integers a, b are drawn near the connection to A, and another two nonnegative integers c, d are drawn near the connection to B. The value "a" must be less than or equal to "b", and "c" must be less than or equal to "d". This tells us that each object in A must have at least a, and at most b, objects in class B as components, and that each object in class B must be a component of at least c, and at most d, objects in class A. See Chapter 4 of Coad and Yourdon's book for more details, including the *notation* they use to depict both kinds of structure.