银行ATM自动取款机系统软件工程课程实验指导书毕业论文

《银行ATM自动取款机系统软件工程课程实验指导书毕业论文》由会员分享，可在线阅读，更多相关《银行ATM自动取款机系统软件工程课程实验指导书毕业论文（21页珍藏版）》请在装配图网上搜索。

1、 .软件工程课程实验指导书（Software Engineering）目 录序言1一、实验安排1第一阶段：ATM系统的分析1第二阶段：ATM系统的设计1第三阶段：用OMT方法分析与设计ATM2二、考核方式与评定标准2三、参考资料与系统初步分析31、ATM系统的需求概述3ATM系统的需求要点3需求述书写要点32、建立对象模型4确定类一对象4确定关联6划分主题9确定属性103、建立动态模型12编写脚本12设想用户界面13画事件跟踪图13画状态图14审查动态模型164、建立功能模型17画出基本系统模型图17画出功能级数据流图17描述处理框功能1819 / 21序言为帮助同学们牢固树立软件工程的思想，

2、必须理论联系实际。本实验是同学们获得用软件工程的思想、方法和技术开发简单软件项目的初步训练，主要目的是使同学们基本掌握用软件工程的思想开发软件的方法。通过本次实验，要求同学们掌握软件工程的基本思想，了解开发一个软件系统的主要阶段，每个阶段所采用的方法与应该生成的主要文档。为学生今后的软件开发实践无论从观念上还是实现上建立良好的基础。本实验以软件工程课程中面向对象方法的容为基础，利用面向对象技术中的OMT方法，针对一个具体的应用实例，如银行网络系统ATM，对其进行分析和设计。OMT（即对象模型技术）是一种软件工程方法学，它支持整个软件生命周期，覆盖了用户需求（即问题构成）、分析、设计和实现等阶段

3、。OMT方法使用建模思想，讨论如何建立一个实际的系统应用模型，从三个不同而又相关的角度建立三类模型：对象模型、动态模型和功能模型。每一个模型都提供了直观、形象图形表示。此外，本实验的完成将涉与到软件工程的其它方面的许多知识，例如何针对用户需求进行有效的软件需求分析，如何用软件工程的思想为用户建立一个有效的系统应用模型，为下一步的软件设计打下良好的基础。本实验对同学们的综合能力要求比较高，包括分析问题和处理问题的能力、实际动手能力如绘制图形的能力以与编写文档的能力等。具体操作时，又分为三个阶段：ATM系统的分析、ATM系统的设计与用OMT方法分析与设计ATM等来进行。一、实验安排第一阶段：ATM

4、系统的分析学时：2（一）实验目的通过分析ATM系统需求，确定各对象与其关联，分析并做出ATM系统的原始对象图。（二）实验容1、阅读ATM系统需求报告（也可自己调研完成），分析出整个系统的框架。2、对ATM系统进行进一步分析，确定系统中涉与的各个对象，理顺相互关联。按照冗余、无关、笼统、属性、操作、实现的原则筛选出正确的对象，并确定相对应的属性描述；再经过正名、分解、补充等方式来进一步完善后，适当运用数据库思想，分析并建立类似E/R图的ATM系统的对象图。第二阶段：ATM系统的设计学时：2（一）实验目的在分析ATM系统的基础上，对较佳的系统方案进行结构与详细设计。（二）实验容1、根据系统模型完成

5、概要设计。在概要设计阶段中，首先进行系统设计，从数据流图出发设想完成系统功能的多种合理的物理方案，并仔细比较这些方案选定一个最佳方案，然后进行软件结构设计，确定软件由哪些模块组成以与模块间的动态调用关系。其中层次图和结构图是描绘软件结构的有用工具。2、用Jackson或Warnier方法完成系统的详细设计。第三阶段：用OMT方法分析与设计ATM学时：2（一）实验目的用面向对象的方法和技术分析具体的ATM系统。（1）掌握面向对象的概念和思想；（2）针对一个用户需求，掌握分析方法，提高逻辑思维能力；（3）掌握建立三种模型的具体方法和步骤。（二）实验容要求学生采用OMT方法分析并设计ATM系统。1、

