Podstawowe diagramy UML. Modelowanie UML

UML lub Unified Modeling Language - język opisu graficznego do modelowania obiektów w fazie rozwoju oprogramowanie... Jednak wykorzystanie UML nie ogranicza się do IT, kolejnym dużym obszarem praktycznego zastosowania UML jest modelowanie procesów biznesowych, inżynieria systemów oraz mapowanie struktur organizacyjnych. UML umożliwia twórcom oprogramowania osiągnięcie porozumienia w sprawie symbole graficzne przedstawić ogólne koncepcje i skoncentrować się na projektowaniu i rozwoju.

Zalety UML

• UML używa symboli graficznych dla elementów modelowanego systemu, a diagramy UML są wystarczająco proste do zrozumienia;
• UML umożliwia opisywanie systemów z niemal każdego możliwego punktu widzenia, z uwzględnieniem różnych aspektów;
• UML jest zorientowany obiektowo: jego metody analizy i konstrukcji są semantycznie zbliżone do metod programowania używanych we współczesnych językach OOP;
• UML to otwarty standard. Standard rozwija się i ewoluuje z wersji na wersję, odpowiadając na większość nowoczesne wymagania do opisu systemów;
• zawiera mechanizm rozszerzeń pozwalający na wprowadzenie dodatkowych typów tekstowych i graficznych, co umożliwia wykorzystanie języka UML nie tylko na polu informatycznym.

Rodzaje diagramów UML

W UML istnieje 14 typów diagramów. Można je podzielić na 2 kategorie:

• strukturalny reprezentujący struktura informacji;
• behawioralny reprezentujące zachowanie systemu i różne aspekty interakcji. Rozważany jest odrębny podgatunek diagramów zachowań diagramy interakcji.

hierarchia typów diagramów UML,
reprezentowana przez diagram klas

Schematy strukturalne

1. Diagram klas jest kluczowym elementem modelowania obiektowego. Za pomocą tego schematu (w rzeczywistości przez zajęcia, ich atrybuty, metody i zależności między klasami) opisuje model domeny i strukturę modelowanego systemu.
2. Schemat komponentów wyświetla podział kod programu na duże bloki (elementy konstrukcyjne) i pokazy zależności między nimi. Komponentami mogą być pakiety, moduły, biblioteki, pliki itp.
3. Schemat obiektu pokazuje pełny lub częściowy wycinek modelowanego systemu w danym momencie. Reprezentuje instancje klas (obiekty), ich stan (bieżące wartości atrybutów) oraz relacje między nimi.
4. Schemat struktury kompozytowej demonstruje wewnętrzną strukturę klas i, jeśli to możliwe, interakcje między elementami tej struktury.
5. Schemat pakietu pokazuje pakiety i relacje między nimi. Ten rodzaj diagramów służy uproszczeniu struktury modelu (i odpowiednio pracy z nim) poprzez łączenie elementów modelu w grupy według określonych kryteriów.
6. Schemat wdrożenia symuluje wdrożenie komponenty oprogramowania ow ( artefakty) o zasobach obliczeniowych / komponentach sprzętowych ( węzły).
7. Schemat profilu opisuje mechanizm rozszerzenia, który umożliwia dostosowanie UML do różnych dziedzin i branż.

Przykładowy diagram klas UML

Diagramy zachowań

1. Diagram aktywności pokazuje akcje ( działania) z czego pewna działalność ( działalność). Diagramy aktywności służą do modelowania procesów biznesowych, przepływów pracy, obliczeń sekwencyjnych i równoległych.
2. Diagram przypadków użycia(lub diagram przypadków użycia) opisuje relacje między aktorami (znakami) oraz przypadki użycia modelowanego systemu (jego możliwości). Głównym celem diagramu jest bycie punktem kompleksowej obsługi dla klientów, programistów i użytkowników końcowych w celu wspólnego omówienia systemu — jego możliwości i zachowania.
3. Diagram stanu przedstawia dynamiczne zachowanie podmiotu, pokazując, jak ten podmiot, w zależności od jego stan obecny reaguje na różne zdarzenia. Jest to zasadniczo diagram stanu z teorii atomów.
4. Schemat komunikacji(v wczesne wersje schemat współpracy) pokazuje interakcje między częściami struktury złożonej i role we współpracy. Schemat wyraźnie wskazuje relacje między elementami (obiektami).
5. Diagram sekwencyjny służy do wizualizacji sekwencji interakcji obiektów. Pokazuje cykl życia danego obiektu i interakcję aktorów (aktorów) w ramach przypadku użycia, sekwencję wymienianych przez nich komunikatów.
6. Tabela przeglądu interakcji zawiera część diagramu sekwencji i konstrukcje przepływu sterowania. Pomaga rozważyć interakcję obiektów z różnych punktów widzenia.
7. Schemat synchronizacji- osobny podtyp diagramów interakcji, specjalizujący się w taktowaniu. Tego rodzaju diagramy służą do badania zachowania obiektów w określonym czasie.

Diagram UML to specjalistyczny język opisu graficznego przeznaczony do modelowania obiektowego w tworzeniu różnego rodzaju oprogramowania. Język ten ma szeroki profil i jest otwartym standardem, który wykorzystuje różne notacje graficzne do stworzenia abstrakcyjnego modelu systemu. UML został stworzony w celu zapewnienia definicji, wizualizacji, dokumentacji i projektowania wszelkiego rodzaju systemów oprogramowania. Warto zauważyć, że sam diagram UML nie jest językiem programowania, ale przewiduje możliwość wygenerowania na jego podstawie osobnego kodu.

Dlaczego jest to potrzebne?

UML nie kończy się na modelowaniu wszelkiego rodzaju oprogramowania. Ponadto język ten jest dziś aktywnie wykorzystywany do modelowania różnych procesów biznesowych, prowadzenia inżynierii systemów, a także wyświetlania struktur organizacyjnych.

