軟體工程功能模塊層次圖

① 層次方框圖與功能模塊圖有什麼區別

1、作用不同

模塊結構圖表現的是上下級模塊之間層次化的調用和控制關系；功能層次圖只展示任務的分解，不涉及數據的流動；

2、矩形框表示不同。

只表示上層任務可同哪些子任務協同完成，不管順序與調用；嚴格按層次畫出，不同任務的相同子任務也分別重畫。

方框代表一個模塊；方框之間的直線表示模塊的調用關系；尾部是空心圓箭頭表示傳遞的是數據；尾部實心圓箭頭表示傳遞的是控制信息。

3、連線不同。

可以說，功能層次圖實際上就是數據流程圖去掉數據處理外的所有其他元素，再按層次集成為一張完整的圖。

個矩形框代表一個模塊方框間的連線表示調用關系而不像層次方框圖那樣表示組成關系。

描述了軟體的模塊結構，表示了一個系統的層次分解關系；反映了模塊間的聯系以及塊內聯系；反映了模塊間的信息傳遞。

(1)軟體工程功能模塊層次圖擴展閱讀

結構圖（SC）：

描述了軟體的模塊結構，表示了一個系統的層次分解關系；反映了模塊間的聯系以及塊內聯系；反映了模塊間的信息傳遞。

1、組成元素：方框，內有名稱，表示模塊；直線，表示上層模塊對下層模塊的調用；尾部帶空心圓的箭頭，表示按方向傳遞的數據信息。尾部帶實心圓的箭頭，表示按方向傳遞的控制信息；

2、注意：層次圖和結構圖並不嚴格表示模塊的調用次序，層次圖和結構圖只表明一個模塊調用那些模塊，至於模塊內還有沒有其他成分則完全沒有表示。

（3）作用：描述模塊間參數交換情況、評價模塊間耦合情況、確定模塊間的介面。結構圖一般不列入設計文檔，只用於設計階段檢查模塊設計的正確性和模塊獨立性。

HIPO圖：

即層次圖＋輸入／處理／輸出圖的英文縮寫，由一張H圖和一組IPO圖組成。

H圖，是給每個模塊加上編號的層次圖。IPO圖，要為H圖中的每個模塊畫一張IPO圖。通常將HIPO圖作為軟體結構的描繪，列入設計文檔。

② 軟體工程中軟體結構圖和層次圖的異同

兩者之間沒有區別。兩者指的均是軟體構架，為軟體系統的草圖。

軟體工程中軟體結構圖和層次圖均是為了反映軟體系統中組件之間相互關系和約束的體系結構設計圖，屬於一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。

軟體結構圖（又被叫做軟體構架）一般通過分層次或分時間段等方式說明體系結構的各個組成部分的組合關系。描述的對象是直接構成系統的抽象組件，各個組件之間的連接則明確和相對細致地描述組件之間的通訊關系。

(2)軟體工程功能模塊層次圖擴展閱讀：

其他介紹：

軟體結構圖包括架構元件、聯結器、任務流。所謂架構元素，也就是組成系統的核心磚瓦，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和聯結器完成某一項需求。

通過一個軟體結構圖建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。在建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。

③ 軟體工程層次化結構分幾層

一計劃時期
1.問題定義(要解決的問題是什麼？)
2.可行性研究（對於問題有解決方法嗎？）
二開發時期
1.需求分析（為了解決問題，目標系統必須做什麼？）
2.概要設計（怎樣實現目標系統？）
3.詳細設計（怎樣具體實現這個系統？）
4.編碼
5.測試
三運行時期
運行時期的主要工作是維護

④ 軟體工程 各個階級段有哪些uml圖

一、UML5個互聯視圖
UML中常用5個互聯的視圖來描述系統的體系結構。如下圖：
（1）用例視圖（Use-case View）
由專門描述可被最終用戶、分析人員、測試人員看到的系統行為的用例圖組成。
最終用戶使用用例圖——理解要完成的系統的功能，確認是否符合自己的要求。
分析人員使用用例圖——描述用戶需求。
測試人員使用用例圖——根據用例圖驗證實現後的系統是否符合用戶需求。
（2）設計視圖（Logical View）
包含了主要的設計包、子系統、類和介面，主要從軟體角度描述系統要解決的問題和解決方案。
（3）進程視圖（Process View）
主要針對系統性能、可擴展行和吞吐量。
（4）實現視圖（Implementation View）
在UML實現視圖用類圖、包圖、對象圖、順序圖、合作圖、狀態圖、和活動圖來描述。編程人員根據設計視圖和進程視圖來最終實現系統。
（5）部署視圖（Deployment View）
包含了系統硬體拓撲結構點各種軟體模塊和構件模塊。
二、UML在軟體開發各個階段的應用
經典的軟體工程思想將軟體開發分成5個階段:需求分析\系統分析與設計;系統實現\測試及維護五個階段。其中UML在各個階段都有不同的應用，除了學習每種圖的具體畫法，還要注意學習UML圖在軟體開發過程中每個階段的應用。
1、需求
採用用例圖描述需求。
2、 分析
採用類圖描述靜態結構
採用順序圖、合作圖、活動圖、狀態圖描 述動態行為
3、設計
採用類圖、包，對類的介面進行設計
4、 實現
將類用某現象對象語言實現
5、繼承與交付
構件圖、包、部署圖
6、 測試
單元測試——類圖和類的說明書