6、根据已知ATM系统需求与分析，重点建立相应的对象模型。并用直观、形象的图形表示。2、根据已知ATM系统需求与分析，建立动态模型。3、根据已知ATM系统需求与分析，建立功能模型。4、分析、对比三种模型的特点，充分理解软件设计中方法与模型的综合运用。二、考核方式与评定标准上机实验要求对软件工程的整个流程与编制思想进行综合认识，并能在实际的软件系统的编写中体会、分析，并加深理解。须提交的文档有：软件设计的全部文档（主要含：调研或需求报告、软件系统分析、软件系统各个方案的概要设计与其比较、较佳设计方案分析与数据流程、软件系统结构设计、系统功能分析与设计、系统功能调整与测试分析等）、软件系统的程序代码。

7、实验成绩满分为100分，其中，上机占50%（含平时上机操作与考勤），文档占50%。三、参考资料与系统初步分析ATMATMATM中央计算机分行计算机柜员终端账户分行计算机账户账户账户储户储户柜员1、ATM系统的需求概述图1-1 ATM（自动取款机）系统ATM系统的需求要点拟开发一个自动取款系统（参考图1-1），它是一个由自动取款机、中央计算机、分行计算机与柜员终端组成的网络系统。ATM和中央计算机由总行投资购买。总行拥有多台ATM，分别设在全市各主要街道上。分行负责提供分行计算机和柜员终端。柜员终端设在分行营业厅与分行下属的各个储蓄所。该系统的软件开发成本由各个分行分摊。银行柜员使用柜员终端处理

8、储户提交的储蓄事务。储户可以用现金或支票向自己拥有的某个账户存款或开新账户。储户也可以从自己的账户中取款。通常，一个储户可能拥有多个账户。柜员负责把储户提交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户。拥有银行账户的储户有权申请领取现金兑换卡。使用现金兑换卡可以通过ATM访问自己的账户。目前仅限于用现金兑换卡在ATM上提取现金（即取款），或查询有关自己账户的信息（如余额）。将来还可能要求用ATM来办理转账、存款。所谓现金兑换卡就是一个特制的磁卡，上面有分行代码和卡号。分行代码唯一标识总行

9、下属的一个分行，卡号确定了这卡可以访问哪些账户。通常，一卡可以访问储户的若干个账户，但是不一定能访问这个储户的全部账户。每卡仅属于一个储户所有，但是，同一卡可能有多个副本，因此，必须考虑同时在若干台ATM上使用同样的现金兑换卡的可能性。也就是说，系统应该能够处理并发的访问。当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。首先，ATM要求用户输入密码，接下来ATM把从这卡上读到的信息以与用户输入的密码传给中央计算机，请求中央计算机核对这些信息并处理这次事务。中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分

10、行计算机验证用户的密码。如果用户输入的密码是正确的，ATM就要求用户选择事务类型（取款、查询等）。当用户选择取款时，ATM请求用户输入取款额。最后，ATM从现金口吐出现金，并且打印账单交给用户。需求述书写要点通常，需求述的容包括：问题围，功能需求，应用环境与假设条件等。它应该阐明“做什么”而不是“怎么样做”；它描述的是用户的需求而不是提出解决问题的方法，并应该指明哪些是系统必要的性质，哪些是任选的性质；它应该避免对设计策略加过多的约束，也不要描述系统部结构，以免影响系统实现的灵活性。但是，对系统性能与系统外界环境交互协议的描述，对采用的软件工程标准、模块构造准则、将来可能做的扩充以与可维护性要

11、求等方面的描述，则是合适的需求。书写需求述是时，要尽力做到语法准确，真正反映用户的需求，而且要应该慎重选用名词、动词、形容词和同义词；更不能将实际需求和设计决策混为一谈。2、建立对象模型面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。通常，它从分析述用户需求的文件开始，再通过深入理解，抽象出目标系统的本质属性，并用模型对问题的进行精确而又简洁的表示，再以此分析模型为基础进行后继的设计。在概念上，我们可以认为面向对象分析大体上按照下列顺序进行：寻找类对象，识别结构，识别主题，定义属性，建立动态模型、建立功能模型，定义服务。但是，分析不可能是严格按照此顺序进行的，通常要多次反复构造

12、才能完全建立。面向对象分析首要的工作，是建立域的对象模型。这个模型描述了现实世界中的“类一对象”以与它们之间的关系，表示了目标系统的静态数据结构。静态数据结构对应用细节依赖较少，比较容易确定当用户的需求变化时。静态数据结构相对来说比较稳定。因此，用面向对象方法开发绝大多数软件时，都首先建立对象模型，然后再建立另外两个子模型。需求述、应用领域的专业知识以与关于客观世界的常识，是建立对象模型时的主要信息来源。如前所述，对象模型通常有五个层次。典型的工作步骤是，首先确定对象类和关联（因为它们影响系统整体结构和解决问题的方法)，对于大型复杂问题还要进一步划分出若干个主题；然后给类和关联增添属性，以进一

