需求分析與系統(tǒng)設(shè)計

1、需求分析與系統(tǒng)設(shè)計 第9章 程序和事務(wù)設(shè)計 我們區(qū)分系統(tǒng)設(shè)計和程序設(shè)計。程序設(shè)計是系統(tǒng)設(shè)計中模擬程序的執(zhí)行邏輯，定義客戶機服務(wù)器對象合作的框架的那個部分。IS程序執(zhí)行業(yè)務(wù)事務(wù)。假設(shè)一個事務(wù)的范圍定義在程序之內(nèi)的話，它就是DBMS可以維持的數(shù)據(jù)庫一致性的一個單元。 第9章 程序和事務(wù)設(shè)計 程序和事務(wù)設(shè)計將系統(tǒng)設(shè)計制品放在一起，并作為系統(tǒng)設(shè)計過程的最終階段。它將應(yīng)用邏輯賦給GUI和數(shù)據(jù)庫設(shè)計。它的結(jié)果是給程序員提供足夠的程序設(shè)計指令，使他們能開始“裁剪代碼”的設(shè)計文檔。事實上，一些初步的代碼可以從設(shè)計中自動生成（前向工程）。程序員對初始代碼的擴展?？梢阅嫦蚧厮莸皆O(shè)計階段，從而得到一個“雙向”工程的

2、周期。 第9章 程序和事務(wù)設(shè)計 9.1設(shè)計程序 9.2程序?qū)Ш?9.3設(shè)計事務(wù) 9.4雙向工程 9.1設(shè)計程序 程序設(shè)計是完整的系統(tǒng)設(shè)計（第6章、7章和第8章）的一個內(nèi)在部分。類包和構(gòu)件的體系結(jié)構(gòu)設(shè)計建立通用的執(zhí)行框架。GUI和數(shù)據(jù)庫的詳細設(shè)計說明這個框架的前端和后端。程序設(shè)計填充通用框架中間的空缺，并將它轉(zhuǎn)換為可以交給程序員去進行開發(fā)的設(shè)計文檔。 9.1設(shè)計程序 程序設(shè)計一次集中在一個應(yīng)用程序上。在這個意義上，程序設(shè)計是在第7章中討論的用戶界面設(shè)計的直接擴展。程序設(shè)計使用數(shù)據(jù)庫設(shè)計的部分（子框架）（第8章），它還定義數(shù)據(jù)庫過程方向的內(nèi)容：存儲過程和專用程序觸發(fā)器。 9.1設(shè)計程序 程序的執(zhí)行

3、邏輯劃分為客戶機和服務(wù)器過程。客戶機過程具體化程序中大多數(shù)的動態(tài)對象合作（6.2節(jié)）。對象內(nèi)聚和耦合（9.1.1節(jié)）的適當(dāng)?shù)钠胶饪梢砸种坪献鞯膹?fù)雜度。尤其是，服務(wù)器過程更注重執(zhí)好由客戶機過程啟動的業(yè)務(wù)事務(wù)。 9.1設(shè)計程序9.1.1類的內(nèi)聚和耦合 9.1.2設(shè)計客戶機服務(wù)器合作 9.1.1類的內(nèi)聚和耦合 前面，特別是在第 5章和第 6章中，我們已經(jīng)給出了好的程序設(shè)計的主要原理，雖然那是在好的系統(tǒng)設(shè)計的意義下說的。類分層是寫出可理解、可維護的以及可控規(guī)模程序的基礎(chǔ)。一旦將面向?qū)ο蟮某绦蚪唤o投入者，該程序便會變成遺產(chǎn)程序。正確地使用繼承和代理對避免這種情況是必需的。 9.1.1類的內(nèi)聚和耦合 好的

4、程序設(shè)計要保證類的內(nèi)聚和耦合的良好平衡。內(nèi)聚和耦合這兩個術(shù)語是由結(jié)構(gòu)化設(shè)計方法創(chuàng)造的。然而，這兩個術(shù)語在面向?qū)ο笤O(shè)計中具有相似的內(nèi)涵和重要性。 類內(nèi)聚是類的內(nèi)部自我確定的程度，它度量類不與外界相關(guān)的強度。一個具有高內(nèi)聚的類可以自己執(zhí)行一個行為，或者達到一個單一的目標(biāo)。內(nèi)聚越強越好。 9.1.1類的內(nèi)聚和耦合 類耦合是類之間的關(guān)聯(lián)程度，它度量類的相互關(guān)系。耦合越弱越好（然而，類有時不得不“耦合”以便合作工作）。 內(nèi)聚和耦合相互是不一致的。好的內(nèi)聚意味著弱的耦合，反過來也一樣。設(shè)計者的任務(wù)是使這兩者之間達到一個最好的平衡。 9.1.1類的內(nèi)聚和耦合 啟發(fā)式規(guī)則 ：兩個類應(yīng)該要么不依賴于另一個，要么

5、一個類應(yīng)該只依賴于另一個類的公共接口。屬件和與之相關(guān)的方法應(yīng)該保存在同一個類中（這個啟發(fā)式常常被其定義在公共接口許多存取者（get和set）方法所破壞）。一個類應(yīng)該捕獲一個且只捕獲一個抽象。無關(guān)的信息，當(dāng)其方法的一個子集作用到屬性的一個真子集上，應(yīng)該移到另一個類中。系統(tǒng)的智能應(yīng)該盡可能一致地分布（從而使得類能夠一致地分擔(dān)同一項工作）。 9.1.1類的內(nèi)聚和耦合 9.1.1.1類耦合的種類 9.1.1.2 Demeter法則 9.1.1.3存取程序方法和無智能類 9.1.1.4動態(tài)分類和混合實例內(nèi)聚 9.1.1.1類耦合的種類 為了兩個類之間能互相通信，它們需要被“耦合”。類X和類Y之間的耦合當(dāng)

6、類X能夠直接涉及到類Y時就存在了。八種類的耦合： 1.X從Y繼承。 2.X具有類Y的屬性。 3.X具有帶上類Y作為參數(shù)的模板屬性。 4.X具有將類Y作為輸入?yún)?shù)的方法。 5.X具有將類Y作為輸出參數(shù)的方法。 6.X知道類Y的全局變量。 7.X知道包含類Y的局部變量的方法。 8.X是Y的一個友元。9.1.1.2 Demeter法則 類耦合對對象通信是必需的，但是它應(yīng)該盡可能被限制在類層的范圍之內(nèi)（即限制為層內(nèi)的耦合）。層之間的耦合應(yīng)該降到最低。在Demeter法則中給出了對限制類之間的任意通信的另一個方針，它說消息的目標(biāo)只能是下面給出的對象：1.方法的對象本身。2.方法型構(gòu)中的作為參數(shù)的對象。3

