Scribd
Upload
22 views6 pages

INF2009F - Workshop 5

The document discusses developing a class diagram for the first phase of the RestEasy Hotels reservation and billing system. It provides instructions on identifying important classes, their attributes, and relationships between classes. Students are asked to list noteworthy classes, document class attributes, draw a domain class diagram, and then refine it into an analysis class diagram. The analysis class diagram is then tested against several system requirements.

Uploaded by

asmal.saarah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
22 views6 pages

INF2009F - Workshop 5

The document discusses developing a class diagram for the first phase of the RestEasy Hotels reservation and billing system. It provides instructions on identifying important classes, their attributes, and relationships between classes. Students are asked to list noteworthy classes, document class attributes, draw a domain class diagram, and then refine it into an analysis class diagram. The analysis class diagram is then tested against several system requirements.

Uploaded by

asmal.saarah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

Systems Analysis and Design – INF2009F 2019

RestEasy Hotels Case Study – Workshop 5 - Class Diagram


Please enter the names of students in your workshop group into this table
Student Name Student Number Project Group
1.
2.
3.
4.
Your first step in identifying the RestEasy Hotel Reservations and Billing system
requirements was to build a use case diagram depicting all the uses of the system and
then to document the “Make a Guest Reservation” use case in more detail using a use
case narrative.
The next task we must perform is to identify and document the things in the system that
we need to keep information about. In the object-oriented approach these “things” will
become classes in our class diagram. This will be a four step process:
 to identify the things (classes) we need to keep information about
 to identify what properties (attributes) each class should “know”
 to identify the associations (relationships) that would be required between classes
together with their multiplicity (constraints) and draw a Domain Class Diagram
 finally to refine the diagram to represent an Analysis Class diagram and walk through
the use case narratives to verify the model has the classes, attributes and associations
to support the users requirements.
Remember, your class diagram should only relate to phase one of the project, the
reservation and billing system at RestEasy Hotels.
[6 Marks]
1. Identify and list the things (classes) the system needs to keep information about
in the space provided below. Taking the video store example, these could include
tangible things (eg. videos), people (eg. customers), organizational units (eg.
departments), documents (eg. video contract) and locations (eg. video store). Ask
yourself “Do I need to store information about these things in my system?” See if you
can identify 5 to 7 “noteworthy” concepts that are required in phase 1.
Time for this activity is 10 minutes (

Once you have identified the “noteworthy concepts” required in the RestEasy Hotels
Reservation and Billing system, call on a tutor to discuss the relevance of each one
you have identified before continuing. Classes we decide to keep will now move
into stage two.
[14 Marks]
2. Understanding the information stored by a class goes a long way towards
understanding the role of the object in the system. Below is a set of 7 tables you can
use to document the attributes (pieces of specific information) for each class.
For example, in the video store we would have a class Video with attributes such as
Video Number, Title, Distributor, Release Date.
 Write the name of each class in the first row of a table.
 Now try and identify an attribute that will act as a unique identifier (like a video
number or employee number) and write that into the second row.
 Finally, identify as many other attributes (pieces of specific information) you
feel the system should maintain about that particular object class. Repeat this
exercise for all object classes approved above. This exercise will take some time as
you will need to walkthrough the business activities described in the case study to
determine all the data attributes required. It is very important to document attributes
at this stage as they will assist in your understanding of what data each class
contains and therefore what role it plays in the system. Often you will hear
comments like “I thought we were storing the video hire details in the customer
class, not the video class” (incidentally both are wrong). We will not have enough
time to complete the identification of all attributes today but finding the main ones
will be sufficient to develop the first cut Class Diagram.

Time for this exercise 20 minutes


[14 Marks]
3. You are now ready to draw a class diagram for phase one of the RestEasy Hotels
project. Your class diagram must show the classes and the relationships between
them. Later the model can be refined to include attributes and methods. When
drawing lines from one class to another to documenting associations, remember the
four main ways of depicting multiplicity being one to many (1..*), zero to many (0..*),
zero or one (0..1) and one (1). It may help to follow these simple steps in identifying an
association:
 Draw a line between two classes where you feel there is an association
 Give the association a name (verb). Lets take an example where we have two
classes, Customer and Order and we have named the relationship “makes” (as per
the picture below).
Makes
Customer Order
 Now make the following statement
One Customer makes ……… Order (which of the four types of multiplicity described
above best fits the dotted line in this statement). By careful analysis of the order
process we find a customer may not have made an order or could have made many
so the relationship would be zero to many.
One Customer makes zero to many Orders
 Now test the multiplicity from the other side
One Order is made by ……… Customer (note we have changed the association
verb slightly for better reading). Here we should agree that a single customer makes
an order. The statement is therefore
One Order is made by one Customer. Now all we need to do is to add the
appropriate association symbols against the appropriate classes.

Makes
1 0..*
Customer Order

It is important that you work in rough until you have developed and refined your
model. You may want to keep your rough workings but only transcribe your solution
onto the space provided on the next page when you are comfortable with your
solution.
Time for this exercise 30 minutes
You now have a domain class diagram that documents the important concepts required by
the RestEasy Hotels Reservations and Billing System. We now need to refine this
diagram to represent the software classes involved in this subsystem and to ensure it can
accommodate the requirements documented in your use case model.

[20 Marks]
4. Now we are in the last stage of the process – refining our class diagram to produce an
analysis class diagram. Use the space on the next page to draw your analysis
class diagram. Start with your domain class diagram and look for the following
opportunities to better define these concepts as software classes. Use your
lecture notes where you need clarity on an issue and understand that not all of these
refinements will be required in this process:
 Decompose complex concepts
 Include “generic or specification” classes
 Identify where “tables” are required.
 Are there any associations that carry data and need associative classes
 Look for opportunities for reuse (Inheritance)
 Are there strong associations requiring Aggregation or Composition

Once you have implemented these refinements, you are ready to perform a walkthrough to
test the class diagram and see if it contains the classes, attributes and associations to
support your user requirements. We do not have detailed use case narratives at our
disposal but certain requirements have been taken out of the various use cases and listed
below. Take each item on the list and test whether your class diagram can support it.

1. Enquire about the room rate for a specified period (remember rates are seasonal –
low, medium or high).
2. Check room availability for a particular date.
3. Check whether a guest is currently in the hotel and indicate the room he/she is
occupying.
4. Allocate rooms the night before the guests arrive.
5. Have the flexibility to allow accounts to be generated across multiple rooms and
where rooms are shared by separate guests.
6. Identify which receptionist recorded a reservation and processed a payment.
7. Keep tabs on regular guests and those who are in “bad standing” (unpaid bills or
unacceptable behaviour).
8. Allow companies to negotiate special discounts on room rates for their employees.
9. Decommission 20 rooms over July to allow for refurbishment.
Time for this exercise 40 minutes

You might also like