March 19, 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.

artists association between QuadAdmin, multiplicity 1, and Artist, multiplicity 0..*. Navigation arrow pointing to Artist.

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.

  1. Locate the instance, anArtist, of Artist, with the name artistName linked to admin via artists. (UI)
  2. Get a collection, artworks, consisting of all Artwork instances that are linked to anArtist via creates.
  3. 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.

sequence diagram

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