关键词不能为空

当前您在: 主页 > 英语 >

经营理念英文前沿技术课程报告

作者:高考题库网
来源:https://www.bjmy2z.cn/gaokao
2021-01-28 00:59
tags:

经营理念英文-hiper

2021年1月28日发(作者:guilty)






武汉大学



计算机学院





2010


级硕士研究生课程





软件工程前沿技术







研究方向主讲老师:






彭蓉












院:









计算机学院













号:







2










名:










程胜




















需求工程中需求获取方法综述



摘要:


随着社会信息化的飞速发展,


计算机软件变得愈来愈复杂、


规模也越来越庞大,


软件


工程的研究也日益 深入,


软件需求则逐步成为贯穿于整个软件开发过程的核心因素,


而需求


获取则成为需求工程领域的新热点。


需求获取是软件生 命周期的初始阶段,


也是决定软件成


败的关键因素之一,


由于需求不清或错误导致软件失败的案例越来越多,


所以如何快速、< /p>



确地获取软件需求成为软件行业研究的重点。

< br>


通过需求建模来获取需求,


目前有用例驱动的交互式需 求获取、


基于


UML


的需求获取、


基于领域本体的需求获取方法、基于


Event-B


的软件形式化需求获取方法、基于


RGPS


的网


络式软件需求方法等需求获取方法。


这几种方法都有自己的独特的获取 需求的方法,


侧重于


获取过程中的不同的方面,


从不同角度方向、


不同领域来克服需求获取中的困难,


提高需求


获取的准确性。



关键字:需求工程



、需求获取方法、 用例驱动、


UML


、领域本体、


Eve nt-B



RGPS


一、引言



需求工程是随着软件工程的 发展而产生的。


在软件开发的初级时期,


软件规模不大,



件开发所关注的是代码编写,


软件需求很少 受到重视。


在引入软件生命周期的概念后,


需求


工程成了软件生命周期的第一阶段。随着软件系统规模的扩大,以及为了解决“软件危机”


而引起的软件工程技术与方法的发展,


需求工程在整个软件开发与维护过程中 就显得越来越


重要了。


人们普遍认识到,


充分研究软件需求可以避免开发系统时的盲目性,


能够直接关系


到软件的成功与否。


随着软件工程的研究和应用的逐渐深入,


人们同时认识到软件需求不再


仅限于软件开发的最初阶段,


它贯 穿于系统开发的整个生命周期。


许多项目开发过程中出现


的诸多 问题都与需求工程阶段没有合理完整的进行需求获取、


分析有关。


由此可见,


需求工


程对于项目开发尤其是大型项目的研发的至 关重要的作用。



需求工程的准确含义,没有严格统一的表述。 一种比较常用的解释如下:



需求工程是指应用已证实有效的技 术、


方法进行需求分析、


确定客户需求,


帮助分析人


员理解问题并确定目标系统的所有外部特征的一门学科;

< br>它通过合适的工具和记号系统地描


述待开发系统及其行为特征和相关约束,


形成需求文档;


并对用户不断变化的需求演进给与

支持。需求工程可以分为需求开发和需求管理两部分。需求开发包括需求获取、需求分析、

< br>编写需求规格、


需求验证;


这些子学科涵盖了为软件和软 件相关产品收集、


评估和记录需求


相关的所有活动。

< p>
需求管理包括需求变更控制、


版本控制、


需求跟踪 、


需求状态跟踪等内容。



需求工程中 如何快速获取和准确地理解、


表达用户需求,


即需求获取,


是长期困扰软件


开发者的难题。


一方面,< /p>


软件开发者由于不了解应用领域,


只能被动地等待领域用户提供信


息,他们常常抱怨用户需求不全,经常变化,


使他们无所适从; 他们还难免对领域用户的描


述产生错误的理解,


因而得出不适当 的需求模型,


导致软件开发半途而废。


另一方面,


领域


用户通常不知道如何按软件开发的要求去描述他们的需求,


而且,


他们一开始常常对自己的


需求仅有一个模糊的 认识,


如果没有任何提示和引导,


就不可能立刻给出正确而完整 的需求


描述。


确定系统的需求是一个连续的过程,


开发人员在开发系统之前不可能完全详细地说明


