第7章 設計與實現

1、1第七章 設計與實現本章的目標是介紹運用UML進行面向對象軟件設計,并了解系統實現時的問題。 l 理解一般的面向對象設計過程中最重要的活動;l 理解用于記錄面向對象設計的一些不同的模型;l 知道設計模式的思想,以及如何將其用于設計知識和經驗的復用;l 了解實現軟件時需要考慮的關鍵因素,包括軟件復用和開源開發(fā)。 軟件設計和實現是軟件工程過程中的一個階段,在此階段開發(fā)出可執(zhí)行的軟件系統。對簡單的系統來說,軟件設計和實現就是軟件過程的全部,其他的所有活動都融匯在這個過程中。但是,對于大型的系統,軟件設計和實現只是一系列軟件工程過程(如需求工程、檢驗和有效性驗證等)中的一個。47.1 利用UML進行面

2、向對象設計1 系統上下文和與系統外部的交互系統上下文和與系統外部的交互2 體系結構的設計體系結構的設計3 對象識別對象識別4 設計模型設計模型5 對象接口描述對象接口描述4 統一建模語言（UML）提供對面向對象設計的廣泛支持。開發(fā)系統設計的過程，就是由概念設計轉變?yōu)樵敿毜拿嫦驅ο蟮脑O計,需要完成如下幾個步驟:案例1：“野外氣象站系統”面向對象的設計Wilderness weather station野外氣象站系統是一個數據收集系統，收野外氣象站系統是一個數據收集系統，收集偏遠地區(qū)的天氣條件數據的實時系統。集偏遠地區(qū)的天氣條件數據的實時系統。 野外氣象站隸屬于氣象制圖系統中的一個子系野外氣象站隸

3、屬于氣象制圖系統中的一個子系統。該系統自動地收集氣象數據來生成氣象圖。統。該系統自動地收集氣象數據來生成氣象圖。以以“野外氣象站系統野外氣象站系統”這個案例的設計部這個案例的設計部分來講解面向對象的設計活動。分來講解面向對象的設計活動。氣象站子系統設計過程氣象站子系統設計過程氣象制圖系統氣象制圖系統是一個復雜的系統。以其中是一個復雜的系統。以其中的的氣象站子系統氣象站子系統的面向對象設計過程為例的面向對象設計過程為例進行面向對象設計過程的說明。進行面向對象設計過程的說明。面向對象面向對象設計過程階段如下：設計過程階段如下：1.了解并定義上下文和系統的外部交互了解并定義上下文和系統的外部交互2.

4、設計系統體系結構設計系統體系結構3.識別出系統中的主要對象識別出系統中的主要對象4.開發(fā)設計模型開發(fā)設計模型5.描述對象接口描述對象接口step1 系統上下文建模型系統上下文建模型目的：了解待開發(fā)軟件和外部環(huán)境之間存在的目的：了解待開發(fā)軟件和外部環(huán)境之間存在的關系，決定系統所需要具備的功能；決定系統關系，決定系統所需要具備的功能；決定系統的構成，以便它能有效地與環(huán)境進行通信。的構成，以便它能有效地與環(huán)境進行通信。 采用從外部的觀點描述應用采用從外部的觀點描述應用從系統的用戶和操從系統的用戶和操作員的觀點進行描述。這樣描述，就是在定義系統作員的觀點進行描述。這樣描述，就是在定義系統的上下文（的上

5、下文（Context）。）。使用關聯模型表示系統的靜態(tài)體系結構使用關聯模型表示系統的靜態(tài)體系結構用關聯來表示實體之間的關系，只需用簡單的用關聯來表示實體之間的關系，只需用簡單的方框圖，就能描述系統總的體系結構。方框圖，就能描述系統總的體系結構。系統上下文的描述方法系統上下文的描述方法每個氣象站所在環(huán)境中的系統都包含氣象信息系統、機載衛(wèi)星系統和控制系統。連線上的基數關系說明環(huán)境中有一個控制系統,但有多個氣象站,以及一個衛(wèi)星和一個通用氣象信息系統。用例模型實現對系統中的交互建模使用使用UML中的用例模型可以實現對系統和中的用例模型可以實現對系統和環(huán)境的交互建模環(huán)境的交互建模用用例模型建立系統和環(huán)境

