軟件技術(shù)部分方案

1、技術(shù)服務(wù)在軟件開發(fā)的過程中，我們一向遵循軟件產(chǎn)品的以下原則：1、功能性：與一組功能及其指定的性質(zhì)有關(guān)的一組屬性具體包括：適應(yīng)性：與規(guī)定任務(wù)能否提供一組功能以及這組功能的適合程度有關(guān)的軟件屬性性準(zhǔn)確性：與能否得到正確或相符的結(jié)果或效果有關(guān)的軟件屬性互用性：與同其他指定系統(tǒng)遠(yuǎn)行交互的能力有關(guān)的軟件屬性依從性：使軟件遵循有關(guān)標(biāo)準(zhǔn)，約定，法規(guī)及類似規(guī)定的軟件屬性安全性：與防止對(duì)程序及數(shù)據(jù)的非授權(quán)的故意或意外訪問的能力有關(guān)的軟件屬性2、可靠性：與在規(guī)定的一段時(shí)間和條件下，軟件維持性能水平的能力有關(guān)的一組屬性成熟性：與由軟件故障引起失效的頻度有關(guān)的軟件屬性容錯(cuò)性：與在軟件故障或違反指定接口的情況下，維持規(guī)

2、定的性能水平的能力有關(guān)的 軟件屬性易恢復(fù)性：與在失效發(fā)生后，重建其性能水平并恢復(fù)直接受影響數(shù)據(jù)的能力以及為達(dá) 此目的所需的時(shí)間和能力有關(guān)的軟件屬性3、易用性：與一組規(guī)定或潛在的用戶為使用軟件所需作的努力和對(duì)這樣的使用所作的 評(píng)價(jià)有關(guān)的一組屬性，具體包括：易理解性：與用戶為認(rèn)識(shí)邏輔概念及其應(yīng)用范圍所花的努力有關(guān)的軟件屬性易學(xué)性：與用戶為學(xué)習(xí)軟件應(yīng)用所花的努力有關(guān)的軟件屬性易學(xué)操作性：與用戶為操作和運(yùn)行控制所花的努力有關(guān)的軟件屬性4、效率：與在規(guī)定的條件下，軟件的性能水平與所使用資源量之間關(guān)系有關(guān)的一組屬性包括：時(shí)間特性：與軟件執(zhí)行其功能時(shí)響應(yīng)和處理時(shí)間以及吞吐量有關(guān)的軟件屬性資源特性：與在軟件執(zhí)

3、行其功能時(shí)所使用的資源數(shù)量及其使用時(shí)間有關(guān)的軟件屬性5、可維護(hù)性：與進(jìn)行指定的修改所需的努力有關(guān)的一組屬性具體包括：易分析性：與為診斷缺陷或失效原因及為判定待修改的部分所需努力有關(guān)的軟件屬性易改變性：與進(jìn)行修改，排除格誤或應(yīng)環(huán)境變化所需努力有關(guān)的軟件屬性穩(wěn)定性：與修改所造成的未來預(yù)料結(jié)果的風(fēng)險(xiǎn)有關(guān)的軟件屬性 易測(cè)試行：與確認(rèn)已修改軟件所需的努力有關(guān)的軟件屬性6、可移植性：與軟件可從某一環(huán)境的能力有關(guān)的一組屬性，具體包括:適應(yīng)性：與軟件無需采用有別于為該軟件在準(zhǔn)備的活動(dòng)或手段就可能適應(yīng)不同的規(guī)定 的環(huán)境有關(guān)的軟件屬性 易安裝性：與在指定環(huán)境下安裝軟件所需努力離關(guān)的軟件屬性遵循性：使軟件遵循與可移

4、植性有關(guān)的標(biāo)準(zhǔn)或約定的軟件屬性易替換性與軟件在該軟件環(huán)境中用來替代指定的其他軟件的機(jī)會(huì)和努力有關(guān)的軟件屬 性基于以上原則，根據(jù)項(xiàng)目的不同需求，我們將會(huì)考慮采用B/S和C/S兩種模式開發(fā)I、B/S 模式B/S是Brower/Server的縮寫，客戶機(jī)上只要安裝甲個(gè)瀏覽器（Browser ）,如NetscapeNavigator 或 Internet Explorer , 服務(wù)器安裝 Oracle 、 Sybase , Informix 或 SQL Server等數(shù)據(jù)庫(kù)。瀏覽器通過 Web Server同數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)交互。B/S模式較C/S 模式：C/S模式客戶端需要安裝專用的客戶端軟件。首先涉

5、及到安裝的工作量，其次任何一臺(tái)電腦出問題，如病毒、硬件損壞，都需要進(jìn)行安裝或維護(hù)。特別是需很多分部的情況，不是工作量的問題 ，而是路程的問題。還有，系統(tǒng)軟件升級(jí)時(shí)，每臺(tái)客戶機(jī)需要重新安裝其維護(hù)和升級(jí)成本非常高。C/S模式對(duì)客戶端的操作系統(tǒng)一般也會(huì)有限制，可能適應(yīng)于Windows系列操作系統(tǒng)，而不適用于Lirux 、Unix等操作系統(tǒng)而B/S 最大的優(yōu)點(diǎn)就是可以在任何地方進(jìn)行操作而不用安裝任何專門的軟件只要有一臺(tái)能上網(wǎng)的電腦就能使用，客戶端零維護(hù)。系統(tǒng)的擴(kuò)展非常容易，只要能上網(wǎng)，再 由系統(tǒng)管理員分配 個(gè)用戶名和密碼，就可以使用了。甚至可以在線申請(qǐng)，通過公司 內(nèi)部的安全認(rèn)證（如 CA證書） 后，不

6、需要人的參與 ，系統(tǒng)可以自動(dòng)分配給用戶個(gè)賬 號(hào)進(jìn)入系統(tǒng)，這在最大程度上滿足了項(xiàng)目要求。系統(tǒng)采用的是目前較流行的一種Web應(yīng)用程序開源框架- Struts+Spr ing+Hibernate （ SSH ）。集成SSH框架的系統(tǒng)從職責(zé)上分為四層表示層、業(yè)務(wù)邏輯層、數(shù)據(jù)持久層和域模塊層，以幫助開發(fā)人員在短期內(nèi)搭建結(jié)構(gòu)清晰、可復(fù)用性好、維戶方便的 Web應(yīng)用程序。其中使用 Struts作為系統(tǒng)的整體基礎(chǔ)架構(gòu)，負(fù)責(zé)MVC的分離，在Struts框架的模型部分，利用Hibernate框架對(duì)持久層提供支持，業(yè)務(wù)層用Spring支 持。具體做法是：用面向?qū)ο蟮姆治龇椒ǜ鶕?jù)需求提出一些模型，將這些模型實(shí)現(xiàn)為基本

7、的Java對(duì)象，然后編寫基本的 DAO接口，并給出Hibernate 的 DAO實(shí)現(xiàn)，采用Hibernate架構(gòu)實(shí)現(xiàn)的DAO類來實(shí)現(xiàn)Java類與數(shù)據(jù)庫(kù)之間的轉(zhuǎn)換和訪問，最后由Spring完成業(yè)務(wù)邏輯系統(tǒng)的基本業(yè)務(wù)流程是：在表示層中，首先通過JSP頁(yè)面實(shí)現(xiàn)交互界面，負(fù)責(zé)傳送請(qǐng)求 （Request ）和接收響應(yīng)（Response）,然后Struts 根據(jù)配置文件（struts-config. xml ）將 ActionServlet接收到的 Request 委派給相應(yīng)的Action處理。在業(yè)務(wù)層中，管理服務(wù)組件的Spring IoC 容器負(fù)責(zé)向Action 提供業(yè)務(wù)模型（model）組件和該組件的

8、協(xié)作對(duì)象數(shù)據(jù)處理（DAO 組件案成業(yè)務(wù)邏輯，并提供事務(wù)處理、緩沖池等容器組件以提升系統(tǒng)性能和保證數(shù)據(jù)的完整性。而在持久 層中，依賴于Hibernate的對(duì)象化映射和數(shù)據(jù)庫(kù)交互，處理DAO組件請(qǐng)求的數(shù)據(jù)，并返回處理結(jié)果。采用上述開發(fā)模型，不僅實(shí)現(xiàn)視圖、控制器與模型的徹底給葛，而且還實(shí)現(xiàn)了業(yè)務(wù)邏輯層與持久層的分離。這樣無論前端如何變化，模型層只很少的改動(dòng)，并且數(shù)據(jù)庫(kù)的變化也不會(huì)對(duì)前端有所影響，大大提升了系統(tǒng)的可復(fù)用性。而且由于不同層之間穩(wěn)合 度 高，有利于團(tuán)隊(duì)成員并行工作，大大提高了開發(fā)效率的同時(shí)，也保證了軟件用戶品的質(zhì)量 。2、C/S模式C/S （ Client/Server ,客戶機(jī)/服務(wù)器）

