中文在线а√在线8_ 架構與設計

本文是演示了在分布式的、基于J2EE 的項目中使用 Rational 工具的系列文章（如下面所列）的第 5 部分。

XMLns:xsi="http://www.w3.org/2001/XMLSchema-instance">第 1 部分: 項目介紹；高層次計劃

第 2 部分: 風(fēng)險管理；需求管理

第 3 部分: 模型創(chuàng )建和訪(fǎng)問(wèn)控制；需求分析

第 4 部分: 用例細化；產(chǎn)成報告；工具和技術(shù)選擇

第 5 部分: 體系架構和設計

第 6 部分: 詳細設計；早期開(kāi)發(fā)；雙向工程；早期單元測試

第 7 部分: 繼續開(kāi)發(fā)；早期的構建；演示

第 8 部分: 單元測試策略；功能測試；GUI 測試腳本

第 9 部分: 系統構建和測試；缺陷跟蹤；產(chǎn)品交付

第 10 部分: 項目完成；結論；未來(lái)的工作

本文中所虛構我們是一家軟件公司 Lookoff Technologies Incorporated，我們的客戶(hù) Audiophile Speaker Design, Inc. (ASDI)，它雇用我們實(shí)現他們最初的 IT 需求。對于更詳細的信息，參見(jiàn)第 1 部分。

這個(gè)系列的第 5 部分首先檢查了一下項目的時(shí)間進(jìn)度，然后當我們進(jìn)入了架構、設計、數據建模和創(chuàng )建原型時(shí)，我們已經(jīng)在下一個(gè)階段進(jìn)行細化階段中了。

第 5 部分快照

在第 5 部分演示的工具和技術(shù)：

Rational Rose 企業(yè)版用于創(chuàng )建設計模型（包括使用 Rose 的 data modeler 進(jìn)行數據建模）

Rational RequisitePro — 用于添加或者細化需求

產(chǎn)生或者被更新的產(chǎn)物：

設計模型（Rational Rose） — 被創(chuàng )建來(lái)添加架構和設計信息（包括數據庫計劃（schema））

RequisitePro database — 被更新以添加或者細化基于架構和設計探索的需求

在開(kāi)始進(jìn)行詳細的架構和設計工作之前，讓我們來(lái)檢查一下 ASDI 項目的整體進(jìn)度。就像你可以第 1 部分回想起來(lái)的，這個(gè)由多個(gè)部分組成的系列文章覆蓋了項目的第 1 個(gè)階段：以一系列需求、一個(gè)參考架構和代碼（理想的可重用的）為結果的概念的驗證。到目前為止，我們大概使用了整個(gè)第 1 階段預算的三分之一，但我們已經(jīng)接近了項目時(shí)間進(jìn)度的一半了。這是在我們的預料之中的，因為我們有意的讓進(jìn)度稍微慢一點(diǎn)。分析和計劃活動(dòng)總是以較慢的步伐移動(dòng)，團隊應該在項目開(kāi)始時(shí)逐步的將他們建立起來(lái)。

因為第 1 階段要求一個(gè)相關(guān)的結構化的和正式的概念的證據，我們將它作為一個(gè)小的項目處理，通過(guò)在演進(jìn)的產(chǎn)品上進(jìn)行測試和 QA（同級審查）來(lái)完成它。RUP 有一些用于開(kāi)發(fā)概念證據的機制，基本在分析和設計工作流的執行架構的合成的活動(dòng)中。我們正在進(jìn)一步的將概念的證據轉化成可用的 beta 版產(chǎn)品。我們能夠將更多的功能、風(fēng)險的降低和產(chǎn)品的成熟放到這個(gè)階段中，我們越多的將技能和知識用到系統的產(chǎn)品版本中，我們的客戶(hù)就越高興。

