软件工程实验分析与设计v1.0)

《软件工程实验分析与设计v1.0)》由会员分享，可在线阅读，更多相关《软件工程实验分析与设计v1.0)（35页珍藏版）》请在金锄头文库上搜索。

1、第四章 面向对象的软件分析基础实验 67 第四章第四章 面向对象的软件分析面向对象的软件分析基础基础实验实验 4.1 面向对象的软件分析原则面向对象的软件分析原则和步骤和步骤 OOA（面向对象的分析）模型由 5 个层次（主题层、对象类层、结构层、属性层和服务层）和 5 个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。 在面向对象分析中，主要由对象模型、动态模型和功能模型组成： 对象模型：对用例模型进行分析，把系统分解成互相协作的分析类，通过类图、对象图描述对象、 对象的属性、对象间的关系，是系统的静态模型。 动态模型：描述系统的动态行为,通过时序图、协作图描述对象的交互，以揭

2、示对象间如何协作来 完成每个具体的用例，单个对象的状态变化、动态行为可以通过状态图来表达。 功能模型：描述软件系统的数据处理功能，最直接地反映了用户对系统的需求。通常功能模型由 一组数据流图或一组用例图组成，其中的数据处理功能可以用 IPO 图（表）、PDL 语言等多种方式进 一步描述。 面向对象分析的主要原则有： （1）抽象原则：从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征，就叫 作抽象。抽象是形成概念的必须手段。 抽象原则有两方面的意义：第一，尽管问题域中的事物是很复杂的，但是分析员并不需要了解和 描述它们的一切，只需要分析研究其中与系统目标有关的事物及其本质性特征。第二

3、，通过舍弃个体 事物在细节上的差异，抽取其共同特征而得到一批事物的抽象概念。 抽象是面向对象方法中使用最为广泛的原则。抽象原则包括过程抽象和数据抽象两个方面。 过程抽象是指，任何一个完成确定功能的操作序列，其使用者都可以把它看作一个单一的实体， 尽管实际上它可能是由一系列更低级的操作完成的。数据抽象是根据施加于数据之上的操作来定义数 据类型，并限定数据的值只能由这些操作来修改和观察。数据抽象是 OOA 的核心原则。它强调把数据 （属性）和操作（服务）结合为一个不可分的系统单位（即对象），对象的外部只需要知道它做什么， 而不必知道它如何做。 （2）封装原则。封装就是把对象的属性和服务结合为一个不

4、可分的系统单位，并尽可能隐蔽对 象的内部细节。 （3）继承原则：特殊类的对象拥有的其一般类的全部属性与服务，称作特殊类对一般类的继承。 在 OOA 中运用继承原则，就是在每个由一般类和特殊类形成的一般特殊结构中，把一般类的 对象实例和所有特殊类的对象实例都共同具有的属性和服务，一次性地在一般类中进行显式的定义。 在特殊类中不再重复地定义一般类中已定义的东西，但是在语义上，特殊类却自动地、隐含地拥有它 的一般类（以及所有更上层的一般类）中定义的全部属性和服务。继承原则的好处是：使系统模型比 较简练也比较清晰。 （4）分类原则：就是把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。

5、 分类原则实际上是抽象原则运用于对象描述时的一种表现形式。 （5）聚合原则：又称组装，其原则是：把一个复杂的事物看成若干比较简单的事物的组装体， 从而简化对复杂事物的描述。 （6）关联原则：是人类思考问题时经常运用的思想方法：通过一个事物联想到另外的事物。能 使人发生联想的原因是事物之间确实存在着某些联系。 第四章 面向对象的软件分析基础实验 68 （7）消息通信原则：这一原则要求对象之间只能通过消息进行通信，而不允许在对象之外直接 地存取对象内部的属性。 通过消息进行通信是由于封装原则而引起的。 在 OOA 中要求用消息连接表示 出对象之间的动态联系。 （8）粒度控制原则：一般来讲，人在面对

6、一个复杂的问题域时，不可能在同一时刻既能纵观全 局，又能洞察秋毫。因此需要控制自己的视野：考虑全局时，注意其大的组成部分，暂时不详察每一 部分的具体的细节；考虑某部分的细节时则暂时撇开其余的部分。这就是粒度控制原则。 （9）行为分析原则：现实世界中事物的行为是复杂的。由大量的事物所构成的问题域中各种行 为往往相互依赖、相互交织。 在用 OOA 具体地分析一个事物时，大致上遵循如下五个基本步骤： 第一步，确定对象和类。这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处 理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述，它包括如何在一 个类中建立一个新对象的描述

