INTERNATIONAL UNIVERSITY - VNUHCM

MID-TERM EXAMINATION
Announcement Time: 8:00 AM, Tuesday, 21/04/2020.
Due Date: 8:00AM, Friday, 24/04/2020
Submission: on Blackboard & via Email

SUBJECT: OBJECT-ORIENTED ANALYSIS & DESIGN (IT090IU)

Chair of School of Computer Science & Lecturer

Engineering Signature:
Signature:

(Approved)

Full name: Nguyen Van Sinh, PhD. Full name: Nguyen Hong Quang, PhD.

INSTRUCTIONS (Please read this part carefully)

- Purpose: Testing the students’ knowledge and skills on Object-oriented Analysis and
Design.

- Assessment: Individual work (Assessment No. 5): This part is worth 20% of the final total
score. The Mid-term 2020 questions are announced on Blackboard at 08:00AM, on Tuesday,
21 April 2020, under the link “Exams” of this OOAD course, with the title:
“Mid-term Exam 2020 Questions (Due Date: 8AM, Friday, 24 April 2020)”

- Submission: Students are required to submit the answers in MS WORD document, with
your FULL NAME and STUDENT ID on your front page, using both methods:
1. on Blackboard under the “Exams” link, and
2. via Email: [email protected], with your Email Subject
“OOAD Midterm Answers, <YourStudentID>, <YourStudentName>”

- Academic Honesty: Each student is required to work individually and honestly to answer
these mid-term exam questions. Any academic misconduct (e.g., plagiarism - the submission
of somebody else’s work in a manner that gives the impression that the work is your own) is
strictly prohibited and will be processed based on the International University’s regulations.

- No extensions will be given: Penalties are applied to late submission with the decision from
the School/University. If there are circumstances that prevent the answers being submitted on
time, an application for special consideration may be made. Note that delays caused by
computer downtime cannot be accepted as a valid reason for a late submission without
penalty. Students must plan their work to allow for both scheduled and unscheduled
downtime.

1
QUESTION 1 (20%):
a. Describe a typical software development process, with a clear explanation on what
are expected in each step of the process and input/output of each step.
b. Why do we focus on the two qualities “streamlined” and “rigorous” in our course?

QUESTION 2 (80%):
Problem Statement
DU-Rent is a company in car rental business. It has over 100 branches all over the country. It
has about 5,000 cars and makes about 500,000 rentals per year. The rentals spread across 100
branches: branches in major airports, branches in major cities, and branches in local agencies
such as hotels and garages. Each branch is identified by a branch number.
DU-Rent has several IT systems. We are concerned with one of them. This system is called
DU Rental System. Its main purpose is to maintain information of the cars and the rentals of
those cars. It is also used to manage the car fleet, e.g. moving cars from branch to branch
when necessary.
It is decided that the system will be constructed as a central system which has access to the
information about every DU-Rent branch. Later on, when it is installed at a branch, it will be
customized to restrict its access scope to an appropriate level.
DU-Rent Cars
Each car has a model, identified by a model number. Useful information about a model
includes a short description (which usually includes the model’s marketing name), automatic
or manual, petrol consumption (such as 1.5 liters or 6 cylinders) , number of doors. The cars,
on the basis of their model, are divided into five groups, group ‘A’ to group ‘E’, and all the
cars in a group have the same rental price.

DU-Rent Customers
DU-Rent estimates that about 15,000 customers per year are served, of whom about 12% rent
frequently, 40% rent between 3 to 5 times per year, and 50% are one-off renters in the sense
that they use DU-Rent once per year or less.
In fact, DU-Rent shares a (much larger) customer information base with other businesses
including various airlines and hotel providers. However, the sharing of customer information
is done through a separate system. This is done so transparently (for both querying and
updates) that we think of the shared customer base as part of the current system (for querying
and adding customers).
A blacklist of customers is maintained by DU-Rent. It is updated periodically based on the
reports from the branches. The maintenance of the blacklist follows a separate process that we
do not need to be concerned with. We can simply assume that the list is available for
querying.
A discount customer list is also available. Customers on this list are given a 10% discount for
their car rents. The list is maintained by a separate system. We can simply assume that the list
is available for querying.
Thus, regarding the customers, a list of customers, a blacklist, and a list of customers entitled

2
for discount are available for querying. In addition, the branches are also allowed to add new
customers to the customer list.

DU-Rent Car Rental Activities

