軟件工程課件_第1頁
軟件工程課件_第2頁
軟件工程課件_第3頁
軟件工程課件_第4頁
軟件工程課件_第5頁
已閱讀5頁,還剩746頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

軟件工程

SoftwareEngineering

軟件是與計算機系統(tǒng)操作有關的程序、規(guī)程、規(guī)則及與之有關的文檔及數(shù)據(jù)。軟件的分類系統(tǒng)軟件、實時軟件、嵌入式軟件、科學和工程計算軟件、事務處理軟件、人工智能軟件、個人計算機軟件、CASE工具軟件第一章軟件工程學概述軟件發(fā)展四個階段:

50年代初--60年代初初期階段個人的技藝

60年中期--70年代末多用戶、多道程序和人機交互,軟件維護問題的矛盾加劇70年中期--80年代末分布式系統(tǒng)、計算機網(wǎng)絡等80年代末面向對象技術、專家系統(tǒng)、人工智能軟件、并行軟件、Internet環(huán)境下軟件、布式計算環(huán)境等

§1.軟件危機(SoftwareCrisis)軟件應用范圍擴大—需求增加—軟件規(guī)模增長—復雜度增加—費用巨大—可靠性低、質量差—軟件危機§1.軟件危機例:美國IBM公司在1963年至1966年開發(fā)的IBM360機的操作系統(tǒng)。這一項目花了5000人一年的工作量,最多時有1000人投入開發(fā)工作,寫出了近100萬行源程序。......據(jù)統(tǒng)計,這個操作系統(tǒng)每次發(fā)行的新版本都是從前一版本中找出1000個程序錯誤而修正的結果。......一、軟件危機簡介§1.軟件危機

這個項目的負責人F.D.Brooks事后總結了他在組織開發(fā)過程中的沉痛教訓時說:“......正像一只逃亡的野獸落到泥潭中做垂死的掙扎,越是掙扎,陷得越深,最后無法逃脫滅頂?shù)臑碾y。......程序設計工作正像這樣一個泥潭,......一批批程序員被迫在泥潭中拼命掙扎,......誰也沒有料到問題竟會陷入這樣的困境......”。IBM360操作系統(tǒng)的歷史教訓成為軟件開發(fā)項目的典型事例為人們所記取。SoftwareCrisis!(1)對軟件開發(fā)成本和進度的估計常常很不準確。(2)用戶對“已完成的”軟件系統(tǒng)不滿意的現(xiàn)象經常發(fā)生。(3)軟件產品的質量往往靠不住。(4)軟件常常是不可維護的。(5)軟件通常沒有適當?shù)奈臋n資料(6)軟件成本占計算機系統(tǒng)總成本中所的比例逐年上升。(7)軟件開發(fā)生產率提高的速度,遠遠跟不上計算機應用迅速普及深入的趨勢?!?.軟件危機軟件危機主要有以下一些典型表現(xiàn)§1.軟件危機⑴項目沒有被很好地理解;計劃不周,最終導致進度拖延。問題出在哪里?二、軟件危機的原因§1.軟件危機⑵沒有充分的文檔資料(documentation)人與人的交流比寫程序困難得多。Managers——管理和評價工程的進展Programmers——交流信息Maintainers——至關重要文檔的作用

(1)

作為開發(fā)人員在一定階段內的工作成果和結束標志(2)向管理人員提供軟件開發(fā)過程中的進展和情況,把軟件開發(fā)過程中的一些“不可見的”事物轉換成“可見的”文字資料。以便管理人員在各個階段檢查開發(fā)計劃的實施進展,使之能夠判斷原定目標是否達到,還將繼續(xù)耗用資源的種類和數(shù)量。(3)

記錄開發(fā)過程中的技術信息,以便協(xié)調以后的軟件開發(fā),使用和修改。(4)

提供對軟件的有關運行、維護和培訓的信息,便于協(xié)調管理人員、開發(fā)人員、操作人員和用戶之間相互了解彼此的工作。(5)向潛在用戶報道軟件的功能和性能,使他們能判定軟件能否服務于自己的需要。

補充:§1.軟件危機⑶軟件可靠性(reliability)缺少度量的標準,質量無法保證。如何保證軟件產品的質量,是非常復雜困難的問題。

引入同一變動付出的代價隨時間變化的趨勢早中晚高中低改正同一個問題需要付出的代價概要設計詳細設計編碼系統(tǒng)測試需求分析§1.軟件危機(4)修改軟件所付出的代價會變大§1.軟件危機(5)軟件難以維護(maintainability)

不易升級(evolvability)程序寫完了并不是工作就完成了應該徹底消除“軟件就是程序”的錯誤觀念。軟件是程序、數(shù)據(jù)及相關文檔的完整集合。其中,程序是能夠完成預定功能和性能的可執(zhí)行的指令序列;數(shù)據(jù)是使程序能夠適當?shù)靥幚硇畔⒌臄?shù)據(jù)結構;文檔是開發(fā)、使用和維護程序所需要的圖文資料?!?.軟件危機三、消除軟件危機認識到軟件開發(fā)不是某種個體勞動的神秘技巧,而應該是一種組織良好、管理嚴密、各類人員協(xié)同配合、共同完成的工程項目?!败浖本幊?,它有自己的生命周期

(lifecycle)。大型軟件系統(tǒng)的開發(fā)與其它工程項目如建造橋梁、制造飛機、輪船等的開發(fā)是同理的。更好的語言和工具統(tǒng)一的編碼規(guī)范§1.軟件危機軟件工程是指導計算機軟件開發(fā)和維護的一門工程學科。1968年在第一屆NATO會議上曾經給出了軟件工程的一個早期定義:“軟件工程就是為了經濟地獲得可靠的且能在實際機器上有效地運行的軟件,而建立和使用完善的工程原理?!?993年IEEE(美國電氣電子工程師學會)全面更具體的定義:“軟件工程是:①把系統(tǒng)的、規(guī)范的、可度量的途徑應用于軟件開發(fā)、運行和維護過程,也就是把工程應用于軟件;②研究①中提到的途徑?!薄?.軟件工程(SoftwareEngineering)一、人們普遍認為軟件工程具有下述的本質特性1.軟件工程關注于大型程序的構造2.軟件工程的中心課題是控制復雜性3.軟件經常變化4.開發(fā)軟件的效率非常重要5.和諧地合作是開發(fā)軟件的關鍵6.軟件必須有效地支持它的用戶7.在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人創(chuàng)造產品§2.軟件工程二、軟件工程的基本原理(Principles):⑴用分階段的生命周期計劃嚴格管理

項目概要計劃

里程碑計劃

項目控制計劃

產品控制計劃

驗證計劃

運行維護計劃⑵堅持進行階段評審⑶實行嚴格的產品控制——基準配置管理(Baselineconfigurationmanagement)⑹開發(fā)小組的成員應該少而精

⑷采用現(xiàn)代程序設計技術⑸結果應能清楚地審查⑺承認不斷改進軟件工程實踐的必要性§2.軟件工程軟件工程包括技術和管理兩方面的內容,是技術與管理緊密結合所形成的工程學科。管理:就是通過計劃、組織和控制等一系列活動,合理地配置和使用各種資源,以達到既定目標的過程。方法學:在軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學(methodology),也稱為范型(paradigm)。在軟件工程領域中,這兩個術語的含義基本相同。三、軟件工程方法學§2.軟件工程軟件工程方法學包含3個要素:方法、工具和過程。方法是完成軟件開發(fā)的各項任務的技術方法,回答“怎樣做”的問題;工具是為運用方法而提供的自動的或半自動的軟件工程支撐環(huán)境;過程是為了獲得高質量的軟件所需要完成的一系列任務的框架,它規(guī)定了完成各項任務的工作步驟。目前使用得最廣泛的軟件工程方法學,分別是傳統(tǒng)方法學和面向對象方法學。§2.軟件工程1.傳統(tǒng)方法學傳統(tǒng)方法學也稱為生命周期方法學或結構化范型。它采用結構化技術(結構化分析、結構化設計和結構化實現(xiàn))來完成軟件開發(fā)的各項任務,并使用適當?shù)能浖ぞ呋蜍浖こ汰h(huán)境來支持結構化技術的運用?!?.軟件工程這種方法學把軟件生命周期的全過程依次劃分為若干個階段,然后順序地完成每個階段的任務。前一個階段任務的完成是開始進行后一個階段工作的前提和基礎,而后一階段任務的完成通常是使前一階段提出的解法更進一步具體化,加進了更多的實現(xiàn)細節(jié)。在每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審,從技術和管理兩方面對這個階段的開發(fā)成果進行檢查§2.軟件工程傳統(tǒng)方法學仍然是人們在開發(fā)軟件時使用得十分廣泛的軟件工程方法學。在相當長一段時期內這種方法學還會有生命力。§2.軟件工程2.面向對象方法學當軟件規(guī)模龐大,或者對軟件的需求是模糊的或會隨時間而變化的時候,使用傳統(tǒng)方法學開發(fā)軟件往往不成功,此外,使用傳統(tǒng)方法學開發(fā)出的軟件,維護起來仍然很困難?!?.軟件工程數(shù)據(jù)和對數(shù)據(jù)的處理原本是密切相關的,把數(shù)據(jù)和操作人為地分離成兩個獨立的部分,自然會增加軟件開發(fā)與維護的難度。與傳統(tǒng)方法相反,面向對象方法把數(shù)據(jù)和行為看成同等重要,它是一種以數(shù)據(jù)為主線,把數(shù)據(jù)和對數(shù)據(jù)的操作緊密地結合起來的方法。§2.軟件工程概括地說,面向對象方法學具有下述4個要點。把對象(object)作為融合了數(shù)據(jù)及在數(shù)據(jù)上的操作行為的統(tǒng)一的軟件構件。面向對象程序是由對象組成的,程序中任何元素都是對象,復雜對象由比較簡單的對象組合而成。(2)把所有對象都劃分成類(class)。每個類都定義了一組數(shù)據(jù)和一組操作,類是對具有相同數(shù)據(jù)和相同操作的一組相似對象的定義。§2.軟件工程(3)按照父類(或稱為基類)與子類(或稱為派生類)的關系,把若干個相關類組成一個層次結構的系統(tǒng)(也稱為類等級)。在類等級中,下層派生類自動擁有上層基類中定義的數(shù)據(jù)和操作,這種現(xiàn)象稱為繼承。(4)對象彼此間僅能通過發(fā)送消息互相聯(lián)系。也就是說,對象的所有私有信息都被封裝在該對象內,不能從外界直接訪問,這就是通常所說的封裝性。

