Model-as-Software

A paradigm shift in how software is designed, generated, and executed.

From Model to Software Application
OABuilder
Model
OACodeGen
Full-Stack Application
powered by OAObjectGraph
🔁 The Paradigm Shift

Model-as-Software allows you to go from visually designing a Model, to running as a Software Application.

“ A system where software can be designed at a high level of abstraction, then automatically transformed into robust, scalable, fully functional applications — with minimal coding, full flexibility, and real-time adaptability. ”

OA focuses on filling the space between this Model and Software.

📘 Formal Description

Model-as-Software is a declarative architecture paradigm where a formally defined model — consisting of object structures, relationships, behaviors, rules, and triggers — is executed as a live, reactive object graph. This list represents the full application state and behavior in real time.

🧩 The gap between the Model and the Software
The gap between a defined model and a working software system has long been a core challenge in software architecture. While models offer a high-level, declarative view of a system's structure and behavior, transforming those models into a functional, distributed, and reactive application requires a significant amount of complex infrastructure. This "gap" is not trivial — it involves runtime execution, real-time synchronization, event propagation, validation, transactional consistency, and extensibility.

Finding solutions to fill the gap between model and software is one of software engineering's most persistent challenges

Nearly all modern software architectures, frameworks, and platforms are ultimately attempts to fill this same gap — to take an abstract model or mental picture of a system and make it executable.

Common approaches include:

⚒️ Core Requirements to Fill the Gap

1. ⚡ Live Execution of the Model
  • The model must be interpreted or executed in a live, running environment.
  • All relationships, constraints, and behaviors must be enforced at runtime.
2. 🔄 Reactive Object Graph
  • The system must maintain an observable object graph that reflects real-time state.
  • Dependencies (e.g., calculated properties, triggers) must be tracked and updated automatically.
3. 🌐 Synchronization Across Clients and Threads
  • All parts of the system — including distributed clients — must operate on a consistent view of the object graph.
  • Changes must be serialized, ordered, and propagated safely.
4. 🧱 Automated Code Generation
  • Boilerplate code (POJOs, DAOs, UI templates, REST endpoints) should be generated from the model.
  • Code must remain disposable and aligned with the model's definition.
5. 🧾 Metadata-Driven Architecture
  • The system must use rich metadata from the model for configuration, rules, access control, and behavior.
  • This metadata must remain consistent throughout the system lifecycle.
6. 🔌 Extensibility and Integration
  • The architecture must be open and composable.
  • New technologies (e.g., UI libraries, external APIs, databases) must be easily integrated.
🧩 OA’s Model-as-Software Stack
🔧 OABuilder

Visual modeling tool to design your system using a domain object graph. Enables collaboration between architects and domain experts.

📘 OAModel

The structured, metadata-rich representation of your domain. Includes object types, links, triggers, calculations, rules, and constraints.

⚙️ OACodeGen

Generates the software: Java code, REST interfaces, UI templates, and metadata — all synchronized with the model. Code is disposable and regenerable.

🧠 OAObjectGraph

The runtime engine that executes the model as an object graph. Tracks live state, enforces rules, propagates changes, and syncs clients in real time.

📚 OA Libraries

A complete set of supporting libraries for UI binding, persistence, REST, security, and distributed messaging — all model-driven and tightly integrated.

📜 Model-as-Software Manifesto
🔬 Model-as-Software - A Foundation for Software Engineering