老師推薦：
2024年計算機軟件水平考試易考寶典軟件
2024年計算機軟件水平考試用書
2024年計算機軟考網絡輔導課程
2024年計算機軟件水平考試易考套餐

系分論文1

企業人事信息系統的應用

【摘要】

    本文討論《企業人事信息系統》項目的需求分析方法與工具的選用。該系統的建設目標是幫助該企業管理好企業內部的人員和人員的活動，人事信息管理指的是企業員工從招聘面試到離職退休的全過程，涉及的主要活動包括面試、報到、培訓、升職、離職或其他的人事變動，也包括電子化考勤、工資性收入的計算與分發、使用其他公司資源的有關記錄（如宿舍、保險、證件辦理等等）。此外，本系統也涉及到企業在全國各地的人事信息管理，企業的組織架構的設置，級別與職務管理，人力申請直至人力需求報表，從而形成一個對企業真正有用的人事信息管理應用系統。在本文中首先討論了選用面向對象方法與工具的主要理由與策略，進一步通過一個簡例說明該方法與工具使用的效果，也討論了使用多種工具與方法在需求分析中的必要性，最后簡要小結了選用正確工具與方法的意義和作用。

    在項目開展期間，我擔任了系統分析、系統設計與數據庫管理等大量工作。

【正文】

     人事信息管理系統是一個有著廣泛應用面的實用性系統，但是，我國各個企業有著自身的體制、機制、特點與不同的要求；在開發這類系統時，系統需求分析是極為重要的一環。在整個分析過程中，我們都采用了面向對象的分析方法，這是因為我們在近幾年的實踐中已堅信這種方法能夠更加有效地表達和描述現實世界。軟件要具有適用性和擴展性，就必須更接近于現實世界本身的發展規律。

    以一個簡單的例子來看，假設要求設計關于引進人才評估的一個系統，按我們過去的做法，先會要求提供給我們一份相關的引進人才評估表，然后依葫蘆畫瓢地設計相應的表單與界面。在短期來說，這樣做是簡便而實用的，但并不能夠符合現實世界的長遠目標，這套設計方法不具有擴展性，因為任何一份評估表的結構都會有可能發生許多改變的。采用面向對象的方法，可以從中提取出表類型、表結構、評分方法以及能考慮繼承等各方面的要素，這樣就可以保證軟件的通用性，可配置性與可維護性。

    在工具的選擇過程中，我們選擇了現在已十分流行的Rational系列，包括Rational Rose、RUP、SoDA等，為什么選取這個系列工具呢？這是基于我們對軟件需求分析目標的看法，我們認為需求分析應當能正確地回答如下的幾個關鍵性問題：

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

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

   （3）分析是否會和設計相脫節，

   （4）程序員能明白我們的分析與設計要求嗎？等等。

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

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

     用戶的需求可分為顯式的需求與隱性的需求，用戶的傾向往往只顧及到當前的與明顯的需求。要達到對需求理解的全面性，不僅僅只是依靠有效的用戶談話和調查，因為我們所面對的用戶需求往往會有些片面的，采用Rational Rose（基于UML）提供的用例，以及多種圖的聯合使用，可以使我們發現其中的遺漏。

   （2）使用戶能充分地理解我們的表示方法，能夠真正明白我們描述的內容。

    軟件需求分析規格說明書通常會是冗長而枯燥的，一般的用戶不容易深入理解，這樣就削弱了分析的正確性。通過支持面向對象及UML語言的Rational Rose可以更好地和用戶交流，讓用戶了解系統的運作方式甚至細節的操作。

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

     這是我們選擇面向對象的方法及Rational Rose工具的重要原因，系統分析要向用戶描述的不僅僅是用戶的需求，而且包括解決方法，解決方法當然應包括設計（程序）、數據庫與系統配置，我們當然不希望用戶得到的是一個與需求規格說明不相同的軟件，也不可能要求程序員完成一個不可勝任的任務。然而我們在以前的多項工作中經常發現這類情節，因為系統分析與設計相互脫節，導致一頭扎在分析中不顧設計有關的事宜。

    分析與設計的脫節，還不利于設計現格說明的評估，因為分析往往會脫離現實，導致缺乏評估的依據。

    因為不可能成功地完成設計而使分析需要重來，就會造成巨大的浪費與損失。一個好的工具可以使分析與設計更緊密地連結起來，甚至于—一對應。面向對象的分析方法使對象之間相對而言有獨立性，減少了任何影響到全局的改動，能避免因需求變化而導致全盤皆動的被動局面。

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

     一個好的設計應該讓程序員感到清晰明白，更少疑問。一個疑問很多的設計加上溝通不暢，絕對會出現在應用環境下所不需要的另一個軟件，所以設計規格說明書務必清楚、形象與明確，當然，Rational Rose具有足夠的圖形與其他形式，能使程序員更加明確，甚至能細微到每一個語句（事實上如果使用VB，程序架構都有可能直接生成了）。

   （5）選擇UML可能會有更多的理由。

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

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

     在分析中，面對考勤班次的問題時，由于過去一直使用紙卡方式考勤，使用戶對班次形成了固定的概念，而現在的許多考勤軟件也采用多次刷卡的方法來形成一天的記錄。經過面向對象的分析可以發現，事實上每天的上班記錄是由多個時段所形成的，時段的多少在各個公司，各個工種與部門都不盡相同，每個時段可能有不同的屬性，時段與時段組合可形成為班次，這更適合于現實的情況，使之能更加靈活與更有擴展性。其實，在天與天之間也都有相互之間的關系。在這一點上，我們又發現必須在考勤與薪金工資中加入與MRP中相似的期段（Periods）的基本概念，比如可以稱之為考勤期段，允許為用戶更加方便地設置考勤期段，可能使之不一定與自然年月日相同等等。

    Rational Rose使我們更方便地把上面的想法在類上去實現，更進一步地設計好我們的高效率的數據庫。

    當然，使用單一的一個工具去完成一個中大型的應用系統的需求分析，是不可能成功的。因為社會在發
展，用戶的需求也在改變，如何把握住用戶的需求是需要時間的，面向對象的方法有時也會忽略外在的與表層的要求，不僅僅是要獲得關鍵的需求，其他更多的需求往往要等到用戶在使用后才知道，然而等到用戶使用是不現實的，作為原型開發模型中的原型也是收集用戶需求，描述與解釋需求的一類相當有效的方法與工具。

    在我們的開發過程中，為了更好地讓用戶了解我們的系統和我們的設計方案，讓用戶在見面會上更有方向性與針對性，我們首先用Access開發出原型，讓用戶先試用。這樣，我們在真正的分析與設計時就能更加符合用戶的要求。

    總之，軟件需求分析方法和工具的使用，對我們軟件開發過程影響是很深遠的，選用高效能的正確的方法與工具，可以使我們的軟件更加正確地反映現實需求，更加具有可用性、可擴展性和可維護性；降低了軟件項目的風險。

評注：（1）寫得有些特色，觀點鮮明。（2）摘要寫得不錯，既反映了項目內容，也小結了本文的寫作要點。（3）文中所舉的例子雖然簡單，但很實際。（4）多種方法與工具的使用，敘述得簡明扼要。（5）內容可更豐富一些，更深入的例子也可再增多一些，則會更有說服力。（6）對需求分析的全過程的描述太少。（本文主要參考了廣東延國慶等人的論文）

系分論文2

企業集團的信息管理系統應用

【摘要】
    本文以某個IT產品銷售公司的信息系統項目的開發為背景，討論了一個信息系統需求分析的整個過程，其重要特征是：所涉及的項目是原有系統的一個升級替換版本。因此，需求分析過程不同于建立一個全新的系統，大體上可分為三個階段：（）實施逆向工程獲得對系統的初步了解；（2）在第1步的基礎上寫出基本需求，交由客戶評審補充；（3）在第2步的基礎上開發原型，利用原型與客戶交流，最終獲得基線需求。針對上述三個階段，本文論述了所使用的分析方法與工具以及所遇到過的一些典型問題和措施，最后對需求分析中使用的工具，談一些自己的初步體會。

