Structural modeling: CRC cards, class and object diagrams

The structural model shows what data the system holds and how that data is connected. The use case answers “what is being done”, the structural model answers “what is it done with”. The exam question of this week is almost always the same: a scenario is given and you are asked to draw a class diagram with the classes, attributes, relationships and multiplicities. Marks are lost by writing the multiplicity at the wrong end and by confusing aggregation with composition.

Golden rules:

1. Noun → class or attribute, verb → operation or relationship.
2. Multiplicity is read from the opposite end. The answer to “how many B does one A have?” is written at the B end.
3. The diamond is on the whole side. Hollow: the part is independent (aggregation). Filled: the part dies with the whole (composition).
4. The triangle is at the superclass. The arrow leaves the subclass.

Elements of the structural model

At the analysis stage the model describes the business world (the problem domain): there is no database table, Java type or getter/setter detail yet.

Finding classes

Textual analysis

Look at the words in the use case descriptions:

Other ways: brainstorming (the team lists candidate classes), common object lists (physical things, events, roles, places), patterns (ready-made forms like order-order line, reservation).

CRC cards

A CRC (Class-Responsibility-Collaboration) card shows, on one card per class, the responsibilities and the classes it collaborates with.

+---------------------------------------+
| Class: Reservation       ID: 4        |
| Type: Concrete, domain                |
+---------------------------------------+
| Responsibilities   | Collaborators    |
|--------------------+------------------|
| Knowing:           |                  |
|  code, date,       |                  |
|  end time          |                  |
| Doing:             |                  |
|  check if expired  |                  |
|  set aside copy    | Copy             |
|  notify student    | Student          |
+---------------------------------------+
Back: attributes (code, createdAt,
expiresAt), relationships (Student, Copy)

Responsibilities are of two kinds: knowing (the data it knows) and doing (the work it does). A class that cannot do a responsibility on its own writes the class it collaborates with on the right side. Role-playing: team members take the cards in their hands and act out a use case step by step; a missing responsibility or class shows up immediately.

Class diagram

The class box

+---------------------------+
|         Student           |
+---------------------------+
| -studentNo : String       |
| -name : String            |
| -birthDate : Date         |
| -/age : int               |
+---------------------------+
| +reserve(c : Copy) : Bool |
| +getActiveCount() : int   |
+---------------------------+

Kinds of operation: constructor (creates an object), query (returns information without changing state, e.g. getActiveCount), update (changes state, e.g. reserve).

Association and multiplicity

An association is a solid line between two classes. A name (makes, contains) and a reading direction can be written on it. At each end is written how many objects from the class at that end are possible.

How to read: “How many Reservations does a Student have?” → 0..3 → written at the Reservation end. “How many Students does a Reservation have?” → 1 → written at the Student end.

+---------+ 1    makes >   0..3 +-------------+
| Student |---------------------| Reservation |
+---------+                     +-------------+

PITFALL · writing the multiplicity at its own end. The 3 in the sentence “a student has at most 3 reservations” is written next to Reservation, not next to Student. Each time, ask “how many Y does one X have?” and write the answer next to Y.

Association class

It is used when the relationship itself has data. Student and course are in a many-to-many relationship; the grade belongs neither to the student nor to the course.

+---------+ *          * +--------+
| Student |--------------| Course |
+---------+      :       +--------+
                 :
          +------------+
          | Enrollment |
          +------------+
          | grade      |
          | semester   |
          +------------+

Aggregation and composition

Both are whole-part (part-of) relationships.

+-------+ 1        1..* +-----------+
| Order |<#>------------| OrderLine |
+-------+               +-----------+
(<#> = filled diamond, if the Order is deleted the lines go too)

+--------+ 1       0..* +--------+
| Branch |<>------------|  Copy  |
+--------+              +--------+
(<> = hollow diamond, if the branch closes the copy moves to another branch)

Generalization

An “is-a-kind-of” relationship. The subclass inherits the attributes and operations of the superclass and adds its own.

          +----------+
          | Person   |  (abstract, italic)
          +----------+
          | -name    |
          | -email   |
          +----------+
              /_\
               |
       +-------+-------+
       |               |
+-----------+   +-------------+
| Student   |   | Librarian   |
+-----------+   +-------------+
| -studentNo|   | -staffNo    |
+-----------+   +-------------+

An abstract class is a class with no direct objects (nobody is just a “Person”). A concrete class is a class that has objects.

PITFALL · confusing generalization with aggregation. “A student is a person” → generalization. “A branch has copies” → aggregation. Ask: “is it ‘is a kind of’ or ‘has a / is part of’?”

Worked example: the campus library class diagram

Scenario: “The library has several branches. Each book has one or more physical copies, and each copy is kept at one branch. Students borrow copies; a loan record is for a single student and a single copy. A student can make at most 3 reservations at the same time; a reservation holds a single copy. Students and librarians are persons; the name and e-mail of both are kept.”

Step 1: Classes. Branch, Book, Copy, Student, Librarian, Person, Loan, Reservation.

Step 2: Attributes and operations.

Step 3: Relationships and multiplicity.

Read the Reservation - Copy row: a Reservation holds exactly one Copy (1 at the Copy end). A Copy can be in at most one reservation at a time (0..1 at the Reservation end).

Step 4: The drawing (summary).

Student     1 -------- 0..3 Reservation
Reservation 0..1 ----- 1    Copy
Student     1 -------- 0..* Loan
Copy        1 -------- 0..* Loan
Book        1 -------- 1..* Copy
Branch      1 <>------ 0..* Copy
Student   ---|> Person {abstract}
Librarian ---|> Person {abstract}

Each line is a relationship: the number on the left is written at the end of the class on the left, the number on the right at the end of the class on the right. On the exam you draw this with boxes; what matters is that the multiplicity at each end is on the right side.

Object diagram

An object diagram shows the objects in the system at a particular moment and the links between them. It is a “photograph” of the class diagram. The object name is written in the form name : Class, underlined; attributes are shown with their actual values. Multiplicity is not written.

+------------------+     +------------------+
| ayse : Student   |-----| r1 : Reservation |
| studentNo="2041" |     | code="R-118"     |
+------------------+     +------------------+
        |                         |
        |                +------------------+
        |                | c7 : Copy        |
        |                | status="On Hold" |
        |                +------------------+
+------------------+     +------------------+
| r2 : Reservation |-----| c9 : Copy        |
| code="R-131"     |     | status="On Hold" |
+------------------+     +------------------+

Here there are 5 objects (ayse, r1, r2, c7, c9) and 4 links: ayse-r1, ayse-r2, r1-c7, r2-c9. An object diagram is a good way to test multiplicities: if you try to add a fourth reservation for Ayse, you violate the 0..3 rule in the class diagram.

Common mistakes