UML 学习

本文是 APPLYING UML MODEL AND PATTERNS 英文第二版的读书笔记，因为没有找到合适的中文版，手头的中文版是第三版，但是发现翻译质量很差。

OOA/D         -  以物件为导向的分析和设计，候捷语。

use cases        - 应用场合

domain model - 事物模型

interaction diagram -交互图表

design class diagram -设计的类图表，它属于设计领域而非现实领域，是问题空间在解决空间的映射，可能和问题空间中的概念不一致。

UML - 统一建模语言

iterative development and unified process- 递进开发与统一工序，RUP- rational unified process 合理的统一工序，

IBM主导的统一工序，其工具为rational rose

UP - unified process 统一工序，将普遍为人们接受的递进的生命周期和风险控制的开发方法与文档描述完美结合

iteration - 递进单元，是一个可重复的，逐步接近目标开发单元，采用timebox(时间箱)进行控制，周期不宜长，2-6个星期为佳。每个递进单元都有自己的需求分析、设计、实现和测试。

关于iteration 2个星期的假想安排：Monday- Mona's day,月亮女神的一天，很有诗意啊，星期的每一天都代表一个神，翻译成中文有点索然无味了。Monday,其中一人将最新的递进单元的代码逆向为UML图表（使用CASE TOOL），打印或显示值得关注的部分，继而将递进单元的任务和需求分门别类并进行分配。Tuesday,Tyr's day,战神之日，其中一人在白板上画粗略的UML图表并写伪码和设计备注，可用数码相机拍下来。接下来的8天，实现、测试、集成、编译、系统测试、形成递进单元的稳定版。其它可包含的工作：演示、公司股东的评估、为下一次的递进开发作准备。

embrace change: feedback and adaption - 拥抱变化：反馈和适应 --这并非意味着UP鼓励不可控制的、频繁的、以特征迁移为驱动的开发过程，相反它将平衡两者：一套稳定的需求子集和发生变化的需求（来自客户或股东的市场前瞻）。

“是的，这正是我所要求的，可是，我发现我真正想要的不是这个……，呃，稍微有些不同……”，“是的，可是”并不是意味着失败，而是对真正需要的系统的富有技巧性的逼近。早测试，早发现，这是递进开发的优势。早点发现风险、证明关键性的设计决定的可行性而不是等整个系统都完成了才发现。

UP，时间箱控制的递进的适应的开发是其核心。除此之外，还有OO/AD技术的应用，还有很多实用的方法：

1.尽早地在早期的递进版本中解决高风险和关键的问题，早发现，早知道，避免无谓的劳动。

2.让客户参与反馈，诉说需求。

3.用UML语言可视化地建模

4.谨慎处理客户需求

UP phases - 统一工序的工序

Inception- 开始： 粗略的蓝图，应用场合，范围，模糊估计

Elaboration- 创建：改善的蓝图，核心架构的递进实现。解决高风险问题。确定主要需求，切近实际的估计。

Construction - 构造：余下的较低风险的和相对容易的部分的递进实现，准备系统的配置工作。

Transition -交付： Beta测试，配置。

这不是古老的瀑布式或按顺序的开发方法，即：先确定所有的需求，然后实现所有的设计。

Inception不是需求阶段，而确切的，可称为可行性分析阶段，做充分的调查以便作出做和不做的决定。

Elaboration也不是需求阶段或者设计阶段，而是核心架构的递进实现，高风险被排除的阶段。

一个开发周期包含多个递进单元，每隔递进单元都有自己的需求分析、设计、实现和测试，这个东东用COM组件做好像不错哎，每个递进单元就是一个组件。

UP disciplines (was workflows) - 统一工序规范（旧称流程）。规范是各主题的行为集合的规范，比如需求分析的主题中的所有的行为规范。

artifacts - 作业，一个通用的术语，用来描述劳动产品：代码，网络图，数据库方案，文档，图表，模型。

主要讨论以下的规范：

1.建立事务模型，其中包括事务的物件模型，对于大型的事务分析或事务流程在设计还包括了事务处理的动态模型。

