User Tools

Site Tools


start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
start [2019/11/12 09:45]
admin
start [2020/01/18 04:17]
admin
Line 13: Line 13:
  
 UAF extends the scope of UPDM and generalizes it to make it applicable to industry, federal, and military architectures. The core concepts in the UAF are based on: UAF extends the scope of UPDM and generalizes it to make it applicable to industry, federal, and military architectures. The core concepts in the UAF are based on:
-* DoDAF 2.0.2 Domain Metamodel (DM2) +  * DoDAF 2.0.2 Domain Metamodel (DM2) 
-* MODAF ontological data exchange mechanism (MODEM) +  * MODAF ontological data exchange mechanism (MODEM) 
-* Security Views from Canada's Department of National Defense Architecture Framework (DNDAF) +  * Security Views from Canada's Department of National Defense Architecture Framework (DNDAF) 
-* North Atlantic Treaty Organization (NATO) Architecture Framework (NAF) v4+  * North Atlantic Treaty Organization (NATO) Architecture Framework (NAF) v4
 DoDAF, MODEM, and NAF v4 are all based on the International Defence Enterprise Architecture Specification (IDEAS) ontology. The IDEAS-based format for the domain meta-model (DMM) allows for the implementation of UAF DMM in non-SysML based tools. DoDAF, MODEM, and NAF v4 are all based on the International Defence Enterprise Architecture Specification (IDEAS) ontology. The IDEAS-based format for the domain meta-model (DMM) allows for the implementation of UAF DMM in non-SysML based tools.
  
Line 24: Line 24:
  
 The UAF Specification consists of four parts: The UAF Specification consists of four parts:
-- UAF DMM: basis for all tool vendors +  - UAF Domain Metamodel (DMM): basis for all tool vendors 
-- UAF Profile (UAFP): implementation of UAF in SysML  +  - UAF Profile (UAFP): implementation of UAF in SysML  
-- Traceability to other architecture frameworks  +  - Traceability to other architecture frameworks  
-- Search and Rescue (SAR) Example implementation of UAF+  - Search and Rescue (SAR) Example implementation of UAF
 The UAF DMM and Profile are both normative components of the specification, while the traceability and example components are non-normative. UAF can be implemented directly using the UAF DMM, or by using UAFP (for tool vendors that support SysML/UML), or by some other proprietary implementation. The UAF DMM and Profile are both normative components of the specification, while the traceability and example components are non-normative. UAF can be implemented directly using the UAF DMM, or by using UAFP (for tool vendors that support SysML/UML), or by some other proprietary implementation.
 Building from one of these implementations, we can create either NAF v4, UAF, or DoDAF 2.0 views. Building from one of these implementations, we can create either NAF v4, UAF, or DoDAF 2.0 views.
  
-===== UAF Views =====+===== UAF Grid: Information vs. Presentation =====
  
 The UAF grid shows how UAF is organized into different view specifications. The UAF grid shows how UAF is organized into different view specifications.
Line 37: Line 37:
 {{:uaf_grid.png|}} {{:uaf_grid.png|}}
  
