多幫項目實戰(zhàn)目錄第一章 項目團(tuán)隊 21.1 項目經(jīng)理 41.2 需求分析師 41.3 架構(gòu)設(shè)計師 41.4 開發(fā)工程師 51.5 測試工程師 51.6 質(zhì)量工程師 5第二章 需求描述 62.1 一句話總述 72.2 目標(biāo)用戶 72.3 功能需求 82.4 非功能需求 82.5 項目約束 9第三章 需求分析 93.1 角色特征 93.2 場景分析 103.3 業(yè)務(wù)流程分析 113.4 數(shù)據(jù)流分析 123.5 需求優(yōu)先級 143.6 用戶界面 15第四章 系統(tǒng)框架 184.1 基本框架 184.1 框架內(nèi)容 184.2 系統(tǒng)分層 204.3 框架選擇與演進(jìn) 204.4 關(guān)鍵技術(shù) 214.5 數(shù)據(jù)表設(shè)計 214.6 模塊分解 224.7 拆分原則 22第五章 常見模塊設(shè)計 235.1 異常設(shè)計 23第六章 迭代開發(fā) 26項目團(tuán)隊由于軟件本身的復(fù)雜性，現(xiàn)在開發(fā)軟件基本上都是以團(tuán)隊的方式來開發(fā)軟件。團(tuán)隊成員各司其職，在項目經(jīng)理的帶領(lǐng)下完成軟件的開發(fā)、測試和交付。什么是項目團(tuán)隊？簡單地說就是項目以怎樣的方式組建團(tuán)隊，軟件開發(fā)項目團(tuán)隊的基本團(tuán)隊模型如下：團(tuán)隊在項目經(jīng)理的帶領(lǐng)下，各角色之間協(xié)調(diào)工作，為項目的成功而努力！各角色的基本職責(zé)如下：項目經(jīng)理：整體協(xié)調(diào)項目，編制計劃及保證計劃執(zhí)行，推動項目成功。需求分析師：分析系統(tǒng)需求，保證系統(tǒng)需求既滿足客戶要求。架構(gòu)設(shè)計師：同時保證技術(shù)可行性；指導(dǎo)項目技術(shù)方案及系統(tǒng)架構(gòu)設(shè)計。程序員：細(xì)化系統(tǒng)設(shè)計，并編碼實現(xiàn)設(shè)計。測試工程師：測試系統(tǒng)，保證系統(tǒng)滿足需求。質(zhì)量工程師，保證開發(fā)過程按照既定的要求進(jìn)行，保證工作產(chǎn)品符合既定的規(guī)范。基本團(tuán)隊有兩大特點(diǎn)： 1.一個團(tuán)隊總有一個負(fù)責(zé)人，這個人就是項目經(jīng)理。 2.期望各專業(yè)角色協(xié)調(diào)工作，并能各自發(fā)揮所長，完成各自的項目任務(wù)。但實際情況會是這樣的嗎？ 項目經(jīng)理會埋怨手下能力不夠、不主動報告工作、不主動承擔(dān)責(zé)任。 項目組成員會埋怨項目經(jīng)理不夠強(qiáng)，只會叫他干活，不授權(quán)，更加不會傳授知識。實際項目團(tuán)隊中項目經(jīng)理身兼多職,很多項目大多沒有專職的系統(tǒng)分析師和軟件架構(gòu)師，項目經(jīng)理兼任需求分析與軟件設(shè)計的工作，有的還需要負(fù)責(zé)編碼的工作。項目經(jīng)理要做的事情太多了，往往沒有辦法專注項目管理，項目計劃相關(guān)的文檔能免則免，項目設(shè)計文檔能少則少，但是這樣很容易導(dǎo)致項目失敗。項目經(jīng)理項目經(jīng)理就是項目的主要負(fù)責(zé)人，項目能否按時按質(zhì)量交付的關(guān)鍵人物，能力要求很高。其主要職責(zé)如下：1．參與客戶溝通、項目需求調(diào)研分析并維持良好的客戶關(guān)系；2．負(fù)責(zé)制訂軟件開發(fā)項目的計劃，實施整個項目的管理；3．參與項目需求分析、關(guān)鍵技術(shù)、系統(tǒng)框架和核心模塊的設(shè)計及規(guī)劃；4．根據(jù)項目開發(fā)進(jìn)度進(jìn)行任務(wù)分配和協(xié)調(diào)；5．按照項目計劃，保質(zhì)完成項目編碼、文檔及測試工作；6.確保項目質(zhì)量，滿足客戶的需求；需求分析師需求分析師就是負(fù)責(zé)需求的分析和澄清，保證做出來的是客戶想要的。能力懂技術(shù)，懂行業(yè)知識，溝通能力強(qiáng)。1．協(xié)助需求分析師進(jìn)行需求調(diào)研并維持良好的客戶關(guān)系；2．分析、解析《用戶需求說明書》，將系統(tǒng)需求整理成《軟件需求規(guī)格說明書》；3．負(fù)責(zé)解決《軟件需求規(guī)格說明書》被評審后發(fā)現(xiàn)的問題；4．協(xié)助架構(gòu)設(shè)計師進(jìn)行架構(gòu)設(shè)計，并協(xié)助其完成《系統(tǒng)架構(gòu)說明書》。架構(gòu)設(shè)計師系統(tǒng)架構(gòu)師是軟件項目的總體設(shè)計師，是產(chǎn)品的開發(fā)與集成、技術(shù)體系的構(gòu)建者。系統(tǒng)架構(gòu)師是在技術(shù)上對所有重要事情做出決定的人。1.負(fù)責(zé)軟件整體架構(gòu)和非功能性需求。比如性能、可靠性、可測試性等。2.協(xié)助需求分析師完成《用戶需求說明書》、《需求變更說明書》。3.確認(rèn)開發(fā)團(tuán)隊所提出的設(shè)計，并協(xié)助其完成《數(shù)據(jù)庫設(shè)計說明書》。4．對整個軟件架構(gòu)、關(guān)鍵構(gòu)件、接口的設(shè)計；5．負(fù)責(zé)重點(diǎn)代碼檢查；解決關(guān)鍵技術(shù)問題、技術(shù)培訓(xùn)；6．支持軟件測試、集成和交付；開發(fā)工程師1．參與客戶溝通、項目需求調(diào)研分析；2．參與項目需求分析,研究項目技術(shù)細(xì)節(jié)，進(jìn)行模塊的詳細(xì)設(shè)計；3．根據(jù)公司要求規(guī)范，編寫相應(yīng)的技術(shù)文檔；編制項目文檔；4．開發(fā)相應(yīng)的軟件模塊；根據(jù)需要及時修改、完善軟件；5．根據(jù)任務(wù)分解完成軟件編碼工作，配合測試工程師進(jìn)行軟件測試工作； 測試工程師主要職責(zé)確保軟件可用滿足用戶的需求，核心思想要站在客戶的角度測試軟件。1.搭建軟件測試環(huán)境。2.根據(jù)需求做測試設(shè)計和寫測試用例。3.執(zhí)行測試用例。4.準(zhǔn)確定位問題，并提交BUG單。5.跟蹤問題修改情況，推動問題及時合理地解決。6.做自動化測試，編寫腳本，執(zhí)行，分析，輸出報告。7.做性能測試，編寫腳本，執(zhí)行，分析，調(diào)優(yōu)，輸出報告。質(zhì)量工程師質(zhì)量保證工程師，保證開發(fā)過程按照既定的要求進(jìn)行，保證工作產(chǎn)品符合既定的規(guī)范。以獨(dú)立審查的方式監(jiān)控軟件生產(chǎn)任務(wù)的執(zhí)行，用過程質(zhì)量確保產(chǎn)品質(zhì)量。1.制定項目質(zhì)量保證計劃：在項目開發(fā)的各個階段具體什么措施確保過程的質(zhì)量。2.進(jìn)行項目審查，內(nèi)容包括：需求說明書、項目開發(fā)計劃、測試計劃、測試報告。3.進(jìn)行項目審計，識別開發(fā)中與質(zhì)量保證計劃中規(guī)定的標(biāo)準(zhǔn)和過程不相符時，影響到項目的及時高質(zhì)量完成時，要及時召開項目審計會議。4.進(jìn)行系統(tǒng)測試，確保軟件產(chǎn)品符合質(zhì)量要求，滿足客戶需求。5.進(jìn)行錯誤預(yù)防，提供歷史和當(dāng)前數(shù)據(jù)，讓團(tuán)隊了解項目所處的狀態(tài)和存在的弱點(diǎn)。需求描述 先看看“需求的故事”。其中的主要問題： 1.客戶也沒有完全表達(dá)清楚自己想要的。 2.項目經(jīng)理對客戶的需求沒有完全理解，存在偏差。 3.項目經(jīng)理和分析師在澄清過程中也存在偏差。那么如何把需求描述清楚，傳遞清楚，就需要一定的技能和規(guī)范。一句話總述描述方法：什么樣的人在什么樣的情況下按照什么樣的流程做什么樣的事。說明：1.“什么樣的人”： 表示角色。2.“什么樣的情況”： 表示場景。3.“按照什么樣的流程”：表示流程。4.“做什么樣的事”： 表示功能。如果客戶的需求能按照這種模式來描述自己的需求，那么這樣的需求就比較清楚。客戶需求描述： 本項目需要建立一個題庫項目：包含題目的錄入（并且包含題目的分析和答案），題目的審核，試卷的生成（按照題目的知識范圍（java，sql，框架，項目，題目的難度，初級，中級，高級），題目的類型（選擇題，回答題，編程題）），答題（不會的反復(fù)答題，直到把題目都答對了，才能再次生成新的試卷，初級做3套，才能做中級，中級做三套才能做高級）。分析答題人員的技能，給出建議。用戶或者管理員發(fā)布題目，用戶生成試卷，用戶解答試卷，系統(tǒng)自動判題，用戶通過系統(tǒng)分析自己的技能水平。用戶使用此系統(tǒng)提高自己的技能。并發(fā)限制100人,同時可以容納300人。目標(biāo)用戶這個項目誰是最終的用戶？列出主要用戶。1、列出主要用戶 以角色的方式列舉出來：例如：●

