如何選擇合適的軟體體系結構

㈠ 如何選擇合適的軟體體系結構設計方法

（1）軟體體系結構的多視圖建模
通過邏輯視圖，開發視圖、進程視圖、物理視圖、進程來描述的軟體體系結構。
（2）基於評估與轉換的軟體體系結構設計
通過迭代的開發方式，直至滿足客戶的需求。
（3）模式驅動的軟體體系結構設計
通過總結、記錄、復用來實現的體系結構設計
（4）領域特定的軟體體系結構設計
借鑒領域中已經成熟的軟體體系結構來實現解決方案在某個領域內的復用。
（5）軟體產品線方法
軟體復用發展的一個更高階段，它並不僅僅局限於以前人們在軟體復用中考慮的對函
數、模塊、類、體系結構甚至子系統的復用。
（6）其於目標推理的軟體體系結構設計方法
功能需求和非功能需求皆被表達為要達到的目標。
（7）其於屬性的軟體體系結構設計方法
基於目標圖推理的體系結構設計方法、基於屬性的體系結構設計方法。
開發心得：
在這些具有系統化過程的軟體開發方法中，體系結構設計師一個不可避免
的過程，它們也都有自己的一些設計方式。但這並不排斥前面講到的軟體體系結構設計
方法，反之，如果能把這些體系結構設計方法與開發方法學結合起來，將能起到更好的
效果。

㈡ 求一篇關於 軟體體系結構分析 的論文

軟體體系結構論文：一種面向方面軟體體系結構模型
摘 要: 為了分離軟體系統中的核心關注點和橫切關注點，通過引入面向方面軟體開發的思想設計了一種面向方面軟體體系結構模型，並詳細分析了該模型的三個基本構成單元，即構件、連接件和方面構件。最後通過一個網上支付實例驗證了該模型具有一定的理論意義和實用價值。
關鍵詞: 面向方面軟體體系結構;橫切關注點;構件;連接件;方面構件
20世紀60年代的軟體危機使得人們開始重視軟體工程的研究。起初，人們把軟體設計的重點放在數據結構和演算法的選擇上，然而隨著軟體系統規模越來越大，對總體的系統結構設計和規格說明變得異常重要。隨著軟體危機程度的加劇，軟體體系結構(software architecture)這一概念應運而生。軟體體系結構著眼於軟體系統的全局組織形式，在較高層次上把握系統各部分之間的內在聯系，將軟體開發的焦點從成百上千的代碼上轉移到粒度較大的體系結構元素及其交互的設計上。與傳統軟體技術相比，軟體體系結構理論的提出不僅有利於解決軟體系統日益增加的規模和復雜度的問題，有利於構件的重用，也有利於軟體生產率的提高。面向方面軟體開發(AOSD)認為系統是由核心關注點(corn concern)和橫切關注點(cross-cutting concern)有機地交織在一起而形成的。核心關注點是軟體要實現的主要功能和目標，橫切關注點是那些與核心關注點之間有橫切作用的關注點，如系統日誌、事務處理和許可權驗證等。AOSD通過分離系統的橫切關注點和核心關注點，使得系統的設計和維護變得容易很多。
Extremara大學的Navasa等人［1］在2002年提出了將面向方面軟體開發技術引入到軟體體系結構的設計中，稱之為面向方面軟體體系結構(aspect oriented software architecture，AO-SA)，這樣能夠結合兩者的優點，但是並沒有給出構建面向方面軟體體系結構的詳細方法。
盡管目前對於面向方面軟體體系結構這個概念尚未形成統一的認識，但是一般認為面向方面軟體體系結構在傳統軟體體系結構基礎上增加了方面構件(aspect component)這一新的構成單元，通過方面構件來封裝系統的橫切關注點。目前國內外對於面向方面軟體體系模型的研究還相對較少，對它的構成單元模型的研究更少，通常只關注方面構件這一構成單元。方面構件最早是由Lieberherr等人［2］提出的，它是在自適應可插拔構件(adaptive plug and play component，APPC)基礎之上通過引入面向方面編程(AOP)思想擴展一個可更改的介面而形成的，但它關於請求介面和服務介面的定義很模糊，未能給出一個清晰的方面構件模型。Pawlak等人［3］提出了一個面向方面的框架，該框架主要包含了一個方面構件模型———Java方面構件(Java aspect component，JAC)，但該方面構件模型僅包含了切點(pointcut)，並把AOP中裝備(advice)集成到了切點的表達式中，它主要從實現的角度進行了闡述，並沒有給出詳細的方面構件模型。本文沒有隻關注面向方面軟體體系結構中方面構件這一構成單元模型，還詳細分析了它的另外兩個構成單元，即構件和連接件，因為面向方面軟體體系結構各部分之間是相互關聯的。
1面向方面軟體體系結構相關概念
面向方面軟體體系結構涉及諸多概念，以下將分別介紹。軟體體系結構在軟體工程領域有著廣泛的影響，但當前仍未形成一個統一的、標準的定義。目前國內外普遍認可的看法是軟體體系結構包含構件、連接件和約束［4］。其中約束描述了體系結構配置和拓撲的要求，確定了體系結構的構件與連接件的連接關系。這樣就可以把軟體體系結構寫成
軟體體系結構(software architecture)=構件(components)+
連接件(connectors)+約束(constraints)
構件是軟體體系結構的基本元素之一。一般認為，構件是指具有一定功能、可明確辨識的軟體單位，並且具備語義完整、語法正確、有可重用價值的特點，然而目前對於構件的具體結構及構成並沒有一個統一的標准［5］，而且一些主要的構件技術也沒有使用相同的構件類型。另外，當前被廣泛接受的構件定義並不包含具體的軟體構件模型(software component model)。例如，Szyperski等人［6］給出了軟體構件一個很有名的定義:軟體構件是一個僅帶特定契約介面和顯式語境依賴的結構單位，它可以獨立部署，易於第三方整合。但是關於軟體構件模型有一個被普遍接受的觀點是:軟體構件是一個具有服務提供和服務請求功能的軟體單元［7］。
連接件是軟體體系結構另一個基本的構成元素，是用來建立構件間交互以及支配這些交互規則的構造模塊。連接件最先是由Shaw［8］提出來的，她建議把連接件作為軟體體系結構中第一類實體，用來表示普通構件之間的交互關系。目前對於連接件尚未形成統一的認識，盡管在軟體體系結構中強調了連接件存在的必要性，但是關於連接件模型的研究還很少，連接件的實際應用還不成熟。
面向方面軟體體系結構在傳統軟體體系結構的基礎上增加了方面構件單元。通常認為，方面構件是封裝了系統橫切關注點的一類特殊的構件。目前關於方面構件模型的研究還處於起步階段。
2面向方面軟體體系結構模型
由於傳統軟體體系結構模型包含構件、連接件和約束，而面向方面軟體體系結構是在傳統軟體體系結構的基礎之上擴展了方面構件，所以面向方面軟體體系模型結構包含構件、連接件、方面構件和約束。其中約束描述了面向方面體系結構配置和拓撲的要求，確定了體系結構的構件、連接件和方面構件之間的連接關系，而構件、連接件、方面構件是它的三個基本的構成單元。以下對這三個構成單元的模型進行詳細的設計。
2.1構件模型
構件模型由以下幾個要素構成(圖1):
(a)埠。
構件的服務請求和服務提供功能是通過埠來實現的。埠是構件與外部環境進行交互的惟一通道。一般的構件模型通常採用兩種埠，即雙向埠和單向埠。在使用雙向埠的構件模型中，服務請求和服務提供功能可以在同一個埠中實現。本文中的構件模型使用單向埠，此種埠分為請求埠和服務埠兩種類型。
(a)服務埠。構件通過服務埠向其他構件提供服務。構件通過服務埠向其他構件的請求消息進行應答，返回響應消息。每個服務埠對應一個介面。
(b)請求埠。構件通過請求埠向其他構件請求服務。構件為了實現自己的業務功能，需要通過請求埠向其他構件發送請求消息。每個服務埠也對應一個介面。
(b)介面。
它定義了一個到多個業務功能。這些業務功能由服務埠進行提供，並由請求埠進行使用。一個介面限定了一個特定埠可以進行的交互功能，介面是構件間交互的契約。通常的介面類型有:Java Interface、WSDL 1．1 portTypes和WSDL 2．0 Interfaces等，也可以自定義介面類型。
(c)屬性。
與類或對象相似，構件也具有屬性，屬性可以在構件使用前進行配置，它能夠反映構件在交互過程中狀態的變化。
2.2連接件模型
連接件是用來建立構件間交互以及支配這些交互規則的體系結構構造模塊。連接件為構件間信息交互提供傳輸和路由服務。在最簡單的情況下，構件之間可以直接完成交互，這時體系結構中的連接件就退化為直接連接。在更為復雜的情況下，構件間交互的處理和維持都需要連接件來實現。對於構件而言，連接件是構件的粘合劑，是構件交互的實現，也可以看做是一種特殊的構件［8］。與構件相似，連接件也具有埠。連接件的埠可分為兩種類型，即源埠(source port)和目標埠(target port)。源埠用於接收構件請求埠中的消息，目標埠用於向構件服務埠中輸入消息。連接件通常需要使用一種合適的綁定(binding)機制，構件的請求埠使用這種綁定機制來描述服務請求的方法，構件的服務埠也使用這種機制來描述構件進行請求的方式。常用的綁定機制有:WebService Binding和JMS Binding等，也可以自定義綁定機制。與構件一樣，連接件也具有屬性，來表示構件間交互的狀態變化，如圖2所示。

