作者：邱郁惠
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
系统分析师UML项目实战试读：
前言
缘起很多学员和读者跟我说，他们在书店里、在网络上看到很多关于UML的书籍或文章，一百篇中有一百零一种说法。我能够体会那种众说纷纭的无所适从，或许我们得试着勇敢地抛开所有的说法，认同一个自己能够安身立命、简单遵循的道路。我是这么想的！
回顾我出版第1本UML书——《写给SA的UML/MDA实务手册》（天珑销售第1名），至今为止已经5年了。这5年来，我拿着那本小书的概念到实务界又跑了一圈，有了更多的体验和心得，于是决定潜下心来，再度将这些年来参与项目的所看、所想记录下来，因此有了这本新书的诞生。本书目的
本书关注系统分析师在UML项目现场如何现学现用立即使用活动图、用例图（及用例叙述）、类图，来呈现业务流程、用例以及领域模型。再者，也希望团队成员可以人手一书，作为使用者/客户（甲方）、构建团队/绘制者/观看者（乙方）、独立监审商（丙方）等多方沟通UML概念的基石。本书的内容结构
第1部分 简介。
第1章 UML项目现场。在UML项目现场，限制团队成员使用最少量的UML概念和图标，训诫团队成员采用相同的作业程序，通过牺牲一些自由与创意，或许可以换取团队成员以最快速度齐步向前走，强力挺进UML项目现场。
第2部分 建模。
第2章 业务流程建模。使用UML的活动图（Activity Diagram），表达系统构建之后所支持的新业务流程。
第3章 用例建模。使用UML著名的用例图（Use Case Diagram）以及用例叙述（Use Case Narrative），来呈现用户与系统互动以获取产品或服务的过程。
第4章 领域建模。使用UML的类图（Class Diagram）表达问题领域中的重要实体，以及实体的属性、操作、限制、角色和关系，用来作为系统内部重要的业务核心。
第3部分 模型走读。
第5章 模型走读。程序设计师在编写完程序代码、交付之前，可以先进行人工的“代码走读”（code walkthrough），以便确保程序代码的质量。同样，系统分析师在做完每一个用例，并且将用例涉及的领域概念也同步提取汇总到领域模型之后，也是可以学习代码走读的精神，也来先进行人工的“模型走读”（model walkthrough）。
第6章 继续走读。经过之前的模型走读，修正了一些内容，也与领域专家又做了一次深度的沟通。所以，在本章中，我们将汇总并额外补上一些疏漏的内容。
第4部分 范例。
第7章 基金系统范例。本章内容除汇总第2章到第6章关于基金系统的分析内容外，还会额外补充一些说明和其他分析内容，不过不会再有更多的理论论述。
第5部分 附录。
附录 AUML官方认证。我发现很多人不知道UML有官方认证，事实上，美国OMG协会（http://www.omg.org）于2003年提出了初级、中级和高级3个等级的UML官方认证（http://www.omg.org/uml-certification/index.htm）。所以，本附录会为有兴趣考取UML认证的读者，简单介绍一下UML官方认证。
附录 B成本估算。成本估算一直都是件难事，参考过去流行的“功能点”（Function Point）估算，学者Gustav Karner 提出了“用例点”（Use Case Point）估算来搭配面向对象技术。本附录会简单提到用例点估算公式以及相关的参考文献。本书采用的UML工具
本书范例都采用StarUML绘制。StarUML最大的特色，就是免费且开源（open source）。如果读者不想花钱去买庞大复杂的UML工具的话，试试这套免费又简单的工具，或许您会跟我一样，一试成主顾！您只要访问StarUML（http://staruml.sourceforge.net/en/）网站，就可以免费下载StarUML执行文件以及别人贡献的免费配件了。邱郁惠（271080@gmail.com）UMLBlog（http://www.umltw.com）
作者简介
邱郁惠，中国台湾资深UML专家和畅销书作者。邱老师研究OOAD、UML和MDA十余年，自UML诞生起一直从事UML的普及和指导工作，从事过专案、教学及写作。曾担任《物件导向杂志》主编，编著有《系统分析师UML实务手册》、《C++程序员UML实务手册》、《SOC设计UML实务手册》，其繁体版一经出版即攀升至天珑书局销售排行首位。
邱老师多年来从事UML认证培训工作。她目前拥有OCUP（OMG-CertifiedUMLProfessional）三级认证、PMP（Project Management Professional）认证、ITIL V3Foundation认证、IBM OOAD（Object Oriented Analysis and Design）认证、Scrum Master认证。
本书是作者2010年回归软件开发企业界后，结合这几年的软件项目实践编写的最新力作。
献辞
这本书要献给我的家人、丈夫和小孩没有他们在我背后支持，我和我写的这些书恐怕难见天日
第1章 UML项目现场
IKEA的创办人英格瓦·坎普拉（Ingvar Kamprad）常把“简单是一种美德”这句话挂在嘴边。他经常告诫大家：“只有平庸的人，才会提出复杂的解决方案。”
同样地，在UML项目现场，保持简单使用UML也是一项值得赞许的美德。或许，我们真要借用坎普拉的话来提醒自己：“只有平庸的团队，才会把UML用得既复杂又困难。”
因此，在UML项目现场，限制团队成员使用最少数量的UML概念和图标，告诫团队成员采用相同的作业程序，通过牺牲一些自由与创意，或许可以换取团队成员以最快速度齐步向前走，挺进UML项目现场。
1.1 现场的作业程序
在系统分析师的现场作业中，跟UML有关的产出及作业程序主要有3项，分别如下。
1．业务流程建模——使用UML的活动图（Activity Diagram）表达系统构建后所支持的新业务流程。建议的现场作业程序，如图1-1所示。
2．用例模型——使用UML著名的用例图（Use Case Diagram）以及用例叙述（Use Case Narrative），来呈现用户与系统互动以获取产品或服务的过程。建议的现场作业程序，如图1-2所示。
3．领域模型——使用UML的类图（Class Diagram）表达问题域（problem domain）中的重要实体（entity），以及实体的属性（attribute）、操作（operation）、限制（constraint）、角色（role）和关系（relationship），用来作为系统内部重要的业务核心。建议的现场作业程序，如图1-3所示。图1-1 业务流程建模的作业程序图1-2 用例建模的作业程序图1-3领域建模的作业程序
1.2 现场使用的图标
目前最新版的UML2有14种图，系统分析师只需要从中取用3种图，分别为活动图、用例图和类图。但是，即便如此，每一种图中也包含了数十个概念和图标。
由于每一个图标就是一个可以用来沟通的词汇，所以有必要进一步限制这3种UML图中可以被团队拿来使用的图标，以便缩减团队成员的学习成本与沟通成本。因此，我们限制团队成员只能够使用表1-1、表1-2和表1-3所明确列出的图标。表1-1 活动图图标表1-2 用例图图标表1-3类图图标
除此之外，如果系统分析师需要引进任何一个图标，都需要向项目经理申请，并且邀请所有系统分析师开讨论会议，以共同决议是否采用，同时需要对新采用的图标的定义、使用时机有基本的共识。这样一来，才不会出现系统分析师说着其他成员不甚了解的词汇，而独自一人喃喃自语的窘境！
第2章 业务流程建模
2.1 UML项目现场
在UML项目现场，系统分析师可以发现活动图（Activity Diagarm）经常用来表示下列3种流程。■ 业务流程（Business Process）■ 系统流程（System Process）■ 操作流程（Operational Process）
根据我的项目经验，建议如果要构建的系统并没有明显涉及业务流程，其实没有必要硬是生成活动图。当然，如果遇到构建的系统明显涉及复杂的业务流程，最好采用活动图来表示业务流程，这可以带来下列几项好处。
1．系统分析师可以通过活动图与用户或客户沟通，并确认未来系统上线之后的业务流程。
2．系统分析师可能需要通过活动图中的流程和控制节点，来表示用例执行时的流程与逻辑控制。
3．系统分析师也可以通过活动图，找出可能遗漏的用例（Use Case）。
其实，多数项目时间都压缩得很厉害，绘制每一款或每一张UML图都要花时间、花成本，实在没有必要为了需要交付分析设计文件，硬是绘制了一堆UML图。
再者，UML是一种用来沟通的图形语言，假如在使用任何一个图标（词汇）时，客户/用户（甲方）、构建团队/绘制者/观看者（乙方）、独立监理商（丙方）等多方没有一定水平的共同认知的话，UML就失去了沟通的功效，而且还可能会成为项目成员熬夜加班的原因之一。
因此，本章（或本书）仅聚焦在时，系统分析师在UML项目现场时，如何依样画葫芦、现学现买、立即使用活动图来表示重要的业务流程。此外，更希望团队成员可以人手一书，作为沟通UML/SA概念的基石。
2.2 业务流程
2.2.1 定义
Wiki百科对业务流程的定义如下。
Wiki 百科对于“Business Process”（业务流程）的定义，十分简单明了、容易理解，此处我们就不客气地直接引用了。从这段定义中，我们可以归纳出业务流程的几个重点如下。■ 业务流程主要由一组相关的活动（activity）或任务（task）所组
成。■ 每一条业务流程通常会有一个特定的目标（goal）。■ 企业或组织在执行完业务流程之后，会提供特定的服务（service）或生成特定的产品（product）（即达到了特定的目
标）。■ 业务流程之所以设立特定的目标，经常是为了给某一个或者某一
群特定的客户（customer），提供一项具体且能够被评价的服务
或产品。
最后，我们通过思维导图（mind map）来表示上述的重点，善用图像，可以帮助我们加深印象、强化记忆，如图2-1所示。图2-1 业务流程的定义（思维导图）
2.2.2 现场问题
在对业务流程的定义有一点点初步的共识后，我们紧接着来看在UML项目现场中，系统分析师在动手绘制活动图之前，经常会遇到哪些现场问题，而且又该如何处置呢？如图2-2所示。图2-2 业务流程的现场问题（思维导图）2.2.2.1 绘制？或不绘制？
一直以来，我都是非常建议系统分析师，在分析阶段抽一些时间来绘制活动图。不过，这样的建议，在UML项目现场也是经常出现不适用的例外情况。
我曾经参与过两个大型项目，项目下面当然包含了十多个，甚至数十个子系统，这两个项目不约而同地都规划了一个用来维护共享数据的子系统。诸如此类的公用系统，通常只支持非常片段的业务流程，想要从中找出完整的业务流程可能并不恰当。如果硬是强求系统分析师在这种情况下绘制活动图的话，很可能最后就会变成使用活动图来描述系统流程或操作流程了。
注意除了我们此处提到的维护数据类型的公用系统外，您在UML项目现场中，也可能发现其他什么类型的系统存在这种情况：其实无需花费项目时间和成本，特别使用活动图去绘制无关紧要的业务流程。
在很多大型的项目中，客户/用户（甲方）会在合约上严格规定构建团队（乙方）需要交付的那些文件。特别是在重要的系统需求规格书（SRS，System Requirement Specification）及系统设计规格书（SDS，System Design Specification）中，客户/用户有时还会一并规范了文件的目录章节，想要以此来管理系统分析师与系统设计师（乙方）的作业和生成。
而且，这样的文件规范通常会整体适用，不会因为某些系统无明显业务流程，就特别删去相关章节。所以，系统分析师若遇到这类无明显业务流程的系统时，可以秉持着自身的专业素养，与客户/用户（甲方）和独立监理商（丙方）沟通协调，省略这项工作及产出，不要把生命浪费在这种无谓的文件上头。
注意很多时候，客户/用户（甲方）可能不怎么懂UML，独立监理商（丙方）则可能不懂领域（domain）。在这种情况下，甲方或丙方可能都不易判断出何时无需绘制业务流程，这时身处其中的系统分析师（乙方）就可以跳出来，以其专业与客户/用户（甲方）和独立监理商（丙方）沟通协调。2.2.2.2 未来流程？或现行流程？
系统分析师要是经过了第一个现场问题，确定要采用活动图绘制业务流程之后，可能会遇到的第二个现场问题是，需要绘制未来的业务流程还是现行的业务流程，如图2-3所示。图2-3现行流程或未来流程（思维导图）
理想情况，我们希望先绘制一份现行的业务流程，然后再绘制另一份未来的业务流程。这样，除了可以让相关人员看到系统上线前后业务流程的差异，也可以显示构建新系统所带来的便利与价值。
不过，理想归理想、理论归理论，在UML项目现场是非常现实的，一分一秒都在烧钱，所有的工作或生成总是能省略就省略，能删除就删除。如果在UML项目现场少了某项工作或生成也无伤大雅的话，那就是跳过，删掉，不做。
换句话说，在UML项目现场中，系统分析师若决定要采用活动图绘制业务流程的话，就请直接绘制系统构建之后的未来流程吧！别花时间绘制即将过时的现行流程了。2.2.2.3业务流程？或系统流程？
系统分析师在UML项目现场可能会遇到的最后一个问题是，到底该用活动图来绘制未来的业务流程，还是绘制上线系统的内部流程呢？在钱要花在刀口上，而且项目时间永远都要压缩的情况下，这个问题的答案其实不言而喻。我们当然会建议系统分析师使用活动图，来绘制企业组织未来的业务流程，而非系统内部的系统流程，如图 2-4所示。图2-4 现场问题（思维导图）
不过，此处我们首先要澄清一点，就是在UML规格书中其实并没有限制活动图只能用来表示业务流程，或者不能用来表示系统内部的系统流程。活动图到底要用来表示什么样的流程，完全取决于绘制者。但是，有时候，绘制者自己也不太清楚自己到底该拿活动图表示哪个层级（业务或系统）的流程，甚至有时候也会出现不分层级、混杂在一起使用的情况。
所以，如果系统分析师在UML项目现场，发现用户/客户（甲方）、构建团队（乙方）和独立监理商（丙方）三方可能各说各话或是没有共识时，我会建议系统分析师翻出下面的表2-1，甚至把这张表做成幻灯片，用来说明并取得甲、乙、丙三方的共识。表2-1 活动图用于表示业务流程或系统流程
其实，针对UML/SA的所有概念，最好都可以取得用户/客户（甲方）、构建团队（乙方）和独立监理商（丙方）三方的共同认知，这样三方才能协同工作，如图2-5所示。
最后，我们再回过头来看系统流程这个议题。当然，系统流程也是十分重要的，不过是否该要求系统设计师使用活动图来表示系统流程，这可能有协商讨论的空间。
实际上，我们通常会要求系统设计师在系统设计时间，针对每一个用例对应生成一张或多张的顺序图（Sequence Diagram），用来表示系统内部一群对象实现用例的互动情况。具体来说，系统设计师可以绘制顺序图来表示程序执行时，依次调用（call）多个方法（method）或函数（function）的动态运行情况。图2-5 三方协同工作
不过，说是这样说，我在UML项目现场其实也是经常遇到客户/用户（甲方）要求构建团队的系统设计师（乙方）必须在系统设计规格书（SDS）中，同时绘制活动图和顺序图，前者表示系统流程，后者表示对象互动。当然，活动图与顺序图两者各有优缺点，你可以看一下表2-2的比较表。表2-2 于系统设计时间的活动图与顺序图
理想情况是，针对系统流程较复杂的用例，要求系统设计师同步生成表示系统流程的活动图，但是不要针对每一个用例，都要求生成活动图。顺便一提的是，针对每一个用例，通常会要求系统设计师生成一张或多张的顺序图，这已经属于系统设计时间的事情，所以我们就此打住，不再多谈。
2.3 现场的作业程序
我在担任项目的UML/SA顾问时，通常会直接提出如图2-6所示的作业程序。图2-6 作业程序
1．系统分析师使用活动图，绘制系统上线后的未来业务流程。
2．系统分析师在生成活动图之后，举行确认会议，邀请客户/用户到场修订并确认业务流程的内容。
3．在举行过确认会议之后，系统分析师还需要生成支持业务流程的初版用例图（不含用例叙述）。
上述的第二步骤举行确认会议，其实是相当重要的，建议系统分析师在会议开始的前一周，就先将业务流程的电子文件（或纸本）交付给相关的用户/客户，让相关人员能够在会议之前有时间先看过数据。
系统分析师要特别注意，用户/客户本身也有很多业务要做，通常不怎么愿意在构建团队上花太多时间。所以，系统分析师要把握用户/客户参与会议的难得机会，尽量在会议当场就邀请用户/客户加入，协同修改出有共识且经过确认的未来业务流程。
再者，有时候，用户/客户（甲方）在心态上也会认为自己是花了大钱请构建团队（乙方）来做事的，所以不见得会好声好气地对待构建团队。在这种不太对等的关系中，系统分析师绝对要把握时机，赶紧跟用户/客户把系统上线之后的未来业务流程确认下来。
2.4 现场使用的图标
在这一小节中，系统分析师可以跟着我们一步一步地，一边学习一边绘制出表示业务流程的活动图。
2.4.1 起始节点
一张活动图用来表示一条业务流程，并以活动图中的起始节点（Initial Node）作为业务流程的起点。起始节点的图标是一个实心小圆，一般习惯将起始节点放置在活动图面的左上角处，如图2-7所示。
由于横式书写或是西式书写的习惯都是由左上角开始，我们将起始节点放置在图面的左上角处，会比较符合横式阅读的习惯。不过，这只是习惯用法，没有硬性规定一定得这样做。
虽说内容重于一切，但是排版不佳或者表现风格不一致时，真的会让观看者心生障碍，大大降低阅读的顺畅性。所以说，图 2-8 所示的表示法不是不行，只是建议系统分析师尽量统一采用图2-7的表现风格。图2-7 起始节点图2-8 看起来比较不顺畅
注意用户/客户（甲方）看不太懂系统需求规格书（SRS）或系统设计规格书（SDS）的全部内容，这是十分正常的现象。但是，难保他们不会挑剔章节目录以及内容排版等的表象，而这通常是构建团队（乙方）没时间去重视的部分。所以，为了避免无谓的困扰，干脆一开始就尽量使用统一表示的风格。
在UML规格书中，没有限制一张活动图只能有一个起始节点。也就是说，一张活动图中可以有多个起始节点，也可能没有起始节点。但是，为了避免遗漏起始节点而找不到流程起点，所以我们会建议一张活动图至少放置一个起始节点。
注意活动图中可以没有起始节点，那是因为除了起始节点外，另外有一些节点也能够启动流程。所以，在活动图中，当然就有可能没有出现任何起始节点了。
此外，如果遇到多个起始节点的情况时，建议拆成多张活动图，尽量保持一张活动图一个起始节点的单纯情况。
2.4.2 活动终点
在每一张活动图中放置活动终点（Acitivity Final），用来表示整张活动图的活动终点。活动终点的图标是牛眼图标（双圆，内实外空），如图2-9所示。图2-9 活动终点
2.4.3 判断节点
在任何一条业务流程中，都可能会遇到一些判断节点（Decision Node），也因此改变了流程的路径，引发不同的动作。判断节点的图标是空心菱形，判断节点的内部请留白，不要填入任何字眼。
注意在UML初级认证考试中，有一个考题就是考判断节点的空心菱形图标内部，是否可以出现文字？答案是：不可以。这或许是因为判断节点（Decision Node）和合并节点（Merge Node），这两个概念共享空心菱形图标，才会规定菱形要保持空白吧！后面我们会提到合并节点的概念。
此外，在每一条离开路径都要设置一个警戒条件。流程的图标是带箭头实线，警戒条件（Guard）则放置于中括号中，通过警戒条件（评估为真）时，流程才能按照线条箭头方向往下动作。
注意，设置的警戒条件必须不重叠，也不遗漏。警戒条件重叠时，可能会导致不知该引发哪一条离开路径，这是不恰当的设计。警戒条件遗漏时，也可能会因为所有离开路径都无法通过警戒条件，而导致流程停顿，无法继续往下执行，这也是不恰当的设计。
延续前面的范例，由于银行客户申购基金或赎回基金，都需要通过综合存款账户把款项汇入或汇出，所以需要用到综合存款账户。因此，当银行客户要求开基金账户时，理财专员就会立即跟银行客户确认，是否在本银行开过综合存款账户，如图2-10所示。图2-10 判断节点
2.4.4 动作
动作（Action）应该可以说是一条业务流程中最重要的节点了吧，它代表一个不可再往下细分的最小工作片段。动作节点的图标是圆角矩形，动作图标内部文字的建议格式为：■ 第一行标示动作的负责人，并将负责人名称放置于小括号内。■ 第二行标示动作名称，建议动词起头，并且采用具体明确的字眼。
延续前面的范例，如果银行客户没有开过综合存款账户，理财专员就会把银行柜员找过来，请银行柜员帮客户开一个新的综合存款账户，如图2-11所示。
很多业务流程中都有主管审核的动作，要记得把主管审核的动作跟一开始的申请办理动作分开来，如图2-12所示。
仔细看还漏了一个动作，开一个新的综合存款账户都需要存第一笔款项，所以我们还要再加一个存款的动作，如图2-13所示。
此外，动作尽量保持单纯，最好一项动作（工作片段）只有一位负责人。如果一个动作需要多个人合作才能完成的话，可能这个动作的粒度就太大了。建议系统分析师遇到这种情况时，可以尝试把这个动作分割成数个动作。图2-11 动作图2-12 把审核动作分隔开来图2-13存第一笔款项
还有，评估并调整每一个动作的粒度，让动作的粒度与用例的粒度相近。动作与用例粒度相近的话，生成活动图之后，就可以同时生成初步的用例图了。动作是候选用例，至于动作的负责人则是候选参与者。
注意简单来说，一个用例代表系统提供的一项服务或功能，因此如果系统分析师在分割动作时，让动作的粒度逼近用例的粒度时，这样就会对后续生成系统层面的用例很有帮助。
2.4.5 合并节点
前面提到判断节点时，有提过合并节点（Merge Node）共享空心菱形图标。所以，切记，合并节点的内部请留白，不要填入任何字眼。有些UML软件工具，允许系统分析师在空心菱形图标内部填入文字，但是请系统分析师不要填入任何字眼。
合并节点和判断节点共享图标，所以可能会出现两者重叠共享一个空心菱形的情况，说明如下。
1．判断节点会有一条进入路径，多条离开路径，而且离开路径线头会附有警戒条件，意味着流程将依循着其中一条通过警戒条件的路径离开。
2．合并节点会有多条进入路径，一条离开路径，而且离开路径线头通常不会有警戒条件，意味着任何一条路径进入合并节点后，都只会按照着唯一一条离开路径往下通行。
3．合并和判断共享图标的情况下，空心菱形会有多条进入路径，也会有多条离开路径，并且离开路径线头附有警戒条件，意味着每一条进入空心菱形的路径会先合并，紧接着执行判断，然后从其中一条通过警戒条件的路径离开，如图2-14所示。图2-14 合并节点与判断节点
在开基金户的业务流程中，就出现了共享合并节点和判断节点的情况。在银行柜员协助客户，开了一个新的综合存款账户，并且存了第一笔款项之后，就没其他动作了。因此，流程可以再导回空心菱形，先执行合并再进行判断，如图2-15所示。如果，你看不太懂图2-15是怎么来的，可以看一下图2-16。图2-15 先合并再判断图2-16 先合并再判断的示意图
2.4.6 活动
动作是不可再细切的最底层工作片段，相较之下，活动（Activity）则是指可以再往下细分的工作片段。一个活动的内部可以是由活动和动作混合组成，但是一个动作的内部就不会再有更细小的动作了。
所以，面临比较复杂的业务流程时，系统分析师可以适度混用动作和活动。以前面的开基金账户流程为例，目前在业务流程中的动作似乎都跟开综合存款账户有关，如图 2-17所示。图2-17 开综存户
如果，系统分析师想要把这些动作封装起来的话，可以把这几个动作移到另一张活动图中，如图2-18所示。这时候，原先的活动图中，可以新增一个名为开综合户的活动图标来取代原先的三个动作，如图2-19所示。图2-18 另一张活动图
补充说明一下图标，活动的图标与动作的图标相同，都是圆角矩形。不过，要是在活动图中混用活动和动作的话，活动图标右下角会出现一个三叉图标（向下层级图标），代表可以向下展开的意思。
特别提醒系统分析师，UML在改版时，活动图标右下角的小标记有了变化。请你直接看图 2-20 所示的图标，UML1的旧版标记是一个像哑铃的图标（其实是两个动作串在一起的图标），而UML2的新版标记则是一个像摆放向下的叉子图标。图2-19 原先的活动图图2-20 活动图标的变化
2.4.7 分叉与会合
在一般的业务流程中，并行作业是十分常见的情况，系统分析师可以使用分叉节点（Fork Node）和会合节点（Join Node）来表示两条甚至多条的并行流程。
分叉和会合两节点的图标相同，都是粗线段。分叉节点会有一条进入路径，多条离开路径，意味着一条流程进入分叉节点后，就会分叉成多条并行的支流。会合节点会有多条进入路径，一条离开路径，意味着多条支流进入会合节点后，将会合成一条流程，然后往下继续执行下一个动作。
继续前面的开基金账户的业务流程，只要银行客户拥有综合存款账户之后，无论是早已经拥有还是现场立即开办的，总之银行客户必须开了综合存款账户后，理财专员才能够为银行客户开办基金账户。
接下来，就可以并行作业，以便节省作业时间了。所以，理财专员可以一边请银行客户填写风险容忍度测试表，另一边同时动手开立一个新的基金账户。两条并行的流程将在会合节点处会合，之后才继续执行下一个动作。此处，我们假设后续已经没有其他动作需要执行了，可以让流程进入活动终点，结束整条开基金户的业务流程，如图2-21所示。
最后，建议系统分析师在使用分叉节点和会合节点时，最好可以成对使用。而且，特别注意到，请不要使用合并节点来取代会合节点，两者是不同的概念：■ 会合节点会等待所有的进入路径都到齐了，才会往下执行下一个
动作。■ 合并节点不会等待，所有进入路径都可以直接通过，继续往下执
行到下一个动作。图2-21 分叉与会合
2.4.8 对象节点
在执行业务流程的过程中，经常会附带生成相关的静态对象，像是文件、窗体就是十分常见的对象。假如，系统分析师想要表示流程中流进或流出的数据项，就可以使用此处介绍的对象节点（Object Node），它的图标是矩形图标。
继续前面的业务流程，系统分析师可以在银行主管核准开基金户步骤后面，加上一个名为基金账户存折的对象节点，如图2-22所示。或者，我们也可以更详尽地把证件、印鉴，全都放入这条业务流程中，如图2-23所示。图2-22 对象节点图2-23更多的对象节点
第3章 用例建模
3.1 UML项目现场
3.1.1 用例的来源
在UML项目现场，系统分析师会发现用例的来源可能有下列3处，如图3-1所示。图3-1 用例的来源
1．业务流程——从业务流程图推导出用例。
2．功能架构——从功能架构图推导出用例。
3．其他——未直接支持业务流程，或者未列入功能架构的其他用例。
3.1.2 功能架构
很多用户/客户（甲方）不懂用例，但是却懂得功能架构，而且也很会使用一般的树状结构图来表示功能架构，如图3-2所示。
特别是有些大型的项目，用户/客户（甲方）在项目建置之前，就先提出详尽的征求建议书（RFP，Request for Proposal），文件里就已经明确列出期望的功能架构。在这种情况下，系统分析师几乎只要稍微加工一下，就可以生成初步的用例图了，如图3-3所示。图3-2 树状结构的功能架构图图3-3从功能架构图导出用例
由于系统功能繁多，所以用户/客户一般都习惯使用功能架构图来分类整理这些系统功能。而另一方面，用户/客户之所以不习惯使用业务流程图来寻找及分类用例，或许是因为下列两个原因。
1．大部分的用户/客户只知道自己份内的工作项目，很难得知延伸到其他同仁或部门的工作项目，对于整条业务流程只有见树不见林的局部认知。
2．另外，同样一个工作项目（动作）可能出现在不同的业务流程中，必须不断汇整，才不至于得出重复的用例。
所以，最佳的做法或许是，同步生成用例图和功能架构图。至于在功能架构图的表现上，系统分析师大可采用用户/客户熟悉的树状结构图。若是系统分析师有意要使用UML图的话，最简单的表达方法是混用类别和用例的图标，形成另一个新款的功能架构图，如图3-4所示。图3-4 UML的功能架构图
此外，在功能模块的规划上，经常会切开功能模块之间的相关性，但有时还不免有些相关性时，系统分析师可以把功能模块的图标加到用例图中，展现出功能模块之间的相关性，如图3-5所示。图3-5 使用功能模块概念的用例图
3.2 用例
表3-1 用例的定义[UML2规格书]请您看表3-1的用例英文定义，这段定义非常清楚地点出用例的4项特色，如下所述。
1．规范一套动作——用例是一个规范（specification），规范了一套动作（a set of actions）。
2．系统所履行——用例所规范的一套动作，主要是由系统执行，说得更具体些，系统必须实际做出用例所规范的这一套动作。正因为如此，在用例图面上，如果有显示出系统的大方框的话，用例的椭圆图标一定会放在大方框内部。
3．生成显著的结果——一旦系统执行完毕某一个用例之后，应该会生成明确、显著、可以辨识的结果。
4．有价于参与者或利益干系人——这样的结果是对参与者或利益干系人有价值，且可以让他们评价的。也是因为这样，所以在用例图上，系统分析师会在参与者图标和用例图标之间画上关系线，这样既可以知道是谁启动用例的，也可以知道系统是为谁提供用例的。
因此，我们可以看到用例图及叙述充分地凸显了用例定义中的特色，如图3-6所示。图3-6 用例图及叙述
3.3 现场的作业程序
3.3.1 生成初版的用例
还记得在业务流程建模的作业程序中，最后一个步骤是要生成初版的用例，如图3-7所示。
此处，我们来说明一下，如何从业务流程图导出初版的用例，步骤如下。
1．首先，系统分析师可以查看业务流程图中的动作，将可以信息化的动作直接对应成一个用例。
2．至于原先这个动作的负责人，则对应成可能启动用例的参与者，如图3-8所示。图3-7 业务流程建模的作业程序图3-8 动作导出用例及参与者
3．然后，系统分析师需要再查看判断节点是否有需要系统的支持。若有，也有可能得出其他的用例，如图3-9所示。图3-9 判断节点导出用例
4．判断节点对应的用例有以下两种情形。● 引发一个独立的用例进行判断。若是在这种情形下，需要再进一
步找出启动用例的参与者，如图3-10所示。● 另一种则是通过用例连接到另一个不能独立存在的小用例。若是
在这种情形下，需要再进一步决定两个用例之间的关系，如图
3-11所示。图3-10 引发独立的用例图3-11 连接到另一个不能独立存在的用例
3.3.2 用例建模的作业程序
有了初版的用例之后，系统分析师就可以按照图3-12的作业程序，踏上第一步骤绘制功能架构图和用例图了。图3-12 用例建模的作业程序
如果还没有切分功能模块的话，系统分析师可以先跟用户/客户确认功能模块。这样，系统分析师就可以将初步得出的用例直接归类到各个功能模块内，生成整个系统的功能架构图，如图3-13所示。图3-13功能架构图
系统分析师还可以依照各个功能模块，分别绘制用例图。图3-14是基金账户申办功能模块的用例图，图3-15是基金数据查询功能模块的用例图。图3-14 基金账户申办功能模块的用例图
然后，系统分析师就可以开始动手撰写用例叙述了。以查询基金基本数据用例为例，其主要流程与替代流程如下。图3-15 基金数据查询功能模块的用例图
主要流程 查询基金基本资料
1.银行客户提供基金公司名称、基金名称或关键词给系统。
2.系统查询基金基本数据。2.a.系统依据基金公司名称，查出基金公司名下有在本银行代售的所有基金。2.b.系统依据基金名称，查出一笔基金。2.c.系统依据关键词，查出基金名称中含有关键词的所有基金。
3.系统回复查询结果，每一笔数据包含如下内容。□基金：基金名称、基金编号、目前净值、币别、经理人名称、最低投资金额、手续费费率、管理费费率。□基金公司：基金公司名称、基金公司编号。
替代流程 查询基金基本资料
3.a.系统导出Excel查询结果文件。
3.4 现场使用的图标
3.4.1 参与者
参与者位于系统外部，与系统共同执行用例叙述中所记录的一套动作。参与者的图标是人形图标，放置在系统方框外，以结合关系的实线连接用例，如图3-16所示。
此外，在结合关系的实线上，我们建议系统分析师加上箭头，用来区分主要参与者与次要参与者。主要参与者负责启动用例，因此又称为“启动者”。而次要参与者则负责支持系统执行用例，所以也称为“支持者”。如图3-17所示。图3-16 参与者与结合关系图3-17 主要参与者与次要参与者
参与者并不局限是人类用户，也可能是联机系统、外部数据库、外部服务等。外部服务最常见的例子是排程服务，我们建议系统分析师可以善用排程服务来启动定时启动的用例，如图3-18所示。图3-18 外部服务
3.4.2 用例
用例规范着一套动作，通过这套动作，系统可以生成明显且有价值的服务或产品。在用例图面上，椭圆图标代表的用例放置在系统方框内，并且将用例的一套动作记录在用例的主要流程中。
在主要流程中记录的是一般的、正常的基本流程，执行期间发生较少出现的特殊支流时，则另外记录在替代流程中。以查询基金基本数据为例，系统提供导出Excel文件的附加功能，以方便银行客户取得查询结果作为他用。针对主要流程第3步骤，可能出现一个生成 Excel文件的支流，记录成编号3.a的替代流程，具体如下。
主要流程 查询基金基本资料
1.银行客户提供基金公司名称、基金名称或关键词给系统。
2.系统查询基金基本数据。2.a.系统依据基金公司名称，查出基金公司名下有在本银行代售的所有基金。2.b.系统依据基金名称，查出一笔基金。2.c.系统依据关键词，查出基金名称中含有关键词的所有基金。
3.系统回复查询结果，每一笔数据包含如下内容。□基金：基金名称、基金编号、目前净值、币别、经理人名称、最低投资金额、手续费费率、管理费费率。□基金公司：基金公司名称、基金公司编号。
替代流程 查询基金基本资料
3.a.系统导出Excel查询结果文件。
步骤前的数字编号意味着按照数字依序执行；英文编号则意味着未按照顺序，可能发生其中一个步骤，也可能发生其中多个步骤，但不需要按照顺序，所以没有数字编号。
举例来说，在主要流程的第2步骤下方编列了2.a、2.b、2.c，而不是2.1、2.2、2.3，意味着银行客户可以只择一输入基金公司名称、基金名称、关键词，也可以随意混用这3个查询条件，所以没有依序执行的限制。
至于替代流程是主要流程的支流，所以在替代流程的步骤编号上，会先带出主要流程的步骤编号，后面才是自己的编号。例如，此处替代流程3.a意味着关系到主要流程的第3步骤。
顺便提及的是，有些用例可能会被要求必须在通过某些限制条件时才能够执行。在这种情况下，可以为用例加入前置条件（pre-condition），用来限制用例的启动。
以开基金账户的业务流程为例，银行会要求银行客户必须先拥有本银行的综合存款账户。因此，系统分析师可以把这个条件设为启动｢申办基金办办｣用例的前置条件。这意味着必须通过这项前置条件，才能够启动这个用例，具体如下。
前置条件 申办基金账户
pre：银行客户拥有本银行的综合存款账户。
有前置条件，相对的也有后置条件（post-condition）。前置条件作为执行用例前的把关，后置条件则为执行后的把关。一旦用例正常执行完毕，就应该可以通过后置条件，否则会意味着该用例并未正常执行完毕。同样以申办基金账户为例，后置条件可能是已经取得了申办案件序号，具体如下。
后置条件 申办基金账户
post:系统取得申办案例序号。
3.4.3 包含关系与扩展关系
用例之间的主要关系有两种，一为“包含关系”（include），另一为“扩展关系”（extend）。两者都采用带箭头虚线，而且得在虚线旁边标示出《include》或《extend》字眼，特别需要注意的是，两者的箭头方向恰好相反，如图3-19所示。
包含关系和扩展关系两者在概念上最大的差异在于，基础用例一定会连带执行被包含的用例，但是，不一定会执行扩展的用例。用具体的例子来说明会更容易理解抽象的概念，所以，我们还是来看实例吧！3.4.3.1 包含关系
举例来说，申办基金账户用例的前置条件是银行客户已经拥有综合存款账户了。但是，综存账户的数据并不是存在基金系统中，而是由另一个银行系统负责保管的。所以，常见的做法可能是将银行系统列为次要参与者，如图3-20所示。
可是，系统分析师可能会有如下的考虑。图3-19 包含关系与扩展关系图3-20 向银行系统查验综存账户数据
1．基金系统中可能有多个用例，都需要查询综合存款账户的数据。
2．综存账户的数据其实完全由另一个银行系统所提供，为了将基金系统与其他系统之间的相关性局限在一处，所以系统分析师会切分出“介接服务”的功能模块，专门用来安置委托其他系统执行的用例。
基于上述的两点考虑，系统分析师决定把查验综存账户的流程切出来，新增另一个小的用例，并且放置在介接服务功能模块中，如图3-21所示。图3-21 介接服务的功能模块
对于申办基金账户用例而言，一定要确认综存账户已经存在，才能够被启动，所以两个用例之间就可以使用“包含关系”了，如图3-22所示。
此外，系统分析师也可以在包含关系旁，特别标记出“前置条件”的字眼，这意味着系统是因为要检验申办基金账户的前置条件，才设置这条包含关系的，如图3-23所示。图3-22 包含关系图3-23标记出“前置条件”
对应图3-23的情况，在申办基金账户的用例叙述中，我们可能做如下的叙述。
前置条件 申办基金账户
pre：银行客户拥有本银行的综合存款账户。
主要流程 申办基金账户（略）
在操作流程上，我们也可以有如下的设计。
操作流程 申办基金账户（包含查验综存账户）
1.理财专员按下选单上的申办基金账户的功能键。
2.系统跳出查验综存账户的对话窗，如图3-24所示。图3-24 查验综存账户的对话窗
3.理财专员输入银行客户的身份证号、综存户账号或两个数据都输入，并且按下查验键。
4.通过查验后，系统会出现申办基金账户的主要画面（以下省略）。
刚才我们看到的是基金系统自动查验综存账户存在与否的设计，此处我们来看另一种设计，让理财专员人工查验综存账户。在这种设计下，我们调整了下列两处地方。
1．申办基金账户的前置条件，可以删去，如下。
前置条件 申办基金账户
无。
2．申办基金账户的用例，不需要包含查验综存账户这个小的用例了，所以可以删去两者之间的包含关系，改由理财专员直接启动查验综存账户，如图3-25所示。
这样一来，操作流程可能也要同步修订，必须把查验综存账户与申办基金账户切开，做如下的描述。
操作流程 申办基金账户
1.理财专员按下选单上的申办基金账户的功能键。图3-25 人工查验
2.……（以下省略）
操作流程 查验综存账户
1.理财专员按下选单上的查验综存账户的功能键。
2.系统跳出查验综存账户的对话窗，如图3-26所示。图3-26 查验综存账户的对话窗
3.理财专员键入银行客户的身份证号、综存户账号或两个数据都键入，并且按下查验键。
4.……（以下省略）
最后，我们再来整理一下。两个用例之间具有包含关系时，有下列3项特色。
1．被包含的小用例无法脱离基础用例而独立存在。
2．基础用例一定会执行被包含的小用例。
3．两者加起来是一条流程，如图3-27所示。3.4.3.2 扩展关系
当两个用例之间具有扩展关系时，基础用例不一定会执行扩展的小用例，通常是在符合特定的条件下，才会额外执行扩展用例的小流程。因此，扩展关系的特色如下。
1．扩展的小用例无法脱离基础用例而独立存在。
2．基础用例“不一定”会执行扩展的小用例。
3．两者加在一起，形成两条流程：其一是单独执行基础用例，另一条流程是基础用例外加扩展用例，如图3-28所示。
还记得我们前面提到查询基金基本资料用例，有一个替代流程是可以把查询结果打包成Excel文件，以便银行客户生成作为其他用途，具体如下。
替代流程 查询基金基本资料
3.a.系统导出Excel查询结果文件。图3-27 一条流程图3-28 两条流程
随后，系统分析师发现另一个“查询基金投资明细”的用例，也需要提供 Excel 查询结果文件。此时，系统分析师考虑将“生成 Excel 查询结果文件”切分出来，成为另一个小的扩展用例，这样就可以让查询基金基本数据和查询基金投资明细这两个用例，共享生成Excel查询结果文件，如图3-29所示。图3-29 扩展关系
替代流程 查询基金基本资料
3.a.系统执行“导出Excel查询结果文件”用例。
替代流程 查询基金投资明细
系统执行“导出Excel查询结果文件”用例。
主要流程 导出Excel查询结果文件（略）
第4章 领域建模
4.1 UML项目现场
老实说，我在UML项目现场，从来没见过哪个项目的系统分析师有认真推敲并且正式生成“领域模型”（Domain Model）！系统分析师或构建团队不重视、省略甚至放弃构建领域模型，除了项目时程压迫的通病外，我推敲可能的原因如下。
1．系统分析师缺乏领域知识，也不想花精力去跟领域专家学习领域知识，当然也就构建不出什么有用的领域模型了。
2．系统分析师不重视领域模型，所以鲜少练习领域建模的技术，也不知道怎样跟领域项目沟通，在这种恶性循环下，也就更难构建出领域模型了。
3．即便系统分析师大费周章地生成领域模型，但是系统设计师并未重视领域模型，也不以领域模型作为系统内部的核心结构。
注意有一个设计技术称为“领域驱动设计”（DDD，Domain-Driven Design），这个技术的中心思维就是要构建团队重视领域模型，而且要将领域模型作为设计的核心。
总之，现在最主要的困境是：前头在分析阶段所花费的领域建模成本，无法在后续的设计、实现及维护阶段产生高价值的效益。因此，导致项目经理、系统分析师都不愿意投注时间在领域建模上头，更别说系统设计师和程序员对领域模型的视而不见了。
所以，十分期盼从你阅读这本书开始，让我们一起来打破不重视领域模型的恶性循环。而且，更可以像定期定额申购基金般，也定期定额地投入一些时间和精力在领域模型上。
4.2 领域模型
表4-1 领域模型的英文定义[Wiki百科]表4-2 领域模型的中文定义[Wiki百科]类图
参考维基百科对领域模型的定义，中英文定义都有，如表4-1和表4-2所示。唯独此处的中文的定义，并非是英文定义的中译，而且中文定义中有凸显其他的重点，所以此处我们就一并列出来供你参考了。汇总中英文定义可以得到下列几项重点。
1．领域模型是一种概念模型，用来呈现问题领域中的重要概念。
2．领域模型描述了问题领域中的实体（entity），以及实体的属性（attribute）、操作（operation）、角色（role）、关系（relationship）和限制（constraint）。
3．对于用例所描述的互动过程，领域模型可以作为在用例背后起到支持作用的重要结构。
4．在UML图款中，通常使用类图（Class Diagram）来描述领域模型。
5．领域模型除了可以用来沟通领域知识外，也可以被用在后续的设计实践，甚至进一步实现出对应的程序代码。
最后，我们先来简单看一下，类图如何反映上述的重点，如图4-1所示。图4-1 类图● 实体、属性、操作——类代表领域实体。类的矩形图标内部，
第一格是类（实体）名称，第二格放置属性，第三格放置操作。● 关系——类之间的静态关系有多种，最常见的是实线图标的“结合关系”（Association）。● 角色——结合关系的两个端点可以标示“角色”（Role）名称，
说明实体是以什么样的角色参与这项关系的。● 限制——限制可以用很多方式呈现，最常见的是“个体数目”（Multiplicity），标示在结合关系的两个端点，用来限制两种实体
之间的数量关系。
4.3 现场的作业程序
4.3.1 生成初版的用例
还记得在用例建模的作业程序中，最后一个步骤是要生成的领域模型最初版本，如图4-2所示。4.3.1.1 查询基金基本资料
此处，我们以查询基金基本资料这个用例为例，来示范如何从用例导出初版的领域模型，步骤如下。图4-2 用例建模的作业程序
第1步 查看用例叙述，把出现在其中的数据项依照领域概念做初步分类。以查询基金基本数据为例，找出两大类的数据项，分别如下。□基金：基金名称、基金编号、目前净值、币别、经理人名称、最低投资金额、手续费费率、管理费费率。□基金公司：基金公司名称、基金公司编号。
主要流程 查询基金基本资料
1.银行客户提供基金公司名称、基金名称或关键词给系统。
2.系统查询基金基本数据。2.a.系统依据基金公司名称，查出基金公司名下有在本银行代售的所有基金。2.b.系统依据基金名称，查出一笔基金。2.c.系统依据关键词，查出基金名称中含有关键词的所有基金。
3.系统回复查询结果，每一笔数据包含如下内容。□基金：基金名称、基金编号、目前净值、币别、经理人名称、最低投资金额、手续费费率、管理费费率。□基金公司：基金公司名称、基金公司编号。
第2步 新增一个“类”（Class）代表领域概念，并将该分类下的数据项放置在类图标的第二格（属性）中，如图4-3所示。
试读结束[说明：试读内容隐藏了图片]