軟件工程分析與設計

1、軟件工程分析與設計軟件工程分析與設計選擇1.1問題解決和決策在現(xiàn)階段，介紹杜威在1910年首先闡述的一種解決問題的結構方法是很有益處的。約翰杜威確定的階段是：問題是什么？可供選擇的辦法由那些？那種辦法是最好的？你現(xiàn)在應該努力識別杜威的三個階段與軟件生命周期的相似之處。為了弄清第一階段的問題定義與我們的需求分析階段之間的相似之處，在前面我們已經(jīng)對生命周期介紹得足夠多了。事實上，許多組織使用詞匯‘問題’或‘項目定義’而不用‘需求分析’。后兩

2、個階段同樣的被認為相當于我們所提到的設計階段。最近（1960），西蒙在有關決策的文章中提出了相應的結構。西蒙教授對決策階段作以下分類：信息收集活動，設計活動以及選擇活動。單詞‘信息收集’在這里使用其軍事方面的意義，也就是，在外界環(huán)境中搜索做出決策所需的各種條件?！O計’與發(fā)明及開發(fā)行為可能的發(fā)展方向有關。挑選一個詳細的行動方案的活動稱為選擇。于是，我們的需求分析對應于信息收集活動。盡管軟件設計員不需要拼命尋找作決定所需的環(huán)境條件，但人們

3、通常會在軟件設計員的桌子上看到‘需求說明書’。但是，西蒙所用的單詞‘設計’與我們所用的不同。我們所用的‘設計’同時包括選擇的意義，而西蒙的‘設計’用來描述可能的解決方案的產(chǎn)生。有理由相信問題解決、決策、軟件分析和設計共享一個公共構架。主張前兩項活動實際上在效果上是相同的，而最后一項活動恰是這一現(xiàn)象的一個詳細實例是有一定道理的。因此，我們將堅持把軟件設計當成解決問題的活動，并這樣處理他。這表示我們必須在產(chǎn)生可能的解決方案和從中選擇一個最佳

4、方案兩方面投入一定的精力。人瞠目結舌。大型軟件的設計會造成類似的問題：如果想要選出最好的設計方案，理論上就需要審核與評估無數(shù)的選擇方案。我們說在理論上，因為如果我們計算評估一個方案需要多長時間，就會發(fā)現(xiàn)綜合評估所有的方案是不可能的。如果使用電子手段，而審閱和評估一種方案需要百萬分之一秒，那么增加50個數(shù)據(jù)需要多長時間來挑選最佳樹呢？這種詳細設計方案將用去2.17x1066世紀。事實上，除了一些沒什么價值的案例，這種設計方法是不可能實現(xiàn)的

5、。不過，世界上每天都有人在設計系統(tǒng)，其中的一些系統(tǒng)還相當好用。所以，我們現(xiàn)在必須考慮那些聰明的人是怎樣達到如此好的結果的。1.2.2制約通常，在選擇開始之前盡可能的進行取舍是相當有幫助的。約束恰恰是作這件事的。我們最初在審閱軟件生存周期的需求分析階段進行非功能性需求分析時遇到的約束問題。我們發(fā)現(xiàn)約束常常在用戶需求文檔中有所明確，也常常與硬件、軟件時間和金錢有關。因此，總而言之，將要在奧利維蒂公司M24上執(zhí)行的新軟件即使能排除所有其它的設

6、計方案也無法立即執(zhí)行。類似的，需要使用一個非功能性需求的標準輸入輸出軟件，用來刪除與約束矛盾的所有設計方案。時間和金錢同樣制約著設計。如果軟件必須在某一日期之前投入使用，那么那些復雜的、無法在最后期限之前完成的實際方案必須被拋棄。同樣，超過預算的設計方案也會被淘汰。盡管制約的應用可以嚴格的限制設計員選擇方案的數(shù)目，但是選擇方案的規(guī)模看上去仍然無法控制。所以在解決選擇方案問題時設計員仍然需要一些幫助。這些幫助來自啟發(fā)式的設計條件或者說是經(jīng)