软件信息系统设计说明.docx
《软件信息系统设计说明.docx》由会员分享，可在线阅读，更多相关《软件信息系统设计说明.docx（21页珍藏版）》请在冰豆网上搜索。
软件信息系统设计说明
第五章系统设计
系统设计是把需求转化为软件系统的最重要的环节。
系统设计的优劣在根本上决定了软件系统的质量。
就象“一切帝国主义都是纸老虎”那样可以断定“差的系统设计必定产生差的软件系统。
”所以我们要努力保证系统设计“根正苗红”，把一切左倾、右倾的设计思潮消灭在萌芽状态。
WindowsNT的一位系统设计师拥有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）来替换另一种完全不同的实现（如用卫星信道来代替所有的线），只要新的实现能向上层提供同一组服务就可以了。
[Tanenbaum1998]
考上“举人”时已五十多岁了
复习报考“举人”用了几十年
图5.1（a）从小学读到博士存在的五个学习阶段图5.1（b）进的知识结构
图5.2计算机网络的OSI参考模型
三、其它的层次结构
目前在大型商业应用软件系统中还流行一种包含中间件（Middleware）的层次结构，如图5.3所示[Jacobson1997]。
中间件支持与平台无关的分布式计算，可以用DCOM和CORBA对象来实现。
图5.3包含中间件的层次结构
5.1.2客户机/服务器结构
让我们先回顾一下早期的系统。
贝尔（AlexanderGrahamBell）于1876年申请了专利。
那时期的必须一对一对地卖，用户自己在两个之间拉一根线。
如果一个用户想和其它几个用户通话，他必须拉n根单独的线到每个人的房子里。
于是在很短的时间，城市里到处都是穿过房屋和树木的混乱的线。
很明显，企图把所有的完全互联（如图5.4（a）所示）是行不通的。
贝尔公司在1878年开办了第一个交换局。
公司为每个客户架设一条线。
打时，客户摇动的曲柄使公司办公室的铃响起来，操作员听到铃声以后根据要求将呼叫方和被呼叫方用跳线手工连接起来。
这种集换式的模型如图5.4（b）所示。
很快地，贝尔系统的交换局就出现在各地。
人们又要求能打城市间的长途，就出现了二级交换局，以后进一步发展为多个二级交换局。
[Tanenbaum1998]
5.4（a）完全互联的系统5.4（b）集换式的系统
如果将图5.4（b）中的看成是客户程序，将中心的交换局看成是服务程序，那么图5.4（b）就是典型的客户机/服务器结构。
注意这里客户机和服务器都是指软件而不是指硬件（一台计算机可以放多个客户机和服务器软件）。
客户机/服务器结构存在两个显然的优点：
（1）以集中的方式高效率地管理通讯。
前面讲系统的故事就是要说明这一点。
（2）可以共享资源。
比如在信息管理系统中，服务器将信息集中起来，任何客户机都可以通过访问服务器而获得所需的信息。
客户机和服务器之间的通讯以“请求——响应”的方式进行。
客户机先向服务器发起“请求”（Request），服务器再响应（Response）这个请求，如图5.5所示。
请求
响应
图5.5Client和Server之间的通讯以“请求——响应”的方式进行
采用“请求——响应”这种通讯方式的基本动机是为了解决“聚集”（Rendezvous）问题。
为了理解这一个问题，设想一个人试图在分离的机器上启动两个程序并让它们进行通讯。
还需记住，计算机的运行速度要比人的操作速度高出许多数量级。
在他启动第一个程序后，该程序开始执行并向对等程序发送消息。
在几个微秒，它便发现对等程序还不存在，于是就发出一条错误消息，然后退出。
此后，他启动了第二个程序。
不幸的是，当第二个程序开始执行时，它也找不到第一个程序（早已退出）。
即使这两个程序连续地重新试着通讯，但由于它们的执行速度那么高，以致于它们在同一瞬间联系上的概率非常低。
在客户机/服务器结构中，服务器在启动后必须（无限期地）等待客户机的“请求”，因此就形成了“请求——响应”的通讯方式。
在Internet/Intranet领域，目前“浏览器—Web服务器—数据库服务器”结构是一种非常流行的客户机/服务器结构，如图5.6所示。
这种结构最大的优点是：
客户机统一采用浏览器，这不仅让用户使用方便，而且使得客户机端不存在维护的问题。
当然，软件开发布和维护的工作不是自动消失了，而是转移到了Web服务器端。
在Web服务器端，程序员要用脚本语言编写响应页面。
例如用Microsoft的ASP语言查询数据库服务器，将结果保存在Web页面中，再由浏览器显示出来。
请求
查询
响应
图5.6“浏览器—Web服务器—数据库服务器”结构
5.2模块设计
在设计好软件的体系结构后，就已经在宏观上明确了各个模块应具有什么功能，应放在体系结构的哪个位置。
我们习惯地从功能上划分模块，保持“功能独立”是模块化设计的基本原则。
因为，“功能独立”的模块可以降低开发、测试、维护等阶段的代价。
但是“功能独立”并不意味着模块之间保持绝对的孤立。
一个系统要完成某项任务，需要各个模块相互配合才能实现，此时模块之间就要进行信息交流。
比如手和脚是两个“功能独立”的模块。
没有脚时，手照样能干活。
没有手时，脚仍可以走路。
但如果希望跑得快，那么迈左脚时一定要伸右臂甩左臂，迈右脚时则要伸左臂甩右臂。
在设计一个模块时不仅要考虑“这个模块就该提供什么样的功能”，还要考虑“这个模块应该怎样与其它模块交流信息”。
本节将论述评价模块设计优劣的三个特征因素：
“信息隐藏”、“聚与耦合”和“封闭——开放性”。
5.2.1信息隐藏
在一节不和谐的课堂里，老师叹气道：
“要是坐在后排聊天的同学能象中间打牌的同学那么安静，就不会影响到前排睡觉的同学。
”
这个故事告诉我们，如果不想让坏事传播开来，就应该把坏事隐藏起来，“家丑不可外扬”就是这个道理。
为了尽量避免某个模块的行为去干扰同一系统中的其它模块，在设计模块时就要注意信息隐藏。
应该让模块仅仅公开必须要让外界知道的容，而隐藏其它一切容。
模块的信息隐藏可以通过接口设计来实现。
一个模块仅提供有限个接口（Interface），执行模块的功能或与模块交流信息必须且只须通过调用公有接口来实现。
如果模块是一个C++对象，那么该模块的公有接口就对应于对象的公有函数。
如果模块是一个COM对象，那么该模块的公有接口就是COM对象的接口。
一个COM对象可以有多个接口，而每个接口实质上是一些函数的集合。
[Rogerson1999]
美国也许是世界上丑闻最多的国家，因为它追求，不懂得“隐藏信息”。
但美国又是软件产业最发达的国家，模块化设计的方法都是美国人倡导的，他们应该很懂得“隐藏信息”。
真是前后矛盾，这些美国佬！
5.2.2聚与耦合
聚（Cohesion）是一个模块部各成分之间相关联程度的度量。
耦合（Coupling）是模块之间依赖程度的度量。
聚和耦合是密切相关的，与其它模块存在强耦合的模块通常意味着弱聚，而强聚的模块通常意味着与其它模块之间存在弱耦合。
模块设计追求强聚，弱耦合。
一、聚强度
聚按强度从低到高有以下几种类型：
（1）偶然聚。
如果一个模块的各成分之间毫无关系，则称为偶然聚。
（2）逻辑聚。
几个逻辑上相关的功能被放在同一模块中，则称为逻辑聚。
如一个模块读取各种不同类型外设的输入。
尽管逻辑聚比偶然聚合理一些，但逻辑聚的模块各成分在功能上并无关系，即使局部功能的修改有时也会影响全局，因此这类模块的修改也比较困难。
（3）时间聚。
如果一个模块完成的功能必须在同一时间执行（如系统初始化），但这些功能只是因为时间因素关联在一起，则称为时间聚。
（4）过程聚。
如果一个模块部的处理成分是相关的，而且这些处理必须以特定的次序执行，则称为过程聚。
（5）通信聚。
如果一个模块的所有成分都操作同一数据集或生成同一数据集，则称为通信聚。
（6）顺序聚。
如果一个模块的各个成分和同一个功能密切相关，而且一个成分的输出作为另一个成分的输入，则称为顺序聚。
（7）功能聚。
模块的所有成分对于完成单一的功能都是必须的，则称为功能聚。
二、耦合强度
耦合的强度依赖于以下几个因素：
（1）一个模块对另一个模块的调用；
（2）一个模块向另一个模块传递的数据量；（3）一个模块施加到另一个模块的控制的多少；（4）模块之间接口的复杂程度。
耦合按从强到弱的顺序可分为以下几种类型：
（1）容耦合。
当一个模块直接修改或操作另一个模块的数据,或者直接转入另一个模块时，就发生了容耦合。
此时，被修改的模块完全依赖于修改它的模块。
（2）公共耦合。
两个以上的模块共同引用一个全局数据项就称为公共耦合。
（3）控制耦合。
一个模块在界面上传递一个信号（如开关值、标志量等）控制另一个模块，接收信号的模块的动作根据信号值进行调整，称为控制耦合。
（4）标记耦合。
模块间通过参数传递复杂的部数据结构，称为标记耦合。
此数据结构的变化将使相关的模块发生变化。
（5）数据耦合。
模块间通过参数传递基本类型的数据，称为数据耦合。
（6）非直接耦合。
模块间没有信息传递时，属于非直接耦合。
如果模块间必须存在耦合，就尽量使用数据耦合，少用控制耦合，限制公共耦合的围，坚决避免使用容耦合。
5.2.3封闭——开放性
如果一个模块可以作为一个独立体被其它程序引用，则称模块具有封闭性。
如果一个模块可以被扩充，则称模块具有开放性。
从字面上看，让模块具有“封闭——开放性”是矛盾的，但这种特征在软件开发过程中是客观存在的。
当着手一个新问题时，我们很难一次性解决问题。
应该先纵观问题的一些重要方面，同时作好以后补充的准备。
因此让模块存在“开放性”并不是坏事情。
“封闭性”也是需要的，因为我们不能等到完全掌握解决问题的信息后再把程序做成别人能用的模块。
模块的“封闭——开放性”实际上对应于软件质量因素中的可复用性和可扩充性。
采用面向过程的方法进行程序设计，很难开发出既具有封闭性又具有开放性的模块。
采用面向对象设计方法可以较好地解决这个问题。
5.3数据结构与算法设计
学会设计数据结构与算法，可以让我们编写出高效率的程序。
也许有人要问，在计算机速度日新月异的今天，为什么还需要高效率的程序？
因为我们的雄心与能力是一起增长的，技术进步最快也快不过人们欲望的增长。
计算速度和存储容量上的革新仅仅提供了处理更复杂问题的有效工具，所以高效率的程序永远不会过时。
设计高效率的程序是基于良好的数据结构与算法，而不是基于编程小技巧。
大多数计算机科学系在设置课程时，都重视学习基本的软件工程原理，以与数据结构与算法设计。
一般说来，数据结构与算法就是一类数据的表示与其相关的操作（这里算法不是指数值计算的算法）。
从数据表示的观点来看，存储在数组中的一个有序整数表也是一种数据结构。
算法是指对数据结构施加的一些操作，例如对一个线性表进行检索、插入、删除等操作。
一个算法如果能在所要求的资源限制（ResourceConstraints）围将问题解决好，则称这个算法是有效率（Efficient）的。
例如一个资源限制可能是“用于存储数据的存有限”，或者“允许执行每个子任务所需的时间有限”。
一个算法如果比其它已知算法所需要的资源都少，这个算法也被称为是有效率的。
算法的代价（Cost）是指消耗的资源量。
一般说来，代价是由一个关键资源例如时间或空间来评估的。
毋庸置疑，人们编写程序是为了解决问题。
只有通过预先分析问题来确定必须达到的性能目标，才有希望挑选出正确的数据结构。
有相当多的程序员忽视了这一分析过程，而直接选用某一个他们习惯使用的，但是与问题不相称的数据结构，结果设计出一个低效率的程序。
如果使用简单的设计就能够达到性能目标时，选用复杂的数据结构也是没有道理的。
人们对常用的数据结构与算法的研究已经相当透彻，可以归纳出一些设计原则：
（1）每一种数据结构与算法都有其时间、空间的开销和收益。
当面临一个新的设计问题时，设计者要彻底地掌握怎样权衡时空开销和算法有效性的方法。
这就需要懂得算法分析的原理，而且还需要了解所使用的物理介质的特性（例如，数据存储在磁盘上与存储在存中，就有不同的考虑）。
（2）与开销和收益有关的是时间——空间的权衡。
通常可以用更大的时间开销来换取空间的收益，反之亦然。
时间——空间的权衡普遍地存在于软件开发的各个阶段中。
（3）程序员应该充分地了解一些常用的数据结构与算法，避免不必要的重复设计工作。
（4）数据结构与算法为应用服务。
我们必须先了解应用的需求，再寻找或设计与实际应用相匹配的数据结构。
[Shaffer1998]
5.4用户界面设计
某个人总有办法让自己保持心情愉快、信心十足。
有一天，他向一名围棋九段和一名乒乓球世界冠军挑战，结果他全胜了。
因为他跟围棋九段打乒乓球，跟乒乓球冠军下围棋。
用户界面的编程技术是人们熟悉得不得了的事，我决定讲一讲比较陌生的“用户界面设计美学”。
有位爱好书画的博士后请我欣赏钢琴演奏会。
我从头到尾只听到“叮叮咚咚”的声音，实在享受不到“高雅”，就请这位朋友指点。
他虽然也不懂钢琴，却从欣赏书法的角度设法解释如何欣赏音乐。
可是我既不懂书法也不懂音乐，真是坐立不安。
“美”似乎真的不可言传。
我在读本科时，特别喜欢编写用户界面程序，并且常向同学演示、卖弄。
我觉得还不过瘾，就写了一篇“用户界面设计美学”的短文[林锐1997]。
凡是路过我实验室的同学都被我逮住，被迫听完我得意之极的朗读，茫然者与痛苦者居多。
不久我的朗读便所向披糜，闻声者逃之夭夭。
现在我又把那篇短文摘录至此，请您忍着点吧。
5.4.1界面设计中美的需求与导向作用
人们对美的向往和追与生俱有的。
显然没有人愿意丑化自己的程序，也没有用户嗜好丑陋的界面。
软件开发者要设计美，用户要享受美，所以界面的美是开发者与用户的共同需求。
界面美的概念很抽象，以致让人无法说清楚什么是界面的美。
但它同时又很现实，以致人人都可以去欣赏和感受界面美，并且挑剔美中之不足。
美学不是一种量化的学问，如果因此而轻视美学指导，必将导致在设计过程中光依赖程序员个人的经验与感觉。
由于程序员接受的教育主要是如何使计算机完成工作，而不是人如何工作，因此仅靠程序员主观想象设计而成的界面往往得不到大众用户的认可。
美的界面能消除用户由感觉引起的乏味、紧和疲劳（情绪低落），大大提高用户的工作效率，从而进一步为发挥用户技能和为用户完成任务作出贡献。
从人机界面发展历史与趋势上可以看出人们对界面美的需求，以与美在界面设计中的导向作用。
界面设计已经经历了两个界限分明的时代。
第一代是以文本为基础的简单交互，如常见的命令行，字符菜单等。
由于第一代界面考虑人的因素太少，用户兴趣不高。
随着技术的发展，出现了第二代直接操纵的界面。
它大量使用图形、语音和其它交互媒介，充分地考虑了人对美的需求。
直接操纵的界面使用视听、触摸等技术，让人可以凭借生活常识、经历和推理来操纵软件，愉快地完成任务。
更高层次的界面甚至模拟了人的生活空间，例如虚拟现实环境。
界面的美充分体现了人机交互作用中人的特性与意图，越来越多的用户将通过具有吸引力而令人愉快的人机界面与计算机打交道。
5.4.2界面美的涵
本节从合适性、风格和广义美三个方面论述界面美的涵。
一、界面的合适性
界面的合适性是指界面是否与软件功能相融洽。
如果界面不适合于软件的功能，那么界面将毫无用处，界面美的涵就无从谈起。
所以界面的合适性是界面美的首要因素，它提醒设计者不要片面追求外观漂亮而导致失真或华而不实。
界面的合适性既提倡外美秀，又强调恰如其分。
合适性差的界面无疑会混淆软件意图，致使用户产生误解。
即使它不损害软件功能与性能，也会使用户产生不该有的情绪波动。
例如一些软件开发者喜欢为其作品加一段动画演示，以便吸引更多用户的关注。
这本是无可非议的，问题在于这演示是否合情合理。
如果运行一个程序，它首先表演一套复杂的动画，在后台演奏雄壮的进行曲，电闪雷鸣之后出来的却是一个普通的文本编辑器。
整个过程让用户置身于云里雾里，而结果却让用户感到惊谔而不是惊喜。
合适性差的界面只会给软件带来厄运。
二、界面的风格
界面的风格有两类，一是“一致性”，二是“个性化”。
商业应用软件的界面设计注重一致性。
设计者必须密切注意在一样应用领域中最流行的软件的界面，必须尊重用户使用这些软件的习惯。
例如商业软件习惯于设置F1键为帮助热键，如果某个设计者别出心裁地让F1键成为程序终止的热键，那么在用户渴望得到帮助而伸手击F1键的一刹那，他的工作就此完蛋。
相信这个用户“一朝被蛇咬，十年怕井绳”。
目前流行的软件开发工具如VisualC++、VisualBasic、Delphi、C++Builder、PowerBuilder等，都能够快速地开发出非常相似的图形用户界面。
在Internet/Intranet领域，浏览器几乎成了唯一的客户机程序，因为用户希望用完全一致的软件来完成千变万化的应用任务。
在娱乐领域的软件中，有个性化的界面自然比泯然于众的界面更具有吸引力。
一般说来，计算机专业人员玩过的软件不计其数。
界面看多了，真有种“曾经沧海难为水”的感觉。
不过当我看到一个叫Sonique的放音乐的软件时，不禁对其界面的创意啧啧称赞，忍不住象贴美女像那样把它贴到书中，如图5.7所示。
图5.7Sonique软件的几种界面
人们经常搞不清楚什么情况下应该追求“一致性”或“个性化”。
在大白天，当人们都穿戴整齐时，有些人喜欢只挂几片遮羞布。
而当大家都赤条条地在共公浴室洗澡时，却也有人喜欢穿着衣服。
三、界面的广义美
尽管界面的美并没有增加软件的功能与性能，却又是必为可少的。
用户使用界面时，除了直接的感官美感外，还有很大一部分美感是间接的，它们存在于人们的使用体验中，例如方便，实用等。
与图形用户界面相比，命令行是最原始的界面，它难记又难看。
但对于熟练的用户而言，他们乐于使用命令行以获得高效率。
命令行因具有高效率而赢得了专业人士的喜爱，早期的Unix系统就是彻头彻尾的命令系统。
可以说，一切有利于人机交互的界面设计因素都具有广义美。
界面设计的一些特殊考虑也体现了广义美，如设法使残障人也可以使用软件。
IB
升级会员 