领域模型(概念类图)
第5讲细化阶段与领域模型
Construction Phase Transition Phase
3
Week 15
Week 31
2
Week 25
Week 32
2019/4/8
上海交通大学计算机科学与工程系
15
Phase
Iteration
Description
Associated Milestones
Risks Addressed
2019/4/8
上海交通大学计算机科学与工程系
12
产品定位描述
For Wylie College students, professors, and the course registrar Attend, teach, or administer college courses
Who
The Course Registration System
的高风险用例进行分析和设计。通过开发架构原 型 验证Release1.0所需要的架构的可行性和性能 Release 1.0计划包含的特征:
Logon Close Registration Register for Courses Interface to Course Catalog Database Interface to Finance System Maintain Student Information Maintain Professor Information
上海交通大学计算机科学与工程系
2019/4/8
5
1.3核心活动
尽快定义和验证体系架构，并确定体系架构基线 细化远景 为构造阶段建立详细的迭代计划并建立基线 细化开发用例并将其部署到开发环境中 细化体系架构并选择组件
领域模型、贫血模型、充血模型概念总结
领域模型、贫⾎模型、充⾎模型概念总结领域模型领域模型是对领域内的概念类或现实世界中对象的可视化表⽰。
⼜称概念模型、领域对象模型、分析对象模型。
它专注于分析问题领域本⾝，发掘重要的业务领域概念，并建⽴业务领域概念之间的关系。
业务对象模型（也叫领域模型 domain model）是描述业务⽤例实现的对象模型。
它是对业务⾓⾊和业务实体之间应该如何联系和协作以执⾏业务的⼀种抽象。
业务对象模型从业务⾓⾊内部的观点定义了业务⽤例。
该模型为产⽣预期效果确定了业务⼈员以及他们处理和使⽤的对象（“业务类和对象”）之间应该具有的静态和动态关系。
它注重业务中承担的⾓⾊及其当前职责。
这些模型类的对象组合在⼀起可以执⾏所有的业务⽤例。
贫⾎模型是指领域对象⾥只有get和set⽅法（POJO），所有的业务逻辑都不包含在内⽽是放在Business Logic层。
优点是系统的层次结构清楚，各层之间单向依赖，Client->（Business Facade）->Business Logic->Data Access Object。
可见，领域对象⼏乎只作传输介质之⽤，不会影响到层次的划分。
该模型的缺点是不够⾯向对象，领域对象只是作为保存状态或者传递状态使⽤，它是没有⽣命的，只有数据没有⾏为的对象不是真正的对象，在Business Logic⾥⾯处理所有的业务逻辑，对于细粒度的逻辑处理，通过增加⼀层Facade达到门⾯包装的效果。
在使⽤Spring的时候，通常暗⽰着你使⽤了贫⾎模型，我们把Domain类⽤来单纯地存储数据，Spring管不着这些类的注⼊和管理，Spring 关⼼的逻辑层（⽐如单例的被池化了的Business Logic层）可以被设计成singleton的bean。
假使我们这⾥逆天⽽⾏，硬要在Domain类中提供业务逻辑⽅法，那么我们在使⽤Spring构造这样的数据bean的时候就遇到许多⿇烦，⽐如：bean之间的引⽤，可能引起⼤范围的bean之间的嵌套构造器的调⽤。
4 领域分析——1.类图
系统测试 [5] [工期 = 2 天]
项目验收 [6] [工期 = 4 天]
用例规约 [2.2] [工期 = 3 天] 系统需求确定 [2.1] [工期 = 2 天] 需求评审 [2.3] [工期 = 1 天]
可行性研究
领域分析
需求分析
设计
编码
测试
交付
我们的进度，在这里
通过用户访谈获取需求，形成需求陈述， 并在此基础上完成领域分析，建立业务领域 的数据模型。
◦ 可被接受的数字，最大最小是多少？ ◦ 可被接受的字符串，最长最短是多少？
可行性研究
领域分析
需求分析
设计
编码
测试
交付
我们的进度，在这里
访谈对象：图书馆工作人员 Q1：请问您平时主要有哪些工作要做呢？ A1：我的日常工作包括图书管理（图书的入库，报废，遗失）、图 书的借阅（包括借出图书和归还图书）、还有就是借阅管理（主要是 为学生办理学生借阅证）。 Q2：您在进行图书管理工作，比如图书入库的时候是怎样的流程？ 图书报废的时候又是怎样的，您能谈一下吗？ A2：一般来讲，我们每学年都需要采集一些图书。当图书从采购部 采集进来之后，我们为每本图书建立条码和图书信息，在每本书上粘 贴条码，并登记图书信息到图书信息表。学校图书馆的图书很少报废， 如果报废的话就需要在图书信息表中的备注栏登记一下。如果丢失的 话，会在图书信息表中备注栏记录遗失情况。
主要知识点： 5.1 类 5. 3 关系
类(Class)、对象(Object)和它们之间的关系是面向 对象技术中最基本的元素。类图技术是OO方法的 核心。 类图标加上它们之间的关系就构成了类图。 A class diagram is a graphic presentation of the static view that shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships.
软件工程-12领域模型-概念的可视化
03
之间的关系，从而更好地进行游戏设计和开发。
网站开发
网站开发是指设计和实现网站的 过程。
软件工程领域模型在网站开发中， 可以帮助团队更好地理解和管理 网站的架构和功能，提高网理解网站的结构和各个页面之间 的关系，从而更好地进行网站设
计和开发。
05 软件工程领域模型的挑战 与解决方案
同的语言，有助于更好地沟通和协作。
简化复杂概念
02
通过抽象化方式，领域模型简化了复杂的软件工程概念和过程，
使学习和理解更加容易。
指导实践
03
领域模型可以作为指导软件工程实践的框架，帮助组织和管理
软件开发过程。
领域模型的历史与发展
历史背景
随着软件工程的发展，领域模型的概念逐渐形成并得到广泛应用。早期的领域 模型主要用于描述软件开发的静态结构，而现代的领域模型则更加注重描述动 态过程和交互关系。
版本控制与团队协作
挑战
随着团队规模的扩大和开发任务的增多，如 何实现高效的团队协作和版本控制，是软件 工程领域面临的又一挑战。
解决方案
采用版本控制系统（如Git），实现代码的 版本管理和团队协作。通过分支管理、合并 操作和冲突解决等手段，降低版本控制的风 险。同时，加强团队沟通，定期召开团队会 议，及时了解项目进展和存在的问题，提高 团队协作效率。
软件工程领域模型在开发企业级软件时，可 以帮助团队更好地理解和管理复杂的业务逻 辑和系统架构，提高软件质量和开发效率。
嵌入式系统开发
嵌入式系统是指嵌入到硬件中的计算机系统，广泛应用于智能家居、智能硬件等领 域。
软件工程领域模型在嵌入式系统开发中，可以帮助团队更好地理解和设计硬件与软 件之间的交互和通信，提高系统的可靠性和稳定性。
UML模式应用—领域模型
D e s c rib e s 1
Ite m B e tte r
F lig h t d a te number tim e F lie s -to A irp o rt
*
s e ria l n u m b e r
*
F lig h t D e s c rib e d -b y d a te tim e
课程迭代
–强调的是基础范围和在构建对象系统中所使用的常见 OOA/D技术.
2
IntellAgile
领域模型
面向对象软件系统包括一组软件对象
对一个特定的软件系统，如何发现这些软件对象？ 说明了问题领域内有意义的概念 是设计软件对象的灵感来源
领域模型
领域模型是OOA中的最重要和典型的模型
3
IntellAgile
领域模型
什么是领域模型
是对领域内的概念或现实世界中对象的可视化表示 ，也称概念模型、领域对象模型或分析对象模型
concept o r d o m a in o b je c t S a le s L in e Ite m q u a n tity 1 .. * S to c k e d -in a s s o c ia tio n C o n ta in e d -in 1 S to re a d d re s s nam e 1 H ouses P a id -b y 1 .. * R e g is te r C a p tu re d -o n P aym ent 1 am ount 0 ..1 R e c o rd s -s a le -o f 1 Ite m
5
IntellAgile
领域模型(概念类图)
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机
读卡器 出钞口 用户 客户交互控制台
键盘
显示器
打印机
储蓄卡
酒店入住管理系统 用例图类图
参加者 顾客、前 XX 服务员 前提条件 有剩余房间 事件流 基本流：顾客登录 XX 上酒店预订系统或者 XX 完成预订房间的动作 备选流〔异样流〕：没有剩余房间，XX 占线，XX 站出错 后置条件 系统记录顾客预订信息或者拒绝预订 其他 同一时刻预订胜利的顾客人数受前 XX 服务人员人数和 XX 站负载度的 限制 用例 01 的活动图： 用例编号
事件流
备选流〔异样流〕：XX 占线，XX 站出错
基本流：顾客到前 XX 与前 XX 服务人员完成相关信息的登记
后置条件
备选流〔异样流〕：前 XX 服务人员劳碌需等待
系统取消顾客之前的订单
后置条件
其他
系统登记顾客相关信息
同一时刻取消订单胜利的顾客数受前 XX 服务人员人数和 XX 站负载度
其他
的限制
同一时刻登记胜利的顾客人数受前 XX 服务人员的限制
第1页共1页
用例编号
本文格式为 Word 版，下载可任意编辑，页眉双击删除即可。
用例编号
04
05
用例名称
用例名称
退房
付费
用例目的顾客完成退房动作
用例目的顾客完成付费
参加者
参加者
顾客、前 XX 服务员
顾客、财务人员
前提条件
前提条件
已完成登记和入住
顾客完成预订、入住和退房的动作
事件流
事件流
基本流：顾客到前 XX 完成退房
第1页共1页
本文格式为 Word 版，下载可任意编辑，页眉双击删除即可。
02
用例编号
用例名称
03
取消预订
用例名称
用例目的顾客取消之前的订单
登记
参加者
用例目的顾客入住前完成相关信息的登记
领域分析
保留正确的关联（2 保留正确的关联（2） 派生关联：忽略那些根据其它关联而定 义的关联，因为它们是冗余的。 关联终端名：在合适的地方增加关联终 端名。 限定关联：限定符可以区分在关联中 “多”方上的对象。 多重性 聚合：对于那些涉及机械部件和原料单 的应用而言，聚合是十分重要的。
这些东东是怎么成事的？ 月老牵线搭桥，介绍小伙和姑娘认识； 姑娘和小伙一见钟情，成为一对恋人； 一对恋人开始拍拖； 小伙追求献花，表达对姑娘的爱意； 姑娘收到999火红玫瑰，激动得头晕目眩； 小伙真心求婚，姑娘以身相许； 一对恋人终于走入婚姻殿堂。
用面向对象世界观看事物的答案 A.这里面有些什么东东？ 答：
领域模型 领域模型（domain model）是对领域内 的概念类或现实世界中对象的可视化表 示。 应用UML表示法，领域模型被描述为一 组没有定义操作的类图。它提供了概念 透视图。可以展示： a、概念对象或概念类。 b、概念类之间的关联 c、概念类的属性
创建领域类模型的步骤
寻找类 准备数据字典 寻找关联 寻找对象和联接的属性 使用继承组织和简化类 验证可能查询的访问路径 迭代并细化模型 重新考虑抽象的层次 把类组织成包
站在六个角度来看待事物 A.这里面有什么东东？ B.每个东东看上去是什么样的？ C.每个东东能做点什么用？ E D.这些东东都呆在什么地方？ A E.这些东东之间有什么关系？ F.这些东东是怎么成事的？
B C F
D
“昨天我的一个朋友结婚了” 昨天我的一个朋友结婚了” 这里面有什么东东？
月老，小伙，姑娘，恋人，玫瑰花。
他们都是普通人
月老，小伙，姑娘有共同的属性“年纪”和 “性情”，虽然作为普通人还有很多其他的 属性，但在此起重要作用的大概就这两条了， 于是得到关系。
领域模型
主角
有时候，一个业务的雇员与另一个业务的雇员使用其他业务的信息系统进行。从建模后业务的角度来看，这 个信息系统就是一个业务主角。
示例：某个软件开发人员努力去理解他所负责的产品中出现的问题。为了了解问题是否源于他所使用的编程 工具，他与供应商的万维服务器，并仔细研究编程工具当前版本中已知问题的列表。通过这种方式，业务角色 “软件开发人员”与业务角色“提供商的万维服务器”进行交互。
概念
业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实 体之间应该如何和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为 产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。 它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例 。
核心元素
业务角色显示了一个人承担的一系列职责。业务实体表示使用或产生的可交付工件、资源和事件。业务用例 实现显示了协作的业务角色和业务实体如何执行某个工作流程。使用以下几种图来记录业务用例实现：图显示参 与的业务角色和业务实体。活动图，其中泳道显示业务角色的职责，而对象流显示如何在工作流程中使用业务实 体。序列图描述业务角色和业务主角之间交互的详细情况，并显示如何在业务用例执行过程中访问业务实体。
领域模型业务对象模型将结构的概念和行为的概念结合了起来。
它是一个纽带工件，用于对业务关系进行清晰的表述，表述方式与软件开发人员的思考方式类似，同时仍保 留一些纯粹的业务内容。将我们所知道的有关业务的信息按照对象、属性和职责进行了合并。
它探索业务领域知识的本质，所采用的方式使我们能够从对业务问题的思考转变到对软件应用程序的思考上 来。
领域模型
接口
接口是一种类似于抽象类的机制，接口中的方法都 是抽象方法。
图标表示法 Collection
《Interface》
构造符号表示法
图标表示方法的优点是简单，它只适用于只有单个 操作的接口和草图应用中。 构造符号表示法是采用类（interface实际上是一种特 殊的类）的方式表示，它的优点是可以添加多个抽 象方法，具有更强的表示能力。
(3) 泛化关系
泛化关系是描述类之间的继承关系。利用泛化来表 达类之间的相似性
例：售票系统的类图
3.2 UML扩展类图
1．聚合 聚合用来描述两个类之间的整体—部分关系。 在聚合中，部分类可以没有整体类而存在。
2．组合
组合是一种特殊的聚合关联。 在组合关联中用来组成整体类 的部分类不能独立存在。整体 类由部分类组成，部分类需要 整体类才能存在。这种关系意 味着销毁整体类将会同时销毁 部分类。
角色
类关系还可以通过添加角色来进一步丰富。 在类图中使用角色可以帮助读者理解第一个类对于第二个类 的作用。角色与多重性显示在相同的位置。
关联的限定
类的关联还可以通过限定条件来明确类之间的关系
关联的导航性
关联和属性
在类关联和类属性之间存在紧密的联系。 源类和目标类之间的关联意味着源类的对象能够承载到 目标类对象的引用。
面向对象的分析与设计
第3章 领域模型 (1)
领域模型
领域模型(domain model)是概念类或问题领域中实际对象 的可视化表达，又称为：
概念模型conceptual models 领域对象模型domain object models 分析对象模型analysis object models.
8.2-8.6类图
☆什么是领域建模？
☆建立领域模型有什么用？
1． 我们设计一个系统，总是希望 它能解决一些问题，这些问题总是 会映射到现实问题和概念。 2. 对这些问题进行归纳、分析的 过程就是领域建模（这个域，指的 就是问题域）。
1. 通过建立领域模型能够 从现实的问题域中找到最有 代表性的概念对象。 2. 并发现出其中的类和类 之间的关系，因为所捕捉出 的类是反馈问题域本质内容 的信息。
☞ 注意：识别出对解决问题起关键作 用的关联，而不是现实中的 全部关联。
4
识别泛化关系
★ 假如图书馆出收藏图书之外还收藏了其他资源，比如影 碟（VCD/DVD）、音乐CD、电子书等品种。它同图书 在系统中是有区别的，比如属性，借阅期限等不同，该 如何表现这种类属关系呢？ 这时，可以采取泛化关系。
1.什么是泛化？
（2）保持属性的简单性
①仅定义与系统责任和系统目标有关的属性。
②使用简单数据类型来定义属性。
③不使用可导出的属性。
④不为对象关联定义属性。
（3）属性的说明 对于每一个属性应进行适当说明，包括以下内容：
①属性的名称和解释。
②属性的数据类型。
③其他要求。（取值范围，默认值）
3
识别对象的关联
1、什么是关联？
订单
订购
产品
例：单向关联
2. 整体-部分关联
☞ 如果对象a是对象b的一个组成 部分，则称b为a的整体对象， a为b的部分对象，二者对应 的关联形式为整体-部分关联。 图书品种 1 C C * 图书
(a)组合聚集
☞ 有两种类型，组合聚集和共享 聚集。
学生社团
1 C C
*
学生
(b)共享聚集
领域概念模型
领域概念模型领域概念模型概念领域概念模型（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 ）
是强聚合关系，聚合中的每个部分只能属于一个整 体，而且，当组合对象销毁时，它的所有从属部分 都同时销毁。
窗口
大象版UML领域建模
领域模型
业务模型：在特定的业务场景下研究特定的 业务实例 领域模型实质：从所有业务用例场景对象交 互模型当中抽象出来的更高级别的业务对象 模型，表示业务对象结构和交互的一般规律， 揭示业务运动的“本质”和“核心”。
领域模型
建立和验证领域模型可以使用CRC方法。 Class Responsibility Collaborator（以下简称 CRC）模型（Beck & Cunningham 1989; Wilkinson 1995; Ambler 1995）是一种收集 并整理卡片的开发方式。一个CRC卡片由三个组成 部分构成：1、首先构成相似现实对象的类；2、 明确此类应该知道或者应该做的职责；3、找出在 此类实现职责过程中产生相互作用的其他类作为协 作者。如下图所示。
分析领域模型
领域建模过程是一个提出和求解的过程。实际上， 领域模型要做的事情就是为问题领域寻找和建立起 适合的业务对象，由这些业务对象以及相互之间的 交互来满足问题领域的要求。这个过程可以类比为 列方程和解方程，设定未知数列出方程，求解。 求解过程中，未知数就是要寻找的领域对象，方程 就是对象的交互场景（该场景能够解决提出的领域 问题），而最终的解就是领域对象模型。
领域建模归纳
第五：在联立方程组，即遍历相关的业务用 例场景时，对未知数进行调整，可以增加、 减少、合并和拆分等等，使之尽量满足所有 的业务用例场景。 第六：绘制出领域模型的静态图，绘制出领 域对象，领域对象之间的关系以及领域对象 与业务对象之间的关系。参看图9.21和 9.22
建立领域模型
图9.21 用户档案领域模型
建立领域模型
图9.21中的领域对象模型还比较粗略，在系 统分析阶段可以更加详细的明确每一个领域 对象的详细构成。 在这个例子中，基本资料领域对象来源于申 请单，申请单又是由用户信息，申请资料等 构成，相应的，我们可以补充基本资料领域 对象，如图9.22所示。实际上，该图表明领 域对象构成的同时，还表明了领域对象域模型场景示例—编排抄表计划
领域模型概念类描述文档
领域模型概念类描述文档领域模型：概念类的简要说明：Payment：（付款）amount 为了确定是否提供足够的支付金额，并且计算零头，所以必须记录总额（或“支付总额”）。
Custumer：（顾客）Product Description：（产品描述）description 显示在显示器或票据上的描述。
itemID 用于查询ProductDescription。
price 显示商品单价并计算销售总额。
Product Catalog：（产品目录）Ledger：（总账）Sale：（销售）dateTime 票据上一般要显示销售的日期和时间，同时可用于销售分析。
Item：（商品）Sales Line ltem：（销售商品项）quantity 当同一种商品售出多个时（例如，5包豆腐），需要记录收银员输入的该商品的数量。
Store：（商店）address, name 票据上需要有商店的名称和地址。
Register：（终端）id 终端的编号。
Cashier：（收银员）id 收银员的编号。
关系及关系描述：与其他交易相关的交易：Sale Paid-by Payment。
顾客发起的交易：Sale Is-for Customer。
交易在终端上被捕获：Sale Captured-on Register。
总账记录着交易：Sale Logs-completed Ledger。
交易中的项目：Sale Contains Sales Line Item。
交易（或项目）对应的商品：Sales Line ltem Records-sale-of Item。
每个商店有自己的总账记录收账：Ledger Records-accounts-for Store。
产品目录被商店使用：Product Catalog Used-by Store。
产品目录包含产品描述：Product Catalog Contains Product Description。
系分
用例图（Use case）参与者，通过使用系统服务实现其目标的那些人或者事物用例，外部可见的系统功能，对系统提供的服务进行描述。
用椭圆表示。
用例是动词或者动名词。
可以从每一个界面的主要功能来析取用例。
关系：用例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所示：泛化包含扩展扣分点：参与者，用例的词性（动名词），关联是实线还是虚线，关联是否有箭头活动图（Activity）：每一个用例有一个活动图，活动图尽量简单开始节点：（只有一个）结束节点：（可以有多个）同步条：（必须成对出现），表示并行执行选择：（需要写明分支的判断条件）活动：（圆边矩形，必须与状态图进行区分，动名词，可以从一个用例的执行流程中分析出动词）扣分点：同步条必须成对出现，判定需列明条件，活动的框一定是圆边矩形状态图（statement）：每一个用例有一个状态图，显示一个对象从创建到消亡的整个生命周期状态：表示对象具有的一个状况，条件（名词或者说是动名词格式）转移：事件名[监护条件]/动作名（如果前面出现“/”,说明是系统的动作，不加是使用者进行的操作）开始/结束状态：扣分点：状态是圆角矩形，状态不能是一个动作（动名词格式），而是一个状况（名词或者名词+动词的格式）必须要有状态发生变化的条件领域模型（domain model）：一组没有定义操作（方法的特征标记）的类图，也称为概念类图步骤：（1）寻找概念类概念类：思想，事物或对象（也就是说找名词）描述类：描述其他事物的信息，如Flight和Airport之间最好添加一个FlightDescription这个描述类。
（2）将其绘制为UML类图的类（3）添加关联和属性关联：名称需要首字母大写，一般以类名-动词短语-类名的格式来命名。
但在领域模型中，避免加入太多关联，是否需要记录关联，要基于现实世界的需要，就是那些“需要记住”的关联关系。
多重性：类A有多少个实例可以和类B的一个实例关联0或更多1或更多1~40属性：对象的逻辑数据值。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
输入可能是角色的属性，也有可能是单独的一个类。
4、用例反馈与之关联的每个角色的输出是什么？
首先确定该输出的责任实体，然后进一步确认输出是否需 要识别为类。
5、用例需要操作哪些设备？
分类列表法
人 事物 地点 组织 概念 事件
规则 角色
抽象名词 设备
交易项目 组织结构
关联的UML表示法
用一条写着关联名称的线段来表示两个类之
间的关联。关联自然具有双向性，这意味着
从关联两端的任何一个类的实例出发在逻辑
上都是可以达到另一端。
关联的每一端都可以包含一个多重性的表达 式，它表示两个类的实例之间的数量关系.
导读箭头 关联名
Customer name phoneNumber
itemID, description，price
quantity name
Records-sale-of Product Description Contains 1 1 0..1 Sales LineItem quantity 1..* Contained-in 1 Sale dateTime / total 1 Paid-by 1 CashPayment amountTendered 1 Logscompleted 1 Recordsaccountsfor 1 Used-by 1..* itemID description price Describes
1 Uses 1
非“简单”属性
收银台 编号
选择有效的属性类型…
属性常见的简单数据类型包括：布尔、 日期、数字、字符串或文本、时间 其他如：地址、颜色、几何元素、电 话号码、身份证号、通用商品代码、邮 政编码等
保持简单的数据类型
选择有效的属性类型…
保持简单的数据类型
较差
飞机
目的地
飞机 1 Flies-to 1
Ledger
Product Catalog
*
Store Stocks 1 1
*
Item
1 1..* Contained-in 1 Sale Logscompleted
*
1..*
Houses
1..* Register
*
Captured-on 0..1 1
Paid-by 1 CashPayment
1
1
Is-for 1 Customer
关键思想
领域模型是现实世界的一个可视化抽象字典
它可视化了领域中的单词或概念类，并为这些单词
或概念类建立了关联
领域模型是没有方法的类图的集合，并且在领 域模型中不会出现软件工件 Sale
store register sale
Sale date time Print() date time
SalesDatabase
1
Makes
*
Reservation
多重性 顾客和预定建模
•规定关联的重数，每个预定是由一个顾客 进行的，这个人的姓名和电话由系统记录， 但是每个顾客可以进行多个预定
建立关联的原则
1）注意力集中在那些需要将概念之间的关 系信息记忆一段时间的关联上（“需要记 住”型关联）。 花费在领域模型创建的大部分时间
查询 储蓄卡
2、建立概念模型的基本步骤 1、发现类和对象
2、建立类之间的的方法
a、使用概念类分类列表来找出概念；
b、根据名词性短语识别出概念类；
领域模型中的概念类越多越好
从用例中识别概念
1、用例描述中出现了哪些实体？
2、用例执行过程中会产生并存储哪些信息？
主要的成功场景(续)： 5.系统显示最后的总价 6.收银员请顾客付款 7.顾客支付，系统处理支付 8.系统记录完整的销售信息，并将销售和 付款信息发送到外部的记账系统（进行 记账）和库存系统 9.系统打印收据 10.顾客带着商品和收据离开
顾客，购买的商品，POS，收银员 ，新的销售，商品标识，商品项列 表，描述，价格，累加值，总价， 支付，销售信息，付款信息，记账 系统，库存系统，收据 确定对象：顾客， 摒弃对象：商品标 商品，POS，收银 识，描述，价格， 员，新的销售，商 累计值，总价 品项列表，支付， 销售信息，付款信 息，记账系统，库 存系统，收据
SaleLineItem 0..1 Records-sale-of 1..*
Item
SaleLineItem 0..1 Records-sale-of 1..* /quantity
Item
从多重性值 导出的属性
选择有效的属性类型
属性应该是简单的数据类型。复杂的问题域 概念应该被识别为概念。
收银员 姓名 收银台 更好 收银员 姓名
复杂概念
较好
机场
定义新的数据类型
数据类型
原始数据类型：数字、字符串、布
尔、日期或时间
——把它当作属性来看待
非原始的数据类型:
——把它表示成一个单独的概念类
定义新的数据类型
ItemID
id manufactureCode countryCode
Product Specification
1
1
Product Specification Id：ItemID
根据用例模型建立领域模型
用例模型
领域模型
关闭ATM系统 管理员 启动ATM系统
查询
<<include>> <<include>> <<include>>
身份验证
存钱
用户
<<include>>
银行信息系统
取钱
转账
ATM管理员
钥匙开关
ATM机
日志
读卡器 转账 出钞口 用户
客户交互控制台 存钱 键盘 显示器 取钱 打印机 网络连接 银行信息系统
图书馆系统：不关注头发颜色、眼
睛颜色；
公安局侦察管理系统：头发颜色、
眼睛颜色、指纹等
导出属性
在属性名称前加以”/”符号 SaleLineIt em（销售 明细项） 的 quantity 信息可以 从多重性 的实际值 导出
SaleLineItem 0..1 Records-sale-of 1 Item
当你见到多对多关联，则需要考虑使用关 联类
继承
1.顾客携带购买的商品到达POS机收费口 2.收银员开始一次新的销售 3.收银员输入商品标识 4.系统记录销售的商品项列表，并显示该商品 的描述、价格和累加值。价格可以根据一套 定价规格来计算 收银员重复3-4步，直到结束 5.系统显示最后的总价 6.收银员请顾客付款 7.顾客支付，系统处理支付 8.系统记录完整的销售信息，并将销售和付款 信息发送到外部的记账系统（进行记账）和 库存系统 9.系统打印收据 10.顾客带着商品和收据离开
记录 销售
存储 商品
系统记录完整的销售信息？
并将销售和付款信息发送到外部的记账系统 （进行记账）和库存系统
Records-sale-of Product Description Contains 1 1 0..1 Sales LineItem 1 Recordsaccountsfor 1 Used-by Describes 1..*
Store
1
1
Address street1 street2 cityName
Store address:Address
避免设计潜行：任何属性都不表示外健
在领域模型里,不应该使用属性来联系概念 类.这个原则最常见的反例是添加一种外键 属性(foreign key attribute),这是关系数据库 设计中为了连接两种类型的典型做法.
在需求说明（例如用例）中提示或暗示我们要记
住的那些信息。
（3）属性的UML表示
Date
time
Sale
属性表示法
Sale
Datetime /total:Money
Sale
-DateTime:Date -/total:Money
Person
-firstName -middleName:[0..1]
1
Works-on 1 Cashier
理解型关联 1. 需要记住型关联：概念之间的 关联需要在数据库中保存一段时间 ，可以形成一个最小的信息模型；
2. 理解型关联：概念之间的关 联不是必须的，但是加上之后可以 更好的理解问题域关键概念。
3、添加类的重要属性
属性及其UML表示
（1）定义：属性是某个对象的数据值。 （2）在一个概念模型中包括如下属性：
属性还是概念？
有时很难决定是应该将一个特 殊的信息作为一个类还是作为 一个属性包含在领域模型中。
类：标识、状态和行为
2.2 建立类之间的关联 类之间有三种关系：
－关联（包括聚合和组合） －继承（一般与特殊的关系） －依赖
关联
类之间的某种语义关系。这种 语义关系体现了事物之间的联
系。进一步说，联系又可以分 为长久的、稳定的联系和短暂
领域模型
软件学院 代飞 2013〃秋
内容
1、概念模型的简介
2、建立概念模型的基本步骤
1、领域模型简介
领域模型：显示最重要的业务概念和它们 之间的关系的类图。 领域模型用：
类表示业务概念，但类通常只包含重要属性
，不包含操作
关联和泛化显示了这些概念之间的关系。
它是真实世界中各个事物的表示，而不是软 件中各构件的表示。
关联的命名
采用动词短语来为关联命名；
关联的名称应该以大写字母开头。动词 短语由几个单词组成时需用连字符“－ ”将单词连接在一起。
Paid-by PaidBy