第6章 用例描述和图
UML可视化建模（航空订票系统）
UML可视化建模（航空订票系统）《可视化建模与UML》课程结业报告课题名称: 航空客运订票系统建模姓名: ***学号: *******班级:指导⽼师: 夏⽼师完成⽇期: 2013.06.16⽬录第⼀章概述 (3)1.1系统开发的摸底和开发背景 (3)1.2系统功能 (3)1.3系统结构框架 (4)1.4开发环境 (5)第⼆章⽤例模型 (6)2.1⽤例模型简介 (6)2.2⽤例图的的含义及其作⽤ (6)2.3⽤例图及⽤例描述 (7)第三章类模型 (10)3.1类模型简介 (10)3.2类图的作⽤ (10)3.3类图 (11)第四章交互模型 (13)4.1交互模型简介 (13)4.2序列图简介 (13)4.3序列图的作⽤ (13)4.4序列图描述及其序列图 (14)第五章⾏为模型 (20)5.1⾏为模型简介 (20)5.1.1活动图简介 (20)5.1.2活动图的作⽤ (20)5.1.3状态图简介 (21)5.1.4状态图的作⽤ (21)5.2⾏为模型图 (21)5.2.1活动图及其描述 (21)5.2.2状态图及其描述 (23)第六章构件图和部署图 (25)6.1构件图简介 (25)6.2部署图简介 (25)第七章课程学习⼩结 (27)7.1课程⼩结 (27)7.2学习⼼得 (27)参考⽂献 (28)第⼀章概述1.1系统开发的摸底和开发背景随着科技与经济的发展，越来越多的⼈选择乘飞机，这跟我国的经济增长有很⼤关系，⼈们在追求快节奏的⽣活⽅式，所以做飞机⽆疑成了⾸选。
⽽且随着⽹络的盛⾏，航空订票系统就显得尤为重要，我们开发这个系统主要是为了⽅便⼤家，让⼤家能够快速、清晰、准确地了解航班信息，⽽不⾄于像以前那样排队等候，从⽽避免耽搁乘客⼤量的等待时间。
航空客运业务诞⽣已有进⼀个世纪了，作为现有交通⼯具中最⽅便快捷的⼀种，它确实地给⼤家的⽣活、出⾏带来了极⼤的⽅便。
随着航空客运业务多年来的发展，其售票业务也同样不断地发展。
第6章 详细设计
使用PAD图提供的定义功能来逐步求精的例子
(a) 初始的PAD图；(b) 使用def符号细化处理框P2
软件工程 Software Engineering ——第六章 详细设计 武警警官学院 电子技术系
软件工程 Software Engineering ——第六章 详细设计 武警警官学院 电子技术系
软件工程 Software Engineering ——第六章 详细设计
武警警官学院
电子技术系
软件工程 Software Engineering ——第六章 详细设计
武警警官学院
电子技术系
结构程序设计的经典定义如下所述：“如果一 个程序的代码块仅仅通过顺序、选择和循环这3种基 本控制结构进行连接，并且每个代码块只有一个入 口和一个出口，则称这个程序是结构化的。”
武警警官学院
电子技术系
6.1
结构程序设计
1965年 -- E.W.Dijkstra提出 “可以从高级语言中取消GO TO语句” ，“程序的质量与程序中所包含的GO TO 语句的数量成反比”。
1966年 -- Bohm和Jacopini证明了：只用3种基本的控制结构（顺序、 选择、循环）就能实现任何单入口单出口的程序。该证明为结构程 序设计技术奠定了理论基础。 1971年 -- IBM公司在纽约时报信息库管理系统的设计中，在美国宇 航局空间实验室飞行模拟系统的设计中，结构程序设计技术获得圆 满成功。前者包含83 000行高级语言源程序，后者包含40万行源程 序，而且在设计过程中用户需求又曾有过很多改变。 1972年 -- IBM公司的Mills进一步提出，程序应该只有一个入口和一 个出口，从而补充了结构程序设计的规则。
第03章 用例和用例图
5
用例的特点 ① 用例用于描述系统的功能，这个功能是外 部使用者看到的系统功能，不反映功能的实现 方式。
储蓄系统
开户 存款
√
√ √ √
取款
转帐
6
用例的特点
② 用例描述用户提出的一些可见需求，对应 一个具体的用户目标。
储蓄系统 √ √ √ 开户 存款 取款 转帐
√
×
数据上传
7
用例的特点 ③ 用例反映系统与用户的一次交互过程，应 该具有交互的信息的传递。
泛化关系代表一般与特殊的关系, 与继承类似.
在泛化关系中, 子用例继承了父用例的行为和含义, 子用例也可以增加新的行为和含义或覆盖父用例中 的行为和含义.
20
3.4.2 泛化关系
21
3.4.3 包含关系
包含关系是指一个用例(基本用例)的行为包含了另一 个用例(包含用例)的行为.
包含关系是依赖关系的版型, 但其含义更多.
3.6 用例的描述
用例阐述：写用例规约
用例规约：更进一步的精度
用例文档的核心，作为用例文档的总图 进一步的精度：有层次的文档 文档中每一句话都有其价值
用例图是骨架，而用例规约则是其内在的血肉
43
3.6 用例的描述
谁来写用例文档 ?
最完美：业务人员接受训练，写出优美的 用例文档 最现实：业务人员提供素材，开发人员写 用例文档 最糟糕：业务人员不管，完全由开发人员 杜撰
3
3.7 寻找用例的方法
3.8 用例的常见问题
15
3.3 脚本
脚本(scenario)在UML中指贯穿用例的一条单一路径, 用来显示用例中的某种特殊情况. 其它译名: 情景、场景、情节、剧本.
自动售货机系统用例图
谁负责维护、管理并保持系统正常运行（副行为者）？
系统控制哪些硬件设备？系统需要与哪些其他系统交互？ 哪些人或系统对本系统产生的结果（值）感兴趣？
2. 寻找用例
2. 寻找用例 一旦找到了行为者，就可以通过请每个行为者回
答下述问题来获取用例：
•行为者需要系统提供哪些功能？ •行为者自身需要做什么？ •行为者是否需要读取、创建、删除、修改或存储系 统中的某类信息？ •系统中发生的事件需要通知行为者吗？行为者需要 通知系统某些事情吗？从功能观点看，这些事件能做 什么？ • 行为者的日常工作是否因为系统的新功能而被简化 或提高了效率？
填空题答案
1. 功能分解 2. 表达 描述 3. 数据值 4. 行为 数据 操作 9. 对象 类 可能的链 实例 抽象 二元关联 三元关联 10. 整体-部分 整体类 部分类 11. 一般-具体 一般化类 具体类 继承 12. 子类继承了一个父类的性质 树型层次结构 子类继承了多个父
类的性质 网状层次结构
其中，对象模型是最基本、最核心、最重要的。
本章所讲述的面向对象方法及定义的概念和表示 符号，可以适用于整个软件开发过程。软件开发人 员无须像用结构分析、设计技术那样，在开发过程 的不同阶段转换概念和表示符号。
用面向对象方法开发软件时，阶段的划分是十分 模糊的，通常在分析、设计和实现等阶段间多次迭 代。喷泉模型是典型的面向对象软件过程模型。
33. 具有相同或相似性质的对象的______就是类。类的____就是对 象，也可以说类的______是对象。
34. 类具有属性，它是__的抽象，用___来描述类的属性。
35. 类具有操作，它是____的抽象，用____和____实现来描述。
第6章(2)PIM建模技术资料
Warm up: Use Case & Use Case
Realization
• Use Case是描述需求的工具，把系统看做黑盒子。 • Use Case Realization在分析设计阶段做，不在视系统
为黑盒子，而是白盒子。
– 用分析和设计出来的类及它们之间的Collaboration来描述系统 如何完成Use Case。
– 指南：推荐的做法，在其解释、实施或使用中，允许有一定 的自由度或回旋余地。
• 10.把用例规约中的路径直接粘贴在鲁棒图的左边，以 便一一对应，逐项对象化；
• 9.直接利用域模型中的业务对象实体；
– 也用鲁棒图补充和完善域模型
• 8.在画鲁棒图时，要完善用例规约(去掉歧义)
– 画鲁棒图迫使作者逐句斟酌用例规约
• 鲁棒图示例 • 初步设计审核
– 目的与参与者 – 初步设计审核指导原则、指南和常犯的错误
• 软件体系结构及其模式*
– 体系结构风格、设计原则与常见错误 – 鲁棒图与MVC模式 – 新课程：软件体系结构
Warm up:Analysis and Design
• Design
– Realization of a concept or idea into a model or specification
• 分析模型和设计模型最早在Jacobson的OOSE中提出 来了，并非RUP首创。这两个模型的本质差别在于：
– 分析模型是对问题域的描述，独立于实现技术。 – 设计模型在使用具体技术实现分析模型。设计模型可以立即
拿去实施。 – 区分两种模型的目的：当实现技术改变时，重用分析模型。
• 基础：问题域不会如计算机技术发展得那么快。
第6章需求分析与建模
第6章需求分析与建模需求分析与建模是软件开发过程中的重要环节，它是基于用户需求，对系统功能和性能进行细致的分析和建模，以便于后续的系统设计与实现。
本章主要介绍需求分析与建模的概念、方法和工具，以及需求分析与建模的步骤和技巧。
需求分析是软件开发过程中的首要任务，它旨在明确系统的功能需求、性能需求和非功能需求，以及用户对系统的期望和要求。
需求分析包括需求获取、需求分析、需求规格和需求验证等环节。
需求获取是在与用户和其他相关人员的沟通和交流中，获取系统需求的过程。
需求获取的方法有面谈、问卷调查、文档分析、原型演示等。
面谈是需求获取的主要方法，它可以直接与用户进行交流，了解用户的需求和期望。
问卷调查可以广泛收集用户的意见和建议，但需要注意问卷设计和样本选择的合理性。
文档分析是从已有的文档中提取需求信息，如用户手册、竞争产品分析、市场调研报告等。
原型演示可以通过模拟系统的界面和功能，来引导用户提供需求，从而达到需求获取的目的。
需求规格是将需求描述、需求功能和需求级别等信息进行形式化和详细化的过程。
需求规格可以采用自然语言、用例图、数据流图、状态转换图等形式进行描述。
自然语言是最常用的需求规格方法，通过文字和语言描述需求的功能和性能。
用例图是一种图形化的需求规格方法，它可以清晰地描述系统的功能和用户之间的交互。
数据流图是一种描述系统输入、处理和输出的方法，它能够明确系统的数据流和数据处理过程。
状态转换图是一种描述系统状态和状态转换的方法，它能够清晰地描述系统的状态变化和状态转移。
需求验证是对需求的正确性和可行性进行验证的过程。
需求验证的方法有面谈、演示、原型测试和用例测试等。
面谈是需求验证的主要方法，通过与用户的交流和沟通，来验证需求的准确性和合理性。
演示可以通过模拟系统的功能和性能，来验证需求的可行性和有效性。
原型测试是通过制作系统的原型，来进行需求验证和改进的过程。
用例测试是通过编写测试用例和执行测试脚本，来对系统需求进行详细测试和验证。
系统分析与设计——统一建模语言UML
北京理工珠海学院
6.1.2统一建模语言特点
（1）面向对象:支持面向对象技术的主要概念,提供 了一批基本的模型元素表示图形和方法,简明表 达面向对象的各种概念. （2）可视化:通过UML的模型图清晰表示系统的逻辑 模型和实现模型,还用于各种复杂系统的建模. （3）独立于过程:独立于开发过程. （4）独立于程序设计语言:建好的系统模型可用任何 面向对象的语言来实现. （5）易于掌握和使用:结构清晰,建模简明易于掌握
五类图
第一类是用例图，从用户角度描述系统功能，并指出各功能的操作者 .
第二类是静态图 ，包括类图、对象图和包图 .
第三类是行为图,描述系统的动态模型和组成对象间的交互关系。行为图 包括：状态图、活动图、顺序图和协作图 第四类是交互图,描述对象间的交互关系。(顺序图显示对象之间的动态 合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互 ；合作图描述对象间的协作关系，显示对象间的动态合作关系和对象以 及它们之间的关系)。如果强调(时间和顺序，则使用顺序图)；如果强 调(上下级关系，则选择合作图)。这两种图合称为交互图. 第五类是实现图 ,其中构件图描述代码部件的物理结构及各部件之间的 依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个 可执行部件。它包含逻辑类或实现类的有关信息。构件图有助于分析和 理解部件之间的相互影响程度。
《include》 打印查询结果
(From Use Case View)
(From Use Case View)
北京理工珠海学院
案例：泛化、扩展关系
下面左图给出了一个扩展关系的例子，在还书的过程中， 只有在例外条件（读者遗失书籍）的情况下，才会执行赔 偿遗失书籍的分支流。 泛化关系：用例可以被特别列举为一个或多个子用例，这 被称做用例泛化。当父用例能够被使用时，任何子用例也 可以被使用。如在右图中，订票是电话订票和网上订票的 抽象。
统计学原理06-第6章时间数列分析(新)
点或连续时期上测量的观测值的集合。 点或连续时期上测量的观测值的集合。
年份 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 国内生产总值 亿元） （亿元） 4038.2 4517.8 4862.4 5294.7 5934.5 7171.0 8964.4 10202.2 11962.5 14928.3 年份 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 国内生产总值 亿元） （亿元） 16909.2 18547.9 21617.8 26638.1 34634.4 46759.4 58478.1 67884.6 74462.6 79395.7
平均发展水平 时期 数列 序 时 总量指标 平 均 方 法 连续 时点 间断 时点 简单算术平均 间隔相等 简单算术平均 间隔不等 加权算术平均 间隔相等 两次简单平均 间隔不等 先简单后加权
时点 数列
相对指标、 视情况选用：先平均再相除、 相对指标、 视情况选用：先平均再相除、先加总再 平均指标 相除、加权算术平均、加权调和平均等 相除、加权算术平均、
趋势性数列
指数（ 指数 （ % ）
平稳性数列
79
80
81
82
83
85
84
86
87
88
89
90
91
92
93
95
94
96
97
19
19
19
19
19
19
19
19
19
19
19
19
19
19
19
19
19
19
19
电子商务系统的分析与设计-第6章_教材
数据库表设计方法（案例）
分析业务流程中所涉及的信息
案例中包括客户信息、客户服务信息、销售信息等
针对信息分类确定待设计的数据库表
三、商务应用软件设计
商务应用软件的层次结构设计 子系统划分及模块设计 应用软件详细设计
商务应用软件的层次结构设计
层次性是现代所有计算机软硬件系统均具有 的特征 层次化的目的
简化问题 分头求解 重用组件
电子商务系统基本的层次划分方法
应用表示层 业务逻辑层 数据层 电子商务 应用软件 逻辑
此报修问题处理人编号 int
4
4 300 8
PlanStartTime
RealStartTime FinishTime Suggestions
计划开始维修时间
实际开始维修时间 维修完成时间 用户意见建议
DateTime
DateTime DateTime varchar
8
8 8 300
联机事务处理基本概念
确定维修基本信息表（RepairBaseInfo） 考虑数据库设计基本原则，确定采用单独的表（ClientInfo） 存储客户信息 确定表的关键字及关联方式
ClientInfo
ID Name Address Phone
RepairBaseInfo
ClientID „„
继续设计数据库表
考虑到维修时需掌握其当初销售的相关信息，因此， 如果在其它模块设计中尚未建立订单基本信息表 （OrderInfo），则增加之
面向对象分析与设计课件第6章 顺序图与通信图建模
Ad d (Ch ro m o so m e )
loop [nt So rtByAcco m m o d a ti o n () Cro ssOve r(Ch ro m o so m e )
m u ta ti o n ()
CanbeEnded(int): Boolean
图6-1 顺序图中常见的对象
6.1.2 生命线（lifeline）
生命线是从对象图标向下出来的延伸的一条直线，也是和对象紧密联系在 一起的一种模型元素，用于表示对象的生存期或生存期内的某个时间片段。
事实上，在顺序图中，对象和生命线是不可分割的同一个元素，生命线是 对象的一个组成部分，代表了对象的整个或部分生命期。顺序图中即不存在 没有生命线的对象，也不存在没有对象的生命线。当然这并不排除生命线分 支的概念。
除了图形符号，UML还使用消息表达式的方式来描述消息。 按照对象间交互的形式，可以把消息分成方法调用、发送信号、创建实例 和销毁对象等多种形式。其中，最常用的形式就是对象间的方法调用。
6.1.4 消息（Message）
描述方法调用或发送信号的消息的语法格式定义如下： [returnvalue=] message_name (arguments) : type_of_return_value return_value：是消息的可选部分，表示存储消息返回值的变量。这个变 量可以是发送者的一个属性、整个交互的全局属性、或者是某个拥有交互的 类的属性。 message_name：表示消息名称，可以是接收者的某个方法名或发送的信号 名等。 arguments：表示消息参数列表，是一个用逗号分隔的若干个参数构成的 列表，其中每个参数都可以是参数名或参数值。 type_of_return_value:返回值类型。