Fragment opublikowanego artykułu:
Stanisław Niepostyn, Ilona Bluemke, Modeler modelu przestrzennego DOD w środowisku Topcased, Metody Informatyki Stosowanej nr 2/2009 (19), s. 81-91, Polska Akademia Nauk Oddział w Gdańsku, Komisja Informatyki, ISSN 1898-5297.
Projekt TOPCASED (Toolkit In OPen-source for Critical Application & SystEms Development) powstał w celu redukcji kosztów wytwarzania oprogramowania, które wspiera różnorodne dziedziny inżynierii procesów. Animatorem projektu Topcased była firma Airbus, która w 2004 roku utworzyła wraz z innymi znanymi firmami zespół projektowy, a wynik prac owego zespołu został zaprezentowany w 2005 roku w formie oprogramowania typu „open source”. Projekt Topcased jest środowiskiem otwartym, gdzie programiści, testerzy i użytkownicy końcowi razem opracowują narzędzia niezbędne do opisu procesów, oprogramowania, czy też infrastruktury nie tylko IT. Rozwiązania proponowane przez Topcased mają na celu zautomatyzowanie czynności związanych z rozwojem szerokiej gamy procesów od fazy projektowej (analitycznej) aż do fazy produktu końcowego. Produktem końcowym może być tu zarówno model określonego systemu jak i gotowe oprogramowanie. W ogólności projekt Topcased znacznie ułatwia czynności przy analizie i projektowaniu systemów, symulacji tych systemów, transformacji modeli pomiędzy poszczególnymi rodzajami ich reprezentacji, automatycznemu sprawdzaniu zgodności funkcjonalności systemów z założeniami oraz tworzy gotowy kod źródłowy wraz ze stosownymi testami oraz dokumentacją.
Środowisko Topcased oparte jest na projekcie eclipse. W niniejszym artykule opisano środowisko Topcased w aspekcie automatyzacji większości czynności, jakie należy wykonać w środowisku EMF oraz w środowisku GEF, by wygenerować aplikację MDA z własnego metamodelu. Automatyzacja ta jest możliwa ponieważ środowisko Topcased integruje ze sobą projekty EMF i GEF udostępniając równocześnie oba te frameworki. Poniżej opisano w skrócie oba te środowiska.
Środowisko Eclipse Modeling Framework zostało zaprojektowane do uproszczenia procesu projektowania, implementacji i uruchamiania aplikacji opartych na metamodelu danych zgodnie z postulatami Model Driven Architecture. Na podstawie modelu danych opisanych w pliku XML w środowisku EMF można utworzyć narzędzia oraz środowisko uruchomieniowe (ang. runtime support) obsługujące model danych. W szczególności można budować klasy adaptera (wzorca projektowego) do przeglądania i edycji modelu. Edytor taki można następnie wzbogacać o przeróżne funkcje implementując w edytorze odpowiedni kod w języku Java. Główną ideą wykorzystania tego środowiska (Rysunek 1) jest możliwość zdefiniowania metamodelu (np. UML Model, XML Schema, Relational Database Schema, Java Annotations), wygenerowania odpowiedniego modelu z tego metamodelu (ang. Core Model), standardowa serializacja wszystkich zmian wykonanych w tym modelu oraz wygenerowanie kodu implementacyjnego Javy (bądź wygenerowaniu innych modeli). Wygenerowana aplikacja w tym środowisku oparta jest na standardowym edytorze TreeView toteż nie jest zbyt wygodna do modelowania np. procesów biznesowych.
Rysunek 1 Wewnętrzny (core’owy) model środowiska EMF [3]
Powyższą niedogodność można zniwelować wprowadzając odwzorowania graficzne poszczególnych elementów projektowanego modelu. Funkcjonalność tą zapewnia środowisko Graphical Editing Framework (GEF), które umożliwia utworzenie szkieletu edytora (bądź innej aplikacji) do graficznej reprezentacji istniejącego modelu danych (np. utworzonego w środowisku EMF). Elementy graficzne takiego edytora wykorzystują środowisko Draw2D (org.eclipse.draw2d), które to środowisko jest standardem wywodzącym się z biblioteki SWT z eclise.org. W takim edytorze można np. graficznie wiązać ze sobą elementy poprzez używanie graficznej reprezentacji poszczególnych elementów modelu danych. Edytor taki można następnie wzbogacać o przeróżne funkcje wprowadzając do kodu tego edytora swój własny kod w języku Java (przystosowanie kodu do własnych potrzeb).
Środowisko GEF wykorzystuje architekturę MVC (ang. Model-View-Controller), dzięki której zmiany w warstwie modelu dokonuje się poprzez warstwę widoku. Poniżej opisano powyższy mechanizm wykorzystywany przy budowie edytorów graficznych w środowisku Graphical Editing Framework - Rysunek 2.
Kontroler jest połączeniem pomiędzy widokiem (ang. View), a modelem (ang. Model). Każdy kontroler (zwany również w środowisku GEF elementem EditParts) jest odpowiedzialny zarówno za wiązanie obiektów modelu z obiektami graficznymi widoku jak i za wprowadzanie zmian z widoku do modelu. Element EditParts jest również Obserwatorem (wzorzec Obserwator), który wykonuje zmiany w widoku (View) w zależności od stanu modelu (Model).
Rysunek 2 Architektura aplikacji GEF w środowisku Topcased [3]
Na Rysunek 2 przedstawiono architekturę aplikacji GEF. Warstwa Layers pozwala zobrazować model za pomocą elementów środowiska GEF (wizualizacja elementu RootEditPart). Część edytora GEF zwana EditPartViewer odpowiedzialna jest za zainstalowanie jednego widoku danego modelu na kanwie SWT Control. Ponadto EditPartViewer zachowuje mapowanie obiektów modelu w odpowiadające im części struktury drzewiastej RootEditPart. Za utworzenie odpowiedniego powiązania obiektu modelu danych z elementem kontrolera EditPart odpowiedzialny jest interfejs EditPartFactory. Podobnie rzecz się ma z mapowaniem elementów RootEditPart, a odpowiadającym im elementom graficznym SWT Control. W tym przypadku również stosuje się interfejs EditPartFactory.
Na Rysunek 3 przedstawiono proces tworzenia edytora klasy EMF. Do zdefiniowania metamodelu należy użyć odpowiedniego narzędzia środowiska EMF (GenModelWizzard), które można „zasilić” odpowiednim metamodelem zaprojektowanym w różnych formatach. Tak zdefiniowany metamodel posiada reprezentację specyficzną w środowisku eclipse - Eclipse Core Model (Ecore) - zarówno w formie graficznej (diagram klas) jak i w formie pliku XMI.
Rysunek 3 Proces tworzenia aplikacji klasy EMF [3]
Kolejnym etapem procesu generowania edytora klasy EMF jest wygenerowanie modelu generatora tzw. GenModel, który posiada dodatkowy opis niezbędny do utworzenia edytora w środowisku eclipse (np. odpowiednie ścieżki do projektu eclipse, właściwości elementów zdefiniowane dla platformy docelowej itd.). Wygenerowany GenModel można następnie modyfikować za pomocą GenModel Edytora. Po dostosowaniu GenModelu do własnych potrzeb można następnie wygenerować odpowiedni edytor (o strukturze drzewa – TreeView Editor) w formie wtyczki, czy też można nawet wygenerować plik z modelem, który z kolei można wykorzystać w innych narzędziach. Wygenerowana aplikacja w formie TreeView nie jest zbyt dogodna do modelowania, toteż dopiero wizualizacja obiektów modelu do postaci edytowalnych elementów graficznych znacznie zwiększa atrakcyjność zaprojektowanego narzędzia do modelowania.
Na Rysunek 4 pokazano proces generowania edytora graficznego właściwy dla środowiska Topcased. W procesie tym wykorzystywany jest GenModel uzyskany w trakcie tworzenia edytora klasy EMF. Pierwszym etapem procesu jest wygenerowanie konfiguratora dla modelu (ConfiguratorModel) za pomocą narzędzia ConfiguratorWizzard. Kolejną czynnością jest przyłączenie do konfiguratora, za pomocą edytora konfiguratora (Configurator Editor), GenModelu otrzymanego w procesie EMF . Następnie konfigurator należy wypełnić odpowiednimi wartościami dla docelowego edytora graficznego (wiązanie modelu z elementami sterującymi oraz z elementami graficznymi – patrz Rysunek 2).
Rysunek 4 Proces tworzenia aplikacji klasy GEF w środowisku Topcased [3]
Odpowiednio skonfigurowany ConfiguratorModel jest podstawą do wygenerowania szkieletu edytora graficznego (Generator Topcased). Szkielet ten (Edytor Graficzny [Wygenerowany]) można następnie ulepszać już w samym Edytorze (modyfikacja kodu Java), przy czym zmiany natychmiast są widoczne w instancji Edytora Graficznego. Taki sposób budowy edytora graficznego pozwala uniknąć wykonywania przeróżnych czynności związanych z „ręcznym” projektowaniem i implementacją klas w projektowanej aplikacji (automatyzacja czynności wymaganych w środowisku Graphical Modeling Framework). Należy zauważyć, że automatyzacja takich programistycznych kroków pozwala znacznie obniżyć poziom błędów wprowadzanych przez programistów do kodu aplikacji.
LITERATURA
[1] http://www.eclipse.org
[2] Randy Hudson, Create an Eclipse-based application using the Graphical Editing Framework. How to get started with the GEF, 29 July 2003 – artykuł
[3] Topcased Team, Topcased Specification and Architecture v1.170, TPC-SPE-DESIGN-029, dokumentacja na www.topcased.org
| 