§2.軟件工程面向對象方法學的出發(fā)點和基本原則:盡量模擬人類習慣的思維方式,使開發(fā)軟件的方法與過程盡可能接近人類認識世界解決問題的方法與過程,從而使描述問題的問題空間(也稱為問題域)與實現(xiàn)解法的解空間(也稱為求解域)在結構上盡可能一致。傳統(tǒng)方法學強調自頂向下順序地完成軟件開發(fā)的各階段任務?!?.軟件工程用面向對象方法學開發(fā)軟件的過程,是一個主動地多次反復迭代的演化過程。面向對象方法普遍進行的對象分類過程:支持從特殊到一般的歸納思維過程;通過建立類等級而獲得的繼承性,支持從一般到特殊的演繹思維過程。§2.軟件工程對象是相對獨立的實體,容易在以后的軟件產品中重復使用,面向對象范型的另一個重要優(yōu)點是促進了軟件重用面向對象方法特有的繼承性和多態(tài)性,進一步提高了面向對象軟件的可重用性§2.軟件工程1.問題定義“要解決的問題是什么?”,在實踐中它卻可能是最容易被忽視的一個步驟。通過對客戶的訪問調查,系統(tǒng)分析員扼要地寫出關于問題性質、工程目標和工程規(guī)模的書面報告,經過討論和必要的修改之后這份報告應該得到客戶的確認。§3.軟件生命周期(SoftwareLifeCycle)2.可行性研究“對于上一個階段所確定的問題有行得通的解決辦法嗎?”系統(tǒng)分析員需要進行一次大大壓縮和簡化了的系統(tǒng)分析和設計過程,也就是在較抽象的高層次上進行的分析和設計過程。研究問題的范圍,探索這個問題是否值得去解,是否有可行的解決辦法?!?.軟件生命周期3.需求分析這個階段的任務仍然不是具體地解決問題,而是準確地確定“為了解決這個問題,目標系統(tǒng)必須做什么”,主要是確定目標系統(tǒng)必須具備哪些功能。§3.軟件生命周期系統(tǒng)分析員在需求分析階段必須和用戶密切配合,充分交流信息,以得出經過用戶確認的系統(tǒng)邏輯模型。通常用數(shù)據(jù)流圖、數(shù)據(jù)字典和簡要的算法表示系統(tǒng)的邏輯模型。用正式文檔準確地記錄對目標系統(tǒng)的需求,這份文檔通常稱為規(guī)格說明書(specification)。(提示:它經常被作為軟件驗收的技術協(xié)議)§3.軟件生命周期4.總體設計這個階段必須回答的關鍵問題是:“概括地說,應該怎樣實現(xiàn)目標系統(tǒng)?”總體設計又稱為概要設計。應該設計出實現(xiàn)目標系統(tǒng)的幾種可能的方案。并在充分權衡各種方案的利弊的基礎上,推薦一個最佳方案??傮w設計的另一項主要任務就是設計程序的體系結構,也就是確定程序由哪些模塊組成以及模塊間的關系。§3.軟件生命周期5.詳細設計詳細設計階段的任務就是把解法具體化,也就是回答下面這個關鍵問題:“應該怎樣具體地實現(xiàn)這個系統(tǒng)呢?”不是編寫程序,而是設計出程序的詳細規(guī)格說明。詳細設計也稱為模塊設計,在這個階段將詳細地設計每個模塊,確定實現(xiàn)模塊功能所需要的算法和數(shù)據(jù)結構。§3.軟件生命周期6.編碼和單元測試這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。程序員應該根據(jù)目標系統(tǒng)的性質和實際環(huán)境,選取一種適當?shù)母呒壋绦蛟O計語言(必要時用匯編語言),把詳細設計的結果翻譯成用選定的語言書寫的程序,并且仔細測試編寫出的每一個模塊?!?.軟件生命周期7.綜合測試這個階段的關鍵任務是通過各種類型的測試(及相應的調試)使軟件達到預定的要求。最基本的測試是集成測試和驗收測試。所謂集成測試是根據(jù)設計的軟件結構,把經過單元測試檢驗的模塊按某種選定的策略裝配起來,在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規(guī)格說明書的規(guī)定,由用戶對目標系統(tǒng)進行驗收。§3.軟件生命周期8.軟件維護維護階段的關鍵任務是,通過各種必要的維護活動使系統(tǒng)持久地滿足用戶的需要。通常有4類維護活動:改正性維護,也就是診斷和改正在使用過程中發(fā)現(xiàn)的軟件錯誤;適應性維護,即修改軟件以適應環(huán)境的變化;完善性維護,即根據(jù)用戶的要求改進或擴充軟件使它更完善;預防性維護,即修改軟件為將來的維護活動預先做準備。§3.軟件生命周期§4.軟件過程軟件過程是為了獲得高質量軟件所需要完成的一系列任務的框架,它規(guī)定了完成各項任務的工作步驟。

ISO9000把過程定義為“使用資源將輸入轉化為輸出的活動所構成的系統(tǒng)。”此處,“系統(tǒng)”的含義是廣義的:“系統(tǒng)是相互關聯(lián)或相互作用的一組要素?!边^程定義了運用方法的順序、應該交付的文檔資料、為保證軟件質量和協(xié)調變化所需要采取的管理措施,以及標志軟件開發(fā)各個階段任務完成的里程碑。科學、有效的軟件過程應該定義一組適合于所承擔的項目特點的任務集合。通常,一個任務集合包括一組軟件工程任務、里程碑和應該交付的產品。通常使用生命周期模型簡潔地描述軟件過程。生命周期模型規(guī)定了把生命周期劃分成哪些階段及各個階段的執(zhí)行順序,因此,也稱為過程模型。§4.軟件過程一、瀑布模型(WaterfallModel):維護開發(fā)定義定義

可行性研究需求分析詳細設計編碼和測試集成和系統(tǒng)測試提交和維護概要設計通常使用生命周期模型簡潔地描述軟件過程。把生命周期劃分成哪些階段及各個階段的執(zhí)行順序,也稱為過程模型。⑴順序性、依賴性

前一階段的輸出文檔是后一階段的輸入文檔

瀑布模型特點

用戶要求系統(tǒng)測試

需求分析概要設計單元測試綜合測試確認測試編碼程序清單需求規(guī)格說明軟件結構圖模塊說明詳細設計圖§4.軟件過程⑵推遲程序的物理實現(xiàn)軟件開發(fā)人員不能急于求成,它們總想早點編寫程序。對于大、中型的軟件編碼開始得越早,完成所需時間反而越長,過早地考慮程序的實現(xiàn),常常導致大量返工,甚至災難性后果(徹底推翻)§4.軟件過程⑶質量保證的觀點——階段文檔與評審的要求,利于盡早發(fā)現(xiàn)錯誤。

每一階段都要完成規(guī)定的文檔每一階段都要對完成的文檔進行復審,以便盡早發(fā)現(xiàn)問題,消除隱患,復審要及時,暴露出問題愈晚,排除故障付出代價也愈高。

