How to derive the class diagram

• Classes and their interrelationships come from the domain model
• When first analysing the problem statement, you can add a first guess at likely attributes and methods to the domain model to produce an initial class diagram
• The class diagram will be updated later, once we have gone through the full analysis and design process (robustness diagrams, sequence diagrams) as the full analysis and design will reveal additional methods and attributes

Class diagram syntax

Each class is represented by a box, with content as follows:

• Each class begins with the class name, followed by a horizontal line
• Attributes are denoted by:

  ACCESS AttributeName: AttributeType
  

  where ACCESS is:
  • + : public - accessible from anywhere
  • - : private - accessible only from instances of the current class
  • # : protected - accessible from instances of both the current class and subclasses
• A further horizontal line separates the attributes and methods
• Methods also have an access indicator, and show parameters and return types are, using this syntax (also used in the Kotlin language, which many of you will do next term):

  ACCESS method(param1: DataType, param2: DataType): ReturnType

• Regular lines, annotated by multiplicity indicators, link classes (as in the domain model)
• Additionally, arrows with unfilled heads indicate inheritance

Here is an example, based on the domain model above. Note that the addition of thesisTopic to the masters' student was not part of the domain model. I have added it here to help illustrate the inheritance hierarchy, but in a real case, you would not, at this stage, add things not in the domain model.

Inheritance in class diagrams

Inheritance in class diagrams is shown via an open arrow pointing at the superclass, for example:

Use cases

We may return to this in a later week, depending on how you are progressing.

The other step we need to take as an initial analysis and design step is use-case analysis. This takes a different approach to the problem compared to the domain model by considering the system from a user point of view; i.e. thinking about how the user will interact with the system. For example, we consider questions such as:

• Who are the users?
• How are they able to interact with the system?

An example use case diagram

A use case diagram shows:

• The actor(s)
  • These are the external entities interacting with the system: typically, but not necessarily, humans (the university administrator in our example)
  • Actors can be non-human, for example if an automated background process was interacting with the system (e.g. auto-removing students whose degree has finished) this would be an actor too
  • Represented by matchstick figures
• The use cases themselves
  • These are the tasks which the actors need to perform with the system
  • They can be derived by analysing the problem statement
  • e.g. for the university admin application, these could be:
    • Enrol student
    • Search for student by ID
    • Search for students by name
    • Create module
    • Add module to student
    • Edit student details
    • Delete student
• From these, we would draw the use-case diagram below. Note the actor (matchstick figure) and use cases themselves (shown as ovals).

Dependencies between use cases

A more detailed use-case diagram will show dependencies between use cases. Dependencies include:

• A use case extending another; this is when the second use case is an optional extension of the first
  • For example, delete a student might extend search for a student, because after searching for a student object, the administrator might optionally delete it
• A use case including another; this is where the second use case is part of the process of the first
  • For example, enrol a student might include edit student details, because student details is part of the process of enrolling a student
• A use case preceding another; this indicates that the first use case must take place sometime before the second
  • For example, the login use case might precede enrolling a student, updating a student's details, or deleting a student

Generalised and specialised actors

• A use-case diagram can have more than one actor, as different use cases might be performed by different actors
• Through use of the generalisation symbol in UML (an arrow with an unfilled arrow-head), we can distinguish between generalised actors and more specialised actors
• An example for the university system might be if senior administrators (only) were allowed to add staff. The senior administrator is a more specialised version of the administrator, so they can do all use cases that administrators can do, as well as their own specific use case of adding a member of staff.
• The example below shows this
  

Use-case texts

The next step is to break down each use case shown on the diagram into a series of steps describing how a user will interact with the system in order to complete the use case. use-case text has two columns:

• Actor action, describing how the actor will interact with the system
• System response, describing how the system will respond.

Example use-case text: Enrol student

Alternative courses of action

Our use-case text must also include alternative courses of action. These describe how the system should react to errors, which can help us design robust systems. These go below the main use-case text. For example, in the previous use-case text:

At step 4: Date of birth is not sensible.
    Staff informed that date of birth is not sensible.
    Staff re-prompted for details (go back to step 3)

Example use-case text: Edit student details

This is a simplified version assuming includes or extends are not being used.

Alternative courses of action:

At step 4: Student ID does not exist on system 
    Staff informed that the student ID does not exist
    Staff re-prompted for details (go back to step 2)

At step 7: New details are not valid (e.g. blank strings)
    Staff informed that the new details are invalid
    Staff re-prompted for details (go back to step 6)