6、間的交互模型。用用例模型建立系統和環(huán)境間的交互模型。氣象站的用例模型給出了通過氣象站與外部實氣象站的用例模型給出了通過氣象站與外部實體間的交互來開啟和關閉、上報采集的數據、體間的交互來開啟和關閉、上報采集的數據、儀器測試和校準。儀器測試和校準。氣象站系統的用例模型氣象站系統的用例模型用例圖用例圖能用簡單能用簡單的自然語言來描述的的自然語言來描述的交互過程，這有助于交互過程，這有助于識別系統中的對象和識別系統中的對象和操作。操作。只有結合用例描述的只有結合用例描述的用例圖才能表達豐富用例圖才能表達豐富的含義。見下頁。的含義。見下頁。從這個報告用例中可以看出：從這個報告用例中可以看出：1.需要一個

7、代表采集天氣數據的儀器對象需要一個代表采集天氣數據的儀器對象2.需要一個代表對天氣數據總結的對象需要一個代表對天氣數據總結的對象3.還需要兩個操作還需要兩個操作請求氣象數據的操作和發(fā)送氣象數據請求氣象數據的操作和發(fā)送氣象數據的操作。的操作。 step2體系結構的設計體系結構的設計設計體系結構的前提條件設計體系結構的前提條件1.完成軟件系統中的交互設計完成軟件系統中的交互設計2.完成系統環(huán)境的定義完成系統環(huán)境的定義3.具備有關體系結構設計的一般性知識和具備有關體系結構設計的一般性知識和具體的領域知識。具體的領域知識。如何考慮系統的非功能性需求如何考慮系統的非功能性需求?1.用例與基于用例的模型主

8、要注重的是功能性設計用例與基于用例的模型主要注重的是功能性設計在大多數面向對象方法中，都通過用例來獲取系統的在大多數面向對象方法中，都通過用例來獲取系統的所需功能性需求。所需功能性需求。2.用例設計之后是體系結構設計。用例設計之后是體系結構設計。n體系結構是確保滿足非功能需求（如可維護性、效體系結構是確保滿足非功能需求（如可維護性、效率和可靠性）的主要工具。率和可靠性）的主要工具。3.一個良好的設計，應該同時采用用例和其他獲取功能一個良好的設計，應該同時采用用例和其他獲取功能性需求的方法，并通過使用構架產生一個符合非功能性需求的方法，并通過使用構架產生一個符合非功能需求的設計。需求的設計。氣象

9、站系統的高層體系結構非功能需求考慮子系統之間的可靠的互聯和通信實時操作的支持氣象站系統的高層體系結構分布式體系結構這種體系結構的主要優(yōu)點在于它易于支持不同配置的子系統,因為消息的發(fā)送方無需特別指定消息的接收子系統。數據采集系統體系結構Transmitter和Receiver對象與通信管理有關，WeatherData對象封裝儀器采集的信息并將其傳輸給氣象信息系統。這種結構屬于生產者-消費者模式,。step3對象類的識別對象類的識別體系結構的設計過程，也是識別對象類的過程。體系結構的設計過程，也是識別對象類的過程。如何識別對象類如何識別對象類 ？1.對系統的自然語言描述做文法分析。對系統的自然語言

