確定對架構(gòu)的關(guān)鍵需求

《確定對架構(gòu)的關(guān)鍵需求》由會(huì)員分享，可在線閱讀，更多相關(guān)《確定對架構(gòu)的關(guān)鍵需求（15頁珍藏版）》請?jiān)谘b配圖網(wǎng)上搜索。

1、關(guān)鍵需求決定架構(gòu)。 軟件架構(gòu)師沒有時(shí)間對“所有需求”進(jìn)行深入分析，這是現(xiàn)實(shí)——大多數(shù)項(xiàng)目都面臨項(xiàng)目工期的壓力，軟件架構(gòu)師必須在一定的時(shí)間內(nèi)定奪架構(gòu)設(shè)計(jì)方案；否則，沒有軟件架構(gòu)所提供的對技術(shù)的足夠指導(dǎo)以及對分工協(xié)作的足夠限制，后期的團(tuán)隊(duì)開發(fā)將面臨巨大風(fēng)險(xiǎn)。 軟件架構(gòu)師沒有必要對“所有需求”進(jìn)行深入分析，這是策略——把大部分時(shí)間和精力花在對決定架構(gòu)最重要的一部分需求上，好鋼用在刀刃上，最終你設(shè)計(jì)出的軟件架構(gòu)的質(zhì)量反而會(huì)更高；否則，所有需求的分析都不夠深入，導(dǎo)致最終設(shè)計(jì)出的軟件架構(gòu)可能會(huì)流于形式。 6.1 虛擬高峰論壇：窮兵黷武還是擇戰(zhàn)而斗 解釋一下這兩個(gè)隱喻。所謂“窮兵黷武”是指把所有需求

2、徹底分析一遍從而設(shè)計(jì)出軟件架構(gòu)的做法，而“擇戰(zhàn)而斗”是指為了設(shè)計(jì)架構(gòu)僅重點(diǎn)分析對軟件架構(gòu)起關(guān)鍵作用的一部分需求的做法。 讀書猶如和作者交談。本節(jié)的寫作形式頗為輕松：我們假設(shè)把一些高人請到了一起，就“從軟件需求到軟件架構(gòu)”問題展開一個(gè)“高峰論壇”（當(dāng)然是虛擬的）。 6.1.1 需求是任何促成設(shè)計(jì)決策的因素 說到底，一個(gè)軟件系統(tǒng)的軟件架構(gòu)最終設(shè)計(jì)成什么樣，是由軟件需求決定的。 咨詢專家Brian Lawrence提出：“需求是任何促成設(shè)計(jì)決策的因素（Anything that drives design choices）?！? 6.1.2 很少有開發(fā)者能奢侈地?fù)碛幸粋€(gè)穩(wěn)定的需求集 “

3、需求決定架構(gòu)”。話雖這么說，但現(xiàn)實(shí)要復(fù)雜得多，因?yàn)檐浖枨蟊旧頃?huì)因需求背景的變化和項(xiàng)目人員的理解等問題發(fā)生變更。 正如《軟件需求管理：統(tǒng)一方法》的作者Dean Leffingwell所說：“很少有開發(fā)者能奢侈地?fù)碛幸粋€(gè)穩(wěn)定的需求集……” 6.1.3 關(guān)鍵性的第一步是縮小范圍 勿在浮沙筑高臺(tái)。倘若作為架構(gòu)設(shè)計(jì)重要依據(jù)的軟件需求變化了，你建起的軟件架構(gòu)這個(gè)“高臺(tái)”豈不是要倒塌？ 杰拉爾德溫伯格的話讓人更深刻地體會(huì)到了“運(yùn)籌帷幄”應(yīng)有的含義，他說：“關(guān)鍵性的第一步是縮小范圍……” 6.1.4 要擇戰(zhàn)而斗 窮兵黷武還是擇戰(zhàn)而斗，這或許不是問題，因?yàn)槲覀円呀?jīng)傾向于擇戰(zhàn)而斗了。但問題在