The main activity at the branches is, of course, to rent cars on customers' requests. Customer
can reserve a car. They can also walk-in to request and pick up a car. Thus, the rentals involve
the following activities: (1) answering customers' enquiries, (2) making reservations (3)
recording walk-in rentals, (4) recording car pick-up, (5) recording returns of cars (may be at a
different branch form the pick-up one, late returns possible), etc.
The company's headquarter is responsible for purchasing and disposing off cars. When a car
is bought, its information (including its model if necessary) is entered into the system.
Depending on their conditions and customer demand, cars may be removed from the fleet to
be disposed off (e.g. though sales).

Descriptions of Main Business Processes

The following descriptions of the main business processes have been produced. It is
acknowledged that some part of the descriptions might be neither clear nor complete. They
are meant to serve as a starting point for further analysis activities. As you carry out the
required tasks, you can refine or enhance them with additional details and business processes
if you think it is necessary. In such cases, clearly state your assumptions.

Business Process: Renting a Car (BP1)

Starts when: Customer requests for a car
Ends when: The car is returned (normal case)
Description:
1. A customer reserves a car with a branch. This is dealt with in the subprocess Reserving a
Car (BP1.1a)
Alternatively, a customer can request and pick up a car without reservation. See
subprocess Picking-up a Car without Reservation (BP1.1b)
2. The branches must make sure that the car is available for pick-up. See subprocess Moving
Cars on Request (BP1.2)
3. The customer picks up a car that has been reserved. See subprocess Picking-up a
Reserved Cars (BP1.3)
4. The customer returns the car. See subprocess Recording the Returning of a Car (BP1.4)

Business Process: Reserving a Car (BP1.1a)

Starts when: Customer requests for a car
Ends when: A car is reserved for the customer (normal case)
Description:
1. A customer can rent a car by email, by phone or by walking into an office, making an
enquiry or a request.
2. The booking clerk gets the customer's requirements. Typical requirements are as shown
below:

3
 Location of Travel
Pick-up Branch: Melbourne Airport
Return Branch: Melbourne Airport
When
Pick-up Date: 20-AUG-2010 Time: AM 10.00
Return Date: 22-AUG-2010 Time: AM 10.00
Type of Car (Make one or more selections)
Economy: ü Station Wagon:
Compact Car: Van:
Medium Size: ü 4 Wheel:
Full Size: Sports/Luxury Car:

3. The clerk finds out from the system if an appropriate car is available at the requested
branch or a neighboring branch and the cost (which is often of interest to the customer).
Branches A and B are neighboring branches if any car at A can be requested to be moved
to B overnight and vice versa (see subprocess BP1.2). Each branch has a list of
neighboring branches.
To find out if a car is available is not a trivial task. We can apply simple search rules as
well as quite sophisticated search rules. Currently, DU-Rent uses the following simple
search rule.
Simple Search Rule:
A car is available if
(1) Its status is RENT-READY
(2) It matches the types of car the customer asks for
(3) It is at the requested pick-up branch or one of its neighboring branches

4. If no car is available, the clerk fills out a paper form which contains the requested pick-up
branch, pick-up date and time, types of car wanted, and the customer contact phone
number and/or email address. The supervisor may negotiate to have a car delivered to the
requested branch and inform the customer about it. (It is not part of the responsibility of
the system to support this sub-process.)
5. Otherwise (i.e. one or more cars are available), the clerk selects a car and put it on hold,
that is sets it status to “HELD” (so that other operators will not reserve it).
NOTE ON ALTERNATIVE: If the deal does not go ahead as planned the clerk must
release the hold on a car.
6. The clerk then asks for the customer’s driver license to check if the customer is
blacklisted or not.
7. If the customer is new, the clerk will enter the new customer to the customer base. The
following information is entered: the customer’s first name, last name, driver license,
email address (if available), and contact phone number (if available).
8. If the customer is not black listed, a new transaction, which is called a rental, is created.
The new rental has a unique rental number (generated by the system) and has its status set
to “RESERVED”.

4
 In addition to information about the reserved car, the pick-up and the return (date, time,
branch), the clerk also enters information about payment.
A deposit of 10 % of cost (which may involves discount) has to be made by the customer.
The payment can be made against the payment item “Deposit Payment” (the other
payment item is “Cost Less Deposit Payment”). Payment amount and payment method
(cash or credit card) are recorded. If the payment is made by credit card, the credit card’s
details are obtained and validated. The validation is performed by a call to another
system.
The car assigned to this rental will have its status set to “RESERVED”.

