第一篇：UML九種視圖總結

1.UML關系

UML類圖中的關系分為四種：泛化關系、依賴關系、關聯關系、實現關系；關聯關系又可以細化為聚合和組合。

1.1 泛化（Generalization)泛化是父類和子類之間的關系，子類繼承父類的所有結構和行為。在子類中可以增加新的結構和行為，也可以覆寫父類的行為。

1.2.依賴（Dependencies）

依賴關系是一種使用關系，特定事物的改變有可能會影響到使用該事物的事物，反之不成立。在你想顯示一個事物使用另一個事物時使用，兩個元素之間的一種關系，其中一個元素（服務者）的變化將影響另一個元素（客戶），或向它（客戶）提供所需信息。它是一種組成不同模型關系的簡便方法。依賴表示兩個或多個模型元素之間語義上的關系。它只將模型元素本身連接起來而不需要用一組實例來表達它的意思。它表示了這樣一種情形，提供者的某些變化會要求或指示依賴關系中客戶的變化。

根據這個定義，關聯和泛化都是依賴關系，但是它們有更特別的語義，故它們有自己的名字和詳細的語義。我們通常用依賴這個詞來指其他的關系。依賴用一個從客戶指向提供者的虛箭頭表示，用一個構造型的關鍵字來區分它的種類，通常情況下，依賴關系體現在某個類的方法使用另一個類作為參數。

1.3.關聯（Association）

關聯是一種結構化的關系，指一種對象和另一種對象有聯系。給定有關聯的兩個類，可以從一個類的對象得到另一個類的對象。

類與類之間由弱到強關系是: 沒關系 > 依賴 > 關聯 > 聚合 > 組合。

類和類之間八竿子打不著那就是沒關系，這個沒啥歧義。依賴(dependency)

可以簡單的理解，就是一個類A使用到了另一個類B，而這種使用關系是具有偶然性的、、臨時性的、非常弱的，但是B類的變化會影響到A；比如某人要過河，需要借用一條船，此時人與船之間的關系就是依賴；表現在代碼層面，為類B作為參數被類A在某個method方法中使用。用帶虛線的箭頭。

關聯(association)

他體現的是兩個類、或者類與接口之間語義級別的一種強依賴關系，比如我和我的朋友；這種關系比依賴更強、不存在依賴關系的偶然性、關系也不是臨時性的，一般是長期性的，而且雙方的關系一般是平等的、關聯可以是單向、雙向的；表現在代碼層面，為被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯類A引用了一個類型為被關聯類B的全局變量；

依賴和關聯區別：我用錘子修了一下桌子，我和錘子之間就是一種依賴，我和我的同事就是一種關聯。依賴是一種弱關聯，只要一個類 用到另一個類，但是和另一個類的關系不是太明顯的時候（可以說是“uses”了那個類），就可以把這種關系看成是依賴，依賴也可說是一種偶然的關系，而不是必然的關系。關聯是類之間的一種關系，例如老師教學生，老公和老婆這種關系是非常明顯的。依賴是比較陌生，關聯是我們已經認識熟悉了。

1.3.1 聚合（Aggregation）

聚合是一種特殊的關聯。它描述了“has a”關系，表示整體對象擁有部分對象。

關聯關系和聚合關系來語法上是沒辦法區分的，從語義 上才能更好的區分兩者的區別。聚合是較強的關聯關系，強調的是整體與部分 之間的關系。

與關聯關系一樣，聚合關系也是通過類的成員變量 來實現的。

1.3.2 組合（Composition）

組合是聚合的一種形式，它具有更強的擁有關系，強調整體與部分的生命周期 是一致的。整體負責部分的生命周期的管理。如果整體被銷毀，部分也必須跟著一起被銷毀，如果所有者被復制，部分也必須一起被復制。

與關聯關系一樣，組合關系也是通過類的成員變量 來實現的。

1.4.實現（Realization）

實現關系指定兩個實體之間的一個合約。換言之，一個實體定義一個 合約，而另一個實體保證履行該 合約。

1.5 擴展關系(extends)1.6 包含(include)

1.7 精化關系（refine）UML視圖

說明：

構件事物是名詞，是模型的靜態部分。行為事物是動態部分，表示行為。分組事物是組織部分。注釋事物是解釋部分。

依賴：一個事物變化會引起另一個事物變化。聚集：特殊的關聯，描述整體與部分的組合關系。

泛化：是一種特殊與一般的關系，如子元素（特殊）與父元素（一般），箭頭指向父元素。實現：類元之間的關系，其中一個類元指定了由另一個類元保證執行的契約。一般用在接口和實現他們的類之間或用例和實現它們的協作之間。

2.1 類圖

