软件工程

12:10:55
37
OOA向OOD的过渡

分析类演变为设计元素 职责演变为设计元素的行为
12:10:55
38

4. 绘制状态图 用例行为比较复杂，并且分散到不同的事件序 列中，这时就需要为这个类创建一个状态图

针对一个类的状态变化 研究该类的动态行为
12:10:55
39
6.2.3 建立对象—关系模型

分析类的合并

12:10:55
40
链与关联的对应关系
PerformResponsibility
协作图
:Client
:Supplier
链
Client Supplier
类图
Client
0..* 0..* Prime suppliers
Supplier
PerformResponsibility()
关联
12:10:55
29
查找分析类
②为每个用例设置一个控制类
最简单的查找方法…………..，分解，合并
12:10:55 30
查找分析类
③确定相关的各个实体（包括属性与方法） 提取实体信息 如果一个拟建的实体类 A仅被另一个实体类 B 引用，可考虑 将A作为实体类B的属性。 如果某一实体类可能被多个类引用，或者该实体信息具有 明显的行为特征，则通常将其定义为一个独立的实体类

复杂问题（大型系统）的对象模型由下述五个 层次组成：
12:10:55
8
①类和对象
定义类和对象，将分析与待开发 软件对应的各个现实世界有实体， 并从中抽象出类和对象
②属性
定义属性，为类/对象层中抽取 出来的各个类和对象设计静态属 性和它们之间的关系
五个层次的 问题域模型 ④结构
定义对象和类之间的层次 结构关系，常见的关系有 包含、继承和关联
12:10:55 19
12:10:55
20
识别界面类
用户界面类 关注要呈现给用户的信息是什么 不要陷入UI的设计细节 系统和设备接口类 关注必须定义的协议是什么 不要关注协议是如何实现的 关注职责而不是细节

12:10:55
21
控制类
用于封装一个或几个用例所特有的流程控制行 为，通过它可建立系统的动态行为模型。有效地 分离了边界类对象与实体类对象。 只有当用例的事件流比较复杂并具有可以独立 于系统的接口（边界类）或者存储信息（实体类） 的动态行为时，才需要控制类。典型的有事务管 理器、资源协调器和错误处理器等
12:10:55
5

OOA的优点
（1）同时加强了对问题空间和软件系统的理解； （2）改进包括用户在内的与软件分析有关的各类人 员之间的交流； （3）对需求的变化具有较强的适应性； （4）很好地支持软件复用； （5）确保从需求模型到设计模型的一致性。


分析模型的特点
全面覆盖软件的功能需求 分析模型与软件的实现无关 （是一种概念模型） 分析模型的表述方法与所采用的分析技术有关
第6章 面向对象分析

6.1 软件分析概述 6.2 面向对象分析建模 6.3 面向对象分析示例
12:10:55
1
1. 软件分析概述

软件需求与软件分析 软件需求：用户角度，注重软件外在表现 软件分析：开发者角度，注重软件内部逻辑 结构
12:10:55
2

面向对象软件分析(对比：结构化分析) (1)OOA的主要任务 a)理解用户需求
学生
课程表
课程目录
12:10:55 31
6.2.2 建立对象—行为模型
强调动态行为 问题：UML建模中常见的动态图有哪些？ 动态图将用例的动态行为分派到分析类，这是向 OOD过渡的关键
12:10:55
32
小复习 ：OOA的典型步骤

P140


需求理解 定义类和对象 标识对象的属性和操作 标识类的结构与层次 建立对象-行为模型 建立对象-关系模型
12:10:55 23
12:10:55
24
识别控制类


封装用例的事件控制流程 控制类应当具备合适的粒度，并承担内聚的控 制逻辑 划分控制类


将性质不同的控制逻辑封装到分离的控制类中 将(逻辑复杂的)主事件流和可选/异常事件流封装到 不同的控制类中
12:10:55
25
实体类
用于对必须存储的信息和相关行为建模的类。 用于保存和管理系统中的有关信息 。通常都是永 久性的，它们所具有的属性和关系是长期需要的， 有时甚至在系统的整个生存期都需要。 一个实体对象通常不是某个用例实现所特有的； 有时，一个实体对象甚至不专用于系统本身。 其属性和关系的值通常由参与者决定。实体对象 是独立于环境的。
primaryCourses 0..4
<<entity>> CourseOffering
12:10:55
42
分析类的合并
12:10:55
43
源自文库
12:10:55
44
7. 需求建模示例—网上购物系统



当今，网上购物已成为一种时尚。本示例作为WEB 应用的一 例，主要为普通购物用户和管理员服务。 普通购物用户在使用本系统的购物功能前，必须先注册账号。 在注册页面中填写个人信息，如使用本系统的账号名和密码, 联系地址等。 在提交表单、完成注册后，系统将保存信息，以方便管理员 管理用户信息、联系用户。 如果用户已经在系统中注册过，可以在登录页面输入账号名 和密码。如果密码正确，用户就可以购物，否则只能做一般 的页面浏览。
12:10:55
10
3. OOA模型在软件开发中的地位
软件需求模型
OOA
分析模型
OOD
设计模型
OOP
实现模型
OOT
12:10:55
软件成品
11
12:10:55
12
6.2 面向对象分析建模