Korzystając z UML, twórcy oprogramowania mogą wymusić pełną konwencję w notacjach graficznych używanych do reprezentowania ogólnych pojęć, takich jak komponent, uogólnienie, klasa, zachowanie i agregacja. Pozwala to osiągnąć większy stopień koncentracji na architekturze i projektowaniu.

Warto również zauważyć, że istnieje kilka rodzajów takich diagramów.

Diagram klas

Diagram klas UML to statyczny diagram struktury zaprojektowany w celu opisania struktury systemu, a także pokazania atrybutów, metod i zależności między kilkoma różnymi klasami.

Warto zwrócić uwagę na fakt, że istnieje kilka punktów widzenia na budowę takich schematów, w zależności od tego, w jaki sposób zostaną wykorzystane:

• Konceptualistyczny. W tym przypadku diagram klas UML opisuje model konkretnej domeny, a udostępniane są w nim tylko klasy zastosowanych obiektów.
• Konkretny. Schemat wykorzystywany jest w procesie projektowania różnych systemów informatycznych.
• Realizacja. Diagram klas zawiera wszystkie rodzaje klas, które są bezpośrednio używane w kodzie programu.

Schemat komponentów

Diagram komponentów UML to w pełni statyczny diagram strukturalny. Ma na celu zademonstrować rozszczepienie pewnego system oprogramowania na różnych elementach konstrukcyjnych, a także połączeniach między nimi. Diagram komponentów UML jako taki może wykorzystywać wszelkiego rodzaju modele, biblioteki, pliki, pakiety, pliki wykonywalne i wiele innych elementów.

Schemat struktury kompozytowej / kompozytowej

Diagram struktury złożonej / złożonej UML jest również diagramem struktury statycznej, ale służy do pokazania wewnętrznej struktury klas. Jeśli to możliwe, diagram ten może również zademonstrować interakcję elementów znajdujących się w wewnętrznej strukturze klasy.

Ich podtypem jest diagram współpracy UML, który służy do wykazania ról, a także interakcji różnych klas w granicach współpracy. Są bardzo przydatne, gdy trzeba modelować wzorce projektowe.

Warto zauważyć, że typy diagramów klas UML i typy struktur złożonych mogą być używane jednocześnie.

Schemat wdrożenia

Ten diagram służy do symulacji działających węzłów, a także wszelkiego rodzaju artefaktów, które zostały w nich wdrożone. UML 2 wdraża artefakty w różnych węzłach, podczas gdy pierwsza wersja wdraża wyłącznie komponenty. W związku z tym diagram wdrażania UML jest używany głównie przez drugą wersję.

Między artefaktem a implementowanym przez niego składnikiem powstaje manifestacja zależności.

Schemat obiektu

Ten widok pozwala zobaczyć pełny lub częściowy obraz. tworzony system w pewnym momencie. W pełni wyświetla wszystkie instancje klas danego systemu, wskazując aktualne wartości ich parametrów, a także powiązania między nimi.

Schemat pakietu

Diagram ten ma charakter strukturalny, a jego główną treścią są wszelkiego rodzaju pakiety, a także relacje między nimi. W tym przypadku nie ma twardy podział między kilkoma schematami strukturalnymi, w wyniku czego ich użycie jest najczęściej spotykane wyłącznie dla wygody i nie ma żadnego znaczenia semantycznego. Warto zauważyć, że różne elementy mogą dostarczać inne diagramy UML (przykłady: pakiety i same diagramy pakietów).

Ich wykorzystanie odbywa się w celu zapewnienia organizacji kilku elementów w grupy według określonego kryterium, w celu uproszczenia struktury, a także uporządkowania pracy z modelem tego systemu.

Diagram aktywności

Diagram aktywności UML przedstawia rozkład określonej aktywności na kilka części składowych. W tym przypadku pojęcie „działania” odnosi się do określenia pewnego wykonywalnego zachowania w postaci równoległego, a także skoordynowanego sekwencyjnego wykonywania różnych podrzędnych elementów – zagnieżdżonych typów czynności i różnych akcji, połączonych wątkami pochodzącymi z dane wyjściowe jednego węzła na dane wejściowe innego.

Diagramy aktywności UML są często wykorzystywane do modelowania różnych procesów biznesowych, obliczeń równoległych i sekwencyjnych. Między innymi symulują wszelkiego rodzaju procedury technologiczne.

Schemat automatu

Ten widok jest również nazywany diagramem stanu UML. Ma zaprezentowaną maszynę stanów ze stanami prostymi i złożonymi oraz przejściami.

Maszyna stanów to specyfikacja sekwencji różnych stanów, przez które przechodzi dany obiekt, lub interakcja w odpowiedzi na pewne zdarzenia z jego życia, jak również reakcje obiektu na takie zdarzenia. Automat stanów, który używa schematu stanów UML, jest dołączony do elementu źródłowego i używany do definiowania zachowania jego wystąpień.

Tak zwane smocze schematy mogą być używane jako analogi takich diagramów.

Diagramy przypadków użycia

Diagram przypadków użycia UML przedstawia wszystkie relacje, które powstają między aktorami, a także różne przypadki użycia. Jego głównym zadaniem jest zapewnienie siebie jako pełnoprawnego środka, za pomocą którego klient, użytkownik końcowy lub jakiś programista może wspólnie omówić zachowanie i funkcjonalność konkretnego systemu.

W przypadku wykorzystania diagramu przypadków użycia UML w procesie modelowania systemu, analityk zamierza:

• Wyraźnie oddziel symulowany system od otoczenia.
• Zidentyfikuj aktorów, sposoby ich interakcji z tym systemem, a także jego oczekiwaną funkcjonalność.
• Ustaw w słowniku jako obszar tematyczny różne koncepcje, które odnoszą się do szczegółowego opisu funkcjonalności tego systemu.

Jeżeli diagram użytkowania jest tworzony w UML, procedura rozpoczyna się od opisu tekstowego, który uzyskuje się podczas pracy z klientem. Jednocześnie warto zauważyć, że różne wymagania niefunkcjonalne w procesie tworzenia modelu przypadków użycia są całkowicie pomijane, a dla nich zostanie już utworzony osobny dokument.

