电子商务网站的 UML 类图？
下图是我第一次尝试创建类图和描述电子商务或在线购物的用例图。
我确信它的设计很糟糕并且充满缺陷，但我希望向你们学习如何设计它。我对您对设计模式的使用以及您将使用哪些模式、如何在设计中实现它以及原因特别感兴趣。
任何建议、批评、意见和建议将不胜感激。提前致谢。
The diagrams below are my very first attempt at creating a class diagram and the use case diagram describing an E-commerce or Online shopping.
I'm sure its a poor design and full of flaws, but I'm hoping to learn from you guys how you would design it. I'm particularly interested in your use of design patterns and which patterns you would use, how you would implement it in the design, and why.
Any advise, criticisms, comments and suggestions will be really appreciated. Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
令人印象深刻且全面，我想说你走在正确的道路上。我没有看到任何重大失误会阻碍您继续定义序列图。我下面的评论只是一个意见，可以以任何方式进行辩论。
您显示了 storeList 和 ProductList 之间的关联，如果您使用产品主列表（例如母公司和特许经营店）跨商店追踪相同的产品，这是有意义的，但您的商店看起来并不相关那样。
如果您要为货币设置一个类，请继续将价格设置为一个单独的类。这将使处理价格变化（例如折扣）变得更加容易。此外，您只显示每种产品可能使用 1 种货币，那么以多种货币销售怎么样？您需要将销售交易视为与库存不同的独立领域。产品本身没有标有价格（通常），价格是分配给它的并且可以更新，更不用说随着时间的推移或由不同的商店以不同的价格出售相同的产品。您需要的是一个库存清单，其中包含产品 ID 的属性、当前售价以及可能需要的任何折扣的属性，以及一个历史文件，其中包含库存清单的所有更改，以便您需要检查商品价格时使用。过去的销售。
出于与价格相同的原因，请继续将所有产品描述属性移至 ProductDescription 类，例如颜色、尺寸、重量等。这样，如果产品需要自定义属性类型（一家商店同时销售汽车和软件），您仅子类化 ProductDescription 类，而不是 Product 类。
Impressive and comprehensive, I'd say you're on the right track. I don't see any large missteps that would hold you back from moving on to define your sequence diagrams. My comments below are just an opinion and could be debated either way.
You show an association between the storeList and ProductList, which makes sense if you are traking the same products accross stores with a master list of products, like with a parent company and franchised stores, but it doesn't look like your stores are related in that way.
If you are going to have a class for Currency, go ahead and make Price a separate class. This will make it easier to handle changes to prices, like discounts. Also, you show only 1 currency possible per product, what about selling in multiple currencies? You need to think about the sale transaction as a seperate and distinct domain from inventory. A product itself doesn't have a price stamped on it (typically), it is assigned to it and can be updated, not to mention that the same product could be sold for different prices over time or by different stores. What you need is a stock list that contains attributes for product id, the current selling price, and attributes for whatever discounts might be needed along with a history file that contains all changes to the stock list for when you need to check a price on a sale from the past.
For the same reasons as Price, go ahead and move all product description attributes to a ProductDescription class, e.g. color, size, weight, etc. That way if products have a custom attribute type needed (one store sells both cars and software), you only subclass the ProductDescription class, not the Product class.