Business Process: Picking-up a Car without Reservation (BP 1.1b)

Starts when: Customer walks in and requests a car
Ends when: The customer picked up a car (normal case)
Description:
1. A customer walks into the office of a branch and makes a request.
2. The booking clerk gets the customer's requirements (as in subprocess BP1.1a) and see if a
car is available at the branch.
3. If it is the clerk asks for the customer’s driver license to check if the customer is
blacklisted or not.
4. If the customer is not black listed, the clerk asks for payment and creates a new car rental.
The same information recorded is as those described in the subprocess BP1.1a, except
that the status of the new rental is marked as “PICKED-UP”.
In addition, the car status is set to “PICKED-UP” and the mileage of the car is recorded
for the rental (which is known as start-mileage).

NOTE ON ALTERNATIVE: The customer may be a new one. In this case, his or her details
are entered to the system as described in the previous process.

Business Process: Moving Cars on Request (BP1.2)

Starts when: The supervisor starts arranging to move the cars requested for neighboring
branches (done daily at certain time)
Ends when: Cars requested by other branches have been arranged to be moved
Description:
1. The supervisor prints out the list of cars at his/her branch which have been requested by
other neighboring branches
2. The supervisor arranges for the cars to be transferred. (It is not part of the responsibility
of the system to support this activity.)

NOTE ON SUBSEQUENT ACTIVITIES: When a car requested from a neighboring branch

arrives, its new location is updated. This is actually a separate process though it is not
currently described in this document.

5
Business Process: Picking-up a Reserved Car (BP1.3)
Starts when: The customer arrives at a branch to pick-up a car that has been reserved
Ends when: The car has been picked-up
Description:
1. If the reserved car is not available for some reason (e.g. overnight trip failed, which is
rarely the case), the clerk will replace it by another car (if possible).
In this case, the previously reserved car will have its status set to “EXCEPTIONAL”, and
the substitute car will have its status set to “HELD” (so that no one else can put it on
hold).
2. If a substitute cannot be made, the clerk sets the status of the reserved rental to
“EXCEPTIONAL” and also ensures that the status of the reserved car is set to
“EXCEPTIONAL”.
The case is then referred to the supervisor to arrange for a refund. (It is not part of the
responsibility of the system under study to support this process.)
3. Otherwise, the clerk checks the driver license to see if it matches the license used for the
reservation. If a different driver license is used and the new driver is not blacklisted, a
change of driver can be made.
4. The clerk asks for the rest of the payment and enters the payment details is entered. The
payment item is “Cost Less Deposit Payment”.
5. The clerk also enters the actual pickup date and time. The status of the rental is changed
to PICKED-UP. The status of the car is also changed to PICKED-UP. The car’s mileage
is recorded again the rental record.
6. The customer picks up the car.

NOTE ON ALTERNATIVE: A customer may cancel a reservation or may simply not turn
up. In either case, the rental will be cancelled and the customer losses their deposit. The
rental’s status is set to “EXCETIONAL”, and the car’s status set to “RENT-READY”.

Business Process: Recording the Returning of a Car (BP1.4)

Starts when: A customer returns a car
Ends when: Details have been entered for the return
Description:
1. The clerk records end mileage, and the actual return date and time, and changes the status
of the rental to “RETURNED”.
2. If the car is returned to different branch (i.e. not the “return” branch recorded at the time
of reservation or pick-up), this has to be recorded against the rental record.
3. The clerk changes the status of the car to RETURNED, and updates the car’s residing
branch (i.e. where the car is).

NOTE ON SUBSEQUENT ACTIVITIES: The car will need to be inspected before returning
to the “active” pool ready to be rented. The car can also be set aside for services or to be
removed from the fleet..

6
Business Process: Arranging for Car Maintenance (BP2)
Starts when: One or more cars need to be inspected
Ends when: Decisions have been made about the cars
Description:
1. The supervisor prints the list of cars to be inspected if necessary (for example, the list of
cars that were returned to the current branch).
2. The supervisor inspects the cars. The outcome for a car can be that it is OK, or that it
needs servicing, or that it is to be removed, and the supervisor will have its status updated
accordingly, i.e. RENT-READY, SERVICE NEEDED, or REMOVED respectively.
3. Supervisor arranges for necessary actions. (It is not part of the responsibility of the system
under study to support this activity.)

NOTE ON SUBSEQUENT ACTIVITIES: Later when a car has been serviced, and becomes
available at a branch, the information about the car is updated.