2.需求，即需求分析，比如研究应用场合，确定哪些是非功能性的需求。

3.设计，设计的所有方面，包括总体架构，物件，数据库，网络，等等。

每个工序或者说阶段对各规范的开销是不同的，比如在elaboration,建立事务模型的规范占大头。

 

应用场合研究 NextGen Pos System
User Interface-界面
Application Logic and Domain Objects-应用逻辑和事务对象
TechnicalServices- 技术服务 - 提供外部接口（如数据库，日志等）的通用对象和子系统。

NextGen 应用场合研究着重于问题空间对象，分配职责给它们来实现应用需求。以物件为导向的设计也将应用于创建技术服务。
第二部分 INCEPTION -开始
* 软件概览和适用范围
* 可行吗？
* 买还是自己做？
* 要投入多少？
* 还要继续做吗？
概览和评估离不开需求分析.开始阶段不是定义所有的需求、准确地估计或者项目计划。

 

理解需求

FURPS+MODEL
功能 - 在应用场合模型(USE CASE MODEL)和软件概览中的系统特征列表中探讨、记录
易用性
可靠性
性能
可维护性
+: 使用条件 接口 配置 安装包 版权信息

 

应用场合模型

关键的态度: How can using system provide observable value to the user, or fulfill their goals?

老黄给我上了一堂UML之应用场合的课：

1.老黄说twilight做lrc不方便，我说twilight不是用来做lrc的，老黄从用户---一个语言学习者的角度来举例说明制作lrc是用户非常需要的功能，我觉得挺有道理。

2.有用户提出能否为每句话设定复读次数，我说这个太繁琐，显然是忽视了用户的需求。

3.对于空白或用户不需要的音频删除或跳过，这个功能是极佳的，应该支持。

4.老黄提出支持双语lrc，这个对初学者来说不错。

老黄给我上了一堂UML之应用场合的课,完完全全是活生生的一个Scenario--情景描述，他从用户兴冲冲地购买了音像教材后，使用起我开发的Twilight

复读软件，发现没有LRC…… 而我是一个钟道隆的fans，所以我的Scenaria可能又是另外一番情景。

应用场合是在讲故事，有演员，有情节，它就是一系列情节。
不要开功能和特征清单，相反应用场合将特征和功能放在以用户目标为导向的情境中（in contrast,use cases place features

and functions in a goal-oriented context.）
应用场合是需求，主要是功能性的需求，指示系统将做什么。
应用场合定义了一个承诺或契约，那就是系统将如何作为。
黑箱子风格和系统职能
应用场合 UC1: 处理销售

主要参与者：出纳员
股东和利益：
--出纳员: 希望准确无误，录入商品快速，没有支付错误，因为钱箱少了钱要从他/她的工资里扣。
--销售员: 希望销售佣金及时更新
--顾客: 希望买东西方便快捷，获得购买的发票以便退货。
--公司: 希望准确无误地记录事务，满足客户的需求。希望记录支付授权服务中心的应收款项。希望系统有容错能力，在某些服务单元（比如远程信用卡验证）不可用时，销售还可以进行。希望账目和仓库自动快速地更新。
--政府税收部门:希望每笔销售都征税，可能有多个税收部门，如国税，州税，县税。
--支付授权中心：希望接收到的数字授权请求遵从正确的格式和协议。希望支付给商店的支付款准确无误地记账。
前提条件：出纳员已经被识别和通过验证。

主要的成功的情景（或基本流程）
1.客户拿着货物和/或服务来到POS机关口付钱
2.出纳员开始一个新的销售
3.出纳员录入商品编号
4.系统记录销售流水项，提供商品项目描述、价格和累计金额，价格由一套计价规则算出。
出纳员重复3-4步骤直到完成。
5.系统显示总价（税收已经被计算）
6.出纳员告诉客户总价并请求支付。
7.客户完成支付，系统处理客户的支付。
8.系统记录成功的销售日志并且发送销售和支付信息到外部的会计系统（或会计和佣金)和仓库系统（来更新库存）。
9.系统提供发票
10.客户拿着发票和货物（如果有的话）离开。

 

