面向对象设计问题在访谈中的应用

Question

我是一个软件开发人员，有2年的经验。我参与了几个“小”模块的设计和开发。

我最近一直在接受技术面试。我被要求对各种问题进行模型设计(例如Apple推荐系统等)。到目前为止，我的专长是开发相对较小的模块。我想提一下我如何处理手头的设计问题：

(1)识别最基本的用例。

(2)基于行为对系统进行动态建模(如协作图)。

(3)根据第2步的动态建模绘制类图。

(4)找出更多的用例并迭代这个过程。

(5)当我感到满意时，我要求我的同龄人对它进行审查。

虽然到目前为止，我在我的项目中做得很公平，但是面试官对这种方法并不满意。当我为一个大问题做模特时，我是不是错过了什么？

我会感谢你的指点。

P.S.：我不从类图开始，因为我通过这样做找到了非常集中的体系结构，而动态建模帮助我分散了设计。

Answer 1

您是否曾被要求进行高层模型(模块)设计或低级别模型设计？对于高层模型设计来说，解决一个大问题或领域是一个好主意，因为对于低层次模型设计来说，通常需要较小的问题或领域。

通常，需求/问题来自询问者(用户/面试官)，因此我们不再需要定义业务需求。但我们仍然需要设计系统。

高级模型

我不太熟悉"Apple推荐系统“，所以我会使用不同的问题类比，那就是常见的Point Of Sales问题。对于高级模型，您将定义整个系统。通常是关于：

• 定序
• 批复令
• 首期付款
• 货物交付
• 返回

这都是高级别的模型/模块。如果有人问我如何实现这个模型，下面是我要做的步骤：

1. 定义用户和系统之间的标准用例
2. 将用例倾注到一些协作关系图中，如富图片(或任何熟悉的)
3. 定义异常用例。如果可以很容易地定义异常，就立即进行建模。如果没有，则将模型标记为例外情况，以便与业务团队进一步讨论。 一些用例例外情况可以是更改所承诺的订单，在定金后更改所承诺的订单，取消付款订单，缺货等。
4. 迭代这个过程。通常，步骤3可以成为步骤1(异常可以/将是另一个用例)。 例如，更改提交的顺序可以是用例，因为发生的变化很大。
5. 当第三个用例完成时，没有额外的用例异常(所有用例都已处理)，通常我会添加value-additional operations。 这些操作可以是通知(电子邮件/屏幕上)、历史数据维护、提醒、错误处理等。一些操作也可以是另一个用例，所以您可能需要迭代到第1号。 例如，当您在首付款结算过程中遇到错误时，可能需要另一个用例来手动输入首付款数据。或者您可能需要在另一个系统中维护提醒系统。
6. 移至低层模型

对于其他信息，我通常使用状态图来表示用例/功能，例如order状态。

低层模型

低水平模型将从高层次解决较小的问题。简单地说，您从高级别(可能是订购)获取一个用例，然后从它开始设计低级别。我通常使用某种形式的序列图来处理，而不是先定义类图。以下是一些原因：

1. 序列为您提供了关于获取输入、获取数据和提供响应的并发视图。
2. 它很好地描述了与其他系统的关系，如数据库和webservice。
3. 它可以为您提供关于入口点或接口的图片，这些图片对于应用程序的基本架构非常有用。
4. 您可以将类图作为基础，在序列设计过程中很容易地发现缺陷，而不是类图。

然后我将继续进行系统状态图(可编辑、可查看等)。

最后，我将继续database design和class diagram。

为什么类图在最后一步？

类图(和数据库设计)非常依赖于整个过程。并发发生的方式、通知、外部系统交互等都会影响接口和类图的设计。这也是最近的设计与您的代码库。

希望这个帮助，这完全是我的经验和意见。

Answer 2

我想说的是，也许你应该给出一个总体的观点/概述，然后再做更深入的研究。就像您给出的"Apple Genius推荐系统“的示例一样，我认为您应该从总体设计(系统的总体情况)开始，以便确定系统的适当架构，例如确定需要哪些组件、哪些协议等等。您需要识别组件、连接器和这些组件的配置。然后，通过提出模式和工具，您可以开始深入研究。最后，用场景、用例等对体系结构进行验证。

Answer 3

我认为你的方法可能会错过非功能性需求。我还要提到如何捕捉这些信息。