University of Wollongong in Dubai

CSIT114 – System Analysis

Understanding Users & Domain Modeling

Dr. Haitham Yaish

Dr. Zeenath Reza Khan
 Document Change Control

Version Author Date Change Description

1.0 Dr. Haitham Yaish Autumn 2023 Defined the first version

3
 Agenda

First Part of the Lecture

• Understanding Users
- Robustness Diagrams
- Robustness Diagrams - Case Study
- Robustness Diagrams – Class Activity

Second Part of the Lecture

• Domain Modelling
- Class Responsibility Collaborator
- Class Responsibility Collaborator - Class Activity

4
 Robustness Diagrams

• Robustness diagrams describe a technique called robustness analysis.

• The basic idea is that you can analyze the steps of a use case

1) To validate the business logic within it.

2)To ensure that the terminology is consistent with other use cases
that you have previously analyzed.

3) To ensure that your use cases are sufficiently robust to represent the
usage requirements for the system you're building.

5
 Robustness Diagrams

A robustness diagram is basically a simplified UML

communication/collaboration diagram which uses the graphical
symbols.

6
 Robustness Diagrams

The graphical symbols of robustness diagram are:

• Actors: the same concept as actors on a UML use case diagram.

• Boundary elements: represent software elements such as screens, reports, HTML

pages, or system interfaces that actors interact with.

• Control elements: are glue between boundary elements and entity elements,
implementing the logic required to manage the various elements and their
interactions.

• Entity elements: These are entity types that are typically found in a conceptual
model, such as Student and Seminar.

• Use cases (optional): Because use cases can invoke other use cases you need to be
able to depict this on your robustness diagrams

7
 Robustness Diagrams

The flowing diagram illustrates the rules of

robustness analysis.

• You can have one or more actors, boundary

objects, controllers, and entity objects in a use
case.

• Actors can only talk to boundary objects.

• Boundary objects can only talk to controllers

and actors.

• Entity objects can only talk to controllers.

• Controllers can talk to boundary and entity

objects, other controllers, but not to actors.
8
 Robustness Diagrams

Sign up in a web site

Example.

9
 Robustness Diagrams

• We add a boundary element for each major user interface element

such as a screen or a report.

• We add a controller to manage the overall process of the

scenario being modeled.

• The controller provides the glue which keeps the diagram

together.

• The controller can be implemented as one class, one or more

operations, or workflow engine.

10
 Robustness Diagrams

• We add an entity for each business concept.

(e.g. student, and student fee classes).

• We add a use case whenever one is

included in the scenario.

11
 Robustness Diagrams

• By drawing a robustness diagram we quickly gain a sense for

the work that we need to do to implement a use case.

• Robustness diagram helps to visualize the potential

elements we have to build.

• The boundary elements will help to bridge your use cases to

your user interface development.

• The controllers are much closer to design concepts, so

robustness diagrams help to bridge to your design.

12
 Robustness Diagrams - Example

Student Table

Use the Enrol in Seminar System Use Case and the Student Table to draw a
Robustness Diagram that depicts this case study.
13
 Robustness Diagrams - Example

14
 Robustness Diagrams - Case Study

Car Rental Booking Use Case

Name: Car Rental Booking.

Identifier: UC 1

Description:
This use case describes the events of a customer who wants to make online booking to rent a
car.

Preconditions:
The customer who would like to book a car for rental must be over 18 years old or older and has
a driving license.

Postconditions:
None.

15
 Robustness Diagrams – Case Study
Basic Course of Action:

1. The use case begins when a customer indicates he/she wants to book a car from UI 1 - Home page screen.
2. The customer selects the booking option.
3. The system navigates the customer to UI 2 - Booking Screen.
4. The customer inputs his/her booking details to search for a suitable car via UI 2 - Booking Screen.
5. The system searches for matched cars. [Alternate Course A]
6. The system displays UI 3 Available Cars Screen, which indicates the list of available car types.
7. The customer views and then selects the car type that he/she is interested in. [Alternate Course B].
8. The system validates if the customer age is 18 years old or older and has a driving license. [Alternate Course
C]
9. The system displays the price of the car for the person via UI 4 Display Car Price Screen.
10. The customer confirms he/she wants to book the car via UI 4 Display Car Price Screen. [Alternate Course D]
11. The system navigates the customer to UI 5 Customer Personal Details.
12. The customer inputs his personal details.
13. The system stores the customer’s details and the reservation details.
14. The system displays UI 6 Payment Screen.
15. The customer inputs his/her credit card details.
16. The system verifies the customer credit card via external system.
17. The system bills the customer for his/her booking. [Error]
18. The system informs the customer that he/she booked the car via UI 7 Thank You Screen.
19. The use case ends.

16
 Robustness Diagrams - Case Study

Alternate Course A: The required car type is not available.

A5. The system determines that the car type is not available.
A6. The system informs the customer that the required car is not available via UI 8 Not
Available Car Screen.
A7. The use case ends.

Alternate Course B: The customer decides not to book a car.

B7. The customer views the available cars and he/she is not interested in any of the cars.
B8. The use case ends.

Alternate Course C: The customer is not eligible to book a car.

