第一章概述1.2通用的軟件產品開發和定制化軟件開發之間最重要的區別是什么?這在實踐中對于通用軟件產品的用戶意味著什么?根本區別在于，在通用軟件產品開發中，規范由產品開發者擁有。對于定制產品開發，規范由客戶擁有和控制。這一點的影響是重大的——開發者可以根據一些外部變化（例如競爭產品）迅速決定更改規范，但當客戶擁有規范時，更改必須在客戶和開發者之間進行協商，并且可能會產生合同影響。對于通用產品的用戶，這意味著他們無法控制軟件規范，因此無法控制產品的演變。開發者可能會決定包含/排除功能并更改用戶界面。這可能會對用戶的業務流程產生影響，并在安裝新版本的系統時增加額外的培訓成本。這也可能會限制客戶改變自己業務流程的靈活性。1.3軟件產品應該具有的4個重要屬性是什么?另外舉出4個可能有意義的屬性。四個重要的屬性是可維護性、可靠性和安全性、效率和可接受性。其他可能重要的屬性可能是可重用性（它是否可以在其他應用程序中重用）、可分布性（它是否可以分布在處理器網絡上）、可移植性（它是否可以在多個平臺上運行，例如筆記本電腦和移動平臺）和互操作性（它是否可以與廣泛的其他軟件系統一起工作）。對4個關鍵屬性的分解，例如可靠性分解為安全性、安全性、可用性等，也是這個問題的有效答案。1.4除了異構性、企業和社會的變革、可信和信息安全之外，說一說軟件工程在21世紀有可能面對的其他問題和挑戰(提示：想一想環境)。軟件工程面臨的問題與挑戰眾多，主要包括：開發節能系統，以提升其在低功耗移動設備上的適用性，并減少IT設備的整體碳排放。開發模擬系統的驗證技術，這對于預測和應對氣候變化的程度至關重要。開發適合多文化背景用戶使用的系統。開發能夠迅速適應新商業需求的靈活系統。設計便于外包開發的系統架構。開發具有高安全性的系統，能夠抵御各種攻擊。開發易于最終用戶調整和配置的系統。探索測試、驗證和維護最終用戶開發系統的有效方法。1.5參考1.1.2節討論的應用類型，舉例說明為什么設計和開發不同類型的應用需要特殊化的軟件工程技術。不同應用類型需要使用不同的開發技術，原因如下：成本與變更頻率。一些系統（如消費設備中的嵌入式系統）更改成本極高；其他系統則需要頻繁變化以響應需求變化（如業務系統）。更改成本極高的系統需要進行廣泛的前期分析以確保需求一致性，并進行廣泛的驗證以確保系統符合規格。這對于快速變化的系統來說并不具成本效益。最重要的“非功能”需求。不同系統對非功能需求的優先級不同。例如，飛機中的實時控制系統以安全為主要優先級；交互式游戲則以響應性和可用性為優先級。用于實現安全的技術不適用于交互式游戲；游戲所需的廣泛用戶界面設計在安全關鍵的控制系統中不需要。軟件生命周期和交付計劃。一些軟件系統的生命周期相對較短（如許多基于網絡的系統），而其他系統的生命周期可達數十年（如大型指揮和控制系統）。某些系統需要快速交付以便實用。開發短生命周期、快速交付系統的技術（如使用腳本語言、原型開發等）不適用于需要長期支持的系統，這些系統需要采用允許長期支持的技術，如設計建模。1.8討論一下職業工程師是否應該和醫生或律師一樣頒發資格證書。這些是可能的討論要點——任何討論都會涉及廣泛的范圍，并觸及諸如職業操守等其他問題。認證的優勢認證向雇主表明具備某種最低水平的能力。認證提升了職業的公眾形象。認證通常意味著建立和檢查教育標準，因此是一種確保課程質量的機制。認證在爭議發生時意味著責任。認證機構可能被接受為在國家和國際層面代表該職業的權威認證可能提高軟件工程師的地位，并吸引特別有能力的人進入該職業。認證的劣勢認證往往導致保護主義，認證成員往往不保護他人免受批評。認證并不保證能力，僅表明在認證時達到了最低標準。認證費用高昂，會增加個人和組織的成本。認證往往會抑制變革。在技術發展非常迅速的領域，這是一個特別的問題。第二章軟件過程2.1針對以下每個系統，請推薦最合適的可以管理其開發的基礎的通用軟件過程模型，按照所開發系統的類型給出你的理由。一個汽車中的防抱死剎車控制系統；一個支持軟件維護的虛擬現實系統；一個準備替換現有系統的大學會計系統；一個交互式的旅行規劃系統，可以幫助用戶以最小的環境影響規劃旅程。1.防抱死制動系統：這是一個安全關鍵系統，因此在實施前需要大量的前期分析。它肯定需要一個計劃驅動的開發方法，要求進行仔細的需求分析。因此，瀑布模型是最適合使用的方法，或許可以在不同開發階段之間進行正式轉換。2.虛擬現實系統：這是一個需求會變化并且具有大量用戶界面組件的系統。增量開發可能是最合適的模型，或許需要一些UI原型開發。可以使用敏捷過程。3.大學會計系統：這是一個需求相對明確的系統，并且將在與許多其他系統（如研究經費管理系統）配合使用的環境中使用。因此，基于重用的方法可能是適合的。4.交互式旅行規劃系統：這是一個具有復雜用戶界面的系統，但必須穩定可靠。由于系統需求會隨著用戶實際使用經驗的積累而變化，因此增量開發方法是最合適的。2.3考慮圖2-3中所示的集成和配置過程模型。為什么在這個過程中要重復需求工程活動?您需要重復需求工程活動，因為根據系統/組件的可重用性來調整系統需求是至關重要的。這些活動包括：1.初始活動：了解系統功能并概述系統應執行的廣泛需求。應以足夠詳細的方式表達這些需求，以便您可以據此決定某個系統/組件是否滿足某些需求并能夠重用。2.詳細需求工程活動：一旦選定了系統/組件，您需要進行更詳細的需求工程活動，以檢查重用軟件的功能是否滿足業務需求，并識別所需的更改和添加。2.4為什么在需求工程過程中區分用戶需求開發和系統需求開發是重要的?用戶需求和系統需求之間存在根本差異，這意味著應該分別考慮它們。用戶需求旨在從用戶角度描述系統的功能和特性，用戶理解這些需求至關重要。它們應該用自然語言表達，可能不會表達得非常詳細，以允許一些實現的靈活性。參與該過程的人員必須能夠理解用戶的環境和應用領域。系統需求比用戶需求詳細得多，旨在成為系統的精確規范，可能是系統合同的一部分。它們也可能用于開發外包的情況，開發團隊需要完整的規范說明應該開發什么。系統需求是在用戶需求確定后制定的。2.6為什么在復雜系統中變化是不可避免的?舉出一些有助于預測可能的變化并使所開發的軟件更適應變化的軟件過程活動的例子(除了原型和增量交付之外)。系統必須變化，因為當它們安裝在環境中時，環境會適應它們，這種適應自然會產生新的/不同的系統需求。此外，系統的環境是動態的，隨著業務、業務目標和業務政策的變化不斷產生新需求。除非系統適應這些需求，否則其功能將與支持業務所需的功能脫節，從而變得不那么有用。支持變化的過程活動示例包括：記錄需求的理由：記錄需求被包含的原因，這有助于未來的變化。需求可追溯性：顯示需求之間以及需求與系統設計/代碼之間的依賴關系。設計建模：設計模型記錄軟件的結構。代碼重構：通過提高代碼質量，使其更易于變更。2.9指出SEI的能力成熟度框架中所包含的過程評估和改進方法的兩個優點和兩個缺點流程改進框架的優勢這種方法提供了一種衡量流程當前狀態的手段，以及一種引入流程改進的有序方法。它作為借鑒其他人在流程改進方面的經驗的一種方式非常有用。流程改進框架的劣勢與任何測量系統一樣，存在一種傾向，即為了提升測量結果而進行改進，而不是專注于滿足實際業務目標的改進。成熟度模型方法操作起來成本高昂且官僚。它并不真正適合那些采用敏捷開發方法。第三章敏捷軟件開發3.2敏捷方法所基于的原則是如何加快軟件的開發和部署的?敏捷開發的基本原則是：個人和交互勝過過程和工具。通過利用個人技能和能力，并確保開發團隊了解彼此的工作，避免了正式溝通和過程保證的開銷。這意味著團隊可以專注于工作軟件的開發。工作軟件勝過全面的文檔。這有助于加速開發，因為不會花費時間開發、檢查和管理文檔。相反，程序員的時間集中在代碼的開發和測試上。客戶協作勝過合同談判。敏捷開發人員認為，與其花費時間開發、分析和談判要包含在系統合同中的需求，不如在開發過程中直接從客戶那里獲得關于需求的反饋更有效。這允許比需要合同的情況更早地開發和交付有用的功能。響應變化勝過遵循計劃。敏捷開發人員正確地認為，對變化做出響應比遵循基于計劃的過程更有效，因為無論使用什么過程，變化都是不可避免的。更改計劃以適應變化會產生巨大的開銷，而計劃的不靈活性意味著可能會做一些后來被丟棄的工作。3.3極限編程將用戶需求表達為故事，每個故事寫在卡片上。討論這種方法對于需求描述的優點和缺點故事的優點：它們代表了經常出現的真實情況，因此系統將支持最常見的用戶操作。用戶很容易理解和評論故事。它們代表了功能的增量——實現一個故事為用戶提供了一些價值。故事的缺點：它們可能不完整，而且它們的非正式性質使得這種不完整性難以察覺。它們關注的是功能需求，而不是非功能需求。當使用故事時，不可能表示性能和可靠性等橫切系統需求。系統架構和用戶故事之間的關系不清楚，因此架構設計很困難。3.6比較Scrum方法和傳統的基于計劃的方法中的項目管理(如第23章所介紹的)。你的比較應該基于每種方法對項目人員分配計劃、項目成本估算、維持團隊延續性、管理項目團隊成員變化等方面的有效性1.項目人員分配計劃ScrumScrum采用非正式的方式進行人員分配。團隊成員會根據產品待辦事項列表中的功能特性，如果認為自己的專長合適，就會“競標”來實施這些功能。或者，Scrum主管也可以分配任務。在Scrum中，沒有正式的機制來規劃具備非常特殊專長的項目成員臨時分配到一個團隊中。這種需求必須由Scrum主管識別，并且他或她需要討論如何提供這些專長。基于計劃的開發項目計劃用于識別系統要交付的部分，并在需求文檔中加以說明。然后可以識別出每個部分所需的專長，并基于此規劃人員分配到項目中。2.項目成本估算Scrum項目成本是基于軟件的預期交付日期和Scrum團隊中的人員來估算的。系統的功能會進行調整，以確保在原始成本估算內總能交付一些可工作的系統。當然，這可能對客戶來說不夠充分，他們需要參與重新安排系統交付的時間。基于計劃的開發項目成本基于需求文檔中指定的功能性以及系統的非功能性需求進行分析。成本可能會根據團隊規模和交付時間進行調整。通常情況下，成本會被低估，最終項目的實際成本會遠高于最初的估算。團隊成員的平均成本是默認的。3.維持團隊凝聚力Scrum團隊成員每天會面，無論是面對面還是通過電子方式。鼓勵廣泛的非正式討論和溝通。團隊成員從項目待辦事項中協商工作任務。這一切都促成了產品所有權的共同感和一個非常有凝聚力的團隊。基于計劃的開發團隊凝聚力是項目經理的責任，他或她必須采取明確的行動來促進這一點。總體方法依賴于相對不頻繁的正式會議，這并不利于發展一個有凝聚力的團隊。4.管理項目團隊成員的變動Scrum這是Scrum中很少討論的話題，但卻是一個根本性問題，因為很多信息是非正式的，依賴于人們記住已經達成的共識。當有人離開時，尤其是在很少有項目文檔的情況下，很難讓新成員快速上手。基于計劃的開發項目管理計劃圍繞專長而不是個人制定，并且項目文檔應該是可用的。因此，如果團隊成員離開，那么具有相當專長的新成員可以閱讀已完成的工作，在理解之后，應該能夠作為替代者。3.8為什么在將敏捷方法規模化應用到由分布式開發團隊開發的更大項目中的時候，有必要從基于計劃的方法中引入一些方法和文檔?當大型團隊開發軟件時，項目規劃通常至關重要。這包括確保在開發過程中需要時，可以獲取合適的人員，以及確保由不同團隊開發的系統不同部分能夠協調交付。這意味著如果部分A依賴于部分B，時間表應確保在部分A開發之前先完成部分B。需求分析和文檔化對于決定如何分配工作并確保每個團隊對其他團隊的工作有一定的了解非常重要。設計文檔，尤其是接口規范，對于團隊能夠獨立開發而不需要接觸正在開發中的軟件非常重要。風險管理可能需要確保所有團隊了解面臨的風險，并能夠組織工作以最小化這些風險。風險管理也可能有助于應對不同團隊采用的不同交付時間表3.10讓一個用戶緊密參與軟件開發團隊的一個問題是他們會被“同化”。也就是說，他們會采用開發團隊的觀點，并丟掉關于用戶需要的觀點。提出3種有利于避免這一問題的方法，并討論每種方法的優點和缺點讓多個用戶參與到開發團隊中。優點是您可以獲得關于問題的多個視角，更好地覆蓋用戶任務，從而獲得需求，并且不太可能有非典型用戶。缺點是成本、讓用戶參與的困難以及可能的用戶沖突。改變參與團隊的用戶。優點同樣是多個視角。缺點是每個用戶都需要時間才能發揮生產力，以及可能來自不同用戶的相互沖突的需求。與其他用戶代表驗證用戶建議。優點是對建議進行獨立檢查；缺點是這會減慢開發過程，因為進行檢查需要時間。第四章需求工程4.2找出下面這段售票系統需求陳述中有二義或遺漏的地方：一個自動化的售票機銷售火車票。用戶選擇他們的目的地并輸入信用卡和個人身份信息。機器吐出火車票，而用戶的信用卡賬戶會進行付款。當用戶按下啟動按鈕，一個顯示候選目的地的菜單被激活，同時系統向用戶顯示一條選擇目的地以及所需要的票的類型的消息。一旦選擇了目的地，系統顯示票價并請客戶輸入他們的信用卡。檢查信用卡是否有效之后，系統請用戶輸入個人身份(PIN碼)。信用卡交易確認后，票被吐出。存在的歧義和遺漏包括：客戶是否可以一次性購買多個同一目的地的車票，還是必須逐個購買？如有誤操作，客戶能否取消購票請求？若輸入無效卡，系統應如何處理？若客戶在選擇目的地前就插入卡（類似于ATM機操作），會出現什么情況？若客戶想購買去往其他目的地的車票，是否需要再次按下“開始”按鈕？系統是否僅提供從機器所在車站出發的直接連接車站的車票，還是包括所有可能的目的地？4.4為售票系統書寫一組非功能性需求，明確所期望的可靠性和響應時間。售票系統的可能非功能需求包括：在任何一天的06:00到23:00之間，整個系統的停機時間不應超過5分鐘。在任何一天的06:00到23:00之間，系統故障后的恢復時間不應超過2分鐘。在任何一天的23:00到06:00之間，整個系統的停機時間不應超過20分鐘。所有這些都是可用性要求——請注意，這些要求根據一天中的時間而有所不同。在大多數人旅行時發生的故障比在客戶很少時發生的故障更不可接受。在客戶按下機器上的按鈕后，顯示器應在0.5秒內更新。在收到信用卡驗證后，出票時間不應超過10秒。在驗證信用卡時，顯示屏應為客戶提供狀態消息，表明正在進行活動。這告訴客戶驗證這種可能耗時的活動仍在進行中，而且系統并沒有簡單地失敗。售票請求的最大可接受故障率為1:10000。請注意，這實際上是ROCOF。我沒有指定可接受的錯誤票數量，因為這取決于系統是否包括允許記錄客戶請求的跟蹤設施。如果是這樣，相對較高的故障率是可以接受的，因為客戶可以投訴并獲得退款。如果沒有，只有非常低的故障率是可以接受的。顯然，這些要求是任意的，還有許多其他可能的答案。您只需檢查它們的可信度。4.6一個負責起草系統需求規格說明的工程師，應當如何記錄功能性需求和非功能性需求之間的關系?請給出你的建議追蹤功能需求和非功能需求之間的關系是復雜的，因為非功能需求往往是針對整個系統的，而不是單一功能或一組功能。一種可行的方法是明確指出與特定功能需求相關的系統級非功能需求，并將它們單獨羅列。所有對每個功能需求有影響的系統需求都應被詳細列出。可以通過如下表所示的方式，將它們聯系起來。功能要求相關的非功能性系統需求非功能性需求系統應提供一種操作，允許操作員打開釋放閥，將蒸汽排入大氣中。安全要求：如果在蒸汽發生裝置上進行維護工作，則不得釋放蒸汽。時間要求：操作員開始行動后，閥門必須在2秒內完全打開。在這個例子中，請注意系統級非功能需求通常會比針對特定操作的定時要求具有更高的優先級。顯然，任何能夠合理地將功能需求和非功能需求聯系起來的方法都是可以接受的。4.7根據你自己關于ATM機使用的經驗，開發一組可以作為理解ATM機系統需求的基礎的用況有多種不同類型的自動取款機，所以，顯然，不可能有一套確定的用例可以產生。然而，我期望看到涵蓋主要功能的用例，如提取現金、顯示余額、打印對賬單、更改密碼和存入現金。用例描述應該描述所涉及的參與者、輸入和輸出、正常操作和異常情況。取款：參與者：客戶，ATM，會計系統輸入：客戶的卡，PIN，銀行賬戶詳情輸出：客戶的卡，收據，銀行賬戶詳情正常操作：客戶將卡插入機器。他/她被提示輸入PIN，并在鍵盤上輸入。如果正確，他/她將看到一系列選項。選擇“取款”選項。客戶被提示輸入所需現金金額并輸入金額。如果賬戶中有足夠的資金，現金將被分配，打印收據并更新賬戶余額。在分配現金之前，卡片被退還給客戶，機器提示客戶取卡。異常：無效卡。卡片被機器保留；建議客戶尋求建議。PIN錯誤。請求客戶重新輸入PIN。如果3次嘗試后仍然錯誤，卡片被機器保留，并建議客戶尋求建議。余額不足。交易終止。卡片退還給客戶。顯示余額：參與者：客戶，ATM，會計系統輸入：客戶的卡，PIN，銀行賬戶詳情輸出：客戶的卡正常操作：客戶使用卡和PIN進行身份驗證，如“取款”并選擇“顯示余額”選項。他們賬戶的當前余額顯示在屏幕上。卡片退還給客戶。異常：無效卡。如“取款”所述PIN錯誤。如“取款”所述打印對賬單：參與者：客戶，ATM，會計系統輸入：客戶的卡，PIN，銀行賬戶詳情輸出：客戶的卡，打印的對賬單正常操作：客戶使用卡和PIN進行身份驗證，如“取款”并選擇“打印對賬單”選項。他們賬戶的最后五筆交易被打印出來。卡片退還給客戶。異常：無效卡。如“取款”所述PIN錯誤。如“取款”所述更改PIN：參與者：客戶，ATM輸入：客戶的卡，PIN輸出：客戶的卡正常操作：客戶進行身份驗證，如“取款”并選擇“更改PIN”選項。他/她被提示兩次輸入新PIN。輸入的PIN應該相同。客戶的PIN被加密并存儲在卡上。卡片退還給客戶。異常：無效卡。如“取款”所述。PIN錯誤。如“取款”所述。PIN不匹配。邀請客戶重復過程以重置他/她的PIN。存款：參與者：客戶，ATM，會計系統輸入：客戶的卡，PIN，銀行賬戶詳情，要存款的現金輸出：客戶的卡，收據正常操作：客戶使用卡和PIN進行身份驗證，如“取款”并選擇“存款”選項。客戶被提示輸入要存款的現金金額并輸入金額。然后，他或她將獲得一個存款信封，將現金放入其中然后將其退還給機器。客戶的賬戶余額被更新為存款金額，但這被標記為未清算資金，直到檢查后才清算。發出收據，并退還客戶的卡。異常：無效卡。如“取款”所述。PIN錯誤。如“取款”所述。在信封發出1分鐘內未存款。交易終止。卡片退還給客戶。4.9當系統面臨必須滿足的緊急修改時，系統中的軟件可能不得不在相應的需求變更被批準前就進行修改。建議一個實施這類修改的過程模型，使之可以確保需求文檔和系統實現不會變得不一致下圖展示了一個用于保持需求文檔與系統一致性的變更流程。該流程應對變更設定優先級，確保緊急變更得到及時處理，并在修改系統需求時優先考慮這些變更。變更后的代碼應作為最終變更流程的輸入。同時，當有更多時間進行分析時，可能會發現更優的變更方法。分析變更請求[緊急變更]修改程序代碼記錄代碼更改重新提交變更請求以待分析變更請求數據庫[非緊急變更]評估需求影響更改需求設計/修改代碼更新變更請求數據庫第五章系統建模5.2如何使用一個已經存在的系統模型?解釋為什么這樣一個系統模型并不一定是完整和正確的。如果你在開發一個新系統的模型情況還是這樣嗎?您可能會創建并使用一個已經存在的系統的模型，原因包括：為了理解和記錄現有系統的架構與運作方式。作為討論對該系統可能變更的焦點。為了指導系統的重新實施。除非您的目的是完全記錄現有系統的操作，否則您不需要一個完整的模型。在這種情況下，模型的目的是幫助您處理系統的某些部分，因此只需要對這些部分進行建模。此外，如果模型被用作討論焦點，您可能不會對細節感興趣，因此可以在模型中忽略系統的部分。一般來說，對于新系統的模型也是如此，除非正在進行基于模型的開發，這種情況下需要一個完整的模型。您可能需要完整模型的另一種情況是，根據合同要求，必須將此類模型作為系統文檔的一部分產生。5.5開發一個順序圖來描述一所大學中的一個學生注冊一門課程時所涉及的交互。課程可能有人數限制，因此注冊過程必須包含針對是否還有空位的檢查。假設學生通過訪問一個電子課程目錄來找出可選的課程5.6仔細觀察你所使用的電子郵件系統中消息和郵箱是如何表示的。建模為了表示郵箱和電子郵件消息而需要在系統實現中使用的對象類Mailmessage（郵件信息）:sender（發送者）receiverlist（接收者列表）cclist（抄送列表）bcclist（密送列表）date（日期）subject（主題）returnpath（返回路徑）routinginfo（路由信息）spaminfo（垃圾信息）mailer（郵件發送者）messageinfo（消息信息）messagebody（消息主體）attachments（附件）signature（簽名）read（）reply（）replyall（）print（）forward（）send（）Mailbox（郵箱）:name（名稱）pathname（路徑名）creationdate（創建日期）changedate（更改日期）messages（消息）unreadmessages（未讀消息）flaggedmessages（已標記的消息）deletedmessages（已刪除的消息）movemessage（）copymessage（）deletemessage（）fetchmail（）（提取郵件）create（）rename（）delete（）5.7基于你對于銀行ATM機的經驗，畫一個活動圖來建模當一個客戶從機器中提取現金時所涉及的數據處理5.10你是一個軟件工程經理，你的團隊中的一個資深成員提出應當使用模型驅動的工程來開發一個新系統。你在決定是否應該將該方法引入軟件開發中時要考慮哪些因素?在做出決策時，應考慮以下幾個因素：團隊對UML和MDA的掌握程度（團隊是否已具備相關專業知識，還是需要接受大量培訓）支持MDA的工具有效性和成本（工具是否已內部可用，或需另行購買。它們是否滿足正在開發的軟件類型的需求）軟件的預期使用壽命（MDA更適用于長期使用的系統）對高性能或高吞吐量的需求（MDA依賴代碼生成，可能不如手工編碼高效）采用MDA的長遠利益（這種方法是否能真正節省成本）開發團隊的熱情和承諾（團隊成員是否都支持這一新方法）在編寫規范之前可能必須設計架構，以提供一種構建規范和同時開發不同子系統規范的方法，以便允許分包商制造硬件，并為系統成本提供模型。第六章體系結構設計6.1當描述一個系統時，為什么必須要在得到完整的需求規格說明之前就開始系統體系結構的設計?在設計規范之前，可能需要先制定架構。這樣做是為了提供一個清晰的方法來結構化規范，并允許同時開發各種子系統規范。這樣的做法有助于分包商制造硬件，并且為系統成本估算提供了一個模型。6.3在為一個可用性和信息安全需求都是最重要的非功能性需求的系統設計體系結構時，為什么可能會出現設計沖突?從根本上說，為了提供可用性，架構中需要有（a）復制的組件，以便在一個組件失敗時，可以立即切換到備份組件。同時，還需要有正在處理的數據的多個副本。安全性要求最小化數據副本的數量，并在可能的情況下，采用每個組件只了解完成其工作所需的信息的架構。這減少了入侵者訪問數據的機會。因此，可用性（復制，多個副本）和安全（專業化，最小副本）之間存在根本的建筑沖突。系統架構師必須在這些根本對立的要求之間找到最佳的折衷方案。6.7將要開發一個信息系統以用于維護關于一個公用事業公司所擁有資產(例如建筑、車輛、設備)的信息。希望該系統可以在新的資產信息可用時，在現場工作的員工可以使用移動設備進行更新。該公司有幾個已有的資產數據庫，它們應當通過該系統進行集成。基于圖6-18中所示的通用信息系統體系結構，為這個資產管理系統設計一個分層體系結構。1.BrowserUI和MobileUI：BrowserUI：瀏覽器用戶界面MobileUI：移動設備用戶界面2.中間層（從左到右）：Mobiledevicemanagement：移動設備管理Formsmanager：表單管理器Alertmanager：警報管理器Authenticationandauthorization：認證和授權3.最下面一層（從左到右）：Databasesearch：數據庫搜索Databasealerts：數據庫警報Databasebrowser：數據庫瀏覽器Databasequerymanagement：數據庫查詢管理Buildingsdatabase：建筑物數據庫Equipmentdatabase：設備數據庫Infrastructuredatabase：基礎設施數據庫Vehicledatabase：車輛數據庫6.8使用這里所介紹的語言處理系統通用模型，設計一個系統的體系結構，該系統接受自然語言命令，并將其翻譯為數據庫查詢語言(例如SQL)。Dictionary:字典Abstractsyntaxtree:抽象語法樹Lexicalanalysis:詞匯分析Partofspeechtagger:詞性標注器Commandparser:命令解析器Parameteranalysis:參數分析SQLcodegenerator:SQL代碼生成器6.9使用如圖6-18中所示的信息系統基本模型，針對一個面向移動設備用于顯示某個特定機場航班到達和起飛信息的應用，建議其中應該包含哪些構件?這是一個混合系統，系統的某些元素托管在遠程服務器上，而某些元素則內置在應用程序中。您需要考慮信息系統的各個層次，并識別可能包含在每個層次中的組件。這些組件的例子可能包括：第1層（數據庫級別）：航班數據庫；航班狀態數據庫；機場信息；第2層（信息檢索級別）：狀態管理；航班管理；搜索；第3層（用戶交互級別）：認證；會話管理；表單處理（）第4層（用戶界面）：應用程序UI然后，您需要決定哪些信息系統元素應該在移動設備上托管，哪些應該遠程托管。1.數據庫級別很明顯，試圖在應用程序上托管主要的數據庫組件是沒有意義的，因此在應用程序中，這些被一個數據庫查詢組件所替代，該組件提供了對這些數據庫的訪問權限。2.信息檢索級別應用程序中需要一個搜索組件，但這實際上應該是運行在服務器上的更廣泛數據庫搜索的前端。用戶感興趣的航班及其狀態信息必須在應用程序中本地收集和管理。3.用戶交互級別這也必須在應用程序中處理，盡管它基于存儲的信息，例如認證依賴于存儲用戶的憑據，并在調用應用程序時自動進行認證。4.用戶界面級別僅在應用程序中實現第七章設計和實現7.1使用圖7-3中所示的表格化表示法對氣象站用況“報告狀態和重配置”進行描述。你應當對這里所需要的功能做出合理的假設系統：氣象站用況：報告狀態參與者：氣象信息系統、氣象站數據：氣象站向氣象信息系統發送狀態更新，提供有關其儀器、計算機和電源供應的狀態信息。激勵：氣象信息系統與氣象站建立衛星鏈接并請求狀態信息。響應：狀態摘要上傳到氣象信息系統備注：系統狀態通常與天氣報告同時被激勵。系統：氣象站用況：重新配置參與者：氣象信息系統、氣象站數據：氣象信息站向氣象站發送重新配置命令。這將其置于遠程控制模式，在該模式下，可以從遠程系統發送進一步的命令來更新氣象站軟件。激勵：來自氣象信息系統的命令。響應：確認系統處于遠程控制模式備注：在必須安裝軟件更新時偶爾被激勵。7.3使用UML對于對象類的表示法設計下列對象類，識別屬性和操作。根據你自己的經驗來決定與這些對象相關聯的屬性和操作。一個移動電話或者平板電腦上的消息通信系統一個個人計算機的打印機一個個人音樂系統一個銀行賬戶一個圖書館目錄這里有許多可能的設計，并且可以給對象增加大量的復雜性。然而，我真正尋找的只是簡單對象，這些對象封裝了這些工件的主要需求。可能的設計顯示在下面的圖中。1.Messagingsystem（消息系統）message(status,sender,length,body)（消息（狀態、發送者、長度、主體））messagelist（消息列表）attachments（附件）create_message()（創建消息）send_message()（發送消息）copy_message()（復制消息）select_message()（選擇消息）edit_message()（編輯消息）add_to_list()（添加到列表）remove_from_list()（從列表中刪除）view_attachment()（查看附件）notify()（通知）2.Librarycatalogue（圖書館目錄）Publicationrecords（出版物記錄）Transactions（交易）Datecreated（創建日期）Dateupdated（更新日期）Permissions（權限）keywordindex（關鍵詞索引）newentry()（新條目）editentry()（編輯條目）deleteentry()（刪除條目）search()（搜索）create_index()（創建索引）editpermissions()（編輯權限）recordtransaction()（記錄交易）3.Musicsystem（音樂系統）songstore（歌曲庫）playlists（播放列表）volume（音量）nowplaying（正在播放）recentlyplayed（最近播放）display（顯示）batterylevel（電池電量）play()（播放）stop()（停止）selectplaylist()（選擇播放列表）selectsong()（選擇歌曲）search()（搜索）randomplay()（隨機播放）repeat()（重復）changevolume()（改變音量）displaystatus()（顯示狀態）4.Printer（打印機）document（文檔）tonerlevel（墨粉水平）paperstatus（紙張狀態）errorstatus（錯誤狀態）display（顯示）setup_printer()（設置打印機）print()（打印）cancelprintjob()（取消打印作業）selftest()（自檢）startup()（啟動）shutdown()（關閉）5.BankAccount（銀行賬戶）accountnumber（賬號）accounttype（賬戶類型）dateopened（開戶日期）dateclosed（關閉日期）balance（余額）transactionlist（交易列表）overdraftlimit（透支限額）open()（打開）close()（關閉）credit()（信貸）debit()（借記）showbalance()（顯示余額）editoverdraftlimit()（編輯透支限額）addtransaction()（添加交易）listtransactions()（列出交易）7.7畫一個順序圖展示小組日程系統在一組人正在安排一個會議時對象間的交互Organizer（組織者）G:GroupDiary（G組日記）D1:Diary（D1日記）D2:Diary（D2日記）D3:Diary（D3日記）Setup(window,participants)（設置（窗口，參與者））getAvail(W1,P1)（獲取可用性（W1，P1））Availdates(p1)（可用日期（p1））getAvail(W2,p2)（獲取可用性（W2，p2））Availdates(p2)（可用日期（p2））getAvail(W3,p3)（獲取可用性（W3，p3））Availdates(p3)（可用日期（p3））reserve(date)（預訂（日期））confirm(date)（確認（日期））report(window)（報告（窗口））[Datesavailable]：日期可用[Nodatesavailable]：沒有可用日期在上述圖表中，假設會議有3名參與者，包括一名組織者。組織者提出一個會議時間“范圍”，涉及相關參與者。團隊日歷會依次與每位參與者的日歷進行協調，根據他們的時間安排來調整這個范圍。例如，如果組織者提議的會議時間是6月18日至19日，團隊日歷首先查看組織者的日歷（D1），確認這些日期是否有空。然后，團隊日歷將這個確認后的時間范圍告知參與者D2的日歷，而不是最初提議的時間范圍。如果在這個時間范圍內沒有找到大家都有空的日期，系統會通知組織者。如果有可行的日期，系統會選定一個日期，更新所有相關日歷，并通知組織者確認。7.9舉例解釋為什么一組人在開發一個軟件產品時配置管理系統很重要配置管理的目標有兩個：一是確保不同開發人員對系統的更改不會相互影響；二是保證能夠隨時創建系統的特定版本。如果沒有配置管理，就很難追蹤每位開發人員對代碼所做的修改，而且后一個程序員的改動可能會覆蓋前一個程序員的成果。比如，一個程序員可能修改了一個組件來提升性能，而另一個程序員可能修復了該組件的一個功能錯誤。如果沒有配置管理，最后提交代碼的開發者可能會覆蓋之前的改動，導致之前的修改丟失。此外，一個系統通常由多個組件組成，每個組件都有多個版本，每個版本都有其特定用途。例如，可能存在適用于Windows、Linux和MacOS等不同平臺的系統版本。這些版本中有些組件是特定的，有些是共享的，如果沒有配置管理工具的幫助，組裝這些版本很容易出錯。一旦在某個版本中錯誤地包含了不合適的組件，就很可能導致軟件后續出現故障。7.10一個小公司開發了一個可以專門為每個客戶專門配置的專業軟件產品。新客戶通常都有一些特定的需求要加入到系統中，他們會為這些需求的開發和集成支付費用。該軟件公司有一個機會去投標一個新項目，這將會使客戶基數翻倍。新客戶希望參與一些系統的配置。解釋為什么在這種情況下讓這個軟件產品開源對于擁有該軟件的公司而言可能是個好主意開源的主要好處在于它將開發開放給廣泛的開發人員，從而加速產品的開發和調試。如果客戶群翻倍，小公司將面臨巨大壓力，因為他們需要招募大量新員工，因此通過開源可以降低擴展成本。在這種情況下，由于產品專門針對不同用戶的需求，擁有該軟件的公司仍然可以向這些用戶收取對系統進行更改的費用。因此，銷售軟件的收入損失可以通過增加的服務更多客戶的努力來彌補。此外，大公司通常不愿意從可能倒閉的小公司購買產品。某種程度上，開源為客戶提供了保障，即使原始軟件所有者不可用，他們也可以獲得源代碼，從而繼續維護他們的系統。最后，開源可能會增加人們對公司產品的了解，從而吸引更多客戶。第八章軟件測試8.2為什么測試只能表明錯誤的存在，而不是顯示沒有錯誤存在?假設對一個程序進行窮舉測試，即檢查每個可能的有效輸入，是不可能的（對于所有但微不足道的程序都是如此）。測試用例要么沒有揭示程序中的錯誤，要么揭示了程序錯誤。如果它們揭示了程序錯誤，那么它們就證明了存在錯誤。然而，如果它們沒有揭示錯誤，這僅僅意味著它們已經執行了一個對于所選輸入來說沒有錯誤的代碼序列。對同一代碼序列的下一次測試（使用不同的輸入）可能會揭示錯誤。8.4你被安排測試“Paragraph”對象中一個名為catWhiteSpace的方法，該方法在一個段落里面將所有連續的空格符替換成單個的空格符。為這個例子確定測試劃分，并且為catWhiteSpace方法設計一組測試。測試分為以下幾個部分：只包含單個空格的字符串。字符串中間有連續空格。字符串開頭或結尾有連續空格。測試示例包括：Thequickbrownfoxjumpedoverthelazydog（單個空格）Thequickbrownfoxjumpedoverthelazydog（中間空格數量不同）“Thequickbrownfoxjumpedoverthelazydog”（開頭有空格序列）“Thequickbrownfoxjumpedoverthelazydog”（結尾有空格序列）“Thequickbrownfoxjumpedoverthelazydog”（開頭兩個空格）“Thequickbrownfoxjumpedoverthelazydog”（開頭多個空格）“Thequickbrownfoxjumpedoverthelazydog”（結尾兩個空格）“Thequickbrownfoxjumpedoverthelazydog”（結尾多個空格）8.5什么是回歸測試?解釋該如何使用自動化測試以及JUnit這樣的測試框架來簡化回歸測試回歸測試是在開發新功能或更改系統時，對已經實現的功能運行測試的過程。回歸測試檢查系統更改是否沒有給先前實現的代碼引入問題。自動化測試和測試框架（如JUnit）極大地簡化了回歸測試，因為每次更改時都可以自動運行整個測試集。自動化測試包括它們自己的檢查，以確定測試是否成功，否則檢查回歸測試成功與否的成本很低。8.7編寫一個可以用于為野外氣象站系統設計測試的場景一個可能的氣象站系統高級測試場景是：約翰是一名氣象學家，負責為明尼蘇達州制作氣象地圖。這些地圖是使用氣象繪圖系統從自動收集的數據中生成的，它們顯示了明尼蘇達州天氣的不同數據。約翰選擇要生成地圖的區域、地圖的時間段，并請求生成地圖。在創建地圖時，約翰運行一個氣象站檢查，檢查所有遠程收集的氣象站數據，并查找數據中的間隙——這意味著遠程氣象站存在問題。這里有許多可能的替代場景。它們應該確定所涉及的參與者的角色，并討論該角色可能執行的典型任務。8.8你是如何理解術語“壓力測試”的?談一談如何對Mentcare系統進行壓力測試壓力測試是指故意將系統的負載增加到超過其設計限制，以觀察它如何應對高負載。系統應該優雅地降級，而不是崩潰Mentcare系統被設計為客戶端-服務器系統，具有下載到客戶端的可能性。要對系統進行壓力測試，需要安排(a)許多不同的診所同時嘗試訪問系統，以及(b)向系統中添加大量記錄。這可能涉及使用模擬系統來模擬多個用戶第九章軟件演化9.1為什么在現實環境中使用的軟件系統必須進行變更，否則就會逐漸失去其作用?系統必須改變或逐漸變得不那么有用，原因有以下幾點：系統的存在改變了其環境中的工作方式，這產生了新的需求。如果這些需求得不到滿足，系統的有用性就會下降。使用該系統的業務會根據市場力量的變化而變化，這也會產生新的系統需求。系統的外部法律和政治環境發生變化，產生了新的需求。出現了提供顯著好處的新技術，系統必須改變以利用這些技術。9.4什么情況下一個組織會決定廢棄一個被評估為高質量和商業價值的系統?軟件可能被廢棄和重寫的情況示例包括：當維護成本高且組織決定投資新硬件時。無論如何，這都將涉及大量的轉換成本，因此可能會借機重寫軟件。當業務流程發生變化并且需要新的軟件來支持該流程時。當用于開發軟件的工具和語言的支持不可用時。這在早期的4GL中是一個特別的問題，在許多情況下，供應商已經不再營業。根據當地情況，還有其他原因可能導致軟件被廢棄。9.5對遺留系統演化的策略選擇是什么?什么時候你通常會替換整個或部分系統而不是繼續進行軟件維護?遺留系統演進的戰略選擇是：放棄對系統的維護，并用新系統替換它。繼續維護系統。進行一些再工程（系統改進），使系統更易于維護并繼續維護。將系統的現有功能封裝在包裝器中，并通過編寫調用現有系統作為組件的新代碼來添加新功能。將系統分解為獨立的單元，并將它們包裝為組件。這與上述解決方案類似，但在系統的使用方式上提供了更大的靈活性。通常，在以下情況下會選擇替換選項：系統的硬件平臺正在被替換，公司希望標準化一些與當前系統不一致的開發方法，某些主要子系統正在被替換（例如數據庫系統），或者現有系統的技術質量較低，并且目前沒有用于再工程的工具。9.7你是公司的一名軟件項目經理，專門從事離岸石油業的軟件開發，你現在需要發現影響公司軟件系統的維護性的因素。你該如何設置一個程序去分析維護的過程以及提出并度量軟件的維護指標?這是一個非常開放的問題，有許多可能的答案。基本上，學生應該確定影響可維護性的因素，例如（程序和數據的復雜性、有意義的標識符的使用、編程語言、程序文檔等）。然后，他們應該建議如何在維護成本已知的現有系統中評估這些因素，并討論交互問題。方法應該是發現那些維護成本特別高的程序單元，并評估這些組件和其他組件的成本因素。然后檢查相關性。其他因素可能導致異常，因此應該在問題組件中尋找這些因素。9.8簡要描述3種不同類型的軟件維護。為什么有時候很難區分它們?軟件維護的三種主要類型是：糾錯維護或故障修復。對系統進行的更改是為了修復報告的故障，這些故障可能是程序錯誤或規格錯誤或遺漏。適應性維護或環境適應。更改軟件以使其適應環境的變化，例如其他軟件系統的變化。完善性維護或功能添加。這涉及向系統添加新的功能或特性。有時它們很難區分，因為同一組更改可能涵蓋所有三種類型的維護。例如，系統中報告的故障可能通過升級其他一些軟件來修復，然后使系統適應使用這個新版本（糾錯+適應）。新軟件可能具有額外的功能，并且作為適應性維護的一部分，可能會添加新的特性以利用這一點。第二十二章項目管理22.2解釋最好的程序設計者為什么不一定能成為最好的軟件管理者。22.1節中列出的管理活動可以幫助你回答這個問題管理活動，如提案撰寫、項目規劃和人員選擇，需要一套技能，包括展示和溝通技能、組織技能以及與其他項目團隊成員溝通的能力。編程技能與這些技能不同（事實上，程序員經常被批評缺乏人際交往技能），所以不能說優秀的程序員可以重新調整他們的能力成為優秀的管理者。22.4除了圖22-1中所列的風險，識別可能在軟件項目中出現的其他6種風險其他可能的風險是：技術：在達到預期交易限制之前，通信網絡飽和。人員：可用人員的技能水平低于預期。組織：組織變革意味著項目進度加快。工具：軟件工具無法處理大型系統可用的數據量。需求：引入了新的非功能性需求，需要對系統架構進行更改。估計：軟件的難度被低估了。22.6價格鎖定的合同，即承包人以某個確定價格投標一系統開發，是一種將項目風險從委托人轉移給承包人的做法。如果出現問題，需要由承包人承擔。分析一下為什么這種合同容易增加產品風險的可能性固定價格合同增加了產品風險的可能性，因為它們從開發過程中移除了選項。因為合同是固定價格的，承包商自然不愿意增加項目的努力或時間支出，因為這會減少他們在工作中的利潤。因此，如果出現問題，他們會尋找方法來減少產品的范圍或降低產品開發的成本（例如，通過減少用于測試的努力）。這兩個因素都可能導致產品不符合客戶的預期22.8在極限編程團隊中許多管理決策權被下放到團隊成員手中，這會帶來哪些問題?雖然將管理決策下放到團隊的概念在激勵方面很有吸引力，但可能會出現兩種類型的問題：決策可能主要受技術考慮因素的影響，而不是業務決策