軟件工程基本概念
軟件危機
軟件的功能、規模及復雜性與日俱增,軟件的復雜性達到了它的開發者難以控制的程度
這種情況導致了嚴重的后果: 軟件可靠性下降 開發效率低下 維護極為困難
這使軟件開發者陷入困境,人們稱之為“軟件危機”
解決軟件危機
軟件開發行業的研究
1. 程序設計方法學的研究
結構化程序設計方法
面向對象程序設計方法
2. 軟件工程學的研究
用工程學的方法進行軟件的開發與維護,并對軟件生產過程進行工程化的管理
3. 其它方面
并發程序設計
數據結構與算法
編程語言 ……
軟件工程的定義
概括地說,軟件工程是指導計算機軟件開發和維護的一門工程學科。采用工程化的方法來開發和維護軟件,把經過時間考驗而證明正確的工程管理技術和當前能夠得到的最好的技術方法結合起來,以經濟地開發出高質量的軟件并有效地維護它,這就是軟件工程。
軟件工程的內容
針對軟件生命周期全過程及其每個具體階段的工程方法、技術細則、文檔規范、技術支持、管理制度、人員組織以及質量保證體系等。每個軟件開發者必須按工程的統一要求行事,不能隨意地自由發揮。每個開發階段都要產生健全的、符合工程規范的文檔。軟件產品是這些文檔的總合,而不僅僅是程序。
軟件工程三要素
1. 方法:完成軟件開發的各項任務的技術方法,為軟件開發提供 “如何做” 的技術
2. 工具:為運用方法而提供的自動的或半自動的軟件工程的支撐環境
3. 過程:為了獲得高質量的軟件所需要完成的一系列任務的框架,它規定了完成各項任務的工作步驟,如何將軟件工程方法與軟件工具相結合,合理、及時地進行軟件開發
我們在項目中采用的方法、工具、過程
方法:面向對象方法
工具:EA
過程:基于原型的增量迭代軟件開發過程
軟件生命周期(一)
1. 可行性分析階段
本階段的主要任務:系統分析員在用戶的配合下對用戶的要求和現有的環境進行深入調查并寫出調研報告,從經濟可行性、技術可行性、操作可行性、法律可行性等方面研究并論證該項目的可行性,即該項目是否值得去做,是否存在可行的解決辦法。
本階段的主要成果:可行性分析報告。
2. 需求分析階段
本階段的主要任務:系統分析員和用戶反復討論和商量,充分交流信息,確定待開發的軟件系統“做什么”,確定軟件系統的功能需求和非功能需求,用某種方法和工具構件軟件系統模型,并編寫軟件需求規格說明書。
本階段的主要成果:軟件需求規格說明書(Software Requirements Specification,即SRS)。
軟件生命周期(二)
3. 系統設計階段
本階段的主要任務:根據需求分析階段確定的功能需求和非功能需求,對整個系統進行總體框架設計、詳細功能設計和數據庫設計等。簡單來說,需求分析階段回答“做什么”的問題,而系統設計階段要回答“怎么做”的問題。設計階段又分為概要設計和詳細設計。概要設計是以需求分析的結果為依據定義系統的主要構成成分和它們之間的關系。而詳細設計是定義每個系統成分內部的構造細節。
本階段的主要成果:概要設計說明、詳細設計說明書、數據庫設計說明書。
4. 系統實現階段: 通常也稱為編碼階段。
本階段的主要任務:根據詳細設計說明書,用某種選定的程序設計語言把詳細設計的結果轉化成機器可運行的源代碼,這是一個編寫和調試程序的過程。
本階段的主要成果:通過單元測試的源代碼。
軟件生命周期(三)
5. 測試階段
本階段的主要任務:通過各種軟件測試方法和測試工具,使軟件的Bug降到最低。
本階段的主要成果:軟件測試報告。
6. 維護階段
本階段的主要任務:通過各種必要的維護活動使系統持久地滿足用戶的需要。
通常維護活動有四類:
改正性維護:診斷和改正系統使用過程中發現的軟件錯誤。
適應性維護:修改軟件以適應環境的變化。
完善性維護:根據用戶的要求改進或擴充軟件使它更完善。
預防性維護:即修改軟件為將來的維護活動做準備。
本階段的主要成果:軟件問題報告、軟件變動記錄、軟件維護記錄。
軟件開發過程
軟件開發過程是在軟件生命周期的軟件系統開發過程中,一系列活動和軟件生成結果的集合。軟件過程模型描述軟件開發過程的各項活動、角色、產品及其相互關系的模型。
目前有若干軟件過程模型,各種模型有其不同的特點,并適用于不同的開發方法。例如,瀑布模型、循環模型、螺旋模型、增量模型和噴泉模型等。
不同的軟件開發方法和軟件開發模型要求有不同的工程體系。從歷史看,使用最多的是結構化方法和瀑布模型。代表當前技術主流的是面向對象方法和噴泉模型。
統一建模語言UML
如同蓋一座高樓大廈需要先畫建筑圖建立模型一樣,在軟件系統開發的系統分析和設計階段時,我們通常會使用建模技術為系統建立模型。在軟件工程發展過程中,出現了很多建模技術。最終,IBM的統一建模語言UML成為業界認同的統一建模技術。
統一建模語言UML(Unified Modeling Language)是專門用來進行軟件系統設計和架構建模的一門可視化建模語言,它通過各種圖示展示了軟件系統的方方面面。
UML圖有很多種,對于程序員來說,最頻繁使用的莫過于類圖。類圖主要是用來顯示系統中的類、接口以及它們之間的靜態結構和關系的一種靜態模型。類圖中最基本的元素是類、接口。軟件設計師設計出類圖后,程序員就可以用代碼實現類圖中包含的內容。
使用類圖表示關系
類和類、類和接口、接口和接口之間存在一定關系,共有六種類型:分別是實現關系、泛化關系、關聯關系、依賴關系、聚合關系、組合關系,
1. 實現關系是指接口及其實現類之間的關系。
2. 泛化關系(Generalization)是指對象與對象之間的繼承關系。
3. 關聯關系(Association)是指對象和對象之間的連接,它使一個對象知道另一個對象的屬性和方法。在java中,關聯關系的代碼表現形式為一個對象含有另一個對象的引用。 關聯關系有單向關聯和雙向關聯。
4. 依賴 (Dependency) 關系是一種弱關聯關系。依賴關系在Java中的具體代碼表現形式為B為A的構造器或方法中的局部變量、方法或構造器的參數、方法的返回值,或者A調用B的靜態方法。
5. 聚合(Aggregation)是關聯關系的一種特例,它體現的是整體與部分的擁有關系,即“has a”的關系。此時整體與部分之間是可分離的,它們可以具有各自的生命周期,部分可以屬于多個整體對象,也可以為多個整體對象共享,所以聚合關系也常稱為共享關系。(比如:部門和員工)
6. 組合(Composition)也是關聯關系的一種特例,它同樣體現整體與部分間的包含關系,即“contains a”的關系。但此時整體與部分是不可分的,部分也不能給其它整體共享,作為整體的對象負責部分的對象的生命周期。這種關系比聚合更強,也稱為強聚合。(比如:公司和部門)
面向對象系統分析與設計
在面向對象技術中,建造整個軟件系統的過程常常被稱為面向對象的分析和設計(Object-Oriented Analysis and Design,OOAD)。對于我們要開發的軟件系統來說,OOAD解決了系統是什么(面向對象的系統分析,即OOA)以及如何做的問題(面向對象的系統設計,即OOD),OOP只是用編程語言去實現該系統。
一般來說,OOAD工作一般由需求分析師、系統分析員、系統架構師來完成,而OOP則由程序員來完成。但是,對于程序員來說,掌握OOD技術,對于編寫高質量的代碼以及個人技術成長和職業規劃來說,有特別重要的意義。
新聞熱點
疑難解答