一个系统的真正需求。


一个不完整的需求获取和管理过程,


会对项目的生命周期产生多米诺< /p>


骨牌的效应。


用户需求的缺失会导致系统需求的缺失,

< p>
从而导致设计单元及功能的缺失,



最终导致系统 不能实现预期的功能,或者需要在后期花费较大的代价来修正或补充这些功


能,导致项目 延期、产生严重的质量问题或超出项目预算。因此,及时、准确地获取用户需


求,是决定 软件项目能否取得成功的关键步骤之一。




二、需求获取及需求建模



需求获取就 是通过不断交流沟通使软件开发者和领域用户对目标系统形成共识。


现今国


内外提出了数种需求获取的方法,


从不同角度方向、


不同领域来克服需求获取中的困难,



高需求获取的准确性。< /p>



获取需求存在诸多困难主要原因如下:




1




缺乏领域知识、应用领域的问题常常是模糊的,不准确的;




2




存在默认的知识,即难以描述的日常知识(常识问题)


< p>



3




存在多个知识源,而且多个知识源之间可能有冲突。



通过需求建模可以来获取项目需求,


明确需求细节。

目前需求建模方法针对软件范型不


同主要分为结构化需求建模和面向对象需求建模,


涉及功能需求分析和非功能需求分析。



过对各种需求工程方法的研究,


目前影响力较大的需求建模方法,

分别是面向目标的需求建


模方法,基于领域本体的需求建模方法以及面向特征的需求 建模方法。



1




面向目标的建模方法



面向目标的建模 方法侧重于对早期需求进行分析和建模,


试图帮助开发者理解领域中不

< br>同角色的动机和期望,


可对功能和非功能需求目标识别分析。

面向目标的建模方法,


在需求


阶段的主要任务是要确定软件 系统需求相关者想要实现的各项目标,


建立实现这些目标所需


要 的服务和约束条件的规格说明,


并将需求按职责分配给相应的主体来完成。


该方法将


“目


标”


看作软件 需求的源头和依据,


以目标为需求获取的基本线索,


诱导需求提 供者按目标的


分解、精华和抽象关系,逐步构建系统目标与


(< /p>



)


树。面向目标方法的主要特点是目标 树为


需求活动提供了一种表示结构和自顶向下的需求分析方法,


有助于将零碎分散的需求信息组


织成易于理解的层次结构,


多种 目标分解方式使得不同的设计方案得以兼顾和考虑。


更为重


要的 是,


将目标与形式化方法结合,


能够为需求工程以及软件产品的 正确性和完整性提供可


靠的保证。


面向目标的方法,

< p>
考虑组织中参与者的主动需求,


不仅分析单个参与者的目标分


解,更研究参与者之间的各种依赖关系,如目标依赖、任务依赖、资源依赖和软目标依赖。

< p>
面向目标的方法主要有以时序逻辑为基础的基于自动规约的需求获取方法


K AOS


、面向目标


和过程分析的非功能需求框架


NFR



i


半建模框架以及建 立在目标基础上的开发方法——


TROPOS


方法。

< p>


2


、基于领域本体的建模方法



本体论是一个哲学概念,用于描述事物的本质


.


知识工程学者借用这个概念,是为了解


决知识共享中的问题。


人们发现,


知识难以共享常常是因为大家对同一件事用了不同的术语

来表达。于是人们提出,


如果能找出事物的本质,


并以此统 一知识的组织和知识的表达,使


之成为大家普遍接受的规范,


就 有可能解决知识共享中的问题。


简而言之,


本体是对于知识


的描述。就需求工程而言,本体的作用体现于:本体作为需求规格说明,即建立特定领域的< /p>


本体,


利用这个本体为建立多个目标应用系统的需求提供知识库。


此时,


本体可以看作一个


公共的领域模 型,


作为建立领域内应用系统需求规范和系统开发的基础,


能够 进行知识重用。



ODE


方法是一种比 较典型的基于本体领域分析方法,


包含三个部分:


领域分析、< /p>


领域模


型到对象模型的映射和


Java< /p>


构建开发。


ODE


方法的基本步骤包括: 建立目标和需求规范;


基于本体捕获领域概念,


标识和组织相关 领域实体,


