2023年系統(tǒng)架構設計時案例分析

論文一公司人事信息系統(tǒng)的應用

廣東延國慶中國系統(tǒng)分析師網(wǎng)站

【摘要】

本文討論《公司人事信息系統(tǒng)》項目的需求分析方法與工具的選用。該系統(tǒng)的建設目的是幫

助該公司管理好公司內部的人員和人員的活動，人事信息管理指的是公司員工從招聘面試到

離職退休的全過程，涉及的重要活動涉及面試、報到、培訓、升職、離職或其他的人事變動，

也涉及電子化考勤、工資性收入的計算與分發(fā)、使用其他公司資源的有關記錄（如宿舍、保

險、證件辦理等等）。此外，本系統(tǒng)也涉及到公司在全國各地的人事信息管理，公司的組織

架構的設立，級別與職務管理，人力申請直至人力需求報表，從而形成一個對公司真正有用

的人事信息管理應用系統(tǒng)。在本文中一方面討論了選用面向對象方法與工具的重要理由與策

略，進一步通過一個簡例說明該方法與工具使用的效果，也討論了使用多種工具與方法在需

求分析中的必要性，最后簡要小結了選用對的工具與方法的意義和作用。

在項目開展期間，我擔任了系統(tǒng)分析、系統(tǒng)設計與數(shù)據(jù)庫管理等大量工作。

【正文】

人事信息管理系統(tǒng)是一個有著廣泛應用面的實用性系統(tǒng)，但是，我國各個公司有著自身的體

制、機制、特點與不同的規(guī)定；在開發(fā)這類系統(tǒng)時，系統(tǒng)需求分析是極為重要的一環(huán)。在整

個分析過程中，我們都采用了面向對象的分析方法，這是由于我們在近幾年的實踐中已堅信

這種方法可以更加有效地表達和描述現(xiàn)實世界。軟件要具有合用性和擴展性，就必須更接近

于現(xiàn)實世界自身的發(fā)展規(guī)律。以一個簡樸的例子來看，假設規(guī)定設計關于引進人才評估的一

個系統(tǒng)，按我們過去的做法，先會規(guī)定提供應我們一份相關的引進人才評估表，然后依葫蘆

畫瓢地設計相應的表單與界面。在短期來說，這樣做是簡便而實用的，但并不可以符合現(xiàn)實

世界的長遠目的，這套設計方法不具有擴展性，由于任何一份評估表的結構都會有也許發(fā)生

許多改變的。采用面向對象的方法，可以從中提取出表類型、表結構、評分方法以及能考慮

繼承等各方面的要素，這樣就可以保證軟件的通用性，可配置性與可維護性。

在工具的選擇過程中，我們選擇了現(xiàn)在已十分流行的Rational系列，涉及RationalRose、

RUP、SoDA等，為什么選取這個系列工具呢？這是基于我們對軟件需求分析目的的見解,

我們認為需求分析應當能對的地回答如下的幾個關鍵性問題：

（1）用戶的需求是否已詳盡地被考慮到了？

（2）用戶能理解或明白我們所描述的內容嗎？

（3）分析是否會和設計相脫節(jié)，

（4）程序員能明白我們的分析與設計規(guī)定嗎？等等。

以下對上述幾個問題逐個簡要地加以說明：

（1）詳盡地獲取用戶的需求。

用戶的需求可分為顯式的需求與隱性的需求，用戶的傾向往往只顧及到當前的與明顯的需

求。要達成對需求理解的全面性，不僅僅只是依靠有效的用戶談話和調查，由于我們所面對

的用戶需求往往會有些片面的，采用RationalRose（基于UML）提供的用例，以及多種圖

的聯(lián)合使用，可以使我們發(fā)現(xiàn)其中的漏掉。

（2）使用戶能充足地理解我們的表達方法，可以真正明白我們描述的內容。

軟件需求分析規(guī)格說明書通常會是冗長而枯燥的，一般的用戶不容易進一步理解，這樣就削

弱了分析的對的性。通過支持面向對象及UML語言的RationalRose可以更好地和用戶交

流，讓用戶了解系統(tǒng)的運作方式甚至細節(jié)的操作。

（3）使分析和設計兩個階段互相聯(lián)系與貫通。

這是我們選擇面向對象的方法及RationalRose工具的重要因素，系統(tǒng)分析要向用戶描述的

不僅僅是用戶的需求，并且涉及解決方法，解決方法當然應涉及設計（程序）、數(shù)據(jù)庫與系

統(tǒng)配置，我們當然不希望用戶得到的是一個與需求規(guī)格說明不相同的軟件，也不也許規(guī)定程

序員完畢一個不可勝任的任務。然而我們在以前的多項工作中經常發(fā)現(xiàn)這類情節(jié)，由于系統(tǒng)

分析與設計互相脫節(jié)，導致一頭扎在分析中不顧設計有關的事宜。

分析與設計的脫節(jié)，還不利于設計現(xiàn)格說明的評估，由于分析往往會脫離現(xiàn)實，導致缺少評

估的依據(jù)。

由于不也許成功地完畢設計而使分析需要重來，就會導致巨大的浪費與損失。一個好的工具

可以使分析與設計更緊密地連結起來，甚至于一一相應。面向對象的分析方法使對象之間相

對而言有獨立性，減少了任何影響到全局的改動，能避免因需求變化而導致全盤皆動的被動

局面。

（4）使程序員明白我們的設計。

一個好的設計應當讓程序員感到清楚明白，更少疑問。一個疑問很多的設計加上溝通不暢，

絕對會出現(xiàn)在應用環(huán)境下所不需要的另一個軟件，所以設計規(guī)格說明書務必清楚、形象與明

確，當然，RationalRose具有足夠的圖形與其他形式，能使程序員更加明確，甚至能細微

到每一個語句（事實上假如使用VB,程序架構都有也許直接生成了）。

（5）選擇UML也許會有更多的理由。

比如用戶文檔的編寫、數(shù)據(jù)庫設計，我們都需要做到有延續(xù)性，有自動化支持和具有質量上

的保證。

所以，我們選用了以上的方法和工具。

在分析中，面對考勤班次的問題時，由于過去一直使用紙卡方式考勤，使用戶對班次形成了

固定的概念，而現(xiàn)在的許多考勤軟件也采用多次刷卡的方法來形成一天的記錄。通過面向對

象的分析可以發(fā)現(xiàn)，事實上天天的上班記錄是由多個時段所形成的，時段的多少在各個公司，

各個工種與部門都不盡相同，每個時段也許有不同的屬性，時段與時段組合可形成為班次，

這更適合于現(xiàn)實的情況，使之能更加靈活與更有擴展性。其實，在天與天之間也都有互相之

間的關系。在這一點上，我們又發(fā)現(xiàn)必須在考勤與薪金工資中加入與MRP中相似的期段

（Periods）的基本概念，比如可以稱之為考勤期段，允許為用戶更加方便地設立考勤期段，

也許使之不一定與自然年月日相同等等。

RationalRose使我們更方便地把上面的想法在類上去實現(xiàn)，更進一步地設計好我們的高效

率的數(shù)據(jù)庫。

當然，使用單一的一個工具去完畢一個中大型的應用系統(tǒng)的需求分析，是不也許成功的。由

于社會在發(fā)展，用戶的需求也在改變，如何把握住用戶的需求是需要時間的，面向對象的方

法有時也會忽略外在的與表層的規(guī)定，不僅僅是要獲得關鍵的需求，其他更多的需求往往要

等到用戶在使用后才知道，然而等到用戶使用是不現(xiàn)實的，作為原型開發(fā)模型中的原型也是

收集用戶需求，描述與解釋需求的一類相稱有效的方法與工具。

在我們的開發(fā)過程中，為了更好地讓用戶了解我們的系統(tǒng)和我們的設計方案，讓用戶在見面

會上更有方向性與針對性，我們一方面用Access開發(fā)出原型，讓用戶先試用。這樣，我們

在真正的分析與設計時就能更加符合用戶的規(guī)定。