2.3復合構件模型
構件可分為兩種，即原子構件和復合構件。前者是不可再分的構件。後者是可再分構件，它封裝了若干個子構件。子構件間通過連接件相互連接，且子構件的埠也可以暴露成為復合構件的埠，子構件也可能是復合構件。如圖3所示:復合構件A包含兩個子構件B和D，子構件B和D通過連接件C進行相連，構件B的服務埠E暴露成為復合構件A的服務埠F，其請求埠G暴露成為A的請求埠H。
2.4方面構件模型
方面構件是面向方面軟體體系結構的一個核心的構成單元，它封裝了橫切關注點，這是與傳統軟體體系結構最大的不同之處。圖4給出了方面構件模型，與普通構件一樣，方面構件也有服務埠和請求埠以及屬性，但是它還有普通構件所沒有的方面埠。當一個構件具有一個方面埠時，即可認為此構件就是方面構件。一個方面埠中包含若干個方面，這與一般面向方面編程(AOP)技術中方面概念有所不同。面向方面編程具有以下四個基本概念:方面(aspect)、連接點(joinpoint)、通知(advice)和切點(pointcut)。連接點是應用程序執行過程一個定義明確的位置，如方法調用是一種典型的連接點。切點是一系列連接點的集合，是方面的作用點。通知表述了在切點所選定的連接點處要執行的動作，常見通知類型有before、around和after等，分表代表在連接點之前、連接點附近和連接點之後執行相應的通知代碼。方面是用來描述和實現橫切關注點的基本單位，由切點和通知構成。方面埠中的方面橫切關注的是構件，這與一般AOP(如AspectJ)橫切關注的對象(object)不同，由於構件能夠表達對象所不能表達的請求服務的能力［9］，這使得方面埠中方面所採用的連接點模型和切點語言具有很大的不同。

2.4.1連接點模型
該連接點模型包含兩種不同類型的連接點，即構件服務埠中的服務提供操作和請求埠的服務請求操作。由於構件的內部結構通常被視為黑盒，因此連接點模型應該僅考慮構件的外部可見元素，如構件請求埠和服務埠中的服務操作。如果連接點模型包含構件的屬性，那麼它將會破壞構件的分裝性。
2.4.2切點語言
用來選用連接點的切點語言基於切點表達式，表1給出了切點的五個組成部分，即component、jp_type、port、interface和service，然後分別對其進行了說明。其中，jp_type代表選用的連接點類型，可以是請求埠中的服務、服務埠中的服務或所有埠中的服務，詳細如表1。表2給出了切點語言的一些例子，其中正則表達式基於java．util．regexp包。

2.5面向方面軟體體系結構模型
面向方面軟體體系結構由構件、連接件、方面構件組成，詳細請參見圖6。

3基於面向方面軟體體系結構模型的網上支付實例
近年來，網上購物發展迅速，網上支付是消費者主要的支付手段之一，圖7給出了基於面向方面軟體體系結構的網上支付模型，它由四個原子構件，即一個復合構件、兩個方面構件和三個連接件組成。其中WebClientComponent代表客戶端構件，它可以向網上銀行構件WebBankComponent請求AccountService()服務，該服務有三個參數，即username、password、cost，分別對應於用戶的網上銀行賬戶名、密碼及購買商品的消費金額。
〈component name="WebClientComponent"〉〈required．port name="WebClientRequest"〉
〈java．interface interface="AccountServiceInterface"〉〈service name="AccountService()"〉
〈param name="username"type="string"/〉
〈param name="password"type="string"/〉
〈param name="cost"type="float"/〉
〈/service〉〈/java．interface〉
〈/required．port〉
〈/component〉
連接件AccountServiceConnector用於連接客戶端構件和網上銀行構件，它採用WebServiceBinding綁定機制。
〈connector name="AccountServiceConnector"binding="WebServi-ceBinding"/〉
〈source name="S"/〉〈target name="T"〉
〈/connector〉
〈connect．source from="WebClientComponent．WebClientRequest"to="S"/〉
〈connect．target from="T"to="WebBankComponent．Bank-Re-sponse"/〉
網上銀行構件是一個復合構件，由賬戶服務構件Account-ServiceComponent、賬戶資料庫連接件AccountDBConnector和賬戶資料庫構件AccountDBComponent組裝而成。其中該復合構件的服務埠也使用介面AccountServiceInterface，這是為了兼容客戶端構件請求埠使用的介面。
身份驗證構件AuthenticationComponent用於驗證用戶的身份信息，它通過UserInfoConnector連接件訪問用戶信息資料庫構件UserInfoDBComponent。
pointcut="WebBankComponent;BankResponse;AccountServiceInterface;AccountService()"
是該方面構件的方面埠中使用切點的表達式。
為了保證資料庫構件UserInfoDBComponent和AccountDB-Component的安全性，方面構件SecurityComponent使用方面埠Security監視這兩個構件的服務埠，使得在這兩個構件服務調用之前增加日誌和事務功能，而日誌和事務功能在系統中通常表現為橫切關注點，面向方面軟體體系結構能夠對它進行很好的封裝，便於設計和維護。
〈aspect．component name="SecurityComponent"〉〈aspect．port name="Security"〉〈aspect〉〈pointcut="UserInfoDBComponent;UserInfoResponse;*;*|Ac-countDBComponent;AccountDBResponse;*;*"/〉〈advice．role="before"action="Log()"/〉〈advice．role="before"action="Transaction()"/〉〈/aspect〉〈/aspect．port〉〈required．port name="UserInfoRequest"/〉〈/aspect．component〉
4結束語
本文給出了一種面向方面軟體體系結構模型，詳細設計了它的三個基本構成單元模型，即構件、連接件和方面構件;最後通過一個網上支付實例驗證了該模型有效性和實用性，為面向方面軟體體系結構的實際應用奠定了一定的基礎。筆者將繼續完善該模型的相關理論，研究面向方面軟體體系結構的工程化應用方法。
參考文獻:
［1］FABRESSE L，DONY C，HUCHARD M．Foundations of a simpleand unified component-oriented language［J］．Journal of ComputerLanguages，Systems＆Structures，2008，34(2-3):130-149．
［2］LIEBERHERR K，LORENZ D，MEZINI M．Programming with as-pectual components，T R NU-CSS-99-01［R］．［S．l．］:NoutheastamUniversity，1999．
［3］PAWLAK R，SERNTURIER L，DUCHIEN L D，et al．JAC:an as-pect-based distributed dynamic framework［J］．Software Practiceand Experiences，2004，34(12):1119-1148．
［4］李千目．軟體體系結構設計［M］．北京:清華大學出版社，2008．
［5］馬亮，孫春艷．軟體構件概念的變遷［J］．計算機科學，2002，29(4):28-30．
［6］SZYPERSKI C，GRUNTZ D，MURER S．Component software:be-yond object-oriented programming［M］．2nd ed．［S．l．］:Addison-Wesley，2002．
［7］LAU K K，WANG Z．Software component models［J］．IEEE TransSoft Eng，2007，33(10):709-724．
［8］SHAW M．Procere calls are the assembly language of software in-terconnection:connectors deserve first-class status［C］//Proc of InICSE Workshop on Studies of Software Design．1993:17-32．
［9］NAVASA A，PREZ M A，MURILLO J M，et al．Aspect orientedsoftware architecture:a structural perspective［C］//Proc of Workshopon Early Aspects．2002．

