W świecie programowania obiektowego, termin „hermetyzacja” odgrywa kluczową rolę. Jak Grady Booch, jeden z pionierów programowania obiektowego, określił w swojej książce 'Object-Oriented Analysis and Design': Hermetyzacja to proces kompartmentalizacji elementów abstrakcji, które stanowią jej strukturę i zachowanie; kompartmentalizacja służy do ukrycia wewnętrznych mechanizmów działania obiektów i ujawniania jedynie tych aspektów, które są zewnętrznie widoczne. To właśnie hermetyzacja wyróżnia dobrze zaprojektowane obiekty od prostych kontenerów danych. Przyjrzyjmy się, jak ten koncept wpływa na projektowanie encji. Problem Encji Anemicznych: Przykład Dostępności W tradycyjnym podejściu anemicznym, encje często są traktowane jako proste kontenery danych. Przykładem może być klasa `Availability`, która przechowuje informacje o dostępności terminu, ale sama w sobie nie zawiera żadnej logiki biznesowej: ```java class Availability { private LocalDate date; p...
Ostatnio, testując różne możliwości tego kontrowersyjnego, ale jednak genialnego narzędzia, pojawiła się w mojej głowie potrzeba stworzenia diagramu na podstawie wcześniejszej konwersacji. Zastanawiałem się, jak GPT poradzi sobie z podziałem problemu na konteksty i wyodrębnieniem generycznych subdomen. Nawiasem mówiąc, przeprowadzenie pseudo-sesji event stormingowej z ChatGPT zasługuje na osobny wpis.
Biorąc pod uwagę szczątkowy opis biznesu, jaki dostał na wejściu, poszło mu całkiem nieźle. Opis dotyczył aplikacji do rezerwacji samochodów z wypożyczalni. Pomijając szczegóły całej rozmowy, otrzymałem taką listę (jak już wspomniałem, opis był bardzo krótki):
- ReservationsReservationManagement (processes related to car reservations)
- ClientAuthentication (verifying client identity and driving license details)
- VehicleFleetFleetManagement (managing vehicles, their availability, and pricing)
- GenericAvailability (checking vehicle availability in a specific period)
- CommunicationNotifications (communication between the rental company and clients, e.g., sending confirmations and notifications)
Pomyślałem, że miło byłoby mieć to wszystko rozrysowane. Poprosiłem więc o przedstawienie diagramu w postaci tekstowej. Otrzymałem coś takiego:
Nieźle jak na model językowy, jednak mało czytelne. Chciałem uzyskać coś bardziej na kształt mapy kontekstów. Napisałem więc tę sugestię i otrzymałem zmieniony diagram:
Co do sposobu relacji pomiędzy subdomenami można mieć oczywiście zastrzeżenia, ale tak jak już wspominałem, opis systemu był dosyć ubogi, więc GPT miało zdecydowanie za mało informacji na sensowną "analizę". W każdym razie, otrzymałem jakiś diagram. Myśląc jednak o praktycznym podejściu, czy taki diagram rzeczywiście jest czytelny? Jesteśmy raczej przyzwyczajeni do rysowanych prostokącików i strzałeczek... Wtedy przypomniałem sobie o pewnym narzędziu. Mermaid (https://mermaid.live/) — aplikacja do rysowania diagramów zapisanych w specjalnym, całkiem intuicyjnym, tekstowym formacie. Nie pozostało mi nic innego jak poprosić AI o przepisanie diagramu do odpowiedniego formatu.
zapisz diagram w formacie dla Mermaid
Otrzymałem następujący kod:
graph TD
Reservations[Reservations] -->|Open Host| VehicleFleet[VehicleFleet]
Reservations -->|Shared Kernel| ReservationManagement[ReservationManagement]
ReservationManagement -->|Customer| ClientAuthentication[ClientAuthentication]
ClientAuthentication -->|Shared Kernel| Communication[Communication]
Communication -->|Shared Kernel| GenericAvailability[GenericAvailability]
VehicleFleet -->|Shared Kernel| FleetManagement[FleetManagement]
FleetManagement -->|Customer| Notifications[Notifications]
Notifications -->|Shared Kernel| GenericAvailability
Pomijając merytoryczne błędy w podziale domen, wygląda to już całkiem ciekawie. Powyższy diagram powstał jednak po odrobinę dłużej rozmowie i nakierowaniu GPT na podział aplikacji na konteksty. Postanowiłem spróbować zadziałać bardziej bezpośrednio. Dałem AI kolejne zadanie:
Na podstawie tylko opisu aplikacji stwórz diagram obrazujący
proces rezerwacji samochodu.
Odpowiedź:
graph LR
A[Wybierz samochód] --> B[Wybierz daty rezerwacji]
B --> C[Podaj dane osobowe]
C --> D[Podaj dane o prawie jazdy]
D --> E[Wybierz dodatkowe opcje]
E --> F[Sprawdź i zatwierdź rezerwację]
F --> G[Otrzymaj potwierdzenie rezerwacji]
No... proces. Spróbowałem więc trochę podrasować ten graf:
@ja: przerób ten diagram na diagram sekwencji uwzględniający odpowiednich aktorów i potrzebne elementy
@ChatGPT:
sequenceDiagram
participant Klient
participant Aplikacja
participant Wypożyczalnia
Klient->>Aplikacja: Wybierz samochód
Aplikacja->>Klient: Pokaż dostępne samochody
Klient->>Aplikacja: Wybierz daty rezerwacji
Aplikacja->>Klient: Potwierdź dostępność
Klient->>Aplikacja: Podaj dane osobowe
Klient->>Aplikacja: Podaj dane o prawie jazdy
Klient->>Aplikacja: Wybierz dodatkowe opcje
Aplikacja->>Klient: Pokaż podsumowanie rezerwacji
Klient->>Aplikacja: Zatwierdź rezerwację
Aplikacja->>Wypożyczalnia: Nowa rezerwacja
Wypożyczalnia->>Aplikacja: Potwierdź rezerwację
Aplikacja->>Klient: Otrzymaj potwierdzenie rezerwacji
W rezultacie, dzięki współpracy z GPT, udało się stworzyć różnorodne diagramy, które przedstawiają zarówno podział domen, jak i proces rezerwacji samochodu. Oczywiście, wyniki nie są doskonałe, ale są na tyle czytelne i interesujące, że można się zainspirować i kontynuować pracę nad nimi w dalszej rozmowie z AI, lub programie przeznaczonym do tworzenia diagramów.
To doświadczenie pokazuje, że AI może być pomocne w generowaniu wstępnych wersji diagramów oraz wizualizacji, nawet jeśli nie są one idealne.
Moja zabawa z ChatGPT trwa, zobaczę czym jeszcze będzie potrafił mnie zaskoczyć...
Komentarze
Prześlij komentarz