9、模式又稱C/S結(jié)構(gòu)，是20世紀(jì)80年代逐步成長(zhǎng)起來的一種模式，是軟件系統(tǒng)體系結(jié)構(gòu)的種。C/S結(jié)構(gòu)的關(guān)鍵在于功能的分布，一些功能放在前端機(jī)（即客戶機(jī)） 上執(zhí)行，另一些功能放在后端機(jī)（即服務(wù)器）上執(zhí)行。功能的分布在于減少計(jì)算機(jī)系統(tǒng)的各種瓶頸問題。C?模式簡(jiǎn)單地講就是基內(nèi)部網(wǎng)絡(luò)的應(yīng)用系統(tǒng)。與B/S （ Browser/Server，瀏覽器 /服務(wù)器）模式相比C/S模式的應(yīng)用系統(tǒng)最大的好處是不依賴企業(yè)外網(wǎng)環(huán)境，無論企業(yè) 是否能上網(wǎng)，都不影響。應(yīng)用C/S結(jié)構(gòu)服務(wù)通常采用高性能的 PC工作站或小型機(jī)，并采用大型數(shù)據(jù)庫(kù)系 統(tǒng)，如ORACLE、SYBASE、InfORIMix 或SQL Server ?？蛻舳?/p>

10、需要安裝專用的 客戶端軟件。C/S結(jié)構(gòu)的優(yōu)點(diǎn)是能充分發(fā)揮客戶端 pc的處理能力，很多工作可以在 客戶端處理后再提交給服務(wù)器，因此對(duì)應(yīng)的優(yōu)點(diǎn)就是客戶端響應(yīng)速度快。C/S架構(gòu)軟件的優(yōu)勢(shì)與劣勢(shì)：（1）應(yīng)用服務(wù)器運(yùn)行數(shù)據(jù)負(fù)荷較輕。最簡(jiǎn)單的C/S體系結(jié)構(gòu)的數(shù)據(jù)庫(kù)應(yīng)用由兩部分組成，即客戶應(yīng)用程序和數(shù)據(jù)庫(kù)服務(wù)器程序。二者可分別稱為前臺(tái)程序與后臺(tái)程 序。運(yùn)行數(shù)據(jù)庫(kù)服務(wù)器程序的機(jī)器，也稱為應(yīng)用服務(wù)器。一旦服務(wù)被程序被啟動(dòng)，就 隨時(shí)等待響應(yīng)客戶程序發(fā)來的請(qǐng)求；客戶應(yīng)用程序運(yùn)行在用戶自己的電腦上，對(duì)應(yīng)于 數(shù)據(jù)庫(kù)服務(wù)囂，可稱為客戶電腦，當(dāng)需要數(shù)據(jù)庫(kù)中的數(shù)據(jù)進(jìn)行任何操作時(shí)，客戶程序 自動(dòng)地尋找服務(wù)器程序，并向 其發(fā)出請(qǐng)

11、求，服務(wù)器程序根據(jù)預(yù)定的規(guī)則作出應(yīng)答，送 回結(jié)果，應(yīng)用服務(wù)運(yùn)行數(shù)據(jù)負(fù)荷較輕。（2 ）數(shù)據(jù)的儲(chǔ)存管理功能較為透明。在數(shù)據(jù)庫(kù)應(yīng)用中，數(shù)據(jù)的儲(chǔ)存管理功能， 是由服務(wù)器程序和客戶應(yīng)用程序分別獨(dú)立運(yùn)行的，并且通常把那些不同的（不管是已 知還是來知的） 前臺(tái)應(yīng)用所不能違反的規(guī)則，在服務(wù)器程序中集中實(shí)現(xiàn)，例如訪問這 的權(quán)限，編號(hào)可以重復(fù) 、必須有客戶才能建立定單這樣的規(guī)則。所有這些，對(duì)于工作 在前臺(tái)程序上最終用戶，是“透明”的，他們無須追問（通常也無法干涉）背后的過程，就可以完成自己的 一切的工作。在客戶服務(wù)器架構(gòu)的應(yīng)用中，前臺(tái)程序事不是 非?！笆菪　甭闊┑氖虑槎冀唤o服務(wù)器和網(wǎng)絡(luò)在C/S體系下，數(shù)據(jù)庫(kù)不能真

12、正成為公共、專業(yè)化的倉(cāng)庫(kù)，它受到獨(dú)主的專門管理。C/S模式系統(tǒng)的開發(fā):C/S結(jié)構(gòu)是建立在中間件產(chǎn)品基礎(chǔ)之上的，要求應(yīng)用開發(fā)者自己去處理事務(wù)官理、消息隊(duì)列、數(shù)據(jù)的復(fù)制和同步、通信安全等系統(tǒng)級(jí)的問題。這對(duì)應(yīng)用開發(fā)者提出了較高的要求，而且迫使應(yīng)用開發(fā)者投入很多精力來解決應(yīng)用程序以外的問題。這使得應(yīng)用程序的維護(hù) 、移植和操作變得復(fù)雜。如果客戶端是在不同的操作系統(tǒng)上，C/S結(jié)構(gòu)的軟件需要開發(fā)不同版本的客戶端軟件。但是 ，與B/S結(jié)構(gòu)相比，C/S技 術(shù)發(fā)展歷史更為“悠久”從技術(shù)成熟度及軟件設(shè)計(jì)、開發(fā) 人員的掌握水平來看，C/S技術(shù)應(yīng)是更成熟、至可靠的項(xiàng)目總體架構(gòu)及技術(shù)解決萬案一、項(xiàng)目總體架構(gòu)一、SSH框架

13、介紹和分析大型企業(yè)級(jí)Web應(yīng)用系統(tǒng)的開發(fā)通常要求有一個(gè)良好的軟件架構(gòu)、便于協(xié)作開發(fā) 和擴(kuò)展升級(jí)，而傳統(tǒng)的開發(fā)模式不能很好地滿足這些要求?；诋?dāng)前Web應(yīng)用程序開發(fā)面臨的問題，項(xiàng)目結(jié)合目前比較流行的開源框架 SSH（ Spring、Struts 、Hibemate）,具體討論其基本相似性及有關(guān)基本概念，提出了 一種開發(fā)Java Web應(yīng)用的輕量級(jí)解決方案，此系統(tǒng)架構(gòu)可以在短期內(nèi)搭建結(jié)構(gòu)清晰 可復(fù)用性好、可擴(kuò)展性好、維護(hù)方便的Web應(yīng)用程序。1、框架技術(shù)框架一般具有即插即用的可重用性、成熟的穩(wěn)定性以及良好的團(tuán)隊(duì)協(xié)作性。JavaEE復(fù)雜的多層結(jié)構(gòu)決定了大型的 JavaEE項(xiàng)目需要運(yùn)用框架和設(shè)計(jì)模式來

14、控制軟 件質(zhì)量。目前，市場(chǎng)上出現(xiàn)了些商業(yè)的、開源的基于 JavaEE的應(yīng)用框架，其中主流的框架技術(shù)有：基于 MVC模式Struts 框架、基于IcC 模式的Spring框架以及對(duì)象 /關(guān)系映射框架Hibernate 等。2、框架共同點(diǎn)所有現(xiàn)代的網(wǎng)絡(luò)開發(fā)框架幾乎都遵循了模型-視圖-控制（MVC股計(jì)模式：商業(yè)邏輯和描述被分開，由一個(gè)邏輯流控制器來協(xié)調(diào)來自客戶端的請(qǐng)求和服務(wù)器上將采取的 行動(dòng)。這條途徑成為了網(wǎng)絡(luò)開發(fā)的事實(shí)上的標(biāo)準(zhǔn)。每個(gè)框架的內(nèi)在的機(jī)制當(dāng)然是不同 的，但是開發(fā)者們使用來設(shè)計(jì)和實(shí)現(xiàn)他們的Web應(yīng)用軟件的API是很類似的。差別還存在于每個(gè)框架提供的擴(kuò)展方面，例如標(biāo)簽庫(kù)，JavaBean包裝

15、器等。所有的框架使用不同的技術(shù)來協(xié)調(diào)在Web應(yīng)用程序之內(nèi)的導(dǎo)航，例如XMM己制文件，java屬性文件或定制屬性。所有的框架在控制器模塊實(shí)現(xiàn)的方法方面也存在 明顯的不同。例如，EJB可能實(shí)例化在每個(gè)請(qǐng)求中需要的類或使用Java反射動(dòng)態(tài)地調(diào)用一個(gè)適當(dāng)?shù)男袨椋ˋction ）類。另外，不同框架在各自引入的概念上也有所不同。例如 一個(gè)框架可能定義用戶請(qǐng)求和反應(yīng)場(chǎng)所，而另外一個(gè)框架可能僅僅定義一個(gè)完整的流： 從一個(gè)請(qǐng)求到多個(gè)響答和隨后的再請(qǐng)求。各種Java框架在它們組織數(shù)據(jù)流的方法方面是很類似的。在請(qǐng)求發(fā)出后，在應(yīng) 用程序服務(wù)器上產(chǎn)生一些行動(dòng)；而作為響應(yīng)，一些可能包含對(duì)象集的數(shù)據(jù)總是被發(fā)送 到WEB!。

16、然后從那些對(duì)象：可能是有setter和getter方法的簡(jiǎn)單類、JAVABEANS值對(duì)象、或者一些集合對(duì)象中提取數(shù)據(jù)?，F(xiàn)代的Java框架還想方設(shè)法簡(jiǎn)化開發(fā)者的開發(fā)任務(wù)，如通過使用簡(jiǎn)易的 API、數(shù)據(jù)庫(kù)連接池、甚至數(shù)據(jù)庫(kù)調(diào)用包等提供自動(dòng)化的追 蹤方式來實(shí)現(xiàn)。一些框架或者能夠鉤進(jìn)（ hooked into ）另外的JavaEE技術(shù)中，例如 JMS（Java消息服務(wù)）或JMX,或把這些技術(shù)集成到一起。服務(wù)器數(shù)據(jù)持續(xù)性和日志也有 可能成為框架的一部分3、MVO 式MVO式是一個(gè)用于將用戶界面邏基與業(yè)務(wù)分離開來的基礎(chǔ)設(shè)計(jì)模式，它將數(shù)據(jù) 處理、界面以及用戶的行為控制分為：Model （模型）-View（視