㈢ 軟體體系結構的評估方法有哪些

評估方法
成功的體系結構遵循各種指導原則和最佳實踐。SEI 在這方面做了廣泛的研究，並最終創建了幾種用於改進和評估體系結構的方法。四種代表性的方法如下：
質量屬性專題研討會 (QAW)
體系結構權衡分析方法 (ATAM)
軟體體系結構分析方法 (SAAM)
積極的中間設計審核 (ARID)
QAW 在定義體系結構之前執行，ARID 在設計工作過程中執行，而 ATAM 和 SAAM 則在已經完成體系結構之後執行。這些方法的引出部分的執行由一個協調人員引導。

㈣ 體系結構與開發平台選擇

原型系統架構分硬體架構、軟體架構和部署方式3個方面。硬體部分描述了系統在部署的時候會涉及的伺服器角色、不同角色之間的關聯關系和網路連接方式；軟體架構描述了系統各軟體組件之間的層次關系；部署方式說明系統在不同用戶環境下的配置形式。

5.2.5.1 硬體體系結構

按照原型系統的功能要求，根據數據處理流程，從多種數據源輸入開始，到數據存儲和處理，再到面向最終用戶的不同形式展現，分來源/控制、存儲/處理，以及運算/發布3個層次來設計系統硬體體系結構。硬體體系結構的設計需要根據系統對多數據源、多種數據處理方式、多種展現方式和多用戶等功能要求，將不同的功能模塊獨立部署於不同的硬體平台，以滿足系統的多種功能要求，支持負載均衡控制，提高系統的可擴展性（左美雲等，2006）。系統的硬體體系結構見圖5.24。

圖5.24 系統硬體體系結構

（1）第一層次：來源/控制

系統的數據來源有Internet自動抓取、人工輸入、模型運算輸入等。數據下載伺服器（Data Download Server）負責從Internet自動抓取數據，其中抓取的數據類型包括不同網站來源的石油價格數據以及影響石油價格的事件等；模型運算伺服器（Model Server）負責模型的運算執行，並生成模型運算的結果數據。數據下載和模型運算的數據將存儲到中心資料庫伺服器（Center Database Server）中，由中心資料庫來完成數據歸一、合並、錯誤數據檢測等任務。

（2）第二層次：存儲/處理

第二層次包含的中心資料庫是整個系統的核心。通過設置中心數據伺服器，完成存儲在中心資料庫中的數據增加、修正、計算、展現等任務。中心資料庫除了由第一層次的數據下載伺服器和模型運算伺服器獲取數據之外，還需要提供數據的人工輸入，並為模型運算伺服器提供中間數據介面任務。

除此之外，考慮到數據量規模，中心資料庫伺服器可以兼備數據倉庫伺服器（Data Warehouse Server）的角色。中心資料庫伺服器對數據倉庫數據的生成、轉換進行控制，提供具有星型架構的多維數據源。

（3）第三層次：發布/展現

第三層次負責完成對中心資料庫中的數據進行提取，按照不同的應用進行展現。第三層次包括GIS展現伺服器（GIS Server）、數據發布伺服器（Data Deployment Server）等，這些伺服器由獨立的W eb伺服器（Web Server）向網路用戶提供單一的用戶訪問介面。GIS展現伺服器負責對系統的GIS展現部分提供支持，包括國家風險、運輸風險等。數據發布伺服器則包含了所有二次開發的系統數據處理內容，包括各個風險模塊中的指標體系定義和評價、基本數據的維護和展現等。此外，第三層次還提供對系統中心資料庫的多維數據的展現功能，提供數據的切片、旋轉、上鑽、下卷等多維操作，並可以對結果數據進行導出。

GIS展現伺服器從中心資料庫伺服器處獲得的數據包括展現對象的基本信息、風險值等；數據發布伺服器從中心資料庫伺服器處獲得的數據包括石油價格、匯率、影響油價的事件等，另外數據發布伺服器還從數據倉庫伺服器（中心資料庫伺服器）讀取多維數據源。

5.2.5.2 軟體體系結構

在軟體體系結構設計方面，通過對系統關於國家風險、運輸風險、市場風險、需求風險和供應風險的功能需求進行分析，抽象出共性的功能，依照三層設計的原則進行系統軟體體系結構的設計，如圖5.25所示，包括數據層、中間層和用戶層。

圖5.25 系統軟體體系結構

在系統的軟體體系結構中，系統運行管理模塊具有貫穿全局的作用，負責對系統各個層次功能的運行參數進行配置，控制系統的許可權等（左美雲等，2006）。此外，系統的主體可以劃分為數據層、中間層和用戶層3個相互作用的軟體層次結構。

（1）數據層

系統的數據層以中心資料庫為核心。圖5.26展示了處於數據層中的中心資料庫裡面的相關數據信息類別。可見，中心資料庫是整個系統的基礎，提供了所有數據的存儲空間。在中心資料庫層和程序代碼之間設置了數據訪問中間層，用來抽象程序對資料庫的訪問，提供統一的數據訪問介面，提高程序代碼對資料庫平台的獨立性。

圖5.26 中心資料庫內容

（2）中間層

系統的中間層包括數據抓起模塊、圖庫管理模塊、指標管理模塊、模型運算模塊和基礎信息維護模塊。

數據抓取模塊負責對Internet數據進行抓取和更新。數據抓取模塊自動連接不同的數據源網站，將網站上的數據經過下載、轉換和過濾等處理，更新到中心資料庫中，其中還要求留有處理各個階段的詳細日誌。在數據抓取到本地的中心資料庫之後，多個數據源的數據需要合並到一起，向數據使用者提供單一的數據出口。

圖庫管理模塊為系統中國家、港口等模塊中涉及的圖片進行集中管理，完成圖片的更新控制等。

指標管理模塊將多個功能中所包含的指標歸類形成一個共享模塊。指標管理模塊主要包括評價對象定義、評價指標維護、評價方法審核、評價值錄入、評價指標存儲、評價指標體系展現等功能。指標管理模塊按照樹形方式提供評價指標的定義功能，並可以提供按照時間版本進行管理的歷史評價指標，同時為展現模塊提供指標的查詢和顯示介面。

模型運算模塊主要處理系統要求的數據計算模型，模型數據來源和數據輸出需要經過數據訪問中間層連接到中心資料庫。在這個過程中，模型運算模塊調用數據處理模塊獲得數據輸入，並將模型運算結果依據模型本身的要求輸入到中心資料庫中。如油價預測模型以及石油市場風險預測模型就是模型運算模塊中非常重要的組成部分。油價預測模型讀取數據抓取模塊獲得的原始油價數據，在客戶端進行計算預測，並顯示預測結果；石油市場風險預測模型讀取進行結構轉換後的中間油價數據，接受用戶輸入的參數，計算並輸出結果和報告。模型運算模塊需要定義統一的模型結構，為多單位聯合開發提供一致的介面，便於集成。

基礎信息維護模塊主要負責完成系統內實體對象相關屬性信息的修改維護功能，主要包括國家、港口和航線等對象。

（3）用戶層