7、.由對象的屬性所指的對象（包括在屬性的集合中索引到的對象）。4.由該方法創(chuàng)建的對象。5.由全局變量代表的對象。 為了限制由繼承引起的耦合，第三個規(guī)則可以局限于類本身定義的屬性。被類繼承的屬性不能用來代表一個消息的目標(biāo)對象。這個限制被認為是強Demeter法則。 9.1.1.3存取程序方法和無智能類 像在9.1.1節(jié)中所提到的那樣，屬性及其相關(guān)的方法應(yīng)該保存在一個類中。一個類應(yīng)該決定它自己的命運，一個類可以用將存取程序方法局限在它自己接口中的方法來限制其他類存取自己的狀態(tài)。存取程序方法定義觀察器（get）或變異器（set）操作（8.3.1.2節(jié)）。 9.1.1.3存取程序方法和無智能類 存取程序

8、方法將一個類“開放”，并由其他類來進行內(nèi)部操作。雖然耦合蘊涵一定程度的開發(fā)，但過多地使用存取程序方法可能導(dǎo)致智能在類之間的不平衡分布。一個帶有許多存取程序方法的類有變?yōu)闊o智能類的危險，其他的類決定什么對它來說是好的。 這就是說，存在這樣的情況，一個類不得不對其他類開放。當(dāng)存在實現(xiàn)兩個或多個類之間的一種策略時，這種情況就會出現(xiàn)。這樣的例子有很多。 9.1.1.3存取程序方法和無智能類 假設(shè)我們有兩個類INTEGER和REAL，我們需要實現(xiàn)一個整數(shù)和實數(shù)之間進行轉(zhuǎn)換的“策略”，那么這個策略應(yīng)該在其中哪個類中實現(xiàn)呢？或者我們需要一個CONVERTER類來實現(xiàn)這個策略？采取任何一種方式，都至少有其中的

9、一個類必須允許存取程序方法，而且對這個策略而言它將變成是“無智能”。 9.1.1.3存取程序方法和無智能類 一個出自Jones的著名引證在這里是恰當(dāng)?shù)模骸霸谝粋€面向?qū)ο蟮霓r(nóng)場，有面向?qū)ο蟮呐Ｄ?。?yīng)該是面向?qū)ο蟮呐０l(fā)送給面向?qū)ο蟮呐Ｄ蘵ncow_ yourself消息，還是面向?qū)ο蟮呐Ｄ贪l(fā)送給自向?qū)ο蟮呐nmilk_yourself消息？” 。 例9.1（大學(xué)注冊） 在第6章，我們已經(jīng)為大學(xué)注冊的部分需求設(shè)計了其中的合作部分。這個合作模型提供了相對統(tǒng)一的智能的分布，但是沒有討論其他的解決方案。 對這個例子，假設(shè)需要對一個課程增加一個學(xué)生。為此，需要做兩個檢查。第一，必須找出學(xué)習(xí)這個課程的前提條

10、件。第二，必須檢查學(xué)生的學(xué)業(yè)記錄以確定這個學(xué)生是否滿足這個前提條件。有了這些信息，我們才可以決定這個學(xué)生是否能夠增加到這個課程的學(xué)習(xí)中。 考慮由邊界對象：EnrolmentWindow發(fā)送的消息enrol()，考慮三個類：CourseOffering、Course和Student來合作完成這個任務(wù)。我們的工作是設(shè)計一組可能的協(xié)作圖來解決這個問題。討論不同方案的利弊。 例9.1（大學(xué)注冊） 圖9.1說明了第一種方案。邊界對象：Enrolmentwindow通過發(fā)送enrol()消息給aCourse.aCourse請求aStudent的學(xué)習(xí)記錄，并對照它的前提條件進行檢查來啟動這個事務(wù)。aCour

11、se決定aStudent是否可以被汪冊，并請求aCourseOffering增加aStudent到它的學(xué)生表中。 例9.1（大學(xué)注冊） 圖9-1中的情景賦予對象aCourse太大的能力。aCourse是策略的制定者，aStudent是個無智能類。這個方案是不平衡的但又沒達到平衡的辦法。 例9.1（大學(xué)注冊）例9.1（大學(xué)注冊） 我們可以將重心從aCourse轉(zhuǎn)移到astudent，從而獲得了圖9-2所示的方案?，F(xiàn)在，:EnrolmentWindow要求astudent做重要的工作。aStudent調(diào)用aCourse中的一個觀察者方法getPrereq()。aStudent決定這次注冊是否可能，

12、并命令aCourseOffering給這個學(xué)生注冊。圖9-3說明了一個較為平衡的解決方案，其中aCourseOffering是策略制定者。這個方案對aCourse和aStudent是公平的，但它卻使這兩個對象相當(dāng)空閑和不用思考。ACourseOffering就像是“主程序”（Riel的說法中的一個“上帝”類。 例9.1（大學(xué)注冊）例9.1（大學(xué)注冊）例9.1（大學(xué)注冊） 圖9-3的方案可以得到改進，即引入一個控制對象來處理策略信息（參見BCE方法，5.2.4節(jié)）。圖9-4中的控制對象：EnrolmentPolicy將這三個實體對象從注冊策略中解放出來。這是有益的，因為注冊策略的任何變化都封裝在

13、這個單獨的控制類中。然而，類EnrolmentPolicy也有變?yōu)椤吧系邸鳖惖奈ｋU。 例9.1（大學(xué)注冊）9.1.1.4動態(tài)分類和混合實例內(nèi)聚 在第2.1.5.2.3節(jié)中，我們提出了動態(tài)分類的問題，并且觀察到流行的面向?qū)ο蟪绦蛟O(shè)計環(huán)境并不支持它。缺乏這個支持的代價常常反映在設(shè)計出具有混合實例內(nèi)聚的類。 Jones定義“一個具有混合實例內(nèi)聚的類有某些對該類的一些對象來說沒有定義的性質(zhì)?！边@種類的一些方法只能作用到其對象的一個子集上，一些屬件只對對象的子集有意義。9.1.1.4動態(tài)分類和混合實例內(nèi)聚 例如，類Employee可能定義了一些對象，他們可以是“一般的”雇員也可以是經(jīng)理。經(jīng)理是付年薪的，

14、然而向一個Employee對象發(fā)送PayAllowance的消息是沒有意義的，因為可能這個Employee對象井不是經(jīng)理。 9.1.1.4動態(tài)分類和混合實例內(nèi)聚 為了消除這種混合實例內(nèi)聚，需要擴展泛化層次來標(biāo)識Employee的子類，如Ordinary mployee和Manager。然而，Employee對象可能今天是OrdinaryEmployee，明天就成為Manager，或者反之亦然。為了消除混合實例內(nèi)聚，需要允許對象能在運行時動態(tài)地改變它所屬的類公認的catch-22，如果不支持動態(tài)分類的話。 例9.2（大學(xué)注冊） 考慮下面對例9.1的變化：晚上的課程只向非全日制學(xué)生提供。全日制學(xué)生

