《UML实务》序言

《UML实务》序言

曹伟（来自中国系统分析员） 　　2003年03月03日

我有话说……

　　路漫漫其修远兮
　　吾将上下而求索
　　　　　　　　　--屈原《离骚》

　　本书的读者的对象很广泛，没有什么限制，但是有一点应该注意，该书不是向读者介绍具体的软件开发，而是告诉读者一个开发的过程或思路，让读者知道如何使用程序设计语言来实现这个过程或思路。

　　在写如此的相关于软件工程的书之前，我想到卡内基梅隆大学软件工程研究院提出的软件过程（CMM），这个新名称我也是刚刚认识。但我很早的时候就知道戴明的关于企业管理的十四点精神，还认认真真抄了下来当成"座右铭"了。

　　软件开发怎么和管理来上关系，其实软件和什么都拉上关系，拉不上的也是左右邻居，最近人类智慧也被激活了，想了许多关于软件的问题，并提出方法来解决它。

　　唯一的一个人类共同的智慧：站在软件开发之外来看软件开发。

　　现在，本书还没有开始，那我们就先谈谈软件开发之外的事。

　　我以前是学习核物理的，由于是业余的，也没有压力，想学就学一点，不想学就去干其他的，很好！没办法在学习热力学的时候，关于熵焓的公式比较复杂，我一直有一个观点："东西复杂了就是好东西"，我就想在数学上一定有简单的方法，我开始学习数学，从基础数学开始，集合论、群论、拓扑学、图论…乱七八糟的，反正自己没事，就什么都学了，学吧自己又搞不清楚，搞不清楚的就忽略（ignore）。

　　后来，别人说集合论是数学基础，我开始留心集合论，发现有一批人比较喜欢它，一打听计算机系的，在离散数学中有这一节，一知道便没劲：为了考试。

　　计算机和离散数学有什么关系？先不说这个关系，我想和你讨论讨论现代物理上最高深的理论"爱氏相对论"，因为我学了，所以我说其很简单。

　　简单在那里？在我们看问题的角度，在其中者觉得问题不变，在其外者觉得问题在变。爱因斯坦的常用的例子是一列开动的火车，站在火车上的人觉得火车不动，站在火车外的人觉得火车在动。所以相对论给我们带来一个理论：站在不同的角度观察相同的物体得到不同的结果。现在我们就以此理论为基础来观测一个柜子：
　　我们很自然的知道我们在柜子的正面还是反面，现在我们把柜子的门拿下来当一个面，我们也可以知道该门的上面、下面及其左右。假如，把我们人反一下，我们再观测该门，情况就变了。好了，依此为基础我们来看看这个整柜子，把我们放在不同的边，不同的方向，我们得到观测柜子的不同结果。
　　假如我们在柜子里，我们反过来，柜子也跟着反过来了，固然没有什么变化。

　　再回到计算机和离散数学的问题？简单一点我们谈谈软件开发和集合(Set)的关系：在集合里有很简单的几种关系（我认为凡是看该书的人都知道，当然首先我们也知道集合是描述物体间简单的相互关系的。）：交集、并集、差集和补集等几个关系。

　　看看软件开发的程序设计语言，无论是Basic、c或Java 还是汇编都有一个共性：属性、方法和过程（在汇编不这么叫，但意义相同），这个共性与集合比较如下：
　　比如数组，就是有序的集合，对数组进行操作，把数组中的第几位数字拿出来放在一个新的数组（有序的）或集合中（无序的），该操作是函数来实现的。函数操作就是一系列机器操作的组合（操作集合），机器操作有转移指令等操作，该类操作不是数据从寄存器移出来就是移进去，现在高级的操作系统采用的内存呀，硬盘呀，就是来放一系列数据的，然后把数据从其中取出来，再放在另外的地方（该地方有一个标识码叫地址码）。

　　我们对有序集合的操作，取其运算，那就是对集合的交并差补，数学上的算法仅仅是个法则，正如加法就是两个集合的并集，乘法是根据加法的规则来的一种数学法则，没有什么比集合运算更基础。

