I.概要
システムソフトウェアアーキテクチャフレームワーク主含む、より高いレベルの各部分の説明の間にアップ関係のためのインターフェース、部材、部材の特性とコンポーネント間の関係を。
簡単に、効果的にユーザーのニーズを分析するために修飾、システムのソフトウェアアーキテクチャを使用して、ならびにリスクのプログラム構成を低下させることによって。
ますます高いフレームアーキテクチャのシステム設計の増え続けるソフトウェアのサイズと複雑で、ますます重要になります。コアの問題は、ソフトウェアフレームワークの設計で建築プログラムがすでに形成されて再利用することができます。これは、ソフトウェアアーキテクチャスタイルの概念を引き起こします。
第二に、一般的なスタイルの分類
建築スタイルの形成には、調査研究エンジニアリングの実践の多くの年の結果です。良いと多彩な建築スタイルは、多くの場合、満期エンジニアリングと技術のサインです。開発の年後、我々のような、洗練されたソフトウェアアーキテクチャのスタイルの多くをまとめています：
- スタイルデータストリーム：バッチおよびパイプ/フィルタ。
- コール/リターンスタイル：メイン/サブ、階層、およびC / S。
- オブジェクト指向スタイル。
- 独立したコンポーネントのスタイル：プロセス間通信とイベント駆動型。
- 仮想マシンのスタイル：インタプリタとルールベースのシステム。
- データの共有スタイル：データベースシステムと黒板システム。
第三に、建築様式
1.ライン/フィルタの建築様式
慣用パターン：
フィルタとパイプは2つの要素を含みます。この構成では、フィルタ部材が呼び出され、データ処理を担当しています。各フィルタは、入力ポートと出力ポートの組を有し、内部処理の後、からのデータを受信する入力ポートは、出力ポートに伝達されます。接続部材との間の隣接するフィルタ伝達経路との間の接続を介してデータがパイプラインされた入力データストリーム及び出力データストリームと見なすことができます。
回路図：
利点：
- シンプル。
- サポートの再利用。
- システムはスケーラブルであり、進化のことができます。
- システムの同時実行（各フィルタは、効率を向上させる、異なるサブタスクを並列に実行することができる、独立して動作することができます）。
- システム分析の容易さ。
短所：
- システムエンジニアリングは、バッチ処理モードです。
- インタラクティブなアプリケーションを設計するには適していません。
- 共通のデータ伝送規格の不在、解析入力データと合成データの各フィルタが必要です。
- エラー処理は困難です。
コンパイラは、パイプスタイル/フィルタシステムの構成の従来例です。字句解析、構文解析、意味解析、中間コード生成、コード最適化、及び複数のモジュールのコード生成ターゲットのコンパイラは、一つのモジュールの出力は、別のモジュールに入力されます。独立して各モジュールの処理ソースの後、最終的なオブジェクトプログラムが生成されます。図コンパイラフレームワーク：
2.オブジェクト指向の建築様式
慣用パターン：
オブジェクト指向のアーキテクチャでは、モジュラーソフトウェア工学、情報隠蔽、抽象化および再利用の原則を完全に反映されています。このアーキテクチャでは、データ表現と関連付けられたプリミティブオペレーションは抽象データ型内にカプセル化されています。このスタイルでは、対象は、メンバーであるインスタンスの抽象データ型となっています。オブジェクトとオブジェクト間の関数呼び出しとプロシージャ・コールを介して相互作用します。
回路図：
利点：
- 外部のオブジェクトは、あなたの詳細を隠します
- オブジェクトの操作データパッケージ一緒に
- テクニカルサポート撮影を提供するオブジェクトの継承とカプセル化する方法
短所：
- オブジェクトが別のオブジェクトを呼び出したい場合は、そのロゴと名前を知っている必要があります
- これは、波及効果を持っています
3.イベント駆動型アーキテクチャスタイル
慣用パターン：
イベント駆動型、現在のシステムに基づいて、イベントの宣言と実行に基づいて、アプリケーション全体の開発を推進するために、オーバーです。
イベント駆動型アーキテクチャの基本的な考え方は：システムの外部の行動は、事件の取り扱いで実現することができます。このアーキテクチャでは、メンバーは、もはや直接プロセスを呼び出しませんが、イベントが宣言されます。処理システムの他の構成要素は、これらのイベントに登録することができます。イベントがトリガされると、システムは自動的にこのイベントのすべての登録コースを呼び出します。したがって、トリガイベントは、他のメンバーを呼び出す処理が発生します。
回路図：
利点：
- イベント宣言は、メンバーが、物事に反応するかを知る必要がありません。
- ソフトウェアの再利用の能力を向上させます
- 簡単にシステムのアップグレード
短所：
- 計算手段の制御を放棄するために、システムは、完全にすることによって決定されます
- データ伝送の問題があります
4.階層化アーキテクチャスタイル
慣用パターン：
階層的なスタイルでは、システムは、階層に分割されます。
各層は、抽象化、情報隠蔽のサポートの同じレベルを含む種々の成分を凝集度を有します。
複雑な階層システムは、それによって設計および実装の手順を簡略化する、別のモジュールに分割するのに役立ちます。
分解により、システムの機能は、明確に定義された層の数に分割することができる、より高い層は、特定の問題に直面して、下層は一般性を有しています。
每层都为上层提供服务，同时又利用了下层的逻辑功能。在分层体系结构中，每一层只对相邻层可见。层次之间的连接件是协议和过程调用。用以实现各层之间的交互。
原理图：
优点：
- 设计者可以将系统分解为一个增量的步骤序列从而完成复杂的业务逻辑。
- 每一层之多和相邻的上下两层进行交互。
- 只要给相邻层提供相同的接口。
缺点：
- 并非所有系统都能够按照层次来进行划分。
- 很难找到一种合适和正确的层次划分方法。
- 在传输数据是，需要经过多个层次。
- 多层结构难以调试。
5.C2 体系结构风格
惯用模式：
C2结构是一个层次网络，包括构件和连接件两种软件元素。构件和连接键都是包含顶部和底部的软件元素。构件和构件之间只能通过连接件进行连接，而连接件之间则可以直接进行连接。构件的顶部、底部分别与连接件的底部、顶部连接，连接件的顶部、底部也分别与连接件的底部、顶部连接。
在C2体系结构中，构件之间的所有通信必须使用消息传递机制来实现。构件之间所有传递的信息可以分为两种，一种是向上层构件发出服务请求的请求消息，另一种是向下层构件发出指示状态变化的通知消息。连接件负责消息的过滤、路由、广播、通信和相关处理。
原理图：
优点：
- 可以使用任何编程语言来开发构件，构件重用和替换比较容易实现
- 具有一定的扩展能力，可以有多种不同粒度的构件
- 构件不需要共享地址空间，避免了共享全局变量所造成的复杂关系
- 具有良好的适应性
- 在C2体系结构中，可以使用多个工具集和多种媒体类型，能够动态地更新系统的框架结构
缺点：
- 构件和构件之间不允许直接相连
- 与某一个连接件相关联的构件和连接件的数目没有限制
6.数据共享 体系结构风格
定义：
数据共享风格也成为仓库风格。
在这种风格中，有两种不同类型的软件元素：一种是中央数据单元，也成为资源库，用于表示系统的当前状态；另一种是相互依赖的构件组，这些构件可以对中央数据单元实施操作。中央数据单元和构件之间可以进行信息交换，这是数据共享体系结构的技术实现基础。
根据所使用的控制策略不同，数据共享体系结构可以分为两种类型，一种是传统的数据库，另一种是黑板。
如果由输入流中的事件来驱动系统进行信息处理，把执行结构存储到中央数据单元，则这个系统就是数据库应用系统。
如果由中央数据单元的当前状态来驱动系统运行，则这个系统就是黑板应用系统。
黑板是数据共享体系结构的一个特例，用以解决状态冲突并处理可能存在的不确定性知识源。
黑板常用于信号处理，如语音和模式识别，同时在自然语言处理领域中也有广泛的应用，如机器翻译和句法分析。
原理图：
一个典型的黑板系统主要包括知识源、中央控制单元、控制单元。
优点：
- 便于多客户共享大量数据，而不必关心数据是何时产生的、由谁提供的及通过何种途径来提供
- 便于将构件作为知识源添加到系统中来
缺点：
- 对共享数据结构，不同知识源要达成一致
- 需要同步机制和加锁机制来保证数据的完整性和一致性，增大了系统设计的复杂度
7.解释器 体系结构风格
惯用模式：
解释器作为一种体系结构，主要用于构建虚拟机，用以弥合程序语义和计算机硬件之间的间隙。实际上，解释器是利用软件来创建的一种虚拟机，因此，解释器风格又被称为虚拟机风格。
原理图：
优点：
- 能够提高应用程序的抑制能力和变成语言的跨平台移植能力。
- 实际测试工作可能费城复杂，测试代价极其昂贵，具有一定的风险性。
缺点：
- 由于使用了特定了语言和自定义操作规则，因此增加了系统运行的开销。
- 解释器系统难以设计和测试。
8.反馈控制环 体系结构风格
定义：
反馈控制环是一种特定的数据流结构。传统数据流结构是线性的，而控制连续循环过程的体系结构应该是环形的。
反馈控制环系统主要包括以下三个部分：
- 过程，指操纵过程变量的相关机制。
- 数据元素，指连续更新的过程变量，包括输入变量、控制变量、操纵变量和相关参考值。
- 控制器，通过控制规则来修正变量，收集过程的实际状态和目标状态，调节变量以驱动实际状态朝目标状态前进。
原理图：
优点：
- 过程控制是连续的，可以利用各种构件和相关规则来设计反馈控制环系统，实现各种功能。
- 反馈控制环结构能够处理复杂的自适应问题，机器学习就是一个例子。
缺点：
？
9.C/S 体系结构风格
惯用模式：
……
原理图：
优点：
- 客户机构件和服务器构件分别运行在不同的计算机上，有利于分布式数据的组织和处理。
- 构件之间的位置是相互透明的，客户机程序和服务器程序都不必考虑对方的实际存储位置。
- 客户机侧重数据的显示和分析，服务器则注重数据的管理。
- 构件之间是彼此独立和充分隔离的。
- 将大规模的业务逻辑分布到多个通过网络连接的低成本的计算机，降低了系统的整体开销。
缺点：
- 开发成本较高。
- 在开发C/S结构系统时，大部分工作都都集中在客户机程序的设计上，增加了设计的复杂度。
- 信息内容和形式单一。
- 如果对C/S体系结构的系统进行升级，开发人员需要到现场来更新客户机程序，同时需要对运行环境进行重新配置，增加了维护费用。
- 两层C/S结构采用了单一的服务器，同时以局域网为中心，因此难以扩展到Intranet和Internet。
- 数据安全性不高。
10.B/S 体系结构风格
惯用模式：
B/S结构是三层C/S体系结构的一种实现方式，主要包括浏览器，Web服务器和数据库服务器。B/S结构主要利用不断成熟的WWW技术，结合浏览器的多脚本语言，采用通用浏览器来实现原来需要复杂的专用软件才能实现的强大功能，节约了开发成本。
B/S体系结构的核心是Web服务器，可以将应用程序以网页的形式存放在Web服务器上。
当用户运行某个应用程序时，只需要在可以断的浏览器中输入响应的 URL，向 Web 服务器提出 HTTP 请求。
当Web 服务器接收 HTTP 请求之后，会调用相关的应用程序（Servlets），同时向数据库服务器发送数据操作请求。
数据库服务器对数据操作请求进行响应，将结果返回给Web服务器的应用程序。
Web服务器应用程序执行业务处理逻辑，利用 HTML 来封装操作结果，通过浏览器呈现给用户。在B/S结构中，数据请求、王爷生成、数据库访问和应用程序执行全部由Web 服务器来完成。
原理图：
优点：
- 客户端只需要安装浏览器，操作简单。
- 运用HTTP标准协议和统一客户端软件，能够实现跨平台通信。
- 开发成本比较低，只需要维护Web服务器程序和中心数据库。
缺点：
- 个性化程度比较低，所有客户端程序的功能都是一样的。
- 客户端数据处理能力比较差。
- 在B/S结构的系统中，数据提交一般以页面为单位，动态交互性不强，不利于在线事务处理。
- B/S体系结构的可扩展性比较差，系统安全性难以保障。
- B/S结构的应用系统查询中心数据库，其速度要远低于C/S体系结构。
11.公共对象请求代理（CORBA）体系结构风格
惯用模式：
公共对象请求代理（Common Object Request Broker Architecture，CORBA）是由对象管理组织（Object Management Group，OMG）提出来的，是一套完整的对象技术规范，其核心包括标准语言、接口和协议。
在异构分布式环境下，可以利用CORBA来实现应用程序之间的交互操作，同时，CORBA也提供了独立于开发平台的编程语言的对象重用方法。
原理图：
优点：
- 实现了客户端程序与服务器程序的分析。
- 将分布式计算模式与面向对象技术结合起来，提高了软件复用率。
- 提供了软件总线机制，软件总线是指一组定义的完整的接口规范。
- CORBA能够支持不同的编程语言和操作系统，在更大的范围内，开发人员能够相互利用已有的开发成果。
缺点：
？
12.正交 体系结构风格
惯用模式：
正交体系结构是一种以 垂直线索构件族 为基础的层次化结构，包括组织层和线索。
在每一个组织层中，都包含具有相同抽象级别的构件。
线索是子系统的实例，是由完成不同层次功能的构件通过相互调用而形成的，每一条线索完成系统的一部分相对独立的功能。
在正交体系结构中，每条线索的实现与其他线索的实现无关或关联很少。在同一层次中，构件之间不存在相互调用关系。
原理图：
优点：
- 结构清晰。
- 便于修改和维护。
- 易于重用。
缺点：
？
13.MVC 体系结构风格
惯用模式：
模型-视图-控制器（Model-View-Controller，MVC）是一种常见的体系结构风格。MVC被广泛应用与用户交互程序的设计中。
原理图：
优点：
- 多个视图与一个模型相对应
- 具有良好的移植性。
- 系统被分割为三个独立的部分，当功能发生变化时，改变其中的一个部分就能够满足要求。
缺点：
- 增加了系统设计和运行复杂性。
- 视图与控制器连接过于紧密，妨碍两者的独立复用。
- 视图访问模型的效率比较低。
