【系統分析師之路】第七章 系統設計(軟件架構設計)記憶敲出

【系統分析師之路】第七章 系統設計(軟件架構設計)記憶敲出

1. 軟件架構的概念

  • 軟件架構是連接軟件需求和軟件設計的橋樑,通過軟件的結構就可以有效的把軟件的各個需求通過設計分配到軟件的各個模塊中。

2. 五種軟件架構的風格:

  1. 數據流風格:批處理風格和管道過濾器風格
  2. 虛擬機風格:解釋器,基於規則的系統
  3. 獨立構件風格:事件系統,進程通信
  4. 調用返回風格:面向對象風格,主程序子程序風格,層級架構風格
  5. 倉庫風格:黑板系統,超文本系統,數據庫系統

3. 數據流風格的概念

  • 批處理風格和管道過濾器風格是數據流風格的兩個典型的代表。
  • 批處理風格和管道過濾器相同之處是兩者在處理過程中都是沒有和用戶有交互的,
  • 批處理風格和管道過濾器不同之處是批處理風格更加強調一個完整地處理完了之後纔可以進行下一個環節的處理。
  • 編譯器有詞法分析,語法分析,語義分析等幾個步驟,往往是一個步驟完了之後纔可以執行下一個步驟,這個就是數據流風格的一個應用,當然編譯器可能不光光使用批處理風格,虛擬器風格里面有解釋器風格也可以應用於編譯器之中。
  • DOS裏面的指令也是數據流風格的一個應用。
  • 數據流風格相比於其他的架構風格,它更加強調的是處理的是按部就班的處理數據流,一個處理部件的輸入是下一個處理部件的輸出;在結構化圖形中的數據流圖比較適合描述數據流風格。

4. 獨立構件風格概念

  • 獨立構件風格包括了進行通信和事件驅動系統兩個。
  • 獨立構件風格不同於調用返回風格的顯示調用,它是通過消息通信的方式完成信息的交換。進程之間的消息通信,遠程過程調用,套接字異步消息通信等方式都屬於獨立構件的風格。因爲獨立構件是基於消息通信的,所以它是隱式調用。
  • 事件驅動系統中,按一個按鈕會觸發什麼事件往往是不明確的,但是一個事件的觸發就導致了另一個模塊中的過程調用。
  • 獨立構件最大的優點就是構件的維護和演化變得更加的方便了。構件之間的耦合度低,所以基於構件的開發模型就能夠更好的運用。獨立構件的缺點是構件放棄了對系統計算的控制。
  • 獨立構件風格和基於服務的架構SOA和EJB,WebServices應該有千絲萬縷的聯繫。

5. 主程序子程序風格的概念

  1. 面向對象架構風格
    這種風格的構件是對象。對象是抽象數據類型的實例。連接件即是對象間交互的方式。面向服務的開發模型是基於面向對象思想的,在我看來把面向對象解耦,功能封裝之後,並改變原來對象之間直接的調用關係,於是就可以形成獨立構建的架構。
  2. 主程序/子程序架構風格
    不同於獨立構件風格的隱式調用,主程序子程序都是顯示的調用。它把問題劃分爲若干處理步驟進行。比如調用LIB或者動態鏈接庫的IF函數的完成某一個功能的時候,這就是主程序子程序的一個應用場景。
  3. 層次化架構風格
    層次結構的優點就是可以把一個大問題化繁爲簡地分解成一個個的小問題,然後逐步解決,這樣在層次架構中就隱藏了問題的複雜性;在層次化的結構中,每一個層都是爲了在自己之上的層次服務,如果修改了該層次的模塊,也只會影響直接上下調用的其他模塊。影響很小。層次化的優點就是化繁爲簡把大問題進行了有效的分解;
    但是在層次化的架構中,到底分幾層才合適沒有一個統一的定論和標準,分得層次越多效率越低。
    OSI七層模型,TCPIP協議簇四層模型,物聯網三層模型,BS架構,CS架構都是層次化架構的應用。

6. 4+1架構風格

  • 場景:用例視圖
  • 動態視圖:邏輯視圖和開發視圖;
  • 邏輯視圖一般給最終用戶看,確認系統的需求情況,記錄系統中有哪些功能,在架構中也是邏輯視圖
  • 開發視圖記錄系統之間信息的交互過程,在架構中是實現視圖。
  • 靜態模型:進程視圖和物理視圖;
  • 進程視圖描述系統的非功能需求,性能等內容,所以系統集成管理人員比較關心;在架構中也叫進程視圖。
  • 物理視圖描述系統部署情況,比如網絡拓撲,安裝,所以系統工程人員比較關心;在架構中叫部署視圖。

