iT邦幫忙

DAY 3
4

UML學習過程分享-以EA為例系列 第 3

[Day 3]Use Case Diagram簡介

隨著VSTS2010的問世,UML已經可以直接在Visual Studio裡面設計,
UML就像ISO、CMMI一樣,是種趨勢,是種必備的工具和標準。
不會UML也不會死,會用也沒有加錢,
但是UML卻是一個開放的標準,當人與人之間溝通沒有一個橋樑時,開放的標準就會顯得格外重要。
UML diagram – Use Case Diagram

這幾乎是每一個案例第一個會用到的圖,為什麼?

  1. 重要,從這張圖可以瞭解整個系統的Scope(Boundary)、需求(Use Case)、參與成員(Actor)。
  2. 簡單,因為圖裡面使用的Element就只有上面這些,再加上箭頭來表示關聯。
    * 也因為簡單,所以這張圖連User也會看的懂,是少數不用教育訓練,就可以透過UML diagram讓雙方進行溝通。

Use Case Diagram主要就是用來捕捉系統功能需求的圖形。

然而,要畫圖之前,我們通常會有一堆文字,再用圖來解釋和溝通。

所以我們會先有使用案例敘述,這些條列性的文字,通常是經由SA與User訪談後,所表列出來的文字。
我們要從訪談過程,去引導出User真正需要什麼,從訪談記錄這堆文字裡面,瞭解User想要系統能作什麼,
整理歸納出來的每一個需求與目的,都是我們的Use Case。

有了Use Case,才能訂出來我們這個系統到底要做些什麼,到底有哪一些相關的成員,這些成員會使用什麼樣的功能。

Element介紹
1.Actor:成員,不一定是人,也有可能是外部系統,只要與這個系統有關的人或物都可以是Actor。

2.Use Case:使用案例,滿足實際使用者需求目的的功能,通常對應到系統裡,就是Business logic layer裡面的Service。

3.System Boundary:一個矩形框框,在這個框框裡的,就是我們的系統範圍內,在框框以外,就是外部的角色,
外部功能我們也不會在這張圖出現,因為沒有必要,太多東西反而會增加雜訊,這在每一張diagram都是相當重要的原則,
不要想用一張圖就表達出太多的東西。

4.Association:關聯,通常是Actor與Use Case之間的的關係,也可以是include或extend的關係。

這邊舉一個提款機系統來當例子:


上一篇
[Day 2]系統需求發展
下一篇
[Day 4]如何使用EA將Class diagram或Data model匯出成文件
系列文
UML學習過程分享-以EA為例30

尚未有邦友留言

立即登入留言