建筑工程管理软件工程学

《建筑工程管理软件工程学》由会员分享，可在线阅读，更多相关《建筑工程管理软件工程学（17页珍藏版）》请在金锄头文库上搜索。

1、（建筑工程管理）软件工 程学 （建筑工程管理）软件工 程学 第五章系统设计 系统设计是把需求转化为软件系统的最重要的环节。系统设计的优劣于根本上决定了 软件系统的质量。就象“壹切帝国主义均是纸老虎”那样能够断定“差的系统设计必定产 生差的软件系统。 ”所以我们要努力保证系统设计“根正苗红” ，把壹切左倾、右倾的设计 思潮消灭于萌芽状态。 WindowsNT 的壹位系统设计师拥有 8 辆法拉利跑车，让 Microsoft 公司的壹些程序员 十分眼红。但你只能羡慕而不能愤恨，因为且不是每个程序员均有本事成为复杂软件系统 的设计师。系统设计要比纯粹的编程困难得多。即便你清楚客户的需求，却未必知道应该

2、 设计什么样的软件系统既能挣最多的钱又能让客户满意。 “天下西湖三十六，最美是 杭州” ，千年前苏东坡大学士对西湖精采绝伦的系统设计，使杭州荣升为“天堂” ，让后人 只剩下赞叹和破坏的份了。 本章讲述系统设计的四方面内容：体系结构设计、模块设计、数据结构和算法设计、 用户界面设计。如果将软件系统比喻为人体，那么： （1）体系结构就如同人的骨架。如果某个家伙的骨架是猴子，那么无论怎样喂养和美容， 这家伙始终均是猴子，不会成为人。 （2）模块就如同人的器官，具有特定的功能。人体中最出色的模块设计之壹是手，手只 有几种动作，却能做无限多的事情。人体中最糟糕的模块设计之壹是嘴巴，嘴巴将最有价 值但毫无

3、相干的几种功能如吃饭、说话、亲吻混为壹体，使之无法且行处理，真乃人类之 不幸。 （3）数据结构和算法就如同人的血脉和神经，它让器官具有生命且能发挥功能。数据结 构和算法分布于体系结构和模块中，它将协调系统的各个功能。人的耳朵和嘴巴虽然是相 对独立的器官，但如果耳朵失聪了，嘴巴就只能发出“啊” “呜”的声音，等于丧失了说 话的功能（所以聋子天生就是哑巴） ，可人们却又能用手势代替说话。人体的数据结构和 算法设计真是十分神奇且且十分可笑。 （4）用户界面就如同人的外表，最容易让人壹见钟情或壹见恶心。象人类追求心灵美和 外表美那样，软件系统也追求（内于的）功能强大和（外表的）界面友好。但随着生活节

4、奏的加快，人们已少有兴趣去品味深藏不露的内于美。如果把 Unix 系统比作是健壮的汉 子和妇人，那么 Windows 系统就象妩媚的小白脸和狐狸精。想不到 Windows 系统竟然能兴 风作浪，占去大半市场。有鉴于此，我们应该鼓励女士多买化妆品（男士付钱）以获得更 好的界面。 于进行系统设计时，我们要深情地关注软件的质量因素，如正确性和精确性、性能和 效率、易用性、可理解性和简法性、可复用性和可扩充性等等。即使把系统设计做好了， 也且不意味着就能产生好的软件系统。于程序设计、测试、维护等环节仍要做大量的工作， 无论哪个环节出了差错，均会把好事搞砸了。据说上帝把所有的女士均设计成天使，可是 天使

5、们于下凡时有些双脚先着地，有些脸先着地。上帝的这壹疏忽让很多女孩伤透了心。 我们于开发软件时，壹定要吸取这个教训。 5.1 体系结构设计 杨叔子院子曾这样指点其弟子： 文学中有科学，音乐中有数学，漫画中有现代数学的拓扑学。漫画家能够“几笔”就 把壹个人画出来，不管怎么美化或丑化，就是活像。为什么？因为那“几笔”不是别的， 而是拓扑学中的特征不变量，这是事物最本质的东西。 体系结构是软件系统中最本质的东西： （1）体系结构是对复杂事物的壹种抽象。良好的体系结构是普遍适用的，它能够高效地 处理多种多样的个体需求。壹提起“房子” ，我们的脑中马上就会出现房子的印象（而不 是地洞的印象） 。 “房子”

