信息系統(tǒng)分析與設計重點

1、第一章 信息（數(shù)據(jù)）是信息系統(tǒng)的核心，是信息系統(tǒng)處理和管理的對象，信息的特征和處理方法 直接影響到信息系統(tǒng)的類型與形式，了解信息的有關知識有助于信息系統(tǒng)的分析與設計。數(shù)據(jù) 數(shù)據(jù)是用各種可以鑒別的物理符號記錄下來的客觀事實； 數(shù)據(jù)是原始記載，是未經(jīng)任何加工的，因而是粗糙的、雜亂的，但它真實、 可靠、有積累的價值。信息 信息是具有一定含義的數(shù)據(jù)，是加工（處理）后的數(shù)據(jù)，是對決策有價值的 數(shù)據(jù)數(shù)據(jù)與信息的關系數(shù)據(jù)和信息的特點 數(shù)據(jù)在計算機化的信息系統(tǒng)中往往和計算機系統(tǒng)有關。 信息不隨載荷它的物理載體而改變；數(shù)據(jù)與信息密切相關 信息是加工后的數(shù)據(jù)，比數(shù)據(jù)更有價值； 數(shù)據(jù)則是信息的具體表現(xiàn)； 在一定的環(huán)

2、境內(nèi)可以互相代用系統(tǒng)的特征：輸入輸出界面關系部件界面環(huán)境系統(tǒng)的層次系統(tǒng)層次的概念 一個系統(tǒng)可以劃分成不同的層次，或不同的子系統(tǒng)系統(tǒng)層次的劃分根據(jù)抽象的粒度不同 （詳細程度不同） 根據(jù)功能的不同信息系統(tǒng)的定義信息系統(tǒng)是一組相關聯(lián)的要素（Elements）或部件（Components ）,其收集（輸入）操作和儲存（處理） 、散布（輸出）數(shù)據(jù)和信息，并具備 反饋機制 。 信息系統(tǒng)的基本功能信息的收集信息的存儲信息的傳輸信息的加工信息的輸出信息系統(tǒng)的方法分解（ Decomposition ）將系統(tǒng)分成更小的要素（子系統(tǒng)、組件或模塊） ；“分而治之 ”，將系統(tǒng)分割成小的、可管理的、便于理解的子系統(tǒng) 便于

3、一次僅關注一個范圍，而不干涉其它的范圍； 關注一組用戶相相關的部件，而不必用不必要的細節(jié)去困惑用戶 在不同的時間段實現(xiàn)不同的部件，使項目便于管理模塊化( Modularity )將一個系統(tǒng)劃分成相對一致大小的過程；系統(tǒng)分解的結(jié)果模塊簡化了系統(tǒng)設計耦合( Coupling )低子系統(tǒng)之間的相互依賴性內(nèi)聚( Cohesion )高子系統(tǒng)完成單獨功能的程度集成( Integration )允許不同廠商的軟件和硬件一起工作； 使過程語言系統(tǒng)同可視化編程系統(tǒng)一起工作 可視化的變成環(huán)境使用客戶 / 服務器模型 信息系統(tǒng)發(fā)展： TPS->MIS->DSS 三個典型的信息系統(tǒng)： TPS、 MIS、

4、 DSS 事務處理系統(tǒng)( Transaction Processing System ,TPS) 功能或特點自動處理商業(yè)活動或交易的數(shù)據(jù)目標通過增加速度、提高生產(chǎn)力，簡化過程來改進事務處理發(fā)展從 EDP 到 OLTP面向的用戶操作或辦事人員典型的例子銷售與市場系統(tǒng)、生產(chǎn)與制造系統(tǒng)、財務/ 會計系統(tǒng)、人力資源系統(tǒng)、學校的注冊系統(tǒng)管理信息系統(tǒng)( Management Information System ,MIS )功能或特點利用來自TPS系統(tǒng)的未加工的數(shù)據(jù)，將其轉(zhuǎn)換成有意義的聚合形式目標提供有助于工作管理的信息特點輸入大量的數(shù)據(jù)進行定期的報表和簡單模式的處理產(chǎn)生管理的報表：計劃報表、查詢報表、異

5、常報表、匯總報表面向的用戶中層管理人員決策支持系統(tǒng)( Decision Support System ,DSS)功能或特點通過應用數(shù)學或邏輯模型， 應用交互的對話來解決非結(jié)構(gòu)化問題， 交互地支 持決策的制定。亦稱為 “What if 分”析目標提供不同方案的 比較和首選方案的推薦特點輸入少量的數(shù)據(jù)交互式的模擬與分析產(chǎn)生決策分析報告面向的用戶高層管理人員或?qū)I(yè)分析人員信息系統(tǒng)與組織基本目標 改進信息和知識管理；改進業(yè)務過程；改進組織內(nèi)部和組織之間的通信。基本任務 將適當?shù)男畔?，在適當?shù)臅r間、適當?shù)牡攸c，以 適當?shù)男问?，傳遞給 適當?shù)?人員?；咀饔眯畔⑾到y(tǒng)是企業(yè)或組織信息化戰(zhàn)略的一個具體的、重要

6、的組成部分。 信息系統(tǒng)是現(xiàn)代商業(yè)組織獲得成功的關鍵?，F(xiàn)代商業(yè)組織需要不斷地開發(fā)或更新系統(tǒng)來使商業(yè)更具有競爭力。比爾 . 蓋茨 : “Business the speed of thought-using a digital nervous system ” 第二章 系統(tǒng)分析與設計基礎系統(tǒng)建設生命周期（System Development Life Cycle , SDLC觀念的討論兩段論 系統(tǒng)開發(fā)，系統(tǒng)運行（使用，修改）四段論 系統(tǒng)計劃與選擇，系統(tǒng)分析，系統(tǒng)設計，系統(tǒng)實施與運行五段論 規(guī)劃、分析、設計、實施，運行與維護六段論 計劃，需求分析，設計， 編碼，測試，（編碼，測試對應五段論中的實施階

