我是一名有2年经验的软件开发人员。我参与了几个“小”模块的设计和开发。
我最近一直在接受技术面试。我被要求对各种问题的设计进行建模（例如 Apple Genius 推荐系统等）。到目前为止，我的专长是开发相对较小的模块。我想提一下我如何处理手头的设计问题：
(1) 识别最重要的用例。
(2) 根据行为对系统进行动态建模（如协作图）
(3) 根据步骤 2 中完成的动态建模绘制类图。
(4) 找出更多用例并迭代这个过程。
(5) 当我感到满意时，我会请我的同行对其进行审查。
虽然到目前为止我的项目做得足够好，但面试官对这种方法并不满意。我在为一个大问题建模时是否遗漏了什么？
我会很感激任何指示。
PS：我没有从类图开始，因为这样做我发现非常集中的架构，而动态建模帮助我分散设计。
我想说，也许你应该给出一个一般的观点/概述，然后再深入一点。就像您给出的“Apple Genius Recommendation System”示例一样，我认为您应该从总体设计（系统的大图）开始，以确定系统的适当架构，例如确定需要哪些组件，什么协议等。您需要识别组件、连接器和论文的配置。然后，您可以通过建议模式和工具开始深入研究。最后，通过场景、用户案例等验证架构。
您是否被要求进行高级模型（模块）设计或低级模型设计？解决高级模型设计的大问题或领域是一个好主意，因为对于低级模型设计通常需要较小的问题或领域。
通常需求/问题来自提问者（用户/面试官），因此我们不再需要定义业务需求。但是我们仍然需要设计系统。
高级模型
我对“Apple Genius Recommendation System”不太熟悉，所以我将使用不同的问题类比，这是常见的Point Of Sales问题。对于高级模型，您将定义整个系统。通常大约：
这就是所有高级模型/模块。如果有人问我如何实现该模型，我将执行以下步骤：
定义异常用例。如果可以轻松定义异常，请立即将其用于建模。如果没有，请将模型标记为案例例外，以便与业务团队进一步讨论
一些用例例外可能是更改已提交订单、在首付后更改已提交订单、取消已付款订单、商品缺货等。
迭代过程。通常第 3 步可以变成第 1 步（例外情况可以/将是另一个用例）
例如，更改的已提交订单可以是一个用例，因为发生的更改很高。
当第 3 次完成而没有额外的用例异常（所有用例都已处理）时，通常我会添加value-additional operations.
这些操作可以是通知（电子邮件/屏幕上）、历史数据维护、提醒、错误处理等。一些操作也可以是另一个用例，所以也许你需要迭代到第一。
例如，当您在预付定金结算过程中遇到错误时，您可能需要另一个用例来手动输入预付定金数据。或者，您可能需要在另一个系统中维护提醒系统。
移动到低级模型
对于其他信息，我通常将状态图用于用例/功能，例如订单状态。
低级模型
低层次模型将从高层次解决更小的问题。很容易说，您从高层（可能是订购）获取一个用例，然后从它开始设计低层。我通常不会先定义类图，而是使用某种形式的序列图来解决。以下是一些原因：
然后我会继续系统状态图（可编辑、可查看等）。
最后，我会继续database design和class diagram。
为什么类图在最后一步？
类图（和数据库设计）非常依赖于你的整个过程。并发如何发生、通知、外部系统交互等都会影响接口和类图的设计。它也是与您的代码库最近的设计。
希望这能有所帮助，这完全是我的经验和意见。
我认为您的方法可能会错过非功能性需求。我还要提到如何捕获这些。
从我从您的问题中收集到的信息是，您要求的是“模型”，而不是您概述的“方法”或“过程”。
因此，他们所要做的就是设计（可能使用 UML）Apple Genius Recommendation System 可以处理各种问题的场景。提示，如果是这种情况，设计的主要部分是有一个名为Problem的接口，其中包含与问题相关的核心接口方法。例如，getSeverity、getDescription、getDateReported、getDateSolved等。当然，他们将需要与此接口协作的其他类来完成设计。
希望以上对你有所帮助。