變電站綜合管理信息系統的設計方法_secret_第1頁
變電站綜合管理信息系統的設計方法_secret_第2頁
變電站綜合管理信息系統的設計方法_secret_第3頁
變電站綜合管理信息系統的設計方法_secret_第4頁
變電站綜合管理信息系統的設計方法_secret_第5頁
已閱讀5頁,還剩4頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、PAGE PAGE 9變電站綜合管理信息系統的設計方法摘 要:本文主要介紹基于Web的分布式結構的變電站綜合信息管理系統。從系統設計原則和設計思路、設計方法和設計流程、設計內容和設計特點等幾個方面闡述了變電站綜合管理信息系統的設計方法。關鍵詞:Web的分布式系統 變電站 管理信息系統 設計方法1概述管理信息系統(ManagementInformationSystem,簡稱MIS)在現代社會已經深入到各行各業,MIS是一個不斷發展的新型學科,MIS的定義隨著計算機和通訊技術的進步也在不斷更新。隨著信息時代的來臨,電力行業傳統的管理方式已經無法滿足我國經濟的迅速發展和居民生活水平提高的需要。要提高

2、供電質量和供電可靠性,改變電力系統的基本供電單位變電站的供變電質量是解決這個問題的必由之路。要提高一個企業的生產質量,首先要提高企業的管理水平。因此,變電站綜合管理信息系統的建設已經成為建設和改造城市電網的首要任務。 變電站管理是一項復雜、枯燥、安全性要求高,制度嚴格,邏輯結構復雜,重復性大的業務。特別對于各變電站分布在不同的地區,變電站人員的文化素質參差不齊,各項記錄以及工作票、操作票要求嚴格來講,人工處理這項業務顯得工作繁重,而且容易出錯,給變電站管理造成不便。目前的變電站及其上級部門變電工區之間存在的問題是由于信息過度分散管理而造成信息資源的浪費和資源短缺共存的現狀,一方面變電工區對變電

3、站信息資源的收集,目前還處于手工方式,信息的可靠性,準確性低,需要采用自動化管理方式提高管理水平。另一方面。各變電站與工區的信息存貯處于孤立狀態,這與電力系統所要求的達到各個部門之間密切配合,職能獨立又相互配合的要求是脫節的。 針對這種情況,開發出一套適用于變電站的綜合信息管理系統具有重要的現實意義和經濟價值。本系統采用了基于Web的分布式系統作為變電站綜合管理信息系統的解決方案。基于Web的分布式系統具有優越的系統特性,即整體性、目的性、層次性和耦合性、動態適應性。Web分布式系統結構具有很多傳統Client/Server結構不具備的優點,而且又緊密結合了Internet/Intranet技

4、術,是技術發展的大勢所趨。變電站綜合管理信息系統采用基于Web的分布式系統作為解決方案,不僅符合了用戶的需求,也符合了未來的發展趨勢。2系統的設計2.1設計原則 對變電站綜合信息管理系統總的設計原則是:統一規劃、分步實施、追求合理、突出實用。統一規劃:從計算機網絡結構,數據庫規劃,應用系統規劃以及系統的實用性、可擴展性上進行統一規劃,以使變電站的管理水平能夠在一定投資的基礎上向前邁進一大步。分步實施:在完成對變電站MIS建設的基礎上進行完善和改進,再根據各變電站的實際情況推廣到各變電站去。追求合理:在系統設計開發過程中,將盡力追求軟件系統結構的合理性、處理流程的合理性以及軟件所體現的管理思想的

5、合理性。突出實用:在進行設計開發時,必須把軟件的實用性放在突出地位,強調系統的可用性、可靠性、安全性和易操作性。2.2設計思路基于Web的變電站綜合管理系統的設計是一個不斷改進和反饋的過程。圖2-1是進行基于Web的變電站綜合管理信息系統的設計思路圖,圖中虛線表示反饋,在每一個過程都可能對前面的過程產生反饋。2.2.1系統界定拿到一個系統,我們首先必需對系統進行界定,即劃分系統的范圍,分析系統與其他系統之間的關系、系統與環境的關系。這個過程產生對系統的一個清晰的描述,確定所研究的問題。2.2.2系統規劃、分析和方案設計針對一個已經界定清楚的系統,下面的工作便是進行系統的規劃、分析及方案設計。在

6、這個過程中,首先對系統進行規劃,進行子系統的劃分和系統的實施計劃的設計,同時對系統進行分析,這些分析包括系統的特性和結構的分析、需求分析、系統的可行性分析等內容,系統規劃和分析經常交織在一起。另外,在這個階段還完成系統方案的設計和選擇工作。2.2.3系統概要設計系統概要設計主要是對系統業務進行流程分析,完成系統的設計以及系統的功能劃分和初步設計,并對系統具體結構和技術方案進行設計。2.2.4系統詳細設計系統詳細設計包括數據流的設計、數據庫的設計、系統模塊的詳細設計、界面設計、程序流程的設計等內容。2.2.5代碼開發代碼開發是按照詳細設計的要求進行代碼的編寫工作。2.2.6系統測試系統測試是在系

