软件工程案例分析

案例分析会议管理系统医院病房监护系统银行网络系统ATM目录

一、问题陈述

有一个对外营业的会议中心，有各种不同规格的会议室，为用户提供以下服务：1、用户可以按照会议人数、会议时间预订会议室。可以只预订１次，也可预订定期召开的会议。2、开会前允许修改会议时间、人数，重新选择会议室，甚至取消预订的会议。3、确定会议预订后，会议中心负责会务管理：包括通过邮寄或电子邮件，通知开会人员有关会议信息，制作代表证等。4、系统根据会议室的使用情况（紧张与否），调整、更改会议室和会议时间，并调整修改预订会议的时间。会议管理系统退出下页末页案例一二、建立用例模型1、识别角色

找出所有可能与系统发生交互行为的外部实体、对象、系统。考虑系统的主要功能的使用者，就会想到用户和系统管理者，但如果直接将用户定义为角色，系统的所有功能几乎都由用户使用。根据问题的描述，系统要求将会议和会议的召开分开来。从会议的角度看，允许用户定义、更改或删除一个会议。从会议召开的角度看，允许用户为某个会议定义召开时间、参加人数、更改相应的数据或删除已定义的会议召开。因此，将用户识别为“会议管理者”和“会议申请者”两个角色。本系统定义以下角色：会议管理者（MeetingAdministrator）会议申请者（MeetingInstanceRequester）邮局（PostOffice）会议人员管理（AttendeeManagement）系统维护者（SystemMaintainer）退出上页首页下页末页

在识别角色的基础上，列出与角色相关的用例，有的用例与多个角色相关，经过分析，确定系统的用例（打）。⑴与会议管理者相关的用例：

定义一个会议（DefineMeeting）更改一个会议（AlterMeeting）

删除一个会议（RemoveMeeting

）

⑵与会议申请者相关的用例：

申请会议召开（RequestMeetingInstance）

更改申请（ChangRequest）

取消申请（CancelRequest）

定义参加人员（AddAttendee）

归还会议室（ReleaseRoom）

2、用例识别退出上页首页下页末页2、用例识别

⑶与邮局相关的用例：

申请会议召开（RequestMeetingInstance）更改申请（ModifyRequest）取消申请（CancelRequest

）⑷与会议人员管理相关的用例：定义参加人员（AddAttendee）取消申请（CancelRequest）申请会议召开（RequestMeetingInstance）更改申请（ModifyRequest）

⑸与系统维护者相关的用例：会议室维护（MeetingRoomMaintenance）

设定预定时限（SetReservationTomeLimit）

在确定角色和用例的基础上，画出用例图（图１）。

退出上页首页下页末页3、会议管理系统的Usecase图图1会议管理系统的Usecase图归还会议室申请会议召开更改申请取消申请定义参加人员会议召开申请者邮局会议人员管理设置预定时限会议室维护定义会议更改会议删除会议系统维护者会议管理员

退出上页首页下页末页用例1、定义会议（DefineMeeting）输入会议名称确定会议规模确定会议类型其中会议规模是指参会人数范围。用例２、更改会议（AlterMeeting）改变会议名称改变会议规模改变会议召开频度用例３、删除会议（RemoveMeeting）如果该会议没有召开申请从会议列表中删除如果该会议有召开申请取消与之相关的会议召开信息删除该会议使用：用例8删除参加人员（RemoveAttendee）用例6取消申请（CancelRequest）4、对用例的进一步描述用例4、申请会议召开（RequestMeetingInstance)确定召开时间（年、月、日）确定参加人员确定侯选会议室发会议通知使用：用例11发会议通知（InformofMeeting）用例13选择参加组（SelectGroupAttendee）扩展：①如果召开时间在申请时限之外用例12申请拒绝(RequestRejection）②如果还没定义参加人员用例7定义参加人员(AddAttendee

)用例5：更改申请（ModifyRequest）更改召开时间更改参加人员更改取得会议室发会议更改通知使用：用例13选择参加组（SelectGroupAttendee）用例11发会议通知(InformofMeeting)扩展：①如果更改的时间不合法用例12申请拒绝（RequestRejection）②用例7定义参加人员(AddAttendee)退出上页首页下页末页用例6：取消会议召开（CancelRequest）、取消申请归还会议室发会议取消通知使用：用例8归还会议室（ReleaseRoom）用例14发会议取消通知（InformRejection）扩展：①如果会议已召开用例12申请拒绝（RequestRejection）用例7：定义参加人员(AddAttendee)输入参加人员的详细信息定义参加组用例9：会议维护（MeetingRoomMaintenance）加入一个会议室（用例15)标记一个会议室不可用（用例16)查询会议室预定情况（用例17)用例10：设置预定时限制（SetReservationTomeLimit）设置时间限用例11：发会议通知(InformofMeeting)

