久久摸摸碰碰97网站,伊人伊成久久人综合网,国产精品99久久

1.目的

邏輯架構模型開發的目的是定義、選擇、和集成系統的邏輯架構模型提供了一個框架,來驗證一個對未來的系統將滿足所有操作場景的系統需求,在權衡系統需求可以探索開發這樣的系統。

流程的通用輸入包括系統需求、架構師識別并用于回答需求的通用架構模式、系統分析過程的結果，以及來自系統驗證和確認過程的反饋。根據所選擇的生命周期模型，這些輸入和輸出以及它們之間的關系將在整個過程中演進和變更(請參閱應用生命周期過程)。

流程的一般輸出要么是單個邏輯架構模型，要么是一組候選邏輯架構模型，以及所選的獨立邏輯架構模型及其選擇的基本原理。它們至少包括視圖和模型。這些包括功能、行為和時間視圖，邏輯架構模型要素和系統需求之間的可跟蹤矩陣。

2.過程的活動

在此過程中執行的主要活動和任務包括:

識別和分析功能和行為要素:

通過分析功能、接口和操作需求，從系統需求中識別功能、輸入-輸出流、操作模式、模式轉換和操作場景。

為每個功能和輸出定義必要的輸入和控制(能量、材料和數據流)，從而推論出使用、轉換、移動和生成輸入-輸出流所需的功能。

將系統需求分配到功能和行為要素:

通過對性能、有效性和約束需求的分配，正式地描述功能表達式及其屬性。特別是，研究時間方面的需求，以分配持續時間，響應時間，和頻率的功能。

通過接口、有效性、操作性、時間和約束需求的分配，正式地描述輸入、輸出和控制流表達式及其屬性。

在系統需求和這些功能和行為要素之間建立可追溯性。

為每個候選項定義候選邏輯架構模型:

根據系統需求(如果有的話)分析操作模式，并/或使用先前定義的要素來建模操作模式的序列和模式的轉換。最終將模式分解為子模式，然后為每個操作模式建立一個或多個功能識別和/或使用相關的通用行為模式的場景。

集成這些功能場景，以獲得系統的行為架構模型(動態行為的完整描述)。

根據需要分解前面定義的邏輯要素，以查看實現。

為之前定義的邏輯要素分配和合并時間約束，如時間周期、持續時間、頻率、響應時間、超時、停止條件等。

為與決策級別相對應的功能定義多個級別的執行頻率，以便監控系統操作，在這個時間基礎上對處理進行優先級排序，并在這些執行頻率級別之間共享功能，以獲得一個當前架構模型。

執行功能失效模式和效果分析，并根據需要更新邏輯架構要素。

使用模擬器執行模型(如果可能的話)，并調整這些模型以獲得預期的特性。

集成選擇的獨立邏輯架構模型:

通過根據評估標準(與系統需求相關)評估候選邏輯架構模型并對它們進行比較，選擇邏輯架構，使用系統分析過程來執行評估和選擇的決策管理過程(參見系統分析和決策管理主題)。這種選定的邏輯架構模型稱為獨立邏輯架構模型，因為它盡可能地獨立于實現決策。

識別和定義為設計的必要性而創建的與派生的系統需求相對應的派生的邏輯架構模型要素。將這些需求分配給適當的系統(當前研究的系統或外部系統)。

驗證并驗證所選擇的邏輯架構模型(盡可能使用可執行的模型)，根據需要進行修正，并建立系統需求和邏輯架構模型要素之間的可追溯性。

反饋邏輯架構模型開發和系統需求。此活動在物理架構模型開發過程之后執行:

如果可能的話，將分配的邏輯架構建模到系統和系統要素，并根據需要添加任何功能、行為和時間要素來同步功能和處理。

定義或合并由所選邏輯和物理架構模型產生的派生邏輯和物理要素。定義相應的派生需求，并將它們分配到適當的邏輯和物理架構要素。將這些派生的需求合并到受影響系統的需求基線中。

3.工件、方法和建模技術

邏輯架構描述使用分組在下列模型類型下的建模技術。已經開發了幾種方法來支持這些類型的模型(有些是可執行模型):