7、統投入使用前,對系統的需求分析、設計規格說明和編碼的復審。2.2.7系統修改、運行和維護維護系統的運行,保證系統有效、可靠的運轉。2.2.8系統評價和總結對系統的完成和運行情況進行評價,總結系統開發過程中的得失,有些好的體會、思想和資源可以累積下來,并且這個過程還可以對系統的改進和再設計進行分析。實際上,以上這些過程并不是要求嚴格按順序的,前后過程之間存在反饋,這些過程之間并不一定存在明顯的界限。3設計方法和設計流程3.1設計方法應用系統的設計方法一般有結構化設計方法和面向對象的設計方法。具體采用什么樣的系統設計方法跟具體的應用實際情況有關,同時也和系統的體系結構有關。而且結構化設計方法和面向

8、對象的方法并不是互相排斥的,這些方法可以根據實際情況進行組合。在基于Web的分布式系統結構中,應用層是連接表示層和數據層的中介,同時也是業務流程和業務邏輯的具體實現所在的層。因此,應用層的設計是基于Web的分布式應用系統設計的中心。在基于Web的分布式系統的結構中,應用層又可被分為工作流層和業務邏輯層,其中工作流層的設計一般適合于結構化的設計方法,而業務邏輯層很多時候可以采用面向對象的設計方法。因此基于Web的分布式應用系統可以采用結構化的設計方法和面向對象的設計方法的組合。結構化的思想主要是基于把一個復雜的問題劃分為許多可對付的子問題。令C(X)是確定問題X復雜程度的函數,E(X)是決定解決

9、問題X所需的工作量的函授。對于兩個問題P1和P2,如果:C(P1)C(P2),那么顯然有:E(P1)E(P2)。依據人類解決問題的經驗,如果一個問題由P1和P2組合而成,那么它的復雜程度大于分別考慮每個問題時的復雜程度之和。即:C(P1+P2)C(P1)+C(P2),最后有:E(P1+P2)E(P1)+E(P2)。在大型的應用系統中,采用結構化的方法比較容易進行系統的分析,但是面向對象的方法比較容易解決軟件的重復使用問題,并且開發效率高。因此針對具體的應用可以先以結構化的方法將系統分為小系統,然后采用面向對象的方法對其中重要的業務邏輯進行設計,這樣可以綜合結構化設計方法和面向對象的方法對其中重

10、要的業務邏輯進行設計。而在實際系統中,結構化思想和面向對象的思想經常結合在一起。在基于Web的分布式應用中采用結構化設計方法和面向對象的方法相結合的原因還在于基于Web的應用系統的特性。在基于Web的應用系統中,功能的實現一般以動態頁面的集合形式實現,具體的業務流程步驟一般與這些動態頁面相對應,這種方式更符合過程化的思想,因此采用結構化設計方法是符合習慣的,但每個頁面中以結構化的代碼來處理復雜的邏輯是不可取的,這時可以采用面向對象的設計方法來設計,這種結構化設計方法和面向對象的設計方法的結合在基于Web的分布式應用系統中是比較自然的。3.2設計流程基于Web的分布式應用系統比較適合軟件生命周期

11、模型中的演化模型和噴泉模型的思想。但是軟件生命周期各種模型提供的僅是指導思想,具體的應用系統的設計流程應根據具體情況對軟件生命周期模型中的具體模型進行改造和組合。從實際角度出發,圖3-1所示的基于Web的分布式應用系統的設計流程是在本系統的實際應用中的一個設計流程。在這個流程中各個設計工作之間關聯緊密,體現了設計過程中不斷Review和改進的過程,是噴泉模型思想的體現。基于Web的分布式應用系統采用圖3-1所示的設計流程基于以下理由:(1)系統認識的漸進過程:人們對一個系統的認識是一個漸進的過程,隨著設計過程的不斷發展,人們會對系統的認識不斷加深,在設計的后期發現前期設計的一些問題,這需要返回

12、修正。這個構成可能是一個循環的過程。令系統設計頭疼的一個問題就是需要常常處于一個不斷變化的狀態,這種變化包含的因素很多,例如問題域本身在系統的開發過程中發生了變化;用戶在立項的時候可能對需求提的不完全或者不恰當,他們隨著系統的開發而逐漸成熟,常常補充和更改早期提出的要求。(2)因交流而產生新的創意:系統的設計需要大量的人與人之間的交流,這些交流包括和分析人員的交流、分析人員和用戶之間的交流、用戶和領域專家的再交流等等,這些交流產生火花,而其中有些是特別有價值的或必需的。(3)盡早避免設計錯誤:將設計錯誤代入到代碼階段會產生嚴重的后果,因此設計過程本身就是一個不斷Review的過程,中間也伴隨著