7. 架構的評估方法

  • 信息系統主要的評估方式有三種:基於問卷調查和檢查表的評估,基於場景的評估和基於度量的評估
  1. 基於調查問卷或檢查表的方式
    這種方式很大程度上依賴於評估人員的主觀判斷,儘管主管但卻是目前使用率最高的方式,
    而檢查表會比調查問卷問更加具體的問題,而且這種方式往往依賴於專家判斷。
  2. 基於場景的方式
    包括了ATAM架構權衡分析法和SAAM軟件架構分析法,CBAM成本效益分析法三種方式。
    在體系結構中一般採用刺激(stimulus),環境(environment)和響應(response)三個方面來對場景進行描述。
  3. 基於度量的方式
    代碼的行數,構件個數,調用層次數等
  4. 評估方式的特點比較
    從通用性方面看,問卷調查和度量比較通用
    只有度量的方式,需要在瞭解架構的前提之下才可以實施,也是最客觀的架構評估方式,
    基於場景的評估方式也是比較主觀的評估方式。

8. 虛擬機風格

  • 構件一個平臺,讓其他功能能夠運行在虛擬機之上。虛擬機屏蔽的操作系統的不同的內容,構件了一個讓程序執行的統一的平臺,也爲跨平臺的實現提供了技術支撐。在PC機上完FC遊戲,玩GBA遊戲都是虛擬平臺的很好的應用。
  • 解析器和基於規則的系統就是虛擬機風格的典型應用。J2EE和.NET框架中都採用了虛擬機風格。

9. 倉庫風格

  • 倉庫系統的典型代表就是數據庫系統,它是以數據爲中心的架構風格。黑板系統也是和倉庫系統有關係,它包括三部分:知識源,黑板和控制。黑板系統還可以解決編譯器優化的問題(通過一個集成的編譯平臺),黑板系統是以知識源爲核心。

10. C/S架構

  • 分爲兩層CS架構和三層CS架構,傳統的兩層CS架構分爲數據層和表示層。數據層是服務器,表示層是客戶端。兩層CS架構是一種重客戶端輕服務器的框架,因爲它主要的業務邏輯和功能表示都在客戶端完成,這樣帶來的一個問題就是更新變得困難,客戶端需要更新時,往往所有的安裝的客戶端都同步需要更新纔可以,而且有的客戶端在Mac,有的在Windows的話,都需要分別的更新,成本高那是肯定的了。除去不同客戶端表示差異的問題,隨着客戶端的升級,客戶端會越來越重,越來越複雜和不易維護。兩層CS架構還有新技術不容易使用和導入等缺點。正因爲兩層結構有這樣那樣的缺點,所以3層CS架構呼之欲出。
  • 三層CS架構在兩層的基礎上多出了一個功能層,簡單可以理解爲它將兩層CS架構中的客戶端,獨立出其中的業務邏輯,也就是說是功能層,僅僅只將頁面表示放在客戶端。所以三層CS架構也叫做瘦客戶端架構。三層架構使各層邏輯之間相對的獨立,提高了整個系統的可擴展性可維護性和可靠性,而且各層可以使用不同的開發語言增加了靈活性。各層之間職責相互的獨立,各司其職,也爲安全性設計提供了有效的前提條件。
  • 三層架構中,數據層也就是服務器部署在一臺PC中,業務邏輯功能層和表示層可以部署在一臺應用服務器中,也可以分開部署。三層架構中各個層次之間通信效率肯定不如兩層CS架構。但是三層CS架構沒有得到很好的應用,因爲三層CS架構生不逢時,在它出來後不久就有了三層BS的架構。

11. 三層B/S架構

  • 這個架構最大的特點也是最大的優點就是零客戶端,也就是不需要安裝客戶端。這樣在部署升級系統的時候就變得更加簡單了。CS架構的不足之處也得到了很好的解決。BS架構有一個Web服務器來處理功能和實現頁面表示,和CS架構一樣的是都有數據層。當然BS架構的缺陷也是十分突出。首先它的交互性不如CS架構,所以後來纔有了Ajax異步傳輸技術的補充和發展,它的安全性不高,所以需要https協議的配合;頁面的動態表現力不如CS架構,什麼Flash很難實現;由於BS架構大多數計算處理都集中到了Web服務器,而CS架構在客戶端可以處理,所以BS架構的速度不如CS架構快(響應速度)那也是合情合理的;哪怕是局部變動,提交頁面也往往是一整個頁面,交互性不好。

