（1）以下有關模型的說法，錯誤的是
模型是對現實的簡化；
模型必須是視覺化的；
乙個好的模型包括那些有廣泛影響的主要元素；
通過建模，可以幫助人們解決理解複雜的問題；
（2）以下不是uml事物
結構事物
行為事物
分組事物
機制事物改為注釋事物
（3）在進行哪一項相關領域的應用開發時不推薦使用uml建模
數值計算、工業系統、資訊系統、軟體系統；
（4）哪一項不是軟體開發過程中可以盡量避免或者可以著力改進的問題
軟體開發沒有計畫性，進度的執行和實際情況有著很大的差距；
軟體需求分析階段工作不夠充分；
軟體開發過程中沒有統一的規範指導，參與軟體開發的人員各行其事；
軟體的開發過程中，必須投入大量的高強度的腦力勞動；
（5）不屬於軟體的生存期
計畫、編碼、測試、公升級；
（6）下列說法錯誤的是
用例既可以描述系統做什麼，又可以描述系統是如何被實現的；應該從參與者如何使用系統的角度出發定義用例，而不是從系統自身的角度；
基本能流程描述的是該用例最正常的一種場景，在基本流中系統執行一系列活動步驟來響應參與者提出的服務請求；
備選流負責描述用例執行過程中的異常或者偶爾發生的狀況；
（7）用例圖畫在rose的use case view檢視中
（8）以下關於模型的說法錯誤的是
模型是對現實的簡化，雖然模型對現實進行了簡化，但是不能改變或者歪曲任何重要細節；
模型可以是對乙個物件的縮微表示，或者是一種用於生產某種事物的模式，也可以是一種設計或者是乙個型別，還可以是乙個待模仿或者**的樣例；
不管專案是簡單還是複雜，都應該建造模型來描述它；
對乙個複雜的或者是重要的系統，有時候需要用多種模型對系統分別進行研究和描述；
（9）以下不是uml基本關係的是
依賴關係
泛化關係
協作關係改為關聯關係
實現關係
只有類可以實現介面，元件不能實現介面；
結構事物描述的是模型的靜態部分，行為事物描述的是模型的動態部分；
主要的分組事物是元件和包； 用例圖展示了一組用例、參與者以及他們之間的關係。他不但描述了系統可以幹什麼，而且描述了系統可以在如何幹；
活**是一種特殊的狀態圖
順序圖和協作圖都是互動圖，並且二者可以相互轉換；
uml建模知識點（一）
需求 設計源於需求，高於需求 需求和設計的區別 需求設計 賣的視角 做的視角 具體抽象 產品當專案做 專案當產品做 分析 為了滿足功能需求，找到系統的核心域機制 設計 為了滿足質量需求和設計規約，核心域機制如何對映到選定的平台 不同工作流的區別不在形式而在於內容 思考的邊界 不要把敏捷迭代作為偷懶的...
UML統一建模語言 知識點3 3類的關係
3.3類的關係 關係 relationship 是指事物之間的聯絡 泛化 實現 依賴和關聯都是重要的關係。泛化 generalization 是一般事物 稱為父類或超類 和較特殊事物 稱為子類或孩子類 之間的關係。級 一般類定義了共同的屬性和方法 特殊類繼承了一般類的屬性和方法 特殊類還可以定義自己...
統一建模語言（UML）
統一建模語言提供了一種表示法，通過它，我們可以獲取和說明程式設計。uml類圖描述系統中的類 它們之間的靜態關係 與類關聯的屬性和操作以及有關物件間連線的約束。uml類圖 在uml中，類由乙個矩形來表示，並且通常分割成3部分 類名 屬性和操作。上圖說明了乙個名為libraryitem的類名。該類有兩個...