标签：需求 系统 类图 Diagram 用例 银行业务 实验报告 办理 体系结构

实验目的

通过对一个实际案例进行完整的系统分析和设计，对课程中所学习的知识进行强化巩固和应用。

• 针对一个实际系统，根据需求描述，通过需求确定方法，确定详细用户需求；
• 基于详细用户需求，对系统进行需求分析和规格说明，建立系统分析模型；
• 设计系统体系结构，建立系统逻辑体系结构模型和物理体系结构模型；
• 基于系统体系结构和系统分析模型，对系统进行详细设计，建立系统设计模型；
• 培养对实际系统进行分析和设计的能力；
• 培养通过 UML 对实际系统进行建模的能力。

---

实验原理

利用统一建模语言 UML 对项目进行完整的分析与建模，借助 StarUML 建模工具绘制相关的 UML 模型。StarUML（简称 SU），是一种创建 UML 类图，生成类图和其他类型的统一建模语言 UML 图表的工具。

（1）确定详细用户需求
软件需求（Software Requirement）是一个软件系统所需具有的功能与性能要求，它描述了待开发软件系统的行为、特性、属性及其约束条件。

1. 系统服务：功能性需求
   ① 系统应该提供的服务、对输入做出的反应、系统在特定条件下的行为等；
   ② 系统范围、必须的业务功能、要求的数据结构。
2. 系统约束：非功能性需求（也叫做补充需求）
   ① 对系统提供的服务或功能遵循的约束；
   ② 关于“视觉与使用体验”、性能、安全性等。

（2）建立系统分析模型

1. 用例图（Use Case Diagram）
   用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。
   用例图是外部用户（被称为参与者）所能观察到的系统功能的模型图，主要用于对系统、子系统或类的功能行为进行建模。
   用例图主要的作用有三个：①获取需求；②指导测试；③还可在整个过程中的其它工作流起到指导作用。
2. 活动图（Activity Diagram）
   活动图阐明了业务用例实现的工作流程。业务用例由一系列活动组成，它们共同为业务主角生成某些工件；业务工作流程说明了业务为向所服务的业务主角提供其所需的价值而必须完成的工作。
   可以使用垂直实线将活动图划分为泳道，每条泳道代表整个工作流程的某个部分的职责，该职责由组织的某个部门来执行。在业务流程主体上，通过泳道（纵向条）区分出执行主体，即部门和岗位来。
   泳道之间的排序并不会影响语义，每个活动状态都指派了一条泳道，而转移则可能跨越数条泳道。

（3）设计系统体系结构

1. 构件图（Component Diagram，组件图）
   构件图主要用于描述各种软件构件之间的依赖关系，所设计的系统中的构件的表示法及这些构件之间的关系构成了构件图。构件是系统中遵从同一组接口且提供其实现的物理的可替代的部分。
   构件图经常是一个架构师在项目的初期就建立的非常重要的图，因为它们模型化和文档化了一个系统的架构，开发者和系统可能的系统管理员会发现这一工作的关键产品有助于他们理解系统。
2. 部署图（Deployment Diagram，配置图）
   部署图是用来显示系统中软件和硬件的物理架构，从部署图中可以了解到软件和硬件组件之间的物理关系以及处理节点的组件分布情况。使用部署图可以显示运行时系统的结构，同时还传达构成应用程序的硬件和软件元素的配置和部署方式。

（4）建立系统设计模型

1. 类图（Class Diagram）
   类图显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图最基本的元素是类（Class）或者接口（Interface），类图可以组织在（并且属于）包（Package）中，仅显示特定包中的相关内容。
   类图是面向对象建模的主要组成部分，它用于描述系统的结构化设计。类图既用于应用程序的系统分类的一般概念建模，也用于详细建模，将模型转换成编程代码，也可用于数据建模。
2. ER 图（Entity Relationship Diagram，实体-联系图）
   ER 图提供了表示实体类型、属性和联系的方法，是用来描述现实世界的概念模型。
   ER 图用矩形框表示实体型，矩形框内写明实体名称；用椭圆图框或圆角矩形表示实体的属性，用实心线段将其与相应关系的实体型连接起来；用菱形框表示实体型之间的联系成因，在菱形框内写明联系名，并用实心线段分别与有关实体型连接起来，同时在实心线段旁标上联系的类型（1:1、1:n 或 m:n）。
