|
级别： 中级
Christopher P. Caserio (mailto:cppc@acm.org?subject=关于需求建模您所需要了解的所有内容), IT 架构师,
Objex Consulting
2007 年 9 月 06 日
您的软件项目能否取得成功，这依赖于准确和完整的需求。要保证体系结构的正确，就要求人们能够使用相应的技术技能来捕获和细化正确的需求。发现用于需求建模的有价值的技能和工具，并且了解如何评估能力方面的进展。
确定需求可能是非常困难的。通常，现有应用程序的操作包含了业务流程的各种需求，使其成为了设计或者实现更改的等价物。例如，“我们需要向表 XYZ
中添加一列以存储客户代码”，这一需求并没有说明为什么需要这一列、它支持什么样的业务流程、或者任何关于合法性的业务规则、跨数据库完整性等等。这并不是一项需求：它只是一项实现决策。在这个级别上表达业务要求，您已经丧失了分析解决方案并确定支持业务流程的最合适的方法的能力。客户代码可能存在于其他地方，或者可能由其他数据推导而来。基于这个需求的解决方案很可能会忽略该问题，以及创建副本、同步问题和其他问题。
本文是关于应用程序体系结构原则的系列文章中的第 1
部分，在这篇文章中，您将了解关于应用程序体系结构的需求建模方面的内容，并研究相关的技能和能力、工具和技术、里程碑、以及与应用程序体系结构原则相关的交流过程。
技能和能力：建模
要有效地收集需求，您要做的第一步是建模，它包括创建体系结构的表示形式以捕获需求、就解决方案方法进行交流、以及分析所提出的系统设计。其目的是使用模型来表现系统中的关键方面。然后，您可以在形式化的分析、模拟和原型设计中使用这些模型，以研究预期的系统行为，并且可以在编写文档或总结时使用这些模型，以便就系统的性能和外观进行交流。
域建模
域建模 指的是，您对问题域创建相应的模型并且把它划分为若干个内聚组的过程。然后，您可以在抽象模型中捕获业务流程、规则和数据。
域模型是一种用于理解问题域的工具。您需要从信息系统之外的角度来理解这个域，这一点是很重要的。
要构造域模型，您必须完成下列工作：
- 标识并确定参与者（实体）及其操作（活动）的特征。
- 标识管理操作（规则）的策略。
- 收集有关实现这些操作、来自这些操作或者记录这些操作（构件/数据）的信息。
- 将相关的要素划分为子域。
- 确定结果域（核心的/通用的/外部的）以及它们之间交互的特征。
在这个过程中，一个有见地的架构师将学习到很多东西。结果域模型和相关的知识是实现您的角色（作为问题空间和解决方案空间之间的桥梁）的第一步。
用例建模
用例模型 描述了各种参与者（人和其他系统）和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。
用例模型应该将系统放到上下文环境中，显示系统和外部参与者之间的边界，并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者（例如，用户和维护人员）所看到的系统行为。
组件和服务建模
组件模型
为子系统、模块和组件的层次结构分配需求和职责。每个元素作为一个自包含的单元，以用于开发、部署和执行的目的。组件模型的元素由它们所提供和使用的接口来进行规定。在这里，没有考虑其中的内部细节。
服务模型
将应用程序定义为一组位于外部边界（用例）、架构层之间的抽象服务接口，并且提供了通用的应用程序和基础结构（安全、日志记录、配置等等）。支持应用程序需求的这组服务可以与现有的内部和外部提供的接口规范相匹配。所得到的分析结果可以确定预置策略，并将项目活动划分为特定类型的部分，这取决于给定的服务是否已经存在（内部或者外部的，并且其中每个服务都具有适当的活动）、存在但需要进行修改（定义一个新的接口，并规划其实现）、或者必须构建新的服务。
性能建模
您可以通过各种各样的方式来度量性能，最显而易见的方式是，应用程序执行其关键操作任务的速度。然而，作为一名架构师，您必须考虑性能建模
过程中其他的几个方面：
- 构建和部署应用程序的速度如何？
- 构建、维护和运行需要多少花费？
- 该应用程序能在多大程度上满足其需求？
- 对于必须使用该应用程序的人来说，需要为其付出多大的开销？
- 该应用程序会对其他应用程序和基础结构产生怎样的影响？
关于这些问题（和无数的其他问题，这取决于具体情况）的答案，对一个成功的应用程序来说是至关重要的，并且通常称其为应用程序在架构上的质量。对这些质量进行建模是很困难的，甚至比性能的标准质量更困难，后者通常解决处理和数据存储方面的需求。
您可以将其分为应用程序的质量属性，如：
技能和能力：分析
需求分析意味着将广泛的业务要求提炼为用于设计和开发的可管理单元。您必须能够确定可以应用相关技术的域模型的范围，然后设计应用程序的概要结构，确定关键的组件和性能标准。
见树又见林
兼顾大规模和小规模的方面，以及应用程序的隐含需求，这是需求建模中一项重要的技能。在需求中，表面上的一些小细节可能对应用程序的实现有着深入和广泛的影响。您必须熟悉问题和解决方案域，以便了解其中哪些是关键的需求，以及哪些可能仅需要在描述上做出更改。您还必须能够在更广泛的利益相关者中评估低级别的设计决策，坚持那些不为具体实现者所知的价值的特定选择，例如，可维护性、稳定性和可重用性，这些是在完整的
IT 功能和策略的环境中才能观察到的。证明和维护这些决策依赖于下面讨论的交流技能。
模拟
模型的一个重要的优势是，您可以使用它们来模拟系统行为。可以采用原型、数学方程或者交互式图表的形式。对于成功的应用程序架构师来说，拥有选择正确的模型类型（有助于进行模拟或预测系统某些重要方面的模型类型）的能力是很重要的。
论证
在大部分的架构实践中，都非常缺乏对逻辑和逻辑推理的使用。在一定程度上，这反映出了大部分架构师在分析技巧方面缺乏经验和相应的能力。最近有一本书，Software
Blueprints（请参见参考资料），它描述了一种用于分析需求和构造论证系统（包括各种问题，以及可能的解决方案）的方法。从此分析得出，您可以根据所提出的解决方案中隐含的内容来构造相应的断言，并验证是否满足各种需求。
技能和能力：学习
学习
指的是吸收和理解新信息的能力，然后应用所学到的知识，以便对需求进行分析，并形成解决现有问题的体系结构。您应该有能力同时在不同的抽象级别上获得并应用知识，以及通过综合和创造来创建新的概念。
抽象
对于应用程序架构师来说，另一个重要技能是，具有为特定的需求（删除细节，并将其映射为更普通的问题类别）创建抽象的能力。这项技能是非常关键的基础性技能，是建立其他学习技能的基础。能够对细节进行抽象，并识别各种模式（基于来自经验的直觉以及对各种最佳实践的了解）。成功的架构师能够在维护较高级别决策和模式策略的同时，在体系结构中的所有级别上应用这项技能。
综合
组合两个或者更多的概念、抽象、或者其他的知识，以创建以一种创新的方式来支持需求的新概念。
所以，既然您可以跨设计空间的所有级别来创建和操作抽象与模式，那么您应该可以将它们组合起来使其符合现有的功能、或者发明新的方法以解决问题。例如，了解满足需求的现有应用程序的企业开发、部署模式与框架，您就可以创建并应用合适的映射。在该模式中确定和指定一个扩展点，以便利用新的外部网关产品来改进这个模式、或者满足该模式无法支持的附加需求，在有经验的架构师的工具集中，这是一项非常重要的技能。
技能和能力：交流
您必须能够与具有高度复杂背景的利益相关者进行沟通交流，以提取和细化您的需求，并向这些利益相关者描述系统的体系结构。您必须准备好与各种规模的小组进行交互、进行演示，并且进行各种类型的书面交流。您还必须了解相应的技术，以便使用不同的交流方式与各种受众进行交流。
组交互
一名优秀的架构师必须能够与不同组中的成员进行交流，而这些人具有不同的背景、技能和日程安排。通常，这包括与各种参与者开会，所有的人一起或者集中其中部分人。
演示
有些时候，架构师必须向广泛的听众介绍所提出的体系结构。有效地和高效地对大型的组进行介绍，是这项工作的一部分；另外还需要准备相关的材料。您应该能够创建清楚且有效的演示文档，该文档需要避免使用填满了项目符号的大量幻灯片。力求使用图形的表示方法，并围绕相关的图表展开介绍。这需要对所讨论的主题提供大量的支持和简化。如果让您的听众去阅读大量项目，将会使他们感到厌烦和苦恼。
调查
您应该能够通过各种调查来发现需求，否则将无法清楚地得到这些需求。调查的问题应该是清楚的、明确的并且具有启发性的。
访谈
在许多情况下，您将不得不通过与关键利益相关者的访谈来澄清一些特定的需求。您应该能够自如地与组织中各个级别的利益相关者进行访谈，他们可能来自于不同的技术和业务部门。准备好相关的知识和问题，以便帮助公开问题域。
书面方式
通常，书面交流需要比口头交流更加小心。与面对面的直接交流相比，它无法（表情图标除外）通过面部的表情和身体语言来传达微妙的暗示。这在电子邮件消息中尤其困难，它很容易就会被误解。
如果您希望自己的主张能够得到响应，就需要为其中的观点和设计决策提供背景信息和解释。使得每个人都感觉到，他或她对您来说是非常重要的，以至于您很愿意向他们解释自己的观点。
您应该擅于并且能够使用电子邮件，以及准备相关的报告。您还应该能够从访谈、会议和调查中，将含糊不清的表述转换为准确的需求声明。
技能和能力：原型设计
当一个或更多的需求暗示了某项活动，而该活动无法被清楚地理解，或者需求自身是有问题的，那么您可以使用原型设计的方法进行深入地调查，并提供反馈信息以便规划将来的活动。这个阶段通常重点关注于用户界面（UI）或者应用程序的关键用例，但是也可以用于技术问题和产品选择。
原型可能是各种各样的对象，从类-职责-协作（CRC）对话框到 UI 原型或者工作代码。有一些新的框架可用于直接将对象模型表示为工作应用程序。
CRC 和角色扮演
您必须能够引导、记录和促进角色扮演研讨会，其中各种参与者可以扮演预想的应用程序中各种不同的角色。CRC
卡为利益相关者和技术主题专家（SME）提供了一种用于揭示和研究需求的方法。每个小卡片上记录了名称、职责和某些实体的合作者。您可以让不同的人来扮演相关类的角色，以此演练各种场景。在域和用例建模中，这个练习是特别有价值的。
UI
您应该能够快速地生成 UI
原型，该模型显示并表达了系统行为、外观、以及接口的新的或危险的方面。可能的工具包括带集成开发环境（IDE）、制图工具的接口构建包，甚至基于模型的自动生成的接口。
原型框架
作为一名应用程序架构师，您需要熟练掌握和使用进行原型设计的各种现有框架，包括脚本编程语言和环境、原型生成器、动态语言以及接口构建器。您还应该能够创建特定于应用程序域和组织的新的、自定义的原型环境。
技能和能力：企业体系结构
当在大型企业中工作时，您必须清楚应用程序在该企业内的上下文环境。其中包括业务上下文以及实现和执行环境。
您应该非常熟悉组织的企业体系结构原则和用于管理与执行开发项目的各种形式化的方法。您还应该了解现有的各种企业组件，如安全机制、业务流程和业务规则引擎、工作流引擎和打包的应用程序。
熟悉基础企业环境是非常关键的。您应该深入地了解各种开发工具、中间件平台、以及应用程序部署的标准平台，包括它们的相关特征和成本。在决定体系结构和确定何处存在开发风险的工作中，开发团队技能集中的相关知识同样是非常重要的。
工具和技术：建模
当前，用于建模的工具主要是统一建模语言（UML）。这些工具通常允许创建软件的静态和动态模型，包括类、活动、状态、组件和整体的模型结构（包）。通过指定对象类型（类、包，等等）的元模型来定义的
UML 模型，这些对象类型可以包含在最终产品模型（称之为用户模型）中。请记住，元模型只是一个模型。
Rational Software
Architect
IBM® Rational® Software Architect 是一种面向架构师的、非常全面且功能齐全的工具。它是基于 Eclipse 框架的，其
IDE 支持建模、Java™ 开发、Web 开发和 Java 2 平台 Enterprise
Edition（J2EE™）开发。还可以使用其他方法来建立模型，比如手动地从模式、或者通过对代码进行逆向工程建立模型。支持创建项目模板，模板中包含预先构建好的项目元素，并且能够进行实例化以用于特定的项目。这些模板可以包括任何有效的项目元素，通常包括注释的图表，以便在预期的活动中为架构师、设计人员或者开发人员提供帮助。
Poseidon
Poseidon for UML 是由 Gentleware 提供的一种全面的 UML
建模和代码生成工具。您可以免费下载其共享版，或者您也可以购买标准许可版、专业版和嵌入式版本。这个工具对 UML 2
模型和图表类型提供了全面的支持。其专业版包括对正反向工程的支持，以及将建模工具嵌入到 Eclipse 的功能。
Argo
ArgoUML 是一个开放源代码 UML 模型编辑器，该编辑器支持 UML V1.4。Argo
的一个最有趣的特性是评论功能，即评估模型的完整性和可靠性。该工具还提供了所有九种图表类型、图表导出、XML 元数据交换 (XMI)
集成，并且支持对象约束语言（OCL）。
ArgoUML
工具开始使用设计评论、检查清单、用户模型（该模型可以将相关评论加工为决策、目标、工作分类和用户的技能）来解决建模者的认知过程。ArgoUML
还提供了大量的基于自定义规则的模型资源管理器透视图，它们允许您按照上下文特定的方式来查看模型。
Eclipse Modeling
Framework
Eclipse Modeling Framework (EMF) 是一个基于 Eclipse 的 Java
框架，它为构建工具和其他建模应用程序、转换以及正反向功能提供了基础。该框架是一个 Eclipse 插件，它提供了从其他格式导入和导出模型所需的功能，这些格式包括
Java 代码、可扩展标记语言（XML）模式、或者 Rational Rose®。
工具和技术：规范
架构师应该能够自如地为相关的需求和满足这些需求而提出的体系结构创建不同程度的形式化规范。您应该能够跨越各种规范技术和模型进行操作，针对既定的目标、形式化级别、每项需求所关联的风险和整体应用程序概要，应用合适的方法。
UML
您应该能够使用 UML 作为一种规范环境，在该环境中定义应用程序的静态和动态结构。您应该对各种 UML
模型元素和图表语法有全面的认识，并且能够有效地在交流和应用程序的形式化规范中使用它们。使用 OCL
更形式化地指定域模型中的业务规则和对象与组件的行为契约。
XML
XML 及其派生技术，特别是 XML
模式定义（XSD）语言，常常可用于指定不同应用程序之间和同一个应用程序的不同组件之间所交换的数据。可以在系统、平台、语言、层/级和组织内部或者之间的边界上使用
XML/XSD 规范。
形式化方法
对于一位精明的架构师，如果他希望或者需要执行形式化证明，证明给定的体系结构或设计将满足相应的需求，那么他可以使用众多的形式化规范语言和方法学。对于这些方法，完整性和正确性是关键。这些规范的缺点是，有时几乎难以理解，并且在创建和维护方面需要进行大量工作。
工具和技术：原型设计
用于进行原型设计的工具的数量和种类非常之多，我无法在这里一一介绍。通常，原型设计需要一个灵活的、动态的工具集，而该工具集能够在很短时间内、以很低的费用来创建典型的功能。大多数原型设计工具都使用解释性语言来指定行为，允许以一种并不是很精确和可靠的方式进行更快速的开发工作。这里的关键是，使用任何合适的工具以显示所分析的系统的某些方面。下面，我给出了几个示例。
Naked Objects 框架
Naked Objects 框架是一类典型的原型工具，这类工具依赖于代码中的命名约定以及从代码自动生成 UI
的反映机制。这个框架的最新版本正在将约定/反映方法转变为外部配置，通过外部配置将用户可见的属性和操作映射为代码元素。所得到的接口支持非常复杂的应用程序，可以在该应用程序中评估域模型。在有些情况下，事实上这足以交付应用程序。
从这个框架得到的结果是图形用户界面（GUI），可以在其中创建并操纵域对象。用户可以创建这些对象、修改它们的属性、使用拖放功能在对象之间创建关联以及调用操作。当然，必须在操作中对该业务逻辑进行编码，但是要构造完整的功能原型，不需要编写任何
UI 代码。这种方法功能非常强大，可用于显示和探究域模型的特征，并评估业务逻辑，其中包括利益相关者的参与。
脚本编写环境
对于架构师来说，可以使用许多脚本编写语言和环境，它们都为迅速地创建和执行代码提供灵活的、解释性的平台。其中大多数并不适合于复杂的 UI
评估，但是它们可以很好地应用于模拟和性能分析。
HTML/动态 Web
也许，最容易获得且最廉价的原型设计环境是普遍存在的 Web 服务器/Servlet 动态 Web。有一些新出现的工具，如 Asynchronous
JavaScript + XML (Ajax)，它们提供相当丰富的 UI
工具包。在任何情况下都可以迅速地部署和修改原型应用程序，并且连接到服务器的任何用户都可以访问这些原型应用程序。
工具和技术：容器
在软件体系结构的历史中，最具革命性的工具也许就是容器。容器
提供了许多连接和机制以部署应用程序功能，而不需要在所有方面中进行编码。使用外部配置文件（通常是 XML），可以将要部署的组件映射到容器环境。一些示例容器，包括
J2EE Web/Enterprise JavaBeans (EJB) 容器，提供了重量级的平台，以便部署组件；轻量级依赖注入容器，如
Spring，它允许将组成应用程序模块或组件的对象连接在一起，并且支持发布或使用分布式的接口、自动化对象持久性，等等。
工具和技术：层
将应用程序划分为层，这是一种在体系结构中关注点分离的基本技术。每一层反映了一组常见的功能和非功能性的需求。
逻辑层将概念体系结构划分为在应用程序内扮演特定角色的组件，如表示层、应用程序逻辑层、业务流程层和数据访问层。物理层将逻辑层中的组件分配到其部署的物理平台。逻辑层可以跨物理层，并且可以将一个或多个、甚至所有的层分配到一个物理层。
里程碑
这部分内容为应用程序架构师确定了关键的技能和能力里程碑，因为它们是与需求建模工具和技术相关联的。请记住，这不是一个静态的序列，而需要在各种模型和视图之间进行反馈和迭代，直到利益相关者的需求。无论在哪个级别上出现了设计问题，都应该在体系结构的更高或者更低级别上进行深入分析。
域模型
域模型表明了架构师对于这个问题域的理解，包括参与者、过程和管理它们的活动的策略。在企业环境中，通常存在现有的域模型。在这种情况下，您应该确定现有模型中与应用程序需求相关的部分，并详细说明由这些需求间接表示的模型更改。在完成了以上的工作后，您可以与利益相关者一同检查新的模型，验证需求，并确定后续开发工作的范围。最后，通过记录系统将支持哪些角色交互，将所提出的系统放置于域模型的上下文中。
用例模型
作为应用程序架构师，我们可以使用用例模型以确定应用程序的外部边界、以及在这些边界处的交互。在大多数情况下，主要的交互位于用户和系统之间。然而，也应该捕获与其他系统（内部或者外部）之间的交互。如果将系统视为一个整体，结果是它的一种刺激响应，而不考虑内部实现细节，仅仅关注于边界处的事件和信息的交换。
完成后的用例模型应该允许所有的利益相关者看见系统是如何支持他们的角色的。因此，可以对该模型进行扩展，使其包括系统操作所有方面的用例。系统的体系结构应该考虑可能拥有和使用系统的所有方面。
用例模型应该捕获已发现的所有这些利益相关者的交互。首个模型应该重点关注于核心的功能需求，而后来添加的附加用例则用于支持非功能性的方面。或者，您可以为特定类型的利益相关者创建不同的模型视图。
体系结构
在本文中，对于表示系统概要设计的模型和映射，我使用体系结构
作为一个通用的术语。当理解和说明相应的域和用例模型时，您可以从下面几点入手：
- 服务模型。确定并说明系统提供给其他内部和外部系统以及应用程序自身的服务。
- 组件模型。确定应用程序的子系统/模块/组件结构。
- 服务/组件映射。将服务规范映射为组件规范；确定哪个组件提供了哪项服务，以及任何所需的适配器和协调。
- 性能模型（可选的）。为每个组件确定关键性能指标，并指定应用程序的整体性能目标；应该适合于系统操作的性能分析和模拟。
- 层分区。在您构造这些模型时，请始终记住这些体系结构的层次。组件不应该跨越层的边界，并且将服务封装在同一层内的组件中，这是很有价值的，特别是在中间层和较低的层中。
工作分类
在有了所有的概要设计之后，现在您应该能够提前对相关的工作进行规划了。工作分类应该确定所有的子项目的特征，这里的子项目包括将要构建、购买、重用、或者改写系统组件的子项目。考虑并且定制体系结构，以便适应不同种类的工作。从相对较高级别上看，应该将工作划分为解决方案特定的（UI、应用程序流）以及解决方案独立（业务流程、实体）的活动。接下来，根据需要完成的工作的类型，对每一项活动进行划分：构建、评估和购买、改写和扩展，等等。
总结
您可以看到，软件解决的问题域和构建及执行该软件的解决方案域之间存在直接的关系。在需求建模中，您的角色是去探究、详细描述、发现并创建这一关系。要做到这一点，您必须确定利益相关者并与其进行交流，记录并提出您的发现，构建并分析相关模型，同时创建一个在时间和预算限制以内的、能满足需求的、可构建实施的设计方案。
这种密集但简洁的定义说明了，要想有效地捕获并细化需求，架构师所必须完成的工作。通常，架构师必须了解所有级别的内容，并且有兴趣缩小问题及其解决方案之间的差距。您必须全力以赴地扮演好相关的角色。最重要的是，架构师角色需要与广泛的听众进行交流。培养耐心，并学习使用最重要的交流工具：倾听。
参考资料
学习
获得产品和技术
- 下载 IBM 产品评估版 并使用 DB2®、Lotus®、Rational、Tivoli® 和 WebSphere
软件中的应用程序开发工具和中间件产品。
讨论
关于作者
 |
|
|
|
Christopher Caserio 是一家著名保险公司的一位 IT 架构师。他从事软件系统的开发和设计已经超过 25
年，在此期间他曾担任过各种各样的角色。他在 1993 年创办了 Objex Consulting，旨在为客户提供企业体系结构和软件设计以及开发服务。您可以通过
cppc@acm.org 与
Christopher 联系。
|
对本文的评价
|
