信息系统开发与管理实验报告3(共34页)

1、PAGE PAGE 44电 子 科 技 大 学实 验 报 告学生(xu sheng)姓名： 学 号：指导(zhdo)教师： 一、实验室名称(mngchng)：电子政务可视化实验室二、实验项目名称： 面向对象的信息系统分析三、实验原理：1. 业务模型（1）业务用例模型1）业务用例模型概述 业务用例模型描述了业务的目标、业务的启动者和业务范围；涉及的UML元素主要包括参与者、用例和边界；使用的UML图主要包括用例图和活动图。业务用例模型的构成包括业务用例图和对每一个业务用例的详细描述。2）业务用例模型的基本要素参与者也称为主角，是系统之外与系统进行交互的任何事物；参与者存在于系统之外，并不是系统的

2、一部分；在UML图形上，参与者用一个小人图来表示，如下所示。系统边界对于明确参与者非常重要，在实践中可以考虑是谁对系统主动发出动作，他是否有着明确的目标和要求以及系统是为谁服务的。另外，注意参与者并非一定是人。业务主角是参与者的一个构造型，是与业务系统有着交互的人和事物；一般在需求阶段使用，用于定义业务参与者；在UML图形上，业务主角的表示方式如下：用例用例与参与者交互，是对一组动作序列的抽象描述，通过执行该动作序列向参与者提供可观测的有意义的结果；一个用例描述了系统的一个完整的功能(gngnng)需求；在UML中，系统的所有行为都可建模为用例，而用例的描述独立于这些行为的实现。在UML图形中

3、，用例的表示方式如下：用例所描述(mio sh)目标的达成是由很多种不同情况构成的，把可能的目标达成方式称为用例场景，一个用例场景就是用例的一种实现方式；在UML中可以使用活动图对用例场景进行图形化的详细说明，通过用例规约对用例的其他信息进行说明。用例的特征：用例相对独立(dl)且执行效果对参与者有意义；用例必须要有启动者；用例的名称应以动宾形式出现。用例的关系有包含关系、扩展关系和泛化关系三种：基本用例是指包含了常规会发生的、具有基本功能的用例。用例之间的包含关系表示基本用例在它内部的某一位置上显式地合并了另一个用例的行为；扩展关系表示基本用例可以在特定条件下执行某些特定的扩展出来的行为，这

4、些扩展的行为可以单独形成一个用例，称为扩展用例。如果两个或更多用例在行为、结构和目的方面存在共性，可以使用一个新的、通常也是抽象的用例来描述这些共有部分，该用例随后被子用例特殊化，子用例继承父用例的所有结构、行为和关系。包含(bohn)关系示例图扩展(kuzhn)关系示意图用例中有个叫做业务用例的构造型。业务用例专门用于业务建模，其面对的问题领域是没有未来信息系统参与的、目前客观存在的业务领域；业务用例的参与者就是业务主角；在建立业务模型时，需识别业务用例。业务用例在UML中表示(biosh)如下：3）边界边界决定了系统的范围，在其范围内的就是系统的需求集合；边界和抽象层次也有十分密切的联系，

5、在不同的抽象层次，边界大小也是不同的；可以采取迭代的方式来获取系统边界；在UML中，边界被描绘成一个矩形框（查阅资料显示，Rational Rose的用例图中不能画系统边界，也不用画，因为Rational Rose认为用例的边界就是系统边界）。4）用例图 概括有关参与者和用例信息的一个图形化模型；显示了一组用例、参与者以及它们(t men)之间的关系；用例图展示了系统的功能性需求。如下为用例图的示例：5）活动(hu dng)图 活动图描述了为了完成一个用例所描述目标需要做的活动以及这些活动的执行顺序；活动图可以用来描述用例场景(chng jng)，与流程图类似，但活动图支持并行行为。如下为活动

6、图的示例：6）构建业务(yw)用例模型的过程识别(shbi)业务主角业务(yw)主角必须是在实际业务里能找到对应的岗位、人员或其他具体的事物；通常来说，业务主角可以从业务提出者、业务管理者、业务执行者及客户等人员中提取；注意不要将业务工人（主要为具体执行的工作人员）识别为业务主角。获取业务用例模型站在业务主角的角度，通过多种方式明确其所期望达成的业务目标；瞄准业务目标，将一个业务目标建模为一个业务用例，而暂时忽略实现业务目标的过程；在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为准。一个明确有效的业务目标是一个业务用例的来源，一个真实(zhnsh)的业务目标应当完备地表达业务主角的

