1、軟件平臺設計技術方案目錄 TOC o 1-5 h z HYPERLINK l bookmark0 o Current Document 1定義問題與歸結模型3 HYPERLINK l bookmark2 o Current Document 1.1問題分析3 HYPERLINK l bookmark4 o Current Document 1.2問題定義6 HYPERLINK l bookmark6 o Current Document 2需求分析與軟件設計8 HYPERLINK l bookmark8 o Current Document 2.1需求分析的任務與過程8 HYPERLINK l

2、 bookmark10 o Current Document 2 如何進行系統設計11 HYPERLINK l bookmark12 o Current Document 2.3軟件設計的任務與活動12 HYPERLINK l bookmark14 o Current Document 3結構化分析與設計13 HYPERLINK l bookmark16 o Current Document 1結構化分析13 HYPERLINK l bookmark18 o Current Document 3.2結構化設計18 HYPERLINK l bookmark22 o Current Documen

3、t 3.3模塊設計20 HYPERLINK l bookmark24 o Current Document 4面向對象的分析與設計22 HYPERLINK l bookmark26 o Current Document 1面向對象的基本概念22 HYPERLINK l bookmark30 o Current Document 4.2面向對象分析25 HYPERLINK l bookmark32 o Current Document 4.3統一建模語言27 HYPERLINK l bookmark34 o Current Document 5用戶界面設計41 HYPERLINK l bookm

4、ark36 o Current Document 5.1用戶界面設計的原則41 HYPERLINK l bookmark38 o Current Document 5.2用戶界面設計過程42 HYPERLINK l bookmark40 o Current Document 6工作流設計43 HYPERLINK l bookmark42 o Current Document 6. 1工作流設計概述43 HYPERLINK l bookmark44 o Current Document 6.2工作流管理系統45 HYPERLINK l bookmark46 o Current Document

5、7簡單分布式計算機應用系統的設計46 HYPERLINK l bookmark48 o Current Document 8系統運行環境的集成與設計48 HYPERLINK l bookmark50 o Current Document 9系統過渡計劃491定義問題與歸結模型軟件系統的目的是為了解決問題，因此在建模之初最重要的步驟是對問題的分析與定義, 并在此基礎上歸結模型，這樣才能夠獲得切實有效的模型。定義問題的過程包括：理解真實 世界中的問題和用戶的需要，并提出滿足這些需要的解決方案的過程。1.1問題分析問題分析的目標就是在開發之前對要解決的問題有一個更透徹的理解。為了達到這一目 標，通常

6、需要經過在問題定義上達成共識，理解問題的本質，確定項目干系人和用戶，定義 系統的邊界和確定系統實現的約束這五個步驟。在問題定義上達成共識要檢驗大家是否在問題的定義上達成了共識，最簡單的方法就是把問題寫出來，看看是 否能夠獲得大家的認可。而要使得這個過程更加有效，應該將問題用標準化的格式寫出來， 根據UP的建議，應該包括以下幾個方面的要素。問題概述：用簡短的幾句話，將所理解的問題本質描述出來；影響：說明該問題將會對哪些項目干系人（Stakeholder,風險承擔者）產生影響；結果：確定問題對項目干系人和商業活動會產生什么樣的影響； 優點：概要性地提出解決方案，并列舉出該解決方案的主要優點。在問題

7、定義上達成共識，就能夠有效地將開發團隊的理解與用戶的需求達成一致，這樣 就能夠使得整個系統的開發沿著合理的方向發展。理解問題的本質每一句描述都會夾雜著敘述者的個人理解和判斷，因此透過表面深入本質，理解問題背 后的問題，是問題分析階段一個十分關鍵的任務。其中一種技術是根本原因”分析，這是 一種提示問題或其表象的根本原因的系統化方法。在實際的應用中，常使用因果魚骨圖和帕 累托圖兩種方法。（1）因果魚骨圖。因果魚骨圖是一種有效的探尋問題根源的技術，它通過直觀的圖形 找出問題或現象的所有潛在原因，從而追蹤出問題的根源。它能夠幫助人們將問題的原因而 放在首位，提供了一種運用集體智慧解決問題的方法。在使用

8、時，通常按照以下步驟進行。 將問題簡明扼要地寫在右邊的方框里；確定問題潛在原因的主要類別，將它們連到魚的脊骨上；用頭腦風暴法尋找原因并歸類。圖8-1是魚骨圖的一個示例。圖魚骨圖示例（2）帕累托圖。帕累托圖是采用直方圖的形式，根據問題的相對頻率或大小從高往低降序排列，幫助設 計師將精力集中在重要的問題上。它為80%的問題找到關鍵的20%的原因，它可以一目了然 地顯示出各個問題的相對重要程度，有助于預防在解決了一些問題后，卻使另外一些問題變 得更糟的現象發生。在使用時，通常按照以下步驟進行。明確問題：也就是前面達成共識的問題定義：找出問題的各種可能原因：通常可以利用頭腦風暴來收集意見，并通過參考以

9、往積累的資料 和運營的數據來綜合分析；選擇評價標準和考察期限：最常用的評價標準包括頻率（占總原因的百分比）和費用（產生 的影響），而考察的期限則應具有相應問題的代表性，并不是越長越好；收集各種原因發生的頻率及費用數據；將原因按照發生的頻率或費用從大到小排列起來；將原因排在橫軸上，頻率或費用排列在縱軸上，形成如圖8-2所示的結果。這樣就能夠將造成問題的關継原因捕獲出來，以便指導設計出更符合需要、更能夠解 決問題的解決方案。40圖82帕累托圖示例確定項目干系人和用戶要想有效地解決問題，必須了解用戶和其他相關的項目干系人（任何將從新系統或應用 的實現中受到實質性影響的人）的需要。不同的項目干系人通常

