需求建模（上）
本帖最后由 草帽路飞UU 于 2017-8-10 13:20 编辑您的软件项目能否取得成功，这依赖于准确和完整的需求。要保证体系结构的正确，就要求人们能够使用相应的技术技能来捕获和细化正确的需求。发现用于需求建模的有价值的技能和工具，并且了解如何评估能力方面的进展。
确定需求可能是非常困难的。通常，现有应用程序的操作包含了业务流程的各种需求，使其成为了设计或者实现更改的等价物。例如，“我们需要向表 XYZ 中添加一列以存储客户代码”，这一需求并没有说明为什么需要这一列、它支持什么样的业务流程、或者任何关于合法性的业务规则、跨数据库完整性等等。这并不是一项需求：它只是一项实现决策。在这个级别上表达业务要求，您已经丧失了分析解决方案并确定支持业务流程的最合适的方法的能力。客户代码可能存在于其他地方，或者可能由其他数据推导而来。基于这个需求的解决方案很可能会忽略该问题，以及创建副本、同步问题和其他问题。
本文是关于应用程序体系结构原则的系列文章中的第 1 部分，在这篇文章中，您将了解关于应用程序体系结构的需求建模方面的内容，并研究相关的技能和能力、工具和技术、里程碑、以及与应用程序体系结构原则相关的交流过程。
要有效地收集需求，您要做的第一步是建模，它包括创建体系结构的表示形式以捕获需求、就解决方案方法进行交流、以及分析所提出的系统设计。其目的是使用模型来表现系统中的关键方面。然后，您可以在形式化的分析、模拟和原型设计中使用这些模型，以研究预期的系统行为，并且可以在编写文档或总结时使用这些模型，以便就系统的性能和外观进行交流。
域建模
域建模 指的是，您对问题域创建相应的模型并且把它划分为若干个内聚组的过程。然后，您可以在抽象模型中捕获业务流程、规则和数据。
域模型是一种用于理解问题域的工具。您需要从信息系统之外的角度来理解这个域，这一点是很重要的。
要构造域模型，您必须完成下列工作：
[*]标识并确定参与者（实体）及其操作（活动）的特征。
[*]标识管理操作（规则）的策略。
[*]收集有关实现这些操作、来自这些操作或者记录这些操作（构件/数据）的信息。
[*]将相关的要素划分为子域。
[*]确定结果域（核心的/通用的/外部的）以及它们之间交互的特征。
在这个过程中，一个有见地的架构师将学习到很多东西。结果域模型和相关的知识是实现您的角色（作为问题空间和解决方案空间之间的桥梁）的第一步。
用例建模
用例模型 描述了各种参与者（人和其他系统）和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。
用例模型应该将系统放到上下文环境中，显示系统和外部参与者之间的边界，并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者（例如，用户和维护人员）所看到的系统行为。
组件和服务建模
组件模型 为子系统、模块和组件的层次结构分配需求和职责。每个元素作为一个自包含的单元，以用于开发、部署和执行的目的。组件模型的元素由它们所提供和使用的接口来进行规定。在这里，没有考虑其中的内部细节。
服务模型 将应用程序定义为一组位于外部边界（用例）、架构层之间的抽象服务接口，并且提供了通用的应用程序和基础结构（安全、日志记录、配置等等）。支持应用程序需求的这组服务可以与现有的内部和外部提供的接口规范相匹配。所得到的分析结果可以确定预置策略，并将项目活动划分为特定类型的部分，这取决于给定的服务是否已经存在（内部或者外部的，并且其中每个服务都具有适当的活动）、存在但需要进行修改（定义一个新的接口，并规划其实现）、或者必须构建新的服务。
性能建模
您可以通过各种各样的方式来度量性能，最显而易见的方式是，应用程序执行其关键操作任务的速度。然而，作为一名架构师，您必须考虑性能建模 过程中其他的几个方面：
[*]构建和部署应用程序的速度如何？
[*]构建、维护和运行需要多少花费？
[*]该应用程序能在多大程度上满足其需求？
[*]对于必须使用该应用程序的人来说，需要为其付出多大的开销？
[*]该应用程序会对其他应用程序和基础结构产生怎样的影响？
关于这些问题（和无数的其他问题，这取决于具体情况）的答案，对一个成功的应用程序来说是至关重要的，并且通常称其为应用程序在架构上的质量。对这些质量进行建模是很困难的，甚至比性能的标准质量更困难，后者通常解决处理和数据存储方面的需求。
您可以将其分为应用程序的质量属性，如：
[*]执行时间
[*]资源使用
[*]开发复杂性
[*]维护复杂性
需求分析意味着将广泛的业务要求提炼为用于设计和开发的可管理单元。您必须能够确定可以应用相关技术的域模型的范围，然后设计应用程序的概要结构，确定关键的组件和性能标准。见树又见林
兼顾大规模和小规模的方面，以及应用程序的隐含需求，这是需求建模中一项重要的技能。在需求中，表面上的一些小细节可能对应用程序的实现有着深入和广泛的影响。您必须熟悉问题和解决方案域，以便了解其中哪些是关键的需求，以及哪些可能仅需要在描述上做出更改。您还必须能够在更广泛的利益相关者中评估低级别的设计决策，坚持那些不为具体实现者所知的价值的特定选择，例如，可维护性、稳定性和可重用性，这些是在完整的 IT 功能和策略的环境中才能观察到的。证明和维护这些决策依赖于下面讨论的交流技能。
模拟
模型的一个重要的优势是，您可以使用它们来模拟系统行为。可以采用原型、数学方程或者交互式图表的形式。对于成功的应用程序架构师来说，拥有选择正确的模型类型（有助于进行模拟或预测系统某些重要方面的模型类型）的能力是很重要的。
论证
在大部分的架构实践中，都非常缺乏对逻辑和逻辑推理的使用。在一定程度上，这反映出了大部分架构师在分析技巧方面缺乏经验和相应的能力。最近有一本书，Software Blueprints，它描述了一种用于分析需求和构造论证系统（包括各种问题，以及可能的解决方案）的方法。从此分析得出，您可以根据所提出的解决方案中隐含的内容来构造相应的断言，并验证是否满足各种需求。
学习 指的是吸收和理解新信息的能力，然后应用所学到的知识，以便对需求进行分析，并形成解决现有问题的体系结构。您应该有能力同时在不同的抽象级别上获得并应用知识，以及通过综合和创造来创建新的概念。
抽象
对于应用程序架构师来说，另一个重要技能是，具有为特定的需求（删除细节，并将其映射为更普通的问题类别）创建抽象的能力。这项技能是非常关键的基础性技能，是建立其他学习技能的基础。能够对细节进行抽象，并识别各种模式（基于来自经验的直觉以及对各种最佳实践的了解）。成功的架构师能够在维护较高级别决策和模式策略的同时，在体系结构中的所有级别上应用这项技能。
综合
组合两个或者更多的概念、抽象、或者其他的知识，以创建以一种创新的方式来支持需求的新概念。
所以，既然您可以跨设计空间的所有级别来创建和操作抽象与模式，那么您应该可以将它们组合起来使其符合现有的功能、或者发明新的方法以解决问题。例如，了解满足需求的现有应用程序的企业开发、部署模式与框架，您就可以创建并应用合适的映射。在该模式中确定和指定一个扩展点，以便利用新的外部网关产品来改进这个模式、或者满足该模式无法支持的附加需求，在有经验的架构师的工具集中，这是一项非常重要的技能。
http://www.ibm.com/i/v14/rules/blue_rule.gif
http://www.ibm.com/i/c.gif
您必须能够与具有高度复杂背景的利益相关者进行沟通交流，以提取和细化您的需求，并向这些利益相关者描述系统的体系结构。您必须准备好与各种规模的小组进行交互、进行演示，并且进行各种类型的书面交流。您还必须了解相应的技术，以便使用不同的交流方式与各种受众进行交流。
组交互
一名优秀的架构师必须能够与不同组中的成员进行交流，而这些人具有不同的背景、技能和日程安排。通常，这包括与各种参与者开会，所有的人一起或者集中其中部分人。
演示
有些时候，架构师必须向广泛的听众介绍所提出的体系结构。有效地和高效地对大型的组进行介绍，是这项工作的一部分；另外还需要准备相关的材料。您应该能够创建清楚且有效的演示文档，该文档需要避免使用填满了项目符号的大量幻灯片。力求使用图形的表示方法，并围绕相关的图表展开介绍。这需要对所讨论的主题提供大量的支持和简化。如果让您的听众去阅读大量项目，将会使他们感到厌烦和苦恼。
调查
您应该能够通过各种调查来发现需求，否则将无法清楚地得到这些需求。调查的问题应该是清楚的、明确的并且具有启发性的。
访谈
在许多情况下，您将不得不通过与关键利益相关者的访谈来澄清一些特定的需求。您应该能够自如地与组织中各个级别的利益相关者进行访谈，他们可能来自于不同的技术和业务部门。准备好相关的知识和问题，以便帮助公开问题域。
书面方式
通常，书面交流需要比口头交流更加小心。与面对面的直接交流相比，它无法（表情图标除外）通过面部的表情和身体语言来传达微妙的暗示。这在电子邮件消息中尤其困难，它很容易就会被误解。
如果您希望自己的主张能够得到响应，就需要为其中的观点和设计决策提供背景信息和解释。使得每个人都感觉到，他或她对您来说是非常重要的，以至于您很愿意向他们解释自己的观点。
您应该擅于并且能够使用电子邮件，以及准备相关的报告。您还应该能够从访谈、会议和调查中，将含糊不清的表述转换为准确的需求声明。
http://www.ibm.com/i/v14/rules/blue_rule.gif
http://www.ibm.com/i/c.gif
当一个或更多的需求暗示了某项活动，而该活动无法被清楚地理解，或者需求自身是有问题的，那么您可以使用原型设计的方法进行深入地调查，并提供反馈信息以便规划将来的活动。这个阶段通常重点关注于用户界面（UI）或者应用程序的关键用例，但是也可以用于技术问题和产品选择。
原型可能是各种各样的对象，从类-职责-协作（CRC）对话框到 UI 原型或者工作代码。有一些新的框架可用于直接将对象模型表示为工作应用程序。
CRC 和角色扮演
您必须能够引导、记录和促进角色扮演研讨会，其中各种参与者可以扮演预想的应用程序中各种不同的角色。CRC 卡为利益相关者和技术主题专家（SME）提供了一种用于揭示和研究需求的方法。每个小卡片上记录了名称、职责和某些实体的合作者。您可以让不同的人来扮演相关类的角色，以此演练各种场景。在域和用例建模中，这个练习是特别有价值的。
请转至
需求建模（下）
建模的要求真的很高
页:
[1]