15、只可以注冊白天的課程。如果非全日制學(xué)生要注冊晚上的課程的話，要付少量的費用。非全日制學(xué)生當(dāng)在一個給定的學(xué)期中注冊了多于六個信用點（即一般要多于兩個課程）時，自動考慮為是全日制的。 我們的任務(wù)是提出一個不帶混合實例內(nèi)聚的高內(nèi)聚結(jié)構(gòu)合作模型，然后仔細地評價這個模型，并提出和討論另一個能避免動態(tài)分類問題的方案。 例9.2（大學(xué)注冊） 為了消除混合實例內(nèi)聚，需要將Student特化為兩個子類PartTimeStudent和FullTimeStudent（圖9-5），如果每個學(xué)生必須要么是非全日制的要么是全日制的話，類Student就是抽象的。消息payExtraFee(crs_off)將不會發(fā)送給類F

16、ullTimeStudent的對象，因為FullTimeStudent沒有這樣的方法。 例9.2（大學(xué)注冊） 必須承認，這樣仍然存在問題。一個非全日制的學(xué)生可能對白大的課程有偏愛（即evening_preference=False）并且沒有額外要付的費用。換句話說，在 PartTimeStudent中仍有混合實例內(nèi)聚問題。如果學(xué)生選擇了白天的課程的話，向PartTimeStudent發(fā)送消息payExtraFee(crs_off）將沒有意義。 例9.2（大學(xué)注冊） 例9.2（大學(xué)注冊） 圖9-6擴展了這個設(shè)計來消除另一方面的混合實例內(nèi)聚。類DayPrefPartTimeStudent沒有方法p

17、ayExtraFee(crs_off) 。但是如果DayPrefPartTimeStudent因為白天的課程的沒有更多的名額而不得不選擇晚上的課程，又會怎么樣呢？也許，要付某種其他的費用。應(yīng)該再進一步特化從而導(dǎo)出類UnluckyDayPrefPartTimeStudent嗎？ 例9.2（大學(xué)注冊） 例9.2（大學(xué)注冊） 若不想進入一個荒謬的情景的話，我們可以選擇放棄進一步推進消除混合實例內(nèi)聚的想法。這里我們還沒有提到動態(tài)分類，但實際上，屬性current_sem_credit_points的當(dāng)前值決定了一個學(xué)生是非全日制的還是全日制的。 例9.2（大學(xué)注冊） 同樣，一個學(xué)生在任何時候都可以改變

18、他對晚上還是白天的課程的偏好。如果缺少程序設(shè)計環(huán)境對動態(tài)分類的支持，那就是程序員的責(zé)任來讓一個對象在運行過程中改變它所屬的類。這是很困難的在永久對象的情況下，其對象OID值包含了類標(biāo)識符時尤其困難。 例9.2（大學(xué)注冊） 另一種方法就是限制繼承層次的深度，消除對動態(tài)分類的要求，并重新引入一定數(shù)量的混合實例內(nèi)聚。例如，我們可以允許一個對象根據(jù)屬性evening_preference的不同取值用不同的方式去響應(yīng)消息payExtraFee(crs_off)，從而能夠依靠圖 9-5中的結(jié)構(gòu)化合作，并解決含偏好晚上課程的問題。 例9.2（大學(xué)注冊） 可以用一個if語句來編程，如下述偽代碼所示：metho

19、d payExtraFee(crs_off) for the class PartTimeStudentif evenig_preference=False returnelsedo itend method 例9.2（大學(xué)注冊） 雖然在面向?qū)ο蟠a中使用if語句表明了放棄繼承和多態(tài)性，但從純粹實際的原因來看它是不可避免的。與其費力地解決動態(tài)分類的問題，不如程序員給類引入了動態(tài)語義。一個對象根據(jù)它當(dāng)前的局部狀態(tài)對相同的消息用不同的方式去響應(yīng)。狀態(tài)圖可以用來為這個類設(shè)計動態(tài)語義。不可否認的是，這個過程將承受類的內(nèi)聚問題。 9.1.2設(shè)計客戶機服務(wù)器合作 IS程序為了數(shù)據(jù)與數(shù)據(jù)庫交互?？蛻魴C程序必

20、須使用數(shù)據(jù)庫語言（通常是SQL）來存取和修改數(shù)據(jù)庫。為了理解一個客戶機程序如何與數(shù)據(jù)庫服務(wù)器通信，需要認識到SQL可以用不同的形式出現(xiàn)并可以用于程序抽象的不同層次上。 9.1.2設(shè)計客戶機服務(wù)器合作 圖9-7區(qū)別了SQL接回的五個層次。在第一層，SQL用做DDL（數(shù)據(jù)定義語言）。DDL是一種規(guī)格說明語言，用于定義數(shù)據(jù)庫的結(jié)構(gòu)（數(shù)據(jù)庫模式）。數(shù)據(jù)庫設(shè)計者和數(shù)據(jù)庫管理者（DBA）是第一層SQL的主要用戶。 9.1.2設(shè)計客戶機服務(wù)器合作 在第二層，SQL用做數(shù)據(jù)操縱語言（DML）或查詢語言。查詢語言這個術(shù)語有點用詞不當(dāng)，因為第二層上的SQL不僅用來檢索數(shù)據(jù)用，還用來修改數(shù)據(jù)（帶有插入、修改和刪除操

21、作）。 9.1.2設(shè)計客戶機服務(wù)器合作 使用第二層SQL的用戶范圍很廣，從沒有經(jīng)驗的專門用戶到有經(jīng)驗的DBA。這一層上的SQL是交互式的，這意味著一個用戶可以在程序設(shè)計環(huán)境之外構(gòu)造一個查詢，并讓它立即在數(shù)據(jù)庫上運行。第二層SQL是學(xué)習(xí)下面幾層更精化的SQL的一個切入點。 9.1.2設(shè)計客戶機服務(wù)器合作 應(yīng)用程序使用第二層以上的SQL。在這些更高的層次上，SQL允許第二層上（作為惟一選擇的）一次一個集合的處理機制仍然有效外，還允許一次一個記錄的處理機制。一次一個集合的處理取一個或多個表（記錄的集合）作為對一個查詢的輸入，并返回一個表作為輸出。雖然這是一個很強的機制，但在復(fù)雜查詢中使用卻是困難和危

22、險的。 9.1.2設(shè)計客戶機服務(wù)器合作 為了能肯定一次查詢返回正確的結(jié)果，程序員必須有能力逐行瀏覽由查詢返回的記錄，并在一次一個記錄的基礎(chǔ)上決定對這些記錄要做什么。這樣的一次一個記錄的處理能力稱為光標(biāo)，并在第二層之上的SQL中有效。 9.1.2設(shè)計客戶機服務(wù)器合作 第三層上的SQL是嵌入在常規(guī)程序設(shè)計語言，如C和COBOL中的。因為程序設(shè)計語言編譯器不理解SQL，需要一個預(yù)編譯器來將SQL語句翻譯成由DBMS供應(yīng)商提供的DB庫中的功能調(diào)用。程序員可以選擇直接使用DB庫函數(shù)來編程，在這種情況下就不需要預(yù)編譯器了。 9.1.2設(shè)計客戶機服務(wù)器合作 將客戶機程序與數(shù)據(jù)庫接口的一個流行方式是通過開放數(shù)