　　搞不搞清楚关于集合是否是数学的基础，这个并不重要，或者和我们现在拿在手的书一点关系也没有，但我现在想问一句：我们看这本书的目的是什么？是来学习如何编写程序的程序设计语言，还是来学习设计软件的软件设计语言？那么你会失望，我仅仅在介绍我们在设计我们的软件是需要什么样的思想。在书籍中有如此的两本书《Thinking in java》和《Thinking in C++》,我是各买两本，一本放在书架上（收藏），一本放在案头（备查），计算机实用技术发展如此之快，但原理和基础还没有改变，但不是我们前面所说的数学基础，如果是那也就没有什么意义了，而这个基础就是我们在该书中看见的。

　　软件的行业被划分在信息产业领域中，软件开发和服务的技术又被广而称为IT技术，从制造出电子管开始，其所谓的IT行业就被高新技术的行业所包装，被包装的东西是难得见其内核的，但是我们在来研究软件的时候，很有必要知道我们面临的技术是那路神仙？

　　当我们关起门来讨论软件的核心技术或其他的什么技术的同时，我们已经把自己包装在计算机领域所谓的边缘性问题里。

　　我所说的边缘性问题并不同于现在工程技术领域内的边缘科学，而是说一种没有什么说明文字（Document）可以来表述，不能表述的在程序界就是没有定义（Define）的，除非是公理，不然就可能产生众多的争议。如此，我此的观点和你不同就是一种合理的存在。

　　关于软件的核心问题是每个程序员所关心的，一方面由于技术的问题一方面由于人的心理的问题导致的软件核心问题很神秘。

　　这个神秘的问题并不是如同历史学家研究"Mona-Lisa"的微笑，我从学校出来的一段日子里，很长很长的时间正为如此的问题而在心理上奔波。我是一个闲人，基本上每天有好几个小时用在对生活的思考上，思考的结果很简单-我写我一生中的唯一的一部小说（我决定不再写如同此类的玩意）。

　　计算机业界人事认为：软件的核心技术就是采用什么样的方式把软件生产出来。把如此让天下所有的人都不能反驳的话都说出来了，我固然没有反对意思，举双手赞成吧！

　　我是喜欢思考的人固然喜欢把一个问题拿过来切实地思考一下，我为什么赞成？赞成什么？为何赞成？

　　翻了一下2000年的历史文物-计算机软件工程规范，内部讲的连秦始皇都知道的1995年的Information-Technology(书上标识着信息技术)软件生存期过程的一个规范，我还真没有想到在"古老的"社会都已经拥有世界同步的技术。

　　别人在金字塔里得到了金子，而我在其里得到了"武林秘集"，虽然是基础的功夫，但久而练之，也能达到出神入化的境地。

　　视之，生存期中的活动可分为七个基本的、主要的生存期过程，我来解释：

　　过程有
　　1． 管理过程：从空洞地开始到空洞地结束的按机制约束的过程。
　　2． 获取过程：软件需求者和软件开发者相互给对方提要求过程。
　　3． 供应过程：软件开发者从需求者处获得资金而提供软件产品或和服务过程。
　　4． 开发过程：编写文档和代码过程。
　　5． 操作过程：软件需求这使用过程。
　　6． 维护过程：更改软件的不足的过程。
　　7． 支持过程：培训和引导用户使用的过程。

　　我看了半天很不明白，第一排序不明白，第二如何来分这些过程也不明白。举例示之：就操作过程、维护过程和支持过程等三个过程，其都在软件交付给用户使用的期间内发生的行为。就目前的所说的软件的需求分析、软件设计等最为重要的东西到那里去了？我们不能在老古董寻找新的东西（虽然OMG已经成立？年），就IT，我现在认为I和T的等同位置。不管以前的东西如何，我们都必须有一个建立、评价和改进的过程。

　　原始的过程如下：

　　画了这个图，我一下子想起去年我做工程的时候，由于软件的种种原因我们工程部可是大江南北地跑断了腿，比一揽子事务还多，为何有如此多的事，听我慢慢讲。工程实在不想维护了，改行做ERP了，这下可害了我们原始的客户了，每每和同事谈起，就觉得该做一个工程管理软件来协调那些乱七八糟事。

　　ERP：我个人认为我们的ERP就是卖管理解决方案给别人。从IBM的转型计算机领域的发展已经开始向服务性转变，当然这个不IBM的带来的，但至少是个阶段性的标志，而ERP就是这类服务的一种。