13、步描述它们；接下来利用适当的继承关系进一步合并和组织类。而对类中操作的最后确定，则需等到建立了动态模型和功能模型之后，因为这两个子模型更准确地描述了对类中提供的服务的需求。应该再一次强调指出的是，人认识客观世界的过程是一个渐进过程，是在继承前人知识的基础上，经反复迭代而不断深化的。因此，面向对象分析不可能严格按照顺序线性进行。初始的分析模型通常都是不准确不完整甚至包含错误的，必须在随后的反复分析中加以扩充和更正。此外，在面向对象分析的每一步，都应该仔细分析研究以前针对一样的或类似的问题域进行面向对象分析所得到的结果，并尽可能在本项目中重用这些结果。在描述面向对象分析的具体过程时，将按上述规则进

14、行处理。确定类一对象类一对象是在问题域中客观存在的，系统分析员的主要任务，就是通过分析找出这些类一对象。首先找出所有候选的类一对象；然后，从候选的类一对象中筛选掉不正确的或不必要的。首先，找出候选的类一对象对象是对问题域中有意义的事物的抽象，它们既可能是物理实休-也可髓是抽象概念。具体地说，爽多数客观事物可分为下述五类：(1) 可感知的物理实体，例如，飞机、汽车、书、房屋等。(2) 人或组织的角色，例如，医生、教师、雇主、雇员、计算机系、财务处等等。(3) 应该记忆的事件，例如，飞行、演出、访问、交通事故等等。(4) 两个或多个对象的相互作用，通常具有交易或接触的性质，例如，购买、纳税、结婚等

15、等。(5) 需要说明的概念，例如，政策、保险政策、法等等。在分析所面临的问题时，可以参照上列五类常见事物，找出在当前问题域中的候选类一对象。另一种更简单的分析方法，是所谓的非正式分析。这种分析方法以用自然语言书写的需求述为依据，把述中的名词作为类一对象的候选者，用形容词作为确定属性的线索，把动词作为服务(操作)的候选者。当然，用这种简单方法确定的候选者是非常不准确的，其中往往包含大量不正确的或不必要的事物。还必须经过更进一步的严格筛选。通常，非正式分析是更详细、更精确的正式的面向对象分析的一个很好的开端。下面以ATM系统为例，说明非正式分析过程。认真阅读给出的需求述，从述中找出下列名词，可以把

16、它们作为类一对象的初步的候选者：银行，自动取款机(ATM)系统，中央计算机，分行计算机，柜员终端，网络，总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问。通常，在需求述中不会一个不漏地写出问题域中所有有关的类一对象。因此，分析员应该根据领域知识或常识进一步把隐台的类一对象提取出来。例如，在ATM系统的需求述中虽然没写“通信链路”和“事务日志”，但是，根据领域知识和常识可以知道，在ATM系统中应该包含这两个实体。第二步，筛选出正确的类一对象显然，仅通过一个简单、机械的过程不

17、可能正确地完成分析工作。非正式分析仅仅帮助我们找到一些候选的类一卜对象接下来应该严格考察每个候选对象，从中去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象。筛选时主要依据下列标准删除不正确或不必要的类一对象： (1)冗余如果两个类表达了同样信息，则应该保留在此问题域中最富于描述力的名称。以ATM系统为例，上面用非正式分析法得出了34个候选的类，其中储户与用户，现金兑换卡与磁卡与副本分别描述了一样的二类信息，因此，应该去掉“用户”、“磁卡”、“副本”等冗余的类，仅保留“储户”和“现金兑换卡”这两个类。(2)无关现实世界中存在许多对象，不能把它们都纳入到系统中去仅需要把与