7、段） 運行與維護三種基本過程模型 -瀑布模型瀑布模型（Waterfall model , Royce,1970）的特點將系統(tǒng)開發(fā)分成分離的、 不同的階段， 一個階段完成后， 才進入到下一個階 段。瀑布模型的階段 項目計劃、需求分析與定義、系統(tǒng)和軟件設計、實施和測試、運行與維護。瀑布模型的問題 過程開始后適應環(huán)境的變化困難，并且將項目不靈活地劃分成不同的階段， 因而對用戶需求的變化很難響應。瀑布模型的用途適用于對需求充分理解的系統(tǒng)、 用戶交互程度低的計算系統(tǒng)、 或者關鍵系統(tǒng) 的開發(fā)。進化開發(fā)（ Evolutionary development ）的特點將系統(tǒng)開發(fā)活動的分析、設計與實施交叉進行。進

8、化開發(fā)的兩種形式探索性開發(fā)： 目標是同用戶一起工作，從最初的雛形發(fā)展成最終的系統(tǒng)。 在一開始對需求有很好地理解的情況下使用。一次性原型： 目標是理解系統(tǒng)的需求。 在一開始對需求不能很好地理解的情 況下使用。進化開發(fā)的問題 過程可見性缺乏；開發(fā)的系統(tǒng)通常結(jié)構(gòu)較差；需要專門的技巧進化開發(fā)的用途 中小規(guī)模的交互系統(tǒng)的開發(fā)；大型系統(tǒng)中的部分(如用戶界面)的開發(fā)；較 短生命周期系統(tǒng)的開發(fā)。面向重用開發(fā)( Reuse-oriented development )的特點 基于系統(tǒng)化重用，系統(tǒng)由已有的組件或商品軟件系統(tǒng) (Commercial-off-the-shelf ， COTS) 集成而建立。面向重用開

9、發(fā)的階段 組件分析、需求調(diào)整、基于重用的系統(tǒng)設計、開發(fā)和集成面向重用開發(fā)的優(yōu)點 顧客價值能隨著每部分工作的完成而交付，所以系統(tǒng)的功能較早能獲得。 降低整個系統(tǒng)失敗的風險 早先的完成的部分能作為原型來幫助后面部分獲取需求 最高優(yōu)先級的系統(tǒng)服務傾向于獲得最多的測試面向重用開發(fā)的用途 雖然經(jīng)驗有限，但成為應用越來越重廣泛的方法過程迭代的含義 過程迭代是重復地多次的進行相同的開發(fā)活動，即重復先前階段的工作，有 時是增加詳細程度，有時是增加精度。可以同基本過程中的任何一個過程結(jié) 合使用。早期的迭代著重于需求、分析和設計；后期的迭代著重于實現(xiàn)和測試。 過程迭代的應用增量開發(fā)方法( Incremental

10、development ， Mills, 1980 ) 螺旋開發(fā)方法( Spiral development ， Boehm, 1988 ) 增量開發(fā)的特征系統(tǒng)不是一次總體交付，而是將系統(tǒng)開發(fā)和交付分割成若干個部分，每一個 部分交付要求功能的一部分，系統(tǒng)被逐漸地開發(fā)、測試和集成。 用戶需求被優(yōu)化，最高優(yōu)先等級的需求被包括在較早實施的部分中。 一旦一個部分的工作開始， 需求被凍結(jié)， 雖然后續(xù)部分的需求可以繼續(xù)發(fā)展。 增量開發(fā)的優(yōu)點顧客價值能隨著每部分工作的完成而交付，所以系統(tǒng)的功能較早能獲得。 早先的完成的部分能作為原型來幫助后面部分獲取需求 降低整個系統(tǒng)失敗的風險最高優(yōu)先級的系統(tǒng)服務傾向于獲得

11、最多的測試螺旋開發(fā)的特征 開發(fā)過程不是一系列重復的部分，而是通過若干階段的增長、改進和精練而 完成，其是一個螺旋過程。螺旋中的每個循環(huán)代表了過程中的一個階段 在螺旋中的循環(huán)根據(jù)需要來選擇，因此沒有諸如需求定義或設計的固定階 段。螺旋開發(fā)的優(yōu)點開發(fā)工作是呈螺旋式上升，而不是簡單地重復 在開發(fā)過程中，風險被明確地評價并解決螺旋的組成部分 目標制訂：為每個確定的階段定義目標 風險評價和減少：風險被評價，減少關鍵風險的活動被執(zhí)行 開發(fā)和確認：選擇任一個基本過程模型作為系統(tǒng)開發(fā)的過程模型 規(guī)劃：項目被評論，螺旋的下一個階段被規(guī)劃典型的開發(fā)過程方法生命周期法原型法快速法面向?qū)ο蠓–ASE法其它過程方法 生

12、命周期法（ SDLCMethod ） 生命周期法是一種 基于過程瀑布模型 的系統(tǒng)開發(fā)方法， 也被稱為 結(jié)構(gòu)化生命 周期法，或瀑布周期法。其是應用結(jié)構(gòu)化技術(shù)， 根據(jù)系統(tǒng)發(fā)展生命周期， 將系統(tǒng)開發(fā) 明確 劃分為規(guī)劃、 分析、設計、實施和維護五個階段。 （ 不重復，一個階段完成才能進行下 一個階段）生命周期法的 優(yōu)點 采用生命周期的瀑布形式，預先定義需求的策略。 能對系統(tǒng)進行科學的分析與設計， 因而能全面地規(guī)劃， 等到優(yōu)化的整體設計， 實現(xiàn)整個設計過程科學化和系統(tǒng)化； 整個項目按階段和步驟可以劃分為許多組成部分， 各部分可各自獨立地開展 工作，有利于整個項目的管理與控制。生命周期法的 缺點 開發(fā)周期

13、過長，見效慢，難以適應環(huán)境的急劇變化； 從分析階段的模型向設計階段模型轉(zhuǎn)換較困難，需要熟練的技巧； 由于在開始時不可能得到全部的、 嚴格的需求分析， 為以后的修改帶來困難。生命周期法的應用 特別適合于開發(fā)那些能夠預先定義需求、 結(jié)構(gòu)化程度又比較高的大型事務型 系統(tǒng)（TPS、管理信息系統(tǒng)（MIS）。 適應與用戶交互活動少的大型計算系統(tǒng) 適應工業(yè)系統(tǒng)和大型的關鍵系統(tǒng)。 不適合于開發(fā)信息需求不明確的系統(tǒng)，外界環(huán)境變化大的系統(tǒng)原型法（ Prototype Method 、 原型法依據(jù)過程進化模型中 的探索性開發(fā) ，并結(jié)合了增量式迭代。 其應用直觀認識問題的方法和先進的計算機技術(shù)， 一開始便憑借系統(tǒng)開發(fā)

