軟件質量控制期中復習

V模型的特點：

1）軟件開發(fā)過程與軟件測試過程是并發(fā)進行的；

2）軟件測試的目標和計劃在系統(tǒng)實現(xiàn)（編碼）之前就已確定；

3）針對不同的測試目的和測試階段，采用的測試方法應該合理選擇。

1.2軟件缺陷

軟件缺陷的定義：

只有至少滿足下列5個規(guī)則之一才稱發(fā)生了一個軟件缺陷（Software

bug）:

軟件未實現(xiàn)產品說明書要求的功能；

軟件出現(xiàn)了產品說明書指明不應該出現(xiàn)的錯誤；

軟件實現(xiàn)了產品說明書未提到的功能；

軟件未實現(xiàn)產品說明書雖未明確提及但應該實現(xiàn)的目標；

軟件難以理解、不易使用、運行緩慢或-從測試員的角度看-最終用

戶會認為不好。

軟件缺陷的主要類型/表現(xiàn)形式：

功能、特性沒有實現(xiàn)或部分實現(xiàn)

設計不合理，存在缺陷

實際結果和預期結果不一致

運行出錯，包括運行中斷、系統(tǒng)崩潰、界面混亂

數(shù)據(jù)結果不正確、精度不夠

用戶不能接受的其他問題，如存取時間過長、界面不美觀

軟件錯誤的根本原因來源于下面幾個方面：

說明不完整或說明錯誤

與客戶交流不夠所產生的誤解

故意與說明偏離

違反編程標準

數(shù)據(jù)表示有錯

模塊接口不一致

設計邏輯有錯

不完整或錯誤的測試

就就性（對白外特境它能適%地響應嗎?）

軟件產品時

效率（完成預定功能時它需要的計尊機費源名叫?）

的［產品轉移。

完誼性（它是安全的嗎?）

信可用性（我能使用它嗎?）

風險性（能恢修定計劃完成它嗎?）

1.4軟件質量工程體系的構成

1.6軟件質量成本軟件質量成本是為確保和保證滿意的質量而發(fā)生的費用

以及沒有達到滿意的質量所造成損失的總和，即包括保證費用和損失費

用。

軟i牛質量成本的構成：軟件質量成本=質量預防成本+評價成本+失效

成本

,預防成本：預防產生質量問題（軟件缺陷）的費用，是企業(yè)的計劃

性支出，專門用來確保在軟件產品交付和服務的各個環(huán)節(jié)不出現(xiàn)失

誤。

/評價成本：是指在交付和服務環(huán)節(jié)上，為評定軟件產品或服務是否

符合質量要求而進行的試驗、軟件測試和質量評估等所必需的支出。

/失效成本：分為內部的和外部的，如果在軟件發(fā)布之前發(fā)現(xiàn)質量問

題，而要求重做、修改和問題分析所帶來的成本屬內部失效成本，

包括修正軟件缺陷、回歸測試等，以及因產品或服務不合要求導致

的延誤。

1.7軟件的項目度量內容1規(guī)模度量（sizemeasurement）:以代碼行數(shù)、

功能點數(shù)、對象點或特征點等來衡量。軟件規(guī)模度量是工作量度量、進度

度量的基礎，用于估算軟件項目工作量、編制成本預算、策劃項目進度的

基礎。

2復雜度度量(complexitymeasurement)：確定程序控制流或軟件系

統(tǒng)結構的復雜程度指標。復雜度度量用于估計或預測軟件產品的可測試

性、可靠性和可維護性，以便選擇最優(yōu)化、最可靠的程序設計方法，來確

定測試策略、維護策略等。

3缺陷度量(defectmeasurement):幫助確定產品缺陷分布的情況、

缺陷變化的狀態(tài)等，從而幫助分析修復缺陷所需的工作量、設計和編程中

存在哪些弱點、預測產品發(fā)布時間、預測產品的遺留缺陷等。

4工作量度量(workloadmeasurement):任務分解并結合人力資源水

平來度量，合理地分配研發(fā)資源和人力，獲得最高的效率比。工作量度量

是在軟件規(guī)模度量和生產率度量的基礎上進行。

5進度度量(schedulemeasurement):通過任務分解、工作量度量、

有效資源分配等做出計劃，然后將實際結果和計劃值進行對比來度量。6

風險度量(riskmeasurement):一般通過兩個參數(shù)“風險發(fā)生的概率”和

“風險發(fā)生后所帶來的損失”來評估風險。

其他的項目度量，如需求穩(wěn)定性或需求穩(wěn)定因子(RSI,Requirement

StabilityIndex),資源利用效率(ResourceUtilization),文檔復審水

平(Reviewlevel),問題解決能力(Issue-resolvingability)、代碼

動態(tài)增長等。

1.8軟件需求工程

所有與需求直接相關的活動統(tǒng)稱為需求工程，需求工程分為了兩個部

分：需求開發(fā)和需求管理。其中，需求開發(fā)又分為了需求獲取、需求分析、

需求定義和需求驗證4個部分，而需求管理則包含了變更控制、版本控制、

需求跟蹤和需求狀態(tài)跟蹤。

