【文档说明】面向对象技术与Java程序课件.ppt，共(105)页，808.352 KB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-44886.html

以下为本文档部分文字说明：

面向对象技术与Java程序课件软件设计概述设计模式介绍体系结构设计数据库设计模块设计用户界面设计第五讲软件系统设计1.1软件设计的任务软件设计是一个把软件需求变换成软件表示的过程。采用“分而治之”的方法进行系统设计，最初要描绘出软件的总体框架

，然后进一步细化，在此框架上填入细节，加工成在程序细节上非常接近于源程序的软件表示。设计的系统能够被开发方顺利地实现，并且恰如其分地满足用户的需求，使开发方和用户的利益极大化。开发人员万万不能为了追求技术的先进性，却偏离需求

开展系统设计工作。1.软件设计概述1.2软件设计的过程软件设计过程就是将软件需求转化为数据结构和软件系统结构的过程。1.软件设计概述2.1何为“模式”所谓模式，就是得到很好研究的范例。模式理论的基本思想其实起源于中国，是中国文化的固有思想。在孙子

兵法中，充斥着各种模式。孙子说，“至于死地而后生”，就是战争模式。三十六计，条条都是模式。这些模式中的每一个都具有典型意义，具有学习价值。通过研究这些模式，学习者可以相互交流，可以在自己的实践中举一反三，推陈出新，加以应用。建筑设计大

师ChristopherAlixander，1977：“模式描述了在我们周围不断重复发生的问题，以及该问题解决方案的核心，这样你就能一次又一次地使用该解决方案而不必重复劳动”。2.设计模式2.1何为“模式”台湾作家蔡学庸先生对“设计模式好还是不好”作了通俗而精辟的解释：模式就是一种公式化的表现，

究竟公式化是不是好事？以艺术来说，公式化的结果会造成僵化，所以负面效果居多。电影号称“第八艺术”，拍电影是一种艺术创作，所以电影里最好不要出现太多的公式，否则肯定被影评人痛批为“毫无新意”。对工程而言，公式化是好事。公式都是千锤百炼的成果，运用这些公式

可以确保工程具备一定的质量，并且能加快工程的进展。软件开发也是一项工程，所以需要尽量地运用公式。尽管软件技术发展非常快，但是仍然有非常多的设计模式可以让我们套用。2.设计模式2.2何为设计模式”设计模式（Desig

npattern）是对应用域问题及其解决方案进行抽象和分析，发现本质，并按照一定的格式记录下来，能被反复使用的设计范例。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。内行的设计者知道，解决任何问题并不一定都要从零开始做起，他们更愿

意复用以前使用过的解决方案。当找到一个好的解决方案时，他们会一遍又一遍地使用。这些模式能解决对应的设计问题，使设计更加灵活和优雅。熟悉这些模式的人们不必重新发明它们，能够立即将它们应用于设计之中。一旦懂得

了设计模式，许多设计方案自然而然就产生了。2.设计模式2.2何为“设计模式”利用成熟的方案提高设计和建造效率，以确保建筑质量，这是从事建筑行业的人千百年来的梦想，许多有识之士很早就开始在建筑实践中探索这一思路的可行性和有效性了。从中世纪欧

洲的建筑师对教堂建筑风格的总结、模仿和复制，到20世纪上半叶中国建筑大师梁思成对中国古建筑“营造法式”的寻访和归纳，古往今来的建筑师们一直都在勉力追求着建筑学中的“永恒之道”。但直到亚历山大耗费14年心血写就《建筑的永恒之道》一书之后，有关模式的理论和方法才真正上升到了科学的层

面，建筑学的“永恒之道”才第一次离建筑师如此之近。2.设计模式2.2何为“设计模式”1995年，ErichGamma，RichardHelm，RalphJohnson，JohnVlissides出版了《Desi

gnPatterns：ElementsofReusableObject－OrientedSoftware》，该书的中译本已于2000年出版。《DesignPatterns》这本书的主要贡献是：确立了设计模式这个术语，创导了一种新的面向对象设计思潮。该书出版

后，全世界参与设计模式研究的人数呈爆炸性地增长。该书的负面效应是：这本书深奥无比，读者被分成两类；即看得懂设计模式的和看不懂设计模式的，后者居多。很多人刚入门时就被吓住了，知难而退。2.设计模式2.3常见的体系结构模式pipesandFilters（管道与过滤器）DataAbstracti

onandobject－OrientedorganizationEvent-Based/ImplicitInvocationLayeredSystems（层次结构系统）Repositories（仓库）In

terpreters（解释器）ProcessControl（过程控制）DistributedSystems（分布式系统）。Client/server（客户机/服务器）Main/subPrograms（主程序/子程序）S

tateTransition（状态转换）DomainSpecificStyles（领域专用模式）2.设计模式2.4常见的界面模式主窗口/子窗口/对话框下拉菜单／弹出菜单工具条／图标按钮基本控件如命令按钮、输入框、选择框、列表框等2.设计模式2.5常见的接口设计模式

构造型模式：AbstractFactory（抽象工厂）、Builder（建造器）、FactoryMethod（工厂方法）、Prototype（原型）、Singleton（单例）。结构性模式：Adapter（适配器）、Bridge（桥梁）、Composite（合成）、Decorator（装饰）、

Facade（外观）、Flyweight（享元）、Proxy（代理）行为型模式：ChainofResponsibility（责任链）、Command（命令）、Interpreter（解释器）、Iterator（迭代器）、Media

tor（协调器）、Memento（备忘录）、Observer（观察者）、State（状态）、Strategy（策略）、TemplateMethod（模板方法）、Visitor（访问者）2.设计模式2.6核心设计法则（1）开放-封闭法则应该试图去设计出永远也不需要改变

的模块，可以添加新代码来扩展系统的行为，不能对已有的代码进行修改。符合该法则的模块需满足两个标准：可扩展，即“对扩展是开放的”－模块的行为可以被扩展，以需要满足新的需求。不可更改，即“对更改是封闭的”－模块的源代码是不允许

进行改动的。一个软件系统的所有模块不可能都满足该法则，但是应努力最小化这些不满足法则的模块数量。开放－封闭法则是OO设计的真正核心。符合该法则便意味着最高等级的复用性和可维护性。2.设计模式2.6核心设计法则（2）适应需要法则设计模式最根本的意图

是适应需求变化，我们应只对变化或可能变化的部分使用设计模式。使用设计模式的关键是预测未来可能发生的需求变化，并在设计过程中选用合适的设计模式。易变性就是软件的一个内在特征。比如，当某个业主想在外墙增加几个窗户时，建筑公司只要对业主说“这个位置一旦开出窗户，房

