基於層次體系結構的管理資訊系統設計與實現
1. 引言
隨著經濟全球化的程序和市場競爭的加劇, 商務環境的變化正深刻影響著企業組織管理的各方面. 資訊系統作為現代企業管理系統的重要組成部分, 也正面臨著前所未有的挑戰. 一方面, 資訊科技的發展要求企業進行流程重組, 創造性的應用資訊科技, 另一方面, 在企業組織變化的條件下, 敏捷製造、虛擬企業、大規模客戶定製等新的生產模式也對企業資訊系統提出了更高的要求.
在新的市場環境下, 企業的管理業務處在不斷變化的過程中, 而資訊系統一經開發完成, 就具有相對穩定性, 難以滿足企業管理變化的需要.同時隨著計算機技術的迅速更新、軟體開發競爭的日趨激烈已經使傳統的從源**級開發軟體系統的方法面臨越來越大的挑戰。利用傳統開發方法開發的大多數系統所使用的是在開發初始時所能得到的技術, 面向的是當時所需處理的問題, 要使這些軟體系統適應處理物件如業務過程的變化以及計算機技術的進步是一件非常複雜的工作, 往往必須對原有系統在**上進行重大修改, 這種修改代價較高並且也有一定的風險, 從而造成軟體的可擴充性較差。
在開發過程中, 為減少軟體開發費用、縮短軟體開發周期, 保持開發者的技術水平變得越來越重要, 因為只有這樣才能達到乙個較高的開發效率, 使得專案按時完成。而在傳統的開發方法中, 由於開發不同的軟體時常需要不同的開發工具, 這使得開發者必須不斷學習新的開發工具, 原有的技巧以及已具備的經驗難以被再次利用。當今的軟體開發經常需要利用現有成果, 開發時可能要整合不同的系統、新的應用、標準的軟體包以及已在業務開展中使用了的與任務有關的現有資料與系統, 通過整合可以減少不必要的工作量, 提高軟體的可用性, 加快開發進度。
但是傳統的**開發方法主要著眼於從無到有的構造, 對軟體整合的支援不夠, 大量的開發時間被投入到底層程式設計中, 這種程式設計不僅耗時而且可能是重複勞動, 從長遠看還會造成**難於維護。
計算機應用系統的日益複雜和龐大，使得軟體體系結構的研究成為當前的研究熱點。軟體體系結構設計已經成為軟體生命週期中的乙個重要環節。隨著軟體系統越來越大，越來越複雜，軟體設計的核心已經轉移到乙個新的計算模式，而遠非傳統的「程式=演算法+資料結構」，這個新的模式就是系統的總體結構的設計和規範。
2.層次體系的設計
本文研究了資訊系統結構的層次性和管理的層次性的關係。層次體系的設計軟體體系結構為軟體系統提供了乙個結構、行為和屬性的高階抽象, 由構成系統的元素的描述、這些元素的相互作用、指導元素整合的模式以及這些模式的約束組成。軟體體系結構不僅指定了系統的組織結構和拓撲結構, 並且顯示了系統需求和構成系統的元素之間的對應關係, 提供了一些設計決策的基本原理.
管理資訊系統是乙個以人為主導, 利用計算機硬體、軟體、網路通訊裝置以及其他辦公裝置, 進行資訊的收集、傳輸、加工、儲存、更新和維護, 以企業戰略競優、提高效益和效率為目的, 支援企業高層決策、中層控制、基層運作的高度整合化的人機系統。
從軟體系統體系結構設計的角度出發, 管理資訊系統主要特點有:(1) 問題領域龐大、複雜、易變, 軟體系統體系結構受問題領域的影響較大。(2) 系統構件之間的互動關係複雜、多變, 然而這些關係卻恰恰是管理資訊系統軟體體系結構設計的基礎, 因此必須能夠有效地把握系統構件之間的關係。
(3) 管理資訊系統構件之間存在很多的相似, 系統構件重用的可能性特別大。(4) 管理資訊系統軟體是從資訊管理的角度抽象問題領域的模型, 因此問題領域模型決定了管理資訊系統軟體系統模型。如何抽象問題領域模型來建立軟體模型, 從而更好地管理兩者之間的關係, 是管理資訊系統軟體體系結構設計成功的關鍵。
對於軟體專案的開發來說, 乙個清晰的軟體體系結構是首要的。然而, 在系統開發的初始階段就設計好系統的最終結構是不可能的, 也是不現實的, 因為需求還在不斷地發生變化。所以, 乙個好的軟體體系結構應該可以建立或再建立功能、使用者介面和問題域模型, 進化原型以滿足新的軟體需求。
層次式軟體體系結構是把大型軟體系統按照功能的擴充套件性, 分成若干層。為了使開發人員在開發軟體時對系統體系結構有乙個清晰的把握, 不至於將一大堆工作混雜在一起而造成系統的維護困難, 我們利用層次軟體體系結構來對系統進行層次化的分類。軟體系統的最終目標是完成目標系統需求所要求完成的任務。
系統的各個組成部分在系統中扮演不同的角色, 完成不同的任務, 它們組合在一起共同完成軟體系統的所有任務。其中有些部分實現比較底層的操作, 比如與資料庫打交道; 有些部分實現某一類資料結構的基本操作, 比如棧、佇列的操作等; 還有些部分是專門與系統的終端使用者進行互動, 讀取使用者輸入資訊, 將結果反饋給使用者等。這些不同部分之間有可能是純粹的聚集關係, 它們在一起只是因為系統需要它們各自的功能來完成不同的任務。
另外一種關係就可能是層次關係, 實現底層操作的部分為實現較高層操作的部分提供服務。有了底層的基本服務,高層操作就只需要關心本層必須完成的任務。對於底層的操作,它只需要明確定義可以提供給高層的服務介面即可, 其內部可以採用不同的實現方法, 層與層之間是完全透明的, 它們只通過層間的服務介面進行互動。
在對軟體系統進行分析後首先對它的所有功能進行層次化劃分, 然後對每乙個層次的功能進行模組化分解。乙個層次中可能有多個模組具有相似的功能, 對這些模組進行更深層次的劃分, 將相同部分提取出來作為低一層次來對待, 而上層的不同部分就劃分到不同模組中。這樣的層次劃分和模組化分解一直進行下去, 直到系統所有功能都有乙個明確的模組歸屬為止。
這種軟體系統的分解採用先水平後垂直的劃分方法, 層與層之間的界限是明確的, 但層中的模組內部可能要進行進一步的劃分, 這是乙個反覆迭代的遞迴分解過程。至於為什麼不採用先垂直後水平的劃分方法是因為先垂直後水平的方法與傳統的" 自上而下, 逐步求精"方法類似, 這種方法不易識別系統底層的公共操作, 減少了底層模組的復用機會, 容易造成不必要的重複開發。在對軟體系統進行先水平後垂直的分解過程中, 可能會發現同一層不同模組的內部模組中有功能相似的子模組, 對於這種情況需要將它們的公共部分進行提取, 然後對初始的層次劃分進行調整, 將公共部分作為它們的下乙個層次, 當前層次只需要去訪問公共部分提供的服務。
完成軟體系統的分解後, 首先按照各模組對上層提供的服務來定義它與上層模組之間的介面。定義好層與層之間的服務介面後, 就可以對各個模組進行獨立的設計了。有了這種先進行層次化分解再進行獨立設計的方法, 軟體開發人員就可完全按照各模組的設計進行獨立的開發, 這樣就不會再出現將多個層次的東西揉合在一起的情況。
為了明確層次化軟體構造過程中不同構件所處的層次, 依照軟體系統的層次分解思路將構件歸屬於如下三個層次:
第一，資料操作層構件: 這類構件與資料庫打交道, 其主要功能是完成對資料庫操作。劃分這一層構件的目的是用這一層的構件來遮蔽底層資料庫操作的複雜性和多樣性, 為上層應用提供統一或資料庫操作服務介面。
第二，業務層構件: 這一層構件有兩種, 一種是用於公共服務, 一種是用於特定領域操作。公共服務構件專注於提供常見問題的高效解決演算法, 同時提供與作業系統相關的公共服務, 比如檔案讀寫、目錄管理、報表製做等。
它還對一些通用資料結構提供常見的操作支援。這類構件支援水平復用, 也就是說各種軟體系統都可能使用它們提供的服務, 從而避免重複勞動, 節省軟體開發時間; 避免重複開發過程中引入錯誤, 提高軟體產品質量。特定領域構件與實際的應用領域密切相關。
首先需要領域專家對該領域作廣泛深入的調查研究, 進行領域分析, 蒐集各種資料, 最後為各個構件界定範圍。
第三，表示層構件: 這類構件與軟體系統的終端使用者打交道, 所以稱為使用者介面構件。提供使用者介面操作服務, 可以說它們也屬於公共服務這一類。
但由於這些服務有許多自身的特點, 所以將它作為單獨的使用者介面層構件來討論。當前視覺化開發環境中已經提供了大量的介面構件, 為軟體系統的介面開發提供了有力支援。可以對這些介面構件進行組合、改進, 開發不僅使終端使用者感覺友好, 而且使開發人員更易於使用的大粒度使用者介面構件。
這個構件層次是乙個大粒度的劃分, 它們之間不具有嚴格意義上的上下層關係, 在各個層次構件的內部層次劃分中才能看到明顯的上下層依賴關係。乙個軟體系統的層次化構造在粗粒度角度看是這個層次構件的聚集, 當從細粒度角度, 即從內部去觀察軟體系統時, 就可以看到內部明顯的層次關係。之所以提出基於構件的層次化軟體構造是因為構件技術在很大程度上能使軟體復用思想得到具體應用。
採用基於構件的技術, 有利於系統可擴充套件性能的提高, 使系統具有更大的靈活性。當完成乙個軟體系統所有構件的開發後, 系統整合只須按照系統需求將構件組合起來。要新增或刪除系統功能只須將相關構件加入或從系統中去除就行了。
這大大減輕了軟體系統的維護負擔, 並在很大程度上保證了軟體系統的可伸縮性, 為開發類似產品或系列產品提供了有力的支援。
層次軟體體系結構框架
3、系統設計
本系統圖書管理系統主要分成了，圖書系統維護、圖書採購、圖書編目、圖書流通、期刊管理和幫助部分。這幾部分的操作與資料庫和表結構相關。通過與資料庫的連線實現web的查詢。
3.1 系統的功能
本系統的功能目標：建立網上圖書查詢、圖書預約模式。借助於學院校園網"在學院現有**上加入鏈結頁面實現圖書、期刊查詢、借書情況查詢、圖書預約，通過學院校園網為讀者提供更多的資訊服務；2、規範圖書管理工作模式，用計算機管理取代以往的手工作業和定性管理模式，使圖書管理工作模式規範化、機讀資料格式標準化、管理決策科學化；3、提高圖書館的服務質量。
便於工作人員準確地掌握藏書結構，全面了解讀者對文獻資訊的需求，及時調整採購計畫，突出館藏特點。
通過對國內現有的一些圖書文獻管理系統軟體的功能和售價情況進行了詳細調研，發現這些軟體很難滿足學校圖書館的需求。因為從規模或藏書冊數來劃分，學校圖書館僅屬中小型圖書館，但應用需求則涉及到方方面面， 除了通常的圖書採購、圖書編目、圖書流通外，還有期刊管理， 現在市場上中小型圖書館管理軟體均只有基本的功能，採購、編目、流通，很少有期刊管理。 通常這種圖書管理軟體僅執行在圖書館內部的區域網上，沒有查詢系統，大型圖書管理軟體功能齊全，但**昂貴，特別是執行**高、維護困難、操作複雜。
根據學院圖書館的實際情況和學院校園網的現狀，我們確定了網路圖書管理系統應該具備幾個方面的功能，它們是圖書採購、圖書編目、圖書流通、期刊管理、系統維護、 查詢幫助、其中查詢是該系統突出的特點，它的實現是因為有學院主幹網的支援。
3.2系統結構的網路拓撲及其各個子系統
網路拓撲結構，整個系統使用了數台微機和1臺資料庫伺服器，1臺web 伺服器，為了保證訪問的速度和系統安全， 資料庫伺服器和web伺服器放在不同的物理伺服器上，網路採用星型連線構成區域網，區域網與學院主幹網相連。從圖中可以看出，學院校園網上的計算機都能夠訪問圖書館的**獲取資訊資源。
軟體體系結構作業
目錄1.需求描述 1 1.1 專案背景 1 1.2 專案目標 1 1.3 專案任務 1 2.靜態模型 1 2.1.軟體體系結構核心模型描述 1 2.2.靜態建模 2 用例圖 2 類及包圖 6 物件圖 9 構件圖 10 部署圖 10 3.動態模型 10 3.1 動態建模 10 狀態圖 10 活 11 ...
rup sad 軟體體系結構
專案名稱 軟體體系結構文件 版本 1.0 注意 以下模板供與 rational unified process 一起使用。包含在方括號中以藍色斜體 style infoblue 顯示的文字是用於向作者提供指導，在發布文件之前應將這些文字刪除。在此樣式之後輸入的段落將自動設定為正常 style bod...
軟體體系結構作業二章
作業電腦科學與技術09 4班 尹星 20092769 第一章1.根據自己的經驗，談談對軟體危機的看法 答 軟體危機是指軟體生產方式無法滿足迅速增長的計算機需求，開發和維護過程出現的一系列問題。它主要由以下幾個原因導致 1 軟體自身特點 2 開發人員的弱點 3 使用者需求不明 4 缺乏正確理論指導 5...