扩展（或其它流程）
a.在任何时候，系统失败了：
为了支持恢复和更正账目，保证在使用情景的任何一个阶段，所有事务相关的状态和事件都能被恢复。
1.出纳员重启系统，登录并要求恢复先前的状态。
2.系统重新构造先前的状态
 2a. 系统发现下列异常阻止恢复：
  1.系统显示错误、记录错误并进入一个干净的状态。
  2.出纳员启动一个新的销售。
3a. 非法的货物编号
 1.系统显示错误并拒绝录入
3b. 有多个相同的货物且区分单独的货物并不重要（比如，5个蔬菜汉堡）
 1.出纳员可以录入货物种类和数量。
3-6a：客户请求出纳员去掉某个货物
 1.出纳员录入货物编号以便从销售清单中删除。
 2.系统显示更新后的累计金额。
3-6b：客户请求出纳员取消销售：
 1.出纳员取消销售
3-6c：出纳员挂起了销售
 1.系统记录销售以便客户在任何一个POS终端提货。
4a. 客户不接受系统产生的价目表（比如，客户抱怨某某某某，并还了一个更低的价格）
 1.出纳员重新录入价格
 2.系统显示新的价格
5a.系统发现无法和外部的税收计算系统服务中心通信
 1.系统重试了服务，成功并继续.1a.系统发现通信还是不成功。
  1.系统显示错误
  2.出纳员可手工计算并输入税收或者取消销售。
5b.客户说他们符合打折条件（比如，是商场员工，消费会员）
 1.出纳员发出折扣请求
 2.出纳员输入客户编号
 3.系统根据折扣规则计算并显示打折后的累计金额
5c.客户说他们的帐户可以贷记，想贷记购买
 1.出纳员发出贷记请求
 2.出纳员输入客户编号
 3.系统将贷出足够的钱使得累计金额为0，并减去可贷记余额。

扩展（或其它流程）
a.在任何时候，系统失败了：
为了支持恢复和更正账目，保证在使用情景的任何一个阶段，所有事务相关的状态和事件都能被恢复。
1.出纳员重启系统，登录并要求恢复先前的状态。
2.系统重新构造先前的状态
 2a. 系统发现下列异常阻止恢复：
  1.系统显示错误、记录错误并进入一个干净的状态。
  2.出纳员启动一个新的销售。
3a. 非法的货物编号
 1.系统显示错误并拒绝录入
3b. 有多个相同的货物且区分单独的货物并不重要（比如，5个蔬菜汉堡）
 1.出纳员可以录入货物种类和数量。
3-6a：客户请求出纳员去掉某个货物
 1.出纳员录入货物编号以便从销售清单中删除。
 2.系统显示更新后的累计金额。
3-6b：客户请求出纳员取消销售：
 1.出纳员取消销售
3-6c：出纳员挂起了销售
 1.系统记录销售以便客户在任何一个POS终端提货。
4a. 客户不接受系统产生的价目表（比如，客户抱怨某某某某，并还了一个更低的价格）
 1.出纳员重新录入价格
 2.系统显示新的价格
5a.系统发现无法和外部的税收计算系统服务中心通信
 1.系统重试了服务，成功并继续.1a.系统发现通信还是不成功。
  1.系统显示错误
  2.出纳员可手工计算并输入税收或者取消销售。
5b.客户说他们符合打折条件（比如，是商场员工，消费会员）
 1.出纳员发出折扣请求
 2.出纳员输入客户编号
 3.系统根据折扣规则计算并显示打折后的累计金额
5c.客户说他们的帐户有积分，想用积分购买
 1.出纳员发出积分购买请求
 2.出纳员输入客户编号
 3.系统将相应数量的积分换成钱，使得累计金额为0，并扣掉积分。

6a. 客户说他们原打算付现金，但是现金不够
 1a.客户使用其它的支付方式
 2a.客户取消交易