4、于，擇戰(zhàn)而斗怎么個(gè)“擇”法。 PeopleSoft公司的首席技術(shù)官Rick Bergquist說得精辟：“我的第一個(gè)老板John Grillos曾說過，要擇戰(zhàn)而斗。擇戰(zhàn)的標(biāo)準(zhǔn)如下：它們要具有重要性，它們要具有可能性，它們的數(shù)量要少?！? 6.1.5 功能、質(zhì)量和商業(yè)需求的某個(gè)集合塑造了構(gòu)架 方向已經(jīng)明確了，不是嗎？軟件架構(gòu)師要著重深入分析的是軟件需求的一個(gè)子集，再結(jié)合自己的經(jīng)驗(yàn)，最終設(shè)計(jì)出軟件架構(gòu)。 卡內(nèi)基梅隆大學(xué)軟件工程研究所的Len Bass指出：“功能、質(zhì)量和商業(yè)需求的某個(gè)集合‘塑造’了構(gòu)架。我們把這些塑造需求稱為‘構(gòu)架驅(qū)動(dòng)因素’?！懒藰?gòu)架驅(qū)動(dòng)因素后，就可以開始構(gòu)架設(shè)計(jì)了

5、?！? 6.2 關(guān)鍵需求決定架構(gòu) 6.2.1 實(shí)踐中的常見問題 在從需求工作向架構(gòu)設(shè)計(jì)工作轉(zhuǎn)移的環(huán)節(jié)上，我們在實(shí)踐中暴露出一些問題。對于軟件架構(gòu)師而言，這些問題在一定程度上相當(dāng)普遍，所以我們一起來解決它們。 問題一：抱怨留給架構(gòu)設(shè)計(jì)的時(shí)間太短，而不是接受項(xiàng)目節(jié)奏普遍加快的現(xiàn)實(shí)。 從根本上講，這是沒有意識(shí)到軟件開發(fā)所根植于的業(yè)務(wù)背景——當(dāng)然，我相信或多或少也受到瀑布模型的影響。無論是對于企業(yè)業(yè)務(wù)還是個(gè)人業(yè)務(wù)，在復(fù)雜和高速變化的經(jīng)濟(jì)環(huán)境里，在對手云集的競爭條件下，軟件系統(tǒng)“上馬”太慢本身就潛藏著巨大風(fēng)險(xiǎn)。在《非程序員》第50期中有一篇來自Markus Vlter和Jorn Bettin

6、的論文《模型驅(qū)動(dòng)軟件開發(fā)模式》，其中強(qiáng)調(diào)新的商業(yè)應(yīng)用的開發(fā)期最多不得超過9個(gè)月： …… 每三個(gè)月至少要提供可交付代碼。 理想情況下，每三個(gè)月應(yīng)將代碼部署到產(chǎn)品中，并得到實(shí)際反饋。 新的商業(yè)應(yīng)用的開發(fā)，必須在九個(gè)月之內(nèi)“哇哇墜地”，否則就可能危及“媽媽”（開發(fā)組）或“嬰兒”（應(yīng)用）的生命…… 問題二：認(rèn)為必須詳細(xì)分析所有的需求，只有這樣才能設(shè)計(jì)出滿足所有需求的軟件架構(gòu) 有仗就打、有人討敵罵陣就出戰(zhàn)，這種情形在歷史小說里經(jīng)常見到，但往往出現(xiàn)在有勇無謀的武將身上。與此類似，想要將所面對的所有需求都分析一遍的軟件架構(gòu)師是否想過：這是否現(xiàn)實(shí)？在有限的時(shí)間里，將精力分散在過多的問題上，其結(jié)果