§4.軟件過程優(yōu)點:規(guī)范化開發(fā);每個階段提交文檔每個階段驗證缺點:過于理想化(不能適應需求的變化,初期用戶對產品的“樣式”不了解)§4.軟件過程實際的瀑布模型快速建立起來的可以在計算機上運行的程序,它所能完成的功能往往是最終產品能完成的功能的一個子集。快速原型模型的第一步是快速建立一個能反映用戶主要需求的原型系統(tǒng),讓用戶在計算機上試用它,通過實踐來了解目標系統(tǒng)的概貌。§4.軟件過程二、快速原型模型通常,用戶試用,提出修改意見,開發(fā)人員修改原型系統(tǒng),然后用戶再次試用……一旦用戶認可,開發(fā)人員書寫規(guī)格說明文檔,軟件可以滿足用戶的真實需求?!?.軟件過程快速原型模型三、增量模型增量模型§4.軟件過程增量模型也稱為漸增模型。使用增量模型開發(fā)軟件時,把軟件產品作為一系列增量構件來設計、編碼、集成和測試每個構件由多個相互作用的模塊構成,并且能完成特定的功能。使用增量模型時,第一個增量構件往往實現(xiàn)軟件的基本需求,提供最核心的功能。例:開發(fā)字處理軟件第一個增量構件:基本的文件管理、編輯、和文檔生成功能第二個增量構件:更完善的編輯和文檔生成功能;第三個增量構件:實現(xiàn)拼寫和語法檢查功能;第四個增量構件:完成高級的頁面排版功能構件2構件3構件1構件2構件1能在較短時間內向用戶提交可完成部分工作的產品,是增量模型的一個優(yōu)點。逐步增加產品功能可以使用戶有較充裕的時間學習和適應新產品,從而減少一個全新的軟件可能給客戶組織帶來的沖擊。優(yōu)點§4.軟件過程增量模型本身是自相矛盾的。它一方面要求開發(fā)人員把軟件看作一個整體,另一方面又要求開發(fā)人員把軟件看作構件序列,每個構件本質上都獨立于另一個構件。除非開發(fā)人員有足夠的技術能力協(xié)調好這一明顯的矛盾,否則用增量模型開發(fā)出的產品可能并不令人滿意?!?.軟件過程風險更大的增量模型冒構件無法集成到一起的風險§4.軟件過程四、螺旋模型§4.軟件過程簡化的螺旋模型螺旋模型的基本思想是,使用原型及其他方法來盡量降低風險。理解這種模型的一個簡便方法,是把它看作在每個階段之前都增加了風險分析過程的快速原型模型。完整的螺旋模型§4.軟件過程§2.步驟1、復查定義,明確限制的約束。我們認為用戶要的用戶要的2、研究老系統(tǒng)

解決老系統(tǒng)問題老系統(tǒng)功能新增功能

新系統(tǒng)效益注:

只了解老系統(tǒng)做什么,而不管怎樣做;

注意了解與其它系統(tǒng)的接口。

老系統(tǒng)效益§2.步驟3、導出高層邏輯模型(conceptualdesign)…………抽象實現(xiàn)改進老系統(tǒng)模型新模型新系統(tǒng)報告應該告訴用戶“What”而不是“How”§2.步驟

3、邏輯模型4、重新定義1、復查定義注:此時合同未簽,應考慮成本,不宜反復太多次。5、導出多種解法進度表經濟上合算技術上可行操作上可行技術上不可行用戶不可能操作不合算§2.步驟6、推薦行動方針YesorNo?NoYesWhy?Whichoneisthebest?Why?(cost/benefit)7、開發(fā)計劃(粗略)

任務分解,確定負責人

大致進度規(guī)劃

財務預算

風險分析及對策8、審查、存檔§3.系統(tǒng)流程圖(SystemFlowDiagram)系統(tǒng)流程圖是概括地描繪物理系統(tǒng)的傳統(tǒng)工具基本思想是用圖形符號以黑盒子形式描繪組成系統(tǒng)的每個部件(程序,文檔,數(shù)據(jù)庫,人工過程等)。系統(tǒng)流程圖表達的是數(shù)據(jù)在系統(tǒng)各部件之間流動的情況,而不是對數(shù)據(jù)進行加工處理的控制過程(不同于程序流程圖)符號:P.29圖2.1基本符號§3.系統(tǒng)流程圖2.例子:P.30某裝配廠有一座存放零件的倉庫,倉庫中現(xiàn)有的各種零件的數(shù)量以及每種零件的庫存量臨界值等數(shù)據(jù)記錄在庫存清單主文件中。當倉庫中零件數(shù)量有變化時,應該及時修改庫存清單主文件,如果哪種零件的庫存量少于它的庫存量臨界值,則應該報告給采購部門以便定貨,規(guī)定每天向采購部門送一次定貨報告。變化倉庫零

庫存量件臨界值庫存清單XX:————————XX:————…………庫存<

臨界值定貨報告§3.系統(tǒng)流程圖注:符號=系統(tǒng)部件箭頭=信息流動路徑事務庫存清單程序庫存清單主文件定貨信息報告生成程序定貨報告即庫存量變化數(shù)據(jù)流圖(DFD)是一種圖形化技術,它描繪信息流和數(shù)據(jù)從輸入移動到輸出的過程中所經受的變換。只是描繪數(shù)據(jù)在軟件中流動和被處理的邏輯過程。設計數(shù)據(jù)流圖時只需考慮系統(tǒng)必須完成的基本邏輯功能,完全不需要考慮怎樣具體地實現(xiàn)這些功能,§4.數(shù)據(jù)流圖

(DataFlowDiagram,DFD)§4.數(shù)據(jù)流圖

System=data+function1、符號:P.31inputDatastoragefunctionDataflow2、例子:(1)P.32—37output假設一家工廠的采購部每天需要一張定貨報表,報表按零件編號排序,表中列出所有需要再次定貨的零件。對于每個需要再次定貨的零件應該列出下述數(shù)據(jù):零件編號,零件名稱,定貨數(shù)量,目前價格,主要供應者,次要供應者。零件入庫或出庫稱為事務,通過放在倉庫中的顯示器把事務報告給定貨系統(tǒng)。當某種零件的庫存數(shù)量少于庫存量臨界值時就應該再次定貨。例子§4.數(shù)據(jù)流圖

倉庫管理員定貨系統(tǒng)

采購員

倉庫管理員

采購員處理事務1產生報表2D2定貨信息D1庫存清單

定貨信息

定貨信息§4.數(shù)據(jù)流圖

倉庫管理員

采購員接受事務1.1產生報表2D2定貨信息D1庫存清單

定貨信息

定貨信息處理事務1.2更新庫存清單1.3進一步分解后的數(shù)據(jù)流圖§4.數(shù)據(jù)流圖

132

文件2.12.22.32.43.13.23.33.43.5

入入S出出3分層數(shù)據(jù)流圖§4.數(shù)據(jù)流圖

(1)數(shù)據(jù)流圖可以逐層分解頂層的系統(tǒng)S很復雜,可以把它分解為第2層的1,2,3三個子系統(tǒng)。在這子系統(tǒng)中,如果子系統(tǒng)1已經很清楚,無需再分解,子系統(tǒng)2和子系統(tǒng)3仍很復雜,可以再把它們分別分解為下一層的子系統(tǒng)2.1,2.2,2.3,2.4和3.1,3.2,3.3,3.4,3.5……,直到分解所得到的每個子系統(tǒng)都能清楚地理解和實現(xiàn)。對于任何復雜的系統(tǒng),分析工作都可以按照這樣的方式有計劃,有步驟,有條不紊地進行。對大小規(guī)模不同的系統(tǒng)只是分解層次不同而以?!?.數(shù)據(jù)流圖

(2)分層DFD優(yōu)點·便于實現(xiàn),采用逐步細化擴展方法,可避免一次引入過多細節(jié),有利于控制問題的復雜度。·便于使用,用一組圖代替一張圖§4.數(shù)據(jù)流圖

(3)分層DFD的指導原則

①注意父圖和子圖的平衡:父圖和子圖的輸入和輸出數(shù)據(jù)應保持一致.②區(qū)分局部文件和局部外部項.(內外相對變化)注意:一般地,除底層DFD需畫出全部文件名,各中間層的DFD僅畫出處于加工之間的接口文件,其余文件均不必畫出,以保持圖面的簡潔。

③掌握分解的速度:逐步細化(通常在上層可分解快一些,下一層應慢一些)

④遵守加工編號規(guī)則:頂層加工不編號第二層1,2,3,4…,n

第三層1.1,1.2…2.1,1.2…§4.數(shù)據(jù)流圖

