大象
先简要概述这本书的内容，本书主要是讲一种如何以对象的思考方式将复杂化的业务用其的建模方法的方法形象的表达出来。整本书也是围绕UML 的语言概念展开，如定义其元素：用例，业务，包，关系，组件，节点。又通过其语法如：视图和模型来完成一个业务的分析。最后通过一个例子来强化UML的语法。
作者在文章最后一篇还帮我们扩展关于设计的思考。包括理解用例本质、理解建模的抽象层次、学会设计模式等都是为了让我们更扎实的思考底层设计思维和方法论这样才能更好运用UML 。
其实学过编程的人妥妥发现这本书就是文字版的编程产品设计思维。从头到尾都是编程的面向对象思维。所以在刚开始接触这本书的时候我的第一印象是真的很无趣，甚至挑选读了100来页之后觉，心里嘀咕就这？不就是编程的思维把他写成书吗？
再到后来我在产品设计上遇到一些困惑后，决定重新拿起这本书来读的时候解决了我很多问题后，觉得真香。所以在读一本书的时候，最好是带着困惑去读，不然会读完索然无味，如果没有疑惑或者好奇，那么我宁愿不读。那么就让我们带着问题来了解这本书。
1.什么是建模？为什么要用UML建模？
2.uml 核心图能做什么？
3.如何用模型来快速理清一个系统？
什么是建模？为什么要用UML建模？
建模，是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物的理解，同时把这种理解概念化，将这些逻辑组织起来，构成一种对所观察的对象对内部结构和工作眼里的便于理解的表达。
打个比方，如果你看到一座美丽的山。你特别想留住眼前的美景。你通过对这种山用各种不同的角度如：高度，宽度，美丽程度，植被的覆盖度，等多个角度的描述的过程就是建模的过程。而角度的不同决定就是建模方向的不同。描述角度越全面你面前的这座山就更接近它本身。
在面向对象出现之前，有大量的编程语言都是面向过程的，如C，pthen语言、汇编等。开发人员很难从设计中推导出需要的对象，很容易业务变化就会被牵着走。举个例子假设把切好的西瓜放到冰箱冷藏。
那么面向过程设计思路就是：
- 拿到西瓜
- 切成合适的分量
- 放到冰箱
而如果是面向对象的设计思路是：
- 准备不同的工具
- 拿到不同水果
- 选择合适的切法
- 放到冰箱
发现没有，如果我下次拿的是橙子的话，那么面向过程就需要重新再编写和操作一遍。而面向对象就只需要把橙子扔过去，他就能放入冰箱。
而UML出现就是为了解决编程很难从设计中推导出对象的问题。通过UML的基本元素如组件，关系等结合分析模型和核心视图把现实复杂的业务通过面向对象的思路设计出来。
UML核心图能做什么？
如果用文字表述一个复杂业务流程的话，相信没有上千字也有几百字。图的出现恰好解决了这一难题。
UML 视图分为静态视图和动态视图。静态视图主要用来表达结构特征的，而动态试图用来表达用户的行为特性。可以说静态静态图是动态图的基础。下面结合查询到的资料介绍日常用到频率最多的视图。
静态视图包含：用例图（业务用例视图，业务用例实现图，系统用例视图，系统用例实现图），类图（概念层类图，说明层类图，实现层类图），包图（展示层次关系）。
业务用例实现图
业务用例实现图展现业务用例有哪些实现方式，可以更方便我们梳理业务查缺补漏看自己是否设计差什么内容。
类图
类图一般用来描述对象的属性和方法是从现实世界过度到代码世界的一种方法。
如果把多个图类通过类图关系关联起来(泛化、实现、依赖、关联、聚合、组合)则可用于数据库设计也是作者书中提及的设计模式阶段需要做的事情，对应到产品就是信息结构。
对象类图
类图关系链接
动态视图包括：活动图（泳道图，对象活动图，用例活动图）、状态图、时序图（业务模型时序图、概念模型时序图、设计模型时序图）、协作图。
状态图
描述某个事物状态改变的过程
如下图围绕着图书馆书籍整个生命周期状态绘制的状态图
活动图
作为描述某一对象通过多个动作完成的某项工作的过程。如下图包含整个办理登记流程的活动。
办理登记活动流程
泳道图
泳道图最主要的用途就是在分析用例场景时获取角色职责。如下图我们便可清晰指导用户在搜索内容的时候用户和系统分别要做的事情。
用户搜索内容流程
时序图
时序图经常用来描述对象之间在一个流程中的消息通讯关系。它更加强调消息事件的发生顺序，更方便于阐述事件的过程，但是却难以表达对象之间的关系。所以我们经常会看到它出现在需要解释复杂的对象通讯的地方如下图的微信支付消息流程
微信支付消息流程
如何用模型来更快速的理清一个系统
书本用了5种业务模型来展开设计不同阶段的设计。
业务模型
业务模式相对系统模型来说是对显示业务的理解，没有加入其他元素更容易在客户和开发双方达成共同理解。这点和系统模型是有点不同，系统模型相对企业内部的。下面这张图我也修改了一下直接用到自己产品设计
概念模型
概念模型分析是从业务模型中挑选出重要和典型的业务用力场景，绘制这些概念用例如何贡献或者实现业务用例。作为位于业务用例和系统用例模型的中间过度模型，有时候甚至不需要在文档中出现。概念模型用来分析和确认业务需求，而系统用例模型用来规定系统开放需求。
分析模型
分析模型架起现实世界和对象世界的桥梁，即它考虑整体的数据扭转还有服务架构等细节就像后面文章说的考虑接口的问题。分析模型高于设计模型最主要的是业务分析和系统分析都是由它完成。
通过以上3种模型的足以解决日常的产品架构上的设计。在实现业务前，先要确定系统的边界（就是我们到底要做什么功能，功能要做多深入），然后通过是边界，然后通过分割内容（即文章提及包的概念），最后通过业务模型再到分析模型到设计模型就能完成一个完整项目设计。
大象
先简要概述这本书的内容，本书主要是讲一种如何以对象的思考方式将复杂化的业务用其的建模方法的方法形象的表达出来。整本书也是围绕UML 的语言概念展开，如定义其元素：用例，业务，包，关系，组件，节点。又通过其语法如：视图和模型来完成一个业务的分析。最后通过一个例子来强化UML的语法。
作者在文章最后一篇还帮我们扩展关于设计的思考。包括理解用例本质、理解建模的抽象层次、学会设计模式等都是为了让我们更扎实的思考底层设计思维和方法论这样才能更好运用UML 。
其实学过编程的人妥妥发现这本书就是文字版的编程产品设计思维。从头到尾都是编程的面向对象思维。所以在刚开始接触这本书的时候我的第一印象是真的很无趣，甚至挑选读了100来页之后觉，心里嘀咕就这？不就是编程的思维把他写成书吗？
再到后来我在产品设计上遇到一些困惑后，决定重新拿起这本书来读的时候解决了我很多问题后，觉得真香。所以在读一本书的时候，最好是带着困惑去读，不然会读完索然无味，如果没有疑惑或者好奇，那么我宁愿不读。那么就让我们带着问题来了解这本书。
1.什么是建模？为什么要用UML建模？
2.uml 核心图能做什么？
3.如何用模型来快速理清一个系统？
什么是建模？为什么要用UML建模？
建模，是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物的理解，同时把这种理解概念化，将这些逻辑组织起来，构成一种对所观察的对象对内部结构和工作眼里的便于理解的表达。
打个比方，如果你看到一座美丽的山。你特别想留住眼前的美景。你通过对这种山用各种不同的角度如：高度，宽度，美丽程度，植被的覆盖度，等多个角度的描述的过程就是建模的过程。而角度的不同决定就是建模方向的不同。描述角度越全面你面前的这座山就更接近它本身。
在面向对象出现之前，有大量的编程语言都是面向过程的，如C，pthen语言、汇编等。开发人员很难从设计中推导出需要的对象，很容易业务变化就会被牵着走。举个例子假设把切好的西瓜放到冰箱冷藏。
那么面向过程设计思路就是：
- 拿到西瓜
- 切成合适的分量
- 放到冰箱
而如果是面向对象的设计思路是：
- 准备不同的工具
- 拿到不同水果
- 选择合适的切法
- 放到冰箱
发现没有，如果我下次拿的是橙子的话，那么面向过程就需要重新再编写和操作一遍。而面向对象就只需要把橙子扔过去，他就能放入冰箱。
而UML出现就是为了解决编程很难从设计中推导出对象的问题。通过UML的基本元素如组件，关系等结合分析模型和核心视图把现实复杂的业务通过面向对象的思路设计出来。
UML核心图能做什么？
如果用文字表述一个复杂业务流程的话，相信没有上千字也有几百字。图的出现恰好解决了这一难题。
UML 视图分为静态视图和动态视图。静态视图主要用来表达结构特征的，而动态试图用来表达用户的行为特性。可以说静态静态图是动态图的基础。下面结合查询到的资料介绍日常用到频率最多的视图。
静态视图包含：用例图（业务用例视图，业务用例实现图，系统用例视图，系统用例实现图），类图（概念层类图，说明层类图，实现层类图），包图（展示层次关系）。
业务用例实现图
业务用例实现图展现业务用例有哪些实现方式，可以更方便我们梳理业务查缺补漏看自己是否设计差什么内容。
类图
类图一般用来描述对象的属性和方法是从现实世界过度到代码世界的一种方法。
如果把多个图类通过类图关系关联起来(泛化、实现、依赖、关联、聚合、组合)则可用于数据库设计也是作者书中提及的设计模式阶段需要做的事情，对应到产品就是信息结构。
对象类图
类图关系链接
动态视图包括：活动图（泳道图，对象活动图，用例活动图）、状态图、时序图（业务模型时序图、概念模型时序图、设计模型时序图）、协作图。
状态图
描述某个事物状态改变的过程
如下图围绕着图书馆书籍整个生命周期状态绘制的状态图
活动图
作为描述某一对象通过多个动作完成的某项工作的过程。如下图包含整个办理登记流程的活动。
办理登记活动流程
泳道图
泳道图最主要的用途就是在分析用例场景时获取角色职责。如下图我们便可清晰指导用户在搜索内容的时候用户和系统分别要做的事情。
用户搜索内容流程
时序图
时序图经常用来描述对象之间在一个流程中的消息通讯关系。它更加强调消息事件的发生顺序，更方便于阐述事件的过程，但是却难以表达对象之间的关系。所以我们经常会看到它出现在需要解释复杂的对象通讯的地方如下图的微信支付消息流程
微信支付消息流程
如何用模型来更快速的理清一个系统
书本用了5种业务模型来展开设计不同阶段的设计。
业务模型
业务模式相对系统模型来说是对显示业务的理解，没有加入其他元素更容易在客户和开发双方达成共同理解。这点和系统模型是有点不同，系统模型相对企业内部的。下面这张图我也修改了一下直接用到自己产品设计
概念模型
概念模型分析是从业务模型中挑选出重要和典型的业务用力场景，绘制这些概念用例如何贡献或者实现业务用例。作为位于业务用例和系统用例模型的中间过度模型，有时候甚至不需要在文档中出现。概念模型用来分析和确认业务需求，而系统用例模型用来规定系统开放需求。
分析模型
分析模型架起现实世界和对象世界的桥梁，即它考虑整体的数据扭转还有服务架构等细节就像后面文章说的考虑接口的问题。分析模型高于设计模型最主要的是业务分析和系统分析都是由它完成。
通过以上3种模型的足以解决日常的产品架构上的设计。在实现业务前，先要确定系统的边界（就是我们到底要做什么功能，功能要做多深入），然后通过是边界，然后通过分割内容（即文章提及包的概念），最后通过业务模型再到分析模型到设计模型就能完成一个完整项目设计。