　　但期间由于情绪化加上其他的问题，在我们的大脑里形成一个固定的模式：做软件开发的比做需求分析的、工程管理的和技术支持的地位要高。既然在大脑里形成了这个模式，在日常生活中就表现出来，当然首先在办公条件和薪资上。

　　不是我，是领导没有想到，由于等级的观念导致每个类型的人仅仅在内部沟通，开发出来的系统出现严重地和市场和工程规范不衔接，脱离实际。每个人在开会的时候都在强调对方给予的支持和协调，但会后又开始"闭门锁国"。
首先我就应该想到：软件开发的核心问题是人，是相互协调的人。

　　想问题最让人憔悴！

　　软件开发观点之一：相互协调的人和人协调做了有条不紊的事。

　　思考是发现问题的根源。

　　从系统的需求分析过程开始，分析软件各过程实施和控制。（仍以1995年观点分析，分析起来很艰难，但是从这个向UML的进化中容易分析UML的本质）

1．管理过程

　　我们需要干什么？：我们必须为我们的工作定一个范围。
　　需要的干的内容？：计划（该时期是Plan phase）
　　如何实施计划？：如何以建模的方式来开始。
　　评审实施结果？：管理层的种种机制。
　　完成交货？：合同期间的问题和工程实施。

　　还有个问题是细节上东西，在设计初期，许多问题都不一定可见：
　　就是我们计划的详细程度？
　　设施过程的步骤的详细程度？
　　评审的详细程度？

　　这个细节上的东西需要量化，需要把时间规定到小时，把实施细节规定到极其微小的模块。说一个案例（Case）：我原先从通讯软件的开发，有一个很大的项目，我们技术总监不能在宏观上完全把握了，所以这个项目一直拖着，原因太简单，他不出分析结果谁也无法开始实施，事情是这样说了，但不是完全错误的，一：技术总监不是管理层人，是个程序编码的高手，这里的设计是他的程序框架；二：他并不是不在写程序代码，而是无法把握该如何写，写一点后发现和系统有出入，重来，然后再重来……

　　该问题并不是我们程序无法进行编写，而是我们在想一个问题，我们在编一个什么系统，该系统有多大，每个模块间的关联，如何关联，给以后升级的系统留有什么接口，如此等等，我们是一头雾水，这是我们该知道缺什么了？

　　程序：我还是先来解释一下吧，在目前的中国什么都不行，又什么都在学的时候，程序和源代码或文档的定义是不同的，但所有的关于软件设计方面的文档将会全称为文档，或许还含有编写程序源代码的小技巧。

2．获取过程

　　开始和范围定义：召集一帮人准备干活，干多少。
　　提供一个可行的合理的设计方案。
　　招标的准备：把自己和客户的需要联系起来，并统计相关资金。
　　合同的准备、谈判及修改：计划的细节和合同条款和清单，包括子合同的条款和清单。制定服务内容和制定关于服务的内容和收取的相关的费用。
　　对供方的监督：向对你提要求的人提你达到该要求的要求，即从软件的需方取得合理的详尽的需求文档。
　　提供软件运行的软环境和硬环境。
　　验收和完成：软件使用的实施状况。根据合同或协议的详尽验收细则进行。
　　如何获取？获取什么？

　　该过程是如此重要的（我在心里说：其实每个过程都很重要的），我自己的体会是许多时候作为软件的开发者，主要的代码的编写者，没有工作的具体方向和整体思路，什么项目来了，无论是什么，只要告诉一个题目，程序员马上跑到计算机面前开始写他认为该写的代码，写着写着发现不太对劲，才开始过来问关于该项目的细节。

　　"工欲善其事，必先利其器"，该器有两种解释，一是：用什么来干？二是：去干什么？比如一个和尚砍柴，器之一理解是刀，器之二理解是去砍柴，如何理解？砍柴的结果是和尚有了一堆的柴，假如和尚没有准备去砍柴的一系列工具，比如车，那么他就不能把柴运回来，当然可以背一点点，软件开发也如此，大家不用知道什么便去编码？好比有一把刀，开始砍柴，砍了很多柴（写许多代码），回头一看没用，运不回去（该代码和该项目不相关）。气恼的程序员开始骂，为什么没有人告诉他没有?quot;车"！

3．供应过程

