軟件體系結構基本概念匯總


      這門課與UML建模,程序設計方法學一樣。都是站在比較高的角度來看整個軟件結構。並非對算法,或者語言的關注。

假設以后有志於成為軟件架構師,就應該好好學這門課。

如今我把自己整理的這門課的資料與大家分享。

二、名詞解釋(每題2分,共20分)
1、B/S(期中)    
答:瀏覽器/server風格,是三層應用結構的一種實現方式。
詳細結構:瀏覽器/Webserver/數據庫server。

2、C/S(期中)   
答:客戶/server風格,是基於資源不正確等,且為共享而提出來的,定義了工作站怎樣與server相連,以實現數據和應用分布到多個處理機上。C/S體系結構有三個主要組成部分:數據庫server、客戶應用程序和網絡 。



3、HMB     
答:層次消息總線的軟件體系結構風格(Hierarchical Message Bus—based Style)。HMB風格基於層次消息總線。支持構件的分布和並發,構件之間通過消息進行通信。

4、DSSA   
答:特定領域的軟件體系結構(Domain Specific Software Architecture)就是在一個特定的領域中為一組應用提供組織結構參考的標准軟件體系結構。



5、ADL(期中)    
答:軟件體系結構描寫敘述語言(Architecture Description Language)是一種形式化語言。它在底層語義模型的支持下,為軟件的概念體系結構建模提供了詳細語法和框架。

  

6、XML   
答:可擴展標記語言(Extensible Markup Language),XML是W3C制定的作為Internet上數據交換和表示的標准語言,是一種同意用戶定義自己的標記的元語言(Meta)。

7、ATAM   
答:體系結構權衡分析方法(Architecture Tradeoff Analysis Method),它是針對系統所使用或改動活動的支持程度,來推斷該體系結構針對這一場景所代表的質量需求的滿足程度的體系結構評估方法。

8、Web Service  
答:Web服務(Web Service)是一種新的面向服務的體系結構,當中定義了一組標准協議。用於接口定義、方法調用、基於Internet的結構注冊以及各種應用的實現。

9、MTTF    
答:平均失效前時間(Mean Time To Failure)指軟件在失效前正常工作的平均統計時間。



10、SOAP   
答:簡單對象訪問協議(Simple Object Access Protocol)。SOAP是一個基於XML的在松散分布式環境中交換結構化信息的輕量級協議,它為在一個松散的、分布式環境中使用XML交換結構化的和類型化的信息提供了一種簡單的機制。

11、WSDL  
答:Web服務描寫敘述語言(Web Services Description Language)。

定義了一套基於XML的語法,用來將Web Services描寫敘述為可以進行消息交換的服務訪問點的集合。

12、UDDI   
答:(Universal Description Discovery Integration) 統一描寫敘述、發現和集成協議。是一套基於Web的分布式的Web Services信息注冊中心的實現標准規范,同一時候也包括一組訪問協議的實現標准,使得企業能將自身的Web Services注冊上去,並讓別的企業可以發現並訪問這些Web Services。



13、SAAM  
答:(Software Architecture Analysis Method) 軟件體系結構分析方法是最早精心設計並形成文檔並得到廣泛使用的軟件體系結構分析方法 。它最初是為了評估體系結構的可改動性而設計。

14、MVC   
答:(Model-View-Controller style)模型—視圖---控制器 風格。主要處理軟件用戶界面開發中所面臨的問題。MVC風格將交互式應用划分為3種構件:視圖、模型和控制器。同意為一個模型建立多個視圖。

15、Artifact-Driven    
答:制品驅動的體系結構設計方法從方法的制品描寫敘述中提取體系結構描寫敘述。它的樣例包含廣為流行的面向對象分析和設計方法OMT和OAD。

16、Use-Case-Driven
答:用例驅動的體系結構設計方法主要從用例導出體系結構抽象。統一過程使用的就是一種用例驅動的體系結構設計方法。



17、Domain-Driven   
答:領域驅動,體系結構是從領域模型導出的,領域模型是在領域分析階段開發的。

 