从会议人员管理获得参加人员的投递地址填写通知（会议召开时间、会议室号码）发送通知用例12：申请拒绝（RequestRejection）作废当前的一切输入中字止用户当前的操作用例13：选择会议参加人员组(SelectGroupAttendee)浏览会议组成员选择参加组用例14:会议取消通知（InformofCancellation)从会议人员管理处获取参加人员地址填写通知发送通知

用例８：归还会议室（ReleaseRoom）输入会议室号码输入使用时间删除参加人员归还会议室使用：用例９会议室维护（MeetingRoomMaintenance）用例18删除参加人员（RemoveAttendee）退出上页首页下页末页用例15:增加会议室（AddMeetingRoom）输入会议室号码输入会议室规模输入会议室可使用状态（可使用、不可使用）加入该会议室用例16:设置会议室不可使用（SetUnusableFlag）输入会议室号码通知该会议室的预定者标记该会议室的可所以状态为不可用用例17:查询会议室的使用情况(BrowseMeetingroomusage)输入会议室号码查询本用例返回会议室的使用状态（已使用、空闲）和会议室的可否使用情况。用例18：删除会议参加人员（RemoveAttendee）删除参加人员删除参加组图2描述了会议管理系统完整的用例模型。退出上页首页下页末页5、完整的会议管理系统的Usecase图图2完整的会议管理系统Usecase图退出上页首页下页末页

除了用例模型外，其他模型都依赖于类模型，因此，类模型是ＯＯ方法的核心，类模型从对象的角度描述系统的组成，描述类（对象）及相互间的关系。为了建立类模型，首先要识别类，鉴于篇幅，这里就不再讨论类的识别过程。通过分析，识别以下类：1、Meeting类，标识一个会议（名称、类型、规模）。2、MeetingInstance类,Meeting类的子类，对会议时间、人数等进行描述。3、MeetingRoom类,描述会议室的有关信息。4、MeetingAdministration类，管理会议。5、Attendee类，描述参会人员（姓名、性别、地址、头衔等）。6、GroupAttende类，创建一个参加会议的组。7、Address类，描述邮寄地址E-mail地址。8、PostOffice类，负责发送邮寄通知。9、AttendeeManagement类，数据库管理。10、ReservationCriteria类，定义会议室预定准则。11、Information类，构造一条通知。三、建立类模型退出上页首页下页末页

该类与会议召开不同，它标识了一个会议（图3），因此，其属性包括会议名称、类型、规模（参加会议的人数）。其操作则有：增加会议、取消会议。一个会议往往有多个子会议（子类）的召开，因此，必须描述Meeting类与其子类MeetingInstance类之间的关联，如图4所示。2、

MeetingInstance类

MeetingInstance类是Meeting类的子类，描述会议的具体情况，会议的开始(StartTime)、结束时间(EndTime)，参会的人数(AttendeeNumber)，其操作有：添加参加人员AddAttendee()、添加参加人员组AddGroupAttendee()，而AttachMeetingRoom()表示为该类分配一个会议室，而Cancel()则表示取消该会议的召开。MeetingMeetingInstanceStartTimeEndTimeAttendeeNumberAddAttendee()AttachMeetingRoom()AddGroupAttendee()Cancel()MeetingNameTypeSizeAddMeetingInstance()CancelMeetingInstance()图3Meeting类图图4MeetingInstance类图1、

Meeting类退出上页首页下页末页MeetingRoomCapacityBuildingCodeDoorCodeStatusAssignMeetingInstance()SetInvalidate()Release()MeetingInstanceMeeting图5MeetingRoom类图该类描述了有关会议室的情况，因此MeetingRoom类的属性包括：会议室的规模Capacity，位置BuildingCode、DoorCode，使用状态Status（正在使用、已预定、空闲和不可用）等。该类的操作有：AssignMeetingInstance()将MeetingRoom分配给MeetingInstance对象,而SetInvalidate()则表示当会议室出现故障时，将其状态设置为不可用。Release()为归还会议室。当会议被预定后，为了便于查询某个会议室预定给了哪个会议，应建立类MeetingRoom与类MeetingInstanc之间的双向关联，这里定义为1：1。3、MeetingRoom类退出上页首页下页末页AttendeeNameSexPostaddressEmailAddressTitleMeetingInstance11..*图6Attendee类图Attendee类描述参加会议人员的有关信息，如：姓名、性别、地址、E-mail地址、头衔等。MeetingInstance类与Attendee类之间有一对多的关联“1..*”。