14、人 員對用戶需求的理解， 在強有力的軟件開發(fā)環(huán)境的支持下， 用試驗的辦法建 立起一個簡單的系統(tǒng)原型， 然后利用該原型同用戶反復協(xié)商修改和完善， 最 終形成實際系統(tǒng)。原型法的 工作過程 用戶提出系統(tǒng)要求，開發(fā)人員對用戶的功能和性能需求進行分析和確定； 在此基礎上開發(fā)出一個僅僅包括最重要的系統(tǒng)功能、 使用一個最基本數(shù)據(jù)庫 的、可工作的原型系統(tǒng)； 讓用戶使用這個原型系統(tǒng)，研究用戶對它的評價和提出的更改要求； 如果原型系統(tǒng)根本不行， 則重頭構(gòu)造系統(tǒng)原型， 如果不滿意， 則根據(jù)用戶意 見對原型進行改進和完善，直到系統(tǒng)完全滿足用戶的需求為止。原型法的優(yōu)點 原型法將模擬的手段引入系統(tǒng)分析的開始， 溝通了人們

15、的思想， 縮短了用戶 和系統(tǒng)開發(fā)人員之間的距離，解決了系統(tǒng)開發(fā)中難度最大的需求定義問題 。 原型系統(tǒng)能 啟發(fā)人們對原來想不到或不易準確描述的問題有一個比較確切 的描述， 能及早地暴露出系統(tǒng)實現(xiàn)后可能出現(xiàn)的一些問題，使得問題能及早得到解決。原型法的缺點 用戶對于一個大型系統(tǒng)， 如果不經(jīng)過系統(tǒng)分析來進行整體性劃分， 直接用原 型來模擬，容易造成系統(tǒng)結(jié)構(gòu)混亂，并且實現(xiàn)也非常困難。對于需要大量計算、 邏輯性較強的系統(tǒng)， 原型法很難構(gòu)造出模型來進行評價。 對于原基礎管理不善、 信息處理過程混亂的問題， 使用原型法更有一定的困 難。對于批處理系統(tǒng)，由于其大部分是內(nèi)部處理過程，不適宜采用原型法。面向?qū)ο蠓?

16、 Oriented Objects Method ， OOM) 面向?qū)ο蟮南到y(tǒng)分析設計法 OOSAD 面向?qū)ο蠓椒ㄊ腔诿嫦驅(qū)ο蠹夹g(shù)來進行系統(tǒng)開發(fā)。面向?qū)ο蠓ǖ墓ぷ鲀?nèi)容系統(tǒng)調(diào)查和分析： 對系統(tǒng)需要解決的具體管理問題以及用戶對系統(tǒng)性能的需 求進行調(diào)查研究，解決系統(tǒng) “做什么 ”的問題。分析問題的性質(zhì)和求解問題： 在繁雜的問題域中抽象地識別出對象以及其行 為、結(jié)構(gòu)、屬性和方法等。整理問題：對分析結(jié)果作進一步的抽象、歸納、整理，并最終以模型的形式 將它們確定下來。面向?qū)ο蠓ǖ奶攸c以對象為基礎， 利用特定的軟件模塊， 完成從對象客體的描述到軟件結(jié)構(gòu)之 間的轉(zhuǎn)換避免了其它方法在開發(fā)過程中的不一致性和復雜

17、性 系統(tǒng)的開發(fā)具有簡單性、統(tǒng)一性開發(fā)周期短，費用低計算機輔助軟件工程( Computer Aided Software Engineering ， CASE) 基于計算機的自動化的方法，它利用CASE工具來進行系統(tǒng)的開發(fā)，是提高系統(tǒng)開發(fā)效率與質(zhì)量的一種實用的系統(tǒng)開發(fā)方法。CASE法的優(yōu)點使結(jié)構(gòu)化方法可以全面實施； 使面向?qū)ο蠓椒ǜ菀讓崿F(xiàn)； 使原型的建立具 有高效率的手段，加快系統(tǒng)的開發(fā)過程； 使系統(tǒng)開發(fā)人員的精力集中于開創(chuàng)性工作；通過自動檢查提高軟件的質(zhì)量， 提高軟件的可重用度；可以簡化系統(tǒng)的維護工作。通過提供一個具有快速響應、專用資源和早期查錯功能的交互式開發(fā)環(huán)境， 對系統(tǒng)的開發(fā)和維護過程

18、中的各個環(huán)節(jié)實現(xiàn)自動化， 利用圖形接口， 實現(xiàn)直 觀的程序設計。CASE的功能-1基于中心信息庫： 存儲和組織所有與應用系統(tǒng)有關信息的一種機構(gòu)， 包括系 統(tǒng)的規(guī)劃、分析、設計、實現(xiàn)和管理等信息。如：結(jié)構(gòu)化圖形、 OO 模型、 屏幕與菜單的定義、報告的模式、記錄說明、處理邏輯、數(shù)據(jù)模型、組織模 型、處理模型、源代碼、事務規(guī)則、項目管理形式、數(shù)據(jù)元素以及系統(tǒng)信息 模型之間的關系等。 中心信息庫具有對系統(tǒng)信息存儲、 更新、 分析和報告的 功能，系統(tǒng)開發(fā)人員可以直接從中獲取所需的信息圖形功能： 圖形為軟件的描述提供了一種簡明的方法， 是產(chǎn)生好的系統(tǒng)和程 序文檔的基礎。用交互式方式在計算機屏幕上繪圖，可

19、加快圖形繪制過程， 實現(xiàn)標準化和文檔自動生成等。查錯功能：CASE提供了自動檢查的功能，其思想是以即系統(tǒng)說明書為依據(jù) 進行檢測，達到系統(tǒng)的一致性和完整性。CASE的功能-2代碼自動生成：CASE通過程序設計規(guī)格說明生成代碼，實現(xiàn)編程階段的自 動化。這種自動生成可能是一個框架， 也可能是一個完整的程序。 其框架可 以是數(shù)據(jù)庫、 文件、屏幕和報表描述的代碼； 其完整程序可以是可執(zhí)行代碼， 需要訪問的數(shù)據(jù)庫文件、 屏幕求助信息、 出錯信息及程序文檔等。 這樣可以 提高系統(tǒng)開發(fā)的效率。結(jié)構(gòu)化方法工具：CASE提供的若干工具，有利于結(jié)構(gòu)化分析和結(jié)構(gòu)化程序 設計，從而使結(jié)構(gòu)化方法實現(xiàn)自動化。CASE工具為

