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

考試重點知識

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

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

• 數(shù)據(jù)庫設計40
  • 1,2,3范式
  • RBAC
  • 完整性約束
  • sql
• 面向?qū)ο笤O計40
  • 整個系統(tǒng)DFD建模
  • 用例角度,用例描述
  • 事件流刻畫角度
  • activity圖
  • 時序圖
  • 類圖
  • 狀態(tài)圖
  • 以及一些基本原則（7個，類圖中的5+2?）對類圖做一些優(yōu)化

如何復習

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

假設有一個信息管理系統(tǒng)，不管什么端，

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

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

系統(tǒng)+設計

什么是系統(tǒng)

定義

系統(tǒng)是相互聯(lián)系，相互作用的諸元素的綜合體

最佳定義

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

系統(tǒng)的特征

三個特性

• 多元性
  • 系統(tǒng)是多樣性的統(tǒng)一，差異性的統(tǒng)一
• 相關(guān)性
  • 系統(tǒng)不存在孤立元素組分，所有元素或組分間相互依存、相互作用、相互制約
• 整體性
  • 系統(tǒng)是所有元素構(gòu)成的復合統(tǒng)一整體

軟件系統(tǒng)核心要素

軟件系統(tǒng)：指在一定的軟件開發(fā)與應用環(huán)境下，為了達到某一目的而相互聯(lián)系、相互作用的若干個軟件要素所組成的有機整體

軟件系統(tǒng)的要素

涌現(xiàn)

1+1大于2

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

分析之責

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

設計之要

模型驅(qū)動->靈活且可擴展

設計原則

軟件系統(tǒng)分析與設計的主要方法

系統(tǒng)開發(fā)生命周期

功能分解法

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

結(jié)構(gòu)化方法

• 結(jié)構(gòu)化分析（structured analysis，SA）
• 結(jié)構(gòu)化設計（structure design，SD）

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

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

• 概要設計：確定系統(tǒng)中包含哪些模塊以及模塊之間的調(diào)用關(guān)系，得到模塊結(jié)構(gòu)圖（MSD）
• 詳細設計：描述每個模塊內(nèi)部的數(shù)據(jù)結(jié)構(gòu)和操作流程

結(jié)構(gòu)化方法的優(yōu)缺點

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

信息建模法

信息建模法（information modeling）

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

信息建模法已經(jīng)很接近面向?qū)ο蠓椒?#xff0c;因此有的文獻也把它稱為一種面向?qū)ο蠓椒?#xff0c;但是有以下差別：

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

面向?qū)ο蠓椒?/h3>

• 面向?qū)ο蟮姆治?#xff08;object oriented analysis，OOA）
• 面向?qū)ο蟮脑O計（object oriented design，OOD）

運用對象、類、繼承、封裝、聚合、關(guān)聯(lián)、消息、多態(tài)等概念來構(gòu)造系統(tǒng)

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

不同建模方法的比較

需求工程

需求語義斷連現(xiàn)象的分析

軟件分析本質(zhì)：識別并解決問題

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

語義斷連錯誤的原因

形式化需求分析方法

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

需求的重要性

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

需求關(guān)鍵特征屬性

軟件需求特征屬性

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

層次化

需求又分為業(yè)務需求，用戶需求，功能需求以及系統(tǒng)需求，此外還包括一些非功能需求

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

過程

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

追蹤vs狀態(tài)

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

客戶角色

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

與客戶打交道的主要目的

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

需求職責

需求工程

什么是需求工程

• 把所有與需求直接相關(guān)的活動統(tǒng)稱為需求工程
• 需求工程中的活動可以分為兩大類
  • 一類屬于需求開發(fā)
    • 需求調(diào)查
    • 需求分析
    • 需求定義
  • 一類屬于需求管理
    • 需求確認
    • 需求跟蹤
    • 需求變更控制

需求開發(fā)過程域

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

需求管理過程域

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

需求開發(fā)方法

需求服務質(zhì)量差距模型

需求獲取的方法

• 對現(xiàn)有的文檔，表單和數(shù)據(jù)庫進行抽樣

• 研究和現(xiàn)場訪問

• 對工作環(huán)境的觀察

• 調(diào)查問卷

• 采訪

• 原型設計（ProtoTyping）

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

  • 應該是按照已經(jīng)有了的模板進行設計？

• 聯(lián)合需求規(guī)劃（Joint requirements planning，JRP）

如何開展需求調(diào)查

準備需求

首先，需求分析員應當起草需求調(diào)查問題表，將調(diào)查重點鎖在該問題表內(nèi)

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

其次，需求分析員應當確定需求調(diào)查的方式

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

執(zhí)行調(diào)查

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

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

根據(jù)調(diào)查記錄完成《用戶需求說明書》

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

角色->需求->功能->系統(tǒng)邊界

如何進行需求分析

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

撰寫《產(chǎn)品需求規(guī)格說明書》

需求分析方法有兩類

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

問答分析法

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

建模分析法

• 需求建模就是指用圖形符號來表示，刻畫需求
• 建模分析方法主要有兩大類
  • 結(jié)構(gòu)化分析法
  • 面向?qū)ο蠓治龇?/li>
• 在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用

需求分析工具

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

• 數(shù)據(jù)流圖

• WBS

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

• 用例驅(qū)動的分析

關(guān)于Use-Case的描述方法