7、期望，一个有效的业务目标应当在业务边界内由业务主角发起，并具有明确的结果。 建立(jinl)业务用例图 在识别了业务(yw)主角和业务用例的情况下，使用业务用例图的方法能更直观地反映业务主角与业务用例之间的关系，从而反映出业务范围。 描述业务用例采用活动图来描述业务用例的场景，采用用例规约来描述一个业务用例的其他信息。活动图的绘制可以分以下几个步骤：a将业务用例场景中参与业务的人员作为活动图的泳道；b将参与人员所做工作作为活动；c按照实际业务流程中的执行顺序将这些活动连接起来以描述业务用例场景。用例规约则是用于描述用例的一些细节信息，包括用例的前置条件、后置条件和事件流等信息。所谓的事件流是指

8、达到一个业务目标所发生的一系列活动，包括主事件流和异常事件流。主事件流指能够满足业务目标的典型的成功路径，通常不包括任何条件和分支；异常事件流指可能出现失败的情况以及可能的分枝路径或扩展路径。用例规约参考准则的编写要求：使用简单的语法，主语明确，语义易于理解；使用主动语态，也就是在事件流描述中，主语是业务参与者；从第三者的角度来编写，指出业务参与者的动作。（2）领域模型1）领域模型概述描述了达成业务目标过程涉及到的对象、对象间的关系、对象间的交互和对象的内部行为；使用到的最主要的UML元素是业务对象；绘制的UML图主要包括类图、交互图和状态图。2）业务对象业务对象是实现业务目标的过程中涉及到的

9、事物。业务对象来源于现实世界，是参与者在完成其业务目标的过程中使用到的或创建出来的，它表示一个现实中的概念。业务对象是信息系统的一部分，它构成了系统存储信息的相关数据，也就是说系统需要存储这些业务对象的信息。在UML中业务对象的表示方式如下所示：业务对象间的关系有以下几种：依赖关系，即使用关系，当要指明一个对象使用另一个对象时，就可以使用依赖关系来描述；泛化关系，即继承关系，是一般事物（父类）和该事物的较为特殊的种类（子类）之间的关系；关联关系，指明一个事物的对象与另一个事物的对象之间的联系，给定一个连接两个类的关联，可以从一个类的对象导航到另一个类的对象，反之亦然。聚合关系分为组合聚合和共享

10、聚合，组合聚合具有很强的归属关系，部分只能是一个整体的成员，且部分的存在依赖于整体事物；共享聚合是用来描述具有共享特性的“整体部分”关系，其含义是指部分事物可能同时属于多个整体事物。3）类图类图用于展示系统中的类以及类之间的关系；在业务(yw)建模阶段，类图主要用于对业务对象及其之间关系的描述，独立于实现语言和实现方式。4）对象(duxing)间的交互对象相互之间通过传递消息进行交互，一次交互由实现某一特定目标的一组对象进行交换(jiohun)的一组消息构成。对象指的是类图中类的实例；参与者是一个交互过程的发起者。消息是对传送信息的对象之间多进程通信的描述。5）顺序图和协作图顺序图描述了在参与

11、交互的对象中所发生的事件以及这些对象如何通过相互发送消息进行通信，强调发送消息的时间顺序。如下为顺序图在UML中的示例：协作图强调参加交互的对象的组织，它的主要应用是快速浏览相互协作、用来支持一个特定用例的所有对象。协作图示例如下：6）对象的状态状态是指在对象的生命期中满足某些条件、执行(zhxng)某些活动或者等待某些事件时的一个条件或状况；对象在某一状态保持有限的时间，一个对象一直保持某种状态直到某个事件强制使它转换到另一个状态，每个状态有一个唯一的名称。状态一般包括普通、初始、终止和复合四种。转换是指使一个对象离开一个状态并转变到另一新状态的机制，一个转换表示对象在第一个状态中执行一定的