5、GroupAttendee类MeetingInstanceGroupAttendeeMemberNumberGroupNameAddAttendee()DeleteAttendee()10..*Attendee11..*图7GroupAttendee类图该类可创建一个参加会议的组，便于按照小组选择参加会议的人员。MeetingInstance类与GroupAttendee类之间有一对多的关联“0..*”。4、Attendee类退出上页首页下页末页系统中有两种地址：电子邮件地址（EmailAddress）和邮寄地址（PostAddress），而且，每个参加会议的人，可以有一个或者多个邮寄地址，有0个或多个E-mail地址。有关地址的属性，在再内这里不再讨论。负责发送邮寄通知。PostOffice类分别与PostAddress、EmailAddress和Information之间有一对多的关联。

7、PostOffice类1..*InformationEmailAddress1..*PostAddress1..*(fromUseCaseView)DelieverInformation()图9PostOffice类图PostOfficeAddress

PostAddressEmailAddressAttendee图8Address类图1..*0..*6、Address类退出上页首页下页末页InformationNoticeTopicReceiverTitleReceivernameTimeEventExplanationSendTimeSendrSignatureCreate()MeetingRoom图10Information类图该类用于构造一条通知，由于在本系统中，通常有三种：会议召开通知，会议更改通知，会议取消通知。如下例所示，通知的内容常包括标题、接受者、会议内容、会议时间及发通知的时间等。XXXX会议召开通知XX先生：定于2005年9月15日在樱都会议中心召开XXXX会议。

XXXX会议筹备组2005年8月20日8、Information类退出上页首页下页末页GroupAttendeeAttendeeAttendeeManagement(fromUseCaseView)AttendNumber()GroupAttendeeNumber()AddAttendee()ChangeAttendee()AddGroupAttendee()DeleteGroupAttendee()图11AttendeeManagement类图该类使用数据库对参加会议的人员进行管理。分析阶段只确定该类与系统的接口，有关数据库的设计在设计阶段解决。该类与GroupAttendee类及Attendee类的关联如图11所示。

10、ReservationCriteria类

该类定义了预定会议室的准则(如时间)，并建立会议实例（MeetingInstanee类）与该类之间的联系。ReservationCriteriaTimeCriteriasetCrieria()GetCriteria()MeetingInstanee图12ReservationCriteria类图9、AttendeeManagement类退出上页首页下页末页该类管理系统中由用户定义的所有会议，并提供给用户友好的用户界面。由于该类有定义会议（DefineMeeting）、更改会议（AlterMeeting）、删除会议（RemoveMeeting）等操作，建立与Meeting类之间的关联关系。MeetingName:stringMeetingAdministration(fromeetingPack)MeetingNumber:intDefineMeeting()AlterMeeting()RemoveMeeting()Meeting(fromMeetingPack)图13MeetingAdministration类图11、MeetingAdministration类退出上页首页下页末页MeetingMeetingName:stringMeetingAdministrationReservationCriteriaMeetingInstanceInformationMeetingRoom1..*1..*1..*PostOfficeGroupAttendeeAttendeeManagement

Address

PostAddressEmailAddressAttendee1..*0..*1..*0..*110..*0..*0..*111图14会议管理系统类图会议管理系统类图退出上页首页下页末页四、建立系统包图引入包图来对类进行管理，图15为本系统的包图。系统由会议包(MeetingPack)、人员包(AttendeePack)和邮寄包(PostOfficePack)三类包组成。图16、图17、图18分别描述了这三类包的构成。PostOfficePack图15系统包图MeetingPackAttendeePack退出上页首页下页末页1、会议包（MeetingPack）2、人员包（AttendeePack）3、邮寄包（PostOfficePack）GroupAttendeeAddress