Komunikacja

Diagram komunikacyjny, podobnie jak diagram sekwencji UML, jest przechodni, czyli sam w sobie wyraża interakcję, ale jednocześnie ją demonstruje różne sposoby, a jeśli to konieczne, z żądanym stopniem dokładności, możesz konwertować je na inne.

Diagram komunikacyjny przedstawia interakcje zachodzące między różnymi elementami złożonej struktury, a także role we współpracy. Główną różnicą w stosunku do diagramu sekwencji jest to, że wyraźnie wskazuje on związek między kilkoma elementami, a czas nie jest używany jako oddzielny wymiar.

Ten typ wyróżnia się całkowicie swobodnym formatem porządkowania kilku obiektów i linków w taki sam sposób, jak to się robi w diagramie obiektowym. Jeśli istnieje potrzeba zachowania kolejności wiadomości w tym dowolnym formacie, są one ponumerowane chronologicznie. Czytanie tego diagramu rozpoczyna się od oryginalnej wiadomości 1.0, a następnie jest kontynuowane w kierunku, w którym wiadomości są przekazywane z jednego obiektu do drugiego.

Większość z tych diagramów pokazuje dokładnie te same informacje, które dostarcza nam diagram sekwencji, jednak ponieważ wykorzystuje inny sposób prezentacji informacji, pewne rzeczy na jednym diagramie są znacznie łatwiejsze do zidentyfikowania niż na innym. Warto również zauważyć, że diagram komunikacji wyraźniej pokazuje, z jakimi elementami każdy z nich wchodzi w interakcje. oddzielny element, podczas gdy diagram sekwencji pokazuje wyraźniej, w jakiej kolejności zachodzą interakcje.

Diagram sekwencyjny

Diagram sekwencji UML przedstawia interakcje między wieloma obiektami, które są uporządkowane według czasu ich wystąpienia. Ten diagram przedstawia uporządkowane w czasie interakcje między wieloma obiektami. W szczególności wyświetla wszystkie obiekty biorące udział w interakcji, a także pełną sekwencję wymienianych przez nie wiadomości.

Głównymi elementami w tym przypadku są oznaczenia różnych obiektów, a także pionowe linie pokazujące upływ czasu oraz prostokąty, które zapewniają działanie danego obiektu lub pełnienie przez niego dowolnej funkcji.

Schemat współpracy

Ten rodzaj diagramów pozwala zademonstrować interakcje między kilkoma obiektami, abstrahując od sekwencji rozgłaszanych komunikatów. Ten typ diagramów w kompaktowej formie wyświetla absolutnie wszystkie nadawane i odbierane komunikaty danego obiektu, a także formaty tych komunikatów.

Ze względu na to, że diagramy sekwencji i diagramy komunikacyjne to po prostu różne widoki tych samych procedur, Rational Rose zapewnia możliwość tworzenia diagramu komunikacyjnego z diagramu sekwencji lub odwrotnie, a także wykonuje ich w pełni automatyczną synchronizację.

Wykresy przeglądu interakcji

Są to diagramy UML, które są podzbiorem diagramów aktywności, które zawierają zarówno elementy Sekwencji, jak i konstrukcje przepływu sterowania.

Warto zwrócić uwagę na fakt, że ten formatłączy Collaboration i Sequence diagram, które z różnych punktów widzenia dają możliwość rozważenia interakcji między kilkoma obiektami w generowanym systemie.

Schemat synchronizacji

Reprezentuje Alternatywna opcja diagram sekwencji, który wyraźnie pokazuje zmianę stanu na linii życia z określoną osią czasu. Może być bardzo przydatny w różnych aplikacjach czasu rzeczywistego.

Jakie są korzyści?

Warto zwrócić uwagę na kilka zalet, które wyróżniają diagram użycia UML od innych:

• Język jest zorientowany obiektowo, w wyniku czego technologie opisu wyników przeprowadzonych analiz i projektowania są semantycznie zbliżone do metod programowania we wszystkich rodzajach języków obiektowych współczesnego typu.
• Za pomocą tego języka można opisać system z niemal każdego możliwego punktu widzenia iw ten sam sposób opisać różne aspekty jego zachowania.
• Wszystkie diagramy są stosunkowo łatwe do odczytania, nawet po stosunkowo szybkim zapoznaniu się z ich składnią.
• UML pozwala na rozbudowę, a także wprowadzanie własnych stereotypów graficznych i tekstowych, co przyczynia się do jego wykorzystania nie tylko w inżynierii oprogramowania.
• Język stał się dość rozpowszechniony, a także rozwija się dość aktywnie.

niedogodności

Pomimo tego, że budowanie diagramów UML ma wiele zalet, dość często są one krytykowane za następujące niedociągnięcia:

