本人曾經閱讀過《軟件架構設計》一書的第一版，讀了之后對架構設計的方法、流程有了更深刻的認識，也對我后續的工作起了非常大的指導作用。最近從ITEye上了解到溫昱先生出了《軟件架構設計》一書的第二版，趕緊下了樣章讀了一下，感覺第二版相比第一版，在概念、方法、流程、實踐幾個方面的指導性更強了，實在是程序員升級架構師必備良書！
下面基于我實際經歷的一個項目，結合對《軟件架構設計》一書的理解，談一下質量屬性的設計。
首先介紹一下項目背景，某大型電信解決方案提供商向全球電信運營商提供某軟件系統，因不同的運營商需求有差別，需要投入大量的人力物力對某個特定的運營商進行客戶化定制，成本較高，為了降低定制成本，該提供商將交付組織切分為負責通用版本的組織A和負責針對特定局點定制的交付組織B，且成立了一個項目專門提升該軟件系統的可定制性，以實現這種分級交付，降低定制成本。
項目啟動后，負責該項目的架構師憑借豐富的經驗馬上啟動了架構設計，他從業界同類產品了解到，業界為了提升定制能力采用了元數據驅動的架構風格，于是馬上開始了元數據驅動框架的設計，設計好之后召集開發人員和管理人員開了個溝通會，會中，該架構師被兩個問題難住了：
1）有個定制開發人員問，如果基線版本升級了，能否保證定制版本做的修改能夠被直接繼承？在這個問題上，大家發生了激烈的爭論，架構設計團隊認為有些場景可以，有些場景不可以，而定制開發人員的理解跟架構設計團隊的理解不一樣，最終該問題被擱置下來，后續再論。
2）管理人員問，對定制能力目標，我們怎么測試和驗證目標是否達成。這個問題比較毒，一下子把架構設計團隊問傻了，沒人答得上來，于是被罵了一頓。
問題在哪里？？看了《軟件架構設計》的第9章“概念性架構設計”就能找到答案。我認為的問題有：
1）沒有從系統各Actor的角度，分析定制用例，導致重要定制場景遺漏，被問起的時候自然就捉襟見肘；
2）沒有將定制能力目標分解到定制場景，導致對設計缺乏度量，不知道設計到底能不能滿足定制能力目標要求，自然也回答不了“通用版本與定制版本的邊界”這類的問題。
要怎么做呢？？看了《軟件架構設計》的第9章“概念性架構設計”就能找到答案。我認為，應該遵從下面的步驟，才能確保定制目標的達成：
1）分析定制的Actor，比如定制開發人員，定制運維人員等；
2）針對各Actor，分析其定制用例，如開發人員增加一個業務、修改一個業務流程、增加一個業務實體字段等等；
3）針對每個用例，結合定制能力目標，分析該Actor的工作流程，通過這一步的分析，通用版本的邊界（系統用例）能夠大致識別出來。
4）再針對關鍵系統用例，進一步使用分析對象進行魯棒分析；通過這一步，對元數據驅動框架的能力要求能明確下來；
5）然后在進一步對元數據驅動框架進行細化設計；
通過這樣一個系統的方法和流程，我們才能保證做出符合業務目標的可定制性設計。其它類型的質量屬性的設計方法和流程也是類似的。
其實那個負責可定制性設計的架構設計團隊不管是業務經驗還是技術能力，都是比較扎實的，關鍵是沒有掌握一個比較科學的設計方法和流程。因此，廣大程序員兄弟們在實踐的同時，一定不能忘了提升理論素養，這樣才有利于更早的打破天花板，獲得更大的成功。