PostAddressEmailAddressAttendee图17人员包构成0..*1..*1..*1图18邮寄包构成InformationPostOffice（fromUseCaseView）1..*0..*MeetingMeetingName:stringMeetingAdministrationReservationCriteriaMeetingInstanceMeetingRoom图16会议包构成111包图退出上页首页下页末页

静态模型关注的是系统各成分的组织结构，而动态模型则要描述系统各成分之间的交互行为，即系统的动态特征。结合本系统，建立动态模型，包括交互图、合作图、活动图。（一）对象交互模型

在面向对象的方法中，一切元素都与对象紧密相关，事件也不例外。因此，对象在其生命期中不断地与其它对象交互。使用对象交互模型来描述用例图中的每个用例，从对象观点来描述用例的动态交互过程。在UML中，交互模型由两类图来描述：顺序图（Sequencediagram）强调的是对象交互行为的时间“顺序”，直观描述了对象的生存期，用消息传送来清晰地描述了在对象生存期中某一时刻的动态行为。只适宜描述简单的对象交互情况。合作图（Collaborationdiagram）强调的是对象合作的交互行为关系，对象间由各种关联连接，对象之间的合作情况（交互情况）使用消息流来表示，但消息没有发送时间和传送时间的概念。适宜描述对象数目较多，交互情况教复杂的情况。五、建立动态模型退出上页首页下页末页：MeetingAdministration：Meeting：MeetingAdministrattor1:DefineMeeting(meeting)[IsMeetingExisted=.T.]3:Fail(MeetingExisted)2:{new(meeting)}图19定义会议的顺序图当用户向会议中心申请召开会议时，首先要定义一个会议。会议管理者发送DefineMeeting消息给MeetingAdministration对象,消息参数是有关会议的一个临时对象(meeting)，根据该临时对象检查会议是否存在？若不存在，创建新会议：2:{new(meeting)}，若当条件表达式为真时：[IsMeetingExisted=.T.]，表示会议已经被定义，不需要再定义。1、用例：定义会议(DefineMeeting)的顺序图退出上页首页下页末页当用户确定要取消某个会议时，首先检查会议是否定义，如果没有可以直接删除，否则要先取消相关的会议。如图20所示,首先系统用户对象MeetingAdministrator发出RemoveMeeting(MeetingName)消息给对象MeetingAdministration，通过消息的参数检索要取消的会议对象，并向该对象发出取消会议召开的消息。表达式“[IsOpen=.F.]”表示如果会议不处于召开状态，就取消它。表达式“[IsAllMeetingInstancesCanceled=.T.]”表示该会议的所有会议召开都已经被取消，则会议管理就发出取消会议召开的消息。否则返回取消失败（如会议正在召开）的消息。2、用例：取消会议(RemoveMeeting)的顺序图图20取消会议的顺序图：MeetingAdministration：MeetingInstance：MeetingAdministrator1：RemoveMeeting(MeetingName)[IsAllMeetingInstancesCanceled=.F.]5:Fail(MeetingExisted)2:CancelMeetingInstance()：Meeting[IsAllMeetingInstancesCanceled=.T.]4:Fail(MeetingExisted)[IsOpen=.F.]3:Cancel()退出上页首页下页末页３、用例：撤消会议召开（CancelRequestment）的顺序图：MeetingAdministration：Meeting：MeetingInstance：MeetingRoom：PostOffice1:CancelMeetingInstance(Instance)[IsOpen=.F.]2:Cancel()3:Release()4:DelieverInformation(cancellation)图21撤消会议召开的顺序图要撤消某个会议召开，发送Cancel信息给MeetingInstance对象。该对象先要在Meeting对象中注销自己，再归还已分配的会议室，并向参会人员发撤消会议的通知。图21中会议管理对象发送给会议对象的消息CancelMeetingInstance(Instance)中的参数用于检索会议召开。条件表达式[IsOpen=.F.]表示如会议召开未进行，则撤消会议召开。如果会议已进行，则返回失败消息（图中未列出）。退出上页首页下页末页图22撤消会议召开的顺序图：PostOffice：MeetingAdministration：Meeting：MeetingInstance：MeetingRoom1:AddMeetingInstance(instance)2:{new}6:AssignMeetingInstance()7:DelieverInformation(info)5:AttachMeetingRoom(room)4:AddGrooupAttendee(group)3:AddAttendee(member)如果时间合法，就创建一个会议召开对象。４、用例：申请会议召开（RequestMeetingInstance）的顺序图用户申请一个会议召开时，应该指定会议召开的名称，召开的时间，及会议参加人员。图22中instance、member、group、room、info都是临时对象，instance记录了用户指定的会议属性（时间、参加人数等），member为一个参会代表，是Attendeegroup参会人员组的对象；而room是满足要求的会议室。４、用例：申请会议召开退出上页首页下页末页六、合作图与活动图对于简单的对象交互情况，顺序图可以作很好的描述，可是，当交互对象数目增加，交互情况复杂时，顺序图就很难描述清楚了，可用合作图来描述。合作图描述了系统中所有对象之间的交互合作关系，注重对象之间的整体交互情况，交互关系由消息流来表示。在Rose中，还可以将顺序图与合作图进行转换。本案例不再给出合作图。