10、描述做文法分析。對象和屬性是名詞，操對象和屬性是名詞，操作或服務是動詞作或服務是動詞 2.使用應用領域中的真實實體名字。使用應用領域中的真實實體名字。例如飛機、職務（管理者）、事件（請求）、交互（會例如飛機、職務（管理者）、事件（請求）、交互（會議）、位置（辦公室）、機構單元（公司）議）、位置（辦公室）、機構單元（公司）現存系統的信息存儲結構可以用來識別對象?，F存系統的信息存儲結構可以用來識別對象。3.基于情景（用例）的分析識別基于情景（用例）的分析識別識別出系統使用的各個情景，分析情景，識別出需要的識別出系統使用的各個情景，分析情景，識別出需要的對象、屬性和操作。對象、屬性和操作。識別氣象站

11、系統中的對象類識別氣象站系統中的對象類一個氣象站系統是一套用來控制一些設備的軟件包，通過儀器收集氣象數據，并進行數據處理、結果傳輸給氣象系統以便進一步處理。該儀器包括空中和地表溫度計（ thermometersthermometers ），風速計（ anemometeranemometer ），風向標（ wind vanewind vane ），氣壓計（ barometerbarometer）。數據定期收集。當發(fā)出一個命令傳輸氣象數據，氣象站的數據采集過程和總結。綜述數據傳輸到計算機時，收到請求映射。氣象站系統中的對象類氣象站系統中的對象類step4設計模型設計模型設計模型是系統需求和系統實現

12、之間的橋設計模型是系統需求和系統實現之間的橋梁梁1.描述系統中包含的對象或對象類，以及它們描述系統中包含的對象或對象類，以及它們之間的不同類型關系。之間的不同類型關系。2.對設計模型進行抽象，刪去模型與系統需求對設計模型進行抽象，刪去模型與系統需求之間的不必要的細節(jié)關聯之間的不必要的細節(jié)關聯3.消除相互沖突的需求消除相互沖突的需求在不同細節(jié)層次開發(fā)在不同細節(jié)層次開發(fā)不同的模型不同的模型 。4.為程序員提供充分的細節(jié)。為程序員提供充分的細節(jié)。系統描述者、設計者和程序員之間存在直接或系統描述者、設計者和程序員之間存在直接或間接的聯系。間接的聯系。設計的一個重要步驟是要決定需要什么樣的設設計的一個重

13、要步驟是要決定需要什么樣的設計模型和設計模型的細節(jié)層次計模型和設計模型的細節(jié)層次依賴所開發(fā)依賴所開發(fā)的系統類型。的系統類型。 順序數據處理系統和嵌入式實時系統需要使用不順序數據處理系統和嵌入式實時系統需要使用不同的設計模型。同的設計模型。減少模型使用的數量可降低設計的成本和完成減少模型使用的數量可降低設計的成本和完成設計過程所需要的時間。設計過程所需要的時間。 系統設計中注意的問題系統設計中注意的問題1.靜態(tài)模型靜態(tài)模型通過系統對象類及其之間的通過系統對象類及其之間的關系來描述系統的靜態(tài)結構。關系來描述系統的靜態(tài)結構。 在這一階段需要記錄的重要關系有泛化關在這一階段需要記錄的重要關系有泛化關系

14、、使用系、使用/被使用關系和組成關系。被使用關系和組成關系。2.動態(tài)模型動態(tài)模型描述系統的動態(tài)結構和系統描述系統的動態(tài)結構和系統對象（不是對象類）之間的交互。對象（不是對象類）之間的交互。 需要記錄的交互包括由對象請求的服務序列以需要記錄的交互包括由對象請求的服務序列以及系統狀態(tài)與這些對象交互之間的關聯方式。及系統狀態(tài)與這些對象交互之間的關聯方式。兩類設計模型兩類設計模型本系統中用到的幾種模型1.子系統模型子系統模型說明對象的邏輯分組，每個分組構說明對象的邏輯分組，每個分組構成一個子系統。使用類的圖表格式來表示，每個成一個子系統。使用類的圖表格式來表示，每個子系統是一個包的形式存在。子系統模型