需求工程過程柢架和功能需求(也

括

包N映了組織機構

客

或范圍文檔中予以

說

明H一個業(yè)務前景。

業(yè)

務作用。用戶需求

(U壬務的集合，用

戶se

需為明。收集和分

析

用取，更難保證需

求

完行充分地交流。

功

能必須實現(xiàn)的軟件

它

在1要的部分之一,

中都起了重要的

作用操作等，包括要

遵從的業(yè)務規(guī)則、人機接口、安全性和可靠性等要求。

1.9系統(tǒng)分析與設計

L9.1面向對象的分析建模過程

?誘導系統(tǒng)的客戶需求；

?標識場景或用例(usecase);

?使用基本需求來確定類和對象；

?為每個系統(tǒng)對象表示屬性和操作；

?定義組織類的結構和層次；

?建造對象-關系模型；

?建造對象-行為模型；

?依據(jù)use-case/場景來評審00A模型。

1.9.2設計模式重點看資料中的設計模式實現(xiàn)(單一模式和類工廠模式)

設計模式有4個基本要素：

模式名稱：描述模式的問題、解決方案和效果；

問題：描述了應該在何時使用模式；

解決方案：描述了設計的組成部分之間的相互關系、職責和協(xié)

作方式。

效果：描述了模式應用的效果及使用模式應權衡的問題。

,設計模式在工程小組成員之間提供了通用的語義。

/設計模式可以更加簡單方便的復用成功的設計和體系結

構。

,設計模式有助于作出有利于系統(tǒng)復用的選擇，避免設計損

害系統(tǒng)復用性。

,設計模式可以幫助設計者更快更好的完成系統(tǒng)設計

1.9.3設計模式的分類創(chuàng)建型模式

創(chuàng)建型模式抽象了實例化過程。它們幫助一個系統(tǒng)獨立于如何創(chuàng)建、

組合和表示它的那些對象。

②結構型模式

結構型類模式采用繼承機制來組合按口或實現(xiàn)，描述了如何對一些對

象進行組合，從而實現(xiàn)新功能的一些方法。

③行為模式

行為模式涉及到算法和對象間職責的分配。行為模式不僅描述對象或

類的模式，還描述它們之間的通信模式。行為模式使用繼承機制在類間分

派行為。

1創(chuàng)建型模式

抽象工廠：提供一個創(chuàng)建一系列相關或相互依賴對象的接口，而無需

指定它們具體的類。

生成器：將一個復雜對象的構建與它的表示分離，使得同樣的構建過

程可以創(chuàng)建不同的表示。

工廠方法：定義一個用于創(chuàng)建對象的接口，讓子類決定實例化哪一個

類。FactoryMethod使一個類的實例化延遲到其子類。

原型：用原型實例指定創(chuàng)建對象的種類，并且通過拷貝這些原型創(chuàng)建

新的對象。

單一:保證一個類僅有一個實例，并提供一個訪問它的全句訪問點。

2結構型模式

適配器:將一個類的接口轉換成客戶希望的另外一個接口。Adapter模

式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作

橋接:將抽象部分與它的實現(xiàn)部分分離，使它們都可以獨立的變化

組合:將對象組合成樹形結構以表示“部分-整體”的層次結構。

Composite使得用戶單個對象和組合對象的使用具有一致性

裝飾:動態(tài)的給一個對象添加一些額外的職責。就增加功能來說，

Decorator模式相比生成子類更為靈活

外觀:為子系統(tǒng)中的一組接口提供一個一致的界面，F(xiàn)apade模式定義

了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用

享元:運用共享技術有效的支持大量細粒度的對象

代理：為其他對象提供一種代理以控制對這個對象的訪問

3行為型模式

職責鏈:使多個對象都有機會處理請求，從而避免請求的發(fā)送者和接

收者之間的耦合關系。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求,

直到有一個對象處理它為止。

命令:將一個請求封裝為一個對象，從而使你可用不同的請求對客戶

進行參數(shù)化；對請求排對或記錄請求日志，以及支持可撤銷的操作。

解釋器:給定一個語言，定義它的文法的一種表示，并定義一個解釋

器，這個解釋器使用該表示來解釋語言中的句子。

迭代器:提供一種方法順序訪問一個聚合對象中各個元素，而又不需

要暴露該對象的內部表示。

中介者:用一個中介對象來封裝一系列的對象交互。中介者使各對象

不需要顯式的相互引用，從而使其耦合松散，而且可以獨立的改變它們之

間的交互。

備忘錄:在不破壞封裝性的前提下，捕獲一個對象的內部狀態(tài)，并在

該對象之外保存這個狀態(tài)。這樣以后就可將該對象恢復到原先保存的狀

態(tài)0

1觀察者:定義對象間的一種一對多的依賴關系，當一個對象的狀態(tài)發(fā)

生改變時，所有依賴于它的對象都得到通知并被自動更新。

狀態(tài):允許一個對象在其內部狀態(tài)改變時改變它的行為。對象看起來

似乎修改了它的類。

萊略:允許々對象在其內部狀態(tài)改變時改變它的行為。

模板方法:定義一個操作中的算法的骨架，而將一些步驟延遲到子類

中。

訪問者:表示一個作用于某對象結構中的各元素的操作。

1.10數(shù)據(jù)庫設計數(shù)據(jù)庫設計步驟：

,需求分析

/概念設計

/邏輯設計

/物理設計

對數(shù)據(jù)庫進行質量控制方面劃分為：

/數(shù)據(jù)層的需求和構建

/數(shù)據(jù)字典設計數(shù)據(jù)庫

,數(shù)據(jù)流設計

1.11關于B/S和C/S架構的介紹

/jyy_1981/archive/2005/l0/12/500251.asp

X

一、什么是C/S和B/S

第一、什么是C/S結構。C/S(Client/Server)結構，即大家熟知

的客戶機和服務器結構。它是軟件系統(tǒng)體系結構，通過它可以充分利用兩

端硬件環(huán)境的優(yōu)勢，將任務合理分配到Client端和Server端來實現(xiàn)，降

低了系統(tǒng)的通訊開銷。目前大多數(shù)應用軟件系統(tǒng)都是Client/Server形式

的兩層結構，由于現(xiàn)在的軟件應用系統(tǒng)正在向分布式的Web應用發(fā)展，Web

和Client/Server應用都可以進行同樣的業(yè)務處理，應用不同的模塊共享

邏輯組件；因此，內部的和外部的用戶都可以訪問新的和現(xiàn)有的應用系統(tǒng),

通過現(xiàn)有應用系統(tǒng)中的邏輯可以擴展出新的應用系統(tǒng)。這也就是目前應用

系統(tǒng)的發(fā)展方向。

傳統(tǒng)的C/S體系結構雖然采用的是開放模式，但這只是系統(tǒng)開發(fā)一

級的開放性，在特定的應用中無論是Client端還是Server端都還需要特

定的軟件支持。由于沒能提供用戶真正期望的開放環(huán)境，C/S結構的軟件

需要針對不同的操作系統(tǒng)系統(tǒng)開發(fā)不同版本的軟件，加之產品的更新?lián)Q

代十分快，已經很難適應百臺電腦以上局域網用戶同時使用。而且代價高,

效率低。

第二、什么是B/S結構。B/S(Browser/Server)結構即瀏覽器和服

務器結構。它是隨著Internet技術的興起，對C/S結構的一種變化或者

改進的結構。在這種結構下，用戶工作界面是通過WWW瀏覽器來實現(xiàn)，極

少部分事務邏輯在前端(Browser)實現(xiàn)，但是主要事務邏輯在服務器端

(Server)實現(xiàn)，形成所謂三層3-tier結構。這樣就大大簡化了客戶端

電腦載荷，減輕了系統(tǒng)維護與升級的成本和工作量，降低了用戶的總體成

本(TC0)o以目前的技術看，局域網建立B/S結構的網絡應用，并通過

Internet/Intranet模式下數(shù)據(jù)庫應用，相對易于把握、成本也是較低的。

它是一次性到位的開發(fā)，能實現(xiàn)不同的人員，從不同的地點，以不同的接

入方式(比如LAN,WAN,Internet/Intranet等)訪問和操作共同的數(shù)據(jù)

庫；它能有效地保護數(shù)據(jù)平臺和管理訪問權限，服務器數(shù)據(jù)庫也很安全。

二、C/S和B/S之比較

C/S和B/S是當今世界開發(fā)模式技術架構的兩大主流技術。C/S是美

國Borland公司最早研發(fā)，B/S是美國微軟公同研發(fā)。

I、C/S架構軟件的優(yōu)勢與劣勢

(1)、應用服務器運行數(shù)據(jù)負荷較輕。最簡單的C/S體系結構的數(shù)據(jù)

庫應用由兩部分組成，即客戶應用程序和數(shù)據(jù)庫服務器程序。二者可分別

稱為前臺程序與后臺程序。運行數(shù)據(jù)庫服務器程序的機器，也稱為應用服

務器。一旦服務器程序被啟動，就隨時等待響應客戶程序發(fā)來的請求；客

戶應用程序運行在用戶自己的電腦上，對應于數(shù)據(jù)庫服務器，可稱為客戶

電腦，當需要對數(shù)據(jù)庫中的數(shù)據(jù)進行任何操作時，客戶程序就自動地尋找

服務器程序，并向其發(fā)出請求，服務器程序根據(jù)預定的規(guī)則作出應答，送

回結果，應用服務器運行數(shù)據(jù)負荷較輕。

(2)、數(shù)據(jù)的儲存管理功能較為透明。在數(shù)據(jù)庫應用中，數(shù)據(jù)的儲存

管理功能，是由服務器程序和客戶應用程序分別獨立進行的，前臺應用可

以違反的規(guī)則，并且通常把那些不同的(不管是已知還是未知的)運行數(shù)

據(jù)，在服務器程序中不集中實現(xiàn)，例如訪問者的權限，編號可以重復、必

須有客戶才能建立定單這樣的規(guī)則。所有這些，對于工作在前臺程序上的

最終用戶，是“透明”的，他們無須過問(通常也無法干涉)背后的過程,

就可以完成自己的一切工作。在客戶服務器架構的應用中，前臺程序不是

非?！笆菪　?，麻煩的事情都交給了服務器和網絡。在C/S體系的下，數(shù)

據(jù)庫不能真正成為公共、專業(yè)化的倉庫，它受到獨立的專門管理。

(3)、C/S架構的劣勢是高昂的維護成本且投資大。首先，采用C/S

架構，要選擇適當?shù)臄?shù)據(jù)庫平臺來實現(xiàn)數(shù)據(jù)庫數(shù)據(jù)的真正“統(tǒng)一”，使分