23、據(jù)庫互連（ODBC）或Java數(shù)據(jù)庫互連（JDBC）標(biāo)準(zhǔn)。要用這種方式的編程，要求有對特定DBMS的ODBC或JDBC軟件驅(qū)動程序。ODBC和JDBC在SQL之上提供一個標(biāo)準(zhǔn)數(shù)據(jù)庫語言，它被這個驅(qū)動程序翻譯成簡單DBMS SQL。 9.1.2設(shè)計客戶機服務(wù)器合作 ODBCJDBC具有減輕本地DBMS SQL編程耦合度的優(yōu)點。如果程序需要將來移植到不同的目標(biāo)DBMS上，那么只要直接替換一下驅(qū)動程序就可以了。更重要的是，用ODBCJDBC可以支持向多于一個DBMS發(fā)布詢問的應(yīng)用。 9.1.2設(shè)計客戶機服務(wù)器合作 ODBCJDBC的缺點是：它具有SQL的“最低公共特性”，客戶機應(yīng)用不能利用任何特殊的

24、SQL特性或者由特定DBMS供應(yīng)商所支持的任何擴展。 9.1.2設(shè)計客戶機服務(wù)器合作 第四層 SQL采用了與第三層 SQL同樣的策略，將 SQL嵌入在客戶機程序中。但第四層SQL提供更強的程序設(shè)計，應(yīng)用生成器或第4GL（四代語言）。 4GL配置有“屏幕界面”和GUI構(gòu)建能力。由于IS應(yīng)用要求復(fù)雜的GUI，4GLSQL常常是構(gòu)建這種應(yīng)用的首選。 9.1.2設(shè)計客戶機服務(wù)器合作 第五層SQL補充了第三層和第四層，它提供將一些SQL語言從客戶機程序移向主動（可編程）服務(wù)器數(shù)據(jù)庫的可能性。SQL用做程序設(shè)計語言（PLSQL）。服務(wù)器程序可以從客戶機程序內(nèi)進行調(diào)用，就像在下面將要討論的那樣。 9.1.2

25、設(shè)計客戶機服務(wù)器合作9.1.2.1存儲過程 9.1.2.2觸發(fā)器 9.1.2.1存儲過程 Sybase RDBMS首先引入存儲過程，現(xiàn)在他們成為任何主要商用DBMS的一部分。存儲過程將數(shù)據(jù)庫變成一個主動可編程系統(tǒng)。 9.1.2.1存儲過程 存儲過程是用擴展的SQL編寫的，它支持像變量、循環(huán)、分支和賦值這樣一些程序設(shè)計構(gòu)造元素。存儲過程還可以被命名，可以有輸入輸出參數(shù)，它被編譯并存儲在數(shù)據(jù)庫中。客戶機程序調(diào)用一個存儲過程就跟它調(diào)用子過程一樣。 9.1.2.1存儲過程 圖9-8說明了客戶機程序調(diào)用存儲過程與向服務(wù)器發(fā)送完整的查詢命令相比之下的優(yōu)點。在客戶機程序中構(gòu)成的查詢通過網(wǎng)絡(luò)發(fā)送給數(shù)據(jù)庫服務(wù)器

26、，這個查詢語句可能包含語法和其他錯誤，但客戶機不能消除這些錯誤，數(shù)據(jù)庫系統(tǒng)是惟一可以做這種驗證的地方。一旦被驗證，DBMS檢查調(diào)用者是否被授權(quán)運行這個查詢。如果是，這個詢問就被優(yōu)化以決定對所需數(shù)據(jù)的最好的訪問規(guī)劃。只有這時它才能被編譯、執(zhí)行，最后將結(jié)果返回給客戶機。 9.1.2.1存儲過程 另一方面，如果詢問（或者整個的詢問的集合）被編寫為存儲過程，則它被優(yōu)化并被編譯進服務(wù)器數(shù)據(jù)庫。客戶機程序不需要在網(wǎng)絡(luò)上發(fā)送（可能是很大的）詢問取而代之的是它只要發(fā)送對這個過程名的一個短調(diào)用和一組實參。如果幸運的話，這個過程可能就駐留在DBMS內(nèi)存高速緩存中。如果不是，它將從數(shù)據(jù)庫中被調(diào)入內(nèi)存。 9.1.2.

27、1存儲過程 用戶的授權(quán)也要像對SQL詢問一樣被檢查。然后實參代替形參并且存儲過程執(zhí)行，最后結(jié)果返回給調(diào)用者。 9.1.2.1存儲過程 就像在上述情景中看到的那樣，存儲過程提供了更有效的方式來從客戶機程序中訪問數(shù)據(jù)庫。性能上的優(yōu)點是由于網(wǎng)絡(luò)堵塞的緩解，并且不需要每次收到客戶機請求時都進行語法分析和編譯。甚至更重要的是，存儲過程由單獨的地方維護，并可以供許多客戶機程序來調(diào)用。 9.1.2.2觸發(fā)器 觸發(fā)器（8.4.1.4節(jié)）是一種特殊的存儲過程，它不能被調(diào)用他們在一個數(shù)據(jù)庫表上發(fā)生的插入、更新或刪除等事件時將他們自己觸發(fā)。這意味著每個數(shù)據(jù)庫表可以最多有三個觸發(fā)器。在某些系統(tǒng)中的確如此（如Sybas

28、e）。而在其他系統(tǒng)（如Oracle）中，因為可以標(biāo)識出事件的其他變體，使得每個表可能有多于三個觸發(fā)器（雖然這樣，存在更多的觸發(fā)器并不意味著它的觸發(fā)器的表達能力就更強）。 9.1.2.2觸發(fā)器 觸發(fā)器可以被編程以加進作用在數(shù)據(jù)庫上并且不能被任何客戶機程序或者通過交互式SQLDML語句改變的任何業(yè)務(wù)規(guī)則。這意味著觸發(fā)器可以超出引用完整性約束的過程性強制手段（如在第8.4.1.4節(jié)中所討論的那樣）。例如，一個觸發(fā)器可以用來規(guī)定在某些時間段或某些天不允許訪問數(shù)據(jù)庫。 9.1.2.2觸發(fā)器 客戶機程序的用戶甚至不會意識到觸發(fā)器正監(jiān)視著數(shù)據(jù)庫中什么正在被修改。如果這個修改不違反業(yè)務(wù)規(guī)則，觸發(fā)器對這個程序就

