软件体系结构

前言：想要写出一篇令人眼前一亮的文章吗？我们特意为您整理了5篇软件体系结构范文，相信会为您的写作带来帮助，发现更多的写作思路和灵感。

软件体系结构范文第1篇

关键词：体系结构；分层；OSI

中图分类号：TP311 文献标识码：A文章编号：1007-9599 (2011) 07-0000-01

The Hierarchy of SoftwareArchitecture

Li Qiang,Yang Wenqing

(Jiangxi BlueSky University,Ministry of Public Education,Nanchang330098,China)

Abstract:This article mainly introduces software architecture the basic thought that carries on the layer division,has comprehensively analyzed the architecture division layer necessity,the corresponding rules and the good and bad points.

Keywords:Architecture;Stratify;OSI

20世纪90年代以来，随着计算机网络技术的发展和成熟，特别是Internet的普及，将应用扩展到局域网、广域网，甚至Internet已成为用户的普遍需求，另一方面，随着应用的拓展和系统规模的扩大，计算机软件的复杂程度也在不断地增加，软件体系结构在软件设计和开发过程中所起的作用越来越重要，采用层次式软件体系结构的设计思想也越来越受到人们的重视。

一、软件体系结构的概念

虽然软件体系结构已经在软件工程领域中有着广泛的应用，但迄今为止还没有一个被大家所公认的定义。许多专家学者从不同角度和不同侧面对软件体系结构进行了刻画，其中一个较为典型的定义是由Mary Shaw和David Garlan所提出来的，他们认为：软件体系结构是软件设计过程中的一个层次，(即不但软件体系结构具有层次性，从整体上来看软件体系结构本身也是作为软件设计过程中的一个层次）只不过这一层次超越计算过程中的算法设计和数据结构设计。

二、软件体系结构的层次

“分层”可将庞大而复杂的问题，转化为若干较小比较易于研究和处理的局部问题。分层是表示将功能进行有序的分组：应用程序专用功能位于上层，跨越应用程序领域的功能位于中层，而配置环境专用功能位于低层。层的数量与组成取决于问题领域和解决空间的复杂程度。

从整体上看一般可以分为三个层次：客户端层、中间层和数据源层。

1.客户端层是将数据呈现给用户或处理用户输入的应用程序或系统一部分。客户端也称为前端，它并不执行数据函数，而是通过输入向服务器请求数据，然后以一定的格式显示结果。

2.中间层是用户接口或Web客户端与数据库之间的逻辑层。

3.数据源层是用来控制你程序的流程。

（一）分层规则

分层是从逻辑上将一个完整的系统划分成许多个子系统的集合，而层间关系的形成必然要遵循一定的规则。通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。其具体规则如下：

1.可见度。各子系统只能与同一层及其下一层的子系统存在依赖关系。

2.易变性。最上层放置随用户需求的改变而改变的元素。最底层放置随实施平台的改变而改变的元素。中间的夹层放置广泛适用于各种系统和实施环境的元素。如果在这些大类中进一步划分有助于对模型进行组织，则添加更多的层。

3.通用性。一般将抽象的模型元素放置在模型的低层。如果它们不针对于具体的实施，则倾向于将其放置在中间层。

分层反映实体模块之间的依赖关系，层数并不是越多越好，适当最好。对于小型系统，三层就足够了。对于复杂系统，通常需要5-7层。（二）采用层次系统的优缺点

层次系统有许多可取的属性：

1.系统的开发和设计可以逐步的分层次的进行，从底层的简单的功能逐步建立高层的复杂和抽象的功能。这样就可能把一个复杂的系统按递增的步骤进行分解；

2.支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层；

3.支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。

但是，层次系统也有其不足之处：

1.并不是每个系统都可以很容易地划分为分层的模式，划分清晰、逻辑上一致的层次是非常困难的（OSI的失败和TCP/IP的成功说明了这一点）；

2.严格的层次调用结构会降低系统的性能；

3.很难找到一个合适的、正确的层次抽象方法。

（三）分层协议的体系结构

(Open Systems Interconnection)简称OSI，OSI标准采用的方法是将整个庞大而复杂的问题划分为若干个容易处理的小问题，这就是分层的体系结构方法。OSI是分层体系结构的一个实例，每一层是一个模块，用于执行某种主要功能，并具有自己的一套通信指令格式。根据分而治之的原则，OSI将整个通信功能划分为七个层次，划分层次的主要原则是：

1.网中各结点都具有相同的层次；

2..不同结点的同等层具有相同的功能；

3.同一结点内相邻层之间通过接口通信；

4.每一层可以使用下层提供的服务，并向其上层提供服务；

5.不同结点的同等层通过协议来实现对等层之间的通信。

虽然OSI在法律上已经成为国际标准，然而却由于OSI的协议实现起来过分复杂，且运行效率很低以及OSI的层次划分也并不太合理，有些功能在多个层次中重复出现等诸多原因使得OSI并没有得到市场的认可。TCP/IP是四层的体系结构：应用层、运输层、网际层和网络接口层。然而TCP/IP最下面的网络接口层也并没有具体内容。因此往往采取折中的办法，即综合OSI和TCP/IP的优点，采用一种只有五层协议的体系结构，将TCP/IP的网络接口层又分为数据链路层和物理层。

参考文献：

[1]刘真.软件体系结构――21世纪高等学校规划教材[M].北京:中国电力出版社,2004

软件体系结构范文第2篇

[关键词]软件体系结构软件体系结构风格三层C/S软件体系结构

20世纪60年代中期的软件危机使得人们开始重视软件工程的研究。起初，人们把软件设计的重点放在数据结构和算法的选择上。随着软件系统规模越来越大、越来越复杂，整个系统的结构显得越来越重要。

一、软件体系结构风格分析

最初的软件体系结构是Mainframe结构——客户、数据和程序都被集中在主机上，通常只有少量的GUI界面，对远程数据库的访问比较困难。随着PC的广泛应用，该结构逐渐被淘汰。在20世纪80年代中期出现了Client/Server分布式计算结构，应用程序的处理在客户机和服务器之间分担。随着大型软件系统的开发，这种结构在系统的部署和扩展性方面暴漏出不足。随着Internet的发展，一个更灵活的体系结构“三层/多层计算”体系结构应运而生。

Garlan和Shaw将通用软件体系结构风格总结为以下几类：

1.数据流风格：批处理序列；管道/过滤器。2.调用/返回风格：主程序/子程序；面向对象风格；层次结构。3.独立构件风格：进程通讯；事件系统。4.虚拟机风格：解释器；基于规则的系统。5.仓库风格：数据库系统；超文本系统；黑板系统。

下面将介绍几种主要和经典的体系结构风格和它们的优缺点。

1.C2风格。C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。图1中构件与连接件之间的连接体现了C2风格中构建系统的规则。

C2风格是最常用的一种软件体系结构风格。从C2风格的组织规则和结构图中，我们可以得出，C2风格具有以下特点：

(1)系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起;(2)所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的;(3)构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。

2.数据抽象和面向对象风格。目前软件界已普遍转向使用面向对象系统，抽象数据类型概念对软件系统有着重要作用。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。图2是数据抽象和面向对象风格的示意图。

面向对象的系统有许多的优点：

(1)因为对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他的对象。(2)设计者可将一些数据存取操作的问题分解成一些交互的程序的集合。面向对象的系统也存在着某些问题：①为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。②必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。

3.基于事件的隐式调用风格。基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用。隐式调用系统的主要优点有：(1)为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。(2)为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其他构件的接口。隐式调用系统的主要缺点有：①构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被调用的顺序。②数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。③既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。

4.管道/过滤器风格。在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。因此，这里的构件被称为过滤器，这种风格的连接件就象是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。

图3是管道/过滤器风格的示意图。

管道/过滤器风格的软件体系结构的优点：

(1）使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；(2)支持软件重用。重要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；(3)系统维护和性能增强简单；(4)支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行执行。管道/过滤器风格的主要缺点：①通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。②不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重。③因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

5.批处理风格。批处理风格的每一步处理都是独立的，并且每一步是顺序执行的，只有当前一步处理完后，后一步处理才能开始，数据传送在步与步之间作为一个整体。批处理的典型应用是经典数据处理和程序开发。

批处理风格与管道过滤器风格的共同点是把任务分解成一系列固定顺序的计算单元（组件），组件间只通过数据传递交互。区别表现在以下几个方面：批处理是全部的、高潜伏性的、输入时可随机存取、无合作性、无交互性，管道过、滤器是递增的、数据结果延迟小、输入时处理局部化、有反馈、可交互。

6.仓库风格。在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存贮上执行，仓库与外构件间的相互作用在系统中会有大的变化。

若输入流中某类时间触发进程执行的选择，则仓库是一传统型数据库；另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。

二、三层C/S软件体系结构分析

C/S软件体系结构是20世纪90年代成熟起来的技术，它将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务。

传统的二层C/S结构存在以下几个局限：1.二层C/S结构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet；2.软、硬件的组合及集成能力有限；3.客户机的负荷太重，难以管理大量的客户机，系统的性能容易变坏；4.数据安全性不好。因为二层C/S有这么多缺点，三层C/S结构应运而生。三层C/S结构是将应用功能分成表示层、功能层和数据层三个部分，如下图所示。

表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。表示层一般使用图形用户接口，操作简单、易学易用。功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。功能层的程序多半是用可视化编程工具开发的。数据层就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此，一般从功能层传送到数据层的要求大都使用SQL语言。

对二层C/S结构的局限，三层C/S的解决方案是：对这三层进行明确分割，并在逻辑上使其独立。与传统的二层结构相比，三层C/S结构具有以下优点：

1.允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性。2.允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。3.三层C/S结构中，应用的各层可以并行开发，各层也可以选择各自最适合的开发语言。使之能并行地而且是高效地进行开发，达到较高的性能价格比；对每一层的处理逻辑的开发和维护也会更容易些。4.允许充分利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础；整个系统的管理层次也更加合理和可控制。

软件体系结构风格为大粒度的软件重用提供了可能。然而，对于应用体系结构风格来说，由于视点的不同，系统设计师有很大的选择空间。要为系统选择或设计某一个体系结构风格，必须根据特定项目的具体特点，进行分析比较后再确定。不同的结构有不同的处理能力的强项和弱点，一个系统的体系结构应该根据实际需要进行选择，以解决实际问题。

参考文献：

[1]ShawM,GarlanD,SoftwareArchitecturePerspectivesonanemergingdiscipline,PrenticeHall,1996

[2]冯冲江贺冯静芳编著:软件体系结构理论与实践.人民邮电出版社

软件体系结构范文第3篇

一、软件体系结构风格分析

最初的软件体系结构是Mainframe结构——客户、数据和程序都被集中在主机上，通常只有少量的GUI界面，对远程数据库的访问比较困难。随着PC的广泛应用，该结构逐渐被淘汰。在20世纪80年代中期出现了Client/Server分布式计算结构，应用程序的处理在客户机和服务器之间分担。随着大型软件系统的开发，这种结构在系统的部署和扩展性方面暴漏出不足。随着Internet的发展，一个更灵活的体系结构“三层/多层计算”体系结构应运而生。

Garlan和Shaw将通用软件体系结构风格总结为以下几类：

1.数据流风格：批处理序列；管道/过滤器。2.调用/返回风格：主程序/子程序；面向对象风格；层次结构。3.独立构件风格：进程通讯；事件系统。4.虚拟机风格：解释器；基于规则的系统。5.仓库风格：数据库系统；超文本系统；黑板系统。

下面将介绍几种主要和经典的体系结构风格和它们的优缺点。

1.C2风格。C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。图1中构件与连接件之间的连接体现了C2风格中构建系统的规则。

C2风格是最常用的一种软件体系结构风格。从C2风格的组织规则和结构图中，我们可以得出，C2风格具有以下特点：

(1)系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起;(2)所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的;(3)构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。

2.数据抽象和面向对象风格。目前软件界已普遍转向使用面向对象系统，抽象数据类型概念对软件系统有着重要作用。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。图2是数据抽象和面向对象风格的示意图。

面向对象的系统有许多的优点：

(1)因为对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他的对象。(2)设计者可将一些数据存取操作的问题分解成一些交互的程序的集合。面向对象的系统也存在着某些问题：①为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。②必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。

3.基于事件的隐式调用风格。基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用。隐式调用系统的主要优点有：(1)为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。(2)为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其他构件的接口。隐式调用系统的主要缺点有：①构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被调用的顺序。②数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。③既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。

4.管道/过滤器风格。在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。因此，这里的构件被称为过滤器，这种风格的连接件就象是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。

图3是管道/过滤器风格的示意图。

管道/过滤器风格的软件体系结构的优点：

(1）使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；(2)支持软件重用。重要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；(3)系统维护和性能增强简单；(4)支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行执行。管道/过滤器风格的主要缺点：①通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。②不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重。③因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

5.批处理风格。批处理风格的每一步处理都是独立的，并且每一步是顺序执行的，只有当前一步处理完后，后一步处理才能开始，数据传送在步与步之间作为一个整体。批处理的典型应用是经典数据处理和程序开发。

批处理风格与管道过滤器风格的共同点是把任务分解成一系列固定顺序的计算单元（组件），组件间只通过数据传递交互。区别表现在以下几个方面：批处理是全部的、高潜伏性的、输入时可随机存取、无合作性、无交互性，管道过、滤器是递增的、数据结果延迟小、输入时处理局部化、有反馈、可交互。

6.仓库风格。在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存贮上执行，仓库与外构件间的相互作用在系统中会有大的变化。

若输入流中某类时间触发进程执行的选择，则仓库是一传统型数据库；另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。

二、三层C/S软件体系结构分析

C/S软件体系结构是20世纪90年代成熟起来的技术，它将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务。

传统的二层C/S结构存在以下几个局限：1.二层C/S结构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet；2.软、硬件的组合及集成能力有限；3.客户机的负荷太重，难以管理大量的客户机，系统的性能容易变坏；4.数据安全性不好。因为二层C/S有这么多缺点，三层C/S结构应运而生。三层C/S结构是将应用功能分成表示层、功能层和数据层三个部分，如下图所示。

表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。表示层一般使用图形用户接口，操作简单、易学易用。功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。功能层的程序多半是用可视化编程工具开发的。数据层就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此，一般从功能层传送到数据层的要求大都使用SQL语言。

对二层C/S结构的局限，三层C/S的解决方案是：对这三层进行明确分割，并在逻辑上使其独立。与传统的二层结构相比，三层C/S结构具有以下优点：

软件体系结构范文第4篇

摘 要：针对“软件体系结构”教学存在的实践教学形式过于单一的问题，在分析能力本位课程开发方法的基础上，提出基于能力本位的“软件体系结构”实践教学环节开发方法。该方法结合本三院校实际，在“软件体系结构”实践教学中取得较好效果。

关键词：软件体系结构；能力本位；本三；实践教学

作者简介：朱鹏程，男，讲师，研究方向为软件架构；管致锦，男，教授，研究方向为可逆计算。

软件体系结构(又称软件架构)是植根于软件工程发展起来的一门新兴学科[1-2]。专门和广泛研究软件体系结构始于20世纪90代，目前，软件体系结构已经成为软件工程研究和实践的主要领域，成为众多软件企业关注的核心技术之一。现代社会对大规模复杂软件有极高的需求，但目前国内的软件开发综合能力并不能很好地满足这个需求。一方面是由于软件架构方面的高端人才严重缺失；另一方面是绝大多数程序员缺少架构、设计模式及开发规范等相关知识，编写的代码随意性很强。

作为人才培养的基地，高校应该责无旁贷地承担培养具备架构相关知识软件人才的任务，“软件体系结构”便是以此为目的被各个高校所引入的。清华大学是国内是最先开设该课程的学校，在该课程上积累的成功教学经验以及编写的诸多经典教材为其他高校开设该课程提供了基础和借鉴。目前，越来越多本三层次院校的软件专业也开始开设该课程，因此，本三层次学生如何学好本课程是我们要思考的问题。

1 “软件体系结构”教学面临的问题

通过对某本三学院计算机及软件专业学生的问卷调查，我们发现该课程教学效果不佳，主要原因如下。

原因一，课程内容抽象，软件体系结构是从较高层次把握和理解复杂软件的整体结构，考虑元素和元素之间的关系，整门课程中充斥着各种原理、概念和理念，理论性和抽象性很强，而本三层次学生由于数学基础略显薄弱，抽象思维相对较差，所以，学习该课程有困难。

原因二，由于大多数学生在学习该课程之前无软件开发经验，所以不能充分认识该课程的重要性，认为该课程远远没有程序设计类和工具类的课程有价值。

原因三，实践教学形式单一，实践教学环节不够完整。实践是本三层次学生较喜欢的一种学习方式，但该课程往往只单设几节课内实验课，而对于复杂软件开发经验为零的学生而言，几节实验课肯定不能加深其对软件体系结构的理解。

清华大学覃征教授对前两个原因作了精辟的分析，并提出“动机-专题-案例”的教学主导思想[3]，以此为借鉴并结合院校专业实际情况，我们应该能很好地解决这两个问题。但是，该课程实践环节应该如何设置，尤其是针对本三层次学生如何设置，目前还没有太多可供借鉴的成功案例。

2 以能力为本位，设计课程实践教学环节

能力本位教育[4-7]产生于二次大战后，以美国、加拿大为代表，其核心是从职业岗位的需要出发，确定能力目标。学校聘请行业中一批具有代表性的专家组成专业委员会，按照岗位群的需要，层层分解，确定从事行业所应具备的能力，明确培养目标。然后，再由学校组织相关教学人员，以这些能力为目标，设置课程、组织教学内容，最后考核是否达到这些能力要求。能力本位课程开发流程如图1所示。

图1 能力本位课程开发流程

2.1 课程面向岗位

能力本位课程设计的起点是职业岗位，所以，我们首先必须弄清楚本课程面向哪些岗位。部分人认为“软件体系结构”，顾名思义，面向的肯定就是软件架构师岗位了，这种认识较为片面，因为就本三层次而言，极少有学生一毕业就能走上架构师这样的岗位，绝大多数学生直到其职业生涯晚期依然不能走上这样的岗位，按这样的观点，这门课程在本三就没有开设的必要性了。本三层次的“软件体系结构”课程目的应该是培养具备软件架构知识的软件从业人员，其中包含架构师，但以程序员为主。基于这个起点，我们才有可能设计出本三层次学生能胜任且较喜欢的实践环节。

2.2 岗位能力剖析

人们经常会在杂志或论坛上看到架构师抱怨：设计出的好架构，却得不到彻底的贯彻。除了成本、领导决策等因素以外，软件实现人员的技术水准较低，缺少熟悉架构知识的程序员也是导致这种情况出现的根源之一。通过对本地软件公司的走访并结合网络调研[8]，我们认为，熟悉架构师知识的软件从业人员应该具备以下能力。

1) 良好的沟通能力，能清晰地表达自己心中所想，并能正确理解别人的意图。软件是一个高度复杂的逻辑产品，是在需求基础上由设计人员、开发人员、

测试人员等相关人员分工合作而获得的脑力劳动成果。因此，沟通显得尤为重要，无论是和客户沟通，还是团队内部的沟通，必须能正确理解别人并让别人正确理解自己，否则任何一环的沟通不畅甚至是误解，都会给整个项目带来巨大的风险。

2) 较好的抽象思维能力和建模能力。即能从模糊的用户需求中分离出确定因素和不确定因素，然后选择合适的工具和风格构建总体架构模型以容纳确定因素并拥抱未来可能的变化因素，并能通过图形化的工具清晰描述该结构。

3) 较好的软件实现能力。即精通常用程序设计语言、数据库系统及开发工具，熟悉常用的设计原则和设计模式，能将架构描述的规范很好地付诸实践。

