软件架构设计

一、软件架构的概念

1. 概念：软件架构是位于需求分析和软件设计之间的过程，用于连接业务和开发。
2. 静态结构：最终用户——功能需求（逻辑视图——UML：逻辑视图）；编程人员——软件管理（开发视图——UML：实现视图）。
3. 动态结构：场景（UML：用例视图）；系统集成人员——性能可扩充性、吞吐量等（进程视图——UML：进程视图）；系统工程人员——系统拓扑、安装通信等（物理视图——UML：部署视图）。

二、软件架构风格总概

1. 架构设计的一个核心问题是能否达到架构级的软件复用。
2. 架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整系统。
3. 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
4. 数据流风格：批处理序列、过道—过滤器。
5. 调用/返回风格：主程序/子程序、面向对象、层次结构。
6. 独立构件风格：进程通信、事件驱动系统（隐式调用）。
7. 虚拟机风格：解释器、基于规则的系统。
8. 仓库风格：数据库系统、超文本系统、黑板系统。

三、数据流风格

1. 批处理序列：构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递，整个流程几乎没有用户交互过程。
2. 管道—过滤器：每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常是通过对输入数据流的变换或计算来完成的，包括通过计算和增加信息以丰富数据、通过浓缩和删除以精简数据、通过改变记录方式以转化数据和递增地转化数据等。这里的构件称为过滤器，连接件就是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。

四、调用返回风格

1. 主程序/子程序：单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，即充当连接件的角色。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。
2. 面向对象：显式调用。构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的。
3. 层次结构：构件组织成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层（通常只能影响上层）。

五、独立构件风格

1. 进程通信：独立构件。构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程（方法）调用等。
2. 事件驱动系统：隐式调用。构件不直接调用一个过程，而是触发或广播一个或多个时间。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来的方便；其缺点是构件放弃了对系统计算的控制。

六、虚拟机风格

1. 解释器：解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。
2. 基于规则的系统：基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。

七、仓库风格

1. 数据库系统：数据共享。构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。
2. 黑板系统：包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中（信号处理、问题规划和编译器优化等）。
3. 超文本系统：构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以节点为基本单位，链作为节点之间的联想式关联。超文本系统通常应用在互联网领域。

八、CS架构

1. 两层C/S架构：

   1）构成：表示层和数据层。

   2）缺点：开发成本高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一、软件移植困难、软件维护和升级困难、新技术不能轻易应用。

2. 三层C/S架构：

   1）构成：表示层、功能层、数据层。

   2）各层在逻辑上保持相对独立，整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性。

   3）允许灵活有效地选用相应的平台和硬件系统，具有良好的可升级性和开放性。

   4）各层可以并行开发，各层也可以选择各自最合适的开发语言。

   5）功能层有效地隔离表示层与数据层，为严格的安全管理奠定了坚实的基础；整个系统的管理层次也更加合理和可控制。

   6）通信方法、通信频度、数据量。

九、BS架构

1. B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理能力。
2. B/S架构的安全性难以控制。
3. 采用B/S架构的应用系统，在数据查询等响应速度上，要远远低于C/S架构。
4. B/S架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。
5. 混合架构风格：内外有别模型、查改有别模型。

十、富互联网应用（RIA）

1. RIA结合了C/S架构反应速度快、交互性强的优点，以及B/S架构传播范围广及容易传播的特性。
2. RIA简化并改进了B/S架构的用户交互。
3. 数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器次数更少的用户界面。
4. Java、Ajax等。

十一、基于服务的架构（SOA）

1. 服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。
2. 典型的SOA结构和单个服务内部机构。
3. 服务构件粗粒度，传统构件细粒度居多
4. 服务构件的接口是标准的，主要是WSDL接口，传统构件常以具体API形式出现。
5. 服务构件的实现与语言无关，传统构件绑定某种特定的语言。
6. 服务构件可以通过构件容器提供Qos的服务，传统构件完全由程序代码直接控制。

十二、SOA的实现方式（WebService）

1. 体系结构：服务注册中心（服务描述）、服务请求者、服务提供者（服务，服务描述）。
2. 发现服务：UDDI、DISCO。
3. 描述服务：WSDL、XML Schema。
4. 消息格式层：SOAP、REST。
5. 编码格式层：XML。
6. 传输协议层：HTTP、TCP/IP、SMTP等。