　　准备投标？：软件编制者，就是我们认为技术可行性的基础上需要什么样的经济可行性方案；以此为基础进行意向合作。
　　签定协议？：双方或多方认为各自符合各自可行性方案（技术方案和经济方案）。
　　编制计划？：制定各类计划，分析计划、设计计划、开发计划、实施计划和维护计划，和对以上计划的控制。
　　实施和控制？：计划的实施，人员、项目和进度的控制。
　　评审和评价？：项目指标。
　　交付和完成？：可以有时间休息了？

　　在供应的过程中应该注意以下方面：
　　提供该项目的合理的框架（Constructer）。
　　根据合同和内部资源来开发软件和提供服务。
　　权衡内部机制进行合理分工，解决技术、控制和实施时的具体情况。
　　质量保证和质量相关的风险。
　　人员培训。

　　该过程是代码产生前的准备，就是我们去砍柴的时候我们想到了"车"，现在我们正在为车进行"技术改造"，让跑的快，装的多，而且在路上不抛锚。为此，我们还必须想到准备一个备用的轮胎，和修补的工具，还必须准备足够多的油（如果是老式的马车，那就多带一匹马）。

　　项目实施过程中，关于风险管理是项目成败的重重之重，最近，相关的防危机的各种风险分析被频频提及，危机管理培训随处可见，或许是"9.11事件"带来的提示。

　　另外，我们还应该注意，你可曾想过，现在我们可能需要该车装几百近的货（就是该时间段内用户的需求很低），但一段时间后，我们需要一辆车装几千斤，我们此时是否需要对该车装几千斤有所考虑。

　　在UML三位鼻祖（I．Jacobson、G．booch 和J．Rumbaugh）的《The unified software development process》一书中提及的狗窝和大厦的例子，说在不久的将来，狗窝是否需要变成大厦？我认为，在狗的需要有两种，一种是需要将狗窝变成大厦，另一种将狗窝丢在一边不去过问。

　　软件开发不也是如此，每个人都希望发展，但你必须有发展的眼光和有良好的准备，不然狗窝永远是狗窝，不可能变成大厦。

4．开发过程

　　建立过程：根据用户提出需求建立合理软件运行环境并根据此环境来开发软件，该软件环境是在用户可以提供或愿意提供的软件运行环境，因为如此可能会增加用户的成本。
　　系统需求分析：该需求包括人员、资金、设备和相关的测试环境。
　　软件需求分析：软件开发的环境。
　　软件结构设计：结构设计师根据系统分析员提供的系统设计文档对软件架构进行设计，同时包括界面设计人员界面设计。
　　软件详细设计：系统建模，文档编写（开发进程、开发月报、系统测试）。
　　软件编码：文档编写，主要是程序源代码。
　　软件集成：将各个模块合并。
　　软件测试：软件测试人员根据测试文档进行测试。

开发过程应该注意以下方面：
　　用户文档、设计文档、开发文档和测试文档。
　　数据定义和数据库的要求和设计。
　　用户操作和执行需求。
　　协调外部需求。
　　结构设计和集成，保证一致性。
　　系统测试包括和修改记录，更新文档。

　　全世界的软件开发者，都一致认为该过程异常重要，我也同样，在软件的开发过程中是技术结合管理的过程，是产品的诞生的过程（从无到有），无论软件被开发出来的好坏，但有一点是被肯定的，该项目被实施过并结束。

　　程序设计者和系统设计者也同样的应该欢呼，我们去砍柴的"车"回来了，我们现在先不管它带多少柴（不是有没有柴，一定得有），它总算把柴带回来了，至于当时合同上签定多少，那是软件开发者在能力上的问题；至于有没有按时回来，那是项目进度安排失误；但如何保证该"车"柴的数量而又在规定时间内返回，我们需要有两种人，一种是砍柴、开车的人，另一种是让谁去砍柴、谁去开车的人。在软件开发上我们把如此的两种人称为：程序分析师（Programmer analyst 和coder）和系统设计师（System analyst）。

5．操作过程

　　系统操作：用户自己干的事。
　　用户支持：用户需要干的事，如果不干？怎么办？
　　跟踪用户实施，实时提供服务：工程部的一揽子事务。
　　实时修改界面：方便操作。