布于兩地的數(shù)據(jù)同步完全交由數(shù)據(jù)庫系統(tǒng)去管理，但邏輯上兩地的操作者

要直接訪問同一個數(shù)據(jù)庫才能有效實現(xiàn)，有這樣一些問題，如果需要建立

“實時”的數(shù)據(jù)同步，就必須在兩地間建立實時的通訊連接，保持兩地的

數(shù)據(jù)庫服務器在線運行，網絡管理工作人員既要對服務器維護管理，又要

對客戶端維護和管理，這需要高昂的投資和復雜的技術支持，維護成本很

高，維護任務量大。

其次，傳統(tǒng)的C/S結構的軟件需要針對不同的操作系統(tǒng)系統(tǒng)開發(fā)不同

版本的軟件，由于產品的更新?lián)Q代十分快，代價高和低效率已經不適應工

作需要。在JAVA這樣的跨平臺語言出現(xiàn)之后，B/S架構更是猛烈沖擊C/S,

并對其形成威脅和挑戰(zhàn)。

2、B/S架構軟件的優(yōu)勢與劣勢

(1)、維護和升級方式簡單。目前，軟件系統(tǒng)的改進和升級越來越頻

繁，B/S架構的產品明顯體現(xiàn)著更為方便的特性。對一個稍微大一點單位

來說，系統(tǒng)管理人員如果需要在幾百良至上千部電腦之間來回奔跑，效率

和工作量是可想而知的，但B/S架構的軟件只需要管理服務器就行了，所

有的客戶端只是瀏覽器，根本不需要做任何的維護。無論用戶的規(guī)模有多

大，有多少分支機構都不會增加任何維護升級的工作量，所有的操作只需

要針對服務器進行；如果是異地，只需要把服務器連接專網即可，實現(xiàn)遠

程維護、升級和共享。所以客戶機越來越“瘦”，而服務器越來越“胖”

是將來信息化發(fā)展的主流方向。今后，軟件升級和維護會越來越容易，而

使用起來會越來越簡單，這對用戶人力、物力、時間、費用的節(jié)省是顯而

易見的，驚人的。因此，維護和升級革命的方式是“瘦”客戶機，“胖”

服務器。

(2)、成本降低，選擇更多。大家都知道windows在桌面電腦上幾乎

一統(tǒng)天下，瀏覽器成為了標準配置，但在服務器操作系統(tǒng)上windows并不

是處于絕對的統(tǒng)治地位。現(xiàn)在的趨勢是凡使用B/S架構的應用管理軟件，

只需安裝在Linux服務器上即可，而且安全性高。所以服務器操作系統(tǒng)的

