Co to jest UML?

Co to jest UML?

Unified Modeling Language to otwarta standardowa notacja graficzna do rozwoju systemów zaproponowana przez Object Management Group. Notacja oparta jest na pracach Boocha, Rumbaugha i Jacobsona. UML to język modelowania do wyrażania i projektowania dokumentów, szczególnie przydatny do projektowania zorientowanego obiektowo. Język można stosować od ogólnego projektowania początkowego po bardzo szczegółowy projekt w całym cyklu rozwoju oprogramowania. Definicja UML jest następująca:

• Unified Modeling Language ( UML ) to język graficzny do modelowania i tworzenia systemów oprogramowania. Diagramy UML stają się wspólnym produktem pracy, którego używają programiści do omawiania wszystkich faz rozwoju oprogramowania, od analizy wymagań, przez projektowanie, aż po wdrożenie. Celem jest modelowanie systemu oprogramowania przed jego budową.
• Cytat: „Unified Modeling Language (UML) to rodzina notacji graficznych wspieranych przez jednolity meta-model, które pomagają w opisywaniu i projektowaniu systemów oprogramowania, szczególnie systemów oprogramowania tworzonych z wykorzystaniem stylu obiektowego (OO).” [Martin Fowler – UML Distilled] str. 1.

Dlaczego UML?

Wraz z rosnącą rozmiarem i złożonością architektur oprogramowania rośnie potrzeba modeli oprogramowania. UML to dominujący język modelowania w branży oprogramowania. Obecnie jest to standard de facto przyjęty przez Object Management Group, największą konsorcjum oprogramowania na świecie. Trudno znaleźć projekt oprogramowania z więcej niż 10 programistami, który nie wykorzystuje UML w jakikolwiek sposób do określenia swojej architektury.

Oto kilka dodatkowych faktów dotyczących wykorzystania UML w naszym procesie rozwoju oprogramowania:

• Oprogramowanie staje się coraz bardziej złożone: dość stara wersja Windows XP > 40 milionów linii kodu.
• Jeden programista nie może zarządzać całą tą ilością kodu.
• Kod nie jest łatwo zrozumiały dla programistów, którzy go nie pisali.
• Potrzebujemy prostszych reprezentacji dla złożonych systemów: modelowanie to sposób radzenia sobie z złożonością.

Co to jest model?

• Model to abstrakcja rzeczywistości, pomijająca szczegóły.
• „Zbiór wszystkich elementów opisujących Twój system, wraz z ich połączeniami, tworzy Twój model.” (Russ i Hamilton 12).

kiedy używamy UML do tworzenia modeli systemu przed jego kodowaniem, reprezentują one problem w uproszczony sposób. Dają strukturę do rozwiązywania problemów. Pomagają zrozumieć, jak można postępować wobec danego problemu. Pozwalają również eksperymentować z wieloma rozwiązaniami. Ponieważ modele tworzone są przed rzeczywistym rozwojem systemu, możemy zrozumieć różne możliwości, problemy, opcje itd. To również prowadzi do obniżenia kosztów rozwoju. Ponieważ czas nie będzie tracony na próby i błędy, produkt będzie gotowy w krótszym czasie. Modele również pomagają zarządzać złożonością problemu, dzięki czemu planowanie rozwoju, alokacja zasobów takich jak maszyny, programiści, testerzy może być łatwo przeprowadzona.

Czym UML NIE JEST?

• UML to nie notacja, ale język.
• UML nie należy do nikogo. Jest otwarte do użytku przez każdego, kto chce go wykorzystać. Nie jest własnością prywatną.
• UML to nie proces ani metoda.
• UML zachęca do stosowania technik zorientowanych obiektowo oraz iteracyjnych cykli rozwoju oprogramowania.
• UML nie jest trudny. Jest duży, ale nie trzeba go znać w całości. Nie ma również potrzeby używać lub rozumieć każdej drobnej rzeczy w nim.
• UML nie jest czasochłonny. Jeśli używany odpowiednio, stosowanie UML zmniejsza koszty rozwoju. W tym samym czasie daje zalety łatwego zrozumienia i komunikacji, zwiększonej produktywności i lepszej jakości.
• UML nie jest ograniczony. Jest wystarczająco elastyczny, aby umożliwić nową leksykę (koncepcje, słowa i terminy), właściwości (dodatkowe informacje o słowach) i semantykę (zasady języka), które są wymagane w konkretnym dziedzinie.