七、活动图

活动图模型主要用于描述系统在问题域空间中的活动流程，活动图可以方便地描述系统中的并发活动。由于本例中并没有复杂的并发活动，而且也也没有明显的基于核心的、具有复杂状态和行为的对象，所以可以不必画出合作图和活动图。六、合作图退出上页首页监视病情更新病历产生病情报告一、问题的描述在医院的病房里，将病症监视器安置在每个病床，对病人进行监护。监视器将病人的病症信号（组合）实时地传送到中央监护系统进行分析处理。在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。系统根据医生的要求随时打印病人的病情报告，系统还定期自动更新病历。退出下页末页病房中央值班室医院病房监护系统案例二二、简单的需求分析说明系统名称：医院病房监护系统根据分析系统主要实现以下功能：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》细化的用例图（二）识别系统的类通过名词识别法和系统实体识别法等方法可以识别出系统的十二个类,以下用类图这种简单明了的方法分别表示出类的名称，属性，操作。见下图：医生用户名密码查看病情报告（）要求打印病情报告（）查看病历（）要求打印病历（）病人姓名性别年龄病症提供病症信号（）病症监视器采集频率病症信号格式化信号数据（）采集信号（）信号组合（）报警信号声音灯光文字报警（）数模转化（）病历库类型大小容量生成病历（）更新病历（）查看病历（）打印病历（）病人病症信号脉搏血压体温生成病症信号（）病历格式病人基本情况打印时间生成病历（）查看病历（）打印病历（）标准病症信号脉搏血压体温生成标准信号（）用户名密码查看病情报告（）打印病情报告（）值班护士类型大小容量提供标准信号（）标准病症信号库标题格式生成病情报告（）查看病情报告（）打印病情报告（）病情报告输入输出分解信号（）比较信号（）报警（）数据格式化（）中央监护系统退出上页首页下页末页类的识别再进一步在类图中标明类之间的关系：退出上页首页下页末页*******1111111111111111值班护士医生病人病症监视器

病人病症信号

病历病历库病情报告报警信号中央监护系统标准病症信号标准病症信号库

111报警监视系统类图（三）用包图和配置图描述系统的体系结构通过一定的分组机制得到以下包图：用户医生值班护士病人病历管理病历用户界面病情报告局部监视报警信号病症监视器中央监护系统病人病症信号标准病症信号数据库病历库标准病症信号库用户层用户界面层应用层数据库层退出上页首页下页末页包图接下来用配置图进一步描述系统的网络结构四、用UML的动态建模机制定义并描述系统结构元素的动态特性及行为（一）下面给出两个关系很紧密的状态图退出上页首页下页末页病症监视器的状态图信号采集模数转化数据信号组合发送信号数据局部显示开解信号开解信号数据比较数据信号异常比较数据信号正常格式化的数据报警更新病历更新日期到发生病情异常发送报警标志数据格式化数据格式化打印请求中央监护系统的状态图打印病情报告数据库服务器标准病症信号库病历库TCP/IPTCP/IP应用服务器中央监护系统局部监视客户端用户界面状态图与配置图（二）用时序图和合作图描述病人病情异常时系统的情况，其他情况从略。时序图：病情报告监视器采集信号发送信号信号异常返回打印更新中央监视系统病历报警信号退出上页首页下页末页合作图：采集信号发送信号信号异常打印更新监视器中央监视系统报警信号病情报告病历时序图与合作图（三）用活动图描述系统在监护病人时的状态变化退出上页首页信号正常更新时间到信号异常时间间隔未到采集信号分析比较信号判断是否正常判断更新时间报警更新病历打印病情报告活动图

