軟件工程復(fù)習(xí)提綱

第1章軟件工程簡(jiǎn)介..........................................................3

軟件是什么...............................................................3

第2章過(guò)程綜述..........................................................4

軟件工程定義.............................................................4

層次化...................................................................4

通用過(guò)程框架.............................................................4

第3章過(guò)程模型..............................................................6

多種過(guò)程模型.............................................................6

第4章敏捷視角下的過(guò)程......................................................8

敏捷宣言.................................................................8

第5章系統(tǒng)工程.............................................................10

第6章需求工程.............................................................11

質(zhì)量功能布署(QFD)........................................................11

分析模型的元素..........................................................14

第7章構(gòu)建分析模型.........................................................14

第8章設(shè)計(jì)工程.............................................................15

第9章進(jìn)行體系構(gòu)造設(shè)計(jì).....................................................16

體系構(gòu)造風(fēng)格的分類......................................................16

第1()章構(gòu)件級(jí)設(shè)計(jì)建模......................................................17

第11章完畢顧客界面設(shè)計(jì)....................................................17

黃金規(guī)則.................................................................17

第12章軟件測(cè)試方略........................................................18

軟件測(cè)試需要計(jì)劃和執(zhí)行一系列日勺測(cè)試環(huán)節(jié).................................18

第13章測(cè)試技術(shù)............................................................19

兩個(gè)不同樣日勺測(cè)試用例設(shè)計(jì)技術(shù)............................................19

第14章產(chǎn)品度量............................................................20

第1章軟件工程筒介

軟件是什么

軟件是形成配置的一組術(shù)語(yǔ)或?qū)ο螅ǎ?/p>

程序(計(jì)算機(jī)程序)：指令的集合,通過(guò)執(zhí)行這些指令可以滿足預(yù)期的特性、功能和性能需求

數(shù)據(jù)構(gòu)造:它使得程序可以充足運(yùn)用信息

文檔:描述程序操作和使用的文檔(圖文資料)

1.舉例闡明“意外效應(yīng)法則”(lawofunintendedconsequences)在計(jì)算機(jī)軟件方面的I

應(yīng)用。

某些新科技的發(fā)明發(fā)明會(huì)給其他某些看似無(wú)關(guān)的技術(shù)領(lǐng)域、商業(yè)企業(yè)、公眾甚至整個(gè)

社會(huì)文化帶來(lái)深遠(yuǎn)而出人意料的影響和作用。

如：

2.用自己的語(yǔ)言描述保證通曉規(guī)律(TheLawofConservationofFamiliarity)、質(zhì)量衰

減規(guī)律(TheLawofDecliningQuality)以及組織穩(wěn)定性守恒規(guī)律(TheLawof

ConservationofOrganizationalStability)。

保證通曉性規(guī)律(1980):伴隨E類型系統(tǒng)的演化，所有有關(guān)人員(如開(kāi)發(fā)人員、銷售

人員和顧客)都必須清晰地理解演化的內(nèi)容和過(guò)程，以便抵達(dá)滿意的演化效果。

質(zhì)量衰減規(guī)律(1996):假如沒(méi)有嚴(yán)格的維護(hù)和適應(yīng)性調(diào)整使之適應(yīng)運(yùn)行環(huán)境的變化，

E類型系統(tǒng)口勺質(zhì)量有衰減的趨勢(shì)。

組織穩(wěn)定性守恒規(guī)律(1980):一種不停演化的E類型系統(tǒng)，其組織在全球范圍內(nèi)的

平均有效活動(dòng)率在產(chǎn)品的生命周期中是保持不變的。

3.在交付最終顧客之前，或者第1個(gè)版本投入使用之后，許多應(yīng)用程序都會(huì)有頻繁的

變更。為防止變更引起軟件失效，請(qǐng)?zhí)岢瞿承┯行У奶幚泶胧?/p>

首先從心態(tài)上承認(rèn)變化是必然的，我們可以通過(guò)在軟件公布之前進(jìn)行alpha,beta測(cè)