數(shù)據(jù)流圖中每個成分的命名原則:可理解性。注意的問題:1.為數(shù)據(jù)流(或數(shù)據(jù)存儲)命名名字應代表整個數(shù)據(jù)流(或數(shù)據(jù)存儲)的內容,而不是僅僅反映它的某些成分。(2)不要使用空洞的、缺乏具體含義的名字(如“數(shù)據(jù)”、“信息”、“輸入”之類)。(3)為某個數(shù)據(jù)流(或數(shù)據(jù)存儲)起名字時遇到了困難,分析命名是否恰當,應該試試重新分解,看是否能克服這個困難4.數(shù)據(jù)流的命名§4.數(shù)據(jù)流圖

2.為處理(加工)命名通常先為數(shù)據(jù)流命名,然后再為與之相關聯(lián)的處理命名。(2)名字應該反映整個處理的功能,而不是它的一部分功能。(3)名字最好由一個具體的及物動詞加上一個具體的賓語組成。應該盡量避免使用“加工”、“處理”等空洞籠統(tǒng)的動詞作名字。§4.數(shù)據(jù)流圖

(4)通常名字中僅包括一個動詞,如果必須用兩個動詞才能描述整個處理的功能,則把這個處理再分解成兩個處理可能更恰當些。(5)如果在為某個處理命名時遇到困難,則很可能是發(fā)現(xiàn)了分解不當?shù)嫩E象,應考慮重新分解。數(shù)據(jù)源點/終點并不屬于數(shù)據(jù)流圖的核心內容,只不過是目標系統(tǒng)的外圍環(huán)境部分(可能是人員、計算機外部設備或傳感器裝置)。通常,為數(shù)據(jù)源點/終點命名時采用它們在問題域中習慣使用的名字(如“用戶”、“采購員”、“倉庫管理員”等)?!?.數(shù)據(jù)流圖

畫數(shù)據(jù)流圖的基本目的是利用它作為交流信息的工具。分析員把他對現(xiàn)有系統(tǒng)的認識或對目標系統(tǒng)的設想用數(shù)據(jù)流圖描繪出來,供有關人員審查確認。數(shù)據(jù)流圖的另一個主要用途是作為分析和設計的工具。著重描繪系統(tǒng)所完成的功能而不是系統(tǒng)的物理實現(xiàn)方案。數(shù)據(jù)流圖是實現(xiàn)這個目標的極好手段。

用途§4.數(shù)據(jù)流圖

數(shù)據(jù)字典(DD)是關于數(shù)據(jù)的信息的集合,也就是對數(shù)據(jù)流圖中包含的所有元素的定義的集合。字典的用途:供人查閱對不了解的條目的解釋,在軟件分析和設計的過程中給人提供關于數(shù)據(jù)的描述信息;數(shù)據(jù)字典是開發(fā)數(shù)據(jù)庫的第一步數(shù)據(jù)流圖和數(shù)據(jù)字典共同構成系統(tǒng)的邏輯模型§5.數(shù)據(jù)字典(DataDictionary,DD)數(shù)據(jù)字典中還應該包含關于數(shù)據(jù)的一些其他信息:一般信息(名字,別名,描述等等),定義(數(shù)據(jù)類型,長度,結構等等),使用特點(值的范圍,使用頻率,使用方式——輸入、輸出、本地,條件值等等),控制信息(來源,用戶,使用它的程序,改變權,使用權等等)分組信息(父結構,從屬結構,物理位置——記錄、文件和數(shù)據(jù)庫等等)。(1)對于同樣的數(shù)據(jù),不同的用戶使用了不同的名字;(2)一個分析員在不同時期對同一個數(shù)據(jù)使用了不同的名字;(3)兩個分析員分別分析同一個數(shù)據(jù)流時,使用了不同的名字。雖然應該盡量減少出現(xiàn)別名,但是不可能完全消除別名。出現(xiàn)別名主要有下述3個原因:數(shù)據(jù)元素組成數(shù)據(jù)的方式(1)順序即以確定次序連接兩個或多個分量;(2)選擇即從兩個或多個可能的元素中選取一個;(3)重復即把指定的分量重復零次或多次。重復次數(shù):重復算符通常和重復次數(shù)的上下限同時使用(當上下限相同時表示重復次數(shù)固定)。(4)可選即一個分量是可有可無的(重復零次或一次)。=意思是等價于(或定義為);+意思是和(即,連接兩個分量);[]意思是或(即,從方括弧內列出的若干個分量中選擇一個),通常用“|”號隔開供選擇的分量;{}意思是重復(即,重復花括弧內的分量);()意思是可選(即,圓括弧里的分量可有可無)。采用下列符號:標識符=字母字符+字母數(shù)字串字母數(shù)字串=0{字母或數(shù)字}7字母或數(shù)字=[字母字符|數(shù)字字符]例:名字:定貨報表別名:定貨信息描述:每天一次送檢采購員的需要定貨的零件表定義:定貨報表=零件編號+零件名稱

+定貨數(shù)量+目前價格

+主要供應者

+次要供應者位置:輸出到打印機}數(shù)據(jù)結構struct定貨報表{char零件編號[8];

char零件名稱[20];int定貨數(shù)量;float目前價格;structsupplier主要供應者;structsupplier次要供應者;};數(shù)據(jù)字典的實現(xiàn)通過計算機維護采用卡片§5.

數(shù)據(jù)字典名字:零件編號別名:描述:唯一地標識庫存清單中一個特定零件的關鍵域定義:零件編號=8{字符}8位置:定貨報告定貨信息庫存清單若修改“零件編號”的定義,則受到影響的數(shù)據(jù)均列于此§6成本/效益分析(Cost/Benefit)1、成本估計(CostEstimation)⑴代碼行技術:每行代碼的平均成本

源代碼行數(shù)⑵任務分解技術:人力

工資(3)自動估計成本技術采用自動估計成本的軟件工具,長期搜集的大量歷史數(shù)據(jù)為基礎,并且需要有良好的數(shù)據(jù)庫系統(tǒng)支持。§6成本/效益分析2、效益估計(BenefitEstimation)例:假設某軟件生命周期為5年?,F(xiàn)在投資20萬元,平均年利率3%。從第一年起,每年年底收入4.2萬元,問該項目是否值得投資?P=20萬4.2萬4.2萬4.2萬4.2萬4.2萬012345存入銀行§6成本/效益分析到第5年底結算時:存入銀行收入=200000(1+3%)5231855(元)投資軟件的收入=42000[(1+3%)4+(1+3%)3+(1+3%)2+(1+3%)+1]

222984(元)不合算!§6成本/效益分析

衡量工程價值的經濟指標有:⑴純收入

=折合現(xiàn)價的總收入-當前投資額

=⑵投資回收期例:第6年底可收回§1.需求分析的任務仍然回答“What”,而不是“How”,但更細致、精確(合同的擬定)可行性分析DFDDD功能具體化需求規(guī)格說明加細DFDDD算法描述IPOFinalstageofDefinitionphase§1.需求分析的任務1、確定要求⑴功能要求(functionalrequirements):系統(tǒng)必須做什么?⑵性能要求(performance

requirements):做得怎樣?例:responsetime,memory,back-upmemory,security,……⑶運行要求(operationalrequirements)

:運行環(huán)境、軟硬件配置等。⑷未來可能的擴充要求(possibleevolution)

?!?.需求分析的任務2、分析數(shù)據(jù)⑴建立概念模型(conceptualmodels):E-RDiagram⑵形象描繪數(shù)據(jù)結構:DataHierarchy,WarnierDiagram,IPO⑶數(shù)據(jù)結構規(guī)范化(Normalization)3、導出邏輯模型:

DFD+DD+IPO(輸入、處理、輸出)4、修正計劃:重估成本、進度等§1.需求分析的任務5、開發(fā)原型系統(tǒng)(Prototyping)“樣機試用”CD訪談獲取用戶需求的技術。兩種基本形式,正式的和非正式的訪談。正式訪談時,系統(tǒng)分析員將提出一些事先準備好的具體問題。在非正式訪談中,分析員將提出一些用戶可以自由回答的開放性問題,以鼓勵被訪問人員說出自己的想法?!?與用戶溝通獲取需求的方法

1.訪談當需要調查大量人員的意見時,分發(fā)調查表。用戶寫出書面回答,分析員仔細閱讀收回的調查表,有針對性地訪問一些用戶,詢問發(fā)現(xiàn)的新問題。在訪問用戶的過程中使用情景分析技術往往非常有效。所謂情景分析就是對用戶將來使用目標系統(tǒng)解決某個具體問題的方法和結果進行分析。§2與用戶溝通獲取需求的方法情景分析技術的用處主要體現(xiàn)在下述兩個方面:它能在某種程度上演示目標系統(tǒng)的行為,從而便于用戶理解,而且還可能進一步揭示出一些分析員目前還不知道的需求。(2)使用這種技術能保證用戶在需求分析過程中始終扮演一個積極主動的角色?!?與用戶溝通獲取需求的方法

