毛明志老師軟件工程期末總結(jié)-內(nèi)容填充版_第1頁
毛明志老師軟件工程期末總結(jié)-內(nèi)容填充版_第2頁
毛明志老師軟件工程期末總結(jié)-內(nèi)容填充版_第3頁
毛明志老師軟件工程期末總結(jié)-內(nèi)容填充版_第4頁
毛明志老師軟件工程期末總結(jié)-內(nèi)容填充版_第5頁
已閱讀5頁,還剩54頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

第一章:

1.1

補充一下1.1

計算機軟件:指計算機系統(tǒng)中的程序及其文檔。程序是計算任務(wù)的處理對象和處理

規(guī)則的描述。

1.1.2

軟件的特點:

1軟件是一種邏輯實體,開發(fā)成本和進度難以準確估算;

2軟件是被開發(fā)或被設(shè)計的,沒有明顯的制造過程,一旦開發(fā)成功,只需復(fù)制,

但維護的工作量大

3軟件使用沒有硬件的機械磨損和老化問題,但使用過程有維護問題,維護修改

程序的時候可能引入副作用,使故障率升高。

1.1.3

軟件的分類

1系統(tǒng)軟件:操作系統(tǒng)、編譯程序等

2支撐軟件:數(shù)據(jù)庫管理系統(tǒng)、網(wǎng)絡(luò)軟件等

3應(yīng)用軟甲:各類特定應(yīng)用程序

1.2

1.2.1

軟件工程定義

IEEE:軟件工程是:

①將系統(tǒng)化的、嚴格約束的、可量化的方法應(yīng)用于軟件的開發(fā)、運行和維護,

即將工程化應(yīng)用于軟件;

②在①中所述方法的研究。

1.2.2

軟件工程框架:概括為目標、過程和原則

目標:生產(chǎn)具有正確性,可用性和開銷合宜的產(chǎn)品。

過程:生產(chǎn)一個最終滿足需求且達到工程目標的軟件產(chǎn)品所需要的步驟。

原則:

①選取適宜的開發(fā)模型

②采用合適的設(shè)計方法

③提供高質(zhì)量的工程支撐

④重視軟件工程的管理

1.2.3

軟件生存周期:六階段

①計算機系統(tǒng)工程:確定軟件開發(fā)的要求和范圍,估算成本,安排進度,可行性

分析。

②需求分析:要“做什么”,確定軟件功能、性能、數(shù)據(jù)、界面等要求,生成軟

件需求規(guī)約。

③設(shè)計:要“怎么做”,分為系統(tǒng)(總體)設(shè)計和詳細設(shè)計。

前者設(shè)計軟件系統(tǒng)的體系結(jié)構(gòu),包括軟件系統(tǒng)的組成部分,各成分的功能和接口,

成分間的連接和通信,同時設(shè)計全局數(shù)據(jù)結(jié)構(gòu);

后者設(shè)計各個組成成分的實現(xiàn)細節(jié),包括局部數(shù)據(jù)和算法

④編碼:用某種程序設(shè)計語言,將設(shè)計結(jié)果轉(zhuǎn)換為可執(zhí)行代碼。

⑤測試:任務(wù)是發(fā)現(xiàn)并糾正軟件中的錯誤和缺陷。主要包括單元測試、集成測試、

確認測試和系統(tǒng)測試。

⑥運行和維護:軟件測試完成即可交付使用。在軟件運行期間,需對投入運行的

軟件進行維護,即當發(fā)現(xiàn)軟件中潛藏錯誤或需要增加功能或適應(yīng)新外部環(huán)境變化等,對

軟件進行修改。

1.3

1.3.1了解

ISO/IEC12207軟件工程生存周期過程

該標準把軟件生存周期中可以開展的活動分為5個基本過程,8個支持過程和4個

組織過程。每一個過程劃分為一組活動,每項活動又進一步劃分為一組任務(wù)。