采用OMT方法对银行网络系统ATM(AutoTradeMachine)进行分析和设计。一、问题的陈述银行网络系统包括人工出纳和分行共享的自动出纳机；各分理处用自己的计算机处理业务（保存账户、处理事务等）；各分理处与出纳站通过网络通信；出纳站录入账户和事务数据；自动出纳机与分行计算机通信；自动出纳机与用户接口，接受现金卡；发放现金；打印收据；分行计算机与拨款分理处结账。要求系统正确处理同一账户的并发访问；网络费用平均摊派给各分理处。图１给出了银行网络系统的示意图。银行网络系统ATM(AutoTradeMachine)自动出纳机自动出纳机自动出纳机出纳站分理处计算机分理处计算机出纳站账户账户图1银行网络系统的示意图用户分行计算机退出下页末页案例三

二、类的识别方法

常用的识别类的方法有：名词识别法、系统实体识别法、使用重用、从用例中识别类等。１、名词识别法

识别问题域中的实体，实体的描述通常用名词、名词短语、名词性代词的形式出现。用指定语言对系统进行描述；从系统描述中标识名词、名词短语、名词性代词；识别确定（取、舍）类。２、系统实体识别法

不关心系统的运作流程及实体之间的通信状态，而只考虑系统中的人员、组织、地点、表格、报告等实体，经过分析将他们识别为类（或对象）。被标识的实体有：系统需要存储、分析、处理的信息实体、系统内部需要处理的设备、与系统交互的外部系统、系统相关人员、系统的组织实体。

在确定类时，常使用两类技术：

⑴分解技术将整体类和组合类分解。可控制单个类的规模。

⑵抽象技术根据一些类的相似性建立抽象类，并建立抽象类与这些类之间的继承关系。抽象类实现了系统内部的重用，很好地控制了复杂性，并为所有子类定义了一个公共的界面，使设计局部化，提高系统的可修改性和可维护性。退出上页首页下页末页

三、建立对象模型根据下述原则进一步确定类：①去掉冗余类：如两个类表述同一信息，应保留最具有描述能力的类，如“用户”与“顾客”是重复的描述，由于“顾客”更具有描述性，故保留它，删除“用户”。②去掉不相干的类：删除与问题无关或关系不大的类，如“费用”。③删除模糊的类：有些初始类边界定义不确切，或范围太广，应该删除。如“系统”、“安全措施”、“记录保管”、“银行网络”。④删除那些性质独立性不强的，而应该是类“属性”的候选类：如“帐户数据”、“收据”、“现金”、“事务数据”。⑤所描述的操作不适宜作为对象类，并被其自身所操纵，所描述的只是实现过程中的暂时的对象，应删去。如“软件”，“访问”。

（一）确定类采用名词识别法：检查问题陈述中的所有名词，得到初始类：软件银行网络分行计算机系统分行出纳站分理处分理处计算机自动出纳机出纳员帐户数据帐户现金卡事务数据用户顾客收据记录保管事务费用安全措施访问现金

最终确定的类为：分行计算机分行出纳站出纳员分理处分理处计算机自动出纳机账户现金卡事务顾客退出上页首页下页末页

（二）为每个建模实体准备数据词典—描述模板对类进行精确描述，如ＡＴＭ系统中类的范围、成员、方法的限制等。（三）确定关联

两个或多个类之间的相互依赖关系就是关联，实现关联的方式有多种。关联通常用描述性动词和动词词组表示。

可以从问题陈述中抽去所有可能的关联表述，在银行网络系统示例中所有可能的关联，大多数是直接抽取问题中的动词词组而得到的。但在陈述中，有些动词词组表述的关联是不明显的，或在问题陈述中是找不到的，还有一些关联与客观世界或人的假设有关，必须同用户一起确定这种关联。即关联通常由以下方面确定：１、银行网络系统问题陈述中抽取可能的关联（动词词组）２、隐含的动词词组３、基于问题域的知识４、去掉不必要和不正确的关联三、建立对象模型退出上页首页下页末页

１、银行网络系统问题陈述中的关联

银行网络包括出纳站和自动出纳机分行共享自动出纳机分理处提供分理处计算机分理处计算机保存账户分理处计算机处理账户支付事务分理处拥有出纳站出纳站与分行计算机通信出纳员为账户录入事务自动出纳机接受现金卡自动出纳机与用户接口自动出纳机发放现金自动出纳机打印收据系统处理并发访问分理处提供软件费用分摊给分理处３、基于问题域的知识