在可行性研究階段許多實際的數(shù)據(jù)元素被忽略了,當時分析員還不需要考慮這些細節(jié),現(xiàn)在是定義這些數(shù)據(jù)元素的時候了。2.面向數(shù)據(jù)流自頂向下求精§2與用戶溝通獲取需求的方法結構化分析方法就是面向數(shù)據(jù)流自頂向下逐步求精進行需求分析的方法。從數(shù)據(jù)流圖的輸出端著手分析,這是因為系統(tǒng)的基本功能是產生這些輸出,輸出數(shù)據(jù)決定了系統(tǒng)必須具有的最基本的組成元素?!?與用戶溝通獲取需求的方法

輸出端處理

輸入端數(shù)據(jù)分析的方向數(shù)據(jù)沿數(shù)據(jù)流圖回溯時常常遇到下述問題:為了得到某個數(shù)據(jù)元素需要用到數(shù)據(jù)流圖中目前還沒有的數(shù)據(jù)元素,或者得出這個數(shù)據(jù)元素需要用的算法尚不完全清楚。§2與用戶溝通獲取需求的方法向用戶和其他有關人員請教,他們的回答使分析員對目標系統(tǒng)的認識更深入更具體了,系統(tǒng)中更多的數(shù)據(jù)元素被劃分出來了,更多的算法被搞清楚了。通常把分析過程中得到的有關數(shù)據(jù)元素的信息記錄在數(shù)據(jù)字典中,把對算法的簡明描述記錄在IPO圖(見3.7節(jié))中。通過分析而補充的數(shù)據(jù)流、數(shù)據(jù)存儲和處理,應該添加到數(shù)據(jù)流圖的適當位置上?!?與用戶溝通獲取需求的方法請用戶復查從數(shù)據(jù)流圖輸入端開始,分析員借助數(shù)據(jù)流圖、數(shù)據(jù)字典和IPO圖向用戶解釋輸入數(shù)據(jù)是怎樣一步一步地轉變成輸出數(shù)據(jù)的。這些認識正確嗎?有沒有遺漏?用戶應該注意傾聽分析員的報告,并及時糾正和補充分析員的認識。復查過程驗證了已知的元素,補充了未知的元素,填補了文檔中的空白。

面向數(shù)據(jù)流自頂向下求精過程不需分解有補充修正無補充修正分析追蹤數(shù)據(jù)流圖用戶復查細化數(shù)據(jù)流圖需要分解

一種面向團隊的需求收集法,稱為簡易的應用規(guī)格說明技術。這種方法提倡用戶與開發(fā)者密切合作,共同標識問題,提出解決方案要素,商討不同方案并指定基本需求。3.簡易的應用規(guī)格說明技術典型過程如下:首先進行初步的訪談,初步確定待解決的問題的范圍和解決方案。然后開發(fā)者和用戶分別寫出“產品需求”。選定會議的時間和地點,并選舉一個負責主持會議的協(xié)調人。邀請開發(fā)者和用戶雙方組織的代表出席會議,并在開會前預先把寫好的產品需求分發(fā)給每位與會者。列出作為系統(tǒng)環(huán)境組成部分的對象、系統(tǒng)將產生的對象以及系統(tǒng)為了完成自己的功能將使用的對象。列出操作這些對象或與這些對象交互的服務(即處理或功能)。列出約束條件(例如,成本、規(guī)模、完成日期)和性能標準(例如,速度、容量)。并不期望每位與會者列出的內容都是毫無遺漏的,但是,希望能準確地表達出每個人對目標系統(tǒng)的認識。討論的第一個問題是,是否需要這個新產品,一旦大家都同意確實需要這個新產品,可以把這些列表抄寫在大紙上釘在墻上,或者寫在白板上掛在墻上。理想的情況是,表中每一項都能單獨移動,這樣就能方便地刪除或增添表項,或組合不同的列表。在這個階段,嚴格禁止批評與爭論。大家共同創(chuàng)建一張組合列表。在組合列表中消去了冗余項,加入了在展示過程中產生的新想法,但是并不刪除任何實質性內容。由協(xié)調人主持討論這些列表。組合列表將被縮短、加長或重新措辭,以便更準確地描述將被開發(fā)的產品。討論的目標是,針對每個議題(對象、服務、約束和性能)都創(chuàng)建出一張意見一致的列表。一旦得出了意見一致的列表,就把與會者分成更小的小組,每個小組的工作目標是為每張列表中的項目制定小型規(guī)格說明。小型規(guī)格說明是對列表中包含的單詞或短語的準確說明。每個小組都向全體與會者展示他們制定的小型規(guī)格說明,供大家討論。通過討論可能會增加或刪除一些內容,也可能進一步做些精化工作。在完成了小型規(guī)格說明之后,每個與會者都制定出產品的一整套確認標準,并把自己制定的標準提交會議討論,以創(chuàng)建出意見一致的確認標準。最后,由一名或多名與會者根據(jù)會議成果起草完整的軟件需求規(guī)格說明書。許多突出優(yōu)點:開發(fā)者與用戶不分彼此,齊心協(xié)力,密切合作;即時討論并求精;有能導出規(guī)格說明的具體步驟。

構建原型的要點是,它應該實現(xiàn)用戶看得見的功能(例如,屏幕顯示或打印報表),省略目標系統(tǒng)的“隱含”功能(例如,修改文件)。4.快速建立軟件原型快速原型應該具備的第一個特性是“快速”。快速原型的目的是盡快向用戶提供一個可在計算機上運行的目標系統(tǒng)的模型,以便使用戶和開發(fā)者在目標系統(tǒng)應該“做什么”這個問題上盡可能快地達成共識。因此,原型的某些缺陷是可以忽略的,只要這些缺陷不嚴重地損害原型的功能,不會使用戶對產品的行為產生誤解,就不必管它們。

構建和修改原型的3種方法和工具:(1)第四代技術第四代技術包括眾多數(shù)據(jù)庫查詢和報表語言、程序和應用系統(tǒng)生成器以及其他非常高級的非過程語言。第四代技術使得軟件工程師能夠快速地生成可執(zhí)行的代碼,它們是較理想的快速原型工具。(2)可重用的軟件構件使用一組已有的軟件構件(也稱為組件)來裝配(而不是從頭構造)原型。軟件構件可以是數(shù)據(jù)結構(或數(shù)據(jù)庫),或軟件體系結構構件(即程序),或過程構件(即模塊)。必須把軟件構件設計成能在不知其內部工作細節(jié)的條件下重用。應該注意,現(xiàn)有的軟件可以被用作“新的或改進的”產品的原型。(3)形式化規(guī)格說明和原型環(huán)境用于替代自然語言規(guī)格說明技術。形式化語言的倡導者正在開發(fā)交互式環(huán)境,以便可以調用自動工具把基于形式語言的規(guī)格說明翻譯成可執(zhí)行的程序代碼,用戶能夠使用可執(zhí)行的原型代碼去進一步精化形式化的規(guī)格說明。為了更好地理解復雜事物,人們常常采用建立事物模型的方法。所謂模型,就是為了理解事物而對事物做出的一種抽象,是對事物的一種無歧義的書面描述。模型由一組圖形符號和組織這些符號的規(guī)則組成?!?分析建模與規(guī)格說明

分析建模需求分析過程應該建立3種模型,它們分別是數(shù)據(jù)模型、功能模型和行為模型。實體-聯(lián)系圖(E-R),描繪數(shù)據(jù)對象及數(shù)據(jù)對象之間的關系,是用于建立數(shù)據(jù)模型的圖形。數(shù)據(jù)流圖(DFD),描繪當數(shù)據(jù)在軟件系統(tǒng)中移動時被變換的邏輯過程,指明系統(tǒng)具有的變換數(shù)據(jù)的功能,因此,數(shù)據(jù)流圖是建立功能模型的基礎。狀態(tài)轉換圖(簡稱為狀態(tài)圖),指明了作為外部事件結果的系統(tǒng)行為。狀態(tài)轉換圖描繪了系統(tǒng)的各種行為模式(稱為“狀態(tài)”)和在不同狀態(tài)間轉換的方式。狀態(tài)轉換圖是行為建模的基礎。是需求分析階段得出的最主要的文檔。用自然語言完整、準確、具體地描述:系統(tǒng)的數(shù)據(jù)要求功能需求性能需求(響應時間、信息量速率、主存和磁盤容量、安全性)可靠性和可用性要求出錯處理需求(對錯誤的響應)接口需求(用戶、軟件、硬件、通信)約束(精度、工具、語言、使用的標準)逆向需求(不需要做什么)