Cel UML

• Język modelowania wizualnego, a nie język programowania wizualnego. Choć niektóre narzędzia modelowania mają generatory kodu i niektóre mogą odwzorowywać modele z kodu.
• Został zaprojektowany w celu tworzenia diagramów wspierających proces rozwoju oprogramowania, jednak UML to nie jest proces ani metoda rozwoju oprogramowania. Dlatego UML jest niezależny od procesu.
• Standardowy język do tworzenia szkiców oprogramowania.
• Narzędzie komunikacji.
• Język do dokumentowania wymagań, architektury, testów, planowania projektu itp…
• Przeznaczony jest do systemów oprogramowania, ale może modelować inne systemy.
• Przeznaczony jest do wspierania procesu rozwoju opartego na obiektach.
• Może uchwycić zarówno struktury statyczne, jak i zachowanie dynamiczne systemu.
• Diagramy UML mogą pomóc zaangażowanym stronom zrozumieć, omówić i zgodzić się na wymagania.
• Diagramy UML mogą pomóc w abstrakcyjnym przedstawieniu skomplikowanych procesów na poziomie łatwiejszym do zrozumienia.
• Diagramy UML pomagają ułatwić rozwiązywanie problemów.

Co oferuje język modelowania?

• Elementy modelu: Pojęcia i semantyka
• Notacja: Wizualne przedstawienie elementów modelu
• Wskazówki: Wskazówki i sugestie dotyczące używania elementów w notacji

Krótka historia

W latach 80., gdy zaczęliśmy modelowanie, istniało wiele różnych metodologii. Każda z metodologii miała swoją własną notację. Problem polegał na tym, że jeśli różni ludzie używali różnych notacji, w pewnym momencie ktoś musiał dokonać tłumaczenia. Często jeden symbol oznaczał jedno w jednej notacji, a zupełnie coś innego w innej notacji. W 1991 roku wszyscy zaczęli publikować książki. Grady Booch wydał swoją pierwszą edycję. Ivar Jacobson wydał swoją, a Jim Rumbaugh swoją metodologię OMT. Każda książka miała swoje zalety i wady. OMT był bardzo silny w analizie, ale słabszy w projektowaniu. Metodologia Boocha była silniejsza w projektowaniu, ale słabsza w analizie. A Objectory Ivara Jacobsona świetnie radził sobie z doświadczeniem użytkownika, którego ani Booch, ani OMT nie brali naprawdę pod uwagę w tamtym czasie. Booch i Jacobson połączyli swoje metody w 1994 roku, a potem w 1995 roku dołączył do nich Rumbaugh. W 1997 roku OMG wydało UML 1.1, uwzględniając wkład innych, np. Yourdena. Wersja UML v2.x to najnowsza wersja.

Daty wydania

• 1995 – UML 0.8
• 1996 – UML 0.9 – Trzej przyjaciele
• 1997 – OMG przejmuje.
• 1997 – OMG UML 1.1
• 1998 – OMG UML 1.2
• 1999 – OMG UML 1.3
• 2001 – OMG UML 1.4
• 2003 – OMG UML 1.5
• 2003 – OMG UML 2.0 – Używane
• 2005 – OMG UML 2.0 – Ostateczna
• 2006 – OMG UML 2.1
• UML2.1.2 (11/04/07) – Aktualna wersja od 27/05/08

Motywacja unifikacji metod przez „trzech Amegos”

• Fakt, że metody indywidualne ewoluowały do siebie niezależnie
• Unifikacja semantyki i notacji w celu zapewnienia stabilności rynku projektowania obiektowego
• Oczekiwanie, że unifikacja poprawi wcześniejsze metody indywidualne

Partnerzy UML

• Firma Rational Software Corporation
• IBM
• Hewlett-Packard
• I-Logix
• ICON Computing
• Intellicorp
• MCI Systemhouse
• Microsoft
• ObjecTime
• Oracle
• Platinum Technology
• Taskon
• Texas Instruments/Sterling Software
• Unisys

Wprowadzenie notacji UML dla różnych metod przed unifikacją

