建模基础
现实世界 | 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个概念,他们是:对象、对象实例、场景。对象是独立存在的,对象映射到场景中成为对象实例。换言之,通过一个场景,我们仅能得到对象的一个侧面的信息。因此对方的分析方法就是,分析各个场景中的对象实例,提取共同点从而得到对象。
- 对象都具有原子性
- 对象都是可以抽象的:(这一点比较难理解,目前有点理解不透彻,比如下面的原文叙述)对象有多个方面,对象参与一个场景会展现其一个方面,总可以将对象的某一个方面抽象出来,让其作为对象的一个代表来参与场景交换。通常这种抽象会以接口来命名
- 对象都有层次性