7a. 现金支付
 1.出纳员仔细输入收入金额
 2.系统显示找零并且开放钱箱
 3.出纳员仔细地将钱存入钱箱并找零。
 4.系统记录现金支付。
7b. 信用卡支付
 1.用户输入信用卡账号信息
 2.系统向外部支付授权服务系统发送支付授权请求

 2a. 系统发现无法和外部系统协调
  1.系统显示错误
  2.出纳员请求客户使用其它支付方式
 3.系统收到了支付的许准并提示出纳员。
  3a.系统收到了支付被否决的信息
  1.系统提示出纳员支付被否决
  2.出纳员请求客户使用其它的支付方式
 4.系统记录了信用卡支付记录，其中包含了支付准许信息。
 5.系统启用信用卡支付签名的输入机制
 6.出纳员要求客户输入信用卡支付签名，客户输入签名。
7c. 支票支付……
7d. 借记支付……
7e. 客户出示优待券
 1.在处理支付前，出纳员录入每张优待券，系统减去相应的金额。系统记录已经使用过的优待券供会计用。
  1a.所购商品不在优待券适用范围。
   1.系统提示出纳员错误信息。
9a. 有折价商品
 1.系统为每个折价商品提够折价方式和折价凭据。
9b. 客户请求赠礼的收据
 1.出纳员请求赠礼的收据，系统打印收据。

特殊要且
--大平板显示器带触摸屏。文字1米远可见。
--信用授权的响应时间在30秒之内，最多占90%的交易时间。
--毫无疑问，当我们访问远程服务（比如仓库系统）失败时，要求系统有容错恢复能力。
--文本国际化
--在阶段3-7可插入其它事务规则

技术和可变的数据类型列表：
3a. 项目编号可由激光条形码扫描器录入或者由键盘录入。
3b. 项目编号可以是UPC, EAN, JAN, or SKU 编码方案的任一种。

3c. 信用卡帐户信息由读卡器或键盘输入。

3d. 信用卡支付签名签在纸上。不过我们预见，两年之内客户希望用上数字签名输入设备。

应用场合的目标和范围
如何知道应用场合,如何知道应用场合是有效的?任务可以细分为不同等级的粒度,从一个或几个小步骤直到构筑企业级的行为.
应用场合应当细分到什么等级,其范围又如何定义?
下列部分考察基本事务处理和目标的简单概念,并将它作为为一个应用程序确定应用场合的框架. 

基本事务处理的应用场合
下面哪个是有效的应用场合?
.商定一个供应合同
.处理退货
.登录
有争论说它们全部都是应用场合,处于不同阶段的应用场合--基于系统的范围、参与者和目标。在介绍完基本的事务流程后，我们将对它们作出评估。
对于一个POS应用场合研究，与其泛泛地问“什么是一个有效的应用场合”，不如问“为需求分析所作的应用场合的陈述应当细分到什么等级”。

指南：EBP 使用场合
基本事务处理单元
EBP是一个事务处理工程领域的一个术语，定义如下：
它是一个任务，是一个人、在一个地方、一次、对一个事务事件作出的响应行为。所谓的事务事件，它增加了可量化的事务数据并且保持数据的一致状态。比如，批准贷记或价格表（原价格表就作废了）
这个定义不能按字面理解：如果一个基本事务处理单元需要两个人，或者某人不得不四处走走，是不是该应用场合是无效的呢？也许不是，该定义感觉上是对的，它不是一个小步骤，如“删除一行项目”或者“打印该文档”。

EBP级别的应用场合是一个用户目标级别的应用场合。与其问“应用场合是什么”，不如问“你的目标是什么”
想象一下我们来到了需求分析工作室，我们可能会问：
1.你要做什么？
2.你的目标是什么
回答第一个问题表示了现有的解决方案和步骤以及其复杂程度。
回答第二个问题,如果配合调查,可以将系统引入更高的目标层次(该目标的目标是什么?),为新的和改进的方案打开视野,聚焦于商