UML reprezentuje unifikację notacji Booch, OMT i Objectory, a także najlepsze pomysły licznych innych metodologów, jak pokazano na rysunku poniżej. Poprzez unifikację notacji używanych przez te metody obiektowe, język modelowania unifikowany zapewnia podstawę dla de facto standardu w dziedzinie analizy i projektowania obiektowego opartego na szerokim doświadczeniu użytkowników.

Rola notacji

Notacja odgrywa ważną rolę w każdym modelu – jest klejem, który łączy proces. Notacja ma trzy role:

• Służy jako język komunikacji decyzji, które nie są oczywiste lub nie mogą zostać wyprowadzone z samego kodu.
• Zapewnia semantykę wystarczająco bogatą, aby uchwycić wszystkie istotne decyzje strategiczne i taktyczne.
• Oferuje formę wystarczająco konkretną, aby ludzie mogli rozumować, a narzędzia mogły ją przetwarzać.

Język modelowania unifikowanego (UML) zapewnia bardzo solidną notację, która rozwija się od analizy do projektowania. Niektóre elementy notacji (na przykład klasy, związki, agregacje, dziedziczenie) wprowadzane są w trakcie analizy. Inne elementy notacji (na przykład wskaźniki implementacji zawartości i właściwości) wprowadzane są w trakcie projektowania.

Zalety UML

UML można stosować do różnorodnychdziedziny zastosowań (np. bankowość, finanse, internet, lotnictwo, medycyna, itd.) Może być stosowane z wszystkimi głównymi obiektami i komponentami metody rozwoju oprogramowania i do różnych platform implementacyjnych.

• Wiesz dokładnie, co otrzymujesz
• Zmniejszysz koszty rozwoju
• Twoje oprogramowanie będzie działać tak, jak się tego spodziewasz. Mniej nieprzyjemnych zaskoczeń
• Poprawne decyzje są podejmowane przed otrzymaniem słabo napisanego kodu. Zmniejszone koszty ogólne
• Możemy tworzyć bardziej wydajne pod względem pamięci i procesora systemy
• Koszty utrzymania systemu będą niższe. Mniej ponownego nauki zajdzie
• Praca z nowym programistą będzie łatwiejsza.
• Komunikacja z programistami i zewnętrznych kontrahentów będzie bardziej efektywna.

Widoki UML 4 + 1

UML składa się z następujących czterech widoków systemu w trakcie rozwoju (patrz rys. 3) [Eriksson & Penker, 1998; Kruchten, 2000]:

• Widok przypadków użycia: pokazuje funkcjonalność systemu z perspektywy zewnętrznych aktorów; opisuje się ją za pomocą diagramów przypadków użycia i czasem diagramów działania.
• Widok logiczny: pokazuje, jak ta funkcjonalność jest zaprojektowana wewnątrz systemu, pod kątem jego struktury statycznej i zachowania dynamicznego; opisuje się ją za pomocą diagramów klas i obiektów (model statyczny) oraz diagramów przejść stanów, sekwencji, współpracy i działania (model dynamiczny)
• Widok komponentów: pokazuje organizację komponentów oprogramowania; opisuje się ją za pomocą diagramów komponentów.
• Widok wdrożenia: pokazuje konfigurację fizyczną (wdrożenie) węzłów przetwarzania w czasie działania w komputerach i urządzeniach oraz komponentów, procesów i obiektów, które na nich istnieją; opisuje się ją za pomocą diagramów wdrożenia.
• Widok procesu: pokazuje aspekt współbieżny systemu w czasie działania, takie jak zadania, wątki, procesy i interakcje oraz rozwiązuje problemy związane z komunikacją i synchronizacją tych wątków; opisuje się je za pomocą diagramów dynamicznych (diagramy przejść stanów, sekwencji, współpracy i działania) oraz diagramów implementacji (diagramy komponentów i wdrożenia).

Każdy system składa się z statycznego i dynamicznego modelu. Model statyczny jest przedstawiany w diagramach klas i obiektów. Jednakże ujawnia niewiele w kontekście zachowania systemu. Zachowanie systemu jest uchwycone graficznie za pomocą scenariuszy (tj. diagramów przypadków użycia), diagramów sekwencji, diagramów przejść stanów i diagramów działania. Te stanowią model dynamiczny systemu. Zachowanie systemu to łączne zachowanie wszystkich obiektów należących do systemu.