17、圖）-Controller（控器制）。Model:負(fù)責(zé)當(dāng)前應(yīng)用的數(shù)據(jù)獲取與變更及相關(guān)的業(yè)務(wù)邏基?？捎肑AVABEAN來體現(xiàn)；View:負(fù)責(zé)顯示信息?？梢允褂?JSP、飛IELOCITY模板等技術(shù)；Controller :負(fù)責(zé)收集轉(zhuǎn)化用戶的輸入。常用一個(gè)SERVLE俅實(shí)現(xiàn)View和Controller 卻依賴于 Model ,但是 Model既不依賴于 View ,也不依 賴于Controller ,這是分離的主要優(yōu)點(diǎn)之，這樣Model可以單獨(dú)的建主和測(cè)試以便于代碼復(fù)用，View和Controller 只需Model提供數(shù)據(jù)，它們不會(huì)知道、也不會(huì)關(guān)心 數(shù)據(jù)是存儲(chǔ)在SQL Server還是Orac

18、le數(shù)據(jù)庫(kù)中或其他的地方4、WEB!框架 StrutsStruts是一個(gè)在JSP Model2基礎(chǔ)上實(shí)現(xiàn)的 MVC匡架，其主要的設(shè)計(jì)理念是通過 控制器將表現(xiàn)邏輯和業(yè)務(wù)邏輯解耦，以提高系統(tǒng)的可維護(hù)性、可擴(kuò)展性及可重用性。Struts框架的體系結(jié)構(gòu)如下圖所示：wm悔黑的取獗片陶卜面就上圖所示的體系結(jié)構(gòu)圖分析Struts框架中的MVC1件.視圖（view）:視圖部分主要由JSP頁(yè)面組成，其中沒有流程邏輯、業(yè)務(wù)邏 輯和模型信息，只有標(biāo)記。Struts自身包含了一組標(biāo)記庫(kù)（TagLib）,這也是Struts的精華之一，靈活運(yùn)用它們可以簡(jiǎn)化JSP頁(yè)面的代碼，提高開發(fā)效率。.控制器（controller）:

19、 Struts 中的Controller 主要是其自身提供的ActionServlet 。ActionServlet 接收所有來自客戶端的請(qǐng)求并根據(jù)配置文件 （struts-config.xml）中的定義將控制轉(zhuǎn)移到適當(dāng)?shù)腁ction對(duì)象。工模型（model） : Struts沒有定義具體 Model層的實(shí)現(xiàn)，Model層通常是和業(yè) 務(wù)邏輯緊密相關(guān)的，有持續(xù)化的要求。目前在商業(yè)領(lǐng)域和開源世界，都有一些優(yōu)秀的工 具可以為Model層的開發(fā)提供便利。業(yè)務(wù)邏輯層框架SpingSpring是一個(gè)解決了許多JavaEE開發(fā)中常見問題并能夠替代EJB技術(shù)的強(qiáng)大的輕量級(jí)框架。這里所說的輕量級(jí)指的是Sprin

20、g框架本身，而不是指 Spring只能用于輕量級(jí)的應(yīng)用開發(fā)。Spring的輕盈體現(xiàn)在其框架本身的基礎(chǔ)結(jié)構(gòu)以及對(duì)其他應(yīng)用工具 的支持和裝配能力。與EJB這種龐然大物相比，Spring可使程序研發(fā)人員把各個(gè)技術(shù)層次之間的風(fēng)險(xiǎn)降低。服務(wù)和技術(shù)支持的一個(gè)標(biāo)準(zhǔn)化的運(yùn)行時(shí)的環(huán)境）而非傳統(tǒng)實(shí)現(xiàn)中由程序代碼直接 操控，這種將控制權(quán)由程序代碼到外部容器的轉(zhuǎn)移，稱為“翻轉(zhuǎn)”。DI是對(duì)IoC更形象的解釋，即由容器在運(yùn)行期間動(dòng)態(tài)地將依賴關(guān)系（如構(gòu)造參數(shù)、構(gòu)造對(duì)象或接口）注入到組件之中。Spring采用設(shè)值注入（使用Setter方法實(shí)現(xiàn)依賴）和構(gòu)造子注入（在構(gòu) 造方法中實(shí)現(xiàn)依賴）的機(jī)制，通過配置文件管理組建的協(xié)作對(duì)象，

21、創(chuàng)建可以構(gòu)造組件的 IoC容器。這樣，不需要編寫工廠模式、單例模式或者其他構(gòu)造的方法，就可以通過容 器直接獲取所需的業(yè)務(wù)組件。Spring框架的結(jié)構(gòu)如下圖所示|ii文件和株文 化突悻弟這樣的結(jié)構(gòu)，系統(tǒng)從職責(zé)上分為四層：WEEB、業(yè)務(wù)邏輯層、數(shù)據(jù)持久層和實(shí)體層。其中使用Struts作為系統(tǒng)的整體基礎(chǔ)架構(gòu)，負(fù)責(zé)MVC勺分離，在Struts框架的模型部分，利用Hibernate框架對(duì)持久層提供支持，業(yè)務(wù)層用Spring支持。具體做法是：用面向?qū)ο蟮姆治龇椒ǜ鶕?jù)需求提出一些模型，將這些模型實(shí)現(xiàn)為基本的Java對(duì)象，然后編寫基本的 DAO 口，并給出Hibernate的DAO現(xiàn)，采用Hibernate架

22、構(gòu) 實(shí)現(xiàn)的DA或來實(shí)現(xiàn)Java類與數(shù)據(jù)庫(kù)之間的轉(zhuǎn)換和訪問，最后由 Spring完成業(yè)務(wù)邏 輯。系統(tǒng)的基本業(yè)務(wù)流程是：在 WE或示層中，首先通過 JSP頁(yè)面實(shí)現(xiàn)交互界面，負(fù) 責(zé)傳送請(qǐng)求(Request)和接收響應(yīng)(Response),然后Struts根據(jù)配置文件(struts- config.xml) 將ActionServlet接收到的Request委派給相應(yīng)的 Action處理。在業(yè)務(wù)層中，管理服務(wù)組件的 Spring IoC容器負(fù)責(zé)向Action提供業(yè)務(wù)模型(Model)組件和 該組件的協(xié)作對(duì)象數(shù)據(jù)處理(DAO)組件完成業(yè)務(wù)邏輯，并提供事務(wù)處理、緩沖池等容器 組件以提升系統(tǒng)性能和保證數(shù)據(jù)的

23、完整性。而在持久層中，則依賴于 Hibernate的對(duì) 象化映射和數(shù)據(jù)庫(kù)交互，處理DAOfi件請(qǐng)求的數(shù)據(jù)，并返回處理結(jié)果。采用上述開發(fā)模型，不僅實(shí)現(xiàn)了視圖、控制器與模型的徹底分離，而且還實(shí) 現(xiàn)了業(yè)務(wù)邏輯層與持久層的分離。這樣無論前端如何變化，模型層只需很少的改動(dòng)， 并且數(shù)據(jù)庫(kù)的變化也不會(huì)對(duì)前端有所影響，大大提高了系統(tǒng)的可復(fù)用性。而且由于不 同層之間耦合度小，有利于團(tuán)隊(duì)成員并行工作，大大提高了開發(fā)效率。但是對(duì)于當(dāng)前日益復(fù)雜化的 WEB2.0的開發(fā)，卻存在不少問題，歸納起來主要有 以下的不足：DAOffi服務(wù)層容易出現(xiàn)職責(zé)不明，由于按照MV譴輯，業(yè)務(wù)代碼應(yīng)該寫在 StrutsAction里，但是其

24、事務(wù)的提供，卻是配置在 Service層。為了一組在邏輯上完整 的數(shù)據(jù)操作業(yè)務(wù)邏輯，需要涉及兩個(gè)層( Service、Action )來進(jìn)行編寫，遇到判斷的 情況下，為了保證完整的事務(wù)操作，則需要將業(yè)務(wù)代碼移到Service層完成，而通常習(xí)慣了在Struts Action里調(diào)用多次Service而產(chǎn)生多個(gè)事務(wù)，但在出現(xiàn)Exception導(dǎo)致出錯(cuò)時(shí)，操作之前調(diào)用的Service事務(wù)的業(yè)務(wù)數(shù)據(jù)沒有被回滾。當(dāng)需要返回的數(shù)據(jù)供AJAX使用，操作JSON XML的大量使用時(shí)。開發(fā)起來會(huì)很費(fèi)力，一段同樣的業(yè)務(wù)代碼，為了使用AJAX和XML可能需要重新編寫一次，或者在同一個(gè)ACTIONS通過標(biāo)志來判斷，對(duì)分