患者、醫(yī)生

護(hù)士?！?/p>

家長、老師、學(xué)生?！?/p>

乘客、飛行員、空姐。也可以是其他的角度考慮：●

當(dāng)?shù)乜蛻?、外地游客?/p>

購物者，瀏覽者當(dāng)前項目的主要用戶：即將畢業(yè)的大學(xué)生，提供本系統(tǒng)能提升自己的技能進(jìn)而就好業(yè)。功能需求把項目中的功能點(diǎn)描述出來：（1）用戶管理：用戶注冊、用戶登錄。（2）題目管理：增加、審核、發(fā)布、去重。（3）類型管理：增加、啟用是否。（4）試卷管理：生成、解答，分析。（5）分析管理：用戶技能能力趨勢，用戶技能建議。（6）用戶業(yè)務(wù)管理：試卷（歷史試卷，未答完(提交)的試卷，刪除未答完）題目（審核通過的題目，未審核通過的題目，刪除未通過的）技能分析：從java、SQL、框架，項目維度給出建議。非功能需求非功能需求一般是指：可靠性、易用性、效率、維護(hù)性等?？煽啃跃唧w包括：?成熟性：軟件故障引起失效的頻度。 ?容錯性：軟件出現(xiàn)故障并維持在規(guī)定的性能水平的能力。 ?易恢復(fù)性：問題發(fā)生后重建其性能水平并恢復(fù)受影響數(shù)據(jù)的能力。易用性具體包括：?易理解性：用戶為認(rèn)知邏輯概念所花的努力的程度。?易學(xué)習(xí)性：用戶為學(xué)習(xí)軟件應(yīng)用所花的努力的程度。?易操作性：用戶為操作使用軟件所花的努力的程度。這類非功能需求是與UI設(shè)計有著直接關(guān)系，可歸納為界面友好性;性能具體包括：?時間相關(guān)：軟件執(zhí)行功能時的響應(yīng)和處理的時間和吞吐量。?資源相關(guān)：軟件執(zhí)行其功能時所使用的資源數(shù)量及其使用時間。維護(hù)性具體包括：?易分析性：診斷缺陷或者失效原因及為判定待修改的部分所需的努力。?易改變性：在進(jìn)行修改排除錯誤或者適應(yīng)環(huán)境變化所需的努力。?穩(wěn)定性：在修改所造成的未預(yù)料結(jié)果的風(fēng)險所需的努力。?易測試性：在確認(rèn)已修改軟件所需的努力。非功能需求每個軟件都具備的，做好非功能需求成本很高，對架構(gòu)師、開發(fā)人員要求也很高。項目約束一般情況下項目的需求很越來越多，主要是客戶不斷在改需求，也可能是設(shè)計人員自己想當(dāng)然的增加需求，可能會導(dǎo)致在既定的人員、時間、成本下不能完成項交付，導(dǎo)致項目失敗。項目的約束就是要建立項目的范圍和邊界，這里主要是指哪些需求可以不做，或者用戶變更需求的內(nèi)容或者次數(shù)。需求分析

