软件工程实践者的思想(PDF格式)-第13部分
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
Aspect 关注于“有相似需求的考察对象”的群体特性。其
相似性在群体中表现得越广泛，则 AOP 的优势也就越明
显。例如在 Delphi 的 VCL 框架中，以下两个需求就可以
① 人们在争论Aspect 到底应该译成“切面”还是“方面”这件事上
花了很多功夫。其实，就如同讨论前面的“关注点”究竟是“点”
还是“线”的问题一样，他们陷入了细节。如果这些细节被作为
问题持续下去，那么可能有一天台海战争将不是发生在军队之间，
而是在程序员之间：到底是“物件”，还是“对象”？
② 在C 中，这个名词是“结构（Struct） ”。很多人不会承认“对象是
有继承关系的记录”这样的观点。是的，所有的教科书上都不会
这样写。但是从数据结构本身以及数据结构在语言中的实现来看，
对象终究是记录。记录是平板化的内存存储体系中所能表达的最
复杂的单一数据体。
…94
…………………………………………………………Page 99……………………………………………………………
『大道至简』
用 AOP 的思想来实现：
） 使 Delphi 中的全部对象具有多线程特性（ 即线程
安全） ；
） 实现助手工具类以观察、控制 Delphi 对象的运
行期特性或表现。
到现在为止，我们弄清楚了 AOP 作为“思想、方法、
工具”的一些基本知识，以及它的应用范围：至少你要明
白，他是用来考察对象（而不是设计对象） 的思想方法。
所以接下来 AOP 的三个概念我们就明白了：
） 指示（advice）/拦截器（interceptor） ：考察这些对象
以“达到什么样的目的”（ 即需求） ；
） 引导（introduction） ：在目标上实现这些需求时，
目标所需要表现出来的公共特性。引导特性可能
需要配合编译器来实现。
） 元数据（metadata） ：如果需要，为既有对象实体
再补充一些参考数据。
确切的说，切分点（Pointcut）并不是 AOP 编程方法所
需要的概念，而是 AOP 作为一个框架时所需要的一个工
具：一组辨识 Acpects 和 Objects 的索引。
现在你已经会用 Acpect 的思想来编程了，而无论它
是用 Java 来实现的，或者是用 C# 、Delphi ，乃至于
FORTRAN 或 COBOL 。你需要做的是，回到工程最核心
的那个环节：编程＝算法＋结构＋方法。
…95
…………………………………………………………Page 100……………………………………………………………
第 7 章 现实中的软件工程
5。 审视 MDA/MDD
MDA（Model Driven Architecture） 也是一个方法论层
面上的名词。它讨论的是“创建出机器可读和高度抽象的
模 型 ” 的 方 法 。 受 MDA 影 响 的 开 发 活 动 被 称 为
MDD（Model Driven Development） 。
与 MDD 在同一个层面上的概念是：
） TDD（Test Driven Development）
） FDD（Feature Driven Development）
） BDD（Business Driven Development）
） R…TDD（Rapid Template…Driven
Development）
） CDD（Contract Driven Development）
） RDD（Requirements Driven Development）
） 。。。
我不厌其烦地罗列这些名词，只想告诉读者一个事
实：什么都可以“驱动开发”。
不同的方案提供商基于自己的产品构架和当前的理
论倾向，随时都在准备改变他们“驱动开发”的方式。在
这种形势下的 “xDD ”或“xDA ”，已经成为他们促销产
品的保留用词。
回到软件工程的过程环节中来吧，你会看到，“以什
么驱动开发”只是一个“以哪个环节为中心（或导引） ”的
问题。所以你会看到 TDD 中的 X 模型（也可参考 V 模型）
是这样的：
…96
…………………………………………………………Page 101……………………………………………………………
『大道至简』
如果你仍旧不能明白为什么会有这么多被神秘力量
所“驱动着的开发”，那么你就干脆去厨房找个平底锅烧
点热油，然后敲下一个鸡蛋，很快，你就体悟“以蛋黄驱
动开发”的真谛了。
抛开实现的技术细节不论，在工程中，“以什么驱动
开发”其实是一个过程问题。而你应该明白，过程的选择
（或制定）取决于你的工程需要，以及它在相关应用领域的
适用性、过程工具的充备性和这个过程理论的完善程度，
而不是大公司们的鼓吹。
过程模型决定了工程的实施步骤和组织方式。但是
Object Management Group （OMG） 尽管对 MDA 提出了一
套完备的技术和方法体系，工程实施者却无法在这个体系
中找到一个可以适用的软件过程模型。——MDA 不讨论
过程。
…97
…………………………………………………………Page 102……………………………………………………………
第 7 章 现实中的软件工程
也就是说，MDA 架构作为一个新的软件开发方法的
架构，即使在技术研究、底层协议和软件实现方面经过了
持续地完善而渐至成熟，然而如果没有同样成熟的软件过
程理论支持，那么它在工程中的实用价值也就有限。
仔细审视一下这个 MDA ，如果你现在就决定将下一
个工程项目建立在这个构架的基础上，或者用 MDD 的方
式来开发 BIOS ，那么你离精神病就不远了。
…98
…………………………………………………………Page 103……………………………………………………………
第8章 是思考还是思想
“此郎亦管中窥豹，时见一斑。”
——《晋书·王献之传》
1。 软件工程三个要素的价值
思考问题的方法可以是由点及面的，也可以是统揽全
局的。换成业界最常用的词汇，就是“自上而下”还是“自
下而上”的区别。
“牛屎图”中描述的工具、方法与过程也被称为软件
工程的三个要素。在本书中他们被分解开来思考，并不是
要孤立这个三个层面。——它们实际上是相互作用的。
例如“过程”问题，就既有实施过程的工具，也有相
关的过程方法理论。我虽然说方法是“基于一种数据结构
的编程实践的结果”，但这实在一种非常狭义的定义。这
个定义在过程的开发环节是有效的（或者说是对“开发方
法”的定义） 。然而“需求”、“设计”、“测试”等等其它
环节也有各自的方法论，即使站在具体环节之外，过程本
身也有方法论的问题，这还不包括管理方法等等在内。
由于方法在过程环节以及过程总体层面上具有贯通
性，因此保证“方法（或其行为） ”的实施的“工具”也会
…99
…………………………………………………………Page 104……………………………………………………………
第 8 章 是思考还是思想
出现在过程的各个环节和层面上。因此这样得到的软件工
程模型将不是经典的、层状的“牛屎图”，而可能象太极
图一样由阴阳交汇而生万物。
为了不使读者认为我已经入了道家理论的歧途，这样
的一副图还是交由你自己去画吧。只不过你应该清楚，即
使画出了太极图的软件工程模型，你所视见到的仍旧是工
程的细部环节。就如同以管窥豹一般，斑是斑，豹是豹。
你能把每一个“管见”拼合起来，你得到的才能是
“豹”，而不是“斑”。所以尽管本书割裂了软件工程的各
个要素，并从每个孤立的层面来审视。然而实质上，你应
该回归到软件工程的本体上来思考问题，而不是仅关注于
每一个局部的要素。
工程的整体问题仍旧是“实现”。
2。 其实 RUP 是一个杂物箱
我或许总是在批评 RUP ，但是我不得不承认它是对
前人在软件过程思想方面高度包容。
请注意我用“包容”这个词，而不是按照语言习惯那
样用“概括”。因为如果是“高度概括”，那你应该把目光
投向瀑布模型，而 RUP 其实就象一个杂物箱一样“包容”
了全部的已知理论。
你可以把 RUP 定制成其它任何模型所表述的过程形
态。——RUP 本身的特质决定了这一点。——因而它也
如同一个杂物箱一样放满了各种希奇古怪的东西。你可能
…100
…………………………………………………………Page 105……………………………………………………………
『大道至简』
从这个杂物箱里面拿出了一把剪刀，或一只苍蝇拍，或者
是一根钓杆……
喂，等等。面对“软件开发”这样的一个需求，钓杆
能有什么作用呢？在你扔掉它之前，请转换一下你的思
维：钓杆可能带给你的团队以精神上的激励。如果你能意
识到这一点，那么它将立即转化为生产力：把钓杆挂在开
发部的墙上。
RUP 能不能被用起来，将取决于在于你刚才那个挑
挑捡捡的行为，以及现在你在拿到钓杆后的辨识能力与组
织能力。
…101
…………………………………………………………Page 106……………………………………………………………
第 8 章 是思考还是思想
3。 UML 与甲骨文之间的异同
在你真的打算用甲骨文来写项目文档之前，请先明确
UML 与甲骨文之间的异同。
在这本书里，他们都被作为沟通的工具。因此目标是
沟通，而不是“选用工具”这件事本身。更进一步的推论
是：即使你因为个人喜好而选择了甲骨文，也不要试图在
结绳记事的原始人面前去用它。
UML 与甲骨文都是符号文字，都具有象形含义。然
而这并不表明 UML 符号本身能表达多么丰富的含义。如
果要象甲骨文一样用几代人、上千册的论著去解释它，那
么 UML 图的价值也就只剩下象征性的意义了。
出于沟通的必要，这种语言的象征意义在一个图中应
当被表述得足够准确和详细，乃至于针对于不同的阅读者
来说都能提供了充足的信息。然而，一方面 UML 的规范
中没有提供一个标准来衡量“怎样的 UML 图是描述充分
的”；另一方面，UML 作为一个语言，也无法直接在某个
硬件平台中被语法检错和调试。
所以在工程中使用 UML 图，应该有相应的文字来描
述它。而且这种描述与图之间的对应关系要持续地维护下
去。如果这种关系松散了、断裂了，那么下一个阅读 UML
图的人所面对的，将是无异于甲骨文出土时的困境。
…102
…………………………………………………………Page 107……………………………………………………………
『大道至简』
好在做 UML 图的那个工程设计人员（在辞世之前）还
有机会为这些古怪符号写下规约。
4。 经营者离开发者很远，反之亦然
使我第一次意识到 EHM 模型反映了角色所关注的不
同视角的人，是我的老板。
事实上，他是一个完全不懂软件技术的老板。在 EHM
模型中，他所处于的位置在最右端，而开发者在最左端，
在二者之间没有相同的关注界面（关注点） 。EHM 真实地反
应了“老板不懂技术
