Podstawy zunifikowanego języka modelowania. Ogólna charakterystyka języka UML Jak zrobić diagram UML

Model UML(model UML) jest zbiorem skończonego zbioru konstruktów językowych, z których głównym są byty i relacje między nimi.

Jednostki i relacje samego modelu są instancjami metaklas metamodelu.

Rozpatrując model UML z najbardziej ogólnych pozycji można powiedzieć, że jest to graf (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 – relacjami.. Reszta sekcji zawiera biegle (wstępny), ale pełna recenzja dostępne typy jednostek i relacje. Na szczęście nie ma ich zbyt wielu. W kolejnych rozdziałach książki ponownie rozważane są wszystkie byty i relacje, bardziej szczegółowo i z przykładami.

1.4.1. Esencje

Dla wygody przeglądu encje w UML można podzielić na cztery grupy:

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

Jak można się domyślić, elementy strukturalne mają na celu opisanie struktury. Zazwyczaj jednostki strukturalne obejmują następujące elementy.

Obiekt(obiekt) 1 jest jednostką, która ma niepowtarzalność i zawiera stan i zachowanie.

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

Interfejs(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ąć jakiś 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 jako związek zależności ze stereotypem „udoskonalenia”.

∇∇ W UML 1 istniał mimowolny związek między diagramem współpracy a podmiotem o tej samej nazwie, co nie było do końca prawdziwe i czasami wprowadzało w błąd.

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

Poniżej znajduje się lista nowych schematów i ich nazwy przyjęte w tej książce.

• 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) diagram klas pokazujący relacje diagramów w UML 2.

W dalszej części tego rozdziału opiszemy bardzo krótko wszystkie trzynaście diagramów kanonicznych, aby mieć pewien kontekst i słownictwo na to, co następuje. 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 wykresów. Ogólny szablon prezentacji wykresu znajduje się poniżej.

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

Ten 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. W dalszej części używamy prostokąta jako etykiety wykresu, co nie powinno powodować nieporozumień.

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 trzecia kolumna tabeli zawiera naszym zdaniem rozsądną alternatywę.

Patka. Typy wykresów i tagi

Ujednolicony język modelowania (UML) w ten moment 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 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 dystrybucji. 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. 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").

Najnowsza oficjalna specyfikacja językowa znajduje się 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.

Tak więc w odniesieniu do UML semantyka i składnia określają styl prezentacji (budowanie modelu), który łączy języki naturalne i formalne do prezentacji. podstawowe koncepcje(elementy modelu) i mechanizmy ich rozbudowy.

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 pokazuje krótki opis główne jednostki używane w notacji graficznej i główne sposoby ich wyświetlania.

Tabela 11.1. Esencje

Typ	Nazwa	Przeznaczenie	Definicja (semantyka)
Strukturalny	(klasa)		Wiele obiektów, które mają ogólna struktura 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 korzysta z niego funkcjonalność aby osiągnąć określone cele lub rozwiązać określone problemy. 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
	(państwo)		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 systemowe zapewniające implementację spójnego zestawu interfejsów
	(interfejs)	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 Specyficznej Interakcji Instancji 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 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 oraz maszyny państwowe, ale z logicznego punktu widzenia powinny być klasyfikowane 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

Nazwa	Przeznaczenie	Definicja (semantyka)
Stowarzyszenie		Relacja, która opisuje znaczące połączenie między dwoma lub więcej podmiotami. Bardzo ogólna forma relacje
Zbiór		Podtyp powiązania 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”. Relacja jest określona 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 dwiema jednostkami, w której zmiana jednej jednostki (niezależnej) może wpłynąć na stan lub zachowanie drugiej jednostki (zależnej). Po stronie strzałki wskazano niezależny podmiot
Uogólnienie		Relacja między bytem uogólnionym (przodek, rodzic) a bytem wyspecjalizowanym (dziecko, córka). Trójkąt jest wskazany od strony rodzica. Relacja jest określona 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 podejmuje 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 asocjacji, agregacji i składu możesz określić wielość (wielkość 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ń

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łączonym wykresem, w którym jednostki są wierzchołkami, a relacje są łukami. Poniższa tabela podaje krótki opis Diagramy UML.

Tabela 11.5. Schematy

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 - 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 zdefiniowanych 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; są 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 następującego modelu ( proces technologiczny). Więc na przykład powinno być wyjaśnione podczas opracowywania. w modelach.

4. Zdefiniuj termin „”.

Diagram UML jest językiem specjalistycznym opis graficzny, przeznaczony do modelowania obiektowego w rozwoju różnych oprogramowanie. 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 systemy 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 designie.

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 pewnego Tematyka 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 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, ten diagram może również pokazać interakcje elementów, które są w Struktura wewnętrzna klasa.

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 dla 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ładowe. 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

Widok ten 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, jak również 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 sam w sobie wyraża interakcję, ale jednocześnie ją demonstruje. różne sposoby, a jeśli to konieczne, z wymaganym stopniem dokładności, możesz przekonwertować jeden na drugi.

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 różni się całkowicie swobodnym formatem porządkowania kilku obiektów i relacji w taki sam sposób, jak to się robi na 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ą przekazywane 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 którymi elementami każdy oddziałuje. oddzielny element, natomiast diagram sekwencji wyraźniej pokazuje kolejność występowania interakcji.

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ę pomię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 typ 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 określonego 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

To są wykresy język UML, które odwołują się do różnych diagramów aktywności i zawierają zarówno elementy sekwencji, jak i konstrukcje przepływu sterowania.

Warto zwrócić uwagę na fakt, że podany formatłączy Collaboration i Sequence diagram, które dają możliwość rozważenia interakcji mię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.
• Z pomocą podany język 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.

Wady

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 dość dużo 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 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, co ostatecznie prowadzi do niezgodności narzędzi z powodu unikatowy sposób interpretacja 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 dalszego rozwoju skuteczna metoda oprogramowanie do pisania. UML jest ceniony w podejściach, które kompilują modele do ponownego generowania kodu wykonywalnego lub ź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. Podobnie jak w przypadku każdej standardowej notacji, UML może przedstawiać pewne systemy w bardziej wydajny i zwięzły sposób niż inne. W związku z tym programista jest bardziej skłaniany w stronę tych rozwiązań, które są wygodniejsze w tkaniu wszystkich mocnych stron UML, a także innych języków programowania. Ten problem jest bardziej oczywiste, jeśli 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 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. Oprócz możliwe sposoby ograniczenia zakresu UML w jakiejkolwiek konkretnej dziedzinie 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.

UML jest obecnie standardową notacją do wizualnego modelowania systemów oprogramowania, przyjętą przez Object Managing Group (OMG) jesienią 1997 roku i obsługiwaną przez wiele zorientowanych obiektowo produktów CASE.

Standard UML oferuje następujący zestaw diagramów do modelowania:

Diagram przypadków użycia (diagram przypadków użycia) - do modelowania procesów biznesowych organizacji lub przedsiębiorstwa oraz określenia wymagań dla tworzonego systemu informatycznego;

diagram klas (diagram klas) - do modelowania statycznej struktury klas systemowych i relacji między nimi;

diagram zachowania systemu (diagramy zachowania);

diagramy interakcji;

Diagramy sekwencji - do modelowania procesu przesyłania komunikatów między obiektami w ramach jednego przypadku użycia;

diagram współpracy (diagram współpracy) - do modelowania procesu komunikacji między obiektami w ramach tego samego przypadku użycia;

diagram statechart - do modelowania zachowania obiektów systemu podczas przejścia z jednego stanu do drugiego;

diagram aktywności (diagram aktywności) - do modelowania zachowania systemu w obrębie różne opcje wykorzystanie lub modelowanie działań;

schemat wdrożeniowy (schematy wdrożeniowe):

Diagramy składowe (diagramy składowe) - do modelowania hierarchii składowych (podsystemów) systemu informacyjnego;

diagram wdrożeniowy (diagram wdrożeniowy) – służy do modelowania architektury fizycznej projektowanego systemu informatycznego.

Na ryc. 1.1 przedstawia zintegrowany model systemu informacyjnego, w tym główne schematy, które zostaną opracowane w tym projekcie kursu.

Ryż. 1. Zintegrowany model systemu informatycznego w notacji języka UML

4.2. Diagram przypadków użycia

Przypadek użycia to sekwencja działań wykonywanych przez system w odpowiedzi na zdarzenie wywołane przez jakiś zewnętrzny obiekt (aktor). Przypadek użycia opisuje typową interakcję między użytkownikiem a systemem. W najprostszym przypadku przypadek użycia jest ustalany w procesie omawiania z użytkownikiem funkcji, które chciałby zaimplementować w tym systemie informatycznym. W UML przypadek użycia jest przedstawiony w następujący sposób:

Rys.2. Przypadek użycia

Aktor to rola, jaką użytkownik pełni w stosunku do systemu. Aktorzy reprezentują role, a nie specyficzni ludzie lub tytuły zawodowe. Chociaż są one przedstawiane jako stylizowane postacie ludzkie na diagramach przypadków użycia, aktor może być również zewnętrzny. System informacyjny, który potrzebuje informacji z danego systemu. Powinieneś pokazywać aktorów na diagramie tylko wtedy, gdy naprawdę potrzebują niektórych przypadków użycia. W UML aktorzy są reprezentowani jako kształty:

Rys.3. Postać (aktor)

Aktorzy dzielą się na trzy główne typy:

Użytkownicy

systemy;

Inne systemy współpracujące z tym;

Czas staje się aktorem, jeśli od tego zależy wyzwolenie jakichkolwiek zdarzeń w systemie.

4.2.1. Relacje między przypadkami użycia a aktorami

W UML diagramy przypadków użycia obsługują kilka typów relacji między elementami diagramu:

Komunikacja (komunikacja),

Włączenie (m.in.),

rozszerzenie (rozszerzenie),

uogólnienie.

komunikacja komunikacja jest relacją między przypadkiem użycia a aktorem. W UML łącza komunikacyjne są pokazywane przy użyciu jednokierunkowej asocjacji (linia ciągła).

Rys.4. Przykład łącza komunikacyjnego

Połączenie włączenia używane w sytuacjach, w których pewne zachowanie systemu powtarza się w więcej niż jednym przypadku użycia. Za pomocą takich linków zwykle modelowana jest funkcja wielokrotnego użytku.

Połączenie przedłużające używany do opisywania zmian w normalnym zachowaniu systemu. Pozwala to jednemu przypadkowi użycia na wykorzystanie funkcjonalności innego przypadku użycia w razie potrzeby.

Rys.5. Przykład relacji włączenia i rozszerzenia

Uogólnienie komunikacji wskazuje, że kilka aktorów lub klas ma wspólne właściwości.

Rys.6. Przykład relacji uogólniającej

4.3.

Diagramy interakcji opisać zachowanie oddziałujących na siebie grup obiektów. Zazwyczaj diagram interakcji obejmuje zachowanie obiektów tylko w ramach jednego przypadku użycia. Taki diagram wyświetla szereg obiektów i wiadomości, którymi się ze sobą wymieniają.

wiadomość to sposób, w jaki obiekt nadawcy żąda od obiektu odbiorcy wykonania jednej ze swoich operacji.

Komunikat informacyjny (informacyjny) to komunikat, który dostarcza obiektowi odbierającemu pewne informacje umożliwiające aktualizację jego stanu.

Prośba o wiadomość (pytanie) jest komunikatem żądającym wyprowadzenia pewnych informacji o obiekcie odbiorcy.

Komunikat imperatywny to wiadomość, która prosi odbiorcę o wykonanie jakiejś akcji.

Istnieją dwa rodzaje diagramów interakcji: diagramy sekwencji i diagramy współpracy.

4.3.1. Diagramy sekwencji

diagram sekwencyjny odzwierciedla przepływ zdarzeń zachodzących w ramach pojedynczego przypadku użycia.

Wszyscy aktorzy (aktorzy, klasy lub obiekty) zaangażowani w dany scenariusz (przypadek użycia) są pokazani na górze diagramu. Strzałki odpowiadają wiadomościom przekazywanym między aktorem a obiektem lub między obiektami w celu wykonania wymaganych funkcji.

Na diagramie sekwencji obiekt jest przedstawiony jako prostokąt, z którego narysowana jest przerywana pionowa linia w dół. Ta linia nazywa się koło ratunkowe obiektu . Jest to fragment cyklu życia obiektu w procesie interakcji.

Każda wiadomość jest reprezentowana jako strzałka między liniami życia dwóch obiektów. Wiadomości pojawiają się w kolejności, w jakiej pojawiają się na stronie od góry do dołu. Każda wiadomość jest oznaczona przynajmniej nazwą wiadomości. Opcjonalnie możesz również dodać argumenty i niektóre informacje kontrolne. Możesz pokazać samodelegowanie, wiadomość, którą obiekt wysyła do siebie, ze strzałką wiadomości wskazującą tę samą linię życia.

Ryż. 7. Przykład diagramu sekwencji

4.3.2. Schemat współpracy

Schematy współpracy wyświetlić przepływ zdarzeń w ramach określonego scenariusza (przypadek użycia). Komunikaty są uporządkowane według czasu, chociaż diagramy współpracy skupiają się bardziej na relacjach między obiektami. Diagram współpracy pokazuje wszystkie informacje, które posiada diagram sekwencji, ale diagram współpracy opisuje przepływ zdarzeń w inny sposób. Dzięki temu łatwiej jest zrozumieć połączenia, które istnieją między obiektami.

Na diagramie współpracy, podobnie jak na diagramie sekwencji, strzałki reprezentują komunikaty wymieniane w ramach struktury. ta opcja posługiwać się. Ich kolejność czasową wskazuje numeracja komunikatów.

Ryż. 8. Przykładowy schemat współpracy

4.4. diagram klas

4.4.1. Informacje ogólne

diagram klas definiuje typy klas systemowych i różne rodzaje połączeń statycznych, które istnieją między nimi. Diagramy klas pokazują również atrybuty klas, operacje klas i ograniczenia, które są nakładane na relacje między klasami.

Diagram klas w UML to graf, którego węzły są elementami struktury statycznej projektu (klasy, interfejsy), a łuki są relacjami między węzłami (asocjacje, dziedziczenie, zależności).

Diagram klas przedstawia następujące elementy:

· Pakiet (pakiet) - zestaw elementów modelu, logicznie ze sobą powiązanych;

· Klasa (klasa) - opis wspólnych właściwości grupy podobnych obiektów;

· Interfejs (interfejs) - klasa abstrakcyjna określająca zestaw operacji, które obiekt dowolnej klasy skojarzonej z danym interfejsem wykonuje innym obiektom.

4.4.2. Klasa

Klasa to grupa bytów (obiektów), które mają podobne właściwości, a mianowicie dane i zachowanie. Pojedynczy członek klasy nazywany jest obiektem klasy lub po prostu obiektem.

Zachowanie obiektu w UML odnosi się do wszelkich reguł interakcji obiektu ze światem zewnętrznym i danymi samego obiektu.

Na diagramach klasa jest przedstawiona jako prostokąt z ciągłą ramką, podzielony poziomymi liniami na 3 sekcje:

Górna sekcja (sekcja nazwy) zawiera nazwę klasy i inne ogólne właściwości (w szczególności stereotyp).

Środkowa sekcja zawiera listę atrybutów

Na dole znajduje się lista operacji klasy, które odzwierciedlają jej zachowanie (akcje wykonywane przez klasę).

Żadna z sekcji atrybutów i operacji może nie być pokazana (lub obie). W przypadku brakującej sekcji nie trzeba rysować linii podziału i w jakiś sposób wskazywać na obecność lub brak w niej elementów.

Dodatkowe sekcje, takie jak Wyjątki, mogą zostać wprowadzone według uznania określonej implementacji.

Ryż. 9. Przykład diagramu klas

4.4.2.1.Stereotypy klasowe

Stereotypy klas to mechanizm klasyfikacji klas na kategorie.

UML definiuje trzy główne stereotypy klasowe:

Granica (granica);

Podmiot (podmiot);

Kontrola (zarządzanie).

4.4.2.2.Klasy graniczne

Klasy graniczne to te klasy, które znajdują się na granicy systemu i całego środowiska. Są to wyświetlacze, raporty, interfejsy ze sprzętem (takim jak drukarki lub skanery) oraz interfejsy z innymi systemami.

Aby znaleźć klasy graniczne, musisz zbadać diagramy przypadków użycia. Każda interakcja między aktorem a przypadkiem użycia musi mieć co najmniej jedną klasę graniczną. To właśnie ta klasa pozwala aktorowi na interakcję z systemem.

4.4.2.3.Klasy jednostek

Klasy jednostek zawierają przechowywane informacje. Mają one największe znaczenie dla użytkownika, dlatego w ich nazwach często używane są terminy z obszaru tematycznego. Zwykle dla każdej klasy encji w bazie danych tworzona jest tabela.

4.4.2.4.Klasy kontrolne

Klasy sterujące są odpowiedzialne za koordynację działań innych klas. Zazwyczaj każdy przypadek użycia ma jedną klasę kontrolną, która kontroluje sekwencję zdarzeń dla tego przypadku użycia. Klasa kontrolna odpowiada za koordynację, ale sama w sobie nie posiada żadnej funkcjonalności, ponieważ inne klasy jej nie wysyłają duża liczba wiadomości. Zamiast tego sam wysyła wiele wiadomości. Klasa menedżera po prostu deleguje odpowiedzialność na inne klasy, dlatego często nazywa się ją klasą menedżera.

W systemie mogą istnieć inne klasy kontroli, które są wspólne dla kilku przypadków użycia. Na przykład może istnieć klasa SecurityManager odpowiedzialna za monitorowanie zdarzeń związanych z bezpieczeństwem. Klasa TransactionManager obsługuje koordynację komunikatów związanych z transakcjami w bazie danych. Mogą być inni menedżerowie zajmujący się innymi elementami działania systemu, takimi jak współdzielenie zasobów, rozproszone przetwarzanie danych czy obsługa błędów.

Oprócz wspomnianych wyżej stereotypów możesz tworzyć własne.

4.4.2.5.Atrybuty

Atrybut to informacja powiązana z klasą. Atrybuty przechowują enkapsulowane dane klas.

Ponieważ atrybuty są zawarte w klasie, są ukryte przed innymi klasami. Z tego powodu może być konieczne określenie, które klasy mają prawo do odczytywania i modyfikowania atrybutów. Ta właściwość jest nazywana widocznością atrybutu.

Atrybut może mieć cztery możliwe wartości tego parametru:

Publiczne (ogólne, otwarte). Ta wartość widoczności zakłada, że ​​atrybut będzie widoczny dla wszystkich innych klas. Każda klasa może wyświetlać lub zmieniać wartość atrybutu. Zgodnie z notacją UML wspólny atrybut jest poprzedzony znakiem „+”.

Prywatne (zamknięte, tajne). Odpowiedni atrybut nie jest widoczny dla żadnej innej klasy. Atrybut prywatny jest oznaczony znakiem „-” zgodnie z notacją UML.

Chroniony (chroniony). Taki atrybut jest dostępny tylko dla samej klasy i jej potomków. Notacja UML dla chronionego atrybutu to znak „#”.

Pakiet lub wdrożenie (partia). Załóżmy, że dany atrybut jest współdzielony, ale tylko w swoim pakiecie. Ten rodzaj widoczności nie jest oznaczony żadną specjalną ikoną.

Za pomocą zamknięcia lub bezpieczeństwa można uniknąć sytuacji, w której wartość atrybutu zostanie zmieniona przez wszystkie klasy systemu. Zamiast tego logika modyfikacji atrybutu zostanie opakowana w tę samą klasę, co sam atrybut. Ustawione opcje widoczności będą miały wpływ na wygenerowany kod.

4.4.2.6.Operacje

Operacje implementują zachowanie związane z klasami. Operacja składa się z trzech części - nazwy, parametrów i typu zwracanego.

Parametry to argumenty, które operacja otrzymuje jako dane wejściowe. Typ zwracany odnosi się do wyniku akcji operacji.

Diagram klas może pokazywać zarówno nazwy operacji, jak i nazwy operacji wraz z ich parametrami i typem zwracanym. Aby zmniejszyć obciążenie diagramu, warto pokazywać tylko nazwy operacji na niektórych z nich, a ich pełny podpis na innych.

W UML operacje mają następującą notację:

Nazwa operacji (argument: typ danych argumentu, argument2: typ danych argumentu2,...): typ zwracany

Należy wziąć pod uwagę cztery różne typy operacji:

Operacje wdrożeniowe;

Operacje zarządzania;

Operacje dostępu;

Operacje pomocnicze.

Operacje wdrożeniowe

Operacje implementacyjne implementują niektóre funkcje biznesowe. Takie operacje można znaleźć badając diagramy interakcji. Diagramy tego typu skupiają się na funkcjach biznesowych, a każdy komunikat na diagramie najprawdopodobniej może być powiązany z operacją implementacji.

Każda operacja implementacji musi być łatwo identyfikowalna z odpowiednim wymaganiem. Osiąga się to na różnych etapach symulacji. Operacja wywodzi się z wiadomości na diagramie interakcji, wiadomości pochodzą z szczegółowy opis przepływ zdarzeń tworzony na podstawie przypadku użycia, a drugi na podstawie wymagań. Możliwość śledzenia całego łańcucha pomaga zapewnić, że każde wymaganie jest zaimplementowane w kodzie, a każdy fragment kodu implementuje pewne wymaganie.

Operacje zarządcze

Operacje menedżerskie zarządzają tworzeniem i niszczeniem obiektów. Konstruktory i destruktory klas należą do tej kategorii.

Operacje dostępu

Atrybuty są zwykle prywatne lub chronione. Jednak inne klasy czasami muszą przejrzeć lub zmienić swoje wartości. Są do tego operacje dostępu. Takie podejście umożliwia bezpieczne enkapsulowanie atrybutów w klasie, chroniąc je przed innymi klasami, ale nadal umożliwiając kontrolowany dostęp do nich. Tworzenie operacji Get i Set (pobieranie i zmiana wartości) dla każdego atrybutu klasy jest standardem.

Operacje pomocnicze

Pomocnicze (operacje pomocnicze) to te operacje klasy, które są niezbędne do wypełnienia swoich obowiązków, ale o których inne klasy nie powinny nic wiedzieć. Są to operacje klasy prywatnej i chronionej.

Aby zidentyfikować transakcje, wykonaj następujące czynności:

1. Przestudiuj diagramy sekwencji i diagramy kooperacyjne. Większość komunikatów na tych diagramach to operacje implementacyjne. Komunikaty refleksyjne będą operacjami pomocniczymi.

2. Rozważ operacje kontrolne. Może być konieczne dodanie konstruktorów i destruktorów.

3. Rozważ operacje dostępu. Dla każdego atrybutu klasy, z którym inne klasy będą musiały pracować, musisz utworzyć operacje Get i Set.

4.4.2.7.Znajomości

Relacja to związek semantyczny między klasami. Daje klasie możliwość poznania atrybutów, operacji i relacji innej klasy. Innymi słowy, aby jedna klasa przesłała wiadomość do drugiej w sekwencji lub diagramie kooperacyjnym, musi istnieć między nimi połączenie.

Istnieją cztery typy relacji, które można ustanowić między klasami: asocjacje, zależności, agregacje i uogólnienia.

Stowarzyszenie komunikacyjne

Asocjacja to związek semantyczny między klasami. Są one rysowane na diagramie klas jako zwykła linia.

Ryż. 10. Stowarzyszenie komunikacyjne

Asocjacje mogą być dwukierunkowe, jak w przykładzie, lub jednokierunkowe. W UML skojarzenia dwukierunkowe są rysowane jako prosta linia bez strzałek lub ze strzałkami po obu stronach linii. Asocjacja jednokierunkowa ma tylko jedną strzałkę wskazującą jej kierunek.

Kierunek asocjacji można określić, badając diagramy sekwencji i diagramy kooperacyjne. Jeśli wszystkie wiadomości na nich są wysyłane tylko przez jedną klasę i odbierane tylko przez inną klasę, ale nie odwrotnie, istnieje jednokierunkowa komunikacja między tymi klasami. Jeśli co najmniej jedna wiadomość została wysłana do Odwrotna strona, powiązanie musi być dwukierunkowe.

Skojarzenia mogą być odruchowe. Asocjacja zwrotna oznacza, że ​​jedna instancja klasy wchodzi w interakcję z innymi instancjami tej samej klasy.

Uzależnienie od komunikacji

Relacje zależności również odzwierciedlają relacje między klasami, ale zawsze są one jednokierunkowe i pokazują, że jedna klasa zależy od definicji dokonanych w innej. Na przykład klasa A wykorzystuje metody klasy B. Następnie, gdy zmienia się klasa B, konieczne jest dokonanie odpowiednich zmian w klasie A.

Zależność jest reprezentowana przez linię przerywaną narysowaną między dwoma elementami diagramu, a element zakotwiczony na końcu strzałki jest zależny od elementu zakotwiczonego na początku tej strzałki.

Ryż. 11. Uzależnienie od komunikacji

Podczas generowania kodu dla tych klas nie zostaną do nich dodane żadne nowe atrybuty. Zostaną jednak utworzone operatory specyficzne dla języka potrzebne do obsługi komunikacji.

Agregacja komunikacji

Agregacje są ściślejszą formą asocjacji. Agregacja to połączenie całości z jej częścią. Na przykład możesz mieć klasę samochodu, a także klasy silnika, opon i klasy dla innych części samochodowych. W efekcie obiekt klasy Samochód będzie składał się z obiektu klasy Silnik, czterech obiektów Opony itp. Agregacje są wizualizowane jako linia z rombem dla klasy będącej liczbą całkowitą:

Ryż. 11. Agregacja komunikacji

Oprócz prostej agregacji UML wprowadza silniejszą formę agregacji zwaną kompozycją. Zgodnie z kompozycją przedmiot-część może należeć tylko do jednej całości, a ponadto z reguły cykl życia części pokrywa się z cyklem całości: wraz z nią żyją i umierają. Ewentualne usunięcie całości rozciąga się na jej części.

To kaskadowe usuwanie jest często uważane za część definicji agregacji, ale zawsze jest implikowane, gdy krotność ról wynosi 1…1; na przykład, jeśli Klient musi zostać usunięty, to usunięcie musi zostać rozpowszechnione w Zamówieniach (i, z kolei, Wierszach Zamówienia).

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ą stosować UML według własnego uznania, 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łasnego zapisu graficznego. Jednocześnie każda z tych metod miała swoje własne silne strony, ale nie pozwolił 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 reguł łą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 odpowiada określonej semantyce, 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 za pomocą dobrego narzędzia do modelowania wizualnego obsługującego UML, poprzez budując model otrzymamy również blankiet kod programu odpowiadające 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 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 rodzaj podmiotu ma swój własny reprezentacja graficzna. 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 powiązanie między klasami „Zamówienie” i „Produkt” może być użyte do znalezienia wszystkich produktów określonych w konkretnym zamówieniu – z jednej strony, lub wszystkich zamówień, które zawierają 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 między podmiotem definiującym specyfikację zachowania (interfejs) a podmiotem definiującym implementację tego zachowania (klasa, komponent). Ta zależność jest powszechnie stosowana w modelowaniu 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 zorganizowanie 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;
• ekstrakcja i budowa klas danych model koncepcyjny dane 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ędzia modelowanie wizualne. 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 .