4) 较好的创新能力。软件开发中虽然有很多场景不断重复，但每次出现的细节都有所不同，在设计和开发时，不仅要借鉴已有的成功经验，还要懂得灵活变通，因地制宜。

2.3 教学目标和实践内容的确定

为了培养上述能力，我们结合课程理论教学大纲和学生特点，甄选实践内容如下：软件体系结构风格实践、UML建模实践、软件体系结构描述语言实践、设计原则及设计模式实践、完整软件项目的综合性实践。教学目标和实践内容的安排如表1所示。

表1 教学目标和实践内容安排

2.4 教学实施和管理

教学实施是教学设计付诸实践的过程，合理选择实践形式和实践场地，并对实践过程作实时监控和管理有助于教学效果的提升。实践形式及场地选择等情况如表2所示。

本课程的实践体系由课内实验、校内独立实践周和校外独立实践周组成。其中课内实验主要和课程理论教学相辅相成，让学生对课程涉及的概念、原理、工具等有较清晰地认识，并逐步培养相关能力；校内独立实践周是对整门课程所学知识的一个总结和回顾，通过这个环节培养学生的综合能力，并为校外实习打下基础；校外独立实践周，是在企业氛围下进行的课程实践，能让学生真正做到学以致用。本课程的每个实践环节都由专人进行监督和管理，尤其是在校外实践时，除了校内指导教师以外，还会给学生安排相关的企业导师，企业导师就企业环境、开发团队组织、相关技术对学生进行指导，并对学生完成相关任务的过程作监督和评价。

