軟體工程基本系統模型

A. 軟體工程三種演化模型的相同點和不同點

瀑布模型，演化模型（如增量模型、原型模型、螺旋模型）、噴泉模型、基於構件的開發模型和形式方法模型等。
瀑布模型（waterfall model）是1970年有W.Royce提出的，它給出了軟體生存周期活動的固定順序，上一階段的活動完成後向下一階段過渡，最終得到所開發的軟體產品。瀑布模型如下圖所示，有時也稱為軟體生存周期模型。

瀑布模型中，上一階段的活動完成並經過評審後才能開始下一階段的活動，其特徵是：
（1）接受上一階段的結果作為本階段活動的輸入。
（2）依據上一階段活動的結果實施本階段應完成的活動。
（3）對本階段的活動進行評審。
（4）將本階段活動的結果作為輸出，傳遞給下一階段。
瀑布模型是最早出現的也是應用最廣泛的過程模型，對確保軟體開發的順利進行、提高軟體項目的質量和開發效率起到重要作用。
在大量的實踐過程中，瀑布模型也逐漸暴露出它的不足。首先，客戶常常難以清楚地描述所有的要求，而且在開發過程中，用戶的需求也常常會有所變化，使得不少軟體的需求存在著不確定性；在某個活動中發現的錯誤常常是由前一階段活動的錯誤引起的，為了改正這一錯誤必須回到前一階段，這就導致了瀑布的倒流，也就是說，實際的軟體開發很少能按瀑布模型的順序沒有迴流地順流而下。其次，瀑布模型使得客戶在測試完成以後才能看到真正可運行的軟體，此時，如果發現不滿足客戶需求的問題（由於需求不確定性），那麼修改軟體的代價是巨大的。
不是任何軟體都可採用瀑布模型的，瀑布模型適合於結構化方法，也就是面向過程的軟體開發方法。軟體項目或產品選擇瀑布模型必須滿足下列條件：在開發時間內需求沒有或很少變化；分析設計人員應對應用領域很熟悉；低風險項目（對目標、環境很熟悉）；用戶使用環境很穩定；用戶除提出需求以外，很少參與開發工作。
演化模型
演化模型主要針對事先不能完整定義需求的軟體開發，其開發過程一般是首先開發核心系統，當核心系統投入運行後，軟體開發人員根據用戶的反饋，實施開發的迭代過程，每一迭代過程均由需求、設計、編碼、測試、集成等階段組成，直到軟體開發結束。演化模型在一定程度上減少了軟體開發活動的盲目性。

螺旋模型：
它是在瀑布模型和演化模型的基礎上，加入兩者所忽略的風險分析所建立的一種軟體開發模型。沿螺旋模型順時針方向，依次表達了四個方面的活動，制定計劃、風險分析、實施工程、客戶評估。

噴泉模型
它體現了軟體創建所固有的迭代和無間隙特徵，噴泉模型主要用於支持面向對象開發過程。
增量模型內容：
在設計了軟體系統整體體系結構之後，首先完整的開發系統的一個初始子集，繼之，根據這一子集，建造一個更加精細的版本，如此不斷的進行系統的增量開發。

瀑布模型、演化模型、螺旋模型之間的聯系：相同點是這三個模型都分為多個階段，而瀑布模型一次完成軟體，演化模型分為多次完成，每次迭代完成軟體的一個部分，螺旋模型也分為多次完成，每次完成軟體的一個新原型，並考慮風險分析。

演化模型和增量模型之間的區別
演化模型首先開發核心系統，每次迭代為系統增加一個子集，整個系統是增量開發和增量提交，增量模型首先完整的開發系統的一個初始子集，然後不斷的建造更精細的版本。

B. 軟體工程的模型都有那些

都忘光了,只記得有個螺旋型的比較好

C. 軟體開發模型有哪幾種各有什麼特點