子的承重结构就会被破坏，随时都有坍塌的危险”，业主就会知难而退了；但当一个行业软件的客户请求软件公司在软件中增加新功能时，如果程序员对客户说“一旦增加这些功能，原来的软件结构就会被破坏”，客户就会立即提高嗓门说：“破坏就破坏呗，大不了你们重新开发一套。我买的是软件，图的就是这玩意儿可以随时修改，要

不然我干脆买硬件得了！2.设计模式2.6核心设计法则（2）适应需要法则“需求分析”中一个重要的法则是“只实现你真正需要的东西”，该法则和这里所说的预测需求变化似乎是完全对立的两个极端。其实，这两个说法并不矛盾。在实践中，我们应首先考虑“只实现你真正需要的东西”这一法则，并在该法则的指导下适

度使用设计模式。由于设计模式最根本的意图是适应需求变化，需要将设计模式的应用范围限制在系统中那些明显不稳定、极可能发生变化的部分，而不应只为了体验创造的乐趣，把设计模式用在那些永远也不会发生变化的组件中。使用设计模式并不是没有代价的，毫无根据地预测需求变化、滥用设计模式的结果只能是“过

度设计”以及由此得到的过于复杂而难于维护的系统实现。因此，设计者在使用一个设计模式之前，最好问自己一句：“为什么使用这个设计模式？是为了适应哪一种需求变化？”2.设计模式2.6核心设计法则（3）针对接口编程法则尽量针对接口编程，而不要针对实

现编程。针对接口编程的组件不需要知道对象的具体类型和实现，只需要知道抽象类定义了哪些接口，这减少了实现上的依赖关系。Client不必知道其使用对象的具体所属类；一个对象可以很容易地被实现了相同接口的另一个对

象所替换；对象间的连接不必硬绑定到一个具体类的对象上，因此增加了灵活性；松散藕合；增加了重用的可能性；提高了（对象）组合的机率，因为被包含对象可以是任何实现了一个指定接口的类；2.设计模式2.6核心设计法则（4）组

合优先法则在不违反继承和组合的基本结构前提下，应该优先使用组合而不是继承。继承破坏了封装性，因为这会将父类的实现细节暴露给子类；“白盒”复用，因为父类的内部细节对于子类而言通常是可见的；当父类的实现更改时，子类也不得不会随之更改；从父类继承来的实现将不能在运

行期间进行改变；仅当下列的所有标准被满足时方可使用继承：子类表达了“是一个…的特殊类型”，而非“是一个由…所扮演的角色”；子类的一个实例永远不需要转化为其它类的一个对象；子类是对其父类的职责进行扩展，而非重写或废除；子类没有对那些仅作为一个工

具类的功能进行扩展；2.设计模式2.7设计法则应用实例例子是一个建造现代化养猪场的故事：一个机器人研发小组研制了一种能自动喂猪的机器人，于是就有人投资兴建了一座由机器人管理的养猪场。为了提高效率和节省成本，投资者要

求技术人员将该养猪场建造成一个“面向对象”的养猪场。养猪场要饲养的猪的品种可能有三种：大白猪长白猪波中猪。2.设计模式2.7设计法则应用实例最初设计的养猪场并没有预测变化和适应变化，只考虑了饲养大白猪的情况。

一个喂猪机器人管理了若干头大白猪。由于猪天性懒惰，机器人必须把饲料放到猪的嘴边，然后吆喝一句，猪才会进食。所以，喂猪机器人的工作就是把饲料准备好，拿到每一头猪的面前，大叫一声：“大白猪，吃！”2.设计模式2.7设计法则应用实例这座养猪场建好后，运行状况相当不错，每一头大白猪都膘

肥体壮，如果不是该企业要不断地追求剩余价值，我们的故事也许就到此结束了。随着养猪场的蓬勃发展，养猪场老板决定要进军国际市场。可是，不同地方的人喜欢吃不同品种的猪。为了适应这一需求变化，养猪场新引进了几头长白猪，希望进一步扩大养猪场的规模。问题出现了：喂猪机器人照例是把饲料准备好，拿到

每一头猪的面前，大叫一声：“大白猪，吃！”大白猪像往常一样愉快地进食。但轮到长白猪的时候，长白猪无动于衷。这可急坏了养猪场的老板。为了解决问题，喂猪机器人的研发团队紧急出动，当晚便改好了喂长白猪的代码，2

.设计模式2.7设计法则应用实例经过了此次代码修改，喂猪机器人在对待每一头猪时，都会先辨认出这头猪的类型，如果这是一头大白猪，它就会大叫一声：“大白猪，吃！”如果这是一头长白猪，它就会大叫一声：“长白猪，吃！”。经过这一改动，养猪场又恢复了平静。2.设计模式2.7设

计法则应用实例可刚过了几天，类似的问题又再次出现，养猪场引进了几头波中猪！这下，机器人又不知该如何喂养了。和上一次变化时相仿，研发团队又准备大动干戈、修改代码了。老板对研发团队的做法非常不理解：“你们太

不像话了，我是付了钱的，可每次我要扩大再生产的时候，你们都要耽误好几天的时间，重新修改代码，如果下次我又要养鸡、养青蛙了呢？”2.设计模式2.7设计法则应用实例在这个现代化养猪场出现的问题其实就是需求变化的问题。设计模式可以使系统很容易地在某一特定层面适应需求变化。例如

，在面向对象的养猪场系统中，当我们没有确定养猪场是否需要适应不同种类的猪时，完全可以只实现对大白猪的管理操作。但设计人员也必须对需求的变化保持足够的敏感，当养猪场需要引进长白猪时，我们就应立即认识到猪的种

类是一个易变的因素。这时，必须引入一些设计手段以适应类似的需求变化。2.设计模式2.7设计法则应用实例首先，我们应该添加一个猪的抽象接口，该接口中定义了所有猪共有的行为，而大白猪和长白猪则具体实现这些行为。然后，我们修改喂

猪机器人的代码，使其不考虑猪的类型，只应用抽象的猪的接口来操作所有猪的对象实例。2.设计模式2.7设计法则应用实例这个改进的养猪场会为我们带来什么好处呢？假设现在养猪场的老板需要引进波中猪，他只要买来几头波中猪的仔猪，扔进养猪场就可以了。喂猪机器人的代码

不需要发生任何变化，它面对每一头猪只要说：“猪，吃！”所有类型的猪都可以愉快地进食。不管养猪场饲养的猪有多少种，喂猪机器人都会把猪喂得膘肥体壮。2.设计模式2.7设计法则应用实例可以看到，喂猪机器人完全是针对接口进行编程的，当系统添

加一个新的类型时，只需要添加新类型的代码，而系统中原有的代码不需要做任何的改变就可以适应新的需求——这完全符合开闭法则。养猪场的老板还曾经提到过养鸡和养青蛙。对此，我们必须明确该需求是否是合理的需求，系统