18、Pattern-Driven  
答:模式驅動,該方法從模式導出體系結構抽象

19、構件(期中)  
答:構件是指語義完整。語法正確和有可重用價值的單位軟件,是軟件重用過程中能夠明白辨識的系統。

20、連接件(期中)
答:Connectors 是用來建立構件間的交互以及支配這些交互規則的體系結構構造模塊。



21.、MTBF
答:(Mean Time Between Failure)平均無故障時間,是指相鄰兩次故障之間的平均工作時間,也稱為平均故障間隔,它反映了產品的時間質量。是體現產品在規定時間內保持功能的一種能力。



22、敏感點
答:是指會因為體系結構元素的改動而發生顯著變化的系統模型參數。



23、權衡點  
答:與多個敏感點有關的體系結構元素。

24、直接場景
答:直接場景指當前體系結構不經改動就可以支持的場景。

25、間接場景
答:不能直接被當前體系結構支持。為了滿足間接場景。需對體系結構進行某種改動。

26、質量屬性效用樹
答:以樹的形式表現質量屬性的細化。根是效用,接下來是質量屬性層,再下一層是質量屬性詳細描寫敘述分類,最后一層是詳細的場景。

三、問答題(40分)
1、構件描寫敘述模型有哪幾種?
答:3C模型、REBOOT模型、青鳥構件模型。



2、理解並比較構件分類的三種方法:keyword分類法、刻面分類法和超文本組織方法。它們是怎樣組織的?怎樣在當中檢索構件?每種方法各有什么優缺點?
答:
(1)keyword分類法:是一種最簡單的構件庫組織方法。其基本思想是:依據領域分析的結果將應用領域的概念依照從抽象到詳細的順序逐次分解為樹形或有向無回路圖結構;
怎樣檢索:系統在圖形用戶界面上將構件庫的keyword樹形結構直觀的展示給用戶,用戶通過對樹形結構的逐級瀏覽尋找須要的keyword並提取對應的構件。
長處是簡單。易於實現。缺點是在某些場合沒有應用價值,由於用戶往往無法用構建庫中已有的keyword描寫敘述期望的構件功能或行為。對庫的瀏覽也easy使用戶迷失方向;

(2)刻面分類法:主要思想來源於圖書館學。在刻面分類機制中,定義若干用於刻畫構件特征的“面”。每一個面包括若干概念。這些概念表述構件在面上的特征。刻面能夠描寫敘述構件運行的功能,被操作的數據。構件應用的語境或隨意其它特征;
怎樣檢索:構造查詢、檢索構件、對構件進行排序。
長處是易於實現相似構件的查找。

缺點是查詢時比較麻煩;

(3)超文本組織方法:其主要思想是全部構件必須輔以詳盡的功能或行為說明文檔;說明中出現的重要概念或構件以網狀鏈接方式相互連接;檢索者在閱讀文檔的過程中可依照人類的聯想思維方式隨意跳轉到包括相關概念或構件的文檔;全文檢索系統將用戶給出的keyword說明文檔中的文字進行匹配。實現構件的瀏覽式檢索;
怎樣檢索:用戶首先給出一個或數個keyword,系統在構件的說明文檔中進行精確或模糊的語法匹配,匹配成功后,向用戶列出對應的構建說明;
長處是超文本組織方法為構造構件和重用構件提供了友好,直接的多媒體方式。因為網狀結構比較自由,松散,因此,超文本組織方法比前兩種方法更易於改動構件庫的結構。缺點是在某些情況下用戶難以在超文本瀏覽過程中正確選取構件;

3、了解軟件體系結構的四個發展階段。
答:
(1)“無體系結構”設計階段:開發主要採用匯編語言,規模較小;
(2)萌芽階段:主要採用解耦固化的開發技術;
(3)0基礎階段:主要採用面向對象的開發技術。從多種角度對系統建模(如UML);
(4)高級階段:該階段以Kruchten提出的“4+1”模型為標志。軟件開發的中心是描寫敘述系統的高層抽象類型。