-Each row in this grid represents a different domain, and each column represents a different “model kind”. The “domains” can be thought of as the different parts of the underlying information model, while the “model kinds” can be thought of as different standard ways of representing that information. Each cell in the grid is a different view specification or “viewpoint”. UAF defines a metamodel for each viewpoint- the main concepts and relationships you need to build this specific viewpoint. Although the grid is a flat view, think of the information behind each viewpoint in the grid as interrelated.+Each row in this grid represents a different domain, and each column represents a different “model kind”. The “domains” can be thought of as the different parts of the underlying information model, while the “model kinds” can be thought of as different standard ways of representing that information. Each cell in the grid is a different view specification or “viewpoint”. UAF defines a metamodel for each viewpoint- the main concepts and relationships you need to build this specific viewpoint. Although the grid is a flat view, think of the information behind each viewpoint in the grid as interrelated. However, this grid view doesn’t really illustrate how the information is interrelated. 
 + 
 +==== Information ==== 
 + 
 +A better representation of how the information of each domain is interrelated can be seen below. 
 + 
 +{{:uaf_info_grid.png|}} 
 + 
 +In this diagram, the horizontal boxes are stacked to represent how the domain on top ties to the domain below it. For example, the Strategic view is tied to the Operational view, which is tied to the Resources view, etc. The vertical boxes indicate that that domain spans across all the domains horizontally stacked within the vertical box’s height. For example, the Security view spans across the Operational view and the Personnel and Resources views because the Operational views help define the problem in the Security domain, whereas the Personnel and Resources views help define the solution for that domain. 
 +However, this diagram is a very high-level representation. If you would like to see more detail on which elements tie each of the domains together, a simplified version of the UAF information model can be seen below. 
 + 
 +{{::uaf_info_model.jpg|}} 
 + 
 +The “Behavior” column shows a thread between Capabilities (Strategic domain), the Operational Activities (Operational domain) which break down these Capabilities into logical domains, and the Functions (Resource domain) which maps these Operational Activities onto how they might be realized in the physical domain. The “Agent” column shows who exhibits the Capabilities or performs those behaviors.  
 + 
 +==== Presentation ==== 
 + 
 +The UAF model kinds can be mapped to some SysML diagrams, as seen in the table below. 
 +^ Model Kind^ SysML Diagram^ 
 +| Taxonomy (Tx) | Block Definition Diagram (bdd) |  
 +| Structure (Sr) | Block Definition Diagram (bdd) & Internal Block Diagram (ibd) |  
 +| Connectivity (Cn) | Internal Block Diagram (ibd) | 
 +| Processes (Pr) | Activity Diagram (act) | 
 +| States (St) | State Machine Diagram (stm) | 
 +| Interaction Scenarios (Is) | Sequence Diagram (sd) | 
 +| Information (If) | Block Definition Diagram (bdd) | 
 +| Parameters (Pm) | Block Definition Diagram (bdd) | 
 +| Constrains (Ct) | Block Definition Diagram (bdd) & Parametric Diagram (par) | 
 +| Summary & Overview (Sm-Ov) | Block Definition Diagram (bdd) | 
 +| Requirements (Req) | Requirement Diagram (req) | 
 +The Taxonomy (Tx), Connectivity (Cn), and Parameters (Pm) model kinds can also be thought of as tables. The rest of the model kinds do not have analogous SysML diagrams- however, the Roadmap (Rm) model kind can be thought of as a Gantt chart, the Traceability (Tr) model kind can be thought of as a matrix, and the Dictionary (Dc) model kind can be thought of as a table. 
 + 
 +===== UAF Domains and Model Kinds ===== 
 + 
 +This section will give a brief summary of each of the domains and model kinds shown in the [[start#uaf_gridinformation_vs_presentation|UAF Grid]]. 
  
 ====== Upcoming Events ====== ====== Upcoming Events ======
  
 ^Event Name^Event Date^ Event Location^ ^Event Name^Event Date^ Event Location^
 +| [[https://www.omg.org/events/va-20/special-events/UAF-Summit.htm|ACTIONABLE ARCHITECTURE IN THE 21ST CENTURY]] | Mar 26, 2020 | Reston, VA USA |
 +| [[https://www.omg.org/events/va-20/index.htm|OMG Technical Meeting]] | Mar 23-27, 2020 | Reston, VA USA |
 | [[https://www.omg.org/events/ca-19/index.htm|OMG Technical Meeting]] | Dec 9-13, 2019 | Long Beach, CA USA | | [[https://www.omg.org/events/ca-19/index.htm|OMG Technical Meeting]] | Dec 9-13, 2019 | Long Beach, CA USA |
 | [[https://www.incose.org/iw2020/home|INCOSE International Workshop 2020]] | Jan 25-28, 2020 | Torrance, CA USA | | [[https://www.incose.org/iw2020/home|INCOSE International Workshop 2020]] | Jan 25-28, 2020 | Torrance, CA USA |
Line 63: Line 100:
   - MBSE-inspired Actionable Enterprise Architectures Summit, 2018, Ottawa, Canada https://www.omg.org/events/ottawa-18/special-events/MBSE-EA-Summit.htm   - MBSE-inspired Actionable Enterprise Architectures Summit, 2018, Ottawa, Canada https://www.omg.org/events/ottawa-18/special-events/MBSE-EA-Summit.htm
   - MBSE-inspired Actionable Enterprise Architectures Tutorials, 2018, Ottawa, Canada https://www.omg.org/events/ottawa-18/special-events/MBSE-EA-Tutorials.htm   - MBSE-inspired Actionable Enterprise Architectures Tutorials, 2018, Ottawa, Canada https://www.omg.org/events/ottawa-18/special-events/MBSE-EA-Tutorials.htm
 +  - MBSE-inspired Actionable Enterprise Architectures Summit, 2019, Reston, US https://www.omg.org/events/va-19/special-events/MBSE-EA-Summit.htm
 +  - UAF in the context of the NATO Architecture Framework (NAF), 2019, Amsterdam, Netherlands https://www.omg.org/events/amsterdam-19/special-events/UAF-NATO.htm
start.txt · Last modified: 2022/02/10 08:41 by admin