總之，軟件需求分析方法和工具的使用，對我們軟件開發(fā)過程影響是很深遠的，選用高效能

的對的的方法與工具，可以使我們的軟件更加對的地反映現(xiàn)實需求，更加具有可用性、可擴

展性和可維護性；減少了軟件項目的風險。

【評注】

（1）寫得有些特色，觀點鮮明。

（2）摘要寫得不錯，既反映了項目內容，也小結了本文的寫作要點。

（3）文中所舉的例子雖然簡樸，但很實際。

（4）多種方法與工具的使用，敘述得簡明扼要。

（5）內容可更豐富一些，更進一步的例子也可再增多一些，則會更有說服力。

（6）對需求分析的全過程的描述太少。

論文二公司集團的信息管理系統(tǒng)應用

廣東劉小波中國系統(tǒng)分析師網(wǎng)站

【摘要】

本文以某個IT產品銷售公司的信息系統(tǒng)項目的開發(fā)為背景，討論了一個信息系統(tǒng)需求分析

的整個過程，其重要特性是：所涉及的項目是原有系統(tǒng)的一個升級替換版本。因此，需求分

析過程不同于建立一個全新的系統(tǒng)，大體上可分為三個階段：（1）實行逆向工程獲得對系統(tǒng)

的初步了解；（2）在第1步的基礎上寫出基本需求，交由客戶評審補充；（3）在第2步的

基礎上開發(fā)原型，運用原型與客戶交流，最終獲得基線需求。針對上述三個階段，本文論述

了所使用的分析方法與工具以及所碰到過的一些典型問題和措施，最后對需求分析中使用的

工具，談一些自己的初步體會。

【正文】

我于1998年8月至2023年7月參與了某個大型集團的公司信息系統(tǒng)的開發(fā)工作，該大型

集團的業(yè)務重要涉及到IT類產品的進銷存。本人在項目中負責系統(tǒng)分析的工作，該集團公

司原先已委托某個電腦公司開發(fā)過一套IT類產品管理系統(tǒng)，但是該老系統(tǒng)存在兩個重要的

問題：（一）系統(tǒng)運營速度非常慢，如商品銷售開單時，從擬定開單到開單完畢有時需要1?

2分鐘左右的響應時間，讓客戶無法忍受。（二）系統(tǒng)數(shù)據(jù)不準確，經常出現(xiàn)實物庫存與電

腦庫存嚴重不相匹配的情況，使銷售數(shù)據(jù)的記錄產生一些混亂，有關財務的數(shù)據(jù)因此無法有

效使用，只能采用人工錄入方式補充進行。在這種情況下，該集團的總經理決定參考原有系

統(tǒng)重新開發(fā)一個系統(tǒng)，以便解決原系統(tǒng)所存在的上述兩個難以克服的難題。注；原系統(tǒng)采用

PB6.5開發(fā)，數(shù)據(jù)庫采用SYBASE,服務器采用Windows2023Server,客戶端采用Windows

98,程序架構采用的是傳統(tǒng)的C/S結構。

鑒于該集團業(yè)務操作復雜，流程多，涉及人員多等特點，以及項目完畢時間短，經費有限，

人員有限等限制約束條件，再考慮到必須避免前一系統(tǒng)出現(xiàn)過的結構混亂與難于維護等問

題，我們決定要對原系統(tǒng)的需求做一個比較徹底的和切實可行的分析，由于原有系統(tǒng)已經開

發(fā)了近兩年，并且客戶也有了一定的使用經驗，業(yè)務基本流程自身也并沒有太大的變化，因

此，我們把需求分析的過程分為三步：（1）分析原有系統(tǒng)的結構，重要是數(shù)據(jù)庫結構和程序

結構，（2）在獲得第（1）步結果的基礎上寫出基本需求，交由客戶評審補充，（3）在第（2）

步的基礎上開發(fā)原型，運用此原型與客戶交流，從而獲得最終可用的需求結果。下面按上述

三步分別加以論述。

第一步是實行逆向工程，獲取原有系統(tǒng)的基本需求。

由于原有系統(tǒng)在功能上大體上能基本滿足客戶的需求，并且在兩年多的開發(fā)中也積累了不少

經驗，因此，從中可以獲得一些有益的參考，也可以避免多走彎路。在這一階段，我們采用

的重要工具是PB自帶的PowerDesigner和PBDocuments；前者重要用來分析數(shù)據(jù)庫結構,

后者重要用來分析程序結構，便于開發(fā)人員與高級用戶理解程序。采用這兩個工具的因素是:

原系統(tǒng)過于龐大，模塊多，數(shù)據(jù)庫模式多，表格量很大，僅靠人工的方法很難從中獲得一個

比較完整的、明確的系統(tǒng)結構以及整體構成，并且原有系統(tǒng)未能提供一套對的完整有效的設

計文檔，于是我們只能依靠工具輔助來進行。在使用PowerDesigner分析數(shù)據(jù)庫，并且用

PBDocuments分析原程序中的PBL以后，我們對原系統(tǒng)的結構有了一個初步的了解，再

結合對原系統(tǒng)的使用，基本明確了功能與流程的需求，并在此基礎上用人工錄入方式，產生

了初步需求的自然語言文檔。這里指出，使用PowerDesigner的一個局限性之處是：假如

一個表中的字段過多，并且又同時依賴多個表時.，輸出的表格相關圖形很復雜，有很多交叉,

且難于調整，不方便閱讀及打印。

第二步是在第一步的基礎上進行的，即寫出系統(tǒng)基本需求，交由客戶評審和補充。

通過第一步的逆向工程，我們獲得了系統(tǒng)的基本需求。為了充足記錄需求的變化及需求之間

的依賴關系，我們決定選用Rational公司的RequisitePRO作為我們的需求管理工具，

Rational公司有一整套用于需求管理的工具，功能非常強大，涉及RequisitePro>ClearQuest

等等，這些需求分析工具可以對需求進行全面的管理，涉及記錄需求的變化情況，需求之間

的依賴關系等等。但是，我們考慮到Rational的一套工具全面實行會非常昂貴與復雜，需

要非常強的項目管理能力才干全面實行，因此，我們只采用了其中最簡樸的一部分功能，那

就是記錄需求變更，記錄需求之間的依賴關系，其他跟RUP有關的功能都給略去了。

之所以這樣做，重要是考慮到項目的經費、人力以及國內軟件開發(fā)的實際情況。正如前面所

說，我們根據(jù)自己的理解并寫出基本需求后，交由客戶做評審井做適當補充，我們將通過補

充整理后的需求作為正式需求記錄入RequisitePro所維護的數(shù)據(jù)庫中，并對各個需求進行

分類，設定優(yōu)先級等，這些工作完畢后，就可以從數(shù)據(jù)庫中直觀地了解客戶到現(xiàn)在為止提出

了哪些需求，哪些需求是必須優(yōu)先考慮的，哪些是難度較大的等等。在這個過程中，我們碰

到了一些問題，譬如：

用戶對我們用自然語言書寫的需求文檔有許多地方不理解，往往在花了較長時間閱讀之后，

仍不明白我們所描寫的需求過程與他們所完畢的業(yè)務之間的相應關系；此外是由于初次采用

RequisitePro進行需求管理，在類型劃分，屬性值的擬定上，部分開發(fā)人員沒有經驗，導致

了不少反復，對于前者，我們的方法是想辦法增長一些示意圖，將大的流程分解為小流程，

再與客戶反復交流與溝通，最終達成雙方理解一致的目的。對第二個問題，則參考了一些例

子，再結合實際中屬性的使用情況，給予取舍或者選擇，通過這一階段的工作，我們建立了

基本的需求庫，定出了基本需求規(guī)格說明。

第三步則是在第二步的基礎上建立起原型，運用原型與客戶進行更進一步的交流，通過交流

修改相應的需求。

在這一階段的工作是在對第二步任務進行報告交流的基礎上進行的。我們用PB開發(fā)了一個

