一、需求分析

1.概念定义

需求分析，要明确以下4个概念的具体内容：
资源是指使用或产生的对象，如人、物料、信息、产品等。
目标是指希望资源处于什么样的状态。
过程是指被执行的活动，这些活动会改变资源的状态。
规则是指在某些方面进行规定或约束的声明，如一个过程应该怎样执行、资源的结构应该是怎样的等。

2.需求描述

储户在ATM机上插入银行卡进行身份验证。合法的储户可以在ATM机上进行存款、取款、账户余额查询、转账等事务。储户在ATM机上不能进行信用付款、修改密码等操作。

3.需求分析

资源有银行卡、账户和现金。进一步分析可知，银行卡和现金是物理产品，账户是电子信息。

目标有以下两种类型：
目标1：账号、密码、账户余额，三者构成一个一对一的整体。
目标2：账户余额正确反映储户在银行中的存款数目。

过程有登录、存款、取款、账户余额查询、转账。
"登录"过程包括以下活动：储户在ATM机的读卡终端上插入银行卡，储户在ATM机的键盘上输入密码。如果密码正确，则成功登录系统。储户可以进行后续的操作：存款、取款、账户余额查询、转账。
"存款"过程包括以下活动：储户在ATM机的存款终端上放入现金，系统验证现金的真伪，并统计现金的总额，系统修改账户余额数目。
”取款"过程包括以下活动：储户在ATM机的键盘上输入取款金额，系统判断账户余额是否足额，储户从ATM机的存款终端上取走现金，系统修改账户余额数目。
”账户余额查询"过程包括以下活动：储户在ATM机的键盘上输入查询选项（1表示查余额；2表示查历史记录），ATM机的显示终端上显示账户余额数目或存取操作历史记录。
"转账"过程包括以下活动：储户在ATM机的键盘上输入转账选项，储户在ATM机的键盘上输入他人的账号，储户在ATM机的键盘上输入转账金额，系统判断账户余额是否足额，系统修改账户余额数目。

规则有以下7种类型：
规则1：账号由15_{19位的数字0}9组成。
规则2：密码由6位的数字0~9组成。
规则3：每天每次输人密码时，正确性验证三次。三次错误，则禁止当天的ATM机的操作。
规则4：无论是进行存款、取款还是转账，对最终的操作给予确认提示。
规则5：每次取款或转账时，当账户余额不足时，终止后续操作。
规则6：每天取款最多2万元，每次取款最多5千元。
规则7：每次存款或取款时，对现金进行真币验证，禁止伪币流通。

二、UML图型概览

附：UML术语标准和分类_pingcode的博客-CSDN博客

2.1用例图（Use Case Diagram）

用例图是被称为参与者的外部用户所能观察到的系统功能的模型图。
参与者是系统的主体，表示提供或接收系统信息的人或系统。
用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。
用例图的用途是列出系统中的参与者与用例，并显示哪个参与者参与了哪个用例的执行。

在本例中，参与者是储户，系统有5个功能：登录、存款、取款、账户余额查询、转账。实际上对应5个过程，因为每个过程体现了参与者与系统的一次交互行为。所以，系统有5个用例。

下面展示了本例的用例图：

在这里插入图片描述

2.2活动图（Activity Diagram）

用活动图描述业务流程，对应于某个用例的用例描述。
前者用图型表达参与者与系统功能的交互行为，后者用自然语言表达参与者与系统功能的交互行为。

在活动图中定义了流程从哪里开始，到哪里结束，以及在这之中包括哪些活动，并描述了活动发生的顺序。

每个过程对应一个活动图，在本例中，存在5个过程，分别对应5个活动图。
限于篇幅，下面只展示了本例的“登录“和“存款“活动图：

在这里插入图片描述

2.3顺序图（Sequence Diagram）

顺序图描述了对象之间传递消息的时间顺序，表达了用例的用例描述是如何用对象及对象间的消息传递来实现的。

每一个对象用一条竖直虚线代表其生命周期，即生命线；
生命线上的矩形表示一个交互活动所占用的时间段；
生命线之间的箭头连线表示消息。从上到下，消息的位置关系表达了消息之间的时间顺序。

每个用例的用例描述对应一个顺序图，在本例中，存在5个用例的用例描述，分别对应5个顺序图。
限于篇幅，下面只展示了本例的“登录“和“存款“用例的用例描述对应的顺序图：

在这里插入图片描述

读卡机对象代表读卡机驱动程序，完成从银行卡中读取储户的账号及银行信息。显示屏对象代表显示器驱动程序，完成信息的显示输出。键盘代表键盘驱动程序，完成从键盘上读取输入的数字信息。存款机对象代表存款机驱动程序，完成从存款机中获取现金、验钞、统计现金金额。账户信息对象代表在银行数据库中储存的储户账户实体类，包括账号、密码、银行行号、存款余额等信息。

