论基于UML的需求分析

论基于UML的需求分析
摘要：2020年4月，本人所在的某市金融投资集团启动了集团综合管理系统建设，该项目实现基金、融资租赁、资金管理、转贷、融资担保、保理等各金融业务信息化及人力资源、智能办公、法务管理等内部管理功能。在此项目中，我担任了架构师，负责项目总体架构设计工作。本文以该综合管理系统为例，主要论述了基于UML的需求分析。我们通过用例描述了系统参与者与各业务系统之间的交互活动，通过用例图描述了用例与参与者及用例之间的关系，从而形成需求描述；通过层次架构风格形成总体设计，并对系统模块进行划分，产生包图，从而生成顶层架构设计；通过分析汇总抽象系统关键业务概念，结合之间的关系，用类图表示系统的概念模型。最终项目顺利上线，运行平稳，获得了领导的高度认同。

正文：本人所在的某市金融投资集团已经建设了移动办公系统、财务系统、融资租赁系统、基金管理系统等应用系统，但仍有部分业务缺乏信息化支撑，已建成的系统比较分散，主要是“竖井式”方式建设，系统与系统之间信息不共享以及信息与业务流程相脱节。针对这些问题，2020年4月，经集团决定，启动集团综合管理系统建设，实现以下功能。一、实现转贷、保理、融资担保、资金管理、人力资源、智能办公等业务流程信息化，同时整合基金管理系统、移动办公系统、财务系统等已有信息资产，促进部门、子公司之间横向协同。二、建立统一共享的信息平台，利用数据报表平台为管理层提供决策信息支持，实现纵向管控。三、建立涵盖分布式文件存储、单点登录、分布式事务支持、短信邮件通知、可控任务调度等服务的基础IT设施，提供高质量、可重用的平台服务。
在此项目中，我担任架构师一职，负责系统总体架构设计。由于集团相关人员缺乏对信息化的认识，因此我们决定采用基于UML的需求分析对需求进行系统化的分析，以形成以用例图为核心，活动图、状态图、交互图、包图、类图的需求分析及顶层设计与概念模型。
基于UML的需求分析过程主要活动如下。一、根据业务需求描述生成用例以及用例图。用例是外部角色使用系统所产生的一系列交互的描述，包含了前置条件、主事件流、辅事件流、后置条件等，而用例图描述了角色及用例、用例与用例之间的关系，包括关联、扩展、包含、泛化等关系。二、顶层架构设计。结合以往架构设计经验模式，根据实际情况，进行微调，如层次风格，过滤器管道风格，B/S风格等，根据风格以合适的粒度构建包，并根据分析用例及需求，对包中所包含的类进行填充，我们还需要从权限控制角度及进程部署角度对包进行划分，从而建立顶层架构设计。三、建立概念模型。概念模型是对业务用例实现的对象模型，是对领域内的概念类和现实世界中对象的可视化表示，通常可用类图进行表示，可根据需要选择细化类的属性和操作，以及类之间的相互作用关系，包括依赖、关联、泛化、组合、聚合等关系。
一、通过用例和用例图描述需求。
用例是对系统参与者与系统交互过程的描述，而用例图展示了其间的关系。首先，我们识别系统参与者，参与者是用例的作用主体，也是需求的来源。对于业务类系统模块主要角色包括客户经理、风险审核人员、业务部主管、分管领导、总经理等，对于非业务类模块如人力资源系统模块则分为普通员工、部门领导、hr、子公司hr等角色，同一个人对于不同的业务模块可能处于不同的角色，如客户经理岗对于人力资源模块来说他又是公司普通员工的角色。然后根据需求描述中的功能模块，识别该功能交互过程中的相关角色，通过用例描述交互过程。以业务类系统项目立项为例，形成项目立项增删改查、流程审批等用例。对于这些用例，由于几乎每个都涉及工作流审批过程，因此对其进一步通过活动图进行细化，从而描述清楚业务流程及可能存在的并发过程。用例并不是完全独立的，用例与参与者及用例之间的交互及关系需要用用例图进行描述，我们以业务为单位，形成了每个业务的主用例图，主用例图基本涵盖从项目立项、尽调、调整、合同、投放、收付款、收尾的完整流程。这样，我们就形成了完整的需求描述。
二、顶层架构设计。
顶层架构设计是对系统架构的初步设计。根据ERP类型项目开发经验，我们一致认为采用层次架构风格是最为合适的，一来是层次架构清晰地划分了架构层次，对于系统的扩展和维护都非常有力，二来SSM框架整体比较完善，开发人员对该架构也都非常熟悉，开发效率会得到充分释放。因此，我们以层次架构风格为主，以事件驱动系统风格、管道过滤器为辅的总体设计。确定了基础的架构风格之后，结合用例图及用例描述，进行丁层架构设计。首先我们按各个业务模块划分了不同的包，形成以租赁业务、基金业务、融担业务、人力资源等包结构。在此基础上对各个模块包进行进一步划分，我们形成了以VUE为界面框架，服务器端划分为Controller包，Service包，Dao包，Mapper包，Entity包，Dto包等，然后将需求描述的相关概念映射到包中，填充包中所包含的内容,以转贷模块的Entity包为例，它包含项目实体、合同实体、投放实体、财务实体等。并对包之间的作用关系进行分析绘制，主要有包含和依赖关系，形成总体包图，形成顶层架构设计。
三、领域概念模型。
在得到顶层架构设计后，我们进一步对其细化，设计领域概念模型。对于领域概念模型，我们主要用类图进行描述。一方面我们需要细化顶层设计中包中的类属性及操作，另一方面，我们还需要分析类之间的关系，包括关联、泛化、组合、聚合等。由于集团金融业务之间具有极大的相似性，业务流程均可分为立项、尽调、调整、合同等流程，因此我们实现了通用业务层。通用业务层形成以项目、尽调报告、调整数据、合同信息、投放信息、收款、付款、费率计算等类为核心的类图，然后其它业务在此基础上进行扩展，如项目数据，转贷因为有自己的转贷金额、贷款到期金额、到期时间等特定数据，因此形成单独的转贷项目类。另外还需分析类之间的作用关系，如转贷项目类与基础项目类为泛化关系，项目与尽调报告为1对1的关联关系。另外，部分类的属性和操作也可以列出，以形成尽可能详细的类图。通过细化，形成了领域概念模型。当然，在领域概念模型阶段，我们对类的设计并不是完整的，需要在后面设计阶段进一步进行细化，但它对后续设计的指导作用是巨大的。
项目于2021年8月顺利上线，上线后运行平稳，获得了领导和同事的一致好评。特别是在项目中采用了基于UML的需求分析，形成了不管是对用户还是开发设计人员都非常友好、清晰的用例及用例图，以及通过活动图、交互图对其进行详细描述，又用包图形成顶层设计，类图形成领域概念模型，为后续的设计开发打下了非常好的基础。
但是过程中还是遇到了不少问题，如由于正处于集团业务整体规范化运作的节点进行信息化，本身业务需求也在不断地变动发展，因此我们需要对需求不断做变更。这就要求我们做好变更控制，并对采纳的需求变更及时做好文档的变更，包括需求文档及设计文档，而这时候，基于UML的需求分析也发挥了巨大的作用，由于其清晰直观地特性，对于不同的角色人员，也均可以找到自己所重点关注的视图，使得变更还算顺利，保证了项目仍在可控范围内推进，并没有进度延后的现象出现。