零雨其蒙《UML和模式应用》学习笔记（一）

零雨其蒙《UML和模式应用》学习笔记（一）

UML 和模式学习笔记

(零雨其蒙原创 转载请注明) 

本书中的英文

Ledger 分类帐

Payment n. 支付现金

Sale 销售

SalesLineItem 商品条目

Quantity   数量（每一小项的数量）

Amount    数量，总计（钱）

ProductCatalog    产品目录

Register   记录器（指 POS 机）

Credit AuthorizationService 信用卡授权服务

TaxCalculator 税金计算器

Account  财务

Inventory   库存

Approval 批准 requestApproval 请求批准

Discount 折扣

 

Manufacturer 制造商

 

Piece  块（指的应该是棋子）

Die    骰（色）子

Square 格子（棋盘上的格子）

Board  板子（指棋盘）

Cup    骰（色）盅

 

Assembly  部件

 

 

第 2 章 迭代、进化和敏捷

开发案例

为项目选择实践和 UP 制品可以编写为简短文档，这称为开发案例。

 

 

科目	实践	制品 迭代→	初始 I1	细化 E1 … En	构造 C1 … Cn	移交 T1 … Tn
业务建模	敏捷建模 需求讨论会	领域模型		s
需求	需求讨论会	用例模型	s	r
		设想	s	r
		补充性规格说明	s	r
		词汇表	s	r
设计	敏捷建模 测试驱动开发	设计模型		s	r
		软件架构文档		s
		数据模型		s	r
实现	测试驱动开发 结对编程 持续集成 编码标准			s	r	r
项目管理	敏捷项目管理 Scrum 每日例会		s	r	r	r
……

S 表示开始     r 表示精化

第 10 章 系统顺序图

系统事件与系统操作

系统事件， 就是外部输入事件

系统操作 ，就是处理系统事件的操作

 

 

2007 年 3 月 3 日星期六

 

第 13 章 逻辑架构和 UML 包图

 

层（ Layer ）

是对类、包或子系统的甚为粗颗粒度分组，具有对系统主要方面加以内聚的职责。 OO 系统中通常包括的层有：

l         用户界面（ UI ）

l         应用逻辑和领域对象（ domain ）：表示领域概念的软件对象，这些对象实现了应用需求

l         技术服务（ Service ）：提供技术性技术服务的常用对象和子系统，例如数据库接口或错误日志。（ Persistence ， Logging ）

在 springframework 的 jpetstore 例子中的结构就是如此，我是按其目录划分来理解这些层次的。它分为 web （表现层，提供了 spring mvc 和 struts 两种 mvc 框架）、 dao （其中的 iBatis 目录是 dao 目录的接口的实现类和辅助类）、 service （里面包含了 web service 提供的远程服务）、 domain （包括了领域对象，其中的 logic 目录则是一些业务逻辑）。

我觉得在 150 页的图 13-4 更好的细分了信息系统逻辑架构中常见的层。

l         UI （ Presentation,View ）

l         Application(Workflow,Process,Mediation,App Controller)

l         Domain(Business,Application Logic,ZModel)

l         Business infrastructure(Low-Level Business Services)

l         Technical Services(Technical Infrastructure,High-level Technical Services)

l         Foundation(Core Services,Base Services,Low-level Technical Services/Infrastructure)

而在 153 页给出的架构的混合视图，给出了一个基本完整（不包含 UI ）的架构逻辑视图，并对好的设计和不好的设计进行了对比。

Tier 和 Layer

我在 2006 年的夏天曾经仔细研究了这个问题，当时的结论是 Layer 倾向于逻辑层， Tier 倾向于物理层。而在 Larman 的这本书里他给出了一个带有历史进程意味的 Tier 的定义： tier 在架构中最初表示的是逻辑层（ Logic Layer ），而不是物理节点，但是现在，这个词被广泛用于表示物理进程节点（或节点簇），例如“客户层”（客户计算机）。