是否需要适应这一需求变化。一般说来，养猪场是不会养鸡、养青蛙的，我们没必要为此多费心思。但如果老板故意刁难的，我们也不是没有解决方案：适应这一需求变化的方法是提取出一个更一般的“动物接口”，机器人完全使用“动物接口

”类来操作所有的对象。2.设计模式2.7设计法则应用实例现在，面向对象的现代化养猪场又欣欣向荣地发展起来了。但我们不能放松警惕，变化的需求随时都会出现。例如这一次，养猪场的老板突然觉得，老从外面引进仔猪太亏。他希望能在养猪场内部建造一个繁殖基地，自产自销。于是，我们建造了一个猪

工厂。2.设计模式2.7设计法则应用实例不难发现，在实现猪工厂时，我们又陷入了针对实现编程的陷阱。管理员使用猪工厂来选择繁殖哪种类型的仔猪，猪工厂根据管理员的要求执行不同的繁殖过程，繁殖不同类型的仔猪。对于系

统中己有的大白猪和长白猪，这没有问题，但是当我们想繁殖波中猪时，问题又产生了，猪工厂的代码必须修改。显然，我们必须想办法来隔离有关对象创建的代码，以适应需求变化。设计模式中的创建型模式恰恰可以满足我们的需要。2.设计模式2.7设计法则

应用实例为了隔离具体的繁殖过程，我们可以定义一个猪工厂的抽象接口类，其派生类大白猪工厂和长白猪工厂具体地实现接口中的繁殖行为。这样，和具体实现相关的代码被推迟到了具体的派生类工厂中去实现，我们在系统外只要用不同的派生类工厂调用繁殖方法，就可

以繁殖出不同的仔猪了。2.设计模式2.7设计法则应用实例这一改进为我们带来的好处是，当我们要添加一种猪的类型时，也相应地添加繁殖这仔猪的工厂，修改管理员繁殖仔猪的代码等，系统内原有的代码不需要改变。这时，猪工厂负责繁殖仔猪，然后把仔猪交

给喂猪机器人，这些仔猪的生、老、病、死就完全由喂猪机器人来负责了。2.设计模式2.7设计法则应用实例以前，老板雇用清洁工人来打扫猪舍。但有一天，老板忽然对自己说：“不对啊，既然我有机器人，为什么还要雇人来做这件事情？应

该让机器人来打扫猪舍！”。于是，这个需求被提出来。这是一个潜藏了更多变化的需求，未来机器人的功能还可能会不断增加，于是，我们提取出了一个抽象的机器人接口，并实现了两个具体的机器人类——喂猪机器人和清洁机器人。2.设计模式2.7设计法则应用实例这样一来，老板希望机器人

工作时，可以调用机器人接口的“工作”方法。当老板需要新的机器人时，只要添加具体的机器人类即可，其他代码无需变化。但这里还存在另外一个问题：上图中的继承结构是在编译期间就确定了的，在运行不能发生任何变化。因此，如果养猪场需要一个喂猪和清洁机器人，那么必须在养猪场中放进这两个具体的机器人

。如果未来养猪场还需要兽医机器、屠宰机器人等等，养猪场中不就挤满了机器人吗？2.设计模式2.7设计法则应用实例把机器人接口改成功能接口，而清洁和喂猪功能实现了这个功能接口。机器人类中聚合了一个功能接口的引用，这样，我们只需要在养猪场中放进一个机器人，该机器人中聚合了一个喂猪功

能，这时它是一个喂猪机器人。当我们需要打扫养猪场时，老板只需要调用机器人中的“变形”方法，并传递一个“清洁功能”对象给机器人，机器人就变成了一个清洁机器人了。2.设计模式2.7设计法则应用实例此后，当我们添加一个新的机器人种类（如兽医机器人）时，只需要

添加一个兽医功能的派生类，老板就可以根据自己的需要，在任何时刻命令机器人在三个种类之间随意变形。可以看出，添加一个机器人类型时，需要改动的代码都在系统外部。系统内已有的代码不需要发生变化。这里的组合机制使我们很

好地满足了开闭法则。2.设计模式3.1什么是体系结构体系结构（Architecture）一词在英文里就是“建筑”的意思。把软件比作一座楼房，从整体上讲，是因为它有基础、主体和装饰，即操作系统之上的基础设施软件

、实现计算逻辑的主体应用程序、方便使用的用户界面程序。从细节上来看每一个程序也是有结构的。结构化程序设计时代是以砖、瓦、灰、沙、石、预制梁、柱、屋面板盖平房和小楼，而面向对象时代以整面墙、整间房、一层楼梯的预制件盖高楼大

厦。构件怎样搭配才合理？体系结构怎样构造容易？重要构件有了更改后，如何保证整栋高楼不倒？每种应用领域需要什么构件（医院、工厂、旅馆）？有哪些实用、美观、强度、造价合理的构件骨架使建造出来的建筑更能满足用户的需求？3.体系结构设计3.1什么是体

系结构如同土木工程进入到现代建筑学一样，软件也从传统的软件工程进入到现代面向对象的软件工程，研究整个软件系统的体系结构，寻求建构最快、成本最低、质量最好的构造过程。体系结构如同人的骨架。如果某个家伙的骨架是猴子，那么无论怎样喂养和美容，这家伙始终都是猴

子，不会成为人。人的身材大小取决于骨架大小，天生小个子的人基本上不可能成为威猛的大汉，后天再努力（例如锻炼和吃喝）也白搭。由此可见，体系结构乃是系统设计的重中之重。3.体系结构设计3.1什么是体系结构软件体系结构是具有一定形

式的结构化元素（即构件）的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组组合连接起来。软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。包括总体

组织和全局控制、通讯协议、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案间进行选择等。体系结构是软件系统的基本和主体的形态，也就是软件系统中“最本质”的东西。3.体系结构设计3.2体系结构设计原则（1）合适性体系结构是否适合于软件需求。需求与体系结构

之间并没有明显的对应关系，设计师根据需求的特征，通过推理和归纳的方法设计出合适的体系结构。对于软件系统而言，能够满足需求的设计方案可能有很多种，选择能够为开发方和客户方带来最大利益的设计方案。大部分软件开发人员天生有使用新技术的倾向，而这种倾向对开发商业产品而言可能是不利的！经验不丰富的设

计师往往把注意力集中在“功能性需求”而疏忽了“非功能性需求”，殊不知后者恰恰是最能体现设计水平的地方。3.体系结构设计3.2体系结构设计原则(1)合适性比方说住宅的最基本的功能性需求是“吃喝拉撒睡”，全世界