原型系統(tǒng)，就具體的業(yè)務流程與客戶進行交流與溝通，通過原型，客戶發(fā)現(xiàn)了許多我們與他

們的理解互相不協(xié)調的地方，我們在修改需求的同時，也在RequisitePro需求數(shù)據(jù)庫中記

錄下修改的歷史。事實證明，這種記錄歷史的作用是很有效的，如曾經有客戶在兩個不同的

時間對同一需求提了相反的需求，我們根據(jù)歷史記錄不久證實了該客戶的提法有錯誤，在事

實面前無需再作爭論，同時運用RequisitePro,我們還發(fā)現(xiàn)了一些需求互相之間有矛盾。通

過這一階段工作，我們終于獲得了通過用戶認可的需求基線，即是可用于下一步進行具體設

計的基線需求。

在這個項目中，我們運用了PowerDesigner>PBDocuments等逆向工程分析工具和Requisite

Pro需求管理工具，這些工具的使用，使我們提高了工作效率，起到了一定的輔助作用。但

是，就需求分析工具方面而言。我們覺得國內應用得還是太少了，這一方面是由于對需求分

析不夠重視，另一方面是由于管理水平還達不到相應的層次。Rational公司的一整套需求分

析工具，其功能是非常強大的，國外已在普遍地使用，在國內也逐漸開始普及，特別是那些

通過CMM二級以上評審的單位，都必須使用工具對需求進行管理。在本項目中，我們僅

僅運用了RequisitePro功能的一些小方面，已經體會到該工具對于項目管理的諸多好處.

假如一個有實力的公司可以全面實行RUP,那么需求管理這個老大難的問題會變得不再那

么棘手了，項目的質量也會得到相應的提高。目前國內由于CMM熱潮的興起，已經逐漸重

視需求分析，也逐漸使用需求分析工具，這是非?？上驳?，當然，更希望在不久的將來，能

用上國產的需求分析工具，那時我們的軟件產業(yè)也許會真正地騰飛了。

【評注】

采用逆向工具進行再工程的應用很多，本文給出了一個實際的例子。寫作有條理，也很實際。

合理地界定了需求分析的現(xiàn)實水平。所采用的需求分析的方法與工具相對較合理科學。能在

對項目討論的同時抒發(fā)議論、使用體會、愛國心和事業(yè)心。深度還可以提高，例子宜更加豐

富一些。

論文三通信行業(yè)的應用

廣東魏福建中國系統(tǒng)分析師網(wǎng)站

【摘要】

本文以某通信公司的業(yè)務報表系統(tǒng)開發(fā)為例，討論了軟件需求分析工具與方法的選用。我們

認為，軟件需求分析是軟件工程中重要的一步，直接關系到后繼工程的進行以及最終的產品

能否滿足用戶的需求，因此在整個工程中起著關鍵性的作用。采用適當?shù)墓ぞ?，有也許顯著

減少需求階段的錯誤，也可大幅度提高需求分析的質量和工作效率。當然工具的選用應當與

實際的項目相結合，充足地發(fā)揮工具的作用。本文結合我們工作的實際經歷，簡要討論了開

發(fā)系統(tǒng)時所選用的工具及其應用，選用時所考慮的原則以及所碰到的問題。在文中也結合多

種開發(fā)方法（即傳統(tǒng)的瀑布法、信息工程法、面向對象的方法）的比較，指出各種方法的局

限性之處，說明我們所采用的工具對軟件需求分析所起的作用，以及相應產生的效果。

【正文】

我在某市一家通信公司工作，作為一名技術骨于，受領導委托，參與了開發(fā)本公司的業(yè)務報

表系統(tǒng)，我擔任系統(tǒng)的需求分析、總體設計和部分代碼的編寫工作。

我所在的公司作為一家通信運營公司，分為總部、省級公司和地市級分公司三級，各級公司

之間都有數(shù)據(jù)報表的規(guī)定。但是，每一個地市分公司因所處的地方不同，經營環(huán)境不同，所

面臨的問題也不同樣，因此形成了各具特色的數(shù)據(jù)報表（除地市分公司向省公司報告的之

外）。公司又分設了許多部門，這些部門也都會需要數(shù)據(jù)，作為分析決策的依據(jù)。因此，了

解各個部門的需求就成了業(yè)務報表系統(tǒng)的關鍵。

在調研的過程中，我選用了一種工具叫PlayCASE,可以從網(wǎng)上免費下載，有很強的功能。

下面就介紹一下，在需求分析階段，我是如何使用這一工具的。

第一步，了解業(yè)務組織結構。公司內部的數(shù)據(jù)事實上是在部門之間流動的。業(yè)務部門需要知

道在本地覆蓋區(qū)內各基站的話務量、當天的話務量（即話務量的時空分布）。財務部門需要

知道本月各類用戶的話費收入、預交款收入、與其他電信運營商的網(wǎng)間結算等。計劃部門需

要各部門的分析數(shù)據(jù)。計費部門需要提供本月的賬革記錄數(shù)據(jù)、話單記錄數(shù)據(jù)分布（比如分

別按照基站分布、時段分布以及按用戶類別分布）、預交款記錄數(shù)據(jù)、當前的欠費總額分布、

催繳情況等等。這些部門時常為了數(shù)據(jù)而產生了大量無謂的爭議。在使用PlayCASE工具

時，先要將這些部門錄入到PlayCASE的"業(yè)務部門”中.構成了一個信息源的接受點（或

發(fā)送點）；而PlayCASE通過圖示表達了這些部門的關系，并轉換成了相應的軟件結構。事

實上,這是一種系統(tǒng)建模的方法，即把業(yè)務系統(tǒng)中的各個組織轉變?yōu)檐浖δ苤械母鱾€結構。

這樣，在需求分析階段，明確哪些部門需要數(shù)據(jù)，從而保證了需求分析對整個公司的全面性,

而不會忽略掉某一個部門，導致需求分析的不完整。

第二步，了解各個業(yè)務部門中的業(yè)務流程，使之通過PlayCASE轉換成軟件的運營過程，

這是一種動態(tài)建模的方法。在上一步的基礎上，追蹤各個部門的行為，錄入到PlayCASE中，

并以形式化的語言描述各過程。對于復雜的過程，該工具還提供了進一步細化的方法，并且

形成了業(yè)務流程圖和業(yè)務狀態(tài)圖。根據(jù)這些流程圖、狀態(tài)圖與實際業(yè)務部門的業(yè)務相結合比

較，還是較為吻合的。在此步的實行過程中，運用了動態(tài)建模技術，使各部門業(yè)務流程的情

況在軟件的運營過程反映出來，從而保證了需求分析階段中運營過程的描述能真實地反映實

際情況，防止在后繼的程序編寫過程中，也許會經常發(fā)生的一類情況：程序員由于沒有理解

業(yè)務流程而出現(xiàn)"閉門造車”的現(xiàn)象，從軟件的功能角度上保證了軟件的對的性。

第三步，將業(yè)務數(shù)據(jù)轉變?yōu)檐浖?shù)據(jù)，這一步工作事實上就是收集各部門所需要的數(shù)據(jù)。分

析各部門需要的數(shù)據(jù)都有哪些；以及數(shù)據(jù)是如何轉換的，這可以歸入“功能建模"的范疇。將

這些相應數(shù)據(jù)錄入到PlayCASE中，選定所屬的部門。這時就自動地建立了DFD圖（數(shù)

據(jù)流程圖），數(shù)據(jù)字典，省去了人工建立時的很大麻煩。

第四步，將業(yè)務上的數(shù)據(jù)關系轉變成軟件中的數(shù)據(jù)關系。這里采用了面向對象的方法，把業(yè)

務部門所需要的數(shù)據(jù)看作一個實體，部門間的數(shù)據(jù)關系就是實體之間的關系.比如：經營部

門所需要的用戶資料、用戶話費，事實上就是用戶這一實體與賬單這一實體間的關系。Play

CASE提供了構件（但是我覺得是部件更為合適一些），來表達相應的數(shù)據(jù)，并提供了三種