表2 实践形式及场地选择等情况

另外，在教学实施过程中，我们还应该灵活选择实验案例，使案例具备典型性、时效性，贴近学生，并有一定的趣味性。比如在做设计模式实验时，如果只是让学生按照相关模式的概念去设计类图，并编写典型代码，学生往往不感兴趣，对此，我们可以通过一些有趣味性的引子，逐步将学生引入到模式的世界中去。比如在讲工厂方法模式时，可以将中国古代神话“女娲造人”的故事作为引子，女娲通过八卦炉构建出黄种人、白种人、黑种人，其中各个人种是具体产品，而八卦炉是生产产品的工厂，然后让学生为“女娲造人”这样的场景构建类图并给出实现代码，在这样的情境下学生的参与积极性会比较高，对设计模式的理解也会更深入，甚至有的学生用“终身难忘”这样的词汇来形容这种案例。

2.5 教学评价

对教学效果的评价分为两类：对学生学习效果的考核和教师教学活动的评价。

首先，我们谈一谈对学生的考核，课程考核是教学过程中一个十分重要的环节，是检验教学效果、保证教学质量的重要手段，其目的在于帮助和督促学生系统地复习和巩固所学知识和技能，检验其理解程度和灵活运用的能力，调动学生学习的主动性和积极性，培养学生的创新思维。但以往的考核方式过于单一，只是以实验报告为依据给学生打分，这种方式过于注重最后的结果，而忽略学生在实践过程中的参与程度，因此，部分学生在整个实践过程中碌碌无为，只是在最后草草完成一份实验报告。为了改善这种状况，我们除了将实验报告作为考核依据外，还引入成员互评、教师评价、企业导师意见等方式(如表2所示)。成员互评，是由学生根据组内其他成员在共同完成实践任务时所表现出的作用而给出的评价；教师评价是教师根据学生在实践过程中的出勤率、解决问题的能力等方面给出的评价；企业导师意见是企业导师根据学生融入企业开发的速度、给企业创造的价值等方面给出的评价。通过这几种考核方式有机结合，得到学生实践的总评价。比如企业实践的最终评价构成如下：成员互评20%，实验报告及作品40%，教师评价10%，企业导师意见30%。

