Rodzaje diagramów UML. Narzędzia programowe obsługujące język UML

UML służy do modelowania. Sami autorzy UML-a definiują swój pomysł w następujący sposób.

Język UML-owy to graficzny język modelowania ogólnego przeznaczenia, przeznaczony do specyfikacji, wizualizacji, projektowania i dokumentowania wszystkich artefaktów powstałych podczas opracowywania systemów oprogramowania.

W pełni zgadzamy się z tą definicją, a nie tylko aprobujemy wybór słowa kluczowe, ale przywiązujemy dużą wagę do kolejności ich wymieniania.

1.2.1. Specyfikacja

W typowych przypadkach w procesie tworzenia aplikacji biorą udział co najmniej dwa podmioty: klient(konkretna osoba, grupa osób lub organizacja) oraz deweloper(może to być pojedynczy programista, tymczasowy zespół projektowy lub cała organizacja specjalizująca się w rozwoju oprogramowanie). W związku z tym, że bohaterów jest dwóch, wiele zależy od stopnia ich wzajemnego zrozumienia.

Jednym z kluczowych etapów tworzenia aplikacji jest określenie, jakie wymagania musi spełniać tworzona aplikacja. W wyniku tego etapu powstaje formalny lub nieformalny dokument (artefakt), który nazywany jest różnie i oznacza w przybliżeniu to samo: określenie problemu, wymagań, zadanie techniczne, specyfikacje zewnętrzne itp.

Artefakty o podobnym przeznaczeniu, ale być może różniące się formą i treścią, pojawiają się na innych etapach rozwoju, zwłaszcza jeśli w rozwój zaangażowanych jest wielu aktorów. Używa się dla nich także różnych nazw: specyfikacje funkcjonalne, architektura aplikacji itp. Wszystkie takie artefakty będziemy nazywać specyfikacjami.

Specyfikacja jest deklaratywnym opisem struktury lub działania czegoś.

Należy wziąć pod uwagę trzy interpretacje specyfikacji.

• To, co ma na myśli aktor będący źródłem specyfikacji (na przykład klient).
• To, co ma na myśli aktor będący konsumentem specyfikacji (na przykład deweloper).
• To, co obiektywnie zdeterminowane jest naturą określonego przedmiotu.

Te trzy interpretacje specyfikacji mogą się nie pokrywać i niestety, jak pokazuje praktyka, często się nie pokrywają i to znacząco. Klient może nie być świadomy swoich obiektywnych potrzeb, błędnie je zinterpretować lub mylić się co do natury swoich trudności, próbując wykorzystać niestandardową aplikację biurową do leczenia objawów, a nie przyczyny choroby swojej firmy. Deweloper może nie zrozumieć domeny klienta i zupełnie błędnie zinterpretować treść specyfikacji. Jeśli programista jest zaangażowany w formułowanie specyfikacji, nadużywanie terminologii technicznej może całkowicie zdezorientować klienta.

Główny cel UML-a– z jednej strony zapewnić dość formalny, z drugiej strony, całkiem wygodne, a z trzeciej strony dość uniwersalny środek, co pozwala w pewnym stopniu ograniczyć ryzyko rozbieżności w interpretacji specyfikacji.

1.2.2. Wyobrażanie sobie

Znane powiedzenie mówi, że lepiej raz zobaczyć, niż usłyszeć sto razy. Dodamy: szczególnie przeczytaj opowieść tysiąc razy. Specyfika ludzkiej percepcji polega na tym, że tekst z obrazami jest łatwiejszy do zauważenia niż nagi tekst. A zdjęcia z tekstem (to się nazywa „komiks”) są jeszcze łatwiejsze. Modele UML można przedstawić w formie obrazów, a obrazy te są wizualne, intuicyjne, niemal jednoznaczne w interpretacji i łatwe w komponowaniu. W rzeczywistości rozwinięcie i uszczegółowienie tej tezy stanowi znaczną część treści pozostałej części książki. Nie będziemy się wyprzedzać i po prostu podamy przykład bez żadnych wyjaśnień.

Czy coś jest niejasne?

Zatem drugim najważniejszym celem UML-a jest służenie jako odpowiedni środek komunikacji między ludźmi. Oczywiście wizualizacja modeli UML ma znaczenie tylko wtedy, gdy mają one zostać utworzone lub zrozumiane przez ludzi – jest to cel UML-a, który nie ma znaczenia w przypadku komputerów.

Graficzna reprezentacja modelu UML nie jest identyczna z samym modelem. Ten ważny punkt jest często pomijany przy pierwszym zapoznawaniu się z językiem UML.

1.2.3. Projekt

W oryginale ten cel UML-a jest zdefiniowany za pomocą słowa konstrukt, które określamy ostrożnym terminem „projekt”. Chodzi o to, że UML ma za zadanie nie tylko opisywać abstrakcyjne modele aplikacji, ale także bezpośrednio manipulować artefaktami tworzącymi te aplikacje, m.in. np. kodem programu. Inaczej mówiąc, jednym z celów UML-a jest np. tworzenie modeli, dla których jest to możliwe automatyczne generowanie kodu programu(lub fragmenty kodu) odpowiednich aplikacji. Co więcej, natura modeli UML jest taka, że ​​możliwy jest także proces odwrotny: automatyczna konstrukcja modelu z wykorzystaniem kodu gotowej aplikacji.

W języku angielskim automatyczna konstrukcja modelu przy użyciu kodu gotowej aplikacji nazywa się inżynierią odwrotną i zwykle jest tłumaczona na język rosyjski jako „inżynieria odwrotna”. Kategorycznie nie podoba nam się to tłumaczenie: co to za projekt i dlaczego jest odwrotnie? Istnieje dobra alternatywna opcja: „analiza inżynierii programu”, ale nie znalazła ona jeszcze szerokiego zastosowania.

To, co zostało powiedziane w poprzednim akapicie, wymaga zastrzeżeń „w pewnym stopniu”, „w pewnym stopniu” dosłownie po każdym stwierdzeniu. Najbardziej denerwujące jest to, że w tej chwili nie można dokładnie wskazać „stopnia” i „miary”. Powodem nie jest to, że nikt się tym nie przejął, ale to, że jest to zadanie bardzo trudne, ale nie beznadziejne. Narzędzia wspierające UML są cały czas udoskonalane, zatem w przyszłości na pierwszy plan może wysunąć się trzeci cel UML-a.

Niektórzy programiści, zmęczeni niekończącym się debugowaniem, mogą pomyśleć, że jeśli nauczą się UML-a, wszystkie problemy programistyczne zostaną rozwiązane. Niestety, tak nie jest.

1.2.4. Dokumentacja

Modele UML to artefakty, które można przechowywać i wykorzystywać w obu postaciach dokumenty elektroniczne oraz w formie papierowej. W najnowsze wersje UML zrobił całkiem sporo, aby osiągnąć lepszą zgodność z tym celem. W szczególności określono reprezentację modeli UML w postaci dokumentów w formacie XMI, co zapewnia praktyczną interoperacyjność podczas pracy z modelami. Innymi słowy, modele UML nie są czymś samym w sobie, co można jedynie podziwiać – są to dokumenty, z których może korzystać większość różne sposoby, zaczynając od wydruku zdjęć, a kończąc na automatycznym generowaniu zrozumiałych dla człowieka opisów tekstowych.

XMI (XML Metadata Interchange) to zewnętrzny format danych oparty na języku XML (schemat i zbiór reguł używania tagów), przeznaczony do serializacji modeli i wymiany ich.

