C/S结构的数据库应用

最简单的C/S体系结构的数据库应用，由两部分组成，即客户应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序的机器，称为应用服务器，一旦服务器程序被启动，就随时等待响应客户程序发来的请求；客户程序运行在用户自己的电脑上，对应于服务器电脑，可称为客户电脑。当需要对数据库中的数据进行任何操作时，客户程序就自动地寻找服务器程序，并向其发出请求，服务器程序根据预定的规则作出应答，送回结果。 在典型的C/S数据库应用中，数据的储存管理功能，是由服务器程序独立进行的，并且通常把那些不同的（不管是已知还是未知的）前台应用所不能违反的规则，在服务器程序中集中实现，例如访问者的权限，编号不准重复、必须有客户才能建立定单这样的规则。所有这些，对于工作在前台程序上的最终用户，是“透明”的，他们无须过问（通常也无法干涉）这背后的过程，就可以完成自己的一切工作。在客户服务器架构的应用中，前台程序可以变的非常“瘦小”，麻烦的事情，都交给了服务器和网络。在C/S体系的下，数据库真正变成了公共、专业化的仓库，受到独立的专门管理。

非C/S结构的应用

与C/S体系形成对比，传统的数据库应用体系结构，例如基于主机-多终端的系统，或基于LAN上文件服务器运做的多用户系统，数据库是属于应用程序“私有的”，即使它也可以将数据文件放置在某台机器上供不同的用户共同访问（这种情形，称为“文件服务器”），但所有的操作、规则，都是在一个包罗万象的应用程序内部实现的。应用程序因此具有最大的复杂性，即使是原班开发人马，要想对已有功能加以扩充也是很困难的，当数据库稍具复杂性（比如有稍多相互关联的表与规则），其他的人员开发另外的程序共同操作这个数据库的数据，几乎不具可行性。

是否采用C/S体系结构的讨论

当前确定的需求

在这个案例中，已经确定的需求，就是建立一个集中、统一的数据库，实现更新、查询和格式化打印输出操作。访问者分布在总公司（约30人的规模，集中办公，连结于一个小型的LAN中）和外地的子公司（同样是集中办公，连结于一个比总公司大的LAN中）。每一处典型的同时访问人数，在10人以下。两处都有机会更新数据库中的数据。理想的情况下当然是两处的数据随时保持一致，但在特别关键的信息可以随时通过电话、传真等方式直接交换的情况下，两地的信息每隔一至二天交换更新一次，是可以接受的，这也就是目前的实际情况，从业务人员的立场上，尚没有提出在这个周期上作出戏剧性的改变的要求。针对当前的已经明确的需求，作出如下讨论：

采用C/S架构，选择适当的数据库平台，可以实现数据库数据的真正“统一”，分布于两地的数据同步完全交由数据库系统去管理，逻辑上，两地的操作者都直接访问同一个数据库。它的有效实现，有这样一些问题：

1. 如果需要建立“实时”的数据同步，就必须在两地间建立实时的通讯连

接，保持两地的数据库服务器在线运行，这需要高昂的投资和复杂的技术支持，高的维护成本。

2. 可以根据实际的需要，采用“间歇”同步策略，通过合理分配两地的工作

（这一点是现实业务中已经很好地实现的），基本可以避免分别更新数据可能对业务带来的问题。对数据库同步更新的间隔，可以天为最小单位，在这样的同步需求下，采用复杂和昂贵的“分布式数据库”管理技术[注1]，是不划算的。

在该案例中，当前需求的一个重要特征，是在LAN中的多用户操作。进一步分析该客户的要求可以得知，数据更新的频率是很低和集中于少数用户的。大量可能的并发性操作来自查询。

对于本例的应用要求和环境，采用基于网络文件服务器开发非C/S结构的应用，也完全可以满足，虽然C/S结构下的多用户应用可以更好（比如更完善的用户共享特性，用户管理，以及更好地平衡服务器与客户机之间的负荷，大幅度降低网络传输的负荷等），但就用户立场而言，并没有采用C/S结构直接的必要性。

[注1]：应当说明，对于其他的架构的数据库体系，同样可以实现分布式的数据存储与管理，但从本例实现的角度看，比起基于C/S架构的体系，要复杂和昂贵。 潜在和不确定的需求

在电脑应用定制开发的领域，要想真正令客户满意，就必须真正理解用户的需求，尤其是那些潜在的需求。比如，上述对数据同步更新频率的需求，是基于现在的业务方式与节奏的，一旦电脑系统投入应用，改变了整个作业的节奏，就可能提出更高的要求。此外，公司的业务量的不断发展，客户对于公司作出反映的时间的提高，都会导致对电脑系统需求的提高。

