Gdzieś między Polską a Niemcami, a szczególnie w NRD

Czas nieutracony (6) – Modelarze

Teraz będzie o  narzędziach do modelowania.

Enterprise Architect logo

Enterprise Architect logo

Enterprise Architect pojawił się na rynku w roku 2000. Moje pierwsze zetknięcie z nim to był rok 2002 albo 3. Wybierałem narzędzie do modelowania dla serii projektów, które zamierzaliśmy robić w MDD. Wypróbowałem wtedy wszystko, co było dostępne na rynku. EA był wtedy bardzo nowy i miał baaardzo konkurencyjną cenę, przy niezłym usability i funkcjonalności. Projekty zakończyły się sukcesem, pod względem procesu (który ja stworzyłem) były najlepsze jakie robiłem.

Dziś, po ponad 20 latach od premiery, EA jest nadal nie najgorszy w porównaniu z innymi, podobnymi narzędziami. I jego cena jest nadal konkurencyjna - najtańsza wersja (Proffesional) kosztuje 220 USD. Dla porównania: Rhapsody zaczyna się od jakichś 800 USD.

Tyle że to narzędzie przez te dwie dekady prawie nie zmieniło się od strony technicznej i jest w tej chwili totalnie przestarzałe:

  • To jest nadal aplikacja 32-bitowa, czyli może zaallokować max. 2 GB pamięci. Niby dużo, ale jednak nie.
  • Modele zapisywane są w Accessowej bazie danych (przynajmniej dla wersji Proffesional, droższe wersje wspierają również inne bazy danych). Do niedawna używali drivera MS JET 3.5 (MS Access 97) parę lat temu przeszli na MS JET 4.0 (MS Access 2003). Problem jest przede wszystkim w ograniczeniu maksymalnej wielkości pliku bazy danych (v3.5 - 1GB, v4.0 - 2GB). To jest za mało na moje potrzeby. No i samo użycie bazy danych - relacyjna baza danych jest stosunkowo wolna przy zapisie (aktualizacja indeksów), aktualne tendencje idą w stronę nierelacyjnych baz danych NoSQL.
  • Producent nie chce zdradzić w czym to jest napisane, ale musi to być coś ze stajni Microsoftu, prawdopodobnie C++.
  • Interface do pluginów idzie przez microsoftowy COM, to jest strasznie wolne (mierzyłem - wczytanie wszystkich obiektów modelu do mojego plugina przez COM idzie 50 razy dłużej niż jak wczytam je bezpośrednio z bazy danych).
  • Potrafię wywalić ten program do systemu w 100/100 próbach przy normalnej edycji modelu, ten problem był już w wersji 13.5, na pewno był nadal w 15.1, nie sprawdzałem jeszcze w aktualnej 15.2.
  • Struktura bazy danych i COM API są bardzo niespójne (również w konwencjach nazewnictwa), i mają luki - pewne rzeczy nie są w ogóle dostępne przez API, niektóre wyraźnie przez nieuwagę.
  • UI jest jeszcze bardziej niespójne, widać że narastało ewolucyjnie.
  • EA nie za bardzo potrafi generować kod. Daje się z niego łatwo generować nagłówki funkcji, ale kodu wewnątrz funkcji nie (przynajmniej bez kombinowania albo uzupełniania EA pluginami). Notacja do konfigurowania jego wewnętrznego generatora też jest kryptyczna, niezbyt intuicyjna i słabo opisana.

Krótko mówiąc: ten program wymaga totalnego redesignu, którego nie będzie - bo wszystkie pluginy porobione przez użytkowników przez te 20 lat przestały by działać. No ale program jest dość popularny, niedrogi i ma nieźle udokumentowane API w porównaniu z innymi, można od niego zacząć.