構件的表達關系即組裝關系、分類關系與相連關系。這三類關系基本上反映出了現(xiàn)實世界中

的業(yè)務數(shù)據(jù)之間的關系。例如現(xiàn)實世界中的用戶資料與用戶話費，在PlayCASE中，可將

用戶構件與賬單構件用相連關系表達。這種方法，事實上是借鑒了00A面向對象的分析方

法中的類、聚集、繼承、封裝等概念，能較好地反映出現(xiàn)實中的業(yè)務；同時，這一步的工作

也為總體設計中數(shù)據(jù)庫的概念模式設計奠定了很好的基礎。

經歷了上述四個環(huán)節(jié)以后，運用PlayCASE工具自動生成了軟件需求規(guī)格說明書、初步的

DFD圖和業(yè)務流程圖，為下一步的總體設計打好了基礎。使用PlayCASE工具，使需求分

析既能繼承傳統(tǒng)的結構化分析方法，又能吸取面向對象設計方法的優(yōu)點。比如能把業(yè)務流程

轉變成為運營過程，業(yè)務組織轉變成了軟件的結構等都體現(xiàn)了這一點。而在運營過程中，對

復雜過程的細分以及追蹤則反映了傳統(tǒng)方法中的自上到下分解的分析思想，這對于解決復雜

系統(tǒng)的分析是很有幫助的。

通過使用，我覺得這個工具還是很不錯的。由于它實際將以下四個方面的問題結合起來了：

軟件、業(yè)務、開發(fā)人員和用戶。對于用戶而言，PlayCASE用圖形化的方式顯示出業(yè)務流

程，使用戶了解業(yè)務在軟件中的運營過程，提供了將來驗收軟件時的依據(jù)。對于開發(fā)人員來

說，使開發(fā)人員能更清楚地了解業(yè)務流程，不會再發(fā)生"由于不理解用戶的需求而出現(xiàn)的閉

門造車情況，從而導致開發(fā)出來的產品不符合用戶需要”的現(xiàn)象。因此，PlayCASE所自動

提供的需求說明書可以很好地溝通用戶與開發(fā)人員之間的理解，使他們都能對需求有共同的

理解。使用PlayCASE工具后，使我們的需求分析取得了很好的效果，不僅能自動地提供

許多結果，如需求說明書等；還使需求的質量有了很大的提高，受到領導的贊揚（領導不是

學計算機的，但對公司的業(yè)務十分熟悉）；在后繼的設計與維護工作中，我們感到工作似乎

輕松了很多。

當然，該軟件工具也有局限性之處，一個突出問題是靈活性不夠，一旦公司的部門或者組織

機構發(fā)生變化時，整個設計都要重新來過。因此，在改善的過程中，我們在第一步過程預留

了好多個虛擬的部門，以備將來進一步的擴充或者變動。

【評注】

（1）具體項目有些體會，完畢情況似乎不錯。

（2）條理較清楚，比較系統(tǒng)地描述了使用PlayCASE的過程和體會。

（3）偏重于工具的討論，對需求分析的方法分析還嫌不夠。

（4）項目相對較小，僅涉及報表系統(tǒng)，對更為復雜的業(yè)務流程應舉例分析，才干更充足地

體現(xiàn)方法與工具的作用。

論文四IC行業(yè)內部的CAD應用

上海解亮中國系統(tǒng)分析師網(wǎng)站

【摘要】

本文通過一個集成電路設計有關的軟件項目，討論了該項目的重要特點和本人所擔任的工

作，著重討論了在項目需求分析過程中采用的具體方法和工具以及選用的理由。

由于項目的專業(yè)領域的特殊性，分兩類不同的需求討論了需求分析中碰到的問題及解決方

法；在這個過程中給出了對選用的具體工具和方法的效果的描述。接著本文討論了對使用方

法的改善的一些想法以及具體的實現(xiàn)過程。最后提出了我對需求分析的某些見解，強調了與

客戶溝通的重要性。

【正文】

近年，我一直從事某公司中有關IT項目的開發(fā)，有一個系統(tǒng)是用于計算機輔助電路設計的，

涉及了從上流設計到下流設計的所有流程，如用于可設計百萬門數(shù)量級的邏輯門電路。有關

方面把電路半途徑的提取、過濾以及表達的某軟件開發(fā)任務交給我公司，我有幸擔任了該部

分的需求分析以及設計。

我所設計部分為一單獨可啟動的軟件，重要是解析文獻中的連線途徑，以列表視圖和用直方

圖等把它們顯示出來，還可以執(zhí)行諸如查找與過濾等功能。委托方對此提供了很初步的需求

說明，把一些基本功能及性能規(guī)定描述了一下。我在需求分析時的工作重要有兩點：第一，

對該軟件的界面等具體需求要自己重新進行分析提取。第二，對于已提供的功能規(guī)定需要深

化和細化，以形成真正完整的需求分析文檔。

在接到需求分析任務后，我分析了一下所要完畢的工作。發(fā)現(xiàn)由于是專用領域的軟件，對專

業(yè)領域規(guī)定相稱高，所以準備把此項目提成兩部分：

（1）界面所受專業(yè)領域影響幾乎沒有，但由于所有沒有任何規(guī)定，反而會感到風險和改動

也許是最大的。

（2）功能方面由于委托方的許多功能都可以調用相應模塊來得到，并且已有了相應的書面

的簡樸需求，相應來說只是完畢深化。對界面，我采用了部分RUP的思想迭代與漸進。而

對功能需求采用了分層細化，每細化一層就規(guī)定委托方確認、修改和補充。

一方面把風險較大的部分完畢，這是現(xiàn)代軟件開發(fā)的基本常識。我選擇先進行界面的需求分

析。第一步是根據(jù)功能描述抽取出邏輯模型，并使邏輯模型與界面元素及功能一一相應，大

體上決定了界面應有的功能，然后根據(jù)該界面功能描述，擬定具體的控件，這時，我參考了

委托方已初步完畢的主窗口的界面布局及控件的使用規(guī)律，然后根據(jù)需要完畢的功能從Qt

（由于要支持Windows和Unix雙平臺，所以控件庫采用Qt）的類庫中選擇相應的控件。

在提取和抽象邏輯模型時，我采用了Rose2023中的用例圖，即以USE-CASE圖來描述與

外部的關系。之所以采用Rose,我是基于以下的因素：第一，在已開發(fā)的部分中，委托方

統(tǒng)一規(guī)定我們使用Rose進行類和順序圖等的設計和代碼生成。第二，Rose提供了標準的

圖來描述系統(tǒng)與外部的關系，在全球范圍已是一種標準結構。第三，使用上的方便性。我用

Rose的USE-CASE圖，理清了我們的軟件窗口與委托方主窗口以及外部角色（操作者）之

間的互相關系。

在擬定了界面元素后，考慮到文檔的可理解性不是很強，我采用Visi。2023把界面的外觀繪

制出來，寫上了基本的控件作用，隨后送給委托方評審，幸運的是除了幾個小功能的修改，

委托方基本批準了我的方案。

下面的工作是為控件的行為及狀態(tài)變化制定相應的狀態(tài)遷移圖，我選用的工具仍是Rose,

我用了狀態(tài)圖和時序圖，把重要的控件狀態(tài)變化及相應順序進行了描述，隨后的幾天把相應

的DOC文檔建好寫明，基本上界面設計就完畢了。

下面的需求是針對功能需求的。雖然委托方技術部門有初步的需求文檔，但由于領域的專門

化不對，我不清楚其中復雜的途徑提取關系及較進一步的專業(yè)術語，一直有一種舉步維艱的

感覺。只能采用分層細化的原則，從最初的幾條進一步一層變成十幾條。這樣的話，不會一

下子碰到太深的專業(yè)問題，可以循序漸進從委托方與文獻的解答中不斷學習，深化自己對專

業(yè)領域的了解,這樣在設計中自己始終是層層推動的，不至于一下碰到無法逾越的專業(yè)障礙。