在这个案例中，用户的应用方式和规则具有不确定性和不断改变发展的特征，但数据库描述的基本对象却具有相对稳定、有序扩充的特点，因而数据库的结构相对稳定，也就是说，基于对实体的深入分析和抽象作出的数据表是相对稳定的，随着未来的发展，多数的变化将是新表的增加及数据项的增加，而较少更改。

针对这个特征最直接有效的策略，就是将易变的部分（应用和应用规则）和相对稳定的部分（数据和基本属性、结构）分离，这正是C/S结构数据库应用的典型模式。

从原理和经验上看，对本案例或类似的应用，C/S结构是目前技术条件下，能较好适应不确定和变化的需求环境的比较现实的方案。它可以令我们以较低的

投入，实现将易变与稳定的要素分离，快速地增添和替换“瘦小”而互相独立的前台应用，保持数据的连续性和继承性。

未来的需求

在这个案例中，用户确认了这样的应用发展策略：由点到面，由简到繁逐步引进电脑化作业方法，稳步改进日常的业务模式，并期望于时机成熟的时候开展基于信息技术的业务流程重规划。

具体应用的规划是：先建立简单有效的数据库应用，进一步开发更多的，更具专业性、更深入的应用项目，进而在更大的范围上应用，最终期望将客户也纳入到电脑系统的用户中来，实现客户与销售人员的远程在线查询、下单。在指导性的发展规划中，具体提出了企业内部的互连网（Intranet）和面向国际互连网（Internet）的应用远景。

在这样的应用策略下，对电脑应用的开发，将是一个逐步完善的过程，对这样的开发环境，上一节中已经做了分析。

以目前的技术看，先建立C/S结构的局域网络应用，再向Internet/Intranet模式下数据库应用过渡，是比较现实，相对易于把握、成本较低的。即使是一次到位的开发，对于类似的环境和小型的应用而言，要想实现不同的人员，从不同的地点，以不同的接入方式（比如LAN, WAN, Internet/Intranet等）访问和操作共同的数据库，并有效地保证和管理数据的安全性、访问权限、完整性，采用C/S架构和支持C/S架构的数据平台，是必然选择。

成本和资源的考虑

由于用户已经建立并运行着LAN、文件服务器，并运行着（并且以后也要继续运行）一些基于PC或PC LAN的应用，现行的硬件设备基本上不用大的扩充，就可以运行基于文件服务器的多用户数据库或基于应用服务器的C/S应用。 采用C/S体系结构，客户所支出的费用项目，将增加数据库平台和对其维护的成本，和可能需要增加适合数据库平台运行的应用服务器操作系统。

这样，从现有资源出发，不考虑开发的成本，最直接而经济的实现方案，是建立基于文件服务器的多用户系统，其次才是C/S体系结构。相比之下，主机模式无论从软硬件投资、开发成本上都是巨大的，没有什么理由替代前两种模式。 发布、运行与维护的考虑

由于数据库用户的地理位置和数量增加的可能，需要考虑安装上的因素。C/S结构的应用至少需要设置客户和服务器两个项目，而基于文件服务器的应用，通常只需要一次性的安装和设置。现在的客户服务器开发技术，可以将客户端作成简单复制一个瘦小的执行文件就可以运行，客户端通常没有维护的要求，对服务器的安装设置则是一次性的。

对于非C/S架构的数据库系统来说，维护方面的性能也是在应用程序的开发中决定的。这样的系统，通常都需要原设计开发者才能比较好地维护。

C/S架构的数据库系统，由于数据库是建立在通用的平台之上，并且支持SQL这样的通用技术，对数据库的维护工作更加专业，但更为开放，这意味着维护和进一步开发对原设计开发者的依赖性可以降低。用户可以更好地适应人员的流动或服务/供应商的变更。对体系规划的合理性，和一些特殊技术的采用，例如后台服务器上的存储过程、触发器等，会影响到这个特点。出于这个理由，在C/S应用设计时，应尽可能采用规范的模式，标准化的技术。同样的努力，在其他架构中就相对难以实现或较少实际意义。

性能、开发与品质保证的考虑

非C/S结构应用的性能，更大程度取决于应用程序的设计与实现。基于文件服务器运行的多用户系统，当数据量、用户数扩大时，性能就会严重下降，这包括巨大的网络传输量，以及难以有效地平衡工作站与服务器的负荷。因此，大的数据容量和多用户环境，通常是采纳C/S结构的一个重要理由。主机-终端模式虽然可能更具能量，但高成本和封闭性，限制了它的应用领域。

从运行上来看，同样设计良好的系统，C/S结构引入了更多的“衔接”环节，这意味着故障的机会和资源的耗费，然而，一旦系统处于开放的网络与应用环境中，这些开销就变成是必须的。