基于用例的面向对象分析方法 回顾需求阶段产生的用例规约，补充必要的详 细信息； 研究用例的事件流，将用例的职责分配给若干 分析类； 基于这些职责分配以及分析类之间的协作，即 可开始为分析类间的关系建模了 一旦分析了用例，就需要查看确定的类，确保 它们被详尽地描述 确保分析模型各个部分之间的一致
12:10:55 16
三种分析类
边界类 实体类 系统边界 系统信息
控制类
协调用例行为
12:10:55
17
边界类
提供了对参与者或外部系统交互协议的接口,它将 系统和外界的变化隔离。 ①用户界面类 ②系统接口类 ③设备接口类
12:10:55
18
边界类
边界类是系统内部元素与参与者间的沟通桥梁: 转换和翻译交互事件—对内，将外界不同格式的事 件和信息转换为内部能够识别的格式，并触发控制类 对象(或实体时象)来响应它们;对外，则做类似的反向 操作; 变更对外的表示内容—在内部状态(特别是外界关注 的信息)发生变化时，向外部通知或更新表示内容。 常见的边界类对象有:GUI界面、系统(通讯协议)接 口、设备(I/0)接口等。
功能模型 （静态）
对象关系模型
类/对象 模型
以用例模 型 为主体的 需求模型 对象-行为模型
行为模型 （动态）
12:10:55
scenario
4
面向对象软件分析

OOA的模型 需求模型: 以用例模型为主体。 类/对象模型：通过属性、操作和协作者 对象-关系模型：静态关系，消息路径 对象-行为模型：动态关系，对象间协作与 响应消息

12:10:55
22
控制类所提供的行为具有的特点： ①独立于环境，不随环境改变而改变 ②确定用例中的控制逻辑（事件顺序和事务） ③在实体类的内部结构或行为发生变更的情况下， 几乎不会变更。 ④使用或规定若干实体类的内容，因此需要协调 这些实体类的行为。 ⑤不是每次被激活后都以同样的方式执行（事件 流具有多种状态）。
6
12:10:55
6.1.2 面向对象分析模型



Booch方法 Coad/Yourdon方法 Jocobson方法（OOSE方法） Rambaugh方法（OMT方法） Wirfs-Brock方法 RDD方法 VMT方法
12:10:55
7
1.典型的五层次模型(Coad/Yourdong)
12:10:55
15



对象的分析设计最后都要抽象并归结到类上，对 象的行为归类在实际建模操作中主要是进行类的 分析; 这些工作将在分析层面来展开的，分析类是对系 统中设计类和子系统的一种抽象，一个分析类往 往代表了一批负有类似职责的设计类;分析类用于 描述问题域而非设计具体解决方案; 边界类、控制类和实体类等划分实质上是类在用 例实现中充当不同角色的体现。

分析类的属性

分析类本身具有的信息 属性名称是一个名词,属性类型是简单的数据类型, 属性设置是粗略的 通过关联可以找到其他分析类 协作图中,链与关联的对应关系

分析类的关联


分析类图


表现分析类及其关系 VOPC( view of participating classes)
每个分析类都代表一个明确定义的概念，具有不相重叠的职 责
⑤主题（子系
统） 定义若干个主题， 把有关的对象分 别划归不同的主 题，每个主题构 成一个子系统
③服务（方法）
定义对象和类的动态 属性以及对象之间的 消息通信
12:10:55
9
9
2. OOA的共同特征

共同特征


OOA建模步骤

类和类层次的表示 建立对象-关系模型 建立对象-行为模型 需求理解 定义类和对象 标识对象的属性和操作 标识类的结构和层次 建立对象---关系模型 建立对象---行为模型 评审OOA模型
1:CreateSchedule()2:GetCourseOffering()
3:GetCourseOffering
(forSemester)
4:GetCourseOfferings()
5:DisplayCourseOffering ()
6:DisplayBlankSchedule()
7: Select 4 PrimaryAnd 2

全面地理解和分析用户需求 明确所开发的软件系统的职责 形成文件并规范地加以表述 标识类 定义属性和方法 刻画类的层次 表示对象以及对象之间的关系 为对象进行建模
3
b)进行分析，提取类和对象，并结合分析进行建模

12:10:55
面向对象分析模型
数据模型 （静态）
属性、操作、协作者
AlternateOfferings()
8:CreateScheduleWithOfferings() 9:CreateWithOfferings()
10:AddSchedule(Schedule)
选课用例创建课表事件流的时序图
2.绘制出选课用例创建课表事件流的协作图
12:10:55
36

3.为分析类分配职责（消息的接收者）
6.2.2 建立对象—行为模型
根据用例规约中的事件流,绘制用例动态图 1、时序图或者协作图 2、状态图
12:10:55
34
:Student
:RegisterForCoursesFor m
:RegistrationController
:CourseCatalogSystem
:Schedule
:Student :CourseCatalog
12:10:55 41
选课用例的参与类图
<<boundary>> RegisterForCoursesForm 1 1 0..1 <<control>> RegistrationController
<<entity>> Student 1
currentSchedule 0..1 <<entity>> Schedule 0..* 0..*

12:10:55
26
12:10:55
27
识别实体类

使用用例的事件流作为输入 用例中的关健抽象 传统的，名词过滤法


划出用例事件流中的名词条款 去掉重复的候选者 去掉含糊的候选者 去掉参与者 去掉属性 去掉操作
28
12:10:55
2.查找分析类
①为每对参与者/用例确定一个边界类
13
12:10:55
6.2.1 识别与确定分析类


为用例规约补充必要的详细信息，因为用例规 约仅从用户角度对每个用例进行说明。而现在 需要的是从内部角度观察系统响应的说明 通常从文字说明的软件需求过渡到图形说明的 分析模型，是一个渐近的过程。
12:10:55
14
6.2.1 识别与确定分析类

1. 分析类的类型 边界类<<boundary>> :负责系统与外界的通讯 与交通 用户界面 系统接口 硬件接口 控制类<< control>>:负责协调、调度、处理事 务并控制系统内部其它对象的行为 实体类<<entity>>：负责承担系统中需要持久化 的信息及其关联的行为