一切圍繞著用戶，以用戶為中心，了解用戶的需求，采集用戶的特征信息，并傾聽他們的想法或與他們需求的和使用方式內(nèi)容相關(guān)問題。角色特征 列出每角色的關(guān)鍵特征：應(yīng)包含以下方面： 經(jīng)驗和專業(yè)知識、價值觀、技術(shù)水平、用戶的崗位或級別、人口信息（年齡等）經(jīng)驗和專業(yè)知識：考慮用戶在知識領(lǐng)域和網(wǎng)站操作經(jīng)驗和專業(yè)知識。 例如：對于電子商務(wù)（某寶）網(wǎng)站來說：經(jīng)常購買的人： 可能對交易網(wǎng)站非常熟悉，僅僅滿足能夠順利完成交易還不是最終的目的，客戶想 找到同比商品最廉價、信用最高的商品。偶爾購買的人： 可能對交易網(wǎng)站不是很熟悉，僅僅想滿足如何能夠快速購買所需商品。技術(shù)水平 會快速網(wǎng)絡(luò)搜索？ 對常用軟件很熟悉? 電腦、互聯(lián)網(wǎng)、論壇、微博都很熟悉？用戶的崗位或級別： 普通員工？做具體的事情。 項目經(jīng)理？管理項目進(jìn)度和質(zhì)量。 中層主管？項目的價值。 高層主要？項目的投入產(chǎn)出。人口信息（年齡等） 年齡可能對你的軟件有所影響。如果是特定年齡的話，如青少年，那么年齡影響設(shè)計風(fēng)格和寫作風(fēng)格。如果是年輕女性、老人，對軟件的設(shè)計有很大的影響（主要是易用性）。場景分析場景描述，場景主要包括4種主要的類型：正常的使用場景，備選的用例場景，異常的用例場景，假定推測可能的場景。用場景法來分析需求是指模擬特定場景發(fā)生的事情，通過事件來觸發(fā)某個動作的發(fā)生,預(yù)估事件的最終結(jié)果,從而用來分析需求。我們通常以正常的使用場景分析開始，然后再著手其他的場景分析?？磦€具體的例子：假定我們有個電商項目，項目中有個支付模塊：需求描述是：方便用戶網(wǎng)上支付。那么就要考慮各種支付方式，例如：支付寶，微信，銀行App等等，現(xiàn)在的每種支付方式就是一種場景，就需要分析是否支持每種場景。正常的推薦的支付方式是哪種?備選的支付方式是什么？出現(xiàn)問題后怎么解決？還有其他什么可能？把這些都列舉出來，逐個跟用戶澄清，給用戶推薦最實用的的方式。業(yè)務(wù)流程分析業(yè)務(wù)是指企業(yè)管理中必要且邏輯上相關(guān)的、為了完成某種管理功能的一系列相關(guān)的活動。在項目調(diào)研時,