7、往往是效果更差。 我們的策略是：關(guān)鍵需求決定架構(gòu)，其余需求驗(yàn)證架構(gòu)。 順著“全面認(rèn)識(shí)需求”的策略思考開去，很容易讓人產(chǎn)生疑問：你是在說瀑布式開發(fā)嗎？當(dāng)然不是。我們的策略是：在架構(gòu)設(shè)計(jì)期間，關(guān)鍵需求決定架構(gòu)，其余需求驗(yàn)證架構(gòu)。也就是說，“關(guān)鍵需求決定架構(gòu)”和“全面認(rèn)識(shí)需求”的策略是不矛盾的。 非關(guān)鍵需求可以用來驗(yàn)證架構(gòu)，比如以架構(gòu)方案評(píng)審的方式，從每項(xiàng)非關(guān)鍵需求的角度對架構(gòu)方案進(jìn)行走查。 問題三：認(rèn)為軟件架構(gòu)必須是完美的技術(shù)解決方案。 關(guān)于這一點(diǎn)，Philippe Kruchten在他的論文《Common Misconceptions about Software Architectu

8、re》中明確地進(jìn)行了批評(píng)，并指出架構(gòu)“夠用就好”： 通常，在進(jìn)行系統(tǒng)架構(gòu)設(shè)計(jì)時(shí)，時(shí)間非常關(guān)鍵。架構(gòu)師根本沒有時(shí)間去系統(tǒng)地研究每一種可能的解決方案，以找出最佳解決方案；而是必須快速?zèng)Q策，以便讓軟件開發(fā)工作進(jìn)行下去。項(xiàng)目開發(fā)就像一場“戰(zhàn)斗”，如果慢慢吞吞地研究出了最佳解決方案，只怕整場“戰(zhàn)斗”早已結(jié)束多時(shí)了，這顯然毫無意義。我經(jīng)常這樣描述架構(gòu)師的工作：在有些事情并未完全清楚的情況下，快速做出一系列并不算完美的設(shè)計(jì)決策。架構(gòu)并不是靜態(tài)功能，因此無法優(yōu)化至最佳——無論是設(shè)計(jì)約束，還是棘手問題，都不會(huì)長時(shí)間不變而“等”你找到最佳方案。架構(gòu)不是要完美，而是要足夠滿意。 6.2.2 關(guān)鍵需求決定架構(gòu)

9、采用關(guān)鍵需求決定架構(gòu)的方法，其好處有二：一曰防守，二曰進(jìn)攻。 說到“防守”，多少有些“不得不為”的意味。的確如此。 一方面，把所有需求統(tǒng)統(tǒng)確定下來之后再開始下游活動(dòng)是不現(xiàn)實(shí)的。需求來自于實(shí)踐的需要，而實(shí)踐是發(fā)展的，所以“確定的需求”只能是暫時(shí)的。于是，我們不得不在“部分需求已確定”的情況下進(jìn)行架構(gòu)設(shè)計(jì)。 另一方面，項(xiàng)目何時(shí)交付往往是由客戶業(yè)務(wù)的需要決定的，或者是由市場形勢決定的，這使得項(xiàng)目工期成了不可改變的“外部限制”（上市時(shí)間是一種非功能需求）。時(shí)間有限，我們不得不在就項(xiàng)目的業(yè)務(wù)目標(biāo)及核心需求達(dá)成共識(shí)之后開始架構(gòu)設(shè)計(jì)，而這時(shí)需求并未完全清晰化。 至于“進(jìn)攻”就是對期望目標(biāo)的“主動(dòng)追求

10、”了。我們希望追求的目標(biāo)有兩個(gè)： 第一，用有限的精力深入分析最為重要的需求。人的思維能力所能應(yīng)對的復(fù)雜性是有限的，因此人們總是有意識(shí)地將問題分解、化簡和轉(zhuǎn)換。當(dāng)我們把全部精力放在相對少的需求上時(shí)，可以更為深入地分析這些需求，有利于得到透徹的認(rèn)識(shí)，從而設(shè)計(jì)出合理的架構(gòu)。 第二，因?yàn)樾枨笫恰按俪稍O(shè)計(jì)決策的因素”，因此需求的變更可能會(huì)引起架構(gòu)設(shè)計(jì)不再適合。因此，我們希望能通過所有需求的一個(gè)子集來“驅(qū)動(dòng)”我們的架構(gòu)決策過程，這樣可以減少需求變更對架構(gòu)設(shè)計(jì)方案帶來的沖擊，使架構(gòu)設(shè)計(jì)趨于穩(wěn)定。如圖6-1所示。 圖6-1 關(guān)鍵需求決定架構(gòu)，其余需求驗(yàn)證架構(gòu) 特別是，功能需求的數(shù)量是相當(dāng)巨大的；通