選擇是很多的，不管選用那種操作系統(tǒng)都可以讓大部分人使用windows作

為桌面操作系統(tǒng)電腦不受影響，這就使的最流行免費的Linux操作系統(tǒng)快

速發(fā)展起來，Linux除了操作系統(tǒng)是免費的以外，連數(shù)據(jù)庫也是免費的，

這種選擇非常盛行。

(3)、應用服務器運行數(shù)據(jù)負荷較重。由于B/S架構管理軟件只安裝

在服務器端(Server)上，網絡管理人員只需要管理服務器就行了，用戶

界面主要事務邏輯在服務器(Server)端完全通過WWW瀏覽器實現(xiàn)，極少

部分事務邏輯在前端(Browser)實現(xiàn)，所有的客戶端只有瀏覽器，網絡

管理人員只需要做硬件維護。但是，應用服務器運行數(shù)據(jù)負荷較重，一旦

發(fā)生服務器“崩潰”等問題，后果不堪設想。因此，許多單位都備有數(shù)據(jù)

庫存儲服務器，以防萬一。

1.12下一代軟件架構——SOA

/CSDN_document/archive/2004/10/29/15831

1.aspx

Web服務的特點

?強自治：Web服務是可重用的軟件模塊。

?松耦合：只需要很簡單的協(xié)調，并允許更自由的配置。

?粗粒度：一個Web服務就是一個自包含的“小程序；完成單個的

任務。

一?。開放性：Web服務所有公共協(xié)約完全使用開放的標準協(xié)議進行

描述、傳輸和交換。

?可集成：屏蔽了不同軟件平臺的差異。

Web服務作為炙手可熱的技術，如何應用到企業(yè)的IT系統(tǒng)和商業(yè)流程

之中、并給企業(yè)帶來直接的經濟效益，一直備受國內外企業(yè)管理者的高度

關注和推崇。而在近兩年，出現(xiàn)了一種技術架構被譽為下一代Web服務的

基礎架構，它就是SOA(Service-orientedarchitecture,面向服務架構)。

1996年,Gartner最早提出SOA。2002年12月,Gartner提出SOA是"現(xiàn)

代應用開發(fā)領域最重要的課題”，還預計到2008年，SOA將成為占有絕對

優(yōu)勢的軟件工程實踐方法，主流企業(yè)現(xiàn)在就應該在理解和應用SOA開發(fā)技

能方面進行投資。

更好支持商業(yè)流程

SOA并不是一個新事物，IT組織已經成功建立并實施S0A應用軟件很

多年了，BEA、IBM、等廠商看到了它的價值，紛紛跟進。S0A的目標在于

讓IT變得更有彈性，以更快地響應業(yè)務單位的需求，實現(xiàn)實時企業(yè)

（Real-TimeEnterprise,這是Gartner為SOA描述的愿景目標）。而BEA

的CIORhonda早在2001年6月就提出要將BEA的IT基礎架構轉變?yōu)镾OA,

并且從對整個企業(yè)架構的控制能力、提升開發(fā)效率、加快開發(fā)速度、降低

在客戶化和人員技能的投入等方面取得了不錯的成績。

SOA是在計算環(huán)境下設計、開發(fā)、應用、管理分散的邏輯（服務）單

元的一種規(guī)范。這個定義決定了SOA的廣泛性。SOA要求開發(fā)者從服務集

成的角度來設計應用軟件，即使這么做的利益不會馬上顯現(xiàn)。SOA要求開

發(fā)者超越應用軟件來思考，并考慮復用現(xiàn)有的服務，或者檢查如何讓服務

被重復利用。SOA鼓勵使用可替代的技術和方法（例如消息機制），通過把

服務聯(lián)系在一起而非編寫新代碼來構架應用。經過適當構架后，這種消息

機制的應用允許公司僅通過調整原有服務模式而非被迫進行大規(guī)模新的

應用代碼的開發(fā)，使得在商業(yè)環(huán)境許可的時間內對變化的市場條件做出快

速的響應。

SOA也不僅僅是一種開發(fā)的方法論一一它還包含管理。例如，應用SOA

后，管理者可以方便的管理這些搭建在服務平臺上的企業(yè)應用，而不是管

理單一的應用模塊。其原理是，通過分析服務之間的相互調用，SOA使得

公司管理人員方便的拿到什么時候、什么原因、哪些商業(yè)邏輯被執(zhí)行的數(shù)

據(jù)信息，這樣就幫助了企業(yè)管理人員或應用架構師迭代地優(yōu)化他們的企業(yè)

業(yè)務流程、應用系統(tǒng)。

SOA的一個中心思想就是使得企業(yè)應用擺脫面向技術的解決方案的束

縛，輕松應對企業(yè)商業(yè)服務變化、發(fā)展的需要。［11］企業(yè)環(huán)境中單個應

用程序是無法包容業(yè)務用戶的（各種）需求的，即使是一個大型的ERP解

決方案，仍然不能滿足這個需求在不斷膨脹、變化的缺口，對市場快速做

出反應，商業(yè)用戶只能通過不斷開發(fā)新應用、擴展現(xiàn)有應用程序來艱難的

支撐其現(xiàn)有的業(yè)務需求。通過將注意力放在服務上，應用程序能夠集中起

來提供更加豐富、目的性更強的商業(yè)流程。其結果就是，基于SOA的企業(yè)

應用系統(tǒng)通常會更加真實地反映出與業(yè)務模型的結合。服務是從業(yè)務流程

的角度來看待技術的一一這是從上向下看的。這種角度同一般的從可用技

術所驅動的商業(yè)視角是相反的。服務的優(yōu)勢很清楚：它們會同業(yè)務流程結

合在一起，因此能夠更加精確地表示業(yè)務模型、更好地支持業(yè)務流程。相

反我們可以看到以應用程序為中心的企業(yè)應用模型迫使業(yè)務用戶將其能

力局限為應用程序的能力。

企業(yè)流程（enterpriseprocess）是流經企業(yè)框架的空氣，它賦予業(yè)

務模型里的組件以生命，并更加清晰地定義了它們之間的關系。流程定義

