Hello!
I have a Case Study Scenario for which ERD & Use Case Diagram are required. My question is... Should Use Case Actors be the same number of Entities into ERD? E.g. If i have 5 actors in UML it means that I should also have 5 entities of these actors into UML plus what else entities would come out?
Kalimera, ti kanis (supposing you are living in the south part)
UML-CS Actors could also be entities on ERM (and tables on RM later) depending on their relevance and scope of their data. Usually they are attributes of an entity named ACTOR, if necessary.
If you had disclose some more details on your project, I would have given you better guidance.
-- tesu
Kalimera! Well yes I am in the south part :) Where are you? (north one?)
Anyway, I have the following case study where I am working for Use Case Diagram and ERD diagram as well. I have also to prepare a DFD. With DFD I am confident as I know how data flows within the system. My concern is:
1. Which actors should be included into Use Case Diagram?
2. Which entities should be included into ERD?
I am not asking for solution in the whole thing but If I could have a second opinion for 1 & 2 then I would be confident for my solution.
Many thanks in advance!
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.
ochi, ime stin germania (bavaria). ya diakopes tha imai sti aegeou (limou, lesvou, shiou.. kathe xrono).
From your text one can draw some actors / roles which also become classes in OOA:
TAT staff (employees, role: Enquiries Desk)
owners
agent(s)
Properties
holiday resorts (two at least)
Customers
Mapping them into ERM (later database) all of them become entities and later tables.
I myself switched to visual paradigm tool recently, which allow designing both UML 2.0 and also ERM (Chenn) diagrams. Do you know it?
You may post your use case diagram.
-- tesu
Thanks for your feedback! But... in a use case diagram aren't we searching for actors interacting with the system? So properties and holiday resorts could not be actors into a use case diagram...
You are right!
Drop both from the list. I already kept the ERM design in mind when writing them down.
You are right!
Drop both from the list. I already kept the ERM design in mind when writing them down.
OK, Can you then assist with:
1. Recommended actors for Use Case Diagram.
2. Recommeneded entities for ERD
please....
Of course!
Nevertheless, you might post in what you have got so far. I don't like to give you complete solution based on your rather complete proposed paper.
-- tesu
Well firstly for UML... I selected Agent and Owner to be different actors but then I realized that they provide information to a Stuff who then uses it so as to create a form and interact with the system... So Agent and Owners are not actors?
If both Agent and Owner don't act with the system for they only fill in forms from which data will be captured by staff personal they aren't direct actors. Therefore they don't have use cases. For that reason I would omit Agent and Owner.
-- tesu
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.