在這一階段的開發(fā)中，由于一直是與自己不熟悉的專業(yè)領域打交道，所以我覺得一些輔助設

計工具似乎無法發(fā)揮應有的功能。在這期間，對我?guī)椭畲蟮膽枪镜腅-Mail系統(tǒng)，所

有不清楚的問題的提出，以及對問題的解答都通過它進行周轉。換句話說，在需求分析階段,

它起到了一個與客戶的交流溝通和客戶需求的提取作用。所以，我認為在這一階段，E-Mail

系統(tǒng)是對我?guī)椭畲蟮墓ぞ?，另一方面是Excel,我用它建立了問題跟蹤圖表，對每一個提

出的問題，均需要記錄上去，把問題結果（可分為已清楚、仍不太清楚、不清楚、尚未回答）

均記錄下來，根據(jù)這些表，我可以很好地了解自己工作中的核心問題，并有了解決它的方向，

提高了工作效率。

每進行一層的細化，我都把結果交付委托方審核，由他們進行提出何時能終止細化，大約在

八層細化后，對方認為已達成了效果，確認可以結束。至此，分析工作所有完畢，項目的需

求分析基本成功了。

在這次需求分析中，我認為取得成功的因素重要是方法和工具選擇得對的。

在界面設計中采用了流行的輔助工具，對需求及邏輯模型的建立提供很大的幫助，可以更方

便幫助自己理清思緒。選用了迭代法，把一些錯誤的影響在功能分析和界面分析的不斷迭代

過程中加以改正。在后期，以功能需求為主時，我重要依賴的是溝通工具和表格工具，這也

說明輔助工具不是萬能的，需求分析的關鍵之關鍵，應是與客戶的交流與溝通。

通過這次案例，我認為在軟件的需求分析工作中，方法的重要性應遠超過工具的使用，應當

一方面擬定分析中的風險，把風險分類，用不同的方法去解決各類風險，而工具的選擇不僅

是要看影響力和名氣，而是要真正為我所用，應把握其精髓，即是此工具到底可以對開發(fā)有

什么幫助，而不是僅限于如何使用。我認為在需求分析中工具的作用不外乎兩個：一是實際

系統(tǒng)與環(huán)境模型等的抽象工具，二是需求表達工具。第一類的代表是Rose,第二類的代表

是Word,WPS,Visio等，在這次項目中由于地理上的限制還用到了溝通工具，Web瀏覽

與E-Mail服務系統(tǒng)。

最后我還是總結一下，在需求分析中工具方法都只是輔助項目成功的因素，真正的決定因素

還是「與客戶的溝通”。

【評注】

（1）較實際地討論了方法與工具。

（2）兩類需求的討論有點特色，解決需求問題的方法較成功，有說服力。

（3）能發(fā)表自己的觀點和意見，體會較實在。

（4）本例似乎有些特殊性，還是要鼓勵對自己熟悉的業(yè)務領域做項目，否則的話，有時會

事倍功半。

(5)最佳再列舉更多的項目或例子，使方法與工具的討論更全面一些。

論文五ERP開發(fā)的應用

上海陳莉莉中國系統(tǒng)分析師網(wǎng)站

【摘要】

根據(jù)某類公司的迫切需要，我所在的信息技術公司組織了一個公司資源計劃(ERP)項目的

開發(fā)，希望推動我國ERP應用的發(fā)展，也希望更進一步有效地運用Java技術。該項目的

內容涉及到某類行業(yè)的公司生產經營的全過程，其基本目的是為了提高公司的勞動生產率，

增長公司的利潤，優(yōu)化配置公司的資源，使公司的整體運營水平能上一個臺階。這是一個基

于Java技術的Intranet典型應用項目。

在該項目中，我承擔項目負責人的重要職責，比如在項目的準備階段，我曾組織了對項目組

的成員進行該類公司業(yè)務流程方面的培訓；在項目需求分析和設計階段，我著重考慮了架構

好系統(tǒng)的框架和原型，為項目組及其他分析員進行下一步的細化分析奠定了堅實的基礎。同

時我還組織好項目總體組，把握住各模塊之間的接口分析，保持各個分析員之間實現(xiàn)密切的

溝通。在系統(tǒng)的開發(fā)階段，做好開發(fā)、測試方面的協(xié)調和同步工作，保證系統(tǒng)的可靠性，在

系統(tǒng)的實行階段可以順利地推動項目，此項目開發(fā)后的應用已得到了用戶們的一致好評。

【正文】

與國際上ERP項目的廣泛應用相比，我國的ERP應用水平尚有相稱大的差距。根據(jù)某類

公司的實際迫切需求，我公司組織了對一類ERP產品的開發(fā)，我有幸參與了該項目的分析

與設計，開發(fā)的成果是一個典型的Java技術應用于Intranet的實際項目。

在選擇具體的技術方案時，我們曾經進行了認真的思考和研究。對于選擇普遍采用的微軟模

式的平臺方案，還是跨平臺式的Java方案，我們曾舉棋未定，這是由于微軟的VB+ASP已

成為大家在較長時間工作后認可而熟悉了的方案。而Java由于其環(huán)境規(guī)定高與執(zhí)行效率低

的老大難問題，成為我們緊張膽怯的重要因素。但是Java的跨平臺特性越來越成為人們的

關注點，特別是許多大中型的公司，他們現(xiàn)有的網(wǎng)絡系統(tǒng)都是基于多種平臺的，對跨平臺的

規(guī)定和呼聲極為強烈，而對軟件公司來說，軟件的跨平臺特性有也許會節(jié)約開發(fā)成本，減少

維護量，

也能獲得更多客戶的認可。綜合考慮了諸多市場行情與行業(yè)發(fā)展因素，最終決定一定要用

Java。所幸的是現(xiàn)在Java用于因特網(wǎng)的開發(fā)也已經越來越便利了。

目前Java在因特網(wǎng)上的開發(fā)技術已呈白花齊放之勢態(tài)，有最初的JavaServlet,有與數(shù)據(jù)庫

聯(lián)系在一起的SQL-J,尚有可與ASP和PHP相媲美的JSPo特別是JSP技術的迅速發(fā)展，

使得Java的網(wǎng)絡應用不再是少數(shù)人的專利，JSP以其執(zhí)行的高效性和使用的方便性，已成

為近年來大家首選的因特網(wǎng)開發(fā)技術，JSP是一種頁面開發(fā)技術，它以Java為其服務器端

語言，結合JavaScript作為其客戶端語言，能方便地實現(xiàn)頁面的表達。

選擇好了后端的Java和前端的JSP,尚有一項重要的任務，那就是前后的聯(lián)接。由于JSP重

要用于頁面表現(xiàn)，需要表現(xiàn)的內容要封裝起來，這樣，為了保證重要商務邏輯的安全性，我

們采用了JavaBean作為橋梁，即客戶端JSP通過其中JavaBean的使用，完畢重要的商務

邏輯功能。在后臺，將Bean構造好，形成一個強大的Bean庫，再由前臺JSP進行使用。

在進行JavaBean的規(guī)劃時，我們下決心作出很大的投入，由于這些不僅是我們當前項目中

所需急用的，并且還應成為公司長期積累使用的一個強大的資源庫，能實現(xiàn)一定限度的資源

共享和軟件復用，為其他項目開發(fā)打好基礎。因此，本次規(guī)劃的目的是形成公司Java技術

的JavaBean的平臺庫。

我們根據(jù)JavaBean所體現(xiàn)的類的用途，將這些類提成幾個層次。最底部的一層就是參數(shù)化

類的構造，這一層的類所實現(xiàn)的重要功能涉及通用訪問機制，對數(shù)據(jù)庫等其他層次的訪問接

口和公共解決系統(tǒng)等。中間一層是實體類的構造，這些實體類涉及與數(shù)據(jù)信息相關的結構及

其解決方法,其中的重點是包含了一些重要的商務邏輯的解決。這一層類與系統(tǒng)各部分相關,

并且其安全性規(guī)定很高，直接影響到系統(tǒng)重要功能的體現(xiàn)，由于系統(tǒng)的主體是對一些邏輯進