Wyjaśnijmy ostatnie zdanie poprzedniego akapitu. Norma wymaga, aby w wewnętrznej reprezentacji modelu dla każdego elementu modelowania była wydzielona przestrzeń, w której można zapisać nieformalny opis tekstowy tego elementu. Większość narzędzi spełnia ten wymóg: dosłownie dla każdej linii lub rysunku na diagramie można wprowadzić tekst wyjaśniający znaczenie i przeznaczenie tej konkretnej linii lub rysunku. Co więcej, wiele narzędzi jest w stanie zebrać kompletne, znaczące i dobrze sformatowane opisy z tych opisów tekstowych. dokumenty tekstowe, które można wykorzystać dokładnie tak, jak znane opisy tekstowe modelowanego układu. Niestety ta wspaniała szansa jest wykorzystywana w praktyce rzadziej niż na to zasługuje. Faktem jest, że tak jak programiści nie lubią i są leniwi w pisaniu znaczących komentarzy do kodu programu, tak architekci nie lubią i są leniwi w pisaniu tekstowych objaśnień do swoich diagramów.

1.2.5. Czym UML NIE jest

Nie należy myśleć, że UML jest panaceum na wszystkie dzieci ∇ programowanie chorób. Aby jasno zrozumieć cel i zakres UML-a, przydatne jest porównanie UML-a z innymi pokrewnymi zjawiskami.

∇ Technologia informacyjna co najwyżej pół wieku to jeszcze niemowlęctwo dla nowego obszaru ludzkiej działalności.

Po pierwsze, UML-em nie język programowania (chociaż generowanie kodu nie jest zabronione, patrz paragraf 1.2.3). Nie chodzi o to, że UML jest językiem graficznym, ale zdecydowana większość praktycznych języków programowania to języki tekstowe. O wiele ważniejsze jest to, że modele UML nie są zdefiniowane semantyka operacyjna, czyli sposób wykonywania modeli na komputerze nie jest zdefiniowany. Zrobiono to zupełnie świadomie, m.in W przeciwnym razie UML byłby zależny od jakiegoś modelu obliczalności, poziom abstrakcji jego pojęć musiałby zostać znacznie obniżony i nie spełniałby swojego głównego celu: służenia jako środek do określania aplikacji i innych systemów na dowolnym poziomie abstrakcji i w różne obszary tematyczne.

Po drugie, UML nie jest specyfikacją narzędzia(chociaż narzędzia są sugerowane i dostępne, na przykład Magic Draw, Rational Rose Enterprise, Visual Paradigm, Enterprise Architect itp.). Sam język w żaden sposób nie narzuca, w jaki sposób powinien być wspierany narzędziami. Rozwiązanie wszystkich problemów związanych z implementacją UML na komputerze pozostawiono całkowicie twórcom narzędzia.

Trzeci, UML nie jest modelem procesu tworzenia aplikacji(choć potrzebny jest model procesu rozwoju, a różni autorzy proponują wiele różnych modeli). Oczywiście autorzy UML mają swój własny model procesu - Rational Unified Process (RUP), o którym nie mogli nie pamiętać przy opracowywaniu języka, ale mimo to zrobili wszystko, aby wyeliminować bezpośredni wpływ RUP na UML i sprawiają, że UML nadaje się do użycia z dowolnym modelem procesu lub nawet bez niego.

Autorzy tej książki mają także własne zdanie na temat związku UML-a z modelem procesu wytwarzania oprogramowania (patrz podrozdział 5.2), które nie może nie wpłynąć na opis pragmatyki języka, jednak wszędzie tam, gdzie taki wpływ zostanie dostrzeżony, należy zachować odpowiednie zastrzeżenia są zrobione.

1.2.6. Sposoby wykorzystania UML-a

Z powyższego jasno wynika, że ​​UML ma na celu rozwiązywanie różnych problemów, dlatego może być używany i jest praktycznie używany na różne sposoby. Poniżej przedstawiamy różne sposoby wykorzystania języka UML.

Rysowanie obrazów. Grafika UML może i powinien być używany niezależnie od wszystkiego innego. Nawet rysowanie diagramów ołówkiem na papierze pozwala uporządkować myśli i uchwycić istotne informacje na temat modelowanej aplikacji lub innego systemu.

Wymiana informacji. Społeczność ludzi używających i rozumiejących UML szybko rośnie. Jeśli użyjesz UML-a, inni Cię zrozumieją, a Ty zrozumiesz innych od razu.

Specyfikacja systemu. Jest to najważniejszy sposób użycia języka UML. I chociaż UML nie jest w każdym przypadku całkowicie odpowiednim narzędziem do specyfikacji, mamy nadzieję, że w miarę rozwoju języka będzie coraz mniej wyjątków, w których UML nie ma zastosowania.

Ponowne wykorzystanie rozwiązań architektonicznych. Ponowne wykorzystanie opracowanych wcześniej rozwiązań jest kluczem do zwiększenia efektywności. Nasze stanowisko w tej sprawie zostało przedstawione w punkcie 5.2. Niestety modele UML były dotychczas ponownie wykorzystywane w bardzo ograniczonym zakresie.

Przypadek użycia rysunku obejmuje rysowanie diagramów UML w celu myślenia, dzielenia się pomysłami między ludźmi, dokumentowania i tym podobnych. Efektem mającym znaczenie dla Użytkownika w tym przypadku jest obraz samych diagramów. Ogólnie rzecz biorąc, w tym przypadku użycia języka narzędzie wspomagające nie jest zbyt potrzebne. Czasami bardziej praktyczne może być rysowanie diagramów ręcznie pisakiem, a następnie fotografowanie ich aparatem cyfrowym.

Przypadek użycia modelowania obejmuje tworzenie i modyfikowanie modelu systemu pod kątem elementów modelowania dostarczonych przez metamodel UML. Znaczącym rezultatem w tym przypadku jest czytelny maszynowo artefakt opisujący model. Dla uproszczenia taki artefakt nazwiemy po prostu modelem, czynność kompilacji modelu nazwiemy modelowaniem, a podmiot modelowania nazwiemy architektem Architektem.

Przypadek użycia deweloperskiego obejmuje szczegółowe modelowanie, implementację i testowanie aplikacji w języku UML. Znaczącym rezultatem dla użytkownika Programisty w tym przypadku jest działająca aplikacja, która może zostać skompilowana do języka obsługiwanego przez określony system programowania lub natychmiast zinterpretowana przez środowisko wykonawcze narzędzia. Ten przypadek użycia jest najtrudniejszy do wdrożenia.

Obecne narzędzia nie obsługują jednakowo tych przypadków użycia. Wszystkie narzędzia potrafią (źle lub dobrze) wizualizować wszystkie typy diagramów UML, niektóre narzędzia pozwalają na zbudowanie modelu, który pozwala na dalsze wykorzystanie, ale tylko nieliczne narzędzia potrafią wygenerować kod wykonywalny i nawet wtedy nie dla wszystkich diagramów. Istnieje wiele praktycznych i organizacyjnych powodów, dla których powyższe przypadki użycia nie są jednakowo wspierane i są wspierane w różnym stopniu w nowoczesnych narzędziach. Niektóre z tych powodów omówimy w kolejnych rozdziałach.

Unified Modeling Language (UML) można uznać za wynik dość długiej i niezakończonej jeszcze ewolucji metodologii modelowania i projektowania.