這個(gè)接下來(lái)的一系列的任務(wù)將比之前的活動(dòng)更加具有技術(shù)性。我們正很好的向架構。設計、數據建模和原型前進(jìn)。在第 4 部分中我們討論了一些原型和評估如何進(jìn)行我們的工具選擇；現在我們的原型的關(guān)注點(diǎn)在測試我們設想的需求、系統說(shuō)明和設計上。

架構和設計活動(dòng)是在 ASDI 項目中最令人愉快和具有創(chuàng )造力的任務(wù)。我們?yōu)槲覀儗⑾到y計劃的高效、安全和簡(jiǎn)單優(yōu)雅而自豪。技術(shù)方案的遠景在多次令人興奮的會(huì )面、自由討論和技術(shù)探索中最終形產(chǎn)生了。

簡(jiǎn)單的講，架構意在捕獲技術(shù)上靈活的方案，這個(gè)方案可以覆蓋上個(gè)月我們定義出來(lái)的系統需求。不論是向前看（對于設計）還是向后看（對于需求），架構團隊都將承受巨大的壓力。 Rational Rose 的集成開(kāi)發(fā)環(huán)境通過(guò)讓我們能夠做以下的事情簡(jiǎn)化了這個(gè)挑戰：

使用 SoDA 產(chǎn)生文檔以允許架構和設計元素的分發(fā)，簡(jiǎn)化了檢查并保持每個(gè)人都有一致的當前遠景。

從場(chǎng)景直接更新類(lèi)的簽名（方法和屬性），以使我們不必回到類(lèi)的說(shuō)明中添加缺少的方法。

為自動(dòng)化的任務(wù)比如產(chǎn)生類(lèi)的骨架、檢查模型的命名習慣和測試模型的完整性和有效性生成 RoseScripts （可以通過(guò)訪(fǎng)問(wèn) Tools 菜單得到）。

使用 Rose 的 RUP 模板，提供一個(gè)附帶 RUP 指南的模型框架。

在 Rose 中從提供的 J2EE 類(lèi)框架中拖出類(lèi)。

用 Rose 的”單元控制“特性將模型分解成為能夠被團隊進(jìn)行版本控制和并行工作的片斷。

注意，因為我們在過(guò)去的項目中創(chuàng )建的系統與目前這個(gè)系統類(lèi)似，因此如果我們引用一些參考架構，我們的架構將會(huì )從中受益。然而，我們不能在已存在的包或者設計模式中找到任何可重用的機會(huì )，因此我們只是引用了已存在系統中可能會(huì )在將來(lái)用到的思想和類(lèi)。

從用例到設計類(lèi)的轉化過(guò)程是緩慢的，需要進(jìn)行多次的迭代。這牽扯到分析人員和設計人員，因為我們有很少的既可以舒服的與客戶(hù)討論業(yè)務(wù)領(lǐng)域又可以使用特定的工具進(jìn)行分析、細化設計產(chǎn)物的人員。

這個(gè)活動(dòng)的目標

有時(shí)將需求直接的轉換成代碼是誘人的。實(shí)際上，我們在以前的項目中就是這樣做的（因為我們有非常詳細的需求說(shuō)明），我們在我們對項目的理解上非常自信。這樣就產(chǎn)生了一個(gè)錯誤。需求被遺漏，范圍很難被跟蹤，并且大量的工作和返工是無(wú)用的。使用設計模型來(lái)連接在需求和代碼之間的鴻溝是重要的；設計模型可以在開(kāi)發(fā)和測試之前很久捕獲錯誤和有問(wèn)題的假設。

在從用例向設計類(lèi)轉化的過(guò)程中，我們希望能夠實(shí)現：

將分析小組的知識傳授給工程團隊。

識別能夠滿(mǎn)足所有需求的技術(shù)方案 — 或者，什么地方不是可能的，識別與技術(shù)方案沖突的需求，并確定是否他們是重要的或者被改變或者被刪除。

識別能夠幫助確定團隊結構、架構層次和對于購買(mǎi)軟件的候選的接口。