試，運(yùn)用迭代模式，在吸取測(cè)試過(guò)程中的經(jīng)驗(yàn)之后，立即改善軟件。

同步保持和顧客日勺良好溝通，在提交顧客時(shí)進(jìn)行合適培訓(xùn)，讓顧客按照開(kāi)發(fā)思緒進(jìn)行

試用，可以見(jiàn)減少因使用措施不妥引起的變化。

第2章過(guò)程綜述

軟件工程定義

軟件工程是：

（1）將系統(tǒng)化、規(guī)范日勺、可量化的措施應(yīng)用于軟件日勺開(kāi)發(fā)、運(yùn)行和維護(hù)，即將工程化措施應(yīng)

用于軟件。

（2）在（1）中所述日勺措施的研究。

層次化

工具

方法

過(guò)程模型

質(zhì)玨關(guān)注點(diǎn)

軟件工程層次圖

通用過(guò)程框架

1.溝通(Communication)

2.籌劃(Planning)

3.建模(Modeling)

a)需求分析(Analysisoflequirements)

h)設(shè)計(jì)(Design)

4.構(gòu)建(Construction)

a)代碼生成(Codegeneration)

b)測(cè)試(Testing)

5.布署(Deployment)

重點(diǎn)：

1.Baetjer說(shuō)過(guò)“軟件過(guò)程為顧客和設(shè)計(jì)者之間、顧客和開(kāi)發(fā)工具之間以及設(shè)計(jì)者和開(kāi)

發(fā)工具之間提供交互的途徑［技術(shù)］。”設(shè)計(jì)下面問(wèn)題“⑴設(shè)計(jì)者應(yīng)當(dāng)問(wèn)顧客歐I;⑵

顧客應(yīng)當(dāng)問(wèn)設(shè)計(jì)者日勺；⑶顧客對(duì)將要構(gòu)建的軟件日勺自問(wèn)；⑷設(shè)計(jì)者對(duì)于軟件產(chǎn)

品和建造該產(chǎn)品采用的軟件過(guò)程時(shí)自問(wèn)。(怎樣獲取需求)

2.為溝通活動(dòng)設(shè)計(jì)一種任務(wù)集

1.識(shí)別重要客戶和其他共利益者

2.與客戶會(huì)談環(huán)境無(wú)關(guān)的話題

3.寫一頁(yè)項(xiàng)目范圍

4.評(píng)審范圍闡明

5.討論項(xiàng)目大體的階段

6.約定各個(gè)部門的代表，并使他們互相認(rèn)識(shí)

7.為計(jì)劃活動(dòng)做準(zhǔn)備

3.用自己H勺話描述過(guò)程框架。當(dāng)我們談到框架活動(dòng)合用于所有日勺項(xiàng)目時(shí)，與否意味著

對(duì)于不同樣規(guī)模和復(fù)雜度的I項(xiàng)目，可應(yīng)用相似的工作任務(wù)？請(qǐng)解釋。

過(guò)程框架定義了若干小時(shí)框架活動(dòng)，為完整日勺軟件開(kāi)發(fā)過(guò)程建立的基礎(chǔ)，這些框架活

動(dòng)可以廣泛用于所有的軟件開(kāi)發(fā)項(xiàng)目，無(wú)論這些項(xiàng)目日勺復(fù)雜性和規(guī)模怎樣，此外，還包括

某些合用于各個(gè)軟件過(guò)程的普適性活動(dòng)。

雖然過(guò)程框架是普適性的，不過(guò)對(duì)于不同樣規(guī)模和復(fù)雜度日勺項(xiàng)目不能應(yīng)用相似日勺工作

任務(wù)。

首先在軟件開(kāi)發(fā)日勺不同樣階段，工作任務(wù)不同樣。另首先不同樣的軟件項(xiàng)目有不同樣

日勺需求，有特殊日勺背景，找不到一種通用的工作任務(wù)。

4.圖2-1中，基于“質(zhì)量關(guān)注點(diǎn)”指明了軟件工程三個(gè)層次。這意味著在整個(gè)開(kāi)發(fā)組織

