Modeling Guide
Knowledge Guides /How do UAF, DoDAF, and SysML divide responsibilities, and how should system-of-systems viewpoints be tailored?
Last updated: · New Horizon Digital Outsourcing Team
System-of-systems architecture and system modeling can work together, but producing every view mechanically is unnecessary. Define the review questions first, then select essential viewpoints expressing missions, capabilities, activities, resources, and system responsibilities. UAF, DoDAF, and SysML are not interchangeable based on visual appearance; check the adopted specifications and project delivery requirements.
Decide which review questions to answer first
- Identify whether this phase concerns capability gaps, mission coordination, information exchange, or system interfaces. For mission coordination, for example, identify participants, dependencies, and exception paths rather than selecting every view from a tool menu.
- Map each review question to input material, an owner, and output evidence. Mark viewpoints lacking input evidence or an owner authorized to confirm them for clarification, rather than creating formally complete but unusable models.
Establish a shared object dictionary and cross-level relationships
- The same organization, resource, or system should have a stable identifier across viewpoints. Minor name differences should not create duplicate objects. Standardize attribute units, object granularity, and relationship semantics before modeling.
- After allocating system-of-systems activities to system responsibilities, connect them to functions, ports, and interfaces in the system model. This mapping is project modeling work, not a capability automatically completed by selecting a particular tool.
Which assets should be delivered, and how can duplicate work be avoided?
- Recommended deliverables include tailoring rationale, an object dictionary, viewpoint products, relationship traceability, and an issue list. Generate review diagrams and tables from a shared model where possible to reduce discrepancies caused by separately maintained models and documents.
- Before reusing a template, check its object semantics and applicable tasks rather than simply replacing the project name. Organizational relationships, constraints, and boundary conditions from the original task may not suit the new project.
Acceptance priorities and common misconceptions
- Follow one mission to check connections among activities, executing resources, information exchanges, and system responsibilities, then identify which objects would be affected by a change. Explaining change impacts is more valuable than accumulating viewpoints.
- Do not equate architecture-model completeness with proof of operational effectiveness or system performance. Quantitative conclusions require separate simulation models, input assumptions, and validation evidence.