UML to zunifikowany graficzny język modelowania do opisywania, wizualizacji, projektowania i dokumentowania systemów OO. UML ma na celu wsparcie procesu modelowania PS opartego na podejściu OO, uporządkowanie relacji między koncepcjami koncepcyjnymi i programowymi oraz odzwierciedlenie problemów skalowania złożonych systemów. Modele UML są wykorzystywane na wszystkich etapach cyklu życia oprogramowania, od analizy biznesowej po konserwację systemu. Różne organizacje mogą korzystać z UML na swój własny sposób, w zależności od obszarów problemowych i stosowanych technologii.

Krótka historia UML

Do połowy lat 90. różnych autorów zaproponowało kilkadziesiąt metod modelowania obiektowego, 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, aby pokazać 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. Booch , D. Rambo i A. Jacobson, którzy połączyli wysiłki, stworzyli UML w wersji 1.1, zatwierdzonej przez OMG w 1997 roku jako standard.

UML to język

Każdy język składa się ze słownika i zasad łączenia słów w sensowne konstrukcje. A więc w szczególności uporządkowane są języki programowania, takie jak UML. Jego charakterystyczną cechą jest to, że słownictwo 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 przez narzędzie interpretujące UML. Z tego w szczególności wynika, że ​​model PS przedstawiony w UML może zostać automatycznie przetłumaczony na język programowania OO (taki jak Java, C++, VisualBasic), czyli za pomocą dobrego narzędzia do modelowania wizualnego obsługującego UML, budując model , dostaniemy również puste miejsce w kodzie 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, jakie modele iw jakich przypadkach należy opracować. Aby stworzyć metodę opartą na UML, konieczne jest jej uzupełnienie o opis procesu rozwoju PS. 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.

Esencje to abstrakcje będące 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 opisowe (komentarze). Każdy typ jednostki ma swoją własną reprezentację graficzną. Jednostki zostaną szczegółowo omówione podczas studiowania diagramów.

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

• Nałóg pokazuje taki związek między dwoma bytami, gdy zmiana jednego z nich - niezależnego - może wpłynąć na semantykę drugiego - zależnego. Zależność jest reprezentowana przez kropkowaną strzałkę wskazującą od jednostki zależnej do jednostki niezależnej.
• Stowarzyszenie to strukturalna relacja pokazująca, że ​​obiekty jednej jednostki są powiązane z obiektami innej. Graficznie asocjacja jest pokazana jako linia łącząca powiązane podmioty. Asocjacje służą do poruszania się między obiektami. Na przykład skojarzenie między klasami „Zamówienie” i „Produkt” może posłużyć do znalezienia wszystkich produktów określonych w konkretnym zamówieniu – z jednej strony lub wszystkich zamówień zawierających ten produkt – z drugiej. Oczywiste jest, że odpowiednie programy muszą wdrożyć mechanizm zapewniający taką nawigację. Jeśli nawigacja jest wymagana tylko w jednym kierunku, jest to oznaczone strzałką na końcu skojarzenia. Szczególnym przypadkiem asocjacji jest agregacja – relacja formy „całość” – „część”. Graficznie jest wyróżniony rombem na końcu w pobliżu całości bytu.
• Uogólnienie jest relacją między jednostką nadrzędną a jednostką podrzędną. 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). Zależność ta jest powszechnie stosowana podczas modelowania komponentów i zostanie opisana bardziej szczegółowo w kolejnych artykułach.

Schematy. UML zawiera następujące diagramy:

• Diagramy opisujące zachowanie systemu:
• Diagramy stanów (diagramy stanów),
• diagramy aktywności,
• Schematy obiektów,
• Diagramy sekwencji,
• Schematy współpracy;
• Schematy opisujące fizyczną implementację systemu:
• Schematy składowe;
• Diagramy 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, co pozwala na tworzenie hierarchii. UML nie udostępnia oddzielnych diagramów pakietów, ale mogą one pojawiać się w innych diagramach. Pakiet jest wyświetlany jako prostokąt z zakładką.

Co zapewnia UML.

• hierarchiczny opis złożonego systemu poprzez podświetlanie pakietów;
• sformalizowanie wymagań funkcjonalnych dla systemu z wykorzystaniem aparatu przypadków użycia;
• uszczegółowienie wymagań dla systemu poprzez konstruowanie diagramów czynności i scenariuszy;
• dobór klas danych i budowa koncepcyjnego modelu danych w postaci diagramów klas;
• wybór klas opisujących interfejs użytkownika oraz stworzenie schematu nawigacji po ekranie;
• opis procesów interakcji obiektów w realizacji 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 używać w prawdziwym modelowaniu PS 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 odwzorowań modelu PS poprzez automatyczną analizę kodów źródłowych programów, co jest bardzo ważne dla zapewnienia zgodności modelu i kodów oraz przy projektowaniu systemów dziedziczących funkcjonalność systemów poprzednich .

Chyba każdy słyszał w dzieciństwie takie powiedzenie jak „ Siedem razy zmierz cięcie raz„. problem w najbardziej prawidłowy sposób. W tym pomagamy UML.

Co to jest UML?

Jeśli spojrzysz na zdjęcia w wyszukiwarkach, staje się jasne, że UML- to jest coś o schematach, strzałkach i kwadratach. Ważne jest to, że UML tłumaczy się jako Ujednolicony język modelowania. Ważne jest tutaj słowo Unified. Oznacza to, że nasze obrazy będą zrozumiane nie tylko przez nas, ale także przez innych, którzy znają UML. Okazuje się, że to taki międzynarodowy język do rysowania diagramów.