軟體開發模型(Software Development Model)是指軟體開發全部過程、活動和任務的結構框架。軟體開發包括需求、設計、編碼和測試等階段，有時也包括維護階段。軟體開發模型能清晰、直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體項目工作的基礎。對於不同的軟體系統，可以採用不同的開發方法、使用不同的程序設計語言以及各種不同技能的人員參與工作、運用不同的管理方法和手段等，以及允許採用不同的軟體工具和不同的軟體工程環境。軟體工程的主要環節包括人員管理、項目管理、需求分析、系統設計、程序設計、測試、維護等，如圖所示。軟體開發模型是對軟體過程的建模，即用一定的流程將各個環節連接起來，並可用規范的方式操作全過程，好比工廠的生產線。

8.混合模型（hybrid model）過程開發模型又叫混合模型（hybrid model），或元模型（meta-model）,把幾種不同模型組合成一種混合模型，它允許一個項目能沿著最有效的路徑發展，這就是過程開發模型（或混合模型）。實際上，一些軟體開發單位都是使用幾種不同的開發方法組成他們自己的混合模型。各種模型的比較每個軟體開發組織應該選擇適合於該組織的軟體開發模型，並且應該隨著當前正在開發的特定產品特性而變化，以減小所選模型的缺點，充分利用其優點，下表列出了幾種常見模型的優缺點。各種模型的優點和缺點：模型優點缺點瀑布模型文檔驅動系統可能不滿足客戶的需求快速原型模型關注滿足客戶需求可能導致系統設計差、效率低，難於維護增量模型開發早期反饋及時，易於維護需要開放式體系結構，可能會設計差、效率低螺旋模型風險驅動風險分析人員需要有經驗且經過充分訓練

9.RUP模型（迭代模型）

RUP（Rational Unified Process）模型是Rational公司提出的一套開發過程模型，它是一個面向對象軟體工程的通用業務流程。它描述了一系列相關的軟體工程流程，它們具有相同的結構，即相同的流程構架。RUP 為在開發組織中分配任務和職責提供了一種規范方法，其目標是確保在可預計的時間安排和預算內開發出滿足最終用戶需求的高品質的軟體。RUP具有兩個軸，一個軸是時間軸，這是動態的。另一個軸是工作流軸，這是靜態的。在時間軸上，RUP劃分了四個階段：初始階段、細化階段、構造階段和發布階段。每個階段都使用了迭代的概念。在工作流軸上，RUP設計了六個核心工作流程和三個核心支撐工作流程，核心工作流軸包括：業務建模工作流、需求工作流、分析設計工作流、實現工作流、測試工作流和發布工作流。核心支撐工作流包括：環境工作流、項目管理工作流和配置與變更管理工作流。RUP 匯集現代軟體開發中多方面的最佳經驗，並為適應各種項目及組織的需要提供了靈活的形式。作為一個商業模型，它具有非常詳細的過程指導和模板。但是同樣由於該模型比較復雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。它具有如下特點：（1）增量迭代，每次迭代都遵循瀑布模型能夠在前期控制好和解決風險；（2）模型的復雜化，需要項目管理者具有較強的管理能力。

10.IPD模型

IPD（Integrated Proct Development）流程是由IBM提出來的一套集成產品開發流程，非常適合於復雜的大型開發項目，尤其涉及到軟硬體結合的項目。

IPD從整個產品角度出發，流程綜合考慮了從系統工程、研發（硬體、軟體、結構工業設計、測試、資料開發等）、製造、財務到市場、采購、技術支援等所有流程。是一個端到端的流程。在IPD流程中總共劃分了六個階段（概念階段、計劃階段、開發階段、驗證階段、發布階段和生命周期階段），四個個決策評審點（概念階段決策評審點、計劃階段決策評審點、可獲得性決策評審點和生命周期終止決策評審點）以及六個技術評審點。

IPD流程是一個階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復雜的流程來把一個龐大而又復雜的系統進行分解並降低風險。一定程度上，該模型是通過流程成本來提高整個產品的質量並獲得市場的佔有。由於該流程沒有定義如何進行流程回退的機制，因此對於需求經常變動的項目該流程就顯得不大適合了。並且對於一些小的項目，也不是非常適合使用該流程。

D. 軟體工程：若開發一個學生信息管理系統，應該採用哪種開發模型為什麼

根據系統的需求和項目管理及開發團隊的素質來定：噴泉模型，面向對象的軟體開發；
快速原型模型，小型或互動式系統；
增量模型，用戶需求穩定；
瀑布模型，用戶需求明確。

