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

Czas nieutracony (7) – Założenia

Jak wynika z poprzedniego odcinka, podstawowym problemem MDD w praktyce jest to, że nie ma rozwiązań z półki, a zrobienie swojego rozwiązania na jeden projekt jest niezbyt opłacalne.

No ale w przypadku którym się zajmuję - czyli tego AUTOSARa - to mamy mnóstwo projektów w tym samym, dobrze zdefiniowanym środowisku! Przy projekcie dla gwiazdkowców, w tym jednym modelu samochodu urządzeń z częścią AUTOSARową było 60! Niemal każde z tych urządzeń jest robione przez osobny zespół, ale technologicznie to jest dokładnie samo! A potem następują kolejne modele, inni producenci samochodów ze swoimi modelami, powoli już prawie wszyscy wymagają robienia w AUTOSARze! Zainwestowano w niego tyle czasu i pieniędzy, że ta technologia spokojnie pociągnie jeszcze co najmniej 20 lat. A podstawowym problemem tej technologii jest brak porządnych narzędzi.

Czyli: Mamy setki projektów w dokładnie tej samej technologii - więc można by im dostarczyć rozwiązanie MDD z półki. Rozwiązanie ma poważne szanse obniżyć koszty developmentu i istotnie zmniejszyć problemy ze znalezieniem ludzi mających o tym AUTOSARze pojęcie (bo tool pomoże, nie trzeba będzie wiedzieć wszystkiego samemu). Brzmi atrakcyjnie, prawda?

A narzędzi brakuje tak drastycznie, że co i raz ponownie wypływa temat "Muszę zrobić parę diagramów z obiektami AUTOSARowymi, skąd wziąć jakieś narzędzie do tego?"

Ustaliłem więc założenia projektowe, najpierw długoterminowe:

  • Docelowo chcę wspierać całą funkcjonalność AUTOSARa związaną z tworzeniem własnych modułów. (W terminologii AUTOSARa to się nazywa AUTOSAR Authoring Tool). Całą funkcjonalność - na przykład również ten całkiem nieźle wymyślony support tworzenia dokumentacji, którego nikt na świecie jeszcze nawet nie tknął.
  • Nie będę wspierał konfiguracji modułów standardowych. Taki konfigurator musi być dopasowany do samych modułów standardowych, tylko spora firma (100+ pracowników) jest w stanie je wszystkie zrobić i supportować (a konkurencja tu jest silna).
  • Moje narzędzie ma wspierać:
    • Import, eksport i edycję plików ARXML na poziomie pojedynczych obiektów.
    • Edycję obiektów na wyższym poziomie. Chodzi o to, że żeby na przykład utworzyć AUTOSARowy odpowiednik typu wyliczeniowego, trzeba się strasznie naklikać. Idea jest taka, żeby pokazać do wypełnienia tylko okienko z istotnymi informacjami, a te dodatkowe wygenerować. Znaczy takie wizardy.
    • Asocjacje AUTOSARowe to są takie proste linki tekstowe. Program ma automatycznie robić do nich konektory w modelu, żeby bezproblemowo pokazywać je na diagramach.
    • Zrobię własne okienko managera projektu, z moją obsługą - pewnych rzeczy nie da się zrobić standardowym okienkiem EA.
    • Podobnie zrobię własne okienko do edycji atrybutów i asocjacji obiektów AUTOSARowych, bo to standardowe się nie nadaje.
  • Specyfikacja AUTOSARa nie definiuje w żaden sposób tworzenia własnego kodu. Dorobię więc moje rozszerzenie standardu, żeby było możliwe modelowanie kodu modułu powiązane z obiektami AUTOSARa.
  • Zrobię generowanie kodu statemachine kompatybilnego z AUTOSARem ze statechartu. (To bardzo istotny punkt).
  • Zapewnię możliwość szybkiej generacji ARXMLi i kodu z modelu przez CLI - żeby nie było potrzeby checkinowania plików generowanych.
  • Poważnym problemem jest porównywanie plików ARXML - kolejność obiektów w nich niekoniecznie jest taka sama przy każdej nowej wersji pliku, a ta kolejność w większości przypadków nie jest semantycznie istotna  (mógłbym zrobić długą dygresję o przyczynach mieszania kolejności w zależności od typu kolekcji w Javie używanych w różnych toolach). Porównywanie plików narzędziem operującym na poziomie tekstu (nawet przy uwzględnieniu tagów XML, na przykład przy pomocy Beyond Compare) jest często praktycznie niemożliwe. Mój program zapewni możliwość porównywania plików na poziomie obiektów AUTOSARa.
  • Pomysłów mam jeszcze wiele, niektórych nie chcę zdradzać w ogóle nikomu.

To jest oczywiście program na sporo osobolat, a ja na razie robię tylko sam (no, prawie sam) po godzinach. Więc teraz założenia pierwszego etapu, po którym ma powstać pierwsza wersja produktu nadająca się do sprzedaży:

  • Ma to być plugin do Enterprise Architecta. W dłuższym terminie zobaczymy, ale raczej trzeba będzie z niego wyjść i najlepiej zrobić coś swojego. Tak, wiem, to wielka kupa roboty.
  • Będzie to napisane w C# (musi obsługiwać COM, tylko coś od MS wchodzi w grę)
  • Pełny import/eksport plików ARXML i edycja obiektów na niskim poziomie.
  • Obsługa linków AUTOSARowych (automatyczne tworzenie connectorów EA)
  • Działające okienka mojego managera projektów i atrybutów obiektu
  • Generacja kodu, ale na razie nie ze statechartów.
  • Wywołanie generacji z CLI
  • Zewnętrzna aplikacja do porównywania ARXMLi.

Dalej w następnym odcinku.

 

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

Dotyczy:

Kategorie:Programowanie

Sledz donosy: RSS 2.0

Wasz znak: trackback

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


Skomentuj i Ty

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