6、是人们对住宿或办公环境的壹种抽象。不论是办公楼仍是民房， 同壹类建筑物（甚至不同类的建筑物）之间均具有非常相似的体系结构和构造方式。如果 13 亿中国人民每个人均要用特别的方式构造奇异的房子，那么 960 万平方 km 的土地将会 变得千疮百孔，终日不得安宁。 （2）体系结构于壹定的时间内保持稳定。只有于稳定的环境下，人们才能干点事情，社 会才能发展。科学告诉我们，宇宙间万物无时无刻不于运动、飞行。由于我们的生活环境 于地球上保持相对稳定，以致于我们能够无忧无虑地吃饭和睡觉，压根就意识不到自己是 活生生的导弹。软件开发最怕的就是需求变化，但“需求会发生变化”是个无法逃避的现 实。人们希望于需求

7、发生变化时，最好只对软件做些皮皮毛毛的修改，可千万别改动软件 的体系结构。就如人们对住宿的需求也会变动，你能够经常改变房间的装璜和摆设，但不 会于每次变动时均要去折墙、拆柱、挖地基。如果当需求发生变化时，程序员不得不去修 改软件的体系结构，那么这个软件的系统设计是失败的。 良好的体系结构意味着普适、高效和稳定。本节将论述俩种非常通用的软件体系结构 ： 层次结构和客户机/服务器（Client/Server）结构。 5.1.1 层次结构5.1.1 层次结构 层次结构表达了这么壹种常识：有些事情比较复杂，我们没法壹口气干完，就把事情 分为好几层，壹层壹层地去做。高层的工作总是建立于低层的工作之上。层

8、次关系主要有 俩种：上下级关系和顺序相邻关系。 壹、上下级关系的层次结构壹、上下级关系的层次结构 我们从小学壹直读到博士研究生毕业，要读 20 多年，能够分为五个层次。而范进的 知识结构只有俩层：“私塾”和“秀才” ，但读了五十多年，如图 5.1 所示。壹般地处于 较高层次的学生应该懂得所有低层次的知识，而处于低层次学生无法懂得所有高层次的知 识。图 5.1 的层次结构存于上下级关系，如同于军队中，上级能够命令下级，而下级不能 命令上级。如果把图 5.1 的层次结构当成是壹个软件系统的结构，那么上层子系统能够使 用下层子系统的功能，而下层子系统不能够使用上层子系统的功能。 二、顺序相邻关系的层

9、次结构二、顺序相邻关系的层次结构 顺序相邻关系的层次结构表明通讯只能于相邻俩层之间发生，信息只能被壹层壹层地 顺序传递。这种层次结构的经典之作是计算机网络的 OSI 参考模型，如图 5.2 所示。为了 减少设计的复杂性，大多数网络均按层（Layer）或级（Level）的方式组织。每壹层的目 的均是向它的上壹层提供壹定的服务，而把如何实现这壹服务的细节对上壹层加以屏蔽。 壹台机器上的第 n 层和另壹台机器上的第 n 层进行对话。通话的规则就是第 n 层的协议。 数据不是从壹台机器的第 n 层直接传送到另壹台机器的第 n 层。发送方把数据和控制信息 逐层向下传递。最低层是物理介质，它进行实际的通讯

10、。接收方则将数据和控制信息逐层 向上传递。 每壹对相邻层之间均有接口。接口定义了下层提供的原语操作和服务。当网络设计者 于决定壹个网络应包含多少层，每壹层应当做什么的时候，其中很重要的工作是于相邻层 之间定义清晰的接口。接口能够使得同壹层能轻易地用某壹种实现（Implementation）来 替换另壹种完全不同的实现（如用卫星信道来代替所有的电话线） ，只要新的实现能向上 层提供同壹组服务就能够了。Tanenbaum1998 考上“举人”时已五十多岁了 复习报考“举人”用了几十年 图 5.1（a）从小学读到博士存于的五个学习阶段图 5.1（b）范进的知识结构 图 5.2 计算机网络的 OSI

11、参考模型 三、其它的层次结构三、其它的层次结构 目前于大型商业应用软件系统中仍流行壹种包含中间件（Middleware）的层次结构， 如图 5.3 所示Jacobson1997。中间件支持和平台无关的分布式计算，能够用 DCOM 和 CORBA 对象来实现。 图 5.3 包含中间件的层次结构 5.1.2 客户机/服务器结构5.1.2 客户机/服务器结构 让我们先回顾壹下早期的电话系统。贝尔（AlexanderGrahamBell）于 1876 年申请了 电话专利。那时期的电话必须壹对壹对地卖，用户自己于俩个电话之间拉壹根线。如果壹 个电话用户想和其它几个电话用户通话，他必须拉 n 根单独的线到