18、本问题密切相关的类-对象放进目录系统：有些类在其他问题中可能很重要，但与当前要解决的问题无关，同样也应该把它们删掉。以ATM系统为例，这个系统并不处理分摊软件开发成本的问题，而且ATM和柜员终端放置的地点与本软件的关系也不大。因此，应该去掉候选类“成本”、“市”、“街道”、“营业厅”和“储蓄所”。(3)笼统在需求述中常常使用一些笼统的、泛指的名词，虽然在初步分析时把它们作为候选的类一对象列出来了，但是，要么系统无须记忆有关它们的信息，要么在需求述中有更明确更具体的名词对应它们所暗示的事务，因此，通常把这些笼统的或模糊的类去掉。以ATM系统为例，“银行”实际指总行或分行，“访问”在这里实际指事务

19、。“信息”的具体容在需求述中随后就指明了。此外还有一些笼统含糊的名词。总之，在本例中应该去掉“银行”、“网络”、“系统”、“软件”、“信息”、“访问”等候选类。(4)属性在需求述中有些名词实际上描述的是其他对象的属性，应该把这些名词从候选类一对象中去掉。当然，如果某个性质具有很强的独立性，则应把它作为类而不是作为属性。在ATM系统的例子中，“现金”、“支票”、“取款额”、“账单”、“余额”、“分行代码”、“卡号”、“密码”、“类型”等，实际上都应该作为属性对待。(5)操作在需求述中有时可能使用一些既可作为名词，又可作为动词的词，应该慎重考虑它们在本问题中的含义，以便正确地决定把它们作为类还是作

20、为类中定义的操作。例如，谈到时通常把“拨号”当作动词，当构造模型时确实应该把它作为一个操作，而不是一个类。但是，在开发的自动记账系统时，“拨号”需要有自己的属性(例如日期、时间、受话地点等)，因此应该把它作为一个类。总之，本身具有属性需独立存在的操作，应该作为类-对象(6)实现在分析阶段不应该过早地考虑怎样实现目标系统。因此应该去掉仅和实现有关的候选的类-对象。在设计和实现阶段，这些类一对象可能是重要的，但在分析阶段过早地考虑它反而会分散我们的注意力。在ATM系统的例子中，“事务日志”无非是对一系列事务的记录，它的确切表示方式是面向对象设计的议题“通信链路”在逻辑上是一种联系，在系统实现时它是

21、关联链的物理实现。总之，应该暂时去掉“事务日志”和“通信链路”这两个类，在设计或实现时再考虑它们。综上所述，在ATM系统的例子中，经过初步筛选，剩下下列类一对象：ATM、中央总行、分行、柜员、储户、账户、事务、现金兑换卡。确定关联多数人习惯于在初步分析确定了问题域中的类一对象之后，接下来就分析确定类-对象之间存在关联关系。当然，这样的工作顺序并不是绝对必要的。由于在整个开发过程中面向对象概念和表示符号的一致性，分析员在选取自己习惯的工作方式时拥有相当大的灵活性。如前所述，两个或多个对象之间的相互依赖、相互作用的关系就是关联。分析确定关联，能促使分析员考虑问题域的边缘情况，有助于发现那些尚未被发

22、现的类一对象。在分析确定关联的过程中，不必花过多的精力去区分关联和聚集。事实上，聚集不过是一种特殊的关联，是关联的一个特例。首先，初步确定关联在需求述中使用的描述性动词或动词词组，通常表示关联关系。因此，在初步确定关联时，大多数关联可以通过直接提取需求述中的动词词组而得出。通过分析需求述，还能发现一些在述中隐含的关联。最后，分析员还应该与用户与领域专家讨论问题域实体间的相互依赖l相互作用关系，根据领域知识再进一步补充一些关联。以ATM系统为例，经过分析初步确定出下列关联：(1)直接提取动词短语得出的关联ATM、中央计算机、分行计算机与柜员终端组成网络。总行拥有多台ATM。ATM设在主要街道上。

23、分行提供分行计算机和柜员终端。柜员终端设在分行营业厅与储蓄所。分行分摊软件开发成本。储户拥有账户。分行计算机处理针对账户的事务。分行计算机维护账户。柜员终端与分行计算机通信。柜员输入针对账户的事务。ATM与中央计算机交换关于事务的信息。中央计算机确定事务与分行的对应关系。ATM读现金兑换卡。ATM与用户交互。ATM吐出现金。ATM打印账单。系统处理并发的访问。(2)需求述中隐含的关联总行由各个分行组成。分行保管账户。总行拥有中央计算机。系统维护事务日志。系统提供必要的安全性。储户拥有现金兑换卡。(3)根据问题域知识得出的关联现金兑换卡访问账户。分行雇用柜员。第二步，筛选经初步分析得出的关联只能