【正文】

    我于1998年8月至2000年7月參加了某個大型集團的企業信息系統的開發工作，該大型集團的業務主要涉及到IT類產品的進銷存。本人在項目中負責系統分析的工作，該集團企業原先已委托某個電腦公司開發過一套IT類產品管理系統，但是該老系統存在兩個主要的問題：（一）系統運行速度非常慢，如商品銷售開單時，從確定開單到開單完成有時需要1～2分鐘左右的響應時間，讓客戶無法忍受。（二）系統數據不準確，經常出現實物庫存與電腦庫存嚴重不相匹配的情況，使銷售數據的統計產生一些混亂，有關財務的數據因此無法有效使用，只能采用人工錄入方式補充進行。在這種情況下，該集團的總經理決定參考原有系統重新開發一個系統，以便解決原系統所存在的上述兩個難以克服的難題。注；原系統采用PB6.5開發，數據庫采用SYBASE，服務器采用Windows2000Server，客戶端采用Windows 98，程序架構采用的是傳統的C/S結構。

    鑒于該集團業務操作復雜，流程多，涉及人員多等特點，以及項目完成時間短，經費有限，人員有限等限制約束條件，再考慮到必須避免前一系統出現過的結構混亂與難于維護等問題，我們決定要對原系統的需求做一個比較徹底的和切實可行的分析，由于原有系統已經開發了近兩年，并且客戶也有了一定的使用經驗，業務基本流程本身也并沒有太大的變化，因此，我們把需求分析的過程分為三步：（）分析原有系統的結構，主要是數據庫結構和程序結構，（2）在獲得第（1）步結果的基礎上寫出基本需求，交由客戶評審補充，（3）在第（2）步的基礎上開發原型，利用此原型與客戶交流，從而獲得最終可用的需求結果。下面按上述三步分別加以論述。

    第一步是實施逆向工程，獲取原有系統的基本需求。

     由于原有系統在功能上大體上能基本滿足客戶的需求，并且在兩年多的開發中也積累了不少經驗，因此，從中可以獲得一些有益的參考，也可以避免多走彎路。在這一階段，我們采用的主要工具是PB自帶的Power Designer和PB Documents；前者主要用來分析數據庫結構，后者主要用來分析程序結構，便于開發人員與高級用戶理解程序。采用這兩個工具的原因是：原系統過于龐大，模塊多，數據庫模式多，表格量很大，僅靠人工的方法很難從中獲得一個比較完整的、明確的系統結構以及整體構成，而且原有系統未能提供一套正確完整有效的設計文檔，于是我們只能依靠工具輔助來進行。在使用 Power Designer分析數據庫，并且用PB Documents分析原程序中的PBL以后，我們對原系統的結構有了一個初步的了解，再結合對原系統的使用，基本明確了功能與流程的需求，并在此基礎上用人工錄入方式，產生了初步需求的自然語言文檔。這里指出，使用Power Designer的一個不足之處是：如果一個表中的字段過多，而且又同時依賴多個表時，輸出的表格相關圖形很復雜，有很多交叉，且難于調整，不方便閱讀及打印。

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

     通過第一步的逆向工程，我們獲得了系統的基本需求。為了充分記錄需求的變化及需求之間的依賴關系，我們決定選用Rational公司的 Requisite PRO作為我們的需求管理工具，Rational公司有一整套用于需求管理的工具，功能非常強大，包括Requisite Pro、 Clear Quest等等，這些需求分析工具可以對需求進行全面的管理，包括記錄需求的變化情況，需求之間的依賴關系等等。但是，我們考慮到 Rational的一套工具全面實施會非常昂貴與復雜，需要非常強的項目管理能力才能全面實施，因此，我們只采用了其中最簡單的一部分功能，那就是記錄需求變更，記錄需求之間的依賴關系，其他跟RUP有關的功能都給略去了。之所以這樣做，主要是考慮到項目的經費、人力以及國內軟件開發的實際情況。正如前面所說，我們根據自己的理解并寫出基本需求后，交由客戶做評審井做適當補充，我們將經過補充整理后的需求作為正式需求記錄入Requisite Pro所維護的數據庫中，并對各個需求進行分類，設定優先級等，這些工作完成后，就可以從數據庫中直觀地了解客戶到現在為止提出了哪些需求，哪些需求是必須優先考慮的，哪些是難度較大的等等。在這個過程中，我們遇到了一些問題，譬如：用戶對我們用自然語言書寫的需求文檔有許多地方不理解，往往在花了較長時間閱讀之后，仍不明白我們所描寫的需求過程與他們所完成的業務之間的對應關系；另外是由于首次采用Requisite Pro進行需求管理，在類型劃分，屬性值的確定上，部分開發人員沒有經驗，造成了不少反復，對于前者，我們的方法是想辦法增加一些示意圖，將大的流程分解為小流程，再與客戶反復交流與溝通，最終達到雙方理解一致的目的。對第二個問題，則參考了一些例子，再結合實際中屬性的使用情況，給予取舍或者選擇，經過這一階段的工作，我們建立了基本的需求庫，定出了基本需求規格說明。

    第三步則是在第二步的基礎上建立起原型，利用原型與客戶進行更深入的交流，通過交流修改相應的需求。

     在這一階段的工作是在對第二步任務進行報告交流的基礎上進行的。我們用PB開發了一個原型系統，就具體的業務流程與客戶進行交流與溝通，通過原型，客戶發現了許多我們與他們的理解相互不協調的地方，我們在修改需求的同時，也在Requisite Pro需求數據庫中記錄下修改的歷史。事實證明，這種記錄歷史的作用是很有效的，如曾經有客戶在兩個不同的時間對同一需求提了相反的需求，我們根據歷史記錄很快證實了該客戶的提法有錯誤，在事實面前無需再作爭論，同時利用Requisite Pro，我們還發現了一些需求相互之間有矛盾。經過這一階段工作，我們終于獲得了經過用戶認可的需求基線，即是可用于下一步進行詳細設計的基線需求。

    在這個項目中，我們利用了Power Designer、PB Documents等逆向工程分析工具和Requisite Pro需求管理工具，這些工具的使用，使我們提高了工作效率，起到了一定的輔助作用。但是，就需求分析工具方面而言。我們覺得國內應用得還是太少了，這一方面是因為對需求分析不夠重視，另一方面是因為管理水平還達不到相應的層次。Rational公司的一整套需求分析工具，其功能是非常強大的，國外已在普遍地使用，在國內也逐漸開始普及，特別是那些通過CMM二級以上評審的單位，都必須使用工具對需求進行管理。在本項目中，我們僅僅利用了Requisite Pro功能的一些小方面，已經體會到該工具對于項目管理的諸多好處。如果一個有實力的公司能夠全面實施RUP，那么需求管理這個老大難的問題會變得不再那么棘手了，項目的質量也會得到相應的提高。目前國內由于CMM熱潮的興起，已經逐漸重視需求分析，也逐漸使用需求分析工具，這是非常可喜的，當然，更希望在不久的將來，能用上國產的需求分析工具，那時我們的軟件產業也許會真正地騰飛了。

評注；采用逆向工具進行再工程的應用很多，本文給出了一個實際的例子。寫作有條理，也很實際。合理地界定了需求分析的現實水平。所采用的需求分析的方法與工具相對較合理科學。能在對項目討論的同時抒發議論、使用體會、愛國心和事業心。深度還可以提高，例子宜更加豐富一些。（本文主要參考了廣東劉小波等人的論文）

系分論文3

論軟件需求分析方法和工具的選用——論文3：通信行業的應用

【摘要】

    本文以某通信公司的業務報表系統開發為例，討論了軟件需求分析工具與方法的選用。我們認為，軟件需求分析是軟件工程中重要的一步，直接關系到后繼工程的進行以及最終的產品能否滿足用戶的需求，因此在整個工程中起著關鍵性的作用。采用適當的工具，有可能顯著減少需求階段的錯誤，也可大幅度提高需求分析的質量和工作效率。當然工具的選用應當與實際的項目相結合，充分地發揮工具的作用。本文結合我們工作的實際經歷，簡要討論了開發系統時所選用的工具及其應用，選用時所考慮的原則以及所碰到的問題。在文中也結合多種開發方法（即傳統的瀑布法、信息工程法、面向對象的方法）的比較，指出各種方法的不足之處，說明我們所采用的工具對軟件需求分析所起的作用，以及相應產生的效果。

【正文】
    我在某市一家通信公司工作，作為一名技術骨于，受領導委托，參與了開發本公司的業務報表系統，我擔任系統的需求分析、總體設計和部分代碼的編寫工作。

     我所在的企業作為一家通信運營公司，分為總部、省級公司和地市級分公司三級，各級公司之間都有數據報表的要求。但是，每一個地市分公司因所處的地方不同，經營環境不同，所面臨的問題也不一樣，因此形成了各具特色的數據報表（除地市分公司向省公司匯報的之外）。公司又分設了許多部門，這些部門也都會需要數據，作為分析決策的依據。因此，了解各個部門的需求就成了業務報表系統的關鍵。

    在調研的過程中，我選用了一種工具叫Play CASE，可以從網上免費下載，有很強的功能。下面就介紹一下，在需求分析階段，我是如何使用這一工具的。

     第一步，了解業務組織結構。公司內部的數據實際上是在部門之間流動的。業務部門需要知道在本地覆蓋區內各基站的話務量、當天的話務量（即話務量的時空分布）。財務部門需要知道本月各類用戶的話費收入、預交款收入、與其他電信運營商的網間結算等。計劃部門需要各部門的分析數據。計費部門需要提供本月的賬革統計數據、話單統計數據分布（比如分別按照基站分布、時段分布以及按用戶類別分布）、預交款統計數據、當前的欠費總額分布、催繳情況等等。這些部門時常為了數據而產生了大量無謂的爭議。在使用Play CASE工具時，先要將這些部門錄入到Play CASE的“業務部門”中．構成了一個信息源的接收點（或發送點）；而Play CASE通過圖示表示了這些部門的關系，并轉換成了相應的軟件結構。實際上，這是一種系統建模的方法，即把業務系統中的各個組織轉變為軟件功能中的各個結構。這樣，在需求分析階段，明確哪些部門需要數據，從而保證了需求分析對整個公司的全面性，而不會忽略掉某一個部門，導致需求分析的不完整。

    第二步，了解各個業務部門中的業務流程，使之通過Play CASE轉換成軟件的運行過程，這是一種動態建模的方法。在上一步的基礎上，追蹤各個部門的行為，錄入到Play CASE中，并以形式化的語言描述各過程。對于復雜的過程，該工具還提供了進一步細化的方法，并且形成了業務流程圖和業務狀態圖。根據這些流程圖、狀態圖與實際業務部門的業務相結合比較，還是較為吻合的。在此步的實施過程中，運用了動態建模技術，使各部門業務流程的情況在軟件的運行過程反映出來，從而保證了需求分析階段中運行過程的描述能真實地反映實際情況，防止在后繼的程序編寫過程中，可能會經常發生的一類情況：程序員因為沒有理解業務流程而出現“閉門造車”的現象，從軟件的功能角度上保證了軟件的正確性。

    第三步，將業務數據轉變為軟件數據，這一步工作實際上就是收集各部門所需要的數據。分析各部門需要的數據都有哪些；以及數據是如何轉換的，這可以歸入“功能建模” 的范疇。將這些相應數據錄入到Play CASE中，選定所屬的部門。這時就自動地建立了DFD圖（數據流程圖），數據字典，省去了人工建立時的很大麻煩。

    第四步，將業務上的數據關系轉變成軟件中的數據關系。這里采用了面向對象的方法，把業務部門所需要的數據看作一個實體，部門間的數據關系就是實體之間的關系。比如：經營部門所需要的用戶資料、用戶話費，實際上就是用戶這一實體與賬單這一實體間的關系。Play CASE提供了構件（不過我覺得是部件更為合適一些），來表示對應的數據，并提供了三種構件的表示關系即組裝關系、分類關系與相連關系。這三類關系基本上反映出了現實世界中的業務數據之間的關系。例如現實世界中的用戶資料與用戶話費，在Play CASE中，可將用戶構件與賬單構件用相連關系表示。這種方法，實際上是借鑒了OOA面向對象的分析方法中的類、聚集、繼承、封裝等概念，能較好地反映出現實中的業務；同時，這一步的工作也為總體設計中數據庫的概念模式設計奠定了很好的基礎。

    經歷了上述四個步驟以后，利用Play CASE工具自動生成了軟件需求規格說明書、初步的DFD圖和業務流程圖，為下一步的總體設計打好了基礎。

     使用Play CASE工具，使需求分析既能繼承傳統的結構化分析方法，又能吸收面向對象設計方法的優點。比如能把業務流程轉變成為運行過程，業務組織轉變成了軟件的結構等都體現了這一點。而在運行過程中，對復雜過程的細分以及追蹤則反映了傳統方法中的自上到下分解的分析思想，這對于解決復雜系統的分析是很有幫助的。

    通過使用，我覺得這個工具還是很不錯的。因為它實際將以下四個方面的問題結合起來了：軟件、業務、開發人員和用戶。對于用戶而言，Play CASE用圖形化的方式顯示出業務流程，使用戶了解業務在軟件中的運行過程，提供了將來驗收軟件時的依據。對于開發人員來說，使開發人員能更清楚地了解業務流程，不會再發生“因為不理解用戶的需求而出現的閉門造車情況，從而導致開發出來的產品不符合用戶需要”的現象。因此， Play CASE所自動提供的需求說明書能夠很好地溝通用戶與開發人員之間的理解，使他們都能對需求有共同的理解。

    使用 Play CASE工具后，使我們的需求分析取得了很好的效果，不但能自動地提供許多結果，如需求說明書等；還使需求的質量有了很大的提高，受到領導的贊揚（領導不是學計算機的，但對公司的業務十分熟悉）；在后繼的設計與維護工作中，我們感到工作似乎輕松了很多。

    當然，該軟件工具也有不足之處，一個突出問題是靈活性不夠，一縣公司的部門或者組織機構發生變化時，整個設計都要重新來過。因此，在改進的過程中，我們在第一步過程預留了好多個虛擬的部門，以備將來進一步的擴充或者變動。