人民都差不多。非功能性需求主要是让人住得舒服。住宅的种类非常多，如茅草屋、窑洞、别墅等。窑洞的体系结构与别墅的有天壤之别，但两者没有可比性。如果一名建筑师给中国陕北农民设计住宅，他应当设计更好的窑洞而非别墅。因为广大的陕北农民住不起别墅，而那里的条件特别适合于建窑

洞。窑洞对于当地的农民而言是非常实用而且成本低廉。窑洞最大的危险是在下大雨和下大雪的时候容易坍塌，如果建筑师能够设计出“安全、舒适、便宜”的窑洞，那么他真是功德无量。3.体系结构设计3.2体系结构设计原则(2)结构稳定性体系结构是系统设计的第一要素，详细设计阶段的工作都是在体系结构确

定之后开展的，而编程和测试则是更后面的工作。如果体系结构经常变动，那么建筑在体系结构之上的用户界面、数据库、模块、数据结构等也跟着经常变动，用“树倒猢狲散”来比喻很恰当，这将导致项目发生混乱。所以体系结构一旦设计完成，应当在一定的时

间内保持稳定不变，只有这样才能使后续工作顺利开展。体系结构是依据需求而设计的。如果需求变更了，很可能导致体系结构也发生变更，高水平的设计师应当能够分析需求文档，判断出哪些需求是稳定不变的，哪些需求是可能变动的。于是根

据那些稳定不变的需求设计体系结构，而根据那些可变的需求设计软件的“可扩展性”。3.体系结构设计3.2体系结构设计原则(3)可扩展性可扩展性是指软件扩展新功能的容易程度。可扩展性越好，表示软件适应“变化”的能力越强。由于软件是“软”的，是否它天生就容易扩展新功能？这要视软件

的规模和复杂性而定。如果软件规模很小，问题很简单，那么扩展功能的确比较容易。要是软件的代码只有100行，这时就无所谓“可扩展性”了，你想怎么扩展都可以。如果软件规模很大，问题很复杂，倘若软件的可扩展性不好，那么该软件就像用卡片造成的房子，抽出或者塞进去一张

卡片都有可能使房子倒塌。是否任何软件在设计的时候都要考虑可扩展性？不见得。如果确信某个软件在它淘汰之前永远都不会变更（如一次性产品），那么在设计阶段就没有必要考虑可扩展性，这样省事省力。3.体系结构设计3.2体系结构设计原则（3）可扩展性可扩展性越来越重要

，这是由现代软件的商业模式决定的：社会的商业越发达，需求变化就越快。需求变化必将导致修改（或者扩展）软件的功能，现代软件的规模和复杂性要比十年前的大得多，如果软件的可扩展性比较差的话，那么修改（或者扩展）功能的代价会很高。现代软件产品通常采用

“增量开发模式”，开发商不断地推出软件产品的新版本，从而不断地获取增值利润。如果软件的可扩展性比较差的话，每次开发新版本的代价就会很高。虽然开发商抓住了商机，但却由于设计水平差而导致没有赚取多少利润，真是要活活气死。3.体系结构设计3.2体系结构设计原则（3）可扩展性体系结构的稳定性是

根据那些稳定不变的需求而设计的，体系结构的可扩展性则是依据那些可变的需求而设计的。两者之间存在辨证的关系：如果系统不可扩展的话，那么就没有发展前途，而软件系统“可扩展”的前提条件是“保持结构稳定”，稳定性是使系统能够持续发展的基础，否则软件难以按计划开发出来。所以稳定性和可

扩展性都是体系结构设计的要素。人们对于物质有喜新厌旧的天性，你可以经常改变住房的装璜和摆设，但不会在每次变动时都去折墙、拆柱、挖地基（否则就是搞破坏了）。在软件开发过程中，变化是司空见惯的事情。如果每次变化都导致体系结构发生大的变动，那简直就是“伤筋

动骨”，这样的体系结构无疑是败笔之作。3.体系结构设计3.2体系结构设计原则（4）可复用性复用就是指“重复利用已经存在的东西”。被复用的对象可以是有形的物体，也可以是无形的知识财富。复用不是人类懒惰的表现而是智慧的表现。因为人类总是在继承了前人的成果，不断加

以利用、改进或创新后才会进步。复用有利于提高产品的质量、提高生产效率和降低成本。由经验可知，通常在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般地，可以相信成熟的东西总是比较可靠的

（即具有高质量），而大量成熟的工作可以通过复用来快速实现（即具有高生产效率）。勤劳并且聪明的人们应该把大部分的时间用在小比例的创新工作上，而把小部分的时间用在大比例的成熟工作中，这样才能把工作做得又快又好。3.体系结构设计3.2体系结构设计原则（4）

可复用性把复用的思想应用于软件开发，称为软件复用。技术开发活动与管理活动中的任何成果都可以被复用，如思想方法、经验、程序、文档，等等。据统计，世界上已经有一千多亿行程序，无数功能被重写了成千上万次，真是浪费哪！面向对象学者们的口头禅就是“请不要再发明相同的车轮子了”。复

用的意义很容易理解，人们也乐意复用以前的成果，但是前提条件是该成果具有比较好的可复用性。可复用性是指成果被复用的容易程度。可复用性是设计出来的，而不是偶然碰到的。要使体系结构具有良好的可复用性，设计师应当分析应用域的共性

问题，然后设计出一种通用的体系结构模式，这样的体系结构才可以被复用。3.体系结构设计3.3体系结构设计的规程3.体系结构设计3.体系结构设计3.4体系结构设计的步骤3.4体系结构设计的步骤（1）设计准备项

目经理分配系统设计任务，包括体系结构设计、模块设计、用户界面设计、数据库设计等。如果系统设计的工作量比较大，人员比较多的话，可能产生一份阶段性的开发计划，如《系统设计计划》。体系结构设计人员阅读需求文档，明确设计任务，并准备相关的设计和资料。3.体系结构设计3.4体系

结构设计的步骤（1）确定影响系统设计的约束因素设计人员从需求文档中提取需求约束，例如：本系统应当遵循的标准或规范软件、硬件环境（包括运行环境和开发环境）的约束接口/协议的约束用户界面的约束软件质量的约束，如正确性、健壮性、可靠性、性能、易用性、清晰性、安全性、可扩展性、兼容

性、可移植性，等等有一些假设或依赖并没有在需求文档中明确指出，但可能会对系统设计产生影响，设计人员应当尽可能地在此处说明。例如对用户教育程度、计算机技能的一些假设或依赖，对支撑本系统的软件硬件的假设或依赖等。3.体系结构设计3.4

