面向对象的分析与设计
UP – Inception & Elabpration 1
Xiao ding TSEG
UP基本结构
1,UP是一个软件开发过程
2,软件开发过程是一个将用户需求转化为软件系统所需要的活动集合。
3,UP不仅仅是一个简单的过程，而是一个通用的过程框架。
4,UP使用 UML来制定和描述软件系统的所有视图。
5,UP的突出特点：用例驱动、以构架为中心、使用迭代和增量的开发模式
UP生命周期
UP是在重复一系列组成软件系统生命周期的循环。每次循环都以向用户提供一个产品版本作为终结。
每次循环都包括四个阶段,初始、细化、构造和移交 。每个阶段又进一步细分为多次迭代过程
每次循环都产生系统的一个新的 版本 (version)，每个版本都是一个可交付的产品它包括由能够编译和运行的构件所体现的源代码、各种手册和相关的交付品
所完成的产品包括 一整套 需求、非功能性需求和测试用例等文档，还包括构架和可视化的模型
UP 的迭代增量开发模式
UP的每个阶段可以进一步分为几个迭代过程。它是生成可执行产品版本（内部和外部）的完整开发循环，是最终产品的一个子集，从一个迭代过程到另一个迭代过程递增式增长形成最终的系统。
迭代和增量的三个关键点
计划一小步
说明、设计和实现一小步
集成、测试和运行每次迭代（一小步）
UP的其它重要概念
在早期迭代中解决高风险和高价值的问题
不断地让用户参与评估、反馈和需求确认
在早期迭代中确定系统的核心架构
不断地验证质量，尽早并经常性的实施测试
进行可视化建模（使用 UML）
认真管理需求，实施变更管理和配臵管理
UP里程碑
每个阶段都以一个里程碑作为结束标志。 通过获得一组 可用的制品 来定义每个里程碑。
在每个阶段结束时进行评估以确定是否实现了此阶段的目标。 良好的评估可使项目顺利进入下一阶段。
迭代和增量模型的特点
将项目分解成许多袖珍项目，每一个袖珍项目都作为一次迭代
每个这样的袖珍项目都像过去的瀑布模型，因为它处理的是瀑布模型的活动。我们可以将每次迭代标注为一个,袖珍瀑布,
迭代不是一个完全独立的实体，它是项目的一个阶段，它在很大程度上是作为项目的一部分而得到的
规划人员设法对迭代进行排序以得到一条有序的途径，使早期的迭代为后期的迭代提供认知基础
项目的早期迭代增进了对需求、问题、风险和方案领域的了解，而后期迭代产生的附加增量最终构成了外部版本，即客户产品
最终的成功是一个一直前进的迭代系列；即不必因为在后期的迭代中了解到的一些问题而回退 2 ~ 3个迭代去修补模型使用迭代和增量的理由
为了尽早处理关键风险和重要风险
为了建立一个构架来指导软件开发
能够处理不断变化的需求，并提供灵活变化的机制
为了提供一个开发过程，使所有工作人员更高效地工作合理规划迭代过程
项目经理在当前迭代的目标未达到之前不应同意开始下一次迭代。否则，就会导致必须改变计划来适应新的情况确定迭代次序
用例设定了一个目标；而构架建立了一个模式。
记住这个目标和模式，管理人员可以在人力资源充分的情况下规划出进行产品开发的顺序迭代和增量的优点
允许变更需求,需求总是会变化，这是事实。
逐步集成元素,集成并不只是简单的“一锤定音”。在迭代式方法中，
集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量
40% 的那段较长的、不确定的且棘手的时期，现在分散到六至九个集成部分中，每一部分要集成的元素都比过去少得多。
及早降低风险,因为风险一般只有在集成阶段才能发现或得到处理。
有助于组织学习和提高,团队成员有机会在整个生命周期中边做边学，
各显其能。测试员可以早一些开始测试，技术文档编写员可及早开始编写，其他人也是如此。
提高复用性,早期迭代中的设计复审可使构架设计师确定毋庸臵疑的潜在复用部分，并在以后的迭代中开发和完善这些公用代码。
生成性能更强壮的产品,性能上的瓶颈可以尽早发现并处理，而不象在交付前夕，此时已来不及处理。
迭代流程自身可在进行过程中得到改进和精炼,一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。
初始阶段 Inception
主要目的是将一个好的想法发展为最终产品的一个构想。
本质上，该阶段应回答下面三个问题：
系统向它的每个主要用户提供的基本功能是什么？
该系统的构架看起来是什么样子？
开发该产品的计划如何？开销多大？
该阶段中 最关键用例的 简化用例模型 可以回答第一个问题。
在这个阶段,构架是试验性的,通常只是一个包括主要子系统的大致轮廓。
在这个阶段，要确定最主要的风险及其优先次序，要对细化阶段进行详细规划，并对整个项目进行粗略估算。
注意，该阶段的目标不是定义所有的需求初始阶段的目标和任务
建立项目的 软件规模和边界条件,包括运作前景、验收标准以及希望产品中包括和不包括的内容。
识别系统的 关键用例
对比一些主要场景，展示至少一个备选构架
给出用户提出的非功能性要求描述
评估整个项目的 总体成本和进度
评估潜在的风险（源于各种不可预测因素）
准备项目的支持环境。
在阶段后期为细化阶段 制定迭代计划初始阶段的工件集
Vision,核心项目需求、关键特性、主要约束的总体构想
Business Case,业务用例
Use-case Model,初始的关键用例模型，占 10-20%的数量
Risks List
Plan
Project-specific templates
Software Development Plan
Iteration Plan
Product Acceptance Plan
Development Case
Tools
Glossary
电子收款机（ POS）系统案例
POS机是一个计算机化应用的系统，用于记录销售信息和处理支付过程，一般超市和零售商店都会用到。该系统的假设条件如下：
系统包括终端系统、条码扫描仪等硬件，还有相应的软件系统；
它可能还需要与其他系统存在接口，比如信用卡支付系统、库存系统、记费系统等；
该系统具有一定的容错性能，比如在与库存系统暂时终端连接时，
仍能够进行物品的销售，不至于使系统瘫痪；
多样化的终端接口：瘦客户 Web终端,PC、触摸屏、无线 PDA
能适应不同商店业务销售的功能要求，提供一种灵活性和定制能力的功能（作为系统开发的复用需求）
POS案例 -Step1
初始阶段应该考虑以下问题：
项目的前景如何？
业务背景和业务流程是什么？
可行性如何？项目是否停止或继续进行？
购买还是开发？
粗略估计一下成本，估计收益。
主要目标：
只进行一定的研究，得到未来新系统的可行性以及实现系统总体目标的合理判断，并确定是否值得继续深入研究系统即可。（深入的研究是细化阶段的工作）
概括为：
预见项目的范围、前景和业务案例；
项目相关人员是否就项目的前景达成基本的一致，项目是否值得继续进行认真的研究。
POS机案例 -Step2
该阶段的主要工作成果集
项目前景
业务背景及业务流程
关键用例模型（ 10-20%）
补充性规格说明
词汇表
….
POS机案例 -Step3
用例建模的基本过程：
1.选择系统边界
POS作为一个待构建的系统，包含软件,POS机、输入终端等，收银员、支付授权、税金计算等不包括在系统之内。任何系统之外的事物都在系统边界之外。
2.识别主要角色
主要角色：在使用系统服务的过程中满足自己的用户目标的那些参与者。 找出用户目标
次要角色：为系统提供服务的那些参与者。 说明外部接口和协议
后台角色：对用例的行为感兴趣。 保证找到并满足所有必要的兴趣。
3.识别主要角色的目标
一般来讲：第 2和第 3步是同时进行的。
POS机案例 -Step4 寻找 ACtor
顾客：
购买商品、退货、支付费用
希望得到快速的服务、能清楚地看到购买的商品和价格信息，得到收据以便退货
收银员：
处理销售、处理退货、入款、出款
希望能快速准确地输入，切无支付错误（出现错误时，将从其薪水中扣除）
经理：
启动、关机、处理销售异常操作
希望能快速地执行相应的操作，易于更正收银员出现的错误
系统管理员：
添加用户、修改用户、删除用户、安全管理、系统表管理
希望能方便地添加使用 POS机的用户，并针对不同用户赋予不同的操作权限等
销售活动分析系统：
分析销售数据和销售表现
能够定期快速地获得必需的数据，制定相应的统计报表
库存系统、记费系统等 ……
主要参与者的确定
主要参与者是收银员还是顾客？
答案：收银员。
问题：为什么？为什么不是顾客？
主要原因取决于系统的边界，以及有关系统设计的主要对象。
如果将企业（超市）和销售服务视为一个整体，则主要参与者是“顾客”，顾客的主要目标是通过商店购买商品然后离开。
然而从 POS系统建设的角度出发，认为使用系统的用户是收银员，他（她）的目标是使用 POS机并通过该机处理销售交易
POS机案例 -Step5 确定用例
顾客：购买商品
收银员,处理销售、销售前准备、结束销售
经理：开关机、处理销售异常
系统管理员,用户管理、权限安全管理
……
由系统的主要参与者确定系统的关键用例
销售
用户管理
权限安全管理
POS机案例 -Step6 用例图
绘制初始用例图用户管理
( f r o m < U s e C a s e N a m e > )
安全管理
( f r o m < U s e C a s e N a m e > )
系统管理员
( f r o m A c t o r s )
收银员
( f r o m A c t o r s )
认证系统
( f r o m A c t o r s )
计费系统
( f r o m A c t o r s )
<<角色 >>
销售
( f r o m < U s e C a s e N a m e > )
POS机案例 -Step6 关键用例描述
用例,销售
主要参与者,收银员
项目相关人员及其兴趣：（参见第 19页）
前臵条件,收银员必须已经被识别和授权
后臵条件,存储销售信息、更新账目和库存信息、生成收据等
主要成功场景：
1.顾客携带商品到达 POS机收费口
2.收银员开始一次新的销售
3.收银员输入商品标识
4.系统记录单件商品，并显示该商品的描述、价格、累加值。
收银员重复 3～ 4步，直到商品输入结束。
5.系统显示总值并计算税金。
6.收银员请顾客付款。
7.顾客支付，系统处理支付。
8.系统记录完整的销售信息，并将销售和付款信息发送到外部的帐务系统和库存系统。
9.系统打印收据
10.顾客带着商品和收据离开。
……
POS机案例 - step7 其他文档编写用例模型只是描述了系统的功能性需求，其他需求放在下列工件中描述：
前景（ vision）：概述项目的远景。用简洁的语言表达项目总体想法，包括：项目为什么被提出？有哪些问题？有哪些项目相关人员？他们需要什么？以及提出了哪些解决方案等。
补充规格说明：未在用例中描述的 FURPS+需求。
术语表：术语及其定义，还可以用作数据字典。
需求,FURPS+
Function（功能）：特性、能力、安全性
Usability（可用性）：人性化因素、帮助和文档；
Reliability（可靠性）：故障周期、可恢复性、可预测性；
Performance（性能）：响应时间、吞吐量、准确性、有效性；
Supportability（可支持性）：适应性、可维护性、国际化、可配臵性。
＋：一些辅助性和次要的因素。
Implementation（实现）：资源限制、语言和工具、硬件等；
Interface（接口）：与外部系统接口所加的约束；
Operations（操作）：系统操作环境中的管理
Package（包装）
Legal（授权）：许可证或其他方式。
前景 Vision page1
修订历史
简介
定位
商业机会
问题综述
产品定位综述
替代方案和竞争对手
项目相关人员描述
项目相关人员（非用户）概述
用户概述
项目相关人员主要的高级别目标和问题
用户级别目标
用户环境前景 Vision page2
产品纵览
产品远景
优点概述
假设和依赖
成本和定价
授权和安装
系统特性概述
系统特性是系统提供的一个外部可观测到的服务，这种服务能够 直接满足项目相关人员的需要。
特性是系统能做的事情。 系统会做 <某特性 >，比如记录销售记录、
支付授权（信用卡、借记卡、支票）
其他需求和约束补充性规格说明 page1
修订历史
简介
功能性（ 跨越许多用例的一般功能）
日志和错误处理
可插入的业务规则
安全性
可用性
人为因素，比如屏幕的分辨率要求
可靠性
可恢复性：外部服务发生错误的时候，尽量采用本地方法来解决，
以使交易能够完成。
性能：交易的处理速度
可支持性
适应性
可配臵性
实现约束,用户要求使用 Java技术的解决方案
采购的组件
免费的开放源码的组件
接口
值得注意的硬件及其接口
软件接口
领域（业务）规则,规定一个领域或者业务如何操作，如：
退货、折扣等 。
法律问题
有关感兴趣的业务规则,商品定价,信用卡支付需要签名、条形码产品等补充性规格说明 page2
术语表 Glossary
修订历史
定义
术语
定义和相关信息
别名细化阶段 Elaboration
详细说明系统的绝大多数用例,并根据关键用例的实现在第 1-2次迭代中设计出系统的构架
最关键用例都要在这个阶段具体化。 该阶段的结果是构架基线
在细化阶段末期，要规划完成项目的活动，估算完成项目所需的资源。
该阶段的关键问题是,用例、构架和计划是否足够稳定可靠，风险是否得到充分控制，以便能够按照合同的规定完成整个开发任务。
细化阶段的目标和任务
确保构架、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定完成开发所需的成本和进度。
处理在构架方面具有重要意义的所有项目风险
建立一个已确定基线的构架
制作具有产品质量构件的演进式 原型
细化前景文档
在细化阶段后期为 构造阶段 制定详细的迭代计划
建立支持环境。这包括创建开发案例、创建模板和指南、
安装工具细化阶段的工件集
Vision
Prototypes
Use-case Model,至少 80%的用例要完成，所有用例均被识别，大多数用例描述被开发
Domain Model,结合用例模型完成相应的领域模型构建
Analysis Model,可选，主要用于帮助系统结构的确定
Design Model,结合用例给出系统的静态和动态结构
Data Model,结合用例模型和领域模型给出相应的数据模型
Implementation Model,将部分用例转化为代码
Risk List
Tools
Software Architecture Document
Software Development Plan
Iteration Plan
细化阶段：迭代 1
POS机案例 确定迭代次数
进入到细化阶段的首要工作就是确定阶段的迭代次数
根据细化阶段的主要目标：构建架构基线，来确定具体的迭代次数
一般情况下，通过实现 2-3个用例来证明架构的稳定性
本案例计划使用两次迭代细化阶段：迭代 1
构建领域模型 Domain Model
领域模型是 OO分析中最重要的和经典的模型，它阐述了领域中的重要业务概念
领域模型是 UP过程的可选制品，但领域模型很大程度上会影响用例模型分析和构建，甚至是设计模型中的软件对象。
领域模型的构建 限定于当前迭代所分析的用例,它能够不断地演进用以展示相关的重要概念。
定义：是对领域内的概念类或现实世界中对象的可视化表示，而非软件对象。也称之为概念模型、分析对象模型、
领域对象模型。
细化阶段：迭代 1
领域模型 Domain Model
应用 UML表示法,领域模型被描述为一组没有定义操作的类图,提供了概念透视图，用以展示：
领域对象或概念类
概念类之间的关联
概念类的属性
概念类的定义：是思想、事物或对象，可以从其符号、内涵和外延来考虑
符号：表示概念类的词语或图形
内涵：概念类的定义
外延：概念类所适用的一组实例表示,销售,交易的事件、具有时间和日期销售 1、销售 2… 销售 n
细化阶段：迭代 1
领域模型不是软件组件模型
领域模型所关注的仅仅是客观世界中的事物并将其可视化，而非诸如 Java或 C#类的软件对象。
以下元素不适用于领域模型
软件制品，例如窗口、界面、数据库
软件模型中具有职责或方法的对象领域模型软件制品，不属于领域模型销售数据库软件类制品细化阶段：迭代 1
降低与 OO建模之间的表示差异
OO的关键思想：领域层软件类的名称要源于领域模型的信息和职责
这样可以减小人们的思维与软件模型之间的表示差异启发了软件对象及其名称细化阶段：迭代 1
创建领域模型的原则
以当前迭代所关注的需求为界
寻找概念类
将其绘制为 UML类图中的类
添加关联和属性
寻找概念类的三条策略
重用和修改现有的概念模型
根据经验使用分类列表
根据用例说明确定名词短语细化阶段：迭代 1
使用分类列表寻找概念类概念类分类 示例 概念类分类 示例物理或具体对象 RegisterAirplane 抽象名词的概念 HungerAcrophobia
事物的设计、
描述和规范
ProductSpecification
FlightDescription 组织
SalesDepartment
ObjectAirline
位臵 StoreAirport 事件 Sale,Payment,MeetingFlight,Crash,Landing
交易 Sale,PaymentReservation 过程 SellingAProductBookingASeat
交易项目 SalesLineItem 规则和政策 RefundPolicyCancellationPolicy
人的角色 CashierPilot 分类 ProductCatalogPartsCatalog
其他事物的容器
Store,Bin
Airplane
有关工作、契约、财务和法律事物的记录
Receipt,Ledger,
EmploymentContract
MaintenanceLog
容器包含的元素 ItemPassenger 财务设施及服务 LineOfCreditStock
在该系统之外的系统
CreditPaymentAuthorizationSystem
AirTrafficControl
手册、文档、引用论文、书籍
DailyPriceChangeList
RepairManual
细化阶段：迭代 1
通过识别名词短语寻找概念类
用例是通过名词短语识别领域概念的丰富源泉,因此应该详述用例。
名词可以是概念类，也可能是概念类的属性。
属性一般是可以赋值的，比如数字或者文本。
该名词可以这样赋值吗？如果不行的话，那么就有可能是一个概念类。
如果对一个名词是概念类还是属性举棋不定的时候，最好将其作为概念类处理。
需要注意的是,不存在名词到类的映射机制，因为自然语言具有二义性
这种方法的弱点是自然语言的不精确性细化阶段：迭代 1
POS机案例 - Step1寻找概念类
主要成功场景：
1.顾客 携带 商品 到达 POS机 收费口
2.收银员 开始一次新的 销售
3.收银员输入 商品标识
4.系统记录单件 商品,并显示该商品的 描述、价格、累加值 。
收银员重复 3～ 4步，直到商品输入结束。
5.系统显示 总值 。
6.收银员 请顾客 付款 。
7.顾客支付，系统处理支付。
8.系统记录完整的 销售 信息，并将销售和付款信息发送到外部的 记帐系统和库存系统 。
9.系统打印 收据
10.顾客带着商品和收据离开。
……
细化阶段：迭代 1
POS机案例 -寻找到的初始概念类
顾客：商品销售的主体和驱动者
商品,顾客所需购买的物品
POS机,商店进行商品销售的设备
收银员：商店执行商品销售并使用销售设备的人员
销售,一次或多次商品交易事件
商品标识：是销售设备能唯一标识物品的 ID
商品条目,销售设备记录每一个商品销售的具体信息，销售小票中的多条商品信息
商品总价：一次销售所有商品的总价
付款,顾客支付该次销售交易的金额
帐务系统：销售设备将一次销售交易的金额等信息传递给记账系统
库存系统,一次销售将对库存的商品信息和数量进行修改
商品描述：每一个销售商品的具体信息细化阶段：迭代 1
添加关联
关联通常意味着我们必须知道这个关系的存在，
并且这个关系需要保存一段时间，时间的长短取决于关联所处的语境。
添加关联的两种方式：
需要将概念之间的关系信息保持一段时间的关联－ 需要知道（ need-to-know）型关联
只需理解型关联反映了理解概念类所需的本质信息细化阶段：迭代 1
添加关联 -使用常见的关联列表分类 示例 分类 示例
A在物理上是 B的一部分
Drawer — Register
Wing — Airplane
A是 B的一个组织子单元
Department — Store
Maintenance — Airline
A在逻辑上是 B的一部分
SalesLineItem — Sale
FlightLeg— FlightRoute A使用或管理 B
Cashier — Register
Pilot — Airplane
A在物理上包含在 B
中或者依赖于 B
Register — Store,Item —
Shelf
Passenger — Airplane
A与 B通信
Customer — Cashier
Reservation Agent —
Passenger
A在逻辑上包含在 B
中
ItemDescription — Catalog
Flight— FlightSchedule A与一个交易 B有关
Customer — Payment
Passenger — Ticket
A是对 B的描述 ItemDescription — ItemFlightDescription — Flight A是一个与另一个交易 B有关的事务 Payment — SaleReservation — Cancellation
A是交易或者报表 B
中的一项
SalesLineItem — Sale
Maintenance Job —
Maintenance Log
A与 B相邻
SalesLineItem —
SalesLineItem
City— City
A为 B所知 /为 B所记录 /
录入 B中 /为 B所捕获
Sale — Register
Reservation —
FlightManifest
A为 B所拥有 Register — StorePlane — Airline
A是 B的一个成员 Cashier — StorePilot — Airline A是一个与 B有关的事件
Sale — Customer,Sale —
Store
Departure — Flight
细化阶段：迭代 1
关联与概念类
识别概念类比识别关联更重要，因此领域模型创建过程中应该更加注重概念类的识别。
根据,需要知道型,原则获取最小集合的关联，
然后利用,只需理解型,关联增强对领域中关键概念的理解。
太多的关联不仅不能有效地表示领域模型，反而容易使领域模型变得混乱。
避免显示冗余或导出关联。
细化阶段：迭代 1
POS机案例 - Step2 添加关联
POS机案例中领域模型的核心概念类应该是销售
销售与 POS机之间存在“使用”或者“扫描”的关系
一个销售“包括”多个销售条目
一次销售必然要有顾客“支付”相应的金额
销售条目“记录”的是销售的商品信息
POS机“位于”库存系统中
商店的商品“存储”于库存系统细化阶段：迭代 1
案例 - Step3 构建初始领域模型类图商店细化阶段：迭代 1
Step 4 添加属性
领域模型中包含的属性：是需求（用例）建议或者暗示我们需要记忆的那些信息。
有效属性类型原则：
概念模型中的属性应当被优先定义为简单属性或数据类型。如,boolean、
date,number,string,text,time，其他常见的简单数据类型如：
address,color,zip等。
用关联而不是用属性来联系概念类，
避免用属性表达一个复杂的领域概念。
细化阶段：迭代 1
POS机案例 - Step5 完善领域模型类图付款顾 客
( f r o m A c t o r s )
<< A ct or >>
销售
1 1
Pa y ed -b y
1
1
is fo r
收银员
( f r o m A c t,,,
<< A ct or >>
PO S 机
1
0.,1
Ca p tu re d on
1
1
wo r ks o n
帐务系统
1
n
Lo g s- co mp le te d
销售条目
1.,n
1
Co n ta in ed -i n
商品
10.,1
Re c or ds -s al e- of
商店
1
1.,n
Ho u se s
11
re c or ds -a cc ou nt s- fo r
n
1
st o ck s
产品目录
1
n
Us e d- by
产品描述
1
n
de s cr ib es
1
1.,n
co n ta in s
细化阶段：迭代 1
Step 6 领域模型是否正确
没有所谓唯一正确的领域模型
所有的模型都是用于理解领域的特点
领域模型主要是在特定群体中用于理解和沟通的工具
领域的概念
术语
概念之间的关系细化阶段：迭代 1
构建用例模型 Use-Case Model
用例模型的组成
用例图
用例说明
SSD系统顺序图
操作契约细化阶段：迭代 1
POS案例 -Step1-用例模型之 SSD
系统顺序图（ SSD）：用于说明与系统相关的输入和输出事件，它是操作契约和对象设计的输入。
用例图表达了角色使用系统的目标，那么角色是如何激活系统操作满足其目标的呢？
面向对象思想中，通过事件激活。
系统事件有哪些？系统顺序图（ SSD）
用例描述角色是如何与系统进行交互的。在交互中，角色对系统发起系统事件，系统中的某些系统操作对这些事件加以处理。
例如，当收银员使用扫描仪输入商品 ID时，收银员请求 POS机记录对该商品的销售（ EnterItem事件），该事件引发了系统的操作。用例说明暗示了 EnterItem事件，而 SSD将其变得具体和明确。
细化阶段：迭代 1
系统顺序图 SSD
系统顺序图：
为每个用例的主要成功场景以及频繁或复杂的替代场景进行设计；
描述外部角色与系统（作为一个黑箱）之间交互的事件；
本次迭代主要考虑主要角色产生的事件；
也可以描述次要角色接收系统产生的事件。
描述事件的顺序。
此时所描述的系统行为只需要确定系统,做什么,,而无需解释如何做。
细化阶段：迭代 1
系统顺序图 SSD目的
软件设计中需要明确的问题是：系统中会发生什么事情？为什么？
原因是我们必须为这些处理和事件（来自于鼠标、
键盘 … ）来设计软件
来自于参与者（人或计算机）的外部事件
时间事件
错误或异常（通常源于外部）
因此需要准确地知道什么是外部输入的事件，即系统事件细化阶段：迭代 1
SSD与用例图之间的关系简化的现金支付的处理销售场景
1,顾客携带所需商品到 POS机进行付款
2,收银员开始一次新的销售交易
3,收银员输入商品项目标识
4,系统逐条记录出售的商品项目，并显示该商品的基本描述、数量、价格和累计金额
5,系统显示总价
6,收银员告知顾客总价并提请付款
7,顾客支付
8,系统处理支付。
……
,收银员
,系统
1:m ake N ewS a le
2*[ mor e it e ms],ent e rIt em (it e mID,qua n tit y)
des cri p tio n,to t al
3:e ndS a le
tot al
4:m ake p aym e nt( a mou n t)
cha nge due,re c eip t
细化阶段：迭代 1
POS案例 -Step2- 整理 SSD的信息
在 SSD中所展示的元素：操作名称、参数、返回的数据等
需要对这些在图中很简洁的数据加以适当的解释，以便为设计时能明确输入了什么和输出了什么。
词汇表是详细描述这些元素的最佳选择
例如，实例中的一条返回信息,change due,receipt” 。就可以在词汇表中加入票据条目，显示票据样本（数码图片）、详细内容和布局细化阶段：迭代 1
POS案例 -Step3-用例模型之 操作契约
用例的操作契约可以作为用例模型中一个补充环节，它对用例指出的系统操作的作用提供了更详细的分析。
操作契约的主要输入是 SSD中确定的系统操作、领域模型或者领域专家的见解。
操作契约也可以作为对象设计的输入
定义操作执行的结果（对象状态的改变），而非过程细化阶段：迭代 1
操作契约的组成操作,操作以及参数的名称交叉引用,（可选择）可能发生此操作的用例前臵条件,在操作执行前，领域模型中系统或对象状态的假设，它们在此操作的逻辑内不会得到测试，而被假设为真，同时，它们并非无关紧要而应让读者了解此假设的存在。
后臵条件,操作完成后领域模型中对象的状态。（最重要的部分）
操作,enterItem(itemID:ItemID,quantity:integer)
交叉引用,用例,Sale
前置条件,有一个 Sale正在进行后置条件,1.创建一个 SalesLineItem实例 sli（实例创建）
2.sli和当前的 Sale形成关联（关联形成）
3.sli.quantity变成 quantity（属性修改）
4.在 itemID匹配的基础上,sli和 ProductSpecification形成关联（关联形成）
细化阶段：迭代 1
操作契约的后置条件
后臵条件描述了领域模型内对象的变化，后臵条件可以分为三种类型：
创建或删除实例
属性值的变化
形成或消除关联（ UML的链接）
后臵条件是声明性的，而且是面向状态变化而不是面向行为的。正是基于此，后臵条件能够在不描述系统操作如何实现的前提下描述系统操作引起系统状态的变化，给出了分析的细节。因此，分析阶段可以集中精力于系统发生了什么而非是如何发生的。
在需求分析时，要为系统操作产生一个完整、详细的后臵条件集是不可能甚至是不需要的。 （初始契约不完整） 。
细化阶段：迭代 1
示例,enterItem后置条件
创建和删除实例
输入 itemID和商品条目的 quantity后，会创建哪些新对象？
答,创建了 SalesLineItem的实例 Sli。
属性修改
在收银员输入商品条目标识和对应的商品数量后，修改了哪些新对象或现有对象的属性？
答,SalesLineItem的 quantity被赋值为 quantity参数，即修改属性 Sli.quantity = quantity
关联形成和消除
在收银员输入商品的 itemID和 quantity后，形成或清除了哪些新的或已有的对象之间的关联？
答,Sli与当前的 Sale关联
答,基于 itemID的匹配,Sli与 ProductDescription关联细化阶段：迭代 1
示例：销售用例中的系统操作契约 page1
操作,makeNewSale( )
交叉引用,用例,Sale
前置条件,无后置条件,1.创建了 Sales的实例 s（实例创建）
2.S被关联到 Register（关联形成）
3.S的属性被初始化（属性修改）
操作,enterItem(itemID:ItemID,quantity:integer)
交叉引用,用例,Sale
前置条件,有一个 Sale正在进行后置条件,1.创建一个 SalesLineItem实例 sli（实例创建）
2.sli和当前的 Sale形成关联（关联形成）
3.sli.quantity变成 quantity（属性修改）
4.在 itemID匹配的基础上,sli和 ProductSpecification形成关联
（关联形成）
细化阶段：迭代 1
示例：销售用例中的系统操作契约 page2
操作,endSale( )
交叉引用,用例,Sale
前置条件,正在进行中的销售后置条件,1.Sale.iscomplete被置为真（修改属性）
操作,makePayment(amount:Money )
交叉引用,用例,Sale
前置条件,正在进行中的销售后置条件,1.创建了 Payment的实例 p（实例创建）
2.p.amountTendered被赋值为 amount（修改属性）
3.P被关联到当前的 Sale（形成关联）
4.当前的 Sale被关联到 Store（形成关联），将其加入到完成销售的历史日志中用例模型、领域模型与设计模型的关系总结初始阶段、细化阶段的初次迭代
初始阶段完成了大约 10%～ 20%的需求调研，细化阶段的第一次迭代在此基础上进行稍微深入的调研工作。
需求和面向对象的分析工作,do the right thing
（做正确的事情）
设计工作,do the thing right（正确地做事情）
开始对象设计：核心是交互图。
UP – Inception & Elabpration 1
Xiao ding TSEG
UP基本结构
1,UP是一个软件开发过程
2,软件开发过程是一个将用户需求转化为软件系统所需要的活动集合。
3,UP不仅仅是一个简单的过程，而是一个通用的过程框架。
4,UP使用 UML来制定和描述软件系统的所有视图。
5,UP的突出特点：用例驱动、以构架为中心、使用迭代和增量的开发模式
UP生命周期
UP是在重复一系列组成软件系统生命周期的循环。每次循环都以向用户提供一个产品版本作为终结。
每次循环都包括四个阶段,初始、细化、构造和移交 。每个阶段又进一步细分为多次迭代过程
每次循环都产生系统的一个新的 版本 (version)，每个版本都是一个可交付的产品它包括由能够编译和运行的构件所体现的源代码、各种手册和相关的交付品
所完成的产品包括 一整套 需求、非功能性需求和测试用例等文档，还包括构架和可视化的模型
UP 的迭代增量开发模式
UP的每个阶段可以进一步分为几个迭代过程。它是生成可执行产品版本（内部和外部）的完整开发循环，是最终产品的一个子集，从一个迭代过程到另一个迭代过程递增式增长形成最终的系统。
迭代和增量的三个关键点
计划一小步
说明、设计和实现一小步
集成、测试和运行每次迭代（一小步）
UP的其它重要概念
在早期迭代中解决高风险和高价值的问题
不断地让用户参与评估、反馈和需求确认
在早期迭代中确定系统的核心架构
不断地验证质量，尽早并经常性的实施测试
进行可视化建模（使用 UML）
认真管理需求，实施变更管理和配臵管理
UP里程碑
每个阶段都以一个里程碑作为结束标志。 通过获得一组 可用的制品 来定义每个里程碑。
在每个阶段结束时进行评估以确定是否实现了此阶段的目标。 良好的评估可使项目顺利进入下一阶段。
迭代和增量模型的特点
将项目分解成许多袖珍项目，每一个袖珍项目都作为一次迭代
每个这样的袖珍项目都像过去的瀑布模型，因为它处理的是瀑布模型的活动。我们可以将每次迭代标注为一个,袖珍瀑布,
迭代不是一个完全独立的实体，它是项目的一个阶段，它在很大程度上是作为项目的一部分而得到的
规划人员设法对迭代进行排序以得到一条有序的途径，使早期的迭代为后期的迭代提供认知基础
项目的早期迭代增进了对需求、问题、风险和方案领域的了解，而后期迭代产生的附加增量最终构成了外部版本，即客户产品
最终的成功是一个一直前进的迭代系列；即不必因为在后期的迭代中了解到的一些问题而回退 2 ~ 3个迭代去修补模型使用迭代和增量的理由
为了尽早处理关键风险和重要风险
为了建立一个构架来指导软件开发
能够处理不断变化的需求，并提供灵活变化的机制
为了提供一个开发过程，使所有工作人员更高效地工作合理规划迭代过程
项目经理在当前迭代的目标未达到之前不应同意开始下一次迭代。否则，就会导致必须改变计划来适应新的情况确定迭代次序
用例设定了一个目标；而构架建立了一个模式。
记住这个目标和模式，管理人员可以在人力资源充分的情况下规划出进行产品开发的顺序迭代和增量的优点
允许变更需求,需求总是会变化，这是事实。
逐步集成元素,集成并不只是简单的“一锤定音”。在迭代式方法中，
集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量
40% 的那段较长的、不确定的且棘手的时期，现在分散到六至九个集成部分中，每一部分要集成的元素都比过去少得多。
及早降低风险,因为风险一般只有在集成阶段才能发现或得到处理。
有助于组织学习和提高,团队成员有机会在整个生命周期中边做边学，
各显其能。测试员可以早一些开始测试，技术文档编写员可及早开始编写，其他人也是如此。
提高复用性,早期迭代中的设计复审可使构架设计师确定毋庸臵疑的潜在复用部分，并在以后的迭代中开发和完善这些公用代码。
生成性能更强壮的产品,性能上的瓶颈可以尽早发现并处理，而不象在交付前夕，此时已来不及处理。
迭代流程自身可在进行过程中得到改进和精炼,一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。
初始阶段 Inception
主要目的是将一个好的想法发展为最终产品的一个构想。
本质上，该阶段应回答下面三个问题：
系统向它的每个主要用户提供的基本功能是什么？
该系统的构架看起来是什么样子？
开发该产品的计划如何？开销多大？
该阶段中 最关键用例的 简化用例模型 可以回答第一个问题。
在这个阶段,构架是试验性的,通常只是一个包括主要子系统的大致轮廓。
在这个阶段，要确定最主要的风险及其优先次序，要对细化阶段进行详细规划，并对整个项目进行粗略估算。
注意，该阶段的目标不是定义所有的需求初始阶段的目标和任务
建立项目的 软件规模和边界条件,包括运作前景、验收标准以及希望产品中包括和不包括的内容。
识别系统的 关键用例
对比一些主要场景，展示至少一个备选构架
给出用户提出的非功能性要求描述
评估整个项目的 总体成本和进度
评估潜在的风险（源于各种不可预测因素）
准备项目的支持环境。
在阶段后期为细化阶段 制定迭代计划初始阶段的工件集
Vision,核心项目需求、关键特性、主要约束的总体构想
Business Case,业务用例
Use-case Model,初始的关键用例模型，占 10-20%的数量
Risks List
Plan
Project-specific templates
Software Development Plan
Iteration Plan
Product Acceptance Plan
Development Case
Tools
Glossary
电子收款机（ POS）系统案例
POS机是一个计算机化应用的系统，用于记录销售信息和处理支付过程，一般超市和零售商店都会用到。该系统的假设条件如下：
系统包括终端系统、条码扫描仪等硬件，还有相应的软件系统；
它可能还需要与其他系统存在接口，比如信用卡支付系统、库存系统、记费系统等；
该系统具有一定的容错性能，比如在与库存系统暂时终端连接时，
仍能够进行物品的销售，不至于使系统瘫痪；
多样化的终端接口：瘦客户 Web终端,PC、触摸屏、无线 PDA
能适应不同商店业务销售的功能要求，提供一种灵活性和定制能力的功能（作为系统开发的复用需求）
POS案例 -Step1
初始阶段应该考虑以下问题：
项目的前景如何？
业务背景和业务流程是什么？
可行性如何？项目是否停止或继续进行？
购买还是开发？
粗略估计一下成本，估计收益。
主要目标：
只进行一定的研究，得到未来新系统的可行性以及实现系统总体目标的合理判断，并确定是否值得继续深入研究系统即可。（深入的研究是细化阶段的工作）
概括为：
预见项目的范围、前景和业务案例；
项目相关人员是否就项目的前景达成基本的一致，项目是否值得继续进行认真的研究。
POS机案例 -Step2
该阶段的主要工作成果集
项目前景
业务背景及业务流程
关键用例模型（ 10-20%）
补充性规格说明
词汇表
….
POS机案例 -Step3
用例建模的基本过程：
1.选择系统边界
POS作为一个待构建的系统，包含软件,POS机、输入终端等，收银员、支付授权、税金计算等不包括在系统之内。任何系统之外的事物都在系统边界之外。
2.识别主要角色
主要角色：在使用系统服务的过程中满足自己的用户目标的那些参与者。 找出用户目标
次要角色：为系统提供服务的那些参与者。 说明外部接口和协议
后台角色：对用例的行为感兴趣。 保证找到并满足所有必要的兴趣。
3.识别主要角色的目标
一般来讲：第 2和第 3步是同时进行的。
POS机案例 -Step4 寻找 ACtor
顾客：
购买商品、退货、支付费用
希望得到快速的服务、能清楚地看到购买的商品和价格信息，得到收据以便退货
收银员：
处理销售、处理退货、入款、出款
希望能快速准确地输入，切无支付错误（出现错误时，将从其薪水中扣除）
经理：
启动、关机、处理销售异常操作
希望能快速地执行相应的操作，易于更正收银员出现的错误
系统管理员：
添加用户、修改用户、删除用户、安全管理、系统表管理
希望能方便地添加使用 POS机的用户，并针对不同用户赋予不同的操作权限等
销售活动分析系统：
分析销售数据和销售表现
能够定期快速地获得必需的数据，制定相应的统计报表
库存系统、记费系统等 ……
主要参与者的确定
主要参与者是收银员还是顾客？
答案：收银员。
问题：为什么？为什么不是顾客？
主要原因取决于系统的边界，以及有关系统设计的主要对象。
如果将企业（超市）和销售服务视为一个整体，则主要参与者是“顾客”，顾客的主要目标是通过商店购买商品然后离开。
然而从 POS系统建设的角度出发，认为使用系统的用户是收银员，他（她）的目标是使用 POS机并通过该机处理销售交易
POS机案例 -Step5 确定用例
顾客：购买商品
收银员,处理销售、销售前准备、结束销售
经理：开关机、处理销售异常
系统管理员,用户管理、权限安全管理
……
由系统的主要参与者确定系统的关键用例
销售
用户管理
权限安全管理
POS机案例 -Step6 用例图
绘制初始用例图用户管理
( f r o m < U s e C a s e N a m e > )
安全管理
( f r o m < U s e C a s e N a m e > )
系统管理员
( f r o m A c t o r s )
收银员
( f r o m A c t o r s )
认证系统
( f r o m A c t o r s )
计费系统
( f r o m A c t o r s )
<<角色 >>
销售
( f r o m < U s e C a s e N a m e > )
POS机案例 -Step6 关键用例描述
用例,销售
主要参与者,收银员
项目相关人员及其兴趣：（参见第 19页）
前臵条件,收银员必须已经被识别和授权
后臵条件,存储销售信息、更新账目和库存信息、生成收据等
主要成功场景：
1.顾客携带商品到达 POS机收费口
2.收银员开始一次新的销售
3.收银员输入商品标识
4.系统记录单件商品，并显示该商品的描述、价格、累加值。
收银员重复 3～ 4步，直到商品输入结束。
5.系统显示总值并计算税金。
6.收银员请顾客付款。
7.顾客支付，系统处理支付。
8.系统记录完整的销售信息，并将销售和付款信息发送到外部的帐务系统和库存系统。
9.系统打印收据
10.顾客带着商品和收据离开。
……
POS机案例 - step7 其他文档编写用例模型只是描述了系统的功能性需求，其他需求放在下列工件中描述：
前景（ vision）：概述项目的远景。用简洁的语言表达项目总体想法，包括：项目为什么被提出？有哪些问题？有哪些项目相关人员？他们需要什么？以及提出了哪些解决方案等。
补充规格说明：未在用例中描述的 FURPS+需求。
术语表：术语及其定义，还可以用作数据字典。
需求,FURPS+
Function（功能）：特性、能力、安全性
Usability（可用性）：人性化因素、帮助和文档；
Reliability（可靠性）：故障周期、可恢复性、可预测性；
Performance（性能）：响应时间、吞吐量、准确性、有效性；
Supportability（可支持性）：适应性、可维护性、国际化、可配臵性。
＋：一些辅助性和次要的因素。
Implementation（实现）：资源限制、语言和工具、硬件等；
Interface（接口）：与外部系统接口所加的约束；
Operations（操作）：系统操作环境中的管理
Package（包装）
Legal（授权）：许可证或其他方式。
前景 Vision page1
修订历史
简介
定位
商业机会
问题综述
产品定位综述
替代方案和竞争对手
项目相关人员描述
项目相关人员（非用户）概述
用户概述
项目相关人员主要的高级别目标和问题
用户级别目标
用户环境前景 Vision page2
产品纵览
产品远景
优点概述
假设和依赖
成本和定价
授权和安装
系统特性概述
系统特性是系统提供的一个外部可观测到的服务，这种服务能够 直接满足项目相关人员的需要。
特性是系统能做的事情。 系统会做 <某特性 >，比如记录销售记录、
支付授权（信用卡、借记卡、支票）
其他需求和约束补充性规格说明 page1
修订历史
简介
功能性（ 跨越许多用例的一般功能）
日志和错误处理
可插入的业务规则
安全性
可用性
人为因素，比如屏幕的分辨率要求
可靠性
可恢复性：外部服务发生错误的时候，尽量采用本地方法来解决，
以使交易能够完成。
性能：交易的处理速度
可支持性
适应性
可配臵性
实现约束,用户要求使用 Java技术的解决方案
采购的组件
免费的开放源码的组件
接口
值得注意的硬件及其接口
软件接口
领域（业务）规则,规定一个领域或者业务如何操作，如：
退货、折扣等 。
法律问题
有关感兴趣的业务规则,商品定价,信用卡支付需要签名、条形码产品等补充性规格说明 page2
术语表 Glossary
修订历史
定义
术语
定义和相关信息
别名细化阶段 Elaboration
详细说明系统的绝大多数用例,并根据关键用例的实现在第 1-2次迭代中设计出系统的构架
最关键用例都要在这个阶段具体化。 该阶段的结果是构架基线
在细化阶段末期，要规划完成项目的活动，估算完成项目所需的资源。
该阶段的关键问题是,用例、构架和计划是否足够稳定可靠，风险是否得到充分控制，以便能够按照合同的规定完成整个开发任务。
细化阶段的目标和任务
确保构架、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定完成开发所需的成本和进度。
处理在构架方面具有重要意义的所有项目风险
建立一个已确定基线的构架
制作具有产品质量构件的演进式 原型
细化前景文档
在细化阶段后期为 构造阶段 制定详细的迭代计划
建立支持环境。这包括创建开发案例、创建模板和指南、
安装工具细化阶段的工件集
Vision
Prototypes
Use-case Model,至少 80%的用例要完成，所有用例均被识别，大多数用例描述被开发
Domain Model,结合用例模型完成相应的领域模型构建
Analysis Model,可选，主要用于帮助系统结构的确定
Design Model,结合用例给出系统的静态和动态结构
Data Model,结合用例模型和领域模型给出相应的数据模型
Implementation Model,将部分用例转化为代码
Risk List
Tools
Software Architecture Document
Software Development Plan
Iteration Plan
细化阶段：迭代 1
POS机案例 确定迭代次数
进入到细化阶段的首要工作就是确定阶段的迭代次数
根据细化阶段的主要目标：构建架构基线，来确定具体的迭代次数
一般情况下，通过实现 2-3个用例来证明架构的稳定性
本案例计划使用两次迭代细化阶段：迭代 1
构建领域模型 Domain Model
领域模型是 OO分析中最重要的和经典的模型，它阐述了领域中的重要业务概念
领域模型是 UP过程的可选制品，但领域模型很大程度上会影响用例模型分析和构建，甚至是设计模型中的软件对象。
领域模型的构建 限定于当前迭代所分析的用例,它能够不断地演进用以展示相关的重要概念。
定义：是对领域内的概念类或现实世界中对象的可视化表示，而非软件对象。也称之为概念模型、分析对象模型、
领域对象模型。
细化阶段：迭代 1
领域模型 Domain Model
应用 UML表示法,领域模型被描述为一组没有定义操作的类图,提供了概念透视图，用以展示：
领域对象或概念类
概念类之间的关联
概念类的属性
概念类的定义：是思想、事物或对象，可以从其符号、内涵和外延来考虑
符号：表示概念类的词语或图形
内涵：概念类的定义
外延：概念类所适用的一组实例表示,销售,交易的事件、具有时间和日期销售 1、销售 2… 销售 n
细化阶段：迭代 1
领域模型不是软件组件模型
领域模型所关注的仅仅是客观世界中的事物并将其可视化，而非诸如 Java或 C#类的软件对象。
以下元素不适用于领域模型
软件制品，例如窗口、界面、数据库
软件模型中具有职责或方法的对象领域模型软件制品，不属于领域模型销售数据库软件类制品细化阶段：迭代 1
降低与 OO建模之间的表示差异
OO的关键思想：领域层软件类的名称要源于领域模型的信息和职责
这样可以减小人们的思维与软件模型之间的表示差异启发了软件对象及其名称细化阶段：迭代 1
创建领域模型的原则
以当前迭代所关注的需求为界
寻找概念类
将其绘制为 UML类图中的类
添加关联和属性
寻找概念类的三条策略
重用和修改现有的概念模型
根据经验使用分类列表
根据用例说明确定名词短语细化阶段：迭代 1
使用分类列表寻找概念类概念类分类 示例 概念类分类 示例物理或具体对象 RegisterAirplane 抽象名词的概念 HungerAcrophobia
事物的设计、
描述和规范
ProductSpecification
FlightDescription 组织
SalesDepartment
ObjectAirline
位臵 StoreAirport 事件 Sale,Payment,MeetingFlight,Crash,Landing
交易 Sale,PaymentReservation 过程 SellingAProductBookingASeat
交易项目 SalesLineItem 规则和政策 RefundPolicyCancellationPolicy
人的角色 CashierPilot 分类 ProductCatalogPartsCatalog
其他事物的容器
Store,Bin
Airplane
有关工作、契约、财务和法律事物的记录
Receipt,Ledger,
EmploymentContract
MaintenanceLog
容器包含的元素 ItemPassenger 财务设施及服务 LineOfCreditStock
在该系统之外的系统
CreditPaymentAuthorizationSystem
AirTrafficControl
手册、文档、引用论文、书籍
DailyPriceChangeList
RepairManual
细化阶段：迭代 1
通过识别名词短语寻找概念类
用例是通过名词短语识别领域概念的丰富源泉,因此应该详述用例。
名词可以是概念类，也可能是概念类的属性。
属性一般是可以赋值的，比如数字或者文本。
该名词可以这样赋值吗？如果不行的话，那么就有可能是一个概念类。
如果对一个名词是概念类还是属性举棋不定的时候，最好将其作为概念类处理。
需要注意的是,不存在名词到类的映射机制，因为自然语言具有二义性
这种方法的弱点是自然语言的不精确性细化阶段：迭代 1
POS机案例 - Step1寻找概念类
主要成功场景：
1.顾客 携带 商品 到达 POS机 收费口
2.收银员 开始一次新的 销售
3.收银员输入 商品标识
4.系统记录单件 商品,并显示该商品的 描述、价格、累加值 。
收银员重复 3～ 4步，直到商品输入结束。
5.系统显示 总值 。
6.收银员 请顾客 付款 。
7.顾客支付，系统处理支付。
8.系统记录完整的 销售 信息，并将销售和付款信息发送到外部的 记帐系统和库存系统 。
9.系统打印 收据
10.顾客带着商品和收据离开。
……
细化阶段：迭代 1
POS机案例 -寻找到的初始概念类
顾客：商品销售的主体和驱动者
商品,顾客所需购买的物品
POS机,商店进行商品销售的设备
收银员：商店执行商品销售并使用销售设备的人员
销售,一次或多次商品交易事件
商品标识：是销售设备能唯一标识物品的 ID
商品条目,销售设备记录每一个商品销售的具体信息，销售小票中的多条商品信息
商品总价：一次销售所有商品的总价
付款,顾客支付该次销售交易的金额
帐务系统：销售设备将一次销售交易的金额等信息传递给记账系统
库存系统,一次销售将对库存的商品信息和数量进行修改
商品描述：每一个销售商品的具体信息细化阶段：迭代 1
添加关联
关联通常意味着我们必须知道这个关系的存在，
并且这个关系需要保存一段时间，时间的长短取决于关联所处的语境。
添加关联的两种方式：
需要将概念之间的关系信息保持一段时间的关联－ 需要知道（ need-to-know）型关联
只需理解型关联反映了理解概念类所需的本质信息细化阶段：迭代 1
添加关联 -使用常见的关联列表分类 示例 分类 示例
A在物理上是 B的一部分
Drawer — Register
Wing — Airplane
A是 B的一个组织子单元
Department — Store
Maintenance — Airline
A在逻辑上是 B的一部分
SalesLineItem — Sale
FlightLeg— FlightRoute A使用或管理 B
Cashier — Register
Pilot — Airplane
A在物理上包含在 B
中或者依赖于 B
Register — Store,Item —
Shelf
Passenger — Airplane
A与 B通信
Customer — Cashier
Reservation Agent —
Passenger
A在逻辑上包含在 B
中
ItemDescription — Catalog
Flight— FlightSchedule A与一个交易 B有关
Customer — Payment
Passenger — Ticket
A是对 B的描述 ItemDescription — ItemFlightDescription — Flight A是一个与另一个交易 B有关的事务 Payment — SaleReservation — Cancellation
A是交易或者报表 B
中的一项
SalesLineItem — Sale
Maintenance Job —
Maintenance Log
A与 B相邻
SalesLineItem —
SalesLineItem
City— City
A为 B所知 /为 B所记录 /
录入 B中 /为 B所捕获
Sale — Register
Reservation —
FlightManifest
A为 B所拥有 Register — StorePlane — Airline
A是 B的一个成员 Cashier — StorePilot — Airline A是一个与 B有关的事件
Sale — Customer,Sale —
Store
Departure — Flight
细化阶段：迭代 1
关联与概念类
识别概念类比识别关联更重要，因此领域模型创建过程中应该更加注重概念类的识别。
根据,需要知道型,原则获取最小集合的关联，
然后利用,只需理解型,关联增强对领域中关键概念的理解。
太多的关联不仅不能有效地表示领域模型，反而容易使领域模型变得混乱。
避免显示冗余或导出关联。
细化阶段：迭代 1
POS机案例 - Step2 添加关联
POS机案例中领域模型的核心概念类应该是销售
销售与 POS机之间存在“使用”或者“扫描”的关系
一个销售“包括”多个销售条目
一次销售必然要有顾客“支付”相应的金额
销售条目“记录”的是销售的商品信息
POS机“位于”库存系统中
商店的商品“存储”于库存系统细化阶段：迭代 1
案例 - Step3 构建初始领域模型类图商店细化阶段：迭代 1
Step 4 添加属性
领域模型中包含的属性：是需求（用例）建议或者暗示我们需要记忆的那些信息。
有效属性类型原则：
概念模型中的属性应当被优先定义为简单属性或数据类型。如,boolean、
date,number,string,text,time，其他常见的简单数据类型如：
address,color,zip等。
用关联而不是用属性来联系概念类，
避免用属性表达一个复杂的领域概念。
细化阶段：迭代 1
POS机案例 - Step5 完善领域模型类图付款顾 客
( f r o m A c t o r s )
<< A ct or >>
销售
1 1
Pa y ed -b y
1
1
is fo r
收银员
( f r o m A c t,,,
<< A ct or >>
PO S 机
1
0.,1
Ca p tu re d on
1
1
wo r ks o n
帐务系统
1
n
Lo g s- co mp le te d
销售条目
1.,n
1
Co n ta in ed -i n
商品
10.,1
Re c or ds -s al e- of
商店
1
1.,n
Ho u se s
11
re c or ds -a cc ou nt s- fo r
n
1
st o ck s
产品目录
1
n
Us e d- by
产品描述
1
n
de s cr ib es
1
1.,n
co n ta in s
细化阶段：迭代 1
Step 6 领域模型是否正确
没有所谓唯一正确的领域模型
所有的模型都是用于理解领域的特点
领域模型主要是在特定群体中用于理解和沟通的工具
领域的概念
术语
概念之间的关系细化阶段：迭代 1
构建用例模型 Use-Case Model
用例模型的组成
用例图
用例说明
SSD系统顺序图
操作契约细化阶段：迭代 1
POS案例 -Step1-用例模型之 SSD
系统顺序图（ SSD）：用于说明与系统相关的输入和输出事件，它是操作契约和对象设计的输入。
用例图表达了角色使用系统的目标，那么角色是如何激活系统操作满足其目标的呢？
面向对象思想中，通过事件激活。
系统事件有哪些？系统顺序图（ SSD）
用例描述角色是如何与系统进行交互的。在交互中，角色对系统发起系统事件，系统中的某些系统操作对这些事件加以处理。
例如，当收银员使用扫描仪输入商品 ID时，收银员请求 POS机记录对该商品的销售（ EnterItem事件），该事件引发了系统的操作。用例说明暗示了 EnterItem事件，而 SSD将其变得具体和明确。
细化阶段：迭代 1
系统顺序图 SSD
系统顺序图：
为每个用例的主要成功场景以及频繁或复杂的替代场景进行设计；
描述外部角色与系统（作为一个黑箱）之间交互的事件；
本次迭代主要考虑主要角色产生的事件；
也可以描述次要角色接收系统产生的事件。
描述事件的顺序。
此时所描述的系统行为只需要确定系统,做什么,,而无需解释如何做。
细化阶段：迭代 1
系统顺序图 SSD目的
软件设计中需要明确的问题是：系统中会发生什么事情？为什么？
原因是我们必须为这些处理和事件（来自于鼠标、
键盘 … ）来设计软件
来自于参与者（人或计算机）的外部事件
时间事件
错误或异常（通常源于外部）
因此需要准确地知道什么是外部输入的事件，即系统事件细化阶段：迭代 1
SSD与用例图之间的关系简化的现金支付的处理销售场景
1,顾客携带所需商品到 POS机进行付款
2,收银员开始一次新的销售交易
3,收银员输入商品项目标识
4,系统逐条记录出售的商品项目，并显示该商品的基本描述、数量、价格和累计金额
5,系统显示总价
6,收银员告知顾客总价并提请付款
7,顾客支付
8,系统处理支付。
……
,收银员
,系统
1:m ake N ewS a le
2*[ mor e it e ms],ent e rIt em (it e mID,qua n tit y)
des cri p tio n,to t al
3:e ndS a le
tot al
4:m ake p aym e nt( a mou n t)
cha nge due,re c eip t
细化阶段：迭代 1
POS案例 -Step2- 整理 SSD的信息
在 SSD中所展示的元素：操作名称、参数、返回的数据等
需要对这些在图中很简洁的数据加以适当的解释，以便为设计时能明确输入了什么和输出了什么。
词汇表是详细描述这些元素的最佳选择
例如，实例中的一条返回信息,change due,receipt” 。就可以在词汇表中加入票据条目，显示票据样本（数码图片）、详细内容和布局细化阶段：迭代 1
POS案例 -Step3-用例模型之 操作契约
用例的操作契约可以作为用例模型中一个补充环节，它对用例指出的系统操作的作用提供了更详细的分析。
操作契约的主要输入是 SSD中确定的系统操作、领域模型或者领域专家的见解。
操作契约也可以作为对象设计的输入
定义操作执行的结果（对象状态的改变），而非过程细化阶段：迭代 1
操作契约的组成操作,操作以及参数的名称交叉引用,（可选择）可能发生此操作的用例前臵条件,在操作执行前，领域模型中系统或对象状态的假设，它们在此操作的逻辑内不会得到测试，而被假设为真，同时，它们并非无关紧要而应让读者了解此假设的存在。
后臵条件,操作完成后领域模型中对象的状态。（最重要的部分）
操作,enterItem(itemID:ItemID,quantity:integer)
交叉引用,用例,Sale
前置条件,有一个 Sale正在进行后置条件,1.创建一个 SalesLineItem实例 sli（实例创建）
2.sli和当前的 Sale形成关联（关联形成）
3.sli.quantity变成 quantity（属性修改）
4.在 itemID匹配的基础上,sli和 ProductSpecification形成关联（关联形成）
细化阶段：迭代 1
操作契约的后置条件
后臵条件描述了领域模型内对象的变化，后臵条件可以分为三种类型：
创建或删除实例
属性值的变化
形成或消除关联（ UML的链接）
后臵条件是声明性的，而且是面向状态变化而不是面向行为的。正是基于此，后臵条件能够在不描述系统操作如何实现的前提下描述系统操作引起系统状态的变化，给出了分析的细节。因此，分析阶段可以集中精力于系统发生了什么而非是如何发生的。
在需求分析时，要为系统操作产生一个完整、详细的后臵条件集是不可能甚至是不需要的。 （初始契约不完整） 。
细化阶段：迭代 1
示例,enterItem后置条件
创建和删除实例
输入 itemID和商品条目的 quantity后，会创建哪些新对象？
答,创建了 SalesLineItem的实例 Sli。
属性修改
在收银员输入商品条目标识和对应的商品数量后，修改了哪些新对象或现有对象的属性？
答,SalesLineItem的 quantity被赋值为 quantity参数，即修改属性 Sli.quantity = quantity
关联形成和消除
在收银员输入商品的 itemID和 quantity后，形成或清除了哪些新的或已有的对象之间的关联？
答,Sli与当前的 Sale关联
答,基于 itemID的匹配,Sli与 ProductDescription关联细化阶段：迭代 1
示例：销售用例中的系统操作契约 page1
操作,makeNewSale( )
交叉引用,用例,Sale
前置条件,无后置条件,1.创建了 Sales的实例 s（实例创建）
2.S被关联到 Register（关联形成）
3.S的属性被初始化（属性修改）
操作,enterItem(itemID:ItemID,quantity:integer)
交叉引用,用例,Sale
前置条件,有一个 Sale正在进行后置条件,1.创建一个 SalesLineItem实例 sli（实例创建）
2.sli和当前的 Sale形成关联（关联形成）
3.sli.quantity变成 quantity（属性修改）
4.在 itemID匹配的基础上,sli和 ProductSpecification形成关联
（关联形成）
细化阶段：迭代 1
示例：销售用例中的系统操作契约 page2
操作,endSale( )
交叉引用,用例,Sale
前置条件,正在进行中的销售后置条件,1.Sale.iscomplete被置为真（修改属性）
操作,makePayment(amount:Money )
交叉引用,用例,Sale
前置条件,正在进行中的销售后置条件,1.创建了 Payment的实例 p（实例创建）
2.p.amountTendered被赋值为 amount（修改属性）
3.P被关联到当前的 Sale（形成关联）
4.当前的 Sale被关联到 Store（形成关联），将其加入到完成销售的历史日志中用例模型、领域模型与设计模型的关系总结初始阶段、细化阶段的初次迭代
初始阶段完成了大约 10%～ 20%的需求调研，细化阶段的第一次迭代在此基础上进行稍微深入的调研工作。
需求和面向对象的分析工作,do the right thing
（做正确的事情）
设计工作,do the thing right（正确地做事情）
开始对象设计：核心是交互图。