7、。 第二步，确定结构（structure）。结构是指问题域的复杂性和连接关系。类成员结构反映了泛化- 特化关系，整体-部分结构反映整体和局部之间的关系。 第三步，确定主题（subject）。主题是指事物的总体概貌和总体分析模型。 第四步，确定属性（attribute）。属性就是数据元素，可用来描述对象或分类结构的实例，可在图 中给出，并在对象的存储中指定。 第五步，确定方法（method）。方法是在收到消息后必须进行的一些处理方法：方法要在图中定 义，并在对象的存储中指定。对于每个对象和结构来说，那些用来增加、修改、删除和选择一个方法 本身都是隐含的（虽然它们是要在对象的存储中定义的，但并不在

8、图上给出），而有些则是显示的。 4.2 面向对象的软件分析主要过程面向对象的软件分析主要过程 4.2.1 面向对象建模面向对象建模 面向对象模型是一个类（包括其属性和行为）、对象（类的实例）、类和对象关系的定义集。例 如以公共自行车租赁系统为例，只要开通公交卡、城市通或者市民卡（这里统称为卡）中的公共自行 车租用功能，并使得卡内有足够押金，即可在就近租车点通过刷卡进行自行车的租用。 其中，在公共自行车租赁系统中的对象主要有：系统用户（包括管理员、操作员和租借用户）、 卡、自行车、租借记录表、服务站、车位等。如下图 4-1 所示为系统中这些对象之间的关系图： 图 4-1 对象关系图 第四章 面向

9、对象的软件分析基础实验 69 经分析，公共自行车租赁系统各个对象之间有如下关联： （1）一个租借用户可以拥有多张不同种类的卡； （2）每张卡都设有一个电子钱包，负责管理账户金额； （2）每张卡每次只能租用一辆自行车，卡信息将与被租用自行车的信息相关联； （3）操作员负责人工租赁服务和自行车管理，操作员可以在不同的服务站进行服务； （4）一个服务站具有多个车位和多辆自行车，每个车位对应一辆自行车停放； （5）租借记录表中包括所有卡的租用记录情况，包括具体的用户、租用的自行车以及其他相关 信息。 （6）管理员、操作员和租借用户都是系统用户，他们之间存在继承关系。其中，系统用户是父 类，管理员、操作

10、员和租借用户均为子类； （7）服务站信息同时也包含所有的车位信息，这是因为车位点被设置在服务站中。 在对系统包含的对象及对象间的总体关联进行分析之后，也要单独对每个对象进行建模，确定每 个对象所具有的属性。例如对于系统用户类，应具有编号、姓名、出生日期、电话、性别等属性，而 管理员在继承这些属性的同时，还应有登录密码和权限属性；操作员也具有登录权限和权限属性，他 与管理员的不同在于这两个对象应具有不同的具体方法；租借用户继承所有系统用户属性的同时，应 具有自行车编号属性，用于同所租用的自行车相关联。如下图 4-2 所示： 图 4-2 用户关系图 4.2.2 用例建模用例建模 以公共自行车租赁系

11、统为例，系统参与者主要有租借用户、自行车管理员和操作员，租借用户可 以通过刷卡方式租用自行车，归还自行车；管理员负责管理用户的各种信息、基础设施信息管理以及 工作人员的相关信息；操作员则负责自行车调度，必要时向租借用户提供人工租赁服务。 下面给出涉及到租借用户和操作员的部分用例，见图 4-3： 第四章 面向对象的软件分析基础实验 70 图 4-3 部分用例图 表 4-1 租用自行车用例场景描述 用例名称 租用自行车 主要参与者 租借用户 A、操作员 D 涉众及其关注点 租借用户 A：希望能够便捷地租到自行车。 操作员 D：希望能够快速、方便地帮助租借用户完成人工租车服务。 公共自行车服务公司：