29、是不可見的。觸發(fā)器只有當(dāng)DML命令是不允許的時候才將自己暴露給用戶。觸發(fā)器將通知用戶所出現(xiàn)的問題，它在程序屏幕上顯示出錯信息并拒絕運行這個DML操作。 9.2程序?qū)Ш?主動數(shù)據(jù)庫出現(xiàn)了，程序設(shè)計對象的數(shù)量就增加了，并且對象合作也變得更復(fù)雜。作為程序員可以以此為起點考察實現(xiàn)工作的設(shè)計文檔的窗口導(dǎo)航圖（7.6.2節(jié)）就顯得不夠了，它們需要擴展為（代換為）更完整的程序?qū)Ш綀D。 9.2程序?qū)Ш?程序?qū)Ш綀D概念在UML中沒有標(biāo)準(zhǔn)化或者說沒有討論。不過它是一種基本建模抽象，用來消除系統(tǒng)設(shè)計和系統(tǒng)實現(xiàn)之間的鴻溝。否則就是壞的軟件工程程序的體系結(jié)構(gòu)和邏輯沒有文檔化，而且留給程序員去決定。 9.2程序?qū)Ш?9.

30、2.1構(gòu)造型程序?qū)Ш降幕顒訄D9.2.2程序?qū)Ш綀D 9.2.1構(gòu)造型程序?qū)Ш降幕顒訄D 為了將窗口導(dǎo)航圖轉(zhuǎn)換為程序?qū)Ш綀D，需要對UML的活動圖增加服務(wù)器端的構(gòu)造型。狀態(tài)（圓角長方形）和活動（橢圓）都應(yīng)該被構(gòu)造型。構(gòu)造型必須考慮DBMS模型或者甚至是特定DBMS的特性（這當(dāng)然是為什么UML中沒有提供這種導(dǎo)航圖的主要原因或借口）。 9.2.1構(gòu)造型程序?qū)Ш降幕顒訄D 下面的構(gòu)造型表可以用來用RDBMS設(shè)計程序?qū)Ш?。依賴于程序?qū)Ш綀D所處的抽象層次，這個表可以縮小，或者用另外的對象來擴展：狀態(tài)（數(shù)據(jù)對象）：活動（程序?qū)ο螅嚎蛻魴CSQL查詢。9.2.1構(gòu)造型程序?qū)Ш降幕顒訄D 狀態(tài)（數(shù)據(jù)對象）：數(shù)據(jù)庫。關(guān)系表

31、。列。記錄。關(guān)系視圖。列。記錄。索引。簇。9.2.1構(gòu)造型程序?qū)Ш降幕顒訄D 活動（程序?qū)ο螅捍鎯^程。觸發(fā)器。對插入操作的。對更新操作的。對刪除操作的。其他種類的觸發(fā)器。9.2.1構(gòu)造型程序?qū)Ш降幕顒訄D 客戶機SQL查詢。本地查詢。DB庫查詢。ODBCJDBC查詢。9.2.2程序?qū)Ш綀D 為了說明程序?qū)Ш綀D，我們將簡單地擴展在7.6.2節(jié)中給出的窗口導(dǎo)航圖。圖9-9就是擴展（并進行了細微的調(diào)整）圖7-23中的窗口導(dǎo)航圖后得到的程序?qū)Ш綀D。 程序?qū)Ш綀D 9.2.2程序?qū)Ш綀D 圖9-9引入了兩個服務(wù)器狀態(tài)：Inventory Control（）和Product（），增加了三個服務(wù)器活動：Selec

32、t Product（）、 Update Product（）和 On Update Product（），還增加了一個客戶機活動Scroll（）。 9.2.2程序?qū)Ш綀D 通過所增加的信息，圖9-9中的程序?qū)Ш綀D告訴程序員，要在Product Browser中顯示產(chǎn)品必須調(diào)用存儲過程（Select Product）。當(dāng)用戶上下滾動瀏覽器窗口，這個窗口中的內(nèi)容必須從數(shù)據(jù)庫中更新時，也調(diào)用相同的存儲過程。 9.2.2程序?qū)Ш綀D 在這個圖的下半部分，我們可以看到在 Update Product（）中按下OK或Save鍵，就調(diào)用Update Product（）。一個觸發(fā)器控制輸出的修改（On Update

33、Product）。 例9.3（關(guān)系管理） 考慮下述對例7.5（7.6.2節(jié)）的擴展：使用存儲過程來修改（插入、刪除、更新和完成）一個事件。需要有觸發(fā)器來監(jiān)控Event表上的插入和修改。 我們的任務(wù)是，為Contact Management應(yīng)用中處理事件修改這部分設(shè)計程序?qū)Ш綀D。 例9.3（關(guān)系管理） 這個例子的解決方案（圖9-10）只涉及來自圖7-24中與事件修改相關(guān)的那些客戶機狀態(tài)和活動。注意，存儲過程Complete Event既可以從主窗口中也可以從對話框中調(diào)用。因為Complete Event要更新表Event，所以觸發(fā)器On Update Event啟動。同樣的觸發(fā)器也可以被存儲過程

34、Save Event激活。 關(guān)系管理例9.3（關(guān)系管理） 對話框TaskEvent Details有雙重的作用，既用來插入新的事件，又用來更新存在的事件。命令鍵OK調(diào)用存儲過程Save Event。這個調(diào)用中的參數(shù)列表告訴這個過程OK是指插入還是指更新。對應(yīng)地，這個過程的執(zhí)行要啟動兩個觸發(fā)器： On Insert Event或On Update Event中的一個。 9.3設(shè)計事務(wù) 事務(wù)是工作的一個邏輯單元，它包含一個或多個由用戶執(zhí)行的SQL語句。事務(wù)也是數(shù)據(jù)庫一致性的單元，數(shù)據(jù)庫的狀態(tài)在事務(wù)完成之后還是一致的。為了保證這個一致性，DBMS的事務(wù)管理有兩個作用：數(shù)據(jù)庫恢復(fù)和并發(fā)控制。 9.3設(shè)

35、計事務(wù) 按照SQL標(biāo)準(zhǔn)，事務(wù)從第一個可執(zhí)行的SQL語句開始（在某些系統(tǒng)中，要求有顯式的 begin transaction語句）。事務(wù)結(jié)束于 commit或rollback語句。commit語句將變化永久地寫入數(shù)據(jù)庫中，而rollback語句擦除由這個事務(wù)帶來的任何變化。 9.3設(shè)計事務(wù) 事務(wù)是原子的，這個事務(wù)中所有SQL語句的結(jié)果要么被承認要么被駁回。用戶決定事務(wù)的期限（大?。?。根據(jù)業(yè)務(wù)的需要，以及應(yīng)用領(lǐng)域和用戶-計算機交互風(fēng)格，一個事務(wù)可以只有一條SQL語句那樣短，它也可以涉及一系列SQL語句。 9.3設(shè)計事務(wù) 9.3.1短事務(wù)9.3.2長事務(wù) 9.3.1短事務(wù) 大多數(shù)傳統(tǒng)的IS應(yīng)用都要求