体系结构设计的步骤（3）确定设计策略设计人员根据产品的需求，以及本产品的发展战略，确定设计策略。例如：设计模式。根据本产品的功能性需求和非功能性需求，确定体系结构设计模式。扩展策略。说明为了方便本系统在将来扩展功能，现在有什么措施。复用策略。说明本系统在当前“复用什么”，以及将来“如何

被复用”。折衷策略。说明当两个目标难以同时被优化时如何折衷，例如“时一空”效率折衷，复杂性与实用性之间的折衷。3.体系结构设计3.4体系结构设计的步骤（4）系统分解与设计按照体系结构设计模式，将系统分解为若干子系统，确定每个子系统的功能及子系统之间的关系，绘

制系统的总体结构图（包括物理图和逻辑图）；将子系统分解为若干模块，确定每个模块的功能及模块之间的关系，绘制子系统的结构图；确定系统开发、测试、运行所需的软硬件环境。3.体系结构设计3.4体系结构设计的步骤（5）撰写体系结构设计文档设计人员根据指定的

模板撰写《体系结构设计报告》。（6）设计评审设计人员邀请同行专家、开发人员对体系结构进行技术评审。体系结构评审的重点不是“对还是错”，而是要考察系统的综合能力。设计评审的要素视产品的特征而定，例如除了合适性、结构稳定性、可扩展性、可复用性之外，还要考虑性能、容量、安全性，等等。《体系结构设计报告

》的参考模板见附录E。3.体系结构设计3.5层次结构层次结构是最常见的体系结构模式，它体现了“分而治之”的思想：当我们没法一口气解决复杂的原始问题时，就把该问题切割成许多个小的相对简单的问题，然后逐个解决。水平方向切割产生的层称为Layer，而竖直方向切割产生的层称为Tier，3.体系结构

设计3.5层次结构古代中国文人的学历大体分为两层：秀才和举人，这种划分太粗了（即Layer数目太少），对发展教育是很不利的。很多老百姓读不起几年书，拿不到秀才毕业证书的人就被归类为文盲，不幸成为社会下层人物。虽然社会上的秀才人数也不少，但是从秀才到

举人的跨度太大、门槛太高，很多秀才考举人考了一辈子也考不上。后人吸取了经验教训，于是逐步建立了现代的学历层次结构，将学历划分为5个层次：小学、中学、学士、硕士、博士，这样人们读书的选择面广了，工作面也广了。3.体系结构设计3.5层次结构3.体系结构设计

3.5层次结构在计算机领域，采用层次模型的体系结构设计的经典之作是计算机网络OSI参考模型。OSI模型分为7层，每一层的目的都是向它的上一层提供一定的服务，而把如何实现这一服务的细节对上一层加以屏蔽。3.体系结构设计3.6MVC结构MVC（model-view-controlle

r）结构是为同样的数据提供多个视图的应用程序而设计的，对于界面可变的需求，把系统组成分解成模型、视图、控制器三种部件，很好地实现了数据层、控制层、表示层的分离。使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其他依赖于这些数据的

视图都应反映这些变化。是一种模型变化传播机制。3.体系结构设计3.6MVC结构模型类包含应用问题的核心数据、逻辑关系和计算功能，封装所需的数据，提供完成问题处理的操作过程。控制器调用这些操作。模型还

为视图获取显示数据提供访问操作。注册视图与控制器的关系。3.体系结构设计模型类数据结构关系视图和控制器的注册关系内部数据逻辑计算内部数据的获取向视图和控制器通知数据变化3.6MVC结构视图类通过显示的形式，把信息

转达给用户。每个视图有一个更新操作，被变化-传播机制激活，获取来自模型的数据值来更新显示。初始化时，根据注册关系建立与模型的关联。控制器可以获得主动激发界面更新的能力。3.体系结构设计视图类显示形式显示模式控制从模型中获得数据视图更新操作3.6MVC结构控制类通过

时间触发的形式，接受用户的输入。控制器通过事件处理过程对输入事件进行处理，并为每个输入事件提供相应的操作服务，把事件转化为对模型或相关视图的激发操作。3.体系结构设计控制类状态事件控制控制视图更新4.1用户界面概述现今的软件系统大多采用

图形方式的人机界面，它以形象、直观、易学、易用拉近了人和计算机的距离。用户界面如同人的外表，最容易让人一见钟情或一见恶心。像人类追求心灵美和外表美那样，软件系统也追求（内在的）功能强大和（外表的）界面友好。现代社会的生活节奏

越来越快，人们已少有兴趣去品味深藏不露的内在美。如果把UNIX系统比做是健壮的汉子和妇人，那么Windows系统就像妩媚的小白脸和狐狸精。想不到Windows系统竟然能兴风作浪，占去操作系统的大半市场。有鉴于此，我们在设计软件时不要沉迷于

技术，而要多多思考什么样的界面才能让用户更加喜欢。4.界面设计4.用户界面设计4.2什么是好的用户界面是否容易使用：易用性是指用户使用软件的容易程度。现代人的生活节奏快，干啥事都想图个方便，谁都不乐意掏钱买很难用的东西，所以把易用性作为用户界面的重要属性对待无可厚非。是否美观：美观

的界面能消除用户由感觉引起的乏味、紧张和疲劳（情绪低落），大大提高用户的工作效率，从而进一步为发挥用户技能和为用户完成任务做出贡献。人们对美的向往和追求是与生俱有的。显然没有开发人员愿意丑化自己的软件，也没有用户嗜好丑陋的界面。软件开发者要设计美，用户要

享受美，所以界面的美是开发者与用户的共同需求。4.2什么是好的用户界面开发人员在设计用户界面方面不仅存在先天的教育缺陷，更加糟糕的是还常常犯“错位”的毛病，即他以为只要自己感觉用户界面漂亮、使用起来方便，那么用户也一定会满意。当开发人员向用户展示软件时，常会得意

地讲：“这个软件非常好用，我操作给你看，……是很好用吧！蛮漂亮的吧！”软件是否易用、是否美观要让用户来评价。如果用户对界面很不满意，开发人员不要有逆反心里：到哪里找来的笨蛋？其实不是用户笨，是自己开发的软件太笨了。当用户

真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“界面友好”来表扬这个软件。4.用户界面设计4.3用户界面设计原则（1）适合于软件的功能用户界面的合适性是指界面与软件功能相融洽的程度。软件的功能需要通过用户界面来展现。毫无疑问，用户界

面一定要适合于软件的功能，这是最基本的要求。否则用户无法通过这个界面来使用软件，如果连用都不能用，“易用性”根本就无从谈起。例如，对于一个三维建模软件而言，如果用户不能使用鼠标对模型进行旋转、移动、缩放等操作，那么这个软件的