12、希望用户能够顺利租用到服务站的自行车；希望在租 用高峰期系统的租车服务工作能够稳定运行； 希望自行车数量能够尽量与用户 的租用需求相符； 在租用高峰期操作员通过人工租赁服务减轻系统的租车服务 压力。 前置条件 用户 A 持有已开通租用自行车服务的市民卡、公交卡或城市通卡。 操作员 D 具有提供人工租车服务权限。 后置条件 租借用户 A 可以顺利租得一辆处于空闲的自行车。 基本流程 1. 用户 A 携带卡到就近服务站 B。 2. 用户 A 将卡置于服务站 B 中任意一辆空闲自行车旁的刷卡处。 3. 系统通过设备感应卡内的信息。 4. 系统核实该卡是否开通服务，并且确认该卡处于尚未租车状态。 5.

13、 查看用户 A 账户余额是否足够支付保证金，若能够支付，则扣除保证金。 6. 锁止器解锁并发出声响，用户 A 可以将自行车推出。 7. 借车操作完成。 扩展： a. 用户卡发生故障，无法进行刷卡操作。 1)用户 A 携带卡到服务站的自助服务器 C 上选择异常卡处理操作。 (1)用户 A 将卡置于刷卡区； (2)自助服务器 C 显示所有服务项； (3)用户 A 选择异常卡处理项； (4)系统进行异常卡处理工作。 (5)异常卡修复工作完成，若用户 A 结束自助操作则取回卡，否则回到(2) 2)用户 A 请求操作员 D 提供帮助或者直接在操作员 D 处办理一张新卡。 第四章 面向对象的软件分析基础实

14、验 71 b. 用户 A 携带的卡尚未开通租车服务功能。 1)用户可以请求操作员 D 帮助开通服务。 (1)用户 A 将卡交给操作员 D； (2)操作员 D 通过 POS 机进行租赁服务开通； (3)操作员 D 将卡归还给用户 A； (4)用户A使用已经开通租赁服务的卡重新刷卡租车或者请求操作员D直 接进行人工租车。 c. 服务站 B 没有可供租赁的空闲车辆。 1)用户 A 可以前往下一个就近站点。 2)等待调度自行车运往当前自行车服务站。 d. 账户余额不足以支付保证金。 1)用户 A 需前往就近充值服务点，对卡内电子钱包进行充值。 e. 自行车故障或损坏，无法正常行驶。 1)在 2 分钟内

15、快速还车。 (1) 用户 A 将自行车通过正常方式归还； (2) 系统通过故障判断机制记录快借快还的自行车，自动提出报修； (3) 用户 A 重新进行借车。 2)若站点具有维修人员，请求维修人员维修。 此外，若要体现特定场景内交流的图形化表示还可以使用活动图或泳道图分层描述。如图 4-4 所 示为租用自行车的活动图，图 4-5 为租用自行车的泳道图。两图中均有同步条出现，这是因为当系统 顺利将租赁保证金扣除后，一方面系统要修改租赁状态以及对站点、自行车数据的更新，另一方面要 在租借记录表中新添加一条用户的租借记录，最后系统发出指令解锁并提示用户推出自行车。 第四章 面向对象的软件分析基础实验

16、72 图 4-4 活动图 第四章 面向对象的软件分析基础实验 73 图 4-5 泳道图 4.2.3 领域模型建模领域模型建模 领域模型实际上是一个比较完整的业务模型。在建立领域模型时我们要根据具体问题的描述和在 上一章节中的用例描述，得到潜在的分析类。分析类总是能够符合边界类、控制类或者实体类中的某 一种。比如，在如图 4-6 所示的租借管理相关用例中，可以得到下列分析类： (1) 控制类： 租用自行车：负责租用自行车过程中系统特定指令和动作； 归还自行车：负责归还自行车过程中系统特定指令和动作； 查询租借记录，负责在用户查询时的请求和返回业务的相关指令和数据流。 (2) 实体类： 租借记录表：记录用户每一次的租借和归还详细记录； 用户卡账户：存储用户状态信息和余额信息； 自行车信息：保存自行车信息； 服务站信息：保存服务站信息包括站点车位信息； 电子钱包：保管账户金额信息。 (3) 边界类： 感应卡接口：负责感应和获取刷卡动作产生的信息； 用户查询界面：用户进行查询记录时与系统交流的媒介。 由上述分析类，可以得到租借管理用例相关类图，如下图 4-6 所示： 第四章 面