Chapter5系統(tǒng)需求建模：事件和事物哈爾濱工業(yè)大學國家示范性軟件學院主講：范國祥2008.04本章主要內容

模型和建模事件和系統(tǒng)需求

事物和系統(tǒng)需求

實體-關系圖（ERD）類圖本章目標

解釋為何要建立信息系統(tǒng)模型描述三類模型，并列出一些分析和設計專用模型闡述如何使用事件來定義系統(tǒng)需求確定和分析系統(tǒng)做出響應的事件解釋如何用系統(tǒng)中事物的概念來定義需求比較數(shù)據實體和對象之間的異同確定和分析系統(tǒng)中需要的數(shù)據實體和對象閱讀、解釋并創(chuàng)建實體-關系圖閱讀、解釋并創(chuàng)建類圖引子-WaitersonCall–餐館送貨系統(tǒng)1.在發(fā)生如下事件時，系統(tǒng)

可以進行處理：客戶打電話下訂餐訂單客戶打電話修改訂單送貨司機匯報工作情況送貨司機上交一天的收入2.在特定時間內系統(tǒng)產生所

需信息：生成日結算存款單生成周末餐館支付帳單生成周銷售報表生成月財務報表3.需要建立數(shù)據庫存儲如下信息：餐館菜單客戶訂單訂單支付帳單司機（送餐員）4.系統(tǒng)還需要處理以下情況新餐館加盟餐館更改了菜單雇傭了新的送貨司機（送餐員）送貨司機（送餐員）離職分析員需要一組模型來充分描述信息

系統(tǒng)的需求不同的模型分別顯示了問題和解決方

案的不同部分5.1模型和建模5.1模型和建模5.1模型和建模5.1.1模型的作用

建立模型的過程能幫助分析員澄清和改良設計系統(tǒng)往往很復雜，模型能很好表示各部分之間的關系

模型便于項目組成員之間交流

模型有助于和系統(tǒng)用戶之間進行交流并促進理解

建立的模型可以作為以后的維護和升級時的文檔在建模中了解信息通過抽象降低系統(tǒng)的復雜性有助于回憶所有的細節(jié)有助于和用戶及系統(tǒng)相關者進行交流為以后的維護和升級提供了文檔

5.1.2模型的類型

數(shù)學模型：描述系統(tǒng)技術方面的一系列數(shù)學公式

描述模型：描述系統(tǒng)某些方面的敘述性的備忘錄、

報表、列表、文字等圖形模型：描述系統(tǒng)的圖表或系統(tǒng)某些方面的示

意性表示三種常見模型：數(shù)學模型、描述模型、圖形模型5.1.3用于分析和設計的模型狀態(tài)圖協(xié)作圖

時序圖用例圖

類圖結構化英語/偽代碼數(shù)據元素定義數(shù)據流定義ERDDFD事件列表分析階段創(chuàng)建的模型界面設計報表設計數(shù)據庫設計

結構圖

系統(tǒng)流程圖

網絡圖

分布圖設計階段創(chuàng)建的模型5.2事件和系統(tǒng)需求信息系統(tǒng)的所有處理過程都是由事件驅動或觸發(fā)的，

因此當定義系統(tǒng)需求時將所有事件羅列出來并加以分

析是非常有意義的事件：發(fā)生在某一特定的時間和地點、可描述并且系統(tǒng)應該

記錄下來的事情事件和系統(tǒng)需求的關系：什么事件發(fā)生時需要系統(tǒng)做出響應，

能列出所有這樣的事件應該說就可以搞清楚用戶對系統(tǒng)的需求5.2事件和系統(tǒng)需求過賒購帳處理系統(tǒng)：外部三個事件，內部三個事件5.2.1事件的類型

外部事件：系統(tǒng)之外發(fā)生的事件，通常是由外部實體或

動作參與者觸發(fā)的

臨時事件：由于到達某一時刻所發(fā)生的事件

狀態(tài)事件：當系統(tǒng)內部發(fā)生了需要處理的情況時所引發(fā)

的事件事件分三大類：外部事件、臨時事件、狀態(tài)事件5.2.1事件的類型外部事件應包括：外部實體的需要觸發(fā)一個事務處理，如客戶下訂單外部實體想獲得某些信息，如客戶查詢帳戶信息數(shù)據發(fā)生改變需要更新，如客戶地址變更管理部門想獲取某些信息，如管理者需要銷售情況分析報告臨時事件應包括：所需的內部輸出結果，如定期報表

所需的外部輸出結果，如定期結算單、帳單等

突發(fā)的情況，如系統(tǒng)掉電、內存溢出、讀寫錯誤、缺頁狀態(tài)事件應包括：所有外部事件和臨時事件都要考慮是否有狀態(tài)事件發(fā)生，

