顯示具有 UML 標籤的文章。 顯示所有文章
顯示具有 UML 標籤的文章。 顯示所有文章

星期日, 11月 14, 2010

系統分析設計與實作 Week 2 - Modeling By UML 三劍客

Modeling By UML 三劍客
  • Use Case Diagram
    由SA畫出使用者需求
  • Class Diagram
    由SD畫出結構圖
  • 物件合作圖
    方便Programmer實作
各代表不同view, 三大構面:需求、結構、實作

問題:已經足夠?
視專業,原則上已經符合大部份需求,最好還有table schema

系統是提供服務(API), 畫面(介面)及DB都不是系統

過去常用畫面捕抓需求
直覺,但不易找出user使用的目的,因為太多操縱細節,最常抓「欄位」、「企業規則」,但一開始其實不需要(先過濾細節),且使用者常不知自己所需,因此SA要能抓出「目的」(使用者使用系統的目的)
ex,付款時,要填「地址」(欄位,易變),目的在付款時,提供滿足需求的服務,但跟end user溝通,仍是一個溝通工具

前導工作
-訪談、會議記錄、畫面、錄音 以導出use case

use case model
  • Use Case Diagram => 聚焦在what, 而非how-to
    買咖啡及點餐各為一個use case,但結帳不是,因結帳非目的,而是點餐後的一項
  • Use Case Description 細節、互動

4.1 Web ATM
晶片金融卡視為一外部系統
因為密碼及交易計錄(約10筆)會存在金融卡,而金融卡會提供存取的API,因此算系統

寫好Use Case的好處
  • 好維護
  • 保持開發節奏順暢
*重覆的use case如何處理?
先當獨立,事後再依refactoring評估是否相關,再進行合併

2.3.1 系統範圍
抓價值高的=>交易
而非價值低的維護欄位

星期日, 11月 07, 2010

系統分析設計與實作 Week 1

如何分析系統(How)?從何分析,分析什麼?

聚焦重點,系統為提供服務,而服務是從需求而來,所以分析需求即為重點
ex. 咖啡廳的需求為何?
咖啡廳提供服務有
  • 餐點
  • 設備
組成咖啡廳的元素 (內部結構)

問:咖啡機也是組成元素,為何沒列入?
因為重點在Service,咖啡機有如framework(基礎建設),很重要,但不會自己做,將重點放在滿足需求,而不是自己再造輪子

三大構面
依使用者角度不同,分析出來的需求也不同

PG Skill

分析 (SA )
著重功能、需求
設計
內部結構元素
實作
Infrastructure
當三者有技術衝突時,靠Architect講合
PM 人、客戶的溝通、時程的掌握

Ch1. 軟體開發方法論(Methodology)
1.1.1 方法論的組成元素 - 溝通語言與開發流程(Process)
軟體開發會有PM,Architect, SA/D, Programmer組成的團隊,在一定的時程內、運用有麥的資源,來達成有效率的系統開發。如果做有效率的專案控管,「溝通」與「開發製程」即為影影專案成敗的最重要關鍵 。
  • 開發流程: Waterfall, RUP, XP, agile
    因project的性質、團隊素質不同,不可能適用每次的project
  • Notation: UML
    統一溝通的語言,讓PM,SA/D, Architect, Programmer有共同的語言
團隊開發成員之間可講相同的語言(UML),以利相互的溝通;但每個團隊要如何達成目標,則各有方法與程序(Process)來達成任務。程序是"How-to",每個團隊的"How-to"是不會完全一樣的。

1.1.2 什麼是有效的開發流程
軟體開發失敗原因,不外乎
  • 溝通的障礙
  • 無法處理需求的變更
  • 脆弱的架構
  • 難處理的複雜性(團隊合作造成的複雜 ex.維護別人的code)
  • 不一致的需求、設計和實作 (分析文件太多,不易維護)
  • 無法分析並克服風險 (讓風險儘早發現)
  • 無法建立標準化的測試環境

