Diagram UML

Spis treści

 [hide] 

• 1 Historia
• 1.1 Przed UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Projekt
• 2.1 Metody tworzenia oprogramowania
• 2.2 Modelowanie
• 3 Wykresy
• 3.1 Schematy strukturalne
• 3.2 Diagramy zachowań
• 3.2.1 Diagramy interakcji
• 4 Metamodelowanie
• 5 Przyjęcie
• 6 Krytyka
• 6.1 Krytyka UML 1.x

Historia[edit źródło | edit]

Historia metod i notacji zorientowanych obiektowo

UML ewoluuje od drugiej połowy lat 90. i ma swoje korzenie w metodach obiektowych rozwijanych na przełomie lat 80. i 90. Na osi czasu (patrz rysunek) przedstawiono najważniejsze punkty historii metod i notacji modelowania obiektowego.

Jest on pierwotnie oparty na notacjach metody Boocha, techniki modelowania obiektowego (OMT) i zorientowanej obiektowo inżynierii oprogramowania (OOSE), które zostały zintegrowane w jednym języku. ^[5]

Przed UML 1.x[edit źródło | edit]

Rational Software Corporation zatrudniła Jamesa Rumbaugha z General Electric w 1994 r., po czym firma stała się źródłem dwóch najpopularniejszych obecnie podejść do modelowania zorientowanego obiektowo:^[6] techniki modelowania obiektowego (OMT) Rumbaugha i metody Grady'ego Boocha. Wkrótce w ich wysiłkach wspomógł ich Ivar Jacobson, twórca metodyobject-oriented software engineering (OOSE), który dołączył do nich w Rational w 1995 r.^[1].

Pod technicznym kierownictwem tych trzech osób (Rumbaugh, Jacobson i Booch) w 1996 roku powstało konsorcjum o nazwie UML Partners, którego celem było ukończenie specyfikacji języka UML (Unified Modeling Language) i zaproponowanie jej standaryzacji Object Management Group (OMG). W skład partnerstwa weszły również inne zainteresowane strony (na przykład HP, DEC, IBM i Microsoft). Projekt UML 1.0 autorstwa UML Partners został przedstawiony OMG w styczniu 1997 r. przez konsorcjum. W tym samym miesiącu UML Partners utworzyło grupę, której zadaniem było dokładne zdefiniowanie znaczenia konstrukcji językowych, pod przewodnictwem Crisa Kobryna i pod kierownictwem Eda Eykholta, w celu sfinalizowania specyfikacji i zintegrowania jej z innymi działaniami standaryzacyjnymi. Wynik tych prac, UML 1.1, został złożony w OMG w sierpniu 1997 r. i przyjęty przez OMG w listopadzie 1997 r.^[1][7]

UML 1.x[edit źródło | edit]

Po pierwszym wydaniu utworzono grupę zadaniową^{[1] w} celu ulepszenia języka, która wydała kilka mniejszych poprawek, 1.3, 1.4 i 1.5.^[8].

Opracowane przez nią normy (jak również norma pierwotna) zostały uznane za niejednoznaczne i niespójne. ^[9][10]

UML 2.x[edit źródło | edit]

Główna rewizja UML 2.0 zastąpiła w 2005 r. wersję 1.5, która została opracowana przez rozszerzone konsorcjum w celu dalszego udoskonalenia języka, aby odzwierciedlić nowe doświadczenia w zakresie wykorzystania jego funkcji. ^[11]

Chociaż UML 2.1 nigdy nie został wydany jako formalna specyfikacja, wersje 2.1.1 i 2.1.2 pojawiły się w 2007 r., a następnie UML 2.2 w lutym 2009 r. UML 2.3 został formalnie wydany w maju 2010 r.^{[12] UML} 2.4.1 został formalnie wydany w sierpniu 2011 r.^[12] UML 2.5 został wydany w październiku 2012 r. jako wersja "W trakcie" i został oficjalnie wydany w czerwcu 2015 r.^[12].

Specyfikacja UML 2.x składa się z czterech części:

1. Nadbudowa, która definiuje notację i semantykę dla diagramów i ich elementów modelu
2. Infrastruktura, która definiuje podstawowy metamodel, na którym opiera się nadbudowa
3. Język Object Constraint Language (OCL) do definiowania reguł dla elementów modelu
4. Wymiana diagramów UML, która definiuje sposób wymiany układów diagramów UML 2