Żeby nie było że EA to jakiś technologiczny wyjątek - Rhapsody jest parę lat starsze (1996) i też od tego czasu niewiele się technicznie zmieniło:

  • Też jest 32-bitowe (tymczasem jest też wersja 64-bitowa, ale nie ma ona jeszcze wszystkich ficzerów wersji 32-bitowej)
  • Jest napisane bodajże w C++ (wnioskuję po tym, że wywala się czasem do systemu, w Javie tak nie ma), ale wygląda na bardzo posprzęgane z Javą.
  • Wersje 8.1.x też się wywalały aż do systemu przy normalnej pracy, nie wiem czy udało im się to poprawić.
  • API do rozszerzeń jest w Javie, ma to plusy i minusy.
  • Projekty są zapisywane w plikach tekstowych, jest możliwość podłączenia bazy danych.
  • Kilka dodatkowych toolów do konfigurowania tego i owego w Rhapsody (na przykład template dokumentacji) jest zrobiona w Eclipse (w końcu Eclipse jest od IBM, a nazwa jego wynika stąd, że miało zaćmić Słońce (czyli Suna, popatrzcie na logo)). Eclipse dobre było, ale dziś to nie jest już aktualny stan techniki.
Logo Eclipse

Logo Eclipse

Narzędzi do modelowania jest znacznie więcej, miałem kontakt jeszcze z kilkoma innymi (np. Borland Together, MagicDraw, Papyrus, Astah...). Długo by opisywać, do ideału wszystkim jest daleko.  Może teraz parę generalnych uwag co do takich narzędzi i MDD:

  • Hype na MDD sprzed dwudziestu lat szybko opadł, kiedy się okazało że nie za bardzo da się wziąć narzędzia z półki i z marszu zrobić MDD aplikacji według swoich potrzeb. Praktycznie zawsze niezbędny jest długi etap dopasowywania narzędzia do projektu, i to może być trudniejsze niż zrobienie aplikacji "normalnie". W każdym razie, dla jednego projektu najczęściej się nie opłaca, a wiele kolejnych projektów w dokładnie tej samej technologii (czyli nie wymagających dopasowania narzędzia od nowa) to nie jest znowu taki częsty przypadek.
  • Producenci narzędzi często oferują profile do robienia MDD w różnych działkach, ale żeby któryś z tych profili pasował do konkretnego zastosowania bez potrzeby robienia w nim zmian, to jest raczej wyjątek.
  • Robiłem już projekt, w  którym modelowaliśmy obiekty w toolu, a potem ręcznie robiliśmy analogiczne definicje w plikach tekstowych, z których był generowany kod. (To był pomysł klienta, nie jedyny taki świetny w tym projekcie, aż na koniec rzuciłem wypowiedzeniem). Takie podejście praktycznie nie różni się od modelowania + kodowania całkowicie ręcznego - jest media break (jest na to polskie określenie?), więc nie ma MDD.
  • Narzędzia do modelowania są najczęściej słabo zintegrowane z build process - w praktyce kod generowany z modelu jest checkinowany, bo generacja nie jest możliwa z batcha, za długo trwa żeby generować za każdym buildem, albo (jak w standardowym EA) generowane są tylko nagłówki funkcji, a kod trzeba dopisać ręcznie. Problem polega na tym, że jeżeli kod jest w repository a generacja wymaga czasu/wysiłku, to developer ma mocne pokusy żeby poprawiać kod w wygenerowanym źródle, a nie w modelu, i w tym momencie jest po MDD. (Nie rzucę pierwszy kamieniem, mimo że jestem z tych twardszych i bardziej zdyscyplinowanych)
  • Praktyczny, realnie istniejący (nie mylić z górnolotnymi ideami) development z użyciem toola do modelowania wygląda typowo tak:
    • W toolu architekci robią system design. Do tego taki tool nadaje się praktycznie z marszu, do tego takie narzędzia zostały wymyślone.
    • Dalej development przechodzi na poziom modułów. Developerzy rzadko są biegli w modelowaniu i raczej od razu implementują (czytaj: kodują) swoje moduły.
    • Szczególnym problemem są automaty skończone (czy tak się mówi fachowo po polsku na statemachine?). W praktyce każdy kawałek który ma jakąś swoją zmienną przechowywaną pomiędzy wywołaniami i jakiegoś ifa zależnego od tej zmiennej, to już jest statemachine. Problem jest taki, że w implementacji nie widać zbyt dobrze, co ona właściwie robi - do tego służy statechart. Tyle że jeżeli statechart i implementację zrobimy niezależnie od siebie, to można spokojnie założyć, że obie te rzeczy wcześniej czy później się rozjadą. Porządna implementacja statemachine też nie jest taka całkiem trywialna, ludzie robią to często mnożąc ify w różnych miejscach kodu, a potem nie są w stanie tego wszystkiego opanować (to był przypadek modułu, z powodu którego leciałem do Meksyku). Prawdziwy zysk z MDD ma się wtedy, gdy kod statemachine jest generowany ze state diagramu (w moim przypadku, tym jednym ruchem udało się uniknąć dobrych paru baniek strat w euro).
    • Dokumentację modułu robi się, nawet jeżeli w tym toolu, to ręcznie i dopiero na późnym etapie.
    • Nawet jeżeli dokumentacja jest OK, to potem trzeba robić poprawki w kodzie, ręcznie nanoszone znowu do modelu, i na 90% dokumentacja przestaje dokładnie odpowiadać stanowi rzeczywistemu.
    • Robienie dokumentacji z modelu to też większy temat. W praktyce najczęściej diagramy przekleja się ręcznie do dokumentu w czymś innym. W Rhapsody generowało się z każdego diagramu (ręcznie) osobny dokument w Wordzie, z listą obiektów widocznych na diagramie i opisami do nich wziętymi z modelu, ale porządną dokumentacją nazwać tego nie można było. Zrobienie porządnych templatów do dokumentacji jest możliwe (chociaż nie w każdym narzędziu tego typu), ale to może być jeszcze więcej roboty, niż ze zrobieniem generacji kodu.
  • Nie wiem skąd ten pomysł, ale i EA, i Rhapsody (inne pewnie też, ale nie sprawdzałem albo nie pamiętam) mają taki ficzer, że jak dodać connector między dwoma obiektami, to ten connector pojawia się automatycznie na wszystkich diagramach gdzie te dwa obiekty są. Nawet jeżeli diagram jest zalockowany. No tylko strzelać do pomysłodawców - regularnie trzeba przeglądać wszystkie diagramy i usuwać z nich te niepotrzebne connectory.
  • U mnie, w automotive, w działce safety, zasadniczą sprawą jest requirement tracing. Same requirementy trzymane są zazwyczaj w IBM Doors, to jest server, do którego można się podłączyć z aplikacji. W odpowiednich miejscach modelu (i kodu, ale to nie jest ściśle wymagane) powinny być linki do requirementów, które dany element implementuje. No i tu też nie widziałem dotąd dobrze zrobionego połączenia z modelem, to zawsze jest prawa ręka za lewe ucho, potem puścić skrypt, a potem szukać gdzie linka jeszcze brakuje.