24、是作为候选的关联，还需经过进一步筛选，以去掉不正确的或不必要的关联。筛选时主要根据下述标准删除候选的关联：(1)已删去的类之间的关联如果在分析确定类一对象的过程中已经删掉了某个候选类，则与这个类有关的关联也应该删击，或用其他类重新表达这个关联。以ATM系统为例，由于已经删去了“系统”、“网络”、“市”、“街道”、“成本”、“软件”、“事务日志”、“现金”、“营业厅”、“储蓄所”、“账单”等候选类，因此，与这些类有关的下列八个关联也应该删去；ATM、中央计算机、分行计算机与柜员终端组成网络。ATM设在主要街道上。分行分摊软件开发成本。系统提供必要的安全性。系统维护事务日志。ATM吐出现金。ATM

25、打印账单。柜员终端设在分行营业厅与储蓄所。(2)与问题无关的或应在实现阶段考虑的关联应该把处在本问题域之外的关联或与实现密切相关的关联删去。例如，在ATM系统的例子中，“系统处理并发的访问”并没有标明对象之间的新关联，它只不过提醒我们在实现阶段需要使用实现并发访回的算法，以处理并发事务。(3)瞬时事件关联应该描述问题域的静态结构，而不应该是一个瞬时事件。以ATM系统为例，“ATM读现金兑换卡”描述了ATM与用户交互周期中的一个动作，它并不是ATM与现金兑换卡之间的固有关系，因此应该删去。类似地，还应该删去“ATM与用户交互”这个候选的关联。如果用动作表述的需求隐含了问题域的某种基本结构，则应该

26、用适当的动词词组重新表示这个关联。例如，在ATM系统的需求述中，“中央计算机确定事务与分行的对应关系”隐含了结构上“中央计算机与分行通信”的关系。(4)三元关联三个或三个以上对象之间的关联大多可以分解为二元关联或用词组描述成限定的关联。在ATM系统的例子中，“柜员输入针对账户的事务”可以分解成“柜员输入事务”和“事务修改账户”这样两个二元关联。而“分行计算机处理针对账户的事务”也可以做类似的分解。“ATM与中央计算机交换关于事务的信息”这个候选的关联，实际上隐含了“ATM与中央计算机通信”和“在ATM上输入事务”这两个二元关联。如果三元关联中涉与的某个实体仅用于描述另两个实体的关系而且这个实体

27、本身不包含属性，则它是二元关联上的链属性。例如，“公司付给员工工资”可以改造成带有链属性“工资”的二元关联“公司雇用员工”。(5)派生关联应该去掉那些可以用其他关联定义的冗余关联。例如，在ATM系统的例子中，。总行拥有多台ATM”实质上是“总行拥有中央计算机”和“ATM与中央计算机通信”这两个关联组合的结果。而“分行计算机维护账户”的实际含义是，“分行保管账户”和“事务修改账户”。第三，进一步完善应该进一步完善经筛选后余下的关联。通常从下述几个方面进行改进：(1)正名好的名字是帮助读者理解的关键因素之一。因此，应该仔细选择含义更明确的名字作为关联名。例如，“分行提供分行计算机和柜员终端”不如改

28、为“分行拥有分行计算机”和“分行拥有柜员终端”。(2)分解为了能够适用于不同的关联，必要时应该分解以前确定的类一对象。倒如，在ATM系统中，应该把“事务”分解成“远程事务”和“柜员事务”。(3)补充发现了遗漏的关联就应该与时补上。例如，在ATM系统中把“事务”分解戚上述两类之后，需要朴充“柜员输入柜员事务”、“柜员事务输进柜员终端”、“在ATM上输入远程事务”和“远程事务由现金兑换卡授权”等关联。(4)标明阶数应该初步判定各个关联的类型，并粗略地确定关联的阶数。但是，无须为此花费过多精力，因为分析过程中随着认识的逐渐深入，阶数也会经常改动。图2-1是经过上述分析过程之后得出的ATM系统原始对象