Jak mówi Wikipedia

UML to graficzny język opisu do modelowania obiektowego w zakresie tworzenia oprogramowania, modelowania procesów biznesowych, inżynierii systemów i mapowania struktur organizacyjnych.

Najbardziej interesującą rzeczą, o której nie wszyscy myślą lub zgadują, jest to, że UML ma specyfikacje. Co więcej, istnieje nawet specyfikacja UML2. Więcej informacji o specyfikacji można znaleźć na stronie Object Management Group. Obecnie grupa ta zajmuje się opracowywaniem specyfikacji UML. Interesujące jest również to, że UML nie ogranicza się do opisu struktury klas. Istnieje wiele rodzajów diagramów UML. Krótki opis typów diagramów UML można zobaczyć w tej samej Wikipedii: Diagramy UML lub w filmie Timura Batyrshinova Przegląd diagramów UML. UML jest również szeroko stosowany w opisie różnych procesów, na przykład tutaj: Pojedyncze logowanie przy użyciu JWT. Wracając do wykorzystania diagramów klas UML, warto zwrócić uwagę na książkę Head First: Design Patterns, w której wzorce są ilustrowane przez te same diagramy UML. Okazuje się, że rzeczywiście używa się UML. I okazuje się, że poznanie i zrozumienie jego zastosowania jest całkiem przydatną umiejętnością.

Wniosek

Zobaczmy, jak możesz pracować z tym samym UML z poziomu IDE. Jako IDE, weź IntelliJ Idea. Jeśli używasz IntelliJ Idea Ultimate, wtedy będziemy mieć zainstalowaną wtyczkę "po wyjęciu z pudełka" Obsługa UML Umożliwia automatyczne generowanie pięknych diagramów klas. Np. poprzez Ctrl+N lub pozycję menu „Nawiguj” -> „Klasa” przejdź do klasy Lista tablic. Teraz z menu kontekstowego przy nazwie klasy wybierz „Diagram” -> „Pokaż wyskakujące okno diagramu”. W efekcie otrzymujemy piękny wykres:

Ale co, jeśli chcesz narysować siebie, a nawet nie ma wersji Ultimate Idea? Jeśli korzystamy z IntelliJ Idea Community Edition, to nie mamy innego wyjścia. Aby to zrobić, musisz zrozumieć, jak działa taki schemat UML. Najpierw musimy zainstalować Graphviz . Jest to zestaw narzędzi do wizualizacji wykresów. Jest używany przez wtyczkę, z której będziemy korzystać. Po instalacji musisz dodać katalog kosz z zainstalowanego katalogu grafiz do zmiennej środowiskowej ŚCIEŻKA. Następnie w IntelliJ Idea wybierz z menu Plik -> Ustawienia. W oknie „Ustawienia” wybierz kategorię „Wtyczki”, kliknij przycisk „Przeglądaj repozytoria” i zainstaluj wtyczkę integracyjną PlantUML. Dlaczego ten jest taki dobry? RoślinUML? Używa języka opisu wykresów o nazwie „ kropka" a to pozwala być bardziej uniwersalnym, bo tego języka używa nie tylko PlantUML. Co więcej, wszystko, co zrobimy poniżej, można zrobić nie tylko w IDE, ale także w serwisie online planttext.com. Po zainstalowaniu Wtyczka PlantUML będziemy mogli tworzyć diagramy UML poprzez "Plik" -> "Nowy". Stwórzmy diagram typu "Klasa UML". W tym czasie automatycznie generowany jest szablon z przykładem. Usuńmy jego zawartość i stworzyć własny, uzbrojony w artykuł z Habr: Class Relations - from UML to code... A żeby zrozumieć, jak to przedstawić w tekście, weźmy podręcznik PlantUML: plantuml class-diagram... W nim, na na samym początku pojawia się znak, jak opisać relacje:

O samych połączeniach możemy jeszcze zajrzeć tutaj: „Relacje między klasami w UML. Przykłady”. Na podstawie tych materiałów zacznijmy tworzyć nasz diagram UML. Dodaj następującą treść opisującą dwie klasy: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Aby zobaczyć wynik w Idea, wybierz "Widok" -> "Narzędzia Windows" -> "PlantUML". Otrzymamy tylko dwa kwadraty oznaczające klasy. Jak wiemy, obie te klasy implementują interfejs List. Ta relacja klas nazywa się - implementacja (realizacja). Do zobrazowania takiego związku służy strzałka z linią przerywaną. Narysujmy to: Lista listy interfejsów< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о pakiet prywatny element array: ~ Object elementData Teraz chcemy pokazać, że ArrayList zawiera kilka obiektów. W takim przypadku typem połączenia będzie - zbiór(zbiór). Agregatem w tym przypadku jest ArrayList , ponieważ zawiera inne obiekty. Wybieramy agregację, ponieważ obiekty na liście mogą żyć bez listy: nie są jej integralną częścią. Ich czas życia nie jest związany z czasem życia listy. Jednostka z łaciny jest tłumaczona jako „zebrana”, czyli coś, co składa się z czegoś. Na przykład w życiu istnieje zespół pompujący, który składa się z pompy i silnika. Samo urządzenie można zdemontować, pozostawiając niektóre jego elementy. Na przykład, aby sprzedać lub umieścić w innej jednostce. Więc to jest na liście. Wyraża się to w postaci pustego rombu na jednostce i ciągłej linii. Ujmijmy to w ten sposób: class Object ( ) ArrayList o- Object Teraz chcemy pokazać, że w przeciwieństwie do ArrayList , klasa LinkedList zawiera kontenery Node, które odwołują się do przechowywanych danych. W takim przypadku węzły są częścią samej LinkedList i nie mogą żyć oddzielnie. Węzeł nie jest bezpośrednio przechowywaną treścią, a jedynie zawiera odniesienie do niej. Na przykład, kiedy dodajemy wiersz do LinkedList, dodajemy nowy Node , który zawiera link do tego wiersza, a także link do poprzedniego i następnego Node . Ten rodzaj połączenia nazywa się kompozycja(kompozycja). Aby wyświetlić kompozyt (składający się z części), rysowany jest wypełniony robic, do którego prowadzi ciągła linia. Teraz napiszmy to jako tekstowe wyświetlanie linku: class Node ( ) LinkedList * -- Node A teraz musimy nauczyć się wyświetlać inny ważny typ linku - nałóg(relacja zależności). Jest używany, gdy jedna klasa korzysta z innej, a klasa nie zawiera używanej klasy i nie jest jej następcą. Na przykład LinkedList i ArrayList mogą utworzyć ListIterator . Wyświetlmy to jako kropkowane strzałki: class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Możesz podać tyle szczegółów, ile potrzebujesz. Wszystkie oznaczenia są wymienione tutaj: "PlantUML - Diagram klas". Ponadto w rysowaniu takiego schematu nie ma nic nadprzyrodzonego, a podczas pracy nad zadaniami możesz szybko narysować go ręcznie. To rozwinie twoje umiejętności myślenia o architekturze aplikacji i pomoże ci wykryć wady struktury klas na wczesnym etapie, a nie po spędzeniu dnia na implementacji niewłaściwego modelu. Myślę, że to dobry powód, aby spróbować?)

Automatyzacja

Istnieje wiele sposobów automatycznego generowania diagramów PlantUML. Na przykład w pomysły Istnieje wtyczka SketchIT, ale nie rysuje ich poprawnie. Na przykład implementacja interfejsów jest rysowana niepoprawnie (wyświetlana jako dziedziczenie). Istnieją również przykłady w Internecie, jak wbudować to w cykl życia kompilacji projektu. Powiedzmy dla Maven jest przykład używający uml-java-doclet . Aby pokazać, jak to się robi, użyjmy archetypu Maven, aby szybko stworzyć projekt Maven. Wykonajmy polecenie: mvn archetype:generate W kwestii wyboru filtra ( Wybierz liczbę lub zastosuj filtr) pozostaw wartość domyślną, naciskając klawisz Enter. Zawsze będzie” maven-archetyp-szybki start Wybieramy najnowszą wersję. Następnie odpowiadamy na pytania i kończymy tworzenie projektu:

Ponieważ Maven nie jest tematem tego artykułu, odpowiedzi na pytania dotyczące Mavena można znaleźć w Centrum użytkowników Mavena. W wygenerowanym projekcie otwórz plik opisu projektu do edycji, pom.xml. Skopiujemy zawartość z opisu instalowania do niego uml-java-docklet. Artefaktu użytego w opisie nie można znaleźć w repozytorium Maven Central. Ale zadziałało to dla mnie z tym: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0 . Oznacza to, że w tym opisie wystarczy wymienić Identyfikator grupy od " info.leadinglight" na " com.chfourie" i umieść wersję " 1.0.0 ". Następnie możemy wykonać w katalogu, w którym znajduje się plik pom.xml te polecenia to: mvn clean install i mvn javadoc:javadoc . Teraz, jeśli otworzymy wygenerowaną dokumentację (docelowy eksplorator\site\apidocs\index.html), zobaczymy diagramy UML. Nawiasem mówiąc, implementacja jest już poprawnie wyświetlana tutaj)

Wniosek

Jak widać, UML umożliwia wizualizację struktury Twojej aplikacji. Ponadto UML nie ogranicza się tylko do tego. Za pomocą UML możesz opisać różne procesy w Twojej firmie lub opisać proces biznesowy, w ramach którego działa napisana przez Ciebie funkcja. To, na ile UML przyda się Tobie osobiście, zależy od Ciebie, ale znalezienie czasu i poznanie go bardziej szczegółowo i tak się przyda. #Viacheslav Rosyjska wersja tego postu: diagram UML Java na CodeGym

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 tworzenia abstrakcyjnego modelu systemu. UML został stworzony, aby umożliwić definiowanie, wizualizację, dokumentację i projektowanie 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 potrzebna?

Korzystanie z 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, projektowania systemów, a także wyświetlania struktur organizacyjnych.

Za pomocą UML twórcy oprogramowania mogą zapewnić pełną zgodność w zapisie graficznym używanym do reprezentowania wspó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 wykresó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 określonego obszaru tematycznego i udostępnia tylko klasy obiektów aplikacji.
• 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 jest całkowicie statycznym diagramem struktury. Ma na celu zademonstrować podział konkretnego systemu oprogramowania na różne elementy konstrukcyjne, a także relacje między nimi. Diagram komponentów UML może wykorzystywać wszelkiego rodzaju modele, biblioteki, pliki, pakiety, pliki wykonywalne i wiele innych elementów jako takie.

Schemat struktury kompozytowej/kompozytowej

Diagram struktury kompozytowej/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 podgatunkiem jest diagram współpracy UML, który służy do demonstrowania ról i interakcji różnych klas w ramach współpracy. Są bardzo przydatne, jeśli potrzebujesz modelować wzorce projektowe.

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