Ogólnie to jest tak, że MDD to świetny pomysł, tyle że w praktyce nikt nie ma czasu i szmalu żeby to zrobić. Guglanie za projektami które naprawdę zostały zrobione przez MDD nie przynosi prawdziwych rezultatów, tylko linki do opracowań teoretycznych, materiałów reklamowo-szkoleniowych producentów narzędzi i do dyskusji, dlaczego tego nie ma.

W praktyce toole do modelowania są używane jako trochę lepsze narzędzia do rysowania diagramów, i tyle. To warto było by zmienić. Za zmienianie weźmiemy się w następnym odcinku.

-----------------------------------------------------------------------------------------------------------------------

Dotyczy:

Kategorie:Programowanie

Sledz donosy: RSS 2.0

Wasz znak: trackback

-----------------------------------------------------------------------------------------------------------------------


11 komentarzy do “Czas nieutracony (6) – Modelarze”

  1. maciek pisze:

    automaty skończone (czy tak się mówi fachowo po polsku na statemachine?)

    Mówi się maszyna stanów, tzn. mówi się podobnie jak po angielsku – automat skończony na FSA a maszyna stanów na FSM, czyli zazwyczaj jak naprawdę tego używamy do jakiegoś stanu w programie.

  2. charliebravo pisze:

    @jak fachowo po polsku
    Ja „mam ochotę powiedzieć” automat skończony albo maszyna stanowa (nie stanów). Ale ostatni raz słyszałem takie rzeczy po polsku na wykładach 20 lat temu 🙂

    @temat notki
    Muszę powiedzieć, że _tak w ogóle_, to MDD wydaje mi się overkillem/jeszcze jednym fadem w rodzaju „zamiast pisać słowa kluczowe, można rysować schematy i każdy będzie umiał programować” (vide LabView). 99% programistów pisze rzeczy, których nie ma sensu tak robić, bo wychodzi za drogo jeśli zrobić porządnie, a w innym przypadku jest niepotrzebnym zawracaniem głowy.

    ALE: w takich zastosowaniach jak automotive, czy innych gdzie zależy od tego bezpieczeństwo, to dobrze wdrożone i naprawdę formalnie trzymane za mordę wydaje mi się spoko. Oczywiście tak jak pisałeś – nie słyszałem nigdy o projekcie, który byłby tak naprawdę dobrze zrobiony. Więc powodzenia!

    ORAZ: w programowaniu obiektowym w pewnym sensie wszystko jest maszyną stanową, ale tak naprawdę dosyć rzadko ta maszyna stanowa robi się nietrywialna. I tutaj 100% racji, czasem zdarza się że z jakichś skomplikowanych struktur ifów, zmiennych składowych i innych rzeczy robi się coś co de facto jest maszyną stanową. Efekt jest taki, że często kod wygląda OK, albo w miarę rozsądnie, i tak normalnie to działa, ale potem przychodzi na przykład nietypowa sekwencja danych wejściowych, i to powoduje wejście w stan którego nie da się opuścić, lub podobnie.

    Od wielu lat męczy mnie myśl że to się powinno specyfikować formalnie jako maszynę stanową właśnie (stany, reguły przejścia, itp), i potem odpowiedni program powinien to weryfikować i wypluwać stosowne błędy i ostrzeżenia, a jeśli wszystko jest OK, to generować kod w odpowiednim języku, realizujący taką właśnie maszynę stanową. Analogicznie jak np lex czy yacc, to nawet nie musiałoby być graficzne przecież.

    @ograniczeniem jest COM/Access
    Taaak, tam gdzie pojawia się COM, tam zaczyna się wolno i ciężko, a jako dodany bonus, oczy wypływają od tego jakie to jest brzydkie. A nie dałoby się „zhackować” ograniczenia pisząc własny driver udający ten właściwy, ale pod maską wykorzystujący coś bardziej rozsądnego i wydajnego (choćby SQLite?)

    • cmos pisze:

      @charliebravo
      „można rysować schematy i każdy będzie umiał programować”

      Takie podejście to jest oczywisty fad. Według mnie podstawowym zyskiem z MDD jest to, że koncepcja, kod i dokumentacja zawsze zgadzają się we wszystkie strony.

      „generować kod w odpowiednim języku, realizujący taką właśnie maszynę stanową.”

      BTDT, i to nie raz. To działa. Problem jest tylko taki jak opisuję – że to tylko rzadko działa z półki.

      „nie dałoby się „zhackować” ograniczenia”

      A pewnie że się dało, czytam sobie wprost z bazy danych (i piszę sporo rzeczy też) omijając EA, tyle że to jest dublowanie istniejącej funkcjonalności i wymaga wielu kombinacji żeby EA i mój kawałek były zsynchronizowane. Znaczy mniej roboty by było bez tego EA.

  3. marku pisze:

    Po tych kilku latach już straciłem nadzieję, że tak wartościowy blog przepadnie, jak wiele innych stron, których już nie ma.
    A tu takie miłe zaskoczenie- odżył i jeszcze ruszył się temat programowania.
    Co do Sparxa-cóż, widać, że powstał w dawnych czasach. I choć ma swoje zalety- to przegrywa ze „zwinnymi narzędziami”. W użytku lokalnym ( dla jednej osoby) – może wydawać się „ciężki”, a w użyciu grupowym przegrywa koniecznością instalacji na każdym kompie (plus brak możliwości prostego publikowania jako web). Podobno 16 ma być już 64 i mieć kilka nowych rozwiązań. Mam wrażenie, że jednak twórcy przegapili moment w którym można go było usprawnić i uniknąć łatki „starego”

    • cmos pisze:

      @Sparx
      To samo można powiedzieć o Rhapsody i paru innych. W ogóle modelowanie utknęło, potrzebne jest nowe podejście (jak mi się zacznie kręcić aktualny projekt, spróbuję podejść)

      • marku pisze:

        Niestety same „języki modelowania/konwencje” powstały w innych realiach. Część nie ulegała zmianom od lat, lub były symboliczne- nieodzwierciedlając dynamiki zmian w szerokopojętym IT. To tak jakby w elektronice próbować tworzyć schematy układów zawierających np. tranzystory, czy układy scalone, przy pomocy symboli z okresu królowania lamp- Nie dziwi więc, że gro dokumentacji powstaje jako proste „prostokąty połączone kreskami” – a ich sens jest wytłumaczony opisowo tekstem.

        • cmos pisze:

          Tu się nie zgadzam – diagramy w UML2 robi się cały czas i to działa. No może poza paroma dość specyficznymi przypadkami, na przykład nigdy nie udało mi się zrobić sequence diagramu dla wywłaszczania tasków. Ale przy normalnym kodzie nie ma problemu.
          Specyfikacja UML 2.5.1 to jest grudzień 2017, nie tak znowu dawno.

          • marku pisze:

            Może nieprecyzyjnie się wyraziłem, oraz jednak używamy Sparxa w nieco innym celu ( co tylko pokazuje też jego uniwersalność jako potencjalnej platformy do współpracy różnych użytkowników). Zajmuję się bardziej działaniem w Archimate, BPMN, UML to dla mnie głównie UseCase, Req, i diagramy sekwencji, stanów. Po prawdzie to już zwątpiłem czy ktokolwiek używa Sparxa do „programowania” (czytałem o tym, widziałem jakieś przykłady, coś próbowałem samemu-ale nie spotkałem nikogo kto by to używał) – a tu proszę, przedstawiasz całe to zagadnienie. I własnie Archimate, BPMN miałem na myśli jako ” niezmieniane”- owszem kilka lat temu pojawił się Archi 3.1, i od początku dało się prezentować zależności między warstwami aplikacji, biznesu etc, ale np. dalej zapomnij o „obiekcie” który by reprezentował ” bazę danych”, czy choćby temat rozwiązań chmurowych. Sparx od wersji 15 zawiera zbiór własnych symboli na potrzeby chmur ( Googla, Azure, AWS) – ale to jest „nakładka” na UML-owy obiekt „Component”

          • cmos pisze:

            A, jak masz na myśli profile, to rzeczywiście z aktualizacjami słabo. Dokładnie o tym piszę – że te wszystkie rozwiązania rzadko dają się używać z półki, i trzeba brać sprawy w swoje ręce (keywords: MDG, ShapeScript).

  4. marku pisze:

    i jeszcze 2 tematy:
    „A pewnie że się dało, czytam sobie wprost z bazy danych (i piszę sporo rzeczy też) omijając EA, tyle że to jest dublowanie istniejącej funkcjonalności i wymaga wielu kombinacji żeby EA i mój kawałek były zsynchronizowane. Znaczy mniej roboty by było bez tego EA.”
    🙂 Dla mnie Sparx – to taka nakładka ( interfejs graficzny) na bazę danych/repozytorium (serce tego narzędzia). Czasami czuję się niczym Cypher z Matrixa patrzący na cyferki i widzący…. 😉
    Gdzieś – w którymś miejscu wspominałeś o tym, że w SParx relacje (linie) łączące 2 obiekty są widoczne na wszystkich diagramach.
    – ” to nie bug, to funkcjonalność” ( cyt klasyka) – chodzi o to, że diagram jest tylko „reprezentacją graficzną” tego co jest zapisane w przepastnej bazie/repozytorium Sparxa nt. tych obiektów. To plus ” założenie” współużytkowania bazy/repozytorium przez innych userów powoduje, że relacje pojawiają się wszedzie gdzie występują te konkretnie obiekty (początek i koniec relacji). Owszem da się ukryć relacje na innych diagramach ( jest taka opcja po kliknięciu w relację) oraz chyba w najnowszej wersji będzie można ” zamrozić” diagram- by nie wyskakiwały na nim relacje tworzone w innych diagramach

Skomentuj i Ty

Komentowanie tylko dla zarejestrowanych i zalogowanych użytkowników. Podziękowania proszę kierować do spamerów