了同業(yè)務模型進行交互操作的專門方法。例如，會計可能是企業(yè)服務系統(tǒng)

的一個組件一一但是將發(fā)票寄給客戶卻是一個業(yè)務流程。服務被定義用來

支持業(yè)務流程，因而貫穿整個流程始終的是：各種服務組件在流程和邏輯

實現(xiàn)過程中的裝配操作。理解業(yè)務流程是定制服務的關鍵所在。

有利于企業(yè)業(yè)務的集成

傳統(tǒng)的應用集成方法（點對點集成、企業(yè)消息總線或中間件的集成

（EAI）、基于業(yè)務流程的集成）都很復雜、昂貴，并且不靈活。這些集成

方法難于快速適應基于企業(yè)現(xiàn)代業(yè)務變化不斷產生的需求。基于面向服務

架構（SOA）的應用開發(fā)和集成可以很好的解決其中的許多問題。

SOA描述了一套完善的開發(fā)模式來幫助客戶端應用連接到服務上。這

些模式定制了系列機制用于描述服務、通知及發(fā)現(xiàn)服務、與服務進行通信。

不同于傳統(tǒng)的應用集成方法，在SOA中，圍繞服務的所有模式都是

以基于標準的技術實現(xiàn)的。大部分的通信中間件系統(tǒng)，如即C、CORBA、

DCOM、EJB和RMI,也同樣如此。可是它們的實現(xiàn)都不是很完美的，在權

衡交互性以及標準定制的可接受性方面總是存在問題。SOA試圖排除這些

缺陷。因為幾乎所有的通信中間件系統(tǒng)都有固定的處理模式，如RPC的功

能、CORBA的對象等等。然而，服務既可以定義為功能，又可同時對外定

義為對象、應用等等。這使得SOA可適應于任何現(xiàn)有系統(tǒng)，并使得系統(tǒng)

在集成時不必刻意遵循任何特殊定制。

SOA幫助企業(yè)信息系統(tǒng)遷移到“l(fā)eave-and-layer”架構之上，這意

著

味

DT+工FlI/玄①/th力攵：3卜附不+日卞玄也可對外提供Web服

接

務

］的應用層做了一層

裝

封

可以將系統(tǒng)和應用迅

轉

速

立用和遺留系統(tǒng)中的

息

信

IT架構中的功能和

據(jù)

數(shù)

以務架構中添加功能,

所1

\世業(yè)務部門設計開發(fā)

新

出

見圖。與傳統(tǒng)的企業(yè)

應用順務，并包括過程/

數(shù)據(jù)內集成點。服務的編

排和

圖示：使用基于服務集成的企業(yè)應用

SOA服務粒度

可以按基于服務的功能及發(fā)送和接收的數(shù)據(jù)數(shù)量來定義服務，如細粒

度服務、粗粒度服務或組合服務。

在SOA中服務粒度有兩種相關的意思：服務是如何實現(xiàn)的，服務使

用和返回了多少數(shù)據(jù)或多少消息。細粒度服務執(zhí)行了最小的功能，發(fā)送和

接收少量的數(shù)據(jù)。粗粒度服務執(zhí)行了較大的業(yè)務功能，并交換了更多的數(shù)

據(jù)。

細粒度服務是供粗粒度服務或組合服務使用的，而不是由終端應用直

接使用的。如果應用是使用細粒度服務建立的，則應用將不得不調用網絡

上多個服務，并且發(fā)生在每個服務上的數(shù)據(jù)量較少，因而會對對系統(tǒng)整體

性帶來影響。所以粗粒度服務的用戶不能直接調用他所使用的細粒度服

是

不

在

這

M

CR

這

需

據(jù)

線

圖?。悍樟６?/p>

通過一組有效設計和組合的粗粒度服務，業(yè)務專家就能夠有效地組合

出新的業(yè)務流程和應用程序了。

SOA與Web服務

SOA不是一定需要Web服務來實現(xiàn)，并且一個基于Web服務開發(fā)出

來的應用也不代表就是一個基于SOA構架應用。Web服務只是服務實現(xiàn)

的一個典型，是實現(xiàn)企業(yè)SOA的一個組件（非必需組件）。SOA為基于服

務的分布式系統(tǒng)提供了概念上的設計模式。Web服務則是基于標準的、可

經濟實惠地實現(xiàn)SOA的一項技術。[12]

SOA將IT資源透過服務這樣一個在業(yè)務上有重要涵義的概念來提供、

共享，把IT與業(yè)務的距離更加拉近了一步。服務在涉及的層次上要比組

件、函數(shù)、流程等更高，而且往往在業(yè)務上可以找到與之直接對應的概念

或實體，例如報價、訂單。服務打破了IT系統(tǒng)間的藩籬，就像一家公司

的各個部門，平常各自扮演特定對內或對外服務的角色，但彼此間如果能

有效地通過共通的語言及文字，進行良好的溝通，便能協(xié)力達成更大、更

局的目標。

隨著SOA和Web服務的潮流，帶來了組合式應用（composite

application）的開發(fā)方式和觀念，開始逐漸被大量應用在Portal（門戶）

和Integration（集成）上。組合式Portal的做法，就是通過Portal界

面所提供的應用，往往不是真的在Portal服務器上執(zhí)行，而是將Web服

務即時抓過來，再加以呈現(xiàn)，同時匯總給Portal的使用者。在整合方面

也是采用組合式的方式。通過高級工具來設定，使系統(tǒng)得以靈活地配合任

務的調整,對各項以Web服務方式提供的服務進行不同形式的串聯(lián)和協(xié)作,

同時快速地加以部署。2004年3月，BEA發(fā)布了一個企業(yè)門戶合理化

（enterpriseportalrationalization,EPR）戰(zhàn)略，這個戰(zhàn)略用來平衡

BEAWebLogicPlatform的SOA能力，憑借最好的行業(yè)實踐和行業(yè)專家，

幫助客戶解決多年來形成的散亂的portal和Web應用程序開發(fā)。

如果說Web服務等技術是SOA的血肉，那么正確的服務設計理念及系

統(tǒng)運行平臺則是SOA的靈魂。SOA試圖讓IT能更快和業(yè)務同步，在規(guī)劃上

