第一篇：軟件系統分析與設計

第1章

軟件工程基礎知識 1.1軟件工程知識體系

? 軟件需求（Software Requirements）? 軟件設計（Software Design）

? 軟件構造（Software Construction）? 軟件測試（Software Testing）? 軟件維護（Software Maintenance）

? 軟件配置管理（Software Configuration Management）? 軟件工程管理（Software Engineering Management）? 軟件工程過程（Software Engineering Process）

? 軟件工程工具和方法（Software Engineering Tools and Methods）? 軟件質量（Software Quality）

1.2軟件生存周期與軟件開發模型

? 1.2.1 軟件生存周期

? Boehm定義的軟件生存周期模型

? GB 8566-1988定義的軟件生存周期模型

? GB/T 8566-1995定義的軟件生存周期過程模型 ? GB/T 8566-2001定義的軟件生存周期過程模型 ? UP定義的軟件生存周期模型

? 1.2.2 軟件開發模型

? 瀑布模型（waterfall model）

? 快速原型模型（rapid prototype model）? 演化模型（evolutionary model）? 增量模型（incremental model）? 螺旋模型（spiral model）

? 噴泉模型（water fountain model）

1.3軟件質量模型與軟件質量管理

? 1.3.1 軟件質量模型

? 軟件產品的內部質量、外部質量和使用質量 ? 質量特性、質量子特性和度量

? 功能性：適宜性、準確性、互用性、依從性、安全性 ? 可靠性：成熟性、容錯性、可恢復性 ? 可用性：可理解性、易學性、可操作性 ? 效率：時間特性、資源特性

? 可維護性：可分析性、可修改性、穩定性、可測試性 ? 可移植性：適應性、易安裝性、一致性、可替換性

? 1.3.2 軟件質量管理

? 質量需求分析 ? 質量計劃 ? 質量保證 ? 質量控制 ? 質量改進

? 軟件質量管理體系

? ? ? ? ? ? ? ? ? ?

? ?

? ? ? ? ? ? ? ? ? ? ? ? ?

? ? ?

1.4軟件配置管理

? 1.4.1 軟件配置項與基線

計算機軟件配置項（CSCI）基線（baseline）

功能基線（functional baseline）指派基線（allocated baseline）產品基線（product baseline）

? 1.4.2 軟件配置管理過程

對象標識 版本控制 變化控制 配置審計 配置報告

1.5軟件過程管理

? 1.5.1 軟件能力成熟度模型（CMM）

CMM的5個等級：初始級、可重復級、已定義級、已管理級、優化級 CMM的關鍵過程域（KPA）：需求管理、軟件項目計劃、軟件項目跟蹤和監控、軟件子合同管理、軟件質量保證、軟件配置管理、組織級過程焦點、組織級過程定義、培訓大綱、集成軟件管理、軟件產品工程、組間協調、同行評審、定量過程管理、軟件質量管理、缺陷預防、技術變更管理、過程變更管理

? 1.5.2 軟件過程與軟件能力成熟度評估

第一步，建立評估組 第二步，填寫提問單 第三步，響應分析 第四步，現場考察

第五步，提出調查發現清單

第六步，制作關鍵過程域（KPA）剖面圖

? 1.5.3 軟件過程改進

第一步，比較“目標狀態”與“目前狀態”，找出所有差距 第二步，確定改進目標 第三步，制定改進計劃 第四步，執行改進計劃

第五步，總結本輪改進經驗，開始下一輪改進

1.6

小節

軟件工程學是研究如何有效地組織和管理軟件開發的工程學科。

軟件產品所要經歷的計劃、分析、設計、編程、測試、維護直至被淘汰這樣一個全過程被稱為軟件生存周期。用不同的方式將軟件生命周期中的所有開發活動組織起來，可以形成不同的軟件開發模型。

軟件質量就是軟件與明確地和隱含地定義的需求相一致的程度。軟件質量管理是指軟件開發機構為保證軟件項目滿足客戶需求所要實施的質量活動。軟件配置管理是在軟件的整個生命期內管理變化的一組活動，目標是使變化更正確且更容易被適應。

軟件過程是指人們用于開發和維護軟件及其相關產品的一系列活動，包括軟件工程過程和軟件管理過程。軟件過程管理的目的就是提升軟件組織的提高軟件開發能力。

? 1.? 1.? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

第2章

項目管理基礎知識 2.1項目與項目管理 ? 2.1.1 項目

項目是在特定條件下、具有特定目標的一次性任務，是在一定時間內、滿足一系列特定目標的多項相關工作的總和。項目的臨時性 項目的獨特性 項目的漸進性

2.1.2 項目管理

項目管理就是將各種知識、技能、工具和技術應用于項目之中，以達到項目的要求。項目范圍 項目時間 項目成本 項目質量

2.2項目管理過程與過程組 ? 2.2.1 過程與過程組

過程就是一組為了完成一系列事先指定的產品、服務或成果而需執行的互相聯系的行動和活動。軟件項目管理過程可歸納為五個過程組。啟動過程組（initiating process group）規劃過程組（planning process group）實施過程組（executing process group）

監控過程組（monitoring and controlling process group）收尾過程組（closing process group）

? 2.2.2 項目管理過程的交互作用

項目管理過程并不是互不相干的一次性事件

項目管理過程組之間是一種前后銜接、承前啟后的關系

項目管理過程組之間有時又是一種時間交錯、空間并行的關系 項目管理過程組之間還是一種信息收集、存儲、處理和傳遞的關系 某些過程組的關聯具有重復迭代性

規劃過程組、執行過程組和監控過程組之間形成一種閉環的關系 過程組的交互作用往往還會跨越項目階段 項目階段和過程之間有相互聯系

? 2.2.3 項目管理過程的裁剪

不同類型的軟件項目應選用不同的項目管理過程 不同階段的軟件項目應選用不同的項目管理過程 不同軟件項目的管理過程會有不同的具體過程 不同軟件項目的管理過程會有不同的具體過程順序 不同軟件項目的管理過程會有不同的條件與約束 不同軟件項目的管理過程會有不同的簡化程度 不同軟件項目的管理過程需要不同的集成程度 項目變更會使項目管理過程隨之變化

2.3項目管理知識體系

項目綜合管理 項目范圍管理

? ? ? ? ? ? ? ? ? ? 項目時間管理 項目成本管理 項目質量管理 項目人力資源管理 項目溝通管理 項目風險管理 項目采購管理

2.4小節

項目管理就是將項目管理知識、技能、工具和技術應用于項目活動之中，可以將軟件項目管理活動視做一系列相互聯系的過程。

項目管理過程可歸納為5個過程組：啟動過程組、規劃過程組、實施過程組、監控過程組與收尾過程組。

項目管理包括9個知識領域：項目綜合管理、項目范圍管理、項目時間管理、項目成本管理、項目質量管理、項目人力資源管理、項目溝通管理、項目風險管理與項目采購管理。

第3章

軟件開發技術 3.1軟件開發平臺

? 3.1.1 Microsoft.NET平臺

Microsoft.NET Framework：.NET CLR（通用語言運行環境）；.NET BCL（基礎類庫）；ASP.NET；ADO.NET。

Microsoft Visual Studio.NET：ADO.NET組件；XML數據組件；Windows表單組件；ASP.NET應用服務；ASP.NET Web表單；Web服務支持。

? 3.1.2 J2EE平臺

組件-容器：搭建體系架構平臺標準服務 多層應用模型

3.1.3 Microsoft.NET與J2EE的異同

類似的平臺基礎構造 相同的三層/多層體系 不同的移植、性能和擴展 在Web支持方面的比較 第三方廠商的支持 潛在的市場

3.2中間件技術 ? 3.2.1 中間件簡介

終端仿真/屏幕轉換中間件 數據訪問中間件 遠程過程調用中間件 消息中間件 交易中間件 對象中間件

Web服務器中間件 安全中間件

? 3.2.2 消息代理中間件 ? ?

? ? ? ? ? 1.? ? 1.? ? ? ? ? ? ? ?

? ? ? ? ? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

?

? 構件化的結構

可恢復性、易于管理、靈活性 具有數據轉換設施。可靠高效的通信 多樣的管理能力 豐富的應用開發環境

? 3.2.3 面向數據庫的中間件

ODBC JDBC 數據庫網關

3.3構件技術 ? 3.3.1 構件庫

構件的存儲

構件的分類與檢索機制 構件庫的編目

構件庫的管理和維護

? 3.3.2 構件模型

3C模型

刻面（Facet）模型 青鳥模型

? 3.3.3 構件的屬性與特點

構件是可獨立配置的單元，構件必須自包容。

構件強調與環境和其他構件的分離，因此構件的實現是嚴格封裝的，外界沒機會或沒必要知道構件內部的實現細節。

構件可以在適當的環境中被復合使用，因此構件需要提供清楚的接口規范，可以與環境交互。

構件沒有個體特有的屬性，最多僅有特定構件的一份副本。

