Expand a module to see its topics. Use search to filter modules and topics.
- Why MBSE is perceived as slow, painful, and brittle
- High-pain / low-value modeling practices
- The Value-to-Pain Ratio
- Modeling for clarity and intent instead of tools
- How small modeling choices create disproportionate pain
- Why traditional MBSE diverges from real software practice
- Object-oriented thinking vs. functional thinking
- Behavioral ownership and encapsulation
- Aligning system models with executable reality
- Why software teams struggle to trust system models
- The distinction between problem-space analysis and solution-space architecture
- Why functional decompositions are often mistaken for architectures
- The absence of a natural stopping rule in functional breakdowns
- How functional hierarchies fragment behavior and responsibility
- Subsystems as architectural and behavioral owners
- Recursive decomposition with a natural stopping point
- Clear alignment with software and embedded implementation
- Why requirements are always incomplete at first
- Discovering missing requirements through behavior modeling
- Alternate and exception behavior as first-class requirements
- Preventing late-stage requirement surprises
- Maintaining traceability without cluttering diagrams
- What use cases are for—and what they are not
- Use cases as user-focused requirements
- Actors as parameters
- Why use cases should not be treated as behavioral specifications
- Clean handoff from use cases to behavior models
- Activity diagrams as discovery tools, not design artifacts
- Logic flow vs. data flow
- Avoiding object-flow and pin overload
- Deferring allocation and architectural decisions
- Using activities to stabilize requirements early
- Allocating responsibilities across subsystems
- Discovering interface obligations
- Coordinating multi-subsystem behavior
- Clarifying interactions without over-modeling
- Relationship to activities and state machines
- State machines as block-owned behavior
- States vs. modes
- Composite states and hierarchical modeling
- Entry, exit, and do semantics
- Internal transitions and history states
- Preparing state machines for simulation and code realization
- Why interfaces are a major source of MBSE friction
- Logical vs. physical interfaces
- Signals vs. flows
- Lean use of interface blocks and proxy ports
- Designing interfaces for change and simulation
- Keeping IBDs readable and reviewable
- The role of parametrics in system models
- Constraint blocks vs. constraint properties
- Writing clear, bindable equations
- Units, quantities, and consistency
- Separating constraint definition from usage
- Building reusable constraint libraries
- Binding parametrics to behavior models
- Understanding simulation context
- Why simulations often appear to “do nothing”
- Signals, events, and parametric evaluation
- Using the simulation console effectively
- Debugging models through execution
- End-to-end Lunar Lander performance modeling
- Integrating structure, behavior, and physics
- Validating descent, thrust, and safety constraints
- Connecting requirements to executable models
- Understanding executable architecture
- Autonomous landing as a state-based control problem
- Signals as the behavioral API
- Interrupt handling and recovery behavior
- Simulation-driven validation
- Bridging MBSE models to embedded software
- Complete reference architecture
- Domain model, subsystems, behavior, and interfaces
- Parametrics and simulation context
- Teaching anchor and post-course reference
- Bridge to AI-Assisted MBSE and SysML v2
