Co prawda formalna publikacja wersji 2.5 UML to 1 marzec 2015 r. ale co ma wisieć nie utonie (spokojne przebrnięcie tych 794 stron wymaga czasu i cierpliwości), czyli wzmianka i kilka słów z pierwszych wrażeń. Specyfikacja do pobrania tu:
Documents Associated With Unified Modeling Language (UML) Version 2.5 (Źródło: UML 2.5)
Zdaję sobie sprawę z tego, że poniższe nie wszystkim z Was wszystko wyjaśni ale ten akurat wpis adresuję dla tych z Was, którzy korzystają już z UML, nawet w bardzo prosty sposób.
Wersja 2.5 UML to wersja chyba przełomowa, bo:
- zrezygnowano w końcu z podziału na dwie części Infrastructure i Superstructure,
- uporządkowano cały system pojęciowy notacji: jest to w końcu jedna w pełni spójna notacja (system klasyfikatorów, kiedyś Infrastructure) oraz zestaw predefiniowanych grup stereotypów z ich dedykowaną semantyką i syntaktyką (kiedyś Superstructure).
- diagram jako pojęcie, obecnie stanowi jedynie kontekst a nie, jak kiedyś zamkniętą “subnotację” (UML zaczynał w latach 90-tych jako zlepek kilku notacji trzech autorów).
Obecnie mamy osiem typów diagramów (kopia z oryginału):
UML diagrams may have the following kinds of frame names as part of the heading:
? activity
? class
? component
? deployment
? interaction
? package
? state machine
? use case
In addition to the long form names for diagram heading types, the following abbreviated forms can also be used:
? act (for activity frames)
? cmp (for component frames)
? dep (for deployment frames)
? sd (for interaction frames)
? pkg (for package frames)
? stm (for state machine frames)
? uc (for use case frames)
Jak widać, trzylitrowych skrótów oznaczających diagramy jest o jeden mniej (siedem). To wynika z tego, że wszystkie diagramy w UML to tak na prawdę diagramy klas (ten typ diagramu nie ma swojego dedykowanego skrótu), z tym że stanowią one kontekstowe profile. Struktura pojęciowa tych diagramów (ich [[taksonomia]]):
W stosunku do UML 2.4 diagram profilu jest teraz równoprawnym typem diagramu (czternasty). Wszystkie pojęcia UML (constructs) zostały przydzielone kontekstowo to typów diagramów:
The constructs contained in each of the UML diagrams are described in the clauses indicated below.
? Activity Diagram – Activities
? Class Diagram – Structured Classifiers
? Communication Diagram – Interactions
? Component Diagram – Structured Classifiers
? Composite Structure Diagram – Structured Classifiers
? Deployment diagram – Deployments
? Interaction Overview Diagram – Interactions
? Object Diagram – Classification
? Package Diagram – Packages
? Profile Diagram – Packages
? State Machine Diagram – State Machines
? Sequence Diagram – Interactions
? Timing Diagram – Interactions
? Use Case Diagram – Use Cases
Należy to rozumieć w ten sposób: diagram aktywności daje kontekst dla pojęć z grupy “activities” (aktywności i czynności oraz ich syntaktyczne asocjacje), diagram klas daje kontekst dla “klasyfikatorów strukturalnych”, itd.
Warto przypatrzeć się swoim narzędziom CASE, gdyż niestety nie wszystkie mają wbudowany powyższy “klasowy” paradygmat (w UML wszystko jest klasą). Wiele z nich nadal hołduje zasadzie diagramy jako odrębne notacje, obecnie w UML w każdym typie diagramu można użyć każdego elementu notacji, diagram jako pojęcie to wyłącznie kontener niosący główny kontekst danego modelu, bo przypominam, że diagram w UML to wyłącznie widok całości lub części modelu z określonej perspektywy i na określonym poziomie abstrakcji.
[uzupełnienie 2015-11-21] Z pewną satysfakcją “odkryłem” (pierwotnie, pisząc ten artykuł miesiąc temu, nie zwróciłem na to uwagi), że zrezygnowano w końcu z pojęcia agregacji, zwanej w części literatury “słabą kompozycją”. Ta kuriozalna konstrukcja pojęciowa kłóciła się z pojęciem i asocjacji jako takiej i kompozycji jako związku “całość część”. Nie ja jeden, jak śledzę dyskusje członków OMG na listach LinkedIn, deklarowałem, że “nie rozumiem” czym jest agregacja (chyba pierwszym, który to głośno mówił był Martin Fowler). Na szczęście widać, że definicja tego pojęcia nie wytrzymała boju z logiką. Co prawda symbol asocjacji z “pustym rombem” jest (tylko) na liście symboli w dodatku B.6 (str. 718) jednak widać, że to relikt kompatybilności wstecz, w treści całej specyfikacji to pojęcie nie jest w ogóle używane. Generalnie mamy związek kompozycji (pełny romb), a element skomponowany może być rzeczywisty (part) lub abstrakcyjny (patrz rozdz. 11.2.3.2 Parts and Roles oraz 11.2.3.3 Connectors). Podobnie z dziedziczeniem: nie ma dziedziczenia (korekta grudzień 2017, UML 2.5.1.).
Polecam całą specyfikację, znacznie krótsza od poprzedniej :).