• Nadmierność. W zdecydowanej większości krytycy twierdzą, że UML jest zbyt duży i złożony, co często jest nieuzasadnione. Zawiera wiele zbędnych lub praktycznie bezużytecznych konstrukcji i schematów, a najczęściej taka krytyka trafia do wersji drugiej, a nie pierwszej, ponieważ nowsze rewizje zawierają duża ilość kompromisy „opracowane przez komisję”.
• Różne niedokładności semantyczne. Ponieważ język UML jest definiowany przez kombinację samego siebie, języka angielskiego i języka OCL, brakuje mu sztywności, która jest nieodłączna w językach precyzyjnie określonych techniką opisu formalnego. W pewnych sytuacjach abstrakcyjna składnia języków OCL, UML i angielskiego zaczyna być ze sobą sprzeczna, podczas gdy w innych jest niekompletna. Niedokładny opis samego języka wpływa zarówno na użytkowników, jak i dostawców narzędzi, co ostatecznie prowadzi do niekompatybilności narzędzi ze względu na unikalny sposób interpretacji różnych specyfikacji.
• Problemy w procesie realizacji i badania. Wszystkie powyższe problemy stwarzają pewne trudności w procesie wprowadzania i uczenia się języka UML, a dzieje się tak zwłaszcza wtedy, gdy kierownictwo zmusza inżynierów do użycia go na siłę, podczas gdy nie mają oni wcześniejszych umiejętności.
• Kod odzwierciedla kod. Inna opinia jest taka, że ​​to nie piękne i atrakcyjne modele są ważne, ale same działające systemy, czyli kod jest projektem. Według tej opinii istnieje potrzeba dalszego rozwoju skuteczna metoda oprogramowanie do pisania. UML jest ceniony za podejścia, które kompilują modele w celu regeneracji pliku wykonywalnego lub kod źródłowy... Ale w rzeczywistości może to nie wystarczyć, ponieważ językowi brakuje właściwości kompletności Turinga, a każdy wygenerowany kod będzie ostatecznie ograniczony przez to, co narzędzie interpretera UML może założyć lub zdefiniować.
• Niezgodność obciążenia. Termin ten pochodzi z teorii analizy systemów w celu określenia niezdolności wejścia jednego systemu do postrzegania wyjścia innego. Jak w każdym systemy standardowe notacji, UML może reprezentować niektóre systemy w bardziej wydajny i zwięzły sposób niż inne. W związku z tym programista jest bardziej skłonny do rozwiązań, które są wygodniejsze w tkaniu wszystkich mocnych stron UML, a także innych języków programowania. Problem ten jest tym bardziej oczywisty w przypadku, gdy język programowania nie jest zgodny z podstawowymi zasadami ortodoksyjnej doktryny obiektowej, czyli nie stara się działać zgodnie z zasadami OOP.
• Stara się być wszechstronna. UML to język modelowania ogólnego przeznaczenia, który stara się być kompatybilny z dowolnym dostępnym obecnie językiem przetwarzania. W kontekście konkretnego projektu, aby zespół projektowy mógł osiągnąć ostateczny cel, konieczne jest dobranie odpowiednich możliwości tego języka. Ponadto możliwe sposoby ograniczania zakresu UML w określonym obszarze przechodzą przez formalizm, który nie jest w pełni sformułowany, ale sam w sobie jest przedmiotem krytyki.

Dlatego użycie tego języka nie jest właściwe we wszystkich sytuacjach.

Model UML(model UML) to zbiór skończonego zbioru konstrukcji językowych, z których głównym są byty i relacje między nimi.

Same byty i relacje modelu są instancjami metaklas metamodelu.

Rozważając Model UML z najogólniejszego punktu widzenia możemy powiedzieć, że jest to graf (a dokładniej obciążony multi-pseudo-hiper-digraf), w którym wierzchołki i krawędzie są obciążone dodatkowymi informacjami i mogą mieć złożoną strukturę wewnętrzną. Wierzchołki tego grafu nazywane są bytami, a krawędzie są relacjami... Pozostała część sekcji zawiera pobieżne (wstępne), ale pełny przegląd dostępne typy podmiotów i relacji. Na szczęście nie ma ich zbyt wiele. W kolejnych rozdziałach książki ponownie omówiono wszystkie byty i relacje, bardziej szczegółowo i z przykładami.

1.4.1. Podmioty

Aby ułatwić przeglądanie, encje w UML można podzielić na cztery grupy:

• strukturalny;
• behawioralne;
• grupowanie;
• opisowy.

Jak można się domyślić, byty strukturalne mają opisywać strukturę. Zazwyczaj jednostki strukturalne obejmują następujące elementy.

Obiekt(obiekt) 1 to jednostka, która jest unikalna i zawiera stan i zachowanie.

Klasa(klasa) 2 - opis zbioru obiektów o wspólnych atrybutach określających stan i operacjach określających zachowanie.

Berło(interfejs) 3 to nazwany zestaw operacji, który definiuje zestaw usług, o które może poprosić konsument i które są świadczone przez dostawcę usług.

Współpraca(współpraca) 4 – zbiór obiektów, które wchodzą w interakcję, aby osiągnąć cel.

Aktor(aktor) 5 to podmiot, który znajduje się poza modelowanym systemem i bezpośrednio z nim współdziała.

∇ Taki związek z pewnością istnieje, co wyraża ryc. Hierarchia typów diagramów dla UML 1 w postaci relacji zależności z wyrafinowanym stereotypem.

∇∇ W UML 1 między diagramem współpracy a podmiotem o tej samej nazwie powstał mimowolny związek, który nie był do końca prawdziwy, a czasem mylący.

∇∇∇ W UML 2 obciążenie syntaktyczne i semantyczne diagramu stanów zmieniło się tak bardzo, że nazwa nie odzwierciedla już treści.

Poniżej znajduje się lista nowych wykresów i ich nazwy użyte w tej książce.

• Diagram Struktura wewnętrzna(Schemat struktury kompozytowej)
• Schemat pakietu
• Schemat maszyny stanowej
• Schemat komunikacji
• Diagram Przegląd interakcji
• Schemat czasowy

Na ryc. Hierarchia typów diagramów dla UML 2 (część 1 i 2) to diagram klas pokazujący relacje między diagramami w UML 2.

W dalszej części tego rozdziału bardzo krótko opiszemy wszystkie trzynaście diagramów kanonicznych, aby mieć pewien kontekst i słownictwo do późniejszej prezentacji. Szczegóły znajdują się w pozostałych rozdziałach książki.

Ale zanim przejdziemy do następnej sekcji, zróbmy małą dygresję na temat tego, jak standard wymaga formatowania diagramów. Ogólny szablon prezentacji wykresu pokazano poniżej.

Istnieją dwa główne elementy projektu: ramka zewnętrzna i etykieta z nazwą schematu. Jeśli z ramką wszystko jest proste - jest to prostokąt ograniczający obszar, w którym powinny znajdować się elementy diagramu, to nazwa diagramu jest zapisana w specjalnym formacie, pokazanym na ryc. Notacja dla wykresów.