12、动作，在某个特定事件发生并在某个特定的条件满足时进入第二个状态。转换包括源状态、事件触发、监护条件、行动表达式以及目标状态5个部分。状态图示例如下：7）构建(u jin)领域模型的步骤 获取(huq)业务对象从业务用例场景里获取业务对象。其中，最常用的识别方法有：Wirfs-Brock名词短语策略和概念类列表法。 业务对象属性建模在建立业务模型时，需要明确每个业务对象的属性。 业务对象关系建模根据对象间的关系类型，可以从依赖关系、泛化关系、关联关系和聚合关系几个方面来考虑业务对象间的关系。 业务对象交互建模关键是要理清业务对象间的交互方式，也就是决定消息该发给哪个对象；派发消息的一个简单原则就

13、是消息的接收者应该拥有处理消息所需要的数据。主要包括顺序图和协作图两种图的开发。顺序图的开发步骤：a针对每一个业务用例场景，确定所有与业务用例有关的业务对象和业务主角；b基于业务用例的活动图和用例规约，确定每一个需要用于完成此业务用例的消息，同时表示消息的源对象（或业务主角）和目的对象（或业务主角）；c决定是否总是发送还是有条件地发送每一条消息；d正确地为这些消息排序并把它们附在合适的业务主角或业务对象的生命线上，并对消息进行适当描述。协作图的开发步骤：a协作图的开发过程与顺序图的开发过程大体一致；b在找出业务用例涉及到的业务对象后，就需要描述出这些对象之间可能有消息传递的链；c在链都描述完之

14、后，从引起这个交互的消息开始，将随后的每个消息附到适当的链上，恰当地设置其顺序号。业务对象状态分析该步骤(bzhu)的工作主要是开发状态图，开发状态图的主要问题是识别业务对象的正确状态。这个过程是一个反复的过程。状态图开发的基本步骤：a检查业务对象模型并选择出需要描述状态转换的业务对象；b标识所选业务对象在交互图中的所有输入消息；c对业务对象从多个方面来寻找其状态。d综合前面得到的状态和转换，以此建立状态图片段；e使用适当的消息事件、监护条件和行动表达式扩展每一个转换。2. 分析模型(1)分析模型概述(i sh)分析模型是介于原始业务需求和计算机实现之间的一种过渡模型，向上可以(ky)追溯到业

15、务模型，也可以向下映射到设计模型。它既对业务模型进行了精化，同时也加入了计算机领域的内容。建立分析模型的工作包括识别系统用例、识别分析类和组织分析类三大块。(2)系统用例系统用例用于定义系统的范围，获取系统功能性需求；系统用例是从业务用例中推导出来的。(3)分析类业务领域模型中的业务对象不是计算机能理解的元素，系统不能直接构建在业务对象上。UML提供了三种类来描述计算机能理解的对象边界类、实体类和控制类。边界类边界类用于建立系统与其参与者（即用户和外部系统）之间交互的模型。这种交互通常包括接收来自用户和外部系统的信息与请求以及将信息和请求发送到用户和外部系统、描述系统的边界需求。每个边界类至少

16、与一个参与者有关。实体类实体类用于对长效且持久的信息建模；主要是对诸如个体、实际对象或实际事件的某些现象或概念的信息及相关行为建模。实体类来源于领域模型中的业务对象，但又有所区别。参与者不会与实体类进行交互，边界类在两者中起到一个桥梁的作用。控制类控制类代表协调、排序、事务处理以及对其他对象的控制，经常用于封装与某个具体用例有关的控制信息和操作。控制类并不封装与参与者交互有关的问题，也不封装与系统处理的长期、持久信息有关的问题。实体类、控制类、边界类和参与者的协作如下图所示：(1)包与包图在UML中，可以取其中的任何一种事物，将相关成分聚在一起，以构成更高的组织(zzh)单元包。包可以拥有类、