29、图。图2-1 ATM系统原始对象图划分主题在开发大型、复杂系统的过程中，为了降低复杂程度，人们习惯于把系统再进一步划分成几个不同的主题，也就是在概念上把系统包含的容分解成若干个畴。应该按问题领域而不是用功能分解方法来确定主题。此外，应该按照使不同主题的对象相互间依赖和交互最少的原则来确定主题。1 12 22 21 13 33 3以ATM系统为例，可划分为“总行”、“分行”、“ATM”等三个主题，分别可标识为如下图22所示。图22 把ATM系统划分为三个主题确定属性属性是对象的性质，藉助于属性我们能对类-对象和结构有更深入、更具体的认识。注意，在分析阶段不要用属性来表示对象间的关系，使用关联能够

30、表示两个对象间的任何关系，而且把关系表示得更清晰、更醒目。一般说来，确定属性的过程包括分析和选择两个步骤。首先，分析通常，在需求述中用名词词组表示屑性，例如，“汽车的颜色”或“光标的位置”。往往用形容词表示可枚举的具体属性，倒如，“红色的”、“打开的”。但是，不可能在需求述中找到所有属性，分析员还必须藉助于领域知识和常识才能分析得出需要的属性。幸运的是，属性对问题域的基本结构影响很小。随着时间的推移，问题域中的类始终保持稳定，属性却可能改变了，相应地，类中方法的复杂程度也将改变。属性的确定既与问题域有关，也和目标系统的任务有关。应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题

31、围的属性。在分析过程中应该首先找出最重要的属性，阻后再逐渐把其余属性增添进去。在分析阶段不要考虑那些纯粹用于实现的属性。第二步，选择认真考察经初步分析而确定下来的那些属性，从中删掉不正确的或不必要的属性。通常有以下几种常见情况：(1)误把对象当作属性如果某个实体的独立存在比它的值更重要，则应把它作为一个对象而不是对象的属性。在具体应用领域中具有自身性质的实体，必然是对象。同一个实体在不同应用领域中，到底应该作为对象还是属性，需要具体分析才能确定。例如，在邮政目录中，“城市”是一个属性，而在人口普查中却应该把“城市”当作对象。(2)把链属性误作为属性如果某个性质依赖于某个关联链的存在，则该性质是

32、链属性，在分析阶段不应该把它作为对象的属性带别是在多对多关联中，链属性很明显，即使是在以后的开发阶段中，也不能把它归并成相互关联的两个对象中任一个的属性。(3)把限定误当成属性限定是一种特殊的链属性。正确使用限定词往往可以减少关联的阶数。如果把某个属性值固定下来以后能减少关联的阶数，则应该考虑把这个属性重新表述成一个限定词。在ATM系统的例子中，“分行代码”、“账号”、“雇员号”、“站号”等都是限定词。(4)误把部状态当成了属性如果某个性质是对象的非公开的部状态，则应该从对象模型中删掉这个属性。(5)过于细化在分析阶段应该忽略那些对大多数操作都没有影响的属性。(6)存在不一致的属性类应该是简单

33、而且一致的。如果得出一些看起来与其他属性毫不相关的属性，则应该考虑把该类分解成两个不同的类。经过筛选之后，得到ATM系统中各个类的属性，如图23所示。图中还标出了一些限定词：“卡号”实际上是一个限定词。在研究卡号含义的过程中，发现以前在分析确定关联的过程中遗漏了“分行发放现金兑换卡”这个关联，现在把这个关联补上，卡号是这个关联限定词。“分行代码”是关联“分行组成总行”上的限定词。“账号”是关联“分行保管账户”上的限定词。“雇员号”是“分行雇用柜员”上限定词。“站号”是“分行拥有柜员终端”、“柜员终端与分行计算机通信”与“中央计算机与ATM通信”等三个关联上的限定词。图23 ATM对象模型中的属

34、性应该说明的是，我们讨论的ATM系统是一个经过简化后的例子而不是一个完整的实际应用系统。因此，图23中示出的属性远较实际应用系统中的属性少。在实际过程中，通常要反复修改，如ATM系统对象模型，修改后可示意为如下，图24所示。图2-4 修改后的ATM对象模型3、建立动态模型建立动态模型的第一步，是编写典型交互行为的脚本。接下来是从脚本中提取事件，确定触发每个事件的动作对象以与接受事件的目标对象。第三步，排列事件发生的次序，确定每个对象可能有的状态与状态间的转换关系，并用状态图描绘它们。最后，比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。建立动态模型时，通常先根据事件，画出事件跟

