用例建模（精选4篇）
用例建模 篇1
1、引言
软件系统开发都要经历需求分析、软件设计、编码、测试4个阶段, 需求分析是软件开发期的第一个阶段, 也是最重要的一步。通过需求分析, 我们可以确定计算机应用系统必须为其用户所做的事, 及系统必须提供的具体功能、特性、质量, 并且来体现系统存在价值。
有效的需求是产生满足用户需求软件的决定因素, 但是现实需求开发工作中却存在很多难点: (1) 软件客户与开发人员存在背景知识差异, 双方之间缺乏有效沟通方法, 交流上存在障碍, 客户与开发人员双方都从自己的角度、使用自己的语言表达方式来描述和理解问题, 使得双方并不能够很好地就软件需求达成共识; (2) 需求信息描述的不一致、不规范; (3) 在软件开发的过程中, 需求会不断变化及演进, 软件客户会提出更多的新需求。
用例作为软件需求分析的工具之一, 在软件工程领域的需求阶段得到相当广泛的应用, 可以帮助我们解决这些难题。
2、用例及其相关概念
1.1 用例和用例模型
用例 (Use Case) 是一种描述系统需求的方法, 使用用例的方法来描述系统需求的过程就是用例建模。一般说来, 用例是参与者 (这里不仅仅是人) 与系统的交互。用例代表了系统为其参与者所执行的有价值的操作, 用于表达系统的功能需求和行为, 获取的是功能需求。用例可以捕获在引发系统某些行为时用户所做的操作, 同时还可以捕获系统在提供所需行为时所做的操作。它清晰的定义了系统在满足用户目的方面具有责任, 以及用户是如何支持系统的。
基于用例的软件需求建模是以用例为主导线索捕获和描述软件需求的过程, 它提供了收集需求的框架和表达需求的方法。用例模型是从用户的角度出发描述系统功能的一组视图, 它是需求的工作结果, 主要由以下元素构成:
用例名称:所有用例的名称应该表明它与参与者的交互结果, 为了便于理解, 可以使用多个单词, 并且是唯一的。
简要描述:对用例的角色、目的的简要描述。
事件流:从用例的角度对系统的行为进行文本描述。
前置条件:定义用例启动的系统约束, 以文本形式描述。
后置条件:定义用例终止后的系统约束, 以文本形式描述。
扩展点:用例事件流中的一个位置列表, 这些位置上可以插入附加行为。
关系:用例参与的一些关系, 比如通信关系。
示意图:演示用例的各个方面, 比如事件流的结构或用例涉及到的关系。
特殊需求:集用例中不在事件流内考虑的需求, 但在设计和实现过程中都要考虑的, 例如非功能性需求。
用例模型的这些构件, 既有图形表示, 又包含文字陈述, 因此可以更直观的表现用户的需求。在用例中最重要的属性就是事件流, 它描述了系统和参与者如何协作来传递用例体现的需求价值。
1.2 软件需求建模概念及建模过程
软件需求建模是指用清晰、简明的方式将需求分析获得的信息记录下来的过程, 建模的结果通常是一个逻辑模型。需求建模的方法不同, 所获得的逻辑模型亦不同。基于用例的软件需求建模的结果一般包括一组用例模型及其相关描述等。
一般说来, 对软件需求建模的过程要经历三个阶段:需求获取, 需求分析, 需求描述。
(1) 需求的获取阶段主要工作是由领域专家、需求分析师、用户等各方面人员对企业的业务过程进行标准化与规范化的定义, 去粗取精, 创建功能需求的集合, 描述系统的行为, 形成概要的需求说明。
(2) 需求分析的主要任务是确定系统边界, 领导协调需求, 抽取用例, 定义什么是系统该做的, 什么是不该做的, 同时确定非功能需求, 设计用户界面, 从而对需求调研结果达成一致。
(3) 当获得详细的需求分析结果之后, 必须把这些信息记录下来, 并使用相关符号来表达它们, 这个过程称为需求描述。使用符号和文字的描述, 可以创建许多不同类型的模型, 以用例为基础的需求建模创建的是一个用例模型, 它指明了系统的主要功能。
需求建模的持续过程可能会依据特定的开发过程不同而异, 在迭代开发过程中, 需要不断地迭代, 在瀑布开发过程中, 则会持续一个较长、较完整的阶段。
2、实例分析
本文将以一个网上招聘系统的管理端子系统为例, 描述软件需求建模的全部过程。
2.1 功能需求
该系统管理端子系统主要是提供公司内部人力资源管理人员使用的功能部分, 它的功能分为知识库、试卷管理、职位发布、简历整理、面试管理等部分, 每个登录者首先经过认真安全认证然后缺陷权限, 根据相应的权限现实相应的功能。
2.2 系统需求建模
(1) 确定执行者:为了确定执行者, 开发人员要考虑谁或什么使用系统, 它们与系统的交互中扮演什么角色。本例中的执行者有:试题管理者、面试管理者、职位发布者、系统管理员。
(2) 模型建立:一个用例表达建模系统的一项外部功能需求。用例的获取一般从执行者列表开始, 考虑每个执行者如何使用系统, 要求系统提供哪些功能等, 把获得的这些答案表示为用例。本例中的用例有:登录管理、知识库管理、试题管理、职位管理、简历管理、面试管理、用户管理。图1展示的是系统的总体用例图。
显然, 总体用例图在需求表达方面还不够详细, 需要对它进一步细化, 为每个用例分别建模直到被用户完全接受为止, 这个细化过程必须经过系统分析员和领域专家的反复论证才能成功。下面以"简历管理"为例, 对它进行细化, 用例图如图2所示, 下文是经过细化后生成的用例规约。
用例描述:简历管理
执行者:面试管理者
前置条件:面试管理者已登录系统;
后置条件:简历整理完成后, 则可以将应聘者分为几个类别, 以便为面试做好准备。
基本路径:
a) 进入简历管理界面, 首先展示目前的简历对应的职位列表, 提供查询功能;
b) 通过点击职位列表进入相应的这个职位的所有简历列表的界面;这个界面也显示了每个应聘者的名字、年龄、性别、问卷的分数以及目前的处理状态等信息;
c) 简历列表中, 通过点击一个应聘者可以显示这个应聘者的简历信息, 这个应聘者的问卷回答情况, 可以打印简历;
d) 对简历有三种处理结果:通知面试、保留简历、拒绝;
e) 对简历的处理结果, 可以采用电子邮件、电话和信件等方式通知应聘者, 如果采用电子邮件通知应聘者, 系统提供一个模板。
3、结束语
软件需求是软件设计及实现的基础, 对于整个软件项目来说至关重要。而软件需求的不确定性又是客观存在的事实, 每年由此导致开发失败的项目也是数不胜数。使用用例进行软件需求建模, 可以有效控制需求规模和需求变更, 从而降低风险和成本, 保证客户与开发者对不断变更的软件需求的一致性。
参考文献
[1].朱卫平, 谭汉松.用例技术应用探讨[J].湘南学院学报, 2005, 26 (2) :66～70.
[2].Kurt Bittner, Ian Spence.用例建模[M].姜昊, 许青松译.北京:清华大学出版社, 2003。
[3].Steve Adolph, Paul Bramble.有效用例模式[M].ePress.cn车立红译.北京:清华大学出版社, 2003.
[4].王枫, 石冰心, 罗莉敏.UML建模机制研究及在系统需求分析中的应用[J].计算机工程与设计, 2005, 26 (4) :971-975.
从用例到控例的非功能性需求建模 篇2
关键词：用例驱动,非功能性需求,扩展视图模型,控例视图
0 引言
一般而言,功能性需求主要用于识别系统的目的,而非功能性需求关注系统行为中参数的设定,其中包括系统性能,可信性,安全性,响应时间,服务质量以及系统可用性等。非功能性需求也常被称为技术要求,系统性能或质量服务。一般开发过程中性能需求往往都是被忽略的,直到开发周期结束比如集成测试的时候才会考虑。
网络飞速发展所带来的进化使得开发中非功能性需求的要求更为苛刻,迫使在整个系统开发过程中需要综合考虑非功能性方面的需求。文中通过用控例去建模和记录非功能性需求,并将这些控例通过一些条件来与用例相关联起来。控例技术主要运用于一些关键性的要求,有利于管理整个开发生命周期。并可以通过扩展UML体系机构和视图模型去描述增加了控例视图后的软件体系结构。
1 背景及相关性工作
用例自提出后,现已应用于软件开发的各个方面,常用于系统功能性需求建模[1],包含对象和组件模型的创建、领域模型分析、测试用例的生成等。虽然功能性需求解决方案已受到学术上越来越多的关注,但非功能性需求方面却鲜有关注,更没有相对明确的标准或开发工具。非功能性需求本质上是非行为性的,单纯的用例模型是不适合直观地解决这些需求特征的,原因在于用例的目的是定义一个分类(包括一个子系统或者整个系统)的一块行为,但却不揭示分类的内部结构,这就非常不适合非功能性需求的分析了。
1.1 非功能性需求的可操作性
非功能性需求可从以下两个角度定义。第一个是操作性的角度,被定义为服务层次需求,有:性能,响应时间,可用性,完整性,安全性,可扩展性和可恢复性等。另一个就是非操作性的角度,诸如:体系结构,技术标准,可移植性和可维护性等。但这些非功能性需求并不能很明显地与明确的用例相关联起来,相反,它们是整个软件系统开发的特点所在。
一般来说,所有的非功能性需求都被视为是系统范围内的性能需求。意味着这些需求是在记录功能性需求的分离式任务中被定义的,但这种分离式分析方法却饱受争议。原因在于这样的方法忽略了一个可以获取确定的非功能性需求的重要机会,就在它可能与一个功能性需求非常相关的时候。
本文提出了一种控例用例[2]的概念,用于定义系统,子系统或组件的特定质量要求。控例用于获取服务性能的需求或者操作的非功能性需求,这样系统才能满足需求。对于非操作性的非功能性需求而言,控例将通过策略,流程或程序来记录约束或可能的控制方法,以确保符合相应的非功能性需求。
1.2 用例相关工作
非功能性需求包含在用例里面,这使得它们难以被识别。但原型工具中,非功能性需求是可以被描述出来的,在工作中也可以被定义为软目标。需要注意的是一系列非功能性需求的管理。
目标导向需求语言(GRL)是一个需求建模语言,尤其在非功能性需求方面。该方法基于用例图,关注重点是目标,而不是以非功能性需求方案为基础的规范。文献[3]提出一种面向方面[4,5]的建模非功能性需求的方法[6],目的是对非功能性需求的定义进行软件体系结构的验证。
相关工作主要集中在扩展用例,形式语言,或目标导向的方法来定义非功能性需求。本文中,用另一种方法来完成用例,并展示与已概述的运行条件之间的关联。控例是一个基于方案的非功能需求规范,这样的技术将有助于在非功能性需求关联的功能性需求分析过程中捕捉非功能性需求,确保系统和系统建模的可信性[7,8]。
2 需求建模
控例的基本原则概述说明是如何定义非功能性需求收集的一部分,目标是定义和概述如何在实践中使用控制用例,并提供规定的流程来识别非功能性需求存在的几种方法,包括以过程为导向的框架。功能性需求模型可能由用例模型,接口描述和问题领域模型所构成,而非功能性需求模型可以用一个控制用例来表示,并捕获控制用例所定义的操作条件。表1为更加详细的定义。
用例建模一开始需要找出所有参与者以及用例之间的相互概念关系。反之,控例建模则一开始需要确定可能的操作条件和系统相关的风险,主要是系统的所有者和用户。控制用例的概念可以在非功能性需求的每一个操作范畴中发现,比如性能,操作可用性,完整性,可扩展性,安全性和可恢复性。
根本上说,一个控例代表一系列的系统性能要求。系统要能够控制管理这些暴露给用户的威胁,这些风险威胁可能来源于不同操作条件下的低质量服务。比如,可能面临的风险有:
①用户操作时系统运行性能不佳或响应时间较久。
②系统不能提供足够的可用性服务。
③如果系统安全性设计很差,将会受到攻击。
表1说明了控例的概念模版,表2是完整的控例概念的一个例子。
控制用例的发展是一个需要迭代和增量的过程,初始的控例概念可以进一步阐述为创建详细的控制用例。控制用例的目的是降低系统中的风险到用户可以接受的水平,甚至解决这样的风险。实践中,控制用例概念的阐述在很大程度上还是一个遵循风险评估的过程。风险评估的目的是确定威胁的可能性、对系统的影响以及额外的服务性能需求,而非功能性需求需要对系统进行定义,以减轻识别的风险。在控例的情况下,控制相当于实现服务性能需求的方法。服务性能需求是什么以及如何控制的。最初,控制用例应该专注于需要实现的部分,控制(如何实现服务性能需求)可以在设计阶段解决。
控例给系统用户提供一个风险威胁的概述。为了减轻风险,服务性能需求需要被解决。控例可以作为服务性能需求定义的基础,其次,也可以用于规划项目活动、资源、成本和周期等。此外,它可以应用于建模技术设计和管理后期阶段控制的具体实施。
一个完整的控例构造方法应该是在软件性能工程过程之后定义的。这种方法中,最初始步骤是性能风险的评估,其次是关键用例的识别。控例情况下,首先是定义高层次的控例,然后将识别的关键用例(即控例)进一步细化。
3 语义含义和符号
从模型的角度来看,UML目前并不代表服务质量的概念。因此,非功能性需求可能无法有效地使用UML建模。另一种可行的方法是使用UML的约束概念来代表非功能性需求。UML约束是一种语义条件或限制。一个UML约束可以用任何语言来表达,甚至是自然语言。UML提供了一个正式的语言,这就是对象约束语言(OCL)。OCL中,约束是对一个或多个值的限制,是一种面向对象的模型或系统。这定义意味着一个约束被施加到一个对象的状态或行为后,仍然是受到系统架构功能性方面限制的。另一方面,由于自然语言的模糊性,如果用来表达约束可能会导致误解。
一些方法已经认识到UML元模型[9]的局限性,一个精炼的元模型应该包括非功能性需求和其他操作模型元素。非功能性需求概念可以链接到一个指定的质量要求或约束的模型元素。从架构的角度来看,通过控例模型可以有效地实现非功能性需求的建模。
3.1 符号
这里着重介绍控例的概念,并只突出元模型的影响。控例建模之前有两个新的概念需要介绍,首先是操作条件,二是实际控制用例。每个概念都是一种UML的术语[10]或是在体系结构规范中定义的类型。操作条件表示系统、子系统或组件的特定环境状态。可能是负载条件,带宽条件,或物理条件等。控制用例定义了其系统、子系统或组件需要在特定的操作条件下满足适应业务风险的质量要求。图1所示为一个控例控制下的操作条件的符号。
为了在用例中识别和关联控例,需求分析者仔细了解每个用例中是否有操作条件的存在。传统上,一旦功能性需求被提取出来后,注意点就要转移到非功能性需求的捕获上去。如果它们被主动地处理掉了,那么在功能性需求收集过程中控例的识别将会是一种更加自然的方法去提取。由于是直接关联,并且能有助于描述一个特别的非功能性需求的意义(通过其关联的一个关键用例)。因此,控制用例方法通过与特定用例紧密关联,更加符合一个需求收集的自然进化过程。图2说明一个与确定用例关联的控制用例的符号。
3.2“4+1”视图和控例(扩展视图模型)
UML“4+1”模型进程视图清晰地为非功能性需求规定了范围,但是目前的用例建模并不能直接支持。由于控制用例[11]提供了必要的范围,因此可以用UML符号去为控例提供相应的服务。这样就可延伸至用传统的UML“4+1”模型视图加上控例视图来得到一个更加完整的系统结构图。
UML“4+1”视图中,进程视图旨在解决性能、可扩展性和吞吐量。然而,实践中很难使用UML来建模系统结构的质量方面的需求。由于UML元模型只支持行为和结构的概念,这可能就会出现一个风险,非功能性需求被忽视,或非功能性需求的实现是有缺陷或不足的,由于体系结构模型没有一个能明确代表非功能性方面需求的。因此,控例视图可用于增加UML“4+1”视图。和用例视图一起使用时,控例视图突出每一个视图中都需要考虑的功能和非功能性需求,提出了一个完整的架构图。图3是体系结构在添加控例视图后的扩展视图。
从扩展视图可以看到,控例视图捕获不同操作条件下的非功能性需求。因此,当准备设计、实施、部署视图时,这意味着准备用用例视图表示功能性需求,控例视图代表非功能性需求。为了判断系统体系结构模型是否有必要引入控例视图,可以参考以下六个质量标准:完整性、内在性、清晰性、一致性、正交性、一般性。
控例的情况下,通过捕获结构的非功能性需求有助于系统整体架构的完整性。清晰性的概念和相关的规则是很容易理解的,因而可以应用于体系结构模型中。控例的概念提供了一致性,因为它提供了无歧义,同时也不与现有的观念相冲突,如UML。从用例视图的行为性质来看,视图通过分离非行为的要求提供了正交性。最后,这将通过通用性测试,因为它解决的非功能性问题存在于一般的应用程序领域。
因此,从一个系统架构建模的角度来看,引入用例视图来扩展UML“4+1”视图模型,并最终得到一个更加完整和实用的系统结构模型是可行的。
4 结束语
控例视图与当今复杂而又不断变化着的软件环境是息息相关的。由于现在的软件系统大多数还是注重于功能需求的设计与实现,并未太多考虑非功能性需求的影响,这是最危险的,一旦软件系统开发完成后再来考虑的话将会给系统带来额外的负载,并极有可能导致系统的最终崩溃。本文提出从用例到控例的概念以及对非功能性需求的视图建模,但是这些方法仅仅局限于系统架构模型的设计,并未应用到实际的软件设计开发中,也缺少更加实际的控例开发方法。接下来的研究方向将会转移到这方面来,并将控例技术应用到实际的系统应用中去。
参考文献
[1]王达.需求工程的探讨[J].软件,2011,32(5):67-70.
[2]刘春,张伟,赵海燕,等.一种“用例+控例”驱动的软件分析与设计方法[J].软件学报,2013,24(4):675-695.
[3]Xu L,Ziv H,Richardson D,et al.Towards Modeling Non-Functional Requirements in Software Architecture[M].Proceedings of Early Aspects 2005:Aspect-Oriented Requirements Engineering and Architecture Design Workshop,Chicago,Illinois,USA,Mar.2005.
[4]刘敬勇,钟勇,张立臣.软件非功能需求的面向方面建模[J].计算机应用与软件,2010,27(12):40-41,85.
[5]邓惠敏,张立臣,邓建波.基于面向方面和UML的实时系统建模研究[J].计算机技术与发展,2010,20(12):118-121.
[6]汤根生,王姚.面向方面状态模型的UML扩展实现[J].计算机技术与发展,2011,21(1):116-119.
[7]王越,刘春,张伟,等.知识引导的软件可信性需求的提取[J].计算机学报,2011,34(11):2165-2175.
[8]汪京培,孙斌,钮心忻,等.基于可信建模过程的信任模型评估算法[J].清华大学学报:自然科学版,2013,53(12):1699-1707.
[9]郑丽伟.NFROnto:一种软件非功能需求本体元模型[J].北京信息科技大学学报:自然科学版,2012,27(6):78-83.
[10]Saleh K,Al-Zarouni A.Capturing Non-Functional Software Requirements Using the User Requirements Notation[C].The 2004International Research Conference on Innovations in Information Technology(IIT2004),Dubai UAE,October 2004.
用例建模 篇3
UML(unified modeling language,统一建模语言)是一个通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统制品的文档。使用UML建立模型的重要内容就是利用用例图、静态图、行为图、交互图、实现图来定义模型。建立用例图(Use Case Diagram)则是开发软件工程的第一步，以后的各项工作都是围绕着如何实现这个Use Case模型展开。
需求分析是软件工程开发中最为关键的一个过程，需求分析的质量决定着用户的满意程度、产品质量高低、系统开发的工期、功能的完整程度等。对系统需求进行建模时,要将需求分析首先转化为用例，即用用例图清楚、准确地表达系统功能需求，使系统投资者、项目开发人员和系统用户达成一致的理解，并且用来指导项目开发人员的后续工作，以后的各项工作都以Use Case图为中心去开展。可以说，用例图驱动着其他模型的开发，是整个系统需求的核心。
所以，通过使用UML的Use Case用例模型从系统的功能结构和行为出发对将要开展的系统进行建模，能够更好的了解到用户需求，帮助系统开发人员了解到“谁来做”、“做什么”，同时也能够避免因需求分析不清而导致的一系列问题，更彻底的了解用户对整个系统需求。
2 电子公文与电子公文归档移交系统
电子公文归档系统所作用的对象是电子公文，电子公文是公共机构产生的、专用于处理公务活动、具有法律效力和规范格式的文本型电子文件。电子公文归档移交工作的流程是从电子公文的收集和积累开始，再对电子公文进行整理编目，交付档案室进行归档，然后整理、登记、分类，之后存入档案室库房。档案室保管以归档的电子档案，并对本机构提供利用服务。档案室中的档案在本单位保存一定期限后，定期向档案馆移交有价值的档案。根据电子公文的归档管理流程，可以看出，电子公文归档系统是一个能够支持电子文件归档业务流全过程的自动化信息系统，它将办公自动化系统和档案馆的管理信息系统连成一体，是介于办公自动化系统与数字档案馆系统之间的自动化中间系统。
电子公文归档移交系统的核心功能是实现电子公文的顺利归档和移交。归档是与办公自动化系统的公文交换，而移交则是与数字档案馆系统的公文交换，电子公文从办公自动化系统中接收过来，经过电子公文归档移交系统的整理、验收，在完成待定期限的保管后实施相应的处置措施，并将具有永久保存价值的电子公文向数字档案馆移交。
3 使用用例图描述需求
建立用例模型(Usecase diagram)首先需要进行角色(Actors)确定，Actors代表一个系统的使用者或外部通信的目标。用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。用例模型的用途是列出系统中的用例和参与者，并显示哪个是用例的执行。
3.1 确定参与者
参与者是系统的主体，表示提供或接收系统信息的人或系统，他们是与系统有交互作用的人或事物，通常代表了一个系统的使用者或外部通信目标。本系统的参与者有公文归档移交系统、文件负责人、档案室、档案馆。
公文归档移交系统，是生成、存储、传递文件的信息系统，也是为参与者提供辅助技术支持的辅助系统，由于它帮助参与了归档移交业务，其本身就可以看成归档移交业务的一个参与者。
文件负责人是在电子文公归档前，完成公文的收集、分类、整理、统计、数据修改维护的操作。在电子公文归档之后文件形成机构还能对电子公文进行查询、检索及目录与数据信息打印。
档案室完成在线接收各部门的电子文件(含文本文件、图像文件和多媒体文件等)和电子档案的业务。并与机关各部门实现网上信息交互传递，实现各部门电子档案的规范管理，定期将电子档案导入数字档案馆管理系统，通过数字档案馆政务网站和互联网站为各级党政机关和人民群众提供及时的档案信息服务。
档案馆通过政务网，完成对档案中心目录与原文数据的接收业务。远程对机关档案工作进行业务指导，帮助机关档案工作人员解决工作中的具体问题，做到业务监督指导的“零距离”、“零延误”。
3.2 使用用例图描述需求
3.2.1 公文分类业务用例图
电子环境中，系统首先判断公文的类别，给公文以分类标记。此分类标记由系统提供选择，可以与公文的登记号合一，也可不同。当不存在公文的类别时，需要创建公文集合，再将公文归类到相应的公文集合类别中。档案室的工作人员对文件集合的创建与文件归类情况通过电子公文归档系统进行核查。(图1所示)
1)公文分类标记用例的需求说明：
在系统下拉菜单中选择文件类别，选定后系统赋予文件以分类标记。
这个过程中要需要的需求有：(1)系统能支持类目两种以上的命名方法，并保证可以同时在某一特定层级上使用。命名方法包括依据分类方案中的分类名进行命名和依据分类方案中的分类编号进行命名;(2)保证分类标记在同一类目下的唯一性，允许在不同文件集合下文件分类标记有重复;(3)自动赋予该公文的上位类标记信息。
2)创建文件集合用例的需求说明：
(1)系统提供分类方案的查询，机关公文负责人选定分类方案。
(2)系统将分类方案予以集成，建立文件集合，自动生成集合创建时间，授权用户自定义文件集合名称。
(3)当分类方案的设计和配置需要修改时，修改文件集合，并可将集合内公文重新分类。
(4)在创建文件集合过程中，禁止用户在已存在的文件集合中创建子类，避免文件集合与文件在同一层级出现。
(5)创建同时给文件集合自动编号，自动生成创建时间。
(6)创建新文件集合的同时在新的文件集合中标识其上位类的信息。
3)公文归类用例的需求说明：
(1)找到相应的文件集合，此文件集合必须是集合中的最低一级。
(2)向文件集合中添加电子公文，再确定完成电子公文添加之后，用户可以锁定文件集合使之状态变为可读。
(3)若发现有遗漏或需修改，则重新开放已锁定的文件集合。
(4)在文件集合发生变化时，允许文件集合下的公文重新归类。
(5)当电子公文归类需要修改时，允许公文重新归类。
(6)将此过程中的元数据进行著录，如果元数据有继承的，要与其上位类元数据进行动态链接。
3.2.2 鉴定业务用例图
如图2，机关公文负责人将要归档的公文数据提交到公文归档系统中，系统根据预定规则进行初步鉴定，识别此数据单元是否是公文。系统根据预定规则自动判断某文件是否具有保存必要，根据文件的信息类别，即其记录、支持的业务职能，参照《电子文件保存期限表》，自动判断文件的保存期限。档案馆工作人员对文件的真实性、完整性、可读性进行鉴别。
1)确定电子公文保管期限用例需求说明：
(1)系统根据公文元数据信息，参照《电子文件保存期限表》作出相应的运算。
(2)若以月为单位，系统以1-11个月进行计算;若以年份为单位，系统以1-100年进行计算;若为年份和月份的结合单位，则结合以上两种假设进行计算。计算后系统得出公文保管期限。
(3)若系统得出保管期限与《电子文件保存期限表》或人工判断不符合，则进行人工修改。
2)公文处置用例的需求说明，公文处置包含了三种措施分别是复审、迁移、销毁。
(1)复审是对初次鉴定的一次过滤，决定了电子公文未来的命运。复审结果分为三种一种是具有电子公文永久保存价值待移交档案馆;一种是继续保存在电子文件保管系统中有待本机构利用;还有一种是将电子公文销毁。复审带来一系列变化应记录在系统日志中。
(2)若电子公文需要销毁，在可擦写介质上保存的公文，其类目、案卷、公文的数据从介质上被完全删除，且不可恢复。在一次性介质上的公文，系统销毁与此介质的所有链接，使此介质无法链接到本系统或操作系统。系统最后保存一部分已销毁的元数据信息。
3.2.3 归档业务用例图
当登记的对象为公文时，系统根据编号规则，对公文进行登记赋予公文的唯一标识，系统同时记录文件的名称、形成部门、创建时间等信息。当登记的对象为公文集合时，由档案人员在系统中创建有关类目。系统根据文件鉴定结果，赋予文件以档案身份，形成电子档案的档号。进入电子公文归档系统的电子档案，进行按照移交档案的标准进行再次分类，电子公文归档系统将公文的在其生命周期内的所有信息包括背景信息、内容信息以及文件系统信息的元数据。并对电子档案进行维护。对于归档后的电子档案及其目录信息，机关负责人可以即使查询。
1)登记公文用例的需求说明：
(1)如果电子公文有多个版本，用户可选择将所有版本登记为一份公文，或仅登记其中一份版本，或将每一个版本登记为一个独立文件。
(2)选定，浏览公文登记表。
(3)系统根据电子公文的元数据，进行一些项目的自动登记。
(4)根据电子公文的元数据，系统向用户提供一些与项目所对应的公文元数据的可视化选择，同时也可人工录入登记项目。
(5)登记完成后，提交给系统。
(7)系统将登记的时间和日期作为元数据进行保存。
2)归档用例的需求说明：
(1)将公文划归为一个或多个案卷。
(2)系统根据公文的元数据列出相关类目和案卷目录。
(3)当同一份公文在同一个案卷中进行的登记时，系统给予提醒和阻止。
(4)接收公文，确定接收公文的所有内容，包括定义文件类型、文件格式、文件结构的相关信息，对公文的完整性、真实性、可读性是否具备加以提示。
(5)接收公文的相关元数据，并保证与电子公文的关联性。
(6)选择归档方式，即时归档或定期归档，选择即时归档则将选中公文状态即时变更为“已归档”，若选择定期归档则等到期时系统向用户发出通知提醒，再对公文状态进行更改。另外还可以选择网络归档和介质归档，选择介质归档，系统直接链接输出设备，将公文脱机保存于介质上。
(7)给公文赋予档号，成为电子公文的唯一标识。
(8)归档后系统将公文生成一份以系统默认格式存在的原电子公文文件转换本。
3.2.4 移交业务用例图
按照国家法律规定，将有社会文化价值的电子文件移交给档案馆。现阶段移交的情况有两种：一是信息系统根据文件的保存期限自动判断文件是否应该移交，并对应移交的文件通过安全网络传送到指导位置;二是档案人员根据系统的判断结果，将移交文件脱机保存在一定的介质上，将介质移交至档案馆。
公文移交资格判断用例的需求说明。在系统的决策支持下人工判断待移交的电子公文是否符合移交条件，移交条件主要有以下几点：
(1)电子档案是否是最后核定的定稿;
(2)电子档案是否具有永久保存价值;
(3)电子档案的真实性、完整性、有效性和可读性;
(4)电子档案包括的公文原件、相关元数据、归档时的日志文件、内容留痕和留真信息以及电子公文在本系统中的管理和使用日志。
(5)移交电子公文格式是否符合规定格式要求，专用软件产生的格式需要转换，无法转换的随文件一同进馆。
(6)电子公文与元数据关联完好，元数据格式符合要求。
3.2.5 电子公文系统用例图
在电子环境的公文归档移交业务与传统公文管理的区别就是著录需要贯穿于文件的整个生命周期之中，它需要记录文件形成、管理、利用的全过程。这样著录业务在内容和时间上都与传统公文管理活动有所区别。为了保证著录信息的准确性，在电子环境下著录被提前到了公文形成之前，由电子公文著录管理系统来完成对电子公文在整个生命周期活动的著录。在公文的不同阶段，所捕获的元数据不同，元数据在系统中不断被积累。跟踪是电子公文系统根据事先的定义自动记录电子文件生成、处理和保管过程。统计是根据预先定义自动生成有关的临时性报表。公文每个不同的阶段都在发生改变，在电子环境下文件系统也处于不稳定的状态，应对公文进行实时备份。权限控制用于控制各类用户的访问权限。
4 使用活动图描述关键用例
在需求分析中，需要用活动图对复杂用例加以描述。活动图实质上也是一种流程图，表现的是一个活动到另一个活动的控制流。其基本图形元素有动作状态、动作流、泳道、对象等。
4.1 电子公文归档用例
如图6归档公文验收与公文整理过程之间是靠“归档申请单”和“验收通知书”进行联系的。档案室首先接到来自机关公文责任人提交的“归档申请单”，根据申请单中所列目录调阅对应的公文进行检查验收，验收完成后，赋予公文以档案身份。这个活动在系统中表现的结果为系统将公文的状态变为已归档，自动生成电子档案帐目，显示档案存放的逻辑地址。同时，系统向机关公文负责人发送验收通过通知。如果验收没有通过，系统则向机关公文负责人发送返回修改通知，机关公文负责人可根据情况选择重新申请或者退出归档。归档结束后公文传送到机关档案室，等待登记、整理、入库。系统在此活动中著录元数据。
4.2 电子公文移交用例
如图7，电子公文的移交用例由档案室和档案馆负责，其最终结果是将电子公文、公文目录、元数据及其关联信息由电子公文归档移交系统进入数字档案馆系统中。根据实际移交工作流程，可以看出系统至少要满足两种移交方式的需求。一是在线移交，档案室向档案馆提交移交档案目录，档案馆调阅文样进行验收，符合移交条件的由档案馆负责选择公文存放的逻辑地址，通过安全网络进行在线移交，判断公文、目录信息元数据及其关联信息在移交过程是否受到破坏，数据完好则著录此过程产生的元数据，然后将公文、目录信息、关联信息及元数据一并进入数字档案馆管理系统中。二是脱机介质移交，移交公文符合移交条件，验收合格之后，档案室根据移交档案目录中的相关公文数据导出，一部分纸质档案通过打印输出，还有一部分文本文件、图像文件和多媒体文件等数据脱机保存于一定介质中，一并移交到档案馆。
5 结束语
电子公文归档移交系统是建立在电子政务网和数字档案馆基础之上的“虚拟”文件中心，为保证各部门形成的电子公文、电子档案其信息的齐全、安全、有效和长期可读，加强进馆档案的监控与移交，保证进馆档案质量提供了有效的保障。但是电子公文归档移交活动具有复杂性，系统参与的对象众多，对电子公文归档移交建设前的系统需求获取比较困难。运用面向对象的建模技术，特别引入对用例图建模的技术，可以有效的解决这个困难。通过对电子公文归档移交系统用例的建模与对用例的分析，软件开发者可以准确的了解用户需求与系统功能，档案工作人员也可对系统功能有更直观的印象，从而参与软件开发的专业指导之中。
当然，需求分析阶段是一个迭代的过程，需要不断的调查、分析和总结，只有不断的实践才可使获取的系统需求更加完善合理。
摘要：电子公文的归档工作是档案管理工作和电子政务建设的重要内容之一,电子公文归档系统作为一个连接办公自动化系统和数字档案管理系统的桥梁,在文档一体化管理体系中占据着重要位置。建设电子公文归档系统首先要从需求分析做起,确定系统“做什么”的问题。将UML(统一建模语言)的用例模型应用到电子公文归档系统的需求分析中可以更有效的获取系统需求,并清晰描绘出系统需求。
关键词：电子公文归档系统,用例图,活动图,需求分析
参考文献
[1]Jacobson I.Object-Oriented Software Engineering:A UseCase Driv-en Approach[M].NewYork:Addison-WesleyPublishing Company,1992:16.
[2]薛四新.档案信息化应用系统建设[M].北京:机械工业出版社,2006:110-120.
[3]国刚,周峰,孙更新.UML与Rational Rose2003软件工程统一建模原理与实践教程[M].北京:电子工业版社,2007:96-111.
[4]吴建,郑潮,汪杰.UML基础与Rose建模案例[M].北京:人民邮电出版社,2007:56-65.
[5]谢海新.电子公文归档移交系统功能研究[D].天津:天津师范大学,2006.
[6]刘丽,夏友斌.Use Case建模在数字图书馆系统中的应用[J].图书与情报.2002(2):58-61.
[7]沈晓近.基于UML建模的图书馆信息管理系统的分析与设计[J].现代计算机,2007(26):108-110.
[8]刘越男.建立新秩序——电子文件管理流程研究[M].北京:中国人民大学出版社,2005:185-273.
用例建模 篇4
模型是对现实存在的实体的抽象和简化, 模型提供了系统的蓝图, 可以通过过滤非本质的细节信息, 抽象出问题的本质, 使问题更容易理解。建模是用某种工具对同类或其他工具进行更易于理解的表达。
UML (Unified Modeling Language) , 称为统一建模语言或标准建模语言, 它是基于面向对象的, 着眼于那些有重大影响的问题, 创建一种人和计算机都适用的语言。是一种支持模型化和软件系统开发的图形化语言, 为软件开发的所有阶段提供模型化和可视化支持, 可将用户的业务需求映射为代码, 保证代码满足这些需求, 并能方便地追溯需求的过程, 它可以描述软件开发从需求分析直至实现和测试的全过程。
在UML中, 模型是通过视图来描述系统的不同侧面, 通过图来描述待建立系统的模块。UML由四种视图组成, 分别是用例视图、逻辑视图、组件视图和布署视图。其中, 用例视图是其他视图的“心脏”, 描述了系统应该做什么, 在集成其他三种视图的内容中扮演了重要角色。
本文主要阐述网上报名系统用例模型的建模方法。
2 系统功能分析
大多数的高职院校都已开展学生职业资格认证工作, 目前的流程均是采用手工建立Excel报名表报名, 手工排版打印准考证、安排考场等, 为提高工作效率, 方便教师管理及学生操作, 特开发网上报名系统, 功能如下:
(1) 网上报名功能
对于登录报名网站的考生, 通过网上报名系统的考生界面, 可以浏览考试相关信息;
通过浏览器进行网上报名 (填报信息、上传照片) ;
在指定时间范围内修改报名信息或取消报名;
可以在指定的时间内打印准考证;
在成绩公布后查询考试成绩。
(2) 系统管理功能
对于登录报名网站的系统管理员, 通过网上报名系统的管理员界面可以对网站进行维护 (信息的更新, 数据的维护等) ;
启动报名功能, 并在报名期间, 对报名表定时备份、维护和管理, 报名结束时可以终止报名;
可以对考生报名表进行编辑和维护, 清除垃圾数据, 得到准确数据, 导出报名表并上报考试中心;
可以对报名表进行统计报表、费用结算;
考试中心下发成绩后, 可以将成绩表上传供考生查询;
可以对成绩进行浏览、查询、分析统计和打印报表。
3 用例模型建立
用例建模是UML建模的一部分, 也是UML中最基础的部分。其主要功能是用来表达系统的功能性需求或行为。用例建模可分为用例图和用例描述, 用例图由活动者、用例、关系、系统边界组成, 用画图的方法来完成;用例描述必须对在执行用例时, 用户和系统之间可能的交互给出定义。这些交互可以作为一种对话描述, 其中用户对系统执行一些行为, 系统于是以某种方式响应, 这样的对话一直进行到该用例实例结束, 用文本文档来完成。
3-1用例图
在UML中, 一个用例模型由若干个用例图来描述, 一个用例图中包含一至多个用例, 一个用例是用户对系统的一次典型使用。
(1) 用例图的组成
用例图的主要元素是用例和活动者。用例表示为一个椭圆;活动者是指系统的使用者 (也可以是使用该系统的其他系统或设备等) , 用一个小人形图表示;系统边界由矩形框线画出, 框内是用例系统的职责范围, 即用例系统应完成的功能, 用例系统的名字写在方框上或方框里面, 方框内部还包含该系统中的用符号表示的用例;用例图显示的用例与活动者之间、用例与用例之间以及活动者与活动者之间的关系, 使用实线表示, 实线可以有箭头, 也可以没有箭头。
(2) 识别活动者
活动者是直接或间接与系统交互的用户、外部硬件或其他系统, 它是一个群体概念。活动者是启动用例的前提条件。根据高职院校职业资格认证网上报名系统的职责范围和需求可以初步确定活动者:管理员、考生和职业资格鉴定中心。管理员负责管理系统, 考生通过系统进行考试报名、成绩查询, 系统向职业资格鉴定中心上报报名表, 职业资格鉴定中心向系统下发成绩。
(3) 定义系统边界
系统边界是指一个系统的所有系统元素与系统以外事物的分界线, 因此, 系统分析的首要任务是问题识别, 明确系统范围, 划分系统边界, 确定系统责任。网上报名系统的使用者都是系统的外部事物, 职业资格鉴定中心是系统边界之外的外部系统。而实现用户管理、网上报名、报名管理、成绩查询、系统维护等功能的程序模块均属于网上报名系统的职责范围, 是系统边界之内的部分。
(4) 确定用例
一个完整的系统包括多个用例, 各个用例具体说明所完成的功能。在UML中, 用例被定义成系统执行的一系列动作, 动作执行的结果能被指定活动者觉察。引入用例可以为系统的功能提供清晰一致的描述, 便于为后续开发工作打下良好的基础, 方便开发人员传递需求的功能。
对网上报名系统进行分析, 可初步确定六个用例:“网上报名”用例、“成绩查询”用例、“用户管理”用例、“报名管理”用例、“成绩管理”用例和“系统维护”用例。前两个用例与考生存在交互, 后四个用例与管理员存在交互, 职业资格鉴定中心与“报名管理”用例和“成绩管理”用例之间存在交互。
对上述用例继续分析, “报名管理”用例可分解为:“启动报名”用例、“终止报名”用例、“认证管理”用例、“浏览报名”用例、“上传报名表”用例和“管理报名费”用例等;“成绩管理”用例可分解为:“查询成绩”用例和“分析统计成绩”用例等。
(5) 用例和活动者之间的关系
在确定了活动者和用例等基本元素后, 接下来需确定用例和活动者之间的关系。用例和活动者之间的关系为典型的关联关系, 在这种关系下, 每一个活动者都可以触发若干个用例, 并和用例进行信息交换, 同时每个用例也可以服务于多个活动者。用例与用例之间有多种关系, 包括泛化关联、包含关联、扩展关联等。本系统中, “报名管理”用例与“启动报名”用例、“终止报名”用例、“认证管理”用例、“浏览报名”用例、“上传报名表”用例等五个用例之间是包含关系, 表示它们是报名管理过程中不可缺少的行为部分;而用例“添加报名”、“删除报名”、“更新报名”与用例“查询报名”之间是扩展关系, 表示扩展了管理系统过程中的基本行为。在系统的分析过程中, 对用例的细节描述不可能一次完成, 需要在系统生命周期的循环中逐步完善。在软件开发的初始阶段只需绘出系统的高层用例图, 而后在模型精化阶段和系统构建阶段, 逐步演化用例图。较高层次的用例被精细化为若干个小的低一层次的用例, 低层次的用例协作实现它的上一个层次的用例。以下是运用建模工具Rational Rose绘制的系统顶层用例图, 如图3-1所示, 其它用例图不再列举。
3-2描述用例
在定义用例的过程中, 描述用例是一个非常重要的环节, 用例执行需满足的条件、范围、目的等因素在系统设计阶段都占据不可忽视的地位。不同设计者采用不同的方法描述用例, 但大致如表3-1所示的几个方面。
按照上述方法对本系统的重要用例“网上报名”用例进行描述, 其中主要步骤采用两列格式来描述, 以强调活动者和系统之间的交互, 如表3-2所示。
4 结束语
本文结合高职院校职业资格认证报名管理工作的相关环节, 给出了采用UML对其进行面向对象的用例建模方法。
在UML中, 用例模型描述了系统具有的功能 (即“做什么”) , 它一般由用户 (执行者) 和用例构成, 其中用例定义了用户与计算机之间为达到某个目的而进行的一系列交互。在用例模型的设计中, 我们站在系统的外界获取系统的需求, 可方便与用户交流, 便于对需求分析做进一步的了解。建立用例模型的目的在于使用户和开发者双方可以在高层次上把握系统的主要功能, 从而为后面的设计及实现打下坚实的基础。用例模型的提出对于软件开发方法的研究具有重要的意义。H
摘要：本文针对面向对象的建模方法, 探讨统一建模语言 (UML) 在高职院校职业资格认证网上报名系统中的建模应用, 详细描述了网上报名系统用例模型的建模方法。
关键词：网上报名系统,UML,建模
参考文献
[1]吴建, 郑潮, 汪杰编著.UML基础与Rose建模案例[M].北京:人民邮电出版社, 2007.
[2]曲维娟.UML中各种图形工具的科学选择与灵活应用Ⅲ[J].河北能源职业技术学院学报, 2008 (28) :77—79.
[3]王凤斌, 段隆振, 李向军.UML面向对象建模在管理信息系统中的应用[J].计算机与现代化, 2005 (2) .