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