(內(nèi)容坑爹,無視,P9~P12約3頁的表格,有興趣的自己看

(話說了解比知道要輕..現(xiàn)在我這么覺得

1.3.2

能力成熟度模型CMM

5級:

初始級:無秩序或混亂,成功依賴個人或小組的努力

可重復(fù)級:建立了基本的項目管理過程來跟蹤成本、進度和功能特性。制定了必要

的過程紀律,能重復(fù)早先類似應(yīng)用項目的成功。

已定義級:以將管理和工程活動兩方面的軟件過程文檔化、標準化,并綜合成該組

織的標準軟件過程。所有項目均使用經(jīng)批準、剪裁的標準軟件過程來開發(fā)和維護軟件。

已管理級:收集對軟件過程和產(chǎn)品質(zhì)量的詳細度量值,對軟件過程和產(chǎn)品都有定量

的理解和控制。

優(yōu)化級:過程的量化反饋和先進的新思想、新技術(shù)促使過程不斷改進

CMM的結(jié)構(gòu)P14有興趣的..

1.3.3知道

能力成熟度模型集成CMMI

兩種表示法:

①階段式模型:同CMM,關(guān)注組織成熟度,5級

初始的、已管理的、已定義的、定量管理的、優(yōu)化的。

②連續(xù)式模型:關(guān)注每個過程域的能力,分為6級:

CL0:未完成的:未執(zhí)行或未達到Q1定義的所有目標

CL1:已執(zhí)行的:共性目標是過程將可標識的輸入工作產(chǎn)品轉(zhuǎn)換成可標識的輸出工

作產(chǎn)品,以實現(xiàn)支持過程域的特定目標。

CL2:已管理的:共性目標集中于已管理的過程的制度化。

CL3:已定義級的:共性目標集中于以定義過程的制度化。

CL4:定量管理的:共性目標集中于可定量管理的過程的制度化。

CL5:優(yōu)化的使用量化(統(tǒng)計學(xué))手段改變和優(yōu)化過程域,以對付客戶要求的該百

年和持續(xù)改進計劃中的過程域的功效。

1.4

常見模型的種類,特點,優(yōu)缺點,不同模型間對比

瀑布模型:一路向下,可倒流回到上一級,7級

系統(tǒng)工程->需求分析與規(guī)約->設(shè)計與規(guī)約。編碼與單元測試〉

集成測試系統(tǒng)測試。運行與維護

演化模型:先做原型給用戶,根據(jù)使用意見逐步改造,最終得到令客戶滿意的產(chǎn)品。

典型的模型有:增量模型、原型模型、螺旋模型(?.居然這模型和后面這三種在同一級

的標題

增量模型:將開發(fā)過程分成若干個日程時間交錯的線性序列,每個線性序列都產(chǎn)生

軟件的一個可發(fā)布“增量版本”。(越看越像流水線

原型模型:快速計劃,快速設(shè)計方式建模,構(gòu)建原型。部署交付和反饋。交流??焖?/p>

計劃……不斷循環(huán)。根據(jù)原型目的不同可分為:探索型、實驗型、演化型。使用策略分

為廢棄策略、追加策略。

螺旋模型:制定計劃->風(fēng)險分析〉工程實施,客戶評估不斷循環(huán)。風(fēng)險太大則可能

終止

噴泉模型:支持面向?qū)ο箝_發(fā)的過程模型,開發(fā)各個活動沒有明顯邊界,各個活動

經(jīng)常重復(fù)、迭代地進行?!皣娙斌w現(xiàn)了面向?qū)ο蠓椒ǖ牡蜔o間隙特性。六個活動:

演化,集成,測試,編碼,設(shè)計,分析

1.5

敏捷軟件開發(fā)基本概念,XP開發(fā)特點

敏捷軟件開發(fā)概念:

書上沒有,自由發(fā)揮。

簡單而言就是軟件工程用了,質(zhì)量提高了,但工作量太大以至于難以準時交付,

于是快節(jié)奏開發(fā)軟件的需求就來了,方法也出來了,這些方法就是敏捷軟件開發(fā)。

敏捷軟件開發(fā)價值觀:

②個人和交互高于過程和工具

③可運行軟件高于詳盡的文檔

④與客戶協(xié)作高于合同(契約)淡判

對變更及時作出反應(yīng)高于遵循計劃

敏捷軟件開發(fā)原則:12條P27有興趣的話..

XP:extremeprogramming極限編程。四個價值觀:交流,簡單,反饋,勇氣(追加

第5個謙虛)。

XP適用于軟件需求模糊且揮發(fā)性(今天要求明天可能就不需要了)強,開發(fā)團隊人

數(shù)在10人以下,開發(fā)地點集中的場合。(這是特點么..?

XP方法的12個核心實踐P29-30怎么都是這種..

1.完整的團隊

2.計劃對策

3.系統(tǒng)比喻

4.小發(fā)布

5.測試

6.簡單設(shè)計

7.結(jié)對編程

8.設(shè)計改進

9.持續(xù)集成

10.代碼全體共享

11.編碼標準

12.可持續(xù)步調(diào)

第二章

2.1

計算機系統(tǒng)的概念,內(nèi)容

基于計算機的系統(tǒng):通過處理信息來完成某些預(yù)定義目標而組織在一起的元素

的集合或排列。組成基于計算機系統(tǒng)的元素主要有:軟件、硬件、人員、數(shù)據(jù)庫、

文檔和規(guī)程。

軟件:計算機程序、數(shù)據(jù)結(jié)構(gòu)和相關(guān)的工作產(chǎn)品,以實現(xiàn)所需要的邏輯方法、

規(guī)程和控制;

硬件:指提供計算能力的電子設(shè)備、支持數(shù)據(jù)流的互連設(shè)備、提供外部世界功

能的電子機械設(shè)備(傳感器,馬達等)。

人員:硬件和軟件的用戶和操作者。

數(shù)據(jù)庫:通過軟件訪問并持久存儲的大型的有組織的信息集合。

文檔:描繪系統(tǒng)使用或操作的描述性信息。

規(guī)程:指定義每個系統(tǒng)元素的特定使用或系統(tǒng)所處的過程性語境的步驟。

一個基于計算機的系統(tǒng)可以是另一個更大的基于計算機的系統(tǒng)的一個宏元素

(組成部分)。

2.3

可行性分析的概念,分類

可行性分析:

一個基于計算機的系統(tǒng)通常受到資源和時間上的限制,可行性分析主要從經(jīng)

濟、技術(shù)、法律等方面分析給出的解決方案是否可行,能否在規(guī)定的資源和時間約

束下完成。

可行性分析分類:

①經(jīng)濟可行性:從成本、效益、貨幣的時間價值(通??捎媚昀蕘肀硎荆?、投

資回收期、純收入來分析。

②技術(shù)可行性:分為風(fēng)險分析、資源分析、技術(shù)分析。

③法律可行性。

第三章

需求工程的角色及其各個階段〃好吧,其實就是全部

3.1概述

需求工程是應(yīng)用已證實有效的技術(shù)、方法進行需求分析,確定客戶需求,幫助分析

人員理解問題,評估可行性,協(xié)商合理的解決方案、無歧義地規(guī)約方案、確認規(guī)約以及

將規(guī)約轉(zhuǎn)換到可運行的系統(tǒng)時的管理要求,需求工程通過合適的工具和符號系統(tǒng)地描述

開發(fā)系統(tǒng)及其行為特征和相關(guān)約束,形成需求文檔,并對用戶不斷變化的需求演進給予

支持。

分為6階段:

①需求獲?。和ㄟ^與用戶交流,對已有系統(tǒng)的觀察及對任務(wù)的分析,確定系統(tǒng)或

產(chǎn)品范圍等。

②需求分析與協(xié)商:對需求進行分類組織,分析每個需求與其他需求的關(guān)系以檢

查需求的?致性、重疊和遺漏的情況,并根據(jù)用戶的需要對需求排序。

③系統(tǒng)建模:通過合適的工具和符號地描述需求。分析和建模方法有:面向數(shù)據(jù)

流方法、面向數(shù)據(jù)結(jié)構(gòu)方法和面向?qū)ο蠓椒ā?/p>

④需求規(guī)約:需求規(guī)約是分析任務(wù)的最終產(chǎn)品,建立完整的信息描述、詳細功能

和行為描述、性能需求和設(shè)計約束說明、合適的驗收標準,給出對目標軟件的各種需求。

⑤需求驗證:對功能的正確性、完整性和清晰性以及其他需求給予評價。

⑥需求管理:對需求工程所有相關(guān)活動的規(guī)劃和控制。

3.2需求獲取

3.2.1軟件需求

①功能需求:系統(tǒng)要做什么,在何時做,在何時及如何修改或升級

②性能需求:軟件開發(fā)的技術(shù)性指標

③用戶或人的因素:用戶類型

④環(huán)境需求:軟件應(yīng)用的環(huán)境,包括硬件和軟件。

⑤界面需求:考慮來自其他系統(tǒng)的輸入,到其他系統(tǒng)的輸出,對數(shù)據(jù)格式的

特殊規(guī)定,對數(shù)據(jù)存儲介質(zhì)的規(guī)定。

⑥文檔需求:需要什么文檔,針對哪些讀者

⑦數(shù)據(jù)需求:考慮輸入、輸出數(shù)據(jù)的格式,接受、發(fā)送數(shù)據(jù)的頻率,數(shù)據(jù)的

準確性和精度,數(shù)據(jù)流量,數(shù)據(jù)需保持的時間。

⑧資源使用需求:考慮軟件運行時所需要的數(shù)據(jù)、其他軟件、內(nèi)存空間等資

源;軟件開發(fā)、維護所需人力、支撐軟件、開發(fā)設(shè)備等。

⑨安全保密要求。

⑩可靠性需求

①①軟件成本消耗與開發(fā)進度需求

①②其他非功能性要求。

3.2.2需求獲取方法與策略

①建立順暢的通信途徑

②訪談與調(diào)查

③觀察用戶操作路程

④組成聯(lián)合小組

⑤用況

3.3需求分析、協(xié)商與建模

3.3.1需求分析原則

?必須能夠表示和理解問題的信息域

?必須能夠定義軟件將完成的功能

?必須能夠表示軟件的行為(作為外部事件的結(jié)果)

?必須劃分描述數(shù)據(jù)、功能和行為的模型,從而可以分層次地揭示細節(jié)。

?分析過程應(yīng)該從要素信息移向細節(jié)信息。

3.3.2信息域

信息域包括:

信息內(nèi)容:表示了單個數(shù)據(jù)和控制對象,目標軟件所有處理的信息集合由它們構(gòu)成。

信息流:表示了數(shù)據(jù)和控制在系統(tǒng)中流動時的變化方式,輸入對象被變換為中間信

息(數(shù)據(jù)或控制),然后進一步被變換為輸出。

信息結(jié)構(gòu):表示了各種數(shù)據(jù)和控制項的內(nèi)部組織形式,比如數(shù)據(jù)或控制項將被組織

為n維表還是樹形結(jié)構(gòu)..?等

3.3.3抽象、分解與多視點分析

問題抽象方法要求分析人員在分析過程中捕捉用戶描述或問題本身固有的一般-特

殊關(guān)系,首先關(guān)注一般問題的解決途徑,進而指導(dǎo)特殊問題的解決方法。

問題分解的目的是要能以層次化的方式對問題進行分解和不斷細化。

分析人員在整理用戶描述的過程中應(yīng)注意用戶視角上的變化,避免由于視角不全引

起的需求遺缺。

3.3.4需求協(xié)商

復(fù)雜的系統(tǒng)又許多項目相關(guān)人員,他們之間的需求必定會出現(xiàn)沖突,協(xié)商的過程就

是討論需求沖突,找出每個人都滿意的折衷方案。

通常會議是解決沖突最快的方式。沖突解決會議應(yīng)當只關(guān)注與沖突相關(guān)的需求問

題。

通常會議分為3個階段:敘述階段、討論階段和決策階段。

3.3.5需求建模

在需求分析階段,所創(chuàng)建的模型,要著重于描述系統(tǒng)要做什么,而不是如何去做。

目標軟件的需求模型不應(yīng)涉及軟甲你的實現(xiàn)細節(jié)。

常用的分析方法有以下幾種:

面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法(SA)

面向數(shù)據(jù)結(jié)構(gòu)的分析方法

面向?qū)ο蟮姆治龇椒?00A)

3.4需求規(guī)約與驗證

3.4.1需求規(guī)約的原則

①從現(xiàn)實中分離功能

②使用面向處理的規(guī)約語言,討論來自環(huán)境的各種刺激可能導(dǎo)致系統(tǒng)做出什

么樣的功能性反應(yīng)。

③如果被開發(fā)軟件知識一個基于計算機的系統(tǒng)中的一個元素,那么整個大系

統(tǒng)也應(yīng)包括在規(guī)格說明的描述中

⑤規(guī)約必須包括系統(tǒng)運行環(huán)境。

⑥規(guī)約必須是一個認識模型,而不是設(shè)計或?qū)崿F(xiàn)的模型。