通過了解組織結(jié)構(gòu)和業(yè)務(wù)功能,

我們對項目的主要業(yè)務(wù)有了一個大概的認(rèn)識。但由此我們得到的對業(yè)務(wù)的認(rèn)識是靜態(tài)的,

是由組織部門映射到業(yè)務(wù)的。而實際的業(yè)務(wù)是流動的,

我們稱之為業(yè)務(wù)流程。1.先用文字描述一個用戶在項目中的實際的操作流程：a.用戶小明進(jìn)入項目主頁，先進(jìn)行注冊，注冊成功后進(jìn)入登錄業(yè)務(wù)，登錄成功后生成試卷，再解答試卷，再分析自己的技能如何。b.小明遇到了好的題目，登錄后直接把題目增加到題庫，之后等待系統(tǒng)審核，審核通過后，就可能就可以生成試卷。c.小明可以管理自己做過的試卷（刪除），也可以管理自己增加的題目（更新，但不能刪除）。2.畫成業(yè)務(wù)流程圖：visio：業(yè)務(wù)流程圖是一本用圖形方式來反映實際業(yè)務(wù)處理過程的“流水帳”。繪制出這本流水帳對于開發(fā)者理順和優(yōu)化業(yè)務(wù)過程是很有幫助的。業(yè)務(wù)流程圖的符號簡單明了,

易于閱讀和理解業(yè)務(wù)流程。繪制流程圖的目的是為了分析業(yè)務(wù)流程,

在對現(xiàn)有業(yè)務(wù)流程進(jìn)行分析的基礎(chǔ)上進(jìn)行業(yè)務(wù)流程重組,

產(chǎn)生新的更為合理的業(yè)務(wù)流程。通過除去不必要的、多余的業(yè)務(wù)環(huán)節(jié);

合并重復(fù)的環(huán)節(jié);增補(bǔ)缺少的必須的環(huán)節(jié);

確定計算機(jī)系統(tǒng)要處理的環(huán)節(jié)等重要步驟,

在繪制流程圖的過程中可以發(fā)現(xiàn)問題,

分析不足,

改進(jìn)業(yè)務(wù)處理過程。業(yè)務(wù)流程圖就是用一些規(guī)定的符號及連線來表示某個具體務(wù)處理過程。業(yè)務(wù)流程圖的繪制是根據(jù)系統(tǒng)詳細(xì)調(diào)查過程中所得的資料,

按業(yè)務(wù)實際處理過程,

用規(guī)定的符號將它們繪制在同一張圖上。它的繪制無嚴(yán)格的規(guī)則,

只需簡明扼要地如實反映實際業(yè)務(wù)過程。在繪制過程中一般也遵循“自頂向下”的原則。數(shù)據(jù)流分析數(shù)據(jù)流程圖是對業(yè)務(wù)流程的進(jìn)一步抽象與概括。抽象性表現(xiàn)在它完全舍去了具體的物質(zhì),

只剩下數(shù)據(jù)的流動、加工處理和存儲;

概括性表現(xiàn)在它可以把各種不同業(yè)務(wù)處理過程聯(lián)系起來,形成一個整體。數(shù)據(jù)流程圖主要是對信息流的描述。

數(shù)據(jù)流程圖還要配合數(shù)據(jù)字典的說明,

對系統(tǒng)的邏輯模型進(jìn)行完整和詳細(xì)的描述。數(shù)據(jù)流程分析主要包括對信息的流動、傳遞、處理、存儲等的分析。數(shù)據(jù)流程分析的目的就是要發(fā)現(xiàn)和解決數(shù)據(jù)流通中的問題,

這些問題有:

數(shù)據(jù)流程不暢,

前后數(shù)據(jù)不匹配,

