iT邦幫忙

DAY 20
2

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

[Day 20]PGR該看的懂的UML Diagram

  • 分享至 

  • xImage
  •  

前幾天在training公司新人的時候,剛好負責了這個部分。
分享給比較沒經驗的PGR參考一下。
這邊列出來的有五張圖,分別是
1.Use Case Diagram
2.Activity Diagram
3.State Machine Diagram
4.Class Diagram
5.Sequence Diagram
這五張圖是我覺得PGR要看懂,才會降低各層級溝通的門檻。

1.Use Case Diagram:
可以幫助PGR瞭解自己正在寫的系統到底是什麼,
系統範圍有多大,
有多少相關外部界接系統,
有多少角色會使用這樣的系統,
系統要提供什麼樣的角色使用什麼樣的功能。
反思自己正要進行的規格功能設計,是屬於那一塊Use Case。

2.Activity Diagram
通常是SA會先請User提供現行的作業流程文件,再來進行企業流程分析,畫出Activity Diagram,有點類似flow chart,但是主要focus的目標在每一個activity。

PGR瞭解各個抽象等級的activity diagram,有助於知道自己正在進行的功能,在Use Case Diagram裡面是屬於哪個Use Case,而該Use Case裡可能有很多Activity,可以幫助瞭解前後支程式的關聯與走向。

在開始動手寫程式之前,瞭解系統的前後關聯功能,傳遞參數等,可以避免這支程式寫完單元測試可能通過,系統整合測試卻有一大堆問題(例如寫死測試值)。

3.State Machine Diagram
這也是抽象層級可大可小的UML diagram,不過這張圖對PGR應該比較不陌生,
也是類似flow chart,但是focus的目標在於「狀態的改變」。
PGR如果瞭解這張圖,在看到規格上展開所有UI的prototype時,才不會手忙腳亂,
不知道什麼時候該做什麼事。
這張圖對設計UI動線很有幫助。

4.Class Diagram
這邊的Class Diagram指的並非是從一堆class code 逆向工程gen出來的圖,
而是還沒寫CODE之前,SA與SD設計的圖。
Class Diagram可能很大,因為它mapping到的可能是某個Use Case,
PGR要瞭解自己正在進行的功能,是整張Class Diagram的哪一個區塊,
自己功能內相關的有哪一些class,class彼此之間的關係等等。
可以供PGR在開始寫程式之前,就知道要使用哪一些Class (mapping到系統架構可能是BLL的Service跟Domain object)。

5.Sequence Diagram
這張圖就更細了,最適合PGR看的一張圖,因為就跟trace程式一樣,
可以知道哪一些物件什麼時候要被初始化,物件與物件之間如何互動,
該傳遞與回傳什麼樣的訊息,
搭配state machine diagram去進行condition的判斷,
搭配class diagram去完成物件與物件之間的互動。
這張圖其實很適合擺在程式規格裡面,用來描述PGR在進行這支功能設計時,
該有的logic flow....


上一篇
[Day 19]使用EA時批次修改Attributes
下一篇
[Day 21]MDA中的PIM-1
系列文
UML學習過程分享-以EA為例30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
海綿寶寶
iT邦大神 1 級 ‧ 2009-10-20 17:21:32

請教一下

所以貴公司目前是完全以UML文件
做為系統分析文件或軟體開發規格?
還是還有其他的文件?

搭配程式語言工具是什麼?

運作起來順暢嗎?

看更多先前的回應...收起先前的回應...
就是91 iT邦研究生 4 級 ‧ 2009-10-20 21:11:22 檢舉

hi,
SA的部分主要是以EA為底,產出文件以CMMI產出為標準,
逐步地在全面推行Domain model與UML分析和文件,
軟體開發規格的部分,則是主要與SD設計的底層和架構相關使用說明為主,
不過我上個案子在設計程式規格時,有特地以Class Diagram和Sequence Diagram來說明該規格的設計概念。

程式語言工具,ASP.NET的部分當然就是Visual Studio囉,JAVA就是Eclipes。

就是91 iT邦研究生 4 級 ‧ 2009-10-20 21:13:41 檢舉

至於順不順暢,我是覺得「目前」是一半一半,
因為還不是所有成員都熟UML(也還沒有強迫一定得用UML,沒有使用UML,QA就記NC)
加上SA使用domain model分析系統的經驗也還不多。

不過逐步推廣,收到的效果和開發成員能力的提升,倒是還不錯唷。
(至少我收穫很多啦 :) )

謝謝

之所以問是因為曾經試著要
以UML文件做為系統分析規格文件
後來卻失敗的慘痛教訓....@_@

就是91 iT邦研究生 4 級 ‧ 2009-10-21 11:11:42 檢舉

喔?
請問一下失敗的情況是怎麼回事呢?
可以順便給我當個借鏡嗎?(我想應該還是 獨力難以回天 的原因吧...畢竟這種東西沒有policy強力推行跟全面training是頗難成為「溝通」的工具)

我要留言

立即登入留言