我有一个涉及自动售货机的场景，然后要求我们创建问题域＆＃34;模拟问题域＆＃34;。我非常松散地介绍了建模，并希望有人能清除它。
从研究看起来，问题领域只是一个领域模型，而这又是一个UML类图。
我见过的例子看起来几乎是数据库模式，包括客户实体，订单实体等等。
我不确定这些差异究竟是什么。
所以我只是想知道我是否走在正确的轨道上，是否有人会想到详细阐述这一点，或者可能指向一个简洁的定义。感谢。
答案 0 :(得分：1)
“问题域”只是你感兴趣的东西。在你的情况下，它是自动售货机所做的所有事情，以及与之交互的人。
它归结为一组用例，可以在用例图中绘制。自动售货机做什么？它从买家（演员）获取硬币，给予改变（可能......所以确保你理解“扩展点”），吐出东西（总是，因为我们不在现实世界中），等等。那么也许你可以通过不同的演员获得创意。维护人员拿出钱，增加更改，填满机器，运行诊断堆栈等等。其中每一个都是一个用例。将它们放在一个用例图中。
如果您想详细了解每个用例的功能，请使用活动图。每个用例一个。
答案 1 :(得分：1)
任何系统（软件与否，建模与否）都具有结构和行为方面。
结构方面是系统的非时间限制方面，例如系统由哪些类组成，它们的关联和依赖关系，它们如何划分为子系统等等。大多数这些元素通常被称为分类。
行为方面显示了这些结构方面如何随着时间的推移协作以实现系统的目标，例如方法，状态机，工作流，用例实现等。
结构和行为方面是您在编写代码或创建模型时指定的方面。
对象，按定义是类的实例。这意味着对象是＆＃34;事物＆＃34;系统执行时实际存在的。因此，您不编写对象;编写一个类，它在执行时被实例化为一个或多个对象。
但是，在许多建模语言中（但在编程语言中并不常见），您还可以对场景规范进行建模，这些场景显示对象的规范以及它们如何交互，例如在UML中您可以创建一个对象图，显示一个示例如何在执行期间构建和协作对象系统（即实例化类）。
现在，系统总是努力实现一个或几个目标。周围环境由人和/或与系统交互的其他系统（演员）组成。这＆＃34;周围＆＃34;或者＆＃34;背景＆＃34;，系统所处的位置和意义，通常被称为＆＃34;域＆＃34;。
这些＆＃34;演员＆＃34;有一个＆＃34;问题＆＃34;他们希望系统能帮助他们解决问题。当对这个问题进行建模时，可以调用一个模型来解决问题域模型＆＃34;对于系统。它陈述了问题域的逻辑结构和行为方面，而没有说明如何在系统的特定实现中实现它。即，它不是指实现方面，如Java，SQL，主键，事务，反射，角度等;相反，它专注于域名的核心结构，如订单，缔约方，合同，产品等。
问题领域模型是最重要的合同之一＆＃34;系统开发人员与支付系统的人员或系统的所有者和用户之间的关系。它使您能够以相同的方式理解要解决的问题，并确保您都使用相同的概念来推理它。根据定义，它不是技术人工制品，您应该使用尽可能简单的符号（但仍然严格和清晰）来描述它，以便非软件专业人员也能理解并同意它。类图（从所有技术细节中删除）和用例图是两种可用的表示法技术。但是对象图和活动图也可以派上用场。
如果您对此感兴趣，我将在Udemy上提供高级概念域建模课程。这是链接和90％的代码：https://www.udemy.com/get-your-concepts-straight/?couponCode=CONCEPTS29
此致 每