我正在为面向对象的设计模块进行大学作业。在对名词和动词进行语言学分析并确定用例之后,现在正在制作类图。
程序的相关部分如下:
该程序供商店员工使用。这里有代表商店商品的产品清单。每个产品都有唯一的详细信息,包括相关的供应商和交付公司(可以具有称为“外部公司”的父类)。
还应该具有跟踪订单的功能(但不能下订单)。要求不包括每个产品的多个订单;每个产品一次只能进行一次重新库存。
这使我认为与产品订单相关联的任何详细信息都可以列为该产品对象的属性,而不是链接到该产品对象的订单对象的属性。如果每个产品有多个订单,我肯定会在产品列表之外再创建一个订单列表,但是每个产品只有一个。
问题是具有所有产品属性(名称,重量,保质期,ID,单位成本,销售速度,照片等)和所有订单属性(估计订单日期,订单金额,交货日期,欠款额供应商,最后订购日期),因为产品的属性会使产品类别繁琐。或者,将它们分为两类可能会产生冗余。此外,大多数订单“属性”实际上是使用产品属性而非“基本属性”(对不正确的术语表示歉意)执行的计算结果。
类图的选项如下所示。请原谅我缺乏细节,因为这只是一个可视化上面问题中的内容的模型。
选项1:
选项2:
将非常感谢您对选择哪个(如果有的话)类图的任何帮助,并且在阅读问题时想到的任何其他信息也将不胜感激。
成功进行OO设计的关键是separation of concerns。这意味着,如果您知道某些产品固有的东西,而其他与该产品的订单有关的东西,则应将它们分开。
现在,在使用ERP 20年之后,我可以告诉您,一次只下订单只是一种暂时情况。迟早,您将需要发展,因此请更好地预测是否显而易见。因此,选项2是可行的方法。
现在您应该在图表中做几件事:
Product
,Order
,Supplier
和External Company
之间的关联与您的叙述不符。您说每个产品都有一个关联的供应商和交付公司。因此,两者之间应该有直接的联系。您还说过,供应商可以将外部公司作为母公司。因此,可能会有没有任何外部母公司的订单。 现在,最后一件事:我不知道您的分配情况,但是我建议您专注于域类并放出GUI。为什么呢因为一旦您开始使用GUI,您肯定会拥有与产品列表以外的其他东西相关联的GUI子类。实际上,我发现它具有误导性。