20、畫數(shù)據(jù)流圖、ER圖(實體聯(lián)系圖) 等提供了圖形支持， 可自動生成諸如系統(tǒng)說明和偽碼等形式的規(guī) 格說明。同時，CASE指導用戶正確地使用結(jié)構(gòu)化方法，使用戶按照一定的 標準化程序進行系統(tǒng)分析與設計。極限編程( Extreme programming ， XP， Boehm, 1988 ) 極限編程是快速法在軟件開發(fā)中的例子， 其采用了持續(xù)代碼改進、 用戶參與 開發(fā)團隊、以及 配對編程( pairwise programming )等方法來進行增量開發(fā) 。Rational 統(tǒng)一開發(fā)過程( Rational Unified Process ， RUP)是R ational提出的一種基于反復和增量的面向

21、對象開發(fā)方法。 是軟件開發(fā)最佳經(jīng)驗(迭代化開發(fā)、需求管理、基于構(gòu)件的軟件架構(gòu)、可視 化建模、持續(xù)的質(zhì)量保證、配置管理)的一個總結(jié)，其用流程來加以表示和 使用這些經(jīng)驗。是經(jīng)過實踐檢驗的、實用的、靈活的、基于 Web 的流程框架和定義流程工 具平臺。RUP的特點迭代化思想活動和工件的向?qū)б曰炯軜?gòu)為中心用例驅(qū)動對系統(tǒng)進行抽象和建模«4>9Et»工作百商業(yè)建糧一幻芮用也討一實現(xiàn)嘲溢辭皤-伺CM祖3隹M 理 項目首理環(huán)境送代系統(tǒng)分析與設計技術(shù)-結(jié)構(gòu)化技術(shù)、面向?qū)ο蠹夹g(shù)、信息工程結(jié)構(gòu)化分析與設計（SAD）系統(tǒng)開發(fā)使用結(jié)構(gòu)化編程、結(jié)構(gòu)化設計和結(jié)構(gòu)化分析技術(shù)，應用過程建模， 使用數(shù)

22、據(jù)流程圖（Data Flow Diagrams，DFD），是模型驅(qū)動的技術(shù)方法。技術(shù)的組成結(jié)構(gòu)化編程技術(shù)結(jié)構(gòu)化設計技術(shù)結(jié)構(gòu)化分析技術(shù)實施過程分析-設計-編程方法的缺點將數(shù)據(jù)與過程分開，不能很好地反映實際需求，如定單的內(nèi)容與處理基于瀑布式的SDLC不易適應變化分析和設計脫節(jié)，分析階段的圖表和表示不容易映射到設計結(jié)構(gòu)結(jié)構(gòu)化編程技術(shù)技術(shù)產(chǎn)生（1960s）提供改善計算機程序質(zhì)量的指南。技術(shù)思想一個高質(zhì)量的程序不僅要在程序每次運行時產(chǎn)生正確的結(jié)果，而且要容許其他的程序員在以后能容易地讀懂和修改該程序主要概念結(jié)構(gòu)化程序：一個程序或程序模塊， 其有起點和終點，并且程序執(zhí)行的任何 一步都是由三個基本的編程結(jié)構(gòu)

23、（順序結(jié)構(gòu)、判斷結(jié)構(gòu)、循環(huán)結(jié)構(gòu)）之一組 成。自上而下編程（模塊化編程）：將一個復雜的程序分解成有層次的程序模塊， 頂層模塊按需要調(diào)用下層模塊來控制程序的執(zhí)行，模塊可以是同一程序的一部分，模塊也可以不同的程序。結(jié)構(gòu)化設計技術(shù)技術(shù)產(chǎn)生（1970s）提供一些指南來確定程序集應該如何組織、每個程序應該如何完成、以及程序應該如何組織成層次結(jié)構(gòu)。表示方法 結(jié)構(gòu)圖 模塊和模塊的組織層次用一個稱為模塊結(jié)構(gòu)圖（structure chart） 的模型來圖形地表示。主要原理松散耦合： 每個模塊盡可能地相互獨立， 以便各個模塊能方便設計， 并且能 夠在以后的修改時對其它模塊的執(zhí)行沒有影響。高度內(nèi)聚： 每個模塊的完成

24、明確地作業(yè)， 以便模塊的功能易于理解， 并且當 模塊需要改變時，不至于意外地影響其它的作業(yè)。評價的方法 定義不同程度的藕荷和內(nèi)聚，并且提供一個評價設計質(zhì)量的途徑 -質(zhì)量由設 計的理解和以后需要時修改的難易程度衡量。設計的要求 假設設計者掌握系統(tǒng)需要做什么， 而不僅僅是組織程序模塊。 例如： 主系統(tǒng) 的功能是什么？數(shù)據(jù)要求是什么？需要輸出的內(nèi)容是什么？設計的新內(nèi)容1980s 起，包括數(shù)據(jù)庫的設計 用戶界面的設計結(jié)構(gòu)化分析技術(shù)技術(shù)產(chǎn)生（ 1980s） 解決前面設計中對設計者要求掌握系統(tǒng)應該做什么的問題。 更詳細地定義系 統(tǒng)必須做什么，而不涉及具體地技術(shù)。結(jié)構(gòu)化分析用于幫助開發(fā)人員定義系統(tǒng)需要做什么

25、（處理的要求） ，系統(tǒng)需 要儲存和使用什么數(shù)據(jù)（數(shù)據(jù)的要求） ，什么輸入和輸出需要，以及這些功 能如何一同工作來完成任務。表示方法 數(shù)據(jù)流程圖 在結(jié)構(gòu)化分析中使用的表示系統(tǒng)需求的關鍵圖形化模型是數(shù)據(jù)流程圖， 其顯 示了輸入、處理過程、存儲和輸出，以及它們?nèi)绾我黄鸸ぷ鳌＞唧w步驟 通過確定所有能夠引起系統(tǒng)以某種方式反應的事件來定義系統(tǒng)處理需求。 每 一個事件導致不同的系統(tǒng)活動。 分析員根據(jù)這些活動產(chǎn)生一個數(shù)據(jù)流程圖來 表示包括輸入和輸出的處理細節(jié)。面向?qū)ο笙到y(tǒng)分析與設計（OOSAD）（提高了重用性，擴展性，維護性） 是基于對象表示的分析與設計方法， 對象將數(shù)據(jù)和過程封狀在一個統(tǒng)一的結(jié) 構(gòu)中。技術(shù)構(gòu)

