第8章 用例分析.pptVIP

第8章 用例分析 “左右世界的人，必先左右自己。” ——古希腊哲学家：苏格拉底 分析的故事：正确结果来自正确分析 学习目标 掌握分析类的方法 学会分析对象行为模型 学会使用StarUml绘制时序图和协作图 8.1 面向对象分析 面向对象分析模型 用例模型：处于OOA模型核心的是“用例模型”（Use Case），简称“用例”。获得软件的需求后，软件分析员即可据此创建一组“场景”（Scenario），每个场景包含一个使用实例。从这些用例出发，进一步抽取和定义OOA模型的3种模型，即 类—对象模型：描述系统所涉及的全部类-对象，每个类-对象都通过属性、操作和写作者来进行进一步描述； 对象—关系模型：描述对象之间的静态关系，同时定义了系统中所有重要的消息路径，它也可以具体化到对象的属性、操作和协作者； 对象—行为模型：描述了系统的动态行为，即对复杂的状态下如何反映外界的事件。 面向对象分析完成下列内容： 1）发现和定义系统存在的类。 2）识别分析类。 3）定义交互行为，即对象行为模型。 8.2 识别分析类 分析类的来源：用例规约 分析类的角度： 系统与角色的边界； 系统使用的信息； 系统的控制逻辑。 8.2.1 什么是分析类 在面向对象的分析中，类代表了一组对象所共同拥有的属性和行为。在分析识别类中，根据分析角度的不同，将分析类划分为边界类、实体类和控制类。 边界类：表示参与者与系统之间的交互； 实体类：表示系统存储和管理的永久信息； 控制类：表示系统在运行过程中的业务控制逻辑。 这种划分的基本思想是将对象在系统中所承担的行为按照其作用和变化影响程度进行分类，将变化对系统结构的影响限制在一个相对明确的范围内。 需求分析的过程 1．边界类（Boundary） 边界类是用于描述外部参与者与系统之间的交互。一个系统可能有多种边界类： 用户界面类：用户和系统用户进行通信； 系统接口类：用户和其他软件系统进行通信； 设备接口类：为硬件设备提供接口。 边界类的表示方法 边界类在模型中有两种表示方法，如下图所示。一种是构造性boundary的类形式，另一种是图标形式。 2．控制类（Control） 控制类是用于封装一个或几个用例所特有的流程控制行为，通过它可建立系统的动态行为模型。它有效地分离了边界类对象和实体类对象，使系统更能承受边界的变更，它还将用例所特有的行为与实体类对象分离，使得实体类对象在用例和系统中具有更高的可复用性。 控制类的特点： 独立于环境，不随环境的变更而变更； 确定用例中的控制逻辑和事务； 在实体类的内部结构或行为发生变更时，也不会变更； 使用或规定若干实体类的内容，协调这些实体类的行为； 可能按不同的流程或方式执行。 控制类的表示 控制类在模型中有两种表示方法，如下图所示。一种是构造性control的类形式，另一种是图标形式。 3．实体类（Entity） 实体类是用于对必须存储的信息和相关的行为建模，其主要职责是存储和管理系统中的信息。它通常具有持久性，即他们的属性和关系需要长期保存，有时甚至在系统整个生命周期都存在。 实体类的表示 实体类在模型中有两种表示方法，如下图所示。一种是构造性entity的类形式，另一种是图标形式。 8.2.2 识别边界类 通常，一个参与者与一个用例之间的交互或者通信对应一个边界类。边界类信息收集是从参与者的角度考虑，而这些边界类信息将来可以被实体类和控制类所使用。下图示意了边界类识别的基本方法，也就是在每一对“用例—参与者”之间确定一个边界类。 识别边界类应注意以下几个问题： 边界类应关注参与者与用例之间交互的信息或者响应的事件，不要描述窗口组件等界面的组成元素； 在分析阶段，力求使用用户的术语描述界面； 边界类实例的生命周期不限于用例的事件流，如果两个用例同时与一个参与者交互，那么它们很可能会一边共用一个边界类，一边增加边界类的复用性。 8.2.3 识别控制类 控制类负责协调边界类和实体类，通常在现实世界中没有对应的事物，它负责接受边界类的信息，并将其分发给实体类。 控制类与用例存在着密切的关系，它在用例开始执行时创建，在用例结束时取消。一般来说，一个用例对应一个控制类，如下图所示。 识别控制类应当注意以下几个问题： 当用例比较复杂时，特别是在产生分支事件流的情况下，一个用例可以有多个控制类； 在有些情况下，用例事件流的逻辑结构十分简单，这时没有必要使用控制类，边界类可以实现用例的行为； 不同用例包含的任务之间存在着比较密切的联系，则这些用例可以使用一个控制类，其目的是复用相似部分以降低复杂