用户界面就不适合于软件的功能。如果不改进用户界面的话，即使软件的内核功能很强（如算法很先进），这个软件也很难卖得出去。4.用户界面设计4.3用户界面设计原则（1）适合于软件的功能合适性差的界面无疑会混淆软件意图，致使用户产生误解。即使它不损害软件功能与性能，也会使用户产生不该有的情绪波动。例如

一些软件开发者喜欢为其作品加一段动画演示，以便吸引更多用户的关注。这本是无可非议的，问题在于这演示是否合情合理。如果运行一个程序，它首先表演一套复杂的动画，在后台演奏雄壮的进行曲，电闪雷鸣之后出来的却是一个普

通的文本编辑器，整个过程让用户置身于云里雾里，而结果却让用户感到惊愕而不是惊喜。合适性差的界面只会给软件带来厄运。“用户界面适合于软件的功能”是基本的设计原则，它提醒设计者不要片面追求界面外观漂亮而导致华而不实。界面的合适性既提倡秀外慧中，又强调恰如其分。

4.用户界面设计4.3用户界面设计原则（2）容易理解如果用户很难理解界面的意图，那么他使用起来肯定很费劲。所以“容易理解”是“容易使用”的前提条件。提高用户界面可理解性的一些规则如下：界面中的所有元素（如菜单、工具条等）没有

错误，也不会让人误解。所有的界面元素应当提供充分而必要的提示，例如当鼠标移动到工具条上的某个图标按钮时，应当在该图标旁边出现功能提示。界面结构能够清晰地反映工作流程，以便用户按部就班地操作。对于复杂的用户界

面而言，最好提供界面“向导”，及时让用户知道自己在界面结构中所处的位置。否则用户很容易在众多的页面中迷失方向。4.用户界面设计4.3用户界面设计原则（3）风格一致风格一致有两方面的含义：•一个软件的用户界面中，同类的

界面元素应当有相同的视感和相同的操作方式。例如命令按钮是最常见的界面元素，所有命令按钮的形状、色彩及对鼠标的响应方式都是一致的。•同一类型软件的用户界面应当有一定程度的相似性。例如Microsoft公司的Office家族里所有软件。对于用户界面而言，风格一致的最大好处就是

能够减少用户的记忆量、减少出错几率，并且迅速积累操作经验。4.用户界面设计4.3用户界面设计原则（4）及时反馈信息用户进行某项操作后，如果过了一会儿（几秒钟）用户界面一点反应都没有，这将使用户感到迷茫和不安，因为他不知道是自己操作错了

还是软件死机了。所以及时反馈信息很重要，至少要让用户心里有数，知道该任务处理得怎么样了，有什么样的结果。例如下载一个文件，界面上应当显示“百分比”或相关数字来表示下载的进度，否则人们不知道要等待多少时间。如果某些事务处

理不能提供进度等数据，那么至少要给出提示信息如“正在处理，请等待……”，最好是提供合适的动画，让用户明白软件正在干活，没有死机。4.用户界面设计4.3用户界面设计原则（5）出错处理用户在使用软件的过程中，不可避免地会出现一些错误的操作。在设计用户界面时必须考虑出错处

理，目的是让用户不必为避免犯错误而提心吊胆、小心翼翼地操作。常见的错误处理方式有：•提供对输入数据进行校验的功能。当用户输入错误的数据时，及时提醒用户改正数据。•对于在某些情况下不应该使用的菜单项和命令按钮

，将其“失效”（屏蔽）可以有效防止该项功能被错误地使用。•提供undo功能，用于撤消不期望的操作。•执行破坏性的操作之前，应当获得用户的确认。例如用户删除一个文件时，应当弹出对话框：“真的要删除该文件吗？”当用户确认后才真正删除文件。4.

用户界面设计4.3用户界面设计原则（6）适应各种用户一个软件产品可能有许多类型的用户，例如有些用户对计算机比较外行，有一些用户可能是计算机的行家。在设计用户界面时应当尽可能多地了解用户的需求和技能水平，努力使用户在操作软件的时候感觉不到差异和麻烦。为了达到这个目标，一般需要提供多种操作

途径以适应各种水平的用户。例如使用Windows下的文件管理器，对于一个初学者来说，他愿意使用鼠标和菜单一步一步地操作；而对于技术专家而言，他也许更愿意使用热键来获取更高的效率。更了不起的是，一些优秀的软件为患有疾病的人们提供了很好的用户界面。例如全世

界的计算机用户中可能有成千上万的人患有色盲或色弱，他们都是正常人，但是当他们面对花花绿绿的软件时会一片茫然。因此通用的软件如浏览器、字处理软件等都要经过色盲人群的测试。设计者越为用户着想，用户就越喜欢这样的软件。4.用户界面设计4.3用户界面设

计原则(7)国际化中国己经进入了WTO，软件的国际化是大势所趋。为了能够更好地适应国内和国际市场，在设计用户界面的时候应当充分考虑语言和文化的差异，尽可能使用标准的图解方式和国际通行的语言，要求简单易懂，易于翻译，方便于

不同母语的用户。特别要留意下列易变的元素：•字体、提示信息、在线帮助；•货币、度量单位；•数字、日期格式；•人的名宇、电话号码、通信地址；•图标、标签；•声音；•阅读顺序或习惯；4.用户界面设计4.3用户界面设计原则(8)个性化用户界面的“

个性化”与“一致性”之间存在微妙的矛盾关系。对于一些非常注重安全性的商业软件而言，用户界面的“一致性”要比“个性化”重要得多，因为一致的界面可以减少用户出错的几率。而对于普通的应用软件而言，有个性化的界面自然比大众化的界面

更具有吸引力。通常计算机专业人员玩过的软件不计其数，界面看多了，真有种“曾经沧海难为水”的感觉。不过当看到一个有创意的界面就啧啧称赞。设计人员应当根据软件的需求以及广大用户的喜好，在使用户界面具备必要的“一致性”的前提下，突出该软件

的“个性”。不仅让用户使用起来方便，而且对软件留下深刻的印象。4.用户界面设计4.3用户界面设计原则(9)合理的布局首先，界面的布局应当符合逻辑，最好能够与工作流程吻合。界面设计人员只有仔细地分析软件的需求，才能提取对界面布局有价值的信息。其次，界面的

布局应当整洁（整齐清爽）。界面元素应当在水平或者垂直方向对齐，行、列的间距保持一致。窗体的尺寸要合适，各种控件不能过分拥挤也不能过分宽松。要善于利用窗体和控件的空白，以及分割用的线条。4.用户界面设计4.3用户界面设计原则(10)和谐的色彩用户界面

是否美观，主要取决于该界面的布局和色彩。如果不是为了显示真实感的图形和图像，那么应当限制一帧屏幕的色彩数目，因为人们在观察屏幕的时候很难同时记住多种色彩。应当根据对象的重要性来选择颜色，重要的对象应当用醒目的色彩表示。使用颜色的时候应当保持一致性，例如错

