軟件設(shè)計與體系結(jié)構(gòu)

第1章軟件工程與軟件設(shè)計1.1軟件工程1.2軟件生存周期1.3軟件開發(fā)過程模型1.4軟件設(shè)計1.5軟件體系結(jié)構(gòu)1.6小結(jié)第一頁，共664頁。第1章軟件工程與軟件設(shè)計以計算機為核心的信息社會軟件是信息化的靈魂以工程化方法和思想開發(fā)軟件軟件設(shè)計是軟件開發(fā)過程中的核心活動之一第二頁，共664頁。1.1軟件工程軟件危機：在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題軟件設(shè)計：計算機軟件發(fā)展到一定階段，為了應(yīng)對軟件危機計算機軟件=程序+數(shù)據(jù)+文檔計算機軟件是邏輯和智力產(chǎn)品，不是物理產(chǎn)品第三頁，共664頁。1.1軟件工程軟件的應(yīng)用領(lǐng)域和分類系統(tǒng)軟件實時軟件嵌入式軟件科學(xué)和工程計算軟件事物務(wù)理軟件人工智能軟件個人計算機軟件第四頁，共664頁。1.1軟件工程軟件危機軟件危機是指在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題。即包含兩方面的問題：(1)如何開發(fā)軟件(2)如何維護軟件軟件危機的原因軟件產(chǎn)品生產(chǎn)效率較低軟件供需失衡用戶需求不明確整個軟件開發(fā)過程缺乏正確的理論指導(dǎo)軟件產(chǎn)品的規(guī)模越來越大軟件產(chǎn)品開發(fā)的復(fù)雜度越來越高第五頁，共664頁。1.1軟件工程軟件工程軟件工程是指導(dǎo)計算機軟件開發(fā)和維護的工程學(xué)科；將系統(tǒng)的、規(guī)范的、可度量的工程化方法應(yīng)用于軟件開發(fā)、運行和維護的全過程及上述方法的研究；是用工程、科學(xué)和數(shù)學(xué)的原則與方法研制、維護計算機軟件的有關(guān)技術(shù)和管理方法；軟件工程要素：方法、工具、過程方法：為軟件開發(fā)提供了“如何做”的技術(shù)，是完成軟件工程項目的技術(shù)手段工具：人類在開發(fā)軟件的活動中智力和體力的擴展和延伸，為軟件工程方法提供自動或半自動的軟件支持環(huán)境過程：將方法和工具綜合起來以達到合理、及時地進行軟件開發(fā)的目的第六頁，共664頁。1.1軟件工程軟件工程的目標(biāo)和原則在給定成本、進度的前提下，開發(fā)出具有可修改性、有效性、可靠性、可理解性、可維護性、可復(fù)用性、可適應(yīng)性、可移植性、可跟蹤性并滿足用戶需求的軟件產(chǎn)品。抽象、信息隱藏、模塊化、局部化、一致性、完全性、可驗證性第七頁，共664頁。目標(biāo)可修改性有效性可靠性可理解性可維護性可復(fù)用性可適應(yīng)性可移植性可追蹤性基本目標(biāo)：付出較低的開發(fā)成本達到要求的軟件功能取得較好的軟件性能開發(fā)的軟件易于移植需要較低的維護費用能按時完成開發(fā)工作及時交付使用軟件工程的目標(biāo)是提高軟件的質(zhì)量與生產(chǎn)率，最終實現(xiàn)軟件的工業(yè)化生產(chǎn)。

第八頁，共664頁。軟件工程的原則抽象

采用分層次抽象，自頂向下、逐層細化的辦法控制軟件開發(fā)過程的復(fù)雜性信息隱蔽

將模塊設(shè)計成“黑箱”，實現(xiàn)的細節(jié)隱藏在模塊內(nèi)部，不讓模塊的使用者直接訪問。這就是信息封裝，使用與實現(xiàn)分離的原則模塊化

如C語言程序中的函數(shù)過程，C++語言程序中的類。模塊化有助于信息隱蔽和抽象，有助于表示復(fù)雜的系統(tǒng)。第九頁，共664頁。軟件工程的原則局部化

要求在一個物理模塊內(nèi)集中邏輯上相互關(guān)聯(lián)的計算機資源，保證模塊之間具有松散的耦合，模塊內(nèi)部具有較強的內(nèi)聚。這有助于控制解的復(fù)雜性確定性

軟件開發(fā)過程中所有概念的表達應(yīng)是確定的、無歧義性的、規(guī)范的。一致性

整個軟件系統(tǒng)的各個模塊應(yīng)使用一致的概念、符號和術(shù)語。程序內(nèi)部接口應(yīng)保持一致。軟件和硬件、操作系統(tǒng)的接口應(yīng)保持一致。系統(tǒng)規(guī)格說明與系統(tǒng)行為應(yīng)保持一致。用于形式化規(guī)格說明的公理系統(tǒng)應(yīng)保持一致第十頁，共664頁。軟件工程的原則完全性

軟件系統(tǒng)不丟失任何重要成分，可以完全實現(xiàn)系統(tǒng)所要求功能的程度。為了保證系統(tǒng)的完備性，在軟件開發(fā)和運行過程中需要嚴格的技術(shù)評審?？沈炞C性

開發(fā)大型的軟件系統(tǒng)需要對系統(tǒng)自頂向下、逐層分解。系統(tǒng)分解應(yīng)遵循系統(tǒng)易于檢查、測試、評審的原則，以確保系統(tǒng)的正確性。第十一頁，共664頁。軟件工程的原則復(fù)雜問題子問題1子問題2子問題n程序1程序2程序n軟件系統(tǒng)解決原始問題集成分解第十二頁，共664頁。1.2軟件生存周期Softwarelifecycle軟件產(chǎn)品從形成概念開始，經(jīng)過開發(fā)、使用和維護，直到最后退役的全過程稱為軟件生存周期軟件有一個孕育、誕生、成長、成熟、衰亡的生存過程。這個過程即為計算機軟件的生存周期軟件定義-軟件開發(fā)-軟件使用和維護軟件定義(系統(tǒng)分析)：可行性研究(軟件計劃)、需求分析軟件開發(fā)(系統(tǒng)設(shè)計)：概要設(shè)計、詳細設(shè)計、軟件實現(xiàn)(編碼、單元測試)、軟件測試(組裝測試、確認測試)軟件使用、維護退役第十三頁，共664頁。第十四頁，共664頁。軟件生存周期可行性研究確定要開發(fā)軟件系統(tǒng)的總目標(biāo)給出功能、性能、可靠性以及接口等方面的要求完成該軟件任務(wù)的可行性研究估計可利用的資源

、成本、效益、開發(fā)進度制定出完成開發(fā)任務(wù)的實施計劃，連同可行性研究報告，提交管理部門審查需求分析對用戶提出的要求進行分析并給出詳細的定義編寫軟件需求說明書或系統(tǒng)功能說明書及初步的系統(tǒng)用戶手冊提交管理機構(gòu)評審第十五頁，共664頁。軟件生存周期概要設(shè)計

—把各項需求轉(zhuǎn)換成軟件的體系結(jié)構(gòu)。結(jié)構(gòu)中每一組成部分都是意義明確的模塊，每個模塊都和某些需求相對應(yīng)，編寫設(shè)計說明書，評審詳細設(shè)計

—對每個模塊要完成的工作進行具體的描述，為源程序編寫打下基礎(chǔ)，編寫設(shè)計說明書，提交評審軟件構(gòu)造把軟件設(shè)計轉(zhuǎn)換成計算機可以接受的程序代碼，即以某一種特定程序設(shè)計語言表示的“源程序清單”；程序應(yīng)當(dāng)是結(jié)構(gòu)良好、清晰易讀的，且與設(shè)計相一致的。第十六頁，共664頁。軟件生存周期軟件測試單元測試，查找各模塊在功能和結(jié)構(gòu)上存在的問題并加以糾正