其次，对教师教学活动评价的主体为学生。经过两年的“软件体系结构”实践教学改革，对07级和08级学生的问卷调查显示学生在学习兴趣、对课程的理解程度等方面都有了较大进步，课程的平均成绩也有较大提升。调查结果如表3所示。

表3 学生调查结果统计表

3 结语

能力本位课程以职业能力为主线,按照能力单元或能力要素来开发课程,课程目标直指相应岗位，从这个角度看，它有利于学生就业。但是，它打破学科本位的知识体系，不再追求学科体系的逻辑严密性，以相关岗位上的典型工作过程为载体按照能力单元来开发课程，而这点对本三院校来说是有待商榷。本三院校培养的应用性人才和专科院校培养的应用性人才应该有区别，本三院校培养的人才应该更有弹性而不只是局限在少数几个岗位上，正因为这个原因，本门课程将面向岗位定位具备架构知

识的软件从业人员，而不仅仅是某一个具体岗位。另外，将若干典型工作过程(即完整工作任务)贯穿整个课程，看起来好像是学生更贴近真实工作任务，其实，它加剧了学生在开始学习时对各个知识单元的掌握难度，所以在设计该实践教学环节时，前面环节应依然采用小案例让学生逐步掌握各个知识单元，最后才引入完整的工作任务，让学生掌握如何综合运用知识。这样循序渐进的方式更符合认知规律，因此，本文提出的能力本位实践教学环节是在参照传统能力本位课程开发方法上的修改版本，更适合于本三院校。

