我個人認為,完整覆蓋「需求進,架構出」的架構設計方法才是符合一線實踐需要的。
pre-architecture就是架構設計的最前期階段,其工作目標包括:理解需求、建立需求大局觀、確定架構設計方向等。
「磨刀不誤砍柴工」,這是近乎常識的古訓。整個admems方法包含pre-architectureconceptual architecture. refined architecture 3個階段。如果說, conceptual architecture和refinedarchitecture 階段是「砍柴」 (這兩個階段都對系統進行了某種程度的切分,系統已經不再是「黑盒子」了),那麼最初的pre-architecture階段就是「磨刀」(此階段未對系統進行切分,系統還是「黑盒子"。
需求理解的大局觀
架構師常常面對相互矛盾的需求目標。如果對需求的理解缺乏大局觀,那將如何進行需求的權衡取合?
重大需求塑造概念架構。如果對需求的理解缺乏大局觀,那將如何識別重大需求、特色需求、高風險需求?
架構師必須在相對短的時間內設計架構。如果對需求的理解缺乏大局觀,那將如何進一步運用「關鍵需求決定架構,其餘需求驗證架構」的策略?
prearchitecture 段能幫助架構師建立需求理解的大局觀。任何需求都可定位於業務級需求、使用者級需求、開發級需求這3個需求層次的某一層,同時也必屬於功能、質量、約束這3類需求的某一類。如此一來,就便於梳脈理絡、把握關係。
建議架構師在參與需求分析工作時,不斷運用admems矩陣等工具對需求進行大局的梳理,只要滿足下列3個條件(如圖3-3所示)就可以盡早開始架構設計工作:
1,有了明確的業務需求。必須保證甲、乙雙方就建設系統的目標(可能不止一項)達成了共識, 《願景文件》經過了正式評審,並且明確了投資、工期標準、整合等約束條件。試想,業務需求含糊不清,架構設計方向如何確定呢?
2,了解全面的使用者需求。也就是說,系統能幫助使用者幹什麼、不能幹什麼,這個「需求的scope」已經非常明確了。如果採用了用例技術,則表現為「用例圖」是比較完善的,沒有明顯的遺漏(注意用例圖和用例規約在需求分析中的實踐意義不同,可參考《軟體架構設計》一書)。
3,有了典型的行為需求。這意味著,大量行為需求還未明確定義,離提交《軟體需求規格說明書》還早。如果採用用例技術,則表現為核心功能的《用例規約》已定義。
一線架構師實踐指南閱讀筆記2
一線架構師實踐指南閱讀筆記2 第6,7章 concepture architecture 概念性架構 把最關鍵的設計要素和互動的機制確定下來，然後考慮具體技術的運用，設計出實際架構。概念性架構界定系統的高層元件，以及它們之間的關係。概念性架構意在對系統進行適當分解，對高層元件的職責進行了籠統的界定，...
《一線架構師實踐指南》閱讀筆記02
架構 是人們為了提高生活質量，進而為了提高生產力，接著為了提高生產效率，而做出的對目標的有機的分割。這種分割與建築的架構是一樣，對目標內部進行空間切分，又留下門窗與各部分進行連通，讓各部分相互隔離而又可以有效的溝通。就好像我們的社會，我們每個人通過自己的工作掙到錢 分割 讓後通過錢與物的交易 溝通 ...
《一線架構師實踐指南》閱讀筆記01
第一節課結束以後一臉懵逼，我有了了很多問題，其中的大前提什麼是軟體架構模式？設計模式是一套解決類似問題的經驗的總結。採用設計模式的目的是為了可重用 而架構模式也乙個通用的 可重用的解決方案。我覺得他們的區別是，設計模式跟 更有直接關係，架構模式站在系統全域性的角度解決子系統之間的關係 功能需求與非功...