指定技術(shù)方案的細節并開(kāi)始計劃如何在團隊之中分配工作。

基于設計模型的細化時(shí)間進(jìn)行計劃和預算的預估。

分配類(lèi)到平臺、產(chǎn)品和私有代碼。

為了反饋和同步的目的，生成軟件架構文檔，軟件架構文檔能夠被分發(fā)到內部和外部的團隊成員。

實(shí)現穩定的設計

從用例和分析類(lèi)到設計和設計類(lèi)的轉化是不可避免的模糊的。在我們能夠擁有我們感到滿(mǎn)意的設計之前，我們需要做大量的工作。圖 1 顯示了我們以我們的方法定義一個(gè)穩定的設計的主要活動(dòng)。

圖 1: 從用例模型到設計模型的轉化

前面的文章部分討論了多數的在圖 1 中作為”架構“準備的活動(dòng)和產(chǎn)物（特別是 SOW 需求、用例、業(yè)務(wù)對象模型和分析類(lèi)）。此外，這些其他的活動(dòng)對設計工作也是重要的：

確定包的結構

建模數據（創(chuàng )建數據庫計劃）

創(chuàng )建原型和屏幕模擬

這些將在接下來(lái)的部分連同如何處理新的和改變的需求一起被討論。

在開(kāi)始考慮設計類(lèi)之前，整個(gè)團隊要對一個(gè)良好的包結構達成一致同意。不管我們最后的決定是什么，它都應該成為設計過(guò)程中的指導方針，所有團隊成員都要遵守這個(gè)指導方針。

我們一直在爭論是按照子系統（圖 2）來(lái)劃分包還是按照架構的層次來(lái)劃分（圖 3）。表 1 列出了每種方法的有點(diǎn)和缺點(diǎn)。

圖 2: 按照子系統定義包

圖 3 : 按照架構的層次進(jìn)行包的劃分

方法優(yōu)點(diǎn) 缺點(diǎn)

按照子系統定義包它簡(jiǎn)化了模型的管理。復雜的子系統能夠以單一的 *.cat 文件或者 *.cat 文件的層次被分配給大的團隊。

對于在子系統之間不合規定的依賴(lài)可以容易的測試出來(lái)。

它簡(jiǎn)化了對項目增量的計劃。

它鼓勵減少子系統，使架構更容易被看懂。

它增加了子系統重用的可能性。

子系統之間的一致性和被共享的關(guān)系將更難的被協(xié)調。例如，DBA 也許要更加努力的理解數據層的藍圖，或者數據抽象類(lèi)和計劃實(shí)體之間的依賴(lài)。

它能夠促進(jìn)來(lái)自于通用服務(wù)包的令人泄氣的重用哲學(xué)。

按照架構層次劃分包層次之間的一致性要被維護。

它隔離了不同的技術(shù)領(lǐng)域：在用戶(hù)界面層的JavaServer Pages (JSP)；在業(yè)務(wù)邏輯層的 EntERPrise JavaBeans (EJB) 和Servlets ；實(shí)體 bean 、類(lèi)和數據層的表。

它增加了重用系統架構的可能性。

不是所有的代碼都是恰好的符合三層架構中的一層。

對于一個(gè)子系統，團隊領(lǐng)導或者遠程團隊必須檢出（check out）幾個(gè) *.cat 文件來(lái)更新或者獲得子系統模型的所有權限。

如果不將所有的模型都檢出（check out），通常很難報告或者呈現一個(gè)具體的子系統。

表 1: 打包方法的比較

最終我們使用了第一種方法，按照子系統來(lái)劃分設計模型。我們覺(jué)得系統是足夠小的，我們可以保持好子系統之間的一致性。

我們的頂層的包結構的一個(gè)最初草稿就象圖 4 。你可以從頂層的包中看到被識別的子系統（因此，原型 <<subsystem>> 被分配給了每一個(gè)子系統）。

