三、架構設計的過程
本人經歷過不少項目，一些項目的架構設計負責人能力很強，接到活之后，馬上一頭扎進設計，抽象出一堆玄玄乎乎的概念，講得人暈頭轉向的，讓人覺得高深莫測，但是，在會議上卻被涉眾提的一些簡單的問題問得很倉促，究其根本，還是漏考慮了涉眾的需求，被人提問而又缺乏準備，是不是很多人有類似的經驗？：）
我們還經常遇到的場景是設計人員通常為一些模型、概念爭論不休，公說公的英俊，婆說婆的漂亮，其實模型概念這東西就像人的人生觀和世界觀，是人對世界和人生的主觀認識，可能隨著年齡階段的變化而變化，而且有時候沒有絕對的對與錯，就像有些人喜歡金戈鐵馬，有些人喜歡與世無爭，我們很難說誰一定是對的一定是錯的！遇到這種清醒時，我建議停下爭論，爭論方各自拿出實際的業務場景來檢驗模型，哪個模型對場景的滿足度更好，實現成本更低則更好，如果兩個都挑不出刺兒，隨便選一個即可。
還有一些架構設計人員喜歡創造一些與眾不同的概念，讓人看上去顯得高深莫測。我覺得如果一個架構師能夠用最少的語言、文字把問題和方案講清楚，那才是真正的有水平！你讓人暈頭轉向的時間既是項目的成本，因此，我們創造概念詞匯的時候，需要從涉眾的角度出發，我這里的意思不是盲從涉眾語言詞匯，而是說出發點從涉眾角度出發，如果涉眾原本使用的語言不夠準確，我們可以跟他們一起探討，定義更合適的概念詞匯。
還有一個就是對軟件競爭力的認識。有人通過包裝一堆玄玄乎乎的概念來顯得很高深莫測，試圖通過這種方式讓人覺得有競爭力，我認為，競爭力首先是要跟對手比，其次一定是涉眾能感知的，能夠涉眾帶來正向價值的，比如省多少成本，端到端業務流程節約多少時間。
我認為遵循一個科學的架構設計過程跟上篇提到的軟件架構4+1視圖法是架構設計的兩個法寶，一個指導思維、定義輸出，另一個指導如何來做，相輔相成，確保架構設計人員全面而正確的理解需求，做好需求平衡、設計平衡，設計出實用的、能落地的架構。
下面我會按順序講解架構設計的過程，以及每個步驟具體要做的事情。
3.1 確定涉眾
一般來講，涉眾包括客戶（資方）、承接方（勞方）、用戶。我們通常找到代表某一類型的涉眾群體的代表人：客戶代表、勞方代表、用戶代表等。訪談的時候直接找代表進行。
3.2 確定系統邊界
對于要明確實現某種標準的軟件系統，通常確定邊界非常容易，直接按標準圈定的scope分析即可，比如像SIPServlet容器，是要求遵從JSR168規范的，那么軟件系統的Scope就是JSR168規定的Scope，但是也有例外，比如客戶或者勞方明確指定要復用一個現有的實現了部分功能的系統或組件，那么Scope就不同了。對于沒有標準的軟件系統，就需要分別訪談客戶代表、承接方代表確定系統邊界。為什么要訪談承接方代表呢？因為承接方代表往往是勞方領導，領導肩負企業戰略達成的使命，很有可能對系統提出比客戶更多的要求。舉個例子，某客戶需要一個SIP通信協議棧，以實現三方通話的業務，但是勞方領導認為，后續ICT融合是趨勢，我們構建的系統要支持ICT融合應用部署和運行，支持業務標準JSR168規范。
3.3 軟件需求收集
軟件需求可分為二類：
功能需求（即業務用例）：描述Actor（用戶或系統）可基于軟件系統做什么事，要符合什么業務規則；
非功能性需求又可分為兩類：
質量屬性：質量屬性指軟件系統的品質，可分為運行期質量屬性與開發期質量屬性。
運行期質量屬性包括
（1）性能：性能是指軟件系統及時提供相應服務的能力。具體而言，性能包括速度、吞吐量和持續高速性這三方面的要求。
（2）安全性：指軟件系統同時兼顧向合法用戶提供服務，又阻止非授權使用功能的能力。
?。?）易用性：指軟件系統易于使用的程度。
（4）可用性：可用性與易用性不相同?？捎眯灾赶到y長時間無故障運行的能力。
（5）可伸縮性：指當用戶增加時，軟件系統維持高服務質量的能力。
?。?）互操作性：指本軟件系統與其他系統交換數據和相互調用服務的難易程度。
（7）可靠性：軟件系統在一定時間內無故障運行的能力。
?。?）健壯性：也稱容錯性。是指軟件系統在異常情況仍能夠正常運行的能力。
開發期質量屬性包括：
（1）易理解性：是指系統設計能被開發人員理解的難易程度。
?。?）可擴展性：為適應新需求或者需求變化，為軟件增加功能的能力。有些時候，稱之為靈活性。
?。?）可重用性：重用軟件系統或其中一部分的能力的難易程度。
（4）可測試性：對軟件測試以證明其滿足需求規約的難易程度。在實際的項目中，主要指進行單元測試等難易程度。
?。?）可維護性：修改Bug，增加功能，提高質量屬性。
（6）可移植性：將軟件系統從一個運行環境轉移到另一個不同的運行環境的難易程度。
約束：規定開發軟件系統時必須遵循的限制條件，如要基于什么操作系統，要基于什么開發語言等等。
對于功能需求，可找系統的直接使用用戶代表，對其進行訪談，收集其要基于系統做的事情，可按照標準的用例模板，在訪談的過程中引導用戶代表。之后，繪制業務用例視圖，并針對每個業務用例，使用標準的用例模板將功能需求編檔，通常叫用例規約。
對于非功能性需求，可找軟件系統的涉眾，依據下面的模板，引導涉眾，收集其對相應質量屬性的要求：
總結：本階段需要輸出業務用例視圖，業務用例規約，非功能性需求。
待續。。。