軟件工程考試復(fù)習(xí)(參考).doc

一、考試題型及分值分布（1）單選題（20題，每題2分，共40分）（2）判斷題（10題，每題1分，共10分）（3）簡答題（6題，每題5分，共30分）（4）應(yīng)用題（1題，20分）二、復(fù)習(xí)范圍（1）軟件危機(jī)及產(chǎn)生的原因軟件危機(jī)指在計(jì)算機(jī)軟件的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題。這些問題絕不僅僅是不能正常運(yùn)行的軟件才具有的，實(shí)際上，幾乎所有軟件都不同程度地存在這些問題。-如何開發(fā)、如何維護(hù)軟件。產(chǎn)生的原因與軟件本身的特點(diǎn)有關(guān)非常復(fù)雜成本高風(fēng)險(xiǎn)大維護(hù)困難（2） 軟件工程是一種層次化技術(shù)，其主要包括哪些內(nèi)容？ 軟件工程是一種層次化的技術(shù)方法：提供了建造軟件在技術(shù)上需要“如何做”。涵蓋一系列的任務(wù)：需求分析、設(shè)計(jì)、編程、測試和維護(hù)。 工具：對過程和方法提供了自動(dòng)的或半自動(dòng)的支持。工具被集成起來 ，形成計(jì)算機(jī)輔助軟件工程(CASE) （3） 通用的軟件過程框架包括哪些活動(dòng)？溝通：包含了涉眾之間大量的交流和協(xié)作，還包括需求獲取以及其他相關(guān)活動(dòng)。策劃：指為后續(xù)的軟件工程工作制定計(jì)劃。它描述了需要執(zhí)行的技術(shù)任務(wù)、可能的風(fēng)險(xiǎn)、資源需求、工作產(chǎn)品和工作進(jìn)度計(jì)劃。建模：包括創(chuàng)建模型和設(shè)計(jì)兩方面。創(chuàng)建模型有助于客戶和開發(fā)人員更好地理解軟件需求，設(shè)計(jì)可以實(shí)現(xiàn)需求。構(gòu)建：包括編碼和測試。部署：軟件(全部或者完成的部分)交付到用戶，用戶對其進(jìn)行評測并給出反饋意見。典型的普適性活動(dòng)軟件項(xiàng)目跟蹤和控制：由項(xiàng)目組根據(jù)計(jì)劃來評估項(xiàng)目進(jìn)度，并采取必要的措施保證項(xiàng)目按計(jì)劃進(jìn)行風(fēng)險(xiǎn)管理：對可能影響項(xiàng)目成果或產(chǎn)品質(zhì)量的風(fēng)險(xiǎn)進(jìn)行評估。軟件質(zhì)量保證：確定和執(zhí)行用以保證軟件質(zhì)量的活動(dòng)。正式的技術(shù)復(fù)審：評估軟件工程產(chǎn)品，盡量在錯(cuò)誤傳播到下一個(gè)動(dòng)作或活動(dòng)之前發(fā)現(xiàn)并清除錯(cuò)誤。測量：定義和收集過程、項(xiàng)目和產(chǎn)品的度量，以幫助團(tuán)隊(duì)在發(fā)布軟件的時(shí)候滿足客戶要求。軟件配置管理：管理整個(gè)軟件過程中變更所帶來的影響?？蓮?fù)用管理：定義產(chǎn)品復(fù)用的標(biāo)準(zhǔn)(包括軟件構(gòu)件)，并且建立構(gòu)件復(fù)用機(jī)制。工作產(chǎn)品的準(zhǔn)備和產(chǎn)生：包括了創(chuàng)建產(chǎn)品所必需的活動(dòng)，如建模、文檔、日志、表格和列表等。（4） 各種軟件過程模型的特點(diǎn)及適用的場景？1） 瀑布模型特點(diǎn)：結(jié)構(gòu)化，有序；適用于傳統(tǒng)軟件工程領(lǐng)域的結(jié)構(gòu)化開發(fā)。2） 螺旋過程模型特點(diǎn)：它結(jié)合了原型的迭代性質(zhì)和瀑布模型的系統(tǒng)性和可控性，螺旋模型可應(yīng)用在計(jì)算機(jī)軟件的整個(gè)生命周期，螺旋模型是開發(fā)大型系統(tǒng)和軟件的理想方法，螺旋模型把原型開發(fā)作為降低風(fēng)險(xiǎn)的機(jī)制；適用于龐大、復(fù)雜并具有高風(fēng)險(xiǎn)的系統(tǒng)。3） 原型過程模型特點(diǎn)：原型模型采用逐步求精的方法完善原型，使得原型能夠“快速”開發(fā)；快速原型法是在需求不明確的情況下常用的一種方法。（5） UP的三大特點(diǎn)及其五個(gè)階段。1） a.用例驅(qū)動(dòng) b.以體系架構(gòu)為核心 c.迭代并且增量2) UP包括起始階段，細(xì)化階段，構(gòu)建階段，轉(zhuǎn)化階段，生產(chǎn)階段。 起始階段 ：包括用戶溝通和計(jì)劃活動(dòng)兩個(gè)方面，強(qiáng)調(diào)定義和細(xì)化用例，并將其作為主要模型。 細(xì)化階段 ：包括用戶溝通和建?；顒?dòng)，重點(diǎn)是創(chuàng)建分析和設(shè)計(jì)模型，強(qiáng)調(diào)類的定義和體系結(jié)構(gòu)的表示。 構(gòu)建階段:將設(shè)計(jì)轉(zhuǎn)化為實(shí)現(xiàn)，并進(jìn)行集成和測試。 移交階段 ：將產(chǎn)品發(fā)布給用戶進(jìn)行測試評價(jià)，并收集用戶的意見，之后再次進(jìn)行迭代修改產(chǎn)品使之完善。（6） 分析模型的建模目的是什么？分析模型主要包括哪四大類元素？ 分析模型的目的是為基于計(jì)算機(jī)的系統(tǒng)提供必要的信息、功能和行為域的說明。模型應(yīng)該能夠動(dòng)態(tài)改造，以便于軟件工程師更多地了解將要實(shí)現(xiàn)的系統(tǒng)，以便于共利益者更多地了解他們到底需要什么。1）基于場景的建模：使用基于場景的方法可以從客戶的視角描述系統(tǒng)。如最基本的用例圖。同樣，它們可以作為創(chuàng)建其他建模元素時(shí)的輸入。 2）基于類的建模：每個(gè)使用場景都暗示著當(dāng)一個(gè)參與者和系統(tǒng)交互時(shí)所操作的一組對象，這些對象被分成類具有相似屬性和共同行為的事物集合。3）基于行為的建模： 需求分析模型必須提供描述行為的建模元素，就是uml中的狀態(tài)圖。狀態(tài)圖是一種表現(xiàn)系統(tǒng)行為的方法，該方法描述系統(tǒng)狀態(tài)以及導(dǎo)致系統(tǒng)狀態(tài)改變的事件。狀態(tài)時(shí)任何可以觀察到的行為模式。4）面向信息流的建模：信息在基于計(jì)算機(jī)的系統(tǒng)中流動(dòng)時(shí)會被轉(zhuǎn)換，系統(tǒng)接受多種形式的輸入，使用函數(shù)輸入，生成多種形式的輸出。 （7） 面向?qū)ο蠓治龇椒ê徒Y(jié)構(gòu)化分析方法各自特點(diǎn)及他們使用了哪些技術(shù)？（8）軟件設(shè)計(jì)的原則有哪些？(1)可靠性用軟件系統(tǒng)規(guī)模越做越大越復(fù)雜，其可靠性越來越難保證。應(yīng)用本身對系統(tǒng)運(yùn)行的可靠性要求越來越高，軟件系統(tǒng)的可靠性也直接關(guān)系到設(shè)計(jì)自身的聲譽(yù)和生存發(fā)展競爭能力。軟件可靠性意味著該軟件在測試運(yùn)行過程中避免可能發(fā)生故障的能力，且一旦發(fā)生故障后，具有解脫和排除故障的能力。軟件可靠性和硬件可靠性本質(zhì)區(qū)別在于：后者為物理機(jī)理的衰變和老化所致，而前者是由于設(shè)計(jì)和實(shí)現(xiàn)的錯(cuò)誤所致。故軟件的可靠性必須在設(shè)計(jì)階段就確定，在生產(chǎn)和測試階段再考慮就困難了。(2)健壯性健壯性又稱魯棒性，是指軟件對于規(guī)范要求以外的輸入能夠判斷出這個(gè)輸入不符合規(guī)范要求，并能有合理的處理方式。軟件健壯性是一個(gè)比較模糊的概念，但是卻是非常重要的軟件外部量度標(biāo)準(zhǔn)。軟件設(shè)計(jì)的健壯與否直接反應(yīng)了分析設(shè)計(jì)和編碼人員的水平。(3)可修改性要求以科學(xué)的方法設(shè)計(jì)軟件，使之有良好的結(jié)構(gòu)和完備的文檔，系統(tǒng)性能易于調(diào)整。(4)容易理解軟件的可理解性是其可靠性和可修改性的前提。它并不僅僅是文檔清晰可讀的問題，更要求軟件本身具有簡單明了的結(jié)構(gòu)。這在很大程度上取決于設(shè)計(jì)者的洞察力和創(chuàng)造性，以及對設(shè)計(jì)對象掌握得透徹程度，當(dāng)然它還依賴于設(shè)計(jì)工具和方法的適當(dāng)運(yùn)用。(5)程序簡便(6)可測試性可測試性就是設(shè)計(jì)一個(gè)適當(dāng)?shù)臄?shù)據(jù)集合，用來測試所建立的系統(tǒng)，并保證系統(tǒng)得到全面的檢驗(yàn)。(7)效率性軟件的效率性一般用程序的執(zhí)行時(shí)間和所占用的內(nèi)存容量來度量。在達(dá)到原理要求功能指標(biāo)的前提下，程序運(yùn)行所需時(shí)間愈短和占用存儲容量愈小，則效率愈高。（8）標(biāo)準(zhǔn)化原則在結(jié)構(gòu)上實(shí)現(xiàn)開放，基于業(yè)界開放式標(biāo)準(zhǔn)，符合國家和信息產(chǎn)業(yè)部的規(guī)范。（9）先進(jìn)性滿足客戶需求，系統(tǒng)性能可靠，易于維護(hù)。（10）可擴(kuò)展性軟件設(shè)計(jì)完要留有升級接口和升級空間。對擴(kuò)展開放，對修改關(guān)閉。（9）軟件體系結(jié)構(gòu)風(fēng)格 體系結(jié)構(gòu)風(fēng)格 定義了一個(gè)系統(tǒng)家族，其包括一個(gè)詞匯表和一組約束。 一個(gè)詞匯表包含一些構(gòu)件和連接件類型， 一組約束指出系統(tǒng)是如何將這些構(gòu)件和連接件組合起來的。體系結(jié)構(gòu)風(fēng)格 反映了領(lǐng)域中眾多系統(tǒng)所共有的結(jié)構(gòu)和語義特性，并指導(dǎo)如何將各個(gè)模塊和子系統(tǒng)有效地組織成一個(gè)完整的系統(tǒng)。 對體系結(jié)構(gòu)風(fēng)格的研究和實(shí)踐為大粒度的軟件復(fù)用提供了可能。 數(shù)據(jù)流風(fēng)格 典型的體系結(jié)構(gòu)風(fēng)格 管道/過濾器風(fēng)格 調(diào)用返回風(fēng)格 倉庫風(fēng)格數(shù)據(jù)流風(fēng)格 特點(diǎn)：當(dāng)輸入數(shù)據(jù)經(jīng)過一系列的計(jì)算和操作構(gòu)件的變換形成輸出數(shù) 據(jù)時(shí)，可以應(yīng)用這種體系結(jié)構(gòu)。 管道/過濾器、批處理序列屬于數(shù)據(jù)流風(fēng)格。（2）管道/過濾器風(fēng)格 擁有一組過濾器構(gòu)件，這些構(gòu)件通過管道連接管道將數(shù)據(jù)從一個(gè)構(gòu)件傳 送到下一個(gè)構(gòu)件。 每個(gè)過濾器獨(dú)立于其上游和下游的構(gòu)件而工作，過濾器的設(shè)計(jì)要針對某 種形式的數(shù)據(jù)輸入，并且產(chǎn)生某種特定形式的數(shù)據(jù)輸出。 如果數(shù)據(jù)流退化成為單線的變換，則稱為批處理序列。這種結(jié)構(gòu)接收一 批數(shù)據(jù)，然后應(yīng)用一系列連續(xù)的構(gòu)件（過濾器）變換它。調(diào)用-返回風(fēng)格 在此類體系結(jié)構(gòu)中，存在以下3種子風(fēng)格。 主程序/子程序風(fēng)格 分層風(fēng)格在這種體系結(jié)構(gòu)中，整個(gè)系統(tǒng)被組織成一個(gè)分層結(jié)構(gòu)，每一層為上層提供服務(wù)，并作為下一層的客戶。面向?qū)ο箫L(fēng)格 I.系統(tǒng)的構(gòu)件封裝了數(shù)據(jù)和必須應(yīng)用到該數(shù)據(jù)上的操作，構(gòu)件間通過消息傳遞進(jìn)行通信與合作。 II與主程序/子程序的體系結(jié)構(gòu)相比，面向?qū)ο箫L(fēng)格中的對象交互會復(fù)雜一些。 III面向?qū)ο箫L(fēng)格與網(wǎng)絡(luò)應(yīng)用的需求在分布性、自治性、協(xié)作性、演化性等方面具有內(nèi)在的一致性。倉庫風(fēng)格 數(shù)據(jù)倉庫（如文件或數(shù)據(jù)庫）位于體系結(jié)構(gòu)的中心，其他構(gòu)件經(jīng)常訪問該數(shù)據(jù)倉庫，并對倉庫中的數(shù)據(jù)進(jìn)行增加、修改或刪除操作。 數(shù)據(jù)庫系統(tǒng)、超文本系統(tǒng)和黑板系統(tǒng)都屬于倉庫風(fēng)格。 倉庫風(fēng)格：中心存儲庫變換成“黑板”，黑板構(gòu)件負(fù)責(zé)協(xié)調(diào)信息在客戶間的傳遞，當(dāng)用戶感興趣的數(shù)據(jù)發(fā)生變化時(shí)，它將通知客戶軟件。黑板系統(tǒng)的傳統(tǒng)應(yīng)用是信號處理領(lǐng)域，如語音和模式識別。另一應(yīng)用是松耦合代理數(shù)據(jù)共享存取。（10） 軟件測試的目的是什么？有哪些測試策略？測試目的：為了發(fā)現(xiàn)軟件設(shè)計(jì)和實(shí)現(xiàn)過程中的疏忽所造成的錯(cuò)誤。傳統(tǒng)的測試策略：單元測試是針對程序中的模塊或構(gòu)件，主要揭露編碼階段產(chǎn)生的錯(cuò)誤。集成測試針對集成的軟件系統(tǒng)，主要揭露設(shè)計(jì)階段產(chǎn)生的錯(cuò)誤。確認(rèn)測試是根據(jù)軟件需求規(guī)約對集成的軟件進(jìn)行確認(rèn)，主要揭露不符合需求規(guī)約的錯(cuò)誤。系統(tǒng)測試是針對基于計(jì)算機(jī)系統(tǒng)中的軟件，以揭露不符合系統(tǒng)工程中對軟件要求的錯(cuò)誤。（11）自頂向下和自底向上兩種集成測試方法的優(yōu)缺點(diǎn)。1）自頂向下集成的優(yōu)點(diǎn)： 不需要驅(qū)動(dòng)模塊；能盡早對程序的主要控制和決策機(jī)制進(jìn)行檢驗(yàn)，能較早發(fā)現(xiàn)整體性的錯(cuò)誤；深度優(yōu)先的自頂向下集成能較早對某些完整的程序功能進(jìn)行驗(yàn)證。 自頂向下集成的缺點(diǎn)： 測試時(shí)低層模塊用樁模塊替代，不能反映真實(shí)情況；重要數(shù)據(jù)不能及時(shí)回送到上層模塊。2）自底向上集成的優(yōu)點(diǎn)： 不需要樁模塊，所以容易組織測試；將整個(gè)程序結(jié)構(gòu)分解成若干個(gè)簇，對同一層次的簇可并行進(jìn)行測試，可提高效率。 自底向上集成的缺點(diǎn)： 整體性的錯(cuò)誤發(fā)現(xiàn)得較晚。(12) 測試、測試測試和測試如果軟件是為一個(gè)客戶開發(fā)的，那么，最后由客戶進(jìn)行驗(yàn)收測試（acceptance test），以使客戶確認(rèn)該軟件是他所需要的。如果軟件是給許多客戶使用的（如市場上銷售的各種軟件），那么讓每個(gè)客戶做驗(yàn)收測試是不現(xiàn)實(shí)的。大多數(shù)軟件廠商都使用一種稱為測試和測試的過程，來發(fā)現(xiàn)那些似乎只有最終用戶才能發(fā)現(xiàn)的錯(cuò)誤。測試是由用戶在開發(fā)者的場所進(jìn)行的，軟件在開發(fā)者對用戶的“指導(dǎo)下”進(jìn)行測試。經(jīng)測試后的軟件稱為版軟件。測試是由軟件的最終用戶在一個(gè)或多個(gè)用戶場所進(jìn)行的，與測試不同，開發(fā)者通常不在測試現(xiàn)場。測試是軟件在開發(fā)者不能控制的環(huán)境中的“活的”應(yīng)用用戶記錄所有在測試中遇到的（真正的或想象的）問題，并定期把這些問題報(bào)告給開發(fā)者，接到測試的問題報(bào)告后，開發(fā)者對軟件進(jìn)行最后的修改，然后著手準(zhǔn)備向所有的用戶發(fā)布最終的軟件產(chǎn)品。（13） 白盒測試和黑盒測試的基本概念白盒測試（又稱為結(jié)構(gòu)測試）把測試對象看作一個(gè)透明的盒子測試人員根據(jù)程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息設(shè)計(jì)測試用例檢查程序中所有邏輯路徑是否都按預(yù)定的要求正確地工作。黑盒測試（又稱行為測試）把測試對象看做一個(gè)黑盒子測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能需求。（14）給出需求，能繪制出用例圖和設(shè)計(jì)類圖1.各種過程模型的區(qū)別和聯(lián)系 瀑布模型： 1 特點(diǎn)： 結(jié)構(gòu)化，有序 2 過程：溝通 策劃 建模 構(gòu)建 部署 演化過程模型： 1.特點(diǎn)：迭代的過程模型 （1）原型過程模型（可作為一個(gè)獨(dú)立的過程模型。更多時(shí)候作為一種技 原型模型的主要思想：先借用已有系統(tǒng)作為原型模型，通過“樣品”不斷改進(jìn)， 使得最后的產(chǎn)品就是用戶所需要的。 原型模型通過向用戶提供原型獲取用戶的反饋，使開發(fā)出的軟件能夠真正 反映用戶的需求。同時(shí)，原型模型采用逐步求精的方法完善原型，使得原型能夠“快速”開發(fā)，避免了像瀑布模型一樣在冗長的開發(fā)過程中難以對用戶的反饋?zhàn)鞒隹焖俚捻憫?yīng)。相對瀑布模型而言，原型模型更符合人們開發(fā)軟件的習(xí)慣，使目前較流行的一種實(shí)用軟件生存期模型。 （2）螺旋過程模型 特點(diǎn)：它結(jié)合了原型的迭代性質(zhì)和瀑布模型的系統(tǒng)性和可控性。 優(yōu)點(diǎn)：螺旋模型強(qiáng)調(diào)風(fēng)險(xiǎn)分析，使得開發(fā)人員和用戶對每個(gè)演化層出現(xiàn)的風(fēng)險(xiǎn)有所了解，繼而做出應(yīng)有的反應(yīng)，因此特別適用于龐大、復(fù)雜并具有高風(fēng)險(xiǎn)的系統(tǒng)。 自身特點(diǎn)：1、采用循環(huán)的方式逐步加深系統(tǒng)的定義和實(shí)踐的深度，同 時(shí)降低風(fēng)險(xiǎn)。 2、確定一系列里程碑。確保共利益者都支持可行的和令人滿意的系統(tǒng)解決方案。聯(lián)系：（1）原型模型是在瀑布模型的基礎(chǔ)上進(jìn)行完善的過程模型，瀑布模型是線性的，有序的；但是原型模型就讓瀑布模型形成了一個(gè)環(huán)，有迭代的特點(diǎn)。 （2）螺旋過程模型，它結(jié)合了原型的迭代性質(zhì)和瀑布模型的系統(tǒng)性和可控性。 （圖表見下頁）2 什么是統(tǒng)一過程模型？特點(diǎn)： 用例驅(qū)動(dòng) 功能描述 以架構(gòu)為核心 軟件結(jié)構(gòu)的藍(lán)圖 迭代并且增量 起始 細(xì)化 構(gòu)建 移交瀑布模型（經(jīng)典生命周期）原型過程模型慣用過程模型演化過程模型螺旋模型過程模型統(tǒng)一過程模型敏捷過程模型思考：為什么迭代過程更容易管理變更？ 如何建立能解決不可預(yù)測的過程？答案在于過程（對于飛快變化的項(xiàng)目和技術(shù)條件）的可適應(yīng)性。 原地踏步式的連續(xù)適應(yīng)性變化收效甚微，因此敏捷軟件過程必須增量地適應(yīng)。為了達(dá)到這一目的，團(tuán)隊(duì)則需要客戶的反饋（以做出正確的適應(yīng)性改變），可執(zhí)行原型或部分實(shí)現(xiàn)的可運(yùn)行系統(tǒng)是客戶反饋的最有效媒介。因此，應(yīng)當(dāng)使用增量式開發(fā)策略，必須在很短的時(shí)間間隔內(nèi)交付軟件增量（可執(zhí)行原型或部分實(shí)現(xiàn)的可運(yùn)行系統(tǒng)）來適應(yīng)（不可預(yù)測的）變更步伐。這種迭代的方法使客戶能夠：周期性地評價(jià)軟件增量，向軟件項(xiàng)目組提出必要的反饋，影響能夠接受反饋的過程適應(yīng)性變更。 迭代模型的一個(gè)重要特性即是支持項(xiàng)目的并行開發(fā)。從整個(gè)項(xiàng)目周期的角度，是通過各次迭代過程時(shí)間上的重疊來實(shí)現(xiàn)的，例如將多個(gè)產(chǎn)品化迭代與多個(gè)構(gòu)建迭代的后續(xù)迭代重疊，以分別向用戶交付迭代演進(jìn)版本；而在迭代過程之中，則可以通過任務(wù)的邏輯劃分來做到。然而，這需要滿足很多的條件，比如設(shè)計(jì)優(yōu)良、健壯的體系架構(gòu)，才使得將產(chǎn)品的功能需求分配到不同構(gòu)建迭代過程中完成變得現(xiàn)實(shí)可行；又如只有層次分明、接口穩(wěn)定的模塊設(shè)計(jì)，才可能真正實(shí)現(xiàn)各模塊的并行開發(fā)，雖然現(xiàn)在強(qiáng)大的軟件配置管理工具可以從技術(shù)層面支持團(tuán)隊(duì)協(xié)同開發(fā)，但仍解決不了并行開發(fā)的根本問題。實(shí)際上迭代模型是典型的以體系架構(gòu)為中心的開發(fā)方法，沒有健壯的體系架構(gòu)，迭代最終只能退化成多次小瀑布模型過程的循環(huán)，真的成了“增量就是打補(bǔ)丁,迭代就是推倒重來”.迭代模型的開發(fā)流程： 根據(jù)軟件開發(fā)計(jì)劃，修正與細(xì)化各次迭代的具體目標(biāo)與工作范圍（如須解決的風(fēng)險(xiǎn)，將實(shí)現(xiàn)的需求項(xiàng)等），針對迭代目標(biāo)，組織與裁減核心開發(fā)流程（包括業(yè)務(wù)分析、需求開發(fā)、分析設(shè)計(jì)、編碼實(shí)現(xiàn)、測試、發(fā)布與部署等），策劃具體的活動(dòng)內(nèi)容與任務(wù)，安排人力、物力資源的分配，設(shè)定具體的時(shí)間表等等。優(yōu)點(diǎn)比較：與大粒度、不夠精細(xì)的軟件開發(fā)計(jì)劃不同，迭代計(jì)劃關(guān)注的時(shí)間短、策劃的依據(jù)比較確定，由此對迭代過程采取時(shí)間框管理。與里程碑控制不同，它以保證計(jì)劃進(jìn)度為首要目標(biāo)，主要通過裁減迭代的任務(wù)范圍，比如將任務(wù)推后到下次迭代，來跟上進(jìn)度期限（增加人力的方式須謹(jǐn)慎考慮）。本次迭代的執(zhí)行結(jié)果，往往成為調(diào)整項(xiàng)目估計(jì)和策劃下次迭代的經(jīng)驗(yàn)參照和依據(jù)，使得下次迭代計(jì)劃更為精細(xì)與切實(shí)可行。思考 1.在分析建模的過程中有哪3個(gè)域需要考慮？ 功能域 信息域 行為域 2.在軟件工程中，為什么模型是很重要的？ 作為軟件工程師，每天的工作都離不開模型，會用模型來輔助理解整個(gè)項(xiàng)目大的構(gòu)想體系結(jié)構(gòu)、不同的構(gòu)件如何結(jié)合，以及其他一些特征。當(dāng)然，也可以把模型不斷細(xì)化，以便更好地理解軟件需求并完成符合這些需求的軟件設(shè)計(jì)。思考：簡述需求工程的7項(xiàng)任務(wù) 需求工程的7項(xiàng)任務(wù)：起始 、導(dǎo)出、精化、協(xié)商、規(guī)格說明、確認(rèn)和管理。 （PS：某些需求工程的任務(wù)并行發(fā)生且要全部適應(yīng)項(xiàng)目的要求） 起始 發(fā)現(xiàn)價(jià)值 項(xiàng)目范圍（粗粒度）當(dāng)確定了商業(yè)要求或是發(fā)現(xiàn)了潛在新市場、新服務(wù)時(shí)才開始的。業(yè)務(wù)領(lǐng)域的共利益者定義業(yè)務(wù)用例，確定市場的寬度和深度，進(jìn)行初略的可行性分析，并確定項(xiàng)目范圍的工作說明。所有的這些信息都取決于變更，但是應(yīng)該充分地與軟件開發(fā)組及時(shí)討論。 在項(xiàng)目起始階段中，要建立基本的理解，包括對問題、誰需要解決方案、所需要解決方案的性質(zhì)，與姜木利益相關(guān)者的和開發(fā)人員之間達(dá)成初步交流合作的效果。 導(dǎo)出（需求獲取/誘導(dǎo)） 對于需求的獲取也就是導(dǎo)出是十分困難的。從三個(gè)方面可以理解導(dǎo)出的困難之處。 范圍問題 系統(tǒng)的邊界不清楚，或是客戶或用戶的說明帶有不必要額技術(shù)細(xì)節(jié)，這些細(xì)節(jié)可能會到時(shí)混淆而不是澄清系統(tǒng)的整體目標(biāo)。 理解問題 客戶和用戶不能完全確定需要什么，對問題域沒有完整的認(rèn)識，與開發(fā)人員存在溝通的問題，省略那些他們認(rèn)為是“明顯的”信息。確定的需求和其他用戶需求相沖突，需求說明有歧義或不可測試。 易變問題 需求會隨時(shí)間不斷變化 精化（構(gòu)建分析模型） 在起始和導(dǎo)出階段獲得的信息會在精化階段進(jìn)行擴(kuò)展和提煉。改任務(wù)集中于開發(fā)一個(gè)精確的分析模型，用以說明軟件的三個(gè)方面：信息，功能和行為。 協(xié)商（協(xié)調(diào)需求沖突） 只給定了有限的業(yè)務(wù)資源，而客戶和用戶提出了過高的要求，只是常有的事。另一個(gè)相當(dāng)常見的現(xiàn)象是，不同的客戶或用戶提出了相互沖突的需求。需求工程師必須通過協(xié)商過程來調(diào)節(jié)這些沖突。應(yīng)該讓客戶、用戶、和其他共利益者對各自的需求排序，然后按優(yōu)先級討論沖突，使用迭代的方法給需求排序，評估每項(xiàng)需求對項(xiàng)目產(chǎn)生的成本和風(fēng)險(xiǎn)，表述內(nèi)部沖突。刪除、組合或修改需求，以便參與各方面均能達(dá)到一定的滿意度。規(guī)格說明 在基于計(jì)算機(jī)的系統(tǒng)的環(huán)境下，術(shù)語規(guī)格說明對不同的人有不同的含義。一個(gè)規(guī)格說明可以是一份文檔，一套圖形化的模型，一個(gè)形式化的數(shù)學(xué)模型，一組使用場景，一個(gè)原型或上訴各項(xiàng)的任意組合。確認(rèn)（評審SRS） 在確認(rèn)這一步將對需求工程的工作產(chǎn)品進(jìn)行質(zhì)量評估。需求確認(rèn)要檢查規(guī)格說明以保證：已無歧義地說明了所有系統(tǒng)需求；已檢測出不一致、疏忽和錯(cuò)誤并得以糾正；工作產(chǎn)品符合為過程、項(xiàng)目、和產(chǎn)品建立的標(biāo)準(zhǔn)。需求管理 基于計(jì)算機(jī)的系統(tǒng)其需求會變更，而且變更的要求貫穿于系統(tǒng)的整個(gè)生存期。需求管理是用于幫助開發(fā)人員在項(xiàng)目進(jìn)展中標(biāo)識、控制和跟蹤需求以及需求變更的一組活動(dòng)。 思考：需求模型每類元素對模型的貢獻(xiàn)，每類元素為什么是唯一的，以及每個(gè)元素所表現(xiàn)的信息。 需求模型的元素有3類：（1） 基于場景的元素；（UML中的用例圖） 使用基于場景的方法可以從客戶的視角描述系統(tǒng)。如最基本的用例圖。 同樣，它們可以作為創(chuàng)建其他建模元素時(shí)的輸入。 貢獻(xiàn)： 需求模型基于場景的元素通常是正在開發(fā)模型的第一部分。 明白軟件所需功能和功能之間的交互。 （2）基于類的元素；（UML中的類圖） 每個(gè)使用場景都暗示著當(dāng)一個(gè)參與者和系統(tǒng)交互時(shí)所操作的一組對象 這些對象被分成類具有相似屬性和共同行為的事物集合。 貢獻(xiàn)： 類圖用于對系統(tǒng)靜態(tài)設(shè)計(jì)視圖的建模，涉及到對系統(tǒng)的詞匯、協(xié)作、 模式的建模。在UML中，類圖顯示了一組類、接口、協(xié)作以及它們之間 的關(guān)系。在UML的靜態(tài)機(jī)制中類圖是一個(gè)重點(diǎn)，它不但為設(shè)計(jì)人員所關(guān)心， 更為實(shí)現(xiàn)人員所關(guān)注。 （3）行為元素；（UML中的狀態(tài)圖） 需求分析模型必須提供描述行為的建模元素，就是uml中的狀態(tài)圖。 狀態(tài)圖是一種表現(xiàn)系統(tǒng)行為的方法，該方法描述系統(tǒng)狀態(tài)以及導(dǎo)致系統(tǒng)狀 態(tài)改變的事件。狀態(tài)時(shí)任何可以觀察到的行為模式。 貢獻(xiàn)： 1、描述一個(gè)操作的執(zhí)行過程中所完成的工作或者動(dòng)作 2、描述對象內(nèi)部的工作 3、描述用例的執(zhí)行 4、處理多線程 5、顯示如何執(zhí)行一組相關(guān)的動(dòng)作，以及這些動(dòng)作如何影響周圍對象需求模型的3類元素分別對應(yīng)了軟件工程的3個(gè)方面：基于場景的元素功能域基于類的元素信息域行為元素行為域所以每類元素都是唯一的。思考：基于用例、類、行為模型的區(qū)別 一、基于用例的建模 （1）新建初試用例 （先畫用例圖） 兩個(gè)首要的需求工程工作是起始和導(dǎo)出，它們提供了開始編寫用例 所需要的信息，確定共利益者，定義問題的范圍，說明整體的運(yùn)行目建 立優(yōu)先級順序，概述所有已知的功能需求。 開始開發(fā)用例時(shí)，應(yīng)該列出特定參與者執(zhí)行的功能或活動(dòng)。這些可 以從所需的系統(tǒng)功能的列表通過與共利益者交流等方式而獲得。 1.定義術(shù)語表 每個(gè)業(yè)務(wù)領(lǐng)域都具有它本身獨(dú)一無二的詞匯，需求分析的目的就 是理解和定義這些詞匯。詞匯應(yīng)該被項(xiàng)目相關(guān)人所理解。術(shù)語表必須 解決同音異義和同義異音問題。 2.標(biāo)識參與者 首先，需要標(biāo)識業(yè)務(wù)參與者。參與者是在業(yè)務(wù)中扮演某個(gè)角色的 人、部門或者獨(dú)立的軟件系統(tǒng)。一般來說，參與者使用系統(tǒng)或給系 統(tǒng)提供服務(wù)。 與現(xiàn)實(shí)生活一樣，參與者可以在不同的時(shí)刻，扮演不同的業(yè)務(wù)角 色。例如，小劉在Nowhere Cars商店上班時(shí)，他是一個(gè)助手；如果他 在回家之前要租用一輛汽車，就成為一個(gè)顧客。 3. 標(biāo)識系統(tǒng)用例 一旦有了參與者，就可以從參與者的角度看系統(tǒng),問系統(tǒng)能給參與 者提供哪些服務(wù)?通過一問一答,就可以查找用例。 （2）細(xì)化初始用例 為全面理解用例描述功能，對于交互操作給出另外的描述是非常必要 的。就是進(jìn)行用例規(guī)約，寫出用例描述。如：表一User Case:0101注冊用戶角色：游客前置事件：游客未登錄基本事件流:1.顯示注冊頁面，Register.jsp2填寫注冊信息 2.1用戶名 必填 長度小于10 2.2密碼 兩次密碼需相同 必填 長度小于16 2.3qq號碼 選填 長度小于16 2.4E-mail 格式需正確 必填 長度小于503.信息輸入正確，點(diǎn)擊提交4.顯示注冊成功界面,RegisterSuccess.jsp 信息有誤詳述注冊失敗界面,RegisterFailure.jsp后置條件: 注冊成功可選事件流1：后置條件1: 可選事件流2：后置條件2: 表一 （3）編寫正規(guī)用例 最后，結(jié)合以上2步驟，分析整合處理，完成最終的用例建模。2、 基于類的建模 （一） 尋找分析類 我們以問題陳述為輸入信息，采用“名詞動(dòng)詞法”尋找分析類。名詞 動(dòng)詞法的主要規(guī)則是從名詞與名詞短語中提取對象與屬性；從動(dòng)詞與動(dòng)詞 短語中提取操作和關(guān)聯(lián)。 1找備選類 首先?？梢灾鹱种鹁涞亻喿x上面那段需求描述,并將其中的所有的名詞 及名詞短語列出來，可以得到備選類列表。 2從備選類中篩選出候選類 并不是所有的備選類都是適合候選類，有些名詞對于要開發(fā)的系統(tǒng)來 說無關(guān)緊要。甚至不屬于系統(tǒng)；而有些名詞表述的概念則相對較小，適 合某個(gè)候選類的屬性。因此，需要對備選類進(jìn)行一番篩選，將這些不適 合的排除掉。 （二）確定類關(guān)系 通過上面的工作，從需求描述中找到了6個(gè)相關(guān)的類，接下來就是確 定類之間的關(guān)系。 1確定類關(guān)系 為了反映和記錄這些類之間的關(guān)系，可以使用UML中的類圖將其記錄 下來。 2.給關(guān)聯(lián)添加屬性 （1）確定關(guān)聯(lián)的多重性 基于以上的分析可以得到類圖。 如果系統(tǒng)較大，可以以上面的類圖為基礎(chǔ)，把關(guān)聯(lián)度緊密的類合 成一個(gè)包，以便更好的組織子系統(tǒng)。 （2） 確定關(guān)聯(lián)的導(dǎo)航性 類圖中的諸如導(dǎo)航性，角色名，導(dǎo)出屬性，限定符及約束等高級 屬性不是每個(gè)類模型都必須加入的。 (3) 確定約束 (4) 確定關(guān)聯(lián)的限定符 3給類添加職責(zé) 當(dāng)找到了反應(yīng)問題域本質(zhì)的主要類，并清理他們之間的關(guān)系之后，就 可以為這些類添加相應(yīng)的職責(zé)。類的職責(zé)包括以下兩個(gè)內(nèi)容：類所維護(hù)的 信息(成員變量)和類提供的行為(成員方法)。 在本階段將主要的成員變量和成員方法標(biāo)識出來，以便更好的理解問題域。三 行為建模 行為建模，就是uml中的狀態(tài)圖。狀態(tài)圖是一種表現(xiàn)系統(tǒng)行為的方法， 該方法描述系統(tǒng)狀態(tài)以及導(dǎo)致系統(tǒng)狀態(tài)改變的事件。狀態(tài)時(shí)任何可以觀察到的 行為模式。 （一）理解系統(tǒng)內(nèi)的變更 （二）識別事件 （三）為每個(gè)用例生成序列區(qū)別： 基于用例模型：描述角色以及角色與用例之間的連接關(guān)系。說明的是誰要使用 系統(tǒng)，以及他們使用該系統(tǒng)可以做些什么。一個(gè)用例圖包含了多個(gè)模型元素，如系統(tǒng)、參與者和用例，并且顯示了這些元素之間的各種關(guān)系，如泛化、關(guān)聯(lián)和依賴。 用例模型描述一組用例、參與者以及它們之間的關(guān)系，其展示的是該系統(tǒng)在它的外面環(huán)境中所提供的外部可見服務(wù)。 基于類的模型：是描述系統(tǒng)中的類，以及各個(gè)類之間的關(guān)系的靜態(tài)視圖。能夠讓我們在正確編寫代碼以前對系統(tǒng)有一個(gè)全面的認(rèn)識。類圖是一種模型類型，確切的說，是一種靜態(tài)模型類型。類模型描述一組對象、接口、協(xié)作等事物之間的關(guān)系 行為模型：描述類的對象所有可能的狀態(tài)，以及事件發(fā)生時(shí)狀態(tài)的轉(zhuǎn)移條件?？梢圆东@對象、子系統(tǒng)和系統(tǒng)的生命周期。他們可以告知一個(gè)對象可以擁有的狀態(tài)，并且事件(如 消息的接收、時(shí)間的流逝、錯(cuò)誤、條件變?yōu)檎娴?會怎么隨著時(shí)間的推移來影響這些狀態(tài)。一個(gè)狀態(tài)圖應(yīng)該連接到所有具有清晰的可標(biāo)識狀態(tài)和復(fù)雜行為的類；該圖 可以確定類的行為，以及該行為如何根據(jù)當(dāng)前的狀態(tài)變化，也可以展示哪些事件將會改變類的對象的狀態(tài)。狀態(tài)模型是對類模型的補(bǔ)充。狀態(tài)模型展示了一個(gè)狀態(tài)機(jī)，由狀態(tài)、轉(zhuǎn)換、事件和活動(dòng)組成。強(qiáng)調(diào)事件行為的順序。一：這3種模型各有側(cè)重1:用例圖側(cè)重描述用戶需求，2:類圖側(cè)重描述系統(tǒng)具體實(shí)現(xiàn)；二：描述的方面都不相同1:類圖描述的是系統(tǒng)的結(jié)構(gòu)，2:狀態(tài)圖描述的是系統(tǒng)的行為；在有的文獻(xiàn)書籍中，將這3種模型分為三類：結(jié)構(gòu)分類、動(dòng)態(tài)行為和模型管理：1：結(jié)構(gòu)分類包括用例圖、類圖，2：動(dòng)態(tài)行為包括狀態(tài)圖，3：模型管理則包含類圖。思考：簡要說明結(jié)構(gòu)化分析和面向?qū)ο蠓治龅闹饕獏^(qū)別一結(jié)構(gòu)化分析 結(jié)構(gòu)化分析是以數(shù)據(jù)流圖為工具，實(shí)現(xiàn)對問題空間即需求的描述。它主要以數(shù)據(jù)流、數(shù)據(jù)變換為考慮對象，從這個(gè)角度來描述整個(gè)系統(tǒng)的狀況。通過數(shù)據(jù)流圖為藍(lán)本對系統(tǒng)的功能加以分解，一直到最小的功能元素單元，然后開發(fā)人員據(jù)此進(jìn)行程序設(shè)計(jì)。 結(jié)構(gòu)化分析強(qiáng)調(diào)的是開發(fā)方法的結(jié)構(gòu)和理性，它的本質(zhì)是功能分解，從代表目標(biāo)系統(tǒng)整體功能的單個(gè)處理著手，自頂向下不斷地把復(fù)雜的處理分解為子處理，這樣一層一層地分解下去，直到僅剩下的若干個(gè)容易實(shí)現(xiàn)的子處理為止。當(dāng)所分解的子處理十分簡單時(shí)，就可以寫出各個(gè)最底層處理的處理描述。但隨著軟件工程的發(fā)展，接過話分析與設(shè)計(jì)方法表現(xiàn)出以下弊端： （1）結(jié)構(gòu)化分析是圍繞現(xiàn)實(shí)處理功能的過程來構(gòu)造系統(tǒng)的。然而，用戶需要的變化大部分是針對功能的，因此，用結(jié)構(gòu)化方法分析設(shè)計(jì)出的系統(tǒng)結(jié)構(gòu)常常不穩(wěn)定。 （2）結(jié)構(gòu)化分析定了了目標(biāo)系統(tǒng)的邊界，且開發(fā)系統(tǒng)的結(jié)構(gòu)依賴于對系統(tǒng)邊界的定義因此，很難把系統(tǒng)擴(kuò)展到新的邊界，系統(tǒng)難修改和擴(kuò)充。 （3）結(jié)構(gòu)化分析系統(tǒng)時(shí)，幾乎每開發(fā)一個(gè)新的軟件系統(tǒng)都要針對具體系統(tǒng)做大量重復(fù)和復(fù)雜的工作，代碼重用性差。二面向?qū)ο蟮姆治觯∣OA） 1）問題領(lǐng)域分析（標(biāo)識對象） 分析領(lǐng)域的業(yè)務(wù)范圍、業(yè)務(wù)規(guī)則和業(yè)務(wù)處理過程，確定系統(tǒng)的責(zé)任、范圍和邊界，確定系統(tǒng)的需求、在分析中需要著重對系統(tǒng)與外部的用戶和其他系統(tǒng)的交互進(jìn)行分析。確定交互的內(nèi)容、步驟和順序。 2）發(fā)現(xiàn)和定義對象、類（標(biāo)識結(jié)構(gòu)） 識別對象和類，確定它們的內(nèi)部特征：屬性與服務(wù)操作。這是一個(gè)從現(xiàn)實(shí)世界到概念模型的抽象過程，是認(rèn)識從特殊到一般的上升過程。 3）識別對象的外部聯(lián)系（標(biāo)識主題） 在識別和定義對象與類的過程中，需要同時(shí)識別對象與對象、類與類之間的各種外部聯(lián)系，包括結(jié)構(gòu)性的靜態(tài)聯(lián)系和行為性的動(dòng)態(tài)聯(lián)系，包括特殊與一般、整體與部分、實(shí)例連接、消息鏈接等聯(lián)系。 4）建立系統(tǒng)的靜態(tài)結(jié)構(gòu)模型（定義屬性） 根據(jù)系統(tǒng)的靜態(tài)結(jié)構(gòu)，建立系統(tǒng)的靜態(tài)結(jié)構(gòu)模型，并且把它們用圖形和文字說明表達(dá)出來。這主要是在前面對于類和對象、及其聯(lián)系的分析基礎(chǔ)上，繪制對象類圖和對象圖、系統(tǒng)與子系統(tǒng)結(jié)構(gòu)圖等，編制相應(yīng)的說明文檔。 5）建立系統(tǒng)的動(dòng)態(tài)行為模型（定義方法） 分析系統(tǒng)的行為，建立系統(tǒng)的動(dòng)態(tài)行為模型，并且把它們用圖形和文字說明表達(dá)出來，如繪制交互圖、狀態(tài)圖等，編制相應(yīng)的說明文檔。三結(jié)構(gòu)化方法（面向過程）和面向?qū)ο蠓椒ǖ膮^(qū)別（1）處理問題時(shí)的出發(fā)點(diǎn)不同 結(jié)構(gòu)化方法強(qiáng)調(diào)過程抽象化和模塊化，以過程為中心； 面向?qū)ο蠓椒◤?qiáng)調(diào)把問題域直接映射到對象及對象之間的接口上，用符合人們通常思維方式來處理客觀世界的問題。（2）處理問題的基本單位和層次邏輯關(guān)系不同 結(jié)構(gòu)化方法把客觀世界的問題抽象成計(jì)算機(jī)可以處理的過程，處理問題的基本單位是能夠表達(dá)過程的功能模塊，用模塊的層次結(jié)構(gòu)概括模塊或模塊間的關(guān)系和功能； 面向?qū)ο蠓椒ㄊ怯糜?jì)算機(jī)邏輯來模擬客觀世界中的物理存在，以對象的集合類作為處理問題的基本單位，盡可能使計(jì)算機(jī)世界向客觀世界靠攏，它用類的層次結(jié)構(gòu)來體現(xiàn)類之間的繼承和發(fā)展。（3）數(shù)據(jù)處理方式與控制程序方式不同 結(jié)構(gòu)化方法是直接通過數(shù)據(jù)流來驅(qū)動(dòng)，各個(gè)模塊程序之間存在著控制與被控制的關(guān)系； 面向?qū)ο蠓椒ㄊ峭ㄟ^用例（業(yè)務(wù)）來驅(qū)動(dòng)，是以人為本的方法，站在客戶的角度去考慮問題。思考：簡述設(shè)計(jì)模型，以及分析模型和設(shè)計(jì)模型的聯(lián)系設(shè)計(jì)模型分為：數(shù)據(jù)或類的設(shè)計(jì) 體系結(jié)構(gòu)設(shè)計(jì) 接口設(shè)計(jì) 構(gòu)件級設(shè)計(jì) 部署級設(shè)計(jì)數(shù)據(jù)或類設(shè)計(jì)：是將類模型轉(zhuǎn)化為設(shè)計(jì)類的實(shí)現(xiàn)以及軟件實(shí)現(xiàn)所需要的數(shù)據(jù)結(jié)構(gòu)。體系結(jié)構(gòu)設(shè)計(jì)：定義了軟件的主要構(gòu)造元素之間的關(guān)系、課用于達(dá)到系統(tǒng)所定義需求的體系結(jié)構(gòu)風(fēng)格和設(shè)計(jì)模式以及影響體系結(jié)構(gòu)實(shí)現(xiàn)方式的約束。體系結(jié)構(gòu)設(shè)計(jì)表示基于計(jì)算機(jī)系統(tǒng)的框架可以從需求模型導(dǎo)出。接口設(shè)計(jì)：描述了信息如何流入好人流出系統(tǒng)以及被定義為體系結(jié)構(gòu)一部分構(gòu)件之間是如何通信的。 有3個(gè)要素：（1）用戶界面UI （2）和其他系統(tǒng)、設(shè)備、網(wǎng)絡(luò)或其他信息生成者或 使用者的外部接口 （3）各種設(shè)計(jì)構(gòu)件之間的內(nèi)部接口這些接口設(shè)計(jì)元素能夠使軟件進(jìn)行外部通信，還能使軟件體系結(jié)構(gòu)中的構(gòu)件之間進(jìn)行內(nèi)部的通信和協(xié)作。構(gòu)件級設(shè)計(jì)：完整的描述了每個(gè)軟件構(gòu)件的內(nèi)部細(xì)節(jié)。 細(xì)節(jié)：構(gòu)件級設(shè)計(jì)為所有局部數(shù)據(jù)對象定義數(shù)據(jù)結(jié)構(gòu) 為所有在構(gòu)件內(nèi)發(fā)生的處理定義算法細(xì)節(jié) 定義允許訪問所有構(gòu)件操作部署級設(shè)計(jì)：指明軟件功能和子系統(tǒng)將如何在支持軟件的物理計(jì)算環(huán)境內(nèi) 分布。分析模型：是概念層次的東西，與具體實(shí)現(xiàn)技術(shù)無關(guān)，分析模型又稱分析類，分為邊界類、控制類、實(shí)體類, 分析用于獲取系統(tǒng)中主要的“職責(zé)簇”，他們代表系統(tǒng)的原型類，是系統(tǒng)必須處理的主要抽象概念的“第一個(gè)關(guān)口”。分析類是跨越需求和設(shè)計(jì)實(shí)現(xiàn)的橋梁。聯(lián)系：分析模型的每個(gè)元素都提供了創(chuàng)建四種設(shè)計(jì)模型所必需的信息。數(shù)據(jù)/類設(shè)計(jì)：將分析類模型轉(zhuǎn)化為設(shè)計(jì)類的實(shí)現(xiàn)以及軟件實(shí)現(xiàn)所要求的 數(shù)據(jù)結(jié)構(gòu)。體系結(jié)構(gòu)設(shè)計(jì)：定義軟件的主要結(jié)構(gòu)元素之間的聯(lián)系、可用于達(dá)到系統(tǒng)所定義需求的體系結(jié)構(gòu)風(fēng)格和設(shè)計(jì)模式以及影響體系結(jié)構(gòu)實(shí)現(xiàn)方式的約束。接口設(shè)計(jì)：描述軟件和協(xié)作系統(tǒng)之間、軟件和使用人員之間是如何通信的。構(gòu)件設(shè)計(jì)：將軟件體系結(jié)構(gòu)的結(jié)構(gòu)元素變換為對軟件構(gòu)件的過程性描述。如下圖：思考：簡述軟件體系結(jié)構(gòu)風(fēng)格體系結(jié)構(gòu)風(fēng)格 定義了一個(gè)系統(tǒng)家族，其包括一個(gè)詞匯表和一組約束。 一個(gè)詞匯表包含一些構(gòu)件和連接件類型， 一組約束指出系統(tǒng)是如何將這些構(gòu)件和連接件組合起來的。體系結(jié)構(gòu)風(fēng)格 反映了領(lǐng)域中眾多系統(tǒng)所共有的結(jié)構(gòu)和語義特性，并指導(dǎo)如何將 各個(gè)模塊和子系統(tǒng)有效地組織成一個(gè)完整的系統(tǒng)。 對體系結(jié)構(gòu)風(fēng)格的研究和實(shí)踐為大粒度的軟件復(fù)用提供了可能。 數(shù)據(jù)流風(fēng)格 典型的體系結(jié)構(gòu)風(fēng)格 管道/過濾器風(fēng)格 調(diào)用返回風(fēng)格 倉庫風(fēng)格（1） 數(shù)據(jù)流風(fēng)格：（見圖一） 特點(diǎn)：當(dāng)輸入數(shù)據(jù)經(jīng)過一系列的計(jì)算和操作構(gòu)件的變換形成輸出數(shù) 據(jù)時(shí)，可以應(yīng)用這種體系結(jié)構(gòu)。 管道/過濾器、批處理序列屬于數(shù)據(jù)流風(fēng)格。 圖一（2）管道/過濾器風(fēng)格 擁有一組過濾器構(gòu)件，這些構(gòu)件通過管道連接管道將數(shù)據(jù)從一個(gè)構(gòu)件傳 送到下一個(gè)構(gòu)件。 每個(gè)過濾器獨(dú)立于其上游和下游的構(gòu)件而工作，過濾器的設(shè)計(jì)要針對某 種形式的數(shù)據(jù)輸入，并且產(chǎn)生某種特定形式的數(shù)據(jù)輸出。 如果數(shù)據(jù)流退化成為單線的變換，則稱為批處理序列。這種結(jié)構(gòu)接收一 批數(shù)據(jù)，然后應(yīng)用一系列連續(xù)的構(gòu)件（過濾器）變換它。（3） 調(diào)用-返回風(fēng)格 在此類體系結(jié)構(gòu)中，存在以下3種子風(fēng)格。 主程序/子程序風(fēng)格（見圖二） 圖二分層風(fēng)格（見圖三）在這種體系結(jié)構(gòu)中，整個(gè)系統(tǒng)被組織成一個(gè)分層結(jié)構(gòu)，每一層為上層提供服務(wù)，并作為下一層的客戶。 圖三面向?qū)ο箫L(fēng)格 I.系統(tǒng)的構(gòu)件封裝了數(shù)據(jù)和必須應(yīng)用到該數(shù)據(jù)上的操作，構(gòu)件間通過消息傳遞進(jìn)行通信與合作。 II與主程序/子程序的體系結(jié)構(gòu)相比，面向?qū)ο箫L(fēng)格中的對象交互會復(fù)雜一些。 III面向?qū)ο箫L(fēng)格與網(wǎng)絡(luò)應(yīng)用的需求在分布性、自治性、協(xié)作性、演化性等方面具有內(nèi)在的一致性。（4） 倉庫風(fēng)格（見圖四） 數(shù)據(jù)倉庫（如文件或數(shù)據(jù)庫）位于體系結(jié)構(gòu)的中心，其他構(gòu)件經(jīng)常訪問該數(shù)據(jù)倉庫，并對倉庫中的數(shù)據(jù)進(jìn)行增加、修改或刪除操作。 數(shù)據(jù)庫系統(tǒng)、超文本系統(tǒng)和黑板系統(tǒng)都屬于倉庫風(fēng)格。 圖四 倉庫風(fēng)格：中心存儲庫變換成“黑板”，黑板構(gòu)件負(fù)責(zé)協(xié)調(diào)信息在客戶間的傳遞，當(dāng)用戶感興趣的數(shù)據(jù)發(fā)生變化時(shí)，它將通知客戶軟件。黑板系統(tǒng)的傳統(tǒng)應(yīng)用是信號處理領(lǐng)域，如語音和模式識別。另一應(yīng)用是松耦合代理數(shù)據(jù)共享存取。（見圖五） 圖五 思考：（一）簡述軟件體系結(jié)構(gòu)框架 一、定義：體系結(jié)構(gòu)框架是特定應(yīng)用領(lǐng)域問題的體系結(jié)構(gòu)模式，它在組織形 式上是一個(gè)待實(shí)例化的完整系統(tǒng)。 定義了軟件系統(tǒng)的構(gòu)成單元和關(guān)系 創(chuàng)建了基本的模塊 定義了涉及功能更改和擴(kuò)充的插件位置。 重要作用：重用2、 趨勢：面向某領(lǐng)域（包括業(yè)務(wù)領(lǐng)域，如ERP，和計(jì)算領(lǐng)域，如GUI）的、可復(fù)用的“半成品”軟件，它實(shí)現(xiàn)了該領(lǐng)域的共性部分，并提供一系列定義良好的可變點(diǎn)以保證靈活性和可擴(kuò)展性?？梢哉f，軟件體系結(jié)構(gòu)框架是領(lǐng)域分析結(jié)果的軟件化，是領(lǐng)域內(nèi)最終應(yīng)用系統(tǒng)的模板。隨著軟件規(guī)模的擴(kuò)大、應(yīng)用的廣泛和軟件復(fù)用技術(shù)的發(fā)展，以子程序或類（Class）為單位的軟件復(fù)用有許多不足：（1） 子程序庫日趨其龐大以致于使用人員難以掌握，（2） 大多數(shù)類粒度很小，且其自身往往不能完成有用的功能。這一問題迫使人 們在復(fù)用中將一組類（或模塊）及其交互作為一個(gè)整體來考慮，由此出現(xiàn)了 軟件體系結(jié)構(gòu)框架。三、軟件體系結(jié)構(gòu)框架至少包含以下組成部分：（1） 一系列完成計(jì)算的模塊，在此稱為構(gòu)件。（2） 構(gòu)件之間的關(guān)系與交互機(jī)制。（3） 一系列可變點(diǎn)（也稱熱點(diǎn)，Hot-spots，或調(diào)整點(diǎn)）。（4） 可變點(diǎn)的行為調(diào)整機(jī)制。四、開發(fā)人員通過軟件體系結(jié)構(gòu)框架的行為調(diào)整機(jī)制，將領(lǐng)域中具體應(yīng)用所特有的軟件模塊綁定到該軟件框架的可變點(diǎn)，從而得到最終應(yīng)用系統(tǒng)，這一過程稱為軟件體系結(jié)構(gòu)框架的例化（instantiation）。通過軟件體系結(jié)構(gòu)框架的使用，開發(fā)人員可將主要精力放在應(yīng)用所特有的模塊的開發(fā)上，從而大大提高了軟件生產(chǎn)率和質(zhì)量。軟件體系結(jié)構(gòu)框架的行為調(diào)整機(jī)制是指如何針對具體的應(yīng)用調(diào)整該框架的可變部分、如何在可變點(diǎn)加入特定應(yīng)用模塊所采用的方法和規(guī)則。行為調(diào)整機(jī)制可分為四種：（1） 模板參數(shù)化。軟件體系結(jié)構(gòu)框架提供代碼自動(dòng)生成工具，該工具根據(jù)用戶 設(shè)置的參數(shù)自動(dòng)生成所需的代碼。（2） 繼承和多態(tài)。通過面向?qū)ο笾械淖宇惱^承和重載，在子類中加入新的功能 或改變父類的行為。（3） 動(dòng)態(tài)綁定。在運(yùn)行時(shí)刻動(dòng)態(tài)綁定所需的對象服務(wù)，可通過軟件模式技術(shù)實(shí) 現(xiàn)。（4） 構(gòu)件替換。通過替換框架中可插拔的構(gòu)件來加入業(yè)務(wù)特定的功能，不同于一般的可復(fù)用軟件制品，軟件體系結(jié)構(gòu)框架的一個(gè)顯著特點(diǎn)是逆向控制（Inversion of Control），在復(fù)用過程中，前者需被顯式調(diào)用，控制是在應(yīng)用特定的模塊中，軟件框架則不然，應(yīng)用開發(fā)人員只要將應(yīng)用特定的模塊綁定到框架內(nèi)，框架則根據(jù)自己的交互機(jī)制自動(dòng)調(diào)用該模塊，控制由框架負(fù)責(zé)。五、分類（1）按其應(yīng)用的范圍可分為： 系統(tǒng)基礎(chǔ)設(shè)施框架。用于簡化系統(tǒng)級軟件的開發(fā)，如操作系統(tǒng)、用戶界面、語言處理等，典型例子為MacApp