而后， Larman 给出了对比了 layer 和 partition ，前者是对系统的垂直划分，后者是水平划分，形成相对平行的子系统。比如技术服务层（ service ）可以划分为安全（ Security ）、持久化（ Persistence ）等分区。在这里我再一次很佩服 Larman 对问题的阐述能力，以前在《程序员》上看过一篇讲分层结构的正交分解的文章，当时可能也是我水平有限，所以看得还是比较糊涂。

 

领域层和领域模型之间的关系

其实这个问题在学习领域模型时已经探讨过了，不过现在则更清楚，领域模型是分析阶段的将重要的领域概念可视化的结果，而领域层则是软件设计中领域对象和领域规则的集合，在这里我觉得领域对象和领域规则的关系是领域对象内部包含一部份领域规则，而一部分领域规则则是依赖很多领域对象来完成的。

就像我以前主张的一样，类的定义要有现实意义，比如 People 类就应该只干人事，公鸡类就不应该有下蛋的方法，而 OO 技术则倡导由领域模型来获得领域层类命名的灵感。这种做法叫作现实世界与软件设计之间的低表示差异。

 

模型——视图分离原则

 

这一部分的论述帮我找到了先前研究 MVC 最大的一个疑惑，就是 Model 到底指的是什么？ Larman 在 154 页做了回答：在这种语境下（应该指的是前面提到的分层架构（ Layered Architecture ，它的先驱是在 [BMRSS96] 中描述的层模式（ layers pattern ））这个语境下），模型是领域层对象的同义词（源于 20 世纪 70 年代末的陈旧术语）。视图是 UI 对象的同义词，例如窗口、 Web 页面、 applet 和报表。

 

关于 MVC 的进一步理解

 

我一直在寻求一份 MVC 中各个元素是什么的标准答案，在介绍模型—视图分离原则时下面有一段注释（不知道是不是 Larman 本人的注释，不过该书的注释部分似乎有这样的规范：如果是译者添加的注释，则在注释后面写上译者注，由此判断此处的注释是作者原文的注释）：这（指模型—视图分离原则）是模型—视图—控制器（ MVC ）模式的关键原则。 MVC 源于一个小型的 Smalltalk-80 模式，与数据对象（模型）、 GUI 小部件（视图）和鼠标、键盘事件句柄（控制器）相关。近来，术语“ MVC ”被分布式设计团队采纳，将其应用在大规模的架构上。 MVC 中的模型指领域层、视图指 UI 层、控制器指应用层的工作流对象。 以前，我一直在模型是指数据模型还是指领域层（那些能够处理业务逻辑的类——那时我还不知道他们叫领域层对象），而上面这段说法使我比较信服。说 M 表示数据对象也不错，不过那是 Smalltalk-80 朝代的事情了，就像说 PHP 是个人主页工具（ Personal Home Page ）的缩写也是正确的一样，不过那是它最早的名字。

 

UML 包图

通常用于描述系统的逻辑架构——层、子系统、包（就 Java 而言，那么就 .Net 而言指的就应该是命名空间了）。 UML 包提供了组织元素的方式。 UML 包能够组织任何事物：类、其他包、用例等。

第 14 章 迈向对象设计

    159 页介绍的一个重要的学习 UML 图的准则就是：应该把时间花费在交互图（顺序图或通信图），而不仅是类图上。忽视这一准则是十分常见的 UML 错误实践。

这一点在我当初学习 UML 时就深深感到，当我们花类图时还感觉比较容易，而到了交互图则感到十分的困难，往往不知道怎么画，于是从那时到现在我一直依靠类图来进行设计和代码生成（类图只是帮助我来定义单个类，而对于类之间的关系就不考虑了，不过这已经很有用了）。

 

第 15 章 UML 交互图

UML 顺序图中的图框 P168

图框操作 符	含 义
alt	选择性的片断，用于表示保护信息所表达的互斥条件逻 辑
loop	用于表示保护信息为真的循环片断。也可以写为 loop （ n ）以指名循环的次数。这样能够增强规格说明，用以表示 FOR 循环，例如 loop （ i ， 1 ， 10 ）
opt	当保护信息为真时执行的可选片 断
par	并行执行的并行片 断
region	只能执行一个线程的临界片 断