? 3.3.4 構件與中間件

中間件，本質上是對分布式應用的抽象，中間件與系統架構實際上是從兩種不同的角度看待軟件的中間層次。

中間件促進了構件化軟件，基于中間件開發的應用系統是構件化的，中間件提供了構件的體系結構，極大提高了構件化軟件開發的效率和質量。構件化的軟件設計思想在中間件發展中起到了重要的作用。

3.4小節

Microsoft.NET平臺和J2EE平臺是目前最常用的兩大軟件開發平臺。作為彼此競爭的應用平臺，Microsoft.NET平臺和J2EE平臺在目標和體系結構上極其相似，但在實現上又完全不同。二者總的關系是：異中有同，同中有異。中間件是處于操作系統和應用程序之間的軟件。中間件保持了平臺的透明性，抽象了典型的應用模式。應用軟件開發者可以基于標準的中間件進行再開發，而不必再考慮操作系統的問題。

構件是可復用的軟件成份，可被用來構造其他軟件。中間件促進了構件化軟件，應用系統在中間件提供的環境中可以更好地集中于業務邏輯上，并以構件的形式存在。構件思想也反過來推動了中間件的發展。

第4章

軟件項目規劃

4.1項目策劃

? 1.? 1.從政策導向中尋找項目機會 從市場需求中尋找項目機會 從技術發展中尋找項目機會 從特定事件中尋找項目機會

4.2項目可行性分析 4.2.1 技術可行性分析

? ? ? ? ? 1.? ? ? ? ? ? ? ? ? 項目的必要性分析

軟件組織水平與能力分析 項目技術來源分析 與項目相關的專利分析

項目負責人及技術骨干的資質分析 項目總體技術方案分析 項目創新點分析 項目技術風險分析 項目技術成熟性分析

? 4.2.2 項目投資及效益分析

項目投資預算分析 項目投資來源分析

市場需求與產品銷售額分析

產品成本、利潤與盈虧平衡點分析 投資回收期、投資收益率分析 社會效益分析

4.3項目論證、評估與立項

? 4.3.1 項目論證與評估的基本概念

項目論證是指對擬實施項目技術上的先進性、成熟性、適用性，經濟上的合理性、盈利性，實施上的可能性、風險性進行全面科學的綜合分析，為項目決策提供客觀依據的一種技術經濟研究活動。

項目評估指在項目可行性研究的基礎上，項目投資者或項目主管部門或其委托的第三方權威機構根據國家頒布的政策、法律、法規、標準和技術規范，對擬開發項目的市場需求、技術先進性和成熟性、預期經濟效益和社會效益等進行評價、分析和論證，進而判斷其是否可行的過程。

項目論證與評估的內容、程序和依據大同小異，只是側重點稍有不同，有時不加區分或合并進行。

? 4.3.2 項目可行性報告的真實性評估

項目申請單位的資質真實性評估 項目申請單位的財務真實性評估 項目申請單位的技術真實性評估 其他事項的真實性評估

? 4.3.3 項目可行性報告的客觀性評估

技術創新點的客觀性評估

技術先進性與成熟性的客觀性評估 ?

?

?

? ? ? ? ? ?

? ? ? ? 信息安全措施的客觀性評估

采用標準、規范的先進性、合理性評估 項目風險及應對方案的客觀性評估 其他事項的客觀性評估

? 4.3.4 評估報告

? 項目概況 ? 評估目標 ? 評估依據 ? 評估內容

? 評估機構與評估專家 ? 評估過程

? 詳細評估意見

? 存在或遺漏的重大問題 ? 潛在的風險 ? 評估結論

? 進一步的建議

? 4.3.5 項目立項

項目立項的決定應當由項目團隊之外的、適當級別的、并為項目出資的項目發起人或投資人作出，通常以項目立項決定（通知）書、項目批文、項目許可證書和項目任務書等形式發布。

4.4項目開發計劃

? 1．引言 ? 2．引用文件 ? 3．項目最終成果 ? 4．需求與約束

? 5．系統開發總體計劃 ? 6．項目開發詳細計劃 ? 7．進度表與活動網絡圖 ? 8．項目組織與資源 ? 9．培訓

? 10．項目估算 ? 11．風險管理 ? 12．支持條件 ? 13．注解 ? 14．附錄

4.5小節

? 軟件項目規劃的任務主要包括項目策劃、可行性研究、論證、評估、立項與項目開發計劃的制訂工作。

? 項目策劃，也稱項目機會研究，其目的是選擇投資機會、鑒別投資方向。

? 項目可行性分析的目的是確定以下問題：項目有無必要？能否完成？是否值得去做？ ? 項目論證與評估的目的是審查項目可行性研究的可靠性、真實性和客觀性，為項目主管部門或投資機構的立項決策提供科學依據。

? 項目開發計劃是項目規劃階段的重要成果，編寫軟件項目開發計劃時可依據《GB/T 8567-2006 計算機軟件文檔編制規范》中的軟件開發計劃模版。

? ?

? ? ? ? ?

?

?

?

?

? ? ? ? ? ? ? ? ?

第5章

系統分析方法學 5.1系統需求分析與軟件需求

系統需求：系統總體功能和業務結構；硬件系統需求；軟件系統需求；硬件系統和軟件系統之間的接口需求。軟件需求：軟件能力需求；軟件外部接口需求；軟件內部接口需求；軟件內部數據需求；適應性需求；安全性需求；保密性和私密性需求；軟件環境需求；計算機資源需求；軟件質量需求；設計和實現的約束；數據需求；操作需求；故障處理需求；算法需求；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求。

5.2結構化分析

結構化分析（SA）方法是一種面向數據流的需求分析方法，基本思想是自頂向下逐層分解。

數據流圖（DFD）和數據字典（DD）是結構化分析最常用的工具。數據流圖用來描述數據流從輸入到輸出的變換流程。

數據字典是關于數據的信息的集合，也就是對數據流圖中包含的所有元素的定義的集合。

數據流圖和數據字典共同構成系統的邏輯模型。

5.3原型化方法

? 5.3.1 原型化方法與結構化方法的比較

結構化方法的假設：所有的需求都能被預先定義；修改定義不完備的系統代價昂貴且實施困難；項目參加者之間能夠清晰進行準確的通信；靜態描述或圖形模型對應用系統的反映是充分的；結構化方法的生命周期的各階段都是固有正確的。

原型化方法的假設：并非所有的需求在系統開發以前都能準確地說明；有快速的系統建造工具；項目參加者之間通常都存在通信上的障礙；需要實際的、可供用戶參與的系統模型；需求一旦確定，就可以遵從嚴格的方法；大量的反復是不可避免的、必要的，應該加以鼓勵。

? 5.3.2 原型生命周期及其策略

原型生命周期劃分：選擇開發方法；識別基本需求；開發工作模型；模型驗證；修正和改進；判定原型完成；差別細部說明；嚴格說明細部；判定原型效果；整理原型和提供文檔。

原型化的策略：建立數據模型；利用組合工程；剪裁和粘貼；用系統舉例；字典驅動；文檔的自動化；小的原型化隊伍；交互式開發平臺；陳述性規格說明；終端用戶報表生成器；專業原型化人員；開發人員參加原型化。

5.4面向對象的分析

? 5.4.1 面向對象方法學概述

對象與封裝 類

繼承與多態性 消息通信

面向對象方法學的優點

? 5.4.2 面向對象的分析方法

OMT方法簡介 建立對象模型 建立動態模型 建立功能模型

?

?

? ? ?

? ? ? ? ? ? ? 1.? ? 1.? ? ? ? ?

? ? ? ? ? ?

5.5小節

系統分析涉及系統需求的獲取、分析、規格說明和確認。系統需求可分為以下幾個方面：系統總體功能和業務結構、硬件系統需求、軟件系統需求、硬件系統和軟件系統之間的接口需求。

常用的系統分析方法包括結構化分析、原型化方法和面向對象的分析。

第7章

系統分析文檔

7.1系統/子系統需求規格說明

引言 引用文件

需求：要求的狀態和方式；需求概述；系統能力需求；系統外部接口需求；系統內部接口需求；系統內部數據需求；適應性需求；安全性需求；保密性和私密性需求；操作需求；可使用性、可維護性、可移植性、可靠性和安全性需求；故障處理需求；系統環境需求；計算機資源需求；系統質量需求；設計和構造的約束；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求；需求的優先次序和關鍵程度 合格性規定 需求可追蹤性 非技術性需求 尚未解決的問題 注解 附錄

7.2接口需求規格說明

引言 引用文件 需求

合格性規定 需求可追蹤性 注解 附錄

7.3軟件需求規格說明

引言 引用文件

軟件需求：要求的狀態和方式；需求概述；需求規格；軟件能力需求；軟件外部接口需求；軟件內部接口需求；軟件內部數據需求；適應性需求；安全性需求；保密性和私密性需求；軟件環境需求；計算機資源需求；軟件質量需求；設計和實現的約束；數據需求；操作需求；故障處理需求；算法需求；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求；需求的優先次序和關鍵程度 合格性規定 需求可追蹤性 尚未解決的問題 注解 附錄

7.4小節

根據《GB/T 8567-2006 計算機軟件文檔編制規范》（Specification for computer

? ? ?

? ?

? ? ? ? ? ?

? ? ? ? ?

?

? software documentation），系統分析文檔主要包括系統/子系統需求規格說明（SSS）、接口需求規格說明（IRS）和軟件需求規格說明（SRS）。系統/子系統需求規格說明（SSS）為一個系統或子系統指定需求以及保證每個需求得到確認所使用的方法。

接口需求規格說明（IRS）描述為實現一個或多個系統、子系統、硬件配置項（HWCI）、計算機軟件配置項（CSCI）、用戶

軟件需求規格說明（SRS）描述對計算機軟件的需求以及確保每個需求得到確認所使用的方法。

第8章

系統設計基礎 8.1系統設計概述

? 8.1.1 系統級設計決策

系統級設計決策，是指系統行為的設計決策（忽略其內部實現，從用戶角度出發，描述系統將怎樣運轉以滿足需求）和其他對系統部件的選擇和設計產生影響的的決策。系統級設計決策內容：有關系統接收的輸入和產生的輸出的設計決策；對每個輸入或條件進行響應的系統行為的設計決策；系統數據庫/數據文件如何呈現給用戶的設計決策；為滿足安全性、保密性和私密性需求所選用的方法；硬件或硬軟件系統的設計和構造選擇；為了響應需求而作出的其他系統級設計決策。

? 8.1.2 系統架構設計

總體設計

系統部件設計 動態交互設計 接口設計

? 8.1.3 運行設計

系統初始化——說明本系統的初始化過程。

運行控制——說明對系統施加不同的外界運行控制時所引起的各種不同的運行組件組合、每種運行所經歷的內部組件和支持軟件、每一種外界運行控制的方式方法和操作步驟、每種運行組件組合將占用各種資源的情況以及系統運行時的安全控制。運行結束——說明本系統運行的結束過程。

? 8.1.4 系統出錯處理設計

出錯信息——包括出錯信息表、故障處理技術等。補救措施——說明故障出現后可能采取的補救措施。

? 8.1.5 系統維護設計

檢測點的設計——說明在系統中專門安排用于系統檢查與維護的檢測點。

檢測專用組件的設計——說明在系統中專門安排用于系統檢查與維護的專用組件。

8.2軟件設計概述

? 8.2.1 軟件級設計決策

軟件級設計決策是指軟件行為的設計決策（忽略其內部實現，從用戶角度出發，描述軟件將怎樣運轉以滿足需求）和其他影響組成該軟件的軟件配置項的選擇與設計的決策。

軟件級設計決策內容：有關軟件接收的輸入和產生的輸出的設計決策；對每個輸入或條件進行響應的軟件行為的設計決策；有關數據庫/數據文件如何呈現給用戶的設計決策；為滿足安全性、保密性和私密性需求所選用的方法；為響應需求而作出的其他軟件級設計決策。

? 8.2.2 軟件架構設計

? ? ? ? ? ? ? ? ? ? ? 程序結構設計

全局數據結構設計 軟件配置項設計 動態交互設計 接口設計

? 8.2.3 軟件詳細設計

軟件配置項設計決策

軟件配置項設計中的約束、限制或非常規特征 軟件配置項使用的編程語言考慮 軟件配置項使用的過程式命令選取

軟件配置項的局部數據與軟件配置項的輸入或輸出數據設計 軟件配置項的邏輯設計

8.3設計原則 ? 8.3.1 組件化

組件的可分解性 組件的可組裝性 組件的可理解性 組件的連續性 組件的保護性

? 8.3.2 抽象

抽象就是抽出事物的本質特性而暫時忽略其細節，使得不同的事物可以當作相同的事務來處理。

軟件工程過程的每一步都是對軟件解法的抽象層次的一次精化。

軟件設計中的抽象機制主要包括類、模板、過程抽象、數據抽象和控制抽象。

? 8.3.3 內聚與耦合

內聚是指一個組件內各個元素彼此結合的緊密程度 內聚種類（由低到高排列）：偶然內聚；邏輯內聚；瞬時內聚；過程內聚；通信內聚；順序內聚；功能內聚

耦合是指一個軟件結構內不同組件之間的互連程度 耦合種類（由高到低排列）：內容耦合；公共耦合；外部耦合；控制耦合；標記耦合；數據耦合；非直接耦合

組件的高內聚、低耦合原則稱為組件獨立原則

? 8.3.4 封裝與信息隱蔽

第一，組件是其全部屬性和全部服務緊密結合而形成的一個不可分割的整體。

第二，組件是一個不透明的黑盒子，表示組件狀態的數據和實現操作的代碼都被封裝在黑盒子里面。使用一個組件的時候，只需知道它向外界提供的接口形式，無須知道它的數據結構細節和實現操作的算法。

? 8.3.5 啟發式規則

深度、寬度、扇出與扇入 作用域和控制域 功能的可預測性

8.4設計視圖

? 8.4.1 架構視圖（靜態視圖）

架構描述語言（ADL）? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? ? ?

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? ? 類圖與對象圖 組件圖

協作責任卡（CRC）部署圖

實體-聯系圖（E-R圖）接口描述語言（IDL）結構圖

Jackson結構圖

? 8.4.2 行為視圖（動態視圖）

活動圖 協作圖 順序圖 數據流圖

決策表和決策圖

流程圖和結構化流程圖 狀態圖

形式化描述語言 偽碼

8.5小節

系統設計是定義一個系統或軟件的架構、組件、接口和其它特征的過程。包括系統級設計決策、系統架構設計、運行設計、系統出錯處理設計和系統維護設計。

軟件設計主要包括軟件級設計決策、軟件架構設計（概要設計）與詳細設計。軟件架構設計的主要任務是程序結構設計、全局數據結構設計、軟件配置項設計、動態交互設計和接口設計。軟件詳細設計是指每一個軟件配置項的具體設計。

組件化、抽象、高內聚與低耦和、封裝與信息隱蔽是軟件設計的基本原則。軟件設計視圖通?？煞譃榧軜嬕晥D（靜態視圖）和行為視圖（動態視圖）兩類。第9章

系統設計方法 9.1結構化設計

? 9.1.1 結構化設計方法概述

分析系統的總體需求，并將需求逐步分解為基本、具體的功能。確定每個功能應當記錄的數據。

列出系統中應提供的各項基本功能，并分析各項基本功能之間的耦合關系，根據高內聚、低耦和的原則分配到系統中適當的模塊中。

? 9.1.2 系統結構圖

模塊 調用 數據 控制 轉接符號

? 9.1.3 系統結構圖分類

變換流與事務流 變換型系統結構圖 事務型系統結構圖 ? ? ?

? ? ? ? ? ? ? ?

? 混合型系統結構圖

9.2面向數據結構的設計

? 9.2.1 面向數據結構的設計概述

分析并建立適合系統的數據結構；

根據數據結構在相應的層次建立程序結構；

羅列出程序中用到的各種基本操作，并將這些基本操作分配到程序結構中合適的模塊中。

? 9.2.2 Jackson圖

順序結構 選擇結構 重復結構

改進的Jackson圖

? 9.2.3 Jackson方法

分析并確定輸入和輸出數據的邏輯結構，并利用Jackson 找出輸入和輸出數據結構中存在對應關系的數據單元。從描繪數據結構的Jackson圖導出描繪程序結構的Jackson

列出所有操作和條件(包括分支條件和循環結束條件)，并且把它們安排到程序結構圖的適當位置。用偽代碼表示。

9.3面向對象的設計

? 9.3.1 面向對象的設計概述

面向對象設計的基本思想是通過建立和客觀實際相對應的對象，并通過這些對象的組合來創建具體的應用。

面向對象設計具有基于抽象、信息隱藏、功能獨立和模塊性構造系統的能力。

對于面向對象的系統，可以定義一個四個層次的設計金字塔：子系統層；類及對象層；消息層；責任層。

? 9.3.2 面向對象設計技術

? Coad/Yourdon方法 ? Booch方法 ? OMT方法 ? ?

? 9.3.3 面向對象設計過程

系統設計過程：將分析模型劃分為子系統；子系統分配及與問題的并發性；任務管理；數據管理；資源管理；人機界面；子系統間通信

對象設計過程：對象描述；算法與數據結構設計；接口設計與模塊化

9.4設計模式

? 9.4.1 設計模式概述

設計模式就是將面向對象軟件的設計經驗記錄下，可供設計者能夠復用的設計方案。設計模式極大提高了面向對象軟件開發的效率，降低了軟件的復雜度。

在軟件設計中使用設計模式，將使用開發出來的軟件更容易理解、更容易維護、更容易擴展，使用設計模式同時也能夠提高開發團隊和個人的開發能力。

? 9.4.2 設計模式基本組成

模式名稱：惟一標識一個設計模式。問題：描述應該在何時使用該模式。? ? ?

? ? ? ? ? ? ? ? ?

? ? ?

? ? ?

? ?

? 解決方案：描述設計的組成要素，以及它們之間的相互關系及各自的職責與相互之間協作的方式。

? 效果：描述應用設計模式的效果，以及使用設計模式必須考慮的限制和約束因素。

? 9.4.3 設計模式分類

? 面向對象模式 ? 代碼模式

? 框架應用模式

? 創建型模式、結構型模式與行為型模式 ? 類模式與對象模式

? 9.4.4 如何使用設計模式

? 針對接口編程，而不是針對實現編程 ? 優先使用對象組合，而不是類繼承 ? 找出變化并封裝

9.5小節

? 系統設計是一系列迭代的過程，主要任務包括數據結構、體系結構、接口及過程細節的設計等，而設計方法是軟件設計活動中實現設計模型的方法。? 系統設計方法主要包括面向過程的結構化設計方法、面向數據結構的設計，以及面向對象的設計方法與設計模式。

第10章

數據庫設計 10.1數據建模

? 10.1.1 數據模型分類

? 概念數據模型 ? 結構數據模型 ? 物理數據模型

? 10.1.2 實體-聯系（E-R）模型

? 實體 ? 屬性 ? 聯系 ? 實體型 ? 實體集 ? 鍵 ? 域

? 10.1.3 數據模型

? 層次數據模型（hierarchical model）? 網狀數據模型（network model）? 關系數據模型（relational model）

? 面向對象模型（object oriented model）

10.2數據規范化

? 10.2.1 數據規范化的基本概念

? 函數依賴

? 非平凡函數依賴 ? 完全函數依賴 ? 部分函數依賴

? 傳遞函數依賴 ? 鍵

? 10.2.2 范式

? ? ? ? 第一范式（1NF）第二范式（2NF）第三范式（3NF）BC范式（BCNF）

10.3數據庫設計過程 ? 10.3.1 數據庫需求分析

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 數據邊界的確定 數據環境的確定 數據內部關系 數據字典

數據性能需求

數據需求分析說明書

? 10.3.2 數據庫概念設計

概念設計與概念模型 概念設計的主要方法 分解與抽象 局部概念模式 全局概念模式

? 10.3.3 數據庫邏輯設計

初始模式的形成 子模式設計

應用程序概要設計 模式評審 修正模式

? 10.3.4 數據庫物理設計

存儲記錄結構設計 確定數據存放位置 存取方法設計

完整性和安全考慮 程序設計

10.4小節

? 數據庫系統普遍采取數據模型表示和處理客觀事物的數據特征與信息。數據模型主要由數據結構、數據操作和完整性約束三部分組成，從抽象層次上描述和模擬了系統的靜態特征、動態行為和約束條件。

? 關系數據庫中的關系必須滿足一定的要求，即滿足不同的范式。目前關系數據庫中常用的范式包括：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）和BCNF。? 數據庫設計主要包括需求分析、概念設計、邏輯設計和物理設計等幾個階段。

第11章

用戶界面設計

11.1基本概念

? ? ?

? ? ? ? ? ? ? ? ? ?

? ? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ?

? 11.1.1 界面設計目標

可用性目標：可行性、有效性、易學性、易記性、安全性、通用性

用戶體驗目標：令人滿意、令人愉快、引人入勝、富有啟發、激發創造??

可用性目標主要從客觀角度來評價系統界面，而用戶體驗目標則是從用戶主觀感受的角度來評價系統界面。

? 11.1.2 界面設計原則

可視性：將系統功能呈現得一目了然。

反饋性：返回與活動相關的信息，以便用戶能夠繼續這個活動。限制性：將用戶的行為限制在一定的范圍內。

對應性：明確系統某個控制與其控制效果之間的對應關系。一致性：用相似的元素表現相似的操作或相似的任務。啟示性：界面元素應給予用戶某種提示。

? 11.1.3 界面設計過程

標識出用戶的真實需要并建立需求模型 設計出候選方案

構建或實現設計的原型版本 對界面設計進行評估

11.2界面設計技術

? 11.2.1 界面設計分析技術

GOMS模型及GOMS擊鍵層模型 Hick律 Fitts律

? 11.2.2 界面設計方法

原型設計方法

以用戶為中心的設計方法 用戶界面設計的支持工具

11.3界面設計評估

? 11.3.1 構造性評估與總結性評估

構造性評估：在設計過程中對所設計的系統或產品界面進行評估以確保其滿足用戶需求。

總結性評估：對已經完成的產品或系統界面進行評估。

? 11.3.2 評估范型

快速評估 可用性測試 實地研究 預測性評估

? 11.3.3 評估方法與技術

觀察用戶

征求用戶意見 征求專家意見 用戶測試

用戶執行情況的分析模型

? 11.3.4 評估框架

明確（Determine）

? ? ? ? ? ? ? ? ?

發掘（Explore）選擇（Choose）標識（Identify）決定（Decide）評估（Evalute）

11.5小節

用戶界面體現了用戶利用系統完成任務的方式以及系統對用戶行為的響應方式，一個沒有良好的用戶界面設計的系統很可能會成為一個沒有用戶的系統?？捎眯阅繕伺c用戶體驗目標。

界面設計的量化模型：GOMS模型及其子模型-擊鍵層模型，Hick律和Fitts律。構造性評估與總結性評估。

第12章

系統設計文檔

12.1系統/子系統（結構）設計說明

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 引言 引用文件

系統級設計決策

系統體系結構設計：總體設計；系統部件設計；動態交互設計；接口設計 運行設計

系統出錯處理設計 系統維護設計 尚未解決的問題 需求的可追蹤性 注解 附錄

12.2

接口設計說明

引言 引用文件 接口設計

需求的可追蹤性 注解 附錄

12.3

軟件（結構）設計說明

引言 引用文件

軟件級設計決策

軟件體系結構設計：程序結構設計；全局數據結構設計；軟件配置項設計；動態交互設計；接口設計 軟件詳細設計 需求的可追蹤性 注解 附錄

12.4數據庫設計說明

? ? ? ? ? ? ? ? ?

? ? ? ? ?

引言 引用文件

數據庫級設計決策 數據庫詳細設計

用于數據庫操縱或訪問的軟件配置項的詳細設計 需求的可追蹤性 注解 附錄

12.5

小節

根據《GB/T 8567-2006 計算機軟件文檔編制規范》，系統設計文檔主要包括系統/子系統設計（結構設計）說明（SSDD）、接口設計說明（IDD）、軟件（結構）設計說明（SDD）和數據庫設計說明（DBDD）。

系統/子系統設計（結構設計）說明（SSDD）描述了系統（或子系統）的系統級（或子系統級）設計決策與體系結構設計。

接口設計說明（IDD）描述了一個或多個系統、子系統、硬件配置項（HWCI）、計算機軟件配置項（CSCI）、用戶或其他系統部件的接口特性。

軟件（結構）設計說明（SDD）描述了計算機軟件系統的軟件級設計決策、軟件體系結構設計（概要設計）與詳細設計。

數據庫（頂層）設計說明（DBDD）描述了數據庫的設計。系統設計文檔可以使用自然語言，可以使用形式化語言，也可以根據具體的系統設計方法使用各種圖形工具，還可以根據實際情況混合使用多種表現形式。

第二篇：《軟件系統分析與設計》期末復習知識點總結

一、方法論模型。

1、BOOCH、OMT、OOSE、Coad-Yourdon（前三者組成UML）

2、UML包括9種圖，分別為用例圖、靜態圖（包圖、類圖、對象圖）、實現圖（構件圖、部署圖）、行為圖（活動圖、狀態圖、交互圖(順序圖、協作圖)）基本規范，泛化關聯，包含關聯，擴展關聯

3、基本模型——類圖、需求模型——用例圖、輔助模型——其他各種圖

4、兩大工具：Rose、PowerDesigner

5、方法三要素：模型、工具和過程

6、結構化分析三視圖模型E-R、DFD、STD

7、OMT方法的三大模型：對象模型、功能模型、動態模型

8、Coad/Yourdon方法的五大層次：對象-類、結構、主題、屬性、服務

二、基本建模（類圖與對象圖）

1、類之間的關系：關聯關系、依賴關系、泛化關系。

2、抽象類與接口：抽象類有些方法可以提供實現代碼，接口所有的方法都沒有提供實現代碼。抽象類只能被繼承，接口只能被實現。

3、類的版型：實體類（數據庫、文件等）、邊界類（如窗體、對話框）、控制類（協調交互）

三、需求建模（用例圖）

1、參與者指系統以外的、需要使用系統或與系統交互的外部實體?？梢苑譃椋喝恕⑼獠吭O備、外部系統。

2、參與者之間的關系：泛化關系，參與者與用例之間的關系：關聯關系。用例之間的關系：泛化關系，包含關系，擴展關系。包含關系和擴展關系都是依賴關系的特例。

3、用例是對一個參與者使用系統的一項功能時所進行的交互過程的一個文字描述序列。是參與者可以感受到的系統服務或功能單元。

4、用例描述是一個關于參與者與系統如何交互的規范說明（包含用例用例名稱、用例描述、基本事件流、參與者、前置后置條件等）

5、用例的進一步描述：活動圖、順序圖（通信圖）

四、行為建模（狀態圖與活動圖）

1、行為模型包括：狀態模型（狀態圖，單對象）、活動模型（活動圖，多對象）、交互模型（順序圖，多對象）。

2、調用事件表示的是對操作的調用，變化事件一個布爾表達式變量的值發生變化。時間事件滿足某一時間表達式的情況的出現。信號事件就是由一個對象異步地發送、并由另一個對象（即狀態圖所對應的對象）接收的已命名的實體。調用事件狀態圖內對象和外部對象都能發起，信號事件只能由外部發起。

3、對象處于不同的狀態，導致后續要執行不同的操作。這些操作可能歸屬于不同的用例。一個用例的執行對應一個順序圖。順序圖刻畫了多個對象之間的消息發送關系。需要多個用例的順序圖，來融合地描述一個對象的完整狀態圖。

4、活動表示的是某流程中的任務的執行，它可以表示某算法過程中語句的執行。

5、分叉表示的是一個控制流被兩個或多個控制流代替，經過分叉后，這些控制流是并發進行的。匯合正好與分叉相反，表示兩個或多個控制流被一個控制流代替。

6、泳道（swimlane）是活動圖中的區域劃分，根據每個活動的職責對所有活動進行劃分，每個泳道代表一個責任區。關心的是其所代表的職責。

7、活動圖用途：對業務過程進行建模。對某個方法具體過程建模。

8、狀態與活動的區別：狀態是一個對象所處的境況。通常是執行了一個（或多個）活動后的結局?；顒邮且欢纬绦虼a的執行，對應于若干個步驟的集成。不同的狀態會導致不同的功能（對應于若干個活動）的執行。一個方法可能需要多個（也可以是一個）活動來完成。一個活動只能屬于一個方法。一個用例對應于若干個活動。

五、交互建模（順序圖和協作圖）

1、靜態結構使用類圖，動態結構使用順序圖、協作圖、狀態圖、活動圖。

2、對象：同類圖中的對象，是類的實例

生命線：從對象圖標向下延伸的一條虛線，表示對象存在的生命期 控制焦點（激活期）：對象執行一個動作的時間段 消息：對象間的一次通信

調用消息的發送者把控制傳遞給消息的接收者，然后停止活動，等待消息接收者放棄或返回控制。調用消息可以用來表示同步的意義。

3、順序圖一般對應一個用例。一個類中的職責對應該對象執行一個動作。

4、對象：同類圖中的對象，是類的實例 ；鏈：對象之間的連接關系；消息：對象間的一次通信；對象生命周期：對象名稱之后標以{new}約束表示創建對象，標以{destroy}約束表示銷毀對象

5、協作圖的建模同順序圖的建模，或者：可以從順序圖直接變換過來，或者：根據類圖，畫出對應的對象圖。在鏈上附著消息。

6、順序圖和協作圖的聯系：都用于描述系統中對象之間的交互協作完成一項功能，彼此可以相互轉換。區別：順序圖強調的是消息的時間順序；協作圖強調的是對象的空間位置關系。順序圖中有對象生命線和控制焦點；協作圖中有路徑，消息必須要有消息順序號。順序圖可以表示生命線的分叉；協作圖可以表示多對象、主動對象。

第三篇：系統分析與設計 期末考試

10.在一個課程注冊系統中，定義了類CourseSchedule和類Course，并在類CourseSchedule中定義了方法add(c: Course)和方法remove(c: Course)，則類CourseSchedule和類Course之間的關系是：（）A.泛化（generalization）關系 B.組合（composition）關系 C.依賴（dependency）關系 D.包含（include）關系 13.進行企業系統規劃，哪種規劃方法使目標識別比較全面

A、企業系統規劃法 B、關鍵成功因素法

C、戰略目標集轉化法 D、成本效益分析法 14.系統開發的生命周期中不包括下列哪個階段（）A.系統規劃 B.系統分析 C.系統設計 D.系統實施

19.面向對象程序設計將描述事物的數據與()封裝在一起,作為一個相互依存、不可分割的整體來處理。A.信息 B.數據隱藏 C.對數據的操作 D.數據抽象 22.屬于系統設計階段的工具是（）：

A.數據流程圖 B.處理流程圖 C.系統流程圖 D.HIPO圖

23.進行企業系統規劃，哪種規劃方法可以形成一套完整的信息系統結構方案（）A.企業系統規劃法 B.關鍵成功因素法 C.戰略目標集轉化法 D.成本效益分析法

30.導出模塊結構圖的基礎是（）

A.業務流程圖 B.數據流程圖 C.處理流程圖 D.層次結構圖

32.（）是從用戶使用系統的角度描述系統功能的圖形表達方法。

A.類圖 B.對象圖 C.序列圖 D.用例圖

35.UML中，對象行為是通過交互來實現的，是對象間為完成某一目的而進行的一系列消息交換。消息序列可用兩種圖來表示，分別是（D）

A.狀態圖和順序圖 B.活動圖和協作圖

C.狀態圖和活動圖 D.順序圖和協作圖

36.用例（Use-case）用來描述系統在事件做出響應時所采取的行動。用例之間是具有相關性的。在一個“訂單輸入子系統”中，創建新訂單和更新訂單都需要檢查用戶帳號是否正確。那么，用例“創建新訂單”、“更新訂單”與用例“檢查用戶帳號”之間是（A）關系。

A.包含（include）B.擴展（extend）

C.分類（classification）D.聚集（aggregation）

1、組成UML有三種基本的建筑塊是：（A），事物和圖

A、關系 B、類 C、用例 D、實體

2、UML體系包括三個部分：UML基本構造塊，（A）和UML公共機制

A、UML規則 B、UML命名 C、UML模型 D、UML約束

4、（A）模型的缺點是缺乏靈活性，特別是無法解決軟件需求不明確或不準確的問題

A、瀑布模型 B、原型模型 C、增量模型 D、螺旋模型

5、下面哪個不是UML中的靜態視圖（A）

A.狀態圖 B.用例圖 C.對象圖 D.類圖

6、（A）技術是將一個活動圖中的活動狀態進行分組，每一組表示一個特定的類、人或部門，他們負責完成組內的活動。

A、泳道 B、分叉匯合 C、分支 D、轉移

7、下列關于狀態圖的說法中，正確的是（C）

A.狀態圖是UML中對系統的靜態方面進行建模的五種圖之一。B.狀態圖是活動圖的一個特例，狀態圖中的多數狀態是活動狀態

C.活動圖和狀態圖是對一個對象的生命周期進行建模，描述對象隨時間變化的行為。D.狀態圖強調對有幾個對象參與的活動過程建模，而活動圖更強調對單個反應型對象建模

8、對反應型對象建模一般使用（A）圖

A、狀態圖 B、順序圖 C、活動圖 D、類圖

12、（D）是系統中遵從一組接口且提供實現的一個物理部件，通常指開發和運行時類的物理實現 A、部署圖 B、類 C、接口 D、組件

13、關于協作圖的描述，下列哪個不正確（B）

A.協作圖作為一種交互圖，強調的是參加交互的對象的組織； B.協作圖是順序圖的一種特例 C.協作圖中有消息流的順序號；

D.在ROSE工具中，協作圖可在順序圖的基礎上按“F5”鍵自動生成； 8定義大多數的需求和范圍的工作是在UP中的 B 階段完成的。A初始階段 B細化階段 C構造階段 D提交階段

1.信息系統設計是系統開發的重要階段，進行系統設計的主要依據應是（）。A、可行性研究報告B 系統分析報告

C、系統調查報告 D、系統規劃報告

3.在系統總體結構設計時，應采納什么樣的方法（）。A、程序設計 B、結構化設計 C、由里向外 D、自底向上 4.結構化設計的基本思想是（）。

A、模塊化 B、集成化 C、自底向上，逐步求精 D、規范化

5.在結構化生命周期法中，系統分析和系統實施之間的階段是（）。A、詳細設計 B系統設計 C、需求分析 D、編程調試 6.對于結構化設計思想的描述哪一項是錯誤的（）。

A、在結構化設計中，模塊的功能應當簡單明確，易于理解 B、自頂向下，逐步求精

C、設計者應先設計頂層模塊

D、越下層模塊，其功能越具體，越復雜 8.系統設計階段的主要目的是（）。

A、設計新系統的目標 B 將系統邏輯方案轉換成物理方案 C、代碼設計 D、程序設計 19.結構化設計方法中繪制模塊結構圖的基礎是（）。A 數據流程圖 B、數據關系圖 C、數據結構圖 D、業務流程圖 29.系統設計階段的主要工作內容之一是（）。

A、程序設計 B、購置計算機 C、畫出數據流程圖 B、規定處理過程 31.系統的呑吐量指的是（）。

A、每天的數據輸出量 B、每秒數據的處理量 C、每日數據的輸入量 D、每秒執行的作業數

33.在系統物理配置方案的設計中，系統的（）可以用連續工作時間來表示。A、吞吐量 B、響應時間 C 可靠性 D、地域范圍 34.計算機和網絡系統配置說明，應包含在()中。

A、系統規劃說明書 B、系統設計說明書 C、系統實施說明書 D、系統分析說明書 35.屬于系統詳細設計工作的是（）。

A、輸入輸出設計 B、系統平臺設計 C、系統結構設計 D、程序設計 39.系統設計報告的主要作用是作為（）的依據。A、系統規劃 B、系統分析 C、系統實施 D、系統評價

1.B 3.B 4.A 5.B 6.D8.B 19.A 29.D 31.D 33.C 34.B 35.A 39.C 11.系統設計階段需要從數據流程圖導出模塊結構圖。B.生命周期結構(Lifecycle Architecture)里程碑 4．系統實施的主要活動包括（D）。C.初始功能(Initial Operational)里程碑 A、編程、系統調試 B、系統安裝 C、新舊系統轉換 D、以上都是 1．系統實施是以（B）為依據的。

A、系統分析文檔資料 B、系統設計文檔資料

C、系統分析和設計文檔資料 D、數據流程圖

7.一般子系統的劃分是在系統()階段,根據對系統的功能/數據分析的結果提出的.A.需求分析 B.邏輯階段 C.總體設計 D.詳細設計 答案: A 4.業務系統規劃法(BSP)的核心是()A.明確企業目標 B.定義(識別)業務過程 C.進行數據分析 D.確定信息結構 答案: C 7.一般子系統的劃分是在系統()階段,根據對系統的功能/數據分析的結果提出的.A.需求分析 B.邏輯階段 C.總體設計 D.詳細設計 答案: A 4.業務系統規劃法(BSP)的核心是()A.明確企業目標 B.定義(識別)業務過程 C.進行數據分析 D.確定信息結構 答案: C 12.RUP中的軟件生命周期在時間上被分解為四個順序的階段,分別是:初始階段(Inception),細化階段(Elaboration),構造階段(Construction)和交付階段(Transition),每個階段結束于一個主要的里程碑(Major Milestones).構建階段結束時是第三個重要的里程碑:初始功能(Initial Operational)里程碑.A.生命周期目標(Lifecycle Objective)里程碑

D.產品發布(Product Release)里程碑 答案: C

14.信息系統開發的結構化方法的一個主要原則是().A.自頂向下原則 B.自底向上原則 C.分步實施原則 D.重點突破原則 答案: A

16.一般來說,占維護工作比例最高的是().A.糾錯性維護 B.適應性維護 C.完善性維護 D.預防性維護 答案: C

17.用戶開發應用系統的主要手段是().A.生命周期法 B.原型法 C.第四代語言 D.面向對象方法 答案: A

19.系統規劃的主要任務包括().A.明確組織的信息需求,制定系統總體結構方案 B.對系統進行經濟,技術和使用方面的可行性研究 C.選擇計算機和網絡系統的方案 D.確定軟件系統的模塊結構 答案: A

20.系統設計階段的主要成果是().A.用戶的決策方針 B.用戶的分析方案 C.系統設計說明書 D.系統總體設計方案

答案: C

21.信息系統建設的結構化方法中用戶必須參與的原則是用戶必須參與().A.系統建設中各階段工作 B.系統分析工作 C.系統設計工作 D.系統實施工作 答案: A

22.結構化生命周期法的主要缺點之一是().A.系統開發周期長 B.缺乏標準,規范

C.用戶參與程度低 D.主要工作集中在實施階段 答案: A 24.系統分析工作的全面總結和主要成果是().A.可行性研究報告B.數據詞典 C.系統說明書 D.系統詳細調查報告 答案: A 28.生命周期法的特點之一是().A.整個系統的開發工作是非勞動密集型的 B.系統開發時間短

C.對用戶需求的變更能做出迅速響應 D.適合大型復雜系統 答案: C 30.系統維護中要解決的問題來源于().A.系統分析階段 B.系統設計階段 C.系統實施階段 D.三者都包括

答案: D 38.下面哪一項不是系統設計階段的主要活動().A.系統總體設計 B.系統硬件設計 C.系統詳細設計 D.編寫系統實施計劃 答案: D 39.對于結構化設計思想的描述哪一項是錯誤的().A.在結構化設計中,模塊的功能應當簡單明確,易于理解

B.自頂向下,逐步求精

C.設計者應先設計頂層模塊

D.越下層模塊,其功能越具體,越復雜

答案: D 73.在系統生命周期的各階段中,花費費用和人力投入最多的階段是().A.分析與設計 B.編制程序 C.測試程序 D.系統維護

答案: A 78.在UML提供的圖中,()用于描述系統與外部系統及用戶之間的交互.A.用例圖 B.類圖 C.對象圖 D.部署圖

答案:A 79.在UML提供的圖中,()用于按時間順序描述對象間的交互.A.網絡圖 B.狀態圖 C.協作圖 D.序列圖（順序圖）答案:D 96.系統分析報告的主要作用是().A.系統規劃的依據 B.系統實施的依據 C.系統設計的依據 D.系統評價的依據 答案:C 95.繪制系統流程圖的基礎是().A.數據關系圖 B.數據流程圖 C.數據結構圖 D.功能結構圖 答案:B

9.信息系統開發的步驟是:在系統規劃后,循進行_____, _____, _____ ,_____ 工作.答案: 系統分析 系統設計 系統構建與實施 系統評價 13.信息系統規劃有哪些方法

答:用于企業信息系統規劃的方法主要有戰略分析法,即關鍵成功因素法(Critical Success Factors,CSF);企業分析法,即企業系統規劃法(Business System Planning,BSP);基于BPR的信息系統戰略規劃方法.其他的方法還有戰略目標集轉化法(Strategy Set Transformation,SST),企業信息分析與集成技術(BIAIT),投資回收法(R01)等.12.RUP中的軟件生命周期在時間上被分解為四個順序的階段,分別是:初始階段(Inception),細化階段(Elaboration),構造階段(Construction)和交付階段(Transition),每個階段結束于一個主要的里程碑(Major Milestones).構建階段結束時是第三個重要的里程碑:初始功能(Initial Operational)里程碑.A.生命周期目標(Lifecycle Objective)里程碑 B.生命周期結構(Lifecycle Architecture)里程碑 C.初始功能(Initial Operational)里程碑 D.產品發布(Product Release)里程碑

答案: C

14.信息系統開發的結構化方法的一個主要原則是().A.自頂向下原則 B.自底向上原則 C.分步實施原則 D.重點突破原則 答案: A

16.一般來說,占維護工作比例最高的是().A.糾錯性維護 B.適應性維護 C.完善性維護 D.預防性維護 答案: C

17.用戶開發應用系統的主要手段是().A.生命周期法 B.原型法 C.第四代語言 D.面向對象方法

答案: A

19.系統規劃的主要任務包括().A.明確組織的信息需求,制定系統總體結構方案 B.對系統進行經濟,技術和使用方面的可行性研究 C.選擇計算機和網絡系統的方案 D.確定軟件系統的模塊結構 答案: A

20.系統設計階段的主要成果是().A.用戶的決策方針 B.用戶的分析方案 C.系統設計說明書 D.系統總體設計方案 答案: C

21.信息系統建設的結構化方法中用戶必須參與的原則是用戶必須參與().A.系統建設中各階段工作 B.系統分析工作 C.系統設計工作 D.系統實施工作 答案: A 22.結構化生命周期法的主要缺點之一是().A.系統開發周期長 B.缺乏標準,規范

C.用戶參與程度低 D.主要工作集中在實施階段 答案: A 24.系統分析工作的全面總結和主要成果是().A.可行性研究報告B.數據詞典 C.系統說明書 D.系統詳細調查報告 答案: A 28.生命周期法的特點之一是().A.整個系統的開發工作是非勞動密集型的 B.系統開發時間短

C.對用戶需求的變更能做出迅速響應 D.適合大型復雜系統 答案: C 30.系統維護中要解決的問題來源于().A.系統分析階段 B.系統設計階段 C.系統實施階段 D.三者都包括 答案: D 38.下面哪一項不是系統設計階段的主要活動().A.系統總體設計 B.系統硬件設計 C.系統詳細設計 D.編寫系統實施計劃

答案: D 39.對于結構化設計思想的描述哪一項是錯誤的().A.在結構化設計中,模塊的功能應當簡單明確,易于理解

B.自頂向下,逐步求精

C.設計者應先設計頂層模塊

D.越下層模塊,其功能越具體,越復雜