數(shù)據(jù)處理過程不合理等。通過對這些問題的解決形成一個通暢的數(shù)據(jù)流程作為今后新系統(tǒng)的數(shù)據(jù)流程。數(shù)據(jù)流程圖比起業(yè)務(wù)流程圖更為抽象,

它舍棄了業(yè)務(wù)流程圖中的一些物理實體,

更接近于信息系統(tǒng)的邏輯模型。對于較簡單的業(yè)務(wù),

我們可以省略其業(yè)務(wù)流程圖直接繪制數(shù)據(jù)流程圖。數(shù)據(jù)流程圖的繪制方法較為復(fù)雜,

它是按照“自頂向下,

逐層求精”的方法進(jìn)行的,

也就是將整個系統(tǒng)當(dāng)成一個處理功能,畫出它和周圍實體的數(shù)據(jù)聯(lián)系過程,

即一個粗略的數(shù)據(jù)流程圖(

頂層數(shù)據(jù)流程圖),然后逐層向下分析,

直到把系統(tǒng)分解為詳細(xì)的低層次的數(shù)據(jù)流程圖。業(yè)務(wù)流程圖和數(shù)據(jù)流程圖的聯(lián)系1.

業(yè)務(wù)流程圖和數(shù)據(jù)流程圖都是從流程的角度動態(tài)地去考察分析對象,

都是用圖形符號抽象地表示調(diào)查結(jié)果。2.

數(shù)據(jù)和業(yè)務(wù)的聯(lián)系具體表現(xiàn)在:

數(shù)據(jù)流是伴隨著業(yè)務(wù)過程而產(chǎn)生的,

它是業(yè)務(wù)過程的衍生物;數(shù)據(jù)資料基本上也是按組織結(jié)構(gòu)或業(yè)務(wù)過程收集的;

在數(shù)據(jù)匯總時,

我們也是以業(yè)務(wù)流程為單位,將同一業(yè)務(wù)的不同處理步驟中的數(shù)據(jù)加以集中;

數(shù)據(jù)流程圖的繪制遵照業(yè)務(wù)處理的全過程。3.

數(shù)據(jù)流程圖和業(yè)務(wù)流程圖存在一定的對應(yīng)關(guān)系。由業(yè)務(wù)流程圖可以導(dǎo)出相應(yīng)的數(shù)據(jù)流程圖。有兩種思路:

一種是先按業(yè)務(wù)流程圖理出的業(yè)務(wù)流程順序,

然后將相應(yīng)調(diào)查過程中所掌握的數(shù)據(jù)、表單分離出來,

接下來考查數(shù)據(jù)的流向,

加工處理過程和存儲,

把它們串起來就繪制成一完整的數(shù)據(jù)流程圖;

另一種是從業(yè)務(wù)流程中分離出處理過程,

再考查每一個處理過程的輸入數(shù)據(jù)與輸出數(shù)據(jù),

