Help on a Use Case Diagram
stevthym
I have the following Use Case study on which a Use Case diagram is
required. What I need is assistance on the selection of the actors...
Please can you advice which actors should be selected for this
prospect diagram?
Case Study:
Tracel and Tourism Ltd (TAT advertise and manage properties for rent
in popular holiday resorts arount the Eastern Mediterranean and black
sea coasts. Properties can be registered with TAT by their owners or
by an agent who acts on behalf of one or more owners.
When property owners or agants reg their property with TAT they must
provide info about their property, TAT staff will use this info to
complete an Accomodation Spec Form (ASF) An example of ASF is shown in
FIgure 1.
Historically TAT only used to deal with agents so the ASF was used to
store agent details and then list all details of properties from the
agent. More recently TAT has began to operate directly with owners and
so in these cases the owner is also considered to be the agent(they
assigned an Agent ID) and only one property is entered on the ASF.
For all properties a copy is made of the owner's details wich are
saved in the Owner File whilist the completed ASF is file by agent
name in property file.Agent's details are currently not stored
separately from the property details.
Customers will contact the TAT Enquiries Desk with general enquiries
regarding accom and availability. It is company policy that an enquiry
will always result in some form of communication back to the customer.
However due to the persuasive skills of the Enquiries Desk team
general enqueiries often also result in a booking
Bookings (either directly from a customer or through the Enquiries
Desk) will always be handled by the booking Dep. Property details and
retes are checked against the booking request provided by the customer
as is the availability of the prop. If everithing is in order then a
booking is recorded, the deposit is taken and the abailability of
property details will be adjusted accordingly. The customer will
receibe a confirmation of the booking.
If there are any probs with the booking the alternative accomd. may be
offered but on the rare occasion that a booking can't be made the
customer is sent a cancellation notice and their deposit refunded.
All Payments to TAT must be taken through the Acc Section. Deposits
sent with bookings will be directed there and also customers who are
making advance payments for their accomodation will send payments
directly to the Acc sec. Receipts are issued for every payment
received.
The Accounts Section also handles payments of rental fees to owners
and agents. At the end of Each month the Acc Section will calculate
the rental income generated by the property subtract is commission
(usuallu 2.5%) and send the remainder to the owner. In the case where
an agent has provided the property details payment sent to the agent
rather than teh owner. This allows the agent to subtract their own
fees before sending the remainder to the owner.
H. S. Lahman
> I have the following Use Case study on which a Use Case diagram is
> required. What I need is assistance on the selection of the actors...
> Please can you advice which actors should be selected for this
> prospect diagram?
>
The purpose of these forums is not to do your homework for you; that is
part of the learning experience. However, I will provide some general
comments that might be useful.
Use cases describe *interactions* between the software and the outside
world. So the first thing you need to do is figure out what activities
will be done by the software and what activities will be done by people.
That is, you need to separate activities that people will do to prepare
for interacting with the software. Those activities can be ignored
because all you care about in the use case is the end interaction after
that preparation.
[In some situations one needs to understand those preparations simply to
decide what functionality the software can automate. But that is a
separate issue for requirements analysis. Use cases are only about
requirements specification once one knows what the software requirements
actually are. As it happens, your case study seems to be aimed at
requirements analysis as well as specification because it does not
already provide that separation in an unambiguous way. IOW, the case
study reads more like an overall problem specification where the student
needs to figure out what the software should do and, consequently, what
the interactions are.]
So the focus in determining actors lies in analyzing the interactions
across the boundary between the software in hand and the entire outside
world. One uses actors to organize interactions that are logically
related by context. The notion of 'actor' is useful for that purpose; it
provides a convenient mnemonic for interaction context. But that's all
it really is: a device for organizing interactions with the software
with respect to problem space contexts. Generally the software will be
more robust in the face of volatile requirements if one can map that
device to something stable in the problem space. People with specific
job titles using the software often provide that mapping conveniently.
However, one should not get hung up on the idea that actors are software
users. Most of them will be, but there are many other contexts for
interactions. For example, in R-T/E the hardware is almost always an
actor relative to the software because it provides messages like
interrupts. It is also common for other software to be an actor so long
as it is not part of the software in hand that is being designed. Thus
if the software for your Accounts Section was not part of the software
you were designing, it would be an external actor. The key idea is that
an actor is any external entity that somehow interacts with the software
in hand.
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html