December 21, 2024

Initial Structural Model - Deriving Classes

 

Initially we are looking for suitable classes for the application. Students usually make a good attempt at this, but some make the mistake of writing a class as plural (Artists) rather than singular (Artist).

Classes will fall into one of four categories.

  1. Tangible objects - can you touch it? e.g. Painting
  2. Roles - can you act it? e.g. Artist
  3. Events - can you take part in it? e.g. Exhibition
  4. Organizational units - is it a team, group etc? e.g. BuyerQueue

With this in mind you can work through the NSR selecting suitable nouns from the text. The analysis and design process is, I repeat, iterative in nature; you are unlikely to deduce all the classes on the first sweep through. As you will see, I have chosen to use a class that is not at first apparent from reading the NSR.

Generalisation relationships

You will need to detect any generalisation relationships. For example, "There are two kinds of exhibition. Solo exhibitions show works of art created by just one artist. Group exhibitions show the work of several artists." should lead one to think that Exhibition, SoloExhibition and GroupExhibition will be likely candidates for this relationship. Furthermore, Exhibition is a strong candidate for being selected as an abstract class. This is illustrated by the use of italics in the class diagram, Exhibition, together with a label, {abstract}. The more generalised class in the relationship is not always abstract. If there is a need, determined from the NSR, for the system to record instances of this class, it should be left as a concrete class.

Attributes

The distinction between a class and its attributes is not always apparent. An attribute is a property of a class. It is something that belongs to the class rather than something that you would wish to model as a class itself.

It might be tempting to select both Print and Edition as suitable classes. I decided to use just Print, as I think of editionSize and number as properties of the print. But there is a case for thinking that Edition is an example of an organizational unit, with the class having a size attribute. I will stick with Print, but I might change my mind at some later stage.

Another case for consideration is the selection of name as an attribute of Buyer, similarly for Artist. Both are properties of each class. Later on, in the design phase, you might decide to create another class, Name. This class will have attributes, firstName and secondName. Instance variables, held by instances of Buyer and Artist subclasses, will reference Name objects. But that kind of refinement can wait.

You should, after looking at collection classes, be familiar with programming queues. Typically the implementation of a queue will require it to have some attributes. But that is going to be left until the design stage where reuse of the class library would come into consideration. For the moment, the NSR makes only one reference to an attribute, the unique code. The NSR also states:
"The gallery assigns each buyer a priority, to determine his or her position in a queue. This priority may change with time."
How prioritising is achieved will be left to later when design decisions are made. The NSR makes it clear that the system will have to model this behaviour. All we can do for now is to record that Buyer requires a priority attribute.

As a general rule:

  1. If it reads as a thing (tangible/role/event/organization), think class.
  2. If it reads as a property of the thing, think attribute.

 

Next page » Associations

Previous page « Analysis and the initial structural model

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

⇑ Up to top of page