保护信息 指的是 loop 后面的 [more items] ，和 opt 后面的 [color=red] 党这些保护信息为真时将执行该片断。

 

生命线参与者应该表示一个对象，而不是集合。如 lineItems[i] ： SalesLineItem 。 （ P170 图 15-16 ）

 

顺序图就是序列图（翻译方法不同），通信图就是协作图（叫法不同），它们合成交互图

第 16 章 UML 类图

UML 用类图（ class diagram ）表示类、接口及其关联。

 

表示 UML 类图属性的方式：属性文本和关联线

准则：对数据类型对象使用属性文本表示法，对其他对象使用关联线。

 

UML 操作与方法

P186 UML 操作是声明， 其中包括名称、参数、返回类型、异常列表、可能的前置和后置条件约束等。但是操作不是实现，而方法是实现。

 

UML 方法（ method ）是操作的实现。表示方法：

l         在交互图中，通过消息的细节和顺序来表示。

l         在类图中，使用构造型为 <<method>> 的 UML 注解符号

 

类元：

是“描述行为和结构特性的模型元素” [OMG03b] 。类元也可以被特化。它们（指类元）是对众多 UML 元素（指被特化的类元）的泛化。这些元素包括类、接口、用例和参与者。在类图中，最常用的两个类元是常规的类和接口。（泛化和特化看上去像是一对反义词）

 

泛化

泛化（ generalization ） 用由子类到超类的 -----|> 表示。

UML 对泛化的定义：

泛化——普通的类元与特殊的类元之间的分类学关系。特殊类元的每个实例也是普通类元的间接实例。因此，特殊类元间接的拥有了普通类元的特性。

 

P298 泛化 是识别概念之间的共性部分并定义超类（泛化概念）和子类（特化概念）关系的活动。它是在概念间构建分类的方法，这些概念将在类层次结构中加以描述。

泛化与继承

（超类和子类的关系）

对于领域模型，超类是超集，而子类是子集。

对于 DCD 软件视角的类图，泛化 = 由超类到子类的 OOPL （ OO 编程语言）继承。

 

依赖

UML 中的依赖： 表示客户（ client ）元素 （任何种类，包括类、包、用例等）了解其他的提供者（ supplier ）元素 ，并且表示当提供者有所改变时会对客户产生影响。

 

在对象图和类图中比较常见的类型：

l         拥有提供者类型的属性（通过表示属性的关联线表示）

l         向提供者发送消息。对提供者的可见性可能是：属性、参数变量、局部变量、全局变量或类的可见性（调用静态或类的方法） √

l         接收提供者类型的参数 √

l         提供者 是超类或接口（通过表示泛化的线表示）

√ 表示需要使用依赖线

不需要使用依赖线 的情况：

l         表示超类的特殊的 UML 类

l         表示接口实现的线

l         表示属性的线（以关联表示属性的线）

 

何时使用依赖线

在类图中，使用依赖线描述对象之间的全局变量、参数变量、局部变量和静态方法（对其他类的静态方法加以调用）的依赖。

 

依赖与耦合

依赖可视为耦合（ coupling ）的另一个版本 ，耦合是软件开发中的传统术语，意为某元素耦合或依赖于另一个元素。

 

耦合是对某元素与其他元素之间的连接、感知和依赖程度的度量（ P216 ）。

组合（ composition ）：

1 ）在某一时刻，部分的实例只属于一个组成实例； 2 ）部分必须总是属于组成（不存在随意游离的 Fingers ）； 3 ）组成要复杂创建和删除其部分，既可以自己来创建 / 删除部分，也可以与其他对象协作来创建 / 删除部分。 ◆----表示拥有-部分

 

限定关联：

一般来说，在软件透视图中，限定关联暗示了基于键对事物进行查找，如 HashMap 中的对象。

 

UML 表示静态类成员

UML 表示法：在类框图中，具有下划线的属性或方法表示静态类（类级别）成员，而不是实例成员。 Instance ： ServicesFactory ， getInstance （）： ServicesFactory