4、依據軟件體系結構的定義,你覺得軟件體系結構的模型應該由哪些部分組成?(期中)
答:軟件體系結構定義為構件,連接件和約束。構件是可預制和可重用的軟件部件,是組成體系結構的基本計算單元或數據存儲單元;連接件也是可預制和可重用的軟件部件,是構件之間的連接單元;構件和連接件之間的關系用約束來描寫敘述。這樣即能夠把軟件體系結構寫成:體系結構=構件+連接件+約束。



5、至少掌握三種經典軟件體系結構風格。
答:
倉庫風格和黑板風格
倉庫風格的體系結構由兩種構件組成:中央數據結構和獨立構件集合。


黑板體系結構由三部分組成:知識源、黑板數據結構、控制器
黑板體系結構是倉庫體系結構的特殊化,便於共享大量數據,也便於擴展共享的黑板數據結構。


MVC風格
將模型與視圖、控制器分開。從而同意為一個模型建立多個視圖。

將各方面問題分解開來考慮,簡化了系統設計。保證了系統的可擴展性。
C2風格
由構件和連接件兩種元素組成。構件可實現應用需求,並能將隨意復雜度的功能封裝在一起。全部構件之間的通信是通過以連接件為中介的異步消息交換機制來實現的。



6、試分析和比較B/S,二層C/S和三層C/S。指出各自的長處和缺點。


答:二層C/S體系結構將應用一分為二。server負責數據管理,客戶機完畢與用戶的交互任務。長處:
(1)C/S體系結構具有強大的數據操作的事務處理能力。模型思想簡單,易於人們理解和接受;(2)對軟硬件的變化有極大的適應性和靈活性,易於對系統進行擴充和縮小;
(3)將大的應用處理任務分布到很多通過網絡連接的低成本計算機上。以節約大量費用;
缺點:
(1)開發成本較高。
(2)client程序設計復雜。
(3)信息內容和形式單一;
(4)用戶界面風格不一,使用繁雜不易推廣。
(5)軟件移植困難;
(6)軟件維護和升級困難;
(7)新技術不能輕易應用。

三層CS在上面的基礎上進行了改造。並添加了一個應用server。
長處:
(1)同意合理的划分三層結構的功能,能提高系統和軟件的可維護性和可擴展性;
(2)具有良好的可升級性和開放性;
(3)應用的各層能夠並行開發。能夠選擇各自最適合的開發語言;
(4)為嚴格的安全管理奠定了堅實的基礎。

B/S風格就是上述三層應用結構的一種實現方式,其詳細結構為:瀏覽器/Webserver/數據庫server。
長處:
(1)基於B/S體系結構的軟件,系統安裝,改動和維護全在server端解決;
(2)提供了異種機,異種網。異種應用服務的聯機,聯網;
缺點:
(1)缺乏對動態頁面的支持能力,沒有集成有效的數據庫處理能力;
(2)在數據查詢等響應速度上,要遠遠低於C/S體系結構;
(3)系統擴展能力差。安全性難以控制;

7、請對MVC風格體系結構進行介紹,並說明該風格的優缺點。
答:模型-視圖-控制器風格常被稱為MVC風格,主要處理軟件用戶界面開發中所面臨的問題。將模型與視圖、控制器分開,從而同意為一個模型建立多個視圖
具有例如以下長處:
(1)將各方面問題分解開來考慮,簡化了系統設計,保證了系統的可擴展性;
(2)改變界面不影響應用程序的功能內核,使得系統易於演化開發,可維護性好;
(3)易於改變。甚至能夠在執行時改變,提供了良好的動態機制;
缺點:主要是僅局限在應用軟件的用戶界面開發領域中。

8、在正交軟件體系結構中。什么是全然正交結構?在實際使用時是不是必須嚴格遵守結構正交?使用正交軟件體系結構有什么長處?(期中)
答:假設線索是相互獨立的。即不同線索中的構件之間沒有相互調用,那么這個結構就是全然正交的。

在實際使用時不是必須嚴格遵守結構正交。
長處:
(1)結構清晰,易於理解。
(2)易改動。可維護性強;
(3)可移植性強。重用粒度大;