26、成面向?qū)ο蠓治觯?定義在系統(tǒng)中工作的所有類型的對象， 并說明這些對象是如 何相互作用來完成工作的。面向?qū)ο笤O計： 定義在系統(tǒng)需要同人和設備通訊的所有另外類型的對象。 并 將每一類型的對象的定義細化。面向?qū)ο缶幊蹋豪靡环N編程語言編寫語句來定義每類對象具體做什么。 技術(shù)特點基于對象建模 利用統(tǒng)一建模語言（ Use of Unified Modeling Language ， UML） 表示（如類 圖）。 系統(tǒng)由對象組成， 對象與環(huán)境、 對象之間相互作用來實現(xiàn)系統(tǒng)的功能 （如例 圖）系統(tǒng)架構(gòu)的層次劃分 （基本三層，表現(xiàn)層，應用邏輯層，數(shù)據(jù)處理層） 表現(xiàn)層：是實際的用戶界面 -對用戶輸入和輸出的表現(xiàn)

27、； 表現(xiàn)邏輯層：是未了生成表現(xiàn)而必須進行的處理； 應用邏輯層：包括支持實際業(yè)務應用和規(guī)則所需的所有邏輯和處理 數(shù)據(jù)處理層： 包括用來存儲和訪問來往于數(shù)據(jù)庫的數(shù)據(jù)所需的所有命令和邏 輯；數(shù)據(jù)層：是數(shù)據(jù)庫中實際存儲的數(shù)據(jù)。數(shù)據(jù)流程圖（ Data-Flow Diagram ， DFD） 圖形地表示數(shù)據(jù)在外部實體、過程和系統(tǒng)內(nèi)的數(shù)據(jù)存儲之間的運動； 表示了系統(tǒng)的動態(tài)屬性。數(shù)據(jù)流程圖的構(gòu)成 （圖素 ）過程（ Process）： 用帶園角的矩形表示，過程的編號和名稱被標出。數(shù)據(jù)存儲（ Data Store ）： 用右邊缺一邊的長方形表示，標簽包括存儲的名稱和編號。數(shù)據(jù)流（ Data Flow ）： 用箭頭

28、表示，選擇有意義的名稱來表示數(shù)據(jù)。外部實體（ External Entity ） 用正方形表示，名稱表示外部的實體。題型：一 判斷 10*1 '（程序，概念）不用改錯二 選擇 20*1 '三 簡答 5*6 '四 案例應用 2*12 '（類圖，活動圖模型 ,填類名稱，類之間關系）五 繪圖題（用例場景描述，序列圖） （ 16'）參與者，對象，實體 消息傳 遞UML 這塊是重點，大家一定要好好看看。最好可以實際練習一下。Figure 5.2 Gane and Sarson identified four symbols to use in data flow

29、diagrams to represent the flow of data: data flow symbol, data store symbol, process symbol, and source/sink symbol.DataFlowlData FlowDataStorelData StoreProcesslProcessInterfacel Source/Sink外酣加 劃據(jù)流和過程來自事彬愫中關于事件的信息事件源觸發(fā)活動分析模型（UML）用例圖： 描述系統(tǒng)與其它外部系統(tǒng)以及用戶之間交互的圖形。用例圖描述 了誰將使用系統(tǒng)，用戶希望用什么方式與系統(tǒng)交互。用例場景（用例描述）：是業(yè)

30、務事件以及用戶如何冋系統(tǒng)交互以完成任務的 文字描述。類圖：描述系統(tǒng)的靜態(tài)組成交互圖：描述系統(tǒng)對象之間的交互活動（序列圖和協(xié)作圖（也叫通訊圖）狀態(tài)圖：描述對象內(nèi)部的活動E-R 圖：（下圖中關系的表示有的也為："> ）類圖：（三層，類名，屬性，方法）類圖與E-R圖區(qū)別在類圖有方法。類與類關聯(lián)間注意基數(shù)表示（一對多，多對多）<<PK>>用于主鍵Figure 12.8 Design Ckiis PiuJuclProduct (from Inventory)«PK» -prodId : Integer-prodName : String-pro

31、dDesc: String-prodListPrice : Currency-quantOnHand : Integer-minQuant: Intege=0-reorderQuant: Integer+getProductlnfo(v_Prodld : Integer): String +updateinventory(v QuantOnHand : Integer)注意三種類圖畫法1分析類的原型 同步條是活動圖特有的，注意判斷點的用法實體類；訂單邊界類：訂單表單控制類；訂單控制OiderformOrdrGontrol豔慕者和用例之同用例內(nèi)部工作相關 的主要操作行為一般，參與者同邊界類交互,

32、 邊界類依次同控制類交互， 控制類再同實體類交互。序列圖畫法（類用上圖圖示）Figure 9*7OiULruirn of ilia Umi UuhQ PltLec OriJi&4-UML 的視圖視圖是從不同的角度來觀察待建模的系統(tǒng)，其是由多個圖表組成的抽象體； 視圖同建模語言保持聯(lián)系，為系統(tǒng)選擇開發(fā)方法或過程；UML 有 5 個層面用例視圖( Use-Case View)邏輯視圖( Logical View )組件視圖( Component View )協(xié)作視圖( Concurrency View )部署視圖( Deployment View ) 第三章 信息系統(tǒng)計劃 信息系統(tǒng)的規(guī)劃分

33、 戰(zhàn)略規(guī)劃與項目計劃 兩個層次，二者既有區(qū)別，又有聯(lián)系；前者與組織 的戰(zhàn)略規(guī)劃密切相關，后者在前者的框架下，與具體的信息系統(tǒng)項目相關，不能將二者混 為一談。信息系統(tǒng)建設項目的第一步是項目計劃，其是在信息系統(tǒng)戰(zhàn)略規(guī)劃的指導下，對 具體的信息系統(tǒng)開發(fā)項目進行計劃，項目計劃的任務定義問題確定項目可行性制訂項目時間安排表項目人力資源安排項目正式開始實施經(jīng)濟可行性分析要點有形效益 VS 無形效益有形效益 -有形效益是信息系統(tǒng)帶來的，可以容易地用貨幣計量或確定地衡量的效益， 無形效益 -無形效益是信息系統(tǒng)帶來的，不容易用貨幣計量或確定地衡量的效益可見成本 VS 不可見成本可見成本 -同信息系統(tǒng)相關的，可以

