Tutorial 4 - Actors AND USE Cases PDF

Preview

Summary

18329328OOA: Tutorial 4 – Actors & UseCasesGROUP WORK: Identify actors for the Great Western Real Estate Management System (GWREMS) (minimum five actors per package based on the packages identified in project work of Week 3). This will result in identifying minimum five actors per student, a...

Description

Derick Tran 18329328

OOA: Tutorial 4 – Actors & Use Cases GROUP WORK: 1. Identify actors for the Great Western Real Estate Management System (GWREMS) (minimum five actors per package based on the packages identified in project work of Week 3). This will result in identifying minimum five actors per student, as one student is the primary owner of one package. Please note that all students in the team should discuss together regarding to the list of actors as some actors could be associated with multiple packages. - Administrator (Office assistant) - Agent - Clients - Front/back end website (GWRE Management System) - Financial Management system 2. Document all import and complex actors using the actor documentation template given in the lecture notes (Lecture 4). Save you work in a WORD file (the refined version will be integrated in the final project report).  







Actor Thumbnail o Actor: Client Actor Type & Stereotype o This is an abstract actor representing all clients in the Great Western Real Estate Management System Actor Description o The actor client is the primary role interacting with the GWREMS in order to carry out all functions related to the client. This actor will primarily use the system to search for properties, search for agents, create buying requests, register to buy properties, set online/onside sales, make offers, setting online auctions, participating in online/onside auctions and creating selling requests on their properties. For all these functions, the actor will have to register him/herself and also identify themselves every time the system is to be accessed. Actor Relationships o Actor will interface with the following Use Cases  RegisterClientDetails  SearchProperties  SearchAgents  RegisterPropertySale  MakeOffer  ParticipateAuction  RegisterPropertyPurchase Interface Specifications Page 1 of 8

Derick Tran 18329328 o o o o

 







3.

Login PropertyRegistrationForm FinancialManagementSystem ClientRegistrationForm

Actor Thumbnail o Actor: Agent Actor Type & Stereotype o This is an abstract actor representing the agents in the Great Western Real Estate Management System Actor Description o The actor agent interacts with the GWREMS in order to carry out real estate as well as administrative functions. These functions include checking/responding to requests made by clients, updating property statuses for clients, running auctions, updating their own details on the system and following up with clients. The agent is registered as a staff member, and must require a valid login and password to access the system. Actor Relationships o This actor inherits from Staff o Actor will interface with the following Use Cases  CreateClientProfile  CreatesPropertySale  CreateAuction  UpdatePropertyDetails  CreateAgentProfile Interface Specifications o Login o PropertyRegistrationForm o FinancialManagementSystem o ClientRegistrationForm

Identify a basic list of use cases for your package. There is a requirement of creating at least five use cases per package. For a team of four students, at least total of 20 use cases should be documented. Do note that this list may contain include and extend use cases.  RegisterPropertySalePhone  SellProperty  RegisterPropertyPurchase  ContactAgent  RequestInformation

4. Document TWO use cases per package (per student) based on your above work. The use case documentation should contain at least Use Case Thumbnail, Use Case Description, Stereotype Page 2 of 8

Derick Tran 18329328 and Package, Actors, Pre-condition, Post-condition, Normal Flow and Alternative Flow. Save you work in a WORD file (the refined version will be integrated in the final project report).  Use Case Thumbnail: o RegisterPropertySalePhone  Use Case Description: o This use case deals with registration of new properties into the GWREMS. These registration details include, address, size, bedrooms, other details on the property and potentially the Agent as well as the expected prices. The Client provides all these details to the administrator to be entered into the system. The AgentDatabaseSystem is an interface to an internal system, which is provided by Agents within the business to verify valid agents within the agency.  Stereotype and Package:  Pre-Conditions: Client must not have their property currently listed with GWRE.  Post-Conditions: Client has their property listed with GWRE  Actors: o Client o Administrator o Agent  Use Case Relationships: o SearchProperty  Basic Flow: 1. Client contacts GWRE to have their property listed to sell 2. Administrator asks client if they have previously had a property listed with us. (A1) 3. Client provides answer 4. Admin asks client for details on property such as size, address, location. 5. Client provides details as requested 6. Admin enters details into system 7. System verifies details 8. Admin asks if they would like to allocate an Agent or to allow agencies to approach with selling requests 9. Client provides answer [Agent] a.Admin asks for agent name b.Client provides the name c. Admin enters the name into system d.System verifies agent with AgentDatabaseSystem (A2) [No Agent] a. Admin confirms that client will giving property details to all agencies to try to obtain offers. b. Client confirms. 10. System saves property details 11. System then confirms property details 12. System notifies Agent or Agencies that the new property is listed. 13. Agent/Agencies receive notification with details to contact client. Page 3 of 8

Derick Tran 18329328 

Alternative Flow: A1. Client has never had a property listed with GWRE, will require to be set up as a new client. The administrator informs the client to begin registration. A2. Agents name does not exist within the database, client is requested to provide an agent identification number or advise the agent to contact us directly as they may not be within our system.