11、過選取不到20%的典型功能需求，進(jìn)行有重點(diǎn)的深入分析來帶動(dòng)架構(gòu)設(shè)計(jì)，可以節(jié)約很多時(shí)間。如果再考慮到需求變更的問題，在架構(gòu)設(shè)計(jì)期間80%的功能需求的變更都不會(huì)對架構(gòu)設(shè)計(jì)的推進(jìn)造成沖擊，這太有誘惑力了；畢竟，架構(gòu)設(shè)計(jì)之時(shí)一般難以達(dá)到所有需求都穩(wěn)定的狀態(tài)。 6.3 確定關(guān)鍵需求在軟件過程中所處的位置 6.3.1 對架構(gòu)關(guān)鍵的需求vs.需求優(yōu)先級(jí) 在軟件過程上游的需求分析活動(dòng)中，我們有必要識(shí)別并記錄需求的優(yōu)先級(jí)，這對項(xiàng)目管理乃至控制交付范圍等都有重要影響。那么，項(xiàng)目經(jīng)理所關(guān)心的需求優(yōu)先級(jí)和軟件架構(gòu)師所關(guān)心的對架構(gòu)關(guān)鍵的需求之間，到底是什么關(guān)系呢？ 一“圖”以蔽之。如圖6-2所示，高優(yōu)先級(jí)的需求

12、和對軟件架構(gòu)關(guān)鍵的需求之間，既有區(qū)別又有聯(lián)系。 圖6-2 對架構(gòu)關(guān)鍵的需求vs.需求優(yōu)先級(jí) 一個(gè)事物是否關(guān)鍵、是否優(yōu)先考慮，要視具體目標(biāo)不同而定。我們通常所說的“需求優(yōu)先級(jí)”是針對客戶而言的（同時(shí)要從技術(shù)角度考慮需求之間的依賴關(guān)系），而本章的主題“對軟件架構(gòu)關(guān)鍵的需求”是對架構(gòu)設(shè)計(jì)的影響而言的，請讀者注意區(qū)分。 需求優(yōu)先級(jí)主要是針對功能需求而言的，除卻被依賴的需求應(yīng)當(dāng)優(yōu)先實(shí)現(xiàn)之外，需求優(yōu)先級(jí)主要反映了客戶希望最終系統(tǒng)提供某功能需求的迫切程度。一般而言，需求優(yōu)先級(jí)可以分為三級(jí)： 高優(yōu)先級(jí)。必不可少的功能。只有在這些需求上達(dá)成一致意見，軟件才可能被接受。這些功能的實(shí)現(xiàn)質(zhì)量必須趨于完美；

13、 中優(yōu)先級(jí)。必要的功能。這些功能是系統(tǒng)所需要的，如果有必要可以延遲實(shí)現(xiàn)。雖然不提供這些功能系統(tǒng)也有可能被接受，但最好不要忽略它們。值得為這些功能的質(zhì)量付出努力； 低優(yōu)先級(jí)。錦上添花式的功能增強(qiáng)。低優(yōu)先級(jí)的需求可以實(shí)現(xiàn)也可以不實(shí)現(xiàn)；但如果資源允許的話，實(shí)現(xiàn)這些需求將會(huì)使產(chǎn)品更臻完美。另外，對于這些需求的實(shí)現(xiàn)質(zhì)量要求不是很高，甚至可以容忍不嚴(yán)重的缺陷存在。 鑒于此，我們也就不難理解，一個(gè)項(xiàng)目中，需求優(yōu)先級(jí)為高、中、低的需求的比例應(yīng)該科學(xué)（比如3:4:3），從而有利于項(xiàng)目管理。如果將需求優(yōu)先級(jí)統(tǒng)統(tǒng)定為高，或者需求優(yōu)先級(jí)為高的需求明顯占了壓倒性的比例，這顯然是不科學(xué)的做法，違背了設(shè)定需求優(yōu)先級(jí)的