規(guī)約必修是可操作的,利用它能夠通過測試用例判斷已提出的解決方案是

否都能滿足規(guī)約。

⑦規(guī)約必須允許不完備性并允許擴充。

⑧規(guī)約必須局部化和松散耦合。

3.4.2需求規(guī)約

軟件需求規(guī)約的框架IEEE/ANSI830-1993標準:

1引言

2信息描述

3功能描述

4行為描述

5檢驗標準

6參考書目

7附錄

3.4.3需求驗證

需求驗證的目的是要檢驗需求是否能夠反映用戶的意愿。

評審人員評審時往往需要檢查以下內(nèi)容:

①系統(tǒng)定義的目標是否與用戶的要求?致

②系統(tǒng)需求分析階段提供的文檔資料是否齊全;文檔中的描述是否完整、清

晰、準確地反映了用戶要求。

被開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否確定且充足。

⑤主要功能是否已包括在規(guī)定的軟件范圍之內(nèi),是否都已充分說明

⑥設(shè)計的約束條件或限制條件是否符合實際。

⑦開發(fā)的技術(shù)風(fēng)險是什么。

是否制定了詳細的檢驗標準,它們能否對系統(tǒng)定義進行確認。

3.5需求管理

需求管理是一組用于幫助項目組在項目進展中的任何時候去標識、控制和跟蹤需求

的活動。

在需求管理中,每個需求被賦予唯一的標識符,一旦標識出需求,就可以為需求建

立跟蹤表,每個跟蹤表標識需求和其他需求或設(shè)計文檔、代碼、測試用例的不同版本間

的關(guān)系。

需求跟蹤有兩種方式:正向跟蹤以用戶需求為切入點,檢查《需求規(guī)約》中的每個

需求是否能在后繼工作中找到對應(yīng)點;逆向跟蹤檢查設(shè)計文檔、代碼、測試用例等工作

產(chǎn)品是否都能在《需求規(guī)約》中找到出處。

第四章

4.1軟件設(shè)計工程概述

軟件設(shè)計是把軟件需求變換成軟件表示的過程,主要包含兩個階段:軟件體系結(jié)構(gòu)

(概要)設(shè)計階段和部件級設(shè)計階段。

軟件體系結(jié)構(gòu)設(shè)計:將軟件需求轉(zhuǎn)化為數(shù)據(jù)結(jié)構(gòu)和軟件的系統(tǒng)結(jié)構(gòu)。

部件級設(shè)計:將軟件體系結(jié)構(gòu)中的結(jié)構(gòu)性元素轉(zhuǎn)化為軟件部件的過程性描述,得到

軟件詳細的數(shù)據(jù)結(jié)構(gòu)與算法。

4.1.1軟件設(shè)計的任務(wù)

軟件設(shè)計的輸入的軟件分析模型。使用一種設(shè)計方法,軟件分析模型中通過數(shù)據(jù)、

功能和行為模型所展示的軟件需求的信息被傳送給設(shè)計階段,產(chǎn)生數(shù)據(jù)/類設(shè)計、體系

結(jié)構(gòu)設(shè)計、接口設(shè)計、部件級設(shè)計。

①數(shù)據(jù)/類設(shè)計:將分析類模型變換成類的實現(xiàn)和軟件實現(xiàn)所需要的數(shù)據(jù)結(jié)構(gòu)。

②體系結(jié)構(gòu)設(shè)計:定義了軟件的整體結(jié)構(gòu),由軟件部件、外部可見的屬性和它們

之間的關(guān)系組成。

③接口設(shè)計:描述了軟件內(nèi)部、軟件和協(xié)作系統(tǒng)之間以及軟件同人之間的通信方

式。

主要包括3方面內(nèi)容:設(shè)計軟件模塊間的接口,設(shè)計模塊與其他非人的信息生

產(chǎn)者和消費者之間的外部接口以及設(shè)計人與計算機間的人機接口。