25、層結(jié)構(gòu)造成了比較糟糕的破壞。如果設(shè)計(jì)得 不好，為了使用JSON和XML還得額外增加大量的配置，嚴(yán)重降低了開發(fā)效率。因此,為了克服這些缺點(diǎn)，對(duì)于 SS佛構(gòu)，進(jìn)行了重新的分層，共享了業(yè)務(wù)代碼。簡(jiǎn)化了開 發(fā)、增強(qiáng)了與AJAX技術(shù)、XML&術(shù)的結(jié)合。提供了一種更高效的開發(fā)模式。其開發(fā)的結(jié)構(gòu)圖如下：MODEL 層生成對(duì)雙a哀件,并生 或?qū)?yīng)的持久化戔SEXW7E 層柜揖惇斯雷拄住目拈久化 方法，確定對(duì)應(yīng)操作方法*瑜1成的D40,布月需 要的方法升配直到Sptlg實(shí)現(xiàn) BuimesjServict 他口 并組置到Spring.編寫北務(wù)愛朝，跳出異京， 爵用【向遂行獨(dú)據(jù)操作分析需要常規(guī)提交的提 作*稿吊切E

26、田Fmm用于 保右囊甲牛把V1YW 層描寫Fomi笄設(shè)對(duì)匣的ActtojiFgi頁(yè)面調(diào)用對(duì)應(yīng) 冊(cè) A Mi in如常規(guī)觸則顯示麻布等I 敷施.異中提交則解析Jun1或XML數(shù)據(jù)并顯示據(jù)強(qiáng)1L務(wù)將要，分析fug上 提交的SfT及分所再平的ax異步授交過1作這個(gè)架構(gòu)的優(yōu)點(diǎn)在于，由于業(yè)務(wù)代碼統(tǒng)一實(shí)現(xiàn)BusinessService 接口，使得只需要相對(duì)固定的幾個(gè) Struts Action類調(diào)用Service層的方法，便可以完成工作。包括 JSON&式輸出，XML輸出及WebService輸出均調(diào)用Service層方法來完成功能。這樣 便實(shí)現(xiàn)了業(yè)務(wù)代碼的分離，以及與前端框架的極大解耦技術(shù)解決方案開發(fā)一

27、款好的軟件產(chǎn)品，離不開一個(gè)好的開發(fā)過程。開發(fā)期間對(duì)過程的把控程度， 往往會(huì)決定軟件產(chǎn)品的質(zhì)量好壞。因此，開發(fā)前期的計(jì)劃流程是必不可少的。本公司軟件系統(tǒng)的開發(fā)是按階段進(jìn)行的，一般劃分為以下階段:1、可行性分析可行性分析的目的是明確系統(tǒng)的目的、功能和要求，了解目前所具備的開發(fā)環(huán)境 和條件，分析的內(nèi)容有：在技術(shù)能力上是否可以支持在經(jīng)濟(jì)上效益如何在法律上是否符合要求與部門、企業(yè)的經(jīng)營(yíng)和發(fā)展是否吻合系統(tǒng)投入運(yùn)行后的維護(hù)有無保障2.可行性分析需求分析概要設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼測(cè)試修改完善驗(yàn)收維護(hù)項(xiàng) 目：.可行性研究報(bào)告.軟件需求說明書.概要設(shè)計(jì)說明書.數(shù)據(jù)庫(kù)設(shè)計(jì)說明書.詳細(xì)設(shè)計(jì)說明書.測(cè)試計(jì)劃.測(cè)試分析報(bào)告.驗(yàn)

28、收?qǐng)?bào)告.用戶操作手冊(cè)可行性討論的目的是判定軟件系統(tǒng)的開發(fā)有無價(jià)值，分析和討論的內(nèi)容形成 “系統(tǒng)開發(fā)計(jì)劃書”，主要內(nèi)容有：開發(fā)的目的及所期待的效果系統(tǒng)的基本設(shè)想，涉及的業(yè)務(wù)對(duì)象和范圍開發(fā)進(jìn)度表，開發(fā)組織結(jié)構(gòu)開發(fā)、運(yùn)行的費(fèi)用預(yù)期的系統(tǒng)效益開發(fā)過程中可能遇到的問題及注意事項(xiàng)。求分析需求分析是軟件系統(tǒng)開發(fā)中最重要的一個(gè)階段，直接決定著系統(tǒng)的開發(fā)質(zhì)量和成 敗。因此必須要明確用戶的要求和應(yīng)用現(xiàn)場(chǎng)環(huán)境的特點(diǎn)，了解系統(tǒng)應(yīng)具有哪些功能、 數(shù)據(jù)的流程和數(shù)據(jù)之間的聯(lián)系。需求分析應(yīng)有用戶參加，到使用現(xiàn)場(chǎng)進(jìn)行調(diào)研學(xué)習(xí)，軟件設(shè)計(jì)人員應(yīng)虛心向技術(shù) 人員和使用人員請(qǐng)教，共同討論解決需求問題的方法，對(duì)調(diào)查結(jié)果進(jìn)行分析，明確問

29、題的所在需求分析階段的工作，可以分為四個(gè)方面：?jiǎn)栴}識(shí)別，分析與綜合，制訂規(guī)格說明 評(píng)審。 (一)、問題識(shí)別從系統(tǒng)角度來理解軟件，確定對(duì)所開發(fā)系統(tǒng)的綜合要求，并提出這些需求的實(shí)現(xiàn)條 件，以及需求應(yīng)該達(dá)到的標(biāo)準(zhǔn)。這些需求包括：功能需求（做什么），性能需求（要達(dá)到什么指標(biāo)）,環(huán)境需求（如機(jī)型，操作系統(tǒng)等）,可靠性需求（不發(fā)生故障的概率），安全保密 需求，用戶界面需求，資源使用需求（軟件運(yùn)行是所需的內(nèi)存，CPU等），軟件成本消耗與開 發(fā)進(jìn)度需求，預(yù)先估計(jì)以后系統(tǒng)可能達(dá)到的目標(biāo)。（二）、分析與綜合逐步細(xì)化所有的軟件功能，找出系統(tǒng)各元素間的聯(lián)系，接口特性和設(shè)計(jì)上的限制， 分析他們是否滿足需求，剔除不合理部

30、分，增加需要部分。最后，綜合成系統(tǒng)的解決方案 給出要開發(fā)的系統(tǒng)的詳細(xì)邏輯模型（做什么的模型）。（三）、制訂規(guī)格說明書即編制文檔，描述需求的文檔稱為軟件需求規(guī)格說明書。（四）、評(píng)審對(duì)功能的正確性，完整性和清晰性，以及其它需求給予評(píng)價(jià)。評(píng)審?fù)ㄟ^才可進(jìn)行下 一階段的工作，否則重新進(jìn)行需求分析。需求分析的內(nèi)容最終會(huì)編寫成“系統(tǒng)需求分析報(bào)告”。系統(tǒng)設(shè)計(jì)一、 設(shè)計(jì)原則和設(shè)計(jì)要求描述對(duì)本軟件系統(tǒng)運(yùn)行概要要設(shè)計(jì)的原則，通?？梢钥紤]以下幾方面的內(nèi)容1、命名規(guī)則2、模塊獨(dú)立性原則3、邊界設(shè)計(jì)原則4、數(shù)據(jù)庫(kù)設(shè)計(jì)規(guī)則5、必須的安全措施6、安全性和保密原則7、系統(tǒng)靈活性要求8、系統(tǒng)易操作性要求9、系統(tǒng)可維護(hù)性要求二、系

31、統(tǒng)邏輯設(shè)計(jì)系統(tǒng)邏輯設(shè)計(jì)主要是根據(jù)軟件產(chǎn)品需求規(guī)格說明書和軟件產(chǎn)品數(shù)據(jù)字典建立系統(tǒng) 的邏輯模型。此種模型暫時(shí)與系統(tǒng)的物理因素（例如：計(jì)算機(jī) 、數(shù)據(jù)庫(kù)管理系統(tǒng)）無關(guān)。它是系統(tǒng)需求與物理實(shí)現(xiàn)的中間結(jié)構(gòu)，它的主要結(jié)果是建立：系統(tǒng)結(jié)構(gòu)圖、系統(tǒng)界面結(jié)構(gòu)圖、系統(tǒng)出錯(cuò)處理 、以及系統(tǒng)開發(fā)技術(shù)說明。（三）系統(tǒng)組織設(shè)計(jì)系統(tǒng)組織設(shè)計(jì)通過系統(tǒng)組織表描述本系統(tǒng)由哪些子系統(tǒng)（模塊）組成，這些子系統(tǒng)與業(yè)務(wù)職能之間的關(guān)系，以及各個(gè)子系統(tǒng)的安裝地點(diǎn)。系統(tǒng)組織表的格式如下：子系統(tǒng)編號(hào)英義名稱中文名稱業(yè)務(wù)職能安裝地點(diǎn)備注1、子系統(tǒng)編號(hào)給出本系統(tǒng)中指定子系統(tǒng)的順序編號(hào)。如果本系統(tǒng)末劃分為多個(gè)子系統(tǒng)， 僅由一個(gè)運(yùn)行模塊組成；則本項(xiàng)內(nèi)容