3. 顺序图（Sequence Diagram）
   顺序图将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸；横向轴代表了在协作中各独立对象的类元角色。
   类元角色用生命线表示，当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。消息用从一个对象的生命线到另一个对象生命线的箭头表示，箭头以时间顺序在图中从上到下排列。
   顺序图是一种动态建模方法，一般用于确认和丰富一个使用情境的逻辑。一个使用情境就是系统潜在的使用方式的描述，也就是它的名称所要描述的。
4. 状态机图（Statechart Diagram）
   状态机图用于对系统的动态方面进行建模，适合描述一个对象在其生命周期中的各种状态及状态的转换。状态图显示状态机（它指定对象所在的状态序列）、使对象达到这些状态的事件和条件、以及达到这些状态时所发生的操作。
   状态机是一种行为，它说明对象在其生命周期中响应事件所经历的状态变化序列以及对那些时间的响应。状态机从对象的初始状态开始，响应事件并执行某些动作，从而引起状态的转换；在新状态下又继续响应事件并执行动作，如此循环进行到对象的终结状态。

---

实验内容

（1）需求描述
银行是与人们日常生活紧密相关的一个机构，银行可提供存款、取款、转账等业务。在银行设立账户的个人或机构称为银行的客户。一个客户可以在银行开多个账户，客户可以存钱到自己的账户中，也可以从自己的账户中取钱，还可以将存款从自己的账户转到另一个账户。客户可以随时查询自己的账户信息，查询以前所进行的存款、取款、转账等交易记录。客户有权利要求关闭自己的账户。
银行业务办理方式有：银行柜台、ATM、网银、手机银行。
任选两种方式进行分析和设计（最好选择银行柜台）。

（2）需求确定
根据需求描述，通过需求确定方法，确定详细用户需求：
① 确定需求来源；
② 采用需求引导方法导出需求，如面谈、业务示范、原型法、头脑风暴、联合应用开发等；
③ 进行需求协商与确认；
④ 确定用户需求，包括功能性需求和非功能性需求。
模拟以上过程，用文字描述该过程。

（3）需求分析
基于详细用户需求，对系统进行分析和规格说明，建立系统分析模型：
① 从用户需求中提炼用例，创建系统用例图（多张），反映功能需求；
② 用活动图（泳道图）描述每一个用例，反映业务处理要求。

（4）体系结构设计
设计系统体系结构，建模逻辑体系结构和物理体系结构：
① 用构件图或包图说明系统的逻辑体系结构；
② 用部署图说明系统的物理体系结构以及构件或制品的部署。

（5）详细设计
基于系统体系结构和分析模型，对系统进行详细设计，建立系统设计模型：
① 从用户需求和用例场景中发现类，创建系统类图，命名类和属性，建立类之间的关系，反映系统静态结构设计；
② 从类模型中导出数据库设计，只需提供概念模型 ER 图；
③ 根据用例场景和类图绘制顺序图，反映系统动态交互设计；
④ 对于有明显状态变化的实体类，绘制其状态机图；
⑤ 补充类操作，演化类图。

（6）要求
专业 UML 建模工具，如 StarUML 或 Bouml。
实验完成后，撰写标准实验报告，描述系统的分析和设计，体现出分析和设计的过程、探讨和说明等。

---

实验器材

硬件环境：个人计算机
操作系统：Windows 10
软件工具：StarUML

---

实验步骤

（1）确定详细用户需求

1. 需求描述
   银行是与人们日常生活紧密相关的一个机构，银行可提供存款、取款、转账等业务。在银行设立账户的个人或机构称为银行的客户。一个客户可以在银行开多个账户，客户可以存钱到自己的账户中，也可以从自己的账户中取钱，还可以将存款从自己的账户转到另一个账户。客户可以随时查询自己的账户信息，查询以前所进行的存款、取款、转账等交易记录。客户有权利要求关闭自己的账户。
   银行业务办理方式有：银行柜台、ATM、网银、手机银行。