如，銷售引起庫存變化等5.2.2事件定義客戶走進沃爾瑪客戶在沃爾瑪試穿襯衫客戶購買一件襯衫

（該事件直接影響系統(tǒng)）客戶想買一件新襯衫客戶開車來到購物中心客戶在Sears試穿襯衫導致影響系統(tǒng)的一個事物的一系列行為區(qū)分事件和隨事件發(fā)生的一部分交互行為5.2.2事件定義外部事件應包括：外部實體的需要觸發(fā)一個事務處理，如客戶下訂單外部實體想獲得某些信息，如客戶查詢帳戶信息數(shù)據發(fā)生改變需要更新，如客戶地址變更管理部門想獲取某些信息，如管理者需要銷售情況分析報告臨時事件應包括：所需的內部輸出結果，如定期報表

所需的外部輸出結果，如定期結算單、帳單等狀態(tài)事件應包括：所有外部事件和臨時事件都要考慮是否有狀態(tài)事件發(fā)生，

如，銷售引起庫存變化等客戶查詢訂單狀態(tài)客戶修改帳戶信息客戶退貨用戶想要一本商品目錄客戶想確定商品信息的有效性客戶下訂單客戶修改或取消訂單導致許多事件的某一特定客戶的“事務”處理序列跟蹤事務處理生命周期可以得到一系列事件5.2.2事件定義外部事件應包括：外部實體的需要觸發(fā)一個事務處理，如客戶下訂單外部實體想獲得某些信息，如客戶查詢帳戶信息數(shù)據發(fā)生改變需要更新，如客戶地址變更管理部門想獲取某些信息，如管理者需要銷售情況分析報告臨時事件應包括：所需的內部輸出結果，如定期報表

所需的外部輸出結果，如定期結算單、帳單等狀態(tài)事件應包括：所有外部事件和臨時事件都要考慮是否有狀態(tài)事件發(fā)生，

如，銷售引起庫存變化等系統(tǒng)崩潰，需要恢復數(shù)據庫該備份數(shù)據庫了用戶該修改密碼了用戶登錄系統(tǒng)用戶需要更改密碼系統(tǒng)要改變系統(tǒng)性能設置在設計階段之前可以忽略的事件特別細節(jié)的事件在系統(tǒng)分析階段不予考慮5.2.3系統(tǒng)需求建模：事件列表事件列表屬于“描述性模型”事件表各段信息的格式如下事件觸發(fā)器來源活動/用例響應目的地5.2.3系統(tǒng)需求建模：事件列表5.2.3系統(tǒng)需求建模：事件列表5.3事物和系統(tǒng)需求事件和事物的區(qū)別與聯(lián)系：

事件–發(fā)生在瞬間，有一定的隨機性

事物–客觀存在，不以主觀意志為轉移

聯(lián)系–事件的發(fā)生可以改變事物的狀態(tài)或產生新的事物事物：在傳統(tǒng)的開發(fā)方法中，事物就是構成系統(tǒng)存儲

信息的相關數(shù)據在面向對象的開發(fā)方法中，事物就是在系統(tǒng)中

相互交互的對象飛機書汽車文檔工作表雇員顧客醫(yī)生病人最終用戶系統(tǒng)管理員管區(qū)部門工段任務組工作組傳感器定時器控制器打印機磁盤驅動器鍵盤顯示器窗口鼠標菜單按鈕航班服務電話登錄退出合同購買訂單支付倉庫部門辦公室工廠零售店桌面5.3事物和系統(tǒng)需求5.3.1事物的類型事物實物角色組織部門設備偶然事件、

事件或交互地點/位置5.3事物和系統(tǒng)需求5.3.2開發(fā)事物初始列表的過程第一步：收集可能得到的名詞方法1：與客戶談話中獲得方法2：使用事件表及關于每一事件的信息獲得方法3：使用已有系統(tǒng)、當前過程及報表中獲得第二步：將名詞列表精簡并記錄假設/要檢查的問題5.3事物和系統(tǒng)需求5.3.2開發(fā)事物初始列表的過程第二步：將名詞列表精簡并記錄假設/要檢查的問題（1）確定名詞是否應包含在列表中是系統(tǒng)需要了解的獨特的事物嗎？在你所工作的系統(tǒng)的范圍之內嗎？系統(tǒng)需要記住多于這些項目的一個嗎？（2）確定每個名詞是否應該從列表中將其排除與你已經定義的某個其它事物是同義詞嗎？真的是從你已經定義的其他信息中產生的系統(tǒng)輸出嗎？這一輸入真的可以導致記錄一些你已經定義的其他信息嗎？（3）對每個名詞提出問題確定是否應該對其進行進一步的研究可能是你已經定義的其他事物的一些具體信息（屬性）嗎？是當假設變化時你可能需要的事物嗎？5.3事物和系統(tǒng)需求開發(fā)事物初始列表的過程5.3事物和系統(tǒng)需求開發(fā)事物初始列表的過程包含包含訂單#1043財務部紅襯衫