32、仍需要描述，但是本表內(nèi)容只有一行。在一個(gè)系統(tǒng)中有可能安裝若干個(gè)相同的子系統(tǒng)，在這種情況下，應(yīng)該視為 一個(gè)子系統(tǒng)，并且劃多個(gè)安裝地點(diǎn)分別進(jìn)行描述。如果相同的子系統(tǒng)通過系統(tǒng)設(shè) 置，實(shí)現(xiàn)的業(yè)務(wù)職能具有明顯差異時(shí)，應(yīng)該采用多行進(jìn)行分別描述，并且在備 主中說明其差異所在。2、子系統(tǒng)英文名稱給出本子系統(tǒng)的英文各稱，該名稱是在應(yīng)用軟件中實(shí)際使用的可執(zhí)行文件 名稱，必須能夠說明該子系統(tǒng)的特點(diǎn)。若本系統(tǒng)中只有 一個(gè)子系統(tǒng)，則本項(xiàng)內(nèi)容需要描述，但是本表內(nèi)容只有一行。 3、子系統(tǒng)中文名稱給出本子系統(tǒng)的中文名稱，該名稱必須能夠說明該子系統(tǒng)的特點(diǎn)若本系統(tǒng)中只有 一個(gè)子系統(tǒng)，則本項(xiàng)內(nèi)容需要描述，但是本表內(nèi)容只有一行。4、

33、業(yè)務(wù)職能描述該子系統(tǒng)完成的核心業(yè)務(wù)。5、安裝地點(diǎn)描述該子系統(tǒng)實(shí)際安裝的部門、或者某個(gè)具體地點(diǎn)。6、備注針對(duì)該子系統(tǒng)，需要說明的其它有關(guān)問題。（四）、系統(tǒng)結(jié)構(gòu)設(shè)計(jì)1、系統(tǒng)特性表系統(tǒng)特性是系統(tǒng)中完成某項(xiàng)具體操作的基本單元，它由入口參數(shù)，出口參數(shù)以及處理過程三部分組成。系統(tǒng)特性可以真奇操作界面，也可以沒操作界面，可以被其它操作界面或者系統(tǒng)特性調(diào)用，也可以調(diào)用其它操作界面、非操作界面、或者 系統(tǒng)特性；但是不 允許遞歸調(diào)用（調(diào)用自己） ，包括間接遞歸調(diào)用。當(dāng)系統(tǒng)由多個(gè)子系統(tǒng)（模塊）組成肘，每個(gè)子系統(tǒng)分別使用一張系統(tǒng)特性表進(jìn)行描述。系統(tǒng)特性表的格式如下;子系統(tǒng)編號(hào)子系統(tǒng)編號(hào) 英義名稱子系統(tǒng)編號(hào) 中文名稱特

34、性編號(hào)系統(tǒng)特性英 文名稱系統(tǒng)特性中 文名稱操作功能調(diào)用對(duì)象被調(diào)用對(duì)象備 注說明：其中:(1)、子系統(tǒng)編號(hào)含義同上。(2)、子系統(tǒng)英文名稱含義同上。(3)、子系統(tǒng)中文名稱含義同上。(4)、特性編號(hào)整個(gè)系統(tǒng)所有特性的統(tǒng)一編號(hào)。(5)、系統(tǒng)特性英文名稱系統(tǒng)特性的英文正式名稱，將來用于軟件開發(fā)中，必須符合命名規(guī)范。(6)、系統(tǒng)特性中文名稱系統(tǒng)特性的中文正式名稱，來源于需求規(guī)格說明書中，系統(tǒng)特性一節(jié)中的有關(guān)描述。(7)、操作功能是指該特性實(shí)際完成的操作說明。(8)、調(diào)用對(duì)象是指調(diào)用該系統(tǒng)特性的系統(tǒng)對(duì)象，這里的系統(tǒng)對(duì)象可以是系統(tǒng)特性、也可以是操作界 面。(9)、被調(diào)用對(duì)象是指被該系統(tǒng)特性調(diào)用的系統(tǒng)對(duì)象，這

35、里的系統(tǒng)對(duì)象可以是系統(tǒng)特性、也可以是操作 界面。(10)、備注描述與該系統(tǒng)特性有關(guān)的其它注意事項(xiàng)。(11)、說明描述與該系統(tǒng)特性表有關(guān)的其它注意事項(xiàng)。(五)系統(tǒng)接口設(shè)計(jì)：1.系統(tǒng)接口；接口作為系統(tǒng)的一種輸入 /輸出形式，分為網(wǎng)絡(luò)接口，數(shù)據(jù)接口，Rs-232串通訊接口， IEEE串行接口，并I/0接口等(六)系統(tǒng)完整性設(shè)計(jì)描述系統(tǒng)對(duì)象(數(shù)據(jù)元 數(shù)據(jù)類)，所受的邏輯約束關(guān)系當(dāng)系統(tǒng)由多個(gè)子系統(tǒng)(模塊)組成，每個(gè)子系統(tǒng)分別使用一張系統(tǒng)完整性約束表。子系統(tǒng)編號(hào)子系統(tǒng)英文名稱子系統(tǒng)中午名稱約束編號(hào)完整性名稱相對(duì)對(duì)象名約束表這式備注說明其中:(1)、子系統(tǒng)編號(hào)含義同上。 (2)、子系統(tǒng)英文名稱含義同上。(3

36、)、子系統(tǒng)中文名稱含義同上。(4)、約束編號(hào)整個(gè)系統(tǒng)所有約束的統(tǒng)一編號(hào)。(5)、完整性名稱系統(tǒng)完整性約束的正式名稱，必須符合通常習(xí)慣(6)、相對(duì)對(duì)象名完整性約束中的相關(guān)對(duì)象(數(shù)據(jù)元和數(shù)據(jù)類)(7)、約束表達(dá)式用一階邏輯表達(dá)式表達(dá)的約束方程式。(8)、備注描述與該系統(tǒng)完整性約束有關(guān)的其它注意事項(xiàng)。(9)、說明描述與該系統(tǒng)完整性約束表有關(guān)的其它注意事項(xiàng)。系統(tǒng)設(shè)計(jì)具體可根據(jù)系統(tǒng)的規(guī)模分成概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)兩個(gè)階段，概要設(shè)計(jì)包括:劃分系統(tǒng)模塊每個(gè)模塊的功能確定用戶使用界面概要設(shè)計(jì)輸入輸出數(shù)據(jù)的概要設(shè)計(jì)報(bào)表概要設(shè)計(jì)數(shù)據(jù)之間的聯(lián)系、流程分析 文件和數(shù)據(jù)庫(kù)表的邏輯設(shè)計(jì)硬件、軟件開發(fā)平臺(tái)的確定有規(guī)律數(shù)據(jù)的規(guī)范

37、化及數(shù)據(jù)惟一性要求。系統(tǒng)的詳細(xì)設(shè)計(jì)是對(duì)系統(tǒng)的概要設(shè)計(jì)進(jìn)一步具體化，其主要工作有：文件和數(shù)據(jù)庫(kù)的物理設(shè)計(jì) 輸入輸出記錄的方案設(shè)計(jì)對(duì)各子系統(tǒng)的處理方式和處理內(nèi)容進(jìn)行細(xì)化設(shè)計(jì)編制程序設(shè)計(jì)任務(wù)書4、編碼根據(jù)程序設(shè)計(jì)任務(wù)書的要求，用計(jì)算機(jī)算法語(yǔ)言實(shí)現(xiàn)解題的步驟，主要工作包括：模快的理解和進(jìn)一步劃分 以模塊為單位的邏基設(shè)計(jì)，也就是模塊內(nèi)的流程圖的編制縮寫代碼，用程序設(shè)計(jì)語(yǔ)言編制程序進(jìn)行模塊內(nèi)功能的測(cè)試 、單元測(cè)試。程序質(zhì)量的要求包括：滿足要求的確切功能處理效率高方便操作，用戶界面友好程序代碼的可讀性好，函數(shù) 、變量標(biāo)識(shí)符合規(guī)范擴(kuò)充性、維護(hù)性好 。降低程序的復(fù)雜性也是十分重要的，系統(tǒng)的復(fù)雜性由模塊間的接口數(shù)

38、來衡量，般地講，n個(gè)模塊的接口數(shù)的最大值為n(n-1)/2；若是層次結(jié)構(gòu)，n個(gè)模塊的接口數(shù)的最小值為n-1。為使復(fù)雜性最小，對(duì)?？斓膭澐衷O(shè)計(jì)常常采用層次結(jié)構(gòu)。要主意編制的程序或模塊應(yīng)容易理解、容易修改，模塊應(yīng)相互獨(dú)立，對(duì)某一模塊的修改應(yīng)其他模快的功能不產(chǎn)生影響，模塊間的聯(lián)系盡可能少。5.系統(tǒng)測(cè)試測(cè)試是為了發(fā)現(xiàn)程序中的錯(cuò)誤，對(duì)于設(shè)計(jì)的軟件，出現(xiàn)錯(cuò)誤是難免的。系統(tǒng)測(cè)試 通常由經(jīng)驗(yàn)豐富的設(shè)計(jì)人員設(shè)計(jì)測(cè)試方案和測(cè)試樣品，并寫出測(cè)試過程的詳細(xì)報(bào)告。 系統(tǒng)測(cè)試是在單元測(cè)試的基礎(chǔ)上進(jìn)行的 ，包括：測(cè)試方案的設(shè)計(jì)；進(jìn)行測(cè)試；寫出測(cè)試報(bào)告；用戶對(duì)測(cè)試結(jié)果進(jìn)行評(píng)價(jià)。具體測(cè)試方式如下：.黑盒測(cè)試黑盒測(cè)試也稱功能測(cè)試

