需求建模

 

您的软件项目能否取得成功，这依赖于准确和完整的需求。要保证体系结构的正确，就要求人们能够使用相应的技术技能来捕获和细化正确的需求。发现用于需求建模的有价值的技能和工具，并且了解如何评估能力方面的进展。

确定需求可能是非常困难的。通常，现有应用程序的操作包含了业务流程的各种需求，使其成为了设计或者实现更改的等价物。例如，“我们需要向表 XYZ 中添加一列以存储客户代码”，这一需求并没有说明为什么需要这一列、它支持什么样的业务流程、或者任何关于合法性的业务规则、跨数据库完整性等等。这并不是一项需求：它只是一项实现决策。在这个级别上表达业务要求，您已经丧失了分析解决方案并确定支持业务流程的最合适的方法的能力。客户代码可能存在于其他地方，或者可能由其他数据推导而来。基于这个需求的解决方案很可能会忽略该问题，以及创建副本、同步问题和其他问题。

本文是关于应用程序体系结构原则的系列文章中的第 1 部分，在这篇文章中，您将了解关于应用程序体系结构的需求建模方面的内容，并研究相关的技能和能力、工具和技术、里程碑、以及与应用程序体系结构原则相关的交流过程。

要有效地收集需求，您要做的第一步是建模，它包括创建体系结构的表示形式以捕获需求、就解决方案方法进行交流、以及分析所提出的系统设计。其目的是使用模型来表现系统中的关键方面。然后，您可以在形式化的分析、模拟和原型设计中使用这些模型，以研究预期的系统行为，并且可以在编写文档或总结时使用这些模型，以便就系统的性能和外观进行交流。

域建模

域建模 指的是，您对问题域创建相应的模型并且把它划分为若干个内聚组的过程。然后，您可以在抽象模型中捕获业务流程、规则和数据。

域模型是一种用于理解问题域的工具。您需要从信息系统之外的角度来理解这个域，这一点是很重要的。

要构造域模型，您必须完成下列工作：

• 标识并确定参与者（实体）及其操作（活动）的特征。
• 标识管理操作（规则）的策略。
• 收集有关实现这些操作、来自这些操作或者记录这些操作（构件/数据）的信息。
• 将相关的要素划分为子域。
• 确定结果域（核心的/通用的/外部的）以及它们之间交互的特征。

在这个过程中，一个有见地的架构师将学习到很多东西。结果域模型和相关的知识是实现您的角色（作为问题空间和解决方案空间之间的桥梁）的第一步。

用例建模

用例模型 描述了各种参与者（人和其他系统）和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。

用例模型应该将系统放到上下文环境中，显示系统和外部参与者之间的边界，并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者（例如，用户和维护人员）所看到的系统行为。

组件和服务建模

组件模型 为子系统、模块和组件的层次结构分配需求和职责。每个元素作为一个自包含的单元，以用于开发、部署和执行的目的。组件模型的元素由它们所提供和使用的接口来进行规定。在这里，没有考虑其中的内部细节。

服务模型 将应用程序定义为一组位于外部边界（用例）、架构层之间的抽象服务接口，并且提供了通用的应用程序和基础结构（安全、日志记录、配置等等）。支持应用程序需求的这组服务可以与现有的内部和外部提供的接口规范相匹配。所得到的分析结果可以确定预置策略，并将项目活动划分为特定类型的部分，这取决于给定的服务是否已经存在（内部或者外部的，并且其中每个服务都具有适当的活动）、存在但需要进行修改（定义一个新的接口，并规划其实现）、或者必须构建新的服务。

性能建模

您可以通过各种各样的方式来度量性能，最显而易见的方式是，应用程序执行其关键操作任务的速度。然而，作为一名架构师，您必须考虑性能建模 过程中其他的几个方面：

• 构建和部署应用程序的速度如何？
• 构建、维护和运行需要多少花费？
• 该应用程序能在多大程度上满足其需求？
• 对于必须使用该应用程序的人来说，需要为其付出多大的开销？
• 该应用程序会对其他应用程序和基础结构产生怎样的影响？

关于这些问题（和无数的其他问题，这取决于具体情况）的答案，对一个成功的应用程序来说是至关重要的，并且通常称其为应用程序在架构上的质量。对这些质量进行建模是很困难的，甚至比性能的标准质量更困难，后者通常解决处理和数据存储方面的需求。

您可以将其分为应用程序的质量属性，如：

• 执行时间
• 资源使用
• 开发复杂性
• 维护复杂性

 

需求分析意味着将广泛的业务要求提炼为用于设计和开发的可管理单元。您必须能够确定可以应用相关技术的域模型的范围，然后设计应用程序的概要结构，确定关键的组件和性能标准。

见树又见林

兼顾大规模和小规模的方面，以及应用程序的隐含需求，这是需求建模中一项重要的技能。在需求中，表面上的一些小细节可能对应用程序的实现有着深入和广泛的影响。您必须熟悉问题和解决方案域，以便了解其中哪些是关键的需求，以及哪些可能仅需要在描述上做出更改。您还必须能够在更广泛的利益相关者中评估低级别的设计决策，坚持那些不为具体实现者所知的价值的特定选择，例如，可维护性、稳定性和可重用性，这些是在完整的 IT 功能和策略的环境中才能观察到的。证明和维护这些决策依赖于下面讨论的交流技能。

模拟

模型的一个重要的优势是，您可以使用它们来模拟系统行为。可以采用原型、数学方程或者交互式图表的形式。对于成功的应用程序架构师来说，拥有选择正确的模型类型（有助于进行模拟或预测系统某些重要方面的模型类型）的能力是很重要的。

论证

在大部分的架构实践中，都非常缺乏对逻辑和逻辑推理的使用。在一定程度上，这反映出了大部分架构师在分析技巧方面缺乏经验和相应的能力。最近有一本书，Software Blueprints（请参见参考资料），它描述了一种用于分析需求和构造论证系统（包括各种问题，以及可能的解决方案）的方法。从此分析得出，您可以根据所提出的解决方案中隐含的内容来构造相应的断言，并验证是否满足各种需求。