評注：（1）具體項目有些體會，完成情況似乎不錯。（2）條理較清晰，比較系統地描述了使用Play CASE的過程和體會。（3）偏重于工具的討論，對需求分析的方法分析還嫌不夠。（4）項目相對較小，僅涉及報表系統，對更為復雜的業務流程應舉例分析，才能更充分地體現方法與工具的作用。（本文主要參考了廣東魏福建等人的論文）

系分論文4

論軟件需求分析方法和工具的選用——論文4：IC行業內部的CAD應用

【摘要】

    本文通過一個集成電路設計有關的軟件項目，討論了該項目的主要特點和本人所擔任的工作，著重討論了在項目需求分析過程中采用的具體方法和工具以及選用的理由。

     由于項目的專業領域的特殊性，分兩類不同的需求討論了需求分析中遇到的問題及解決方法；在這個過程中給出了對選用的具體工具和方法的效果的描述。接著本文討論了對使用方法的改進的一些想法以及具體的實現過程。最后提出了我對需求分析的某些看法，強調了與客戶溝通的重要性。

【正文】

     近年，我一直從事某企業中有關IT項目的開發，有一個系統是用于計算機輔助電路設計的，包括了從上流設計到下流設計的所有流程，如用于可設計百萬門數量級的邏輯門電路。有關方面把電路中路徑的提取、過濾以及表示的某軟件開發任務交給我公司，我有幸擔任了該部分的需求分析以及設計。

    我所設計部分為一單獨可啟動的軟件，主要是解析文件中的連線路徑，以列表視圖和用直方圖等把它們顯示出來，還可以執行諸如查找與過濾等功能。

    委托方對此提供了很初步的需求說明，把一些基本功能及性能要求描述了一下。我在需求分析時的工作主要有兩點：第一，對該軟件的界面等詳細需求要自己重新進行分析提取。第二，對于已提供的功能要求需要深化和細化，以形成真正完整的需求分析文檔。

    在接到需求分析任務后，我分析了一下所要完成的工作。發現由于是專用領域的軟件，對專業領域要求相當高，所以準備把此項目分成兩部分：

   （1）界面所受專業領域影響幾乎沒有，但由于全部沒有任何要求，反而會感到風險和改動可能是最大的。

   （2）功能方面由于委托方的許多功能都可以調用相應模塊來得到，并且已有了相應的書面的簡單需求，相應來說只是完成深化。對界面，我采用了部分RUP的思想迭代與漸進。而對功能需求采取了分層細化，每細化一層就要求委托方確認、修改和補充。

     首先把風險較大的部分完成，這是現代軟件開發的基本常識。我選擇先進行界面的需求分析。第一步是根據功能描述抽取出邏輯模型，并使邏輯模型與界面元素及功能一一對應，大體上決定了界面應有的功能，然后根據該界面功能描述，確定具體的控件，這時，我參考了委托方已初步完成的主窗口的界面布局及控件的使用規律，然后根據需要完成的功能從Qt（由于要支持Windows和Unix雙平臺，所以控件庫采用Qt）的類庫中選擇相應的控件。在提取和抽象邏輯模型時，我采用了Rose 2000中的用例圖，即以 USE-CASE圖來描述與外部的關系。之所以采用Rose，我是基于以下的原因：第一，在已開發的部分中，委托方統一要求我們使用Rose進行類和順序圖等的設計和代碼生成。第二，Rose提供了標準的圖來描述系統與外部的關系，在全球范圍已是一種標準結構。第三，使用上的方便性。我用Rose的USE-CASE圖，理清了我們的軟件窗口與委托方主窗口以及外部角色（操作者）之間的相互關系。

    在確定了界面元素后，考慮到文檔的可理解性不是很強，我采用Visio 2000把界面的外觀繪制出來，寫上了基本的控件作用，隨后送給委托方評審，幸運的是除了幾個小功能的修改，委托方基本批準了我的方案。

    下面的工作是為控件的行為及狀態變化制定相應的狀態遷移圖，我選用的工具仍是Rose，我用了狀態圖和時序圖，把重要的控件狀態變化及相應順序進行了描述，隨后的幾天把相應的DOC文檔建好寫明，基本上界面設計就完成了。

     下面的需求是針對功能需求的。雖然委托方技術部門有初步的需求文檔，但由于領域的專門化不對，我不清楚其中復雜的路徑提取關系及較深入的專業術語，一直有一種舉步維艱的感覺。只能采用分層細化的原則，從最初的幾條深入一層變成十幾條。這樣的話，不會一下子碰到太深的專業問題，可以循序漸進從委托方與文獻的解答中不斷學習，深化自己對專業領域的了解，這樣在設計中自己始終是層層推進的，不至于一于碰到無法逾越的專業障礙。

    在這一階段的開發中，由于一直是與自己不熟悉的專業領域打交道，所以我覺得一些輔助設計工具似乎無法發揮應有的功能。在這期間，對我幫助最大的應是公司的E- Mail系統，所有不清楚的問題的提出，以及對問題的解答都通過它進行周轉。換句話說，在需求分析階段，它起到了一個與客戶的交流溝通和客戶需求的提取作用。所以，我認為在這一階段，E-Mail系統是對我幫助最大的工具，其次是Excel，我用它建立了問題跟蹤圖表，對每一個提出的問題，均需要記錄上去，把問題結果（可分為已清楚、仍不太清楚、不清楚、尚未回答）均記錄下來，根據這些表，我可以很好地了解自己工作中的核心問題，并有了解決它的方向，提高了工作效率。

    每進行一層的細化，我都把結果交付委托方審核，由他們進行提出何時能終止細化，大約在八層細化后，對方認為已達到了效果，確認可以結束。至此，分析工作全部完成，項目的需求分析基本成功了。

     在這次需求分析中，我認為取得成功的原因主要是方法和工具選擇得正確。在界面設計中采用了流行的輔助工具，對需求及邏輯模型的建立提供很大的幫助，可以更方便幫助自己理清思路。選用了迭代法，把一些錯誤的影響在功能分析和界面分析的不斷迭代過程中加以改正。在后期，以功能需求為主時，我主要依賴的是溝通工具和表格工具，這也說明輔助工具不是萬能的，需求分析的關鍵之關鍵，應是與客戶的交流與溝通。

    通過這次案例，我認為在軟件的需求分析工作中，方法的重要性應遠超過工具的使用，應當首先確定分析中的風險，把風險分類，用不同的方法去解決各類風險，而工具的選擇不僅是要看影響力和名氣，而是要真正為我所用，應把握其精髓，即是此工具到底可以對開發有什么幫助，而不是僅限于如何使用。我認為在需求分析中工具的作用不外乎兩個：一是實際系統與環境模型等的抽象工具，二是需求表達工具。第一類的代表是Rose，第二類的代表是Word，WPS，Visio等，在這次項目中由于地理上的限制還用到了溝通工具，Web瀏覽與E-Mail服務系統。

    最后我還是總結一下，在需求分析中工具方法都只是輔助項目成功的因素，真正的決定因素還是—一“與客戶的溝通”。

    評注；
    （1）較實際地討論了方法與工具。（2）兩類需求的討論有點特色，解決需求問題的方法較成功，有說服力。（3）能發表自己的觀點和意見，體會較實在。（4）本例似乎有些特殊性，還是要鼓勵對自己熟悉的業務領域做項目，否則的話，有時會事倍功半。（5）最好再列舉更多的項目或例子，使方法與工具的討論更全面一些。（本文主要參考了上海解亮等人的論文）

系分論文5

論Java技術在因特網平臺上的應用——論文1：ERP開發的應用

【摘要】

    根據某類企業的迫切需要，我所在的信息技術公司組織了一個企業資源計劃（ERP）項目的開發，希望推進我國ERP應用的發展，也希望更深入有效地運用 Java技術。該項目的內容涉及到某類行業的企業生產經營的全過程，其基本目標是為了提高企業的勞動生產率，增加企業的利潤，優化配置企業的資源，使企業的整體運營水平能上一個臺階。這是一個基于Java技術的Intranet典型應用項目。

    在該項目中，我承擔項目負責人的重要職責，比如在項目的準備階段，我曾組織了對項目組的成員進行該類企業業務流程方面的培訓；在項目需求分析和設計階段，我著重考慮了架構好系統的框架和原型，為項目組及其他分析員進行下一步的細化分析奠定了堅實的基礎。同時我還組織好項目總體組，把握住各模塊之間的接日分析，保持各個分析員之間實現密切的溝通。在系統的開發階段，做好開發、測試方面的協調和同步工作，保證系統的可靠性，在系統的實施階段能夠順利地推進項目，此項目開發后的應用已得到了用戶們的一致好評。