39、，它是通過測(cè)試來檢測(cè)每個(gè)功能是否都能正常使用。在測(cè)試中， 把程序看作一個(gè)不能打開的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下， 在程序接口進(jìn)行測(cè)試，它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用， 程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。黑盒測(cè)試著眼于程序外部結(jié) 構(gòu)，不考慮內(nèi)部邏輯結(jié)構(gòu)，主要針對(duì)軟件界面和軟件功能進(jìn)行測(cè)試，黑盒測(cè)試是基于 用戶角度測(cè)試.白盒測(cè)試白盒測(cè)試又稱結(jié)構(gòu)測(cè)試、透明盒測(cè)試、邏輯驅(qū)動(dòng)測(cè)試或基于代碼的測(cè)試。白盒測(cè)試是 一種測(cè)試用例設(shè)計(jì)方法，盒子指的是被測(cè)試的軟件，白盒指的是盒子是可視的，即清 楚盒子內(nèi)部的東西以及里面是如何運(yùn)作的。白盒法全面了解程序內(nèi)部邏

40、輯結(jié)構(gòu)、對(duì)所有邏輯路徑進(jìn)行測(cè)試。白盒法是窮舉路徑測(cè)試。在使用這一方案時(shí)，測(cè)試者必須 檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測(cè)試數(shù)據(jù)。從程序設(shè)計(jì)的角度對(duì) 程序測(cè)試，可以幫助軟件測(cè)試人員增大代碼覆蓋率，提高代碼質(zhì)量，發(fā)現(xiàn)代碼隱藏問 題。.灰盒測(cè)試可以理解為靜態(tài)的白盒測(cè)試或動(dòng)態(tài)的黑盒測(cè)試，灰盒就是界于黑白之間，對(duì)軟件內(nèi)部所了解，但不見得到了如指掌的程度，卻可以結(jié)合這些了解做些比黑拿多點(diǎn)的測(cè)試。.文檔測(cè)試文擋測(cè)試涵蓋面很大，在軟件的各個(gè)版本中均有所使用。隨著軟件版本的變化，文擋測(cè)試的測(cè)試內(nèi)容也有所變化。在需求分析以及原型架構(gòu)階段，文擋測(cè)試主要目標(biāo)是Sitemap動(dòng)作分解列表、數(shù)據(jù)庫(kù)ER圖、UM

41、LH .例圖、流程圖、需求文擋等文擋。 文擋測(cè)試主要檢查文擋的正確性，完整性，和可理解性，正確性是指不要把軟件的功 能和操作寫錯(cuò)，也不允許文擋內(nèi)容前后矛盾。完整性是指文擋不可以漏掉關(guān)鍵性內(nèi)， 容?？衫斫庑允侵冈谖臋n中描述的語(yǔ)言要簡(jiǎn)明易懂，不能讓別的開發(fā)人員拿到文擋時(shí) 看不懂文擋的內(nèi)容。.命名規(guī)范測(cè)試命名規(guī)范測(cè)試用于測(cè)試項(xiàng)目的文件命名，代碼及版本號(hào)等書寫是否符合規(guī)范。.需求完整性測(cè)試需求完整性測(cè)試主要存在于需求探索階段，在需求尚未完全明確之前對(duì)已受收集到的 需求做出整理性的、檢查遺漏性的測(cè)試，確認(rèn)需求是否明確。另外，需求完整性測(cè)試 也承擔(dān)著部分澄清需求的任務(wù).鏈接完整性測(cè)試在原型架構(gòu)階段，鏈接完

42、整性測(cè)試是非常有必要的。該項(xiàng)測(cè)試任務(wù)主要是檢查假頁(yè)畫中各種鏈接是否完整，是否指向目標(biāo)位置，屬于檢查性的測(cè)試。.頁(yè)面完整性測(cè)試頁(yè)面完整性測(cè)試主要存在于集成測(cè)試階段以及其后續(xù)其它階段中，測(cè)試頁(yè)面是否完整， 頁(yè)面質(zhì)量是否達(dá)標(biāo)，屬于檢查性測(cè)試。.UI合理性測(cè)試也是人機(jī)交互界面的合理性，UI合理性測(cè)試內(nèi)容很多，具體如下：。提示、菜單、幫助的格式是否一致；。提示、菜單、幫助中的術(shù)語(yǔ)是否 致；。各個(gè)1控件之間的對(duì)齊方式是否一致；。輸入界面和輸出界面在外觀、布局、交互方式上是否一致；。功能類似的相關(guān)界面在外觀、布局、交互方式上是否一致；。同一層次的文字在同一種提示場(chǎng)合（一般情況、特殊字體、警告等） 在文字大小

43、、字體、顏色、對(duì)齊方面是否一致，字體大小是否與界面的大小比例協(xié)調(diào);。多個(gè)連續(xù)界面依次出現(xiàn)的情況下，界面的外觀、操作方式是否一致系統(tǒng)是否拒絕客戶的錯(cuò)誤輸入并做出提示；。系統(tǒng)是否在用戶完成成操作時(shí)會(huì)給出操作成功的提示；。用戶界面是否存在空白空間，沒有空白空間的界面是雜亂無章的，易用性差；.數(shù)據(jù)和數(shù)據(jù)庫(kù)完整性測(cè)試在開發(fā)階段開發(fā)人員隨時(shí)都有可能根據(jù)需要來修改數(shù)據(jù)庫(kù)，所以對(duì)數(shù)據(jù)和數(shù)據(jù)庫(kù)完整 性測(cè)試在軟件項(xiàng)目的任何階段也是非常必要的。該項(xiàng)測(cè)試內(nèi)容主要是以數(shù)據(jù)庫(kù)表為單 位，檢查數(shù)據(jù)庫(kù)表以及表中各字段命名是否符合命名規(guī)范，表中字段是否完整，數(shù)據(jù) 庫(kù)表中的字段描述是否正確包括字段的類型、長(zhǎng)度、是否為空，數(shù)據(jù)庫(kù)表

44、中的關(guān)系、 索引、主鍵、約束是否正確。.功能測(cè)試功能測(cè)試在軟件項(xiàng)目的任何階段中都是重要的。實(shí)現(xiàn)功能，滿足客戶需求是軟件本身 最大的使命。功能測(cè)試在任何階段下基本上都作為測(cè)試工作的第一項(xiàng)出現(xiàn)。該項(xiàng)測(cè)試 任務(wù)主要為了測(cè)試已實(shí)現(xiàn)的功能是否滿足需求，是否正確，是否有價(jià)值以及是否完整。 在黑盒和白盒測(cè)試狀態(tài)下，該測(cè)試均會(huì)被使用。功能測(cè)試中測(cè)試人員往往會(huì)忽略掉一些細(xì)節(jié)問題，比如：一個(gè)功能的實(shí)現(xiàn)必須要經(jīng)過6步操作才能完成，而且需要加入 20條信息才能看得出測(cè)試結(jié)果，有的測(cè)試人員為了 節(jié)省時(shí)間雖然做完了 6步操作，但是沒有加入足量的信息 ，使得測(cè)試不全面，正是因?yàn)?這樣而導(dǎo)致一些隱藏的 BUG有被測(cè)試出來。所

45、以說在功能測(cè)試中要按部就班的把所 有要進(jìn)行的測(cè)試功能每一步都執(zhí)行一遍，應(yīng)該添加的數(shù)據(jù)都添加完整，以避免遺漏掉 BUG沒有測(cè)試出來.壓力測(cè)試壓力測(cè)試是為了發(fā)現(xiàn)在什么條件下您的應(yīng)用程序的性能會(huì)變得不可接受。這通過改變 應(yīng)用程序的輸入以對(duì)應(yīng)用程序施加越來越大的負(fù)載并測(cè)量在這些不同的輸入時(shí)性能的 改變來實(shí)現(xiàn)的。這種操作也稱為負(fù)載測(cè)試，但是負(fù)載測(cè)試通常描述一種特定類型的壓 力測(cè)試一一增加用戶數(shù)量以對(duì)應(yīng)用程序進(jìn)行壓力測(cè)試。對(duì)應(yīng)用程序進(jìn)行壓力測(cè)試最簡(jiǎn)單的方法是手工改變輸入（客戶機(jī)數(shù)量、需求大小、請(qǐng) 求的頻率、請(qǐng)求的混合程度等等）并描繪性能的變化。但是如果有許多輸入，或者需 要在大的范圍內(nèi)改變輸入，那么你可以

46、借助一個(gè)自動(dòng)化的壓力測(cè)試工具來完成此測(cè)試.安全性測(cè)試安全性測(cè)試主要是測(cè)試系統(tǒng)在沒有授權(quán)的內(nèi)部或者外部用戶對(duì)系統(tǒng)進(jìn)行攻擊或者惡意破壞時(shí)如何進(jìn)行處理，是否仍能保證數(shù)據(jù)和頁(yè)面的安全。測(cè)試人員可以學(xué)習(xí)一些黑客 技術(shù)，來對(duì)系統(tǒng)進(jìn)行攻擊。另外，對(duì)操作權(quán)限的測(cè)試也包含在安全性測(cè)試中。具體測(cè)試內(nèi)容如下：執(zhí)行添加、刪除、修改等動(dòng)作中是否做過登錄檢測(cè)。退出系統(tǒng)之后的操作是否可以完成。所有插入表單操作中輸入特殊字符是否可以正常輸出正常存儲(chǔ)，特殊字符。測(cè)試表單中有沒有標(biāo)簽測(cè)試，標(biāo)簽檢測(cè)是否完整。在插入表單中加入特殊的 HTML弋碼.頁(yè)面腳本測(cè)試頁(yè)面中時(shí)常使用到JavaScript腳本，為了降低頁(yè)面的出錯(cuò)率，則必須對(duì)頁(yè)

