UML系统建模与分析设计.ppt
合集下载
课件—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．对象之间的同步操作
同步消息的发送者把进程控制传递给消息 的接收者，然后暂停活动，等待消息的接收者 放弃或返回控制； 同步消息的接收者执行所请求的操作，如 果需要的话，可以把控制传递给另一个对象角 色，请求做某个操作，并且当该操作完成后把 控制返回给原来的同步消息的发送者； 同步消息的接收者也可以直接返回或发送 信息给原来的消息发送者。
《系统分析及建模》PPT课件
精选课件ppt
13
难题之二
❖ 开发人员与用户之间存在着专业知识的鸿沟。俗话讲，隔行如隔山， 专业知识的壁垒构成了开发人员与用户间的沟通障碍。然而，开发活 动恰恰要求必须由用户来确认系统分析说明的准确性和完整性，必须 确保开发人员完整、准确地理解了用户心目中对新系统的真实要求。 开发人员也必须努力准确理解和表述用户的需求，因此，这个阶段的 活动难度非常大。
与计划
划的制订
含计划） （或签协议、订合同）
精选课件ppt
7
4.2 系统分析的内容与主要活动
活动名称
目标
关键问题
主要成果 （产品）
管理决策
3
现行系统调查
详细调查现行系统 的工作过程，建立 现行系统的逻辑模 型，发现现行系统 存在的主要问题。
现行系统的结构业 务流程和数据的详 细分析，确认存在 的问题（结构化遍 历3W+1H）
精选课件ppt
5
4.2 系统分析的内容与主要活动
系统分析的基本内容： 系统分析阶段需要对管理信息系统的下列问题进行调研和分析：
（1）确定新系统的目标。 （2）系统的总体结构描述。 （3）子系统功能描述： （4）子系统数据分析： （5）数据输入输出描述： （6）确定技术性能指标，包括可靠性、安全保密性、适用性、可维护性和可移
2
本章内容
❖ 4.1系统分析的目标 ❖ 4.2系统分析内容和主要活动 ❖ 4.3需求分析的重要性 ❖ 4.4系统分析面临的主要问题 ❖ 4.5系统分析相关概念 ❖ 4.6建模 ❖ 4.7 需求分析说明书的编写
精选课件ppt
3
4.1 系统分析的目标
❖ 系统分析、系统设计和系统实施构成系统开发周期的三个主要阶段。 系统分析是开发人员和用户共同参与的一项活动。这一阶段的主要任 务是充分挖掘和理解用户对新系统的要求，并将其明确表述成一份书 面资料。这份资料的主要内容就是新系统的逻辑模型，这就是系统分 析说明书，又称用户需求说明书。
第3章 uml系统建模与分析设计-需求分析与用例建模01课件
2019/1/31
软件工程方法
42
目标和步骤的误区
2019/1/31
软件工程方法
43
用例的粒度
ATM取钱的场景中，取钱，读卡，验证账号，打 印回执单等都是可能的用例？ 用例粒度的划分最标准的方法应该是：以该用例 是否完成了参与者的某个完整目的为依据的。 同一个需求阶段，用例的粒度应该时同一级别的。 粒度选取的问题本质上还是因为边界认定不同而 产生的。
•给出清晰、一致的关于系统做什么的描述，确定系统的功能要求；
•提供从功能需求到系统分析、设计、实现各阶段的度量标准； •为最终系统测试提供基准，据此验证系统是否达到功能要求； •为项目目标进度管理和风险管理提供依据。
2019/1/31
软件工程方法
7
用例建模的步骤
确定系统的范围和边界； 确定系统的执行者和用例； 对用例进行描述； 定义用例之间的关系； 审核用例模型。
3.2.5.3.描述用例
用例名： 简单名： 路径名：
2019/1/31
软件工程方法
48
用例的文字描述应包括以下内容:
用例的目的（功能）； 该用例在什么情况下被哪个执行者启动执行； 用例与执行者之间交互哪些消息来通知对方作
•反映系统动态特性： •综合系统的全部因素： •突出系统的重要因素： •结构简单：
3.1.3 法律可行性分析 3.1.4 开发方案可行性分析研究
1. 提出待选方案 2. 评价待选方案 3. 确定开发方案
2019/1/31 软件工程方法 4
3.1.5
可行性分析报告文档格式
2019/1/31
软件工程方法
错，这是一个过程步骤，不是完整目标 错，这是一个过程步骤，不是完整目标 错，这是一个过程步骤，不是完整目标
课件—UML系统建模与分析设计(2)
5
用例视图
2014-9-4
UML系统建模与分析设计
6
2．逻辑视图 作用：描述如何实现系统内部的功能 ； 适用对象：分析者、设计者、开发者 ； 描述使用的图：类图和对象图、状态图、 顺序图、合作图和活动图 ； 重要性：描述了系统的静态结构和因发 送消息而出现的动态协作关系 。
2014-9-4
UML系统建模与分析设计
7
2．逻辑视图 作用：描述如何实现系统内部的功能 ； 适用对象：分析者、设计者、开发者 ； 描述使用的图：类图和对象图、状态图、 顺序图、合作图和活动图 ； 重要性：描述了系统的静态结构和因发 送消息而出现的动态协作关系 。
2014-9-4
UML系统建模与分析设计
40
2.5.1
迭代、渐增式的开发过程
一级：必须；二级：短期；三级：长期;
（1）用例分类 1）将用例的优先级分为三级 2）体系结构方面的风险的风险
一级：高；二级：可能；三级：不可能;
3）进度风险（对实现每个用例所需 工作量估算的评价）分为三级
一级：无法；二级：人/月；三级：确信;
（2）确定每次迭代的开发周期
1
2.1
UML模型系统体系结构
2.1.1 UML的诞生与发展
2014-9-4
UML系统建模与分析设计
2
2014-9-4
UML系统建模与分析设计
3
2.1.2 UML的特点
统一标准 面向对象 可视化、表达能力强 独立于(开发)过程 易掌握、易用
2014-9-4
UML系统建模与分析设计
12
5．配置视图 作用：描述系统的物理设备配置，如计 算机、硬件设备以及它们相互间的连接 ； 适用对象：开发者、系统集成者和测试 者； 描述使用的图：配置图 ； 重要性：描述硬件设备的连接和哪个程 序或对象驻留在哪台计算机上执行 。
课件—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
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
统、角色和用例
等三种模型元素，
以及它们之间的
关系。
贸易经理
营销人员
设置边界
更新帐目
风险分析 交易估价
《使用》 《使用》
评价
进行交易
《扩展》
超越边界
记账系统 销售人员
2020/10/16
软件工程方法
4
用例模型描述的是外部执行者(Actor)所理解的系 统功能。它描述了待开发系统的功能需求。
它驱动了需求分析之后各阶段的开发工作,不仅在 开发过程中保证了系统所有功能的实现,而且被用 于验证和检测所开发的系统,从而影响到开发工作 的各个阶段和 UML 的各个模型。
2．定义系统的边界:一个系统的所有元素与系统以外的事物的 分界线。
2020/10/16
软件工程方法
8
1.4 确定执行者（参与者，角色） aActor
执行者（actor）是指在系统外部与系统交互的人或其他系统，它以某 种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图 符来表示。
执行者类型：参与者不仅可以由人承担，还可以是其它系统、硬件设备、 甚至是时钟 ： 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中， 银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系 统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者
•将需求规约变为可视化模型，并得到用户确认；
•给出清晰、一致的关于系统做什么的描述，确定系统的功能要 求；
•提供从功能需求到系统分析、设计、实现各阶段的度量标准；
•为最终系统测试提供基准，据此验证系统是否达到功能要求；
•为项目目标进度管理和风险管理提供依据。
2020/10/16
软件工程方法
3
用例图中包含系
用例模型由若干个用例图构成，用例图中主要描 述执行者和用例之间的关系。在UML中,构成用例 图的主要元素是用例和执行者及其它们之间的联 系。
2020/10/16
软件工程方法
5
用例建模的步骤：
•确定系统的范围和边界； •确定系统的执行者和用例； •对用例进行描述； •定义用例之间的关系； •审核用例模型。
需求分析与用例建模
2020/10/16
软件工程方法
1
1 客户需求分析与用例建模
用例用于表示系统所提供的服务，它定义了系统是如何被 参与者所使用的，它描述的是参与者为了使用系统所提供
的某一完整功能而与系统之间发生的一段对话。
用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例 驱动的。分析、设计、实现、测试都是用例驱动的，都是以实现用例 为求，并以用例的形式 组织成用例模型。然后分析并设计系统来满足这些用例，因此在用例 模型之后就是分析模型，接着是设计模型和实施模型。在实现了整个 系统之后，还将根据用例模型设计出测试模型来对系统进行验证。
这些模型之间并不是线性转变的，它们是一个迭代、增量的开发过程。 也就是在整个项目开发周期中，将会多次经过这五个模型的迭代，每 次都将越来越精化。
本科生
研究生
硕士研究生
博士研究生
软件工程方法
14
（2）执行者代表一种角色而不是具体某个人 （3）对同一个人担任角色的限制 （4）执行者可分成主执行者和副执行者 （5）执行者还可细分为主动执行者和被动执行者
主动角色：Use Case的动作序列是由他先发起的，通常 系统返回最后结果
主叫方，采购人员，票据录入员等
角色与用例的关联表示角色 与用例相关性。在UML中是 使用一条实线连接角色与用 例
7
1.3 定义系统的边界和范围
系统：特指基于计算机的用于解决某个特定问题域的软硬件系 统。它代表的是一个活动范围。 定义系统：要定义系统的范围和边界
1．定义系统的范围 :系统问题域的目标、任务、规模即系统 提供的功能和任务。
2020/10/16
软件工程方法
2
1.1 建造需求模型——用例建模
用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对 典型用例的分析，使开发者能够有效地了解用户的需求。
对于正在构造的新系统用例描述系统应该作什么? 对于已构造完毕的系统用例则反映了系统能够完成什么样的功能?
用例建模的主要目标是：
被动角色：系统通过调用角色来完成Use Case的动作序 列（或其中的某一个动作）
角色与系统交互：角色向系统发送消息、从系统接受消息、或是与系统 交换信息。
角色与用例：角色往往是发现新用例的基础，同时也是分析员和用户交 流的起点。一个执行者可用启动多个用例，而一个用例也可以被多个执 行者启动。
2020/10/16
软件工程方法
9
1.寻找和确定执行者
通过向用户提问来识别角色： 谁使用系统提供的主要功能？（主要角色） 谁来维护、管理系统？（次要角色） 谁需要借助于系统完成日常工作任务？ 系统需要控制的硬件设备有哪些？ 系统需要与其他哪些系统交互？ 系统从哪儿得到信息？ 对系统产生的结果感兴趣的人或事是哪些？ ！不能把目光只专著于人身上。
2020/10/16
软件工程方法
6
1.2 用例图
2020/10/16
软件工程方法
图中的元素包括：参与者、 用例、一个方框和一些表示 关系的连接线 。 所有的用例都位于方框之内 ，该方框称为“系统边界” 参与者与用例的关系：在参 与者和用例之间的关联是用 一根带箭头的线来表示的 用例之间的关系： 1）包含关系 2）扩展关系 3）泛化关系
2020/10/16
软件工程方法
10
ATM系统的Actor
1、谁使用ATM系统的主要功能（提款）？ 答：储户
2、谁使用ATM系统的支持以完成日常工作任务？ 答：出纳员？还不肯定，先放在这里
3、谁来维护、管理并保持系统正常运行？ 答： ATM系统工程师，银行人员
2020/10/16
软件工程方法
11
4、该系统需要和哪些系统交互？ 答：目前还不清楚
5、ATM系统需要处理哪些设备？ 答：信用卡 6、谁对ATM系统运行的结果感兴趣？ 答：银行会计、储户
2020/10/16
软件工程方法
12
储户 信用卡
银行人员 银行会计
2020/10/16
软件工程方法
13
2.定义执行者时应该注意的问题 1）执行者之间可以有继承关系
学生
小学生
中学生
大学生
2020/10/16