新書推薦：
《
一个人·谁也不是·十万人（诺贝尔文学奖得主反思自我的巅峰之作）
》
售價：NT$
250.0
《
重写晚明史（全5册 精装）
》
售價：NT$
3560.0
《
汉末晋初之际政治研究
》
售價：NT$
602.0
《
强者破局：资治通鉴成事之道
》
售價：NT$
367.0
《
鸣沙丛书·鼎革：南北议和与清帝退位
》
售價：NT$
551.0
《
从康德到黑格尔的发展：兼论宗教哲学（英国观念论名著译丛）
》
售價：NT$
275.0
《
突破不可能：用特工思维提升领导力
》
售價：NT$
352.0
《
王阳明大传：知行合一的心学智慧（精装典藏版）
》
售價：NT$
1010.0
|
| 編輯推薦： |
本书重点介绍了在当代敏捷开发过程中,采用基于图形符号的UML与基于文本模板的用例故事建模来进行产品的业务分析与系统需求分析的一些基本方法、步骤与技巧,而贯穿始终的是太极建模口诀由外而内,层次分明;动静结合,逐步求精。
本书所采用的用例模板书写格式,吸收、借鉴了Jacobson、UP、Cockburn等流行用例模板的优缺点,引入了关键词、可嵌套执行块等多个创新的语法特征,从而使得用例文本看上去像是一种更加清晰、易读的需求程序,并且在此基础上有可能形成一种统一、规范的用例描述语言UCL,暂定名。
|
| 內容簡介： |
本书重点介绍了通过采用基于统一建模语言UML和用例Use Case建模的统一用例方法,开展业务分析包括业务流程与业务对象分析与系统需求分析以功能需求为主的基本方法、流程、步骤与技术。通过可视化的UML图形如用例图、活动图、序列图和类图等与基于规范模板的用例交互脚本有机结合,既可以化繁为简、抓住本质,又能够保证产品需求描述具有足够的精准度,从而弥补传统敏捷开发仅采用用户故事的许多不足。
本书主要适合各类软件研发团队中与需求分析、产品设计工作相关的产品或项目经理、业务与需求分析师、产品与交互设计师、架构师等中高级技术或技术管理人员阅读,同时也推荐希望成为专业软件工程师的普通开发人员以及大专院校软件工程相关专业的本科生、研究生与教师阅读。
|
| 關於作者： |
|
张恂，东南大学计算机科学与工程系本科与硕士毕业。作为一名面向对象技术与敏捷软件工程（Agile 2）领域的资深教练，长期从事现代软件工程与敏捷方法、对象技术的应用开发、管理、咨询和推广工作，具有二十年以上软件开发的丰富经验和扎实的理论功底。曾担任国内著名通信企业大型移动通信系统研发架构师和软件工程项目经理，软件公司 CTO、业务总监和副总经理等职务，具有高科技上市企业、民企和外企的丰富工作经验。
|
| 目錄：
|
第1章 产品与需求工程1
1.1 产品、系统与软件1
1.2 需 求4
1.2.1 需求的种类 4
1.2.2 常用需求表示法 9
1.3 需求工程12
1.3.1 需求的重要性12
1.3.2 主要的内部需求干系13
1.3.3 需求过程18
1.3.4 需求质量22
1.4 小 结26
第2章 敏捷需求方法 27
2.1 敏捷开发述评28
2.1.1 敏捷体系28
2.1.2 敏捷需求实践34
2.2 敏捷的产品设计36
2.2.1 产品需求文档37
2.2.2 产品模型39
2.2.3 交互设计41
2.3 统一的敏捷需求流程45
2.3.1 太极建模口诀45
2.3.2 业务分析流程50
2.3.3 系统需求分析流程56
2.4 小 结63
第3章 用例基础 64
3.1 用例简介64
3.2 什么是用例66
3.3 用例文本范例67
3.4 用例名称70
3.5 用例简述71
3.6 范围与类型71
3.7 用角与干系者72
3.7.1 主用角73
3.7.2 辅用角73
3.7.3 其他干系者74
3.7.4 Actor的译法 74
3.8 层 级77
3.8.1 概要目标层79
3.8.2 用户目标层 79
3.8.3 子功能层81
3.8.4 WhyHow关系83
3.8.5 粒度是否存在84
3.9 交互流86
3.9.1 前 态86
3.9.2 后 态87
3.9.3 触发事件89
3.9.4 基本流89
3.9.5 基本写作技巧90
3.9.6 辅助构造97
3.9.7 扩展流99
3.9.8 流控制保留词 102
3.10 用例编写的常见错误103
3.11 小 结103
第4章 UML基础 105
4.1 UML简介 105
4.1.1 简 史105
4.1.2 用 途 106
4.1.3 基本内容 107
4.1.4 UML工具 109
4.2 动态图 110
4.2.1 用例图 111
4.2.2 活动图 122
4.2.3 序列图 128
2
统一用例方法： UML与敏捷需求实践
4.3 静态图 136
4.3.1 对象图 137
4.3.2 类 图138
4.3.3 包 图 144
4.4 扩展机制 145
4.4.1 关键词 145
4.4.2 版 型 145
4.4.3 约 束 146
4.4.4 扩 集147
4.5 小 结 147
第5章 业务分析149
5.1 分析流程概述150
5.1.1 主要任务 150
5.1.2 主要角色 152
5.1.3 主要工件 153
5.2 确定业务边界154
5.3 业务用角分析155
5.3.1 抽象的角色 155
5.3.2 提取业务用角 156
5.3.3 业务用角的属性 158
5.3.4 业务用角图 158
5.4 提取业务流程 158
5.4.1 分析业务用角目标 159
5.4.2 重点业务用例图 160
5.4.3 与系统用例的区别与联系 160
5.4.4 业务用角用例图 162
5.4.5 特殊的业务用例 162
5.4.6 核心业务用例包 164
5.5 业务流程分析165
5.5.1 业务用例实现 165
5.5.2 UML建模 166
5.6 业务对象分析 185
5.6.1 领域分析与建模 186
5.6.2 基本步骤 187
5.6.3 主动对象建模191
5.7 业务模型分析 192
5.7.1 模型的结构与组织 193
5.7.2 业务模型评审 196
5.8 小 结 197
第6章 系统需求分析199
6.1 分析流程概述 199
6.1.1 主要任务 200
6.1.2 主要角色201
6.1.3 主要工件 202
6.2 确定系统边界 205
6.2.1 术语澄清 206
6.2.2 BoS与BoB的联系与区别 206
6.2.3 一个常见的误解207
6.3 用角分析 208
6.3.1 主辅用角 209
6.3.2 提取用角 209
6.3.3 用角属性 210
6.3.4 用角图 210
6.4 提取用例 211
6.4.1 直接分析用角目标 211
6.4.2 从业务模型中提取用例 214
6.4.3 由系统发起的用例 220
6.4.4 组织用例包 220
6.4.5 提取用例不同于传统功能分解 224
6.4.6 特性列表225
6.5 用例分析227
6.5.1 设置基本属性 228
6.5.2 画动态图 229
6.5.3 编写交互脚本 235
6.5.4 补充包含与扩展用例 261
6.5.5 用例评审 267
6.6 用例模型分析 268
6.6.1 模型的组织 269
6.6.2 何时算完成 271
6.7 NFR分析272
6.7.1 主要内容 272
6.7.2 补充需求规约273
6.7.3 数据需求与领域分析 274
6.8 系统需求模型评审 276
6.9 小 结 277
第7章 两个故事278
7.1 用户故事简介 278
7.2 两个故事比较 280
7.2.1 生命期 280
7.2.2 完全性 281
7.2.3 粒 度 282
7.2.4 用 途284
7.2.5 与用例简述比较 285
7.2.6 偏等价性287
7.3 用户故事的优点 289
7.3.1 优点一： 对话优先 289
7.3.2 优点二： 适宜做计划 292
7.3.3 优点三： 推迟确定细节 294
7.3.4 其他优点 295
7.4 用户故事的缺点296
7.4.1 缺点一： 不完整 296
7.4.2 缺点二： 不正规297
7.4.3 缺点三： 不鼓励建模 297
7.4.4 缺点四： 不可追溯 298
7.5 小 结298
结 束 语300
参考文献302
|
| 內容試閱：
|
在过去十多年间的全球软件包括互联网等开发界,最令人瞩目、堪称现象级的一场持续风潮大概就属敏捷开发热了,其中又以Scrum、XP极限编程,也译为极端编程以及Lean精益、Kanban看板等为代表的敏捷方法与流派最为热门。时至今日,可能很多人仍对当年异常火爆的Scrum 认证热、人们争先恐后地追求Scrum Master证书的场景记忆犹新。这场热热闹闹的敏捷运动带来了各方面有好、有差的许多效应。例如,源自XP的用户故事User Story就顺着这股浪潮,成为了一项知名度最高、Scrum XP开发的缺省配置,可谓No.1的敏捷需求技术,同时在坊间也很少或很难听到针对它的任何批评意见。
用户故事的优势显然被高估了,其实际价值远没有各种营销、推广所宣传的那么大。然而,远比用户故事更为强大和实用、传入中国已近二十年的另一项敏捷需求技术用例Use Case,也译作用况用案等却被普遍忽视了,这不禁令人感到些许遗憾。
于是,就有了本书。
什么是用例?
简单地说,一个用例就是对用户使用某个系统功能的具体执行、交互流程的描述,即一个比较完整的使用故事Use Story。不要以为用例是多么高深、难懂的东西。其实,不管是软件还是硬件,地球上的任何产品、系统或有使用价值的东西都有用例,至少一个吧。在产品设计与需求分析的过程中,用例的分析与建模常常从画系统的UMLUnified Modeling Language,统一建模语言用例图Use Case Diagram开始。以下是一个日常生活中的例子,一个最简单的微波炉系统的用例图可描绘如下：
图中的UML椭圆符号加热食物所标记的就是一个用例。而一个用例的名称反映了用户针对某个特定系统或产品的一个功能目标,或者系统可为该用户提供的一项有价值的服务。例如,用例加热食物,它代表了微波炉的一项基本功能与服务用户可以利用微波炉来加热食物。这既是一个用户的目标User Goal,也体现了微波炉作为产品的一项使用价值。
用例图主要用来提取和表示多个用例及其关系,那么一个用例的具体内容又是什么呢?例如,用户应该怎么通过微波炉来加热食物? 正确的使用流程和操作方法是怎样的? 具体有哪些步骤呢? 用比较规范的用例交互脚本来描述加热食物,其文本大致是这样的：
用户打开微波炉的电源;
用户打开炉门,把食物放入微波炉,关好炉门;
用户设置火力;
用户设置加热时长;
用户启动微波炉;
微波炉运转加热食物,直到超过用户已设置好的运行时间;
用户在听到微波炉的提示音、停止运转后,打开炉门,取出食物,然后关上炉门;
用户关闭微波炉的电源。
您看,这就是用例的基本流一个用户如何用微波炉加热食物的使用故事。在微波炉的用户手册上常常也能看到类似的介绍,形式与内容非常简单,几乎人人都能读懂。用例技术是由来自瑞典的UML创始人、被称为UML 三友之一的Ivar Jacobson在20世纪80年代中期发明的。20世纪7080年代Jacobson曾长期为爱立信公司工作参与开发程控交换机,他于1992年出版的名著《面向对象软件工程》OOSE可谓是用例技术的奠基之作。1995年以后,用例与UML技术一起被整合进了Rational公司的统一软件开发过程框架指南RUPRational Unified Process之中。
我第一次接触用例、UML是在1998年。那时由于要带领研发团队,我正式开始学习了包括UML建模在内的软件架构方法与技术,并在RUP的相关文档中看到了用例。说实话,当时我并不太理解一个个的软件需求为什么要写成用例那样,用文本模板来写,还包括若干步骤和字段,感觉有点麻烦。
直到2000年以后,当我认真读完了继Jacobson之后另一位用例大师AlistairCockburn的名著《编写有效用例》之后,才逐渐深刻地体会到,除了描画各种UML统一用例方法： UML与敏捷需求实践图形之外,文本用例与模板对于复杂软件和系统需求分析的巨大价值。
如今自用例诞生,近三十年过去了,业界有哪些著名国际企业一直或仍在使用用例技术呢? 大家熟知的主要包括爱立信、IBM于2003年收购了Rational、Oracle、Amazon等公司,涉及通信、IT、互联网等行业。除了这些行业以外,过去这些年我自己也曾经为国内的其他一些行业如证券、保险、外贸、税务等中的知名企业或机构讲解过用例技术。虽然总数不算多,但用例技术在许多软件工程比较成熟的研发组织中应用也并不少见。尤其值得一提的是,两大IT巨头这些年主推的企业级开发过程与方法IBM的RUP与Oracle的OUMOracle统一方法其实都源自于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图如用例图、活动图、序列图或者编写特性清单等更加轻量的方式来表示。
最后,在第7章两个故事中,我们对Scrum XP团队常用的用户故事技术的优缺点作了比较深入的分析,并且对用户故事与用例故事这两种故事的异同作了对比,得出的结论是两者具有某种偏等价性,即用户故事所能描述的内容、发挥的作用用例故事基本上也可以做到,因而在除了采用XP之外的敏捷开发过程中,后者通常可以取代前者,而反之则不行。
请注意,Use Case在本书中除了被译为用例外,有时也被称为用例故事,两者完全等价,可自由替换,这是因为用例本来就是一种书面、规范的系统使用或交互故事,而且历史上比用户故事出现得更早,其形式与内容也比后者更加完备。不过本书的用例故事不同于Ivar Jacobson在其提出的新版Use Case 2.0中所描述和采用的术语用例故事Use Case Story,请勿混淆。
本书适合哪些读者阅读
本书主要适合各类软件研发团队中与需求分析、产品设计工作相关的产品经理、项目经理、业务分析师、需求分析师、产品设计师、交互设计师以及架构师和测试师等中、高级技术或技术管理人员阅读。当然,也建议希望今后成为高级程序员、专业软件工程师或架构师的普通开发人员阅读,毕竟需求分析是高级尤其敏捷开发人员必备的一项重要技能,应当熟练掌握。
本书所采用的主案例是大家日常都很熟悉的B2C电商网站业务包括购物、下统一用例方法： UML与敏捷需求实践订单等,为此虚构了一家宠物店公司及其网站,基本不涉及其他行业、领域中一些很专业、难懂的概念或知识,所以对于书中所举例的业务流程、系统需求等各项内容,普通读者也应该很容易理解,没什么难度。
总之,无论你们团队目前采用的是相对传统的软件工程方法,还是这些年比较流行的敏捷方法,相信本书所介绍的统一用例方法对于继续改进您个人或团队的需求分析工作、提升需求质量,或多或少都会有一些启发或切实的帮助。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