用戶層負責用戶和系統介面的交互，包括GIS、價格數據、數據倉庫、指標等多種展現形式完成交互。GIS展現和指標展現是最終用戶界面的主要顯示內容，主要功能包括多個風險的GIS展現、風險對象詳細信息的查詢顯示和風險評價指標的顯示等以及模型運輸結果的展示等；價格展現模塊則主要提供石油價格數據和影響油價事件的查詢顯示和導出；數據倉庫展現模塊從數據倉庫讀入數據，按照用戶的要求進行國際石油價格的多維展現，包括價格按照市場、油品、價格類型和時間等多個維度的分析。

5.2.5.3 系統部署方式

在海外油氣資源利用的風險管理系統中，系統的用戶分為普通用戶和管理員用戶，這些用戶的分布位置分散，特別是最終用戶，包括了不同單位、不同地理位置，以及不同的訪問終端等。為了最大程度地提高系統的靈活性和兼容性，在部署上主要採取了B/S（瀏覽器/伺服器）的結構形式，以降低系統對客戶端的要求，提高系統的可維護性。考慮到部分功能模塊的特殊需求，採用了C/S（客戶機/伺服器）結構，這些主要是數據抓取和部分需要獨立運行的模型程序。

5.2.5.4 開發平台選擇

開發平台採取具有較高開發效率的.net平台為主體。Microsoft.net是一種全新的運算平台，其核心內容之一就是要搭建第三代互聯網平台，以最大限度保護用戶的現有投資和適應未來發展的需要。Microsoft為促進.net應用程序的開發而推出的Visual Studio.net集成開發環境中包含了許多強大的工具，並且支持多種編程語言，如 C＃,Visual Basic.net,ASP.net等，這些編程語言可以實現代碼級的無縫鏈接。

整個開發平台的選型如下：

1）伺服器操作系統：Microsoft Windows Server 2003;

2）資料庫管理系統：Microsoft SQL Server 2008;

3）內容管理系統：Microsoft Sharepoint Service 3.0,Microsoft Office Sharepoint Design 2007;

4）工作站操作系統：IE/FireFox/Opera等主流瀏覽器，Windows/Linux平台；

5）應用系統開發環境：Microsoft Visual Studio 2008;

6）應用系統開發語言：C＃,ASP.NET,VB.net，框架為.net Framework 2.0;

7）GIS開發軟體：MapInfo MapXtreme 2008;

8）數據倉庫軟體：QlikTech QlikView 9.0。

㈤ 什麼是軟體架構

當你去了解一個東東的時候，第一步要做的，就應該去知道這個東東的定義，對於軟體架構也是如此，經過網上查詢和書籍的幫助，我大概理清了一個輪廓。
軟體行業是一個熱衷於製造‘名詞’的行業，如果退回15年，估計沒幾個人知道‘軟體架構’是什麼，在上個世紀80年代，隨著軟體開發的規模不斷擴大，軟體開發成為一個行業，初期，隨之而來的是越來越多的軟體項目的失敗，造成項目失敗的原因很多，但主要集中在開發過程，所以軟體工程應運而生，CMMI等流程標准也是一茬接著一茬的冒個不停。
在軟體工程初具規模的時候，軟體開發還是以數據結構+演算法的形式存在，進入20世紀最後10年，隨著面向對象技術、設計模式等在開發過程中的成功應用，軟體架構也走進了大家的視野。
軟體架構在定義上分為‘組成派’和‘決策派’兩大陣營，分別描述如下：
’組成派‘認為軟體架構是將系統描述成計算組件及組件之間的交互
。它有兩個非常明顯的特點：
關注架構實踐的客體——軟體，以軟體本身作為描述對象。
分析了軟體的組成，說明軟體不是一個‘原子’意義上的整體，而是有不同的部分經過特定的介面進行連接組成的一個整體，這對軟體開發來說很重要。
‘決策派’認為
軟體架構包含了一系列的決策
，主要包括：
軟體系統的組織
選擇組成系統的結構元素和它們之間的介面，以及當這些元素相互協作時所體現的行為
用於指導這個系統組織的架構風格：這些元素以及它們的介面、協作和組合
軟體架構並不僅僅關注軟體本身的結構和行為，還注重其他特性：使用、功能性、性能、彈性、重用、可理解、經濟以及技術的限制和權衡等。
‘決策派’有以下兩個顯著的特點：
關注軟體架構中的實體——人，以人的決策為描述對象。
歸納了軟體架構決策的類型，指出架構決策不僅包括關於軟體系統的組織、元素、子系統和架構風格等幾類決策，還包括關於眾多非功能性需求的決策。
按照‘組成派’的觀點，軟體架構關注的是軟體整體的分割和交互，之所以分割，是因為不同的部分在邏輯或物理上相對獨立，通過‘分而治之’的原則進行分割可以更好的理解整個系統，把握用戶的需求，但是雖然整個軟體可以分割成多個模塊或子系統，但是模塊和子系統之間的通信和交互也是很重要的，我想按照這種觀點，架構師的主要任務是將軟體分割成不同的模塊，並定義模塊之間的介面。
按照‘決策派’的觀點，軟體是一個在很多限制下產生的產品，這些限制包括用戶和技術兩方面，用戶方麵包括功能需求、性能需求、硬體需求等，技術方麵包括技術選擇、可擴展性、可重用性、可維護性等。我想按照這中觀點，架構師的主要任務就是作出上述個各種限製作出選擇或決策。《軟體架構設計》 溫昱

㈥ 網際網路應用軟體架構主要有哪兩種組織架構模型

網路體系結構是固定的。
指通信系統的整體設計，它為網路硬體、軟體、協議、存取控制和拓撲提供標准。
它廣泛採用的是國際標准化組織，並為應用程序提供了特定的服務集合，分層思想比如應用層，傳輸層等。應用程序體系結構由應用程序研發者設計，規定了如何在各種端系統上組織該應用程序。在選擇應用程序體系結構時，有兩種主流體系結構，serverclient結構或p2p體系結構。

㈦ 流程管理軟體的流程管理軟體系統的體系結構

