Quo Vadis UML?

Język UML ma długą historię.  Jego początki sięgają połowy lat 90-tych XX w., kiedy to Grady Booch, Ivar Jacobson oraz James Rumbaugh rozpoczęli wspólne prace nad zunifikowanym językiem modelowania systemów informatycznych, który wspierałby paradygmat obiektowy. W czerwcu 1996 roku opracowana została dokumentacja języka UML w wersji 0.9.  Następnie powstało konsorcjum odpowiedzialne za rozwój UML, w które zaangażowali się tacy giganci jak HP, IBM, Oracle i Microsoft. Wynikiem współpracy był UML 1.0. W styczniu 1997 roku UML 1.0 przekazano grupie Object Management Group (OMG), która do dzisiaj zajmuje się jego rozwojem.

Pod “skrzydłami” OMG powstały wersje 1.1, 1.2, 1.3, 1.4, 1.4.2 (ta została poddana standaryzacji ISO/IEC 19501) i ostatnią wersję z gałęzi 1.x oznaczoną numerem 1.5. W czerwcu 2005 roku OMG opublikowała wersję 2.0 UML . Następnie wydała wersje 2.1.1 i 2.1.2, 2.2, 2.3, 2.4. Najnowsza oficjalna wersja UML nosi numer 2.4.1. i została opublikowana w sierpniu 2011 r., zaś znormalizowana (jako ISO/IEC 19505-1 i 19505-2) w kwietniu 2012 roku. W październiku 2012 roku pojawiała się wersja beta1 UML 2.5. Zgodnie z  informacjami podanymi przez Scotta W. Amblera należy się spodziewać w najbliższym czasie oficjalnej publikacji tej wersji standardu UML.

Nie ukrywam, że to jego materiał  zainspirował mnie do przygotowania niniejszego wpisu. Co by nie było Scott Ambler jest osobą niezwykle rozpoznawalną i liczącą się w światku software development. Jest on autorem takich książek jak: The Elements of UML 2.0 Style (2005), The Object Primer 3rd Edition (2004) oraz Building Object Applications that Work (1997). Ponadto od kilku lat próbuje on połączyć świat agile z UML – chociażby w książce Agile Modeling (2002).

Scott Ambler  w swoim materiale zauważa, że jednym z głównych celów nowej wersji UML było jego uproszczenie (w szczególności dotyczy to zapisów znajdujących się w samej specyfikacji, która w obecnej postaci jest niestrawna dla normalnego czytelnika). Sądzę, że to jak najlepszy ruch. Pamiętam czasy UML w wersji 1.5 i kiedy zestawiam ją z UML w wersji 2.4.1 – widać, że chyba twórcy tego języka zapętlili się. Z kliku rodzajów diagramów, które były w linii 1.x w wersji 2.x pojawiło się ich aż 16 typów. Swego czasu czytałem, że sami twórcy UML przyznają, że część z tych 16 rodzajów diagramów (np. diagram kompozycji struktury czy też diagram przeglądu interakcji nie była chyba nigdy zastosowana w prawdziwym projekcie; przekonać się o tym można analizując wyniki mini-ankiety przeprowadzonej przez Scotta nt. wykorzystania określonych typów diagramów UML – por. rysunek 1).

Rysunek 1. Częstość wykorzystania określonych typów diagramów UML w projektach informatycznych

Źródło: http://www.ambysoft.com/surveys/modelingDocumentation2013.html

Co wyszło z tych zapowiedzi? Pozytywne jest to, że nie zmieniła się składnia/filozofia języka. Niestety znowu wzrosła (!) liczba diagramów o 3, do 19 (por. rysunek 2).

Rysunek 2. Klasyfikacja rodzajów diagramów występujących w UML 2.5
Źródło: http://www.uml-diagrams.org/uml-25-diagrams.html

Twórcy UML postanowili dodać:

• Diagram modelu (ang. Model Diagram) – który jest specjalizacją diagramu pakietów (ang. Package Diagram)
• Diagram manifestu (ang. Manifestation Diagram), który jest specjalizacją labo diagramu wdrożenia (ang. Deployment Diagram) albo diagramu komponentów (ang. Component)
• Diagram architektury sieciowej (ang. Network Architecture Diagram), który jest de-facto diagramem wdrożenia (ang. Deployment Diagram) wysokiego poziomu.

Scott Ambler wskazuje, że z jednej strony liczba diagramów nieustannie wzrasta, ale ciągle brakuje mu np. diagramu interfejsu użytkownika albo diagramu przedstawiającego strukturę bazy danych.

Nowa wersja UML miała także poprawić interoperacyjność między narzędziami do modelowania. Ale i tutaj Scott Ambler zauważa, że chyba nie udało się osiągnąć założonych celów.

Całość materiału Scotta ma mocno pesymistyczny wydźwięk –  według niego okazuje się,  że OMG jest niezłe w realizacji działań marketingowych, ale niekoniecznie dobre w tworzeniu przydatnych dla użytkowników specyfikacji. Scott nie traci jednak nadziei, że przyjdzie taki moment, w którym UML stanie się rzeczywiście językiem pozwalającym uchwycić wysokopoziomową, architektoniczną warstwę abstrakcji.

Na koniec pozwolę sobie na mój komentarz. Uczę UML od ponad 12 lat. Mimo swoich niedoskonałości nie ma lepszego języka do opisu systemów informatycznych. Jest to standard de-facto w zakresie modelowania tej klasy rozwiązań. Ma bardzo szerokie wsparcie narzędziowe – zarówno komercyjne jak i darmowe (a pamiętam, kiedy pierwsze licencje do Rational Rose – jeszcze przed przejęciem Rationala przez IBM – potrafiły kosztować po 3-4 tysiące USD). I może to nie jest język idealny – ale w obszarze zastosowań, dla którego został on pomyślany – nie ma nic lepszego :). Natomiast jeżeli chodzi o jego efektywne wykorzystanie na poziomie “enterprise” (czyli do tworzenia modeli architektury korporacyjnej), to będziemy musieli poczekać na UML w wersji 3.0.