需求建模（下）
本帖最后由 草帽路飞UU 于 2017-8-10 13:23 编辑此篇承接 需求建模（上）
UI
您应该能够快速地生成 UI 原型，该模型显示并表达了系统行为、外观、以及接口的新的或危险的方面。可能的工具包括带集成开发环境（IDE）、制图工具的接口构建包，甚至基于模型的自动生成的接口。
原型框架
作为一名应用程序架构师，您需要熟练掌握和使用进行原型设计的各种现有框架，包括脚本编程语言和环境、原型生成器、动态语言以及接口构建器。您还应该能够创建特定于应用程序域和组织的新的、自定义的原型环境。
当在大型企业中工作时，您必须清楚应用程序在该企业内的上下文环境。其中包括业务上下文以及实现和执行环境。
您应该非常熟悉组织的企业体系结构原则和用于管理与执行开发项目的各种形式化的方法。您还应该了解现有的各种企业组件，如安全机制、业务流程和业务规则引擎、工作流引擎和打包的应用程序。
熟悉基础企业环境是非常关键的。您应该深入地了解各种开发工具、中间件平台、以及应用程序部署的标准平台，包括它们的相关特征和成本。在决定体系结构和确定何处存在开发风险的工作中，开发团队技能集中的相关知识同样是非常重要的。
当前，用于建模的工具主要是统一建模语言（UML）。这些工具通常允许创建软件的静态和动态模型，包括类、活动、状态、组件和整体的模型结构（包）。通过指定对象类型（类、包，等等）的元模型来定义的 UML 模型，这些对象类型可以包含在最终产品模型（称之为用户模型）中。请记住，元模型只是一个模型。
Rational Software Architect
IBM® Rational® Software Architect 是一种面向架构师的、非常全面且功能齐全的工具。它是基于 Eclipse 框架的，其 IDE 支持建模、Java? 开发、Web 开发和 Java2 平台 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、应用程序流）以及解决方案独立（业务流程、实体）的活动。接下来，根据需要完成的工作的类型，对每一项活动进行划分：构建、评估和购买、改写和扩展，等等。
您可以看到，软件解决的问题域和构建及执行该软件的解决方案域之间存在直接的关系。在需求建模中，您的角色是去探究、详细描述、发现并创建这一关系。要做到这一点，您必须确定利益相关者并与其进行交流，记录并提出您的发现，构建并分析相关模型，同时创建一个在时间和预算限制以内的、能满足需求的、可构建实施的设计方案。
这种密集但简洁的定义说明了，要想有效地捕获并细化需求，架构师所必须完成的工作。通常，架构师必须了解所有级别的内容，并且有兴趣缩小问题及其解决方案之间的差距。您必须全力以赴地扮演好相关的角色。最重要的是，架构师角色需要与广泛的听众进行交流。培养耐心，并学习使用最重要的交流工具：倾听。
产品经理要干的事情了，感觉
页:
[1]