14、初衷，不利于項(xiàng)目管理中權(quán)衡與調(diào)整。鑒于項(xiàng)目管理不是本書的主題，對此我們不再展開討論。 總之，可以這么說，需求優(yōu)先級(jí)是項(xiàng)目經(jīng)理的一種權(quán)衡和決策的工具（如圖6-3所示）。該工具使項(xiàng)目經(jīng)理可以在一定程度上獲得對項(xiàng)目管理的靈活調(diào)整的余地，為了在項(xiàng)目的時(shí)間、成本和質(zhì)量要求范圍內(nèi)順利完成目標(biāo)，對項(xiàng)目所提供的功能范圍（Scope）進(jìn)行調(diào)整。 圖6-3 需求優(yōu)先級(jí)是項(xiàng)目經(jīng)理的一種權(quán)衡和決策工具 6.3.2 關(guān)鍵需求對后續(xù)活動(dòng)的影響 確定了對架構(gòu)關(guān)鍵的需求之后，軟件架構(gòu)師下面的活動(dòng)將主要針對這些關(guān)鍵需求展開（如圖6-4所示）： 無論對于概念性架構(gòu)的設(shè)計(jì)（第14章），還是實(shí)際架構(gòu)的設(shè)計(jì)（第16章），

15、都需要對關(guān)鍵用例進(jìn)行分析。此時(shí)將采用魯棒圖等用例分析技術(shù)，最終將各魯棒圖進(jìn)行綜合，得到整體的軟件系統(tǒng)職責(zé)劃分模型（也被稱為邏輯設(shè)計(jì)模型或分析模型）； 質(zhì)量屬性分析中，采用“質(zhì)量屬性—場景—決策”表等技術(shù)手段，分析質(zhì)量屬性要求，制定架構(gòu)級(jí)設(shè)計(jì)決策； 當(dāng)然，經(jīng)過質(zhì)量屬性分析之后得到的架構(gòu)決策，可能引起軟件系統(tǒng)職責(zé)劃分模型的調(diào)整。以高性能設(shè)計(jì)為例，無論是“對消息采用多線程并發(fā)處理”還是“將圖片服務(wù)器獨(dú)立出來以便進(jìn)行專門的緩存和索引等加速處理”都需要對軟件系統(tǒng)職責(zé)劃分模型進(jìn)行細(xì)化等調(diào)整。 圖6-4 關(guān)鍵需求與后續(xù)活動(dòng) 6.4 什么是對軟件架構(gòu)關(guān)鍵的需求 對軟件架構(gòu)關(guān)鍵的需求包括功能需求、

16、質(zhì)量（屬性）需求、商業(yè)需求三類，下面一一討論之。 6.4.1 關(guān)鍵的功能需求 任何功能需求，都是由一條特定的“模塊協(xié)作鏈”完成的。 所謂軟件架構(gòu)就是關(guān)于如何構(gòu)建軟件的一些最重要的設(shè)計(jì)決策，這些決策往往是圍繞將系統(tǒng)分為哪些部分、各部分之間如何交互展開的。而一個(gè)完整的軟件功能的實(shí)現(xiàn)，則需要這些不同的“部分”之間相互配合，形成一條“模塊協(xié)作鏈”，從而才能滿足一個(gè)完整的應(yīng)用功能?？刂茩?quán)在模塊協(xié)作鏈中來回傳遞，而功能需求就相當(dāng)于串起不同模塊的線索（如圖6-5所示）。 圖6-5 功能需求與模塊協(xié)作鏈（參考《AOSD中文版》） 所以，所謂對軟件架構(gòu)關(guān)鍵的功能需求，就是它涉及（或串起）的模塊最多