35、踪图，再画出状态图。编写脚本脚本是指系统在某一执行期间出现的一系列事件。脚本描述用户（或其他外部设备）与目标系统之间的一个或多个典型的交互过程，以便对目标系统的行为有更具体的认识。编写脚本的目的，是保证不遗漏重要的交互步骤，有助于确保整个交互过程的正确性和清晰性。下面分别给出参考的ATM系统的正常、异常情况脚本。ATM系统的正常情况脚本l ATM请储户插卡；储户插入一现金兑换卡。l ATM接受该卡并读它上面的分行代码和卡号。l ATM要求储户输入密码；储户输入自己的密码“1234”等数字。l ATM请求总行验证卡号和密码；总行要求“39”号分行核对储户密码，然后通知ATM说这卡有效。l ATM

36、要求储户选择事务类型（取款、转账、查询等）；储户选择“取款”。l ATM要求储户输入取款额；储户输入“880”。l ATM确认取款额在预先规定的限额，然后要求总行处理这个事务；总行把请求转给分行，该分行成功处理完这项事务并返回该账户的新余额。l ATM吐出现金并请储户拿走这些现金；储户拿走现金。l ATM问储户是否继续这项事务；储户回答“不”。l ATM打印账单，退出现金兑换卡，请储户拿走它们；储户取走账单和卡。l ATM请储户插卡。ATM系统的异常情况脚本l ATM请储户插卡；储户插入一现金兑换卡。l ATM接受该卡并顺序读它上面的数字。l ATM要求密码；储户误输入“8888”等数字。l

37、ATM请求总行验证卡号和密码；总行在向有关分行咨询后拒绝这卡。l ATM显示“密码错”，并请储户输入密码；储户输入“1234”等数字；ATM请求总行验证后知道输入密码正确。l ATM要求储户选择事务类型；储户选择“取款”。l ATM询问取款额；储户改变主意不想取款了，按“取消”。l ATM退出现金兑换卡，请储户拿走它们；储户取走卡。l ATM请储户插卡。设想用户界面大多数交互行为都可以分为应用逻辑和用户界面两部分。通常，系统分析员首先集中精力考虑系统的信息流和控制流，而不是首先考虑用户界面。一般来说，不经过实际使用是很难评价一个用户界面的优劣的，因此，软件开发人员往往常需快速地建立起用户界面的

38、原型，供用户试用与评价。故请同学们参考现有ATM取款机原型，来设计用户界面。画事件跟踪图首先，确定事件应该仔细分析每个脚本，以便从中提取所有外部事件。事件包括系统与用户（或外部设备）交互的所有信号、输入、输出、中断、动作等等。从脚本中容易找出正常事件，但是，应该小心仔细，不要遗漏异常事件和出错条件。提示：传递信息的对象的动作也事件。如，储户插入现金兑换卡、储户输入密码、ATM吐出现金等都是事件。经过分析，应该区分出每个（类）事件的发送对象和接受对象。其次，画出事件跟踪图确定事件与其发送对象、接受对象后，就可以用事件跟踪图把事件序列以与事件与对象的关系，形象、清晰地表示出来。事件跟踪图实质上是扩

39、充的脚本。下面给出参考的ATM系统正常情况下的事件跟踪图。如图3-1示。分行图31 ATM系统正常情况脚本的事件跟踪图。画状态图通常，用一状态图描绘一类对象的行为，它确定了由事件序列引出的状态序列。但是，也不是任何一个类一对象都需要有一状态图描绘它的行为。很多对象仅响应与过去历史无关的那些输入事件或者把历史作为不影响控制流的参数。对于这类对象来说，状态图是不必要的。系统分析员应该集中精力仅考虑具有重要交互行为的那些类。从一事件跟踪图出发画状态图时，应该集中精力仅考虑影响一类对象的事件，也就是说，仅考虑事件跟踪图中指向某条竖线的那些箭头线。把这些事件作为状态图中的有向边(即箭头线)，边上标以事件

40、名。两个事件之间的间隔就是一个状态。一般说来，如果同一个对象对一样事件的响应不同，则这个对象处在不同状态。应该尽量给每个状态取个有意义的名字。通常，从事件跟踪图中当前考虑的竖线射出的箭头线，是这条竖线代表的对象达到某个状态时所做的行为(往往是引起另一类对象状态转换的事件)。根据一事件跟踪图画出状态图之后，再把其他脚本的事件跟踪图合并到已画出的状态图中。为此需在事件跟踪图中找出以前考虑过的脚本的分支点(例如“验证账户”就是一个分支点，因为验证的结果可能是“账户有效”，也可能是“无效账户”)，然后把其他脚本中的事件序列并入已有的状态图中，作为一条可选的路径。考虑完正常事件之后再考虑边界情况和特殊情

