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

Czas nieutracony (4) – Trigger

Następny mój projekt był dla gwiazdkowców.

Wyświetlacze S-Klasse

Wyświetlacze S-Klasse (Źródło: Materiały prasowe Daimler AG)

Tu nie był to cluster, tylko te dwa wyświetlacze, ten po prawej miał touch. Obraz dla nich był generowany przez inny kawałek sprzętu, nie od nas. Kod był w bardzo dużej części wspólny dla obu urządzeń, oba miały też mniejsze wersje dla E-Klasse.

Sytuacja rynkowa zmieniła się tymczasem:

  • Moje korpo zrezygnowało z tworzenia własnych modułów standardowych, i po prostu kupiło firmę tworzącą takie. Na największego na rynku Vektora nie mieli dość kasy, kupili drugą firmę w kolejności - Elektrobit, z ich Tresosem.
  • Korporacyjne narzędzie do ARXMLi zrobiło się abandonware, ale jest używane do dziś, bo nie ma nic lepszego do dyspozycji.
  • Vektor udoskonalił swoje narzędzie do konfiguracji modułów, ale ono jest w korpo politycznie niekoszerne. To narzędzie też jest w Eclipse. Potrafi robić również diagramy, ale w ograniczonym asortymencie i nie w UMLu.
  • Pojawiło się inne narzędzie do ARXMLi, francuskie, firmy Dassault (tak, ci od samolotów), też na bazie Eclipse, nazywa się Autosar Builder. Ładnie wygląda, ma dużo teoretycznie świetnych narzędzi, ale to niestety typowy przykład co wychodzi, gdy narzędzie tworzy ktoś, kto go nie używa. To się po prostu do niczego nie nadaje i szybko wypadło z obiegu.

Ten projekt był pierwszym w korpo, w którym użyto modułów i narzędzi od kupionego właśnie Elektrobitu. No i oczywiście to ja miałem doprowadzić to wszystko do działania. Przećwiczyłem generację projektu w różnych kombinacjach dobre kilkaset razy, zrozumiałem wszystko, doprowadziłem rzecz do działania, ale MDD nie było w tym nawet śladu.

Ale pewnego dnia pojawił się Autosar Engineer, małej firmy LieberLieber z Wiednia. Był to plugin do Enterprise Architecta. Obejrzałem go - i poczułem się poważnie ztriggerowany. A jeszcze poważniej gdy ktoś zaproponował, żeby go użyć w projekcie. Już od dłuższego czasu planowałem takie narzędzie zrobić, to miało być przecież moje!

(nie chcę linkować do stron LieberLiebera, istnieje niezerowe prawdopodobieństwo, że przez analitykę znajdą źródło linka, przetłumaczą sobie googlem i teraz oni poczują się ztriggerowani).

Wiec przyjrzałem się temu dokładniej. Oni zrobili to tak:

  • Wybrali sobie z AUTOSARa trochę co częściej używanych obiektów
  • Zrobili ręcznie profil UML i MDG Technology z tymi obiektami.
  • Lekko scustomizowali EA tak, jak on na to pozwala w łatwy sposób.
  • Dorobili parę funkcji przez API EA, parę ikonek i obrazków i tyle.

To było naprawdę mało, i to mnie ruszyło. Ponieważ miałem już sporo doświadczenia z EA (chociaż ponad 10 lat wcześniejszego) i wstępną analizę problemu już robiłem to stwierdziłem, że przecież w dwa tygodnie mogę mieć tyle samo, a w cztery coś znacznie lepszego!

