英文:
UML class diagram for online reservations, need some assistance
问题
以下是您要翻译的内容:
为了一个学校项目,我必须开发一个网站,用于处理一个度假屋的预订和预约。管理员可以将客户添加到CRM系统中。只有在此之后,客户才能使用他们选择的凭据进行登录。
当客户进行预订时,由管理员决定给予其状态,可以是:已接受,已拒绝或正在验证。最后一个是每个预订的标准状态。
在设计UML类图时,我发现了一些错误。
首先,对于项目,我们想要一个仅供管理员使用的列表,其中包含所有预订。但也需要一个列表,每个客户独立使用,以便操作更加便捷。
其次,项目需要一个CRM系统。其中包含所有数据,包括预订、客户、登录凭据(当然是哈希的!)
现在,如何在类图中表示这些内容?
首先,我尝试将所有客户和预订放入两个不同的ArrayList中,如附图所示。但我不确定如何从管理员的角度访问它们。
英文:
For a school project I have to develop a website that handles booking-reservations for one vacation house. The idea is that the administrator can add customers to a CRM-system. Only then, customers can login with their chosen credentials.
When the customer makes a reservation, it is up to the administrator to give it a status, which can be: ACCEPTED, REJECTED or VALIDATING. The last one is the standard status for every reservation.
Here the updated class diagram:
While designing the UML class diagram, I found some errors.
Firstly, for the project we wanted to have a list, available for the administrator only, filled with all reservations. But also a list, per customer, just for ease.
Secondly, for the project a CRM-system. Which contains all data, reservations, customers, login credentials (hashed of course!)
Now, how do I imply that, to the class diagram?
Looking forward to your answers!
Firstly I tried to put all customers and reservations in 2 different ArrayLists, as seen in the attached image. But I wasn't sure how I could access them from the administrator perspective.
答案1
得分: 0
如果你的UML图不包括ReservationSystem
类,那就错了。
顾客和管理员不应拥有任何列表。ReservationSystem
应该拥有。它应该公开允许不同角色查看、添加、更新和删除Reservation
实例的方法。私有实现可以使用Java List
,也可以选择使用任何其他集合来维护内存中的Reservation
实例或者使用关系型数据库来持久化它们。美妙之处在于用户不需要知道或关心你选择如何持久化数据。
顾客和管理员只是不同的角色。顾客应该只能看到自己的预订。管理员应该能够看到所有预订。
如果你同意这些想法,让你的UML图反映这些想法。
这是我可能会做的方式:
英文:
If your UML diagram doesn't include a ReservationSystem
class, you're doing it wrong.
Customer and Administrator should not own any lists. The ReservationSystem
does. It should expose methods that allow different Roles to view, add, update, and remove instances of Reservation
. The private implementation might use Java List
; it could choose to use any other collection to maintain instances of Reservation
in memory OR a relational database to persist them. The beauty is that users need not know or care how you choose to persist the data.
Customer and Administrator are just different Roles. A Customer should only see their Reservations. An Administrator should be able to see ALL of them.
Make your UML reflect these ideas if you agree.
Here's how I might do it:
Here is the Plant UML text file I created to generate it:
@startuml
!theme vibrant
title Reservation Class Diagram
class Customer #LightBlue
class Reservation #LightBlue
class ReservationManager #LightBlue {
reservationRepository
findAll()
findById()
saveOrUpdate()
remove()
}
class CustomerManager #LightBlue {
customerRepository
findAll()
findById()
saveOrUpdate()
remove()
}
interface GenericRepository #LightBlue {
findAll()
findById()
saveOrUpdate()
remove()
}
interface ReservationRepository #LightBlue
interface CustomerRepository #LightBlue
class InMemoryReservationRepository #LightBlue
class RelationalReservationRepository #LightBlue
class InMemoryCustomerRepository #LightBlue
class RelationalCustomerRepository #LightBlue
enum Role #LightBlue {
CUSTOMER
ADMIN
}
ReservationManager *-- ReservationRepository : "has a"
CustomerManager *-- CustomerRepository : "has a"
ReservationManager -up-> Role : "uses"
CustomerManager -up-> Role : "uses"
Reservation "many" o-right- "1" ReservationRepository : "persists"
Customer "many" o-left- "1" CustomerRepository : "persists"
GenericRepository <|-left- ReservationRepository : "extends"
GenericRepository <|-right- CustomerRepository : "extends"
ReservationRepository <|-- InMemoryReservationRepository : "implements"
ReservationRepository <|-- RelationalReservationRepository : "implements"
CustomerRepository <|-- InMemoryCustomerRepository : "implements"
CustomerRepository <|-- RelationalCustomerRepository : "implements"
@enduml
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论