版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)
文檔簡介
第3章
可行性研究與項目開發(fā)計劃2項目立項概述第一節(jié)可行性研究第二節(jié)制定項目開發(fā)計劃第三節(jié)目錄content第一節(jié)項目立項概述項目立項概述任何一個完整的軟件工程項目都是從項目立項開始的。項目立項包括項目發(fā)起、項目論證、項目審核和項目立項四個過程4SWOT03.項目審核1.項目發(fā)起4.項目立項2.項目論證項目立項概述項目經(jīng)過可行性研究并且認為可行后,還需要報告主管領(lǐng)導或單位,以獲得項目的進一步審核,并得到他們的支持。5項目通過可行性研究和主管部門的批準后,將其列入項目計劃的過程,叫做項目立項。在發(fā)起一個項目時,項目發(fā)起人或單位為尋求他人的支持,要以書面材料的形式遞交給項目的支持者和領(lǐng)導,使其明白項目的必要性和可行性。項目發(fā)起項目論證過程,也就是可行性研究過程??尚行匝芯烤褪侵冈陧椖窟M行開發(fā)之前,根據(jù)項目發(fā)起文件和實際情況,對該項目是否能在特定的資源、時間等制約條件下完成做出評估,并且確定它是否值得去開發(fā)??尚行匝芯康慕Y(jié)論有以下三種情況:(1)可行,按計劃進行(2)基本可行,需要對解決方案作出修改(3)不可行,終止項目項目論證項目發(fā)起項目發(fā)起第二節(jié)可行性研究可行性研究的任務可行性研究的步驟7可行性研究的任務可行性研究需要從多個方面進行評估,主要包括:計劃可行性戰(zhàn)略可行性社會可行性社會可行性技術(shù)可行性操作可行性市場可行性經(jīng)濟可行性風險可行性8可行性研究的任務技術(shù)可行性技術(shù)可行性主要研究待開發(fā)的系統(tǒng)的功能、性能和限制條件,確定現(xiàn)有技術(shù)能否實現(xiàn)有關(guān)的解決方案,在現(xiàn)有的資源條件下實現(xiàn)新系統(tǒng)的技術(shù)風險有多大。這里的資源條件是指已有的或可以得到的軟硬件資源,現(xiàn)有的開發(fā)項目的人員的技術(shù)水平和已有的工作基礎。在評估技術(shù)可行性時,需要考慮以下情況:
了解當前最先進的技術(shù),分析相關(guān)技術(shù)的發(fā)展是否支持新系統(tǒng)確定資源的有效性,如新系統(tǒng)的軟硬件資源是否具備,開發(fā)項目的人員在技術(shù)和時間上是否可行等分析項目的開發(fā)的技術(shù)風險,即能在給定的資源和時間等條件下,設計并實現(xiàn)系統(tǒng)的功能和性能等9可行性研究的任務操作可行性操作可行性是對開發(fā)系統(tǒng)在一個給定的工作環(huán)境中能否運行或運行好壞程度的衡量。操作可行性研究決定在當前的政治意識形態(tài)、法律法規(guī)、社會道德、民族意識以及系統(tǒng)運行的組織機構(gòu)或人員等環(huán)境下,系統(tǒng)的操作是否可行。經(jīng)濟可行性可行性研究成本--效益分析是可行性研究的重要內(nèi)容,它用于評估基于項目的經(jīng)濟合理性,給出項目開發(fā)的成本論證,并將估算的成本與預期的利潤進行對比。一般說來,基于項目的成本由4個部分組成:購置并安裝軟硬件及有關(guān)設備的費用;項目開發(fā)費用;軟硬件系統(tǒng)安裝、運行和維護費用;人員的培訓費用。項目開發(fā)效益包括經(jīng)濟效益和社會效益兩部分。經(jīng)濟效益是指所使用系統(tǒng)為用戶增加的收入,可以通過直接的或統(tǒng)計的方法估算;社會效益只能用定性的方法估算??尚行匝芯康娜蝿杖蝿杖肆?%可行性研究4~5需求分析10~25設計20~25編碼15~20測試和調(diào)試30~4010典型環(huán)境下各個階段需要投入的人力百分比1.成本估算代碼行技術(shù)
。代碼行技術(shù)是比較簡單的定量估算方法,它將開發(fā)每個軟件功能的成本與實現(xiàn)這個功能需要用的源代碼行數(shù)聯(lián)系起來。通常根據(jù)經(jīng)驗和歷史數(shù)據(jù)估算實現(xiàn)一個功能所需要的源代碼行數(shù)。一旦估算出源代碼行數(shù)后,用每行代碼的平均成本乘以行數(shù)即可確定軟件的成本。每行代碼的平均成本主要取決于軟件的復雜程度和人員的薪資水平。任務分解技術(shù)。首先將開發(fā)項目分解為若干個相對獨立的任務,再分別估算每個任務單獨開發(fā)的成本,最后累加起來就可得出開發(fā)項目的總成本。經(jīng)濟可行性2.成本-效益分析開發(fā)成本:使用代碼行技術(shù)或任務分解技術(shù)進行估算運行費用:取決于系統(tǒng)操作的費用(涉及操作人員、工作時間和消耗物資等),以及維護費用經(jīng)濟效益:因使用新系統(tǒng)而增加的收入加上使用新系統(tǒng)可以節(jié)省的運行費用11可行性研究的任務經(jīng)濟可行性3.貨幣的時間價值通常使用利率的形式表示貨幣的時間價值。假設年利率為i,如果現(xiàn)在存入P,則n年后可以得到的價值為:F=P(1+i)^nF就是P在n年后的價值。反之,如果n年后能收入F,那么這些貨幣的現(xiàn)在價值就是:P=F/(1+i)^n12可行性研究的任務經(jīng)濟可行性可行性研究的任務例如:有這樣一個庫房管理系統(tǒng),它每天能產(chǎn)生一份訂貨報告。假定開發(fā)該系統(tǒng)共需50000元,系統(tǒng)開發(fā)完后及時訂貨,以免商品短缺,估算一下,每年可以節(jié)約25000元,5年則可以總共節(jié)約125000元。假定年利率為5%,利用上面計算貨幣現(xiàn)在價值的公式,可以計算出開發(fā)完該庫房管理系統(tǒng)后,每年預計節(jié)省費用的現(xiàn)在價值,如右表所示。年將來值(元)(1+i)n現(xiàn)在值(元)累計的現(xiàn)在值(元)1250001.0523809.5223809.522250001.1022675.7446485.263250001.1621595.9468081.204250001.2220567.5688648.765250001.2819588.15108236.9213將來的收入折算成現(xiàn)在值4.投資回收期投資回收期是衡量一個項目價值的常用方法。投資回收期就是使累計的經(jīng)濟效益等于最初投資所需要的時間。很明顯,投資回收期越短,所獲得的利潤就越快,因此該項目就越值得開發(fā)。14可行性研究的任務經(jīng)濟可行性5.純收入純收入是衡量一個項目價值的另一項經(jīng)濟指標。純收入就是在軟件生命周期中軟件系統(tǒng)的累計經(jīng)濟效益(折合成現(xiàn)在值)與投資之差。這相當于比較投資開發(fā)一個軟件系統(tǒng)和將錢存在銀行中(或貸給其他企業(yè))這兩種方案的優(yōu)劣。如果純收入為零,則項目的預期效益和在銀行存款一樣,而且開發(fā)一個軟件系統(tǒng)要冒風險,從經(jīng)濟觀點來看,這個項目可能是不值得投資的。如果純收入小于零,這個項目顯然不值得投資開發(fā)。15可行性研究的任務經(jīng)濟可行性16可行性研究的步驟進行可行性研究的步驟不是固化的,而是根據(jù)項目的性質(zhì)、特點以及開發(fā)團隊的能力有所區(qū)別。一個典型的可行性研究的步驟可以歸結(jié)為以下幾步1.明確系統(tǒng)的目標在這一步,可行性分析人員要訪問相關(guān)人員,閱讀分析可以掌握的材料,確認用戶需要解決的問題的實質(zhì),進而明確系統(tǒng)的目標以及為了達到這些目標所需的各種資源。2.分析研究現(xiàn)行系統(tǒng)現(xiàn)行系統(tǒng)是新系統(tǒng)重要的信息來源。新系統(tǒng)應該完成現(xiàn)行系統(tǒng)的基本功能,并在此基礎上對現(xiàn)行系統(tǒng)中存在的問題進行改善或修復。可以從3個方面對現(xiàn)有系統(tǒng)進行分析:系統(tǒng)組織結(jié)構(gòu)定義、系統(tǒng)處理流程分析和系統(tǒng)數(shù)據(jù)流分析。系統(tǒng)組織結(jié)構(gòu)可以用組織結(jié)構(gòu)圖來描述。系統(tǒng)處理流程分析的對象是各部門的業(yè)務流程,可以用系統(tǒng)流程圖來描述。系統(tǒng)數(shù)據(jù)流分析與業(yè)務流程緊密相連,可以用數(shù)據(jù)流圖和數(shù)據(jù)字典來表示。17可行性研究的步驟3.設計新系統(tǒng)的高層邏輯模型這一步從較高層次設想新系統(tǒng)的邏輯模型,概括地描述開發(fā)人員對新系統(tǒng)地理解和設想。4.獲得并比較可行的方案開發(fā)人員可根據(jù)新系統(tǒng)的高層邏輯模型提出實現(xiàn)此模型的不同方案。在設計方案的過程中要從技術(shù)、經(jīng)濟等角度考慮各方面的可行性。然后,從多個方案中選擇出最合適的方案。18可行性研究的步驟5.撰寫可行性研究報告可行性研究的最后一步就是撰寫可行性研究報告。此報告包括項目介紹、可行性分析過程和結(jié)論等內(nèi)容??尚行匝芯康慕Y(jié)論一般有以下三種:(1)可以按計劃進行軟件項目的開發(fā)(2)需要解決某些存在的問題(如資金短缺、設備陳舊和開發(fā)人員短缺等)或者需要對現(xiàn)有的解決方案進行一些調(diào)整或改善后才能進行軟件項目的開發(fā)。(3)待開發(fā)的軟件項目不具有可行性,立即停止該軟件項目。19可行性研究的步驟可行性研究實例假設開發(fā)某個計算機應用系統(tǒng)的投資額為3000元,該計算機應用系統(tǒng)投入使用后,每年可以節(jié)約1000元,5年內(nèi)節(jié)約5000元。3000元是現(xiàn)在投資的錢,假定年利率為12%,請計算該系統(tǒng)的純收入和投資回收期。年節(jié)省利率現(xiàn)在值(元)累計的現(xiàn)在值(元)110001.12892.86892.86210001.2544797.191690.05310001.404928711.782401.83410001.573519635.523037.35510001.762342567.433604.7820純收入最終結(jié)果:3604.78-3000=604.78元投資回收期:3+(3000-2401.83)/(3037.35-2401.83)=3.94年第三節(jié)制定項目開發(fā)計劃在可行性研究之后,就可得知一個軟件項目是否值得開發(fā)。如果值得開發(fā),則開發(fā)人員應制訂相應的項目開發(fā)計劃。計劃的合理性和準確性往往關(guān)系著項目的成功與否。計劃應考慮周全,要考慮到一些未知因素和不確定因素,以及要考慮到可能的修改。計劃應盡量準確,盡可能提高數(shù)據(jù)的可靠性。22制定項目開發(fā)計劃項目計劃軟件開發(fā)計劃軟件開發(fā)計劃是軟件工程中的一種管理文檔,主要是對所要開發(fā)軟件的人員、進度、費用、軟件開發(fā)環(huán)境和運行環(huán)境的配置和硬件設備的配置等進行說明和規(guī)劃,是項目管理人員對項目進行管理的依據(jù),管理員據(jù)此對項目的費用、進度和資源進行控制的和管理項目概述:說明項目的各項主要工作;說明軟件的功能和性能;為完成項目應具備的條件;甲方和乙方應承擔的工作、完成期限和其他限制條件;應交付的軟件名稱,所使用的開發(fā)語言及存儲形式;應交付的文檔等)。實施計劃:說明任務的劃分,各項任務的責任人;說明項目開發(fā)進度,按階段應完成的任務,用圖表說明每項任務的開始時間和完成時間;說明項目的預算,各階段的費用支出預算等。人員組織及分工:說明開發(fā)該項目所需人員的類型、組成結(jié)構(gòu)和數(shù)量等。交付期限:說明項目應交付的日期等。23制定項目開發(fā)計劃項目開發(fā)計劃的主要內(nèi)容謝謝聆聽第4章需求分析與結(jié)構(gòu)化分析
目錄264.1
需求分析概述4.2結(jié)構(gòu)化分析方法4.3結(jié)構(gòu)化分析建模4.4結(jié)構(gòu)化分析圖形工具4.1需求分析概述4.1需求分析概述284.1.1
需求分析的任務和原則
1.為什么需要需求分析
為了開發(fā)出真正滿足用戶需要的軟件產(chǎn)品,明確地了解用戶需求是關(guān)鍵。雖然在可行性研究中,已經(jīng)對用戶需求有了初步的了解,但是很多細節(jié)還沒有考慮到。可行性研究的目的是評估系統(tǒng)是否值得去開發(fā),問題是否能夠解決,而不是對需求進行定義。如果說可行性分析是要決定“做還是不做”,那么需求分析就是要回答“系統(tǒng)必須做什么”這個問題。需求分析是一個非常重要的過程,它完成的好壞直接影響了后續(xù)軟件開發(fā)的質(zhì)量。4.1需求分析概述292.確定系統(tǒng)的運行環(huán)境要求
系統(tǒng)運行時的硬件環(huán)境要求,如對計算機的CPU、內(nèi)存、存儲器、輸入/輸出方式、通信接口和外圍設備等的要求;軟件環(huán)境要求,如操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)和編程語言等的要求。4.1需求分析概述303.確定系統(tǒng)的功能性需求和非功能性需求需求可以分為兩大類,功能性需求和非功能性需求,前者定義了系統(tǒng)做什么,后者定義了系統(tǒng)工作時的特性。功能需求:軟件系統(tǒng)的最基本的需求表述,包括對系統(tǒng)應該提供的服務,如何對輸入做出反應,以及系統(tǒng)在特定條件下的行為描述。在某些情況下,功能需求還必須明確系統(tǒng)不應該做什么,這取決于開發(fā)的軟件類型、軟件未來的用戶、以及開發(fā)的系統(tǒng)類型。所以,功能性的系統(tǒng)需求,需要詳細地描述系統(tǒng)功能特征、輸入和輸出接口、異常處理方法等。非功能性需求:包括對系統(tǒng)提出的性能需求、可靠性和可用性需求、系統(tǒng)安全以及系統(tǒng)對開發(fā)過程、時間、資源等方面的約束和標準等。性能需求指定系統(tǒng)必須滿足的定時約束或容量約束,一般包括速度(響應時間)、信息量速率(吞吐量、處理時間)和存儲容量等方面的需求。4.1需求分析概述314.進行有效的需求分析一般情況下,用戶并不熟悉計算機的相關(guān)知識,而軟件開發(fā)人員對相關(guān)的業(yè)務領(lǐng)域也不甚了解,用戶與開發(fā)人員之間對同一問題理解的差異和習慣用語的不同往往會為需求分析帶來很大的困難。所以,開發(fā)人員和用戶之間充分和有效的溝通在需求分析的過程中至關(guān)重要。有效的需求分析通常都具有一定的難度,這一方面是由于交流障礙所引起的,另一方面是由于用戶通常對需求的陳述不完備、不準確和不全面,并且還可能在不斷的變化。所以開發(fā)人員不僅需要在用戶的幫助下抽象現(xiàn)有的需求,還需要挖掘隱藏的需求。此外,把各項需求抽象為目標系統(tǒng)的高層邏輯模型對日后的開發(fā)工作也至關(guān)重要。合理的高層邏輯模型是系統(tǒng)設計的前提。4.1需求分析概述325.需求分析的兩個階段
首先,是需求分析的建模階段,即在充分了解需求的基礎上,要建立起系統(tǒng)的分析模型。
其次,是需求分析的描述階段,就是把需求文檔化,用軟件需求規(guī)格說明書的方式把需求表達出來。4.1需求分析概述336.軟件需求規(guī)格說明書
軟件需求規(guī)格說明書是需求分析階段的輸出,它全面、清晰地描述了用戶需求,因此是開發(fā)人員進行后續(xù)軟件設計的重要依據(jù)。軟件需求規(guī)格說明書應該具有清晰性、無二義性、一致性和準確性等特點。同時,它還需通過嚴格的需求驗證、反復修改的過程才能最終確定。01020304GOAL4.1需求分析概述34在需求分析的過程中應該遵守一些原則首先,需求分析是一個過程,它應該貫穿于系統(tǒng)的整個生命周期中,而不是僅僅屬于軟件生命周期早期的一項工作。其次,需求分析應該是一個迭代的過程。由于市場環(huán)境的易變性以及用戶本身對于新系統(tǒng)要求的模糊性,需求往往很難一步到位。通常情況下,需求是隨著項目的深入而不斷變化的。所以需求分析的過程還應該是一個迭代的過程。此外,為了方便評審和后續(xù)的設計,需求的表述應該具體、清晰,并且是可測量的、可實現(xiàn)的。最好能夠?qū)π枨筮M行適當?shù)牧炕?。比如:系統(tǒng)的響應時間應該低于0.5秒;系統(tǒng)在同一時刻最多能支持30000個用戶。4.1需求分析概述354.1.2需求分析的步驟為了準確獲取需求,需求分析必須遵循一系列的步驟。只有采取了合理的需求分析的步驟,開發(fā)人員才能更有效地獲取需求。一般來說,需求分析分為需求獲取、分析建模、需求描述和需求驗證4步。以下將分步進行介紹。4.1需求分析概述36
需求獲取就是收集并明確用戶需求的過程。系統(tǒng)開發(fā)方人員通過調(diào)查研究,要理解當前系統(tǒng)的工作模型、用戶對新系統(tǒng)的設想與要求。在需求獲取的初期,用戶提出的需求一般模糊而且凌亂,這就需要開發(fā)人員能夠選取較好的需求分析的方法,提煉出邏輯性強的需求。而且不同用戶的需求有可能發(fā)生沖突,對于發(fā)生沖突的需求必須仔細考慮并做出選擇。獲取需求的方法有多種,比如問卷調(diào)查、訪談、實地操作、建立原型等。
1.需求獲取4.1需求分析概述37
獲取到需求后,下一步就應該對開發(fā)的系統(tǒng)建立分析模型了。模型就是為了理解事物而對事物做出的一種抽象,通常由一組符號和組織這些符號的規(guī)則組成。對待開發(fā)系統(tǒng)建立各種角度的模型有助于人們更好地理解問題。通常,從不同角度描述或理解軟件系統(tǒng),就需要不同的模型。常用的建模方法有數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)轉(zhuǎn)換圖、控制流圖、用例圖、類圖、對象圖等。
2.分析建模4.1需求分析概述38
需求描述就是指編制需求分析階段的文檔。一般情況下,對于復雜的軟件系統(tǒng),需求階段會產(chǎn)生3個文檔:系統(tǒng)定義文檔(用戶需求報告)、系統(tǒng)需求文檔(系統(tǒng)需求規(guī)格說明書)、軟件需求文檔(軟件需求規(guī)格說明書)。而對于簡單的軟件系統(tǒng)而言,需求階段只需要輸出軟件需求文檔就可以了。軟件需求規(guī)格說明書主要描述軟件部分的需求,簡稱SRS(SoftwareRequirementSpecification),它站在開發(fā)者的角度,對開發(fā)系統(tǒng)的業(yè)務模型、功能模型、數(shù)據(jù)模型、行為模型等內(nèi)容進行描述。經(jīng)過嚴格的評審后,它將作為概要設計和詳細設計的。
3.需求描述4.1需求分析概述39文檔與軟件規(guī)模的對應關(guān)系4.1需求分析概述40
需求分析的第四步是驗證以上需求分析的成果。需求分析階段的工作成果是后續(xù)軟件開發(fā)的重要基礎,為了提高軟件開發(fā)的質(zhì)量,降低軟件開發(fā)的成本,必須對需求的正確性進行嚴格的驗證,確保需求的一致性、完整性、現(xiàn)實性、有效性。確保設計與實現(xiàn)過程中的需求可回溯性,并進行需求變更管理。
4.需求驗證與評審4.1需求分析概述41
需求評審就是將需求規(guī)約文檔發(fā)布給利益相關(guān)者進行檢查,發(fā)現(xiàn)需求規(guī)約中存在缺陷(如錯誤、不完整性、二義性等)的過程。對工作產(chǎn)品的評審有兩類方式,一類是正式技術(shù)評審,也稱同行評審,另一類是非正式技術(shù)評審。對于任何重要的工作產(chǎn)品,都應該至少執(zhí)行一次正式技術(shù)評審。在進行正式技術(shù)評審前,需要有人員對要進行評審的工作產(chǎn)品進行把關(guān),確認其是否具備進入評審的初步條件。需求評審的規(guī)程與其他重要工作產(chǎn)品(如系統(tǒng)設計文檔、源代碼)的評審規(guī)程非常相似,主要區(qū)別在于評審人員的組成不同。前者由開發(fā)方和客戶方的代表共同組成,而后者通常來源于開發(fā)方內(nèi)部。4.1需求分析概述424.1.3需求管理
為了更好的進行需求分析并記錄需求結(jié)果,需要進行需求管理。需求管理是一種用于查找、記錄、組織和跟蹤系統(tǒng)需求變更的系統(tǒng)化方法。可用于:獲取、組織和記錄系統(tǒng)需求使客戶和項目團隊在系統(tǒng)變更需求上達成并保持一致
有效需求管理的關(guān)鍵在于維護需求的明確闡述、每種需求類型所適用的屬性,以及與其他需求和其他項目工件之間的可追蹤性。01020304GOAL4.1需求分析概述434.1.3需求管理
需求管理實際上是項目管理的一個部分,它涉及以下3個主要問題:(1)識別、分類、組織需求,并為需求建立文檔(2)需求變化,是建立對需求不可避免的變化是如何提出、如何協(xié)商、如何驗證以及如何形成文檔的過程(3)需求的可追蹤性,即帶有維護需求之間以及與系統(tǒng)的其他制品之間依賴關(guān)系的過程4.1需求分析概述444.1.4需求分析的常用方法
需求分析的方法有多種,下面只簡單介紹功能分解方法、結(jié)構(gòu)化分析方法、信息建模方法和面向?qū)ο蟮姆治龇椒ā?.1需求分析概述454.1.4需求分析的常用方法(1)功能分解方法功能分解方法是將一個系統(tǒng)看成是由若干功能模塊組成的,每個功能又可分解為若干子功能及接口,子功能再繼續(xù)分解,即功能、子功能和功能接口成為了功能分解方法的3個要素。功能分解方法采用的是自頂向下、逐步求精的理念。4.1需求分析概述46(2)結(jié)構(gòu)化分析方法結(jié)構(gòu)化分析方法是一種從問題空間到某種表示的映射方法,其邏輯模型由數(shù)據(jù)流圖和數(shù)據(jù)詞典構(gòu)成并表示。它是一種面向數(shù)據(jù)流的需求分析方法。它主要適用于數(shù)據(jù)處理領(lǐng)域問題。第4章將詳細介紹這種方法。4.1需求分析概述47(3)信息建模方法模型是用某種媒介對相同媒介或其他媒介里的一些事物的表現(xiàn)形式。從一個建模角度出發(fā),模型就是要抓住事物的最重要方面而簡化或忽略其他方面。簡而言之,模型就是對現(xiàn)實的簡化。建立模型的過程,稱為建模。建??梢詭椭斫庹陂_發(fā)的系統(tǒng),這是需要建模的一個基本理由。并且,人對復雜問題的理解能力是有限的。建模可以幫助開發(fā)者縮小問題的范圍,每次著重研究一個方面,進而對整個系統(tǒng)產(chǎn)生更加深刻的理解??梢悦鞔_地說,越大、越復雜的系統(tǒng),建模的重要性也越大。信息建模方法常用的基本工具是E-R圖,其基本要素由實體、屬性和關(guān)系構(gòu)成。它的核心概念是實體和關(guān)系,它的基本策略是從現(xiàn)實中找出實體,然后再用屬性對其進行描述。4.1需求分析概述48(4)面向?qū)ο蟮姆治龇椒?/p>
面向?qū)ο蟮姆治龇椒ǖ年P(guān)鍵是識別問題域內(nèi)的對象,分析它們之間的關(guān)系,并建立3類模型,它們分別是:描述系統(tǒng)靜態(tài)結(jié)構(gòu)的對象模型描述系統(tǒng)控制結(jié)構(gòu)的動態(tài)模型描述系統(tǒng)計算結(jié)構(gòu)的功能模型
其中,對象模型是最基本、最核心、最重要的。面向?qū)ο笾饕紤]類或?qū)ο蟆⒔Y(jié)構(gòu)與連接、繼承和封裝、消息通信,只表示面向?qū)ο蟮姆治鲋袔醉椬钪匾卣?。類的對象是對問題域中事物的完整映射,包括事物的數(shù)據(jù)特征(即屬性)和行為特征(即服務)。4.1需求分析概述494.1.5原型設計
原型設計是指在項目的前期階段,系統(tǒng)分析人員根據(jù)對客戶需求的理解和客戶希望實現(xiàn)的結(jié)果,快速地給出一個翔實地產(chǎn)品雛形,然后與客戶反復協(xié)商修改。01020304GOAL4.2結(jié)構(gòu)化分析方法4.2結(jié)構(gòu)化分析方法51
一種考慮數(shù)據(jù)和處理的需求分析方法被稱作結(jié)構(gòu)化分析方法(StructuredAnalysis,簡稱SA法),是70年代由YourdonConstaintine及DeMarco等人提出和發(fā)展,并得到廣泛的應用。它基于“分解”和“抽象”的基本思想,逐步建立目標系統(tǒng)的邏輯模型,進而描繪出滿足用戶要求的軟件系統(tǒng)?!胺纸狻笔侵笇τ谝粋€復雜的系統(tǒng),為了將復雜性降低到可以掌握的程度,可以把大問題分解為若干個小問題,然后再分別解決。4.2結(jié)構(gòu)化分析方法52最頂層描述了整個目標系統(tǒng)X中間層將目標系統(tǒng)劃分為若干個模塊,每個模塊完成一定的功能最底層是對每個模塊實現(xiàn)方法的細節(jié)性描述4.2結(jié)構(gòu)化分析方法53結(jié)構(gòu)化分析方法是一種面向數(shù)據(jù)流的需求分析方法,其中數(shù)據(jù)作為獨立實體轉(zhuǎn)換,數(shù)據(jù)建模定義了數(shù)據(jù)的屬性和關(guān)系,操作數(shù)據(jù)的處理建模表明當數(shù)據(jù)在系統(tǒng)流動時處理如何轉(zhuǎn)換數(shù)據(jù)。4.2結(jié)構(gòu)化分析方法541)建立當前系統(tǒng)的“具體模型”:系統(tǒng)的“具體模型”就是現(xiàn)實環(huán)境的忠實寫照,這樣的表達與當前系統(tǒng)完全對應,因此用戶容易理解。2)抽象出當前系統(tǒng)的邏輯模型:分析系統(tǒng)的“具體模型”,抽象出其本質(zhì)的因素,排除次要因素,獲得當前系統(tǒng)的“邏輯模型”。3)建立目標系統(tǒng)的邏輯模型:分析目標系統(tǒng)與當前系統(tǒng)邏輯上的差別,從而進一步明確目標系統(tǒng)“做什么”,建立目標系統(tǒng)的“邏輯模型”。4)為了對目標系統(tǒng)進行完整的描述,還需要考慮人機界面和其他一些問題。
結(jié)構(gòu)化分析的具體步驟為:4.3結(jié)構(gòu)化分析建模4.3結(jié)構(gòu)化分析建模56
結(jié)構(gòu)化分析實質(zhì)上是一種創(chuàng)建模型的活動,它建立的分析模型如圖所示。此模型的核心是“數(shù)據(jù)字典”,它描述軟件使用或產(chǎn)生的所有數(shù)據(jù)對象。圍繞著這個核心有3種不同的圖:“數(shù)據(jù)流圖”指出當數(shù)據(jù)在軟件系統(tǒng)中移動時怎樣被變換,以及描繪變換數(shù)據(jù)流的功能和子功能,用于功能建?!皩嶓w-關(guān)系圖”(E-R圖)描繪數(shù)據(jù)對象之間的關(guān)系,用于數(shù)據(jù)建?!盃顟B(tài)轉(zhuǎn)換圖”指明了作為外部事件結(jié)果的系統(tǒng)行為,用于行為建模4.3結(jié)構(gòu)化分析建模57結(jié)構(gòu)化分析方法必須遵守下述準則:(1)必須定義軟件應完成的功能,這條準則要求建立功能模型。(2)必須理解和表示問題地信息域,根據(jù)這條準則應該建立數(shù)據(jù)模型。(3)必須表示作為外部事件結(jié)果的軟件行為,這條準則要求建立行為模型。(4)必須對描述功能、信息和行為的模型進行分解,用層次的方式展示細節(jié)。(5)分析過程應該從要素信息移向?qū)崿F(xiàn)細節(jié)。4.3結(jié)構(gòu)化分析建模584.3.1功能建模
功能建模的思想就是用抽象模型的概念,按照軟件內(nèi)部數(shù)據(jù)傳遞和變換的關(guān)系,自頂向下逐層分解,直到找到滿足功能要求的可實現(xiàn)的軟件為止。功能模型用數(shù)據(jù)流圖來描述。數(shù)據(jù)流圖(簡稱DFD圖)就是采用圖形方式來表達系統(tǒng)的邏輯功能、數(shù)據(jù)在系統(tǒng)內(nèi)部的邏輯流向和邏輯變換過程,是結(jié)構(gòu)化系統(tǒng)分析方法的主要表達工具及用于表示軟件模型的一種圖示方法。4.3結(jié)構(gòu)化分析建模591.數(shù)據(jù)流圖的表示符號在數(shù)據(jù)流圖中,存在4種表示符號。外部實體:表示數(shù)據(jù)的源點或終點,它是系統(tǒng)之外的實體,可以是人、物或者其他系統(tǒng)數(shù)據(jù)流:表示數(shù)據(jù)流的流動方向。數(shù)據(jù)流可以從加工流向加工,從加工流向文件,從文件流向加工數(shù)據(jù)變換:表示對數(shù)據(jù)進行加工或處理,比如對數(shù)據(jù)的算法分析和科學計算數(shù)據(jù)存儲:表示輸入或輸出文件。這些文件可以是計算機系統(tǒng)中的外部或者內(nèi)部文件,也可以是表、賬單等4.3結(jié)構(gòu)化分析建模602.環(huán)境圖環(huán)境圖(如圖所示)也稱為系統(tǒng)頂層數(shù)據(jù)流圖(或0層數(shù)據(jù)流圖),它僅包括一個數(shù)據(jù)處理過程,也就是要開發(fā)的目標系統(tǒng)。環(huán)境圖的作用是確定系統(tǒng)在其環(huán)境中的位置,通過確定系統(tǒng)的輸人和輸出與外部實體的關(guān)系確定其邊界。4.3結(jié)構(gòu)化分析建模61
根據(jù)結(jié)構(gòu)化需求分析采用的“自頂向下,由外到內(nèi),逐層分解”的思想,開發(fā)人員要先畫出系統(tǒng)頂層的數(shù)據(jù)流圖,然后再逐層畫出低層的數(shù)據(jù)流圖。頂層的數(shù)據(jù)流圖要定義系統(tǒng)范圍,并描述系統(tǒng)與外界的數(shù)據(jù)聯(lián)系,它是對系統(tǒng)架構(gòu)的高度概括和抽象。底層的數(shù)據(jù)流圖是對系統(tǒng)某個部分的精細描述。0102034.3結(jié)構(gòu)化分析建模62可以說,數(shù)據(jù)流圖的導出是一個逐步求精的過程。其中要遵守如下一些原則:(1)第0層的數(shù)據(jù)流圖應將軟件描述為一個泡泡(2)主要的輸入輸出應該被仔細地標記。(3)通過把在下一層表示的候選處理過程、數(shù)據(jù)對象和數(shù)據(jù)存儲分離,開始求精過程。(4)應使用有意義的名稱標記所有的箭頭和泡泡。(5)當從一個層轉(zhuǎn)移到另一個層時要保持信息流連續(xù)性。(6)一次精化一個泡泡。4.3結(jié)構(gòu)化分析建模634.3.2數(shù)據(jù)建模
數(shù)據(jù)建模的思想是在較高的抽象層次(概念層)上對數(shù)據(jù)庫結(jié)構(gòu)進行建模。數(shù)據(jù)模型用實體關(guān)系圖來描述。
實體-關(guān)系圖(簡稱E-R圖)可以明確描述待開發(fā)系統(tǒng)的概念結(jié)構(gòu)數(shù)據(jù)模型。對于較復雜的系統(tǒng),通常要先構(gòu)造出各部分的E-R圖,然后將各分E-R圖集合成總的E-R圖,并對E-R圖進行優(yōu)化,以得到整個系統(tǒng)的概念結(jié)構(gòu)模型。4.3結(jié)構(gòu)化分析建模64
在建模的過程中,E-R圖以實體、關(guān)系和屬性3個基本概念概括數(shù)據(jù)的基本結(jié)構(gòu)。實體就是現(xiàn)實世界中的事物,多用矩形框來表示,框內(nèi)含有相應的實體名稱。屬性多用橢圓形表示,并用無向邊與相應的實體聯(lián)系起來,表示該屬性歸某實體所有。
可以說,實體是由若干個屬性組成的,每個屬性都代表了實體的某些特征。例如,在某教務系統(tǒng)中,“學生”實體的屬性如圖所示。4.3結(jié)構(gòu)化分析建模65
關(guān)系用菱形表示,并用無向邊分別與有關(guān)實體連接起來,以此描述實體之間的關(guān)系。實體之間存在著3種關(guān)系類型,分別是一對一、一對多、多對多,它們分別反映了實體間不同的對應關(guān)系。
如圖所示,“人員”與“車位”之間是一對一的關(guān)系,即一個人員只能分配一個車位,且一個車位只能屬于一個人員。“訂單”與“訂單行”之間是一對多的關(guān)系,即一個訂單包含若干個訂單行,而一個訂單行只屬于一個訂單。“學生”與“課程”之間是多對多的關(guān)系,即一個學生能登記若干門課程,且一門課程能被多個學生登記。4.3結(jié)構(gòu)化分析建模664.3.3行為建模狀態(tài)轉(zhuǎn)換圖是一種描述系統(tǒng)對內(nèi)部或外部事件響應的行為模型。它描述系統(tǒng)狀態(tài)和事件,事件引發(fā)系統(tǒng)在狀態(tài)間的轉(zhuǎn)換,而不是描述系統(tǒng)中數(shù)據(jù)的流動。這種模型尤其適合用來描述實時系統(tǒng),因為這類系統(tǒng)多是由外部環(huán)境的激勵而驅(qū)動的。4.3結(jié)構(gòu)化分析建模674.3.3行為建模使用狀態(tài)轉(zhuǎn)換圖具有以下優(yōu)點:1)狀態(tài)之間的關(guān)系能夠直觀地被捕捉到。(2)狀態(tài)轉(zhuǎn)換圖因其單純性,能夠機械地分析許多情況,可很容易地建立分析工具。(3)狀態(tài)轉(zhuǎn)換圖能夠很方便地對應狀態(tài)轉(zhuǎn)換表等工具。4.3結(jié)構(gòu)化分析建模68并不是所有系統(tǒng)都需要畫狀態(tài)轉(zhuǎn)換圖,有時系統(tǒng)中的某些數(shù)據(jù)對象在不同狀態(tài)下會呈現(xiàn)不同的行為方式,此時應分析數(shù)據(jù)對象的狀態(tài),畫出狀態(tài)轉(zhuǎn)換圖,才可正確地認識數(shù)據(jù)對象的行為,并定義其行為。對這些行為規(guī)則較復雜的數(shù)據(jù)對象需要進行如下分析:(1)找出數(shù)據(jù)對象的所有狀態(tài)。(2)分析在不同的狀態(tài)下,數(shù)據(jù)對象的行為規(guī)則是否不同,若無不同則可將其合并成一種狀態(tài)。(3)分析從一種狀態(tài)可以轉(zhuǎn)換成哪幾種狀態(tài),是數(shù)據(jù)對象的什么行為導致這種狀態(tài)的轉(zhuǎn)換。4.3結(jié)構(gòu)化分析建模691.狀態(tài)狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式,一個狀態(tài)代表系統(tǒng)的一種行為模式。狀態(tài)規(guī)定了系統(tǒng)對事件的響應方式。系統(tǒng)對事件的響應,既可以是做一個(或一系列)動作,也可以是僅僅改變系統(tǒng)本身的狀態(tài),還可以是既改變狀態(tài)又做動作。
在狀態(tài)轉(zhuǎn)換圖中定義的狀態(tài)主要有:初態(tài)、終態(tài)和中間狀態(tài)。狀態(tài)之間為狀態(tài)轉(zhuǎn)換,用一條帶箭頭的線表示。帶箭頭的線上的事件發(fā)生時,狀態(tài)轉(zhuǎn)換開始。在一張狀態(tài)圖中只能有一個初態(tài),而終態(tài)則可以沒有,也可以有多個。狀態(tài)轉(zhuǎn)換圖中使用的主要符號如圖所示。4.3結(jié)構(gòu)化分析建模70事件事件是在某個特定時刻發(fā)生的事情,它是對引起系統(tǒng)做動作或(和)從一個狀態(tài)轉(zhuǎn)換到另一個狀態(tài)的外界事件的抽象。例如,觀眾使用電視遙控器,用戶移動鼠標、點擊鼠標等都是事件。簡而言之,事件就是引起系統(tǒng)做動作或(和)轉(zhuǎn)換狀態(tài)的控制信息。狀態(tài)變遷通常是由事件觸發(fā)的,在這種情況下應在表示狀態(tài)轉(zhuǎn)換的箭頭線上標出觸發(fā)轉(zhuǎn)換的事件表達式。如果在箭頭線上未標明事件,則表示在源狀態(tài)的內(nèi)部活動執(zhí)行完之后自動觸發(fā)轉(zhuǎn)換。4.3結(jié)構(gòu)化分析建模713.例子4.3結(jié)構(gòu)化分析建模723.例子圖書在初始時需要進行分類并更新在庫數(shù)量。如果圖書發(fā)生借閱,則執(zhí)行借閱操作,并對在庫圖書數(shù)量進行更新。在借閱期間,如果圖書發(fā)生續(xù)借操作,則對該圖書重新執(zhí)行借閱操作并更新在庫數(shù)量。如果借閱的圖書被歸還,則需要對在庫圖書數(shù)量進行更新。此外,如果在庫圖書發(fā)生破損或者借閱圖書發(fā)生遺失,則對在庫圖書的數(shù)量進行更新。01020304GOAL01020304GOAL4.3結(jié)構(gòu)化分析建模734.3.4數(shù)據(jù)字典
如前所述,分析模型包括功能模型、數(shù)據(jù)模型和行為模型。數(shù)據(jù)字典以一種系統(tǒng)化的方式定義在分析模型中出現(xiàn)的數(shù)據(jù)對象及控制信息的特性,給出它們的準確定義,包括數(shù)據(jù)流、數(shù)據(jù)存儲、數(shù)據(jù)項、數(shù)據(jù)加工,以及數(shù)據(jù)源點、數(shù)據(jù)匯點等。數(shù)據(jù)字典成為將分析模型中的3種模型黏合在一起的“黏合劑”,是分析模型的“核心”。4.3結(jié)構(gòu)化分析建模74數(shù)據(jù)字典中采用的符號如表所示4.3結(jié)構(gòu)化分析建模754.3.5加工規(guī)格說明
在對數(shù)據(jù)流圖的分解中,位于最底層數(shù)據(jù)流圖的數(shù)據(jù)處理,也稱為基本加工或原子加工,對于每一個基本加工都需要進一步說明,這稱為加工規(guī)格說明,也稱為處理規(guī)格說明。在編寫基本加工的規(guī)格說明時,主要目的是要表達“做什么”,而不是“怎樣做”。加工規(guī)格說明一般用結(jié)構(gòu)化語言、判定表和判定樹來表述。01020304GOAL4.3結(jié)構(gòu)化分析建模761.結(jié)構(gòu)化語言結(jié)構(gòu)化語言也稱為過程設計語言(ProcedureDesignLanguage,PDL),也稱為偽代碼,在某些情況下,在加工規(guī)格說明中會用到。但一般來說,最好用PDL來描述加工規(guī)格說明的工作推遲到過程設計階段進行比較好。4.3結(jié)構(gòu)化分析建模772.判定表在某些數(shù)據(jù)處理中,某個數(shù)據(jù)處理(即加工)的執(zhí)行可能需要依賴于多個邏輯條件的取值,此時可用判定表。判定表能夠清晰地表示復雜的條件組合與應做的動作之間的對應關(guān)系。一張判定表由5部分組成,左上部列出所有條件,左下部是所有可能做的動作,右上部是表示各種條件組合的矩陣,右下部是和每種條件組合相對應的動作。判定表右半部的每一列實質(zhì)上是一條規(guī)則,規(guī)定了與特定的條件組合相對應的動作。4.3結(jié)構(gòu)化分析建模78某工廠生產(chǎn)兩種產(chǎn)品A和B。凡工人每月的實際生產(chǎn)量超過計劃指標者均有獎勵。獎勵政策為:對于產(chǎn)品A的生產(chǎn)者,超產(chǎn)數(shù)n小于或等于100件時,每超產(chǎn)1件獎勵2元;n大于100件小于等于150件時,大于100件的部分每件獎勵2.5元,其余的每件獎勵金額不變;n大于150件時,超過150件的部分每件獎勵3元,其余按超產(chǎn)150件以內(nèi)的方案處理。對于產(chǎn)品B的生產(chǎn)者,超產(chǎn)數(shù)n小于或等于50件時,每超產(chǎn)1件獎勵3元;n大于50件小于等于100件時,大于50件的部分每件獎勵4元,其余的每件獎勵金額不變;n大于100件時,超過100件的部分每件獎勵5元,其余按超產(chǎn)100件以內(nèi)的方案處理。4.3結(jié)構(gòu)化分析建模79此處理功能的判定表如圖所示決策規(guī)則號123556
條件產(chǎn)品AYYYNNN
產(chǎn)品BNNNYYY
N<=50YNNYNN
50<N<=100YNNNYN
100<N<=150NYNNNY
N>150NNYNNY
獎勵政策2*N√
2.5*(N-100)+200
√
3*(N-150)+325
√
3*N
√
5*(N-50)+150
√
5*(N-100)+350
√4.3結(jié)構(gòu)化分析建模803.判定樹判定樹是判定表的變種,也能清晰地表示復雜地條件組合與應做地動作之間的對應關(guān)系。判定樹也是用來表述加工規(guī)格說明的一種工具。判定樹的優(yōu)點在于,它的形式簡單到不需任何說明,讓人一眼就可以看出其含義,因此易于掌握和使用。多年來判定樹一直受到人們的重視,是一種比較常用的系統(tǒng)分析和設計的工具。01020304GOAL4.3結(jié)構(gòu)化分析建模813.判定樹4.4結(jié)構(gòu)化分析圖形工具4.4結(jié)構(gòu)化分析圖形工具83
除了前述所用的數(shù)據(jù)流圖、E-R圖、狀態(tài)圖、數(shù)據(jù)字典和加工規(guī)格說明(結(jié)構(gòu)化語言、判定表和判定樹)外,在結(jié)構(gòu)化的分析中,有時還會用到層次方框圖、Warnier圖和IPO圖這3種圖形工具。4.4結(jié)構(gòu)化分析圖形工具844.4.1層次方框圖層次方框圖由樹形結(jié)構(gòu)的一系列多層次的矩形組成,用來描述數(shù)據(jù)的層次結(jié)構(gòu)。樹形結(jié)構(gòu)的額頂層是一個單獨的矩形框,它表示數(shù)據(jù)結(jié)構(gòu)的整體。下面的各層矩形框表示這個數(shù)據(jù)的子集,最底層的各個框表示這個數(shù)據(jù)的不能再分割的元素。這里需要提醒的是,層次方框圖不是功能模塊圖,方框之間的關(guān)系是組成關(guān)系,而不是調(diào)用關(guān)系。4.4結(jié)構(gòu)化分析圖形工具85圖為電子相冊管理系統(tǒng)組成的層次方框圖。4.4結(jié)構(gòu)化分析圖形工具864.4.2Warnier圖
Warnier圖是表示數(shù)據(jù)層次的另一種圖形工具,它與層次方框圖相似,也用樹形結(jié)構(gòu)來描繪數(shù)據(jù)結(jié)構(gòu)。Warnier圖提供了比層次方框圖更詳細的描繪手段,能指出某一類數(shù)據(jù)或某一數(shù)據(jù)元素重復出現(xiàn)的次數(shù),并能指明某一數(shù)據(jù)在某一類數(shù)據(jù)中是否有條件地出現(xiàn)。4.4結(jié)構(gòu)化分析圖形工具87報紙的組成就可用Warnier圖描述,如圖所示。4.4結(jié)構(gòu)化分析圖形工具884.4.3IPO圖
IPO圖是輸入/處理/輸出圖地簡稱,它是IBM公司提出的一種圖形工具,能夠方便地描繪輸入數(shù)據(jù)、處理數(shù)據(jù)和輸出數(shù)據(jù)地關(guān)系。
IPO圖使用的基本符號少而簡單,因此這種工具很容易掌握和使用。它的基本形式是在左邊的框中列出有關(guān)的輸入,在中間的框中列出主要的處理,在右邊的框中列出產(chǎn)生的輸出。處理框中列出了處理的順序,但是用這些基本符號還不足以精確描述執(zhí)行處理的詳細情況。在IPO圖中用空心大箭頭指出數(shù)據(jù)通信的情況。4.4結(jié)構(gòu)化分析圖形工具89一個主文件更新的IPO圖如圖所示。4.4結(jié)構(gòu)化分析圖形工具90一種改進的模塊IPO圖的形式如圖所示,這種圖除了描述輸入、處理、輸出過程外,還包括了某些附加的信息,這些附加的信息非常有利于理解系統(tǒng)及對該模塊的實現(xiàn),它們包括系統(tǒng)名稱、設計人員、設計日期、模塊名稱、模塊編號,還包括調(diào)用本模塊的模塊清單、本模塊調(diào)用的模塊清單以及全局的、局部的數(shù)據(jù)變量等。4.5結(jié)構(gòu)化分析實例91謝謝聆聽第5
章軟件設計與結(jié)構(gòu)化設計94錄目CONTENTS5.1
軟件設計的基本概念5.2軟件體系結(jié)構(gòu)5.3結(jié)構(gòu)化設計概述5.4結(jié)構(gòu)化設計與結(jié)構(gòu)化分析的關(guān)系5.5結(jié)構(gòu)化設計方法5.6接口設計5.6
數(shù)據(jù)設計5.7
過程設計5.8
軟件設計評審5.1軟件設計的基本概念965.1軟件設計的基本概念
5.1.1軟件設計的意義和目標5.1.2軟件設計的原則5.1.3軟件設計的分類975.1軟件設計的基本概念
做什么怎么做0102完成了需求分析,回答了軟件系統(tǒng)能“做什么”的問題,軟件的生命周期就進入了設計階段。軟件設計是軟件開發(fā)過程中的重要階段,在此階段中,開發(fā)人員將集中研究如何把需求規(guī)格說明書里歸納的分析模型轉(zhuǎn)換為可行的設計模型,并將解決方案記錄到相關(guān)的設計文檔中。實際上,軟件設計的目標就是要回答“怎么做”才能實現(xiàn)軟件系統(tǒng)的問題,也可以把設計階段的任務理解為把軟件系統(tǒng)能“做什么”的邏輯模型轉(zhuǎn)換為“怎么做”的物理模型。軟件設計在軟件開發(fā)中處于核心地位。985.1軟件設計的基本概念
5.1.1軟件設計的意義和目標1.設計必須實現(xiàn)所有包含在分析模型中的明確需求,而且必須滿足用戶期望的所有隱含需求2.對于程序員、測試人員和維護人員而言,設計必須是可讀的、可理解的指南3.設計必須提供軟件的全貌,從實現(xiàn)的角度說明數(shù)據(jù)域、功能域和行為域評價良好設計演化的特征McGlaughlin提出軟件設計在軟件開發(fā)過程中處于核心地位,它是保證質(zhì)量的關(guān)鍵步驟。設計為我們提供了可以用于質(zhì)量評估的軟件表示,設計是我們能夠?qū)⒂脩粜枨鬁蚀_地轉(zhuǎn)化為軟件產(chǎn)品或系統(tǒng)的唯一方法。軟件設計是所有軟件工程活動和隨后的軟件支持活動的基礎。軟件設計是一個迭代的過程,通過設計過程,需求被變換為用于構(gòu)建軟件的“藍圖”995.1軟件設計的基本概念
1.模塊化模塊是數(shù)據(jù)說明、可執(zhí)行語句等程序?qū)ο蟮募?,是?gòu)成程序的基本構(gòu)件,可以被單獨命名并通過名字來訪問。在面向過程的設計中,過程、函數(shù)、子程序、宏都可以作為模塊;在面向?qū)ο蟮脑O計中,對象是模塊,對象中的方法也是模塊。模塊化就是把系統(tǒng)或程序劃分為獨立命名并且可以獨立訪問的模塊,每個模塊完成一個特定的子功能。模塊集成起來可以構(gòu)成一個整體,完成特定的功能,進而滿足用戶需求。5.1.2軟件設計的原則->模塊化.抽象.逐步求精.信息隱藏.復用性設計.靈活性設計
1005.1軟件設計的基本概念
5.1.2軟件設計的原則->模塊化.抽象.逐步求精.信息隱藏.復用性設計.靈活性設計
在模塊化的過程中,要注意以下幾點。(1)模塊的規(guī)模要適中。(2)提高模塊的獨立性,降低模塊間的耦合程度。(3)提高模塊的內(nèi)聚程度。(4)加強模塊的保護性。1015.1軟件設計的基本概念
5.1.2軟件設計的原則->模塊化.抽象.逐步求精.信息隱藏.復用性設計.靈活性設計
在模塊化的過程中,要注意以下幾點。(1)模塊的規(guī)模要適中。(2)提高模塊的獨立性,降低模塊間的耦合程度。(3)提高模塊的內(nèi)聚程度。(4)加強模塊的保護性。1025.1軟件設計的基本概念
5.1.2軟件設計的原則->模塊化.抽象.逐步求精.信息隱藏.復用性設計.靈活性設計
在模塊化的過程中,要注意以下幾點。(1)模塊的規(guī)模要適中。(2)提高模塊的獨立性,降低模塊間的耦合程度。(3)提高模塊的內(nèi)聚程度。(4)加強模塊的保護性。1035.1軟件設計的基本概念
5.1.2軟件設計的原則->模塊化.抽象.逐步求精.信息隱藏.復用性設計.靈活性設計
2.抽象
抽象是人們認識復雜的客觀世界時所使用的一種思維工具。抽象主要是為了降低問題的復雜度,以得到問題領(lǐng)域中較簡單的概念,好讓人們能夠控制其過程或以宏觀的角度來了解許多特定的事態(tài)。
抽象在軟件開發(fā)過程中起著非常重要的作用。一個龐大、復雜的系統(tǒng)可以先用一些宏觀的概念構(gòu)造和理解,然后再逐層地用一些較微觀的概念去解釋上層的宏觀概念,直到最底層的元素。1045.1軟件設計的基本概念
5.1.2軟件設計的原則->模塊化.抽象.逐步求精.信息隱藏.復用性設計.靈活性設計
3.逐步求精在面對一個新問題時,開發(fā)人員可暫時忽略問題非本質(zhì)的細節(jié),而關(guān)注于與本質(zhì)相關(guān)的宏觀概念,集中精力解決主要問題,這種認識事物的方法就是逐步求精。逐步求精是抽象的逆過程。開發(fā)人員認識問題時逐步求精的過程,同時也是抽象程度逐漸降低的過程。按照逐步求精的思想,程序的體系結(jié)構(gòu)是按照層次結(jié)構(gòu),逐步精化過程細節(jié)而開發(fā)出來的??梢?,求精就是細化,它與抽象是互補的概念。1055.1軟件設計的基本概念
5.1.2軟件設計的原則->模塊化.抽象.逐步求精.信息隱藏.復用性設計.靈活性設計
4.信息隱藏信息隱藏與模塊化的概念相關(guān)。當一個系統(tǒng)被分解為若干個模塊時,為了避免某個模塊的行為干擾同一系統(tǒng)中的其他模塊,應該讓模塊僅僅公開必須讓外界知道的信息,而將其他信息隱藏起來,這樣模塊的具體實現(xiàn)細節(jié)相對于其他不相關(guān)的模塊而言就是不可見的,這種機制就叫做信息隱藏。信息隱藏提高了模塊的獨立性,加強了外部對模塊內(nèi)部信息進行訪問的限制,它使得模塊的局部錯誤盡量不影響其他模塊。信息隱藏有利于軟件的測試和維護工作。通常,模塊的信息隱藏可以通過接口來實現(xiàn)。模塊通過接口與外部進行通信,而把模塊的具體實現(xiàn)細節(jié)(如數(shù)據(jù)結(jié)構(gòu)、算法等內(nèi)部信息)隱藏起來。一般來說,一個模塊具有有限個接口,外部模塊通過調(diào)用相應的接口來實現(xiàn)對目標模塊的操作。API1065.1軟件設計的基本概念
5.1.2軟件設計的原則->模塊化.抽象.逐步求精.信息隱藏.復用性設計.靈活性設計
5.復用性設計
軟件復用(重用)就是將已有的軟件成分用于構(gòu)造新的軟件系統(tǒng)。可以被復用的軟件成分一般稱作可復用構(gòu)件,無論對可復用構(gòu)件原封不動地使用還是作適當?shù)男薷暮笤偈褂?,只要是用來?gòu)造新軟件,則都可稱作復用。軟件復用不僅僅是對程序的復用,它還包括對軟件生產(chǎn)過程中任何活動所產(chǎn)生的制成品的復用,如軟件開發(fā)計劃、可行性研究報告、分析模型、設計模型、源程序`、測試用例等等。如果是在一個系統(tǒng)中多次使用一個相同的軟件成分,則不稱作復用,而稱作共享;對一個軟件進行修改,使它運行于新的軟硬件平臺也不稱作復用,而稱作軟件移值。1075.1軟件設計的基本概念
5.1.2軟件設計的原則->模塊化.抽象.逐步求精.信息隱藏.復用性設計.靈活性設計
降低耦合并提高內(nèi)聚建立抽象不要將代碼寫死拋出異常使用并創(chuàng)建可復用的代碼在設計(尤其是面向?qū)ο蟮脑O計)中引入靈活性的方法靈活性設計,簡而言之就是軟件在面對需求修改時的隨機應變能力,可以體現(xiàn)在修改程序代碼的工程量等方面。抽象是軟件設計的關(guān)鍵因素。設計模式、軟件架構(gòu)等可以用來實現(xiàn)更高抽象層次的編程,以達到軟件的靈活性1085.1軟件設計的基本概念
5.1.3軟件設計的分類活動任務觀點.工程管理觀點軟件設計活動任務工程管理1.數(shù)據(jù)設計
2.體系結(jié)構(gòu)設計3.接口設計4.構(gòu)件設計和部署設計。1.概要設計(總體設計)2.詳細設計1095.1軟件設計的基本概念
5.1.3軟件設計的分類活動任務觀點.工程管理觀點軟件設計活動任務工程管理數(shù)據(jù)設計、體系結(jié)構(gòu)設計、接口設計、構(gòu)件設計和部署設計。1)數(shù)據(jù)設計創(chuàng)建在高抽象級別上表示的數(shù)據(jù)模型和信息模型。然后,數(shù)據(jù)模型被精化為越來越多和實現(xiàn)相關(guān)的特定表示,即基于計算機的系統(tǒng)能夠處理的表示。2)體系結(jié)構(gòu)設計為我們提供軟件的整體視圖,定義了軟件系統(tǒng)各主要成份之間的關(guān)系。3)接口設計告訴我們信息如何流入和流出系統(tǒng)以及被定義為體系結(jié)構(gòu)一部分的構(gòu)件之間是如何通信的。4)構(gòu)件設計完整的描述了每個軟件構(gòu)件的內(nèi)部細節(jié),為所有本地數(shù)據(jù)對象定義數(shù)據(jù)結(jié)構(gòu),為所有在構(gòu)件內(nèi)發(fā)生的處理定義算法細節(jié),并定義允許訪問所有構(gòu)件操作的接口。5)部署設計指明軟件功能和子系統(tǒng)如何在支持軟件的物理計算環(huán)境內(nèi)分布。1105.1軟件設計的基本概念
5.1.3軟件設計的分類活動任務觀點.工程管理觀點軟件設計活動任務工程管理概要設計確定軟件的結(jié)構(gòu)以及各組成部分之間的相互關(guān)系。它以需求規(guī)格說明書為基礎,概要地說明軟件系統(tǒng)的實現(xiàn)方案,包括:目標系統(tǒng)的總體架構(gòu)每個模塊的功能描述、數(shù)據(jù)接口描述及模塊之間的調(diào)用關(guān)系數(shù)據(jù)庫、數(shù)據(jù)定義和數(shù)據(jù)結(jié)構(gòu)等其中,目標系統(tǒng)的總體架構(gòu)為軟件系統(tǒng)提供了一個結(jié)構(gòu)、行為和屬性的高級抽象,由構(gòu)成系統(tǒng)的元素的描述、這些元素之間的相互作用、指導元素集成的模式以及這些模式的約束組成。1115.1軟件設計的基本概念
5.1.3軟件設計的分類活動任務觀點.工程管理觀點軟件設計活動任務工程管理詳細設計確定模塊內(nèi)部的算法和數(shù)據(jù)結(jié)構(gòu),產(chǎn)生描述各模塊程序過程的詳細文檔。它對每個模塊的功能和架構(gòu)進行細化,明確要完成相應模塊的預定功能所需要的數(shù)據(jù)結(jié)構(gòu)和算法,并將其用某種形式描述出來。詳細設計的目標是得到實現(xiàn)系統(tǒng)的最詳細的解決方案,明確對目標系統(tǒng)的精確描述,從而在編碼階段可以方便地把這個描述直接翻譯為用某種程序設計語言書寫的程序。在進行詳細設計的過程中,設計人員的工作涉及到的內(nèi)容有過程、數(shù)據(jù)和接口等。過程設計主要是指描述系統(tǒng)中每個模塊的實現(xiàn)算法和細節(jié)數(shù)據(jù)設計是對各模塊所用到的數(shù)據(jù)結(jié)構(gòu)的進一步細化接口設計針對的是軟件系統(tǒng)各模塊之間的關(guān)系或通信方式以及目標系統(tǒng)與外部系統(tǒng)之間的聯(lián)系5.2軟件體系結(jié)構(gòu)什么是軟件體系結(jié)構(gòu)?軟件體系結(jié)構(gòu)是系統(tǒng)的一個或多個結(jié)構(gòu),它包括1)軟件的組成元素(組件)2)這些(組件)元素的外部可見特性3)這些元素(組件)之間的相互關(guān)系軟件體系結(jié)構(gòu)不僅指定了系統(tǒng)的組織結(jié)構(gòu)和拓撲結(jié)構(gòu),也顯示了系統(tǒng)需求和構(gòu)成系統(tǒng)的元素之間的對應關(guān)系,提供了一些設計決策的基本原理。什么是軟件體系結(jié)構(gòu)?軟件體系結(jié)構(gòu)描述的對象是直接構(gòu)成系統(tǒng)的抽象組件。它由功能各異、相互作用的部件按照層次構(gòu)成,包含了系統(tǒng)的基礎構(gòu)成單元、單元之間的相互作用關(guān)系、在構(gòu)成系統(tǒng)時它們的合成方法以及對合成約束的描述。具體來說,部件包括客戶端、服務器、數(shù)據(jù)庫、程序包、過程、子程序等一切軟件的組成部分。相互作用的關(guān)系可以是過程調(diào)用、消息傳遞、共享內(nèi)存變量、客戶端/服務器的訪問協(xié)議、數(shù)據(jù)庫的訪問協(xié)議等。軟件體系結(jié)構(gòu)的作用
設計軟件的體系結(jié)構(gòu)在設計階段非常重要。軟件體系結(jié)構(gòu)就好比軟件系統(tǒng)的骨骼,如果骨骼確定了,那么軟件系統(tǒng)的框架就確定了。設計軟件體系的過程中應當包含以下幾項:1)定義基本構(gòu)件、構(gòu)建打包方式以及相互作用的方式2)明確系統(tǒng)如何實現(xiàn)功能、性能、可靠性、安全性等各個方面需求3)盡量使用已有的構(gòu)件軟件體系結(jié)構(gòu)的作用
軟件體系結(jié)構(gòu)在軟件開發(fā)過程中的作用如下:2)便于開發(fā)人員與用戶的溝通
開發(fā)人員與系統(tǒng)設計人員、用戶以及其他有關(guān)人員之間進行有效溝通,可以達成某些一致。應用軟件體系結(jié)構(gòu)的思想方法可以更好劃分范圍,規(guī)劃時間成本,應對客戶不夠明確的需求。1)規(guī)范軟件開發(fā)的基本架構(gòu)體系結(jié)構(gòu)一般與需求密切相關(guān),明確的需求可以產(chǎn)生明確的規(guī)格,使設計出來的軟件結(jié)構(gòu)更清晰。需求的變更也需要考慮,明確的變更趨勢可以提早在設計中體現(xiàn)。軟件體系結(jié)構(gòu)的作用
3)模塊化、層次化設計有利于減少返工提高效率,模塊越獨立越好,盡量把有明確需求的應用劃分為獨立模塊,減少模塊之間的交集。層次化設計就是一層一層分割,利用分層處理復雜功能,下層執(zhí)行簡單功能,上層調(diào)用功能,可以有效杜絕層次之間的交集。4)便于系統(tǒng)開發(fā)前后期的籌備與服務利用體系結(jié)構(gòu)的思想開發(fā)產(chǎn)品不僅可以規(guī)范流程,節(jié)省時間,還能留下大量開發(fā)文檔、產(chǎn)品類型框架、軟件開發(fā)標準流程等資料,為今后的售前咨詢和售后服務提供參考。
兩種常用的軟件體系結(jié)構(gòu)如圖所示樹形結(jié)構(gòu)網(wǎng)狀結(jié)構(gòu)軟件體系結(jié)構(gòu)的作用典型的軟件體系結(jié)構(gòu)風格
典型的軟件體系結(jié)構(gòu)風格
軟件體系結(jié)構(gòu)風格包含4個關(guān)鍵要素:1)提供一個詞匯表2)定義一套配置規(guī)則3)定義一套語義解釋規(guī)則4)定義對基于這種風格的系統(tǒng)進行的分析根據(jù)以上4要素框架,Garlan和Shaw對通用軟件體系結(jié)構(gòu)風格的進行分類,每種體系結(jié)構(gòu)風格有各自的應用領(lǐng)域和優(yōu)缺點。所謂軟件體系結(jié)構(gòu)風格,是描述某一特定應用領(lǐng)域中系統(tǒng)組織方式的慣用模式。數(shù)據(jù)流風格
數(shù)據(jù)到達即被激活處理工作,無數(shù)據(jù)時不工作。一般來說,數(shù)據(jù)的流向是有序的。在純數(shù)據(jù)流系統(tǒng)中,處理之間除了數(shù)據(jù)交換,沒有任何其他的交互。主要研究近似線性的數(shù)據(jù)流,或在限度內(nèi)的循環(huán)數(shù)據(jù)流。其中包括批處理序列、管道/過濾器。調(diào)用
∕
返回風格
各個構(gòu)件通過調(diào)用其他構(gòu)件和獲得返回參數(shù)來進行交互,配合完成功能。包括主程序/子程序、面向?qū)ο箫L格、層次結(jié)構(gòu)。主程序子程序子程序子程序獨立構(gòu)件風格
這種風格的主要特點是:事件的觸發(fā)者并不知道哪些構(gòu)件會被這些事件影響,相互保持獨立,這樣不能假定構(gòu)件的處理順序,甚至不知道哪些過程會被調(diào)用各個構(gòu)件之間彼此無連接關(guān)系,各自獨立存在,通過對事件的發(fā)布和注冊實現(xiàn)關(guān)聯(lián),其中包括進程通訊、事件系統(tǒng)虛擬機風格
它創(chuàng)建了一種虛擬的環(huán)境,將用戶與底層平臺隔離開來,或者將高層抽象和底層實現(xiàn)隔離開來。其中包括解釋器、基于規(guī)則的系統(tǒng)倉庫風格
倉庫是存儲和維護數(shù)據(jù)的中心場所。在倉庫風格中存在兩類構(gòu)件,表示當前數(shù)據(jù)的狀態(tài)的中心數(shù)據(jù)結(jié)構(gòu)和一組對中心數(shù)據(jù)進行操作的獨立構(gòu)件。其中包括數(shù)據(jù)庫系統(tǒng)、超文本系統(tǒng)、黑板系統(tǒng)??蛻舳?服務器體系結(jié)構(gòu)
客戶端/服務器(Client/Server,簡稱C/S)體系結(jié)構(gòu)是為了共享不對等的資源而提出來的,是20世紀90年代成熟起來的技術(shù),C/S體系結(jié)構(gòu)定義了客戶端如何與服務器連接,以將數(shù)據(jù)和應用系統(tǒng)分部到多個處理機上。C/S體系結(jié)構(gòu)有3個主要的組成部分。服務器:負責給其子系統(tǒng)提供服務,如數(shù)據(jù)庫服務器提供數(shù)據(jù)存儲和管理服務,文件服務器提供文件管理服務,搜索服務器提供數(shù)據(jù)檢索等。客戶端:通常是獨立的子系統(tǒng),通過向服務器請求約定的資源獲取數(shù)據(jù)。一臺服務器可以同時為許多客戶端提供服務。網(wǎng)絡:連接服務器和客戶端。有時客戶端和服務器位于同一臺物理主機上,但多數(shù)情況下它們分布在不同主機上。網(wǎng)絡可以有各種形式,包括有線和無線等。
客戶端/服務器體系結(jié)構(gòu)C/S系統(tǒng)的設計必須考慮應用系統(tǒng)的邏輯結(jié)構(gòu)在邏輯上,我們通常將應用系統(tǒng)劃分為3層,即數(shù)據(jù)管理層、應用邏輯層和表示層數(shù)據(jù)管理層主要處理數(shù)據(jù)存儲和管理操作應用邏輯層處理與業(yè)務相關(guān)的邏輯表示層處理用戶界面以及用戶的交互在集中式系統(tǒng)中,不需要將這些清楚地分離,但在分布式系統(tǒng)中,不同層常常被部署在不同的主機上,因此必須嚴格地分離不同層。
客戶端/服務器體系結(jié)構(gòu)C/S體系結(jié)構(gòu)C/S體系結(jié)構(gòu)通常有兩層或三層,也可根據(jù)需要劃分為更多層兩層C/S結(jié)構(gòu)一般有兩種形態(tài):瘦客戶端模型。在瘦客戶端模型中,數(shù)據(jù)管理和應用邏輯都在服務器端執(zhí)行,客戶端只負責表示部分胖客戶端模型。在這種模型中,服務器只負責對數(shù)據(jù)的管理??蛻舳松系能浖崿F(xiàn)應用邏輯以及與系統(tǒng)的交互
隨著軟件復雜度不斷提高,胖客戶端模型逐漸暴露出以下缺點:開發(fā)成本高。C/S體系對客戶端的配置要求較高,增加系統(tǒng)成本,且會使客戶端越來越臃腫用戶界面風格不一,使用繁雜,不利于推廣使用軟件移植困難,采用不同開發(fā)工具和平臺開發(fā)的軟件之間一般不兼容,有時不得不因此開發(fā)針對另一平臺的版本軟件維護和升級困難,由于應用程序安裝在客戶端上,需要維護時必須升級和維護所有客戶端客戶端/服務器體系結(jié)構(gòu)在兩層C/S結(jié)構(gòu)需要考慮如何將三個邏輯層映射到兩個系統(tǒng),在瘦客戶端模型存在伸縮性和性能問題,在胖客戶端模型則存在系統(tǒng)管理問題
三層C/S結(jié)構(gòu)就避免了這個問題,將數(shù)據(jù)管理層和應用邏輯層分別放在兩個物理層或物理主機上,客戶端仍然保留在客戶端上。對于三層C/S結(jié)構(gòu),各層的功能或指責如下:表示層表示層是應用系統(tǒng)的用戶界面部分,擔負著用戶與應用程序之間的對話功能。通常采用圖形界面的方式呈現(xiàn)應用邏輯層應用邏輯層為應用系統(tǒng)的主體,包含全部的業(yè)務邏輯。比如數(shù)據(jù)處理,用戶管理,與其他系統(tǒng)交互,以及記錄系統(tǒng)日志等。通常是應用服務器。數(shù)據(jù)層數(shù)據(jù)層一般只負責數(shù)據(jù)的存取、管理和維護(如備份等),通常是關(guān)系型數(shù)據(jù)庫服務器客戶端/服務器體系結(jié)構(gòu)瀏覽器/服務器(Browser/Server,簡稱B/S)結(jié)構(gòu)是三層應用結(jié)構(gòu)的一種實現(xiàn),其具體結(jié)構(gòu)為瀏覽器/Web服務器/數(shù)據(jù)庫服務器
三層結(jié)構(gòu)的優(yōu)點:通過合理劃分三層結(jié)構(gòu),使之在邏輯上保持相對獨立,提高系統(tǒng)的可維護性和可擴展性。能夠更靈活選用相應的平臺和應用系統(tǒng),使之在處理負荷能力和處理特性上分別適應各層的要求,并具有良好的可升級性和開放性。應用各層可以獨立并行開發(fā),每層可以根據(jù)特點選用合適的開發(fā)語言。安全性相對較高,因為應用層屏蔽了用戶直接訪問數(shù)據(jù)庫的權(quán)利,使得未授權(quán)用戶或黑客難以繞過應用層獲取數(shù)據(jù)但三層結(jié)構(gòu)必須精心設計通信模塊,以避免通信稱為瓶頸限制服務器的發(fā)揮??蛻舳?服務器體系結(jié)構(gòu)模型-視圖-控制器
MVC(Model-View-Controller)模型由TrygveReenskaug博士在20世紀70年代提出,并最早在面向?qū)ο缶幊陶Z言Smalltalk-80中實現(xiàn)MVC強調(diào)將用戶的輸入、數(shù)據(jù)模型和數(shù)據(jù)表示方式分開設計,一個交互式應用系統(tǒng)由模型、視圖、控制器3部分組成,分別對應內(nèi)部數(shù)據(jù)、數(shù)據(jù)表示和輸入/輸出控制部分模型-視圖-控制器
模型模型對象代表應用領(lǐng)域中的業(yè)務實體和業(yè)務邏輯規(guī)則,是整個模型的核心,獨立于外在的顯示內(nèi)容和顯示形式。模型對象的變化通過事件通知視圖和控制器對象。采用了發(fā)布者/訂閱者方式,模型是發(fā)布者,視圖和控制器是訂閱者。對于模型來說,并不知道自己對應的視圖控制器;但控制器可以通過模型提供的接口改變模型對象,接口內(nèi)封裝了業(yè)務數(shù)據(jù)和行為。
視圖視圖對象代表GUI對象,以用戶熟悉和需要的格式表現(xiàn)模型信息,是系統(tǒng)與外界的交互接口。視圖訂閱模型可以感知模型的數(shù)據(jù)變化,并更新自己的顯示。視圖對象也可以包含子視圖,用于顯示模型的不同部分。在多數(shù)的MVC實現(xiàn)技術(shù)中,視圖和控制器常常是一一對應的??刂破骺刂破鲗ο筇幚碛脩舻妮斎耄⒔o模型發(fā)送業(yè)務事件,再將業(yè)務事件解析為模型應執(zhí)行的動作;同時,模型的更新與修改也將通過控制器來通知視圖,保持視圖與模型的一致。MVC的整個處理流程為:系統(tǒng)攔截到用戶請求,根據(jù)相應規(guī)則(多數(shù)采用路由技術(shù)),將用戶請求交給控制器,控制器決定哪個模型來處理用戶的請求模型根據(jù)業(yè)務邏輯處理完畢后將結(jié)果返回給控制器然后控制器將數(shù)據(jù)提交給視圖;視圖把數(shù)據(jù)組裝之后,呈現(xiàn)給用戶模型-視圖-控制器其中,模型處理所有的業(yè)務邏輯和規(guī)則,視圖只負責顯示數(shù)據(jù),控制器負責用戶的請求,這樣將業(yè)務和表現(xiàn)層分離,以便業(yè)務代碼可以被用于任何相似的業(yè)務中,視圖代碼也可以根據(jù)需要隨意替換。5.3結(jié)構(gòu)化設計概述5.3結(jié)構(gòu)化設計概述
一二三從軟件需求規(guī)格說明書出發(fā)設計軟件系統(tǒng)的整體結(jié)構(gòu)確定每個模塊的實現(xiàn)算法以及編寫具體的代碼概要(總體)設計階段&過程(詳細)設計階段概要設計:體系結(jié)構(gòu)設計、數(shù)據(jù)設計及接口設計。過程設計:它詳細地設計每個模塊,確定完成每個模塊功能所需要的算法和數(shù)據(jù)結(jié)構(gòu)。設計決策決定成果設計決策將決定軟件維護的難易程度設計是軟件開發(fā)過程中決定軟件產(chǎn)品質(zhì)量的關(guān)鍵階段。5.4結(jié)構(gòu)化設計與結(jié)構(gòu)化分析的關(guān)系1385.4
結(jié)構(gòu)化設計與結(jié)構(gòu)化分析的關(guān)系
數(shù)據(jù)設計體系結(jié)構(gòu)設計接口設計過程設計數(shù)據(jù)對象描述處理規(guī)格說明控制規(guī)格說明狀態(tài)轉(zhuǎn)換圖數(shù)據(jù)流圖實體—關(guān)系圖數(shù)據(jù)字典要進行結(jié)構(gòu)化的設計,必須依據(jù)結(jié)構(gòu)化分析的結(jié)果,結(jié)構(gòu)化設計與結(jié)構(gòu)化分析的關(guān)系如圖所示。圖的左邊是用結(jié)構(gòu)化分析方法所建立的模型,圖的右邊是用結(jié)構(gòu)化設計方法所建立的設計模型。1395.4
結(jié)構(gòu)化設計與結(jié)構(gòu)化分析的關(guān)系
結(jié)構(gòu)化軟件設計的具體步驟如下:1)從需求分析階段的數(shù)據(jù)流圖出發(fā),制訂幾個方案,從中選擇合理的方案。2)采用某種設計方法,將一個復雜的系統(tǒng)按功能劃分成模塊化的層次結(jié)構(gòu)。3)確定每個模塊的功能、模塊間的調(diào)用關(guān)系,建立與已確定的軟件需求的對應關(guān)系。4)系統(tǒng)接口設計,確定模塊間的接口信息。5)數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫設計,確定實現(xiàn)軟件的數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)庫模式。6)基于以上,并依據(jù)分析模型中的處理(加工)規(guī)格說明、狀態(tài)轉(zhuǎn)換圖及控制規(guī)格說明進行過程設計。7)制訂測試計劃。8)撰寫軟件設計文檔。5.5結(jié)構(gòu)化設計方法1415.5
結(jié)構(gòu)化設計方法
5.5.1表示軟件結(jié)構(gòu)的圖形工具5.5.2面向數(shù)據(jù)流的設計方法5.5.3面向數(shù)據(jù)結(jié)構(gòu)的設計方法1425.5
結(jié)構(gòu)化設計方法
5.5.1表示軟件結(jié)構(gòu)的圖形工具1.層次圖和HIPO圖
2.結(jié)構(gòu)圖
通常使用層次圖描繪軟件的層次結(jié)構(gòu)。在層次圖中一個矩形框代表一個模塊,框間的連線表示調(diào)用關(guān)系(位于上方的矩形框所代表的模塊調(diào)用位于下方的矩形框所代表的模塊)。每個方框可以帶編號,像這樣帶編號的層次圖稱為HIPO(HierarchyInput-Process-Output)圖,如圖所示。1435.5.1表示軟件結(jié)構(gòu)的圖形工具1.層次圖和HIPO圖
2.結(jié)構(gòu)圖結(jié)構(gòu)圖是描繪軟件結(jié)構(gòu)的圖形工具,圖中一個方框代表一個模塊,框內(nèi)注明模塊的名字或主要功能;方框之間的箭頭(或直線)表示模塊的調(diào)用關(guān)系。在結(jié)構(gòu)圖中通常還用帶注釋的箭頭表示模塊調(diào)用過程中來回傳遞的信息。如果希望進一步標明傳遞的信息是數(shù)據(jù)還是控制信息,則可以利用注釋箭頭尾部的形狀來區(qū)分:尾部是空心圓表示傳遞的是數(shù)據(jù),實心圓表示傳遞的是控制信息。5.5
結(jié)構(gòu)化設計方法
1445.5.1表示軟件結(jié)構(gòu)的圖形工具1.層次圖和HIPO圖
2.結(jié)構(gòu)圖有時還會用一些附加的符號,如用菱形表示選擇或者條件調(diào)用,用弧形箭頭表示循環(huán)調(diào)用,如圖所示。選擇/條件調(diào)用循環(huán)調(diào)用5.5
結(jié)構(gòu)化設計方法
145
5.5.2面向數(shù)據(jù)流的設計方法面向數(shù)據(jù)流的設計方法是常用的結(jié)構(gòu)化設計方法,多在概要設計階段使用。它主要是指依據(jù)一定的映射規(guī)則,將需求分析階段得到的數(shù)據(jù)描述從系統(tǒng)的輸入端到輸出端所經(jīng)歷的一系列變換或處理的數(shù)據(jù)流圖轉(zhuǎn)換為目標系統(tǒng)的結(jié)構(gòu)描述。在數(shù)據(jù)流圖中,數(shù)據(jù)流分為變換型數(shù)據(jù)流和事務型數(shù)據(jù)流兩種。所謂變換,是指把輸入的數(shù)據(jù)處理后轉(zhuǎn)變成另外的輸出數(shù)據(jù)。信息沿輸入路徑流入系統(tǒng),在系統(tǒng)中經(jīng)過加工處理后又離開系統(tǒng),當信息流具備這種特征時就是變換流。所謂事務,是指非數(shù)據(jù)變換的處理,它將輸入的數(shù)據(jù)流分散成許多數(shù)據(jù)流,形成若干個加工,然后選擇其中一個路徑來執(zhí)行。5.5
結(jié)構(gòu)化設計方法
146
5.5.2面向數(shù)據(jù)流的設計方法1.變換型數(shù)據(jù)流2.事務型數(shù)據(jù)流通常,在一個大型系統(tǒng)中,可能同時存在變換型數(shù)據(jù)流和事務型數(shù)據(jù)流。對于變換型數(shù)據(jù)流,設計人員應該重點區(qū)分其輸入和輸出分支,通過變換分析將數(shù)據(jù)流圖映射為變換結(jié)構(gòu),從而構(gòu)造出目標系統(tǒng)的結(jié)構(gòu)圖。針對變換型數(shù)據(jù)流的設計可以分為以下幾個步驟:(1)區(qū)分變換型數(shù)據(jù)流中的輸入數(shù)據(jù)、變換中心和
輸出數(shù)據(jù),并在數(shù)據(jù)流圖上用虛線標明分界線。(2)分析得到系統(tǒng)的初始結(jié)構(gòu)圖。(3)對系統(tǒng)結(jié)構(gòu)圖進行優(yōu)化。變換型數(shù)據(jù)流5.5
結(jié)構(gòu)化設計方法
147
5.5.2面向數(shù)據(jù)流的設計方法1.變換型數(shù)據(jù)流2.事務型數(shù)據(jù)流對于事務型數(shù)據(jù)流,設計人員應該重點區(qū)分事務中心和數(shù)據(jù)接收通路,通過事務分析將數(shù)據(jù)流圖映射為事務結(jié)構(gòu)。針對事務型數(shù)據(jù)流的設計可以分為以下幾個步驟:(1)確定以事務為中心的結(jié)構(gòu),找出事務中心、接
收數(shù)據(jù)、處理路徑這三個部分。(2)將數(shù)據(jù)流圖轉(zhuǎn)換為初始的系統(tǒng)結(jié)構(gòu)圖。(3)分解和細化接收分支和處理分支事務型數(shù)據(jù)流5.5
結(jié)構(gòu)化設計方法
5.5.3面向數(shù)據(jù)結(jié)構(gòu)的設計方法148
軟件結(jié)構(gòu)設計軟件結(jié)構(gòu)描述輸入數(shù)據(jù)結(jié)構(gòu)輸出方法:Jackson方法和Warnier方法面向數(shù)據(jù)結(jié)構(gòu)的設計方法就是根據(jù)數(shù)據(jù)結(jié)構(gòu)設計程序處理過程的方法,具體地說,面向數(shù)據(jù)結(jié)構(gòu)的設計方法按輸入、輸出以及計算機內(nèi)部存儲信息的數(shù)據(jù)結(jié)構(gòu)進行軟件結(jié)構(gòu)設計,從而把對數(shù)據(jù)結(jié)構(gòu)的描述轉(zhuǎn)換為對軟件結(jié)構(gòu)的描述。使用面向數(shù)據(jù)結(jié)構(gòu)的設計方法時,分析目標系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)是關(guān)鍵。5.5
結(jié)構(gòu)化設計方法
5.5.3面向數(shù)據(jù)結(jié)構(gòu)的設計方法149
Jackson方法把數(shù)據(jù)結(jié)構(gòu)分為3
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
- 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 二零二五版跨境電商平臺傭金比例調(diào)整合同3篇
- 二零二五版?zhèn)€人教育貸款擔保合同模板3篇
- 二零二五年建筑裝修幫工雇傭合同2篇
- 二零二五版寄賣合同范本:藝術(shù)品寄售代理中介服務協(xié)議2篇
- 二零二五版辦公設備智能化升級改造合同5篇
- 二零二五版橋梁工程勞務分包合同模板6篇
- 二零二五版職工住房借款與社區(qū)文化活動支持合同3篇
- 二零二五年度黃牛養(yǎng)殖與屠宰行業(yè)購銷法律法規(guī)遵守合同3篇
- 二零二五年鋁藝門安裝與外觀設計承包合同3篇
- 二零二五年度電商代發(fā)貨及品牌授權(quán)合同2篇
- 店鋪交割合同范例
- 大型活動LED屏幕安全應急預案
- 舞蹈課家長會
- 2024年內(nèi)蒙古包頭市中考道德與法治試卷
- 湖南省長沙市2024-2025學年高二上學期期中考試地理試卷(含答案)
- 自來水質(zhì)量提升技術(shù)方案
- 金色簡約蛇年年終總結(jié)匯報模板
- 農(nóng)用地土壤環(huán)境質(zhì)量類別劃分技術(shù)指南(試行)(環(huán)辦土壤2017第97號)
- 反向開票政策解讀課件
- 工程周工作計劃
- 房地產(chǎn)銷售任務及激勵制度
評論
0/150
提交評論