軟件需求規(guī)格說明自然語言的規(guī)格說明具有容易書寫、容易理解的優(yōu)點,為大多數(shù)人所歡迎和采用。為了消除用自然語言書寫的軟件需求規(guī)格說明書中可能存在的不一致、歧義、含糊、不完整及抽象層次混亂等問題,也可采用用形式化方法描述用戶對軟件系統(tǒng)的需求。§4.實體-聯(lián)系圖1、概念性數(shù)據(jù)模型:描述從用戶角度看到的數(shù)據(jù)實體-聯(lián)系圖(Entity-RelationshipDiagram,ER圖)數(shù)據(jù)對象(實體)、數(shù)據(jù)對象的屬性、數(shù)據(jù)對象的聯(lián)系⑴Entities例:,

,學生

教師課程(2)Attributes例:,姓名學號(3)Relations例:學教111NMN§4.實體聯(lián)系圖教師學生學教課程職務學號姓名姓名性別性別職稱教工號ClassID成績系年級學時課名課程號例:學分教學管理的ER圖§5.數(shù)據(jù)規(guī)范化范式(NormalForms):消除數(shù)據(jù)冗余的程度

1-NF:所有屬性都是原子值,即不出現(xiàn)“表中有表”2-NF:在1-NF基礎上,每個非關鍵字屬性都由整個關鍵字決定(而非依賴于keyword的一部分)。3-NF:在2-NF基礎上,非關鍵字屬性之間無從屬關系。

狀態(tài)轉換圖(簡稱為狀態(tài)圖)通過描繪系統(tǒng)的狀態(tài)及引起系統(tǒng)狀態(tài)轉換的事件,來表示系統(tǒng)的行為。狀態(tài)圖還指明了作為特定事件的結果系統(tǒng)將做哪些動作(例如,處理數(shù)據(jù))。因此,狀態(tài)圖提供了行為建模機制3.6狀態(tài)轉換圖狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式,一個狀態(tài)代表系統(tǒng)的一種行為模式。狀態(tài)規(guī)定了系統(tǒng)對事件的響應方式。系統(tǒng)對事件的響應,既可以是做一個(或一系列)動作,也可以是僅僅改變系統(tǒng)本身的狀態(tài),還可以是既改變狀態(tài)又做動作。狀態(tài)主要有:初態(tài)(即初始狀態(tài))、終態(tài)(即最終狀態(tài))和中間狀態(tài)。在一張狀態(tài)圖中只能有一個初態(tài),而終態(tài)則可以有0至多個。

狀態(tài)狀態(tài)圖可以表示系統(tǒng)循環(huán)運行過程和系統(tǒng)單程生命期。描繪循環(huán)運行過程時,通常并不關心循環(huán)是怎樣啟動的。描繪單程生命期時,需要標明初始狀態(tài)(系統(tǒng)啟動時進入初始狀態(tài))和最終狀態(tài)(系統(tǒng)運行結束時到達最終狀態(tài))。事件是在某個特定時刻發(fā)生的事情,它是對引起系統(tǒng)做動作或(和)從一個狀態(tài)轉換到另一個狀態(tài)的外界事件的抽象。例如,內部時鐘表明某個規(guī)定的時間段已經過去,用戶移動或點擊鼠標等都是事件。事件就是引起系統(tǒng)做動作或(和)轉換狀態(tài)的控制信息。

事件初態(tài)用實心圓表示,終態(tài)用一對同心圓(內圓為實心圓)表示。中間狀態(tài)用圓角矩形表示,分上、中、下3個部分。上面部分為狀態(tài)的名稱,這部分是必須有的;中間部分為狀態(tài)變量的名字和值,這部分是可選的;下面部分是活動表,這部分也是可選的。

符號狀態(tài)圖中使用的主要符號

語法格式如下:事件名(參數(shù)表)/動作表達式其中,“事件名”可以是任何事件的名稱。3種標準事件:entry,exit和do。entry事件指定進入該狀態(tài)的動作,exit事件指定退出該狀態(tài)的動作,而do事件則指定在該狀態(tài)下的動作。帶箭頭的連線稱為狀態(tài)轉換,箭頭指明了轉換方向。狀態(tài)變遷通常是由事件觸發(fā)的,在表示狀態(tài)轉換的箭頭線上標出觸發(fā)轉換的事件表達式;如果在箭頭線上未標明事件,則表示在源狀態(tài)的內部活動執(zhí)行完之后自動觸發(fā)轉換。電話系統(tǒng)的狀態(tài)圖。圖中表明,沒有人打電話時電話處于閑置狀態(tài);有人拿起聽筒則進入撥號音狀態(tài),到達這個狀態(tài)后,電話的行為是響起撥號音并計時;這時如果拿起聽筒的人改變主意不想打了,他把聽筒放下(掛斷),電話重又回到閑置狀態(tài);如果拿起聽筒很長時間不撥號(超時),則進入超時狀態(tài);……。例子§7.圖形工具1、層次方框圖(Hierarchy)——描繪數(shù)據(jù)的結構例:例:P.58

3.5Warnier圖的一個例子§7.圖形工具法國計算機科學家Warnier提出2.Warnier圖或重復次數(shù)§7.圖形工具3、IPO圖(Input/Process/Output):簡要的算法描述1.校驗主記錄2.校驗事務記錄3.更新主記錄舊的主文件事務文件有效的主記錄有效的事務記錄更新后的主文件輸出O處理P輸入IIPO表系統(tǒng):作者:

模塊:日期:編號:被調用:調用:

輸入:輸出:處理:局部數(shù)據(jù)元素:注釋:改進的IPO圖的形式§5.驗證需求(RequirementsValidation)方法:

人工審查

初步用戶手冊

Prototyping

使用軟件工具——完整性、一致性把軟件工程使用的方法劃分成非形式化、半形式化和形式化3類。用自然語言描述需求規(guī)格說明,是典型的非形式化方法。用數(shù)據(jù)流圖或實體-聯(lián)系圖建立模型,是典型的半形式化方法。所謂形式化方法,是描述系統(tǒng)性質的基于數(shù)學的技術,也就是說,如果一種方法有堅實的數(shù)學基礎,那么它就是形式化的。用自然語言書寫的系統(tǒng)規(guī)格說明書,可能存在矛盾、二義性、含糊性、不完整性及抽象層次混亂等問題。所謂矛盾是指一組相互沖突的陳述。二義性是指讀者可以用不同方式理解的陳述。1概述

非形式化方法的缺點系統(tǒng)規(guī)格說明書不可避免地會出現(xiàn)含糊性。不完整性可能是在系統(tǒng)規(guī)格說明中最常遇到的問題之一。抽象層次混亂是指在非常抽象的陳述中混進了一些關于細節(jié)的低層次陳述。這樣的規(guī)格說明書使得讀者很難了解系統(tǒng)的整體功能結構。人們把數(shù)學引入軟件開發(fā)過程,創(chuàng)造了基于數(shù)學的形式化方法。在開發(fā)大型軟件系統(tǒng)的過程中應用數(shù)學,能夠帶來下述的幾個優(yōu)點:數(shù)學最有用的一個性質是,它能夠簡潔準確地描述物理現(xiàn)象、對象或動作的結果,因此是理想的建模工具。數(shù)學特別適合于表示狀態(tài),也就是表示“做什么”。形式化方法的優(yōu)點可以在不同的軟件工程活動之間平滑地過渡。不僅功能規(guī)格說明,而且系統(tǒng)設計也可以用數(shù)學表達,當然,程序代碼也是一種數(shù)學符號(雖然是一種相當繁瑣、冗長的數(shù)學符號)。它提供了高層確認的手段。可以使用數(shù)學方法證明,設計符合規(guī)格說明,程序代碼正確地實現(xiàn)了設計結果。對形式化方法也應該“一分為二”,既不要過分夸大它的優(yōu)點也不要一概排斥。為了更好地發(fā)揮這種方法的長處。

應用形式化方法的準則(1)應該選用適當?shù)谋硎痉椒ā?2)應該形式化,但不要過分形式化。(3)應該估算成本。使用形式化方法,需要進行大量的培訓。估算所需的成本。(4)應該有形式化方法顧問隨時提供咨詢。需要專家指導和培訓。