误提示信息用红色表示，正常信息用绿色表示，那么切勿乱用红色和绿色。在表达信息时，不要过分依赖颜色，因为有些用户是色盲或色弱。4.用户界面设计4.4用户界面设计的规程4.用户界面设计4.5用户界面设计步骤4.用户界面设计4.5用户界

面设计步骤(1)设计准备界面设计人员确定用于指导用户界面设计的详细规则，主要包括：优秀界面的特征或通用的设计原则；软件主界面的设计规则；软件子界面的设计规则；标准控件的使用规则。界面设计人员阅读需求文档和体系结构设计文档，明确界面设计任务。界面设计人员与用户交流，了解用户的工作习惯和他们对界

面的看法。界面设计人员准备相关的设计工具和资料，收集或创作基本的界面资源，如图像、图标及通用的组件。4.用户界面设计4.5用户界面设计步骤(2)界面设计用户界面设计一般要经历原型创作一原型评估一细化等步骤，通常迭代进行。•原型创

作：界面设计人员创作界面原型，例如先徒手画，或者用Visio等工具绘制界面的视图；再用软件开发工具实现可以运行的原型。•原型评估：界面设计人员邀请用户和同行们评估界面的原型，汇集意见，及时改进。•细化：界面设计人员细化界面原型，例如美工处

理，添加细节等。4.用户界面设计4.5用户界面设计步骤(3)撰写用户界面设计文档用户界面设计定型之后，界面设计人员根据指定的模板撰写《用户界面设计报告》。《用户界面设计报告》的参考模板见附录F。(4)设计评审界面设计人员邀请用

户和同行们对定型后的界面进行评审，尽最大努力使界面变得更加易用和美观。4.用户界面设计5.1数据库设计概述数据库是以信息处理为核心的应用系统的基础，数据库设计的质量直接关系到系统开发的成败与优劣。过去常用的方法是E-

R图，存在的主要问题只能对数据建模，而不能对行为建模。而UML类图描述能力更强。对于关系模型来说，可以用类图描述数据库模式，用类描述数据库表。顾名思义，数据库是存储和处理数据用的。人体的数据库是大脑，知识相当于数据，全存在大脑里。如果脑子里存储的知识很多，那么这

个人就显得博学。如果脑子处理知识的速度很高，那么这个人就显得聪明。5.数据库设计5.1数据库设计概述很多人误以为数据库设计就是设计一些表格，觉得那是轻而易举的事情。其实，傻瓜的脑袋并不比正常人的小，他们之所以傻是因为脑子里面存储的东西太少了，并且放进去、取出来的

速度太慢了。数据库设计的主要挑战是“高速处理大容量的数据”。数据库系统和应用软件的数据库区别：数据库系统是指数据库厂商提供的数据库服务器，目前著名的大型数据库系统有Oracle、DB2、Informi

x、Sybase，中型数据库系统如MSServer。而应用软件的数据库则是指开发者在数据库系统中创建的库，用于存储应用软件的数据。5.数据库设计5.2数据库设计的主要工作设计数据库的表（数据就存在表里面），表的结构就是数据的存储结构；对

这些表中的数据进行操作，常见操作如查询、插入、修改、删除等。数据库设计的难易程度取决于两个要素：数据关系的复杂程度和数据量的大小。如果应用软件只涉及几张简单的表，并且数据量特别小，那么设计这样的数据库就非常容易（例如设计一个班级的学生成绩单

数据库）。但是你绝对不能盲目乐观，以为所有的数据库设计都是那么简单。软件开发人员学习数据库设计的特点是：入门很容易，但是成为高手非常难。大家千万不要学万公子写字。5.数据库设计5.3数据库设计的主要问题（1）是否需要开发与平台无关的数据库应用程序目前国际上有很多应用广泛的

数据库系统，这些数据库系统之间的激烈竞争即有好处又有坏处。竞争的好处是使数据库系统不断发展和完善。竞争的最大坏处是逼迫数据库厂商不断开发出独特的功能以吸引更多的用户，所以各个数据库系统的独特功能无法形成统一标准，导致用户难以开发出与平台无关的数据库应用程序。建议：如

果你开发的是通用的数据库应用软件，不想让应用软件与特定的数据库系统捆绑在一起，那么你就老老实实地用SQL语言写程序。如果你开发的是行业专用的数据库应用软件，并且这个行业己经指定了数据库系统，最近若干年都不会改变的话

，那么你可以超越SQL使用该数据库系统的独特功能。5.数据库设计5.3数据库设计的主要问题（2）数据库性能优化问题如何优化数据库的性能是设计人员经常面临的问题。数据库性能优化主要有两种途径：设计人员应当按照第三范式设计

表结构，使得表中没有冗余数据，表结构很清晰，将来修改或者扩充非常方便。反规范化处理是指对第三范式的表进行修改，通过合并一些表，或者在表中创建冗余的列，从而减少表链接操作代价，达到提高性能的目的。除了优化表结构之外，优化数据库的环境

参数也能够提高数据库的性能。例如给服务器配置更快的CPU，增加内存。在安装数据库系统时，要为系统指定“块大小”。在创建表时，也要为表指定一定的空间。5.数据库设计5.4数据库设计的规程5.数据库设计5.5数据库设计的步骤5.数据库设计5.5数据库设计的步骤（

1）设计准备数据库设计人员阅读需求文档和体系结构设计文档，明确数据库设计任务。数据库设计人员准备相关的设计工具和资料。数据库设计人员确定本软件的数据库设计规则（或指南），例如数据库命名规则。5.数据库设计5.5数据库设计的步骤（2）数据库设计逻辑设计：数据库设

计人员根据需求文档，创建与数据库相关的那部分实体关系图。如果采用面向对象设计方法，那么“实体”相当于类。物理设计：按照第三范式设计表结构（即规范化处理）。一般地，实体对应于表，实体的属性对应于表的列，实体之间的关系成为表的约束。逻辑设计中的实

体大部分可以转换成物理设计中的表，但是它们并不一定是一一对应的。5.数据库设计5.5数据库设计的步骤（2）数据库设计安全性设计：用户只能用账号登录到应用软件，通过应用软件访问数据库，而没有其他途径可以操作数据库；对用户账号的密码进行加密处理，确保在任何地方都

不会出现密码的明文；确定每个角色对数据库表的操作权限，如创建、检索、更新、删除等。每个角色拥有刚好能够完成任务的权限，不多也不少。在应用时再为用户分配角色，则每个用户的权限等于他所兼角色的权限之和。性能优化：通过优化表结构本身

