Jak działa Junexis

Junexis to eksperymentalny język i zestaw narzędzi do opisywania systemów, których części działają w różnych miejscach: na urządzeniu, serwerze i w interfejsie użytkownika. W jednym projekcie autor określa zadania, dane, połączenia i miejsca wykonania. Narzędzia sprawdzają ten opis i w obsługiwanym zakresie tworzą kod dla wybranych środowisk.

Jaki problem rozwiązujemy

Wyobraź sobie magazyn z czujnikiem temperatury. Urządzenie wysyła pomiary, serwer sprawdza próg alarmowy, a panel pokazuje człowiekowi stan magazynu. Te trzy części mogą być napisane w różnych językach i uruchamiane osobno. Mimo to muszą tak samo rozumieć pomiar, alarm i brak połączenia.

Gdy opis każdej części znajduje się gdzie indziej, trudniej odpowiedzieć:

• kto wytwarza dane i kto ich potrzebuje,
• czy obie strony połączenia rozumieją ten sam typ danych,
• gdzie podejmowana jest decyzja,
• co trzeba zbudować dla urządzenia, serwera i panelu,
• jak sprawdzić, co wydarzyło się podczas działania systemu.

Junexis pozwala zapisać zadania i ich połączenia we wspólnym modelu projektu. Dzięki temu kompilator może sprawdzić obsługiwane kontrakty przed uruchomieniem, a narzędzia mogą korzystać z tego samego obrazu systemu.

Jeden przykład: temperatura w magazynie

flowchart LR
    SENSOR["Urządzenie<br/>odczytaj temperaturę"] -->|"pomiar"| RULE["Serwer<br/>sprawdź próg alarmowy"]
    RULE -->|"stan i alarm"| PANEL["Interfejs<br/>pokaż stan magazynu"]

W projekcie opisujesz znaczenie pomiaru, odpowiedzialność każdego zadania i przepływ informacji. Wskazujesz również, które zadanie ma działać na urządzeniu, które na serwerze, a które w interfejsie.

Wynikiem budowania są pliki przeznaczone dla tych środowisk — nazywane dalej artefaktami. W obsługiwanych ścieżkach Junexis generuje C++ dla urządzenia, Go dla serwera i TypeScript dla interfejsu. Zbudowanie artefaktów oraz ich uruchomienie wymagają odpowiednich narzędzi i konfiguracji środowiska.

Wspólny model pomaga zachować zgodność części systemu. Nie usuwa opóźnień sieci, awarii urządzeń ani potrzeby sprawdzania działania całości.

Kiedy warto przyjrzeć się Junexis

Punktem wyjścia są systemy, w których kilka niezależnych części wymienia dane i wspólnie realizuje cel: monitoring, telemetria, inteligentny dom albo panel nadzorujący urządzenia. Junexis pomaga opisać ich odpowiedzialności oraz powiązania przed przejściem do szczegółów poszczególnych środowisk.

Obecny zakres

Junexis jest projektem eksperymentalnym. Istnieją wykonywalne scenariusze generowania, pakowania i lokalnego uruchamiania, ale obsługa konstrukcji języka i integracji zależy od środowiska docelowego. Opis możliwości platformy nie oznacza, że każde połączenie urządzenia, serwera i interfejsu jest już obsługiwane ani gotowe do użycia produkcyjnego.

Przykład podziału odpowiedzialności

Junexis nie narzuca jednej architektury ani jednego modelu mentalnego. Model dobieramy do rzeczywistych zadań i relacji w systemie. Nie każdy system potrzebuje centralnego serwera decyzyjnego lub interfejsu dla człowieka.

Przykład magazynu można zrozumieć przez model Producer–Controller–Presenter:

flowchart LR
    P["Producer<br/>dane"] --> C["Controller<br/>decyzje i stan"]
    C --> V["Presenter<br/>obraz dla człowieka"]
    V -.->|"intencja"| C