(5)不應該放棄傳統(tǒng)的開發(fā)方法。把形式化方法和結構化方法或面向對象方法集成起來是可能的,取長補短。(6)應該建立詳盡的文檔。建議使用自然語言注釋形式化的規(guī)格說明書,以幫助用戶和維護人員理解系統(tǒng)。(7)不應該放棄質量標準。形式化方法并不能保證軟件的正確性,有助于開發(fā)出高質量軟件的一種手段。必須一如既往地實施其他質量保證活動。(8)不應該盲目依賴形式化方法。是眾多工具中的一種。形式化方法并不能保證開發(fā)出的軟件絕對正確,必須用其他方法(例如,評審、測試)來驗證軟件正確性。(9)應該測試、測試再測試。形式化方法不僅不能保證軟件系統(tǒng)絕對正確,也不能證明系統(tǒng)性能或其他質量指標符合需要,因此,軟件測試的重要性并沒有降低。(10)應該重用。即使采用了形式化方法,軟件重用仍然是降低軟件成本和提高軟件質量的惟一合理的方法。而且用形式化方法說明的軟件構件具有清晰定義的功能和接口,使得它們有更好的可重用性。簡單例子。一個保險箱上裝了一個復合鎖,鎖有三個位置,分別標記為1、2、3,轉盤可向左(L)或向右(R)轉動。這樣,在任意時刻轉盤都有6種可能的運動,即1L、1R、2L、2R、3L和3R。保險箱的組合密碼是1L、3R、2L,轉盤的任何其他運動都將引起報警。2有窮狀態(tài)機

概念

保險箱的狀態(tài)轉換圖一個有窮狀態(tài)機包括下述5個部分:狀態(tài)集J、輸入集K、由當前狀態(tài)和當前輸入確定下一個狀態(tài)(次態(tài))的轉換函數(shù)T、初始態(tài)S和終態(tài)集F。對于保險箱的例子,相應的有窮狀態(tài)機的各部分如下。狀態(tài)集J:{保險箱鎖定,A,B,保險箱解鎖,報警}。輸入集K:{1L,1R,2L,2R,3L,3R}。轉換函數(shù)T:如表4.1所示。初始態(tài)S:保險箱鎖定。終態(tài)集F:{保險箱解鎖,報警}。如果使用更形式化的術語,一個有窮狀態(tài)機可以表示為一個5元組(J,K,T,S,F(xiàn)),其中:J是一個有窮的非空狀態(tài)集;K是一個有窮的非空輸入集;T是一個從(J-F)×K到J的轉換函數(shù);S∈J,是一個初始狀態(tài);F

J,是終態(tài)集。有窮狀態(tài)機的概念在計算機系統(tǒng)中應用得非常廣泛。例如,每個菜單驅動的用戶界面都是一個有窮狀態(tài)機的實現(xiàn)。一個菜單的顯示和一個狀態(tài)相對應,鍵盤輸入或用鼠標選擇一個圖標是使系統(tǒng)進入其他狀態(tài)的一個事件。狀態(tài)的每個轉換都具有下面的形式:當前狀態(tài)〔菜單〕+事件〔所選擇的項〕下個狀態(tài)。對有窮狀態(tài)機做一個很有用的擴展,即在前述的5元組中加入第6個組件——謂詞集P,從而把有窮狀態(tài)機擴展為一個6元組,其中每個謂詞都是系統(tǒng)全局狀態(tài)Y的函數(shù)。轉換函數(shù)T現(xiàn)在是一個從(J-F)×K×P到J的函數(shù)。現(xiàn)在的轉換規(guī)則形式如下:當前狀態(tài)〔菜單〕+事件〔所選擇的項〕+謂詞下個狀態(tài)。用有窮狀態(tài)機技術表達系統(tǒng)的規(guī)格說明,給出電梯系統(tǒng)的規(guī)格說明。首先給出用自然語言描述的對電梯系統(tǒng)的需求:在一幢m層的大廈中需要一套控制n部電梯的產品,要求這n部電梯按照約束條件C1,C2和C3在樓層間移動。C1:每部電梯內有m個按鈕,每個按鈕代表一個樓層。當按下一個按鈕時該按鈕指示燈亮,同時電梯駛向相應的樓層,到達按鈕指定的樓層時指示燈熄滅。

例子C2:除了大廈的最低層和最高層之外,每層樓都有兩個按鈕分別請求電梯上行和下行。這兩個按鈕之一被按下時相應的指示燈亮,當電梯到達此樓層時燈熄滅,電梯向要求的方向移動。C3:當對電梯沒有請求時,它關門并停在當前樓層?,F(xiàn)在使用一個擴展的有窮狀態(tài)機對本產品進行規(guī)格說明。這個問題中有兩個按鈕集。n部電梯中的每一部都有m個按鈕,一個按鈕對應一個樓層。因為這m×n個按鈕都在電梯中,所以稱它們?yōu)殡娞莅粹o。此外,每層樓有兩個按鈕,一個請求向上,另一個請求向下,這些按鈕稱為樓層按鈕。電梯按鈕的狀態(tài)轉換圖如圖4.2所示。令EB(e,f)表示按下電梯e內的按鈕并請求到f層去。EB(e,f)有兩個狀態(tài),分別是按鈕發(fā)光(打開)和不發(fā)光(關閉)。更精確地說,狀態(tài)是:EBON(e,f):電梯按鈕(e,f)打開EBOFF(e,f):電梯按鈕(e,f)關閉如果電梯按鈕(e,f)發(fā)光且電梯到達f層,該按鈕將熄滅。相反如果按鈕熄滅,則按下它時,按鈕將發(fā)光。上述描述中包含了兩個事件,它們分別是:EBP(e,f):電梯按鈕(e,f)被按下EAF(e,f):電梯e到達f層

電梯按鈕的狀態(tài)轉換圖

EBON(e,f):電梯按鈕(e,f)打開EBOFF(e,f):電梯按鈕(e,f)關閉EBP(e,f):電梯按鈕(e,f)被按下EAF(e,f):電梯e到達f層為了定義與這些事件和狀態(tài)相聯(lián)系的狀態(tài)轉換規(guī)則,需要一個謂詞V(e,f),它的含義如下:V(e,f):電梯e停在f層如果電梯按鈕(e,f)處于關閉狀態(tài)〔當前狀態(tài)〕,而且電梯按鈕(e,f)被按下〔事件〕,而且電梯e不在f層〔謂詞〕,則該電梯按鈕打開發(fā)光〔下個狀態(tài)〕。狀態(tài)轉換規(guī)則的形式化描述如下:EBOFF(e,f)+EBP(e,f)+notV(e,f)

EBON(e,f)反之,如果電梯到達f層,而且電梯按鈕是打開的,于是它就會熄滅。這條轉換規(guī)則可以形式化地表示為:EBON(e,f)+EAF(e,f)

EBOFF(e,f)接下來考慮樓層按鈕。令FB(d,f)表示f層請求電梯向d方向運動的按鈕,樓層按鈕FB(d,f)的狀態(tài)轉換圖如圖4.3所示。樓層按鈕的狀態(tài)如下:FBON(d,f):樓層按鈕(d,f)打開FBOFF(d,f):樓層按鈕(d,f)關閉如果樓層按鈕已經打開,而且一部電梯到達f層,則按鈕關閉。反之,如果樓層按鈕原來是關閉的,被按下后該按鈕將打開。這段敘述中包含了以下兩個事件。樓層按鈕的狀態(tài)轉換圖FBP(d,f):樓層按鈕(d,f)被按下EAF(1…n,f):電梯1或…或n到達f層其中1…n表示或為1或為2…或為n。FBON(d,f):樓層按鈕(d,f)打開FBOFF(d,f):樓層按鈕(d,f)關閉

為了定義與這些事件和狀態(tài)相聯(lián)系的狀態(tài)轉換規(guī)則,同樣也需要一個謂詞,它是S(d,e,f),它的定義如下。S(d,e,f):電梯e停在f層并且移動方向由d確定為向上(d=U)或向下(d=D)或待定(d=N)。這個謂詞實際上是一個狀態(tài),形式化方法允許把事件和狀態(tài)作為謂詞對待。使用謂詞S(d,e,f),形式化轉換規(guī)則為:FBOFF(d,f)+FBP(d,f)+notS(d,1…n,f)

FBON(d,f)FBON(d,f)+EAF(1…n,f)+S(d,1…n,f)

FBOFF(d,f)其中,d=UorD。也就是說,如果在f層請求電梯向d方向運動的樓層按鈕處于關閉狀態(tài),現(xiàn)在該按鈕被按下,并且當時沒有正停在f層準備向d方向移動的電梯,則該樓層按鈕打開。反之,如果樓層按鈕已經打開,且至少有一部電梯到達f層,該部電梯將朝d方向運動,則按鈕將關閉。在討論電梯按鈕狀態(tài)轉換規(guī)則時定義的謂詞V(e,f),可以用謂詞S(d,e,f)重新定義如下:V(e,f)=S(U,e,f)orS(D,e,f)orS(N,e,f)定義電梯按鈕和樓層按鈕的狀態(tài)都是很簡單、直觀的事情?,F(xiàn)在轉向討論電梯的狀態(tài)及其轉換規(guī)則,就會出現(xiàn)一些復雜的情況。一個電梯狀態(tài)實質上包含許多子狀態(tài)。下面定義電梯的3個狀態(tài):M(d,e,f):電梯e正沿d方向移動,即將到達的是第f層S(d,e,f):電梯e停在f層,將朝d方向移動(尚未關門)W(e,f):電梯e在f層等待(已關門)其中S(d,e,f)狀態(tài)已在討論樓層按鈕時定義過,但是,現(xiàn)在的定義更完備一些。圖4.4是電梯的狀態(tài)轉換圖。3個電梯停止狀態(tài)S(U,e,f)、S(N,e,f)和S(D,e,f)已被組合成一個大的狀態(tài),這樣做的目的是減少狀態(tài)總數(shù)以簡化流圖。圖4.4中包含了下述3個可觸發(fā)狀態(tài)發(fā)生改變的事件。DC(e,f):電梯e在樓層f關上門ST(e,f):電梯e靠近f層時觸發(fā)傳感器,電梯控制器決定在當前樓層電梯是否停下RL:電梯按鈕或樓層按鈕被按下進入打開狀態(tài),登錄需求