內(nèi)采用質(zhì)量管理活動(dòng)，如“全面質(zhì)量管理”。仔細(xì)研究，并列出全面質(zhì)量管理活動(dòng)

中關(guān)鍵原則的大綱。

第3章過(guò)程模型

多種過(guò)程模型

通例軟件過(guò)程模型

力圖給軟件開(kāi)發(fā)帶來(lái)秩序和構(gòu)造。盡管每一老式過(guò)程模型都提議了一種不同樣口勺過(guò)程流，但

均實(shí)現(xiàn)了同樣的一組通用框架活動(dòng)：溝通、計(jì)劃、建模、構(gòu)建利布署。

瀑布模型

提議線性流程的框架活動(dòng)，與軟件世界里現(xiàn)代軟件開(kāi)發(fā)實(shí)際（持續(xù)的變更、演化的系統(tǒng)、緊

迫的開(kāi)發(fā)時(shí)間）不符；但瀑布模型確實(shí)合用于需求定義清晰且穩(wěn)定的軟件開(kāi)發(fā)；

增量軟件過(guò)程模型

通過(guò)一系列的增量公布產(chǎn)生軟件。

RAD模型

迅速應(yīng)用程序開(kāi)發(fā)，是為大型且必須在嚴(yán)格的時(shí)間內(nèi)提交口勺項(xiàng)目而設(shè)計(jì)的；

演化過(guò)程模型

認(rèn)識(shí)到大多數(shù)軟件工程項(xiàng)目的送代特性，其設(shè)計(jì)的目日勺是為了適應(yīng)變更演化模型（如原型模

型、螺旋模型），其迅速產(chǎn)生增量的工作產(chǎn)品（或是軟件日勺工作版本），這些模型可以應(yīng)用

于所有的軟件工程活動(dòng)一一從概念開(kāi)發(fā)到長(zhǎng)期日勺軟件維護(hù)。

基于構(gòu)建的模型

強(qiáng)調(diào)構(gòu)件復(fù)用及組裝。

形式化措施模型

倡導(dǎo)采用數(shù)學(xué)日勺措施進(jìn)行軟件開(kāi)發(fā)和驗(yàn)證。

面向方面的模型

目的I是處理跨整個(gè)軟件體系構(gòu)造的橫切關(guān)注點(diǎn)；

統(tǒng)一過(guò)程模型

是一種“用例驅(qū)動(dòng)、以體系構(gòu)造為關(guān)鍵、迭代及增量”的軟件過(guò)程框架，由UML措施和工

具支持。統(tǒng)一過(guò)程是一種增量模型，定義了五個(gè)階段：

起始階段：包括顧客溝通和計(jì)劃活動(dòng)兩個(gè)方面，強(qiáng)調(diào)定義和細(xì)化用例，并將其作為重要模型;

細(xì)化階段：包括顧客溝通和建模活動(dòng)，重點(diǎn)是創(chuàng)立分析和設(shè)計(jì)模型，強(qiáng)調(diào)類的定義和體系構(gòu)

造的體現(xiàn)；

構(gòu)建階段：細(xì)化設(shè)計(jì)模型，并將設(shè)計(jì)模型轉(zhuǎn)化為軟件構(gòu)建實(shí)現(xiàn)；

轉(zhuǎn)化階段：將軟件從開(kāi)發(fā)人員傳遞給最終顧客，并由顧客完畢Beta測(cè)試和驗(yàn)收測(cè)試；

生產(chǎn)階段：持續(xù)地監(jiān)捽軟件叼運(yùn)行,并提供技術(shù)支持.

重點(diǎn)：

1.開(kāi)發(fā)質(zhì)量“足夠好”的軟件，其長(zhǎng)處和缺陷是什么？當(dāng)我們追求開(kāi)發(fā)速度勝過(guò)產(chǎn)品

質(zhì)量的時(shí)候，會(huì)產(chǎn)生什么后果？