Schemat wdrożenia

Ten diagram służy do modelowania działających węzłów, a także wszelkiego rodzaju artefaktów, które zostały na nich wdrożone. W UML 2 artefakty są wdrażane w różnych węzłach, podczas gdy w pierwszej wersji wdrażane były tylko komponenty. W związku z tym diagram wdrażania UML jest używany głównie w drugiej wersji.

Zależność manifestacji powstaje między artefaktem a implementowanym przez niego komponentem.

Schemat obiektu

Ten widok pozwala zobaczyć pełną lub częściową migawkę systemu tworzonego w określonym momencie. W pełni wyświetla wszystkie instancje klas danego systemu, wskazując aktualne wartości ich parametrów, a także relacje między nimi.

Schemat pakietu

Diagram ten ma charakter strukturalny, a jego główną zawartością są wszelkiego rodzaju pakiety, a także relacje między nimi. W tym przypadku nie ma ścisłego rozdzielenia kilku schematów strukturalnych, w wyniku czego ich użycie jest najczęściej używane 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 użycie odbywa się w celu zapewnienia organizacji kilku elementów w grupy według określonego atrybutu, 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, zjednoczonych przepływami wychodzącymi z dane wyjściowe jednego węzła na dane wejściowe innego.

Diagram aktywności UML jest często używany do modelowania różnych procesów biznesowych, obliczeń równoległych i sekwencyjnych. Między innymi modelują wszelkiego rodzaju procedury technologiczne.

schemat automatu

Ten widok nazywa się i nieco inaczej - diagramem stanów UML. Posiada przedstawioną 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, a także reakcja obiektu na takie zdarzenia. Automat stanów używany przez diagram stanów UML jest dołączony do oryginalnego elementu i używany do definiowania zachowania jego instancji.

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

Diagramy przypadków użycia

Diagram przypadków użycia UML wyświetla wszystkie relacje, które występują między aktorami, a także różne przypadki użycia. Jego głównym zadaniem jest zapewnienie pełnoprawnych środków, za pomocą których klient, użytkownik końcowy lub jakiś programista mogą wspólnie omówić zachowanie i funkcjonalność konkretnego systemu.

Jeśli diagram przypadków użycia UML jest wykorzystywany w procesie modelowania systemu, analityk zamierza:

• Wyraźnie oddziel modelowany system od jego 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.

W przypadku tworzenia diagramu użytkowania w UML, procedura rozpoczyna się od opisu tekstowego, który uzyskuje się podczas pracy z klientem. Jednocześnie warto zwrócić uwagę na fakt, że różne wymagania niefunkcjonalne są całkowicie pomijane w procesie kompilowania modelu przypadków użycia, a dla nich zostanie już utworzony osobny dokument.

Komunikacja

Diagram komunikacyjny, podobnie jak diagram sekwencji UML, jest przechodni, czyli wyraża interakcję, ale jednocześnie demonstruje ją na różne sposoby i w razie potrzeby z wymaganym stopniem dokładności można go przekształcić w inne.

Diagram komunikacyjny odzwierciedla interakcje zachodzące między różnymi elementami złożonej struktury, a także role współpracy. Jego główna różnica w stosunku do diagramu sekwencji polega na tym, że wyraźnie wskazuje 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 relacji w taki sam sposób, jak w diagramie obiektowym. Jeśli istnieje potrzeba zachowania kolejności wiadomości w tym dowolnym formacie, są one numerowane chronologicznie. Czytanie tego diagramu rozpoczyna się od początkowej wiadomości 1.0, a następnie jest kontynuowane w kierunku, w którym wiadomości są przesyłane z jednego obiektu do drugiego.

W większości takie diagramy pokazują dokładnie te same informacje, które dostarcza nam diagram sekwencji, ale ponieważ wykorzystuje inny sposób prezentacji informacji, pewne rzeczy na jednym diagramie są znacznie łatwiejsze do ustalenia niż na innym. Warto również zauważyć, że diagram komunikacji wyraźniej pokazuje, z jakimi elementami oddziałuje każdy pojedynczy element, a diagram sekwencji wyraźniej pokazuje, w jakiej kolejności przeprowadzane są interakcje.

diagram sekwencyjny

Diagram sekwencji UML pokazuje interakcje między kilkoma obiektami, które są uporządkowane według czasu ich wystąpienia. Taki diagram pokazuje uporządkowaną w czasie interakcję między kilkoma 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 reprezentujące aktywność danego obiektu lub pełnienie przez niego jakiejś funkcji.

Schemat współpracy

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

Ponieważ diagramy sekwencji i diagramy komunikacji są po prostu różnymi widokami tych samych procedur, Rational Rose zapewnia możliwość tworzenia diagramu sekwencji komunikacji na podstawie diagramu sekwencji lub odwrotnie, a także synchronizuje je całkowicie automatycznie.

Diagramy przeglądu interakcji

Są to diagramy UML, które należą do pewnego rodzaju diagramów aktywności i zawierają zarówno elementy sekwencji, jak i konstrukcje przepływu sterowania.

Warto zauważyć, że format ten łączy w sobie Collaboration i Sequence diagram, co daje możliwość rozważenia interakcji pomiędzy kilkoma obiektami w tworzonym systemie z różnych punktów widzenia.

Schemat czasowy

