搜索
第四章面向对象的软件分析基础实验67第四章面向对象的软件分析基础实验4.1面向对象的软件分析原则和步骤OOA（面向对象的分析）模型由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。在面向对象分析中，主要由对象模型、动态模型和功能模型组成：对象模型：对用例模型进行分析，把系统分解成互相协作的分析类，通过类图、对象图描述对象、对象的属性、对象间的关系，是系统的静态模型。动态模型：描述系统的动态行为,通过时序图、协作图描述对象的交互，以揭示对象间如何协作来完成每个具体的用例，单个对象的状态变化、动态行为可以通过状态图来表达。功能模型：描述软件系统的数据处理功能，最直接地反映了用户对系统的需求。通常功能模型由一组数据流图或一组用例图组成，其中的数据处理功能可以用IPO图（表）、PDL语言等多种方式进一步描述。面向对象分析的主要原则有：（1）抽象原则：从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征，就叫作抽象。抽象是形成概念的必须手段。抽象原则有两方面的意义：第一，尽管问题域中的事物是很复杂的，但是分析员并不需要了解和描述它们的一切，只需要分析研究其中与系统目标有关的事物及其本质性特征。第二，通过舍弃个体事物在细节上的差异，抽取其共同特征而得到一批事物的抽象概念。抽象是面向对象方法中使用最为广泛的原则。抽象原则包括过程抽象和数据抽象两个方面。过程抽象是指，任何一个完成确定功能的操作序列，其使用者都可以把它看作一个单一的实体，尽管实际上它可能是由一系列更低级的操作完成的。数据抽象是根据施加于数据之上的操作来定义数据类型，并限定数据的值只能由这些操作来修改和观察。数据抽象是OOA的核心原则。它强调把数据（属性）和操作（服务）结合为一个不可分的系统单位（即对象），对象的外部只需要知道它做什么，而不必知道它如何做。（2）封装原则。封装就是把对象的属性和服务结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。（3）继承原则：特殊类的对象拥有的其一般类的全部属性与服务，称作特殊类对一般类的继承。在OOA中运用继承原则，就是在每个由一般类和特殊类形成的一般—特殊结构中，把一般类的对象实例和所有特殊类的对象实例都共同具有的属性和服务，一次性地在一般类中进行显式的定义。在特殊类中不再重复地定义一般类中已定义的东西，但是在语义上，特殊类却自动地、隐含地拥有它的一般类（以及所有更上层的一般类）中定义的全部属性和服务。继承原则的好处是：使系统模型比较简练也比较清晰。（4）分类原则：就是把具有相同属性和服务的对象划分为一类，用类作为这些对象的抽象描述。分类原则实际上是抽象原则运用于对象描述时的一种表现形式。（5）聚合原则：又称组装，其原则是：把一个复杂的事物看成若干比较简单的事物的组装体，从而简化对复杂事物的描述。（6）关联原则：是人类思考问题时经常运用的思想方法：通过一个事物联想到另外的事物。能使人发生联想的原因是事物之间确实存在着某些联系。第四章面向对象的软件分析基础实验68（7）消息通信原则：这一原则要求对象之间只能通过消息进行通信，而不允许在对象之外直接地存取对象内部的属性。通过消息进行通信是由于封装原则而引起的。在OOA中要求用消息连接表示出对象之间的动态联系。（8）粒度控制原则：一般来讲，人在面对一个复杂的问题域时，不可能在同一时刻既能纵观全局，又能洞察秋毫。因此需要控制自己的视野：考虑全局时，注意其大的组成部分，暂时不详察每一部分的具体的细节；考虑某部分的细节时则暂时撇开其余的部分。这就是粒度控制原则。（9）行为分析原则：现实世界中事物的行为是复杂的。由大量的事物所构成的问题域中各种行为往往相互依赖、相互交织。在用OOA具体地分析一个事物时，大致上遵循如下五个基本步骤：第一步，确定对象和类。这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述，它包括如何在一个类中建立一个新对象的描述。第二步，确定结构（structure）。结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系，整体-部分结构反映整体和局部之间的关系。第三步，确定主题（subject）。主题是指事物的总体概貌和总体分析模型。第四步，确定属性（attribute）。属性就是数据元素，可用来描述对象或分类结构的实例，可在图中给出，并在对象的存储中指定。第五步，确定方法（method）。方法是在收到消息后必须进行的一些处理方法：方法要在图中定义，并在对象的存储中指定。对于每个对象和结构来说，那些用来增加、修改、删除和选择一个方法本身都是隐含的（虽然它们是要在对象的存储中定义的，但并不在图上给出），而有些则是显示的。4.2面向对象的软件分析主要过程4.2.1面向对象建模面向对象模型是一个类（包括其属性和行为）、对象（类的实例）、类和对象关系的定义集。例如以公共自行车租赁系统为例，只要开通公交卡、城市通或者市民卡（这里统称为卡）中的公共自行车租用功能，并使得卡内有足够押金，即可在就近租车点通过刷卡进行自行车的租用。其中，在公共自行车租赁系统中的对象主要有：系统用户（包括管理员、操作员和租借用户）、卡、自行车、租借记录表、服务站、车位等。如下图4-1所示为系统中这些对象之间的关系图：图4-1对象关系图第四章面向对象的软件分析基础实验69经分析，公共自行车租赁系统各个对象之间有如下关联：（1）一个租借用户可以拥有多张不同种类的卡；（2）每张卡都设有一个电子钱包，负责管理账户金额；（2）每张卡每次只能租用一辆自行车，卡信息将与被租用自行车的信息相关联；（3）操作员负责人工租赁服务和自行车管理，操作员可以在不同的服务站进行服务；（4）一个服务站具有多个车位和多辆自行车，每个车位对应一辆自行车停放；（5）租借记录表中包括所有卡的租用记录情况，包括具体的用户、租用的自行车以及其他相关信息。（6）管理员、操作员和租借用户都是系统用户，他们之间存在继承关系。其中，系统用户是父类，管理员、操作员和租借用户均为子类；（7）服务站信息同时也包含所有的车位信息，这是因为车位点被设置在服务站中。在对系统包含的对象及对象间的总体关联进行分析之后，也要单独对每个对象进行建模，确定每个对象所具有的属性。例如对于系统用户类，应具有编号、姓名、出生日期、电话、性别等属性，而管理员在继承这些属性的同时，还应有登录密码和权限属性；操作员也具有登录权限和权限属性，他与管理员的不同在于这两个对象应具有不同的具体方法；租借用户继承所有系统用户属性的同时，应具有自行车编号属性，用于同所租用的自行车相关联。如下图4-2所示：图4-2用户关系图4.2.2用例建模以公共自行车租赁系统为例，系统参与者主要有租借用户、自行车管理员和操作员，租借用户可以通过刷卡方式租用自行车，归还自行车；管理员负责管理用户的各种信息、基础设施信息管理以及工作人员的相关信息；操作员则负责自行车调度，必要时向租借用户提供人工租赁服务。下面给出涉及到租借用户和操作员的部分用例，见图4-3：第四章面向对象的软件分析基础实验70图4-3部分用例图表4-1租用自行车用例场景描述用例名称租用自行车主要参与者租借用户A、操作员D涉众及其关注点租借用户A：希望能够便捷地租到自行车。操作员D：希望能够快速、方便地帮助租借用户完成人工租车服务。公共自行车服务公司：希望用户能够顺利租用到服务站的自行车；希望在租用高峰期系统的租车服务工作能够稳定运行；希望自行车数量能够尽量与用户的租用需求相符；在租用高峰期操作员通过人工租赁服务减轻系统的租车服务压力。前置条件用户A持有已开通租用自行车服务的市民卡、公交卡或城市通卡。操作员D具有提供人工租车服务权限。后置条件租借用户A可以顺利租得一辆处于空闲的自行车。基本流程1.用户A携带卡到就近服务站B。2.用户A将卡置于服务站B中任意一辆空闲自行车旁的刷卡处。3.系统通过设备感应卡内的信息。4.系统核实该卡是否开通服务，并且确认该卡处于尚未租车状态。5.查看用户A账户余额是否足够支付保证金，若能够支付，则扣除保证金。6.锁止器解锁并发出声响，用户A可以将自行车推出。7.借车操作完成。扩展：a.用户卡发生故障，无法进行刷卡操作。1)用户A携带卡到服务站的自助服务器C上选择异常卡处理操作。(1)用户A将卡置于刷卡区；(2)自助服务器C显示所有服务项；(3)用户A选择异常卡处理项；(4)系统进行异常卡处理工作。(5)异常卡修复工作完成，若用户A结束自助操作则取回卡，否则回到(2)2)用户A请求操作员D提供帮助或者直接在操作员D处办理一张新卡。第四章面向对象的软件分析基础实验71b.用户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分钟内快速还车。(1)用户A将自行车通过正常方式归还；(2)系统通过故障判断机制记录快借快还的自行车，自动提出报修；(3)用户A重新进行借车。2)若站点具有维修人员，请求维修人员维修。此外，若要体现特定场景内交流的图形化表示还可以使用活动图或泳道图分层描述。如图4-4所示为租用自行车的活动图，图4-5为租用自行车的泳道图。两图中均有同步条出现，这是因为当系统顺利将租赁保证金扣除后，一方面系统要修改租赁状态以及对站点、自行车数据的更新，另一方面要在租借记录表中新添加一条用户的租借记录，最后系统发出指令解锁并提示用户推出自行车。第四章面向对象的软件分析基础实验72图4-4活动图第四章面向对象的软件分析基础实验73图4-5泳道图4.2.3领域模型建模领域模型实际上是一个比较完整的业务模型。在建立领域模型时我们要根据具体问题的描述和在上一章节中的用例描述，得到潜在的分析类。分析类总是能够符合边界类、控制类或者实体类中的某一种。比如，在如图4-6所示的租借管理相关用例中，可以得到下列分析类：(1)控制类：租用自行车：负责租用自行车过程中系统特定指令和动作；归还自行车：负责归还自行车过程中系统特定指令和动作；查询租借记录，负责在用户查询时的请求和返回业务的相关指令和数据流。(2)实体类：租借记录表：记录用户每一次的租借和归还详细记录；用户卡账户：存储用户状态信息和余额信息；自行车信息：保存自行车信息；服务站信息：保存服务站信息包括站点车位信息；电子钱包：保管账户金额信息。(3)边界类：感应卡接口：负责感应和获取刷卡动作产生的信息；用户查询界面：用户进行查询记录时与系统交流的媒介。由上述分析类，可以得到租借管理用例相关类图，如下图4-6所示：第四章面向对象的软件分析基础实验74图4-6租借管理类图上图清楚展示了各个分析类之间相互的关系：用户刷卡并表明身份后，通过感应卡接口将卡中信息传递到系统内部，在执行租用自行车或者归还自行车一系列系统操作过程中，不仅要使用和修改户卡账户中的账户信息，还要根据实际情况对租借记录表进行记录和更新，并对自行车、站点包括车位的信息进行更新；此外，用户还可以通过查询界面对租借记录进行查看，这些查询的信息和数据均由租借记录表提供。4.2.4行为建模一旦通过用例确认的事件，就可以创建一个顺序图，顺序图与协作图相比，前者更强调事件的时间关系。图4-7给出了公共自行车租赁系统中“租用自行车”用例的顺序图。在用例交互中，参与者对系统发起事件，通常需要某些系统操作对这些事件加以处理。在“租用自行车”顺序图中，参与者是租借用户，租借用户将卡置于刷卡区请求系统对还车操作进行处理，即由刷卡操作所引