【正文】 always_generate ExclSet； received_messages ReuestWithdrawal always_generate null； received_messages MarkMtg always_generate null； end Attendee； 第四章 軟件體系結(jié)構(gòu)描述 典型軟件體系結(jié)構(gòu)描述語(yǔ)言 ◇ C2對(duì) ImportantAttendee構(gòu)件的描述 ponent ImportantAttendee is subtype Attendee(in and beh) interface bottom_domain is out LocPrefs(l:loc_type)； ExclSet(e:date_mg)； EquipReqts(eq:equip_type)； in GetLocPrefs()； behavior received_messages GetLocPrefs always_generate LocPrefs； end ImportantAttendee； 第四章 軟件體系結(jié)構(gòu)描述 典型軟件體系結(jié)構(gòu)描述語(yǔ)言 ◇ C2對(duì)體系結(jié)構(gòu)的描述 architecture MeetingScheduler is conceptual_ponents Attendee； ImportantAttendee； MeetingInitiator； connectors connector MainConn is message_filter no_filtering； connector AttConn is message_filter no_filtering； connector ImportantAttConn is message_filter no_filtering； architectural_topology connector AttConn connections top_ports Attendee； bottom_ports MainConn； connector ImportantAttConn connections top_ports ImportantAttendee； bottom_ports MainConn； connector MainConn connections top_ports AttConn； ImportantAttConn； bottom_ports MeetingInitiator； end MeetingScheduler； 第四章 軟件體系結(jié)構(gòu)描述 典型軟件體系結(jié)構(gòu)描述語(yǔ)言 ◇ C2對(duì)會(huì)議安排系統(tǒng)的描述 system MeetingScheduler_1 is architecture MeetingScheduler with Attendee instance Att_1， Att_2， Att_3； ImportantAttendee instance ImpAtt_1， ImpAtt_2； MeetingInitiator instance MtgInit_1； end MeetingScheduler_1； 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)與 UML ◇ UML簡(jiǎn)介 ◎ UML(Unified Modeling Language)是下面這些最好的建模方法中最好部分的集成 : ◇ 商務(wù)流程模型 (Work Flow) ◇ 對(duì)象建模方法 ◇ 軟構(gòu)件建模思想 ◎ UML是一種用可視化方法對(duì)軟件系統(tǒng)進(jìn)行描述、實(shí)施和說(shuō)明的標(biāo)準(zhǔn)語(yǔ)言。 ◎ 在 C2中 ， 連接件負(fù)責(zé)構(gòu)件之間消息的傳遞 ， 而構(gòu)件維持狀態(tài) 、 執(zhí)行操作并通過(guò)兩個(gè)名字分別為 “ top”和“ bottom”的端口和其它的構(gòu)件交換信息 。 構(gòu)件之間不能發(fā)送消息 ， 必須通過(guò)連接件 。 一 方 面：體系結(jié)構(gòu)描述如何向其他文檔轉(zhuǎn)移； 另一方面：如何利用需求分析成果來(lái)直接生成系統(tǒng)的 體系結(jié)構(gòu)說(shuō)明。 異構(gòu)連接。 ◇ ADL與其他語(yǔ)言的比較 (2) 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)描述語(yǔ)言 ◎ ADL與需求語(yǔ)言的區(qū)別：后者描述的是問(wèn)題空間 ， 而前者扎根于解空間 。 主要的體系結(jié)構(gòu)描述語(yǔ)言有 Aesop、 MetaH、 C Rapide、SADL、 Unicon和 Wright等 ， 盡管它們都描述軟件體系結(jié)構(gòu) ， 卻有不同的特點(diǎn) 。 ◇ Rational 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)描述框架標(biāo)準(zhǔn) ◎ Rational起草了可重用的軟件資產(chǎn)規(guī)格說(shuō)明 ， 專門討論了體系結(jié)構(gòu)描述的規(guī)格說(shuō)明 ， 提出了一套易于重用的體系結(jié)構(gòu)描述規(guī)范 。 ADL使得系統(tǒng)開(kāi)發(fā)者能夠很好地描述他們?cè)O(shè)計(jì)的體系結(jié)構(gòu)，以便與他人交流，能夠用提供的工具對(duì)許多實(shí)例進(jìn)行分析。 ◎ MIL方式對(duì)模塊化的程序設(shè)計(jì)和分段編譯等程序設(shè)計(jì)與開(kāi)發(fā)技術(shù)確實(shí)發(fā)揮了很大的作用 。第 4章 軟件體系結(jié)構(gòu)描述和設(shè)計(jì) 本章結(jié)構(gòu) 軟件體系結(jié)構(gòu)描述方法 軟件體系結(jié)構(gòu)描述框架標(biāo)準(zhǔn) 體系結(jié)構(gòu)描述語(yǔ)言 典型的軟件體系結(jié)構(gòu)描述語(yǔ)言 （ C2） 軟件體系結(jié)構(gòu)與 UML 可擴(kuò)展標(biāo)記語(yǔ)言 基于 XML的軟件體系結(jié)構(gòu)描述語(yǔ)言 軟件體系結(jié)構(gòu)的設(shè)計(jì) 引言 當(dāng)前對(duì)軟件體系結(jié)構(gòu)的描述在很大程度上還停留在非形式化的基礎(chǔ)上，依賴于軟件設(shè)計(jì)師個(gè)人的經(jīng)驗(yàn)和技巧。 但是由于這些語(yǔ)言處理和描述的軟件設(shè)計(jì)開(kāi)發(fā)層次過(guò)于依賴程序設(shè)計(jì)語(yǔ)言 ， 因此限制了它們處理和描述比程序設(shè)計(jì)語(yǔ)言元素更為抽象的高層次軟件體系結(jié)構(gòu)元素的能力 。 對(duì)于 ADL現(xiàn)在也是無(wú)統(tǒng)一認(rèn)識(shí)。 該建議草案已經(jīng)提交 OMG。 這些 ADL強(qiáng)調(diào)了體系結(jié)構(gòu)不同的側(cè)面 ， 對(duì)體系結(jié)構(gòu)的研究和應(yīng)用起到了重要的作用 ， 但也有負(fù)面的影響 。 ◎ ADL與建模語(yǔ)言的區(qū)別：后者對(duì)整體行為的關(guān)注要大于對(duì)部分的關(guān)注 ， 而 ADL集中在構(gòu)件的表示上 。 連接件包含的屬性：角色。 現(xiàn)在的 ADL大多與領(lǐng)域相關(guān)。 構(gòu)件之間的通信只能通過(guò)消息傳遞來(lái)實(shí)現(xiàn) ， 不允許使用共享內(nèi)存方式通信 。 ◎ 每個(gè)接口包含一種可發(fā)送的消息和一組可接收的消息 。 ◎ 支持用不同實(shí)現(xiàn)技術(shù)進(jìn)行的軟件開(kāi)發(fā)全過(guò)程。通常，狀態(tài)圖是對(duì)類圖的補(bǔ)充 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)與 UML ◇ 活動(dòng)圖 描述滿足用例要求所要進(jìn)行的活動(dòng)以及活動(dòng)間的約束關(guān)系，有利于識(shí)別并行活動(dòng) 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)與 UML ◇ 構(gòu)件圖 描述代碼構(gòu)件的物理結(jié)構(gòu)及各構(gòu)件之間的依賴關(guān)系 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)與 UML ◇ 部署圖 部署圖定義系統(tǒng)中軟硬件的物理體系結(jié)構(gòu) 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)與 UML ◇ 直接使用 UML建模 元 元模型元模型模型用戶對(duì)象UML的四層元模型體系結(jié)構(gòu) 。 三部分不是相互獨(dú)立的 ， 而是相互交叉重疊 、 緊密相連 ， 共同構(gòu)成了 UML的完整語(yǔ)義 。E x c l S e t ( d a t e _ m g ) 。PrefSet(date_mg)。文檔本身只說(shuō)明文檔包括什么標(biāo)記，而不是說(shuō)明文檔看起來(lái)是什么樣的。抽象有幾種形式，如數(shù)據(jù)抽象、對(duì)象抽象、實(shí)體抽象、行為抽象、過(guò)程抽象、虛擬機(jī)抽象等。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 體系結(jié)構(gòu)設(shè)計(jì)的原則 這條原理是眾所周知的，它來(lái)自古時(shí)的政治，也來(lái)自諸如歸并分類的組合算法。例如，通過(guò)對(duì)象、模塊設(shè)計(jì)和訪問(wèn)接口設(shè)計(jì)分別提供了這兩種封裝。例如，在一個(gè)應(yīng)用中為了提高運(yùn)行性能，可能需要對(duì)某一部件的內(nèi)部數(shù)據(jù)結(jié)構(gòu)進(jìn)行直接訪問(wèn)；而在另外一個(gè)應(yīng)用中，可能因?yàn)閷?duì)其性能已經(jīng)滿意了，就不需要對(duì)其數(shù)據(jù)的直接訪問(wèn)了。耦合強(qiáng)調(diào)模塊之間的特征，而內(nèi)聚強(qiáng)調(diào)模塊內(nèi)部的特性。其他形式的內(nèi)聚還有：邏輯內(nèi)聚、時(shí)間內(nèi)聚、過(guò)程內(nèi)聚、通信內(nèi)聚、順序內(nèi)聚和不規(guī)則內(nèi)聚。 實(shí)現(xiàn)部件負(fù)責(zé)全面規(guī)范算法的執(zhí)行，執(zhí)行中不需要對(duì)上下文相關(guān)信息進(jìn)行決策。 實(shí)現(xiàn)部分包括了實(shí)現(xiàn)部件所提供功能的實(shí)際代碼。如果部件的接口和實(shí)現(xiàn)分離，那么它就更容易在系統(tǒng)中進(jìn)行改變。 解決方案領(lǐng)域知識(shí)是指提供領(lǐng)域概念的知識(shí)。 客戶：表示那些關(guān)心軟件體系結(jié)構(gòu)設(shè)計(jì)的系統(tǒng)相關(guān)人員。一般，每種工件都有一套與之相關(guān)的試探法，用來(lái)標(biāo)識(shí)相關(guān)的工件實(shí)例。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 工件驅(qū)動(dòng)（ artifactdriven）的方法 工件驅(qū)動(dòng)的體系結(jié)構(gòu)設(shè)計(jì)方法的例子包括廣為流行的面向?qū)ο蠓治龊驮O(shè)計(jì)方法 OMT和 OAD。參與者通過(guò)用例使用系統(tǒng)。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 用例驅(qū)動(dòng)（ usecasedriven）的方法 在需求工作流中，以用例的形式捕捉客戶的需求，構(gòu)成用例模型。用例實(shí)現(xiàn)決定了任務(wù)在系統(tǒng)內(nèi)部是怎樣進(jìn)行的。 （ 2）對(duì)于如何選擇與體系結(jié)構(gòu)相關(guān)的用例沒(méi)有提供系統(tǒng)的支持。 為了進(jìn)行體系結(jié)構(gòu)描述，需要選擇與體系結(jié)構(gòu)相關(guān)的用例。用例主要關(guān)注的是系統(tǒng)的問(wèn)題域和外部行為。 ◇ 用例驅(qū)動(dòng)（ usecasedriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 模式驅(qū)動(dòng)（ patterndriven）的方法 體系結(jié)構(gòu)模式關(guān)心的是體系結(jié)構(gòu)級(jí)別的元素及其交互。主要由 4個(gè)概念組成： ●意圖：表示使用模式的基本原則； ●上下文：表示問(wèn)題的產(chǎn)生環(huán)境； ●問(wèn)題：表示上下文環(huán)境中經(jīng)常出現(xiàn)的問(wèn)題； ●解決方案：是以元素及其關(guān)系的抽象描述的形式來(lái)表示對(duì)問(wèn)題的解決方案。 （ 4）對(duì)于模式的組合沒(méi)有提供很好的支持。 為了簡(jiǎn)化對(duì)模式的選擇和管理，改進(jìn)對(duì)模式的理解，人們通常把具有共同特點(diǎn)的模式分類到相同的組中。 ◇ 模式驅(qū)動(dòng)（ patterndriven）的方法 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) 例如，對(duì)于一個(gè)給定的問(wèn)題，選擇使用管道－過(guò)濾器模式。分別對(duì)這些模式進(jìn)行定義并不能表示出模式之間的相關(guān)性。 一些領(lǐng)域驅(qū)動(dòng)的體系結(jié)構(gòu)設(shè)計(jì)方法把領(lǐng)域解釋成問(wèn)題領(lǐng)域。盡管解決方案領(lǐng)域分析提供了對(duì)整個(gè)領(lǐng)域建模的潛力，而且這種潛力對(duì)于導(dǎo)出領(lǐng)域體系結(jié)構(gòu)是必需的，但是，這并不足以驅(qū)動(dòng)體系結(jié)構(gòu)設(shè)計(jì)過(guò)程。這種情況下，全面的解決方案領(lǐng)域分析對(duì)于提供穩(wěn)定的抽象也可能是不夠充分的，因?yàn)榻鉀Q方案領(lǐng)域中的概念自身也存在著波動(dòng)。 一般來(lái)講，體系結(jié)構(gòu)的確定應(yīng)當(dāng)在分析和設(shè)計(jì)階段之前或之后完成。 除此之外，需求自身也可能被不正確的描述，既有可能提出過(guò)度要求，也有可能要求不足。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 小結(jié) （ 3）難以適度控制領(lǐng)域模型 領(lǐng)域驅(qū)動(dòng)的方法和用例驅(qū)動(dòng)的方法在構(gòu)造軟件體系結(jié)構(gòu)時(shí)都用到了領(lǐng)域模型。但是，這可能會(huì)帶來(lái)項(xiàng)目的不可管理性，因?yàn)轫?xiàng)目的許多開(kāi)發(fā)過(guò)程將無(wú)法得到體系結(jié)構(gòu)的指導(dǎo)。這些方法被分類為：工件驅(qū)動(dòng)的、用例驅(qū)動(dòng)的、模式驅(qū)動(dòng)的和領(lǐng)域驅(qū)動(dòng)的。首先，解決方案領(lǐng)域分析并不是為軟件體系結(jié)構(gòu)設(shè)計(jì)而定義的，而是為實(shí)現(xiàn)軟件開(kāi)發(fā)等活動(dòng)中的系統(tǒng)資源重用而定義的。類似于用例那樣，場(chǎng)景關(guān)注的也是問(wèn)題領(lǐng)域和系統(tǒng)的外部行為。假設(shè)在某問(wèn)題中，經(jīng)過(guò)問(wèn)題分析階段之后，我們認(rèn)為要組合使用分層模式、管道－過(guò)濾器模式和倉(cāng)庫(kù)模式。過(guò)濾器接收輸入數(shù)據(jù)，進(jìn)行處理，提供輸出數(shù)據(jù)；管道在一個(gè)過(guò)濾器的輸出和另一個(gè)過(guò)濾器的輸入之間發(fā)送數(shù)據(jù)。這樣，對(duì)于同一問(wèn)題，可能有多種體系結(jié)構(gòu)模式可供選擇。 對(duì)于模式驅(qū)動(dòng)的體系結(jié)構(gòu)設(shè)計(jì)方法而言，必要的條件之一是有充足的模式庫(kù)可用。如果發(fā)現(xiàn)一個(gè)模式的意圖和給出的問(wèn)題相關(guān)，那么就分析它的上下文描述。 第四章 軟件體系結(jié)構(gòu)描述 軟件體系結(jié)構(gòu)的設(shè)計(jì) ◇ 模式驅(qū)動(dòng)（ patterndriven）的方法 軟件工業(yè)界已經(jīng)廣泛接受了軟件設(shè)計(jì)模式的概念。因此，即使確定了所有的相關(guān)用例，從用例模型確定體系結(jié)構(gòu)抽象仍將是