以提供彈性的業(yè)務服務為目標。從CIO到負責規(guī)劃的系統(tǒng)分析人員，需要

和業(yè)務單位、策略伙伴間有充分的溝通。CIO必須認識到，SOA的建立將

是一個為期數(shù)年的承諾，基礎建設需要按部就班地進行，資助的模式也必

須在IT和各個業(yè)務部門間建立，來陸續(xù)支援基礎建設及各項業(yè)務服務的

開發(fā)。

在中間件領域，SOA架構日益成為中間件軟件供應商爭奪的新焦點。

誰都希望自己能夠先于競爭對手提供最優(yōu)的SOA技術實現(xiàn)平臺，BEA也不

例外。從技術上來說，Web服務、組件技術的采用將有助于SOA的進一步

普及，從業(yè)務上來說，企業(yè)用戶要求性價比更高的應用系統(tǒng)，SOA恰恰適

應了這樣的趨勢。

1.13RIA富互聯(lián)網應用

/view/706341.htm?fr=alaO_l_l

什么是RIA?

RIA(RichInternetApplications)富互聯(lián)網應用，是一種富客

戶端開發(fā)技術，它結合了C/S客戶端的強大功能和B/S結構的低成本

高效率的優(yōu)點。具有高度互動性、豐富用戶體驗以及功能強大的客戶

端，屬于客戶端呈現(xiàn)技術。

1.13.1RIA的優(yōu)勢

RIA具有的桌面應用程序的特點包括：在消息確認和格式編排方

面提供互動用戶界面；在無刷新頁面之下提供快捷的界面響應時間；

提供通用的用戶界面特性如拖放式(draganddrop)以及在線和離線

操作能力。RIA具有的Web應用程序的特點包括如：立即部署、跨平

臺、采用逐步下載來檢索內容和數(shù)據(jù)以及可以充分利用被廣泛采納的

互聯(lián)網標準。RIA具有通信的特點則包括實時互動的聲音和圖像。

客戶機在RIA中的作用不僅是展示頁面，它可以在幕后與用戶請

求異步地進行計算、傳送和檢索數(shù)據(jù)、顯示集成的用戶界面和綜合使

用聲音和圖像，這一切都可以在不依靠客戶機連接的服務器或后端的

情況下進行。

對于企業(yè)來說，部署RIA的好處在于：

1)RIA可以繼續(xù)使用現(xiàn)有的應用程序模型(包括J2EE和.NET),

因而無需大規(guī)模替換現(xiàn)有的Web應用程序。通過RichClient技術，

可以輕松構建更為直觀、易于使用、反應更迅速并且可以脫機使用的

應用程序。

2)RIA可以幫助企業(yè)提供多元化的重要業(yè)務效益，包括提高銷量、

提高品牌忠誠度、延長網站逗留時間、較頻繁的重復訪問、減少帶寬

成本、減少支持求助以及增強客戶關系等。

L13.2發(fā)展態(tài)勢

在過去的兩到三年中，Web開發(fā)人員一直是想構建一種比傳統(tǒng)HT

ML更豐富的客戶端：這是一個用戶接口，它比用HTML能實現(xiàn)的接口

更加健壯、反應更加靈敏和更具有令人感興趣的可視化特性。RIA技

術的出現(xiàn)允許我們在因特網上以一種像使用Web一樣簡單的方式來部

署富客戶端程序。無論將來RIA是否能夠如人們所猜測的那樣完全代

替HTML應用系統(tǒng)，對于那些采用C/S架構的胖客戶端技術運行復雜應

用系統(tǒng)的機構和采用基于B/S架構的瘦客戶端技術部署Web應用系統(tǒng)

地機構來說，RIA確實提供了一種廉價的選擇。下面介紹一下目前出

現(xiàn)的幾種比較有實力或者有特點的RIA客戶端開發(fā)技術：

1）!MacromediaFlash/Flex

Flash從6.0開始Flash就逐步具備建立窗體風格的應用程序的

功能。據(jù)Macromedia稱已經有98%以上的桌面系統(tǒng)的瀏覽器都安裝

了MacromediaFlashPlayero這使得以MacromediaFlashPlayer

為客戶端的RIA可以支持種類廣泛的平臺和設備。

Flex是為滿足希望開發(fā)RIA的企業(yè)級程序員的需求而推出的表

示服務器和應用程序框架，它可以運行于J2EE和.NET平臺。Flex表

示服務器提供基于標準的、聲明性的編程方法和流程，并提供運行時

服務，用于開發(fā)和部署豐富客戶端應用程序的表示層。Flex開發(fā)者使

用直觀的基于XML的MXML來定義豐富的用戶界面。該語言由Flex服

務器翻譯成SWF格式的客戶端應用程序，在FlashPlayer中運行。

2）!Laszlo

Laszlo是一個開源的RIA開發(fā)環(huán)境。使用Laszlo平臺時，開發(fā)

者只需編寫名為LZX的描述語言（其中整合了XML和Javascript）,

運行在J2EE應用服務器上的Laszlo平臺會將其編譯成SWF格式的文

件并傳輸給客戶端展示。從這點上來說，Laszlo的本質和Flex是一

樣的。Flash是任何瀏覽器都支持的展示形式，從而一舉解決了瀏覽

器之間的移植問題。而且，在未來的計劃中，Laszlo還可以將LZX編

譯成Java或.NET本地代碼，從而大大提高運行效率。（Red5使用）

3）Avalon

Microsoft的Avalon是下一版本的Windows（代號"Longhorn"）

的一部分，是一個圖形和展示引擎，主要由新加到.NET框架中的一組

類集合而成。Avalon定義了一個在Longhorn中使用的新標記語言，

其代號為“XAML〃（可擴展應用程序標記語言）?？梢允褂肵AML來定義

文本、圖像和控件的布局，程序代碼可以直接嵌入到XAML中，也可以

將它保留在一個單獨的文件內。這與Flex中的MXML或者Laszlo中的

LZX非常相似。不同的是：基于Avalon的應用程序必須運行在Longh

orn環(huán)境中，而Flex和Laszlo是不依賴于平臺的，僅僅需要裝有F1

