领域模型(概念类图)页PPT文档
合集下载
02领域模型共62页
40、人类法律，事物有规律，这是不 容忽视 的。— —爱献 生
领域模型
迭代1—基础需求
• Monopoly在第一次迭代中应完成处理的需 求：
– 实现基本和关键场景：游戏者围绕棋盘四周的 方格移动
– 实现用于支持迭代初始化需求的启动用例 – 支持2～8个游戏者 – 游戏通过一系列回合制进行。掷骰子，并且根
– 但是在业务流程看来，单据却非常重要。 – 总的说来，在领域模型中应该包含单据
像画地图一样的思考
• 使用领域内已有的名称 • 排除无关的或者超出范围的特定 • 不凭空添加领事物
类或者属性？
• 类或者属性？
– 某东西，不是现实世界中的文本或数字，那该 东西更多可能是一个概念类，而非属性
过程：精化
• 精化过程：
– 对核心，高风险的软件架构进行编程和测试 – 发现并稳定需求的主体部分 – 规避主要风险
• 精化用一句话来概括：
– 建立核心架构，解决高风险元素，定义大部分 需求，预计总体进度和资源
过程：精化
• 精化过程中最好的实践：
– 实行短时间定量、风险驱动迭代 – 及早开始编程 – 对构架的核心和风险部分进行适应性设计、实
• 领域模型关注的是 显示世界领域中的 事物的可视化
真实世界的可视 化，不表示软件
• 左侧的元素，不适 用于领域模型
软件制品 软件类
概念类
• 概念类，是思想， 事物，或对象
• 概念类，可以从 符号，内涵和外 延来考虑
• P102
领域模型不是数据模型
• 数据模型：表达的是存储在某处的持久性 数据
• 领域模型：
子大小和玩具的属性来给出的 • 顾客选择的是一种不适合3岁小孩玩的具有
一定危险性的玩具 • 店主建议找一件柔软的娃娃
领域模型
迭代1—基础需求
• Monopoly在第一次迭代中应完成处理的需 求：
– 实现基本和关键场景：游戏者围绕棋盘四周的 方格移动
– 实现用于支持迭代初始化需求的启动用例 – 支持2～8个游戏者 – 游戏通过一系列回合制进行。掷骰子，并且根
– 但是在业务流程看来，单据却非常重要。 – 总的说来，在领域模型中应该包含单据
像画地图一样的思考
• 使用领域内已有的名称 • 排除无关的或者超出范围的特定 • 不凭空添加领事物
类或者属性？
• 类或者属性？
– 某东西，不是现实世界中的文本或数字，那该 东西更多可能是一个概念类，而非属性
过程：精化
• 精化过程：
– 对核心，高风险的软件架构进行编程和测试 – 发现并稳定需求的主体部分 – 规避主要风险
• 精化用一句话来概括：
– 建立核心架构，解决高风险元素，定义大部分 需求，预计总体进度和资源
过程：精化
• 精化过程中最好的实践：
– 实行短时间定量、风险驱动迭代 – 及早开始编程 – 对构架的核心和风险部分进行适应性设计、实
• 领域模型关注的是 显示世界领域中的 事物的可视化
真实世界的可视 化，不表示软件
• 左侧的元素，不适 用于领域模型
软件制品 软件类
概念类
• 概念类，是思想， 事物，或对象
• 概念类，可以从 符号，内涵和外 延来考虑
• P102
领域模型不是数据模型
• 数据模型：表达的是存储在某处的持久性 数据
• 领域模型：
子大小和玩具的属性来给出的 • 顾客选择的是一种不适合3岁小孩玩的具有
一定危险性的玩具 • 店主建议找一件柔软的娃娃
第12章 领域建模
第12章 领域建模
状态图具有很强的表达能力。
（）
等形 式；
银行领域模型的凭证相关部分
图12-2储蓄账户的可能
状态及状态转换关系
件过程中所处的位置
12.2领域建模在软件过程中所处的位置
领域模型和需求分析的关系
项目启动
需求分析 为交流提供公领域建模
共的领域词汇
领域建模需求分析
提供探索问题
领域的语境架构设计
领域建模和需求获取之间应详细设计详细设计详细设计该是同时产生、交叠进行的。
12.2领域建模在软件过程中所处的位置
领域模型对整个软件开发活动的重要作用： • 为需求定义提供了领域知识和领域词汇。
域模型 最
新需求：
最初的人事管理
统领域模型之一角色
图12-10 升级后的模型（前者采用关联类）
图12-12领域模型的类图部分
图12-13领域模型的状
考虑分工的建模改任务
多项目管理
任
系
占用
资源项目人设备 材料
目、任务、资源的关
系越来越清晰了
12.5 建立项目管理的领域模型
项目状态建模。
08领域模型与类图
第8讲领域模型和类图
§8.1领域模型
一、面向对象方法
问题1面向对象的基本思想
问题2OOAD的主要任务
1.OOA
2.OOD
二、领域模型的概念
问题1什么是领域模型
1.什么是领域模型？
2.问题领域的重要概念
3.如何表示领域模型
问题2为什么要创建领域模型
1.解析软件设计的关键问题（困难）
1）弹性
2）稳定的结构
2.领域模型的优点
1）减少软件模型与问题域的差异
2）有助于理解领域知识三、领域模型与类图问题1类图
问题2类图的主要元素
1.类
2.泛化关系
3.依赖关系
4.关联
5.整体-部分关系
6.多重性
四、如何创建领域模型
问题1什么时候创建
问题2创建领域模型的基本原则
1.寻找概念类
1）来源
2）识别方法
2.添加类之间的关联
§8.2交易模式
一、交易模式的原理
问题1基本概念
1.交易
2.交易模式
3.交易模式总览
问题2与交易有关的“人”
1.参与者-交易模式
2.演员-参与者模式
问题3与交易有关的“地”
1.地点-交易模式
问题4与交易有关的“事”
1.交易-交易细项模式
2.交易-后续交易模式
3.交易细项-后续交易细项模式问题5与交易有关的“物”
1.物品-交易细项模式
2.特定物品-交易模式
3.物品-特定物品模式
4.特定物品-交易细项模式
5.比较。
领域模型(概念类图)
1
1
Recordsaccounts-
for
1 Used-by
*
Store
1 name address
Stocks
1
*
Product Description
itemID description price
Describes
*
Item
1..*
Logscompleted
1 Houses
1..*
*
Register
员工
*
二元关联
接待员
参与类 基数
关联名
参与
*
组织
关联类
？
顾客
顾客
？
预订
识别关联的方法——关联列表
A在物理上或逻辑上是B的一部分； A是对B的描述 A是交易或项目B中的一项 A为B所知/为B所记录/录入B中/为B所捕获 A是B的一个成员 A是B的一个组织子单元 A使用或管理B A与B通信 A与一个交易B有关 A是一个与另一个交易B有关的事务 A与B相邻 A为B所拥有 A是一个与B有关的事件
根据用例模型建立领域模型
用例模型
领域模型
管理员 用户
关闭ATM系统 启动ATM系统
查询 存钱 取钱
<<include>>
<<include>>
身份验证
<<include>>
<<include>> 银行信息系统
转账
ATM管理员
钥匙开关
ATM机
读卡器 出钞口 用户 客户交互控制台
键盘
显示器
打印机
储蓄卡
领域模型
主角
有时候，一个业务的雇员与另一个业务的雇员使用其他业务的信息系统进行。从建模后业务的角度来看，这 个信息系统就是一个业务主角。
示例：某个软件开发人员努力去理解他所负责的产品中出现的问题。为了了解问题是否源于他所使用的编程 工具，他与供应商的万维服务器，并仔细研究编程工具当前版本中已知问题的列表。通过这种方式，业务角色 “软件开发人员”与业务角色“提供商的万维服务器”进行交互。
概念
业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实 体之间应该如何和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为 产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。 它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例 。
核心元素
业务角色显示了一个人承担的一系列职责。业务实体表示使用或产生的可交付工件、资源和事件。业务用例 实现显示了协作的业务角色和业务实体如何执行某个工作流程。使用以下几种图来记录业务用例实现：图显示参 与的业务角色和业务实体。活动图，其中泳道显示业务角色的职责，而对象流显示如何在工作流程中使用业务实 体。序列图描述业务角色和业务主角之间交互的详细情况，并显示如何在业务用例执行过程中访问业务实体。
领域模型业务对象模型将结构的概念和行为的概念结合了起来。
它是一个纽带工件，用于对业务关系进行清晰的表述，表述方式与软件开发人员的思考方式类似，同时仍保 留一些纯粹的业务内容。将我们所知道的有关业务的信息按照对象、属性和职责进行了合并。
它探索业务领域知识的本质，所采用的方式使我们能够从对业务问题的思考转变到对软件应用程序的思考上 来。
领域模型
接口
接口是一种类似于抽象类的机制，接口中的方法都 是抽象方法。
图标表示法 Collection
《Interface》
构造符号表示法
图标表示方法的优点是简单，它只适用于只有单个 操作的接口和草图应用中。 构造符号表示法是采用类（interface实际上是一种特 殊的类）的方式表示，它的优点是可以添加多个抽 象方法，具有更强的表示能力。
(3) 泛化关系
泛化关系是描述类之间的继承关系。利用泛化来表 达类之间的相似性
例：售票系统的类图
3.2 UML扩展类图
1．聚合 聚合用来描述两个类之间的整体—部分关系。 在聚合中，部分类可以没有整体类而存在。
2．组合
组合是一种特殊的聚合关联。 在组合关联中用来组成整体类 的部分类不能独立存在。整体 类由部分类组成，部分类需要 整体类才能存在。这种关系意 味着销毁整体类将会同时销毁 部分类。
角色
类关系还可以通过添加角色来进一步丰富。 在类图中使用角色可以帮助读者理解第一个类对于第二个类 的作用。角色与多重性显示在相同的位置。
关联的限定
类的关联还可以通过限定条件来明确类之间的关系
关联的导航性
关联和属性
在类关联和类属性之间存在紧密的联系。 源类和目标类之间的关联意味着源类的对象能够承载到 目标类对象的引用。
面向对象的分析与设计
第3章 领域模型 (1)
领域模型
领域模型(domain model)是概念类或问题领域中实际对象 的可视化表达，又称为：
概念模型conceptual models 领域对象模型domain object models 分析对象模型analysis object models.
7领域建模
sale-3
concept's extension
sal解业务领域的关键概念和词汇 • 减小现实世界系统与OO软件模型表示差异
UP Domain Model Stakeholder's view of the noteworthy concepts in the domain. A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter. This reduces the representational gap. This is one of the big ideas in object technology. Payment amount: Money getBalance(): Money 1 Pays-for 1 date: Date startTime: Time getTotal(): Money ... Payment amount inspires objects and names in Sale Sale 1 Pays-for 1 date time
1 Airport 1
*
31
关联角色
• 关联的一每端称为角色（Role） • 角色有如下选项：
– 多重性表达式 – 名称 – 导航
32
多重性
• 多重性定义了某个时刻类A有 多少个实例可以和类B的一个 实例关联 • 多重性的值和建模者及软件开 发者的关注角度有关
UML类图详细教程PPT课件
第46页/共109页
公司直销系统用例图
第47页/共109页
4.2 UML扩展类图
一、聚合和组合 在前面，已经介绍过类之间的简单关联，知道了它们在类图中使用连接类的单线表
示。本节将介绍如何更好地限定这些关联，其方法是以聚合或者组合的形式来定义关联。 这两种新的关联类型都描述了类之间的整体——部分组成关系。 1．聚合
类图支持如下面用例图中用例。 练习步骤：
1）确定可以在用例图中找到的类。 2）创建关联类，给出它们的关联名词。 3）巩固相似的类。 4）确定任何合适的角色名。 5）为任何已经封装到另一个类中的独立功能添加类。 6）添加属性和操作以便提供类图中需要的功能。 7）为操作和属性提供数据类型和参数等信息
第45页/共109页
1）关联关系 关联关系是指类之间的语义联系。关联可以具有如下特性：
•关联名称 •角色名称 •多重性 •导航性
第17页/共109页
多个类可以关联到同一个类
第18页/共109页
多重性： 多重性（mutiplicity）用来指示一个类的多少对象与另一个类的一个对象相关。可
以在类关系的任何一端添加多重性，来指示出多重性，如下图所示。
第11页/共109页
派生的属性： 另一种可以为属性提供的信息是派生值，它可以使用数学函数、字符串函数或者将要
在应用程序中实现的其他商务逻辑。 要想指出一个属性是派生的，需要在属性名之前添 加一个前斜线（／）， 并且要附加一个注释，其中包含了派生属性值的指令，如下图所 示。
第12页/共109页
2. 操作(方法)
第19页/共109页
多重性是一个数值或者数值范围，用来指示一个类的几个对象与另一个类的一个对象相 关。如下图所示。
PPT概念图素材-共170页(对比、环绕、交叉、扩散、列举、循环、展开、整合等)
16 Point Text
20 Point Text
16 Point Text
20 Point Text
16 Point Text
20 Point Text
16 Point Text
20 Point Text
16 Point Text
5 Part Shaded Pyramid
20
12 pt
20 Point
20 Point Text
28 Point Text Here
20 Point Text
20 Point Text
20 Point Text
20 Point Text
20 Point Text
6 PartClipArt Concept
Here ClipArt Here
24 Point Text
ClipArt Here
Your Text Here Your Text Here
Your Text Here
6 Part Concept
Your Text Here Your Text Here
Your Text Here
Your Text Here Your Text Here Your Text Here
28 Point Text
扩散-放射
24 Point Text
24 Point
24 Point Text
24 Point Text
4 Part Concept
20 Point Text
20 Point Text
20 Point Text or Clip Art Here
20 Point Text
20 Point Text
20 Point Text
16 Point Text
20 Point Text
16 Point Text
20 Point Text
16 Point Text
20 Point Text
16 Point Text
5 Part Shaded Pyramid
20
12 pt
20 Point
20 Point Text
28 Point Text Here
20 Point Text
20 Point Text
20 Point Text
20 Point Text
20 Point Text
6 PartClipArt Concept
Here ClipArt Here
24 Point Text
ClipArt Here
Your Text Here Your Text Here
Your Text Here
6 Part Concept
Your Text Here Your Text Here
Your Text Here
Your Text Here Your Text Here Your Text Here
28 Point Text
扩散-放射
24 Point Text
24 Point
24 Point Text
24 Point Text
4 Part Concept
20 Point Text
20 Point Text
20 Point Text or Clip Art Here
20 Point Text
20 Point Text
领域概念模型
领域概念模型领域概念模型概念领域概念模型（Domain Concept Model，DCM）是一种用于描述特定领域内对象、属性和关系的模型。
它是软件开发中的一个重要工具，用于帮助开发人员更好地理解和描述业务需求。
作用领域概念模型的主要作用是帮助开发人员更好地理解和描述业务需求。
通过对特定领域内对象、属性和关系进行建模，可以使开发人员更加清晰地了解业务需求，并且可以在后续的软件设计、编码和测试过程中提供指导。
特点1. 抽象性：领域概念模型是对特定领域内对象、属性和关系进行抽象描述的。
它不涉及具体实现细节，而是侧重于表达业务需求。
2. 精简性：领域概念模型应该尽可能地精简。
只有最核心、最重要的对象、属性和关系才应该被包含在其中。
3. 可读性：领域概念模型应该易于阅读和理解。
它应该使用通俗易懂的术语，并且应该避免使用过于复杂或专业化的术语。
4. 可维护性：领域概念模型应该易于维护。
它应该能够随着业务需求的变化而进行调整，以保持其准确性和有效性。
建模过程1. 收集需求：在开始建模之前，需要收集业务需求。
这包括与客户和业务专家的沟通，以确定应该包含哪些对象、属性和关系。
2. 确定对象：根据收集到的业务需求，确定应该包含哪些对象。
这些对象应该是领域内最核心、最重要的对象。
3. 确定属性：对于每个对象，确定应该包含哪些属性。
这些属性应该是与业务需求密切相关的，并且能够提供有用的信息。
4. 确定关系：确定不同对象之间的关系。
这些关系可以是一对一、一对多或多对多等类型。
5. 优化模型：在完成初步建模之后，需要对模型进行优化。
这包括删除不必要的对象、属性和关系，并且确保模型足够简洁和易于理解。
6. 验证模型：在完成优化之后，需要验证模型是否符合业务需求。
这可以通过与客户和业务专家进行沟通来实现。
7. 更新模型：如果在验证过程中发现模型存在问题，需要进行更新。
这包括添加、删除或修改对象、属性和关系等。
应用场景领域概念模型可以应用于各种软件开发项目中。
第3章 类图及建立领域模型
3.2.3 泛化关系（Generalization）
也叫继承关系，是一般和特殊的关系 继承关系：a-kind-of 表示方法：一头为空心三角形的连线
运动员
public class 大球运动员 { …}
游泳运动员
球类运动员
田径运动员
public class 足球运动员 extends 大球 运动员
}
public class 活人{ private 跳动的心脏 the跳动的心脏=new 跳动的心脏(); public 活人(){} }
3.2.3 依赖（dependency)
依赖：表达“使用”的语义，用带箭头的 虚线表示。
图3-30
与关联关系不同的是，依赖关系除了“知 道”其它对象的存在，还会“使用”其他 对象的属性和方法。
1.名称（Name） 2.角色（Role） 3.多重性（Multiplicity） 3.导航性（Navigation）
关联关系
关联名 －用来描述关联的作用 －动词或动词短语
例如，图3-9显示了一个关联，建立学生和班级的 关联的名称 模型
Student name : String age : int address : String getAddress() loans() belong classes name : String collegeName : String
}
}
球队
1..2
*
球员
组合关系（composite aggregation ）
是强聚合关系，聚合中的每个部分只能属于一个整 体，而且，当组合对象销毁时，它的所有从属部分 都同时销毁。
窗口
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
关联的UML表示法
用一条写着关联名称的线段来表示两个类之 间的关联。关联自然具有双向性，这意味着 从关联两端的任何一个类的实例出发在逻辑 上都是可以达到另一端。 关联的每一端都可以包含一个多重性的表达 式，它表示两个类的实例之间的数量关系.
关联名
导读箭头
Customer
name phoneNumber
输入可能是角色的属性，也有可能是单独的一个类。
4、用例反馈与之关联的每个角色的输出是什么？
首先确定该输出的责任实体，然后进一步确认输出是否需 要识别为类。
5、用例需要操作哪些设备？
分类列表法
人 事物 地点 组织 概念 事件
规则 角色
抽象名词 交易项目
设备
组织结构
概念类分类
示例
物理或具体对象
注册
飞机
根据用例模型建立领域模型
用例模型
领域模型
管理员 用户
关闭ATM系统 启动ATM系统
查询 存钱 取钱
<<include>>
<<include>>
身份验证
<<include>>
<<include>> 银行信息系统
转账
ATM管理员
钥匙开关
ATM机
读卡器 出钞口 用户 客户交互控制台
键盘
显示器
打印机
储蓄卡
日志 转账
存钱
网络连接
取钱
银行信息系统
查询
2、建立概念模型的基本步骤
1、发现类和对象 2、建立类之间的关联 3、添加类的重要属性
2.1发现类和对象
识别概念的方法 a、使用概念类分类列表来找出概念； b、根据名词性短语识别出概念类；
领域模型中的概念类越多越好
从用例中识别概念
1、用例描述中出现了哪些实体？ 2、用例执行过程中会产生并存储哪些信息？ 3、用例要求与之关联的每个角色的输入是什么？
当你见到多对多关联，则需要考虑使用关 联类
继承
1.顾客携带购买的商品到达POS机收费口 2.收银员开始一次新的销售 3.收银员输入商品标识 4.系统记录销售的商品项列表，并显示该商品
付款信息发送到外部的记账系统（进行 记账）和库存系统
9.系统打印收据 10.顾客带着商品和收据离开
顾客，购买的商品，POS，收银员 ，新的销售，商品标识，商品项列 表，描述，价格，累加值，总价， 支付，销售信息，付款信息，记账 系统，库存系统，收据
确定对象：顾客， 摒弃对象：商品标 商品，POS，收银 识，描述，价格， 员，新的销售，商 累计值，总价 品项列表，支付， 销售信息，付款信 息，记账系统，库 存系统，收据
属性还是概念？
有时很难决定是应该将一个特 殊的信息作为一个类还是作为 一个属性包含在领域模型中。
类：标识、状态和行为
－关联（包括聚合和组合） －继承（一般与特殊的关系） －依赖
关联
类之间的某种语义关系。这种 语义关系体现了事物之间的联 系。进一步说，联系又可以分 为长久的、稳定的联系和短暂 的、不稳定的联系。
员工
*
二元关联
接待员
参与类 基数
关联名
参与
*
组织
关联类
？
顾客
顾客
？
预订
识别关联的方法——关联列表
A在物理上或逻辑上是B的一部分； A是对B的描述 A是交易或项目B中的一项 A为B所知/为B所记录/录入B中/为B所捕获 A是B的一个成员 A是B的一个组织子单元 A使用或管理B A与B通信 A与一个交易B有关 A是一个与另一个交易B有关的事务 A与B相邻 A为B所拥有 A是一个与B有关的事件
关键思想
领域模型是现实世界的一个可视化抽象字典
它可视化了领域中的单词或概念类，并为这些单词 或概念类建立了关联
领域模型是没有方法的类图的集合，并且在领
域模型中不会出现软件工件
Sale
store
register
date
sale
time
SalesDatabase
Sale date time Print()
1 Makes
* Reservation
顾客和预定建模
多重性
•规定关联的重数，每个预定是由一个顾客 进行的，这个人的姓名和电话由系统记录， 但是每个顾客可以进行多个预定
建立关联的原则
1）注意力集中在那些需要将概念之间的关 系信息记忆一段时间的关联上（“需要记
花住费”在型领关联域）模。型创建的大部分时间 应2）该识被别用出概于念识类别比概识别念出类关，联而更为非重关要联。
超市收银台
主要的成功场景： 1.顾客携带购买的商品到达POS机收费口 2.收银员开始一次新的销售 3.收银员输入商品标识
4.系统记录销售的商品项列表，并显示该 商品的描述、价格和累加值。价格可以 根据一套定价规格来计算
收银员重复3-4步，直到结束
主要的成功场景(续)： 5.系统显示最后的总价 6.收银员请顾客付款 7.顾客支付，系统处理支付 8.系统记录完整的销售信息，并将销售和
领域模型
软件学院 代飞
2019·秋
内容
1、概念模型的简介 2、建立概念模型的基本步骤
1、领域模型简介
领域模型：显示最重要的业务概念和它们 之间的关系的类图。 领域模型用：
类表示业务概念，但类通常只包含重要属性 ，不包含操作
关联和泛化显示了这些概念之间的关系。
它是真实世界中各个事物的表示，而不是软 件中各构件的表示。
事务的设计、描述和规范 产品说明 飞机说明
位置
商店
飞机场
交易项目
销售项
人的角色
收银员
飞行员
其他事务的容器
商店
箱柜
容器包含的元素
商品
乘客
在该系统之外的其他计算机 授权支付系 飞行事务控
或电子机械系统
统
制系统
抽象名词的概念
购买欲
恐高症
……
名词分析法
识别问题域和用例描述中的 名词和名词短语，然后将它们 作为候选的概念类或属性
关联的命名
采用动词短语来为关联命名；
关联的名称应该以大写字母开头。动词 短语由几个单词组成时需用连字符“－ ”将单词连接在一起。
Paid-by
PaidBy
基于类型名-动词短语-类型名的格式来
为一个关联命名:
商店-包含-收银台
关联类
关联类和其他类相似。只不过一般类描述的 是实体，而关联类描述的是关系。
3）关联太多不仅不能有效展示概念模型， 反而会使概念模型变得混乱。
4）要避免关联之间的信息冗余以及减少派 生关联。
建立关联的原则…
5）概念模型概念间的关联是从纯分析角 度声明有意义的概念间的联系，不需要 考虑如何实现关联。
6）分析阶段得到的关联可能在设计阶段 发现是无用的；设计阶段有可能发现分 析阶段遗漏了有些概念间的关联。