懂得從各領域的表象中跳脫,直接探究核心本質,才能掌握軟體結構分析之道。本書的類別表示法採用作者自創的語法,它可說是自成一格,例如多重性(Multiplicity)剛好與UML類別圖的表示法完全相反,所以一定要先閱讀附錄的語法說明,才不會搞混。  | Object Models: Strategies, Patterns, and Applications Peter Coad,David North,Mark Mayfield/著 Prentice-Hall ECS Professional出版 售價:85美元 Amazon四顆半星 |
擔任系統開發顧問多年,我觀察到各行業(金融、鋼鐵、保險、零售、股票……等)的資訊主管,幾乎清一色要求軟體架構師(SA)要懂得相關領域知識(Domain Knowledge),認為這樣才能作好系統分析。
然而,SA最多只能代表操作人員(Operator)層級的功能需求分析,核心知識包括企業流程的制訂改善等事務,則是由領域專家(Domain Expert)所掌握。
SA與SD(System Designer)均太過偏重領域知識的結果(在臺灣,SA與SD 的分界一向不明顯,可能是SA與客戶訪談需求,然後由SD作E-R Model資料庫表格的結構分析),反而忽略軟體結構分析的重要性,所抓出來的Entity (經常呈現為資料庫表格),往往耦合性(coupling)太重,導致牽一髮而動全身,無法彈性應付變動。
我經常建議SA與SD要學習與各專業領域專家溝通合作,將核心知識抽象化為軟體系統的結構,所以,SA與SD應具備的,不是其他領域的專業知識,而是結構分析的萃取能力,那是一種可以獨立於各個問題領域(Domain)與IT平臺技術的通用技能,我常稱之為「純」軟體的抽象分析。
全文>>
沒有留言:
張貼留言