December 21, 2024
List Works of Artist use-case
Stage 1: Identification and specification of the use case
The NSR states:
"Given the unique name of an artist, the system will provide
a list of any works of art held by the gallery, including title, price
and code"
A specification is now written for the use case.
Given: The name of the artist
Goal: The relevant artworks' titles, prices and codes
Stage 2: Communication with the user interface
This is where we introduce an orchestrating class. This class has one
orchestrating instance (OI), referenced by the variable admin.
It acts as the intermediary between the user interface (UI) and the domain
model (the objects in the Quad system). As such, it is the object that
initiates each use case.
We can add this class to the class descriptions.
Class: QuadAdmin
Attributes: None
User Interface steps
At the start:
Given: A name of an artist, artistName.
Locate the instance, anArtist, of Artist, with the name artistName linked to admin via artists.
At the end:
Retrieve the required data from the relevant instances of Artwork.
Result: The relevant artworks' titles, prices and codes.
An implication of the requirement for the OI admin
to locate a particular instance of Artist, is
the need for QuadAdmin to have an association
between it and Artist. That is the purpose of
an association, for one object to locate another object by means of a
link between them. The course style is to name the association artists.
Furthermore, the artists association will be
navigated from QuadAdmin to Artist.
We can now add QuadAdmin and the artists
association, marked with a navigation arrow, to the initial structural
model.
The multiplicities of artists will be 1 at the QuadAdmin end and 0..* at the Artist end.
The class diagram can now be updated to include the artists association.
Before moving on to Stage 3, a few final words about associations. Associations will be implemented in a later stage of the development process. I mention this now because students are often left wondering how the system will achieve the location of objects. Put simply, the process involves the implementation of instance variables. For example, by defining an instance variable, artists, for the class QuadAdmin, it will be possible to implement the artists association, the collection of all links between admin and Artist instances. This instance variable can reference a dictionary where each instance of the class Association will have the artist's name as the key and a corresponding Artist object as the value. This is an example of why collection classes are so useful, enabling an object to store a record of any objects that it needs to locate in a system.
Stage 3: Walk-through and navigation of an association
It is important to realise that each use case may need revision after
completing other use cases.
Each step of the walk through is numbered and the interface steps are
labelled with UI.
At the start:
Given: A name of an artist, artistName.
- Locate the instance, anArtist, of Artist, with the name artistName linked to admin via artists. (UI)
- Get a collection, artworks, consisting of all Artwork instances that are linked to anArtist via creates.
- Retrieve the required data from the instances of Artwork. (UI)
Result: The relevant artworks' titles, prices and codes.
I think an explanation of the walkthrough may help.
Step 1 has located the Artist instance with
the given name. This does not require admin
to send a message to anArtist. The OI admin
will hold, or encapsulate, a reference to anArtist.
Remember what I said about the use of a collection class (dictionary)
that implements this record. Once it has the artist's name it can get
the Artist object from within itself. It does
not have to send a message to anArtist to achieve
this.
The structural model shows that Artist has a creates association with Artwork. The Artist object will have at least one, but possibly several links with instances of Artwork. To record these links, anArtist will need to hold a collection of Artwork instances. Put another way, creates must be navigated from Artist to Artwork.
The OI admin can send a message to anArtist to get this collection (Step 2). Once admin has the collection it can iterate through each of the Artwork objects sending each object a series of messages to get the title, price and code of each Artwork object.
Stage 4: Sequence diagram and protocol responsibilities
A sequence diagram illustrates the messages sent between objects as described in the walkthrough.
You need to make sure that only instances, and not classes, are illustrated
in the sequence diagram. The variables used in the walkthrough (admin,
anArtist, anArtwork)
are underlined to mark them as instances. Messages are numbered, corresponding
with the walkthrough step, and the arrows are given solid lines. The use
of * denotes them as iteration messages. If
an argument is being passed into the message, as with listArtworksOf,
the argument is placed in brackets e.g. (artistName).
If more than one argument was used then the message would take the form
msg(arg1,arg2,arg3...)
This is UML notation,
not Smalltalk, which of course would be written
listOfArtworks: artistName
Message answers are given arrows with dashed lines. They are only illustrated if the walkthrough has determined a need for them, as is the case here.
Once the diagram is complete we can turn to the class descriptions and add any protocol responsibilities that we have deemed necessary. Assuming that the List Artworks of Artist is use case L, each responsibility is labelled with the use case identifier and the number of the walkthrough step.
Class: QuadAdmin
Protocol:
listArtworksOf(artistName) "Handles the List Artworks
of Artist use case.[L (1 2 3)]"
Class: Artist
Protocol:
getArtworks "Answer a collection of artworks created
by the artist. [L (2)]"
Class: Artwork
Protocol:
getTitle "Answer the title of the artwork. [L(3)]"
getPrice "Answer the price of the artwork. [L(3)]"
getCode "Answer the code of the artwork. [L(3)]"
Next page » Conclusion
Previous page « Dynamic modelling
⇑ Up to top of page