Jeśli chcemy odwzorować powyższe pięć widoków na iteracyjne fazy cyklu życia przedstawione na rys. 3, moglibyśmy powiedzieć następujące:

• Analiza obiektowa (OOA), która tworzy model wymagań użytkowników z perspektywy użytkownika, odwzorowuje się na widok przypadków użycia.
• Projektowanie obiektowe (OOD) dodaje szczegóły i decyzje projektowe (z perspektywy programisty) do analizy i odwzorowuje się na widok logiki.
• Na końcu implementacja lub programowanie obiektowe (OOP) odwzorowuje się na widok procesu, wdrożenia i komponentu.

Diagramy UML 2

UML ma kilka różnych typów diagramów, które mogą być używane do opisu modelu z różnych punktów widzenia. Istnieją dwa główne kategorie diagramów, które następnie są podzielone na podkategorie:

• Diagramy strukturalne –diagramy strukturalnereprezentują aspekt statyczny systemu. Te aspekty statyczne reprezentują te części diagramu, które tworzą główną strukturę i dlatego są stabilne. Te części statyczne są reprezentowane przez klasy, interfejsy, obiekty, komponenty i węzły.
• Diagramy zachowaniowe – każdy system może mieć dwa aspekty: statyczny i dynamiczny. Dlatego model uznaje się za kompletny, gdy oba aspekty są w pełni uwzględnione.
  Diagramy zachowaniowe w zasadzie zapisują aspekt dynamiczny systemu. Aspekt dynamiczny można dalej opisać jako zmieniające się/ruszające części systemu.

Diagramy strukturalne

• Diagram klas– diagram statycznej struktury klas i interfejsów systemu oraz ich relacji lub powiązań (w tym dziedziczenia, agregacji i powiązań), w tym operacji i atrybutów klas. Tryby prezentacji to: powiązanie, dziedziczenie, zależność. Jest to bardzo powszechny diagram w UML.
• Diagram obiektów– to diagram statycznej struktury systemu w konkretnym momencie lub sytuacji (zdjęcie), ilustrujący relację w systemie.
• Diagram komponentów– to diagram opisujący organizację i zależności komponentów wewnątrz systemu.
• Diagram struktury złożonej– to diagram badający instancje czasu wykonania połączonych ze sobą instancji współdziałających poprzez połączenia komunikacyjne.
• Diagram pakietów– to diagram ilustrujący, jak system jest podzielony na grupy logiczne i jakie mogą istnieć zależności między tymi grupami.
• Diagram wdrożenia– to diagram opisujący, jak jednostki fizyczne rozdzielalne (rozdzielalne elementy oprogramowania, aplikacje, serwery, aplikacje, sprzęt itp.) tworzą architekturę systemu rozproszonego.

Diagramy zachowaniowe

• Diagram przypadków użycia – diagram przypadków użycia (funkcje/serwisy oprogramowania) i rola aktorów (użytkownicy – zarówno ludzie, jak i systemy). Ten diagram jest z perspektywy użytkownika.
• Diagram aktywności – to diagram dynamiki systemu poprzez modelowanie przepływu sterowania od aktywności do aktywności. Pokazuje, jak system (np. obiekt/klasa) reaguje na zdarzenie wewnętrzne. (Uwaga: zdarzenia zewnętrzne opisuje diagram stanu). W modelowaniu procesów biznesowych możesz użyć tego diagramu do przedstawienia logiki przypadku użycia lub reguły biznesowej.
• Diagram stanu (inaczej diagram stanów, diagram maszyny stanów) – to diagram, który pokazuje, jak system (np. obiekt/klasa) reaguje na zdarzenie zewnętrzne. (Uwaga: zdarzenia wewnętrzne opisuje diagram aktywności).

Diagramy typów interakcji– interakcje części organizacyjnych modelu.

