在线观看黄色大片-在线观看黄色x视频-在线观看黄日本高清视频-在线观看黄免费-高清潢色大片-高清黄色直接看

作者：亞尼夫·莫德凱(Yaniv Mordecai)，麻省理工學院

譯者注：

對象過程方法（OPM）將事物抽象描述為對象、狀態和過程，并以此為基礎新建了一種工程語言。如此徹底的抽象，其優點是顯而易見的:不僅能對任何領域（除了亞原子尺度的微觀領域）的任何系統作概念建模，而且語言簡單，使用靈活。

不過，語言的靈活性是柄雙刃劍。靈活性能避免束縛思維和表達，但同時會讓模型過分個性化，信馬由韁構建的模型難以描述復雜系統，不僅建模者自己會迷失方向，也不利于他人閱讀理解和協作，讓模型難以維護。

為了“馴服”靈活性，讓OPM更好地用于復雜系統建模，就必須合理制定并恰當運用建模規范。

在運用OPM對系統建模的實踐探索過程中，我被OPM的靈活性負面影響所困擾。受到軍事科學院楊峰教授的指點，向我介紹Yaniv Mordecai 先生和Dov Dori先生的論文《Model-BasedOperational-Functional Unified Specification for Mission Systems》(https://www.researchgate.net/publication/296196819)，讀后感覺受益匪淺。沈陽飛機設計研究所揚州研究院的全嘉鈺將這篇極具價值的論文翻譯成中文，全嘉鈺和我一起反復討論，最終成稿，在此分享給關注MBSE的讀者。如有需要，可以與我們的團隊聯系，作進一步溝通及合作。

正如論文“討論與總結”所述，關于OPM語言和建模規范，還有值得探討的問題。在研讀這篇論文時，論文的內容也引起了我們的很多思考。例如圖6中“功能”與“機能”之間使用包含關系描述，沒有體現關于涌現的認識。如何用模型描述涌現，還需要探索。圖7中“運行”與“SRS”之間的關系，似乎使用實例鏈接更合適，但是當前的OPM語言并不支持這樣的描述……諸多問題值得大家繼續研究。

要恰當地翻譯涉及方法論和語言的論文是個很大的挑戰。文中有一些抽象語義，要逐字逐句翻譯是做不到的，因為英語和漢語中描述抽象語義的詞匯不能精確的一一對應。在翻譯過程中，不得不在尊重原文的直譯和揣摩內容的意譯之間權衡取舍，同時承擔理解錯誤的風險。上面的網址鏈接可以幫助讀者方便地下載英文原文，這讓我們誤導讀者的顧慮有所釋懷。系統工程某些術語的譯法目前還沒有形成廣泛共識。另外，為了盡量準確地體現本論文的思想，不得不在翻譯中引入一些新的中文術語，僅限于理解本篇論文，歡迎讀者指正。相關術語翻譯如下：

Enveloping System（ES）：包絡系統

Functionality：功能

Function：機能

Interoperability：互操作性

Operational-Function：運行功能

Requirement：需求

Stakeholder：利益相關方

System-Contained Scenario（SCS）：包含系統（指SoI，譯者注）的場景

System-Reliant Scenario（SRS）：系統（指SoI，譯者注）依賴的場景

System-of-Interest（SoI）：所關注系統

Systems of Systems（SoS）：體系

Validation：確認

Verification：驗證

要理解本論文所闡述的內容，有必要對OPM有一定了解，建議閱讀Dov Dori先生的著作《基于模型的系統工程-綜合運用OPM與SysML》（楊峰等譯）。

感謝Yaniv Mordecai 先生和Dov Dori先生的著作，感謝楊峰教授的指導，感謝全嘉鈺的辛勤付出，同時贊賞全嘉鈺的獨立思考！

趙獻民，沈陽飛機設計研究所，zxmldx@126.com

以功能為種子的OPM原理^[21]指出，每個模型重要的基本過程是系統的種子功能。這可能讓人擔心OPM側重于功能性。一旦我們意識到該模型描述的是基于環境的SoI集合而不是SoI本身，則無需擔心這一問題，因為該功能既考慮了系統又考慮了環境，并且考慮了兩者之間的相互影響。

通過其統一的結構、行為、功能建模方法^[21]，OPM已被證明能夠滿足多種領域中復雜系統和流程的統一過程功能架構定義和設計，包括企業互操作性、決策自動化、計算機和通信協議以及彈道導彈防御系統^[22-26]。而且，OPM已用于復雜生物過程的形式化描述^[27、28]和項目產品生命周期管理^[29、30]。

（e）圖形文本雙模表示法，可以在對象過程語言（Object-Process Language：OPL）中自動生成形式化的、連貫的OPD規范，OPL是基于上下文無關的語法，即自然語言^[19、20]的子集。

（d）事物的通用本體（具有狀態的對象，以及轉換狀態的過程）以及事物之間的關系，它證明在量子、亞微粒子級以外任何領域中是描述系統的一組必要和充分的概念集；

（c）通過定義明確的抽象提煉機制，基于本質（而非基于外表）分解，降低復雜性并管理復雜性，對于相互關聯的不同層級OPD，其抽象結構自相似；

（b）唯一一種圖，即對象過程圖（Object-ProcessDiagram：OPD），它捕捉結構、行為和功能方面。與之對比，UML有14種圖，SysML有9種圖；

（a）符號數量最少，只有20個符號。與之對比，UML有120個符號；

隨著現代系統和問題的復雜性不斷增長，絕大多數建模和架構框架的復雜性也隨之不斷增長。復雜系統需要用簡單模型描述，OPM一直在辯論和證明這一點，為此堅持了大約二十年。OPM致力于簡單，這體現在以下幾個關鍵特征上：

C． 對象過程方法（OPM）

基于UML的UPDM（Unified Profile for DoDAF and theUK Ministry of Defense Architecture Framework，美國國防部架構框架DoDAF和英國國防部架構框架MoDAF的統一配置文件）試圖圍繞系統能力和服務展開，并導出專用視圖，這些視圖用于將業務活動映射到能力(STV-6)，以及將服務映射到能力^[17]，以解決DoDAF和MODAF中的挑戰。這種方法允許在系統功能的背景下構建運行場景，從而通過功能來限制更廣泛的運行背景。統一架構框架（Unified Architecture Framework：UAF）旨在調解北約（NATO）成員間的各種框架和開發計劃，以使他們能夠在相互了解能力、功能和接口的基礎上，確保聯盟的互操作性以及聯合行動計劃并執行^[18]。

美國國防部架構框架（DoDAF）包括運行視角（OperationalViewpoint：OV，譯者注：在軍事領域常被翻譯為“作戰視角”）和能力視角（CapabilityViewpoint：CV），OV識別并描述支持任務和活動的運行分析、運行要素和資源交換^[16]。與CV模型相關的OV模型將系統能力映射到所支持的運行活動。它們的主要缺點是各種OV模型數量多且冗余，這些OV模型之間邊界模糊，雖然模型的名稱不同，卻會重復描述同樣的內容，描述往往不一致。

B． 架構框架中的運行視角

SBD是在20世紀90年代中期到2000年代中期由卡洛爾、羅森等人帶頭發展起來的。這種方法被批判的原因在于既無法真正捕獲用戶目標，又無法滿足功能設計的需求，而功能設計最終是用來完善SoI的^[2]。SBD的集成主要用于嵌入式、并行和實時系統建模，主要與狀態圖集成^[12-15]。

基于場景的設計（SBD）^[9、10]是面向應用的非正式軟件設計技術，它專注于用戶體驗和使用場景，需要軟件系統支持。這與面向解決方案設計的功能規范方法不同^[11]。在紙上用二維鉛筆草圖描述用戶交互場景，旨在生動地捕捉交互設計的本質，就像用機械圖紙作物理設計一樣。

A． 基于場景的設計

2. 文獻綜述

本文的其余部分安排如下：第二節是文獻綜述，討論了相關的主題，包括基于場景的設計（Scenario-Based Design：SBD）和OPM；第三部分介紹OFUS即運行功能統一規范；第四部分討論了OFUS在搜索和救援任務系統中的運用；第五部分包括問題討論、研究結論以及未來的研究方向。

OFUS方法是對任務系統進行概念建模研究的成果。任務是一種運行場景，其中所關注系統（System-of-Interest：SoI）扮演著一定的角色。在詳細描述和設計SoI時，很難區分與任務相關的運行和系統功能這兩種行為。為了解決此問題，我們開發了基于OPM的建模模式，該模式可捕獲運行場景和系統功能。我們在具有挑戰性的搜索和救援行動中演示了這種模式。這種情況特別有意義，它首先是任務規劃場景，然后是任務執行場景。這兩種場景均需要系統的任務規劃功能和執行功能支持。

該框架基于對象過程方法（Object-Process Methodology：OPM，符合國際標準ISO-19450），這是一種基于整體模型的系統工程（MBSE）范例^[7]，[8]，用于描述復雜系統和過程。使用OPM可以將建模模式無縫地集成到任何基于OPM的系統模型中，并使其具有OFUS的優點。

在本文中，我們提出了運行功能統一規范（Operational-Functional Unified Specification：OFUS），這是一種基于模型的方法，可以在一個連貫、統一和協同的模型中結合對功能的考慮并描述運行。

對于結合場景和功能的模型需求已得到充分理解^[2]。基于UML或SysML等語言的建模方法為面向業務或客戶的可視化描述提供了單獨的視圖^[3、4]，包括用例圖和活動圖，以及SysML所獨有的需求圖。SysML還為功能規范提出了單獨的視圖，包括塊定義圖、狀態圖和順序圖。這種分解是經過深思熟慮的，并且是UML分解方法的一部分。用例主要用于描述與客戶相關的運行場景，但常常被誤用于描述系統功能，而不是用于描述外部參與者運用這些功能的場景^[5]。另外，用例之間是松散的，非結構化的，與UML的其他模型沒有很好地銜接^[6]。

盡管以功能系統為中心的模型偏向于以解決方案為導向的基本視角，但是面向業務的過程規范（使用如業務過程建模BPM、基于場景的設計SBD或架構框架AF中的運行視角等方法）未映射到實際資產、解決方案和促進這些場景的系統功能，從而缺乏它們的支撐。以功能系統為中心的模型有助于弄清端到端、運行環境、業務依據及理由或問題域的范圍和說明，但是它們幾乎不能用于描述系統架構。

系統模型本質上是以系統為中心的，并因此偏向于系統功能架構視角：它們從系統視角描述系統周圍環境和系統行為方式。系統工程師經常傾向并致力于引入現有系統或子系統，以使他們的利益相關方和利益集團受益。例如，參與開發計劃的公司都圍繞各自擁有的資產（技術、服務、系統組件等）介紹系統，希望依靠這些資產提供功能和價值。最后，傳統的系統工程標準很難結合系統功能設計來表達運行需求^[1]。

區分系統的運行視角和功能視角是系統工程常見問題。基于問題域的運行視角與業務或運行相關，而基于解決方案域的功能視角則與系統和目的相關。區分運行需求、系統功能需求、系統需求規范和系統設計都非常困難，這對系統工程師來說是個挑戰，在新的和正在開展的系統工程和運行程序中，該挑戰反復出現。

1. 引言

基于模型的系統工程（Model-Based Systems Engineering，MBSE），對象過程方法（Object-Process Methodology，OPM），功能分析（Functional Analysis），運行分析（ OperationalAnalysis），基于場景的設計（Scenario Based Design，SBD）

關鍵詞：

OPM包含一組緊湊的圖形元素（即事物和鏈接）集合。事物是過程（橢圓）和對象（矩形），對象具有狀態（圓角矩形）。圖1顯示了過程、對象、狀態，按照物理特征和環境特征對它們的分類，以及狀態與對象的從屬關系。過程和對象可以由較低層次的過程和對象組成。鏈接表示這些元素之間的各種關系。如圖2所示的結構鏈接支持描述系統的靜態特征。圖3所示的過程鏈接描述與過程相關的關系、控制和因果。

                       圖1 OPM事物符號：對象、過程、狀態、物理類事物（陰影）、狀態從屬于對象（輪廓線）

UML和SysML所包含的多種圖分別描述結構、行為、狀態轉換、活動和時間流。與此相比，OPM通過分層細化分解方式應對復雜性。分層組織的OPD是使用幾種精簡抽象機制相互關聯的：

i）展開和折疊事物的結構層次。

ii）放大或縮小事物的內部細節（如圖4）。

iii）顯示和隱藏狀態。

iv）創建新視圖，即通過專門視圖描述關鍵元素及其附加信息。

每個事物都要在某些OPD中至少被定義一次，以使其在整體模型中都是正確的。所定義的事物可以出現在指定模型OPD集任意一個OPD中。每一個事物都可以在任意OPD中被復制，即使沒在某些OPD中出現，它也適用于所有OPD。

可以使用免費軟件OPCAT V4.01 ^[31]構建OPM模型。OPCAT提供了一個圖形用戶界面（GUI），供分析人員創建、管理和共享他們的模型。它支持大多數OPM概念，并根據OPM語法和規則立即驗證模型。OPCAT還可根據圖形模型OPD自動生成OPL語句，并提供整個模型的OPL文本規范，或提供針對特定OPD的OPL文本。OPCAT提供了一個內置的定性仿真引擎，該引擎支持模型驗證、確認和測試，在對復雜系統建模過程中，可視化交互特別有用。OPCAT軟件的GUI屏幕截圖如圖5所示。

圖4 在OPM中放大對象和過程

圖5 OPCAT V4.0屏幕截圖

（譯者注：楊峰教授團隊在OPCAT軟件基礎上開發了全中文軟件GreatArch，GreatArch能將OPL文本以全中文形式呈現，并優化了OPCAT軟件的某些功能）

OPM符號的輪廓顏色和填充顏色與模型語義無關。OPCAT軟件對OPD符號輪廓和OPL文本默認定義的顏色是：對象為綠色，過程為藍色，狀態為卡其色。這些顏色可以更改，并非形式化語義。顏色用于提高可視化模型的可讀性。OPCAT還將放大后的事物輪廓涂成加粗的灰色，并將折疊后的事物涂成加粗的紅色。OPCAT允許建模者更改對象和過程的輪廓顏色和填充顏色，以提高視覺可讀性，或利用顏色自定義語義類別。例如，我們可以將灰色填充默認為“當前狀態”，而將另一種顏色（例如白色）默認為“未來狀態”。

3. OFUS：運行功能統一規范

在本節中，我們一方面指定OFUS（即：一種建模模式，可以同時考慮到運行和業務）相關的場景，另一方面描述系統功能。我們首先對運行過程和功能過程之間的關系提出幾點看法。我們定義了基線（僅僅是建模樣板），其中的系統功能就是場景。然后，我們擴展此樣板，使其成為可運行的功能，即它同時描述了運行場景和系統行為。

A． 指導性模型樣板

我們首先在圖6中定義一個指導性的OPM模型和相應的指導性建模樣板。該指導性建模樣板是基礎，即區分功能-場景的起點。我們定義的系統由多個子系統組成。系統具有一些高層級功能。功能是機能的集合，集合中的機能共同提供某些系統能力。機能可以是多個功能的成員。例如，管理機能可以被視為管理功能的成員，而與某個能力相關的每個管理機能都可以被視為該能力的組成部分。

圖6 指導性模型OPM圖：OPD（上部分）和OPL（下部分）

功能是抽象的，是涌現出來的。而機能作為功能的構成要素，是由子系統實際運行的。指導性模型按其自身形式捕獲系統的運行方式和系統功能。

B． 功能與場景區分

現在，我們擴展了建模模式，以在“功能”旁邊添加“場景”概念。場景是與系統相關活動的可能序列。對于每個所關注系統（SoI），都有一個更高層級的包絡系統（Enveloping System：ES即SoI及其環境），它完全包含構成場景的所有過程（活動）和涉及的對象。因此，場景始終是某些ES的種子功能。同一功能可以通過所含機能的不同子集支持多種場景。

從場景中區分功能很重要。盡管這兩個過程集合看起來很相似，有時可以互換，并且可以在所有情況下定義為UML用例，但它們在建模、架構定義和設計定義中的目的不同。功能是機能的概念性容器，可為SoI受益人提供協同價值。因此，功能通過展開進行優化：詳細說明其組成組件和屬性。場景通過有序執行活動來創造價值。這樣，場景通過縮放進行完善描述：過程{/對象}的執行{/部署}，內部時間{/空間}順序的詳細說明。在不同情況下，不同場景可能依賴同一功能。一個常見的例子是驗證用戶身份，它是用戶管理功能的一部分，也是幾個運行場景（如銀行服務系統中的電匯或貸款請求）的一部分。

我們區分包含SoI的場景（System-ContainedScenario：SCS）和SoI依賴的場景（System-Reliant Scenario：SRS）。SCS是僅包含SoI功能的程序或過程，SoI或其某個子系統可以執行此過程。系統的每個功能都是一個SCS，但并非每個SCS都是一個功能。SRS涉及至少一項與SoI功能（或其結果）有關的活動，以及至少一項與SoI功能無關的活動。因此，任何SRS（較高層級的場景）都是ES（包含SoI并比SoI層級更高）的SCS（較低層級的場景）。通常情況下，隱含地假設系統所涉及的場景就是系統的功能，即它是SCS而不是SRS。

OFUS模式如圖7所示。包絡系統（ES）由系統和環境組成。ES展示了運行過程，該運行過程由一個或多個系統相關場景組成，他們包括系統活動和外部活動。系統活動調用構成系統功能的子系統機能。如前所述，環境事物的淺青色可提高圖表的可讀性，但沒有形式化語義。

圖7 功能場景OPM圖

與涉及功能系統方面的功能不同，場景與行為有關：場景是一組旨在實現某些目標的機能。一個場景可以包含多個系統和用戶。場景與功能的不同之處在于場景可以用一個模型對兩個系統（功能和過程）同時進行建模。這樣，我們可以將涌現系統特征或行為作為其功能（機能的特定組合）進行建模，這些功能對某些受益人的價值大于每個單獨子系統提供的功能價值之和。功能與場景區分允許在一個統一模型中對系統功能分解，并對提供附加價值的程序進行建模。

可以說，這種方法擴展了嚴格功能和嚴格程序的方法。初步的建模和設計可以通過以下方式利用此方法：定義功能和機能，而不將其執行過程分配給特定的子系統或組件，并基于機能定義場景，而不必將它們統稱為功能。這樣就可以建立一個早期統一需求的OPM模型，該模型主要基于過程需求，這些需求主要是可運行的、用戶定義的和面向問題的，其次是功能性需求，其中大多數是面向解決方案的。因此，OFUS模式對于早期的系統定義和概念化有用，還對高層級和詳細的功能規范和設計非常有用，這是對開發項目影響最大的系統工程階段。

4. OFUS在搜救任務系統中的應用

在本節中，我們將描述OFUS在任務系統中的一般應用。任務系統是在執行任務時被分派執行的活動，或支持組織、團隊或其他系統的一組旨在實現明確目標的特殊活動。任務系統是體系（Systems of Systems：SoS）。任務體系至少包含兩個過程：規劃任務和執行任務。可以設想兩個獨立的體系功能（可以由獨立系統或集成系統實現），即：（i）任務規劃功能和（ii）任務功能。這種通用任務OFUS模式如圖8所示。

圖8 通用任務的OFUS圖：包括一個任務規劃場景和兩個任務場景：已規劃和未規劃

例如，考慮失蹤登山者的搜尋與救援（Search and Rescue：S＆R）任務。第一階段是S＆R規劃。第二階段是S＆R行動本身，這可能包括搜索、營救或兩者兼而有之，這取決于登山者的最后已知位置。一旦確定了登山者的位置，便會決定是進行救援行動還是讓登山者繼續登山。S＆R可以是通過飛機、車輛、步行或它們的某種手段的組合，并且通常受搜索區域天氣和其他條件的影響。這些參數的每種組合都是潛在的場景或子場景。在某些情況下，我們可以將多個選項組合到一個場景中。

S＆R場景依賴S＆R系統功能的不同子集：

（i） S＆R規劃（繪制地圖，路線規劃，部署規劃）。

（ii） 指揮與控制（監視，通信，記錄，決策）。

（iii）搜索（成像、無線電掃描）。

（iv）救援（飛機，徒步，醫療）

（v） 管理（團隊管理，設備管理）。這些場景還可能依賴外部功能，例如衛星通信、視覺搜索和氣象信息支持。

圖9說明了這三種情況、五種系統功能及其非確定性關系。我們注意到此概念模型中的幾個要素。首先，S＆RES場景（不是系統功能）的目標是拯救登山者。這些功能在某種意義上是具有激勵-響應性的，因為它們是在運行相關場景時被調用和激活的。其次，根據網絡信息與物理現實差異建模模式，場景執行配置是由登山團隊的已知位置而不是其物理現實位置確定的^[25、32]。第三，某些功能是通用的，且適用于多個場景，但另外一些功能則適用于特定場景。

圖９基于OFUS的搜索&救援（S&R）任務模型：S&R規劃場景和兩個任務場景：搜索和救援

為了演示在一個場景中如何利用幾種功能，在圖10中，我們放大了“搜索場景”。這種情況顯然依賴“搜索功能”，包括“成像功能”和“無線電掃描功能”，以及常見的“管理和命令與控制功能”。“搜索場景”沿著一組搜索路段（即相當于一條搜索路徑）展開，相當于在搜索時分段重復實施“搜索”過程。如果在搜索過程中找到了登山者，或者已完全覆蓋了搜索路線，則將觸發新的“S＆R規劃”周期。如果找到了登山者，并且需要救援，那么就會轉入“觸發救援”場景。搜索場景還依賴外部功能，例如“視覺搜索”和“衛星通信”。

圖10基于OFUS的S&R任務模型：搜索場景利用搜索、管理、和指揮&控制功能

由OPCAT自動生成形式化OPL文本規范的子集，附加到基于OFUS的S＆R圖上。OPL語句的子集側重于系統功能結構、搜索場景活動的概述，最重要的是，場景活動的功能利用率以及場景執行、重復執行和完成的條件。結構和狀態設置規范被省略了。由于本文研究范圍有限，我們無法提供S＆R系統的完整規范或完整模型。

5. 討論與總結

我們已經提出并討論了以統一方式捕獲和分析運行場景以及系統功能的挑戰。我們提出了一個概念、框架和建模模式，它們為解決此問題奠定了基礎。常用的分解方法（將運行和功能方面分別劃分為兩個或多個視圖）是有問題的，因為它們之間會產生矛盾、不一致及概念設計不匹配。我們的方法（即運行功能統一規范，OFUS）將這兩個方面統一起來，抓住了它們的密切關系并相互利用。OFUS的功能在于它能夠順利地從問題域過渡到解決方案域，以及將運行概念到架構功能設計作詳盡闡述。

OFUS利用對象過程方法OPM。OPM的縮放機制可用于指定子過程同步性和探索運行場景。OPM的展開機制可用于指定異步過程或過程集群，描述系統功能，組成功能及其對子系統的分配。OFUS鼓勵使用包絡系統（ES）的概念，即所關注系統及其環境的集合。這種方法在廣泛的背景下促進了系統整體分析。

我們已經在搜索和救援案例等任務系統上演示了OFUS。本案例是真實應用程序的簡化版本，由于本文的范圍，無法完全闡述。我們還在彈道導彈防御系統的演化設計中證明了這一概念的價值^[23]，這啟發了將概念擴展到建模和設計框架的層次。

進一步的研究旨在將OFUS正式化為一個框架，并建議與其他方法進行比較分析，同時研究一種建設性方法，該方法依靠OFUS來檢測潛在的運行功能差異，并提出修正式建模和設計步驟以減少這些差異。我們還打算改善圖形和語義表示方式，并減少可視化負擔，并提高關鍵OFUS的OPM概念清晰度和表達能力，例如定義調用鏈接和其他專用語法和語義元素。

致謝

本研究得到以色列理工學院戈登系統工程中心的資助，撥款項目號2021752和2014927。

我們感謝匿名評論員對論文改進和未來研究的有用反饋和建議。

參考文獻

[1] A. P. Sage and S. M. Biemer, “Processes for SystemFamily Architecting, Design, and Integration,” IEEE Syst. J., vol. 1, no. 1,pp.5–16, 2007.

[2] H. Kaindl, “A design process based on a modelcombining scenarios with goals and functions,” IEEE Trans. Syst. Man Cybern.Part A Syst. Humans, vol. 30, no. 5, pp. 537–551, 2000.

[3] G. Booch, J. Rumbaugh, and I. Jacobson, TheUnified Modeling Language User Guide, vol. 3. 1998.

[4] F. Demoly, D. Monticolo, B. Eynard, L. Rivest, andS. Gomes, “Multiple viewpoint modelling framework enabling integratedproduct–process design,” Int. J. Interact. Des. Manuf., vol. 4, no. 4, pp.269–280, Oct. 2010.

[5] R. Heldal, “Use cases are more than SystemOperations,” in 2^nd International Workshop on Use Case Modelling,WUsCaM-2005, 2005.

[6] H. Gomaa and E. Olimpiew, “The role of use casesin requirements and analysis modeling,” in 2nd Int.Workshop on Use CaseModeling (WUsCaM-05): Use Cases in Model-Driven Software Engineering, 2005.

[7] D. Dori, Object-Process Methodology: A HolisticSystems Approach. Berlin, Heidelberg, New York: Springer, 2002.

[8] ISO/TC 184, ISO/PAS 19450:2015 Automation systemsand integration — Object-Process Methodology, no. 1. ISO,2015.

[9] J. M. Carroll, “Scenario-Based Design,” in Hanbookof Human Computer Interaction, M. G. Helander, T. K. Landauer, and P. V. Prabhu,Eds. Elsevier, 1997, pp. 383–406.

[10] M. B. Rosson and J. M. Carroll, “Scenario-baseddesign,” Human Computer Interact. Dev. Process, p. 145, 2009.

[11] J. Carroll, “Five reasons for scenario-baseddesign,” Interact. Comput., 2000.

[12] H. Ben-Abdallah and S. Leue, “MESA: Support forScenario-Based Design of Concurrent Systems,” Lect. notes Comput. Sci., vol.1384, no. 1384, pp. 118–135, 2008.

[13] F. Bordeleau and B. Selic, “A Scenario-BasedApproach to Hierarchical State Machine Design,” in Third IEEE InternationalSymposium on Object-Oriented Real-Time Distributed Computing (ISORC), 2000,pp.78 – 85.

[14] S. V. Gheorghita, F. Vandeputte, K. De Bosschere,M. Palkovic, J. Hamers, A. Vandecappelle, S. Mamagkakis, T. Basten, L.Eeckhout, H. Corporaal, and F. Catthoor, “System-scenario-based design ofdynamic embedded systems,” ACM Trans. Des. Autom. Electron. Syst., vol. 14,no.1, pp. 1–45, 2009.

[15] D. Harel, H. Kugler, and A. Pnueli, “Synthesisrevisited: Generating statechart models from scenario-based requirements,” inFormal Methods in Software and Systems Modeling, vol. Lecture No, no. 287, 2005,pp. 309–324.

[16] DoD, “DoD Architecture Framework Version 2.02,”2009.

[17] M. Hause, “The Unified Profile for DoDAF/MODAF(UPDM) enabling systems of systems on many levels,” in 2010 IEEE InternationalSystems Conference, 2010, pp. 426–431.

[18] M. Hause, “Rebuilding the Tower of Babel The Casefor a Unified Architecture Framework,” in INCOSE Internaional Symposium 2013, 2013.

[19] D. Dori, “Analysis and Representation of ComputerVision Systems By the Object-Process Methodology,” IAPR Work. Mach. Vis. Appl.,1994.

[20] D. Dori, Model-Based Systems Engineering with OPMand SysML. New York: Springer, 2016.

[21] D. Dori, “Object-Process Methodology forStructure-Behavior Codesign,” in Handbook of Conceptual Modeling, D. W. Embleyand B. Thalheim, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, pp.209–258.

[22] Y. Mordecai and D. Dori, “Conceptual Modeling ofSystem-Based Decision-Making,” in INCOSE Internaional Symposium, 2014.

[23] Y. Mordecai and D. Dori, “Agile Modeling of anEvolving Ballistic Missile Defense System with Object-Process Methodology,” in9^th IEEE Systems Conference, 2015.

[24] Y. Mordecai and D. Dori, “I5?: A Model-Based Framework for ArchitectingSystem-of-Systems Interoperability, Interconnectivity, Interfacing,Integration, and Interaction,” in INCOSE International Symposium, 2013.

[25] Y. Mordecai, O. Orhof, and D. Dori, “ModelingSoftware Agent Awareness of Physical-Informatical Essence Duality,” in IEEE InternationalConference of Software Science, Technology, and Engineering - SwSTE 2014, 2014.

[26] Y. Mordecai and D. Dori, “Model-Based ProtocolEngineering: Specifying Kerberos with Object-Process Methodology,” in IEEE28-th Convention of Electrical and Electronics Engineers in Israel, 2014.

[27] J. Somekh, M. Choder, and D. Dori, “ConceptualModel-based Systems Biology: mapping knowledge and discovering gaps in the mRNAtranscription cycle.,” PLoS One, vol. 7, no. 12, p. e51430, Dec. 2012.

[28] J. Somekh, G. Haimovich, A. Guterman, D. Dori,and M. Choder, “Conceptual Modeling of mRNA Decay ProvokesNew Hypotheses,” PLoS One, vol. 9, no. 9, p. e107085, 2014.

[29] A. Sharon, O. L. De-Weck, and D. Dori, “ImprovingProject-Product Lifecycle Management with Model-Based Design Structure Matrix?: A Joint Project Management and SystemsEngineering Approach,” Syst. Eng., vol. 16, no. 4, pp. 413–426, 2013.

[30] A. Sharon and D. Dori, “A Project–ProductModel–Based Approach to Planning Work Breakdown Structures of Complex SystemProjects,” Systems, pp. 1–11, 2014.

[31] D. Dori, C. Linchevski, and R. Manor, “OPCAT – AnObject-Process CASE Tool for OPM-Based Conceptual Modelling,” in 1stInternational Conference on Modelling and Management of Engineering Processes, 2010,pp. 1–30.

[32] Y. Mordecai, C. Chapman, and D. Dori, “ConceptualModeling Semantics for the Physical-Informatical Essence Duality Problem,” in IEEEInternational Conference on Systems, Man, and Cybernetics - SMC2013, 2013.