34、容易地用貨幣或確定地衡量的成本，包括：硬件費用勞動費用運行費用不可見成本 -同信息系統(tǒng)相關的，不容易用貨幣或確定地衡量的成本，包括： 顧客忠誠度降低 雇員士氣降低 操作效率降低一次性成本 VS 重復成本一次性成本 -同信息系統(tǒng)啟動、開發(fā)和投入運行相關的成本，包括：系統(tǒng)開發(fā)新的硬件和軟件購置用戶培訓場地準備數(shù)據(jù)或系統(tǒng)轉(zhuǎn)換重復成本 -同信息系統(tǒng)運行和維護相關的成本，包括：應用軟件維護數(shù)據(jù)存儲增加費用 通訊增加費用 新軟件和硬件的租賃 耗材和其它費用（如紙張、表格、數(shù)據(jù)中心人員） 項目進度計劃工作分解結(jié)構(gòu)（ Work Breakdown Structure ， WBS） 階段由一組相關的工作組成；

35、工作由一組相關的任務組成； 任務是最小的工作單位。 （例圖）階段進度安排的特點 按階段、活動和任務三級層次結(jié)構(gòu)； 規(guī)劃階段不可能列出所有作業(yè)的進度表， 通常僅列出主要的任務進度。 具體 的作業(yè)進度安排可以在一個階段開始前進行。項目進度安排的四個步驟根據(jù)SDLG確定標準的階段、活動和任務，以及項目特需的活動和任務； 評估任務的規(guī)模 （所需人員、需要的人日、 時間要求以及其它專門的需要等） ； 確定任務的序列；制訂任務進度表（PERT/CPM甘特圖）甘特圖與PERT（網(wǎng)絡圖）對比（甘特圖強調(diào)了時間信息相關性，PERT圖著重作業(yè)間的相關性）PERT/ CPM的作用通過確定哪些作業(yè)可以同時進行， 哪些

36、作業(yè)必須連續(xù)進行， 項目經(jīng)理能夠確 定整個項目的預期持續(xù)時間；特別適用于制定最初的項目進度安排關鍵路徑的作用 在該路徑上的每個作業(yè)完成時間直接影響項目的完成時間，必須按時完成。甘特圖的特點 沒有用圖形直接地表示作業(yè)間的相關性，但著重表示了時間信息的相關性； 特別適應于項目開始后的進度跟蹤?？梢杂貌煌伾珮俗R項目的進度，如： 已經(jīng)完成部分、未完成部分、提前完成或延遲完成、剩余時間等。I廿特圖與PERT的關系第四章 信息系統(tǒng)分析? 功能需求(Functional requirements)用來描述系統(tǒng)應該提供的服務(功能)、系統(tǒng)應該如何響應一個特定的輸入， 以及系統(tǒng)在特定的情況下應該如何運行；可以

37、用圖形模型表示；功能需求基于組織用來運營的流程和業(yè)務規(guī)則，可能是明文規(guī)定的。? 非功能需求(Nonfunctional requirements )用來描述對系統(tǒng)提供的服務和功能的約束，如適時性約束、開發(fā)過程約束、標準等；硬件、軟件和網(wǎng)絡的要求和系統(tǒng)技術(shù)性能指標；一般用文字描述，也稱技術(shù)需求。? 區(qū)別功能需求從工作角度來考慮產(chǎn)品的動作或系統(tǒng)提供的服務非功能需求是功能需求所代表的工作或服務的特征功能需求以動詞為特征非功能需求以副詞為特征? 聯(lián)系非功能需求是功能所必備的屬性? 系統(tǒng)分析的活動系統(tǒng)分析階段的工作在軟件工程中稱為需求工程；需求工程的過程是多種多樣，取決于應用的領域，涉及的人員，以及提供

38、 需求的組織。但是，對所有的需求工程的過程而言，有些活動是共同的，即：需求獲取(Requirements elicitation )目的：1獲取信息，為需求分析提供證據(jù)(1) 對商業(yè)環(huán)境的了解(2) 對現(xiàn)行系統(tǒng)的了解2爭取成為行業(yè)專家3加強同用戶的溝通和協(xié)作需求分析( Requirements analysis ) 需求建模 ( Requirements documant ) 需求確認( Requirements validation ) 需求管理( Requirements management )? 需求獲取的方法(每個方法怎么做？特點？)1. 向用戶分發(fā)和收集調(diào)查表2. 評估現(xiàn)存的報告、

39、表格和過程描述3. 同用戶會談和討論4. 觀察業(yè)務流程和工作流5. 建立原型6. 召開聯(lián)合應用設計(JAD)會議? 分發(fā)和收集調(diào)查表? 方法的特點1. 從大量的用戶中收集信息，是簡答問題形式；2. 可以用做初步調(diào)查，然后根據(jù)需要，在此基礎上深入調(diào)查；3. 適合于調(diào)查有關數(shù)量的問題，如，一天輸入多少定單？4. 有利于了解用戶的觀點，大體或趨勢；5. 不適合于了解過程、工作流和技術(shù)。? 方法的關鍵1. 調(diào)查表的設計? 評估現(xiàn)存的報告、表格和過程描述? 方法的特點1. 是初步了解過程的好方法，為進一步詳細調(diào)查打下基礎；2. 要求用戶提供當前使用的表格、過程手冊和描述的拷貝；3. 文檔和報告可以作為工

40、具，幫助會談和討論；4. 可以幫助對數(shù)據(jù)格式、內(nèi)容等的理解；5. 要注意文檔的時效性和正確性，要用戶確認。? 同用戶會談和討論 ? 方法的特點是目前為止了解業(yè)務功能和商業(yè)規(guī)則的最有效方法； 是最耗費時間和資源的方法； 要求多次會議。? 方法的步驟1. 會談準備 內(nèi)容：目的、參加人員、詳細問題、會談安排與通知；2. 進行會談 建議：衣著適當、準時到會、限制會談時間、尋找例外和錯誤條件、探討細節(jié)、作好筆記3. 會談總結(jié) 工作：消化、理解和存檔所獲得的信息，記錄未解決的問題，在此基礎上作出新問題列表，用郵件向用戶表示謝意。? 觀察業(yè)務流程和工作流? 方法的特點 “耳聽為虛，眼見為實 ”；是了解用戶實