十三、SOA的实现方式（ESB）

1. 提供位置透明性的消息路由和寻址服务。
2. 提供服务注册和命名的管理功能。
3. 支持多种消息传递范型。
4. 支持多种可以广泛使用的传输协议。
5. 支持多种数据格式及其相互转换。
6. 提供日志和监控功能。

十四、软件架构评估——质量属性

1. 性能：性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量的标识。性能测试经常要使用基准测试程序（用以测量性能指标的特定事务集或工作量环境）。队列调度是一种提升系统性能的常用方法。
2. 可靠性：可靠性是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性通常用平均失效时间(Mean Time To Failure，简称MTTF)和平均失效间隔时间(Mean Time Between Failure，简称MTBF)来衡量。在失效率为常数和修复时间很短的情况下，MTTF和MTBF几乎相等。
3. 可用性：可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示，实现可用性策略的主要方法有：错误检测、错误恢复（主动冗余）、错误防御
4. 安全性：安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性是根据系统可能受到的安全威胁的类型来分类的。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
5. 可修改性：可修改性是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。
6. 功能性：功能性是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
7. 可变性：可变性是指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品（例如，软件产品线）的基础时，可变性是很重要的。
8. 互操作性：作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件体系结构。

十五、软件架构评估方法

1. 基于问卷调查（检查表）的方式

2. 基于度量的方式

3. 基于场景的方式：

   1）架构权衡分析法（ATAM）

   2）软件架构分析法（SAAM）

   3）成本效益分析法（CBAM）

4. 敏感点：敏感点是一个或多个构件的特性。·

5. 权衡点：权衡点是影响多个质量属性的特性。

6. 风险点

7. 非风险点

十六、软件架构评估方法（ ATAM）

1. 四个阶段:

   1）描述和介绍阶段：评估小组负责人—评估方法、项目决策者—业务角度、首席设计师—架构。

   2）调查和分析阶段：架构设计师、评估小组、设计小组、管理人员和客户代表

   3）测试阶段：项目相关人员—投票、架构设计师

   4）报告阶段：评估小组负责人—评估方法

十七、软件架构评估方法（SAAM）

1. 六个步骤（局部迭代）：

   1）形成场景

   2）描述架构

   3）对场景分类和确定优先级

   4）对场景进行单个评估

   5）评估场景的相互作用

   6）形成总体评价

十八、软件产品线技术

1. 软件架构
2. 领域工程
3. DSSA
4. 软件产品线
5. 建立方式：演化方式、革命方式

十九、中间件技术

1. 概念：中间件是一种独立的系统软件或服务程序，可以帮助分布式应用软件在不同的技术之间共享资源。

2. 功能：

   1）负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制。

   2）提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。

   3）提供多层架构的应用开发和运行的平台，以及应用开发框架，支持模块化的应用开发。

   4）屏蔽硬件、操作系统、网络和数据库的差异。

   5）提供应用的负载均衡和高可用性、安全机制与管理功能，以及交易管理机制，保证交易的一致性。

   6）提供一组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作。

3. 常用的中间件：

   1）远程过程调用

   2）对象请求代理

   3）远程方法调用

   4）面向消息的中间件

   5）事务处理监控器

二十、J2EE和NET

J2EE-分布式多层应用程序

1. 会话Bean：短暂会话
2. 实体Bean：持久化数据
3. 消息驱动Bean：会话Bean+JMS

NET

差异

1. JVM和CLR
2. 对多层分布式应用的支持
3. 安全性
4. 应用程序的补数
5. 可移植性
6. 外部支持

二十一、MVC模式

1. 主动MVC：model层主动把更新后的数据给view。
2. 被动MVC：model层不会主动返回更新后的数据给view。

二十二、MVP（Presenter）模式

1. MVC模式的变种。
2. MVP实现了V与M之间的解耦（V不直接使用M，修改V不影响M）。
3. MVP更好的支持单元测试（业务逻辑在P中，可以脱离V来测试这些逻辑；可以将一个P用于多个V，而不需要改变P的逻辑）。
4. MVP中V要处理界面事件，业务逻辑在P中，MVC中界面事件由C处理。