④部件級設(shè)計:將軟件體系結(jié)構(gòu)的結(jié)構(gòu)性元素變換為對軟件部件的過程性描述。

4.1.2軟件設(shè)計的目標

①設(shè)計必須實現(xiàn)分析模型中描述的所有顯式需求,必須滿足用戶希望的所有隱式

需求。

②設(shè)計必須是可讀,可理解的,使得將來易于編程、易于測試、易于維護。

③設(shè)計應(yīng)從實現(xiàn)角度出發(fā),給出與數(shù)據(jù)、功能、行為相關(guān)的軟件全貌。

設(shè)計出來的結(jié)構(gòu)應(yīng)是分層結(jié)構(gòu),從而建立軟件成分之間的控制。

③設(shè)計應(yīng)當模塊化,從邏輯上將軟件劃分為完成特定功能或子功能的部件。

④設(shè)計應(yīng)該既包含數(shù)據(jù)抽象,也包含過程抽象。

⑤設(shè)計應(yīng)當建立具有獨立功能特征的模塊。

⑥設(shè)計應(yīng)當建立能夠降低模塊與外部環(huán)境之間復(fù)雜連接的接口。

設(shè)計應(yīng)能根據(jù)軟件需求分析獲取的信息,建立可驅(qū)動、可重復(fù)的方法。

4.1.3軟件設(shè)計的過程

軟①件設(shè)計是一個把軟件需求編程軟件表示的過程,通常軟件設(shè)計過程分為6個步驟:

制定規(guī)范

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

④數(shù)據(jù)/類設(shè)計

⑤部件級(過程)設(shè)計

⑥編寫設(shè)計文檔

設(shè)計評審

4.2軟件設(shè)計原則

在將軟件的需求規(guī)約轉(zhuǎn)換為軟件設(shè)計的過程中,軟件的設(shè)計人員通常采用抽象與逐

步求精、模塊化和信息隱藏等原則。

4.2.1抽象與逐步求精

①抽象:將注意力集中在某一層次上考慮問題,忽略低層次的細節(jié)。軟件工程的

每一步都是對較高一級抽象的解作一次具體化的描述。

軟件設(shè)計的主要抽象手段有:

過程抽象:任何一個完成明確定義功能的操作都可被使用者當做單個實體看

待,盡管這個操作實際上是由一系列更低級的操作完成的(類似函數(shù)的概念

數(shù)據(jù)抽象:指定義數(shù)據(jù)類型和施加于該類型對象的操作,并限定了對象的取值

范圍,只能通過這些操作修改和觀察數(shù)據(jù)(類似類的概念。

②逐步求精:把問題的求解過程分解成若干步驟或階段,每一步都比上一步更精

化,更接近問題的解法。

抽象和逐步求精是一對互補的該你那,抽象使設(shè)計者能夠描述過程和數(shù)據(jù)而忽略底

層的細節(jié),而求精有助于設(shè)計者在設(shè)計過程中揭示底層的細節(jié)。

4.2.2模塊化

模塊化,即把軟件按照規(guī)定原則,劃分為一個個較小的,相互獨立的但又相互關(guān)聯(lián)

的部件。模塊化實際上是系統(tǒng)分解和抽象的過程。

在軟件工程中,模塊是數(shù)據(jù)說明、可執(zhí)行語句等程序?qū)ο蟮募?,是單獨命名的?/p>

并且是可以通過名字來訪問的。例如,對象類、構(gòu)件、過程、函數(shù)、子程序、宏等都可

以作為模塊。

模塊具有名字、參數(shù)、功能等外部特征以及完成模塊功能的程序代碼和模塊內(nèi)部數(shù)

據(jù)等內(nèi)部特征。

假設(shè)C(x)是描述問題x復(fù)雜性的函數(shù),E(x)是解決問題x所需工作量(按時間算)的

函數(shù),則有:

①若C(pl)>C(p2)則E(pl)>E(p2)

(2)C(pl+p2)>C(pl)+C(p2)

由①、②可推出

@E(pl+p2)>E(pl)+E(p2)

但雖然有③式存在,模塊劃分并非越多越好,因為還存在著將模塊聯(lián)接起來的工作

量。

4.2.3信息隱藏

每個模塊的實現(xiàn)細節(jié)對于其他模塊來說應(yīng)該是隱蔽的,即模塊中包含的信息(包括

數(shù)據(jù)和過程)不允許其他不需要這些信息的模塊使用。

4.2.4模塊獨立

所謂的模塊獨立指:模塊完成獨立的功能并且與其他模塊的接口簡單,符合信息隱

蔽,模塊間關(guān)聯(lián)和依賴程度盡可能小。模塊獨立性是模塊化、信息隱藏和局部化等概念

的直接結(jié)果。

模塊的獨立性很重要,體現(xiàn)在:

①功能被劃分,并且接口被簡化,所以具有有效模塊化的軟件更易于開發(fā)。

②由于因設(shè)計和編碼修改引起的副作用受到局限,錯誤傳播被減少,并且模塊復(fù)

用成為可能,所以獨立的模塊更易于測試和維護。

模塊的獨立性可以由兩項指標來衡量:內(nèi)聚度和耦合度。

內(nèi)聚度:衡量同一個模塊內(nèi)部的各個元素彼此結(jié)合的緊密程度。

耦合度:衡量不同模塊彼此間相互依賴的緊密程度。

4.2.4.1內(nèi)聚

一般模塊內(nèi)聚性分為7種類型,由低到高分別是:

①巧合內(nèi)聚:將幾個模塊中沒有明確表現(xiàn)出獨立功能的相同程序代碼段獨立

出來建立的模塊。

②邏輯內(nèi)聚:完成一組邏輯相關(guān)任務(wù)的模塊,調(diào)用該模塊時,由傳送給模塊

的控制型參數(shù)來確定該模塊應(yīng)執(zhí)行哪一和功能。

③時間內(nèi)聚:一個模塊中的所有任務(wù)必須在同一時間段內(nèi)執(zhí)行,例如初始化

模塊和終止模塊。

過程內(nèi)聚:一個模塊完成多個任務(wù),這些任務(wù)必須按指定的過程執(zhí)行。

⑥通信內(nèi)聚:--個模塊內(nèi)所有處理元素都集中在某個數(shù)據(jù)結(jié)構(gòu)的一塊區(qū)域中。

⑦順序內(nèi)聚:一個模塊完成多個功能,這些功能又必須順序執(zhí)行。

功能內(nèi)聚:一個模塊中各個部分都是為完成一項具體功能而協(xié)同工作,緊

密聯(lián)系,不可分割。

4.2.4.2耦合

一般模塊之間的可能的耦合方式有7種,由高到低分別是:

①內(nèi)容耦合:一個模塊直接訪問另一個模塊的內(nèi)部數(shù)據(jù);或一個模塊不通過

正常入口轉(zhuǎn)到另一模塊內(nèi)部;或兩個模塊有一部分代碼重疊;或一個模塊有多個入

口。

②公共耦合:一組模塊都訪問同一個公共數(shù)據(jù)環(huán)境。公共數(shù)據(jù)環(huán)境可以是全

局數(shù)據(jù)結(jié)構(gòu)、共享的通信區(qū)、內(nèi)存的公共覆蓋區(qū)等。

③外部耦合:模塊間通過軟件之外的環(huán)境聯(lián)結(jié)(如I/O將模塊耦合到特定的

設(shè)備、格式、通信協(xié)議上)時。

④控制耦合:?個模塊傳送給另一個模塊的參數(shù)中包含了控制信息,該控制

信息用于控制接受模塊中的執(zhí)行邏輯。

⑤標記耦合:兩個模塊之間通過參數(shù)表傳遞一個數(shù)據(jù)結(jié)構(gòu)的一部分(如某一

數(shù)據(jù)結(jié)構(gòu)的子結(jié)構(gòu))。

⑥數(shù)據(jù)耦合:兩個模塊之間僅通過參數(shù)表傳遞簡單數(shù)據(jù)。

⑦非直接耦合:兩個模塊之間沒有直接關(guān)系,即它們中的任何一個都不依賴

于另?個而能夠獨立工作。

強耦合->低內(nèi)聚

強內(nèi)聚。低耦合

耦合和內(nèi)聚都是模塊獨立性的定性標準,都反映了模塊獨立性的良好程度,但耦合

是直接的主導(dǎo)因素,內(nèi)聚則輔助耦合共同對模塊獨立性進行衡量。

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

4.3.2軟件體系結(jié)構(gòu)的風(fēng)格

一些軟件體系結(jié)構(gòu)風(fēng)格:

①數(shù)據(jù)為中心的體系結(jié)構(gòu):一些數(shù)據(jù)保存在整個結(jié)構(gòu)中心,并且被其他部件頻繁

地使用、添加、刪除、修改。

②數(shù)據(jù)流風(fēng)格的體系結(jié)構(gòu):適用于輸入數(shù)據(jù)被一系列的計算或者處理部件變換成

輸出數(shù)據(jù)。由管道和過濾器組成,過濾器之間由傳送數(shù)據(jù)的管道聯(lián)通。

③調(diào)用和返回風(fēng)格的體系結(jié)構(gòu):包含主程序/子程序風(fēng)格體系結(jié)構(gòu)和遠程過程調(diào)用

風(fēng)格的體系結(jié)構(gòu)。前者把功能分解成控制層次,頂層調(diào)用下層,下層調(diào)用下下層,最下

層完成最具體的功能;后者是前者的擴展,這種結(jié)構(gòu)中被主程序調(diào)用的部件分布在網(wǎng)絡(luò)

上不同的計算機中。

④面向?qū)ο箫L(fēng)格的體系結(jié)構(gòu)系統(tǒng)部件封裝數(shù)據(jù)和操作數(shù)據(jù)的方法,部件之間的交

