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