　　操作过程已经是工程投运（项目实施）时或后的事，对不同用户需要采用不同的界面是一定，最简单的就是每个国家的使用的语言不同，那么就必须支持多种语言。
该过程相关于用户较多，暂不累述。

6．维护过程

　　问题修改/修改报告：改造不良情况。
　　实施修改：治病救人。
　　对维护的记录：让其他人知道，避免重犯。
　　系统移植和升级：建立"可持续发展"的过程。
　　在分析基础上选择修改实施方案。

　　为了我们有几百斤的车，没有几千斤的车，而不去重做几千斤的车，却在几百斤的车上改造，让其拥有拉几千斤柴的能力即可，在90%以上的情况下比重做一个几千斤的车节省资金和时间。同样我们也可以组合几个几百斤的车来拉几千斤的东西，如此的方法，就是在建立一个拉几百斤的东西时没有问题，如果连拉几百斤的东西都是问题一把，那么我建议还是重做一个车吧。

　　当然这个比喻不是很切当，软件一旦开发出来，其拷贝的价值几乎等于零，其意思就是我们造好一辆车，以后的车就从车厂出来了。

7．支持过程

　　生产和销售：该项与技术没有大关系，但是保证该过程的持续发展，前几年听见最多的一个词："可持续发展"。

　　又给该过程增加一个过程：支持过程，该过程对于大众软件是尤其必要，这种软件它无须根据用户的个性化的需求制定特定的界面或接口，而是向用户提供一个通用的平台，利用这个平台各个大中小用户根据需要配置自己的软件应用构架。

　　该书谈的是软件开发，首先需要知道的是该软件是为什么而开发的，所以获取过程是非常重要的，当获取过程完成或在完成当中时，需要做一些简单但经过详尽分析的方案来判定问题（该问题就是指软件开发的全过程）可行性，固然需要为软件可行性提供良好的分析设计。最后吗？固然是文档编写（含源代码编写）。

　　注：在软件工程上有些时候把源代码也称为软件的一部分。在软件工程基础一章我们将详述软件开发文档。

　　软件开发的工程化的思想得益于工业化大生产的管理经验，但也有可能会走进一个历史的死胡同，工业化生产的管理是20世纪的经济学（被分出去叫经济管理学了）等的智慧的结晶。但软件产业也略不同于工业过程的管理。

　　工业管理的对象是机器，软件开发的管理对象是人。

　　CMM的思想对软件开发的思想提出人际关系的四个等级，这四个等级就是根据各个公司的人员架构来调整的，不是普适方法。

　　UML是一种语言，在数学的角度，语言是一种符号，既然是符号我们就为符号的合理性、公用性、通用性做好准备，因为如此一个符号将可能需要给被几亿人识别。1998年，C++成为工业标准，在最近的两年，我认为UML也将成为工业标准。

　　从标准上看，其软件的开发过程都已经较为混乱了，我只好为之解释了一番，我为什么选择中国信息产业部的标准来分析：

　　1．UML是软件开发过程文档的工具，我们有一定的流程了，自然就会在去砍柴之前准备车了，国内的标准也告诉我们需要车，但我们去砍什么柴需要什么车就没有那么详细的说明了，更没有如果目前的车不符合要求该如何解决。

　　2．我们是在国内搞软件开发，虽然大家都在喊软件外包，但是我见到每个企业它是什么都做的，我记得我的一个朋友和我说，客户问我们做什么，我告诉它，你买什么我做什么，你买飞机我也做。我不愿意打击人，固然在该书的序中把我们面前的软件开发标准简单说一下，在和UML进行一下对比，可以发现我们在软件上落后了多少，找差补缺，尽快跟上国际的班车。

　　3．计算机的图书和相关的教育软件上在名称的使用也不尽统一，我很气愤的是一些译者使用"翻译软件"对外国的优秀的书籍进行翻译，搞的术语到处都是。我见"用况"一词，想了半天也不解其义，翻开注释，发现是"Use Case"，关于"Case"一词在汉语中被"案例"一词基本诠释。好象在此书之前已经有"用例"的译法，后译之人也不见其，自己却在闭门造"车"。

　　我来说明标准一例，是告诉大家，UML也是一个标准，如此的标准在被介绍到中国来时一定需要谨慎，需要根据国家标准局定义的标准来把国外的标准翻译为中国的信息产业界的标准，不可随心所欲，误人子弟。