集成測試，將已測試過的模塊按一定順序組裝測試確認測試，按規(guī)定的各項需求，逐項進行有效性確認測試，決定已開發(fā)的軟件是否合格，能否交付用戶使用使用與維護：在用戶特定的環(huán)境中，在測試通過后移交用戶使用改正性維護：運行中發(fā)現(xiàn)軟件中的錯誤需要修正適應(yīng)性維護：為了適應(yīng)變化了的軟件工作環(huán)境，需做適當(dāng)變更完善性維護：為了增強軟件的功能需做變更第十七頁，共664頁。1.3軟件開發(fā)過程模型軟件開發(fā)過程模型是跨越整個生存期的系統(tǒng)開發(fā)、運作和維護所實施的全部過程、活動和任務(wù)的結(jié)構(gòu)框架瀑布模型原型模型螺旋模型統(tǒng)一軟件開發(fā)過程第十八頁，共664頁。瀑布模型（生存周期模型）W.W.Royce1970提出瀑布模型，是既自頂向下結(jié)構(gòu)化開發(fā)模型優(yōu)點：奠定了軟件工程方法的基礎(chǔ)；流水依賴；便于分工協(xié)作；推遲現(xiàn)實；文檔易修改；有復(fù)審質(zhì)量保證。缺點：用戶需求明確困難；用戶見面晚；糾錯慢；難于克服系統(tǒng)分析員不懂專業(yè)領(lǐng)域的知識，用戶不懂計算機的困難，成功率低。適合于系統(tǒng)要求明確的小系統(tǒng)。第十九頁，共664頁。帶反饋的瀑布模型第二十頁，共664頁?？焖僭湍Ｐ蛂apidprototypemodel根據(jù)用戶提出的軟件定義，快速的開發(fā)一個原型，在征求用戶對原型意見的過程中，再進一步修改、完善，直至達成一致。模擬軟件的人機界面開發(fā)一個原型，實現(xiàn)部分功能向用戶展示正在運行的類似軟件優(yōu)點：與用戶見面快；開發(fā)成功率高，適合于需求不確定的大系統(tǒng)。缺點：周期長，開發(fā)成本高。第二十一頁，共664頁?？焖僭湍Ｐ偷诙?，共664頁。螺旋模型螺旋模型沿著螺線旋轉(zhuǎn)（一個螺旋式周期），在四個象限上分別表達四個方面的活動，即：制定計劃──確定軟件目標(biāo)，選定實施方案，弄清項目開發(fā)的限制，選定完成目標(biāo)的策略風(fēng)險分析──分析所選方案，考慮如何識別和消除風(fēng)險，風(fēng)險角度分析該策略實施工程──實施軟件開發(fā)，啟動一個開發(fā)階段客戶評估──評價前一步開發(fā)工作，提出修正建議，計劃下一輪的工作特點瀑布模型+快速原型+風(fēng)險分析迭代過程第二十三頁，共664頁。第二十四頁，共664頁。統(tǒng)一軟件開發(fā)過程統(tǒng)一軟件開發(fā)過程(RUP,RationalUnifiedProcess)是一套軟件工程過程，是一套軟件工程方法的框架，各個組織可根據(jù)自身的實際情況，以及項目規(guī)模對RUP進行裁剪和修改，以制定出合乎需要的軟件工程過程。適合與統(tǒng)一建模語言(UML,UnifiedModelLanguage）結(jié)合起來使用支持六大最佳軟件開發(fā)實踐迭代式開發(fā)管理需求基于構(gòu)建的軟件體系結(jié)構(gòu)可視化建模驗證軟件質(zhì)量控制變更第二十五頁，共664頁。統(tǒng)一軟件開發(fā)過程第二十六頁，共664頁。統(tǒng)一軟件開發(fā)過程橫軸：時間軸，表示軟件開發(fā)的順序開啟階段精化階段構(gòu)建階段產(chǎn)品化階段縱軸：“誰”在“何時”、“如何”去做“何事”9個工作流程各個階段實施的工作流程，在不同的時間段內(nèi)工作流所占工作量不同第二十七頁，共664頁。1.4軟件設(shè)計對軟件如何被開發(fā)出來的一種規(guī)范化描述軟件需求分析和軟件設(shè)計受到重視編碼所占比例越來越少軟件設(shè)計的重要性對軟件需求的直接體現(xiàn)為軟件實現(xiàn)提供直接依據(jù)考慮軟件系統(tǒng)的各種約束條件并給出相應(yīng)方案決定最終軟件系統(tǒng)的質(zhì)量及早發(fā)現(xiàn)軟件設(shè)計中存在的錯誤減少軟件修復(fù)和維護的成本第二十八頁，共664頁。1.4軟件設(shè)計軟件設(shè)計的特征出現(xiàn)新的問題需要軟件來解決、解決問題和實施決策的過程、一系列轉(zhuǎn)換過程、滿足各種約束的過程過程、不斷演化的過程、給出一個方案、新思路、新想法軟件設(shè)計的要素目標(biāo)描述、設(shè)計約束、產(chǎn)品描述、設(shè)計原理、開發(fā)規(guī)劃、使用描述第二十九頁，共664頁。1.5軟件體系結(jié)構(gòu)軟件設(shè)計是從軟件需求到軟件實現(xiàn)的活動，它把各種軟件需求轉(zhuǎn)換為能直接實現(xiàn)的軟件結(jié)構(gòu)軟件需求與軟件設(shè)計之間存在難以逾越的鴻溝，如何有效的將軟件需求軟化為相應(yīng)的設(shè)計？軟件需求——？——軟件設(shè)計——軟件實現(xiàn)—軟件體系結(jié)構(gòu)第三十頁，共664頁。1.5軟件體系結(jié)構(gòu)軟件體系結(jié)構(gòu)的定義軟件體系結(jié)構(gòu)是軟件系統(tǒng)的結(jié)構(gòu)，包含軟件元素、軟件元素外部可見的屬性以及這些軟件元素之間的關(guān)系；軟件體系結(jié)構(gòu)是軟件系統(tǒng)的基本組織、包含構(gòu)件、構(gòu)件之間、構(gòu)件與環(huán)境之間的關(guān)系，以及相關(guān)的設(shè)計與演化原則；軟件體系結(jié)構(gòu)是程序或系統(tǒng)中組件的結(jié)構(gòu)、組件之間的相互關(guān)系、設(shè)計的基本原則以及隨時間進化的指導(dǎo)方針；第三十一頁，共664頁。1.5軟件體系結(jié)構(gòu)軟件體系結(jié)構(gòu)的發(fā)展歷程“無體系結(jié)構(gòu)”設(shè)計階段萌芽階段以匯編語言進行小規(guī)模應(yīng)用程序開發(fā)為特征以描述系統(tǒng)的高層抽象結(jié)構(gòu)為中心，不關(guān)心具體的建模細節(jié)，劃分了體系結(jié)構(gòu)模型與傳統(tǒng)軟件結(jié)構(gòu)的界限，該階段以Kruchten提出的“4+1”模型為標(biāo)志出現(xiàn)了從不同側(cè)面描述系統(tǒng)的結(jié)構(gòu)模型，以UML為典型代表。出現(xiàn)了程序結(jié)構(gòu)設(shè)計主題，以控制流圖和數(shù)據(jù)流圖構(gòu)成軟件結(jié)構(gòu)為特征高級階段初期階段第三十二頁，共664頁。1.5軟件體系結(jié)構(gòu)軟件體系結(jié)構(gòu)的內(nèi)容軟件體系結(jié)構(gòu)的描述：軟件體系結(jié)構(gòu)描述語言軟件體系結(jié)構(gòu)的設(shè)計方法軟件體系結(jié)構(gòu)的分析方法軟件體系結(jié)構(gòu)的復(fù)用第三十三頁，共664頁。本章完第三十四頁，共664頁。

第二章：統(tǒng)一建模語言UML第三十五頁，共664頁。內(nèi)容2.1 UML概述2.2 面向?qū)ο箝_發(fā)方法2.3 UML2.0結(jié)構(gòu)建模2.4 UML2.0行為建模第三十六頁，共664頁。（1）UML的發(fā)展歷程多種面向?qū)ο蠓治雠c設(shè)計方法的存在不利于面向?qū)ο蠓椒ǖ陌l(fā)展，也給用戶的選擇帶來一些困惑。1994年Booch和Rumbaugh首先將各自先前的研究成果統(tǒng)一起來，于1995年10月發(fā)布了UM0.8。經(jīng)過Booch、Rumbaugh和Jacobson三人的共同努力，于1996年發(fā)布UML0.9，并從此將UM命名為UML。UML結(jié)束了“模型論戰(zhàn)”，融合了眾多優(yōu)秀的面向?qū)ο蠼７椒ㄒ约败浖こ谭椒?，消除了因建模方法相互獨立帶來的諸多不便。第三十七頁，共664頁。UML2.01997年對象管理組織（ObjectManagementGroup，OMG）采納UML作為其標(biāo)準建模語言，并通過嚴格有序的OMG過程對其進行修訂和維護。1999，UML1.3，相對穩(wěn)定成熟階段2001-05，UML1.42003年6月宣告完成了UML2.0：Infrastructure（底層結(jié)構(gòu)）Superstructure（上層結(jié)構(gòu)）OCL（對象約束語言）DiagramInterchange（圖形交換）第三十八頁，共664頁。UML2.0UML2.0另一個顯著特征就是加強了對模型驅(qū)動體系（ModelDrivenArchitecture，MDA）的支持。MDA的目標(biāo)是要實現(xiàn)從UML模型到最終代碼的自動化生成。UML已經(jīng)迅速成為軟件設(shè)計語言的事實標(biāo)準。本章介紹UML2.0上層結(jié)構(gòu)中規(guī)定的各種模型的語法和用途。第三十九頁，共664頁。（2）UML的特點和用途為使用者提供了統(tǒng)一的、表達能力強大的可視化建模語言，以描述應(yīng)用問題的需求模型、設(shè)計模型和實現(xiàn)模型。提供對核心概念的擴展機制，用戶可加入核心概念中沒有的概念和符號，可為特定應(yīng)用領(lǐng)域提出具體的概念、符號表示和約束。獨立于實現(xiàn)語言和方法學(xué)，但支持所有的方法學(xué)，覆蓋了面向?qū)ο蠓治龊驮O(shè)計的相關(guān)概念和方法學(xué)。獨立于任何開發(fā)過程，但支持軟件開發(fā)全過程。提供對建模語言進行理解的形式化基礎(chǔ)，用元模型描述基本語義，OCL描述良定義規(guī)則，自然語言描述動態(tài)語義。增強面向?qū)ο蠊ぞ咧g的互操作性，便于不同系統(tǒng)間的集成。支持較高抽象層次開發(fā)所需的各種概念，如協(xié)同、框架、模式和構(gòu)件等，便于系統(tǒng)的重用。第四十頁，共664頁。（3）UML2.0建模機制13種視圖模型，分為結(jié)構(gòu)視圖和行為視圖結(jié)構(gòu)視圖：描述系統(tǒng)中各種元素之間的組織結(jié)構(gòu)關(guān)系行為視圖：描述系統(tǒng)中有關(guān)元素的行為過程第四十一頁，共664頁。（3）UML2.0的建模機制結(jié)構(gòu)建模：類圖包圖對象圖構(gòu)件圖組合結(jié)構(gòu)圖部署圖行為建模：活動圖順序圖通信圖交互概覽圖時序圖狀態(tài)圖用例圖第四十二頁，共664頁。UML2.0的建模機制第四十三頁，共664頁。內(nèi)容2.1 UML概述2.2 面向?qū)ο箝_發(fā)方法2.3 UML2.0結(jié)構(gòu)建模2.4 UML2.0行為建模第四十四頁，共664頁。面向?qū)ο蠓椒嫦驅(qū)ο箝_發(fā)方法通過提供對象、對象間消息傳遞等語言機制讓軟件開發(fā)人員在解空間中直接模擬問題空間中的對象及其行為。削減了語義斷層，拉近了問題空間與解空間的距離，簡化了軟件工程師為問題尋找解的工作，并為軟件開發(fā)活動提供了直觀、自然的語言支持和方法學(xué)指導(dǎo)。第四十五頁，共664頁。面向?qū)ο蟮幕靖拍罨靖拍?/p>