利用图形化描述的模型来促进领域专家


的交流;


用一种形式化的语言清晰地描述本体模型;


评估本体以检查它们是否 满足需求规范;


最后对所有本体加以文档化。


从领域本体模式中 导出面向对象的模型时,


ODE


中提供了一个

< br>包括指示、


设计模式和转换规则的系统化方法,


指示可以 指导从本体结构到面向对象相应部


分的映射,设计模式和转换规则可以用来映射本体中的 公理到面向对象的相应部分。



3


、面向特征的建模方法



面向特征的领域分析


(Feature Oriented Domain Analysis, FODA)


是由


K



Kang


等人在


2 0




90


年 代提出的一种全面的领域分析过程描述,用于识别特定领域中一系列应用系统的显


著特征 ,


针对领域进行共性和个性的研究,


抽取领域模型,

< p>
从而建立可复用的软件体系结构。


其基本思想在于,从领域的具体应用系统 中,


抽象出具有代表性的功能,组成领域模型,从


而为以后的应 用系统开发奠定基础


[7]


。随后,


K



Kang


等人对

FODA


方法进行了扩展使之应


用于软件复用领域,提出了 面向特征的软件复用方法


(Feature


Oriented


Reuse


Method,


FOR M)



并且在基于构件的开发中用


FO RM


辅助开发软件体系结构和可重用构件,


确定了在

< p>
软件开发中面向特征方法的作用和意义。



面向特 征的领域分析以


“特征”


作为组织需求的基本单元,

< p>
通过分析领域具有的可复用


特征和特征之间的依赖关系,

< br>建立领域的特征模型。


领域设计则以特征模型为输入进行领域

软件体系结构的构造。


同时,


通过定制对特征模型的复用也 是形成单个软件产品需求模型的


有效手段。



三、几种需求获取方法



目前,使用比较广泛、研究比较热门的几种需求获取方法有:




1




用例驱动的交互式需求获取




2




基于


UML


的需求获取



3




基于领域本体的需求获取方法




4




基于


Event-B


的软件形式化需求获取 方法




5




基于


RGPS


的网络式软件需求方法



1


、用例驱动的交互式需求获取



多年来,


分析者总是利用情节或经历来描述用户和软件系统的交互方 式,


从而获取需求。


Ivar


Jac obson(1992)


把这种看法系统地阐述成用例的方法进行需求获取和建模。虽然 用例来


源于面向对象的开发环境,但是它也能应用在具有许多开发方法的项目中。



用例(


use


c ase


)是指系统为了向参与者提供某些有价值的结果而执行的动作序列,这

< p>
个序列是在与系统的对话中完成的新的活动。用例代表的是外部执行者所理解的系统功能。


涉及到参与者即角色。


用例中的关系有扩展


(< /p>


Extend




包含



Include


< p>
和泛化



Generalization



.



用例驱动的交互式需求获取方法:




1


)功能性需求的获取:获取用户需求,定义问题范围,收集用 户需求,确定参与者



和用例。


参与者 是指所有存在与系统外部并与系统进行交互的人或其他系统,


从需求获取信


息获取参与者。首先要确定系统范围(


System


Scope


)和系统边界(


System


Border



,

< br>系统


的范围与边界取决于开发的目标、


任务和规模;


确定参与者的种类,


参与者有三大类也就是


三种角色


:


用户、其他系统和时间。




2


)用户需求用例的获取:获取用例 的最好办法是考虑每个参与者需要系统为他做些



什么,即参与者的目标。最后进行用例求精(


Use


Case


Refinement


)< /p>


。用户需求决定了系统


的功能需求,


为了 获取这些功能需求,


必须要对用户需求阶段获取的大粒度的抽象用例进行


求精,


通过细化用例的事件流,


得到用例的所有场景的 集合,


而这些场景中各个步骤就是功


能需求的来源。

< p>


用例驱动的关键在于提供准确的


Actor


以及相关的用例信息。


因而我们设计出相应的用

户填写的内容,


让用户填写它所关心的功能需求的描述,


基 本以获取用例驱动相关信息为主。


填写完所需内容我们可以往需求获取表格中添加,


当然,


由于是交互的过程,


我们需要对需< /p>


求进行反复的修改,


