第5章 系统模型
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2
什么是模型？
模型是系统的抽象视图，它忽略了系统 中的所有细节。辅助模型的开发能够反映系 统中不同的信息。
3
描画系统模型
▪ 系统模型描画在纸上，是平面的；但思维则是 多维的，需要从几个不同的视角出发：
1.从外部来看，对系统环境建模，即描述系统的“上 下文” 。
2.从交互上看，它是对系统与环境之间或是一个系统 各组成部分之间的交互建模。
▪ 名称：名称无疑应该表明用户的意图或用例的用途， 如“研究班招生”。
▪ 标识符 [可选]：唯一标识符，如 "UC1701"，在项目的 其他元素（如类模型）中可用它来引用这个用例。
▪ 说明：概述用例的几句话。 ▪ 参与者 [可选]：与此用例相关的参与者列表。尽管这
则信息包含在用例本身中，但在没有用例图时，它有 助于增加对该用例的理解。
13
5.2.1 用例模型
▪ 用例图用于定义系统的功能需求，它描述 了系统的参与者与系统提供的用例之间的 关系。
▪ 参与着可以是人，可以是另外一个系统。 ▪ 用例图仅仅从使用者的角度描述系统中的
信息
1 参与者
▪ 参与者（Actor）是系统外部
的一个实体（可以是任何的
事物或人），它以某种方式
参与了用例的执行过程。参
统外部的！！ 3. 说明外部要素与系统之间的关系；
10
上下文模型示例： MHC-PMS系统的上下文模型
5.2 交互建模
所有的系统都会涉及到交互，有可能是 用户交互，与用户的输入有关，有可能是正 在开发的系统与其它系统之间的交互，或者 是组成系统的各个组成部分之间交互。交互 图的描述是为了更好的识别用户的需求。
识别用例
▪ 识别用例最好的办法就是从分析系统的参 与者开始，考虑每个参与者是怎样使用系 统。使用这种策略的过程中可能会找出一 个新的参与者，这对完善整个系统建模很 有帮助。
识别用例时有用的几个问题
▪ 在识别用例的过程中，通过以下的几个问题可以 帮助识别用例：
▪ （1）特定参与者希望系统提供什么功能？ ▪ （2）系统是否存储和检索信息？如果是，这个行
Leabharlann Baidu
练习
▪ 识别“超市进销存管理系统”中的参与者
2 用例
▪ 用例是一组连续的操作，当用户使用系统来完成某个 过程时出现，它是外部可见的系统功能单元。通过将 这些不同功能单元的组合，就构成了对系统总体需求 的描述。
▪ 用例要点: 1.位于系统 --必须由系统运行 2.目标导向 --用例运行必须有所目的 3.止于边界 --可以观测到结果,并且是在边界和外部 有所交互的 4.用户观点 --参与者观测 5.粒度 --是一组有共同目标或者可以类聚的目标的 实例组成
系 ▪ 状态图：表示系统是如何响应内部和外部事件
的
▪ 静态建模 动态建模
5.1 上下文模型
上下文模型示出了要建模的系统在整个 环境中与其他系统和过程间的位置关系。上 下文模型定义了系统的边界。体系结构模型、 过程模型可以作为上下文模型。
7
上下文模型示例1：ATM系统
系统边界
ATM系统上下文
8
上下文模型是什么意思？
为由哪个参与者触发? ▪ （3）当系统改变状态时，通知参与者吗？ ▪ （4）存在影响系统的外部事件吗？ ▪ （5）是哪个参与者通知系统这些事件？（系统需
要什么样的输入输出）
用例识别练习
ATM自动柜员机系统是由计算机控制的 银行自动出纳系统，主要服务于活期储蓄， 实现客户自助服务的电子化设备。通过UML 对ATM自动取款机建模，实现查询余额、取 款、存款、转账、更改密码等业务，根据 需求还可以进一步扩展具体功能。
与者通过向系统输入或请求
系统输入某些事件来触发系
统的执行。参与者由他们参
与用例时所担当的角色来代
主角1
表。
识别参与者
参与者（Actor）是系统外部的一个实体，他们不是 系统的组成部分。回答如下问题，可以帮助建模人 员发现参与者。 ▪ 系统的主要客户是谁 ？ ▪ 谁借助于系统完成日常工作？ ▪ 谁来维护和管理系统，保证系统的正常运行？ ▪ 系统控制的硬件设置有那些？ ▪ 系统需要和其它系统进行交互吗？ ▪ 在预定的时刻，是否有预定的事件发生？ ▪ 系统从什么地方获取信息？
▪ 注意：上下文模型的意图在于说清“系统的环境 是什么”，说不清的（不确定的）就通过讨论来 逐渐明确。
所谓“系统的环境是什么”——即从系统外部对系统的 输入开始，直到系统处理之后对系统外部的响应，此过 程的结构化描述。
9
上下文模型的建模方法
▪ 具体的建模（描述）方法
1. 对系统命名，表示出确定的系统边界； 2. 标识系统外部的所有参与要素；——注意，是系
3.从结构上看，对系统的体系结构和系统处理的数据 的结构建模。
4.从行为上看，对系统的行为建模，即描述系统的动 态行为和它对事件的响应方式的建模。
4
常见的软件系统模型
▪ 上下文模型 ▪ 交互模型
1 用例建模，2 时序图
▪ 结构模型
1 类图，2 泛化，3 聚合
▪ 行为模型
1 数据驱动的建模，2 事件驱动模型
第五章 系统建模（System models）
1
学习引导
▪ 本章介绍一系列不同的系统模型，这些模型是在 需求工程和系统设计过程中必须建立有用工具。
▪ 主要内容：
理解如何用图形模型来表示软件系统； 理解不同类型的模型以及基本的系统建模角度，如上下
文、交互、结构和行为等； 统一建模语言（UML）中定义的符号及其建模应用；
▪ 用例与参与者之间的连线称为关系，关系也称 为关联或通信关联，它表示参与者与用例之间 的通信。一般情况下，不用带箭头的直线表示 信息流动的方向，因为信息流动是双向的。
▪ 如果使用箭头，则特意的表示信息的发起者或 接受者；
关系
主角1
用例1
3 用例描述
3 用例描述
▪ 在描述用例时，可以用文字来描述，也可以用其他图 形来描述，例如，顺序图等等。
UML（Unified Modeling Language）统一建模语言 已经成为描述面向对象软件系统的标准建模语言
常见的软件系统模型
▪ 活动图：表示一个过程或数据处理中所涉及的 活动
▪ 用例图：表示系统和它所处环境之间的交互 ▪ 时序图：表示参与者和系统之间以及系统各部
分之间的交互 ▪ 类图：表示系统中对象类以及这些类之间的联
什么是模型？
模型是系统的抽象视图，它忽略了系统 中的所有细节。辅助模型的开发能够反映系 统中不同的信息。
3
描画系统模型
▪ 系统模型描画在纸上，是平面的；但思维则是 多维的，需要从几个不同的视角出发：
1.从外部来看，对系统环境建模，即描述系统的“上 下文” 。
2.从交互上看，它是对系统与环境之间或是一个系统 各组成部分之间的交互建模。
▪ 名称：名称无疑应该表明用户的意图或用例的用途， 如“研究班招生”。
▪ 标识符 [可选]：唯一标识符，如 "UC1701"，在项目的 其他元素（如类模型）中可用它来引用这个用例。
▪ 说明：概述用例的几句话。 ▪ 参与者 [可选]：与此用例相关的参与者列表。尽管这
则信息包含在用例本身中，但在没有用例图时，它有 助于增加对该用例的理解。
13
5.2.1 用例模型
▪ 用例图用于定义系统的功能需求，它描述 了系统的参与者与系统提供的用例之间的 关系。
▪ 参与着可以是人，可以是另外一个系统。 ▪ 用例图仅仅从使用者的角度描述系统中的
信息
1 参与者
▪ 参与者（Actor）是系统外部
的一个实体（可以是任何的
事物或人），它以某种方式
参与了用例的执行过程。参
统外部的！！ 3. 说明外部要素与系统之间的关系；
10
上下文模型示例： MHC-PMS系统的上下文模型
5.2 交互建模
所有的系统都会涉及到交互，有可能是 用户交互，与用户的输入有关，有可能是正 在开发的系统与其它系统之间的交互，或者 是组成系统的各个组成部分之间交互。交互 图的描述是为了更好的识别用户的需求。
识别用例
▪ 识别用例最好的办法就是从分析系统的参 与者开始，考虑每个参与者是怎样使用系 统。使用这种策略的过程中可能会找出一 个新的参与者，这对完善整个系统建模很 有帮助。
识别用例时有用的几个问题
▪ 在识别用例的过程中，通过以下的几个问题可以 帮助识别用例：
▪ （1）特定参与者希望系统提供什么功能？ ▪ （2）系统是否存储和检索信息？如果是，这个行
Leabharlann Baidu
练习
▪ 识别“超市进销存管理系统”中的参与者
2 用例
▪ 用例是一组连续的操作，当用户使用系统来完成某个 过程时出现，它是外部可见的系统功能单元。通过将 这些不同功能单元的组合，就构成了对系统总体需求 的描述。
▪ 用例要点: 1.位于系统 --必须由系统运行 2.目标导向 --用例运行必须有所目的 3.止于边界 --可以观测到结果,并且是在边界和外部 有所交互的 4.用户观点 --参与者观测 5.粒度 --是一组有共同目标或者可以类聚的目标的 实例组成
系 ▪ 状态图：表示系统是如何响应内部和外部事件
的
▪ 静态建模 动态建模
5.1 上下文模型
上下文模型示出了要建模的系统在整个 环境中与其他系统和过程间的位置关系。上 下文模型定义了系统的边界。体系结构模型、 过程模型可以作为上下文模型。
7
上下文模型示例1：ATM系统
系统边界
ATM系统上下文
8
上下文模型是什么意思？
为由哪个参与者触发? ▪ （3）当系统改变状态时，通知参与者吗？ ▪ （4）存在影响系统的外部事件吗？ ▪ （5）是哪个参与者通知系统这些事件？（系统需
要什么样的输入输出）
用例识别练习
ATM自动柜员机系统是由计算机控制的 银行自动出纳系统，主要服务于活期储蓄， 实现客户自助服务的电子化设备。通过UML 对ATM自动取款机建模，实现查询余额、取 款、存款、转账、更改密码等业务，根据 需求还可以进一步扩展具体功能。
与者通过向系统输入或请求
系统输入某些事件来触发系
统的执行。参与者由他们参
与用例时所担当的角色来代
主角1
表。
识别参与者
参与者（Actor）是系统外部的一个实体，他们不是 系统的组成部分。回答如下问题，可以帮助建模人 员发现参与者。 ▪ 系统的主要客户是谁 ？ ▪ 谁借助于系统完成日常工作？ ▪ 谁来维护和管理系统，保证系统的正常运行？ ▪ 系统控制的硬件设置有那些？ ▪ 系统需要和其它系统进行交互吗？ ▪ 在预定的时刻，是否有预定的事件发生？ ▪ 系统从什么地方获取信息？
▪ 注意：上下文模型的意图在于说清“系统的环境 是什么”，说不清的（不确定的）就通过讨论来 逐渐明确。
所谓“系统的环境是什么”——即从系统外部对系统的 输入开始，直到系统处理之后对系统外部的响应，此过 程的结构化描述。
9
上下文模型的建模方法
▪ 具体的建模（描述）方法
1. 对系统命名，表示出确定的系统边界； 2. 标识系统外部的所有参与要素；——注意，是系
3.从结构上看，对系统的体系结构和系统处理的数据 的结构建模。
4.从行为上看，对系统的行为建模，即描述系统的动 态行为和它对事件的响应方式的建模。
4
常见的软件系统模型
▪ 上下文模型 ▪ 交互模型
1 用例建模，2 时序图
▪ 结构模型
1 类图，2 泛化，3 聚合
▪ 行为模型
1 数据驱动的建模，2 事件驱动模型
第五章 系统建模（System models）
1
学习引导
▪ 本章介绍一系列不同的系统模型，这些模型是在 需求工程和系统设计过程中必须建立有用工具。
▪ 主要内容：
理解如何用图形模型来表示软件系统； 理解不同类型的模型以及基本的系统建模角度，如上下
文、交互、结构和行为等； 统一建模语言（UML）中定义的符号及其建模应用；
▪ 用例与参与者之间的连线称为关系，关系也称 为关联或通信关联，它表示参与者与用例之间 的通信。一般情况下，不用带箭头的直线表示 信息流动的方向，因为信息流动是双向的。
▪ 如果使用箭头，则特意的表示信息的发起者或 接受者；
关系
主角1
用例1
3 用例描述
3 用例描述
▪ 在描述用例时，可以用文字来描述，也可以用其他图 形来描述，例如，顺序图等等。
UML（Unified Modeling Language）统一建模语言 已经成为描述面向对象软件系统的标准建模语言
常见的软件系统模型
▪ 活动图：表示一个过程或数据处理中所涉及的 活动
▪ 用例图：表示系统和它所处环境之间的交互 ▪ 时序图：表示参与者和系统之间以及系统各部
分之间的交互 ▪ 类图：表示系统中对象类以及这些类之间的联