用于展現系統中的類以及其之間的關系

對象圖：顯示了單獨的對象及其關系。對象圖有助于記錄測試用例以及討論用例。

?靜態圖：包括類圖和對象圖。

類圖描述系統中類的靜態結構，不僅定義系統中的類，表示類之間的聯系，如關聯、依賴、聚合等，也包括類的屬性和操作，類圖描述的是一種靜態關系，在系統的整個生命周期都是有效的。

對象圖是類圖的實例，幾乎使用與類圖完全相同的標識。一個對象圖是類圖的一個實例。由 于對象存在生命周期，因此對象圖只能在系統某一時間段存在。2.1.1 包

包可直接理解為命名空間，文件夾，是用來組織圖形的封裝，包圖可以用來表述功能組命名空間的組織層次。

?在面向對象軟件開發的視角中，類顯然是構建整個系統的基本構造塊。但是對于龐大的應用系統而言，其包含的類將是成百上千，再加上其間“阡陌交縱”的關聯關系、多重性等，必然是大大超出了人們可以處理的復雜度。這也就是引入了“包”這種分組事物構造塊。?包的作用是：

1）對語義上相關的元素進行分組； 2）定義模型中的“語義邊界”； 3）提供配置管理單元；

4）在設計時，提供并行工作的單元；

5）提供封裝的命名空間，其中所有名稱必須惟一

上圖解釋

?首先根據《use》關系，可以發現Client包使用Server包，Server包使用System.Data.SqlClient包，結合其元素，不難得知Client負責Order（訂單）的輸入，并通過Server來管理用戶的登錄（LoggingService）和數據庫存儲（DataBase），而Server包還將通過.NET的SQL Server訪問工具包來實現與數據庫的實際交互。?接著再看兩個《import》，從包的命名和其所屬的元素不難發現Rule負責處理一些規則，并引用一個具體的窗體（Window），而Client包則通過引用Rule來實現整個窗體和表單的顯示、輸入等。并且還將暫存Order（訂單）信息。?最后來看包的泛化關系，GUI有兩個具體實現，一個是針對C/S的WindowsGUI，一個是實現B/S的WebGUI。依賴關系

?《use》使用關系：是一種默認的依賴關系，說明客戶包（發出者）中的元素以某種方式使用提供者包（箭頭指向的包）的公共元素，也就是說客戶包依賴于提供者包

?《import》引用關系：最普遍的包依賴類型，說明提供者包(箭頭指向的包)的命名空間（包本身代表命名空間）將被添加到客戶包（發出者）的命名空間中，客戶包中的元素也能夠訪問提供者包的所有公共元素

?《access》訪問關系：只想使用提供者包中的元素，而不想將其命名空間合并則應使用該關系

?《trace》追溯關系：想表示一個包到另一個包的歷史發展，則需要使用《trace》關系來表示

例子描述

?分析系統工作流程：

1）通過Internet連接到股票信息服務器，獲取實時的股票信息，并存入數據庫中。2）根據用戶的輸入和選擇，從數據庫中獲取相應的信息，展現在屏幕中。3）在數據的展現過程中，將需要繪制大量的圖表 ?根據功能模塊組織包：

包之間的依賴關系

2.2 狀態圖

展示了一個狀態機，由狀態、轉換、事件和活動組成。強調事件行為的順序。如下圖(摘自網絡)：

2.2.1 事件

事件是指某個時刻發生的事情。

信號是指從一個對象到另一個對象的明確的單向信號流動。

信號事件：是指發送或者接受信號的事件。

區別：信號是對象間的消息，而信號事件是指某個時刻發生的事情。

變更事件：是指滿足布爾表達式而引起的事件。

時間事件：是指在絕對時間上或者在某個時間間隔內發生的事情而引起的事件。

2.2.2 狀態

是對象取值和鏈接的抽象。根據對象的總體行為，將取值和鏈接的集合組成一個狀態。

事件表示時間點，狀態表示時間段。

2.2.3 遷移

是指從一種狀態到另一種狀態的瞬時變化。

2.2.4 電話狀態圖

2.2.5 活動 2.2.6 增加了活動的電話狀態圖 2.2.7 嵌套狀態圖

嵌套狀態

2.3 用例圖

描述一組用例、參與者以及它們之間的關系，其展示的是該系統在它 的外面環境中所提供的外部可見服務

2.3.1 用例中的包含

包含關系：使用包含（Inclusion）用例來封裝一組跨越多個用例的相似動作（行為片斷），以便多個基（Base）用例復用。基用例控制與包含用例的 關系，以及被包含用例的事件流是否會插入到基用例的事件流中。基用例可以依賴包含用例執行的結果，但是雙方都不能訪問對方的屬性。2.3.2 擴展