17、、最典型的功能需求。畢竟，由于功能需求數(shù)量眾多，其實(shí)會(huì)有很多功能需求的完成所涉及的“模塊協(xié)作鏈”都非常相似。軟件架構(gòu)師通過分析少數(shù)關(guān)鍵的功能需求，往往就可以完成一般性的模塊劃分、職責(zé)分配、協(xié)作機(jī)制定義等和功能需求密切相關(guān)的架構(gòu)設(shè)計(jì)工作。 6.4.2 關(guān)鍵的質(zhì)量屬性需求 要達(dá)到高質(zhì)量屬性要求，是有成本的。例如，持續(xù)可用性的成本最為明顯，它往往要求通過硬件及網(wǎng)絡(luò)連接的冗余來實(shí)現(xiàn)，使成本投入非?？捎^。因此，現(xiàn)實(shí)中一般應(yīng)慎重考慮對哪些質(zhì)量屬性提出高要求。 另一方面，不同質(zhì)量屬性之間往往具有相互制約性，使得有些質(zhì)量屬性需求同時(shí)達(dá)到高要求比較困難。例如，“互操作性”需求往往給“安全性”需求造成威脅，

18、而為了滿足“高性能”需求，往往需要使用特定平臺(tái)的非標(biāo)準(zhǔn)能力，這勢必影響了系統(tǒng)的“可移植性”，……，不一而足。于是，我們自然應(yīng)該權(quán)衡哪一部分質(zhì)量屬性是架構(gòu)設(shè)計(jì)的重點(diǎn)目標(biāo)。 綜上所述，對架構(gòu)至關(guān)重要的質(zhì)量屬性需求是那些經(jīng)過權(quán)衡取舍、最終決定重點(diǎn)支持的質(zhì)量屬性需求。 6.4.3 關(guān)鍵的商業(yè)需求 商業(yè)需求又稱業(yè)務(wù)需求（其實(shí)對應(yīng)的英文都為Business Requirement）。一般情況下，商業(yè)需求指“組織或客戶高層次的目標(biāo)”。但作為“架構(gòu)設(shè)計(jì)驅(qū)動(dòng)因素”的商業(yè)需求有著更寬泛的含義：它關(guān)注從客戶群、企業(yè)現(xiàn)狀、未來發(fā)展、預(yù)算、立項(xiàng)、開發(fā)、運(yùn)營、維護(hù)在內(nèi)的整個(gè)軟件生命周期涉及的商業(yè)因素，包括了商業(yè)層面

19、的目標(biāo)、期望和限制等。 目標(biāo)和期望的例子很多。例如投資開發(fā)一個(gè)軟件系統(tǒng)的企業(yè)可能期望“業(yè)務(wù)處理能力提高50%”，產(chǎn)品型的軟件公司可能期望“半年內(nèi)該產(chǎn)品的市場占有率達(dá)40%”或者“半年內(nèi)銷售20萬套”，等等。 出于商業(yè)方面考慮的限制因素五花八門，但它們往往對架構(gòu)設(shè)計(jì)有很大影響。表6-1進(jìn)行了歸納總結(jié)。 表6-1 商業(yè)需求中可能的限制因素 因素分類 因素 對架構(gòu)的影響 經(jīng)濟(jì)因素 成本收益 預(yù)算多少會(huì)影響架構(gòu)師對技術(shù)的選擇 可重用性、可維護(hù)性、可移植性 …… 上市時(shí)間 重用程度、技術(shù)選型 通過采購模塊或平臺(tái)減少開發(fā)工作量 …… 客戶群 多國語言 架構(gòu)對多國語

