sty
01

Quo Vadis UML?

Źródło: Andrzej Sobczak
Print Friendly

kompasJę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).

diagramy_popularnosc

 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).

 

UML 2.5 Diagrams Taxonomy.

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.

Andrzej Sobczak

Profesor, kierownik Zakładu Zarządzania Informatyką w Instytucie Informatyki i Gospodarki Cyfrowej SGH. Ma ponad 8 letnie doświadczenie we wdrażaniu koncepcji architektury IT i architektury korporacyjnej. Posiada certyfikaty TOGAF 8/9, ArchiMate 2.0, ITIL, MSP.

Polecane wpisy

TAGI DLA WPISU

Dyskusja do artykułu “Quo Vadis UML?

  1. Także śledzę rozwój UML i zaczynam dostrzegać pewną prawidłowość, która mi się “podoba”, a mianowicie upraszcza się system pojęciowy (wszystko jest klasą i ich związkami), diagramy (typy diagramów) postrzegam raczej jako odrębne perspektywy i wyróżnione poziomy abstrakcji, a co za tym idzie także pewne określone profile (aktor to klasa o stereotypie <>). Osobiście nie widzę sensu pakowania do UML modelowania baz danych bo to implementacja, nie jedyna, utrwalania obiektów (UML to system pojęciowy oparty na obiektowym paradygmacie). UML to język modelowania, budowanie abstrakcji, a nie język programowania (osobiście jestem sceptykiem w kwestii generowania kodu z modeli UML, nie licząc szkieletu tego kodu). Co do tego jak często są używane poszczególne diagramy to wynik ankiety, w mich oczach, raczej świadczy o poziomie radzenia sobie z OOAD a nie przydatnością poszczególnych diagramów. Np. diagram sekwencji jest bardzo przydatny (bo jak inaczej sprawdzić logikę realizacji przypadków użycia??), zaś diagram klas ma wiele zastosowań (modele pojęciowe, struktury kodu, bardzo często (niestety) modele danych, inne – nieinformatyczne – systemy, nie dziwię się, że zajął pierwsze miejsce.

  2. Zaciekawiły mnie wskazane ‘nowe’ diagramy dodane w najnowszej wersji języka. Próbowałam znaleźć je w specyfikacji języka UML. Niestety bezskutecznie.
    Proszę o informację gdzie w oficjalnych dokumentacjach mogę znaleźć przedstawione informacje.
    Z góry dziękuję za pomoc.

    Uwaga do komentarza powyżej:
    Actor nie jest klasą ze stereotypem. Składnia abstrakcyjna języka UML wprowadza metaklasę Actor, która dziedziczy po klasyfikatorze (dokładnie po BehavioredClassifier), nie klasie. Uwzględniona notacja ‘klasy ze stereotypem’ jest zaproponowaną w specyfikacji notację dla klasyfikatorów w ogólności, gdzie słowo ‘Actor’ jest słowem kluczowym, a nie stereotypem.

    • Moja odpowiedź: owszem aktor dziedziczy ale na modelu pojęciowych (Superstructure Figure 16.2 Concepts used for modeling…) ale jako klasa (obiekt na diagramie) jest to element modelu – klasa, jest klasą (klasyfikatorem) o stereotypie <> (Superstructure 16.3.1. Actor). Model pojęciowy pojęć (concepts) UML to nie metamodel notacji. Stereotyp aktor jako pojęcie, jego znacznie – semantyka, jest definiowane modelem pojęciowym, obiekt actor na diagramie to klasyfikator (klasa).

      • Jest jeden metamodel języka UML (wyrażony za pomocą MOF’a). Klasy stanowiące składowe metamodelu UML(zwane metaklasami), mogą być rozpatrywane z perspektywy MOF’a jako instancje metaklasy Class. W tym ujęciu metaklasa Actor (jak i inne składowe, np. przypadek użycia, notatka, węzeł, itd.) jest taką właśnie instancją – a w konsekwencji można powiedzieć, że jest klasę. Ale tak było zawsze (od pierwszej wersji języka UML) i chyba nie tego dotyczyła Pana uwaga:
        “zaczynam dostrzegać pewną prawidłowość, która mi się “podoba”, a mianowicie upraszcza się system pojęciowy (wszystko jest klasą i ich związkami)”.

        Odnosząc się do słów: “Model pojęciowy pojęć (concepts) UML to nie metamodel notacji.”
        Powtarzając się: jest jeden metamodel języka UML specyfikujący składnię abstrakcyjną języka (odwołując się do gramatyki języków: ustalający zbiór symboli języka). Notacja, tj. graficzna reprezentacja, dla tych symboli to zupełnie osobna sprawa. Dla aktora zaproponowana w specyfikacji notacja to:
        “An Actor is represented by a “stick man” icon with the name of the Actor in the vicinity (usually above or below) the icon, as illustrated by the example in Figure 18.6.
        An Actor may also be shown as a Classifier rectangle with the keyword «actor», with the usual notation for all compartments, as illustrated by the example in Figure 18.7.” (fragmenty z: http://www.omg.org/spec/UML/2.5/Beta2/)

        Odnosząc się do słów: “Stereotyp aktor jako pojęcie, jego znacznie – semantyka, jest definiowane modelem pojęciowym…”.
        Specyfikacja języka UML nie definiuje stereotypu aktor. Wręcz, słowo wymienione jest jako słowo kluczowe, a w konsekwencji jako zabronione w kontekście definicji stereotypów.

        Artykuł odwołuje się do najbardziej aktualnej wersji języka UML (tj. 2.5), przy ewentualnej odpowiedzi proszę o wskazania fragmentów czy rysunków z tej właśnie wersji lub, jeżeli nie jest to możliwe, precyzyjne zaznaczenie, o którą wersję dokumentacji chodzi.

        Z pozdrowieniami, dziękując za dyskusję,
        aw

        • Generalnie nie mam uwag poza jedną: metamodel notacji a notacja to nie to samo i tu chyba widzę małe nieporozumienie… Konkretna notacja jest raczej instancją określonego metamodelu, no i UML to w zasadzie kilkanaście notacji (diagramy) opartych na wspólnym “korzeniu” (metamodel), wydaje mi się, że chyba tu leży “nasz problem” zapewne nieporozumienie: to nie metamodel a profile, bo w zasadzie konkretne diagramy to pewne profile “system klasyfikatorów” jakim jest UML (i co wynika faktycznie z metamodelu MOF). Tak więc actor to klasyfikator, ma swoją semantykę i syntaktykę, diagram przypadków użycia można nazwać profilem “diagramu klas”…

Dodaj komentarz

W celu wzięcia udziału w dyskusji jako zalogowany użytkownik możesz zalogować się poprzez jeden z poniższych serwisów.

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Captcha Captcha Reload

Możesz użyć następujących tagów oraz atrybutów HTML-a: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>