面向?qū)ο?對象+類+繼承+聚集+多態(tài)+消息對象:現(xiàn)實世界中個體或事物的抽象表示，是其屬性和相關(guān)操作的封裝。類:某些對象的共同特征（屬性和操作）的表示。對象是類的實例，類是創(chuàng)建對象的模板。繼承聚集:部分—整體關(guān)系多態(tài):父類及其子類中，對外接口的定義形式相同，卻可以對應(yīng)多種接口的實現(xiàn)形態(tài)（重寫、重載）。消息:對象和對象之間是通過傳遞消息來完成相互通信，對象與外部世界相互關(guān)聯(lián)的唯一途徑。第四十六頁，共664頁。（2）面向?qū)ο蠓椒ǖ膬?yōu)勢簡化軟件開發(fā)過程支持軟件復(fù)用改善軟件結(jié)構(gòu)第四十七頁，共664頁。內(nèi)容2.1 UML概述2.2 面向?qū)ο箝_發(fā)方法2.3 UML2.0結(jié)構(gòu)建模2.4 UML2.0行為建模第四十八頁，共664頁。結(jié)構(gòu)建模結(jié)構(gòu)建模也稱為靜態(tài)建模，主要用來描述系統(tǒng)中包含的元素以及元素之間的關(guān)系。結(jié)構(gòu)建模中的視圖可以對各個層次和階段的軟件進行刻畫，例如軟件設(shè)計、軟件實現(xiàn)、系統(tǒng)部署等。這些模型對系統(tǒng)的邏輯結(jié)構(gòu)或物理結(jié)構(gòu)進行描述，并不涉及系統(tǒng)的動態(tài)行為和過程。UML2.0中的結(jié)構(gòu)建模包括類圖、包圖、對象圖、構(gòu)件圖、組合結(jié)構(gòu)圖和部署圖。第四十九頁，共664頁。結(jié)構(gòu)建模本節(jié)結(jié)構(gòu)建模視圖模型如下：包圖包、依賴關(guān)系、導(dǎo)入關(guān)系、合并關(guān)系對象圖構(gòu)件圖構(gòu)件、接口、裝配連接子、委托連接子組合結(jié)構(gòu)圖部署圖第五十頁，共664頁。（1）類圖類圖是UML中最基本、也是最重要的一種視圖，它用來刻畫軟件中類等元素的靜態(tài)結(jié)構(gòu)和關(guān)系。類圖的圖元：類、抽象類、接口、依賴關(guān)系、關(guān)聯(lián)關(guān)系、聚集關(guān)系、構(gòu)成關(guān)系、泛化（繼承）關(guān)系、實現(xiàn)關(guān)系、關(guān)聯(lián)類第五十一頁，共664頁。類描述具有相同特征、約束和語言的一類對象，這些對象具有共同的屬性和操作。Customer+Buy():void+Pay():void+name:string#address:stringCustomer類名屬性：類型操作+:Visiblea：詳細設(shè)計的類b：簡單表示的類：僅給出類名第五十二頁，共664頁。抽象類一個類只提供操作名，而不對其進行實現(xiàn)，對這些操作的實現(xiàn)可以由其子類進行，并且不同的子類可以對同一操作進行不同的實現(xiàn)。不能被實例化的類，一般至少包含一個抽象操作+Buy():void+Pay():voidCustomer類名，斜體字符表示抽象類第五十三頁，共664頁。接口聲明一些屬性或方法，但并不實現(xiàn)它們。用來規(guī)定一種契約，對接口進行實現(xiàn)的元素（類）必須遵循該契約。構(gòu)造型和圓圈兩種表示。構(gòu)造型表示的接口接口名標(biāo)識元素類型與接口相連的是對接口進行實現(xiàn)的類第五十四頁，共664頁。依賴關(guān)系兩個類之間存在依賴關(guān)系，表明一個類使用或需要知道另一個類中包含的信息，用虛線箭頭表示第五十五頁，共664頁。關(guān)聯(lián)關(guān)系兩個類之間存在關(guān)聯(lián)關(guān)系，表明這兩個類的實例之間存在語義上的聯(lián)系。關(guān)聯(lián)可以具有方向性(有單方向關(guān)聯(lián)，雙方向關(guān)聯(lián))。

多重性意義11個并且只有一個0。。*或者*0到無限1。。*1到無限2。。42到4的范圍2，42或者4第五十六頁，共664頁。聚集關(guān)系聚集關(guān)系是一種特殊的關(guān)聯(lián)，表示兩個類的實例之間存在一種擁有或?qū)儆陉P(guān)系，是較弱的“整體—部分”關(guān)系，或是邏輯上的“隸屬”關(guān)系。整體（上級）類一側(cè)有一個空心菱形的圖。PersonCompany*1第五十七頁，共664頁。構(gòu)成關(guān)系構(gòu)成關(guān)系表明兩個類的實體間存在一種包含關(guān)系，是比聚聚關(guān)系更強的“整體—部分”關(guān)系，部分對象在任何時候都只能屬于一個整體對象，整體對象被破壞則部分對象也被破壞。用實心菱形表示，菱形在整體一側(cè)。第五十八頁，共664頁。泛化（繼承）關(guān)系第五十九頁，共664頁。實現(xiàn)關(guān)系實現(xiàn)關(guān)系表示一個元素是對另一個元素的實現(xiàn)第六十頁，共664頁。關(guān)聯(lián)類關(guān)聯(lián)類用來記錄與關(guān)聯(lián)（關(guān)系）有關(guān)的信息，提供與關(guān)聯(lián)有關(guān)的操作。第六十一頁，共664頁。（2）包圖包圖在UML中可以看作是類圖的一部分。包用來對一組元素進行劃分，是對復(fù)雜模型的一種分而治之的層次劃分。常用來描述一個復(fù)雜系統(tǒng)邏輯上的子系統(tǒng)劃分。包圖主要由包和包之間的關(guān)系組成。包的劃分應(yīng)遵循高內(nèi)聚、低耦合的原則，一個包中可以包含多個類和子包。包圖的圖元：包、依賴關(guān)系、導(dǎo)入關(guān)系、合并關(guān)系第六十二頁，共664頁。包第六十三頁，共664頁。依賴關(guān)系如果包中的元素之間存在依賴關(guān)系，則包存在依賴關(guān)系。OrderManager包中的類依賴于SystemInterface包中的某個類第六十四頁，共664頁。導(dǎo)入關(guān)系當(dāng)一個包（CustomerManager）中的元素訪問另一個包（OrderManager）中的元素時，需要給出被訪問元素的完整名稱，如OrderManager::Order。如果把OrderManager包中的元素導(dǎo)入到CustomerManager中，則可以使用直接訪問Order類。《import》導(dǎo)入?！禷cess》導(dǎo)入：被導(dǎo)入元素的可見性是private，不可以被其他包使用。第六十五頁，共664頁。導(dǎo)入關(guān)系第六十六頁，共664頁。導(dǎo)入關(guān)系第六十七頁，共664頁。合并關(guān)系把一個包中的內(nèi)容合并到另一個包中，合并后的包擁有兩個包中的內(nèi)容，可見性為private的元素不被合并，具有相同名字的元素通過泛化關(guān)系連接起來。第六十八頁，共664頁。（3）對象圖對象圖是看作類圖的實例，對象之間的連接是類之間關(guān)聯(lián)關(guān)系的實例。對象名：所屬的類；可以出現(xiàn)一個類的多個實例。第六十九頁，共664頁。（4）構(gòu)件圖基于構(gòu)件的軟件開發(fā)日益受到重視，UML2.0對構(gòu)件圖進行較大的改進。構(gòu)件的根本特征在于它的封裝性和可復(fù)用性，其內(nèi)部結(jié)構(gòu)被隱藏起來，只通過接口向外部提供服務(wù)或請求外部的服務(wù)。通過明確構(gòu)件對運行環(huán)境的假設(shè)（即接口定義），可以將構(gòu)件封裝起來，盡可能的獨立，從而為復(fù)用提供支持。構(gòu)件圖用來描述系統(tǒng)中存在的構(gòu)件、構(gòu)件具有的接口、以及各個構(gòu)件怎樣通過接口連接起來形成一個完整的系統(tǒng)。第七十頁，共664頁。（4）構(gòu)件圖構(gòu)件圖的圖元：構(gòu)件、接口、裝配連接子、委托連接子構(gòu)件是系統(tǒng)中具有良好封裝、可替換的模塊簡單構(gòu)件構(gòu)件的表示符號：復(fù)雜構(gòu)件內(nèi)部有實現(xiàn)細節(jié)，可以是構(gòu)件或者是類第七十一頁，共664頁。（4）構(gòu)件的依賴關(guān)系一個構(gòu)件需要用到另一個構(gòu)件的信息第七十二頁，共664頁。接口一個構(gòu)件與其他構(gòu)件之間通過具有規(guī)范定義的接口進行交互，這使得一個構(gòu)件可以被另一個具有相同接口定義的構(gòu)件替換（換燈泡）。需求接口（RequiredInterface）提供接口（ProvidedInterface）第七十三頁，共664頁。裝配連接子把一個構(gòu)件的服務(wù)和另一構(gòu)件的需求連接起來第七十四頁，共664頁。委托連接子復(fù)雜構(gòu)件包括多個子構(gòu)件，復(fù)雜構(gòu)件的需求和提供接口的功能應(yīng)由其某個子構(gòu)件完成。把復(fù)雜構(gòu)件的外部接口與內(nèi)部子構(gòu)件的接口映射起來，由端口（port）和委托連接子（delegate）描述。端口由一個小方框表示，一個端口可以對應(yīng)多個接口，方向是從需求方指向提供服務(wù)方。第七十五頁，共664頁。委托連接子需求接口委托給Customer子構(gòu)件的Account需求接口提供接口委托給Order子構(gòu)件的OrderState提供接口第七十六頁，共664頁。（5）組合結(jié)構(gòu)圖為了描述復(fù)雜系統(tǒng)在運行時的結(jié)構(gòu)，組合結(jié)構(gòu)圖通過內(nèi)部結(jié)構(gòu)、端口、協(xié)作等概念，描述系統(tǒng)、對象、協(xié)作實例等元素之間的結(jié)構(gòu)關(guān)系。組合結(jié)構(gòu)圖中可以使用類圖、對象圖、構(gòu)件圖中的有關(guān)圖元，也可以有自己獨特的建模元素。第七十七頁，共664頁。組合結(jié)構(gòu)圖中的端口端口q是一個行為端口，與一狀態(tài)連接，狀態(tài)用來解釋端口運行時的行為端口p在運行中有兩個實例第七十八頁，共664頁。組合結(jié)構(gòu)組合結(jié)構(gòu)圖可用來描述系統(tǒng)及其組成部分，組成部分的描述類似于對象圖中的對象，但組合結(jié)構(gòu)圖可以說明該部分屬于哪個系統(tǒng)。第七十九頁，共664頁。協(xié)作組合結(jié)構(gòu)圖能夠描述表示系統(tǒng)功能行為的協(xié)作（Collaboration）及其內(nèi)部的實現(xiàn)結(jié)構(gòu)，并且協(xié)作可以實例化，第八十頁，共664頁。（6）部署圖部署圖用來描述軟件開發(fā)過程中生成的物理文件形式的軟件或信息、運行平臺中的物理節(jié)點和通信，以及軟件文件到相應(yīng)硬件節(jié)點的部署或映射。制品：物理文件形式的軟件或信息，如：源代碼文件、文檔、模型文件等。節(jié)點：運行平臺中的硬件，節(jié)點間通過通信路徑進行消息傳遞。描述制品怎樣在節(jié)點上部署以及節(jié)點之間如何連接第八十一頁，共664頁。（6）部署圖