功能模型——包括結構化分析設計技術(SADT/IDEF0)、系統分析與實時(SA-RT)、增強功能流框圖(eFFBD)和功能分析系統技術(FAST)等模型。

語義模型——包括實體關系圖、類圖和數據流圖等模型。

動態模型——包括狀態轉換圖、狀態圖、eFFBDs、狀態機等模型

圖(SysML)、活動圖(SysML) (OMG 2010)和petri網。

根據領域的類型(如防御、企業)，架構框架提供了可以幫助表示架構的其他方面/視圖的描述——參見企業系統工程關鍵概念中的“企業架構框架和方法論”一節。參見使用與ISO/IEC/IEEE 42010 (ISO 2011)相關的通用模板的實用方法。

4.實際考慮

如上所述，邏輯架構模型的目的是提供系統必須能夠做什么來滿足所述需求的描述。這將有助于確保所有利益攸關方的需求和/或關注點都能通過任何解決方案得到解決，并且能夠考慮創新的解決方案，以及基于當前解決方案技術的解決方案。在實踐中，問題利益攸關方推動他們自己的議程，解決方案架構師或設計師提供他們熟悉的解決方案，這是人的本性。如果邏輯架構模型在選擇的生命周期中沒有得到適當的執行，那么問題和解決方案利益攸關方很容易忽略它，并恢復到他們自己的偏見(參見第5部分:啟用系統工程)。如果邏輯架構模型成為其自身權利的終點，或者與主要生命周期活動斷開連接，這種情況就會加劇。這可以通過使用抽象語言或符號、細節級別、花費的時間或過于復雜的最終架構來實現，而最終架構與創建它的目的并不匹配。如果架構的語言、范圍和及時性與問題利益攸關方或解決方案提供者不匹配，他們就很容易忽略它。下面兩部分將描述有助于避免與邏輯架構模型相關的問題的關鍵缺陷和良好實踐。

4.1陷阱

表1提供了在開發邏輯架構時遇到的一些關鍵缺陷。

表1。邏輯架構開發的缺陷。

陷阱	描述
問題的相關性	邏輯架構模型應該與任務分析產生的操作場景相關聯。
架構模型的輸入	包括一組系統需求和實例，在這些需求和實例中，它們沒有解決正確的架構級別。其結果是，架構師允許將需求放在一邊，并使用他或她通過輸入理解的內容來發明解決方案。
分解太深	許多架構初學者經常犯的一個錯誤是:將功能分解得太深，或者在場景中或當前的功能架構模型中有太多的功能和輸入/輸出流系統的塊。
沒有將輸入和輸出與功能一起考慮	一個常見的錯誤是只考慮功能支持的操作并分解它們，而忘記了輸入和輸出，或者考慮它們太晚了。輸入和輸出是一個功能不可分割的部分。
只考慮功能的靜態分解	靜態功能分解是最小的功能架構模型任務，并回答了基本問題，“這是如何完成的?”靜態分解的目的是為了方便對功能列表的管理或導航。只有在場景已經創建并且邏輯架構接近完成時，才應該建立靜態分解。
混合治理、管理和操作	治理(策略監控)、管理(戰術監控)和基本操作通常混合在復雜系統中。邏輯架構模型應該處理行為架構模型和當前架構模型。

4.2實踐證明

表2提供了從參考資料中收集的一些經過驗證的實踐。

表2。經過驗證的邏輯架構開發實踐。

實踐	描述
構成功能場景	在構成功能分解樹之前，必須對系統的行為建模，建立功能場景，并將功能分解為子功能場景。
分析與合成循環	當面對一個包含大量功能的系統時，應該嘗試在標準的幫助下將功能集成為更高的功能抽象級別。不要只進行分析;相反，進行小的分析(分解)和合成周期。使用場景的技術包括這種設計實踐。
交替的功能和行為視圖	功能(動作動詞;如。“移動”)及其執行狀態/操作模式(例如:“移動”)是兩個相似和稱贊的觀點。利用這一點來考慮系統的行為視圖，該視圖允許從一種操作模式轉換到另一種操作模式。
創建一個場景的順序功能	在創建功能場景時，首先建立功能的(控制)流，然后添加輸入和輸出流，最后添加用于同步的觸發器或信號，這樣效率更高。