分理处雇佣的出纳员现金卡访问帐户２、隐含的动词词组分行由分理处组成分理处拥有账户分行拥有分行计算机系统提供记录保管系统提供安全顾客有现金卡（三）确定关联退出上页首页下页末页

４、去掉不必要和不正确的关联

使用下列标准去掉不必要和不正确的关联：

（1）

若某个类已被删除，那么与它有关的关联也必须删除或者用其他类来重新表述。在示例中，删除了“银行网络”，相关的关联也要删除。（２）不相干的关联或实现阶段的关联。删除所有问题域之外的关联或涉及实现结构中的关联，如“系统处理并发访问”就是一种实现的概念。（３）动作。关联应描述应用域的结构性质而不是瞬时事件，因此应删除“自动出纳机接受现金卡”，“自动出纳机与用户接口”等。（４）

派生关联，省略那些可以用其他关联来定义的关联。因为这种关联是冗余的。

银行网络系统的初步对象图如图２所示，其中含有关联。（三）确定关联退出上页首页下页末页

图２初始对象图

建立对象模型图2银行网络系统的初始对象类图分行分理处帐户顾客分行计算机自动出纳机远程事务分理处计算机出纳员现金卡出纳站出纳事务通信通信所有所有所有雇佣涉及涉及访问认可有有拥有组成录入录入录入退出上页首页下页末页

（四）确定类属性

属性通常用修饰性的名词词组来表示。属性一般不可能在问题陈述中完全表述出来，应分析应用领域，并考虑最主要的属性。只考虑与具体应用直接相关的属性，不要考虑那些超出问题范围的属性；找出重要属性，避免那些只用于实现的属性，要为各个属性取有意义的名字。按下列标准删除不必要的和不正确的属性：（1）限定词：若属性值固定下来后，能减少关联的重数，则可考虑把该属性重新表述为一个限定词。如银行码、站代码及雇员号等是限定词，不作为属性。

（2）内部值：若属性描述了对象的非公开的内部状态，则应从对象模型中删除该属性。

（3）细化：在分析阶段应忽略那些不可能对大多数操作有影响的属性。

图３给出了银行网络系统对象模型的部分属性。

退出上页首页下页末页

确定类属性退出上页首页下页末页图3银行网络系统的部分属性自动出纳机分发现金远程事务种类,日期,时间,数量顾客名字地址现金卡密码雇员号站代码分理处名字账户号卡片码银行码分理处计算机账户余额、类型贷款限定出纳员名字出纳事务出纳站银行码分行分行计算机银行码站代码

（五）使用继承来细化类使用继承来共享公共结构，以此来重新组织类：１、自底而上将现有类的共性一般化为父类。找出具有相同属性、关联、操作的类，来发现继承，例如：“出纳事务”和“远程事务”其属性与主要操作是是类似的，则将它们的共性一般化，得到父类“事务”。２、自顶而下将现有类细化为更具体的子类。

若假设的具体化与现有的类发生冲突，则说明该类结构不恰当，当同一关联名多次出现，且意义也相同时，应尽量具体化为相联系的类。例如“事务”从“出纳站”和“自动出纳机”进入，“录入站”就是“出纳站”和“自动出纳机”的一般化。

图4给出了加入继承后银行网络系统的对象模型。

退出上页首页下页末页图4使用继承来细化类退出上页首页下页末页图4银行网络系统的对象模型银行码出纳站录入站远程事务账户余额、类型贷款限定顾客名字地址出纳员名字现金卡密码事务种类,日期,时间,数量分行计算机银行码站代码银行码分行自动出纳机分发现金出纳事务雇员号站代码分理处名字账户号卡片码银行码分理处计算机

（六）完善对象模型在软件开发的全过程中，需要不断地完善对象模型。可以从以下几方面考虑：

１、检查是否有缺少的对象

如果一个类中，存在毫无关系的属性和操作，则应该分解这个类。

一般化体系不清楚，可分离为两个类。

存在名称及目的相同的冗余关联，则通过一般化创建一个父类，并组织关联。

２、查找多余的类若类中缺少属性、操作和关联，删除该类。

３、查找缺少的关联