和优化数据库的环境参数，对数据库进行调优。5.数据库设计5.5数据库设计的步骤（3）撰写数据库设计文档数据库设计人员根据指定的模板撰写《数据库设计报告》，主要内容包括：数据库环境说明、数据库的命名规则、逻辑设计、物理设计、安全性

设计、性能优化方法、数据库管理与维护说明。《数据库设计报告》的参考模板见附录。（4）设计评审数据库设计人员邀请同行专家、开发人员对数据库进行技术评审，数据库的主要评审要素包括：①正确性、完整性、一致性；②安全性；③

性能。5.数据库设计6.1何为“模块”模块泛指软件系统的功能部件。模块的基本特征是“功能独立，并且可以被集成”。每个模块都具有特定的、明确的功能。人们在设计模块时应当尽量使模块的功能独立，因为功能独立的模块可以降低开发、测试、维护的代价。但是

功能独立并不意味着模块是绝对孤立的。模块之间必定要交流信息、相互配合。比如手和脚是两个“功能独立”的模块。没有脚时，手照样能干活。没有手时，脚仍可以走路。但如果想让人跑得快，那么迈左脚时一定要伸右臂甩左臂，迈右脚时则要伸左臂甩右臂。所以在设计模块时不仅虑“

这个模块应当有什么样的功能”，还要考虑“这个模块应该怎样与其他模块交流信息”。6.模块设计6.1何为“模块”模块如同人的器官。每个器宫都具有特定的功能，它们依附在骨架上。模块是软件系统的部件，它们安插在体系结构上。人体

中设计得最出色的模块是手，手只有几个基本动作，却能做无限多的事情。而最糟糕的设计莫过于嘴巴，嘴巴将很有价值但毫无相干的几种功能如吃饭、说话、亲吻混为一体，使之无法并行处理。所以我们在设计模块时要重视功能独立性，模块的接口应当充分体现该模块的行为特征（即

抽象）。人的嘴巴和耳朵虽然是相对独立的器官，但是如果一个人从小耳朵就聋了，他的嘴巴就只能发出“啊”“呜”的声音，等于丧失了说话的功能。更奇怪的是，瞎子的听力却比正常人的更好。那些看似独立的器官功能常有纠缠不清的时候，真是十分神奇并且十分可笑。所以我们在设计模块时还要追求“高内聚、低耦合”。6.

模块设计6.2模块设计概述在体系结构设计划分的模块基础上，对模块进行接口设计。对象设计是对以前系统分析和设计的结果进行精工细雕，对实现过程使用得类和关联进行定义，以及实现各个操作的算法和接口。根据分析模型，进行对象设计，建立由详细类图、顺序图、

状态图表示的设计模型。最后确定设计的类应该被包到那些模块中。6.模块设计6.3模块设计原则（1）信息隐藏在一节不和谐的课堂里，老师叹气道：“要是坐在后排聊天的同学能像中间打牌的同学那么安静，就不会影响到前排睡觉

的同学。”这个故事告诉我们，如果不想让坏事传播开来，就应该把坏事隐藏起来，“家丑不可外扬”就是这个道理。美国也许是世界上丑闻最多的国家，因为它追求民主，不懂得“隐藏信息”。但美国又是软件产业最发达的国家，模块化设计的方法都是美国人倡导的，他们应该很懂得“隐藏信息”。真是前后矛盾！6.模块设计

6.3模块设计原则（1）信息隐藏为了尽量避免某个模块的行为干扰同一系统中的其他模块，在设计模块时就要注意信息隐藏。应该让模块仅仅公开必须要让外界知道的东西，而隐藏其他一切内容。接口设计是模块设计(构件设计)的核心工作之一，体现了

信息隐藏这一原则。接口是模块的外部特征，应当公开；而结构、算法、实现体等则是模块的内部特征，应当隐藏。一个模块仅提供有限的接口，接口是模块与外界交互的唯一途径。6.模块设计6.3模块设计原则(2)高内聚内聚是一个模块内部各

成分之间相关联程度的度量。模块7种内聚类型，绘制了模块的“内聚谱系”，内聚程度从低到高大致划分为低端、中段和高端。模块设计者没有必要确定内聚的精确级别，重要的是尽量争取高内聚，避免低内聚。6.模块设计6.3模块设计原则（3）低耦合耦

合是模块之间依赖程度的度量。耦合的强度依赖于：一个模块对另一个模块的函数调用数量；一个模块向另一个模块传递的数据量；一个模块施加到另一个模块的控制的多少；模块之间接口的复杂程度。常见的6种耦合类型，绘制了模块的“耦合谱系”，耦合程度从低到高大致

划分为低端、中段和高端，模块设计应当争取“高内聚、低耦合”。6.模块设计6.模块设计6.4模块设计规程6.模块设计6.4模块设计步骤Step1设计准备Step2模块设计2.1接口设计2.2对象设计2.3数据结构与

算法设计Step3撰写文档Step4设计评审6.4模块设计步骤（1）设计准备模块设计人员阅读需求文档和体系结构设计文档，明确模块设计任务。模块设计人员准备相关的设计工具和资料。模块设计人员确定本软

件的编程规范，确保模块设计文档的风格与代码的风格保持一致。6.模块设计6.4模块设计步骤（1）模块设计接口设计：模块设计人员设计每个模块的主要接口。相当于设计类的公有函数。对象设计：组合分析模型获取类上的操作；实现操作的设计算法；优化数据的访问路径；实现外部交互式的控

制；调整类结构提高继承性；设计关联；确定对象表示；把类和关联封装成模块。即通过扩充分析模型，添加对象、动态和功能模型的细节使之文档化。6.模块设计6.4模块设计步骤（1）模块设计数据结构与算法设计数据结构与算法如同人的神经和肌肉，它分布在全身，让器官具有生命并能发挥功能。人之所以能够全身运

动，那是无数的神经和肌肉在起作用。如果局部的神经和肌肉失效了，那么会导致对应的器官残废。如果全局的神经和肌肉失效了，那么人就瘫痪了。同理，数据结构与算法也有全局和局部之分，先设计全局的，后设计局部的每一种数据结构与算法都有其时间、空间的开销和收益。设计者要彻底地掌握怎样

权衡时空开销和算法有效性的方法。6.模块设计6.4模块设计步骤（1）模块设计数据结构与算法设计程序员应该充分地了解一些常用的数据结构与算法，避免不必要的重复设计工作。数据结构与算法为应用服务。我们必须先了解应用的需求，再寻找或设计与实际应用相匹配的数据结构。根据问题的特征，

先查找已经存在的数据结构与算法，挑选最合适的。如果不存在现成的，那么自己设计。设计并且编写代码之后，要进行测试。如果不满足性能要求，那么要进一步优化数据结构和算法。6.模块设计胡清河东北大学信息科学与工程学院

系统工程研究所