尺寸16/32牛仔褲尺寸：

34長被訂購工作在Smith先生事物之間自然發(fā)生的關系5.3事物和系統(tǒng)需求5.3.3事物間的關系關系：某些事物間自然發(fā)生的聯(lián)系，比如客戶

發(fā)送訂單、雇員在某部門工作等5.3事物和系統(tǒng)需求5.3.3事物間的關系根據每件事物的關聯(lián)數(shù)目來理解每種關系的本質非常重要基數(shù)（重數(shù)）：發(fā)生在事物間關聯(lián)的數(shù)目

例如一個客戶發(fā)送量多個訂單

一個雇員在一個部門工作等

基數(shù)可以：0，1，0..n，1..n二元關系：兩種不同類型事物之間的關系，如Teacher與Student一元(回歸)關系：同一類型的兩個事物間的關系，例如一個人和

另一個人的婚姻關系三元關系：三種不同類型事物之間的關系，

如Course、Teacher和Studentn元關系：n（n為任意數(shù)）種不同類型事物之間的關系5.3事物和系統(tǒng)需求5.3.4事物的屬性屬性：有關事物的一條特定信息標示符（關鍵字）：能唯一標志事物的一個屬性復合屬性：包括了許多相關屬性的屬性，如客戶全名：名+姓5.3事物和系統(tǒng)需求5.3.5數(shù)據實體和對象數(shù)據實體：在傳統(tǒng)的系統(tǒng)開發(fā)方法中，事物被稱為數(shù)據實體對象：在面向對象的系統(tǒng)開發(fā)方法中，將某一個事物稱為對象數(shù)據實體與過程是分離的對象將數(shù)據和處理數(shù)據的方法封裝成一個單元要讓某個對象執(zhí)行

某種操作，可以讓

另外一個對象給該

對象發(fā)送一個消息5.4實體-關系圖傳統(tǒng)的系統(tǒng)開發(fā)方法都將重點集中在數(shù)據存儲需求上數(shù)據存儲需求包括數(shù)據實體、數(shù)據實體的屬性以及它

們之間的關系一個客戶可以發(fā)送

0個或多個訂單一個訂單必須對應一個客戶5.4.1ERD概念的實例5.4實體-關系圖只能一個（強制）0或多個（可選）1或多個（強制）0或1個（可選）實體之間關系的基數(shù)符號5.4.1ERD概念的實例5.4實體-關系圖帶有屬性的擴展ERD圖*表示標識符或關鍵字5.4.1ERD概念的實例5.4實體-關系圖5.4.1ERD概念的實例圖5-21客戶、訂單和訂單中的商品該圖顯示了實際的數(shù)據在事務處理中呈現(xiàn)的形式5.4實體-關系圖5.4.1ERD概念的實例分析員在建模的過程中，常常對ERD進行細化的工作就是

處理多對多的關系由于關系數(shù)據庫中不能直接實現(xiàn)多對多的關系，因此必

須建立一個單獨的表，來消除多對多的關系

關聯(lián)實體

–解決上述問題的人為增加的數(shù)據實體，它

一定包含兩端數(shù)據實體的關鍵字5.4實體-關系圖5.4.1ERD概念的實例5.4實體-關系圖5.4.2RMO商店實例的ERD圖“產品”可在多個目錄中列出，而一個“目錄”可以列出多個“產品”，需用一個關聯(lián)實體“商品目錄”“退回商品”是關聯(lián)實體嗎？復雜的多元關系“發(fā)貨員”和“發(fā)貨部門”的關系完全是一種業(yè)務規(guī)則，與公司規(guī)定相關5.5類圖面向對象的方法也強調對系統(tǒng)中所包含事物的理解面向對象的方法給事物建立的模型即是“類圖”“類”和“實體”是明顯區(qū)別的5.5類圖5.5.1有關對象類的更復雜的問題

概括/具體層次圖–把類按照從最概括的父類到

最具體的子類的順序進行排列的層次圖，有時

也被稱作繼承層次圖

繼承

–允許子類共享其父類的所有的特征5.5類圖5.5.1有關對象類的更復雜的問題

概括/具體層次圖機動車輛小汽車卡車拖拉機轎車跑車體育用車機動車輛的概括/具體層次圖（繼承關系）5.5.1有關對象類的更復雜的問題

概括/具體層次圖5.5類圖訂單電話訂單網上訂單郵件訂單5.5.1有關對象類的更復雜的問題

整體/局部層次圖：按照類之間的關聯(lián)組件將類進行

結構化分解的層次圖

聚合：對象及其各個部分之間的一種整體-局部關系

組成：對象及其與它不可分割的各個部分之間的一種