务价值,真正理解利益相关方的需求.
例子：使用EBP准则
系统分析师：在使用POS系统过程中，你的目标是什么?
出纳员：只有一个，登录快，还有，完成并记录交易。
系统分析师：为什么要登录？想想看，是什么更高层次的目标让你认为要登录？
出纳员：我的身份可以得到确认，这样我就可以利用系统完成并记录交易以及做其他事情。
系统分析员：还有深层的原因吗？
出纳员：为了防小偷、数据崩溃和窃取公司机密。
注意，系统分析师为了发现更高级别的用户目标所采取的探索目标层次的策略是符合EBP指南的：理解行为的真实意图，理解目标的背景。
“为了防小偷……”是最高层次，它可以被叫做企业目标，但不是EBP目标。尽管它能激发新的思考问题和方案的思路（诸如彻底省掉POS系统和出纳员

），不过我们还是将它放置一旁。
更低的目标层次“确定自己的身份并验证”似乎更接近于用户目标层。但是，他是EBP层次吗？ 它并没有增加可观察的或可测量的事务数据啊。如果

CEO问，“你今天做了什么？”你回答“我登录了20次！”，他脑子将一片空白。因此，这是一个次级目标，是处于某项服务中的目标，而不是EBP或用

户目标。相反，完成并记录交易符合成为一个EBP或用户目标的标准。
在另外一个例子，有些商店有一个环节叫作“现金存入”，即出纳员将自己的放钱的抽屉插入终端，登录并告诉系统里抽屉里有多少钱。“现金存入”

是一个EBP级别的应用场合；而登录不是，它只是一个支持“现金存入”目标的一个子目标。

发现主要的参与者，目标和应用场合
1 确定系统边界
2 确定主要参与者
3 确定每个参与者的用户目标
4 定义应用场合来满足他们的用户目标；通常，用户目标和应用场合一一对应，但至少有一个例外，我们将检查它。

1 确定系统边界
2、3 发现主要参与者和目标
我们人为地在用户目标和主要参与者中间划一条线。在需求分析工作室，大家进行头脑风暴式的讨论并确定用户目标和参与者。有时，目标引出参与者，有时参与者提示了目标。准则：首先着重讨论主要参与者，因为他可以建立一个框架已进行后续的探究。

系统边界决定谁是主要参与者

另一个帮助发现参与者、目标和应用场合的方法是确定外部事件。

4 定义应用场合
为每个用户目标定义一个EBP层次的应用场合。用用户目标来命名应用场合，如：目标：处理一个交易； 应用场合：处理交易。用一个动词作为开头
命名应用场合。一个目标对应一个应用场合的例外：将CRUD（Creat，Retrieve，Update，Delete）单独的目标合并成一个CRUD应用场合。比如，

目标“编辑用户”、“删除用户”等可以合并为一个管理用户的应用场合。
 
恭喜：应用场合大功告成但还不完善
需要沟通和参与
NextGen POS开发小组总是处在一系列短期的递进开发周期中，在多个需求专题谈论会中，撰写应用场合，不断增加用户需求集，

根据反馈进行完善和调整。问题专家、出纳、编程人员积极地参与应用场合的定义。在出纳、其他的用户和编程人员之间没有中间人，而是直接进行沟

通。
很好，但还不够。写成的需求说明书似乎让人觉得它就是对的，事实并非如此。它们可能缺少关键信息并包含错误的陈述。我们的的解决方案不是“瀑

布式”流程，即已开始就尽力写好需求，让它尽善尽美。尽管我们也尽力在可用的时间内把需求做得尽量完美

，但是它永远不可能完美。
我们需要一种不同的方式，也就是递进式开发，但是我们还需要--不断地进行个人沟通，每天，开发人员与问题专家（理解该领域并能做出需求判定的

人）密切地参与开发和沟通。所谓的问题专家，当有了疑问，编程人员可以问他并很快得到解释。比如，XP实践（极限编程实践）包含了一个极好的建