Więc zacząłem. Kupiłem Enterprise Architecta (dał się odliczyć od podatku 🙂 ) wziąłem Visual Studio Community Edition i ostro ruszyłem. W Javie napisałem wczytanie danych z metamodelu AUTOSARa, zagenerowałem z tego pliki profili i technology dla EA i w C# porobiłem trochę potrzebnej funkcjonalności jako plugin EA.  Całość nazwałem dumnie MaximumAUTOSAR, że niby ma to być docelowo AUTOSAR to the max. W cztery tygodnie faktycznie miałem coś o wiele lepszego niż ten LieberLieber, ale oprócz tego bardzo istotny wniosek - że tak zrobione, to nigdy nie będzie dobre. Z dwóch przyczyn:

  • Pierwsza to braki w API EA. Paru absolutnie podstawowych rzeczy nie dało się zrobić customizując ich standardowy Project Manager i inne okienka.
  • Druga leżała po stronie AUTOSARa i mojej. Moim założeniem było że wezmę sobie metamodele udostępniane przez konsorcjum i przetransformuję je programowo na pliki profilu/technologii EA. I tu nie doceniłem problemu. Szczegóły w następnych odcinkach.

Tak więc pojawiło się prawdziwe wyzwanie - nikt na świecie dotąd nie zrobił odpowiedniego narzędzia do AUTOSARa, i nie wyglądało żeby ktoś - poza mną - był w stanie to zrobić. Padł na tym nawet IBM, a wszyscy inni ograniczali się do rozwiązań bazujących na Eclipse (nie bez przyczyny - o tym dalej). A w Eclipse nie za bardzo da się zrobić modeling tool (chociaż niektórzy próbują, na przykład coś takiego).

A dlaczego nikt poza mną ma nie być w stanie? Bo to jest tak:

  • Fachowcy od takich narzędzi nie mają pojęcia o AUTOSARze i nigdy nie robili aktywnego developmentu w tej działce (to był przypadek IBMa i Dassault), stąd nie wiedzą, co jest naprawdę potrzebne i jak to ma działać.
  • Fachowcy od AUTOSARa nie mają pojęcia o robieniu takich tooli (cała reszta próbujących).

I na placu boju pozostaję ja, cały na biało.

Oprócz tego wkrótce LieberLieber wywalił cały ten projekt do kosza, więc na boisku zostałem prawie sam. Prawie, bo jest jeszcze jeden team: jacyś ludzie zrobili support AUTOSARa w MatLabie. Umieją wczytywać i wypisywać te ARXMLe i cośtam z tego generować. Na szczęście nie są oni dla mnie prawdziwą konkurencją, bo MatLab zasadniczo nie umie w UMLa i design (on nie do tego został wymyślony), i prawdziwe MDD to to jednak nie jest.

Ciąg dalszy oczywiście nastąpi.

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

Dotyczy:

Kategorie:Programowanie

Sledz donosy: RSS 2.0

Wasz znak: trackback

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


5 komentarzy do “Czas nieutracony (4) – Trigger”

  1. igor pisze:

    Miałem bardzo niewielki kontakt z Eclipse, a i tak mnie wzdryga za każdym razem jak o nim piszesz. A zwłaszcza perspektywa używania kilku różnych narzędzi bazujących na Eclipse jednocześnie. Podejrzewam, że osoby z branży będą zainteresowane Twoim softem już z tego powodu, że nie korzysta z Eclipse.

  2. janekr pisze:

    Może nie katastrofą, ale dużą niedogodnością jest używanie dwóch wersji eclipse do dwóch projektów, które są luźno powiązane.
    Przy pomocy eclipse tworzę formularze webowe, które wywołują raporty BIRT. Wstawki programistyczne są w java.
    A raporty tworzę przy pomoce eclipse w specjalnej wersji BIRT, przy czym wstawki programistyczne są w javascript.
    Do tego na dwóch różnych komputerach (linux i windows), przy czym do obu wchodzę zdalnie z trzeciego.

    • cmos pisze:

      U nas to nie tylko są „dwie wersje Eclipse”, tylko „dwa produkty na bazie Eclipse”, rozszerzające bazę w różny sposób, i one nie będą działać na jednym workspace, chociażby nie wiem co. Synchronizacja tych workspace dodaje mnóstwo upierdliwości do projektu. Wszyscy chcieliby z tego wyjść, ale na razie nie ma jak.

  3. dobiasz pisze:

    O, to wygląda znajomo 😀

Skomentuj i Ty

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