UCAGEN Documentation

Introduction

UCAGEN is a software tool for generating client application code. More specifically, it creates an application architecture skeleton based on input specifications—represented as a list of atoms and their characteristics (Invariant Pattern).

Code generation platforms

The current version supports code generation for the following languages and platforms:

Two Ways to Use the Invariant Pattern

The Invariant Pattern is not tied to any specific tool. You can implement it manually, from scratch — and many engineers do exactly that. But if you'd rather skip the boilerplate and focus on your actual logic, UCAGEN is here to help.

It’s the same pattern either way. The only difference is whether you want to spend your time writing plumbing code — or building features. Just keep in mind: whether you use the generator or go manual, please make sure to follow the appropriate license.

Who probably won’t need UCAGEN

If you or your team:

Still curious? You can explore ready-made application templates to see what the Invariant Pattern feels like in action. No commitment required.

Web Version

UCAGEN comes in two editions: Web and Desktop. The Web version is free to use and runs right in your browser. The Desktop version (available for Windows, macOS, and Linux) is part of the paid subscription plan.

What’s the difference?

Both versions follow the same logic and generate identical project structures. There’s no difference in how the code is produced — it’s the same powerful engine under the hood. The only difference lies in the available features.

Limitations of the Web Version

1. You can use up to 5 logic atoms per project.
2. Code generation is limited to one platform at a time.
3. Unity support is not available.
4. Projects can’t be saved between sessions.
5. There’s a request limit per IP address.

If you need full flexibility, local storage, and support for all platforms — the Desktop version has you covered.

Desktop Client

The Desktop version of UCAGEN is available through a subscription and unlocks full functionality without the limitations of the free Web version.

Why choose the Desktop version?

Designed for professional use, the Desktop client provides a richer interface and a more productive workflow — especially when working on complex, multi-platform applications.

Key Advantages

1. Generate code for multiple platforms in a single operation.
2. No fixed limit on logic atoms — usage depends on your subscription plan.
3. Unity code generation is fully supported.
4. Includes support and updates based on your subscription tier.

You can also save and reopen your project configurations, making the Desktop version ideal for iterative development and long-term projects.

The Desktop version runs on Windows, macOS, and Linux. While code generation itself still occurs server-side, the client offers improved usability compared to the Web version.

It's the preferred option for teams building scalable UI applications across different platforms, or for users who want to streamline their development workflow with a dedicated client.

First Application

Building a client application consists of few key stages, each of which we will examine separately.

1. Preparing the Specification in Terms of Logical Atoms

In science and engineering, the only proven way to manage complexity—no matter how high—is to break a system down into its fundamental components. The Invariant Pattern follows the same principle, asserting that any client application, regardless of its complexity, can be represented as a set of standardized code blocks, identified by so-called atoms.

As explained earlier, defining an atom requires answering a few simple questions:

This information is sufficient to automatically generate the application's skeleton. Defining atoms is straightforward, as the logic of decomposition follows the SRP.

Take a simple CRUD application as an example. Its decomposition naturally results in:

• CreateEmployeeAtom;
• ReadEmployeesAtom;
• UpdateEmployeeAtom;
• DeleteEmployeeAtom.

However, there are nuances.

• If a certain functionality is frequently reused, it makes sense to extract it into a separate logic atom. For example, a CheckInternetConnectionAtom can be useful when internet availability needs to be checked repeatedly.
• Any real-world client application will require additional atoms beyond CRUD operations, such as: CreateNewProjectAtom, CloseApplicationAtom, UpdateRecentProjectsAtom, RemoveRecentProjectAtom, CloseProjectAtom and, probably, SaveProjectInquireAtom.

These names are self-explanatory, requiring no further clarification. With this, the preparatory phase is complete.

2. View Templates

In a client application, every action is triggered by an event. In the terminology of the Invariant Pattern, this means that the logic must be bound to a user interaction event within a specific UI window. Typically, this binding looks like this:

For example:

@Override
public void Bind() {
    if (_binderCloseProject == null) {
        IEventSource eventSourceCloseProject = new SimpleEventSource();
        _binderCloseProject =
            new BinderCloseProject(eventSourceCloseProject, this, _Binder);
        _binderCloseProject.Bind();
    }
    // ==================================
    ...
}

                            

Atom activity starting is provided by command manner in any comfortable location:

_bindableCloseProject.getAtomEventSource().RaiseEvent();

                            

In practice, it is rare to execute the same logical block in multiple windows. Typically, each logic atom is associated with a single, most appropriate window, although there are no strict limitations for special cases.

Defining UI window templates is straightforward; it requires specifying a window policy, of which there are four:

1. Permanent Policy

   A window created as a single instance that persists throughout the user session. These are usually container windows.
2. New Policy

   A short-lived window, typically used for individual list items.
3. Progress Policy

   A short-lived window associated with visualizing the progress of a long-running process.
4. Dialog Policy

   A short-lived window used for confirming user input.