Aktualne wersje tych standardów są następujące: UML Superstructure w wersji 2.4.1, UML Infrastructure w wersji 2.4.1, OCL w wersji 2.3.1 oraz UML Diagram Interchange w wersji 1.0.^{[13] Jest} on wciąż aktualizowany i ulepszany przez grupę zadaniową Revision, która rozwiązuje wszelkie problemy z językiem. ^[14]

Design[edit source | edit]

Unified Modeling Language (UML) oferuje sposób wizualizacji projektu architektonicznego systemu w postaci diagramu (patrz obrazek), zawierającego takie elementy jak:^[5]

• Wszelkie działania (miejsca pracy)
• Poszczególne elementy systemu
• I jak mogą one współdziałać z innymi komponentami oprogramowania.
• Jak będzie działał system
• Jak jednostki oddziałują z innymi (komponenty i interfejsy)
• Zewnętrzny interfejs użytkownika

Chociaż pierwotnie przeznaczony był wyłącznie do dokumentacji projektowania obiektowego, Zunifikowany Język Modelowania (UML) został rozszerzony, aby objąć szerszy zestaw dokumentacji projektowej (jak wymieniono powyżej),^[15] i okazał się przydatny w wielu kontekstach. ^[16]

Metody tworzenia oprogramowania[edytuj źródło | edytuj]

UML sam w sobie nie jest metodą tworzenia oprogramowania; ^[17] został jednak zaprojektowany tak, aby był kompatybilny z wiodącymi w swoim czasie metodami tworzenia oprogramowania zorientowanego obiektowo (na przykładOMT, metoda Boocha, Objectory), a w szczególności z RUP, do którego był pierwotnie przeznaczony, gdy rozpoczęto prace w Rational Software Inc.

Modelarstwo[edit źródło | edit]

Ważne jest rozróżnienie pomiędzy modelem UML a zbiorem diagramów systemu. Diagram jest częściową graficzną reprezentacją modelu systemu. Zbiór diagramów nie musi całkowicie pokrywać modelu, a usunięcie diagramu nie powoduje zmiany modelu. Model może również zawierać dokumentację, która napędza elementy modelu i diagramy (takie jak spisane przypadki użycia).

Diagramy UML reprezentują dwa różne spojrzenia na model systemu:^[18]

• Widok statyczny (lub strukturalny): kładzie nacisk na statyczną strukturę systemu, wykorzystując obiekty, atrybuty, operacje i relacje. Widok strukturalny obejmuje diagramy klas i diagramy struktury złożonej.
• Widok dynamiczny (lub behawioralny): podkreśla dynamiczne zachowanie systemu poprzez pokazanie współpracy pomiędzy obiektami oraz zmian stanów wewnętrznych obiektów. Widok ten zawiera diagramy sekwencji, diagramy aktywności oraz diagramy maszyn stanów.

Modele UML mogą być wymieniane pomiędzy narzędziami UML za pomocą formatu wymiany XML Metadata Interchange (XMI).

Schematy[edit źródło | edit]

UML 2 posiada wiele typów diagramów, które są podzielone na dwie kategorie. ^5] Niektóre typy reprezentują informacje strukturalne, a pozostałe reprezentują ogólne typy zachowań, w tym kilka reprezentujących różne aspekty interakcji. Diagramy te mogą być skategoryzowane hierarchicznie, jak pokazano na poniższym diagramie klas:^[5]

Wszystkie te diagramy mogą zawierać komentarze lub uwagi wyjaśniające zastosowanie, ograniczenia lub intencje.

Schematy strukturalne[edytuj źródło | edytuj]

Diagramy strukturalne podkreślają rzeczy, które muszą być obecne w modelowanym systemie. Ponieważ diagramy strukturalne reprezentują strukturę, są one szeroko stosowane w dokumentowaniu architektury systemów oprogramowania. Na przykład diagram komponentów, który opisuje, jak system oprogramowania jest podzielony na komponenty i pokazuje zależności między tymi komponentami.

• Schemat komponentów
• Diagram klas

Diagramy zachowań[edytuj źródło | edytuj]

Diagramy zachowań podkreślają, co musi się wydarzyć w modelowanym systemie. Ponieważ diagramy zachowań ilustrują zachowanie systemu, są one szeroko wykorzystywane do opisywania funkcjonalności systemów oprogramowania. Przykładowo, diagram aktywności opisuje biznesowe i operacyjne działania krok po kroku komponentów w systemie.

• Diagram działań
• Diagram przypadków użycia

Diagramy interakcji[edytuj źródło | edytuj]

