DSS的系统分析与设计.ppt

DSS的系統分析與設計本章大綱q第一節 導論q第二節 ROMC系統分析法q第三節 反覆設計法q第四節 雛型(prototyping)系統設計法q第五節 使用者自建系統q第六節 物件導向程式設計法q第七節 UML技術q第八節 結論學習目標q決策支援系統的分析步驟l分析決策問題的範圍與流程分析。l確認系統的需求。q決策支援系統的設計方法l反覆設計的方法與應用。l雛型法的設計方式與應用。l使用者自建系統的意義與應用。l物件導向技術與UML模組語言。圖9-1 資訊系統開發建立的過程初步設計系統分析系統設計程式編碼系統實施ROMC系統分析法q四大構成元素l表達方式(Representations)分析決策過程中必要資訊的表達形式是決策支援需求分析的首要工作。l運算(Operations)指的是對資料所做的各種操作。l輔助記憶(Memory Aids)決策支援系統能將有用的中間結果加以儲存，以備後面再使用。ROMC系統分析法（續）l控制機制(Control Mechanisms)DSS控制機制是協助決策者依他個人的風格、技巧和知識，利用表達、運算及記憶來組合出一個決策程序。ROMC分析程序 q找出決策各階段的主要活動 q針對每個活動找出系統的可能支援功能q建置ROMC要素 圖9-2 放款評估DSS的控制流程 客戶資料查詢案件分類風險分析評估可能方案找出最佳方案實施What-if分析舊案件資料ROMC應用實例q購車決策系統l情報蒐集資料瀏覽 l設計比較比較車型與可行方案 l做出決策決定購買的車型 反覆設計法的步驟q找出重要的次問題(Subproblems)l由決策者或使用者和系統建立者共同找出次問題。愈是時間短的專案或問題反而特別適用於DSS的反覆設計法。q發展一個小而實用的系統來協助決策者l系統建立者和使用者共同迅速且小規模地完成系統發展過程。這個雛型系統經由不斷地修改測試，將發展成一個完整的決策支援系統。反覆設計法的步驟（續）q反覆地精製、擴充並修改系統l系統初步完成後，便可以反覆地經由使用者評估與回饋來修正系統的功能，而得到新的版本。事實上，每個修改週期事實上都進行了分析設計實施使用評估等所有階段。雛型(Prototyping)系統設計法q步驟l找出決策者做決策的資訊需求和SDLC不同之處在於，雛型法並不要求將所有的需要一次完整地找出來。l建立雛型系統來檢驗決策者的需求雛型法要求根據前面所找出的初步需求，很快就做出一個雛型系統。l修改雛型讓使用者在試用過雛型系統後，能明確地知道自己的需求。雛型(Prototyping)系統設計法（續）l依據雛型來開發完整的系統暫時雛型經過持續的修改之後，成為有用的系統，則將這種雛型稱為演進雛型。使用者自建系統的優點q交貨時間短l使用者在需要時便開發自用系統，因為他不需要經過申請、核准經費等手續，所以不需配合資訊部門的時間，可以立即進行開發而不會錯過時效。q較能滿足使用者的需求l因為是由使用者自行設計所需的系統，使用者和設計者間的溝通問題完全消失，理論上便能夠設計出一個充分滿足使用者需求的系統。使用者自建系統的優點（續）q減少系統實施的阻力l因為系統是使用者自行設計建置，必然願意使用系統，因此可以消除使用者對資訊部門所設計的新系統的抗拒或不適應情況。使用者自建系統的缺點q績效不彰q管理不易l使用者自行開發系統的目的往往是為了解決眼前的個別問題，所以在開發過程中無法審慎考量，也多半不會對系統作評估。一旦使用者離職，接任者可能完全無法使用該系統。另外，不同的使用者也可能重複開發功能相同的系統，造成資源的浪費而不自知，這些問題都使資訊資源的管理變得困難。使用者自建系統的缺點（續）q角色衝突l使用者本身的主要任務並非開發系統，若他們花費太多時間與精力在自行開發系統上，可能會因此疏忽了他們本來的職責，造成本末倒置的現象，甚至與資訊部門的角色相衝突，這是必須要避免的問題。EUC的管理策略q必須有一明確的EUC策略，配合整體政策和標準，在符合標準的情況下，讓使用者自行選擇，而不以嚴格的成本效益作為控制手段。q必須明確界定資訊部門和使用者雙方的權責，並鼓勵發展合夥關係。q必須顧及全體，不能只關注少數幾個使用者；讓使用者之間彼此分享資訊、程式與經驗。q全面持續推廣使用者教育訓練，讓使用者電腦知識能不斷充實、更新。EUC的管理策略（續）q成立資訊中心，向EUC使用者提供下列服務l電腦入門訓練l電話諮詢服務l硬體和軟體標準的訂定l安全控管l編寫主機與PC的連線介面軟體l提供新軟體的安裝與試用報告l擔任EUC的系統專案經理人EUC成功實施的重要條件q功能完整而且熱心的資訊服務中心，可對EUC的發展提供較佳的規劃、教育訓練、支援服務與管制措施。q擁有高素質的員工，員工大多數具高學歷，學習能力強。q公司擁有高度電腦化的環境，以及豐富電腦化的經驗，且各部門皆已電腦化。q容易使用的電腦軟、硬體，可以滿足多樣的需求。物件導向程式設計法q物件l是具有獨立運作及行為的一組程式。q物件導向方法l認為電腦軟體系統的設計應以物件(object)作為思考的核心。並以物件做為軟體的基本模組單元(module)。圖9-6 物件間之訊息傳遞方式物件1物件2物件3物件4物件5物件6使用者的要求Communication updateCommunication updateCommunication update物件類別q物件定義l將具有相同結構、操作，並遵守相同約束規則的物件可以聚合成一組物件集合，稱為物件類別 q物件應包括l類別名稱l外部界面用於操縱類別實例的外部操作（外部操作較典型的應包括目標物件和許多變數）。l內部表示l界面的內部實現物件類別具有的重要訊息q類別規格l類別本身具有規格(Class Specification)，類別規格也稱為類別的外部特性或稱為外部界面，是讓使用者瞭解物件類別是什麼和能夠做什麼事，因而也是與使用者溝通的外部界面或界面。q類別實現l類別實現是類別的內部表示，即類別規格的具體實現方法。也就是詳細設計物件類別所說明的功能應當如何做，通常由系統開發人員透過程式設計來實現。對使用者來說，是不必瞭解類別實現的。物件類別具有的重要訊息（續）q類別層次與類別網(Class Hierarchy and Class lattice)l物件類別之間可能具有層次的結構或網狀的結構關係。類別的層次結構和網狀結構可用來描述現實世界中概括的抽象關係。物件導向方法的特性q抽象性l物件導向技術採用物件來表達一切事物。物件不僅可表達結構化的資料，而且可以表達傳統的結構化方法所不能夠表達的非結構化資料，包括複雜的工程實體、圖形、聲音、規則等。q封裝性l封裝性是指將結構及程序結合成為一個類別(Class)的特性，亦即封裝成一個單一的個體。物件導向方法的特性（續）q繼承性l是指子類別可以擁有母類別中的部分或全部屬性，使前者繼承了後者的原函數與變數，然後再加入它自己的成員變數，亦即前者的結構是後者的延伸。q多型性l是指某些函數可以接受多種不同變數型態。圖9-7 UML的4+1觀點Logical ViewProcessViewImplementationViewDeploymentViewEnd UserFunctionalityProgrammersSoftware managementSystem engineeringSystem topology,Delivery andinstallation,CommunicationSystem integratorsPerformance,Scalability,ThroughputAnalysts/TestersBehaviorUse Case ViewUML的核心觀點4+1觀點q使用案例觀點l是UML的核心，描述系統功能性的需求，找出使用個案(use case)與行為者(actor)。q邏輯觀點l描述達成系統內部功能性作業的細部設計，包括靜態結構和動態行為。q建置觀點l描述系統如何切分成軟體元件，進行實作。UML的核心觀點4+1觀點（續）q處理觀點l描述系統各組成部份整體運作的程序。q佈署觀點l描述系統硬體或設備之間的連結關系，以及軟體程序的配置情形。圖9-8 UML模式、觀點與圖相互間的關係使用案例圖程序圖類別圖物件圖元件圖部屬圖合作圖靜態圖活動圖模式靜態觀點動態觀點UML的模式化q統一模式化語言(UML)是一種規格化(Specifying)、視覺化(Visualizing)、文件化(Documenting)、建構化(Constructing)的軟體模式化語言，焦點是成為一個標準的建模語言。q好的建模技術三要素l模式元素(method elements)：基本的模式化概念與語義。l標記法(notation)：視覺化地表示出模式元素。l指導方針(Guidelines)：提供慣用的原則。UML符合企業作業流程模式建構q在眾多模式化語言中，UML是最符合規範的技術。q圖形化的表示方式，易於了解整個流程中所有參與者的角色及任務。q模式化流程組成的元件具有再使用性。q能輔助評估、衡量整個作業流程（利用動態模擬、統計分析等方式）。q明確的語意表達，以便很容易地實際執行。UML應用實例新聞製播資訊傳送資訊中心展示平台新聞製作新聞處理新聞展現企業資訊DB原始新聞帶DB完成新聞帶DB即時新聞帶DBuseuseusehashashashashashas