互和協(xié)調(diào)通過消息來傳遞。

⑤層次式風(fēng)格的體系結(jié)構(gòu):圓環(huán)套圓環(huán),最外面層部件向用戶提供接口操作,最

內(nèi)層部件使用系統(tǒng)接口,每個中間層都是對內(nèi)層接口的封裝。

4.4部件級設(shè)計技術(shù)

在部件設(shè)計階段,主要完成如下工作:

①為每個部件確定采用的算法,選擇某種適當?shù)墓ぞ弑磉_算法的過程,編寫部件

的詳細過程性描述。

②確定每一部件內(nèi)部使用的數(shù)據(jù)結(jié)構(gòu)。

③在部件級設(shè)計結(jié)束時,應(yīng)該把上述結(jié)果寫入部件級設(shè)計說明書,并通過復(fù)審形

成正式文檔,作為下一階段(編碼階段)的工作依據(jù)。

4.4.1結(jié)構(gòu)化程序設(shè)計方法

如果一個程序的代碼塊僅僅通過順序、選擇和循環(huán)這3種基本控制結(jié)構(gòu)進行連接,

并且每個代碼塊只有一個入口和一個出口,則稱這個程序是結(jié)構(gòu)化的。

結(jié)構(gòu)化程序設(shè)計方法能提高程序的可讀性、可維護性和可驗證性,從而提高軟件的

生產(chǎn)率。

4.4.2圖形表示法

4.4.2.1程序流程圖

入口出口:圓角矩形

順序語句:矩形

條件分支:菱形

只允許5種基本控制結(jié)構(gòu):順序型,選擇型、先判定型循環(huán)、后判定型循

環(huán)、多情況選擇型,如下所示:

③先判定型循環(huán)④后判定型街好

(DOWHILE)<DO-INTIL)

4.4.2.2N-S圖

懶的畫了

、P1

二1=2??????=n

AlA2??????An

⑤多分支選擇型

s(CASE型)

DO-UNTILP

③WHILE重復(fù)型④UNTIL重復(fù)型

4.4.23PAD

PAD=problemanalysisdiagram

①順序型②選擇型

⑤多分支選擇型

③WHILE重復(fù)型④UNTIL重復(fù)型(CASE型)

4.4.3判定表

簡單而言就是列出所有條件可能組合以及對應(yīng)的操作。

1251891011121314

4.4.4設(shè)計性語言PDL

某種偽代碼,關(guān)鍵字一律大寫,其他單詞一律小寫。

PROCEDUREspellcheckIS查找錯拼的單詞

BEGIN

splitdocumentintosinglewords

把整個文檔分離成單詞

loodupwordsindictionary

在字典中查這些單詞

displaywordswhicharenotindictionary

顯示字典中查不到的單詞

createanewdictionary造一新字典

ENDspellcheck

P85課后題,第2,4,5,8題

以下問題答案不保證正確性

4.2軟件設(shè)計和軟件質(zhì)量的關(guān)系是怎么樣的

答:在進行軟件設(shè)計的過程中,我們要密切關(guān)注軟件的質(zhì)量因素。同時軟件質(zhì)量也很

大程度依賴于軟件設(shè)計。

4.4簡述模塊、模塊化及模塊化設(shè)計的概念

答:

模塊是數(shù)據(jù)說明、可執(zhí)行語句等程序?qū)ο蟮募?,它是單獨命名的,并且可以通過

名字來訪問。

模塊化,即把軟件按照規(guī)定原則,劃分為一個個較小的,相互獨立的但又相互關(guān)聯(lián)

的部件,實際上是系統(tǒng)分解和抽象的過程。

模塊化設(shè)計,即利用模塊化的思想進行軟件設(shè)計。

4.5舉例說明每種類型的模塊契合度和每種類型的模塊內(nèi)聚度,作業(yè)

4.8什么是模塊的獨立性?設(shè)計中為什么模塊要獨立?如何度量獨立性?模塊功能獨

立有何優(yōu)點?

答:

所謂的模塊獨立指:模塊完成獨立的功能并且與其他模塊的接口簡單,符合信息隱

蔽,模塊間關(guān)聯(lián)和依賴程度盡可能小。模塊獨立性是模塊化、信息隱藏和局部化等概念