E. 軟體工程中的主要體系結構有哪些，並說明區別

20世紀60年代的軟體危機使得人們開始重視軟體工程的研究。起初，人們把軟體設計的重點放在數據結構和演算法的選擇上，然而隨著軟體系統規模越來越大，對總體的系統結構設計和規格說明變得異常重要。隨著軟體危機程度的加劇，軟體體系結構(software architecture)這一概念應運而生。軟體體系結構著眼於軟體系統的全局組織形式，在較高層次上把握系統各部分之間的內在聯系，將軟體開發的焦點從成百上千的代碼上轉移到粒度較大的體系結構元素及其交互的設計上。與傳統軟體技術相比，軟體體系結構理論的提出不僅有利於解決軟體系統日益增加的規模和復雜度的問題，有利於構件的重用，也有利於軟體生產率的提高。面向方面軟體開發(AOSD)認為系統是由核心關注點(corn concern)和橫切關注點(cross-cutting concern)有機地交織在一起而形成的。核心關注點是軟體要實現的主要功能和目標，橫切關注點是那些與核心關注點之間有橫切作用的關注點，如系統日誌、事務處理和許可權驗證等。AOSD通過分離系統的橫切關注點和核心關注點，使得系統的設計和維護變得容易很多。
Extremara大學的Navasa等人［1］在2002年提出了將面向方面軟體開發技術引入到軟體體系結構的設計中，稱之為面向方面軟體體系結構(aspect oriented software architecture，AO-SA)，這樣能夠結合兩者的優點，但是並沒有給出構建面向方面軟體體系結構的詳細方法。
盡管目前對於面向方面軟體體系結構這個概念尚未形成統一的認識，但是一般認為面向方面軟體體系結構在傳統軟體體系結構基礎上增加了方面構件(aspect component)這一新的構成單元，通過方面構件來封裝系統的橫切關注點。目前國內外對於面向方面軟體體系模型的研究還相對較少，對它的構成單元模型的研究更少，通常只關注方面構件這一構成單元。方面構件最早是由Lieberherr等人［2］提出的，它是在自適應可插拔構件(adaptive plug and play component，APPC)基礎之上通過引入面向方面編程(AOP)思想擴展一個可更改的介面而形成的，但它關於請求介面和服務介面的定義很模糊，未能給出一個清晰的方面構件模型。Pawlak等人［3］提出了一個面向方面的框架，該框架主要包含了一個方面構件模型———Java方面構件(Java aspect component，JAC)，但該方面構件模型僅包含了切點(pointcut)，並把AOP中裝備(advice)集成到了切點的表達式中，它主要從實現的角度進行了闡述，並沒有給出詳細的方面構件模型。本文沒有隻關注面向方面軟體體系結構中方面構件這一構成單元模型，還詳細分析了它的另外兩個構成單元，即構件和連接件，因為面向方面軟體體系結構各部分之間是相互關聯的。
1面向方面軟體體系結構相關概念
面向方面軟體體系結構涉及諸多概念，以下將分別介紹。軟體體系結構在軟體工程領域有著廣泛的影響，但當前仍未形成一個統一的、標準的定義。目前國內外普遍認可的看法是軟體體系結構包含構件、連接件和約束［4］。其中約束描述了體系結構配置和拓撲的要求，確定了體系結構的構件與連接件的連接關系。這樣就可以把軟體體系結構寫成
軟體體系結構(software architecture)=構件(components)+
連接件(connectors)+約束(constraints)
構件是軟體體系結構的基本元素之一。一般認為，構件是指具有一定功能、可明確辨識的軟體單位，並且具備語義完整、語法正確、有可重用價值的特點，然而目前對於構件的具體結構及構成並沒有一個統一的標准［5］，而且一些主要的構件技術也沒有使用相同的構件類型。另外，當前被廣泛接受的構件定義並不包含具體的軟體構件模型(software component model)。例如，Szyperski等人［6］給出了軟體構件一個很有名的定義:軟體構件是一個僅帶特定契約介面和顯式語境依賴的結構單位，它可以獨立部署，易於第三方整合。但是關於軟體構件模型有一個被普遍接受的觀點是:軟體構件是一個具有服務提供和服務請求功能的軟體單元［7］。
連接件是軟體體系結構另一個基本的構成元素，是用來建立構件間交互以及支配這些交互規則的構造模塊。連接件最先是由Shaw［8］提出來的，她建議把連接件作為軟體體系結構中第一類實體，用來表示普通構件之間的交互關系。目前對於連接件尚未形成統一的認識，盡管在軟體體系結構中強調了連接件存在的必要性，但是關於連接件模型的研究還很少，連接件的實際應用還不成熟。
面向方面軟體體系結構在傳統軟體體系結構的基礎上增加了方面構件單元。通常認為，方面構件是封裝了系統橫切關注點的一類特殊的構件。目前關於方面構件模型的研究還處於起步階段。
2面向方面軟體體系結構模型
由於傳統軟體體系結構模型包含構件、連接件和約束，而面向方面軟體體系結構是在傳統軟體體系結構的基礎之上擴展了方面構件，所以面向方面軟體體系模型結構包含構件、連接件、方面構件和約束。其中約束描述了面向方面體系結構配置和拓撲的要求，確定了體系結構的構件、連接件和方面構件之間的連接關系，而構件、連接件、方面構件是它的三個基本的構成單元。以下對這三個構成單元的模型進行詳細的設計。

