Monday, October 20, 2008

Section 1.3: Class Relationships

Requirement: Describe, compare, and contrast class compositions, and associations (including multiplicity: (one-to-one, one-to-many, and many-to-many), and association navigation.


Composition:

We are going to start with a simple example, an instance of Point class may be a part of a polygon or may be the center of a circle, but it cannot be both. (1.3.1) Although a class may be a component of many other classes, any instance of that class must be a component of only one owner (this no sharing rule is the key to composition). (1.3.2) In a composition relationship, data usually flows in only one direction (that is from the whole classifier or owner to the part classifier or the owned) (ex: if you remove the Polygon object, the owned Point objects are also removed).


Association:

(1.3.3) Association is a way to notate a property (ex: you can think of a property as a field in a class). (1.3.4) The name of an association describes the nature of the relationship between 2 classes and should be a name or a verb. (1.3.5) The multiplicity of a property is an indication of how many objects may fill the property. (1.3.6) The most common multiplicities are:
  1. 1 (ex: an order must have exactly one customer).
  2. 0..1 (ex: a customer may or may not have a single sales rep.).
  3. * (ex: a customer need not place an order and there is no upper limit on the number of orders that the customer can place).

(1.3.7) More generally, multiplicities are defined with a lower bound (which may be any positive integer or zero) and an upper bound (which may be any positive integer or *). (1.3.8) There are various terms that refer to multiplicity:

  1. Optional implies a lower bound of 0.
  2. Mandatory implies a lower bound of 1 and possibly more.
  3. Single-Valued implies an upper bound of 1.
  4. Multivalued implies an upper bound of more than 1: usually *.

(1.3.9) The default multiplicity of an attribute is 1.


Association Navigation:

(1.3.10) Associations are either unidirectional or bidirectional. (1.3.11) Unidirectional associations are navigable in only 1 direction (ex: an order has a property called arrivalDate but not vice versa). (1.3.12) A bidirectional association is a pair of properties that are linked together as inverses (ex: the Car class has a property called owner of type Person and the Person class has a property called cars of type Car).

(Approximately all of the material written here is taken from the references mentioned in the first post. I don't claim to have authored any part of this material . I just compile my own notes from one or many of these references).

No comments: