本文內容均整理自西安交通大學軟件學院饒元老師的ppt中，僅供學習使用，請勿轉載或他用

考試重點知識

十個選擇:基本概念（20分）

綜合題（80分）：給一個場景，需要把一個案例從頭到尾設計出來就ok了

• 數據庫設計40
  • 1,2,3范式
  • RBAC
  • 完整性約束
  • sql
• 面向對象設計40
  • 整個系統DFD建模
  • 用例角度,用例描述
  • 事件流刻畫角度
  • activity圖
  • 時序圖
  • 類圖
  • 狀態圖
  • 以及一些基本原則（7個，類圖中的5+2?）對類圖做一些優化

如何復習

• 看書，形成知識框架，對于所有知識形成腦圖，如何與業務場景銜接，如何建立一個實際開發需要的東西
• 將開發好的系統重新設計出來
• 將上課設計的案例看老師如何設計，能不能找到更好的方法
• 圖書館找教材，UNL實訓教材，數據庫設計教材

假設有一個信息管理系統，不管什么端，

• 先將用戶找出來
• 確認需求

下面是從ppt上整理的一些基礎知識，雖然我整理的時候記得挺多的，把覺得重點知識都整理出來了，但是考試證明整理的都沒有用，主要還是去真正的設計一個系統，所以對于下面的概念可以選擇性閱讀，不要求背過，但是一定要理解，后面與UML相關的東西一定需要牢牢掌握，尤其是上面寫到的那些UML圖，必須必須必須得會！！！是在不會的話可以去圖書館借一些UML的書，然后對照著里面的例子去設計
我最后的總評成績由于平時作業的加分獲得了大學中的第一個滿分，對于這門科目的考試我的感覺就是考試時間非常的緊，看上面的考試重點就知道我們需要從頭去設計一個系統，包括功能模型，動態模型，靜態模型，而設計一個系統肯定不是一天兩天就能設計好的，因此需要在考試兩個半小時設計一個系統的難度可想而知了，這就要求如果想獲得一個比較好的成績就必須要能夠熟練的設計一個系統，包括數據庫，數據庫的優化，用例圖，活動圖，時序圖，類圖以及類圖的優化，這些東西必須必須必須掌握！！！不然考完試就等著郁悶吧
這門課程相對來說背誦的知識還是比較少的，大部分都是需要自己動手實踐的，這從平時作業也可以看的出來，饒老師非常鼓勵我們自己去動手完成一些東西，也非常強調coding的重要性，所以哪怕下面的東西都不會，也需要把上面的那些東西掌握了！！！

系統+設計

什么是系統

定義

系統是相互聯系，相互作用的諸元素的綜合體

最佳定義

• 系統是指由相互聯系、相互作用的若干組成部分構成的有機整體，整個整體具有其各個組成部分所沒有的新性質和功能，并和一定的換將發生交互作用
• 系統各要素之間、要素與整體之間，以及整體與環境之間，存在著一定的有機聯系，從而在系統的內部和外部形成一定的結構和秩序
  • 要素是指組成系統的基本成分，是系統形成的基礎。要素和系統的關系，是部分與整體的關系，他們相互聯系，相互作用
  • 功能是指系統與外部環境在相互聯系和作用的過程中產生的效能
  • 活動是系統形成、發展、變化的動態過程，這個過程通過系統內部諸要素之間、要素與系統之間以及系統與環境之間相互影響、相互作用而完成的。
  • 信息時值事務存在的方式或運動狀態以及這些方式、狀態的直接或簡介的傳播與表述
  • 環境是指出于系統邊界之外并和系統進行著物質、能量和信息交換的所有事務

系統的特征

三個特性

• 多元性
  • 系統是多樣性的統一，差異性的統一
• 相關性
  • 系統不存在孤立元素組分，所有元素或組分間相互依存、相互作用、相互制約
• 整體性
  • 系統是所有元素構成的復合統一整體

軟件系統核心要素

軟件系統：指在一定的軟件開發與應用環境下，為了達到某一目的而相互聯系、相互作用的若干個軟件要素所組成的有機整體

軟件系統的要素

涌現

1+1大于2

群體的需求是一種涌現現象，即整體大于部分之和，這種高層次具有的屬性、特征、行為和功能還原到低層級就不復存在

分析之責

• 客戶需求
  • 在需求分析階段，需要挖掘出客戶真正在乎的需求，最好對需求進行分優先級
  • 而且需求并不是一成不變，項目過程中增減需求是平常的事，但是由此造成的影響要評估并更新文檔
• 假設的條件
  • 有時項目執行中會因為某些需要客戶或第三方完成的事情不具備，而造成項目延遲
  • 這就需要在合同中對這些結社特別說明，以避免后面的責任不清
• 環境的限制
  • 這點尤其重要，常常在分析階段被忽略
  • 盡可能挖掘限制條件，會避免后面階段很多的問題
• 風險
  • 風險分析對于軟件項目管理是決定性的
  • 風險分析實際上就是貫穿在軟件過程中的一系列風險管理步驟，其中包括：風險識別、風險估計、風險管理策略、風險解決和風險監督等

設計之要

模型驅動->靈活且可擴展

設計原則

軟件系統分析與設計的主要方法

系統開發生命周期

功能分解法

• 以系統需要提供的功能為中心組織系統
• 首先定義各種功能，然后把功能分解為子功能
• 對較大的子功能進一步分解，直到可給出明確的定義
• 設計功能、子功能所需要的數據結構
• 定義功能、子功能之間的接口
• 作為一種早期的建模方法，沒有明確地區分分析與設計

結構化方法

• 結構化分析（structured analysis，SA）
• 結構化設計（structure design，SD）

結構化分析又稱為數據流法，其基本策略是跟蹤數據流，即研究問題域中的數據如何流動，以及在各個環節上進行何種你那個處理，從而發現數據流和加工。得到的分析模型是數據流圖（DFD），主要的模型元素是數據流，加工，外部實體及存儲，外加處理說明和數據字典

結構化設與功能分解法基本相同，基于模塊的概念建立設計模型，分為概要設計和詳細設計

• 概要設計：確定系統中包含哪些模塊以及模塊之間的調用關系，得到模塊結構圖（MSD）
• 詳細設計：描述每個模塊內部的數據結構和操作流程

結構化方法的優缺點

• 優點
  • 強調研究問題域，并由嚴格的法則
• 缺點
  • 仍然是間接映射問題域
  • 分析與設計的概念不一致，從分析到設計的過渡比較困難
  • 數據流和加工的數量太多，引起分析文檔的膨脹

信息建模法

信息建模法（information modeling）

• 核心概念是實體和關系。實體描述問題域中的事務，關系描述事務之間在數據方面的聯系，都可以帶有屬性
• 發展之后的方法也把實體稱為對象，并使用了類型和子類型的概念，作為實體（對象）的抽象描述

信息建模法已經很接近面向對象方法，因此有的文獻也把它稱為一種面向對象方法，但是有以下差別：

• 強調的重點是信息建模和狀態建模，而不是對象建模
• 實體中只有屬性沒有操作
• 只有屬性的繼承，不支持操作的繼承
• 沒有采用消息通訊

面向對象方法

• 面向對象的分析（object oriented analysis，OOA）
• 面向對象的設計（object oriented design，OOD）

運用對象、類、繼承、封裝、聚合、關聯、消息、多態等概念來構造系統

• 把問題域中的事務抽象為對象，作為系統的基本構成單位，其屬性和操作刻畫了事務的靜態特征和動態特征----完整地刻畫了問題域中的事務
• 用類作為對象的抽象描述，建立他們之間的繼承、聚合、關聯、消息等關系----如實地表達了問題域中事務之間的各種關系

不同建模方法的比較

需求工程

需求語義斷連現象的分析

軟件分析本質：識別并解決問題

• 語義斷連是需求分析中常見的現象
  • 需求分析中所有的涉及物需要明確定義，避免不一致或二義性的發生
  • 劃清角色與系統的邊界，形成完整的業務關聯場景至關重要
• 需求目標的缺失是需求分析中常見的現象
  • 需求中邊界的確實，往往會造成全局性的失敗
  • 需求分析中必須避免目標確實問題的發生
  • 建立起所涉及物之間的關系，形成完整的業務關聯場景至關重要

語義斷連錯誤的原因

形式化需求分析方法

• 一個軟件包含了所有功能的集合，同時包含了實現所有功能的所有方法和算法描述。
• 需求分析師依據于用戶需求，經過需求問題識別，進行分析、消化與綜合，指定規格說明，評審，分為四個階段，形成用戶需求與設計同步，設計滿足用戶的需求目標

需求的重要性

• 開發軟件系統最困難的部分就是準確說明開發什么。
• 最困難的概念性工作是編寫出詳細的需求，包括面向用戶，面向機器和其他軟件系統的接口。

需求關鍵特征屬性

軟件需求特征屬性

• 層次化
• 過程（評審vs版本）
• 追蹤vs狀態
• 客戶角色

層次化

需求又分為業務需求，用戶需求，功能需求以及系統需求，此外還包括一些非功能需求

• 業務需求
  • 表示組織或客戶高層次的目標，業務需求描述了組織為什么要開發一個系統，即組織希望達到的目標
• 用戶需求
  • 描述的是用戶的目標，或用戶要求系統必須能完成的任務
• 功能需求
  • 規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求
• 系統需求
  • 用于描述包含有多個子系統的產品（即系統）的頂級需求

過程

需求的開發是一個不斷反復的過程，主要是企業向開發商提交初步的需求，開發商針對已提出的需求編寫需求規約并交付企業，企業經過評審后提出意見，開發商對于需求規約進行一次次的修改，往復提交，直到雙方達成一致

追蹤vs狀態

需求跟蹤是指跟蹤一個需求使用期限的全過程，需求跟蹤包括編制每個需求同系統元素之間的聯系文檔，這些元素包括其他類型的需求，體系結構，其他設計部件，源代碼模塊，測試，幫助文件等。需求跟蹤為我們提供了由需求到產品實現整個過程范圍的明確查閱的能力。在跟蹤的過程中最重要的一個屬性便是需求的狀態，這個用來標識需求當前情況的一個屬性，可以幫助我們更好了解需求變更的過程以及當前情況

客戶角色

• 用戶：可以細分為三種
  • 客戶（customer）
  • 最終用戶（the end user）
  • 間接用戶（或稱關系人）
• 掏錢買軟件的用戶稱為客戶，而真正操作軟件的用戶叫最終用戶。客戶與最終用戶可能是同一個人也可能不是同一個人
• 簡介用戶：既不掏錢買該軟件，也不適用該軟件，但是他可能對軟件產品有很大的影響
• 利益攸關人：如果項目規模比較大，那么項目所涉及到的軟件開發放與最終用戶放一些人員的工作與利益，這些人稱為利益相關人

與客戶打交道的主要目的

• 一是獲取明確需求（業務功能需求分析+心理需求分析）
• 二是簽合同
• 三是順利驗收
• 四是為未來的項目留下余地

需求職責

需求工程

什么是需求工程

• 把所有與需求直接相關的活動統稱為需求工程
• 需求工程中的活動可以分為兩大類
  • 一類屬于需求開發
    • 需求調查
    • 需求分析
    • 需求定義
  • 一類屬于需求管理
    • 需求確認
    • 需求跟蹤
    • 需求變更控制

需求開發過程域

• 需求開發的目的是通過調查與分析，獲取用戶需求并定義產品需求
• 需求調查的目的是通過各種途徑獲得用戶的需求信息（原始材料），產生《用戶需求說明書》
• 需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節等。常見的需求分析方法有“問答分析法”和“建模分析法”兩類
• 需求定義的目的是根據需求調查和需求分析的結果，進一步定義準確無誤的產品需求，產生《產品需求規格說明書》。系統設計人員將依據《產品需求規格說明書》開展系統設計工作

需求管理過程域

• 需求管理的目的是在客戶和開發方之間建立對需求的共同理解，維護需求與其他工作成果的一致性，并控制需求的變更
• 需求確認是指開發方和客戶共同對需求文檔進行評審，雙方對需求達成共識后做出書面承諾，使需求文檔具有商業合同效果
• 需求跟蹤是指通過比較需求文檔與后續工作成果之間的對應關系，建立與維護“需求跟蹤矩陣”，確保產品依據需求文檔進行開發
• 需求變更控制是指依據“變更申請–審批–更改–重新確認”的流程處理需求的變更，防止需求變更失去控制而導致項目發生混亂

需求開發方法

需求服務質量差距模型

需求獲取的方法

• 對現有的文檔，表單和數據庫進行抽樣

• 研究和現場訪問

• 對工作環境的觀察

• 調查問卷

• 采訪

• 原型設計（ProtoTyping）

  • 原型設計是交互設計師與PD、PM、網站開發工程師溝通的最好工具。而該塊的設計在原則上必須是交互設計師的產物，交互設計以用戶為中心的理念會貫穿整個產品。利用交互設計師專業的眼光與經驗直接導致該產品的可用性。

  • 應該是按照已經有了的模板進行設計？

• 聯合需求規劃（Joint requirements planning，JRP）

如何開展需求調查

準備需求

首先，需求分析員應當起草需求調查問題表，將調查重點鎖在該問題表內

• 問題表可以有多份，隨著調查的深入，問題表將不斷被細化
• 問題選擇表應當以選擇題和是非題為主

其次，需求分析員應當確定需求調查的方式

• 與用戶交談，向用戶提問題
• 向用戶群體發放調查問卷
• 參觀用戶的工作流程，觀察用戶的操作
• 與同行、專家交談，聽取他們的意見
• 撰寫《需求調查計劃》
• 特別留意：不要漏掉典型的用戶

執行調查

需求分析員與用戶，面談時應當注意一下事項

• 應該事先了解用戶的身份、背景，以便隨機應變
• 需求調查應該先了解宏觀問題，再了解細節問題

根據調查記錄完成《用戶需求說明書》

需求獲取的重要工具----上下文圖（DFD）

角色->需求->功能->系統邊界

如何進行需求分析

需求分析是指在需求開發過程中，對所獲取的需求信息進行分析，及時排出錯誤和彌補不足，確保需求文檔正確地反映用戶的真實意圖

撰寫《產品需求規格說明書》

需求分析方法有兩類

• 文檔分析法
• 建模分析法

問答分析法

• 問答分析最重要的問題是是什么和為什么
  • 每個需求都應當用陳述句說明"是什么"，如果“是什么”的內涵不夠清晰，則應該補充說明“不是什么”
  • 追究“是什么”和“為什么”的目的是獲得正確、清晰的需求

建模分析法

• 需求建模就是指用圖形符號來表示，刻畫需求
• 建模分析方法主要有兩大類
  • 結構化分析法
  • 面向對象分析法
• 在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用

需求分析工具

• 業務流程圖、泳道圖：反映業務信息處理的具體過程

• 數據流圖

• WBS

• E-R圖，數據模型包括三種互相關聯的信息：數據對象，描述對象的屬性，描述對象間相互連接的關系。在需求分析階段進行數據庫邏輯設計過程中，使用E-R圖，可以定義一個實體模型

• 用例驅動的分析

關于Use-Case的描述方法

用戶動作與系統響應反映了Use-Case的實現策略的核心機制

候選流程反映了系統的健壯性，是區分系統設計好壞的一個前提，需要體現在活動圖中

需求的好壞直接決定了設計的好壞

管理關鍵問題分析

需求管理控制過程

• 版本控制
  • 確定需求文檔版本
  • 確定單個需求文檔版本
• 變更控制
  • 建議變更
  • 分析影響
  • 做出決策
  • 交流
  • 合并
  • 測量需求的穩定性
• 需求跟蹤
  • 定義對其他需求的階段鏈
  • 定義對其他系統元素階段
  • 注意此處跟蹤的狀態表示階段
• 需求狀態跟蹤
  • 定義需求狀態
  • 跟蹤需求每一個狀態
  • 注意此處狀態是審核狀態

需求確認

• 需求確認：是指開發方和客戶方共同對《產品需求規格說明書》及進行評審，雙方對需求達成共識后做出承諾
• 需求承諾具有商業合同的效果

需求跟蹤

• 建立“需求–設計–編程–測試”之間的一致性，確保所有的工作成果符合用戶需求

• 需求跟蹤有三種方式：

  • 正向跟蹤，檢查《產品需求規格說明書》中的每個需求是否都能在后繼工作成果中找到對應點

  • 逆向跟蹤：檢查設計文檔、代碼、測試用例等工作成果是否都能在《產品需求規格說明書》中找到出處

  • 建立與維護需求跟蹤矩陣：需求跟蹤矩陣保存了需求與后繼成果的對應關系

小結

軟件開發影響因素

軟件失敗的原因與好設計的原則

IT系統不成功的六大類型

• 已經開始的項目，在未結束之前便放棄；
• 項目已經開發完成，但從未使用；
• 項目已經開發完成并投入使用，但是在很短的時間內就放棄使用；
• 所開發的項目并未達到預期的目標，無法完全提供設計的功能；
• 項目開發時間比預計延長較多；
• 項目開發經費不斷增加。

產生問題的主要原因

好設計的十項原則

軟件系統開發的十大原則

項目管理的”三五九“

• 三個約束條件
  • 是范圍、時間及成本
• 五個過程組
  • 啟動、計劃、控制、實施、收尾
• 九大知識領域
  • 整體管理、范圍管理、時間管理、成本管理、質量管理、人力資源管理、溝通管理、風險管理、采購管理

軟件可行性研究

概念

可行性研究是指系統建設項目確立之前對系統建設的必要性和可能性以及可能的候選方案從整個系統周期的角度進行分析和評價，為企業信息化決策提供科學的依據，并據此由系統開發人員形成書面的可行性研究報告

任務

是根據確定的問題，通過分析新系統需要的信息技術、可能發生的投資和費用、產生的效益，確定將開發的軟件系統成功的可能性

目的

降低風險，用最小的代價在最小的時間內確定問題是否能夠解決

前提

明確的要求、目標、假定、限制

數據庫設計

問題引入基本概念

• 數據：是客觀事物的符號表示。在計算機科學中指的是所有能輸入到計算機中被計算機程序處理的符號的總稱

• 數據元素：是數據的基本單位，在程序中通常作為一個整體來進行考慮和處理

• 一個數據元素可以由若干個數據項組成。

  • 數據項是數據的不可分割的最小單位。
  • 數據項是對客觀事務某一方面特性的數據描述

• 數據對象：是性質相同的數據元素的集合，是數據的一個子集

• 數據結構：是指相互之間具有一定聯系的數據元素的集合。

  • 元素之間的相互聯系稱為邏輯結構

  • 數據元素之間的邏輯結構有四種基本類型

• 數據類型：指的是一個值的集合和定義在該值集上的一組操作的總稱

• 抽象數據類型（ADT）：是指一個數學模型以及定義在該模型上的一組操作

數據建模的基本概念

• 數據建模：是一組組織和記錄系統數據的技術，即數據庫建模
• 實體關系圖（ERD）：是一種利用符號標記實體與關系，實現對數據刻畫的一種數據模型
• 實體：是我們需要收集數據與存儲數據的人，地點，對象，事件或概念的類
• 屬性：是實體的描述性的性質或特征，同義詞包括要素，性質或域
• 組合屬性：由其他屬性組成的屬性，它在不同的數據建模中有不同的名稱：串聯屬性，合成屬性，數據結構

屬性的特征

• 數據類型：是屬性的一個參數，定義了這個屬性中可以存儲什么類型的數據
• 域：是屬性的一個參數，定義了這個屬性可以取的合法數據值
• 默認值：如果用戶沒有指定值的話，將被記錄的值
• 鍵：是一個屬性（或一組屬性），他們對每個實體實例具有唯一的值，也稱為標識符
• 候選鍵：是一組可以作為一個實體主鍵的鍵，也稱為候選標識符
• 主鍵：是最終用來唯一表示或者確定一個實體實例的候選鍵
• 替代鍵：是沒有被選中作為主鍵的其他候選鍵

關系的特征

• 關系：是存在于一個或多個實體之間的業務聯系
• 聚數：定義了一個實體相對于另一個關聯實體的某個具體指的最大或最小具體值的數量
• 度數：是參與某一個關系的實體數量
  • 二維關系：兩個實體之間的關系
  • 單一實體之間的關系，即遞歸關系
  • 頁存在多個實體之間，即多維關系

外鍵的特征

• 外鍵，是一個實體的主鍵，但被復制到另一個實體以確定一個關系實例
  • 外鍵總是與另一個實體的主鍵匹配
  • 獲得外鍵的實體為子實體
  • 提供外鍵的實體為父實體
• 非確定性關系：是每個參與關系的實體都有各自的獨立主鍵關系
  • 不共享主鍵屬性
  • 實體被稱為獨立實體（強實體）
• 確定性關系：是父實體提供其轉稱為子實體的主鍵的一部分的關系
  • 不共享主鍵屬性
  • 子實體被稱為關聯實體（弱實體）
• 非特定關系：是一個實體的多個實例同另一個實體的多個實例相關聯的關系，即多對多的關系

實體的泛化

• 泛化（Generalization）：是指將幾類實體公共的屬性組合成獨立的實體
• 超類（SuperType）：是一個實體，其實例存儲了一個或多個實體子類的公共屬性
• 子類（SubType）：是一個實體，其實例從一個實體超類中繼承了一些公共屬性

信息工程設計核心視角

在軟件系統中需要處理的數據是系那是世界中存在的事物及其聯系的反映

人們通常將于數據處理有關的領域分為三個世界

• 現實世界
• 信息世界
• 數據世界

現實世界

現實世界是存在于人們頭腦之外的客觀世界，現實世界中的事務可分成對象和性質兩大類

• 對象可以是人、是物，還可以是實際的東西或者概念
• 對象還可以指事務與事務之間的聯系
• 性質則是指事務的性質或特征

信息世界

信息世界也叫做觀念世界，是現實世界在人們頭腦中的反映

• 客觀世界中的事務在信息世界中叫做實體，反映事務之間聯系的叫做實體模型
• 實體是由若干屬性的屬性值組成
• 屬性是實體某一方面的特征，相應于事務的性質

數據世界

數據世界則是信息世界中信息的數據化，顯示世界中的事務及其聯系在數據世界中用數據模型描述

• 描述每一實體的數據稱為記錄，描述屬性的數據叫做數據項或字段
• 與實體集相對的稱為文件

信息工程設計的方法和原則

數據庫設計的基本步驟

數據庫設計分成6個階段

• 需求分析
• 概念結構設計
• 邏輯結構設計
• 物理結構設計
• 數據庫實施
• 數據庫運行和維護

需求分析和概念設計獨立于任何數據庫管理系統

E-R方法和實體模型

規范化的目的

• 消除數據冗余：即消除表格中的數據重復
• 消除多義性：使關系中的屬性含義清楚、單一
• 使關系單純化：讓每個數據項只是簡答的數或字符串，而不是組項或重復組
• 方便操作：是數據的插入、刪除與修改操作可行并方便
• 使關系模式更靈活：易于實現接近自然語言的查詢方式

規范化的三個條件

• 表格中每個信息項必須是一個不可分割的數據項
• 表格中每一列中所有信息項必須是同一類型，各列的名字（屬性名）互異，列的次序任意
• 表格中各行互不相同，行的次序任意

第一范式

定義：數據庫中的所有字段都是單一屬性，不可再分的，這一個單一屬性是由基本的數據類型所構成的

關系中所有的屬性都是單純域，即不出現“表中套表”

第二范式

定義：數據庫的表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴

部分函數依賴是指存在著組合關鍵字段中的某一個關鍵字段決定其他非關鍵字段的情況

第三范式

定義：實體的非主屬性的值不依賴于任何其他非主鍵屬性

注：所有非主屬性對任何候選管關鍵字都不存在傳遞依賴

好的數據模型評價標準

簡單高效，無冗余或少冗余，靈活且可擴展

數據庫的完整性設計

• 為了防止不符合規范的數據進入數據庫，在用戶對數據進行插入、修改、刪除等操作時，DBMS自動按照一定的約束條件對數據進行監測，使不符合規范的數據不能進入數據庫，以確保數據庫中存儲的數據正確性、有效性、相容性
• DBMS提供一種機制來檢查DB中的數據，看其是否滿足語義規定的條件。這些加在DB數據之上的語義約****束條件稱為DB完整性約束條件，它們作為模式的一部分存入DB中。有一些需要在應用程序中來限制。
• 而DBMS中檢查數據是否滿足完整性條件的機制稱為完整性檢查。

非空約束

Unique約束

主鍵約束

primary約束與unique約束

• 在一個表中，只能定義一個primary key約束，但可以定義多個unique約束
• 對于指定為primary的一個列或者多個列的組合，其中任何一個列都不能出現空值，而對于unique所約束的唯一鍵，則允許為null，只是null值最多有一個

外鍵約束

check（校驗）約束：

• 用來檢查字段值所允許的范圍。
• DBMS每當執行delete, insert或update語句時，都對這個約束過濾。如果為true，則執行。否則，取消執行并提示錯誤。

完整性的分類

• 實體完整性：規定表中的每一行在表中是唯一的實體
• 域完整性：是指表中的列必須滿足某種特定的數據類型約束，其中約束又包括取值范圍、精度等規定
• 參照完整性：是指兩個表的主鍵和外鍵的數據應一致，保證了表之間的數據的一致性。防止了數據丟失或無意義的數據在數據庫中擴散
• 用戶定義的完整性：不同的關系數據庫系統根據應用環境的不同，往往還需要一些特殊的約束條件。用戶定義的完整性即是針對某個特定關系數據庫的約束條件，它反映某一具體應用必須滿足的語義要求

完整性約束條件包括

• 靜態完整性約束和動態完整性約束
  • 靜態約束是指對DB每一確定狀態的數據所應滿足的約束條件。值的約束和結構約束均屬靜態約束。
  • 動態約束是指DB從一種狀態轉變為另一種狀態時,新、舊值之間所應滿足的約束條件，它是反映DB狀態變遷的約束。例如，當更新職工工資時，要求新工資值不低于舊工資值，并且當舊工資值超過2500元時，保持不動
• 立即執行完整性約束和延遲執行完整性約束
  • 立即執行約束（Immediate Constraints）是在執行用戶事務處理程序時，某一更新語句執行完后馬上對此數據所應滿足的約束條件進行完整性檢查。
  • 延遲執行約束(Deferred Constraints)是指在整個事務處理程序執行完畢后，再對約束條件進行檢查，結果正確才能提交出來。

數據庫安全性設計

用戶標識與鑒別

它是系統提供的最外層安全保護措施。其方法是由系統提供一定的方式讓用戶標識自己的名字或身份。每次用戶要求進入系統時，由系統進行核對，通過鑒定后才提供機器使用。為了進一步核實用戶，系統常常要求用戶輸入口令（Password）。

數據加密

數據加密是防止DB中數據在存儲和傳輸中失密的有效手段。

加密方法主要有兩種：

• 一種是替換方法，該方法使用密匙(Encryption Key)將明文中的每一個字符轉換為密文中的一個字符；
• 另一種是置換方法，該方法僅將明文的字符按不同的順序重新排列。單獨使用這兩種方法的任意一種都是不夠安全的。

但是將這兩種方法結合起來就能提供足夠好的安全程度。

存取控制

• 定義用戶權限：用戶權限是指不同的用戶對于不同的數據對象允許執行的操作權限。系統必須提供適當的語言定義用戶權限，這些定義經過編譯后存放在數據字典中，被稱作安全規則或授權規則
• 合法權限檢查：每當用戶發出存取DB的操作請求后（請求一般應包括操作類型、操作對象和操作用戶等信息），DBMS查找數據字典，根據安全規則進行合法權限檢查，若用戶的操作請求超出了定義的權限，系統將拒絕執行上述操作。

視圖機制

進行存取權限控制時可以為不同的用戶定義不同的視圖（View），把數據對象限制在一定的范圍內，即通過視圖機制把要保密的數據對無權存取的用戶隱藏起來，從而自動地對數據提供一定程度的安全保護。一般設計階段中有用戶視圖設計。

審計

審計功能把用戶對DB的所有操作自動記錄下來放入審計日志(Audit Log)中。DBA可以利用審計跟蹤的信息，重現導致DB現有狀況的一系列事件，找出非法存取數據的人、時間和內容等

面向對象設計

UML的圖模型

用例圖

• 用例圖是被稱為參與者的外部用戶所能觀察到的系統功能的模型圖
• 用例圖列出系統中的用例和系統外的參與者，并顯示哪個參與者參與了哪個用例的執行

活動者(角色,Actor)：系統外部的參與者，可以是人、外部硬件、其他系統，甚至時間

關系

• 包含：基用例可以看到包含用例，并需要依賴于包含用例的執行結果
  • 當某個都會做片段在多個用例中都出現了的時候，可以將其分離出來從而形成一個單獨的用例
• 擴展：使用擴展用例，可以在不改變基用例的同時，根據需要自由地向用例中添加行為

用例描述

類圖

類圖以反映類的結構(屬性、操作)以及類之間的關系為主要目的，描述了軟件系統的結構，是一種靜態建模方法

類圖中的事物及解釋

從上到下分為三部分，分別是類名、屬性和操作。類名是必須有的

類的關系描述

類之間主要存在的關系：依賴、關聯、聚合、組合、實現和泛化。

活動圖

描述系統的動態行為。包含活動狀態(ActionState)，活動狀態是指業務用例的一個執行步驟或一個操作，不是普通對象的狀態。

時序圖

順序圖用來表示用例中的行為順序。當執行一個用例行為時，順序圖中的每條消息對應了一個類操作或狀態機中引起轉換的事件。

順序圖展示對象之間的交互，這些交互是指在場景或用例的事件流中發生的。順序圖屬于動態建模。

時序圖的組成

狀態機圖

• 狀態機：
  • 用于描述一個對象在其生存期間的動態行為，表現對象響應事件所經歷的狀態序列以及伴隨動作
• 狀態機圖
  • 用來顯示狀態機，一個狀態機可用多張狀態圖描述
  • 狀態圖說明對象在它的生命期中響應事件所經歷的狀態序列

事務及解釋

面向對象的設計目標與原則

設計的總體目標

面向對象設計基本原則

• 單一職責原則
• 開放封閉原則
• 接口隔離原則
• 依賴倒置原則
• 李氏替換原則
• 合成/聚合復用原則
• 迪米特原則

單一職責原則

一個類，最好只做一件事，只有一個引起它變化的原因

單一職責，強調的是職責的分離，在某種程度上對職責的理解，構成了不同類之間耦合關系的設計關鍵，因此單一職責原則或多或少成為設計過程中一個必須考慮的基礎性原則

如果一個類中包含多個職責不同的方法，則把這個類拆分成多個類，保證每個類中只包含有一個職責的方法

開閉原則

• 考慮設計中什么可能會發生變化，將其封裝起來，考慮允許什么發生而不讓這一變化導致重新設計
• 聲明的變量的類型、函數的參數類型、函數的返回類型等要盡量使用抽象類和接口

接口分離原則

設計時采用多個與特定客戶類有關的接口比采用一個通用的接口好

一個類對另外一個類的依賴應建立在最小的接口上

將一個復雜的接口拆分成很多小接口

依賴倒置原則

• 高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象
• 抽象不應該依賴于細節，細節應該依賴于抽象

某種意義上，依賴倒轉原則是達到“開–閉原則”的途徑

依賴關系應盡可能依賴接口（或抽象類），而不是某個具體的類

里氏替換原則

子類可以擴展父類的功能，但不能改變父類原有的功能

在軟件中將一個基類替換成它的子類對象，程序將不會產生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那么它不一定能夠使用基類對象

里氏替換原則是繼承復用的基石：只有當衍生類可以替換掉基類，軟件單元的功能不受影響時，基類才能真正被復用

子類中對于一個方法的訪問優先級應該不小于父類中的訪問優先級

應注意的問題

• 子類的所有方法必須在父類中聲明，或子類必須實現父類中聲明的所有方法。根據里氏替換原則，為了保證系統的擴展性，在程序中通常使用父類來進行定義，如果一個方法只存在子類中，在父類中不提供相應的聲明，則無法在以父類定義的對象中使用該方法。
• 我們在運用里氏替換原則時，**盡量把父類設計為抽象類或者接口，讓子類繼承父類或實現父接口，并實現在父類中聲明的方法，**運行時，子類實例替換父類實例，我們可以很方便地擴展系統的功能，同時無須修改原有子類的代碼，增加新的功能可以通過增加一個新的子類來實現。
• 在系統設計時，遵循里氏替換原則，盡量避免子類重寫父類的方法，可以有效降低代碼出錯的可能性。

迪米特法則

迪米特法則也稱為最少知識原則，一個對象應對其他對象有最少的了解

由右側改進為左側

合成/聚合復用原則

要盡量使用合成/聚合，盡量不要使用繼承。

合成/聚合復用原則就是在一個新的對象里面使用一些已有的老對象，使之成為新對象的一部分；新的對象通過向這些老對象的委派，達到復用已有功能的目的。

監聽器

main(){ 聯想 聯想1 = new 聯想() 惠普 惠普2 = new 惠普()if(lian) lian.print()else if (hui) hui.print }interface dayinji{print() }class lianxiang implements dayinji{print(){lainxinagprint} }class huipu implements dayinji{print(){lainxinagprint} }main(){聯想 聯想1 = new 聯想();惠普 惠普2 = new 惠普();print(Lianxiang); }print(dayiji dd){dd.print(); }parent aa = new children(); aa.eat()class parent{eat(){sout(parent)return a+b;} }class children extends parent{eat(){sout(children);return a-b;} }

總結

以上是生活随笔為你收集整理的软件系统分析与设计考试重点、复习指导及复习笔记汇总的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。