Poznaj platformę / architektura
Architektura platformy
Junexis rozdziela opis systemu, analizę, przygotowanie artefaktów i wykonanie. Narzędzia pracy oraz komponenty diagnostyczne łączą te etapy, ale każdy z nich odpowiada na inne pytanie.
Ten rozdział przedstawia role i kierunki współpracy. Zakres obsługi zależy od komponentu, wersji, środowiska docelowego i konkretnego scenariusza.
Mapa współpracy
Źródła Junexis, manifest i konfiguracja.
Studio · VS Code · CLIAnaliza opisu, diagnostyka i generowanie; następnie narzędzia właściwe dla wybranych środowisk.
Model analizy · kod · manifesty · mapy debugowaniaArtefakty, zależności oraz konfiguracja muszą trafić do właściwych miejsc wykonania.
Urządzenie · serwer · aplikacjaZadania przetwarzają dane. Podłączona instrumentacja przekazuje sygnały o ich pracy.
Runtime · Observability · NarrativeDwie drogi informacji zwrotnej: Mentor korzysta z zapisu analizy projektu, a obserwacja i Narrative korzystają z danych wykonania. Studio i narzędzia CLI mogą prezentować te wyniki autorowi. Analiza struktury i historia pracy systemu nie są tym samym źródłem wiedzy.
Schemat porządkuje odpowiedzialności. Nie jest dowodem automatycznego wdrożenia na dowolne urządzenie ani pełnej integracji wszystkich komponentów.
Kto za co odpowiada?
| Komponent lub obszar | Rola w platformie | Granica odpowiedzialności |
|---|---|---|
| Lang i kompilator | Opis zadań, danych i połączeń; sprawdzanie projektu i generowanie obsługiwanych artefaktów. | Poprawny wynik kontroli nie potwierdza działania całego systemu. |
| Narzędzia środowiska docelowego | Budowanie i przygotowanie wygenerowanego kodu. | Ich dostępność oraz wymagania zależą od wybranego targetu. |
| Studio | Praca nad projektem, uruchamianie dostępnych operacji i prezentacja ich wyników. | Nie definiuje semantyki języka i nie zastępuje narzędzi wykonania. |
| Runtime | Obsługiwane zachowania zadań i komunikacji podczas pracy. | Nie ma jednej ujednoliconej implementacji o identycznym zakresie dla wszystkich środowisk. |
| Mentor | Analiza struktury i ryzyk na podstawie danych projektu. | Opinia nie zastępuje kompilatora, testów ani próby wykonania. |
| Observability | Odczyt przekazanych logów, audytu, gotowości i telemetrii. | Widzi dostarczone sygnały; nie monitoruje automatycznie każdego elementu systemu. |
| Narrative | Odtwarzanie historii wykonania i powiązań zarejestrowanych zdarzeń. | Brak zdarzenia nie dowodzi, że działanie nie nastąpiło. |
| Instalator | Przygotowanie narzędzi i zarządzanie obsługiwanymi komponentami środowiska. | Instalacja narzędzi nie oznacza wdrożenia systemu użytkownika. |
Co przekazują sobie komponenty?
Dokumentacja platformy opisuje artefakty jako kontrakty między narzędziami. Wersja kontraktu i zgodność jego odbiorcy mają znaczenie; nie należy zakładać, że każdy komponent odczyta dowolny format lub wersję.
- Zapis analizy, w tym
junexis.analysis.json, dostarcza Mentorowi informacje o symbolach, zadaniach, komunikacji i topologii. Nie jest zapisem tego, co rzeczywiście wykonały procesy. - Wygenerowany kod i manifesty artefaktów opisują wyniki przygotowane dla środowisk docelowych. Obecność pliku nie potwierdza jego zbudowania i uruchomienia.
- Mapy debugowania pomagają wiązać wygenerowany program ze źródłem. Dostępne możliwości debugowania zależą również od adaptera i konfiguracji.
- Paczka systemu wiąże przygotowane wyniki i informacje potrzebne do ich dostarczenia. Odbiór paczki oraz próba gotowości są osobnymi krokami.
- Sygnały i zdarzenia wykonania dostarczają danych obserwacji i Narrative. Ich kompletność zależy od instrumentacji oraz zbierania danych.
Identyfikatory budowania i paczki pomagają łączyć obserwowany wynik z wersją programu. Sam identyfikator nie gwarantuje autentyczności nadawcy ani kompletności historii.
Przykład: temperatura widoczna w aplikacji
Celem systemu jest pokazanie pomiaru człowiekowi. Jedno zadanie tworzy pomiar przy urządzeniu, drugie przekazuje go na serwerze, a trzecie prezentuje w aplikacji.
- Autor opisuje system: nazywa odpowiedzialności, dane, miejsca wykonania i połączenia.
- Kompilator i narzędzia przygotowują artefakty: wyniki dotyczą wybranych, obsługiwanych środowisk.
- System jest uruchamiany: potrzebne są właściwe zależności i konfiguracja procesów lub urządzeń.
- Autor sprawdza rezultat: potwierdza, czy pomiar dociera do aplikacji. Jeżeli scenariusz przekazuje zdarzenia, może dodatkowo przejrzeć sygnały i historię wykonania.
To przykład podziału odpowiedzialności, nie nowy test ani deklaracja gotowości wszystkich transportów. Zmiana wartości z 21°C na 24°C nie musi zmieniać topologii systemu.
Lab pokazuje poglądowy przepływ tego pomiaru. Model w przeglądarce ma własne ograniczenia i nie jest dowodem wykonania prawdziwego projektu.
Gdzie są Lab i specyfikacja?
Laboratorium organizuje poznawanie platformy przez cel i obserwowalny rezultat. Nie jest obowiązkowym komponentem uruchamianego systemu.
Specyfikacja jest miejscem precyzyjnych reguł języka i jawnych luk. Nie jest usługą, przez którą przepływają dane aplikacji.
Podportale porządkują dokumentację. Podział na domeny Lang, Studio, Lab i specyfikację nie jest narzuconą topologią systemu napisanego w Junexis.
Junexis nie narzuca jednego modelu mentalnego ani architektury Producer–Controller–Presenter. Podział odpowiedzialności dobiera autor do celu systemu.