Model specjalizowany

Kolejna kwestia dotyczy tego, że tak naprawdę MDA przydaje się, ale "tylko" (lub aż - to zależy od aplikacji) do generowania logiki biznesowej i ewentualnie warstwy pośredniczącej w komunikacji z bazą danych. Jeśli natomiast chodzi o interfejs użytkownika, architektura MDA jest niemal bezużyteczna. Oczywiście, zawsze można coś tam wygenerować, ale obecnie użytkownicy są tak przyzwyczajeni do bardzo bogatych, intuicyjnych w użyciu interfejsów, że takie "surowe" automatycznie generowane interfejsy są powodem do narzekań. Stąd właśnie coraz większa rola języków typu DSL (Domain Specific Language).

O ile MDA zakłada jeden sposób wyrażania modelu, w architekturze DSL przyjmuje się, że powstają specjalistyczne języki przeznaczone do realizacji konkretnych zadań. Taki język nie musi być kodem w ścisłym tego słowa znaczeniu, ale np. - diagramem pokazującym strukturę aplikacji. Ta idea jest bardzo stara i dosyć dobrze rozpowszechniona w informatyce, choć sama nazwa DSL została rozpropagowana stosunkowo niedawno.

Gama języków specjalistycznych jest naprawdę olbrzymia. Dostępne są np. rozwiązania, takie jak PLAN-P - język przeznaczony do implementowania protokołów sieciowych i generalnie algorytmów związanych z komunikacją. W tym języku można zdefiniować np. wirtualny serwer WWW z wbudowanym wyrównywaniem obciążeń. Liczba linii kodu potrzebnych do jego implementacji jest naprawdę niewielka. Innym przykładem jest język GAL upraszczający pisanie sterowników do kart graficznych, czy Devil - do tworzenia oprogramowania w systemach wbudowanych (embedded). Dostępne są też języki do pisania interfejsu, np. XScene, czy np. wspierające konstrukcję logiki gier (XGame-RPS).

Podstawowym problemem w tego typu językach jest zupełny brak wsparcia ze strony IDE - do najbardziej zaawansowanych narzędzi dla takich języków należą edytory tekstu pozwalające na podświetlanie składni innym kolorem. Jest jednak nadzieja - pewne inicjatywy w tym względzie pojawiły się ostatnio w ramach projektu Eclipse. Dużym odrodzeniem języków typu DSL będzie na pewno Visual Studio .Net 2005 (obecnie jeszcze w wersji beta, premiera jesienią br.). Pakiet ten zawiera specjalne komponenty, które pozwalają tworzyć edytory dla języków specjalistycznych.

Pakiet SDK dla Visual Studio .Net 2005 pozwala stworzyć narzędzia, które w pełni zintegrują się ze środowiskiem - będą mogły definiować własne zachowanie przy kasowaniu elementów, operacjach kopiuj/wklej, praktycznie wszystkich elementach zawartych w Visual Studio .Net 2005, i jakie może potem użyć programista tworząc kod. Z nowym pakietem Microsoftu dla każdego języka będzie można zdefiniować oddzielne narzędzia do modelowania, albo też powiązać jedynie z mechanizmem tworzenia diagramów, na podstawie których parser sam wygeneruje kod. Aby tworzyć język DSL, będzie potrzebna wersja Visual Studio .Net 2005 Professional, zaś aby go używać - wystarczy wersja Standard.

Nadzieje w nowej generacji

Można też podejść inaczej do zagadnienia automatyzacji tworzenia "żmudnych" elementów aplikacji. Na rynku dostępnych jest bardzo dużo generatorów, które na podstawie schematu bazy generują warstwę dostępową, albo też np. dysponując listą pól pozwalają stworzyć gotowy szkielet interfejsu aplikacji. W ten sposób mamy wyeliminowane tworzenie powtarzających się czy podobnych fragmentów kodu.

Dostępne są uniwersalne generatory - np. CodeSmith, Velocity, nGen (czy w pewnym sensie MetaL), które na podstawie pewnych informacji (m.in. struktura tabel, kolejne rekordy, ciąg właściwości podanych przez programistę itp.) i skryptu (w CodeSmith przypominającym skrypty ASP) generują dowolny kod. Może to być kod Java, C# czy nawet aplikacja PHP.

Nie ma tu żadnych ograniczeń - generatory są parserami, które mają własny dialekt i wiele interfejsów do zasilania zewnętrznymi danymi. Czasami takie generatory mają też pewne IDE do projektowania, jak np. IronSpeed czy najnowszy CodeSmith. Oczywiście, pod spodem zawsze działa jakiś język makrodefinicji generujący kod na podstawie wzorca. Warto dodać, że np. Velocity pozwala łatwo oddzielić kod Javy "biznesowy" od kodu używanego do obsługi interfejsu użytkownika. Dostępne są też całe środowiska, jak np. rozwijany od 15 lat deKlarit, zawierające modeler do tworzenia encji, na podstawie których potem generować można tabele bazy danych, interfejs użytkownika, a nawet interfejs administracyjny. Dzięki ograniczeniom nałożonym na encje, warunkom poprawności itp. można wygenerować aplikację, która od razu spełni określone wymagania biznesowe.