参考文献：

[1] 张友生,李雄. 软件体系结构原理、方法与实践[M]. 北京:清华大学出版社,2009:1-29.

[2] 董威,齐志昌,陈振邦. 软件设计与体系结构[M]. 北京:高等教育出版社,2009:1-22.

[3] 覃征,邢剑宽. 软件体系结构课程教学:抽象与实践的协调与统一[J]. 中国大学教学,2009(7):14-15.

[4] 樊继轩. 基于能力本位的人才培养模式的构建:对民办高校本科学历教育+职业技能培养人才培养模式的思考[J]. 北京城市学院学报,2010(1):15-20.

[5] 梁熠葆,王晓江,罗怀晓. 基于能力本位实践教学体系的探索与实践[J]. 教育与职业,2010(6):157-158.

[6] 张锡侯. 民办本科高校应实施能力本位的素质教育[J]. 黄河科技大学学报,2009(1):6-7.

[7] 吕玉铬. 应用型本科的能力本位教育与职业化取向探析[J]. 教育与职业,2008(7):178.

[8] 周爱民. 做人、做事,做架构师――架构师能力模型解析[J]. 程序员,2009(4):20-21.

Competency-based Software Architecture Practice Teaching Development

ZHU Pengcheng1, GUAN Zhijin2

(1.College of Xinglin, Nantong University, Nantong 226000, China; 2. Department of Computer Science, Nantong University,

Nantong 226000, China )