因而我们允许进行修改、

删除等操作。


用户需求描述信息的格式以及要


素有:功能需 求描述、用户名、用例描述、主要


Actor


、前置条件、成功 后置条件、失败后


置条件、关联用例。



2


、基于


UML


的需求获取



面向对象的建模是一种新的设计思想,


一种关 于计算和信息结构化的新思维。


面向对象


的建模,把系统看作是 相互协作的对象,


这些对象是结构和行为的封装,都属于某个类,那

些类具有某种层次化的结构。


系统的所有功能通过对象之间相互发送消息来获得。< /p>


面向对象


的建模可以视为是一个包含以下元索的概念框架


:


抽象、封装、模块化、层次、分类、并行、


稳 定、可重用和可扩展。



UML


适用于 以面向对象的技术来描述任何类型的系统。而且适用于系统开发的不同阶


段。

< p>
可以应用于任何领域,


其实现机制又极人地缩短了与用户的距离,


易于被用户掌握和接


受。


UML


使用户不仅可以有效地参与需求定义,还能在建模过程中参与部分的设计、实现


和测试,从而有效地进行需求验证。使用户在需求的定义、决策、验证和管理,乃至整个软


件开发过程中,充分发抨其主导作用。



UML


包括


UML


语义和


UML< /p>


表示法两个部分。


UML


语义采用


4


级元模型体系结构:元


-

< br>元模型(


meta-meta model


< p>
,元模型的基础体系结构,定义了一种说明元模型的语言;元模


型(


met


model



,元


-


元模型的一个实例,定义一种说明模型的语言;模型(


model



,元模

< br>型的一个实例,定义一种语言来描述信息领域;用户对象(


user objec t


)模型的一个实例,


定义一个特定的信息领域。标准建模语言


UML


有五类图:用例图,从用户角度描述系统功

< p>
能,并指出各功能的操作者;静态图,包括类图、对象图和包图;行为图,描述系统的动态


模型和组成对象间的交互关系;


交互图,


描述对 象间的交互关系;


实现图,


包括构件图和配

置图。



UML


适用于系统开发过 程中从需求规格描述到系统完成后测试的不同阶段。在需求分


析阶段,

< br>可以用用例来捕获用户需求。


通过用例建模,


描述对系统 感兴趣的外部角色及其对


系统


(


用例< /p>


)


的功能要求。分析阶段主要关心问题域中的主要概念

< p>
(


如抽象、类和对象等


)


和机


制,需要识别这些类以及它们相互间的关系,并用


UML< /p>


类图来描述。为实现用例,类之间


需要协作,这可以用

< p>
UML


动态模型来描述。在分析阶段,只对问题域的对象

< br>(


现实世界的概



)

< p>
建模,而不考虑定义软件系统中技术细节的类


(


如 处理用户接口、数据库、通讯和并行性


等问题的类


)

< p>
。这些技术细节将在设计阶段引入,因此设计阶段为构造阶段提供更详细的规


格说明。



3


基于领域本体的需求获取方法



所谓领域本体(


Domain Ontology



,是指用于描述指定领域知识的一种专门本体,它给


出了领域实体概念及相互关系、领域活动以及该领域所具有的特性和规律的一种形式化描


述。目前最普遍的本体描述语言有


OWL


< br>Ontolingua



CycL



Loom


等。此外,本体的建模


工 具也有很多,主要有


OntoEdit



Ontolingua



Prot


é


g


é等。目前使用最多的本体编辑工具是


Prot


é。领域本体由对象、对象的属性、对象之间的关系以及子领域本体构成。领 域本体的


构建方法有多种,如:


TOVE


法、


METHONOTOLOGY


法、


KACTUS


法等。



为了解决传统 需求获取方法的不足,


将特定领域的领域本体引入到需求分析过程中,

< br>不

经营理念英文-hiper


经营理念英文-hiper


经营理念英文-hiper


经营理念英文-hiper


经营理念英文-hiper


经营理念英文-hiper


经营理念英文-hiper


经营理念英文-hiper



本文更新与2021-01-28 00:59,由作者提供,不代表本网站立场,转载请注明出处:https://www.bjmy2z.cn/gaokao/575751.html

前沿技术课程报告的相关文章