Wskazany złożony kształt zakładki nie jest obsługiwany przez wszystkie narzędzia. Nie jest to jednak konieczne, ponieważ semantyka jest pierwotna, a notacja drugorzędna. Od teraz będziemy używać prostokąta jako etykiety dla całego diagramu i nie powinno to powodować zamieszania.

W poniższej tabeli przedstawiono możliwe tagi (typy) wykresów. Tagi oferowane przez normę są zapisane w drugiej kolumnie. Jednak, jak pokazała praktyka, proponowane przez normę reguły nie zawsze są wygodne i logicznie uzasadnione, dlatego też trzecia kolumna tabeli zawiera naszym zdaniem rozsądną alternatywę.

Patka. Typy wykresów i tagi

Tytuł wykresu	Etykieta (standardowa)	Tag (sugerowane)
Schemat użytkowania	przypadek użycia lub uc	przypadek użycia
Diagram klas	klasa	klasa
Schemat automatu	maszyna stanowa lub stm	maszyna stanowa
Diagram aktywności	działalność lub działać	działalność
Diagram sekwencyjny	interakcja lub sd	sd
Schemat komunikacji	interakcja lub sd	komunikacja
Schemat komponentów	składnik lub cmp	składnik
Schemat rozmieszczenia	nieokreślony	rozlokowanie
Schemat obiektu	nieokreślony	obiekt
Schemat struktury wewnętrznej	klasa	klasa lub składnik
Schemat przeglądu interakcji	interakcja lub sd	interakcja
Schemat synchronizacji	interakcja lub sd	wyczucie czasu
Schemat pakietu	pakiet lub pakiet	pakiet

11.1. Struktura zunifikowanego języka modelowania

Ujednolicony język modelowania (UML) w obecnie jest de facto standardem opisu (dokumentowania) wyników projektowania i rozwoju systemów obiektowych. Rozwój UML rozpoczął w 1994 roku Grady Booch i James Rambeau z Rational Software. Jesienią 1995 roku dołączył do nich Ivar Jacobson, aw październiku tego samego roku ukazała się wstępna wersja 0.8 Unified Method. Od tego czasu wydano kilka wersji specyfikacji UML, z których dwie mają status standardu międzynarodowego:

UML 1.4.2 - „ISO / IEC 19501: 2005. Technologia informacyjna. Otwarte przetwarzanie rozproszone. Zunifikowany język modelowania (UML). Wersja 1.4.2” (ang. „Technologia informacyjna. Otwarte przetwarzanie rozproszone. Zunifikowany język modelowania (UML). Wersja 1.4.2 ");

UML 2.4.1 - „ISO / IEC 19505-1: 2012. Technologia informacyjna. OMG UML. Część 1. Infrastruktura” (ang. „Technologia informacyjna - zunifikowany język modelowania Object Management Group ( OMG UML) - Część 1: Infrastruktura ”) oraz" ISO / IEC 19505-2: 2012. Technologia informacyjna. Język modelowania Unified Object Management Group (OMG UML). Część 2. Nadbudowa "(eng." Information technology - Object Management Group Unified Modeling Language (OMG UML) - Część 2 : Nadbudowa ").

Najnowszą oficjalną specyfikację językową można znaleźć na stronie www.omg.org.

Ogólną strukturę UML pokazano na poniższym rysunku.

Ryż. 11.1. Struktura UML

11.2. Semantyka i składnia UML

Semantyka - dział językoznawstwa, który bada znaczenie jednostek językowych, przede wszystkim jego słów i fraz.

Składnia - sposoby łączenia słów i ich form we frazy i zdania, łączenia zdań w zdania złożone, sposoby tworzenia wypowiedzi w ramach tekstu.

Tak więc, po zastosowaniu do UML, semantyka i składnia definiują styl prezentacji (budowanie modelu), który łączy języki naturalne i formalne do reprezentowania podstawowe koncepcje(elementy modelu) i mechanizmy ich rozbudowy.

11.3. Notacja UML

Notacja to graficzna interpretacja semantyki w celu jej wizualnej prezentacji.

UML definiuje trzy typ encji :

Strukturalny - abstrakcja będąca odzwierciedleniem obiektu pojęciowego lub fizycznego;

Grupowanie - element używany do pewnej semantycznej unifikacji elementów diagramu;

Objaśnienie (adnotacja) - komentarz do elementu diagramu.

Poniższa tabela zawiera krótki opis głównych jednostek używanych w notacji graficznej oraz głównych sposobów ich wyświetlania.

Tabela 11.1. Podmioty

Typ	Nazwa	Przeznaczenie	Definicja (semantyka)
Strukturalny	(klasa)		Zbiór obiektów, które mają struktura ogólna i zachowanie
	(obiekt)		Abstrakcja rzeczywistego lub wyobrażonego bytu z jasno określonymi granicami pojęciowymi, indywidualnością (tożsamością), stanem i zachowaniem. Z perspektywy UML obiekty są instancjami klas (instancjami encji)
	(aktor)	Inżynier usługi ścieżek	Jednostka zewnętrzna w stosunku do systemu, która wchodzi w interakcję z systemem i korzysta z niego funkcjonalność aby osiągnąć określone cele lub rozwiązać określone problemy. Tak więc aktor jest źródło zewnętrzne lub odbiorca informacji
	(przypadek użycia)		Opis czynności wykonywanych przez system, które prowadzą do wyniku istotnego dla aktora
	(stan)		Opis momentu w życiu podmiotu, w którym spełnia określony warunek, wykonuje jakąś czynność lub czeka na zajście jakiegoś zdarzenia
	Współpraca (współpraca)		Opis zbioru instancji aktorów, obiektów i ich interakcji w procesie rozwiązywania określonego problemu
	(składnik)		Fizyczna część systemu (plik), w tym moduły systemu zapewniające implementację spójnego zestawu interfejsów
	(berło)	Obliczanie	Zbiór operacji definiujących usługę (zbiór usług) dostarczaną przez klasę lub komponent
	(węzeł)		Fizyczna część systemu (komputer, drukarka itp.), która zapewnia zasoby do rozwiązania problemu
Grupowanie	(pakiet)		Ogólny mechanizm grupowania elementów. W przeciwieństwie do komponentu, pakiet jest koncepcją czysto koncepcyjną (abstrakcyjną). Poszczególne przypadki pakietu to system i model
	(fragment)		Obszar specyficznej interakcji między instancjami aktora i obiektu
	(podział aktywności)		Grupa operacji (obszar odpowiedzialności) wykonywanych przez jeden podmiot (aktor, obiekt, komponent, węzeł itp.)
	(obszar aktywności przerywanej)		Grupa operacji, których normalna sekwencja może zostać przerwana w wyniku niestandardowej sytuacji
Wyjaśnienie	Notatka (komentarz)		Komentarz do przedmiotu. Dołącza do komentowanego elementu linią przerywaną

W niektórych źródłach, w szczególności [,], wyróżnia się także byty behawioralne interakcje oraz maszyny skończone,, ale z logicznego punktu widzenia powinny być klasyfikowane jako diagramy.

Niektóre z powyższych podmiotów według implikują je szczegółowy opis na diagramach rozkładu. Na schemacie Najwyższy poziom są oznaczone specjalną ikoną lub etykietą.

Poniższa tabela zawiera opis wszystkich typów relacja UML używany na diagramach do wskazywania relacji między podmiotami.

Tabela 11.3. Relacja

Nazwa	Przeznaczenie	Definicja (semantyka)
Stowarzyszenie		Relacja opisująca znaczącą relację między dwoma lub większą liczbą jednostek. Bardzo ogólna forma relacja
Zbiór		Podtyp skojarzenia opisujący relację „część” – „całość”, w którym „część” może istnieć oddzielnie od „całości”. Romb jest wskazany od strony „całości”. Związek jest wskazany tylko między podmiotami tego samego typu
Kompozycja		Podtyp agregacji, w którym „części” nie mogą istnieć w oderwaniu od „całości”. Z reguły „części” są tworzone i niszczone w tym samym czasie, co „całość”
Zależność		Relacja między dwoma podmiotami, w której zmiana jednego podmiotu (niezależnego) może wpłynąć na stan lub zachowanie innego podmiotu (zależnego). Po stronie strzałki wskazano niezależny podmiot
Uogólnienie		Relacja między bytem generycznym (przodek, rodzic) a bytem wyspecjalizowanym (dziecko, dziecko). Trójkąt jest określony od strony rodzica. Związek jest wskazany tylko między podmiotami tego samego typu
Realizacja		Relacja między podmiotami, w której jeden podmiot definiuje działanie, które drugi podmiot zobowiązuje się wykonać. Relacje są używane w dwóch przypadkach: między interfejsami a klasami (lub komponentami), między przypadkami użycia i współpracą. Strona strzałki wskazuje podmiot, który definiuje akcję (interfejs lub przypadek użycia)

W przypadku powiązania można określić agregację i skład wielość (liczba angielska), która charakteryzuje łączną liczbę wystąpień podmiotów uczestniczących w relacji. Jest to zwykle wskazane po każdej stronie relacji w pobliżu odpowiedniego podmiotu. Wielokrotność można określić w następujący sposób:

- * - dowolna ilość egzemplarzy, w tym brak;

Nieujemna liczba całkowita - krotność jest ściśle ustalona i równa podanej liczbie (na przykład: 1, 2 lub 5);

Zakres nieujemnych liczb całkowitych „pierwsza liczba .. druga liczba” (na przykład: 1..5, 2..10 lub 0..5);

Zakres liczb od określonej wartości początkowej do dowolnej końcowej „pierwszej liczby .. *” (na przykład: 1 .. *, 5 .. * lub 0 .. *);

Wyliczanie nieujemnych liczb całkowitych i zakresów oddzielonych przecinkami (na przykład: 1, 3..5, 10, 15 .. *).

Jeżeli krotność nie jest określona, ​​to przyjmuje się, że jej wartość wynosi 1. Przyjmuje się zawsze, że krotność instancji podmiotów uczestniczących w zależności, uogólnieniu i implementacji wynosi 1.

Poniższa tabela opisuje: mechanizmy rozbudowy używane do wyjaśnienia semantyki bytów i relacji. Ogólnie mechanizm rozszerzenia to ciąg tekstu ujęty w nawiasy lub cudzysłowy.

Tabela 11.4. Mechanizmy rozszerzeń

Nazwa	Przeznaczenie	Definicja (semantyka)
Stereotyp (stereotyp)	« »	Oznaczenie określające semantykę elementu notacji (na przykład: zależność ze stereotypem „włącz” jest uważana za relację włączenia, a klasa ze stereotypem „granicznym” jest klasą graniczną)
Warunek ochrony (stan strażnika)		Warunek logiczny (na przykład: lub [identyfikacja zakończona])
Ograniczenie (ograniczenie)	{ }	Reguła ograniczająca semantykę elementu modelu (na przykład (czas wykonania mniejszy niż 10ms))
Oznaczona wartość (oznaczona wartość)	{ }	Nowa lub kwalifikująca właściwość elementu notacji (na przykład: (wersja = 3.2))

Oprócz stereotypów, wskazanych jako ciąg tekstu w cudzysłowie, w wykresach można stosować stereotypy graficzne. Poniższy rysunek przedstawia przykłady wyświetlania standardowego i stereotypowego.

a) oznaczenie standardowe		b) oznaczenie standardowe ze stereotypem tekstu		c) stereotyp graficzny

Ryż. 11.2. Przykłady standardowego i stereotypowego wyświetlania klas

Diagram to grupa elementów notacji reprezentująca pewien aspekt System informacyjny... Diagramy są zwykle połączonymi wykresami, w których jednostki są wierzchołkami, a relacje są łukami. Poniższa tabela podaje krótki opis Diagramy UML.