【正文】

    與國際上ERP項目的廣泛應用相比，我國的ERP應用水平尚有相當大的差距。根據某類企業的實際迫切需求，我公司組織了對一類ERP產品的開發，我有幸參與了該項目的分析與設計，開發的成果是一個典型的Java技術應用于Intranet的實際項目。

     在選擇具體的技術方案時，我們曾經進行了認真的思考和研究。對于選擇普遍采用的微軟模式的平臺方案，還是跨平臺式的Java方案，我們曾舉棋未定，這是因為微軟的VB＋ASP已成為大家在較長時間工作后認可而熟悉了的方案。而Java由于其環境要求高與執行效率低的老大難問題，成為我們擔心害怕的重要因素。但是Java的跨平臺特性越來越成為人們的關注點，尤其是許多大中型的企業，他們現有的網絡系統都是基于多種平臺的，對跨平臺的要求和呼聲極為強烈，而對軟件公司來說，軟件的跨平臺特性有可能會節約開發成本，降低維護量，也能獲得更多客戶的認可。綜合考慮了諸多市場行情與行業發展因素，最終決定一定要用Java。所幸的是現在Java用于因特網的開發也已經越來越便利了。

    目前Java在因特網上的開發技術已呈白花齊放之勢態，有最初的Java Servlet，有與數據庫聯系在一起的SQL-J，還有可與ASP和PHP相媲美的JSP。尤其是JSP技術的迅速發展，使得 Java的網絡應用不再是少數人的專利，JSP以其執行的高效性和使用的方便性，已成為近年來大家首選的因特網開發技術，JSP是一種頁面開發技術，它以 Java為其服務器端語言，結合Java Script作為其客戶端語言，能方便地實現頁面的表示。

    選擇好了后端的Java和前端的JSP，還有一項重要的任務，那就是前后的聯接。由于JSP主要用于頁面表現，需要表現的內容要封裝起來，這樣，為了保證主要商務邏輯的安全性，我們采用了Java Bean作為橋梁，即客戶端JSP通過其中Java Bean的使用，完成主要的商務邏輯功能。在后臺，將Bean構造好，形成一個強大的Bean庫，再由前臺JSP進行使用。

    在進行Java Bean的規劃時，我們下決心作出很大的投入，因為這些不僅是我們當前項目中所需急用的，而且還應成為公司長期積累使用的一個強大的資源庫，能實現一定程度的資源共享和軟件復用，為其他項目開發打好基礎。因此，此次規劃的目標是形成公司Java技術的Java Bean的平臺庫。

    我們根據Java Bean所體現的類的用途，將這些類分成幾個層次。最底部的一層就是參數化類的構造，這一層的類所實現的主要功能包括通用訪問機制，對數據庫等其他層次的訪問接口和公共處理系統等。中間一層是實體類的構造，這些實體類包括與數據信息相關的結構及其處理方法，其中的重點是包含了一些重要的商務邏輯的處理。這一層類與系統各部分相關，并且其安全性要求很高，直接影響到系統主要功能的體現，因為系統的主體是對一些邏輯進行處理，這就要求這層實體類的規劃需要十分認真，做到細節準確。最上面的一層可以稱為接口類，這一層類主要用于實現底層的類與前臺之間的關系。也只有這層類才能由前臺JSP進行Java Bean調用而加以使用，只有這層具有開放性，這一層類除了上述的接口功能外，還應當有一項重要的實用內容，即包括用于實現前臺JSP的頁面自動構造程序。

    這里所說的頁面自動構造程序可以認為是本系統的一個重要特點，目的是為了讓用戶可以方便地自定義界面，而不需要由程序員修改程序，這樣能夠極大地滿足了用戶的要求。頁面自動構成程序的主要內容包括對界面元素的定制與修改、位置的修改、動作的觸發、行為的控制以及報表設計和計算匯總等功能。頁面自動構成程序的設計主要采用上述的接口類與JSP相結合的方式，用類實現元素的定制、控制及關聯，并將重要信息加以保存，以利于用戶的多次反復修改。該自動構造程序提供了強大功能，已成為我們的一個獨立產品。能應用于各個項目的界面制作，實現了我們原先制定的共享資源的目標。

    在前臺JSP的應用中，做到了盡可能最簡化的程度，這樣可以提高系統的安全性。當然在我們的系統中，還存在一些客戶端控制比較復雜的情況，為保護這段比較復雜的控制腳本，我們采取了用Servlet的方法，保護這段腳本，從而保證了一定程度的安全性。

     在系統的登錄過程中，我們采取了相當嚴格的登錄鍵檢查操作，用戶沒有供應商提供的相應的鍵，就無法通過驗證而進入系統。對于試用版的用戶則提供了一種有效期限約束。這些加密或安全措施，通過在Java Bean中封裝了嚴格而有強大功能的加密算法，在客戶端申請驗證后才能準予通過。

     在使用這套技術方案的過程中，我們曾經遇到過許多的困難。比如；前面曾提到過要求JSP中代碼能夠盡量簡化，以提高安全性。由于JSP中仍有一些容易讓人可能猜測到處理方法的語句及處理的過程，為進一步提高安全性，我們通過查閱大量的網上資料，才形成了一套較好的措施，比如制作JSP的標記庫，將有可能被猜測的處理進一步加以規劃，對應地生成一套行之有效的實用標記庫，這樣就又增加了一道很有效的防護墻，大幅度地提高了安全保密性，并且使頁面結構的分離達到了一定的水準。又如：在對數據的處理上，剛開始時也總是遇到系統運行會變得越來越慢的情況，最后追查其原因，發現原來是數據的連接過多，我們及時地采用了數據連接池等技術解決了此類問題。

    該系統采用Java平臺，提供了深入地使用Java Bean和JSP的方案，其效果是相當顯著的，在用戶真實使用環境中受到了一致好評，運行也較為穩定。由于采用了統一而方便的頁面自動構造程序，用戶的界面非常友善，并且可以按用戶需求進行定制，滿足了用戶的適應性需求。而在我們公司的內部，也開始建立了一套基于此平臺的資源庫，成為公司的今后開發使用的寶貴財富。
必須指出的是，在此系統中，還存在著很多的不足，比如實體類的組裝程度尚不盡如人意，根據多種商務邏輯的一些共同點，可以進一步加以抽象封裝，使這部分內容能滿足多種系統對類似邏輯的處理過程。我將會在今后的工作中進一步加強各方面的分析能力，帶領團隊不斷地超越現在的層次與水準，加強我們的隊伍建設，希望有更多優秀的軟件產品上寫著Made In China。（本文主要參考了上海陳莉莉等人的論文）

系分論文6

論Java技術在因特網平臺上的應用——論文2：通信服務平臺的應用

【正文】

    數據通訊是當前十分活躍與熱門的計算機與信息技術的應用領域。某大型通信公司開發了其業務的主要支撐平臺，在這里，我們簡稱之為“通信信息服務平臺”，用于在全國與全球開展數據業務的需要。該平臺是一個典型的Java技術應用于Internet的項目。

    作為信息技術公司中的一名技術骨干，我有幸參加了該系統的分析與設計工作，承擔了相當多的Java應用開發任務。此系統中的軟件部分大多由Java來實現，在全系統中我們是這樣來用Java構架系統的：

   （1）本系統可分為4層，分別是Browser、表示層、中間件層和數據層。

   （2）表示層用Java中的Java Script來實現頁面輸出。

   （3）中間件層用Java來實現CORBA，即實現Component（構件），主要實現業務邏輯的封裝與復用。

   （4）數據層主要是數據庫和存儲過程的實現。

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

    （1）使Java Script盡量簡單，因為Java Script在我們系統中是放在服務器端執行的，該語言是通過一個解釋器解釋執行的，相對速度很慢，我們采用了兩臺HP前置機來運行Java Script，但是其運行速度還是不理想，所以我們在設計中把Java Script僅用來顯示從中間件層所得到的數據，生成動態頁面。在最初的設計中表示層（Java Script）曾承擔了一些業務邏輯處理操作，導致效率不理想，因此，我們不得不盡量地減少Java Script的程序量。

   （2）用Java實現CORBA時，應盡量考慮共享和復用。在本系統中，最初的設計是讓 Java在實現Component時，只是執行一些數據庫表的操作，導致表示層的負載較大。后來，我們重新設計時，總結歸納了所有的Use Case，找出了其中可供共享和復用的接口，把相同的業務邏輯操作封裝到一個接口中去。因為 Java的執行效率比Java Script要高，因此提高了系統效率。

    （3）在別的項目中，我們曾大量地使用過Java中的JSP技術和Servlet技術，一般人可能不能區分這兩種Java技術的區別。為了得到系統的一些執行速率的數據，我們采用了一個著名的壓力測試軟件——Load Runner來測試這兩種技術的差別。測試表明：用JSP和Servlet完成同樣的一個操作，并且保證是在相同的測試環境中（相同服務器、壓力測試工作站與數據庫環境），得到的測試數據卻有著很大差別，JSP完成一個操作的平均執行時間大致會是Servlet程序的兩倍。在一個企業級應用項目中，這可能是一個很關鍵的瓶頸。因此，我們得出的結論是：在可能的條件下，盡量地多使用 Servlet。當然，與Servlet相比，JSP編程快速，修改方便，在訪問量不是很大的應用場合下也是可以接受的。

   （4）使用Java作為整體解決方案時，應盡量使用相同版本的JDK。在用Java作為編程語言的項目中，幾乎大多要遇到“漢字”問題，即Java在沒有經過轉換的情況下，在輸出漢字時，很可能會出現亂碼。采用不同版本的JDK，解決的方案是不一樣的，比如V1.2.2版本的JDK和V1.3版本的JDK解決方法就會有一些不一樣，把V1.2.2的Java程序放在V1.3的JDK中，就不能順利輸出漢字了。其根本原因在于Java使用了Unicode編碼，和我們中國的國標編碼不一樣。所以在這個意義上一些人竭力鼓吹的“一次編寫，到處運行”似乎不一定能在所有的場合都行得通。

   （5）使用 Java時，應盡量遵從軟件規范。在Java中有一個JVM的概念，即在Java虛擬機中使用了一個垃圾收集器，專門用來回收內存。但是該垃圾收集器在給編程人員帶來方便的同時，也隱埋下了隱患。在程序設計中，并不能強制執行垃圾收集器，所以，開發人員不能確定某對象是否已釋放，常常讓編程人員養成依賴自動收集的壞習慣，因此我們要求：在Try，Catch之后必須明確要求回收內存（當然，也只能是通知垃圾收集器來回收垃圾），這樣可以有效地提高系統穩定性。

    以上這些實用性的技術與策略，是我們在實踐中的一些實際體會，僅供各位開發人員根據實際情況參考。

    當然，在使用Java作為解決方案時，也會遇到很多讓我們頭疼的問題，這些問題導致同時執行的并發性比較差，系統速度慢等等。歸納起來看，我們曾遇到過的主要具體的問題有：

   （1）用Java來實現CORBA中的Component，有時效率會比較低。

   （2）用Java來建立數據庫連接往往會比較慢。

    （3）用JSP編程時容易導致系統信息的擴散。比如，如果有黑客攻擊一臺運行JSP程序的服務器，他可以故意地輸入一些非法字符或異常信息給JSP程序，于是程序執行將出現異常。這時，就會在頁面上打印出相應的錯誤信息。很不幸的是，這些信息極有可能暴露出這臺服務器的JDK的版本號與路徑信息等內容。這往往容易讓黑客們有機可乘，有可能去抓住系統的漏洞。

    在發現了這些問題后，我們經過仔細研究，找出了一些解決辦法。比如：

   （1）既然用Java實現Component比較慢，我們就盡量減少Component所執行的業務邏輯量。爭取把能夠放在存儲過程中實現的操作，盡可能在存儲過程中加以實現。眾所周知，數據庫的存儲過程操作，比起在Java程序中執行數據庫操作要快得多。

   （2）既然用Java建立數據庫連接比較慢，我們就可以把數據庫連接封裝成連接池（Connect Pool），從而能非常有效地提高系統效率。我們也曾經用“Load Runner”作過壓力測試，使用連接池比不使用連接池的速度要快上3～5倍。

    （3）為了對付JSP程序與Servlet程序會打印出異常系統信息的問題。我們曾查閱了很多JSP或Servlet的資料，最終是毫無頭緒。但是我們可以換另一種思路，即是不從程序下手，而從Web Server著手，我們可以把Apache配置成為使這類異常信息不再打印出來，而是使之僅出現一個通用的異常說明的頁面，這樣，就能十分有效地解決這個問題。

    在我們使用Java作為編程語言的這么多項目中，絕大多數是比較成功的。Java語言作為一種快捷、穩定的計算機語言，開發基于因特網應用的項目大多是相當穩定和比較適用的。

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

   （1）在因特網上將會有更加廣泛的應用。

   （2）在嵌入式設備中，Java也大有用武之地。比如，在最新推出的Java技術中，Java已經進入了手機領
