按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
埃纯晌叶嘧鞴毕住！焙罄此复蜗嘌揖涂丛诠业姆萆献∪胨摇Ｗ源佣林醒б岳矗业谝淮蜗硎苁忱凑抛欤挥孟匆碌纳莩蕖Ｎㄒ坏穆榉呈俏业孟蚝芏嗯笥呀馐停骸拔也皇潜槐鹑搜鹄戳耍俏斯业睦妫坏靡巡耪饷醋龅摹先生是男的不是女的，并且没有待出嫁的女儿。”
4。3 需求分析为什么困难
有几种原因使需求分析变得困难：（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理解有误。
4。3。1 客户说不清楚需求
有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多政府机构在搞网络建设，这些单位的领导和办公人员大多不清楚计算机网络有什么用，反而要软件系统分析人员替他们设想需求。这类工程的需求是如此的主观，以致产生很多贪污腐败现象。
有些客户心里非常清楚想要什么，但却说不明白。读者可能很不以为然。就举日常生活的事例吧，比如说买鞋子。我们非常了解自已的脚，但没法说清楚脚的大小和形状。只能拿鞋子去试，试穿时感觉到舒服才会买鞋（居然也有神通广大的售货员，看一眼客户的手，就知道应该穿什么样的鞋）。
如果客户本身就懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。如果客户全不懂软件，但信任软件开发方，这事也好办。分析人员可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。最怕的就是“不懂装懂”或者“半懂充内行”的客户，他们会提出不切实际的需求。如果这些客户甚至觉得自己是上帝的爸爸，那么沟通和协商都会很困难。
4。3。2 需求自身经常变动
唐僧曾说：“妖要是有了仁慈之心，就不再是妖，是人妖。”（《大话西游之大圣娶亲》）
连妖都会变心，别说人了。所以喜新厌旧乃人之常情，世界也因此变得多姿多彩。
软件的需求会变化吗？
答：据历史记载，没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。＇Cline 1995＇
让我们先接受“需求会变动”这个事实吧，免得在需求变动时惊慌失措。明白“需求会变动”这个道理后，在进行需求分析时就要留点神：
（1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。
（2）在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。要防止象韩复渠那样，在别人请他喝酒吃饭时他什么都点头（人家就更加献殷勤），吃完了他就宣布刚才答应的事都不算数，便扬长而去。
4。3。3 分析人员或客户理解有误
有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”
软件系统分析人员不可能都是全才。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。我读中学时候最怕写作文逃题，如果逃题了，不管作文写得多长，总是零分。所以分析人员写好需求说明书后，要请客户方的各个代表验证。如果问题很复杂，双方都不太明白，就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。
由于客户大多不懂软件，他们可能觉得软件是万能的，会提出一些无法实现的需求。有时客户还会把软件系统分析人员的建议或答复给想歪了。
有一个软件人员滔滔不绝地向客户讲解在“信息高速公路上做广告”的种种好处，客户听得津津有味。最后，心动的客户对软件人员说：“好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。”
为什么软件系统分析员的工资要比普通程序员高？就是因为需求分析困难嘛。
4。4 如何进行需求分析
上一节诉说了需求分析的困难，本节要知难而进。
进行需求分析不象情人之间的浪漫做法——“让我摸摸你的头发，感觉它是什么颜色。”我们要围绕两个核心问题开展需求分析：（1）应该了解什么？（2）通过什么方式去了解？
4。4。1 应该了解什么
那怕是天下最无能的市长或书记，都知道在作报告时要先从宏观上讲一、二、三、四、五，再从细节上讲A、B、C、D、E。需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题，如图4。1所示。
问题域 对应于软件子系统
问题 对应于子系统的软构件
行为（功能） 对应于软构件的接口
图4。1 进行需求分析时要了解的内容
一个软件系统（记为 S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。
S = ｛ D1，D2，D3，… Dn ｝
问题域Di 由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。
Di = ｛ P1，P2，P3，… Pm ｝
问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的接口。
Pj = ｛ F1，F2，F3，… Fk ｝
按图4。1结构写成的需求说明书，对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时还应该注意两个问题：
（1）最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。
（2）需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。
4。4。2 通过什么方式去了解
了解需求的方式有好几种：
（1）直接与客户交谈。如果分析人员生有足球评论员的那张“大嘴”，就非常容易侃出需求。
（2）有些需求客户讲不清楚，分析人员又猜不透，这时就要请教行家。有些高手真的很厉害，你还没有开始问，他就能讲出前因后果。让你感到“听君一席言，胜读十年书。”
（3）有很多需求可能客户与分析人员想都没有想过，或者想得太幼稚。要经常分析优秀的和蹩脚的同类软件，看到了优点就尽量吸取，看到了缺点就引以为戒。前人既然付了学费，后人就不要拒绝坐享其成。
4。5 小 结
为了阐述可行性分析的四个要素：经济、技术、社会环境和人，本章讲了几个令人垂头丧气的案例。如果您学会了客观、科学的可行性分析，在作决策时就要果断，要学习热恋中的这个年青人——“倒底行还是不行？行就结婚，不行就离婚。”
本章并没有鼓吹需求分析的难度，不是在吓唬人。如果需求分析搞错了，麻烦大哩。几十年前，我们最最伟大的领袖毛主席说了一声“人多力量大”，导致现在中国人口蹦到13亿。他老人家辉煌地走了，后人却付出了沉重的代价。
所以我们要认真地做好可行性分析和需求分析。
第五章 系 统 设 计
系统设计是把需求转化为软件系统的最重要的环节。系统设计的优劣在根本上决定了软件系统的质量。就象“一切帝国主义都是纸老虎”那样可以断定“差的系统设计必定产生差的软件系统。”所以我们要努力保证系统设计“根正苗红”，把一切左倾、右倾的设计思潮消灭在萌芽状态。
Windows NT的一位系统设计师拥有8辆法拉利跑车，让Microsoft公司的一些程序员十分眼红。但你只能羡慕而不能愤恨，因为并不是每个程序员都有本事成为复杂软件系统的设计师。系统设计要比纯粹的编程困难得多。即便你清楚客户的需求，却未必知道应该设计什么样的软件系统——既能挣最多的钱又能让客户满意。“天下西湖三十六，最美是杭州”，千年前苏东坡大学士对西湖精采绝伦的系统设计，使杭州荣升为“天堂”，让后人只剩下赞叹和破坏的份了。
本章讲述系统设计的四方面内容：体系结构设计、模块设计、数据结构与算法设计、用户界面设计。如果将软件系统比喻为人体，那么：
（1）体系结构就如同人的骨架。如果某个家伙的骨架是猴子，那么无论怎样喂养和美容，这家伙始终都是猴子，不会成为人。
（2）模块就如同人的器官，具有特定的功能。人体中最出色的模块设计之一是手，手只有几种动作，却能做无限多的事情。人体中最糟糕的模块设计之一是嘴巴，嘴巴将最有价值但毫无相干的几种功能如吃饭、说话、亲吻混为一体，使之无法并行处理，真乃人类之不幸。
（3）数据结构与算法就如同人的血脉和神经，它让器官具有生命并能发挥功能。数据结构与算法分布在体系结构和模块中，它将协调系统的各个功能。人的耳朵和嘴巴虽然是相对独立的器官，但如果耳朵失聪了，嘴巴就只能发出“啊”“呜”的声音，等于丧失了说话的功能（所以聋子天生就是哑巴），可人们却又能用手势代替说话。人体的数据结构与算法设计真是十分神奇并且十分可笑。
（4）用户界面就如同人的外表，最容易让人一见钟情或一见恶心。象人类追求心灵美和外表美那样，软件系统也追求（内在的）功能强大和（外表的）界面友好。但随着生活节奏的加快，人们已少有兴趣去品味深藏不露的内在美。如果把Unix系统比作是健壮的汉子和妇人，那么Windows系统就象妩媚的小白脸和狐狸精。想不到Windows系统竟然能兴风作浪，占去大半市场。有鉴于此，我们应该鼓励女士多买化妆品（男士付钱）以获得更好的界面。
在进行系统设计时，我们要深情地关注软件的质量因素，如正确性与精确性、性能与效率、易用性、可理解性与简法性、可复用性与可扩充性等等。即使把系统设计做好了，也并不意味着就能产生好的软件系统。在程序设计、测试、维护等环节还要做大量的工作，无论哪个环节出了差错，都会把好事搞砸了。据说上帝把所有的女士都设计成天使，可是天使们在下凡时有些双脚先着地，有些脸先着地。上帝的这一疏忽让很多女孩伤透了心。我们在开发软件时，一定要吸取这个教训。
5。1 体系结构设计
杨叔子院子曾这样指点其弟子：
文学中有科学，音乐中有数学，漫画中有现代数学的拓扑学。漫画家可以“几笔”就把一个人画出来，不管怎么美化或丑化，就是活像。为什么？因为那“几笔”不是别的，而是拓扑学中的特征不变量，这是事物最本质的东西。
体系结构是软件系统中最本质的东西：
（1）体系结构是对复杂事物的一种抽象。良好的体系结构是普遍适用的，它可以高效地处理多种多样的个体需求。一提起“房子”，我们的脑中马上就会出现房子的印象（而不是地洞的印象）。“房子”是人们对住宿或办公环境的一种抽象。不论是办公楼还是民房，同一类建筑物（甚至不同类的建筑物）之间都具有非常相似的体系结构和构造方式。如果13亿中国人民每个人都要用特别的方式构造奇异的房子，那么960万平方公里的土地将会变得千疮百孔，终日不得安宁。
（2）体系结构在一定的时间内保持稳定。只有在稳定的环境下，人们才能干点事情，社会才能发展。科学告诉我们，宇宙间万物无时无刻不在运动、飞行。由于我们的生活环境在地球上保持相对稳定，以致于我们可以无忧无虑地吃饭和睡觉，压根就意识不到自己是活生生的导弹。软件开发最怕的就是需求变化，但“需求会发生变化”是个无法逃避的现实。人们希望在需求发生变化时，最好只对软件做些皮皮毛毛的修改，可千万别改动软件的体系结构。就如人们对住宿的需求也会变动，你可以经常改变房间的装璜和摆设，但不会在每次变动时都要去折墙、拆柱、挖地基。如果当需求发生变化时，程序员不得不去修改软件的体系结构，那么这个软件的系统设计是失败的。
良好的体系结构意味着普适、高效和稳定。本节将论述两种非常通用的软件体系结构：层次结构和客户机/服务器（Client/Server）结构。
5。1。1 层次结构
层次结构表达了这么一种常识：有些事情比较复杂，我们没法一口气干完，就把事情分为好几层，一层一层地去做。高层的工作总是建立在低层的工作之上。层次关系主要有两种：上下级关系和顺序相邻关系。
一、上下级关系的层次结构
我们从小学一直读到博士研究生毕业，要读20多年，可以分为五个层次。而范进的知识结构只有两层：“私塾”和“秀才”，但读了五十多年，如图5。1所示。一般地处于较高层次的学生应该懂得所有低层次的知识，而处于低层次学生无法懂得所有高层次的知识。图5。1的层次结构存在上下级关系，如同在军队中，上级可以命令下级，而下级不能命令上级。如果把图5。1的层次结构当成是一个软件系统的结构，那么上层子系统可以使用下层子系统的功能，而下层子系统不能够使用上层子系统的功能。
二、顺序相邻关系的层次结构
顺序相邻关系的层次结构表明通讯只能在相邻两层之间发生，信息只能被一层一层地顺序传递。这种层次结构的经典之作是计算机网络的OSI参考模型，如图5。2所示。为了减少设计的复杂性，大多数网络都按层（Layer）或级（Level）的方式组织。每一层的目的都是向它的上一层提供一定的服务，而把如何实现这一服务的细节对上一层加以屏蔽。一台机器上的第n层与另一台机器上的第n层进行对话。通话的规则就是第n层的协议。数据不是从一台机器的第n层直接传送到另一台机器的第n层。发送方把数据和控制信息逐层向下传递。最低层是物理介质，它进行实际的通讯。接收方则将数据和控制信息逐层向上传递。
每一对相邻层之间都有接口。接口定义了下层提供的原语操作和服务。当网络设计者在决定一个网络应包含多少层，每一层应当做什么的时候，其中很重要的工作是在相邻层之间定义清晰的接口。接口可以使得同一层能轻易地用某一种实现（Implementation）来替换另一种完全不同的实现（如用卫星信道来代替所有的电话线），只要新的实现能向上层提供同一组服务就可以了。＇Tanenbaum 1998＇
考上“举人”时已五十多岁了
复习报考“举人”用了几十年
图5。1（a）从小学读到博士存在的五个学习阶段 图5。1（b）范进的知识结构
图5。2 计算机网络的OSI参考模型
三、其它的层次结构
目前在大型商业应用软件系统中还流行一种包含中间件（Middleware）的层次结构，如图5。3所示＇Jacobson 1997＇。中间件支持与平台无关的分布式计算，可以用DCOM和CORBA对象来实现。
图5。3 包含中间件的层次结构
5。1。2 客户机/服务器结构
让我们先回顾一下早期的电话系统。贝尔（Alexander Graham Bell）于1876年申请了电话专利。那时期的电话必须一对一对地卖，用户自己在两个电话之间拉一根线。如果一个电话用户想和其它几个电话用户通话，他必须拉n根单独的线到每个人的房子里。于是在很短的时间内，城市里到处都是穿过房屋和树木的混乱的电话线。很明显，企图把所有的电话完全互联（如图5。4（a）所示）是行不通的。
贝尔电话公司在1878年开办了第一个交换局。公司为每个客户架设一条线。打电话时，客户摇动电话的曲柄使电话公司办公室的铃响起来，操作员听到铃声以后根据要求将呼叫方和被呼叫方用跳线手工连接起来。这种集中交换式的模型如图5。4（b）所示。很快地，贝尔系统的交换局就出现在各地。人们又要求能打城市间的长途电话，就出现了二级交换局，以后进一步发展为多个二级交换局。＇Tanenbaum 1998＇
5。4（a）完全互