议：用户与开发人员共处一室，全职参与项目开发。

 

以本质III自由风格撰写应用场合
新的，改进的！指纹机的应用场合
调查和询问目标而不是任务和步骤的理念鼓励开发人员关注需求的本质--它们背后真正的意图。比如，在需求专题讨论会上，出纳员也许会说他的目标
之一是登录。出纳员也许想到了一个GUI对话框，用户ID和密码。这只是一个获得某个目标的机制而不是目标本身。通过调查目标层次（这个目标的目

标是什么？），系统分析师会得到一个与机制无关的目标：识别身份并通过鉴定，或者更高的目标：防小偷。
这种发现目标的方法能够开拓开发人员的视野，发现新的改进了的解决方案。比如，带有生物特征感应器的键盘和鼠标，通常是一个指纹机，现在已经

很普通很便宜了。如果目标是“识别身份和鉴定”，那么为什么不用一个带有生物特征感应器的键盘呢？也许还要考虑易用性的问题，比如事先录入用

户的指纹，他们的手指有油脂吗？他们有手指吗？

本质风格
这个概念被总结成不同的应用场合准则，如“不要理会用户界面，关注意图”，Larry Constantine 在如何创建更好的用户界面和易用性工程的课题中

最全面地探索了该准则的驱动机制和符号。他把这种风格叫作“本质风格”--不考虑UI细节，只关注用户意图。在本质书写风格中，陈述部分被表示成

某个级别的用户意图和系统职责而不是他们的具体行动，它们不考虑技术和机制的细节，特别是与GUI相关的技术和机制的细节。

“不要理会用户界面，关注参与者意图”
注意在开发词典中，目标被定义成意图的同义词，显示了Constantine本质风格的概念和本章强调的以目标为导向的观点之间的联系。诚然，在本质风

格的应用场合中，很多参与者意图可以被认为是子功能目标。

截然不同的例子
本质风格
假设一个用户管理应用场合要求身份识别和鉴定。Constantine所鼓励的本质风格使用了两列格式，尽管如此，也可以写成一列。
参与者意图   系统职责
1 管理员识别自己  2 鉴定其身份
2 ……

实现这些意图和职责的设计的解决方案是宽泛的：生物特征感应器，图形用户界面（GUI),等等。

具体风格
相反，有一种具体应用场合风格。在这种风格中，用户界面的设计被嵌入到应用场合的文字中，甚至还包含了用户界面的屏幕拷贝

，讨论窗口之间的导航，窗口部件的操作，诸如此类。
1 管理员在对话框中输入ID和密码（见图3）
2 系统鉴定管理员
3 系统显示“编辑用户”的窗口（见图4）
这种风格对以后的GUI设计有用，但是在需求分析阶段并不合适。

参与者
参与者是任何有行为能力的对象，包括当前讨论的系统(SuD--system under discussion)本身（当它调用其它系统的服务时，它就是一个参与者）。主

要参与者和辅助参与者将出现在应用场合文本中的行动步骤中。参与者不光可以是人，也可以是组织，软件和机器。 有三种与SuD相关的外部参与者：
.主要参与者 -- 其用户目标通过使用Sud的服务而实现，例如，出纳员，如何找到他？-- 通过寻找驱动应用场合的用户目标。
.辅助参与者 -- 为SuD提供一项服务（例如信息）。自动支付授权服务是一个例子。通常是一个计算机系统，但也可以是一个组织或个人。
如何找到他？-- 通过理清外部的接口和协议。
.幕后参与者 -- 在应用场合的行为中有相关利益，但既不是主要参与者也不是辅助参与者，例如，政府税收部门。如何找到他？

-- 确保所有的必要的利益关系都被分辨和满足。幕后参与者的利益有时很微妙或者容易漏掉除非这些参与者被明确命名。

应用场合图表
UML提供了应用场合图表标记来表示应用场合和参与者的名字以及他们之间的关系。
应用场合图表和应用场合关系在应用场合的工作中是次要的。应用场合是文字性的，写应用场合意味着撰写文字。