• Diagram sekwencji – to diagram interakcji i przepływu komunikatów między obiektami oraz ich względnej kolejności czasowej
• Diagram komunikacji(inaczej Diagramy współpracy UML1) – to diagram, który pokazuje, jak systemy współpracują ze sobą w celu wykonania zadania oraz relacje, które muszą istnieć między nimi. Diagram współpracy powstaje poprzez przeanalizowanie diagramu sekwencji i opisanie jego interakcji z diagramem klas. Podsumowując, ten diagram pokazuje przepływ komunikatów między obiektami oraz podstawowe związki (relacje) między klasami
• Diagram czasowy – to diagram, który bada zachowania jednego lub więcej obiektów w danym okresie czasu.
• Diagram przeglądowy interakcji – to diagram interakcji i sterowania przepływem między diagramami interakcji (diagram sekwencji, diagram komunikacji, diagram czasowy, diagram przeglądowy interakcji).

Profil UML

Profil UML to nie jest dokładnie diagramem, ale profil służący do opisu rozszerzeń i podzbiorów UML. Podzbiory są opisywane za pomocą Języka Ograniczeń Obiektów (OCL). Rozszerzenia tworzy się poprzez zdefiniowanie stereotypów, które są etykietami, które mogą ozdabiać dowolny element modelu. Na przykład możemy oznaczyć klasę jako „trwałą” i użyć tej etykiety do identyfikacji klasy, której instancje są przechowywane po zakończeniu działania systemu. Nieformalnie – i to jest ideologicznie niepoprawne – profil to dowolny zbiór rozszerzeń i podzbiorów UML, niezależnie od tego, czy są one zapisane za pomocą tych mechanizmów czy nie. Formalnie, profil to definicje OCL i stereotypów, które opisują zasady, które w UML 2 są zapisane w pakiecie.

Powiązane diagramy dla rozwoju oprogramowania

W zależności od różnic między metodologiami OOAD i ewolucji standardów UML nazwy diagramów i ich funkcje mogą się zmieniać z czasem. Oto przykłady diagramów i/lub produktów pracy, które mogą lub nie być częścią UML1 lub UML2, ale mogą być używane w metodologiach OOAD:

• Diagram kontekstu systemu
• Diagram relacji encji (podobny do diagramu klas) z ERD koncepcyjnym, logicznym i fizycznym
• Analiza odporności

Wnioski

Przeglądnęliśmy pochodzenie i definicję UML, aby zapewnić uproszczone zrozumienie, czym jest i co może nam oferować. Przeglądnęliśmy również, jak możemy skorzystać z jego zastosowania w naszym następnym projekcie rozwojowym, a także krótko omówiliśmy widoki architektoniczne, modele i typy diagramów dostępne w UML 2. UML to nie jest proces, ale otwarty standard graficznego języka modelowania do tworzenia systemów zintegrowanych z oprogramowaniem. Składowe potrzebne do sukcesu projektu wymagają trzech aspektów: notacji, procesu i narzędzia:

Tylko notacja – możesz nauczyć sięnotacji (np. UML), ale jeśli nie wiesz, jak jej używać (procesu), prawdopodobnie nie powiedzie się.

Tylko proces – możesz mieć świetny proces, ale jeśli nie potrafisz przekazać procesu (notacja), prawdopodobnie nie powiedzie się. Na koniec

Brak wsparcia narzędziowego – jeśli nie potrafisz skutecznie dokumentować artefaktów swojej pracy (narzędzie), prawdopodobnie stracisz dużo czasu i w końcu nie powiedzie się.

Narzędzie do automatyzacji UML

Visual Paradigm to narzędzie automatyzujące, które zapewnia sukces w projektach oprogramowania dzięki:

1. Łatwe edytowanie składni, aby zmniejszyć potrzebę zapamiętywania notacji
2. Wsparcie dla popularnych i najłatwiejszych procesów i zestawów narzędzi do rozwoju oprogramowania agile scrum
3. Automatyzacja do wygładzenia dla projektów i raportów produktu dowolnego rozmiaru w czasie rzeczywistym

Zasoby UML

1. Kompletny przewodnik po 14 typach diagramów UML – Cybermedian
   • Ten przewodnik zawiera przegląd 14 typów diagramów UML obsługiwanych przez wersję społecznościową Visual Paradigm. Wyjaśnia, jak diagramy UML pomagają w wizualizacji systemów intensywnie wykorzystujących oprogramowanie, a także opisuje funkcjonalność oferowaną przez każdy typ diagramu. Przewodnik również podkreśla zróżnicowanie Visual Paradigm w obsłudze różnych typów diagramów UML w różnych potrzebach modelowania11.
