没有合适的资源?快使用搜索试试~ 我知道了~
理论计算机科学电子笔记264(2010)91-105www.elsevier.com/locate/entcs行为驱动的UML基础组件开发IoanLazar1,2SimonaMotogna1,3BazilParv1,4BolyaiUniversity计算机科学系罗马尼亚克卢日-纳波卡摘要行为驱动开发(BDD)将所有开发活动集中在行为的交付上-系统应该做什么,描述为开发人员和领域专家说同一种语言。 BDD框架允许用户将所需的系统行为表示为可执行的用户故事,并将验收标准表示为附加到用户故事的可执行场景。在本文中,我们定义了一个UML概要文件,允许用户创建可执行的基础UML(fUML)故事和场景。 为了方便地构建场景,我们引入了一个BDD模型库,其中包含用于测试等式和包含的fUML活动。我们还提出了一个基于BDD的开发工具,支持开发fUML组件的方法。该工具为开发人员提供了定义可执行场景的具体语法,并根据已验证的交付行为自动更新项目状态关键词:行为驱动开发,可执行UML,用户故事,可执行规范,验收标准1介绍BDD[17]是一种敏捷软件开发方法,鼓励所有项目参与者之间的协作。BDD是测试驱动开发(TDD)[3]和验收测试驱动计划的演变。BDD最重要的核心原则是为了实现这一目标,需要一种通用的(普遍存在的)语言来指定系统行为,允许:(a)客户从业务角度指定需求,(b)业务分析师附加具体示例(场景1这项工作得到了罗马尼亚国家研究委员会(CNCSIS)资助的546号基金的支持。2电子邮件地址:ilazar@cs.ubbcluj.ro3电子邮件地址:motogna@cs.ubbcluj.ro4电子邮件地址:bparv@cs.ubbcluj.ro1571-0661 © 2010 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi:10.1016/j.entcs.2010.07.00792I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)91或验收测试),阐明系统的行为,以及(c)开发人员以TDD方式实现所需的系统行为。用户故事代表了为了允许开发人员和领域专家使用相同的语言,需要一种领域特定语言(DSL)来定义故事的场景。BDD的第二个核心原则是围绕系统行为组织开发任务可以实现第一个目标,但是我们如何知道我们何时交付了一个行为呢?如果使用可执行的sce- narios(可执行验收测试)描述行为,则可以通过成功通过测试自动验证软件在模型驱动开发(MDD)环境中应用这些敏捷原则对两个世界都有好处。MDD方法依赖于使用模型来表示系统元素。MDD方法有两种变体:专注于使用领域特定的建模语言(DSML)和基于OMG的模型驱动架构(MDA)[ 18 ],后者依赖于使用UML [ 25 ]以及特定MDA方法比DSML更受青睐,因为UML是一种被广泛接受的建模语言。可以与BDD方法合并的MDA过程的一个特殊类别是敏捷MDA过程[14],它将敏捷原则(例如,首先测试,立即执行)应用到经典MDA过程中。对于这样的过程,模型就像代码一样。可执行的UML [15]意味着足以满足计算完整性的动作子集的执行语义。今天,定义标准执行语义的任务进入了最终采用阶段。基础UML(fUML)定义了一个在本文中,我们定义了一个UML概要文件,允许开发人员使用BDD方法构建fUML模型。我们还定义了一个BDD库,其中包含可以帮助用户构建可执行场景的活动。为了轻松构建可执行的场景,我们为BDD场景引入了一个具体的语法,并讨论了该语法与目前正在开发的预期标准化动作语言的关系[22]。本文还介绍了一个面向fUML模型的BDD工具(bUML)。该工具支持所有BDD活动,并在场景执行后自动更新项目状态。在第2节中,我们介绍了BDD和MDD的一般背景。第三和第四部分介绍了建议的UML概要文件和库,第5部分描述了我们的开发工具。在第6节中,我们讨论了相关的工作,而最后一节包含结论和未来的工作。I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)9193具有0..* 用户0..*- 所有者0..1是负责场景名称<<枚举>>-status场景状态描述0..*包含0..*0..*故事ID名称文本未决失败成功验证具有<<枚举>>StoryStatus已定义的进行中0..*估计0.. *产率-状态完成number迭代名称/估计数/progress项目2背景当Dan North引入BDD [17]时,他提出了一种无处不在的分析语言,以便将需求捕获到代码库中。这种语言将需求表示为用户故事,将验收标准表示为附加到用户故事的scenar-ios。他提出了以下编写情景的标准形式:给定一些初始上下文,当事件发生时,然后确保一些结果。为了自动验证一个给定的故事是否被实现,他建议场景必须被编写为测试用例。接下来,我们将从两个角度来分析这些概念:敏捷项目计划和执行框架。本节中呈现的数字代表了第5节中呈现的开发框架的设计工件。具有0..*Fig. 1. BDD的主要概念敏捷项目规划。图1给出了一个领域模型,它捕获了BDD的主要概念。一个项目有许多描述项目需求的故事,每个故事都由场景来验证一个项目有用户,用户可能有附加的角色,如客户、分析师和开发人员。故事用于估计开发时间,并分配用户来实现所需的功能。BDD是一种迭代开发方法,因此Storie被分配给Iteration。这些概念也用于基于卡片的规划,其中客户和开发人员使用故事卡来表示用户故事(参见例如[1])。需求分析US1.用户将新故事添加到项目US2。用户向故事中添加新场景项目规划US3.用户将新的迭代添加到项目US4。用户将故事分配给迭代US5。开发者接受故事开发迭代US6. 开发人员实施故事US7.在场景执行后更新迭代状态US8.方案执行可核查的进展US9用户可以获得迭代状态报告US10。用户可以获得项目状态报告图二. BDD活动以用户故事的形式但最重要的方面与StoryStatus和ScenarioSta- tus有关,以及我们如何确定项目进度。为了分析这些方面,我们考虑BDD过程的主要活动-参见图2。94I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)91<<场景>>验证故事初始化<<场景>>估算一个包含两个估算故事的项目<<场景>>估算包含估算故事的项目<<故事>>添加新故事一个项目{id=“US1”}(b)估算一个包含两个估算故事的项目给出“一个项目”和“两个新故事”当“两个故事都有估计”时,那么“项目估计是故事估计的总和”当一个新的故事被添加到一个项目中时,它的状态被定义。当开发人员接受故事时 , 故 事 进 入 Accepted 状 态 。 当 开 发 人 员 开 始 实 现 故 事 时 , 它 进 入 状 态Inprogress,当他/她完成时,它进入状态Completed。几乎所有的敏捷项目计划工具都需要手动设置Inprogress和Completed状态。为了能够自动设置故事状态,我们需要进一步分析故事和场景之间的关系。图三. US1故事及其场景执行框架。为了澄清需求中的歧义,用户为每个故事添加场景。根据项目设置,可以由客户、分析师和/或开发人员定义sce- narios。新添加的方案进入Pending状态。图3显示了在图2的US 1上下文中定义的三种场景。使用given、when和then子句的具体示例描述了一个场景,如图4所示。一些BDD框架(例如[6])允许开发人员运行场景,尽管它们不包含验证代码。因此,这些工具将报告有多少Scenario处于Pending状态,这可以被视为对实现故事必须完成的工作量的估计(a)验证故事初始化给定“一个项目”当“一个新的故事被创造”时,然后“故事状态应该被定义”和“项目应该包括故事”(c)估算包含估算故事的项目给定“一个项目”和“一个新故事”当“故事被估计”时,那么“项目评估应该是故事评估”见图4。 US1场景描述当开发人员实现一个故事时,他们会依次考虑它的场景并应用TDD步骤。他们首先添加测试代码,然后添加生产代码,只是单词test被单词should替换。例如在I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)9195在 Java 上 下 文 中 , 他 们 不 是 使 用 JUnit [9] 编 写 assertEquals ( story.status ,StoryStatus. Defined),而是使用easyb[6]编写story.status.shouldBe StoryStatus.Defined。与图2所示的BDD活动相关,所有BDD执行框架,包括easyb [6],都允许开发人员执行与开发迭代和可验证进度阶段相关的所有活动。研究的问题是,我们如何可以使用BDD方法开发可执行的fUML组件。fUML标准为创建可执行的UML模型提供了一个简化的UML抽象语法子集[25为了能够使用任何UML兼容工具,我们必须定义一个与fUML规范[23]和现有UML测试概要[19]一致的概要。fUML定义了面向实现的抽象,因此,在MDA方面,我们在本文中的调查涉及平台无关模型(PIM)。MDA指南指出,系统的需求是在计算独立模型(CIM)中捕获的,CIM代表了系统预期要做的事情,然后使用模型转换生成PIM。在这方面,我们还应该讨论与其他现有的用于定义CIM的需求模型的关系,例如业务动机模型[21]和SysML需求[24]。此外,我们的调查仅限于fUML规范定义的结构和行为构造。fUML结构构造不包括组件、复合结构和协作,而行为构造不包括交互和状态机。在这种情况下,系统结构使用包、类、属性、关联和操作来定义,而系统行为则通过活动来定义。关于系统的类型,fUML构造可用于定义反应系统以及算法/数据密集型系统。我们的主要目标是获得一个适合算法和数据密集型程序的BDD框架。此外,我们没有涵盖典型分层架构的所有方面,该架构由表示层、域层和基础架构层组成。当前的fUML构造可以用于定义域元素。为了定义一个框架,允许开发人员执行包含表示和基础设施元素的模型,必须考虑其他可执行结构另一个必须调查的重要方面是创建可执行的UML活动,这仍然是一项艰巨的任务,因为用于执行的UML原语是低级的。需要一个具体的文本语法,因为它强制执行了构建模型的特定方式。这意味着需要在图形化UML活动图中显式创建的许多元素可以隐式地从语法中派生出来并自动创建。正如MDA指南所指出的,从PIM开始,可以向不同的目标平台生成代码。生成的代码应该是完整的,没有代码占位符供开发人员填写。生成类的结构但是,为操作的行为生成代码更加复杂,因为元素的结构和操作的方式96I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)91<<构造型>>TestContext[StructuredClassifier]<<刻板印象>>TestCase[行为,操作]<>given[Action]必须要考虑到连接如果用于定义活动的具体语法遵循结构化编程原则,那么为活动生成的UML模型是结构化的,那么生成面向Java或C++等语言的代码就成为一个简单的过程。3BDD简介本节介绍了用于定义可执行fUML故事和场景的建议UML概要此概要的定义与UML测试概要[19]和fUML规范[23]一致。图5显示了用于对故事和场景建模的构造型集。fUML标准为创建可执行的UML模型提供了一个简化的UML抽象语法子集。fUML的结构构造由包、类、属性、操作和关联组成,而行为构造由活动组成。在这种情况下,故事可以建模为类,场景可以建模为类上下文中定义的活动。故事和场景创作。通常这些工件是由客户和/或分析师在需求分析阶段创建的。Story和Scenario原型分别扩展了TestContext和TestCase原型。TestContext充当一组TestCase的分组机制,TestCase是指定测试的行为,因此Story可能会将Scenario作为自己的行为。为了与fUML保持一致,Scenario可以只应用于活动(从fUML中删除其他UML行为此外,因为TestCase总是返回一个Verdict(通过、失败、不确定或错误),我们要求每个Scenario必须返回一个Verdict。图五. BDD配置文件在图3中可以找到故事和场景的示例,它显示了一个类图,其中包含一个由Story定型的类和三个由Scenario定型的活动。为了节省空间,图中只显示了这些工件的name属性。请注意,默认情况下,Storie% s的状态为“已定义”,Scenario%s的状态为“待定”。如果我们使用符合fUML和UML测试概要的用例工具来执行这些场景,那么我们应该获得(根据BDD)所有场景都是Pending。为了适应现有的测试等待失败成功<<枚举>>情景状态text:String [0..[1]状态:ScenarioStatus [1] =待定<<刻板印象>>场景已定义的进行中已接受已完成<<枚举>>StoryStatusid:String [1]text:String [0..[1]status:StoryStatus [1] =已定义的估计值:[0..[1]优先级:[0..1]OwnerName:String<<刻板印象>>故事<<原型>>when[Action]<>then[Action]I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)9197基础设施到BDD,我们将Pending场景约束为返回一个不确定的裁决Story和Scenario原型的text属性表示系统行为的细节属性estimate、priority和ownerName表示敏捷项目规划中使用的概念场景描述。给出的构造型,when和then可以用于描述场景,并且可以应用于任何fUML动作。同样的原型可以被多次应用,但必须遵循以下顺序:given、when和then。描述过程可以由任何用户(客户、分析师或开发人员)在场景实现之前进行。使用这些原型的示例如图6所示,其中根据图4(a)中呈现的文本描述详细描述了图3中呈现的第一个场景该方案使用四个结构化活动进行描述,开发人员将进一步实施这些活动。正如我们所看到的,当我们执行这个场景时,会得到一个不确定的判决。见图6。场景描述:给 出 的 原 型 , when , and , then 扩 展 了 UMLAction 元 类 ( 而 不 是StructuredActivityNode),以允许用户在场景之间重用代码。例如,当相同的语句序列出现在多个场景中时,可以在单独的Activity中定义该序列,然后在所有场景中使用由given、when或then定型的CallbehaviourActions调用该序列。4使用BDD库的从场景描述开始,开发人员实现必须返回通过或失败判决的场景。正如TDD建议的那样,它们可能会引用尚不存在的编程元素。然而,这是一个困难的任务,因为用于执行的fUML原语的级别太低。fUML强制使用数据流抽象表示来定义方法的行为。这意味着,这些类型的实体的值(或引用)将作为标记在边缘上流动,而不是从某些保留位置访问参数或变量的值在这种情况下实现sce- narios的缺点之一是必须使用图形编辑器和低级fUML操作(如ObjectAction,ReadStructuralAction等)来定义UML活动。其他缺点是指测试等式和包含,定义场景的然后部分所需的操作测试两个值是否是相同的对象,98I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)91函数签名描述shouldBe(x[0.. 1],y[0.. 1]):Boolean如果x等于y,则为True。shouldNotBe(x[0.. 1],y[0.. 1]):Boolean如果x不等于y,则为True。shouldInclude(list[*],item[0.. 1]):Boolean如果列表包含项,则为True。shouldIncludeAll(list1[*],list2[*]):Boolean如果list1包含list2,则为True。shouldList(list[*],item[0.. 1]):Boolean如果列表不包括项,则为True。shouldExcludeAll(list1[*],list2[*]):Boolean如果list1不包含list2的任何元素,则为True。shouldBeEmpty(list[*]):Boolean如果列表为空,则为True。shouldNotBeEmpty(list[*]):Boolean如果list不为空,则为True。shouldBeLessThan(x:0.. 1],y:0 [0.. 1]):Boolean如果x小于y,则为True。调用fUML原语函数。原始函数。应小于或等于(x:0.. 1],y:0 [0.. 1]):Boolean如果x小于或等于y,则为True。调用fUML =原始函数。shouldBeGreaterThan或Equal(x:0.. 1],y:0 [0.. 1]):Boolean如果x大于或等于y,则为True。调用fUML> =原始函数。见图7。 BDD模型库表示空值,并处理具有0..1或0..*多重性表示用于创建场景的then部分的最困难的任务。必须使用TestIdentityAction来测试两个值是否是相同的对象,但此操作将输入引脚的多重性约束为1。1.所以,当我们测试一个多重性为0的属性时。1我们必须首 先 使 用 fUML 中 的 ListSize 原 语 函 数 执 行 null 测 试 , 然 后 调 用TestIdentityAction。另一个困难和重复的任务是测试一个值是否属于一个值列表。在这种情况下,我们必须使用扩展区域,我们还必须考虑可选的多重性。为了简化创建场景的then部分的过程,我们定义了一个BDD模型库,其中包含用于测试等式和包含的fUML活动-参见图7。所有这些活动都有非类型化的参数,并返回一个布尔值。对于可比较值,我们还包括比较的活动:shouldBe{LessThan,LessThanOrEqual,GreaterThan,GreaterThanOrE-qual}。见图8。shouldInclude(list[*],item[0.. 1]):BooleanI. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)9199这个库的设计遵循为集合定义的OCL [20]函数的设计。这些活动是使用低级别的UML动作来描述的(例如:TestIden- tityAction)和fUML原语函数(例如ListSize)。作为一个例子,图8展示了使用扩展区域描述的活动shouldInclude首先,通过测试item的列表大小是否为零来测试item是否为null。然后,使用扩展区域来覆盖list的元素,并调用TestIdentityAction来测试list的元素(it)是否等于item。 这不是一个有效的实现,因为扩展区域将针对所有输入引脚执行一个理想的设计是将这些行为定义为由案例工具基础设施实现的基本功能,类似于fUML模型库。见图9。 情景实施图9(a)示出了图6中描述的场景的实现。给定的和结构化的活动使用fUML的ObjectAction,re-callOperationAction。ForkNode模拟变量project和story,如fUML规范所示。然后结构化的活动包含其他UML标准操作,用于读取结构化特征值,并从我们的库中调用行为100I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)91使用这种基础设施实现场景是可能的,但这是一项繁琐的任务。此外,如果我们不使用结构化活动来保持良好的动作嵌套,我们就无法执行向结构化编程语言(例如Java)的模型到文本转换。下一节将介绍我们的敏捷解决方案,用于轻松创建fUML场景。5bUML工具我们已经开发了一个工具(bUML),它支持图2中所示的所有BDD活动,并允许用户基于所提出的UML概要文件和BDD库创建fUML模型为了简单快速地定义场景,我们引入了bUML是COM DE VAL CO工作台的一部分[29,5],这是一个软件框架。组件定义、验证和组成。COM DE VAL CO使用了一个骗局-[12]第11话:不好意思,不好意思。目前,基于fUML的动作语言还没有标准化的具体语法,OMG发布了一个具体语法的征求建议书(RFP)[22]。本文中为场景定义的具体语法扩展了我们今天的动作语言[11]。当标准化的动作语言可用时,我们将使我们的动作语言与标准保持一致。然而,正如RFP所示,预期的标准化语言将不包含BDD结构,因此,我们的场景扩展将不支持更大的更改。下面的每个小节描述了我们的开发方法的步骤。项目设置。一个项目包含fUML模型,每个模型都是一个UML片段,其中可能包含故事或产品代码。将fUML模型划分为片段对于管理迭代和组织开发团队非常有用。fUML虚拟机[16]用于执行模型。bUML作为敏捷BDD工具提供了两个重要特性• 鼓励客户使用bUML来编写他们的需求,并将其表达为用户故事,并用于验证项目进度。• 用户(包括客户)可以在开发生命周期中的任何时候执行故事。需求分析。客户和/或分析师将需求捕获为添加到初始fUML模型中的故事。UML包可以用于按功能区域对故事进行分组。故事是一个被故事定型的类。场景可以附加到故事中,以阐明所需的系统行为,场景被定义为由场景定型的UML活动,并在故事的上下文中定义。例如,图3显示了一个类关系图,其中包含由三个场景描述的故事US1(参见图2为每个场景添加一个具体的示例有助于用户更好地理解需求,并获得所需行为的验收测试。为了方便创建场景,我们定义了一个类似于easyb的具体语法[6]。I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)91101具体语法UML抽象语法表示“X”条款一个名为x的StructuredActivityNode。条款{语句块}一个名为x的StructuredActivityNode,语句块作为内容,根据当前使用的操作语言。条款一个名为x和bevaviory的CallbehaviourAction。x应该xxx y对应shouldXxx的CallbehaviourActionBDD library中的行为。见图10。 具体和抽象语法映射用户可以使用给定的关键字来定义场景,when和then对应于引入的原型。关键字和可以在同一子句重复时使用。具体语法元素的UML抽象语法表示如图10所示。图4显示了图3中场景的这些工件是使用文本编辑器创建的,该编辑器根据图10中给出的规则生成UML表示。例如,图6在图形编辑器中显示了由文本编辑器为US1的第一个场景生成的模型。项目规划。捕获整个所需系统行为的初始模型可以分成几个模型片段,每个片段对应于一个迭代。通过在这些片段之间移动故事来将它们分配给迭代。当用户执行场景时,他/她可以选择执行所有项目故事,或者只执行分配给给定迭代的故事集对应于迭代的模型也可以被分成几个模型,这些模型对应于接受故事的开发人员。当用户执行变更管理操作时,通过迭代和开发人员将初始模型划分为片段也很有帮助。拥有一个包含当前迭代中给定用户的已接受故事的模型,有助于用户仅执行他/她的故事,以便对已完成的工作量或必须完成的工作量进行估计。开发迭代。支持典型的TDD步骤,但重点关注以下场景:(a) 编写一个场景,其中可能涉及尚不存在的元素(b) 运行场景,看看它们是否失败;(c) 写代码让场景通过。开发人员可以使用图形编辑器来定义fUML活动,从而完成步骤(a)和(c)。但是创建甚至合理大小的fUML模型是一项乏味的任务-例如参见图9(a)。为了加快步骤(c)编写生产代码的活动,我们使用为fUML定义的具体语法[11]。对于编写场景-步骤(a),我们扩展了这种语言,允许用户编写附加到给定和when子句的业务代码,以及附加到then子句的验证代码。我们为BDD模型库定义的每个活动引入了二元运算符使用二进制运算符编写验证代码,102I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)91项目+ Story():Story定义<<枚举>>StoryStatus见图11。 生产代码代码接近自然语言表示-客户应该能够阅读它,根据BDD原则。这些操作符的UML抽象表示如图10所示。图4显示了没有验证代码的有效场景描述,而图9(b)显示了具有附加代码的场景,其对应于图9(a)的抽象语法表示。此场景所需的生产代码如图11所示。见图12。文字和图形表示文本或图形编辑器可用于实现方案和方法的主体。我们的工具将这些工件的文本和图形表示转换为文本和图形。作为一个例子,图12显示了当使用多个then子句时文本和图形表示statement 1和statement 2可以是任何fUML语句,并且图中没有显示初始化变量的给定/then子句这些子句具有决策节点,这些决策节点又具有来自调用行为动作的结果决策节点有两个传出控制流,一个带有保护真,另一个带有保护假。false控制流连接到失败验证操作,true控制流连接到下一个子句或通过验证操作。可核查的进展。正如我们在本节开始时提到的,客户可以使用bUML来编写需求和获取进度报告。在任何时候,用户可以执行项目故事的选择,以获得进度报告。该报告包含与已完成的工作量和必须完成的工作量为了能够比较系统应该做的和它实际上应该做的- 故事0.. *-status:状态故事I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)91103这样,bUML自动管理故事和场景状态。当一个场景被执行时,判决会自动设置为模型场景。此外,给定一个故事,当所有场景都通过时,故事状态会自动更改为已完成。因此,当用户打开项目构件时,他们会看到项目进度的状态在最后一个场景执行后自动更新。6相关工作据我们所知,没有其他现有的作品结合BDD和MDD的方法。正如我们在第3节和第4节中所展示的,我们构建fUML模型的方法接近于easyb [6],一个平台特定的BDD框架。还有很多其他BDD平台特定的框架(例如[8],[30]),但都代表了第2节中提出的相同概念。在这个阶段,我们已经研究了BDD profile和easyb之间的映射[6]。我们的分析结果表明,我们可以定义使用此概要文件和easyb框架开发的fUML模型系统行为可以用系统作为一个整体应该实现的不同粒度级别来描述,描述系统各个组件的行为,技术行为,等等。建议的BDD概要文件和其他现有的需求规范模型(如业务动机模型(BMM)[21]和SysML需求[24])之间的关系是通过与UML测试概要文件的一致性来建立的如果我们使用BMM来表示需求,那么故事可以被定义为具有BMM(战略,战术,业务政策和业务规则)的行动过程的目标。客观构造型由UML测试概要定义,可以用作TestContext和其他模型元素之间的依赖关系。如果我们使用SysML需求,那么故事将验证需求。verify构造型由SysML规范定义,可以用作TestContext和SysMLRequirement之间的依赖关系。BDD方法与其他可执行文档工具相当,例如Fit [7]及其衍生物,它们遵循称为可执行验收测试驱动开发(EATDD)的类似方法[27]。这些工具允许客户、测试人员和开发人员比较他们的软件应该做什么和它实际做什么。EATDD工具实现了图2所示的所有活动,但没有为所有用户提供一种普遍存在的语言。验收测试标准表示为输入数据和预期输出数据的表格,每行代表一个场景。这种表示是EATDD相对于BDD的优势,因为用户能够针对软件系统的各个层和组件使用相同的表格数据-一种称为多模态测试执行的技术[28]。我们的工具的项目规划功能类似于EATDD工具(例如,[7]),但与场景执行后更新项目状态相关的功能除外。我们的工具会自动更新故事状态,而后者需要用户手动设置故事状态。104I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)917结论和进一步工作为了获得可执行UML组件的BDD框架,本文介绍了一个UML profile。基于所介绍的概要文件的模型可以使用任何UML工具来构建,或者可以在任何具有fUML执行能力并符合UML测试概要文件的UML工具中运行。我们还提出了一个具体的语法,便于创建可执行的方案,我们已经展示了如何COM DE VAL CO框架支持这个基础设施。作为未来的工作,我们打算调查多模态测试执行技术的fUML的背景下,使用UML复合结构和测试数据的概念。此外,还必须添加模型转换功能。在构建fUML模型的BDD方法的背景下,与使用需求规范语言[13,26,10]相关的调查也可以改进所提出的普适语言。引用[1] 敏捷规划师,http://ase.cpsc.ucalgary.ca/index.php/AgilePlanning/AgilePlanner网站。[2] Ambler,S. W.,“The Object Primer: Agile Model-Driven Development with UML 2.0,” CambridgeUniversity Press,[3] Beck,K.,[4] 行为驱动开发,http://behaviour-driven.org。[5] 齐 布 拉 岛 G. , C.- L. Lazar , S. 莫 托 尼 亚 湾 帕 夫 和 我 。 Lazar , ComDeValCo Tools for ProceduralParadigm , in : International Conference on Computers , Communications and Control ( ICCC2008),2008,pp. 243-247[6] easyb,http://www.easyb.org/。[7] Fit,http://fit.c2.com/。[8] JBehave,http://jbehave.org/.[9] JUnit,http://www.junit.org。[10] Kaindl,H. 等人,www.redseeds.eu网站。[11]拉扎尔角L.,I. Lazar,S.莫托尼亚湾Parv和我G. Czibula,使用fUML动作语言构建UML模型,在:第11届国际。Symp. SYNASC,2009年,(待发表)。[12] 拉扎尔岛,B. Parv,S.莫托尼亚岛G. Czibula和C.-L. Lazar,An Agile MDA Approach forExecutable UML Structured Activities,Studia Univ. Babes-BolyaiLII(2007),pp.101-114[13] Leonardi,M.C. 和M.诉Mauco,将面向自然语言的需求模型集成到MDA中,在:需求工程研讨会论文集(WER),2004年,第10页。六十五比七十六[14] Mellor,S.J.,敏捷MDA,技术报告,Project Technology,Inc.(2005年)。[15] Mellor,S. J.和M. J. Balcer,[16] 模型驱动组织,“Foundationalhttp://portal.modeldriv,org/project/fondationalUML.[17] 诺斯,D.,介绍BDD,Better Software Magazine(2006年3月 ),http://www.stickyminds.com/BetterSoftware/magazine.asp网站。[18]OMG,I. Laz apuzzleetal. /ElectronicNotesinTheoreticalComputerScience264(2010)91105[19] OMG,[20] OMG,[21] OMG,[22] OMG,[23] OMG,[24] OMG,“系统建模语言”,2008年,http://www.omgsysml.org/。[25] OMG,[26] Osis,J.,E. Asnina和A.Grave,MDA中的计算独立建模,在:ICSSTE07会议记录,2007年,第10页。22比34[27] 帕克,S。S. 和F.Maurer,可执行验收测试的好处和挑战,在APOS十九比二十二[28] 帕克,S。S.和F. Maurer,多模态功能测试执行,在:Proceedings 9th International Conference onAgile Processes and eXtreme Programming in Software Engineering(XP 2008),2008。[29] Parv , B. , I. Lazar 和 S. Motogna , ComDeValCo Framework - The Modeling Language forProcedural Paradigm,IJCCC3(2008),pp. 183-195。[30] RSpec,http://rspec.info/。
下载后可阅读完整内容,剩余1页未读,立即下载
cpongm
- 粉丝: 4
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- zigbee-cluster-library-specification
- JSBSim Reference Manual
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功