將基用例中一段相對獨立并且可選的動作，用擴展（Extension）用例加以封裝，再讓它從基用例中聲明的擴展點（Extension Point）上進行擴展，從而使基用例行為更簡練和目標更集中。擴展用例為基用例添加新的行為。擴展用例可以訪問基用例的屬性，因此它能根據基用例中擴展點的當前狀態來判斷是否執行自己。但是擴展用例對基用例不可見。

2.3.3 泛化

泛化關系：子用例和父用例相似，但表現出更特別的行為；子用例將繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。在實際應用中很少使用泛化關系，子用例中的特殊行為都可以作為父用例中的備選流存在。2.3.4 實例

2.4 交互圖

場景是指系統在某個特定的執行期內發生的一系列事件。

包括序列圖（順序圖）和協作圖，兩者對應，順序圖是強調消息時間順序，有對象生命線和控制焦點。

協作圖是強調接收和發送消息的對象的結構組織，有路徑和順序號

交互圖強調的是對象到對象的控制流，而活動圖則強調的是從活動到活動的控制流

?活動圖是一種表述過程基理、業務過程以及工作流的技術。它可以用來對業務過程、工作流建模，也可以對用例實現甚至是程序實現來建模

2.4.1 順序圖

顯示了交互的參與者以及參與者之間的消息順序。也顯示了系統為了執行全部或部分用例而與參與者的交互。

2.4.2 活動圖

顯示了組成復雜過程的步驟序列。

活動圖的主要元素

?初始節點和活動終點：用一個實心圓表示初始節點，用一個圓圈內加一個實心圓來表示活動終點

?活動節點：是活動圖中最主要的元素之一，它用來表示一個活動

?轉換：當一個活動結束時，控制流就會馬上傳遞給下一個活動節點，在活動圖中稱之為“轉換”，用一條帶箭頭的直線來表示 活動圖的主要元素

?分支與監護條件：分支是用菱形表示的，它有一個進入轉換（箭頭從外指向分支符號），一個或多個離開轉換（箭頭從分支符號指向外）。而每個離開轉換上都會有一個監護條件，用來表示滿足什么條件的時候執行該轉換。

?分岔與匯合：

修改后的簡單活動圖

帶泳道的活動圖

帶對象流的活動圖 復雜活動圖 ?輔助活動圖：

?匯合描述：當匯合的所有入流均到點匯合點時，就將執行匯合點指向的活動節點。但是有些時候，你希望對其做一些約束，這時就可以借助匯合描述來完成。匯合描述實際上是一個約束，其格式就是“{約束條件}”。?發送信號與接收信號：

?如何繪制活動圖 繪制活動圖

?“活動圖” 比較直觀易懂；與傳統的流程圖十分的相近，只要能夠讀懂活動圖，就不難畫出活動圖

?繪制時首先決定是否采用泳道：主要根據活動圖中是否要體現出活動的不同實施者 ?然后盡量使用分支、分岔和匯合等基本的建模元素來描述活動控制流程

?如果需要，加入對象流以及對象的狀態變化，利用一些高級的建模元素（如輔助活動圖、匯合描述、發送信號與接收信號、引腳、擴展區）來表示更多的信息

?活動圖的建模關鍵是表示出控制流，其它的建模元素都是圍繞這一宗旨所進行的補充 工作流程，控制流程，業務流程中使用。

? ?活動圖應用說明

活動圖應用說明

?對工作流建模：用于業務建模的時候，每一條泳道表示一個職責單位，該圖能夠有效地體現出所有職責單位之間的工作職責，業務范圍及之間的交互關系、信息流程 建模時應遵循以下策略： ?為工作流建立一個焦點，除非你所涉及的系統很小，否則不可能在一張圖中顯示出系統中所有的控制流

?選擇對全部工作流中的一部分有高層職責的業務對象，并為每個重要的業務對象創建一條泳道

?識別工作流初始節點的前置條件和活動終點的后置條件，這可有效地實現對工作流的邊界進行建模。

?從該工作流的初始節點開始，說明隨時間發生的動作和活動，并在活動圖中把它們表示成活動節點

?將復雜的活動或多次出現的活動集合歸到一個活動節點，并通過輔助活動圖或子活動圖來表示它們

?找出連接這些活動節點的轉換，首先從工作流的順序開始，然后考慮分支，接著再考慮分岔和匯合

?如果工作流中涉及重要的對象，則也可以將它們加入到活動圖中 ?若工作流中有多次啟用的，則可采用展開區表示

?對操作建模：每一個對象占據一個泳道，而活動則是該對象的成員方法 ?建模時應遵循以下策略：