圖 4: 頂層包的結構

在我們將這個(gè)早期的草稿變成最終穩定的包結構之前，我們進(jìn)行了大量的討論。下面是我們關(guān)注的一些問(wèn)題：

我們如何組織通用的服務(wù)？

回答：公用服務(wù)被單獨的放在一個(gè)子包中（日志服務(wù)；數據同步和備份服務(wù)；訪(fǎng)問(wèn)控制服務(wù)和登陸服務(wù)）。

我們應該在 shipping 和 part management 之間畫(huà)線(xiàn)嗎？

回答: 我們不需要連接他們兩個(gè)。

我們根據領(lǐng)域還是架構來(lái)定義子系統？

回答：架構在大多數地方都能與領(lǐng)域結合。

我們允許包之間的雙向依賴(lài)嗎？

回答：不。這是違背我們內部設計指導方針的不好的設計實(shí)踐。

作為一個(gè)例子，我們將著(zhù)重關(guān)注在 command gateway 子系統上。雖然系統的很多地方都是以一個(gè)內部的和外部的Web 接口為中心的，我們還是計劃提供一個(gè)安全的、基于 XML 的命令網(wǎng)關(guān)（command gateway），這個(gè)命令網(wǎng)關(guān)允許 ASDI 的系統與它的大客戶(hù)之間的形成一個(gè) B2B（business-to-business）的接口。這個(gè)特性允許這些客戶(hù)能夠從他們已有的系統對 ASDI 查詢(xún)、提交和更新信息。這是非常重要的，因為一些公司的需求是不能通過(guò) Web 接口訪(fǎng)問(wèn)，相反他們需要的來(lái)自與公司的代號的批量的或者是幕后的提交。

在每一個(gè)包中，我們最初的類(lèi)圖都來(lái)自于我們的用例、業(yè)務(wù)對象模型、注釋和訪(fǎng)談。圖5 顯示了 command gateway 子系統從早期的思想到詳細的設計的演進(jìn)過(guò)程。

圖 5: command gateway 的初始設計

在這個(gè)第一輪的設計中，我們簡(jiǎn)單的識別出 command gateway 子系統的主要部分，在這個(gè)層次上存在著(zhù)必須被關(guān)注的問(wèn)題：

我們使用 XML 嗎？（問(wèn)題包括寬帶消費、穩定性和解釋器的成熟性）。

我們要向客戶(hù)發(fā)送和接收數據嗎？

我們要提供命令的客戶(hù)端軟件或者僅僅為此發(fā)布命令的規范？

我們要通過(guò) SSL（Secure Sockets Layer）、HTTP 或者私有的套接字通訊傳輸 XML 嗎？

在后續的設計中（圖 6 ），我們識別出了在系統中的更多依賴(lài)關(guān)系，并開(kāi)始識別看起來(lái)象實(shí)現類(lèi)的東西。我們仍然在爭論高級別的概念，因此我們對文檔和類(lèi)的簽名并不感興趣（方法和屬性）。文檔和類(lèi)的簽名應該在我們覺(jué)得設計開(kāi)始穩定時(shí)被填充進(jìn)去。

圖 6: command gateway 的中期設計

(點(diǎn)擊放大)

就像圖 7 顯示的那樣，我們后來(lái)細化了一些我們識別出的依賴(lài)關(guān)系、適當的方法和屬性（被隱藏在圖中以節省空間），并且添加了一些技術(shù)的細節。例如，通過(guò)建立原型我們識別出將JSSE (Java Secure Socket Extension) 作為在客戶(hù)和服務(wù)器之間的 SSL 連接的方案。JSSE 被直接集成到了JDK 1.4 中，當對 JDK 1.4 以前的版本它只是一個(gè)附加的部分。

圖 7: 成熟的 command gateway 設計

(點(diǎn)擊放大)