12、每个人的房子里。于是 于很短的时间内，城市里到处均是穿过房屋和树木的混乱的电话线。很明显，企图把所有 的电话完全互联（如图 5.4（a）所示）是行不通的。 贝尔电话公司于 1878 年开办了第壹个交换局。公司为每个客户架设壹条线。打电话 时，客户摇动电话的曲柄使电话公司办公室的铃响起来，操作员听到铃声以后根据要求将 呼叫方和被呼叫方用跳线手工连接起来。这种集中交换式的模型如图 5.4（b）所示。很快 地，贝尔系统的交换局就出当下各地。人们又要求能打城市间的长途电话，就出现了二级 交换局，以后进壹步发展为多个二级交换局。Tanenbaum1998 网络层 应用层 主 机 B Applicatio

13、n Systems 小 学 （5-6 年） 博 士（3-4 年） 网络层 应用层 5.4（a）完全互联的电话系统 5.4（b）集中交换式的电话系统 如果将图 5.4（b）中的电话见成是客户程序，将中心的交换局见成是服务程序，那么 图 5.4（b）就是典型的客户机/服务器结构。注意这里客户机和服务器均是指软件而不是 指硬件（壹台计算机能够放多个客户机和服务器软件） 。 客户机/服务器结构存于俩个显然的优点： （1）以集中的方式高效率地管理通讯。前面讲电话系统的故事就是要说明这壹点。 （2）能够共享资源。比如于信息管理系统中，服务器将信息集中起来，任何客户机均能 够通过访问服务器而获得所需的信息。

14、 客户机和服务器之间的通讯以“请求响应”的方式进行。客户机先向服务器发起 “请求” （Request） ，服务器再响应（Response）这个请求，如图 5.5 所示。 请求 响应 图 5.5Client 和 Server 之间的通讯以“请求响应”的方式进行 采用“请求响应”这种通讯方式的基本动机是为了解决“聚集” （Rendezvous） 问题。为了理解这壹个问题，设想壹个人试图于分离的机器上启动俩个程序且让它们进行 通讯。仍需记住，计算机的运行速度要比人的操作速度高出许多数量级。于他启动第壹个 程序后，该程序开始执行且向对等程序发送消息。于几个微秒内，它便发现对等程序仍不 存于，于是就发出

15、壹条错误消息，然后退出。此后，他启动了第二个程序。不幸的是，当 第二个程序开始执行时，它也找不到第壹个程序（早已退出） 。即使这俩个程序连续地重 新试着通讯， 但由于它们的执行速度那么高， 以致于它们于同壹瞬间联系上的概率非常低。 于客户机/服务器结构中，服务器于启动后必须（无限期地）等待客户机的“请求” ，因此 就形成了“请求响应”的通讯方式。 于 Internet/Intranet 领域，目前“浏览器Web 服务器数据库服务器”结构是壹种非 常流行的客户机/服务器结构，如图 5.6 所示。这种结构最大的优点是：客户机统壹采用 浏览器，这不仅让用户使用方便，而且使得客户机端不存于维护的问题。

16、当然，软件开发 布和维护的工作不是自动消失了，而是转移到了 Web 服务器端。于 Web 服务器端，程序员 要用脚本语言编写响应页面。例如用 Microsoft 的 ASP 语言查询数据库服务器，将结果保 存于 Web 页面中，再由浏览器显示出来。 HTTP 请求 查询 HTTP 响应 图 5.6“浏览器Web 服务器数据库服务器”结构 服务器 ASP Engine 5.2 模块设计 于设计好软件的体系结构后，就已经于宏观上明确了各个模块应具有什么功能，应放 于体系结构的哪个位置。我们习惯地从功能上划分模块，保持“功能独立”是模块化设计 的基本原则。 因为， “功能独立” 的模块能够降低开发、 测试、 维护等阶段的代价。 可是 “功 能独立”且不意味着模块之间保持绝对的孤立。壹个系统要完成某项任务，需要各个模块 相互配合才能实现，此时模块之间就要进行信息交流。 比如手和脚是俩个“功能独立”的模块。没有脚时，手照样能干活。没有手时，脚仍 能够走路。但如果希望跑得快，那么迈左脚时壹定要伸右臂甩左臂，迈右脚时则要伸左臂 甩右臂。于设计壹个模块时不仅要考虑“这个模块就该提供什么样的功