软件工程思想5
综合能力考核表详细内容
软件工程思想5
第五章 系 统 设 计 系统设计是把需求转化为软件系统的最重要的环节。系统设计的优劣在根本上决定了 软件系统的质量。就象“一切帝国主义都是纸老虎”那样可以断定“差的系统设计必定产生 差的软件系统。”所以我们要努力保证系统设计“根正苗红”,把一切左倾、右倾的设计思 潮消灭在萌芽状态。 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)完全互联的电话系统 5.4(b)集中交换式的电话系统 如果将图5.4(b)中的电话看成是客户程序,将中心的交换局看成是服务程序,那么 图5.4(b)就是典型的客户机/服务器结构。注意这里客户机和服务器都是指软件而不是 指硬件(一台计算机可以放多个客户机和服务器软件)。 客户机/服务器结构存在两个显然的优点: (1)以集中的方式高效率地管理通讯。前面讲电话系统的故事就是要说明这一点。 (2)可以共享资源。比如在信息管理系统中,服务器将信息集中起来,任何客户机都可 以通过访问服务器而获得所需的信息。 客户机和服务器之间的通讯以“请求——响应”的方式进行。客户机先向服务器发起“请 求”(Request),服务器再响应(Response)这个请求,如图5.5所示。 请求 响应 图5.5 Client和Server之间的通讯以“请求——响应”的方式进行 采用“请求——响应”这种通讯方式的基本动机是为了解决“聚集”(Rendezvous)问题。 为了理解这一个问题,设想一个人试图在分离的机器上启动两个程序并让它们进行通讯 。还需记住,计算机的运行速度要比人的操作速度高出许多数量级。在他启动第一个程 序后,该程序开始执行并向对等程序发送消息。在几个微秒内,它便发现对等程序还不 存在,于是就发出一条错误消息,然后退出。此后,他启动了第二个程序。不幸的是, 当第二个程序开始执行时,它也找不到第一个程序(早已退出)。即使这两个程序连续 地重新试着通讯,但由于它们的执行速度那么高,以致于它们在同一瞬间联系上的概率 非常低。在客户机/服务器结构中,服务器在启动后必须(无限期地)等待客户机的“请 求”,因此就形成了“请求——响应”的通讯方式。 在Internet/Intranet领域,目前“浏览器—Web 服务器—数据库服务器” 结构是一种非常流行的客户机/服务器结构,如图5.6所示。这种结构最大的优点是:客 户机统一采用浏览器,这不仅让用户使用方便,而且使得客户机端不存在维护的问题。 当然,软件开发布和维护的工作不是自动消失了,而是转移到了Web 服务器端。在Web 服务器端,程序员要用脚本语言编写响应页面。例如用Microsoft的ASP语言查询数据库 服务器,将结果保存在Web 页面中,再由浏览器显示出来。 HTTP 请求 查询 HTTP 响应 图5.6 “浏览器—Web 服务器—数据库服务器”结构 5.2 模 块 设 计 在设计好软件的体系结构后,就已经在宏观上明确了各个模块应具有什么功能,应放 在体系结构的哪个位置。我们习惯地从功能上划分模块,保持“功能独立”是模块化设计 的基本原则。因为,“功能独立”的模块可以降低开发、测试、维护等阶段的代价。但是 “功能独立”并不意味着模块之间保持绝对的孤立。一个系统要完成某项任务,需要各个 模块相互配合才能实现,此时模块之间就要进行信息交流。 比如手和脚是两个“功能独立”的模块。没有脚时,手照样能干活。没有手时,脚仍可 以走路。但如果希望跑得快,那么迈左脚时一定要伸右臂甩左臂,迈右脚时则要伸左臂 甩右臂。在设计一个模块时不仅要考虑“这个模块就该提供什么样的功能”,还要考虑“这 个模块应该怎样与其它模块交流信息”。 本节将论述评价模块设计优劣的三个特征因素:“信息隐藏”、“内聚与耦合”和“封闭— —开放性”。 5.2.1 信息隐藏 在一节不和谐的课堂里,老师叹气道:“要是坐在后排聊天的同学能象中间打牌的同学 那么安静,就不会影响到前排睡觉的同学。” 这个故事告诉我们,如果不想让坏事传播开来,就应该把坏事隐藏起来,“家丑不可外 扬”就是这个道理。为了尽量避免某个模块的行为去干扰同一系统中的其它模块,在设计 模块时就要注意信息隐藏。应该让模块仅仅公开必须要让外界知道的内容,而隐藏其它 一切内容。 模块的信息隐藏可以通过接口设计来实现。一个模块仅提供有限个接口(Interface) ,执行模块的功能或与模块交流信息必须且只须通过调用公有接口来实现。如果模块是 一个C++对象,那么该模块的公有接口就对应于对象的公有函数。如果模块是一个COM对 象,那么该模块的公有接口就是COM对象的接口。一个COM对象可以有多个接口,而每个 接口实质上是一些函数的集合。[Rogerson 1999] 美国也许是世界上丑闻最多的国家,因为它追求民主,不懂得“隐藏信息”。但美国又 是软件产业最发...
软件工程思想5
第五章 系 统 设 计 系统设计是把需求转化为软件系统的最重要的环节。系统设计的优劣在根本上决定了 软件系统的质量。就象“一切帝国主义都是纸老虎”那样可以断定“差的系统设计必定产生 差的软件系统。”所以我们要努力保证系统设计“根正苗红”,把一切左倾、右倾的设计思 潮消灭在萌芽状态。 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)完全互联的电话系统 5.4(b)集中交换式的电话系统 如果将图5.4(b)中的电话看成是客户程序,将中心的交换局看成是服务程序,那么 图5.4(b)就是典型的客户机/服务器结构。注意这里客户机和服务器都是指软件而不是 指硬件(一台计算机可以放多个客户机和服务器软件)。 客户机/服务器结构存在两个显然的优点: (1)以集中的方式高效率地管理通讯。前面讲电话系统的故事就是要说明这一点。 (2)可以共享资源。比如在信息管理系统中,服务器将信息集中起来,任何客户机都可 以通过访问服务器而获得所需的信息。 客户机和服务器之间的通讯以“请求——响应”的方式进行。客户机先向服务器发起“请 求”(Request),服务器再响应(Response)这个请求,如图5.5所示。 请求 响应 图5.5 Client和Server之间的通讯以“请求——响应”的方式进行 采用“请求——响应”这种通讯方式的基本动机是为了解决“聚集”(Rendezvous)问题。 为了理解这一个问题,设想一个人试图在分离的机器上启动两个程序并让它们进行通讯 。还需记住,计算机的运行速度要比人的操作速度高出许多数量级。在他启动第一个程 序后,该程序开始执行并向对等程序发送消息。在几个微秒内,它便发现对等程序还不 存在,于是就发出一条错误消息,然后退出。此后,他启动了第二个程序。不幸的是, 当第二个程序开始执行时,它也找不到第一个程序(早已退出)。即使这两个程序连续 地重新试着通讯,但由于它们的执行速度那么高,以致于它们在同一瞬间联系上的概率 非常低。在客户机/服务器结构中,服务器在启动后必须(无限期地)等待客户机的“请 求”,因此就形成了“请求——响应”的通讯方式。 在Internet/Intranet领域,目前“浏览器—Web 服务器—数据库服务器” 结构是一种非常流行的客户机/服务器结构,如图5.6所示。这种结构最大的优点是:客 户机统一采用浏览器,这不仅让用户使用方便,而且使得客户机端不存在维护的问题。 当然,软件开发布和维护的工作不是自动消失了,而是转移到了Web 服务器端。在Web 服务器端,程序员要用脚本语言编写响应页面。例如用Microsoft的ASP语言查询数据库 服务器,将结果保存在Web 页面中,再由浏览器显示出来。 HTTP 请求 查询 HTTP 响应 图5.6 “浏览器—Web 服务器—数据库服务器”结构 5.2 模 块 设 计 在设计好软件的体系结构后,就已经在宏观上明确了各个模块应具有什么功能,应放 在体系结构的哪个位置。我们习惯地从功能上划分模块,保持“功能独立”是模块化设计 的基本原则。因为,“功能独立”的模块可以降低开发、测试、维护等阶段的代价。但是 “功能独立”并不意味着模块之间保持绝对的孤立。一个系统要完成某项任务,需要各个 模块相互配合才能实现,此时模块之间就要进行信息交流。 比如手和脚是两个“功能独立”的模块。没有脚时,手照样能干活。没有手时,脚仍可 以走路。但如果希望跑得快,那么迈左脚时一定要伸右臂甩左臂,迈右脚时则要伸左臂 甩右臂。在设计一个模块时不仅要考虑“这个模块就该提供什么样的功能”,还要考虑“这 个模块应该怎样与其它模块交流信息”。 本节将论述评价模块设计优劣的三个特征因素:“信息隐藏”、“内聚与耦合”和“封闭— —开放性”。 5.2.1 信息隐藏 在一节不和谐的课堂里,老师叹气道:“要是坐在后排聊天的同学能象中间打牌的同学 那么安静,就不会影响到前排睡觉的同学。” 这个故事告诉我们,如果不想让坏事传播开来,就应该把坏事隐藏起来,“家丑不可外 扬”就是这个道理。为了尽量避免某个模块的行为去干扰同一系统中的其它模块,在设计 模块时就要注意信息隐藏。应该让模块仅仅公开必须要让外界知道的内容,而隐藏其它 一切内容。 模块的信息隐藏可以通过接口设计来实现。一个模块仅提供有限个接口(Interface) ,执行模块的功能或与模块交流信息必须且只须通过调用公有接口来实现。如果模块是 一个C++对象,那么该模块的公有接口就对应于对象的公有函数。如果模块是一个COM对 象,那么该模块的公有接口就是COM对象的接口。一个COM对象可以有多个接口,而每个 接口实质上是一些函数的集合。[Rogerson 1999] 美国也许是世界上丑闻最多的国家,因为它追求民主,不懂得“隐藏信息”。但美国又 是软件产业最发...
软件工程思想5
[下载声明]
1.本站的所有资料均为资料作者提供和网友推荐收集整理而来,仅供学习和研究交流使用。如有侵犯到您版权的,请来电指出,本站将立即改正。电话:010-82593357。
2、访问管理资源网的用户必须明白,本站对提供下载的学习资料等不拥有任何权利,版权归该下载资源的合法拥有者所有。
3、本站保证站内提供的所有可下载资源都是按“原样”提供,本站未做过任何改动;但本网站不保证本站提供的下载资源的准确性、安全性和完整性;同时本网站也不承担用户因使用这些下载资源对自己和他人造成任何形式的损失或伤害。
4、未经本网站的明确许可,任何人不得大量链接本站下载资源;不得复制或仿造本网站。本网站对其自行开发的或和他人共同开发的所有内容、技术手段和服务拥有全部知识产权,任何人不得侵害或破坏,也不得擅自使用。
我要上传资料,请点我!
管理工具分类
ISO认证课程讲义管理表格合同大全法规条例营销资料方案报告说明标准管理战略商业计划书市场分析战略经营策划方案培训讲义企业上市采购物流电子商务质量管理企业名录生产管理金融知识电子书客户管理企业文化报告论文项目管理财务资料固定资产人力资源管理制度工作分析绩效考核资料面试招聘人才测评岗位管理职业规划KPI绩效指标劳资关系薪酬激励人力资源案例人事表格考勤管理人事制度薪资表格薪资制度招聘面试表格岗位分析员工管理薪酬管理绩效管理入职指引薪酬设计绩效管理绩效管理培训绩效管理方案平衡计分卡绩效评估绩效考核表格人力资源规划安全管理制度经营管理制度组织机构管理办公总务管理财务管理制度质量管理制度会计管理制度代理连锁制度销售管理制度仓库管理制度CI管理制度广告策划制度工程管理制度采购管理制度生产管理制度进出口制度考勤管理制度人事管理制度员工福利制度咨询诊断制度信息管理制度员工培训制度办公室制度人力资源管理企业培训绩效考核其它
精品推荐
下载排行
- 1社会保障基础知识(ppt) 16695
- 2安全生产事故案例分析(ppt 16695
- 3行政专员岗位职责 16695
- 4品管部岗位职责与任职要求 16695
- 5员工守则 16695
- 6软件验收报告 16695
- 7问卷调查表(范例) 16695
- 8工资发放明细表 16695
- 9文件签收单 16695
- 10跟我学礼仪 16695