10、對問題有不同的看法和不同 的需要，這些在解決問題時必須加以考慮。事實上，許多項目干系人就是系統的用戶，這一 部分通常是易于識別的；但還有一部分項目干系人是系統的間接用戶，甚至只是受系統影響 的商業結果，這一部分不易識別，但十分重要。在尋找項目干系人時，可以思考：系統的用戶是誰？系統的客戶（購買者）是誰？還有 哪些人會受到系統輸出的影響？系統完成并投入使用后，有誰會對它進行評估？還有沒有其 他系統內部或外部的客戶，他們的需要有沒有必要去考慮？系統將來由誰來維護？定義系統的邊界系統的邊界是指解決方案系統和現實世界之間的邊界。在系統邊界中，信息以輸入和輸 出的形式流入系統并由系統流向系統外的用戶，所

11、有和系統的交互都是通過系統和外界的接 口進行的。在定義系統的邊界時，將世界分為兩個部分：系統及與系統進行交互的事物。要 描述系統的邊界有兩種方法：一種是結構化分析中的“上下文范圍圖”，另一種則是面向對 象分析中的用例模型”。（1）上下文范圍圖。也就是數據流圖中的頂層圖，它是一個反映領域信息的模型，能 夠清晰地顯示出系統的工作職責和相鄰系統的職責起止之處，從而讓讀者能夠從宏觀的層面 去了解系統。圖8-3就是一個描述“證券經紀人系統”的上下文范圍圖。（2）用例模型。用例模型則通過引入參與者來描述和系統進行交互的事物”，只要識 別了參與者，自然而然系統的界限就確定下來了。在尋找參與者時，可以思考以下

12、問題：誰 會對系統提供信息？誰會在系統中使用信息？誰會從系統中刪除信息？誰將操作系統？系 統將會在哪里被使用？系統從哪里得到信息？哪些外部系統要和系統進行交互？然后，再根據每個參與者的功能需求，識別出代表系統功能的用例，從而界定系統的邊界。而關于用例模型的更多細節，請參考4.3節。確定系統實現的約束由于各種因素的存在，會對解決方案的選擇造成一定的限制，稱這種限制為約束。每條 約束都將影響到最后的解決方案的形成，甚至會影響是否能夠提出解決方案。在考慮約束時，首先應該考察到不同的約束源，其中包括進度、投資收益、人員、設備 預算、環境、操作系統、數據庫、主機和客戶機系統、技術問題、行政問題、已有軟件

13、、公 司總體戰略和程序、工具和語言的選擇、人員及其他資源限制等。1.2問題定義通過對問題進行細致周密的分析，就可以對其進行綜合的定義。對于一個問題的完整定 義，通常應包括目標、功能需求和非功能需求三個方面。1目標目標是指構建系統的原因，它是最高層次的用戶需求，是業務上的需要，而功能、性能 需求則必須是以某種形式對該目標做出貢獻。在描述目標時，應該注意以下幾個方面。 優勢：目標應該不僅僅是解決問題，還要提供業務上的優勢；度量：不僅要說明業務的優勢，而且還必須提供度量這種優勢的標準；合理性：要確保完成解決方案所需的工作量少于所獲得的業務優勢，這才是合理的解決方案; 可行性：要探尋能夠滿足度量標準的

14、解決方案；可達成性：對于組織而言，是否具備獲取該系統的技能，構建完成后是否能夠操作它。例如，表8-1就是一個很好的目標描述的例子。表目標描述的例子目標：在冬予道路養護支出卜.節彷費用優勢：減少除冰和道路弄護的費用度量標準：除冰帯用將在目和道路處瑪費用的藝礎卜皆低25%.冰對道路i&成的損傷將降低50%功能需求功能需求是用來指明系統必須做的事情，只有這些行為的存在，才有系統存在的價值。 功能需求應該源于業務需求，它只與問題域相關，與解決方案域無關。也就是說，功能需求 是在與用戶或某個業務人員交談時，他們所描述的內容是為了完成他們某部分的工作而必須 做的事情。而在設計解決方案時，會遇到一些限制條件

15、，這些東西也是“系統需求”的一 部分，不過應該是設計約束或非功能需求形式指定。在規定功能需求時要注意其詳細程度。由于這些需求是業務需求，因此應該由業務人員 來驗證。也就是說，用戶應該能夠指明系統要達到有用的程度，功能是否已經足夠；考慮到 工作的成果，它的功能是否正確。另外，在描述功能需求時，應該注意需求的二義性。而二 義性主要體現在以下幾個方面。同名異義的詞：在自然語言中存在許多同名但異義的詞語，應該謹慎地排除它們 帶來的影響。代詞：在需求描述中，代詞經常會產生指代不明的現象，應該盡量避免使用，而 是換成主語及賓語。希賽教育專家提示：在檢查功能需求的二義性時，一種有效的方法是大聲地朗讀出來，

16、大家一起邊聽邊進行討論，這樣可以不斷地優化。非功能需求非功能需求是系統必須具備的屬性，這些屬性可以看作是一些使產品具有吸引力、易用、 快速或可靠的特征或屬性。非功能需求并不改變產品的功能，它是為工作賦予特征的。在識 別功能需求和非功能需求時，有一種十分有用的思維模式：功能需求是以動詞為特征的，而 非功能性需求則是以副詞為特征的。非功能需求主要包括以下幾種。觀感需求：即產品外觀的精神實質，也就是與用戶界面的觀感相關的一組屬性；易用性需求：也就是產品的易用性程度，以及特殊的可用性考慮，通常包括用戶 的接受率、因為引入該產品而提高的生產效率、錯誤率、特殊人群的可用性等指標;（3）性能需求：也就是關于