用戶動作與系統(tǒng)響應反映了Use-Case的實現(xiàn)策略的核心機制

候選流程反映了系統(tǒng)的健壯性，是區(qū)分系統(tǒng)設計好壞的一個前提，需要體現(xiàn)在活動圖中

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

管理關(guān)鍵問題分析

需求管理控制過程

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

需求確認

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

需求跟蹤

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

• 需求跟蹤有三種方式：

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

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

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

小結(jié)

軟件開發(fā)影響因素

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

IT系統(tǒng)不成功的六大類型

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

產(chǎn)生問題的主要原因

好設計的十項原則

軟件系統(tǒng)開發(fā)的十大原則

項目管理的”三五九“

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

軟件可行性研究

概念

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

任務

是根據(jù)確定的問題，通過分析新系統(tǒng)需要的信息技術(shù)、可能發(fā)生的投資和費用、產(chǎn)生的效益，確定將開發(fā)的軟件系統(tǒng)成功的可能性

目的

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

前提

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

數(shù)據(jù)庫設計

問題引入基本概念

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

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

• 一個數(shù)據(jù)元素可以由若干個數(shù)據(jù)項組成。

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

• 數(shù)據(jù)對象：是性質(zhì)相同的數(shù)據(jù)元素的集合，是數(shù)據(jù)的一個子集

• 數(shù)據(jù)結(jié)構(gòu)：是指相互之間具有一定聯(lián)系的數(shù)據(jù)元素的集合。

  • 元素之間的相互聯(lián)系稱為邏輯結(jié)構(gòu)

  • 數(shù)據(jù)元素之間的邏輯結(jié)構(gòu)有四種基本類型

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

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

數(shù)據(jù)建模的基本概念

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

屬性的特征

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

關(guān)系的特征

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

外鍵的特征

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

實體的泛化

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

信息工程設計核心視角

在軟件系統(tǒng)中需要處理的數(shù)據(jù)是系那是世界中存在的事物及其聯(lián)系的反映

人們通常將于數(shù)據(jù)處理有關(guān)的領(lǐng)域分為三個世界

• 現(xiàn)實世界
• 信息世界
• 數(shù)據(jù)世界

現(xiàn)實世界

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

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

信息世界

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

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

數(shù)據(jù)世界

數(shù)據(jù)世界則是信息世界中信息的數(shù)據(jù)化，顯示世界中的事務及其聯(lián)系在數(shù)據(jù)世界中用數(shù)據(jù)模型描述

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

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

數(shù)據(jù)庫設計的基本步驟

數(shù)據(jù)庫設計分成6個階段

• 需求分析
• 概念結(jié)構(gòu)設計
• 邏輯結(jié)構(gòu)設計
• 物理結(jié)構(gòu)設計
• 數(shù)據(jù)庫實施
• 數(shù)據(jù)庫運行和維護

需求分析和概念設計獨立于任何數(shù)據(jù)庫管理系統(tǒng)

E-R方法和實體模型

規(guī)范化的目的

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

規(guī)范化的三個條件

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

第一范式

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

關(guān)系中所有的屬性都是單純域，即不出現(xiàn)“表中套表”

第二范式

定義：數(shù)據(jù)庫的表中不存在非關(guān)鍵字段對任一候選關(guān)鍵字段的部分函數(shù)依賴

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

第三范式

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

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

好的數(shù)據(jù)模型評價標準

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

數(shù)據(jù)庫的完整性設計

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

非空約束

Unique約束

主鍵約束

primary約束與unique約束

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

外鍵約束

check（校驗）約束：

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

完整性的分類

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

完整性約束條件包括

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

數(shù)據(jù)庫安全性設計

用戶標識與鑒別

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

數(shù)據(jù)加密

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

加密方法主要有兩種：

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

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

存取控制

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

視圖機制

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

審計

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

面向?qū)ο笤O計

UML的圖模型

用例圖

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

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

關(guān)系

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

用例描述

類圖

類圖以反映類的結(jié)構(gòu)(屬性、操作)以及類之間的關(guān)系為主要目的，描述了軟件系統(tǒng)的結(jié)構(gòu)，是一種靜態(tài)建模方法

類圖中的事物及解釋

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

類的關(guān)系描述

類之間主要存在的關(guān)系：依賴、關(guān)聯(lián)、聚合、組合、實現(xiàn)和泛化。

活動圖

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

時序圖

順序圖用來表示用例中的行為順序。當執(zhí)行一個用例行為時，順序圖中的每條消息對應了一個類操作或狀態(tài)機中引起轉(zhuǎn)換的事件。

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

時序圖的組成

狀態(tài)機圖

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

事務及解釋

面向?qū)ο蟮脑O計目標與原則

設計的總體目標

面向?qū)ο笤O計基本原則

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

單一職責原則

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

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

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

開閉原則

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

接口分離原則

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

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

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

依賴倒置原則

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

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

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

里氏替換原則

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

在軟件中將一個基類替換成它的子類對象，程序?qū)⒉粫a(chǎn)生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那么它不一定能夠使用基類對象

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

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

應注意的問題

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

迪米特法則

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

由右側(cè)改進為左側(cè)

合成/聚合復用原則

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

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

監(jiān)聽器

main(){ 聯(lián)想 聯(lián)想1 = new 聯(lián)想() 惠普 惠普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(){聯(lián)想 聯(lián)想1 = new 聯(lián)想();惠普 惠普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;} }

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。