47、面腳本 進(jìn)行測(cè)試。其主要內(nèi)容包括：相關(guān)頁(yè)面中的腳本是否正常運(yùn)行，JavaScript腳本是否有錯(cuò)誤頁(yè)面。.提示文本測(cè)試提示文本測(cè)試從嚴(yán)格意義上來講應(yīng)該屬于UI合理性測(cè)試的一部分，該項(xiàng)測(cè)試主要針對(duì)各個(gè)頁(yè)面中使用到的大量提示文檔進(jìn)行測(cè)試，主要包括：表達(dá)不明確的位置是 否有提示文本、提示文本的彈出是否正常、提示信息含義是否明確易懂。.瀏覽器測(cè)試由于B/S結(jié)構(gòu)項(xiàng)目是基于瀏覽器運(yùn)行的，所以需要對(duì)瀏覽器進(jìn)行必要的測(cè)試。該測(cè) 試任務(wù)主要是軟件對(duì)各種瀏覽器（IE5.5、IE6.0、 FireFox瀏覽器 ）的支持是 否正常，在IE瀏覽器中可以正常顯示的頁(yè)面在其它瀏覽器中是否可以正常顯示。.安裝測(cè)試在軟件項(xiàng)目的

48、后期階段，會(huì)對(duì)做好的軟件進(jìn)行打包把軟件做成安裝程序，以便用戶 可以正確的安裝使用，所以需要對(duì)做好的安裝文件進(jìn)行安裝功能方面的測(cè)試。該測(cè) 試的主要任務(wù)是：檢查軟件是否能夠正常安裝使用、是否可以完全卸載此軟件的所 有功能和頁(yè)面。6、文檔資料文檔包括開發(fā)過程中的所有技術(shù)資料以及用戶所需的文檔，軟件系統(tǒng)的文檔一般可 分為系統(tǒng)文檔和用戶文檔兩類。用戶文檔主要描述系統(tǒng)功能和使用方法，并不考慮這些功能是怎樣實(shí)現(xiàn)的，系統(tǒng)文 檔描述系統(tǒng)設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試等方面的內(nèi)容。文檔是影響軟件可維護(hù)性、可用性的 決定因素，有句話講，系統(tǒng)編程人員的每一張紙片都要保留，所以文檔的編制是軟 件開發(fā)過程中的一項(xiàng)重要工作。系統(tǒng)文檔包括

49、：軟件系統(tǒng)在計(jì)劃需求分析設(shè)計(jì)編制調(diào)試運(yùn)行等階段的有關(guān)文檔。在對(duì)軟件系統(tǒng)進(jìn)行修改時(shí)，系統(tǒng)文檔應(yīng)同步更新，并注明修改者和修改日期，如有 必要應(yīng)注明修改原因，應(yīng)切記過時(shí)的文檔是無用的文檔。用戶文檔包括：系統(tǒng)功能描述安裝文檔，說明系統(tǒng)安裝步驟以及系統(tǒng)的硬件配置方法用戶使用手冊(cè)，說明使用軟件系統(tǒng)方法和要求，疑難問題解答參考手冊(cè)，描述可以使用的所有系統(tǒng)設(shè)施，解釋系統(tǒng)出錯(cuò)信息的含義及解決途 徑。系統(tǒng)的運(yùn)行與維護(hù)系統(tǒng)只有投入運(yùn)行后，才能進(jìn)一步對(duì)系統(tǒng)檢驗(yàn)，發(fā)現(xiàn)潛在的問題，為了適應(yīng)環(huán)境的 變化和用戶要求的改變，可能會(huì)對(duì)系統(tǒng)的功能、使用界面進(jìn)行修改。要對(duì)每次發(fā)現(xiàn) 的問題和修改內(nèi)容建立系統(tǒng)維護(hù)文檔，并使系統(tǒng)文檔資料同

50、步更新。服務(wù)保證措施本公司軟件質(zhì)量保證由各項(xiàng)任務(wù)構(gòu)成，這些任務(wù)的參與者有兩種人：軟件開發(fā)人員 和質(zhì)量保證人員。前者負(fù)責(zé)技術(shù)工作，后者負(fù)責(zé)質(zhì)量保證的計(jì)劃、監(jiān)督、記錄、分 析及報(bào)告工作。軟件開發(fā)人員通過采用可靠的技術(shù)方法和措施，進(jìn)行正式的技術(shù)評(píng) 審，執(zhí)行計(jì)劃周密的軟件測(cè)試來保證軟件產(chǎn)品的質(zhì)量。軟件質(zhì)量保證人員則輔助軟 件開發(fā)組得到高質(zhì)量的最終產(chǎn)品。我們的軟件質(zhì)量保證計(jì)劃大體分為如下三大部分：,制定出質(zhì)量評(píng)審、把軟件研制合理地劃分為若干階段，并針對(duì)每個(gè)階段的特點(diǎn) 評(píng)測(cè)的要求和措施。 從軟件質(zhì)量的要求出發(fā)，制定出相應(yīng)的技術(shù)和管理規(guī)范，如軟件文檔規(guī)范、軟 件編程規(guī)范、軟件測(cè)試規(guī)范、軟件版本控制規(guī)范等。創(chuàng)

51、建和積累公用模塊，向軟件工廠化方向發(fā)展1、軟件研制的階段劃分及其質(zhì)量控制我們把軟件系統(tǒng)的研制劃分為 8個(gè)階段，即總體需求分析、總體設(shè)計(jì)、各分系統(tǒng)的 需求說明及概要設(shè)計(jì)、詳細(xì)設(shè)計(jì) （面向子系統(tǒng)）、程序編制、自測(cè)試、組裝與驗(yàn)收測(cè) 試、試用和初步定型。我們規(guī)定，總體需求分析及總體設(shè)計(jì)需經(jīng)有關(guān)領(lǐng)導(dǎo)及管理專家評(píng)審認(rèn)定。分系統(tǒng)的 需求說明、概要設(shè)計(jì)及詳細(xì)設(shè)計(jì)需經(jīng)總工程師組織的技術(shù)評(píng)審組評(píng)審。評(píng)審前，多 數(shù)分系統(tǒng)的需求說明及概要設(shè)計(jì)需經(jīng)有代表性的用戶審核認(rèn)可，即分析和設(shè)計(jì)階段 主要靠評(píng)審把關(guān)，編程和實(shí)施階段主要靠執(zhí)行規(guī)范和測(cè)試把關(guān)。每次評(píng)審的結(jié)果都 有相應(yīng)的記錄，并填寫相應(yīng)的表格。軟件的文檔規(guī)范系統(tǒng)開發(fā)的文

52、檔要求是：每個(gè)分系統(tǒng)必須有需求說明、概要設(shè)計(jì)，每個(gè)子系統(tǒng)必須有 詳細(xì)設(shè)計(jì)和操作使用說明。需求說明、概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)必須串行完成，而且規(guī)定， 詳細(xì)設(shè)計(jì)未經(jīng)評(píng)審?fù)ㄟ^不能進(jìn)入正規(guī)編程。不寫設(shè)計(jì)就進(jìn)入編程，這是軟件開發(fā)人員 常犯的毛病，在我們的系統(tǒng)開發(fā)中這是不允許的。軟件編程規(guī)范開發(fā)中所有設(shè)計(jì)文件經(jīng)過認(rèn)真的評(píng)審、推敲和認(rèn)定后，軟件編程將是保證軟件質(zhì)量的 一個(gè)重要環(huán)節(jié)。為保證這一環(huán)節(jié)的質(zhì)量，我們專門制定了編程的有關(guān)規(guī)范。其中最主 要的是界面規(guī)范。需要強(qiáng)調(diào)的是，對(duì)界面的理解不應(yīng)只限于屏幕格式和操作方法，界面設(shè)計(jì)應(yīng)貫穿于軟 件編制的全過程，我們的界面規(guī)范分為兩大部分：第一部分是設(shè)計(jì)原則，包括：一般原則、屏

53、幕格式設(shè)計(jì)原則、輸入過程設(shè)計(jì)原則、信 息顯示設(shè)計(jì)原則、提示信息設(shè)計(jì)原則、報(bào)表設(shè)計(jì)原則、菜單設(shè)計(jì)原則、操作方法原則。 它重點(diǎn)解決操作的方便性和直接性、顯示和提示的確定性、輸入的準(zhǔn)確性、輸入輸出 的一致性，以保證對(duì)用戶習(xí)慣和心理的良好適應(yīng)性，給用戶一種愉快感，讓用戶產(chǎn)生 一種喜愛感。特別是在服務(wù)器模式下工作的系統(tǒng)，編程時(shí)對(duì)處理和數(shù)據(jù)的合理分布將直接影響到 系統(tǒng)資源利用得是否充分、恰當(dāng)，直接影響到整個(gè)系統(tǒng)的性價(jià)比。它包括：對(duì)象和控制命名規(guī)范、編程風(fēng)格、數(shù)據(jù)校驗(yàn)、環(huán)境配置與應(yīng)用的可移植性、 事件驅(qū)動(dòng)、面向?qū)ο?、?shù)據(jù)庫(kù)訪問規(guī)范、數(shù)據(jù)及處理分布、出錯(cuò)處理、安裝及設(shè)置。實(shí)踐證明，這一規(guī)范對(duì)保證程序質(zhì)量、提高

