Model stroi miny

Pomysłów na modelowanie przybywa, co można odczytać jako dążenie do doskonalenia aplikacji. Niestety, wiele problemów z aplikacjami ma z jakością czy łatwością modelowania związek raczej luźny.

Pomysłów na modelowanie przybywa, co można odczytać jako dążenie do doskonalenia aplikacji. Niestety, wiele problemów z aplikacjami ma z jakością czy łatwością modelowania związek raczej luźny.

Pytanie, w jaki sposób modelować aplikację, często kryje w sobie pytanie o to, co zrobić, by pisać lepsze, a więc np. bardziej niezawodne i skalowalne oprogramowanie. Trzeba od razu zaznaczyć, że nawet najdoskonalszy model nic w tej materii nie gwarantuje. Z drugiej strony, pewien związek niewątpliwie jednak istnieje.

Jeśli umiejętnie połączy się model, kod, wspomoże proces produkcji dodatkowymi narzędziami czy bogatym IDE - liczba linii kodu do napisania "ręcznie" znacznie maleje. To zaś niewątpliwie oznacza mniej błędów w oprogramowaniu, a przy okazji zostawia więcej czasu w projekcie na jego testowanie.

Rozwój myślenia na temat modelowania aplikacji ciągle podlega różnym ewolucjom, co znajduje swoje odbicie w zawartości narzędzi do modelowania i ich powiązaniach z pakietami do tworzenia kodu.

Kłopot z biegiem wstecznym

Jednym z najczęściej stosowanych metod modelowania jest zastosowanie tzw. architektury MDA, czyli Model Driven Architecture. To bardzo formalne podejście do tworzenia modelu i aplikacji opracowane i licencjonowane przez OMG (Object Management Group). Ta metodologia modelowania wykorzystuje koncepcje oparte na formalnym języku opisu modelu - UML (Unified Modelling Language).

W pierwszym etapie prac prowadzonych zgodnie z MDA powstaje CIM (Computation Independent Model). Jest to metoda wyrażenia kształtu rozwiązania informatycznego w języku biznesowym. W ten sposób teoretycznie udowadniamy, że "znamy", czy też "rozumiemy" biznes, klient zaś może uświadomić sobie lepiej to, co dokładnie będzie realizowane w ramach projektu.

Według MDA na podstawie CIM powstaje PIM - czyli Platform Independent Model. Ten model pokazuje jak system informatyczny będzie konstruowany, ukrywa natomiast wszystkie szczegóły techniczne, które na tym etapie są nieistotne. Dopiero na podstawie modelu PIM może powstać (jeden lub więcej) PSM - Platform Specific Model - model dostosowany do konkretnej technologii i zawierający symbole odpowiadające konkretnej platformie. Na podstawie PSM może być generowany kod - przy użyciu jakiegoś narzędzia, np. Select, IBM Rational, Sybase PowerDesigner czy Borland Together.

Z punktu widzenia aplikacji wspomagających takie modelowanie praktycznie nierozwiązany jest problem przejścia w drugą stronę. Narzędzia, które pozwolą przejść od modelu PSM do PIM, a potem do CIM zwykle po prostu nie działają - na każdym z tych etapów trzeba ręcznie usuwać pewne szczegóły techniczne, decydować o mapowaniu, czy dodawać do modelu PSM sygnatury wskazujące, jakiemu elementowi PIM odpowiada dana klasa czy funkcja.

Interesującym podejściem do tego problemu jest to, które Microsoft zawarł w Visio, czy też to, które można znaleźć w narzędziu Borland Together dla Visual Studio .Net. W obu tych przypadkach informacje potrzebne do synchronizacji modeli w obie strony zawarte są po prostu w komentarzach - które niestety użytkownik może zmienić. Drugi, trochę prostszy problem to aktualizacja. Jeżeli zmieniają się warunki biznesowe, to (w naturalny sposób) uaktualniamy model CIM, PIM i PSM. Jednak wielokrotnie dzieje się to dużo później po rozpoczęciu projektu, kiedy duża część aplikacji została już napisana. Trzeba więc uaktualnić kod, a tu bez ręcznej synchronizacji zmian się nie obejdzie.

Zawiłości formalne

Pomimo wszystkich niedogodności, CIM jest modelem użytecznym, dlatego byłoby dobrze, gdyby można go było zapisać w języku zrozumiałym dla klienta, a nie w UML. Oczywiście, można wskazać przypadki, w których abstrakcyjność modelu CIM opartego na języku UML jest zaletą, np. w projektach wielonarodowych, w których kilka korporacji realizuje jedno zadanie. W pozostałych przypadkach "lokalnych" - już niekoniecznie.

W typowym projekcie znacznie lepiej sprawdziłby się prawdopodobnie "zwykły" język uniwersalny (nawet j. angielski, w projekcie międzynarodowym) - oczywiście przy zastosowaniu pewnej ustalonej struktury dokumentów, krótkich zdań, słowników składni itp. Tym bardziej, że pewne pojęcia z UML, np. przypadek użycia, sekwencja, aktor, sposób opisu procesów itp. przeszły do "normalnego" języka i są powszechnie używane bez "formalizmów" rodem z OMG.

Można się z takim punktem widzenia nie zgadzać, bo przecież "liczą się zasady", niemniej nie można nie zauważyć, że UML w praktyce projektowej bywa często "sztuką dla sztuki". Klienci często sądzą, że gdy dostawca przedstawia im formalny model aplikacji w UML, jest to dowód na to, że dołożył on należytej staranności. Dostarczenie modelu to niewątpliwie wartościowa sprawa, ale...