第八十二頁，共664頁。內(nèi)容2.1 UML概述2.2 面向?qū)ο箝_發(fā)方法2.3 UML2.0結(jié)構(gòu)建模2.4 UML2.0行為建模第八十三頁，共664頁。行為建模行為建模也常被稱為動態(tài)建模，它主要用來刻畫系統(tǒng)中的動態(tài)行為、過程和步驟。UML行為建模中提供的視圖可以從不同側(cè)面來描述軟件系統(tǒng)的動態(tài)過程。結(jié)構(gòu)建模對系統(tǒng)中的元素及其關(guān)系進行描述，而行為建模對這些元素完成特定任務(wù)的過程進行描述，兩者相互結(jié)合就能夠完整地描述整個系統(tǒng)的特征。第八十四頁，共664頁。（1）活動圖活動圖主要描述一個系統(tǒng)行為的執(zhí)行過程或步驟，它的適用范圍非常廣泛，能夠用來描述工作流、過程流、算法步驟等從問題域到解空間的任何能夠用流的形式描述的行為，可以用于概念層、設(shè)計層、實現(xiàn)層等不同抽象層次的系統(tǒng)行為建模。第八十五頁，共664頁?；顒雍蛣幼骰顒邮前唤M動作的行為，動作是活動中的一個步驟。初始/終止節(jié)點、初始/動作、動作第八十六頁，共664頁。對象節(jié)點為了增強對活動的表達能力，活動圖還有一些特殊的節(jié)點，以表示活動的輸入、輸出，以及動作之間傳遞的復(fù)雜對象。示例：兩個動作之間傳遞Order對象第八十七頁，共664頁?？刂乒?jié)點在實際的活動流程中，會經(jīng)常出現(xiàn)分支選擇情況。還有可能執(zhí)行完一個動作后，下面需要同時開始執(zhí)行幾個流程，或幾個流程完成后匯總為一個流程。分支節(jié)點，可標(biāo)明分支條件分叉節(jié)點匯合節(jié)點第八十八頁，共664頁?？刂乒?jié)點第八十九頁，共664頁。泳道為了能夠把動作按照執(zhí)行該動作的對象進行劃分，以明確活動中各個參與者的相應(yīng)職責(zé)，活動圖引入了泳道的概念。泳道可以是水平的，也可以是垂直的，或者二者同時存在。第九十頁，共664頁。泳道第九十一頁，共664頁。交互圖順序圖通信圖交互概覽圖時序圖第九十二頁，共664頁。（2）順序圖順序圖用來描述對象之間動態(tài)的交互關(guān)系，主要強調(diào)完成某個場景的對象之間存在哪些消息傳遞以及消息的時間序。順序圖的水平軸表示交互的不同對象，垂直虛線表示對象的生命線。對象間的通信表示為對象生命線之間的消息傳遞，消息有簡單消息、同步消息、異步消息等類型。消息有消息名，還可以有參數(shù)標(biāo)識，可以用條件表達式表示消息發(fā)送的條件。[發(fā)送條件]消息標(biāo)號：消息名（消息參數(shù)）第九十三頁，共664頁。簡單順序圖第九十四頁，共664頁。順序圖—交互操作對象的交互是一個很復(fù)雜的過程，使用交互片段（InteractionFragment）和片段組合（CombinedFragment）對復(fù)雜交互進行建模。多個交互片段通過交互操作（InteractionOperator）組合成為一個復(fù)雜的交互圖。片段組合：交互操作（1..*交互片段）=復(fù)雜交互圖交互操作：ref,alt,opt,par,loop,critical,neg,assert,strict,seq,ignore,consider,break圖2-31第九十五頁，共664頁。（3）通信圖關(guān)注參與交互的對象通過連接組成的結(jié)構(gòu)，消息和方向附屬于對象間的連接，并通過編號表示消息的順序。第九十六頁，共664頁。（3）通信圖第九十七頁，共664頁。（4）交互概覽圖交互概覽圖(interactionoverviewdiagram)是把順序圖和活動結(jié)合起來描述交互流程和交互細節(jié)的一種交互圖。交互概覽圖通過類似于活動圖的方式，描述交互之間的流程，給出交互控制流的概覽。在交互概覽圖中，節(jié)點不像活動圖中那樣是動作，而是一個交互圖或?qū)换D的引用。圖2-33第九十八頁，共664頁。（4）交互概覽圖第九十九頁，共664頁。（5）時序圖時序圖用來表示交互中關(guān)于消息時間的描述，并描述對象在生命線中，其所處狀態(tài)或條件隨著消息發(fā)生的變化。每個事件可給出時間約束。第一百頁，共664頁。時序圖的緊湊形式第一百零一頁，共664頁。（6）狀態(tài)圖狀態(tài)圖使用有窮狀態(tài)變遷圖的方式刻畫系統(tǒng)或元素的離散行為，可以用來描述一個類的實例、子系統(tǒng)甚至整個系統(tǒng)的在其生命周期內(nèi)，所處狀態(tài)如何隨著外部激勵而發(fā)生變化。在UML2.0中，狀態(tài)圖又分為行為狀態(tài)機和協(xié)議狀態(tài)機，前者描述一個建模元素的行為（例如對象），而后者描述一個協(xié)議的行為。第一百零二頁，共664頁。狀態(tài)與遷移狀態(tài)指所描述的元素在其生命周期中可位于一種相對穩(wěn)定的位置，狀態(tài)一般會（隱含）滿足一組條件。狀態(tài)的表示：狀態(tài)名，狀態(tài)中發(fā)生的動作/動作的類型，狀態(tài)之間存在遷移，即從一個狀態(tài)變化為另一個狀態(tài)。遷移條件：事件[條件]/動作第一百零三頁，共664頁。狀態(tài)圖第一百零四頁，共664頁。狀態(tài)圖—復(fù)合狀態(tài)一個狀態(tài)還可以再細分為若干個子狀態(tài)。復(fù)合狀態(tài)可以用來對狀態(tài)進行層次劃分，使得狀態(tài)圖具有良好的結(jié)構(gòu)，并且易于理解。復(fù)合狀態(tài)也有自己的初始狀態(tài)和終止?fàn)顟B(tài)。第一百零五頁，共664頁。狀態(tài)圖—復(fù)合狀態(tài)（1）第一百零六頁，共664頁。狀態(tài)圖—復(fù)合狀態(tài)（2）把內(nèi)部分成幾個正交的區(qū)域，每個區(qū)域內(nèi)都有一個狀態(tài)圖，幾個區(qū)域之間是并行執(zhí)行的，適用于描述具有并發(fā)狀態(tài)的對象。第一百零七頁，共664頁。偽狀態(tài)偽狀態(tài)是一些特殊的狀態(tài)：初始狀態(tài)和終止?fàn)顟B(tài)選擇（Choice）入口點（Entry）出口點（Exit）分岔（Fork）匯合（Join）深度歷史（DeepHistory）淺度歷史（ShallowHistory）……第一百零八頁，共664頁。（7）用例圖用例圖通常被用來描述系統(tǒng)的需求，從用戶的角度對系統(tǒng)的功能視點進行建模。一個用例表示系統(tǒng)的一個特定功能，是用戶與系統(tǒng)之間一次典型交互，能引發(fā)系統(tǒng)執(zhí)行一系列動作，并且動作執(zhí)行的結(jié)果能被用戶（或外部實體）覺察到。用例圖刻畫了系統(tǒng)包含哪些用例、用例之間、用例與外部角色之間的關(guān)系。第一百零九頁，共664頁。用例和參與者一個用例代表系統(tǒng)執(zhí)行的一組動作，這些動作完成特定的任務(wù)，并產(chǎn)生對用戶或外部實體可觀察的結(jié)果。用例用來描述系統(tǒng)對外可見的需求或功能。參與者是與用例發(fā)生交互的系統(tǒng)外部角色，必須是被開發(fā)的系統(tǒng)范圍之外的角色（不必在本開發(fā)系統(tǒng)中實現(xiàn)），它們只與系統(tǒng)發(fā)生某種形式的交互。第一百一十頁，共664頁。用例圖第一百一十一頁，共664頁。用例之間的關(guān)系包含關(guān)系（include）：表示一個用例執(zhí)行過程中，另一個用例也必須被執(zhí)行。通常把多個用例共享的行為提取出來形成一個用例，然后用包含關(guān)系連接起來。擴展關(guān)系（extend）：一個用例的功能需要通過其他用例進行擴展（在線幫助）。擴展用例只有在某些條件下才會被用到，UML提供了擴展點機制，在被擴展的用例中描述什么條件下執(zhí)行擴展用例。第一百一十二頁，共664頁。用例之間的關(guān)系第一百一十三頁，共664頁。本章完第一百一十四頁，共664頁。第3章

