分類彙整: 分析設計建模

軟體設計須面對現實

最近看到有人領域模型中的客戶類別如此設計: 這個設計觀點是將個人戶與公司戶都看成 … 閱讀全文

分類: 分析設計建模, 設計原則, 軟體開發 | 10 則留言

類別設計演化論

最近HSDc有一篇文章,主題是《繼承或是一般化?》,作者Ringle Lai認為 … 閱讀全文

分類: 分析設計建模, 設計原則, 軟體開發 | 15 則留言

不要用技術來主導需求分析

很多系統分析師喜歡用技術的眼光來看客戶的需求。當客戶提出他們的看法之後,系統分析 … 閱讀全文

分類: 分析設計建模, 問題解決, 軟體開發 | 8 則留言

軟體設計並不昧於專案現實

專案現實不但不會侵蝕我們的能力,而是讓我們能力與時俱進,因為軟體設計是不昧於專案現實的,所以專案前期面對現實的規劃(管理面)與分析設計(技術面)是必須的 閱讀全文

分類: 分析設計建模, 品質文化, 易經思維, 系統思考, 軟體開發 | 4 則留言

模組與耦合

其實國內的workflow engine廠商其實都聲稱符合WfMC工作流程標準,但一般人很難了解它們各模組間是否有做到真正的分離。曾問過幾家workflow engine要如何整合其應用程式,所得到的答案多半是「客製化」這個專業術語,但進一步了解才發現,他們並未設計界面來做為減震點(Decouple Point)以減少不必要的模組相依,而是模組必須和特定的實作緊密耦合在一起,也就是他們的客製化會使原先定義良好的模組被破壞了。因此可以推知他們並不是採用模組分離的設計,也就是並未符合所謂的模組鬆散耦合的理想。我想這當中除了作業環境會有不相容的問題外(Web base vs. AP base),更重要的原因就是市場利基的考量,技術問題容易克服的,但workflow市場恐怕還沒具備須鬆散耦合設計的條件。 閱讀全文

分類: 分析設計建模, 設計原則, 軟體開發 | 4 則留言

軟體的模組化設計思維

針對需求的不確定,軟體設計的方式應該做一些調整。從為需求而設計轉變成為延緩(Postponement)的設計策略,也就是為開發後續開發活動(實作、測試、組裝、配置)預留空間而設計,於是DTx(Design for xxx)的概念於是應運而生。 閱讀全文

分類: 分析設計建模, 設計原則, 軟體開發 | 5 則留言