行解決，這就規(guī)定這層實體類的規(guī)劃需要十分認真，做到細節(jié)準確。最上面的一層可以稱為

接口類，這一層類重要用于實現(xiàn)底層的類與前臺之間的關系。也只有這層類才干由前臺JSP

進行JavaBean調用而加以使用，只有這層具有開放性，這一層類除了上述的接口功能外,

還應當有一項重要的實用內容，即涉及用于實現(xiàn)前臺JSP的頁面自動構造程序。

這里所說的頁面自動構造程序可以認為是本系統(tǒng)的一個重要特點，目的是為了讓用戶可以方

便地自定義界面，而不需要由程序員修改程序，這樣可以極大地滿足了用戶的規(guī)定。頁面自

動構成程序的重要內容涉及對界面元素的定制與修改、位置的修改、動作的觸發(fā)、行為的控

制以及報表設計和計算匯總等功能。頁面自動構成程序的設計重要采用上述的接口類與JSP

相結合的方式，用類實現(xiàn)元素的定制、控制及關聯(lián)，并將重要信息加以保存，以利于用戶的

多次反復修改。該自動構造程序提供了強大功能，已成為我們的一個獨立產品。能應用于各

個項目的界面制作，實現(xiàn)了我們原先制定的共享資源的目的。

在前臺JSP的應用中，做到了盡也許最簡化的限度，這樣可以提高系統(tǒng)的安全性。當然在

我們的系統(tǒng)中，還存在一些客戶端控制比較復雜的情況，為保護這段比較復雜的控制腳本，

我們采用了用Servlet的方法，保護這段腳本，從而保證了一定限度的安全性。

在系統(tǒng)的登錄過程中，我們采用了相稱嚴格的登錄鍵檢查操作，用戶沒有供應商提供的相應

的鍵，就無法通過驗證而進入系統(tǒng)。對于試用版的用戶則提供了一種有效期限約束。這些加

密或安全措施，通過在JavaBean中封裝了嚴格而有強大功能的加密算法，在客戶端申請驗

證后才干準予通過。

在使用這套技術方案的過程中，我們曾經碰到過許多的困難。比如；前面曾提到過規(guī)定JSP

中代碼可以盡量簡化，以提高安全性。由于JSP中仍有一些容易讓人也許猜測到解決方法

的語句及解決的過程，為進一步提高安全性，我們通過查閱大量的網(wǎng)上資料，才形成了一套

較好的措施，比如制作JSP的標記庫，將有也許被猜測的解決進一步加以規(guī)劃，相應地生

成一套行之有效的實用標記庫，這樣就又增長了一道很有效的防護墻，大幅度地提高了安全

保密性，并且使頁面結構的分離達成了一定的水準。又如：在對數(shù)據(jù)的解決上，剛開始時也

總是碰到系統(tǒng)運營會變得越來越慢的情況，最后追查其因素，發(fā)現(xiàn)本來是數(shù)據(jù)的連接過多，

我們及時地采用了數(shù)據(jù)連接池等技術解決了此類問題。

該系統(tǒng)采用Java平臺，提供了進一步地使用JavaBean和JSP的方案，其效果是相稱顯著

的，在用戶真實使用環(huán)境中受到了一致好評，運營也較為穩(wěn)定。由于采用了統(tǒng)一而方便的頁

面自動構造程序，用戶的界面非常友善，并且可以按用戶需求進行定制，滿足了用戶的適應

性需求。而在我們公司的內部，也開始建立了一套基于此平臺的資源庫，成為公司的此后開

發(fā)使用的寶貴財富。

必須指出的是，在此系統(tǒng)中，還存在著很多的局限性，比如實體類的組裝限度尚不盡如人意，

根據(jù)多種商務邏輯的一些共同點，可以進一步加以抽象封裝，使這部分內容能滿足多種系統(tǒng)

對類似邏輯的解決過程。我將會在此后的工作中進一步加強各方面的分析能力，帶領團隊不

斷地超越現(xiàn)在的層次與水準,加強我們的隊伍建設，希望有更多優(yōu)秀的軟件產品上寫著Made

InChina?

【評注】

無

論文六論Java技術在因特網(wǎng)平臺上的應用-通信服務平臺的應用

廣州王海波中國系統(tǒng)分析師網(wǎng)站

【正文】

數(shù)據(jù)通訊是當前十分活躍與熱門的計算機與信息技術的應用領域。某大型通信公司開發(fā)了其

業(yè)務的重要支撐平臺，在這里，我們簡稱之為"通信信息服務平臺"，用于在全國與全球開展

數(shù)據(jù)業(yè)務的需要。該平臺是一個典型的Java技術應用于Internet的項目。

作為信息技術公司中的一名技術骨干，我有幸參與了該系統(tǒng)的分析與設計工作，承擔了相稱

多的Java應用開發(fā)任務。此系統(tǒng)中的軟件部分大多由Java來實現(xiàn)，在全系統(tǒng)中我們是這

樣來用Java構架系統(tǒng)的：

（1）本系統(tǒng)可分為4層，分別是Browser、表達層、中間件層和數(shù)據(jù)層。

（2）表達層用Java中的JavaScript來實現(xiàn)頁面輸出。

（3）中間件層用Java來實現(xiàn)CORBA,即實現(xiàn)Component（構件），重要實現(xiàn)業(yè)務邏輯的

封裝與復用。

（4）數(shù)據(jù)層重要是數(shù)據(jù)庫和存儲過程的實現(xiàn)。

我們在應用Java技術時，所采用的技術和策略可大體上歸納為以下5個方面：

（1）使JavaScript盡量簡樸，由于JavaScript在我們系統(tǒng)中是放在服務器端執(zhí)行的，該語

言是通過一個解釋器解釋執(zhí)行的，相對速度很慢，我們采用了兩臺HP前置機來運營Java

Script,但是其運營速度還是不抱負，所以我們在設計中把JavaScript僅用來顯示從中間件

層所得到的數(shù)據(jù)，生成動態(tài)頁面。在最初的設計中表達層(JavaScript)曾承擔了一些業(yè)務

邏輯解決操作，導致效率不抱負，因此，我們不得不盡量地減少JavaScript的程序量。

(2)用Java實現(xiàn)CORBA時，應盡量考慮共享和復用。在本系統(tǒng)中，最初的設計是讓Java

在實現(xiàn)Component時，只是執(zhí)行一些數(shù)據(jù)庫表的操作，導致表達層的負載較大。后來，我

們重新設計時，總結歸納了所有的UseCase,找出了其中可供共享和復用的接口，把相同的

業(yè)務邏輯操作封裝到一個接口中去。由于Java的執(zhí)行效率比JavaScript要高，因此提高了

系統(tǒng)效率。

(3)在別的項目中，我們曾大量地使用過Java中的JSP技術和Servlet技術，一般人也許

不能區(qū)分這兩種Java技術的區(qū)別。為了得到系統(tǒng)的一些執(zhí)行速率的數(shù)據(jù)，我們采用了一個

著名的壓力測試軟件-LoadRunner來測試這兩種技術的差別。測試表白：用JSP和Servlet

完畢同樣的一個操作，并且保證是在相同的測試環(huán)境中(相同服務器、壓力測試工作站與數(shù)

據(jù)庫環(huán)境)，得到的測試數(shù)據(jù)卻有著很大差別，JSP完畢一個操作的平均執(zhí)行時間大體會是

Servlet程序的兩倍。在一個公司級應用項目中，這也許是一個很關鍵的瓶頸。因此，我們

得出的結論是：在也許的條件下，盡量地多使用Servlet。當然，與Servlet相比，JSP編

程快速，修改方便，在訪問量不是很大的應用場合下也是可以接受的。

(4)使用Java作為整體解決方案時，應盡量使用相同版本的JDK?在用Java作為編程語

言的項目中，幾乎大多要碰到“漢字"問題，即Java在沒有通過轉換的情況下，在輸出漢字

