Business process : 活動 - 程序的循序性 , 該用什麼樣的設計圖來表現出來? 以及BP要如何轉化與Use case完成契合
同時這個bp是給stakeholder參考使用的，主要是要展現出整體性的資訊
Use Case : 主要強調的是系統功能，用給團隊使用
SA最常犯的問題是上述兩者不太會分的清楚 @.@
課程中有介紹到一個物流的flow chart 的範例，但內容實在太多，很多的note，也很多的流程圖表，可是實在太複雜了，根本難以聚焦也難以開始下手，舉例，像一開始流程圖就把系統抓進來，也常把某個Activity作為資料傳遞的展現，但實際上是流程圖裡面必須把資料給封裝起來，不該把細節整個放在流程圖裡面，同時也不該把可能是多個分類的主題給併在一起, ex:定進退貨流程概要圖，這邊就很詭異~
如果這時候可以搭配使用火箭圖，把各個主要的主體流程拉開來(不過這時候還看不出細節)，讓輸入與輸出的條件明確，還有讓流程預定達成的目標明確出來，等你的火箭圖的大流程拉好以後，再逐步的drill down的去描繪出 activity的內涵，所以其實整體來看，軟體開發的先決條件就是封裝...
MSS三層次(大BP , 小BP , Use Case)原則 - 最重要的是Use Case // 用activity來關聯use case , 只要是需要轉為系統的就是放入use case處理
企業流程: 服務客戶的一連串企業內部的活動~ by Jacobson
關於MSS三層次的更詳細的說明，可以參考Kenming的解說 !!
什麼是大業務流程? 就是業務流程範圍廣闊，參與者多，所涵蓋的時間更長，跨部門複雜的一個共同合作的業務需求
但是，若要使用Activity diagram來體現大業務流程的話，感覺會很不好用，因為多個不同的activity的流程資訊不一，
所以可能不好用，推薦使用的是UML Extension ~ Erickson Penker 俗稱火箭圖
常見的問題是: //所以設計圖的最基本要求就是要簡潔&有層次, 有廣度&深度
1. 一張圖就想表現所有的細節
2. 把資料作為主體，呈現的就是資料傳遞的流程
把大業務流程用火箭圖來描述時，就是很經典的IPO --> Input , Process , Output
火箭圖的參與人員用 角色/部門/組織來表示，而且也不要把資訊系統參預放進來，原因是SA沒有能力決定哪個資訊系統可以放進來參預,對於系統的定義就延宕到use case才來表達。
描繪Activity時，當你已經描繪出多個活動時，就可以詢問是否要將此活動納入到資訊系統裡面，而每個活動裡面可能會包含多個action，
so : 1 activity contains more actions.而這些actions 則需要被綁定在同一個 transaction裡面 !
從復合結構圖中找到你需要分析的part組件之後，將他轉化為use case，與你的組件有關系的部份，則成為了你的外部系統
特別注意一下，UML與OO沒有百分百關聯，Use Case只是紀錄分析的一種手法而已
Use Case 幾點重要資訊
1. Goal --> 意圖 --> 會轉化為Controller class
2. narrative -->陳述其動作步驟--> Controller class的 method ,而methd則會封裝了data 以及 business logic
用上述的這2個重點，可以很容易的就被我們mapping到實作階段
Use Case Description
- Pre-Condition
- Brief Description --> 通常給pm or stakeholder參考使用
- Flow of Event
- Normal
- Alternative
- Exception
- Post-Condition
Sequence Diagram 對應到實作的關係?
對於Actor 呼叫系統的功能時，這邊對應出來的是public method，而系統內部相關呼叫，或者呼叫外部支援系統的部份，
則是protected or private的設計考量了
在method的呼叫過程中會進行資料的傳遞，而這邊的data 則進而成為了field or entity
我們在訪談的過程中，其實很難掌握客戶會陳述哪些資訊，但是我們的目標就是先掌握住意圖，然後在將客戶提供的資訊分別的抽絲剝繭的分別列入細部的UC內涵。
從企業流程找出使用案例需求
老實說系統設計師應該是佔了軟體成敗的主要因素，SA反而沒那麼重要
系統分析師其實不該肩負著開table layout的工作，反而是該流到SD階段再來進行才是，只是台灣的畸形生態Q_Q
Q1 : UC對應到實作到底都生出了什麼?
A1 : 一個UC 對應產出一個Controller , Entity , Boundary, 還有個VDB ，去對應實體的Entity
Q2 : 如何有效的掌握你的需求範圍?
A2 : 將需求納入你的框架範圍內，也就是USe Case 的使用，同時也可透過物件導向的多行概念，來容納多種變化的需求來源。
Q3 : 使用案例是系統的內部還是外部?
A3 : 使用者案例是以使用者角度來看系統功能，所以這屬於系統外觀，因為是給他們看大概有什麼功能的，而UC本身並不是真的可以work，所以是外部無誤。
而當你把外部搞定之後，在開始來進行內部結構設計，這時候也就是進行重構的時候了。
使用UC iteration1 的好處，是可以產出一個常數時間(一個可預估的專案功能開發時間)
PS : Iteration的進展是從UC開始的
//從活動圖開始去找出你的使用者案例
Jacobson的企業流程案例作法太困難，所以我們改用了活動圖案例分析方法
主要作法是對每一活動出問題：
- Who is the major worker?
- 這個活動的進行中，需要提供服務嗎?
- 系統需要提供什麼服務
- 需要其他資訊系統支援嗎?
一個Use case 可能對應到多個activity,舉例(擬定採購需求 then 通知供應商)，在活動圖中看起來是兩個activity，可是在UC裡面可看作是同一個目的，使用Use Case 還有個好處，當你名列出Actor所對應的Use Case時，就可以獻縮Actor 對UC 的意見，對於Actor 本身沒有參與的UC，則可以不予理會
使用者案例的敘述一般分成四種：
- 使用案例的簡述 --> 通常用1~2句話來說明案例的目的為何
- 使用案例的正常流程 --> 全部都是肯定句的案例功能描述，沒有branch，而且盡可能需要佔據整個功能的6成以上
- 使用案例的替代流程 --> 在某個正常流程的分支，而且也都必須是肯定句的描述
- 使用者案例的例外處理 --> 發生意外狀況的處理，也都必須是肯定句的描述
通常在 1st iteration中，只處理正常流程的精要部份(把細節跟欄位規範都先不考慮的那麼細)，但一整個iteration仍然是要包含畫面跟實際寫入db功能都要完成，2nd 補細節 , 3rd 補例外跟錯誤處理流程，而若是要交付給客戶的話，起碼是2nd iteration之後才進行交付比較完整一點。
使用者案例的正常流程有基本原則要遵守：
- 第一句主詞一定是主要參與者
- 第一句主詞只能是參與者或系統
- 當主詞是系統時，只能作以下幾件事情 --> 針對資料作處理(查詢或儲存CRUD) / 根據企業邏輯進行驗證或處理 / 將資料轉派給次要參與者
- 盡量不要描述過多的細節(包括資料欄位&運算邏輯)
當你案例完成後要準備進入Coding之前，可以先撰寫測試案例，這裡指的是單元功能測試，至少先確定功能框架功能正常，日後若進行功能修改時，可以快速的進行功能測試。
撰寫測試案例其實理論上是甲方來提供，但很顯然的不常看到有這樣的機會，測試案例主旨在提供很明確的輸入與預期產出即可。
最後彙整，先從火箭圖去拉出不同的business process , 再從bP 中去找出其 activity diagram ，在從ACT其中去找出有可能的use case，進而進行後續的訪談與開發基礎。這時候RA的階段就算是完成了。
UML Components 一書提到元件的設計很多人以為是可以讓他重用，以為可以找到最佳的解決方案來處理重複性的問題，但實際上是目的應該是讓他容易被抽換。 物件的方法如果是你已經宣告成public的，那麼這個method就可以被定義為公開的界面，並且盡可能的求其不易變動性...
沒有留言:
張貼留言