W latach 90. najpopularniejsze były trzy podejścia obiektowe:

W wyniku rywalizacji tych metod autorzy powyższych metodologii stworzyli ujednolicony język modelowania UML (rys. 1), który odziedziczył elementy obecne w innych językach. Poniżej znajduje się oryginalna terminologia zapożyczonych/odziedziczonych elementów języka tej metodologii - faktem jest, że obecnie istnieje kilka opcji tłumaczenia tych terminów na język rosyjski.

Ryż. 1. UML i jego poprzednicy

To zjednoczenie miało trzy główne cele:

Modelowanie systemu od koncepcji po moduł wykonywalny z wykorzystaniem technik obiektowych;

Rozwiązywanie problemów skalowalności w złożonych systemach;

Stworzenie języka modelowania, który może być używany zarówno przez ludzi, jak i komputery.

Za oficjalną datę rozpoczęcia prac nad UML-em uznaje się październik 1994 roku, kiedy Rambo przeniósł się do Rational (obecnie Rational jest jednym z oddziałów IBM Corporation). Najnowszym standardem dla tego języka jest UML1.3, wydany w 1999 roku.

Narzędzia do modelowania UML

Czy UML jest niezbędnym składnikiem RUP? Tak, zdecydowanie. Jednak praktyka stosowania UML-a do opisu procesu modelowania i tworzenia oprogramowania nie ogranicza się do RUP. Jak każdy inny język, UML jest tylko narzędziem. RUP udostępnia szereg narzędzi, które znacznie ułatwiają korzystanie z języka UML, ale nie ograniczają się one do produktów IBM/Rational. Poniżej jest daleko pełna lista niektóre produkty obsługujące UML:

Rational Rose (Rational Software, Windows 98/NT/2000/XP, Linux Red Hat 6.2, 7.0, Solaris 2.5.1, 2.6, 7, 8, HP-UX 10.20, 11.0, 11.i);

Microsoft Visual Studio .NET Enterprise Architect, Microsoft Visio (Microsoft, platformy: Windows 98/NT/2000/XP/Server 2003);

Opisz Enterprise (technologie Embarcadero, platformy: Windows 98/NT/2000/XP);

Razem rodzina produktów (Borland, platformy: Windows 98/NT/2000/XP, Linux, Solaris);

Bold dla Delphi (Borland, platformy: Windows 98/NT/2000/XP);

MagicDraw (Magic, Inc., platformy: Windows 98/Me/NT/2000/XP, Solaris, OS/2, Linux, HP-UX, AIX, Mac OS);

QuickUML (ExcelSoftware, platformy: Windows 98/NT/2000/XP) to dobre narzędzie dla początkujących.

Zwróćmy także uwagę na niektóre produkty OpenSourse, na przykład ArgoUML, Novosoft UML Library.

Dokument zawierający listę produktów obsługujących UML, firmy produkcyjne, platformy oraz informacje o szacunkowych cenach produktów można znaleźć pod adresem: http://www.objectsbydesign.com/tools/umltools_byCompany.html.

Należy również zaznaczyć, że pomimo istnienia standardu UML 1.3, implementacje UML obsługiwane przez te produkty albo mają swoje własne cechy, albo nie są w pełni zgodne ze standardem, dlatego przy wyborze narzędzia do modelowania należy zwrócić uwagę na obsługiwane typy diagramów i cechy składni. Ponadto możliwości inżynierii do przodu i do tyłu (inżynieria w obie strony) znacznie się różnią w zależności od produktu. Nie wszystkie powyższe produkty mogą obsługiwać języki Programowanie w Javie, C++, CORBA IDL, dlatego należy zwrócić szczególną uwagę na to, jaki model dany produkt może wygenerować z istniejącego kodu, w jakim języku można uzyskać kod z Twojego modelu UML i jakiego typu powinien być.

Tabela pokazująca, które diagramy UML są zaimplementowane w danym produkcie, można znaleźć pod adresem: http://www.jeckle.de/umltools.htm.

Do czego służy UML?

UML jest przede wszystkim językiem i jak każde narzędzie językowe udostępnia słownik i zasady łączenia słów w tym słowniku. W tym przypadku słownictwo i reguły skupiają się na koncepcyjnych i fizycznych reprezentacjach systemu. Język dyktuje, jak tworzyć i czytać model, ale nie dostarcza żadnych wskazówek, jaki rodzaj modelu systemu należy utworzyć; wykracza to poza zakres UML i jest domeną procesu tworzenia oprogramowania. W związku z tym wydaje się, że UML jest dość często kojarzony z RUP, jednym z możliwych procesów, które rekomendują, jakie modele, jak i kiedy tworzyć, aby zapewnić pomyślny rozwój produktu.

UML jest językiem wizualizacji. Pisanie modeli w języku UML ma jeden prosty cel – ułatwić proces przekazywania informacji o systemie. Każdy symbol UML ma ściśle określoną semantykę, co pozwala uniknąć błędów interpretacyjnych (odpowiedzi na pytania typu „co programista X miał na myśli, opisując hierarchię klas Y...” itp. będą w miarę przejrzyste).

UML to język specyfikacji i precyzyjnych definicji. W tym sensie modelowanie UML oznacza budowanie modeli, które są dokładne, jednoznaczne i kompletne.

UML to język projektowania. UML nie jest wizualnym językiem programowania, ale modele w języku UML można odwzorować na określony zestaw obiektowych języków programowania. UML zapewnia bezpośrednie (istniejący model ® nowy kod) i odwrotnie (istniejący kod ® nowy model) projekt. Dość często narzędzia do modelowania UML implementują mapowania modeli UML w kodzie w językach Java, C++, CORBA, VB, Smalltalk.

UML jest językiem dokumentacji. Proces tworzenia oprogramowania obejmuje nie tylko pisanie kodu, ale także tworzenie artefaktów, takich jak lista wymagań, opis architektury, projekt, kod źródłowy systemu, planowanie projektu, testy, zestaw prototypów i wydania produktów. W zależności od kultury rozwoju produktu w danej firmie stopień sformalizowania tych dokumentów jest bardzo zróżnicowany, począwszy od ściśle określonych szablonów i formatów dokumentów, po rozmowy na dowolny temat za pośrednictwem poczty elektronicznej lub osobiście. Jednakże wszystkie te artefakty mają kluczowe znaczenie dla pomyślnego procesu rozwoju produktu. UML dostarcza narzędzi do wyświetlania wymagań systemowych, konstruowania dokumentacji, testowania, modelowania działań niezbędnych do planowania projektu i zarządzania wydaniami dostarczanymi użytkownikowi końcowemu.

Elementy języka

Głównymi elementami UML-a są encje (Rzecz), relacje (Relacja), diagramy (Diagram). Jednostki są podstawowymi abstrakcjami języka, relacje łączą je ze sobą, a diagramy grupują zbiory interesujących nas jednostek.

Podmioty

Jednostki strukturalne są rzeczownikami języka (ryc. 2). Obejmują one:

zajęcia (klasa) to zbiór obiektów, które mają te same atrybuty, operacje, relacje i semantykę. Klasa implementuje jeden lub więcej interfejsów i jest przedstawiana jako prostokąt zawierający nazwę klasy, nazwy atrybutów, operacje i uwagę;

interfejsy to zestaw operacji definiujących usługę lub komponenty klasy. Interfejs jest reprezentowany graficznie jako okrąg i zwykle jest dołączony do klasy lub komponentu, który implementuje interfejs;

