應用 Rational 工具簡(jiǎn)化基于 J2EE 的項目第 6 部分 ：早期開(kāi)發(fā)
文章發(fā)表:jackei 發(fā)表日期:2005-03-30 閱讀次數:138
本文是演示了在分布式的、基于
J2EE 的項目中使用
Rational 工具的系列文章（如下面所列）的第
6部分。
645 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 部分。
本文討論了團隊的進(jìn)展進(jìn)入了實(shí)現階段，并且因此進(jìn)入了 RUP 的構建階段。我們挑選了在 ASDI 項目的第一階段被使用的大
部分技術(shù)。設計的情況相當的好，雖然在本系列的
第五部分中被討論的包的結構和設計在未來(lái)的一到兩周內還將繼續的演進(jìn)。例如，包結構的
部分被重新定義來(lái)反映預期的 Java 包命名習慣。
第
6部分快照
在第
6部分演示的工具和技術(shù)：
Rational Rose 企業(yè)版 — 支持雙向工程
Rational Purify — 用于檢查 Java 內存的使用情況
Rational Quantify — 用于了解性能瓶頸
J2SE （Java 2 平臺標準版） 1.3 — Sun 的 Java 參考實(shí)現
Jikes — IBM 的高速編譯器（Sun 的 Javac 的替代物）
Castor — 來(lái)自于 ExoLab Group 的數據綁定框架，用于綁定 XML 到 Java ，反之亦然。
被創(chuàng )建或者更新的產(chǎn)物：
設計模型 （
Rational Rose） — 隨著(zhù)代碼的發(fā)展被更新 Java 代碼 — 為 command gateway 和其他的子系統而創(chuàng )建
在能夠進(jìn)行開(kāi)發(fā)之前，我們必須在管理和團隊領(lǐng)導的層面上完成下面的事情：
建立指導方針和非正式的培訓以便工程團隊都能夠遵守相同的編碼和設計約定。 更新原有的團隊結構（在本系列的
第二部分被顯示的）來(lái)反映與設計不同的實(shí)現需要。 建立開(kāi)發(fā)策略和環(huán)境，以使我們的開(kāi)發(fā)人員能夠有效的協(xié)同工作，使開(kāi)發(fā)人員可以在自己的系統
部分工作而不會(huì )影響其他人，并且方便的測試他們的代碼。 適當的緊密跟蹤以確保任務(wù)能夠按計劃完成并滿(mǎn)足他們的目標。
RUP 強調在一個(gè)產(chǎn)品被構建時(shí)同級評審的重要性；我們將在后面了解更多的細節。團隊必須對同級評審的標準達成一致意見(jiàn)，以避免走向兩個(gè)極端：松散的評審將帶來(lái)非常微小的價(jià)值，或者過(guò)度嚴格的評審將產(chǎn)生大量的注釋行，比如"這個(gè)被實(shí)現了，但這里我是如何實(shí)現的"的注釋。
對于我們的 Java 代碼，我們創(chuàng )建了一個(gè)基于
AmbySoft Inc. Java 編碼標準的編碼標準文檔。這些標準被證明在我們進(jìn)行同級評審中是意義重大的。這些標準不僅可以幫助我們?yōu)榭蛻?hù)產(chǎn)生更加一致的和高質(zhì)量的交付系統，而且還允許我們的團隊成員更加容易的在不同的子系統（和項目）之間進(jìn)行調整。我們發(fā)現如果開(kāi)發(fā)人員們對編碼的形式和構建非常熟悉的話(huà)，他們將能夠非?？斓娜谌氲浇y一的團隊之中。通過(guò)避免使用模糊的命名習慣、不充分的注釋和不好的編碼風(fēng)格，開(kāi)發(fā)人員能夠創(chuàng )建出使其他開(kāi)發(fā)人員更加容易接手的代碼。
通常的情況下，工程師們都在盡力的學(xué)習被需要的技術(shù)以在業(yè)務(wù)上保持競爭力；然而，一些項目也會(huì )引入一些需要團隊培訓的新技術(shù)。我們在 ASDI 項目中并沒(méi)有處于這種情況下，因為這個(gè)項目中使用的架構和技術(shù)都是我們所熟悉的。我們在這個(gè)項目中的培訓是關(guān)于
Rational 工具的使用、UML 、Java 編碼標準和
J2EE 設計模式的。雖然我們在這些領(lǐng)域有著(zhù)非常好的知識背景，但是這些知識多數是在團隊領(lǐng)導的頭腦里。因此，培訓由非正式的午餐時(shí)間和被團隊領(lǐng)導發(fā)起的下午會(huì )議組成。我們發(fā)現這些維持在一個(gè)小時(shí)到半天的會(huì )議是非常成本高效的（但前提是，你必須要有具有充足知識和良好溝通能力的團隊成員）。
因為我們的話(huà)題是與整個(gè)公司相關(guān)的，因此我們鼓勵其他的技術(shù)人員參與到這些培訓會(huì )議中。我們發(fā)現有更多的技術(shù)人員參與將會(huì )引發(fā)更加有價(jià)值的思想上的交換。最其碼，我們計劃能夠讓 ASDI 項目中所有的工程師都參加的會(huì )議（不論是參與分析、設計、實(shí)現或者測試的工程師）。
團隊的結構從在系統的分析期間演變到了為滿(mǎn)足實(shí)現期間的不同需要的結構。如表 1 所示，大量時(shí)間上的約定發(fā)生了變化，并且有五個(gè)新的職位被加了進(jìn)來(lái)。
角色 分析期間實(shí)現期間
項目管理項目經(jīng)理50%25%
財會(huì )支持15%25%
質(zhì)量保證10% 25%
項目工程項目工程師50%25%
團隊領(lǐng)導/高級分析人員100%75%
工程支持，除了配置管理（CM）20% 10%
工程支持: 配置管理20%40%
支持和評審團隊10%5%
高級開(kāi)發(fā)人員100%100%
初級開(kāi)發(fā)人員100%100%
數據庫架構師25%25%
高級開(kāi)發(fā)人員（遠程）—100%
中級開(kāi)發(fā)人員（遠程）—100%
初級開(kāi)發(fā)人員（遠程）—100%
集成和測試（I&T）領(lǐng)導—50%
I&T 初級成員—100%
表 1:團隊結構的演進(jìn)
團隊結構的變化和變化背后的原因被總結如下：
項目管理減少，關(guān)注點(diǎn)放在了客戶(hù)的接口和預算的跟蹤上。 財會(huì )的支持增加，因為我們的目標是在每一個(gè)任務(wù)進(jìn)度上的更加精確和低粒度的報告。 質(zhì)量保證增加了。我們需要這個(gè)角色來(lái)確認代碼評審的進(jìn)行和工程的筆記簿被開(kāi)發(fā)人員維護等等。 項目工程增加了，高級分析人員角色加上團隊領(lǐng)導角色減少了。因此，項目工程和團隊的領(lǐng)導層（分別下降到了 25% 和 75%）被合并成了一個(gè)全職的職位。 除了配置管理之外，工程支持增加了，因為到現在為止多數的基礎架構（也就是，計算機硬件）是時(shí)候被用到了。配置管理增加了以允許集成和測試人員參與構建，同時(shí)也支持用于版本控制的配置管理的存儲。 支持和評審團隊的工作增加了，因為我們要讓他們?yōu)榇蟮膯?wèn)題把關(guān)。多數的代碼評審是通過(guò)團隊的同級評審完成的。
這些職位被增加：
高級的、中級的和初級的開(kāi)發(fā)人員，他們支持著(zhù)增加的開(kāi)發(fā)工作。這些團隊成員在總部中進(jìn)行著(zhù)遠程的開(kāi)發(fā)活動(dòng)，提供“后端系統”的專(zhuān)家意見(jiàn)。（我們原計劃將項目的管理移到總部進(jìn)行，但是項目當前的安排正在很好的進(jìn)行工作，因此我們都同意繼續保持在項目中的協(xié)調方式。） 一個(gè)集成與測試的團隊有一名領(lǐng)導和一個(gè)初級的成員組成。領(lǐng)導成員起草最初的測試說(shuō)明書(shū)，制定高級的測試計劃，并且指導初級成員使他能夠以生成測試數據、編寫(xiě)測試腳本和書(shū)寫(xiě)測試文檔的形式為測試提供支持。
后來(lái)我們發(fā)現，我們的團隊結構也許是太具有殺傷力了，因為我們的工具僅僅是為了實(shí)現在第一階段中的概念的驗證的。我們也許應該在沒(méi)有太大傷害的前提下調整一下系統的構建和質(zhì)量保證的正式過(guò)程，并且依然要滿(mǎn)足我們的第一階段的目標。最后，我們建立了高質(zhì)量的概念的驗證，而且比我們最初預想的為第二階段的工作提供了更多的可重用性。
一些之前的項目要求我們在共享的開(kāi)發(fā)環(huán)境下工作，并且這經(jīng)常是痛苦的源頭。工作在公共代碼之上的開(kāi)發(fā)人員經(jīng)常會(huì )打斷開(kāi)發(fā)過(guò)程中其他的軟件
部分的工作。我們有時(shí)因為架構上的或者許可證上的限制被要求在一個(gè)共享的環(huán)境下工作，但是我們還是希望在每一個(gè)開(kāi)發(fā)人員的機器上擁有一個(gè)獨立的環(huán)境。我們計劃以一種正規的基礎將開(kāi)發(fā)人員的組件集成到一起。
在 ASDI 的項目中，提供獨立的開(kāi)發(fā)環(huán)境是容易的，甚至對于我們的遠程辦公也是如此。僅有的共享方面是 DB2 的數據庫，但是我們能夠為每一個(gè)開(kāi)發(fā)人員建立獨立的數據庫計劃（schema），這樣就可以去除任何的潛在的問(wèn)題。此外，我們?yōu)槲覀兊墓こ虉F隊設置每一個(gè)類(lèi)被一個(gè)單一的開(kāi)發(fā)人員所“擁有”。我們發(fā)現這非常好的減少了我們的合并與修改的工作。我們從來(lái)不相信以 CVS （Concurrent Versioning System）方式在一個(gè)源文件上實(shí)現并行開(kāi)發(fā)的哲學(xué)，因為在一個(gè)方法上的改變將會(huì )帶來(lái)在其他方法上的細微但又重大的影響。我們覺(jué)得最安全的方法是將每個(gè)類(lèi)實(shí)現的責任交給單獨的團隊成員。
關(guān)于我們的特定開(kāi)發(fā)環(huán)境，我們發(fā)現 Orion
6%D3%C3">應用服務(wù)器、
Rational Suite DevelopmentStudio 、J2SE JDK 和 DB2 客戶(hù)端軟件能夠很容易的符合 P-III 500 和 25
6 M 內存的機器。Orion 驚人的小的足跡和高效的設計是他能夠在這樣低的硬件配置的機器上運行的主要因素。
基本的開(kāi)發(fā)周期在圖 1 中被顯示出來(lái)（它大量的借用了 RUP 的內容）。
6.jpg" width=420>
圖 1: 開(kāi)發(fā)周期
每一個(gè)開(kāi)發(fā)人員最初從基線(xiàn)設計說(shuō)明開(kāi)發(fā)工作。開(kāi)發(fā)的的第一個(gè)迭代包括使用
Rational Rose 作為起始點(diǎn)生成代碼的框架。一系列的迭代（包括時(shí)常發(fā)生的小的構建）都是從這里開(kāi)始的。開(kāi)發(fā)人員非正式的對早期的迭代進(jìn)行單元測試，同時(shí)也與團隊的領(lǐng)導協(xié)商任何與設計的背離。小的設計變化可以通過(guò)電子郵件進(jìn)行溝通，然而重大的變化需要一對一的討論以確保變化是適當的并且不會(huì )對系統的其他方面做成負面的影響。顯然，任何對接口（甚至是公用方法）的變化要求特別細致的檢查和沖突分析。設計要定期的通過(guò)逆向工程進(jìn)行更新，合并任何的變化回到 Rose 模型中以維護系統的最新畫(huà)面。
回顧一下，我們希望我們投入更多的工作在場(chǎng)景上。如果我們的場(chǎng)景已經(jīng)演示了系統的大
部分，我們就能夠在 Rose 中使用報告來(lái)顯示類(lèi)之間的詳細依靠了。這將使我們可以產(chǎn)生關(guān)于特定變化的影響的更具有根據的推測。而不是，我們必須編寫(xiě)腳本來(lái)根據被配置管理的代碼進(jìn)行文本的搜索以確定誰(shuí)正依靠著(zhù)給定類(lèi)的特定的方法。
當遇到復雜的事情和問(wèn)題時(shí)，他們將被交給團隊的領(lǐng)導。通常團隊領(lǐng)導或者親自的協(xié)助解決問(wèn)題，或者讓開(kāi)發(fā)人員解決問(wèn)題，再或者使用來(lái)自其他團隊或者公司的幫助解決問(wèn)題。有時(shí)，我們會(huì )遇到技術(shù)上的需要與客戶(hù)討論的問(wèn)題和后續的需求本身的更新問(wèn)題。例如，我們的一些安全方面需求的遵循
JSSE64150 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">（Java Secure Socket Extension） API 的變化。
一旦代碼被充實(shí)起來(lái)，開(kāi)發(fā)人員編譯一系列的單元測試，集成與測試團隊創(chuàng )建一系列的組件測試，他們被設計用來(lái)測試性能、功能和可靠性方面的需求。在完成了代碼和單元測試之上，開(kāi)發(fā)人員要為同級評審過(guò)程（后面被描述）組裝一個(gè)評審包并等候反饋。評審過(guò)程有時(shí)會(huì )導致設計的修改，其他時(shí)候算只是簡(jiǎn)單的識別出一些 bug 或者需要增強的地方。
因為我們只是剛剛開(kāi)始實(shí)現的工作，因此我們不準備使用來(lái)自于
Rational ClearQuest 的缺陷統計功能作為測量我們的進(jìn)展
部分。相反，我們依靠?jì)蓚€(gè)主要的信息來(lái)源：任務(wù)報告和小的里程碑。
任務(wù)報告以每周為基礎被開(kāi)發(fā)人員提交。這些報告能夠指出最近一周的任務(wù)工作完成情況和在任務(wù)中的預算的花費情況，并且可以估計任務(wù)中剩余的工作量。任何阻礙任務(wù)進(jìn)展的障礙也會(huì )在每周的總結中被報告。
小的里程碑甚至是更加關(guān)鍵的，因為他們有時(shí)揭示了重要的問(wèn)題。團隊領(lǐng)導經(jīng)常要求小版本的構建、非正式的星期五下午的演示、代碼預演或者甚至是當場(chǎng)的代碼檢查。如果我們發(fā)現一個(gè)團隊或者團隊成員不能在時(shí)間期限內實(shí)現一個(gè)適當產(chǎn)品的里程碑，這有時(shí)意味著(zhù)存在需要幫助的問(wèn)題。
軟件工程的目標是在給定的時(shí)間和預算內產(chǎn)出高質(zhì)量的軟件。質(zhì)量的精確定義從團隊到團隊，從項目到項目會(huì )有所不同。對于工程團隊來(lái)說(shuō)質(zhì)量相關(guān)的目標包括：
容易維護的代碼 保證所有的需求被實(shí)現 可靠的操作 足夠的性能 清晰的文檔 可擴展的設計 符合時(shí)間計劃和預算
我們發(fā)現
Rational 工具能夠幫助我們滿(mǎn)足這些要求中的很多。為了舉例說(shuō)明
Rational 工具能夠在哪些地方幫助我們，這
部分將重點(diǎn)集中在客戶(hù)接口的 command gateway
部分。就像在本系列第五
部分所注明的，這個(gè)網(wǎng)關(guān)是一個(gè) B2B （business-to-business）接口，這個(gè)接口允許大公司可以查詢(xún) ASDI 的零件的可用性、提交訂單、更新他們的客戶(hù)信息和查詢(xún)運輸或者帳目狀態(tài)。
command gateway 的設計經(jīng)歷了一系列的迭代，已經(jīng)成為了被顯示在本系列的第五
部分成熟的設計；然而，一種情形引發(fā)了遠程的高級開(kāi)發(fā)人員得到與設計的同步。她在她自己負責的
部分提出一些優(yōu)秀的想法，并且我們能夠通過(guò)雙向工程合并他們 — 也就是說(shuō)，通過(guò)逆向工程她的改變合并到我們的 Rose 模型中。這種簡(jiǎn)單的設計與最新代碼變化的同步對于維護我們系統的質(zhì)量是十分重要的，因為我們的大多數事情都是圍繞著(zhù)設計模型進(jìn)行的。
command gateway 通過(guò)遠程被開(kāi)發(fā)（在總部），因為他們具有在 Java 、 XML 和 JSSE 方面的豐富的經(jīng)驗。我們在周五將最新的設計發(fā)給高級的開(kāi)發(fā)人員，并且計劃在接下來(lái)的星期通過(guò)電話(huà)會(huì )議來(lái)討論設計。然而，開(kāi)發(fā)人員那個(gè)星期五病了，并且沒(méi)有收到設計；實(shí)際上她并不知道任何我們已經(jīng)完成的進(jìn)展的信息，因為我們的
最初設計并不是詳細的。在周末她在家中繼續的通過(guò)她的膝上型電腦進(jìn)行著(zhù)項目的工作，卻沒(méi)有意識到她已經(jīng)喪失了與 command gateway 設計的同步。
在接下來(lái)的電話(huà)會(huì )議中，高級的開(kāi)發(fā)人員詳細的談?wù)摿怂龑υO計的改進(jìn)、她對新技術(shù)引進(jìn)和她在整個(gè)開(kāi)發(fā)中的大的超前。這使團隊領(lǐng)導非常的驚訝，當然開(kāi)發(fā)人員聽(tīng)到了關(guān)于設計上的更新也是非常驚訝的。我們協(xié)商同意忽略最新的設計和開(kāi)發(fā)人員的工作以找到哪一種方法我們應該使用。
當我們選擇好方法之后，開(kāi)發(fā)人員的進(jìn)步是顯著(zhù)的，并且比我們以前的工作更加深思熟慮。她使用了一個(gè)開(kāi)放的產(chǎn)品
Castor，這個(gè)產(chǎn)品能夠封裝 XML 數據的映射到 Java 的對象，并且她合并了一些比我們提議的方案更加好的設計決定。因此，我們同意更新設計以反映她的良好的方法。
因為她開(kāi)始于她的草稿代碼，因此我們需要返回她的設計到我們的模型中。這是相當容易完成的：我們簡(jiǎn)單的提供給開(kāi)發(fā)人員我們最新的對于 command gateway 的 *.cat 文件，并且逆向工程她的代碼成為模型。在項目的稍后
部分，相似的情形逆向工程將會(huì )帶來(lái)巨大的幫助。
當我們進(jìn)行逆向工程時(shí)的第一個(gè)步驟是在 Windows 中設置 CLASSPATH 環(huán)境變量。這個(gè)環(huán)境變量的位置依賴(lài)于 Windows 的版本，但是典型的情況下你可以通過(guò)系統的控制面板找到它。（在 Windows 2000 中，查看面板的高級標簽。）如果 CLASSPATH 環(huán)境變量沒(méi)有被適當的設置，
Rational Rose 在評測代碼與外部的引用類(lèi)之間的關(guān)聯(lián)時(shí)遇到麻煩，通常會(huì )導致類(lèi)分析的失敗。在我們的例子中，我們必須設置這個(gè)變量為
D:\jdk1.3.1\jre\lib\rt.jar;j:\usr\local\lib\xerces\xerces.jar; j:\usr\local\lib\castor\castor-0.9.3-xml.jar
這個(gè)值指向了核心的 J2SE 類(lèi)的運行時(shí)庫和我們用來(lái)映射 Java 對象和 XML 數據的 Castor 的 XML 綁定類(lèi)。
然后我們定義項目的說(shuō)明，在
Rational Rose 中使用 Tools > Java > Project Specification 選項（彈出如圖 4 所示的對話(huà)框）。我們確認所有被發(fā)現的路徑，并且我們指出了在 Rose 中我們的代碼的根。
64>
6.gif" width=3
64>
圖 2: 在 Rose 中定義項目的說(shuō)明
接下來(lái)，我們選擇 Tools > Java > Reverse Engineer 選項，它彈出一個(gè)對話(huà)框（如圖 3 所示）提示我們選擇將要被分析的源文件。我們選擇我們感興趣的包 — asdi 類(lèi)，來(lái)引入高級開(kāi)發(fā)人員的所有代碼 — 然后點(diǎn)擊 Add Recursive 按鈕。然后我們選擇所有被列出的文件并點(diǎn)擊 Reverse 來(lái)逆向工程他們。
6.jpg" width=420>
圖 3: 在 Rose 中進(jìn)行逆向工程
在首先的幾次嘗試當中，我們意識到我們在設置我們的 CLASSPATH 環(huán)境變量時(shí)范了錯誤，導致在日值文件中出現了一些錯誤信息。（重要的是不要忽略這些錯誤，他們有時(shí)指出文件的解析完全的失敗了）。
6B>逆向工程的結果
一旦逆向工程被成功的完成，我們就能夠在我們的模型的邏輯視圖和組件視圖中發(fā)現被命名為 asdi 的包（見(jiàn)圖 4 和 5）。
6.gif" width=291>
圖 4:逆向工程產(chǎn)生的類(lèi)（邏輯視圖）
6.gif" width=359>
圖 5: 逆向工程產(chǎn)生的組件（組件視圖）
逆向工程在分析類(lèi)之間的關(guān)系上是相當有效的。當類(lèi)的變量被聲明為類(lèi)的成員變量時(shí)，找到所有權關(guān)系是更加可靠的。有些關(guān)系被獲取的并不正確（例如，在我們的 Java 代碼中通過(guò)本地范圍的實(shí)例變量創(chuàng )建的關(guān)系），因此一些繼續的檢查工作是必要的。
可以理解的是 Rose 沒(méi)有為代碼創(chuàng )建圖。在上百個(gè)類(lèi)中， Rose 沒(méi)有辦法知道如何進(jìn)行邏輯的分組這些類(lèi)來(lái)適當的表示系統的架構和設計。然而，所有類(lèi)之間的關(guān)系已經(jīng)被適當的生成了，產(chǎn)生設計和組件圖是相對容易的。在圖 8 中顯示的是在逆向工程后修改的網(wǎng)關(guān)設計。
6 src="http://www.kehui.net/articleimg/5898
中顯示的設計上的主要變化是引入和 Castor 的 XML 綁定的接口。我們不必做我們自己的分析（使用 Xerces-J 或者 XML4J）來(lái)進(jìn)行 XML 消息到對象的轉換，因為 Castor 顯然提供了這種映射的能力。Talker 類(lèi)封裝了 JSSE 的功能，并且 java.util.Vector 子類(lèi)提供了進(jìn)入消息的簡(jiǎn)單管理。Vectors 通過(guò) add(...) 和 remove(0) 的調用使先進(jìn)先出（FIFO）的查詢(xún)更加容易。一般情況下我們選擇 Vector 之上的 ArrayList ，但是因為查詢(xún)必須是在線(xiàn)程之間共享的，我們同意使事情保持簡(jiǎn)單。（Vector 是同步的，但是 ArrayList 不是，它要求 Collections.synchronizedList() 被使用）
一個(gè)與新的 command gateway 方法相關(guān)的風(fēng)險是不確定的關(guān)于 Castor 的序列化 API 的性能問(wèn)題。使用經(jīng)過(guò)長(cháng)期測試的 XML 解釋器，我們知道他們的內存使用和性能在負載條件達到高峰時(shí)是足夠的。我們需要評估 Castor 產(chǎn)品以確保它能夠符合我們的系統性能的要求。
Quantify 來(lái)觀(guān)察 Castor 的行為。這些工具允許我們精密的檢查資源的需求和運行時(shí) Castor 的行為。為了方便起見(jiàn)，而不干擾實(shí)現整個(gè) JSSE 客戶(hù)端和服務(wù)器端的代碼，我們決定去掉 JSSE 的功能（在
我們想要了解被 Castor 引擎需要的資源的水平。使用這個(gè)開(kāi)放源碼的產(chǎn)品對于我們的項目是稍微有一點(diǎn)冒險，因此我們需要確保它是仿彈的并且不是嚴重吞噬資源的。我們設計了一些通宵運行的單元測試來(lái)找出任何內存的泄漏或者穩定性的問(wèn)題。
在 C 或者 C++ 項目中，我們已經(jīng)強制在組件上運行 Purify 來(lái)預防進(jìn)入產(chǎn)品代碼的內存訪(fǎng)問(wèn)的違規。使用 Java ，象讀空指針、內存泄漏和數組越界的問(wèn)題已經(jīng)不是什么問(wèn)題了；然而，Purify 依然在分析 Castor 中為我們提供了非常有用的特性。
為了運行 Purify ，我們首先必須設置參數配置以使用正確的 JDK 。除了我們選中了" Pause JVM console after exit "選項之外，我們?yōu)槲覀兊?JDK 版本使用缺省的設置，以便我們能夠在 Purify 測試被完成時(shí)看到我們的
為了運行 Purify 測試，我們選擇 File > Run 并且通過(guò)瀏覽Main.class 文件設置程序名為 Main.class 。這設置了如圖 8 所示的缺省選項。我們所做的唯一改變（因為切斷的顯示，所以在這個(gè)圖中看不到）是更新命令行參數來(lái)運行 asdi.exchange.command.Main ，因此 Purify 的缺省設置是沒(méi)有包范圍的 Main 。
有趣的是，我們第一次就遇到了類(lèi)格式的異常錯誤。在過(guò)去當我們在 JDK 1.1 和 JDK 1.3 之間遷移時(shí)我們看到過(guò)這些異常，在那里 *.class 驗證規則發(fā)生了變化。由于一些原因我們有一次遇到了這個(gè)問(wèn)題，但是僅僅是在 Purify 中遇到了這個(gè)問(wèn)題。如果我們使用 J2SE 的 javac.exe 代替 jikes.exe （IBM 的高速編譯器）來(lái)編譯 *.class 文件，問(wèn)題就消失了。