54、軟件重用度，進(jìn)而對(duì)提高編程效率、乃至提高系統(tǒng)的可靠性均起了重要作用。4、軟件測(cè)試規(guī)范軟件測(cè)試是在設(shè)計(jì)階段保證軟件質(zhì)量的最后一關(guān)。從測(cè)試手段來說，我們把整個(gè)測(cè)試 分為白盒測(cè)試和黑盒測(cè)試，并在軟件編制過程中交叉使用。指派對(duì)開發(fā)工具認(rèn)識(shí)最深 入、編程經(jīng)驗(yàn)最豐富的同志從事白盒測(cè)試；指派對(duì)工作流程最熟悉、對(duì)操作使用研究 和體會(huì)最細(xì)致的同志從事黑盒測(cè)試。從測(cè)試過程來說，又分為兩步：自測(cè)試和組裝驗(yàn) 收測(cè)試。自測(cè)試是軟件編制者自己設(shè)計(jì)測(cè)試用例，自己驗(yàn)證；組裝和驗(yàn)收測(cè)試則是按 照需求說明和工作流程全面設(shè)計(jì)測(cè)試案例，進(jìn)行全面測(cè)試。工作流程、數(shù)據(jù)流程、各 子系統(tǒng)之間及各模塊之間的接口是驗(yàn)收測(cè)試的重點(diǎn)之一。整個(gè)測(cè)試階

55、段必然是一個(gè)發(fā)現(xiàn)問題一修改完善一再測(cè)試的過程，而且可能多次反復(fù)。 此時(shí)，最重要的是要把握住兩點(diǎn)：一是每提出一個(gè)修改，都需經(jīng)過總體設(shè)計(jì)師和分系 統(tǒng)設(shè)計(jì)者的認(rèn)真研究討論，既要保證軟件的正確性、流程的合理性和功能的完備性， 又要保證總體設(shè)計(jì)思想和軟件設(shè)計(jì)風(fēng)格不受破壞，即保證軟件的整體質(zhì)量；二是程序 編制者和測(cè)試者都要有足夠的耐心和良好的協(xié)作精神，都要有對(duì)軟件質(zhì)量負(fù)責(zé)的責(zé)任 感。無論自測(cè)試，還是組裝及驗(yàn)收測(cè)試，都是極其細(xì)致而又繁瑣的過程。不少技術(shù)人員愿 意搞設(shè)計(jì)和編程，而不愿在測(cè)試方面多花功夫。軟件開發(fā)的管理者對(duì)這種傾向需嚴(yán)密 注視、盡力防范，同時(shí)應(yīng)做出具體規(guī)定，作為軟件設(shè)計(jì)的法規(guī)，要求大家嚴(yán)格遵守。

56、 測(cè)試規(guī)范的概要如下在自測(cè)試階段制定了自測(cè)試方法和自測(cè)試過程。自測(cè)試方法重點(diǎn)規(guī)定了兩點(diǎn)：一是白盒測(cè)試、人工審查與機(jī)器執(zhí)行相結(jié)合；二是給出 了測(cè)試用例設(shè)計(jì)原則，即模塊內(nèi)部和模塊間的測(cè)試用例設(shè)計(jì)原則及重點(diǎn)檢查的內(nèi)容。 自測(cè)試過程分為代碼審查、模塊測(cè)試、組裝測(cè)試和整理測(cè)試報(bào)告四個(gè)過程。規(guī)范中詳 細(xì)規(guī)定了每一過程的細(xì)節(jié)和要求。組裝及驗(yàn)收測(cè)試規(guī)范中同樣規(guī)定了測(cè)試方法和測(cè)試 過程。其中，重點(diǎn)強(qiáng)調(diào)三點(diǎn)：一是再次推敲流程是否合理，功能是否齊全；二是測(cè)試用例設(shè) 計(jì)必須考慮如下幾方面要求：功能測(cè)試、性能測(cè)試、大數(shù)據(jù)量測(cè)試、可靠性測(cè)試、可 恢復(fù)性測(cè)試、多用戶測(cè)試、安裝測(cè)試和配置測(cè)試；三是要重視模塊和子系統(tǒng)之間的接

57、口測(cè)試。軟件版本控制版本控制是對(duì)已做成的軟件在發(fā)展過程中的一種質(zhì)量管理，各大公司對(duì)自己的軟件均 有一套版本控制方法。我們開發(fā)的軟件系統(tǒng)絕不是“一錘子買賣”，推出了第一期軟 件的試用版，還會(huì)有第二期軟件補(bǔ)充進(jìn)來，兩期軟件到一定階段都將定為正式版，而 且今后還會(huì)繼續(xù)發(fā)展，到一定時(shí)候還要更新。何時(shí)定為正式版，何時(shí)宣布版本升級(jí)， 都需要有明確的要求和界限，兩個(gè)版本之間的任何修改和維護(hù)都需要一套管理辦法。 升級(jí)也好，更新也好，都需要考慮與原來版本的兼容，以保護(hù)用戶的投資利益建立公共模塊，向工廠化方向發(fā)展盡管一套軟件系統(tǒng)可分為若干分系統(tǒng)和子系統(tǒng)，但它們?nèi)詴?huì)有一些共同或類似的操作。 將共同操作抽取出來，制成

58、若干公用模塊，供各子系統(tǒng)調(diào)用或直接使用，這不僅可提 高軟件的編程效率，也直接提高了軟件質(zhì)量。這雖屬于總體設(shè)計(jì)和總體規(guī)劃中的工作, 但從質(zhì)量管理的角度重視這一工作，把它作為軟件質(zhì)量保證的一項(xiàng)措施，也很有意義。技術(shù)培訓(xùn)計(jì)劃1、概述人員培訓(xùn)作為工程實(shí)施的一個(gè)重要環(huán)節(jié)，對(duì)整個(gè)項(xiàng)目的實(shí)施至關(guān)重要，通過系統(tǒng) 的培訓(xùn)，使得工作人員得到日常工作需要的專業(yè)技術(shù)知識(shí)和經(jīng)驗(yàn)，從而保障整個(gè) 系統(tǒng)的順利運(yùn)行。項(xiàng)目建設(shè)最終系統(tǒng)將交付用戶使用，項(xiàng)目培訓(xùn)是項(xiàng)目實(shí)施中的重要環(huán)節(jié)，通過項(xiàng) 目培訓(xùn)對(duì)業(yè)主人員進(jìn)行全面的技術(shù)培訓(xùn)，使業(yè)主單位人員達(dá)到能獨(dú)立進(jìn)行管理、 故障處理、日常測(cè)試維護(hù)等工作，以便于我方提供的軟、硬件能夠正常、安全的

59、 運(yùn)行。培訓(xùn)的總體目標(biāo)：1、管理員培訓(xùn)。培訓(xùn)對(duì)象：系統(tǒng)管理員。培訓(xùn)目的：可以獨(dú)立完成本單位行政執(zhí)法的日常維護(hù)，解決一般問題。培訓(xùn)內(nèi)容：系統(tǒng)體系結(jié)構(gòu)、系統(tǒng)配置、系統(tǒng)管理、系統(tǒng)使用。培訓(xùn)方式：集中培訓(xùn)和個(gè)別培訓(xùn)。培訓(xùn)批次：不少于1次的集中培訓(xùn)，個(gè)別培訓(xùn)隨時(shí)安排。2、使用人員培訓(xùn)培訓(xùn)對(duì)象：系統(tǒng)一般使用人員。培訓(xùn)目的：熟練掌握所涉及部分的操作。培訓(xùn)內(nèi)容：系統(tǒng)使用。培訓(xùn)方式：集中培訓(xùn)和個(gè)別培訓(xùn)。培訓(xùn)批次：不少于2次的集中培訓(xùn)，個(gè)別培訓(xùn)隨時(shí)安排2、培訓(xùn)對(duì)象如果項(xiàng)目是一項(xiàng)綜合型的項(xiàng)目，系統(tǒng)使用范圍廣，用戶層次多，不同用戶層次使 用的系統(tǒng)角色不相同，使用的內(nèi)容和側(cè)重點(diǎn)各不相同，那么我們?cè)陧?xiàng)目中將針對(duì)不同的 用

60、戶層次提供針對(duì)性的用戶培訓(xùn)，保障培訓(xùn)效果，使各層次的用戶都能熟練掌握 系統(tǒng)相關(guān)的知識(shí)。普通用戶層普通用戶層是應(yīng)用系統(tǒng)的直接使用者，涉及到系統(tǒng)的各方面功能，是對(duì)系統(tǒng)功能 理解最深、業(yè)務(wù)最熟悉的用戶群，然而普通用戶層由于覆蓋的面廣，各部門主要 使用的功能模塊不盡相同，因此針對(duì)于普通用戶將按照不同的部門的側(cè)重點(diǎn)進(jìn)行 分期培訓(xùn)，組織類似業(yè)務(wù)部門或單獨(dú)部門進(jìn)行培訓(xùn)，以便于各部門對(duì)各自業(yè)務(wù)系 統(tǒng)使用的把握，以達(dá)到各用戶能熟練掌握系統(tǒng)的使用方法。系統(tǒng)管理員和應(yīng)用級(jí)管理員系統(tǒng)管理員和應(yīng)用級(jí)管理員是業(yè)主單位對(duì)系統(tǒng)進(jìn)行管理維護(hù)的主要人員，這一用 戶群掌握一定的信息技術(shù)，并且針對(duì)應(yīng)用系統(tǒng)管理員和平臺(tái)維護(hù)員分別進(jìn)行針