４、系统的改进⑴现金卡有多个独立的特性，分解为卡片权限和现金卡。卡片权限是银行用来鉴别用户访问权限的卡片，表示一个或多个用户帐户的访问权限；各个卡片权限对象中可能具有好几个现金卡，每张都带有安全码、卡片码，它们附在现金卡上，表示银行的卡片权限。现金卡是自动出纳机得到标识码的数据卡片，它也是银行代码和现金卡代码的数据载体。⑵为了“事务”与“账户”之间的传输描述具有一般性，增加“更新”。因为一般在每个账户中，一个“事务”包括一个或多个“更新”，一个“更新”是对账户的一个动作，它们是取款、存款、查询之一。即事务由若干更新组成，更多涉及到账户。⑶由于“分理处”与“分理处计算机”之间的区别不影响分析，可将“分理处计算机”并入“分理处”。同理，将“分行计算机”并入“分行”。以上改进如图５所示。退出上页首页下页末页

图5完善对象模型退出上页首页下页末页图5修改后的对象模型录入站远程事务现金卡银行名、卡片码安全号出纳员事务出纳员名字出纳站分行银行码站代码账户余额、类型贷款限定顾客名字地址自动出纳机分发现金事务种类、日期、时间、数量卡片权限密码、限制更新数量、类型雇员号站代码分理处名字账户号卡片码录入组成拥有拥有雇用访问标识发行被录入开始涉及维持有有

四、建立动态模型动态分析从寻找外部可见的模拟和响应事件开始，确定各对象的可能事件的顺序，在分析阶段不考虑算法的执行，它是实现模型的一部分。通常动态模型有：事件跟踪表、状态图。建立动态模型的步骤分为４步：

１、准备典型的对话脚本脚本是事件序列，每当系统中的对象与外部用户发生互换信息时，就产生一个事件，所互换的信息值就是该事件的参数。对于各事件，应确定触发事件的动作对象和该事件的参数。包括“正常脚本”、“例外脚本”，自动出纳机与用户交互的正常的脚本如下所示：

⑴自动出纳机请求用户插入卡片；用户插入现金卡。⑵自动出纳机接受卡片并读出它的卡号。

⑶自动出纳机要求密码，用户键入密码“4011”。

⑷自动出纳机与分行确认卡号和密码；分理处检查它并通知承兑的自动出纳机。⑸自动出纳机要求选择事务类型（取款、存款、转户及查询），用户选择取款。⑹自动出纳机要求现金数量；用户输入￥100。⑺自动出纳机要求分行处理事务；分行把要求转给分理处，确认事务成功。⑻自动出纳机分发现金并且要求用户取现金；用户取现金。⑼自动出纳机提示用户是否想继续；用户指出不继续。⑽自动出纳机打印收据，退出卡，并请求用户取出它们；用户拿走收据和卡。⑾自动出纳机请求用户插入。

退出上页首页下页末页

自动出纳机与用户交互的例外的脚本如下所示：

⑴自动出纳机请求用户插入卡；用户插入现金卡。⑵自动出纳机接受卡并读它的卡号。⑶自动出纳机要求密码；用户键入：9999：。⑷自动出纳机与分行确认卡号和密码，在咨询分理处后拒绝它。⑸自动出纳机指示密码错并要求重新键入；用户键入：4011：，分行确认成功。⑹自动出纳机请求用户选择事务类型；用户选择取款。⑺自动出纳机请求键入现金数量；用户改变选择并键入“CANCEL”（取消）。⑻自动出纳机退出卡并且请求用户拿走卡；用户取出卡。⑼自动出纳机请求用户插入卡。２、确定事件

根据脚本确定所有的外部事件，事件包括：发送者、接收者、外设信号、输入、中断、转换和动作等。使用脚本可以发现正常事件，但不要遗漏条件和异常事件。３、画出事件跟踪表把脚本表示成一个事件跟踪表，即不同对象间的事件排序表，图６给出了银行网络系统的事件跟踪表。图7给出了事件流图，它给出类之间的所有事件。事件流图是对象图的一个动态对照，对象图中路径反映了可能的信息流，而事件流图反映了可能的控制流。

退出上页首页下页末页退出上页首页下页末页

图6银行网络系统的事件追综图用户自动出纳机分行分理处确认账号插入卡要求密码输入密码要求类型输入类型要求数量输入数量分发现金要求取现金取现金提示继续终止打印收椐退出卡要求取卡取卡显示屏确认银行卡银行账户正确处理银行事务银行事务成功账户正确处理事务事务成功

图7系统的事件图自动出纳