级别： 初级
Adam Frankl, 市场营销副总裁, Ravenflow
2007 年 10 月 15 日
解读企业如何在软件开发过程中应用用例来作为验证需求的基础。
来自 The Rational Edge。
在 应用程序开发项目的各个涉众之间进行有效的沟通往往非常具有挑战性，特别是当开发团队受到时间和空间上的种种限制的时候更是如此。IBM® Rational® 软件帮助开发组织通过 IBM Rational 软件交付平台对软件核系统核心业务流程进行自动的、集成的、可掌控的操作。平台的核心就是 IBM Rational 统一过程® (RUP®) 一种为软件和系统交付建立的迭代业务流程的灵活的框架结构。在超过二十年的成功实践的基础上，RUP 有助于开发组织减少项目失败的风险，提升一致性、可预测性、生产力和效率。
该 RUP 业务模型为业务用例提供了工具和符号，这些用例可以有效的促进涉众同领域专家之间的交流和验证。它允许业务分析师使用同样的符号和工具来记录业务流程，软 件架构师和设计者也使用同样的符号来记录软件的解决方案。从而两组人可以更好的进行沟通，确保软件系统真正满足业务的需要。
一 个业务用例描述了一个业务流程，记录了一系列动作的顺序，这些动作为业务操作者提供了显而易见的价值。业务操作者可以使任何人、系统、或者同该业务或组织 发生交互操作的事物。所以，业务用例应该描述业务做了什么（也就是同其外部环境进行了那些互操作），从而将价值传送给其涉众。要想全面的理解业务及其流程 的目的，就必须知道是谁提出了要求，是谁输出的结果感兴趣。
另一种思考业务用例的方式是，它记录了特定的业务流程。事件流、或者工作流程流，是业务用例的一个关键要素。它描述了业务“做什么”才能将价值传送给业务操作者。任何参与该业务的人员都应当理解这种描述。（重要的是，这不同于那种对“如何”解决业务问题的描述）
无论开发项目所关注的是一个新的业务领域还是提供新的功能，验证业务用例都是 RUP 的一项至关重要的组成部分。Rational 统一过程业务建模原则通过提供工具和符号，提高了沟通和项目需求验证的效率。
从 业务参与者的角度来看，业务用例模型提供了蓝图。它以一种所有项目团队成员都能理解的方式描述了业务流程。但是，还有其他一些原因使得软件团队需要业务模 型。软件在商业价值而非技术需要的驱动下，必须被快速的交付。一个好的业务模型能够为进程的自动化提供一个软件独立的描述，从而在技术选择之前提升对优先 级和风险的包容能力。
IT 团队必须对业务加以描述，从而使团队成员做出正确的决定，包括涉及相关价值和开销因素的业务流程的明确的规格。业务用例通过包含文本描述和一至多个 UML 活动图被记录下来。图1为我们提供了一个业务用例规格的例子。请注意，左侧的图为右侧的业务用例文本中描述的工作流程结构提供了一个图形化的展示。
图1：一个业务用例规格的例子
图1的相应的工作流程描述。
- “Customer Sales Interface”完成初始化操作。
- 如果“Customer Sales Interface”确定初始化机会工作已经完成，那么“Customer Sales Interface”发送一个请求到“Proposal Owner”。
- 否则，“Customer Sales Interface”寻找替代方案。
- 如果“Customer Sales Interface”找到了替代方案，那么就启动它。
- “Proposal Owner”创建一个提议项目方案。
- “Proposal Owner”发送一个提议项目计划到“Quote Owner”。
- “Quote Owner”准备一个报价。
- “Quote Owner”发送一个报价到“Proposal Owner”。
- “Proposal Owner”分析这个提议并且确定这个提议。
- “Proposal Owner”生成一个项目方案。
- “Proposal Owner”完成附加的信息。
- “Proposal Owner”发送提议到“Customer Sales Interface”
- “Customer Sales Interface”呈现这个提议。
- “Customer Sales Interface”获得客户的决定。
图1中组件的清单如下。
- “泳道”或者列，显示哪一个业务人员在执行活动。业务人员将不会显示在一个为了业务用例本身所绘制的活动图里，但是他会作为业务用例实现的一部分被显示出来。
- 活动状态表现了工作流程中的活动或者步骤的执行情况。
- 跃迁表明了活动状态之间的顺序关系。这种类型的跃迁被称作完成跃迁。这种跃迁类型是在某一活动状态时完成某一活动所触发的。
- 每一个决定都已一套明确定义的守卫条件。守卫条件控制着在某项活动完成后触发一套备选方案中的哪一个跃迁。决定和守卫条件允许业务分析师在业务用例流程中展示不同的路径。
用 户接口原型能够大大促进验证用户用例的过程。通过接口验证所获得的反馈信息应当被整合进业务用例规格中，但是在原型建立之前生成用户用例规格十分重要。过 早的在用户面前展示仿真效果会带来错失完整的问题定义的风险。在开始设计页面流程之前，业务分析师必须开启业务用例才能理解问题，理解进程流程。换句话 说，业务分析师需要在设计特定页的仿真之前理解业务流程。
业 务用例模型描述了在业务操作者和业务之间发生了什么——不对业务的结构及其如何达到目标做任何假设——业务分析模型的目的就是描述业务用例是如何工作的。 业务分析模型正确的定义了由业务提供的服务，定义了内部业务工作者及其使用的信息，将他们的结构组织描述为独立的单元，并且定义了它们如何互操作从而实现 业务用例中所描述的行为。
业务分析模型通过提供一种业务系统、工作人员以及其他实体如何协作以执行业务用例的抽象，从而描述了业务用例的实现。它还定义了那些在业务用例执行过程中由业务操作者所调用的额外的业务服务。
涉 众和业务流程分析师通过业务分析模型来理解业务的当前工作（采用如-是形式），并且分析变化对业务的影响（采用将要形式）。系统分析师通过该模型获取自动 系统所需的要求，这种自动系统将作为业务流程的一部分被使用。软件架构师通过该模型定义无缝连接的软件架构，同时在软件分析和设计模型中定义类。由于业务 方和 IT 团队方都采用同样的模型，所以这两部分人员拥有“共同的语言”，因此他们能够更好的沟通业务的真正需要是什么。
业务建模既可以是独立的也可以作为业务流程再工程的一部分，两种情况下它都向软件开发流程中添加了价值。具体来说，业务建模有助于定义系统需求。对于开发团队来说，需求处理部分就是分析待解决的问题。在更大的背景下从事这种分析有助于确保系统建成后达到业务的目标。
实际上，基于 UML 的业务模型可以直接输入到需求模型中。RUP 定义了两者之间的直接映射关系。如果要将一个业务模型映射到一个分析模型上：
- 要被自动处理的业务流程将呈现为一个用例。
- 业务用例将变成一个子系统。
- 每一个业务实体都将变成一个实体类。
这种映射为敲定需求和分析、设计工作流程提供了一个开头。当一个复杂的开发组织试图自动处理重要的功能时，业务用例模型是非常宝贵的。请确保企业解决的这个问题对于其业务的成败来讲至关重要。使用 UML 为业务和需求建模，是一种最好的重视沟通和良好项目成果的办法。
无论是对于正确获得需求，还是对于同所有项目团队成员进行良好的沟通，工具都是非常重要的。它能够自动将文本用例转换成可视化的模型，从而大大节省了时间。
常 见的错误往往在图中更加容易被发现，因此，快速生成可视化用例的能力就会加速迭代需求的验证过程。项目陷入困境往往是因为业务人员用语言思考，而架构师和 设计师用模型回应。克服这种沟通障碍的最佳方式就是文本和图一同工作。在开发周期的早期阶段获得完整的需求和精确的可视化模型，是项目取得成功的关键。
图2指出了对于应用程序开发来说，适合 Rational 统一过程的需求定义、管理和建模工具流行于哪些地方。
图2：对于应用程序开发来说，适合 Rational 统一过程的需求定义、管理和建模工具是多么的流行
IBM Rational RequisitePro® 是一个需求管理工具，它可以让团队通过使用相似的、基于文档的方法来共享需求，同时使用激活的数据库功能（诸如需求追溯和效果分析）。结果中包括更加有效 的对需求的沟通和管理，以及更大的按时完成项目的可能性，同时满足预算和以上所述的各种期望。
IBM Rational 软件建模器是一个功能强大的、基于 UML 2.0 的可视化建模和设计工具。它使得架构师、系统分析师、设计师以及其他人员能够从若干个角度同不同的涉众说明和沟通开发信息，同时，它还为 UML 2.1 建模提供了丰富的支持。
来 自 Ravenflow 的 RAVEN 是一款经过验证的“为 IBM Rational 量身定做”的配套产品，它帮助设计团队开发和验证业务用例。“为 IBM Rational 量身定做”的称号表明了 RAVEN 达到了 Rational 的综合指导方针；它可以同 Rational 产品安全的完成互操作，并且提供了一致的用户体验。RAVEN 允许分析师同所有的项目涉众和用户一起通过从业务用例文本中自动生成图视图快速地指定和验证业务用例。它通过同 Rational RequisitePro 的互操作将业务视图保存在 RequisitePro 的数据库中。
学习
- 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
- 您可以参阅 Rational Edge 电子月刊中文版 的其他文章。
-
注册今天的 Webinar
撰写，确认和管理业务需求的自动化解决方案：Ravenflow 和 IBM Rational RequisitePro
2007 年 9 月 5 日 - 12pm EDT - Ravenflow 赞助
准 确地将业务目标和 IT 交付结合起来对于交付创新的业务应用程序是非常重要的。不幸的是，说远比做容易。复杂需求的沟通不足常常会导致项目交付延期，超过预算，或者缺失业务所需 要的特性。参加 webinar 来学习 Ravenflow 和 IBM Rational 的 RequisitePro 如何形成一个完整的解决方案，获得正确的需求，并成功地在整个业务应用程序项目的开发和交付过程中管理它们，以及观看此集成的演示。
博文
没有评论:
发表评论