以Internet為代表的信息技術的快速發展和應用改變著企業的商業環境，使商業運行節奏越來越快，企業的價值鏈更加緊密和多樣性.企業的布局和資源的配里不以地域、國家和行業為主要考f，而是根據企業價值鏈，通過優化資源配里、降低企業的組織成本和交易成本，提升企業的市場競爭力，進而使企業的價值最大化。這種以價值鏈為核心的企業變革主要表現為企業的重組(包括組織結構、業務流程和業務操作方式的重組)，CSCIndex顧問公司抽查621家北美和歐洲最具實力的企業調查結果表明，在497家北美公司中有69%、在124家歐洲企業中有75緯都推行一項或多項不同的企業重組工程;其中業務流程重組最為突出，因為企業流程的重組可獲得的「戲劇性」成就— 將生產周期縮短70%，成本降低40腸，顧客滿意度、產品質I$和總收入均提高40%。比如，柯達公司對新產品開發實施業務流程重組，把35毫米焦距一次性照相機從產品概念到產品生產所需要的開發時間一下子縮減了50%.從原來的38周降低到19周。
企業的重組工程的趨勢是朝電子商務的運營模式轉變，這種變化深刻影響著企業的組織結構和企業內部的作業流程。因此，必須解決企業應用中的「信息孤島」現象，把針對相對具體和復雜業務的各項獨立系統集成起來是企業信息系統支律企業重組工程面臨的問題.在構造一個信息系統時每一個項目干係人(Stakeholder)都要考慮如何提高系統柔性，以支持企業重組和業務流程再造?如何集成異構系統，對原有系統資源的利用和保護?
在實際開發中。許多系統需要返工往往並不是因為系統功能沒有完成，而是因為質量性能得不到滿足，而這些質量屬性又總是交織在一起的，在系統設計時沒有方法使其中的一性能最大而不犧牲其他質性能，這就要求在著手設計系統時首先要考慮好如何滿足系統的業務性能(如投放市場時間、成本、系統的生命周期和目標市場等)和質量性能，如何滿足質蚤性能的動態屬性(運行時可以測量的屬性，如安全性、可用性、功能性和使用性等)和靜態(運行時不能測量的屬性，如可修改性、移植性、重用性、集成性和可測試性等)屬性，並根據需求在這些性能之間權衡，這種權衡可通過分析系統軟體體系結構來實現一個系統的軟體體系結構是系統分析時優先考慮的諸多因素中最早著手的物件(Artifact)，它反映了系統應該包涵的全部屬性，是對系統需要實現的諸多屬性的平衡，比如系統運行效率與安全性、維護性與可靠性、目前開發成本與今後擴展成本之間的平衡，系統對這些質量屬性的實現就是通過系統的結構平衡實現的，並且可能是設計者一開始不能用文字表述的。
流程管理的挑戰
業務主管希望企業的流程能夠與不斷變化的業務環境保持同步，而IT主管希望對不斷變化的業務需求迅速做出響應，以較低的成本進行改變
經營管理者希望對企業流程的執行進行通盤的監控和績效分析，更好的協調業務，做出更迅速、有效的決策
業務系統越來越多也越來越復雜，完成一筆業務需要人工訪問多個系統 企業應用系統中軟體成分越來越復雜，系統規模不斷擴大，使得軟體體系結構越來越龐雜，系統的質量和性能己經不再僅僅取決於實現演算法和數據結構，軟體系統體系結構在一定程度上決定系統的優劣。軟體體系結構提供了一種使軟體開發活動可被管理、形式化、可組織的一種工具，通過它可以把軟體開發過程中的一些物件轉化成新的軟體體系結構下的物件，例如，我們可以通過軟體體系結構把軟體的需求規格說明轉化成系統設計、把設計轉化成實現。
軟體體系結構是指計算機軟體(程序)系統的一個或多個系統結構，它們由組成系統的構件、構件的外在表現屬性和構件之間的關系構成軟體系統的體系結構有好壞之分，一個好的體系結構能夠使軟體系統滿足特性要求、性能要求和生命周期的需求，而不好的體系結構則不能。因此，在系統開發工作啟動時我們要通過實驗、驗證等評估方法，選擇一個最好的體系結構來構造系統。
軟體體系結構很多，文中將軟體體系結構分為五類:以數據為中心的體系結構、數據流體系結構、虛擬機體系結構、調用和返回體系結構和獨立構件體系結構，每一類體系結構都為我們提供了一種分析系統需求的基點和設計系統的方法，並且都是行之有效的、實用的.但都是立足於技術角度，從產品域分析體系結構所定義的構件，構件間相互作用的信息和構件的外在表現屬性即該構件被其他構件操作時它所能提供的服務、性能統計、錯誤處理、共享數據的應用等等。系統的質t屬性孺求源於系統的業務需求，如果我們從業務域出發考慮系統的體系結構，通過抽象企業應用需求中的業務建模，用業務功能構件實現業務處理中的具體工作來描述業務邏輯在軟體體系結構中的靜態屬性，用參與者匹配和過程定義來建立業務流程、業務活動和組織機構間的關系，並用工作流虛擬機作為支撐，解釋運行反映業務流程的過程模型實例，實現軟體體系結構中的動態屬性。通過對業務邏輯和系統實現的分離，系統軟體體系結構中的靜態屬性和動態屬性的邏輯，用業務邏輯的表現實體來描述企業應用系統的體系結構，企業應用中的業務邏輯描述實體可分為:業務流程、業務活動和參與者。通過對它們之間的信息文換機制獨立封裝，可降低業務邏輯、業務數據和業務操作實體三者間的藕合，實現在業務域中的業務流程的柔性管理(即業務過程管理)和不同業務活動的應用功能在業務流程的集成。
業務流程指在企業或機構中，能夠實現業務目標和策略的相互連接的過程和活動集。業務流程可以用工作流來描述，將其表示成為能夠完全或部分由計算機自動執行的業務過程，在此過程中，文檔、信息或任務按照預定的規則傳遞，企業人員、已有軟體互相之間協調工作，以實現企業業務的整體目標，通過流程建模定義業務處理過程中涉及到的各種數據，包括開始和中止條件、各個工作環節及相互之間的控制流和數據流關系等。
業務活動是業務流程最小工作單元，表示了業務的具體功能，對應工作流中一個邏輯步驟或環節的工作任務，一般分為手工操作和自動處理兩類。通過對業務活動建模，可以分離活動的內容和活動的控制關系，這樣活動的內容可以是一個用戶界面，也可以是一個構件(如COST構件，編譯後的執行程序，或一個子業務流程)。當業務內容改變時，只豁替換具體的功能構件，無需改變業務流程的過程定義;業務流程變化時只需改變活動的控制關系，而業務內容及其相關的資料庫則不需改變。
組織機構 是對參與者的建模機制，它有三種荃本元素:組織單位、角色和參與者，這些荃本元素供過程建模使用，並通過建模機制保證已定義的過程中使用的角色和組織機構中定義元素的一致性。對組織建模帶來兩個好處:①分離業務的過程定義和業務的實際執行參與者，提供了過程模型和企業人員組織模型之間的相對獨立性;②提供了一種平衡工作t的手段。當有多個執行者滿足參與者孺要時，可在不改動流程定義的前提下，通過角色匹配在這些參與者之間平衡工作，提高工作效率，降低流程一次執行的周轉時間。 SynchroFLOW就是採用面向業務域的系統體系結構的業務過程管理與集成系統，通過對業務流程建模、對組織機構分離，最大限度地滿足系統的各項質量屬性。
1 工作流虛擬機
工作流虛擬機是解釋執行業務流程的工作流管理系統，是工作流過程實例創建、執行和監督管理的一個運行環境.它對外提供過程、活動、工作流的查詢、控制、管理功能、日誌管理功能、系統管理功能.對內它提供工作流解釋執行的語義和語法規則，在SynchroFLOW 中提供基於信牌驅動模型的工作流語義和語法規則，它是遵循WfMC標准基於Petri一網理論提出的一種工作流模型，通過劃分同步區與非同步區，以及在同步區使用真假信牌規則。在非同步區使用真信牌規則，具有豐富的語義和直觀的描述能力，能夠描述各種業務流程的控制邏輯。
2 業務流程建模
業務過程建模就是按照信牌驅動模型制定工作流解釋執行語義和語法規則對業務流程的嚴格描述。只要完整地定義了業務流程的過程和一些相關的描述信息，工作流虛擬機按照這種流程定義自動或半自動地執行，而無需用戶再另外開發軟體。
SynchroFLOW的業務過程建模分為過程建模定義、過程建模管理和過程定義結果的標准格式等，過程建模完成業務流程的棋型定義，包括流程信息和相關數據;過程建模管理負責過程定義的管理職能，包括過程定義結果保存、獲取和過程定義資料庫的管理等。過程定義結果的格式將遵循XMLWPDL過程定義交換標准。
3 業務活動建模
一個工作流模型可以包含若干個過程;一個過程可以包含若干個基本元素;它們可分為兩類:活動元素和轉移元素.活動分為開始活動、手工活動、自動活動、內里活動、子活動、路由活動、活動組、意外活動和結束活動等九種特殊情況。業務活動建模，一方面把活動的內容(具體功能)設計成為一個個構件(如COST構件，編譯後的執行程序，或一個子業務流程或一個用戶界面)，由它們完成人機交互、數據處理和與資料庫的連接等功能，並把它們按一定的方式存儲起來，供業務過程定義時調用.另一方面，根據活動的類型和控制流信息，在業務過程定義時，定義參與者匹配方式，以便在活動執行時確定活動的執行者。
4 組織結構建模
業務流程定義中除了定義一系列活動以及活動之間的關系外，還要考慮手工執行的活動由誰來做和如何決定誰來做。在工作流系統中，一個活動的參與者(執行者)可能有三種情況:人員、單位和角色.這三種信息存放在一個企業的組織模型資料庫中，供過程定義使用。
人員:指明某一活動的具體執行者，由該人員互動式地完成該活動的任務。
單位:一個活動的執行者並不指定給一個人，而是一個組織單位，它表明該單位中的任何一個人員都有能力和貴任執行該活動，當系統執行時再根據當時的情況動態地選擇該單位中的一個合適的人員完成該活動。
角色:是對不同人員在業務流程中所承擔責任的一種劃分，不同的貴任可由不同的角色完成。
參與者就是活動的執行者，描述了一個活動可以由誰來執行，它是一個人、組織單位和角色的集合運算表達式，參與者是與過程相關的，而人、組織單位和角色是獨立於過程定義的。參與者與活動之間的關系是執行與被執行的關系，參與者與人、組織單位和角色之間是扮演與被扮演的關系.只有滿足參與者表達式的人、組織單位和角色才有權執行活動(只要在流程實例執行前，將參與者分配給某個活動就行了，即參與者匹配或參與者轉換)。因此，參與者和執行者之間存在著多對多的關系，一個參與者可由一個或幾個執行者來扮演，而一個執行者可以扮演多個參與者，這種多對多的關系給參與者匹配的實現帶來一定的難度。但同時帶來了靈活、簡便、易於控制的好處。
利用SynchroFLOW實現業務流程管理
由於SynchroFLOW過程建模採用標準的XML-WPDL形式的過程定義，作為過程建模與工作流虛擬機之間交換過程定義的方式，從而使表現企業業務流程的過程定義程序與工作流虛擬機之間建立起了一種鬆散的韌合關系.當企業業務流程重組時，業務流程變化，只需要改變業務過程定義，用新的過程定義文件替換舊的即可，系統的功能構件、參與者以及資料庫屬性都不用修改。
在採用SynchroFLOW開發企業應用時，業務流程、活動或參與者發生變化時，可以利用SynchroFLOW提供的工具對系統的局部快速修改而不影響系統的體系結構整體，保證了系統質量屬性.同時由於工作流虛擬機和反映業務流程的過程定義文件分離，還可以動態修改業務流程，即對流程定義模型的實例進行修改，當一個實例化的流程在運行過程中需要修改時，由工作流虛擬機掛起濡要修改的流程實例，利用SynchroFLOW提供的工具對流程、活動或參與者進行快速修改，並得到新的業務流程模型文件，交由工作流虛擬機實例化，恢復被掛起的業務流，由於其實例己被更新，它將按新的業務流程運行。
利用SynchroFLOW實現企業應用集成
SynchroFLOW降低業務邏輯、業務數據和業務操作實體三者間的藕合，在企業應用異構環境中可以實現功能構件級和流程級不同層次的集成。軟體開發商開發的EJB、應用程序、FORM和與過程定義有關的附件通過系統管理進行注冊和注銷;用FORM開發工具開發的FORM通過應用程序管理提供的API進行注冊;EJB通過EJB部署工具部署到EJB伺服器上;EJB、應用程序、FORM和附件的索引信息保存到應用程序資料庫中。利用SynchroFLOW的FORM開發工具開發的FORM或用第三方開發工具(如FrontPage)開發的FORM以及以JSP,HTML, EJB封裝的組件，通過注冊，成為一個業務活動功能構件。
在企業應用中有很多應用程序是二次開發商和用戶自己開發的，有的是第三方開發的COST組件，這些應用程序是工作流虛擬機所不認識的.SynchroFLOW通過應用程序的注冊和注銷機制實現對它們的集成。應用程序的集成有兩種方式，一種是將做好的應用程序作為活動一個功能構件，將應用程序索引信息登記在應用程序管理中，供過程定義時集成到活動中，當業務流程運行時它隨活動一塊執行;另一種是調用應用程序，由相應的API進行處理客戶端注冊應用程序的請求，還有響應調用應用程序的請求。