這個(gè)設計還不是最終的。雖然設計已經(jīng)通過(guò)眾多的場(chǎng)景圖被測試過(guò)了，但是在接下來(lái)的數周和數月的編碼中將發(fā)現設計中不正確的地方或者或者遺漏的細節。

當我們進(jìn)行架構和設計時(shí)，我們識別出了添加新的需求或者對已有系統需求進(jìn)行細化的需要。忽略一些小的變更是誘人的，但是我們看到需要相當多的預算來(lái)完成變更。在預算上的小的缺口將增加需要的時(shí)間，并給客戶(hù)一個(gè)不好的先例。我們發(fā)現跟蹤所有的添加和變更將有助于我們用檢查保持期望，并迫使我們問(wèn)，“在將來(lái)我們真的需要這個(gè)嗎？” 這是一個(gè)我們通常忽略的關(guān)鍵點(diǎn)：如果一個(gè)需求不是足夠重要進(jìn)入系統，那么這個(gè)需求就不值得去實(shí)現。

有時(shí)，需求的引入會(huì )對已有的進(jìn)化和預算帶來(lái)負面的影響。這就要求我們坐下來(lái)和客戶(hù)討論選擇 — 但是首先，我們應該在我們內部進(jìn)行討論，以便我們能可信的向客戶(hù)提出備選方案，而不是簡(jiǎn)單的“即興表演”。選擇通常包括以下的方面：

推遲需求。這通常發(fā)生在需求不是都重要的時(shí)候，或者是其他的需求沒(méi)有目前正在構建的需求那么重要。

去掉需求。這發(fā)生在需求更本不重要的時(shí)候。

用一個(gè)新的需求代替一個(gè)已有的需求。如果已存在的需求不是重要的或者這至少不是特別緊急的，我們可以推遲或者去除這個(gè)需求來(lái)為新的需求在時(shí)間進(jìn)度和預算上騰出空間。

添加需求到目前的工作中。這種選擇僅僅在不會(huì )引入不可接受的風(fēng)險到已存在的需求和整個(gè)系統計劃時(shí)才被考慮。添加任何重要的需求自然會(huì )要求額外的時(shí)間和預算。

對用例進(jìn)行變更不是問(wèn)題，因為我們對用例進(jìn)行了嚴格的版本控制，并可以直接的在模型中更新他們。此外，Rational RequisitePro 的使用將編程集成回到 SOW 中也是容易的。然而，追溯我們所希望的，我們已經(jīng)花費時(shí)間建立了 Rational ClearQuest 來(lái)管理需求的變更。有時(shí)變更是被內部識別出來(lái)的，但是更多的情況是有外部的請求產(chǎn)生的。我們的變更管理過(guò)程是非常笨拙的，包括每月的會(huì )議、硬拷貝的文件等等。更加無(wú)縫的變更請求過(guò)程幾乎會(huì )為控制范圍的增長(cháng)、產(chǎn)生更好的系統和更高的和約價(jià)值帶來(lái)的更多的機會(huì )。

當我們開(kāi)始進(jìn)行上面所描述的設計工作的同時(shí)，我們也開(kāi)始建模數據了。在以前的項目中，我們使用 Rational Rose 進(jìn)行設計，并發(fā)現在持久類(lèi)和暫時(shí)類(lèi)之間的分割有點(diǎn)笨拙：一旦我們識別出了一個(gè)用于持久存儲的類(lèi)，我們便設置它的持久屬性并開(kāi)始用其他的工具對他建模。在 ASDI 項目中，我們使用了集成在 Rational Rose Enterprise 中的 data modeler 進(jìn)行數據建模，并且發(fā)現過(guò)度更加的成熟。

實(shí)際上，我們最初在使用老方法上范了一個(gè)錯誤 — 將持久對象放到他們自己的文件夾中，并遺忘了他們 — 但是，我們自己發(fā)覺(jué)了他們并使用 Rose 將這些對象轉換成了數據模型。將所有收集到的持久類(lèi)放入一個(gè)包中，我們可以通過(guò)鼠標右鍵點(diǎn)擊包，并轉換他們成為數據模型（通過(guò)從上下文菜單選擇 Data Modeler > Transform to Data Model ）。