Tabela 11.5. Schematy

Diagram			Spotkanie
				według stopnia fizycznej realizacji	wyświetlając dynamikę	według wyświetlanego aspektu
(przypadek użycia)			Wyświetla funkcje systemu, interakcję między aktorami i funkcjami	Logiczny	Statyczny	Funkcjonalny
(klasa)			Wyświetla zestaw klas, interfejsów i relacji między nimi	Logiczne lub fizyczny	Statyczny	Funkcjonalne i informacyjne
(pakiet)			Wyświetla zestaw pakietów i relacje między nimi	Logiczne lub fizyczny	Statyczny	Składnik
Zachowania (zachowanie)	(maszyna stanowa)		Wyświetla stany jednostki i przejścia między nimi podczas jej cyklu życia	Logiczny	Dynamiczny	Behawioralne
	(działalność)		Wyświetla procesy biznesowe w systemie (opis algorytmów zachowania)
	Interakcje (interakcja)	(sekwencja)	Wyświetla sekwencję przekazywania wiadomości między obiektami i aktorami
		(Komunikacja)	Podobny do diagramu sekwencji, ale nacisk kładziony jest na strukturę interakcji między obiektami
Realizacja (realizacja)	(składnik)		Wyświetla komponenty systemu (programy, biblioteki, tabele itp.) oraz powiązania między nimi	Fizyczny	Statyczny	Składnik
	(rozlokowanie)		Wyświetla rozmieszczenie komponentów według hostów, a także ich konfigurację

Standard UML 2.x definiuje również dodatkowe, wysoce wyspecjalizowane diagramy:

Diagram obiektów jest podobny, ale zamiast klas wyświetlane są obiekty;

Diagram czasowy - opisuje stan obiektu w czasie;

Diagram struktury złożonej - opisuje porty (w tym interfejsy) klasy do interakcji z innymi klasami;

Schemat profilu - podobny do opisu zawartych w nich klas;

Diagram przeglądu interakcji jest podobny, ale z ukrytymi fragmentami interakcji (fragmentami ze znacznikiem ref). Jest to kontekst kontekstowy (konceptualny), którego elementy zostaną skonkretyzowane na osobnych diagramach dekompozycji.

W celu powiększenia koncepcyjnego przedstawienia wewnętrznej architektury systemu, większość konstrukcji pozwala na wykorzystanie ustalonych stereotypów graficznych dla tzw. Taki diagram nosi nazwę 1, ale nie należy do listy diagramów zdefiniowanej przez standard UML.

Podczas opracowywania oddzielnego modelu systemu buduje się kilka rodzajów diagramów. Co więcej, podczas opracowywania modelu złożonego systemu z reguły buduje się kilka diagramów tego samego typu. Jednocześnie można nie tworzyć odrębnych typów diagramów, jeśli nie jest to konieczne. Na przykład diagramy i są wymienne; są budowane tylko dla obiektów o złożonym zachowaniu. Poniższa tabela zawiera wskazówki dotyczące potrzeby opracowywania (dopracowywania) diagramów według modelu systemu.

Tabela 11.6. Łączenie modeli i diagramów

W tabeli nie przedstawiono modelu testowego, gdyż w ramach jego budowy nie są opracowywane diagramy, lecz są sprawdzane (testowane) pod kątem kompletności i spójności.

Część diagramów po ich zbudowaniu wymaga opracowania i dopracowania w ramach opracowania następującego modelu ( proces technologiczny). Więc na przykład powinno być wyjaśnione podczas opracowywania. W modelach.

4. Podaj definicję pojęcia „”.

UML to ujednolicony język modelowania graficznego do opisywania, wizualizacji, projektowania i dokumentowania systemów obiektowych. UML ma na celu wsparcie procesu modelowania systemów oprogramowania w oparciu o podejście OO, uporządkowanie relacji koncepcji i koncepcji oprogramowania, odzwierciedlenie problemów skalowania złożonych systemów. Modele w UML są używane na wszystkich etapach cyklu życia systemu oprogramowania, od analizy biznesowej po konserwację systemu. Różne organizacje mogą stosować UML według własnego uznania, w zależności od obszarów problemowych i wykorzystywanych technologii.

Krótka historia UML

Do połowy lat 90. różnych autorów zaproponowało kilkadziesiąt metod modelowania OO, z których każdy używał własnej notacji graficznej. Jednocześnie każda z tych metod miała swoje mocne strony, ale nie pozwalała zbudować wystarczająco kompletnego modelu PS, pokazując go „ze wszystkich stron”, czyli wszystkie niezbędne rzuty (patrz artykuł 1). Ponadto brak standardu modelowania obiektowego utrudniał programistom wybór najbardziej odpowiedniej metody, co uniemożliwiło szerokie zastosowanie podejścia obiektowego do tworzenia oprogramowania.

Na prośbę Object Management Group (OMG) – organizacji odpowiedzialnej za przyjmowanie standardów w zakresie technologii obiektowych i baz danych, pilny problem unifikacji i standaryzacji rozwiązali autorzy trzech najpopularniejszych metod OO – G Buch, D. Rambo i A. Jacobson, którzy zjednoczyli siły, stworzyli UML 1.1, który został zatwierdzony przez OMG w 1997 roku jako standard.

UML to język

Każdy język składa się ze słownictwa i zasad łączenia słów w celu uzyskania znaczących konstrukcji. A więc w szczególności uporządkowane są języki programowania, takie jak UML. Jego charakterystyczną cechą jest to, że słownik języka tworzą elementy graficzne. Każdy znak graficzny ma określoną semantykę, dzięki czemu model stworzony przez jednego programistę może być jednoznacznie zrozumiany przez drugiego, a także narzędzie programowe interpretacja UML. Z tego w szczególności wynika, że ​​model PS przedstawiony w UML może być automatycznie przetłumaczony na język programowania OO (np. Java, C++, VisualBasic), czyli jeśli istnieje dobre narzędzie do modelowania wizualnego obsługujące UML , budując model, otrzymamy przygotowanie kodu programu odpowiadającego temu modelowi.