時，很也許會出現(xiàn)亂碼。采用不同版本的JDK,解決的方案是不同樣的，比如V122版本

的JDK和V1.3版本的JDK解決方法就會有一些不同樣，把V1.2.2的Java程序放在V1.3

的JDK中，就不能順利輸出漢字了。

其主線因素在于Java使用了Unicode編碼，和我們中國的國標編碼不同樣。所以在這個意

義上一些人竭力鼓吹的"一次編寫，到處運營”似乎不一定能在所有的場合都行得通。

(5)使用Java時，應盡量遵從軟件規(guī)范。在Java中有一個JVM的概念，即在Java虛擬

機中使用了一個垃圾收集器，專門用來回收內存。但是該垃圾收集器在給編程人員帶來方便

的同時，也隱埋下了隱患。在程序設計中，并不能強制執(zhí)行垃圾收集器，所以，開發(fā)人員不

能擬定某對象是否已釋放，經常讓編程人員養(yǎng)成依賴自動收集的壞習慣，因此我們規(guī)定：在

Try,Catch之后必須明確規(guī)定回收內存(當然，也只能是告知垃圾收集器來回收垃圾)，這

樣可以有效地提高系統(tǒng)穩(wěn)定性。

以上這些實用性的技術與策略，是我們在實踐中的一些實際體會，僅供各位開發(fā)人員根據(jù)實

際情況參考。

當然，在使用Java作為解決方案時，也會碰到很多讓我們頭疼的問題，這些問題導致同時

執(zhí)行的并發(fā)性比較差，系統(tǒng)速度慢等等。歸納起來看，我們曾碰到過的重要具體的問題有：

(1)用Java來實現(xiàn)CORBA中的Component,有時效率會比較低。

(2)用Java來建立數(shù)據(jù)庫連接往往會比較慢。

(3)用JSP編程時容易導致系統(tǒng)信息的擴散。比如，假如有黑客襲擊一臺運營JSP程序的

服務器，他可以故意地輸入一些非法字符或異常信息給JSP程序，于是程序執(zhí)行將出現(xiàn)異

常。這時，就會在頁面上打印出相應的錯誤信息。很不幸的是，這些信息極有也許暴露出這

臺服務器的JDK的版本號與途徑信息等內容。這往往容易讓黑客們有機可乘，有也許去抓

住系統(tǒng)的漏洞。

在發(fā)現(xiàn)了這些問題后，我們通過仔細研究，找出了一些解決辦法。比如：

(1)既然用Java實現(xiàn)Component比較慢，我們就盡量減少Component所執(zhí)行的業(yè)務邏輯

量。爭取把可以放在存儲過程中實現(xiàn)的操作，盡也許在存儲過程中加以實現(xiàn)。眾所周知，數(shù)

據(jù)庫的存儲過程操作，比起在Java程序中執(zhí)行數(shù)據(jù)庫操作要快得多。

(2)既然用Java建立數(shù)據(jù)庫連接比較慢，我們就可以把數(shù)據(jù)庫連接封裝成連接池(Connect

Pool),從而能非常有效地提高系統(tǒng)效率。我們也曾經用“LoadRunner”作過壓力測試，使用

連接池比不使用連接池的速度要快上3?5倍。

(3)為了對付JSP程序與Servlet程序會打印出異常系統(tǒng)信息的問題。我們曾查閱了很多

JSP或Servlet的資料，最終是毫無頭緒。但是我們可以換另一種思緒，即是不從程序下手，

而從WebServer著手，我們可以把Apache配置成為使這類異常信息不再打印出來，而是

使之僅出現(xiàn)一個通用的異常說明的頁面，這樣，就能十分有效地解決這個問題。

在我們使用Java作為編程語言的這么多項目中，絕大多數(shù)是比較成功的。Java語言作為一

種快捷、穩(wěn)定的計算機語言，開發(fā)基于因特網(wǎng)應用的項目大多是相稱穩(wěn)定和比較合用的。

在我個人看來，Java的應用前景十分光明，大體上可以著眼于以下方面：

(1)在因特網(wǎng)上將會有更加廣泛的應用.

(2)在嵌入式設備中，Java也大有用武之地。比如，在最新推出的Java技術中，Java已

經進入了手機領域。

(3)Java程序大多以線程運營，占用資源少，會逐步代替ASP與CGI程序。根據(jù)第三方

測試表白：JSP程序比ASP程序要快2倍以上。用JSP代替ASP應是大勢所趨。

(4)Java在無線互聯(lián)網(wǎng)中的應用將會更加廣泛。Java支持WAP,可以方便地用Java開發(fā)

WAP程序，實現(xiàn)WAP應用。

(5)Java與XML的無縫連接使Java在數(shù)據(jù)傳輸和異構網(wǎng)絡通信方面有著很大的優(yōu)勢。

就我個人而言，我將會在相稱長一段時期內致力于Java在無線互聯(lián)中的應用，為我國的移

動通信事業(yè)開發(fā)出更多的優(yōu)秀實用的項目.

【評注】

評注；參與了一個較大的項目后有實踐體會。全文都采用1、2、3、4方式，

文章的風格顯得單調，不大吸引人。但是本文的優(yōu)點是；

(1)寫得很有條理。

(2)內容的選擇合適。

(3)所列舉的策略、注意事項與發(fā)現(xiàn)的問題都很現(xiàn)實可信.

論文七論Java技術在因特網(wǎng)平臺上的應用-銀行業(yè)的應用

上海戴黎平中國系統(tǒng)分析師網(wǎng)站

【摘要】

因特網(wǎng)上應用的日益普及與深化，為Java技術的運用提供了廣闊的活動舞臺，也大大推動

了Browser/Server模式的公司內聯(lián)網(wǎng)應用與網(wǎng)絡計算。

作為某信息公司中的技術骨干，我有幸承擔了某銀行信貸管理與查詢系統(tǒng)等的開發(fā)任務，獨

立地完畢了其中的系統(tǒng)設計、類設計、部分開發(fā)及測試工作。

整個系統(tǒng)完全按照J2EE的標準來設計。前臺界面應用了JSP技術，控制部分采用了Servlet

來開發(fā)，業(yè)務邏輯應用了EJB技術來封裝，應用服務器采用了支持J2EE標準的BEA公司

的Weblogic,后臺的數(shù)據(jù)庫選用的是Informix7.3,目的是為了與銀行中其他業(yè)務系統(tǒng)數(shù)據(jù)

庫保持一致。在硬件平臺上，我們選用的是HP公司的某臺中型服務器機器，操作系統(tǒng)是

HP-UXo

該系統(tǒng)界面運用的是IE,它不僅兼容性較好，并且已為廣大用戶所熟悉。

系統(tǒng)運營后，各個支行都普遍反映界面友善，功能強大，開發(fā)的效果令人滿意。

【正文】

在銀行應用中私人的儲蓄、公司的會計、國際的業(yè)務、信貸、財務管理都是十分重要的，它

們構成銀行的基礎業(yè)務系統(tǒng)。我從事開發(fā)的信貸業(yè)務更是銀行利潤來源的重要部分。與儲蓄,

對公等以交易事務為主的業(yè)務模式有所不同的是，盡管信貸也是交易，但需要更多其他輔助

信息的支持。如客戶的基本資料，在本行內業(yè)務發(fā)生狀況、信用等級、是否有逾期貸款未能

歸還等。各個支行的有關業(yè)務人員及分行管理人員都希望能方便及時地了解這些信息。傳統(tǒng)

的基于終端的用戶界面難以傳遞這么多信息給用戶，所以我們決定采用基于測覽器IE的用

戶界面，一方面IE使用方便，不需要專門培訓，此外它是與Windows操作系統(tǒng)捆綁在一

起的，也可節(jié)省前臺費用。在開發(fā)技術上有ASP,JSP可供選擇。

由于考慮到Java技術在Internet上的迅速發(fā)展,J2EE更是提出了全新的用語言來統(tǒng)一平臺

的思緒，于是我們決定采納J2EE標準，并選用了JSP。在設計上，基本上是采用了一個