Reprezentuje alternatywną wersję diagramu sekwencji, która wyraźnie pokazuje zmianę stanu na linii życia w określonej skali czasowej. 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 wykorzystania 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.
• Używając tego języka, system można opisać z niemal każdego możliwego punktu widzenia, a różne aspekty jego zachowania są opisane w ten sam sposób.
• 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 i dość aktywnie się rozwija.

niedogodności

Pomimo tego, że konstrukcja diagramów UML ma wiele zalet, często krytykuje się je 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 sporo zbędnych lub prawie bezużytecznych konstrukcji i schematów, a najczęściej taka krytyka trafia do wersji drugiej, a nie pierwszej, bo w nowszych wersjach jest więcej „komitetowych” kompromisów.
• Różne nieścisłości w semantyce. 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, które są precyzyjnie definiowane za pomocą 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ładność opisu samego języka wpływa zarówno na użytkowników, jak i dostawców narzędzi, prowadząc ostatecznie do niezgodności narzędzi ze względu na unikalny sposób traktowania różnych specyfikacji.
• Problemy w procesie wdrażania i badania. Wszystkie powyższe problemy stwarzają pewne trudności w procesie wdrażania i uczenia się UML, a jest to szczególnie prawdziwe, gdy kierownictwo zmusza inżynierów do korzystania z niego, gdy brakuje im wcześniejszych umiejętności.
• Kod odzwierciedla kod. Inna opinia jest taka, że ​​to nie piękne i atrakcyjne modele są ważne, ale bezpośrednio działające systemy, czyli kod jest projektem. Zgodnie z tym poglądem istnieje potrzeba opracowania wydajniejszego sposobu pisania oprogramowania. UML jest ceniony w podejściach, które kompilują modele w celu ponownego wygenerowania pliku wykonywalnego lub kodu źródłowego. 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 interpretujące UML może założyć lub określić.
• 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 przypadku każdej standardowej 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, jeśli język programowania nie jest zgodny z głównymi zasadami ortodoksyjnej doktryny obiektowej, czyli nie stara się działać zgodnie z zasadami OOP.
• Stara się być wszechstronna. UML jest językiem modelowania ogólnego przeznaczenia, który stara się być kompatybilny z dowolnym obecnie istniejącym językiem przetwarzania. W kontekście konkretnego projektu, aby zespół projektowy mógł osiągnąć ostateczny cel, konieczne jest wybranie odpowiednich cech tego języka. Ponadto możliwe sposoby ograniczania zakresu użycia UML w danym obszarze przechodzą przez formalizm, który nie jest w pełni sformułowany, ale sam jest przedmiotem krytyki.

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

11.1. Struktura zunifikowanego języka modelowania

Ujednolicony język modelowania (UML) jest obecnie de facto standardem opisu (dokumentowania) wyników projektowania i rozwijania systemów obiektowych. Rozwój UML rozpoczął w 1994 roku Grady Booch i James Rumbaugh z Rational Software. Jesienią 1995 roku dołączył do nich Ivar Jakobson, 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”);

