Poznaj platformę / modele mentalne
Modele mentalne
Model dobieramy do systemu. Producer–Controller–Presenter jest jednym z pomocnych sposobów porządkowania odpowiedzialności, a nie obowiązkowym podziałem każdego projektu.
Model mentalny pomaga odpowiedzieć: co w tym systemie jest ważne i jak jego części współpracują? Upraszcza obraz problemu, zanim przejdziemy do szczegółów kodu, narzędzi i wykonania.
Modele nie są dodatkowymi konstrukcjami języka. Nazwa roli nie tworzy zadania, procesu, transportu ani gwarancji działania.
Model, język i wykonanie to różne poziomy
| Poziom | Pytanie | Przykład |
|---|---|---|
| Model mentalny | Jak rozdzielić odpowiedzialności? | Źródło danych, decyzje i obraz dla człowieka. |
| Opis w Junexis | Jak zapisać wybrany podział? | Zadania, dane, komunikacja i miejsca wykonania. |
| Przygotowanie i wykonanie | Co rzeczywiście działa i gdzie? | Artefakty, narzędzia docelowe, procesy, urządzenia i konfiguracja. |
Zgodny z modelem diagram nie jest dowodem uruchomienia systemu. O tym, co obsługuje wybrana ścieżka, decydują kontrakty oraz zakres implementacji.
Producer–Controller–Presenter: opisany przykład
W dokumentacji repozytorium PCP jest pierwszym przyjętym modelem. Jego rola to pomoc w rozumieniu systemów, w których źródła dostarczają dane, część decyzyjna interpretuje je i utrzymuje stan, a interfejs przedstawia wynik człowiekowi.
Wytwarza dane.
Interpretuje, podejmuje decyzje i utrzymuje stan.
Przedstawia wynik.
Przykład: monitoring temperatury
- Producer przekazuje pomiar temperatury.
- Controller sprawdza pomiar według reguły i ustala stan, który należy pokazać.
- Presenter wyświetla temperaturę i wynik decyzji.
Jeśli użytkownik zmienia próg, interfejs przekazuje żądanie do części odpowiedzialnej za decyzje. Sprawdzenie uprawnień, walidacja i zapis zmiany wymagają implementacji; nie wynikają automatycznie z nazwy „Controller”.
Przeczytaj osobny rozdział Producer–Controller–Presenter.
Gdzie kończy się użyteczność PCP?
Nie każdy system potrzebuje centralnego Controllera ani interfejsu dla człowieka. Rola nie musi odpowiadać jednemu procesowi, a przypisanie Producer → urządzenie, Controller → serwer, Presenter → aplikacja jest mapowaniem przykładu, nie regułą języka.
Nie dodawaj warstwy tylko po to, aby dopasować projekt do diagramu. Najpierw ustal rzeczywiste odpowiedzialności i potrzebne połączenia.
Jak korzystać z modelu?
- Nazwij cel. Jaki rezultat ma dać system i kto go potrzebuje?
- Wypisz odpowiedzialności. Kto dostarcza dane, kto je przetwarza, kto korzysta z wyniku?
- Sprawdź dopasowanie. Czy model upraszcza opis, czy wymusza niepotrzebny element?
- Opisz system w Junexis. Rozróżnij odpowiedzialność zadania, miejsce wykonania i połączenia.
- Zweryfikuj rezultat. Sprawdź artefakty i działanie obsługiwanego scenariusza. Sam model tego nie potwierdza.
Na początku można prześledzić prosty przepływ pomiaru przez urządzenie, serwer i aplikację. Samo przekazanie pomiaru przez serwer nie oznacza jeszcze roli decyzyjnego Controllera.
Lab: pierwszy przepływ pomiaru jest modelem poglądowym w przeglądarce, a nie uruchomieniem wykonawców Junexis.
Inne kierunki: hipotezy do sprawdzenia
Poniższe nazwy pochodzą z katalogu w repozytorium. Nie mają statusu przyjętych modeli Junexis. Nie oznaczają też gotowych funkcji, gwarancji ani obsługiwanych scenariuszy. Służą obserwowaniu powtarzających się układów odpowiedzialności.
| Hipoteza | Pytanie, które może porządkować |
|---|---|
| Observe–Decide–Act | Jak obserwacja prowadzi do decyzji i skutku? |
| Ingest–Process–Present | Jak przyjąć, przetworzyć i pokazać dane? |
| Command–Execute–Explain | Jak polecenie prowadzi do kontrolowanego i wyjaśnianego wykonania? |
| Event–State–Projection | Jak zdarzenia budują stan i jego widoki? |
| Detect–Recover–Prove | Jak wykryć problem, odzyskać działanie i zachować dowód? |
| Edge–Coordinator–Fleet | Jak jednostki współpracują jako grupa? |
| Intent–Policy–Effect | Jak intencja przechodzi przez politykę do skutku? |
Nazwy i zakres mogą się zmienić. Wybór nazwy nie zastępuje projektu, implementacji ani sprawdzenia zachowania.
Kiedy rozszerzać katalog?
Dokumentacja przyjmuje kolejność: działający scenariusz, rozpoznanie powtarzającego się układu, nazwa i diagram, a następnie opis granic i dowodów.
Kandydat powinien upraszczać podział odpowiedzialności, pasować do więcej niż jednej dziedziny oraz mieć wykonywalny przykład lub powtarzalny scenariusz. Trzeba wskazać również sytuacje, w których model przestaje wystarczać.
Ten rozdział porządkuje istniejące materiały. Nie zatwierdza nowych modeli i nie przedstawia nowego dowodu wykonania PCP ani pozostałych układów.