13、許多討論和爭議,顯然在這個過程中可能會發現設計不合理的地方,這時需要對原有設計進行修改。(4)基于Web的分布式應用系統需要創造性發揮:由于基于Web的分布式應用系統提倡靈活,而且其處理方式多樣,在設計過程中很難將所有的細節都考慮的面面俱到,因此在某些方面留有創造性空間。3.3設計內容和特點基于Web的分布式應用系統的設計和一般的應用系統的設計在大部分方面是一致的,但是由于基于Web的分布式應用系統結構的特殊性,在某些方面有自己的特色,本節的重點是針對基于Web分布式應用系統的特殊部分討論有關的內容和特點。3.3.1統結構和方案設計系統結構和方案的設計主要包含以下內容:(1)應用系統的子系統的

14、劃分;(2)應用系統的應用平臺和開發平臺的選擇;(3)應用系統的技術方案的選擇;即,在有了需求之后,應該先描述出系統的大致輪廓,進行子系統的劃分,并針對需求進行技術方案的選擇和論證。在基于Web的分布式應用系統中,應用平臺多樣,技術方案和開發平臺也有多種選擇,但是具體采用哪一種方案不僅需要具體的需求、未來的規劃和技術發展趨勢,而且還得考慮許多非技術因素,如資金、項目周期以及人力等因素。選擇不同的技術方案和開發平臺不僅會對以后的代碼開發產生決定性影響,而且還會對應用系統的架構和設計思想產生重大影響。因此在這一步做出抉擇要仔細論證。3.3.2業務流程和數據流程的設計由于基于Web的分布式應用系統一

15、般是以頁面為單元組織的,因此業務流程和數據流程設計一般采用結構化方法。在數據流的設計中,基于Web的分布式應用系統的客戶端本身不能直接訪問數據庫,它是通過Web服務器為中介進行訪問的,所以在數據流程中應考慮客戶端不能直接從數據庫中獲取數據,而要以Web應用層為中介。3.3.3數據庫的設計在數據庫的設計上,基于Web的分布式應用系統與一般的應用系統基本相同。3.3.4頁面結構和功能設計頁面結構和功能設計主要完成:進行系統功能劃分,按照數據流程圖映射頁面集合,并按照系統功能建立一定的目錄結構并形成約定,以便頁面集合的管理。3.3.5接口設計接口設計主要是對基于Web的分布式系統的表示層和應用層之間

16、的數據接口的設計,包括頁面之間數據傳遞的問題,同時接口設計也包括了應用層中工作流程和業務邏輯層之間的接口設計。在基于Web的分布式應用系統中,Web服務器是無狀態的服務器,一般不保留客戶信息。在這種結構下,解決跨頁面數據傳遞的一種方案是將數據保存在客戶頁面(例如采用隱藏域、Cookie、URL后加參數等方法),然后由客戶端提交給服務器;另一種解決方案是一些應用服務器提供了保存會話(Session)和應用(Application)變量的功能,采用這種方式也能解決跨頁面數據傳遞。采用服務器端的會話和應用變量簡單,但是會話和應用變量是全局變量,增加了頁面之間的耦合性。3.3.6頁面設計頁面設計實際上

17、是系統與用戶之間的接口,也是控制和選擇信息輸入輸出的主要途徑。頁面設計規定頁面的布局、風格、色彩等約定,頁面設計應該堅持友好、簡單、實用、易于操作等原則。3.3.7代碼編寫代碼編寫實際上是具體實現系統的功能,在基于Web的分布式應用系統中,代碼可以是CGI、ISAPI和JavaServlet等代碼,也可以是ASP、PHP、JSP、ASP.NET等動態腳本代碼,具體取決于實際情況和技術方案的設計。3.3.8業務邏輯設計業務邏輯是應用系統中具有穩定一致的業務規則,而且這個規則又是不易改變的部分。在基于Web的分布式應用系統中,業務邏輯可以在設計前前確定,也可以在設計過程中進行分析來提取業務邏輯。業務邏輯一般通過組件的方式實現,采用面向對象的方法設計。然而,在一般的中小型系統中,簡單的業務邏輯也可以通過數據庫的存儲過程來實現。4總結 由于基于Web的分布式系統的特性,我們一般采用結構化的設計方法和面向對象的設計方法相結合的方法進行基于Web的分布式應用系統的設計。由于需求常常處于不斷變化的狀態,加上人們對系統理解的不完善,系

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論