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

Czas nieutracony (11) – Wtyczki

Teraz pożalę się na Enterprise Architecta. W sumie mógłby to być odcinek cyklu o twitach.

Najpierw lekka dygresja. Robienie mojego plugina zacząłem od założenia stubów wszystkich funkcji API do pluginów, żeby zobaczyć co tam się dzieje. Ściągnąłem też dostępną dokumentację od Sparksa i zacząłem czytać forum u nich. Szybko zauważyłem, że Sparx nie za bardzo odpowiada na pytania, za to rządzi tam jeden gościu, niezależny guru od EA z Holandii, nazwiskiem Geert Bellekens. Ten gościu żyje z robienia konsultacji z EA i pisaniu pluginów na zamówienie. No i on opublikował darmowy framework do robienia takich pluginów w C# i kilka dość użytecznych pluginów ogólnego przeznaczenia. Ściągnąłem sobie to i zajrzałem do źródeł - to było całkiem nieźle zrobione, ale zorientowane na reusing przy robieniu wielu pluginów, przy jednym, jak u mnie, to by był overkill. Zostawiłem to więc, zajrzałem potem do tego może ze dwa razy.

Kwiatków w tym EA jest masa, parę przykładów:

  • Przy tworzeniu elementów i package pluginy dostają eventy PreNew i PostNew. Niestety przy tworzeniu package, w PreNew nie dostajemy informacji jak package będzie się nazywać, i w związku z tym nie możemy zapobiec utworzeniu obiektu o niepożądanej nazwie.  Przy elemencie to działa, więc nie ma że się nie da.
  • Przy usuwaniu obiektu jest tylko event PreDelete, nie ma PostDelete. Problem jest taki, że PreDelete idzie po kolei do wszystkich aktywnych pluginów, możemy dostać go i zgodzić się na skasowanie obiektu, ale inny plugin po nas  może mieć coś przeciwko i na koniec obiekt nie zostanie skasowany. Jeżeli podjęliśmy jakieś akcje w PreDelete - bo gdzie indziej? - to możemy stracić synchronizację.
  • Przy kasowaniu diagramu w PreDeleteDiagram nie dostajemy nawet ID kasowanego diagramu. Po co komu taki event, jeżeli nie wiadomo czego dotyczy?
  • Obiekt COM dla diagramu nie zawiera pola TreePos (pozycja obiektu pod parentem). W bazie danych takie pole jest, przy innych typach obiektów też, tylko w tym jednym miejscu im się po prostu zapomniało. No i przez to nie mogę zmieniać kolejności diagramów.
  • Jest event wołany po modyfikacji obiektu, no i on jest wołany po jednej modyfikacji od jednego do czterech razy. Jak zrobić porządną i szybką obsługę?
  • Po zmianie zestawu kolorów w EA, wszystkie okna dostają notyfikację. Wszystko pięknie w przypadku jego własnych okien, ale plugin nie wie, jakie kolory zostały ustawione, bo tą informację może wziąć tylko z registry, a EA zapisuje ją tam dopiero przy wyjściu z programu. No super.
  • Warto by było, żeby elementy mogły mieć więcej niż jeden stereotyp. W EA jest to, i owszem, możliwe, ale obsługa tego jest doczepiona na gumę do żucia, nawet nie pomalowaną wapnem żeby spoiny nie było widać. Więcej stereotypów można ustawić praktycznie tylko w jednym, specjalnym okienku, cholernie niewygodnym. W bazie danych jest do tego dodatkowa tabela, robiąca jeszcze pięć innych rzeczy. Lista linków w tabeli jest w polu tekstowym, polinkowane to jest przez GUID też zapisane jako string, co gorsza to stringi w hex mają pomieszane duże i małe litery, więc nie da się ich w programie obsługiwać jako klasy Guid (znaczy obsłużyć się da, ale nie można ich zapisać spowrotem bez rozwalenia linka), tylko trzeba  robić operacje na stringach. Nie mogę zrobić swojego porządnego okna do ustawiania tych stereotypów, bo nie ma API żeby poznajdować aktywne profile UML. Co za twit to powymyślał?

Bardziej złożone rzeczy:

  • Podstawowe obiekty w bazie danych to Package i Element. W bazie danych Element może mieć TaggedValues i stereotyp, Package nie. Wyraźnie w miarę rozwoju EA wymyślili jak to poprawić - do każdego Package tworzony jest ukryty Element, gdzie przyczepiane są te brakujące ficzery. Tyle że zatrzymali się w pół drogi- Package najwyższego poziomu nie ma tego Elementu, i w związku z tym nie może mieć ani stereotypu, ani TaggedValues. Dorobiłem swoje, w końcu sam operuję na tej bazie danych omijając EA, ale to nie zmienia faktu że pomysł takiego ograniczenia jest durny.
  • Żeby pokazać obiekt na diagramie jako port, taki przywiązany do brzegu komponentu, ten obiekt musi być - zgodnie z logiką - typu Port. Według AUTOSARa, pod portem jest jeszcze całe drzewo różnych obiektów. Problem jest taki, że EA bardzo ogranicza możliwe typy obiektów pod portem, próba podwieszenia tam normalnego elementu powoduje wyjątek. Udało mi się zrobić taki numer, że zmieniam typ Port na coś innego, podwieszam mu element, i przywracam typ Port. Działa, i owszem, ale tylko jeżeli ten port nie jest wyświetlany na aktualnie aktywnym diagramie. Musiałem dorobić jeszcze zamknięcie aktualnego diagramu w takiej sytuacji i otwarcie go ponownie. Pytałem o to wszystko support Sparxa, ale w ogóle nie zrozumieli problemu.

