我正在尝试在汽车经销商的UML中绘制域模型或类图。我坚持如何在模型中呈现试驾。一种方法是预约类，然后测试驱动器作为子类。经销商还提供售后车辆服务，因此我可以将预约/预订等级作为超级等级，然后将车辆服务和试驾作为两个子类别。
另一种方法是让客户类与预约类下的试驾类和车辆服务类有直接关系。
经销商还销售新车和二手车及其零件。
经销商还为汽车销售提供融资。
testdrive类与车辆类有关系，还是有单独的类用于显示和testdrive类？
另一个问题是如何在模型中展示潜在客户及其有关销售和服务的查询。如果经销商允许营销，他们希望保存潜在客户的详细信息。我应该有两个类：一个用于客户，一个用于潜在客户，或者只能通过在客户类中使用属性来实现？
答案 0 :(得分：2)
您实际上只能通过拥有一组良好的用例或模型的预期行为来区分正确的决策。
这将告知特定的子分类是否真的准确。
我可以看到预约可能包含多个试驾，这些试驾本身与个别车辆相关联。因此，试驾本身只不过是从客户到车辆的链接，这些链接与约会有关。 / p>
答案 1 :(得分：0)
test-drive将包含仅与测试驱动器相关的信息：
对客户的引用 - 即使这可能是有争议的，包括
参考车辆
试驾时间
位置（也许车辆的驾驶位置不同于拥有预约所确定的位置）
客户温度（热或冷 - 即客户看起来很热情）
评论
等
但是测试驱动对象中没有的是与约会相关的任何内容 - 因为它总是包含在集合中 - 可能作为约会或其他事件容器的一部分。现在，如果可以包含测试驱动器的容器始终包含客户信息，我甚至可能不会在测试驱动对象中包含客户引用 - 毕竟，它将是多余的。
这取决于测试驱动器是否可以在非预约场景中发生 - 可能是在“销售活动”或“开放日”或者在用例中实际未创建约会的情况 - 或者是多个测试驱动器客户将在容器内发生。
答案 2 :(得分：0)
您的问题的第二部分已被遗忘（当您在一个问题中轻松完成时）：
另一个问题是如何在模型中展示潜在客户及其有关销售和服务的查询。如果经销商允许营销，他们希望保存潜在客户的详细信息。我应该有两个类：一个用于客户，一个用于潜在客户，或者只能通过在客户类中使用属性来实现？
我认为您的用例是“经销商希望保留潜在客户的详细信息，如果他们允许营销目的。”最简单的解决方案是拥有一个邮件列表集合，其中包含每个潜在客户的姓名和地址。
答案 3 :(得分：0)
我想你错过了重点。域模型的目标是让您熟悉域名：
-- What kind of entities you have in yor domain?
-- If they are important for your system under desing,
what kind of properties they have, how they behave?
-- What kind of business rules they obey?
其余的是细节。像地图制作者一样思考。记录下有什么。创建一个简单的地图，这样你就不会迷失在那个领域。不要试图发明。结构域中存在的东西：不是在你自己创造的“花哨抽象”背后运行。
域模型可以用作源 用于面向对象的分析/设计。 但他们的目标不是代表 软件抽象。