案例分析第 9 章一,银行网络系统 ATM
二,医院病房监护系统三、会议管理系统案 例采用 OMT方法对 银行网络系统 ATM(Auto Trade Machine) 进行分析和设计。
一、问题的陈述银行网络系统包括人工出纳和分行共享的自动出纳机；各分理处用自己的计算机处理业务 （ 保存帐户,处理事务等 ） ；各分理处与出纳站通过网络通信；出纳站录入帐户和事务数据；自动出纳机与分行计算机通信；
自动出纳机与用户接口,接受现金卡；发放现金；打印收据；分行计算机与拨款分理处结帐 。
要求系统正确处理同一帐户的并发访问；网络费用平均摊派给各分理处。图１给出了银行网络系统的示意图。
银行网络系统 ATM(Auto Trade Machine)
自动出纳机自动出纳机自动出纳机出纳站分理处计算机分理处计算机出纳站帐户帐户图 1 银行网络系统的示意图用户分行计算机退出首页 下页 末页案 例 一二,类的识别方法常用的识别类的方法有：名词识别法,系统实体识别法,使用重用,从用例中识别类等 。
１,名词识别法识别问题域中的实体,实体的描述通常用名词,名词短语,名词性代词的形式出现 。
用指定语言对系统进行描述；
从系统描述中标识名词,名词短语,名词性代词；
识别确定 （ 取,舍 ） 类 。
２,系统实体识别法不关心系统的运作流程及实体之间的通信状态,而只考虑系统中的人员,组织,地点,表格,报告等实体,经过分析将他们识别为类 （ 或对象 ） 。
被标识的实体有：系统需要存储,分析,处理的信息实体,系统内部需要处理的设备,与系统交互的外部系统,系统相关人员,系统的组织实体 。
在确定类时,常使用两类技术：
⑴ 分解技术 将整体类和组合类分解 。 可控制单个类的规模 。
⑵ 抽象技术 根据一些类的相似性建立抽象类,并建立抽象类与这些类之间的继承关系 。
抽象类实现了系统内部的重用,很好地控制了复杂性,并为所有子类定义了一个公共的界面,使设计局部化,提高系统的可修改性和可维护性 。
退出上页首页 下页 末页三、建立对象模型根据下述原则进一步确定类：
① 去掉冗余类：如两个类表述同一信息,应保留最具有描述能力的类,如,用户,与,顾客,是重复的描述,由于,顾客,更具有描述性,故保留它,删除,用户,。
② 去掉不相干的类：删除与问题无关或关系不大的类,如,费用,。
③ 删除模糊的类：有些初始类边界定义不确切,或范围太广,应该删除 。 如,系统,,,安全措施,,
,记录保管,,,银行网络,。
④ 删除那些性质独立性不强的,而应该是类,属性,的候选类：如,帐户数据,,,收据,,,现金,,
,事务数据,。
⑤ 所描述的操作不适宜作为对象类,并被其自身所操纵,所描述的只是实现过程中的暂时的对象,应删去 。 如,软件,,,访问,。
（一）确定类采用名词识别法：检查问题陈述中的所有名词,得到初始类：
软件 银行网络 分行计算机 系统 分行 出纳站分理处 分理处计算机 自动出纳机 出纳员 帐户数据 帐户现金卡 事务数据 用户 顾客 收据 记录保管事务 费用 安全措施 访问 现金最终确定的类为：
分行计算机 分行 出纳站 出纳员 分理处 分理处计算机自动出纳机 帐户 现金卡 事务 顾客退出上页首页 下页 末页
（ 二 ） 为每个建模实体准备数据词典 — 描述模板对类进行精确描述,如ＡＴＭ系统中类的范围,成员,方法的限制等 。
（ 三 ） 确定关联两个或多个类之间的相互依赖关系就是关联,实现关联的方式有多种 。
关联通常用描述性动词和动词词组表示 。
可以从问题陈述中抽去所有可能的关联表述,在银行网络系统示例中所有可能的关联,大多数是直接抽取问题中的动词词组而得到的 。 但在陈述中,有些动词词组表述的关联是不明显的,或在问题陈述中是找不到的,还有一些关联与客观世界或人的假设有关,必须同用户一起确定这种关联 。
即关联通常由以下方面确定：
１,银行网络系统问题陈述中抽取 可能 的关联 （ 动词词组 ）
２,隐含的动词词组
３,基于问题域的知识
４,去掉不必要和不正确的关联三、建立对象模型退出上页首页 下页 末页
１,银行网络系统问题陈述中的关联银行网络包括出纳站和自动出纳机 。
分行共享自动出纳机分理处提供分理处计算机分理处计算机保存帐户分理处计算机处理帐户支付事务分理处拥有出纳站出纳站与分行计算机通信出纳员为帐户录入事务自动出纳机接受现金卡自动出纳机与用户接口自动出纳机发放现金自动出纳机打印收据系统处理并发访问分理处提供软件费用分摊给分理处
３,基于问题域的知识分理处雇佣的出纳员现金卡访问帐户
２,隐含的动词词组分行由分理处组成分理处拥有帐户分行拥有分行计算机系统提供记录保管系统提供安全顾客有现金卡
（三）确定关联退出上页首页 下页 末页
４,去掉不必要和不正确的关联使用下列标准去掉不必要和不正确的关联：
（ 1） 若某个类已被删除,那么与它有关的关联也必须删除或者用其他类来重新表述 。 在示例中,删除了,银行网络,,相关的关联也要删除 。
（ ２ ） 不相干的关联或实现阶段的关联 。 删除所有问题域之外的关联或涉及实现结构中的关联,如,系统处理并发访问,就是一种实现的概念 。
（ ３ ） 动作 。 关联应描述应用域的结构性质而不是瞬时事件,因此应删除,自动出纳机接受现金卡,,,自动出纳机与用户接口,等 。
（ ４ ） 派生关联,省略那些可以用其他关联来定义的关联 。 因为这种关联是 冗 余的 。
银行网络系统的初步对象图如图２所示,其中含有关联 。
（三）确定关联退出上页首页 下页 末页图２初始对象图建立对象模型图 2 银行网络系统的初始对象类图分行 分理处 帐户 顾客分行计算机自动出纳机 远程事务分理处计算机 出纳员 现金卡出纳站 出纳事务通信通信所有所有所有雇佣涉及涉及访问认可有有拥有组成录入由录入录入?
退出上页首页 下页 末页
（ 四 ） 确定类属性属性通常用修饰性的名词词组来表示 。 属性一般不可能在问题陈述中完全表述出来,应分析应用领域,并考虑最主要的属性 。
只考虑与具体应用直接相关的属性,不要考虑那些超出问题范围的属性；找出重要属性,避免那些只用于实现的属性,要为各个属性取有意义的名字 。
按下列标准删除不必要的和不正确的属性：
（ 1） 限定词：若属性值固定下来后,能减少关联的重数,则可考虑把该属性重新表述为一个限定词 。 如银行码,站代码及雇员号等是限定词,不作为属性 。
（ 2） 内部值：若属性描述了对象的非公开的内部状态,则应从对象模型中删除该属性 。
（ 3） 细化：在分析阶段应忽略那些不可能对大多数操作有影响的属性 。
图３给出了银行网络系统对象模型的部分属性 。
退出上页首页 下页 末页确定类属性退出上页首页 下页 末页图 3 银行网络系统的部分属性自动出纳机分发现金远程事务种类,日期,时间,数量顾客名字地址现金卡密码雇员号站代码分理处名字帐户号卡片码
银行码分理处计算机?
帐户余额、类型贷款限定出纳员名字出纳事务出纳站银行码分行分行计算机 银行码站代码
（ 五 ） 使用继承来细化类使用继承来共享公共结构,以此来重新组织类：
１,自底而上 将现有类的共性一般化为父类 。
找出具有相同属性,关联,操作的类,来发现继承,例如：,出纳事务,和,远程事务,其属性与主要操作是是类似的,则将它们的共性一般化,得到父类,事务,。
２,自顶而下 将现有类细化为更具体的子类 。
若假设的具体化与现有的类发生冲突,则说明该类结构不恰当,当同一关联名多次出现,且意义也相同时,应尽量具体化为相联系的类 。 例如,事务,从,出纳站,和,自动出纳机,进入,
,录入站,就是,出纳站,和,自动出纳机,的一般化 。
图４给出了加入继承后银行网络系统的对象模型 。
退出上页首页 下页 末页图 4 使用继承来细化类退出上页首页 下页 末页图 4 银行网络系统的对象模型银行码出纳站录入站远程事务帐户余额、类型贷款限定顾客名字地址出纳员名字现金卡密码事务种类,日期,时间,数量分行计算机 银行码站代码银行码分行自动出纳机分发现金出纳事务雇员号站代码分理处名字帐户号卡片码?
银行码分理处计算机
（六）完善对象模型在软件开发的全过程中,需要不断地完善对象模型 。 可以从以下几方面考虑：
１,检查是否有缺少的对象
如果一个类中,存在毫无关系的属性和操作,则应该分解这个类 。
一般化体系不清楚,可分离为两个类 。
存在名称及目的相同的 冗 余关联,则通过一般化创建一个父类,并组织关联 。
２,查找多余的类若类中缺少属性,操作和关联,删除该类 。
３,查找缺少的关联
４,系统的改进
⑴ 现金卡有多个独立的特性,分解为卡片权限和现金卡 。 卡片权限是银行用来鉴别用户访问权限的卡片,表示一个或多个用户帐户的访问权限；各个卡片权限对象中可能具有好几个现金卡,每张都带有安全码,卡片码,它们附在现金卡上,表示银行的卡片权限 。
现金卡是自动出纳机得到标识码的数据卡片,它也是银行代码和现金卡代码的数据载体 。
⑵ 为了,事务,与,帐户,之间的传输描述具有一般性,增加,更新,。 因为一般在每个帐户中,
一个,事务,包括一个或多个,更新,,一个,更新,是对帐户的一个动作,它们是取款,存款,查询之一 。 即事务由若干更新组成,更多涉及到帐户 。
⑶ 由于,分理处,与,分理处计算机,之间的区别不影响分析,可将,分理处计算机,并入,分理处,。 同理,将,分行计算机,并入,分行,。
以上改进如图５所示 。
退出上页首页 下页 末页图 5 完善对象模型退出上页首页 下页 末页图 5 修改后的对象模型录入站 远程事务现金卡银行名、卡片码安全号出纳员事务出纳员名字出纳站分行 银行码站代码帐户余额、类型贷款限定顾客名字地址自动出纳机分发现金事务种类、日期、时间、数量卡片权限密码、限制更新数量、类型
雇员号站代码分理处名字帐户号卡片码?
录入 组成
拥有拥有雇用 访问标识发行被录入开始涉及维持有有
四,建立动态模型动态分析从寻找外部可见的模拟和响应事件开始,确定各对象的可能事件的顺序,在分析阶段不考虑算法的执行,它是实现模型的一部分 。 通常动态模型有,事件跟踪表,状态图 。
建立动态模型的步骤分为４步：
１,准备典型的对话脚本脚本是事件序列,每当系统中的对象与外部用户发生互换信息时,就产生一个事件,所互换的信息值就是该事件的参数 。 对于各事件,应确定触发事件的动作对象和该事件的参数 。 包括,正常脚本,,
,例外脚本,,
自动出纳机与用户交互的正常的脚本如下所示：
⑴ 自动出纳机请求用户插入卡片；用户插入现金卡 。
⑵ 自动出纳机接受卡片并读出它的卡号 。
⑶ 自动出纳机要求密码,用户键入密码,4011”。
⑷ 自动出纳机与分行确认卡号和密码；分理处检查它并通知承兑的自动出纳机 。
⑸ 自动出纳机要求选择事务类型 （ 取款,存款,转户及查询 ）,用户选择取款 。
⑹ 自动出纳机要求现金数量；用户输入 ￥ 100。
⑺ 自动出纳机要求分行处理事务；分行把要求转给分理处,确认事务成功 。
⑻ 自动出纳机分发现金并且要求用户取现金；用户取现金 。
⑼ 自动出纳机提示用户是否想继续；用户指出不继续 。
⑽ 自动出纳机打印收据,退出卡,并请求用户取出它们；用户拿走收据和卡 。
⑾ 自动出纳机请求用户插入 。
退出上页首页 下页 末页自动出纳机与用户交互的例外的脚本如下所示：
⑴ 自动出纳机请求用户插入卡；用户插入现金卡 。
⑵ 自动出纳机接受卡并读它的卡号 。
⑶ 自动出纳机要求密码；用户键入,9999,。
⑷ 自动出纳机与分行确认卡号和密码,在咨询分理处后拒绝它 。
⑸ 自动出纳机指示密码错并要求重新键入；用户键入,4011：,分行确认成功 。
⑹ 自动出纳机请求用户选择事务类型；用户选择取款 。
⑺ 自动出纳机请求键入现金数量；用户改变选择并键入,CANCEL”（ 取消 ） 。
⑻ 自动出纳机退出卡并且请求用户拿走卡；用户取出卡 。
⑼ 自动出纳机请求用户插入卡 。
２,确定事件根据脚本确定所有的外部事件,事件包括：发送者,接收者,外设信号,输入,中断,转换和动作等 。 使用脚本可以发现正常事件,但不要遗漏条件和异常事件 。
３,画出事件跟踪表把脚本表示成一个事件跟踪表,即不同对象间的事件排序表,图６ 给出了银行网络系统的事件跟踪表 。 图 7 给出了事件流图,它给出类之间的所有事件 。 事件流图是对象图的一个动态对照,对象图中路径反映了可能的信息流,而事件流图反映了可能的控制流 。
退出上页首页 下页 末页退出上页首页 下页 末页图 6 银行网络系统的事件追综图用户 自动出纳机 分行 分理处确认帐号插入卡要求密码输入密码要求类型输入类型要求数量输入数量分发现金要求取现金取现金提示继续终止打印收椐退出卡要求取卡取卡显示屏确认银行卡银行帐户正确处理银行事务银行事务成功帐户正确处理事务事务成功图 7系统的事件图自动出纳机的事件流图退出上页首页 下页 末页图 7 银行网络系统的事件图用户分理处自动出纳机分行确认卡及银行,处理银行事务分理处事务成功,失败,分理处帐户正确事务成功,事务失败,
帐户正确,不正确帐户,
密码,银行代码插入卡，输入密码，类型，取现金，取卡不显示主屏可读卡,要求密码,类型,数量,取消信息,分发现金,要求继续,不正确帐户信息确认帐户处理事务
４,构造状态图对各对象类建立状态图,反映对象接收和发送的事件,每个脚本或事件跟踪表都对应于状态图中一条路径 。
在银行网络系统示例中,自动出纳机,出纳站,分行和分理处对象都是动作对象 。 用来互换事件,而现金卡,
事务和帐户都是被动对象,不交换事件,顾客和出纳员都是动作对象,它们同录入站的交互作用已经表示出来了 。 但顾客和出纳员对象都是系统外部的因素,不在系统内部实现 。 图给出了自动出纳机的状态图,图８
给出了,分行,类的状态图,图给出了,分理处,类的状态图 。
图8自动出纳机类的状态图为重要的类建立状态图退出上页首页 下页 末页图 8,自动出纳机”类的状态图检查
do:要求密码核对
do:确认帐户选择
do:要求类型输数据
do:要求数量开始
do:显示屏?
插入插入密码帐户正确输入类型取卡片不可读
do:不可读卡信息取消
do:取消信息帐户错误
do:帐户错误信息失败
do:失败信息取消取消插入卡卡片退出
do:退出卡,取卡片结束
do:打印收据继续否
do:请求继续发现金
do:请求继续事物
do:处理事务事务成功取现金终止取消输入事务帐户错取消 取消密码错事务失败等
５
秒图 9分行类的状态图退出末页图 9,分行”类的状态图
do:处理分理处事务
do:确认分理处代码
do:确认卡
［ 正确代码 ］
分理处事务成功／事务成功
处理事务确认帐户 ［ 错误代码 ］ ／错的分理处代码?
错的分理处帐户／ 错的帐户错的分理处帐户ＯＫ／ 错的密码
分理处密码／ 帐户ＯＫ
分理处事务失败／事务失败上页首页 下页
do:更新帐户
do:确认卡片号
do:确认密码
［有效］
［成功］／分理处事务成功?处理分理处事务确认分理处与卡片 ［无效］／错的分理处帐户?
［无效］／错的分理处密码
［有效］ ／分理处帐户ＯＫ
［失败］／分理处事务失败图 10,分理处”类的状态图五,建立功能模型功能模型描述了值之间的依赖关系,通常用分层的数据流图描述 。 数据流图有助于表示功能依赖关系,
其中的处理对应于状态图的活动和动作,其中的数据流对应于对象图中的对象或属性 。
建立功能模型的步骤是：
１,确定输入,输出值先列出输入,输出值,输入输出值是系统与外部世界之间的事件的参数 。 检测问题陈述,从中找出遗漏的所有输入输出值 。 由于所有系统与外部世界之间的交互都经过自动出纳机,因而所有输入输出值都是自动出纳机事件的参数 。 图给出了自动出纳机的输入输出值 。
退出上页首页 下页 末页图 11 自动出纳机的输入输出值现金卡用户自动出纳机银行码 卡片码帐户类型事务类型密码现金 收据信息图 12 自动出纳机顶层数据流图自动出纳机顶层数据流图
2,建立数据流图退出上页首页 下页 末页数据流图说明输出值是怎样从输入值 得来的,数据流图通常按层次组织 。 最顶层由单个处理组成,
也可由收集输入,计算值及生成结果的一个综合处理构成 。 图给出自动出纳机顶层数据流图 。
将顶层图中的处理扩展成更低层次的数据流图,如果第二层次图中的处理仍包含一些可细化的处理,
它们还可继续扩展,图 13是图 12中,执行事务,处理的扩展 。
现金卡用户读输入 执行事务产生输出帐户结算银行码 卡码密码数量事务类型现金 收据信息帐户类型图 13 自动出纳机“执行事务”数据流图
“执行事务,加工的分解退出上页首页 下页 末页图 13 自动出纳机“执行事务”数据流图更新帐户选择帐户确认密码选择卡选择分理处分行银行码银行码卡码无效卡码不正确密码卡授权密码密码帐户类型帐户不正确帐户无效事务现金、收据数量、事务类型帐户不正确的银行码
3、描述处理退出上页首页 下页 末页当数据流图已细化到一定程度后,对各处理进行描述,描述方法用自然语言,伪码及判定树等,描述可以是说明的或过程的 。
说明性描述确定了输入,输出值之间的关系 。 说明性描述优于过程性描述,因为它隐含实现的考虑 。 过程性描述确定一个算法来实现处理功能,算法只是用来确定处理干什么 。 过程性描述实现起来较为容易 。
下面给出,更新帐户,处理的描述：
IF 取款数目超过当前帐户结算,
退出事务,不发现金
IF 取款数目不超过当前帐户结算,
记帐并分发要求的现金
IF 事务是存款,
建立帐户并无现金分发
IF 事务是状态请求,
无现金分发在任何情况收据显示自动出纳机编号,日期,时间,帐户编号,
事务类型,数量 （ 若有 ） 以及新的结算 。
监视病情更新病历产生病情报告一,问题的描述在医院的病房里,将病症监视器安置在每个病床,对病人进行监护 。 监视器将病人的病症信号 （ 组合 ）
实时地传送到中央监护系统进行分析处理 。 在中心值班室里,值班护士使用中央监护系统对病员的情况进行监控,监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析,当病症出现异常时,系统会立即自动报警,并打印病情报告和更新病历 。 系统根据医生的要求随时打印病人的病情报告,系统还定期自动更新病历 。
退出下页 末页病房 中央值班室医院病房监护系统案 例 二二,简单的需求分析说明系统名称：医院病房监护系统根据分析系统主要实现以下功能：
1,病症监视器可以将采集到的病症信号 （ 组合 ）,格式化后实时的传送到中央监护系统 。
2,中央监护系统将病人的病症信号与标准的病症信号库里的病症信号的正常值进行比较,当病症出现异常时系统自动报警 。
3,当病症信号异常时,系统自动更新病历并打印病情报告 。
4,值班护士可以查看病情报告并进行打印 。
5,医生可以查看病情报告,要求打印病情报告,也可以查看或要求打印病历 。
6,系统定期自动更新病历 。
三,用 UML的静态建模机制定义并描述本系统的静态结构
（ 一 ） 建立系统的用例图通过以下六个问题识别角色
(1)谁使用系统的主要功能？
(2)谁需要系统的支持以完成日常工作任务？
(3)谁负责维护,管理并保持系统正常运行？
(4)系统需要应付 （ 或处理 ） 哪些硬设备？
(5)系统需要和哪些外部系统交互？
(6)谁 （ 或什么 ） 对系统运行产生的结果 （ 值 ） 感兴趣？
退出上页首页 下页 末页需求分析通过回答这六个问题以后,再进一步分析可以识别出本系统的四个角色：值班护士,医生,病人,标准病症信号库 。
角色描述模板角色,病 人角色职责：
提供病症信号角色职责识别：
负责生成,实时提供各种病症信号 。
角色,值班护士角色职责：
负责监视病人的病情变化角色职责识别：
(1)使用系统主要功能
(2)对系统运行结果感兴趣角色,标准病症信号库角色职责：
负责向系统提供病症信号的正常值角色职责识别：
(1)负责保持系统正常运行
(2)与系统交互角色,医 生角色职责：
对病人负责,负责处理病情的变化角色职责识别：
(1)需要系统支持以完成其日常工作
(2)对系统运行结果感兴趣通过分析可以初步识别出系统的用例为：中央监护,病症监护,提供标准病症信号,病历管理,病情报告管理 。 顶层用例图为：
退出上页首页 下页 末页提供标准病症信号病历管理病人标准病症信号库医生值班护士病症监护病情报告管理中央监护,使用,
,使用,
,使用,
角色描述将用例细化,可以得到分解的用例：
1,中央监护分解为,a 分解信号 将从病症监护器传送来的组合病症信号分解为系统可以处理的信号 。
b 比较信号 将病人的病症信号与标准信号比较 。
c 报警 如果病症信号发生异常 （ 即高于峰值 ）,发出报警信号 。
d 数据格式化 将处理后的数据格式化以便写入病历库 。
2,病症监护分解为,e 信号采集 采集病人的病症信号 。
f 模数转化 将采集来的模拟信号转化为数字信号 。
g 信号数据组合 将采集到的脉搏,血压等信号数据组合为一组信号数据 。
h 采样频率改变 根据病人的情况改变监视器采样频率 。
3,提供标准病症信号 i（ 此用例不分解 ）
4,病历管理分解为,j 生成病历
k 查看病历
l 更新病历
m 打印病历
5,病情报告分解为,n 显示病情报告 在显示器上显示病情
o 打印病情报告 在打印机打印病情报告退出上页首页 下页 末页用例细化给出细化的用例图退出上页首页 下页 末页病人模数转化数据格式化值班护士报警信号采集比较信号标准病症信号库医生信号数据组合采样频率改变提供标准病症信号生成病历查看病历 更新病历打印病历显示病情报告打印病情报告分解信号,Extend,
,Extend,
,Extend,
,use》
,use》
,use》
,use》
,use》
,use》
,use》,use》
细化的用例图
（ 二 ） 识别系统的类通过名词识别法和系统实体识别法等方法可以识别出系统的十二个类,
以下用类图这种简单明了的方法分别表示出类的名称,属性,操作 。
见下图：
医生用户名密码查看病情报告 （ ）
要求打印病情报告 （ ）
查看病历 （ ）
要求打印病历 （ ）
病人姓名性别年龄病症提供病症信号 （ ）
病症监视器采集频率病症信号格式化信号数据 （ ）
采集信号 （ ）
信号组合 （ ）
报警信号声音灯光文字报警 （ ）
数模转化 （ ）
病历库类型大小容量生成病历 （ ）
更新病历 （ ）
查看病历 （ ）
打印病历 （ ）
病人病症信号脉搏血压体温生成病症信号 （ ）
病历格式病人基本情况打印时间生成病历 （ ）
查看病历 （ ）
打印病历 （ ）
标准病症信号脉搏血压体温生成标准信号 （ ）
用户名密码查看病情报告 （ ）
打印病情报告 （ ）
值班护士类型大小容量提供标准信号 （ ）
标准病症信号库标题格式生成病情报告 （ ）
查看病情报告 （ ）
打印病情报告 （ ）
病情报告输入输出分解信号 （ ）
比较信号 （ ）
报警 （ ）
数据格式化 （ ）
中央监护系统退出上页首页 下页 末页类的识别再进一步在类图中标明类之间的关系：
退出上页首页 下页 末页
*
*
*
*
* *
*
11 1
1
1
1
1 1 1
1
1
1
1
1
11
值班护士 医生 病人病症监视病人病症信号病历病历库病情报告报警信号 中央监护系统标准病症信号标准病症信号库
1
1
1
报警监视系统类图
（ 三 ） 用包图和配置图描述系统的体系结构通过一定的分组机制得到以下包图：
用户医生值班护士病人病历管理病历用户界面病情报告局部监视报警信号病症监视器中央监护系统病人病症信号标准病症信号数据库病历库标准病症信号库用户层用户界面层应用层数据库层退出上页首页 下页 末页包图接下来用配置图进一步描述系统的网络结构四,用 UML的动态建模机制定义并描述系统结构元素的动态特性及行为
（ 一 ） 下面给出两个关系很紧密的状态图退出上页首页 下页 末页病症监视器的状态图信号采集模数转化 数据信号组合 发送信号数据局部显示开解信号 开解信号数据比较数据信号异常比较数据信号正常 格式化的数据报警更新病历更新日期到 发生病情异常发送报警标志数据格式化 数据格式化打印请求中央监护系统的状态图打印病情报告数据库服务器标准病症信号库病历库
TCP/IP TCP/IP
应用服务器中央监护系统局部监视 客户端用户界面状 态 图 与 配 置图
（ 二 ） 用时序图和合作图描述病人病情异常时系统的情况,其他情况从略 。
时序图,
病情报告监视器采集信号发送信号信号异常返回 打印更新中央监视系统 病历 报警信号退出上页首页 下页 末页合作图：
采集信号 发送信号 信号异常打印更新监视器 中央监视系统 报警信号病情报告病历时 序 图 与 合 作图
（ 三 ） 用活动图描述系统在监护病人时的状态变化退出上页首页 末页信号正常更新时间到信号异常时间间隔未到采集信号分析比较信号判断是否正常 判断更新时间报 警 更新病历 打印病情报告活动图一,问题陈述有一个对外营业的会议中心,有各种不同规格的会议室,为用户提供以下服务：
１,用户可以按照会议人数,会议时间预订会议室 。 可以只预订１次,也可预订定期召开的会议 。
２,开会前允许修改会议时间,人数,重新选择会议室,甚至取消预订的会议 。
３,确定会议预订后,会议中心负责会务管理：包括通过邮寄或电子邮件,通知开会人员有关会议信息,制作代表证等 。
４,系统根据会议室的使用情况 （ 紧张与否 ）,调整,更改会议室和会议时间,并调整修改预订会议的时间 。
会议管理系统退出下页 末页案 例 三二、建立 用例模型
1,识别角色找出所有可能与系统发生交互行为的外部实体,对象,系统 。
考虑系统的主要功能的使用者,就会想到用户和系统管理者,但如果直接将用户定义为角色,系统的所有功能几乎都由用户使用 。 根据问题的描述,系统要求将会议和会议的召开分开来 。
从会议的角度看,允许用户定义,更改或删除一个会议 。
从会议召开的角度看,允许用户为某个会议定义召开时间,参加人数,更改相应的数据或删除已定义的会议召开 。
因此,将用户识别为,会议管理者,和,会议申请者,两个角色 。
本系统定义以下角色：
会议管理者 （ Meeting Administrator）
会议申请者 （ Meeting Instance Requester）
邮局 （ Post Office ）
会议人员管理 （ Attendee Management ）
系统维护者 （ System Maintainer ）
退出上页首页 下页在识别角色的基础上,列出与角色相关的用例,有的用例与多个角色相关,经过分析,确定系统的用例 （ 打? ） 。
⑴ 与会议管理者相关的用例：
定义一个会议 （ Define Meeting ）?
更改一个会议 （ Alter Meeting ）?
删除一个会议 （ Remove Meeting ）?
⑵ 与会议申请者相关的用例：
申请会议召开 （ Request Meeting Instance ）?
更改申请 （ Chang Request ）?
取消申请 （ Cancel Request ）?
定义参加人员 （ Add Attendee ）?
归还会议室 （ Release Room ）?
2,用例识别退出上页首页 下页
2,用例识别
⑶ 与邮局相关的用例：
申请会议召开 （ Request Meeting Instance ）
更改申请 （ Modify Request ）
取消申请 （ Cancel Request ）
⑷ 与会议人员管理相关的用例：
定义参加人员 （ Add Attendee ）
取消申请 （ Cancel Request ）
申请会议召开 （ Request Meeting Instance ）?
更改申请 （ Modify Request ）
⑸ 与系统维护者相关的用例：
会议室维护 （ Meeting Room Maintenance ）?
设定预定时限 （ Set Reservation Tome Limit ）?
在确定角色和用例的基础上,画出用例图 （ 图１ ） 。
退出上页首页 下页
3、会议管理系统的 Use case图图 1 会议管理系统的 Use case图归还会议室申请会议召开更改申请取消申请定义参加人员会议召开申请者邮局会议人员管理设置预定时限会议室维护定义会议更改会议删除会议系统维护者会议管理员退出上页首页 下页用例 1,定义会议 （ Define Meeting ）
输入会议名称确定会议规模确定会议类型其中会议规模是指参会人数范围 。
用例２,更改会议 （ Alter Meeting ）
改变会议名称改变会议规模改变会议召开频度用例３,删除会议 （ Remove Meeting ）
如果该会议没有召开申请从会议列表中删除如果该会议有召开申请取消与之相关的会议召开信息删除该会议使用：
用例 8 删除参加人员 （ Remove Attendee ）
用例 6 取消申请 （ Cancel Request）
4,对用例的进一步描述用例 4,申请会议召开 （ Request Meeting Instance)
确定召开时间 （ 年,月,日 ）
确定参加人员确定侯选会议室发会议通知使用：
用例 11 发会议通知 （ Inform of Meeting）
用例 13 选择参加组 （ Select Group Attendee）
扩展：
① 如果召开时间在申请时限之外用例 12 申请拒绝 (Request Rejection ）
② 如果还没定义参加人员用例 7 定义参加人员 (Add Attendee )
用例 5：更改申请 （ Modify Request ）
更改召开时间更改参加人员更改取得会议室发会议更改通知使用：
用例 13 选择参加组 （ Select Group Attendee）
用例 11 发会议通知 (Inform of Meeting)
扩展：
① 如果更改的时间不合法用例 12 申请拒绝 （ Request Rejection）
② 用例 7 定义参加人员 (Add Attendee )
退出上页首页 下页用例 6：取消会议召开 （ Cancel Request）,
取消申请归还会议室发会议取消通知使用：
用例 8 归还会议室 （ Release Room）
用例 14 发会议取消通知 （ InformRejection）
扩展：
① 如果会议已召开用例 12 申请拒绝 （ Request Rejection）
用例 7：定义参加人员 (Add Attendee )
输入参加人员的详细信息定义参加组用例 9：会议维护 （ Meeting RoomMaintenance）
加入一个会议室 （ 用例 15)
标记一个会议室不可用 （ 用例 16)
查询会议室预定情况 （ 用例 17)
用例 10：设置预定时限制 （ Set Reservation Tome Limit）
设置时间限用例 11：发会议通知 (Inform of Meeting)
从会议人员管理获得参加人员的投递地址填写通知 （ 会议召开时间,会议室号码 ）
发送通知用例 12：申请拒绝 （ Request Rejection）
作废当前的一切输入中字止用户当前的操作用例 13：选择会议参加人员组 (Select Group Attendee)
浏览会议组成员选择参加组用例 14:会议取消通知 （ Inform of Cancellation)
从会议人员管理处获取参加人员地址填写通知发送通知用例８：归还会议室 （ Release Room）
输入会议室号码输入使用时间删除参加人员归还会议室使用：
用例９会议室维护 （ Meeting RoomMaintenance）
用例 18 删除参加人员 （ Remove Attendee）
退出上页首页 下页用例 15:增加会议室 （ Add Meeting Room）
输入会议室号码输入会议室规模输入会议室可使用状态 （ 可使用,不可使用 ）
加入该会议室用例 16:设置会议室不可使用 （ Set Unusable Flag）
输入会议室号码通知该会议室的预定者标记该会议室的可所以状态为不可用用例 17:查询会议室的使用情况 (Browse Meetingroom usage)
输入会议室号码查询本用例返回会议室的使用状态 （ 已使用,空闲 ） 和会议室的可否使用情况 。
用例 18：删除会议参加人员 （ Remove Attendee）
删除参加人员删除参加组图 2描述了会议管理系统完整的用例模型 。
退出上页首页 下页
5、完整的会议管理系统的 Use case图图 2 完整的会议管理系统 Use case图 退出上页首页 下页除了用例模型外,其它模型都依赖于类模型,因此,类模型是ＯＯ方法的核心,类模型从对象的角度描述系统的组成,描述类 （ 对象 ） 及相互间的关系 。 为了建立类模型,首先要识别类,鉴于篇幅,这里就不再讨论类的识别过程 。 通过分析,识别以下类：
1,Meeting类,标识一个会议 （ 名称,类型,规模 ） 。
2,MeetingInstance类,Meeting类的子类,对会议时间,人数等进行描述 。
3,MeetingRoom类,描述会议室的有关信息 。
4,MeetingAdministration类,管理会议 。
5,Attendee类,描述参会人员 （ 姓名,性别,地址,头衔等 ） 。
6,GroupAttende类,创建一个参加会议的组 。
7,Address类,描述邮寄地址 E-mail地址 。
8,PostOffic类,负责发送邮寄通知 。
9,AttendeeManagement类,数据库管理 。
10,ReservationCriteria类,定义会议室预定准则 。
11,Information类,构造一条通知 。
三,建立类模型退出上页首页 下页该类与会议召开不同,它标识了一个会议 （ 图 3）,因此,其属性包括会议名称,类型,规模 （ 参加会议的人数 ） 。 其操作则有：增加会议,取消会议 。 一个会议往往有多个子会议 （ 子类 ） 的召开,因此,必须描述 Meeting类与其子类 MeetingInstance类之间的关联,如图 4所示 。
2,MeetingInstance类
MeetingInstance类是 Meeting类的子类,描述会议的具体情况,会议的开始 (Start Time)、
结束时间 (End Time),参会的人数 (AttendeeNumber),其操作有：添加参加人员 AddAttendee()
,添加参加人员组 AddGroupAttendee(),而 AttachMeetingRoom()表示为该类分配一个会议室,
而 Cancel()则表示取消该会议的召开 。
Meeting
Name
Type
Size
AddMeetingInstance()
CancelMeetingInstance()
图 3Meeting类图
Meeting
MeetingInstance
Start Time
EndTime
AttendeeNumber
AddAttendee()
AttachMeetingRoom()
AddGroupAttendee()
Cancel()
图 4 MeetingInstance类 图
1,Meeting类退出上页首页 下页
MeetingRoom
Capacity
BuildingCode
DoorCode
Status
AssignMeetingInstance ()
SetInvalidate()
Release()
MeetingInstance
Meeting
图 5 MeetingRoom类 图该类描述了有关会议室的情况,因此 MeetingRoom类的属性包括：会议室的规模 Capacity,位置
BuildingCode,DoorCode,使用状态 Status（ 正在使用,已预定,空闲和不可用 ） 等 。
该类的操作有,AssignMeetingInstance() 将 MeetingRoom 分配给 MeetingInstance 对象,而
SetInvalidate()则表示当会议室出现故障时,将其状态设置为不可用 。 Release()为归还会议室 。
当会议被预定后,为了便于查询某个会议室预定给了哪个会议,应建立类 MeetingRoom 与类
MeetingInstanc之间的双向关联,这里定义为 1,1。
3,MeetingRoom类退出上页首页 下页
Attendee
Name
Sex
Postaddress
EmailAddress
Title
MeetingInstance
1 1..*
图 6 Attendee类 图
Attendee类 描述参加会议人员的有关信息,如：姓名,性别,地址,E-mail地址,头衔等 。
MeetingInstance类与 Attendee类之间有一对多的关联,1..*” 。
5,GroupAttendee类
MeetingInstance
GroupAttendee
MemberNumber
GroupName
AddAttendee()
DeleteAttendee()
1 0..* Attendee1 1..*
图 7 GroupAttendee类 图该类可 创建一个参加会议的组,便于按照小组选择参加会议的人员 。 MeetingInstance类与 GroupAttendee类之间有一对多的 关联,0..*”。
4,Attendee类退出上页首页 下页系统中有两种地址：电子邮件地址 （ EmailAddress ） 和邮寄地址 （ PostAddress ）,而且,
每个参加会议的人,可以有一个或者多个邮寄地址,有 0个或多个 Email地址 。 有关地址的属性,在再内这里不再讨论 。
负责发送邮寄通知 。 PostOffice类分别与 PostAddress,EmailAddress和 Information之间有一对多的关联 。
7,PostOffice类
1..*
Information EmailAddress
1..*
PostAddress
1..*(from Use Case View)
DelieverInformation( )
图 9 PostOffice类 图
PostOffice
Address
PostAddress EmailAddress
Attendee
图 8 Address类 图
1..* 0..*
6,Address类退出上页首页 下页
Information
Notice Topic
Receiver Title
Receiver name
Time
Event
Explanation
SendTime
Sendr
Signature
Create()
MeetingRoom
图 10 Information类 图该类用于构造一条通知,由于在本系统中,通常有三种：会议召开通知,会议更改通知,
会议取消通知 。 如下例所示,通知的内容常包括标题,接受者,会议内容,会议时间及发通知的时间等 。
XXXX会议召开通知
XX先生：
定于 2003年 9月 15日在樱都会议中心召开 XXXX会议 。
XXXX会议筹备组
2003年 8月 20日
8,Information类退出上页首页 下页
GroupAttendee Attendee
AttendeeManagement
(from Use Case View)
AttendNumber()
GroupAttendeeNumber()
AddAttendee()
ChangeAttendee()
AddGroupAttendee()
DeleteGroupAttendee()
图 11 AttendeeManagement类 图该类使用数据库对参加会议的人员进行管理 。 分析阶段只确定该类与系统的接口,有关数据库的设计在设计阶段解决 。 该类与 GroupAttendee类及 Attendee类的关联如图 11所示 。
10,ReservationCriteria类该类定义了预定会议室的准则 (如时间 ),并建立会议实例 （ MeetingInstanee 类 ） 与该类之间的联系 。
ReservationCriteria
TimeCriteria
setCrieria()
GetCriteria()
MeetingInstanee
图 12 ReservationCriteria类 图
9,AttendeeManagement类退出上页首页 下页该类管理系统中由用户定义的所有会议,并提供给用户友好的用户界面 。 由于该类有定义会议 （ DefineMeeting）,更改会议 （ AlterMeeting）,删除会议 （ RemoveMeeting ）
等操作,建立与 Meeting类之间的关联关系 。
MeetingName:string
MeetingAdministration
(from eetingPack)
MeetingNumber:int
DefineMeeting()
AlterMeeting()
RemoveMeeting()
Meeting
(from MeetingPack)
图 13 MeetingAdministration类 图
11,MeetingAdministration类退出上页首页 下页
Meeting
MeetingName:stringMeetingAdministration
ReservationCriteria MeetingInstance
Information
MeetingRoom
1..*1..* 1..*
PostOffice
GroupAttendeeAttendeeManagement
Address
PostAddress EmailAddress
Attendee
1..*
0..*
1..*
0..*
1
1
0..*
0..*
0..*
1 11
图 14 会议管理系统 类 图会议管理系统类图退出上页首页 下页四、建立系统包图引入包图来对类进行管理,图１５本系统的包图 。
系统由会议包 (MeetingPack),人员包 (AttendeePack)和邮寄包 (PostOfficePack)三类包组成 。 图
16,图 17,图 18分别描述了这三类包的构成 。
退出上页首页 下页
PostOfficePack
图 15 系统包图
MeetingPack AttendeePack
1、会议包（ MeetingPack ）
2,人员包（ AttendeePack ） 3、邮寄包（ PostOfficePack ）
GroupAttendee
Address
PostAddress EmailAddress
Attendee
图 17 人员包构成
0..*1..*
1..*
1
图 18 邮寄包构成
Information
PostOffice
（ from Use Case View）
1..*
0..*
MeetingMeetingName:stringMeetingAdministration
ReservationCriteria MeetingInstance
MeetingRoom
图 16 会议包构成
1 1 1
包图退出上页首页 下页静态模型关注的是系统各成分的组织结构,而动态模型则要描述系统各成分之间的交互行为,即系统的动态特征 。 结合本系统,建立动态模型,包括交互图,合作图,活动图 。
（ 一 ） 对象交互模型在面向对象的方法中,一切元素都与对象紧密相关,事件也不例外 。 因此,对象在其生命期中不断地与其它对象交互 。 使用对象交互模型来描述用例图中的每个用例,从对象观点来描述用例的动态交互过程 。
在ＵＭＬ中,交互模型由两类图来描述：
顺序图 （ Sequence diagram） 强调的是对象交互行为的时间,顺序,,直观描述了对象的生存期,用消息传送来清晰地描述了在对象生存期中某一时刻的动态行为 。 只适宜描述简单的对象交互情况 。
合作图 （ Collaboration diagram） 强调的是对象合作的交互行为关系,对象间由各种关联连接,对象之间的合作情况 （ 交互情况 ） 使用消息流来表示,但消息没有发送时间和传送时间的概念 。 适宜描述对象数目较多,交互情况教复杂的情况 。
五、建立动态模型退出上页首页 下页
,Meeting
Administration,Meeting
,Meeting
Administrattor
1:DefineMeeting(meeting)
[IsMeetingExisted=.T.] 3:Fail(MeetingExisted)
2:{new(meeting)}
图 19 定义会议的顺序图当用户向会议中心申请召开会议时,首先要定义一个会议 。 会议管理者发送 DefineMeeting
消息给 Meeting Administration对象,消息参数是有关会议的一个临时对象 (meeting),根据该临时对象检查会议是否存在？ 若不存在,创建新会议,2:{new(meeting)},若当条件表达式为真时：
[IsMeetingExisted=.T.],表示会议已经被定义,不需要再定义 。
1、用例：定义会议 (Define Meeting)的顺序图退出上页首页 下页当用户确定要取消某个会议时,首先检查会议是否定义,如果没有可以直接删除,否则要先取消相关的会议 。
如图 20所示,首先系统用户对象 MeetingAdministrator发出 RemoveMeeting (MeetingName)消息给对象 MeetingAdministration,通过消息的参数检索要取消的会议对象,并向该对象发出取消会议召开的消息 。 表达式,[IsOpen=.F.]”表示如果会议不处于召开状态,就取消它 。 表达式
,[IsAllMeetingInstancesCanceled=.T.]”表示该会议的所有会议召开都已经被取消,则会议管理就发出取消会议召开的消息 。 否则返回取消失败 （ 如会议正在召开 ） 的消息 。
2,用例,取消会议 (Remove Meeting )的顺序图图 20 取消会议的顺序图
,Meeting
Administration
,Meeting
Instance,MeetingAdministrator
1,RemoveMeeting (MeetingName)
[IsAllMeetingInstancesCanceled=.F.]
5:Fail(MeetingExisted)
2:CancelMeetingInstance()
,Meeting
[IsAllMeetingInstancesCanceled
=.T.]4:Fail(MeetingExisted)
[IsOpen=.F.]
3:Cancel()
退出上页首页 下页
３,用例,撤消会议召开（ Cancel Requestment） 的顺序图
,Meeting
Administration,Meeting
,Meeting
Instance
,Meeting
Room
,Post Office
1:CancelMeetingInstance(Instance) [IsOpen=.F.]
2:Cancel() 3:Release() 4:DelieverInformation (cancellation)
图 21 撤消会议召开的顺序图要 撤消某个会议召开,发送 Cancel 信息给 MeetingInstance对象 。 该对象先要在 Meeting对象中注销自己,再归还已分配的会议室,并向参会人员发 撤消会议的通知 。
图 21中会议管理对象 发送给会议对象的消息 CancelMeetingInstance(Instance)中的参数用于检索会议召开 。 条件表达式 [IsOpen=.F.]表示如会议召开未进行,则 撤消会议召开 。 如果会议已进行,则返回失败消息 （ 图中未列出 ） 。
退出上页首页 下页
,Post Office
,Meeting
Administration,Meeting
,Meeting
Instance
,Meeting
Room
1:AddMeetingInstance(instance) 2:{new}
6:AssignMeetingInstance ()
7:DelieverInformation (info)
5:AttachMeetingRoom(room)
4,AddGrooupAttendee (group)
3:AddAttendee (member)
图 22 撤消会议召开的顺序图如果时间合法，
就创建一个会议召开对象。
４,用例,申请会议召开（ Request Meeting Instance） 的顺序图用户申请一个会议召开时,应该指定会议召开的名称,召开的时间,及会议参加人员 。
图 22中 instance,member,grou,room,info都是临时对象,instance记录了用户指定的会议属性 （ 时间,参加人数等 ）,member为一个参会代表,是 Attendee group参会人员组的对象；
而 room是满足要求的会议室 。
４,用例,申请会议召开退出上页首页 下页六,合 作 图 与活动 图对于简单的对象交互情况,顺序图可以作很好的描述,可是,当交互对象数目增加,交互情况复杂时,顺序图就很难描述清楚了,可用合作图来描述 。
合作图描述了系统中所有对象之间的交互合作关系,注重对象之间的整体交互情况,交互关系由消息流来表示 。 在 Rose中,还可以将顺序图与合作图进行转换 。 本案例不再给出合作图 。
七,活动图活动图模型主要用于描述系统在问题域空间中的活动流程,活动图可以方便地描述系统中的并发活动 。 由于本例中并没有复杂的并发活动,而且也也没有明显的基于核心的,具有复杂状态和行为的对象,所以可以不必画出合作图和活动图 。
六、合作图退出上页首页 下页
二,医院病房监护系统三、会议管理系统案 例采用 OMT方法对 银行网络系统 ATM(Auto Trade Machine) 进行分析和设计。
一、问题的陈述银行网络系统包括人工出纳和分行共享的自动出纳机；各分理处用自己的计算机处理业务 （ 保存帐户,处理事务等 ） ；各分理处与出纳站通过网络通信；出纳站录入帐户和事务数据；自动出纳机与分行计算机通信；
自动出纳机与用户接口,接受现金卡；发放现金；打印收据；分行计算机与拨款分理处结帐 。
要求系统正确处理同一帐户的并发访问；网络费用平均摊派给各分理处。图１给出了银行网络系统的示意图。
银行网络系统 ATM(Auto Trade Machine)
自动出纳机自动出纳机自动出纳机出纳站分理处计算机分理处计算机出纳站帐户帐户图 1 银行网络系统的示意图用户分行计算机退出首页 下页 末页案 例 一二,类的识别方法常用的识别类的方法有：名词识别法,系统实体识别法,使用重用,从用例中识别类等 。
１,名词识别法识别问题域中的实体,实体的描述通常用名词,名词短语,名词性代词的形式出现 。
用指定语言对系统进行描述；
从系统描述中标识名词,名词短语,名词性代词；
识别确定 （ 取,舍 ） 类 。
２,系统实体识别法不关心系统的运作流程及实体之间的通信状态,而只考虑系统中的人员,组织,地点,表格,报告等实体,经过分析将他们识别为类 （ 或对象 ） 。
被标识的实体有：系统需要存储,分析,处理的信息实体,系统内部需要处理的设备,与系统交互的外部系统,系统相关人员,系统的组织实体 。
在确定类时,常使用两类技术：
⑴ 分解技术 将整体类和组合类分解 。 可控制单个类的规模 。
⑵ 抽象技术 根据一些类的相似性建立抽象类,并建立抽象类与这些类之间的继承关系 。
抽象类实现了系统内部的重用,很好地控制了复杂性,并为所有子类定义了一个公共的界面,使设计局部化,提高系统的可修改性和可维护性 。
退出上页首页 下页 末页三、建立对象模型根据下述原则进一步确定类：
① 去掉冗余类：如两个类表述同一信息,应保留最具有描述能力的类,如,用户,与,顾客,是重复的描述,由于,顾客,更具有描述性,故保留它,删除,用户,。
② 去掉不相干的类：删除与问题无关或关系不大的类,如,费用,。
③ 删除模糊的类：有些初始类边界定义不确切,或范围太广,应该删除 。 如,系统,,,安全措施,,
,记录保管,,,银行网络,。
④ 删除那些性质独立性不强的,而应该是类,属性,的候选类：如,帐户数据,,,收据,,,现金,,
,事务数据,。
⑤ 所描述的操作不适宜作为对象类,并被其自身所操纵,所描述的只是实现过程中的暂时的对象,应删去 。 如,软件,,,访问,。
（一）确定类采用名词识别法：检查问题陈述中的所有名词,得到初始类：
软件 银行网络 分行计算机 系统 分行 出纳站分理处 分理处计算机 自动出纳机 出纳员 帐户数据 帐户现金卡 事务数据 用户 顾客 收据 记录保管事务 费用 安全措施 访问 现金最终确定的类为：
分行计算机 分行 出纳站 出纳员 分理处 分理处计算机自动出纳机 帐户 现金卡 事务 顾客退出上页首页 下页 末页
（ 二 ） 为每个建模实体准备数据词典 — 描述模板对类进行精确描述,如ＡＴＭ系统中类的范围,成员,方法的限制等 。
（ 三 ） 确定关联两个或多个类之间的相互依赖关系就是关联,实现关联的方式有多种 。
关联通常用描述性动词和动词词组表示 。
可以从问题陈述中抽去所有可能的关联表述,在银行网络系统示例中所有可能的关联,大多数是直接抽取问题中的动词词组而得到的 。 但在陈述中,有些动词词组表述的关联是不明显的,或在问题陈述中是找不到的,还有一些关联与客观世界或人的假设有关,必须同用户一起确定这种关联 。
即关联通常由以下方面确定：
１,银行网络系统问题陈述中抽取 可能 的关联 （ 动词词组 ）
２,隐含的动词词组
３,基于问题域的知识
４,去掉不必要和不正确的关联三、建立对象模型退出上页首页 下页 末页
１,银行网络系统问题陈述中的关联银行网络包括出纳站和自动出纳机 。
分行共享自动出纳机分理处提供分理处计算机分理处计算机保存帐户分理处计算机处理帐户支付事务分理处拥有出纳站出纳站与分行计算机通信出纳员为帐户录入事务自动出纳机接受现金卡自动出纳机与用户接口自动出纳机发放现金自动出纳机打印收据系统处理并发访问分理处提供软件费用分摊给分理处
３,基于问题域的知识分理处雇佣的出纳员现金卡访问帐户
２,隐含的动词词组分行由分理处组成分理处拥有帐户分行拥有分行计算机系统提供记录保管系统提供安全顾客有现金卡
（三）确定关联退出上页首页 下页 末页
４,去掉不必要和不正确的关联使用下列标准去掉不必要和不正确的关联：
（ 1） 若某个类已被删除,那么与它有关的关联也必须删除或者用其他类来重新表述 。 在示例中,删除了,银行网络,,相关的关联也要删除 。
（ ２ ） 不相干的关联或实现阶段的关联 。 删除所有问题域之外的关联或涉及实现结构中的关联,如,系统处理并发访问,就是一种实现的概念 。
（ ３ ） 动作 。 关联应描述应用域的结构性质而不是瞬时事件,因此应删除,自动出纳机接受现金卡,,,自动出纳机与用户接口,等 。
（ ４ ） 派生关联,省略那些可以用其他关联来定义的关联 。 因为这种关联是 冗 余的 。
银行网络系统的初步对象图如图２所示,其中含有关联 。
（三）确定关联退出上页首页 下页 末页图２初始对象图建立对象模型图 2 银行网络系统的初始对象类图分行 分理处 帐户 顾客分行计算机自动出纳机 远程事务分理处计算机 出纳员 现金卡出纳站 出纳事务通信通信所有所有所有雇佣涉及涉及访问认可有有拥有组成录入由录入录入?
退出上页首页 下页 末页
（ 四 ） 确定类属性属性通常用修饰性的名词词组来表示 。 属性一般不可能在问题陈述中完全表述出来,应分析应用领域,并考虑最主要的属性 。
只考虑与具体应用直接相关的属性,不要考虑那些超出问题范围的属性；找出重要属性,避免那些只用于实现的属性,要为各个属性取有意义的名字 。
按下列标准删除不必要的和不正确的属性：
（ 1） 限定词：若属性值固定下来后,能减少关联的重数,则可考虑把该属性重新表述为一个限定词 。 如银行码,站代码及雇员号等是限定词,不作为属性 。
（ 2） 内部值：若属性描述了对象的非公开的内部状态,则应从对象模型中删除该属性 。
（ 3） 细化：在分析阶段应忽略那些不可能对大多数操作有影响的属性 。
图３给出了银行网络系统对象模型的部分属性 。
退出上页首页 下页 末页确定类属性退出上页首页 下页 末页图 3 银行网络系统的部分属性自动出纳机分发现金远程事务种类,日期,时间,数量顾客名字地址现金卡密码雇员号站代码分理处名字帐户号卡片码
银行码分理处计算机?
帐户余额、类型贷款限定出纳员名字出纳事务出纳站银行码分行分行计算机 银行码站代码
（ 五 ） 使用继承来细化类使用继承来共享公共结构,以此来重新组织类：
１,自底而上 将现有类的共性一般化为父类 。
找出具有相同属性,关联,操作的类,来发现继承,例如：,出纳事务,和,远程事务,其属性与主要操作是是类似的,则将它们的共性一般化,得到父类,事务,。
２,自顶而下 将现有类细化为更具体的子类 。
若假设的具体化与现有的类发生冲突,则说明该类结构不恰当,当同一关联名多次出现,且意义也相同时,应尽量具体化为相联系的类 。 例如,事务,从,出纳站,和,自动出纳机,进入,
,录入站,就是,出纳站,和,自动出纳机,的一般化 。
图４给出了加入继承后银行网络系统的对象模型 。
退出上页首页 下页 末页图 4 使用继承来细化类退出上页首页 下页 末页图 4 银行网络系统的对象模型银行码出纳站录入站远程事务帐户余额、类型贷款限定顾客名字地址出纳员名字现金卡密码事务种类,日期,时间,数量分行计算机 银行码站代码银行码分行自动出纳机分发现金出纳事务雇员号站代码分理处名字帐户号卡片码?
银行码分理处计算机
（六）完善对象模型在软件开发的全过程中,需要不断地完善对象模型 。 可以从以下几方面考虑：
１,检查是否有缺少的对象
如果一个类中,存在毫无关系的属性和操作,则应该分解这个类 。
一般化体系不清楚,可分离为两个类 。
存在名称及目的相同的 冗 余关联,则通过一般化创建一个父类,并组织关联 。
２,查找多余的类若类中缺少属性,操作和关联,删除该类 。
３,查找缺少的关联
４,系统的改进
⑴ 现金卡有多个独立的特性,分解为卡片权限和现金卡 。 卡片权限是银行用来鉴别用户访问权限的卡片,表示一个或多个用户帐户的访问权限；各个卡片权限对象中可能具有好几个现金卡,每张都带有安全码,卡片码,它们附在现金卡上,表示银行的卡片权限 。
现金卡是自动出纳机得到标识码的数据卡片,它也是银行代码和现金卡代码的数据载体 。
⑵ 为了,事务,与,帐户,之间的传输描述具有一般性,增加,更新,。 因为一般在每个帐户中,
一个,事务,包括一个或多个,更新,,一个,更新,是对帐户的一个动作,它们是取款,存款,查询之一 。 即事务由若干更新组成,更多涉及到帐户 。
⑶ 由于,分理处,与,分理处计算机,之间的区别不影响分析,可将,分理处计算机,并入,分理处,。 同理,将,分行计算机,并入,分行,。
以上改进如图５所示 。
退出上页首页 下页 末页图 5 完善对象模型退出上页首页 下页 末页图 5 修改后的对象模型录入站 远程事务现金卡银行名、卡片码安全号出纳员事务出纳员名字出纳站分行 银行码站代码帐户余额、类型贷款限定顾客名字地址自动出纳机分发现金事务种类、日期、时间、数量卡片权限密码、限制更新数量、类型
雇员号站代码分理处名字帐户号卡片码?
录入 组成
拥有拥有雇用 访问标识发行被录入开始涉及维持有有
四,建立动态模型动态分析从寻找外部可见的模拟和响应事件开始,确定各对象的可能事件的顺序,在分析阶段不考虑算法的执行,它是实现模型的一部分 。 通常动态模型有,事件跟踪表,状态图 。
建立动态模型的步骤分为４步：
１,准备典型的对话脚本脚本是事件序列,每当系统中的对象与外部用户发生互换信息时,就产生一个事件,所互换的信息值就是该事件的参数 。 对于各事件,应确定触发事件的动作对象和该事件的参数 。 包括,正常脚本,,
,例外脚本,,
自动出纳机与用户交互的正常的脚本如下所示：
⑴ 自动出纳机请求用户插入卡片；用户插入现金卡 。
⑵ 自动出纳机接受卡片并读出它的卡号 。
⑶ 自动出纳机要求密码,用户键入密码,4011”。
⑷ 自动出纳机与分行确认卡号和密码；分理处检查它并通知承兑的自动出纳机 。
⑸ 自动出纳机要求选择事务类型 （ 取款,存款,转户及查询 ）,用户选择取款 。
⑹ 自动出纳机要求现金数量；用户输入 ￥ 100。
⑺ 自动出纳机要求分行处理事务；分行把要求转给分理处,确认事务成功 。
⑻ 自动出纳机分发现金并且要求用户取现金；用户取现金 。
⑼ 自动出纳机提示用户是否想继续；用户指出不继续 。
⑽ 自动出纳机打印收据,退出卡,并请求用户取出它们；用户拿走收据和卡 。
⑾ 自动出纳机请求用户插入 。
退出上页首页 下页 末页自动出纳机与用户交互的例外的脚本如下所示：
⑴ 自动出纳机请求用户插入卡；用户插入现金卡 。
⑵ 自动出纳机接受卡并读它的卡号 。
⑶ 自动出纳机要求密码；用户键入,9999,。
⑷ 自动出纳机与分行确认卡号和密码,在咨询分理处后拒绝它 。
⑸ 自动出纳机指示密码错并要求重新键入；用户键入,4011：,分行确认成功 。
⑹ 自动出纳机请求用户选择事务类型；用户选择取款 。
⑺ 自动出纳机请求键入现金数量；用户改变选择并键入,CANCEL”（ 取消 ） 。
⑻ 自动出纳机退出卡并且请求用户拿走卡；用户取出卡 。
⑼ 自动出纳机请求用户插入卡 。
２,确定事件根据脚本确定所有的外部事件,事件包括：发送者,接收者,外设信号,输入,中断,转换和动作等 。 使用脚本可以发现正常事件,但不要遗漏条件和异常事件 。
３,画出事件跟踪表把脚本表示成一个事件跟踪表,即不同对象间的事件排序表,图６ 给出了银行网络系统的事件跟踪表 。 图 7 给出了事件流图,它给出类之间的所有事件 。 事件流图是对象图的一个动态对照,对象图中路径反映了可能的信息流,而事件流图反映了可能的控制流 。
退出上页首页 下页 末页退出上页首页 下页 末页图 6 银行网络系统的事件追综图用户 自动出纳机 分行 分理处确认帐号插入卡要求密码输入密码要求类型输入类型要求数量输入数量分发现金要求取现金取现金提示继续终止打印收椐退出卡要求取卡取卡显示屏确认银行卡银行帐户正确处理银行事务银行事务成功帐户正确处理事务事务成功图 7系统的事件图自动出纳机的事件流图退出上页首页 下页 末页图 7 银行网络系统的事件图用户分理处自动出纳机分行确认卡及银行,处理银行事务分理处事务成功,失败,分理处帐户正确事务成功,事务失败,
帐户正确,不正确帐户,
密码,银行代码插入卡，输入密码，类型，取现金，取卡不显示主屏可读卡,要求密码,类型,数量,取消信息,分发现金,要求继续,不正确帐户信息确认帐户处理事务
４,构造状态图对各对象类建立状态图,反映对象接收和发送的事件,每个脚本或事件跟踪表都对应于状态图中一条路径 。
在银行网络系统示例中,自动出纳机,出纳站,分行和分理处对象都是动作对象 。 用来互换事件,而现金卡,
事务和帐户都是被动对象,不交换事件,顾客和出纳员都是动作对象,它们同录入站的交互作用已经表示出来了 。 但顾客和出纳员对象都是系统外部的因素,不在系统内部实现 。 图给出了自动出纳机的状态图,图８
给出了,分行,类的状态图,图给出了,分理处,类的状态图 。
图8自动出纳机类的状态图为重要的类建立状态图退出上页首页 下页 末页图 8,自动出纳机”类的状态图检查
do:要求密码核对
do:确认帐户选择
do:要求类型输数据
do:要求数量开始
do:显示屏?
插入插入密码帐户正确输入类型取卡片不可读
do:不可读卡信息取消
do:取消信息帐户错误
do:帐户错误信息失败
do:失败信息取消取消插入卡卡片退出
do:退出卡,取卡片结束
do:打印收据继续否
do:请求继续发现金
do:请求继续事物
do:处理事务事务成功取现金终止取消输入事务帐户错取消 取消密码错事务失败等
５
秒图 9分行类的状态图退出末页图 9,分行”类的状态图
do:处理分理处事务
do:确认分理处代码
do:确认卡
［ 正确代码 ］
分理处事务成功／事务成功
处理事务确认帐户 ［ 错误代码 ］ ／错的分理处代码?
错的分理处帐户／ 错的帐户错的分理处帐户ＯＫ／ 错的密码
分理处密码／ 帐户ＯＫ
分理处事务失败／事务失败上页首页 下页
do:更新帐户
do:确认卡片号
do:确认密码
［有效］
［成功］／分理处事务成功?处理分理处事务确认分理处与卡片 ［无效］／错的分理处帐户?
［无效］／错的分理处密码
［有效］ ／分理处帐户ＯＫ
［失败］／分理处事务失败图 10,分理处”类的状态图五,建立功能模型功能模型描述了值之间的依赖关系,通常用分层的数据流图描述 。 数据流图有助于表示功能依赖关系,
其中的处理对应于状态图的活动和动作,其中的数据流对应于对象图中的对象或属性 。
建立功能模型的步骤是：
１,确定输入,输出值先列出输入,输出值,输入输出值是系统与外部世界之间的事件的参数 。 检测问题陈述,从中找出遗漏的所有输入输出值 。 由于所有系统与外部世界之间的交互都经过自动出纳机,因而所有输入输出值都是自动出纳机事件的参数 。 图给出了自动出纳机的输入输出值 。
退出上页首页 下页 末页图 11 自动出纳机的输入输出值现金卡用户自动出纳机银行码 卡片码帐户类型事务类型密码现金 收据信息图 12 自动出纳机顶层数据流图自动出纳机顶层数据流图
2,建立数据流图退出上页首页 下页 末页数据流图说明输出值是怎样从输入值 得来的,数据流图通常按层次组织 。 最顶层由单个处理组成,
也可由收集输入,计算值及生成结果的一个综合处理构成 。 图给出自动出纳机顶层数据流图 。
将顶层图中的处理扩展成更低层次的数据流图,如果第二层次图中的处理仍包含一些可细化的处理,
它们还可继续扩展,图 13是图 12中,执行事务,处理的扩展 。
现金卡用户读输入 执行事务产生输出帐户结算银行码 卡码密码数量事务类型现金 收据信息帐户类型图 13 自动出纳机“执行事务”数据流图
“执行事务,加工的分解退出上页首页 下页 末页图 13 自动出纳机“执行事务”数据流图更新帐户选择帐户确认密码选择卡选择分理处分行银行码银行码卡码无效卡码不正确密码卡授权密码密码帐户类型帐户不正确帐户无效事务现金、收据数量、事务类型帐户不正确的银行码
3、描述处理退出上页首页 下页 末页当数据流图已细化到一定程度后,对各处理进行描述,描述方法用自然语言,伪码及判定树等,描述可以是说明的或过程的 。
说明性描述确定了输入,输出值之间的关系 。 说明性描述优于过程性描述,因为它隐含实现的考虑 。 过程性描述确定一个算法来实现处理功能,算法只是用来确定处理干什么 。 过程性描述实现起来较为容易 。
下面给出,更新帐户,处理的描述：
IF 取款数目超过当前帐户结算,
退出事务,不发现金
IF 取款数目不超过当前帐户结算,
记帐并分发要求的现金
IF 事务是存款,
建立帐户并无现金分发
IF 事务是状态请求,
无现金分发在任何情况收据显示自动出纳机编号,日期,时间,帐户编号,
事务类型,数量 （ 若有 ） 以及新的结算 。
监视病情更新病历产生病情报告一,问题的描述在医院的病房里,将病症监视器安置在每个病床,对病人进行监护 。 监视器将病人的病症信号 （ 组合 ）
实时地传送到中央监护系统进行分析处理 。 在中心值班室里,值班护士使用中央监护系统对病员的情况进行监控,监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析,当病症出现异常时,系统会立即自动报警,并打印病情报告和更新病历 。 系统根据医生的要求随时打印病人的病情报告,系统还定期自动更新病历 。
退出下页 末页病房 中央值班室医院病房监护系统案 例 二二,简单的需求分析说明系统名称：医院病房监护系统根据分析系统主要实现以下功能：
1,病症监视器可以将采集到的病症信号 （ 组合 ）,格式化后实时的传送到中央监护系统 。
2,中央监护系统将病人的病症信号与标准的病症信号库里的病症信号的正常值进行比较,当病症出现异常时系统自动报警 。
3,当病症信号异常时,系统自动更新病历并打印病情报告 。
4,值班护士可以查看病情报告并进行打印 。
5,医生可以查看病情报告,要求打印病情报告,也可以查看或要求打印病历 。
6,系统定期自动更新病历 。
三,用 UML的静态建模机制定义并描述本系统的静态结构
（ 一 ） 建立系统的用例图通过以下六个问题识别角色
(1)谁使用系统的主要功能？
(2)谁需要系统的支持以完成日常工作任务？
(3)谁负责维护,管理并保持系统正常运行？
(4)系统需要应付 （ 或处理 ） 哪些硬设备？
(5)系统需要和哪些外部系统交互？
(6)谁 （ 或什么 ） 对系统运行产生的结果 （ 值 ） 感兴趣？
退出上页首页 下页 末页需求分析通过回答这六个问题以后,再进一步分析可以识别出本系统的四个角色：值班护士,医生,病人,标准病症信号库 。
角色描述模板角色,病 人角色职责：
提供病症信号角色职责识别：
负责生成,实时提供各种病症信号 。
角色,值班护士角色职责：
负责监视病人的病情变化角色职责识别：
(1)使用系统主要功能
(2)对系统运行结果感兴趣角色,标准病症信号库角色职责：
负责向系统提供病症信号的正常值角色职责识别：
(1)负责保持系统正常运行
(2)与系统交互角色,医 生角色职责：
对病人负责,负责处理病情的变化角色职责识别：
(1)需要系统支持以完成其日常工作
(2)对系统运行结果感兴趣通过分析可以初步识别出系统的用例为：中央监护,病症监护,提供标准病症信号,病历管理,病情报告管理 。 顶层用例图为：
退出上页首页 下页 末页提供标准病症信号病历管理病人标准病症信号库医生值班护士病症监护病情报告管理中央监护,使用,
,使用,
,使用,
角色描述将用例细化,可以得到分解的用例：
1,中央监护分解为,a 分解信号 将从病症监护器传送来的组合病症信号分解为系统可以处理的信号 。
b 比较信号 将病人的病症信号与标准信号比较 。
c 报警 如果病症信号发生异常 （ 即高于峰值 ）,发出报警信号 。
d 数据格式化 将处理后的数据格式化以便写入病历库 。
2,病症监护分解为,e 信号采集 采集病人的病症信号 。
f 模数转化 将采集来的模拟信号转化为数字信号 。
g 信号数据组合 将采集到的脉搏,血压等信号数据组合为一组信号数据 。
h 采样频率改变 根据病人的情况改变监视器采样频率 。
3,提供标准病症信号 i（ 此用例不分解 ）
4,病历管理分解为,j 生成病历
k 查看病历
l 更新病历
m 打印病历
5,病情报告分解为,n 显示病情报告 在显示器上显示病情
o 打印病情报告 在打印机打印病情报告退出上页首页 下页 末页用例细化给出细化的用例图退出上页首页 下页 末页病人模数转化数据格式化值班护士报警信号采集比较信号标准病症信号库医生信号数据组合采样频率改变提供标准病症信号生成病历查看病历 更新病历打印病历显示病情报告打印病情报告分解信号,Extend,
,Extend,
,Extend,
,use》
,use》
,use》
,use》
,use》
,use》
,use》,use》
细化的用例图
（ 二 ） 识别系统的类通过名词识别法和系统实体识别法等方法可以识别出系统的十二个类,
以下用类图这种简单明了的方法分别表示出类的名称,属性,操作 。
见下图：
医生用户名密码查看病情报告 （ ）
要求打印病情报告 （ ）
查看病历 （ ）
要求打印病历 （ ）
病人姓名性别年龄病症提供病症信号 （ ）
病症监视器采集频率病症信号格式化信号数据 （ ）
采集信号 （ ）
信号组合 （ ）
报警信号声音灯光文字报警 （ ）
数模转化 （ ）
病历库类型大小容量生成病历 （ ）
更新病历 （ ）
查看病历 （ ）
打印病历 （ ）
病人病症信号脉搏血压体温生成病症信号 （ ）
病历格式病人基本情况打印时间生成病历 （ ）
查看病历 （ ）
打印病历 （ ）
标准病症信号脉搏血压体温生成标准信号 （ ）
用户名密码查看病情报告 （ ）
打印病情报告 （ ）
值班护士类型大小容量提供标准信号 （ ）
标准病症信号库标题格式生成病情报告 （ ）
查看病情报告 （ ）
打印病情报告 （ ）
病情报告输入输出分解信号 （ ）
比较信号 （ ）
报警 （ ）
数据格式化 （ ）
中央监护系统退出上页首页 下页 末页类的识别再进一步在类图中标明类之间的关系：
退出上页首页 下页 末页
*
*
*
*
* *
*
11 1
1
1
1
1 1 1
1
1
1
1
1
11
值班护士 医生 病人病症监视病人病症信号病历病历库病情报告报警信号 中央监护系统标准病症信号标准病症信号库
1
1
1
报警监视系统类图
（ 三 ） 用包图和配置图描述系统的体系结构通过一定的分组机制得到以下包图：
用户医生值班护士病人病历管理病历用户界面病情报告局部监视报警信号病症监视器中央监护系统病人病症信号标准病症信号数据库病历库标准病症信号库用户层用户界面层应用层数据库层退出上页首页 下页 末页包图接下来用配置图进一步描述系统的网络结构四,用 UML的动态建模机制定义并描述系统结构元素的动态特性及行为
（ 一 ） 下面给出两个关系很紧密的状态图退出上页首页 下页 末页病症监视器的状态图信号采集模数转化 数据信号组合 发送信号数据局部显示开解信号 开解信号数据比较数据信号异常比较数据信号正常 格式化的数据报警更新病历更新日期到 发生病情异常发送报警标志数据格式化 数据格式化打印请求中央监护系统的状态图打印病情报告数据库服务器标准病症信号库病历库
TCP/IP TCP/IP
应用服务器中央监护系统局部监视 客户端用户界面状 态 图 与 配 置图
（ 二 ） 用时序图和合作图描述病人病情异常时系统的情况,其他情况从略 。
时序图,
病情报告监视器采集信号发送信号信号异常返回 打印更新中央监视系统 病历 报警信号退出上页首页 下页 末页合作图：
采集信号 发送信号 信号异常打印更新监视器 中央监视系统 报警信号病情报告病历时 序 图 与 合 作图
（ 三 ） 用活动图描述系统在监护病人时的状态变化退出上页首页 末页信号正常更新时间到信号异常时间间隔未到采集信号分析比较信号判断是否正常 判断更新时间报 警 更新病历 打印病情报告活动图一,问题陈述有一个对外营业的会议中心,有各种不同规格的会议室,为用户提供以下服务：
１,用户可以按照会议人数,会议时间预订会议室 。 可以只预订１次,也可预订定期召开的会议 。
２,开会前允许修改会议时间,人数,重新选择会议室,甚至取消预订的会议 。
３,确定会议预订后,会议中心负责会务管理：包括通过邮寄或电子邮件,通知开会人员有关会议信息,制作代表证等 。
４,系统根据会议室的使用情况 （ 紧张与否 ）,调整,更改会议室和会议时间,并调整修改预订会议的时间 。
会议管理系统退出下页 末页案 例 三二、建立 用例模型
1,识别角色找出所有可能与系统发生交互行为的外部实体,对象,系统 。
考虑系统的主要功能的使用者,就会想到用户和系统管理者,但如果直接将用户定义为角色,系统的所有功能几乎都由用户使用 。 根据问题的描述,系统要求将会议和会议的召开分开来 。
从会议的角度看,允许用户定义,更改或删除一个会议 。
从会议召开的角度看,允许用户为某个会议定义召开时间,参加人数,更改相应的数据或删除已定义的会议召开 。
因此,将用户识别为,会议管理者,和,会议申请者,两个角色 。
本系统定义以下角色：
会议管理者 （ Meeting Administrator）
会议申请者 （ Meeting Instance Requester）
邮局 （ Post Office ）
会议人员管理 （ Attendee Management ）
系统维护者 （ System Maintainer ）
退出上页首页 下页在识别角色的基础上,列出与角色相关的用例,有的用例与多个角色相关,经过分析,确定系统的用例 （ 打? ） 。
⑴ 与会议管理者相关的用例：
定义一个会议 （ Define Meeting ）?
更改一个会议 （ Alter Meeting ）?
删除一个会议 （ Remove Meeting ）?
⑵ 与会议申请者相关的用例：
申请会议召开 （ Request Meeting Instance ）?
更改申请 （ Chang Request ）?
取消申请 （ Cancel Request ）?
定义参加人员 （ Add Attendee ）?
归还会议室 （ Release Room ）?
2,用例识别退出上页首页 下页
2,用例识别
⑶ 与邮局相关的用例：
申请会议召开 （ Request Meeting Instance ）
更改申请 （ Modify Request ）
取消申请 （ Cancel Request ）
⑷ 与会议人员管理相关的用例：
定义参加人员 （ Add Attendee ）
取消申请 （ Cancel Request ）
申请会议召开 （ Request Meeting Instance ）?
更改申请 （ Modify Request ）
⑸ 与系统维护者相关的用例：
会议室维护 （ Meeting Room Maintenance ）?
设定预定时限 （ Set Reservation Tome Limit ）?
在确定角色和用例的基础上,画出用例图 （ 图１ ） 。
退出上页首页 下页
3、会议管理系统的 Use case图图 1 会议管理系统的 Use case图归还会议室申请会议召开更改申请取消申请定义参加人员会议召开申请者邮局会议人员管理设置预定时限会议室维护定义会议更改会议删除会议系统维护者会议管理员退出上页首页 下页用例 1,定义会议 （ Define Meeting ）
输入会议名称确定会议规模确定会议类型其中会议规模是指参会人数范围 。
用例２,更改会议 （ Alter Meeting ）
改变会议名称改变会议规模改变会议召开频度用例３,删除会议 （ Remove Meeting ）
如果该会议没有召开申请从会议列表中删除如果该会议有召开申请取消与之相关的会议召开信息删除该会议使用：
用例 8 删除参加人员 （ Remove Attendee ）
用例 6 取消申请 （ Cancel Request）
4,对用例的进一步描述用例 4,申请会议召开 （ Request Meeting Instance)
确定召开时间 （ 年,月,日 ）
确定参加人员确定侯选会议室发会议通知使用：
用例 11 发会议通知 （ Inform of Meeting）
用例 13 选择参加组 （ Select Group Attendee）
扩展：
① 如果召开时间在申请时限之外用例 12 申请拒绝 (Request Rejection ）
② 如果还没定义参加人员用例 7 定义参加人员 (Add Attendee )
用例 5：更改申请 （ Modify Request ）
更改召开时间更改参加人员更改取得会议室发会议更改通知使用：
用例 13 选择参加组 （ Select Group Attendee）
用例 11 发会议通知 (Inform of Meeting)
扩展：
① 如果更改的时间不合法用例 12 申请拒绝 （ Request Rejection）
② 用例 7 定义参加人员 (Add Attendee )
退出上页首页 下页用例 6：取消会议召开 （ Cancel Request）,
取消申请归还会议室发会议取消通知使用：
用例 8 归还会议室 （ Release Room）
用例 14 发会议取消通知 （ InformRejection）
扩展：
① 如果会议已召开用例 12 申请拒绝 （ Request Rejection）
用例 7：定义参加人员 (Add Attendee )
输入参加人员的详细信息定义参加组用例 9：会议维护 （ Meeting RoomMaintenance）
加入一个会议室 （ 用例 15)
标记一个会议室不可用 （ 用例 16)
查询会议室预定情况 （ 用例 17)
用例 10：设置预定时限制 （ Set Reservation Tome Limit）
设置时间限用例 11：发会议通知 (Inform of Meeting)
从会议人员管理获得参加人员的投递地址填写通知 （ 会议召开时间,会议室号码 ）
发送通知用例 12：申请拒绝 （ Request Rejection）
作废当前的一切输入中字止用户当前的操作用例 13：选择会议参加人员组 (Select Group Attendee)
浏览会议组成员选择参加组用例 14:会议取消通知 （ Inform of Cancellation)
从会议人员管理处获取参加人员地址填写通知发送通知用例８：归还会议室 （ Release Room）
输入会议室号码输入使用时间删除参加人员归还会议室使用：
用例９会议室维护 （ Meeting RoomMaintenance）
用例 18 删除参加人员 （ Remove Attendee）
退出上页首页 下页用例 15:增加会议室 （ Add Meeting Room）
输入会议室号码输入会议室规模输入会议室可使用状态 （ 可使用,不可使用 ）
加入该会议室用例 16:设置会议室不可使用 （ Set Unusable Flag）
输入会议室号码通知该会议室的预定者标记该会议室的可所以状态为不可用用例 17:查询会议室的使用情况 (Browse Meetingroom usage)
输入会议室号码查询本用例返回会议室的使用状态 （ 已使用,空闲 ） 和会议室的可否使用情况 。
用例 18：删除会议参加人员 （ Remove Attendee）
删除参加人员删除参加组图 2描述了会议管理系统完整的用例模型 。
退出上页首页 下页
5、完整的会议管理系统的 Use case图图 2 完整的会议管理系统 Use case图 退出上页首页 下页除了用例模型外,其它模型都依赖于类模型,因此,类模型是ＯＯ方法的核心,类模型从对象的角度描述系统的组成,描述类 （ 对象 ） 及相互间的关系 。 为了建立类模型,首先要识别类,鉴于篇幅,这里就不再讨论类的识别过程 。 通过分析,识别以下类：
1,Meeting类,标识一个会议 （ 名称,类型,规模 ） 。
2,MeetingInstance类,Meeting类的子类,对会议时间,人数等进行描述 。
3,MeetingRoom类,描述会议室的有关信息 。
4,MeetingAdministration类,管理会议 。
5,Attendee类,描述参会人员 （ 姓名,性别,地址,头衔等 ） 。
6,GroupAttende类,创建一个参加会议的组 。
7,Address类,描述邮寄地址 E-mail地址 。
8,PostOffic类,负责发送邮寄通知 。
9,AttendeeManagement类,数据库管理 。
10,ReservationCriteria类,定义会议室预定准则 。
11,Information类,构造一条通知 。
三,建立类模型退出上页首页 下页该类与会议召开不同,它标识了一个会议 （ 图 3）,因此,其属性包括会议名称,类型,规模 （ 参加会议的人数 ） 。 其操作则有：增加会议,取消会议 。 一个会议往往有多个子会议 （ 子类 ） 的召开,因此,必须描述 Meeting类与其子类 MeetingInstance类之间的关联,如图 4所示 。
2,MeetingInstance类
MeetingInstance类是 Meeting类的子类,描述会议的具体情况,会议的开始 (Start Time)、
结束时间 (End Time),参会的人数 (AttendeeNumber),其操作有：添加参加人员 AddAttendee()
,添加参加人员组 AddGroupAttendee(),而 AttachMeetingRoom()表示为该类分配一个会议室,
而 Cancel()则表示取消该会议的召开 。
Meeting
Name
Type
Size
AddMeetingInstance()
CancelMeetingInstance()
图 3Meeting类图
Meeting
MeetingInstance
Start Time
EndTime
AttendeeNumber
AddAttendee()
AttachMeetingRoom()
AddGroupAttendee()
Cancel()
图 4 MeetingInstance类 图
1,Meeting类退出上页首页 下页
MeetingRoom
Capacity
BuildingCode
DoorCode
Status
AssignMeetingInstance ()
SetInvalidate()
Release()
MeetingInstance
Meeting
图 5 MeetingRoom类 图该类描述了有关会议室的情况,因此 MeetingRoom类的属性包括：会议室的规模 Capacity,位置
BuildingCode,DoorCode,使用状态 Status（ 正在使用,已预定,空闲和不可用 ） 等 。
该类的操作有,AssignMeetingInstance() 将 MeetingRoom 分配给 MeetingInstance 对象,而
SetInvalidate()则表示当会议室出现故障时,将其状态设置为不可用 。 Release()为归还会议室 。
当会议被预定后,为了便于查询某个会议室预定给了哪个会议,应建立类 MeetingRoom 与类
MeetingInstanc之间的双向关联,这里定义为 1,1。
3,MeetingRoom类退出上页首页 下页
Attendee
Name
Sex
Postaddress
EmailAddress
Title
MeetingInstance
1 1..*
图 6 Attendee类 图
Attendee类 描述参加会议人员的有关信息,如：姓名,性别,地址,E-mail地址,头衔等 。
MeetingInstance类与 Attendee类之间有一对多的关联,1..*” 。
5,GroupAttendee类
MeetingInstance
GroupAttendee
MemberNumber
GroupName
AddAttendee()
DeleteAttendee()
1 0..* Attendee1 1..*
图 7 GroupAttendee类 图该类可 创建一个参加会议的组,便于按照小组选择参加会议的人员 。 MeetingInstance类与 GroupAttendee类之间有一对多的 关联,0..*”。
4,Attendee类退出上页首页 下页系统中有两种地址：电子邮件地址 （ EmailAddress ） 和邮寄地址 （ PostAddress ）,而且,
每个参加会议的人,可以有一个或者多个邮寄地址,有 0个或多个 Email地址 。 有关地址的属性,在再内这里不再讨论 。
负责发送邮寄通知 。 PostOffice类分别与 PostAddress,EmailAddress和 Information之间有一对多的关联 。
7,PostOffice类
1..*
Information EmailAddress
1..*
PostAddress
1..*(from Use Case View)
DelieverInformation( )
图 9 PostOffice类 图
PostOffice
Address
PostAddress EmailAddress
Attendee
图 8 Address类 图
1..* 0..*
6,Address类退出上页首页 下页
Information
Notice Topic
Receiver Title
Receiver name
Time
Event
Explanation
SendTime
Sendr
Signature
Create()
MeetingRoom
图 10 Information类 图该类用于构造一条通知,由于在本系统中,通常有三种：会议召开通知,会议更改通知,
会议取消通知 。 如下例所示,通知的内容常包括标题,接受者,会议内容,会议时间及发通知的时间等 。
XXXX会议召开通知
XX先生：
定于 2003年 9月 15日在樱都会议中心召开 XXXX会议 。
XXXX会议筹备组
2003年 8月 20日
8,Information类退出上页首页 下页
GroupAttendee Attendee
AttendeeManagement
(from Use Case View)
AttendNumber()
GroupAttendeeNumber()
AddAttendee()
ChangeAttendee()
AddGroupAttendee()
DeleteGroupAttendee()
图 11 AttendeeManagement类 图该类使用数据库对参加会议的人员进行管理 。 分析阶段只确定该类与系统的接口,有关数据库的设计在设计阶段解决 。 该类与 GroupAttendee类及 Attendee类的关联如图 11所示 。
10,ReservationCriteria类该类定义了预定会议室的准则 (如时间 ),并建立会议实例 （ MeetingInstanee 类 ） 与该类之间的联系 。
ReservationCriteria
TimeCriteria
setCrieria()
GetCriteria()
MeetingInstanee
图 12 ReservationCriteria类 图
9,AttendeeManagement类退出上页首页 下页该类管理系统中由用户定义的所有会议,并提供给用户友好的用户界面 。 由于该类有定义会议 （ DefineMeeting）,更改会议 （ AlterMeeting）,删除会议 （ RemoveMeeting ）
等操作,建立与 Meeting类之间的关联关系 。
MeetingName:string
MeetingAdministration
(from eetingPack)
MeetingNumber:int
DefineMeeting()
AlterMeeting()
RemoveMeeting()
Meeting
(from MeetingPack)
图 13 MeetingAdministration类 图
11,MeetingAdministration类退出上页首页 下页
Meeting
MeetingName:stringMeetingAdministration
ReservationCriteria MeetingInstance
Information
MeetingRoom
1..*1..* 1..*
PostOffice
GroupAttendeeAttendeeManagement
Address
PostAddress EmailAddress
Attendee
1..*
0..*
1..*
0..*
1
1
0..*
0..*
0..*
1 11
图 14 会议管理系统 类 图会议管理系统类图退出上页首页 下页四、建立系统包图引入包图来对类进行管理,图１５本系统的包图 。
系统由会议包 (MeetingPack),人员包 (AttendeePack)和邮寄包 (PostOfficePack)三类包组成 。 图
16,图 17,图 18分别描述了这三类包的构成 。
退出上页首页 下页
PostOfficePack
图 15 系统包图
MeetingPack AttendeePack
1、会议包（ MeetingPack ）
2,人员包（ AttendeePack ） 3、邮寄包（ PostOfficePack ）
GroupAttendee
Address
PostAddress EmailAddress
Attendee
图 17 人员包构成
0..*1..*
1..*
1
图 18 邮寄包构成
Information
PostOffice
（ from Use Case View）
1..*
0..*
MeetingMeetingName:stringMeetingAdministration
ReservationCriteria MeetingInstance
MeetingRoom
图 16 会议包构成
1 1 1
包图退出上页首页 下页静态模型关注的是系统各成分的组织结构,而动态模型则要描述系统各成分之间的交互行为,即系统的动态特征 。 结合本系统,建立动态模型,包括交互图,合作图,活动图 。
（ 一 ） 对象交互模型在面向对象的方法中,一切元素都与对象紧密相关,事件也不例外 。 因此,对象在其生命期中不断地与其它对象交互 。 使用对象交互模型来描述用例图中的每个用例,从对象观点来描述用例的动态交互过程 。
在ＵＭＬ中,交互模型由两类图来描述：
顺序图 （ Sequence diagram） 强调的是对象交互行为的时间,顺序,,直观描述了对象的生存期,用消息传送来清晰地描述了在对象生存期中某一时刻的动态行为 。 只适宜描述简单的对象交互情况 。
合作图 （ Collaboration diagram） 强调的是对象合作的交互行为关系,对象间由各种关联连接,对象之间的合作情况 （ 交互情况 ） 使用消息流来表示,但消息没有发送时间和传送时间的概念 。 适宜描述对象数目较多,交互情况教复杂的情况 。
五、建立动态模型退出上页首页 下页
,Meeting
Administration,Meeting
,Meeting
Administrattor
1:DefineMeeting(meeting)
[IsMeetingExisted=.T.] 3:Fail(MeetingExisted)
2:{new(meeting)}
图 19 定义会议的顺序图当用户向会议中心申请召开会议时,首先要定义一个会议 。 会议管理者发送 DefineMeeting
消息给 Meeting Administration对象,消息参数是有关会议的一个临时对象 (meeting),根据该临时对象检查会议是否存在？ 若不存在,创建新会议,2:{new(meeting)},若当条件表达式为真时：
[IsMeetingExisted=.T.],表示会议已经被定义,不需要再定义 。
1、用例：定义会议 (Define Meeting)的顺序图退出上页首页 下页当用户确定要取消某个会议时,首先检查会议是否定义,如果没有可以直接删除,否则要先取消相关的会议 。
如图 20所示,首先系统用户对象 MeetingAdministrator发出 RemoveMeeting (MeetingName)消息给对象 MeetingAdministration,通过消息的参数检索要取消的会议对象,并向该对象发出取消会议召开的消息 。 表达式,[IsOpen=.F.]”表示如果会议不处于召开状态,就取消它 。 表达式
,[IsAllMeetingInstancesCanceled=.T.]”表示该会议的所有会议召开都已经被取消,则会议管理就发出取消会议召开的消息 。 否则返回取消失败 （ 如会议正在召开 ） 的消息 。
2,用例,取消会议 (Remove Meeting )的顺序图图 20 取消会议的顺序图
,Meeting
Administration
,Meeting
Instance,MeetingAdministrator
1,RemoveMeeting (MeetingName)
[IsAllMeetingInstancesCanceled=.F.]
5:Fail(MeetingExisted)
2:CancelMeetingInstance()
,Meeting
[IsAllMeetingInstancesCanceled
=.T.]4:Fail(MeetingExisted)
[IsOpen=.F.]
3:Cancel()
退出上页首页 下页
３,用例,撤消会议召开（ Cancel Requestment） 的顺序图
,Meeting
Administration,Meeting
,Meeting
Instance
,Meeting
Room
,Post Office
1:CancelMeetingInstance(Instance) [IsOpen=.F.]
2:Cancel() 3:Release() 4:DelieverInformation (cancellation)
图 21 撤消会议召开的顺序图要 撤消某个会议召开,发送 Cancel 信息给 MeetingInstance对象 。 该对象先要在 Meeting对象中注销自己,再归还已分配的会议室,并向参会人员发 撤消会议的通知 。
图 21中会议管理对象 发送给会议对象的消息 CancelMeetingInstance(Instance)中的参数用于检索会议召开 。 条件表达式 [IsOpen=.F.]表示如会议召开未进行,则 撤消会议召开 。 如果会议已进行,则返回失败消息 （ 图中未列出 ） 。
退出上页首页 下页
,Post Office
,Meeting
Administration,Meeting
,Meeting
Instance
,Meeting
Room
1:AddMeetingInstance(instance) 2:{new}
6:AssignMeetingInstance ()
7:DelieverInformation (info)
5:AttachMeetingRoom(room)
4,AddGrooupAttendee (group)
3:AddAttendee (member)
图 22 撤消会议召开的顺序图如果时间合法，
就创建一个会议召开对象。
４,用例,申请会议召开（ Request Meeting Instance） 的顺序图用户申请一个会议召开时,应该指定会议召开的名称,召开的时间,及会议参加人员 。
图 22中 instance,member,grou,room,info都是临时对象,instance记录了用户指定的会议属性 （ 时间,参加人数等 ）,member为一个参会代表,是 Attendee group参会人员组的对象；
而 room是满足要求的会议室 。
４,用例,申请会议召开退出上页首页 下页六,合 作 图 与活动 图对于简单的对象交互情况,顺序图可以作很好的描述,可是,当交互对象数目增加,交互情况复杂时,顺序图就很难描述清楚了,可用合作图来描述 。
合作图描述了系统中所有对象之间的交互合作关系,注重对象之间的整体交互情况,交互关系由消息流来表示 。 在 Rose中,还可以将顺序图与合作图进行转换 。 本案例不再给出合作图 。
七,活动图活动图模型主要用于描述系统在问题域空间中的活动流程,活动图可以方便地描述系统中的并发活动 。 由于本例中并没有复杂的并发活动,而且也也没有明显的基于核心的,具有复杂状态和行为的对象,所以可以不必画出合作图和活动图 。
六、合作图退出上页首页 下页