Use Case Thumbnail: BookAppointment Use Case Description: This use case describes the process which Client is able to book an appointment with an Agent. This process would require the Client to search for information on properties they would like to purchase, then search for the information on the respective agents availabilities on a particular day and time. The system will help provide alternatives and the Client will select from these alternatives. Stereotype and Package:

Pre-conditions: Client is already registered into the system Post-conditions: Client is given a date and time of their appointment. Actors:  

Client Administrator

Use Case Relationships: 

UC-ChecksCalendar

Basic Flow: 1. 2. 3. 4. 5. 6. 7. 8. 9.

Client searches for property they are interested in purchasing Finds the contact information of the respective Agent Client requests an appointment with an Agent to the admin Admin enters the property into the system System provides a list of agents and available appointment times for the specific property. 5.1. UC-ChecksCalendar Client selects the Agent and Preferred time (A1) Admin enters selected Agent and time into the system System schedules the appointment and updates that agents personal calendar System confirms appointment time, location and agent. Page 4 of 8

Derick Tran 18329328

Alternative Flow: A1. None of the offered times and doctors are acceptable for the client, so the client cancels their request.

 

   

 



 



Use Case Thumbnail: o MakeOffer Use Case Description: o This use case describes the process which Client is able to make an offer to GWRE following receiving an invitation. This process requires a client to be logged in to create a formal offer, they will then receive a response from the owner via the agent. Stereotype and Package: Pre-conditions: Client is logged into their approved account and has been given an invitation Post-conditions: Property deposit is paid and “sold” Actors: o Client o Owner o GWREMS Use Case Relationships: o UC-MakePayment Basic Flow: 1. Client receives an invitation to purchase a property 2. Client logs into their account on the GWRE 3. Client responds to the invitation through the GWREMS with an offer (A2) 4. Owner receives offer from this client with an expected price 5. Owner accepts the offer via their agent or the GWREMS (A1) 6. Client receives acceptance so the property changes to “under contract” on the GWREMS 6.1. UC-MakePayment 7. The property status changes to “sold” on the GWREMS Alternative Flow: A1 – Owner requests to give a new offer, moves back to step 3. A2 – Client cannot meet the new offer, cancels deal.

Use Case Thumbnail: o RegistertoBuy Use Case Description: o This use case describes the process which Client is able to register themselves to purchase specific types of properties through different types of sales. Stereotype and Package: Page 5 of 8

Derick Tran 18329328   

 



 

   





Pre-conditions: Client needs to have been registered with the GWREMS Post-conditions: Client is registered to receive information about properties. Actors: o Client o Agent o GWREMS Use Case Relationships: o UC-ClientLogin Basic Flow: 1. Client is registered and logged into the GWREMS 2. Client clicks through to register themselves to be contacted in regards to specific properties 3. GWREMS receives this information and reaches out to client for other information required 4. Client completes registration 5. GWREMS adds client to the list for certain properties. (A1) Alternative Flow: A1 – GWREMS already has their types of properties listed and contacts the client. Client then may request documents, or book appointment -BookAppointment. Use Case Thumbnail: o SettingOnlineSale Use Case Description: o This use case describes the process which a client advises GWREMS of a sale and the system announces the sale of the property to registered and interested clients. The clients then send offers mediated by the GWREMS and rejected or approved by the seller. Stereotype and Package: Pre-conditions: Seller needs to be registered with the GWREMS Post-conditions: Offer has been taken or a new round of negotiation Actors: o Seller o Buyer o GWREMS Use Case Relationships: o UC-ClientLogin o UC-MakeOffer o UC-RegistertoBuy o UC-MakePayment Basic Flow: 1. Seller is registered and logged into the GWREMS 2. Seller registers property for purchase 2.1. UC-RegistersProperty

Page 6 of 8

Derick Tran 18329328



3. GWREMS approves property for purchase placing it in the system and sending invitations to interest parties. 4. Buyers receive invitation and log in to make offers to the seller. 4.1. UC-MakeOffer 5. GWREMS records all the offers and records and analyses them before sending them through to the seller. 6. Seller rejects all offers and sends invitation for next round. (A1) 7. Buyers receive invitation and make new round of offers. (A2) 8. Seller rejects all offers and sends invitation for further negotiation with remaining buyers. (A3) Alternative Flow: A1 – Seller makes deal with one of buyers to purchase the property. A2 – Buyer does not make an invitation and drops out of the deals A3 – Seller takes an offer from a buyer.

TUTORIAL WORK: 1. Can an indirect actor be a primary actor? Yes indirect actors can be primary actors. As primary actors are considered main actors who benefit from the system and indirect actors are considered those who do not use the system, but are assisted by a direct actor. An example of this would be a customer, who benefits from the system, whilst still being assisted by directed actors.

2. Briefly explain strengths and weaknesses of use cases. Strengths 1. Models the Important user as Actor 2. Organises Requirements 3. Facilitates communication 4. Documents all Functionality 5. Reuses and extends requirements 6. Facilitates Traceability of Reqs. 7. Provides System context/Boundary Weaknesses 1. 2. 3. 4. 5.

Not object-oriented Have no documentation standards Imprecise Relationships Granularity is subjective Has no Flow of use cases

3. Show the actor hierarchy in GWREMS.

Page 7 of 8

Derick Tran 18329328

Page 8 of 8...