⑤ 模塊層次結構

根據系統總體目標及設計原則，以及系統所具備的項目技術內容，結合二次開發平台的特點，將整個子系統分成5大模塊。即：圖像處理模塊、知識庫模塊、信息提取模塊、模型建立模塊和數據管理模塊。

1.圖像處理模塊

圖像處理模塊實現各種原始遙感圖像數據進行幾何校正和配准、鑲嵌處理、圖像裁切、信息增強、圖像融合等。

（1）圖像處理功能

對原始衛星遙感圖像進行處理，內容包括幾何校正和配准、鑲嵌處理、遙感信息增強等。

1）幾何校正：利用變形的遙感圖像與標准地圖之間的對應點（即控制點數據對），用一種數學模型來近似描述遙感圖像的幾何形變過程，通過幾何控制點求出幾何畸變模型，然後進行圖像的幾何校正。

2）圖像配准：通過確定參考圖像與配准圖像的同名地物點在圖像上行列坐標交點的映射關系得到交點的偏移量值，建立數學模型，得到配准圖像與參考圖像之間象元位置的對應映射關系，從而可以將參考圖像的控制點文件通過得到的映射關系映射到配准圖像中，使得兩期圖像能夠完全配准。

3）鑲嵌處理：對若干景互為鄰接（時相往往可能不同）遙感圖像通過彼此之間的幾何鑲嵌、色調調整、去重疊等數字處理，鑲嵌拼接成一幅統一的新圖像，以便於更好的統一處理、解譯、分析和研究。

4）增強處理：通過增強處理突出圖像中的有用的信息，使圖像中感興趣的區域的特徵得以突出，使圖像清晰，圖像增強的目的主要是提高圖像的可解譯性。

5）數據融合：充分發揮多光譜波段的光譜和全色波段的高空間解析度優勢，以提高遙感信息提取的精度。

6）圖像裁切：將處理過的圖像分別按照地域地貌和地形圖標准分幅的格式輸出，以便用戶能夠方便地得到與標准地形圖相對應的圖像和按照地域分區分析，並為數據的入庫提供方便。

（2）圖像處理模塊層次結構

詳見圖7-4。

2.知識庫模塊

知識庫模塊是通過野外調查驗證典型岩石特徵，在工作區范圍內建立的岩石類型庫、解譯標志庫、岩石光譜庫。知識庫是信息提取的基礎，因此其鑲嵌在信息提取子系統中（圖7-5）。

3.信息提取模塊

（1）信息提取功能

信息提取分人機交互解譯和計算機信息自動提取兩種方法。

人機交互解譯是憑光譜規律、地學規律和解譯者的經驗，從衛星圖像的顏色、紋理、結構、位置等各種特徵和通過野外調查建立的解譯標志庫，解譯出各種信息。

信息自動提取即計算機圖像分類是模式分類在圖像處理中的應用，分類的結果是將圖像根據不同屬性劃分為多個不同類別的子區域，從而完成信息的提取。其包括非監督分類和監督分類。

圖7-8 數據管理模塊層次結構圖

⑥ 軟體系統結構圖和功能模塊圖區別

系統結構圖：反映的是系統中模塊的調用關系和層次關系,誰調用誰,有一個先後次序(時序)關系。圖中的有向線段表示調用時程序的控制從調用模塊移到被調用模塊,並隱含了當調用結束時控制將交回給調用模塊.

功能結構圖就是按照功能的從屬關系畫成的圖表，圖中的每一個框都稱為一個功能模塊。功能模塊可以根據具體情況分的大一點或小一點，分解得最小功能模塊可以是一個程序中的每個處理過程，而較大的功能模塊則可能是完成某一個任務的一組程序。
功能結構圖是對硬體、軟體、解決方案等進行解剖，詳細描述功能列表的結構，構成，剖面的從大到小，從粗到細，從上到下等而描繪或畫出來的結構圖。從概念上講，上層功能包括 (或控制)下層功能，愈上層功能愈籠統，愈下層功能愈具體。功能分解的過程就是一個由抽象到具體、由復雜到簡單的過程。圖中每一個框稱為一個功能模塊。功能模塊可以根據具體情況分得大一點或小一點。分解得最小的功能模塊可以是一個程序中的每個處理過程，而較大的功能模塊則可能是完成某一任務的一組程序。

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

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面向方面軟體體系結構模型
由於傳統軟體體系結構模型包含構件、連接件和約束，而面向方面軟體體系結構是在傳統軟體體系結構的基礎之上擴展了方面構件，所以面向方面軟體體系模型結構包含構件、連接件、方面構件和約束。其中約束描述了面向方面體系結構配置和拓撲的要求，確定了體系結構的構件、連接件和方面構件之間的連接關系，而構件、連接件、方面構件是它的三個基本的構成單元。以下對這三個構成單元的模型進行詳細的設計。

⑧ 《軟體工程導論》一書中，數據流圖和層次圖的聯系是什麼

數據流圖是需求分析階段得到的結果。
層次圖是總體設計階段得到的結果，用於描述軟體結構。
層次圖是對數據流圖進一步分析得來的。