36、短事務(wù)。短事務(wù)包含一條或多條SQL語句，它們必須盡可能快地完成，從而使得其他事務(wù)不被掛起。 9.3.1短事務(wù) 考慮一個飛機預(yù)定系統(tǒng)，其中許多旅行代理為全球的旅客做航班預(yù)定。每個預(yù)定的事務(wù)必須快速由DBMS執(zhí)行，以便使得該航班的空位信息能及時更新，從而數(shù)據(jù)庫又可以處理等待在隊列中的下一個事務(wù)，這是基本的。 9.3.1短事務(wù)9.3.1.1悲觀的并發(fā)控制 9.3.1.2隔離的層次 9.3.1.3自動恢復(fù) 9.3.1.1悲觀的并發(fā)控制 DBMS和ODBMS的異常都被構(gòu)架為短事務(wù)。這些系統(tǒng)按照悲觀并發(fā)控制來工作。事務(wù)要處理的每個永久對象都獲取鎖。有四種對象的鎖：1.排它性（寫）鎖。其他事務(wù)必須等待，直到

37、持有這樣一個鎖的事務(wù)完成并將這種鎖釋放。2.更新（寫意圖）鎖。其他事務(wù)可以讀這個對象，但一旦有這樣的需要，持有這種鎖的事務(wù)被保證能夠用排它的模式來對它進行升級。3.讀（共享）鎖。其他事務(wù)可以讀并且可能獲得對這個對象的更新后的鎖。4.無鎖。其他事務(wù)可以在任何時候更新對象，只適合于允許“受污染的讀取”的應(yīng)用，即一個事務(wù)要讀的數(shù)據(jù)可以在這個事務(wù)完成之前就被修改或者甚至被（被另一個事務(wù)）刪除。 9.3.1.2隔離的層次 與這四種鎖相關(guān)聯(lián)的是在并發(fā)執(zhí)行的事務(wù)之間的四個隔離的層次。系統(tǒng)設(shè)計者的責(zé)仟是決定哪個隔離層次適合數(shù)據(jù)庫上的事務(wù)的混合。這四個層次是：1.受污染的讀取。2.不可重復(fù)的讀取。3.幻影對象。

38、4.可重復(fù)讀取。1 受污染的讀取。 事務(wù)t1修改了一個對象但還沒有承認這次修改，事務(wù)t2就讀取了一個對象。如果t1回滾這個事務(wù)，則t2獲得了一個數(shù)據(jù)庫中從沒有存在的一個對象。 2.不可重復(fù)的讀取。 t1已經(jīng)讀取了一個對象，t2更新這個對象，t1再讀取這個對象，但這次它獲得這個對象的不同值。 3.幻影對象。 t1讀取了一組對象，t2在這個對象集中插入一個新對象，t1重復(fù)這個讀操作并將看到一個“幻影”對象。 4.可重復(fù)讀取。 t1和t2可以并發(fā)執(zhí)行，但這兩個事務(wù)的交叉執(zhí)行將產(chǎn)生同樣的結(jié)果，就像它們是一次執(zhí)行一個一樣（這稱為可序列化的執(zhí)行）。 9.3.1.2隔離的層次 通?；贕UI的交互式IS應(yīng)用

39、要求短事務(wù)。然而，在同一個應(yīng)用中不同的事務(wù)的隔離層次可以不同。SQL語句set transaction可以用于這個目的。很明顯這中間需要折中增加隔離的層次就減少了系統(tǒng)的全面并發(fā)性。 9.3.1.2隔離的層次 一個至關(guān)重要的設(shè)計決定與上面的考慮無關(guān)，事務(wù)的開始必須總是要被延遲到最后一秒鐘。從客戶機窗口開始一個事務(wù)，然后在它確實可以完成這個工作之前，必須讓它一直等待到它從用戶處獲得了一些另外的信息，這一點是不可接受的。 9.3.1.2隔離的層次 用戶可能要很長時間才能提供這些信息，或者甚至可能會在這個事務(wù)正在運行時關(guān)閉計算機。事務(wù)超時后就回滾回去，但對整個系統(tǒng)的吞吐量的危害己經(jīng)產(chǎn)生了。 9.3.1

40、.3自動恢復(fù) Murphy 法則說，如果什么事能夠出錯，那它就會的。程序可能含有錯誤，運行進程可能被暫?；蛘咧袛唷恿?yīng)可能失敗、磁頭可能斷裂等等。幸運的是，DBMS為大多數(shù)情景提供自動恢復(fù)的能力。只有磁盤數(shù)據(jù)出現(xiàn)物理丟失的情況下，需要DBA的干預(yù)來命令DBMS從最近的數(shù)據(jù)庫備份中恢復(fù)數(shù)據(jù)。 9.3.1.3自動恢復(fù) 根據(jù)事務(wù)在故障點的狀態(tài)，DBMS將自動地執(zhí)行回滾操作，或者一旦問題的原因被消除，再進行事務(wù)的向前滾動。這個恢復(fù)是自動的，但是一個DBA能夠通過設(shè)置檢查點出現(xiàn)的頻率來控制恢復(fù)時間的長短。一個檢查點強制DBMS暫時停止所有的事務(wù)并將所有的事務(wù)對數(shù)據(jù)庫的改變（它上個檢查點以來的）寫進數(shù)

41、據(jù)庫。 9.3.1.3自動恢復(fù) 圖9-11示例了涉及從故障點進行自動恢復(fù)的問題。事務(wù)t1在檢查點之后但在系統(tǒng)故障之前承認，由于DBMS不知道檢查點之后的所有的改變是否都已經(jīng)物理地寫進數(shù)據(jù)庫，它將在從故障中恢復(fù)之后；向前滾動（再做一次）事務(wù)t1。 9.3.1.3自動恢復(fù) 9.3.1.3自動恢復(fù) 事務(wù)t2在檢查點和故障之間有一個回滾作用到它上面。同事務(wù)t1的情況一樣，DBMS不知道這個被回滾的改變是否已經(jīng)記入磁盤，DBMS將再進行一次回滾。 其他事務(wù)是在檢查點之后開始的。事務(wù)t3將向前滾動以保證它的改變影響到數(shù)據(jù)庫。同樣，事務(wù)t4也將被重復(fù)，即回滾。 9.3.1.3自動恢復(fù) 事務(wù)t5不要求任何補救

42、行為，因為它在出現(xiàn)故障的時候正在運行。任何在故障之前由t5引起的改變還沒有被寫進數(shù)據(jù)庫中，所有中間的改變也只是寫進了日志文件。用戶意識到在出故障時這個事務(wù)正在進行，可以在DBMS啟動并再次運行時重新發(fā)送這個事務(wù)。 9.3.1.4可編程的恢復(fù) 沒有預(yù)見的系統(tǒng)故障由DBMS自動恢復(fù)，然而設(shè)計者和程序員應(yīng)該控制任何可預(yù)見的事務(wù)問題。DBMS提供一組到程序上的回滾選項以使得它可以從問題中平緩地恢復(fù)，從而可能使用戶意識不到在什么地方出了問題。 9.3.1.4可編程的恢復(fù) 首先，GUI指南，如用戶控制或?qū)捜菰瓌t（7.3節(jié)），要求程序允許用戶出錯并從中恢復(fù)。一個程序員控制的作用在程序正確的位置上的回滾可以將

