We have already seen that the domain model represents classes in the system, while use-cases analyse the application from a user interaction point of view. However, we need to bridge the gap between these two aspects of the system, the user interaction, and the potential classes. Robustness diagrams allow us to do this by considering what classes from the domain model are needed for each step of each use-case. See Rosenberg and Stephens, "Use Case Driven Object Modeling with UML - Theory and Practice" (2013), p101-2
Robustness diagrams use three different symbols to represent different aspects of the system:
Robustness diagrams must follow certain interaction rules, described below:
We will now look at a robustness diagram for the "enrol student" use case. The use-case text is repeated below, from week 4.
| Step | Actor action | System response |
|---|---|---|
| 1 | The use case begins when the admin staff selects to enrol a new student. | - |
| 2 | - | System prompts the user for the student details (name, address, date of birth, course) |
| 3 | The user enters the details specified in step 2. | - |
| 4 | - | System checks validity of details, e.g. date of birth is sensible |
| 5 | - | System allocates student ID for new student |
| 6 | - | System enrols student in university |
| 7 | - | System confirms enrolment is successful |
The diagram is derived from the use-case text as follows:
if statement to check that the student details are not blank, year of birth is sensible, etc.Here is a second example, again the use-case text is repeated from week 4.
| Step | Actor action | System response |
|---|---|---|
| 1 | The use case begins when the admin staff selects to edit the student details | - |
| 2 | - | System prompts the user for the student ID |
| 3 | The member of staff enters the student ID. | - |
| 4 | - | System searches for the student with that ID |
| 5 | - | System displays details of that student in editable text boxes |
| 6 | The admin staff changes the details. | - |
| 7 | - | System checks that the new details are valid (e.g. no blank strings) |
| 8 | - | System updates details of the student |
| 10 | - | System confirms details updated |
StudentDetailsValidator class, in which we validate the student details within its own class; this might be necessary as it could be a relatively complex process (e.g. check the date of birth is valid, check the course exists, etc).StudentDetailsValidator are shown below, firstly enrol student:
Having linked the use-cases to the domain model classes with robustness diagrams, the next stage is to move to a more detailed design, in which we work out what methods might be in the system, which classes they belong to and what order each method should be called. The sequence diagram allows us to do this: sequence diagrams show all the components in the system and their interactions (in the form of method calls), focusing on the order (sequence) in which they are called. Once a sequence diagram is completed, the methods shown on it can be used to enhance or correct the class diagram, to produce a finalised, accurate class diagram from which coding can begin.
allocateStudentId()addStudent(), and again add it to the class diagram if it is not there already
getDetails() is shorthand for a series of getter methods, to retrieve each individual detail (name, course, etc).setDetails() method.You can also show alternative courses of action on a sequence diagram. This sis done by means of a UML frame. This has a label (alt for alternative courses of action) together with two or more sections, each representing an alternative course of action, and separated by a dotted line. Each section is annotated with the condition which must hold true for that course of action to run. Here is an example:
Please see this blog article for more detail on preparing a sequence diagram in diagrams.net.
Note: exercises on use cases have now been moved here from week 4.
For the live music venue scenario from week 4, draw up a use case diagram for these use cases:
Below is a domain model and two use case texts for the live music venue scenario, introduced in week 4. Using these:
| Step | Actor action | System response |
|---|---|---|
| 1 | The use case begins when an administrator selects to add an event | - |
| 2 | - | System prompts the administrator for the event details |
| 3 | The administrator enters the event details | - |
| 4 | - | System checks there is no event already on that date at that time |
| 5 | - | System creates event with the entered details |
| 6 | - | System adds the event to the venue. |
| 7 | - | System confirms event added to the user. |
| Step | Actor action | System response |
|---|---|---|
| 1 | The use case begins when a customer selects to book an event | - |
| 2 | - | System prompts the customer for the event name |
| 3 | The customer enters the event name. | - |
| 4 | - | System searches for the event(s) with that name |
| 5 | - | System displays details of all matching events |
| 6 | The customer chooses an event from the list. | - |
| 7 | - | System checks the event is not fully booked |
| 8 | - | System books the event for the customer |
| 9 | - | System confirms event booked |