Proces Typ
Wyrażenie graficzne
Myślenie Typ
Wyrażenie strukturalne
Notatki Typ
Efektywne wyrażanie
Mapa drzewa
Schemat nawiasów
Tryb domyślny
W programowaniu zaplecza kod rozwiązuje problem „jak”, natomiast wykresy rozwiązują problemy „co” i „dlaczego”.
Diagramy są dla programistów back-end „lustrem perspektywy systemowej” – dzięki nim niewidoczne wywołania stają się widoczne, niejasne architektury – wyjaśnione, a niepamiętane relacje – przeszukiwalne. Niniejszy artykuł rozpoczyna się od problemów charakterystycznych dla back-endu i przedstawia sześć typów diagramów, które rzeczywiście rozwiązują problemy – każdy diagram odpowiada rzeczywistemu dylematowi w back-endzie.
W erze architektury monolitycznej struktura systemu była bardzo prosta – jedna aplikacja, jedna baza danych, a zależności były jasne na pierwszy rzut oka. Jednak w architekturze mikrousług liczba usług wzrasta z kilku do kilkudziesięciu, a nawet setek, a relacje wywołań między usługami tworzą sieć, której nikt nie jest w stanie wyraźnie dostrzec.
Ponad 67% przedsiębiorstw po wdrożeniu mikrousług boryka się z problemami, takimi jak mylące zależności usług i nieprzejrzyste łańcuchy wdrożeń. Typowy system e-commerce może obejmować usługi zamówień, płatności, magazynowania, obsługi użytkowników, logistyki, przesyłania wiadomości itd. Wiesz, że A wywołuje B, ale czy A pośrednio zależy od C? Jeśli B ulegnie awarii, ile usług nadrzędnych zostanie dotkniętych? Na te pytania nie da się odpowiedzieć, po prostu „patrząc na kod”.
Diagram topologii mikrousług wizualizuje strukturę zależności systemu mikrousług poprzez węzły (usługi) i krawędzie (relacje wywołań). Nie jest to statyczny diagram architektury, lecz narzędzie do obserwacji, które może dynamicznie odzwierciedlać częstotliwość wywołań w czasie rzeczywistym, rozkład opóźnień i stan usług.
Schemat topologii sieci mikrousług
Dobry diagram topologii mikrousług może odpowiedzieć na trzy podstawowe pytania:
Kto od kogo zależy? — Pobieżne spojrzenie pozwoli dostrzec powiązania między podmiotami świadczącymi usługi w górę i w dół łańcucha dostaw.
Kto nas powstrzymuje? — Węzły usługowe charakteryzujące się dużym opóźnieniem lub wysokim wskaźnikiem błędów są automatycznie wyróżniane.
Kto poniesie największe straty w przypadku awarii? — Zidentyfikuj krytyczne węzły i pojedyncze punkty ryzyka awarii w systemie.
Scenariusz 1: Analiza przyczyn źródłowych. W przypadku dużej liczby przekroczeń limitu czasu w systemie, tradycyjna metoda rozwiązywania problemów polega na sprawdzaniu logów dla każdej maszyny i monitorowaniu każdej usługi. Na diagramie topologii mikrousług widać: ruch wchodzący z bramy API → przechodzi przez usługę zamówień → wywołuje usługę płatności → usługa płatności wywołuje zewnętrzny kanał płatności — a węzeł zewnętrznego kanału płatności jest wyświetlany na czerwono (nieprawidłowy). Przyczynę źródłową można zlokalizować w 3 sekundy, a nie w 3 godziny.
Scenariusz 2: Wykrywanie zależności kołowych. Usługa A wywołuje usługę B, usługa B wywołuje usługę C, a usługa C ponownie wywołuje usługę A – trudno to wykryć na poziomie kodu, ale na diagramie topologii od razu widoczna jest struktura strzałek kołowych.
Scenariusz 3: Planowanie przepustowości. Natężenie ruchu każdego węzła na diagramie topologii jest reprezentowane przez grubość linii, wskazujących, która usługa jest węzłem ruchu, a która usługa wymaga priorytetowej rozbudowy, co jest prezentowane bezpośrednio wizualnie.
Grupuj usługi według domeny biznesowej lub warstwy, aby uniknąć spłaszczania wszystkich węzłów.
Stan usługi oznaczony jest kolorem (zielony = normalny, żółty = ostrzeżenie, czerwony = usterka).
Grubość linii wskazuje częstotliwość połączenia, a kolor linii wskazuje poziom opóźnienia.
Rozróżniaj połączenia synchroniczne (linie ciągłe) i wiadomości asynchroniczne (linie przerywane).
Najtrudniejszym problemem do debugowania w programowaniu zaplecza często nie jest „ten kod jest błędny”, ale „które ogniwo w całym łańcuchu wywołań jest błędne”.
Żądanie użytkownika dotyczące zamówienia może przejść przez następujące etapy: Frontend → Bramka API → Obsługa zamówień → Usługa płatności (połączenie z podmiotem zewnętrznym) → Obsługa zapasów → Kolejka komunikatów → Usługa logistyczna → Baza danych. Jeśli którykolwiek z tych siedmiu etapów napotka problem – przekroczenie limitu czasu, zwrócenie błędu lub niespójność danych – użytkownik końcowy zobaczy jedynie niejasny komunikat „Błąd systemu, spróbuj ponownie później”.
Co bardziej skomplikowane, te wywołania mogą być synchroniczne (oczekiwanie na odpowiedź) lub asynchroniczne (wysyłanie komunikatu, a następnie jego ignorowanie); mogą istnieć mechanizmy ponawiania prób lub wyłączniki czasowe. Bez narysowania pełnej sekwencji wywołań po prostu nie da się określić, „z kim się skontaktować w sprawie tego błędu”.
Diagramy sekwencji, ujęte w pionową oś czasu i poziome diagramy uczestników, wyraźnie ilustrują chronologiczny proces przekazywania komunikatów między wieloma systemami. Są najlepszym narzędziem do ujednolicania interfejsu zaplecza, rozwiązywania problemów rozproszonych i projektowania procesów asynchronicznych.
Scenariusz 1: Pełna oś czasu procesu płatności. Użytkownik inicjuje płatność → Usługa zamówień tworzy zamówienie (status: płatność oczekująca) → Usługa płatności zostaje wywołana → Usługa płatności wywołuje zewnętrzny kanał płatności → Strona trzecia zwraca wynik płatności → Usługa płatności odwołuje się do usługi zamówień → Usługa zamówień aktualizuje status zamówienia → Usługa zamówień wysyła komunikat „płatność pomyślna” do MQ → Usługa magazynowa pobiera komunikat i odlicza zapasy → Usługa logistyczna tworzy zamówienie wysyłki. Inicjator, odbiorca, treść komunikatu i relacje czasowe dla każdego kroku są wizualizowane.
Scenariusz 2: Wzorzec Saga dla transakcji rozproszonych. Wzorzec Saga dzieli długie transakcje na wiele transakcji lokalnych, z których każda ma odpowiadającą im operację kompensacji. Diagram sekwencji wyraźnie pokazuje: Utworzenie zamówienia → Odliczenie zapasów → Odliczenie płatności → (Jeśli płatność się nie powiedzie) → Kompensacja zapasów → Anulowanie zamówienia. Udane i nieudane ścieżki są reprezentowane na diagramie sekwencji odpowiednio za pomocą fragmentów alt i opt.
Uczestnicy ustawiają się od lewej do prawej w kolejności inwokacji, inicjator znajduje się najdalej po lewej.
Wiadomości synchroniczne używają strzałek ciągłych, a wiadomości powrotne — strzałek przerywanych.
Różne scenariusze przedstawiono za pomocą fragmentów alt (gałąź warunkowa) i opt (gałąź opcjonalna).
Oznaczaj każdą wiadomość informacją o czasie jej wykonania, aby ułatwić analizę wydajności.
Wdrożenie kodu front-end jest stosunkowo proste – wystarczy go spakować i przesłać do sieci CDN. Wdrożenie back-end to jednak złożony projekt inżynierii systemów, obejmujący kontenery, klastry, sieci, pamięć masową i konfigurację.
Na ilu podach działa Twoja aplikacja Spring Boot? Ile pamięci jest przydzielone do każdego poda? Czy baza danych ma architekturę master-slave, czy klaster? Czy Redis jest wdrożony na tej samej maszynie co aplikacja? Ile warstw równoważenia obciążenia znajduje się przed bramą API? Nikt nie zapamięta wszystkich szczegółów, jeśli opiszesz je tylko ustnie. Co gorsza, struktury wdrożeń w środowiskach deweloperskim, testowym, przedpremierowym i produkcyjnym często się różnią – główna przyczyna problemu „działa dobrze w środowisku testowym, ale zawiesza się w środowisku produkcyjnym” często leży w tych różnicach wdrożeniowych.
Diagram wdrożenia ilustruje fizyczną strukturę wdrożenia systemu – gdzie komponenty oprogramowania są rozproszone w węzłach sprzętowych/kontenerowych oraz jak węzły komunikują się ze sobą. Służy on jako pomost między „projektowaniem kodu” a „działaniem systemu”, wyraźnie ukazując proces „przekształcania kodu w usługę online”.
Scenariusz 1: Architektura wdrożenia kontenerowego. Żądanie klienta → Kubernetes Ingress (punkt wejścia ruchu) → Kubernetes Service (wykrywanie usług i równoważenie obciążenia) → Klaster podów (uruchamianie instancji usług) → Pamięć trwała (PV/PVC). Diagram wdrożenia przedstawia liczbę replik, limity zasobów i zasady sieciowe dla każdego komponentu.
Scenariusz 2: Wdrożenie chmury hybrydowej. Podstawowe operacje biznesowe są wdrażane w chmurze prywatnej (ze względu na wymogi suwerenności danych), natomiast elastyczne zasoby obliczeniowe są wdrażane w chmurze publicznej (w celu obsługi nagłych wzrostów ruchu). Komunikacja między chmurami jest rozdzielana asynchronicznie za pomocą kolejek komunikatów. Diagram wdrożenia wyraźnie pokazuje, które usługi są lokalne, które lokalne, oraz jak przebiega przepływ ruchu między chmurami.
Węzły są reprezentowane przez kostki (maszyny fizyczne/maszyny wirtualne/kontenery), a komponenty wewnętrzne są reprezentowane przez prostokąty.
System operacyjny, środowisko wykonawcze i konfiguracja zasobów oznaczonych węzłów
Ścieżka komunikacji jest oznaczona protokołem (protokół HTTP/gRPC/Redis) i portem.
Do rozróżniania środowisk stosuje się różne kolory.
Dane stanowią fundament rozwoju zaplecza. Jeśli struktura tabel zostanie zaprojektowana nieprawidłowo, cały późniejszy kod będzie budowany na tym wadliwym fundamencie. Jednak projektowanie baz danych wiąże się z nieodłącznym wyzwaniem: interesariusze biznesowi opisują swoje wymagania w języku biznesowym, podczas gdy programiści projektują struktury tabel w języku baz danych – wymaga to procesu tłumaczenia.
Bardziej praktycznym problemem jest to, że gdy system obejmuje wiele usług i baz danych, modele danych dla każdej usługi są rozproszone w różnych repozytoriach kodu. Nikt nie jest w stanie zobaczyć „pełnego obrazu” na podstawie jednego diagramu. Nowi pracownicy często spędzają tygodnie, analizując kod kawałek po kawałku, aby dowiedzieć się, „jakie pola zawiera tabela zamówień i jak tabela użytkowników i tabela zamówień są ze sobą powiązane”.
Bez diagramów ER model danych istnieje wyłącznie w kodzie, a nie w konsensusie zespołu.
Diagramy ER (diagramy związków encji) służą do projektowania struktur baz danych, definiowania encji (tabel), atrybutów (pól) oraz relacji między encjami. Służą jako standardowe narzędzie do tłumaczenia „wymagań biznesowych” na „tabele bazy danych” oraz wizualna reprezentacja konsensusu zespołu w sprawie modelu danych.
Scenariusz 1 : Projekt modelu danych dla nowej funkcji. Zespół produktowy zaproponował dodanie funkcji kuponu. Programiści zaplecza najpierw zaprojektowali nowe tabele, korzystając z diagramu ER — tabelę kuponów, tabelę rekordów realizacji kuponów użytkownika oraz tabelę wykorzystania kuponów zamówień. Po narysowaniu diagramu odkryli zbędną relację między tabelami „rekord realizacji kuponów użytkownika” i „wykorzystanie kuponów zamówień”. Ta zbędna zależność została wyeliminowana na etapie rysowania diagramu, a nie odkryta w połowie tworzenia kodu.
Scenariusz 2 : Analiza wpływu zmian w bazie danych. Planowane jest dodanie pola do tabeli zamówień, ale nie jest jasne, które usługi nadrzędne i podrzędne zostaną objęte tą zmianą. Diagram ER wyraźnie pokazuje, które usługi korzystają z tabeli zamówień i z którymi tabelami jest ona powiązana – zakres wpływu zmiany jest bezpośrednio przedstawiony na diagramie, co znacznie obniża koszty oceny.
Obiekty reprezentowane są przez prostokąty, relacje przez romby, a atrybuty przez elipsy — zachowując standardowy system notacji.
Oznacz kardynalność (1:1, 1:N, M:N) na liniach połączeń między encjami i relacjami, aby uniknąć niejednoznacznego oznaczania.
Rysunek wykonywany jest w modułach, które odpowiadają dziedzinom działalności, aby uniknąć przeciążenia informacyjnego w jednym obrazie.
Oznacz klucz podstawowy (PK) i klucz obcy (FK).
W programowaniu zaplecza występuje częsty, lecz ukryty problem: jeśli zmodyfikujesz tabelę w usłudze A, pamięć podręczna w usłudze B nagle stanie się nieważna; jeśli dodasz pole do usługi zamówień, dane w usłudze raportów staną się niewspółosiowe.
Przyczyną tych problemów jest fakt, że dane nigdy nie są statyczne – nieustannie przepływają między wieloma usługami, bazami danych i warstwami buforowania. Jednak większość programistów rozumie tylko niewielki fragment ścieżki danych, za który odpowiadają, i nie ma globalnej perspektywy na cały cykl życia danych.
Gdy pojawiają się problemy z danymi (niespójność, utrata, duże opóźnienie), nie wiesz, którą ścieżką podążać. Rozumiesz strukturę każdej tabeli, ale nie wiesz, jak dane przemieszczają się od punktu początkowego do miejsca docelowego.
Diagram przepływu danych (DFD) ilustruje ścieżkę danych podczas ich przesyłania, transformacji i przechowywania między komponentami systemu. Odpowiada na trzy podstawowe pytania: skąd pochodzą dane, przez kogo przepływają i dokąd ostatecznie trafiają? Nie jest to statyczny model danych, lecz dynamiczna ścieżka danych.
Schemat przepływu danych systemu zarządzania biblioteką
Scenariusz 1 : Optymalizacja projektu interfejsu za pomocą grafu przepływu danych. Po wprowadzeniu grafu przepływu danych do procesu przetwarzania zamówień, platforma e-commerce odkryła, że dane tożsamości użytkownika były wielokrotnie odszyfrowywane w trzech usługach, co prowadziło do wydłużenia średniego czasu reakcji o 80 milisekund. Po optymalizacji, scentralizowane przetwarzanie za pośrednictwem ujednoliconej bramki uwierzytelniania przyniosło 19% poprawę wydajności. Wartość grafu przepływu danych polega na ujawnieniu „niewidocznej redundancji”.
Scenariusz 2 : Kontrola spójności danych. Produkt finansowy wykrył rozbieżność między saldami użytkowników a kwotami zamówień. Śledzenie danych za pomocą diagramu przepływu danych ujawniło, że „śledzenie zdarzeń” wynikające ze zmian na kontach przechodziło przez cztery usługi, a trzecia usługa traciła atrybut podczas transformacji danych. Diagram przepływu danych przekształcił dochodzenie z „szukania igły w stogu siana” w „kierowane wyszukiwanie”.
Do oznaczenia „kroków przetwarzania” użyj kółek lub zaokrąglonych prostokątów, a do oznaczenia „obiektów zewnętrznych” prostokątów.
Użyj otwartych prostokątów do przedstawienia „przechowywania danych” (baza danych/plik/pamięć podręczna).
Strzałki wskazują kierunek przepływu danych i opisują zawartość danych (np. „informacje o zamówieniu” lub „wynik płatności”).
Renderowanie warstwowe — wysoki poziom (diagram kontekstowy) wyświetla przepływ danych na poziomie systemu, natomiast niski poziom (poziom 1/2) wyświetla przepływ danych na poziomie modułu.
Systemy zaplecza stają się coraz bardziej złożone – rośnie liczba mikrousług, rodzaje oprogramowania pośredniczącego są zróżnicowane, a konfiguracje środowisk chmurowych są zróżnicowane. Gdy system składa się z dziesiątek usług, kilkunastu komponentów oprogramowania pośredniczącego i jest wdrożony w wielu strefach dostępności, nikt nie jest w stanie w pełni opisać jego wyglądu słowami.
Taka sytuacja może wywołać szereg reakcji łańcuchowych: nowi uczestnicy rozumieją tylko 30% treści omawianych na spotkaniach, na których omawiane są rozwiązania; gdy pojawia się awaria, nie sposób określić, czy bieżący problem należy do „problemu logiki biznesowej”, czy „problemu infrastrukturalnego”; podczas dyskusji na temat wyboru technologii każdy ma zupełnie inną definicję granicy systemu.
Diagram architektury to „ogólna mapa” systemu, pokazująca liczbę warstw, funkcje każdej z nich, lokalizację kluczowych modułów i wybrane technologie. Nie służy on konkretnemu scenariuszowi (takiemu jak rozwiązywanie problemów czy projektowanie bazy danych), lecz odpowiada na najbardziej fundamentalne pytanie: Jak wygląda ten system?
Diagram architektury systemu produktów Big Data
Dobry diagram architektury powinien umożliwiać czytelnikowi zrozumienie ogólnej struktury systemu w ciągu 30 sekund i odnalezienie interesującego go modułu w ciągu 2 minut.
Scenariusz 1: Przegląd rozwiązania technicznego. Diagram architektury stanowi podstawowy materiał na spotkaniu przeglądowym. Oznaczając strukturę warstwową „Warstwa dostępu → Warstwa biznesowa → Warstwa oprogramowania pośredniczącego → Warstwa danych” oraz stos technologiczny każdej warstwy na diagramie, recenzenci mogą intuicyjnie ocenić racjonalność rozwiązania, zamiast polegać na Twoim opisie.
Scenariusz 2 : Definicja granicy modułu. Gdy granica między usługą zamówienia a usługą płatności jest niejednoznaczna, jasny podział modułów i kierunki strzałek na diagramie architektury (która strona może wywołać którą stronę) bezpośrednio dostarczają odpowiedzi.
Warstwy stanowią istotę diagramu architektury — każda warstwa ma jedną odpowiedzialność i wyraźne granice.
Kierunek strzałek wskazuje kierunek przepływu danych lub połączenia. Spójność jest kluczowa, aby uniknąć pomyłek.
Nie umieszczaj wszystkich szczegółów technicznych (takich jak numery portów i ścieżki plików konfiguracyjnych) w jednym schemacie architektury.
Podkreśl najważniejsze wybory technologiczne, takie jak „Spring Cloud”, „Kubernetes” i „Redis Cluster”.
Sześć powyższych typów wykresów obejmuje podstawowe scenariusze rozwoju zaplecza, od projektowania architektury po modelowanie baz danych, od zarządzania usługami po wdrażanie i konserwację. Wiedza o tym, „co narysować”, to pierwszy krok, ale równie ważny jest wybór odpowiednich narzędzi.
ProcessOn, jako profesjonalna platforma do tworzenia wykresów i współpracy online, zapewnia programistom back-end kompleksowe rozwiązanie do tworzenia wykresów:
Obszerna biblioteka szablonów: Społeczność szablonów ProcessOn udostępnia różnorodne często używane szablony wykresów zaplecza, takie jak diagramy architektury mikrousług, diagramy architektury wdrożeń, diagramy ER, diagramy sekwencji i diagramy przepływu danych, obejmujące kompletne scenariusze od architektury systemu po projektowanie danych .
Obsługiwane są różne typy wykresów: ProcessOn obsługuje profesjonalne rysowanie diagramów topologii usług, diagramów sekwencji czasowych, diagramów wdrożenia, diagramów ER, diagramów przepływu danych i diagramów architektury .
Diagramy generowane przez sztuczną inteligencję: Wystarczy wprowadzić opis tekstowy, aby jednym kliknięciem wygenerować schematy blokowe, diagramy sekwencji, diagramy architektury itp., co znacznie zmniejsza bariery utrudniające tworzenie diagramów .
Współpraca zespołowa: Obsługuje współpracę online w czasie rzeczywistym między wieloma użytkownikami. Zespoły back-endowe mogą wspólnie zarządzać diagramami architektury i dokumentacją techniczną, a każda modyfikacja automatycznie zapisuje wersje historyczne .
P1: Które typy wykresów powinni traktować jako priorytetowe w masteringu programiści back-end?
O: Biorąc pod uwagę rzeczywiste problemy związane z programowaniem back-endu, zaleca się priorytetowe opanowanie: diagramów topologii usług (aby rozwiać wątpliwości dotyczące zależności mikrousług), diagramów sekwencji (aby wyjaśnić rozproszone łańcuchy wywołań), diagramów ER (język inżynierski projektowania baz danych) oraz diagramów architektury (przegląd systemu). Te cztery typy diagramów bezpośrednio odpowiadają czterem najczęstszym dylematom w programowaniu back-endu – niejasnym zależnościom usług, niejasnym łańcuchom wywołań, niespójnym modelom danych i niepełnemu obrazowi całego systemu.
P2: Jaka jest różnica między diagramem sekwencji a schematem blokowym?
A: Diagramy blokowe koncentrują się na przepływie sterowania w pojedynczym systemie – wejście → przetwarzanie → decyzja → wyjście – odpowiadając na pytanie „jak ta funkcja/moduł wykonuje się wewnętrznie”. Diagramy sekwencji koncentrują się na kolejności przekazywania komunikatów między wieloma systemami – kto co do kogo wysłał pierwszy i kto jaką odpowiedzią – odpowiadając na pytanie „które łącze w wywołaniu rozproszonym uległo awarii”. Oba są potrzebne w programowaniu zaplecza – diagramy blokowe dla logiki biznesowej i diagramy sekwencji dla wywołań rozproszonych.
P3: Jaka jest różnica między diagramem topologii mikrousług a diagramem architektury?
A: Diagram architektury jest statycznym produktem fazy projektowania – pokazuje, jak system „powinien” wyglądać, kładąc nacisk na warstwowanie, moduły i wybór technologii. Diagram topologii mikrousług jest dynamicznym produktem fazy wykonawczej – pokazuje, jak system „faktycznie” nazywa sam siebie, kładąc nacisk na zależności w czasie rzeczywistym, dystrybucję ruchu i stan systemu. Diagram architektury to „plan projektu”, a diagram topologii to „działający elektrokardiogram”.
P4: Czy diagram ER jest nadal przydatny w architekturze mikrousług?
O: To jeszcze bardziej użyteczne. Architektura mikrousług opowiada się za tym, że „każda usługa ma własną, niezależną bazę danych” – oznacza to, że model danych nie jest już skoncentrowany w jednym dużym grafie, lecz rozproszony na wielu diagramach ER usług. Wartość diagramu ER zmienia się z „rysowania jednego dużego grafu” na „rysowanie wielu mniejszych grafów i precyzowanie granic danych między nimi”. Diagram ER każdej usługi definiuje zakres suwerenności danych usługi i stanowi podstawę dekompozycji usługi.
P5: Jaka jest różnica między diagramem przepływu danych a diagramem ER?
A: Diagramy ER koncentrują się na „strukturze statycznej” – jak wyglądają tabele danych, jakie pola się w nich znajdują i jak są ze sobą powiązane? Odpowiadają na pytanie: „Jak wyglądają dane?”. Diagramy przepływu danych koncentrują się na „przepływie dynamicznym” – skąd pochodzą dane, przez co przechodzą i dokąd trafiają? Odpowiadają na pytanie: „Jak dane się przemieszczają?”. Te dwa rodzaje diagramów wzajemnie się uzupełniają – diagramy ER to narzędzia do projektowania bazy danych, a diagramy przepływu danych to narzędzia do rozwiązywania problemów z danymi i zarządzania nimi.
P6: Czy ProcessOn może generować profesjonalne wykresy zaplecza?
O: Tak. ProcessOn obsługuje często używane typy diagramów w programowaniu back-end, takie jak diagramy topologii usług, diagramy sekwencji, diagramy wdrożeń, diagramy ER, diagramy przepływu danych i diagramy architektury. Społeczność szablonów udostępnia gotowe szablony dla diagramów architektury mikrousług, diagramów architektury wdrożeń, diagramów ER itp., wspierając generowanie sztucznej inteligencji jednym kliknięciem i współpracę zespołową online.
Następując tutorial, aby spróbować
Darmowe korzystanie z ProcessOn