F. 軟體工程中三種面向對象模型的主要功能

1、功能模型(即用例模型à作為輸入)

2、對象模型:對用例模型進行分析,把系統分解成互相協作的分析類,通過類圖/對象圖描述對象/對象的屬性/對象間的關系,是系統的靜態模型

3、動態模型:描述系統的動態行為,通過時序圖/協作圖描述對象的交互,以揭示對象間如何協作來完成每個具體的用例,單個對象的狀態變化/動態行為可以通過狀態圖來表達

G. 軟體工程 用來描述系統的是什麼模型

件工程中能「標識系統要解決的的問題」的模型是概念模型 概念模式也稱為模式或邏輯模式，概念模式是資料庫中全體數據的整體邏輯結構和特徵的描述，概念模式通常還包含有訪問控制、保密定義和完整性檢查等方面的內容，以及概念/物理之間的映射。

H. 軟體工程，軟體過程，軟體生命周期模型三者之間的區別和聯系

1. 軟體開發模型(Software Development Model)是指軟體開發全部過程、活動和任務的結構框架。 一個軟體產品或軟體系統也要經歷孕育、誕生、成長、成熟、衰亡等階段，一般稱為軟體生存周期(軟體生命周期)。
   2.軟體開發模型能清晰、直觀地表達軟體開發全過程，明確規定了要完成的主要活動和任務，用來作為軟體項目工作的基礎。所以沒有它是不行的。
   3.CISE工具和環境有利於軟體開發過程的快速進展，提高開發效率。
   4.需求分析是對功能的正確性,完整性和清晰性,以及其它需求給予評價.只有需求審批通過了才可以正式開始開發。可以通過與客戶、業界有經驗人士溝通以及開發團隊共同商討等方式進行分析。
   5.首先要對人力資源進行分析，然後通過這些人力資源對目標、資源、環境等方面需求分析
   6.見問題4答案。
   7.可以通過實際的案例分析或者實踐來更好的理解和領會。
   8.可行性功能、可擴展性、可維護性、性能良好、耗費資源相對較少等。可以用編碼實現性能上的優化，用介面來實現可擴展性等等。
   9.創建一個軟體系統與其它需要耗費人力與財力的工程是一樣的。如果你要造一幢房子，在開始砌第一塊磚之前，你必須事先畫好建築圖與藍圖。在你開始澆鑄水泥之前，你必須讓人評審你的藍圖並獲得通過，在軟體開發中事先做計劃也與此類似。
   10.可行性（合法性）、成本（人員、時間成本和其他資源的耗費成本）
   11.不可能。只能是盡量避免和減少。
   12.在軟體交付使用後，由於開發時測試的不徹底、不完全，必然會有一部分隱藏的錯誤被帶到運行階段來。這些隱藏下來的錯誤在某些特定的使用環境下就會暴露。為了識別和糾正軟體錯誤、改正軟體性能上的缺陷、排除實施中的誤使用，所以要對其維護。

2.