12. 混合架構

  • 正因B/S架構和C/S架構各有優缺點,於是就有了混合架構的概念。混合架構就是綜合了兩個架構之間的優點。他有兩個應用,一個是內外有別,一個是查改有別。
  • 內外有別就是對內網使用CS架構,對外使用BS架構,這樣對外網用戶就不用更新安裝下載客戶端了,對內使用CS架構,維護升級查詢處理都比BS架構好一個數量級。
  • 還有一種查改有別就是簡單的交互比如查找信息使用BS架構,而複雜的交互使用CS架構保證速度,這兩個混合模式都是兩個架構取長補短的應用。

13. 富互聯網技術

  • 他最大的特點就是彌補了B/S架構中交互性不強的問題,它裏面包括了Ajax技術和Flex技術。Ajax是異步的javascript和xml,比如我們輸入用戶名的時候,在沒有刷新頁面的前提下就提示我們該用戶名已經註冊了,這就是阿賈克斯技術的一個應用;而Flex技術更多的應用在網絡遊戲中,在網遊中炫酷的畫面就是富互聯網的應用。提高了人機界面交互的能力,這個知識點可以和人機界面設計結合在一起。RIA技術已經可以將數據緩存在客戶端了,這樣就減少了數據往返的次數。

14. SOA基於服務的架構

  • SOA最大的特點有三個:高度標準化的接口,鬆散耦合,粗粒度;從小到大分別是對象,構件和服務。可以看到構件是對一系列對象的封裝與整合,像VB.NET語言中的控件庫就是構件技術的應用;再對一系列的這種控件有機結合在一起,就構成了服務。構件的標準是多種多樣的,有COM,EJB,有COM+。正因爲構件的多樣化,纔有了服務存在的價值。
  • 服務都是基於XML,相關協議也是基於XML發展而來的。服務是把所有使用到的東西高度標準化的過程。
    ESB和WebServices是基於服務的架構最爲經典的應用。

15. Webservice

  • 在Webservice中有三個角色:服務請求者,服務提供者,服務註冊中心。它是SOA的實現方式。三者當中,服務註冊中心是可有可無的,他記錄了服務請求者和提供者之間的映射關係。服務請求者和提供者之間有一個綁定的過程,而綁定又可以分爲靜態和動態兩種。靜態綁定就不需要使用到註冊中心了,而動態綁定需要先通過查找找到服務的提供者,再與服務的提供者建立綁定關係。

16. ESB

  • 企業應用總線在我的理解中,更像是企業應用集成中的邏輯集成。更像是一個超級中間件,它將各個封裝的服務進行集成,以提供給Web應用和MIS應用。使用了ESB,我們就可以忽略每個子系統的物理位置,它還支持多種數據之間的格式轉換,在企業總線上佈下日誌功能,就能監控總線上所有通信內容,提高了安全性。在企業中建立ESB,可以有效解決信息孤島的問題。
  • ESB和Webservice有什麼不同,他們的應用場景不同,Webservice是把服務在因特網中封裝成一個個高度標準統一的服務,而ESB更加側重於企業的應用,將企業的子系統以服務的形式一個個掛接到服務器上,把各個服務給連接起來。

17. 中間件

  • 中間件是一種獨立的軟件或服務程序,它可以應用在分佈式系統中,在各個不同的技術軟件之間共享資源,中間件可以理解爲SOA架構中的構件,在企業應用集成中,有邏輯集成,使用中間件在不同的子系統之間實現通信,將原本信息孤島的系統連接起來,這個就是中間件的一個應用。中間件也可以簡單理解爲翻譯者,使用中間件就可以實現遺留系統的可重用。
  • 中間件有消息中間件,有數據庫中間件,還有遠程過程調用中間件,還有業務型的中間件。
  • 在負載均衡技術中,有使用軟件實現負載均衡算法的應用,這個也是中間件技術的一個應用。
  • 中間件技術的實現依賴於構件之間的通信,中間件可以實現分部在兩臺不同PC上的機器可以相互的進行消息轉化後的通信,也覈實中間件技術最重要的優勢。
  • 企業應用總線ESB中的總線可以理解爲一箇中間件,各種層次架構(比如CS架構等)的分佈式實現也需要通過中間件技術實現。在虛擬機風格中跨平臺的實現,也是中間件的一種應用。