我們總在質(zhì)量和開(kāi)發(fā)速度之間做取舍，開(kāi)發(fā)質(zhì)量“足夠好”的軟件，明顯弼調(diào)質(zhì)量，

長(zhǎng)處是使軟件符合或超過(guò)客戶的預(yù)期，在性能上，交互上力圖做到盡善盡美。缺陷是忽視

了開(kāi)發(fā)成本，很輕易導(dǎo)致開(kāi)發(fā)時(shí)間延期，影響軟件工程后幾種階段日勺工作，對(duì)全局導(dǎo)致不

利影響。

2.當(dāng)沿著螺旋過(guò)程流發(fā)展日勺時(shí)候，你對(duì)正在開(kāi)發(fā)或者維護(hù)日勺軟件的見(jiàn)解是什么？

在螺旋模式下，開(kāi)發(fā)過(guò)程是迭代式日勺，采用循環(huán)的方式逐漸加深系統(tǒng)定義和實(shí)現(xiàn)的深

度，同步減少風(fēng)險(xiǎn)。

當(dāng)軟件交付使用后，螺旋模式?jīng)]有停止，它將永遠(yuǎn)保持可操作性，每一圈完畢后都會(huì)

計(jì)算成本，可以更好日勺維護(hù)軟件。

3.可以合用幾種過(guò)程模型嗎？假如可以，舉例闡明。

可以。

幾種過(guò)程模型，都是互相兼容可以互相擴(kuò)展日勺，如螺旋模型結(jié)合了原型H勺迭代性質(zhì)和

瀑模型日勺系統(tǒng)性和可控性的特點(diǎn)。

在詳細(xì)項(xiàng)目實(shí)行中，對(duì)于某一部分用以合用幾科過(guò)程模型，例如形式語(yǔ)言與自動(dòng)機(jī)演

示軟件在算法開(kāi)發(fā)過(guò)程，就需要使用形式化措施模型，用嚴(yán)格歐I數(shù)學(xué)符號(hào)定義形式語(yǔ)言和

自動(dòng)機(jī)。

尚有某些桌面應(yīng)用程序日勺前臺(tái)UI部分，可以單獨(dú)使用RAD模型，例如用delphi語(yǔ)言

開(kāi)發(fā)桌面窗體就是一種RAD實(shí)現(xiàn).而其他部分可以使用其他如瀑布式模型等措施.

第4章敏捷視角下的過(guò)程

敏捷宣言

?個(gè)體和交互勝過(guò)過(guò)程和工具(Individualsandinteractionsoverprocessesandtools)

?可工作軟件勝過(guò)寬泛『、J文檔(Workingsoftwareovercomprehensivedocumentation)

?客戶合作勝過(guò)協(xié)議談判(Customercollaborationovercontractnegotiation)

?響應(yīng)變化勝過(guò)遵照計(jì)劃(Respondingtochangeoverfollowingaplan)

重點(diǎn)：

1.與否每一種敏捷過(guò)程都可以用第2章所提及日勺通用框架性活動(dòng)來(lái)描述？建一張表，

將通用活動(dòng)和每個(gè)敏捷過(guò)程所定義日勺活動(dòng)對(duì)應(yīng)起來(lái)。

2.用自己日勺語(yǔ)言描述(用于軟件項(xiàng)目日勺)敏捷性？

普遍存在的變化是敏捷的基本動(dòng)力，敏捷需要有效的響應(yīng)變化，它鼓勵(lì)在共利益者之

間進(jìn)行更便利的溝通和協(xié)作，強(qiáng)調(diào)可運(yùn)行軟件時(shí)迅速交付。

敏捷容許項(xiàng)目團(tuán)體調(diào)整并合理安排任務(wù)，理解易變性并制定計(jì)劃。精簡(jiǎn)并維持最基本

日勺工作產(chǎn)品，強(qiáng)調(diào)增量交付，迅速提供可運(yùn)行軟件。

3.許多敏捷過(guò)程模型推薦面對(duì)面交流，實(shí)際上，目前軟件開(kāi)發(fā)團(tuán)體組員及其客戶在地