Prawdziwą zmianę jakościową daje dopiero połączenie generatora kodu z językiem DSL. Wtedy będziemy mieli swoisty metajęzyk, w którym wyrazimy to, co ma zostać wygenerowane. Takie środowiska już w tej czy innej postaci istnieją. Jeżeli da się opracować dla nich wsparcie ze strony środowiska IDE, będzie można łatwo "wrócić" do generatora, coś poprawić i kontynuować pracę nad resztą aplikacji. Obecnie największą bolączką generatorów jest fakt, że jeżeli raz się wygeneruje jakiś szkielet i wykona w nim zmiany "ręcznie", zwykle nie da się dokonać częściowej ponownej generacji zmienionego fragmentu - trzeba zaczynać od nowa, tworząc pełen kod.

Refaktoring i wzorce

Źródłem błędów i problemów z aplikacjami od zawsze był kod i zapewne tak już pozostanie. Aby minimalizować problemy, powstało wiele tzw. wzorców projektowych - rozwiązujących w optymalny sposób typowe problemy powstające podczas kodowania aplikacji. Powstały też mechanizmy transformacji, które pozwalają przekształcić kod do innej, analogicznej postaci, charakteryzującej się lepszą strukturą obiektową (tzw. refaktoring kodu).

Operacją refaktoringu może być np. zmiana nazwy metody (także - we wszystkich miejscach, gdzie ta metoda jest używana), czy np. przeniesienie funkcji do klasy nadrzędnej, rozbicie skomplikowanego wyrażenia na kilka mniejszych itp. Refaktoring to wyrafinowany mechanizm "znajdź i zastąp". Można nań jednak spojrzeć inaczej: skoro tak bardzo rozpowszechnił się jako wygodne narzędzie, to może umożliwi także szybkie pisanie kodu?

Przykłady już są. Ze środowiskiem IDE można np. zintegrować narzędzie, które w zależności od tego, w jakim miejscu znajduje się kursor, po naciśnięciu kilku znaków automatycznie wygeneruje duży blok kodu. Tu chyba najlepszymi przykładami są CodeRush (.Net) czy CodeSmart (VB6 i .Net) - za ich pomocą można definiować takie wzorce i potem np. napisać tc<spacja>, co przełoży się np. na blok "try catch" wstawiony w danym miejscu.

Gdzie jest postęp

Podsumowując, obecnie bardzo rośnie rola IDE - czasy aplikacji pisanych w "edytorze tekstu" odeszły do lamusa. IDE musi mieć nie tylko debugger, ale także mechanizmy projektowania i modelowania aplikacji, transformacji kodu, narzędzia do testowania, oferować narzędzia do współpracy programistów itp. W konsekwencji, IDE nie jest już produktem tylko jednej firmy - zwykle ma bardzo rozbudowany mechanizm tworzenia rozszerzeń, czego dobrymi przykładami są zarówno Eclipse, jako i Visual Studio .Net.

Z biegiem czasu będzie można pójść jeszcze dalej, w kierunku opracowywania wzorców dla konkretnych typów aplikacji. Jeśli można wykorzystywać gotowe zestawy kontrolek dla interfejsu użytkownika, można wyobrazić sobie bibliotekę komponentów specyficznych, np. dla branży farmaceutycznej. Ta koncepcja pojawia się w literaturze od mniej więcej dwóch lat pod nazwą "Software Factories" czy też "Software product lines", a więc branżowych zestawów bibliotek, narzędzi projektowych czy języków modelowania.

Prace nad tymi mechanizmami trwają w wielu firmach, m.in. Nokia, Unisys, Nationwide czy Siemens. Ich rozwiązania przypominają koncepcyjnie np. Business Accelerators do tworzenia analiz dla danej gałęzi przemysłu oferowanych przez wielu producentów narzędzi BI. Część z tych mechanizmów będzie realizowana w ramach obsługi DSL w Visual Studio .Net 2005.

Idea Software Factories na pewno pozwoli uprościć pisanie aplikacji dla branż. Należy jednak podkreślić, że klasyczny refaktoring i wzorce projektowe to mechanizmy proste i uniwersalne, do zastosowania w sytuacjach, w których kod wejściowy ma określoną strukturę. W przypadku Software Factories tak nie będzie, pojawia się zatem pytanie, czy z punktu widzenia producentów aplikacji taki framework rzeczywiście coś ułatwi na dłuższą metę.