这个类图正确吗？
我需要一些帮助来确认我是否走在正确的轨道上。 我为流行的在线购物场景制作了用例图和类图。
请仔细阅读并提出建设性的批评，让我谈谈你的看法，因为我还在学习 UML。
建模背后的故事如下所示：
该公司的名称是 X-company，他们从事销售 油漆。 X 公司有一个网站，将这些涂料在线销售给两个人 客户类型 - 零售商和批发商。 X公司有几个 目前的油漆颜色、尺寸、每种油漆类型的成本各不相同 这些特征明显不同。零售商可以登录 网站并以个位数购买油漆（例如 1 或 2 种油漆） 批发商以折扣价大量购买油漆的时间 10 种及以上涂料 10%，20 种及以上涂料 20%，30 种涂料 30% 油漆及以上。
网站已尽可能简单。客户可以到达 现场，选择油漆类型并显示其特征 油漆。如果客户访问购买，他们会选择 他们需要的数量。如果客户对价格满意，那么他们就会 确认他们的订单。确认后，网站会检查库存 油漆，看看是否有足够的油漆可用。如果有 不可用，客户会收到通知并要求选择另一个 类型。如果可用，客户提供支付卡 地址、卡号、卡密码等详细信息。付款完成 通过外部集成。付款后，客户的订单是 发送给客户，除非客户要求取消或 通过网站管理员下订单。
网站组织者或管理员负责添加新内容 油漆到网站并在有新油漆时取出旧油漆 油漆库存。
我画的类图如下所示：
I need some help to confirm I am on the right track with this.
I did a use case diagram and class diagram for the popular online shopping scenario.
Please look through it and criticize constructively, let me have your views on it as I am still learning UML.
The story behind the modeling is shown below:
The name of the company is X-company and they are into the sales of
paints. X-company has a website that sells these paints online to two
types of customers - retailers and wholesalers. X-Company has a few
paints currently which vary in color, size, cost each paint-type
obviously varying in these characteristics. Retailers can log into the
site and purchase paints in single digits (like 1 or 2 paints) at a
time while wholesalers buy paints in large quantities at discounts of
10% for 10 paints and above, 20% for 20 paints and above, 30% for 30
paints and above.The website has been made to be easy as possible. Customers get to the
site, selects the type of paint and is shown the characteristics of
the paint. If the customer accesspts to purchase they select the
quanitity they need. If the customer is ok with the price they then
confirm their order. on confirmation, the website checks for the stock
of paints to see if there are enough paints available. If there are
not available, the customer is notified and asked to select another
type. If they are available, the customer provides payment card
details such as address, card number, card pin. The payment is done
through an external integration. On payment, the customers order is
sent to the customer except if the customer requests a cancellation or
the order through the website administrator.The website-organizer or administrator is responsible for adding new
paints to the website and taking out old paints when there is a new
stock of paints.
The class diagram I have drawn is shown below:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为类指定单一名称。订单，不是命令。折扣，不是折扣。但是，如果您有一个类是订单的集合\列表，那么“订单”就可以了。
用户不能一次购买超过一种油漆！ Order 类应该有一个 Paint 集合，而不是单个 Paint 实例。
Paint、PaintType 的设计似乎不符合逻辑。我不明白为什么应该有不止一堂课。组合成一个Paint类。
我认为应该有一个 PaintStock 类。 Administrator类中的方法好像是对PaintStock做的事情，所以把它们移过来。 Administrator 类需要 PaintStock 引用，以便它可以调用 PaintStock.Add 等。
添加/删除绘制函数不适合管理员类。将这些方法放入 PaintStock 类中。
将 BulkBuyer 重命名为 Wholesaler
考虑一个 User 类。摆脱零售商和批发商。我不认为不同的课程有什么区别。在User类中创建一个BuyerType字段来区分。如果您的业务规则规定了基于零售商与批发商的购买限制，则这种简单的规则差异可以轻松地存在于一个类别中。
作为一般规则 - 这是一个很好的规则 - 不要存储计算结果。因此 Order.TotalCost 应该是一种方法而不是字段。
订单需要取消方法。不是管理员类。 Administrator 类需要 Order 引用，以便它可以调用 Order.Cancel。
Give the classes singular names. Order, not Orders. Discount, not Discounts. If you have a class that is a collection\list of Orders, however, then "Orders" would be fine.
A User cannot buy more than one kind of paint at a time! The Order class should have a collection of Paint, not a single Paint instance.
Paint, PaintType design does not seem logical. I don't see why there should be more than one class. Combine into a Paint class.
I think there should be a PaintStock class. The methods in the Administrator class seem to be things that are done to PaintStock, so move them over. The Administrator class needs a PaintStock reference so it can call PaintStock.Add, etc.
Payment class should be called CreditCardPayment given what's in it. I suspect that credit card is not the only way make payments. I'd make a Payment base class so we can easily expand the ways to pay later on.
Add/Remove paint functions are inappropriate for the Administrator class. Put these methods in a PaintStock class.
Rename BulkBuyer to Wholesaler
Consider one User class. Get rid of Retailer and Wholesaler. I don't see a difference worth different classes. Make a BuyerType field in the User class to differentiate. If your business rules dictate purchase limits based on retailer vs wholesaler, that simple rule difference can easily live in one class.
As a general rule - and it's a good one - do not store calculation results. So Order.TotalCost should be a method not a field.
Order needs a Cancel method. NOT the Administrator class. The Administrator class needs an Order reference so it can call Order.Cancel.