20、言的支持 …… 移動(dòng)與便攜 支持哪些協(xié)議、哪些客戶端 是否按產(chǎn)品線進(jìn)行規(guī)劃 可移植性 …… 企業(yè)現(xiàn)狀 遺留系統(tǒng)的集成 互操作性 …… 企業(yè)人員和部門分布 分布式系統(tǒng)架構(gòu) 可維護(hù)性、安全性 …… 未來發(fā)展 期望的系統(tǒng)生存期 可伸縮性、可擴(kuò)展性、可移植性 …… 續(xù)表 因素分類 因素 對架構(gòu)的影響 階段性計(jì)劃 可重用性 可伸縮性、可擴(kuò)展性、可移植性 …… 其他因素 法律法規(guī) 可擴(kuò)展性 可修改性、可維護(hù)性 …… 競爭對手 技術(shù)選擇 易用性 …… 6.5 如何確定對軟件架構(gòu)關(guān)鍵的需求 圖6-6展示了確定對軟件架構(gòu)關(guān)鍵需求的步驟

21、，下面我們將一一討論。 圖6-6 確定對軟件架構(gòu)關(guān)鍵需求的步驟 6.5.1 全面整理需求 軟件架構(gòu)師為了確定關(guān)鍵需求，他需要全面整理需求，從而對需求建立通盤認(rèn)識(shí)。為此，軟件架構(gòu)師可能需要： 研究《愿景和范圍文檔》 研究《軟件需求規(guī)格說明書》 參加需求討論會(huì) 詢問客戶、用戶、領(lǐng)域?qū)＜摇⑾到y(tǒng)分析員 大多數(shù)情況下需求文檔未必有軟件架構(gòu)師需要的所有信息，例如易擴(kuò)展性、易測試性等開發(fā)期質(zhì)量屬性往往是《軟件需求規(guī)格說明書》相對薄弱的環(huán)節(jié)，所以軟件架構(gòu)師必須通過通盤理解需求，將缺失的、隱含的需求找出來。 如果條件允許，軟件架構(gòu)師應(yīng)該多參與需求活動(dòng)，這樣更有利于把握需求的輕重緩急。 6

22、.5.2 分析約束性需求 對約束性需求進(jìn)行分析非常有必要，因?yàn)楹芏嗉s束之中“藏”著一些隱含的需求，我們必須將它們找出來。 總體而言，約束性需求可能通過三種途徑影響設(shè)計(jì)（如圖6-7所示）。 圖6-7 約束性需求影響設(shè)計(jì)的三種途徑 直接制約設(shè)計(jì)決策。例如，“系統(tǒng)運(yùn)行于Linux平臺(tái)之上”作為一條約束，架構(gòu)師直接遵守即可； 轉(zhuǎn)化為功能需求。例如，“本銀行系統(tǒng)必須嚴(yán)格執(zhí)行人行統(tǒng)一規(guī)定的利率”是一條約束，但分析后發(fā)現(xiàn)，正是它引出了一條功能需求：即必須提供調(diào)整利率設(shè)置的實(shí)用功能； 轉(zhuǎn)化為質(zhì)量屬性需求。例如，有經(jīng)驗(yàn)的系統(tǒng)分析員發(fā)現(xiàn)了一條重要約束：要開發(fā)的軟件系統(tǒng)的預(yù)期用戶計(jì)算機(jī)水平普遍不高。

23、由此，未來的軟件系統(tǒng)必須具有很高的易用性（否則不會(huì)用）和魯棒性（否則可能把系統(tǒng)搞癱瘓了）就是非常必要的啦。 6.5.3 確定關(guān)鍵功能需求 如何確定關(guān)鍵功能需求？ 對此，Per Kroll和Philippe Kruchten在《Rational統(tǒng)一過程實(shí)踐者指南》中所論述的相當(dāng)令人信服（或許讀者需要一點(diǎn)RUP知識(shí)基礎(chǔ)）： 在初始階段，應(yīng)該確定出一些（大概占總數(shù)的20%至30%）對系統(tǒng)起關(guān)鍵作用的用例。這些用例通常對創(chuàng)建架構(gòu)具有重要影響。 A. 作為應(yīng)用程序的核心或?qū)崿F(xiàn)了系統(tǒng)的主要接口的功能，因此，對系統(tǒng)架構(gòu)有很重要的影響。通常系統(tǒng)架構(gòu)師通過分析冗余的管理策略、資源互斥風(fēng)險(xiǎn)、性能風(fēng)險(xiǎn)和數(shù)