17、功能實現要求有多快、多可靠、多少處理量及多精確的約 束。例如：速度、精度、安全性、容量、值范圍、吞吐量、資源使用效率、可靠性（平均無 故障時間）、可用性（不停機時間）、可擴展性等；（4）可操作性需求：衡量產品的操作環境，以及對該操作環境必須考慮的問題；（5）可維護性和可移植性需求：期望的改變，以及完成改變允許的時間；（6）安全性需求：產品的安全保密性，通常體現為保密性、完整性和可獲得性；（7）文化和政策需求：由產品的開發者和使用者所帶來的特別需求；（8）法律需求：哪些法律和標準適用于本產品。2需求分析與軟件設計需求分析是軟件生命周期中相當重要的一個階段。根據Standish Group對230

18、00個 項目進行的研究結果表明，28%的項目徹底失敗，46%的項目超出經費預算或者超出工期，只 有約26%的項目獲得成功。需求分析工作在整個軟件開發生命周期中有著十分重要的意義。 而在這些高達74%的不成功項目中，有約60%的失敗是源于需求問題，也就是差不多有一半 的項目都遇到了這個問題，這一可怕的現象引起人們對需求分析的高度重視。需求分析階段 的主要任務是通過開發人員與用戶之間的廣泛交流，不斷澄清一些模糊的概念，最終形成一 個完整的、清晰的、一致的需求說明。而當明確了用戶的需求之后，下一步的任務就是對未來的軟件系統進行設計，它是確定 系統實現的關鍵工作。需求分析和設計的方法對軟件開發過程而言

19、是十分重要的，因此必須 扎實地掌握它。需求分析與軟件設計是軟件生存期中最重要的兩個步驟，需求分析解決的是“做什么” 的問題，系統設計則是解決“怎么做”的問題。2.1需求分析的任務與過程需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其 他系統元素的接口細節，定義軟件的其他有效性需求，細化軟件要處理的數據域。用一句話 概括就是：需求分析主要是確定待開發軟件的功能、性能、數據、界面等要求。需求分析的 實現步驟通常包括：獲取當前系統的物理模型，抽象出當前系統的邏輯模型，建立目標系統 的邏輯模型三個部分。具體來說，需求分析階段的工作可以分成4個方面：問題識別：用于發現需求、描

20、述需求，主要包括功能需求、性能需求、環境需求、 可靠性需求、安全保密需求、用戶界面需求、資源使用需求、軟件成本消耗與開發進度需求， 以此來預先估計以后系統可能達到的目標。分析與綜合：也就是對問題進行分析，然后在此基礎上整合出解決方案。這個步 驟經常是反復進行的，常用的方法有面向數據流的結構化分析方法(Structured Analysis, SA),面向數據結構的Jackson方法，面向對象的分析方法(Object Oriented Analysis, 00A),以及用于建立動態模型的狀態遷移圖和Petri網。編制需求分析的文檔：也就是對已經確定的需求進行文檔化描述，該文檔通常稱 為“需求規格

21、說明書”。需求分析與評審：它是需求分析工作的最后一步，主要是對功能的正確性、完整 性和清晰性，以及其他需求給予評價。需求的分類什么是軟件的需求呢？軟件需求就是系統必須完成的事及必須具備的品質。具體來說, 軟件需求包括功能需求、非功能需求和設計約束三方面內容。各種需求的概念示意圖如圖 8-4所示。項目視圖/ 范圍文檔圖&4需求概念示意圖功能需求：是指系統必須完成的那些事，即為了向它的用戶提供有用的功能，產品必須執行的動作。非功能需求：是指產品必須具備的屬性或品質，如性能、響應時間、可靠性、容錯性、 擴展性等。設計約束：也稱為限制條件、補充規約，這通常是對解決方案的一些約束說明，例如必 須采用國有

22、自主知識版權的數據庫系統，必須在UNIX操作系統之下運行等。除了這三種需求之外，還有業務需求、用戶需求、系統需求這三個處于不同層面的概念， 充分地理解這樣的模型才能夠更加清晰地理清需求的脈絡。HH (Business Requirement)：是指反映組織機構或客戶對系統、產品高層次的 目標要求，通常問題定義本身就是業務需求。(User Requirement)：是指描述用戶使用產品必須要完成什么任務，怎么完 成的需求，通常是在問題定義的基礎上進行用戶訪談、調查，對用戶使用的場景進行整理, 從而建立從用戶角度出發的需求。(System Requirement)：是從系統的角度來說明軟件的需求，

23、它包括用特性 說明的功能需求、質量屬性、非功能需求及設計約束。分析師經常圍繞著“功能需求”來展開工作，而功能需求大部分都是從“系統需求”的 角度來分析與理解的，也就是用開發人員”的視角來理解需求。但要想真正地得到完整的 需求，僅戴上“開發人員”的眼鏡是不夠的，還需要“領域專家”的眼鏡，要從更高的角度 來理解需求，這就是“業務需求”；同時還應該更好地深入用戶，了解他們的使用場景，了 解他們的想法，這就是“用戶需求”。這是一個理解層次的問題，并不僅僅是簡單的概念。需求工程需求工程就是包括創建和維護系統需求文檔所必需的一切活動的過程，主要包括需求 開發和需求管理兩大工作。需求開發：包括需求捕獲、需求

24、分析、編寫規格說明書和需求驗證4個階段。在 這個階段需要完成確定產品所期望的用戶類型、獲取每種用戶類型的需求、了解實際用戶任 務和目標及這些任務所支持的業務需求、分析源于用戶的信息、對需求進行優先級分類、將 所收集的需求編寫成為軟件規格說明書和需求分析模型、對需求進行評審等工作。需求管理：通常包括定義需求基線、處理需求變更、需求跟蹤等方面的工作。這兩個方面是相輔相成的，需求開發是主線，是目標；需求管理是支持，是保障。換句 話說，需求開發是努力更清晰、更明確地掌握客戶對系統的需求；而需求管理則是對需求的 變化進行管理的過程。需求分析方法需求分析的方法可謂種類繁多，不過如果按照分解方式的不同，可以

