统一用例方法：UML与敏捷需求实践_张恂著_9787512429888

本书重点介绍了通过采用基于统一建模语言(UML)和用例(Use Case)建模的“统一用例方法”,开展业务分析(包括业务流程与业务对象分析)与系统需求分析(以功能需求为主)的基本方法、流程、步骤与技术。通过可视化的UML图形(如用例图、活动图、序列图和类图等)与基于规范模板的用例交互脚本有机结合,既可以“化繁为简、抓住本质”,又能够保证产品需求描述具有足够的精准度,从而弥补传统敏捷开发仅采用用户故事的许多不足。

本书主要适合各类软件研发团队中与需求分析、产品设计工作相关的产品(或项目)经理、业务与需求分析师、产品与交互设计师、架构师等中高级技术(或技术管理)人员阅读,同时也推荐希望成为专业软件工程师的普通开发人员以及大专院校软件工程相关专业的本科生、研究生与教师阅读。

在过去十多年间的全球软件(包括互联网等)开发界,最令人瞩目、堪称现象级的一场持续风潮大概就属“敏捷开发热”了,其中又以Scrum、XP(极限编程,也译为极端编程)以及Lean(精益)、Kanban(看板)等为代表的敏捷方法与流派最为热门。时至今日,可能很多人仍对当年异常火爆的Scrum 认证热、人们争先恐后地追求Scrum Master证书的场景记忆犹新。这场热热闹闹的敏捷运动带来了各方面有好、有差的许多效应。例如,源自XP的用户故事(User Story)就顺着这股浪潮,成为了一项知名度最高、Scrum+XP开发的缺省配置,可谓“No.1”的敏捷需求技术,同时在坊间也很少或很难听到针对它的任何批评意见。

用户故事的优势显然被高估了,其实际价值远没有各种营销、推广所宣传的那么大。然而,远比用户故事更为强大和实用、传入中国已近二十年的另一项敏捷需求技术———用例(Use Case,也译作“用况”“用案”等)却被普遍忽视了,这不禁令人感到些许遗憾。

于是,就有了本书。

什么是用例?

简单地说,一个“用例”就是对用户使用某个系统功能的具体执行、交互流程的描述,即一个比较完整的“使用故事(Use Story)”。不要以为用例是多么高深、难懂的东西。其实,不管是软件还是硬件,地球上的任何产品、系统(或有使用价值的东西)都有用例,至少一个吧。在产品设计与需求分析的过程中,用例的分析与建模常常从画系统的UML(Unified Modeling Language,统一建模语言)用例图(Use Case Diagram)开始。以下是一个日常生活中的例子,一个最简单的微波炉系统的用例图可描绘如下:

图中的UML椭圆符号“加热食物”所标记的就是一个用例。而一个用例的名称反映了用户针对某个特定系统或产品的一个功能目标,或者系统可为该用户提供的一项有价值的服务。例如,用例“加热食物”,它代表了微波炉的一项基本功能与服务———用户可以利用微波炉来加热食物。这既是一个用户的目标(User Goal),也体现了微波炉作为产品的一项使用价值。

用例图主要用来提取和表示多个用例及其关系,那么一个用例的具体内容又是什么呢?例如,用户应该怎么通过微波炉来加热食物? 正确的使用流程和操作方法是怎样的? 具体有哪些步骤呢? 用比较规范的用例交互脚本来描述“加热食物”,其文本大致是这样的:

1. 用户打开微波炉的电源;

2. 用户打开炉门,把食物放入微波炉,关好炉门;

3. 用户设置火力;

4. 用户设置加热时长;

5. 用户启动微波炉;

6. 微波炉运转加热食物,直到超过用户已设置好的运行时间;

7. 用户在听到微波炉的提示音、停止运转后,打开炉门,取出食物,然后关上炉门;

8. 用户关闭微波炉的电源。

您看,这就是用例(的基本流)———一个用户如何用微波炉“加热食物”的使用故事。在微波炉的用户手册上常常也能看到类似的介绍,形式与内容非常简单,几乎人人都能读懂。用例技术是由来自瑞典的UML创始人、被称为“UML 三友”之一的Ivar Jacobson在20世纪80年代中期发明的。20世纪70—80年代Jacobson曾长期为爱立信公司工作(参与开发程控交换机),他于1992年出版的名著《面向对象软件工程》(OOSE)可谓是用例技术的奠基之作。1995年以后,用例与UML技术一起被整合进了Rational公司的“统一软件开发过程”框架指南RUP(Rational Unified Process)之中。