ash播放器的瀏覽器即可。

4）!JavaSWT

Java已經出現(xiàn)幾年了，并且完全支持創(chuàng)建基于窗體的用戶界面。

除了Java基礎類（JFC/Swing）中的用戶界面組件之外，開發(fā)人員還

可以使用來自于EclipseProject的SWT工具箱和許多第三方工具箱

進行開發(fā)。對于圖形來說，可以采用Java2DAPI：一個非常完整且

非常復雜的圖形API。你可以通過一個Web瀏覽器使用Java插件軟件,

或使用Java運行時環(huán)境中較新的JavaWebStart技術來部署應用程

序。使用Java建立RichClient的主要缺陷是它的復雜性（即使對簡

單的窗體㈣圖形也要求編寫非常煩瑣的代碼）和Java瀏覽器插件的低

市場占有率。

5）XUL

XUL（念作"zool"）是一種基于XML的用戶界面語言，它來自于

Mozilla的開放源碼項目。它可用于建立窗體應用程序，這些應用程

序不但可以在Mozilla瀏覽器上運行，而且也可以運行在其他描述引

擎上，如Zulu（一個FlashMX組件）和Thinleys（一個Java實現(xiàn)）。

XUL描述引擎都非常?。?00K以下），它可以使用XML數(shù)據(jù)也可以生成

XML數(shù)據(jù)。XUL的一個主要缺點在于它目前還沒有獲得一個主要商業(yè)實

體的支持。XUL最大的優(yōu)點在于它與Gecko引擎的集成（打開了通向

大量Web標準的大門），以及與大多數(shù)其它XML用戶界面描述語言相比

它是一種非常具有表達力和簡潔的語言。

6）Bindows

Bindow是用Javascript和DHTML開發(fā)的Web窗體框架。Javasc

ript用于客戶端界面的顯示和處理，XMLHTTP用于客戶端與服務器的

信息傳輸。Javascript在客戶端的表現(xiàn)力不容置疑，利用Javascrip

t幾乎可以實現(xiàn)Windows應用程序所能干的大部分事情，XMLHTTP—

直以來常被用于實現(xiàn)“無刷新〃的Web頁面，它和Javascript配合，

可以完成數(shù)據(jù)從服務器和客戶端的傳輸。Bindows的一個主要的缺點

是它采用一次全部載入的方式來實現(xiàn)腳本庫，在窗口的加載期，需要

一個漫長的等待過程，甚至瀏覽器的進程會產生無響應的情況。這點

Bindows根本沒有遵循〃用多少去多少〃的準則。另外，內部大量利用

了IE6的技術，沒有考慮到非IE的瀏覽器，限制了Bindows的流行。

7）!JavaFX

2008年12月05日Sun微系統(tǒng)公司今天正式發(fā)布了基于Java語

言的平臺JavaFXlo0,這個平臺建立在其廣泛應用的Java編程語言

的基礎上，旨在建立大量可在電腦和手機上運行的網絡程序。Java

一直以來就是編程語言，但是隨著JavaFX的發(fā)布，Sun公司開始允許

將編程內容創(chuàng)新這一任務轉移到以設計藝術為重點而非編程科學為重

點的設計人員身上。

/我們的目標群體是叫做創(chuàng)造者的人群'；Sun公司Java平臺組的

高級副主任OctavianTanase對InternetN說，"隨著1.0版的

發(fā)布，我們將目標鎖定在網頁開發(fā)人員，這群可能拓展Java界面體驗

的人。到2011年，主要的目標是大量使用諸如Adobe系統(tǒng)等設計工具

的設計人員：

當然，通向這個以設計為導向的工具還需要一些時間。Sun公司

最后打算提供自己的程序給設計人員來建立RIAS,但是直到如今，這

些設計人員還得使用程序員所使用的Netbeans或Eclipse集成開發(fā)環(huán)

境（IDE）。新工具將在來年夏天面市。

8）Curl

Curl誕生于1995年的美國，Curl是由美國國防部高級研究項目

代理資助，馬薩諸塞州科技學院的DavidA.Kranz開發(fā)的Web開發(fā)語

言，HTML語言的創(chuàng)建者TimBerners-Lee也參與其中，并扮演了重

要的角色。

該語言的目標是用一種統(tǒng)一的面向對象的語言代替HTML、Cascad

ingStyleSheets,JavaScript等；僅使用Curl便可開發(fā)出Web應

用的各種軟件；Curl程序在瀏覽器中運行，并且因為它以類似JRE的

形式提供了客戶端運行環(huán)境SurgeRTE,能夠輕松開發(fā)出日益流行的R

ichClient應用程序。

Curl是為了實現(xiàn)富客戶端（richclient）應運而生的Web開發(fā)

語言，僅僅從其外觀的豐富性上就能體現(xiàn)其富客戶端理念。

為了實現(xiàn)真正有益的富客戶端，它能有效地實現(xiàn)各種復雜處理，

具備提供高信賴、高擴展性、高維護性的應用程序所應擁有的各種編

碼能力。其擁有在Web環(huán)境上便利的分配、管理以及低廉的維護費以

及在C/S環(huán)境上的用戶便利性、迅速的應答，華麗的圖像顯示等重多

優(yōu)點于一身。

Curl語言于2002年在美國正式開始商業(yè)化，在美國和日本擁有

重多的客戶和合作伙伴，現(xiàn)已進軍北美及韓國市場，發(fā)展勢頭迅猛。

9）!SilverLight

微軟在Mix07上發(fā)布一些重大通告，其中最值得關注的就是Silv

erLight的發(fā)布，SilverLight的前身就是WPF/E技術。

這是一種新的Web呈現(xiàn)技術的名稱，創(chuàng)建該技術的目的是使其能

夠在各種平臺上運行。該技術支持創(chuàng)建豐富的、具有絢麗視覺效果的

交互式體驗，并且可以隨處實現(xiàn)：無論是在瀏覽器內、在多個設備上

還是在桌面操作系統(tǒng)（如AppleMacintosh）中。可擴展應用程序標

記語言（XAML）遵循Windows演示基礎（WPF）,前者是“WPF/E”呈現(xiàn)