współpraca definiują interakcje i służą do łączenia ról i innych elementów, które oddziałują ze sobą, tak że powstałe zachowanie obiektu jest większe niż suma wszystkich elementów. Przedstawiany jako elipsa z kropkowaną krawędzią;

Przypadki użycia opis zbioru sekwencji akcji wykonywanych przez system i mających znaczenie dla konkretnego aktora (Aktora). Przypadki użycia są przedstawiane w postaci elipsy i służą do strukturyzowania jednostek behawioralnych w modelu;

zajęcia aktywne są to klasy, których instancje są aktywnymi obiektami, które posiadają proces lub przepływ kontroli i mogą inicjować działania kontrolne. Stereotypy konkretnej klasy to Proces i Wątek. Graficznie taka klasa jest przedstawiona jako klasa z grubą ramką;

składniki są to fizycznie wymienne części systemu, które umożliwiają realizację szeregu interfejsów. Komponent to fizyczna reprezentacja elementów logicznych, takich jak klasy, interfejsy i kooperacje. Dziedzina komponentów odnosi się do implementacji. Komponenty są pokazane jako prostokąt z etykietami po lewej stronie i zwykle mają tylko nazwę i notatkę;

węzły obiekty fizyczne, które istnieją podczas wykonywania programu i reprezentują zasób komunikacyjny posiadający przynajmniej pamięć, a często także procesor. Węzły mogą zawierać wykonywalne obiekty i komponenty. Węzły są pokazane jako sześcian i mają nazwę oraz notatkę.

Dane tych siedmiu typów obiektów są podstawowymi obiektami strukturalnymi UML-a. Istnieją również odmiany tych obiektów, takie jak aktorzy (Actor), sygnały (Signal), narzędzia (Utility - rodzaj klasy), procesy i wątki (Process i Thread - typy aktywnej klasy), aplikacje (Application), dokumenty (dokument), pliki (Plik), biblioteki (Biblioteka), strony (Strona), tabele (Tabela).

Jednostki behawioralne są dynamiczną częścią modeli UML (rysunek 3). Obejmują one:

Interakcja zawierać zestaw komunikatów wymienianych pomiędzy określonymi obiektami w celu osiągnięcia określonego celu. Interakcja opisana jest w kontekście współpracy i przedstawiona jest za pomocą skierowanej linii, oznaczonej u góry nazwą operacji;

Maszyny stanu specyfikacje zachowania, czyli sekwencje stanów, przez które przechodzi obiekt w trakcie swojego życia, lub interakcja w reakcji na zachodzące zdarzenia (a także reakcja obiektu na te zdarzenia). Automat jest dołączony do pierwotnego elementu (klasy, współpracy lub metody) i służy do określenia zachowania jego instancji. Maszyna jest przedstawiona jako prostokąt z zaokrąglonymi narożnikami.

Grupowanie podmiotów są to elementy organizacyjne modeli UML. Obejmują one pakiety uogólniony mechanizm organizowania elementów w grupy. W pakiecie można umieścić elementy strukturalne, behawioralne i grupujące. Pakiety są bytami czysto koncepcyjnymi, w przeciwieństwie do komponentów istniejących w czasie wykonywania. Pakiet jest wyświetlany jako folder ze skrótem u góry i z reguły ma tylko nazwę.

Elementy adnotacji są to wyjaśniające elementy modeli UML, które obejmują notatki elementy objaśniające języka (ryc. 4). Zawierają tekst komentarza i mają postać prostokąta z zagiętym rogiem strony.

Relacja

Do podstawowych relacji pomiędzy obiektami pozwalających na budowę bloków UML zaliczamy (rys. 5):

zależność jest to relacja semantyczna pomiędzy dwoma bytami, w której zmiana w jednym z nich (byt niezależny) może wpłynąć na semantykę drugiego (bytu zależnego). Poniżej wymieniono typy zależności odpowiadające kilku typom relacji pomiędzy obiektami:

- abstrakcja reprezentuje zmianę poziomu abstrakcji jakiegoś pojęcia. Z reguły jeden z elementów jest bardziej abstrakcyjny, a drugi bardziej konkretny, choć zdarzają się sytuacje, gdy oba elementy są po dwa możliwe opcje pojęcia istniejące na tym samym poziomie abstrakcji. Zależność abstrakcji obejmuje następujące stereotypy (w kolejności rosnącej szczegółowości relacji): śledzenie (Trace), udoskonalanie (Refine), implementowanie (posiada własną notację) i wyprowadzanie (Derive),

- Wiążący kojarzy element z szablonem. Argumenty wymagane dla parametrów szablonu są dołączone do zależności wiązania w postaci listy,

- połączenie koreluje dwie części opisu klasyfikatora (dowolny element modelu opisujący pewne cechy struktury i zachowania systemu) w celu uzyskania pełnego opisu elementu,

- pozwolenie Zależność (zawsze przedstawiana jako specjalny stereotyp), która łączy pakiet (lub klasę) z innym pakietem (lub klasą), któremu udziela pozwolenia na użycie jego zawartości. Stereotypy zależności uprawnień to: Dostęp, Przyjaciel i Import.

- Stosowanie opisuje sytuację, w której jeden element wymaga obecności innego elementu do prawidłowego wdrożenia lub działania. Stereotypy tego typu zależności obejmują: wywołanie, utworzenie instancji, parametr i wysłanie;

Stowarzyszenie relacja strukturalna opisująca zbiór połączeń pomiędzy obiektami klasyfikatora, gdzie połączenie (Link) to połączenie pomiędzy obiektami opisujące połączenia pomiędzy ich instancjami. Skojarzenia są jak klej spajający system. Bez skojarzeń mielibyśmy po prostu wiele klas, które nie są w stanie ze sobą współdziałać. Stowarzyszenie może mieć nazwę, ale główne informacje o skojarzeniu należy znaleźć na jego biegunach, które opisują sposób, w jaki każdy obiekt uczestniczy w skojarzeniu: skojarzenie posiada listę składającą się z dwóch lub więcej biegunów skojarzenia: każdy z nich określa rolę że ten pełni rolę klasyfikatora w tym skojarzeniu. Ten sam klasyfikator może pełnić kilka ról, które nie są zamienne. Każdy biegun skojarzenia opisuje właściwości, które mają zastosowanie do konkretnego obiektu w tym skojarzeniu, np. ile razy jeden obiekt może pojawić się w relacjach (wielokrotność). Niektóre właściwości (takie jak nawigowalność) mają zastosowanie tylko do powiązań binarnych, chociaż większość właściwości ma zastosowanie zarówno do powiązań binarnych, jak i n-arnych;

uogólnienie jest to relacja specjalizacji/uogólnienia, w której obiekty elementu wyspecjalizowanego (dziecko) można zastąpić obiektami elementu uogólnionego (rodzic, przodek, rodzic). W przypadku uogólnienia klas bezpośredni przodek można nazwać nadklasą, a bezpośredni potomek można nazwać podklasą;

Realizacja związek pomiędzy specyfikacją a jej implementacją oprogramowania; wskazówka, że ​​zachowanie jest dziedziczone bez struktury.

Wymieniliśmy cztery główne zależności. W UML-u występują także ich warianty: udoskonalenie (Refinement), śledzenie (Trace), włączenie (Include), rozszerzenie (Extend).

Diagramy UML-a

Wizualizacja projektu systemu z różnych punktów widzenia w języku UML realizowana jest poprzez diagramy – rzuty systemu. Schemat jest Reprezentacja graficzna zbiór elementów, który jest przedstawiany jako połączony graf z wierzchołkami (bytami) i krawędziami (związkami).