--收集操作所涉及的抽象概念，包括操作的參數、返回類型、所屬類的屬性以及某些鄰近的類

--識別該操作的初始節點的前置條件和活動終點的后置條件。也要識別在操作執行過程中必須保持的信息

--從該操作的初始節點開始，說明隨著時間發生的活動，并在活動圖中將它們表示為活動節點

--如果需要，使用分支來說明條件語句及循環語句

--僅當這個操作屬于一個主動類時，才在必要時用分岔和匯合來說明并行的控制流程 構件圖

2.5 構件圖

類是最基礎的“模塊化”元素，它封裝了屬性和成員的方法，就像是物理世界中的“分子”。但是，對于復雜的軟件系統而言，往往擁有成百上千的各種類。因此，類的粒度太小了，引入更粗的粒度的概念—“構件”

構件是系統中可替換的物理部分，它包裝了實現而且遵從并提供一組接口的實現。通俗的說，構件是系統設計的一個模塊化元素，它隱藏了內部的實現，對外提供一組外部接口。在系統中，滿足相同接口的組件可以自由地替換。

1、構件的表示方法

和類的名稱相近，構件的名稱也是一個正文字符串，它可以是簡單名，也可以是帶路徑的全名。

2、構件圖實例：

2.6 部署圖

1、部署圖描述了一個系統運行時的硬件節點，在這些節點上運行的軟件構件將在何處物理運行以及它們將如何彼此通信的靜態視圖。

部署圖包括兩種基本模型元素：節點和節點間的連接。每個模型中，僅包含一個部署圖。節點包括兩種類型：處理器和設備。

處理器指本身具有計算能力且能執行各各軟件的節點，如服務器。

處理器具有處理能力，所以在描述處理器方面應當包含了處理器的調度和進程。

調度指在處理器處理其進程中為實現一定的目的而對共同使用的資源進行時間分配。調度方式包含：搶占，無優先級，循環，算法控制，手動執行。進程表示一個單獨的控制純種，是系統中一個重量級的并發和執行單元。

設備指本身不具備處理能力的節點，如打印機。

連接用來表示兩個節點之間的硬件連接。節點之間的連接可以通過光纜直接進行，或通過衛星等方式非直接連接，通常連接都是雙向的。連接用實線表示，實線上可加連接名和構造型。

系統開發人員和部署人員可以利用部署圖去了解系統的物理運行情況。如果，開發的軟件系統只需在一臺計算機上運行，且使用的標準設備，則不需要為它畫出系統部署圖。部署圖只需要給那些復雜的物理運行情況進行建模。

部署圖顯示了系統的硬件，安裝在硬件上的軟件，用于連接硬件的各種協議和中間件等。

2、部署模型的目的：

描述一個具體應用的主要部署結構，通過對各種硬件，在硬件中的軟件以及各種連接協議的顯示，可以很好的描述系統是如何部署的；平衡系統運行時的計算資源分布；可以通過連接描述組織的硬件網絡結構或者是嵌入式系統等具有多種硬件和軟件相關的系統運行模型。

3、部署圖實例：

第二篇：oracle視圖總結

oracle視圖總結(轉)

視圖簡介: 視圖是基于一個表或多個表或視圖的邏輯表，本身不包含數據，通過它可以對表里面的數據進行查詢和修改。視圖基于的表稱為基表。視圖是存儲在數據字典里的一條select語句。通過創建視圖可以提取數據的邏輯上的集合或組合。

視圖的優點：

1.對數據庫的訪問，因為視圖可以有選擇性的選取數據庫里的一部分。2.用戶通過簡單的查詢可以從復雜查詢中得到結果。3.維護數據的獨立性，試圖可從多個表檢索數據。4.對于相同的數據可產生不同的視圖。

視圖的分類：

視圖分為簡單視圖和復雜視圖。

兩者區別如下：

1.簡單視圖只從單表里獲取數據，復雜視圖從多表獲取數據； 2.簡單視圖不包含函數和數據組，復雜視圖包含； 3.簡單視圖可以實現DML操作，復雜視圖不可以。

視圖的創建：

CREATE [OR REPLACE] [FORCE|NOFORCE] VIEW view_name [(alias[, alias]...)] AS subquery [WITH CHECK OPTION [CONSTRAINT constraint]] [WITH READ ONLY] 其中：

OR REPLACE：若所創建的試圖已經存在，ORACLE自動重建該視圖； FORCE：不管基表是否存在ORACLE都會自動創建該視圖； NOFORCE：只有基表都存在ORACLE才會創建該視圖： alias：為視圖產生的列定義的別名；

subquery：一條完整的SELECT語句，可以在該語句中定義別名；