9、層次系統結構和基於消息的層次系統結構有什么差別?
答:層次結構將系統進行分級組織,其組織思想是:在層次結構中,每一層向上層提供服務。並作為客戶向下層請求服務。分層系統的長處:支持基於抽象程度遞增的系統設計;支持功能增強。支持重用。分層系統的缺點:並非每一個系統都能夠非常easy的划分為分層的模式,甚至即使是層次化的。出於性能的考慮,也不得不把一些低級或高級的功能綜合起來。非常難找到一個合適的、正確的層次抽象方法。


消息總線是系統的連接件、負責消息的分派、傳遞和過濾以及處理結果的返回。消息是構件之間通信的唯一方式。因為構件通過總線進行連接,並不要求各個構件具有同樣的地址空間或局限在一台機器上。因此該風格能夠非常好的刻畫分布式開發系統,以及CORBA.DCOM和EJB規范的系統。

10、體系結構描寫敘述語言與程序設計語言有什么差別?
答:ADL與其它的語言比較具有下面能力:
(1)構造能力:ADL可以使用較小的獨立體系結構元素來建造大型軟件系統;
(2)抽象能力:ADL使得軟件體系結構中的構件和連接件描寫敘述能夠僅僅關注他們的抽象特性。而無論其詳細的實現細節;
(3)重用能力:ADL使得組成軟件系統的構件,連接件甚至是軟件體系結構都成為軟件系統開發和設計的可重用部件;
(4)組合能力:ADL使得其描寫敘述的每一系統元素都有其自己的布局結構。這樣的描寫敘述布局結構的特點使得ADL支持軟件系統的動態變化組合;
(5)異構能力:ADL同意多個不同的體系結構描寫敘述關聯存在;
(6)分析和推理能力:ADL同意對其描寫敘述的體系結構進行多種不同的性能和功能上的多種推理分析;

11、ACME中定義了哪七種體系結構實體?ACME中的類型和風格是什么含義?
答:七種體系結構實體:構件、連接件、系統、port、角色、表述和表述映射。
體系結構描寫敘述一個重要能力就是可以定義系統的風格或族。風格同意我們定義領域特定或應用特定的設計詞匯,以及怎樣使用這些詞匯的約束,在ACME中。設計師可以定義三種類型,各自是屬性類型、結構類型和風格。

12、了解基於XML的軟件體系結構描寫敘述語言。
答:因為XML在體系結構描寫敘述上的很多長處,已經開發出不同的基於XML的體系結構描寫敘述語言,如XADL 2.0 、XBA、XCOBA。
XADL 2.0:具有非常好的擴展性。不是為了描寫敘述某一模型而建立的單一語言。而是對模型描寫敘述的集合。
XBA:把XML應用於軟件體系結構的描寫敘述。

利用XML的可擴展性,對現有的各種ADL進行描寫敘述及定義;
XCOBA:能夠動態的反映系統在執行時體系結構的相關信息,支持系統的精華和演化。支持基於構件的軟件開發方法和實現異構構件之間的通信。

13、簡要介紹Krutchten的“4+1”視圖模型。


答:Krutchten “4+I“視圖模型從5個不同的視角包含邏輯視圖,開發視圖,進程視圖。物理視圖和場景視圖來描寫敘述軟件體系結構。
(1)邏輯視圖主要支持系統的功能需求,即系統提供給終於用戶的服務。
(2)開發視圖要考慮軟件內部的需求,如軟件開發的easy性,軟件的重用和軟件的通用性;
(3)過程視圖側重於系統的執行特性,主要關注一些非功能性的需求。
(4)物理視圖主要考慮怎樣把軟件映射到硬件上,解決系統拓撲結構。系統安裝,通訊等問題 ;
(5)場景,通過它能夠將各種視圖聯系起來。描寫敘述不同視圖構件之間是怎樣作用的;

