CPSC 333 --- Lecture 28 --- Friday, March 22, 1996

Components of an Object-Oriented Analysis & Specification
(Continued From Lecture 27):

3) Attributes --- Remembered Data

These are similar to (but not identical to) attributes of entities in
ERDs. Each attribute should be associated with one or more (usually,
*exactly* one) class in the specification --- namely, the highest or
"most general" in a generalization-specialization structure that
includes this attribute.

Every object of this class (and all the specializations of this class)
must have a well-defined value for this attribute at all times. (Of,
course, this value can be changed over time --- at least, it can if
the attribute isn't part of a "key".)

Coad and Yourdon recommend that you try to ensure that each attribute
corresponds to an "atomic concept" --- either an elementary data type
(as was the case for attributes of entities in ERDs) or a "tightly
related group of values." For example (of the latter), they would
allow "legal name" to be considered to be a single attribute of a
class, even though it almost certainly has two or three components: a
first name, (optional) middle initial, and last name. Since the
components are likely (almost) always treated as a group it seems
reasonable to give the whole group the name "legal name" and consider
it to be *one* attribute instead of a set of three. Similarly, one
might consider "date" to be a single attribute, even though it likely
includes three components --- day of month, month, and year; "time of
day" to be an attribute, with components "second," "minute," "hour"
and (maybe) "AM/PM", etc.

Coad and Yourdon *don't* consider "normalization of data" to be
important to object-oriented analysis --- so, for example, they don't
say that you should try hard to exclude "redundant" attributes (which
are computable from others) at this stage. They consider the decision
of whether to "normalize" data to be a *design* decision --- so it
shouldn't be considered during analysis.

Similarly, they recommend that the selection of a way to *identify*
(or distinguish among) the objects of the same class to be a design or
implementation decision --- so, they defer the decision of primary
keys (or, even the decision of whether to use sets of attributes ---
keys --- at all, instead of pointers, etc, as identifiers) to be
something that can wait until later.

4) Instance Connections

These resemble relationships in ERDs in the sense that they are drawn
as connecting classes on the diagram but represent connections that
might (or might not) exist between objects in these classes --- and
that represent information that must be maintained in order for the
system to function.

For example, in an object-oriented model for the "Student Information
System," you might include classes called "Student" and "Section of
Course." You might represent registrations of students in course
sections as a (set of) instance connection(s) between these classes.

Coad and Yourdon show instance connections by drawing lines (usually
horizontal) between the classes whose objects can be connected. They
show a bit more information, too. In particular, if Class A is
connected to Class B then a pair of nonnegative integers a, b is shown
at the end of the connection near A, and another pair of nonnegative
integers c, d is shown at the end near B. The number "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 class A must be connected to at least a
objects in class B via this (kind of) instance connection, and can be
connected to at most b objects in Class B --- while each object in
class B must be connected to at least c objects in Class A and can be
connected to at most d objects in Class A.

Coad and Yourdon allow multiple instance connections between the same
pair of classes --- and they add labels to the connections (to provide
distinct names for them) then this happens; labels don't seem to be
required when there's only one instance connection between a pair of
classes (since the pair of classes being connected is enough to
identify the connection in this case).

It seems that instance connections could be used to represent the same
things (and, perhaps, more) that connections in "whole-part"
structures could. Quoting Coad and Yourdon (page 128)...

  "... The difference between Whole-Part Structure and Instance
   Connections is the underlying semantic strength. Whole-and-part
   is one of the basic methods of organization that pervade all
   human thinking. This is much stronger in meaning than a mere
   mapping between Objects in a Problem Domain."

In order to try to reflect this, I chose to use a "Whole-Part
Structure" to connect "Course" and "Course Section," but just used an
instance connection between "Student" and "Course Section" (to
represent registrations of students in course sections) in the
object-oriented model that was developed for the "Student Registration
System" during this lecture. (This model might --- but probably won't
--- be made available. Two running examples are used in Coad and
Yourdon's book, and these should be used as examples instead.)

See Chapter 6 of Coad and Yourdon's book for more information about
attributes and instance connections.

5) Services

According to Coad and Yourdon, a service represents "a specific
behaviour that an object is responsible for exhibiting."