我第一次接触用例、UML是在1998年。那时由于要带领研发团队,我正式开始学习了包括UML建模在内的软件架构方法与技术,并在RUP的相关文档中看到了用例。说实话,当时我并不太理解一个个的软件需求为什么要写成用例那样,用文本模板来写,还包括若干步骤和字段,感觉有点麻烦。

直到2000年以后,当我认真读完了继Jacobson之后另一位用例大师AlistairCockburn的名著《编写有效用例》之后,才逐渐深刻地体会到,除了描画各种UML统一用例方法: UML与敏捷需求实践图形之外,文本用例与模板对于复杂软件和系统需求分析的巨大价值。

如今自用例诞生,近三十年过去了,业界有哪些著名国际企业一直或仍在使用用例技术呢? 大家熟知的主要包括爱立信、IBM(于2003年收购了Rational)、Oracle、Amazon等公司,涉及通信、IT、互联网等行业。除了这些行业以外,过去这些年我自己也曾经为国内的其他一些行业(如证券、保险、外贸、税务等)中的知名企业或机构讲解过用例技术。虽然总数不算多,但用例技术在许多软件工程比较成熟的研发组织中应用也并不少见。尤其值得一提的是,两大IT巨头这些年主推的企业级开发过程与方法———IBM的RUP与Oracle的OUM(Oracle统一方法)其实都源自于“UML三友”所引领研发的UP(统一过程),而用例驱动开发与可视化(包括UML)建模正是UP方法(家族)的两个基本特征。

这些年在日常软件开发过程中,坊间常用到的需求技术除了用例以外,主要还有特性(Feature)、用户故事等。那么,用例区别于其他需求技术,有哪些独特的优点和价值呢?

用例在本质上,是一种主要用自然语言编写而成的规范、结构化(模板化)的“需求程序(Requirement Program)”,一个比较完整的用例通常包含了名称、前态、后态、基本流、扩展流等若干项内容,主要被用来描述产品(系统或软件)的功能需求及其交互流。因此,用例文本通常也可以称为功能的“用例脚本”或“交互脚本”。在工作与生活中我们常常可以看到许多案例,比如一件产品在使用、功能、交互等方面,其设计细节,往往会直接影响到它的易用性与用户体验。如果是一个复杂、上规模的软件密集型的大中型产品或系统,则常常包含了大量的需求或交互细节,要想及时、准确地发现和处理这些细节常常既费时又费力。“细节决定成败,细节是魔鬼”,众所周知的这些谚语说明了简单的事实和道理。

研究UML与用例技术多年,我的体会是:与特性、用户故事等其他需求技术相比,用例方法与技术的最大价值就在于通过其设计科学、系统、合理、规范的文本模板与相应的分析过程和技巧,可以帮助产品的设计师(或需求分析师等)能够有条不紊地把各种复杂、潜藏、难以发现和理解的需求及交互细节逐步挖掘出来,并梳理、表达清楚,从而尽最大可能不遗漏(甚至可以提前预见到)那些关键的、对开发成败具有重要影响的需求。

不仅如此,用规范、格式化的用例脚本结合更加形象、直观的UML图形联合建模,可以更加积极、有效地应对常见的需求难题(比如管理好各种需求细节,妥善应对需求变化等),这也是“用例+UML”方法相较于其他需求方法所具有的一项明显简单一句话,用例与UML建模的主要价值可以概括为:基于其他需求方法所欠缺的———流程化与结构化(需求程序)的书面描述方式(包括文本与图形建模等),可以更加精准、有效地发掘、记载和管理好复杂的需求与交互细节,做到化繁为简、抓住本质。

相信读完本书并经过一段时间的实践之后,您大概也会有类似的体会。可以说,用例(与UML)建模是自1990年代以来现代软件工程中最重要的需求技术(之一),在驱动并保障各类复杂产品、系统与软件的成功开发中发挥了独特的价值和重要的作用,用例分析作为当代软件与系统需求分析的一项重点(或核心)技术是当之无愧的。

敏捷方法传入中国也快二十年了,然而对于敏捷需求技术,坊间一直广泛流传着许多似是而非的观点或误解,例如:用户故事是敏捷的,用例是不敏捷的;用户故事比用例更好、更先进;Scrum 必须用用户故事,不能用用例。莫非自敏捷运动兴起以来,用例就真的已经过时、落后了,应该被用户故事所淘汰了吗?

非也。

前面提到的以实用用例技术而闻名的Alistair Cockburn,不但是当年组建敏捷联盟与签署《敏捷宣言》的主创成员之一,而且同时也是敏捷方法水晶(Crystal)流派的创始人,他对于肯定用例在敏捷开发中的重要价值以及优先采用用例的主张与态度可以说是非常坚定和一贯的。而另一位知名的敏捷与极限编程专家Martin Fowler对“用例与用户故事之争”也持有相对中立的立场。他曾经提到,在敏捷开发实践中用例与用户故事两者既可以结合一起使用,也可以分开单独使用(要么只用用例,要么只用用户故事),不同的团队可根据自己的实际情况进行选择。

