本文为《软件方法-业务建模和需求》的读后感系列，可在线试读
工作流
定义
软件工程中阶段中的的计划、需求分析和设计阶段，都需要进行建模：
| 工作流 | 描述 |
|---|---|
| 业务建模（严格来说叫组织建模） | •组织内部各系统协作 •组织引进一个软件系统，和招聘一批新员工没有本质区别 |
| 需求 | •描述为了解决组织的问题，系统必须具有的表现——功能和性能 •从“卖”的角度思考哪些是涉众在意的、不能改变的契约，哪些不是，严防“做”污染“卖” |
| 分析 | •提炼为了满足功能需求，系统需要封装的核心领域机制 •可运行的系统需要封装各个领域的知识，其中只有一个领域（核心域）的知识是系统能在市场上生存的理由 |
| 设计 | •为了满足质量需求和设计约束，核心领域机制如何映射到选定平台上实现。 |
误解
软件开发人员如果对以上工作流没有概念，就会把这些工作通通称为“设计”或者“文档”，产生以下误解：
- 例如问开发人员在做什么，回答“我在做设计”、“我在写文档”，其实他的大脑可能正在思考组织的流程（业务建模），或者在思考系统有什么功能性能（需求），或者在思考系统要包含的领域概念之间的关系（分析），但他通通回答成“在做设计”、“在写文档”
- 又有牛人认为“代码就是设计”。本来“设计”在他脑子里就是“代码以外的东西”，这么一推导，不就变成了：代码就是一切？
把工件简单分割为代码和文档（或设计），背后还隐含着这样的误解：认为模型（文档）只不过是源代码的另一种比较概要或比较形象的表现形式。
边界
不同工作流产出的工件之间的区别不在于形式，而在于内容，也就是思考的边界
UML建模
建模不一定非要用UML，也可以用文本或其他自造符号来表达。每个项目中，团队一定会思考和表达建模思想，只是可能无意识、不严肃的做。
UML全称Unified Modeling Language，翻译过来叫做统一建模语言，是非专利的第三代建模和规约语言。
为何钟爱UML
大家看看有没有遇到这种情况：开会讨论问题，某些人就是白板手绘草图，“来，我给大家讲讲”。我感觉这种特别常见，基本是画流程图和活动图、时序图的混合体，以及ER图、类图糅杂砸一起。
这样的做法有巨大的“优点”：怎么画都是对的，关于这个草图的解释权归“我”所有。同事不好批评“我”，项目要依赖于“我”头脑中的隐式知识——要是“我”不“给大家讲讲”，大家就玩不转了。这样，“我”在团队里的地位就提高了。上面这种现象，在有一定资历、但又不对项目的成败承担首要责任的“高手”身上表现更明显。
这种做法的本质是想通过形式上的丑陋来遮掩内容上的丑陋。
掌握统一的建模语言之后，开发团队在基本共识上沟通，会大大提高沟通的效率和深度，有意无意遮掩的脓包也会强制露出。开发人员如果习惯于画“草图”，用“模块”、“特性”等词汇含糊不清地表达思想，在严谨建模思维的追问之下，往往会千疮百孔，暴露许多之前没有想到的问题。
作者特意提到：
使用UML沟通仅限于软件组织内部，UML模型不是用来和涉众沟通的！
跟客户沟通，还是Visio那种流程图、泳道图合适。跟客户谈业务流程，这种形式更合适。
建模UML图
UML2.5中，已经有14种图：
不是所有图都要在建模工作流中使用，下面是建模工作流推荐的UML图：
可选和推荐的建模元素用法（●：优先使用，√：可以使用 ）
这里简单介绍下使用的UML图形
用例图
简单来说，用例图的目的如下：
- 用例图用来收集系统的要求
- 用例图用于获取系统的外观图
- 用例图识别外部和内部因素影响系统
- 用例图显示要求之间的相互作用是参与者。
下面是一个示例用例图，代表订单管理系统。因此，如果我们看看图，那么我们会发现三个用例（订单，特殊订单和正常订单）和一个参与者：顾客。
SpecialOrder 和NormalOrder 从订单使用情况扩展。因此，他们扩展了关系。另外很重要的一点是确定系统边界，这是图中所示。参与者是客户以外的系统，因为它是系统的外部用户。
再举一个包含关系的例子：
包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例
类图
类图可以用来：描述系统的静态视图。显示静态视图中的元素之间的协作。由系统执行的功能的描述。构建软件应用面向对象的语言。
举个例子：
车的类图结构为<
>，表示车是一个抽象类； 它有两个继承类：小汽车和自行车；它们之间的关系为实现关系，使用带空心箭头的虚线表示；
小汽车为与SUV之间也是继承关系，它们之间的关系为泛化关系，使用带空心箭头的实线表示；
小汽车与发动机之间是组合关系，使用带实心箭头的实线表示；
学生与班级之间是聚合关系，使用带空心箭头的实线表示；
学生与身份证之间为关联关系，使用一根实线表示；
学生上学需要用到自行车，与自行车是一种依赖关系，使用带箭头的虚线表示；
序列图
状态图
UML 状态图是图表本身的名称，主要用于描述对象具有的各种状态、状态之间的转换过程以及触发状态转换的各种事件和条件。
使用状态图的主要目的：
- 为了模拟系统的动态环节
- 反应系统模型生命周期
- 一个对象来描述不同的状态，在其生命周期的时间。
- 定义一个状态机模型状态的对象
当发生特定事件时，对象可能会发生状态的变动。
绘制状态图之前，我们必须明确以下几点：
- 识别对象，以进行分析
- 识别对象的各类状态
- 识别各类的事件，尤其是直接导致状态改变的时间
举个例子：
活动图
UML 活动图能够捕捉到该系统的动态行为，UML 中其它的四个图是用来显示从一个对象到另一个消息流，但活动图是用来显示消息流从一个活动到另一个活动图。
以下是 UML 活动图目的描述：
- 绘制活动流程系统
- 描述的顺序从一个活动到另一个
- 描述系统并行，分支，并发流。
以找饮料为例子：
上述的图将人视为开始起点有些奇怪，整体上是没有问题的。
包含子活动，如下图所示：
其中pay for the book为子活动，子活动的结束符号可能是其他样式