UML 2.4.1 - „ISO / IEC 19505-1: 2012. Technologia informacyjna. Zunifikowany język modelowania grup zarządzania obiektami (OMG UML). Część 1. Infrastruktura” (ang. „Technologia informacyjna -- zunifikowany język modelowania grupy zarządzania obiektami ( OMG UML) - Część 1: Infrastruktura") i "ISO / IEC 19505-2: 2012. Technologia informacyjna. Zunifikowany język modelowania grup zarządzania obiektami (OMG UML). Część 2. Nadbudowa" (angielski "Technologia informacyjna - Zunifikowane modelowanie grupy zarządzania obiektami Język (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ęzyka, przede wszystkim jego słów i fraz.

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

Zatem w odniesieniu do UML semantyka i składnia określają styl prezentacji (budowanie modeli), który łączy języki naturalne i formalne w celu przedstawienia podstawowych pojęć (elementów modelu) oraz mechanizmów ich rozszerzania.

11.3. Notacja UML

Notacja to graficzna interpretacja semantyki dla jej wizualnej reprezentacji.

UML definiuje trzy typ encji :

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

Grupowanie - element używany do jakiegoś semantycznego powiązania elementów diagramu;

Objaśnienie (opisowe) - 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. Esencje

Rodzaj	Imię	Przeznaczenie	Definicja (semantyka)
Strukturalny	(klasa)		Zestaw obiektów, które mają wspólną strukturę i zachowanie
	(obiekt)		Abstrakcja rzeczywistego lub wyimaginowanego bytu z dobrze zdefiniowanymi granicami pojęciowymi, indywidualnością (tożsamością), stanem i zachowaniem. Z punktu widzenia UML obiekty są instancjami klas (instancjami encji)
	(aktor)	Inżynier usługi ścieżek	Podmiot zewnętrzny w stosunku do systemu, który wchodzi w interakcję z systemem i wykorzystuje jego funkcjonalność do osiągania określonych celów lub rozwiązywania określonych problemów. Aktor jest więc zewnętrznym źródłem lub odbiorcą informacji.
	(przypadek użycia)		Opis czynności wykonywanych przez system, które prowadzą do wyniku istotnego dla aktora
	(stan)		Opis momentu w życiu jednostki, kiedy spełnia ona jakiś 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	Zestaw operacji definiujący usługę (zestaw 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ą). Szczególne przypadki pakietu to system i model
	(fragment)		Obszar szczególnej interakcji aktora i instancji 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 kolejność wykonywania może zostać przerwana w wyniku nietypowej sytuacji
wyjaśniający	Notatka (komentarz)		Komentarz elementu. Dołączony do komentowanego elementu linią przerywaną

Niektóre źródła, w szczególności [ , ], również wyróżniają byty behawioralne interakcje I maszyny państwowe, ale z logicznego punktu widzenia należy je zaklasyfikować jako diagramy.

Niektóre z powyższych jednostek zgodnie z implikują ich szczegółowy opis na diagramach dekompozycji. Na schemacie najwyższego poziomu są one oznaczone specjalną ikoną lub etykietą.

Poniższa tabela opisuje każdy typ relacje UML używany na diagramach do wskazywania relacji między podmiotami.

Tabela 11.3. Relacje

Imię	Przeznaczenie	Definicja (semantyka)
Stowarzyszenie		Relacja opisująca znaczącą relację między dwoma lub większą liczbą jednostek. Najbardziej ogólny rodzaj relacji
Zbiór		Podgatunek stowarzyszenia opisujący relację „część”–„całość”, w której „część” może istnieć oddzielnie od „całości”. Romb jest wskazany od strony „całości”. Związek jest określony tylko między podmiotami tego samego typu
Kompozycja		Podgatunek agregacji, w którym „części” nie mogą istnieć w oderwaniu od „całości”. Z reguły „części” są tworzone i niszczone jednocześnie z „całością”
Zależność		Relacja między dwoma podmiotami, w której zmiana jednego podmiotu (niezależnego) może wpłynąć na stan lub zachowanie drugiego podmiotu (zależnego). Po stronie strzałki wskazano niezależny podmiot
Uogólnienie		Związek pomiędzy bytem uogólnionym (przodek, rodzic) a bytem wyspecjalizowanym (dziecko, córka). Trójkąt jest wskazany od strony rodzica. Związek jest określony tylko między podmiotami tego samego typu
Realizacja		Relacja między podmiotami, w której jeden podmiot określa działanie, które inny 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ą. Bok strzałki wskazuje podmiot, który definiuje akcję (interfejs lub przypadek użycia)

W przypadku powiązania, agregacji i składu można określić wielość (liczba angielska), która charakteryzuje łączną liczbę wystąpień podmiotów uczestniczących w relacji. Z reguły jest to wskazane po każdej stronie relacji w pobliżu odpowiedniego podmiotu. Wielość 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śli krotność nie jest określona, ​​przyjmuje się, że jej wartość wynosi 1. Przyjmuje się, że liczność wystąpień jednostek zaangażowanych w zależność, uogólnienie i implementację wynosi 1.

Poniższa tabela zawiera opis mechanizmy rozprężne służy do udoskonalania semantyki bytów i relacji. Ogólnie mechanizm rozwinięcia to ciąg tekstu ujęty w nawiasy lub cudzysłowy.

Tabela 11.4. Mechanizmy rozszerzeń

Imię	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 „granica” jest klasą graniczną)
stan strażnika (stan strażnika)		Warunek logiczny (na przykład: lub [identyfikacja wykonana])
Ograniczenie (ograniczenie)	{ }	Reguła ograniczająca semantykę elementu modelu (na przykład (czas wykonania mniejszy niż 10 ms))
Oznaczona wartość (oznaczona wartość)	{ }	Nowa lub kwalifikująca się właściwość elementu notacji (na przykład: (wersja = 3.2))

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

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

Ryż. 11.2. Przykłady standardowego i stereotypowego mapowania klas

Diagram to grupa elementów notacji, aby pokazać pewien aspekt tworzonego systemu informacyjnego. Diagramy są zwykle połączonymi wykresami, w których jednostki są wierzchołkami, a relacje są łukami. Poniższa tabela zawiera krótki opis diagramów UML.

Tabela 11.5. Schematy

Diagram			Cel, powód
				w zależności od stopnia fizycznego wykonania	wyświetlając dynamikę	według wyświetlanego aspektu
(przypadek użycia)			Wyświetla funkcje systemu, interakcje między aktorami i funkcjami	logiczny	statyczny	funkcjonalny
(klasa)			Wyświetla zestaw klas, interfejsów i relacji między nimi	Boole'a lub fizyczny	statyczny	Informacje funkcjonalne
(pakiet)			Wyświetla zestaw pakietów i ich relacji	Boole'a lub fizyczny	statyczny	Składnik
zachowanie (zachowanie)	(maszyna stanowa)		Wyświetla stany encji i przejścia między nimi podczas cyklu życia	logiczny	Dynamiczny	behawioralny
	(czynność)		Wyświetla procesy biznesowe w systemie (opis algorytmów zachowania)
	Interakcje (interakcja)	(sekwencja)	Wyświetla sekwencję komunikatów przekazywanych między obiektami i aktorami
		(Komunikacja)	Podobny do diagramu sekwencji, ale główny nacisk kładziony jest na strukturę interakcji między obiektami
Realizacje (realizacja)	(składnik)		Wyświetla komponenty systemu (programy, biblioteki, tabele itp.) oraz powiązania między nimi	Fizyczny	statyczny	Składnik
	(zastosowanie)		Wyświetla rozmieszczenie komponentów według węzłów sieci, a także ich konfigurację

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

Diagram obiektów (diagram obiektów) - podobny, ale zamiast klas wyświetlane są obiekty;

Wykres czasowy – opisuje stan obiektu w czasie;

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

Diagram profilu (diagram profilu) - podobny do opisu zawartych w nich klas;

Diagram przeglądu interakcji - podobny, ale z ukrytymi fragmentami interakcji (fragmenty z etykietą ref). Jest to kontekst kontekstowy (konceptualny), którego elementy zostaną określone na osobnych diagramach dekompozycji.

W celu powiększenia koncepcyjnego przedstawienia wewnętrznej architektury systemu większość konstrukcji pozwala na wykorzystanie ugruntowanych 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 typó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 nie musisz tworzyć osobnych widoków wykresów, jeśli nie musisz. Na przykład diagramy i są wymienne, budowane tylko dla obiektów o złożonym zachowaniu. Poniższa tabela zawiera zalecenia dotyczące konieczności opracowania (doprecyzowania) diagramów dla modeli systemów.

Tabela 11.6. Łączenie modeli i diagramów

Powyższa tabela nie przedstawia 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 kolejnego modelu (procesu technologicznego). Więc na przykład powinno być wyjaśnione podczas opracowywania. w modelach.

4. Zdefiniuj termin „”.

Wszystkie diagramy UML można warunkowo podzielić na dwie grupy, z których pierwsza to diagramy ogólne. Diagramy ogólne są praktycznie niezależne od przedmiotu modelowania i mogą być stosowane w dowolnym projekcie oprogramowania bez względu na obszar tematyczny, obszar decyzyjny itp.

1.5.1. Schemat użytkowania

Schemat użytkowania(diagram przypadków użycia) jest najbardziej ogólną reprezentacją funkcjonalnego celu systemu.

Diagram użytkowania ma odpowiedzieć na główne pytanie modelowania: co system robi w świecie zewnętrznym?

W diagramie użycia używane są dwa typy encji głównych: przypadki użycia 1 i aktorzy 2, pomiędzy którymi ustanawiane są następujące główne typy relacji:

• związek między aktorem a przypadkiem użycia 3 ;
• generalizacja między aktorami 4 ;
• uogólnienie przypadków użycia 5 ;
• zależności (różnego rodzaju) między przypadkami użycia 6 .

Diagram użycia, jak każdy inny, może mieć komentarze 7 . Ponadto zdecydowanie zaleca się to zrobić, aby poprawić czytelność wykresów.

Poniżej przedstawiono główne elementy notacji użytej w schemacie użytkowania. Szczegółowy opis znajduje się w punkcie 2.2.

1.5.2. diagram klas

diagram klas(diagram klas) jest głównym sposobem opisu struktury systemu.

Nie jest to zaskakujące, ponieważ UML jest przede wszystkim językiem zorientowanym obiektowo, a klasy są głównym (jeśli nie jedynym) blokiem konstrukcyjnym.

Na diagramie klas używany jest jeden główny typ encji: klasy 1 (w tym liczne szczególne przypadki klas: interfejsy, typy pierwotne, klasy asocjacyjne i wiele innych), pomiędzy którymi ustanawiane są następujące główne typy relacji:

• powiązanie między klasami 2 (z wieloma dodatkowymi szczegółami);
• generalizacja między klasami 3 ;
• zależności (różnego rodzaju) między klasami 4 oraz między klasami i interfejsami.

Poniżej przedstawiono niektóre elementy notacji użytej na diagramie klas. Szczegółowy opis znajduje się w rozdziale 3 .

1.5.3. schemat automatu

schemat automatu(diagram automatu stanów) jest jednym ze sposobów szczegółowego opisu zachowania w UML w oparciu o jawną alokację stanów i opis przejść między stanami.

W istocie diagramy automatów, jak sama nazwa wskazuje, są grafem przejść stanów (patrz rozdział 4), obciążonym wieloma dodatkowymi szczegółami i szczegółami.

W schemacie automatu używany jest jeden główny typ bytów - stany 1 , oraz jeden typ relacji - przejścia 2 , ale dla obu zdefiniowano wiele odmian, przypadków specjalnych i dodatkowych oznaczeń. Wymienienie ich wszystkich we wstępnej recenzji nie ma sensu.

Szczegółowy opis wszystkich odmian schematów automatów znajduje się w rozdziale 4.2, a poniższy rysunek przedstawia tylko główne elementy notacji użytej w schemacie automatu.

1.5.4. Diagram aktywności

Diagram aktywności(diagram aktywności) - sposób opisania zachowania na podstawie wskazania przepływów sterowania i przepływów danych.

Diagram aktywności to kolejny sposób na opisanie zachowania, który wizualnie przypomina stary dobry schemat blokowy. Jednak dzięki unowocześnionej notacji, zgodnej z podejściem obiektowym, a co najważniejsze, dzięki nowemu komponentowi semantycznemu (swobodnej interpretacji sieci Petriego) diagram aktywności UML jest potężnym narzędziem opisu zachowania systemu.

W diagramie aktywności zastosowano jeden główny typ encji - akcja 1 , oraz jeden typ relacji - przejścia 2 (przekazywanie kontroli i danych). Wykorzystywane są również takie konstrukcje jak widełki, fuzje, połączenia, rozgałęzienia 3 , które są podobne do bytów, ale tak naprawdę nie są, ale są graficznym sposobem zobrazowania niektórych szczególnych przypadków relacji wielomiejscowych. Semantykę elementów diagramu aktywności omówiono szczegółowo w rozdziale 4. Poniżej przedstawiono główne elementy notacji użytej w diagramie aktywności.

1.5.5. diagram sekwencyjny

diagram sekwencyjny(diagram sekwencji) to sposób opisu zachowania systemu na podstawie wskazania sekwencji przesyłanych komunikatów.

W rzeczywistości diagram sekwencji jest zapisem protokołu konkretnej sesji systemu (lub fragmentu takiego protokołu). W programowaniu obiektowym najważniejszą rzeczą w czasie wykonywania jest przekazywanie komunikatów między współpracującymi obiektami. Jest to kolejność wysyłania wiadomości, która jest wyświetlana na tym diagramie, stąd nazwa.

W diagramie sekwencji używany jest jeden główny typ encji – instancje oddziałujących klasyfikatorów 1 (głównie klas, komponentów i aktorów) oraz jeden typ relacji – połączenia 2, przez które wymieniane są komunikaty 3 . Istnieje kilka sposobów wysyłania wiadomości, które w zapisie graficznym różnią się formą strzałki odpowiadającej relacji.

Ważnym aspektem diagramu sekwencji jest wyraźne przedstawienie upływu czasu. W przeciwieństwie do innych typów diagramów, z wyjątkiem być może diagramów synchronizacji, w diagramie sekwencji ważna jest nie tylko obecność powiązań graficznych między elementami, ale także względne położenie elementów na diagramie. Mianowicie uważa się, że istnieje (niewidoczna) oś czasu, domyślnie skierowana od góry do dołu, a wiadomość, która jest wysyłana później jest rysowana poniżej.

Oś czasu może być skierowana poziomo, w takim przypadku uważa się, że czas płynie od lewej do prawej.

Poniższy rysunek przedstawia główne elementy notacji używanej w diagramie sekwencji. Do oznaczenia samych obiektów oddziałujących stosuje się standardową notację - prostokąt z nazwą instancji klasyfikatora. Wychodząca z niej przerywana linia nazywana jest linią życia (liną życia) 4 . Nie jest to oznaczenie relacji w modelu, ale komentarz graficzny mający na celu skierowanie czytelnika diagramu we właściwym kierunku. Figury w postaci wąskich pasków nałożonych na linię życia również nie są obrazami symulowanych bytów. Jest to komentarz graficzny pokazujący czas, przez jaki obiekt posiada wystąpienie wykonania 5 lub innymi słowy, ma miejsce aktywacja obiektu. Złożone etapy interakcji (połączony fragment) 6 umożliwiają diagramowi sekwencji odzwierciedlenie algorytmicznych aspektów protokołu interakcji. Zobacz rozdział 4, aby uzyskać więcej informacji na temat notacji diagramu sekwencji.

1.5.6. Schemat komunikacji

Schemat komunikacji(diagram komunikacyjny) - sposób opisu zachowania, semantycznie równoważny diagramowi sekwencji.

W rzeczywistości jest to ten sam opis sekwencji wymiany komunikatów wchodzących w interakcje instancji klasyfikatorów, wyrażony tylko za pomocą innych środków graficznych. Co więcej, większość narzędzi może automatycznie konwertować diagramy sekwencji na diagramy komunikacji i odwrotnie.

Tak więc na diagramie komunikacyjnym, a także na diagramie sekwencji, używany jest jeden główny typ encji - instancje oddziałujących klasyfikatorów 1 i jeden typ relacji - połączenia 2 . Jednak nacisk kładzie się tu nie na czas, ale na strukturę relacji między konkretnymi instancjami.

Rysunek przedstawia główne elementy notacji użytej na schemacie komunikacyjnym. Do oznaczenia samych obiektów oddziałujących stosuje się standardową notację - prostokąt z nazwą instancji klasyfikatora. Nie ma znaczenia wzajemne położenie elementów na schemacie współpracy – ważne są tylko powiązania (najczęściej przypadki skojarzeń), którymi przesyłane są komunikaty 3 . Aby wyświetlić kolejność komunikatów w czasie, stosowana jest hierarchiczna numeracja dziesiętna.

1.5.7. Schemat komponentów

Schemat komponentów(schemat komponentów) - pokazuje relacje między modułami (logicznym lub fizycznym) składającym się na symulowany system.

Głównym typem encji w schemacie komponentów są same komponenty 1 , a także interfejsy 2 , poprzez które wskazywane są relacje pomiędzy komponentami. W diagramie komponentów obowiązują następujące zależności:

• implementacje między komponentami a interfejsami (komponent implementuje interfejs);
• zależności między komponentami a interfejsami (komponent wykorzystuje interfejs) 3 .

Rysunek przedstawia główne elementy notacji użytej na schemacie komponentów. Szczegółowy opis znajduje się w rozdziale 3 .

1.5.8. Schemat rozmieszczenia

Schemat rozmieszczenia(schemat wdrożenia) wraz z wyświetleniem składu i relacji elementów systemu pokazuje, jak fizycznie są one rozmieszczane na zasobach obliczeniowych podczas wykonywania.

Zatem w diagramie rozmieszczenia, w porównaniu do diagramu komponentów, dodawane są dwa typy encji: artefakt 1 , który jest implementacją komponentu 2 i węzeł 3 (może być albo klasyfikatorem opisującym typ węzła, albo konkretną instancją), jako jak również związek asocjacji między węzłami 4 , wskazujący, że węzły są fizycznie połączone w czasie wykonywania.

Rysunek przedstawia główne elementy notacji użytej w diagramie rozmieszczenia. Aby pokazać, że jedna jednostka jest częścią innej, stosuje się relację zależności „rozmieszczenia” 5 lub kształt jednej encji jest umieszczany wewnątrz kształtu innej encji 6 . Szczegółowy opis schematu znajduje się w rozdziale 3.