Ch03细化迭代1-OOA

写出第一版的愿景文档（Vision）和补充规格说明书（Supplementary Specification）。
• •
列出风险表（risk list）。
为了探讨特殊需求的技术可行性（technical feasibility），进行技术上的概 念验证的原型（prototypes）和其它的调查（investigations）。
启发了对象 及其名称
UP 设计模型 面向对象开发者在创建软件类时受到真实世界领域的启发 因此，涉众所设想的领域与其在软件的表示之间的表示差异被 降低
16
OOAD
如何创建领域模型
(1) 寻找概念类 (2) 将其绘制为UML类图中的类 (3) 添加关联和属性
17
OOAD
如何找到概念类
• 找到概念类的三条策略
OOAD
领域模型
• 领域模型(domain model)是对领域内的概念类或 现实中对象的可视化表示。
• 领域模型也称为概念模型、领域对象模型和分析 对象模型。 • 应用UML:类图
– 领域对象或概念类 – 概念类之间的关联 – 概念类属性
8
OOAD
示例：NextGen POS 部分领域模型
概念或 领域对象 Sales LineItem quantity 1..* Stocked-in 关联 Contained-in 1 Sale 属性 date time 1 Paid-by 1 Payment amount Store address name 1 Houses 1..* Register Captured-on 1 1 0..1 Records-sale-of 1 Item
• 节点间可以有(n*n(n-1))/2个关联 • 太多关联，会产生“视觉干扰，使图变混 乱。 • 要谨慎地增加关联线，并重点关注”需要 记住“的关联。
31
OOAD
观点：关联是否会在软件中实现
• 在领域建模中，关联不是关于数据流、数 据库外键联系、实例变量或软件方案中的 对象连接语句；关联声明是针对现实领域 从纯概念角度看有意义的关系。 • 这些关系的大部分将作为（设计模型和数 据模型中的）导航和可见性路径在软件中 加以实现。
– 重用和修改现有模型。
• 在许多常见领域中都存在已发布的，绘制精细的领 域模型和数据模型
– 使用分类列表（见P104表9-1） – 确定名词短语。将对领域的文本描述中的名词 和名词短语作为候选的概念类或属性。（见 P106用例的文本描述）
18
OOAD
示例：寻找和描述概念类(NextGen POS）
5
OOAD
在多个迭代里对同一用例进行增量式开发
1 2 3 ... 一个用例或特性对于一个 简短的迭代来说通常过于 复杂而难以完成 因此，必须将不同部分或 场景分配到不同的迭代中 进行
用例： 处理销售
用例： 处理销售
用例： 处理销售
用例： 处理租金 特性： 日志记录
图8-1 用例的实现可能在多个迭代中展开
Airport name
Baidu Nhomakorabea
25
OOAD
准则：何时使用“描述”类建模
• 描述述(description class)包含描述其它事 物的信息。 • 如：ProductDescription记录Item的价格、 图片和文字描述。命名方式：项目-描述符
26
OOAD
准则：何时需要描述类
Item description price serial number itemID 较差
• • • • •
为了阐明功能需求的愿景，产生面向用户界面的原型（prototypes）。 给出关于购买/构建/重用组件的建议。 高层的候选架构（candidate architecture）和构件的建议 . 第一次迭代（iteration）的计划。 候选工具的列表。
4
OOAD
细化阶段会开始构建哪些制品
Sale date time 概念符号:表示概念类的词语或图形
“Sale表示购买交易的事件、 具有日期和时间”。
概念内涵：概念类的定义
sale-1 sale-2
sale-3
概念外延：概念类所适用 的一组示例
sale-4
14
图9-5 概念类具有符号、内涵和外延
OOAD
领域模型和数据模型是一回事吗
• 领域模型不是数据模型（持久化数据）
• 在领域模型中不会排除没有明确要求记录 其相关信息的类，也不会排除没有属性的 概念类
– 在领域内充当纯行为角色而不是信息角色的概 论类也是有效的。
15
OOAD
动机：为什么要创建领域模型
• 理解关键概念和词汇 • 降低与OO建模之间的表示差异
UP领域模型 涉众对领域内重要概念的看法 Payment 领域模型中的Payment是概念， 但在设计模型中的Payment是软 件类。它们不是一回事，但前 者对后者的名称和定义有启发 作用。 这减少了表示差异 这是对象技术的主要思想之一 Payment amount: Money getBalance(): Money 1 Pays-for 1 date: Date startTime: Time getTotal(): Money ... Sale amount Sale 1 Pays-for 1 date time
OOAD
UML面向对象的分析与设计
Object Oriented Analysis and Design with UML
邓成剑
1
OOAD
第3章 细化迭代1—OOA
3.1 细化阶段 3.2 领域模型
– – – – 领域模型 概念类 关联 属性
3.3 系统顺序图 3.4 操作契约
教材CH08, CH09，CH10，CH11
在初始阶段发生了什么
•
• •
简短的需求讨论会；
大多数参与者（actors）、目标（goals）和用例（use cases）的命名。
按概要格式（ brief format ）写出多数用例，其中10-20% 的用况按详细格式 （fully dressed）描述。
•
•
找出大多数有影响的，有风险的质量需求（quality requirements）。
*
Flight Described-by date time
FlightDescription 1 number
较好
*
*
Describes-flights-to 1 Airport name
图9-10 对其它事物的描述
28
OOAD
关联
• 关联(association)是类（更精确也说，是这些类 的实例）之间的关系，表示有意义和值得关注的 连接。 • 在UML中，关联被定义为“两个或多个类之间的 语义联系，涉及这些类元实例之间的连接。
Register Item Store Sale
Sales LineItem
Cashier
Customer
Ledger
Cash Payment
Product Catalog
Product Description
图9-7 初始的POS领域模型
19
OOAD
准则：敏捷建模-绘制类图的草图
• 注意图9-8中UML类图的风格，让类框的底 部和右侧呈开放状态，以方便扩展。
经历状态变化的领域对象、 属性和关联
领域模型中某 些术语的细化
Operation: enterItem(…) Post-conditions: -... 操作契约
Cashier: … Item ID: … ... 词汇表
需求
领域中的 概念类会 给某些设 计中软件 类的名称 带来启示
设计模型 : Register enterItem (itemID, quantity) spec = getProductSpec( itemID ) addLineItem( spec, quantity ) ... : ProductCatalog : Sale
避
免
SalesDatabase
软件制品，不属于领域模型
避
免
date time print()
Sale 软件类，不属于领域模型
图9-4 领域模型并非表示软件制品或类
13
OOAD
什么是概念类
• 概念类(conceptual class)是思想、事物或对象。更 正式地讲，概念类可以从其符号、内涵和外延来考 虑。
6
OOAD
NextGen POS应用 在第一次迭代中要处理的需求
实现“处理销售”用例中基本的和关键的场景：输入 商品项目并收取现金
• • • • •
实现用于支持迭代初始化需要的“启动”用例 不考虑非正常情况，设计和实现主要场景 不考虑与外部服务的协作，例如税金器或产品数据库 不考虑复杂的价格规则
7
*
0..1
图9-2 部分领域模型：可视化字典
9
OOAD
业务建模
Sale date ... 1 1..*
UP制品关系示例 域模型 Sales LineItem quantity ... ...
概念类、术语、概念、 属性、关联
用例模型 Process Sale 1. Customer arrives ... 2. ... 3. Cashier enters item identifier. 4.... 用例文本
设计
图9-1 UP制品样例的影响
10
OOAD
领域模型是软件业务对象图吗
在UML中，领域模型被描 述为一组没有定义操作的 类图
Sale dateTime
对领域内所关注的真实世界概念的可视化 并非表示软件类
图9-3 领域模型表示真实世界概念的可视化并非表示软件类
11
OOAD
“领域模型”的两个传统含义
22
OOAD
准则：像地图绘制者一样思考：使用领域术语
• 使用地域中现有的名称。在图书馆模型中， 将顾客命名为“借书者”、“赞助者”等， 这是图书馆职员使用的术语。 • 排除无关或超出范围的特性 • 不要凭空增加事物
23
OOAD
准则：如何对非现实世界建模
• 有些软件系统的领域与自然领域或业务领 域几乎没有类似之处，例如：电信软件。 • 此时需要高度的抽象，对常见的非OO设计 进行回顾，并且认真汲取领域专家所使用 的核心词汇和概念。 • 例如，电信软件的候选概念类：消息、连 接、端口、会话、路由、协议。
ProductDescription description price itemID Describes 1 Item 较好
*
serial number
图9-9 关于其它事物的描述
27
OOAD
示例：航空领域中的描述
Flight date number time Flies-to Airport 较差 1 name
• 含义一：领域模型是现实世界中对象的概 念透视图，而非软件透视图 • 含义二：软件对象的领域层。在表示层之 下的软件对象层是由领域对象组成的。领 域对象是表示问题领域空间事物的软件对 象，并且与“业务逻辑”或“领域逻辑” 方法相关
在本书中，用领域层(domain layer)来表示第二种含义
12
OOAD
2
OOAD
细化阶段
细化(Elaboration)是一般项目最初一系列迭代， 包括：
•
• •
•
对核心、有风险的软件架构进行编程和测试 发现大多数主要需求，并且稳定下来； 降低和排除主要风险；
用一句话来说明细化阶段的工作: 构建核心架构，解决高风险元素，定义大部分需求、 以及预计总体进度和资源
3
OOAD
20
OOAD
准则：敏捷建模-是否要使用工具维护模型
• 在后期的草图设计中或编程中发现新的概 念类，是否需要更新早期的概念模型？视 情况而定 • 通常，进化的软件领域层对大部分重要术 语会给予提示，而且长生命期的OO分析领 域模型不会增加价值。
21
OOAD
准则：报表对象-模型中是否要包括“票据”
• 一般来说，在领域模型中显示其它信息的报表并 没有意义，因为其所有信息都是源于或复制于其 他信息源的。这是排除它的理由 • 另一方面，就业务规则而言，票据有特殊的作用： 通常持有（纸质）票据的人有退货的权利。这是 在模型中要表示它的原因 在本次迭代中没有考虑退货，所以不应包括票据。 在解决“处理退货”用例的迭代中，再考虑将其 包含在内。
关联
Register
Records-current 1
图9-11 关联
29
1
Sale
OOAD
准则：何时表示关联
• 在领域模型中要考虑如下关联：
– 如果存在需要保持一段时间的关系，将这种语 义表示为关联（“需要记住”的关联）。 – 从常见关联列表中派生的关联（见P115表9-2）
30
OOAD
准则：为什么应该避免加入大量关联
24
OOAD
准则：属性与类的常见错误
• 常见错误：把应该是概念类的事物表示为属性 • 判别准则：如果我们认为某概念类X不是现实世 界中的数字或文本，那么X可能是概念类而不是 属性。
Sale store 或…? Sale Store phoneNumber
Flight destination
或…?
Flight