的直接結(jié)果。

模塊的獨立性很重要,體現(xiàn)在:

①功能被劃分,并且接口被簡化,所以具有有效模塊化的軟件更易于開發(fā)。

②由于因設(shè)計和編碼修改引起的副作用受到局限,錯誤傳播被減少,并且模塊復(fù)

用成為可能,所以獨立的模塊更易于測試和維護。

模塊的獨立性可以由兩項指標來衡量:內(nèi)聚度和耦合度。

第五章結(jié)構(gòu)化分析與設(shè)計〃重點。

/*極度混亂,MMZ想到什么說什么,不保證全都記下了,因為有些說得很含糊*/

數(shù)據(jù)流的分析方法,數(shù)據(jù)字典,數(shù)據(jù)流圖,UML,UML視圖,面向?qū)ο蟮脑O(shè)計步驟

/*個人整理如下,實在太混亂,而且感覺他沒講全,僅供參考*/

5.1結(jié)構(gòu)化方法概述

一種面向數(shù)據(jù)流的傳統(tǒng)軟件開發(fā)方法

以數(shù)據(jù)流為中心構(gòu)建軟件的分析模型和設(shè)計模型

分為:

結(jié)構(gòu)化分析(StructuredAnalysis簡稱SA)

結(jié)構(gòu)化設(shè)計(StructuresdDesign簡稱SD)

結(jié)構(gòu)化程序設(shè)計(StructuredProgrammin簡稱SP)

5.1.1抽象和分解

抽象:在每個抽象層次上忽略問題的內(nèi)部復(fù)雜性,只關(guān)注整個問題與外界的聯(lián)

分解:將問題不斷分解為較小的問題,直到每個最底層的問題都足夠簡單為止

5.1.2結(jié)構(gòu)化分析過程

①理解當前的現(xiàn)實環(huán)境,獲得當前系統(tǒng)的具體模型(物理模型)

②從當前系統(tǒng)的具體模型抽象出當前系統(tǒng)的邏輯模型

③分析目標系統(tǒng)與當前系統(tǒng)邏輯上的差別,建立目標系統(tǒng)的邏輯模型

④為目標系統(tǒng)的邏輯模型作補充

5.1.3結(jié)構(gòu)化分析模型的描述

/畢

融/

狀態(tài)轉(zhuǎn)換圖

稔制規(guī)妁

5.2數(shù)據(jù)流圖(這貨毫無疑問的是重點啊

DataFlowDiagram(簡稱DFD):描述輸入數(shù)據(jù)流到輸出數(shù)據(jù)流的變換(即加工)過

程,用于對系統(tǒng)的功能建模。

5.2.1數(shù)據(jù)流圖的圖形表示

_A數(shù)據(jù)流(dataflow):由一組固定成分的數(shù)據(jù)組成,代表

數(shù)據(jù)的流動方向

C加工(process):描述了輸入數(shù)據(jù)流到輸出數(shù)據(jù)流的變

3換,即將輸入數(shù)據(jù)流加工成輸出數(shù)據(jù)流

—文件(file):使用文件'數(shù)據(jù)庫等保存某些數(shù)據(jù)結(jié)果供以

一后使用

I—I源或宿(sourceorsink):由一組固定成分的數(shù)據(jù)組成,

1■-1代表數(shù)據(jù)的流動方向

5.2.1.1數(shù)據(jù)流圖的基本圖形元素

①源或宿:存在于軟件系統(tǒng)之外的人員或組織,表示軟件系統(tǒng)輸入數(shù)據(jù)

的來源和輸出數(shù)據(jù)的去向,因此也稱為源點和終點

源或宿用相同的圖形符號表示

當數(shù)據(jù)流從該符號流出時表示是源

當數(shù)據(jù)流流向該符號時表示是宿

當兩者皆有時表示既是源又是宿

②加工:描述輸入數(shù)據(jù)流到輸出數(shù)據(jù)流的變換

每個加工用一個定義明確的名字標識

至少有一個輸入數(shù)據(jù)流和一個輸出流

可以有多個輸入數(shù)據(jù)流和多個輸出數(shù)據(jù)流

③文件:保存數(shù)據(jù)信息的外部單元

每個文件用一個定義明確的名字標識

由加工進行讀寫

DFD中稱為文件,但在具體實現(xiàn)時可以用文件系統(tǒng)實現(xiàn)也可以用數(shù)據(jù)

庫系統(tǒng)等實現(xiàn)

④數(shù)據(jù)流:每個數(shù)據(jù)流用由一組固定成分的數(shù)據(jù)組成并擁有一個定義明

確的名字標識

數(shù)據(jù)流的流向

從一個加工流向另一?個加工

從加工流向文件(寫文件)

從文件流向加工(讀文件)

從源流向加工

從加工流向宿

示例:圖書訂購系統(tǒng)DFD

5.2.1.2數(shù)據(jù)流圖中的擴充符號

描述一個加工的多個數(shù)據(jù)流之間的關(guān)系

①星號(*):表示數(shù)據(jù)流之間存在“與”關(guān)系

所有輸入數(shù)據(jù)流同時存在時,才能進行加工處理

或加工處理的結(jié)果是同時產(chǎn)生所有輸出數(shù)據(jù)流

②加號(+):表示數(shù)據(jù)流之間存在“或”關(guān)系

至少存在一個輸入數(shù)據(jù)流時才能進行加工處理

或加工處理的結(jié)果是至少產(chǎn)生一個輸出數(shù)據(jù)流

③異或(?):表示數(shù)據(jù)流之間存在“異或"(互斥)關(guān)系

必須存在且僅存在一個輸入數(shù)據(jù)流時,才能進行加工處理

或加工處理的結(jié)果是產(chǎn)生且僅產(chǎn)生一個輸出數(shù)據(jù)流

5.2.1.3數(shù)據(jù)流圖的層次結(jié)構(gòu)

頂層圖只有代表整個軟件系統(tǒng)的1個加工,描述了軟件系統(tǒng)與外界(源

或宿)之間的數(shù)據(jù)流

頂層圖中的加工經(jīng)分解后的圖稱為0層圖(只有1張)

中間層圖中至少有一個加工(也可以有多個)在下層圖中分解成一張子

處于最底層的圖稱為底層圖,其中所有的加工不再分解成新的子圖

頂層圖只有一個代表整個軟件系統(tǒng)的加工,該加工不必編號。

。層圖中的加工編號分別為1,2,3,-

子圖號:若父圖中的加工號x分解成某一子圖,則該子圖號記為“圖

X”

子圖中加工的編號:若父圖中的加工號為X的加工分解成某一子圖,

則該子圖中的加工編號分別為x.l、x.2、X.3-

小技巧:對于層次較多的DFD,較底層加工號可能很長,則可以在圖

中先標上圖號,然后其中的加工號則可寫作:.1,.2,.3

5.2.2分層數(shù)據(jù)流圖的畫法

這例子是某考務(wù)處理系統(tǒng)

①畫出系統(tǒng)的輸入和輸出

確定源或宿:考生、閱卷站和考試中心

它們都既是源又是宿

頂層圖唯一的加工:軟件系統(tǒng)(考務(wù)處理系統(tǒng))

確定數(shù)據(jù)流:系統(tǒng)的輸入/輸出信息

輸入數(shù)據(jù)流:報名單(來自考生)、成績清單(來自閱卷站)、合格標準卜來自考

試中心)