41、際工作的最好方法。? 方法的形式快速調(diào)查現(xiàn)場 獲得現(xiàn)場的概貌，如布局、計算機設備的使用與需求、工作流1. 重點調(diào)查 解決其它形式存在的疑問1. 同用戶一道工作 消除用戶的局促感建立原型? 原型方法的進一步討論 原型法的基礎理念是一個較大的、較復雜的實體的初始的、工作模型； 模型根據(jù)其使用的目的不同，可分為：“扔掉的”原型、“發(fā)現(xiàn)”原型、設計原 型和發(fā)展原型。如何在需求階段使用原型 ?利用原型來實驗可行性、幫助確定流程需求。例如：屏幕的形式和報告方案； 使用“發(fā)現(xiàn)”原型來作為工作模型，以檢驗一個概念或驗證一種方法。? 如何建立有效的原型 ？-原型的特點可操作性不象實驗或教學用的實物大模型，僅顯示

42、一個外觀，不能操作。其應該提供 “ look and feel ”，僅缺乏一些功能；聚焦性雖然一個原型應著重于一個目的， 檢驗一個專門的概念或驗證一個特殊的方法， 若干個原型可以結(jié)合起來實驗若干個部件的集成；快速性需要CASE工具來幫助進行原型的快速建立和修改。召開聯(lián)合應用設計（JAD）會議? JAD的含義 是一個通過使所有必要的參與人員通過一個單獨的會議來定義需求或設計系統(tǒng)的技術(shù)? JAD的目的 是在會見用戶、寫出討論的記錄和建立模型，對模型進行評價和修改的基礎上， 為了解決一些仍未解決或難以解決的事情而舉行的。? JAD的時間 從幾周到幾個月，取決于系統(tǒng)的大小和可得的用戶和開發(fā)人員的資源；

43、一個會議可以是一天或一周?JAD的參與者JAD會議的主持人需要經(jīng)過訓練來確定會議的目的和議程，引導與會者討論，領導小組制定決策； 用戶所有有關的用戶，特別是有確定權(quán)的用戶。如果決策人不能參加整個會議，也 應到會就關鍵問題進行決策。否則，會議延期舉行。技術(shù)人員和項目開發(fā)組的技術(shù)專家? JAD的形式講座形式機房形式需求分析數(shù)據(jù)分析方法 -U/C 矩陣是基于 數(shù)據(jù)的靜態(tài)分析；U/C矩陣本質(zhì)是一種聚類方法，它可以用于過程的數(shù)據(jù)、功能/組織、功能/數(shù)據(jù)等各種分析中；U/C 矩陣是通過一個普通的二維表來分析匯總數(shù)據(jù)；數(shù)據(jù)正確性分析 基本原則是“數(shù)據(jù)守恒原理”，即數(shù)據(jù)必定有一個產(chǎn)生的源，而且必定有一個 或多

44、個用途數(shù)據(jù)項特征分析1 ）數(shù)據(jù)的類型以及精度和字長2 ）合理取值范圍3 ）數(shù)據(jù)量4 ）所涉及業(yè)務活動/數(shù)據(jù)矩陣 CRUDC = 產(chǎn)生新數(shù)據(jù)， R = 讀取已有數(shù)據(jù)， U = 修改已有數(shù)據(jù)， D = 刪除已有數(shù)據(jù) 需求定義 建模建立模型的目的有助于更清楚地、深入地了解和理解需求產(chǎn)生模型 -思考（提出）問題 -回答（解決） -增加新內(nèi)容 -進行評價 -提出問題-建立較完善的需求定義；有助于簡化問題，便于分析和設計工作系統(tǒng)的復雜性和無形性的特點所要求； 分而治之，一次僅解決系統(tǒng)的部分問題。有助于將系統(tǒng)需求定義形式化 收集和消化的信息量的巨大、開發(fā)時間的持續(xù)、人的記憶能力的限 制、回憶已完成工作的細節(jié)

45、的需要 模型以一個理解和消化后的形 式來提供所需信息；有助于信息的交流，是交流的工具開發(fā)人員內(nèi)部：不同部分之間互提資料 開發(fā)人員和用戶之間：利用模型檢驗是否正確地理解了需求，幫助 理解系統(tǒng)分析員的建議，理解系統(tǒng)所能提供的功能 開發(fā)人員、用戶和管理層：介紹系統(tǒng)性能供審查 為后續(xù)工作（開發(fā)、維護和升級等）提供文檔資料從建模過程中學習通過抽象降低復雜性記憶所有的細節(jié)同其他開發(fā)人員交流同各種用戶交流為將來的維護和改進提供文檔資料分析的集成視圖用例圖 系統(tǒng)與外部交互（行為） 。交互圖 -系統(tǒng)與系統(tǒng)內(nèi)部交互（動態(tài)） 。類圖-E-R 圖的 擴展。(剩下的沒記到)建立用例模型一般建立步驟確定參與者確定用例繪制

46、用例圖編寫用例的文字描述組織用例結(jié)構(gòu)引用 VS 擴展在對一個應經(jīng)存在的用例進行修改，如擴展或產(chǎn)生變化時，使用entend 在需要將在兩個以上事例中的共同行為提取到單個通用的用例中時，使用 include 一種 用例場景 的格式用例名稱( Title )用例的名稱，與在用例圖中的名稱一致；主要參與者( Primary actor )通常是一個用戶的角色利益相關者( Stakeholders ) 同用例功能有關的任何團體或個人。前置條件( Precondition ) 為了執(zhí)行用例必須滿足的條件。最小保障( Minimal guarantee )當服務失敗時，所可能產(chǎn)生的輸出成果保障( Succe

47、ss guarantee) 當服務成功時，所可能產(chǎn)生的輸出。觸發(fā)器( Trigger )！ =前置條件啟動用例的事件或活動。主成功場景( Main success scenario ) 描述在用例執(zhí)行過程中參與者和用例之間交互的主要活動序列。擴展場景( Extensions scenario ) 描述在用例執(zhí)行過程中參與者和用例之間交互的次要或不常發(fā)生的活動序 列。出錯場景( Precondition ) 詳細描述出錯時如何處理。組織用例 Include 關系兩個用例之間的連接；表示一個用例使用(引用)了另一個用例； 它允許將不同用例中的行為抽取出來放到其它獨立用例中， 類似編程中的公 共子程