软件体系结构范文第5篇

论文关键词：ATM系统,软件体系结构,数据流风格,管道/过滤器

常见的主要软件体系结构设计风格有数据流风格、调用/返回风格、独立组件风格、虚拟机风格、仓库风格等五种[2]。其中，“数据流风格”的软件体系结构是一种最常见，结构最为简单的结构。这样的结构体系下，所有的数据按照流的形式在执行过程中前进，不存在结构的反复和重构，就像玩具工厂中的流水线一样，数据就像玩具零部件一样在流水线的各个节点上流动，最终输出所需要的结果（一个完整的玩具）。在流动过程中，数据经过序列间的数据处理组件进行处理，然后将处理结果向后传送，最后进行输出。

管道/过滤器模式是一种常见的数据流风格。管道/过滤器模型的基本部件都有一套输入输出接口。每个部件从输入接口中读取数据，经过处理，将结果数据置于输出接口中，这样的部件称为“过滤器”。这种模型的连接者将一个过滤器的输出传送到另一个过滤器的输入，这种连接者被称为“管道”。

在这种模型中，过滤器必须是独立的实体，其内部状态不受其它过滤器的影响。模型中有三种不同形式的数据流，分别是单向流水，非顺序流水和回流（见图1）。其中：单向流水表示了一种按加工顺序的正向的流水方式，是最常见的，最直观的数据流方式；非顺序流水交换了其中若干过滤器的顺序，这些过滤器间的处理顺序不重要；回流表示了一种回返方式，某些结果数据可能经由一些管道回流，进行再处理，表示数据处理的重复迭代过程。