C8. The system determines the customer is not eligible to book a car.
C9. The system informs the customer he/she is younger than 18 years old or doesn’t have driver license via UI 9 Not Eligible Screen.
C10. The use case ends.

Alternate Course D: The customer decides not to proceed with the booking.
D10. The customer views the price of the car and he/she decides not to book the car.
D11. The use case ends.

Error: The customer credit card details are not valid.

E17. The system determines the customer’s credit card is not valid.
E18. The system displays error message to the customer via UI 10 Not valid Credit Card Screen.
E19. The use case ends.

17
 Robustness Diagrams - Case Study

Car Rental Booking Database

18
 Robustness Diagrams - Case Study

The first version before applying the alternative scenarios

19
 Robustness Diagrams - Case Study

Alternate A

After applying the alternative scenario A

20
 Robustness Diagrams - Case Study

Alternate A

Alternate C

After applying the alternative scenarios A and C

21
 Robustness Diagrams - Case Study

Alternate A

Alternate C

Alternate E

After applying the alternative scenarios A , C, and E

22
 Robustness Diagrams - Class Activity

E-Scooter Rental Application

Use Case Description: E-Scooter Rental Application

Use Case Title: Renting an E-Scooter

Primary Actor: Customer

Preconditions:
1. The customer has a valid user account with the E-Scooter
rental service with money account balance.
2. The customer has the E-Scooter rental application installed
on their mobile device.

23
 Robustness Diagrams - Class Activity

E-Scooter Rental Application

Postconditions:
1. The E-Scooter is locked and parked securely.
2. The E-Scooter rental application updates the availability
of the E-Scooter for other potential renters.
3. The E-Scooter is available for the next customer to rent.

24
 Robustness Diagrams - Class Activity

E-Scooter Rental Application

Main Success Scenario:

1. The customer clicks on the E-Scooter rental icon of the application on their mobile device
via UI 1 - Mobile Application Icon.

2. The E-Scooter application navigates the user to UI 2 - login screen.

3. The customer logs in using their credentials (username and password).

4. The E-Scooter application verifies the credentials. [Error – Invalid credentials]

5. The E-Scooter application displays a map with the locations of available E-Scooters in
Dubai via UI 3 - E-scooter Map.

6. The customer selects an available E-Scooter on the map to view more details, such as the
scooter's current battery status and estimated distance to their location.

7. The E-Scooter Application displays more details about the scooter on UI 4 E-Scooter
details Screen.

25
 Robustness Diagrams - Class Activity

E-Scooter Rental Application – Case study

Main Success Scenario:

8. The customer decides to rent the selected E-Scooter and taps the "Rent“
button.

9. The application prompts the customer to confirm the rental, and displays
information about the cost per hour, the E-Scooter battery status, and location via UI
5 – Confirmation Rent.

10. The customer confirms the rental via UI 5 – Confirmation Rent. [ Alternate Course
A – The Customer Declined the rent]

11. The E-Scooter application processes and updates the rental request, reserves the
selected E-Scooter for the customer, and sends a confirmation to the customer along
with a digital unlock code or QR code on UI 6 – unlock code.

12. The customer arrives at the location of the E-Scooter, they enter the unlock code
or scan the QR code on the E-Scooter using the E-scooter unluck device via UI 7 – Lock
and unlock device screen.
26
 Robustness Diagrams - Class Activity

E-Scooter Rental Application

Main Success Scenario:

13. The rental information will be updated in the application.

14. The E-Scooter is unlocked, and the customer is now able to use it.

15. The customer rides the E-Scooter to their desired location.

16. Once the customer has completed their ride, they park the E-Scooter in a designated
parking area and securely lock it using UI 7 – Lock and unlock device screen.

17. The E-Scooter application registers the end of the ride and deducts the ride from the
customer’s money account balance.

18. The application will send a message to the customer to display the rental summary,
including the total cost and distance travelled and the details will be displayed on UI 8 –
Rental summary screen.

27
 Robustness Diagrams - Class Activity

E-Scooter Rental Application

Alternative Paths:

Alternate Course A: The Customer Declined the rent

A10. The customer views the E-Scooter details and he/she decided not to
proceed with renting it.
A11. The use case ends.

Error: The credentials of the customer are invalid

E4. The E-Scooter system verifies and determines the customer’s
credentials are invalid.
E5. The E-Scooter system displays error message to the customer via UI 9
Invalid credentials screen.
E6. The use case ends.

28
 Robustness Diagrams - Class Activity

E-Scooter Rental Application

Data Storage (Database)

29
 Robustness Diagrams - Class Activity

E-Scooter Rental Application

Work in a group to analyse the E-Scooter Rental

Application use case description and the data storage
to construct E-Scooter Rental Application Robustness
Diagram.

30
 Class Responsibility Collaborator (CRC) Cards

• CRC (Class-Responsibility-Collaboration) cards

are a commonly used technique in domain
modelling, specifically in the context of object-
oriented analysis and design.

• CRC cards are a visual and interactive way to

represent and analyse the structure and
behaviour of classes within a software system.

31
 Class Responsibility Collaborator (CRC) Cards