Należy podkreślić, że UML jest językiem, a nie metodą. Wyjaśnia, z jakich elementów tworzyć modele i jak je czytać, ale nie mówi nic o tym, które modele należy rozwijać iw jakich przypadkach. Aby stworzyć metodę opartą na UML, konieczne jest jej uzupełnienie o opis procesu wytwarzania oprogramowania. Przykładem takiego procesu jest Rational Unified Process, który zostanie omówiony w kolejnych artykułach.

Słownictwo UML

Model jest reprezentowany w postaci encji i relacji między nimi, które są pokazane na diagramach.

Podmioty Czy abstrakcje są głównymi elementami modeli. Istnieją cztery typy encji - strukturalne (klasa, interfejs, komponent, przypadek użycia, współpraca, węzeł), behawioralne (interakcja, stan), grupujące (pakiety) i adnotacyjne (komentarze). Każdy rodzaj podmiotu ma swój własny Reprezentacja graficzna... Encje zostaną szczegółowo omówione podczas eksploracji diagramów.

Relacja pokazać różne relacje między podmiotami. UML definiuje następujące typy relacji:

• Nałóg pokazuje takie powiązanie dwóch bytów, gdy zmiana jednego z nich – niezależnego – może wpłynąć na semantykę drugiego – zależnego. Zależność jest zobrazowana przerywaną strzałką wskazującą od jednostki zależnej do jednostki niezależnej.
• Stowarzyszenie To strukturalna relacja pokazująca, że ​​obiekty w jednej jednostce są powiązane z obiektami w innej. Powiązanie jest przedstawione graficznie jako linia łącząca połączone podmioty. Asocjacje służą do poruszania się między obiektami. Np. powiązanie między klasami „Zamówienie” i „Produkt” może posłużyć z jednej strony do wyszukania wszystkich towarów określonych w danym zamówieniu, a z drugiej do wyszukania wszystkich zamówień, w których występuje dany produkt . Oczywiste jest, że odpowiednie programy muszą wdrożyć mechanizm takiej nawigacji. Jeśli do nawigacji wymagany jest tylko jeden kierunek, jest to oznaczone strzałką na końcu skojarzenia. Szczególnym przypadkiem asocjacji jest agregacja - relacja postaci "całość" - "część". Graficznie jest wyróżniony diamentem na końcu w pobliżu całości bytu.
• Uogólnienie Jest relacją między podmiotem nadrzędnym a podmiotem potomnym. Zasadniczo ta relacja odzwierciedla właściwość dziedziczenia klas i obiektów. Uogólnienie jest pokazane jako linia zakończona trójkątem skierowanym w stronę bytu nadrzędnego. Dziecko dziedziczy strukturę (atrybuty) i zachowanie (metody) rodzica, ale jednocześnie może mieć nowe elementy struktury i nowe metody. UML umożliwia wielokrotne dziedziczenie, gdy jednostka jest powiązana z więcej niż jedną jednostką nadrzędną.
• Realizacja- relacja pomiędzy podmiotem definiującym specyfikację zachowania (interfejs) a podmiotem definiującym implementację tego zachowania (klasą, komponentem). Ta zależność jest powszechnie stosowana w modelowaniu komponentów i zostanie opisana bardziej szczegółowo w kolejnych artykułach.

Schematy. UML udostępnia następujące diagramy:

• Diagramy opisujące zachowanie systemu:
• diagramy stanu,
• diagramy aktywności,
• Schematy obiektów,
• Diagramy sekwencji,
• Schematy współpracy
• Diagramy opisujące fizyczną implementację systemu:
• Schematy składowe
• Schematy wdrożeniowe

Widok kontroli modelu. Pakiety.

Powiedzieliśmy już, że aby model był dobrze rozumiany przez osobę, konieczne jest uporządkowanie go hierarchicznie, pozostawiając niewielką liczbę podmiotów na każdym poziomie hierarchii. UML zawiera sposób organizowania hierarchicznej reprezentacji modelu - pakietów. Każdy model składa się z zestawu pakietów, które mogą zawierać klasy, przypadki użycia oraz inne encje i diagramy. Pakiet może zawierać inne pakiety do tworzenia hierarchii. W UML nie ma oddzielnych diagramów pakietów, ale mogą pojawić się na innych diagramach. Pakiet jest wyświetlany jako prostokąt z zakładką.

Co zapewnia UML.

• hierarchiczny opis złożonego systemu poprzez przydzielanie pakietów;
• sformalizowanie wymagań funkcjonalnych dla systemu z wykorzystaniem aparatu przypadków użycia;
• uszczegółowienie wymagań dla systemu poprzez budowanie diagramów czynności i scenariuszy;
• wyróżnianie klas danych i budowanie koncepcyjnego modelu danych w postaci diagramów klas;
• wyróżnianie klas opisujących interfejs użytkownika i tworzenie schematu nawigacji po ekranie;
• opis procesów interakcji obiektów podczas wykonywania funkcji systemu;
• opis zachowania obiektów w postaci diagramów czynności i stanów;
• opis komponentów oprogramowania i ich interakcji za pośrednictwem interfejsów;
• opis fizycznej architektury systemu.

I ostatni ...

Pomimo całej atrakcyjności UML, trudno byłoby go wykorzystać w modelowaniu rzeczywistego oprogramowania bez narzędzi do modelowania wizualnego. Takie narzędzia pozwalają szybko prezentować diagramy na ekranie wyświetlacza, dokumentować je, generować puste kody programów w różnych językach programowania OO oraz tworzyć schematy baz danych. Większość z nich obejmuje możliwość reengineeringu kodów programów - przywracanie określonych rzutów modelu SS poprzez automatyczną analizę kodów źródłowych programów, co jest bardzo ważne dla zapewnienia spójności modelu i kodów oraz przy projektowaniu systemów dziedziczących funkcjonalność poprzednika systemy.