图1 管道/过滤器的形式

管道/过滤器模式的体系结构最典型的应用是在编译系统。一个普通的编译系统包括词法分析器，语法分析器，语义分析与中间代码生成器，优化器，目标代码生成器等一系列对源程序进行处理的过程。

下面举一个ATM系统的例子说明管道/过滤器模式的应用与实现。

ATM系统有不同的系统结构，同其他的电子银行系统[3,4,5]一样，根据交换中心在系统中的不同位置，可将ATM系统结构分为以下类型（图2）:

 后方交换型——成员行拥有自己的ATM终端，交换中心位于各成员行主机之后；

 前方交换型——成员行共享ATM终端，交换中心位于各成员行主机和ATM终端之间；

 复合型——既含前方交换型又含后方交换型的系统结构。

ATM系统采用不同类型的系统结构，将导致不同的数据流处理流程。实际上 ATM系统中的数据流处理分为后方交换型与前方交换型这两种方式。在后方交换型的系统中，各成员行拥有自己独立的ATM终端，存在行内交易和跨行交易，不仅需要交换中心来分配交易信息，还需要通过中央银行实行资金清算，数据流处理较为复杂，而前方交换型系统中，因各成员行共享ATM终端，不存在跨行交易的，数据流处理较为简单。

本文主要分析后方交换型的ATM系统，可以应用“数据流风格”的管道/过滤器体系结构建模，将这个系统分为4个过滤器，分别为持卡人信息处理过滤器、行账务处理过滤器、发卡行交易授权和账务处理过滤器、交易数据分配过滤器、以及资金清算过滤器，每个过滤器都拥有一个数据处理中心、一个数据输入接口和一个数据输出接口。

