目錄

1、語法和語義規則

2、UML中的公共機制

（1）規約

（2）修飾

（3）通用劃分

（4）擴展機制

衍型/版型/類型（stereotype）

標記值?（tagged value）

約束（constraint）

3、系統的體系結構建模

用例視圖 （use case view）

設計視圖 （design view）

交互視圖 （interaction view）

實現視圖 （implementation view）

部署視圖 （deployment view）

4、軟件開發的生命周期

4.1、初始 （inception）

4.2、細化 （elaboration）

4.3、構造 （construction）

4.4、移交 （transition）

---

1、語法和語義規則

命名——為事物、關系和圖起的名字；

范圍——使名字具有特定含義的語境；

可見性——這些名字如何讓其他成分看見和使用；

完整性——事物如何正確、一致地相互聯系；

執行——運行或模擬一個動態模型意味著什么。

2、UML中的公共機制

（1）規約

UML 不僅僅是一種圖形語言。實際上，在它的圖形表示法的每部分背后都有一個規約，這個規約提供了對構造塊的語法和語義的文字敘述。
?

（2）修飾

UML中的大多數元素都有唯一而直接的圖形表示符號，這些圖形符號對元素的最重要的方面提供了可視化表示。

圖中表明這個類是一個抽象類，

有兩個公共操作、一個受保護操作和一個私有操作。

（3）通用劃分

第一種方式是對類和對象的劃分。類是一種抽象，對象是這種抽象的一個具體表現。

在圖形上，UML是這樣區分對象的：采用與類同樣的圖形符號來表示對象，并且在對象名的下面畫一道線

有一個名稱為Customer的類，它有3個對象，分別為

Jan（它被明確地標記為Customer的對象）

:Customer（匿名的Customer對象）

Elyse（它在規約中被說明為一種Customer對象，盡管在這里沒有明確地表示出來）。

第二種方式是接口和實現的分離。接口聲明了一個合約，而實現則表示了對該合約的具體實施，它負責如實地實現接口的完整語義。

在這個圖中，有一個名稱為SpellingWizard.dll的構件，

它實現了接口IUnknown和接口ISpelling，

并且還需要使用一個由其他構件提供的名為IDictionary的接口。

第三種方式是類型和角色的分離。類型聲明了實體的種類（如對象、屬性或參數），角色描述了實體在語境中的含義（如類、構件或協作等）。

任何作為其他實體結構中的一部分的實體（例如屬性）都具有兩個特性：

從它固有的類型派生出一些含義

從它在語境中的角色派生出一些含義

（4）擴展機制

衍型/版型/類型（stereotype）

擴展了UML的詞匯，可以用來創造新的構造塊，這個新構造塊既是從現有的構造塊派生的，但是針對專門的問題。

例如，假設正在使用一種編程語言，如Java或C++，經常要對“異常事件”建模。在這些語言里，“異常事件”就是類，只是用很特殊的方法進行了處理。通常可能只想允許拋出和捕捉異常事件，沒有其他要求。

此時可以讓異常事件在模型中成為“一等公民”——可以像對待基本構造塊一樣對待它們，只要用一個適當的衍型來標記它們即可。

標記值?（tagged value）

擴展了UML衍型的特性，可以用來創建衍型規約的新信息。

例如，如果在制作以盒裝形式銷售的產品，隨著時間的推移，它經過了多次發行，那么經常會想要跟蹤產品的版本和對產品做關鍵摘要的作者。

版本和作者不是UML的基本概念，通過引入新的標記值，可以把它們加到像類那樣的任何構造塊中去。例如，在圖中，在類EventQueue上明確標記了版本和作者，這樣就對該類進行了擴展。

約束（constraint）

擴展了UML構造塊的語義，可以用來增加新的規則或修改現有的規則。例如，可能想約束類 EventQueue，以使所有的增加都按序排列。如上圖，對操作 add增加了一個約束，即{ordered}，以明確標示這一規則。
?

3、系統的體系結構建模

不同人員關注各自的問題

用況：用例

用例視圖 （use case view）

由描述可被最終用戶、分析人員和測試人員看到的系統行為的用例組成。用例視圖實際上沒有描述軟件系統的組織，而是描述了形成系統體系結構的動力。

在UML中，該視圖的靜態方面由用例圖表現；動態方面由交互圖、狀態圖和活動圖表現

設計視圖 （design view）

包含了類、接口和協作，它們形成了問題及其解決方案的詞匯。這種視圖主要支持系統的功能需求，即系統應該提供給最終用戶的服務。

在UML中，該視圖的靜態方面由類圖和對象圖表現；動態方面由交互圖、狀態圖和活動圖表現。類的內部結構圖特別有用。

交互視圖 （interaction view）

展示了系統的不同部分之間的控制流，包括可能的并發和同步機制。該視圖主要針對性能、可伸縮性和系統的吞吐量。

在UML中，對該視圖的靜態方面和動態方面的表現與設計視圖相同，但著重于控制系統的主動類和在它們之間流動的消息

實現視圖 （implementation view）

包含了用于裝配與發布物理系統的制品。這種視圖主要針對系統發布的配置管理，它由一些獨立的文件組成；這些文件可以用各種方法裝配，以產生運行系統。它也關注從邏輯的類和構件到物理制品的映射。

在UML中，該視圖的靜態方面由構件圖表現，動態方面由交互圖、狀態圖和活動圖表現。

部署視圖 （deployment view）

包含了形成系統硬件拓撲結構的結點（系統在其上運行）。這種視圖主要描述組成物理系統的部件的分布、交付和安裝。

在UML中，該視圖的靜態方面由部署圖表現，動態方面由交互圖、狀態圖和活動圖表現。

4、軟件開發的生命周期

1）用例驅動

把用例作為一種基本的制品，用于建立所要求的系統行為、驗證和確認系統的體系結構、測試以及在項目組成員間進行交流。

2）以體系結構為中心

以系統的體系結構作為一種基本制品，對被開發的系統進行概念化、構造、管理和演化。

3）迭代的和增量

迭代：涉及到對一連串可執行的發布的管理。

增量：涉及到系統體系結構的持續集成，以產生各種發布，每個新發布都比上一個發布有所改善

總的來講，迭代和增量的過程是風險驅動的（risk-driven），每個新的發布都致力于處理和降低對于項目成功影響最為顯著的風險。

RUP四個階段，即軟件開發生命周期

4.1、初始 （inception）

在此階段，萌發的開發想法經過培育要達到這樣一個目標：至少要在內部奠定足夠的基礎，以保證能夠進入到細化階段。

4.2、細化 （elaboration）

在此階段定義產品需求和體系結構。在這個階段，將明確系統需求，按其重要性排序并劃定基線。可以按一般的描述，也可以按精確的評價準則來排列系統的需求，每個需求都說明了特定的功能或非功能的行為，并為測試提供了基礎。

4.3、構造 （construction）

在此階段軟件從可執行的體系結構基線發展到準備移交給用戶。針對項目的商業需要，這里也要不斷地對系統的需求，特別是對系統的評價準則進行檢查，并要適當地分配資源，以主動地降低項目的風險。

4.4、移交 （transition）

在此階段把軟件交付給用戶。在這個階段，軟件開發過程很少能結束，還要繼續改善系統，根除錯誤，增加早期發布未能實現的特性。