㈧ 幾種常見的軟體體系結構及特點分析

20世紀60年代的軟體危機使得人們開始重視軟體工程的研究。起初，人們把軟體設計的重點放在數據結構和演算法的選擇上，然而隨著軟體系統規模越來越大，對總體的系統結構設計和規格說明變得異常重要。隨著軟體危機程度的加劇，軟體體系結構(software architecture)這一概念應運而生。軟體體系結構著眼於軟體系統的全局組織形式，在較高層次上把握系統各部分之間的內在聯系，將軟體開發的焦點從成百上千的代碼上轉移到粒度較大的體系結構元素及其交互的設計上。與傳統軟體技術相比，軟體體系結構理論的提出不僅有利於解決軟體系統日益增加的規模和復雜度的問題，有利於構件的重用，也有利於軟體生產率的提高。面向方面軟體開發(AOSD)認為系統是由核心關注點(corn concern)和橫切關注點(cross-cutting concern)有機地交織在一起而形成的。核心關注點是軟體要實現的主要功能和目標，橫切關注點是那些與核心關注點之間有橫切作用的關注點，如系統日誌、事務處理和許可權驗證等。AOSD通過分離系統的橫切關注點和核心關注點，使得系統的設計和維護變得容易很多。
Extremara大學的Navasa等人［1］在2002年提出了將面向方面軟體開發技術引入到軟體體系結構的設計中，稱之為面向方面軟體體系結構(aspect oriented software architecture，AO-SA)，這樣能夠結合兩者的優點，但是並沒有給出構建面向方面軟體體系結構的詳細方法。
盡管目前對於面向方面軟體體系結構這個概念尚未形成統一的認識，但是一般認為面向方面軟體體系結構在傳統軟體體系結構基礎上增加了方面構件(aspect component)這一新的構成單元，通過方面構件來封裝系統的橫切關注點。目前國內外對於面向方面軟體體系模型的研究還相對較少，對它的構成單元模型的研究更少，通常只關注方面構件這一構成單元。方面構件最早是由Lieberherr等人［2］提出的，它是在自適應可插拔構件(adaptive plug and play component，APPC)基礎之上通過引入面向方面編程(AOP)思想擴展一個可更改的介面而形成的，但它關於請求介面和服務介面的定義很模糊，未能給出一個清晰的方面構件模型。Pawlak等人［3］提出了一個面向方面的框架，該框架主要包含了一個方面構件模型———Java方面構件(Java aspect component，JAC)，但該方面構件模型僅包含了切點(pointcut)，並把AOP中裝備(advice)集成到了切點的表達式中，它主要從實現的角度進行了闡述，並沒有給出詳細的方面構件模型。本文沒有隻關注面向方面軟體體系結構中方面構件這一構成單元模型，還詳細分析了它的另外兩個構成單元，即構件和連接件，因為面向方面軟體體系結構各部分之間是相互關聯的。
1面向方面軟體體系結構相關概念
面向方面軟體體系結構涉及諸多概念，以下將分別介紹。軟體體系結構在軟體工程領域有著廣泛的影響，但當前仍未形成一個統一的、標準的定義。目前國內外普遍認可的看法是軟體體系結構包含構件、連接件和約束［4］。其中約束描述了體系結構配置和拓撲的要求，確定了體系結構的構件與連接件的連接關系。這樣就可以把軟體體系結構寫成
軟體體系結構(software architecture)=構件(components)+
連接件(connectors)+約束(constraints)
構件是軟體體系結構的基本元素之一。一般認為，構件是指具有一定功能、可明確辨識的軟體單位，並且具備語義完整、語法正確、有可重用價值的特點，然而目前對於構件的具體結構及構成並沒有一個統一的標准［5］，而且一些主要的構件技術也沒有使用相同的構件類型。另外，當前被廣泛接受的構件定義並不包含具體的軟體構件模型(software component model)。例如，Szyperski等人［6］給出了軟體構件一個很有名的定義:軟體構件是一個僅帶特定契約介面和顯式語境依賴的結構單位，它可以獨立部署，易於第三方整合。但是關於軟體構件模型有一個被普遍接受的觀點是:軟體構件是一個具有服務提供和服務請求功能的軟體單元［7］。
連接件是軟體體系結構另一個基本的構成元素，是用來建立構件間交互以及支配這些交互規則的構造模塊。連接件最先是由Shaw［8］提出來的，她建議把連接件作為軟體體系結構中第一類實體，用來表示普通構件之間的交互關系。目前對於連接件尚未形成統一的認識，盡管在軟體體系結構中強調了連接件存在的必要性，但是關於連接件模型的研究還很少，連接件的實際應用還不成熟。
面向方面軟體體系結構在傳統軟體體系結構的基礎上增加了方面構件單元。通常認為，方面構件是封裝了系統橫切關注點的一類特殊的構件。目前關於方面構件模型的研究還處於起步階段。
2面向方面軟體體系結構模型
由於傳統軟體體系結構模型包含構件、連接件和約束，而面向方面軟體體系結構是在傳統軟體體系結構的基礎之上擴展了方面構件，所以面向方面軟體體系模型結構包含構件、連接件、方面構件和約束。其中約束描述了面向方面體系結構配置和拓撲的要求，確定了體系結構的構件、連接件和方面構件之間的連接關系，而構件、連接件、方面構件是它的三個基本的構成單元。以下對這三個構成單元的模型進行詳細的設計。