WITH CHECK OPTION ： 插入或修改的數據行必須滿足視圖定義的約束； WITH READ ONLY ： 該視圖上不能進行任何DML操作。

例如： Sql代碼

1.CREATE OR

REPLACE

VIEW dept_sum_vw

2.(name,minsal,maxsal,avgsal)

3.AS SELECT d.dname,min(e.sal),max(e.sal),avg(e.sal)

4.FROM

emp e,dept d

5.WHERE e.deptno=d.deptno

6.GROUP BY d.dname;

視圖的定義原則：

1.視圖的查詢可以使用復雜的SELECT語法，包括連接/分組查詢和子查詢； 2.在沒有WITH CHECK OPTION和 READ ONLY 的情況下，查詢中不能使用 ORDER BY 子句；

3.如果沒有為CHECK OPTION約束命名，系統會自動為之命名，形式為SYS_Cn;4.OR REPLACE選項可以不刪除原視圖便可更改其定義并重建，或重新授予對象權限。

查詢視圖：

視圖創建成功后，可以從視圖中檢索數據，這點和從表中檢索數據一樣。示例：

SQL>SELECT * FROM dept_sum_vw；

修改視圖：

通過OR REPLACE 重新創建同名視圖即可。

刪除視圖：

DROP VIEW VIEW_NAME語句刪除視圖。刪除視圖的定義不影響基表中的數據。

只有視圖所有者和具備DROP VIEW權限的用戶可以刪除視圖。視圖被刪除后，基于被刪除視圖的其他視圖或應用將無效。

查詢視圖定義：

SELECT view_name,text from user_views;其中text顯示的內容為視圖定義的SELECT語句，可通過DESC USER_VIEWS 得到相關信息。

視圖上的DML 操作： DML操作應遵循的原則：

1.簡單視圖可以執行DML操作； 2.在視圖包含GROUP 函數，GROUP BY子句，DISTINCT關鍵字時不能刪除數據行； 3.在視圖不出現下列情況時可通過視圖修改基表數據或插入數據：

a.視圖中包含GROUP 函數，GROUP BY子句，DISTINCT關鍵字； b.使用表達式定義的列； c.ROWNUM偽列。

d.基表中未在視圖中選擇的其他列定義為非空且無默認值。WITH CHECK OPTION 子句

通過視圖執行的INSERTS和UPDATES操作不能創建該視圖檢索不到的數據行，因為它會對插入或修改的數據行執行完整性約束和數據有效性檢查。（也就是說在執行INSERTS、UPDATES時，WHERE條件中除需要INSERT、UPDATE本身的限制條件之外，還需要加上視圖創建時的WHERE條件。）

例如：

CREATE OR REPLACE VIEW vw_emp20 AS SELECT * FROM emp WHERE deptno=20 WITH CHECK OPTION constraint vw_emp20_ck;視圖 已建立。

查詢結果：

SELECT empno,ename,job FROM vw_emp20;EMPNO

ENAME

JOB---------------------

--------------

-------------7369

SMITH

CLERK 7566

JONES

MANAGER 7902

FORD

ANALYST 修改：

UPDATE vw_emp20 SET

deptno=20 WHERE empno=7902;將產生錯誤：

UPDATE vw_emp20 * ERROR 位于第一行：

ORA-01402：視圖WITH CHECK OPTION 違反WHERE 子句

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1，Oracle是可以通過視圖來修改Base table的。所謂base table就是用來構建視圖的表，也就是視圖的數據來源表。但是這種修改是有條件的。比如： create view v_emp as select empno,ename,job,deptno from emp where deptno=10 with check option constraint emp_cnst;如果有這個限制，那么通過視圖v_emp 插入數據的deptno字段的值必須是10，否則就會報“ORA-01402: 視圖 WITH CHECK OPTIDN 違反 where 子句”的異常。

2，聯結視圖：

create view dept1_staff as select e.ename, e.empno, e.job, d.deptno, d.dname from emp e,dept d where e.deptno in(10,30)and e.deptno = d.deptno； 將兩個表的數據聯結起來，看起來應該是一個內聯結（Inner joint）。

對于聯結視圖（Joint view）的修改規則稍顯復雜，設計到所謂key_preserved table的概念。通過聯結視圖來修改基表，只有那些key_preserved 的表才能被修改。上述創建視圖語句中emp和dept通過deptno進行聯結構成視圖時，emp就是key_preserved 表，而dept不是。為什么？因為在dept1_staff 中empno的值唯一的而deptno不是唯一的。所以emp是key_preserved 而dept不是。因此只能通過該視圖來修改emp，而不能修改dept的數據。