15、是靜態(tài)子系統是一個包的形式存在。子系統模型是靜態(tài)模型。模型。2.序列模型序列模型說明對象交互的序列。使用說明對象交互的序列。使用UML序列序列或協作圖來表示。序列模型是動態(tài)模型?；騾f作圖來表示。序列模型是動態(tài)模型。3.狀態(tài)機模型狀態(tài)機模型說明單個對象如何響應事件來改變說明單個對象如何響應事件來改變它們的狀態(tài)。它們使用它們的狀態(tài)。它們使用UML的狀態(tài)圖來表示。的狀態(tài)圖來表示。子系統模型是一種最有幫助的靜態(tài)模型，因為它說子系統模型是一種最有幫助的靜態(tài)模型，因為它說明了設計如何由一組邏輯上相關聯的對象來構成。明了設計如何由一組邏輯上相關聯的對象來構成。序列圖：記錄對象交互發(fā)生的序列1.參與交互的對象

16、水平地排列，每個對象有一條垂直的參與交互的對象水平地排列，每個對象有一條垂直的線條與之連接。線條與之連接。2.時間以垂直方向表示，時間的進展是沿著垂直的虛線時間以垂直方向表示，時間的進展是沿著垂直的虛線向下。向下。3.對象之間的交互表示為帶有標號的箭頭，該箭頭是與對象之間的交互表示為帶有標號的箭頭，該箭頭是與垂直線段相連的。注意：這些不是數據流，而是表示垂直線段相連的。注意：這些不是數據流，而是表示交互中的基本消息或事件。交互中的基本消息或事件。4.對象生命線上的細長方形表示這個對象是系統中控制對象生命線上的細長方形表示這個對象是系統中控制對象的時間。在這個長方形的頂端時刻接管控制，在對象的時

17、間。在這個長方形的頂端時刻接管控制，在長方形的底部放棄控制。長方形的底部放棄控制。氣象站系統中數據采集的操作序列圖氣象站系統中數據采集的操作序列圖該圖給出了當外部制圖系統從氣象站請求數據時的交互該圖給出了當外部制圖系統從氣象站請求數據時的交互序列。序列。 氣象站系統中數據采集的操作序列圖氣象站系統中數據采集的操作序列圖數據收集系統的對象：數據收集系統的對象： 1.satComms對象接收從氣象信息系統發(fā)來的天氣報告請求對象接收從氣象信息系統發(fā)來的天氣報告請求,并發(fā)出收到回復。已發(fā)消息中的實線箭頭表明外部系統并并發(fā)出收到回復。已發(fā)消息中的實線箭頭表明外部系統并不等待回復不等待回復,繼續(xù)進行其他處

18、理。繼續(xù)進行其他處理。 2.satComms通過衛(wèi)星鏈接向通過衛(wèi)星鏈接向WetherStation發(fā)送消息發(fā)送消息,創(chuàng)建創(chuàng)建一個采集氣象數據的匯總。一個采集氣象數據的匯總。 3.WeatherStation向向CommsLink對象發(fā)送包含數據匯總的消對象發(fā)送包含數據匯總的消息。這里的虛線箭頭表明息。這里的虛線箭頭表明WeathStation對象類的實例會等對象類的實例會等待回復。待回復。 4.CommsLink調用調用WeatherData對象中的對象中的summarize方法并方法并等待回復。等待回復。 5.計算出氣象數據匯總并通過計算出氣象數據匯總并通過CommsLink對象返回給對象返

19、回給WeatherStation。 6. WeatherStation 調用調用Satcomms對象對象,通過衛(wèi)星通信系統通過衛(wèi)星通信系統將匯總數據傳輸給氣象信息系統將匯總數據傳輸給氣象信息系統。狀態(tài)機模型狀態(tài)機模型狀態(tài)機模型表示單個對象對不同事件的響應行狀態(tài)機模型表示單個對象對不同事件的響應行為為示例：示例：Weather Station對象的狀態(tài)圖，它給出對象的狀態(tài)圖，它給出了該對象如何響應各種不同服務的請求。了該對象如何響應各種不同服務的請求。Shutdown/停機停機Transmission/傳輸傳輸Summarising/求和求和氣象站的狀態(tài)圖氣象站的狀態(tài)圖 氣象站系統的狀態(tài)圖描述了

