2014年軟件水平考試《系統(tǒng)分析師》考點(5)

　　查看匯總：2014年軟件水平考試《系統(tǒng)分析師》考點匯總

　　第五章

　　1、重點用例分析(10分)DFD(10分)、類圖(10分)

　　2、建模原則(了解)建模的原則：選擇建立什么樣的模型對如何發(fā)現(xiàn)和解決問題具有重要的影響; 每個模型可以有多種表達方式;最好的模型總是能夠切合實際;孤立的模型是不完整的。任何好的系統(tǒng)都是由一些幾乎獨立的模型拼湊出來的。

　　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 月產(chǎn)生了UML 1.1，11 月被OMG 正式采納。1999 年6 月，OMG 發(fā)布了UML 1.3。1999 年7 月，UML RealTime 隨Rose RealTime 推出。2001 年9 月，OMG 發(fā)布了UML 1.4。 2004 年4 月，OMG 發(fā)布了UML 1.5。2005 年7 月，OMG 發(fā)布了UML 2.0。

　　用例：描述了一系列執(zhí)行的活動所產(chǎn)生的一些輸出結果。每個用例描述了外部用戶如何來觸發(fā)系統(tǒng)必須響應的事件。在事件驅動模型中，系統(tǒng)的一切行為都被認為是對某個觸發(fā)事件的響應。

　　相關：用例是由外部用戶觸發(fā);每個用例只描述單獨的任務，而不能描述多個任務;用例必須產(chǎn)生一個對用戶有意義的結果;場景(Scenario)是用例的一個執(zhí)行實例，是例執(zhí)行;過程中的一條實際路徑，一個用例可能會包含多個場景;

　　UML中的用例視圖只能反映出兩類信息：

　　1)哪些外部用戶會和統(tǒng)發(fā)生交互

　　2)系統(tǒng)需要實現(xiàn)哪些功能特性

　　基本信息：

　　1)每個用例都有一個名稱、編號和簡要描述。為了明確標識某些用例在整個系統(tǒng)中的相對重要性，需要使用優(yōu)先級來表示。用例(use case)是一個行為上相關的步驟序列，代表的是一個相對完整的業(yè)務任務。UML中的用例是動作步驟的集合。動作(action)是系統(tǒng)的一次執(zhí)行(能夠給某個參與者輸出結果值)。與參與者通信，或進行計算，或在系統(tǒng)內(nèi)工作都可以稱作動作。用例應支持多種可能發(fā)生的動作，每個動作由許多具體步驟實現(xiàn)。

　　2)用例的元素：參與者是存在于系統(tǒng)之外并與系統(tǒng)交互的人或事。所謂“與系統(tǒng)交互”指的是參與者向系統(tǒng)發(fā)送消息，從系統(tǒng)中接收消息，或是在系統(tǒng)中交換信息。參與者是一個群體概念，代表的是一類能使用某個功能的人或事，參與者不是指某個個體。

　　3)輸入和輸出每一個用例的主要輸入、輸出連同其來源和目的都要進行描述。它包括所有可能的輸入輸出，而不僅僅是用來通常用的部分。建造用例是一個逐漸提煉的過程，用例在分析的過程中可以逐步的完善。

　　4)細節(jié)：用例需要描述詳細的步驟和它們所使用到的輸入和輸出，這些步驟就是用例中所執(zhí)行的活動。

　　相關推薦：

　　2014年計算機軟件水平考試如何避免五大失誤

　　名師指導如何復習并通過2014年軟考開發(fā)類考試