图2 (a)后方交换型系统结构 (b)前方交换型系统结构

在管道/过滤器模式下的整个后方交换型ATM系统的体系结构如图3所示。在这种体系结构中，持卡人数据信息主要包括持卡人的卡号、PIN、交易类型和金额。持卡人信息处理过滤器主要负责接收并确认持卡人数据信息，如确认其卡号和密码的真实性、交易金额的正确性等，并形成请求交易信息，经管道流入行账务处理过滤器。该过滤器主要负责对这些请求交易信息辨别和分类，如：将请求交易信息中的卡号数据分为两大类，一类为本行卡号、另一类为他行卡号，属于本行卡号的相关持卡人交易信息将被截留在行账务处理

图3 后方交换型ATM系统的体系结构

过滤器中实行相应的账务处理，其处理结果经由管道回流至持卡人信息处理过滤器中，由持卡人信息处理过滤器向持卡人输出现金、卡、单据或查询结果；

属于他行卡号的相关持卡人交易信息将经由管道流入交易数据分配过滤器中。该过滤器主要负责将非行卡号的交易信息按照各自的归属行（即发卡行）再次分类，分类后的交易信息将经由管道流入各自对应的发卡行交易授权和账务处理过滤器中。该过滤器主要负责审核流入的交易信息的真实性和有效性，如：是否为仿造卡或过期卡等。审核通过之后，过滤器将依据流入的交易信息产生相应的授权对应行账务处理的信息，这些授权信息将经由管道回流至交易数据分配过滤器。此过滤器负责将这些授权信息按照对应行对号入座，再经由管道让这些授权信息回流至行账务处理过滤器中，此时，行账务处理过滤器将按照授权进行账务处理，处理结果经由管道回流至持卡人信息处理过滤器中，由持卡人信息处理过滤器向持卡人输出现金、卡、单据或查询结果。另外，交易数据分配过滤器在接收到交易授权信息时，还要将这些授权信息同时分配到资金清算过滤器中，由此过滤器完成行和发卡行之间的账务清算和各种交易费用的计费处理，并将清算结果和处理结果经管道回流至交易数据分配过滤器中，分别分配给相应的行和发卡行，完成资金清算。

很显然，上述根据管道/过滤器模式所设计的面向数据流风格的软件体系结构完全体现了ATM系统内部数据流的流动与被加工的过程，结构清晰，功能划分明确，是非常易于理解和实现的。管道/过滤器模式既有优点，也有缺点。其优点在于：

(1)根据数据流处理过程将系统功能分解为若干过滤器行为的写作，将问题化繁为简。

(2)任何两个过滤器，只要它们之间传送的数据遵守共同的规约就可以相连接。

(3)整个系统易于维护和升级，可以很方便用新过滤器替代某旧过滤器。

(4)可以支持若干互相独立的过滤器并发执行。

这种结构模式也存在某些缺点：

(1)交互式处理能力弱：管道/过滤器模型适于数据流的处理和变换，不适合为与用户交互频繁的系统建模。（ATM系统并不是一个与用户交互频繁的系统）

(2)有的系统中过滤器需要有一个数据转换器来对输入输出数据进行解包打包。这样会降低系统性能，增加实现过滤器的复杂性。

总之，数据流风格软件体系最大的特点在于简单独立的结构，这就造就了其简便易用的优势以及不够丰富灵活的弱点。数据流风格是一种很基础的软件体系结构风格。

参考文献

【1】张友生，《软件体系结构》，北京：清华大学出版社，2005年

【2】Mary Shaw，David Garlan，《Software Architecture》，美国：Prentice Hall，2001年

【3】孟祥瑞，《网上支付与电子银行》，上海：华东理工大学出版社，2009年

【4】张卓其,《电子银行》，北京：高等教育出版社，2008年