初学的或学究气浓的建模者的公共特征就是以应用场合和应用场合关系为主，而不是撰写文字。世界级的应用场合专家，如Andrson,Fowler,Cockburn

与众不同，不看重应用场合图表和应用场合关系，而看重文字。我们要引以为戒，让应用场合尽量简单，提供一个简洁的可视的系统关系图表，表示外

部参与者以及他们是如何使用系统的。

建议：画一个简单的应用场合图表并建立一个参与者-目标对应表。
应用场合图表是一个极好的系统关系图。它建立了一个很好的关系图表，显示了系统的边界，什么是它的外部，它是如何被使用的。它提供了一个交流

工具，总结了一个系统和它的参与者的行为。图6.2显示了NextGen系统的部分应用场合关系图表。

画图表的建议--略

其它背景下和低层次的特征列表中的需求分析
建议: 尽可能用应用场合代替详细的低层次的特征列表.

高层次的系统特征列表是可以接受的

什么时候详细的特征列表是适用的?
有时候应用场合不是真正地适用.有些应用程序需要特征驱动的观点.比如,应用服务器,数据库产品和其他中间件或者后台系统,需要用特征这个术语来

考虑和改进.应用场合不适用于它们,或者不适用于它们的基于市场需要的改进.

应用场合不是以物件为导向的

统一工序中的应用场合
应用场合在UP(统一工序)中是关键的和核心的,UP--统一工序,它鼓励以应用场合为驱动的开发方式. 这意味着:
.需求主要在应用场合中被记录.其他需求技术(比如功能清单)是次要的.
.应用场合是递进式开发的重要部分.一个递进单元的工作很大一部分是由选择某些应用场合情景或整个应用场合来定义的.并且应用场合是预计工作的

关键输入项.
.应用场合的实现驱动着整个设计.那就是,开发小组设计相互协作的对象和子系统来执行或实现应用场合.
.应用场合经常影响用户手册的组织方式.

在递进开发中的各阶段的应用场合和需求说明
这一部分重申在统一工序和递进开发中的一个关键概念：需求说明在整个递进开发中的时间表和工作量。表6.1给出了一个例子（不是普遍适用的处方

），它展示了如何与统一工序关于如何开发需求的策略相沟通。
注意开发小组仅仅当10%的需求被陈述后就着手于开发系统的核心部分。事实上，这是一个有意的需求分析的延迟，该需求分析工作直到第一次创建的

递进单元将近结束才得以继续。
这是递进开发与瀑布式开发的主要不同点。有关系统核心部分的关系到产品品质的开发尽早开始，早早地先于所有的需求被获知。

创建各UP作业的时间表 --略

确定其它需求
   当想法失败了,借口总是现成的.-- Johann Wolfgang von Goethe
目标：撰写补充说明书、术语表和概览。比较和对照系统特征和应用场合。将概览与其它作业相联系，和递进式开发相联系。定义品质特征。
仅仅写应用场合是不够的。还有其它需求需要被确定，比如文档、安装包、版权信息等。这些在补充说明中被定义。
术语：定义术语和约定，可以充当数据词典的作用。
概览：概括了项目的大致面貌。它解释了为什么开发该项目，解决什么问题，谁是相关利益方，他们的需求是什么，解决方案大致是怎么样的。
引用：概览定义了所要开发的产品的利益相关方的观点，用利益相关方的主要需求和所需特征的术语来定义。包含了可视化的需求轮廓，为更详细的技

术需求提供基础。
这一章后面略

从开始到创建
  The hard and stiff breaks. The supple prevails. 柔弱胜刚强 --道德经,哈哈，编程上升到了艺术和哲学的高度，东方的智慧和西方的智慧本是

相融的。
目标：定义创建步骤，推动后续章节的演绎。

介绍
创建是一系列的递进开发：
.主要的需求被发现和被固定成某一个版本
.主要的风险被排除或者放弃开发该项目
.核心架构部分被实现和验证，架构在很少情况下不存在风险（建个和别人类似的网站是没有风险的，也不需要前期的递进开发，不需要验证核心部分

