【正文】 顧客按鍵后飲料由取物樓掉出，并自動結算及找錢。 UML的開發(fā)歷程 Booch’91 其它方法 OMT1 OOSE Booch’93 OMT2 UML UML amp。 面向對象分析方法使得軟件工程師能夠通過對象、屬性和操作（作為主要的建模成分）的表示來對問題建模。 消息連接體現(xiàn)了對象行為的 動態(tài)聯(lián)系 。 (部分對于整體是 “ apartof”關系 ) 組裝結構體現(xiàn)了面向對象方法的 聚合（也叫聚集 Aggregation） 原則。 OO方法強調圍繞對象而不是功能來構造系統(tǒng) 。 類的生存期模型 類的規(guī) 格說明 從廢棄型開發(fā) 既存類 的復用 漸增式的實現(xiàn) 漸增式的測試 求精和 維護 測試用 例和測試 的開發(fā) 實現(xiàn) 從既存 類演變 類的設計與實現(xiàn) ?類的規(guī)格說明指導對存放現(xiàn)存類的軟件庫進行查找 ?現(xiàn)存類提供當前應用所需功能 ?三種可能利用現(xiàn)存類的方向 ： ? 現(xiàn)存類的復用 ? 從現(xiàn)存類進行演變 ? 從廢棄類進行開發(fā) 對象之間的聯(lián)系與對象模型 面向對象方法開發(fā)軟件 通常建立的三種形式的模型 ? 描述系統(tǒng)數(shù)據(jù)結構的 對象模型 ? 描述系統(tǒng)控制結構的 動態(tài)模型 ? 描述系統(tǒng)功能的 功能模型 三種模型從三個不同但由密切相關的角度模擬目標系統(tǒng)。 ?軟件復用 可復用性（可重用性） reusebility ?可擴展性 ?可管理 性 可復用性（可重用性） 面向對象技術允許復用的不僅僅是 代碼 , 通過面向對象技術 , 我們可以復 用需求、分析、設計、測試計劃、用戶 界面以及體系結構等等 , 事實上 , 軟件 工程生存期中的每個部分都可以復用 。 面向對象分析方法 思考題 ?軟件開發(fā)中為什么要使用面向對象 方法？ ?面向對象分析方法與結構化分析方 法有哪些相似之處？有何區(qū)別？ ?面向對象方法是對過去的一個完全 突破，還是 “ 換湯不換藥 ” ？ 對象 （ object) 現(xiàn)實世界中某個具體的物理實體或概念在計算機邏輯中的映射和體現(xiàn)。 需求不完整， 導致需求不可驗證 改 進 需求文檔的陳述與改進舉例（ 2） 產品必須在顯示和隱藏非打印字符之間進行瞬間切換 。 a. 在 后臺任務進程啟動之后，消息必須每隔 60(?10)秒更新一次，并且保持連續(xù)的可見性。 也可在 DD中定義只說明每個加工的組 成 (每個處理分解成多少小處理 ),而在 小說明中詳細描述它的處理邏輯 . 加工條目 (加工邏輯說明 ) 加工邏輯名 :登記報名單 編號： 激活條件：收到報名單 加工邏輯 ： { 檢查報名單 + 編準考證號 + 登記考生 } 執(zhí)行頻率： 2022次 /日 ＤＤ定義方法 ?找出所有數(shù)據(jù)元素 (數(shù)據(jù)流，數(shù)據(jù)存儲，數(shù)據(jù)項，加工 ) ?對數(shù)據(jù)項分類 ?作結構定義 ?排序 ?DD的分類 ?DD中的命名 (遵守系統(tǒng)開發(fā)規(guī)范規(guī)定 ) DD的實現(xiàn) (1)人工方法 (2)自動方法 (利用字典管理程序 ) DD應具特點 (1)通過名字可方便查閱數(shù)據(jù)定義 (2)無冗余 (3)易更新修改 (加工邏輯說明的另一種形式 ) 描述的內容： (1) 處理邏輯 描述基本加工如何把輸入數(shù)據(jù)流變化為輸出數(shù)據(jù)流的加工原則，不涉及具體處理方法。狀態(tài) ” 有關 閃爍 與 “ 顯示信息 amp?？刂葡到y(tǒng) ” 有關 顯示活動狀態(tài) 與 “ 用戶交互 ” 有關 傳感器事件 與 “ 顯示信息 amp。 (5)按地區(qū)進行成績分類統(tǒng)計和試題難度分析，產生統(tǒng)計分析表。 實例 考務處理系統(tǒng)功能 (1)對考生送來的報名單進行檢查 。 ?描述對數(shù)據(jù)流進行變換的功能 。 描述新系統(tǒng)是如何實施的（包括技術）。 模型的類型 ?數(shù)學模型 ?描述模型 ?圖形模型 需求分析的步驟 當前 系統(tǒng) 目標 系統(tǒng) 物理 模型 邏輯 模型 邏輯 模型 物理 模型 模型化 抽象化 具體化 實例化 怎 么 做 做 什 么 當前 系統(tǒng) 目標 系統(tǒng) 需 求 定 義 邏輯模型和物理模型 ? 模型是對對象系統(tǒng)的形式化的特征 抽象，概括性或近似地表示； ? 構造模型的過程是一個抽象、分 析的過程。 描述新系統(tǒng)的主要業(yè)務功能和用戶新的需求，無論系統(tǒng)應如何實施。 有時我們使用術語 “ 抽象 ” 來表示模型，因為我們從現(xiàn)實世界中 抽象 出對我們特別有用的東西。 內存空間等資源。 需求分析的任務 準確地 定義 未來系統(tǒng)的目標，確定為了滿足用戶的需求系統(tǒng)必須做什么。 每個階段結束前完成文檔審查 , 及早改正錯誤。它能直觀表達軟件開發(fā)全過程，明確規(guī)定要完成的主要活動、任務和開發(fā)策略。 (3) 構筑一個軟件系統(tǒng)，實踐 軟件開發(fā)全過程。 應用發(fā)展的眼光看待它。 ” 軟件工程的定義 IEEE【 IEE93】 給出了一個更加綜合的定義： “ 將系統(tǒng)化的、規(guī)范的、可度量的方法應用于軟件的開發(fā)、運行和維護的過程，即將工程化應用于軟件中。 改正一個問題需付出的代價 需 求 分 析 結構設計 詳細設計 編碼 集成測試 系統(tǒng)測試 現(xiàn)場 改正一個問題的估計費用 改正一個問題估計的工作量 20 200 2022 1000 (美元 ) (人天 ) yet, Success Hasn?t Come Easily 31% 53% 16% Successfully Challenged Canceled 成功的標準： ?用戶在 用 ?用戶可很容易做完要做的事 失敗的根本原因： 開發(fā)人員寫出的東西達不到 用戶要求 (人的問題 .技術問題 ) 處在十字路口的中國軟件產業(yè) ? 主權大國必須建立基于自主技術的、 完整的軟件產業(yè)體系。 軟件工程的背景和歷史 1968年由 NATO (北大西洋公約組織 )在德國 Garmish召開的學術會議上， Feitz Bauer首先提出了 “ 軟件工程 ” 概念。 Evolution of software 早期 第二階段 第三階段 第四階段 ?面向批處理 ?多用戶 ?分布式系統(tǒng) ?強大的桌面系統(tǒng) ?有限的分布 ?實時 ?嵌入 “ 智能 ” ?面向對象技術 ?自定義軟件 ?數(shù)據(jù)庫 ?低成本硬件 ?專家系 統(tǒng) ?軟件產品 ?消費者的影響 ?人工神經(jīng)網(wǎng)絡 ?并行計算 ?網(wǎng)絡計算機 1950 1960 1970 1980 1990 2022 軟件技術面臨的問題 ? 復雜性 ? 生產率 ?例 :Windows95有 1000萬行代碼 Windows2022有 5000萬行代碼 Exchange2022和 Windows2022開發(fā)人員結構 Exchange2022 Windows2022 項目經(jīng)理 25人 約 250人 開發(fā)人員 140人 約 1700人 測試人員 350人 約 3200人 軟件危機的主要特征 ? 軟件開發(fā)周期大大超過規(guī)定 日期 。 軟件本國提供率：中國 1/3左右，美國 97% ? “印度模式 ” 還是 “ 中國模式 ” ? 軟件人才結構不合理， 缺乏中高級軟 件人才 軟件人員缺乏軟件工程化的概念。 ” 軟件工程的定義 軟件工程是應用計算機科學、數(shù)學及管理科學等原理開發(fā)軟件的工程。 軟件工程 — 一種層次化技術 工具 方法 過程 質量焦點 Software engineering layers 軟件工程三個要素： 方法、工具、過程 軟件工程框架 可 用 性 性 性 確 正 合 算 選取適宜的開發(fā)模型 采用合適的設計方法 提供高質量的工程支持 重視軟件工程的管理 基本過程 原則 目標 過 程 支 持 過 程 組 織 過 程 軟件工程與一般工程的差異 ?軟件是邏輯產品而不是實物產品 ?軟件的功能依賴于硬件和軟件的運行環(huán)境以及人們對它的操作 ?軟件設計的復雜性 ?軟件特征： 功能的多樣性 實現(xiàn)的多樣性 能見度低 軟件結構合理性差 ?智力密集及知識產權保護 軟件工程知識結構 2022年 5月 ISO/IEC JTC 1（ ISO和 IEC的第一聯(lián)合技術委員會）發(fā)布了《 SWEBOK指南 (試用版 )》 （ Guide to the Software Engineering Body of Knowledge,簡稱 SWEBOK） SWEBOK把軟件工程學科的主體知識分為 10個知識領域。 “ 軟件工程”課程教學與實踐的目標 ? 轉變對軟件的認識： 上升 程序 系統(tǒng) ? 轉變思維定式： 上升 程序員 系統(tǒng)工程師 (系統(tǒng)分析員 ) ? 工程化訓練 系統(tǒng)分析員的地位 用戶 分析員 程序員 “ 一個好的工業(yè)，應有一套 良好的標準來配套” 軟件的工業(yè)化生產過程應具備的特點： ?明確的工作步驟 ?詳細具體的規(guī)范化文檔 ?明確的質量評價標準 軟件產品的標準化 軟件開發(fā)過程的標準化 軟件工程技術的兩個明顯特點： ? 強調規(guī)范化 ? 強調文檔化 167。 軟件開發(fā)模型也常稱為： 軟件過程模型 軟件生存期模型 軟件工程范型 1. 瀑布模型 (線形順序模型 ) 可行性研究與計劃 需求分析 設計 編碼 運行維護 測試 定義 階段 開 發(fā) 階 段 維護階段 按照傳統(tǒng)瀑布模型開發(fā)軟件的特點 。 2. 原型模型 （快速成型模型） 建造 /修改 原型 用戶測試 運行原型 聽取用 戶意見 原型范型 采用原型模型的軟件生存周期 分析定義 系統(tǒng)需求 生成 原型 系統(tǒng) 設計 程序 設計 編碼 測試 運 行 和維護 原型化 含原型化的 軟件生存期 3. 演化模型 增量模型 (遞增模型 ) 先完成一個系統(tǒng)子集的開發(fā)，再按同樣的開發(fā)步驟增加功能 (系統(tǒng)子集 ),如此遞增下去直至滿足全部系統(tǒng)需求。用 需求規(guī)格說明書 規(guī)范的形式準確地表達用戶的 需求 。 ? 軟件開發(fā)、維護所需的人力、 支撐軟件、開發(fā)設備等。 需求分析的步驟 當前 系統(tǒng) 目標 系統(tǒng) 物理 模型 邏輯 模型 邏輯 模型 物理 模型 模型化 抽象化 具體化 實例化 怎 么 做 做 什 么 當前 系統(tǒng) 目標 系統(tǒng) 需 求 定 義 邏輯模型和物