In the current version of the application, these policies are not yet enforced. However, it is important to understand that different atoms are “placed” in different windows. This behavior can be managed in the Platforms tab.

3. Code Generation

This is the simplest step. Just press the Generate button and receive a ready-to-use project folder containing the application's skeleton for the selected platform(s).

4. Filling in Target Function Templates

This is the most creative part of the process. At this stage, you have multiple options:

• Manually implement function templates based on project requirements.
• Leverage AI in various ways.

The collective knowledge accumulated by developers over the years is immense. The fastest and easiest way to implement this step is to generate AI-powered code blocks based on your request. For example, you can ask AI to generate an implementation of a specific algorithm for your target platform.

5. UI Design

Everything discussed in the previous step also applies here—but with a focus on user interface design. The AI can assist in generating UI layouts, ensuring consistency and efficiency while allowing customization where needed.

UCAGEN Open License v1.0

Copyright © 2015-2025 Sergey Orlov / UCAGEN
Patent pending (USPTO Application No. 19227354)
Website: www.ucagen.com

1. Grant of Rights

You are granted the right to use, study, and modify the source code provided in this repository ("Licensed Work").

This grant applies to the following categories:

• Individuals — natural persons acting on their own, without employees or contractors.
• Small Teams — legal entities with no more than five (5) total team members (including owners, employees, and contractors contributing to the Licensed Work) and with aggregate gross revenue not exceeding €250,000 over the preceding twelve (12) months, measured across the entity and any affiliates under common control.

These users may use the Licensed Work in commercial projects only through manual use, as defined below.

Manual Use means use, modification, and creation of derivative works performed by humans without any form of Automatic Code Generation.

Deliverables created under work-for-hire or client agreements are permitted, but clients receive no rights to automate or generate derivative works using the patented method.

2. Restrictions

You may not use the Licensed Work, or any part of it, for Automatic Code Generation.

Automatic Code Generation means any process, tool, script, or system (including AI-based systems) that produces source code, configuration files, or architectural components without direct human authorship.

This includes, but is not limited to:

• Generating atoms, logic identifiers, or event pipelines;
• Creating or replicating UCAGEN-compatible project structures;
• Using AI or software tools to infer or reproduce the underlying method;
• Using the Licensed Work to train or fine-tune models, or to build or validate competing code generators or meta-programming tools.

Permitted AI Use

AI assistance is allowed only for the following purposes:

• Filling in internal logic slots (e.g., validation, execution, confirmation) within already defined atoms;
• Generating or adapting UI templates or components of arbitrary complexity;
• Performing non-structural tasks such as refactoring, renaming, or formatting code.

AI must not participate in selecting, generating, or organizing atoms, routes, or lifecycle logic. Any use beyond these limits is prohibited.

3. Patent Notice

The UCAGEN system and the Invariant Approach — also referred to as the Invariant Pattern or Orlov Pattern — are protected by a pending patent application (USPTO No. 19227354), with an international (PCT) filing in progress.

This license does not grant any rights under patent law. Use of the Licensed Work does not imply permission to reproduce, automate, or commercialize the patented method or system beyond the scope explicitly allowed in this license.

4. Warranty Disclaimer

The Licensed Work is provided "as is", without warranty of any kind, express or implied. The copyright holder shall not be liable for any damages arising from its use.

5. Redistribution

Redistribution of the Licensed Work, modified or unmodified, is permitted only if all of the following conditions are met:

• This license file remains intact and unmodified;
• No claims are made implying affiliation with or endorsement by the UCAGEN project;
• Any distributed code, including deliverables provided under work-for-hire or client contracts, retains this license and all associated restrictions;
• Clients or downstream recipients are made aware of this license and are bound by the same limitations, including the prohibition on Automatic Code Generation.

Failure to propagate the license or communicate these restrictions to recipients constitutes a violation of this license.

6. Termination

Violation of any restriction in this license will result in immediate termination of all granted rights.

Upon termination, you must cease all use of the Licensed Work and destroy all copies in your possession. Sections 2–4 shall survive termination.

7. Trademark

This license does not grant permission to use the names "UCAGEN", "Invariant Pattern", "Invariant Approach", or "Orlov Pattern" in commercial branding or to imply official affiliation or endorsement.

However, factual references to the method, such as stating that your project uses or follows the Invariant Pattern or Approach, are explicitly permitted and encouraged.

8. Governing Law

This license shall be governed by the laws of the Republic of Belarus.

Nothing in this section prevents the enforcement of this license or any related intellectual property rights in other jurisdictions, including through competent courts or international arbitration.

At the Licensor's discretion, disputes may also be resolved through final and binding arbitration administered by the International Chamber of Commerce (ICC) under its Rules of Arbitration. The seat of arbitration shall be in a neutral location, and the language of the proceedings shall be English.

9. Versioning

This license applies to the specific version of the repository in which it appears. Updated license versions may be published in the future, but they will not apply retroactively.