W tym przykładzie mapowanie to @embedded → @server → @report. Jest to ilustracja odpowiedzialności, nie wymagany układ ani obowiązkowy etap projektowania. Obsługę konkretnej topologii trzeba sprawdzić w możliwościach wybranych środowisk wykonania.

Droga programu

flowchart LR
    A["Kod .jnx"] --> B["Parser i semantyka"]
    B --> C["Model systemu"]
    C --> D["Generowanie artefaktów"]
    D --> E["Urządzenie / serwer / interfejs"]
    E --> F["Dowody wykonania"]

1. Opis

Pliki .jnx definiują typy danych, zadania i potoki wykonania. Adnotacje takie jak @embedded, @server i @report wskazują środowisko wykonania.

2. Sprawdzenie

Kompilator buduje strukturę programu, sprawdza typy i wykrywa niepoprawne połączenia. junexis check kończy pracę na tym etapie.

3. Model systemu

Analiza zachowuje symbole, relacje i topologię programu w maszynowo czytelnej postaci. Dzięki temu Studio i inne narzędzia widzą ten sam system co kompilator.

4. Artefakty

junexis build wybiera generator odpowiedni dla środowiska docelowego. Obecny zestaw narzędzi generuje ograniczone, ale wykonywalne ścieżki C++, Go i TypeScript. Zakres zależy od konstrukcji użytych w programie.

5. Wykonanie i wyjaśnienie

Środowisko wykonawcze uruchamia wygenerowany kod. Narrative zbiera ślady potrzebne do odpowiedzi na pytanie „dlaczego system znalazł się w tym stanie?”, a Observability porządkuje sygnały techniczne i operacyjne.

Od źródła do paczki

flowchart TB
    SRC["src/main.jnx"] --> AST["Struktura programu"]
    AST --> IR["Model pośredni"]
    IR --> TOP["Topologia zadań i połączeń"]
    TOP --> GEN{"Generator środowiska docelowego"}
    GEN --> CPP["urządzenie / C++"]
    GEN --> GO["serwer / Go"]
    GEN --> TS["interfejs / TypeScript"]
    CPP --> MAN["Manifest artefaktów"]
    GO --> MAN
    TS --> MAN
    MAN --> PKG["Pakiet systemu"]

Elementy platformy

Element	Rola
Język i kompilator	opis, sprawdzenie i generowanie systemu
Środowisko wykonawcze	wykonanie i kontrakty komunikacyjne
Studio	edycja, budowanie, uruchamianie i debugowanie
Mentor	analiza struktury projektu i wskazówki
Narrative	rekonstrukcja przyczyn i przebiegu wykonania
Obserwacja systemu	logi, audyt, stan gotowości i korelacja zdarzeń
Narzędzia	praca w VS Code, LSP i integracja usług
Instalator	przygotowanie i aktualizacja środowiska

flowchart TB
    DEV["Autor systemu"] --> STUDIO["Studio lub VS Code"]
    STUDIO --> COMP["Język i kompilator"]
    COMP --> RUN["Wykonanie i środowiska docelowe"]
    COMP --> MENTOR["Mentor<br/>analiza projektu"]
    RUN --> OBS["Obserwacja systemu<br/>log · audyt · gotowość"]
    RUN --> NAR["Narrative<br/>historia przyczynowa"]
    OBS --> STUDIO
    NAR --> STUDIO
    MENTOR --> STUDIO

Pętla diagnozy

sequenceDiagram
    participant R as Wykonanie
    participant O as Observability
    participant N as Narrative
    participant S as Studio
    R->>O: sygnały techniczne i stan
    R->>N: zdarzenia z kontekstem wykonania
    S->>O: pokaż stan gotowości i logi
    O-->>S: bieżący obraz systemu
    S->>N: dlaczego to się wydarzyło?
    N-->>S: uporządkowana historia przyczyn

Nie trzeba poznawać wszystkich elementów naraz. Pierwszy projekt wymaga tylko kompilatora i Go.

Pełniejszy obraz odpowiedzialności znajduje się w architekturze platformy.