对于具备良好的规划能力的开发者而言，C/S结构给予规划者更大的空间和更强的支持，易于实现不同应用间的合理分离，分别调试和投入应用。前台应用和后台数据库的开发，被“强制”地分开；数据库部分的逻辑与规则，一经调试完成，就可以在将来的应用中一直保证下去；在一个动态改进或逐步扩充的开发环境，或复杂的应用环境中，这些都是提高系统可靠性有利因素。对基于文件服务器的系统而言，每次增加或修改功能，通常都意味着整个系统的升级，前后台的一体化，也就意味着每次变更都有更大的可能性造成对原有规则的破坏，并引起连锁效应。

以目前的技术环境而言，在C/S结构下，有更多成熟的，适合不同规模应用的开发平台与数据库平台可供选择，并普遍遵循或采用SQL等标准或技术，相对较具开放性，有更多的技术支持、开发与维护人员的来源，并且——基于技术与行业发展的趋势，将来也会有更多的发展和保障。

小结

总结以上的种种分析，可以发现，对于这个特定的案例，仅就当前已确定的和希望马上实现的需求而言，可以用传统的，基于LAN的文件服务器的多用户系统实现，但考虑到用户真实需求的不确定性和不断扩充的可能等等因素，有更多的理由支持采用C/S体系结构。作为一种权宜的方案，也可以考虑先采用基于文件服务器的多用户系统，在规划和实现上，尽量为将适当时候来转换成为C/S

结构打下基础。此外，如果采用C/S体系结构，还应当尽可能采用开放的，标准的技术。

在上面的分析中，支持采用C/S的理由主要有：

应用的不确定性，逐步开发和增加新应用的需要

适应将来开放的异种网络环境中应用的需要

用户数、数据量增长的可能性

适应电脑开发、维护、供应商与相关技术人员变更的需要

有利于动态规划与动态开发过程，对系统可靠性的保证

此外，从用户的现有资源的延续利用与新增投入，及开发的成本和难度看，采用C/S结构，也是比较适中、现实的选择。

第二篇：软件体系结构总结

1、 软件危机：软件开发维护过程中的遇到一系列严重问题

表现：软件成本日益增长，开发进度难以控制，软件质量差，软件维护困难，

原因；用户需求不明确，缺乏正确的理论指导，软件规模越来越大，软件复杂度越来越高，

软件工程是用工程科学和数学的原则和方法研制，维护计算机软件的有关技术及管理方法 软件工程三要素，方法，工具，过程

解决方法：管理，采用工程化的开发方法，加大软件重用，采用先进的开放工具 2、软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。 特点：从高层抽象了软件系统结构、行为、属性。

软件体系结构的意义： 体系结构是风险担保者进行交流的手段

是早期设计决策的体现 是可传递和可重用的模型

3、构件是语义完整，语法正确和有可重用价值的单位软件是软件重用过程中可以明确

辨识的系统，

构件模型是对构件本质特征的抽象描述 分类：参考模型，描述模型，实现模型

构件分类方法：关键字分类法，刻面分类法，超文本分类法

4、软件体系结构模型：结构模型，动态模型，框架模型，过程模型，功能模型

5、4+1 视图模型从五个不同的视角包括 逻辑视图，开发视图，进程视图，物理视图和场景

逻辑视图：主要支持系统功能需求：即系统提供给最终用户的服务

开发视图：主要侧重于软件模块的组织和管理

进程视图：系统的运行特征，主要关注与一些非功能性的需求

物理视图：主要考虑如何把软件映射到硬件上，他通常考虑系统性能，规模，可靠性，解决系统拓扑结构，系统安装，通讯等问题

场景：可以看作是那些重要系统活动的抽象，它使四个视图有机联系在一起，

6、软件体系结构的核心模型：构件，连接件，配置，端口，和角色

7、软件体系风格：是描述某一特定应用领域中系统组织方式的惯用模式

最关键的四要素内容：一个词汇表，定义一套配置规则，定义一套语义解释原则 定义对基于这种风格的系统所进行的分析

经典体系结构风格：数据流风格，调用/返回风格，独立构件风格，虚拟机风格，仓库风格

几种软件风格

8，为什么使用异构风格

不同的结构有不同的处理能力的强项和弱项

关于软件包，框架，通信以及其他一些体系结构上的问题

一些遗留下来的代码

9，体系结构描述方法：

图形表达工具 有矩形和有向线段组合而成的图形表达工具

模块连接语言：采用一种或几种传统程序设计语言的模块连接起来的内连接语言MIL 基于软构件的系统描述语言

软件体系结构描述语言：ADL 在底层语义模块的支持下，为软件系统的概念体系结构提

供了具体的语法和概念框架，基于底层语义的工具为体系结构表示分析 演化 分化设计构成提供支持 三个基本元素 构件 连接件 体系结构配置

优点

缺点

UML ：统一建模语言是一个通用的可视化建模语言，用于对软件精星描述，可视化处理，构造，和建立软件体系的文档，

A、状态图 B、用例图 C、时序图 D、配置图

E、协作图 F、类图