14、設計模式的基本成分有哪幾個?請簡介其各個基本成分。
答:設計模式的四個基本成分:名稱,問題,解決方式,后果。名稱通經常使用來描寫敘述一個設計問題,它的解法和后果,由1~2個詞組成。問題告訴我們什么時候使用設計模式、解釋問題及其背景。解決方式是描寫敘述設計的基本要素,它們的關系、各自的任務以及相互之間的合作。

后果描寫敘述應用設計模式后的結果和權衡。

15、為什么要評估軟件體系結構?從哪些方面評估軟件體系結構?
答:
原因:
軟件體系結構反映了系統最初始的設計決策,對相同一個問題。在初始階段糾正所帶來的花費和在測試或部署階段糾正導致的開銷不在一個數量級。
評估是挖掘隱形需求並將其補充到設計中的最后機會。
體系結構是開發過程的中心,不良體系結構會帶來糟糕的結果;
從下面幾方面進行評估:
(1)性能是指系統的影響能力。即要經過多長時間才干對某個事件做出響應,或者在某段事件內系統所能處理的事件的個數。
(2)可靠性是軟件系統在應用或系統錯誤面前,在意外或錯誤使用的情況下維持軟件系統的功能特性的基本能力;
(3)可用性是系統可以正常執行的時間比例;
(4)安全性是指系統在向合法用戶提供服務的同一時候可以阻止非授權用戶使用的企圖或拒絕服務的能力。
(5)可改動性是指可以高速的以較高的性能代價比對系統進行變更的能力;
(6)功能性是系統所能完畢所期望的工作的能力。
(7)可變性是指體系結構經擴充或變更而成為新體系結構的能力。
(8)可集成性是指系統能與其它系統協作的程度。
(9)互操作性是指與其它環境或者系統本身相互作用的能力;

16、軟件體系結構評估的主要方法有哪三種?請簡單解釋每種方法。
答:(1)基於調查或檢查表的評估方式:比較靈活,能夠用來評估多種質量屬性,也能夠在體系結構設計的多個階段進行。

可是因為評估的結果非常大程度來自評估人員的主觀猜測。因此不同的評估人員可能會產生不同的甚至是截然不同的結果,並且評估人員的對領域的熟悉程度、是否具有豐富的相關經驗也將是評估結果的重要因素;
(2)基於場景的評估方式:這樣的體系結構評估方式分析軟件體系結構對場景也就是對系統的使用或改變活動的支持程度。從而推斷該體系結構對這一場景所代表的質量需求的滿足程度;
(3)基於度量的評估方式:涉及三個基本活動:首先須要建立質量屬性和度量之間的映射原則,即確定如何從度量結果推出系統具有什么樣的質量屬性。然后從軟件體系結構文檔中獲取度量信息。最后依據映射原則分析推導出系統的某些質量屬性。基於度量的評估方式提供更為客觀和量化的質量評估;


17、SAAM和ATAM評估方法的基本步驟各自是什么?
答:SAAM步驟:
場景生成;
體系結構描寫敘述;
場景的分類和優先級確定。
間接場景的單獨評估。
對場景關聯的評估。
形成整體評估;

ATAM步驟:
介紹ATAM。
介紹商業動機;
介紹體系結構;
識別體系結構方法;
生成質量屬性效用樹。
分析體系結構方法。
頭腦風暴和設定場景優先級。
分析體系結構方法;
提供評估結果;

18、Web服務有哪些核心技術,這些技術是怎樣在Web服務中發揮作用的。
答:Web服務技術核心基於可擴展標記語言XML的標准。包含SOAP、WSDL、UDDI。
SOAP:採用HTTP作為底層通信協議,以RPC作為一致性的調用途徑,用XML作為傳輸數據格式,同意服務提供者和服務請求者通過防火牆在Internet環境下進行交互;
WSDL:定義了一套基於XML的語法,用來將Web Services描寫敘述為可以進行消息交換的服務訪問點的集合;
UDDI:基於Web的分布式的Web Services信息注冊中心的實現標准規范,同一時候也包括一組訪問協議的實現標准。使得企業能將自身的Web Services注冊上去,並讓別的企業能發現並訪問這些Web Services。