Mogę tak długo, ogólnie to musiałem zdublować dużą część funkcjonalności EA, i to jeszcze wkładając mnóstwo wysiłku żeby mój plugin i EA były cały czas synchronizowane. W sumie to trzeba by jeszcze tylko dorobić rysowanie diagramów, i wszystko było by moje. Tyle że to "tylko" to oczywiście wielka kupa roboty, ale w przyszłości trzeba będzie to zrobić.

Może jeszcze jedna historyjka z pogranicza EA i windowsów:

Typowym sposobem umieszczania obiektów na diagramach jest drag-and-drop z jakiegoś okienka z drzewem obiektów. Tak też robi się to w EA. Tyle że ja zrobiłem swoje okienko z drzewem, a upuszczać trzeba na okienko EA. Popróbowałem trochę dragdropować na bardzo różne sposoby, ale nie wyszło. Więc prowizorycznie zrobiłem menu kontekstowe z pozycją "Wrzuć do aktualnego diagramu" i to jakoś działało. Oczywiście obiekty były umieszczane wszystkie w tym samym miejscu, i trzeba je było potem przesuwać ręcznie. Zajrzałem jak zrobił to guru Bellekens, i on zrobił dokładnie tak samo - menu kontekstowe, bez dragdropa.

Ale potem zaczęło mnie męczyć: Owszem, nie daje się tego zrobić czystym windowsowym mechanizmem. Ale przecież dodaję ten obiekt do diagramu przez API, mogę też podać w którym miejscu on się ma pojawić - i tam się pojawia. Więc może nie trzeba tego robić "naprawdę" przez drag-and-drop, tylko wystarczy poudawać? Znaczy zmienić kursor myszy przy drag, potem rozpoznać czy jestem nad oknem diagramu, i po puszczeniu klawisza myszy dodać obiekt - przecież mogę mieć pozycję kursora myszy w stosunku do początku okna, a aktualne powiększenie diagramu w procentach jest w API.

No i rzeczywiście to zadziałało. Jedynym problemem było, że diagram mógł być przescrollowany i wtedy upuszczony obiekt nie trafił by na właściwe miejsce na diagramie. Ale kolega podpowiedział mi, że w Windowsach da się przeczytać pozycję scrollbarów obcego okna, i rzeczywiście się dało. No i mój udawany drag-and-drop działa super.

Do czego zmierzam: Jak niewiele trzeba, żeby w jakiejś niszy być guru. O panu Bellekensie jeszcze będzie.

I jeszcze: Zajrzałem właśnie na strony Sparxa, i tam jest o nowej wersji 16, na razie beta. Podobno będzie też jako 64-bitowa, jako podstawową bazę danych ma mieć SQLite. No to by był jakiś postęp, nawet jeżeli z udostępnionej dokumentacji wychodzi, że większość problemów które opisałem wyżej nie została usunięta. Inne pytanie, czy oni zrobią integrację tego SQLite dobrze - czy da się pisać do tej bazy równolegle tak, jak ja to robię. Na razie planuję zrobienie upgrade mojego EA na wersję Corporate - ona obsługuje też inne bazy danych, a korpo używa właśnie tej wersji. Podłączyłbym lokalnego MySQLa i bolesne ograniczenie wielkości pliku bazy danych by odpadło, pozostało by tylko to na 2GB w pamięci. A może by nawet szło szybciej. Tyle że te twity każą zakładać bazę danych i wgrywać schemat ręcznie, to ma się zmienić dopiero w tej wersji 16. Serio muszę zrobić swoje rysowanie diagramów i uwolnić się od tych twitowych narzędzi jak najszybciej.

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

Dotyczy:

Kategorie:Programowanie

Sledz donosy: RSS 2.0

Wasz znak: trackback

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


2 komentarze do “Czas nieutracony (11) – Wtyczki”

  1. charliebravo pisze:

    @hackowanie drag and dropa
    O tak, brzmi jak typowe Windowsowe sięganie lewą ręką do prawego ucha pomiędzy nogami.

    @SQLite
    Ale hej, czy ja dobrze odbieram że Ty jakoś nie lubisz SQLite’a? IMHO jest zajebisty, lekki, szybki i niezawodny. Naprawdę rzadko się zdarza _cokolwiek_ tak porządnie zrobione, a już w Open Source czy tam Free Software to jest rodzynek rodzynków.

    • cmos pisze:

      „Ale hej, czy ja dobrze odbieram że Ty jakoś nie lubisz SQLite’a?”

      Nie mam nic przeciwko SQLite, ja po prostu nie bardzo wierzę w Sparxa. Poczytałem jak wygląda multi user w SQLite i obawiam się, że Sparx nie pomyślał że ktoś może chcieć działać na ich bazie równolegle z nimi.

Skomentuj i Ty

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