㈨ 軟體體系結構的研究范疇有哪些請舉例加以說明！

軟體體系結構的形式化方法研究
軟體體系結構研究如果僅僅停留在非形式化的框圖階段，已經難以適應進一步發展的需要。為支持基於體系結構的開發，需要有形式化建模符號、體系結構說明的分析與開發工具。從軟體體系結構研究的現狀來看，在這一領域近來已經有不少進展，其中比較有代表性的是美國卡耐基梅隆大學（Carnegie Mellon University）的Robert J．A11en於l997年提出的Wright系統。Wright是-種結構描述語言，該語言基於一種形式化的、抽象的系統模型，為描述和分析軟體體系結構和結構化方法提供了一種實用的工具。Wright主要側重於描述系統的軟體構件和連接的結構、配置和方法。它使用顯式的、獨立的連接模型來作為交互的方式，這使得該系統可以用邏輯謂詞符號系統，而不依賴特定的系統實例來描述系統的抽象行為。該系統還可以通過一組靜態檢查來判斷系統結構規格說明的一致性和完整性。從這些特性的分析來說，Wright系統的確適用於對大型系統的描述和分析。
軟體體系結構的建模研究
研究軟體體系結構的首要問題是如何表示軟體體系結構，即如何對軟體體系結構建模。根據建模的側重點的不同，可以將軟體體系結構的模型分為5種：結構模型、框架模型、動態模型、過程模型和功能模型。在這5個模型中，最常用的是結構模型和動態模型。
（1）結構模型
這是一個最直觀、最普遍的建模方法。這種方法以體系結構的構件、連接件和其他概念來刻畫結構，並力圖通過結構來反映系統的重要語義內容，包括系統的配置、約束、隱含的假設條件、風格、性質。研究結構模型的核心是體系結構描述語言。
管道/過濾器風格的體系結構
（2）框架模型
框架模型與結構模型類似，但它不太側重描述結構的細節而更側重於整體的結構。框架模型主要以一些特殊的問題為目標建立只針對和適應該問題的結構。
（3）動態模型
動態模型是對結構或框架模型的補充，研究系統的"大顆粒"的行為性質。例如，描述系統的重新配置或演化。動態可能指系統總體結構的配置、建立或拆除通信通道或計算的過程。這類系統常是激勵型的。
（4）過程模型
過程模型研究構造系統的步驟和過程。因而結構是遵循某些過程腳本的結果。
（5）功能模型
該模型認為體系結構是由一組功能構件按層次組成，下層向上層提供服務。它可以看作是一種特殊的框架模型。
這5種模型各有所長，也許將5種模型有機地統一在一起，形成一個完整的模型來刻畫軟體體系結構更合適。例如，Kruchten在1995年提出了一個"4+1"的視角模型。"4+1"模型從5個不同的視角包括邏輯視角、過程視角、物理視角、開發視角和場景視角來描述軟體體系結構。每一個視角只關心系統的一個側面，5個視角結合在一起才能夠反映系統的軟體體系結構的全部內容。"4+1"模型如圖1所示。
圖1 "4+1"模型
發展基於體系結構的軟體開發模型
軟體開發模型是跨越整個軟體生存周期的系統開發、運行、維護所實施的全部工作和任務的結構框架，給出了軟體開發活動各階段之間的關系。目前，常見的軟體開發模型大致可分為三種類型:
（1）以軟體需求完全確定為前提的瀑布模型。
（2）在軟體開發初始階段只能提供基本需求時採用的漸進式開發模型,如螺旋模型等。
（3）以形式化開發方法為基礎的變換模型。
所有開發方法都是要解決需求與實現之間的差距。但是，這三種類型的軟體開發模型都存在這樣或那樣的缺陷，不能很好地支持基於軟體體系結構的開發過程。因此，研究人員在發展基於體系結構的軟體開發模型方面做了一定的工作。例如，為了形象地表示體系結構的生命周期，北京郵電大學的周瑩新博士建立了一個軟體體系結構的生命周期模型，該模型如圖2所示。
數據抽象和面向對象風格的體系結構
圖2 軟體體系結構的生命周期模型
軟體產品線體系結構的研究
軟體體系結構的開發是大型軟體系統開發的關鍵環節。體系結構在軟體生產線的開發中具有至關重要的作用，在這種開發生產中，基於同一個軟體體系結構，可以創建具有不同功能的多個系統。在軟體產品族之間共享體系結構和一組可重用的構件，可以增加軟體工程和降低開發和維護成本。
一個產品線代表著一組具有公共的系統需求集的軟體系統，它們都是根據基本的用戶需求對標準的產品線構架進行定製，將可重用構件與系統獨有的部分集成而得到的。採用軟體生產線式模式進行軟體生產，將產生巨型編程企業。但目前生產的軟體產品族大部分是處於同一領域的。

㈩ 軟體體系結構的體系風格

