解析UML的靜態建模機制

2019-11-17 04:43:50

字體：大中小

來源：轉載

供稿：網友

任何建模語言都以靜態建模機制為基礎，標準建模語言UML也不例外。UML的靜態建模機制包括用例圖(Use case diagram)、類圖(Class diagram)、對象圖(Object diagram )、包(Package)、構件圖(Component diagram)和配置圖(Deployment diagram)。 用例圖用例模型(Use case model) 長期以來，在面向對象開發和傳統的軟件開發中，人們根據典型的使用情景來了解需求。但是，這些使用情景是非正式的，雖然經常使用，卻難以建立正式文擋。用例模型由Ivar Jacobson在開發AXE系統中首先使用，并加入由他所倡導的OOSE和Objectory方法中。用例方法引起了面向對象領域的極大關注。自1994年Ivar Jacobson的著作出版后，面向對象領域已廣泛接納了用例這一概念，并認為它是第二代面向對象技術的標志。用例模型描述的是外部執行者(Actor)所理解的系統功能。用例模型用于需求分析階段，它的建立是系統開發者和用戶反復討論的結果，表明了開發者和用戶對需求規格達成的共識。首先，它描述了待開發系統的功能需求; 其次，它將系統看作黑盒，從外部執行者的角度來理解系統; 第三，它驅動了需求分析之后各階段的開發工作，不僅在開發過程中保證了系統所有功能的實現，而且被用于驗證和檢測所開發的系統，從而影響到開發工作的各個階段和UML的各個模型。在UML中，一個用例模型由若干個用例圖描述，用例圖主要元素是用例和執行者。 用例(use case) 從本質上講，一個用例是用戶與計算機之間的一次典型交互作用。以字處理軟件為例，“將某些正文置為黑體”和“創建一個索引”便是兩個典型的用例。在UML中，用例被定義成系統執行的一系列動作，動作執行的結果能被指定執行者察覺到。在UML中，用例表示為一個橢圓。圖1顯示了一個金融貿易系統的用例圖。其中，“風險分析”，“交易估價”，“進行交易”，“設置邊界”，“超越邊界的交易”，“評價貿易”，“更新帳目”等都是用例的實例。概括地說，用例有以下特點: •用例捕捉某些用戶可見的需求，實現一個具體的用戶目標。 •用例由執行者激活，并提供確切的值給執行者。 •用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。解析UML的靜態建模機制（圖一）

