以前老是听到UML的大名，不过很少去真正地了解它，无非以为只是一种建模的方法，乍看这封面或许和产品经理毫无相关，但是认真细读，其实和产品经理工作方法思考模式都是紧密相关的，虽然本书涉及更多是关于软件产品方面的，但是秉着“世间万物皆产品”的心态去阅读和思考也是能发现其中的精髓
作者从UML是什么，为什么需要UML开始； 以UML核心元素（版型、参与者、用例、边界、业务实体、包、分析类、设计类、关系、组件、节点）为点， 以UML核心视图（静态视图与动态视图）为线， 以UML核心模型（业务用例模型、概念用例模型、领域模型、系统用例模型、分析模型、设计模型、组件模型、实施模型）为面来介绍UML表示法的内涵； 全书以一个案例贯穿始终，并以RUP核心工作流为指引，分别介绍了业务建模、系统建模、分析与设计建模及实施建模的工作流程、活动集与工件集，帮助你了解软件生命周期各阶段要完成的工作和阶段之间工作之间的联系与推导
而且本书框架非常好的一点是能逐层深入，从准备篇（需要了解）--基础篇（在学习中思考）--进阶篇（在实践中思考）--高级篇（在提炼中思考），着实让我眼前一亮，因为最近工作也需要这么一套方法
所以写读书笔记过程中，我也希望遵循从了解到思考，再到提炼这过程，看看每个阶段对于自己的收获，所以读书笔记先针对前两篇，准备篇和基础篇（第一章~第七章），往后还会更新进阶篇和高级篇的文章
一.为什么需要UML
看待世界有两种方法，一种是面向过程，另一种是面向对象。面向过程归纳为结构化程序设计、DFD图、ER图、UC矩阵等，而面向对象可归纳为继承、封装、多态、复用等具体技术。
面向对象方法能够将复杂的系统分解成许多的小零件，就像制造一辆汽车，先标准化生产出汽车的各个零部件，再组装起来，进一步的，当需要将汽车和其它元素联系时，可以将汽车看成是一个整体，进一步抽象。这就是面向对象的强大之处，可以多层次抽象。不过面向对象也有弱点，它不能让我们知道这个世界要如何去抽象，我们抽象的现实世界是否一致。这时就需要UML这种面向对象分析设计方法统一可视化语言来描绘。
现实世界---业务模型
UML捕获了现实世界的人，事，物，规则，将现实信息转化成业务模型
业务模型---概念模型
业务模型只是原始需求信息，接下来需要建立计算机可理解的和可实现的模型
边界类（boundary）：计算机的操作都要通过界面进行，边界类就这个界面。边界类决定了外面能对里面做什么“事”。
实体类（entity): UML用实体类来表示现实世界种参与者完成业务目标所涉及的事物。
控制类（control）：UML采用控制类来表述原始需求中的动态信息，也就是业务和用例场景中的步骤和活动。
概念模型---设计模型
概念模型实例化
二.UML关键元素
以人为本开始
参与者
思考下面问题有助于找到参与者
1.谁对系统有着明确的目标和要求并且主动发出动作
2.系统是为谁服务的
3.参与者也可能是非人类，例如一个每天自动统计网站访问量报表的系统，这个参与者就是一个时间触发器，参与者肯定是一个需求的启动者，如果找不到启动者，说明这不是一个功能性需求
确定参与者可思考下面问题
1.谁负责提供，使用或删除信息？
2.谁将使用此功能？
3.谁对某个特定功能感兴趣？
4.在组织中的什么地方使用系统？
5.谁负责支持和维护系统？
6.系统有哪些外部资源？
7.其他还有那些系统将需要与该系统进行交互？
业务主角
用于定义业务的参与者，业务主角必须在实际的业务里找到对应的岗位或人员
业务工人
例如定票系统中的人工作机，他的最终目的不是订票，而是服务客户，他属于系统之内，所以他是业务工人，而不是参与者
用例
完整用例=参与者+前置条件+场景+后置条件，就是一件事情，要完成这件事情，需要做的一系列的活动；而做一件事情可以有很多不同的办法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的
要注意的点：
1.用例的执行结果对于参与者来说是可观测的和有意义的。例如系统中有个删除前自动备份数据的操作，这个操作结果对与参与者是透明的，参与者不是直接受益人，所以他不能称之为用例
2.用例必然是以动宾短语形式出现的、例如“喝水”是一个有效的用例，而“喝”不是
获取用例
要思考如下问题
1.您有什么期望
2.打算做些什么事情
3.做这些事情目的是什么
4.希望出现一个什么结果
用例和功能的区分
1.功能是脱离使用者的愿望而存在的。例如我们描述一个自行车的功能就是他能骑和载物，并无谁来使用它。用例是要从使用者绝度描述使用者愿望
2.功能是孤立的，在系统中，给一个输入就能得到一个输出。而用例是一个系统性的工作，这个系统的工作非常明确的去为某个参与者达成一个特定的目标
3.如果非要从功能的角度去解释用例，那么用例可以解释为一系列完成一个特定目标的功能的组合
边界
一个非常虚无缥缈的概念，它是“事物”展现给外部的一个限定，对于有形事物和无形事物都有区分
业务实体
用于业务建模阶段。业务实体描述了我们使用什么来达到业务目标，以及通过什么来记录这个业务目标。
分析类
包括三类：边界类，控制类，实体类
分析类三高：
1.高于设计实现，在为需求考虑系统实现的时候，可以不必理会复杂的设计要求。如应用的设计模式，系统框架等
2.高于语言实现，在需求考虑系统的时候，可以不必理会采用哪一种特性的语言来编码
3.高于实现方式，在为需求考虑系统实现的时候，可以不考虑采用哪一种具体的实现方式
关系
关联关系
A—B，它描述不同类的对象之间的结构关系，就像A知道B的存在一样
依赖关系
A----->B 它描述一个对象的修改回导致另一个对象的修改这样的关系。犹如B的修改会导致A的修改
扩展关系
它特别用于在用力模型中说明向基本用例中的某个扩展点插入扩展用例。就像一个用例的“支流”一样。比如，你在接电话的时候，这时候有另一通电话打进来，这时候你而已选择保持通话去接这个刚来的电话，这个保持通话就是一个扩展，它是“可选”的，这与包含关系有区别
包含关系
它和扩展关系的唯一不同就在于他是必选的，例如你去银行办理业务的时候，无论是取钱，转账，查看账户资料的时候，都必须经过一个身份的验证，这一个验证的过程就是一个包含用例
实现关系
用于在用例模型链接用例和用例实现，说明基本用例的一个实现方式。例如交纳电话费这个用例，可以选择营业厅交费，银行交费，预存话费，这3种方式都是交纳电话费的一个实现途径，所以他们是实现用例
精化关系
用于用例模型，精化关系表示由基本对象可以分解为更明确，精细的子对象，这些子对象并没有增加，减少，改变经本对象的行为和属性。例如预存话费这个用例，可以分解为开立账户，存入现金，转账，支付划账等精化用例
泛化关系
泛化关系表示面向对象里面的继承
聚合关系
用于类图，表达整体部分的语义，且部分可以单独存在，例如一个部门由许多人员构成，但部门解散了，人员依然存在。
组合关系
和聚合关系不同，如果整体部分消失，分部也消失，不能单独存在
三.UML核心试图
静态视图
UML中的静态视图包括：用例图，类图，包图
用例图：用例图是采用参与者和用例作为基本元素，以不同的视角展示系统的功能需求。它是了解系统的第一个关口
业务用例图：两个视角，业务主角视角和业务模块视角
业务主角视角：从业务主角视角来展示业务主角在业务中使用哪些业务用例来达成业务目标
业务模块视角：从业务模块视角来展示业务领域的业务目标
业务用例实现图：业务用例实现图是来展现业务用例有哪些实现途径
概念用例视图：概念用例图用于展现业务用例中经过分析分解出来的关键概念用例，并表示概念用例和业务用例之间的关系
系统用例视图：系统用例图展现系统范围，将对业务用例进行分析以后得到的系统用例展现出来
类图：类图用与展现系统中的类与其相互之间的关系，类图现有又概念层到说明层再到实现层
概念层类图：根据业务用例来描述出现实世界中所用到的事物，并把它抽象出类
说明层类图：在这个层次的类图考察是类的接口而不是类的实现
实现层类图：在这个层次上，类必须明确采用哪种实现语言，什么设计模式，什么通信标准等
包图：包图一般都是来展示高层次的观点
动态视图
包括：活动图，状态图，时序图，协作图
活动图：用例活动，对象活动，泳道
用例活动：表达参与者的一个目标，用例场景表达如何达到这个目标
对象活动图：用于展示对象的交互
泳道：代表特定的类，人，部门，层次等对象的职责区
状态图：描述单个复杂对象行为时
时序图：用于描述按时间顺序排列的对象之间的交互模式
业务模型时序图：目标是实现业务用例
概念用例时序图：根据业务模型场景图
设计模型时序图：实现概念模型某个事件流
协作图：描述对象间一种交互模式，通过对象之间的连接和他们相互发送的信息来显示交互的对象
业务模型协作图：只需要将影响对象相互的信息绘制出来
概念模型协作图：
设计模型协作图：
四：UML核心模型
静态图是论据，动态图事论证，模型提出论点，采用论据来论证论点的过程
完整的业务用例模型
1.业务用例视图
2.业务用例场景
3.业务用例规约
4.业务规则
5.业务对象模型
6.业务用例实现视图
7.业务用例实现场景
8.包图
完整的概念用例模型
1.概念用例视图
2.概念用例分析
3.分析类视图
4.分析场景
完整的系统用例模型
1.业务用例
2.概念用例
3.用例视图
4.用例规约
5.补充规约
6.业务规则
7.用例实现
8.用例场景
9.分析对象
五.UML工作流程
业务建模工作流程
系统建模工作流程
分析设计建模流程
