银行ATM自动取款机系统软件工程课程实验指导书毕业论文.docx
《银行ATM自动取款机系统软件工程课程实验指导书毕业论文.docx》由会员分享，可在线阅读，更多相关《银行ATM自动取款机系统软件工程课程实验指导书毕业论文.docx（28页珍藏版）》请在冰豆网上搜索。
银行ATM自动取款机系统软件工程课程实验指导书毕业论文
《软件工程》课程实验指导书
（SoftwareEngineering）
序言
为帮助同学们牢固树立软件工程的思想，必须理论联系实际。
本实验是同学们获得用软件工程的思想、方法和技术开发简单软件项目的初步训练，主要目的是使同学们基本掌握用软件工程的思想开发软件的方法。
通过本次实验，要求同学们掌握软件工程的基本思想，了解开发一个软件系统的主要阶段，每个阶段所采用的方法与应该生成的主要文档。
为学生今后的软件开发实践无论从观念上还是实现上建立良好的基础。
本实验以《软件工程》课程中面向对象方法的容为基础，利用面向对象技术中的OMT方法，针对一个具体的应用实例，如银行网络系统ATM，对其进行分析和设计。
OMT（即对象模型技术）是一种软件工程方法学，它支持整个软件生命周期，覆盖了用户需求（即问题构成）、分析、设计和实现等阶段。
OMT方法使用建模思想，讨论如何建立一个实际的系统应用模型，从三个不同而又相关的角度建立三类模型：
对象模型、动态模型和功能模型。
每一个模型都提供了直观、形象图形表示。
此外，本实验的完成将涉与到《软件工程》的其它方面的许多知识，例如何针对用户需求进行有效的软件需求分析，如何用软件工程的思想为用户建立一个有效的系统应用模型，为下一步的软件设计打下良好的基础。
本实验对同学们的综合能力要求比较高，包括分析问题和处理问题的能力、实际动手能力如绘制图形的能力以与编写文档的能力等。
具体操作时，又分为三个阶段：
ATM系统的分析、ATM系统的设计与用OMT方法分析与设计ATM等来进行。
一、实验安排
第一阶段：
ATM系统的分析
学时：
2
（一）实验目的
通过分析ATM系统需求，确定各对象与其关联，分析并做出ATM系统的原始对象图。
（二）实验容
1、阅读ATM系统需求报告（也可自己调研完成），分析出整个系统的框架。
2、对ATM系统进行进一步分析，确定系统中涉与的各个对象，理顺相互关联。
按照冗余、无关、笼统、属性、操作、实现的原则筛选出正确的对象，并确定相对应的属性描述；再经过正名、分解、补充等方式来进一步完善后，适当运用数据库思想，分析并建立类似E/R图的ATM系统的对象图。
第二阶段：
ATM系统的设计
学时：
2
（一）实验目的
在分析ATM系统的基础上，对较佳的系统方案进行结构与详细设计。
（二）实验容
1、根据系统模型完成概要设计。
在概要设计阶段中，首先进行系统设计，从数据流图出发设想完成系统功能的多种合理的物理方案，并仔细比较这些方案选定一个最佳方案，然后进行软件结构设计，确定软件由哪些模块组成以与模块间的动态调用关系。
其中层次图和结构图是描绘软件结构的有用工具。
2、用Jackson或Warnier方法完成系统的详细设计。
第三阶段：
用OMT方法分析与设计ATM
学时：
2
（一）实验目的
用面向对象的方法和技术分析具体的ATM系统。
（1）掌握面向对象的概念和思想；
（2）针对一个用户需求，掌握分析方法，提高逻辑思维能力；（3）掌握建立三种模型的具体方法和步骤。
（二）实验容
要求学生采用OMT方法分析并设计ATM系统。
1、根据已知ATM系统需求与分析，重点建立相应的对象模型。
并用直观、形象的图形表示。
2、根据已知ATM系统需求与分析，建立动态模型。
3、根据已知ATM系统需求与分析，建立功能模型。
4、分析、对比三种模型的特点，充分理解软件设计中方法与模型的综合运用。
二、考核方式与评定标准
上机实验要求对软件工程的整个流程与编制思想进行综合认识，并能在实际的软件系统的编写中体会、分析，并加深理解。
须提交的文档有：
软件设计的全部文档（主要含：
调研或需求报告、软件系统分析、软件系统各个方案的概要设计与其比较、较佳设计方案分析与数据流程、软件系统结构设计、系统功能分析与设计、系统功能调整与测试分析等）、软件系统的程序代码。
实验成绩满分为100分，其中，上机占50%（含平时上机操作与考勤），文档占50%。
三、参考资料与系统初步分析
1、ATM系统的需求概述
图1-1ATM（自动取款机）系统
ATM系统的需求要点
拟开发一个自动取款系统（参考图1-1），它是一个由自动取款机、中央计算机、分行计算机与柜员终端组成的网络系统。
ATM和中央计算机由总行投资购买。
总行拥有多台ATM，分别设在全市各主要街道上。
分行负责提供分行计算机和柜员终端。
柜员终端设在分行营业厅与分行下属的各个储蓄所。
该系统的软件开发成本由各个分行分摊。
银行柜员使用柜员终端处理储户提交的储蓄事务。
储户可以用现金或支票向自己拥有的某个账户存款或开新账户。
储户也可以从自己的账户中取款。
通常，一个储户可能拥有多个账户。
柜员负责把储户提交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。
柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户。
拥有银行账户的储户有权申请领取现金兑换卡。
使用现金兑换卡可以通过ATM访问自己的账户。
目前仅限于用现金兑换卡在ATM上提取现金（即取款），或查询有关自己账户的信息（如余额）。
将来还可能要求用ATM来办理转账、存款。
所谓现金兑换卡就是一个特制的磁卡，上面有分行代码和卡号。
分行代码唯一标识总行下属的一个分行，卡号确定了这卡可以访问哪些账户。
通常，一卡可以访问储户的若干个账户，但是不一定能访问这个储户的全部账户。
每卡仅属于一个储户所有，但是，同一卡可能有多个副本，因此，必须考虑同时在若干台ATM上使用同样的现金兑换卡的可能性。
也就是说，系统应该能够处理并发的访问。
当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。
首先，ATM要求用户输入密码，接下来ATM把从这卡上读到的信息以与用户输入的密码传给中央计算机，请求中央计算机核对这些信息并处理这次事务。
中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分行计算机验证用户的密码。
如果用户输入的密码是正确的，ATM就要求用户选择事务类型（取款、查询等）。
当用户选择取款时，ATM请求用户输入取款额。
最后，ATM从现金口吐出现金，并且打印账单交给用户。
需求述书写要点
通常，需求述的容包括：
问题围，功能需求，应用环境与假设条件等。
它应该阐明“做什么”而不是“怎么样做”；它描述的是用户的需求而不是提出解决问题的方法，并应该指明哪些是系统必要的性质，哪些是任选的性质；它应该避免对设计策略加过多的约束，也不要描述系统部结构，以免影响系统实现的灵活性。
但是，对系统性能与系统外界环境交互协议的描述，对采用的软件工程标准、模块构造准则、将来可能做的扩充以与可维护性要求等方面的描述，则是合适的需求。
书写需求述是时，要尽力做到语法准确，真正反映用户的需求，而且要应该慎重选用名词、动词、形容词和同义词；更不能将实际需求和设计决策混为一谈。
2、建立对象模型
面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。
通常，它从分析述用户需求的文件开始，再通过深入理解，抽象出目标系统的本质属性，并用模型对问题的进行精确而又简洁的表示，再以此分析模型为基础进行后继的设计。
在概念上，我们可以认为面向对象分析大体上按照下列顺序进行：
寻找类—对象，识别结构，识别主题，定义属性，建立动态模型、建立功能模型，定义服务。
但是，分析不可能是严格按照此顺序进行的，通常要多次反复构造才能完全建立。
面向对象分析首要的工作，是建立域的对象模型。
这个模型描述了现实世界中的“类一对象”以与它们之间的关系，表示了目标系统的静态数据结构。
静态数据结构对应用细节依赖较少，比较容易确定}当用户的需求变化时。
静态数据结构相对来说比较稳定。
因此，用面向对象方法开发绝大多数软件时，都首先建立对象模型，然后再建立另外两个子模型。
需求述、应用领域的专业知识以与关于客观世界的常识，是建立对象模型时的主要信息来源。
如前所述，对象模型通常有五个层次。
典型的工作步骤是，首先确定对象类和关联（因为它们影响系统整体结构和解决问题的方法），对于大型复杂问题还要进一步划分出若干个主题；然后给类和关联增添属性，以进一步描述它们；接下来利用适当的继承关系进一步合并和组织类。
而对类中操作的最后确定，则需等到建立了动态模型和功能模型之后，因为这两个子模型更准确地描述了对类中提供的服务的需求。
应该再一次强调指出的是，人认识客观世界的过程是一个渐进过程，是在继承前人知识的基础上，经反复迭代而不断深化的。
因此，面向对象分析不可能严格按照顺序线性进行。
初始的分析模型通常都是不准确不完整甚至包含错误的，必须在随后的反复分析中加以扩充和更正。
此外，在面向对象分析的每一步，都应该仔细分析研究以前针对一样的或类似的问题域进行面向对象分析所得到的结果，并尽可能在本项目中重用这些结果。
在描述面向对象分析的具体过程时，将按上述规则进行处理。
确定类一对象
类一对象是在问题域中客观存在的，系统分析员的主要任务，就是通过分析找出这些类一对象。
首先．找出所有候选的类一对象；然后，从候选的类一对象中筛选掉不正确的或不必要的。
首先，找出候选的类一对象
对象是对问题域中有意义的事物的抽象，它们既可能是物理实休-也可髓是抽象概念。
具体地说，爽多数客观事物可分为下述五类：
（1）可感知的物理实体，例如，飞机、汽车、书、房屋等。
（2）人或组织的角色，例如，医生、教师、雇主、雇员、计算机系、财务处等等。
（3）应该记忆的事件，例如，飞行、演出、访问、交通事故等等。
（4）两个或多个对象的相互作用，通常具有交易或接触的性质，例如，购买、纳税、结婚等等。
（5）需要说明的概念，例如，政策、保险政策、法等等。
在分析所面临的问题时，可以参照上列五类常见事物，找出在当前问题域中的候选类一对象。
另一种更简单的分析方法，是所谓的非正式分析。
这种分析方法以用自然语言书写的需求述为依据，把述中的名词作为类一对象的候选者，用形容词作为确定属性的线索，把动词作为服务（操作）的候选者。
当然，用这种简单方法确定的候选者是非常不准确的，其中往往包含大量不正确的或不必要的事物。
还必须经过更进一步的严格筛选。
通常，非正式分析是更详细、更精确的正式的面向对象分析的一个很好的开端。
下面以ATM系统为例，说明非正式分析过程。
认真阅读给出的需求述，从述中找出下列名词，可以把它们作为类一对象的初步的候选者：
银行，自动取款机（ATM）．系统，中央计算机，分行计算机，柜员终端，网络，总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金．支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问。
通常，在需求述中不会一个不漏地写出问题域中所有有关的类一对象。
因此，分析员应该根据领域知识或常识进一步把隐台的类一对象提取出来。
例如，在ATM系统的需求述中虽然没写“通信链路”和“事务日志”，但是，根据领域知识和常识可以知道，在ATM系统中应该包含这两个实体。
第二步，筛选出正确的类一对象
显然，仅通过一个简单、机械的过程不可能正确地完成分析工作。
非正式分析仅仅帮助我们找到一些候选的类一卜对象．接下来应该严格考察每个候选对象，从中去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象。
筛选时主要依据下列标准．删除不正确或不必要的类一对象：
（1）冗余
如果两个类表达了同样信息，则应该保留在此问题域中最富于描述力的名称。
以ATM系统为例，上面用非正式分析法得出了34个候选的类，其中储户与用户，现金兑换卡与磁卡与副本分别描述了一样的二类信息，因此，应该去掉“用户”、“磁卡”、“副本”等冗余的类，仅保留“储户”和“现金兑换卡”这两个类。
（2）无关
现实世界中存在许多对象，不能把它们都纳入到系统中去．仅需要把与本问题密切相关的类--对象放进目录系统：
有些类在其他问题中可能很重要，但与当前要解决的问题无关，同样也应该把它们删掉。
以ATM系统为例，这个系统并不处理分摊软件开发成本的问题，而且ATM和柜员终端放置的地点与本软件的关系也不大。
因此，应该去掉候选类“成本”、“市”、“街道”、“营业厅”和“储蓄所”。
（3）笼统
在需求述中常常使用一些笼统的、泛指的名词，虽然在初步分析时把它们作为候选的类一对象列出来了，但是，要么系统无须记忆有关它们的信息，要么在需求述中有更明确更具体的名词对应它们所暗示的事务，因此，通常把这些笼统的或模糊的类去掉。
以ATM系统为例，“银行”实际指总行或分行，“访问”在这里实际指事务。
“信息”的具体容在需求述中随后就指明了。
此外还有一些笼统含糊的名词。
总之，在本例中应该去掉“银行”、“网络”、“系统”、“软件”、“信息”、“访问”等候选类。
（4）属性
在需求述中有些名词实际上描述的是其他对象的属性，应该把这些名词从候选类一对象中去掉。
当然，如果某个性质具有很强的独立性，则应把它作为类而不是作为属性。
在ATM系统的例子中，“现金”、“支票”、“取款额”、“账单”、“余额”、“分行代码”、“卡号”、“密码”、“类型”等，实际上都应该作为属性对待。
（5）操作
在需求述中有时可能使用一些既可作为名词，又可作为动词的词，应该慎重考虑它们在本问题中的含义，以便正确地决定把它们作为类还是作为类中定义的操作。
例如，谈到时通常把“拨号”当作动词，当构造模型时确实应该把它作为一个操作，而不是一个类。
但是，在开发的自动记账系统时，“拨号”需要有自己的属性（例如日期、时间、受话地点等），因此应该把它作为一个类。
总之，本身具有属性需独立存在的操作，应该作为类---对象
（6）实现
在分析阶段不应该过早地考虑怎样实现目标系统。
因此应该去掉仅和实现有关的候选的类---对象。
在设计和实现阶段，这些类一对象可能是重要的，但在分析阶段过早地考虑它反而会分散我们的注意力。
在ATM系统的例子中，“事务日志”无非是对一系列事务的记录，它的确切表示方式是面向对象设计的议题}“通信链路”在逻辑上是一种联系，在系统实现时它是关联链的物理实现。
总之，应该暂时去掉“事务日志”和“通信链路”这两个类，在设计或实现时再考虑它们。
综上所述，在ATM系统的例子中，经过初步筛选，剩下下列类一对象：
ATM、中央总行、分行、柜员、储户、账户、事务、现金兑换卡。
确定关联
多数人习惯于在初步分析确定了问题域中的类一对象之后，接下来就分析确定类--对象之间存在关联关系。
当然，这样的工作顺序并不是绝对必要的。
由于在整个开发过程中面向对象概念和表示符号的一致性，分析员在选取自己习惯的工作方式时拥有相当大的灵活性。
如前所述，两个或多个对象之间的相互依赖、相互作用的关系就是关联。
分析确定关联，能促使分析员考虑问题域的边缘情况，有助于发现那些尚未被发现的类一对象。
在分析确定关联的过程中，不必花过多的精力去区分关联和聚集。
事实上，聚集不过是一种特殊的关联，是关联的一个特例。
首先，初步确定关联
在需求述中使用的描述性动词或动词词组，通常表示关联关系。
因此，在初步确定关联时，大多数关联可以通过直接提取需求述中的动词词组而得出。
通过分析需求述，还能发现一些在述中隐含的关联。
最后，分析员还应该与用户与领域专家讨论问题域实体间的相互依赖l相互作用关系，根据领域知识再进一步补充一些关联。
以ATM系统为例，经过分析初步确定出下列关联：
（1）直接提取动词短语得出的关联
·ATM、中央计算机、分行计算机与柜员终端组成网络。
·总行拥有多台ATM。
·ATM设在主要街道上。
·分行提供分行计算机和柜员终端。
·柜员终端设在分行营业厅与储蓄所。
·分行分摊软件开发成本。
·储户拥有账户。
·分行计算机处理针对账户的事务。
·分行计算机维护账户。
·柜员终端与分行计算机通信。
·柜员输入针对账户的事务。
·ATM与中央计算机交换关于事务的信息。
·中央计算机确定事务与分行的对应关系。
·ATM读现金兑换卡。
·ATM与用户交互。
·ATM吐出现金。
·ATM打印账单。
·系统处理并发的访问。
（2）需求述中隐含的关联
·总行由各个分行组成。
·分行保管账户。
·总行拥有中央计算机。
·系统维护事务日志。
·系统提供必要的安全性。
·储户拥有现金兑换卡。
（3）根据问题域知识得出的关联
·现金兑换卡访问账户。
·分行雇用柜员。
第二步，筛选
经初步分析得出的关联只能是作为候选的关联，还需经过进一步筛选，以去掉不正确的或不必要的关联。
筛选时主要根据下述标准删除候选的关联：
（1）已删去的类之间的关联
如果在分析确定类一对象的过程中已经删掉了某个候选类，则与这个类有关的关联也应该删击，或用其他类重新表达这个关联。
以ATM系统为例，由于已经删去了“系统”、“网络”、“市”、“街道”、“成本”、“软件”、“事务日志”、“现金”、“营业厅”、“储蓄所”、“账单”等候选类，因此，与这些类有关的下列八个关联也应该删去；
①ATM、中央计算机、分行计算机与柜员终端组成网络。
②ATM设在主要街道上。
③分行分摊软件开发成本。
④系统提供必要的安全性。
⑤系统维护事务日志。
⑥ATM吐出现金。
⑦ATM打印账单。
⑧柜员终端设在分行营业厅与储蓄所。
（2）与问题无关的或应在实现阶段考虑的关联
应该把处在本问题域之外的关联或与实现密切相关的关联删去。
例如，在ATM系统的例子中，“系统处理并发的访问”并没有标明对象之间的新关联，它只不过提醒我们在实现阶段需要使用实现并发访回的算法，以处理并发事务。
（3）瞬时事件
关联应该描述问题域的静态结构，而不应该是一个瞬时事件。
以ATM系统为例，“ATM读现金兑换卡”描述了ATM与用户交互周期中的一个动作，它并不是ATM与现金兑换卡之间的固有关系，因此应该删去。
类似地，还应该删去“ATM与用户交互”这个候选的关联。
如果用动作表述的需求隐含了问题域的某种基本结构，则应该用适当的动词词组重新表示这个关联。
例如，在ATM系统的需求述中，“中央计算机确定事务与分行的对应关系”隐含了结构上“中央计算机与分行通信”的关系。
（4）三元关联
三个或三个以上对象之间的关联．大多可以分解为二元关联或用词组描述成限定的关联。
在ATM系统的例子中，“柜员输入针对账户的事务”可以分解成“柜员输入事务”和“事务修改账户”这样两个二元关联。
而“分行计算机处理针对账户的事务”也可以做类似的分解。
“ATM与中央计算机交换关于事务的信息”这个候选的关联，实际上隐含了“ATM与中央计算机通信”和“在ATM上输入事务”这两个二元关联。
如果三元关联中涉与的某个实体仅用于描述另两个实体的关系．而且这个实体本身不包含属性，则它是二元关联上的链属性。
例如，“公司付给员工工资”可以改造成带有链属性“工资”的二元关联“公司雇用员工”。
（5）派生关联
应该去掉那些可以用其他关联定义的冗余关联。
例如，在ATM系统的例子中，。
总行拥有多台ATM”实质上是“总行拥有中央计算机”和“ATM与中央计算机通信”这两个关联组合的结果。
而“分行计算机维护账户”的实际含义是，“分行保管账户”和“事务修改账户”。
第三，进一步完善
应该进一步完善经筛选后余下的关联。
通常从下述几个方面进行改进：
（1）正名
好的名字是帮助读者理解的关键因素之一。
因此，应该仔细选择含义更明确的名字作为关联名。
例如，“分行提供分行计算机和柜员终端”不如改为“分行拥有分行计算机”和“分行拥有柜员终端”。
（2）分解
为了能够适用于不同的关联，必要时应该分解以前确定的类一对象。
倒如，在ATM系统中，应该把“事务”分解成“远程事务”和“柜员事务”。
（3）补充
发现了遗漏的关联就应该与时补上。
例如，在ATM系统中把“事务”分解戚上述两类之后，需要朴充“柜员输入柜员事务”、“柜员事务输进柜员终端”、“在ATM上输入远程事务”和“远程事务由现金兑换卡授权”等关联。
（4）标明阶数
应该初步判定各个关联的类型，并粗略地确定关联的阶数。
但是，无须为此花费过多精力，因为分析过程中随着认识的逐渐深入，阶数也会经常改动。
图2--1是经过上述分析过程之后得出的ATM系统原始对象图。
图2--1ATM系统原始对象图
划分主题
在开发大型、复杂系统的过程中，为了降低复杂程度，人们习惯于把系统再进一步划分成几个不同的主题，也就是在概念上把系统包含的容分解成若干个畴。
应该按问题领域而不是用功能分解方法来确定主题。
此外，应该按照使不同主题的对象相互间依赖和交互最少的原则来确定主题。
以ATM系统为例，可划分为“总行”、“分行”、“ATM”等三个主题，分别可标识为如下图2—2所示。
图2—2把ATM系统划分为三个主题
确定属性
属性是对象的性质，藉助于属性我们能对类---对象和结构有更深入、更具体的认识。
注意，在分析阶段不要用属性来表示对象间的关系，使用关联能够表示两个对象间的任何关系，而且把关系表示得更清晰、更醒目。
一般说来，确定属性的过程包括分析和选择两个步骤。
首先，分析
通常，在需求述中用名词词组表示屑性，例如，“汽车的颜色”或“光标的位置”。
往往用形容词表示可枚举的具体属性，倒如，“红色的”、“打开的”。
但是，不可能在需求述中找到所有属性，分析员还必须藉助于领域知识和常识才能分析得出需要的属性。
幸运的是，属性对问题域的基本结构影响很小。
随着时间的推移，问题域中的类始终保持稳定，属性却可能改变了，相应地，类中方法的复杂程度也将改变。
属性的确定既与问题域有关，也和目标系统的任务有关。
应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题围的属性。
在分析过程中应该首先找出最重要的属性，阻后再逐渐把其余属性增添进去。
在分析阶段不要考虑那些纯粹用于实现的属性。
第二步，选择
认真考察经初步分析而确定下来的那些属性，从中删掉不正确的或不必要的属性。
通常有以下几种常见情况：
（1）误把对象当作属性
如果某个实体的独立存在比它的值更重要，则应把它作为一个对象而不是对象的属性。
在具体应用领域中具有自身性质的实体，必然是对象。
同一个实体在不同应用领域中，到底应该作为对象还是属性，需要具体分析才能确定。
例如，在邮政目录中，“城市”是一个属性，而在人口普查中却应该把“城市”当作对象。
（2）把链属性误作为属性
如果某个性质依赖于某个关联链的存在，则该性质是链属性，在分析阶段不应该把它作为对象的属性带别是在多对多关联中，链属性很明显，即使是在以后的开发阶段中，也不能把它归并成相互关联的两个对象中任一个的属性。
（3）把限定误当成属性
限定是一种特殊的链属性。
正确使用限定词往往可以减少关联的阶数。
如果把某个属性值固定下来以后能减少关联的阶数，则应该考虑把这个属性重新表述成一个限定词。
在ATM系统的例子中，“分行代码”、“账号”、“雇员号”、“站号”等都是限定词。
（4）误把部状态当成了属性
如果某个性质是对象的非公开的部状态，则应该从对象模型中删掉这个属性。
（5）过于细化
在分析阶段应该忽略那些对大多数操作都没有影响的属性。
（6）存在不一致的属性
类应该是简单而且一致的。
如果得出一些看起来与其他属性毫不相关的属性，则应该考虑把该类分解成两个不同的类。
经过筛选之后，得到ATM系统中各个类的属性，如图2—3所示。
图中还标出了一些限定词：
“卡号”实际上是一个限定词。
在研究卡号含义的过程中，发现以前在分析确定关联的过程中遗漏了“分行发放现金兑换卡”这个关联，现在把这个关联补上，卡号是这个关联限定词。
“分行代码”是关联“分行组成总行”上的限定词。
“账号”是关联“分行保管账户”上的限定词。
“
升级会员 