輸出數(shù)據(jù)流:準考證(送往考生)、考生名單(送往閱卷站)、考生通知書(送往

考生)、統(tǒng)計分析表(送往考試中心)

額外的輸出流(考慮系統(tǒng)的健壯性):不合格報名單(返回給考生),錯誤成績

清單(返回給閱卷站)

頂層圖通常沒有文件

于是得到了:

不合格報名單統(tǒng)計分析表,

考生考試中心

閱卷站

②畫出系統(tǒng)內(nèi)部

以下確定加工、數(shù)據(jù)流、文件、源或宿的一般方法適用于0層圖及其各層

子圖

確定加工:將父圖中某加工分解而成的子加工

根據(jù)功能分解來確定加工:將一個復(fù)雜的功能分解成若干個較小的功能,

較多應(yīng)用于高層DFD中的分解

根據(jù)業(yè)務(wù)處理流程確定加工:分析父圖中待分解加工的業(yè)務(wù)處理流程,業(yè)

務(wù)流程中的每一步都可能是一個子加工

特別要注意在業(yè)務(wù)流程中數(shù)據(jù)流發(fā)生變化或數(shù)據(jù)流的值發(fā)生變化的地方,

應(yīng)該存在?個加工,例如:

合格報名單正式報名單

1確定數(shù)據(jù)流

在父圖中某加工分解而成的子圖中,父圖中相應(yīng)加工的輸入/輸出數(shù)據(jù)流都

是且僅是子圖邊界上的輸入/輸出數(shù)據(jù)流

分解后的子加工之間應(yīng)增添相應(yīng)的新數(shù)據(jù)流表示加工過程中的中間數(shù)據(jù)

如果某些中間數(shù)據(jù)需要保存以備后用,那么可以成為流向文件的數(shù)據(jù)流

同一個源或加工可以有多個數(shù)據(jù)流流向一個加工,如果它們不是一起到達

和一起加工的,那么可以將它們分成若干個數(shù)據(jù)流。

2確定文件

如果父圖中該加工存在讀寫文件的數(shù)據(jù)流,則相應(yīng)的文件和數(shù)據(jù)流都應(yīng)畫

在子圖中

在分解子圖中,如果需要保存某些中間數(shù)據(jù)以備后用,則可以將這些數(shù)據(jù)

組成一個新的文件

新文件(首次出現(xiàn)的文件)至少應(yīng)有一個加工為其寫入記錄,同時至少存在

另一個加工來讀該文件的記錄

注意:從父圖中繼承下來的文件在子圖中可能只對其進行讀,或只進行寫

3確定源和宿

0層圖和其它子圖中通常不必畫出源和宿

有時為了提高可讀性,可以將頂層圖中的源和宿畫在0層圖中

4最終得到考務(wù)處理系統(tǒng)0層圖

不合格報名單考生通知單

2

報名單統(tǒng)計分析表

統(tǒng)計

考試成績

報名

準考證錯誤成績清單

名、成績清單

根據(jù)功能分解方法謖別出兩個加工:考試報名、統(tǒng)計成績

數(shù)據(jù)流

繼承頂層圖中的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流

定義二個加工之間的數(shù)據(jù)流:由于這二個加工分別在考試前后進行,因此

登記報名單所產(chǎn)生的結(jié)果“考生名冊”應(yīng)作為文件保存以便考試后由統(tǒng)計成績

加工引用

③畫出加工內(nèi)部

復(fù)雜的加工可以繼續(xù)分解成1張DFD子圖

分解方法

將該加工看作一個小系統(tǒng),該加工的輸入/輸出數(shù)據(jù)流就是這個假設(shè)的小系統(tǒng)的

輸入/輸出數(shù)據(jù)流

然后采用畫0層圖的方法,畫出該加工的子圖

④重復(fù)第3步,直至每個尚未分解的加工都足夠簡單(即不必再分解)

總結(jié):畫分層數(shù)據(jù)流圖的步驟

1.畫系統(tǒng)的輸入和輸出

2.畫系統(tǒng)內(nèi)部

3.畫加工內(nèi)部

4.重復(fù)第3步,直至每個尚未分解的加工都足夠簡單(即不必再分解)

5.4數(shù)據(jù)字典

數(shù)據(jù)流圖與數(shù)據(jù)字典是密不可分的,兩者結(jié)合起來構(gòu)成軟件的邏輯模型(分析模

型)

5.4.1字典條目的種類及描述符號

數(shù)據(jù)字典由字典條目組成,每個條目描述DFD中的一個元素

①字典條目的種類

數(shù)據(jù)字典條目包括:數(shù)據(jù)流、文件、數(shù)據(jù)項(組成數(shù)據(jù)流和文件的數(shù)據(jù))、

加工、源或宿

②數(shù)據(jù)字典使用的描述符號

符號名稱舉例

=定義為X=...表示X由…組成

4-與a+b表示a和b

...1或[a,bl表示a或b

或[a|bJ表示a或b

{...)重復(fù){a}表示a重復(fù)0或多次

n

{…}加重復(fù){a}:表示a重復(fù)3到8次

(...)(a)新重復(fù)0或1次

99,,基本數(shù)據(jù)元素表a是基本數(shù)據(jù)

5.4.2字典條目

不同的開發(fā)組織或團隊可以根據(jù)項目的需要定義字典條目的描述內(nèi)容

字典條目中的描述內(nèi)容主要包括

DFD元素的基本信息(名稱、別名、簡述、注解)

定義(數(shù)據(jù)類型、數(shù)據(jù)組成)

使用特點(取值范圍、使用頻率、激發(fā)條件)

控制信息(來源、去向、訪問權(quán)限)等

卜面的條目內(nèi)容太多,忽略。

D數(shù)據(jù)流條目

2)文件條目

3)數(shù)據(jù)項條目

④加工條目

⑤源或宿條目

⑥別名條目:為有必要補充說明的別名給出

5.4.3字典條目實例

培訓(xùn)報名單=姓名+單位+課程

運動員報名單=隊名+姓名+性別+{參賽項目}

5.4.4數(shù)據(jù)字典的實現(xiàn)

提倡采用專用的軟件工具或者常用的實用程序(如,正文編輯程序、電子表

格)來建立數(shù)據(jù)字典的電子文檔,其好處是便于字典條目的檢索,字典的管理和

維護。

如果數(shù)據(jù)字典由輔助繪制DFD的工具自動產(chǎn)生的話,那么可以利用數(shù)據(jù)字

典來檢查DFD的一致性和完整性,并保持數(shù)據(jù)字典與DFD的一致。

