wejścieOgólna charakterystyka języka UML. Podstawy ujednoliconego języka modelowania Diagram struktury wewnętrznej Uml
Diagram UML to specjalistyczny język opisu graficznego przeznaczony do modelowania obiektowego w rozwoju różnych oprogramowanie... Ten język ma szeroki profil i jest otwartym standardem, który wykorzystuje różne symbole graficzne stworzyć abstrakcyjny model systemu. UML został stworzony w celu zapewnienia definicji, wizualizacji, dokumentacji i projektowania 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 to potrzebne?
UML nie kończy się na modelowaniu wszelkiego rodzaju oprogramowania. Ponadto język ten jest dziś aktywnie wykorzystywany do modelowania różnych procesów biznesowych, prowadzenia inżynierii systemów, a także wyświetlania struktur organizacyjnych.
Korzystając z UML, twórcy oprogramowania mogą wymusić pełną konwencję w notacjach graficznych używanych do reprezentowania ogólnych pojęć, takich jak komponent, uogólnienie, klasa, zachowanie i agregacja. Pozwala to osiągnąć większy stopień koncentracji na architekturze i projektowaniu.
Warto również zauważyć, że istnieje kilka rodzajów takich diagramów.
Diagram klas
Diagram klas UML to statyczny diagram struktury zaprojektowany w celu opisania struktury systemu, a także pokazania atrybutów, metod i zależności między kilkoma różnymi klasami.
Warto zwrócić uwagę na fakt, że istnieje kilka punktów widzenia na budowę takich schematów, w zależności od tego, w jaki sposób zostaną wykorzystane:
- Konceptualistyczny. W tym przypadku diagram klas UML opisuje model konkretnej domeny, a udostępniane są w nim tylko klasy zastosowanych obiektów.
- Konkretny. Schemat wykorzystywany jest w procesie projektowania różnych systemów informatycznych.
- Realizacja. Diagram klas zawiera wszystkie rodzaje klas, które są bezpośrednio używane w kodzie programu.
Schemat komponentów
Diagram komponentów UML to w pełni statyczny diagram strukturalny. Ma na celu zademonstrować podział określonego systemu oprogramowania na różne elementy konstrukcyjne, a także powiązania między nimi. Diagram komponentów UML jako taki może wykorzystywać wszelkiego rodzaju modele, biblioteki, pliki, pakiety, pliki wykonywalne i wiele innych elementów.
Schemat struktury kompozytowej / kompozytowej
Diagram struktury złożonej / złożonej UML jest również diagramem struktury statycznej, ale służy do pokazania wewnętrznej struktury klas. Jeśli to możliwe, diagram ten może również zademonstrować interakcję elementów znajdujących się w wewnętrznej strukturze klasy.
Ich podtypem jest diagram współpracy UML, który służy do wykazania ról, a także interakcji różnych klas w granicach współpracy. Są bardzo przydatne, gdy trzeba modelować wzorce projektowe.
Warto zauważyć, że typy diagramów klas UML i typy struktur złożonych mogą być używane jednocześnie.
Schemat wdrożenia
Ten diagram służy do symulacji działających węzłów, a także wszelkiego rodzaju artefaktów, które zostały w nich wdrożone. UML 2 wdraża artefakty w różnych węzłach, podczas gdy pierwsza wersja wdraża wyłącznie komponenty. W związku z tym diagram wdrażania UML jest używany głównie przez drugą wersję.
Między artefaktem a implementowanym przez niego składnikiem powstaje manifestacja zależności.
Schemat obiektu
Ten widok pozwala zobaczyć peł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 powiązania między nimi.
Schemat pakietu
Diagram ten ma charakter strukturalny, a jego główną treścią są wszelkiego rodzaju pakiety, a także relacje między nimi. W tym przypadku nie ma twardy podział między kilkoma schematami strukturalnymi, w wyniku czego ich użycie jest najczęściej spotykane wyłącznie dla wygody i nie ma żadnego znaczenia semantycznego. Warto zauważyć, że różne elementy mogą dostarczać inne diagramy UML (przykłady: pakiety i same diagramy pakietów).
Ich wykorzystanie odbywa się w celu zapewnienia organizacji kilku elementów w grupy według określonego kryterium, w celu uproszczenia struktury, a także uporządkowania pracy z modelem tego systemu.
Diagram aktywności
Diagram aktywności UML przedstawia rozkład określonej aktywności na kilka części skł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, połączonych wątkami pochodzącymi z dane wyjściowe jednego węzła na dane wejściowe innego.
Diagramy aktywności UML są często wykorzystywane do modelowania różnych procesów biznesowych, obliczeń równoległych i sekwencyjnych. Między innymi symulują wszelkiego rodzaju procedury technologiczne.
Schemat automatu
Ten widok jest również nazywany diagramem stanu UML. Ma zaprezentowaną maszynę stanów ze stanami prostymi i złożonymi oraz przejściami.
Maszyna stanów to specyfikacja sekwencji różnych stanów, przez które przechodzi dany obiekt, lub interakcja w odpowiedzi na pewne zdarzenia z jego życia, jak również reakcje obiektu na takie zdarzenia. Automat stanów, który używa schematu stanów UML, jest dołączony do elementu źródłowego i używany do definiowania zachowania jego wystąpień.
Tak zwane smocze schematy mogą być używane jako analogi takich diagramów.
Diagramy przypadków użycia
Diagram przypadków użycia UML przedstawia wszystkie relacje, które powstają między aktorami, a także różne przypadki użycia. Jego głównym zadaniem jest zapewnienie siebie jako pełnoprawnego środka, za pomocą którego klient, użytkownik końcowy lub jakiś programista może wspólnie omówić zachowanie i funkcjonalność konkretnego systemu.
W przypadku wykorzystania diagramu przypadków użycia UML w procesie modelowania systemu, analityk zamierza:
- Wyraźnie oddziel symulowany system od otoczenia.
- Zidentyfikuj aktorów, sposoby ich interakcji z tym systemem, a także jego oczekiwaną funkcjonalność.
- Ustaw w słowniku jako obszar tematyczny różne koncepcje, które odnoszą się do szczegółowego opisu funkcjonalności tego systemu.
Jeżeli diagram użytkowania jest tworzony w UML, procedura rozpoczyna się od opisu tekstowego, który uzyskuje się podczas pracy z klientem. Jednocześnie warto zauważyć, że różne wymagania niefunkcjonalne w procesie tworzenia modelu przypadków użycia są całkowicie pomijane, a dla nich zostanie już utworzony osobny dokument.
Komunikacja
Diagram komunikacyjny, podobnie jak diagram sekwencji UML, jest przechodni, czyli sam w sobie wyraża interakcję, ale jednocześnie ją demonstruje różne sposoby, a jeśli to konieczne, z żądanym stopniem dokładności, możesz konwertować je na inne.
Diagram komunikacyjny przedstawia interakcje zachodzące między różnymi elementami złożonej struktury, a także role we współpracy. Główną różnicą w stosunku do diagramu sekwencji jest to, że wyraźnie wskazuje on związek między kilkoma elementami, a czas nie jest używany jako oddzielny wymiar.
Ten typ wyróżnia się całkowicie swobodnym formatem porządkowania kilku obiektów i linków w taki sam sposób, jak to się robi w diagramie obiektowym. Jeśli istnieje potrzeba zachowania kolejności wiadomości w tym dowolnym formacie, są one ponumerowane chronologicznie. Czytanie tego diagramu rozpoczyna się od oryginalnej wiadomości 1.0, a następnie jest kontynuowane w kierunku, w którym wiadomości są przekazywane z jednego obiektu do drugiego.
Większość z tych diagramów pokazuje dokładnie te same informacje, które dostarcza nam diagram sekwencji, jednak ponieważ wykorzystuje inny sposób przedstawiania informacji, pewne rzeczy na jednym diagramie są znacznie łatwiejsze do zidentyfikowania niż na innym. Warto również zauważyć, że diagram komunikacji wyraźniej pokazuje, z jakimi elementami każdy z nich wchodzi w interakcje. oddzielny element, podczas gdy diagram sekwencji pokazuje wyraźniej, w jakiej kolejności zachodzą interakcje.
Diagram sekwencyjny
Diagram sekwencji UML przedstawia interakcje między wieloma obiektami, które są uporządkowane według czasu ich wystąpienia. Ten diagram przedstawia uporządkowane w czasie interakcje między wieloma obiektami. W szczególności wyświetla wszystkie obiekty biorące udział w interakcji, a także pełną sekwencję wymienianych przez nie wiadomości.
Głównymi elementami w tym przypadku są oznaczenia różnych obiektów, a także pionowe linie ukazujące upływ czasu oraz prostokąty, które świadczą o działaniu danego obiektu lub wykonywaniu przez niego dowolnej funkcji.
Schemat współpracy
Ten rodzaj diagramów pozwala zademonstrować interakcje między kilkoma obiektami, abstrahując od sekwencji rozgłaszanych komunikatów. Ten typ diagramów w kompaktowej formie wyświetla absolutnie wszystkie nadawane i odbierane komunikaty danego obiektu, a także formaty tych komunikatów.
Ze względu na to, że diagramy sekwencji i diagramy komunikacyjne to po prostu różne widoki tych samych procedur, Rational Rose zapewnia możliwość tworzenia diagramu komunikacyjnego z diagramu sekwencji lub odwrotnie, a także wykonuje ich w pełni automatyczną synchronizację.
Wykresy przeglądu interakcji
Są to diagramy UML, które są podzbiorem diagramów aktywności, które zawierają zarówno elementy Sekwencji, jak i konstrukcje przepływu sterowania.
Warto zauważyć, że format ten łączy diagramy Collaboration i Sequence, które z różnych punktów widzenia dają możliwość rozważenia interakcji między kilkoma obiektami w tworzonym systemie.
Schemat synchronizacji
Jest to alternatywny diagram sekwencji, który wyraźnie pokazuje zmianę stanu na linii życia z określoną skalą czasową. Może być bardzo przydatny w różnych aplikacjach czasu rzeczywistego.
Jakie są korzyści?
Warto zwrócić uwagę na kilka zalet, które wyróżniają diagram użycia UML od innych:
- Język jest zorientowany obiektowo, w wyniku czego technologie opisu wyników przeprowadzonych analiz i projektowania są semantycznie zbliżone do metod programowania we wszystkich rodzajach języków obiektowych współczesnego typu.
- Za pomocą tego języka można opisać system z niemal każdego możliwego punktu widzenia iw ten sam sposób opisać różne aspekty jego zachowania.
- Wszystkie diagramy są stosunkowo łatwe do odczytania, nawet po stosunkowo szybkim zapoznaniu się z ich składnią.
- UML pozwala na rozbudowę, a także wprowadzanie własnych stereotypów graficznych i tekstowych, co przyczynia się do jego wykorzystania nie tylko w inżynierii oprogramowania.
- Język stał się dość rozpowszechniony, a także rozwija się dość aktywnie.
niedogodności
Pomimo tego, że budowanie diagramów UML ma wiele zalet, dość często są one krytykowane za następujące niedociągnięcia:
- Nadmierność. W zdecydowanej większości krytycy twierdzą, że UML jest zbyt duży i złożony, co często jest nieuzasadnione. Zawiera wiele zbędnych lub praktycznie bezużytecznych konstrukcji i schematów, a najczęściej taka krytyka trafia do wersji drugiej, a nie pierwszej, bo w nowszych poprawkach jest więcej kompromisów „wypracowanych przez komisję”.
- Różne niedokładności semantyczne. Ponieważ język UML jest definiowany przez kombinację samego siebie, języka angielskiego i języka OCL, brakuje mu sztywności, która jest nieodłączna w językach precyzyjnie określonych techniką opisu formalnego. W pewnych sytuacjach abstrakcyjna składnia języków OCL, UML i angielskiego zaczyna być ze sobą sprzeczna, podczas gdy w innych jest niekompletna. Niedokładny opis samego języka wpływa zarówno na użytkowników, jak i dostawców narzędzi, co ostatecznie prowadzi do niekompatybilności narzędzi ze względu na unikalny sposób interpretacji różnych specyfikacji.
- Problemy w procesie realizacji i badania. Wszystkie powyższe problemy stwarzają pewne trudności w procesie wprowadzania i uczenia się języka UML, a dzieje się tak zwłaszcza wtedy, gdy kierownictwo zmusza inżynierów do użycia go na siłę, podczas gdy nie mają oni wcześniejszych umiejętności.
- Kod odzwierciedla kod. Inna opinia jest taka, że to nie piękne i atrakcyjne modele są ważne, ale same działające systemy, czyli kod jest projektem. Zgodnie z tym poglądem istnieje potrzeba opracowania wydajniejszego sposobu pisania oprogramowania. UML jest ceniony za podejścia, które kompilują modele w celu regeneracji kodu 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 interpretera UML może założyć lub zdefiniować.
- Niezgodność obciążenia. Termin ten pochodzi z teorii analizy systemów w celu określenia niezdolności wejścia jednego systemu do postrzegania wyjścia innego. Jak w każdym systemy standardowe notacji, UML może reprezentować niektóre systemy w bardziej wydajny i zwięzły sposób niż inne. W związku z tym programista jest bardziej skłonny do rozwiązań, które są wygodniejsze w tkaniu wszystkich mocnych stron UML, a także innych języków programowania. Ten problem jest bardziej oczywiste w przypadku, gdy język programowania nie jest zgodny z podstawowymi zasadami ortodoksyjnej doktryny obiektowej, czyli nie stara się działać zgodnie z zasadami OOP.
- Stara się być wszechstronna. UML to język modelowania ogólnego przeznaczenia, który stara się być kompatybilny z dowolnym dostępnym obecnie językiem przetwarzania. W kontekście konkretnego projektu, aby zespół projektowy mógł osiągnąć ostateczny cel, konieczne jest dobranie odpowiednich możliwości tego języka. Ponadto możliwe sposoby ograniczania zakresu UML w określonym obszarze przechodzą przez formalizm, który nie jest w pełni sformułowany, ale sam w sobie jest przedmiotem krytyki.
Dlatego użycie tego języka nie jest właściwe we wszystkich sytuacjach.
UML lub Unified Modeling Language to graficzny język opisu do modelowania obiektów w tworzeniu oprogramowania. Jednak wykorzystanie UML nie ogranicza się do IT, kolejnym dużym obszarem praktycznego zastosowania UML jest modelowanie procesów biznesowych, inżynieria systemów oraz mapowanie struktur organizacyjnych. UML umożliwia twórcom oprogramowania osiągnięcie porozumienia w sprawie zapisu graficznego do reprezentowania Pojęcia ogólne i skoncentruj się na projektowaniu i rozwoju.
Zalety UML
- UML używa symboli graficznych dla elementów modelowanego systemu, a diagramy UML są wystarczająco proste do zrozumienia;
- UML umożliwia opisywanie systemów z niemal każdego możliwego punktu widzenia, z uwzględnieniem różnych aspektów;
- UML jest zorientowany obiektowo: jego metody analizy i konstrukcji są semantycznie zbliżone do metod programowania używanych we współczesnych językach OOP;
- UML to otwarty standard. Norma rozwija się i ewoluuje z wersji na wersję, spełniając najnowocześniejsze wymagania dotyczące opisu systemów;
- zawiera mechanizm rozszerzeń pozwalający na wprowadzenie dodatkowych typów tekstowych i graficznych, co umożliwia wykorzystanie języka UML nie tylko na polu informatycznym.
Rodzaje diagramów UML
W UML istnieje 14 typów diagramów. Można je podzielić na 2 kategorie:
- strukturalny reprezentujący struktura informacji;
- behawioralny reprezentujące zachowanie systemu i różne aspekty interakcji. Rozważany jest odrębny podgatunek diagramów zachowań diagramy interakcji.
hierarchia typów diagramów UML,
reprezentowana przez diagram klas
Schematy strukturalne
- Diagram klas jest kluczowym elementem modelowania obiektowego. Za pomocą tego schematu (w rzeczywistości przez zajęcia, ich atrybuty, metody i zależności między klasami) opisuje model domeny i strukturę modelowanego systemu.
- Schemat komponentów wyświetla podział kodu programu na duże bloki (komponenty strukturalne) i pokazuje zależności między nimi. Komponentami mogą być pakiety, moduły, biblioteki, pliki itp.
- Schemat obiektu pokazuje pełny lub częściowy wycinek modelowanego systemu w danym momencie. Reprezentuje instancje klas (obiekty), ich stan (bieżące wartości atrybutów) oraz relacje między nimi.
- Schemat struktury kompozytowej demonstruje wewnętrzną strukturę klas i, jeśli to możliwe, interakcje między elementami tej struktury.
- Schemat pakietu pokazuje pakiety i relacje między nimi. Ten rodzaj diagramów służy uproszczeniu struktury modelu (i odpowiednio pracy z nim) poprzez łączenie elementów modelu w grupy według określonych kryteriów.
- Schemat wdrożenia symuluje wdrażanie komponentów oprogramowania ( artefakty) o zasobach obliczeniowych / komponentach sprzętowych ( węzły).
- Schemat profilu opisuje mechanizm rozszerzenia, który umożliwia dostosowanie UML do różnych dziedzin i branż.
Przykładowy diagram klas UML
Diagramy zachowań
- Diagram aktywności pokazuje akcje ( działania) z czego pewna działalność ( działalność). Diagramy aktywności służą do modelowania procesów biznesowych, przepływów pracy, obliczeń sekwencyjnych i równoległych.
- Diagram przypadków użycia(lub diagram przypadków użycia) opisuje relacje między aktorami (znakami) oraz przypadki użycia modelowanego systemu (jego możliwości). Głównym celem diagramu jest bycie punktem kompleksowej obsługi dla klientów, programistów i użytkowników końcowych w celu wspólnego omówienia systemu — jego możliwości i zachowania.
- Diagram stanu przedstawia dynamiczne zachowanie podmiotu, pokazując, jak ten podmiot, w zależności od swojego aktualnego stanu, reaguje na różne zdarzenia. Jest to zasadniczo diagram stanu z teorii atomów.
- Schemat komunikacji(we wcześniejszych wersjach schemat współpracy) pokazuje interakcje między częściami struktury złożonej i role we współpracy. Schemat wyraźnie wskazuje relacje między elementami (obiektami).
- Diagram sekwencyjny służy do wizualizacji sekwencji interakcji obiektów. Pokazuje cykl życia danego obiektu i interakcję aktorów (aktorów) w ramach przypadku użycia, sekwencję wymienianych przez nich komunikatów.
- Tabela przeglądu interakcji zawiera część diagramu sekwencji i konstrukcje przepływu sterowania. Pomaga rozważyć interakcję obiektów z różnych punktów widzenia.
- Schemat synchronizacji- osobny podtyp diagramów interakcji, specjalizujący się w taktowaniu. Tego rodzaju diagramy służą do badania zachowania obiektów w określonym czasie.
UML jest obecnie standardową notacją do wizualnego modelowania systemów oprogramowania, przyjętą przez Object Managing Group (OMG) jesienią 1997 roku i jest obsługiwana przez wiele zorientowanych obiektowo produktów CASE.
Standard UML oferuje następujący zestaw diagramów do modelowania:
· 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 systemu i powiązań między nimi;
Diagramy zachowań
· Diagramy interakcji;
· Diagramy sekwencji – symulujące proces wymiany komunikatów między obiektami w ramach jednego przypadku użycia;
· Diagram współpracy - do modelowania procesu komunikacji między obiektami w ramach jednego przypadku użycia;
· Diagram wykresu stanów - do modelowania zachowania obiektów systemowych podczas przejścia z jednego stanu do drugiego;
· Diagram aktywności – do modelowania zachowania systemu w ramach różnych przypadków użycia lub czynności modelowania;
Schematy realizacji:
Diagramy składowe - do modelowania hierarchii składowych (podsystemów) systemu informacyjnego;
· Diagram wdrożeniowy – do modelowania fizycznej architektury projektowanego systemu informatycznego.
Na ryc. 1.1 przedstawia zintegrowany model systemu informatycznego, w tym podstawowe schematy, które należy opracować w ramach tego projektu 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 określamy poprzez omówienie z użytkownikiem funkcji, które chciałby zaimplementować w danym systemie informatycznym. W języku UML przypadek użycia jest przedstawiony w następujący sposób:
Rys. 2. Przypadek użycia
Aktor to rola użytkownika w stosunku do systemu. Aktorzy reprezentują role, a nie konkretne osoby lub stanowiska. Chociaż na diagramach przypadków użycia przedstawiany jest jako stylizowane postacie ludzkie, aktor może być także zewnętrzny. System informacyjny który potrzebuje pewnych informacji z tego systemu. Pokaż aktorów na swoim diagramie tylko wtedy, gdy naprawdę potrzebują niektórych przypadków użycia. W UML aktorzy są reprezentowani jako kształty:
Rys. 3. Aktor (aktor)
Istnieją trzy główne typy aktorów:
· Użytkownicy;
· Systemy;
· Inne systemy współpracujące z tym;
Czas staje się aktorem, jeśli od tego zależy uruchomienie jakichkolwiek wydarzeń 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,
Włączenie (m.in.),
Rozszerzenie (przedłużenie),
Uogólnienie.
Łącze komunikacyjne Czy relacja między przypadkiem użycia a aktorem. W UML łącza komunikacyjne są pokazywane za pomocą jednokierunkowej asocjacji (linia ciągła).
Rys. 4. Przykład łącza komunikacyjnego
Link do włączenia ma zastosowanie w sytuacjach, w których pewne zachowanie systemu powtarza się w więcej niż jednym przypadku użycia. Te linki są zwykle używane do modelowania funkcji wielokrotnego użytku.
Link do rozszerzenia służy do opisywania zmian w normalnym zachowaniu systemu. Pozwala na użycie jednego przypadku użycia funkcjonalność inny przypadek użycia.
Rys. 5. Przykład połączenia włączenia i rozszerzenia
Link do generalizacji wskazuje, że kilka aktorów lub klas ma wspólne właściwości.
Rys. 6. Przykład linku generalizacji
4.3.
Diagramy interakcji opisać zachowanie oddziałujących na siebie grup obiektów. Zazwyczaj diagram interakcji obejmuje zachowanie obiektów tylko w jednym przypadku użycia. Taki diagram wyświetla szereg obiektów i wiadomości, którymi się ze sobą wymieniają.
Wiadomość Jest środkiem, za pomocą którego obiekt nadawcy żąda od obiektu odbiorcy wykonania jednej ze swoich operacji.
Wiadomość informacyjna Jest komunikatem, który dostarcza obiektowi odbiorcy pewnych informacji w celu zaktualizowania jego stanu.
Prośba o wiadomość (pytanie) Jest to wiadomość żądająca wydania pewnych informacji o obiekcie odbiorcy.
Komunikat imperatywny To wiadomość, która prosi odbiorcę o podjęcie działania.
Istnieją dwa rodzaje diagramów interakcji: diagramy sekwencji i diagramy współpracy.
4.3.1. Diagramy sekwencji
Diagram sekwencyjny odzwierciedla przepływ zdarzeń, które występują w ramach pojedynczego przypadku użycia.
Wszyscy aktorzy (aktory, klasy lub obiekty) zaangażowane 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 rysowany jako prostokąt z pionową przerywaną linią skierowaną w dół. Ta linia nazywa się linia życia 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ć samodelegację - 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ć przebieg 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 reprezentuje wszystkie informacje, które zawiera diagram sekwencji, ale diagram współpracy inaczej opisuje przepływ zdarzeń. Ułatwia zrozumienie powiązań istniejących między obiektami.
Na diagramie współpracy, podobnie jak na diagramie sekwencji, strzałki wskazują komunikaty wymieniane w ramach ta opcja posługiwać się. Ich kolejność czasową wskazuje numeracja wiadomości.
Ryż. 8. Przykład schematu współpracy
4.4. Diagram klas
4.4.1. Informacje ogólne
Diagram klas definiuje typy klas systemu i różnego rodzaju połączenia statyczne, jakie istnieją między nimi. Diagramy klas przedstawiają również atrybuty klas, operacje klas i ograniczenia, które mają zastosowanie do relacji między klasami.
Diagram klas 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 - zestaw elementów modelu, które są ze sobą logicznie powiązane;
· Klasa - opis ogólnych właściwości grupy podobnych obiektów;
· Interfejs jest klasą abstrakcyjną, która definiuje zestaw operacji, które obiekt dowolnej klasy skojarzonej z tym interfejsem zapewnia 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. Indywidualny reprezentant klasy nazywany jest obiektem klasy lub po prostu obiektem.
Przez zachowanie obiektu w UML rozumie się wszelkie reguły interakcji obiektu ze światem zewnętrznym oraz z danymi samego obiektu.
Na diagramach klasa jest przedstawiona jako prostokąt z pełną 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 (działania wykonywane przez klasę).
Żadna z sekcji atrybutów i operacji może nie być wyświetlana (jak również obie naraz). 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ładowy diagram klas
4.4.2.1.stereotypy klasowe
Stereotypy klasowe to mechanizm kategoryzacji klas.
Istnieją trzy główne stereotypy klasowe zdefiniowane w UML:
Granica
Podmiot
Kontrola.
4.4.2.2.Klasy graniczne
Klasy brzegowe to 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 przejrzeć diagramy przypadków użycia. Dla każdej interakcji między aktorem a przypadkiem użycia musi istnieć co najmniej jedna klasa graniczna. 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 często w swoich nazwach używają terminów z obszaru tematycznego. Zazwyczaj dla każdej klasy encji w bazie danych tworzona jest tabela.
4.4.2.4.Klasy kontrolne
Klasy sterujące odpowiadają 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 kontrolująca odpowiada za koordynację, ale sama nie posiada żadnej funkcjonalności, ponieważ inne klasy nie wysyłają jej wielu komunikatów. Zamiast tego sam wysyła wiele wiadomości. Klasa menedżera po prostu deleguje odpowiedzialność na inne klasy, dlatego często nazywana jest klasą menedżera.
W systemie mogą istnieć inne klasy kontrolne, które są wspólne dla wielu przypadków użycia. Na przykład może istnieć klasa SecurityManager odpowiedzialna za monitorowanie zdarzeń związanych z bezpieczeństwem. Klasa TransactionManager odpowiada za koordynację komunikatów związanych z transakcjami bazodanowymi. 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ą one ukryte przed innymi klasami. Dlatego może być konieczne określenie, które klasy mogą odczytywać i modyfikować atrybuty. Ta właściwość jest nazywana widocznością atrybutów.
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. W notacji 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 Taki atrybut jest dostępny tylko dla samej klasy i jej potomków. Notacja UML dla chronionego atrybutu to znak „#”.
Pakiet lub wdrożenie Zakłada, że dany atrybut jest powszechny, ale tylko w jego opakowaniu. 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 modyfikowania atrybutu zostanie opakowana w tę samą klasę, co sam atrybut. Ustawione przez Ciebie parametry widoczności będą miały wpływ na wygenerowany kod.
4.4.2.6.Operacje
Operacje implementują zachowanie specyficzne dla klasy. Operacja składa się z trzech części - nazwy, parametrów i typu zwracanego.
Parametry to argumenty otrzymane przez operację „wejście”. Typ zwracany odnosi się do wyniku akcji operacji.
Na diagramie klas można wyświetlić 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 na innych pełny podpis.
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 rodzaje transakcji:
Operacje wdrożeniowe;
Operacje kontrolne;
Operacje dostępu;
Operacje pomocnicze.
Operacje wdrożeniowe
Operacje wdrożeniowe 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żdy etap wdrożenia musi być łatwo powiązany z odpowiednim wymaganiem. Osiąga się to na różnych etapach symulacji. Aktywność wywodzi się z komunikatu na diagramie interakcji, komunikaty wywodzą się z szczegółowy opis przepływ zdarzeń, który jest generowany na podstawie przypadku użycia, a ten ostatni jest generowany na podstawie wymagań. Możliwość śledzenia całego łańcucha gwarantuje, że każde wymaganie jest zaimplementowane w kodzie, a każdy fragment kodu implementuje wymaganie.
Operacje kontrolne
Operacje menedżera kontrolują tworzenie i niszczenie 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żliwia kontrolowany dostęp do nich. Standardową praktyką jest tworzenie operacji Get i Set dla każdego atrybutu klasy.
Operacje pomocnicze
Operacje pomocnicze to te operacje klasy, których potrzebuje, aby wypełnić swoje obowiązki, ale o których inne klasy nie powinny nic wiedzieć. Są to prywatne i chronione operacje klasy.
Aby zidentyfikować transakcje, wykonaj następujące kroki:
1. Poznaj diagramy sekwencji i diagramy kooperacyjne. Większość komunikatów na tych diagramach to działania wdrożeniowe. 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. Umożliwia klasie poznanie atrybutów, operacji i relacji innej klasy. Innymi słowy, aby jedna klasa mogła wysłać wiadomość do drugiej na diagramie sekwencji lub diagramie kooperacyjnym, musi istnieć związek między nimi.
Istnieją cztery typy relacji, które można ustanowić między klasami: asocjacje, zależności, agregacje i uogólnienia.
Stowarzyszenie komunikacyjne
Asocjacja jest semantycznym ogniwem 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. Na asocjacji jednokierunkowej jest pokazana tylko jedna strzałka pokazująca jej kierunek.
Kierunek powiązania można określić, badając diagramy sekwencji i diagramy kooperacyjne. Jeśli wszystkie komunikaty do nich są wysyłane tylko przez jedną klasę i są odbierane tylko przez inną klasę, ale nie odwrotnie, między tymi klasami zachodzi jednokierunkowa relacja. Jeśli co najmniej jedna wiadomość zostanie wysłana do Odwrotna strona, powiązanie musi być dwukierunkowe.
Skojarzenia mogą być refleksyjne. Asocjacja zwrotna zakłada, że jedna instancja klasy współdziała 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 w drugiej. Na przykład klasa A używa metod klasy B. Następnie, gdy zmienia się klasa B, musisz dokonać odpowiednich zmian w klasie A.
Zależność jest przedstawiana jako linia przerywana między dwoma elementami wykresu, a element zakotwiczony na końcu strzałki jest uważany za 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 wygenerowane specyficzne dla języka oświadczenia wymagane do wsparcia komunikacji.
Agregacji łącza
Agregacje są ściślejszą formą asocjacji. Agregacja to połączenie całości z jej częścią. Na przykład możesz mieć klasę dla samochodu, a także klasy dla silnika, opon i klasy dla innych części samochodu. W efekcie obiekt klasy Samochód będzie składał się z obiektu klasy Silnik, czterech obiektów Opony itp. Agregacje wizualizowane są jako linia z rombem dla klasy będącej całością:
Ryż. 11. Agregacja komunikacji
Oprócz prostej agregacji UML wprowadza silniejszą formę agregacji zwaną kompozycją. Zgodnie z kompozycją, przedmiot częściowy 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 postrzegane jako część definicji agregacji, ale zawsze jest sugerowane, gdy wielość ról wynosi 1,1; na przykład, jeśli konieczne jest usunięcie Klienta, to usunięcie to musi dotyczyć Zamówień (i z kolei Wierszy Zamówienia).
UML to skrót od Unified Modeling Language. W rzeczywistości jest to jedna z najpopularniejszych technik modelowania procesów biznesowych i międzynarodowy standard notacji do określania, wizualizacji i dokumentowania rozwoju oprogramowania. Zdefiniowany przez Object Management Group, powstał w wyniku kilku dodatkowych systemów notacji UML i stał się de facto standardem modelowania wizualnego. Podstawowa zasada każdego programowania obiektowego zaczyna się od zbudowania modelu.
UML powstał z chaosu wokół tworzenia oprogramowania i dokumentacji. W latach 90. było ich kilka różne sposoby reprezentacje systemów oprogramowania. Zaistniała potrzeba bardziej zunifikowanego wizualnego sposobu przedstawiania tych systemów w języku UML, w wyniku czego został on opracowany w latach 1994-1996 przez trzech inżynierów oprogramowania pracujących w Rational Software. Został później przyjęty jako standard w 1997 roku i pozostaje taki, z zaledwie kilkoma aktualizacjami.
Zasadniczo UML jest językiem modelowania ogólnego przeznaczenia w dziedzinie tworzenia oprogramowania. Obecnie znajduje to jednak odzwierciedlenie w dokumentacji kilku procesów biznesowych lub przepływów pracy, takich jak diagramy aktywności. Diagramy typu UML mogą być używane jako zamiennik schematów blokowych. Zapewniają zarówno bardziej ustandaryzowany sposób modelowania przepływów pracy, jak i szeroką gamę funkcji poprawiających czytelność i wydajność.
Architektura opiera się na meta-obiekcie, który określa podstawę tworzenia UML. Jest wystarczająco dokładny, aby stworzyć całą aplikację. W pełni wykonywalny UML może być wdrażany na wielu platformach przy użyciu różnych technologii ze wszystkimi procesami w całym cyklu tworzenia oprogramowania.
UML jest przeznaczony do tworzenia przez użytkowników języka modelowania wizualnego. Obsługuje koncepcje projektowe wysokiego poziomu, takie jak struktury, szablony i współpraca. UML to zbiór elementów takich jak:
- Oświadczenia języka programowania.
- Aktorzy - opisz rolę odgrywaną przez użytkownika lub jakikolwiek inny system, który wchodzi w interakcję z obiektem.
- Czynności do wykonania w celu wykonania umowy o dzieło i przedstawione na schematach.
- Proces biznesowy obejmujący zestaw zadań tworzących konkretną usługę dla klientów, zwizualizowanych za pomocą schematu blokowego działań sekwencyjnych.
- Logiczne i wielokrotnego użytku komponenty oprogramowania.
Diagramy UML dzielą się na dwie kategorie. Pierwszy typ obejmuje siedem typów diagramów, które reprezentują informacje strukturalne, drugi obejmuje siedem pozostałych, które reprezentują typowe typy zachowań. Diagramy te służą do dokumentowania architektury systemów i są bezpośrednio zaangażowane w modelowanie systemu UML.
Diagramy UML są prezentowane jako statyczne i dynamiczne widoki modelu systemu. Widok statyczny obejmuje diagramy klas i struktur złożonych, które podkreślają strukturę statyczną. Widok dynamiczny reprezentuje interakcję między obiektami i zmiany wewnętrznych stanów obiektów za pomocą diagramów sekwencji, aktywności i stanu.
Dostępna jest szeroka gama narzędzi do modelowania UML w celu uproszczenia modelowania, w tym IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner i Dia.
UML jest używany na różne sposoby, zarówno w dokumentacji tworzenia oprogramowania, jak i w procesach biznesowych:
- Naszkicować. W tym przypadku diagramy UML służą do przekazywania różnych aspektów i cech systemu. Jest to jednak tylko reprezentacja Najwyższy poziom system i najprawdopodobniej nie będzie zawierał wszystkich szczegółów niezbędnych do realizacji projektu do samego końca.
- Projekt do przodu — projekt szkicu jest wykonywany przed zakodowaniem aplikacji. Ma to na celu zapewnienie lepszego przeglądu systemu lub przepływu pracy, który użytkownik próbuje utworzyć. Można zidentyfikować wiele problemów lub wad projektowych, co poprawi ogólny stan zdrowia i dobre samopoczucie projektu.
- Odwrócona konstrukcja. Po napisaniu kodu diagramy UML pojawiają się jako forma dokumentacji dla różnych działań, ról, uczestników i przepływów pracy.
- Projekt. W tym przypadku schemat pełni rolę kompletnej konstrukcji, która wymaga jedynie faktycznego wdrożenia systemu lub oprogramowania. Często odbywa się to za pomocą narzędzi CASE (Computer Aided Software Engineering Tools). Główną wadą korzystania z narzędzi CASE jest to, że wymagają one pewnego poziomu wiedzy, przeszkolenia użytkowników oraz zarządzania i personelu.
UML nie jest samodzielnym językiem programowania, takim jak Java, C++ lub Python, jednak przy odpowiednich narzędziach może stać się pseudo UML. Aby osiągnąć ten cel, cały system musi być udokumentowany na różnych diagramach, a przy użyciu odpowiedniego oprogramowania diagramy można bezpośrednio przełożyć na kod. Ta technika może być użyteczna tylko wtedy, gdy czas poświęcony na rysowanie wykresów jest mniej czasochłonny niż pisanie samego kodu. Chociaż UML został stworzony do modelowania systemów, znalazł kilka zastosowań w obszarach biznesowych.
Poniżej znajduje się przykładowy diagram UML do modelowania biznesowego.
Jednym z praktycznych rozwiązań byłaby wizualizacja przebiegu procesu telesprzedaży za pomocą diagramu aktywności. Od momentu przyjęcia zlecenia jako wkładu, do momentu, gdy zlecenie jest kompletne i dany wynik jest podany.
Istnieje kilka rodzajów diagramów UML, a każdy z nich wykonuje inne zadanie, niezależnie od tego, czy jest opracowywane przed wdrożeniem, czy po, w ramach dokumentacji. Dwie najszersze kategorie, obejmujące wszystkie inne typy, to diagram zachowań i diagram struktury. Jak sama nazwa wskazuje, niektóre diagramy UML próbują analizować i przedstawiać strukturę systemu lub procesu, podczas gdy inne opisują zachowanie systemu, jego uczestników i komponentów.
Poszczególne typy są podzielone w następujący sposób:
- Nie wszystkie z 14 różnych typów diagramów UML są regularnie używane podczas dokumentowania systemów i architektur.
- Zasada Pareto dotyczy również korzystania z diagramów UML.
- 20% wykresów jest używanych przez programistów 80% czasu.
Najczęściej używane elementy w tworzeniu oprogramowania to:
- schematy użytkowania;
- diagramy klas;
- sekwencja.
Diagramy akcji to najważniejsze diagramy UML do tworzenia modeli procesów biznesowych. W tworzeniu oprogramowania służą do opisu przepływu różnych działań. Mogą być sekwencyjne lub równoległe. Opisują przedmioty używane, konsumowane lub wytwarzane w wyniku czynności oraz relacje między różnymi czynnościami.
Wszystko to jest ważne dla modelowania procesów biznesowych, które prowadzą od jednego do drugiego, ponieważ są one połączone z wyraźnym początkiem i końcem. W środowisku biznesowym nazywa się to również mapowaniem procesów biznesowych. Głównymi aktorami są autor, redaktor i wydawca. Przykłady UML obejmują następujące. Kiedy recenzent przegląda wersję roboczą i decyduje, że należy wprowadzić pewne zmiany. Autor następnie poprawia szkic i zwraca go ponownie w celu przeanalizowania przeglądu.
Schemat użytkowania
Podstawa systemu - służy do analizy wymagań na poziom systemu. Te wymagania są wyrażone w różnych przypadkach użycia. Trzy główne elementy diagramu UML to:
- Funkcjonalne - przedstawiane jako przypadki użycia.
- Czasownik opisujący czynność.
- Aktorzy - do interakcji z systemem. Aktorem mogą być użytkownicy, organizacje lub aplikacja zewnętrzna. Relację między uczestnikami reprezentują proste strzałki.
Na przykład dla wykresu kontroli zapasów. W tym przypadku mamy do czynienia z właścicielem, dostawcą, kierownikiem, specjalistą ds. inwentaryzacji i inspektorem inwentaryzacji. Okrągłe pojemniki reprezentują akcje, które wykonują aktorzy. Możliwe działania: kupowanie i opłacanie zapasów, sprawdzanie jakości zapasów, zwracanie zapasów lub ich dystrybucja.
Ten typ diagramu dobrze nadaje się do wyświetlania dynamicznych zachowań między uczestnikami systemu, upraszczając jego prezentację bez odzwierciedlania szczegółów implementacji.
Tymczasowy
Diagramy czasowe UML są używane do reprezentowania relacji między obiektami, gdy skupienie jest zależne od czasu. Jednocześnie nie jest interesujące, w jaki sposób obiekty oddziałują lub zmieniają się nawzajem, ale użytkownik chce sobie wyobrazić, jak obiekty i podmioty zachowują się wzdłuż liniowej osi czasu.
Każdy indywidualny uczestnik jest reprezentowany przez linię życia, która jest zasadniczo linią, która tworzy etapy, gdy indywidualny uczestnik przechodzi z jednego etapu do następnego. Nacisk kładziony jest na czas trwania wydarzeń i zachodzące w zależności od niego zmiany.
Główne elementy wykresu czasowego to:
- Lifeline jest indywidualnym członkiem.
- Oś czasu stanu — pojedyncza ścieżka życia może przechodzić przez różne stany w ramach procesu.
- Ograniczenie czasu trwania — ograniczenie przedziału czasu, które reprezentuje czas trwania wymagany do spełnienia ograniczenia.
- Limit czasu - limit czasu, w którym uczestnik musi coś zrobić.
- Wygląd zniszczenia — wygląd wiadomości, która niszczy pojedynczego uczestnika i przedstawia koniec cyklu życia tego uczestnika.
Diagramy poziome, zwane również diagramami stanów, służą do opisywania różnych stanów komponentu w systemie. Przyjmuje ostateczny format nazwy, ponieważ diagram jest zasadniczo maszyną, która opisuje wiele stanów obiektu i jego zmiany w zależności od zdarzeń wewnętrznych i zewnętrznych.
Bardzo prosty diagram stanu maszyny byłby w grze w szachy. Typowa gra w szachy składa się z ruchów wykonanych przez białe i ruchów wykonanych przez czarne. Biały ma pierwszy ruch, który inicjuje grę. Koniec gry może nastąpić niezależnie od tego, czy wygra biały, czy czarny. Gra może zakończyć się meczem, rezygnacją lub remisem (inne warunki maszynowe). Wykresy stanów są używane głównie w projektowaniu UML do przodu i do tyłu w różnych systemach.
Kolejny
Ten rodzaj diagramu jest najważniejszym diagramem UML nie tylko w środowisku informatycznym, ale także jako model warstwy projektowej do tworzenia aplikacji biznesowych. Są popularne do opisywania procesów biznesowych ze względu na ich wizualną, oczywistą naturę. Jak sama nazwa wskazuje, diagramy opisują sekwencję komunikatów i interakcji zachodzących między podmiotami i przedmiotami. Aktorzy lub obiekty mogą być aktywne tylko wtedy, gdy są potrzebne lub gdy inny obiekt chce się z nimi komunikować. Wszystkie komunikaty są przedstawione w porządku chronologicznym.
Aby uzyskać więcej informacji, zobacz przykładowy diagram sekwencji UML poniżej.
Jak pokazuje przykład, diagramy struktury służą do pokazania struktury systemu. Mówiąc dokładniej, w tworzeniu oprogramowania używany jest język do reprezentowania architektury systemu i sposobu, w jaki różne komponenty są ze sobą połączone.
Diagram klas UML jest najczęstszym typem diagramu do dokumentacji oprogramowania. Ponieważ większość pisanych obecnie programów nadal opiera się na paradygmacie programowania obiektowego, rozsądnie jest używać diagramów klas do dokumentowania oprogramowania. Dzieje się tak, ponieważ OOP opiera się na klasach UML i relacjach między nimi. W skrócie, wykresy zawierają klasy wraz z ich atrybutami, zwanymi również polami danych, oraz ich zachowaniem, zwanymi funkcjami składowymi.
Dokładniej, każda klasa ma 3 pola: nazwa na górze, atrybuty tuż pod nazwą, operacje/zachowanie na dole. Relacja między różnymi klasami (reprezentowanymi przez linię łączącą) tworzy diagram klas. Powyższy przykład przedstawia podstawowy diagram klas.
Obiekty
Omawiając diagramy strukturalne UML, musisz zagłębić się w koncepcje informatyki. W rozwoju oprogramowania klasy są uważane za abstrakcyjne typy danych, podczas gdy obiekty są instancjami. Na przykład, jeśli istnieje „Samochód”, który jest ogólnym typem abstrakcyjnym, to instancją klasy „Samochód” będzie „Audi”.
Diagramy obiektów UML pomagają twórcom oprogramowania sprawdzić, czy wygenerowana abstrakcyjna struktura jest strukturą realną, gdy zostanie zaimplementowana w praktyce, to znaczy podczas tworzenia obiektów. Niektórzy programiści uważają to za wtórny poziom weryfikacji dokładności. Wyświetla instancje klas. Dokładniej, ogólna klasa „Klient” ma teraz rzeczywistego klienta, na przykład o nazwie „James”. James jest instancją bardziej ogólnej klasy i ma te same atrybuty, jednak z podane wartości... To samo zrobiono z kontem Konta i oszczędności. Obaj są przedmiotami swoich klas.
Rozlokowanie
Diagramy wdrożeniowe służą do wizualizacji relacji między oprogramowaniem a sprzętem. Mówiąc dokładniej, za pomocą diagramów wdrożeniowych można zbudować fizyczny model tego, jak składniki oprogramowania (artefakty) są wdrażane na składnikach sprzętowych znanych jako węzły.
Typowy uproszczony wzorzec wdrażania aplikacji internetowej obejmuje:
- Węzły (serwer aplikacji i serwer bazy danych).
- Artefakty schemat aplikacji klienta i baza danych.
Diagram pakietów jest podobny do makr dla diagramów wdrażania UML, które wyjaśniliśmy powyżej. Różne pakiety zawierają węzły i artefakty. Grupują diagramy i komponenty modelu w grupy, podobnie jak przestrzeń nazw zawiera różne nazwy, które są w pewnym stopniu powiązane. Ostatecznie pakiet może być również utworzony przez kilka innych pakietów, aby reprezentować bardziej złożone systemy i zachowanie.
Głównym celem diagramu pakietów jest pokazanie relacji między różnymi głównymi komponentami, które składają się na złożony system. Programiści znajdują tę abstrakcyjną okazję dobra zaleta do korzystania ze schematów pakietów, zwłaszcza gdy niektóre szczegóły mogą zostać pominięte.
Jak każda inna rzecz w życiu, zrobienie czegoś dobrze wymaga odpowiednich narzędzi. Aby udokumentować oprogramowanie, procesy lub systemy, użyj narzędzi oferujących adnotacje UML i szablony diagramów. Istnieją różne narzędzia dokumentacji oprogramowania, które mogą pomóc w narysowaniu diagramu.
Zwykle dzielą się na następujące główne kategorie:
- Papier i długopis są łatwe. Biorą papier i długopis, otwierają kod składni UML z Internetu i rysują dowolny rodzaj diagramu, który jest potrzebny.
- Narzędzia online — istnieje kilka aplikacji internetowych, których możesz użyć do stworzenia wykresu. Większość z nich oferuje płatna subskrypcja lub ograniczona liczba diagramów na dowolnym poziomie.
- Darmowe narzędzia online są prawie takie same jak płatne. Główna różnica polega na tym, że płatne również oferują samouczki oraz gotowe szablony pod konkretne schematy.
- Aplikacja komputerowa to typowa aplikacja komputerowa używana do tworzenia diagramów, a prawie każdy inny diagram to Microsoft Visio. Oferuje zaawansowane funkcje i funkcjonalność. Jedynym minusem jest to, że trzeba za to zapłacić.
Jest więc jasne, że UML jest ważnym aspektem związanym z rozwojem oprogramowania obiektowego. Wykorzystuje notację graficzną do tworzenia wizualnych modeli programów systemowych.
UML to uniwersalny język modelowania graficznego do określania, wizualizacji, projektowania i dokumentowania wszystkich artefaktów utworzonych podczas opracowywania systemów oprogramowania.
Istnieje wiele dobrych książek, które szczegółowo opisują UML (w niektórych miejscach nawet bardzo szczegółowo), chciałbym zebrać w jednym miejscu podstawowe pojęcia dotyczące diagramów, encji i połączeń między nimi dla szybkiego przypomnienia, coś w rodzaju ściągawki .
W notatce wykorzystano materiały z książek: Iwanow D. Yu., Novikov F. A. Zunifikowany język modelowania UML oraz Leonenkow. Samouczek UML.
Najpierw zdecydujmy się na edytor. Pod Linuksem próbowałem różnych edytorów UML, przede wszystkim podobał mi się UMLet, chociaż jest napisany w Javie, porusza się bardzo szybko i zawiera większość szablonów encji. Jest też ArgoUML, wieloplatformowy edytor UML, również napisany w Javie, bogaty funkcjonalnie, ale bardziej spowalnia.
zdecydowałem się UMLet, ustaw to pod Arch Linux oraz Ubuntu:
# dla Arch Linux yaourt -S umlet # Dla Ubuntu sudo apt-get zainstaluj umlet
W UML wszystkie encje można podzielić na następujące typy:
- strukturalny;
- behawioralne;
- grupowanie;
- adnotacja;
Istnieją cztery główne typy relacji używanych w UML:
Zależność- wskazuje, że zmiana podmiotu niezależnego w jakiś sposób wpływa na podmiot zależny. Graficznie relacja zależności jest przedstawiona jako linia przerywana ze strzałką wskazującą od jednostki zależnej do jednostki niezależnej.
Stowarzyszenie- ma miejsce, gdy jeden podmiot jest bezpośrednio powiązany z drugim (lub z innymi - powiązanie może być nie tylko binarne). Powiązanie jest przedstawione graficznie jako ciągła linia z różnymi dodatkami łączącymi powiązane podmioty.
Uogólnienie jest relacją między dwoma podmiotami, z których jeden jest szczególnym (wyspecjalizowanym) przypadkiem drugiego. Graficznie uogólnienie jest przedstawione jako linia z trójkątną, niecieniowaną strzałką na końcu, skierowaną od konkretnej (podklasy) do ogólnej (nadklasy).
Realizacja- relacja implementacyjna wskazuje, że jeden podmiot jest implementacją innego. Graficznie implementacja jest przedstawiona jako linia przerywana z trójkątną, niecieniowaną strzałką na końcu, skierowaną od jednostki realizującej do jednostki możliwej do zrealizowania.
V UML 2 definiuje 13 rodzaje wykresów. Zgodnie ze standardami, każdy wykres powinien mieć prostokąt z prostokątem (prawy dolny róg ścięty) w lewym górnym rogu, który wskazuje identyfikator wykresu (tag) i tytuł.
Schematy obrazujące strukturę systemu:
- Schemat komponentów (znacznik składnik);
- Diagram wdrożeniowy (tag rozlokowanie);
- Diagram klas (diagram klas, tag klasa);
- Diagram obiektów (znacznik obiekt);
- Schemat struktury wewnętrznej (diagram struktury złożonej, tag klasa);
Diagramy przedstawiające zachowanie systemu:
- Diagram interakcji (tag wyczucie czasu);
- Diagram aktywności (tag działalność);
- Diagram sekwencji (tag sd);
- Schemat komunikacji (tag komunikacja);
- Schemat automatu stanów (tag maszyna stanowa);
- Tag diagramu przeglądu interakcji interakcja);
Schematy wyróżniają się:
- Diagram użycia (diagram przypadków użycia, tag przypadku użycia);
- Schemat pakietu (tag pakiet);
Schemat użytkowania
Schemat użytkowania(diagram przypadków użycia) jest najbardziej ogólną reprezentacją funkcjonalnego celu systemu.
Traktując diagram przypadków użycia jako model systemu, można go powiązać z modelem czarnej skrzynki. Każdy przypadek użycia definiuje sekwencję działań, które musi wykonać zaprojektowany system, gdy wchodzi w interakcję z odpowiednim aktorem.
Diagram użycia wykorzystuje dwa typy podstawowych encji: przypadki użycia i aktorów, między którymi ustanawiane są następujące podstawowe typy relacji.
Relacja asocjacyjna- Ta relacja określa, jaką konkretną rolę odgrywa aktor podczas interakcji z wystąpieniem przypadku użycia. Związek asocjacyjny jest zaznaczony linią ciągłą między aktorem a przypadkiem użycia. Ta linia może mieć dodatkowe legenda, takie jak imię i nazwisko oraz kardynalność.
Współczynnik ekspansji- określa, w jaki sposób instancje konkretnego przypadku użycia odnoszą się do bardziej ogólnego przypadku użycia, którego właściwości są określane na podstawie sposobu, w jaki te instancje są ze sobą połączone. Tak więc, jeśli istnieje relacja rozszerzenia z przypadku użycia A do przypadku użycia B, oznacza to, że właściwości instancji przypadku użycia B mogą zostać rozszerzone ze względu na obecność właściwości w rozszerzonym przypadku użycia A.
Relacja rozszerzenia między przypadkami użycia jest oznaczona linią przerywaną ze strzałką (przypadek relacji zależności) wskazującą od przypadku użycia, który jest rozszerzeniem pierwotnego przypadku użycia.
Relacja generalizacji służy do wskazania, że pewien przypadek użycia A można uogólnić na przypadek użycia B. W tym przypadku opcja A będzie specjalizacją opcji B. W tym przypadku B jest nazywany przodkiem lub rodzicem w stosunku do A, a opcja A jest potomkiem w stosunku do wykorzystania opcji V.
Graficznie związek ten jest oznaczony linią ciągłą z otwartą strzałką trójkątną, która wskazuje nadrzędny przypadek użycia.
Relacja uogólniona między przypadkami użycia jest używana, gdy trzeba zauważyć, że podrzędne przypadki użycia mają wszystkie atrybuty i zachowania nadrzędnych przypadków użycia.
Współczynnik włączenia między dwoma przypadkami użycia wskazuje, że pewne określone zachowanie dla jednego przypadku użycia jest zawarte jako składnik złożony w sekwencji zachowań drugiego przypadku użycia.
Relacja włączenia od przypadku użycia A do przypadku użycia B wskazuje, że każda instancja opcji A zawiera funkcjonalność określoną dla opcji B.
Graficznie ta relacja jest oznaczona linią przerywaną ze strzałką (przypadek relacji zależności) wskazującą od podstawowego przypadku użycia do uwzględnionego przypadku użycia.
Diagram klas
Diagram klas(diagram klas) jest głównym sposobem opisu statycznej struktury systemu.
Na diagramie klas używany jest jeden główny typ encji: klasy (w tym liczne szczególne przypadki klas: interfejsy, typy pierwotne, klasy asocjacyjne itp.), pomiędzy którymi ustanawiane są następujące podstawowe typy relacji: zależności, asocjacje, uogólnienia , wdrożenia.
Związek uzależnienia ogólnie wskazuje pewną relację semantyczną między dwoma elementami modelu lub dwoma zestawami takich elementów, która nie jest powiązaniem, uogólnieniem ani relacją implementacji. Relacja zależności jest używana w sytuacji, gdy jakaś zmiana w jednym elemencie modelu może wymagać zmiany w innym elemencie zależnym w modelu.
Relacja zależności jest przedstawiona graficznie linią przerywaną między odpowiednimi elementami ze strzałką na jednym z jej końców, przy czym strzałka wskazuje od klasy klienta zależności do klasy niezależnej lub źródłowej.
Nad strzałką może być coś wyjątkowego słowa kluczowe(stereotypy):
- „dostęp” - służy do wskazania dostępności publicznych atrybutów i operacji klasy źródłowej dla klas klienckich;
- "bind" - klasa klienta może użyć jakiegoś szablonu do jego późniejszej parametryzacji;
- „derive” – atrybuty klasy klienta można obliczyć z atrybutów klasy źródłowej;
- "import" - publiczne atrybuty i operacje klasy źródłowej stają się częścią klasy klienta, tak jakby były w niej zadeklarowane;
- „udoskonalenie” - wskazuje, że klasa klienta służy jako udoskonalenie klasy źródłowej ze względów historycznych, gdy się pojawi Dodatkowe informacje podczas pracy nad projektem.
Relacja asocjacyjna odpowiada istnieniu pewnej relacji między klasami. Relację tę oznaczono linią ciągłą z dodatkowymi znakami specjalnymi, charakteryzującymi poszczególne właściwości danego skojarzenia. Jako dodatkowe znaki specjalne można użyć nazwy stowarzyszenia, a także nazw i liczebności klas ról stowarzyszenia. Nazwa stowarzyszenia jest opcjonalnym elementem jego oznaczenia.
Współczynnik agregacji ma miejsce między kilkoma klasami w przypadku, gdy jedna z klas jest pewną jednostką, która obejmuje inne jednostki jako części składowe. Służy do reprezentowania relacji części do całości.
Związek kompozycji jest szczególnym przypadkiem relacji agregacji. Relacja ta służy podkreśleniu szczególnej formy relacji „część-całość”, w której części składowe w pewnym sensie znajdują się wewnątrz całości. Specyfika relacji między nimi polega na tym, że części nie mogą działać w oderwaniu od całości, to znaczy przy zniszczeniu całości zniszczeniu ulegają wszystkie jej części składowe.
Relacja generalizacji jest relacją między bardziej ogólnym elementem (rodzicem lub przodkiem) a bardziej prywatnym lub specjalnym elementem (potomkiem lub potomkiem). W przypadku zastosowania do diagramu klas, relacja ta opisuje hierarchiczną strukturę klas oraz dziedziczenie ich właściwości i zachowania. Zakłada się, że klasa potomka ma wszystkie właściwości i zachowanie klasy przodka, a także ma swoje własne właściwości i zachowanie, których klasa przodka nie posiada.
Schemat automatu
Schemat automatu(schemat maszyny stanowej) lub diagram stanu w UML 1 (diagram wykresu stanu) jest jednym ze sposobów szczegółowego opisania zachowania w UML. W istocie diagramy automatów, jak sama nazwa wskazuje, są grafem stanów i przejść automatu skończonego, obciążonego wieloma dodatkowymi szczegółami i szczegółami.
Diagram stanów opisuje proces zmiany stanów tylko jednej klasy, a raczej jednej instancji pewnej klasy, czyli modeluje wszystkie możliwe zmiany stanu konkretnego obiektu. W takim przypadku zmiana stanu obiektu może być spowodowana wpływami zewnętrznymi z innych obiektów lub z zewnątrz. Diagramy stanów służą do opisu reakcji obiektu na takie wpływy zewnętrzne.
Na schemacie automatu używany jest jeden główny typ bytu - stany i jeden typ relacji - przejścia, ale dla obu zdefiniowano wiele odmian, przypadków specjalnych i dodatkowych zapisów. Automat reprezentuje dynamiczne aspekty modelowanego układu w postaci grafu skierowanego, którego wierzchołki odpowiadają stanom, a łuki odpowiadają przejściom.
Stan początkowy jest szczególnym przypadkiem stanu, który nie zawiera żadnych działań wewnętrznych (pseudo stanów). Obiekt domyślny znajduje się w tym stanie w początkowym momencie czasu. Służy do wskazania na diagramie stanów obszaru graficznego, z którego rozpoczyna się proces zmiany stanu.
Finał (ostateczny) stan jest szczególnym przypadkiem stanu, który również nie zawiera żadnych działań wewnętrznych (pseudostanów). Domyślny obiekt będzie w tym stanie po zakończeniu pracy automatu w ostatnim momencie czasu.
Diagram aktywności
Podczas modelowania zachowania projektowanego lub analizowanego systemu konieczne staje się nie tylko przedstawienie procesu zmiany jego stanów, ale także uszczegółowienie cech algorytmicznej i logicznej realizacji operacji wykonywanych przez system.
Diagram aktywności(schemat aktywności) to kolejny sposób opisywania zachowania, który wizualnie przypomina stary dobry schemat blokowy algorytmu. Służy do symulacji procesu wykonywania operacji.
Głównym kierunkiem wykorzystania diagramów aktywności jest wizualizacja specyfiki implementacji operacji na klasach, gdy konieczne jest przedstawienie algorytmów ich wykonania.
W diagramie aktywności stosuje się jeden główny typ bytu - akcja i jeden typ relacji - przejścia (przekazania kontroli). Wykorzystywane są również takie konstrukcje jak widelce, scalenia, łączenia, rozgałęzienia. Polecane jako nazwa prosta czynność użyj czasownika ze słowami objaśniającymi.
Diagram sekwencyjny
Diagram sekwencyjny(diagram sekwencji) to sposób na opisanie zachowania systemu „przykładami”.
W rzeczywistości diagram sekwencji jest zapisem protokołu określonej sesji działania systemu (lub fragmentem takiego protokołu). W programowaniu obiektowym najistotniejszym czasem działania jest przesyłanie komunikatów między komunikującymi się 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 (głównie klas, komponentów i aktorów) oraz jeden typ relacji - łącza, przez które wymieniane są komunikaty.
Możliwe typy wiadomości (zdjęcie z larin.in):
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 między instancjami oddziałujących klasyfikatorów, wyrażony tylko w innych środkach graficznych.
Tak więc w diagramie komunikacyjnym, a także w diagramie sekwencji, używany jest jeden główny typ encji - instancje klasyfikatorów oddziałujących i jeden rodzaj relacji - linki. Jednak nacisk kładziony jest nie na czas, ale na strukturę powiązań między konkretnymi instancjami.
Schemat komponentów
Schemat komponentów(schemat komponentów) - pokazuje relacje pomiędzy modułami (logicznym lub fizycznym), które tworzą symulowany system.
Głównym typem encji na diagramie komponentów są same komponenty, a także interfejsy, przez które wskazywane są relacje między komponentami. Na diagramie składników obowiązują następujące relacje:
- implementacje między komponentami a interfejsami (komponent implementuje interfejs);
- zależności między komponentami a interfejsami (komponent wykorzystuje interfejs);
Schemat rozmieszczenia
Schemat rozmieszczenia(schemat wdrożenia), wraz z wyświetleniem składu i relacji elementów systemu, pokazuje, jak są one fizycznie rozmieszczone na zasobach obliczeniowych w czasie wykonywania.
W diagramie rozmieszczenia, w porównaniu z diagramem komponentów, dodawane są dwa typy encji: artefakt, który jest implementacją komponentu oraz węzeł (może to być albo klasyfikator opisujący typ węzła, albo konkretna instancja ), a także relację asocjacji między węzłami, pokazującą, że węzły są fizycznie połączone w czasie wykonywania.
Schemat obiektu
Schemat obiektu(diagram obiektów) - jest instancją diagramu klas.
Na diagramie obiektowym wykorzystywany jest jeden główny typ encji: obiekty (instancje klas), pomiędzy którymi wskazane są określone relacje (najczęściej instancje asocjacyjne). Diagramy obiektów mają charakter pomocniczy - w rzeczywistości są przykładami (można powiedzieć zrzutami pamięci) pokazującymi, czym są obiekty i jakie są między nimi powiązania w określonym momencie funkcjonowania systemu.
Schemat struktury wewnętrznej(diagram struktury kompozytowej) służy do bardziej szczegółowej prezentacji klasyfikatorów strukturalnych, przede wszystkim klas i komponentów.
Klasyfikator strukturalny jest przedstawiony jako prostokąt, w górnej części którego znajduje się nazwa klasyfikatora. Wewnątrz znajdują się części. Może być kilka części. Części mogą ze sobą współdziałać. Wskazują na to różnego rodzaju złącza. Lokalizacja na zewnętrznej krawędzi części, do której przyłączane jest złącze, nazywana jest portem. Porty znajdują się również na zewnętrznej krawędzi klasyfikatora strukturalnego.
Schemat przeglądu interakcji Diagram przeglądu interakcji to rodzaj diagramu aktywności o rozszerzonej składni: łącza użycia interakcji zdefiniowane przez diagramy sekwencji mogą działać jako elementy diagramu przeglądu interakcji.
Schemat synchronizacji
Schemat synchronizacji(diagram czasowy) to specjalna forma diagramu sekwencji, w której szczególną uwagę zwraca się na zmianę stanów różnych instancji klasyfikatorów i ich taktowania.
Schemat pakietu
Schemat pakietu(diagram pakietu) to jedyne narzędzie, które pozwala zarządzać złożonością samego modelu.
Głównymi elementami notacji są pakiety i zależności o różnych stereotypach.
Model relacji encji (model ER)
Analog diagramy klas(UML) może Model ER, który jest wykorzystywany przy projektowaniu baz danych (model relacyjny).
Model relacji encji (model ER) to model danych, który umożliwia opisywanie schematów pojęciowych domeny. Model ER jest używany w projektach baz danych wysokiego poziomu (koncepcyjnych). Za jego pomocą możliwe jest wyróżnienie kluczowych podmiotów i wyznaczenie powiązań, które można nawiązać między tymi podmiotami. Wikipedia
Dowolny fragment obszaru tematycznego może być reprezentowany jako zbiór encji, pomiędzy którymi istnieje szereg powiązań.
Podstawowe koncepcje:
Esencja(podmiot) to podmiot, który można zidentyfikować w sposób odróżniający go od innych podmiotów, na przykład KLIENT 777... Jednostka jest w rzeczywistości zbiorem atrybutów.
Zestaw jednostek(zestaw encji) - zbiór encji tego samego typu (o tych samych właściwościach).
Połączenie(relacja) to związek ustanowiony między wieloma podmiotami.
Domena(domena) – zbiór wartości (zakres) atrybutu.
Istnieją trzy rodzaje linków binarnych:
- Jeden na jednego- pojedyncza instancja encji jednej klasy jest skojarzona z pojedynczą instancją encji innej klasy, np. HEAD - DEPARTMENT;
- 1 do N lub jeden za dużo- pojedyncza instancja podmiotu jednej klasy jest powiązana z wieloma instancjami podmiotu innej klasy, np. DZIAŁ - PRACOWNIK;
- N do M lub wiele do wielu- wiele instancji encji jednej klasy jest powiązanych z wieloma instancjami encji innej klasy, np. PRACOWNIK - PROJEKT; Słowniczek podstawowych pojęć UML
- Fowlera M. UML. Podstawy, 3. edycja
- Booch G., Rambeau D., Jacobson I. UML. Instrukcja obsługi
Obiekt- byt, który jest unikalny i zawiera stan i zachowanie.
Klasa- opis zestawu obiektów ze wspólnymi atrybutami, które określają stan i operacje, które określają zachowanie.
Berło- nazwany zestaw operacji definiujący zestaw usług, o które może poprosić konsument i które są świadczone przez usługodawcę.
Współpraca- zestaw obiektów, które współdziałają, aby osiągnąć cel.
Aktor- podmiot znajdujący się poza modelowanym systemem i bezpośrednio z nim współdziałający.
Składnik- modułowa część systemu z dobrze zdefiniowanym zestawem wymaganych i dostarczonych interfejsów.
Artefakt- element informacji, który jest wykorzystywany lub generowany w procesie tworzenia oprogramowania. Innymi słowy, artefakt to fizyczna jednostka implementacji wywodząca się z elementu modelu (takiego jak klasa lub komponent).
Węzeł- zasób obliczeniowy, na którym znajdują się artefakty i, jeśli to konieczne, są wykonywane.
Jednostki behawioralne mają opisywać zachowanie. Istnieją tylko dwa podstawowe byty behawioralne: stan i działanie.
Stan- okres w cyklu życia przedmiotu, w którym przedmiot spełnia określony warunek i prowadzi własną działalność lub oczekuje na zajście jakiegoś zdarzenia.
Akcja- prymitywne obliczenia atomowe.
Maszyna to pakiet, który definiuje zestaw pojęć niezbędnych do reprezentowania zachowania modelowanego bytu w postaci dyskretnej przestrzeni o skończonej liczbie stanów i przejść.
Klasyfikator jest deskryptorem zbioru obiektów tego samego typu.
Dodatkowe czytanie