四、看圖答題(30分)
1、請依據P38圖3-5介紹黑板系統的組成。

答:
(1)知識源:特定應用程序知識的獨立散片;
(2)黑板數據結構:反映應用程序求解狀態的數據;
(3)控制器:控制(即對知識源的調用)是由黑板的狀態決定的;

2、請依據P59圖3-26解釋HMB風格的構件模型。(期中)

答:在圖3-26所看到的的構件模型中。左上方是構件的接口部分,一個構件能夠支持多個不同的接口。每一個接口定義了一組輸入和輸出的消息,刻畫了構件對外提供的服務以及要求的環境服務,體現了該構件同環境的交互。

右上方是用帶輸出的有限狀態自己主動機刻畫的構件行為。構件接收到外來消息后。依據當前所處的狀態對消息進行響應。並可能導致狀態的變遷。

下方是復合構件的內部結構定義。復合構件時由更簡單的子構件通過局部消息總線連接而成。消息總線為整個系統和各個層次的構件提供了統一的集成機制。



3、請依據P60圖3-27解釋消息總線的屬性和服務。(期中)

答:消息總線屬性:構件實例表,構件-消息響應登記表,消息過濾表。服務:消息登記,消息分派,消息傳遞,消息過濾。該圖的描寫敘述中,構件1向消息總線登記感興趣的消息。形成構件消息響應登記表。消息總線依據收到的消息的類型和構件——消息響應登記表的信息。定位傳遞該消息給對應的響應者。並負責返回處理結果。必要時。假設所接受的消息不是消息總線感興趣的消息時,消息總線還能夠對這些消息進行過濾和堵塞。


構件僅僅對消息本身感興趣。並不關心消息是怎樣產生的,消息的發出者和接收者不必知道彼此的情況。這使得構件之間的耦合度低。構件重用性好,構件的更換更easy。在一般的互聯接口定義的系統中,構件之間的連接是在要求的服務和提供的服務之間進行固定的匹配,而在HMB中,構件對外來消息進行響應后。可能會引起狀態的變遷。因此,一個構件在收到相同的消息后,在不同一時候刻所處的不同狀態下。可能會有不同的響應。

4、請依據P147圖5-2介紹體系結構設計方法的元模型。



答:元模型是對各種體系結構設計模型的抽象。圖中用圓角矩形表示概念,用連線表示概念之間的關聯,用菱形符號表示3~4個概念之間的關聯。
客戶:表示那些關心體系結構設計的系統相關人員;
需求規格說明:描寫敘述了所要開發的體系結構的系統需求;
制品:表示某一方法的制品描寫敘述;
解決方式抽象:定義了子結構的概念表示;
體系結構描寫敘述:定義了體系結構的規格說明;
領域知識:用於表示在解決某一問題中所用的知識范圍。

5、請依據P167圖6-1簡要介紹基於體系結構的軟件開發過程的各個步驟。並說明各個步驟的必要性何在?或者說,它們在軟件生命周期中都起到了什么作用?

答:本過程由下面步驟組成:
(1)導出體系結構需求:體系結構需求由開發組織創建,並受技術環境和體系結構設計師個人經驗的影響。

該步驟的輸出有3個:列舉功能需求;列舉特定體系結構需求。列舉質量場景集合。它為體系結構需求提供詳細測試;
(2)設計體系結構:一個體系結構設計師在開發體系結構時,先做出一些設計決定,然后通過考慮不同的體系結構構造和視圖來對這些設計決定進行分析。體系結構設計是一個迭代的過程,首先做出某些決策並進行分析,然后又一次考慮並又一次作決定,直到設計達到封閉;
(3)文檔化體系結構:體系結構的文檔是為支持程序設計人員和分析人員而設計的。它是加深各種系統相關人員之間通信交流程度的有效工具,並能從中導出體系結構需求。創建並維護體系結構文檔是長期性的軟件體系結構取得 成功的關鍵因素之中的一個。
(4)分析體系結構:確定潛在的風險,驗證所給出的設計可以處理所提出的質量需求,之所以要求外部評估人員的參與。是為了確保可以毫無偏見地進行檢查。並保證評估結果的可信性;
(5)實現體系結構:當把一個體系結構轉變成代碼。要考慮到各種經常使用的軟件project和項目管理知識:具體設計、編碼實現、測試、配置管理等。
(6)維護體系結構:對於體系結構來說。良好的文檔、良好的公布和良好的維護都很重要。假設缺少不論什么一方面的活動。那么體系結構將不可避免地偏離其初始原則;