將業(yè)務(wù)過程中所有的處理過程的輸入、輸出數(shù)據(jù)流進(jìn)行有機(jī)的集成就形成了一個完整的數(shù)據(jù)流程圖。需求優(yōu)先級1、首先明確自己項目的現(xiàn)階段的主要目標(biāo)是什么？一個產(chǎn)品在每個階段的重點(diǎn)是不同的，提升用戶體驗、用戶數(shù)、提升轉(zhuǎn)化付費(fèi)率……明確了這個目標(biāo)，然后再看你收到的那些需求，評估對每一個現(xiàn)階段目標(biāo)的貢獻(xiàn)程度。2、判斷功能之間的依賴和對用戶的影響只有把注冊功能做了，用戶才能登陸，才能做具體的業(yè)務(wù)。所以注冊、登陸需要先比具體的業(yè)務(wù)先實現(xiàn)。有些功能對用戶非常重要，例如當(dāng)一個網(wǎng)站數(shù)據(jù)量很大，找個信息不好找，那么站內(nèi)搜索，或者智能導(dǎo)航都得優(yōu)先先做，才能方便用戶使用。3、評估技術(shù)實現(xiàn)難度和成本所有的需求，最后都要設(shè)計成為功能，每個功能的技術(shù)實力不同，千萬不要想當(dāng)然覺得都可以實現(xiàn)的，有時候真的很難。這個功能咱們能不能實現(xiàn)？能實現(xiàn)的話，需要多少人多長時間？有沒有其他實現(xiàn)的建議或者方案？這些都需要考慮的。綜合以上因素就可以對需求進(jìn)行排序。輸出一個表格化的排序結(jié)果。用戶界面數(shù)據(jù)流圖一端是頁面，一端是數(shù)據(jù)實體，那么下來就需要考慮頁面的設(shè)計。1.根據(jù)業(yè)務(wù)特征，先在網(wǎng)上找類似的網(wǎng)頁，先學(xué)習(xí)他們的設(shè)計出來的頁面。2.分析他們各自的特點(diǎn)，思考他們?yōu)槭裁催@么設(shè)計，對用戶有什么幫助。3.先畫草圖跟用戶進(jìn)行澄清，草圖主要是布局圖，其中的元素基本上都是示意。4.跟用戶確認(rèn)差不多了，來下確認(rèn)網(wǎng)站風(fēng)格，就是CSS。5.風(fēng)格確認(rèn)之后，提供各種js動態(tài)效果，我們推薦的某些具體的效果。6.然后在用Hbuilder進(jìn)行開發(fā)。注意：UI的設(shè)計其實很難的，要考慮因素特別多，一般大的項目都有專業(yè)的UI設(shè)計師。系統(tǒng)框架基本框架框架是軟件的主體，它不負(fù)責(zé)任何業(yè)務(wù)邏輯部分的內(nèi)容，但它決定了整個軟件的整體結(jié)構(gòu)?？蚣艿闹饕氊?zé)是維護(hù)軟件系統(tǒng)架構(gòu)，并將構(gòu)件組織起來，維護(hù)構(gòu)件之間的關(guān)系，控制構(gòu)件的創(chuàng)建、清除與調(diào)用。構(gòu)件封裝了所有的業(yè)務(wù)邏輯，而框架則為構(gòu)件運(yùn)行提供了活動環(huán)境，另所有的構(gòu)件形成一個有機(jī)的整體。目前名氣最大的框架結(jié)構(gòu)就是MVC。MVC全名是ModelViewController，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設(shè)計典范，用一種業(yè)務(wù)邏輯、數(shù)據(jù)、界面顯示分離的方法組織代碼，將業(yè)務(wù)邏輯聚集到一個構(gòu)件里面，在改進(jìn)和個性化定制界面及用戶交互的同時，不需要重新編寫業(yè)務(wù)邏輯。MVC分層有助于管理復(fù)雜的應(yīng)用程序，因為您可以在一個時間內(nèi)專門關(guān)注一個方面。例如，您可以在不依賴業(yè)務(wù)邏輯的情況下專注于視圖設(shè)計。同時也讓應(yīng)用程序的測試更加容易。MVC分層同時也簡化了分組開發(fā)。不同的開發(fā)人員可同時開發(fā)視圖、控制器邏輯和業(yè)務(wù)邏輯?？蚣軆?nèi)容MVC是一個框架模式，它強(qiáng)制性的使應(yīng)用程序的輸入、處理和輸出分開。使用MVC應(yīng)用程序被分成三個核心部件：模型、視圖、控制器。它們各自處理自己的任務(wù)。最典型的MVC就是JSP

servlet

+