Business Process: Adding a New Car to the Active Pool (BP3)

Starts when: A new car is acquired by the company and to be added to the active pool
Ends when: The car’s details have been entered
Description:
1. If the model is new, the clerk enter the model’s details, which include (a) the model
number and a short description of the model (which usually includes the model’s
marketing name), (b) automatic or manual, (c) petrol consumption (such as 1.5 liters or 6
cylinders) , and (d) number of doors. The clerks also specifies which group (“A” to “E”)
the model is classified into
2. The clerk enters details of the car, including registration number, color, year of
production, and the car’s initial residing branch. The car’s status will be RENT-READY.

Notes on Other Processes

There are other processes that are not described here (for example the processes to generate
various kinds of reports). We will not be concerned with those processes in this exam.

Tasks
For this exam, you are required to do the following:

Task 1 – Use Cases [50%]

(a) Identify all the use cases, at the system level, to support the business processes described
above.

The business processes you have to consider include those given as NOTE ON
ALTERNATIVE or NOTE ON SUBSEQUENT ACTIVITIES (regardless of whether
7
 these processes are described separately or not).
If for certain processes to make sense, you think additional details or even additional
processes need to be added, then by all means do so. In such cases, clearly describe your
additional details or processes.
You must list your use cases against the steps in business process descriptions (given or
added by you). Each step of the business process corresponds to zero or more use cases.
Set up your answer in a table in the format shown below:

Business Process Step Use case Remarks

<name of business <name of use case> (UC 1)
process> (BP n) 1 <name of use case> (UC 2)

2
… … … …
… …

(b) Describe each of the use cases identified in Part (a) using the Event Flow Format (with
Main Flow/Extensions)
For ease of reference, give each use case a number.
Though there are dependencies among the use cases, you can ignore the specification of
invocation constraints and post obligations. This is done to keep the descriptions simple.
We do not seem to lose much information by not specifying those constraints and
obligations.

NOTE ON MARKING: You are required to describe all the use cases, but about 5 use-
case descriptions will be selected to mark in detail.

SAMPLE SOLUTION:
The business process BP2 (Arranging for Car Maintenance) has been done as a sample
solution for you as follows.

Business Process Step Use case Remarks

… … … …
Arranging for Car UC 16: Print the List of Cars to be Inspected
Maintenance (BP2) 1
UC 17: Record that a Car Needs to be Serviced
2 UC 18: Record that a Car is to be Removed
… … … …

8
Their use-case descriptions (with the Main Flows only) are given below as a sample.
Your answers must be provided in detail with the full the Event Flow Format.

UC 16: Print the List of Cars to be Inspected

1. Supervisor enters the branch’s number
2. System prints the list of cars to be inspected (i.e. cars on the branch with status
“RETURNED” or “EXCEPTIONAL”)

UC 17: Record that a Car Needs to be Serviced

1. Clerks/Supervisor enters the car’s registration number
2. System checks that the car exists
3. System sets status of the car to “SERVICE NEEDED”

UC 18: Record that a Car is to be Removed

1. Clerks/Supervisor enters the car’s registration number
2. System checks that the car exists
3. System sets status of the car to “REMOVED”

Task 2 – Structural Domain Modeling [30%]

Construct a structural domain model in terms of one or more (analysis) class diagrams.
Clearly state any assumptions you make.

9
THE BELOW STATECHARTS FOR REFERENCE ONLY:
To accomplish all the tasks above, it may be useful for you to consider the statecharts below
for (a) Car, (b) Rental with Reservation, and (c) Rental without Reservation.
Statecharts for Car
Basic Statechart – with exceptions being left out

From any state – except “REMOVED” – we can go to the special catch-all state
“EXCEPTIONAL”. This state covers the cases: Customer cancels reservation, or Reserved
car is not available, or DU-Rent cancels a reservation, or a Picked-up car has an accidence,
etc. Each time, one of these events happen, the car is moved to the state of
“EXCEPTIONAL”. From this state, it can go to: RENT-READY, SERVICE NEEDED, or
REMOVED.

10
Statechart – With exceptions being modeled by a catch-all EXCEPTIONAL state

Statecharts for Rental with Reservation

Basic Statechart - With exceptions being left out

11
Statechart - With exceptions modeled by the Exceptional state

For Rental without Reservation

The statecharts are the same as for Rental with Reservation, except that they do not have
Reserved state.
■

12