【doc】 基于UML的需求获取工具的设计.docVIP

基于UML的需求获取工具的设计 第10卷第3期 2005年9月 集美大学(自然科学版) JournalofJimeiUniversity(NaturalScience) go1.1()NO.3 Sep.2005 [文章编号]1007—7405(2005)03—0241—04 基于UML的需求获取工具的设计 刘艳霞 (华南理工大学计算机学院,广东广州510640) [摘要]提出了一种用例构造框架帮助分析人员构造结构化的用例,同时在用例构造框架的基础上设 计了需求获取工具,为分析人员获取和管理需求提供一个直观的可视化的平台. [关键词]UML;需求获取;用例分析技术 [中图分类号]TP311.56[文献标识码]A O引言 需求分析是软件开发过程中非常关键的一个阶段,需求分析的好坏直接影响到软件开发的成功与否. 用例的出现在一定程度上缓解了需求带给分析人员的压力,它从用户的角度出发,描述系统与用户的交互 过程,为获取需求提供了技术支持.由于用例的广泛使用,统一建模语言(UML)将其融人了它的建模机 制中,作为基本模型元素来捕获需求,并且在UML标准中定义了用例的抽象语法,语义和可视化表示.然 而,在基于UML的面向对象的软件开发过程中,用例经常被错误地使用,或过于庞大,或缺少结构化的规 格描述.而且,已有的基于UML的CASE工具,如现在流行的建模工具RationalRose以及需求管理工具 RequisitePro等,忽略了支持构造标准化用例的过程,仅仅提供了用例模型的绘制和说明描述平台.笔者研 究和设计了URET(UML—BasedRequirementElieitationToo1)用于弥补以上不足. 1用例构造框架 UML中虽然给出了用例的语义和可视化表示,却对用例结构缺乏准确和细节的描述.在UML语义 中规定:用例的描述形式可以是自然语言,活动图,状态机或其它任何一种行为描述方法.这表明人们 可以随意使用各种方法或自己的格式定义对用例进行描述,这种随意性极大地阻碍了需求双方对用例的 理解.人们希望能使用一种统一的描述格式来增加用例的理解度.为此,笔者在综合改进Coekbum, DerekColeman等人在相关方面所做的工作的基础上,提出了URET的用例构造框架.它扩展了UML 对用例的结构定义,以模板的形式对用例进行描述,同时为构造标准化的用例提供了理论指导,框架中 包括了用例构造过程中应该遵循的步骤和用例流图.用例模板和用例流图是两种构造用例的方式,用例 模板侧重于文字描述,而用例流图侧重于图形表示,两者有效的结合可以方便获得结构化的用例. 1.1用例构造步骤 URET的用例构造框架中给出了构造用例应该遵循的步骤,其主要顺序为:1)指出系统所属范 畴,了解系统的上下文环境;2)列出参与系统的执行者,并识别主执行者和辅执行者,得到执行者 列表,表1是银行帐户系统中确定的执行者列表;3)指出每个主执行者的所有目标,得到(执行者: [收稿日期]2004—12—20 【作者简介】刘艳霞(1979一),女,助教,从事软件工程环境,软件体系结构研究. ? 242?集美大学(自然科学版)第l0卷 目标)对,表2是银行帐户系统中确定的执行者 的目标列表;4)对每个主执行者的目标进行调 整,用概要层或用户任务层上的目标命名主要的 用例;5)对于每个用例,确定用例的前提条件, 用例的范围等特征;6)对于每个用例,运用用 例流图分析该用例的主要成功场景和可恢复/不 表1执行者列表 Tab.1ActtorIist 执行者角色 主执行者 主执行者 辅执行者 描述 银行客户 银行管理人员 打印机 使用系统查询帐户或完成交易 管理客记和帐户信息 可恢复的场景;7)对用例流图中产生的新的子用例重复步骤5), 6)进行分析;8)对用例进行调整,检验用例的可读性和完整性. 1.2用例模板 URET的用例构造框架中提供了用例模板用于描述用例,在 构造用例的过程中运用用例模板可以使得到的用例更加规范,用 例描述也更容易理解.表3显示了用例模板的格式. 表3用例模板 Tab.3Usecasetemplate 表2执行者:目标列表 Tab.2Actor:objectlist 执行者目标 打开一个帐户 从帐户中取钱 客户向帐户中存钱 向另一个帐户中转帐 查询帐户余额 银行管理人员… 项目内容 用例名 描述 范围 目标层次 执行者 前提条件(可选) 后置条件(可选) 触发事件(可选) 主要路径 备选路径 优先级 非功能需求(可选) 备注(可选) 表明用例要实现的目标,用简洁的动词短语表示,包括用例编号 更为详细地描述用例要实现的目标以及用例的上下文 用例所属的系统或商业企业 用例目标所属的层次(概要层,用户任务层,子功能层) 参与用例的执行者,包括主执行者和辅执行者