Diagramy interakcji, będące podzbiorem diagramów zachowań, kładą nacisk na przepływ sterowania i danych pomiędzy obiektami w modelowanym systemie. Na przykład diagram sekwencji, który pokazuje, jak obiekty komunikują się ze sobą w postaci sekwencji komunikatów.

• Schemat sekwencji
• Schemat komunikacyjny

Meta modeling[edit source | edit]

Główny artykuł: Meta-Object Facility

Ilustracja obiektu Meta-Object Facility

Object Management Group (OMG) opracowała architekturę metamodelowania w celu zdefiniowania Zunifikowanego Języka Modelowania (UML), zwaną Meta-Object Facility (MOF). ^[19] Meta-Object Facility jest zaprojektowany jako czterowarstwowa architektura, jak pokazano na obrazku po prawej stronie. W górnej warstwie udostępnia model meta-meta, zwany warstwą M3. Ten M3-model jest językiem używanym przez Meta-Object Facility do budowania metamodeli, zwanych M2-modelami.

Najbardziej prominentnym przykładem modelu warstwy 2 Meta-Object Facility jest metamodel UML, model opisujący sam UML. Te M2-modele opisują elementy warstwy M1, a więc M1-modele. Byłyby to na przykład modele napisane w języku UML. Ostatnią warstwą jest warstwa M0, czyli warstwa danych. Służy ona do opisu instancji systemu w trybie runtime. ^[20]

Meta-model może być rozszerzany za pomocą mechanizmu, który nazywa się stereotypowaniem. Zostało to skrytykowane jako niewystarczające/nieuzasadnione przez Briana Hendersona-Sellersa i Cesara Gonzaleza-Pereza w "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0" ^[21]

Adopcja[edit źródło | edit]

UML okazał się przydatny w wielu kontekstach projektowych,^{[16] do tego stopnia,} że stał się niemal wszechobecny w społeczności IT. ^[22]

Czasami traktowany był jako projektowy silver bullet, co prowadziło do problemów w jego użyciu. Niewłaściwe użycie obejmuje jego nadmierne wykorzystanie (projektowanie każdej małej części kodu systemu za jego pomocą, co jest niepotrzebne) i zakładanie, że każdy może zaprojektować cokolwiek za jego pomocą (nawet ci, którzy nie programowali). ^[23]

Jest on postrzegany jako duży język, z wieloma konstrukcjami w nim zawartymi. Niektórzy (w tym Jacobson) uważają, że jest ich zbyt wiele i że utrudnia to naukę (a więc i używanie) tego języka. ^[24]

Krytyka[edit źródło | edit]

Powszechna krytyka UML ze strony przemysłu obejmuje:^[4]

• nieprzydatne: "[nie] oferuje im korzyści w stosunku do ich obecnych, wyewoluowanych praktyk i reprezentacji".
• zbyt skomplikowany, szczególnie do komunikacji z klientami: "niepotrzebnie złożony" oraz "Najlepszym powodem, aby nie używać UML jest to, że nie jest on 'czytelny' dla wszystkich interesariuszy. Ile wart jest UML, jeśli użytkownik biznesowy (klient) nie może zrozumieć rezultatu twoich wysiłków w zakresie modelowania?"
• konieczność synchronizacji UML i kodu, tak jak w przypadku dokumentacji w ogóle

Krytyka UML 1.x[edit źródło | edit]

Notacja kardynalności

Podobnie jak w przypadku diagramów baz danych Chen, Bachmana i ISO ER, modele klas są określone tak, aby używać kardynalności "look-across", mimo że kilku autorów (Merise,^[25] Elmasri & Navathe[26] i inni[27]⁾ preferują technikę "same-side" lub "look-here" dla ról i zarówno minimalnej, jak i maksymalnej kardynalności. Niedawni badacze (Feinerer,^[28] Dullea i inni^[29]) wykazali, że technika "look-across" używana przez UML i diagramy ER jest mniej efektywna i mniej spójna, gdy jest stosowana do n-arygodnych relacji rzędu >2.

Feinerer mówi "Problemy pojawiają się, jeśli działamy w oparciu o semantykę look-across używaną dla asocjacji UML. Hartmann^[30] bada tę sytuację i pokazuje, jak i dlaczego różne transformacje zawodzą." (Chociaż wspomniana "redukcja" jest złudna, ponieważ dwa diagramy 3.4 i 3.5 są w rzeczywistości takie same), a także "Jak zobaczymy na następnych kilku stronach, interpretacja look-across wprowadza kilka trudności, które uniemożliwiają rozszerzenie prostych mechanizmów z asocjacji binarnych na n-ary."