17、接口、用例和图等，也可以嵌套。分包的原则有共同(gngtng)封闭原则和共同复用原则。包图则用于描述包及其依赖关系。目的是用于表示一个完整系统的主要构成。其包括包和表示其依赖关系的虚线。包图的确定可以分为以下几个(j )步骤：A根据用例图，可以确定大致需要的包；B根据类图，按照类的分包原则将类放入各包中；C根据类图中各个类之间的关系确定包之间的关系；D根据系统构架调整包图。(2)构建分析模型 确定系统用例建立备选系统用例对每个业务用例的活动图进行分析，考虑其中的每一个活动是否可由计算机来实现，如果能由计算机实现，则将该活动识别为一个备选用例，将活动的执行人员识别为备选参与者。对于备选用例，再使

18、用映射、抽象、合并、拆分和演绎等方法来确定最终用例。识别分析类 考虑要达成系统用例的目标，需要哪些计算机世界的类来实现。为每一个用例考虑设置一个边界类，提供与参与者交互的职责；而参与者也应该从边界类开始启动一个用例。实体类大多来源于业务对象，出于系统结构优化的需要，一些实体类也会在后继的过程中被分拆、合并。控制类源于用例场景中行为的定义，即对用例场景中动词的分析，这些动词都可以成为控制类的来源。最后主要使用包对类进行逻辑分组。描述系统用例 与业务用例类似，系统用例也有场景，也需要对场景进行描述。具体描述方式有活动图或者用例规约和交互图。四、实验目的：理解业务模型和系统分析模型的基本概念和建立步

19、骤，掌握相关UML图示的画法，熟练使用Rational Rose软件进行相关操作。五、实验内容：根据实验材料的内容，使用Rational Rose软件完成以下实验任务：1. 对实验材料中涉及的系统(xtng)建立业务模型，包括业务用例模型和领域模型；2. 在业务模型的基础上建立(jinl)系统的分析模型；六、实验(shyn)器材（设备、元器件）：计算机windows7操作系统、IBM Rational Rose软件七、实验步骤：1. 构建业务模型（1）构建业务用例模型 1) 识别业务主角；2) 获取业务用例模型；3) 建立业务用例图；4) 描述业务用例。（2）构建领域模型1)获取业务对象；2)

20、 业务对象属性建模；3) 业务对象关系建模；4)业务对象交互建模；5）业务实体状态分析。2. 构建分析模型（1） 确定系统用例；（2） 识别分析类；（3） 描述系统用例。八、实验数据及结果分析：1. 构建业务模型（1）构建业务用例模型1)识别业务主角根据实验材料，我们将客户和总经办建模为业务主角，如下图：2) 获取业务用例模型根据实验材料，我们可以识别入库、出库和盘点库存三个业务用例，如下图：3) 建立(jinl)业务用例图根据(gnj)前两个步骤建立如下的业务用例图：4) 描述(mio sh)业务用例入库业务用例（i）活动图出库业务(yw)用例（i）活动(hu dng)图盘点(pndin)业

21、务用例（i）活动图（2）构建领域(ln y)模型1）获取(huq)业务对象由业务(yw)用例和业务流程可得该系统的业务对象有码单、到站日报、入库单、出库单、出门条、盘点表、货品明细单和派车单，如下图：2) 业务对象属性建模根据系统需求，将业务对象进行属性建模，建模结果如下：3) 业务对象(duxing)关系建模4)业务对象(duxing)交互建模入库(r k)业务用例(i) 顺序(shnx)图(ii)协作(xizu)图出库业务(yw)用例(i) 顺序(shnx)图(ii)协作(xizu)图盘点(pndin)业务用例(i) 顺序(shnx)图(ii)协作(xizu)图2. 构建(u jin)分析

22、模型（1） 确定(qudng)系统用例根据活动(hu dng)图确定该仓储管理系统的系统用例如下：（2） 识别分析类根据活动图、顺序图和系统(xtng)用例判断该仓储管理系统的分析类。1）边界(binji)类包2）控制(kngzh)类包3）实体类包边界类包、控制类包和实体类包之间的关系如下：（3） 描述系统用例1）创建出库单(i)活动图(ii)顺序(shnx)图2）创建(chungjin)出门条(i)活动(hu dng)图(ii)顺序(shnx)图3）派车单创建(chungjin)(i)活动(hu dng)图(ii)顺序(shnx)图4）创建入库单(i)活动图(ii)顺序(shnx)图5）创建(chungjin)码单(i)活动(