25、很容易地劃分出幾 種類型。本節先從分析方法發展的歷史，對其建立一個概要性的認識，在本章的后面幾節中 將詳細說明最具有代表性的結構化分析與設計、面向對象分析與設計兩種方法。結構化分析方法：最初的分析方法都不成體系，而且通常都只包括一些籠統的告 誡，在20世紀70年代分析技術發展的分水嶺終于出現了。這時人們開始嘗試使用標準 化的方法，開發和推出各種名為結構化分析”的方法論，而Tom DeMacro則是這個領域 最有代表性和權威性的專家。軟系統方法：這是一個過渡性的方法論，并未真正流行過，它的出現只是證明了 結構化分析方法的一些不足。因為結構化分析方法采用的相對形式化的模型不僅與社會觀格 格不入，而

26、且在解決“不確定性”時顯得十分無力。最有代表性的軟系統方法是Checkland 方法。面向對象分析方法：在20世紀90年代，結構化方法的不足在面對多變的商業 世界時，顯得更加蒼白無力，這就催使了 00A的迅速發展。面向問題域的分析(Problem Domain Oriented Analysis, PDOA):現在又發現面 向對象分析方法也存在著很多的不足，應運而生了一些新的方法論，PDOA就是其中一種。 不過現在還在研究階段，并未廣泛應用。2.2如何進行系統設計當設計者拿到一個需求，他如何開展系統設計呢？許多想進入系統分析與設計的年輕人 以為自己知道了面向對象、統一建模語言、設計模式等新鮮深

27、奧的名詞就可以進行設計了， 可是掌握工具和技能絕不是成為優秀設計者的充分條件，甚至也不是必要條件。遺憾的是這 里沒有捷徑，只有設計者在實踐中不斷學習和總結。而在實踐中，系統設計與其說是在設計， 不如說是在選擇和妥協。妥協，就是在各個系統目標之間找到一個平衡點。系統目標包括但不限制于功能、性 能、健壯性、開發周期、交付日期等。不幸的是，這些目標往往是矛盾的，提高軟件性能直 接意味著開發周期的增加、交付日期的推遲，盲目地增加功能可能導致性能降低，維護成本 提高。軟件設計者的難題在于在如此眾多的目標之間找到這個平衡點，并且明確知道如何設 計能實現這個平衡，既可以讓投資者覺得在預算之內，又能讓用戶相對

28、滿意。可行性分析階 段應該已經論述了這樣一個平衡點，可是如果設計者發現沒有這樣一個平衡點，如同沒有一 個設計者能讓人騎著自行車到月球上去，那么設計者只能提出放棄某個方面的過度要求，否 則系統要遭受必然失敗的命運。更多的情況是沒有經驗的設計者不知道是否存在這些平衡 點，更不知道如何利用合理的設計及有效的工具來達到平衡。因此設計者需要了解可以解決 問題的各種方案，并清楚知道各個方案的效果、成本、缺點，以及這些方案的區別，并在各 種方案中進行選擇。而這些，不是一個人能在一兩天了解的。沒有一個設計者會完全重新開始設計一個系統，他們總參考多個與目標系統相類似的系 統，再從中進行甄別、取舍和補充來作為新系

29、統的設計。人們發現一個優秀的設計者似乎能 在聽完需求后就立即構想出目標系統的框架，這并不是因為他聰明或者比不知所措的設計者 新手多一個腦袋，而是因為他在平時已經了解大量的系統，對各種設計的優缺點、局限性也 了然于胸，能夠把以前的設計根據需要再次使用。所以要成為優秀的設計者，了解、掌握、 消化、總結前人和自己以前的設計成果是最好的方法，這似乎也是唯一的方法。設計者的苦惱有時候和編程人員一樣。計算機系統的發展如此迅速，解決方案也越來越 多，如同編程語言的發展，同時，隨著人類社會的進步，投資者和客戶也提出了越來越高的 要求，這又需要設計者不斷學習、創造新的方案。但系統設計也并非沒有規律可以遵循，如同

30、幸福的家庭都很相似，不幸的家庭各有各的 不幸，人們在實踐中發現優秀的系統設計一般在以下幾個方面都很出色。組件的獨立性。審視自己設計的系統，是否做到了高內聚、低耦合？例外的識別和處理。誰能保證系統使用者都精確按照使用說明書使用？防錯和容錯。當網絡中斷、數據庫崩潰這樣的災難性事件發生時，系統也跟著崩 潰嗎？而且，更幸運的是，也有一些技術能夠改進系統設計，這些方法包括：降低復雜性、通 過合約進行設計、原型化設計、錯誤樹分析等。2.3軟件設計的任務與活動軟件設計(又叫系統設計xxk)是一個把軟件需求變換成軟件表示的過程。最初這種表示 只是描繪出軟件的總體框架，然后再進一步細化，并在此框架中填入細節。軟

31、件設計的兩個階段從工程管理角度，軟件設計可以分為兩個步驟：(1)槪要設計：也稱為高層設計，將軟件需求轉化為數據結構和軟件的糸統結構。例 如，如果采用結構化設計，則將從宏觀的角度將軟件劃分成各個組成模塊，并確定模塊的功 能及模塊之間的調用關系。(2)詳細設計：也稱為低層設計，將對結構表示進行細化，得到詳細的數據結構與算 法。同樣的，如果采用結構化設計，則詳細設計的任務就是為每個模塊進行設計。主要的設計方法比較在結構化設計風行的時代，主流的設計方法還包括Jackson方法和Parnas方法。結 構化方法側重于“模塊相對獨立且功能單一，使模塊間聯系弱、模塊內聯系強”；而Jackson 方法則是從數據