）
该书在这个阶段着重介绍OOA/D在UML、模式和架构中的应用。

检查点：“开始”阶段发生了什么？
NextGen POS 项目的“开始”阶段也许只要一个星期就够了。完成的“作业”应当是简洁的不完整的，探究也非深入的。
它不是一个项目的需求分析阶段，而是一个很短的阶段，来决定其可行性、风险及其范围，并决定该项目是否值得更深的探究（在创建阶段）。不是所

有在开始阶段的行为都被涉及，其探究强调了以需求为导向的“作业”。开始阶段可能涉及的行为和作业包括：
.一个很短的需求专题研讨会
.命名大多数的参与者、目标和应用场合。
.用简单的格式撰写大多数的应用场合，10-20%的应用场合被详尽地描述，以提高对项目的范围和复杂性的理解。
.大多数影响大且有风险的品质需求被识别。
.撰写V1.0版本的概览和补充说明书
.风险清单
 >比如，公司迫切需要一个POS系统的演示程序，以便在18个月后，在德国的汉堡的POS世界商业展中演示。但是开发一个演示程序所需的工量

无法估计（哪怕是粗略的估计），除非进行更深入的探究。
.技术上的设想验证原型和其它探索为某些特殊需求所做的技术可行性调查。（Java Swing 在触摸屏上能良好地工作吗？）
.建立以用户界面为导向的原型，阐明功能需求。
.建议什么模块需要购买、或自己开发、重用、将在创建阶段改进。
>比如， 建议购买税收计算器软件包
.提议高级别的候选的架构和模块
>这不是一个详细的架构说明，也不是最终的或正确的。它是一个简要的推测，作为在创建阶段中的探究的起点。比如，“一个Java 客户端程序，不是

一个服务器程序，用Oracle的数据库，……”在创建阶段，也许它将被证明是有价值的或者发现它是一个馊主意并放弃。
.计划第一次递进开发。
.候选的开发工具清单

着手创建
创建是初始的一系列递进开发，开发小组在创建阶段做一系列的调查，实现（编程和测试）核心架构，阐明大多数的需求，解决高风险的问题。在UP，

风险包含了商业价值。因此，早期的工作可能包含情景的实现，这些情景被认为是重要的，不过技术风险不是很大。
创建通常由2-4个递进开发单元组成。建议每个递进开发单元的周期为2-6个星期（除非开发小组的人数很多）。每个递进开发单元都有时间限制

（timeboxed），也就是说，它有一个最后期限。如果开发小组不能按时完成，那么需求就放到计划表的后面，这样递进单元能够在递进开发结束时，

获得一个稳定的、经过测试的版本。
创建阶段不是一个设计阶段，也不是一个建模阶段，即建好所有模型，为在构造阶段的实施做准备。如果是那样的话，就是在递进开发和统一工序上又添加了瀑布式开发的概念。
在这个阶段，开发人员不是在创建最终被丢弃原型，而是最终系统的产品级的部分。在有些UP描述中，可能被误解的术语“架构原型”是用来说明局部的系统。这不意味着它是一个最后将被丢弃的试验品，在UP，它意味着一个最终系统的产品子集。 通常，它又被佳作“可执行的架构”或者“基础架构”。

一句话来描述“创建”： 建造核心架构，排除高风险因素，定义大多数的需求并且估计总的计划和人力安排。
在“创建”阶段，一些关键的概念和最好的实践将被罗列：
.做短期的受时间控制的风险驱动的递进开发。
.尽早开始编程
.灵活的设计、实现和测试核心和架构的风险部分
.早测试，勤测试，切合实际地测试。
.根据测试结果、用户意见和开发人员的意见进行调整
.详细撰写大多数的应用场合和其它的需求（通过开一系列的专题研讨会，每次递进开发开一次研讨会）

“创建”在架构上的重要性
早期的递进开发建造核心架构并证明其可行性。 作为一个下一代的POS工程