用例分析
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
类—对象模型：描述系统所涉及的全部类-对象，每个类-对 象都通过属性、操作和写作者来进行进一步描述； 对象—关系模型：描述对象之间的静态关系，同时定义了 系统中所有重要的消息路径，它也可以具体化到对象的属 性、操作和协作者； 对象—行为模型：描述了系统的动态行为，即对复杂的状 态下如何反映外界的事件。
用户
用例
外部系统
用户界面 图 7-6：识别边界类的示意图
外部系统接口
识别边界类应注意以下几个问题：
边界类应关注参与者与用例之间交互的信息或者响应的事件， 不要描述窗口组件等界面的组成元素； 在分析阶段，力求使用用户的术语描述界面；
边界类实例的生命周期不限于用例的事件流，如果两个用例同 时与一个参与者交互，那么它们很可能会一边共用一个边界类， 一边增加边界类的复用性。
识别控制类应当注意以下几个问题：
当用例比较复杂时，特别是在产生分支事件流的情况 下，一个用例可以有多个控制类； 在有些情况下，用例事件流的逻辑结构十分简单，这 时没有必要使用控制类，边界类可以实现用例的行为； 不同用例包含的任务之间存在着比较密切的联系，则 这些用例可以使用一个控制类，其目的是复用相似部 分以降低复杂性。
8.2.4 识别实体类
实体类通常是用例中的参与对象，对应 着现实世界中的“事物”，识别实体类需 要开发人员进一步理解应用领域，可以通 过分析用例描述和词汇表等发现备选的实 体对象。
实体类的因素包括以下几点： 人员 组织 物品 设备 事件 表格
识别实体类应当注意的以下几个问题：
1）实体类的识别质量很大程度上取决于分析人员书写 文档的风格和质量； 2）自然语言是不精确的，因此在分析自然语言描述时， 应该尽量使描述文档中的一些措辞规范化，以弥补这种不 足； 3）在自然语言描述中，名词可以对应类、属性或同义
词等多种类型。
8.2.5 用例分析示例
修改帖子
边界类的表示方法
边界类在模型中有两种表示方法，如下 图所示。一种是构造性<<boundary>>的类 形式，另一种是图标形式。
<<boundary>> 边界类名称
边界类名称
图7-3：边界类的表示方法
2．控制类（Control）
控制类是用于封装一个或几个用例所特 有的流程控制行为，通过它可建立系统的 动态行为模型。它有效地分离了边界类对 象和实体类对象，使系统更能承受边界的 变更，它还将用例所特有的行为与实体类 对象分离，使得实体类对象在用例和系统 中具有更高的可复用性。
<<entity>> 实体类名称
实体类名称
图7-5：实体类的表示方法
8.2.2 识别边界类
通常，一个参与者与一个用例之间的交互或者通信 对应一个边界类。边界类信息收集是从参与者的角度考虑， 而这些边界类信息将来可以被实体类和控制类所使用。下 图示意了边界类识别的基本方法，也就是在每一对“用 例—参与者”之间确定一个边界类。
分析的故事：正确结果来自正确分析
学习目标
掌握分析类的方法 学会分析对象行为模型 学会使用StarUml绘制时序图和协作图
8.1 面向对象分析
面向对象分析模型
、 协 作 者
性 、 操
类-对象模型
对象-行为 模型
作
属
用例模型 对象-关系模 型
用例模型：处于OOA模型核心的是“用例模型”（Use Case），简称“用例”。获得软件的需求后，软件分析员 即可据此创建一组“场景”（Scenario），每个场景包含 一个使用实例。从这些用例出发，进一步抽取和定义OOA 模型的3种模型，即
控制类的特点：
独立于环境，不随环境的变更而变更； 确定用例中的控制逻辑和事务； 在实体类的内部结构或行为发生变更时， 也不会变更； 使用或规定若干实体类的内容，协调这些 实体类的行为； 可能按不同的流程或方式执行。
控制类的表示
控制类在模型中有两种表示方法，如下 图所示。一种是构造性<<control>>的类形 式，另一种是图标形式。
边界类：表示参与者与系统之间的交互； 实体类：表示系统存储和管理的永久信息； 控制类：表示系统在运行过程中的业务控制逻辑。
这种划分的基本思想是将对象在系统中所承担 的行为按照其作用和变化影响程度进行分类，将 变化对系统结构的影响限制在一个相对明确的范 围内。
需求分析的过程
理解用例模型 识别实体类
识别分析类
识别边界类
识别控制类 定义交互行为
评审分析模型 图7-2：需求分析过程
1．边界类（Boundary）
边界类是用于描述外部参与者与系统之间的交互。 一个系统可能有多种边界类： 用户界面类：用户和系统用户进行通信； 系统接口类：用户和其他软件系统进行通信； 设备接口类：为硬件设备提供接口。
面向对象分析完成下列内容： 1）发现和定义系统存在的类。
2）识别分析类。
3）定义交互行为，即对象行为模型。
8.2 识别分析类
分析类的来源：用例规约
分析类的角度：
系统与角色的边界； 系统使用的信息； 系统的控制逻辑。
Fra Baidu bibliotek.2.1 什么是分析类
在面向对象的分析中，类代表了一组对象所 共同拥有的属性和行为。在分析识别类中，根据 分析角度的不同，将分析类划分为边界类、实体 类和控制类。
<<control>> 控制类名称
控制类名称
图7-4：控制类的表示方法
3．实体类（Entity）
实体类是用于对必须存储的信息和相关 的行为建模，其主要职责是存储和管理系 统中的信息。它通常具有持久性，即他们 的属性和关系需要长期保存，有时甚至在 系统整个生命周期都存在。
实体类的表示
实体类在模型中有两种表示方法，如下 图所示。一种是构造性<<entity>>的类形式， 另一种是图标形式。
8.2.3 识别控制类
控制类负责协调边界类和实体类，通常在现实世界中没有 对应的事物，它负责接受边界类的信息，并将其分发给实 体类。 控制类与用例存在着密切的关系，它在用例开始执行时创 建，在用例结束时取消。一般来说，一个用例对应一个控 制类，如下图所示。
用户
用例
外部系统
控制逻辑 图 7-7：识别控制类的示意图
用户
用例
外部系统
用户界面 图 7-6：识别边界类的示意图
外部系统接口
识别边界类应注意以下几个问题：
边界类应关注参与者与用例之间交互的信息或者响应的事件， 不要描述窗口组件等界面的组成元素； 在分析阶段，力求使用用户的术语描述界面；
边界类实例的生命周期不限于用例的事件流，如果两个用例同 时与一个参与者交互，那么它们很可能会一边共用一个边界类， 一边增加边界类的复用性。
识别控制类应当注意以下几个问题：
当用例比较复杂时，特别是在产生分支事件流的情况 下，一个用例可以有多个控制类； 在有些情况下，用例事件流的逻辑结构十分简单，这 时没有必要使用控制类，边界类可以实现用例的行为； 不同用例包含的任务之间存在着比较密切的联系，则 这些用例可以使用一个控制类，其目的是复用相似部 分以降低复杂性。
8.2.4 识别实体类
实体类通常是用例中的参与对象，对应 着现实世界中的“事物”，识别实体类需 要开发人员进一步理解应用领域，可以通 过分析用例描述和词汇表等发现备选的实 体对象。
实体类的因素包括以下几点： 人员 组织 物品 设备 事件 表格
识别实体类应当注意的以下几个问题：
1）实体类的识别质量很大程度上取决于分析人员书写 文档的风格和质量； 2）自然语言是不精确的，因此在分析自然语言描述时， 应该尽量使描述文档中的一些措辞规范化，以弥补这种不 足； 3）在自然语言描述中，名词可以对应类、属性或同义
词等多种类型。
8.2.5 用例分析示例
修改帖子
边界类的表示方法
边界类在模型中有两种表示方法，如下 图所示。一种是构造性<<boundary>>的类 形式，另一种是图标形式。
<<boundary>> 边界类名称
边界类名称
图7-3：边界类的表示方法
2．控制类（Control）
控制类是用于封装一个或几个用例所特 有的流程控制行为，通过它可建立系统的 动态行为模型。它有效地分离了边界类对 象和实体类对象，使系统更能承受边界的 变更，它还将用例所特有的行为与实体类 对象分离，使得实体类对象在用例和系统 中具有更高的可复用性。
<<entity>> 实体类名称
实体类名称
图7-5：实体类的表示方法
8.2.2 识别边界类
通常，一个参与者与一个用例之间的交互或者通信 对应一个边界类。边界类信息收集是从参与者的角度考虑， 而这些边界类信息将来可以被实体类和控制类所使用。下 图示意了边界类识别的基本方法，也就是在每一对“用 例—参与者”之间确定一个边界类。
分析的故事：正确结果来自正确分析
学习目标
掌握分析类的方法 学会分析对象行为模型 学会使用StarUml绘制时序图和协作图
8.1 面向对象分析
面向对象分析模型
、 协 作 者
性 、 操
类-对象模型
对象-行为 模型
作
属
用例模型 对象-关系模 型
用例模型：处于OOA模型核心的是“用例模型”（Use Case），简称“用例”。获得软件的需求后，软件分析员 即可据此创建一组“场景”（Scenario），每个场景包含 一个使用实例。从这些用例出发，进一步抽取和定义OOA 模型的3种模型，即
控制类的特点：
独立于环境，不随环境的变更而变更； 确定用例中的控制逻辑和事务； 在实体类的内部结构或行为发生变更时， 也不会变更； 使用或规定若干实体类的内容，协调这些 实体类的行为； 可能按不同的流程或方式执行。
控制类的表示
控制类在模型中有两种表示方法，如下 图所示。一种是构造性<<control>>的类形 式，另一种是图标形式。
边界类：表示参与者与系统之间的交互； 实体类：表示系统存储和管理的永久信息； 控制类：表示系统在运行过程中的业务控制逻辑。
这种划分的基本思想是将对象在系统中所承担 的行为按照其作用和变化影响程度进行分类，将 变化对系统结构的影响限制在一个相对明确的范 围内。
需求分析的过程
理解用例模型 识别实体类
识别分析类
识别边界类
识别控制类 定义交互行为
评审分析模型 图7-2：需求分析过程
1．边界类（Boundary）
边界类是用于描述外部参与者与系统之间的交互。 一个系统可能有多种边界类： 用户界面类：用户和系统用户进行通信； 系统接口类：用户和其他软件系统进行通信； 设备接口类：为硬件设备提供接口。
面向对象分析完成下列内容： 1）发现和定义系统存在的类。
2）识别分析类。
3）定义交互行为，即对象行为模型。
8.2 识别分析类
分析类的来源：用例规约
分析类的角度：
系统与角色的边界； 系统使用的信息； 系统的控制逻辑。
Fra Baidu bibliotek.2.1 什么是分析类
在面向对象的分析中，类代表了一组对象所 共同拥有的属性和行为。在分析识别类中，根据 分析角度的不同，将分析类划分为边界类、实体 类和控制类。
<<control>> 控制类名称
控制类名称
图7-4：控制类的表示方法
3．实体类（Entity）
实体类是用于对必须存储的信息和相关 的行为建模，其主要职责是存储和管理系 统中的信息。它通常具有持久性，即他们 的属性和关系需要长期保存，有时甚至在 系统整个生命周期都存在。
实体类的表示
实体类在模型中有两种表示方法，如下 图所示。一种是构造性<<entity>>的类形式， 另一种是图标形式。
8.2.3 识别控制类
控制类负责协调边界类和实体类，通常在现实世界中没有 对应的事物，它负责接受边界类的信息，并将其分发给实 体类。 控制类与用例存在着密切的关系，它在用例开始执行时创 建，在用例结束时取消。一般来说，一个用例对应一个控 制类，如下图所示。
用户
用例
外部系统
控制逻辑 图 7-7：识别控制类的示意图