理上是分散的。你與否認(rèn)為這意味著這種地理上的分散應(yīng)當(dāng)防止？能否想出一種措

施克服這個(gè)問(wèn)題。

我認(rèn)為這種地理上的分散是現(xiàn)實(shí)，是無(wú)法防止的。我認(rèn)為可以分為客戶和開(kāi)發(fā)人員日勺

分散，開(kāi)發(fā)人員內(nèi)部分散兩種狀況。

對(duì)于第一種：產(chǎn)品經(jīng)理需要同客戶建立一條良好日勺通信信道，如通過(guò)email,即時(shí)聊天

工具進(jìn)行定期溝通。

對(duì)于第二種：開(kāi)發(fā)人員需定期組織交流，通過(guò)webgroup消除地理上的分散。

4.為何需求變化這樣大，人們究竟無(wú)法確定他們想要什么嗎？

我認(rèn)為是這樣的。

其實(shí)需求是客戶對(duì)他們心目中軟件的一種描述，由于軟件還沒(méi)有實(shí)現(xiàn)，這種描述便是

不確定日勺，模糊日勺。同步當(dāng)今世界處在高速變化之中，人們H勺需求會(huì)伴隨環(huán)境的變化而變

化。

因此敏捷開(kāi)發(fā)承認(rèn)變化，認(rèn)為普遍存在的變化是敏捷日勺基本動(dòng)力。

第5章系統(tǒng)工程

在寫下每行代碼之前

?理解所要處理的問(wèn)題（詳見(jiàn)溝通與建模）

?理解基本的設(shè)計(jì)原則和概念

?選擇一種可以滿足軟件構(gòu)建以及運(yùn)行環(huán)境規(guī)定的編程語(yǔ)言

?選擇一種能提供工具以簡(jiǎn)化工作日勺編程環(huán)境

?構(gòu)件級(jí)編碼完畢后進(jìn)行單元測(cè)試

系統(tǒng)工程層次圖

重點(diǎn)：

1.對(duì)你熟悉的系統(tǒng)、產(chǎn)品或服務(wù)，建立它們的層次系統(tǒng)。層次應(yīng)當(dāng)向下擴(kuò)展到簡(jiǎn)樸系

統(tǒng)要素（硬件、軟件等），至少得到層次樹(shù)H勺一種分支。

即時(shí)聊天系統(tǒng)

2.系統(tǒng)工程師由3種來(lái)源：系統(tǒng)開(kāi)發(fā)人員、顧客或某些外部組織。討論一下每種來(lái)源

的利與弊。描述一種理想的系統(tǒng)工程師。

3.研究文獻(xiàn)并寫出一篇簡(jiǎn)短文章描述建模和模擬工具是怎樣工作的I。或者是搜集兩個(gè)

或更多日勺商用建模或模擬工具的文獻(xiàn)，并且比較它們的相似處與不同樣處。

第6章需求工程

質(zhì)量功能布署（QFD）

是一種將客戶規(guī)定轉(zhuǎn)化成軟件技術(shù)需求的技術(shù)。QFD“目日勺是最大程度地讓客戶從軟件工程

過(guò)程中感到滿意"，并強(qiáng)調(diào)"什么是對(duì)客戶有價(jià)值日勺”。確認(rèn)三類需求：

?正常需求：反應(yīng)了在和客戶開(kāi)會(huì)時(shí)確定歐I針對(duì)某產(chǎn)品或系統(tǒng)的目日勺。假如實(shí)現(xiàn)了這些需

求，將滿足客戶（例如：所規(guī)定日勺圖形顯示類型、特定的I系統(tǒng)功能以及己定義的性能級(jí)

別）。

?期望需求：隱含在產(chǎn)品或系統(tǒng)中，并且也許是非常基礎(chǔ)的以至于客戶沒(méi)有顯式地闡明，

但缺乏這些將導(dǎo)致客戶明顯不滿（例如：易交互性、可操作性、可靠性、易安裝等）。

?令人興奮的需求：反應(yīng)了客戶期望之外的特點(diǎn)，但假如實(shí)現(xiàn)了這些特點(diǎn)，將會(huì)使客戶非

常滿意。

重點(diǎn)：

1.為如下活動(dòng)之一開(kāi)發(fā)一種完整的用例：

＞在ATM提款；

＞在餐廳使用信用卡付費(fèi);

＞使用一種在線經(jīng)紀(jì)人賬戶購(gòu)置股票:

＞使用在線書店搜索書（某個(gè)指定主題）；

ATM用例圖

“ATM取款”用例規(guī)約

用例名稱：ATM取款

簡(jiǎn)述：客戶持銀行卡（本行或其他行）從ATM提取現(xiàn)金

actors:客戶和銀行主機(jī)

基本流：1.客戶插入銀行卡。

2.ATM從銀行卡讀入卡號(hào)（含銀行標(biāo)識(shí)和賬號(hào)），驗(yàn)證卡

的有效性。

3.客戶輸入密碼。

4.ATM驗(yàn)證帳號(hào)和密碼。

5.ATM顯示包括取款在內(nèi)的服務(wù)功能，客戶選擇“取款”。

6.輸入取款額：客戶輸入數(shù)量為50元的倍數(shù)的取款額。

7.ATM向銀行主機(jī)告知卡號(hào)、密碼、賬號(hào)和取款額，獲得

具有最新余額的取款成功確認(rèn)信息。

8.ATM打印并吐出憑條。

9.ATM清點(diǎn)并吐出現(xiàn)金，記錄取款成功。

10.ATM問(wèn)詢客戶與否繼續(xù)服務(wù)。

11.客戶選擇否，ATM吐出銀行卡，結(jié)束用例，否則回到環(huán)

節(jié)5。

［用例結(jié)束］

備選流：3-7,10a.客戶取消服務(wù):

ATM記錄服務(wù)取消，打印憑條，吐出憑條和銀行卡，［用

例失敗］

3,6,11a.客戶未及時(shí)輸入超過(guò)30秒：

ATM吞卡，［用例失敗］

2a.K無(wú)效：

ATM吞卡，［用例失敗］

2b.讀卡器或卡被損壞：

ATM吞卡，［用例失敗］

4a.密碼錯(cuò):

4al.客戶重新輸入密碼

a.合計(jì)3次密碼錯(cuò)誤：

ATM吞卡，［用例失敗］

4b.無(wú)此帳號(hào)：

ATM吞卡，［用例失敗1

5a.ATM無(wú)現(xiàn)金：

ATM不顯示“取款”功能，客戶可選擇其他服務(wù)，［用

例失敗1

6a.取款額超過(guò)ATM現(xiàn)金余額；

ATM規(guī)定客戶重新輸入取款額。

7a.帳戶余額局限性：

ATM規(guī)定客戶重新輸入取款額。

7b.取款額超過(guò)當(dāng)日最高限額：

ATM規(guī)定客戶重新輸入取款額。

7c.網(wǎng)絡(luò)或銀行主機(jī)失效、通訊超時(shí)：

ATM記錄服務(wù)取消，打印憑條，吐出憑條和銀行卡，［用

例失敗］

8a.憑條打印失敗，紙用完或卡紙：

8al.ATM告知銀行主機(jī)取消取款

8a2.ATM記錄服務(wù)取消，吐出銀行卡，［用例失敗］

9a.吐現(xiàn)金失敗：

9al.ATM告知銀行主機(jī)取消取款

9a2.ATM記錄服務(wù)取消，吐出銀行卡，［用例失敗］

11a.客戶未及時(shí)取走卡：

ATM吞卡，［用例失敗］

業(yè)務(wù)規(guī)則：7b單日取款不得超過(guò)5000元

6c每次取款不得超過(guò)2023元

2.為何大量的軟件開(kāi)發(fā)人員沒(méi)有足夠重視需求工程？此前有無(wú)什么狀況讓你可以跳過(guò)

需求工程？