43、數(shù)據(jù)庫恢復(fù)到以前的狀態(tài)（即撤消錯誤），假如這個事務(wù)還沒有被確認的話。 9.3.1.4可編程的恢復(fù) 如果這個事務(wù)已經(jīng)確認，那么程序員還可以選擇寫一個補償事務(wù)。用戶然后可以請求執(zhí)行這個補償事務(wù)來撤消對數(shù)據(jù)庫的改變。補償事務(wù)特別設(shè)計來允許可編程的恢復(fù)，并應(yīng)該在用例中建模。 9.3.1.4可編程的恢復(fù) 9.3.1.4.1保存點 9.3.1.4.2觸發(fā)器回滾 9.3.1.4.1保存點 保存點是程序中的一個語句，它將一個較長的事務(wù)劃分成幾個小的部分。被命名的保存點插在程序的戰(zhàn)略性的關(guān)鍵位置上。程序員就可以選擇將進程回滾到某個被命名的保存點上，而不是回滾到事務(wù)的開始。 9.3.1.4.1保存點 例如，程序員

44、可以在update操作之前插入一個保存點。如果update失敗，程序回滾到這個保存點并試圖再執(zhí)行更新操作。或者，程序可能采取另外的行為來避免放棄整個事務(wù)。 9.3.1.4.1保存點 在較大的程序中，可以在每個子程序之前都插入保存點。如果子例程失敗，就可以回滾到這個子過程之前再用改過的參數(shù)來執(zhí)行它。如果必要的話，需要一個特別設(shè)計和編程的恢復(fù)子例程來做這個掃尾工作，以便使得這個事務(wù)能恢復(fù)執(zhí)行。 9.3.1.4.2觸發(fā)器回滾 觸發(fā)器回滾是一種特殊的保存點。就像在9.1.2.2節(jié)所解釋的那樣，一個觸發(fā)器可以用來編程任意復(fù)雜度的業(yè)務(wù)規(guī)則。有時當(dāng)一個觸發(fā)器拒絕修改一個表（由于這個事務(wù)試圖打破業(yè)務(wù)規(guī)則）時并

45、不想撤消整個事務(wù)。這個事務(wù)可能想要采取補救行為。 9.3.1.4.2觸發(fā)器回滾 針對上述原因，DBMS可以提供編寫觸發(fā)器的可能以回滾整個事務(wù)或只回滾這個觸發(fā)器。在后一種情況下，程序（可能是一個存儲過程）可以分析這個問題并決定進一步的行為。甚至如果整個事務(wù)不得不被回滾，程序可能更好地解釋這個錯誤的原因，并向用戶顯示更有智能的消息。 9.3.1.5設(shè)計存儲過程和觸發(fā)器 程序?qū)Ш綀D（9.2.2節(jié)）可以進一步擴展以包括事務(wù)狀態(tài)。然而，從圖形分布的觀點來看這非常麻煩，另一個解決辦法可以是設(shè)計多個程序?qū)Ш綀D，每個都代表了導(dǎo)航的不同角度。其中有一個這樣的角度重點在捕獲事務(wù)的導(dǎo)航。 9.3.1.5設(shè)計存儲過程

46、和觸發(fā)器 在任一情況下，程序?qū)Ш綀D都確定了存儲過程和觸發(fā)器，還需要提供每個存儲過程和觸發(fā)器的目的、定義和詳細設(shè)計。特別地，需要部署一些偽代碼表示法來定義算法。 9.3.1.5設(shè)計存儲過程和觸發(fā)器 作為一個例子，我們下面給出關(guān)系管理應(yīng)用（參見圖 9-10和 9.2.2節(jié)）中的存儲過程DeleteEvent的一個算法。這個過程檢查正試圖刪除事件的用戶（雇員）是否與創(chuàng)建這個事件的是同一個用戶。如果不是，這個刪除操作就被拒絕。這個過程還檢查這個事件是否已經(jīng)是當(dāng)前任務(wù)剩下的惟一事件。如果是，這個任務(wù)也被刪除。 9.3.1.5設(shè)計存儲過程和觸發(fā)器 BEGININPUT PARAMETERS(event_i

47、d,user_id) Select Event(where event_id = event_id) IF user_id = Event.created_emp_idTHENdelete Event(where event_id = event.id) IF no more events forTask.task_id = Event.task_id ANDEvent.event_id = event_idTHENdelete that TaskEnD IFELSEraise error(Only the creator of the event can delete that event)

48、ENDIFEND9.3.1.5設(shè)計存儲過程和觸發(fā)器 存儲過程DeleteEvent包含delete語句來從表Event和Task中刪除記錄。這些delete語句將啟動對這些表的刪除觸發(fā)器（如果有的話）。如果這些觸發(fā)器的算法超出了正常的引用完整性檢查范圍，設(shè)計者還應(yīng)該為它們提供偽代碼規(guī)格說明（包含對回滾策略的決定是觸發(fā)器回滾還是事務(wù)回滾）。 9.3.2長事務(wù) 一些IS應(yīng)用的新的類鼓勵用戶之間的合作。這些應(yīng)用被認為是工作組計算應(yīng)用或者計算機支持協(xié)同工作（CSCW）應(yīng)用。這方面的例子包括許多辦公室應(yīng)用、協(xié)同寫作、計算機輔助設(shè)計、CASE工具等。 9.3.2長事務(wù) 工作組計算應(yīng)用在很多方面都有對與帶短

49、事務(wù)的傳統(tǒng)數(shù)據(jù)庫模型正交的數(shù)據(jù)庫需求，傳統(tǒng)數(shù)據(jù)庫模型將用戶分隔開，而工作組計算應(yīng)用要求長事務(wù)、版本管理、合作并發(fā)控制等。 9.3.2長事務(wù) ODB模型為工作組計算提供一個框架，并且許多ODBMS產(chǎn)品是針對這個應(yīng)用領(lǐng)域的。工作組計算應(yīng)用的用戶共享信息，并且能意識到他們正在進行的工作是在共享的數(shù)據(jù)上進行的。他們使用個人數(shù)據(jù)庫在他們自己的工作空間上工作，這個數(shù)據(jù)庫由從公共工作組數(shù)據(jù)庫（備份）中選出來的數(shù)據(jù)組成。他們在一個長事務(wù)中工作，這個長事務(wù)能夠跨越幾個計算片段（用戶能夠中斷，然后又可以返回，繼續(xù)在同一個長事務(wù)中工作）。 9.3.2長事務(wù) 長事務(wù)的主要方面是，它不允許因為故障而在沒有系統(tǒng)提供軌跡的