交易畫面相應于一個JSP程序，充足發(fā)揮JSP動態(tài)解決頁面的長處。

為了使設計有更好的可擴性、靈活性與邏輯性，能為以后擴展奠定堅實的基礎，我采用了

(Modelu,View,Controller)的MVC設計模式，View所有由JSP實現(xiàn)，而Controller則

是設計了一個Servlet程序，它負責解決前臺瀏覽器傳送來的所有請求，并按事先定義好的

途徑/程序關系，分發(fā)給相應的JSP程序去解決。由于Servlet本來就是為Java服務器端編

程來設計的，因此由它來負責服務器端的解決是相稱合適的。

在開始設計時，我運用了構件技術，由EJB承擔起設計模式的Modelu角色。具體的貸款

開戶，放款，結息逾期貸款，歸還貸款等交易都相應一個具體的EJB。為了將這些解決邏

輯與相應的數(shù)據(jù)庫操作分離開,能更加便于維護，我將解決業(yè)務的EJB設計成SessionBean,

而為每個SessionBean再配備一個相相應的EntityBean,用于訪問后臺的數(shù)據(jù)庫。貸款管

理中有很重要的一點是進行查詢，我按照需求分析的結果，為每類查詢都設計了相相應的

Bean,其目的是盡也許地提高查詢的速度。

在對數(shù)據(jù)庫的存取中，我本來的設計應用InformixJDBC所帶的DriverManager,這樣，在

存取數(shù)據(jù)庫中的Bean中就要把Driver及Server寫入，后來考慮到應盡量提高應用的平臺

獨立性，在參閱了J2EE中JDBC部分的說明后，改用了DataResource的解決方法，這樣,

即使以后數(shù)據(jù)庫換成Oracle或其他產品，程序也不用修改，只需要在配置時進行變動即可。

在這次信貸管理系統(tǒng)的開發(fā)過程中，Java的平臺無關性優(yōu)勢，在開發(fā)人員從事開發(fā)的活動

中體現(xiàn)得淋漓盡致。由于經費相對緊缺，我們的開發(fā)環(huán)境是各個項目組共用一臺HP機器，

雖然每個開發(fā)小組都搭建了自己的環(huán)境，但項目一多，特別是遇上結息與批量測試等場合，

機器就顯得不堪重負，使開發(fā)與測試工作的效率大為下降。我們小組由于采用的是Java技

術，大家可以在自己的NT機器上搭建相同的環(huán)境。這樣一來，大家平時的開發(fā)工作，涉

及JSP,Servlet,EJB的程序，都可以在本地完畢，只是到測試或展現(xiàn)階段才需放到HP開

發(fā)機器上進行。

以前我們開發(fā)的Web應用，往往只是應用了部分的Web技術，如采用ApacheWebServer、

ASP開發(fā)語言等。整個體系的集成與組合往往不夠抱負，這次由于我們采用的一整套符合

J2EE標準的組件，整個系統(tǒng)的協(xié)同性與一致性非常之好。再加上有一個支持J2EE的應用

服務器-BEAWeblogic,以往我們做得不抱負的復雜配置，模塊間的連結，如今都用不到再

操心了，只需在圖形化的配置工具中，輸入系統(tǒng)所需要的配置，如途徑與實際應用程序的關

系，組件中的EJB引用，DataResource的屬性等；所有配置完畢后，Weblogic會替我們

完

成項目的部署，并將這一切有關的程序都封裝起來。

本來，我們開發(fā)小組的文檔編制任務顯得非常之繁重，由于整個系統(tǒng)既有交易部分，又有管

理查詢部分，交易、數(shù)據(jù)與源程序都很多。為了解決這個問題，我們直接應用了Java源程

序中的Javadoc導出文檔，這樣不僅文檔美觀，并且可以保持與源程序的一致性，實乃一石

二鳥之舉。

整個項目完畢后，用戶使用下來都覺得界面和諧，操作簡便。但是我心里知道.這個系統(tǒng)尚

有很多可以加以改善的地方。一方面，基于Java系統(tǒng)的開發(fā)需要資金較多的投入，由于該

系統(tǒng)受到經費的限制，只申請到一臺生產用機，這樣，Webserver、ApplicationServer、

DBServer只能被擠放在一起。雖然Weblogic能實現(xiàn)部分負載平衡，但在將來的業(yè)務發(fā)展

時，這樣的分布肯定不是最抱負的。好在我們在設計時已經考慮過盡量有良好的擴展性，在

以后條件許可時，只需進行在不同機器之間的進一步部署即可，應用程序大體上無需改動。

另一方面，在設計上，可以采用UML的產品，如RationalRose,另一方面，RationalRose具

有自動代碼生成功能，也可以大大節(jié)省開發(fā)的成本。最后，目前的信貸管理系統(tǒng)相對用戶數(shù)

目量不多，當推廣類似系統(tǒng)需要擁有大批用戶時，基于Java的系統(tǒng)的響應時間與系統(tǒng)分布

都會有較為突出的矛盾出現(xiàn)。

以上這些，都是我在此后的系統(tǒng)設計與開發(fā)中需要加以注意的地方，也是運用Java技術應

當努力的方向。

【評注】

評注：討論具體，應用較為進一步，表達清楚。存在的問題屬實。

論文八論改善Web服務器性能的有關技術-銀行業(yè)的應用

廣州黃昌湛中國系統(tǒng)分析師網(wǎng)站

【摘要】

基于Web技術的數(shù)據(jù)庫應用是當前應用的一個熱點，在用戶數(shù)目與通信負荷很大的場合，

提高Web服務器性能是一個迫切的課題。本文從筆者參與某個銀行系統(tǒng)項目開發(fā)的經歷出

發(fā)，闡述了提高Web服務器的性能應滲入到項目論證、選型、開發(fā)、運營和管理的各個環(huán)

節(jié)，只有各個環(huán)節(jié)都能充足考慮到性能與質量的需要，系統(tǒng)的性能才是真正可保證的和可擴

充的。

文章從系統(tǒng)的實際運營與相應的經驗出發(fā)，闡述了性能改善方面的一些具體措施。

比如：在本文中討論了Web服務器平臺的選型考慮；Web服務器的配置管理；應用系統(tǒng)自

身的優(yōu)化與預先設計系統(tǒng)時可擴性的性能保障等具體內容。

通過技術上的分析與改善，綜合性地運用多類措施與手段，在實際系統(tǒng)中，Web服務器運

營的性能得到了一定限度的保證。

【正文】

我所在的單位是把目的定位于金融領域開發(fā)IT應用的一家信息技術公司。

隨著金融電子化建設的發(fā)展和商業(yè)銀行之間市場競爭的加劇，各重要商業(yè)銀行不斷通過信息

技術提供新的金融產品，并且希望能整合市場渠道。比如重要的商業(yè)銀行不斷推出形形色色

的網(wǎng)上銀行服務。在這種背景下，本人參與了開發(fā)新一代網(wǎng)上銀行產品，涉及到提供網(wǎng)上個

人理財服務、網(wǎng)上外匯買賣服務、網(wǎng)上公司服務等具有市場競爭力的產品。作為項目開發(fā)的

組織者之一和重要的技術骨干，在整個項目開發(fā)過程中始終要處在第一線，從而在改善Web

服務器性能、提高整個網(wǎng)上平臺系統(tǒng)性能方面收獲良多，在本文中簡要討論如下，希望與讀

者們共享經驗。在Web服務器配置與優(yōu)化方面，我有如下幾方面重要的體會：

第一方面是Web服務器選型考慮。

在Web服務器選型及網(wǎng)上平臺搭建之初，我們就已充足考慮整個網(wǎng)上平臺的性能及可擴展

性問題。這一考慮為該系統(tǒng)的穩(wěn)定性及擴展性能力方面打下了堅實的基礎。

某銀行原有的一些網(wǎng)上產品由于開發(fā)較早，故而采用的是老式的HTTPServer+CGI程序調

用的方式。這時，每一客戶請求需要相應于