javabean的模式。視圖視圖是用戶看到并與之交互的界面。對老式的Web應(yīng)用程序來說，視圖就是由HTML元素組成的界面，在新式的Web應(yīng)用程序中，HTML依舊在視圖中扮演著重要的角色，但一些新的技術(shù)已層出不窮，例如jsp.MVC好處是它能為應(yīng)用程序處理很多不同的視圖。在視圖中其實沒有真正的處理發(fā)生，作為視圖來講，它只是作為一種輸出數(shù)據(jù)并允許用戶操縱的方式。模型模型表示企業(yè)數(shù)據(jù)和業(yè)務(wù)規(guī)則。在MVC的三個部件中，被模型返回的數(shù)據(jù)是中立的，就是說模型與數(shù)據(jù)格式無關(guān)，這樣一個模型能為多個視圖提供數(shù)據(jù)，由于應(yīng)用于模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復(fù)性?？刂破骺刂破鹘邮苡脩舻妮斎氩⒄{(diào)用模型和視圖去完成用戶的需求，所以當(dāng)單擊Web頁面中的超鏈接和發(fā)送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求并決定調(diào)用哪個模型構(gòu)件去處理請求，然后再確定用哪個視圖來顯示返回的數(shù)據(jù)?？蚣芎驮O(shè)計模式的區(qū)別大家很容易把框架模式和設(shè)計模式混淆，認(rèn)為MVC是一種設(shè)計模式。實際上它們完全是不同的概念。

框架、設(shè)計模式這兩個概念總?cè)菀妆换煜?，其實它們之間還是有區(qū)別的?？蚣芡ǔＪ谴a重用，而設(shè)計模式是設(shè)計重用，架構(gòu)則介于兩者之間，部分代碼重用，部分設(shè)計重用，有時分析也可重用。在軟件開發(fā)過程中有三種級別的重用：內(nèi)部重用，即在同一應(yīng)用中能公共使用的抽象塊;代碼重用，即將通用模塊組合成庫或工具集，以便在多個應(yīng)用和領(lǐng)域都能使用；應(yīng)用框架的重用，即為專用領(lǐng)域提供通用的或現(xiàn)成的基礎(chǔ)結(jié)構(gòu)，以獲得最高級別的重用性。框架與設(shè)計模式雖然相似，但卻有著根本的不同。設(shè)計模式是對在某種環(huán)境中反復(fù)出現(xiàn)的問題以及解決該問題的方案的描述，它比框架更抽象；框架可以用代碼表示，也能直接執(zhí)行或復(fù)用，而對模式而言只有實例才能用代碼表示;設(shè)計模式是比框架更小的元素，一個框架中往往含有一個或多個設(shè)計模式，框架總是針對某一特定應(yīng)用領(lǐng)域，但同一模式卻可適用于各種應(yīng)用?？梢哉f，框架是軟件，而設(shè)計模式是軟件的小實踐。系統(tǒng)分層一個項目一般都可以分為5層架構(gòu)：表現(xiàn)層、控制層、服務(wù)層、數(shù)據(jù)訪問層和數(shù)據(jù)庫五層架構(gòu)。表現(xiàn)層：就是web頁面（html,jsp）。一般只是顯示，不做業(yè)務(wù)處理，可以有簡單的邏輯，只能用EL和JSTL表達(dá)式來完成，強(qiáng)烈不建議在jsp中寫java代碼或者sql?？刂茖樱壕褪悄愕恼埱髲捻撁?zhèn)鞯胶笈_后具體控制他的由誰來處理。服務(wù)層：一般就是業(yè)務(wù)邏輯的處理，所有的具體的業(yè)務(wù)都是在這里處理。數(shù)據(jù)實體：一般用來存?zhèn)鬟f的數(shù)據(jù)，是POJO，但一般用xxxBean來表達(dá)。數(shù)據(jù)訪問層：數(shù)據(jù)庫中的數(shù)據(jù)到數(shù)據(jù)實體之間的相互映射。數(shù)據(jù)庫：提供數(shù)據(jù)的增刪改查。框架選擇與演進(jìn)使用Web開發(fā)框架，可以幫助開發(fā)者提高Web開發(fā)工作的質(zhì)量和效率，大大減少開發(fā)工作量。但是目前互聯(lián)網(wǎng)中充斥著各種各樣的Web開發(fā)框架，這些框架都可以為開發(fā)者的項目提供各種功能擴(kuò)展，如何選擇成為了棘手的問題。所有框架必須是免費(fèi)使用的，并且最好是開源的。此外，使用這些框架進(jìn)行開發(fā)時，無需使用專有IDE、應(yīng)用服務(wù)器或數(shù)據(jù)庫。在從如下方面對框架進(jìn)行評估：學(xué)習(xí)難度、針對簡單任務(wù)的開發(fā)效率、針對復(fù)雜、特殊任務(wù)的開發(fā)效率、依賴jar包的管理、代碼性能/安全優(yōu)化調(diào)整的能力、在企業(yè)市場中的認(rèn)同度、開發(fā)的復(fù)雜性進(jìn)行評估。目前企業(yè)對spring、spingmvc比較認(rèn)可。現(xiàn)在的mybatis、hibernate幾乎一樣，他們之間相互學(xué)習(xí)，基本上沒有太大的區(qū)別。目前企業(yè)內(nèi)部：新項目基本上都采用spring+springmvc和mybatis，但是我們不能一上來就是SSM框架，應(yīng)該從基本框架進(jìn)行演進(jìn)。學(xué)習(xí)順序：1.jsp+servlet+jdbc+mysql2.jsp+servlet+mybatis+mysql3.jsp+servlet+spring+jdbc+mysql4.jsp+servlet+spring+mybaits+mysql5.jsp+spring+springmvc+mybaits+mysql關(guān)鍵技術(shù)對于一些復(fù)雜的技術(shù)，要求很高的技術(shù)，必須先進(jìn)性技術(shù)驗證。寫個簡單的例子驗證在技術(shù)上是否可以實現(xiàn)。如果搞不定需要重新更換技術(shù)方案。千萬不要到了最后才說實現(xiàn)不了，那大家估計都得熬夜了。數(shù)據(jù)表設(shè)計梳理業(yè)務(wù)流程，根據(jù)業(yè)務(wù)流梳理數(shù)據(jù)流，在分析數(shù)據(jù)實體，找數(shù)據(jù)實體之間的關(guān)系；根據(jù)數(shù)據(jù)實體設(shè)計數(shù)據(jù)表，根據(jù)關(guān)系建立實體表之間的關(guān)系；考慮數(shù)據(jù)表設(shè)計三范式；建立主外鍵和索引，如果需要還可以考慮視圖。模塊分解拆分原則一般一個項目都需要拆分為多個模塊進(jìn)行開發(fā)，那如何拆分？要注意哪些問題？介紹幾個拆分的基本原則：1、業(yè)務(wù)優(yōu)先：每個項目天然會按業(yè)務(wù)功能分成多個模塊，每個模塊又包含許多業(yè)務(wù)相關(guān)的功能，在拆分時，我們就可以優(yōu)先考慮按照業(yè)務(wù)邊界進(jìn)行切割，切割完成后再針對每個模塊進(jìn)行拆解，循序漸進(jìn)，逐漸迭代深入，最終完成系統(tǒng)的拆解。2、循序漸進(jìn)：拆分過程中包含兩個非常重要的工作：拆分和聚合。二者缺一不可，并且二者是并行進(jìn)行的，一定要邊拆分邊聚合。每一步拆分完成都要保證項目的功能是完整的。3、兼顧技術(shù)：系統(tǒng)不能為了拆分而拆分，需要結(jié)合技術(shù)。拆分過程中需要堅持一個基本原則：高內(nèi)聚、低耦合。拆分的實際工作就是解耦。常見模塊設(shè)計異常設(shè)計一、異常處理的一般原則

