自上而下的设计

自上而下的设计

在软件开发中，您可能会在许多文章和书籍中读到，设计应该是重中之重。一个好的设计可以解决很多问题。该设计将为开发人员带来更多清晰度。它将提供有关确切要求的详细信息。在本文中，我将讨论自上而下的设计方法。我将通过电子学习的例子逐步解释。

一个问题必须从多个层面来看待。它们中的每一种都有其优点。软件设计或开发的不同级别如下

• 大局或主题。
• 模块/系统。
• 子模块/子系统。
• 特征。
• 子功能。
• 商业规则。

大局观

从大的角度来看，这是一种商业目标。重要的是回到业务目标。最终，我们所做的一切都是为了更好的商业目标。因此它将获得更高的优先级。您做出的所有决策都必须映射回业务目标。为了理解自上而下的设计，让我们举一个例子并进行深入研究。

我有电子学习领域的背景。对我来说，设计过程很容易产生共鸣。在电子学习应用程序中，为学生生成进度报告可能是一个需求主题。

很公平，但是这些学生需要什么样的进度报告。它将带您进入新的水平。

报告类型将启动您定义模块。

模块

在更广泛的层面上定义报告类型构成了模块的定义。这些模块被标识为

• 讲师报告。
• 学生报告。

一旦定义了更广泛的模块，我们就必须为这些已识别的模块定义子模块

子模块

让我们讨论这些模块并确定可能的子模块。

• 讲师报告 - 模块

  • 课程报告。
  • 分配明智的报告。
  • 学生明智的报告。
  • 结果报告。

• 学生报告——模块

  • 当然明智的报告。
  • 作业明智的报告。

特征

一旦我们确定了子模块，就用功能列表详细说明它。一些例子是：

• 课程报告
  • 讲师应该能够生成一门或多门课程的报告。
  • 它应该能够灵活地选择日期范围。
  • 它应该为课程中的所有学生提供结果以及作为完整视图选项的考试列表。
• 作业报告
  • 用户应选择一项或多项任务。
  • 用户应该能够按日期范围获取报告。
  • 一门特定课程或多门课程的作业报告。

这些功能也可以分解为子功能。

用例和业务规则

对于这些类型的报告，我们需要识别业务实体。在这种情况下，业务实体将是：

• 课程。
• 学生。
• 讲师。
• 考试。
• 分数。
• 年级。

这些实体将有助于设计API。您的 API 应该基于域的实体进行设计。

它们还将帮助我们识别系统和子系统。例如，在上面的列表中，用户、课程、考试、成绩都是各自不同的系统。报告模块必须与所有这些系统交互才能获取报告所需的数据。

一旦我们定义了上面解释的所有步骤，就可以更深入地挖掘功能和子功能了。

我们必须为每个功能或子功能制定一个业务规则列表。它必须列出作为功能的一部分必须实现的业务规则的确切列表。

它将成为开发人员和测试人员执行任务的清单。开发人员将确保针对该用例实施所有这些业务规则。它将确保不存在与业务规则相关的错误，这是开发中最重要的部分之一。测试人员将考虑用户案例和业务规则来设计测试用例。

非功能性需求

一旦我们在自上而下的设计的帮助下确定并深入研究了功能需求。在每个阶段考虑安全性和性能等非功能性需求也很重要。它将确保设计的系统在更高负载或所需负载下执行且安全。

一个例子是为学生生成报告。了解课程中的学生人数很重要。该系统将能够生成课程中学生人数的报告。在自学的情况下，学生可以自行注册课程。

用户总数可以增长到 3000 到 5000 人。这会给您带来非功能性需求。它将帮助您确定必须采取哪些措施来支持如此大的期望。必须在设计阶段对其进行处理，以便正确实施并按预期执行。

用户个人身份信息的要求应从另一个系统获取。同样，安全性和性能的非功能性需求也在范围内。

设计一个支持所有这些情况的系统需要足够的时间。我们必须将这些非功能性需求识别为自上而下设计的一部分。它还将帮助您做出正确的估计。

自顶向下设计的好处

• 它有助于识别系统和子系统。
• 使两个系统或子系统之间的通信更加清晰。
• 功能和子功能以及所有业务规则的综合列表。
• 在执行用户要求时不允许出现任何错误。可以实现高质量。
• 确保得出正确的估计。
• 易于编码，因为我们在各个级别都有明确定义的期望。
• 非功能性将有助于确保其性能、安全。