18 .NET和J2EE

  • 它的最底層是通用語言運行環境,通用語言運行環境說白了就是一個虛擬機風格。他借鑑了J2EE架構。它可以支持多個開發語言,這些開發語言會被翻譯成通用語言規範。通用語言運行規範運行在CLR之上。.NET體系中其實就有虛擬機了,CLR就是.NET平臺的虛擬機。虛擬機包括有ASP.NET它是用在Windows應用中,ADO.NET是用來做數據庫操作的。.NET中的基礎類庫是一種複用的機制。
  • NET架構雖然支持的開發語言多,但它的移植性不如J2EE,因爲NET是微軟公司的產品,所以NET平臺目前只能應用在微軟的操作系統之上。在其他場合J2EE和.NET框架是大同小異的。
  • 而J2EE分爲四個層次,最底層是企業信息層,其次是業務邏輯層,上兩層是Web層和應用層。JVM是J2EE下的虛擬機,企業Bean和會話Bean等都是運行在業務層。
  • EJB (Enterprise Java Beans) 是基於分佈式事務處理的企業級應用程序的組件。
    EJB容器可以接受三類EJB:實體Bean(Entity Beans),會話Beans(Session Beans),消息驅動Bean(Message Driven Beans ,MDBs)。而會話Beans又可以分爲兩種:一種是無狀態會話Bean(Stateless Session Beans),另一種是有狀態會話Bean(Stateful Session Beans)。

19 .MVC和MVP

  • MVC是一種設計模式也是一種架構模式,MVC是Model-View-Control的縮寫。MVC模式其實類似於之前的分層模式,
  • 它將業務邏輯分成了三個層次,每個層次分別執行不同的分工,Model偏向數據處理層,View偏向頁面表示。
    MVC模式呢也可以分爲兩種,一種是主動MVC,另一種是被動MVC,主動MVC種加入了觀察者模式,View會定期確認Model的情況;如果發現數據有更新了,那麼就更新表示,比如常用的股市軟件就是主動MVC模式的應用;而被動MVC則正好相反,被動MVC只有在Model更新了之後,不通知視圖View讓視圖手動去Model中取內容。
  • 在MVC模式之後,出現了MVP模式。MVP模式是在MVC模式的基礎上進行了優化和改良,MVP最大的改進就是進一步把Model-View之間進行了解耦,Model-View之間沒有了直接的消息通信與聯繫,所有的消息通信都需要經過P層,P就是Presenter的縮寫,Presenter在MVP模型中更像是業務邏輯層,所有的Model-View直接的通信都需要經過Presenter層。
  • MVP解耦更加地徹底,也就更容易實施單體測試;MVP中的V要處理界面事件,業務邏輯在P中,MVC模型中界面事件由C處理。Presenter中既有業務邏輯也有同步邏輯。同步邏輯保證Model-View之間的信息可以同步更新。
  • MVP有什麼缺點呢?因爲在MVP的Presenter中,除了業務邏輯以外,還有很多View-Model的通信邏輯和同步邏輯,所以在有解耦易測試的優點的同時,Presenter層會變得比較龐大和沉重。

20 .質量屬性

  • 質量屬性包括了:性能,可靠性,可用性,安全性,可修改(維護)性,互操作性,功能性,可變性等一系列屬性所組成。
  1. 性能:比如吞吐量,頁面響應速度就是性能屬性。
  2. 可靠性和可用性:在軟件架構中一般我們只提可用性而不是可靠性,在系統性能與評價章節中,可用性是指系統可以正常使用時間和出現故障不可以使用時間的比率,可靠性突出的是在某段時間內出現故障的次數。
  3. 安全性:安全性方面信息系統可以分爲完整性,不可抵賴性,保密性和可控性四個方面。
  4. 可修改性:信息系統需要修改,需要維護的時候,容易不容易維護就是修改性的體現,在這裏與其說是可修改性,倒不如說是可維護性來得切合實際把。
  5. 互操作性:信息系統往往難以獨善其身,它與其他系統之間如何進行交互
  6. 功能性:信息系統能夠完成期望功能的程度。
  7. 可變性:它比可修改性高一個層次,精確的說,可變性應該理解爲系統的可擴展性。在軟件產品線中,可變性十分之重要,因爲在軟件產品線。

21 .ATAM和SAAM架構評估方法

  • 架構權衡分析法(ATAM),軟件架構分析法(SAAM),成本效益分析法(CBAM)都是基於場景的架構評估方法。說到場景,它出現在4+1視圖的中間位置,它使用用例視圖來展現,場景是系統重要的活動的抽象。
  • SAAM軟件架構評估方法:這種方法相比ATAM方法來得簡單的多,這種方法類似於軟件的測試,軟件測試一般先實施單個模塊的測試,再實施集成模塊的測試;在SAAM中,首先要建立場景,然後描述信息系統的架構,建立好的場景先實施優先級的分級,先是單個評估,然後組合在一起實施評估,最後形成對於總體的評價。
  • SAAM的特點就是比較簡單,花在培訓上的成本比較少。
  • ATAM架構權衡分析法:ATAM不僅僅是開發人員,用戶方代表,首席架構師都要參與其中,ATAM方法還有投票環節。如果有15票,你可以將票分別投給你認爲重要的各個場景,也可以將所有的票都投給一個場景。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章