6、請依據P207圖8-1分析服務提供者、服務請求者和服務注冊中心三者的作用,以及它們之間的工作流程。

答:
作用:
(1)服務提供者:公布自己的服務,而且對服務請求進行響應。
(2)服務注冊中心:注冊已公布的Web Services,對其進行分類。並提供搜索服務。
(3)服務請求者:利用服務注冊中心查找所需的服務,然后使用該服務。
工作流程:服務提供者托管可通過網絡訪問的軟件模塊,定義Web Services的服務描寫敘述並把它公布到服務注冊中心;服務請求者使用查找操作來從服務注冊中心檢索服務描寫敘述,然后使用服務描寫敘述與服務提供者進行綁定並調用Web Services實現或同它交互。

7、請依據P229圖8-11介紹 UDDI的詳細工作步驟。

 

答:
(1)軟件公司、標准化組織和程序猿定義了企業怎樣在UDDI中注冊的規划后,開始向UDDI注冊中心公布這些規則的描寫敘述信息。這些規則被稱為技術模型;
(2)企業向UDDI注冊中心注冊關於該企業及其提供的Web Services的描寫敘述;
(3)UDDI注冊中心會給每一個實體指定一個在相關程序中唯一的標識符。從而能夠隨時了解全部這些實體的當前情況;
(4)電子交易場所和搜索引擎等其它類型的客戶和商務應用程序使用UDDI注冊中心來發現他們感興趣的Web Services;
(5)其它的企業就能夠調用這些服務,方便、迅速地進行商務應用程序的動態集成;


一.填空題(10分)——自己整理
構件描寫敘述模型:
3C模型、REBOOT模型、青鳥構建模型。


構件分類方法:
keyword分類法、刻面分類法、超文本組織法。
軟件體系結構的發展歷程:
“無體系結構”設計階段、萌芽階段、0基礎階段、高級階段。
經典軟件體系結構風格:
管道—過濾器風格。
數據抽象和面向對象風格;
基於事件的隱式調用風格;
層次系統風格;
倉庫風格和黑板風格;
MVC風格。
解釋器風格;
C2風格。
典型的軟件體系結構描寫敘述語言:
UniCon
C2
Wright
ACME
基於XML的體系結構描寫敘述語言:
XADL 2.0
XBA
XCOBA
“4+1”模型由5個視圖組成:
邏輯視圖
過程視圖
物理視圖
開發視圖
場景
設計模式的基本成分:
模式名稱、問題、解決方式、后果。
體系結構設計方法:
制品驅動的方法。
用例驅動的方法;
領域驅動的方法;
模式驅動的方法。
軟件體系結構評估普遍關注的質量屬性:
性能
可靠性
可用性
安全性
可改動性
功能性
可變性
可集成性
互操作性
軟件體系結構評估的主要方式:
基於調查問卷或檢查表的評估方式。
基於場景的評估方式;
基於變量的評估方式;
軟件體系結構定義:
軟件體系結構={構件,連接件。約束}
Web Services體系結構基於三種角色:
服務提供者、服務注冊中心、服務請求者。
SOA(面向服務的體系結構)是一個Web Services的體系結構。共同擁有三種角色:服務提供者、服務注冊中心、服務請求者。
3C模型:
Concept:概念
Content:內容
Context:語境
軟件體系結構描寫敘述方法:(期中)
圖形表達工具
模塊內連接語言
基於軟構件的系統描寫敘述語言
ADL
軟件體系結構描寫敘述框架標准


github主頁:https://github.com/chenyufeng1991  。

歡迎大家訪問。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM