1.常見縮寫

基于架構的軟件設計（Architecture-BasedSoftwareDesign,ABSD）

特定領域軟件架構（DomainSpecificSoftwareArchitecture,DSSA）

軟件架構評估方法：

1）架構權衡分析法（ArchitectureTradeoffAnalysisMethod,ATAM）

2）軟件架構分析方法（SoftwareArchitectureAnalysisMethod,SAAM）

快速應用開發(fā)（RapidApplicationDevelopment,RAD）

軟件開發(fā)環(huán)境（SoftwareDevelopmentEnvironment,SDE）

架構描述語言（ArchitectureDescriptionLanguage,ADL）

“4+1”視圖模型（邏輯開發(fā)（姬發(fā)）進屋里的場景）一類實現(xiàn)進程部署的例子

設計模式：1）創(chuàng)建型：單元相公造；2）結構型：理賠喬裝觀元組

軟件架構風格：流返購機艙

用例關系包括：包含include、擴展extend、泛化

UML圖、類圖關系：范組局聯(lián)誼（泛化、組合、聚合、關聯(lián)、依賴）

系統(tǒng)可靠性：冗余技術、軟件容錯技術（恢復塊設計、N版本程序設計）、雙機容錯技術、集群技術

軟件可靠性：軟件容錯設計（恢復塊設計、N版本程序設計）、檢錯設計和降低復雜度設計

2.*基于架構的軟件設計（ABSD）

強調由商業(yè)、質量和功能需求的組合驅動軟件架構設計、它強調采用視角和視圖來描述軟件架構,采用

用例和質量屬性場景來描述需求。用例描述的是功能需求，質量屬性場景描述的是質量需求。使用ABSD方法,

設計活動可以從項目總體功能框架明確就開始。

ABSD方法有三個基礎：

第一個是功能分解，在功能分解中使用已有的基于模塊的內聚和耦合技術.

第二個是通過選擇架構風格來實現(xiàn)質量和商業(yè)需求。

第三個是軟件模板的使用。

ABSD方法是一個自頂向下，遞歸細化的過程，軟件系統(tǒng)的架構通過該方法得到細化，直到能產生軟件構

件的類。

軟件架構文檔的寫作應該遵循一定的原則，這些原則包括：文檔要從使用者的角度進行編寫；必須分發(fā)

給所有與系統(tǒng)有關的開發(fā)人員；應該保持架構文檔的即時更新，但不要隨時保證文檔最新;架構文檔中描述

應該盡量避免不必要的重復；每次架構文檔修改都應該記錄進行修改的原則。架構文檔化的主要輸出結果是

架構規(guī)格說明書和架構質量說明書。

3.*特定領域軟件架構（DomainSpecificSoftwareArchitecture,DSSA）

可以看做開發(fā)產品線的一個方法（或理論）.以一個特定問題領域為對象,形成由領域參考模型、參考需

求、參考架構等組成的開發(fā)基礎架構,其目標是支持一個特定領域中多個應用的生成。DSSA的特征：

1.一個嚴格定義的問題域和問題解域

2.具有普遍性。使其可以用于領域中某個特定應用的開發(fā)

3.對整個領域的構件組織模型的恰當抽象

4.具備該領域固定的、典型的在開發(fā)過程中可重用元素。

DSSA的基本活動：

（1）領域分析：主要目標是獲得領域模型。領域模型描述領域中系統(tǒng)之間共同的需求，即領域需求。

（2）領域設計：目標是獲得DSSA（特定領域軟件架構）,DSSA描述領域模型中表示需求的解決方案。

（3）領域實現(xiàn)：主要目標是依據(jù)領域模型和DSSA開發(fā)與組織可復用信息。這些復用信息可以是從現(xiàn)有系統(tǒng)

中提取得到的，也可能通過新的開發(fā)得到。這個階段可以看作復用基礎設施的實現(xiàn)階段。

參與DSSA的人員：領域專家，領域分析員，領域設計人員和領域實現(xiàn)人員。

,領域。家的主要任務是包括提供關于領域中系統(tǒng)的需求規(guī)約和實現(xiàn)的知識,幫助組織規(guī)范的、一致的領域

字典，幫助選擇樣本系統(tǒng)作為領域工程的依據(jù)，復審領域模筌、DSSA等領域工程產品等。

/領域分析師：主要任務包括控制整個領域分析過程，進行知識獲取,將獲取的指示組織到領域模型中，根

據(jù)現(xiàn)有系統(tǒng)、標準規(guī)范等驗證領域模型的準確性和一致性，維護領域模型。

/領域設計人員：主要任務把控制整個軟件設計過程，根據(jù)領域模型和現(xiàn)有的系統(tǒng)開發(fā)DSSA,對DSSA的準確

性和一致性進行驗證，建立領域模型和DSSA之間的聯(lián)系。

/領域實現(xiàn)人員：主要任務包括根據(jù)領域模型和DSSA,或者從頭開發(fā)可重用構件,或者利用再工程的技術從現(xiàn)

有系統(tǒng)中提取可重用構件，對可重用構件進行驗證，建立DSSA與可重用構件間的聯(lián)系。

1

4.*架構權衡分析方法（ArchitectureTradeoffAnalysisMethod,ATAM）

是一種系統(tǒng)架構評估方法，主要在系統(tǒng)開發(fā)之前,針對性能、可用性、安全性和可修改性等質量屬性進行評

價和折中。主要關注系統(tǒng)需求說明。

ATAM可以分為4個主要的活動階段，包括需求收集、架構視圖和場景實現(xiàn)、屬性模型構造和分析、架構決策

與折中,整個評估過程強調以屬拄作為架構評估的核心概念。ATAM方法要求在系統(tǒng)開發(fā)之前，首先對質量屬

性進行評價和折中。

ATAM是一種常用的軟件架構評估方法，該方法強調對軟件的質量屬性進行組I、分類和優(yōu)先級排序等工

作，在此基礎上構建質量屬性效用樹，并對風險點、非風險點、敏感點和權衡點進行識別和分析。

5.*軟件架構分析方法（Scenarios-basedArchitectureAnalysisMethod,SAAM）

SAAM的主要輸入是問題描述、需求說明和架構描述,其分析過程主要包括場景開發(fā)、架構描述、單個場景評

估、場景交互和總體評估。

6.*Rl；P（統(tǒng)一軟件過程）中“4+1”視圖模型（邏輯開發(fā)（姬發(fā)）進屋里的場景）-類實現(xiàn)進程部署的例子

4+1”視圖模型從5個不同的視角包括：

邏輯視圖、開發(fā)視圖、進程視圖、物理視圖和場景視圖來描述軟件架構。對應的UML圖為：

類圖、實現(xiàn)視圖、進程視圖、部署視圖和用例視圖。

*典用戶，功能特求出程人員，軟件管理

系統(tǒng)集成人員，性能系統(tǒng)工程人員，系及

可擴充性、吞吐堂等拓撲、女裝、通信等

/最終用戶關心的是系統(tǒng)的功能，因此會側重于邏輯視圖。邏輯視圖（類圖）：用來描述設計的對象模型和

對象之間的關系。并說明系統(tǒng)為用戶提供哪些服務。

/程序員關心的是系統(tǒng)的配置、裝配等問題，因此會側重于實現(xiàn)視圖；實現(xiàn)視圖（開發(fā)視圖）描述了軟件

模塊的組織與管理。

/系統(tǒng)集成人員關心的是系統(tǒng)的性能、可伸縮性、吞吐率等問題，因此會側重于進程視圖；進程視圖：描

述設計的并發(fā)和同步特征。

/系統(tǒng)工程師關心的是系統(tǒng)的發(fā)布、安裝、拓撲結構等問題，因此會側重于部署視圖；部署視圖：描述軟

件到硬件的映射，反應了分布式特性。

/分析人員和測試人員關心的是系統(tǒng)的行為，因此會側重于用例視圖；

RUP把軟件開發(fā)生存周期劃分為多個循環(huán)，每個循環(huán)生成產品的一個新的版本，每個循環(huán)依次由4個連續(xù)的

階段組成，每個階段完成確定的任務。這4個階段分別為：

/初始階段：定義最終產品視圖和業(yè)務模型，并確定系統(tǒng)范圍。

,細化階段：設計及確定系統(tǒng)的體系結構,制定工作計劃及資源要求。

/構造階段：構造產品并繼續(xù)演進需求、體系結構、計劃直至產品提交。

/移交階段：把產品提交給用戶使用。

每個階段都有一個或多個連續(xù)的迭代組成。迭代并不是重復地做相同的事，而是針對不同用例的細化和實現(xiàn)。

每一個迭代都是一個完整的開發(fā)過程，它需要項目經理根據(jù)當前迭代所處的階段以及上次迭代的結果，適當

地對工作流中的行為進行裁剪。在每個階段結束前有一個里程碑評估該階段的工作。如果未能通過該里程碑

的評估，則決策者應該做出決定，是取消該項目還是繼續(xù)該階段的工作。

與其他軟件開發(fā)過程相比，RUP具有自己的特點，即RUP是用例驅動的、以體系結構為中心的、迭代和增量

的軟件開發(fā)過程。

7.*配置項

配置項是構成產品配置的主要元素，配置項主要有以下兩大類：

（1）屬于產品組成部分的工作成果：如需求文檔、設計文檔、源代碼和測試用例等；

（2）屬于項目管理和機構支撐過程域產生的文檔：如工作計劃、項目質量報告和項目跟蹤報告等

8.*企業(yè)應用集成模式：面向信息、面向過程、面向服務

企業(yè)應用集成通過采用多種集成模式，構建統(tǒng)一標準的基礎平臺，將具有不同功能和目的而又獨立運行

的企業(yè)信息系統(tǒng)聯(lián)合起來。目前市場上主流的集成模式有三種，分別是面向信息的集成、面向過程的集成和

2

面向服務的集成。其中面向過程的集成模式強調處理不同應用系統(tǒng)之間的交互邏輯,與核心業(yè)務邏輯相分離,

并通過不同應用系統(tǒng)之間的協(xié)作共同完成某項業(yè)務功能。

9.*面向對象設計模式中的圖

面向對象的設計模型包含以包圖表示的軟件體系結構圖;以交互圖表示的用例實現(xiàn)圖,完整精確的類圖，針

對復雜對象的狀態(tài)圖;用以描述流程化處理的活動圖等

10.*企業(yè)集成平臺基本功能

是一個支持復雜信息環(huán)境下信息系統(tǒng)開發(fā)、集成、協(xié)同運行的軟件支撐環(huán)境，包括硬件、軟件、軟件工具和

系統(tǒng)。基本功能包括：

①通信服務：提供分布環(huán)境下透明的同步/異步通信服務功能；

②信息集成服務：為應用提供透明的信息訪問服務，實現(xiàn)異種數(shù)據(jù)庫系統(tǒng)之間數(shù)據(jù)的交換、互操作、分布數(shù)

據(jù)管理和共享信息模型定義：

③應用集成服務：通過高層應用編程接口來實現(xiàn)對相應應用程序的訪問，能夠為應用提供數(shù)據(jù)交換和訪問操

作，使各種不同的系統(tǒng)能夠相互協(xié)作;

④二次開發(fā)工具：是集成平臺提供的一組幫助用戶開發(fā)特定應用程序的支持工具；

⑤平臺運行管理工具：是企業(yè)集成平臺的運行管理和控制模塊。

11.

12.數(shù)據(jù)庫需求分析階段完成的文檔

數(shù)據(jù)庫設計主要分為用戶需求分析、概念結構、邏輯結構設計、物理結構設計四個階段。在用戶調查的

基礎上，通過分析，逐步明確用戶對系統(tǒng)的需求，包括數(shù)據(jù)需求和圍繞這些數(shù)據(jù)的業(yè)務處理需求，以及對數(shù)

據(jù)安全性和完整性方面的要求。在需求分析階段應完成的文檔是需求說明文檔、數(shù)據(jù)字典和數(shù)據(jù)流圖DFD.

13.完整性約束分類

分為實證完整性約束、參照完整性約束和用戶自定義完整性約束三類。

實體完整性約束可以通過PrimaryKey指定，規(guī)定基本關系的主屬性不能取空值，例：庫存關系I中的“倉

庫號，產品號”唯一標識I中的每一個記錄，所以應滿足實體完整性約束；

參照完整性約束通過ForeignKey指定，例如：倉庫關系W中的“負責人”引用員工關系的員工號，所以應

滿足參照完整性約束.其格式：ForeignKey（屬性名）References表名（屬性名）References指明外碼對應

于哪個表的主碼。

例如：職稱為“工程師”的月薪不能低于3500元，是針對某一具體關系數(shù)據(jù)庫的約束條件，它反映某一具體

應用所涉及的數(shù)據(jù)必須滿足的語義要求，所以應滿足用戶定義完整性約束.

某些簡單的約束可以通過Check、Assertion等實現(xiàn)。針對復雜的約束，系統(tǒng)提供了觸發(fā)器機制，通過用戶

編程實現(xiàn)。只有在約束無法實現(xiàn)特定功能的情況下，才考慮通過觸發(fā)器來完成。

14.閉包

閉包就是由一個屬性直接或間接推導出的所有屬性的集合，例如：f=｛a->b,b->c,a->d,e->f｝由a可直接得到

b和d,間接得到c,則a的閉包就是｛a,b,c,d）記做a+

15.求候選碼

首先對于給定的R（U）和函數(shù)依賴集F,可以將它的屬性劃分為4類：

L類，僅出現(xiàn)在F的函數(shù)依賴左部的屬性。

R類，僅出現(xiàn)在F的函數(shù)依賴右部的屬性。

N類，在F的函數(shù)依賴左部和右部均未出現(xiàn)的屬性。

LR類，在F的函數(shù)依賴左部和右部兩部均出現(xiàn)的屬性。

關系模式R（A,B,C,D,E）,存在的函數(shù)依賴有：：：：：.

AE-D,A->B,D-C,CD-A,DE一A。求該患］

關系模式R的所有候選碼.-

?L類：EN類：無

?求E的閉包：｛E｝!=U

?逐一嘗試加入其他屬性：

?加入A,求AE的閉包：｛ABCDE｝=U,AE是一個候選碼，

不驗證AEB,AEC,AED,AEBC,AEBD,AECD,ABCDE（肯定

都是）

?加入B,求BE的閉包：｛BE｝!=U

?加入C,求CE的閉包：｛CE｝!=U

?加入D,求DE的閉包：｛ABCDE｝=U,DE是一個候選碼，

不驗證DEB,DEC,DEBC（肯定都是）

?力口）B,C.求BCE的閉包：｛BCE｝!=U候選碼的閉包二U

3

16.無損連接判斷方法

設有關系模式R(U,V,W,X,Y,Z),其函數(shù)依賴集：F={U-V,W-Z,Y-U,WY-X},現(xiàn)有下列分解：p=

{UVY,WXYZ}判斷分解p是否為無損連接。

步驟：

畫出這樣的二維圖

UVwXYz

UVY

WXYZ

二、在縱軸每個關系中楣有的元素添加ai(看下面)

UVwXYz

UVYala2a5

WXYZa3a4a5a6

三、根據(jù)函數(shù)依賴集(F={U-V,W-Z,Y-U,WY-X})中的每個依賴，填充二維表(看下面)

U9V則：觀察U列與V歹U，看是否有其中一行是U列跟V列都有元素這里al跟a2,如果有，則把V列所有

空都填上V列中對應行的元素，這里是a2

UVWXYZ

UVYala2a5

WXYZa2a3a4a5a6

W-Z則：a3跟a6在同一行，則Z列全部填上a6

uVWXYZ

UVYala2a5a6

WXYZa2a3a4a5a6

Y-U貝ij：a5跟al在同一行，則U列全部填上al

uVWXYZ

UVYala2a5a6

WXYZala2a3a4a5a6

WY-X則：這里注意！?。。。。。∵@里是WY推出X,應該考慮WY都有的那一行再跟X比較

UVwXYz

UVYala2a4a5a6

WXYZa1a2a3a4a5a6

而無損連接分解在二維圖里的表示方式就是，有其中一行全部覆蓋了ai(這里是WXYZ行)。WXYZ行全部覆

蓋了ai,故該分解為無損連接分解。無損連接分解可以通過自然連接、投影等運算還原到原來的關系模式。

無損連接分解的快捷判別方法

首先要申明，這種快捷方法是有前提的，前提就是分解后的關系模式只有兩個。其內容為：設P={R1,R2}

是R的一個分解，F(xiàn)是R上的FD集，那么分解P相對于F是無損分解的充分必要條件是：(RlCR2)f(Rl-

R2)或(RlDR2)f(R2-R1)。這個“或”字很重要,這里表示(RIC1R2)-(RI-R2)、(RICR2)f(R2-R1)中只

要有一個成立就行。這里的求交和相減運算的對象是關系模式的屬性。

例題：關系模式R(U,F),其中U={W,X,Y,Z},F={WX-Y,WfX,X-Z,W}。那么下列分解中是無損分解的是。

供選擇的答案：

A.p={Rl(WY),R2(XZ)}B.p={Rl(WZ),R2(XY)}

C.p={Rl(WXY),R2(XZ)}D.p={Rl(WX),R2(YZ)}

試題分析：

A選項，R1AR2為空，肯定不滿足條件。

B選項，R1AR2為空，肯定不滿足條件。

C選項,RinR2={X},R1-R2={WY},R2-R1={Z},根據(jù)函數(shù)依賴集，X-Z成立，(RIAR2)-(R2-R1)所以滿足

條件。

4

D選項，R1DR2為空，肯定不滿足條件。

17.函數(shù)依賴判斷

如果F上的所有函數(shù)依賴都在其分解后的某一個關系上成立，則這個分解是保持函數(shù)依賴的(這是一個充分

條件)。

設關系模式R<U,F>,其中U={A,B,C,D,E},F={A一BC,C->D,BC—E,

例題：ETA},則分解p={Rl(ABCE),R2(CD)}滿足一(4)。

首先看分解是否保持函數(shù)依賴。在F中有4個函數(shù)依賴。A-BC、BC-E和E-?A

在R1中得到了保持，C-D在R2中得到了保持，因此分解是保持函數(shù)依賴的。

A-BC,BC-E,E-A都在R1上成立(也就是說每一個函數(shù)依賴左右兩邊的屬性都在R1中)，CfD在R2上

成立，因此給分解是保持依賴的。

18.嵌入式系統(tǒng)中斷方式

嵌入式系統(tǒng)中采用中斷方式實現(xiàn)輸入輸出的主要原因是能對會發(fā)事件做出快速響應。在中斷時，CPU斷點信

息一般保存到棧中。高速緩存(Cache)對于程序員來說是透明的。

嵌入式系統(tǒng)通常采用接口中的移位蜜裙|來實現(xiàn)數(shù)據(jù)的串/并和并/串轉換操作。

19.三層模型主要將網絡劃分為核心層、匯聚層和接入層

核心層提供不同區(qū)域或者下層的高速連接和最優(yōu)傳送路徑；

匯聚層將網絡業(yè)務連接到接入層，并且實施與安全、流量負載和路由相關的策略；

接入層為局域網接入廣域網或者終端用戶訪問網絡提供接入。

20.網絡生命周期

網絡的生命周期至少包括網絡系統(tǒng)的構思計劃、分析設計、實時運行和維護的過程。對于大多數(shù)網絡系統(tǒng)來

說，由于應用的不斷發(fā)展，這些網絡系統(tǒng)需要不斷重復設計、實施、維護的迭代過程。常見的迭代周期可分

為以下五個階段：需求規(guī)范、通信規(guī)范、邏輯網絡設計、物理網絡設計、實施階段。

邏輯網絡結構設計是體現(xiàn)網絡設計核心思想的關鍵階段，在這一階段根據(jù)需求規(guī)范和通信規(guī)范，選擇一

種比較適宜的網絡邏輯結構，并基于該邏輯結構實施后續(xù)的資源分配規(guī)劃、安全規(guī)劃等內容。

物理網絡設計是對邏輯網絡設計的物理實現(xiàn)，通過對設備的具體物理分布、運行環(huán)境等的確定，確保網

絡的物理連接符合邏輯連接的要求。在這一階段，網絡設計者需要確定具體的軟硬件、連接設備、布線和服

務，并將它們搭建成一個可以正常運行的網絡。

現(xiàn)有網絡體系分析的工作目的是描述資源分布，以便于在升級時盡量保護已有投資，通過該工作可以使

網絡設計者掌握網絡現(xiàn)在所處的狀態(tài)和情況。

需求分析階段有助于設計者更好地理解網絡應該具有什么功能和拄能，最終設計出符合用戶需求的網絡，它

為網絡設計提供依據(jù)。

21.存儲系統(tǒng)DAS、NAS、SAN

開放系統(tǒng)的直連式存儲(Direct-AttachedStorage.DAS)在服務器上外掛了一組大容量硬盤，存儲設備

與服務器主機之間采用SCSI通道連接，帶寬為lOMB/s,20MB/S、40MB/S和80MB/S等。直連式存儲直接將存

儲設備連接到服務器上，這種方法難以擴展存儲容量，而且不支持數(shù)據(jù)容錯功能，當服務器出現(xiàn)異常時會造

成數(shù)據(jù)丟失。

網絡接入存儲(NetworkAttachedStorage,NAS)是將存儲設備連接到現(xiàn)有的網絡上，提供數(shù)據(jù)存儲和文

件訪問服務的設備。NAS服務器是在專用主機上安裝簡化了的瘦操作系統(tǒng)(只具有訪問權限控制、數(shù)據(jù)保護

和恢復等功能)的文件服務器。NAS服務器內置了與網絡連接所需要的協(xié)議，可以直接聯(lián)網，具有權限的用

戶都可以通過網絡訪問NAS服務器中的文件。

存儲區(qū)域網絡(StorageAreaNetwork,SAN)是一種連接存儲設備和存儲管理子系統(tǒng)的專用網絡，專門

提供數(shù)據(jù)存儲和管理功能。SAN可以被看作是負責數(shù)據(jù)傳輸?shù)暮蠖司W絡，而前端網絡(或稱為數(shù)據(jù)網絡)則

負責正常的TCP/IP傳輸。也可以把SAN看作是通過特定的互連方式連接的若干臺存儲服務器組成的單獨的數(shù)

據(jù)網絡，提供企業(yè)級的數(shù)據(jù)存儲服務。

22.基準測試、負載測試、集成測試、白盒測試

基準測試采用的測試程序稱為基準程序(Benchmark)基準程序就是公認的標準程序，用它能測試多種計算

機系統(tǒng)，比較和評價它們的性能，定期公布測試結果，供用戶選購計算機時參考。應用程序中應用最頻繁的

那部分核心程序作為評價計算機性能的標準程序，稱為基準測試程序。

負載測試就是運行某種診斷程序，加大負載，檢查哪個設備會發(fā)生故障。

在程序模塊測試后進行的集成測試，主要測試各模塊之間的接口是否正常起作用。

白盒測試就是根據(jù)程序內部結構和內部邏輯，測試其功能是否正確。

23.企業(yè)應用集成模式：面向信息、面向過程、面向服務

5

企業(yè)應用集成通過采用多種集成模式，構建統(tǒng)一標準的基礎平臺，將具有不同功能和目的而又獨立運行

的企業(yè)信息系統(tǒng)聯(lián)合起來。目前市場上主流的集成模式有三種，分別是面向信息的集成、面向過程的集成和

面向服務的集成。其中面向過程的集成模式強調處理不同應用系統(tǒng)獨的交互邏輯，與核心業(yè)務邏輯相分離,

并通過不同應用系統(tǒng)之間的協(xié)作共同完成某項業(yè)務功能。

24.電子數(shù)據(jù)交換EDI

電子數(shù)據(jù)交換是電子商務活動中采用的一種重要的技術手段。EDI的實施需要一個公認的標準和協(xié)議,

將商務活動中涉及的文件標準化和格式化；EDI通過計算機網絡，在貿易伙伴之間進行數(shù)據(jù)交換和自動處理;

EDI主要應用于企業(yè)與企業(yè)、企業(yè)與批發(fā)商之間的批發(fā)業(yè)務；EDI的實施在技術上比較成熟，但是實施EDI需

要統(tǒng)一數(shù)據(jù)格式，成本與代價較大。

25.*配置項

配置項是構成產品配置的主要元素，配置項主要有以下兩大類：

(1)屬于產品組成部分的工作成果：如需求文檔、設計文檔、源代碼和測試用例等；

(2)屬于項目管理和機構支撐過程域產生的文檔：如工作計劃、項目質量報告和項目跟蹤報告等

26.*逆向工程：實現(xiàn)級、結構級、功能級、領域級

軟件開發(fā)方法之逆向工程導出的信息可分為如下4個抽象層次。

①實現(xiàn)級：包括程序的抽象語法樹、符號表等信息。

②結構級：包括反映程序分量之間相互依賴關系的信息,例如調用圖、結構圖等。

③功能級：包括反映程序段功能及程序段之間關系的信息。

④領域級：包括反映程序分量或程序與應用領域概念之間對應關系的信息。

27.用例及用例間關系：包含、擴展、泛化

用例是在系統(tǒng)中執(zhí)行的一系列動作，這些動作將生成特定參與者可見的價值結果。它確定了一個和系統(tǒng)參與

者進行交互，并可由系統(tǒng)執(zhí)行的動作序列。用例模型描述的是外部執(zhí)行者(Actor)所理解的系統(tǒng)功能。用例

模型用于需求分析階段，它的建立是系統(tǒng)開發(fā)者和用戶反復討論的結果，表明了開發(fā)者和用戶對需求規(guī)格達

成的共識。

兩個而例之間的關系主要有兩種情況：一種是用于重用的包含關系，用構造型include表示；另一種是用于

分離出不同行為的擴展，用構造型extend表示。

①包含關系：當可以從兩個或兩個以上的原始用例中提取公共行為，或者發(fā)現(xiàn)能夠使用一個構件來實現(xiàn)某一

個用例的部分功能是很重要的事時，應該使用包含關系來表示它們。例如：注冊學生信息、充值都必須先執(zhí)

行用戶登錄操作，所以是包含關系。

②擴展關系：如果一個用例明顯地混合了兩種或兩種以上的不同場景，即根據(jù)情況可能發(fā)生多種事情，可以

斷定將這個用例分為一個主用例和一個或多個輔用例描述可能更加清晰。例如：查詢上機記錄和導出excel

③泛化關系：就是父類和子類的繼承關系。

28.*面向對象設計模式中的圖

面向對象的設計模型包含以包圖表示的軟件體系結構圖；以交互圖表示的用例實現(xiàn)圖,完整精確的類圖，針

對復雜對象的狀態(tài)圖;用以描述流程化處理的活動圖等

29.基于構件的開發(fā)模型

基于構件的開發(fā)模型利用模塊化方法將整個系統(tǒng)模塊化，并在一定構件模型的支持下復用構件庫中的一個或

多個軟件構件，通過組合手段高效率、高質量地構造應用軟件系統(tǒng)的過程?；跇嫾拈_發(fā)模型融合了螺旋

模型的許多特征，本質上是演化形的，開發(fā)過程是迭代的?；跇嫾拈_發(fā)模型由軟件的需求分析定義、體

系結構設計、構件庫建立、應用軟件構建以及測試和發(fā)布5個階段組成

30.MVC

基于MVC(ModelViewController)的JAVAEE應用中，系統(tǒng)的界面由JSP構件實現(xiàn)，分發(fā)客戶請求、有效組

織其他構件為客戶端提供服務的控制器由Servlet構件實現(xiàn)，數(shù)據(jù)庫相關操作由EntityBean構件實現(xiàn)，系

統(tǒng)核心業(yè)務邏輯由SessionBean構件實現(xiàn)。

31.網絡架構數(shù)據(jù)流圖

網絡架構數(shù)據(jù)流圖的主要作用是將處理器和設備分配到網絡中，需要顯示的信息包括服務器及其物理位置；

客戶端及其物理位置；處理器說明；傳輸協(xié)議。

32.系統(tǒng)測試

系統(tǒng)測試是將已經確認的軟件、計算機硬件、外設和網絡等其他因素結合在一起，進行信息系統(tǒng)的各種

集成測試和確認測試，其目的是通過與系統(tǒng)的需求相比較，發(fā)現(xiàn)所開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方。

系統(tǒng)測試是根據(jù)系統(tǒng)方案說明書來設計測試用例，常見的系統(tǒng)測試主要有濃復潮嵐、安全性測試、壓力測試、

性能測試、可靠性測試、可用性測試、可維護性測試和安裝測試。

6

黑盒測試也稱為功能測試，是根據(jù)規(guī)格說明（程序外部功能）所規(guī)定的功能來設計測試用例，它不考慮程序

的內部結構和處理過程。常用的黑盒測試技術有等價類劃分、邊值分析、錯誤猜測和因果圖等。

33.軟件架構

軟件架構貫穿于軟件的整個生命周期，但在不同的階段對軟件架構的關注力度并不相同。其中需求分析階段

主要關注問題域；設計階段主要將需求轉換為軟件架構模型；軟件實現(xiàn)階段主要關注將架構設計轉換為實際

的代碼；軟件部署階段主要通過組裝軟件組件提高系統(tǒng)的實現(xiàn)效率。其中設計與實現(xiàn)階段在軟件架構上的工

作最多，也最重要，因此關注力度最大

軟件架構設計是降低成本、改進質量、按時和按需交付產品的關鍵因素。架構設計能夠滿足系統(tǒng)的性能、

可維護性等品質；能夠使得不同的利益相關人（stakeholders）達成一致的目標；能夠支持項目計劃和項目

管理等活動；能夠有效地管理復雜性；等等。然而系統(tǒng)架構的給出（前提）必須建立在需求明確的基礎上。

基于架構的軟件設計（ABSD）強調由商業(yè)、質量和功能需求的組合驅動軟件架構設計。它強調采用視角和

視圖來描述軟件架構,采用用例和質量屬性場景來描述需求。用例描述的是功能需求，質量屬性場景描述的

是質量需求。使用ABSD方法，設計活動可以從項目總體功能框架明確就開始。ABSD方法有三個基礎：第一

個基礎是功能分解，在功能分解中使用已有的基于模塊的內聚和耦合技術。第二個基礎是通過選擇架構風格

來實現(xiàn)質量和商業(yè)需求。第三個基礎是軟件模板的使用。ABSD方法是一個自頂向下，遞歸細化的過程，軟件

系統(tǒng)的架構通過該方法得到細化，直到能產生軟件構件的類。

軟件架構文檔的寫作應該遵循一定的原則，這些原則包括：文檔要從使用者的角度進行編寫；必須分發(fā)

給所有與系統(tǒng)有關的開發(fā)人員；應該保持架構文檔的即時更新，但不要隨時保證文檔最新;架構文檔中描述

應該盡量避免不必要的重復；每次架構文檔修改都應該記錄進行修改的原則。架構文檔化的主要輸出結果是

架構規(guī)格說明書和架構質量說明書。

34架構復審

架構復審是基于架構開發(fā)中一個重要的環(huán)節(jié)。架構設計、文檔化和復審是一個迭代的過程。從這個方面來說,

在一個主版本的軟件架構分析之后，要安排一次由外部人員（用戶代表和領域專家）參加的復審。架構復審過

程中，通常會對一個可運行的最小化系統(tǒng)進行架構評估和測試。架構復審的目標是標識潛在的風險，及早發(fā)

現(xiàn)架構設計的缺陷和錯誤。

35.架構設計中：閉環(huán)結構和分層結構

閉環(huán)結構的軟件通常由幾個協(xié)作構件共同構成，且其中的主要構件彼此分開，能夠進行替換與重用，但

閉環(huán)結構通常適用于處理簡單任務（如機器裝配等），并不適用于復雜任務。

分層結構的特點是通過引入抽象層，在較低層次不確定的實現(xiàn)細節(jié)在較高層次會變得確定，并能夠組織

層間構件的協(xié)作，系統(tǒng)結構更加清晰。

36.架構模式/設計模式/慣用法

架構模式是軟件設計中的高層決策，例如C/S結構就屬于架構模式，架構模式反映了開發(fā)軟件系統(tǒng)過程中所

作的基本設計決策；

設計模式主要關注軟件系統(tǒng)的設計，與具體的實現(xiàn)語言無關；

慣用法則是實現(xiàn)時通過某種特定的程序設計語言來描述構件與構件之間的關系，例如引用-計數(shù)就是C++語言

中的一種慣用法。

37.軟件架構（體系結構）評估方法

ATAM是軟件體系結構評估中的一種方法，主要對軟件體系結構的設計結果進行評估。評估是軟件系統(tǒng)詳

細設計、實現(xiàn)和測試之前的階段工作，因此評估不涉及系統(tǒng)的實現(xiàn)代碼和測試，因為評估是考查軟件體系結

構是否能夠合適地解決軟件系統(tǒng)的需求，并不對軟件需求自身是否準確進行核實，而軟件需求是否準確是需

求評審階段的工作。ATAM并不是一種精確的評估方法，該方法表現(xiàn)的主要形式是評審會議。

ATAM是一種常用的軟件架構評估方法，該方法強調對軟件的質量屬性進行分析、分類和優(yōu)先級排序等工

作，在此基礎上構建質量屬性效用樹，并對風險點、非風險點、敏感點和權衡點進行識別和分析。

系統(tǒng)架構風險是指架構設計中潛在的、存在問題的架構決策所帶來的隱患。

敏感點是為了實現(xiàn)某一種質量屬性，一個或多個系統(tǒng)組件所具有的特性。例如：對交易請求處理時間的

要求將影響系統(tǒng)的數(shù)據(jù)傳輸協(xié)議和處理過程的設計。

權衡點指影響多個質量屬性，并對多個質量屬性來說都是敏感點的系統(tǒng)屬性。因為是多個質量屬性的敏

感點，所以要權衡。例如：選擇不同的加密方式同時影響性能和安全性。

38.數(shù)據(jù)庫容災

網絡安全體系設計是邏輯設計工作的重要內容之一，數(shù)據(jù)庫容災屬于網絡安全和應用安全考慮范疇

39.對稱加密算法和非對稱加密算法

7

對稱加密算法有DES、3DES、AES、Blowfish.IDEA、RC5、RC6。對稱加密加密與解密使用的是同樣的密

鑰，所以速度快，但由于需要將密鑰在網絡傳輸，所以安全性不高。對稱加密比非對稱加密效率要高。

非對稱加密算法RSA、ElgamaK背包算法、Rabin、D-H、ECC非對稱加密使用了一對密鑰，公鑰與私鑰,

所以安全性高，但加密與解密速度慢。

40.architecturalstyle架構風格

componentsandconnectortypes組件（構件）和連接器類型；constraints約束semanticmodels語

義模型

41.微3法操作系統(tǒng)

采用微內核結構的操作系統(tǒng)與傳統(tǒng)的操作系統(tǒng)相比，其優(yōu)點是提高了系統(tǒng)的靈活性、可擴充性，增強了系統(tǒng)

的可靠性，提供了對分布式系統(tǒng)的支持。其原因如下。

①靈活性和可擴展性：由于微內核0S的許多功能是由相對獨立的服務器軟件來實現(xiàn)的，當開發(fā)了新的硬件和

軟件時，微內核0S只需在相應的服務器中增加新的功能，或再增加一個專門的服務器。與此同時，也必然改

善系統(tǒng)的靈活性，不僅可在操作系統(tǒng)中增加新的功能，還可修改原有功能，以及刪除已過時的功能，以形成

一個更為精干有效的操作系統(tǒng)。

②增強了系統(tǒng)的可靠性和W移植性：由于微內核是出于精心設計和嚴格測試的，容易保證其正確性；另一方

面是它提供了規(guī)范而精簡的應用程序接口（API）,為微內核外部的程序編制高質量的代碼創(chuàng)造了條件。此外,

由于所有服務器都是運行在用戶態(tài)，服務器與服務器之間采用的是消息傳遞通信機制，因此，當某個服務器

出現(xiàn)錯誤時，不會影響內核，也不會影響其他服務器。另外，由于在微內核結構的操作系統(tǒng)中，所有與特定

CPU和I/O設備硬件有關的代碼，均放在內核和內核下面的硬件隱藏層中，而操作系統(tǒng)其他絕大部分（即各

種服務器）均與硬件平臺無關，因而，把操作系統(tǒng)移植到另一個計算機硬件平臺上所需作的修改是比較小的。

③提供了對分布式系統(tǒng)的支持：由于在微內核0S中，客戶和服務器之間以及服務器和服務器之間的通信，是

采用消息傳遞通信機制進行的，致使微內核0S能很好地支持分布式系統(tǒng)和網絡系統(tǒng)。事實上，只要在分布式

系統(tǒng)中賦予所有進程和服務器唯一的標識符，在微內核中再配置一張系統(tǒng)映射表（即進程和服務器的標識符

與它們所駐留的機器之間的對應表），在進行客戶與服務器通信時，只需在所發(fā)送的消息中標上發(fā)送進程和接

收進程的標識符，微內核便可利用系統(tǒng)映射表將消息發(fā)往目標，而無論目標是駐留在哪臺機器上。

42.文件控制塊（FileControlBlock,FCB）

操作系統(tǒng)為了實現(xiàn)“按名存取”，必須為每個文件設置用于描述和控制文件的數(shù)據(jù)結構，專門用于文件的檢

索，因此至少要包括文件名和存放文件的物理地址，該數(shù)據(jù)結構稱為文件控制塊（FCB）,文件控制塊的有序集

合稱為文件目錄，或稱系統(tǒng)目錄文件。若操作系統(tǒng)正在將修改后的系統(tǒng)目錄文件寫回磁盤時系統(tǒng)發(fā)生崩潰，

則對系統(tǒng)的影響相對較大

43.*數(shù)據(jù)庫設計步驟

數(shù)據(jù)庫設計分為用戶需求分析、概念設計、邏輯設計和物理設計4個主要階段。

用戶需求分析是指收集和分析用戶對系統(tǒng)的信息需求和處理需求，得到設計系統(tǒng)所必需的需求信息，建立系

統(tǒng)說明文檔。用戶需求分析階段形成的相關文檔用以作為概念結構設計的設計依據(jù)

概念結構設計對需求說明書提供的所有數(shù)據(jù)和處理要求進行抽象與綜合處理，按一定的方法構造反映用戶環(huán)

境的數(shù)據(jù)及其相互聯(lián)系的概念模型，即用戶的數(shù)據(jù)模型或企業(yè)數(shù)據(jù)模型。這種概念數(shù)據(jù)模型與DBMS無關，

是面向現(xiàn)實世界的、極易為用戶所理解的數(shù)據(jù)模型。概念模型的較理想的工具是E-R圖。

邏輯設計階段的任務是將概念模型設計階段得到的基本E-R圖轉換為與選用的DBMS產品所支持的數(shù)據(jù)模型相

符合的邏輯結構。如采用基于E-R模型的數(shù)據(jù)庫設計方法，該階段就是將所設計的E-R模型轉換為某個DBMS

所支持的數(shù)據(jù)模型；如采用用戶視圖法，則應進行模式的規(guī)范化，列出所有的關鍵字以及用數(shù)據(jù)結構圖描述

表集合中的約束與聯(lián)系，匯總各用戶視圖的設計結果，將所有的用戶視圖合成一個復雜的數(shù)據(jù)庫系統(tǒng)。

物理設計階段的任務是把邏輯設計階段得到的滿足用戶需求的已確定的邏輯模型在物理上加以實現(xiàn)，其主要

內容是根據(jù)DBMS提供的各種手段，設計數(shù)據(jù)的存儲形式和存取路徑，如文件結構、索引設計等，即設計數(shù)

據(jù)庫的內模式或存儲模式。

44.關系代數(shù)運算

8

5)選擇。。BR=-bh'(R)'表示R中取B列值為b的行。根據(jù)某些條件對關系做水平切割。

6)連接叫是從兩個關系的笛卡爾積中選取滿足某一屬性的集合。自然連接還需去掉重復的列。

ABC

123DE

45631

78962

關系R

關系S取B<D的行

45.指令周期

計算機執(zhí)行程序時,在一個指令周期的過程中,為了能夠從內存中讀指令操作碼，首先是將程序計數(shù)器

(PC)的內容送到地址總線上

46.十六進制計算

A=10B=llC=12D=13E=14F=15

FFF轉十進制=15*162+15*16'+15*160=4095

例題：內存按字節(jié)編址，利用8KX4b的存儲器芯片構成84000H到8FFFFH的內存，共需_1

解析：8FFFF-84000=BFFF轉十進制=11*16，+15*162+15*16‘+15*16°=C000T=12*163-l=49151

因為內存是按字節(jié)編碼，所以49151字節(jié)需要49151*8位。每個芯片位數(shù)=8Kx4b=8*1024*4

所需芯片個數(shù)=49151*8/(8*1024*4)=11上取整偶數(shù)，最少需要12片

47.cpu和10通信是同步

CPU訪問內存通常是同步方式，CPU與I/O接口交換信息通常是同步方式，CPU與PCI總線交換信息通常

是同步方式，I/O接口與打印機交換信息則通常采用基于緩存池的異步方式

48.核心層、匯聚層和接入層

大型局域網通常劃分為核心層、匯聚層(分布層)和接入層。

核心層的主要目的在于通過高速轉發(fā)通信，提供優(yōu)化、可靠的骨干傳輸結構，因此，核心層交換機應擁

有更高的可靠性，性能和吞吐量。核心層只完成數(shù)據(jù)交換的特殊任務。常用的技術包括ATM、100Base-Fx

9

和千兆以太網等，通常會使用雙星（樹）結構，即采用兩臺同樣的交換機，與匯聚層交換機分別連接，并使

用鏈路聚合技術實現(xiàn)雙機互聯(lián)。

匯聚層是核心層和接入層的分界面，完成網絡訪問策略控制、數(shù)據(jù)包處理、包過濾、尋址、各種協(xié)議的

轉換，以及其他數(shù)據(jù)處理的任務。

直接面向用戶連接或訪問網絡的部分稱為接入層。接入層的目的是允許終端用戶連接到網絡，因此，接

入層交換機具有低成本和高端口密度特性。接入層提供局域網絡接入功能，可以使用集線器代替交換機。

49.網絡系統(tǒng)設計-需求規(guī)范、通信規(guī)范、邏輯網絡設計、物理網絡設計、實施階段

邏輯網絡結構設計是體現(xiàn)網絡設計核心思想的關鍵階段，在這一階段根據(jù)需求規(guī)范和通信規(guī)范，選擇一

種比較適宜的網絡邏輯結構，并基于該邏輯結構實施后續(xù)的資源分配規(guī)劃、安全規(guī)劃等內容。

物理網絡設計是對邏輯網絡設計的物理實現(xiàn)，通過對設備的具體物理分布、運行環(huán)境等的確定，確保網

絡的物理連接符合邏輯連接的要求。在這一階段，網絡設計者需要確定具體的軟硬件、連接設備、布線和服

務。

50.網絡系統(tǒng)生命周期

網絡系統(tǒng)生命周期可以劃分為5個階段，實施這5個階段的合理順序是需求規(guī)范、通信規(guī)范、邏輯網絡

設計、物理網絡設計、實施階段

51.系統(tǒng)評估的目的

對運行系統(tǒng)進行評估的主要目的是評價信息系統(tǒng)在性能方面的表現(xiàn)，找出系統(tǒng)可能存在的性能瓶頸。其

中，常見的Web服務器性能評估方法有基準測試、壓力測試和可靠性測試等，評價Web服務器的主要性能指

標有最大并發(fā)連接數(shù)、響應延遲和吞吐量等。當系統(tǒng)性能降到基本水平時，需要查找影響性能的瓶頸并消除

該瓶頸。

52.企業(yè)門戶

企業(yè)門戶大致可以分為企業(yè)信息門戶、企業(yè)知識門戶和企業(yè)應用門戶三種。

企業(yè)信息門戶重點強調為訪問結構數(shù)據(jù)和無結構數(shù)據(jù)提供統(tǒng)一入口，實現(xiàn)收集、訪問、管理和無縫集成。

企業(yè)知識門戶提供了一個創(chuàng)造、搜集和傳播企業(yè)知識的平臺，通過企業(yè)知識門戶，員工可以與工作團隊

中的其他成員取得聯(lián)系，尋找能夠提供幫助的專家。

企業(yè)應用門戶是一個用來提高企業(yè)的集中貿易能力、協(xié)同能力和信息管理能力的平臺。它以商業(yè)流程和

企業(yè)應用為核心，將商業(yè)流程中功能不同的應用模塊通過門戶集成在一起，提高公司的集中貿易能力、協(xié)同

能力和信息管理能力。

53.客戶關系管理（CRM客人力資源、業(yè)務流程與專業(yè)技術的整合

客戶關系管理（CRM）系統(tǒng)將市場營銷的科學管理理念通過信息技術的手段集成在軟件上，能夠幫助企業(yè)

構建良好的客戶關系。在客戶管理系統(tǒng)中，銷售自動化是其中最為基本的模塊，營銷自動化作為銷售自動化

的補充，包括營銷計劃的編制和執(zhí)行、計劃結果分析等功能?？蛻舴张c支持是CRM系統(tǒng)的重要功能。目前,

客戶服務與支持的主要手段有兩種，分別是呼叫中心和互聯(lián)網。CRM系統(tǒng)能夠與ERP系統(tǒng)在財務、制造、庫

存等環(huán)節(jié)進行連接，兩者之間雖然關系比較獨立，但由于兩者之間具有一定的關系，因此會形成一定的閉環(huán)

反饋結構。

54.企業(yè)應用集成EAI

EAI是企業(yè)信息系統(tǒng)集成的科學、方法和技術，其目的就是將企業(yè)內的應用彼此連接起來，或在企業(yè)之

間連接起來。EAI主要包括兩方面：企業(yè)內部應用集成和企業(yè)間應用集成。

1）企業(yè)內集成

分為界面集成、平臺集成、數(shù)據(jù)集成、應用集成和過程集成。

2）企業(yè)間集成：應用電子數(shù)據(jù)交換EDI、VPN等技術

企業(yè)應用集成模式：面向信息的集成技術、面向過程的集成技術和面向服務的集成技術。

55.共享數(shù)據(jù)庫

共享數(shù)據(jù)庫是一種重要的企業(yè)應用集成方式，它通常將應用程序的數(shù)據(jù)存儲在一個共享數(shù)據(jù)庫中，通過

制定統(tǒng)一的數(shù)據(jù)庫模式來處理不同應用的集成需求。共享數(shù)據(jù)庫為不同的應用程序提供了統(tǒng)一的數(shù)據(jù)存儲與

格式定義，能夠在一定程度上緩解數(shù)據(jù)語義不一致的問題，但無法完全解決該問題。在共享數(shù)據(jù)庫集成中，

多個應用程序可能通過共享數(shù)據(jù)庫頻繁地讀取和修改相同的數(shù)據(jù)，這會使數(shù)據(jù)庫成為一個性能瓶頸。共享數(shù)

據(jù)庫集成方式的一個重要限制來自外部的已封裝應用，這些封裝好的應用程序只能采用自己定義的數(shù)據(jù)庫模

式，調整和集成余地較小。

56.企業(yè)信息系統(tǒng)集成方式

1）遠程過程調用RPC一般是基于同步的方式，效率較低，而且容易失敗；

10

2）共享數(shù)據(jù)庫和文件傳輸?shù)募煞绞皆谛阅芊矫孑^差，系統(tǒng)不能保持即時數(shù)據(jù)同步，而且容易造成應用

與數(shù)據(jù)緊耦合；

3）消息傳遞的集成方式能夠保證數(shù)據(jù)的異步、立即、可靠傳輸。

57.變更控制工具

一個好的變更控制過程，給項目風險承擔者提供了正式的建議需求變更機制?？梢酝ㄟ^需求變更控制過

程來跟蹤已建議變更的狀態(tài)，使已建議的變更確保不會丟失或疏忽。在實際中，人們總是希望使用自動工具

來執(zhí)行變更控制過程。有許多人使用商業(yè)問題跟蹤工具來收集、存儲、管理需求變更；可以使用工具對一系

列最近提交的變更建議產生一個列表給變更控制委員會開會時做議程用。問題跟蹤工具也可以隨時按變更狀

態(tài)分類包裹變更請求的數(shù)目。

挑選工具時可以考慮以下幾個方面：

①可以定義變更請求的數(shù)據(jù)項。

②可以定義變更請求生存期的狀態(tài)轉換圖。

③可以加強狀態(tài)轉換圖，使經授權的用戶僅能做出所允許的狀態(tài)變更。

④記錄每一種狀態(tài)變更的數(shù)據(jù)，確認做出變更的人員。

⑤可以定義在提交新請求或請求狀態(tài)被更新后應該自動通知的設計人員。

⑥可以根據(jù)需要生成標準的或定制的報告和圖表

58.CMM成熟度級別

一、初始級

軟件過程是無序的，甚至是混亂的，沒有什么是經過定義的，項目成功的完成完全依賴個人的努力和核心人

物的作用。

提高：建立項目過程管理，建立計劃。

二、可重復級。具有6個關鍵過程域KPA

建立基本的項目管理過程和實踐去跟蹤項目成本、進度、質量，必要的過程準則可以重復類似項目的成功。

提高：引入需求管理、項目管理（計劃管理、項目跟蹤與監(jiān)控）、子合同管理、軟件配置管理和質量管理

（包括質量量化和監(jiān)控）。

需求管理的目標是為軟件需求建立一個基線，提供給軟件工程和管理使用。軟件計劃、產品和活動與軟件需

求保持一致。

三、已定義級

軟件已經文檔化、標準化、并綜合成整個軟件開發(fā)組織的標準軟件過程。所有項目都采用根據(jù)實際情況修改

后得到的標準軟件過程來開發(fā)和維護。

提高：組織過程定義、焦點，培訓大綱，軟件集成管理，組織協(xié)調，專家評審等。

四、已管理級

制定了軟件過程和產品質量的詳細度量標準。軟件質量都被開發(fā)組織人員所理解和控制。

提高：定量的軟件過程管理和產品質量管理，防止和規(guī)避缺陷的能力，技術革新能力，過程不斷改進。

五、優(yōu)化級

加強了定量分析，通過質量反饋和新技術的反饋過程不斷持續(xù)的改進。

59.*RUP（統(tǒng)一軟件過程）中“4+1”視圖模型（邏輯開發(fā)（姬發(fā)）進屋里的場景）-類實現(xiàn)進程部署的例子

Kruchten在1995年提出了一個“4+1”的視圖模型。4+1”視圖模型從5個不同的視角包括

邏輯視圖、開發(fā)視圖、進程視圖、物理視圖和場景視圖來描述軟件架構。對應的UML圖為：

類圖、實現(xiàn)視圖、進程視圖、部署視圖和用例視圖。

城終用戶?功能需求編程人員：軟件管理

系統(tǒng)集成人員：性能系統(tǒng)工程人員,系統(tǒng)

可擴充性、吞吐量等拓撲、安裝、通信等

11

,最終用戶關心的是系統(tǒng)的功能，因此會側重于邏輯視圖。邏輯視圖：用來描述設計的對象模型和對象之

間的關系。并說明系統(tǒng)為用戶提供哪些服務。

/程序員關心的是系統(tǒng)的配置、裝配等問題，因此會側重于實現(xiàn)視圖；描述了軟件模塊的組織與管理。

/系統(tǒng)集成人員關心的是系統(tǒng)的性能、可伸縮性、吞吐率等問題，因此會側重于進程視圖；描述設計的先

發(fā)和同步特征。

/系統(tǒng)工程師關心的是系統(tǒng)的發(fā)布、安裝、拓撲結構等問題，因此會側重于部署視圖；描述軟件到硬件的

映射，反應了分布式特性。

,分析人員和測試人員關心的是系統(tǒng)的行為，因此會側重于用例視圖；

60.軟件開發(fā)模型

原型模型又稱快速原型。原型模型主要有兩個階段：①原型開發(fā)階段。軟件開發(fā)人員根據(jù)用戶提出的軟

件系統(tǒng)的定義，快速地開發(fā)一個原型。該原型應該包含目標系統(tǒng)的關鍵問題和反映目標系統(tǒng)的大致面貌，展

示目標系統(tǒng)的全部或部分功能、性能等。②目標軟件開發(fā)階段。在征求用戶對原型的意見后對原型進行修改

完善，確認軟件系統(tǒng)的需求并達到一致的理解，進一步開發(fā)實際系統(tǒng)。

瀑布模型可以說是最早使用的軟件生存周期模型之一。由于這個模型描述了軟件生存的一些基本過程活

動，所以它被稱為軟件生存周期模型。這些活動從一個階段到另一個階段逐次下降，形式上很像瀑布。瀑布

模型的特點是因果關系緊密相連，前一個階段工作的結果是后一個階段工作的輸入。

螺旋模型是在快速原型的基礎上擴展而成的。這個模型把整個軟件開發(fā)流程分成多個階段，每個階段都

由4部分組成，它們是：①目標設定。為該項目進行需求分析，定義和確定這一個階段的專門目標，指定對

過程和產品的約束，并且制定詳細的管理計劃。②風險分析。對可選方案進行風險識別和詳細分析，制定解

決辦法，采取有效的措施避免這些風險。③開發(fā)和有效性驗證。風險評估后，可以為系統(tǒng)選擇開發(fā)模型，并

且進行原型開發(fā)，即開發(fā)軟件產品。④評審。對項目進行評審，以確定是否需要進入螺旋線的下一次回路，

如果決定繼續(xù)，就要制定下一階段計劃。

V模型是一種典型的測試模型。在V模型中測試過程被加在開發(fā)過程的后半部分，分別包括單元測試、

集成測試、系統(tǒng)測試和驗收測試。

61.*軟件開發(fā)環(huán)境SDE-集成機制可以劃分為環(huán)境信息庫、過程控制與消息服務器、環(huán)境用戶界面

軟件開發(fā)環(huán)境(SoftwareDevelopmentEnvironment)是支持軟件產品開發(fā)的軟件系統(tǒng)。它由軟件工具集和環(huán)

境集成機制構成，前者用來支持軟件開發(fā)的相關過程、活動和任務集；后者為工具集成和軟件開發(fā)、維護和

管理提供統(tǒng)一的支持，它通常包括數(shù)據(jù)集成、控制集成和界面集成。

,數(shù)據(jù)集成機制提供了存儲或訪問環(huán)境信息庫的統(tǒng)一的數(shù)據(jù)接口規(guī)范；

/界面集成機制采用統(tǒng)一的界面形式，提供統(tǒng)一的操作方式；

/控制集成機制支持各開發(fā)活動之間的通信、切換、調度和協(xié)同工作。

62.軟件重用

軟件重用是指在兩次或多次不同的軟件開發(fā)過程中重復使用相同或相似軟件元素的過程。按照重用活動

是否跨越相似性較少的多個應用領域，軟件重用可以區(qū)別為橫向重用和縱向重用。

橫向重用是指重用不同應用領域中的軟件元素，例如數(shù)據(jù)結構、分類算法和人機界面構建等。標準函數(shù)

是一種典型的、原始的橫向重用機制。

縱向重用是指在一類具有較多公共性的應用領域之間進行軟部件重用?？v向重用活動的主要關鍵點是域

分析：根據(jù)應用領域的特征及相似性預測軟部件的可重用性。

63.需求分析方法-結構化分析方法

結構化分析方法是一種面向數(shù)據(jù)速的需求分析方法，其基本思想是自頂向下逐層分解。數(shù)據(jù)流圖DFD是

進行結構化分析時所使用的模型，其基本成分包括數(shù)據(jù)流、加工、數(shù)據(jù)存儲和外部實體。在進行結構化設計

時，通過對數(shù)據(jù)流圖進行變換分析和事務分析可以導出程序結構圖。

結構化分析方法的基本思想是自頂向下，逐層分解，把一個大問題分解成若干個小問題，每個小問題再

分解成若干個更小的問題。經過逐層分解，每個最低層的問題都是足夠簡單、容易解決的。結構化方法分析

模型的核心是數(shù)據(jù)字典,圍繞這個核心，有三個層次的模型，分別是數(shù)據(jù)模型、功能模型和行為模型(也稱

為狀態(tài)模型)。在實際工作中，一般使用『R圖表示數(shù)據(jù)模型，用DFD表示功能模型，用狀態(tài)轉換圖表示行

為模型。這三個模型有著密切的關系，它們的建立不具有嚴格的時序性，而是一個迭代的過程。

64.UML

UML是面向對象軟件的標準化建模語言，其中狀態(tài)圖、活動圖、順序圖和通信圖可以用來對系統(tǒng)的動態(tài)行為

進行建模。活動圖展現(xiàn)了在系統(tǒng)內從一個活動到另一個活動的流程?；顒訄D強調對象之間的控制流程。在活

動圖上可以表示分支和匯合。活動圖與傳統(tǒng)的程序流程圖是不等價的。

65.基于構件的開發(fā)

12

在基于構件的開發(fā)中，構件包含并擴展了模塊化程序設計中子程序、面向對象系統(tǒng)中對象或類、系統(tǒng)模

型中包的思想，它是系統(tǒng)設計、實現(xiàn)和維護的基礎。

構件定義：通過接口訪問服務的一個獨立可交付的功能單元。

/邏輯構件模型用功能包描述系統(tǒng)的抽象設計，用接口描述每個服務集合，以及功能之間如何交互以滿足

用戶需求，它作為系統(tǒng)的設計藍圖以保證系統(tǒng)提供適當?shù)墓δ堋?/p>

/物理構件模型用技術設施產品、硬件分布和拓撲結構，以及用于綁定的網絡和通信協(xié)議描述系統(tǒng)的物理

設計■，這種架構用于了解系統(tǒng)的性能、吞吐率等許多非功能性屬性

66.構件標準

對象管理組織(OMG)基于CORBA基礎設施定義了4種構件標準。

/實體(Entity)構件需要長期持久化并主要用于事務性行為，由容器管理其持久化。

/加工(Process)構件同樣需要容器管理其持久化，但沒有客戶端可訪問的主鍵。

，會話(Session)構件不需要容器管理其持久化，其狀態(tài)信息必須由構件自己管理。

/服務(Service)構件是無狀態(tài)的。

67.分布式系統(tǒng)開發(fā)分為5個邏輯計算層

分布式系統(tǒng)開發(fā)分為5個邏輯計算層：

/表示層實現(xiàn)用戶界面；

/表示邏輯層包括為了生成數(shù)據(jù)表示而必須進行的處理任務，如輸入數(shù)據(jù)編輯等；

/應用邏輯層包括為支持實際業(yè)務應用和規(guī)則所需的應用邏輯和處理過程，如信用檢查、數(shù)據(jù)計算和分析

等；

/數(shù)據(jù)處理層包括存儲和訪問數(shù)據(jù)庫中的數(shù)據(jù)所需的應用邏輯和命令，如查詢語句和存儲過程等：

/數(shù)據(jù)層是數(shù)據(jù)庫中實際存儲的業(yè)務數(shù)據(jù)

68.分布式計算架構

客戶機/服務器系統(tǒng)開發(fā)時可以采用不同的分布式計算架構：

/分布式表示架構是將表示層和表示邏輯層遷移到客戶機，應用邏輯層、數(shù)據(jù)處理層和數(shù)據(jù)層仍保留在服

務器上；

，分布式裝據(jù)架構是將數(shù)據(jù)層和數(shù)據(jù)處理層放置于服務器，應用邏輯層、表示邏輯層和表示層置于客戶機;

/分布式數(shù)據(jù)和應用架構是將數(shù)據(jù)層和數(shù)據(jù)處理層放置在數(shù)據(jù)服務器上，應用邏輯層放置在應用服務器上,

表示邏輯層和表示層放置在客戶機上.

69.驗證輸入數(shù)據(jù)的有效性

系統(tǒng)輸入設計中，通常通過內部控制的方式驗證輸入數(shù)據(jù)的有效性。數(shù)據(jù)類型檢查確保輸入了正確的數(shù)據(jù)類

型；自檢位用于對主關鍵字進行基于校驗位的檢查；域檢查用于驗證數(shù)據(jù)是否位于合法的取值范圍；格式檢

查按照已知的數(shù)據(jù)格式對照檢查輸入數(shù)據(jù)的格式。

70.系統(tǒng)測試

系統(tǒng)測試是將已經確認的軟件、計算機硬件、外設和網絡等其他因素結合在一起，進行信息系統(tǒng)的各種

組裝測試和確認測試，其目的是通過與系統(tǒng)的需求相比較，發(fā)現(xiàn)開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方。

系統(tǒng)測試是根據(jù)系統(tǒng)方案說明書來設計測試例子的，常見的系統(tǒng)測試主要有以下內容：

(1)恢復測試：恢復測試監(jiān)測系統(tǒng)的容錯能力。檢測方法是采用各種方法讓系統(tǒng)出現(xiàn)故障，檢驗系統(tǒng)是否按照

要求能從故障中恢復過來，并在約定的時間內開始事務處理，而且不對系統(tǒng)造成任何傷害。如果系統(tǒng)的恢復

是自動的(由系統(tǒng)自動完成)，需要驗證重新初始化、檢查點、數(shù)據(jù)恢復等是否正確。如果恢復需要人工干預,

就要對恢復的平均時間進行評估并判斷它是否在允許的范圍內。

(2)安全性測試：系統(tǒng)的安全性測試是檢測系統(tǒng)的安全機制、保密措施是否完善，主要是為了檢驗系統(tǒng)的防范

能力。測試的方法是測試人員模擬非法入侵者，采用各種方法沖破防線。系統(tǒng)安全性設計準則是使非法入侵

者所花費的代價比進入系統(tǒng)后所得到的好處要大，此時非法入侵已無利可圖。

(3)強度測試：是對系統(tǒng)在異常情況下的承受能力的測試，是檢查系統(tǒng)在極限狀態(tài)下運行時，性能下降的幅度

是否在允許的范圍內。因此，強度測試要求系統(tǒng)在非正常數(shù)量、頻率或容量的情況下運行。強度測試主要是

為了發(fā)現(xiàn)在有效的輸入數(shù)據(jù)中可能引起不穩(wěn)定或不正確的數(shù)據(jù)組合。例如，運行使系統(tǒng)處理超過設計能力的

最大允許值的測試例子；使系統(tǒng)傳輸超過設計最大能力的數(shù)據(jù)，包括內存的寫入和讀出等。

(4)性能測試：檢查系統(tǒng)是否滿足系統(tǒng)設計方案說明書對性能的要求。性能測試覆蓋了軟件測試的各階段，而

不是等到系統(tǒng)的各部分都組裝之后，才確定系統(tǒng)的真正性能。通常與強度測試結合起來進行，并同時對軟件、

硬件進行測試。軟件方面主要從響應時間、處理速度、吞吐量、處理精度等方面來檢測。

13

(5)可靠性測試：通常使用以下兩個指標來衡量系統(tǒng)的可靠性：平均失效間隔時間MTBF(meantimebetween

failures)是否超過了規(guī)定的時限，因故障而停機時間MTTR(meantimetorepairs)在一年中不應超過多少

時間。

⑹安裝測試：在安裝軟件系統(tǒng)時，會有多種選擇。安裝測試就是為了檢測在安裝過程中是否有誤、是否容易

操作等。主要監(jiān)測系統(tǒng)的每一個部分是否齊全，硬件的配置是否合理，安裝中需要產生的文件和數(shù)據(jù)庫是否

已產生，其內容是否正確等。

71.軟件架構

軟件架構是降低成本、改進質量、按時和按需交付產品的關鍵因素，軟件架構設計需要滿足系統(tǒng)的質量

屬性，如性能、安全性和可修改性等，軟件架構設計需要確定組件之間的依賴關系，支持項目計劃和管理活

動，軟件架構能夠指導設計人員和實現(xiàn)人員的工作。一般在設計軟件架構之初，會根據(jù)