電梯的狀態(tài)轉換圖S(d,e,f):電梯e停在f層并且移動方向由d確定RL:電梯按鈕或樓層按鈕被按下進入打開狀態(tài)最后,給出電梯的狀態(tài)轉換規(guī)則。為簡單起見,這里給出的規(guī)則僅發(fā)生在關門之時。S(U,e,f)+DC(e,f)

M(U,e,f+1)S(D,e,f)+DC(e,f)

M(D,e,f-1)S(N,e,f)+DC(e,f)

W(e,f)第一條規(guī)則表明,如果電梯e停在f層準備向上移動,且門已經關閉,則電梯將向上一樓層移動。第二條和第三條規(guī)則,分別對應于電梯即將下降或者沒有待處理的請求的情況。有窮狀態(tài)機方法采用了一種簡單的格式來描述規(guī)格說明:當前狀態(tài)+事件+謂詞下個狀態(tài)這種形式的規(guī)格說明易于書寫、易于驗證,而且可以比較容易地把它轉變成設計或程序代碼。事實上,可以開發(fā)一個CASE工具把一個有窮狀態(tài)機規(guī)格說明直接轉變?yōu)樵创a。維護可以通過重新轉變來實現(xiàn),也就是說,如果需要一個新的狀態(tài)或事件,首先修改規(guī)格說明,然后直接由新的規(guī)格說明生成新版本的產品。評價有窮狀態(tài)機方法比數(shù)據(jù)流圖技術更精確,而且和它一樣易于理解。不過,它也有缺點:在開發(fā)一個大系統(tǒng)時三元組(即狀態(tài)、事件、謂詞)的數(shù)量會迅速增長。此外,和數(shù)據(jù)流圖方法一樣,形式化的有窮狀態(tài)機方法也沒有處理定時需求。下節(jié)將介紹的Petri網(wǎng)技術,是一種可處理定時問題的形式化方法。并發(fā)系統(tǒng)中遇到的一個主要問題是定時問題。如同步問題、競爭條件以及死鎖問題。定時問題通常是由不好的設計或有錯誤的實現(xiàn)引起的,而這樣的設計或實現(xiàn)通常又是由不好的規(guī)格說明造成的。如果規(guī)格說明不恰當,則有導致不完善的設計或實現(xiàn)的危險。用于確定系統(tǒng)中隱含的定時問題的一種有效技術是Petri網(wǎng),這種技術的一個很大的優(yōu)點是它也可以用于設計中。Petri網(wǎng)

概念Petri網(wǎng)是由CarlAdamPetri發(fā)明的。Petri網(wǎng)在計算機科學中也得到廣泛的應用,例如,在性能評價、操作系統(tǒng)和軟件工程等領域,Petri網(wǎng)應用得都比較廣泛。特別是已經證明,用Petri網(wǎng)可以有效地描述并發(fā)活動。Petri網(wǎng)包含4種元素:一組位置P、一組轉換T、輸入函數(shù)I以及輸出函數(shù)O。Petri網(wǎng)的組成短直線代表轉換圓圈代表位置輸入函數(shù)輸出函數(shù)一組位置P為{P1,P2,P3,P4},在圖中用圓圈代表位置。一組轉換T為{t1,t2},在圖中用短直線表示轉換。兩個用于轉換的輸入函數(shù),用由位置指向轉換的箭頭表示,它們是:I(t1)={P2,P4}I(t2)={P2}兩個用于轉換的輸出函數(shù),用由轉換指向位置的箭頭表示,它們是:O(t1)={P1}O(t2)={P3,P3}注意,輸出函數(shù)O(t2)中有兩個P3,是因為有兩個箭頭由t2指向P3。更形式化的Petri網(wǎng)結構,是一個四元組C=(P,T,I,O)。其中,P={P1,…,Pn}是一個有窮位置集,n≥0。T={t1,…,tm}是一個有窮轉換集,m≥0,且T和P不相交。I:T→P∞為輸入函數(shù),是由轉換到位置無序單位組(bags)的映射。O:T→P∞為輸出函數(shù),是由轉換到位置無序單位組的映射。Petri網(wǎng)的標記是在Petri網(wǎng)中權標(token,也稱令牌)的分配。有4個權標,P1(1)中,P2(2),P3(0)P4(1)。上述標記可以用向量(1,2,0,1)表示。Petri網(wǎng)在轉換t1被激發(fā)后的情況Petri網(wǎng)在轉換t1被激發(fā)后的情況(2,1,0,0)(1,2,0,1)由于P2和P4中有權標,因此t1啟動(即被激發(fā))。通常,當每個輸入位置所擁有的權標數(shù)大于等于從該位置到轉換的線數(shù)時,就允許轉換。當t1被激發(fā)時,P2和P4上各有一個權標被移出,而P1上則增加一個權標。Petri網(wǎng)中權標總數(shù)不是固定的,在這個例子中兩個權標被移出,而P1上只能增加一個權標。圖中P2上有權標,因此t2也可以被激發(fā)。當t2被激發(fā)時,P2上將移走一個權標,而P3上新增加兩個權標。Petri網(wǎng)具有非確定性,也就是說,如果數(shù)個轉換都達到了激發(fā)條件,則其中任意一個都可以被激發(fā)。圖4.6所示Petri網(wǎng)的標記為(1,2,0,1),t1和t2都可以被激發(fā)。假設t1被激發(fā)了,則結果如圖4.7所示,標記為(2,1,0,0)。此時,只有t2可以被激發(fā)。如果t2也被激發(fā)了,則權標從P2中移出,兩個新權標被放在P3上,結果如圖4.8所示,標記為(2,0,2,0)。Petri網(wǎng)在轉換t2被激發(fā)后的情況(2,1,0,0)(2,0,2,0)

含禁止線的Petri網(wǎng)禁止線是用一個小圓圈而不是用箭頭標記的輸入線。通常,當每個輸入線上至少有一個權標,而禁止線上沒有權標的時候,相應的轉換才是允許的更形式化地說,Petri網(wǎng)C=(P,T,I,O)中的標記M,是由一組位置P到一組非負整數(shù)的映射:M:P→{0,1,2,…}這樣,帶有標記的Petri網(wǎng)成為一個五元組(P,T,I,O,M)。對Petri網(wǎng)的一個重要擴充是加入禁止線。禁止線是用一個小圓圈而不是用箭頭標記的輸入線。通常,當每個輸入線上至少有一個權標,而禁止線上沒有權標的時候,相應的轉換才是允許的?,F(xiàn)在把Petri網(wǎng)應用于電梯問題。當用Petri網(wǎng)表示電梯系統(tǒng)的規(guī)格說明時,每個樓層用一個位置Ff代表(1≤f≤m),在Petri網(wǎng)中電梯是用一個權標代表的。在位置Ff上有權標,表示在樓層f上有電梯。1.電梯按鈕電梯問題的第一個約束條件描述了電梯按鈕的行為,現(xiàn)在復述一下這個約束條件。

例子第一條約束C1:每部電梯有m個按鈕,每層對應一個按鈕。當按下一個按鈕時該按鈕指示燈亮,指示電梯移往相應的樓層。當電梯到達指定的樓層時,按鈕將熄滅。為了用Petri網(wǎng)表達電梯按鈕的規(guī)格說明,在Petri網(wǎng)中還必須設置其他的位置。電梯中樓層f的按鈕,在Petri網(wǎng)中用位置EBf表示(1≤f≤m)。在EBf上有一個權標,就表示電梯內樓層f的按鈕被按下了。電梯按鈕只有在第一次被按下時才會由暗變亮,以后再按它則只會被忽略。Petri網(wǎng)準確地描述了電梯按鈕的行為規(guī)律。首先,假設按鈕沒有發(fā)亮,顯然在位置EBf上沒有權標,從而在存在禁止線的情況下,轉換“EBf被按下”是允許發(fā)生的。假設現(xiàn)在按下按鈕,則轉換被

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論