UML提供的丰富的图符体系，代表了可视化建模的发展方向。有利于用户、开发人员、分析人员、测试人员、管理人员和其他涉及项目的人员之间的通信。UML适用于从需求分析到系统实现的软件开发的全过程，在系统开发的不同阶段，可以通过灵活运用UML视图，构建目标系统的需求模型、设计模型和实现模型[5]。下面以大坝安全辅助决策系统为例，说明在系统分析、设计阶段采用的几种典型的可视化建模方法。
2 系统的需求分析
需求分析的目的是对目标系统提出尽可能完整、准确的需求，并建立相应的模型加以描述。大坝安全辅助决策系统主要有两个方面的功能需求：一方面是针对综合评价系统确定的异常或不安全因素，对大坝的安全运行提出辅助决策的建议；另一方面是对综合评价系统尚未找出成因的疑难杂症，通过召集专家，由专家组经过查询资料和分析计算后，进行安全评价，并提出辅助决策建议，根据大坝安全决策的要求，辅助决策系统应由下面3个子系统来满足其功能需求。
(1)资料查询子系统。当综合评价分系统判断为结构异常(或险情)时，根据专家的查询需要，将相关的监测量及其相应的环境量的观测资料、分析评价的成果以及疑难杂症部位的有关设计、施工资料等信息，经过联想和智能处理，快速地提供给专家查询，为专家综合诊断提供全面的信息支持。
(2)专家综合诊断子系统。本子系统的功能是对综合评价分系统找不出成因的建筑物结构异常等疑难杂症，进行专家综合诊断。首先召集有关专家成立专家组，专家们通过查询建筑物结构异常的相关资料，对疑难杂症进行影响因素分析，物理成因分析，找出疑难杂症的成因，然后对大坝进行整体安全评价。
(3)辅助决策建议子系统。当已分析出大坝结构异常(或险情)的物理成因，并提出相应的报警级别后，则调用辅助决策建议子系统，利用知识库中的专家经验和技术规范进行智能推理判断，对结构异常(或险情)提出相应的辅助决策建议，并上报有关单位和领导决策参考。
3 需求分析建模
3.1 用例图 用例代表的是一个完整的功能，用例图将从用户的角度描述辅助决策系统的功能，并指出各功能的操作者。需要说明的是，用例图是站在外部用户的角度识别系统能完成什么样的工作，它不考虑系统内部是如何实现的。用例图中包含系统、角色和用例3种模型元素。(1)系统：系统的边界用来说明构建的用例模型的应用范围。用例图中用一个“方框”表示系统。(2)角色：角色是与所建系统交互的人或事，角色是一个群体概念，代表的是一类能使用某个功能的人或事。用“小人”图符表示。在这里角色指与辅助决策系统交互的人，它包括：①大坝安全专家；②上级有关领导。(3)用例：在UML中，用例被定义成系统执行的一系列动作，用一个“椭圆”来表示。这里用例指辅助决策系统提供的功能或服务。它主要包括：①资料查询；②影响因素分析；③物理成因分析；④安全评价；⑤召集专家；⑥辅助决策建议。用例图描述整个系统中角色和角色、用例和角色，用例和用例的关系。即直观地显示了辅助决策系统为“谁”提供了哪些“功能”(图1)。
3.2活动图 在进行用例分析时，可以使用UML提供的动态模型——活动图，来刻画用例的动态特性。活动图能直观清晰地描述工作流以及并行过程的行为。辅助决策建议用例的活动图见图2所示。从图中看出活动图与常用的程序流程图相似，它们的主要区别在于程序流程图一般用来表示串行过程，而活动图则可以用来表示并行过程。如图中用加黑的粗线段表示同步条，同步条上引出3个活动(辅助决策建议)——降低扬压力、控制运行水位和工程措施建议，这3个活动是并行的，就是说它们的执行顺序是不受限制的，交叉进行、同时进行都可以。在模型中保留这种并行行为的描述，对于在实现阶段充分发现那些可以并行的工作非常有利，这将有助于提高工作效率和系统反映的灵敏程度。
文章来源于领测软件测试网 https://www.ltesting.net/