對軟體體系結構風格的研究和實踐促進了對設計的復用，一些經過實踐證實的解決方案也可以可靠地用於解決新的問題。體系結構風格的不變部分使不同的系統可以共享同一個實現代碼。只要系統是使用常用的、規范的方法來組織，就可使別的設計者很容易地理解系統的體系結構。例如，如果某人把系統描述為客戶/伺服器模式，則不必給出設計細節，我們立刻就會明白系統是如何組織和工作的。
下面是Garlan和Shaw對通用體系結構風格的分類：
（1）數據流風格：批處理序列；管道/過濾器
（2）調用/返回風格：主程序/子程序；面向對象風格；層次結構
（3）獨立構件風格：進程通訊；事件系統
（4）虛擬機風格：解釋器；基於規則的系統
（5）倉庫風格：資料庫系統；超文本系統；黑板系統
限於篇幅，在本文中，我們將只介紹幾種主要的和經典的體系結構風格和它們的優缺點。有關新出現的軟體體系結構風格，將在後續文章中進行介紹。 C2體系結構風格可以概括為：通過連接件綁定在一起的按照一組規則運作的並行構件網路。C2風格中的系統組織規則如下：
（1）系統中的構件和連接件都有一個頂部和一個底部；
（2）構件的頂部應連接到某連接件的底部，構件的底部則應連接到某連接件的頂部，而構件與構件之間的直接連接是不允許的；（3）一個連接件可以和任意數目的其它構件和連接件連接；
（4）當兩個連接件進行直接連接時，必須由其中一個的底部到另一個的頂部。
圖3是C2風格的示意圖。圖中構件與連接件之間的連接體現了C2風格中構建系統的規則。
圖3 C2風格的體系結構
C2風格是最常用的一種軟體體系結構風格。從C2風格的組織規則和結構圖中，我們可以得出，C2風格具有以下特點：
（1）系統中的構件可實現應用需求，並能將任意復雜度的功能封裝在一起；
（2）所有構件之間的通訊是通過以連接件為中介的非同步消息交換機制來實現的；
（3）構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制線程之類的相關性假設。 在管道/過濾器風格的軟體體系結構中，每個構件都有一組輸入和輸出，構件讀輸入的數據流，經過內部處理，然後產生輸出數據流。這個過程通常通過對輸入流的變換及增量計算來完成，所以在輸入被完全消費之前，輸出便產生了。因此，這里的構件被稱為過濾器，這種風格的連接件就象是數據流傳輸的管道，將一個過濾器的輸出傳到另一過濾器的輸入。此風格特別重要的過濾器必須是獨立的實體，它不能與其它的過濾器共享數據，而且一個過濾器不知道它上游和下游的標識。一個管道/過濾器網路輸出的正確性並不依賴於過濾器進行增量計算過程的順序。
圖4是管道/過濾器風格的示意圖。一個典型的管道/過濾器體系結構的例子是以Unix shell編寫的程序。Unix既提供一種符號，以連接各組成部分(Unix的進程)，又提供某種進程運行時機制以實現管道。另一個著名的例子是傳統的編譯器。傳統的編譯器一直被認為是一種管道系統，在該系統中，一個階段（包括詞法分析、語法分析、語義分析和代碼生成）的輸出是另一個階段的輸入。
圖4 管道/過濾器風格的體系結構
管道/過濾器風格的軟體體系結構具有許多很好的特點：
（1）使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點；
（2）允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成；
（3）支持軟體重用。重要提供適合在兩個過濾器之間傳送的數據，任何兩個過濾器都可被連接起來；
（4）系統維護和增強系統性能簡單。新的過濾器可以添加到現有系統中來；舊的可以被改進的過濾器替換掉；
（5）允許對一些如吞吐量、死鎖等屬性的分析；
（6）支持並行執行。每個過濾器是作為一個單獨的任務完成，因此可與其它任務並行執行。
但是，這樣的系統也存在著若干不利因素。
（1）通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數據，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換。
（2）不適合處理交互的應用。當需要增量地顯示改變時，這個問題尤為嚴重。
（3）因為在數據傳輸上沒有通用的標准，每個過濾器都增加了解析和合成數據的工作，這樣就導致了系統性能下降，並增加了編寫過濾器的復雜性。 抽象數據類型概念對軟體系統有著重要作用，目前軟體界已普遍轉向使用面向對象系統。這種風格建立在數據抽象和面向對象的基礎上，數據的表示方法和它們的相應操作封裝在一個抽象數據類型或對象中。這種風格的構件是對象，或者說是抽象數據類型的實例。對象是一種被稱作管理者的構件，因為它負責保持資源的完整性。對象是通過函數和過程的調用來交互的。
圖5是數據抽象和面向對象風格的示意圖。圖5 數據抽象和面向對象風格的體系結構
面向對象的系統有許多的優點，並早已為人所知：
（1）因為對象對其它對象隱藏它的表示，所以可以改變一個對象的表示，而不影響其它的對象。
（2）設計者可將一些數據存取操作的問題分解成一些交互的代理程序的集合。
但是，面向對象的系統也存在著某些問題：
（1）為了使一個對象和另一個對象通過過程調用等進行交互，必須知道對象的標識。只要一個對象的標識改變了，就必須修改所有其他明確調用它的對象。
（2）必須修改所有顯式調用它的其它對象，並消除由此帶來的一些副作用。例如，如果A使用了對象B，C也使用了對象B，那麼，C對B的使用所造成的對A的影響可能是料想不到的。 基於事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件。系統中的其它構件中的過程在一個或多個事件中注冊，當一個事件被觸發，系統自動調用在這個事件中注冊的所有過程，這樣，一個事件的觸發就導致了另一模塊中的過程的調用。
從體系結構上說，這種風格的構件是一些模塊，這些模塊既可以是一些過程，又可以是一些事件的集合。過程可以用通用的方式調用，也可以在系統事件中注冊一些過程，當發生這些事件時，過程被調用。
基於事件的隱式調用風格的主要特點是事件的觸發者並不知道哪些構件會被這些事件影響。這樣不能假定構件的處理順序，甚至不知道哪些過程會被調用，因此，許多隱式調用的系統也包含顯式調用作為構件交互的補充形式。
支持基於事件的隱式調用的應用系統很多。例如，在編程環境中用於集成各種工具，在資料庫管理系統中確保數據的一致性約束，在用戶界面系統中管理數據，以及在編輯器中支持語法檢查。例如在某系統中，編輯器和變數監視器可以登記相應Debugger的斷點事件。當Debugger在斷點處停下時，它聲明該事件，由系統自動調用處理程序，如編輯程序可以卷屏到斷點，變數監視器刷新變數數值。而Debugger本身只聲明事件，並不關心哪些過程會啟動，也不關心這些過程做什麼處理。
隱式調用系統的主要優點有：
（1）為軟體重用提供了強大的支持。當需要將一個構件加入現存系統中時，只需將它注冊到系統的事件中。
（2）為改進系統帶來了方便。當用一個構件代替另一個構件時，不會影響到其它構件的介面。
隱式調用系統的主要缺點有：
（1）構件放棄了對系統計算的控制。一個構件觸發一個事件時，不能確定其它構件是否會響應它。而且即使它知道事件注冊了哪些構件的構成，它也不能保證這些過程被 調用的順序。
（2）數據交換的問題。有時數據可被一個事件傳遞，但另一些情況下，基於事件的系統必須依靠一個共享的倉庫進行交互。在這些情況下，全局性能和資源管理便成了問題。
（3）既然過程的語義必須依賴於被觸發事件的上下文約束，關於正確性的推理存在問題。 層次系統組織成一個層次結構，每一層為上層服務，並作為下層客戶。在一些層次系統中，除了一些精心挑選的輸出函數外，內部的層只對相鄰的層可見。這樣的系統中構件在一些層實現了虛擬機（在另一些層次系統中層是部分不透明的）。連接件通過決定層間如何交互的協議來定義，拓撲約束包括對相鄰層間交互的約束。
這種風格支持基於可增加抽象層的設計。這樣，允許將一個復雜問題分解成一個增量步驟序列的實現。由於每一層最多隻影響兩層，同時只要給相鄰層提供相同的介面，允許每層用不同的方法實現，同樣為軟體重用提供了強大的支持。
圖6是層次系統風格的示意圖。層次系統最廣泛的應用是分層通信協議。在這一應用領域中，每一層提供一個抽象的功能，作為上層通信的基礎。較低的層次定義低層的交互，最低層通常只定義硬體物理連接。
圖6 層次系統風格的體系結構
層次系統有許多可取的屬性：
（1）支持基於抽象程度遞增的系統設計，使設計者可以把一個復雜系統按遞增的步驟進行分解；
（2）支持功能增強，因為每一層至多和相鄰的上下層交互，因此功能的改變最多影響相鄰的上下層；
（3）支持重用。只要提供的服務介面定義不變，同一層的不同實現可以交換使用。這樣，就可以定義一組標準的介面，而允許各種不同的實現方法。
但是，層次系統也有其不足之處：
（1）並不是每個系統都可以很容易地劃分為分層的模式，甚至即使一個系統的邏輯結構是層次化的，出於對系統性能的考慮，系統設計師不得不把一些低級或高級的功能綜合起來；
（2）很難找到一個合適的、正確的層次抽象方法。 在倉庫風格中，有兩種不同的構件：中央數據結構說明當前狀態，獨立構件在中央數據存貯上執行，倉庫與外構件間的相互作用在系統中會有大的變化。
控制原則的選取產生兩個主要的子類。若輸入流中某類時間觸發進程執行的選擇，則倉庫是一傳統型資料庫；另一方面，若中央數據結構的當前狀態觸發進程執行的選擇，則倉庫是一黑板系統。
圖7是黑板系統的組成。黑板系統的傳統應用是信號處理領域，如語音和模式識別。另一應用是松耦合代理數據共享存取。
圖7 黑板系統的組成
我們從圖4中可以看出，黑板系統主要由三部分組成：
（1）知識源。知識源中包含獨立的、與應用程序相關的知識，知識源之間不直接進行通訊，它們之間的交互只通過黑板來完成。
（2）黑板數據結構。黑板數據是按照與應用程序相關的層次來組織的解決問題的數據，知識源通過不斷地改變黑板數據來解決問題。
（3）控制。控制完全由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識。