1、能處理就早處理，拋出不去還不能處理的就想法消化掉或者轉(zhuǎn)換為RuntimeException處理。因為對于一個應(yīng)用系統(tǒng)來說，拋出大量異常是有問題的，應(yīng)該從程序開發(fā)角度盡可能的控制異常發(fā)生的可能。2、對于檢查異常，如果不能行之有效的處理，還不如轉(zhuǎn)換為RuntimeException拋出。這樣也讓上層的代碼有選擇的余地――可處理也可不處理。3、對于一個應(yīng)用系統(tǒng)來說，應(yīng)該有自己的一套異常處理框架，這樣當(dāng)異常發(fā)生時，也能得到統(tǒng)一的處理風(fēng)格，將優(yōu)雅的異常信息反饋給用戶。二、異常的轉(zhuǎn)化與異常鏈

1、異常轉(zhuǎn)化的原理

所謂的異常轉(zhuǎn)化就是將一種異常轉(zhuǎn)換另一種新的異常，也許這種新的異常更能準(zhǔn)確表達(dá)程序發(fā)生異常。

在Java中有個概念就是異常原因，異常原因?qū)е庐?dāng)前拋出異常的那個異常對象，幾乎所有帶異常原因的異常構(gòu)造方法都使用Throwable類型做參數(shù)，這也就為異常的轉(zhuǎn)化提供了直接的支持，因為任何形式的異常和錯誤都是Throwable的子類。比如將SQLException轉(zhuǎn)換為另外一個新的異常DAOException，可以這么寫：

先自定義一個異常DAOException：

publicclassDAOExceptionextendsRuntimeException{

//(省略了部分代碼)

publicDAOException(Stringmessage,Throwablecause){

super(message,cause);

}

}

比如有一個SQLException類型的異常對象e，要轉(zhuǎn)換為DAOException，可以這么寫：

DAOExceptiondaoEx=newDAOException(“SQL異常”,e);

異常轉(zhuǎn)化是針對所有繼承Throwable超類的類而言的，從編程的語法角度講，其子類之間都可以相互轉(zhuǎn)換。但是，從合理性和系統(tǒng)設(shè)計角度考慮，可將異常分為三類：Error、Exception、RuntimeException，筆者認(rèn)為，合理的轉(zhuǎn)化關(guān)系圖應(yīng)該如圖2：

為什么要這么做呢？異常的處理存在著一套哲學(xué)思想：對于一個應(yīng)用系統(tǒng)來說，系統(tǒng)所發(fā)生的任何異常或者錯誤對操作用戶來說都是系統(tǒng)"運(yùn)行時"異常，都是這個應(yīng)用系統(tǒng)內(nèi)部的異常。這也是異常轉(zhuǎn)化和應(yīng)用系統(tǒng)異?？蚣茉O(shè)計的指導(dǎo)原則。在系統(tǒng)中大量處理非檢查異常的負(fù)面影響很多，最重要的一個方面就是代碼可讀性降低，程序編寫復(fù)雜，異常處理的代碼也很蒼白無力。因此，很有必要將這些檢查異常Exception和錯誤Error轉(zhuǎn)換為RuntimeException異常，讓程序員根據(jù)情況來決定是否捕獲和處理所發(fā)生的異常。

圖中的三條線標(biāo)識轉(zhuǎn)換的方向，分三種情況：

①：Error到Exception：將錯誤轉(zhuǎn)換為異常，并繼續(xù)拋出。例如SpringWEB框架中，將org.springframework.web.servlet.DispatcherServlet的doDispatch()方法中，將捕獲的錯誤轉(zhuǎn)化為一個NestedServletException異常。這樣做的目的是為了最大限度挽回因錯誤發(fā)生帶來的負(fù)面影響。因為一個Error常常是很嚴(yán)重的錯誤，可能會引起系統(tǒng)掛起。

②：Exception到RuntimeException：將檢查異常轉(zhuǎn)換為RuntimeException可以讓程序代碼變得更優(yōu)雅，讓開發(fā)人員集中經(jīng)理設(shè)計更合理的程序代碼，反過來也增加了系統(tǒng)發(fā)生異常的可能性。

③：Error到RuntimeException：目的還是一樣的。把所有的異常和錯誤轉(zhuǎn)化為不檢查異常，這樣可以讓代碼更為簡潔，還有利于對錯誤和異常信息的統(tǒng)一處理。

1、異常鏈

異常鏈顧名思義就是將異常發(fā)生的原因一個傳一個串起來，即把底層的異常信息傳給上層，這樣逐層拋出。JavaAPI文檔中給出了一個簡單的模型：

try{

lowLevelOp();

}catch(LowLevelExceptionle){

throw(HighLevelException)

newHighLevelException().initCaus