论基于UML的需求分析

论基于UML的需求分析

摘要：

需求分析是系统开发人员经过细致的调研和分析，准确理解用户对系统的功能、非功能性、约束条件以及扩展接口的具体要求，将用户非形式化的需求转化为完整的需求定义，从而确定系统必须做什么。而UML可以使用各种静态图和动态图很好的来将需求分析的结果以形象化的图例展示给用户和项目组成员，让其可以很好的理解软件的蓝图并作为后续开发的指南。

本文通过我参与过的仓库管理系统项目的需求分析过程，主要通过用例图、类图、活动图、部署图的建立过程来讨论了基于UML技术的需求分析方法。经过采用各种UML的相关技术，使得我们很好的描绘并展示出系统的需求，有效的保证了需求工作的质量，并提高了用户满意度。最后，分析了实际工作中碰到的问题，并提出了相关改进方法。

正文：

2017年3月，我有幸参与了我所在某电子元器件集团公司其中一个分公司的ERP系统的设计和开发。公司的长远战略目标是在2021年之前完成所有6个据点的系统统一化，预计投资额为6百万，而该跟子公司就是作为系统实现的第一站。整个系统包含，生产计划模块、销售计划、生产管理模块、出货管理模块、仓库管理模块、财务管理模块。

    公司也专门成立了专门项目组，包括项目办公室，项目管理组和各个功能模块小组，项目一开始我就做为一个系统分析师的角色驻现场，带领其中一个小组针对其中一个子模块-仓库管理系统进行前期的系统分析工作。而作为第一个实施的据点，其中的风险性和重要性不言而喻。

    该项目具有较高的业务需求风险和技术风险，各个子公司都有各自一套独立的运行系统，虽然系统老旧但是运行稳定，加上我们并没有成熟系统作为参照。

所以前期需求分析以及用户的反应和支持将对总公司上层领导对我们团队和整个战略信心起很大的作用。整个系统被分为了多个子模块，所以各组负责人一起讨论了在需求分析期间采用的策略、方法和工具。我们排除了传统的面向结构的方法，因为它存在一些局限性，不能很好的满足软件的易复用性、易扩展性和可维护性，同时没有很好的原型系统支持，用户需求处于多变的状态，所以不太适合。我们最终选择了面向对象的方法，并且采用UML-统一建模语言，它使用了统一的表示法，呈现一致的业界都可以支持的风格，并配套了多种静态图和动态图来展示需求。同时也支持了复用，可扩展性，并具备多种配套的case工具。我们就采用了一种优秀的开源工具StarUML作为最终项目需求分析工具。并主要应用用例图、类图、活动图、顺序图和部署图5中图例。

1.用例图获取和设计

用例图主要描述一个个系统功能单元，描述参与者与系统一次交互作用，用例图是展示系统需求给用户最好的图形模式。我们认为用例图获取关键在于如何从用户那里尽可能的挖掘系统的功能性、非功能性、系统约束和接口信息等系统需求，并通过识别参与者、合并需求获取用例、细化用例描述和调整用例模型完成用例图模型的设计。

在识别参与者环节，考虑到历史系统具备一定的稳定性和可操作性，因此现场领导和用户对陌生系统和陌生人有一定的抗拒因素，而且不同层次的人对系统的理解和操作的细节把握不尽相同，所以我们首先通过现场调查，友好询问方式总结出目前的业务逻辑和实际操作步骤，根据我们的所见所得，通过Viso工具绘制出初步的简单的形象的用例模型，然后在通过联合计划会议方式组织相关的领导，IT技术人员、项目组，会议记录，而我作为会议主持，主导多次会议。我们通过对初步用例模型展示和讲解，然后通过确认反复跟用户确认如下问题来不断的识别参与者并为下一步骤做准备。

1.这个活动谁是主要参与者？

2.这个活动需要系统提供服务吗？

3.需要提供什么服务？

4.系统需要其他系统提供什么服务吗？

我们通过这种方式逐步合并需求，建立初步用例模型，在初步需求收集完之后，识别出主要的参与者，由此我们基本明确了仓库管理系统的主要目标和主要功能特性，并得出整个系统包含主要10个主要用例包，料架管理用例包，物料上架用例包，出货单用例包，物流排载用例包，海关报关用例包，捡料单用例包，标签打印用例包，包装扫描用例包，出库确认扫描用例包，库存管理用例包。一共包含了60个具体用例.

在获取初步用例模型后，还需要对用例进行细化，对用例进行合并或者分解，同时编写用例规约，用例规约规定了系统需要完成的步骤，包含了前置条件、后置条件和事件流，前置条件表明用例执行前系统处于的状态，后置条件是执行后系统应该处于的某种状态，事件流描述了用例执行的步骤，与之配套的包含了基流、分支流、替代流，基流描述了用例执行的基本步骤，没有分支和替代，分支流主要描述执行过程中根据不同的条件和不同选择可能执行的步骤，替代流主要描述当出现故障时，执行的相关的替代步骤。我们为每个用例设计了基流，主要步骤设置了替代流。

最后我们还逐步的完善用例的描述，我们通体采用“肯定句”方式细化用例说明，并组织编写了能够被领导、用户和项目成员都能理解的《需求规格说明书》，通过评审后，作为项目验收的依据。

2.类图的设计

用例图可以描述系统需求的动态结构，但是对于需求特征和用例中出现的概念，并没有统一详细的分析，对于用例中的抽象对象，我们设计类图描述其属性和操作，同时描述这些类之间的各种关系，包括泛化、关联、扩展、实现等关系。

3.活动图的设计

   活动图主要是用来描述各用例的内部行为，是用例图的一个补充，包含并发和同步行为，我们针对主要的10个用例给出了内部实现方式和顺序执行规则，同时包含了相关部门和单位的联动方式和执行步骤。

4.部署图的设计

在设计部署图时，我们主要针对各应用服务器、网络、终端电脑、扫描设备、打印设备做了部署。考虑到与总公司最初总设计思路接轨，我们将主要的服务器部署在总公司，并由专门的服务器组进行监管。通过与网络专员确认，采用快速的网络专线链接主干道，信息终端采用普通的网线连接。根据包装线的安排和货架的分配，定义了终端电脑、扫描设备和打印设备的定位。同时在部署图中并给出了所有设备部署相关的标识和描述。

我们最终用了3个月时间完成了需求分析并完善了相关的《需求规格说明书》，在此期间各级领导给了我们莫大的支持，同时用户无论是在调查过程和设计过程也给了我们很大的帮助，虽然在后续的系统开发过程中，随着系统的完善，我们的需求也有一些细节上的变动，但是主体内容并没有受到影响，所以整个需求分析工作是成功的。

通过此次系统需求分析经验，我意识到强调配合和引导用户为主体进行需求分析的重要性，同时发掘具有强大功能的UML，结合专业的CASE工具StarUML可以很好的完成需求分析工作，并为我以后的工作提供了很好的经验基础。