數據建模器在 Rose 模型中創(chuàng )建了一個(gè)數據庫計劃。我們后來(lái)將這些計劃從它的邏輯表示轉化成了一個(gè)物理的DB2 安裝，并給工程團隊訪(fǎng)問(wèn)表和測試數據。

作為架構和設計的基礎，良好的分析是重要的，但是原型也是非常有價(jià)值的。很多的主意在紙上看起來(lái)很好，但我們的假設只有原型才能提供的證據。

工程團隊非常喜歡原型活動(dòng)。典型的對這些活動(dòng)的時(shí)間計劃是非常自信的，目標是模糊的，技術(shù)是新的，并且 QA 輕松的，因此原型通常是很有趣的 — 金錢(qián)的大量浪費。我們發(fā)現如果原型沒(méi)有清晰的、可測量的目標，它很快就會(huì )淪落到“我能做什么...”的境地，而不是降低風(fēng)險的任務(wù)。

我們通常盡力與 RUP 的演進(jìn)產(chǎn)品理論保持一致，RUP 可以指導我們將我們所有的原型演化成最終的產(chǎn)品。事實(shí)上，我們對快速的探索保留了術(shù)語(yǔ)“原型”。為了從原型中釋放出最大的價(jià)值，我們經(jīng)常忽略代碼的標準、同級檢查和類(lèi)似的過(guò)程。原型的一些方面（類(lèi)的說(shuō)明、設計模式或者編碼習慣）也許可以被重用，但是我們在重用這一點(diǎn)上給團隊非常小的壓力。相反，我們的原型的結果通常被總結成為技術(shù)注釋或者成為可以被活來(lái)項目參考的樣例應用。

馬上，一個(gè)工作包必須被起草。對它的開(kāi)發(fā)人員來(lái)說(shuō)這個(gè)包能夠概括特定原型的目標。我們?yōu)槊總€(gè)原型分配了預算和時(shí)間計劃，這里包括了任務(wù)完成之前的中期檢查。

我們不總是通過(guò)直接的編碼來(lái)創(chuàng )建原型的。有時(shí)我們通過(guò)在寫(xiě)任何代碼之前進(jìn)行學(xué)習來(lái)執行工具的評估。當評估數據庫時(shí)，比如，我們基于我們的經(jīng)驗、供應商提供的信息和第三方的檢查從類(lèi)表中去掉一些候選工具。

我們發(fā)現幾種很好的構建原型和工具選擇的方法：

審查（讀、反復查看、面談）

編碼（深入的代碼片斷可以探察特定的接口、需求或者性能問(wèn)題，并且明朗的、簡(jiǎn)潔的代碼片斷可以顯示連接性、工作流和可用性）

原型的安裝和演示

工具提供商的演示

良好運用原型的關(guān)鍵在于決定原型的實(shí)現的程度。很少有原型能夠在推薦中被設計成為給人 100% 的信心。相反，原型必須演示足夠的結果以減少風(fēng)險到可以忍受的級別。

表 2 列出了一些我們在這個(gè)項目中采用的特定原型活動(dòng)。

原型活動(dòng) 結果

研究（覆蓋特性、成本和性能）Orion Application Server 的選擇（更多信息，看第 4 部分）

OOBD 的評估（覆蓋特性和市場(chǎng)份額），以滿(mǎn)足客戶(hù)的偏愛(ài)決定放棄使用 OODB（更多信息，看第 4 部分）

研究關(guān)系型數據庫（覆蓋特性、成本和性能）選擇 DB2 （更多信息，看第 4 部分）

JSSE 評估（覆蓋復雜性、穩定性和安全性）在 B2B 方案中包括 JSSE