软件体系整理5-6章
第五章 软件体系结构风格
1.管道过滤器风格
特征：
（1）构件即过滤器（Filter），对输入流进行处理、转换，处理后的结果在输出端流出。而且，这种计算常常是递进的，所以可能在所有的输入接受完之前就开始输出，可以并行地使用过滤器。
（2）连接件位于过滤器之间，起到信息流的导管作用，即管道（Pipe）。
（3）每个构件都有输入/输出集合，构件在输入出读取数据流，在输出处生成数据流。
（4）过滤器必须是独立的实体，它们不了解信息流从哪个过滤器流出，也不需要知道信息将流入哪个过滤器。它们可以指定输入的格式，可以确保输出的结果，但是它们可能不知道管道之后将会是什么样子，过滤器之间也不共享状态。
（记住）管道-过滤器模式的特性之一是过滤器的相对独立性，即过滤器独立完成自身功能，相互之间无须进行状态交互。此外,各过滤器无须知道输人管道和输出管道所连接的过滤器的存在，仅仅需要对输人管道的输人数据流进行限制,并保证输出管道的输出数据流有合适的内容，但它们并不知道连接在其输人、输出管道上的其他过滤器的实现细节。并且,整个管道过滤网络的最终输出和网络中各个过滤器执行操作的顺序无关。
优点：
（1）由于每个构件的行为不受其他构件的影响，因此，整个系统的行为比较易于理解。
（2）支持功能模块的复用。
（3）具有较强的可维护性与可扩展性。
（4）支持特殊的分析
（5）支持并发执行。
2.黑板模式
“黑板”模式类似于这样一个情形，即让专家们坐在真实黑板前并一起工作来解决一个问题。每个专家独立评估解法的当前状态，并可在任何时间到黑板上添加、更改或删除信息。人们往往要决定接下来谁去访问黑板。在黑板模式中，如果可用的组件超过一个，仲裁者（moderator）组件决定程序执行的顺序。
分层系统风格p101 OSI
3. 一个标准的黑板型仓库模式系统通常包括3个组成部分：
（1）知识源：
（2）中央数据单元：
（3）控制单元：
4. 模型-视图-控制器风格 — MVC的实现
5.解释器风格
由1个执行引擎+3个存储器，
一共4个构件组成：
正在被解释的程序、执行引擎、被解释的程序的当前状态、执行引擎的当前状态
优点：（1）有助于应用程序的可移植性与程序设计语言的跨平台能力。
（2）可以对未实现的硬件进行仿真。
缺点：额外的间接层次带来的系统性能的下降。
5.C/S体系结构
a.表示层
- 表示层是应用的用户接口部分，它负担着用户与应用之间的对话功能，用于检查用户从键盘等输入的数据，显示应用输出的数据。
- 在变更用户界面时，只需改写显示控制和数据检查程序，而不影响其他两层。
- 检查的内容也仅限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。
b.功能层
- 功能层相当于应用的本体，用于将具体的业务处理逻辑编入程序。
- 表示层与功能层之间的数据交互要尽可能简洁。
- 在功能层中包含确认用户对应用与数据库存取权限的功能以及记录系统处理日志的功能。
c. 数据层
- 数据层就是数据库管理系统，负责管理对数据库的读写操作。
- 数据库管理系统必须能迅速执行大量数据的更新和检索。
6.B/S风格
 |
|
7.正交体系结构
正交软件体系结构的主要特征：
（1）正交软件体系结构由完成不同功能的n（n>1）个线索（子系统）组成。
（2）系统具有m（m>1）个不同抽象级别的层。
（3）线索之间是相互独立的（正交的）。
（4）系统有一个公共驱动层（一般为最高层，和公共数据结构（一般为最低层）。
8.异构体系结构
异构体系结构的实例 — “内外有别”模型
优点：
（1）外部用户不直接访问数据库服务器，能保证企业数据库的相对安全；
（2）企业内部用户的交互性较强，数据查询和修改的响应速度较快。
缺点：企业外部用户修改和维护数据时速度较慢、较繁琐，数据的动态交互性不强。
异构体系结构的实例 — “查改有别”模型
不管用户通过什么方式（局域网或Internet）连接到系统，凡是需要执行维护和修改数据操作的，就使用C/S体系结构；如果只是执行一般的查询和浏览操作，则使用B/S体系结构。
缺点：外部用户能够直接通过Internet连接到数据库服务器，企业数据容易暴露给外部用户，给数据安全造成了一定威胁。
第六章 面向对象的软件设计方法
1.面向对象的系统
面向对象的分析（OOA，Object Oriented Analysis）
面向对象的设计（OOD，Object Oriented Design）
面向对象的编程实现（OOP，Object Oriented Programming）。
2.OOD模型
OOD主要解决与实现有关的问题，基于OOA模型，针对具体的软、硬件条件（如机器、网络、OS、GUI、DBMS等）产生一个可实现的OOD模型。
3. 调整继承层次
（1）使用多重继承机制时，应该避免出现属性及服务的命名冲突。
一种多重继承模式的例子，这种模式可以称为窄菱形模式。使用这种模式时出现属性及服务命名冲突的可能性比较大。
另一种多重继承模式，称为阔菱形模式。使用这种模式时，属性及服务的名字发生冲突的可能性比较小，但是，它需要用更多的类才能表示同一个设计。
  |
|
窄菱形模型 阔菱形模式
（2）把多重继承简化为单一层次的单继承。
 |
|