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.
|Dog Owner||cares for||Dog|
|Dog||is in care of||Dog Owner|
Types of Object Relationships.
Unconditional forms of relationship are called so because every instance of both objects is required to participate in 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.
If they are contradicting each other then model is erroneous.
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.
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 attribute: Owner name - can be reference to Home Owner.
Inheritance is an 'is-a' relation.
The UML graphical representation of a Generalization is a hollow triangle shape on the superclass end of the line (or tree of lines) that connects it to one or more subtypes.
The superclass (base class) in the generalization relationship is also known as the 'parent', superclass, base class, or base type.
The subtype in the specialization relationship is also known as the 'child', subclass, derived class, derived type, inheriting class, or inheriting type.
For example, 'an oak is a type of tree', 'an automobile is a type of vehicle'.
A realization relationship is a relationship between two model elements, in which one model element (the client) realizes (implements) the behavior that the other model element.
The UML graphical representation of a Realization is a hollow triangle shape on the interface end of the dashed line (or tree of lines) that connects it to one or more implementers. A plain arrow head is used on the interface end of the dashed line that connects it to its users.
A dependency is a semantic connection between dependent and independent model elements.
It exists between two elements if changes to the definition of one element (the server or target) may cause changes to the other (the client or source).
This association is uni-directional.
An association represents a family of links.
Aggregation is a variant of the 'has a' association relationship; aggregation is more specific than association. It is an association that represents a part-whole or part-of relationship.
Example: a Professor 'has a' class to teach.
Aggregation can occur when a class is a collection or container of other classes, but the contained classes do not have a strong lifecycle dependency on the container. The contents of the container still exist when the container is destroyed.
In UML, it is graphically represented as a hollow diamond shape on the containing class with a single line that connects it to the contained class.
Example: Library has Students and books. Here the student can exist without library, the relation between student and library is aggregation.
When attempting to represent real-world whole-part relationships, e.g. an engine is a part of a car.
The UML graphical representation of a composition relationship shows composition as a filled diamond shape on the containing class end of the lines that connect contained class(es) to the containing class.
Differences between Composition and Aggregation.
Aggregation relationship is often 'catalog' containment to distinguish it from composition's 'physical' containment.
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 & other UML parts.
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: , , 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.