50、情況下自動回滾。為了認識這個需求的重要性，可以想像如果由于計算機故障，這本教科書現(xiàn)在要被“回滾（撤消）”時我的失望情緒！長事務(wù)的撤消由用戶通過保存點來控制的，保存點永久性地存儲了用戶私有數(shù)據(jù)庫中的對象。 9.3.2長事務(wù) 短事務(wù)的概念并沒有從工作組計算中完全去除。短事務(wù)對在保證組數(shù)據(jù)庫和私有數(shù)據(jù)庫之間的檢出和檢入操作的原子性和相互隔離是必需的。短鎖于是就被免除了，并且長的永久鎖則由組數(shù)據(jù)庫作用到所有檢出的對象上。 9.3.2長事務(wù) 長事務(wù)模型的相關(guān)的目標(biāo)包括：允許合作的用戶之間的信息交換（甚至如果暫時不一致）。檢測數(shù)據(jù)的不一致并促成達成決定。利用對象的版本性來控制共享，不丟失系統(tǒng)故障情況下的工

51、作。 9.4雙向工程 現(xiàn)代軟件生產(chǎn)的迭代增量式過程(1.1.3.1節(jié)）要求來自設(shè)計和實現(xiàn)之間的雙向工程的強有力的支持。雙向工程定義為向前的代碼產(chǎn)生和從代碼到設(shè)計模型的逆向工程的組合。雙向工程給出了“用圖形或文本視點工作的能力，工具保持了兩種視圖的一致性” 。 9.4雙向工程 在客戶機服務(wù)器應(yīng)用中，雙向工程可以單獨作用在客戶機應(yīng)用程序和服務(wù)器數(shù)據(jù)庫程序上。也許實際上是很可能的，不同的 CASE工具用于同一個項目的客戶機設(shè)計和服務(wù)器設(shè)計。還有，用于雙向工程的 CASE工具必須緊密地與特定的客戶機和或服務(wù)器程序設(shè)計環(huán)境集成在一起。 9.4雙向工程 9.4.1客戶機程序的雙向工程9.4.2數(shù)據(jù)庫的雙向

52、工程 9.4.3從關(guān)系數(shù)據(jù)庫到對象關(guān)系數(shù)據(jù)庫的再設(shè)計工程 9.4.1客戶機程序的雙向工程 客戶機應(yīng)用的雙向工程的原理相對來說比較直接但問題出在細節(jié)中。圖9-12是一個面向?qū)ο蟪绦蛟O(shè)計語言的雙向工程的典型周期的活動圖。UML模型存儲在CASE資源庫中（就像在前面解釋的那樣，CASE資源庫本身是一個數(shù)據(jù)庫系統(tǒng)，常常是一個對象數(shù)據(jù)庫）。 9.4.1客戶機程序的雙向工程 UML Design Model（一個UML狀態(tài)）不得不特別針對程序設(shè)計語言來開發(fā)。Code Generation（一個UML活動）使用UML Design Model來產(chǎn)生Source Code（頭文件和實現(xiàn)文件）。任何用戶提供的定

53、義和來自前一個雙向工程的附加聲明被保留下來。 9.4.1客戶機程序的雙向工程 Source Code后來經(jīng)過正規(guī)程序設(shè)計的改變和擴展。Modified Code在圖9-12中稱為UML Generation的活動UML Implemented Model的逆向工程。某種形式的可視化Model Differencing工具然后用來比較當(dāng)前的UML Implemented Model和最新的UML Design Model，從而揭示設(shè)計產(chǎn)生的改變。所有被接受的改變都傳播到UML Design Model中，并且開始雙向工程的下一個循環(huán)。 9.4.1客戶機程序的雙向工程 9.4.1客戶機程序的雙向工

54、程 就像前面所觀察到的，問題出在細節(jié)中。實踐中，在 CASE工具對程序設(shè)計語言的理解和對這個語言的特定的編譯器之間還有許多“遺漏的鏈接”。CASE工具可能對編譯通過的代碼報告分析錯誤，因為它可能不能識別由特定編譯器支持的語言的變體。 9.4.1客戶機程序的雙向工程 CASE工具可能不能解決一些對特定編譯器的聲明或特定庫源文件的引用。例如，如果源文件引用到在另一個文件中定義的符號，但沒有顯式地包含這個文件時，這個引用就不能被解決。雖然存在對許多這樣的問題的工作區(qū)，但它們肯定會導(dǎo)致不恰當(dāng)?shù)慕鉀Q方式，需要手工進行調(diào)整。 9.4.1客戶機程序的雙向工程 這就是說，引起不恰當(dāng)并不是不對客戶機程序進行雙向

55、工程的理由，這種不恰當(dāng)可以用手動方式來改正，一旦改正UML模型就得出了與當(dāng)前程序匹配的文檔。否則就會完全失去對應(yīng)用實現(xiàn)的控制。 9.4.2數(shù)據(jù)庫的雙向工程 數(shù)據(jù)庫的雙向工程在設(shè)計端涉及物理數(shù)據(jù)模型（PDM），在實現(xiàn)端涉及數(shù)據(jù)庫（DB）。PDM模型用來代替UML，因為UML不支持物理數(shù)據(jù)庫設(shè)計（8.4節(jié)）。PDM模型必須針對特定的DBMS。 9.4.2數(shù)據(jù)庫的雙向工程 圖9-13是關(guān)系數(shù)據(jù)庫的雙向工程的一個活動圖。在數(shù)據(jù)庫的PDM模型構(gòu)造之后（狀態(tài)Initial PDM），就可以被存檔（活動Archive）。比較已經(jīng)存檔的和當(dāng)前的PDM支持捕獲該模型的最新修改。 9.4.2數(shù)據(jù)庫的雙向工程 9.

56、4.2數(shù)據(jù)庫的雙向工程 從Initial PDM到Initial DB的前向工程由活動Create DB完成。這個活動產(chǎn)生一個DB模式，包括觸發(fā)器。 Initial DB通過遞歸活動Load來填充數(shù)據(jù)?；顒覯odify DB引入模式的改變并引起到狀態(tài)Current DB的數(shù)據(jù)庫遷移。 9.4.2數(shù)據(jù)庫的雙向工程 在這個階段，有兩種可能性存在：對Current PDM的改變可以與產(chǎn)生Current DB同步（活動Synchronize PDM with DB）或者反之亦然，即對Current DB的改變也可以與產(chǎn)生Current PDM同步（活動 Synchronize DB with PDM）。結(jié)果， Current PDM可能需要存檔并且Current DB也需要在重裝。 9.4.2數(shù)據(jù)庫的雙向工程 圖 9-14顯示了從Current DB（Sybase DB）到Current PDM（PowerDesigner PDM）的逆向工程一個片段（活動Synchronize PDM with DB）的一個屏幕。