24、據(jù)安全風(fēng)險(xiǎn)等來識(shí)別出哪些用例是最重要的。例如，在銷售系統(tǒng)中，從信用卡劃賬和支付是最主要的用例，因?yàn)樗桥c信用卡確認(rèn)系統(tǒng)的接口，它的負(fù)載和性能特性也很重要。 B. 必須被實(shí)現(xiàn)的功能。這些功能反映了系統(tǒng)的本質(zhì)，如果這些功能不能實(shí)現(xiàn)，那么開發(fā)出的應(yīng)用程序就沒有價(jià)值了。通常領(lǐng)域?qū)＜液拖嚓P(guān)方面的專家知道用戶最需要哪些功能（主要行為、數(shù)據(jù)處理的峰值和關(guān)鍵的控制操作等）。比如，如果沒有接受訂單的功能，就不能實(shí)現(xiàn)一個(gè)訂單發(fā)布系統(tǒng)。 C. 覆蓋了系統(tǒng)架構(gòu)的一些方面，但沒有被其他重要的用例覆蓋到的功能。要確保解決所有主要技術(shù)風(fēng)險(xiǎn)，就必須全面了解系統(tǒng)的每個(gè)方面。否則，即使架構(gòu)中的某個(gè)方面看起來沒有重大風(fēng)險(xiǎn)，但是

25、在設(shè)計(jì)、實(shí)現(xiàn)和測試時(shí)就很有可能發(fā)現(xiàn)這個(gè)部分中潛伏著巨大的技術(shù)風(fēng)險(xiǎn)。 讀者還要識(shí)別用戶需求中的一些難于實(shí)現(xiàn)的、未知的或者存在風(fēng)險(xiǎn)的元素（也許包括一些非功能性的元素），并且要找到一些用例（或者用例的一部分）來說明當(dāng)前遇到的困難以及解決方案的風(fēng)險(xiǎn)。在這個(gè)過程中，通常會(huì)有一些技術(shù)性風(fēng)險(xiǎn)轉(zhuǎn)移到系統(tǒng)架構(gòu)的基礎(chǔ)部分中。例如，如果系統(tǒng)對時(shí)間響應(yīng)特性或負(fù)載特性有特殊的要求，就要識(shí)別出一個(gè)用例（或者用例的一個(gè)事件流）來說明這個(gè)需求，同時(shí)還要表現(xiàn)出對特性的要求。還有其他一些例子，比如錯(cuò)誤恢復(fù)策略和系統(tǒng)初始化策略等。 最后，還要識(shí)別出這樣的一些用例：它們既不會(huì)對系統(tǒng)架構(gòu)產(chǎn)生重要影響也沒有技術(shù)風(fēng)險(xiǎn)，但是它們描述了尚未涉及到的系統(tǒng)功能。這樣，在細(xì)化階段結(jié)束時(shí)，才能創(chuàng)建出體現(xiàn)系統(tǒng)要領(lǐng)的整體架構(gòu)。例如，要確保每個(gè)主要的“業(yè)務(wù)實(shí)體”都至少與一個(gè)核心用例交互。 6.5.4 確定關(guān)鍵質(zhì)量屬性需求 為了確定對架構(gòu)設(shè)計(jì)關(guān)鍵的質(zhì)量屬性需求，需要做如下三方面的工作： 考慮為了提高要開發(fā)的軟件系統(tǒng)受認(rèn)可的程度，應(yīng)著重提高哪些方面的質(zhì)量屬性要求 接下來，充分考慮這些質(zhì)量屬性的相互制約或相互促進(jìn)關(guān)系，以調(diào)整不同質(zhì)量屬性的要求標(biāo)準(zhǔn)——例如，你可能會(huì)決定高性能要求最最重要，而可擴(kuò)展性也比較重要； 同時(shí)，必須滿足各種約束性需求。