軟件設(shè)計基礎(chǔ)115第一百一十五頁，共664頁。什么是軟件架構(gòu)？辦公室里，關(guān)于什么是軟件架構(gòu)，爭論正酣。程序員說，軟件架構(gòu)就是要決定需要編寫哪些類、使用哪些現(xiàn)成框架。程序經(jīng)理說，軟件架構(gòu)就是模塊的劃分和接口的定義。系統(tǒng)分析員說，軟件架構(gòu)就是為業(yè)務(wù)領(lǐng)域?qū)ο蟮年P(guān)系建模。配置管理員說，軟件架構(gòu)就是開發(fā)出來的以及編譯過后的軟件到底是個啥結(jié)構(gòu)。數(shù)據(jù)庫工程師說，軟件架構(gòu)規(guī)定了持久化數(shù)據(jù)的結(jié)構(gòu)，其他一切只不過是對數(shù)據(jù)的操作而已。部署工程師說，軟件架構(gòu)規(guī)定了軟件部署到硬件的策略。用戶說，軟件架構(gòu)就是決定一個個功能子系統(tǒng)如何劃分。大家想了想說，這些架構(gòu)視圖好像我們都需要啊，軟件架構(gòu)師哭了?！鲜鰻幷摽梢钥偨Y(jié)為一句話：不同涉眾看待軟件架構(gòu)的視角是不同的。第一百一十六頁，共664頁。軟件設(shè)計是軟件開發(fā)過程中至關(guān)重要的部分，它的結(jié)果直接影響到最終的軟件質(zhì)量。不等同于“編程序”或“寫代碼”結(jié)構(gòu)化開發(fā)方法、面向?qū)ο箝_發(fā)方法、基于構(gòu)件的軟件開發(fā)方法形成各種系統(tǒng)化的軟件設(shè)計過程和技術(shù)。軟件設(shè)計是一個精化的過程，其中也包含多種活動，并需要靈活運用抽象、模塊化、求精等多種技術(shù)。第一百一十七頁，共664頁。內(nèi)容3.1 軟件設(shè)計的基本概念3.2 軟件設(shè)計過程3.3 軟件設(shè)計的質(zhì)量3.4 軟件體系結(jié)構(gòu)設(shè)計3.5 高可信軟件設(shè)計3.6 軟件設(shè)計規(guī)格說明3.7 軟件設(shè)計評審第一百一十八頁，共664頁。3.1軟件設(shè)計的基本概念軟件設(shè)計主要針對需求分析過程得到的軟件需求規(guī)格說明，綜合考慮各種制約因素，探求切實可行的軟件解決方案并最終給出方案的邏輯表示，包括文檔、模型等。軟件設(shè)計受到資源和技術(shù)兩方面的制約。資源：時間、人力、財力、開發(fā)工具。技術(shù)：方法、技術(shù)、平臺。第一百一十九頁，共664頁。軟件設(shè)計的最終目標(biāo)是獲得滿足軟件需求的、明確的、可行的、高質(zhì)量的軟件解決方案。明確：設(shè)計模型易于理解可行：在可用的技術(shù)平臺和軟件項目的可用資源條件下，須用預(yù)定的開發(fā)語言可構(gòu)造技術(shù)可以完整地實現(xiàn)設(shè)計模型高質(zhì)量：設(shè)計模型給出需求的實現(xiàn)方案，非功能需求的約束，設(shè)計模型優(yōu)化軟件設(shè)計基本概念是過去數(shù)十年里陸續(xù)提出的，軟件設(shè)計者根據(jù)這組概念進行設(shè)計決策。第一百二十頁，共664頁。（1）抽象與逐步求精“抽象”是一個心理學(xué)概念，它要求人們將注意力集中在某一層次上考慮問題，而忽略那些低層次的細節(jié)。是管理、控制復(fù)雜性的基本策略。軟件設(shè)計過程是在不同抽象級別考慮、處理問題的過程。最初應(yīng)該在最高抽象級別上，用面向問題域的語言概述問題，包括問題解的形式，然后不斷具體化，不斷用接近計算機域的語言描述問題，最后，在最低的抽象級別上給出可直接實現(xiàn)的問題解，即程序。第一百二十一頁，共664頁。（1）抽象與逐步求精軟件設(shè)過程的每一步都是對較高以及抽象的解作一次更具體化的描述。過程抽象：把完成特定功能的動作序列抽象為一個過程名和參數(shù)表，以后通過指定過程名和實際參數(shù)調(diào)用此過程。數(shù)據(jù)抽象：把一個數(shù)據(jù)對象的定義（或描述）抽象為一個數(shù)據(jù)類型名，用此類型名可定義多個具有相同性質(zhì)的數(shù)據(jù)對象。第一百二十二頁，共664頁。（1）抽象與逐步求精“逐步求精”可視為一種早期的自頂向下設(shè)計策略，其主要思想是，針對某個功能的宏觀描述用逐步求精的方法不斷地分解，逐步確立過程細節(jié)，直至該功能用程序語言描述的算法實現(xiàn)為止。在軟件設(shè)計過程中，抽象與逐步求精是一般都是結(jié)合起來進行應(yīng)用。系統(tǒng)的層次結(jié)構(gòu)的上一層是下一層的抽象，下一層是上一層的求精。第一百二十三頁，共664頁。第一百二十四頁，共664頁。（2）模塊化與信息隱藏軟件體系結(jié)構(gòu)體現(xiàn)了模塊化思想，即把軟件劃分為可獨立命名和訪問的部件，每個部件稱為一個模塊，當(dāng)把所有模塊組裝到一起時則獲得滿足問題需要的一個解。模塊化使得開發(fā)活動更加簡單的一個重要因素是模塊的信息隱藏，即一個模塊的開發(fā)者不必看到其它模塊的內(nèi)部，只需知道其接口即可，這使得每個模塊的開發(fā)人員所要處理的復(fù)雜性顯著降低。信息隱藏指導(dǎo)的模塊化設(shè)計不僅支持模塊的并行開發(fā)，而且還可以減少測試和維護的工作量。第一百二十五頁，共664頁。（2）模塊化與信息隱藏問題求解的研究表明，把兩個問題組合起來進行求解的復(fù)雜性，一般要比分別對兩個問題進行求解的復(fù)雜度之和更大，這個結(jié)論導(dǎo)致“分治法”的出現(xiàn)，即把一個復(fù)雜問題分割成若干個可管理的、更易于求解的小問題。但這種分割并不意味著“無限”分割，當(dāng)模塊數(shù)量增加時，模塊接口所需要的代價也隨之增加。第一百二十六頁，共664頁。模塊數(shù)量與成本第一百二十七頁，共664頁。（2）模塊化與信息隱藏恰當(dāng)?shù)亩x模塊范圍和大小非常重要，這與采用的設(shè)計方法密切相關(guān)，評價所采用設(shè)計方法的標(biāo)準：模塊可分解性模塊的組裝性模塊的可理解性模塊連續(xù)性模塊保護第一百二十八頁，共664頁。內(nèi)聚與耦合每個模塊應(yīng)相對獨立，其功能相對單一，而模塊之間的接口應(yīng)盡可能簡單。內(nèi)聚是前述信息隱藏和局部化概念的自然擴展，它標(biāo)志一個模塊內(nèi)部各成分彼此結(jié)合的緊密程度。耦合是對軟件結(jié)構(gòu)中模塊間關(guān)聯(lián)程度的一種度量。耦合的強弱取決于模塊間接口的復(fù)雜性、進入或調(diào)用模塊的位置以及通過接口傳送數(shù)據(jù)的多少等。追求高內(nèi)聚、低耦合。（1）抽象與逐步求精第一百二十九頁，共664頁。內(nèi)聚內(nèi)聚按其高低程度可劃分為不同等級，內(nèi)聚度越高越好，從而獲得較高的模塊獨立性。低等級內(nèi)聚：偶然性內(nèi)聚：最低程序的內(nèi)聚邏輯性內(nèi)聚時序內(nèi)聚中等級內(nèi)聚：過程性內(nèi)聚通信性內(nèi)聚高級內(nèi)聚：順序性內(nèi)聚功能性內(nèi)聚：最高程度的內(nèi)聚第一百三十頁，共664頁。三、內(nèi)聚與耦合偶然性內(nèi)聚：一個模塊內(nèi)各成分為完成一組功能而組合在一起，它們相互之間即使用關(guān)系，也很松散邏輯性內(nèi)聚：模塊完成的諸任務(wù)邏輯上相關(guān)時序內(nèi)聚：一個模塊包含的任務(wù)必須在同一時間內(nèi)執(zhí)行過程性內(nèi)聚：模塊內(nèi)成分彼此相關(guān)，并且必須按特定的次序執(zhí)行通信內(nèi)聚：模塊中各成分都將對數(shù)據(jù)結(jié)構(gòu)的同一區(qū)域進行操作順序性內(nèi)聚：各成分均與同一功能相關(guān)，且處理按序執(zhí)行功能性內(nèi)聚：所有成分形成一個整體，完成單個功能第一百三十一頁，共664頁。模塊內(nèi)聚A:Readinputsfromdiskfromtapefrom……

