带你在UML项目现场轻松使用UML

《系统分析师-UML项目实战》   邱郁惠 著

带你在UML项目现场轻松使用UML

本书目的：本书关注系统分析师在UML项目现场如何现学现用立即使用活动图、用例图（以及用例叙述）、类图，来呈现业务流程、用例以及领域模型。再者，也希望团队成员可以人手一书，作为使用者/客户（甲方）、构建团队/绘制者/观看者（乙方）、独立监审商（丙方）等多方沟通UML概念的基石。

Part I：简介。

chapter 1    UML项目现场。

在UML项目现场，限制团队成员使用最少量的UML概念和图标，训练团队成员采用相同的作业程序，通过牺牲一些自由与创意，或许可以换取团队成员以最快速度齐步向前走，强力挺近UML项目现场。

Part II：建模。

chapter 2     业务流程建模。

使用UML的活动图（Activity Diagram），表达系统构建之后所支持的新的业务流程。

chapter  3   用例建模。

使用UML著名的用例图（Use Case Diagram）以及用例叙述（Use Case Narrative），来呈现用户与系统互动以获取产品或服务的过程。

 chapter 4    领域建模。

使用UML的类图（Class Diagram）表达问题领域中的重要实体，以及实体的属性、操作、限制、角色和关系，用来作为系统内部重要的业务核心。

Part III：模型走读。

chapter 5   模型走读。

程序设计师在编写完程序代码、交付之前，可以先进行人工的“代码走读”（code walkthrough），以便确保程序代码的质量。同样，系统分析师在做完每一个用例，并且将用例涉及的领域概念也同步提取汇总到领域模型之后，也是可以 学习代码走读的精神，也来进行人工的“模型走读”（model walkthrough）。

chapter 6  继续走读。

经过之前的模型走读，修正了一些内容，也与领域专家又做了一次深度的沟通。所以，在本章中，我们将汇总并额外补上一些疏漏的内容。

Part IV：范例。

chapter 7  基金系统范例。

本章内容除汇总chapter2到chapter6关于基金系统的分析内容外，还会额外补充一些说明和其他分析内容，不过不会再有更多的理论论述。

Part V：附录。

附录AUML官方认证。初级，中级，高级。

附录B成本估算。成本估算一直都是件难事，参考过去流行的“功能点”（Function Point）估算，学者Gustav karner提出了“用例点”（Use Case Point）估算来搭配面向对象技术。本附录会简单提到用例点估算公式以及相关的参考文献。

本书采用的UML工具

本书范例都采用StarUML绘制。StarUML最大的特色，就是免费且开源（open source）。或许您会，一试成主顾！

chapter1

IKEA的创办人英格瓦·坎普拉（Ingvar Kamprad）常把“简单是一种美德”这句话挂在嘴边。他经常告诫大家：“只有平庸的人，才会提出复杂的解决方案。”-->“只用平庸的团队，才会把UML用的既复杂又困难。”

现场的作业程序：

在系统分析师的现场作业中，跟UML有关的产出及作业程序主要有3项，分别如下：

1. 业务流程建模——使用UML的活动图（Activity Diagram）表达系统构建后所支持的新业务流程。建议的现场作业程序：

step1. 绘制未来的业务流程；

step2. 举行确认会议；

step3. 生成初稿的领域模型。

2. 用例模型——使用UML著名的用例图（Use Case Diagram）以及用例叙述（Use Case Narrative），来呈现用户与系统互动以获取产品或服务的过程。建议的现场作业程序：

step1. 绘制功能架构图及用例图；

step2. 编写用例叙述；

step3. 生成初稿的领域模型。

3. 领域模型——使用UML的类图（Class Diagram）表达问题域（Problem Domain）中的重要实体（entity），以及实体的属性（attribute）、操作（operation）、限制（constraint）、角色（role）和关系（relationship），用来作为系统内部重要的业务核心。建议的现场作业程序：

step1. 应用样式调整结构；

step2. 增加及修入业务规则；

step3. 加入重要的操作。

chapter2

在UML项目现场，系统分析师可以发现活动图（Activity Diagram）经常用来表示下例3种流程。

a. 业务流程（Business Process）；

b. 系统流程（System Process）；

c. 操作流程（Operational Process）。

系统分析师可以通过活动图与用户或客户沟通，并确认未来系统上线之后的业务流程。

Business Process（Wiki）：A business process or business method is a collection of related, structured activities or tasks that produce  a specific service or product(serve a particular goal)for a particular customer or customers.

重要：

虽然都用活动图表示，但是不同流程有很大差别：

业务流程的生成时机是需求分析阶段，收录在系统需求规格书（SRS）中，由系统分析师绘制，给客户及系统设计师看。

系统流程的生成时机是系统设计阶段，收录在系统设计规格书（SDS）中，由系统设计师绘制，给程序设计师看。

活动图现场使用的图标：起始节点，活动终点，判断节点（Decision Node），动作（Action，圆角矩形），合并节点（Merge Node），活动，分叉与会合（Fork Node ，Join Node），对象节点（Object Node，矩形图标）。

动作节点图标内部文字的建议格式为：

第一行标示动作的负责人，并将负责人名称放置于小括号内；

第二行标示动作名称，建议动词起头，并且采用具体明确的字眼。

重要：

评估并调整每一个动作的粒度，让动作的粒度与用例的粒度相近。动作与用例粒度相近的话，生成活动图之后，就可以同步生成初步的用例图了。动作是候选用例！！

chapter 3

在UML项目现场，系统分析师会发现用例的来源可能有下列3处：

1. 业务流程——从业务流程图推导出用例；

2. 功能架构——从功能架构图推导出用例；

3. 其他——未直接支持业务流程，或者未列入功能架构的其他用例。

很多客户（甲方）不懂用例，但是却懂得功能架构，特别是有些大型的项目，客户（甲方）在项目建置之前，就先提出详尽的征求建议书（RFP，Request for Proposal），此时，系统分析师只要稍微加工一下，就可以生成初步的用例图了。

Use Case（Wiki）： A use case is the specification(规范) of a set of actions performed by a saytem ,which yields an observable result(显著的结果)that is , typically, of value for one or more actors or other stakeholders(利益相关者) of the system.    重点：规范一套动作，生成显著的结果，有价于参与者或利益相关者。

包含关系与扩展关系（《include》，《extend》）

chapter4

Note：有一个设计技术称为“领域驱动设计”（DDD，Domain-Driven Design），这个技术的中心思维就是要构建团队重视领域模型，而且将领域模型作为设计核心。

Domain Model（Wiki）：A domain model in problem solving and software engineering can be thought of as a conceptual data model of a domain of interest(often referred to as a problem domain) which descibes the various entities,their attributes,roles and relationships, plus the constraints that govern the integrity of the model elements comprising that problem domain(问题领域)。

说白了，就是E-R图，不对，准确叫O-R图。在UML中，通常使用类图（Class Diagram）来描述领域模型。

step1. 绘制功能架构图及用例图；

step2. 编写用例叙述；

step3. 生成初稿的领域模型。

Page 43