最佳實務
  • 以反覆式開發方式去開發軟體
    每個開發流程的目的都是期望在專案的四大變數:成本、品質、時程與規模達成一定的均衡
    但前三樣由客戶決定,能夠控制的只有「規模」,將規模分階段完成
  • 需求的變動管理
  • 以元件為基礎(Component-based)的架構
  • 用視覺化方式製作軟體模型(Visually Model Software)
  • 持續驗證軟體品質
1.1.3 軟體的變動無常
軟體系統的專案開發,特別的是,需求往往不明確,更何況是經常處於變動中,所以導
致專案的範圍與規模無法界定,連帶也引起時程無法估算。能做的只有將變動抑制收斂在某一程度可被控管的範圍
專案四大變數:成本、時程、品質與規模中,前兩樣都控制在客戶,能夠控制的只有「規模」=> 將規模分階段完成 ( I & I)

1.1.4 典型開發模式 - 瀑布式 (Waterfall)
因軟體「變動無常」,所以想要「凍結」,再開發出系統,如同建築工程,但軟體開發與建構大樓的差異在於瀑布式兩個基本假設點
  • 需求會固定不變
    • 更多的使用者
    • IKIWIS效應(I'll Know It When I See It)
      只有到實作完成,有了畫面,使用者才能知道他是否為他要的
    • 無法捕抓需求足夠的細節和精確度
  • 紙上談兵 - 從設計圖就可以導出正確的實作 (Implementation)
    軟體工程的基礎理論很薄弱而且缺乏瞭解,探索的方法也非常糙。直到實作時,發現設計有嚴重瑕疵,造成系統崩潰。
管理階層易接受「瀑布式」,因為每個階段都有「明確」、「標準」的產出,方便「監督」與「追蹤」

1.1.5 I&I(Iteration and Incremental)的開發模式
Iteration就是將整個專案生命周期,分成好幾個迷你專案,每個專案有自己的開發循環,包括分析、設計、實作與測試。
有多迷你?
以「使用案例(Use Case)」或「功能點(Functioinal Point)」為功能單位,大約一星期,最晚不超過兩個星期。每個功能單位,依複雜度切為2~5個Iteration,從第一固Iteration對框奇目標的建立,然後逐漸加入細節,從低精確度往高精確度,到最終完成定案的產出。
好處?開發時間會縮短?
其實沒有,因為重點在提早揭露風險(Risk),而儘早處理掉。開發人員可在一個Iteration看到具體成果,從中得到Feedback,隨時回頭修正,時間不會離得太遠,而不會等到整個系統完成了,使用者才說這不是我要的,或是架構要調整。
優點:
  • 提早降低風險
  • 較早能具有可視性(Visible)的進展(Progress)。
  • 較早能得到回饋,較可以得到使用者的保證(engagement)及適應性(adaptation)由此再精緻由此再精緻(refine)系統的設計,以更進一步契合使用者的需求。
  • 增加團隊的信心,並且可以一直持續學習。
  • 產品的整體品質較佳

系統分析設計與實作課程大綱

Iteration #1

課程階段目標:找捉系統功能需求,快速設計,立即產出程式碼 (先求有)
重點在做出來,著重抓需求
  1. 軟體開發方法論 - 開發流程與塑模
    • 開發模式介紹
    • 專案開發的工作流程
      • 各角色人員的工作執掌
      • 各階段的產出(artifacts)介紹
    • 軟體開發的最佳實務
    • 軟體塑模 - UML介紹
  2. 需求面的功能分析設計 - Modeling by UML 三劍客
    需求如何mapping到實作
  3. 物件導向觀念養成與應用- 觀念、模型與程式碼的三面表達
  4. 實做面 by Spring Framework
  5. 案例分析與實作

Iteration #2
課程階段目標:重構程式碼與類別結構,讓系統更有彈性 (不影響原功能下,改善系統)
  1. 軟體結構面的分析與設計
  2. 重構
  3. 案例分析與實作

整體開發流程總複習
  • 檢視兩個循環(Iteration)開發所各自產出的設計圖與程式碼
  • 回顧每一個流程開發階段的產出與所運用的設計、技術與技能
  • 學員課程中的問題提問與回答總整理

星期六, 6月 05, 2010

系統分析設計與實作 Week 9

Iteration 1
目的:將需求轉實作
=>要求都要配Controller
整合是持續性的在做整合

軟體開發方法
  1. Data-Orented
    易陷入細節,不易抓出圖
  2. Service-Oriented
    延展、彈性、重複利用


測試 unittest
功能性 => Controller
單元性 => Unit test, Business Object

User方面有UAT(User Acceptance Test)使幅者接受度測試

設計資料庫
設計表格
4大類 (人,事(event)/時,地物)
  1. 抓名詞(需求陳述中抓)
    但片斷,不易看到全貌,需求明確,才能完整
  2. 抓核心
    訂烏龜系統=>訂的event
    門禁管理=>刷卡的event (書UML.P148)
    儘可能容變動的需求
需求不再是主導系統的唯一來源
Enterprise => Transaction
Sub query易隱念企業邏輯,反而影響維

Q & A
  1. UML必要畫?
    UML是個語言,語言是用來溝通,所以獨立一個人開發時,基本上不用畫
  2. 交接時?
    需要時再畫,多一張就多需要維護成本
  3. 如何引導客戶提出需求
    客戶分1.Domain Expert可用活動圖(作業流程)或火箭圖
    2.Operator 直接用畫面UI溝通
    流程圖最好能當場畫,讓使用者確認,避免誤解
  4. CURD
    利用actor當授權

系統分析設計與實作 Week 7

烏龜訂購系統
phase 2 萃取穩定的結構共用元素(企業物件)
  1. middle ware
  2. controller
一開始不容易馬上判斷出來,可先放controller,再透過重構方式「逐漸萃取」
ex. 「計算訂購總額」應該放哪
hint: 推理,不要強記
「計算訂購總額」理論上放在訂購object上,但應該抽出到BO(企業物件),當共用的元素
過去,放store_procedure或script都不算好
但一開始要不容易抽,所以折衷先放controller
將來重構放到business object
=>將可共用的企業規則抽出

交易事件
人,(事/時),地,物
  1. 界定範圍
    利用UC,一般抓到5,6成就夠了
    • User Case View
    • Locial View
      -UC Realization
      -Class Model (配合codegen)
    UC都是片斷,有滿足即可,不要流程,至於滿足的程度依"Session"來判斷
  2. 撰寫UC敘述
    把「容易變」的跟「不容易變」的分開
    共用的可抽出來放
    =>產出Document
  3.  
  4. 實現UC (logical view realization)
    用UC Diagram當doc type
    *橋接實作,即建Conroller
  5. 建Controller
    設計可能會漏掉,由實作(feedback)去做調整,補足或修正Controller, UC Description
    隨時都在調,因此文件要少、精簡,過程中都是只是最後文件的snapshot

16.1.3.資訊系統的分層結構
  • 表達層(Presentation):UI
  • 中間層:CO(Control Object)
    DAO: 將DB存取細節放至DAO,任何跟DB有關的存取透過小弟DAO解決
    Adapter:外部系統的鏈結
    軟體主結構即抽出的概念性物件BO
  • 資料層:Database

三大物件
  1. Controller
  2. Boundary
    實體變動
  3. BO
    應付Domain變動,一開始不易抓,先放controller

循序圖不是要表達精細,重點在完成某功能時,反應run time的流程
EA做Sequence Diagram時,拉物件會要選擇"Simple link or Instance", 選instance,因為是物件
隱含的method用加雙斜線 ex.到db抓資料=>//select

不用每個UC都畫Sequence,只畫比較需要的
何謂需要
programmer無法看出必要的method(無共識時)
UI, Controller 應分開獨立的Project

系統結構面
Jobcason將結構分為
控制
實體
邊界
目的:好分類->好維護
結構只對developer有好處(好維護),User只看畫面

---
為何叫物件導向
都是用類別在定義,為何不是類別導向
心中想像的是物件在互動,而利用class描述出來,
ex. 作曲做的是音樂,但是得利用五線譜「作曲」記錄

星期四, 3月 11, 2010

案例圖

目的:滿足系統外部的參與者對系統的某種預期
一個使用案例代表使用者在完成該期望後,就可以離開系統

界限(Boundary)
明確表達系統該關心與不應關心的部份

Reference
UML團隊開發流程與管理

UML應用時機

from UML團隊開發流程與管理

Ch2.企業流程與系統需求 (活動圖、案例圖)
1.瞭解企業流程
ex.記錄現在流程,如SOP
利用活動圖記錄大流程,幫助瞭解

2.取得系統需求
ex.使用者的需求
利用案例圖記錄大方向的系求需求,重心放在該功能需求的描述上
注意不是開發者想提供的功能
-利用使用者易理解的字眼來描述某功能需求
-描述是「目的性」,而非「操作性」
-明確指出相關人員及系統

Ch3.表達系統內部的結構
(類別圖、循序圖、溝通圖)
3.記錄關係
利用類別圖建立通盤性的瞭解

4.記錄流程
利用循序圖說明案例的流程中物件間的互動關係
溝通圖呈現物件結構與合作關係

Ch4.系統的微觀設計 (物件圖、狀態機圖、時序圖)
5.記錄特定時間點中,所有物件在系統的結構,如同某時間點的「快照」
ex.住院事件發生,有病人物件、主治醫生物件、住院醫生物件…
物件圖

6.有複雜的狀態轉換時
ex.病床需為empty才能住
利用狀態機圖描述狀態轉換的機制

7.超過特定時間,要改變狀態
ex.ATM操作
利用時序圖

Ch5.表達系統的鉅觀設計 (套件圖、互動概觀圖、複合結構圖)

活動圖

主要目的:陳述活動與活動之間的流程控制的轉移

適合用在描述企業的本質性的工作流程(Essential Workflow)
盡可能把「中介產出文件」(抱括表單、報表等)排除在外
不要落入活動的細節,需要的是整體業務流程的「大方向」
過早介入流程細節,需求收集容易陷入分析癱瘓陷阱

誤解
誤認活動圖中的活動是可以「共用」
因此想將相關活動併成一張活動圖使用
這會喪失活動圖的易讀性,也無法可顯「共用」的精神

資源的共用性很難透過活動圖來表達
活動圖的目的在表達流程的完整性,而非表達資源的共用價值
重點:活動是沒有共用性
繪製活動圖時,比較不容易綁手綁腳

設計原則
-目的在表達「流程完整性」,而非活動細節
-元素(主要是活動)不要考慮共用的議題
-繪製了「分派點」,則一定有個「會合點」
-盡量不要表達「文件」或是「資料」

Reference
UML團隊開發流程與管理

星期三, 10月 03, 2007

UML學習筆記

開發專案可先從Funcation下手,以先瞭解需求
●Funcation View (系統應該如何運作)
1.Use case diagram =>使用案例圖描述使用者期待系統提供的特性。
系統應該提供什麼。需求功能被視為目標。再以narrative來補充,以描述各使用案例被期待完成什麼,以達到各目標。

2.Activity diagram =>描述包括連續任務、條件邏輯及一致性的程序。
利用活動圖繪製邏輯。也可用來評估應用程式的複雜度,細節複雜時,如果用活動圖畫出來,將使邏輯變好懂。

●Static View (藍圖及關係)
1.Class diagram (general )
2.Object diagram (concrete)

●Dynamic view (互動、狀態改變)
1.Squence (互動)
2. collaboration (互動)
3. statechart(object如何與外剖刺激互動,並管理內部改變)