8/28/14

Object Relationships Modelling & Analysis.

In Context of Object Oriented Analysis (OOA):

Objects & Relationships.

The real world things that participate in relationship must be abstracted as objects.

Every relationship in the model is given a pair of names that describe the relationship from the perspective of each of the participating objects.


Object Relationship Object
Dog Owner cares for Dog
Dog is in care of Dog Owner



Types of Object Relationships.

'Unconditional' relationships.

Unconditional forms of relationship are called so because every instance of both objects is required to participate in relationship.

1-1 relationship.



A one-to-one relationship exists when a single instance of an object is associated with a single instance of another object.

1-to-many relationship.



A one-to-many relationship exists when a single instance of an object is associated with one or more instances of another, and each instance of the second object is associated with just one instance of the first.

many-to-many relationship.



A many-to-many relationship exists when a single instance of an obect is associated with one or more instances of another, and each instance of the second object is associated with one or more instances of the first.

'Conditional' forms & Cardinality.

In a conditional relationship there can be instances of objects that not participate. Relationship can be conditional on either side, or on both sides (biconditional relationship).

Cardinality of a side of relation is number of instances of objects on that side of that relation.

Cardinality options are: 1, 0..1, 0..n, 1..n, n.

Cardinality can be noted on either or on both sides of a relationship model.



Cardinality & Arrow Notation should not be a condtradiction.

If they are contradicting each other then model is erroneous.


Object Attributes.



a 'Home' object with four attributes named appropriately.


An attribute is an abstraction of a single characteristic possessed by all entities that were abstracted as objects.

This abstraction can be named & put in an object.

When implemented and run as a part of a program, each of attributes has a Data Type & a Concrete Value that can change during object's life.

Types of Attributes:

- Descriptive Attributes: provide facts intrisinc to each instance of the object.
- Naming Attributes: identifiers, instance labels.
- Referential Attributes: used to tie an instance of one object to an instance of another.


Relationship Objects.

Relationships can be modelled as objects, and have attribute(-s).

Contrary to opinion of many, either 1-to-1, either 1-to-many, or many-to-many relationship can be separated from objects participating in relationship and modelled as an object with attributes.

in case of 1-1 relation:

for example: where to put 'marriage contract' attribute?

- in 'wife' object?
- in 'husband' object?
- in both?
- or associate it with 'marriage relation' object that is associated both with husband and wife?

putting 'marriage contract' in both objects would cause data redundancy and possibility for inconsistent data; of course 'marriage relation' object should be Secured appriopriately.


in case of 1-to-many relation:

for example: a 'dog, dog-owner' relation, relations can be modelled as objects as well.

each pair: (dog, dog owner) is associated with relation object that applies to this pair.

in theory only part of dogs owned by an owner might be health-insured, others: 'not yet'.


in case of many-to-many relation:

for example: a 'house, house owner' relation, relations can be modelled as objects as well.

each pair: (house, house owner) is associated with relation object that applies to this pair.

in theory a house might have multiple owners, and any/each of owners might own multiple houses.



Ownership relation attributes: Address, Unit at address - can be references to Home.
Ownership relation attribute: Owner name - can be reference to Home Owner.


Graphical Representation of a Model.

There are many graphical notations, for example: Shlaer-Mellor, UML, ...

Above images were based on Shlaer-Mellor representation, enriched with Cardinality which comes from UML as 'far' as i know.


Analysis.

Model is the Basic Tool for Analysis.

Model can be examined, analysed & modified to simplify & abstract, then whole system can be reimplemented if needed or neccessary.


Source: [34], [36], insight.

See also, if You wish: A Quick Method for Mid-High Complexity Software Design, How to create software model using 3D Art model?, 'Talking Objects' Solutions, Object Oriented Analysis, Design & Modelling.

No comments:

Post a Comment