32、結構導出模塊結構；Parnas方法的主要思想則是將可能引起變化的因素隱 藏在有關模塊內部，使這些因素變化時的影響范圍受到限制，它只提供了重要的設計準則， 但沒有規定出具體的工作步驟。而近年來，對象技術憑借其對數據的高效封裝及良好的消息機制，實現了高內聚、低耦 合的系統設計，成了現代軟件設計的主流方法學。3結構化分析與設計結構化分析與設計方法是一種面向數據流的需求分析和設計方法，它適用于分析和設計 大型數據處理系統，是一種簡單、實用的方法，曾獲得廣泛的應用。3.1結構化分析結構化分析方法的基本思想是自頂向下逐層分解。分解和抽象是人們控制問題復雜性的 兩種基本手段。對于一個復雜的問題，人們很難一下

33、子考慮問題的所有方面和全部細節，通 常可以把一個大問題分解成若干個小問題，每個小問題再分解成若干個更小的問題，經過多 次逐層分解，每個最底層的問題都是足夠簡單、容易解決的，于是復雜的問題也就迎刃而解 了。這個過程就是分解過程。結構化分析與面向對象分析方法之間的最大差別是：結構化分析方法把系統看作一個過 程的集合體，包括人完成的和電腦完成的；而面向對象方法則把系統看成一個相互影響的對 象集。結構化分析方法的特點是利用數據流圖來幫助人們理解問題，對問題進行分析。結構化分析一般包括以下工具：數據流圖(Data Flow Diagram, DFD)、數據字典(Data Dictionary, DD)、

34、結構化語言、判定表、判定樹。在接下來的部分將對它們一一做簡單介 紹。結構化系統分析方法從總體上來看是一種強烈依賴數據流圖的自頂向下的建模方法。它 不僅是需求分析技術，也是完成需求規格化的有效技術手段。結構化分析的工作步驟在介紹具體的結構化分析方法之前，先對如何進行結構化分析做一個總結性描述，以幫 助大家更好地應用該方法。研究“物質環境”。首先，應畫出當前系統(可能是非計算機系統，或是半計算機 系統)的數據流圖，說明系統的輸入、輸出數據流，說明系統的數據流情況，以及經歷了哪 些處理過程。在這個數據流圖中，可以包括一些非計算機系統中數據流及處理的命名，例如 部門名、崗位名、報表名等。這個過程可以幫

35、助分析員有效地理解業務環境，在與用戶的充 分溝通與交流中完成。建立系統邏輯模型。當物理模型建立完成之后，接下來的工作就是畫出相對于真 實系統的等價邏輯數據流圖。在前一步驟建立的數據流圖的基礎上，將所有自然數據流都轉 成等價的邏輯流，例如，將現實世界的報表存儲在計算機系統中的文件里；又如將現實世界 中“送往總經理辦公室”改為“報送報表”。劃清人機界限。最后，確定在系統邏輯模型中，哪些將采用自動化完成，哪些仍 然保留手工操作。這樣，就可以清晰地劃清系統的范圍。數據流圖DFD是一種圖形化的系統模型，它在一張圖中展示信息系統的主要需求，即輸入、輸出、 處理(過程)、數據存儲。由于從DFD中可以很容易地

36、看出系統緊密結合的各個部分，而且 整個圖形模式只有5個符號需要記憶，所以深受分析人員的喜愛，因而廣為流行。如圖8-5所示，DFD中包括以下幾個基本元素。過程：也稱為加工(處理)，一步步地執行指令，完成輸入到輸出的轉換。外部實體：也稱為源/宿，系統之外的數據源或目的。數據存儲：也稱為文件，存放數據的地方，一般是以文件、數據庫等形式岀現。數據流：從一處到另一處的數據流向，如從輸入或輸出到一個過程的數據流。實時連接：當過程執行時，外部實體與過程之間的來回通信。敬據流外部實體/源/宿敷據存儲/文件實時連接用85數據流圖的符號集希賽教育專家提示：不同的參考書籍中關于DFD的符號可能有些不一樣，其中加工、

37、 外部實體、數據存儲和數據流是公共的部分。（1）數據流圖的層次。正如前面提到的，結構化分析的思路是依賴于數據流圖進行自 頂而下的分析。這也是因為系統通常比較復雜，很難在一張圖上將所有的數據流和加工描述 清楚。因此，數據流圖提供一種表現系統高層和低層概念的機制。也就是先繪制一張較高層 次的數據流圖，然后在此基礎上，對其中的過程（處理）進行分解，分解成為若干獨立的、 低層次的、詳細的數據流圖，而且可以這樣逐一地分解下去，直至系統被清晰地描述出來。 數據流圖的層次如圖8-6所示。DFD/L1.1DFD/LI.2DFD/LI.3圖數據流圖的層次（2） Context圖。Context圖，也就是系統上下

38、文范圍關系圖。這是描述系統最高層 結構的DFD圖。它的特點是，將整個待開發的系統表示為一個過程，將所有的外部實體和 進出系統的數據流都畫在一張圖中。圖8-7就是一個Context圖的例子。圖87 Context圖實例Context圖用來描述系統有什么輸入、輸出數據流，與哪些外部實體直接相關，可以把 整個系統的范圍勾畫出來。逐級分解。當完成了 Context圖的建模之后，就可以在此基礎上進行進一步的分 解。以圖8-7為例，進行再分解，在對原有流程了解的基礎上，可以得到如圖8-8所示的 結果。18-8 DFD0層圖實例圖8-8是在Context圖的基礎上做的第一次分解，而在Context圖中只有一