圖1 金融貿易系統用例執行者(Actor) 執行者是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。圖1中有四個執行者:貿易經理、營銷人員、售貨員和記帳系統。在某些組織中很可能有許多營銷人員,但就該系統而言,他們均起著同一種作用,扮演著相同的角色,所以用一個執行者表示。一個用戶也可以扮演多種角色(執行者)。例如,一個高級營銷人員既可以是貿易經理,也可以是普通的營銷人員;一個營銷人員也可以是售貨員。在處理執行者時,應考慮其作用,而不是人或工作名稱,這一點是很重要的。圖1中,不帶箭頭的線段將執行者與用例連接到一起,表示兩者之間交換信息,稱之為通信聯系。執行者觸發用例,并與用例進行信息交換。單個執行者可與多個用例聯系;反過來,一個用例可與多個執行者聯系。對同一個用例而言,不同執行者有著不同的作用:他們可以從用例中取值,也可以參與到用例中。需要注重的是執行者在用例圖中是用類似人的圖形來表示,盡管執行的,但執行者未必是人。例如,執行者也可以是一個外界系統,該外界系統可能需要從當前系統中獲取信息,與當前系統有進行交互。在圖1中,我們可以看到,記帳系統是一個外界系統,它需要更新帳目。通過實踐,我們發現執行者對提供用例是非常有用的。面對一個大系統,要列出用例清單經常是十分困難。這時可先列出執行者清單,再對每個執行者列出它的用例,問題就會變得輕易很多。 使用和擴展(Use and Extend) 圖1中除了包含執行者與用例之間的連接外,還有另外兩種類型的連接,用以表示用例之間的使用和擴展關系。使用和擴展是兩種不同形式的繼續關系。當一個用例與另一個用例相似,但所做的動作多一些,就可以用到擴展關系。例如圖1中,基本的用例是"進行交易"。交易中可能一切都進行得很順利,但也可能存在擾亂順利進行交易的因素。其中之一便是超出某些邊界值的情況。例如,貿易組織會對某個特定客戶規定最大貿易量,這時不能執行給定用例提供的常規動作,而要做些改動。我們可在"進行交易"用例中做改動。但是,這將把該用例與一大堆非凡的判定和邏輯混雜在一起,使正常的流程晦澀不堪。圖1中將常規的動作放在"進行交易"用例中,而將非常規的動作放置于"超越邊界的交易"用例中,這便是擴展關系的實質。當有一大塊相似的動作存在于幾個用例,又不想重復描述該動作時,就可以用到使用關系。例如,現實中風險分析和交易估價都需要評價貿易,為此可單獨定義一個用例,即"評價貿易",而"風險分析"和"交易估價"用例將使用它。請注重擴展與使用之間的相似點和不同點。它們兩個都意味著從幾個用例中抽取那些公共的行為并放入一個單獨用例中,而這個用例被其他幾個用例使用或擴展。但使用和擴展的目的是不同的。 用例模型的獲取幾乎在任何情況下都會使用用例。用例用來獲取需求,規劃和控制項目。用例的獲取是需求分析階段的主要任務之一,而且是首先要做的工作。大部分用例將在項目的需求分析階段產生,并且隨著工作的深入會發現更多的用例,這些都應及時增添到已有的用例集中。用例集中的每個用例都是一個潛在的需求。 1. 獲取執行者獲取用例首先要找出系統的執行者?？梢酝ㄟ^用戶回答一些問題的答案來識別執行者。以下問題可供參考: •誰使用系統的主要功能(主要使用者)。
•誰需要系統支持他們的日常工作。 •誰來維護、治理使系統正常工作(輔助使用者)。 •系統需要操縱哪些硬件。 •系統需要與哪些其它系統交互,包含其它計算機系統和其它應用程序。 •對系統產生的結果感愛好的人或事物。2. 獲取用例一旦獲取了執行者,就可以對每個執行者提出問題以獲取用例。

以下問題可供參考:

•執行者要求系統提供哪些功能(執行者需要做什么)?

•執行者需要讀、產生、刪除、修改或存儲的信息有哪些類型。

•必須提醒執行者的系統事件有哪些?或者執行者必須提醒系統的事件有哪些?怎樣把這些事件表示成用例中的功能?

•為了完整地描述用例,還需要知道執行者的某些典型功能能否被系統自動實現?

還有一些不針對具體執行者問題(即針對整個系統的問題):

•系統需要何種輸入輸出?輸入從何處來?輸出到何處?

•當前運行系統(也許是一些手工操作而不是計算機系統)的主要問題?

需要注重,最后兩個問題并不是指沒有執行者也可以有用例,只是獲取用例時尚不知道執行者是什么。一個用例必須至少與一個執行者關聯。還需要注重:不同的設計者對用例的利用程度也不同。例如,Ivar Jacobson說,對一個十人年的項目,他需要二十個用例。而在一個相同規模的項目中,Martin Fowler則用了一百多個用例。我們認為:任何合適的用例都可使用,確定用例的過程是對獲取的用例進行提煉和歸納的過程,對一個十人年的項目來說,二十個用例似乎太少,一百多個用例則嫌太多,需要保持二者間的相對均衡。任何建模語言都以靜態建模機制為基礎，標準建模語言UML也不例外。UML的靜態建模機制包括用例圖(Use case diagram)、類圖(Class diagram)、對象圖(Object diagram )、包(Package)、構件圖(Component diagram)和配置圖(Deployment diagram)。 用例圖用例模型(Use case model) 長期以來，在面向對象開發和傳統的軟件開發中，人們根據典型的使用情景來了解需求。但是，這些使用情景是非正式的，雖然經常使用，卻難以建立正式文擋。用例模型由Ivar Jacobson在開發AXE系統中首先使用，并加入由他所倡導的OOSE和Objectory方法中。用例方法引起了面向對象領域的極大關注。自1994年Ivar Jacobson的著作出版后，面向對象領域已廣泛接納了用例這一概念，并認為它是第二代面向對象技術的標志。用例模型描述的是外部執行者(Actor)所理解的系統功能。用例模型用于需求分析階段，它的建立是系統開發者和用戶反復討論的結果，表明了開發者和用戶對需求規格達成的共識。首先，它描述了待開發系統的功能需求; 其次，它將系統看作黑盒，從外部執行者的角度來理解系統; 第三，它驅動了需求分析之后各階段的開發工作，不僅在開發過程中保證了系統所有功能的實現，而且被用于驗證和檢測所開發的系統，從而影響到開發工作的各個階段和UML的各個模型。在UML中，一個用例模型由若干個用例圖描述，用例圖主要元素是用例和執行者。 用例(use case) 從本質上講，一個用例是用戶與計算機之間的一次典型交互作用。以字處理軟件為例，“將某些正文置為黑體”和“創建一個索引”便是兩個典型的用例。在UML中，用例被定義成系統執行的一系列動作，動作執行的結果能被指定執行者察覺到。在UML中，用例表示為一個橢圓。圖1顯示了一個金融貿易系統的用例圖。其中，“風險分析”，“交易估價”，“進行交易”，“設置邊界”，“超越邊界的交易”，“評價貿易”，“更新帳目”等都是用例的實例。概括地說，用例有以下特點: •用例捕捉某些用戶可見的需求，實現一個具體的用戶目標。 •用例由執行者激活，并提供確切的值給執行者。 •用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。解析UML的靜態建模機制（圖一）

