《大象——Thinking in UML》读书笔记一（建模基础）

 

建模基础

现实世界	UML业务模型
什么人	参与者（actor）
使用什么规则	业务场景（business scenario） 用例场景（use case scenario）
干什么事	用例（use case）
产生什么物	业务对象模型（business object model）

现实世界	UML业务模型	UML概念模型
什么人	参与者（actor）	用户（user）
使用什么规则	业务场景（business scenario） 用例场景（use case scenario）	控制类（control）
干什么事	用例（use case）	边界类（boundary）
产生什么物	业务对象模型（business object model）	实体类（entity）

建模

什么是建模？书中从两个方面进行了阐述，即“怎么建？”以及“何为模”。

“怎么建”这个问题比较容易理解，即“目的”，明确了目的就知道该如何建了。书中使用“抽象角度”一词来解释怎么建，这个词本身就很抽象，使用“目的”一词比较容易理解。怎么建……？那就看你的目的是什么，明确了目的（书中描述为“确定了抽象角度”）也就知道该如何建了。

“何为模”这个问题较难理解，应该是需要逐步理解消化的。书中明确指出“模”就是：人，事，物，规则。就是上面的那张表中的红色字体。书中为了解释“模”这个概念，引入了一个新的词汇“场景”，这个词初看容易理解，但细想起来也是那么抽象，书中给出了一个对于场景一词的解释，使用的是一个公式：

 

特定的场景（事）=静态的事物（物）+特定的条件（规则）+特定的动作（参与者的驱动）（自己的理解：这里也可以理解为人）

--以下公式摘自书中，这里原样搬过来，全当便于以后理解

• 问题领域 = Σ抽象角度（1——N）
• 抽象角度 - 问题领域边界之外的的参与者的业务目标 = 业务用例
• 业务用例 = Σ特定场景（1——N）
• 特定场景 = 静态的事物 + 特定的条件 + 特定的动作 或者
• 特定的事 = 特定的事物 + 特定的规则 + 特定的人的行为

用例驱动

完全搞不明白的一章 ，大体上说的是由用例视图可以推导出另外4种视图，他们是：逻辑视图、进程视图、部署视图、实施视图。这4个视图是什么意思？完全不懂，和RUP以及UML有啥关系？仍然不懂。只能记录下来以后看能理解不！

 

抽象层次

比较好理解的一章。

抽象层次越高，具体的信息越少，概括能力越强（也就是便于人类理解），抽象层次越低，具体信息越多，概括能力越弱（也就是不便于人类理解）。这句话理解不了？那就理解石头的硬度，说石头很硬（抽象）和说石头有摩氏5度（具体）。

值得注意的是，抽象方法有两种，一种自上而下，一种自下而上。通常软件开发采用的是自上而下。这里再次出现“迭代”字样，对RUP中所推崇的迭代方法在看到这里时，若隐若现的有点感觉了，映射到实际中就是 [业务建模]——[概念建模]——[系统建模]——[设计实现]—（迭代）—[业务建模]……

 

视图

好理解难应用的东西。

视图就是事物个各个方面（属性）。

视角是针对每一个视图来说的。那么视图和视角有什么区别？或者说有什么必然联系？（这里不是特别清晰，目前只能做到如下理解）

视图：为特定的信息显示正确的视图。（自己的理解：视图是针对物而言）

视角：为特定的干系人展示正确的视角。（自己的理解：视角是针对参与者而言）

 

对象分析方法

• 一切都是对象
• 对象是独立的：这个论点需要理解3个概念，他们是：对象、对象实例、场景。对象是独立存在的，对象映射到场景中成为对象实例。换言之，通过一个场景，我们仅能得到对象的一个侧面的信息。因此对方的分析方法就是，分析各个场景中的对象实例，提取共同点从而得到对象。
• 对象都具有原子性
• 对象都是可以抽象的：（这一点比较难理解，目前有点理解不透彻，比如下面的原文叙述）对象有多个方面，对象参与一个场景会展现其一个方面，总可以将对象的某一个方面抽象出来，让其作为对象的一个代表来参与场景交换。通常这种抽象会以接口来命名
• 对象都有层次性