首先軟件開(kāi)發(fā)人員認(rèn)為客戶已經(jīng)把需求說(shuō)清晰了，不過(guò)大多數(shù)狀況初步H勺需求都是模

糊跖

另首先工程日勺進(jìn)度規(guī)定很緊迫，軟件開(kāi)發(fā)人員迫切但愿投入到代碼編寫階段。

最終和客戶溝通比較困難，使得大多數(shù)軟件開(kāi)發(fā)人員不重視需求工程。

又一次，項(xiàng)目時(shí)間很短，規(guī)定一種月完畢，我們只是大體上對(duì)需求有一種認(rèn)識(shí)，就跳

過(guò)需求工程開(kāi)始動(dòng)手編碼，成果當(dāng)然失敗了。

3.簡(jiǎn)短地討論一種分析模型的每個(gè)元素，指出每個(gè)元素對(duì)模型日勺奉獻(xiàn)，每個(gè)元素為何

是唯一日勺以及每個(gè)元素所示日勺概要信息。

分析模型的元素

基于場(chǎng)景的元素（用例圖）：使用基丁場(chǎng)景日勺措施可以從顧客的視角描述系統(tǒng)。例如基本日勺

用例和基于模板日勺用例。一般的分析模型的第一步，作為創(chuàng)立其他模型歐I輸入。

基于類的元素（類圖）：每個(gè)使用場(chǎng)景都暗示著當(dāng)一種參與者與系統(tǒng)交互時(shí)所操做的I一組

對(duì)象，這些對(duì)象被提成類一一具有相似屬性和共同行為的I事務(wù)集合。

行為元素（狀態(tài)圖）：狀態(tài)指明了在某個(gè)特殊事件后采用什么動(dòng)作。

面向信息流的模式：描述信息的轉(zhuǎn)換。

第7章構(gòu)建分析模型

重點(diǎn):

1.簡(jiǎn)樸用幾句話嘗試闡明構(gòu)造化分析和面向?qū)ο蠓治龅闹匾町悾?/p>

構(gòu)造化分析考慮數(shù)據(jù)和處理，其中數(shù)據(jù)作為獨(dú)立的實(shí)體轉(zhuǎn)換，數(shù)據(jù)對(duì)象建模定義了對(duì)

象歐I屬性和關(guān)系，操作對(duì)象的處理建模應(yīng)當(dāng)表明數(shù)據(jù)對(duì)象在系統(tǒng)內(nèi)流動(dòng)時(shí)處理怎樣轉(zhuǎn)換數(shù)

據(jù)。

面向?qū)ο蠓治鲫P(guān)注于定義類和影響客戶需求日勺類之間日勺協(xié)作方式。

2.有無(wú)也許在分析模型創(chuàng)立后立即開(kāi)始編碼？解釋你日勺答案，然后說(shuō)服反方。

第8章設(shè)計(jì)工程

從分析根空到設(shè)計(jì)鎮(zhèn)名的找化

重點(diǎn):

1.假如軟件設(shè)計(jì)不是程序（它確定不是），那么它是什么？

是一套結(jié)實(shí)、合用和賞心悅目的模型或設(shè)計(jì)體現(xiàn)。它包括數(shù)據(jù)、類設(shè)計(jì)，體系構(gòu)造設(shè)計(jì)、

接口設(shè)計(jì)、構(gòu)件設(shè)計(jì)。

2.當(dāng)你“編寫”程序時(shí)你設(shè)計(jì)軟件嗎？軟件設(shè)計(jì)和編碼有什么不同樣嗎？

設(shè)計(jì)。

軟件設(shè)計(jì)是逐漸細(xì)化一種可以工作的模型，而編碼是在牛成一種可執(zhí)行的程序。軟件設(shè)計(jì)

重要關(guān)注與否實(shí)現(xiàn)了顧客需求，必須從實(shí)現(xiàn)的角度闡明數(shù)據(jù)域、功能域和行為域，是編碼

工作的指導(dǎo)。

3.用你自己的話闡明軟件體系構(gòu)造。