Najczęściej UML postrzega system z pięciu powiązanych ze sobą perspektyw (rysunek 6).

Widok przypadków użycia zawiera historie użytkowników, które opisują system z punktu widzenia użytkownika końcowego, analityka, testera. Ta reprezentacja nie definiuje struktury oprogramowania, ale ma na celu przekazanie ogólnego widoku systemu. W języku UML jest to przedstawiane za pomocą diagramów przypadków użycia; aspekt dynamiczny jest reprezentowany na diagramach interakcji, diagramach stanów i diagramach aktywności.

Widok Projekt zawiera klasy, interfejsy i kooperacje, które tworzą słownik problemu i jego rozwiązania. Ta prezentacja wspiera przede wszystkim wymagania funkcjonalne dla systemu, wartość usług, które system musi świadczyć użytkownikowi końcowemu. W UML jest to przedstawiane poprzez diagramy klas (diagram klas) i obiekty (diagram obiektów), aspekt dynamiczny jest wyświetlany na diagramach interakcji, stanu i aktywności.

Widok procesu obejmuje wątki i procesy tworzące przetwarzanie równoległe i synchronizację w systemie. Widok ten dotyczy przede wszystkim wydajności, skalowalności i przepustowości systemu. W UML aspekty statyczne i dynamiczne są reprezentowane przez te same diagramy, co w widoku Projekt, ale nacisk położony jest na aktywne klasy reprezentujące procesy i wątki.

Widok Implementacja zawiera komponenty i pliki użyte do zbudowania systemu. Ten pogląd dotyczy przede wszystkim zarządzania konfiguracją wydań produktów. Aspekt statyczny w UML jest reprezentowany przez diagram komponentów, a aspekt dynamiczny przez diagramy interakcji, stanu i aktywności.

Widok Wdrożenie obejmuje węzły i ich interakcje - definiują topologię sprzętu, na którym działa oprogramowanie. Pogląd ten odnosi się przede wszystkim do dystrybucji, dostawy i instalacji komponentów tworzących system fizyczny. Aspekt statyczny w UML jest reprezentowany przez diagram wdrożenia, a aspekt dynamiczny przez diagramy interakcji, stanu i aktywności.

Poniżej znajdują się definicje i przykłady diagramów:

Schemat klas diagram strukturalny pokazujący wiele klas, interfejsów, kooperacji i relacji między nimi (ryc. 7);

Schemat obiektu diagram struktury przedstawiający wiele obiektów i relacje między nimi. Można to uznać za szczególny przypadek diagramu klas. Narzędzia do modelowania nie muszą obsługiwać osobnego formatu diagramów cech. Przedstawiają obiekty, więc diagram klas, który nie ma klas, ale zawiera należące do nich obiekty, można uznać za diagram obiektowy;

Diagram przypadków użycia diagram zachowań, który pokazuje wiele precedensów i aktorów oraz zależności między nimi (ryc. 8);

Schemat interakcji:

- Diagram sekwencyjny diagram zachowania, który pokazuje interakcję i podkreśla sekwencję czasową zdarzeń (ryc. 9),

- Schemat współpracy Diagram zachowania przedstawiający interakcje i wyróżnianie organizacja strukturalna obiekty wysyłające i odbierające wiadomości (ryc. 10);

Diagram stanu diagram zachowania, który pokazuje maszynę i kładzie nacisk na zachowanie obiektów pod względem kolejności odbierania zdarzeń (ryc. 11);

Diagram aktywności diagram zachowania, który pokazuje maszynę i podkreśla przejścia przepływu sterowania z jednej czynności do drugiej (ryc. 12);

Schemat komponentów diagram przedstawiający organizację pewnego zbioru komponentów i zależności między nimi, nawiązuje do statystycznego widoku systemu (ryc. 13);

diagram topologii systemu (schemat wdrożenia) schemat strukturalny przedstawiający węzły i relacje między nimi (ryc. 14).

Ciąg dalszy nastąpi.

Diagramy strukturalne: Diagram klas Diagram komponentów Struktura złożona Diagram współpracy UML2.0 Diagram wdrożenia Diagram obiektów Diagram pakietu Diagram profilu UML2.2 Diagramy zachowań: Diagram aktywności Diagram stanu Diagram przypadków użycia Diagramy interakcji: Diagram komunikacji UML2.0 Diagram współpracy UML1.

Jeśli ta praca Ci nie odpowiada, na dole strony znajduje się lista podobnych prac. Możesz także skorzystać z przycisku wyszukiwania

Metodologia UML-a. Diagramy UML-a.

Metodologia UML-a

UML (ujednolicony język modelowania) ujednolicony język modelowania) Język opisu graficznego dla modelowanie obiektów w pobliżu rozwój oprogramowania. UML jest językiem ogólnym, to prawdastandard otwarty, który do tworzenia wykorzystuje notację graficznąabstrakcyjny model system zwany modelem UML . UML został stworzony, aby definiować, wizualizować, projektować i dokumentować przede wszystkim systemy oprogramowania. UML nie jest językiem programowania, ale generowanie kodu jest możliwe dzięki sposobom wykonywania modeli UML jako kodu interpretowanego.

Zastosowanie UML-a nie ogranicza się do modelowania oprogramowania. Służy również domodelowanie procesów biznesowych, Inżynieria systemowa i wyświetlić struktury organizacyjne.

Stosowanie

UML umożliwia także twórcom oprogramowania uzgodnienie notacji graficznych reprezentujących wspólne koncepcje (takie jak klasa, komponent, uogólnienie, agregacja i zachowanie) i skupienie się bardziej na projektowaniu i architekturze.

Schematy

W języku UML używane są następujące typy diagramy (aby uniknąć dwuznaczności, oznaczenia na język angielski):

Strukturę diagramów UML 2.3 można przedstawić na diagramie klas UML:

Schemat klas

Schemat klas(Diagram klas) statyczny diagram strukturalny opisujący strukturę systemu, przedstawiający klasy systemu, ich atrybuty, metody i zależności pomiędzy klasami.

Istnieją różne punkty widzenia na temat konstruowania diagramów klas w zależności od celów ich użycia:

• z koncepcyjnego punktu widzenia diagram klas opisuje model obszaru tematycznego, zawiera jedynie klasy zastosowanych obiektów;
• Specyfikacja punktu widzenia diagram klas stosowany w projektowaniu systemy informacyjne;
• Diagram klas z punktu widzenia implementacji zawiera klasy używane bezpośrednio w kodzie programu (w przypadku używania obiektowych języków programowania).

Schemat komponentów

Schemat komponentów(Schemat komponentów) statyczny schemat strukturalny, pokazuje awarię systemu oprogramowania na komponentach konstrukcyjnych i połączeniach (zależnościach) pomiędzy komponentami. Komponentami fizycznymi mogą być pliki, biblioteki, moduły, pliki wykonywalne, pakiety itp.

Wzór projektowy Dekorator na schemacie współpracy

Schemat struktury złożonej/kompozytowej(Schemat struktury złożonej) statyczny diagram strukturalny, pokazuje wewnętrzną strukturę klas i, jeśli to możliwe, interakcję elementów (części) wewnętrznej struktury klasy.

Podtypem diagramów struktur złożonych sąschematy współpracy(Schemat współpracy wprowadzony w UML 2.0), który pokazuje role i interakcje klas w ramach współpracy. Współpraca jest wygodna w modelowaniuwzorce projektowe.