邏輯內(nèi)聚（Logicalcohesion）：Logicallyrelatedfunctionsordataareplacedinthesamemodule.例如：

偶然性內(nèi)聚（Coincidentalcohesion）：Unrelatedfunctions,processes,ordataarefoundinthesamemodule(forconvenience).例如：工具模塊第一百三十二頁，共664頁。

時序內(nèi)聚（Temporalcohesion）：Thefunctionsarerelatedonlybythetiminginvolved.例如：系統(tǒng)的初始化問題：不同功能混在一個模塊中，有時共用部分編碼，使局部功能的修改牽動全局。第一百三十三頁，共664頁。

通信內(nèi)聚（Communicationalcohesion）：Allthefunctionsinamoduleoperateonorproducethesamedataset.例如：從同一磁帶上讀取不相干的數(shù)據(jù)——

可能破壞獨立性。

過程內(nèi)聚（Proceduralcohesion）：Functionsaregroupedtogetherinamoduletoensureacertainorderofperformance.例如：enterdatacheckdatamanipulatedata第一百三十四頁，共664頁。

高內(nèi)聚：

順序內(nèi)聚（Sequentialcohesion）：Theoutputfromonepartofamoduleistheinputtothenextpart.

功能內(nèi)聚（Functionalcohesion）：Everyprocessingelementisessentialtotheperformanceofasinglefunction.第一百三十五頁，共664頁。

c

模塊內(nèi)聚第一百三十六頁，共664頁。耦合耦合的強弱取決于模塊間接口的復(fù)雜性、進入或調(diào)用模塊的位置、通過接口傳輸數(shù)據(jù)量等。模塊間的耦合程度直接影響著系統(tǒng)的可理解性、可測試性、可靠性和可維護性，軟件設(shè)計應(yīng)追求盡可能松散的耦合，模塊間的聯(lián)系越少，錯誤在模塊間傳遞的可能性就越小。第一百三十七頁，共664頁。耦合耦合等級的劃分低等級耦合：非直接耦合中等級耦合數(shù)據(jù)耦合特征耦合控制耦合外部耦合公共耦合高等級耦合：內(nèi)容耦合傳遞的信息含有控制信息第一百三十八頁，共664頁。非直接耦合：兩個模塊中的任一個都不依賴對方能獨立工作。數(shù)據(jù)耦合：兩模塊間通過參數(shù)交換信息，數(shù)據(jù)僅限于數(shù)據(jù)?？刂岂詈希耗K間傳遞的信息含有控制信息。特征耦合：介于數(shù)據(jù)耦合和控制耦合之間。外部耦合：若干模塊均與同一外部環(huán)境關(guān)聯(lián)。公共耦合：若干模塊通過全局的數(shù)據(jù)環(huán)境相互作用。內(nèi)容耦合：一個模塊使用另一模塊內(nèi)部的數(shù)據(jù)或控制信息，或一個模塊直接轉(zhuǎn)移到另一模塊內(nèi)部。第一百三十九頁，共664頁。⑴耦合(Coupling)GreatdealofdependenceIndependent

HighlycoupledLooselycoupledUncoupled

第一百四十頁，共664頁。例1：A訪問C的內(nèi)部數(shù)據(jù)或不通過正常入口而轉(zhuǎn)入C的內(nèi)部?！瑼BCDA:……………………gotoC1……………………C:……………………C1:…………

內(nèi)容耦合(ContentCoupling):Onemodulemodifiesanother.第一百四十一頁，共664頁。例2：部分代碼重疊（常出現(xiàn)在匯編程序中）B

A例3：一個模塊有多個入口（功能）A:………………………………entry1:………………………………entry2:………………………………

Theleastdesirable第一百四十二頁，共664頁。

公共耦合

(Commoncoupling)：Dataareaccessiblefromacommondatastore.Global:V1V2A:……………………A1=V1+V2……………………B:……………………V1=B1……………………Global:V1V2A:……………………V1++……………………B:……………………V2=B1+V1……………………問題：

公共部分的改動將影響所有調(diào)用它的模塊；

公共部分的數(shù)據(jù)存取無法控制；

復(fù)雜程度隨耦合模塊的個數(shù)增加而增加。第一百四十三頁，共664頁。

控制耦合(Controlcoupling)：Onemodulepassesparameterstocontroltheactivityofanothermodule.ABFlagF2F1Fn…………Flag接口單一，但仍然影響被控模塊的內(nèi)部邏輯。

數(shù)據(jù)耦合(Datacoupling):Onlydataarepassed.Itiseasytotracedataandmakechanges.

Themostdesirable.原則：盡量使用數(shù)據(jù)耦合，少用控制耦合，限制公共耦合的范圍，完全不用內(nèi)容耦合。第一百四十四頁，共664頁。模塊間的耦合第一百四十五頁，共664頁。啟發(fā)性規(guī)則1.爭取低耦合、高內(nèi)聚（增加內(nèi)聚>減少耦合）2.模塊規(guī)模適中：過大不易理解；太小則接口開銷過大。注意分解后不應(yīng)降低模塊的獨立性。3.適當(dāng)控制——

深度=分層的層數(shù)。過大表示分工過細。

寬度=同一層上模塊數(shù)的最大值。過大表示系統(tǒng)復(fù)雜度大。第一百四十六頁，共664頁。啟發(fā)性規(guī)則系統(tǒng)結(jié)構(gòu)第一百四十七頁，共664頁。啟發(fā)性規(guī)則扇出=一個模塊直接調(diào)用\控制的模塊數(shù)。3fan-out9AA的扇出AA的扇入

扇入=直接調(diào)用該模塊的模塊數(shù)在不破壞獨立性的前提下，fan-in

大的比較好。第一百四十八頁，共664頁。啟發(fā)性規(guī)則盡可能減少高扇出結(jié)構(gòu)，隨著深度增大扇入。

如果一個模塊的扇出數(shù)過大，就意味著該模塊過分復(fù)雜，需要協(xié)調(diào)和控制過多的下屬模塊。應(yīng)當(dāng)適當(dāng)增加中間層次的控制模塊第一百四十九頁，共664頁。啟發(fā)性規(guī)則4、作用域在控制域內(nèi)

控制域MACBM的控制域為{M，A，B，C}

作用域：M中的一個判定所影響的模塊。例如：A:…………if……thengotoB1……………………B:……………………B1:……………………作用域在控制域內(nèi)A:…………if……thengotoM1……………………M:……………………M1:gotoC1……………………作用域超出了控制域上例中A的作用超出了控制域。改進方法之一，可以把A中的if