域。

   （3）Java程序大多以線程運行，占用資源少，會逐步代替ASP與CGI程序。根據第三方測試表明：JSP程序比ASP程序要快2倍以上。用JSP代替ASP應是大勢所趨。

   （4）Java在無線互聯網中的應用將會更加廣泛。Java支持WAP，可以方便地用Java開發WAP程序，實現WAP應用。

   （5）Java與XML的無縫連接使Java在數據傳輸和異構網絡通信方面有著很大的優勢。

    就我個人而言，我將會在相當長一段時期內致力于Java在無線互聯中的應用，為我國的移動通信事業開發出更多的優秀實用的項目。
評注；參與了一個較大的項目后有實踐體會。全文都采用1、2、3、4方式，文章的風格顯得單調，不大吸引人。但是本文的優點是；（1）寫得很有條理。（2）內容的選擇合適。（3）所列舉的策略、注意事項與發現的問題都很現實可信。（本文主要參考了廣州王海波等人論文）

系分論文7

論Java技術在因特網平臺上的應用——論文3：銀行業的應用

【摘要】

    因特網上應用的日益普及與深化，為Java技術的運用提供了廣闊的活動舞臺，也大大推進了Browser/Server模式的企業內聯網應用與網絡計算。

    作為某信息公司中的技術骨干，我有幸承擔了某銀行信貸管理與查詢系統等的開發任務，獨立地完成了其中的系統設計、類設計、部分開發及測試工作。

     整個系統完全按照J2EE的標準來設計。前臺界面應用了JSP技術，控制部分采用了Servlet來開發，業務邏輯應用了EJB技術來封裝，應用服務器采用了支持J2EE標準的BEA公司的Weblogic，后臺的數據庫選用的是Informix7.3，目的是為了與銀行中其他業務系統數據庫保持一致。在硬件平臺上，我們選用的是HP公司的某臺中型服務器機器，操作系統是HP-UX。

    該系統界面運用的是IE，它不僅兼容性較好，而且已為廣大用戶所熟悉。系統運行后，各個支行都普遍反映界面友善，功能強大，開發的效果令人滿意。

【正文】

     在銀行應用中私人的儲蓄、企業的會計、國際的業務、信貸、財務管理都是十分重要的，它們構成銀行的基礎業務系統。我從事開發的信貸業務更是銀行利潤來源的重要部分。與儲蓄，對公等以交易事務為主的業務模式有所不同的是，盡管信貸也是交易，但需要更多其他輔助信息的支持。如客戶的基本資料，在本行內業務發生狀況、信用等級、是否有逾期貸款未能歸還等。各個支行的有關業務人員及分行管理人員都希望能方便及時地了解這些信息。傳統的基于終端的用戶界面難以傳遞這么多信息給用戶，所以我們決定采用基于測覽器IE的用戶界面，一方面IE使用方便，不需要專門培訓，另外它是與Windows操作系統捆綁在一起的，也可節省前臺費用。在開發技術上有ASP，JSP可供選擇。

    由于考慮到Java技術在Internet上的迅速發展，J2EE更是提出了全新的用語言來統一平臺的思路，于是我們決定采納J2EE標準，并選用了JSP。在設計上，基本上是采用了一個交易畫面對應于一個JSP程序，充分發揮JSP動態處理頁面的長處。

     為了使設計有更好的可擴性、靈活性與邏輯性，能為以后擴展奠定堅實的基礎，我采用了（Modelu，View，Controller）的MVC設計模式， View全部由JSP實現，而Controller則是設計了一個Servlet程序，它負責處理前臺瀏覽器傳送來的所有請求，并按事先定義好的路徑/程序關系，分發給相應的JSP程序去處理。由于Servlet本來就是為Java服務器端編程來設計的，因此由它來負責服務器端的處理是相當合適的。

     在開始設計時，我運用了構件技術，由EJB承擔起設計模式的Modelu角色。具體的貸款開戶，放款，結息逾期貸款，歸還貸款等交易都對應一個具體的 EJB。為了將這些處理邏輯與相應的數據庫操作分離開，能更加便于維護，我將處理業務的EJB設計成Session Bean，而為每個 Session Bean再配備一個相對應的Entity Bean，用于訪問后臺的數據庫。貸款管理中有很重要的一點是進行查詢，我按照需求分析的結果，為每類查詢都設計了相對應的Bean，其目標是盡可能地提高查詢的速度。

    在對數據庫的存取中，我本來的設計應用 Informix JDBC所帶的Driver Manager，這樣，在存取數據庫中的Bean中就要把Driver及Server寫入，后來考慮到應盡量提高應用的平臺獨立性，在參閱了J2EE中JDBC部分的說明后，改用了Data Resource的處理方法，這樣，即使以后數據庫換成 Oracle或其他產品，程序也不用修改，只需要在配置時進行變動即可。

    在這次信貸管理系統的開發過程中，Java的平臺無關性優勢，在開發人員從事開發的活動中體現得淋漓盡致。由于經費相對緊缺，我們的開發環境是各個項目組共用一臺HP機器，雖然每個開發小組都搭建了自己的環境，但項目一多，特別是遇上結息與批量測試等場合，機器就顯得不堪重負，使開發與測試工作的效率大為下降。我們小組由于采用的是Java技術，大家可以在自己的NT機器上搭建相同的環境。這樣一來，大家平時的開發工作，包括JSP，Servlet，EJB的程序，都可以在本地完成，只是到測試或展現階段才需放到HP開發機器上進行。

    以前我們開發的Web應用，往往只是應用了部分的Web技術，如采用 Apache Web Server、ASP開發語言等。整個體系的集成與組合往往不夠理想，這次由于我們采用的一整套符合J2EE標準的組件，整個系統的協同性與一致性非常之好。再加上有一個支持J2EE的應用服務器——BEA Weblogic，以往我們做得不理想的復雜配置，模塊間的連結，如今都用不到再操心了，只需在圖形化的配置工具中，輸入系統所需要的配置，如路徑與實際應用程序的關系，組件中的EJB引用，Data Resource的屬性等；全部配置完成后，Weblogic會替我們完成項目的部署，并將這一切有關的程序都封裝起來。

    原來，我們開發小組的文檔編制任務顯得非常之繁重，因為整個系統既有交易部分，又有管理查詢部分，交易、數據與源程序都很多。為了解決這個問題，我們直接應用了Java源程序中的 Javadoc導出文檔，這樣不僅文檔美觀，而且能夠保持與源程序的一致性，實乃一石二鳥之舉。

    整個項目完成后，用戶使用下來都覺得界面友好，操作簡便。但是我心里知道．這個系統還有很多可以加以改進的地方。

     首先，基于Java系統的開發需要資金較多的投入，由于該系統受到經費的限制，只申請到一臺生產用機，這樣，Web Server、 Application Server、DB Server只能被擠放在一起。雖然Weblogic能實現部分負載平衡，但在將來的業務發展時，這樣的分布肯定不是最理想的。好在我們在設計時已經考慮過盡量有良好的擴展性，在以后條件許可時，只需進行在不同機器之間的進一步部署即可，應用程序大體上無需改動。

    其次，在設計上，可以采用UML的產品，如Rational Rose，另一方面，Rational Rose具有自動代碼生成功能，也可以大大節省開發的成本。

    最后，目前的信貸管理系統相對用戶數目量不多，當推廣類似系統需要擁有大批用戶時，基于Java的系統的響應時間與系統分布都會有較為突出的矛盾出現。

    以上這些，都是我在今后的系統設計與開發中需要加以注意的地方，也是運用Java技術應當努力的方向。（本文主要參考了上海戴黎平等人的論文）
評注：討論具體，應用較為深入，表達清晰。存在的問題屬實。

系分論文8

論改進Web服務器性能的有關技術——論文1：銀行業的應用

【摘要】

    基于Web技術的數據庫應用是當前應用的一個熱點，在用戶數目與通信負荷很大的場合，提高Web服務器性能是一個迫切的課題。本文從筆者參與某個銀行系統項目開發的經歷出發，闡述了提高Web服務器的性能應滲入到項目論證、選型、開發、運行和管理的各個環節，只有各個環節都能充分考慮到性能與質量的需要，系統的性能才是真正可保證的和可擴充的。

    文章從系統的實際運行與相應的經驗出發，闡述了性能改進方面的一些具體措施。
比如：在本文中討論了Web服務器平臺的選型考慮；Web服務器的配置管理；應用系統本身的優化與預先設計系統時可擴性的性能保障等具體內容。

    通過技術上的分析與改進，綜合性地運用多類措施與手段，在實際系統中，Web服務器運行的性能得到了一定程度的保證。