3,Oracle視圖非常強大的功能之一在于其可以創建一個帶有錯誤的視圖。比如說視圖里的字段在基表里不存在，該視圖仍然可以創建成功，但是非法的且無法執行。當基表里加入了該字段，或者說某個字段修改成視圖里的該字段名稱，那么視圖馬上就可以成為合法的。這個功能很有意思。例子：

創建基表： create table v_test(name varchar2(32),age number(12));創建帶錯誤的視圖：

create force view view_test as select name,age,address from v_test;（注意加上force選項）

由于address字段在v_test里不存在，所以會報warning: View created with compilation errors的警告，而且執行select * from view_test;時會報“ORA-04063: view “SCOTT.VIEW_TEST” 有錯誤”的異常。但是如果在v_test里加上address字段，那么視圖就會合法。對基表進行修改：

alter table v_test add(address varchar2(128));

現在再執行select * from view_test；就會執行成功了。

from:http://www.blogjava.net/jinhualee/archive/2006/07/14/58115.html

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

其他問題總結：

1、視圖上是否可以創建索引？

一般視圖上不用建立索引，對視圖的操作最終會轉化為對表的操作。一個討論：http://www.itpub.net/viewthread.php?tid=150019&extra=&page=1

第三篇：UML復習總結

1.UML(unified modeling language): 統一建模語言是創建描繪軟件系統結構和設計藍圖的標準語言。它用于指定、構造、記錄軟件系統的工件并使之可視化。~ 的基本組成部分：包括 UML 的靜態、動態、包和注釋等部分。~ 的構建塊包含基本的成分、關系和關系圖。基本成分包括結構、行為、分組和注釋成分。

2.RUP(rational unified process): 統一開發過程是一種過程框架，有助于使用創建和部署用UML設計的軟件。~生命周期分為四個階段：起始階段、細化階段、構造階段、轉換 3.軟件開發生命周期(SDLC)是一個規范的、系統的軟件開發方法。可分為六個階段：可行性分析、需求分析和規范說明、設計、編碼、測試、維護。軟件的開發方法：瀑布方法、原型方法、螺旋方法、雙贏螺旋方法、增量方法。在設計階段，有兩種~：①面向功能方法以模塊為中心，注重軟件的功能。②面向對象（OO）方法支持重用、數據封裝、以及繼承、抽象和多態性等概念。

4.面向對象分析和設計（OOAD）是指根據對象、類、封裝、繼承、多態、抽象和動態邦定來分析需求以及設計軟件系統。

5.軟件系統的各個視圖：①用例視圖：表示系統為客戶提供的功能②設計~：側重于系統的靜態和動態表示③實施~：表示軟件系統中組成系統所需的各個文件和組件④部署~：表示將執行軟件系統和硬件的組合關系。

6.四種建模技術：①需求建模：包括使用用例關系圖描述需求。②靜態~：包括使用類、對象和復合結構關系圖來描述軟件系統的靜態成分③動態~：包括使用以下關系圖來描述動態成分的行為：活動關系圖、狀態機關系圖、通信關系圖、序列關系圖、交互概覽圖、時序關系圖④架構~： 描述軟件系統的內部結構如何構成：包關系圖、主件關系圖、部署關系圖 7.需求管理是一種持續的系統化方法。~的四個階段： 需求收集、~分析與協商、~規格化、~驗證。需求分析指將需求分類和組織為功能性需求和非功能性需求的過程。功能需求指軟件系統需要實現的功能和特性。非功能性需求指軟件系統需要達到的性能指標。需求驗證是在指定需求規范化后對需求進行驗證的活動。需求驗證包括：①確定所有的模糊需求②確定每條需求的來源③說明需求數量④確定需求之間的依賴關系⑤驗證需求是否簡明、可測試并且可跟蹤⑥驗證需求與軟件系統中的約束是否有沖突

8.軟件需求規格化（SRS）是詳細分析任務后產生的文檔。~必須提供信息：軟件系統定義、SRS文檔的用途、軟件系統的范圍、功能性需求、非功能性需求、目標軟件系統的運行條件 9.角色有關的關系：泛化~： 存在于有類似的行為和特性的角色之間繼承關系。關聯~： 顯示用例與角色之間通信關系。