The task of identifying an object's *services* is coupled with
identification of an object's *states*. A *state* generally
corresponds to a combination of values that the object's attributes
might have --- or a particular relationship among the attribute's
values. (Perhaps) more importantly: The particular state that an
object is in influences the way in which one or more of the object's
services are performed. Usually, each object in a class can be in one
of a finite, *fixed,* number of states at any time. Coad and Yourdon
include a "state diagram," which appears to be a simplification of a
"state-transition diagram," as a way to specify the states for a given
class and the transitions from one state to another that are allowed.

Coad and Yourdon identify several kinds of "algorithmically-simple"
services:

 - Create: creates and initializes a new object in a class (a
    "service" that must be provided by a *class*)

 - Connect: connects an object with another (creates an "instance
     connection"); there should be a corresponding "Disconnect"
     service, too

 - Access: gets or sets the attribute values of an object

 - Release: (Possibly another service provided by the *class*
    instead of the *object*): releases (disconnects and deletes)
    an object in the class.

... and, they identify two kinds of "algorithmically-complex" services
that one might expect to find:

  - Calculate: calculates a result from the attribute values for
     the object

  - Monitor: monitors an external system or device. This deals
     with external system inputs and outputs, or with device
     data acquisition and control. It may need some companion
     services, such as "initialize" or "terminate"

Coad and Yourdon introduce a diagram called a "service chart" to
specify each (algorithmically-complex) service; this resembles a
simplified flow chart.

6) Message Connections: These are shown as connecting classes
    (but should probably be thought of as connecting objects in
    the classes). They model the "processing dependency" of an
    object --- in the sense that you should think of their being
    a message connection between object x and object y if x calls
    (or "uses") one of the services that y provides, or vice-versa.

See Chapter 7 of Coad and Yourdon for more details about services,
object states, and message connections.

7) Subjects

Coad and Yourdon note that, for the object-oriented systems they're
familiar with (probably, but not definitely, business-processing
systems of a moderate size),

   - one can expect to find approximately 35 classes in the object-
     oriented model for an "average" system

   - one might find 110 classes if the system is "large"

This is far too many classes that can be shown comfortably on a single
diagram (at least, on an 8 1/2" x 11" page --- or even an 11" x 17"
page) --- and it's too many if the "7 plus-or-minus 2" rule" is to be
taken seriously.

One way to deal with this would be to use the approach that has been
taken with data flow diagrams (as described in this course) --- to
replace a single diagram with a leveled set --- using lots of diagram
that are each small and simple.

An alternative approach (which has also been used in "structured"
methods, using data flow diagrams, that are a bit different from the
ones described in CPSC 333) is to use a small number of large diagrams
--- that each have lots of things drawn on them --- but that *cluster*
or *organize* the things shown on the diagram, in order to guide the
reader who is trying to understand what the diagram represents. This
is the approach used by Coad and Yourdon to show lots of classes for a
single model.

In particular, Coad and Yourdon define *subjects* to be sets of
classes. The "subjects" for a system "partition" the classes, in the
sense that each class is contained in exactly one subject. In order to
define the "structures," Coad and Yourdon say that you should

 - put each class that's at the top of a generalization-specialization
   or whole-part structure into a "subject" of its own

and then

 - try to allocate the remaining classes to the structures that have
   been formed (if necessary, adding a few more) --- so that, in the
   end, you don't have "too many" structures (ideally, again, not too
   many more than 7) and with whole-part connections,
   generalization-specialization connections, instance-connections, and
   message-connections that connect classes in different subjects
   *minimized*

If your system is unusually small, you might not want to bother with
"subjects" at all. If your system is unusually *large* then you might
want to form subjects earlier than these notes suggest --- Coad and
Yourdon say, possibly after classes, generalization-specialization and
whole-part structures have been identified, but before attributes,
instance connections, services, object states, and message connections
have been specified. Then, the "subjects" can be used to split the job
of specifying the rest of the system up (with a different team of
"specifiers" each working on a one or more different subjects, more or
less independently).

See Chapter 5 of Coad and Yourdon's book for more information about
"subjects."

Next: "Object-Oriented Design"...