【正文】

    我所在的單位是把目標定位于金融領域開發IT應用的一家信息技術公司。隨著金融電子化建設的發展和商業銀行之間市場競爭的加劇，各主要商業銀行不斷通過信息技術提供新的金融產品，并且希望能整合市場渠道。比如主要的商業銀行不斷推出形形色色的網上銀行服務。在這種背景下，本人參與了開發新一代網上銀行產品，涉及到提供網上個人理財服務、網上外匯買賣服務、網上企業服務等具有市場競爭力的產品。作為項目開發的組織者之一和主要的技術骨干，在整個項目開發過程中始終要處于第一線，從而在改進Web服務器性能、提高整個網上平臺系統性能方面收獲良多，在本文中簡要討論如下，希望與讀者們共享經驗。在Web服務器配置與優化方面，我有如下幾方面主要的體會：

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

    在Web服務器選型及網上平臺搭建之初，我們就已充分考慮整個網上平臺的性能及可擴展性問題。這一考慮為該系統的穩定性及擴展性能力方面打下了堅實的基礎。

    某銀行原有的一些網上產品由于開發較早，故而采用的是老式的HTTP Server+CGI程序調用的方式。這時，每一客戶請求需要對應于后端系統的系統進程來運行CGI程序來處理，系統的開銷相當大，系統的擴展能力也很差，性能已不能滿足業務處理的需要，故而在為此銀行系統具體選型的時候，我們一開始就否決了這種方案。

    通過市場上同類產品的比較選擇，我們選擇了國際商業機器有限公司IBM的Web Sphere產品系列作為該行網上銀行系統的建立平臺。作出這樣選擇是因為Web Sphere基于使HTTP Server和應用服務器相分離的整體架構，同時支持JSP、Servlet和企業組Java Bean等輕量級線程規范，所有的請求對應于應用服務器上的處理線程，系統的開銷低、效率非常高，同時Web Sphere整個體系結構相當的靈活，為適應擴展需要可以作不同的橫向和縱向擴展，從而可以滿足各銀行未來的擴展需要。

    正是因為在一開始選型的時候我們就已考慮到未來的擴展需要，整個系統在接下來的幾次性能改進方面，我們大體上都能相對順利地達到了預期目標。

    第二方面是Web服務器的性能配置。

    在一開始系統上線的時候，由于系統的負荷不是很大，為了節省系統總擁有成本TCO投資，我們在一臺較低配置的IBM RS6000上投產了該系統。整個系統的HTTP服務器、應用服務器、通信服務器等均位于該臺機器上，由于初始投產時用戶不多，所以系統的性能基本上能令人接受。

    但隨著業務的發展和用戶訪問量的增大，我們發現該服務器的響應變慢，系統的CPU利用率和內外存交換顯著增大。經過跟蹤，我們發現關鍵原因之一是系統的內存不足的緣故。由于網上服務器把大量用戶的會話信息保存在內存中供給應用系統使用，當內存不足時，大量Session信息被迫交換至硬盤，大量CPU時間消耗在等候內外存的交換上，系統效率迅速下降。

    鑒于這種情況，我們把該服務器的內存由2GB擴充為4GB，同時相應調整用戶會話信息的保存時間，這樣整個系統的效率又回到較為理想的狀況。

    由于新應用的不斷投產及數據庫操作的日益增加，我們后來逐漸監控到系統的數據庫處于繁忙狀態，系統的錯誤日志也記錄下了供應用服務器使用的數據庫連接處出現資源不足的情況。在這種背景下，我們認為整個系統由于硬件配置所限，應該進行橫向擴展，因此我們把數據庫服務器分離出來，配置到另一較高性能的服務器上，相應定義的數據庫資源也大幅增加，這樣整個系統的性能又處于較為理想的狀況。

    第三方面是對應用系統進行相應的優化以提高性能。

    Web服務器配置及相應的硬件擴展不失為解決系統性能問題的一條捷徑，但應用系統的優化也是應該重點加以考慮的，畢竟它能夠在投入較少的情況下提高系統的運用效率。

    在開發的初期，我們就已經十分注意系統的利用效率，比如提醒程序員盡量不要利用用戶會話信息(Session）來傳遞大的對象，對于內存要注意回收等。同時，通過內部的交流會推廣與介紹一些小的、有用的編程技巧來提高開發人員的水平，通過代碼的抽查，希望能在早期就發現問題等。

    在系統運行期間，我們通過監控發現，應用服務器所基于的Java虛擬機，其內存堆的空閑空間有不斷下降的趨勢，每隔若干天導致空間消耗殆盡、無法分配新對象空間，從而導致系統重啟。在排除了系統本身問題的原因外，我們確定為應用系統的開發有問題。通過從網上萬載IBM公司檢測Java虛擬機的相關工具對 JVM進行監控后終于發現系統內部存在著不能回收內存的對象，再通過查找相應的程序發現在該程序中有“環狀”的對象引用，從而導致對象使用后不能被垃圾收集器所回收。這個問題的解決過程雖然十分艱苦，但由于該問題不能通過升級硬件或增加資源配置而得到根本解決，會給系統帶來很大的隱患。所以，整個過程的分析與解決是完全值得的，更何況通過查找故障原因的過程，給整個項目組上了生動的一堂軟件質量保證課，對項目組的質量意識起了很大的促進作用。

    所以說改進Web服務器的性能井不單純是系統管理方面的工作，它滲透到開發以及
系統運行等一系列環節中。

    第四方面預先考慮未來的擴展與性能需要。

    隨著系統的發展及成熟，考慮到用戶訪問量的不斷上升，為了預留系統的發展空間，我們最近又對整個系統作了一個系統性的升級。通過引入多臺HTTP服務器及應用服務器并行工作提高整個系統吞吐量及單點故障克服能力。由于在一開始選型的時候就已經充分考慮到動態負載均衡及橫向擴展方面的需要，這一項的升級無需對整個系統的體系結構作根本的變革，對應用程序來說，更是沒有造成任何影響。

    整個項目歷時近兩年，從這兩年的系統情況來看，整個系統是成功的。根據我親身的經歷，系統性能并不單純是系統運行與管理階段的問題，而是滲透在項目論證、開發以及運行的各個階段。只有在各個階段都能充分考慮性能方面的需要，在實際運行時，整個系統的性能才可能真正有保障。在技術方面來看，可以綜合利用選型評估、硬件擴展、應用優化和系統配置優化等一系列的手段；比如在硬件擴展方面，又可以分為主要部件擴容，縱向升級、橫向升級等方面。在我們的項目實踐中，曾綜合地利用了上述的各種手段。比如某銀行的整個系統從日訪問量不足1萬至現在的每日超過I0萬次以上的點擊的發展情況來看，整個系統的性能保障及提高方案是比較成功的。

    評注：實踐過程較有說服力。條理與思路相當清晰，技術措施與管理措施的推進也很明確。所論述的技術還有一些局限，不夠開闊。（本文主要參考了廣州黃昌湛等人的論文）

系分論文9

論改進Web服務器性能的有關技本——論文2：數字圖書館類的應用

【摘要】

    一個大中型的圖書館信息系統涉及到許多方面的技術與方案，本文著重討論與Web服務器性能有關的一些內容。

    本人有幸作為項目負責人之一參與了某大型圖書館數字化信息系統的設計和基于Web應用軟件的開發工作。由于在數字化圖書館信息系統中流通著的大多是數字化的索引、文摘、全文、圖像或音頻視頻等多媒體信息，對Web服務器性能有著較高的要求。

     結合實際工程的經驗，本文將從硬件實現手段（緩存服務器、均衡負載設備、Web雙機鏡像、CPU和網卡的提升、網絡帶寬擴充）和軟件實現手段（三層C/S 軟件結構設計、應用程序部署）等兩個大方面論述如何提高Web服務器的性能，以便使用戶能夠更快捷、高效、安全地使用應用系統。

【正文】

    隨著Intranet信息技術的發展，圖書館為了更好地發揮其圖書流通、資料檢索和學術交流的職能，圖書館的數字信息化工程也勢在必行。某圖書館為了盡快地步入世界先進圖書館的行列，已經啟動了一部分的數字圖書館工程。

     該數字圖書館工程主要包括對外信息Web發布系統，交互式檢索網、后臺館藏信息管理系統、多媒體資料采集制作以及VOD點播系統等。本人有幸作為項目負責人之一，參與了整個數字化信息系統的總體設計，并參與了基于Web的一些應用（如對外信息發布系統、圖像/全文混合檢索系統、VOD點播系統）的開發。

     某圖書館數字化信息系統從網絡環境上講，主要劃分為多個網段：（一）Intranet接入部分，采用2M的DDN專線；（二）公共網段（非軍事區），主要包括前臺發布數據庫服務器、Web服務器、E-Mail/FTP/DNS服務器、檢索服務器及SAN網絡區域存儲設備；（三）是內部局域網，包括內網 Web服務器、后臺館藏數據庫服務器、OA服務器等。（四）是VOD點播專用網，包括音頻視頻點播服務器等。由于制定了嚴格的網絡級和應用級訪問權限，通過具有三層交換能力的高性能交換機和安全授權認證系統等，有效地控制了防問權限，確保了數據的安全性和完整性。考慮到經費和人員素質及今后的維護管理運營等方面，操作系統采用Windows NT平臺，服務器選用DELL高端的系列，數據庫采用IBM的DB2。主干網為千兆快速交換式以太網，局域網百兆到桌面，VOD點播網十兆到桌面。

    在該網絡環境下應用主要分為三大部分：（一）對外Web發布系統、對外圖書輔助檢索系統；（二）后臺館藏信息管理系統和圖像/全文混合檢索系統；（三）VOD點播系統。由于絕大部分應用采用Browser/Server方式結構，最終用戶在本地只需安裝IE或者Netscape Web瀏覽器，在后臺數據庫服務器的支持下通過網頁方式請求和訪問各類應用服務。另外，由于在圖書館信息系統中流通的多為索引、摘要、全文或音頻視頻等多媒體信息，對Web服務器性能與網絡帶寬等都有更高的要求。

    通過不斷地試驗和實踐，我們發現從以下幾個方面可以相對有效地提升Web服務器性能；

   （1）緩存服務器和均衡負載設備使用可以緩解訪問瓶頸，提高網絡帶寬、實現均衡負載。

     緩存服務器也稱為cache服務器，可以存儲cache靜態的內容如網頁、多媒體點播資源和會議實況（已壓縮的、有一定格式要求的）等。此外，目前美國 cashflow緩存服務器，已經可以存儲cache數據庫、ASP等動態內容。cache服務器通常放到防火墻之外，外網Web服務器之前，因此 Internet用戶點擊網頁不再直接訪問網站Web服務器，而是訪問cache服務器。

    由于cache服務器具有多個CPU和高速大容量I/O通道，獨立的OS，因此能大大緩解Internet訪問瓶頸，而且也具有一定的抗黑客攻擊的能力。

    目前某圖書館采用這種方式，把大數據量的靜態圖片、點播資源、虛擬三維應用等都事先置放在cache服務器中，即使現今只有2M Internet的接入帶寬，以上應用的播放速度和效果仍能讓用戶滿意。

     另外一種方式采用均衡負載設備或Web雙機鏡像。這種方式通過負載均衡的方法達到 Web訪問性能最優。Web雙機鏡像是較早以前流行的方式，雖能使系統可靠性提升，但由于雙機總是在互相詢問對方狀態，將會影響一定的訪問性能。均衡負載設備是獨立于Web服務器的硬件，它和Web服務器及網站中其他服務器接在同一交換機上，通過負載調度程序為各個服務器分配工作量，從而，能達到充分利用資源，提高訪問性能的目的。只是由于某圖書館目前對外發布資源相對仍較少，只采用了三臺Web服務器，因此目前的均衡負載設備作用還不顯著。

   （2）從Web服務器的配置來看Web服務器自身CPU個數及速度、網卡數量、Web服務器與防火墻的位置關系等，都會影響到Web服務器的性能。

     從Web服務器硬件本身來講，CPU個數的增加、網卡個數的增加、I/O信道的擴展無疑可以直接地提高Web服務器性能。此外，由于千兆口的防火墻目前較少且費用較高，如果把Web服務器放置防火墻之后，一定會大大影響Internet訪問性能。某圖書館采用IDS（入侵偵測）+Web服務器（服務器防火墻，較低端，不會影響流量）+應用服務器+數據庫服務器（防火墻，高端），分層次的安全模式，既保證了系統的安全性，又提升了
網絡訪問性能。

    另外，某圖書館還采用了SAN網絡區域存儲來提高服務器訪問速度。

   （3）三層C/S軟件結構設計和應用程序的適當部署也會提高Web服務器的性能。

    將業務邏輯、通用訪問接口與數據等相互分離、分別置放于Web服務器、應用服務器、數據庫服務器上，通過程序功能和邏輯的合理部署，也能大大改進Web服務器性能。

     一般的原則是，Web服務器只需接受Internet http訪問請求，使Web只有最少的任務，把實際處理交給各個應用服務器處理，然后返回結果給 Browser。某圖書館采用這種方式專門開發了搜索引擎應用服務器和混合檢索應用服務器等，達到了良好的應用效果。

    事實上，Web服務器的性能提升還存在很多手段和方法，比如CPU與存儲之間關系，Web交換機等等，有待于我們進一步的實踐、分析和討論。（本文主要參考了上海童茵等人的論文）
評注：主題鮮明，條理也較分明。但所討論的技術應更有機地結合于項目的實例。

系分論文10

論實時控制系統與企業信息系統的集成——論文1：通信業應用

【摘要】

    近年來，在應用需求的強大驅動下，我國通信業有了長足的進步。現有通信行業中的許多企業單位，如電信公司或移動集團，其信息系統的主要特征之一是對線路的實時監控要求很高，數據量龐大，如何將實時控制與信息系統集成在一起便成為系統實施的一個關鍵部分。

     在參與了某個通信公司的一套網管系統以及決策支持系統的設計后，我們分析了兩者的集成與應用工作，深切地感受到有一個良好的設計策略以及重視所選用的工具是一個關鍵。這個項目主要是對下屬各分站的子網以及有關鏈路的連通情況進行實時監控、實現報警、路由控制和授權等功能，其關鍵在于提供一個實時顯示情況的地圖界面，井將數據匯總和組織，建立起數據倉庫以及進一步實施數據挖掘分析，從而能支持企業的決策分析。我作為設計人員之一，著重在本文中討論控制系統與信息系統集成時的策略。

【正文】

    眾所周知，通信行業需要有一整套監控通信網絡的手段，其工作特點是涉及到的各分站與基站的在地理位置L的分布性，更加需要有在更高一級提供檢測不同分站鏈接情況的手段。一般來講，由于數據都是海量的，所以，如何將整個網絡系統所得的數據及時處理，以便和決策部門的分析相結合，也成為迫切需要解決的重要課題。簡言之，分布性、實時性以及數據海量性是解決整個系統設計和集成的核心問題。

    首先，讓我們來討論一下“網管監控系統”。由于我參與設計與開發的這個系統并不是位于基層的分站，其定位在將下屬各分站的主機通信數據（包括數據流量、鏈路負荷、通往其他結點即主機的連通情況等）加以收集，所以對于具體通信事務的底層操作要求并不很高。

     考慮到上述原因，我們采用了一個地理信息系統開發平臺Mapinfo并采用Delphi編程，后臺用SQL Server數據庫（這是由于考慮到決策所需要用到的是Microsoft公司的OLAP Service）。在分析和計劃之前，我們先對ITU801標準做了詳細的探討，這只是一個有關子網和鏈路定義以及分層等描述的標準，在聽取了許多分站人員的建議后，將MAPINFO公司提供的一個相關的MAP X的Active X控件嵌入到Delphi程序中，利用MAP X中提供的豐富的類以及操作，比如Object、Layer等實現網管界面，井且加入了子網和鏈路的概念，對屬下的分站可以隨意地組合成為不同子網，而且實現了放大與縮小的功能，大致可以將整個地區的分站集中在一張地圖中，能顯示在屏幕上，這時，只是顯示出各個分站的概要，小到可以顯示出某臺主機的機柜、機柜直到插件板（因為這些都要實時監控）。我們采用了分層的方法來實現以上縮放。對于一些靜態的數據，如分站，主機的位置等則先用 Mapinfo公司提供的一套編制地理信息的工具（MAP X是其提供給編程工具的一個Active X控件）做成靜態的層次圖放置于數據庫中。

    我們新做成的這套系統通過與各分站的專用線路加以連接，能實時地得到數據，顯示于地圖上，反映出各站、各子網、各鏈路的實時狀態，并能將控制命令傳回分站（如強制鏈路中斷、路由轉換等）。

    現在，讓我們來討論其中最為關鍵的問題，即是要將實時控制系統與企業信息系統加以集成，我們的設想和體系結構大體上可以用一張簡圖表示（此處暫略）。

     在這個體系結構中，由各分站保留著詳細的數據，網管系統則在一定時間間隔內將匯總到的數據作少量統計，抽取其中需要保存的內容放入數據庫，如每分鐘流量，某分站與其他分站每分鐘通信流量，在該分站中某個鏈路的負荷（這些鏈路有可能是動態分配的，也可能是固定分站之間的通信鏈路）。盡管如此，數據仍然是海量的，因此，如果要把這些數據都直接送到各個決策部門，比如送給市場部門是不現實的。所以，我們在數據庫的基礎上建立了數據倉庫，確定了客戶、時間、通信量、計費和故障等幾個數據倉庫的主題，每隔一定時間對數據庫中的原始數據進行清理與抽取等預處理工作，建立好數據倉庫。這里的預處理包括了許多方面的內容，比如有建立計算時間，但是無計費的（計費值為零）的數據，應視為建立失敗的無效數據，需要予以剔除；某些企業租用的是專用線路按月計費，中間的通信因此無計費的一些有關記錄也應剔除等。

    在預處理之后，再利用OLAP Service的分析將數據融合與匯總。按照決策部門的需要提供相應數據（比如：市場部門需要每一分站的收益，客戶分布情況以及客戶費用等）。這些都可以由OLAP Service對數據作預先處理，此時處理完的數據在邏輯上是以立方體（CUBE）形式存在的，其占用的存儲空間便能顯著地降低，如1999年8月有2000萬條通訊記錄，即使形成作為備份的文本都需要4G空間，經過OLAP Service處理后僅需200M左右空間，因此，經處理后的數據主要存放于另外的相關部門的機器中，而不能與主服務器放在一起。

    最后，再來討論由決策人員所使用的系統。由于這些部門并不分散，我們就沒有采用OLAP Servce的Web發布方案。采用Delphi編制了訪問OLAP Service的客戶端軟件，用了OLAP Service提供的、Cube Browser控件，用相似于網頁的界面提供了數據立方體的各種操作，如上鉆（觀察角度從月轉到季度甚至年），切片，旋轉等操作。為了便于輸出打印數據，還內嵌了Microsoft的 Excel數據透視表，可以將在Cube Browser上所看到的數據轉化為Excel的表格形式，或者轉換成餅形圖、柱形圖和曲線圖等，比如可以觀察每天24小時通信流量的分布曲線圖，可以發現在夜間12點以后明顯通信流量減少，而決策部門便可制定某些優惠或減價措施吸引更多客戶在12點之后使用網絡。

    另外，在采用OLAP Service中的數據挖掘功能時，其中提供的兩類算法分別是基于決策樹的分類和基于決策樹的聚類，市場部門的聚類算法將客戶根據費用情況加以聚集，以期發現處于同一消費水平的客戶的共同特征，便于制定政策，吸引客戶。這方面的努力我們將會進一步持續進行，以保證有足夠的海量數據而發現其中的規律。

    整個系統運行后，其數據采集，數據處理等一系列工作都由程序定期地自動進行，該系統應用已有一段時間，受到了不少好評。當然，也發現了其中有不少問題，比如；主服務器數據庫的容量問題，主站與分站的通信效率問題，還有在網管系統中，網絡故障的確定還不夠細致，需要由分站再具體化加以確定，決策系統與網管系統之間還缺少直接通信手段等，這些都有待于進一步的解決與改進。

     實時控制系統與企業信息系統集成化是推動從事生產制造、測量與監控等業務的企事業單位真正邁向信息化，提高工作效率的一個重要動力。如果是大型企業，更需要有一整套的系統，支持Web發布，智能查詢，自動識別如用于故障預測和數據挖掘等技術，從而能夠將底層的實時監控與高層的決策更好地集成在一起。展望其前景，無疑是十分美好的，但是我們認為相應的工作量很大，在技術上仍然需要有所提高和有所突破。

評注：能緊扣集成的主題，結合實際作了較有深度的論述。所討論的數據庫和數據倉庫技術符合企業信息化的方向。對遇到的問題的舉例剖析還不夠，實時控制方面的論述也可更細化一些說明。（本文主要參考了廣東林嘉宜等人的論文）

系分論文11

論實時控制系統與企業信息系統的集成——論文2：工業自動化改造的應用

【摘要】

     本文以一個信息化改造項目為例討論了實時系統與信息系統的集成。我曾參加了一個中等規模的現代化生產企業的數字化改造項目，該企業擁有4座自動化連續式工作的窯爐，以及8座自動化間隙式工作的窯爐以及多臺半自動的中大型輔助機器。該企業希望能將這些設備實現數字化，并且重點要建立起一個中央監控室，能實現對設備的運行狀態參數的監督和記錄兩大任務，前者用于防止意外事故，后者可用于向該企業的決策人員和技術開發部門提供信息。

    通過我們的開發組與該企業相關人員一起努力，分四個步驟共同完成了這一工作。第一步是實現設備狀態參數的數字化輸出；第二步是建立中央監控室的監督和記錄功能；第三步健全監控室的控制功能及相應信號的輸出；第四步則是實現生產設備自動化控制的數字信號接入功能。

    我在其中的主要工作有三個方面：

   （1）作為公司開發組和企業間聯絡的橋梁；

   （2）負責確定該項目中各部分之間的分工，在發生沖突或出現問題時提出相應的具體解決辦法；

   （3）幫助解決與協調在工作過程中出現的各種困難。

【正文】

     現代化企業發展生產與提高效率的根本途徑之一是加速信息化的進程。在所從事的專業生產領域中，我參與開發項目的這家企業可以認為已經具有相當程度的現代化的基礎了，比如它已擁有4條自動化連續式工作的窯爐、8座自動化間隙式工作的窯爐和多臺半自動的中大型輔助機器。但是這些設備的自動化控制在改造前還主要依靠模擬量控制，也不具備信息與數據的記錄、匯總與分析功能。該企業一方面出于對今后發展的需要，希望記錄下這些設備在工作過程中連續的狀態參數的變化情況，有運行的日志與歷史記錄，以提供給其技術開發部門，作為產品質量改進研究中的參考；進一步還可提供給企業管理部門決策分析時的參考。另一方面，企業希望能夠對設備生產狀態有全面的監督和一定的緊急控制與應變的能力，能對生產設備的操作意外和設定不當，或者發生突然的未預料到的事件，防止造成事故與損失。

    我們根據該企業的要求，結合項目的資金、時間、人員等現實狀況，再三考慮了該企業的經營情況、產品的市場和前景、項目開發所面臨的風險等諸多因素，經過仔細分析，得出了如下的4條意見：

   （l）由于資金的限制，切實地在相應各個環節上節約成本是相當重要的，因此要盡可能地在原有設施與條件的基礎上進行改造，而不是進行根本性的替換；

    （2）此企業需要的是“實時控制系統和企業信息系統的初步集成”，而不是一個功能相當豐富和完善的系統，該企業現階段既不具備開發這樣一個系統的能力和條件，也不具備管理維護和應用高級集成系統的相關人員，所以，項目的目標應當切合于目前條件下企業的總體要求。這樣既有利于控制成本，也有利于減少項目風險；

   （3）由于該企業的生產情況和資金、人員的限制，項目必須分階段地進行。大體上可劃分為如下四個階段：①實現設備狀態參數的數字化輸出；②建立中央監控室的監督和記錄功能；③健全中央監控的控制功能和相應信號的輸出；④實現生產設備自動化控制的數字信號接入功能；

   （4）參與本項目涉及到的雙方的大多數人員都不精通對方的專業領域，因此必須在加強互相溝通的同時，確定明確的分工關系。

    上述四條意見在經過雙方的磋商與研究后，獲得了雙方全體項目參與人員的一致認同，成為這個項目開發過程中雙方必須理解與遵循的準則。

     在第一階段，我們開展了對半自動的中大型輔助機器的自動化改造。事實上，該企業早有這類打算，并且已做了相應的技術儲備，因而這一部分的工作由該企業自身的技術人員全權負責并加以實施。項目中所涉及到的所有自動化生產設備都已具有依據狀態參數模擬信號量進行控制的能力，對于所采集到的狀態參數模擬量，企業曾計劃采用一類以模擬信號遠程地傳至中央監控室，再進行模數轉換的方案。此方案對企業來說實現比較簡單，但存在著成本較高、遠傳過程易受到干擾等不利因素。隨著模數轉換設備成本的顯著下降和可靠性提高，經我們建議和雙方討論，企業有決心在生產設備的控制設備上就地實現現場模數轉換，再遠傳數字信號至監控室，這一工作同樣地由熟悉這項技術的企業技術人員實行。

    第二階段的工作主要由我方開發組成員負責。我們將人員大體上分為3組，第一組主要是根據企業長期累積的資料以及公開發表的相關技術，建立起一個合理有效的模型，其中包括諸如數據采樣記錄的間隔時間，不同生產階段的數據處理時所采用的數學模型等數據處理的相關內容；第二組負責監控記錄軟件的輸入輸出接口，用戶圖形界面的選定和設計等軟件外圍功能的實現；第三組則集中力量編寫一個簡單實用的、針對性強和小巧的相關數據記錄的專用數據庫。這一階段是控制質量和成本的關鍵性階段。出于對成本的考慮，以及根據數據的流量不很大，對數據的實時性處理要求不是很高（通常情況下，設備的實時控制仍由原來的自動化系統所承擔）的實際情況，中央監控室采用了一套有雙機備份的服務器作為數據處理用的服務器，另一套同樣有雙機備份的服務器作為數據庫服務器，并且沒有使用價格昂貴的商用數據庫，而采用了由自己開發的一個經濟實用的專用數據庫。

     第三階段可以看成是第二階段的自然延伸，在第二階段成功的基礎上，利用第二階段模塊處理后所獲得的數據，依據設備的多種臨界指標，進行相應的判斷，允許在緊急情況下，發出相應的警報，并同時依據設備本身的相應緊急情況處理辦法，發出控制信號加以處理實現。這一階段的關鍵有兩方面內容：一個問題是要求數據轉換設備擁有相對較高的可靠性與可用性，另一個問題是要注意做好與自動化設備原有控制系統的自我保護功能的配合協調工作。

    第四階段則仍然由該企業的技術人員為主實施，在實現過程中主要是解決好第三階段所遇到的上述兩個關鍵問題。對于第一個問題，使用了更好的設備和部件來實現數模轉換和動態控制；對于第二個問題，則在控制設備中設立了優先級判斷，使自我保護裝置的啟動優先級離開中央監控室（由于自我保護啟動速度更快，但是功能較弱）而加以解決。

    從總的項目實施進程上來看，一、四兩個階段相連貫，二、三兩個階段相連貫，而它們之間則可并行地進行，從而滿足了時間進度上的要求。

    今后，本項目所采用的這類技術可能要走向全自動化。項目中涉及到的數據量將會更大得多，實時性要求也會更高。我們應注意使現有成熟的商業系統與產品如何應用到其中去，使之能盡快地滿足企業的要求，節約成本，并且減少開發的風險。
評注：本項目初步實現了生產控制與信息系統的第一階段集成，項目實現目標明確，效果直接。摘要中寫了項目的背景與作者所從事的工作，正文中條理較清晰地列舉了項目實施的策略、過程與主要技術。（本文主要參考了上海沈子敬等人的論文）

系分論文12

論實時控制系統與企業信息系統的集成——論文3：工業控制的常規應用

【摘要】

    本文通過“工控組態軟件”項目的開發，著重討論實時系統與信息系統的集成。近年來，國內外的組態軟件取得了很大的發展，已廣泛應用于企業生產。組態軟件以實時數據庫作為核心技術，綜合了工控、網絡、圖形處理與數據庫訪問接口等技術，是技術含量較高的一類軟件產品，具有良好的應用前景和市場潛力，因此，有多家信息技術公司都在開發工業組態軟件。

    我有幸參與了該項目，在該項目中擔當了分析與設計的部分任務，該軟件采用Windows 2000操作系統，主要采用VC6.0進行開發。以下本文將從我所開發的組態軟件的特征、軟件的體系結構設計、實時數據庫設計、可擴充性與可維護性設計以及項目實施管理等幾方面加以論述。

【正文】

    工業控制組態軟件在工業界有著相當廣泛的應用，此類軟件允許用戶在圖形界面下對控制系統的各種采樣點、過程輸出點、設備、生產車間、控制回路、文件報警、生產報表、控制策略、網絡設備和生產工藝畫面進行定義與組態。使用該類軟件時，用戶甚至可以不寫一行程序就能夠構成自己的控制系統，有些功能強大的組態軟件還可提供與網絡、Internet、數據庫訪問接口等的連接功能，使現場控制系統能相對方便地和企業的信息管理系統加以集成，某信息技術公司決定開發新的具有一定通用性的工業組態軟件，作為技術骨干，我在該項目中擔當了分析與設計的部分任務，該軟件采用了Windows 2000操作系統，主要采用VC6.0進行開發。

    本文將從我們所開發的組態軟件的基本特征、軟件的體系結構設計、實時數據庫設計、可擴充性與可維護性設計以及項目實施管理等幾方面加以論述。

    l. 我所從事開發的組態軟件的基本特征

    通過分析國內外的組態軟件的特點和當前的技術發展情況，我認為我們著手開發的組態軟件應當突出下述三個特征：

    （1）“實時與可靠”是此類軟件賴以生存的應用前提，但是目前還是有很多的組態軟件做不到這一點。

    （2）具備良好的網絡連網能力與分布功能。

    （3）有效地采用ODBC（開放的數據庫連接），便于和其他信息系統集成。

    這個項目在技術上，應著重于組態軟件的體系結構設計與實時數據庫的設計上需求分析則應著重分析國內外同類軟件的功能，通過比較與鑒別，才能產生真正優秀的軟件。

    2. 組態軟件的系統體系結構

    本軟件采用的是三層體系結構，設計結構時要具有開放性和良好的可擴充性。

    （1）軟件的底層是硬件訪問控制層。這一層所采用的是前幾年才推出來的OPC（OLE for Process Control）技術，采用該技術的好處是OPC是微軟參與制定的標準接口技術，有眾多的硬件廠商支持，所采用的OLE技術使軟件具有良好的適應性和擴展能力。

    （2）中間層是實時數據庫。該層是整個系統的核心，在設計上除了具有一般實時數據庫具有的特性之外，應當為應用層提供了兩類接口：一是應用編程接口API（比如以DLL的方式實現），二是ODBC接口，該接口使系統具有很好的開放性，便于系統集成。

    （3）上層是應用程序層。在該層通過ODBC接口訪問實時數據庫，可以通過SQL語句查詢數據庫的數據。

    3、本項目涉及到實時數據庫設計

    在設計時，我們著重考慮了以下的四個方面：

    （1）實時數據庫的基本功能：實時數據庫完成實時數據庫的采集、輸出、報警文件等的管理，也進行歷史數據的管理。

    （2）實時性設計：由于本系統所采用的操作系統是Windows 2000．它的實時性較差，因此要求任務管理定時器必須具有良好的實時性，在系統設計時，我們采用了搶占式服務的高精度定時器，在一定程度上保證了系統具有良好的實時性。

    （3）任務調度：其目標主要是使系統在各時間段達到較理想的負荷任務的均衡性。

    （4）ODBC接口設計：即開發相應的驅動程序，實現ODBC功能，使之完全遵守SQL約定，這樣能允許應用程序的開發手段和開發工具多樣化，允許可以采用VC、VB或Delphi等作為開發語言，也使數據庫具有很好的開放性。但SQL語句不能實現數據發生時間方面的選擇，影響了實時性，因此，系統自動給每個數據庫加上時戳，SQL可以通過時戳進行時間控制來選擇（讀取）數據，從而滿足了實時性方面的基本要求。

    4. 本系統的可擴充性與可維護性設計

    組態軟件綜合了多種技術，其體系結構與數據結構都較為復雜，再加上我們又希望能適應的實際應用場景有著復雜多變性，因此要求系統必須具有良好的可擴展性與對維護性，以滿足功能與性能上不斷變化的要求。在系統的設計技術上，我們大量地采用組件技術，如OPC，COM/DCOM與3D圖形控件等，組件技術的采用使系統具有了良好的可擴展性與可維護性，降低了系統的復雜度。而且也使我們較方便地獲得第三方支持，例如，請經驗豐富的圖形處理專家編寫圖形處理控件，就能加快軟件開發的進度。

    5. 本項目中軟件項目實施和管理

    組態軟件的需求在當前工業控制領域中是較成熟的，基本能滿足一般用戶的功能上需求，通過比較多家組態軟件，可以發現：在它們之間有80％的功能是相同的或雷同的，由于我們項目開發的起步較晚，在自控領域里，我們處于劣勢，因此我們提出了“重技術分析，輕需求分析”的思路，即把重點放在組件設計與體系結構的實現上。

    在人員的配備上則根據組態軟件的技術組成特點，組織一批在自控、網絡、組件、實時系統設計和硬件上各有所長的VC高手組成一支精干高效的隊伍。

    在開發進度上則反復強調“質量第一，進度第二”的原則。

    在我們的項目實施中，可靠性作為設計的首要原則，要求項目組成員養成良好的編程習慣，每天必須完成認真的工作日志，每周要寫工作總結，完成一段程序代碼之后，即應自己先進行從里到外的測試，只有從基礎抓起，才能保證組態軟件的質量。

    通過本項目的開發成功，我深切地體會到要使組態軟件在企業實時控制與信息系統集成中發揮其應有的作用，必須注意以下各點：先進的體系結構；支持ODBC的實時數據庫；強大的網絡功能；功能日益強大的腳本語言等。我期待著本人通過在這個領域中的辛勤耕耘，將會結出更多更豐碩的IT成果。

評注：

    本文抓住了企業實時控制與信息系統集成中的一類關鍵軟件——組態軟件項目的開發，進行了較有條理的討論，思路很清晰。

    由于項目在一定程度上的“通用性”，未能結合具體的應用背景論述；但本文的一個缺點是未能給出開發與應用的實際效果例子，也未能對開發中遇到的困難與問題展開深入的探討。（本文主要參考了廣東王啟飄等人的論文）