Diagramy struktur złożonych mogą być używane w połączeniu z diagramami klas.

Schemat wdrożenia

Schemat wdrożenia(Schemat rozmieszczenia) służy do symulacji pracy węzły (sprzęt komputerowy, język angielski węzeł) i artefakty , rozmieszczone na nich. W UML 2 artefakty są wdrażane w węzłach ( język angielski artefakt ), podczas gdy w UML 1 komponenty zostały wdrożone na węzłach. Ustanawiana jest zależność manifestacji pomiędzy artefaktem a elementem logicznym (komponentem), który on implementuje.

Schemat obiektu

Schemat obiektu(Schemat obiektowy) przedstawia pełną lub częściową migawkę symulowanego systemu w danym momencie. Diagram obiektowy wyświetla instancje klas (obiektów) systemu, wskazując aktualne wartości ich atrybutów i relacje między obiektami.

Schemat pakietu

Schemat pakietu(Schemat pakietu) schemat strukturalny, którego główną treścią jest pakiety i relacje między nimi. Nie ma ścisłego rozróżnienia pomiędzy różnymi diagramami struktur, dlatego nazwa ta została podana jedynie dla wygody i nie ma znaczenia semantycznego (pakiety i diagramy pakietów mogą pojawiać się na innych diagramach struktur). Diagramy pakietów służą przede wszystkim organizowaniu elementów w grupy według jakiejś cechy, aby uprościć strukturę i uporządkować pracę z modelem systemu.

Diagram aktywności

Diagram aktywności(Schemat aktywności) diagram przedstawiający rozkład niektórych zajęcia na jego części składowe. W ramach aktywności ( język angielski działalność ) rozumiany jest jako specyfikacja wykonywalnego zachowania w postaci skoordynowanego, sekwencyjnego i równoległego wykonywania podległych elementów działań zagnieżdżonych i indywidualnych działanie ), połączone strumieniami przechodzącymi z wyjść jednego węzła do wejść drugiego.

Diagramy aktywności znajdują zastosowanie w modelowaniu procesów biznesowych, procesów technologicznych, obliczeniach sekwencyjnych i równoległych.

Analogiem diagramów aktywności sądiagramy algorytmów zgodnie z GOST 19.701-90.

Schemat maszyny

Schemat maszyny(schemat maszyny stanu, schemat maszyny stanowej, diagram stanu) pokazano schematmaszyna stanu z prostymi stanami , przejścia i stany złożone.

Maszyna stanu(eng. Maszyna stanu ) określenie sekwencji stanów, przez które przechodzi obiekt lub interakcja w odpowiedzi na wydarzenia w życiu, a także reakcje obiektu na te wydarzenia. Maszyna stanów jest dołączona do elementu źródłowego ( klasa, współpraca lub metoda) i służy do określenia zachowania jego instancji.

Diagram przypadków użyciaDiagram przypadków użycia – diagram przedstawiający zależności istniejące pomiędzy aktorzy i przypadków użycia.

Głównym zadaniem jest reprezentowanie pojedynczy środek, umożliwiając klientowi, użytkownikowi końcowemu i programiście wspólną dyskusję na temat funkcjonalności i zachowania systemu.

Diagramy komunikacji i sekwencji przechodni , wyrażają interakcję, ale pokazują ją na różne sposoby i można je konwertować między sobą z wystarczającą dokładnością.

Schemat komunikacji(Schemat komunikacji w UML 1.xschemat współpracy, schemat współpracy ) diagram przedstawiający interakcje pomiędzy częściami złożonej struktury lub role współpracy. W odróżnieniu od diagramu sekwencji, diagram komunikacyjny wyraźnie wskazuje zależności pomiędzy elementami (obiektami) i nie wykorzystuje czasu jako odrębnego wymiaru (stosuje się numery porządkowe wywołań).

Diagram sekwencyjny(Diagram sekwencji) diagram przedstawiający interakcję obiektów uporządkowanych w czasie. W szczególności ukazuje obiekty uczestniczące w interakcji oraz sekwencję przekazów, jakie wymieniają.

Schemat współpracyTen typ diagramu pozwala opisać interakcje obiektów, abstrahując od kolejności przekazywania komunikatów. Ten typ diagramu pokazuje w zwartej formie wszystkie odebrane i przesłane wiadomości danego obiektu oraz rodzaje tych wiadomości.

Ponieważ diagramy sekwencji i współpracy to różne widoki tych samych procesów, Racjonalna róża umożliwia utworzenie diagramu współpracy z diagramu sekwencji i odwrotnie, a także automatycznie synchronizuje te diagramy.

Diagram przeglądu interakcji(diagram przeglądu interakcji) rodzaj diagramu aktywności, który zawiera fragmenty diagramu sekwencji i konstrukcje przepływu sterowania.

Ten typ diagramu obejmuje diagram sekwencji i diagram współpracy. Diagramy te pozwalają rozważyć interakcję obiektów w tworzonym systemie z różnych punktów widzenia.

Schemat czasowy

Schemat czasowyDiagram czasowy Alternatywna reprezentacja diagramu sekwencji, która wyraźnie pokazuje zmiany stanu wzdłuż linii życia w danej skali czasu. Może być przydatny w aplikacjach czasu rzeczywistego.

STRONA 7

Zalety UML-a

• 1. UML jest językiem obiektowym, w wyniku czego metody opisu wyników analiz i projektowania są semantycznie zbliżone do metod programowania współczesnych języków OO;
• 2. UML pozwala opisać system z niemal wszystkich możliwych punktów widzenia i różnych aspektów zachowania systemu;
• 3. Diagramy UML są stosunkowo łatwe do odczytania, jeśli dość szybko zaznajomisz się z ich składnią;
• 4. Zmniejszenie liczby możliwe błędy takie jak: niespójne parametry podprogramów, niespójne zmiany atrybutów;
• 5. Użyj ponownie. Zakłada się pewną możliwość ponownego wykorzystania istniejącego projektu lub jego części w nowym projekcie;
• 6. UML rozwija się i pozwala na wprowadzanie własnych stereotypów tekstowych i graficznych, co sprzyja jego wykorzystaniu nie tylko w dziedzinie inżynierii oprogramowania;
• 7. UML stał się powszechny i ​​dynamicznie się rozwija.

Wady UML-a

Pomimo tego, że UML jest dość powszechnym i stosowanym standardem, często spotyka się go z krytyką ze względu na następujące niedociągnięcia:

• 1. Redundancja języka. UML jest często krytykowany jako niepotrzebnie duży i złożony. Zawiera wiele zbędnych lub w dużej mierze nieużywanych diagramów i konstrukcji. Usłyszysz to częściej w odniesieniu do UML 2.0 niż UML 1.0, ponieważ nowsze wersje zawierają więcej kompromisów.
• 2. Niedokładna semantyka. Ponieważ UML jest zdefiniowany przez kombinację samego siebie (składnia abstrakcyjna), OCL (język ograniczeń formalnych) i języka angielskiego (szczegółowa semantyka), nie ma on ograniczeń właściwych dla języków precyzyjnie zdefiniowanych za pomocą technik opisu formalnego. W niektórych przypadkach abstrakcyjna składnia UML, OCL i języka angielskiego jest ze sobą sprzeczna, w innych jest niekompletna. Nieprecyzyjne opisy samego UML-a mają wpływ zarówno na użytkowników, jak i dostawców narzędzi, prowadząc do niekompatybilności narzędzi z powodu unikalnych interpretacji specyfikacji.
• 3. Problemy w trakcie studiów i realizacji. Powyższe kwestie sprawiają, że nauka i wdrażanie UML-a staje się problematyczne, szczególnie gdy kierownictwo zmusza inżynierów do używania UML-a bez wcześniejszej wiedzy.
• 4. Tylko kod odzwierciedla kod. Inna opinia jest taka, że ​​ważne są działające systemy, a nie piękne modele. Jak zwięźle ujął to Jack Reeves: „Kod to projekt”. Zgodnie z tym poglądem istnieje potrzeba lepszego sposobu pisania oprogramowania; UML jest ceniony w podejściach, które kompilują modele w celu wygenerowania kodu źródłowego lub wykonywalnego. Jednak to może nadal nie wystarczyć, ponieważ UML nie jest kompletny w technologii Turinga i każdy wygenerowany kod będzie ograniczony do tego, co narzędzie interpretujące UML może zobaczyć lub wywnioskować.
• 5. Skumulowana impedancja/niedopasowanie impedancji. Niedopasowanie obciążenia to termin z teorii analizy systemów, który oznacza niezdolność wejścia systemu do postrzegania wyjścia innego. Jak w przypadku każdej notacji, UML może reprezentować niektóre systemy w bardziej zwięzły i skuteczny sposób niż inne. Dlatego programista skłania się w stronę rozwiązań, które są wygodniejsze dzięki przeplatającym się zaletom UML i języków programowania. Problem staje się bardziej oczywisty, jeśli język programowania nie trzyma się zasad ortodoksyjnej doktryny obiektowej (nie stara się dostosować do tradycyjnych zasad OOP).
• 6. Stara się być wszystkim dla wszystkich. UML to język modelowania ogólnego przeznaczenia, który stara się osiągnąć zgodność ze wszystkimi możliwymi językami programowania. Aby w kontekście konkretnego projektu zespół projektowy mógł osiągnąć konkretny cel, należy dobrać odpowiednie możliwości UML. Co więcej, sposoby ograniczenia zakresu UML-a w określonej domenie polegają na formalizmie, który nie jest w pełni wyartykułowany i który sam w sobie podlega krytyce.
• 7. Komplikacja metodologii. Stosowanie podejścia obiektowego wymaga wprowadzenia dodatkowych sposobów prezentacji informacji o tematyce oraz metod jej analizy. Język UML obejmuje ponad 100 różnych symbolika. Skuteczne wykorzystanie takiego mechanizmu wymaga pewnego poziomu kwalifikacji specjalistów. W przypadku małych projektów bardziej efektywne może być zastosowanie klasycznych metod programistycznych. Tworzenie projektów, dla których najważniejszym zadaniem jest opisanie tematyki, a dla których nie da się znaleźć osoby rozumiejącej tę tematykę jako całość, również wymaga stosowania podejść tradycyjnych, ze względu na ich większą dostępność nie-specjaliści.

Diagram UML to wyspecjalizowany język opisu graficznego przeznaczony do modelowania obiektów przy tworzeniu różnego rodzaju oprogramowania. Język ma szeroki profil i jest otwartym standardem, który wykorzystuje różne notacje graficzne do stworzenia abstrakcyjnego modelu systemu. UML został stworzony, aby umożliwić definiowanie, wizualizację, dokumentację i projektowanie wszelkiego rodzaju systemów oprogramowania. Warto zaznaczyć, że sam diagram UML nie jest językiem programowania, ale daje możliwość wygenerowania na jego podstawie osobnego kodu.

Dlaczego jest to potrzebne?

Zastosowanie UML-a 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.

Dzięki UML twórcy oprogramowania mogą zapewnić pełną zgodność w notacji graficznej używanej do reprezentowania typowych pojęć, takich jak: komponent, rodzaj, klasa, zachowanie i agregacja. Dzięki temu jest to osiągane wysoki stopień koncentrując się na architekturze i inżynierii.

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

Schemat klas

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

Warto zauważyć, że istnieje kilka punktów widzenia na budowę takich diagramów, w zależności od tego, w jaki sposób będą one wykorzystywane:

• Konceptualistyczny. W tym przypadku diagram klas UML opisuje model konkretnego obszaru tematycznego i udostępnia jedynie klasy obiektów aplikacji.
• Konkretny. Diagram jest wykorzystywany 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 zademonstrowanie podziału konkretnego systemu oprogramowania na różne elementy konstrukcyjne, a także powiązania między nimi. Diagram komponentów UML może wykorzystywać wszelkiego rodzaju modele, biblioteki, pliki, pakiety, pliki wykonywalne i wiele innych elementów.

Schemat struktury złożonej/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 schemat może również pokazać interakcję elementów znajdujących się w Struktura wewnętrzna klasa.

Ich podtypem jest diagram współpracy UML, który służy do ukazania ról, a także interakcji różnych klas w granicach kooperacji. Są całkiem wygodne, jeśli chcesz modelować wzorce projektowe.

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

Schemat wdrożenia

Diagram ten 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. Zatem diagram wdrażania UML jest używany głównie w drugiej wersji.

Pomiędzy artefaktem a komponentem, który implementuje, powstaje zależność manifestacji.

Schemat obiektu

Widok ten 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

Schemat ten ma charakter strukturalny, a jego główną zawartością są wszelkiego rodzaju pakiety, a także relacje pomiędzy nimi. W tym przypadku nie ma ścisłego podziału na kilka schematów strukturalnych, 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ą dawać inne diagramy UML (przykłady: pakiety i same diagramy pakietów).

Ich zastosowanie ma na celu zapewnienie organizacji kilku elementów w grupy według określonego kryterium w celu uproszczenia konstrukcji, a także uporządkowanie pracy z modelem danego układu.

Diagram aktywności

Diagram aktywności UML przedstawia rozkład określonego działania na kilka części składowych. W tym przypadku pojęcie „działania” to specyfikacja określonego wykonywalnego zachowania w postaci równoległego, a także skoordynowanego sekwencyjnego wykonywania różnych podrzędnych elementów - zagnieżdżonych typów działań i różnych działań, połączonych przepływami wychodzącymi z wyjść jednego węzła do wejść innego.

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

Schemat maszyny

Ten typ nazywany jest także nieco inaczej – diagramem stanu UML. Posiada przedstawioną maszynę skończoną ze stanami prostymi i złożonymi oraz przejściami.

Maszyna stanów to specyfikacja ciągu różnych stanów, przez które przechodzi określony obiekt lub interakcja w odpowiedzi na pewne zdarzenia w jego życiu, a także reakcja obiektu na takie zdarzenia. Maszyna stanów korzystająca z diagramu stanu UML jest dołączana do elementu źródłowego i używana do definiowania zachowania jej instancji.

Analogami takich diagramów mogą być tzw. diagramy smoków.

Użyj diagramów przypadków

Diagram przypadków użycia UML przedstawia wszystkie relacje zachodzące pomię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 dowolny programista może wspólnie omówić zachowanie i funkcjonalność określonego systemu.

Jeśli w procesie modelowania systemu zostanie wykorzystany diagram przypadków użycia UML, analityk:

• Wyraźnie oddziel modelowany system od jego otoczenia.
• Zidentyfikuj aktorów, sposoby ich interakcji z tym systemem, a także jego oczekiwaną funkcjonalność.
• W słowniczku jako temat należy umieścić różne pojęcia, do których się odnoszą szczegółowy opis funkcjonalność tego systemu.