48、序被其它用例使用。找出用例場景的共同事件流，用 <<Include>> 關聯(lián)表示包含 Extend 關系兩個用例之間的連接；通過增加新的表現(xiàn)或活動來擴展一個用例；特別的用例擴展通用的用例；對一個基用例添加額外的行為， 而基用例對插入不知情， 擴展的新用例在基 用例之上定義了某些特點并取而代之以新的行為。擴展常用于表示異常行為和特殊實例，以免使模型中的用例圖變得臃腫。根據(jù)需求的擴展發(fā)現(xiàn)特殊的用例，用<<Exte nd>>關聯(lián)來表示擴展概念數(shù)據(jù)模型概念數(shù)據(jù)模型也稱邏輯對象模型， 其是表示整體數(shù)據(jù)組織的詳細模型；其 是獨立于任何數(shù)據(jù)庫關系系統(tǒng)或者其它實

49、現(xiàn)的考慮事情；其用UML 的類圖表示。概念數(shù)據(jù)模型應反映客戶或用戶所理解的事物及其聯(lián)系， 它們代表了現(xiàn)實世 界存在的實體； 概念數(shù)據(jù)模型具體描述的內(nèi)容：一組領域概念；概念之間的聯(lián)系(關聯(lián)、聚 集和組成)；概念的屬性概念數(shù)據(jù)模型的元素類( Classes)屬性( Attributes )標識符 ( Identifiers )關系：關聯(lián)( Associations )、聚集(aggregations )、組成(compositions ) 泛化( Generalizations ) 時間維度( Time dimensions ) 完整性規(guī)則( Integrity rules ) 安全控制( Sec

50、urity controls )關系：關系可以是二元，三元或多元 關系的多重性：關系的一端可以連接任意個數(shù)的對象實例關聯(lián)類的概念特殊目的類， 其表示了在類和其所包含的屬性之間， 或其自身的一種關聯(lián) (關 系)關聯(lián)類的表示是一個用虛線連接到一個關聯(lián)的類關系的度 ( Relationship Degree )一個關聯(lián)涉及的類的數(shù)量 主要的度(例圖)一維：同一類對象之間的關聯(lián)(課程與先修課) 二維：兩個不同類的對象之間的關聯(lián)(雇員與部門) 三維：三個不同類的對象之間的關聯(lián)關系的多重性 (Relationship Multiplicity )能或者必須同類 B中每個對象關聯(lián)的類A中對象的數(shù)量范圍多重性

51、的構(gòu)成(例圖)最小基( A minimum cardinality )：類 A 對象可能的最小數(shù)量 最大基( A maximum cardinality )：類 A 對象可能的最大數(shù)量關系的種類關聯(lián)(Association )沒有對象是任何其它類的subordi nate聚集 (Aggregation)一種特殊的二元關聯(lián)，表示兩個概念之間整體與部分的關系；一個 類表示整體，其它的表示部分，但這是一個松散的耦合組成(Composition )是帶有牢固耦合的聚集，整體和部分缺一不可銀行與賬戶，整體對個體,銀行與雇員，整體對個體,1 n,實心菱形組成關系。賬戶依附于銀行。 n n，空心菱形聚合關系

52、。職員與經(jīng)理是雇員的繼承。雇員是職員經(jīng)理的泛化?？招娜切巍７夯?Generalization )或繼承(Inheritanee)泛化泛化是超類-子類的關系，一個類形成一個更廣泛的類別，而其它類是 這個分類中的子類別；這是一般化對象和具體化對象之間的一種分類關系繼承：一個子類將繼承其父類的所有屬性和操作；一個子類的實例包含其父類實例的所有相同的信息(加上更多的信息)對象關系建模-基于關系和面向?qū)ο蠹夹g(shù)，將概念數(shù)據(jù)模型轉(zhuǎn)換成邏輯數(shù)據(jù)模型標準化形式(Normal Forms )1st NF -所有的關系是第一范式(1NF)2nd NF -沒有部分鍵(partial-key )函數(shù)依賴的關系3rd

53、NF -沒有傳遞函數(shù)依賴的關系序歹卩圖(Sequenee Diagram)是一個UML圖表，用來表示對象之間的基于時序的交互，來執(zhí)行用例行為 的關鍵部分；交互是以消息的形式(例圖)；行為的相應被賦予給消息的接序列圖的目的是描述對象間的動態(tài)協(xié)作關系(例圖)；在序列圖中，最重要的一點是表達了對象間發(fā)送消息(Message)的時序。協(xié)作圖(Collaboration Diagram)是一個UML圖表，用來表示相互協(xié)作來執(zhí)行一個用例的所有對象的圖；協(xié)作圖的目的是確定哪些對象相互協(xié)作來執(zhí)行一個給定的商業(yè)功能，強調(diào)了對象之間的關系(協(xié)作圖例圖)；在協(xié)作圖中，交互作用是用編號的消息(Message )來表示

54、的序列圖和協(xié)作圖的關系共同點：都是交互作用圖(In teraction Diagram)；不同點：協(xié)作圖強調(diào)對象相互作用來支持一個用例，而序列圖更強調(diào)信息細節(jié)(動態(tài)、序列、時序)的本身。序列圖的組成符號參與者符號，由棍狀人形表示；對象符號，由帶有下劃線名稱的矩形表示；通信聯(lián)絡線(Lifeline )符號，由垂直虛線或垂直的窄矩形表示； 消息符號，由一個帶消息描述的方向箭頭表示。第五章 信息系統(tǒng)設計系統(tǒng)的應用架構(gòu)決定了系統(tǒng)的組成、組成部件之間的相互關系，組成部件之間的通訊 與協(xié)作，其是系統(tǒng)的總體結(jié)構(gòu)。系統(tǒng)的應用架構(gòu)通常簡稱為系統(tǒng)架構(gòu)，其包括系統(tǒng)的網(wǎng)絡架構(gòu)、系統(tǒng)的軟件架構(gòu)和系 統(tǒng)的數(shù)據(jù)庫架構(gòu)等。包圖(包圖的層次反應詳細程度