在本例中，每个用例的用例描述对应一个顺序图。它是在对象层次上用图型表达参与者与系统功能的交互行为。对于同一个用例的用例描述，存在3种表达方式：用例描述、活动图、顺序图。用例描述和活动图在描述参与者与系统功能的交互行为时，基本单位是活动。顺序图在描述参与者与系统功能的交互行为时，基本单位是对象及对象间消息。若干个对象及它们之间的消息传递完成一个活动的任务。
例如，图一中的“储户“对象、“读卡机“对象，以及“插入银行卡“消息，共同完成了2.2活动图图一中的“储户插入银行卡“活动。

2.4通信图（Communication Diagram）

通信图对在一次交互中有意义的对象和对象间的链建模。
在通信图中，直接相互通信的对象之间有一条直线，没有画线的对象之间不直接通信。
附在直线上的箭头代表消息（发送者和接收者），消息的编号代表消息的发生顺序。
一般情况下，顺序图和通信图可以互相转换。

下面展示了本例的“存款“用例的顺序图对应的通信图：

在这里插入图片描述

另外，通信图的一个重要用途是表示一个类操作的实现。通信图可以说明类操作中用到的参数和局部变最及操作中的永久链。
当实现一个行为时，消息编号对应了程序中嵌套调用结构和信号传递过程。

2.5类图（Class Diagram）

类图描述系统的静态结构，展现了一组类、接口、协作和它们之间的关系。
需要永久储存的实体类之间的关系用关联关系表示，主要反映对象（类的实例）之间的结构连接多重性。其他类（边界类、控制类、实体类）之间的关系常用依赖关系表示，主要反映一个对象使用另一个对象的属性和／或方法。

下面展示了银行ATM系统的类图：

在这里插入图片描述

在本例中，“账户信息”类和“交易记录”类之间是一对多的关联关系，其他类之间（这些类包括读卡机、键盘、显示屏、存款机、账户信息）是依赖关系。这些依赖关系对应着顺序图中的消息传递，这些消息传递属于操作调用类型。例如，“读卡机”类依赖于“账户信息”类，是因为前者要调用后者的verifyFunds()方法。

2.6状态机图（State Machine Diagram）

状态图是一个类对象所经历的所有历程的模型图，它由对象的各个状态和连接这些状态的变迁组成。
每个状态对一个对象在其生命周期中满足某种条件的一个时间段建模。当一个事件发生时，它会触发状态间的变迁，导致对象从一种状态转化到另一种状态。

下面展示了本例的“账户信息”类对象的状态图：

在这里插入图片描述

在本例中，“账户信息”类对象可以有几种不同的状态：打开、可用、透支、关闭。
如果储户没有插入银行卡，则”账户信息”类对象是不可用的，即无法进行存款、取款、账户余额查询、转账等操作。插人银行卡后，“账户信息”类对象处于“打开“状态，此时，还没有进行任何操作的选择，所以处于等待状态。如果储户选择的操作是存款或账户余额查询，则”账户信息”类对象不会发生异常现象，所以不用描述这两类操作引起的状态变迁。如果储户选择的操作是取款或转账，则在取款额大于存款余额的情况下，”账户信息”类对象会发生异常现象，所以要描述这两类操作引起的状态变迁。取款或转账可以连续操作，只要存款余额充足即可，所以“可用“状态可以有自反变迁（也称为递归变迁）。“透支“状态会引发程序的异常处理，其实质就是取消当前的取款或转账操作。无论在“打开“状态、“可用“状态、“透支“状态中的哪个状态，只要出现“退卡”事件，就可以结束“账户信息”类对象的本次活动期。

针对一个具体的软件系统，通常情况下，不会对所有的类对象都建立一个状态图，只有那些需要刻画属性取不同值的类对象，才有可能和必要建立状态图。此外，状态图的一个重要用途是表示一个类操作的实现。在模型转换和代码生成自动化技术的支持下，从状态图可以自动生成类操作的代码。此外，状态图也支待测试用例的设计和测试活动的进行。

2.7构件图（Component Diagram）

构件图描述了系统中的各种组件（也称为组件图），用于描述系统的体系架构。
组件可以是源代码组件、二进制文件组件或可执行文件组件。
组件之间也存在着依赖关系，利用这种依赖关系可以方便地分析一个组件的变化会给其他组件带来怎样的影响。

下面展示了本例的构件图：

在这里插入图片描述

通常在开发一个软件系统时，不一定要对所有的类的操作编写代码。有些类操作的实现可以通过接口来实现。最常见的接口实现是厂商提供的某类应用的驱动程序。因此，构件图可以准确地表达出软件系统的“软“模块的积木结构特征。就好比一台计算机硬件系统中，CPU部件可以用兼容的不同厂商的产品互换一样，软件系统中的“软“模块也可以实现不同厂商的技术互换。

图中，组件”读卡机”、“显示屏”、”键盘”、“存款机”可以是公开的任何接口，组件ATM.EXE是个任务规范，表示处理线程。在这里，处理线程是个可执行文件，除了调用其他4个组件完成相应的任务外，主要负责存款、取款、账户余额查询、转账功能的代码实现。