如果數(shù)據(jù)字典是由人工制作的,我們可以為每個字典條目制作一張卡片,

所有卡片按字典條目的種類(數(shù)據(jù)流、文件、加工等)分類成冊,每類卡片按某

種約定排序。

以下小節(jié)在提綱中未出現(xiàn),但有過作業(yè),所以也加進來了

5.7數(shù)據(jù)流圖到軟件體系結(jié)構(gòu)的映射

結(jié)構(gòu)化設(shè)計是將結(jié)構(gòu)化分析的結(jié)果(數(shù)據(jù)流圖)映射成軟件的體系結(jié)構(gòu)(結(jié)構(gòu)圖)

將數(shù)據(jù)流圖分為變換型數(shù)據(jù)流圖和事務(wù)型數(shù)據(jù)流圖,對應(yīng)的映射分別稱為變換

分析和事務(wù)分析

5.7.1信息流可分為變換流和事務(wù)流

①變換流

特征:數(shù)據(jù)流圖可明顯地分成輸入、變換、輸出三部分

信息沿著輸入路徑進入系統(tǒng),并將輸入信息的外部形式經(jīng)過編輯、格式轉(zhuǎn)

換、合法性檢查、預(yù)處理等輔助性加工后變成內(nèi)部形式

內(nèi)部形式的信息由變換中心進行處理

然后沿著輸出路徑經(jīng)過格式轉(zhuǎn)換、組成物理塊、緩沖處理等輔助性加工后

變成輸出信息送到系統(tǒng)外

②事務(wù)流

特征:數(shù)據(jù)流沿著輸入路徑到達一個事務(wù)中心,事務(wù)中心根據(jù)輸入數(shù)據(jù)的

類型在若干條動作路徑中選擇一條來執(zhí)行

事務(wù)中心的任務(wù)是:接收輸入數(shù)據(jù)(即事務(wù));分析每個事務(wù)的類型;根據(jù)

事務(wù)類型選擇執(zhí)行-?條動作路徑。

5.7.2數(shù)據(jù)流圖映射到結(jié)構(gòu)圖的步驟

①復(fù)審和精化數(shù)據(jù)流圖

②確定數(shù)據(jù)流圖的類型(變換型、事務(wù)型)

③將DFD映射成初始結(jié)構(gòu)圖:采用變換分析(5.7.3節(jié))或事務(wù)分析(574

節(jié))技術(shù)。

④改進初始結(jié)構(gòu)圖(5.8節(jié))

5.7.3變換分析

變換分析的任務(wù)是將變換型的DFD映射成初始的結(jié)構(gòu)圖,步驟如下:

劃定輸入流和輸出流的邊界,確定變換中心

進行第一級分解:將DFD映射成變換型的程序結(jié)構(gòu)

進行第二級分解:將DFD中的加工映射成結(jié)構(gòu)圖中的一個適當?shù)哪K

標注輸入輸出信息:根據(jù)DFD,在初始結(jié)構(gòu)圖上標注模塊之間傳遞的

主控模塊

輸入變換輸出

控制模塊控制模塊控制模塊

5.7.4事務(wù)分析

事務(wù)分析的任務(wù)是將事務(wù)型的DFD映射成初始的結(jié)構(gòu)圖,步驟如下:

確定事務(wù)中心:事務(wù)中心位于數(shù)條動作路徑的起點,這些動作路徑呈幅射

狀從該點流出

①將DFD映射成事務(wù)型的結(jié)構(gòu)圖

②分解每條動作路徑所對應(yīng)的結(jié)構(gòu)圖

③接收模塊的分解:從事務(wù)中心開始,沿著輸入路徑向外移動,把輸入

路徑上的每個加工映射成結(jié)構(gòu)圖中受接收模塊控制的一個低層模塊

④動作路徑控制模塊的分解:首先確定每條動作路徑的流類型(變換流或

事務(wù)流),然后,運用變換分析或事務(wù)分析,將每條動作路徑映射成與其流特性

相對應(yīng)的以動作路徑控制模塊為根模塊的結(jié)構(gòu)圖

5.8初始結(jié)構(gòu)圖的改進

>結(jié)構(gòu)圖改進技巧

減少模塊間的耦合度

③消除重復(fù)功能

④消除“管道”模塊

⑤模塊大小適中

⑥避免高扇出

應(yīng)盡可能研究整張結(jié)構(gòu)圖,而不是只考慮其中一部分。

第七章面向?qū)ο蟮姆治龊驮O(shè)計〃重點

7.2面向?qū)ο蟮姆治龊驮O(shè)計過程

7.2.1面向?qū)ο蠓治鲞^程(00A)

7.2.1.1面向?qū)ο蠓治龅娜蝿?wù)

目標是完成對所解問題的分析,確定待建的系統(tǒng)要做什么,并建立系統(tǒng)模

型。

7.2.1.2面向?qū)ο蠓治龅牟襟E

①獲取客戶對系統(tǒng)的需求,建造需求模型;

②用基本的需求為指南來選擇類和對象(包括屬性和操作)

③定義類的結(jié)構(gòu)和層次

④建造對象-行為模型

⑤利用用況/場景來復(fù)審分析模型

7.2.2面向?qū)ο笤O(shè)計過程(00D)

00D是將00A所創(chuàng)建的分析模型轉(zhuǎn)化為設(shè)計模型。

與傳統(tǒng)方法不同QOD和00A沒有明確的分界線,往往反復(fù)迭代進行。00A主

要考慮系統(tǒng)做什么,00D則考慮系統(tǒng)怎么做,因此需要在00A的模型上增加一些

類或者在原有類中補充一些屬性和操作。

00D同樣應(yīng)該遵循抽象、信息隱蔽、功能獨立、模塊化等設(shè)計原則。

7.2.2.100D的一般步驟

①系統(tǒng)設(shè)計

②對象設(shè)計

③消息設(shè)計

④復(fù)審

內(nèi)容各種多..有興趣自行P155~157

7.2.3設(shè)計模式

在許多面向?qū)ο笙到y(tǒng)中,存在一些類和通信對象重復(fù)出現(xiàn)的模式。這些模式求

解特定的設(shè)計問題,使面向?qū)ο笤O(shè)計更靈活,并最終可復(fù)用。

?個設(shè)計模式通??捎?個信息來描述

①模式名

②模式的環(huán)境和條件

③設(shè)計模式的特征

④應(yīng)用設(shè)計模式的結(jié)果

7.3UML概述

用于對軟件密集型系統(tǒng)的制品進行可視化、祥述、構(gòu)造和文檔化的圖形語言,

是一種描繪系統(tǒng)藍圖的標準方法。

PPT和課本的UML視圖和圖的分類不同..統(tǒng)?建模語言不統(tǒng)了怎么辦!

這里以PPT為準,因為懶得打字。

圖形化的表示機制,十多種視圖,分4類:

用例圖:用戶角度:功能、執(zhí)行者

靜態(tài)圖:系統(tǒng)靜態(tài)結(jié)構(gòu)

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論