2. 银行柜台
   ① 业务示范：
   客户到银行柜台向银行工作人员提出要办理的业务，银行工作人员根据客户信息办理相关业务。
   可办理的业务有：开户、销户、存款、取款、转账、查询账户信息、查询交易记录。为了办理业务，银行工作人员还需要：登录系统。
   ② 功能性需求：
   客户：提出业务要求。
   银行工作人员：开户、销户、存款、取款、转账、查询账户信息、查询交易记录（包括查询存款记录、查询取款记录、查询转账记录）、登录系统。
   ③ 非功能性需求：
   高性能、可靠性、可扩展性、易管理维护、安全性。
   系统每一个服务级别需求对应其相关服务质量衡量标准，应根据实际情况做出均衡的选择。

3. ATM（自动取款机）
   ① 业务示范：
   ATM 是银行在银行营业大厅、超市、商业机构、机场、车站、码头和闹市区设置的一种小型机器，利用一张信用卡大小的胶卡上的磁带或芯片卡上的芯片记录客户信息，让客户可以通过机器进行各项银行柜台服务。
   客户将银行卡插入读卡器，读卡器识别卡的真伪，并在显示器上提示输入密码。
   客户通过键盘输入密码，取款机验证密码是否有效。如果密码错误，则提示错误内容；如果正确，则提示登录成功。
   客户根据自己的需要可选择各项业务，在客户选择后显示器进行交互提示和操作确认等信息。
   银行工作人员需要定期维护机器。
   ② 功能性需求：
   客户：登录系统、存款、取款、转账、查询账户信息、查询交易记录（包括查询存款记录、查询取款记录、查询转账记录）。
   银行工作人员：维护机器。
   ③ 非功能性需求：
   高性能、可靠性、可扩展性、易管理维护、安全性。
   系统每一个服务级别需求对应其相关服务质量衡量标准，应根据实际情况做出均衡的选择。

（2）建立系统分析模型
基于详细用户需求，对系统进行分析和规格说明，建立系统分析模型。

1. 用例图（Use Case Diagram）
   从用户需求中提炼用例，创建系统用例图（多张），反映功能需求，如下图所示。
   银行柜台的用例图：
   
   ATM 的用例图：
   

2. 活动图（Activity Diagram）
   用活动图（泳道图）描述每一个用例，反映业务处理要求，如下图所示。
   开户和销户的活动图：
   
   客户使用 ATM 的活动图：
   
   查询交易记录的活动图：
   

（3）设计系统体系结构
设计系统体系结构，建模逻辑体系结构和物理体系结构。

1. 构件图（Component Diagram，组件图）
   用构件图或包图说明系统的逻辑体系结构，如下图所示。
   银行系统的构件图：
   

2. 部署图（Deployment Diagram，配置图）
   用部署图说明系统的物理体系结构以及构件或制品的部署，如下图所示。
   银行系统的部署图：
   

（4）建立系统设计模型
基于系统体系结构和分析模型，对系统进行详细设计，建立系统设计模型。

1. 类图（Class Diagram）
   从用户需求和用例场景中发现类，创建系统类图，命名类和属性，建立类之间的关系，反映系统静态结构设计，如下图所示。
   银行系统的实体类图：
   
   银行系统的边界类图：
   
   银行系统的控制类图：
   

2. ER 图（Entity Relationship Diagram，实体-联系图）
   从类模型中导出数据库设计，只需提供概念模型 ER 图，如下图所示。
   银行系统的 ER 图：
   

3. 顺序图（Sequence Diagram）
   根据用例场景和类图绘制顺序图，反映系统动态交互设计，如下图所示。
   登录系统的顺序图：
   
   存款的顺序图：
   
   取款的顺序图：
   
   转账的顺序图：（转账与取款的操作有相似，故省略返回信息和分支）
   
   开户和销户的顺序图：
   
   查询信息的顺序图：
   

4. 状态机图（Statechart Diagram）
   对于有明显状态变化的实体类，绘制其状态机图，如下图所示。
   账户的状态机图：
   

5. 演化类图（Class Diagram）
   补充类操作，演化类图，如下图所示。
   银行系统的演化类图：
   

---

实验结果

标签：需求,系统,类图,Diagram,用例,银行业务,实验报告,办理,体系结构
来源： https://blog.csdn.net/weixin_45034316/article/details/111559605

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。