事实上,用户故事只是一项源于XP的专用技术,而Scrum 作为一个更加开放、简约的敏捷、迭代开发框架,其本身几乎不含任何技术实践,因而对于采用哪种需求技术也是持中立的态度。成功的Scrum 团队既可以采用用户故事,也可以采用用例(故事),而具体采用哪种技术应该由每个团队在实践中因地制宜、按需(价值最大化、风险最小化)来配置。

此外,在用例编写与建模的过程中,我们可以根据敏捷开发的实际需要,采用各种不同的、从简单到复杂的描述形态,例如从用例名称、用例图,到用例简述,以及UML的活动图、交互图,乃至更加全面、详尽的用例脚本等。可见,用用例来描述需求,既可以比用户故事更简单、方便,也可以比用户故事更复杂和完善(比如达到测试级的精准度)。

所以,用例分析是一项灵活、实用、适用面非常广的敏捷需求技术,它对于当代软件工程与下一代敏捷开发(如Agile 2)的价值与潜力还远未被业界所真正、广泛地认识到。

经过多年的发展与演化,目前用例方法与技术尚存在着几个竞合流派(如Jacobson和Cockburn等),虽然它们大同小异且都出自同一个源头,但是在一些具体的技术细节(包括术语解释和用法等方面)上仍存在着不少差异;而且,尽管利用UML等标准图形符号来描述用例这部分早已经标准化了,但是用例文本模板至今还没有出现一个像UML那样被业界广泛认同的国际标准与正式规范。

以上这些情况导致坊间长期一直存在着形态各异的多种用例模板或格式,给专业人士阅读、理解和交流、分享用例脚本与系统需求及其相关知识带来了不少困扰。因此,在日常需求工作中,如何仔细甄别各个流派方法的异同,有效地作出技术决策与取舍以获得运用用例技术的最佳收益,成为产品设计、需求分析相关领域的实践者们必须面对的一个现实问题。

本书根据笔者自2000年以来在用例与UML建模、需求分析与敏捷开发方法的培训教学、咨询等方面的研究与实践经验,提出并重点介绍了整合用例、用户故事与特性等当代主流需求技术的统一用例方法(UUCM,a Unified Use Case Method),以扬长避短、兼收并蓄,消除或减少各流派方法之间的不一致性和分歧,更好地促进“用例+UML”等分析与建模技术在下一代敏捷开发中的应用。

本书共分为7章。

第1章“产品与需求工程”作为全书的开篇,回顾了与产品需求分析相关的一些基本概念和知识,并简要介绍了用例分析在产品、系统或软件开发与需求工程中的关键位置和重要价值。

第2章“敏捷需求方法”是对全书主要内容的综述。首先回顾了敏捷开发的起源,介绍了敏捷体系结构,以及以用户故事为代表的敏捷需求实践的现状;然后,介绍了以用例为代表的成熟功能需求分析方法对于敏捷产品设计与交互设计的重要价值;最后,简要介绍了在16字“太极建模口诀”(由外而内,层次分明;动静结合,逐步求精)的指导下,基于用例与UML建模的统一用例方法的基本工作流程和步骤。

第3~6章是本书的重点。建议对用例、UML不太熟悉的读者先阅读第3~4章“用例基础”与“UML 基础”,以便对需求分析时常用到的用例与UML的一些基本概念、元素和技巧等内容有一个大致的了解。

第5章“业务分析”,介绍了通过基于用例与UML建模的业务分析方法建立产品的业务模型(主要包含“一动一静”业务流程与业务对象两个子模型)的基本流程、步骤和技巧,重点是如何利用业务用例图提取业务流程,以及如何通过绘制UML活动图和序列图来详细分析业务流程。该章最后还简要介绍了用UML类图建立业务对象模型的基本方法。

第6章“系统需求分析”,详细介绍了通过基于用例与UML建模的系统需求分析方法建立系统需求模型(主要包含“一动一静”用例模型与非功能需求集两个部分)的基本流程、步骤和技巧,重点是介绍如何通过编写格式规范、清晰易读的用例(交互)脚本来尽量精准地描述复杂的系统功能需求及其细节。当然,对于一些简单的系统功能,也可以不必编写详细的用例脚本,而是通过画UML图(如用例图、活动图、序列图)或者编写特性清单等更加轻量的方式来表示。

......

你还可能感兴趣

我要评论