20、氣象站對象是如何對請求的各種服務進行響應的。狀態(tài)圖的必要性 狀態(tài)圖是一種很有用的系統或對象操作的高層模型。并不是所有的系統對象都需要狀態(tài)圖。很多系統對象相對簡單，使用狀態(tài)圖反而給設計增加了不必要的細節(jié)。step5接口描述接口描述什么是接口（什么是接口（Interface）？）？“接口接口”只是一個標識，它是系統對外部所具有只是一個標識，它是系統對外部所具有的行為的一個映射的行為的一個映射外部可得到的方法。外部可得到的方法。結合系統的內部，每個接口代表某些相關的系統結合系統的內部，每個接口代表某些相關的系統功能子集功能子集內部可作用的功能內部可作用的功能 。接口描述需要定義服務的標記和語義需要定

21、義服務的標記和語義接口可以用接口可以用UML中與類圖一樣的符號來描述，但沒有屬性部分。中與類圖一樣的符號來描述，但沒有屬性部分。UML的格式標記的格式標記要包含在名字部分要包含在名字部分中。中。 對象接口設計關心的是如何詳細描述一個對象或對象接口設計關心的是如何詳細描述一個對象或一組對象的接口細節(jié)。一組對象的接口細節(jié)。氣象站系統的接口7.3 實現問題實現階段主要完成軟件的可執(zhí)行版本。主要工作就是編寫代碼。參見編程規(guī)范，按要求編寫程序。代碼實現中的幾個問題1.復用 多數現代軟件都是對現有組件或系統的復用。開發(fā)一個軟件時,應該盡可能地多的使用現有代碼。2.配置管理 開發(fā)過程中,每個生成的軟件組件都

22、會有很多不同版本,如果沒有很好地在配置管理系統中追蹤這些版本,有可能在系統中使用錯誤版本的組件。3.宿主機-目標機開發(fā) 軟件產品通常不會在與軟件開發(fā)環(huán)境相同的計算機上運行。更多的是開發(fā)時使用一臺計算機(宿主機),運行時使用另一臺計算機(目標機)。宿主機和目標機的系統也有可能是一樣的類型,但是更經常是完全不同的環(huán)境。1 復用的層次1.抽象層 ：該層中并不是直接復用軟件,而是運用軟件設計中的成功抽象。抽象知識復用的代表方式是設計模式和體系結構模式。2.對象層 ：在這一層可直接復用庫中的對象,代替自己編寫代碼。實現這類復用時,必須妄到一個合適的庫,分析對象和方法是否提供所需的功能。3.組件層 ：組件

23、是一組通過相互合作實現相關功能和服務的對象及對象類集合,通常需要增加自己的代碼對組件進行調整和擴展。4.系統層：在這一層,我們復用整個應用系統。通常涉及這些系統的相關配置。通過添加和修改代碼(如果復用的是軟件的生產線)或者通過使用系統自身的配置界面。2 配置管理配置管理包含如下3個基本活動:1.版本管理2.系統集成3.問題追蹤3 宿主機-目標機開發(fā)多數軟件開發(fā)是基于宿主機-日標機模型的。軟件在一臺計算機(宿主機)上開發(fā)，但在另一臺機器(目標機)中運行。對于分布式系統而言，應該考慮如下三個方面的問題1.組件的軟硬件需求 Cuda2.系統可用性需求 備用的組件3.組件通信 部署在同一個平臺，或者距離比較近的平臺上，減少通信延遲4 開源開發(fā)開源（Open Source，開放源碼)被非贏利軟件組織（美國的Open Sourc