The Unified Architecture Framework (UAF) supports the capability to:
- model architectures for a broad range of complex systems, which may include hardware, software, data, personnel, and facility elements;
- model consistent architectures for system-of-systems (SoS) down to lower levels of design and implementation;
- support the analysis, specification, design, and verification of complex systems; and
- improve the ability to exchange architecture information among related tools that are SysML based and tools that are based on other standards.
According to modeling needs, there are two UAF templates for different purposes:
- UAF Enterprise Architecture Project is designed for enterprise and IT architecture modeling and includes essential elements for this area: capabilities, requirements, operational behaviors, resources (hardware, software, facility), data, and personnel.
- UAF Project is designed to model architectures for a broad range of complex systems. The UAF provides an applicable model security controls, threat, risk, and risk mitigation. It allows defining consistent architectures for System-of-Systems (SoS) inclusive of all creation phases from the design until implementation.
Please make sure, that the UAF Plugin is installed.
UAF 1.2 Grid. The grid is a way of showing how the various view specifications (cells) correspond to viewpoints (prev. known as domains) (horizontal rows) and the aspects (prev. known as model kinds) (the columns) that describe the view specification.
The descriptions of all the viewpoints are provided in the following table:
Viewpoint | Acronym | Description |
|---|---|---|
Architecture Management | Am | Identifies the metadata required to develop a suitable architecture that is fit for its purpose. |
Strategic | St | Capability management process. Describes the capability taxonomy, composition, dependencies, and evolution. |
Operational | Op | Illustrates the Logical Architecture of the enterprise. Describes the requirements, operational behavior, structure, and exchanges required to support (exhibit) capabilities. Defines all operational elements in an implementation/solution-independent manner. |
Services | Sv | The Service-Orientated View (SOV) is a description of services needed to directly support the operational domain as described in the Operational View. A service within MODAF is understood in its broadest sense, as a unit of work through which a provider provides a useful result to a consumer. DoDAF: The Service Views within the Services Viewpoint describe the design for service-based solutions to support operational development processes (JCIDS) and Defense Acquisition System or capability development within the Joint Capability Areas. |
Personnel | Ps | Defines and explores organizational resource types. Shows the taxonomy of types of organizational resources as well as connections, interaction, and growth over time. |
Resources | Rs | Captures a solution architecture consisting of resources, e.g., organizational, software, artifacts, capability configurations, and natural resources that implement the operational requirements. Further design of a resource is typically detailed in SysML or UML. |
Security | Sc | Security assets and security enclaves. Defines the hierarchy of security assets and asset owners, security constraints (policy, laws, and guidance), and details where they are located (security enclaves). |
Projects | Pj | Describes projects and project milestones, how those projects deliver capabilities, the organizations contributing to the projects, and dependencies between projects. |
Standards | Sd | MODAF: Technical Standards Views are extended from the core DoDAF views to include non-technical standards such as operational doctrine, industry process standards, etc. DoDAF: The Standards Views within the Standards Viewpoint are the set of rules governing the arrangement, interaction, and interdependence of solution parts or elements. |
Actual Resources | Ar | The analysis, e.g., evaluation of different alternatives, what-if, trade-offs, V&V on the actual resource configurations. Illustrates the expected or achieved actual resource configurations. |
The descriptions of all the aspects are provided in the following table:
| Aspect | Acronym | Description |
|---|---|---|
| Motivation | Mv | Captures motivational elements e.g., challenges, opportunities, and concerns, that pertain to enterprise transformation efforts, and different types of requirements, e.g., operational, services, personnel, resources, or security controls. |
| Taxonomy | Tx | Presents all the elements as a standalone structure. Presents all the elements as a specialization hierarchy, provides a text definition for each one and references the source of the element. |
| Structure | Sr | Describes the breakdown of structural elements e.g. logical performers, systems, projects, etc. into their smaller parts. |
| Connectivity | Cn | Describes the connections, relationships, and interactions between the different elements. |
| Processes | Pr | Captures activity-based behavior and flows. It describes activities, their Inputs/Outputs, activity actions, and flows between them. |
| States | St | Captures state-based behavior of an element. It is a graphical representation of states of a structural element and how it responds to various events and actions. |
| Sequences | Sq | Expresses a time-ordered examination of the exchanges as a result of a particular scenario. Provides a time-ordered examination of the exchanges between participating elements as a result of a particular scenario. |
| Information | If | Address the information perspective on operational, service, and resource architectures. Allows analysis of an architecture’s information and data definition aspect, without consideration of implementation-specific issues. |
| Parameters | Pm | |
| Constraints | Ct | Details the measurements that set performance requirements constraining capabilities. Also defines the rules governing behavior and structure. |
| Roadmap | Rm | Addresses how elements in the architecture change over time. |
| Traceability | Tr | Describes the mapping between elements in the architecture. This can be between different viewpoints within domains as well as between domains. It can also be between structure and behaviors. |