答案: D 73.在系統生命周期的各階段中,花費費用和人力投入最多的階段是().A.分析與設計 B.編制程序 C.測試程序 D.系統維護

答案: A 78.在UML提供的圖中,()用于描述系統與外部系統及用戶之間的交互.A.用例圖 B.類圖 C.對象圖 D.部署圖 答案:A 79.在UML提供的圖中,()用于按時間順序描述對象間的交互.A.網絡圖 B.狀態圖 C.協作圖 D.序列圖（順序圖）

答案:D

96.系統分析報告的主要作用是().A.系統規劃的依據 B.系統實施的依據 C.系統設計的依據 D.系統評價的依據 答案:C

95.繪制系統流程圖的基礎是().A.數據關系圖 B.數據流程圖 C.數據結構圖 D.功能結構圖 答案:B

9.信息系統開發的步驟是:在系統規劃后,循進行_____, _____, _____ ,_____ 工作.答案: 系統分析 系統設計 系統構建與實施 系統評價 13.信息系統規劃有哪些方法

答:用于企業信息系統規劃的方法主要有戰略分析法,即關鍵成功因素法(Critical Success Factors,CSF);企業分析法,即企業系統規劃法(Business System Planning,BSP);基于BPR的信息系統戰略規劃方法.其他的方法還有戰略目標集轉化法(Strategy Set Transformation,SST),企業信息分析與集成技術(BIAIT),投資回收法(R01)等.2.信息系統規劃是指對組織目標、組織現狀進行分析，從而制定指導信息系統建設的總體規劃和信息系統長期發展展望。在眾多的信息系統規劃方法當中，具有代表性的主要有 企業系統規劃法、戰略目標轉移法、關鍵成功因素法。

4.信息系統建設的特點決定了信息系統建設要做大量復雜和細致的工作。信息系統建設主要包括 信息系統規劃、信息系統開發、信息系統維護 和 信息系統管理 四方面的工作。

1． UML統一建模語言共定義了哪兩類、哪八種圖形？

答：（1）靜態結構圖：類圖，對象圖，構件圖，實施圖

（2）動態行為圖：用例圖，順序圖，協作圖，狀態圖，活動圖

2.在下圖所示的用例分析類圖中，請指出各個概念類屬于哪一類，并分別解釋三種概念類的特點及概念?！笆蹠幚怼钡挠美治鲱悎D書目售書員售書界面產生待售圖書待售圖書開書單打印進程架存圖書出售圖書售出圖書答：屬于實體類的有：書目、架存圖書、代售圖書、售出圖書。

屬于邊界類的有：售書界面。

屬于控制類的有：產生待售圖書、出售圖書、開書單。三種概念類的特點及概念：

特點：概念類面向功能需求，一般不考慮性能要求，具有突出業務領域、突出概念性及大粒度的特征。概念：（1）實體類是信息系統表示客觀實體的抽象要素。它一般對應著在業務領域中的客觀事物，或是具有較穩定信息內容的系統元素。（2）邊界類是描述系統與參與者之間交互的抽象要素。邊界類只是對信息系統與參與者之間交互的抽象建模，并不表示交互的具體內容及交互界面的具體形式。

（3）控制類是表示信息系統對其他對象實施協調處理、邏輯運算的抽象要素。3．請根據下圖所示的概念模型，將其轉換為邏輯模型(即寫出其關系模式)。

編號姓名讀者職業電話住址郵編*待售圖書*類別單價出版日期書號架位架存冊數書號書名作者出版社1選書*架存圖書*11書目書單號冊數折扣率交款標記售書員答：根據其E-R圖，其關系模式為：

讀者(編號，姓名，職業，電話，住址，郵編)架存圖書(書號，架位，架存冊數)

待售圖書(書單號，冊數，折扣率，交款標記，售書員)書目(書號，書名，作者，出版社，出版日期，類別，單價)9.如圖，是在網上商店系統經理的用例圖如下：

網上購物系統顧客的功能用例

1.單一職責原則（Single Responsibility Principle, SRP）：

? There should never be more than one reason for a class to change.? 應該有且僅有一個原因引起類的變更 2.里氏替換原則 最正宗的定義：

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.（如果對每一個類型為S的對象o1，都有類型為T的對象o2，使得以T定義的所有程序P在所有的對象o1都代換成o2時，程序P的行為沒有發生變化，那么類型S是類型T的子類型。）里氏替換原則

通俗講，只要父類出現的地方子類就可以出現，而且替換為子類也不會產生任何錯誤或異常，使用者可能根本就不需要知道是父類還是子類。但是反過來就不行了，有子類出現的地方，父類未必就能適應。3.迪米特法則

迪米特法則的定義：

迪米特法則（Law of Demeter, LoD）也稱為最少知識原則，一個對象應該對其他對象有最少的了解。

一個類應該對自己需要耦合或調用的類知道得最少，被耦合或調用的類的內部如何復雜都和我沒有關系，那是你的事情，我就知道你提供的這么多public方法，我就調用這么多，其他的我一概不關心。4.開閉原則

開閉原則的定義：

一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。

一個軟件實體應該通過擴展來實現變化，而不是通過修改已有的源代碼來實現變化。5.依賴倒置原則

依賴倒置原則包含三層含義：

? 高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象；

? ? 抽象不應該依賴細節； 細節應該依賴抽象。

在java語言中，抽象就是指接口或抽象類，兩者都是不能直接被實例化的；細節就是實現類，實現接口或繼承抽象類而產生的類就是細節，其特點就是可以直接被實例化，也就是可以加上一個關鍵字new產生一個對象。6.接口隔離原則

接口隔離原則定義：

? ? 客戶端不應該依賴它不需要的接口；

類間的依賴關系應該建立在最小的接口上。

建立單一接口，不要建立臃腫龐大的接口，接口盡量細化，同時接口中的方法盡量少。它要求“盡量使用多個專門的接口”。專門接口指提供給每個模塊的都應該是單一接口，提供給幾個模塊就應該有幾個接口，而不是建立一個龐大的臃腫接口，容納所有的客戶端訪問。

1.在RUP中，軟件開發生命周期根據時間和RUP的核心工作流劃分為二維空間。橫軸表示項目的時間維，縱軸以內容來組織為自然的邏輯活動。

第四篇：系統分析與設計心得

讀《系統分析與設計方法》一書有感

作為一個軟件專業的學生，理解和掌握系統分析與設計的知識是必不可少的。在閱讀《系統分析與設計方法》一書中以及加上老師教導，我學到了很多東西，收獲不少。

系統就是由若干可以相互區別、由相互聯系并且各自獨立的單元組成各個子系統之間同樣是獨立而又相互聯系的。系統具有集合性、相關性、目的性、整體性和環境適應性。在開發完成一個軟件項目的過程中，系統工程必須經過開發階段、建造階段、運行階段、更新階段、維護階段。

系統分析與設計的方法主要包括結構化生命周期法（又稱瀑布法）、原型化方法（迭代法）、面向對象方法。

按時間過程來分，開發方法分為生命周期法和原型法，實際上還有許多處于中間狀態的方法。原型法又按照對原型結果的處理方式分為試驗原型法和演進原型法。試驗原型法只把原型當成試驗工具，試了以后就拋掉，根據試驗的結論做出新的系統。演進原型法則把試好的結果保留，成為最終系統的一部分。

按照系統的分析要素，可以把開發方法分為三類：

①面向處理方法（Processing Oriented，簡稱PO）。

②面向數據方法（Data Oriented，簡稱DO）。

③面向對象的方法（Object Oriented，簡稱OO）。

系統分析和設計應遵循的原則有：

系統開發是面向客戶的，應從客戶的角度考慮。

諸如系統開發生命周期之類的產品更新換代機構應該在所有的信息系統開發項目中建立起來。

信息系統開發的過程并不是一個順序的過程，它允許步驟的重疊和倒轉等。

如果系統的成功可能性受到很大限制時，應取消整個項目。文檔材料是系統開發生命周期中重要的可遞交成果，應加以重視。在本書的第一部分中，主要集中于系統分析和設計的整體描述，包括系統分析和設計方法的環境，信息系統構件，信息系統開發，項目管理。期中印象比較深刻的是系統開發過程的能力成熟度模型（CMMI）。信息系統和軟件的CMM框架用來幫助改善其系統開發過程的成熟度。CMM包括了五個成熟度等級：初始級、可重復級、已定義級、已管理級、優化級。期中，每個等級都是下一個等級的必須條件。

在軟件開發過程中需求分析階段是至關重要的一個階段，需求分析階段可能被稱為定義階段或者邏輯設計階段。需求分析階段的第一個任務是確定需求，在這個階段至少將目標轉換成為滿足其需要的功能需求和非功能需求的框架。在這個階段需要交付的成果是功能需求和非功能需求的草稿。在初步定義完了功能需求和非功能需求后，得排列需求的優先次序。如果一個項目落后于進度或者超出預算，知道哪個需求比其他需求更重要可能是很有用的。在排列需求的優先次序中可以使用到時間盒的技術。需求分析并不會真正的技術，因為企業需要具有快速適應不斷變化的需求和機會的能力。信息系統不能比企業自身的響應技術還慢。