Jeżeli diagram użycia jest opracowany w języku UML, procedura rozpoczyna się od opisu tekstowego, który uzyskujemy podczas pracy z klientem. Warto zwrócić uwagę na fakt, że w procesie tworzenia modelu przypadków użycia całkowicie pomija się różne wymagania niefunkcjonalne, a dla nich generowany będzie odrębny dokument.

Komunikacja

Diagram komunikacyjny, podobnie jak diagram sekwencji UML, jest przechodni, to znaczy wyraża interakcję, ale jednocześnie demonstruje ją na różne sposoby i, jeśli to konieczne, może być konwertowany między sobą z wymaganą dokładnością .

Diagram komunikacji odzwierciedla interakcje zachodzące pomiędzy różnymi elementami złożonej struktury, a także role współpracy. Główna różnica między nim a diagramem sekwencji polega na tym, że sprawia, że ​​relacje między kilkoma elementami są dość wyraźne i nie wykorzystuje czasu jako odrębnego wymiaru.

Ten typ Posiada całkowicie darmowy format do rozmieszczania wielu obiektów i połączeń w taki sam sposób, jak na schemacie obiektów. Jeżeli istnieje potrzeba zachowania kolejności wiadomości w tym swobodnym formacie, są one numerowane chronologicznie. Czytanie tego diagramu rozpoczyna się od wiadomości początkowej 1.0, a następnie jest kontynuowane w kierunku, w którym komunikaty są przesyłane z jednego obiektu do drugiego.

W większości diagramy te 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 stają się znacznie łatwiejsze do zidentyfikowania niż na innym. Warto również zauważyć, że diagram komunikacyjny wyraźniej pokazuje, z jakimi elementami wchodzi w interakcję każdy z poszczególnych elementów, natomiast diagram sekwencji wyraźniej pokazuje, w jakiej kolejności zachodzą interakcje.

Diagram sekwencyjny

Diagram sekwencji UML przedstawia interakcje pomiędzy wieloma obiektami, uporządkowanymi według czasu ich wystąpienia. Ten diagram przedstawia uporządkowaną w czasie interakcję między kilkoma obiektami. W szczególności wyświetla wszystkie obiekty biorące udział w interakcji, a także pełną sekwencję wymienianych między nimi komunikatów.

Głównymi elementami są w tym przypadku oznaczenia różnych obiektów, a także pionowe linie przedstawiające upływ czasu oraz prostokąty przedstawiające działanie określonego obiektu lub spełnianie jakiejś funkcji.

Schemat współpracy

Ten typ diagramu pozwala na ukazanie interakcji pomiędzy kilkoma obiektami, abstrahując od kolejności przekazywania komunikatów. Ten typ diagramu wyświetla w zwartej formie absolutnie wszystkie wysłane i odebrane wiadomości określonego obiektu, a także formaty tych wiadomości.

Ponieważ diagramy sekwencji i diagramy komunikacji to po prostu różne widoki tych samych procedur, Rational Rose umożliwia utworzenie diagramu komunikacji na podstawie diagramu sekwencji lub odwrotnie, a także całkowicie automatycznie je synchronizuje.

Diagramy przeglądu interakcji

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

Warto zauważyć, że format ten łączy w sobie diagram współpracy i sekwencji, które dają możliwość rozważenia interakcji pomiędzy kilkoma obiektami w systemie powstającym z różnych punktów widzenia.

Schemat czasowy

Reprezentuje alternatywną wersję diagramu sekwencji, który jawnie demonstruje zmianę stanu wzdłuż linii życia w określonej skali czasu. Może być bardzo przydatny w różnych aplikacjach czasu rzeczywistego.

Jakie są zalety?

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 analiz i projektowania są semantycznie bliskie metodom programowania we wszystkich rodzajach współczesnych języków obiektowych.
• Z pomocą tego języka system można opisać z niemal każdego możliwego punktu widzenia, a różne aspekty jego zachowania są opisywane 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 poszerzanie, a także wprowadzanie własnych stereotypów graficznych i tekstowych, co sprzyja jego wykorzystaniu nie tylko w inżynierii oprogramowania.
• Język stał się dość rozpowszechniony i rozwija się dość aktywnie.

Wady

Pomimo tego, że konstruowanie diagramów UML ma wiele zalet, często krytykuje się je za następujące wady:

• Nadmierność. W zdecydowanej większości przypadków krytycy twierdzą, że UML jest zbyt duży i skomplikowany, co często jest nieuzasadnione. Zawiera sporo zbędnych lub praktycznie bezużytecznych projektów i schematów, przy czym najczęściej taka krytyka skierowana jest pod adresem wersji drugiej, a nie pierwszej, gdyż nowsze rewizje zawierają więcej kompromisów „zaprojektowanych przez komisję”.
• Różne nieścisłości w semantyce. Ponieważ UML jest definiowany przez kombinację samego języka angielskiego i OCL, nie ma on sztywności właściwej językom precyzyjnie zdefiniowanym za pomocą technik opisu formalnego. W pewnych sytuacjach abstrakcyjna składnia języka OCL, UML i języka angielskiego zaczyna być ze sobą sprzeczna, w innych zaś jest niekompletna. Niedokładność w specyfikacji samego języka wpływa zarówno na użytkowników, jak i dostawców narzędzi, ostatecznie prowadząc do niekompatybilności narzędzi ze względu na unikalny sposób traktowania różnych specyfikacji.
• Problemy w procesie wdrażania i studiowania. Wszystkie powyższe kwestie stwarzają wyzwania we wdrażaniu i uczeniu się języka UML, zwłaszcza gdy kierownictwo zmusza inżynierów do korzystania z niego bez wcześniejszej wiedzy.
• Kod odzwierciedla kod. Inna opinia jest taka, że ​​nie ważne są piękne i atrakcyjne modele, ale same działające systemy, czyli kod, który jest projektem. Zgodnie z tym poglądem istnieje potrzeba dalszego rozwoju skuteczna metoda pisanie oprogramowania. UML jest powszechnie ceniony w podejściach, które kompilują modele w celu ponownego wygenerowania 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 do tego, co narzędzie interpretujące UML może odgadnąć lub określić.
• Niedopasowanie obciążenia. Ten termin pochodzi z teorii analizy systemów w celu określenia niezdolności wejścia określonego systemu do dostrzeżenia innego wyjścia. Podobnie jak w przypadku każdej standardowej notacji, UML może reprezentować niektóre systemy wydajniej i zwięźlej niż inne. Dlatego programista jest bardziej skłonny do rozwiązań, które wygodniej łączą w sobie wszystkie zalety UML-a, a także innych języków programowania. Ten problem jest bardziej oczywiste, jeśli język programowania nie jest zgodny z podstawowymi zasadami ortodoksji obiektowej, to znaczy nie stara się działać zgodnie z zasadami OOP.
• Stara się być uniwersalny. UML to język modelowania ogólnego przeznaczenia, który stara się być kompatybilny z każdym dostępnym obecnie językiem przetwarzania. Aby w kontekście danego projektu zespół projektowy mógł osiągnąć ostateczny cel, konieczne jest wybranie odpowiednich cech tego języka. Ponadto możliwe sposoby ograniczenia zakresu UML w określonym obszarze prowadzą do nie w pełni wyartykułowanego formalizmu, który sam w sobie podlega krytyce.

Zatem użycie tego języka nie jest istotne we wszystkich sytuacjach.