軟件系統(tǒng)設(shè)計總體思路

1、.軟件 / 系統(tǒng)設(shè)計的總體思路一、概念軟件設(shè)計的本質(zhì)就是針對軟件的需求，建立模型， 通過將模型映射為軟件， 來解決實際問題。因此軟件設(shè)計需要解決的核心問題是建立合適的模型，使得能夠開發(fā)出滿足用戶需求的軟件產(chǎn)品，并具有以下特性：? 靈活性（ Flexibility）? 有效性（ Efficiency）? 可靠性（ Reliability）? 可理解性（ Understandability）? 維護(hù)性（ Maintainability）? 重用性（ Reuse-ability）? 適應(yīng)性（ Adaptability）? 可移植性（ Portability）? 可追蹤性（ Traceability）

2、? 互操作性（ Interoperability）因此，軟件設(shè)計并沒有一套放之四海而皆準(zhǔn)的方法和模板，需要我們的設(shè)計開發(fā)人員在軟件的設(shè)計開發(fā)過程中針對軟件項目的特點(diǎn)進(jìn)行溝通和協(xié)調(diào)，整理出對軟件項目團(tuán)隊的行之有效的方式， 進(jìn)行軟件的設(shè)計。并保障軟件設(shè)計文檔的一致性，完整性和可理解性。精選.我們經(jīng)常聽到這樣的話：? “設(shè)計文檔沒有用，是用來糊弄客戶和管理層的文檔”；? “用來寫設(shè)計文檔的時間，我的開發(fā)早就做完了”；? “項目緊張，沒有時間做設(shè)計”；這些言論，并不是正確的觀念， 根據(jù)軟件項目的實際情況，軟件開發(fā)設(shè)計團(tuán)隊可以約定設(shè)計文檔的詳細(xì)程度。 項目團(tuán)隊需要保障設(shè)計文檔的完整性和一致性，在項目進(jìn)度

3、緊張的情況下， 軟件設(shè)計文檔可以更初略一些；在項目時間充裕的情況下，相關(guān)文檔可以更為詳盡。 但是在項目開發(fā)過程中， 需要軟件設(shè)計開發(fā)團(tuán)隊對于設(shè)計文檔有共同的理解。二、設(shè)計文檔分類與使用通常來說，作為軟件項目，我們需要有這幾類文檔? 需求說明文檔? 功能設(shè)計文檔? 系統(tǒng)架構(gòu)說明書? 模塊概要設(shè)計文檔? 模塊詳細(xì)設(shè)計文檔就像我之前說到的，在某個軟件團(tuán)隊，對于以上的文檔的要求是可以完全不同的，在簡單項目中，可能所有類型的文檔放在一個文檔中進(jìn)行說明；在復(fù)雜項目中，每一類文檔可能都要寫幾個文檔；而在最極端的情況下， 可能每一類文檔都能裝精選.訂成幾冊。因此，在我們軟件設(shè)計和開發(fā)人員心目中需要明確的是：文

4、檔并不是我們進(jìn)行設(shè)計的目標(biāo)，也不是我們設(shè)計過程中額外的工作。軟件設(shè)計文檔是我們在軟件設(shè)計開發(fā)過程中形成的，用來在軟件設(shè)計開發(fā)團(tuán)隊內(nèi)部以及與各干系人之間進(jìn)行溝通的文檔，這些文檔記錄了軟件項目中的各種知識，方案的思路、以及各種決策意見。三、軟件設(shè)計開發(fā)過程下面我們就軟件設(shè)計開發(fā)過程中必須要完成的工作進(jìn)行梳理，而我們需要注意到，這些需要完成的工作， 在不同的開發(fā)流程模型的指導(dǎo)下可能有不同的時間要求，而我們需要關(guān)注的是在這個階段內(nèi)需要完成的工作，以及這個階段內(nèi)我們需要溝通的人員。1. 需求分析需求分析是我們進(jìn)行任何一個軟件項目設(shè)計開發(fā)過程中都必須要完成的工作。這個工作通常與客戶一起完成。在不同的項目中

5、，這個“客戶”可能來自真正的購買產(chǎn)品的用戶， 使用系統(tǒng)的用戶， 也有可能來自團(tuán)隊的某個人員，如產(chǎn)品經(jīng)理等。軟件設(shè)計開發(fā)團(tuán)隊的參與成員根據(jù)項目的不同規(guī)模，則參與的人員也有所不同。原則上，設(shè)計開發(fā)人員參與的時間點(diǎn)越早，對于需求的理解和把握會更好。這個階段，通常需要軟件架構(gòu)師參與其中。從資源優(yōu)化的角度來說， 開發(fā)人員不必參與需求分析，但需要理解需求。需求分析的結(jié)果通常我們需要使用需求說明文檔來描述，目前主流的需求描述方法包括：用戶例圖、用戶故事等方式。這些方式有所不同的側(cè)重，其核心思想就精選.是描述清楚用戶的使用場景。但無論采取何種方式， 進(jìn)行需求的描述， 需求說明需要明確以下幾點(diǎn)：? 所需要開發(fā)的