移到M中；方法之二，可以把C移到A下面。第一百五十頁，共664頁。啟發(fā)性規(guī)則5、降低接口的復(fù)雜程度：接口復(fù)雜可能表明模塊的獨立性差。6、單出單入，避免內(nèi)容耦合。7、模塊功能可預(yù)測——相同輸入必產(chǎn)生相同輸出。反例：模塊中使用全局變量或靜態(tài)變量，則可能導(dǎo)致不可預(yù)測。第一百五十一頁，共664頁。內(nèi)聚和耦合的量化指標(biāo)類耦合度類的耦合度為與它耦合的其它類的數(shù)目，包括調(diào)用其他類的方法、使用其它類的實例變量。一個類越獨立，它在應(yīng)用中就越容易被重用，類之間的耦合度應(yīng)盡可能的小。方法內(nèi)聚缺乏程度“不訪問相同成員變量的方法對數(shù)目”減去“訪問相同成員變量的方法對數(shù)目”如果一個類中沒有任何兩個方法對同一變量進行訪問，則它們沒有相似性，該類的內(nèi)聚程度將會很低，缺乏內(nèi)聚度意味著該類可以分為兩個或更多的類。第一百五十二頁，共664頁。內(nèi)容3.1 軟件設(shè)計的基本概念3.2 軟件設(shè)計過程3.3 軟件設(shè)計的質(zhì)量3.4 軟件體系結(jié)構(gòu)設(shè)計3.5 高可信軟件設(shè)計3.6 軟件設(shè)計規(guī)格說明3.7 軟件設(shè)計評審第一百五十三頁，共664頁。（1）軟件設(shè)計的一般過程軟件設(shè)計可能是一個多次反復(fù)的過程，所以，軟件設(shè)計一般都可以被看作是迭代的過程。迭代有兩層含義：第一層含義是，針對給定的需求模型，通過多次從抽象到具體的設(shè)計過程，得出足夠精細的設(shè)計模型以供軟件實現(xiàn)之用。第二層含義是，在需求模型發(fā)生變化并更新完成后，第一層含義的設(shè)計過程再隨之展開，直至獲得最終的目標(biāo)軟件產(chǎn)品。第一百五十四頁，共664頁。軟件設(shè)計的迭代第一百五十五頁，共664頁。軟件設(shè)計的一般過程軟件設(shè)計過程包括在不同抽象層次上開發(fā)系統(tǒng)的多個模型。軟件設(shè)計可以看作是將需求規(guī)格說明轉(zhuǎn)換為可直接提供軟件代碼實現(xiàn)使用的設(shè)計規(guī)格說明。工程管理的角度：概要設(shè)計：根據(jù)需求確定軟件和數(shù)據(jù)總體框架。詳細設(shè)計：進一步精化成軟件的算法表示和數(shù)據(jù)結(jié)構(gòu)。技術(shù)上，概要設(shè)計和詳細設(shè)計由若干活動組成，包括軟件體系結(jié)構(gòu)設(shè)計、界面設(shè)計、模塊/子系統(tǒng)設(shè)計、數(shù)據(jù)模型設(shè)計、過程/算法設(shè)計。第一百五十六頁，共664頁。軟件設(shè)計的一般過程第一百五十七頁，共664頁。1）軟件設(shè)計計劃在設(shè)計過程中，對設(shè)計活動進行計劃應(yīng)該最早進行，然后按照計劃實施體系結(jié)構(gòu)設(shè)計、界面設(shè)計、模塊/子系統(tǒng)設(shè)計、數(shù)據(jù)模型設(shè)計、過程/算法設(shè)計等活動。軟件設(shè)計計劃的任務(wù)是：明確設(shè)計過程的輸入制品并使其處于就緒狀態(tài)，定義設(shè)計過程的目標(biāo)、輸出制品及其驗收準則，確定覆蓋設(shè)計過程中各個階段的全局性設(shè)計策略，分配設(shè)計過程相關(guān)人員的職責(zé)，針對設(shè)計過程中的活動制訂工作計劃。第一百五十八頁，共664頁。1）軟件設(shè)計計劃軟件設(shè)計計劃的步驟：確定設(shè)計的目標(biāo)和驗收標(biāo)準明確目標(biāo)軟件系統(tǒng)應(yīng)遵循的技術(shù)標(biāo)準或規(guī)范重新審視項目風(fēng)險管理計劃制定本次設(shè)計過程的工作計劃對設(shè)計過程的工作計劃進行評審第一百五十九頁，共664頁。2）體系結(jié)構(gòu)設(shè)計軟件體系結(jié)構(gòu)設(shè)計的目標(biāo)是建立軟件系統(tǒng)的體系結(jié)構(gòu)，有時也稱“頂層架構(gòu)”。這種架構(gòu)既要明確定義軟件各子系統(tǒng)、關(guān)鍵構(gòu)件、關(guān)鍵類的職責(zé)劃分及協(xié)作關(guān)系，同時也要描繪它們在物理運行環(huán)境下的部署模型。頂層架構(gòu)還必須針對軟件系統(tǒng)全局性、基礎(chǔ)性的技術(shù)問題給出技術(shù)解決方案，這種方案往往構(gòu)成目標(biāo)軟件系統(tǒng)的體系結(jié)構(gòu)的技術(shù)基礎(chǔ)設(shè)施。第一百六十頁，共664頁。2）體系結(jié)構(gòu)設(shè)計評價軟件體系結(jié)構(gòu)寬度和深度：軟件控制的層數(shù)和跨度扇出率和扇入率：扇出率：一個模塊的扇出率指該模塊直接控制的其他模塊數(shù)。扇入率：一個模塊的扇入率指直接控制該模塊的模塊數(shù)?？梢娦院吐?lián)通性模塊的可見性：該模塊可直接或間接引用的一組模塊。模塊的聯(lián)通性：模塊可直接引用的一組模塊。第一百六十一頁，共664頁。軟件結(jié)構(gòu)有關(guān)概念第一百六十二頁，共664頁。3）界面設(shè)計用戶界面設(shè)計的目標(biāo)是，為用戶使用目標(biāo)軟件系統(tǒng)以實現(xiàn)其所有業(yè)務(wù)需求而提供友好的人機交互界面。軟件界面設(shè)計需要考慮以下因素：適用于軟件功能易理解性一致性靈敏性容錯性人性化國際化個性化合理的布局和諧的色彩界面的易用性界面的美觀性第一百六十三頁，共664頁。4）模塊/子系統(tǒng)設(shè)計子系統(tǒng)和模塊的區(qū)別：一個子系統(tǒng)獨立構(gòu)成系統(tǒng)，不依賴其它子系統(tǒng)提供的服務(wù)。一個模塊通常是一個能提供一個或多個服務(wù)的系統(tǒng)部件。它能利用其它模塊提供的服務(wù)，一般不被看成一個獨立的系統(tǒng)。由于模塊和子系統(tǒng)都是軟件組成部分，它們一般都有層次結(jié)構(gòu)，相互之間存在接口，其設(shè)計方法有很多類似的方面，因此我們統(tǒng)一稱為模塊設(shè)計。第一百六十四頁，共664頁。模塊設(shè)計的目標(biāo)模塊設(shè)計的目標(biāo)是，確定模塊的具體接口定義，并設(shè)計模塊的內(nèi)部結(jié)構(gòu)，即，設(shè)置包含于其中的（更小粒度的）模塊、構(gòu)件和設(shè)計類，明確它們之間的協(xié)作關(guān)系，確保它們能夠協(xié)同實現(xiàn)高層模塊接口規(guī)定的所有功能和行為。在進行模塊設(shè)計時，要盡量保持模塊的功能獨立性，遵循“高內(nèi)聚、低耦合”的設(shè)計思想。此外，還要力求將模塊的影響限制在模塊的控制范圍內(nèi)，使得軟件日后的修改和維護工作更加簡單。第一百六十五頁，共664頁。5）過程/算法設(shè)計過程/算法設(shè)計的任務(wù)就是對模塊內(nèi)部的工作和執(zhí)行過程進行描述，給出有關(guān)處理的精確說明，例如事件的順序、確切的決策位置、循環(huán)操作以及數(shù)據(jù)的組成等。軟件結(jié)構(gòu)與軟件過程相互關(guān)聯(lián)，軟件結(jié)構(gòu)中任何模塊的所有從屬模塊必將被引用出現(xiàn)在該模塊的過程說明中。因此，軟件過程對應(yīng)的結(jié)構(gòu)設(shè)計亦構(gòu)成一個層次結(jié)構(gòu)?？梢允褂肬ML對模塊進行設(shè)計第一百六十六頁，共664頁。使用UML的模塊過程設(shè)計第一百六十七頁，共664頁。6）數(shù)據(jù)模型設(shè)計我們把數(shù)據(jù)結(jié)構(gòu)設(shè)計、數(shù)據(jù)庫設(shè)計、甚至數(shù)據(jù)文件設(shè)計等統(tǒng)一稱為數(shù)據(jù)模型設(shè)計。在數(shù)據(jù)模型設(shè)計中有一個重要概念：持久數(shù)據(jù)操作，它包括寫入、查詢、更新和刪除四類基本操作以及由它們復(fù)合而成的業(yè)務(wù)數(shù)據(jù)操作。在很多軟件系統(tǒng)中，數(shù)據(jù)是其核心，因此，對數(shù)據(jù)元素的格式、結(jié)構(gòu)、訪存、表示等機制進行良好建模和優(yōu)化，是提高軟件設(shè)計質(zhì)量和系統(tǒng)性能的基礎(chǔ)，對軟件系統(tǒng)的應(yīng)用具有重要意義。第一百六十八頁，共664頁。內(nèi)容3.1 軟件設(shè)計的基本概念3.2 軟件設(shè)計過程3.3 軟件設(shè)計的質(zhì)量3.4 軟件體系結(jié)構(gòu)設(shè)計3.5 高可信軟件設(shè)計3.6 軟件設(shè)計規(guī)格說明3.7 軟件設(shè)計評審第一百六十九頁，共664頁。軟件設(shè)計質(zhì)量的重要性軟件設(shè)計是軟件開發(fā)過程中的核心活動，軟件設(shè)計的質(zhì)量不但對最終軟件產(chǎn)品的質(zhì)量起著決定性作用，還對軟件開發(fā)過程以及軟件以后在使用過程中維護的難易程度有著重要的影響。高質(zhì)量的軟件設(shè)計，能夠有效縮短軟件開發(fā)時間，減少開發(fā)成本，提高最終軟件產(chǎn)品質(zhì)量。第一百七十頁，共664頁。軟件設(shè)計的質(zhì)量要素評價軟件設(shè)計的質(zhì)量結(jié)構(gòu)良好充分性可行性簡單性實用性靈活性健壯性可移植性可復(fù)用性標(biāo)準化第一百七十一頁，共664頁。軟件設(shè)計的質(zhì)量軟件設(shè)計對最終軟件產(chǎn)品質(zhì)量產(chǎn)生的影響包括：正確性可靠性運行效率可移植性可維護性可復(fù)用性第一百七十二頁，共664頁。軟件設(shè)計的質(zhì)量軟件設(shè)計對軟件開發(fā)過程可能產(chǎn)生的影響包括：開發(fā)效率交付時間風(fēng)險管理資源使用成本人員培訓(xùn)合法性第一百七十三頁，共664頁。正確性目標(biāo):每個項目都要滿足指定的需求，然后一起滿足所有應(yīng)用程序的需求實現(xiàn)正確性的途徑：達到正確性的非正式方法完全理解－>模塊化達到正確性的正式方法第一百七十四頁，共664頁。達到正確性的非正式方法：充分設(shè)計一個設(shè)計足以實現(xiàn)需求一個正確的設(shè)計有時稱為設(shè)計必須完全可理解接下來設(shè)計非常模塊化達到這個目標(biāo)的方法是：。。。最小目標(biāo)第一百七十五頁，共664頁。達到正確性的正式方法基于在嚴密的控制下跟蹤變量的變化，一般會指定一個不變式。不變式在變量值之間表示的是一種不變關(guān)系。例如：length>=0length*breadth==areaoverdraft<OVERDRAFT_MAX用在類級別設(shè)計中的不變式稱為類不變式。例如1）mileage>=02)mileage<10000004)value>=-3005）originalPrice>=06）(type==“REGULAR”&&value<=originalPrice)||(type==“VINTAGE”&&value>=originalPrice)考慮不變式，將變量設(shè)為私有，只能通過公有的存取方法才能改變他們的值?？梢詫Υ嫒》椒ㄟM行編碼來保持不變式。如通過setter方法來設(shè)置類不變式精心設(shè)計的類通常擁有可理解的不變式集。第一百七十六頁，共664頁。1.防止錯誤輸入用戶輸入不是用戶的輸入數(shù)據(jù)通信其他應(yīng)用方法調(diào)用2.防止開發(fā)錯誤錯誤的設(shè)計錯誤的實現(xiàn)健壯性第一百七十七頁，共664頁。健壯性檢查輸入在繼續(xù)進行處理之前，可以檢查應(yīng)用程序的所有輸入的方法。檢查類型（例如：整形);

