系统分析要求接触用户,同时系统还要能够控制不同的用户角色和权限。通过对用户进行分类并了解他们的需求,从而确定安全机制、功能限制方案、用户界面分组和对具体内容的需求。图1 显示了几组不同的系统用户(在UML 中称为Actor , 即参与者) 。普通的用户类型(“普通用户”) 位于图的顶端,空心箭头表示generalization(泛化) 关系,表示“User”又可以具体分成两类用户: 注册用户,未注册用户。而注册用户和未注册用户各自私有的特征则在对应的参与者中说明。在本例中,注册用户又可以细分为外国专家、管理员、行管人员三种类型,系统对这些用户的处理方式应有所不同。
2.2 需求模型
需求建模的过程就是用例的获取过程。用例的获取是需求分析阶段的主要任务之一，而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生，并且随着工作的深入会发现更多的用例，这些都应及时增添到已有的用例集中。用例集中的每个用例都是一个潜在的需求。
对系统需求的建模是通过 UML的用例（USE CASE）图实现的。用例模型描述的是外部执行者（Actor）所理解的系统功能。首先，它描述了待开发系统的功能需求；其次，它将系统看作黑盒，从外部执行者的角度来理解系统；第三，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML 的各个模型。
图 2 为外国专家管理信息系统用例模型。图中的椭圆是用例，表示用户与计算机之间的一次典型交互作用，图形化表示的小人是执行者，表示用户在系统中所扮演的角色，用例和执行者之间的连线表示两者之间的关联。 系统所涉及各种模块的差异较大 ,要描述系统的功能需求,只有将系统划分为多个模块分别描述其功能需求,这就需要多个用例视图。 图中列出了8个用例，对应系统来华申请、在华管理、离华管理、文件管理、统计报表、外专聘请需求的管理、外专聘请单位信息的管理、用户管理。图中还列出了3 个执行者，分别表示外国专家、行管人员、高级用户（系统管理员）。通过用例图，使得设计者在系统设计的最初阶段将主要精力集中在系统的功能上，而不是系统的具体实现上。对于比较复杂的系统，可以增加活动图显示活动流程和并发行为，使得建立的需求模型更加完整。
2.3 系统功能分析与设计
为了让系统设计能够以结构、组织方式和代码重用的形式表现出来,要对系统进行设计规划,设计阶段应该与分析阶段交迭。需求是不断地发展,而设计本身也会推动需求的发展(反之亦然) 。
外国专家管理信息系统功能的建模设计中 ,以下3个方面的问题是要关注的:业务对象的表示、业务服务的实现、用户界面的组织。
文章来源于领测软件测试网 https://www.ltesting.net/