6、軟件系統(tǒng)邊界? 系統(tǒng)所有的相關(guān)及使用人員角色? 系統(tǒng)關(guān)鍵的使用場景? 系統(tǒng)規(guī)模、性能要求以及部署方式等非功能性需求2. 功能設(shè)計功能設(shè)計與需求分析差不多同時在開展，在很多軟件項目中， 對于功能設(shè)計不是特別重視。但對于某些軟件項目而言， 這是一個相當(dāng)重要的工作。對于主要是用戶界面的軟件項目來說， 功能設(shè)計可以看作是畫出原型界面，描述使用場景， 獲得用戶認(rèn)可的過程。 而對于沒有界面的軟件項目來說，則功能設(shè)計與需求分析的區(qū)分更為模糊。參與的人員與需求分析的參與人員類似，架構(gòu)師更側(cè)重于參與此類工作，并給與一些實現(xiàn)層面的判斷和取舍。功能設(shè)計需要明確的核心是：? 系統(tǒng)的行為3. 系統(tǒng)架構(gòu)設(shè)計系統(tǒng)架構(gòu)設(shè)計是

7、一個非常依賴于經(jīng)驗的設(shè)計過程。需要根據(jù)軟件項目的特定功能需求和非功能性需求進(jìn)行取舍，最終獲得一個滿足各方要求的系統(tǒng)架構(gòu)。系統(tǒng)架構(gòu)的不同，將很大程度上決定系統(tǒng)開發(fā)和維護(hù)是否能夠較為容易的適應(yīng)需求變化，以及適應(yīng)業(yè)務(wù)規(guī)模擴(kuò)張。精選.架構(gòu)設(shè)計工作中，用戶參與程度很低。軟件開發(fā)團(tuán)隊中的需求人員參與程度很低，但團(tuán)隊中的所有核心設(shè)計和開發(fā)人員都應(yīng)該參與其中，并達(dá)成一致意見。架構(gòu)設(shè)計的主要成果，是將系統(tǒng)的不同視圖予以呈現(xiàn)，并使之落實到開發(fā)中：? 系統(tǒng)開發(fā)視圖及技術(shù)路線選擇? 系統(tǒng)邏輯視圖? 系統(tǒng)部署視圖? 系統(tǒng)模塊視圖? 系統(tǒng)的領(lǐng)域模型在軟件開發(fā)過程中， 系統(tǒng)的架構(gòu)不是一成不變的， 隨著設(shè)計人員和開發(fā)人員對于

8、系統(tǒng)的理解不斷深入， 系統(tǒng)的架構(gòu)也會發(fā)生演化。在軟件項目中， 架構(gòu)設(shè)計是開發(fā)團(tuán)隊溝通的統(tǒng)一語言， 設(shè)計文檔必須要隨著系統(tǒng)的變化進(jìn)行更新，保障開發(fā)團(tuán)隊對于系統(tǒng)的理解和溝通的一致性。4. 模塊 / 子系統(tǒng)概要設(shè)計模塊 / 子系統(tǒng)的概要設(shè)計， 由架構(gòu)師參與， 核心設(shè)計和開發(fā)人員負(fù)責(zé)的方式進(jìn)行。在概要設(shè)計工作中， 我們需要在架構(gòu)確定的開發(fā)路線的指導(dǎo)下，完成模塊功能實現(xiàn)的關(guān)鍵設(shè)計工作。 在概要設(shè)計階段， 需要關(guān)注于模塊的核心功能和難點(diǎn)進(jìn)行設(shè)計。這個過程中更多推薦的采用UML 來進(jìn)行概要設(shè)計，需要進(jìn)行：? 模塊實現(xiàn)機(jī)制設(shè)計? 模塊接口設(shè)計? 關(guān)鍵類設(shè)計精選.? 畫出時序圖? 交互圖等。5. 模塊詳細(xì)設(shè)計在瀑布式開發(fā)模型中，模塊的詳細(xì)設(shè)計會要求比較嚴(yán)格， 將所有類進(jìn)行詳細(xì)設(shè)計。據(jù)我所知，除了一些對于系統(tǒng)健壯性要求非常嚴(yán)格的軟件項目，如國防項目， 金融項目還要求有詳細(xì)設(shè)計文檔之外。其他的項目大多采用其他方式來處理這樣的工作，如自動化測試等。綜上所述，軟件設(shè)計文檔作為軟件開發(fā)團(tuán)隊的溝通、理解、知識共享的手段，具有非常重要的意義。 而根據(jù)軟件團(tuán)隊的規(guī)模， 對于文檔上承載的信息詳細(xì)程度可以有