圖1 金融貿易系統用例執行者(Actor) 執行者是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。圖1中有四個執行者:貿易經理、營銷人員、售貨員和記帳系統。在某些組織中很可能有許多營銷人員,但就該系統而言,他們均起著同一種作用,扮演著相同的角色,所以用一個執行者表示。一個用戶也可以扮演多種角色(執行者)。例如,一個高級營銷人員既可以是貿易經理,也可以是普通的營銷人員;一個營銷人員也可以是售貨員。在處理執行者時,應考慮其作用,而不是人或工作名稱,這一點是很重要的。圖1中,不帶箭頭的線段將執行者與用例連接到一起,表示兩者之間交換信息,稱之為通信聯系。執行者觸發用例,并與用例進行信息交換。單個執行者可與多個用例聯系;反過來,一個用例可與多個執行者聯系。對同一個用例而言,不同執行者有著不同的作用:他們可以從用例中取值,也可以參與到用例中。需要注重的是執行者在用例圖中是用類似人的圖形來表示,盡管執行的,但執行者未必是人。例如,執行者也可以是一個外界系統,該外界系統可能需要從當前系統中獲取信息,與當前系統有進行交互。在圖1中,我們可以看到,記帳系統是一個外界系統,它需要更新帳目。通過實踐,我們發現執行者對提供用例是非常有用的。面對一個大系統,要列出用例清單經常是十分困難。這時可先列出執行者清單,再對每個執行者列出它的用例,問題就會變得輕易很多。 使用和擴展(Use and Extend)
圖1中除了包含執行者與用例之間的連接外,還有另外兩種類型的連接,用以表示用例之間的使用和擴展關系。使用和擴展是兩種不同形式的繼續關系。當一個用例與另一個用例相似,但所做的動作多一些,就可以用到擴展關系。例如圖1中,基本的用例是"進行交易"。交易中可能一切都進行得很順利,但也可能存在擾亂順利進行交易的因素。其中之一便是超出某些邊界值的情況。例如,貿易組織會對某個特定客戶規定最大貿易量,這時不能執行給定用例提供的常規動作,而要做些改動。我們可在"進行交易"用例中做改動。但是,這將把該用例與一大堆非凡的判定和邏輯混雜在一起,使正常的流程晦澀不堪。圖1中將常規的動作放在"進行交易"用例中,而將非常規的動作放置于"超越邊界的交易"用例中,這便是擴展關系的實質。當有一大塊相似的動作存在于幾個用例,又不想重復描述該動作時,就可以用到使用關系。例如,現實中風險分析和交易估價都需要評價貿易,為此可單獨定義一個用例,即"評價貿易",而"風險分析"和"交易估價"用例將使用它。請注重擴展與使用之間的相似點和不同點。它們兩個都意味著從幾個用例中抽取那些公共的行為并放入一個單獨用例中,而這個用例被其他幾個用例使用或擴展。但使用和擴展的目的是不同的。 用例模型的獲取幾乎在任何情況下都會使用用例。用例用來獲取需求,規劃和控制項目。用例的獲取是需求分析階段的主要任務之一,而且是首先要做的工作。大部分用例將在項目的需求分析階段產生,并且隨著工作的深入會發現更多的用例,這些都應及時增添到已有的用例集中。用例集中的每個用例都是一個潛在的需求。 1. 獲取執行者獲取用例首先要找出系統的執行者?？梢酝ㄟ^用戶回答一些問題的答案來識別執行者。以下問題可供參考: •誰使用系統的主要功能(主要使用者)。 •誰需要系統支持他們的日常工作。 •誰來維護、治理使系統正常工作(輔助使用者)。 •系統需要操縱哪些硬件。 •系統需要與哪些其它系統交互,包含其它計算機系統和其它應用程序。 •對系統產生的結果感愛好的人或事物。2. 獲取用例一旦獲取了執行者,就可以對每個執行者提出問題以獲取用例。