39、個過 程，那就是系統，將其編號為0。而接下來對Context圖進行的分解，其實就是對這個編 號為0的過程進行更細化的描述，在這里引入了新的過程、數據存儲，為了能夠區分其位 置的級別，在這層次上的過程將以1、2、3為序列進行編號。由于這是對過程0的分解，因此也稱之為DFD 0層圖。而可以根據需要對DFD 0層 圖上的過程(編號為1、2、3)進行類似的分解，那么就稱之為DFD 1層圖，在DFD 1層 圖中引入的新過程，其編號規則就是1.1, 1.2，以及2.1, 2.2-,以此類推，直到完成 分析工作。另外，這里存在一個很關縫的要點，那就是DFDO層圖是Context圖的細化，因此所 有的輸入和輸

40、出應該與Context圖完全一致，否則就說明存在著錯誤。如何畫DFD。DFD的繪制是一個自頂向下、由外到里的過程，通常按照以下幾個 步驟進行。畫系統的輸入和輸出：就是在圖的邊緣標出系統的輸入、輸出數據流。這一步其實是決 定研究的內容和系統的范圍。在畫的時候，可以先將盡可能多的輸入、輸出畫出來，然 后再刪除多余的，增加遺漏的。畫數據流圖的內部：將系統的輸入、輸出用一系列的處理連接起來，可以從輸入數據流 畫向輸出數據流，也可以從中間畫出去。為每一個數據流命名：命名的好壞與數據流圖的可理解性密切相關，應避免使用空洞的 名字。為加工命名：注意應該使用動賓短語。不考慮初始化和終點，暫不考慮岀錯路徑等細節

41、，不畫控制流和控制信息。細化記錄DFD部件為了更好地描述DFD的部件，結構化分析方法還引入了數據字典、結構化語言及決策樹、 決策表等方法。通過使用這些工具，能對數據流圖中描述不夠清晰的地方進行有效的補充。 其其中數據字典應用最為廣泛，下面將詳細說明數據字典的相關使用方法。數據字典技術是一種很實用、有效的表達數據格式的手段。它是對所有與系統相關的數 據元素的一個有組織的列表和精確嚴格的定義，使得用戶和系統分析員對于輸入、輸出、存 儲成分和中間計算機有共同的理解。通常數據字典的每一個條目中包括以下信息。名稱：數據或控制項、數據存儲或外部實體的主要名稱，如果有別名的還應該將別 名列出來。何處使用/如

42、何使用：使用數據或控制項的加工列表，以及如何使用。內容描述：說明該條目的內容組成，通常采用以下符號進行說明。=:由構成。+:和，代表順序連接的關系。I :或，代表從中選擇一個。n次重復。O：代表可選的數據項。*：表示特定限制的注釋。補充信息：關于數據類型、默認值、限制等信息。下面就是一個數據字典的實例：客戶基本信息二客戶編號+客戶名稱+身份證號碼+手機+家庭電話 客戶編號=0-9（8客戶名稱二字4身份證號碼二0-9 15| 0-9 18手機二0-9 11| 0912家庭電話=（區號）+本地號區號二094本地號二097| 0983.2結構化設計結構化設計包括架構設計、接口設計、數據設計和過程設計

43、等任務。它是一種面向數據 流的設計方法，是以結構化分析階段所產生的成果為基礎，進一步自頂而下、逐步求精和模 塊化的過程。概要設計與詳細設計的主要任務槪要設計階段的主要任務是設計軟件的結構、確定系統是由哪些模塊組成，以及每個模 塊之間的關系。它采用結構圖（包括模塊、調用、數據）來描述程序的結構，此外還可以使 用層次圖和HTP0 （層次圖加輸入/處理/輸出圖）。整個過程主要包括：復查基本系統模型、復查并精化數據流圖、確定數據流圖的信息流 類型（包括交換流和事務流）、根據流類型分別實施變換分析或事務分析、根據軟件設計原 則對得到的軟件結構圖進一步優化。詳細設計階段的主要任務則是確定應該如何具體地實現

44、所要求的系統，得出對目標系統 的精確描述。它采用自頂向下、逐步求精的設計方式和單入口單出口的控制結構。常使用的 工具包括程序流程圖PFD、盒圖NS、問題分析圖PAD、程序設計語言PDL。結構圖如圖8-9所示，結構圖的基本成分包括模塊、調用（模塊之間的調用關系）和數據（模塊間傳遞及處理數據信息）。O* 數據估息已有模塊人模塊 調用B 模塊圖89結構圖的基木成分結構圖是在需求分析階段產生的數據流圖的基礎上進行進一步的設計。它將DFD圖中 的信息流分為兩種類型。變換流：信息首先沿著輸入通路進入系統，并將其轉換為內部表示，然后通過變換中心（加工）的處理，再沿著輸出轉換為外部形式離開系統。具有這種特性的

45、加工流就是變換流。事務流：信息首先沿著輸入通路進入系統，事務中心根據輸入信息的類型在若干個動作 序列（活動流）中選擇一個執行，這種信息流稱為事務流。程序流程圖和盒圖程序流程圖和盒圖都是用來描述程序的細節邏輯的，其符號如圖8-10所示。程序流程圖的特點是簡單、直觀、易學，但它的缺點也正是由于其隨意性而使得畫岀來的流程圖容易成為非結構化的流程圖。而盒圖正是為了解決這一問題設計的，它是一種符合 結構化程序設計原則的圖形描述工具。盒圖的主要特點是功能域明確、無法任意轉移控制、容易確定全局數據和局部數據的作 用域、容易表示嵌套關系、可以表示模塊的層次結構。但它也帶來了一個副作用，那就是修 改相對比較困難