2. Naucz się modelowania UML za pomocą najlepszych darmowych narzędzi UML (online i desktopowych) – Cybermedian
   • Ten artykuł omawia korzyści z używania Visual Paradigm do modelowania UML, podkreślając wsparcie dla najnowszego standardu UML 2.x oraz szeroki zakres typów diagramów. Wspomina również o możliwościach integracji narzędzia z popularnymi platformami programistycznymi oraz jego szerokim zastosowaniu w akademii i przemyśle12.
3. Nauka na przykładach: Diagramy maszyn stanów UML – Cybermedian
   • Ten zasób skupia się na diagramach maszyn stanów UML i rekomenduje Visual Paradigm jako idealne narzędzie do tworzenia tych diagramów. Zapewnia szczegółowy przegląd sposobu, w jaki diagramy maszyn stanów mogą modelować zachowanie dynamiczne systemu, a także podkreśla integrację Visual Paradigm z narzędziami i platformami programistycznymi13.
4. Diagramy UML: Kompletny przewodnik – Cybermedian
   • Ten kompletny przewodnik wyjaśnia znaczenie diagramów UML w rozwoju oprogramowania oraz sposób, w jaki Visual Paradigm wspiera różne typy diagramów UML. Omawia diagramy strukturalne, behawioralne i interakcyjne, dostarczając wglądów na to, jak można wykorzystać Visual Paradigm do tworzenia skutecznych modeli UML14.
5. BEZPŁATNY Narzędzie online do diagramów UML – Cybermedian
   • Ten artykuł wprowadza Visual Paradigm Online (VP Online) Express Edition – bezpłatny narzędzie internetowy do tworzenia diagramów UML. Wyróżnia łatwość użytkowania narzędzia, brak ograniczeń oraz zgodność z różnymi przeglądarkami internetowymi, co czyni go dostępne rozwiązaniem do tworzenia diagramów UML na potrzeby osobiste i niekomercyjne15.
6. Zrozumienie diagramów czasowych UML: Kompletny przewodnik – Cybermedian
   • Ten przewodnik wyjaśnia diagramy czasowe UML oraz ich znaczenie w systemach czasu rzeczywistego. Omawia sposób, w jaki można wykorzystać Visual Paradigm do tworzenia tych diagramów, skupiając się na wizualnym przedstawieniu ograniczeń czasowych i trwania w systemie16.
7. Kompletny przewodnik do diagramów UML 2.5 – Cybermedian
   • Ten przewodnik zawiera przegląd diagramów UML 2.5 i wyróżnia Visual Paradigm jako pierwszy wybór w zakresie kompletnego modelowania. Omawia elastyczność narzędzia, przyjazny interfejs użytkownika oraz mocne możliwości generowania kodu, co czyni go odpowiednim rozwiązaniem dla specjalistów z różnych branż17.
8. Kompletny przewodnik do diagramu klas UML – Cybermedian
   • Ten przewodnik skupia się na diagramach klas UML oraz sposobie, w jaki Visual Paradigm wspiera ich tworzenie. Omawia szerokie przyjęcie narzędzia w środowisku akademickim oraz jego zastosowanie w projektowaniu i analizie systemów i baz danych. Przewodnik również wspomina o dostępności przykładów i szablonów do szybkiego rozpoczęcia modelowania UML18.
9. Poradnik do diagramu pakietów UML za pomocą Visual Paradigm – Cybermedian
   • Ten poradnik przewodnik po krokach tworzenia diagramu pakietów UML za pomocą Visual Paradigm. Wyjaśnia znaczenie diagramów pakietów w organizacji dużych systemów i zawiera krok po kroku instrukcje tworzenia ich za pomocą Visual Paradigm19.
10. Kompletny przewodnik do modelowania wizualnego w rozwoju oprogramowania agilnego – Cybermedian
    • Ten przewodnik omawia rolę narzędzi UML w rozwoju oprogramowania agilnego i wyróżnia Visual Paradigm jako popularny wybór. Wyjaśnia, jak Visual Paradigm oferuje przyjazny interfejs użytkownika oraz funkcje takie jak weryfikacja, generowanie kodu i inżynieria wsteczna, które poprawiają proces modelowania20.