2009年6月20日 星期六

W18 快速開發的工具(3)──進化為系統分析工具(SA Tool)

限制整個Workspace的UI編輯工具為只能編輯專案層級的元件時,編輯的對象就會只有Use Case下的流程,選用的範圍則是該tier提供的Activity。執行流程的定義只是SA的一部分,所有與交易相關的定義都應該被容納到系統分析工具裡才是完整的SA Tool。

這表示交易相關的輸入與輸出都要被考慮,像是畫面的設計、列印的格式、主機電文的切割定義、主流程的功能選擇、輸出入欄位與Context的對應……等等都應該呈現在工具裡。另外整個系統的設計也應該被定義,像是角色的定義、交易的定義、資料的定義、以及任二者之間的關聯……等等。SA Tool的好處在於進行需求訪談的同時,可以利用系統收集全部相關資訊並立即使用,在快速定義交易的同時盡量避免產生一些已知的問題。

上述每一個編輯項目都應該要能嵌裝與拆解,施行時視系統實際的架構關聯來設定SA Tool應該具有哪些模組。這是一個更龐大的工程,系統開發時所需要的一切概念組成的架構與關係需要精確地定義與設定,再根據這個架構去設計呈現的UI編輯工具;我們當然明白,只要那個架構有所變更就會影響到SA Tool需要再度改寫。換句話說,除非能夠研究出開發系統時會有的所有定義與關聯,要不然SA Tool應該是個會被改來改去的玩具,或者是寫死為只適用在自己專案裡某部分的特定工具而已。

"可被遞迴處理的元件結構"是對程式設計的目標,"通用的系統分析工具"則是對系統開發的理想。縱使這兩個想法的背後都需要艱難的分析設計與實作,不過若能確認能夠解決大部分的現有問題而沒有邏輯上的破綻,這個決心是不會變的。

沒有留言:

張貼留言