41、况，其中包括在不适当时候发生的事件(例如，系统正在处理某个事务时，用户要求取消该事务)。有时用户(或外部设备)不能做出快速响应，然而某些资源又必须与时收回，于是在一定间隔后就产生了“超时”事件。对用户出错情况往往需要花费很多精力处理，并且会使原来清晰的程序结构变得复杂，但是，出错处理是不能省略的。当状态图覆盖了所有脚本，包含了影响某类对象状态的全部事件时，该类的状态图就构造出来了。利用这状态图可能会发现一些遗漏的情况。测试完整性和出错处理能力的最好方法是设想各种可能情况，多问几个“如果则”的问题。图32 ATM类状态图以ATM系统为例。“ATM”、“柜员终端”、“总行”和“分行”都是主动对象，

42、它们相互发送事件；而“现金兑换卡”、“事务”和“账户”是被动对象，并不发送事件。“储户”和“桓员”虽然也是动作对象，但是，它们都是系统外部的因素，无须在系统实现它们。因此，只需要考虑“ATM”、“总行”、“柜员终端”和“分行”的状态图。图32，图33，图34，分别是“ATM”、“总行”和“分行”的状态图。由于“柜员终端”的状态图和“ATM”的状态图类似，为节省篇幅把它省略了。这些状态图都是简化的，尤其对异常情况和出错情况的考虑是相当粗略的(例如，图3-2并没有表示在网络通信链路不通时的系统行为，实际上，在这种情况下，ATM停止处理储户事务)。图33 总行类状态图图34 分行类状态图审查动态模型

43、各个类的状态图通过共享事件合并起来，构成了系统的动态模型。在完成了每个具有重交互行为的类的状态图之后，应该检查系统级的完整性和一致性。一般说来，每个事件都应该既有发送对象又有接受对象，当然，有时发送者和接受者是同一个对象。对手没有前驱或没有后继的状态应该着重审查，如果这个状态既不是交互序列的起点也不是终点，则发现了一个错误。应该审查每个事件，跟踪它对系统中各个对象所产生的效果，以保证它们与每个脚本都匹配。以ATM系统为例。在总行类的状态图中，事件“分行代码话”是由总行发出的，但是在ATM类的状态图中并没有一个状态接受这个事件。因此，在ATM类的状态图中应该再补充一个状态“do：显示分行代码错信

44、息”，它接受由前驱状态“do：验证账户”发出的事件“分行代码错”，它的后续状态是“退卡”。4、建立功能模型功能模型表明了系统中数据之间的依赖关系，以|与有关的数据处理功能，它由一组数据流图组成。其中的处理功能可以用IPO图(或表)、伪码等多种方式进一步描述。通常在建立了对象模型和动态模型之后再建立功能模型。现结合ATM系统的例子，再学习有关数据流图的概念和画法。画出基本系统模型图基本系统模型由若干个数据源点终点。与一个处理框组成，这个处理框代表了系统加工、变换数据的整体功能。基本系统模型指明了目标系统的边界。由数据源点输入的数据和输出到数据终点的数据，是系统与外部世界之间的交互事件的参数。图4

45、-1是ATM系统的基本系统模型。尽管在储蓄所储户的事务是由柜员通过柜员终端提交给系统的，但是信息的来源和最终接受者都是储户，因此，本系统的数据源点终点为储户。另一个数据源点是现金兑换卡，因为系统从它上面读取分行代码、卡号等信息。图41 ATM系统基本系统模型画出功能级数据流图把基本系统模型中单一的处理框分解成若干个处理框。以描述系统加工，变换数据的基本功能，就得到功能级数据流图。ATM系统的功能级数据流图如图4-2所示。图42 ATM系统的功能级数据流图描述处理框功能把数据流图分解细化到一定程度之后，就应该描述图中各个处理框的功能。应该注意的是，要着重描述每个处理框代表的功能，而不是实现功能的具体算法。描述可以是说明性的，也可以是过程性的。说明书性描述规定了输入值与输出值之间的关系，以与输出值应遵循的规律。过程性描述则通过算法说明“做什么”。一般来说，说明性描述优于过程性描述，因为这类描述常不会隐含具体实现方面的考虑。