10.用例關系圖：①顯示目標軟件系統的用例和角色之間的交互關系②顯示用例之間或角色之間的關系（如關聯和泛化等）。用例可以（文本方式，事件流方式）描述外部角色與軟件系統之間的交互過程。用例之間的關系：①擴展：指通過獲取其它用例的某些功能來建立當前用例的方式擴展關系的箭頭方向指向要被擴展的用例②包含：指一個用例的功能包含在另一個用例的功能中。包含關系里箭頭指向被包含在另一個用例中的用例。11.類關系圖表示類、接口、以及它們之間的關系。對象關系圖表示類的特定實例的屬性值以及對象之間的關系。類的屬性和操作的可見性是：+ :表示屬性或操作對于其它類可見。-：表示屬性或操作對其它類不可見。#：表示基類的屬性或操作僅對它的派生類可見。~:表示屬性或操作只對同一個包里的類是可見的。類和對象之間的關系：①關聯：表示兩個類的對象之間一般上的邏輯意義上的聯系。②聚合：表示兩個類之間的整體與局部的關系③組合：表示兩個類之間的整體與局部的關系④依賴性：表示兩個類的對象之間一般上的動態功能上的聯系⑤泛化：表示父類與子類之間派生關系⑥實現：表示類關系圖里兩個元素之間的語義關系，其中一個元素定義一個協議，另一個元素實現這個協議。12．抽象類是沒有任何直接實例的類，繼承于抽象類的類可以有直接實例，用于定義一組子類的公共特征和公共行為。接口是一組用于表示由類或組件提供的服務的操作集合，只能提供公共方法的聲明，而不能提供這些公共方法的實現，不可以創建接口的對象。兩者的相同處：①抽象類和接口都提供方法的規范，但是都不允許您直接創建實例。②抽象類和接口中指定的方法實現都在派生類中提供。不同處：①接口使您能實現多繼承，因為一個類可以實現多個接口。但是，抽象類不支持多繼承。一個類無法繼承多個抽象類②抽象類包含的屬性和方法可以是公共的、私有的或受保護的。接口只包含方法③抽象類可提供一部分方法的定義但接口不提供任何定義④抽象類在同一個包內使用，而接口可以跨多個包里實現。接口繼承與抽象類繼承的區別：①接口繼承可多繼承，而抽象類繼承不行②接口繼承中全是抽象方法，不提供定義，而抽象類繼承中可有方法定義。

13.交互關系圖：描述軟件系統的成分如何彼此交互以實現系統用例的功能。~有兩個部分：①協作者：描述交互關系圖中參與交換的系統靜態部分②交互：描述交互關系圖中靜態部分是怎樣參與動態協作的。常用的交互關系圖有：①序列關系圖：以一組按時間順序排序的消息的形式表示對象之間的交互②通信關系圖：以消息的形式表示對象間的交互

14.包關系圖用于描述軟件系統的各個包以及包之間的關系。使用包來建模軟件系統成分的好處有：①以可視化的方式顯示功能組以及它們之間的關系②使得大型軟件系統易于管理。用例分包規則：①以可視化的方式顯示功能組以及它們之間的關系② 使得大型軟件系統易于管理。類分包~：①具有相同繼承層次結構的類分組在一個包里②具有復合關系的類分組在一個包里③將相互協作、彼此交互的類分組在一個包里。

15.組件:實現一組規定接口功能的可執行部件。組件實現了一組接口。組件類型：①部署組件：描述可執行系統最終可部署部件②工作產品~：描述工程軟件有哪些文件組成③執行~：描述可執行軟件有哪些可執行部件組成

16.框架和模式是使軟件構件可重用的標準。框架：特定領域中類似應用程序的通用功能的模板，增加可重用性和減少應用程序開發時間。其特性：①類或組件的集合，具有執行一些特定或通用的功能②包含一些預定義規范的抽象和具體類接口③可以可通過子類化來擴展和實現這些抽象類和接口④定義一些抽象方法，這些方法接收系統中預定義的消息。模式：

新建的系統能滿足可重用的要求，有助于軟件組件之間更好的通信。~類型：通用職責分配軟件模式（GRASP）、四人組模式(GoF)單例模式：允許創建它自身的唯一一個實例的類。對于有些類只應許創建一個實例對象。用靜態數據成員來定義單件模式，以跟蹤所創建對象的生命期。設計模式好處：①可讓你創建能滿足新需求的可重用的解決方案而無需修改現有系統。②有助于軟件組件之間更好的通信。③有助于設計的重用、提供最有效的問題解決方案、給類分配職責。

17.實施質量流程的目的是為了在軟件開發過程中檢查所開發的軟件模型和產品的質量。質量流程包括：①用于開發軟件系統的軟件開發過程的質量②軟件開發過程中使用的軟件模型的質量③軟件開發過程結束時獲得的軟件產品的質量④質量流程自身的質量。生產質量過硬的產品時需要考慮的維度是：①技術：描述軟件開發過程所需的工具以及生成的輸出② 方法：描述軟件開發過程期間需要執行以生成輸出的操作順序③社會學：描述軟件開發過程所需的人力資源、環境條件和技能。質量保證技術檢查：語法：確保軟件模型使用正確的語法。語義：確保軟件模型表達出目標意圖并確保軟件模型的表示在項目中一致。美觀：確保軟件模型對稱并且完整。UML提供的三種擴展元素為：構造型：擴展 UML 詞匯表約束：擴展 UML 構造塊的語義關系。標記值：擴展 UML 構造塊的屬性