以下問題可供參考:

•執行者要求系統提供哪些功能(執行者需要做什么)?

•執行者需要讀、產生、刪除、修改或存儲的信息有哪些類型。

•必須提醒執行者的系統事件有哪些?或者執行者必須提醒系統的事件有哪些?怎樣把這些事件表示成用例中的功能?

•為了完整地描述用例,還需要知道執行者的某些典型功能能否被系統自動實現?

還有一些不針對具體執行者問題(即針對整個系統的問題):

•系統需要何種輸入輸出?輸入從何處來?輸出到何處?

•當前運行系統(也許是一些手工操作而不是計算機系統)的主要問題?

需要注重,最后兩個問題并不是指沒有執行者也可以有用例,只是獲取用例時尚不知道執行者是什么。一個用例必須至少與一個執行者關聯。還需要注重:不同的設計者對用例的利用程度也不同。例如,Ivar Jacobson說,對一個十人年的項目,他需要二十個用例。而在一個相同規模的項目中,Martin Fowler則用了一百多個用例。我們認為:任何合適的用例都可使用,確定用例的過程是對獲取的用例進行提煉和歸納的過程,對一個十人年的項目來說,二十個用例似乎太少,一百多個用例則嫌太多,需要保持二者間的相對均衡。任何建模語言都以靜態建模機制為基礎，標準建模語言UML也不例外。UML的靜態建模機制包括用例圖(Use case diagram)、類圖(Class diagram)、對象圖(Object diagram )、包(Package)、構件圖(Component diagram)和配置圖(Deployment diagram)。 用例圖用例模型(Use case model) 長期以來，在面向對象開發和傳統的軟件開發中，人們根據典型的使用情景來了解需求。但是，這些使用情景是非正式的，雖然經常使用，卻難以建立正式文擋。用例模型由Ivar Jacobson在開發AXE系統中首先使用，并加入由他所倡導的OOSE和Objectory方法中。用例方法引起了面向對象領域的極大關注。自1994年Ivar Jacobson的著作出版后，面向對象領域已廣泛接納了用例這一概念，并認為它是第二代面向對象技術的標志。用例模型描述的是外部執行者(Actor)所理解的系統功能。用例模型用于需求分析階段，它的建立是系統開發者和用戶反復討論的結果，表明了開發者和用戶對需求規格達成的共識。首先，它描述了待開發系統的功能需求; 其次，它將系統看作黑盒，從外部執行者的角度來理解系統; 第三，它驅動了需求分析之后各階段的開發工作，不僅在開發過程中保證了系統所有功能的實現，而且被用于驗證和檢測所開發的系統，從而影響到開發工作的各個階段和UML的各個模型。在UML中，一個用例模型由若干個用例圖描述，用例圖主要元素是用例和執行者。 用例(use case) 從本質上講，一個用例是用戶與計算機之間的一次典型交互作用。以字處理軟件為例，“將某些正文置為黑體”和“創建一個索引”便是兩個典型的用例。在UML中，用例被定義成系統執行的一系列動作，動作執行的結果能被指定執行者察覺到。在UML中，用例表示為一個橢圓。圖1顯示了一個金融貿易系統的用例圖。其中，“風險分析”，“交易估價”，“進行交易”，“設置邊界”，“超越邊界的交易”，“評價貿易”，“更新帳目”等都是用例的實例。概括地說，用例有以下特點: •用例捕捉某些用戶可見的需求，實現一個具體的用戶目標。 •用例由執行者激活，并提供確切的值給執行者。 •用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。解析UML的靜態建模機制（圖一）