第一节 软件工程三个要素的价值

　　 思考问题的方法可以是由点及面的，也可以是统揽全局的。换成业界最常用的词汇，就是“自上而下”还是“自下而上”的区别。

　　 “牛屎图”中描述的工具、方法与过程也被称为软件工程的三个要素。在本书中他们被分解开来思考，并不是要孤立这个三个层面——它们实际上是相互作用的。

　　 例如“过程”问题，就既有实施过程的工具，也有相关的过程方法理论。我虽然说方法是“基于一种数据结构的编程实践的结果”，但这实在一种非常狭义的定义。这个定义在过程的开发环节上是有效的(或者说是对“开发方法”的定义)。然而“需求”、  “设计”、  “测试”等其他环节也有各自的方法论，即使站在具体环节之外，过程本身也有方法论的问题，这还不包括管理方法等在内。

　　 由于方法在过程环节及过程总体层面上具有贯通性，因此保证“方法(或其行为)”的实施的“工具”也会出现在过程的各个环节和层面上。这样一来，我们得到的软件工程模型将不是经典的、层状的“牛屎图”，而可能像太极图一样由阴阳交汇而生万物。

　　 为了不使读者认为我已经人了道家理论的歧途，这样的一副图还是交由你自己去画吧。只不过你应该清楚，即使画出了太极图的软件工程模型，你所视见到的仍旧是工程的细部环节。就如同以管窥豹一般，斑是斑，豹是豹。

　　 你能把每一个“管见”拼合起来，你得到的才能是“豹”，而不是“斑”。所以尽管本书割裂了软件工程的各个要素，并从每个孤立的层面来审视。然而实质上，你应该回归到电子商务软件工程的本体上来思考问题，而不是仅关注于每一个局部的要素。

　　 工程的整体问题仍旧是“实现”。

第二节 其实RUP是一个杂物箱

　　 我或许总是在批评RUP，但是我不得不承认它是对前人在软件过程思想方面的高度包容。

　　 请注意我用“包容”这个词，而不是按照语言习惯那样用“概括”。因为如果是“高度概括”，那你应该把目光投向瀑布模型，而RUP其实就像一个杂物箱一样“包容”了全部的已知理论。

　　 你可以把RUP定制成其他任何模型所表述的过程形态——RUP本身的特质决定了这一点——因而它也如同一个杂物箱一样放满了各种稀奇古怪的东西。你可能从这个杂物箱里面拿出了一把剪刀，或一只苍蝇拍，或者是一根钓杆……

　　 喂，等等。面对“软件开发”这样的一个需求，钓杆能有什么作用呢?在你扔掉它之前，请转换一下你的思维：钓杆可能带给你的团队以精神上的激励。如果你能意识到这一点，那么它将立即转化为生产力：把钓杆挂在开发部的墙上。

　　 RUP能不能被用起来，将取决于你刚才那个挑挑捡捡的行为，以及现在你在拿到钓杆后的辨识能力与组织能力。

第三节 UML与甲骨文之间的异同

　　 在你真的打算用甲骨文来写项目文档之前，请先明确UML与甲骨文之间的异同。

　　 在这本书里，他们都被作为沟通的工具。因此目标是沟通，而不是“选用工具”这件事本身。更进一步的推论是：即使你因为个人喜好而选择了甲骨文，也不要试图在结绳记事的原始人面前去用它。

　　 UML与甲骨文都是符号文字，都具有象形含义。然而这并不表明UML符号本身能表达多么丰富的含义。如果要像甲骨文一样用几代人、上千册的论著去解释它，那么UML图的价值也就只剩下象征性的意义了。

　　 出于沟通的必要，这种语言的象征意义在一个图中应当被表述得足够准确和详细，乃至针对于不同的阅读者来说都能提供充足的信息。然而，一方面UML的规范中没有提供一个标准来衡量“怎样的UML图是描述充分的”；另一方面，UML作为一个语言，也无法直接在某个环境或场景中被语法检错和调试。

　　 所以在工程中使用UML图，应该有相应的文字来描述它。而且这种描述与图之间的对应关系要持续地维护下去。如果这种关系松散了、断裂了，那么下一个阅读UML图的人所面对的，将是无异于甲骨文出土时的困境。

　　 好在做UML图的那个工程设计人员(在辞世之前)还有机会为这些古符号写下规约。

读过这篇文章的人还读过：

ERP系统实施应用 信息共享“功夫在诗外”

最全面的企业ERP实施规划感悟

企业如何申请电子发票和开具电子发票