功能的基礎。XAML是Microsoft.NETFramework3.0（Windows編

程基礎結構）中的呈現(xiàn)技術。

1.13.3RIA未來的發(fā)展預測

就目前RIA的使用情況來說，離〃RIA時代〃還有很遠的一段距離。

今后幾年時間內傳統(tǒng)的Web應用程序和RIA將會共存。筆者認為真正

具有實力擔當起普及豐富客戶端應用重任的只有基于FlashPlayer

的Flash/Flex應用程序和Microsoft的基于Avalon的應用程序。短

期時間內（估計2-3年時間）可能是Flash/Flex應用程序在新興的

網絡應用程序市場上占有主導地位。

目前Microsoft還在推廣一種叫做SmartClient（智能客戶端）

的客戶端程序技術，Microsoft稱SmartClient是比RichClient更

優(yōu)秀的客戶端，因而采用SmartClient的應用程序算不算RIA目前我

個人還無法作答。這里我們之所以提及SmartClient,是因為Smart

Client的特性跟我們談的RichClient有太多的相似之處。SmartCl

ient擁有自動更新、離線狀態(tài)下的數(shù)據(jù)處理和可以使用本地資源等特

征，其中的可使用本地資源這一項無疑是一大賣點，因為瀏覽器中的

Flash/Flex應用程序目前還無法操作本地的一些資源，比如Flash/F

lex應用程序無法將網上的文件保存到本地或者修改本地文件。雖然

Macromedia的Centrail.5已經可以對本地文件進行簡單的操作，并

且Flexl.5開發(fā)的RIA也能夠運行于Central上，但是如何使Centra

1能夠得到大范圍推廣還是個問題。相對于輕量級的RichClient,S

martClient更接近C/S架構中的客戶端程序°RichClient和Smart

Client的定位還是有所區(qū)別的：RichClient更適合作為輕量級的基

于瀏覽器的網絡應用程序客戶端；SmartClient更適合作為Windows

桌面應用程序的智能客戶端。

不管我們今天稱之為的RIA今后會不會成為主流應用程序，人們

對開發(fā)具有高度互動性、豐富用戶體驗以及功能強大的客戶端的追求

是不變的。有理由相信，擁有成熟技術和極高市場占有率的Flash客

戶端將會在RIA道路上越走越遠。Microsoft未來的重量級武器：Ava

Ion和SmartClient能否后來者居上讓我們拭目以待。

L14MVC設計模型(體系)

/ANALYZE/200712291011101306.htm

http:〃作者：林善茂來源：賽迪網2007年12月

29日

1前言

用戶界面，特別是圖形用戶界面，承擔著向用戶顯示問題模型和與用

戶進行操作和I/O交互的作用。用戶希望保持交互操作界面的相對穩(wěn)定，

但更希望根據(jù)需要改變和調整顯示的內容和形式。例如，要求支持不同的

界面標準或得到不同的顯示效果，適應不同的操作需求。這就要求界面結

構能夠在不改變軟件的功能和模型情況下，支持用戶對界面構成的調整。

要做到這一點，從界面構成的角度看，困難在于：在滿足對界面要求

的同時，如何使軟件的計算模型獨立于界面的構成。模型-視圖-控制(MVC:

Model-View-ControIler)就是這樣的一種交互界面的結構組織模型。

2MVC(Model-View-Control)

MVC由TrygveReenskaug提出，首先被應用在SmallTalk-80環(huán)境中，

是許多交互和界面系統(tǒng)的構成基礎,Microsoft的MFC基礎類也遵循了MVC

的思想。

對于界面設計可變性的需求，MVC把交互系統(tǒng)的組成分解成模型、視

圖、控制三種部件。

模型部件是軟件所處理問題邏輯在獨立于外在顯示內容和形式情況

下的內在抽象，封裝了問題的核心數(shù)據(jù)、邏輯和功能的計算關系，他獨立

于具體的界面表達和I/。操作。

視圖部件把表示模型數(shù)據(jù)及邏輯關系和狀態(tài)的信息及特定形式展示

給用戶。它從模型獲得顯示信息，對于相同的信息可以有多個不同的顯示

形式或視圖。

控制部件是處理用戶與軟件的交互操作的，其職責是控制提供模型中

任何變化的傳播，確保用戶界面于模型間的對應聯(lián)系；它接受用戶的輸入,

將輸入反饋給模型，進而實現(xiàn)對模型的計算控制，是使模型和視圖協(xié)調工

作的部件。通常一個視圖具有一個控制器。

模型、視圖與控制器的分離，使得一個模型可以具有多個顯示視圖。

匚口出IQQZUTTTK4?注:rnI占、殺h+FP二匚七?士才rrFMT/么"「些

欖型類視圖類

數(shù)據(jù)結構和關系制小形式

狀太

程圖和控■,器的注圖大系顯示模式控器模

內部政求和1E林ilR從模型狹打數(shù)據(jù)控控

向ft!圖和捽制器通然故抵登化膽留小》HM1控制現(xiàn)圖如斯

圖IYYC中的模型、視圖和控制類

(1)模型包含了應用問題的核心數(shù)據(jù)、邏輯關系和計算功能，它封

裝了所需的數(shù)據(jù)，提供了完成問題處理的操作過程。控制器依據(jù)I/O的需

要調用這些操作過程。模型還為視圖獲取顯示數(shù)據(jù)而提供了訪問其數(shù)據(jù)的

操作。

務種變化-傳播機制體現(xiàn)在各個相互依賴部件之間的注冊關系上。模

型數(shù)據(jù)和狀態(tài)的變化會激發(fā)這種變化-傳播機制，它是模型、視圖和控制

器之間聯(lián)系的紐帶。

(2)視圖通過顯示的形式，把信息轉達給用戶。不同視圖通過不同

的顯示，來表達模型的數(shù)據(jù)和狀態(tài)信息。每個視圖有一個更新操作，它可

被變化-傳播機制所激活。當調用更新操作時，視圖獲得來自模型的數(shù)據(jù)

值，并用它們來更新顯示。

在初始化時，通過與變化-傳播機制的注冊關系建立起所有視圖與模

圖2MVC的實現(xiàn)過程