Pierwszy problem jest taki, że klient sam zwykle nie jest w stanie wiele wyczytać z modelu UML - do tego potrzebna jest biegłość, której zazwyczaj nie posiada. W konsekwencji prawdziwa weryfikacja wzajemnego porozumienia dostawcy i klienta co do kształtu aplikacji prawie nigdy nie następuje. Po drugie, w tym samym języku UML zapisywane są projekty aplikacji bardzo dobrych, ale także słabych, czy wręcz złych. Dodatkowo, o ostatecznym efekcie prac przesądza bowiem nie sam model, ale jego poprawna implementacja w kodzie, a z tym bywa bardzo różnie.

Pozorne zyski z PIM

Przytaczany przez OMG raport EDS pokazuje, że model PIM pozwala niemal natychmiast przenieść projekt pomiędzy różnymi wersjami J2EE (przykład dotyczył migracji EJB 1.1 a EJB 2.0). Pytanie, czy w dzisiejszych warunkach - poza projektami największymi - ktokolwiek bierze serio pod uwagę pełną niezależność od platformy.

Wyśrubowane terminy wymagają korzystania z efektywnych narzędzi i funkcji ułatwiających projektowanie, kodowanie i testowanie, a te są zwykle związane z konkretną platformą aplikacyjną czy bazodanową. Każda platforma zawiera zwykle olbrzymią liczbę obiektów pomocniczych i API użytkowego i te składniki w jakiś sposób muszą być reprezentowane podczas modelowania. Rezygnacja z nich stawia pod znakiem zapytania korzyści wyboru tej, a nie innej platformy. Poza tym w zdecydowanej większości projektów platforma jest znana z góry i wiele uwagi poświęca się na wybranie takiej, która ma szanse trwać wiele lat - by jej nie zmieniać.

Praktyczną niezmienność platformy odzwierciedla także fakt, że przypadki przenoszenia tej samej aplikacji na inną platformę (zamiast pisania jej od nowa) są w sumie rzadkie. Zawsze powstaje pytanie o koszty, bo przejście pomiędzy PIM a PSM jest wyzwaniem. Być może więc PIM w ogóle nie ma sensu - może lepiej od razu tworzyć model uwzględniający konkretną technologię, pamiętając jednak o stopniu trudności migracji konstrukcji z J2EE na .Net i odwrotnie.

Narzędzia zgodne z ideą MDA nie obsługują zwykle tzw. dynamiki aplikacji, ograniczając się zwykle do statycznego modelu klas. Tymczasem tu czają się prawdziwe problemy. Przykładowo, następstwo zdarzeń, fakt np. używania mechanizmów refleksji itp. nie mogą być w prosty sposób wyrażone w modelu. Rational i Together obsługują tzw. diagramy sekwencji - pokazujące w jakiej kolejności pewne kluczowe algorytmy są realizowane. Ale już np. przełożenie takich diagramów na kod wcale nie jest proste i nie gwarantuje dobrej realizacji zamysłu projektanta. A "reverse engineering" w tym przypadku jest bardzo trudny.

Tu też pojawia się bardziej ogólne pytanie: czy na pewno kod i model powinny być natychmiast synchronizowane. Jeżeli patrzymy na diagram jako na inny sposób wizualizacji kolejnych poleceń w danym języku programowania - to tak. Ale model z założenia jest czymś, co tworzymy zanim powstanie kod i co narzuca kształt naszego systemu. Poza tym model z natury rzeczy jest uogólnieniem ukrywającym nieistotne szczegóły i choćby z tego powodu powrót z implementacji do modelu nie jest trudny.

Microsoft Visual Studio .Net 2005 bez UML

W Visual Studio .Net 2005 Microsoft zrezygnował z MOF (Metadata Object Framework) - koncepcji zbyt abstrakcyjnej, która dodatkowo i tak musiałaby być mapowana na konkretne elementy pakietu Visual Studio .Net 2005 i samego .NET Framework. Nie będzie wspierać UML, uważając tę specyfikację za zbyt trudną w stosunku do zalet, jakie mogłaby oferować (dodatkowo - nie bardzo wiadomo, w jaki sposób pokazać kilka nowych elementów C# 2.0). W zamian Microsoft oferuje własny sposób prezentacji diagramu klas - używając niektórych symboli stanowiących część UML. Ale już np. Borland zapowiedział, że w ramach narzędzia do modelowania DSL opracuje wsparcie dla najnowszej wersji UML 2.0.

Wzorce i refaktoring - kij ma dwa końce

Wzorce projektowe i mechanizmy refaktoringu są bardzo przydatnymi mechanizmami, ale jak każde "dzieło" mogą mieć błędy. Podobnie ma się rzecz z generatorami kodu - zarówno tymi działającymi na podstawie modelu, jak i innego metajęzyka. U jednego z producentów liczących się narzędzi do refaktoringu wzorzec Singletona (chyba najprostszy z wzorców projektowych) generowany w C# zawiera błąd...

W konsekwencji, mimo zaufania do producenta narzędzi, trzeba dokładnie sprawdzić poprawność działania produktu. Jeżeli bowiem na podstawie modelu powstaje, powiedzmy, 60% kodu, to okaże się, że błędy będą właśnie w tej większej części aplikacji i zamiast ułatwić, generator skomplikuje proces tworzenia oprogramowania. Dodatkowo należy pamiętać, że większość narzędzi pozwala programiście samodzielnie definiować, jak będzie dokonywana transformacja konkretnego artefaktu w kod - i tu też można popełnić pomyłkę.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200