檢查與前置條件和不變式的輸入為提高健壯性而初始化提供靜態(tài)方法，用來為類產(chǎn)生標(biāo)準的默認值提高健壯性的參數(shù)傳遞技術(shù)保證方法正確調(diào)用引入一個捕獲參數(shù)的類并將約束條件合并強化意圖通過防止設(shè)計和實現(xiàn)中的錯誤來提高健壯性強化計劃，按計劃使用相應(yīng)功能第一百七十八頁，共664頁。Example:intcomputeArea(intaLength,intaBreadth){…}如果可行，捕獲在類中的參數(shù)約束intcomputeArea(RectangleDimensionaRectangleDimension)

在方法中說明所有的參數(shù)約束aLength>0andaBreadth>0andaLength>=aBreadth在方法代碼中首先檢查約束if(aLength<=0)……如果預(yù)計這種情況將會出現(xiàn)，則拋出異常否則，如果可能就中止程序否則如果返回的默認值在上下文之間有意義，就將其返回并且產(chǎn)生警告或日志參數(shù)的約束第一百七十九頁，共664頁。ReplaceintcomputeArea(intaLength,intaBreadth) {..}with intcomputeArea(RectangleaRectangle) {..}--whereclassRectangle {… Rectangle(intaLength,intaBreadth) { if(aLength>0)this.length=aLength; else….. } …} 只在一個地方進行錯誤處理，改進了設(shè)計與維護性，不足是產(chǎn)生了類的激增。第一百八十頁，共664頁。健壯性在使用數(shù)據(jù)之前進行檢查，可以提高健壯性。第一百八十一頁，共664頁。靈活性靈活性的預(yù)期目標(biāo)：用于增加更多類型功能的設(shè)計例如（銀行應(yīng)用）：處理更多類型的賬號而不需要修改已存在的代碼用于增加不同類型功能的設(shè)計例如：在存款功能的基礎(chǔ)上增加提款功能修改功能例如：可透支第一百八十二頁，共664頁。應(yīng)用中增加同類型功能的設(shè)計舉例：網(wǎng)站成員注冊WebSiteregister()Member0..nmembersclassWebsite{ Member[]members;//ormaybe:vectormembers; voidregister(MemberaMember){...}}怎樣才能使設(shè)計更靈活以注冊新類型的成員？第一百八十三頁，共664頁。注冊網(wǎng)站的靈活性WebSiteMember0..nStandardMemberXMemberYMembermembers解決方案：引入一個基類，將基類抽象化，根據(jù)需要產(chǎn)生繼承類第一百八十四頁，共664頁。靈活性我們之所以進行靈活的設(shè)計，因為變化和重用是經(jīng)常出現(xiàn)的第一百八十五頁，共664頁。可重用性盡可能的降低成本重用原有的工作可以獲得最大生產(chǎn)率重用：函數(shù)重用、類重用、重用類組合可重用設(shè)計，可重用組件函數(shù)設(shè)計的可重用性基于重用的類選擇用于重用的類組合第一百八十六頁，共664頁。使一個方法具有可重用性完全指定前置條件等避免不必要的封裝類耦合如果可行，讓方法成為靜態(tài)的參數(shù)化讓方法功能化但要限制參數(shù)的個數(shù)讓名字更具表達性可理解性促進可重用性解釋算法重用者要知道算法如何工作重用的方法必須給出完整的定義，以便使重用者知道這些方法的功能及使用條件一個方法對于上下文越獨立，其可重用性的性能就越高。靜態(tài)方法就屬于這種類型第一百八十七頁，共664頁。使一個類成為可重用的完整的描述類使類名與功能與實際情況相符定義一個有用的抽象類以獲得更廣泛的應(yīng)用減少對其他類的依賴性通過繼承獲得第一百八十八頁，共664頁。減少類間的依賴性如果類A依賴于類B，沒有類B就不可以使用類A，這就減少了類A的重用性。Piano類依賴Custumer類，因為鋼琴是賣給用戶的，限制了Piano類的使用。一個庫存應(yīng)用程序可能需要Piano類，但卻不需要Customer類。重用Piano類。能否讓Custumer類依賴Piano類，因為用戶只有購買鋼琴時才成為用戶。有沒有更好的解決方案呢？降低依賴性。CustomerReplace…Piano第一百八十九頁，共664頁。減少類間的依賴性引入第三個類PianoOrder將其關(guān)聯(lián)起來。這個設(shè)計具有一定的作用，但在現(xiàn)實情況中可能是不行的。例如，可能需要訪問某一給定用戶的訂單，而不必檢查每個PianoOrder訂單對象。中介者設(shè)計模式解決問題減少類之間的依賴關(guān)系，抽象級的依賴關(guān)系是可以接受的。通過減少類的依賴性來增加其可重用性with…CustomerPianoPianoOrder第一百九十頁，共664頁。高效性應(yīng)用程序必須在給定的時間內(nèi)完成特定的功能執(zhí)行效率處理循環(huán)問題消除遠程調(diào)用消除或制定函數(shù)調(diào)用存儲效率

RAM的大?。ㄟ\行時）代碼本身的規(guī)模輔助存儲器的大小第一百九十一頁，共664頁。執(zhí)行效率影響執(zhí)行效率的一些因素循環(huán)while,for,do遠程調(diào)用：消除遠程調(diào)用Requiringanetwork需要網(wǎng)絡(luò)LANTheInternet函數(shù)調(diào)用：消除函數(shù)調(diào)用如果函數(shù)調(diào)用導(dǎo)致以上情況發(fā)生對象創(chuàng)建高效的設(shè)計并不要求簡單，甚至?xí)容^凌亂高效原則會減少函數(shù)調(diào)用，會導(dǎo)致產(chǎn)生大量的方法和類，難于擴展和重用第一百九十二頁，共664頁。

先按其它原則設(shè)計，再考慮效率以靈活性，可重用性等原則進行設(shè)計找出效率低的部分有針對性的修改一開始就按效率原則進行設(shè)計確認當(dāng)前關(guān)鍵的效率需求在整個階段都按需求進行設(shè)計以上兩種方法的結(jié)合在設(shè)計時為效率需求做出折中在初始設(shè)計之后，也要繼續(xù)考慮效率問題針對時間效率的基本方法第一百九十三頁，共664頁。時空折中Space處理一個項目的時間通常的目標(biāo)第一百九十四頁，共664頁。時間、空間、開發(fā)的折中空間時間開發(fā)的設(shè)備限制可接受的值不可接受的值好于可接受的值第一百九十五頁，共664頁。內(nèi)容3.1 軟件設(shè)計的基本概念3.2 軟件設(shè)計過程3.3 軟件設(shè)計的質(zhì)量3.4 軟件體系結(jié)構(gòu)設(shè)計3.5 高可信軟件設(shè)計3.6 軟件設(shè)計規(guī)格說明3.7 軟件設(shè)計評審第一百九十六頁，共664頁。（1）軟件體系結(jié)構(gòu)設(shè)計方法概述軟件體系結(jié)構(gòu)的設(shè)計方法是指通過一系列的設(shè)計活動，獲得滿足系統(tǒng)功能性需求、并且符合一定非功能性需求約束的軟件體系結(jié)構(gòu)模型。目前存在多種體系結(jié)構(gòu)設(shè)計方法，它們的側(cè)重點有所不同(功能、非功能、復(fù)用)。在實際應(yīng)用過程中，這些體系結(jié)構(gòu)設(shè)計方法并不是絕對互斥的，根據(jù)需要，有可能綜合運用不同體系結(jié)構(gòu)設(shè)計方法的思想，得到最終所需的設(shè)計結(jié)果。第一百九十七頁，共664頁。軟件體系結(jié)構(gòu)設(shè)計方法‘4+1’多視圖建?；谠u估與轉(zhuǎn)換的設(shè)計方法模式驅(qū)動的設(shè)計方法領(lǐng)域特定的軟件體系結(jié)構(gòu)設(shè)計復(fù)用軟件產(chǎn)品線方法其它軟件體系結(jié)構(gòu)設(shè)計方法第一百九十八頁，共664頁。

“4+1”模型概述

Kruchten在1995年提出了“4+1”的視圖模型。

“4+1”視圖模型從5個不同的視角包括邏輯視圖、進程視圖、物理視圖、開發(fā)視圖和場景視圖來描述軟件體系結(jié)構(gòu)。每一個視圖只關(guān)心系統(tǒng)的一個側(cè)面，