软件工程 第9-12章：三大模型

Select(seats)
InsertCard(cardnumber, password)
SubscriptionSeries
series : int
IndividualReservation
Authorized()
0..1
3..6 Ticket no : int 1 1
0..1 Seat no : int 1 colomn : int row : int available : bool 0..* 1 Performance no : int date : Date time : Time
（5）关联关系
双向关联 单向关联 聚集关联 组成关联 标准关联，如老师类与学生类
只有一个类知道关联的存在
拥有关系，如公司与员工 整体与局部的关系，如车与轮胎
book
*
Person
Work for
1 1..*
Company
n
reference
Contract
自身关联 关联类 类的一个实例与另 一个实例相关 两个类关联产生第三个类 的实例
标准病症信号库
*
1
3. 类图的抽象层次和细化关系
类图的层次
在需求分析阶段：类图是研究领域的概念 1. 概念层 在设计阶段：类图描述类之间的接口 在实现阶段：类图描述系统中类的实现 2. 说明层
3. 实现层
功能模型和用例建模
一 用例图
用例图是用户能观察到系统功能的模型图 用于静态建模阶段——
对象图和包图
（3）行为图、活动图
assigned to
time out Available unlock
exchange
Locked
buy
Sold
（4）交互图：顺序图、协作图
（5）实现图： 配置图
信用卡代理
监督员
TicketServer
CreditCard
Charges
ManagerInterface
通过分析问题的陈述，确定以下几类实体： ⑴ 信息实体
交易记录、商品、税务信息、销售记录、存货记录
⑵ 内部设备 ：收款机、条型码扫描器。 ⑶ 交互系统 ：信用卡付款系统。 ⑷ 人员职责 ：收款员、顾客、会计、经理。 ⑸ 系统的组织实体：(不考虑)
（3） 用例识别法
如 用例的描述中出现哪些实体?
用例执行过程中产生并存储哪些信息? 与用例关联的角色向用例输入什么信息?
名词短语、名词性代词的形式出现。
名词识别步骤：
① 用指定语言对系统进行描述 ② 从系统描述中标识名词、名词短语、名词性代词 ③ 识别确定（取、舍）类
① 用指定语言对
系统进行描述 ② 从系统描述中 标识名词、名词短 语、名词性代词 ③ 识别确定类 （取、舍）
与领域专家共同合作完成 遵循问题域中的概念和命名原则
包括：可感知的事物、角色、事件、
相互作用、人员、场所、组织、设
备和地点等。
① 用指定语言对
系统进行描述 ② 从系统描述中 标识名词、名词短 语、名词性代词 ③ 识别确定（取、 舍）类
去掉冗余类
去掉不相干的类：与问题无
关或关系不大的类。
删除模糊类或独立性不强的
类：边界定义不确切，或范
围太广。
Communication with message
2. 面向对象方法的优点
与人的思维方法一致
稳定性好
可重用性好
较易开发大型软件产品 可维护性好
3. 面向对象建模
用面向对象方法开发软件，通常需要建立 三种形式的模型： （1）对象模型：描述系统的数据结构 （2）动态模型：描述系统的控制结构 （3）功能模型：描述系统的功能
限定关联 思想：降低软件复杂度
从一对多转化成一对一
从多对多转化成一对多
二 静态建模
任何建模语言都以静态建模机制为基础。
静态建模是指对象之间通过属性互相联系，而
这些关系不随时间而转移。
UML的静态建模机制包括：
用例图(Use case diagram) 类图(Class diagram) 对象图(Object diagram ) 包图(Package diagram)
4. UML（Unified Modeling Language）
是OOA＆OOD发展的产物
1995年10月：第一个公开版本UM 0.8
1996年6月：UM改名为UML（Unified
Modeling Language），发布 UML 0.9
1996年底：UML占面向对象技术市场的85％，
操作不适宜作为对象类
（2）实体识别法
系统存储、分析、处理的信息实体
系统内部设备 与系统交互的外部系统
系统相关人员
系统的组织实体
例：购物超市管理系统
顾客挑选商品后，由收款机收款，收款机
读取商品上的条型码标签，并计算商品价格。
收款机应保留所有交易的记录明细，以备帐务 复查及汇总。
TicketSeller
《datdbase》 TicketDB
1
节点多重性
*
Kiosk
1
1
*
*
*
SalesTerminal
CustomerInterface
ClerkInterface
售票员
顾客
对象模型与静态建模
现实世界
认识抽象
概念模型
信息世界
一 类图 1.实体
类名
属性 术语标准、含义确切、名词或名词短语 可见性 属性名：类型名=初值{性质串} - private # protected
中央监护系统 历库
标准病症信号库
病人病症信号
病情报告 标准病症信号 处理 组合病症信号
病历 中心值班室 分析确定类：
①去掉冗余类、② 去掉不相干的类、③ 删除模糊的类 或性质独立性不强的类、⑤ 操作不适宜作为对象类
（2）确定系统的类
值班护士 报警信号 病情报告 医生 病人 病症监视 标准病症信号库 病历库 病历 标准病症信号 中央监护系统 病人病症信号
面向对象方法学
基本原则：尽可能模拟人类习惯的思维方式，使开 发软件的方法与过程尽可能接近人类认识世界解决 问题的方法与过程。 面向对象方法以数据为主线，将数据和操作 方法封装在对象中，通过消息请求对象主动执行 它的内部操作，改变其内部私有数据。
1. 面向对象方法四个要点
OO = Objects + Class + Inheritance +
用例又向该角色输出哪些信息?
（4）分解与抽象技术
① 分解技术
整体类、组合类→单个类
② 抽象技术
建立抽象类、继承关系
2. 医院病房监护系统
（1）问题描述
为了对危重病人进行实时监护，随时了解病人病情，及 时进行处理，建立病房监护系统。 病症监视器安置在每个病床，通过网络将病人的病症信 号（组合）实时传送到中央监护系统进行分析处理。 在中心值班室里，值班护士使用中央监护系统对病员的 情况进行监控，监护系统实时地将病人的病症信号与标准的
监视周边 批准预算
经理
管理人事
批准安全 证书
保安
如果要求安全主管可以担任
经理和保安的角色，这样，安
经理
管理人事
全主管与经理，安全主管与保
安之间存在泛化关系，安全主
批准预算
管就可以参与全部4个用例。
但经理或者保安却不能担任
安全主管
批准安全 证书
安全主管的角色，也就不能参
与用例批准安全证书。
保安
监视周边
业务建模、需求建模
1.组件
组件 描 述 UML 表示
① 一个角色或一个系统
（ 1）
参与者
(Actor)
② 角色不是具体的人 ③ 特征：在系统外部与系统发生交
Actor
互作用
组件 ① 黑盒子 （ 2） 系统
描
述
UML 表示
② 系统边界 一个软件系统、一项业务、 一个商务活动、一台机器等。
系统
（ 3） 用例 系统外部可见的功能单元 (Use Case)
病情报告 标题 格式 生成病情报告（） 查看病情报告（）
病历 格式 病人基本情况 打印时间 生成病历（） 查看病历（）
打印病情报告（）
打印病历（）
值班护士
1 1
1
医生
1
病人
*
病历 监视
1
报警
*
*
病情报告
*
1
1
病历库
1 1 1
病症监视
1 1
1
*
1
1
1
报警信号
Leabharlann Baidu
中央监护系统
1
*
病人病症信号
1
标准病症信号
标准病症信号库 类型
病历库 类型 大小
灯光
文字
大小
容量 提供标准信号（）
容量
生成病历（） 更新病历（） 查看病历（） 打印病历（） 标准病症信号 脉搏 血压 体温 生成标准信号（）
分解信号（） 比较信号（） 报警（） 数据格式化（） 病人病症信号 脉搏 血压 体温 生成病症信号（）
报警（）
数模转化（）
元素，具有偶然性。
渡河者
船
（3）聚合、组合
聚合 组合 都表示整体与部分的关系 聚合：对象是可以分离的，有各自的
生命周期
组合：为一种唇齿相依的关系。
机场
飞机
公司 员工
桌子
桌子腿
组合和聚合示例
（4）泛化、细化
泛化（继承） 细化（实现）
泛化与细化：都表示一般与特 殊的关系，即“一般”元素是 “特殊”关系的泛化。
（3）用例间关系——包含
基用例
《include》
包含用例
包含用例是必不可少 的，缺少包含用例，基用例
就不完整；
包含用例是必须执行的；
包含用例执行不会改变基用例的行为。
用例间关系——扩展
基用例
《extend》 扩展用例
扩展用例是可有可无的，缺少扩展用例，不影响
基用例的完整性；
扩展用例在一定条件下才会执行；
构件图(Component diagram)
配置图(Deployment diagram)
1. 类的识别
类识别是面向对象方法的难点，又是建模的关键。 常用的方法有：
① 名词识别法
关键是要定义类的 “属性”及“操作”
② 实体识别法
③ 用例识别法
④ 分解与抽象技术
（1） 名词识别法
识别问题域中的实体，实体的描述通常用名词、
扩展用例执行会改变基用例的行为。
用例间关系——使用
基用例
《use》 使用用例
表示一个用例使用另一个用例
实例2
用例之间扩展和包含关系
短途旅行中，司机要为汽车加油和吃饭。
旅行
司机 《include》 《extend》
为汽车加油
吃饭
总结：
包含
必不可少 的
扩展
可有可无的
病诊信号进行比较分析，当病症出现异常时，系统会立即自
动报警，并打印病情报告和更新病历。
监视病情
产生 病情报告
经过初步的需求分析，得到系统功能要求： 请对系统需求进行分析！ ①监视病员的病症（血压、体温、脉搏等） ②定时更新病历 ③病员出现异常情况时报警。 ④随机地产生某一病员的病情报告。
更新病历
确定初始类: 监视器 网络 值班护士 报警信号 医生 病人 病症监视 病
成为可视化建模语言的工业标准
现版本：UML2.0
UML的内容由五类图（9种图形）来定义：
（1）用例图：从用户角度描述系统功能
Box Office Buy tickets
<<include>> Buy Subscription 职员 信息亭 <<include>>
Make charges
信用卡服务商
Survey sales
监督员
（2）静态图：类图、对象图和包图
Customer name : string phone : string 1 1 1..* Reservation date : Date BoxOffice Request(count, performance) kjosk CreditCardService ShowAvailability(seatlist) DemandPayment(cost) PrintTickets(performance, seats) EjectCard() Charge(cardnumber, cost)
值班护士 用户名 密码 用户名 密码
医生
病人 姓名 性别 年龄 病症 提供病症信号（）
病症监视 采集频率
病症信号
查看病情报告（）
打印病情报告（）
查看病情报告（） 要求打印病情报告（） 查看病历（） 要求打印病历（）
格式化信号数据（） 采集信号（） 信号组合（）
中央监护系统 输入 输出
报警信号 声音
Use Case
2.关系
关 系 （1）参与 者与用例间 参与者与用例之间的交互 关系：关联 解 释 图
（2）参与
者间关系： 箭头由特殊指向一般
泛化
实例：参与者之间的泛化关系
参与者：经理，安全主管，保安 用例：管理人事，批准预算，批准安 全证书，监视周边 参与者参与 用例的情况分别是： 安全主管 经理参与用例管理人事和批准预算； 安全主管参与用例批准安全证书；保 安参与用例监视周边。
操作
可见性
+ public
操作名（参数表）：返回值类型{性质串}
类 属性
操作
对象名:类名 属性 操作
2.类图中的关系
（1）关联：某种语义上的联系
学生 计算机
*
使用
被使用
1..*
0..3 0..*、* 1+、1..* multiplicity 5
重数
（2）依赖
依赖 一个元素以某种方式依赖于另一种