18靜態建模：它表示軟件系統的靜態或結構成分。它包括類關系圖和對象關系圖。它有助于描繪系統成分之間的關聯和依賴性。動態建模：它表示軟件系統靜態成分的行為過程。它包含交互、活動和狀態關系圖。它有助于表達系統在一段時間內的行為流程。

第四篇：UML實驗報告總結

實驗一 熟悉Rational Rose及建立用例模型 實驗

二、時序圖和協作圖建模

實習三 UML類圖與包圖建模（2學時）實驗四 狀態圖和活動圖建模 實驗五

組件與部署圖

實驗一 熟悉Rational Rose及建立用例模型

（2學時）

一、實驗名稱：熟悉（2學時）

二、實驗目的與要求：

? 了解和掌握Rose建模工具的使用 ? 掌握怎樣進行案例需求分析； ? 掌握UML用例圖建模技術

三、實驗內容：

1、熟悉rose上機環境及設置

2、根據以下談話設計出用例圖

Rational Rose及建立用例模型

四、實驗步驟：

見實驗說明書

實習二（2學時）

一、實驗名稱：

時序圖和協作圖建模（2學時）

二、實驗目的與要求：

? 了解和掌握Rose或Visio建模工具的使用

? 掌握怎樣進行系統分析，并進行UML靜態建模分析； ? 掌握UML時序圖和協作圖建模技術

三、實驗內容：

根據以下談話設計出時序圖和協作圖建模。

四、實驗步驟：

、UML類圖與包圖建模（2學時）

一、實驗名稱：UML類圖與包圖建模（2學時）

二、實驗目的與要求：

? 了解和掌握Rose或Visio建模工具的使用

? 掌握怎樣進行系統分析，并進行UML動態建模分析；

三、實驗內容：

四、實驗步驟：

實習四（2學時）

一、實驗名稱：

狀態圖和活動圖建模（2學時）

二、實驗目的與要求：

? 了解和掌握Rose或Visio建模工具的使用

? 掌握怎樣進行系統分析，并進行UML動態建模分析； ? 掌握UML狀態圖和活動圖建模技術

三、實驗內容：

四、實驗步驟：

實習五

組件與部署圖與代碼生成（2學時）

一、實驗名稱：

組件與部署圖（2學時）

二、實驗目的與要求：

三、實驗內容：

四、實驗步驟：

第五篇：uml報告總結

UML課程設計總結

這幾周的課程設計，是對課本知識的總結和鞏固，使我對UML的幾種圖有了更深刻的理解，明白了這些圖分別表達的意思以及各圖的優缺點，還有它們對于程序設計的作用。熟悉了VS中建模，熟悉了VS中控件的意義，對UML有了更深刻的了解。下面是我在每一個圖的學習中的一些心得和體會

在項目設計階段，我覺得順序圖，活動圖，狀態圖比較重要。順序圖在這些圖例里比較直觀，用戶能很快參與到討論中，活動圖和傳統的流程圖類似，也是一個補充。狀態圖在對關鍵對象是一定要做狀態分析的，經常會在做分析的時候發現一些容易被忽視的問題。類圖在設計階段可以用。

深刻體會了UML在建模中關系和作用。UML可以為面向對象的開發系統進行說明，是的復雜的系統和功能，邏輯關系，類之間的關系可視化。用例圖幫助我們從宏觀上認識了學生選導師系統的軟件結構。狀態圖，時序圖，類圖幫助我們從微觀上認識了這個系統的結構和關系。

畫用例圖是我第一次使用VS建模，對VS中的一些工具還很生硬，僅僅知道跟著指導書來進行建模。但經過一定的練習，也有了一定的收獲和體會，使我了解了用例圖的組成，作用以及使用場合；掌握了用例之間的各種關系；知道了用例建模主要要了解各個圖形所代表的意義，用例還可以進行下一集的描述，進行下一步的深化。

對于建模過程中遇到的問題通過上網查資料，問同學并和他們進行討論，得到了比較滿意的解決，避免了自己眼高手低，從實踐中發現自己的不足，并及時改正。更讓我明白，UML的知識是十分豐富的，我現在的認識還不夠，我將會在以后的學習中，不斷提高自己的UML知識，更好地讓UML為將來的編程設計服務。

進一步加強和提高了文檔的編寫能力

增強了寫作能力和團隊精神