46、。起吐點二二 O 口入/輸出處理準備既定處理條件判斷外接內接(a程序流程圖基本符號do-uhile 循環else 部分then 部分分支結構(沁條件/值1值2值nI循環部分循環條件件do-unnl 循環 (b；盒圖基本符號圖810程序流程圖和盒圖基本符號示意圖PAD 和 PDLPAD是問題分析圖的縮寫，它符合自頂向下、逐步求精的原則，也符合結構化程序設計 的思想，它最大的特點在于能夠很方便地轉換為程序語言的源程序代碼。PDL則是語言描述工具的縮寫，它和高級程序語言很相似，也包括數據說明部分和過程 部分，還可以帶注解等成分，但它是不可執行的。PDL是一種形式化語言，其控制結構的描 述是確定的，但

47、內部的描述語法是不確定的。PDL通常也被稱為偽碼。3. 3模塊設計在結構化方法中，模塊化是一個很重要的概念，它是將一個待開發的軟件分解成為若干 個小的簡單部分一一模塊，每個模塊可以獨立地開發、測試。這是一種復雜問題的“分而治 之”原則，其目的是使程序的結構清晰、易于測試與修改。具體來說，模塊是指執行某一特定任務的數據結構和程序代碼。通常將模塊的接口和功 能定義為其外部特性，將模塊的局部數據和實現該模塊的程序代碼稱為內部特性。而在模塊 設計時，最重要的原則就是實現信息隱蔽和模塊獨立。模塊經常具有連續性，也就意味著作 用于系統的小變動將導致行為上的小變化，同時規模說明的小變動也將影響到一小部分模

48、塊。信息隱蔽原則信息隱蔽是開發整體程序結構時使用的法則，即將每個程序的成分隱蔽或封裝在一個單 一的設計模塊中，并且盡可能少地暴靂其內部的處理。通常將難的決策、可能修改的決策、 數據結構的內部連接以及對它所做的操作細節、內部特征碼、與計算機硬件有關的細 節等隱蔽起來。通過信息隱蔽可以提高軟件的可修改性、可測試性和可移植性，它也是現代 軟件設計的一個關鍍性原則。模塊獨立性原則模塊獨立是指每個模塊完成一個相對獨立的特定子功能，并且與其他模塊之間的聯系最 簡單。保持模塊的高度獨立性，也是設計過程中的一個很重要的原則。通常用耦合（模塊之 間聯系的緊密程度）和內聚（模塊內部各元素之間聯系的緊密程度）兩個標

49、準來衡量，設計 的目標是高內聚、低耦合。模塊的內聚類型通常可以分為7種，根據內聚度從高到低排序，如表8-2所示。表&2橫塊的內聚類型內聚類型描 述功鏈內聚完成一個單一功能，各個部分協同工作.缺一不町順序內聚處理元噸相關.而且必須載序執行通信內聚所育處理元索集中圧一個數據址構的區域t過程內聚處理元素相關.而且必演按特定的次序執廳真時內聚所包含的任務必須在同一時間何隔內執行（feiw始化根塊）邏軻內聚完成邏輸卜相關的一 ffl任務偶然內聚完成一組沒有關系或松散關系的任務與此相對應的，模塊的耦合性類型通常也分為7種，根據耦合度從低到高排序，如表8-3 所示。表&3模塊的縄合性類型稱合類靈ffi述沒有

50、自接聯系.互相不依賴對方借Wj#農傳垮簡單收據標記耦合一個救據結構的一部分（8助干楔塊接口來傳遞控制鶴含模塊何傳遞的信息中包含用于捋制模塊內冊邏輯的信息外部耦含與軟件以外的環境有關公共耦含多個復塊引用同一個全局數據區內客耀合一個慢塊訪月另一個根塊的內部救據一個模塊不通過正常入口轉到另一個按塊的內部苗個根塊W-B分程序代叫蚩0一個模塊有多個入口除了滿足以上兩大基本原則之外，通常在模塊分解時還需要注意：保持模塊的大小適中,盡可能減少調用的深度，直接調用該模塊的個數應該盡量大，但調用其他模塊的個數則不宜 過大；保證模塊是單入口、單出口的；模塊的作用域應該在控制域之內；功能應該是可預測 的。4面向對象

51、的分析與設計面向對象方法是一種非常實用的軟件開發方法，它一出現就受到軟件技術人員的青睞, 現已成為計算機科學研究的一個重要領域，并逐漸成為軟件開發的一種主要方法。面向對象 方法以客觀世界中的對象為中心，其分析和設計思想符合人們的思維方式，分析和設計的結 構與客觀世界的實際比較接近，容易被人們接受。在面向對象方法中，分析和設計的界面并 不明顯，它們采用相同的符號表示，能夠方便地從分析階段平滑地過渡到設計階段。此外, 在現實生活中，用戶的需求經常會發生變化，但客觀世界的對象及對象間的關系比較穩定, 因此用面向對象方法分析和設計的結構也相對比較穩定。4.1面向對象的基本概念對象和類對象是系統中用來描

52、述客觀事物的一個實體，它由對象標識（名稱）、屬性（狀態、數 據、成員變量）和服務（操作、行為、方法）三個要素組成，它們被封裝為一個整體，以接 口的形式對外提供服務。在現實世界中，每個實體都是對象，如學生、書籍、收音機等；每個對象都有它的操作， 例如書籍的頁數，收音機的頻道、按鈕等屬性，以及收音機的切換頻道等操作。而類則是對具有相同屬性和服務的一個或一組對象的抽象。類與對象是抽象描述和具體 實例的關系，一個具體的對象被稱為類的一個實例。在系統設計過程中，類可以分為三種類 型，分別是實體類、邊界類和控制類。（1）實體類：類，它們都屬于實體類。實體類通常都是永久性的，它們所具有的屬性 和關系實體類映

53、射需求中的每個實體，實體類保存需要存儲在永久存儲體中的信息，例如, 在線教育平臺系統可以提取出學員類和課程是長期需要的，有時甚至在系統的整個生存期都 需要。實體類是對用戶來說最有意義的類，通常采用業務領域術語命名，一般來說是一個名詞， 在用例模型向領域模型的轉化中，一個參與者一般對應于實體類。通常可以從SRS中的那 些與數據庫表（需要持久存儲）對應的名詞著手來找尋實體類。通常情況下，實體類一定有 屬性，但不一定有操作。（2）控制類：控制類是用于控制用例工作的類，一般是由動賓結構的短語（“動詞+名 詞”或“名詞+動詞”）轉化來的名詞，例如，用例“身份驗證”可以對應于一個控制類“身 份驗證器”，它

54、提供了與身份驗證相關的所有操作。控制類用于對一個或幾個用例所特有的 控制行為進行建模，控制對象（控制類的實例）通常控制其他對象，因此，它們的行為具有 協調性。控制類將用例的特有行為進行封裝，控制對象的行為與特定用例的實現密切相關，當系 統執行用例的時候，就產生了一個控制對象，控制對象經常在其對應的用例執行完畢后消亡。 通常情況下，控制類沒有屬性，但一定有方法。（3）邊界類：邊界類用于封裝在用例內、外流動的信息或數據流。邊界類位于系統與 外界的交接處，包括所有窗體、報表、打印機和掃描儀等硬件的接口，以及與其他系統的接 口。要尋找和定義邊界類，可以檢查用例模型，每個參與者和用例交互至少要有一個邊界

55、類， 邊界類使參與者能與系統交互。邊界類是一種用于對系統外部環境與其內部運作之間的交互 進行建模的類。常見的邊界類有窗口、通信協議、打印機接口、傳感器和終端等。實際上， 在系統設計時，產生的報表都可以作為邊界類來處理。邊界類用于系統接口與系統外部進行交互，邊界對象將系統與其外部環境的變更（例如， 與其他系統的接口的變更、用戶需求的變更等）分隔開，使這些變更不會對系統的其他部分 造成影響。通常情況下，邊界類可以既有屬性也有方法。繼承與泛化繼承是面向對象方法中重要的概念，用來說明特殊類（子類）與一般類（父類）的關系， 而通常用泛化來說明一般類與特殊類的關系，也就是說它們是一對多關系。如圖8-11所

56、示，“交通工具”是“自行車”和“小轎車”的泛化；“自行車”和小轎 車”從“交通工具”中繼承。多態與重載多態（即多種形式）性是指一般類中定義的屬性或服務被特殊類繼承后，可以具有不同 的數據類型或表現出不同的行為，通常是使用重載利改寫兩項技術來實現的。一般有4種不同形式的多態，如表8-4所示。圖表8/多態類型一覽表多態妾型描述示Aft（號用多播涇一個函數名隊有多種不冋實現方式.三編譯時基于類型簽名來區分各個里敎帝 敷的名胃cla 錨 0*rL3odcrpublic void test (int x);public void tect (mt x, double y);public void td(

57、2tnng x);)改號（包含多態的一種特殊1*況，只發生在有關父類和 子奐之關系中.注：JS常簽名相同.內容不 -樣class Parent public void teu (int x); class Child extends Parent pobhc void test (mt); 多態變量多態吾定多態）事第為一種類顯.但實際匕卻町以包含月一種 類星數德的變atParent p=new Child ()：（役板.參皴多念用工只的方法.BTU在輸定的場臺將其特化ttmphteT T max (T a, T b) if ( b) return b;Return a;注1：重載也稱為過載、重

58、置;注2：參數多態和包含多態稱為通用多態，重載多態和強制多態稱為特定多態。希賽教育專家提示：雖然重載和改寫都是在多種潛在的函數體中，選擇和調用某一個函 數或方法并對其進行執行，但它們的本質區別在于：重載是編譯時執行的（靜態綁定），而 改寫則是運行時選擇的（動態綁定）。模板類也稱為類屬類，它用來實現參數多態機制。一個類屬類是關于一組類的一個特性抽象, 它強調的是這些類的成員特征中與具體類型無關的那些部分，而用變元來表示與具體類型有 關的那些部分。消息和消息通信消息就是向對象發出的服務請求，它通常包括提供服務的對象標識、消息名、輸入信息 和回答信息。消息通信則是面向對象方法學中的一個重要原則，它與

59、對象的封裝原則密不可 分，為對象間提供了唯一合法的動態聯系的途徑。4.2面向對象分析面向對象分析的目標是開發一系列模型，這些模型描述計算機軟件，當它工作時以滿足 一組客戶定義的需求。對象技術的流行，演化出了數十種不同的00A方法，每個方法都引 入了 一個產品或系統分析的過程、一組過程演化的模型及使軟件工程師能夠以一致的方式創 建每個模型的符號體系。其中比較流行的方法包括OMT、OOA、OOSE、Booch方法等，而OMT、 OOSE、Booch最后則統一成為UMLo00A/00D 方法這是由Peter Coad和Edward Yourdon提出的，00A模型中包括主題、對象類、結 構、屬性和服

60、務5個層次，需經過標識對象類、標識結構與關聯（包括繼承、聚合、組合、 實例化等）、劃分主題、定義屬性、定義服務5個步驟來完成整個分析工作。00D中將繼續貫穿00A中的5個層次和5個活動，它由人機交互部件、問題域部件、任 務管理部件、數據管理部件4個部分組成，其主要的活動就是這4個部件的設計工作。設計問題域部分：00A的結果恰好是00D的問題域部件，分析的結果在00D中可以被改 動或增補，但基于問題域的總體組織框架是長時間穩定的；設計人機交互部件：人機交互部件在上述結果中加入人機交互的設計和交互的細節，包括窗 口和輸出報告的設計。可以用原型來幫助實際交互機制進行開發和選擇；設計任務管理部分：這部