UML系统建模与分析设计PPT课件
合集下载
课件—UML系统建模与分析设计(8)(1)
2014-12-25
UML系统建模与分析设计
4
8.2.2 结构型设计模式 结构型模式描述类和对象之间通过组织形成新 的结构，以实现新的功能。 结构型的类模式采用继承机制来组合类，如适 配器（Adapter）类模式； 结构型的对象模式则描述了对象的组装方式， 如适配器（Adapter）对象模式、桥接（Bridge） 模式、组合（Composite）模式、装饰（Decorator） 模式、外观（Facade）模式、享元（Flyweight） 模式、代理（Proxy）模式等。
2014-12-25 UML系统建模与分析设计 7
简单工厂模式的优缺点： （1）简单。 （2）增加新的产品时，要修改工厂类，违反了面 向对象设计的基本原则。 （3）工厂类一旦不能正常工作，整个程序都会受 到影响。 （4）静态结构无法形成基于继承的层次结构。
2014-12-25 UML系统建模与分析设计 8
2．工厂方法（Factory Method）模式 又称为多态性工厂模式。
参与的角色有： （1）抽象工厂接口（Creator）：创建对象的工 2014-12-25 厂类必须实施这个接口的实现。 9 UML系统建模与分析设计
（2）具体工厂类（Concrete Creator）：用于 创建产品实例的那样一些类。 （3）产品（Product）：是工厂方法模式所创 建的对象的父类，或它们共同拥有的接口。 （4）具体产品（Concrete Product）：是工厂 方法模式所创建的任何对象所属的类。
第八章
本章目的：
设计模式及其应用
了解设计模式的概念 掌握设计模式的三大分类 掌握常用的11种常的设计模式（其中简单
工厂是工厂方法的最初表现形式） 了解各设计模式的优点、不足 掌握设计模式的使用原则及策略
课件—UML系统建模与分析设计(5)
第五章
系统设计与对象动态交互模型
动态模型主要描述系统的动态行为和控制结构。动态行 为包括系统中对象生存期内可能的状态以及事件发生时状态 的转移，对象之间动态合作关系，显示对象之间的交互过程 以及交互顺序，同时描述了为满足用例要求所进行的活动以 及活动间的约束关系。 在动态模型中,对象间的交互是通过对象间消息的传递来 完成的。对象通过相互间的通信(消息传递)进行合作,并在其 生命周期中根据通信的结果不断改变自身的状态。
16
5.2.1 一个简单的顺序图例子
17
顺序图有两个坐标： 垂直坐标--时间（从上到下），水平坐标—对象。
对象
生存线
时间
18
激活期
消息
顺序图和用例图、类图的关系
19
5.2.2顺序图的主要元素：
（1）对象：顺序图中所包含的每个对象用一个 对象框（短式）表示，对象名需带下划线。
对象图
（2）生存线：对象框下画的一条垂直虚线，称 为该对象的生存线，表示对象的生存时间。 （3）激活期：对象生存线上的一个细长方形框， 表示该对象的激活时间段，即活动期间。一 个激活的对象要么正在执行自己的代码，要 么等待另一个对象的返回。 （4）消息：对象之间消息的发送和接收用两个 对象生存线（激活期）之间的消息箭头线。
28
5.3
对象之间的同步与异步操作
1．对象之间的同步操作
同步消息的发送者把进程控制传递给消息 的接收者，然后暂停活动，等待消息的接收者 放弃或返回控制； 同步消息的接收者执行所请求的操作，如 果需要的话，可以把控制传递给另一个对象角 色，请求做某个操作，并且当该操作完成后把 控制返回给原来的同步消息的发送者； 同步消息的接收者也可以直接返回或发送 信息给原来的消息发送者。
系统设计与对象动态交互模型
动态模型主要描述系统的动态行为和控制结构。动态行 为包括系统中对象生存期内可能的状态以及事件发生时状态 的转移，对象之间动态合作关系，显示对象之间的交互过程 以及交互顺序，同时描述了为满足用例要求所进行的活动以 及活动间的约束关系。 在动态模型中,对象间的交互是通过对象间消息的传递来 完成的。对象通过相互间的通信(消息传递)进行合作,并在其 生命周期中根据通信的结果不断改变自身的状态。
16
5.2.1 一个简单的顺序图例子
17
顺序图有两个坐标： 垂直坐标--时间（从上到下），水平坐标—对象。
对象
生存线
时间
18
激活期
消息
顺序图和用例图、类图的关系
19
5.2.2顺序图的主要元素：
（1）对象：顺序图中所包含的每个对象用一个 对象框（短式）表示，对象名需带下划线。
对象图
（2）生存线：对象框下画的一条垂直虚线，称 为该对象的生存线，表示对象的生存时间。 （3）激活期：对象生存线上的一个细长方形框， 表示该对象的激活时间段，即活动期间。一 个激活的对象要么正在执行自己的代码，要 么等待另一个对象的返回。 （4）消息：对象之间消息的发送和接收用两个 对象生存线（激活期）之间的消息箭头线。
28
5.3
对象之间的同步与异步操作
1．对象之间的同步操作
同步消息的发送者把进程控制传递给消息 的接收者，然后暂停活动，等待消息的接收者 放弃或返回控制； 同步消息的接收者执行所请求的操作，如 果需要的话，可以把控制传递给另一个对象角 色，请求做某个操作，并且当该操作完成后把 控制返回给原来的同步消息的发送者； 同步消息的接收者也可以直接返回或发送 信息给原来的消息发送者。
UML系统建模与分析设计
2．定义系统的边界:一个系统的所有元素与系统以外的事物的 分界线。
2019/11/30
软件工程方法
8
1.4 确定执行者（参与者，角色） aActor
执行者（actor）是指在系统外部与系统交互的人或其他系统，它以某 种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图 符来表示。
执行者类型：参与者不仅可以由人承担，还可以是其它系统、硬件设备、 甚至是时钟 ： 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中， 银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系 统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者
角色与用例的关联表示角色 与用例相关性。在UML中是 使用一条实线连接角色与用 例
7
1.3 定义系统的边界和范围
系统：特指基于计算机的用于解决某个特定问题域的软硬件系 统。它代表的是一个活动范围。 定义系统：要定义系统的范围和边界
1．定义系统的范围 :系统问题域的目标、任务、规模即系统 提供的功能和任务。
2019/11/30
软件工程方法
10
ATM系统的Actor
1、谁使用ATM系统的主要功能（提款）？ 答：储户
2、谁使用ATM系统的支持以完成日常工作任务？ 答：出纳员？还不肯定，先放在这里
3、谁来维护、管理并保持系统正常运行？ 答： ATM系统工程师，银行人员
2019/11/30
软件工程方法
11
4、该系统需要和哪些系统交互？ 答：目前还不清楚
5、ATM系统需要处理哪些设备？ 答：信用卡 6、谁对ATM系统运行的结果感兴趣？ 答：银行会计、储户
2019/11/30
2019/11/30
软件工程方法
8
1.4 确定执行者（参与者，角色） aActor
执行者（actor）是指在系统外部与系统交互的人或其他系统，它以某 种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图 符来表示。
执行者类型：参与者不仅可以由人承担，还可以是其它系统、硬件设备、 甚至是时钟 ： 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中， 银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系 统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者
角色与用例的关联表示角色 与用例相关性。在UML中是 使用一条实线连接角色与用 例
7
1.3 定义系统的边界和范围
系统：特指基于计算机的用于解决某个特定问题域的软硬件系 统。它代表的是一个活动范围。 定义系统：要定义系统的范围和边界
1．定义系统的范围 :系统问题域的目标、任务、规模即系统 提供的功能和任务。
2019/11/30
软件工程方法
10
ATM系统的Actor
1、谁使用ATM系统的主要功能（提款）？ 答：储户
2、谁使用ATM系统的支持以完成日常工作任务？ 答：出纳员？还不肯定，先放在这里
3、谁来维护、管理并保持系统正常运行？ 答： ATM系统工程师，银行人员
2019/11/30
软件工程方法
11
4、该系统需要和哪些系统交互？ 答：目前还不清楚
5、ATM系统需要处理哪些设备？ 答：信用卡 6、谁对ATM系统运行的结果感兴趣？ 答：银行会计、储户
2019/11/30
UML系统建模与分析设计.ppt
统、角色和用例
等三种模型元素，
以及它们之间的
关系。
贸易经理
营销人员
设置边界
更新帐目
风险分析 交易估价
《使用》 《使用》
评价
进行交易
《扩展》
超越边界
记账系统 销售人员
2020/10/16
软件工程方法
4
用例模型描述的是外部执行者(Actor)所理解的系 统功能。它描述了待开发系统的功能需求。
它驱动了需求分析之后各阶段的开发工作,不仅在 开发过程中保证了系统所有功能的实现,而且被用 于验证和检测所开发的系统,从而影响到开发工作 的各个阶段和 UML 的各个模型。
2．定义系统的边界:一个系统的所有元素与系统以外的事物的 分界线。
2020/10/16
软件工程方法
8
1.4 确定执行者（参与者，角色） aActor
执行者（actor）是指在系统外部与系统交互的人或其他系统，它以某 种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图 符来表示。
执行者类型：参与者不仅可以由人承担，还可以是其它系统、硬件设备、 甚至是时钟 ： 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中， 银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系 统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者
•将需求规约变为可视化模型，并得到用户确认；
•给出清晰、一致的关于系统做什么的描述，确定系统的功能要 求；
•提供从功能需求到系统分析、设计、实现各阶段的度量标准；
•为最终系统测试提供基准，据此验证系统是否达到功能要求；
•为项目目标进度管理和风险管理提供依据。
课件—UML系统建模与分析设计(7)PPT课件
（1）一个结构良好的构件图应具备的特点
✓ 侧重描述系统静态视图的某一侧面； ✓ 只包含那些对描述该侧面内容有关的模型元素； ✓ 提供与抽象层次一致的描述，只显示有助于理解该构
件图的必要的修饰； ✓ 图形不要过于简化，以防产生误解。
（2）绘制一个构件图时应注意的问题
➢ 为构件图标识一个能准确表达其意义的名字； ➢ 摆好各个构件的位置，尽量避免连接线的交叉； ➢ 语义相近的模型元素尽量靠近； ➢ 用注解和颜色提示重点部位； ➢ 谨慎采用自定义构造型元素； ➢ 采用尽量少的图符标记描述构件图，保持所有构件
4．构件的组织形式
（1）用包来组织构件。 （2）用构件之间的交互关系来组织构件。
2021/3/6
UML系统建模与分析设计
9
7.2.2 构件的分类
（1）源代码构件 （2）二进制构件 （3）可执行构件
7.2.3 构件的接口
接口描述一个构件能提供服务的操作， 是一个有操作而无实现的类。
2021/3/6
UML系统建模与分析设计
（ 2
1 ）
➢都可以实现一组接口；
） 构
➢抽象的方式不同；
构
件
件 ➢都可以参与依赖、继承、 与 ➢抽象的级别不同；
与
类
类 关联等关系和交互； 的
的 显
➢访问方式不同；
相 同
➢都可以被嵌套；
著 不 ➢与包的关系。
点
同
➢都可以有实例。
点
2021/3/6
UML系统建模与分析设计
8
3．软件构件的特点
（1）接口。 （2）操作。 （3）实例化。 （4）与配置环境的亲合性。 （5）能与同环境下其它构件进行交互。 （6）构件可以是可执行代码、二进制代码和源代码形式。 （7）可替换的物理实体。 （8）系统的组成部分。 （9）构件是软件复用的基本单元。
✓ 侧重描述系统静态视图的某一侧面； ✓ 只包含那些对描述该侧面内容有关的模型元素； ✓ 提供与抽象层次一致的描述，只显示有助于理解该构
件图的必要的修饰； ✓ 图形不要过于简化，以防产生误解。
（2）绘制一个构件图时应注意的问题
➢ 为构件图标识一个能准确表达其意义的名字； ➢ 摆好各个构件的位置，尽量避免连接线的交叉； ➢ 语义相近的模型元素尽量靠近； ➢ 用注解和颜色提示重点部位； ➢ 谨慎采用自定义构造型元素； ➢ 采用尽量少的图符标记描述构件图，保持所有构件
4．构件的组织形式
（1）用包来组织构件。 （2）用构件之间的交互关系来组织构件。
2021/3/6
UML系统建模与分析设计
9
7.2.2 构件的分类
（1）源代码构件 （2）二进制构件 （3）可执行构件
7.2.3 构件的接口
接口描述一个构件能提供服务的操作， 是一个有操作而无实现的类。
2021/3/6
UML系统建模与分析设计
（ 2
1 ）
➢都可以实现一组接口；
） 构
➢抽象的方式不同；
构
件
件 ➢都可以参与依赖、继承、 与 ➢抽象的级别不同；
与
类
类 关联等关系和交互； 的
的 显
➢访问方式不同；
相 同
➢都可以被嵌套；
著 不 ➢与包的关系。
点
同
➢都可以有实例。
点
2021/3/6
UML系统建模与分析设计
8
3．软件构件的特点
（1）接口。 （2）操作。 （3）实例化。 （4）与配置环境的亲合性。 （5）能与同环境下其它构件进行交互。 （6）构件可以是可执行代码、二进制代码和源代码形式。 （7）可替换的物理实体。 （8）系统的组成部分。 （9）构件是软件复用的基本单元。
—UML系统建模与分析设计幻灯片
2021/5/15
UML系统建模与分析设计
19பைடு நூலகம்
２．软件开发 〔1〕概要设计 建立系统总体构造和各模块之间的关系； 定义各个功能摸块的接口； 设计全局数据库或数据构造； 规定设计约束； 制定组装测试方案。 〔2〕详细设计 对概要设计进展细化； 建立文档资料。
2021/5/15
UML系统建模与分析设计
； 必须是首次开发的新系统并且淘汰全部老系统时。
2. 渐增模型〔incremental model〕
2021/5/15
UML系统建模与分析设计
10
慎重考虑使用渐增模型的情况： 不能充分理解客户需求或客户需求有可能迅速发生
变化； 事先拟采用的技术迅速发生变化； 客户突然提出一些新的功能需求； 长时期内仅有有限的资源保证〔开发人员和资金〕
〔5〕按使用的频度划分 一次性使用软件。 使用频度较高的软件。
〔6〕按软件失效的影响程度划分 一般性软件。 关键性软件。
2021/5/15
UML系统建模与分析设计
6
1.2 软件的开展与软件工程
软件工程的指导性原那么： 变动的软件需求。 稳妥的设计方法。 高效的软件开发支持技术。 有效的过程管理。
软件工程具有里程碑意义的进展：
4
2．软件的分类
〔1〕按软件的功能划分
系统软件。
支撑软件。
应用软件。
〔2〕按软件的规模划分
微型软件。
小型软件。
中型软件。
大型甚至超大型软件。
〔3〕按软件工作方式划分
实时处理软件。
分时软件。
交互式软件。
批处理软件。
2021/5/15
UML系统建模与分析设计
5
〔4〕按软件效劳对象的范围划分 工程软件。 产品软件。
UML系统建模与分析设计-需求分析与用例建模PPT课件
异常事件流处理：
（1）标识码有效性检查失败，允许学生重新输入（3次机会）。 （2）注册识别失败，没有注册（尙未交学费）的学生不能选课。 （3）选择课程确认失败，所选几门课程中在上课时间上发生冲
突时，系统提示重选。
2021/1/16
-
15
3.2.6 用例之间的关联
1．继承关联
2．扩展关联
2021/1/16
-
16
3．包含关联 4．使用关联
2021/1/16
-
17
考虑用例的 关联类型
2021/1/16
-
18
2021/1/16
-
19
3.2.7 用例图实例
2021/1/16
-
20
3.3 定义系统的对象和类
类 - 责 任 - 协 作 者 （ Class-ResponsibilityCollaborator， 简称CRC）技术：
2021/1/16
-
41
（4）“采购管理子系统”中的用例（第三层） • 制定采购计划； • 签订采购合同； • 货物入库检验； • 支付货款； • 检查合同履约。 （5）“库存管理子系统”中的用例（第三层） • 入库管理； • 出库管理； • 库存管理。
2021/1/16
-
42
3.6.5 分层绘制用例图
2021/1/16
-
35
2．具体功能要求
本案例只对其中的“进销存管理子系统”进行详细的需 求分析用例建模。
（1）销售管理 1）制定销售计划 2）与客户签订销售合同 3）检查合同履约率 4）生产调度管理部门组织生产 5）库存管理部门对产品进行入库、出库处理 6）财务管理部门收取客户货款 7）售后服务
（1）标识码有效性检查失败，允许学生重新输入（3次机会）。 （2）注册识别失败，没有注册（尙未交学费）的学生不能选课。 （3）选择课程确认失败，所选几门课程中在上课时间上发生冲
突时，系统提示重选。
2021/1/16
-
15
3.2.6 用例之间的关联
1．继承关联
2．扩展关联
2021/1/16
-
16
3．包含关联 4．使用关联
2021/1/16
-
17
考虑用例的 关联类型
2021/1/16
-
18
2021/1/16
-
19
3.2.7 用例图实例
2021/1/16
-
20
3.3 定义系统的对象和类
类 - 责 任 - 协 作 者 （ Class-ResponsibilityCollaborator， 简称CRC）技术：
2021/1/16
-
41
（4）“采购管理子系统”中的用例（第三层） • 制定采购计划； • 签订采购合同； • 货物入库检验； • 支付货款； • 检查合同履约。 （5）“库存管理子系统”中的用例（第三层） • 入库管理； • 出库管理； • 库存管理。
2021/1/16
-
42
3.6.5 分层绘制用例图
2021/1/16
-
35
2．具体功能要求
本案例只对其中的“进销存管理子系统”进行详细的需 求分析用例建模。
（1）销售管理 1）制定销售计划 2）与客户签订销售合同 3）检查合同履约率 4）生产调度管理部门组织生产 5）库存管理部门对产品进行入库、出库处理 6）财务管理部门收取客户货款 7）售后服务
UML系统建模与分析设计
5、ATM系统需要处理哪些设备？ 答：信用卡 6、谁对ATM系统运行的结果感兴趣？ 答：银行会计、储户
2019/10/28
软件工程方法
12
储户 信用卡
银行人员 银行会计
2019/10/28
软件工程方法
13
2.定义执行者时应该注意的问题 1）执行者之间可以有继承关系
学生
小学生
中学生
大学生
2019/10/28
2019/10/28
软件工程方法
6
1.2 用例图
2019/10/28
软件工程方法
图中的元素包括：参与者、 用例、一个方框和一些表示 关系的连接线 。 所有的用例都位于方框之内 ，该方框称为“系统边界” 参与者与用例的关系：在参 与者和用例之间的关联是用 一根带箭头的线来表示的 用例之间的关系： 1）包含关系 2）扩展关系 3）泛化关系
用户是否要在系统中创建、删除、读、修改或存储某类业 务数据？
系统为了维持正常运转需要增加的功能和信息的交互；
这些信息从何而来，到哪里去？
实现当前系统（可能是人工系统而不是自动化系统）的关 键问题是什么？
2019/10/28
软件工程方法
22
通过与用户反复交流，确定主要业务用例和次要 业务用例。
2019/10/28
软件工程方法
27
判断题
支持跨行业务 插入卡片 输入密码 选择服务 取钱 存钱 挂失卡片 交纳费用 警示骗子 三次错误吞没卡片
2019/10/28软件工程方法 Nhomakorabea28
支持跨行业务 错，这是一个业务规则，限定业务的范 围
插入卡片
错，这是一个过程步骤，不是完整目标
2019/10/28
软件工程方法
12
储户 信用卡
银行人员 银行会计
2019/10/28
软件工程方法
13
2.定义执行者时应该注意的问题 1）执行者之间可以有继承关系
学生
小学生
中学生
大学生
2019/10/28
2019/10/28
软件工程方法
6
1.2 用例图
2019/10/28
软件工程方法
图中的元素包括：参与者、 用例、一个方框和一些表示 关系的连接线 。 所有的用例都位于方框之内 ，该方框称为“系统边界” 参与者与用例的关系：在参 与者和用例之间的关联是用 一根带箭头的线来表示的 用例之间的关系： 1）包含关系 2）扩展关系 3）泛化关系
用户是否要在系统中创建、删除、读、修改或存储某类业 务数据？
系统为了维持正常运转需要增加的功能和信息的交互；
这些信息从何而来，到哪里去？
实现当前系统（可能是人工系统而不是自动化系统）的关 键问题是什么？
2019/10/28
软件工程方法
22
通过与用户反复交流，确定主要业务用例和次要 业务用例。
2019/10/28
软件工程方法
27
判断题
支持跨行业务 插入卡片 输入密码 选择服务 取钱 存钱 挂失卡片 交纳费用 警示骗子 三次错误吞没卡片
2019/10/28软件工程方法 Nhomakorabea28
支持跨行业务 错，这是一个业务规则，限定业务的范 围
插入卡片
错，这是一个过程步骤，不是完整目标
课件—UML系统建模与分析设计(7)-系统体系结构建模
还应用伪代码或者文字给出类的规约。
2020/8/8
UML系统建模与分析设计
17
ＯＯ方法中执行主要活动的描述。主要步骤是分析、 设计、实现及测试。
需求分析
设计 实现
实现活动实际上就是编写程序 代码，包括反复的编译、连结、排 错等。
并应遵循传统的编程准则。
测试
2020/8/8
UML系统建模与分析设计
18
21
2 UML体系结构设计
从一般意义上说，体系结构包括两个层面，即硬件体 系结构和软件体系结构。
硬件体系结构指系统的硬件组织模式；而软件体系结 构则描述软件的组织模式。这里我们主要关注软件体系结 构的问题。
1、用包图或构件图描述的静态结构 2、基于配置图的软件体系结构 3、基于模式的软件体系结构
2020/8/8
构件对外提供的可见操作和属性称为构件的界面。 界面的图符是一个小圆圈。用一条连线将构件与圆圈连 起来。
构件之间的依赖关系是指结构之间在编译，连接或 执行时的依赖关系。用虚线箭头表示。
2020/8/8
UML系统建模与分析设计
5
窗口控制 （whnd.cpp）
关
系
通信控制
(comhnd.cpp)
窗口控制 (whnd.obj)
是指在编译阶段和连接阶段，组件之间的依赖关系。
• 调用依赖(Call Dependency)
是指一个组件调用或使用另外一个组件服务。
业务 （源码）
系统管理 （源码）
系统管理 （对象）
系统管理 （执行码）
资源管理 （源码）
资源管理 （对象）
资源管理 （执行码）
项目管理 （源码）
2020/8/8
课件—UML系统建模与分析设计(7)-系统体系结构建模
医院诊疗系统的配置图
Heart Unit Server（心血管病服务器）
:Object Database
:Health Care Domain
:Heart Unit Server
Application
《Communication 》
Heart Unit Configuration
:Configure Knowledge :Configure users
构件对外提供的可见操作和属性称为构件的界面。界面的 图符是一个小圆圈。用一条连线将构件与圆圈连起来。
图形库 (graphic.dll)
构件可以看作包与类对应的物理代码模块，逻辑 上与包，类对应，实际上是一个文件，可以有下列几种 类型的构件：
1） 源代码构件；
2） 二进制构件；
3） 可执行构件
构件图符是一个矩形框。
第七章 系统体系结构建模
• 实现模型描述了系统实现时的一些特性，又称为物 理体系结构建模。包括源代码的静态结构和运行时 刻的实现结构。实现模型包括：
• 构件图(Component diagram) 显示代码本身的逻辑 结构，它描述系统中存在的软构件以及它们之间的 依赖关系。构件图的元素有构件，依赖关系和界面。
配置图可以显示计算机结点的拓扑结构和通信路径，结 点上执行的软构件，软构件包含的逻辑单元等，特别对于分 布式系统，配置图可以清楚的描述系统中硬件设备的配置， 通信以及在各硬件设备上各种软构件和对象的配置。因此， 配置图是描述任何基于计算机的应用系统的物理配置或逻辑 配置的有力工具，配置图的元素有结点和连接。
配置图中的结点代表某种计算机构件，通常是某种硬件。 同时结点还包括在其上运行的软构件，软构件代表可执行的 物理代码模块。如一个可执行程序。 结点的图符是一个立方 体。
UML系统建模与分析设计
2019/12/20
软件工程方法
10
ATM系统的Actor
1、谁使用ATM系统的主要功能（提款）？ 答：储户
2、谁使用ATM系统的支持以完成日常工作任务？ 答：出纳员？还不肯定，先放在这里
3、谁来维护、管理并保持系统正常运行？ 答： ATM系统工程师，银行人员
2019/12/20
软件工程方法
11
4、该系统需要和哪些系统交互？ 答：目前还不清楚
输入密码
错，这是一个过程步骤，不是完整目标
选择服务
错，这是一个过程步骤，不是完整目标
取钱
对，这是一个完整有效的目标
存钱
对，这是一个完整有效的目标
挂失卡片
对，这是一个完整有效的目标
交纳费用
对，这是一个完整有效的目标
角色与用例的关联表示角色 与用例相关性。在UML中是 使用一条实线连接角色与用 例
7
1.3 定义系统的边界和范围
系统：特指基于计算机的用于解决某个特定问题域的软硬件系 统。它代表的是一个活动范围。 定义系统：要定义系统的范围和边界
1．定义系统的范围 :系统问题域的目标、任务、规模即系统 提供的功能和任务。
但是我们所见的很多用例中类似“计算”，“统计”， “报表”，“输出”，“录入”之类的并不在少数。
2019/12/20
软件工程方法
20
2．寻找和确定用例
业务用例：开始阶段，在确定用户需求过程中， 系统分析员通过与客户交流建立业务模型来发现 和确定的用例。
系统用例：系统构造阶段，系统分析和设计人员 在进行系统分析和设计时，根据系统的需求建立 的用例。
需求分析与用例建模
2019/12/20
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
这些模型之间并不是线性转变的，它们是一个迭代、增量的开发过程。 也就是在整个项目开发周期中，将会多次经过这五个模型的迭代，每 次都将越来越精化。
2020/7/31
软件工程方法
3
1.1 建造需求模型——用例建模
用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典 型用例的分析，使开发者能够有效地了解用户的需求。
对于正在构造的新系统用例描述系统应该作什么? 对于已构造完毕的系统用例则反映了系统能够完成什么样的功能?
用例建模的主要目标是：
•将需求规约变为可视化模型，并得到用户确认；
•给出清晰、一致的关于系统做什么的描述，确定系统的功能要 求；
•提供从功能需求到系统分析、设计、实现各阶段的度量标准；
•为最终系统测试提供基准，据此验证系统是否达到功能要求；
2020/7/31
软件工程方法
6
用例建模的步骤：
•确定系统的范围和边界； •确定系统的执行者和用例； •对用例进行描述； •定义用例之间的关系； •审核用例模型。
2020/7/31
软件工程Hale Waihona Puke 法71.2 用例图
2020/7/31
软件工程方法
图中的元素包括：参与者、 用例、一个方框和一些表示 关系的连接线 。 所有的用例都位于方框之内 ，该方框称为“系统边界” 参与者与用例的关系：在参 与者和用例之间的关联是用 一根带箭头的线来表示的 用例之间的关系： 1）包含关系 2）扩展关系 3）泛化关系
2020/7/31
软件工程方法
11
ATM系统的Actor
1、谁使用ATM系统的主要功能（提款）？ 答：储户
2、谁使用ATM系统的支持以完成日常工作任务？ 答：出纳员？还不肯定，先放在这里
3、谁来维护、管理并保持系统正常运行？ 答： ATM系统工程师，银行人员
2020/7/31
软件工程方法
12
4、该系统需要和哪些系统交互？ 答：目前还不清楚
角色与系统交互：角色向系统发送消息、从系统接受消息、或是与系统 交换信息。
角色与用例：角色往往是发现新用例的基础，同时也是分析员和用户交 流的起点。一个执行者可用启动多个用例，而一个用例也可以被多个执 行者启动。
2020/7/31
软件工程方法
10
1.寻找和确定执行者
通过向用户提问来识别角色： 谁使用系统提供的主要功能？（主要角色） 谁来维护、管理系统？（次要角色） 谁需要借助于系统完成日常工作任务？ 系统需要控制的硬件设备有哪些？ 系统需要与其他哪些系统交互？ 系统从哪儿得到信息？ 对系统产生的结果感兴趣的人或事是哪些？ ！不能把目光只专著于人身上。
需求分析与用例建模
2020/7/31
软件工程方法
1
第一部分
整体概述
THE FIRST PART OF THE OVERALL OVERVIEW, PLEASE SUMMARIZE THE CONTENT
1 客户需求分析与用例建模
用例用于表示系统所提供的服务，它定义了系统是如何被 参与者所使用的，它描述的是参与者为了使用系统所提供
2．定义系统的边界:一个系统的所有元素与系统以外的事物的 分界线。
2020/7/31
软件工程方法
9
1.4 确定执行者（参与者，角色） aActor
执行者（actor）是指在系统外部与系统交互的人或其他系统，它以某 种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图 符来表示。
执行者类型：参与者不仅可以由人承担，还可以是其它系统、硬件设备、 甚至是时钟 ： 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中， 银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系 统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者
5、ATM系统需要处理哪些设备？ 答：信用卡 6、谁对ATM系统运行的结果感兴趣？ 答：银行会计、储户
2020/7/31
软件工程方法
13
储户 信用卡
银行人员 银行会计
2020/7/31
软件工程方法
14
2.定义执行者时应该注意的问题 1）执行者之间可以有继承关系
学生
小学生
中学生
大学生
2020/7/31
的某一完整功能而与系统之间发生的一段对话。
用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例 驱动的。分析、设计、实现、测试都是用例驱动的，都是以实现用例 为目标。
在这些开发过程中，开发人员首先捕获客户的需求，并以用例的形式 组织成用例模型。然后分析并设计系统来满足这些用例，因此在用例 模型之后就是分析模型，接着是设计模型和实施模型。在实现了整个 系统之后，还将根据用例模型设计出测试模型来对系统进行验证。
本科生
研究生
硕士研究生
博士研究生
软件工程方法
15
（2）执行者代表一种角色而不是具体某个人 （3）对同一个人担任角色的限制 （4）执行者可分成主执行者和副执行者 （5）执行者还可细分为主动执行者和被动执行者
主动角色：Use Case的动作序列是由他先发起的，通常 系统返回最后结果
角色与用例的关联表示角色 与用例相关性。在UML中是 使用一条实线连接角色与用 例
8
1.3 定义系统的边界和范围
系统：特指基于计算机的用于解决某个特定问题域的软硬件系 统。它代表的是一个活动范围。
定义系统：要定义系统的范围和边界
1．定义系统的范围 :系统问题域的目标、任务、规模即系统 提供的功能和任务。
•为项目目标进度管理和风险管理提供依据。
2020/7/31
软件工程方法
4
用例图中包含系
统、角色和用例
等三种模型元素，
以及它们之间的
关系。
贸易经理
营销人员
设置边界
更新帐目
风险分析 交易估价
《使用》 《使用》
评价
进行交易
《扩展》
超越边界
记账系统 销售人员
2020/7/31
软件工程方法
5
用例模型描述的是外部执行者(Actor)所理解的系 统功能。它描述了待开发系统的功能需求。
它驱动了需求分析之后各阶段的开发工作,不仅在 开发过程中保证了系统所有功能的实现,而且被用 于验证和检测所开发的系统,从而影响到开发工作 的各个阶段和 UML 的各个模型。
用例模型由若干个用例图构成，用例图中主要描 述执行者和用例之间的关系。在UML中,构成用例 图的主要元素是用例和执行者及其它们之间的联 系。
2020/7/31
软件工程方法
3
1.1 建造需求模型——用例建模
用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典 型用例的分析，使开发者能够有效地了解用户的需求。
对于正在构造的新系统用例描述系统应该作什么? 对于已构造完毕的系统用例则反映了系统能够完成什么样的功能?
用例建模的主要目标是：
•将需求规约变为可视化模型，并得到用户确认；
•给出清晰、一致的关于系统做什么的描述，确定系统的功能要 求；
•提供从功能需求到系统分析、设计、实现各阶段的度量标准；
•为最终系统测试提供基准，据此验证系统是否达到功能要求；
2020/7/31
软件工程方法
6
用例建模的步骤：
•确定系统的范围和边界； •确定系统的执行者和用例； •对用例进行描述； •定义用例之间的关系； •审核用例模型。
2020/7/31
软件工程Hale Waihona Puke 法71.2 用例图
2020/7/31
软件工程方法
图中的元素包括：参与者、 用例、一个方框和一些表示 关系的连接线 。 所有的用例都位于方框之内 ，该方框称为“系统边界” 参与者与用例的关系：在参 与者和用例之间的关联是用 一根带箭头的线来表示的 用例之间的关系： 1）包含关系 2）扩展关系 3）泛化关系
2020/7/31
软件工程方法
11
ATM系统的Actor
1、谁使用ATM系统的主要功能（提款）？ 答：储户
2、谁使用ATM系统的支持以完成日常工作任务？ 答：出纳员？还不肯定，先放在这里
3、谁来维护、管理并保持系统正常运行？ 答： ATM系统工程师，银行人员
2020/7/31
软件工程方法
12
4、该系统需要和哪些系统交互？ 答：目前还不清楚
角色与系统交互：角色向系统发送消息、从系统接受消息、或是与系统 交换信息。
角色与用例：角色往往是发现新用例的基础，同时也是分析员和用户交 流的起点。一个执行者可用启动多个用例，而一个用例也可以被多个执 行者启动。
2020/7/31
软件工程方法
10
1.寻找和确定执行者
通过向用户提问来识别角色： 谁使用系统提供的主要功能？（主要角色） 谁来维护、管理系统？（次要角色） 谁需要借助于系统完成日常工作任务？ 系统需要控制的硬件设备有哪些？ 系统需要与其他哪些系统交互？ 系统从哪儿得到信息？ 对系统产生的结果感兴趣的人或事是哪些？ ！不能把目光只专著于人身上。
需求分析与用例建模
2020/7/31
软件工程方法
1
第一部分
整体概述
THE FIRST PART OF THE OVERALL OVERVIEW, PLEASE SUMMARIZE THE CONTENT
1 客户需求分析与用例建模
用例用于表示系统所提供的服务，它定义了系统是如何被 参与者所使用的，它描述的是参与者为了使用系统所提供
2．定义系统的边界:一个系统的所有元素与系统以外的事物的 分界线。
2020/7/31
软件工程方法
9
1.4 确定执行者（参与者，角色） aActor
执行者（actor）是指在系统外部与系统交互的人或其他系统，它以某 种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图 符来表示。
执行者类型：参与者不仅可以由人承担，还可以是其它系统、硬件设备、 甚至是时钟 ： 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中， 银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系 统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者
5、ATM系统需要处理哪些设备？ 答：信用卡 6、谁对ATM系统运行的结果感兴趣？ 答：银行会计、储户
2020/7/31
软件工程方法
13
储户 信用卡
银行人员 银行会计
2020/7/31
软件工程方法
14
2.定义执行者时应该注意的问题 1）执行者之间可以有继承关系
学生
小学生
中学生
大学生
2020/7/31
的某一完整功能而与系统之间发生的一段对话。
用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例 驱动的。分析、设计、实现、测试都是用例驱动的，都是以实现用例 为目标。
在这些开发过程中，开发人员首先捕获客户的需求，并以用例的形式 组织成用例模型。然后分析并设计系统来满足这些用例，因此在用例 模型之后就是分析模型，接着是设计模型和实施模型。在实现了整个 系统之后，还将根据用例模型设计出测试模型来对系统进行验证。
本科生
研究生
硕士研究生
博士研究生
软件工程方法
15
（2）执行者代表一种角色而不是具体某个人 （3）对同一个人担任角色的限制 （4）执行者可分成主执行者和副执行者 （5）执行者还可细分为主动执行者和被动执行者
主动角色：Use Case的动作序列是由他先发起的，通常 系统返回最后结果
角色与用例的关联表示角色 与用例相关性。在UML中是 使用一条实线连接角色与用 例
8
1.3 定义系统的边界和范围
系统：特指基于计算机的用于解决某个特定问题域的软硬件系 统。它代表的是一个活动范围。
定义系统：要定义系统的范围和边界
1．定义系统的范围 :系统问题域的目标、任务、规模即系统 提供的功能和任务。
•为项目目标进度管理和风险管理提供依据。
2020/7/31
软件工程方法
4
用例图中包含系
统、角色和用例
等三种模型元素，
以及它们之间的
关系。
贸易经理
营销人员
设置边界
更新帐目
风险分析 交易估价
《使用》 《使用》
评价
进行交易
《扩展》
超越边界
记账系统 销售人员
2020/7/31
软件工程方法
5
用例模型描述的是外部执行者(Actor)所理解的系 统功能。它描述了待开发系统的功能需求。
它驱动了需求分析之后各阶段的开发工作,不仅在 开发过程中保证了系统所有功能的实现,而且被用 于验证和检测所开发的系统,从而影响到开发工作 的各个阶段和 UML 的各个模型。
用例模型由若干个用例图构成，用例图中主要描 述执行者和用例之间的关系。在UML中,构成用例 图的主要元素是用例和执行者及其它们之间的联 系。