• A Class Responsibility Collaborator is a collection of

standard index cards that have been divided into three
sections including:

1. A class represents a collection of similar objects.

2. A responsibility is something that a class knows or does.

3. A collaborator is another class that a class interacts

with to fulfill its responsibilities.

32
 Class Responsibility Collaborator (CRC) Cards

The layout of a
CRC card

33
 Class Responsibility Collaborator (CRC) Cards

• CRC models are an incredibly effective tool for conceptual modeling

as well as for detailed design.

• A class represents a collection of similar objects. An object is a

person, place, thing, event, or concept that is relevant to the system
at hand.

• The name of the class appears across the top of a CRC card and is
typically a singular noun or singular noun phrase, such as Student,
Professor, and Seminar.

• Class names should be also simple. (e.g. student is better than

person who take seminar).

34
 Class Responsibility Collaborator (CRC) Cards

• A responsibility is anything that a class knows

or does. (e.g. students have names, addresses,
and phone numbers, method (function)).

An example of CRC card

35
 Class Responsibility Collaborator (CRC) Cards

• You have the option of listing important attributes that

are required for particular use cases on the back of the
card.

• This case suitable when we use physical CRC cards not

drawing it using a software/tool.

36
 Class Responsibility Collaborator (CRC) Cards

• Collaboration takes one of two forms: A request for information ,

or a request to do something.

e.g. the card Student requests an indication from the card

Seminar whether a space is available (request for information).

e.g. Student then requests to be added to the Seminar (request to

do something).

37
 Class Responsibility Collaborator (CRC) Cards

How to create CRC models?

1. Find classes.
2. Find responsibilities
3. Define collaborators.
4. Move the cards around.

38
 Class Responsibility Collaborator (CRC) Cards

How to create CRC models?

1. Find classes.
• Finding classes is fundamentally an analysis task because it deals
with identifying the building blocks for your application.

• A good rule of thumb is that you should look for the three-to-five
main classes right away, for example Student, Seminar,
and Professor.

• Sometimes include UI classes such as Transcript and Student

Schedule, both are reports, although others will stick to just entity
classes.
39
 Class Responsibility Collaborator (CRC) Cards

How to create CRC models?

2. Find responsibilities

• You should ask yourself what a class does as well as what

information you wish to maintain about it.

• You will often identify a responsibility for a class to fulfill a

collaboration with another class.
40
 Class Responsibility Collaborator (CRC) Cards

How to create CRC models?

3. Define collaborators.
• A class often does not have sufficient information to fulfill its responsibilities.

• Therefore, it must collaborate (work) with other classes to get the job done.

• Collaboration will be in one of two forms: a request for information or a request to

perform a task.

• To identify the collaborators of a class for each responsibility ask yourself “does
the class have the ability to fulfill this responsibility?”. If not then look for a class
that either has the ability to fulfill the missing functionality or the class which
should fulfill it.

• In doing so you’ll often discover the need for new responsibilities in other classes
and maybe even the need for a new class or two.
41
 Class Responsibility Collaborator (CRC) Cards

How to create CRC models?

4. Move the cards around.

• To improve everyone’s understanding of the system, the cards should be placed on

the table in an intelligent manner.

• Two cards that collaborate with one another should be placed close together on
the table, whereas two cards that don’t collaborate should be placed far apart.

• Furthermore, the more two cards collaborate, the closer they should be on the
desk.

• By having cards that collaborate with one another close together, it’s easier to
understand the relationships between classes.

Note: You can apply the similar concept once you use software/tool to create the CRC
cards.
42
 Class Responsibility Collaborator (CRC) Cards

Advantages of CRC cards?

1. You can get an overview of the system.

2. When some one of the team needs to move a card or change, this action
encourage the discussions to happen between the team.

3. The team most likely will find new responsibilities.

4. To help every one to participate and understand the model.

43
 Class Responsibility Collaborator (CRC) Cards

Sample of the CRC cards for a university Information system

44
 Class Responsibility Collaborator (CRC) Cards

Sample of the CRC cards for a university Information system

• Note: In the Transcript , and Student Schedule CRC cards, the statement “See
the Prototype” is used, because the Transcript and the Student Schedule have
many information, and for simplicity, this way is used.

• This just an example of using this simple way, but it is not always the case to
use this way in CRC cards.

45
 Class Responsibility Collaborator - Class Activity

Work in a group to draw CRC cards for a

Hotel Management System .

Think with your group members about the following:

1. what are the CRC cards (classes) that you would
have for your solution?
2. What are the responsibilities for each card?
3. What are the collaborators for each card?
4. Do you need to move your card around ?

46
 References
• Satzinger, J., Jackson, R. & Burd, S. (2016) Systems Analysis And Design In A
Changing World. 7th Edition, Boston, Mass. Cengage Learning.
• The Object Primer, 978-0521540186, Scott W. Ambler; Cambridge University Press,
3rd edition.​
• Best Practices For WLI Application Lifecycle .
https://docs.oracle.com/cd/E13214_01/wli/docs92/bestpract/requirementsappen
dix.html
. Last Accessed 7 October 2023

47
 THANK YOU
Any Question ?

48