December 21, 2024
Initial Structural Model - Deriving Associations
The next step is to look for associations between any of the selected classes.
Again the NSR should supply you with the clues. This time we need to look
for verbs and prepositions. For example, "Some artists, but not all,
are given an exhibition", or, "buyers are placed in a queue".
Once this part of the textual analysis is done you can begin to construct
a class diagram illustrating the classes and any associations between them.
(Download this Word document - Drawing with Word
381Kb)
Links
M206 emphasises the difference between an association and a link. An association exists between two classes. A link exists between two instances of these classes.
It is important to use the correct terminology if asked to demonstrate an understanding of the nature of an association. It must be described in terms of classes and instances of classes. For example:
- An instance of Order is linked via places to one instance of Buyer
- An instance of Buyer may be linked via places to none, one or many instances of Order
Omitting one of these points would only partially describe the association.
You need both. Furthermore, it would be incorrect to write:
There is a places association between an instance of
Order and one instance of Buyer.
N.B. Do not include such a description in the initial structural model. This understanding can be inferred from the association and its multiplicities illustrated in the class diagram.
Derived associations
The course methodology requires you to include any association explicitly mentioned in the NSR in the class diagram. This may result in the inclusion of derived associations and they must be marked as such (e.g. /attends).
The attends association between Buyer and Exhibition is mentioned in the NSR. "All buyers are invited attend to every exhibition. Buyers may or may not attend exhibitions." It should be apparent that the system can derive an association between Exhibition and Buyer from the associations purchasesVia (between Buyer and Sale) and has (between Sale and Exhibition). In other words, if you have a record of a sale from an exhibition that records the buyer, it is clear that the buyer attended the exhibition.
Some data modelling processes would describe attends as redundant and it would not be included, but this methodology demands the inclusion of attends for the initial model. It will be removed later.
I have included two other derived associations, containsWorkBy and isGiven. These can both be derived from creates, isPresentedFor and presents associations. In plain English, if a work of art is exhibited, and the system is using Showing to record this fact, then there is a connection between the work and the exhibition. But since the work records the artist who created it, a link can be deduced between the artist and the same exhibition. That's the English explanation; you may be asked to demonstrate an understanding of a derived association by use of a very different language, which bears only a passing resemblance to English. For example:
Derivation of isGiven
If p is an instance of Painting, then p is linked via creates to exactly one instance a of Artist. The instance of SoloExhibition se linked to a via isGiven is the instance that is linked to p via presents and isPresentedFor.
You don't need to give this in the associated text; marking the association with / is enough.
Multiplicities
The next step is to label all the multiplicities at each end of every association. Again careful reading of the NSR will be necessary. "... some buyers place an order for a work of art prior its creation. ... Some buyers may have placed several orders...".
Using the example above and putting it in plain English, a buyer may place no orders, or possibly just one or many. UML notation results in 0..* being written at the Order end of the association. However, an order is placed by just one buyer. This necessitates the writing of 1 at the Buyer end of the places association.
Resolving many-to-many associations
Sometimes a many-to-many association can be inferred from the NSR. This will be denoted as 0..* or 1..* at either end of the association. This might be resolved by the introduction of a third class and decomposing the association into two one-to-many associations. The question you must ask yourself is this; do the requirements indicate a need to record data for a class that could be introduced?
For example, a placedIn association can be inferred between Buyer and BuyerQueue. It will be denoted as 0..* at the Buyer end (in plain English, a queue of buyers may have one, two or several buyers, or it may be empty). The association will also be denoted as 0..* at the BuyerQueue end (a buyer may have been placed in zero, one or many queues).
But do we need another class, Placement say, which records the event of a buyer being placed in a queue? The answer is no, because the NSR does not call for it. Similarly there is no requirement to store data about buyers attending exhibitions. Therefore we do not need an Attendance class between Buyer and Exhibition.
There is, however, one place where an "intersection" class is required. On first reading you would most likely infer an association, shows, between Artwork and Exhibition. It would be 1..* at the Artwork end ("The number of works shown in an exhibition will vary, but may be as little as one."). The association will be denoted as 0..* at the Exhibition end (a work of art may not be shown, or it may be shown any of number of times). The NSR states, "Record the showing of all works of art, including the title and date of the exhibition and the identifying code of the artwork". This indicates a need for a class, Showing, since the event of showing is significant for the application area.
Next page » What not to include in the initial structural model
Previous page « Deriving Classes -The initial structural model
⇑ Up to top of page