在UML使用过程中，经常会遇到UML需求分析问题，这里就向大家介绍一下UML的需求分析大致步骤，为了便于大家理解以实例向大家介绍，希望通过本文的介绍你对UML需求分析步骤有所了解。

AD：51CTO学院：IT精品课程在线看！

本节向大家介绍一下UML需求分析的一般步骤，本节用实例向大家介绍，相信通过本节的介绍你对UML需求分析有一定的认识。下面让我们一起来学习具体介绍吧。

基于UML需求分析

在初步的业务需求描述已经形成的前提下，基于UML需求分析大致可分为以下步骤：

（1）利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景；对场景进行汇总、分类、抽象；形成用例；确定执行者与用例、用例与用例图之间的关系，生成用例图。

（2）利用包图及类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。

上述两个步骤并没有时序关系，它们可以并行展开，如图5-3-1所示。

图5-3-1　UML需求分析过程

本节将依次介绍上述步骤中涉及的UML语言机制，并结合“家庭保安系统”实例说明每步骤中基于UML需求分析方法。

开发场景

场景是指从单个执行者的角度观察目标软件系统的功能和外部行为。这种功能通过系统与用户之间的交互来表征。因此也可以说，场景是用户与系统之间进行交互的一组具体的动作。相对于用例而言，场景是用例的实例，而用例是某类场景的共同抽象。

对场景的完整描述应包含场景名称、执行者实例，前置条件、事件流和后置条件。

例如，“家庭保安系统”的初步需求描述：“家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与用户进行信息交互。

配置操作包括：

（1）指定每一传感器的种类和编号；

（2）设置开、关机密码；

（3）指定报警电话电码；

（4）指定报警延迟和电话重拨延迟时间（以秒为单位）；

当软件系统收到传感器发出的数据后，判别是否出现异常事件。如果是，则在指定的延迟时间内拨报警电话号码，拨号操作将按照重拨延迟反复进行，直至电话接通。然后软件系统负责报告时间、地点和异常事件的性质。

开机后，软件系统负责显示当前工作状态，接收并处理用户指令。

根据以上描述，该系统具有“系统配置”、“开机”、“关机”、“门窗监测”、“烟雾监测”和“复位”等场景。其中，门窗监测场景的具体描述如下：

场景名称：门窗监测。

参与执行者实例：警报器、报警电话、显示器和门窗监视器。

前置条件：系统已开机。

事件流：

（1）门窗监视器发现门或窗户发生异动，向软件系统报告异常事件。

（2）软件系统启动警报器并拨报警电话号码。

（3）报警电话接通后，软件系统播出语音，报告异常事件发生的时间、地点和事件的性质（门窗异动）。

（4）系统在控制面板的显示器上显示报警时间及当前状态（报警：门窗异动）。

后置条件：系统处于“报警”状态。

UML需求分析过程中根据场景作用的不同，可以将其划分为以下类型：

（1）实际场景。对实际的业务处理流程或其优化流程的描述。实际场景是用户需求的重要组成部分。

（2）设想场景。分析人员对目标软件系统投入应用后经改进或优化的业务流程的描述。这种场景可视为一种纸面原型，主要用于帮助分析人员挖掘潜在的用户需求。

（3）评价场景。以确认需求或提出改进建议为主要目的的业务流程描述。评价场景可以在用例生成后用例进行实例化而形成，以便用户对用例进行评价或改进。

（4）培训场景。面向开发人员及用户解释系统的功能和外部行为的业务流程描述。

对以下问题的回答有助于分析人员进行UML需求分析获取场景：

（1）目标软件系统有哪些执行者？

（2）执行者希望系统执行哪些任务？

（3）执行者希望获得哪些信息？这些信息由谁生成？由谁修改？

（4）执行者需要通知系统哪些事件？系统响应这些事件时会表现出哪些外部行为？

（5）系统将通告执行者哪些事件？

总之，确定执行者和场景的关键在于理解业务领域和初步需求描述文档。场景将促成开发人员和用户对业务处理流程和目标软件系统的功能范围的共同理解。在场景确定之后，通过对场景的汇总、分类归并和抽象即可形成用例。本节关于UML需求分析相关内容介绍到这里。