第五章
1、重點用例分析(10分)DFD(10分)、類圖(10分)
2、建模原則(了解)建模的原則:選擇建立什么樣的模型對如何發現和解決問題具有重要的影響; 每個模型可以有多種表達方式;最好的模型總是能夠切合實際;孤立的模型是不完整的。任何好的系統都是由一些幾乎獨立的模型拼湊出來的。
UML建模(知道)背景:1994年10月,Rational公司的Booch和Rumbaugh決定將其Booch方法和OMT方法綜合成一個新的建模語言,并于1995年10月公布了Unified Method 0.8。
1995年秋季,Jacobson及其OOSE方法加入Rational公司,決定將OOSE方法與Unified Method進行綜合,更名為UML,并分別于1996年6月和10月公布了UML 0.9和UML 0.91。
1996年,DEC、HP、I-Logix、Intellicorp、IBM、ICON、MCI、Microsoft、Oracle、Rational、會,于1997 年1 月推出了UML 1.0,并向OMG 申請將其作為一種標準語言。1997 年9 月產生了UML 1.1,11 月被OMG 正式采納。1999 年6 月,OMG 發布了UML 1.3。1999 年7 月,UML RealTime 隨Rose RealTime 推出。2001 年9 月,OMG 發布了UML 1.4。 2004 年4 月,OMG 發布了UML 1.5。2005 年7 月,OMG 發布了UML 2.0。
用例:描述了一系列執行的活動所產生的一些輸出結果。每個用例描述了外部用戶如何來觸發系統必須響應的事件。在事件驅動模型中,系統的一切行為都被認為是對某個觸發事件的響應。
相關:用例是由外部用戶觸發;每個用例只描述單獨的任務,而不能描述多個任務;用例必須產生一個對用戶有意義的結果;場景(Scenario)是用例的一個執行實例,是例執行;過程中的一條實際路徑,一個用例可能會包含多個場景;
UML中的用例視圖只能反映出兩類信息:
1)哪些外部用戶會和統發生交互
2)系統需要實現哪些功能特性
基本信息:
1)每個用例都有一個名稱、編號和簡要描述。為了明確標識某些用例在整個系統中的相對重要性,需要使用優先級來表示。用例(use case)是一個行為上相關的步驟序列,代表的是一個相對完整的業務任務。UML中的用例是動作步驟的集合。動作(action)是系統的一次執行(能夠給某個參與者輸出結果值)。與參與者通信,或進行計算,或在系統內工作都可以稱作動作。用例應支持多種可能發生的動作,每個動作由許多具體步驟實現。
2)用例的元素:參與者是存在于系統之外并與系統交互的人或事。所謂“與系統交互”指的是參與者向系統發送消息,從系統中接收消息,或是在系統中交換信息。參與者是一個群體概念,代表的是一類能使用某個功能的人或事,參與者不是指某個個體。
3)輸入和輸出每一個用例的主要輸入、輸出連同其來源和目的都要進行描述。它包括所有可能的輸入輸出,而不僅僅是用來通常用的部分。建造用例是一個逐漸提煉的過程,用例在分析的過程中可以逐步的完善。
4)細節:用例需要描述詳細的步驟和它們所使用到的輸入和輸出,這些步驟就是用例中所執行的活動。
相關推薦:
2014年計算機軟件水平考試如何避免五大失誤北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內蒙古 |