系統(tǒng)構(gòu)造是程序構(gòu)件（模塊）日勺構(gòu)造或組織，這些構(gòu)件交互日勺形式以及這些構(gòu)件因此數(shù)據(jù)

日勺構(gòu)造。構(gòu)件可以被推廣，用于代表重要的系統(tǒng)元素及其交互。

第9章進(jìn)行體系構(gòu)造設(shè)計(jì)

體系構(gòu)造風(fēng)格的分類

以數(shù)據(jù)為中心日勺體系構(gòu)造

數(shù)據(jù)流體系構(gòu)造：

當(dāng)輸入數(shù)據(jù)通過(guò)一系列的計(jì)算和操作構(gòu)件日勺變換形成輸出數(shù)據(jù)時(shí)，可以應(yīng)用這種體系構(gòu)

造。

信息流被描述為單個(gè)數(shù)據(jù)項(xiàng)，被稱為事務(wù)，他可以沿多條途徑中日勺一條觸發(fā)其他數(shù)據(jù)流。

調(diào)用和返回體系構(gòu)造

面向?qū)ο篌w系構(gòu)造

層次體系構(gòu)造

重點(diǎn)：

1.使用數(shù)據(jù)流程圖和處理論述，描述一種具有明顯數(shù)據(jù)流特性和一種具有明顯事務(wù)流

特性的I計(jì)算機(jī)系統(tǒng)。

數(shù)據(jù)流特性：opengl管線

事務(wù)流特性：銀行轉(zhuǎn)賬

以房子或建筑H勺體系構(gòu)造作比方，與軟件體系構(gòu)造進(jìn)行對(duì)比。老式H勺建筑體系構(gòu)造學(xué)科和軟

件體系構(gòu)造有何相似之處？有何不同樣之處？

第10章構(gòu)件級(jí)設(shè)計(jì)建模

構(gòu)件：系統(tǒng)中某一定型化日勺、可配置日勺和可替代的部件，該部件封裝并暴露了某些列接口。

內(nèi)聚性：內(nèi)聚性cohesion意味著構(gòu)件或者類只封裝那些互有關(guān)聯(lián)親密，以及與構(gòu)件或類自身

有親密關(guān)系的屬性和操作。

耦合性：類之間彼此聯(lián)絡(luò)程度日勺一種定性度量

第11章完畢顧客界面設(shè)計(jì)

黃金規(guī)則

置顧客于控制之下；

以不強(qiáng)迫顧客進(jìn)入不必要的或不僅愿H勺動(dòng)作H勺方式來(lái)定義交互模式。

提供靈活度的交互。

容許顧客交互被中斷和撤銷。

當(dāng)技能級(jí)別增長(zhǎng)時(shí)可以使交互流線化并容許定制交互。

使顧客與內(nèi)部技術(shù)細(xì)節(jié)隔離開(kāi)來(lái)。

設(shè)計(jì)容許顧客與出目前屏幕上日勺對(duì)象直接交互。

減少顧客的記憶承擔(dān)；

減少對(duì)短期記憶的規(guī)定。

建立故意義的缺省。

定義直觀日勺快捷方式。

界面日勺視覺(jué)布局應(yīng)當(dāng)基于真實(shí)世界的象征。

以不停進(jìn)展的方式揭示信息。

保持界面一致性。

容許顧客將目前任務(wù)放入故意義日勺環(huán)境中。

在應(yīng)用系統(tǒng)家族內(nèi)保持一致性。

假如過(guò)去口勺交互模型已經(jīng)建立起了顧客期望，除非有不得已的理由，否則不要變化它。

重點(diǎn)：

1.試給出兩個(gè)附加的“減少顧客記憶承擔(dān)”、“保持界面一致性”的設(shè)計(jì)原則。

2.假設(shè)你被邀請(qǐng)開(kāi)發(fā)一種基于WEB的家庭銀行系統(tǒng)。請(qǐng)給出顧客模型、設(shè)計(jì)模型、心

理模型和實(shí)現(xiàn)模型。