在學習本書第二部分的時候，我了解到了需求分析在整個項目開發中的作用以及成為整個項目主導的因素。只要好的需求才能設計開發出好的軟件項目。在項目開發過程中，我們還可以利用圖表的形式來簡化方便人員的開發設計。期中有五種圖表是系統分析師常用的：類圖、用例圖、協作圖、順序圖、狀態圖。期中用例圖是用例建模的產物，它以圖形化的方式將系統描述成用、參與者（用戶）及其之間的關系。簡單的說就是用直立的小人來表示參與者（用戶），用圓圈來表示用例，他們之間以箭頭的形式來連接。關系包括了：關聯關系、擴展關系、使用關系、依賴關系、繼承關系。但是書上沒講到《include》關系，跟老師的講解有點出路。老師在講義上通過畫圖的方式很好的解釋了《include》和《extend》的關系。

數據建模這一章節中，我了解了數據建模的含義，它是一種為數據庫定義業務需求的技術。數據建模中比較重要的概念有實體和屬性之間的關系，關系是連接實體的一個時間，或者僅僅是存在于實體之間的邏輯關系。關系有很多種類，多對多、一對多、一對

一、等等。這些關系的圖形化符號記起來很不容易，但是我自己想到了一個比較容易記憶的簡單的方法。一個就用 “|”表示，零個就用“0”表示，多個就用“<”表示，然后根據相應的說明來選擇。比如零個或一個（0|），一個或多個（|<）。過程建模是一種組織和記錄數據的結構和流向的技術，它記錄系統的“過程”和有系統的“過程”實現的邏輯、策略和程序。期中也介紹到了數據流圖（DFD），數據流圖是一種描述通過系統的數據流以及系統實施的工作或處理過程的工具。我覺得數據流圖DFD的最大的優點就是容易閱讀，因為數據流圖僅有三種符號和一種連接：圓角矩形表示要完成的過程或者工作，正方形表示外部代理（系統的邊界），開放的方框表示數據存儲（可以是文件或者數據庫），箭頭表示數據流（可以是輸入和輸出，或者是表示到過程和來自過程）。統一建模語言UML的目的就是對面向對象系統進行可視化、評述、和文檔化。它適用于系統開發從需求規格描述道系統完成后測試的不同階段（需求分析階段、分析階段、設計階段、編程階段、測試階段）。UML2.0的模型主要圖包括了：用例圖、活動圖、類圖、對象圖、狀態機圖、組合結構圖、交互圖、定時圖、組件圖、部署圖和包圖。在理解這章的過程中，我感覺比較輕松，但是把一些關系，事件，實體等等用圖形化的形式表示出來還是非常難的。用UML設計面向對象系統時候，我們得準確的找到實體類、接口類、控制類、持續類、系統類和設計關系。在面向對象設計的過程中，主要包括了一下活動：對用例模型加以精煉以反映實現環境；建模支持用例情景的對象交互、行為和狀態；修改對象模型以反映實現環境。

前面說到需求分析是整個軟件項目開發中最重要的一環，其實我覺得可行性分析也是跟需求分析一樣的重要。因為信息是一個必須經過檢驗的重要資本投入，就像市場要檢驗一個新產品，系統分析員應該考慮投資能夠收回嗎？是否有其他投資能夠帶來比預期更高的回報。要說他們的區別，我個人覺得是：可行性分析是要決定“做還是不做”。需求分析是要決定“做什么，不做什么”?？尚行苑治鰣蟾嬗辛鶄€準則：運行可行性、文化可行性、技術可行性、進度可行性、經濟可行性。只有進行了可行性分析報告，才能夠確定企業是否要 做這個項目。如果說在可行性報告中顯示沒有成功的可能，那么就沒有必要再做需求分析了，整個項目就不會做下去了。進行可行性分析報告可以避免項目中途告終的結果，在系統開發過程中舉足輕重。

數據庫開發與設計這章，感覺書上講解的沒有老師講的詳細。書上并沒有提到范式，但是在課堂上我了解到數據庫設計的范式。有第一范式、第二范式、第三范式、BC范式等。等級越高，數據冗余越少，對系統調用數據庫更方便。數據庫的核心是DBMS，DBMS的核心是數據庫引擎，引擎響應專門的命令以創建數據庫結構，然后創建、讀取、修改和刪除數據庫中的記錄。DBMS使用數據定義語言（DDL）創建記錄類型、字段和結構化關系，還定義了數據庫視圖；DBMS還是用數據處理語言（DML）用來創建、讀取、修改和刪除數據庫中的記錄。但是并非所有數據庫的DBMS都被要求使用DDL和DML。看完這章，總結了一下建立關系數據庫模式的步驟，首先要為每個實體類型建立一張表，然后為每張表選擇一個主鍵，同時增加外鍵來表示一對多的關系，接著還可以建立幾個新表來表示多對多的關系，然后還得定義參照完整性約束，評價模式質量，并且進行必要的改進，最后為每個字段選擇適當的數據類型和取值約束。數據庫在系統開發的過程中是必不可少的，幾乎所有框架類型都得用到數據庫，它也是MVC框架的底層核心。

對于本書的還有一個比較映像深刻的就是UI（user interface），用戶界面設計。一個良好的用戶界面應該為用戶提供友好的使用方式，通過用戶界面用戶可以同應用程序打交道，處理輸入并且獲得輸出。Galitz曾經提出過用戶界面設計的原則：理解你的用戶及任務、讓用戶參與界面設計、在實際用戶中測試系統、進行迭代設計。記得以前大二的時候學習JAVA的時候，我曾經開發過基于圖形用戶界面（GUI）的聊天軟件，不過當時的界面設計完全設計的是隨心所欲，并沒有理論作為指導。在學習VB課程的時候學過UAR，簡單的了解了一些關于界面友好化設計的原則。這本書也給出了用戶界面設計過程的幾個步驟：1.以圖表形式描述用戶界面對話；2.原型化對話和用戶界面；3.獲得用戶反饋；4.如果需要，回到1步或者2步。

最后總結下，雖然我沒用把這本書的每一個地方都認真精讀，有些地方略讀的，但是看完整本書后我收獲很大。讀完《系統分析與設計方法》這本書再加上老師在課堂上的一些講解以及以前學習事件過程中的收獲，我對于系統分析與設計有了進一步的理解，能高屋建瓴的看待系統分析與設計整個過程的步驟以及增加了一些開發設計中的重要事件的理論知識。

對于系統分析的心得

第五篇：信息系統分析與設計

《信息系統分析與設計》考試題目及評分標準

下周一（11月26日）中午12點之前由班長或學習委員收齊各班紙質版本作業，周二收齊交給任課老師。

請注意論文封面、格式以及老師強調的論文重點，打印并裝訂好交給班長或學習委員?？荚囶}目：（任選其一）

設計一個銀行存取款管理信息系統。

要求具有下面的功能：①儲戶憑身份證在銀行開戶，銀行賬戶中保存儲戶姓名、聯系電話、家庭住址等基本信息，并保存儲戶每筆存取款業務數據。②儲戶存款時，需提交存折/卡號，由業務員在銀行賬戶及存折/卡上登記存款信息。③儲戶取款時，還需提交密碼，以確認身份，在驗證取款合法性后，更新銀行賬戶。④統計員每日統計存、取款情況，形成日存取款匯總表，提供給信貸管理部作為信貸主要依據。

設計一個物資采購及庫存管理業務管理信息系統。

要求具有下面的功能：①車間填寫領料單到倉庫領料，庫長根據用料計劃審批領料單，未批準的退回車間。②庫工收到已批準的領料單后，首先查閱庫存賬，若有貨，則通知車間前來領取所需物料，并登記用料流水賬；否則將缺貨通知采購人員。③采購人員根據缺貨通知，查閱訂貨合同單，若已訂貨，則向供貨單位發出催貨請求，否則就臨時申請補充訂貨。④供貨單位發出貨物后，立即向訂貨單位發出提貨通知。采購人員收到提貨通知單后，就可辦理入庫手續。接著是庫工驗收入庫，并通知車間領料。⑤此外，倉庫庫工還要依據庫存賬和用料流水賬定期生成庫存報表，呈送有關部門。

考核內容：

熟練掌握信息系統分析與設計的方法。具體考核的內容是：

1、編寫信息系統可行性報告。

2、編寫信息系統需求分析報告，繪制數據流圖。

3、編寫信息系統設計報告，繪制功能結構層次圖，數據庫設計，界面設計和硬件和軟件設計。

評分標準：

1、編寫信息系統可行性報告。（20分）

2、編寫信息系統需求分析報告，繪制數據流圖。（30分）

3、編寫信息系統設計報告，繪制功能結構層次圖。（20分）

4、數據庫設計（10分）

5、界面設計。（10分）

6、簡單的硬件和軟件設計。（10分）